ドメインモデル作成の5つの注意点 第4回：もう迷わないシステム開発（2/4 ページ）

[今田忠博, 近藤正裕，ITmedia]

概念モデルに対するイベントは業務そのもの

　ところで、業務で扱う要素に対するイベントは、業務そのものです。例えば、要素「在庫」に対する「出庫する」や「棚卸する」のイベントが業務です。

　そのため、概念クラス図で抽出されたそれぞれの要素に対するイベントは、別途サービスモデリングで作成された業務機能構造図（業務の一覧）に、業務として現れているはずです。もし現れていなければ、業務機能構造図に抜けがあるか、概念モデルに重要でない概念が入っている可能性があります。

　また、業務フローの途中で扱われる情報として、概念モデリングで得られる概念モデルが関連します。地図の例でいうと、「在庫」や「発注指示」などです。

　概念モデリングの作業を通じて、業務機能構造図と業務フロー、概念クラス図を相互に点検し、修正することで整合性を保つようにします。

用語集の作成

　用語集は、システムの利用者とコンサルタント間、ITアーキテクトと開発者間などのコミュニケーションにおいて、概念上の認識のズレが発生するのを防止し、一貫した用語を使用するために作成します。概念モデルと合わせて、トレーサビリティー（追跡可能性）の観点からも極めて重要なドキュメントとなります。

　今なお、多くのプロジェクトが用語の統一を省略して進められ、結果として仕様の間違いなどを引き起こしたり、設計書やプログラムコードの可読性に悪影響を与えたりしている例が散見されます。

• この作業の目的：
  • 業務領域で使用される単語の意味を共有し、コミュニケーションロスを少なくする
  • 誤解、思い込みによる手戻り作業の防止
  • 多義語、類義語、派生語、などを整理
• 入力：
  • 業務マニュアル
  • 関係者への聞き取り
  • 概念クラス図
  • 業務フロー
• 出力：
  • 用語集
• ポイント：
  • 用語集は、業務分析・要件定義の工程を通して継続的にメンテナンスされる
  • 英名を併記すれば、開発工程においてデータベースの項目名やクラス名、メソッド名を決定する際のよりどころとなる

ドメインモデルを作成する

　概念モデルを整理した後は、ユースケースモデルや画面・帳票などの仕様作成を経て、ドメインモデルの作成を行います。

　ドメインモデルは、業務領域を構成するクラスおよびクラス間の関係を抽出するために作成します。ドメインモデルの代わりにドメイン内のオブジェクトの情報に着目したエンティティモデルを作成しても良いでしょう。業務分析を行っている場合は、その分析で作成した概念モデルが下敷きとなります。概念モデルでは、対象ビジネス領域の概念・用語の整理が主な目的でしたが、これを設計が可能となるまで洗練させることでドメインモデル（エンティティモデル）とします。

• この作業の目的：
  • システム化対象領域のオブジェクト（クラス）とオブジェクト間の関係を明らかにする
  • オブジェクトの持つ情報と、操作を明らかにする
• 入力：
  • 業務フロー
  • 用語集
  • 概念クラス図
  • ユースケース記述（詳細、ドラフト）
  • 帳票など業務で実際に利用されている文書
  • 画面項目仕様
• 出力：
  • ドメインモデル（ドラフト）