UMLダイアグラムを使用してコードの編成方法を計画することが不適切なのはなぜですか？
そのため、はい、図が不適切な場合があります。彼らはいつ不適切ですか？それらを検証するためのコードなしでそれらを作成し、それらに従うことを意図している場合。アイデアを探求するために図を描くことには何の問題もありません。
アジャイルソフトウェア開発：原則、パターン、および実践 -Robert C. Martin
これは正確にはどういう意味ですか？ UMLは、コードを構造化する方法beforeの「飛び込み」を計画するのに役立つように設計されていませんか？思いついた図に従わない場合、それを使用する意味は何ですか？
コンテキスト：この章では、ボブおじさんがボウリングゲームのスコアキーパーのUML図を作成します。次に、UML図を参照せずに、テスト駆動方式でプログラムを開発します。結果のプログラムはUMLダイアグラムとは異なり、ボブおじさんは上記の結論に達します。
これを適切に説明するには、短い歴史のレッスンが必要です。ソフトウェアエンジニアリングの初期の頃、よく使われるアナロジーは家を建てることでした。建築家と構造エンジニアは、顧客と計画について話し合い、設計を考え出します。次に、建築業者はその設計に従って実際の家を建てます。コードを書くことは、実際の家を建てることに相当すると見なされました。したがって、そのビルドが行われる前に、フロントデザインの必要性が認識されていました。さまざまなグラフィックデザインツールが作成され、UMLもその1つです。
もともとUMLでのアイデアは、UMLでシステムを完全に設計し、それをプログラマーに引き渡してその設計をコードに変換することでした。実際には、これはうまくいかず、何年ものプログラマーが「デザイナー」ではなく「インプリメンター」と見なされるようになり、プロジェクトが遅れ、デザインは完成するはずだった後に常に変更する必要がありました。
理由は簡単です。コーディングはdesignです。家のアナロジーでは、コードは建築家の図面です。コンパイラーは、それらの設計を取り、それらからプログラムを構築するビルダーです。この実現により、アジャイル技術、TDDなどが生まれました。そのコード設計の品質向上に役立つツールです。
建築家が彼女と彼女のチームが設計全体を視覚化するのに役立つ予備スケッチを作成するのと同じように、開発者はUMLまたは他のツールを使用して、必要な設計を視覚化するのに役立ちます。これらのスケッチが盲目的にフォローされないように、UMLは盲目的にフォローされるべきではありません。コード設計は、アジャイルな反復とTDDの使用から進化する必要があります。同様に、建築家が家のモデルを作成して彼女と彼女のチームが図面を視覚化できるように、UMLを使用してコード構造を視覚化することができます。
ボブおじさんが言うように、UMLを検証することはできません。コードを検証することしかできません。したがって、コードは主要な設計ドキュメントであり、UMLが使用されている場合、それは二次的なドキュメントのみです。
すべてのプログラミングイディオム（またはデザイン、またはコード）がUMLに適合するとは限りません（私はそれがよくわからないことを認めます。
プレーンなCコード（Linuxカーネルのソースコードなど）は、UMLによって正確にモデル化されていない可能性があります。
Ocamlコード（そのモジュールとファンクターを含む）またはC++ 11コード（ラムダとテンプレートを含む）もUMLに適合しない場合があります。
マルチステージプログラミング アラMetaOcamlはおそらくUMLに適合しません。
PrologコードまたはCommon LISPコードはおそらくUMLに適合しません。
Scottの Programming Language Pragmatics とVan Royの の概念、手法、およびコンピュータプログラミングのモデル 本を読んで、そこにあるすべてのプログラミングモデルがUMLに適合するかどうかを自問してください。
Martin Fowlerの Is Design Dead？ ブログも参照してください。