uml - UML は実用的ですか?

Question

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

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

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

score 91 · Accepted Answer

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

それはあなたがしていることだけではありません。今から6か月後に来て、コードを理解する必要がある新入社員はどうですか？現在プロジェクトに取り組んでいる全員がいなくなってから5年後はどうでしょうか。

後でプロジェクトに参加するすべての人が利用できる基本的な最新のドキュメントを用意しておくと、非常に役立ちます。メソッド名とパラメーターを使用した本格的なUML図（保守が非常に難しい）は推奨しませんが、システム内のコンポーネントとその関係および基本的な動作の基本的な図は非常に貴重だと思います。システムの設計が大幅に変更されない限り、実装が微調整されても、この情報はそれほど変更されないはずです。

ドキュメントの鍵は節度であることがわかりました。数ページで眠りにつくことなく、設計ドキュメントを含む本格的なUML図の50ページを読む人は誰もいません。システムがまとめられています。

UMLが役立つと思ったもう1つのケースは、上級開発者がコンポーネントの設計を担当し、その設計を後輩開発者に渡して実装する場合です。

score 50 · Accepted Answer

十分に複雑なシステムUMLでは、一部が有用であると見なされる場所がいくつかあります。

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

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

多くの企業がそれらに誓いを立てており、多くの企業はそれらを時間と労力の完全な無駄として完全に拒否しています。

やり過ぎず、自分が取り組んでいるプロジェクトに何が最適かを考え、適用可能で理にかなったものを選ぶのが最善です。

score 36 · Accepted Answer

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

例外は、たいまつなしで夜に森の中にいることに気づき、雨が降り始めた場合です。その場合、転落しないように足元に注意する必要があります。引き受けたタスクが直感では処理できないほど複雑な場合があり、速度を落としてプログラムの構造を明示的に記述する必要があります。UML は、使用できる多くのツールの 1 つです。その他には、疑似コード、高レベルのアーキテクチャ図、奇妙な比喩が含まれます。

score 19 · Accepted Answer

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

score 16 · Accepted Answer

UML はいたるところで使用されています。IT プロジェクトが設計されているところならどこでも、UML は通常存在します。

さて、それがうまく利用されているかどうかは別問題です。

Stu が言ったように、ユースケース (ユースケースの説明と共に) とアクティビティ図の両方が、開発者の観点から最も役立つと思います。

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

UML の最大の問題の 1 つは、コードが生成されると、UML を最新の状態に保つために必要な作業量です。コードから UML を再設計できるツールはほとんどなく、それをうまく実行できるツールはまだほとんどないためです。

score 13 · Accepted Answer

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

私がUMLとRationalUnifiedProcessを見る方法は、実際にやろうとしていることをやるよりも、やろうとしていることについて話しているということです。

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

score 13 · Accepted Answer

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

score 10 · Accepted Answer

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

教室の外での私の時間と同様に、授業時間は限られていました。そのため、毎回のクラスミーティングでコードレビューを実施する必要がありましたが、25 人の学生が在籍しているため、個々のレビュー時間は非常に短かったです。これらのレビューセッションで最も有用であることがわかったツールは、ERD、クラス図、およびシーケンス図でした。ERD とクラスダイアグラムは Visual Studio でのみ作成されたため、作成に必要な時間は学生にとって取るに足らないものでした。

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

図を使用しなければ、時間をかけて学生のコードファイルを 1 つずつ調べて問題を探す必要があったでしょう。

score 8 · Accepted Answer

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

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

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

議論は、UML がどのような場合に有効であるか、または実際に製品/ソリューションを改善するかについて議論するために、UML がどのように過剰に殺されたり、小さなプロジェクトに適用されたりするかから拡大する必要があります。パターンアプリケーションやコード生成など、1 人の開発者が UML を認識できる状況もあります。

score 5 · Accepted Answer

UMLは私のために何年も働いてきました。私が始めたとき、私はファウラーのUML Distilledを読みました。そこでは、彼は「十分なモデリング/アーキテクチャなどを実行してください」と言っています。必要なものを使用してください！

score 4 · Accepted Answer

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

score 4 · Accepted Answer

この議論は長い間活発ではありませんでしたが、いくつか追加すべき重要な点がいくつかあります。

バグのあるコードは 1 つのことです。下流に流されたままにしておくと、設計ミスが非常に肥大化して醜くなる可能性があります。ただし、UML は自己検証型です。つまり、数学的に閉じた複数の相互チェック次元でモデルを探索できるようにすることで、堅牢な設計が生み出されるということです。

UML にはもう 1 つの重要な側面があります。UML は、私たちの最も強力な機能である視覚化と直接「対話」します。たとえば、ITIL V3 (本質的には十分に単純) が UML ダイアグラムの形式で伝達されていた場合、数ダースの A3 折り図で公開されていた可能性があります。代わりに、それは真に聖書的な割合のいくつかの本で登場し、業界全体を生み出し、息を呑むようなコストと広範な緊張病ショックを引き起こしました.

score 3 · Accepted Answer

UML は便利だと思いますが、2.0 仕様により、かつては明確な仕様であったものがやや肥大化して扱いにくくなっていると思います。空白を埋めたので、タイミング図などの編集に同意します...

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

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

Violet - もっとシンプルにすると、一枚の紙になります
Altova UModel - Java および C# モデリング用の優れたツール
MagicDraw - モデリング用の私のお気に入りの商用ツール
Poseidon - 費用対効果の高いまともなツール
StarUML - 最高のオープンソースモデリングツール

score 3 · Accepted Answer

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

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

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

次の投稿に対する私の回答もお読みください。

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

score 2 · Accepted Answer

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

score 2 · Accepted Answer

UMLは便利です、確かにそうです！私がそれを使った主な用途は次のとおりです。

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

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

score 2 · Accepted Answer

Fowlerが著書「UMLDistilled」で説明しているように、コックバーンスタイルのUML魚、凧、海面のユースケースを利用する方法があるかもしれないと思います。私のアイデアは、コードの可読性を高めるためにCockburnのユースケースを採用することでした。

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

興味のある方は投稿をチェックしてください。ここに行きます。

score 2 · Accepted Answer

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

私はユースケース図を作成するのが好きですが、それが価値があると考える人にあまり会ったことがありません。

Rational Rose は、UML モデルベースの設計から得られる種類のアプリケーションの良い例ではないかと、私はよく考えてきました。肥大化し、バグが多く、遅く、醜い...

score 2 · Accepted Answer

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

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

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

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

score 2 · Accepted Answer

UML に関して私が抱えている問題の 1 つは、仕様のわかりやすさです。特定のダイアグラムのセマンティクスを本当に理解しようとすると、すぐにメタモデルとメタメタモデルの迷路に迷い込んでしまいます。UML のセールスポイントの 1 つは、自然言語よりもあいまいさが少ないことです。ただし、2 人以上のエンジニアが異なるダイアグラムを解釈すると、目標を達成できなくなります。

また、いくつかの UML フォーラムや OMG 自体のメンバーに対して、上部構造ドキュメントに関する具体的な質問を試みましたが、ほとんど、またはまったく結果が得られませんでした。UML コミュニティは、それ自体をサポートできるほど成熟しているとは思いません。

score 2 · Accepted Answer

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

基本的に、何を使用するかは問題ではなく、次の 2 つの点に注意する必要があります。

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

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

1 人の開発者や単純なソフトウェアプロジェクトに UML を使用するのはやり過ぎに思えますが、大規模なチームで作業する場合は、ソフトウェアを計画するための何らかの標準が必要になります。

score 1 · Accepted Answer

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

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

score 1 · Accepted Answer

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

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

score 1 · Accepted Answer

UML にはその場所があります。プロジェクトの規模が大きくなるにつれて、その重要性が増します。長期にわたるプロジェクトがある場合は、すべてを UML で文書化することをお勧めします。

score 0 · Accepted Answer

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

技術面：多くの人（マネージャーや一部の機能アナリスト）は、コードがドキュメントであるため、UMLは贅沢な機能であると考えています。デバッグして修正した後、コーディングを開始します。UMLダイアグラムをコードおよびanalisysと同期すると、顧客の要求を十分に理解する必要があります。
管理側：UMlダイアグラムは、不正確な顧客の要求を反映しています。UMLを使用せずにコーディングすると、長時間の作業の後に、requiresにバグが見つかる可能性があります。ダイアグラムUMLを使用すると、考えられる論争点を見つけて、コーディングの前に解決することができます=>計画に役立ちます。

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

LinkedInグループのSYSTEMSENGINEERSに所属している場合は、私の古いディスカッションを参照してください。

score 0 · Accepted Answer

私の経験では：

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

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

score -1 · Accepted Answer

junit が必須であるように、UML は間違いなく役に立ちます。それはすべて、アイデアをどのように販売するかにかかっています。プログラムは、単体テストがなくても機能するのと同じように、UML がなくても機能します。つまり、UML ダイアグラムを更新するとコードが更新され、コードを更新すると UML が自動生成されます。それをするためだけにしないでください。

score -2 · Accepted Answer

UML は業界でその地位を確立しています。Boing 航空機やその他の複雑なシステム用のソフトウェアを構築していると想像してください。ここでは、UML と RUP が大いに役立ちます。

score -2 · Accepted Answer

結局UMLはRUPがあるからこそ存在する。Java/.Net を使用するには、UML やそれに関連するものが必要ですか? 実用的な答えは、彼らが独自のドキュメント (javadoc など) を持っていることです。

UML いいえ。

score -3 · Accepted Answer

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

score -4 · Accepted Answer

いいえ、そうではありません。コードはコミュニケーションの最良の形態です。それ以外はすべて、間違った業界に入り込み、自分の頭脳に合うように業界を変えることにした人向けです。

インターフェイスは、クラス図よりもはるかに優れています。ユースケース図は、ユーザーの要求を破壊して製品の設計方法を説明する形式にマッシュアップします。データフロー図と ER 図は、データベースの作成プロセスを複雑にします。要点を伝えるためにダイアグラムを描きたい場合もありますが、UML ダイアグラムである必要や、他の人が理解できるという以外の標準に準拠している必要はありません。

結局のところ、これらはすべて、XML を組み込んだひどい製品を作る、大規模で役に立たない官僚的な「ソフトウェア」企業のためのドキュメントの形式です。つまり、文書化が完了した場合です。実際、ほとんどの従業員は自分の仕事に関心がなく、昇進できるように上の人が死ぬのを待っているだけです。

uml - UML は実用的ですか?

31 に答える 31

Related

Reference