java - 同様の特性を持つオブジェクトのUMLアイデア。

Question

イベント、ジョブ、自己および連絡先は、各オブジェクトをデータベースに追加、編集、およびデータベースから削除できるDTOオブジェクトに他なりません。私はユースケース図にあまり詳しくないので、これが正しいか、または改善できるかどうかを知りたいと思いました。

ここで一般化するものはありますか？実装のaddeditメソッドとdeleteメソッドは、1つのクラスによって処理されます。ただし、呼び出しはオブジェクトごとに個別に処理されます。これでいい？

Answer 1

まず、ユースケース図は通常、ユーザーの観点からシステムの要件を説明するために使用されます。「連絡先の管理」と「イベントの管理」がユースケースであることは問題ありませんが、ユースケースモデルは、どのクラスが連絡先とイベントを表すかに依存しない必要があります。（より低いレベルの詳細は、他の図でよりよく説明されています）

次に、拡張関係は、「拡張ユースケースで定義された動作を拡張ユースケースで定義された動作にいつどのように挿入できるか」を指定します。拡張されたユースケースは、矢印で示されているものです。次に、矢印を逆にする必要があります。*連絡先の追加*は連絡先の管理を拡張するためです。「連絡先の管理」の実行のある時点で、いくつかの条件が満たされた場合（たとえば、ユーザーが「追加」を選択した場合）、「連絡先の追加」の動作実行されます。

確かに、これはモデルに合わせるための拡張関係の非常に強制的な解釈です。「連絡先の管理」は抽象的なユースケースであり、 「連絡先の追加」、「連絡先の編集」 、「連絡先の削除」に特化しています（イベント、ジョブなども同様です）。 。

すべての「追加/編集/削除」ユースケースに他のユースケースとの共通点があることをモデル化する場合は、それを抽象的なユースケースとしてモデル化できます。次に、「連絡先の追加」は「連絡先の管理」の専門分野であるだけでなく、「追加」（エンティティの追加の動作を定義する）の専門分野でもあります。

Answer 2

経験則として、「X の管理」は決してユースケースにすべきではありません。ユースケースは、ユーザーの観点から正確な目的を持つアプリケーションの特定の機能です。「管理」は、ユースケースとしては常に漠然としすぎています。

実際、ここにある「X の管理」は明らかにパッケージであり、「X の管理」という名前になります。これらのパッケージを使用すると、アプリケーションの一部を分離できます。また、X の追加、Y の追加、Z の追加をグループ化する必要はありません。唯一の共通点は、最後にデータベースへの挿入を実行することです。これらに継承を使用することは有効ですが、それだけの価値があるとは思いません。

したがって、私の考えでは、独立したユースケースをパッケージにグループ化する必要があります。

もう 1 つのアドバイス: Login との挿入関係は使用しません。もちろん、これらの関係は正しいのですが、それらは図を混雑させており、暗示的である可能性が非常に高いです。ログインが必要なユース ケースとそれ以外のユース ケースを区別する一般的な方法は、匿名の「ユーザー」と「アカデミック」という 2 つのアクターを使用することです。