実装前または実装後にクラス図を作成する必要がありますか？

利点を得る前に作成する場合の見方：

• 前もって計画
• プロジェクトの概要

しかし、あなたは失います：

• 時間（コードを書くときにおそらく繰り返される作業を行う）

一方、将来の開発者のための参照として保持するために、コードを書いた後にそれらをすべて作成することもできます。

どちらがクラス図の目的に役立ち、どれがより有利ですか？

以前に作成した場合、それらは設計段階の一部になります。

後で作成する場合は、ドキュメントに使用できます。ただし、設計およびコーディング中に文書化を行うと、文書化の効率が向上します。

ちなみに、デザインをするのに時間を無駄にしないでください！コーディング部分が高速になります。そしてより良い。

結局、超高層ビルや橋の設計を行うことは、単に構築を開始するのではなく、時間の損失だと思いますか？

妥協点は、設計段階（クラス/関数のプロトタイプのみ）でダミーコードの作成を開始し、このコードスケルトンを使用してクラス図を作成することです。

コーディングする前にそれらを作成した場合、それらを「一時的な」ドキュメントと見なします。つまり、図を作成し、紙に考えを入れます。これらのクラス図からコーディングを開始します。それからそれらを捨てます。コーディングが開始されたら、それらを維持するために時間を費やす価値はありません。また、最新のクラスモデルが必要な場合は、ツールを使用してコードからモデルを作成します。

どちらの場合でも、ドキュメントの一部としてそれらはそのまま使用されます。実装に変更が加えられても、誰もそれらを更新しません。ダイアグラムには日付が含まれないため、参照するコードのバージョンもわかりません。新しい人がプロジェクトに追加されると、「設計または実装中のある時点で作成された図があります。それらがどれだけ最新のものかわかりません。」という図を彼に渡します。

これは設計の一部であるため、実装前に作成する必要があります。これは、現在の実装状態を反映するために、実装中/実装後にそれらを改良できないということではありません。

実装後にデザインを提供することは、私が「カウボーイコーディング」と呼ぶものであり、野生の西部で繁栄することができますが、カウボーイは通常、ある時点で死んでしまうことを忘れないでください。

デザインの深さに依存します。何人かの人々は、「それは良い習慣だから」最も些細なクラスでさえクラス図を書くことを主張します。実装方法を正確に知っている場合、何かを描くのは時間の無駄だと思います。なじみのない新しいデザインを作成する場合、最初にいくつかの図を描くことは間違いなく便利です。

ただし、UMLツールは使用しません。これは、通常、実装中に設計が大きく変化するため、ダイアグラムを再描画する必要があるためです。良い双方向ツールがこれらの変更を処理すると思いますが、良いものを使用したことはありません（ただし、無料のもののみを使用しました）。代わりに、紙またはホワイトボードに描いて、デザインを整理しやすくします。実装し、それが適切であると合理的に確信した後、より正式な図を作成します。

また、他のタイプの図も忘れないでください。シーケンス図は最も便利なものの1つであることが常にわかっており、コンポーネント間の通信が多い場合によく使用します。

実装前。前の同僚の一人がかつて「コーディングを始める前に、できるだけ多くのプログラミングをしたい」と言っていたので、それは良いアプローチだと思います。

ダイアグラムを描く行為は、通常、情報が不足していることを警告します。これは、ダイアグラムを描画せずにコードエディタで入力するだけでも発生しますが、インスタンスはさらに間隔を空けて配置されるため（アルゴリズムや計算、テストなどの作成に時間を費やすため）、不足している情報を取得する前に確認してください。

また、頭の中に漠然と持っているデザインががらくたであることが判明した場合、最初に図を作成すれば、より迅速にそのことに気付くでしょう。したがって、私は少なくとも何かを素早く非公式に描きます。他の人が参照に使用できる電子図に変わるかどうかは、プロジェクトによって異なります。

モデルはコードおよび要件の変更と対話型である必要があるため、クラス図の作成中および実行後にクラス図を作成する必要があります。まず、プロジェクトを開始するためにクラス図を作成する必要があります。オブジェクトをより高いレベルの抽象化で視覚化すると役立ちます。安定したインテリジェントなソフトウェアアーキテクチャを作成できます。次に、コーディングする必要があります。UMLでうまく機能しているように見えるアーキテクチャは、コードでは実際には不可能であることに気付くでしょう。次に、コードとアーキテクチャを変更します。最後に、コードを修正してモデルを更新し、ドキュメントを生成します。

前回のプロジェクトで、意思決定者は昨年、私の要件を50回以上変更しました。それは本当に苦痛であり、UMLは変更の追跡可能性とその理由を維持するのに役立ちます。UMLは、モデルとコードをいつでも反復的に（たとえば、コードからモデルへ、モデルからコードへ、両方から、リファクタリング後のコードからなど）マージできるようにする必要があります。このツール。私のお気に入りの機能はモデルのマージです。これにより、モデル情報を失うことなく、いつでもモデルを更新できます。また、クラス図で直接モデリングするエンティティが好きで、ステレオタイプと休止状態を使用してデータベースを作成します。オブジェクトからデータベースまで本当に強力で完全な!!

前：考えを整理し、意図を伝えるのに役立ちます。ここでは詳細に触れないでください。

後：ビルドプロセスの一部としてコードから自動的に生成されます（明らかに、あなたはumlに執着していません）

どちらも便利ですが、前のものは実装されるとすぐに捨てることができます...この時点ではすでに時代遅れです。

Topcased、私は設計段階で私のクラス図を作成します。次に、「コードの生成」ボタンをクリックして、実装のキャンバスを作成します。次に、プレースホルダーにコードを入力します。

私は答えに投票するつもりです（C）気にしないでください。

それらはほとんど不要です。個人的には、それらが提供されたときにそれらを見るのを気にしません。

とにかくデザインが変わるので、開発の前にそれらは不要です。また、クラスのデザインが変更されると思わない場合は、すでに手錠をかけられており、将来の自分が問題を適切に解決できないようにしています。既存のクラス図に固執する必要があると思われる場合は、NASAで働いているか、自分で足を踏み入れています。

その後、それらは不要なドキュメントです。少しのコード検査でクラスが何をしているか、またはそれらがどのように関連しているかを理解できない場合、ソフトウェア開発者としてのスキルセットに穴が開いています。

もちろん、この答えは本当に慢で意見が多いようです。しかたがない。

エッフェルと関連ツールを使用すると、これは視点の違いであり、すべて同じ基になるファイルを指します。