製品要件仕様を作成しています。このドキュメントでは、ユーザーがシステムと対話する方法を非常に高いレベルで説明する必要があります。これらの操作のいくつかは、オブジェクトによっては「作成-読み取り-更新-削除」です。
問題は、これらの操作のユース ケースを作成する場合、どのように行うのが正しいのかということです。「オブジェクト x の管理」というユース ケースを 1 つだけ作成して、これらの操作をユース ケースに含めることはできますか? それとも、操作ごと、オブジェクトごとに 1 つのユース ケースを作成する必要がありますか? 最後のアプローチで私が目にする問題は、問題の理解に実際には貢献しないと感じるかなりの数のページを書くことになるということです。
ベストプラクティスは何ですか?
ユースケースの当初のコンセプトは、アクターやクラス定義と同様に、率直に言ってすべてが継承<<uses>>と<<extends>>関係を楽しむというものでした。
ユース ケース スーパークラス ("CRUD") は理にかなっています。多くのユース ケースは、エンティティ タイプがプラグインされた "CRUD" の簡単な拡張です。
いくつかのユースケースは、"CRUD" の興味深い拡張であり、おそらく、Retrieve の一部としての高度な検索、Create または Update の複数ステップのプロセス、または Delete の複雑な確認のためのバリアント処理シナリオがあります。
継承を自由に使用して、ユースケースを単純化および正規化してください。UML ツールを使用すると、ユース ケースに「継承」矢印が表示されることに気付くでしょう。
答えは、相互作用がどれほど複雑であるか、およびオブジェクトごとに可能なバリエーションの数に大きく依存します。CRUD ごとに特定のユースケースを作成することをお勧めする本当の理由は 2 つあります。
(a) 実際にインタラクションの高レベルの要約のみを行っている場合、オーバーヘッドは非常に小さい
(b) 「リソース」を変更し、特定のオブジェクトの特定のステップを拡張/オーバーライドするための一般的なユースケースのセットを指定すると便利であることがわかりました。明らかに、一般的な動作は一般的な「リソース」のユース ケースに取り込まれています。
ドメインの理解が深まるにつれて (つまり、ビジネス ユーザーがより多くの要件をあなたに投げかけるにつれて)、CRUD を削除するよりも、CRUD に追加する可能性が高くなります。
意味があり読みやすい限り、表現は問題ではないと思います。すべての詳細で UML 仕様に準拠することは、特に無関係です。
重要なことは、実装に必要な操作と操作の種類を明確に指定することです。
C: どのような形式の挿入操作が存在しますか? 完全に入力されていない行を挿入できますか? ID なしで行を挿入できますか? 最後に挿入された ID を取得できますか? 挿入を選択的にキャンセルできますか? 重複キーまたは制約エラーが発生した場合はどうなりますか? REPLACE INTO に相当するものはありますか?
R: どの分野で選択できますか? 任意のグループ分け、注文はできますか？集計フィールド、エイリアスを作成できますか? 埋め込まれた (たくさんあるなどの) データを取得するにはどうすればよいですか? 再帰の深さ、制限をどのように指定しますか?
U、D: R + C を参照
ワークフローのケースとリソース/オブジェクトのライフサイクルを区別することは理にかなっています。それらは相互作用しますが、同じではありません。両方を指定することは理にかなっています。
ユース ケース シナリオまたはより拡張されたワークフロー仕様では、通常、ケースがシステムのワークフローをどのように進行するかを説明します。これには通常、さまざまなリソースとのやり取りが含まれます。これらの相互作用は、多くの場合、C、R、U、または D として特徴付けられます。
リソースのライフサイクルは、特定の (タイプの) リソース (オブジェクト) に何が起こるかのプロセス モデルを提供します。それらは多くの場合、「C、R、U、D のいずれかがこのリソースに任意の順序で発生する可能性がある」という単純な「花」モデルであるため、それ自体はあまり興味深いものではありません。
この 2 つの間のリンクは、ワークフローからのステップとライフサイクルからのステップが一致することです。