UML 2 配置図の概要
by Scott
W. Ambler, Copyright 2003
UMLの配置図 (deployment diagram) では、処理ノードやそのノード上で動くコンポーネントが実行時にどう構成されるかを静的に表します。違う言い方をすると、配置図には、システムのハードウェアと、そのハードウェアにインストールされたソフトウェア、種類の異なるマシン同士を接続するためのミドルウェアを表します。アプリケーションが複数のマシンに配置される場合には、配置図を作成するとよいでしょう。たとえば、POS(point-of-sales)アプリケーションがシンクライアントのネットワークコンピュータ上で動き、会社のファイアウォールで保護された複数の内部サーバや、Microsoft .NETのようなWebサービスアーキテクチャを使って配置された顧客サービスシステムなどとやりとりをする場合が考えられます。また、配置図を作成することで、組込みシステムのアーキテクチャについて、ハードウェアやソフトウェアのコンポーネントが一緒になってどう動くかを考えることかできます。ひとことで言うと、よほど小規模なシステム以外では、配置図の作成を考えるべきでしょう。
図1の例は、学生管理アプリケーションのUML2配置図を詳細に記述したものです。立方体の箱はノード(ソフトウェア、ハードウェアの両方)を表します。物理ノードには<<devise>>というステレオタイプを付けて、コンピュータやスイッチなどの物理デバイスであることを表します。この図にはWebサーバがデバイスであることを示していません。このWebサーバは少なくとも何らかのソフトウェア成果物であり、物理デバイスである可能性は高いにしても、チームはまだそう決定したわけではないからです。モデルとはだんだんと発展するものだということを忘れないでください。ノード間の接続は単純な直線で表現し、<<RMI>>や<<message bus>>といったステレオタイプによって接続の種類を示します
ノードには別のノードやソフトウェア成果物を含めることができます。アプリケーションサーバ・ノードにはEJBコンテナ(ソフトウェアノード)が含まれ、さらにそこには3つのソフトウェアコンポーネントと1つのデプロイメント仕様、1つのソフトウェア成果物が含まれています。ソフトウェアコンポーネントは、コンポーネント図と同じ表記法で記述します(インターフェースまで付けることもできたのですが、そうしたところであまり意味があるとは私は思いません)。デプロイメント仕様とは、EJBのデプロイメント記述などのように、基本的には構成ファイルであり、そこにはノードがどう働くかが定義されます。これは、<<deployment spec>>というステレオタイプの付いた2つのセクションからなる長方形で、上部にはノードの名前を、下部には配置プロパティを(あれば)記述します。ただし、配置プロパティは、実行時に実際のデプロイメント仕様ファイルに含めるような種類の情報なので、ここに書くのは余計だと私は考えています。ソフトウェア成果物は、右上を折り返した紙の形をしたアイコンのステレオタイプか、<<artifact>>というテキストのステレオタイプを付けて表します(両方を付けることもありますが、私はこれも余計だと考えています)。この例でのソフトウェア成果物は、AmbySoftから購入した架空の永続化フレームワークです(ベンダーはUMLのプロパティの文字列として表記されています)。
図1 大学情報システムのUML2配置図
★==
Studet Administration:学生管理
Student:学生
Seminar:ゼミ
Schedule:スケジュール
Registration:登録
Persistence:永続性
Course Management Facade: コース管理ファサード
Course Management: Course Management
University DB:大学DB
==★
落ち着いて考えてみると、接続に付けたステレオタイプは正しくありません。実際には、Webサーバー上のソフトウェアが、アプリケーションサーバ上のソフトウェアと、接続上のRMIプロトコル経由で通信を行っているのです。物理ハードウェアノード間の物理的な接続は、おそらくイーサネット接続などもっと低いレベルのものなので、本当ならハードウェアノード間の接続には<<Ethernet>>というステレオタイプを付け、それとは別の接続をソフトウェア要素間に作成して、それに<<RMI>>というステレオタイプを付けるべきでした。また、ソフトウェア接続とハードウェア接続の間に依存関係をモデリングして、おそらくは<<over>>などのステレオタイプを付ける必要があるでしょう。そうすればより正確にはなるでしょうが、手間がかかる割にあまり役立つとは思えません。忘れないでください。アジャイルなモデルは完璧である必要はなく、そこそこ役に立てばいいのです。
私は、配置モデルの作成の仕方を説明するとき以外に、図1のような形式で配置図を書くことはありません。この表記法は見た目に無駄が多いと考えているからです。図2の例の方が効率的です。ソフトウェア要素は、単に物理ファイル名を並べて書いているだけなので(おそらくこれが開発者の知りたい情報です)、図はコンパクトになります。また、Universtiy DBデータベースには円筒のステレオタイプアイコンを使って、図上で区別しやすくしています。もう1つ違うのは、簡易版の方が詳細情報が少なくなっていることです。タグ付き値も、補助文書や構成ファイルやソースコードに記述することができるため、図にはそれほど多く示されていません。配置図は、システムの物理的な複雑さを反映するため、すぐに大きくなりがちです。そのため、うまく作成するためには表記法を簡潔にしておくことが大切です。
図2 UML2配置図(簡易版)
配置図はどの程度アジャイルでしょうか。いつものことですが、それは目的によって異なります。ほとんどの場合、あまり詳細でないネットワーク図(ステレオタイプのアイコンを多用した配置図ともいえます)を作成する方がよいでしょう。相互に接続された多数のマシンからなる環境をモデリングする場合には特にそうです。また、大雑把な自由形式の図の方が、表記法がずっと柔軟なため、適している場合もあります。図2の情報は、インストール用スクリプトと組み合わせることで、ネットワーク図でも自由形式の図でも簡単に表現することができます。そう考えると、インストール用スクリプトは実際上「配置するためのソースコード」だということができます。
配置モデルを作成する必要があるかどうかを判断するには、次の点を考慮してください。もしシステムのことを何も知らないのに、システムをインストールしたり保守やサポートをするよう頼まれたとしたら、システムの部品がどう組み合わさっているかの説明が必要でしょうか? 一緒に働いているプロジェクトチームにこの質問をすると、ほとんどの場合、何らかの配置モデルを作成することになります。さらに重要なことですが、これまでの実践経験からいって配置モデリングはする価値があります。配置モデルを作成することで、実際のシステムを出荷するずっと前に、重要な配置の問題について考えることになるからです。
システムの配置アーキテクチャをどうモデリングするかを決めるときには、どのアーキテクチャを選んだかには関係なく、たいてい次のことを行います。
- モデルの対象 (scope) を明らかにする：そのダイアグラムでは、1つのアプリケーションのあるバージョンの配置方法を扱うのでしょうか。それとも、組織内の全システムの配置を表すのでしょうか。
- 基本的な技術上の問題について考慮する：既存のどのようなシステムと相互作用/統合する必要があるでしょうか。システムはどの程度堅牢でなければならないでしょうか(フェイルオーバーを行うための予備のハードウェアはあるか)。システムと接続しやりとりしなければならないのは誰/何で、それをどのように行うのでしょうか(インターネット経由なのか、データファイルを交換するのか、など)。そのシステムでは、オペレーティングシステムや通信アプローチ/プロトコルなどのミドルウェアは何を使うのでしょうか。ユーザが直接やり取りするハードウェアやソフトウェアは何でしょうか(PCなのか、ネットワークコンピュータなのか、ブラウザなのか、など)。システムが配置された後、どうやって監視するつもりでしょうか。システムはどの程度安全でなければならないでしょうか(ファイアウォールは必要か、ハードウェアが動かないように物理的に固定する必要はあるか、など)。
- 分散アーキテクチャを明らかにする：ファットクライアントのアプローチを採用して、ビジネスロジックをデスクトップアプリケーションに含めるのでしょうか。それともシンクライアントのアプローチで、ビジネスロジックをアプリケーションサーバーに置くのでしょうか。アプリケーションは2層でしょうか、3層でしょうか、それ以上でしょうか。アプリケーションの分散アーキテクチャ戦略があらかじめ決まっていることもよくあります。技術的な環境は現在のままでシステムを配置する場合には、特にその可能性が高くなります。
- ノードと接続を識別する：分散戦略としてノードの種類の概略は定義されますが、厳密な詳細は定義されません。配置するハードウェアやオペレーティングシステムといったプラットフォームに関して、さまざまなノードをどう接続するか(図2のようなMIおよびメッセージバス経由など)といった判断を下さなければなりません。
- ソフトウェアをノードに配置する：どちらの配置図にも、それぞれのノードに配置されるソフトウェアが示されています。これは、システムの配置、インストール、運用に携わる人にとって重要な情報です。
注: この成果物の説明は『The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2』より抜粋しました。本ではより詳しく説明しています。
アジャイルモデリング(AM)について詳しく知るにはこの本をお薦めします。 
Ronin
International, Inc. continues to help numerous
organizations to learn about and hopefully adopt agile
techniques and philosophies. We offer both
consulting and
training offerings. In addition we
host several sites - Agile
Modeling, Agile
Database Techniques, UML
Modeling Style Guidelines, Enterprise
Unified Process (EUP) - that you may find of value. You
might find several of my books to be of interest,
including
The Object Primer, Agile
Modeling, The
Elements of UML Style, and Agile
Database Techniques. For more information please
contact Michael Vizdos at 866-AT-RONIN (U.S. number) or via e-mail (michael.vizdos@ronin-intl.com).
visits since June 8, 2004.
|
