UML によると、このユースケースは正しいですか? そうでない場合は、改善するための入力をお願いします..
境界値「ユースケース」としての見方は、「リリースフェーズ1」として説明できますか?
ライター モジュール/リーダー モジュールは適切な Ator である必要がありますか?
UML によると、このユースケースは正しいですか? そうでない場合は、改善するための入力をお願いします..
境界値「ユースケース」としての見方は、「リリースフェーズ1」として説明できますか?
ライター モジュール/リーダー モジュールは適切な Ator である必要がありますか?
この図は、開発中のシステムの外部に「ライター モジュール」と呼ばれるものがあることを示しています。ライターには、初期化などの 3 つのユース ケースが必要です。
同様に、別のアクターも Check Status と StackUp を必要とします。
それがあなたの意図したものである場合、この図は機能します。本当にそう思ってる?システムを初期化するのは Writer モジュールだけですか? それとも、システム自体が初期化されますか? リーダーは、システムが初期化される前に、システムが初期化されているかどうかを確認できますか? 別のユースケースはありますか?
小さな改善: ユースケース名の品詞を一致させます。初期化は「モノ」、チェックステータスは「アクション」です。おそらく、システムの初期化の方が良いでしょうか?「StackUp」ではなく「Stack Up」、一貫性を保ちます。
通常、ボックスを使用してユース ケースをグループ化する理由は、どのシステムがユース ケースの実現または実現に役立っているかを示すためです。これは正式にはシステム境界 (「構築中のシステム」) として知られています。通常、アクターであるシステム、モジュールなどは、よりブラック ボックスであるか、既存のものであるか、使用のみです。新しいシステムまたは変更されたシステムが多数ある場合、この定義は混乱を招きます。 .
他のコメントは、表示されているもののセマンティクスですが、構文ではなく、依然として重要です。
Martin Fowler の 103 ページには、システム境界の概念とシステム アクターを使用する図と説明があります。
ユースケースは、誰かがシステムを使用して価値のあるものを取得する方法を示すことを目的としています。アクターは、目標を持ち、価値のあるものを求めることができる独立した存在という意味で、常に人を表します。
アクターは、いくつかの方法のいずれかで表されます。名前によって直接、またはロールを介して含めるか、人またはロールに代わって動作するエージェント (「システム」アクター) の形でプロキシによって表されます。形式に関係なく、アクターは常に独立しており、常にシステムに「作用」して独自の目的を達成することができます。
ここにある図はユース ケース図ではありません。「モジュール」は、独立した目的を追求するエンティティではなく、単なるシステムのコンポーネントのように見えます。それらは何も「探す」ことができず、実装の詳細にすぎません。
おそらく探している図は、配置図 (特定のコンポーネントがどのように接続されているかをモデル化する場合)、アクティビティ図 (アプリケーション ロジックをモデル化する場合)、またはクラス図 (正式なロジックをモデル化する場合) です。コンポーネント間の関係)。
例を挙げると、次の図は、Check Status が Writer と Reader の 2 人の参加者を持つシナリオであることを示しています。それが言いたいことですか?
また、一般的にユース ケース (のセット) の周りにボックスを見た覚えがありません。