UML
ソフトウェアの構造や振る舞いを図で表すための、統一されたグラフィカルなモデリング言語。オブジェクト指向による分析・設計で使われ、OMGが標準化している。
イマシルちゃんの解説
ソフトウェアの設計を人に伝えるとき、文章だけでは部品の関係や動く順序を追いにくいことがあるよ。
UMLは、ソフトウェアの構造や動きを共通の記号と図で表すモデリング言語なんだ。
例えば扱うデータや操作をまとめた型をクラスと呼び、その内容やクラス同士の関係をクラス図で表すよ。
一方、部品同士がどんな順序でメッセージをやり取りするかはシーケンス図で表せるの。
知りたいことに応じて図を使い分けるんだね。
記号の意味が決まっているから、設計を共有するときの認識の違いを減らせるよ。
作り始める前に、必要な処理やつながりが抜けていないかを話し合うのにも役立つんだ。
この解説はわかりやすかったですか?
より深い解説
定義
UML(Unified Modeling Language)は、1990年代に、それまで乱立していたオブジェクト指向の分析・設計の表記法を統一して作られたモデリング言語である。現在はOMG(Object Management Group)が仕様を管理し、ISO/IEC 19501などとしても標準化されている。プログラム言語ではなく、設計を表現するための「図の言語」である。
主なダイアグラム
UML 2では、ダイアグラムを大きく2つに分けている。
| 分類 | ダイアグラム | 表すもの |
|---|---|---|
| 構造図 | クラス図 | クラスの属性、操作と、クラス間の関係(関連、汎化、集約など) |
| 構造図 | オブジェクト図 | ある時点のオブジェクト(インスタンス)とその関係 |
| 構造図 | コンポーネント図、配置図、パッケージ図 | 部品、ハードウェアへの配置、整理の単位 |
| 振る舞い図 | ユースケース図 | 利用者(アクタ)から見たシステムの機能 |
| 振る舞い図 | シーケンス図 | オブジェクト間のメッセージのやり取りを、時間の順に表す |
| 振る舞い図 | アクティビティ図 | 処理の流れ(フローチャートに近い) |
| 振る舞い図 | ステートマシン図 | オブジェクトの状態と、イベントによる状態の遷移 |
| 振る舞い図 | コミュニケーション図 | オブジェクト間のメッセージのやり取りを、つながりを中心に表す |
クラス図の主な関係
| 関係 | 意味 | 例 |
|---|---|---|
| 汎化(継承) | 「AはBの一種である」(is-a) | 「普通預金口座」は「口座」の一種 |
| 集約 | 「全体と部分」で、部分が独立して存在できる | 「チーム」と「選手」 |
| コンポジション | 「全体と部分」で、全体が消えると部分も消える | 「注文」と「注文明細」 |
| 関連 | 互いに関係がある | 「顧客」と「注文」 |
関連には、相手の数(多重度)を「1」「0..1」「1..*」「*」のように書き添える。
UMLを拡張した言語
UMLは、プロファイルという仕組みで、特定の分野向けに拡張できる。システムズエンジニアリング向けに、UMLの一部を流用して機能を拡張したものが、SysMLである。
種類と部品を見分ける
is-a関係は「AはBの一種である」と読める関係である。たとえば「定期預金口座は口座の一種である」は成り立つ。UMLの汎化関係では、一般的なクラスへ向かう実線と白抜き三角形で表す。
一方、「口座が残高を持つ」は属性を、「自転車が車輪を持つ」は全体と部分を表す。「残高は口座の一種」「車輪は自転車の一種」とは読めない。操作の名前も、通常はその対象の一種ではない。
図の上下の配置だけで判断せず、矢印が指す一般的な概念へ、下位の概念を種類として分類できるかを確かめる。
汎化・特化と個々の実体
複数のクラスから共通の性質を取り出し、一般的なクラスとして整理することを汎化という。反対に、一般的なクラスから条件や性質を詳しくした種類を定めることを特化という。
| 用語 | 独自の例 |
|---|---|
| 汎化 | 正社員と契約社員の共通の性質を社員としてまとめる |
| 特化 | 社員を、雇用形態の違いから具体的な種類へ分ける |
| 継承 | 下位のクラスが、上位のクラスで定義された性質を引き継ぐ |
| インスタンス | 社員クラスに従って作られた、個々の社員を表す実体 |
クラスは種類や構造の定義であり、インスタンスはそれに基づく具体的な実体である。クラス同士を「一般的な種類と具体的な種類」に分ける関係を、インスタンスの関係と取り違えない。
状態とイベントを整理する
状態遷移図では、対象が置かれる状態と、イベントによって次の状態へ移る関係を表す。遷移には、必要に応じてガード条件や実行する処理を付ける。
| 現在の状態 | イベント・条件 | 次の状態 |
|---|---|---|
| 待機 | 接続要求を受ける | 接続中 |
| 接続中 | 接続に成功する | 利用可能 |
| 接続中 | 制限時間を超える | 待機 |
| 利用可能 | 切断される | 待機 |
これは通信機器を想定した独自の例である。同じイベントでも、現在の状態によって反応が異なることを表現できる。データの流れを表すDFD、条件と動作の対応を整理する決定表、結果と原因候補を整理する特性要因図とは、表したい関係が違う。
UMLの成立には、OMT(Object Modeling Technique)などのオブジェクト指向の分析・設計手法の統合が関わっている。MDAはモデルを軸に実装へ展開する開発の考え方であり、図を表現する言語と同じものではない。
全体と部分の関係
part-of関係は「AはBを構成する一部分である」と読める関係である。たとえば「鍵盤はピアノの一部である」は成り立つが、「鍵盤はピアノの一種である」とは言えない。反対に「グランドピアノはピアノの一種である」は、部品ではなく種類の関係である。
| 観点 | is-a関係 | part-of関係 |
|---|---|---|
| 読み方 | 一種である | 一部分である |
| モデルでの用途 | 一般的な種類と具体的な種類を整理する | 全体がどんな部分から構成されるかを表す |
| 独自の例 | グランドピアノとピアノ | 鍵盤とピアノ |
全体と部分というだけでは、部分の寿命や共有の可否までは決まらない。UMLで集約とコンポジションを選ぶ場合は、その所有や寿命の条件も確認する。名称の印象だけで継承関係へ置き換えない。
入力列を状態に沿って検査する
入力文字列の妥当性を調べるときは、現在の状態から、その文字に対応する遷移が存在するかを一文字ずつ追う。存在しなければ、その時点で受け付けられない列である。同じ文字でも状態によって意味が変わる。
取消し記号が「直前の一文字を消す」とは限らない。入力項目を一つ前へ戻すなど、図に定義された遷移に従う。空白、改行、自己遷移も省かずに追う。最後まで読めても、受理する終了状態に到達していなければ有効とは限らない。
属性と操作を扱う考え方
| 概念 | 目的 |
|---|---|
| 継承(インヘリタンス) | 上位のクラスで定義した性質を下位のクラスへ引き継ぐ |
| カプセル化 | 内部のデータと操作をまとめ、外からの直接操作を制限する |
| 抽象化 | 目的に必要な性質を取り出し、細部を省いて捉える |
| ポリモーフィズム | 共通の操作でも、対象の種類に応じた振る舞いを実現する |
これらは組み合わせて使われるが、同じ意味ではない。例えば内部表現を隠すことと、上位の定義を再利用することを区別する。継承では可視性などの制約があるため、上位クラスのすべての内部データへ下位クラスが無制限に直接アクセスできるわけではない。