UMLやSysMLなどのモデリングは“いつ”“何を”“どうするのか”：プロジェクトを成功させるモデリングの極意（3）（4/8 ページ）

「モデリングはいつ誰が何をどのようにするのか」――今回はソフトウェア開発の現場で、モデリングを実際にどのように実施しているのか見ていきましょう。またUMLやSysMLの使いにくいところを、開発現場ではどのようにカバーしているのかも見ていきます。

[五味弘，MONOist]

モデリングの種類

　ここからはモデリングの種類にはどんなものがあるかを見ていきましょう。ソフトウェア開発で使うモデルでは、モデルの抽象度・粒度に応じて、以下のモデルがあります。

概要モデル・概念モデル

　システムの概要を表現するためのモデリングです。概要レベルのクラス図などで記述します。

仕様モデル

　システム仕様またはプログラム仕様と同レベルな抽象度・粒度のモデリングをします。仕様レベルのクラス図やシーケンス図で記述します。

詳細モデル・実装モデル

　実装可能なレベルの詳細なものまでモデリングをします。詳細レベルのクラス図やシーケンス図、アクティビティ図で表現します。

　また、モデリングの目的に応じて、以下のモデリングがあります。

概念モデル・機能モデル

　要求分析のときに使うモデルで、実装の制約を記述することなく、対象の概念をユーザー視点で記述します。その対象が何をするか（WHAT）を中心に記述し、AS-IS（現状）のものをクラス図やアクティビティ図で描きます。

分析モデル

　概念モデルを抽象化し、拡張性や再利用性を高めたモデルです。概念モデルがAS-IS を記述するものであったのに対し、To-Be (あるべき状態)のものを記述するモデルです。このため概念モデルより理解しにくいものになっています。分析レベルのクラス図やシーケンス図で記述します。

実装モデル

　具体的な実装手段を考慮した実装するためのモデルで、どのようにして（HOW）実装するかを記述します。実装の制約条件も記述し実装レベルのクラス図やシーケンス図、他の図で表現します。

　次の分類としては何をモデリングの対象にするかで分類することができます。

ビジネスモデリング（business modeling）

　ビジネスモデリングはビジネスのコンセプトとプロセスを記述するものです。例えば、EAではプロセスをワークフロー（UMLのアクティビティ図などで記述）で、ビジネスの機能をユースケース図で、ビジネスの構造をクラス図で表現することが多いです。

• 要求モデリング（requirements modeling）

対象システムの要求をモデリングします。要求を抽出し、要求間の関係をモデルで表現します。UMLではユースケース図やそれを補間するシナリオ記述とアクティビティ図などで示します。

アーキテクチャモデリング（architecture modeling）

　対象システムのアーキテクチャをモデリングします。クラス図や一部シーケンス図を使って構造やふるまいを記述します。コンポーネントの配置は配置図で表現します。

• 設計モデリング（design modeling）

　対象システムの設計をモデリングします。どのようにシステムを実装するかその方法が分かるように記述します。実装上の制約条件も記述することになります。クラス図やシーケンス図、アクティビティ図などで記述します。

データモデリング（data modeling）

　対象システムのデータやその関係、データの流れをモデリングします。E-R図やDFD、クラス図、オブジェクト図で表現します。

　これらの分類は文献によって名称や分類数などが異なっているものもあります。しかしここで訴えたいのは、モデリングを分類の軸として、粒度、目的、対象に分けて、それらをごっちゃにしないということです。粒度を統一し、目的を絞り、対象を明確にして、モデリングすることをくれぐれも肝に命じておいてください。このときに、上記の分類学を思い出し、自分は今、どんなモデリングをしているのかを再認識して、モデル図を描いてください。