プログラマーは統一プロセスとUMLについての理解をどの程度深める必要がありますか？[閉まっている]

多くの場所でUMLと統合プロセスが開発モデルとして使用されていることは知っていますが、そうでない場所もたくさんあります。これらの主題の基本的かつ機能的な理解以上のものを持っていることが重要でしょうか、それとも他の分野（つまり、言語開発、IDEなど）でプログラミングスキルの開発に集中する方が良いでしょうか？

下水の深いところにある間にペンキが乾くのを見るのが楽しい時間であると思わない限り、統一プロセスは無視してください。待って、それを無視するだけでは十分ではありません。恐れる。私の知る限り、効率、品質、または健全性のすべての希望を超えた巨大な場所でのみ使用されています。

一方、UMLは、プログラミングの重要な概念を表すのに便利です。マーティンファウラーのUML Distilledを入手し、概要を説明し、デザインについて考えながら図のスケッチを練習してください。それは私が定期的に使用するスキルであり、私がそれを持っていることがうれしいです。

人々はUMLを使いすぎようとすることに注意してください。物事を議論しながらホワイトボードUMLは素晴らしいです。公開されたドキュメンテーションの時折の図表はいいかもしれません。しかし、UMLでコードベース全体を文書化するという探求は無意味で無駄です。そして、「UMLでプログラミングする」という欲求はばかげています。そんな人に出会ったら逃げろ。ただし、最初に、額にシーケンス図を付けることで、残りの人に適切な警告が表示されます。

UMLに時間をかけすぎないでください。私のチームでは、UMLを十分に理解しているため、ユースケース、コンポーネント、状態、デプロイメント、およびその他の図を作成するのは私だけです。他のチームメンバーは、私よりコードの方が優れていますが、UMLダイアグラムにはあまり適していません。

私たちが使用する秘訣は、アプリケーションの構造を定義するためにモデリングレベルのクラス図に焦点を合わせ、開発者/アーキテクトが必要に応じてコーディングできるようにすることです。次に、モデルを新しいコードとマージし、反復ごとにモデルを更新します。本当に簡単で非常に効率的です。Omondo EclipseUMLを使用してJavaで開発します。

私にとって本当のがらくたであるどんなMDDも使わないことを勧めます！Modelerは、開発プロセス内でより多くの能力を発揮しようとしますが、モデルからすべてのコードを生成しようとしても、価値はありません。コードは開発者/アーキテクトに属しますが、モデラーには属しません。UMLは、プロジェクト要件（例：ユースケース、シーケンスなど...）、プロセス（例：状態図またはアクティビティ図）、デプロイメント（デプロイメント、コンポーネント図）のビューのみである必要があります。クラス図はコードのビューである必要があり、UMLクラス図はコードのビューアとしてのみ使用する必要があります。Javaコーディングはオブジェクトアプローチを尊重する必要があります。オブジェクト言語でもあるUMLは、がらくて愚かなコーディングを回避するのに非常に役立ちます。

最も重要なのは、モデルからコードへのコードとモデルからコードへのクラス図の反復です。ライブ同期という意味ではありませんが、反復ごとにコードとモデルをマージできるようにするためです。私はOmondo EclipseUMLを使用しており、Java、データベースエンティティ、モデルIDをマージできるのはそれらだけだと思います。IDマージは非常に強力なコンセプトであり、アジャイルプロジェクトに最適です。

私の推薦は本を買わないことです。より良いアーキテクチャを作成するには、オブジェクトアプローチを採用し、クラス図言語を使用してオブジェクトを視覚化する必要があります。チームメンバーの1人がUMLを知っている場合は、他の図を使用します。そうでない場合は、クラス図で十分です。

統一プロセスとUMLは、構造化された思考およびコミュニケーションツールのセットです。これらのツールはいくつかの点で役立ちます。デザインについて話し合う方法を定義することと、デザインの詳細や側面に取り組む手助けをすることの両方によって。

自分の考えを改善することは、設計の詳細を完成させ、健全で首尾一貫した製品への道を見つけるために重要です。個人的な専門分野は、集中し、詳細を追跡し、端から端まで考え、数か月後の考えを思い出すのに役立ちます。

設計について話し合う方法と改善する方法を改善することは、設計者のグループをさらに迅速に進めるために重要です。グループの分野は、グループからより多くのものを得るのに役立ちます。

しかし、UMLと統合プロセスは多くの思考ツールの1つにすぎないことを覚えておいてください。それらは妥当ですが、あなたやあなたのグループに合うかもしれないし、そうでないかもしれません（これは他の要素と同じくらい重要です）。

私の頭の中では、UMLを回避する方法があります。本を入手し、それを学びます。あなたはそれが必要です：

• UMLを使用する技術本を読む（たくさんあります）
• それをスケッチツールとして使用して、アイデアやソリューションについて大学と話し合います。
• あなたが考えている解決策を視覚化し、それについて推論する簡単な方法を自分に与えてください。
• 特定の企業での技術/機能設計に関する読み取り/理由

統一されたプロセスは別の話だと思いますが、それはあなたがいる雇用主次第です。私は少なくとも本を読んで、それが何であるか、そしてあなたが本当にそれを研究する必要があるときが来たときに知るでしょう。

お役に立てれば。

UMLについての非常に深い知識は必要ないと思いますが、図を見て、何が起こっているのかをはっきりと理解できるはずです。あなたが詳細な知識を得るために試みるべきであるのは、異なるデザインパターンです（本を購入してください）。独自のデザインを思いついたら、実際にそれを引き出さなくても、デザインパターンとUMLパターンの両方を知るのに役立ちます。また、UMLがどのように見えるのかが少しよくわかるので、UMLダイアグラムを表示したときにそれを理解するのにも役立ちます。

私は1987年からこのビジネスに携わっていますが、UMLやユニファイドプロセスを扱ったのは数回だけです。誇張された、優しい方法論。この純粋ながらくたを適用しようとするあらゆる試みの余波の末、私たちはプロジェクトの設計と開発をひどく遅くすると同時に、議会図書館を溢れさせるだけでなく、ほぼすぐに時代遅れの文書を生成することになりました。

あなたのビジネス製品が紙のポンドやドキュメントのサイズで測定される場合、一度に何度も読まれることはなく（その数が多ければ）、その後永遠に陳腐化し、それがあなたの基礎となります。給料が支払われたら、ぜひこのがらくたを食べてください。

そうでない場合は、UMLとUPの最初の言及で丘を叫んでください。または、それをパルプに向かって発声した最初の人を倒します。

統一プロセスなしでUMLを使用できることについて言及するかもしれません。私はプログラミングと同時にUMLをたくさん使用しますが、私にとっては、「その新しいツール」という理由だけで使用するのではなく、実用的な方法であることが重要です。

クラス図、ユースケース、逐次図が私のお気に入りです。これらの図のように、他の種類の図を頻繁に使用する必要はありません。

多くの企業は統一/合理的プロセスを使用していません。