0

私はいくつかのソフトウェア モデリング/設計の宿題に取り組んでおり、この特定のユース ケースをコラボレーション ダイアグラムに変換する方法に頭を悩ませています。私はこの優れたチュートリアルを見つけましたが、私が研究しているユースケースでは、類推を見つけることができない「UI」コンポーネントが導入されています。

問題の問題は次のように引用されています。

ユースケース名: 緊急事態の報告 参加するアクター: 警官によって開始され、特派員と通信する イベントの流れ:

  1. 警官は自分の端末の「緊急通報」機能を有効にします
  2. システムは、役員にフォームを提示することで応答します
  3. 担当者は、緊急レベル、種類、場所、および状況の簡単な説明を選択して、フォームに入力します。警官はまた、緊急事態への可能な対応についても説明します。フォームが完成したら、現場担当者がフォームを送信します。
  4. システムがフォームを受け取り、特派員に通知します。
  5. 特派員は送信された情報を確認し、データベースにインシデントを作成します。コレスポンデントは応答を選択し、レポートを承認します。
  6. システムは、承認と選択された応答を担当者に表示します。前提条件: 担当者がシステムにログインしている 事後条件: 担当者が応答者から確認応答と選択した応答を受信した、または担当者がトランザクションを処理できなかった理由を示す説明を受信した。

私が理解しているように、コラボレーション図の関連付けは、オブジェクト間のメッセージの流れを示しており、オブジェクトがモデル化するものの物理的な関係を必ずしも反映しているわけではありません。その場合、どのオブジェクトが newEmergencyForm() メソッドを担当し、どのオブジェクトがそのメソッドを呼び出す必要があるのでしょうか? newEmergencyForm() メソッドと reportEmergency() メソッドを 1 つにまとめることができませんでしたか?

4

1 に答える 1

1

  • 現在 (現在の UML 標準は 2.4.1 です)、この図はコラボレーション図ではなく、コミュニケーション図と呼ばれています。コラボレーションは一部の図の要素として残っていますが、別の意味があります。

  • 私が理解しているように、Report Emergency はフォームに記入しています。そして newEmergencyForm は入力するフォームを提供しています。これらは 2 つの異なるアクションであり、それらの違いは既にわかっているため、この違いに気付かずに 1 つの操作としてカウントする必要はありません。しかし、なんらかの理由で、後の図の件名の表示を延期したい場合は、そうすることができます。基準に反するものではありません。

  • これらのメッセージを作成するものを「オブジェクト」とは呼びません。このレベルの抽象化では、むしろコンポーネントについて話します。

  • すべてのコンポーネントを定義するまで、どのコンポーネントがメッセージを作成するかはわかりません。頭の中でそれを行うことができますが、それは問題ありませんが、選択についてはお手伝いできません。「システム」とは？(このレベルでは、システム全体について話すのではなく、ユースケースの用語です。「対応者」とは何ですか? オフィサーと同じですか、または同じにすることができますか? それともサブシステムですか? 他にどのようなコンポーネントがありますか? ?

  • それ以外の場合は、コンポーネント図をソースとして提供する必要があります。ところで、すべてのコンポーネントを正しく定義した後、自分で解決策を見つけることができると確信しています。

于 2014-04-05T20:51:16.493 に答える