UML再考

UMLベースの開発手法を整理するためのメモ。

【参考】
オブジェクト指向設計の４つの流派からドメイン駆動設計へ: プログラマの思索

【1】要求定義フェーズ：

a)目的：利用者の要求や現行の業務から、システムの要求を定義し、システムの全体像を描く。

b)利用例：
①ユースケース図：利用者やシステムであるアクターと機能要求を表すユースケースから成る。
開発対象の機能要求の範囲が明確になる利点がある。

＜感想・留意点・課題＞
1)ユースケース≠機能。ユースケースは、アクターに対する価値あるサービス。

2)ユースケースを機能分割するのは良くないと言われる。
理由は、ユースケースがどんどん詳細化されて収拾がつかなくなるから。

しかし、機能分割しないユースケースは粒度が大きすぎて、ユースケース図を書く意味が薄れる。
ユースケース記述書を書く場合、類似した内容は、Includeしたユースケースで記述したくなる。
Includeされるユースケースを洗い出しておけば、再利用できるから、ユースケースを記述する量が減るからだ。
だから、どうしてもユースケースは機能分割したくなる。

ユースケース図のあるべき姿は何なのか？

ユースケースを記述する粒度 - Ken's Blog

3)astahでは、ユースケースをどのように利用すればよいか？

astahでは、マインドマップで、アクターやユースケースを洗い出しておけば、右クリックで生成できる。
つまり、マインドマップでラフなスケッチとしてアクターやユースケースを書き出すと、すごく楽。

ユースケースが使える場面は、SysMLの要求図、CRUD表、ロバストネス図。

3-1)要求図では、要求(Request)を実現する(satisfy)対象としてユースケースを対応づけることができる。
つまり、ユースケースの発端となる顧客の要求の関連を示すことができる。
この方法を徹底できれば、顧客の要求→ユースケース(実現すべき機能・サービス)→クラス(実装対象)へ後方追跡できるだけでなく、逆方向から前方追跡できるようになる。

設計工程でトレーサビリティを実現できれば、仕様変更や障害修正で変更すべき要求から、影響を受けるユースケースやクラスを調査でき、実装漏れを減らせる。
また、影響対象の機能の規模が分かれば、工数を見積もれるので、コストの予測の精度も上がる。

astah 6.1 で「要求モデル」が目指している姿：An Agile Way：ITmedia オルタナティブ・ブログ

3-2)CRUD表は、ユースケース(機能・プロセス)とクラス(クラス図)・テーブル(ER図)に関するCRUD表。
画面Aの機能Bでは、どのクラスまたはどのテーブルを参照し、更新し、登録・削除されるか、を示す。
CRUD表の利点は、詳細設計書やテストケース、テストデータの元ネタになること。

画面Aの機能Bの詳細設計書では、CRUD表を見ながら、対象テーブルの参照・更新の処理をトランザクション処理の観点で書けばいい。
画面Aの機能Bのテストケースでは、参照されたテーブルのデータが画面に反映されているか、更新対象のテーブルに想定通りの入力データが入っているか、を確認するケースを書けばいい。
そのために必要なテストデータを洗い出しやすくなる。

ユースケースが効果的な場面はおそらく、CRUD表として用いる時ではないかと個人的に思っている。
データモデリングの設計経験がある人がCRUD表を見れば、どんな機能であるか、その機能の画面の入力項目はどんなレイアウトか、その機能の開発規模はどれくらいか、を想像できるだろう。

Railsのようなフルスタックフレームワークを知っていれば、テーブル設計さえできれば、scafoldでWeb画面は一瞬で自動生成できる。
しかも、テーブルのレイアウトと画面の入力項目は強い依存関係があるから、テーブルレイアウトから画面のユーザインターフェイスを想像できる。
実際、外部キーがあれば、ポップアップの検索画面が欲しくなるし、複合キーがあれば、ヘッダ部分は検索条件、リスト部分は明細データのようなレイアウトに強制されるから。

渡辺幸三さんの本「業務システムモデリング練習帳」を読めば、テーブルレイアウトと画面のユーザインターフェイスの関係性に法則があるのがよく分かる。

3-3)ICONIXプロセスでは、ユースケースをオブジェクトの絵として表現する時、ユースケース記述の内容をロバストネス図で表す。
ロバストネス図は、論理的なDFDと見なせる。
ロバストネス図に出てくるバウンダリ、エンティティはクラス、コントローラはクラスのメソッドに対応付けられる。

ユースケース駆動開発実践ガイドを読んでわかったこと - paz3のおもいつき

ロバストネス図は手書きが一番書きやすい。
また、ロバストネス図はDFDの代わりに書きやすい。
Webの画面設計だけでなく、バッチ処理に出てくるジョブフロー図の代わりにも書けるから便利。

ロバストネス図は素晴らしい - 檜山正幸のキマイラ飼育記

②アクティビティ図：利用者の業務や現行システムの機能を手続き的流れで表した図である。
主に利用者の業務フローを可視化し、機能要求を抽出するために使われる。

＜感想・留意点・課題＞
1)「業務システム」を「コンピュータ上で動く情報システム」だけでなく、「ユーザが関わる手運用の業務」も含めるものとして見なす時に、有効。
ITコンサルとしてシステム提案する時、システムの機能だけでなく、どの利用者がどのようにシステムを使い、実際の業務を行うのか、をイメージする時に使う。

業務システムを導入するのは、業務のコスト削減が目的なので、アクティビティ図からその箇所を明示できると良い。
たとえば、手運用のプロセスが減る、とか、関わる人数が減る、とか、リードタイムが短くなる、とか。

2)アクティビティ図では、ステータスよりも処理やプロセスを記述する。
その時、処理の目的が分かるように明記する方が良い。
つまり、アクティビティの粒度は荒く、システムへの実装はあまり意識しない。
その方が、システムの仕様変更があっても、アクティビティ図への影響が小さくなるから。

3)アクティビティ図は、レーンを使った場合とレーンを使わない場合の2種類を意識して使い分ける。

3-1)レーンを使う場合、アクターに組織またはロールを当てはめる。物理的な業務モデル。
プロセスの流れが同じでも、どのアクターに配置するか、で業務の意味が変わってくる。

アクターに配置されたアクティビティ(プロセス・業務)が多いほど、その役割に期待される責任の量は大きい。
下手をすると作業負荷が集中しやすくなる。
役割分担を再配置することは、組織構造の変更に最終的につながる。

3-2)レーンを使わない場合は、論理的な業務のモデル。
組織や役割を当てはめる前のモデル。
「機能関連図」と呼ばれるモデルに相当する。
組織や役割は機能ではなく、機能の一部として書く。

4)アクターにシステムが出る場合、システムのレーンのアクティビティはユースケースに対応づけられる。
だから、ユースケース図は、アクティビティ図で書かれた業務の流れの順にユースケースを縦に並べて上から下へ並べると分かりやすくなる。

【2】システム分析フェーズ：

a)目的：ユースケースから利用者と設計者が相互理解できる概念モデルを作成する。

b)利用例：
①クラス図(概念モデル):問題領域の概念を表すクラスとその関連をまとめた図である。
但し、分析フェーズで使われるクラス図はそのまま実装されるのではなく、システムの機能要件や制約を分析するために使われる。

＜感想・留意点・課題＞
1)ドメイン駆動設計で使われる最も重要な成果物。
ユビキタス言語がクラスで表現される。

概念モデルのクラス図の設計は、ER図のモデリングと同じ。
どんな情報を蓄積したのか？
その情報をどのように加工したいのか？

2)クラスの抽出元は、ユースケース記述に出てくる名詞。
しかし、実際はそれ以外の概念もクラスに出てくる。

イベントはクラスで抽出しやすい。
イベントを時系列に並べると業務フローになる。

クラス図で表現しにくいのは連関エンティティ。
リソース同士の関連(A◇--C--◇B　の絵)をどう表現するか？

ER図ならば、テーブルCに外部キーが2個ある場合と、テーブルCに複合キーがある場合(連関エンティティ)は厳密に区別される。
しかし、クラス図では両方とも同じ表記になってしまい、混同されがち。

あえて連関エンティティを表現したいなら、「A◆--C--◆B」の絵で表現するか？

3)astahでは、ステレオタイプごとにクラスを色付けすると、絵として読みやすくなる。
ER図と同じく「リソース(マスタ)」「イベント(トランザクション)」「サマリ」の3種類で色付けしてもいい。

②オブジェクト図：クラスのインスタンス同士の関係を示した図である。主にクラス間の関連や多重度を検証するために使われる。

＜感想・留意点・課題＞
1)オブジェクト指向設計を十分に理解しているかどうかは、オブジェクト図の使い方で分かる。
実際のインスタンスがどのように関連付けられるのか、を理解できていないと、オブジェクト図は書けない。
オブジェクト図が書けるならば、多重度やクラス間の関連の意味を説明できるだろう。

2)クラス図を書く前にオブジェクト図を書くと理解が早まる。
astahでは、クラス図上でオブジェクト図が書ける。

【3】システム設計フェーズ：

a)目的：概念モデルを元に論理的な設計モデルを構築する。

b)利用例：
①クラス図：概念モデルのクラス図をより具体的に詳細化する。

＜感想・留意点・課題＞
1)astahでは、テキストファイルにクラス名の一覧を洗い出しておき、クラス名の一覧をコピー＆ペーストすると、クラスを自動生成できる。

2)クラスに「Actor」のステレオタイプを付けると、ユースケースのアクターにもなる。

②シーケンス図：クラス間の動的な相互作用を表す。

＜感想・留意点・課題＞
1)シーケンス図は詳細設計書と同じ。
プログラムの記述はシーケンス図で表現できる。

詳細設計書→プログラムのフォワードエンジニアリングよりも、現行システム→詳細設計の抽出というリバースエンジニアリングで、シーケンス図が役立つ時が多いと思う。
プログラムの流れを大量の日本語で読むよりも、絵で読み取る方が概要はつかみやすい。

ユースケース駆動開発実践ガイドを読んでわかったこと、その2 - paz3のおもいつき

2)astahでは、クラスをドラッグ＆ドロップすれば、ライフラインが表示される。
クラスのメソッドを選択すれば、メッセージを表現できる。

③ステートマシン図：あるクラスの状態の変化に着目し、生成から消滅までのライフサイクルを表す。

＜感想・留意点・課題＞
1)一つのクラス、オブジェクトのライフサイクルを状態の変化で表す。
ステートマシン図は、プログラム設計だけでなく、業務モデルの設計にも使える。

会員クラスの状態遷移図も書けるし、画面遷移図をステートマシン図と見なしてももいい。
ワークフローシステムで、一つの申請書に申請者→上長→経理部のようなハンコの押印を状態とみなしてもいい。

2)ステートマシン図は、組み込み設計ではすごく重要。
センサー、監視モニタなどの操作をステートマシン図で表現できれば、詳細設計書に落とせるし、テストケースにもなりえる。
絵で描ければ、大量の日本語の仕様では気づかなかった、処理の漏れも見つけやすくなる。
例えば、この状態から別の状態へ移る遷移はあるはずなのに、設計書に漏れていた、とか。

3)ステートマシン図とアクティビティ図、シーケンス図は1対1に対応する。
アクティビティ図のアクティビティやシーケンス図のメッセージは、ステートマシン図のアクティビティに相当する。
ステートマシン図の状態は、アクティビティ間の矢印、シーケンス図の活性区間に相当する。

シーケンス図とアクティビティ図と状態遷移図の関係: プログラマの思索

だから、アクティビティ図やシーケンス図を書いた時に、ステートマシン図も一緒に書くと、仕様の網羅性が高まるはず。

4)ステートマシン図は、プログラムの自動生成に必須の情報がすべて含まれている。
おそらく、DSLもステートマシン図で表現できるだろうと思う。
形式手法におけるSPINも、システムからある範囲の状態遷移図をリバースエンジニアリングで復元し、そこからしらみ潰しに状態遷移を計算してバグを見つけ出そうとする。

モデルから動くプログラムを自動生成したい場合、ステートマシン図は必須だ。

④コミュニケーション図：クラス間の相互作用を責務の観点から表現する。

⑤パッケージ図：クラスをパッケージにまとめてレイヤ化する。

＜感想・留意点・課題＞
1)パッケージ図はあくまでも、クラスやユースケースなどを整理するための論理的枠組み。

2)凝集度や結合度、レイヤー設計で使う。

【4】実装フェーズ：

a)目的：設計フェーズの成果物を物理的なコンポーネントや物理的資源(例:サーバー)へ対応付けて配置する。

b)利用例：
①コンポーネント図：クラスやパッケージ等をコンポーネントとして部品化した図である。
大規模プロジェクトでシステムを俯瞰する際に有用である。

＜感想・留意点・課題＞
1)コンポーネントは、パッケージとは違う。
コンポーネントは、メッセージを送信できる部品。
パッケージはあくまでも分類しただけ。

コンポーネントの例は、WindowsのEXE、DLLなどのように、実行可能な物理ファイルや呼び出し可能な物理ファイル。
Javaならwar, ear, jar, classなど。

2)コンポーネント図の使い道はよく分からない。
使える場面が極端に少ない気がする。

コンポーネントの中身を表現しようとしても、10個ぐらいのコンポーネントではそもそも頑張って描いてもあまり意味がない。

The Rational Edge：UML 2.0のキホン：コンポーネント図の詳細解説 - ITmedia エンタープライズ

The Rational Edge （22）：サブシステムの「なに？」「なぜ？」「どうやって？」（前編） - ITmedia エンタープライズ

②配置図：コンポーネントと物理的資源の関係を表した図である。
ハードウェアやコンポーネントの依存関係を可視化するのに役立つ。

＜感想・留意点・課題＞
1)配置図は、ルータやファイアウォールなどのネットワーク図の代わりに使える。
また、リリースされる物理ファイルの配置イメージにも使える。

配置図から非機能用件を類推する: プログラマの思索

2)配置図は、クラス図のような概念モデルと、オブジェクト図のようなインスタンスモデルの2種類がある。
実際に使えるのは、オブジェクト図のように、ノードのインスタンスで物理的ファイルを表現して、その関連を描く場合。

例えば、バッチ処理のファイルを配置する場合、そのファイルがどこに配置されるか、他のファイルとどのように関連するかを記述できる。
開発環境と本番環境の違いも的確に表現できる。

配置図は必須 - ビープラウド社長のブログ

また、ノードのインスタンスをサーバーに対応付けて、IPアドレスを振れば、ネットワーク図と同等になる。
ExcelやVisioで書かれたネットワーク図はアイコンで表現する時が多いが、ほぼ同じ。

ゼロから始めるUMLモデリング講座 (12) 配置図の作成 | マイナビニュース