0

MAKE RESERVATIONSはアクティビティであり、次のように記述されています。

顧客がレンタカーについて予約担当者に連絡します。

顧客は、必要な開始日と終了日、優先車両、および集荷所を見積もります。

予約担当者は価格ファイルを検索し、価格を見積もります。顧客は価格に同意します。

車両の可用性は、適切な車両が必要なオフィスで必要な時間利用可能かどうかを確認するためにチェックされます。

要求された車両が指定された集荷所で利用可能である場合、それは顧客のために予約されています。予約を登録する車両空室状況にエントリが作成されます。

予約担当者は、顧客にレンタル番号を発行します。次に、賃貸契約書が賃貸ファイルに作成されます。これには、賃貸番号、賃貸期間、車種、および集荷所が含まれます。

例外

  1. ピックアップオフィスでは適切な車両が利用できません。顧客には代替車両が提供されます。
  2. 顧客は価格に同意せず、代替車両および/または期間を要求します。

上記のアクティビティのアクティビティ図を設計しましたが、質問を決定ノードに配置する必要があるのか​​、それとも制御フローの上記に配置する必要があるのか​​わかりません。私の場合、Agree to Priceは、決定ノードにあるべきですか、それともノードを入力する制御フロー矢印にあるべきですか？

また、ユースケースで「車両が利用可能な場合は車両が提供され、価格が提示されます。顧客が同意した場合はレンタルが開始されます」などの条件のみが指定されている場合。決定ノードはどのように見えますか？

さらに、3人の異なるアクターがいる場合、アクターを表すスイムレーンが必要ですか、それともアクティビティ図を1人なしで描画できますか？

上記のユースケースのアクティビティ図は以下に掲載されています

予約を取る

4

1 に答える 1

1

質問を制御フローの決定ノードまたはそれ以上に配置する必要があるかどうかわかりませんか？

あなたがしたように、それらはフローに書かれています。UMLでは、決定ノードは空です（これは、ノード内に条件を書き込む基本的なフローチャートとは異なります）。決定ノードからの各フローには、ガード（つまり条件）の注釈を付けることができます。決定ノードが実行されると、ガードがtrueと評価されるフローを実行対象として選択できます（通常、ガードの条件は排他的であり、1つのガードのみを選択できますが、これは必須ではありません）。

また、ユースケースで「車両が利用可能な場合は車両が提供され、価格が提示されます。顧客が同意した場合はレンタルが開始されます」などの条件のみが指定されている場合。決定ノードはどのように見えますか？

図のように見えますが、決定ノードの唯一の目的はいくつかの可能なフローから選択することであるため、決定ノードの前にクライアントに問い合わせるためのアクションノードが必要です。決定ノードの実行の一部としてアクションは実行されません。

決定ノード、前にアクションノードがあります

さらに、3人の異なるアクターがいる場合、アクターを表すスイムレーンが必要ですか、それともアクティビティ図を1人なしで描画できますか？

モデル化する対象によって異なります。システムのさまざまな部分でさまざまなアクションを実行する場合は、スイムレーンを使用できますが（最近ここに例を示しました）、その分離をモデル化するのが面白くない場合は、スイムレーンを避けることができます。通常、アクターはシステムに入力を提供しますが、アクターが単独でアクションを実行することはありません。

たとえば、例では、顧客からの入力（最初の見積もりと契約）に基づいて予約担当者（システムの一部）の動作をモデル化し、顧客は出力（レンタル番号）を受け取ります。サードアクターに重点を置いた別の質問としてそれを尋ねることをお勧めします。

于 2013-03-16T16:19:44.813 に答える