ところで、業務で扱う要素に対するイベントは、業務そのものです。例えば、要素「在庫」に対する「出庫する」や「棚卸する」のイベントが業務です。
そのため、概念クラス図で抽出されたそれぞれの要素に対するイベントは、別途サービスモデリングで作成された業務機能構造図(業務の一覧)に、業務として現れているはずです。もし現れていなければ、業務機能構造図に抜けがあるか、概念モデルに重要でない概念が入っている可能性があります。
また、業務フローの途中で扱われる情報として、概念モデリングで得られる概念モデルが関連します。地図の例でいうと、「在庫」や「発注指示」などです。
概念モデリングの作業を通じて、業務機能構造図と業務フロー、概念クラス図を相互に点検し、修正することで整合性を保つようにします。
用語集は、システムの利用者とコンサルタント間、ITアーキテクトと開発者間などのコミュニケーションにおいて、概念上の認識のズレが発生するのを防止し、一貫した用語を使用するために作成します。概念モデルと合わせて、トレーサビリティー(追跡可能性)の観点からも極めて重要なドキュメントとなります。
今なお、多くのプロジェクトが用語の統一を省略して進められ、結果として仕様の間違いなどを引き起こしたり、設計書やプログラムコードの可読性に悪影響を与えたりしている例が散見されます。
概念モデルを整理した後は、ユースケースモデルや画面・帳票などの仕様作成を経て、ドメインモデルの作成を行います。
ドメインモデルは、業務領域を構成するクラスおよびクラス間の関係を抽出するために作成します。ドメインモデルの代わりにドメイン内のオブジェクトの情報に着目したエンティティモデルを作成しても良いでしょう。業務分析を行っている場合は、その分析で作成した概念モデルが下敷きとなります。概念モデルでは、対象ビジネス領域の概念・用語の整理が主な目的でしたが、これを設計が可能となるまで洗練させることでドメインモデル(エンティティモデル)とします。
Copyright © ITmedia, Inc. All Rights Reserved.