チェンジビジョン
平鍋 健児

 Ivar Jacobson(イバー・ヤコブソン)氏は初期のUML(共通モデリング言語:Unified Modeling Language)設計者の一人であり、ユースケースの発明者としてオブジェクト指向の歴史に名を刻んだ人物である。本特集では、同氏みずからUMLに関する最新のアイデアを明かした解説をお届けする。UMLのこれまでと課題、今後進むべき方向性を概観するのが目的である。

 今回はイントロダクションとして、Jacobson氏がこのような考え方に至った経緯と現在のソフトウエア業界の状況を、筆者が解説する。次回からは、実際の記事の和訳をJacobson氏の許可の下に3回に分けて掲載する。

ソフトウエア開発の標準として定着

 UMLは当初、オブジェクト指向設計方法論の統一記法として標準化された。その後、ソフトウエア設計だけでなく、ビジネスプロセスの記述、システム仕様の記述など、さまざまな領域で利用され、今日に至っている。

 UMLのダイヤグラムをご覧になったことのある方は多いだろう。四角や線、矢印などのグラフィカルな記法を使って、文法と意味論を表現できる「図言語」のスタンダードとして、ソフトウエア開発に広く利用されている。

 仕様を拡張しやすい構造を目指して当初から設計されているのも、UMLの特徴である。UMLの仕様の上に「プロファイル」という形で、さまざまなドメイン(対象領域)に特有な拡張記法がつくられてきた。

 自動車業界において、次世代の車載ソフトウエアアーキテクチャの標準として注目されている「AUTOSAR(AUTomotive Open System ARchitecture)」はその一例である。車載LANとECU(エンジン・コントロールユニット)、そこで使うソフトウエアコンポーネントの配置をモデリングするもので、UMLを拡張したプロファイルとして仕様を定義している。

 AUTOSARのように実用的な産業領域における標準仕様の定義に利用されてきたことは、UMLが大きな成功を収めている要因の一つと言えよう。

仕様があまりに複雑

 一方で、UMLは大きな問題を抱えている。仕様が非常に複雑であるということだ。

 当初からUMLの仕様はかなり複雑であり、一般のソフトウエア開発者が全貌を理解するのは困難だった。UMLそのものの仕様書を見ると、仕様の複雑さが端的に分かる。

 UML自身の仕様はUMLで記述されている。このモデルを「メタモデル」(モデルのモデル、という意味)と呼ぶ。UML仕様書は、このメタモデルを解説しているのだが、これが膨大かつ難解なのだ。2006年にオーム社が出した仕様書の日本語版は、電話帳並みに900ページ近くある。

 仕様書ではクラス図の「クラス」とは何か、「属性」とは何か、といったことを自然言語とUML自身で記述している。しかし、内容は非常に複雑で相互参照が張り巡らされており、読み解くのはとても骨が折れる。

写真●チェンジビジョン社内の「UML2.0仕様書 2.1対応」
写真●チェンジビジョン社内の「UML2.0仕様書 2.1対応」(OMG著、日本語版)。厚い仕様書に大量に貼り付けられた付箋紙のメモから読解の難しさがうかがえる

 クラスという概念だけでも、他の多くの概念に依存した定義になっており、かなりの分量の仕様を読み込む必要がある。結果的に、この概念を理解するにはあちらを理解し、それを理解するには別の個所を理解しなければならない、などと数珠つなぎが起こる。

 筆者が属するチェンジビジョンは、UMLエディタ「astah」を開発していることもあり、社内にUML仕様書が複数冊ある。いずれも付箋紙が大量に貼り付けられており、エンジニアが大変な苦労をして読み解いた痕跡が残っている(写真)。