配置図に外部サービスを含める必要がありますか

Question

既存のJava EEアプリケーションのデプロイメント図とコンポーネント図を設計しています。

アプリはsoap webサービスとftpを介して3つの外部システムと統合されています。

これらのシステムをコンポーネント図に含めていますが、展開図に含める必要があるかどうかわかりません。したほうがいい？ UMLの標準がこれについて何かを述べているかどうかはわかりませんでした。

それらを含める必要がある場合、それらのノードのステレオタイプは何ですか？

ありがとう！

Thomas Owens · Accepted Answer

ML仕様では、セクション11がコンポーネント図を説明し、セクション19が配置図を説明します。どちらの図の種類にも外部システム、サービス、またはコンポーネントを含めることができる、または含めることができないということは何もありません。

個人的には、私はおそらくあなたがしていることの反対をするでしょう。コンポーネント図ではなく、配置図に外部サービスを含めます。

配置図の目的は、「システムの論理要素および/または物理要素とそれらに割り当てられた情報技術資産との間の関係を捉えること」です。配置図のユーザーには、システムの物理インフラストラクチャの責任者が含まれます。特にファイアウォールで開いたままにする必要がある特定のネットワークポートがある場合、または特定のアーティファクトを含む物理リソースに外部からアクセスできるようにするには、システムが外部サービスと相互作用することを知っていると便利です。

一方、コンポーネントは「その内容をカプセル化し、その表現をその環境内で置き換えることができるシステムのモジュール部分」です。ここでの情報は、要件をソフトウェアシステムの各部分にマッピングし、再利用を計画し、システムの各部分間の特定のインターフェースをより重要にして、システムの他のビューでさらに詳細に分解できる要素のグラフィカルな概要を提供します。これらは、サービスの特定の性質やサービスがどこにあるかについてそれほど気にしないソフトウェア開発者やアーキテクトにとってより興味深いものです。むしろ、開発中のシステムの一部であり、これらの部分がどのように相互作用するかについてです。

ただし、図はわかりやすいものにする必要があります。多分、あなたの聴衆のために、配置とコンポーネント図で外部システムを示すことはコミュニケーションをより簡単にします。 UMLはコミュニケーションツールです。ソフトウェアシステムの設計を伝えるための共通言語を提供します。私の好みはアジャイルモデリングテクニックの多くを採用し、標準的な表記法と言語の精神に固執することですが、私が図を作成しているのは誰か、彼らが仕事をするのに役立つものについて考えてください。

maple_shaft · Answer

ThomasOwensは素晴らしい答えをここに残していますが、私は尋ねられた質問に対して異なる意見を持っていますが、彼が間違っているとは言いません。結局のところ、彼がすでに指摘したように、この図は、可能な限り集中している間、コミュニケーションの最大の利益をもたらすはずです。

配置図にはいくつかの種類があり、それぞれの種類を使用して、システムの一意のビューを表示できます。配置図を使用して、システム内のコンポーネントの物理的な状態、配置ターゲットへのアーティファクトの仕様、さらにはシステムの物理的または論理的なインフラストラクチャを示すことができます。

Thomas Owensのような外部サービスとFTP接続は、システムの論理インフラストラクチャ（ファイアウォール、FTPクライアントソフトウェアパッケージなど）を通信するために重要である可能性があると述べましたが、これらのサービスまたはFTPドロップ場所を論理の一部として考慮しない限りインフラストラクチャーの場合、それらをノードとしてノードに表示しません。私が通常行うことは、論理インフラストラクチャの周囲に境界を描き、その通信パスの反対側にある名前を付けるための曖昧なボックスを用意することです。

ただし、コンポーネント図では外部サービスなどを表示することを好みます。システム内のコンポーネントは通常、より大きなシステム（エンタープライズ、インターネット、VPNを介したクライアントイントラネットなど）内で動作するため、このような要素は、明確に定義されたインターフェイスを持つ外部コンポーネントと見なします。コンポーネントは他のコンポーネントへのインターフェースを提供することも要求することもできるので、コンポーネントが何を必要としているのかが明確になるように、外部システムコンポーネントインターフェースを実際に示す必要があります。これを文書化することで、アーキテクトと開発者は、構築する必要があるコンポーネントについてより簡単に推論できます。

しかし、結局のところ、これらの種類のことについて厳格なルールはありません。そしていつものように、彼らがあなたに利益をもたらさなくなるまでできる限りの緩いガイドラインの中に留まってください。ダイアグラムは、システムの通信を支援するツールである必要があるため、最も重要なことは、聴衆が必要なすべての答えを見つけて、ダイアグラムから必要なすべてを得るようにすることです。