Skip to content

Instantly share code, notes, and snippets.

@kkas
Last active August 29, 2015 14:23
Show Gist options
  • Save kkas/5aa0e4f65ae7320190ff to your computer and use it in GitHub Desktop.
Save kkas/5aa0e4f65ae7320190ff to your computer and use it in GitHub Desktop.
「第4回 UMLモデリング ハンズオンvol.1」に行ってきた
  • 2015/6/22

  • 4回目

  • 今回だけでは治らないと。なので、「vol.1」

  • 発表は長瀬嘉英さん

    • UML界隈では知らない人はいないとのこと
  • テクノロジックアートでやっているセミナーの抜粋

    • 資料:「実践UMLモデリングコンポーネントベースによる - UML2.x対応版 -」
  • UMLにはいろいろある。

    • ユースケースベース
    • コンポーネントベース ← これ
  • MDA

    • CIM (コンピューター処理日依存)
    • PIM (プラットフォーム日依存)
  • 業務分析

    • 業務領域ごとに分割

    • 登場人物の整理

    • ロール(役割)の定義

      • 登場人物とは異なる
        • 営業、営業部長、営業事務 (登場人物)
        • 受注係 (ロール)
      • モデルはロールベースで人物を登場させていく(変更容易性を向上させるため)
    • 業務のビジネスプロセスの定義

      • アクティビティ図
        • システムは書かない。業務の手順だけを記載する
        • あくまでもスナップショット。なので、事前条件、事後条件をきちっと書いておくのが重要
          • ばかでかい、分岐の多いものを書くのは間違い。それぞれ作成するのが正しい
        • Q. いっぱい作成すると、全体で整合性が合わなくなったりする。うまくやる方法は?
          • A. 対象を絞る。広げすぎない。
        • Q. 組み込みをやっている。なので、細かい話を書いてしまう。
          • A. コンピューターに関することはほとんど書かない。ユーザーの視点で書く
        • 開始したら、最後、そのロールまで戻るのが基本(らしい)by コダマ?
          • 戻らないやつもあるとは思う
      • 大きくなりすぎたら分割する。ただし、3階層くらいまでで納める
        • それ以上になると、悲惨な結末に
        • 細かすぎることは書かない
        • ある程度でやめる
    • <ハンズオン>

    • <解答例>

      • 最後はお客さんにあっているか確認してオK。大体の人は読める。(医者、看護師等も)
      • 予約台帳を書かなくてよい?
      • UML的にオブジェクトとしてやりとりする場合は記載するが、この場合はノートか何かで書いておいてもよい
    • 場合によっては、AS-ISは時間がないので、TO-BEだけ記述するような場合もある

  • 要求分析

    • モデルを基準に要求を聞き出し、整理する
      • 粒度・種類を事前に決めておく
    • 機能要求
      • ユースケース図として整理していく
    • 非機能要求
      • UMLで表現しずらい
      • 別途資料作成などする
    • ユースケース図
      • ユースケースでは「動詞」で記載していく
      • ユースケースは10個くらいの粒度で。それ以上の場合は、別システム扱いなどで別で記載する
        • ユースケース爆発
      • は詳細な機能。包含している
      • あまり使わない。後で機能を足し忘れた場合などに追加する。
      • ユースケースの候補
        • 事前に作成したアクティビティが候補となる
      • ユースケース図から書き始める人もいる。機能を出して。。。が、相当慣れた人がやる。
        • なぜいきなりユースケースずは難しいか?
          • 粒度を揃えるのが難しいため
      • 複数のアクティビティ図で共通した機能を利用する場合もある
      • ユースケース記述を記載する
        • オブジェクト思考で重要なのは、あくまでもインスタンス(具体的なもの)を考えた後、抽象化してオブジェクトモデル(クラス図)を作成する
          • なぜ具体的なものから考えるのか?
            • クラス図は正解が一つではない。変な設計でも動くかもしれない。
            • データ思考の場合、ある程度同じような設計になる
  • 以下の流れで設計していく

    • ビジネスプロセス ---- アクティビティ図
      • アクティビティ図からユースケース図は半自動的に作成できる
    • 機能 ---------------- ユースケース図
    • 値(シナリオ) -------- オブジェクト図
    • 構造 ---------------- クラス図
      • 熟練すると、いきなりクラス図から書くこともできる。(アジャイル開発のコードベース)
      • それ以外は、クラスが動くか不明(なぜそのクラス図が出てきたのか、エビデンスが少ない)
  • 重要なのは、半自動的に次のステップに進んでいくこと

  • アジャイル開発をやる場合でも、いきなりWFからは難しい。まずは、モデリングをしっかりと行って、慣れてから移行していくのがよい

  • Q. アジャイルでやるときに、

    • アジャイルでもクラス図くらいまではざっくりと作成しておくとよいのでは。
    • ベテランを入れてやっておく
    • テスト駆動で開発していき、事前にざっくりクラス図と照らし合わせて徐々に拡充していく
    • 慣れてくると、大体掴めてきたりもする
  • 次回予定: compassで発表。現時点では未定。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment