第2回で確かめたとおり、ソフトウェアは目に見えません。 見えないものをチームで共有し、議論し、合意するには、 共通の記法が要ります。それが UML（Unified Modeling Language）です。
UML は言語であって、方法論ではありません。
「こう描けば、この意味になる」という約束事の集まりです。
どんな順序で設計を進めるかは決めていません。
だから、ウォーターフォールでもアジャイルでも使えます。
| 図 | 表すもの | いつ使うか |
|---|---|---|
| ユースケース図 | 誰が（アクター）システムに何をさせるか | 要求分析。システムの外枠を決める |
| クラス図 | クラス・属性・操作と、クラス間の静的な構造 | 分析・設計の中心。もっともよく使う |
| シーケンス図 | オブジェクト間のやりとりを時間に沿って並べたもの | ある処理の流れを追うとき |
| 状態遷移図 | 1 つのオブジェクトが取りうる状態と遷移 | 状態で振る舞いが変わるものを設計するとき |
| アクティビティ図 | 処理や業務の流れ（フローチャートに近い） | 業務の手順を整理するとき |
静的な図と動的な図。 クラス図は「どうできているか」、 シーケンス図や状態遷移図は「どう動くか」を表します。 両方そろってはじめてシステムが分かります。 構造だけ見ても動きは分からず、動きだけ見ても全体像はつかめません。
クラス図でよく使う関連は 3 つです。
| 関連 | 意味 | 読み方 | 例 |
|---|---|---|---|
| 汎化（継承） | 一方が他方の特殊な場合である | is-a（〜は〜である） | 正社員は従業員である |
| 集約 | 全体と部分の関係 | has-a（〜は〜を持つ） | 注文は注文明細を持つ |
| 関連 | 単に結びつきがある | 〜が〜を使う など | 学生が科目を履修する |
よくある誤り。
「継承できるから継承する」のは危険です。
is-a が成り立つかどうかで判断してください。
たとえば「正方形は長方形である」は数学的には正しいのですが、
プログラムで長方形クラスを継承した正方形クラスを作ると、
「幅だけを変える」操作で破綻します。
継承は、共通部分をくくり出す便利な道具である前に、
「〜は〜の一種である」という強い約束です。
関連の線の両端には、いくつ対応するかを書きます。
| 書き方 | 意味 |
|---|---|
1 | ちょうど 1 つ |
0..1 | 0 個または 1 個 |
* または 0..* | 0 個以上（いくつでも） |
1..* | 1 個以上 |
たとえば「注文 1 ── 1..* 注文明細」と書けば、
1 つの注文には必ず 1 つ以上の明細があることを表します。
多重度は、要求のうち数に関する約束を図に固定するものです。
すべての図を描く必要はありません。
UML には十数種類の図がありますが、実務でよく使われるのは
クラス図・シーケンス図・ユースケース図のあたりです。
図は考えるためと伝えるために描くものです。
描くこと自体が目的になると、更新されない図が増えて、
かえって誤解のもとになります。