見える化同士でも、連携にはXMLのような・・（をUMLを例に説明する）

　前に書いた、意味論の世界の見える化→形式論の世界の自動化にXMLがいいという話を書きましたけど、意味論の世界の見える化ツールの連携にも、やっぱXMLだよね！というお話を、UMLを例に書いてみます。

---

　結局UMLは、プログラム開発に必要な業務の情報の見える化なわけです。

　そして、業務（の情報）には、動的なものと静的なものがあるわけです
　静的な情報、つまり保持しておくべきデータについて、その関係は、

　出力に必要なデータ
　　↓　
　正規化
　　↓
（UMLではないけど）ER図→DB、ファイル定義
　　↓
　クラス図のクラス（＝エンティティ）および属性

となり、

　動的に必要なデータ
　　↓
　アクティビティ図
　　↓
　ユースケース図→画面イベント→画面定義
　　↓
　クラス図のメソッドとして、クラスに割り振る

ということになります。

---

ってことで、ER図のエンティティと属性は、クラス図に使える部分が多いわけです。
（っていうか、そこをベースに考える）

また、アクティビティ図のアクティビティのコンピューター化する部分が、
ユースケース図のユースケースとなり、
ユースケースから引かれるアクターは、たいていアクティビティ図の
　　・アクティビティが所属するスイムレーンか
　　・アクティビティから引かれる線の元や先があるスイムレーン
が多いわけです（必ずしもそうじゃないけど）

なので、アクティビティ図がユースケースに使えると、役立つわけです。

また、アクティビティないし、ユースケースをクラスのメソッドにしたい
ことも多いので、この点でも、流用できると役立つわけです。

---

　以上により、アクティビティ図、ユースケース図、クラス図のそれぞれが、
XML化してくると、それぞれが流用できて、(自動化のようにすべて使う
わけではないけど）、支援して、利用できるようになるので（利用も簡単に
なるので、出来る人が増える）、メリット大だとおもうわけです。

見える化→XML→形式化の自動化（ER図→XML→テーブル定義を例に）

　昨日の見える化から形式化における自動化の話のつづき。

　たとえば、要求仕様の出力内容から、データベースを作成する場合、

（１）出力内容から、正規化により、テーブル(エンティティ）と項目を抽出する
（２）(エンティティ）と項目をER図で見える化する

ここで、最終的に

・ER図の見える化した内容からテーブル定義(CREATE TABLE）を作成する

としたいわけです（もちろん、型とかNot NULL情報はないので、それは補うとします）
でも、ER図から、テーブル定義には落ちません。そこで、どうするか・・

---

ここは、XMLを使うのが素直だと思うんです。

（１）出力内容から、正規化により、テーブル(エンティティ）と項目を抽出する
（２）(エンティティ）と項目をER図で見える化する
（３）ER図を、XMLで書き出す
（４）そのXMLを読み込み、（XSLTやプログラムにより）
　　　テーブル定義(CREATE TABLE）を作成(変換）する

っていう風になると思うんです。ER図→XMLは、フリーソフトとして
DBDesigner（日本語サイトはここ、
ウィリアムのいたずらは使ったことないので、どんなXMLがかかれるか、
日本語が使えるかとかは、わかんない）とかあるらしい・・・
ってことで、出来ない話ではないわけです。

（っていうか、テーブルとリンクにわけて、テーブル定義は、テーブル名
　とかを指定するタグと、項目のタグ、あとリンクのほうは接続するテーブル
　とカーディナリティを定義すれば、XML化すぐにできますね　＾＾；）

で、XML化してしまえば、あとは、そこからCreate　Tableをつくるなり、なんなりって
いうのは、XMLを読み込んでテキスト書き出しするプログラムでしかない。。

---

　っていうことで、見える化したものを、いろんな形式化(形式言語：
今回はCreate Tableでしたけど、Javaによる入出力とか、いろいろな派生が
ありえます）して自動化するためには、交換フォーマットとしてXMLで
落とし込むっていうのが、一番現実的かな・・と思ったりもします。

INPUTタグでClassを利用することによって、エラーチェックが見える化／自動化できるかも？

　まえに、ここでJavaとJavaScriptにおける、「型の代わりのクラス」を使うことによって、テストが階層化できたり、自動化できるという話を書きましたよね。

　で、そうなってくると、HTMLのフォームにおいて、INPUTタグのところ、

＜INPUT　TYPE=TEXT　ID=su1 CLASS=suryo＞

のように、CLASS指定をして、そこで、「型の代わりのクラス」を書いておけば、
ボタンがクリックされたとき、そのフォームのINPUT文に対し、クラスで指定されたチェック（上記例だと、数量のチェック、suryo_validation）を行うようにするという感じでいいことになる。

　で、その数量は、整数に属しているのであれば、その数量のチェックの中で、整数のチェックを呼び出せばよい（階層化）。

---

　こうなってくると、チェック部分は、なにもHTMLの中にある必要はなく、HTMLの中では、チェック用のJavascriptを呼び出し、そのチェック用Javascriptの中で、それぞれのClassで指定された「型の代わりのクラス」のチェックを記述すればよい。
　そうなってくると、この「型の代わりのクラス」のチェックは再利用できるし、あるボタンがおされたとき、どの変数をつかい、その変数の型はなんだから、どんなチェックがされるはずかというのが、表形式みたいな感じ

ボタン：受注

項目　　　　クラス
受注年月日　hizuke
顧客名　　　kokyaku
受注商品１　shohin
受注数量１　int
受注単価１　TANKA
受注商品２　shohin
受注数量２　int
受注単価２　TANKA
：
：

なかんじで、見える化できる。
さらに、クラスのところ、たとえば、hizukeをクリックすると、

型：hizuke

要素チェック　全体　要素数 3　区切り/
文法チェック　年月日（要素）
範囲チェック　全体（要素）　2008/1/1
：
：

のように、チェック内容も見える化できるようにして、
実際のチェックのときには、プログラムをあえて書かなくても、
上記のチェックが自動的に動くようにすれば、
チェックの手間が省けると思う。

---

やっぱ、具体的な例を示しながらでないと、
わかりにくいですよね、。今度やっときます。