シリーズ「UML等各種ダイアグラムのエラーチェック体系化」です。
現在「いろんなダイアグラムをＲＤＢにいれよう！」化計画、
をやっていて、前回、ＤＦＤを入れました。
今回は、そのＤＦＤのエラーチェック方法です
なお、ここで書いたとおり、いままでのまとめは
こちら
システム開発における「最小単位」とその連結法
http://www.geocities.jp/xmldtp/index_system.htm
■ＤＦＤのエラーチェック方法
そもそも、このシリーズの表題が、「UML等各種ダイアグラムのエラーチェック体系化」なのに、
エラーチェックについて何も書いていないので、今回はそれについて書きます。
エラーチェックには、
・２つ以上のダイアグラム間のエラーチェック
・あるダイアグラムの詳細・概要間、あるいは１枚のシート内のエラーチェック
と分けられると思います。
はじめの「２つ以上のダイアグラム間のエラーチェック」については、ある程度ダイアグラムのＤＢ化が進んでから説明しようと思います。後者の「あるダイアグラムの詳細・概要間」については、それぞれのダイアグラムを紹介した後にやろうと思ってます（今まで書いたＥＲ図、クラス図はチェック項目がないので、書かなかった）。
で、今回は、ＤＦＤのエラーチェック方法ですが、それは、ここ
平成１７年度
会計検査院法第３０条の３の規定に基づく報告書
「各府省等におけるコンピュータシステムに関する会計検査の結果について」
http://report.jbaudit.go.jp/org/h17/yousei5/2005-h17-8092-0.htm
にあるように、
・ＤＦＤ中に書かれたプロセスについて、それを詳細化したＤＦＤが記述されるが
・そのとき、概略を書いたＤＦＤのプロセスに対する入出力のデータソース、データストアは
・詳細化して書かれたＤＦＤのどれかのプロセス（複数あってもよい）の入出力のデータソース、データストアに
なっていないといけない
というおきてがあります。
■具体的には
前回の図
http://itpro.nikkeibp.co.jp/article/COLUMN/20080619/308620/zu3s.jpg
を例にとっていうと、たとえば「自動発注」には、在庫データ、受注データ、メーカーのデータストアまたはデータ発生・吸収があります。
ということは、もし「自動発注」の詳細ＤＦＤを考えたとして、そのときのプロセスを「発注量算定」「発注データ作成」「発注実行」とすると、それら３つのプロセスのどれかが、在庫データ、受注データ、メーカーに「必ず」アクセスするということです（もちろん、２つ以上アクセスしてもＯＫです）
そして、これ以外のデータ、たとえば「発注データ」というのを「発注データ作成」と「発注実行」でアクセスしていたとすると、このデータは、親プロセス「自動発注」以外の、他の親プロセス（内のプロセス）からアクセスされることはないということです。
（「発注量算定」は「発注データ」にアクセスするかもしれないが、他親プロセスの「注文入力」がアクセスすることはない。
■これをＲＤＢで表現するには
まず、プロセステーブルに親プロセスＩＤというのを持ちます。
プロセステーブル：プロセスＩＤ，プロセス名,親プロセスＩＤ
先ほどの例でいうと、
「発注量算定」「発注データ作成」「発注実行」の親プロセスが「自動発注」になります。
なので、データはこんな感じ
プロセスＩＤ，プロセス名,親プロセスＩＤ
：
3,自動発注,0
：
28,発注量算定,3
29,発注データ作成,3
30,発注実行,3
このとき、データフローテーブルが
10010,3,3003,メーカー
10011,6001,3,注残データ
10011,6002,3,在庫情報
とあったら、
XXXXX,○,3003,******
XXXXX,6001,○,******
XXXXX,6002,○,******
○は、3の自動発注の子である、28,29,30のいずれか
(XXXXX,*****は任意）
となる３種類のレコードが、データフローテーブルにかならず１件は存在する
（１種類１件、最低３種類３件）存在するということになります。
このエラーチェックが出来ます。
ただし、これ、若干の問題があります。
それについては、次回に書きます。
アクセス
トータル
ランキング
