1

HTTP 要求を JSON API に送信し、そこから応答を取得する Web アプリケーションを開発しました。また、SMTP サーバーを介して電子メールをユーザーに送信しています。シーケンス図でこれらのシナリオをモデル化する方法に行き詰まっています。

編集：

ログインのシーケンスは次のとおりです。

1-ユーザーがログインとパスワードをビューに入力します

2-ビューは入力されたデータをコントローラーに送信します

3-コントローラーは WebService クラスにある関数を呼び出します

4- 関数はログイン要求モデルのインスタンスを作成します (ログイン要求モデルは、送信される JSON データと同じ形式のクラスです)

5- 関数は、作成されたインスタンスを JSON にシリアル化し、HTTP 経由でリモート Web サービスに送信します。

6-関数は応答ストリームを読み取り、それを応答クラスの新しいインスタンスに逆シリアル化します

7-その後、作成されたインスタンスがコントローラーに送り返されます

8-コントローラーは、受信したインスタンスでテストを実行して、ユーザーが正しい資格情報を提供したかどうかを確認します

9-テスト結果に基づいて、コントローラーはユーザーをランディング ページにリダイレクトするか (正しい資格情報を入力した場合)、インデックス ページに資格情報が間違っていることを示すメッセージを送信します。

この場合、シーケンス図のアクターは何になり、何を入れるべきで、何を記述せずに残すべきでしょうか?

4

1 に答える 1

1

最初の図は良いスタートです。

私はここに黒字の英語のテキスト (誰もがそれから恩恵を受けることができるように)、番号付きシーケンスリストの参照、およびマゼンタのいくつかの変更で注釈を付けました. また、いくつかの一般的な発言を強調するために 3 つの円を追加しました。 ここに画像の説明を入力

注意 1: この最初のメッセージが同期であるかどうかは不明です (プレーン矢印)。あなたのユーザークラスは本当に return を待っていますか? これは非同期である可能性があり、返される最終メッセージは必ずしも返信メッセージ(点線) であるとは限りません。

注意 2: リクエスト テンプレート/モデルの着信メッセージ 4 は非同期です。したがって、回答も非同期メッセージであると予想されます（点線ではありません）。

注意 3: ここ (および他のいくつかの場合) では、「作成」メッセージが着信しています。新しいオブジェクトを作成する場合は、そこでライフラインを開始して、インスタンス化を表示することをお勧めします。

注意:領域を使用することで、(シーケンスの最後に)代替の相互作用をより曖昧に表示できaltます。

最後のコメント: さまざまな種類の送信 (つまり、JSON と SMTP) について心配しています。UML ダイアグラムには、メッセージの形式は示されていません。したがって、フローが同じでプロトコルのみが変更されている場合は、そのままにしておくことができます (最終的には、JSON または SMTP であることを示すアノテーションを作成します)。シーケンスに異なる種類の相互作用がある場合は、alt.

于 2016-05-22T12:10:31.550 に答える