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

さて、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

ソフトウェア開発を「問題解決」、と見ると、 
問題→解という活動だと考えられる。左の「問題」は、問題空間にあり、右の「解」は解空間にある。設計とは、このマッピングを行なう活動だと考える。では、分析とは何か。 

実際には、（ソフトウェアでは特に）問題が複雑だったり曖昧だったりすることから、このままではうまく解けない（悪構造 ill-structured problem）。そこで、一旦、この「問題→解」という現実世界の問題をモデル化しよう、ということになる。「問題空間」、「解空間」という空間と直行する空間軸として、上下に「モデル空間」と「現実空間」を導入する。そうすると、４つの象限が現れる。その４つの象限に、現実空間の「問題」と「解」、そして、モデル空間の「分析モデル」と「設計モデル」を置く。ここで、分析モデル＝モデル化された問題 、設計モデル＝モデル化された解である。そして、問題→解という直線的な解き方ではなく、一旦モデル空間に上って遠回りをしてみる。

　分析モデル→設計モデル

　　　↑　　　　↓

　　　問題　　　解

問題を一旦モデル化する活動を「分析」と呼ぶ。成果物は、「モデル空間上の問題」（分析モデル）だ。そして、モデル空間上で解決させる活動を、「設計」と呼ぶ。成果物は、「モデル空間上の解」（設計モデル）だ。最後に、モデル空間から現実空間へと逆変換する。これを実装と呼ぶ。成果物は解、すなわち（ソフトウェア開発であれば）動くコードである。 

まとめると、設計とは、問題空間から解空間への変換である。ただし、一旦問題をモデル化し（分析）、それをモデルで解決する（設計）。つまり、モデル領域で変換する。そして、解のモデルを、再度現実領域にもどしてやる。これで最終的な現実世界の解にたどりつく。 

最後のミッシングリンクは、現実領域での、問題と解との突合せ、すなわち「テスト」である。テストによって、「右回りの活動」がもともとの意図である「問題→解決」と合っていることを示す。そう、この「テスト」こそが、問題に対する解が正しいことの最終的保障になるのだ。

Thanks > ぁまんにょさん（このロジックは二人の共作）

» 続きを読む