はじめての設計をやり抜くための本【設計編】第3章外部設計の手法④概念モデリング
概念モデルとは
要件定義で作成されることがある。その後、設計のフェーズで画面設計などの外部仕様を整理するうちに、足りない概念が発見されることはよくある。
そのため、設計の中で更新される可能性が高い。設計者が概念モデルを更新するか、要件定義者が更新するのかは状況により異なる。
ユースケースがシステムの動的な振る舞いを表す。対して概念モデルはシステムの静的な構造を表す。ユースケースで記述した様々な概念（会員、注文、配送、返品など…）についてはユースケース内では詳細な内容については触れていない。その概念の属性、他概念との関係性について概念モデルで明らかにする。
概念モデルはデータの構造を表す。概念モデルをもとにDB論理設計を行う。
また、概念モデルはUMLのクラス図で記述する。
特徴
・ユースケースは日本語で記述するので概念モデルも日本語で記述する。
・「int」、「String」などの属性（データ型）は記載しない。
・概念モデルをクラス図で表す場合は操作は記載しない。
概念モデルで表現するものは下記の３点
○概念の名前を整理する
○概念の関連を整理する
○概念の関連の多重度を整理する
概念モデルで注意すべき点
概念モデルという表記法が完璧ではない。上記の図でクラスと関連、集約、コンポジションなどで表現できることは全てではない。概念モデルで表現できるビジネスルールはあるが、表現できないビジネスルールもある。
概念モデルの書き方
最初に、それぞれの概念を洗い出す。ユースケース記述があれば概念となるべき候補をユースケース記述から洗い出す。ユースケースが無い場合は一番代表的な概念をピックアップする。（受注システムであれば「注文」、
「会員」、「商品」など）
○注文に関わる概念の例
注文、注文番号、注文日時、合計価格、購入者、配送先、商品数量、商品価格、商品名、商品説明
UML（クラス図）作成
１．注文を書く
２．注文番号を書く
注文にはかならず１つだけ注文番号がある。そのため注文と注文番号は
１対１の関係となる。
３．２とその他の概念をまとめて属性とする。
「注文番号」、「注文日時」、「合計価格」を注文の属性としてまとめる。
４．その他の概念と関連付ける
このシステムでは会員登録されている会員のみ注文できる。会員は多くの注文ができ。１つの注文の購入者は必ず１人のため会員と注文は１対多の関係となる。１対１とならない、注文の属性にはできない、また、ログインや他会員向け機能もあるため別のクラスとする。
５-a．配送先追加
配送先の情報が単純に住所を文字列として持つのであれば注文の属性に追加する。
５-b．配送先追加（別クラス）
配送先情報が構造を持つため別クラスに分ける
５-c．配送先追加（別クラスかつ会員に配送先を複数登録できる）
配送先を会員ごとに登録できる場合に会員に配送先をもたせ、注文時に
その中から配送先を１つ選択する。そして、配達希望日と配達時間帯は注文時に指定する。
６．注文の「商品数量」、「商品価格」、「商品名」、「商品説明」を追加
商品価格、商品名、商品説明は商品固有の属性であるため別クラスにする。
７．注文明細追加
商品数量は商品固有の情報ではなく、注文に関連した情報のため注文明細クラスの属性として配置する。そして注文明細は注文と商品を結ぶ
注文明細は注文に含まれる商品の種類ごとに作成されるクラス。
矢印（→）と黒いひし形（◆）が付いており、コンポジションを表現している。コンポジションは集約の１種で「全体と部分」を表す。
商品は商品マスタであり、値上げがあれば商品の価格は変わる。ただし、値上げをしても注文時の価格は変わらないため注文明細は明細価格を持つ必要がある。
８．決済情報追加
上記の図では注文に注文決済を持たせた。注文決済は注文時に会員が選択して入力する決済情報を抽象化したもの。決済情報の具象クラスとしてクレジットカード決済と銀行振込決済のどちらか１つを選択する。
用語集
概念モデリングでは難解な業界用語が採用しなければならないことはよくある。明確に定義しておかないと開発チームが理解できない。そのため用語集を作成する。その対象は概念モデルに登場する概念と属性である。
※一般的な用語や定義する必要はない。例：電話番号など
概念モデリングの注意点として下記の３点がある
○概念の名前を整理する
○概念の関連を整理する
○概念の関連の多重度を整理する
概念の名前を整理する上での注意点が２点ある。その改善例を記載する。
・同じ意味で２つの言葉があれば１つにする
「受注」と「注文」が同じであれば業務担当者と合意した後、統一する
・違う意味で１つの言葉があれば分割する
「注文」という言葉を会員が使用する場合と卸業者が使用する場合がある。
その場合は前者を「受注」、後者を「発注」とする。
※業務担当者と相談し、普段の業務で使用している言葉を選ぶ。使い慣れない言葉を選ぶと名前が定着せずに間違った使い方をされてしまう。
冗長な関連付けの禁止
会員が過去に購入した商品を一覧で表示する機能があると、会員と商品を関連付けたくなるが、これは冗長すぎる関連である。
既に会員と商品は注文と注文明細を経由して関連づけているので、さらに会員と商品を関連づけると、二重になる。注文の返品キャンセルが発生した場合、関連削除し忘れることに繋がる。
関連の多重度の整理
・１対１の多重度
「概念の属性が多すぎる」、「概念の意味が違う」場合に視認性を考えて１対１の多重度になることを承知の上で分ける。
・多対多の多重度
「本当にその関連が必要か」、「関連の間に新しい概念が存在しないか」をもう一度考える。
概念モデリングの終わり
下記の４項目を目安とする。
・ユースケース記述に登場する概念が全て表現されているか ※要件定義で概念モデルが作成されていない場合
・画面設計に登場する概念が基本的に表現されているか
・外部システムI／Fに登場する概念が基本的に表現されているか
・関係者により承認を得ているか
第3章外部設計の手法④概念モデリングを終了します。
次回は⑤画面設計について記載します。
この記事が気に入ったらサポートをしてみませんか？