7.スキーマ定義(業務設計)

業務設計で使うここでの全体のスキーマを定義すると以下のようになります。 ただし、全部を前回のような記法で表現すると、それだけで煩雑になってしまうので 表形式でまとめました。
二項関係は"/2"、それ以上は"/N"で一緒には存在しえないセルに書いてあります。 少しパズル的な表現になっていますがお許しください。
行と列が逆転しているところは、"@"が付いていますので、行と列を交換して理解してください。

		M01	A01 M02	A02 M03	M04	M05	M06	M07	M08	M09	M10	A22 M11	M12	M13	M14	M15	M16	M17	M18
サブシステム	M01
機能	M02	A01 /2
アクティビティ	M03		A02 /3
ロール	M04			A03 /4@
画面	M05			A04 /4
エンティティ	M06			A05 /4							A10 /2
帳票	M07			A06 /4							A11 /2
ファイル	M08			A07 /4							A12 /2
外部データ源	M09			A08 /4							A13 /2
バッチ	M10											A09 /2
イベント	M11												A22 /2
状態	M12											A23 /3
アクション	M13											A24 /3
メッセージ	M14					A21 /2
ルール	M15
権限	M16				A20 /2
項目	M17					A14 /2	A15 /2	A16 /2	A17 /2	A18 /2						A25 /2
部品ファイル	M18																	A19 /2

なにやら数独みたいな表に結果なりましたが、非常にシンプルに１８個もの設計パラメータの関係を 把握でき且つコントロールできてしました。 オントロジー的な思考アプローチで可能になってしまうことが示せたと思いますがいかがでしょうか。
これは、一つのケースであり、それぞれシステム開発の現場で変更することにより、より設計が正確に なることでしょう。ただし、あまり理想的に関連を規定すると設計が細かすぎたり、矛盾等が 発生する場合が出てきます。
むしろ検証用のツールを作成して使い、その情報を二次的に利用するか、設計書修正で役に立てる ことをお勧めします。

「これはスキーマなのでまだわかりやすいのでは？」と疑問に思うかもしれません。次回は 簡単な業務サンプルを書きます。