ＵＭＬを使用したシステム構築(作成中 2001/6/15)

要求仕様の確認

ユースケース図

システム要求を整理し、要求仕様とするときに使用します。
より具体的に定義するために各ユースケースに基本シナリオと２次シナリオを作成します。

アクティビティ図

ビジネスプロセスや電子商取引のＢ２Ｂプロセスを表現する時に使用します。プロセスを知っている人（主にユーザ）に確認を求めたり、（開発者ではなく）プロセスを知っている人が自ら使用します。

開発体制の決定

パッケージ図

パッケージ図は名前空間の分割を定義するもので、パッケージ（ある意味サブシステム）の依存関係を定義します。大きなシステムを開発する際には必須のものです。なぜなら開発者の担当割に影響するからです。（サブシステム間の結合度をうまく低くすれば会議を少なくできる！）パッケージ分割については以下の指針が適用できます。

・最も重大な（依存される）型は一般的（抽象的）かつ非依存的にする

・より具体的なパッケージに依存しない
　　↑
　　インターフェイスや抽象クラスを用いる

・変更が「オール・オア・ナッシング」でパッケージに影響する（高い凝集度）
　　↑
　　逆に言うとパッケージを超えて影響しないようにする（低い結合度）

・独立的な型を括り出す（当たり前）

・ファクトリを使って具象パッケージへの依存度を弱める（低い結合度）
　　↑
　　具体的にはファクトリの戻り値はインターフェイスとする

・パッケージに循環依存がないこと
　　↑
　　もしそのようなときはパッケージを分割する

システム開発の実施（設計）

クラス図

システムをどのように設計するかを示します。クラス図は設計の静的な見方です。
その時の基準になるのが、カップリングとコヒージョンです。また、良い設計の定石として使えるのがデザインパターンです。

シーケンス図

クラス図作成を補助します。クラス図は静的な見方ですが、シーケンス図は動的な視点から見て、クラス図の正しさを確認します。

状態遷移図

オブジェクトが幾つかの状態を持つときに作成します。特に通信（サブ）システムの開発時にはステートパターンを意識して書くと効果的です。

システム開発の実施（実装）

コンポーネント図

コンポーネントはパッケージ図に記載されたサブシステム(外部に見せる操作リストである仕様部とクラスのコラボレーションである実装部を持つパッケージの一種)を実装したものです。
コンポーネント図ではコンポーネントの形式を定義します。

配置図

システムはハードウェア上に配置されたコンポーネントの集まりです。
配置図では、どのハードウェア上に何のコンポーネントを配置するか定義します。

参考リンク

communityUML:最新のUML仕様についての策定活動を行っているホームページ