現在、Martin Fowler の UML Distilled を読んでいます。クラス図のセクションを取り上げたところで、クラス図をモデル化する前に視点を整理する必要性を強調しています。しかし、実際にクラス図を描くと、これが実際にどのように見えるかについて、私は少し混乱しています。たとえば、理論的な意味合いが、ある視点から次の視点へと関連付けの意味を変えることを理解しています。
私の主な質問は、たとえば、彼が本で行っているように単純な順序付けシステムをモデル化していた場合、クラス図は異なって見え、ある観点から別の観点へと異なる量の表記を含むかということになると思います. たとえば、概念的な観点から、クラスといくつかのあいまいな関連付けとそれらの多様性を示すだけで、仕様の観点でモデル化すると、ナビゲーション機能と基本的なクラス操作とフィールドが含まれます。
この問題をよりよく理解したいので、これについてのガイダンスを本当に感謝します。
良い質問。これは私自身の経験からの考えです。Martin が同意するかどうかはわかりませんが (!)、それでも役立つことを願っています。
要約すると、主な違いは、関係の形式とデザインの選択から生じます。
私は次の便利なことがわかりました：
基本構造: スケッチとして Fowler の UML に大まかにマップし、ホワイトボード上でインタラクティブに作成します。主な目的は、全体の構造を理解することです。非常に非公式。特に、関係に焦点を当てるのは、形式化するのではなく、それらを識別することだけです。したがって、カーディナリティ、削除動作、コンテナ クラスの選択などはありません。
ドメイン モデル。関係の形式化に重点を置いた正確なモデル。具体的には、アソシエーションの名前付け、カーディナリティの定義、および削除動作の確認を行います。カーディナリティが 1 を超える場合、ナビゲート可能性やコンテナー クラスの選択は考慮されません。問題領域を学習するために私が知っている最高のテクニックの 1 つです。
ほとんどの場合、上記の両方を使用します。ドメイン モデルの重要な点は、役割ベースではなく動詞ベースの命名を使用することです。これは、関係が存在する理由を説明するためです (ビジネス ルールが効果的に表面化されます。たとえば、「注文は 1 人の顧客によってのみ行われる必要があります」など)。Simsion & Wittの本に記載されている命名テンプレートを使用します。
ドメイン モデルを実際のコードに変換するには、特にリレーションシップにおいて、やらなければならない作業があります。プログラミング言語はリレーションシップをあまりサポートしていないため、関連付けを参加クラスの属性に変換する必要があります。その時点で、1 を超える多重度のコレクション タイプの選択とともに、ナビゲーション機能が登場します。また、すべての操作を指定する必要がある場所でもあります。個人的には、このタイプの図が特に役立つとは思いません。ドメイン モデルとコードがあれば、必要なものはすべて手に入ります。
実行可能な UML ツールを使用している場合にのみ、「UML をプログラミング言語として」使用します。
それが少しとりとめのない場合は申し訳ありませんが、それが役立つことを願っています...
PS: 動詞に基づく命名のより良い例が必要な場合は、私のブログに投稿があります。それを自己宣伝と見なさないでください。ここで繰り返しても意味がありません。
開発者にアイデアを説明する方法は次のとおりです。
概念は関係です。これは、カップリングが発生するレベルです。概念から実装への結合は見るべきではありません。これは、設計が不十分であることを示しています。
仕様は、実装を定義せずにアルゴリズムを定義します。クラス図では、これは抽象クラスとして表現される場合があります。Alan Shaloway は、この領域に分類されるメソッドを「軍曹メソッド」と呼んでいます。
実装は、実際の作業が行われる場所です。これは、抽象的な仕様を実装する具象クラスによって表される場合があります。
正確には、UML クラス図は、現在のソフトウェア開発フェーズに応じて異なる方法で記述できる (そしてそうすべきである) 表記法にすぎません。クラス、属性、および関連付けのみから始めて、属性の型情報を追加するために図を改良することができます。次に、ナビゲーション、クラスメソッド、関連付けの修飾子...実装フェーズの準備が整った完全なクラス図が得られるまで
アソシエーションを削除して複雑なタイプの属性に置き換えるところまで反復して、最終的な実装にさらに似たクラス図を作成することもできます。各フェーズでクラス図をどのように使用するかは、あなた次第です。
マーティン・ファウラーの本は、彼がクラス図について話し始めるとすぐに、私にとってはがらくたです（たとえば、私の個人的な気持ち）!! 他の図にも同意しますが、クラス図は高レベルの設計だけでなく、より実用的である必要があります。
より高いレベルの抽象化でモデル化し、次に実際に必要なものをモデル化する必要があるのは、常に同じ理論です。実行中のコードをすばやく提供して、顧客に見せたいと思います。その最初の段階から、機能的な要求だけでなくコードも持つためにモデリングを開始します。この第2段階が終了したら、それを顧客に再度示し、実行する必要があることを変更するためのUMLクラス図を再度提供します。10回の反復の後、私のプロジェクトは通常終了します。たとえば、私のプロジェクトは3〜6か月続きます。これは本当に複雑なプロジェクトであり、私の顧客は通常満足しています。マーティンファウラーの推奨を使用すると、私のプロジェクトは12〜18か月で完了せず、顧客は確かに失望するでしょう。