UMLと、分析・設計。JUDE製品の方向性。
前回の記事で、ソフトウェア開発における「分析」「設計」とはそれぞれ、なんであるか、ということを、問題解決、という観点、および、現実・モデルという観点から説明した。
さて、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
※「考具」（加藤昌治さん）