【UML】UML入門
UMLの基本的な内容について解説します。
UMLとは
- Unified Modeling Language の略です。
- オブジェクト指向におけるプログラムの構造を把握する場合に使用します。
- システムの要件や業務の流れを整理する際にも使用されます。
- UMLに含まれる図のことを「ダイアグラム」と呼びます。
UMLを学習することのメリット
- クラス間の関連性の整理に役立ちます。
- オブジェクト指向の設計・理解の手助けとなります。
- 日本語の通じない相手にもクラス設計を伝えることができます。
- 業務分析の際の整理術として使用できます。
UMLについての知識がなくても、オブジェクト指向プログラミングは可能です。
しかし、デザインパターン(オブジェクト指向を活用した設計パターン)を理解しようと思うと、UML(その中でも特にクラス図)の理解は必須だと思ったほうが良いでしょう。
全てのダイアグラムを理解する必要はありませんが、「クラス図 + α」程度の知識があるとオブジェクト指向言語での開発・設計・分析をする際に役に立ちます。
ダイアグラム一覧
UMLで使用されるダイアグラムは以下のようなものがあります。
かなり多くのダイアグラムが存在しますが、大きく2種類に分類できます。
- 構造の表記
- 振る舞いの表記
構造の記述
- オブジェクト図
- クラス図
- コンポーネント図
- コンポジット構成図
- 配置図
- パッケージ図
振る舞いの記述
- アクティビティ図
- コミュニケーション図
- シーケンス図
- 状態マシン図
- 相互作用概要
- タイミング図
- ユースケース図
かなり多くの図があることがわかるかと思いますが、実際に業務で良く使用されているものはそれほど多くありません。
以下の4つを覚えておけば概ね困ることはないかと思います。
プログラムを把握するためによく使用されるダイアグラム
- クラス図
- シーケンス図
業務分析でよく使用されるダイアグラム
- ユースケース図
- アクティビティ図
ここからは各ダイアグラムについて簡単に解説します。
クラス図
UMLの中で最も使用頻度の高いダイアグラムです。
クラスの仕様とクラス間の関連性を記述できるものです。
デザインパターンを説明するうえでクラス図を使用するので、オブジェクト指向言語を学んでいる人は最低限クラス図は抑えておきましょう。
クラス図は以下のような図になります。
一番上はクラス名。
真ん中はフィールド。
下はメソッドになります。
クラスフィールドやクラスメソッドの場合は、下線を入れます。
アクセス修飾子を指定することも可能です。
アクセス修飾子を指定する場合は
- :private
:protected
- :public
をフィールド名やメソッド名の右側に記述します。
メソッド名やフィールド名の右側に型が書かれている場合もあります。
その場合、フィールドの右側にあるのはフィールドの型。
メソッドの右側にあるのはメソッドの戻り値の型になります。
継承
クラス図で継承を表すこともできます。
継承を表す図は以下になります。
図の矢印(中身が白で実線の矢印)は継承を指します。
上のクラスがスーパークラスで、下がサブクラスです。
抽象クラスや抽象メソッドは斜体で表記するのが一般的です。
矢印が指している方がスーパークラス。
クラス図を初めて見る人は、矢印は逆なのでは?と感じる人が多いです。
直感のイメージとしては、継承先の方に矢印が向いている方が自然に感じると思います。
しかし、実際には継承元の方に矢印が向くので注意してください。
矢印を、「知っている」という風にとらえるとしっくりくると思います。
サブクラスはスーパークラスを知っている必要があります。
一方でスーパークラスはサブクラスの存在を知らなくても単体で存在することが可能です。
矢印を、ある意味で「依存している」と捉えると理解しやすいかもしれません。
また、継承はモデリングの世界では、「特化-汎化」と表現されることがあります。
スーパークラスから見たサブクラスを「特化」
サブクラスから見たスーパークラスを「汎化」と呼びます。
実装
継承ではなく、インターフェースを実装する場合は以下のような図になります。
図が若干見えにくいかもしれませんが、矢印が実線ではなく破線になっています。
実装の場合は破線で表現します。
インターフェースはクラスと区別するために<
集約
以下は集約を表す図です。
集約は、インスタンス(オブジェクト)を配列やリストなどでフィールド(プロパティ)に保持しているイメージです。
図では、 Carクラス(車クラス)がTireクラス(タイヤクラス)をフィールドで複数保持している状態を表しています。
関連
以下は関連を表す図です。
関連、つまり、そのクラスのことを知っている状態を表した図です。
プログラム的には集約と同じ意味と捉えても良いでしょう。
持っている、というよりも、関連している、ということを強調したい時に使うようです。
使用
以下は使用を表す図です。
実線ではなく破線となっている点に注意してください。
図は、Utilクラスを使用することを表しています。
集約、関連、使用などについては、意味や表記方法が似ていてどこで何を使うかがイメージしにくいかもしれません。
正直なところ、UMLはプログラムと厳密に結びついているわけではなく、プログラムを整理したり、人に分かりやすく伝えるためのツールなので、厳密さにこだわるよりも、伝わりやすさを優先してケースバイケースで選べば良いでしょう。
シーケンス図
クラス図は、クラス間の静的な関係を表した図でした。
クラス図ではクラスの振る舞いの相互作用(どのメソッドからどのメソッドが呼ばれるかなど)は分かりません。
この振る舞いの相互作用を表したのがシーケンス図です。
オブジェクトとオブジェクト間のメッセージの流れを表現することができます。
オブジェクトに限らず、ユーザーとシステム間のメッセージのやりとりなどでも使用可能です。
いずれにせよ、時系列でのメッセージのやりとりを表現する手法として使用できます。
ユースケース図
ユースケース図は、ユーザーとシステム間のやり取り(相互作用)を記述すための図です。
これはシステムの要件定義などで使用されます。
アクティビティ図
手続きや、メソッド(関数)のロジック、ビジネスプロセスなどのフローを記述するための技法です。
フローチャートに似ています。
オブジェクト図
オブジェクトのある時点におけるスナップショットを表す図です。
インスタンス図とも呼ばれます。
クラス図だけでは構造を把握するのが困難な場合に有効です。
コミュニケーション図
シーケンス図では、時系列でオブジェクト間のやり取りを記述しますが、コミュニケーション図では、時系列に関係なくオブジェクトを配置できます。
メッセージのやり取りをオブジェクトの関係を中心に表現できる。
コンポーネント図
コンポーネントの構造や、コンポーネント間の相互作用と表す図です。
そもそもコンポーネントとは、ソフトウェアの部品という意味ですがクラスとの明確な違いはありません。
一般には複数のクラスから構成されるシステムの一部をコンポーネンと呼びます。
システムをいくつかの部品に分割し、その関係性や構造を示す場合に使用します。
コンポジット構成図
複数のクラスを包括するようなクラス、コンポーネントにおいて、その内部構造を表現するための図です。
ステートマシン図
ステートマシン図は、1つのオブジェクトの存在期間中における振る舞いを示す図。
相互作用概要図
相互作用概要図は、アクティビティ図とシーケンス図を合体させたものです。
アクティビティ図の中のアクテビティを、シーケンス図に置き換えたもの、もしくはアクティビティ図の記法で制御フローを分割したシーケンス図。
タイミング図
タイミングは、オブジェクトの状態が変化するタイミングを表すことを重視した図です。
配置図
配置図は、システムの物理的なレイアウトを示す図です。
ソフトウェアのどの部分がハードウェアのどの部分で動作するかを示す。
パッケージ図
パッケージとは、クラスをグルーピングするための仕組みです。
言語によっては名前空間とも呼ばれます。
パッケージ図は、パッケージ(名前空間)、およびパッケージ間の依存関係を表す図です。
規模が大きいシステムでは、パッケージ間の依存関係を把握するのに便利です。
まとめ
後半のダイアグラムに関しては、画像を入れてませんが、画像がない図においては使用頻度が低いものなので必ずしも覚える必要はありません。
(私もほぼ使用したことのないものばかりです)
興味がある方は書籍や他のサイトを参考に学習してみてください。
とりあえず、クラス図、シーケンス図、ユースケース図、アクティビティ図においては概要を理解しておき、それ以外は必要に応じて調べながら活用できれば良いでしょう。
クラス図は、業務で作成を求められない場合でも、自分自身のクラスの関連性を把握するために紙などに書くと頭が整理されますので、積極的に活用することをおすすめします。
関連書籍
もっと深く勉強したい方は以下の書籍がおすすめです。