統一モデリング言語
背景
UMLについて雰囲気で読んだり都度意味を調べたりして読んでいました。
書く機会には恵まれず自分で書いたことは無いのですが、今後は書く機会があるかもしれないと思い一旦知識の整理としてそれぞれの意味について調べたので記事にします。
UMLとは
UML(Unified Modeling Language)は統一モデリング言語と言われ。ソフトウェアの成果物を仕様化、図式化するときに使用する。UMLとして表記法は統一されているが開発プロセスについては統一されていない
UMLを使用した開発では反復型開発プロセスが用いられる。
「要求分析」「分析」「設計」「実装」「テスト」の各工程を繰り返しながら開発を進める。
リスクが高いものや優先度が高いものは初期の繰り返しに計画し実施する
メリットは以下4点
- システムのリスクを早期に発見し回避できる
- 仕様変更に対する柔軟な対応ができる
- 繰り返し行うことにより品質が向上する
- 分割で1つの作業単位が小さくなるので複雑さが低減する
各工程それぞれで使用する図のまとめは下記
- 要求分析
- ユースケース図
- アクティビティ図
- 分析
- クラス図
- シーケンス図
- コミュニケーション図
- ステートマシン図
- オブジェクト図
- 相互作用概要図
- 設計
- クラス図
- シーケンス図
- コミュニケーション図
- ステートマシン図
- オブジェクト図
- 相互作用概要図
- アクティビティ図
- コンポーネント図
- 配置図
- 合成構成図
- タイミング図
- パッケージ図
- 実装
- テスト
モデリングとは、抽象化された概念をもとに分析領域の全体像をビジュアル化し、わかりやすく表現すること。
モデリングを行うことで対象領域を誰もが理解できるように目に見える形に作り上げることができる。
ユースケース図
ユーザの視点から、システムに対して要求する機能を表現する。
システム開発者から見た場合はシステムが提供すべき機能を表現する。
また、ユースケース図はシステム開発の初期段階で使用する。
ユースケース図を用いる目的は3点
- 開発対象システムの主要機能を明確にする
- 開発対象範囲を明確にする
- 開発対象システムと外部との関係を明確にする
ユースケースのサイズはアクターからみて、1つのユースケースを終了すれば目的が達成されており、かつ1つのユースケースの中では中断が行われないことを目安にする。
イベントフロー
イベントフローでは1つのユースケースにおけるすべての流れを、汎用的に記述します。
イベントフローでは次の項目ごとに記述します。
- 事前条件・・・ユースケースを開始するための制約や条件
- 事後条件・・・ユースケースが終了した後の制約や条件
- 基本フロー・・・イベントフローのもっとも一般的な流れ
- 代替フロー・・・基本フローより頻度が少ない正常な流れ
- 例外フロー・・・正常終了しない流れ
クラス図
クラスとクラスの静的な関係を表現する。
ユースケース図ではユーザから見たシステムの機能を考えたが分析段階のクラス図では、ユースケース図の時と同様にユーザ視点に立ち、どのような物や概念があるかを考える。
属性名 : 属性の型 = 初期値
操作名(引数名 : 引数の型) : 戻り値の型
クラス間に依存関係は次の場合に使用する
- 引数として参照するとき
- ローカル変数として参照するとき
- グローバル変数として参照するとき
可視性
-
- public ： 全てにおいて参照可能
-
- private ： 自クラスでのみ参照可能
-
protected ： 自クラス及びその派生クラスにおいて参照可能
- ~ package ： 同パッケージ内で参照可能
シーケンス図
シーケンス図はライフライン同士のメッセージを上から下に、順番に配置する。
処理の順番が明確な場合に時系列に沿って処理の流れを表現するのに適している。
ビジネス系のシステムでは一般的に処理の順番が明確な場合が多いのでシーケンス図がよく利用される。
矢印の先端を塗りつぶすと同期メッセージ、普通の矢印の場合は非同期メッセージ、点線矢印で同期メッセージの戻りを表現します。
あるライフラインが自分自身に対してメッセージを送信する場合、再帰呼び出しで表現することができる。
再帰呼び出しは、ライフラインの点線から出たメッセージを折り曲げて表記する。
コミュニケーション図
コミュニケーション図は、シーケンス図と同じ相互作用図の一つです。シーケンス図では処理の順番を考え、それに従いメッセージを上から下へ配置したが、そコミュニケーション図ではライフラインを中心にメッセージの送信を考えます。
コミュニケーション図はライフラインを中心に、ライフライン同士の関係を明確にした上で、メッセージのやり取りを表現します。シーケンス図の場合は上から下へでしたがコミュニケーション図の場合はそのようなルールがありません、なのでシーケンス番号で代用します。
ステートマシン図
相互作用図ではライフライン同士におけるメッセージのやり取りで、システムの動的な振る舞いを表現してきました。それに対してステートマシン図では。1つのオブジェクトの生成から消滅までに時間の経過に伴って変化する状態について表現します。
主に組み込み系の開発においては必須となっています。
アクティビティ図
アクティビティ図はシステムや業務の流れを表現するのに使用します。
アクティビティ図のモデリング
処理を順番に並べて矢印で接続していきます。処理の流れを最初に開始状態、処理の流れの最後に終了状態を配置します。
処理の分岐にはデンジョンノードを用いて表現する。
コンポーネント図
コンポーネント図はソフトウェアコンポーネント構成を表現します。ソフトウェアコンポーネントとは、あらかじめ決められたインターフェースを持った再利用部品です。それぞれの再利用部品をコンポーネントで表記し、ファイル関係はコンポーネント依存関係で接続して表現します。
配置図
コンポーネント図ではシステムを構成しているソフトウェアコンポーネントを表現しました。しかし、実行時にその物理的なファイルを配置するハードウェア構成についても表現する必要があります。配置図はコンピュータやプリンタといった機器やネットワーク接続関係など、システムのハードウェア構成を表現します。
一般的にノードにはコンピュータやプリンタなどハードウェアを表現する装置と、OS等のソフトウェアを表現する実行環境があります。ノードは立方体で表現し、ノード名を中に記述します。ノードが装置の場合はステレオタイプ<>のをノード名の上につけます。
UMLのデメリット
UMLには以下のようなデメリットが挙げられています。
これらをうまく理解し利用していく必要があります。特に学習コストに関し、UMLのバージョンが上がるにつれて複雑化していくので問題視されていることが多いようです。
- 言語肥大
- 学習と採用に関する問題
- コードとの同期問題
- インピーダンス不整合
- 見た目の不統一感
- 八方美人
これらの詳細についてはwikiをご参照ください。
統一モデリング言語
まとめ
とりあえずメインどころを調べて記載してみました。
雰囲気で読んで勘違いとかする可能性がこれで少しでも減るといいなって甘い考えです（笑）