シリーズ「UML等各種ダイアグラムのエラーチェック体系化」です。
現在「いろんなダイアグラムをＲＤＢにいれよう！」化計画、
をやっていて、前回、ＤＦＤのエラーチェックをやりました。
今回は、そのＤＦＤのエラーチェックの問題点です。
なお、ここで書いたとおり、いままでのまとめは
こちら
システム開発における「最小単位」とその連結法
http://www.geocities.jp/xmldtp/index_system.htm
（最新のものになおしました）
■前回のＤＦＤエラーチェック方法
前回のＤＦＤエラーチェック方法は、
親と子のＤＦＤがあったとき、
親プロセスと結びついているデータ吸収・発生、データストアは、
子プロセス中のどれかのプロセスとも、結びついていないといけない
という性質を利用してチェックしました。
で、今回は、このとき、問題があると書いたことについてです。
■同じものは、同じ名前になっているか？
ここで、問題なのは、
すべての部署で、同じ名前＝同じモノか？
という問題が起こります。
つまり、ある部署では、まったく名称なのに、同じものをさしていたり、
逆に、同じ名称なのに、違うものということはないか？
ということです。
まず先ほどのチェックをする際には、同じものが、同じＩＤになっていないと、いけません
（そうしないと、ＩＤから、同じものをさしているかどうか判断できない）
なので、同じものをあつめてくる、つまり名寄せするわけですが、
この際、同じ名前のものは、同じものと考えます。
だから、すべての部署で、同じ名前＝同じモノになってくれていないと困ります。
■モノにおける親子関係
しかし、おおまかなＤＦＤと詳細ＤＦＤでは、
データストアなどの名称が、
おおまかなもの→詳細なもの
へ変わっていくのが普通です。
そうすると、「おおまかなもの」を親、詳細のものを子として、親子関係をもたせるということになります。
結果として
プロセステーブル：プロセスＩＤ，プロセス名、親プロセスＩＤ
データ発生・吸収テーブル：発生吸収ＩＤ,元名、親発生吸収ＩＤ
データストアテーブル：データストアＩＤ，データストア名、親データストアＩＤ
データフロー：データフローＩＤ、元データＩＤ，先データＩＤ、フロー情報内容
となります。親のＩＤが０のものは、これがトップということです。
そして、検索は、
親と子のＤＦＤがあったとき、
親プロセスと結びついているデータ吸収・発生、データストア
自身あるいはその子孫が、
子プロセス中のどれかのプロセスと、結びついていないといけない
ということになります
■ただし・・・
データ吸収・発生をものすごく大雑把にとってしまい、
子、孫をどこまでも調べていって、結びつきを確認してしまうと、
実は違うものをさしていたのに、親が一緒になってしまいＯＫってこともありえます。
たとえば、親を従業員として取ってしまうと、
社員用のプロセスをアルバイトと間違えて書いても、どっちも従業員なので、エラーが取れない
といったケースです。
そこで、
親プロセスと結びついているデータ吸収・発生、データストア
自身あるいはその子が、
子プロセス中のどれかのプロセスと、結びついていないといけない
のように、プロセスの親子１段階に対してデータのほうも、親子１段階しか対象にしない
といった方法が考えられます。
なお、このように、ＤＦＤのチェックをするためには、
名寄せや親子関係の作業がいることになりますが、
むしろ、この作業のほうが、間違いを直すには有効かもしれません・・・
ＤＦＤは、とりあえずここまで。
次は違う図を扱います。
アクセス
トータル
ランキング
