« 業務マニュアルのデータモデル | トップページ | Ajaxで業務マニュアルサーバ »

2006.05.06

機能モデルのデータモデル

データモデルのデータモデル」と「業務モデルのデータモデル」を見たので、今度は「機能モデルのデータモデル」を見よう。「機能」は「業務」と「データ」を結ぶ要素なので、そのデータモデルを見ても業務モデルとデータモデルとの双方の関連を持つ点が際立っている。

◆機能とテーブルはサブシステムに所属する

 まず、それぞれの機能定義はいずれかの「サブシステム」に所属するものとして定義される。「サブシステム」とは複数の機能とテーブルとが集まったソフトウエア群のことで、通常、ひとつのシステムは数個から20個程度のサブシステムで構成される。また、ひとつのサブシステムも数個から数十個の機能で構成される。

 サブシステムは必ずしも実装対象とみなされるものではないが、保守フェーズにおいても無視できない概念だ。これまで何度か説明してきたように、サブシステムはデータとメソッドを持ついわゆる「オブジェクト」によく似ていて、サブシステム構成をうまく切り出すことでシステムの保守性が高まるからだ。

 データモデルは次のとおり。インスタンスで示した例でサブシステムや機能の実際の粒度感を想像してもらえると思う。

Imagex1

◆機能と各種入出力

 前回説明したように、それぞれの機能はひとつか複数の「入出力フォーム」をともない、それぞれの「入出力フォーム」は各業務において利用される。機能と業務との関連に注目してほしい。

Imagex2

 「入出力フォーム」だけでなく、機能は「テーブル入出力」を伴う。今度は機能とテーブルとの関連に注目。

Imagex3

 このように、テーブルと業務とは直接には関連しないが、機能はテーブルと業務との関連を持つ。テーブルと業務は機能によって結び付けられる。機能はテーブルと業務を結びつける仲人である。言い換えれば、機能モデルはデータモデルと業務モデルの2支点で支えられているともいえるし、機能モデルはデータモデルと業務モデルとの「板ばさみ」になってうめいているともいえる。ことほどさように、機能のあり方を考える際に業務やデータのあり方を無視するわけにはいかないのである。

◆機能間の「呼び出し関係」

 機能は機能との関連を持つ。ある機能Aから別の機能Bが呼び出されるとすれば、機能Aは機能Bを「呼び出し機能」として持つことになる。モデルで示せば次のようになる。

Imagex4

 「ある機能からどんな機能が呼び出されるか」を登録するということは、呼び出される機能を起点にして「この機能を呼び出す機能はどれか」がわかるということでもある。機能定義が修正される場合に、抜け目なく「その機能を利用している機能」の一覧を確認して影響を確認できる。

 また、システム全体に含まれる各機能の呼び出し機能に関する情報を集約すれば、システムでの「機能展開ツリー(メニュー構成)」を示せる。すなわち、全体を調べて「どの機能からも呼び出されない機能」を取り出せば、それが「ルート」の機能とみなせる。システムにおいてルート機能となり得るものの代表は各種イベントのリスナー機能である。特定の時刻や月次でのタイミングをつかまえて自動的にバッチ処理を起動する処理や、ユーザのログインをモニターする処理などが該当する。

 機能展開ツリーの実際例を「CONCEPTWARE/財務管理」から紹介する。「ルート」としてリスナー系の機能が並んでいる点に注目してほしい。

Imagex5

 もしリスナー機能でもないのに機能展開ツリーのルートに現れているとしたら、呼び出し関係の登録が抜けているか指定が間違っているかのどちらかだ。そんな凡ミスを機械的に発見できるようになるのも、設計情報を構造化して扱うことで得られる果実のひとつである。

|

« 業務マニュアルのデータモデル | トップページ | Ajaxで業務マニュアルサーバ »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 機能モデルのデータモデル:

« 業務マニュアルのデータモデル | トップページ | Ajaxで業務マニュアルサーバ »