UMLシーケンス図のWebページ？
私の現在のプロジェクトでは、Webページを表すアーティファクトをWebアプリケーションのUMLシーケンス図に含めて、どのページがビジネス対話を開始するかを明示的にすることが良いアイデアかどうかについて、継続的に議論しています。
Webページを含めるのは悪い考えだと思います。私にとって、シーケンス図はビジネスロジックとビジネスオブジェクト間の相互作用についてであり、Webページなどのプレゼンテーションの問題は含めないでください。 Webページを含めると、ナビゲーション図に表示されます。また、私の経験では、これまで、シーケンス図に含まれるWebページを見たことはありませんでした。
これに関する推奨事項/ベストプラクティスは何ですか？各シーケンス図にWebページを表すアーティファクトを含める必要がありますか？
編集：
回答が、引用された設計/モデリングガイドライン、UMLに関する本など、UML設計図にプレゼンテーションアーティファクトを含めることに賛成または反対である場合に理想的です。これまでのところ、個人的な意見の代わりに、この件について引用できる信頼できる情報源を見つけていません。
Webページは、最終的な実装の視覚的表現の一部であり、UMLシーケンス図言語構成要素の一部ではありません。 Webページは、現在のUMLシーケンス図の言語と定義で対処されていない目的には役立ちません。
さらに、設計ドキュメントにWebページを含めることにより、視覚的な実装を前提としています。シーケンスロジックを厳密に設計している場合は、視覚的な実装がどのように見えるかについて、先入観はありません。 （これは「Webサイト設計図」ではなく、一連の論理図です。）
ほとんどの場合、anyの指導原則、設計アプローチ、チーミング合意、プログラミング言語のパラダイム、さらにはエンジニアリングの「ベストプラクティス」に違反するケースを作成できることがわかりました。ただし、これらは「レッドフラグ」であり、そうである必要があります。これは、元々のコンセプト/理由から外れて、何らかのテクニック/ツール/その他を使用することを警告するものです。あなたが選択した、それはより少ない厳しさにつながるだけです。 Rigorは、それ自体のために、良くも必要でもありません。ただし、特定の目標に対する厳密な制約動作は通常、「A Good Thing（tm）」です。これは、自分から、または選択したフレームワークの（ある種の）誤解からあなたを救うためです。
提案/フレームワーク/ベストプラクティスは、特定の結果を優先して行動を助言および制限するためにのみ存在し、多くの非常に才能のある人々の組み合わせた経験に基づいています。これはUMLシーケンス図の厳密な構造に違反するため、ダイアグラムにWebページを含めることでUMLシーケンス図の構成に違反することはお勧めしません。どちらかといえば純粋なビジネスロジックおよび/またはdesign）の相互作用である必要があります。
UMLシーケンス図は文字通りもう少し使用することをお勧めします。これが「Webサイト設計図」ではありませんが、それが目的の場合を除きます。もしそうなら、あなたはあなたが作っているものを「ウェブサイトシーケンス図」と呼ぶかもしれませんが、それはストレッチのようです...
ニーズに合ったツールを使用するかどうかは、あなた次第です。しかし、私はこの変更を軽くはしません。 =）
重要なのは、Webページ用に作成する抽象化です。
たとえば、ユーザーがフォームに入力してリクエストを送信すると、Webページは基本的に、一連のダイアログ（たとえばバックエンド）に対するユーザーへの開始または応答のソースになります。その場合、Webページの役割は、同様のシナリオのクライアントアプリケーションと同じです。
ユーザーとの数回の反復の後、キーリクエストがエンドサーバー/サービスに送られる場合があります。たとえば、ユーザーが間違ったパスワードを入力したり、リダイレクトされたユーザーがログインしていないなど-ユーザーが認証されていると想定して、通常のワークフローからこのようなことを省略できます。 。
ユーザーがページ内のボタンやその他の要素を操作する方法と、ページがそれに反応する方法との間に定義する中間アクションがある場合-そのような場合、UML couldは悪い考えです。
適切なシーケンス図にプロットされる相互作用の正確な目的と範囲を定義する必要があります。
伝統的に一方がもう一方とまったく関係がなかったため、UMLシーケンス図へのWebページの追加に関する賛成または反対のいずれのディスカッション/アドバイスもおそらく見つかりません。
プロジェクトのUMLシーケンス図にある程度の情報が不足していると同僚が信じているようです。
プロジェクトの設計のどの側面が図から「欠落」しているかを正確に説明するように依頼し、絵で表す必要性を感じてもらえるようにします。これらの情報を箇条書きリスト形式で配置すると、各箇条書きをUMLシーケンス図の「標準/従来のコンポーネント」に変換できる（そしてそうする必要がある）場合があります。
つまり、彼らが不足していると感じ、視覚的に表現する必要がある情報は、ダイアグラム内の追加の入力/遷移/状態/相互作用として属している可能性があります。
欠落している情報を絵文字の形式で追加するのではなく、従来のUMLシーケンス図の構成を使用して図から現在欠落している情報を追加して、図を修正することをお勧めします。
ページは実際にはstartインタラクションではありませんか？これは、Ajax呼び出し、HTTP GET、またはそれを行うバックエンドコンポーネントへのPOSTになります。この場合、ページを省略して、バックから始めます。 （理論的には）トリガーイベントはどのページからでも発生する可能性があるため、-endコンポーネント。