オブジェクト指向言語の研究者らが記事UML: The Positive Spinにて、「UMLはソフトウェア開発には何も役に立たない」と批判しています。以下、直訳では無く私の理解の混じった完全な意訳にてメモとして残します。
UMLの利点
大学のGPAや会社での成績を助けることによる自尊心の向上, Rational(現IBM)の利益向上
補足：ソフトウェア開発に関しては誰にとっても全く利点は無い
UMLはコンピュータが実行不可能という事実
プログラミング言語はどんなに酷いものでも共通してコンピュータが実行可能で、それがApplicationとして動作したりHardwareを制御したりします。しかしUMLはどんなに詳細に書いてもコンピュータは実行できません。
膨大で曖昧、謎めいた記法
UMLでは三角形やひし形、実線、点線・・・といった記法が用いられます。UMLはこれらのシンボル同士の関係性を示すモデリングとしか見ることが出来ません。設計図から製品を作れる回路図とCADと同じレベルで、プログラミングの設計図にUMLを使うならば、その「記法概要欄」はぎっしり詰まった60ページ、70ページという膨大な量を費やすことになります。結果、UMLを書く間にコーディングを終えることができます。
オブジェクト指向と考え方が真逆
例えばflight, seat, personという3つのパラメータがあったとします。UMLでは、これらを一つ一つシンボルとして関係性をモデリングします。対照的にオブジェクト指向ではこれらのパラメータは一つのクラスに属します。考え方が異なるにも関わらず、UMLはオブジェクト指向を意味しオブジェクト指向はUMLだという認識は、オブジェクト指向有識者からするとオブジェクト指向の技術革新を10年遅らせています。
正確性の欠如
Ariane 5の爆破事故は、Ariane 4の適切なアサーションの無いコードを再利用し、再利用部分で前回ちゃんと動いた機能についてはテストされなかったことが原因と一つとして発生しました。オブジェクト指向では「機能」のオブジェクトのタイプに集中して全ての操作に対してこれらのタイプを定義するのに対し、UMLでは「ユースケース(システムがどういった動作をしないといけないか)」という根本ではなく表面的な性質に着目してしまうため、結果そこに正確性を保障することはできていません。
変更にも再利用にも対処できない
プログラムは堅牢で変更も再利用も容易でなければなりません。しかし、UMLにこれらを助ける何かはあるでしょうか。例えばコードの再利用について、インタフェースの規約の標準化、オプションとオペランドの分離、コマンドとクエリの分離などの、「再利用の課題に対処する何か」がオブジェクト指向の一貫性やモジュール性のように存在するようには思えません。
最後に
以上、直訳では無く、私の理解の混じった完全な意訳による要約でした。
UMLを描くのには時間がかかります。時間がかかる分、それだけの付加価値があることを説明できないといけないと思います。大学で教えられたから、会社で皆やっているから・・という理由で記法概要が足りず良く分からない多くのUML図を書き残してきた自分にとっては良い記事でした。
参考：国別で異なるモデリング手法の利用率と考え方
経済産業省 組込みソフトウェア産業実態調査報告書(P26参照)では、米国でほとんどUMLを使用していないという結果になっています。実際に私は米国の大学で学びながら米国の会社でプログラムを書いていますが日本に比べて圧倒的にUMLを使いません。シーケンスもフローチャートも、状態遷移図もほとんど描かずにコードを書きます。
2019/05/07
上記、"経済産業省 組込みソフトウェア産業実態調査報告書" のリンク先が削除されている件について、当時公開されていたページのキャプチャを掲載しました。
