|
システムが管理すべきデータ構造を表す「論理データ・モデル」を作成するのも、外部設計の重要な工程である。ここでER（エンティティ・リレーションシップ）図やCRUD（Create＝作成、Read＝参照、Update＝更新、Delete＝削除）図などを作成する。
データモデル編は、これらの図を作成、レビューする際のコツをまとめている。特にレビューの割合が大きいのが他の2編と異なる特徴だ（表3）。
というのも、ER図やCRUD図はユーザーにとって難解な場合が多く、ユーザーとベンダーの間で合意を取るためには設計書の直接的なレビューだけでは不十分だからだ。データ・モデルはシステムの要であり、双方で合意しておかないと開発時だけでなく、稼働後にも悪影響を及ぼす可能性が高い。
レビューの基本は、段階的に複数回実施するというものだ。これはデータモデル編に限らず、3編すべてでコツとして挙げているが、とりわけデータ・モデルを作成する際に重要になる。
業務で利用する情報と、システムで利用するデータ・モデルとの関係は、ユーザーにはなかなかつかみにくい。複数回のレビューを通じて、ユーザーの理解度を確認しつつ、データ・モデルに関するより詳細な内容を確認していくという形をとると、ユーザーが理解しやすくなる。
業務を意識してカスタマイズ
ER図、CRUD図に関するコツも紹介しておこう。データベース設計の際に利用するER図では、データ項目を表すエンティティをグループ化しておく、というのがコツの例だ。
データ・モデルに関する合意形成の第一歩は、エンティティの見極めである。ユーザーと外部設計担当者の間で業務の流れや内容を考慮しつつ、エンティティをどう決めるべきかを意識合わせしておく。
そのとき、外部設計の担当者が図6上のようなエンティティ一覧を示すことがある。データベース技術者が詳細設計へのつながりを意識して作成すると、こうしたエンティティの羅列になりがちだ。これでは、ユーザーは各エンティティが何を示しているのか理解できない。
図6下のように関係するエンティティをグループ化しておけば、ユーザーはそれぞれの関係を理解でき、外部設計担当者との合意を取りやすくなる。
データの作成、参照、更新、削除のタイミングを図示したCRUD図については、CRUD図を外部設計時点で作成する、ユーザーが確認すべきポイントに絞って分かりやすく分類する、などのコツがある。
CRUD図は、詳細設計書の作成後に機能やエンティティに漏れがないかを分析するために利用することが多い。このCRUD図を外部設計時に使っても効果がある。業務とエンティティの対応関係に漏れがないかを確認するのに役立つからだ。
ただ、CRUD図そのものをユーザーが理解するのは難しい（図7上）。特有の記法を使っている上に、ベンダーは網羅性を持たせて記述することが多いからだ。そこで外部設計でCRUD図を生かすためには、図7下のように分類を増やす、分かりにくい表現を避けるといった工夫を凝らす必要がある。これでユーザーが理解しやすいCRUD図を作成できる。
発注者ビュー検討会は本ガイドラインを公開後、08年3月に解散した。4月からは情報処理推進機構（IPA）のソフトウェア・エンジニアリング・センター（SEC）に活動の場を移した。検討会に参加した9社は新たな参加企業を募り、SECでガイドラインの改善と普及展開を進めていく。並行して、9社は各社の開発標準にガイドラインを組み込んで利用推進に努めている。
