UMLの仕組みと実装がこれ1冊で分かる本

UMLの基礎知識

• 開発方法論がそもそも乱立していた
• オブジェクト指向のパラダイムがUML誕生の基礎にある
  • その他の開発手法論
    • Booch法
    • OMT法
    • OOSE法
  • こういう手法論における表記方法としてUML 0.9が提唱。標準化団体ができて、UML 1.1が標準として採択
• 各バージョンをざっくり
  • 0.9：最初のバージョン
  • 1.1：OMGによって標準化された最初のバージョン
  • 1.5：1系の最後。2系に移行せずに今もコレを採用していることがあるらしい
  • 2.0：システム開発以外にも、ビジネスモデルの定義等の上流での需要もあった。それに応える目的で図の種類が9から15に増えた。
  • 2.5：UML自体のドキュメントとかUML自体を定義するメタモデルの整備が進んでいる
• モデリングで抽象化する時には目的に合わせた取捨選択が大事
  • 不要な情報を削る
• システム開発でのモデリング手順
  • 情報収集→全体のモデリング→詳細のモデリング
  • 情報収集
    • 業務フロー的なものをヒアリング
  • 全体のモデリング
    • 主に順序性に着目して
  • 詳細なモデリング
    • 詳細化する。各データの深掘りとか

オブジェクト指向

• 包含関係
  • スーパークラスとサブクラスの関係
  • 2種類ある
    • 集約
      • A has a B
      • 継承関係を持たせられる
        • 車に対する救急車みたいな
    • コンポジション
      • A is a part of B
      • 集約よりも強い関係
      • 不可分な関係に使う
        • 車に対するエンジン。ラップトップにおけるモニタ
• 関連関係
  • テーブル定義でのリレーションがあることで大丈夫
• クラス間の依存関係
  • 一方のクラスに変更があると依存してるクラスの振る舞いも影響を受ける
  • たいていの関係に当てはまる
    • 継承関係だと親の変更がこの全てに影響する
• インターフェース
  • インターフェースには振る舞いだけを定義するが、具体的なビジネスロジックまでは定義しない
  • クラスをインターフェースを継承して実装することで、同様のメソッドを持ったクラスの保守性が上がる
    • 例えば、タッチパネルの操作用のインターフェースがあれば、スマホとかタブレットで共通の目そっでおで操作するくらすを実装しやすい
• クラスからインスタンスを作る。インスタンスとオブジェクトは同じもので大丈夫
• メソッドの呼び出しとかをメッセージと言うらしい
  • アラン・ケイ曰く一番大事な考え方
• 処理形態の種類
  • 非同期処理
  • イベント駆動処理
• オブジェクト指向の3大要素
  • カプセル化
    • クラスの利用され方を制限する機能のこと
    • クラス・メソッドの可視性とも言える
      • public：どこからでもアクセスできる
      • private：クラスの外からアクセスできない
      • protected：クラスとそのサブクラスからアクセスできる
      • package：同一パッケージ内からアクセスできる
        • java固有？
  • 継承
    • インターフェースとか抽象クラスとかを継承することで、共通部分の実装コストを抑えられる
  • 多態性(ポリモーフィズム)
    • 同じメソッドでもクラスによって振る舞いが違うこと
• 設計原則
  • クラス間の依存関係を低く保つ
    • 継承の濫用を避ける
    • インターフェースはできるだけシンプルに保つ
  • 高凝集にする
    • 1つのクラス・パッケージの役割をはっきり定めるといっても良い

3章　UMLの全体像

• 大きく2分すると構成図と振る舞い図
  • 構成図：静的構造の表現
    • オブジェクトやクラス、システムの部品等
  • 振る舞い図：動的構造の表現
    • 処理の実行順とか
    • メッセージによる振る舞いの連携を表現する図を特に相互作用図ともいう
• 一覧
  • 構成図
    • クラス図
    • オブジェクト図
    • パッケージ図
    • コンポーネント図
    • 合成構造図
    • 配置図
  • 振る舞い図
    • 相互作用図
      • シーケンス図
      • コミュニケーション図
      • 相互作用概要図
      • タイミング図
    • ユースケース図
    • アクティビティ図
    • ステートマシン図
• 図の構成要素
  • frame（枠）
  • shape（図形）
  • edge（関連線）
  • partition（区分）
• オブジェクト・クラスは矩形
  • 上にオブジェクト名・クラス名
  • 下に線で区切って属性やオブジェクトを列挙する
  • クラス図だと- 属性名: 型、+ メソッド名(引数): 戻り値の型
  • オブジェクト図だとオブジェクト名 = クラス名
• 開始・アクション・完了
  • 開始は黒丸
  • 終了は黒丸の周りに円
  • アクションは角丸矩形
• 要素間の関連は実践でつなぐ
  • 線の上に説明
  • 線の両端に矢印とか
  • 線の両端に数字とか記号とか
• 遷移を表現したい時
  • 矢印でつなぐ
  • 主に振る舞い図で使う
• UML図の間で図形の意味は基本的に共通だが、稀に違うらしい
• ステレオタイプ
  • 図形とか線に厳密な定義を加える
  • <<ステレオタイプ名>>の形で表現する
    • 例えば、クラス図のクラスに<<interface>>と書くと、そのクラスがインターフェースであることを表現できる
• 制約・条件
  • {制約・条件}の形で表現する
    • 例えばクラス図の属性で- 商品名: String {unique, > 1000}は一意であることを表現できる
  • タグ付き値
    • {タグ名 = 値}の形で表現する
      • version = 1.0でそのコンポーネントのバージョン
  • ノート
    • 補足説明
    • おそらく特定の書式はないが、テキストの例だと矩形の角が折れてる要素に補足を書いて、破線で繋ぐ
  • UMLツール

4章　　UMLにおける構造図の基本文法

• まずは読めるレベルを目指す

オブジェクト図

• モノ・コトの関係性の表現が目的。クラス図作成の下準備みたいな立ち位置っぽい
• 使用する図形要素
  • オブジェクト
    • 矩形
    • 上にオブジェクト名 : クラス名
      • オブジェクト名未定の時は省略して:クラス名でも可
    • - 属性名 = 値の形で属性を列挙する
      • クラス図だと型を書く。オブジェクトは具体例をベースに共通性を探ってる感じがする
• 使用する関連線
  • 関連
    • 矢印
  • 包含は一端が菱形の実線（矢印ではない）
    • 集約：包含される側に、白抜き菱形

クラス図

• クラスの属性や振る舞い定義。クラス関係の表現
• 使用する図形要素
  • オブジェクト図とだいたい同じ。オブジェクト図だと具体的な値が入るところに型を書く感じ
  • アクセス修飾子がある
    • +：public
    • -：private
    • #：protected
    • ~：package
  • インターフェースもかける
    • ステレオタイプとして<<interface>>と書くのがMUST？
    • インターフェースの仕様上…
      • 属性は書けない
        • プログラミング言語によっては定数をかけなくはないが、仕様にはない。
      • 振る舞いはすべてpublic
  • その他の要素
    • バウンダリ
      • アクタが利用するモノ・コトをクラスかしたもの
      • クラス名の上に<<boundary>>と書く
    • エンティティ
      • DBとかで永続化するモノ・コトをクラス化したモノ
      • クラス名の上に<<entity>>と書く
    • コントロール
      • 業務や機能を管理するマネージャーのようなモノ・コトをクラスかしたもの
      • クラス名の上に<<control>>と書く
  • 関連線
    • オブジェクト図と一緒
    • 数量の関係も表記できる
      • 両端にかける。線の上下に数の意味と数量をかける
      • 範囲も表現できて、0..*は0以上の任意の数を表す
    • 依存関係は線の矢印
      • 線の上にステレオタイプで<<use>>と書く
    • 継承/実装関係は先端が白抜き三角の矢印の実線
      • 継承は実践。実装は破線
      • 矢印はスーパークラスの方に向ける

合成構造図

クラスやオブジェクトの構造関係を図時する。 インターフェースも含められる。目的に応じて何をクラスとして表現するか変えるらしい。

使用する図形

• パート
  • 矩形の中に、オブジェクト名: クラス名の形で表現する
    • オブジェクト未定の時に省略OK
    • 同じクラスの複数オブジェクトを表現するのにクラス名[数量]
• 構造化分類子
  • クラスのことを指す
  • 矩形の上部にクラス名を書く
  • 中にパートの要素図形を書く。コレも矩形
• インターフェース
  • 提供インターフェース
    • 合成構造子のクラスが実装しているインターフェース
  • 要求インターフェース
    • 合成構造子のクラスを利用するクラスに実装していて欲しいインターフェース
  • 例えば…
    • タイヤクラス・エンジンクラス・動力インターフェースがあるとして
      • エンジンクラスと動力インターフェースは提供インターフェースの関係
        • エンジンクラスは動力インターフェースを実装する
        • タイヤクラスと動力インターフェースは要求インターフェースの関係
          • タイヤクラスを使うクラスは動力インターフェースを実装していて欲しい
• ポート
  • 構造化分類子とかパートの外枠につける小さい矩形
  • カプセル化されてるメソッドの公開されている場所のこと。
  • 実装関係とかでも、ポートを通して繋ぐぽい
• 関連線
  • 実線でつなぐ。線の上に説明をかける
  • 依存関係とかメッセージを送る関係とかでも繋ぐ
  • だいたい見たらわかる

パッケージ図

クラス・インターフェースをどうパッケージに配置するか。 パッケージ感のインポート関係も示せる。 実際に構築するシステムのファイル配置の参考にもできる。 クラス図と合わせて作る。

図形種類

• クラスとパッケージと同様
• パッケージは短い矩形にパッケージ名、その下に大きな矩形
• 関連線
  • アクセスかインポートか
    • アクセスは依存先のクラス・インターフェースだけ使える
    • インポートなら孫クラス・インターフェースも使える点でより依存性が高い
  • アクセスは破線の矢印。ステレオタイプが必須？
  • インポートは実線の矢印
  • マージという関係もある
    • マージした両方のクラスの属性と振る舞いを兼ね備えたクラスができる
    • パッケージCに対して、パッケージAとBから破線の矢印が伸びる感じ。ステレオタイプ必須？

コンポーネント図

• コンポーネントの連携や依存関係等を表現する
• コンポーネントの粒度は難しいが、単独で機能を果たす部品を指す

使用する図形

• ポート・パート・インターフェース・コンポーネントなのでだいたい割愛
• コンポーネント
  • 矩形の右上にコンポーネントのマークを置く。ステレオタイプとして<<component>>と書いても良い
  • provided interfacesとrequired interfacesをそれぞれかける
• 関連線
  • クラス図と同じ線

配置図

• システムの部品の物理的な配置
  • ソフトウェアの設定ファイル
  • jarファイル
  • dllファイル
• パッケージ図よりもさらに大きな粒度で、システムのより広い範囲を表現する

要素図形

• アーティファクト
  • 矩形の右上にファイルマーク、もしくはステレオタイプに<<artifact>>
  • アーティファクト名には下線を引く
  • warファイルだとjarファイルのアーティファクトと入れ子みたいに書く
• スペック
  • ステレオタイプに<<{任意の名前} spec>>と書く
  • 下の矩形に設定値名: データ方/設定値を書ける
• デバイス
  • 物理的なHW。OSもこれで表現することがあるぽい
  • 立方体で表記する（奥行きがある矩形）
  • ステレオタイプ
    • <<device>>
    • <<executionEnvironment>>
• 関連線
  • 依存と通信経路
  • 依存は破線の矢印
  • 通信経路は実線
    • 数量を両端の数字で表現できる

5章　UMLにおける振る舞い図の基本文法

これもまずは読めるレベルを目指す

ユースケース図

• 顧客にシステムの説明する時によく使う
  • どのような機能があるか
  • 誰がその機能を使えるか
  • ユースケース：システムが提供する機能のこと
  • アクタ：システムを利用する人・モノ
• 目的に合わせて粒度を調整する

使用する図形

• アクタ
  • 棒人間
• ユースケース
  • 楕円
  • 拡張ポイントという概念がある
    • ユースケースのクラスのメソッドが別のクラスを使っていること
    • 例えば口座引き出し機能内で、本人確認用の別クラスのメソッドを使うとか
    • 図的には図形中央を線で区切った下に書く
• 関連線
  • 関連
    • 実線
  • 継承
    • スーパークラス側に白抜き三角形の実戦の矢印
  • 包含
    • 破線の点線の矢印
    • 包含される方に矢印
    • 拡張と同じ破線矢印なので、ステレオタイプ必須（<<include>>）
  • 拡張
    • は線の点線の矢印
    • 拡張する方に矢印
    • 包含と同じ破線矢印なので、ステレオタイプ必須（<<extend>>）

アクティビティ図

• 処理の順番
• 分岐・繰り返しとかバッチ的な非同期処理も表現できる

使用する図形

• アクション
  • 角丸四角形
  • アクションの入れ子で親子関係
  • アクション感を矢印で繋いで順序
• メソッド呼び出しアクション
  • アクションの右側に振る舞い呼び出しマークをかく
  • 用途は別のより詳細な図（アクティビティ図とか）へのリンク？
• オブジェクト
  • オブジェクト図と同じ
• ピン
  • 小さい矩形
  • ピン同士でアクションがある場合、オブジェクトのやり取りがあるという意味
  • クラス図のポートみたいなもの
  • ピン図形の上にやり取りするオブジェクト名をかける
• 開始
  • 黒塗りの丸
• 終了
  • 黒丸の外に円
• フロー終了
  • まるとその中のバツ
  • 非同期とかで分離して行われている処理の終了に使う
• ディシジョン・マージ
  • 菱形
  • 条件はノート（点線で繋いだ角が折れた図形）に書く。図形内にステレオタイプで<<decisionInput>>とかく
• フォーク
  • 非同期処理での処理の分離のこと
  • 太線
    • フォークの時は太線に1本の矢印が向いて太線から複数矢印が出る
    • ジョインは太線に複数矢印が向いて1本出る
• タイマー
  • 一定時間経過後にイベントが発生する
  • 砂時計マーク
  • 下に時間条件を書く
• 関連線
  • 遷移
    • 矢印実線
    • 矢印の順番で処理が実行される
    • 離れたり線が重なったりする時には円形の図形に降板を振って線を省略する
    • 遷移条件は[条件]の書式で線の上に書ける
    • 例外イベントはギザギザの線
• 区分
  • パーティション
    • アクションの分類。アクタかオブジェクトが普通
  • 中断可能範囲
    • イベント駆動におけるイベントを受け付ける範囲
    • 点線の角丸矩形
    • イベント中断アクション
      • アクションの繊維を中断するイベントのこと
      • 左辺が凹んだ矩形で書く
      • 中断可能範囲外に配置した場合は常に中断イベントを待ち受ける意味合いになる。イベント中断アクションから次のアクションへは例外イベントと同じギザギザの線で繋ぐ

    • ステートマシンズを作る時に参考になる

Column

パターン

• デザインパターンやアンチパターンの話
• Facadeパターン
  • GoFパターンの中にある？
  • クラスが増えて、メソッドを使うのが大変になった時に、メソッドをまとめたクラスを作る。このクラスをインポートしたら必要なメソッドをまとめてインポートできる状態が楽

依存性の逆転

• 一般に、ビジネスの都合等で変更の多い部分を定位損にする工夫を取る
• 依存性の逆転という手法がある
  • 例えば
    • AsIs：銀行振込機能がATM画面機能に依存している
      • この状態はATM画面機能に変更が入ると銀行振込機能も変更が必要になる
    • ToBe：銀行振込機能がインターフェースを提供して、ATM画面機能がそのインターフェースを実装する（ATM画面機能の要求インターフェースにする）
      • この状態だと、銀行振込機能はATM画面機能に依存しないので、ATM画面機能に変更が入っても銀行振込機能は変更が必要ない