分析設計 重要そうな作業手順メモ
UMLを使った分析設計の講習を受けた。忘れてしまわないうちにメモする。講習を受けるとなんとなくわかった気になるけどちょっとまとめてみるといろいろ疑問点がわいて来る。たしかに経験者が何人かいないとあっという間にプロジェクトが難航しそうだ。経験者がいないことの問題というのは、だれも作成したモデルを評価できないかららしいけれど、作業手順としても正しい手順を知っている人が何人か必要だ。さもなければメンバーの大半が今って何を何のためにやってるんだろうと目的を見失ってしまいそう。だからこそ、どの段階で何をどこまで詳細化すればいいのかといった目安やどこまで文書化すべきなのかといったガイドラインを決定するのが必要なのだろうけど、それを決定するのさえ難しそうだ。基本的にRUPを実行する場合、Rationalのツールを使わなければうまくいかないらしい。しかもかなり値がはるとか。うーんリスクが高い。でもRUPを使う使わないかかわらずオブジェクト指向設計で実現されたシステムを作るにはプロセスが必要なのは確かだろう。モデリングを重視したプロセスでないと機能単位にクラスが作成されてしまうだろうから。そもそもモデリングが出来るだけのオブジェクト指向技術があるのかどうかが問われるだろう、きっと。
分析設計は次のような流れで行われる。要求フェーズですでにユースケースモデルが作成されていることが前提。各工程のまとまりごとにレビューを行うことが大事。この流れを反復ごとに繰り返すことになる。
- アーキテクチャ分析（アーキテクト）
- ユースケース分析（設計者）
- アーキテクチャ設計（アーキテクト）
- レイヤ構造を決定する
- サブシステムを決定する
- パッケージ構造を決定する（クラス間強度に着目する、またコラボレーション図からメッセージの頻度がわかりグルーピングの目安となる）
- 設計者に提供するための永続性/分散性/並行性などのメカニズムを決定
- ユースケース設計（設計者）
- サブシステムインタフェースを取り込み相互作用図を作成する（外部とのインタフェースとなるバウンダリをサブシステムインタフェースとする）
- すでに洗い出されているアーキテクチャメカニズム（永続性/分散性など）をサブシステムとして1つずつ取り込む詳細な相互作用図を作成する（サブシステムとして取り込むことで複雑性を軽減する）
- 個々のユースケースから導き出された設計モデルを統合しひとつの設計モデル（クラス図）を作成する
- サブシステムの責務を振り分け、内部構造を決定し、サブシステムの依存関係を特定する（責務の振り分けは操作1つに対して1つ以上の相互作用図を作成して行う）
- 個々のクラスを詳細化し（派生属性に注意）、クラス間の関係も詳細化する（誘導可能性、関連クラス、変態に注意）
