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