データ、UI、業務手順の「3要素」をとらえる：分析設計技法「三要素分析法」集中講座（2）（2/3 ページ）

[渡辺 幸三，＠IT]

データモデルにはインスタンスを併記できる

　続いて、「CONCEPTWARE／財務管理」から実際のデータモデルを紹介しましょう。図3は「立替精算データ管理サブシステム」のデータモデルで、三要素分析法向けの無償のモデリングツールXEAD（ジード）で表示した図です。会社勤めをしている読者にとって交通費精算はなじみのある作業なので理解しやすいでしょう。

図3　「立替精算データ管理サブシステム」のデータモデル（XEAD）（クリック >> 図版拡大）

　記法を詳しく説明するよりは、ほかの記法で描かれた同一のモデルを示した方が手っ取り早いでしょう。ほぼ同一の内容のクラス図を示します（図4）。

図4　「立替精算データ管理サブシステム」のクラス図（クリック >> 図版拡大）

　クラス図やIDEF1Xのようなメジャーな記法があるのに、あえてこの記法やモデリングツールをお勧めするのはなぜでしょう。それは、前回でも説明したように「ユーザーにも分かりやすい」からです。図3のように、三要素分析法ではインスタンス（テーブルに登録される実際値の例）をデータモデルに併記できるようになっています。すると、ユーザーには表計算ソフトに並べた帳簿データのように見えるため、新システムでの帳簿組織として理解しやすいのです。また、多重度に基づいてテーブルが左右にずらして描いてあるために設計者が全体を直観しやすいという利点もあります。

サブシステムとデータモデルの深い関係

　さらに重要な効果は、XEADにおいてデータモデルが「サブシステム」ごとに示される点です。いくらデータモデルが便利な図面だといっても、おびただしい数のテーブルが載っている集積回路のようなモデルをいきなり示されても困ります（図5）。テーブル関連の線を追いかけるだけでゲンナリしてしまうでしょう。いくつかのセクションに分けて示してほしいところです。

図5　読み解く気の起こらないデータモデル

　後述するように、実際のデータモデリングは「サブジェクトエリア」ごとに手書きされますが、それをモデリングツールで示す際には「サブシステム」別である方が便利です。そうすることで、各テーブルのサブシステムごとの集約的な「CRUD（Create,Read,Update,Delete）」を示せるからです。

　そもそもサブシステムとは、データベースシステムとしてのモジュールを示す概念です。1つのサブシステムにはいくつかのテーブルといくつかの機能（プログラム）が含まれます（図6）。必ずしもサブシステムに相当する実装要素が必要というわけではありませんが、基本設計においては設計情報の章立て節立てとしてサブシステムの考え方は必須です。複雑膨大な設計情報を理解しやすくなるし、モジュール間の結合度を弱め、凝集度を高めるためにいろいろと工夫できるからです。

図6　テーブルとプログラムをまとめたものがサブシステム

　すなわち、サブシステム間のテーブルの引き回しに注意を払うことで、工学的な妥当性を備えたサブシステムを切り出せます。その試行錯誤の過程で、サブシステムごとにデータモデルが示され、その上でテーブルごとの所属サブシステムや当該サブシステムでのCRUD状況が示されるなら、サブシステム構成の妥当性はずっと評価しやすいものになります。

　例えば図3のモデルを見れば、「立替精算データ管理サブシステム」に含まれているはずのさまざまな機能が寄ってたかって、「共通リソース管理サブシステム」に所属するテーブル「従業員」を参照（R）しかしていないことが分かります。これはサブシステムとして妥当な切り出し方といえます。なぜなら、別のサブシステムに含まれるテーブルに対する更新系操作（CUD）を極力排除するのが、サブシステム分割の基本的な指針となるからです。

機能モデルの主役「ユーザーインターフェイス」

　2つ目の要素が「機能モデル」です。分かりにくい表現ですが、要するに「ユーザーインターフェイス（UI）」のことと思ってもらって構いません（実際にはそれだけでなく、機能間の呼び出し関係や入出力テーブルに関する情報なども含めた定義のまとまりを、三要素分析法では機能モデルと呼んでいる）。

　分析・設計手法の中には、ユーザーインターフェイスのデザインを重要視していないものがあります。そのような手法は、業務システム開発の上流工程向けの手法としては使いにくいものです。なぜならユーザーインターフェイスは、ユーザーにとって理解しやすい（数少ない）設計要素だからです。こういう要素を活用しないのはもったいないといえます。描かれたデータモデルが分かりにくいとしても、そのモデルがどのようなユーザーインターフェイスをもたらすものかを描けば、ユーザーは何とかシステムのありようを理解してくれるものです。

　ユーザーインターフェイスの例を「立替精算データ管理サブシステム」から見てみましょう（図7）。パネルデザインを登録するためのXEADの機能は、背景や文字の色を指定したり、下線を引けるくらいのエディタでしかありませんが、基本設計情報として十分なレベルのイメージを描けます。あまりに表現力があるエディタで描くと、かえってユーザーは背景やボタンの色だのバナーのデザインだの、機能上関係のない要素に目を奪われてしまいます。

図7　「立替精算データ管理サブシステム」でのパネルデザイン例（クリック >> 図版拡大）

　少し話はそれますが、表計算ソフトなどでなく専用ツールを用いて基本設計情報を管理することの利点を紹介しましょう。XEADに機能モデルを登録すると、次の図のようにログインパネルから始まってどのようにパネルが展開されるかがツリービューで確認できるようになります。これを眺めることで、登録の漏れや間違いに気付けます。例えば「どこからも呼び出されない機能」がツリービューのルートノードとして並ぶことになるのですが、それがログインパネルやメニューでないとしたら何かの登録ミスである可能性が高いと見なせます。

図8　機能階層ビュー（クリック >> 図版拡大）

　2つ目の利点は「クロスレファレンス」です。上述したように、機能モデルでは「この機能単位で入出力されるテーブル」がCRUD指定で登録されます。すると、各テーブルの定義を見た場合に「このテーブルを入出力する機能」がCRUDとともに自動的に一覧されます（図9）。設計情報をブラッシュアップしていく過程でこの種の情報は大変有用で、XEADではこのほかにもさまざまなクロスレファレンスが縦横に示されるようになっています。これは設計情報がツール内部でリポジトリ管理されているからこそできる芸当で、表計算ソフトや描画ソフトではちょっとまねできないものです。

図9　クロスレファレンス（クリック >> 図版拡大）