私は自動車販売店のビジネス ドメイン モデル/UML クラス図に取り組んでいます。
私はモデリングが初めてなので、クラス図を検証する方法を知りたいです。さらなる開発 (ユースケースなど) を使用するために、100% 正しいとまではいかなくても、適切なクラス図を作成することは、私にとって非常に重要です。
完全に間違ったモデルを構築することは可能ですか? それとも、適切なモデルとあまり適切でないモデルしかありませんか?
SalesTeam がサービスを提供している顧客をモデル化している SalesTeam に関連付けられた Customer がある場合、それは間違っていますか? Customer が Order に関連付けられている例、Order が ItemOrder に関連付けられている例、ItemOrder が ItemInventory に関連付けられている例を見てきました。SalesTeam または Staff が Order に関連付けられている場所。
モデルと関係を検証するにはどうすればよいですか?
ドメイン モデルを検証するには、次の手順を実行します。
ユースケースを書く。執筆中は、名詞と動詞を一貫した方法で使用していることを確認してください。名詞が意味を成していることを確認するには、必ずドメイン モデルにメモを記録してください。
ドメイン モデルに沿って、各ユース ケースについて説明します。そこの実体で？ナビゲーションに必要な関係? 各エンティティの属性?
これはドメイン モデルであるため、物事をクラスとして記述しないようにしてください。クラスは通常、実世界のエンティティです。
たとえば、「営業チーム エンティティと直接的な関係にある顧客エンティティ」は、ユース ケースから学ぶものです。たとえば、顧客は注文に関連付けられていますが、注文は営業チームによって作成されます。したがって、顧客と注文の間には、直接および営業チーム経由の 2 つのナビゲーション パスがあります。どちらも（私には）真実のように見えます。
ドメイン モデルとユース ケースを比較して、両方が一致していることを確認する必要があります。
簡単に言えば、これはあまり重要ではありません。
ドメインクラス図を使用して、ドメイン内にあると思われるものを書き留めます。それだけです。それはあなたの神ではありません。
ドメインの専門家は、ドメイン モデルの検証を支援する必要があります。
特定の関係を検証する限り、モデルをさらに開発し、オブジェクト間のコラボレーションを調査すると、より多くの異なる関係が発見されます。分析および開発中に、ドメイン モデルを頻繁に再確認する必要があります。
前もって（つまり、ユースケースとさらなる分析に移る前に）それが「正しい」かどうかは問題ではないと思います。それが役立つことだけです-問題の概念モデルと主要なクラスが何を含んでいるかを示しますそれは。ソフトウェアが開発または保守されなくなるまで、それは終了しません。
それが現在の問題の見方を表している場合は、さらに分析を開始するのに十分です。問題に対する見方が変わり、より多くのことを学べるように、それを修正してください。