連載第10-2回
UMLの基礎と応用

(株)NTTデータ 技術開発本部 副本部長
山本修一郎

配置図の例

 配置図の例として、ICカード情報流通プラットフォームNICE(Network based IC card Environment)の構成[5][6] を図3に示す。

図3 NICEの機能構成を示す配置図
図3 NICEの機能構成を示す配置図

 NICEは端末およびサーバー上のソフトウェアをすべてJavaで開発されている。NICEでは、ICカード発行者とICカード上のサービス提供者を分離して、多目的ICカードに複数のアプリケーションを動的にダウンロードしたり削除することができる。このためICカード発行者、サービス提供者、ICカード上の空き領域をいくつかの部屋(サービスドメイン)に区切ってサービスドメインごとにAPを安全に管理運用するサービスドメイン運用者、ICカードにAPをダウンロードしたり、削除するAPローダなどの役割に応じたコンポーネントを提供している。またこれらの事業者間やICカードと事業者が相互に認証するために、第三者的な登録機関による公開鍵証明書の発行が必要になる。NICEではこれらの役割に応じたサービスを提供するコンポーネントの柔軟な組み合わせができるようにCORBAを用いて相互に接続できるようにしている。

 それでは図3を説明しよう。まず、ノードにはICカード、ICカードリーダライタ、PC 端末、サーバーがある。PC端末には、利用者端末、運用端末がある。サーバーにはディレクトリサーバー、ブローカサーバーなどの分散システム管理用のサーバーと、CIサーバー、SOサーバー、SPサーバー、ALサーバー、RCサーバーなどの機能別サーバーがある。機能別サーバーには機能名を付与している。また、接続関係には、<<CORBA>>、<<HTTP>>、<<OCF>>、<<ISO7816>>、<<TCP/IP>>がある。このようにノード間の接続関係には通信プロトコルをステレオタイプとして記述するのが分かりやすい。ところで、RCサーバーが発行する公開鍵証明書をネットワーク経由で転送しない場合には、図に示したように、RCサーバーと他の機能別サーバーとの間に接続関係は存在しないことになる。論理的にはファイルをサーバー間で移動するので関係をつけたいところだが、配置図ではノード間の物理的な接続関係を記述するので、このような通信を前提としない関係は記述しないわけだ。このような関係はファイルのコピー関係になるので、配置図の上に重ねて描くなら、異なるノード内にあるオブジェクト間の依存関係を用いて記述することになるだろう。なお、図で用いた記号の意味は次のようである。

RC:登録機関
CI:カード発行者
SO:サービスドメイン運用者
SP:サービス提供者
AL:アプリケーション(AP)ローダ

 配置図に相当する図は従来も作成している。たとえば図3に対しては図4のような図を作成しているものだ。この意味では配置図はとくにUMLであたらしく考案されたのではなく、従来から必要だった図をUMLでも形式的に定義できるようにしたということなので、UMLの図の中では比較的理解しやすいと思われる。しかし、逆にいえば、いままでの図のほうが分かりやすいということもあるかもしれない。また配置図の利点としてはコンポーネント図を埋め込むこともできるので、段階的に詳細化できる可能性もあること、ツールにより機械処理の対象になるので、コードとの対応付けが容易であることなどである。

図4 NICEの構成
図4 NICEの構成

実装図の記述上の留意点

 実装図は実際のコードやハードウェアの構造にあわせて作成するものであるから、可能な限り、コードやハードウェアとの対応関係を明確にするように作成するのがよいと思われる。たとえば、コンポーネントには、あらかじめ<<application>>、<<database>>、<<document>>、<<executable>>、<<file>>、<<library>>、<<code>>、<<table>> などのステレオタイプを明記しておくとよいだろう。また、コンポーネント名にはjavaやdll、exe、docなどの拡張子を付与することで、物理的な走行環境をより具体的に指定できる。

 インタフェースの記述では、ロリポップ形式か展開形式のどちらで記述するかが判断に迷うところである。システム全体のアーキテクチャを明確にするときは省略形式で記述しておき、詳細なインタフェースの内容を示すときは展開形式を用いるということになるだろう。たとえば、ハンスマンらのスマートカードの本[7]では、UMLでAPDUなどのインタフェースを記述しているが、すべて展開形式で示している。これは操作やデータ構造を記述する必要があるためだ。コンポーネント図も段階的に詳細化したり概略化できたりすると便利かもしれない。

 コンポーネントの包含関係を記述する場合、親コンポーネントの中に埋め込んで記述する方法と埋め込まずに依存関係で階層構造を示す場合があるので、どちらか選択する必要がある。

 配置図ではコンポーネント図で検討したソフトウェア構成を物理的な資源にどのように配置するかを記述することになる。したがって、サーバー上にどのコンポーネントを載せるかを考慮してノード数やノード間の関係を決定する必要がある。また接続関係には通信プロトコルを記述すると分かりやすい。たとえば<<HTTP>>、<<JDBC>>、<<IIOP>>、<<RPC>>などをステレオタイプにする。これからはWeb サービス向けに<<SOAP>>や<<UDDI>>も使うことになるだろう。実装図はコードと対応した記述になるため、XP (eXtreme Programming)などとも親和性が高いと考えられる。たとえば、アジャル・モデリング(agile modeling)などの技法が提案されている[8][9][10]

まとめ

 本稿ではコンポーネント図と配置図について紹介した。これで、UMLで使用される各種の図式の説明がひととおり終わったことになる。次回はWebアプリケーション設計へのUMLの適用例について説明しよう。

参考文献
[1]ファウラー,スコット著羽生田監訳,UMLモデリングのエッセンス第2版,翔泳社,2000.
[2]Unified Modeling Language(UML),version1.4,
http://www.omg.org/technology/documents/formal/uml.htm
[3]ブーチ著、UMLユーザーガイド、ピアソン・エデュケーション(原著名The Unified Modeling Language User Guide,1998)
[4] エリクソン、ペンカー著、UMLガイドブック、トッパン(原著名UML,Tool kit,1997)
[5] ICカード情報流通プラットフォームNICE,http://www2.pflab.ecl.ntt.co.jp/index/kenkyu/html/16.html
[6]山本 修一郎, 田路龍太郎, 平田真一, 庭野栄一,IC カード情報流通プラットフォーム:NICE NTT技術ジャーナル」2001年12月号,pp.14-18
[7] Hansmann,U.,Nicklous,M.,Schack,T.,and Seliger,F.,Smart Card Application Development Using Java, Springer-Verlarg,2000
[8] アジャル・モデリング,http://www.ogis-ri.co.jp/otc/hiroba/agilemodeling/
[9] UML Component Diagramming Guidelines,
http://www.modelingstyle.info/componentDiagram.html
[10] UML Deployment Diagramming Guidelines,
http://www.modelingstyle.info/deploymentDiagram.html

●執筆者にメールを出す
yamamotosui@nttdata.co.jp
連載第11回へ >>
・連載第1回

・連載第2回

・連載第3回

・連載第4回

・連載第5回

・連載第6回

・連載第7回

・連載第8回

・連載第9回

・連載第10回

・連載第11回

・連載第12回

・連載第13回

・連載第14回

・連載第15回

・連載第16回

・連載第17回