UMLダイアグラムを使用してコードの編成方法を計画することが不適切なのはなぜですか？

そのため、はい、図が不適切な場合があります。彼らはいつ不適切ですか？それらを検証するためのコードなしでそれらを作成し、それらに従うことを意図している場合。アイデアを探求するために図を描くことには何の問題もありません。

_{アジャイルソフトウェア開発：原則、パターン、および実践-Robert C. Martin}

これは正確にはどういう意味ですか？UMLは、「ダイブイン」する前にコードを構造化する方法を計画するのに役立つように設計されていませんか？あなたが思いついた図に従わない場合、それを使用する意味は何ですか？

コンテキスト：この章では、ボブおじさんがボウリングゲームのスコアキーパーのUML図を作成します。次に、UML図を調べずに、テスト駆動の方法でプログラムを開発します。結果のプログラムはUMLダイアグラムとは異なり、ボブおじさんは上記の結論に達します。

これを適切に説明するには、短い歴史のレッスンが必要です。ソフトウェアエンジニアリングの初期の頃、よく使われるアナロジーは家を建てることでした。建築家と構造エンジニアは、顧客と計画について話し合い、設計を考え出します。次に、建築業者はその設計に従って実際の家を建てます。コードを書くことは、実際の家を建てることと同等であると見なされました。したがって、そのビルドを行う前に、フロントデザインの必要性が認識されていました。さまざまなグラフィックデザインツールが作成され、UMLもその1つです。

もともとUMLでのアイデアは、UMLでシステムを完全に設計し、それをプログラマーに引き渡してその設計をコードに変換することでした。実際には、これはうまくいかず、何年ものプログラマーが「デザイナー」ではなく「インプリメンター」と見なされるようになり、プロジェクトが遅れ、設計は完成するはずだった後に常に変更する必要がありました。

理由は簡単です。コーディングはデザインです。家の類推では、コードは建築家の図面です。コンパイラーは、それらの設計を取り、それらからプログラムを構築するビルダーです。この実現により、アジャイル技術、TDDなどが生まれました。そのコード設計の品質向上に役立つツールです。

建築家が彼女と彼女のチームが設計全体を視覚化するのに役立つ予備スケッチを作成するのと同じように、開発者はUMLまたは他のツールを使用して、必要な設計の視覚化を助けることができます。これらのスケッチが盲目的にフォローされていないように、UMLは盲目的にフォローされるべきではありません。コード設計は、アジャイルな反復とTDDの使用から進化する必要があります。賢明なことに、建築家が家のモデルを作成して彼女と彼女のチームが図面を視覚化できるように、UMLを使用してコード構造を視覚化することができます。

ボブおじさんが言うように、UMLを検証することはできません。コードを検証することしかできません。したがって、コードは主要な設計ドキュメントであり、UMLが使用されている場合、それは二次的なドキュメントのみです。

すべてのプログラミングイディオム（またはデザイン、またはコード）がUMLに適合するとは限りません（私はそれがよくわからないことを認めます。

プレーンなCコード（Linuxカーネルのソースコードなど）は、UML で正確にモデル化されていない可能性があります。

Ocamlコード（そのモジュールとファンクターを含む）またはC ++ 11コード（ラムダとテンプレートを含む）もUMLに適合しない場合があります。

MetaOcamlによる多段階プログラミングはおそらくUMLに適合しません。

PrologコードまたはCommon LispコードはおそらくUMLに適合しません。

参照してください、この答え＆この鉱山の質問を。

Scottのプログラミング言語プラグマティクスとVan Royのコンピュータプログラミングの概念、手法、モデルを読んで、そこにあるすべてのプログラミングモデルがUMLに適合するかどうかを自問してください。

Martin Fowler's Is Design Dead？も参照してください。ブログ。