プロジェクトを成功させるためにUML図はどのくらい重要ですか？
私はプロジェクトの途中で、UML図（ユースケース、クラス図など）を書くように求められました。プロジェクトはそれほど複雑ではありません。
これは私の時間の無駄かどうか疑問に思っていましたか？コードを書くような他の楽しいことをしているだけですか？そして、すべての概念的なフェーズを通過せずに何かを構築するのはいつ問題ないのでしょうか？それはすべて複雑さについてですか？もしそうなら、それをどのように測定するのですか？
私は少し前にUMLの大ファンでした。私もOMG認定を受けています。私が携わった大規模なエンタープライズプロジェクトで幅広く使用しました。
今日、UMLをほぼ完全に停止しました。時々、システム間の相互作用を説明するのに非常に役立つシーケンス図を使用しますが、他の図は使用しません。
私は今、製品の所有者（またはアナリスト）によって書かれた（のみ）必要なドキュメントと、必要に応じて詳細を提供するための開発チームへの彼（彼ら）の献身の両方によってサポートされるユーザーストーリーを扱うことを好みます。
UMLは使用できるツールですが、プロジェクトを成功させるための重要な要素ではありません。何年も経った今、どのツールを使用していても、重要な要素は開発チームだと思います。
計画は重要ですが、有名な戦略家として Carl von Clausewitz は警告します
敵との最初の接触を生き延びたキャンペーン計画はありません
したがって、問題を最初に攻撃する方法を計画するために時間を浪費することはそれほど大きなことではありません。しかし、おそらく将来のプログラマーのためにコードを文書化するための時間の無駄です。軍事的な比喩を使用するには、戦闘計画が必要ですが、その計画を歴史家に提供して、行動後のレポートとして使用することはできません。
より具体的には、これらの図を使用してチーム間で意図を伝え、プロジェクトの前および最中の攻撃の計画について考えることができます。しかし、奇妙なことに、コードを作成して問題についてさらに学習する際に、思いつくものを微調整する必要があります。ほとんどの場合、事前にすべてを知ることができないため、最初の計画/設計を変更する必要があります。
UMLダイアグラムはコードよりも抽象化のレベルが高いで何かを表現している場合にのみ役立つと思います。
UMLを書くためだけにUMLを書くと、不要な官僚主義になり、プロジェクトやコードを変更に適応できなくして、何のメリットもありません。
たとえば、パッケージのすべてのクラスとそれらのすべての属性とメソッド（簡単に自動生成できるもの）を示すUMLクラス図は、まったく値を提供しません。コードと同じ抽象化レベルです。 。さらに、コードは常に最新であり、おそらくより重要なメソッド/属性/事柄をより簡単に把握できる方法で文書化および整理されるため、コードはその情報のより優れたソースになるはずです。
一方、コードで表現できるものよりも抽象度の高い概念がある場合は、それらを図に文書化することをお勧めします。
たとえば、複雑なシステムの上位レベルの抽象モジュールと、それらの依存関係、およびそれらの責任の簡単な説明と、ソースコード内でそれらがどのパッケージ/名前空間にマップするかを示す図は、新しいチームメンバーにとって非常に役立つ場合がありますこれはプロジェクトに導入する必要があります。または、新しいクラス/機能をどこにスローするかを把握するためにも使用できます。
有用な図のもう1つの例は、通信プロトコルで実行される高レベルの手順を示すシーケンス図です。たぶん、それらの各ステップには少しの奇妙さと複雑さがありますが、おそらくコード自体でそれらを記述するのに十分です。上位レベルの図は、プログラマーが各対話の複雑さを気にすることなく、物事の「全体像」を簡単に理解するのに役立ちます。
とにかく、これらはほんの一例です。単純な図が非常に役立つ場合がたくさんあります。コード自体で何かを表現できない場合にのみ、それらを実行する必要があることを覚えておいてください。 UMLダイアグラムを使用してソースコード自体を説明している場合は、代わりにソースコードをより自己文書化してください。
最後に、コードに適用される一般的なルールの一部は図にも適用できます。繰り返しを避け、シンプルに保ち、変更を恐れないでください（UML図に何かが文書化されているからといって、それができないわけではありません変更する）そしてそれらを書くときはいつ誰がそれらの図を読んだり保守したりするのかを常に考えてください（おそらくあなたの未来-あなた）
UMLは、チームメンバーが集合的にそれを理解し、設計決定を要約して伝達するための有用な方法であると考える場合に価値があります。すべてを知る必要はありません。チームが有用であると考えるサブセットだけです。
また、完璧で洗練された図を描く必要はありません。コンテキストによっては、ホワイトボードに大まかにスケッチされたシーケンス図、またはクラスがそのホワイトボードに貼り付けられた付箋であるクラス図で十分な場合があります。
私はかつて海外で契約開発者のチームを管理する必要があるギグで働いていました。
彼らが作成していたもののいくつかはかなり恐ろしいものでした（リモートのコントラクトコーダーの一般的な症状-彼らはあなたのコードをあまり気にしていません。
プロジェクトを管理するために、UMLダイアグラムを作成し、それをコードに渡すことに自分が気付いた。それは非常に成功しました-Javaよりもはるかに速くUMLでプログラムを書くのにそれほど時間はかかりませんでした、そしてそれは請負業者が従うことができて、それに対して測定されたものでした。
注意点の1つ-彼らは時々クリエイティブになり、私のモデルから逸脱したいと思っていましたが、それらのケースでは実際には正しく、UML全体で最終製品の品質が向上しました
誰かがあなたにUML図を準備するように頼み、誰かがあなたの給料を払っているなら、それは本当にあなたの時間の無駄ではありません。それは誰かの時間の無駄かもしれませんし、そうでないかもしれません。
その誰かがあなたのUML図を読んであなたのプロジェクトを理解することを計画しているなら、それはおそらく彼らの時間の無駄ではありません。
紙やホワイトボードでアイデアを得るのは、設計の初期段階で役立ちます。標準に厳密に準拠することなく、主にUMLクラス図を使用しました。途中で、プロジェクトの最後にUMLの元の設計を再検討するのに役立ちます。これは、コードを読むだけで、より高い抽象度でコードベースを確認するのに役立ち、潜在的なバグを見つけるのにも役立ちました。
2つの種類のUMLを区別する hereragu.pattabi によって作成された良い点があります...
UMLのアジャイルフレーバーは、ウォーターフォールフレーバーUML（たとえば、ドキュメントに精通した管理者を満足させるための、ドキュメント、コード生成などのすべての厄介な詳細を含む複雑な図）。
UMLが「必須」のスキルと見なされたとき（10年以上前）、当時の多くのファンの意見が高かったため、おそらく私はそれに反対していました。しかし、今ではそれが支持を失い、ソフトウェア開発の特効薬ではないが有用な便利なツールである私は、それが何であるかを自分で見ています。
UMLは、クラス図を使用してアーキテクチャをグラフィカルに表示するのに非常に優れています。シーケンス図を使用した相互作用は私にとって魔法です。したがって、問題はUMLではなくMDDです。
つまり、UMLがコードのビューアである場合、それはドキュメンテーションの目的には本当に役立ちますが、コード生成には役立ちません。プロジェクトはコード中心であり、モデル駆動中心ではないはずです。 UMLは、ライブコードとモデルの同期を使用して、実装段階で使用する必要があります。つまり、生産性と品質の小さな利益のために多額の投資を必要とする要件レベルだけではありません。
プロジェクト作業文書は、プロフェッショナルプロジェクトの基本的な成果物です。いくらですか？まあそれはもちろん多くの要因に依存します。しかし、私の意見では、ユースケース、クラス図、プロセスフロー図などは、まったく時間の無駄ではありません。さまざまなプロジェクトフェーズで価値があります。ドキュメントに関する唯一の問題は通常、リソースです。
一部のプログラマーは、ドキュメントは時間の無駄だと考えています。しかし、これは真実ではありません。ドキュメンテーションをデザインとシステムルールの表示としてエレガントで明確な方法で表示すると、それをさらに理解できるようになります。また、システムを維持する必要がある人々の立場に自分を置く必要があります。 500ファイルのコードがスローされ、それらの問題を修正するように求められるのは、ちょっと悪いことですが、珍しいことではありません。
プロジェクトに時間を割り当て、図を周期的に作成することをお勧めします。 1つ目はプロジェクトの高レベルの側面をカバーし、次のレベルは詳細に詳しく説明します。
特にユースケースは、（システムの他の多くの側面とは異なり）コードから簡単に推測することはできません。あなたがそれらを行うことを確認してください。
私たちがやろうとしていることについて友人と話すとき、私はUML（またはUMLに似ています:)）を使用します。アイデアについて話し合う。コードを自動生成するUMLプロジェクトを準備しないでください。 UMLでクラスを作成してコードを生成することはできません。後で調整することはできません。これは決して起こりません。したがって、コードからUMLに変更を加える必要があります。また、UMLを使用する場合は、ホワイトボードまたは紙に描画します。 Enterprise Architectのようなツールでは決してありません。
コード全体をUMLで文書化する唯一の理由は、クライアントがそれを要求する契約です。たとえば、ソフトウェアの一部が終了した後、ソフトウェアショップを変更するオプションが必要な場合などです。
UMLはツールであり、それ以上のものではありません。UMLが有用か、それとも重要かは、開発と設計のワークフローにのみ依存します。ローマには多くの方法があり、UMLを使用する方法もあれば、UMLを使用しない方法もあります。
ワークフローがUMLに依存してアーキテクチャを文書化または計画している場合、それをドロップするのは愚かです。プロジェクト構造を他のチームメンバーに（より広い意味で）伝達するための最良の方法がUMLである場合は、必ずそれを使用してください。ただし、UMLがなくてもプロジェクトが正常に機能する場合は、UML図を作成するだけでは意味がありません。
私はこれについていくつか考えています。言語を使用したり、乱用したり、強要したり、注意をそらしたり、誘発したり、沈静化したりできます。 UMLは特定の問題セットに適した別の言語であり、他の言語と同様に、流暢に話して正しく理解することを学ぶには時間と労力がかかります。
何を伝えるべきかについての決定は、伝達される言語よりも非常に重要です。UMLは、悪いデザインを魔法のように理解できるようにはしません。他の言語と同じように、詳細に迷ったり、想像力に任せすぎたりするのは簡単です。
恐ろしいIDEが数多くあり、ラウンドトリップのプロトタイピング、集中的なグラフ操作、そして何でも変更するのが難しいため、UMLは悪い名前になりました。 UML 2.0は特定の学者を満足させるほど複雑かもしれませんが、そのメタモデルは多くの実用的なアプリケーションを引き付けていないようです。
それでも、私は時々UMLを使用します。高レベルのデザインを評価する（優れたデザインは、周辺部が複雑で、中心部が単純である）。アイデアを同僚に伝え、フィードバックを受け取る。隠された関係を見つけたり、正規化したりすることです。しかし、それはいつも私の頭の中にある何かを反映しています。一般的に、筆者はUMLをペンと紙で、できればどのコンピュータからも離れて描きます。必要に応じて、デザインが結晶化したら、描画プログラムで視覚的に表現します。
これまで使用してきたUMLダイアグラムについての私にとっての主な不満の1つは、ほとんどの場合、誰かの壁にある「きれいな絵」として、またはバインディングの折り畳まれたページとしてのみ機能し、ベースラインとして機能することはほとんどないということです量産コード用。
このタイプのシナリオでは、UMLダイアグラム（または使用するモデリング言語のフレーバー）は、時間の経過とともにプロジェクトが進化するにつれて関連性が失われる傾向があるため、長期的にはほとんど役に立ちません。これらの最初の図面は、ほとんどの場合、数年後には役に立たず不正確であり、それらを持ち歩くことはほとんど有害です。
とは言っても、モデルが実際の実行中のコードに実際のライブで関連する入力を提供する場合、モデリングツール（必ずしもUMLである必要はありません）を使用しても、まったく役に立たないというわけではありません。モデルの説明がコードの有用な成果物である場合は、コードとして扱う必要があります。
モデル化された概念に基づいて動的な意思決定を行うためのメタデータの直接ソースとして使用するか、コード生成を使用して実際の作業コードで使用される静的コードアーティファクトを生成します。
私は通常、コードとUMLダイアグラムを繰り返し処理します。これらの図は、全体像と今後の確実な道筋を示すのに役立ち、問題が発見された場合は、すぐに変更できることがわかりました。また、ダイアグラムがあると、コーディングは簡単になる傾向があります。
逆に、私がコードを絵で描くと、依存関係の問題が明らかになり、デザイン改善の機会が明白にわかります。特に、描くのが面倒な場合は、コーディングするのも面倒であり、維持するのも悪夢になります。
画像を描くだけでは常に重要な側面を見逃し、コーディングするだけで問題のある設計ができるため、反復が必要であることがわかりました。
しかし、別のポスターが言ったように、それはすべて人々に要約されます。彼らがUMLダイアグラムを「使用する」のに熟練している場合、UMLは非常に貴重です。そうでない場合、図は価値がありません。
したがって、あなたの質問に対する答えは、実際には「それは依存する」です。この場合、それは人、プロジェクトの複雑さ、システムが適切に機能することがいかに重要であるかに依存します。
私の経験から、UMLは、コードパターンについての開発者間のコミュニケーションと、アプリケーション全般のアーキテクチャにとって重要です。
私は図が大好きですが、図（特にUML！）を作成するように求められた場合、2つの質問をします。
- 誰のためですか？
- 彼らは今それを必要としますか？
図はすぐに古くなります。そのため、現在誰かと通信するために使用しているのでない限り、それは腐敗します。そして、あなたが通信している人がテキストの説明、電話、またはホワイトボード上の非公式の図表を使うとよりうまくいくなら、代わりにそれを提案してください。
私はそれらが非常に過大評価されていると思います。私はそれらを千の言葉を描かない唯一の絵と考えます。
UMLは、システムを設計する人々が自分でコードを記述できない場合にのみ価値があります。つまり、UMLはアーキテクチャの概念を他の人に伝える「言語」であり、コードを設計して実装している人が今なら、何をしようとしているのかを自分に示す必要があるのはなぜでしょうか。 ？！代わりに、コーディングに直行してください。後で何をしたかを文書化する必要がありますが、全体的な効率は速くなります。
ただし、システムアーキテクトが開発者のアウトソーシングチームに必要なことを伝えたい場合は、どういうわけか彼らに伝える必要があります。それがUMLの出番です。しかし、実行する代替手段はたくさんあると思います。このタスクは今日、そして率直に言って、UMLダイアグラムの複雑さは、誰もがそれを読む方法を理解する必要があることを意味します。
私はUMLのファンではありませんでしたが、システムまたはタスク間の相互作用を説明するための優れたシーケンス図を評価するようになりました。
ただし、クラス図は生まれる前に廃止されています。大まかな設計ではUMLは必要ありません。完全なドキュメントは、コードベースから自動的に抽出（ライブ）する方が適切です。 JavadocとDoxygenは、手動のクラス図の必要性を完全に廃止しました。
ドキュメントに関することは、2つのレベルがあることです。
- 高レベル（アーキテクチャー）の決定は手動で文書化する必要があります
- 低レベル（エンティティの関係）のファクトは自動的に抽出されます
問題がUMLのメリットに関するものなのか、プログラムのアーキテクチャを設計するメリットに関するものなのかわからない。
UMLについて。通常必要なのは、ユースケース、クラス図、シーケンス図だけです。シンプルで簡単ですが、独自のタイプの図を使用して確実に実行できます。この点で、UMLは誰もが理解できる標準です。
プログラムの設計について。
計画していなくても、すべてのプログラムにデザインがあります。コードが記述されたら、それをリバースエンジニアリングするだけです。あなたがそれを計画しなかったなら、それは悪いデザインになるでしょう。
繰り返し発生する問題の既知のパターンを使用することで、設計により時間を節約できます。
チームで作業する場合、解決策について話し合い、アイデアを伝達するためにデザインが必要であり、作業を分散させるために非常に実用的ですが必要です。