プロジェクトを成功させるためにUML図はどれほど重要ですか？[閉まっている]

私はプロジェクトの途中で、UMLダイアグラム（ユースケース、クラスダイアグラムなど）を書くように頼まれました。プロジェクトはそれほど複雑ではありません。

これは私の時間の無駄なのだろうか？コードを書くような他の楽しいことをやるだけですか？そして、すべての概念フェーズを経ずに何かを構築することは大丈夫ではないのはいつですか？複雑さがすべてですか？もしそうなら、それを測定する方法？

私は少し前にUMLの大ファンでした。OMG認定も受けています。私が関与した大企業プロジェクトで広く使用しました。

今日、UMLをほぼ完全に停止しました。時々、システム間の相互作用を記述するのに非常に役立つと思うシーケンス図を使用しますが、他の図は使用しません。

現在、製品所有者（またはアナリスト）が作成した（のみ）必要なドキュメントと、必要に応じて詳細を提供する開発チームへの（彼らの）献身の両方によってサポートされているユーザーストーリーで作業することを好みます。

UMLは使用できるツールですが、プロジェクトの成功にとって重要な要素ではありません。何年も経った今、私は、どのツールを使用しても、重要な要因は開発チームだと考えています。

計画は重要ですが、有名な戦略家カール・フォン・クラウゼヴィッツが警告するように

敵との最初の接触で生き残るキャンペーン計画はありません

したがって、問題を最初に攻撃する方法を計画するのに大きな時間の無駄はありません。しかし、将来のプログラマーのためにコードを文書化するための時間の無駄です。軍事的な比phorを使用するには、戦闘計画が必要ですが、行動計画のレポートとして使用するために歴史家にその計画を与えることはありません。

より具体的には、これらの図を使用して、チーム間で意思を伝え、プロジェクトの前後に攻撃の計画について考えることができます。しかし、オッズは、コーディングして問題についてさらに学習するときに、思いついたものを微調整する必要があるということです。事前にすべてを知ることはできないため、ほとんどの場合、最初の計画/設計を変更する必要があります。

UMLダイアグラムは、コードよりも高い抽象化レベルで何かを表現する場合にのみ役立つと思います。

UMLを作成するためだけにUMLを作成すると、不要な官僚主義になり、プロジェクトとコードの変更への適応性が低下し、何のメリットもありません。

たとえば、パッケージ上のすべてのクラスとそのすべての属性とメソッド（簡単に自動生成できるもの）を示すUMLクラス図は、値をまったく提供しません。コードと同じレベルの抽象化です。 。さらに、コードは常に最新であるため、その情報のより良いソースになります。おそらく、どのメソッド/属性/ものがより重要であるかを簡単に把握できる方法で文書化および編成されます。

一方、コードで表現できるものよりも高い抽象化の概念がある場合は、ダイアグラムにそれらを文書化することをお勧めします。

たとえば、複雑なシステムの上位レベルの抽象モジュールを示す図と、その依存関係、およびそれらの責任とソースコードでマッピングするパッケージ/ネームスペースについての少しの説明は、新しいチームメンバーにとって非常に便利です。プロジェクトに導入する必要があります。または、新しいクラス/機能をスローする場所を見つけるために使用することもできます。

有用な図の別の例は、通信プロトコルで実行される高レベルの手順を示すシーケンス図です。それらの各ステップには、ちょっとした癖や複雑さがあるかもしれませんが、おそらくコード自体でそれらを説明するだけで十分でしょう。上位レベルの図は、プログラマが各相互作用の複雑さを心配することなく、物事の「全体像」を簡単に理解するのに役立ちます。

とにかく、これらはほんの一例です。単純なダイアグラムが非常に役立つ場合が多くあります。コード自体で何かを表現できない場合にのみ、それらを行うべきであることを覚えておいてください。ソースコード自体を説明するためにUMLダイアグラムを使用していることに気付いた場合は、代わりにソースコードをより自己文書化してください。

最後に、コードに適用される一般的なルールのいくつかは図にも適用できます：繰り返しを避け、シンプルに保ち、変更を恐れないでください（UML図に何かが文書化されているからといって、できないというわけではありません）変更される）そして、それらを書くとき、誰が将来（おそらくあなたの未来自身）それらの図を読んで/維持するかを常に考えてください:)

チームメンバーが集合的にUMLを理解し、それを設計決定の要約と伝達の有用な方法と考える場合、UMLには価値があります。すべてを知る必要はありません。チームが有用だと判断したサブセットのみです。

また、完璧で洗練された図を描く必要はありません。コンテキストに応じて、ホワイトボード上の大まかにスケッチされたシーケンス図、またはクラスがそのホワイトボードに貼り付けられたポストイットノートであるクラス図で十分な場合があります。

私はかつて、海外の契約開発者のチームを管理する必要があるギグに取り組んでいました。

彼らが制作していたもののいくつかは非常に恐ろしいものでした（リモートコントラクトコーダーの一般的な症状-彼らはあなたのコードにあまり関心がなく、ただ早くやりたいだけです）。

プロジェクトを管理するために、UMLダイアグラムを作成し、それらをコードに渡すことに気付きました。それは大成功でした-UMLでプログラムをJavaで書くよりもはるかに速く書くのにそれほど時間はかからず、請負業者が従い、測定できるものでした。

1つの注意点-彼らは時々創造的になり、私のモデルから外れたいと思っていましたが、そのような場合は実際に正しく、UML全体で最終製品の品質を改善しました

誰かがUML図を準備するように頼み、誰かがあなたの給料を払っているなら、それはあなたの時間の無駄ではありません。それはその人の時間の無駄かもしれませんし、そうでないかもしれません。

その誰かがあなたのUML図を読むことであなたのプロジェクトを理解しようとしているなら、それはおそらく彼らの時間の無駄ではないでしょう。

紙やホワイトボードでアイデアを得るのは、初期設計段階で役立ちます。私は主にUMLクラス図を使用しましたが、標準に厳密に準拠していません。プロジェクトの途中やプロジェクトの終了時に、UMLのオリジナルデザインを再検討するのに役立ちます。これは、コードを読むだけで得られるより高いレベルの抽象化でコードベースを見るのに役立ち、潜在的なバグを見つけるのにも役立ちました。

ここには、2種類のUMLを区別するragu.pattabiによる良い点があります...

UML のアジャイルなフレーバー（クイックホワイトボードスケッチなど）は、UML のウォーターフォールフレーバー（たとえば、ドキュメントに精通した精巧なダイアグラム、コード生成など、ドキュメントに精通したマネージャーを満足させる）よりも成功すると思います。

UMLが「必携」スキルと見なされたとき（10年以上前）、当時の多くのファンからの意見が多かったため、私はおそらくそれに反対でした。しかし、今ではそれが好意的ではなくなったので、私はそれが何であるかを見ていることに気づきました-メリットはあるがソフトウェア開発の特効薬ではない便利なツール

私たちがやろうとしていることについて友人と話すときは、UML（またはUMLに似たsth）を使用します。アイデアを議論する。コードを自動生成するUMLプロジェクトを準備しないでください。UMLでクラスを作成してコードを生成し、後で微調整することは考えられません。これは決して起こりません。そのため、コードからUMLに変更を加える必要があります。そして、UMLを使用するときは、ホワイトボードまたは紙に描きます。エンタープライズアーキテクトのようなツールではありません。

コード全体をUMLで文書化する唯一の理由は、クライアントが要求する契約です。たとえば、ソフトウェアの一部が終了した後にソフトウェアショップを変更するオプションが必要な場合。

プロジェクト作業のドキュメントは、プロのプロジェクトの基本的な成果物です。いくらですか？もちろん、それは多くの要因に依存します。しかし、私の意見では、ユースケース、クラス図、プロセスフロー図などは時間の無駄ではありません。さまざまなプロジェクトフェーズで価値があります。ドキュメントに関する唯一の問題は通常リソースです。

一部のプログラマーは、文書化は時間の無駄だと考えています。しかし、これは真実ではありません。ドキュメンテーションを、デザインおよびシステムルールの表示としてエレガントで明確な方法で表示する場合、それをより感謝するようになるかもしれません。また、システムを維持する必要がある人々の立場に自分を置く必要があります。500ファイルのコードがスローされ、それらの問題を修正するように頼まれることは、一種の悪いことですが、珍しいことではありません。

プロジェクトに時間を割り当て、サイクルで図を作成することをお勧めします。1つ目はプロジェクトの高レベルの側面をカバーし、その後のレベルでは詳細について詳しく説明します。

特に、ユースケースは、システムの他の多くの側面とは異なり、コードから簡単に推測することはできません。必ずそれらを実行してください。

UMLはツールであり、それ以上のものではありません。UMLが有用であるか重要であるかは、開発および設計のワークフローのみに依存します。ローマには多くの方法があり、そのうちのいくつかはUMLを使用しますが、他の方法は使用しません。

ワークフローがUMLに依存してアーキテクチャを文書化または計画している場合、それを削除するのはばかげています。UMLがプロジェクト構造を他のチームメンバーに（より広い意味で）伝えるための最良の方法である場合は、必ずそれを使用してください。しかし、プロジェクトがUMLなしで正常に動作する場合、そのためだけにUMLダイアグラムを作成するのはナンセンスです。

私はこれについていくつかの考えを持っています。言語は使用され、乱用され、強要され、注意をそらされ、引き金を引かれ、小康状態になります。UMLは特定の問題セットに適した別の言語であり、他の言語と同様に、流MLに話し、正しく理解することを学ぶには時間と労力がかかります。

何を伝えるかについての決定は、それが伝えられる言語よりも非常に重要です。UMLはあなたの悪いデザインを魔法のように理解できるようにしません。他の言語と同様に、細部に迷い込んだり、想像力に任せすぎたりするのは簡単です。

UMLは、多数の恐ろしいIDEがあり、ラウンドトリッププロトタイピング、クリックを集中的に使用するグラフ操作、および何も変更することができないため、悪い名前になりました。UML 2.0は特定の学者を満足させるほど複雑かもしれませんが、そのメタモデルは多くの実用的なアプリケーションを引き付けるようには見えません。

それでも、私は時々UMLを使用します。高レベルの設計を評価するため（良い設計には、周辺の複雑さと中心部の単純さがあります）。アイデアを同僚に伝え、フィードバックを受け取る。隠れた関係を見つける、正規化するなど。しかし、それは常に私の頭の中にある何かの反映です。一般に、UMLはペンと紙で、できればどのコンピューターからも離れて描画します。必要に応じて、デザインが結晶化すると、描画プログラムで視覚的に表現します。

UMLは、クラス図を使用してアーキテクチャのグラフィカルビューを取得するのに最適です。シーケンス図を使用した相互作用は私にとって魔法です。したがって、問題はUMLではなくMDDです。

UMLがコードのビューアーである場合、ドキュメンテーションの目的には本当に役立ちますが、コード生成には確かに役立ちません。プロジェクトはコード中心であり、モデル駆動中心ではありません。UMLは、ライブコードとモデルの同期を使用して実装段階で使用する必要があります。生産性と品質のわずかなリターンのために多額の投資を必要とする要件レベルだけでなく、という意味です。

私はそれらが非常に過大評価されていると思う。私はそれらを千の言葉を描かない唯一の写真だと考えています。

UMLは、システムを設計する人々が自分でコードを書くことができない場合にのみ価値があります。つまり、UMLは、アーキテクチャの概念を他の人に伝える「言語」であり、コードを設計して実装しているのであれば、何をするのかを自分で示す必要があるのはなぜですか？！代わりに、コーディングに直行してください。後で行ったことを文書化する必要がありますが、全体的な効率はより速くなります。

しかし、あなたが外部の開発者チームにあなたが望むことを伝えたいシステムアーキテクトであるなら、あなたは彼らに何とか伝えなければならないでしょう、そしてそれがUMLの出番です。このタスク、そして率直に言って、UML作図の複雑さは、誰もがそれを読む方法を理解しなければならないことを意味します。

私はUMLのファンではありませんでしたが、システムまたはタスク間の相互作用を説明するための適切なシーケンス図を評価するようになりました。

ただし、クラス図は、作成される前は廃止されています。大まかな設計にはUMLは必要ありません。徹底したドキュメントは、コードベースから自動的に抽出（ライブ）される方が適切です。JavadocとDoxygenは、手動のクラス図の必要性を完全に廃止しました。

ドキュメントに関することは、2つのレベルがあることです。

• 高レベル（アーキテクチャ）の決定はマニュアルで文書化する必要があります
• 低レベル（エンティティリレーションシップ）ファクトは自動的に抽出されます

私は通常、コードとUMLダイアグラムを繰り返します。この図は、全体像と確実な前進の道筋を示すのに役立ち、問題が発見されたときにかなり迅速に変更できることがわかりました。また、ダイアグラムを作成すると、コーディングが簡単になる傾向があります。

逆に、写真にコードを描画すると、依存関係の問題が明らかになり、デザインの改善の機会が明らかになります。特に、描画するのが苦痛なら、コードを書くのも苦痛であり、維持するのは悪夢です。

単に絵を描くだけでは重要な側面を見逃し、コーディングだけでは問題のあるデザインになるため、反復が必要であることがわかりました。

しかし、別のポスターが言ったように、それはすべて人々に帰着します。UMLダイアグラムを「使用」する熟練者であれば、UMLは非常に貴重です。そうでない場合、ダイアグラムは価値がありません。

したがって、あなたの質問への答えは本当に「それは依存します」です。この場合、それは人々、プロジェクトの複雑さ、およびシステムが適切に機能することの重要性に依存します。

私の経験から、UMLは、コードパターンに関する開発者間のコミュニケーションと、アプリケーションの一般的なアーキテクチャにとって重要です。

私は図が大好きですが、1つ（特にUML！）を作るように頼まれたら、2つの質問をします。

1. 誰のためですか？
2. 彼らは今それを必要としますか？

図はすぐに古くなってしまいます。そのため、現在誰かと通信するために使用しているのでなければ、ただ腐敗します。そして、あなたが通信している人がテキストの説明、電話、またはホワイトボード上の非公式のダイグラムでうまくいくなら、代わりにそれを提案してください。

これまで使用したUMLダイアグラムについての大きな不満の1つは、ほとんどが誰かの壁の「きれいな写真」として、またはどこかのバインディングの折り畳まれたページとしてのみ使用され、ベースラインとしてはほとんど使用されないことです量産コード用。

このタイプのシナリオでは、UMLダイアグラム（または使用するモデリング言語の種類）は、時間が経つにつれてプロジェクトの発展とともに関連性が失われる傾向があるため、長期的にはほとんど役に立ちません。これらの初期図面はほとんど役に立たず、数年のうちに不正確であり、それらを持ち歩くことはほとんど有害です。

ただし、モデルが実際の実行中のコードに実際のライブおよび関連する入力を提供する場合、モデリングツール（必ずしもUMLとは限りません）を使用することは、まったく役に立たないプラクティスではありません。モデルの説明がコードの有用な成果物である場合、コードとして扱う必要があります。

モデル化された概念に基づいて動的な意思決定を行うためのメタデータの直接ソースとして使用するか、コード生成を使用して実際の作業コードで使用される静的コード成果物を生成します。

質問がUMLのメリットなのか、プログラムのアーキテクチャを設計するメリットなのかわからない。

UMLについて。通常必要なのは、ユースケース、クラス図、シーケンス図だけです。シンプルで簡単ですが、独自のタイプのダイアグラムで確実に行うことができます。この点で、UMLは誰もが理解できる標準です。

プログラムの設計について。

1. 計画しなくても、すべてのプログラムにはデザインがあります。コードを作成したら、リバースエンジニアリングします。あなたがそれを計画していなかったなら、それは悪いデザインになるに違いない。

2. 繰り返し発生する問題に対して既知のパターンを使用することにより、設計により時間を節約できます。

3. チームで作業する場合、ソリューションを議論し、アイデアを伝達し、作業を分散するために非常に実用的ですが必要な設計が必要です。