本当にユース ケースに固執したい場合は、エンド ユーザーの視点ではなく、システムの機能の視点からユース ケースを作成します。多分このようなもの：
- システムが起動し、合計変数とカウント変数がゼロになります。
- システムが番号を受け取ります。
- 合計に数値を追加し、カウントをインクリメントします。
- システムが停止するように指示されるまで、ステップ 2 と 3 が繰り返されます。
- 停止するように指示されると、システムは合計をカウントで割り、結果を返します。
Alastair Cockburn の優れた著書「 Writing Effective Use Cases 」を読んでください。さまざまなレベルのユース ケースがあることについて説明します。最初の例はユーザー目標 (または青) のユース ケースと見なされますが、上記の手順はサブ機能 (またはインディゴ) のユース ケースの一部になります (非常に単純なので、黒のユース ケースとして分類され、マージされることさえあります)。その親に)。
他の人が言うように、ユースケースはアルゴリズムを説明する最良の方法ではない場合があり、古き良きフローチャート、状態図、シーケンス図などにフォールバックする必要があります. これらのツールはあなたの利益のためにあります - 特定の方法がうまくいかないときに強制することによって制約されないでください.
編集
@devoured elysium：あなたのコメントに応えて、以下にいくつかのメモを追加しました：
ドメイン オブジェクトを識別する場合、書き込まれていないオブジェクトについて考える必要がある場合があります。それはすべて、それがどのように書かれているかに依存します。したがって、あなたが示した例では、「システム」は「電卓」であり、数値を加算するために使用される変数は「アキュムレータ」であり、数値を受け取る「キュー」がある可能性があります。範囲検証や入力構文チェックなどの明確な動作が可能な場合、数値自体が「数値」型のオブジェクトである可能性があります。考慮する必要がある「表示」オブジェクトはありますか?
それは、あなたが扱っている境界のあるコンテキストにあるとあなたが考えるものに依存します。おそらく、ユーザーの観点からは、「電卓」のみを扱うコンテキストが 1 つありますが、システムの観点からは、「アキュムレータ」、「ALU」、「ビット」、「ワード」などの下位レベルのコンテキストを扱う別のコンテキストがあります。レジスタ」、「クロック」、「ラッチ」など。言語がより技術的になるでしょう。どれがドメイン オブジェクトで、どれが単なる実装オブジェクトであるかを判断する必要があります。それは、記述および構築しようとしているものの種類に大きく依存します (そして、大部分は、対象者が誰であるか、ユビキタス言語などすべてに依存します)。 !)。逆に、「なぜ？」と尋ねることで、スタックを上に行くことができます。機能が実行されています。
サブ機能ユース ケースの主要なアクターは、通常、それを呼び出す上位レベルのユース ケースのアクターと同じです。ただし、一部の「技術的な」ユース ケースでは、主要なアクターはシステム コンポーネント/サブシステムになります。たとえば、システム メッセージ ロギングのユース ケースでは、サブシステムがログを必要とする原因となったタスクを実行していたアクターではなく、主要なアクターとして呼び出しサブシステムを持っている場合があります。なにか。
この例では、アルゴリズムが非常に単純なので、おそらくメインのユース ケースに埋め込むだけです。ただし、他の複数の高レベルのユースケースで使用されている場合は、他のドキュメントから含めることができるようにスタンドアロンにします。単なる機能分解アプローチ。
これには厳格なルールはありません。時代とともに変化していく働き方です。他の人が言ったように、仕事に適したツールを選択できるように、他の形式のダイアグラムに精通していることを確認してください。百聞は一見に如かずということもありますが、実際にはそれらの言葉も必要になる場合があるので、図だけに頼らないでください。