ユースケース図（UML）：データベースストレージは（この図の）サブユースケースにする必要がありますか？
アプリケーションの背景
アプリケーションが何をすべきかについての短い説明
DNA配列を分析するアプリケーションを開発しています。ユーザーはload DNAシーケンスを含む特定のファイルになります。次に、ユーザーはボタンをクリックしてORFを検索（特定の機能を持つDNA配列の部分）を実行できます。次に、これらのORFをBLASTedにすることができます（これらのシーケンスに関する注釈をパブリックデータベースで検索します）。重要な要件の1つは、DNAシーケンス（ユーザーがロードしたもの）、ORF（アプリケーションが見つけたもの）、およびBLASTからの結果がデータベースに保存されるであることです。
- 処理する
最初に、何をしたのか、なぜ図を現状のままにしておくのかを明確にするために、なぜ変更したのかを説明します。 UMLとすべてのコメントを歓迎します。
ユースケース図バージョン1.
この質問 に基づいて、データベースがアクターであることを「発言する」ことに疑問を感じました。データベースはストレージ用であると判断し、省略しました。私の図の最終バージョンになります。
ユースケース図バージョン1.1
一部の人にUC_07について話しましたが、これは "too technical"だと主張する人もいます。ただし、私のビジョンは、この共通のステップを抽出すると、アプリケーションの制限を明確に示すことです。 （たとえばエラーのため）データベースが実行されていない間、3つのユースケース（2、3、4）のすべてがこれに影響されます。
質問C_07は別の（サブ）ユースケースかどうか]さらに上記のとおり（データベースがストレージに使用されているだけの場合、データベースはアクターではありません）- データベースがアクターと見なされない場合、どのようにUC_07を記述できますか？一般に次のようになるためです。1.アプリケーションはデータベース接続を開きます2.アプリケーションはデータを送信します2.データベースはデータを保存します
ユースケース図に関するその他の提案/改善も本当に感謝しています
アモンの回答に基づくコメントのために編集
UC_2-4のデータベースのデータストレージについて言及する必要があるかどうかにかかわらず、UC_07を省略することにしたとしましょう。
ユースケース図は要件の概要を示し、さまざまなアクターがシステムを介してどのように相互作用するかを示しています。
ユースケースを実際にキャプチャするには多くの方法があります。重要なのは単一文ser storiesです。例：「ユーザーとしてORFを検索したい」。これは有効な使用例です。 「ユーザーとして、データベースにデータを保存したい」のようなユースケースを提案しています。 mayは有効なユースケースですが、実際にはそうではありません。
表形式のユースケース形式を使用すると、これはより明確になります。ここでは、ユーザーが実行するステップとシステムの応答方法を明示的にリストしています。例えば：
ORFを検索
前提条件：ファイルがロードされている。
主演俳優：ユーザー
トリガー：ユーザーが「検索」ボタンをクリックします。
シナリオ：
- ユーザーはORFを検索ボックスに入力し、検索を送信します。
- ロードされたファイル内のすべての一致するシーケンスのリストが表示されます。
事後条件：システムは次の検索クエリを受信できます。
このシナリオの一部のステップは非常に複雑で、別のユースケースで説明されているので、次に含まれます。ただし、ユースケースは常にアクターとシステムの相互作用です。ユーザーが「データベースに保存」ボタンをクリックする「データベースにデータを保存する」ユースケースがある場合、実際のユースケースがある可能性があります。それ以外の場合、データベースは単なる実装の詳細です。
データベースがユーザーにとって重要であると思われる場合は、実際にすべてのユースケースをキャプチャしていない可能性があります。それらのユースケースが機能するためにデータベースが実行されている必要があるという制約について言及します。これは前提条件、またはおそらく例外シナリオです。上記の詳細なユースケースを別のフローで拡張できます。
例外：
- データベースがオフラインであるか、エラーが返された場合、システムはユーザーにエラーメッセージを表示します。
「データベースがオフラインです」チェックが多くのユースケースに共通している場合、その共通のステップを共有ユースケースに抽出できます。例えば。 Webアプリケーションの場合、「ユーザーがログインしている」チェックをユースケースごとに繰り返すのではなく、別のユースケースに抽出します。
ここでユーザーの関心は何ですか？回答が得られない場合、検索を入力したくありません。したがって、ユースケースは実際には「ユーザーとして、データベースがダウンしているときに警告を表示したい」または「ユーザーとして、データベースがダウンしているときに検索できないようにしたい」です。
UC_07がシステム全体の一部を形成している場合、UC_07はおそらくまったく必要ないでしょう。
また、多くのユースケースは、シーケンス図に適切に属する一連のステップのように読み取られます。ただし、実際に使用するUMLダイアグラムの数によって異なります。
これは、アプリケーション自体を使用している場合に発生するものであるため、開始アプリケーションと終了アプリケーションを削除することもできます。