UML2.0で変わるモデリング作法：長瀬嘉秀のソフトウェア開発最新事情（7）

[長瀬嘉秀，テクノロジックアート]

UML2.0の仕様についてはこれまでさまざまなメディアで解説されてきたが、サポートするツールが存在しない状況では、それがどんなに便利なものであっても、絵に描いた餅（もち）に過ぎなかった。しかし、ようやくUML2.0に対応したUMLモデリングツールがいくつか登場し始めた。ツールの登場により、UML2.0で拡張された機能の意味を身をもって体験できるようになるだろう。テクノロジックアート 代表取締役社長 長瀬氏に、UML2.0の仕様拡張とそれらがモデリングに与える影響について、簡潔に語ってもらった。（アットマーク・アイティ編集局）

　UMLが登場して8年が経過した。その間に、システム開発の環境も大きく変化した。かつて、オブジェクト指向開発といえば、SmalltalkやJavaでの単体プログラム作成を指していたが、今日では、単体プログラムだけではなく、フレームワークを利用した大規模システム開発もオブジェクト指向技術で構築されるようになっている。システム開発環境の変ぼうに伴い、その設計技術であるUMLの在り方も従来どおりの仕様にとどまり続けるわけにはいかない。UMLが1.5から2.0へのバージョンアップを果たしたのは、開発環境の変化に伴う開発者のニーズの高まりからである。

　今日の開発環境に求められる要素とは何か。初めに指摘できるのは、J2EEや.NETの普及によるコンポーネント技術の導入だろう。特にJ2EE環境においては、（J2EEに）対応したフレームワークを利用すると、クラスによる設計よりもインターフェイスが重要になってくる。つまり、インターフェイス設計を中心とした開発案件が増えているということである。インターフェイス設計はインターフェイスのメソッドを定義するだけで終了すると簡単に考えがちだが、当然のことながら、（インターフェイスを使った）オブジェクト同士のやり取りも設計する必要がある。このような設計ニーズに応えるために、UML2.0ではコンポーネント図の仕様を刷新した。コンポーネント図はUML1.5にもあるが、物理的なコンポーネントの構成を表すだけだった。これと比較してUML2.0のコンポーネント図は、ソフトウェアコンポーネントの構造を表すものへとその機能を変えた。下の図はUML2.0におけるコンポーネント図の例である。

---

---

　この例では、「販売管理システム」コンポーネントと「顧客管理システム」コンポーネント、「在庫管理システム」コンポーネントを「小売」コンポーネント内の構成要素として置き、さらに、「販売管理システム」コンポーネントは、ポートを通してアセンブリコネクタで「取引先」コンポーネントと接続している。このコネクタには、ほかのコンポーネントへのリクエストを送る“要求インターフェイス”と、リクエストを受け取る“提供インターフェイス”を持っている。これらのインターフェイスを使い分けることにより、コンポーネント化されたプログラムを作成できるようになる。

　冒頭で述べたように、最近のオブジェクト指向によるシステム開発は、大規模化の傾向にある。通常、コンポーネントとは、プログラムモジュールレベルの部品とされており、UML1.xがリリースされたときも、それが開発現場の常識だったのだが、企業間システムの接続や、分散した社内システムの統合といった案件の増大は、コンポーネントの概念そのものを見直す契機となった。最近では、1つのシステムや企業のシステム全体が1つのコンポーネントと見なされる場合もある。こういう状況において、コンポーネント図の刷新は必要不可欠な要素であるというのが分かると思う。

　UML2.0における変更点として、コラボレーション図の刷新も挙げられる。UML2.0ではコラボレーション図からコミュニケーション図と名称を変更し、機能も大きく変わった。コミュニケーション図とは相互作用図の1つで、オブジェクト間のメッセージのやり取りを表す図である。相互作用図の1つであるシーケンス図が時系列的な視点でオブジェクトのやり取りを記述するのに対し、コミュニケーション図はオブジェクト（要素）間の関連を重視する。次の図は、オブジェクト間のやり取りを入れ子構造で記述している。UML2.0で可能になった機能である。これにより、実際のプログラムに合った複雑な動きが記述できるようになった。

　細かいコンポーネント設計が可能になったことで、UMLを活用したオブジェクト指向の開発プロセスは従来よりもスムーズに運用できるようになったと思う。従来、UMLで記述した分析、設計モデルはなかなかスムーズに実装段階へ移行させることができなかった。これまでは、インターフェイスの設計モデルを記述できなかったからである。新しくなったUML2.0を活用することで、このような問題点が解消する。もちろん、UML2.0はMDA（Model Driven Architecture）の実現を前提にして設計されているので、コードを自動生成できるくらいに、かなり精密に（モデル）表現することもできる。また、タイミング図が新規に追加され（ステートマシン図も大幅に拡張された）、組み込みエンジニアに対するUMLの本格利用も後押しするようになった。

---

　UMLを活用したこれまでの開発プロセスは、「アクティビティ図によるビジネスプロセス（業務フロー）の整理」から始まり、「ユースケース図による機能の明確化」「シナリオによる機能のブレークダウンからクラスの導出」を経て、「アーキテクチャのモデルへの適用」「プログラマによるコーディング」「テスト」「リリース」という流れで構成されていた。ただし、この中で、「アーキテクチャの適用」と「コーディング」フェイズの作業について、UML1.5ではサポートしておらず、エンジニアが独自の設計書を作成する必要があった。そのため、この段階で不具合があるとせっかくUMLでモデリングを行っているにもかかわらず、仕様と合わないプログラムが作成されてしまう。UML2.0では、「アーキテクチャの適用」と「コーディング」フェイズで“独自に作成していた設計書”をUMLで表現できるようになったため、不具合が起こる可能性が少なくなる。少なくともプログラマが勝手に仕様を解釈することは減るだろう。

　なお、マーチン・ファウラーが提唱するエンタープライズ・アプリケーション・アーキテクチャ（Patterns of Enterprise Application Architecture）を「アーキテクチャの適用」の段階に利用すると開発作業はかなり楽になる。実装に依存していない論理的なUMLモデルをJ2EEや.NETなどの実装技術へマッピングするには、このパターンを活用するのがいいと思う（日本語版は近日発売予定）。

　◎ 「Patterns of Enterprise Application Architecture」