2010-02-12-01-自分にとっての UML - project-enigma

2010-02-12-01-自分にとっての UML

>> Site top >> weblog >> 月別アーカイブ >> 2010年02月のlog >> 2010-02-12-01-自分にとっての UML

最終更新日付:2013/12/31 07:36:09


自分にとっての UML

2010 年 02 月 12 日

UML が好きだった。過去形だ。

C++ がネイティブな自分にとって、UML は設計のためにとても便利な表記法だった。しばらく離れているうちに UML は仕様が肥大化し、個人的には一番重要と考えている『意思疎通のためのスケッチツール』という側面を薄れさせてしまったと思っている。だから『好きだった』と過去形にしているのだ。

個人的には、UML の仕様の肥大化には『CASEツール症候群』とでも呼ぶべきソフトウェア業界の古典的な病気と関係があると考えている。イデオロギーと言っても良いかもしれない。これは、『設計書を書けばそこからプログラムを作れるはずだ』というシンプルな発想からいくつもの病態を発生させるもので、特にプログラミングを知らない管理者クラスや上層部などがこれに罹患すると大いに苦しむことになる(現場の人間が)。過去に CASE という名で壮大な失敗を演じて以来、一時的にこのイデオロギーは『なかったこと』にされていたが、UML などの新しい表記法が表舞台に現れると、そこに取り付いて同じような事態を発生させる。

で、これが UML 仕様の肥大化とどう関係するか。ソフトウェアベンダーは自身が販売する UML ソフトウェアに CASE 的な機能をつけている。付加価値を高めるためだろう。そして、UML 仕様の策定や改善にはソフトウェアベンダーも絡んでいる。これにより、UML 仕様はあまりにも厳密に、そして大きくなりすぎたのだ。

ところで、『設計書を書けばそこからプログラムを作れるはずだ』という考えがなぜ間違いなのか。これは、設計というものをどう考えるかによるが、決定論的な方法(つまりなんらかのソフトウェアの実行)によってプログラムを生成できる設計情報というのは、人的であれ機械的であれ、プログラミングに必要な情報を全て含んでいるはずだ。その作成作業は、もはやかたちを変えただけのプログラミング作業に他ならない。

‥‥‥というところまでであれば、なにも「間違い」であると言って切り捨てるほどのものではない。自分としても、これを否定するつもりはない。問題なのは、そこに幻想が挟まっていることだ。つまり、プログラミングに必要な情報量(つまり人が作成する設計情報の量)を過小評価する幻想である。これは、過去の CASE ツールが判で押したように『省力化』だの『開発コストの低減』を謳っていたことからもわかる。つまり、『設計情報からプログラムを作成できる』だけなら(ひとまず)正しいものの、それが『プログラミングそのものよりも簡単な設計情報の作成により、魔法のようにプログラムを作成できる』になってしまうのが誤りなのだ。

公正を期すために書いておくと、上記のような幻想にとらわれなければ、この方法にはメリットがないわけではない。それは同期の問題だ。つまり、設計と実装の間の乖離を防ぐ方法としては、これは良いものだと言える。人手を使って同期をとることと比べて、CASE 的な方法で同期をとるのがコスト的に安くなるなら、これは良いことだと言えるだろう。

かなり話が横に逸れてしまった。本題に入る前に随分と長くなってしまったので、続きは改めて。

 

コメント

このページにコメントする

 

このページのタグ

Page tag : 開発

 

 


Copyright(C) 2005-2017 project-enigma.
Generated by CL-PREFAB.