システム開発の大黒柱!!「理想のデータ」を掴むには#1

システム開発の大黒柱!!「理想のデータ」を掴むには#1

「理想のデータ」のモデルを作ることがいかに大切かそしてその作り方を示した記事になっています。集めたデータが何を意味しているのか明確にするために、まずは種々の理想のデータモデルを作り、自分の集めたデータがどのデータモデルに属するのか考えていきましょう。2部の構成になっているので続きの記事もどうぞご一緒にお読みください。

まえがき

「理想のデータモデル」作成の手順システム開発プロジェクトでは、プロセスや機能の話が比較的中心になりがちです。しかし実のところ、特に業務においては、ユーザーの操作対象であるUIの目的は「適切なデータの出し入れ」にあります。そしてシステムの価値は、極めて多くの場合、データが佐右します。これは紛れもない事実です。早期にデータに必要な要件(以降、データ要件)を可能な限り固めておけば、開発対象のシステムは、ライフサイクル全般にわたり高い品質を安定して保てるようになります。逆に、いろいろな要件を定義する段階でデータの要件が暖味だと、システムは一定以上の品質を担保するのが極めて困難になります。 データ要件の大枠が固まらないということは、開発対象のシステムの方向性が定まっていないことを意味します。 これはとても危険なことです。

Step 1 サブジェクトエリアに分割

理想のデータモデルとしての概念データモデルが存在する場合、 システム内の関連図などを見やすくするために、必要に応じてサブジェクトエリアの分割を行います。その際、エリアひとつひとつについて、サブジェクトエリアの一覧表と、各サブジェクトエリアに所属する現時点で把握可能なエンティティの一覧表を作成しておくとよいでしょう。サブジェクトエリアは、「業務視点」で分割することを推奨します。データモデルは開発者とユーザーとのコミュニケーションツールの一つであることを忘れてはいけません。開発者だけでなく、ユーザーに理解しやすい表現を心がける必要があります。静的な表現であるデータモデルは、ユーザーが理解可能な単位にまとめていきます。

概念データモデルが存在しない場合は、ある程度概念データモデルが形をなしたところで、改めてサブジェクトエリアの切り分けを実施します。実際には、業務上の結びつきが強いと思われるエンティティ同士をグループ化し、まとめあげていくイメージです。新規開発の場合には、このサブジェクトエリアの括りを意識して作成します。システムの規模により異なりますが、たいていは複数が管理対象になります。修正の場合には、サブジェクトエリアを追加すべきか、既存のサブジェクトエリアを修正すべきか熟考する必要があります。サブジェクトエリアを明確にすることの重要度は、エンタープライズ系の方がコンシューマー向けよりも高いといえるでしょう。なお、エンタープライズ系、コンシューマー向けを問わず、開発対象範囲が明確な場合には、サブジェクトエリアを意識する必要はありません。

Step 2 リソース系エンティティの抽出と定義

リソース系エンティティとは、一般的には、ヒト·モノ·金など企業組織の活動基盤を表すデータのことです。「台帳データ」とも称されます。まずトップダウンモデリング(大枠→細部へと決めるやり方)を行い、抽出していきます。要件定義書、ビジネスルール等を基に抽出します。 リソース系エンティティの定義は「ビジネス要件」からブレイクダウン、した「システム要件」を踏まえたものであるべきです。例えば「顧客」とは?「商品」とは?を明確にしていきます。概念データモデルが存在する場合は、Aslsと制約を踏まえて(要件を踏まえて)、元の概念データモデルに修正を加えます。存在しない場合は、要件を基に、一からリソース系エンティティを抽出します。次にそれらの概要を定義します。 すべてのエンティティには、定義すべき存在意義があります。現時点でわかる範囲で構いませんので、説明· 制約 ルール·範囲になりうるものは余さず洗い出しておきましょう。 「顧客」と「商品」の関係、 複数 「商品」を「受注」の際に処理可能とする、といった当たり前のものから、「顧客」(グループ)ごとの個別契約の有無、商品の店舗別販売価格等を整理していきます。

Step 3 各エンティティ間の関連を分析する

リソース系エンティティ同士の関連を分析し、リレーションシップの登録と、静的なビジネスルールの洗い出しを行います。

Step 4 イベント系エンティティの抽出と定義

リソース系エンティティが活動基盤を表すものであれば、イベント系エンティティは予測できる特殊なできごと(エラーなど)です、もしできるのであればそれぞれを予測し、抽出しましょう。

Step 5 リレーションシップの線を引く

抽出したエンティティ同士の間にリレーションシップの線を引き、併せて定義を行います。すべてのリレーションシップの線には、それが引かれた理由、引かれた方向、矢印の意味があります。それぞれを明確にして定義していきます。リレーションシップの意味の定義文は、「~する」、「~される」という動詞句で統一することを基本とします。

→の方向に沿って「親(矢印の起点のエンティティ)は子(矢印の終点のエンティティ)を~する」(行為)もしくは、「~になりうる」(存在)等、 という書き方で統一すると解りやすくなります。親エンティティから子エンティティへ「(主語)+ (目的語)+(述語)」の形で整理されていれば問題ありません。エンティティを表す箱同士を線で結んで定義していくことにより、概念データモデルの大枠が固まっていきます。元になる理想のデータモデルとしての概念データモデルが存在していたか否かにかかわらず、この時点で、新理想のモデルとしての概念データモデルを確定させます。

 

テックカテゴリの最新記事