12月26日(土)のつぶやき

10:35 from web
Excelで設計書を書くことを批難している人たちは、ひょっとしてExcelを清書ツールや表計算ソフトとして考えているのではないだろうか？そーすると、自動生成やUMLとの関係が見えてこない気がするのは、気のせい？
10:38 from web
Excelのシートをオブジェクトと考えてください。Excelシートのひな型がクラスに相当します。シートの中で、固定領域がクラスの属性項目を表します。たとえば、「氏名」と書かれていて、そこに、自分の名前を入れるようになってたら、氏名はクラスの属性項目です。
10:41 from web
シートの中に、表の部分があります。見出しがついてて、レコードがある。この場合、この部分がひとかたまりのクラスです。見出しが表のクラスの属性名、各レコードが表のクラスのオブジェクトになります。つまり、シートクラスの中に、表クラスが入ってるわけです。
10:42 from web
メソッドはマクロとかです。で、ブック（Excelファイル）は、それらシートのクラスをまとめたクラス、ないしはパッケージとなります。このようにみると、Excelは、オブジェクト（＆クラス）を可視化したものってことになりますね！
10:44 from web
UMLのそれぞれの図も、クラスにすることができます。なので、ExcelシートとUMLの図は、それぞれのクラスに対するマッピングというかんじで処理できるわけです。
10:45 from web
Excelからソース自動生成といった場合は、Excelが表現する設計書のクラスからソースコードへのマッピングということになります。
10:48 from web
そんなら、設計書をXMLにして、XMLからプログラムをマッピングしたほうがいいじゃん！っていう意見があると思うけど、これは２つの理由からExcel仕様書のほうが好まれると思います。
10:50 from web
１つは作りやすさ。XMLからプログラム(テキスト）へのXSLを書くのは結構面倒。じゃ、DOMでプログラムを書けば？となるけど、getElementById()とかやって値とってくるより、VBAのマクロでRange("A1")とかやったほうが早いし、わかりやすい。
10:52 from web
もう一つは「見える化」ブーム。XMLだと、必要なところが見えにくいけど、Excelだと一目でわかりやすい（色とかもつけられるし、空間もいろいろとれて、目立たせたりもできる）
11:01 from web
UMLも小規模ならいい（Excelよりも？）。でも、大規模になったとき、図はわかりにくい。クラス図で、１枚にめちゃくちゃクラス組み込んで、あとで修正が入ったとき、修正箇所を探す場合とか。
12:55 from web
「SugarCRMコミュニティ「SugarCRM」を利用して経産省の「アフターアイディアボックス」を構築」だそうな http://sugarforum.jp/news/1867c80e-27d1-f3f5-4644-4b302c778dda
by xmldtp on Twitter