UMLは実用的ですか？[閉まっている]

大学では、設計とUML指向のコースを数多く受けてきましたが、UMLを使用してソフトウェアプロジェクト、特にユースケースマッピングに利益をもたらすことができることを認識していますが、本当に実用的ですか？私はいくつかの協同作業の作業を行いましたが、UMLは業界であまり使用されていません。プロジェクト中にUML図を作成する価値はありますか？また、クラスのヘッダーファイルを見たほうが速いので、クラス図は一般的に役に立たないことがわかります。具体的には、どの図が最も役立ちますか？

編集：私の経験は、10未満の開発者プロジェクトに限定されています。

編集：多くの良い答え、そして最も冗長ではありませんが、選択されたものが最もバランスが取れていると思います。

十分に複雑なシステムでは、いくつかの場所がUML有用であると考えられています。

システムに役立つ図は、適用性によって異なります。
しかし、最も広く使用されているものは次のとおりです。

• クラス図
• 状態図
• アクティビティ図
• シーケンス図

彼らに誓う多くの企業があり、多くの時間と努力の無駄としてそれらを完全に拒否する多くの企業があります。

やり過ぎないで、自分が現在取り組んでいるプロジェクトに最適なものを考え、適用可能で意味のあるものを選択するのが最善です。

UMLを使用することは、歩くときに足を見るようなものです。それはあなたが普段無意識にできることを意識的かつ明示的にすることです。初心者は自分が何をしているかについて慎重に考える必要がありますが、プロのプログラマーはすでに何をしているかを知っています。ほとんどの場合、プログラミングの直感はタスクに合わせて調整されているため、コード自体を書く方がコードについて書くよりも速くて効果的です。

それはあなたがやっていることだけではありません。今から6か月後に採用され、コードのスピードを上げる必要がある新規採用者はどうですか？現在プロジェクトに取り組んでいる全員がいなくなった今から5年後はどうでしょうか。

後でプロジェクトに参加するすべての人が基本的な最新のドキュメントを入手できると、非常に役立ちます。メソッド名とパラメーターを含む完全なUMLダイアグラムを推奨することはしません（維持するのは非常に難しい）が、システム内のコンポーネントの基本的なダイアグラムとそれらの関係および基本的な動作は非常に貴重だと思います。システムの設計が大幅に変更されない限り、実装が微調整されていても、この情報はあまり変更されません。

ドキュメンテーションの鍵は節度であることがわかりました。数ページで眠りに落ちることなく、設計ドキュメントを含む本格的なUML図を50ページ読む人はいないでしょう。一方、ほとんどの人は、5〜10ページの簡単なクラス図を取得することを望んでいます。システムをまとめています。

UMLが有用であるとわかったもう1つのケースは、上級開発者がコンポーネントの設計を担当しているが、その設計をジュニア開発者に渡して実装する場合です。

UMLを使用することは、歩くときに足を見るようなものです。それはあなたが普段無意識にできることを意識的かつ明示的にすることです。初心者は自分が何をしているかについて慎重に考える必要がありますが、プロのプログラマーはすでに何をしているかを知っています。ほとんどの場合、プログラミングの直感はタスクに合わせて調整されているため、コード自体を書く方がコードについて書くよりも速くて効果的です。

例外は、夜にトーチなしで森の中にいるのに雨が降り始めた理由です。それから、転倒しないように足を見る必要があります。実行したタスクが直感で処理できるよりも複雑で、速度を落としてプログラムの構造を明示的に記述する必要がある場合があります。次に、UMLは、使用できる多くのツールの1つです。その他には、疑似コード、高レベルのアーキテクチャ図、奇妙なメタファーが含まれます。

一般的なワークフローとDFDは、複雑なプロセスに非常に役立ちます。他のすべての図（特にUML）は、私の経験では、例外なく、時間と労力の痛い無駄でした。

UMLは至る所で使用されています。ITプロジェクトが設計されているところならどこでも、UMLは通常そこにあります。

今、それがうまく使われているかどうかは別の問題です。

Stuが言ったように、開発者の観点から見ると、ユースケース（およびユースケースの説明）とアクティビティ図の両方が最も役立ちます。

クラス図は、関係や、永続性などのオブジェクト属性を表示するときに非常に役立ちます。単一の属性またはプロパティを追加することになると、特にコードが記述されるとすぐに古くなってしまうことが多いため、それらは通常過剰です。

UMLの最大の問題の1つは、コードが生成された後、UMLを最新の状態に保つために必要な作業量です。UMLをコードからリエンジニアリングできるツールはほとんどなく、それをうまく行うツールはまだほとんどありません。

私は、大規模な（IBMのような）企業開発環境での経験がないことを述べて、私の回答を修飾します。

私は、UMLや表示方法ラショナル統一プロセスは、それがよりということですTALKINGは、あなたが実際よりもやろうとしているかについてDOINGあなたがやろうとしているものを。

（言い換えれば、それは主に時間の無駄です）

私の意見だけで捨ててください。UMLはアイデアを伝達するための優れたツールです。唯一の問題は、本質的に同じ情報の2つのコピーを作成するため、それを保存して保守することです。最初の実装ラウンドの後、ほとんどのUMLはソースコードから生成する必要があります。それ以外の場合、UMLはすぐに古くなるか、最新の状態を維持するために多くの時間（手動エラーを伴う）を必要とします。

学校の最後の2学期で上級レベルの開発プロジェクトコースを共同で教えました。このプロジェクトは、地域の非営利団体が有料クライアントとして運用環境で使用されることを目的としています。私たちはコードが私たちが期待したことを実行し、生徒がクライアントのニーズを満たすために必要なすべてのデータをキャプチャしていることを確認する必要がありました。

教室の外での私の時間と同様に、授業時間は限られていた。そのため、クラスのミーティングごとにコードレビューを行う必要がありましたが、25人の学生が登録していたため、個別のレビュー時間は非常に短かったです。これらのレビューセッションで最も価値のあるツールは、ERD、クラス図、シーケンス図でした。ERDとクラス図はVisual Studioでのみ作成されたので、それらを作成するのに必要な時間は学生にとって取るに足らないものでした。

ダイアグラムは非常に迅速に大量の情報を伝えました。学生のデザインの概要をすばやく把握することで、コード内の問題領域をすばやく特定し、その場でより詳細なレビューを行うことができました。

図を使用しないと、問題を探すために生徒のコードファイルを1つずつ時間をかけて調べなければなりませんでした。

私は少し遅れてこのトピックに来ており、いくつかのマイナーな点を明確にしてみます。UMLがあまりにも広い範囲で有用かどうかを尋ねる。ほとんどの人は、描画/コミュニケーションツールの観点から、典型的/人気のあるUMLからの質問に答えているようです。注：Martin Fowlerや他のUMLの本の著者は、UMLはコミュニケーションにのみ使用するのが最適だと考えています。ただし、UMLには他にも多くの用途があります。とりわけ、UMLは、論理概念にマッピングされた表記法と図表を備えたモデリング言語です。UMLのいくつかの使用法は次のとおりです。

• コミュニケーション
• 標準化された設計/ソリューションのドキュメント
• DSL（ドメイン固有言語）定義
• モデル定義（UMLプロファイル）
• パターン/アセットの使用
• コード生成
• モデル間の変換

上記の使用リストを考えると、Pascalによる投稿は、ダイアグラムの作成についてのみ述べているため、十分ではありません。上記のいずれかが重要な成功要因であるか、標準化されたソリューションを必要とする問題領域である場合、プロジェクトはUMLの恩恵を受けることができます。

議論は、UMLが過剰に殺されたり、小規模プロジェクトに適用されたりして、UMLが理にかなっている場合、または実際に製品/ソリューションが改善されるとき（つまり、UMLを使用する必要があるとき）を議論する方法から拡張する必要があります。パターンアプリケーションやコード生成など、1人の開発者にとってUMLが同様に感知できる状況があります。

UMLは何年も私のために働いてきました。私が始めたとき、私はFowlerのUML Distilledを読み、「十分なモデリング/アーキテクチャーなどを行う」と述べています。必要なものだけを使用してください！

QAエンジニアの観点から見ると、UML図は論理と思考の潜在的な欠陥を指摘しています。私の仕事を簡単にします:)

UMLは有用だと思います。2.0の仕様では、かつては明確な仕様であったものがやや肥大化して扱いにくくなっていると思います。タイミング図等の改訂版は空欄を埋めたので同意します...

UMLの効果的な使い方を学ぶには、少し練習が必要です。最も重要なポイントは、明確にコミュニケーションし、必要に応じてモデル化し、チームとしてモデル化することです。ホワイトボードは私が見つけた最高のツールです。実際のホワイトボードの有用性をとらえた「デジタルホワイトボードソフトウェア」を見たことはありません。

そうは言っても、私は次のUMLツールが好きです。

1. バイオレット-それがもっとシンプルであるなら、それは一枚の紙でしょう

2. Altova UModel-JavaおよびC＃モデリングに適したツール

3. MagicDraw-私のお気に入りのモデリング用商用ツール

4. ポセイドン-お金のための良い強打を持つまともなツール

5. StarUML-最高のオープンソースモデリングツール

UMLダイアグラムは、要件を収集して伝達し、システムがそれらの要件を確実に満たすようにするのに役立ちます。これらは繰り返し使用でき、計画、設計、開発、テストのさまざまな段階で使用できます。

トピックから：http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspxの開発プロセスでのモデルの使用

モデルは、システムが動作する世界を視覚化し、ユーザーのニーズを明確にし、システムのアーキテクチャを定義し、コードを分析し、コードが要件を満たしていることを確認するのに役立ちます。

また、次の投稿に対する私の返答を読むこともできます。

「優れたソフトウェア設計/アーキテクチャ」を学ぶには？で/programming/268231/how-to-learn-good-software-design-architecture/2293489#2293489

この議論は長い間活発ではありませんでしたが、私が心に留めておくべきいくつかの重要なポイントがあります。

バギーコードは一つです。下流に漂うままにされると、設計ミスは実際に非常に肥大化し、醜くなります。ただし、UMLは自己検証型です。つまり、数学的に閉じた、相互に確認し合う複数の次元でモデルを探索できるようにすることで、堅牢な設計が生まれます。

UMLにはもう1つの重要な側面があります。それは、視覚化という最強の機能と直接「対話」します。たとえば、ITIL V3（非常に単純なもの）がUMLダイアグラムの形式で伝達されていた場合、数十のA3フォールドアウトで公開されている可能性があります。代わりに、それは本当に聖書的な比率のいくつかのトームで現れ、業界全体を生み出し、息をのむほどのコストと広範囲にわたる緊張性ショックをもたらしました。

私はかなり頻繁に使用されるシーケンス図とアクティビティ図を見ます。私は他のシステムと相互作用する「リアルタイム」および組み込みシステムで多くの作業を行っており、シーケンス図はすべての相互作用を視覚化するのに非常に役立ちます。

私はユースケース図を描くのが好きですが、価値があると思う人にあまり会いませんでした。

Rational RoseがUMLモデルベースの設計から得られるアプリケーションの種類の良い例であるかどうか、私はよく疑問に思いました。肥大化し、バグが多く、遅く、醜い...

UMLは非常に小さなプロジェクトにはあまり役に立たないが、大規模なプロジェクトには本当に適していることがわかりました。

基本的に、何を使用するかは重要ではありません。次の2つの点に注意してください。

• ある種のアーキテクチャ計画が必要です
• チームの全員がプロジェクト計画に実際に同じテクノロジーを使用していることを確認したい

つまり、UMLはまさにそのとおりです。プロジェクトの計画方法に関する標準です。新しい人を雇うと、既存の社内のものよりも、UML、Flowchard、Nassi-Schneidermanなど、既存の標準を知っている可能性が高くなります。

単一の開発者または単純なソフトウェアプロジェクト、あるいはその両方にUMLを使用するのはやり過ぎに思われますが、より大きなチームで作業するときは、ソフトウェアを計画するための標準が必要です。

UMLは便利です。そうです。私が作った主な用途は次のとおりです。

• ソフトウェアの動作方法についてブレーンストーミングを行う。考えていることを簡単に伝えることができます。
• システムのアーキテクチャ、そのパターン、およびそのクラスの主な関係を文書化します。それは、誰かがあなたのチームに入ったとき、あなたが去って、後継者がそれを理解することを確実にしたいとき、そしてあなたが最終的にその小さなクラスが何を意味していたのかを忘れたときに役立ちます。
• 上記の点と同じ理由で、すべてのシステムで使用するアーキテクチャパターンを文書化する

Michael が単一の開発者または単純なソフトウェアプロジェクト、あるいはその両方にUMLを使用するのはやり過ぎだと言ったときだけ、私はMichaelに同意しません。私は小さな個人的なプロジェクトでそれを使用しました。UMLを使用してそれらを文書化したことで、7か月後にそれらに戻ったとき、多くの時間を節約し、すべてのクラスを構築してまとめた方法を完全に忘れていました。

Fowlerの著書「UML Distilled」で説明されているように、コックバーンスタイルのUML魚、カイト、海面のユースケースを利用する方法があると思います。私のアイデアは、コードを読みやすくするための助けとして、Cockburnの使用例を採用することでした。

だから私は実験を行い、タグ「UML」または「FOWLER」の付いた投稿がここにあります。それはc＃の単純なアイデアでした。Cockburnのユースケースをプログラミング構造の名前空間に埋め込む方法を見つけてください（クラスおよび内部クラスの名前空間など、または列挙に名前空間を利用することによって）。これは実行可能でシンプルなテクニックかもしれないと思いますが、それでも質問があり、他の人がチェックする必要があります。言語拡張なしでc＃コードの真ん中に存在できる一種の疑似ドメイン固有言語を必要とする単純なプログラムに適しています。

興味のある方は是非チェックしてみてください。ここに行ってください。

UMLで私が抱えている問題の1つは、仕様の理解可能性です。特定の図のセマンティクスを本当に理解しようとすると、メタモデルとメタメタモデルの迷路ですぐに迷ってしまいます。UMLのセールスポイントの1つは、自然言語よりもあいまいさが少ないことです。ただし、2人以上のエンジニアが図を異なる方法で解釈すると、目的に失敗します。

また、いくつかのUMLフォーラム、およびOMG自体のメンバーにスーパー構造ドキュメントに関する特定の質問をしてみましたが、結果はほとんどまたはまったくありませんでした。UMLコミュニティは、それ自体をサポートするのにまだ十分成熟しているとは思いません。

学生から来たので、UMLはほとんど使用されていません。皮肉なことに、あなたが言ったものを自動的に生成するプログラムを開発者がまだ開発していないことが必要です。Visual Studioに機能を設計してデータの一部を引き出し、定義を求め、製品の回答が十分であるため、誰でもその機能を大小問わず、プログラムを理解できるようにすることは非常に簡単です。また、コードから直接情報を取得して情報を生成するため、最新の状態に保つこともできます。

UMLは一種のUMLダイアグラムですが、UMLはフィールドとメソッドでクラスを表すとすぐに使用されます。

UMLの問題は、創設者の本が曖昧すぎることです。

UMLは単なる言語であり、実際にはメソッドではありません。

私については、オープンソースプロジェクトのUMLスキーマの欠如に本当に悩まされています。Wordpressのようなものを取り上げてください。データベーススキーマだけがあり、他には何もありません。全体像を把握するには、コーデックスAPIをさまよっている必要があります。

UMLがその場所にあります。プロジェクトの規模が大きくなるにつれて、それはますます重要になります。実行時間の長いプロジェクトがある場合は、すべてをUMLで文書化するのが最善です。

UMLは、大規模なチームで構成される大規模なプロジェクトに適しているようです。しかし、私はコミュニケーションがより良い小さなチームで働いてきました。

特に計画段階では、UML風の図を使用することをお勧めします。私はコードで考える傾向があるので、大きなスペックを書くのは難しいと思います。私は入力と出力を書き留めて、開発者がビットを途中で設計するようにします。

UMLは、人々がクラス間の関係について考えるようになるという事実だけに役立つと思います。そのような関係について考え始めるのは良い出発点ですが、それは間違いなく誰にとっても解決策ではありません。

UMLの使用は、開発チームが作業している状況に対して主観的であると私は信じています。

私の経験では：

意味のあるコード図を作成して伝達する能力は、新しいコードを開発している、または既存のコードを理解しようとしているソフトウェアエンジニアにとって必要なスキルです。

UMLの詳細（破線または円の端点をいつ使用するか）を知ることは、それほど必要ではありませんが、知っておくとよいでしょう。

UMLは次の2つの点で役立ちます。

• 技術面：多くの人（マネージャーと一部の機能分析者）は、UMLは贅沢な機能であると考えています。これは、コードがドキュメントであるため、デバッグして修正した後でコーディングを開始するためです。UML図とコードおよび分析を同期すると、顧客の要求をよく理解する必要があります。

• 管理面：UML図は、不正確な顧客の要求のミラーです。UMLなしでコーディングすると、何時間もの作業の後に、要求にバグが見つかる可能性があります。図UMLを使用すると、考えられる論点を見つけ、コーディングの前に解決することができます=>計画に役立ちます。

一般に、UMLダイアグラムのないすべてのプロジェクトは、表面的な分析があるか、サイズが短いです。

linkedinグループのSYSTEMS ENGINEERSに参加している場合は、以前の議論を参照してください。

結局、UMLはRUPのためにのみ存在します。Java / .Netを使用するには、UMLまたはそれに関連するものが必要ですか？実際的な答えは、彼らが独自の文書（javadocなど）を持っていることです。これは十分であり、私たちの仕事を終わらせることができます！

UML no thanx。

junitが不可欠であるのと同様に、UMLは間違いなく役に立ちます。それはすべて、アイデアの販売方法に依存します。単体テストなしで動作するのと同じように、プログラムはUMLなしで動作します。とは言っても、コードに接続されている状態でdo UMLを作成する必要があります。つまり、UMLダイアグラムを更新するとコードが更新され、コードを更新するとUMLが自動生成されます。それをするためだけにやらないでください。

UMLは間違いなく業界でその位置を占めています。Boingの航空機やその他の複雑なシステム用のソフトウェアを構築しているとしましょう。UMLとRUPは、ここで非常に役立ちます。

UMLは、人々のコミュニケーション手段の1つにすぎません。ホワイトボードは良いです。