ユースケースとシーケンス図を介してUMLの2ステップログインを適切にモデル化する方法
基本的な会計関連のアプリケーションのログインページを作成する必要があります。ログインアクションは2つのステップで行う必要があります。
- ユーザーはユーザー名とパスワードを入力し、「承認」ボタンを押します、
- 認証が成功した後、ユーザーは現在のセッションの初期パラメーター（つまり、月と年、計算の対象となる単位など）を設定する必要があります。選択可能なパラメーターはサーバーから取得する必要があります（許可されたユーザーの権限などによって異なる場合があります）。
上記のアクションについて、ユースケースとシーケンス図の両方を使用してUMLで説明したいと思います。だから今のところ私はそのようなユースケース図を作成しました： 
シーケンス図：
これらの図が正しいかどうか（特にサーバーアクターとの関係が正しい方向にあるかどうか、およびinclude関係をユースケースで適切に使用しているかどうか）を知りたいシーケンス図が理にかなっている場合も同様です）。改善や提案はありがたいです。
ダイアグラムにいくつかの問題があります。
まず第一に、俳優の使用。アクターは何か/誰かoutsideシステムと対話する必要のある、モデリングしているシステムです。アクターは通常人間であるので、棒人間で表されます。人間以外の俳優が存在する可能性もありますが、人間以外の俳優が俳優として正しくモデル化されているのか、システム自体の一部としてモデル化されているのかを伝えるのははるかに困難です。
ソフトウェアが実行されるサーバー、プリンター、ディスプレイなどは、間違いなくnotアクターです。これらは、設計しているシステムの不可欠な部分を形成します。
アクターは当然のことながらシステムの外部にあるため、アクター間の直接の対話はユーザーにとって重要ではありません。 2つのアクターの間に呼び出し/イベントの矢印が付いたシーケンス図がある場合、シーケンス図の意味を変更せずにその相互作用を削除できるか、少なくとも1つのアクターがシステムの一部である必要があります。
適切なユースケース図は、驚くべきことにlittle情報を読者に提供します。ユースケース図は、存在するユースケースとその主要なアクターへのグラフィカルなインデックスにすぎないと見なすのが最善の場合があります。
ユースケースは、アクターとシステムの間の相互作用であり、アクターはシステムを使用して目標を達成します。
あなたの例では、「ログイン」は適切なユースケースですが、他のすべてはそうではありません。これらは、「ログイン」ユースケースの一部として実行される手順にすぎません。正しいユースケース図を作成するには、「ログイン」ユースケースの右側にあるすべてのものを消去するだけです。
使用例を説明する通常の方法はプレーンテキストですが、シーケンス図やアクティビティ図などのサポート図が使用される場合があります。