複数の俳優が俳優 - ゴールリストの同じ目標を共有するべきか

Question

Craig Larmanは、俳優[/ユーザー] - ゴールリストをいくつかのテーブル/グリッドの形で作成すると、要件分析中にユースケースを見つけるのに適しています。 （UMLとパターンの適用 - P. 69 ff）

いくつかの単純な2列テーブルは、この例の良い概要を提供するのに十分なはずです。以下の俳優・目標のリストを想像：

ActorGoal

AdminCreate User
" Read User
" .. (full CRUD)
" CRUD Entry
" Assign Entry (to User)
" ..

User Create Entry
" .. (full CRUD)
" CRUD himself?
" ..

管理は何ができるかユーザーすることができます+よりS ystem UファインダーD evelopmentのユーザーを管理したり、それらにエントリを割り当てるように。

管理者とユーザーが明らかにいくつかの目標を共有しています（「ユースケース」という用語を使用できますか？）。

ここで、このアクター - ゴールリストを洗練するという観点から、どこから行くべきかわかりません。

私の脳は、私がここに再利用/抽象化ことで、時間と労力を惜しまできることを私に伝えますので、私は最も可能性の高い管理がで機能を拡張しているCRUDエントリに動作を実装する一つの共通のスーパークラス、で終わるだろうゴールを管理する（CRUDユーザー、割り当てなど）。

しかし、これはむしろDesign than Analysisの問題です。
私は、これを孤立して使うためにユースケースを書くこともできることを知っています。私はそれを正確に使用する人を述べる必要はありません、特定の契約[インタフェース]を守っているエンティティであることを知る必要があります。

抽象化について考えるときはいつですか？
私はこれを今行うことで事態を複雑にしていますか？
上記のようなActor-Goalリストを残して、 "Complete"アーティファクトとしてチェックしますか？

俳優、目標リストの古典目的は我々の次のアーティファクトのためのいくつかの簡単な概要を提供することであるから - ユースケース図を - 私たちはここの移行を始めることができる？：

ユースケース図を作ります部分を再利用することは、はるかに目に見える（少なくとも私にとって）。今すぐ冗長性を採用し、後の段階（設計など）でそれを処理することをお勧めしますか？

あなたのご意見をお待ちしています！

EDIT：また、私は自分自身をCRUDingユーザーについてはかなりよく分からない..しかし、物事をシンプルに保つと、メインの質問に固執することができます。

Answer 1

あなたが説明したように、アクター - ゴールリストの候補ユースケースを特定することは、優れたアイデアです。

問題は現実の生活では

をユースケースを識別する際の要件の誘発時にリストを起草するとき、あなたはすぐに整合性の問題が発生します：

• いくつかのインタビューのユーザー/ビジネスの専門家を意志（システム機能に対応する）非常に詳細なステップバイステップのゴールを記述しますが、したがって、各ユースケースのgoal levelを識別するには3番目の列が必要です。

• 用語とユーザーの目標は、常に均質な方法で表現されるとは限りません。したがって、クロスチェック、およびユースケースの名前の変更が必要になることがあります。例えば、私が持っていたシステム：

  • 管理者がmanage authorizationsに主張し、ビジネスユーザーがmanage authorizationに主張しました。それは同じユースケースでしたか？いいえ：システム内の最初のmaintained assignment of authorizationsと2番目のシステムは管理者からdecide on authorizations assignment and request themに権限が与えられたようです。
  • 買い手は、請求書を支払う前に、購入注文に対して誰かがregister a good receiptを持っていると説明しました。倉庫係は、倉庫ではmanage stock movementと説明しました。後で、それは、それらの動きが良い領収書、良い問題、株式が移動するところに現れたようだ。

だから、メインの変種についてのコメントのための4番目の列には、概要を維持するのに役立つ可能性があり、かつ隠された共有の可能性を発見します。

ユースケースを共有/再利用する前に、一般的に十字チェックと調和が行われます。再利用が速すぎると、予想以上に時間がかかりすぎる可能性があります。

ダイアグラムユースケース

私は今、非常に挑発的になります：あなたはすべての俳優とユースケースといいと一貫性のあるテーブルを持っていたら、何を使用すると、ユースケース図から期待利益となります？

一般に、not to abuse use case diagrams for functional decomposition（also here参照）が推奨されます。したがって、ユースケース図はあなたが既にリストにあるものに少しだけ追加します。

さらに、<<Include>>,<<Extend>>と一般化関係は、図をすぐに理解しにくくする傾向があるためほとんど使用しないでください。

最後に、抽象化と再利用は実際にユースケースのレベルで行われますか？これはシステム外のアクターには関係がありますか？そうでない場合は、設計と実装の詳細です。だから私は、ユースケースを実装するために作成（または派生）するクラスモデルでこれらをさらに検討することをお勧めします。