2016-09-13 10 views
2

私は確かに、ユースケースダイアグラムを使用してすべてのクライアントの要件を文書化しています。私は設計パラダイムで新しいです。私は全体的なシステム要件を含む高レベルのユースケース図を持っています。そして、私は、それぞれのユースケースの詳細レベルのユースケース図を高レベルのユースケース図で定義しています。さて、詳細レベルの図では、システム自体も同様にトリガするようなケースを含めました。詳細レベルのユースケース図の作成

高レベルのユースケース - アップロードレポートのアップロードレポートファイルのため

詳細レベルのユースケースファイル:上の図ではここ

enter image description here

、ユースケース1.3、1.4および1.5は、システムからのトリガとこのですユースケースはユーザーと直接対話しません。

私の質問は、これらのタイプのシステムレベルのユースケースを詳細のユースケース図に含めるか、ユーザーとのやりとりだけを行うユースケースを含めるべきかということです。

P.S.私が上でやっていることが有効でないなら(あなたが私の推薦図を表示しているように)、私はあなたの推薦をしたいと思います。

+0

Bittner/Spenceを読むことをお勧めします。ユースケースを作成するのではなく、機能的な分解を試みています。 –

+0

よろしくお願いします。私はちょっと、私が何らかの機能的な方法で制作しているユースケースを感じています。とにかく、代わりに私が何をすることができるか教えてくれれば幸いです。あなたは私のケースのための解決策を私に提供できますか?その間に、私はあなたのお勧めの本を勉強します。 –

答えて

1

まあ、実際には答えではなく、アドバイスです。ここでの問題は、これまでのところあなたのデザインをダンプして最初から始める必要があるということです。それはもちろん不可能です。したがって案内として:

  • 機能性ではなく付加価値を探します。
  • (!)include/extendを使用せず、アクターとユースケースの単純な関連付けを描きます。
  • 各ユースケースについて、自分自身に質問してください。その付加価値ですか?答えが「はい」の場合にのみ、バブルを追加します。
  • 名動詞/件名の各ユースケース(そして最終的にオブジェクト)
  • のみを使用し、メインの俳優や、あなたの図の中の任意の二次役者を離れて去ります。
  • あなたのUC図がスパイダーウェブに似ていると、デザインが壊れている可能性があります。
  • 絶対数はありませんが、通常は少数の俳優と数十のUCで終了します。
+0

あなたの答えは本当に非常に明確で有益です。どうもありがとうございました。 –

関連する問題