0

これは、UMLシーケンス図でコンポーネントとサブコンポーネント間の関係を処理するための技術的に適切な方法は何かという考えの糧として、同僚との議論で思いつきました。

ここで質問があります。UML のベスト プラクティスでは、シーケンス図は、図に記述されているオブジェクトとの関係に関連しているべきでしょうか? 私の本能はそうではありません。各コンポーネントを分けてシーケンス図を描き、それをクラス図または配置図でフォローアップして、他のタイプの関係を示します。

「YES!」と言ったら どのように、そしてなぜあなたが違うことをするのかについて、いくつかの良い例を私に記入してください.

「いいえ」の場合、正当化するための信頼できるオンライン リファレンスをいくつか教えていただけますか? 私はUML仕様を試してみました...オイ！...無意識に自分を打ち負かそうとしていない限り、私が望んでいたことではありません。

具体的には、これが私の例です。アプリケーション サーバーがセキュリティ プラグインを呼び出し、JSP と Java でデプロイされた基本的なアプリケーションを呼び出す方法のシーケンス図をモデル化したいと考えています。アプリケーション サーバーは確かにプラグインとアプリケーションを「含んでいます」が、それはシーケンス図にとってさえ重要なのでしょうか?

そのような状況では、アプリ サーバーを操作の頭脳として 3 つのスイムレーンとして 3 つのことを投げるだけでしょうか、それとも、プラグインもアプリケーションもスタンドアロンの方法でほとんど何もしないことを示すために何か別のことをしますか? ?

4

3 に答える 3

1

良い、

どちらも有効です....

シーケンス図を使用する目的によって異なります。

> We draw a diagram since we have a purpose.... So Ask yourself which
> one help me more about solving my problem at hand? Which one is
> helpfull for my purpose?

ここに画像の説明を入力

ここに画像の説明を入力

于 2011-07-16T08:29:12.220 に答える
0

これは、仕様について知っていること、読んだこと、経験したことを要約したものです。

いいえ。シーケンス図は動作を示すためのものであり、コンポーネントの関係は構造の一部です。UML の仕様と書籍は、構造図と動作図のように分類されています。ウィキはこれの画像を提供します。 クラスなどのいくつかのモデル要素は両方で使用されますが、関係と構成は実際にはこの意味ではありません。さらに、動作図は実行パスを示すことを目的としており、通常は「完全」ではありません。構造図とコンポーネントの関係は、その意味でより具体的で決定的です。いつでも色分けしたり、フルネームを使用したり、ステレオタイプを使用してビューを充実させることができますが、モデルに関する限り、標準的な図の表記法はありません。

于 2011-07-15T19:04:32.383 に答える
0

要素の「内部生活」をシーケンスに含める正当な理由がある場合があります。可能な限り完全で詳細な情報を提供したい場合があります。たとえば、セキュリティ レビューのために設計を提出する場合などです。抽象化は役に立ちません。実際に何が起こっているのかを正確に示す必要があります。

つまり、UML のベスト プラクティスの問題というよりも、特定の対象者に正確にどのような情報を伝える必要があるかという問題です。

Sparx Systems の Enterprise Architect を使用すると、埋め込み要素 (ポートや提供されたインターフェイスなど) をシーケンスに含めることができますが、正直なところ、これが UML に準拠しているかどうかはわかりません。いずれにせよ、ここに例があります。些細なことですが、アイデアは次のとおりです。

ここに画像の説明を入力 ここに画像の説明を入力

于 2011-08-08T18:58:55.450 に答える