アプリケーションルールの定義
はじめに
DFDを作る際の注意点は前述した「データフローダイアグラムの書き方」の通りです．これら注意点でDFDは作成可能ですが，アプリケーションルールの定義にはまだ不充分です．ここでは，アプリケーションルールをDFDで表現するために必要な規則を説明し，具体的にDFDでアプリケーションルールを定義します．
念のため，アプリケーションルールの定義を再掲します．
- アプリケーションルール
- エンティティのデータや他のプロセスの出力結果を使い，業務上必要な情報を導き出す方法．
そして，アプリケーションルールはデータモデルに「依存」します．これに対し，アプリケーションルールはユーザインターフェースからは「独立」します．
DFDのシンボルと組織体の構成要素
アプリケーションルールを定義するために，DFDで使用するシンボルと対象となった組織体の構成要素を以下のように関連付けます．
- データの発生源・行き先
- 組織体の中の部門・人間や他システム等，システム開発対象外となっているもの．
- データの保管先・保管元
- エンティティ．すなわち，組織体が認識できるもの，および概念．「あるとプログラムで便利に使える」という理由でER図にないエンティティを勝手に増やしてはならない．
- プロセス
- 組織体におけるエンティティを使用した活動，およびエンティティを使用して発生する事象．
- データの流れ
- シンボル間を行き来するエンティティの属性やデータの発生源・プロセスの出力．
データの発生源・行き先について補足します．システム開発対象外なので，これらを軽視する場合がありますが，それは間違いです．これらは，開発したコンピュータシステムが円滑に動作するための外部環境です．齟齬があってはまともに動くものはできません．データの発生源からやってくるデータ，データの行き先に送るデータに間違いがないことを確かめるのはもちろんですが，更に，データの発生源は本当にそのデータを送ることが可能なのか，データの行き先は送ったデータで何をやりたいのか，他システムにメンテナンスが発生するのではないか，部門や人間に新しい役割を必要としているのではないのか，もう一歩踏み込んで考え・対処することを忘れてはなりません．
具体例
「エンティティとリレーションシップ」で作成した業務概要とER図，および「エンティティのライフサイクル」で作成したエンティティ・プロセス関連図を元に，アプリケーションルールを定義します．業務概要とER図，エンティティ・プロセス関連図は以下の通りです．
ソフトウェアの管理システムです．保有しているソフトウェアや製造元・販売元・アップグレードの履歴を管理します．各ソフトウェアには管理者が存在し，アップグレードの手続きはこの管理者が行います．ソフトウェアの機器への導入は，管理者にライセンスの有無を確認した上で，各担当者が行います．使用しなくなったソフトウェアは各担当者が導入機器から削除し，管理者に連絡します．
図1.ER図 
表1.エンティティ・プロセス関連図 取引先 ソフトウェア ライセンス 社員 管理者 導入機器 アップブレード ライセンスの購入 CU CU C R C ライセンスの破棄 D D D U R D アップグレード R R C 機器への導入 R R C 機器からの削除 D 人事システム（他システム） CD
収拾がつかなくなったらプロセスをまとめる
DFDを書き始めると，データの流れを表わす矢印があちこちで交差し，収拾がつかなくなることがあります．今回も，ER図のエンティティ，エンティティ・プロセス関連図のプロセスを使用してDFDを書き始めたところ，収拾がつかなくなったりました．その場合は，プロセスをある程度まとめデータの流れの数を減らします．
|
５プロセスを以下のように２プロセスにまとめました．
- ライセンスの購入・破棄・アップグレード
- 機器への導入・機器からの削除
データの流れを理解しやすく整理できるのなら，プロセスをまとめる必要はありません．また，まとめた状態から書き始めなくてはならないわけでもありません．書きやすいところからDFDを書き始め，収拾がつかなくなったらプロセスをまとめてみる，プロセスをまとめた結果あまりに簡単になりすぎたら分けてみる，試行錯誤でかまいません．
まとめたプロセスで以下のDFDを作成しました．
|
データの発生源・行き先とデータの流れの検討
DFDが書けたら，まずデータの発生源・行き先とそれらから伸びる・それらに入るデータに注目します．これらの過不足・提供の可否を検討します．
このDFDの場合，検討対象となるのは以下の通りです．
- 人事システムが提供する入社・退社社員．
- 管理者が入力する購入・破棄・アップグレードライセンス．
- 管理者が入力する機器導入・削除用ライセンス．
まず，入社・退社社員については，すでに人事システムで把握済みであり，その提供を受けることにはなんの問題もありません．
管理者が入力する購入・廃棄・アップグレードライセンスについてはどうでしょう．購入したライセンスについてはパッケージなりライセンス証なりを見れば入力可能です．廃棄するライセンスはどうでしょう．管理者は不要なライセンスをどうやって知れば良いのでしょう．ライセンスを破棄するためには，保有しているライセンスと機器への導入状況を管理者が知る必要があります．しかし，それを提供するデータの流れはこのDFDには存在しません．アップグレードについても，破棄と同様保有しているライセンスと機器への導入状況を管理者が知る必要があります．そのためのデータの流れも，このDFDには存在しません．
管理者が入力する機器導入・削除用ライセンスはどうでしょう．導入・削除可能なライセンスを管理者はどうやって知れば良いのでしょう．やはり，保有しているライセンスと機器への導入状況を管理者が知る必要があります．そのためのデータの流れはこのDFDには存在しません．
保有しているライセンスと機器への導入状況を管理者に知らせるデータの流れをDFDに追加します．
|
この段階で決めなくてはならないのは，ここまでで十分です．保有しているライセンスと機器への導入状況を管理者に知らせるための「画面や帳票のフォーマット」の検討は不要です．禁止するつもりはありませんし，やりたければやっても構いませんが，ここで決めたフォーマットは後々変ることを肝に銘じておきましょう．
プロセスの分割
データの発生源・行き先とデータの流れの検討が終了したら，まとめたプロセスを分割します．すなわち，「購入・破棄・アップグレード」を「購入」・「破棄」・「アップグレード」に，「導入・削除」を「導入」・「削除」に分割します．プロセスの分割は対象となったプロセスが「単一の機能を有する」まで続けます．
プロセス「購入・破棄・アップグレード」を分割します．
|
この中のプロセス「購入」は「購入したライセンスの登録」と「購入したライセンスの管理者の登録」の二つの機能を有しています．プロセス「購入」を二つに分けます．同様にプロセス「破棄」も「ライセンスの破棄」と「管理者の抹消」の二つの機能を有しています．これも二つに分けます．
|
データの発生源・行き先「管理者」についてもう少し検討します．破棄・アップグレードの際の管理者は既に決まっていますが，購入したライセンスの管理者は「いつ・誰が・どうやって」決めるのでしょう．「システム開発の対象外」として切捨るのは簡単ですが，この対象外の要素が，システム内部に影響を与えるかもしれません．念のため確認しておきましょう．こう言うことにしておきます．
ライセンス購入時の手順は以下の通りです．
- 新規ライセンスが必要となった場合，直属の上司経由で調達部に依頼します．
- その際，調達部とのやり取り，および購入ライセンスの管理を行う管理者を上司は任命します．
- ライセンスが手配できたら，調達部は以来を受けた上司および上司が任命した管理者にその旨連絡し，管理者に現物を手渡します．
完全にシステム外部の活動ですが，忘れないように，要約をデータの発生源・行き先「管理者」の隣にメモとして残しておきます．検討していないでのではなく，検討した結果システム開発対象外としたわけです．これで「管理者任命用の機能が必要」と言う話が後になって出たときには，仕様追加として対応できます．
|
もう一つのプロセス「導入・削除」も同様にプロセスを分けます．
 |
まとめ
- データの発生源・行き先を組織体の中の部門・人間や他システム等，システム開発対象外となっているもの，データの保管先・保管元をエンティティとする．これらの間の流れるデータをデータの流れ，必要なデータの加工をプロセスとして表現する．
- 矢印が交錯して収集がつかなくなったら，プロセスをまとめる．
- データの発生源・行き先へのデータの流れを，システム対象外として軽視してはならない．
- DFDが書けたら，プロセスを「単一の機能を有する」まで分割する．
参考文献
Audrey M. Weaver "USING THE STRUCTUAED TECHNIQUES A Case Study" Prentice-Hall, Inc. 1987
（神間清展訳 "構造化技法を使いこなす" 総研出版 1989）
Arthur Young Information Technology Group "The Arthur Young practical guide to information engineering" Arthur Young & Company 1987
（高梨智弘，竹本則彦訳 "管理職のためのインフォメーションエンジニアリング" 日経BP社）
岡田英明 "システム部門再生講座" 戦略コンピュータ 1994年10月号 Vol.33 No.10 p.50- 日刊工業新聞社
Tom DeMarco "Structured Analysis and System Specification" 1979
（高梨智弘，黒田純一郎監訳 "構造化分析とシステム仕様" 日経BP出版センター）