3

そこで私は学校の課題に取り組んでおり、(ドメイン モデルを使用して) 人々の家に完全な食料品の袋を届ける Web ショップをモデル化することになっています。( http://www.linasmatkasse.se ). ここでもっと具体的にできればいいのですが、残念ながらこれがすべてです。

ユースケースは受け取っていませんが、シナリオは、カートにバッグを追加し、アカウントを作成/情報を追加し、支払いを行うようなものです。

これは私がこれまでに持っているものです: http://i.imgur.com/BIljBtj.png?1

ここに画像の説明を入力

  1. 冗長性はありますか？(サイトのモデルを描写するだけでよいので、どれだけ含めるかはわかりません)。
  2. たとえば、Customer と Account、Cart と OrderLineItem、Order と Cart の間に構成を追加できますか?
  3. 一般的に、属性と多重度についてはかなり不確かです。ここでのフィードバックやサポートは大歓迎です。
  4. 支払いクラス？必要ですか？支払い方法を含める必要がありますか？
  5. サポートのような人間の要素をモデル化する必要がありますか?
  6. 配信をもっとモデル化する必要があります
  7. 顧客と注文の関連付けは必要ですか?

本当にありがとう！また...

4

1 に答える 1

5
  • クラス図である必要があります。したがって、「has」、「contains」などの動詞は集合体として表示され、「supplies」、「desscribes」、「makes」は、これらの名前がソース内の属性の名前である場合にのみ、関連付けの矢印に表示されます (矢印) クラス。「owns」は、関連付けの最後にドットとして表示する必要があります。また、アソシエーションの最後に属性名を実際に配置します。アソシエーション全体に名前を付けることができますが、これは、クラスのインスタンスがなくても、アソシエーション自体が何らかの形で存在することを意味します。コメントを書きたい場合は、メモに配置する必要があります. しかし、通常、ユースケース図には、「supplies」、「desscribes」、「makes」、「has」、「contains」、「owns」などの単語が表示されます。このロジックについて考えたり、一緒に仕事をしているクライアントや営業マネージャーと話し合ったりする場合は、クラス図とは別にしてください。
  • 構成
    • あなたが非常にうまく作ったアカウントとカートの間のそれ。したがって、カートはそのアカウントの外には存在せず、アカウントにはカートが 1 つしかないことがわかります。したがって、多重度が 1 対 1 の構成は賢明であり、多くの重要な情報を含んでいます。
    • あなたが作った顧客は役に立たない。アカウントのみが必要です。
    • 今まで、OrderLineItem と ItemList の使用法を理解していません。一部のクラスの使用が明らかでない場合、それは悪いことです - 少なくともそこにコメントを入れるか、本当に必要な場合は考えてください。
  • お支払い - はい、必要です。支払い方法については、特定の Enumeration クラス ブロックに配置し、そこでアイテムとして名前を付け、Payment を PaymentMethods に接続します。
  • ここには人間の要素はありません！あなたはコーディングの境界で、IT モデルに深く関わっています。あなたは本当にユースケース図を作りたいと思いませんか?

  • 配達？おそらく、Account、Order から見られる配送方法とサプライヤー、ClientAddress の列挙が増えるでしょう。このスコープをカバーするか、そのスコープをカバーするかを決定するのはあなたです。

  • ItemDescription は Item のみに接続する必要があります

  • すべての関連付けは、両方の方法でナビゲートできます。無意味です。操作性を選択します。

  • クラス属性が別のクラスのインスタンスである場合は、関連付けのもう一方の端 (分類子が所有する端) にドットを付けます。

  • サプライヤーは注文に接続されていますか? 仕入先との取引もテーマに取り上げませんか？次に、そのテーマに関するクラスがさらにあるはずです。また、別のコンポーネントや別のクラス図である可能性もあります。それともグラフィックエラーですか？

于 2014-02-05T08:47:55.810 に答える