ユースケース図のCRUD？
私の質問は非常に簡単です。 [〜＃〜] crud [〜＃〜] をユースケース図に取り込むための最良の方法は何ですか？ [〜＃〜] dry [〜＃〜] である必要があります。 UMLは裁量である場合もありますが、それについてどう思いますか？
いくつかのアイデア：
1つのユースケース図
- CRUDオブジェクトがいくつかある場合、実際にはDRYではありません。
2ユースケース図
- CRUDオブジェクトがいくつかある場合は、実際にはDRYではありません。
3ユースケース図
- 私はこれが好きです。
更新
4ユースケース図（@Uffe）
- ドキュメントに記載されている場合、おそらく必要ないことに注意してください。
5ユースケース図（@home @Uffe）
これらのうち、「CRUD」自体はユースケースではないため、実際には＃3が最悪です。あなたはいつもCRUD 何か。ユースケースを混同しないでください<<extend>>クラス継承あり。
オプション＃2もあまり良くありません。「ユーザーの管理」のユースケースを実行しても、4つのCRUDアクションすべてを実行することにはならないからです。
ユースケースでこれを明示的にしたい場合は、＃1にお金があります。しかし、私であれば、「ユーザーの管理」のユースケースを1つだけ入れます。
ユーザー（または何か）の管理はよく理解されている概念であるため、「ユーザーの管理」のユースケースは実際にはかなり自明であり、特定の理由がない限り（たとえば、要件を分析しているシステムが認証メカニズムである場合）。その場合は、＃1を使用してください。
「UMLとパターンの適用-CraigLarman」という本によると、ユースケース名に「ユーザーの管理」を使用して、ユースケースでのCRUD操作を示すことができます。 4は適切な選択ではありません。この場合、シナリオでのCRUD操作について説明する必要があります。イベントのメインフローでユーザーを作成し、その他のイベントフローで他のユーザーを作成します。
CRUDの意味を会社で暗黙的または明示的に理解している限り、3つに投票します（つまり、クラスがより複雑なものを必要とする場合は、すべてのデータを入力するための基本的なフォームを意味することに誰もが同意する必要があります）入力プロセスは、別のユースケースとしてモデル化する必要があります）。