ユースケース図の本質

Question

学校の課題では、ユースケース図を作成する必要があります。しかし、私たちが持っているドキュメントはあまり拡張されていません。ユースケースがどのコンポーネントで構成されているか、および1つの例を説明するだけです。
ライブラリシステムに関するユースケースを作成する必要があります。 11のユースケースが見つかりましたが、それらすべてについて気にすることはありません。

IIRC、ユースケースはシステムの典型的な使用法を説明していますよね？しかし、ユースケース図にはどのようなものが含まれており、それらはどのように結び付いていますか？

現在、4つのアクター（メンバー、従業員、マネージャー、会計士）がいます。最も問題があるのはメンバーと従業員です。
従業員は、システムを使用している人です。メンバーはまだ俳優としてここに属していますか？

私たちが持っているいくつかのユースケース：

• メンバーがライブラリに参加します。
• メンバーは記録を変更します。
• メンバーは本を借ります。
• メンバーはライブラリを分割します（購読解除）。
• メンバーが記事を予約します。
• メンバーは本を返します。
• メンバーは、料金と罰金の一部を支払います。

これらは図のユースケースになります。しかし、従業員がmembernumberを入力する、従業員がbooknumberを入力するなど、さらにユースケースがあるはずです（使用しますか？）。

誰でもこれに光を当てることができますか？

編集： 一連のアクションはどのように記述されますか？私はあなたが再帰するある種のルーチンへのメソッド呼び出しのようなuses関連付けを見ることができると言われましたこれは正解？そして、拡張はどのように使用されますか？

Answer 1

  

IIRC、ユースケースは典型的な   システムの使用法ですよね？しかし、何   thin [g]はユースケース図に属し、そして   どうやって接続するのですか？

ユースケース図（はい、典型的なプロジェクトには複数あります）は、おそらくUMLスイートの中で最も単純な図です。システムのユースケースに直接定義したアクター/ロールをマップする必要があります。実際、彼らは主に単一のアクターに焦点を合わせ、特定のユースケースに参加する必要がある場合にのみ他のアクターを含める必要があります。

Googleから降りた例を次に示します。

ユースケース図のサンプルhttp://java.sun.com /mailers/newsletters/fundamentals/img/usecase.png

単純さに注意してください。 1つのアクター、1つのシステム、5つのユースケース。他に何もありません。

また、 @Eric P が提案したように、私のサンプル画像つまり、ユースケースに＆quot; [動詞] [オブジェクト]＆quot;というタイトルを付ける必要があります。構造;つまり、「メンバーが本を借りる」 「借用帳」になります。ユースケース文の欠落している件名（「メンバー」）は、ユースケースに関連付けられたアクターとしてユースケース図にエンコードされます。

  

従業員は使用している従業員です   システム。まだメンバーはいますか   ここに俳優として属しますか？

その答えは主観的なものだと思います。システムが従業員によってのみ使用されているため、従業員が唯一のアクターであると言う人もいます。個人的には同意しません。

なぜですか？たとえば、ユースケースは要件収集フェーズの一部です。これらは、システムの最終的な機能を整理するのに役立ちます。しかし、技術が Member によって使用されないというあなたの現在の信念のために、単に Member アクターを拒否することは、その段階で自分自身を制限することです。

最終的なシステムが 自動化された場合、つまりメンバーが端末に行き、本をチェックアウトするとどうなりますか？要件の収集中に仮定を行った場合、重要な機能を逃す可能性があります。

  

編集： アクションのシーケンスはどうですか   説明？私はあなたが見ることができると言われました   メソッド呼び出しのような関連付けを使用します   再発するある種のルーチンに？   これは正解？そしてどのように拡張されます   使用されていますか

ユースケース図は高レベルです。彼らはあなたの高レベルの機能（各ユースケースの形で）とそれらを利用するアクタのみを表示するべきです。ユースケース図に拡張とインクルードを散らかさないでください。それらはまれで、特別な場合のみであるべきです。あなたが犯す可能性のある最大のルーキーの間違い（そして私はそれをやったと信じています！）は、ユースケース図内でコードをモジュール化することです。はい、私は知っています、それは彼の塩の価値があるプログラマーが最初にやろうとすることですが、ユースケース図はそれのための場所ではありません。

アクションのシーケンスについて：UMLダイアグラムの典型的なスイートでは、各ユースケースに1つ以上のアクティビティ図。これらはフローチャートにほぼ類似しており、ほとんどのソフトウェアエンジニアリングの教科書で推奨されている典型的なユースケースの物語構造のグラフィカルな表現として機能します。

とにかく、これが役立つことを願っています。他に質問がある場合は、お気軽にお問い合わせください！

Answer 2

ユースケース図への全員のアプローチは少し異なると教えられたので、これがあなたに当てはまるかどうかはわかりませんが、俳優は一般的にシステムに直接接触する人です。そのため、メンバーは従業員を通過する必要があるため、自分のライブラリカードなどをスキャンしない限り、俳優にはなりません。

ユースケースはすべてをカバーする必要がありますが、あまり詳細にはなりません。そのため、従業員はメンバーシップをチェックし、存在しない場合はメンバーシップのユースケースを作成し、そうでない場合は未払い料金をチェックします。メンバーシップが良好な場合、本をスキャンするなど。

Answer 3

あなたはユースケースが何であるかをはっきりと理解しているようです。正しい方向に進むためのリソースを次に示します。

• ユースケース-はじめに
• UMLユースケース図

Answer 4

アクターはシステムを使用している人であるため、システムを使用しているのが従業員だけである場合は、アクターでなければなりません。たとえば、従業員とマネージャーの両方が機能を使用できる場合、複数のアクターを使用することもできます。

したがって、ユースケースを「新しいメンバーを追加」、「メンバーアカウントを変更」などのように言い換えることができます。

詳細レベルについては、「技術」を取得せずに、できるだけ多くの詳細を含めます。ブランドンの提案はかなり良いものです。