ひさびさに、シリーズ「UML等各種ダイアグラムのエラーチェック体系化」です。
現在「いろんなダイアグラムをRDBにいれよう!」化計画、
をやっていて、そのため、まずは、ダイアグラムの構成要素を、ノード、リレーション(エッジ)、属性、属性値に分けようとしています。
前回までで、その構成要素の分類は終わったので、ここでそのまとめをしたいと思います。
なお、ここで書いたとおり、いままでのまとめは
こちら
システム開発における「最小単位」とその連結法
http://www.geocities.jp/xmldtp/index_system.htm
■構成要素のまとめ
RDBにいれるため、ダイアグラムを
・ノード
・リレーション(エッジ)
・属性
・属性値
の4つにわけます。
まず、単独に存在しても意味をもつものを、ノードとしました。
のこりは、単独に存在できないものですが、このとき
2つ以上のノードを結びつけて、存在しているものをリレーション(エッジ)
1つしか結びついていないものを、属性値
としました。
ただし、属性値は、ノードに対してだけでなく、リレーションに結びついている(関連している)ものもあります。
また、結びついているというのは、物理的に線でつながっている場合もありますが、単に上に乗っている(書いてある)というものでも、関連していれば、結びついていると考えます。
別の紙に書いてある場合でも、関連していれば、結びついていると考えます。
そして、属性値を意味的にまとめて、属性とします。
なお、分類上、
単独に存在できないもので、1つのノードとも結びついていないもの
というのがありえます。
枠の線などがこれにあたります。何も関連していないので、まあ、これはRDBにいれなくていいでしょう(^^;)
■このあとは
これで、構成要素がきまったので、その構成要素をRDBにいれます。
そして、ダイアグラム間の関係を示していきます。
あるダイアグラムの構成要素から、他のダイアグラムの構成要素を
・select文を使って取り出せる(元の構成要素のほうが情報大)
・select文を使って結び付けられる(関連性がある)
・まったく結び付けられない(関連ない)
にわけます。
さらに、プログラムを記述するうえで必要な情報というのがあります。
これと、上記ダイアグラムを関連付けていき、
・どのダイアグラムは、プログラム記述に必要な情報を持っていて
・どのダイアグラムは、プログラム記述に必要な情報を持っていないか
をチェックしていきます。
結果として、
・UMLやDFDは業務流れ図の部分的な情報しか持っていない。
・業務流れ図とその関連性がある図から、プログラムは記述できる
ってことは
・UMLやDFDは業務流れ図から、プログラムを記述するには、
必要な情報が欠けている。
ということを示していきます。
ということで、こんかいはおしまい。
次回は、RDBにいれる方法について