オルタナティブ・ブログ > An Agile Way >

アジャイルに行こう!

UMLと、分析・設計。JUDE製品の方向性。

»

前回の記事で、ソフトウェア開発における「分析」「設計」とはそれぞれ、なんであるか、ということを、問題解決、という観点、および、現実・モデルという観点から説明した。

JUDE-UML-Vision さて、UMLである。…

UMLは、当然、Modeling Language なのだから、【モデル領域】をカバーするものである。UMLのカバー範囲を、黄色で図示した。ただし、現在のUMLは、問題の分析にはとても非力だと思っている(ちなみに、UMLの"U"は、"Universal"ではなく、"Unified"であり、羊頭狗肉という訳ではない)。

そして、MDA(Model-Driven Architecture)である。…(sign)

MDAでは、PIM(Platform Independent Model)を元に、アーキテクチャ記述にあわせて実装が「自動生成される」(らしい)。それはそれですばらしいことだとは思う。しかし、当然、現在実現できているのは幾つかの領域(一部の組込みやJ2EE)に限られているし、ぼくの意見では、動くモデルを作る労力を使うならば、はっきりいって、コードを書いた方が速い。つまり、「正しい」発想だとは思うが、2005年の現時点では、「実りが少ない」と思う。スイートスポットを外している。しかし、多くのUMLモデリングツールが、この「コードを自動生成する方向」に重点を置いている。別の言葉でいうと、多くのUMLモデリングツールは、コンパイラとの対話に重点を置いているのだ。

ぼくは、

UMLモデリングツールは、「コンパイラ」ではなく「人」との対話に重点をおくべきだ

と思う。JUDEは、実装の方向ではなく、より、「要求」の方向を目指す。人の頭の中をどのように整理していくのか、人が図でどのようにコミュニケーションできるのか、人に考えを伝える図とはなにか、どんな図やどんな操作が、人の発想にフレンドリーなのか。

コードを自動生成しても、それは、所詮人間の考えをコンピュータが分かる形に規則的に変換しているにすぎない。そうではなくて、発想そのもの、あるいは、発想を要求の形にすること、そしてそれを伝えること、そこをサポートしたいんだ。

そんな思いをこめて、今回、JUDEでは、マインドマップをサポートしました。さて、次は何をサポートするか?候補としては、フィッシュボーン、マンダラート、SKMS、マジカ、…。

アナログはアナログでいいところがある。それはそうしておいて、デジタルで何がサポートできるか。。。そこを考えたい。きっとメリットがある何かがあるはず。

JUDEを、ITの「考具」にしたい。

これがぼくの思いです。

※JUDEのマインドマップ

http://jude.change-vision.com/

※マインドマップとUMLの相互利用

http://www.atmarkit.co.jp/farc/rensai/mm01/mm01a.html

※「考具」(加藤昌治さん)

http://www.amazon.co.jp/exec/obidos/ASIN/4484032058/xpjp-22

Comment(3)