UML を用いた XML スキーマの設計

ビジネス概念を XML ボキャブラリーに取り込む

統一モデリング言語 (Unified Modeling Language: UML) は、オブジェクト指向の手法に基づいてソフトウェア・システムを構築するときに、ビジネス概念をモデル化するという段階で使われる業界標準です。最近では、XML がこの種のシステムで情報や命令をやり取りするための中心的な役割を果たすようになってきました。その結果、やり取りする XML の性質を定義・制約するしくみとして脚光を浴びるようになったのが、XML スキーマです。この記事では、XML スキーマを設計するための UML の使用例を示し、UML フレームワークを使って XML ボキャブラリーを作成する実践的な手法を説明します。

Ayesha Malik, Senior Consultant, Object Machines

Ayesha MalikAyesha Malik 氏は、Object Machinesの上級ソフトウェア・コンサルタントとして、Java、XML、Web サービスに関連した大規模なシステムを幅広く手がけており、これまでにかかわった業種は多岐にわたります。IBM developerWorks、XML.com、XML Developer Journal などでソフトウェア開発に関する記事を発表しており、O'Reilly 社のバイオインフォマティクス・コンファレンスや Web サービス・エッジ・コンファレンスにはゲスト・スピーカーとして招かれました。ハーバード大学で優等の文学士号を修得したほかに、コロンビア大学では、オペレーションズ・リサーチ、応用数学、情報科学を研究し、理学修士号を修得しています。



2003年 2月 01日

UML フレームワークを使って XML スキーマを作成するには、次の 3 つの点を検討する必要があります。

  • UML と XML スキーマの相互補完の関係
  • XML スキーマのすべての機能に対応するためのUML の拡張方法
  • UML 図からXML スキーマを構築する機能

UML と XML スキーマという 2 つのフレームワークをこのような形で組み合わせる方法を示すために、この記事では、BALTIC Shipping という架空の会社を例にとって話を進めることにします。

BALTIC Shipping は、アメリカから東ヨーロッパへのルートを専門に扱う国際的な運送会社です。ニューヨークの本社から各地の支社 (エストニアのタリン支社など)への荷物の出荷を管理するためのしくみを作るというのが、この会社の現在の課題です (図 1 を参照)。イチゴジャムなどの商品を出荷するときには、まず本社が支社に対して XML 形式の電子出荷票を送ります。支社に荷物が届くと、今度は支社が本社に対して電子確認票を送り返します。

出荷票と確認票の全データは XML 文書の形でやり取りするので、その XML 文書の様式を定義するためのスキーマが必要になります。さらに、これらの書類は、出荷状況を常に把握するための「荷物管理システム(Inventory Tracking System)」との間で情報をやり取りするときにも使われます。この記事では、XML でデータをやり取りするための書類を定義した XML スキーマを作成するときに、UML がいかに有効な手段になるかを示したいと思います。

図 1. BALTIC Shipping 社の業務の流れ
BALTIC Shipping 社の業務の流れ

UML と XML スキーマの相互補完の関係

UML のオブジェクト指向のモデリング手法は、XML スキーマの作成時に補完的な役割を果たします。UML のグラフィカルな表記法を利用すれば、ビジネス概念を簡単にモデル化できるので、そのモデルが XML スキーマ設計の開始点になるわけです。

モデル化の価値

XML スキーマの作成時に UML を利用するメリットを示そうとする場合、その前提になるのは、オブジェクト指向のモデリングに価値があるという点です。「Create flexible and extensible XML schemas」という記事の中では、オブジェクト指向の手法を使って XML スキーマを作成することの重要性と価値を説明しました。UML を利用してオブジェクト指向システムを設計する技術的なメリットとは別に、UML はビジネス・チームと技術チームが簡単にアイデアを交換するための共通手段ともなります。ビジネス分析の担当者がソフトウェア・システムの構築に果たす役割は大きくなっており、特に、特定業種に関連した情報を処理するシステムではその傾向が強いと言えます。XML 文書の設計過程にビジネス分析の担当者がかかわる以上、ビジネス分析の担当者とソフトウェア設計の担当者との共同作業がスムーズにいくかどうかは、プロジェクトの成否を左右する重要な要素になっています。UML のグラフィカルな表記法を利用すれば、技術系のスタッフと非技術系のスタッフが、たとえば「出荷票」とは何かといったビジネス概念の理解を容易に共有できるため、それが結果的にプロジェクトの成功や工期の短縮にもつながっていくわけです。

相互補完の関係

たとえば、BALTIC Shipping 社の営業部長から、社内の各種システムで情報をやり取りするための XML スキーマのモデル化を依頼されたとしましょう。まずは、この業種にかかわるビジネス概念について話し合う必要があります。紙に大まかな流れを書くこともできますが、UML を利用すれば、一定の図や表記法に基づいてビジネス概念を定型様式でモデル化できます。

図 2. UML の図
UML の図

この UML 図 (図 2) では、「出荷票 (Shipping Order)」のビジネス定義をまとめています。BALTIC Shipping 社の出荷票には、ShippingId (出荷票番号)Origin (ご依頼主)Destination (お届け先)Order (ご注文) という 4 つの項目があります。出荷票に関するデータをやり取りするときには、この必須情報が基礎データになります。さらに、この UML 図では、「Origin (ご依頼主)」や「Order (ご注文)」などの情報のデータ型も示しています。「Origin (ご依頼主)」と「Destination (お届け先)」は「Address (住所)」と同じデータ型であり、BALTIC Shipping 社では、その「Address (住所)」の情報を「Name (名前)」、「Street (街)」、「City (市)」、「Country (国)」という 4 つの項目でデータベースに格納します。これらがビジネス概念であり、データベース・モデルでも、ソフトウェア・プログラムでも、部課長やビジネス・パートナーが読む書類においても、このようなビジネス概念が使用されています。また、品目数 (「Order (ご注文)」に含める「Item (品目)」の数)、継承 (「Origin (ご依頼主)」は「Address (住所)」のすべての項目を継承する)、依存関係 (「Order (ご注文)」は「Item (品目)」の明細に依存している)などもビジネス概念に含まれており、この種の関係もすべて UML 図で表現できます。最終目標は、この出荷票の情報を記述した XML 文書を作成することなので、これから UML 図に基づく XML スキーマを設計していきます。次に示す XML スキーマは、この UML 図 (図 2) との対応関係を表現したものです。

リスト 1. ShippingOrder.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    elementFormDefault="qualified" 
    attributeFormDefault="unqualified">
      <xs:include schemaLocation="DataTypes.xsd"/>
      <xs:element name="shippingOrder">
          <xs:complexType>
             <xs:sequence>
                <xs:element name="shippingId"type="int"/>
                <xs:element name="origin" type="Origin"/>
                <xs:element name="destination" type="Destination"/>
                <xs:element name="order" type="Order"/>
             </xs:sequence>
          </xs:complexType>
      </xs:element>
</xs:schema>

リスト 1 から分かるとおり、UML の「Shipping Order (出荷票)」クラスは、スキーマの中では複合型のshippingOrder (出荷票) として記述しました。この会社の方針のとおり、「Shipping Order (出荷票)」には、shippingId (出荷票番号)Origin (ご依頼主)Destination (お届け先)Order (ご注文) という 4 つの項目を入れます。ここで注目しておきたいのは、Origin (ご依頼主) などの汎用データ型を「DataTypes(データ型)」スキーマにまとめてあるという点です (リスト 2 を参照)。「DataTypes (データ型)」ライブラリーは、「Address (住所)」の定義など、社内のさまざまなプロジェクトの XML 文書で使い回せる再利用可能なデータ型を格納しておくのに便利です。

この UML 図 (図 2) では、Address (住所) が抽象データ型になっており、その点は、「Address」という語を斜体にすることによって示してあります。Origin (ご依頼主)Destination (お届け先) というデータ型は、Address (住所) の「Name (名前)」、「Street (街)」、「City (市)」、「Country (国)」という特性を継承します。このように、再利用可能なデータ型の青写真を作成するのは、オブジェクト指向の優れた設計であると言えます。データ型の XML スキーマ (リスト 2) では、Address (住所) が抽象データ型であることを示すために、abstract="true" というキーワードを使っています。そして、Origin (ご依頼主)Destination (お届け先) のデータ型には、UML 図に倣ってextension base="Address" というキーワードを追加し、その 2 つのデータ型がAddress (住所) の特性を継承することを示すようにしました。さらに、Order (ご注文) には多数のItem (品目)が含まれるというビジネス・モデルを取り込むために、type="Item" maxOccurs="unbounded" というコードを入れてあります。

リスト 2. DataTypes.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    elementFormDefault="qualified" 
    attributeFormDefault="unqualified">
  <xs:complexType name="Address" abstract="true">
      <xs:sequence>
          <xs:element name="name" type="xs:string"/>
          <xs:element name="street" type="xs:string"/>
          <xs:element name="city" type="xs:string"/>
          <xs:element name="country" type="xs:string"/>
      </xs:sequence>
  </xs:complexType>
  <xs:complexType name="Origin">
      <xs:complexContent>
          <xs:extension base="Address"/>
      </xs:complexContent>
  </xs:complexType>
  <xs:complexType name="Destination">
      <xs:complexContent>
          <xs:extension base="Address"/>
      </xs:complexContent>
  </xs:complexType>
      <xs:complexType name="Order">
          <xs:sequence>
              <xs:element name="item" type="Item" maxOccurs="unbounded"/>
          </xs:sequence>
      </xs:complexType>
      <xs:complexType name="Item">
          <xs:sequence>
              <xs:element name="description" type="xs:string"/>
              <xs:element name="weight" type="xs:double"/>
              <xs:element name="tax" type="xs:double"/>
          </xs:sequence>
  </xs:complexType>
</xs:schema>

この XML スキーマをゼロから書くとしたら、XML でオブジェクトのデータ型を記述するだけでも大変なことになります。まして、XML スキーマの用語を知らない営業部長にきちんと説明するのは、ほとんど不可能でしょう。ところが、UML 図を使えば、会社のビジネス概念を図という形で効果的に置き換えてから、目の前にあるビジュアルな図に基づいて XML スキーマを作成できるわけです。そのスキーマに基づいて、ニューヨークからタリンにイチゴジャムの小包を送るための出荷票の XML 文書を次のように生成できます。

リスト 3. ShippingOrder.xml
<?xml version="1.0" encoding="UTF-8"?>
<shippingOrder xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="C:\schemas\ShippingOrder.xsd">
<shippingId>09887</shippingId>
<origin>
<name>Ayesha Malik</name>
<street>100 Wall Street</street>
<city>New York</city>
<country>USA</country>
</origin>
<destination>
<name>Mai Madar</name>
<street>Liivalaia 33</street>
<city>Tallinn</city>
<country>Estonia</country>
</destination>
<order>
<item>
<description>Ten Strawberry Jam bottles</description>
<weight>3.141</weight>
<tax>7.60</tax>
</item>
</order>
</shippingOrder>

基本機能

この例からだけでも UML のメリットを十分に理解できますが、BALTIC Shipping 社の例は、UML と XML スキーマとの間の相互補完の関係を示す典型的な例と言えるのでしょうか。確かに、XML スキーマが UML 図の情報をうまく取り込めるというのはすでに見たとおりですが、その逆はどうでしょうか。つまり、UML 図は XML スキーマのすべての機能に本当に対応しているのでしょうか。XML スキーマには、XML 文書の形式を設定するための機能が豊富に用意されているのは事実です。しかし、少し分析してみれば、XML スキーマの基本機能のほとんどは UML 図で表現できることを理解できます。それで、XML スキーマの重要な機能を次に取り上げてみましょう。

1. データ型
XML スキーマには、intdouble などの組み込みデータ型があります。また、先ほどのAddress (住所) の項目を表す複合型のように、記述によって生成するデータ型もあります。データ型の生成は、オブジェクト指向設計の重要な一面であり、モジュール化、柔軟性、カプセル化のための必須要件とも言えます。この点、UML では、組み込みデータ型が存在しますし、クラス構造を使って新しいデータ型を生成することも可能です。

さらに、XML スキーマにはユーザー定義データ型もあります。W3C の仕様書によれば、「ユーザー定義データ型の作成が可能であり、たとえば、既存のデータ型をベースにして一部のプロパティー(範囲、制度、長さ、形式など) を制限した派生データ型などを作成できる」となっています。こうした特殊なデータ型 (ユーザー定義データ型) については、UML でも基本プロファイルの拡張機能としてステレオタイプというものが用意されています。ステレオタイプについては、ステレオタイプによって UML を拡張するで詳しく取り上げます。

2. 属性
XML スキーマの属性は次の 2 つの点で便利です。

  • 関連付けの記述。たとえば、Order (ご注文) には多数のItem (品目)を含めることができるということを XML スキーマで表すには、maxOccurs="unbounded" と書きます。UML の場合、関連付けにはモデル内の複数のクラスがかかわっているので、関連クラス同士を矢印で結び、その関連付けに伴う数の指定を書き添えるという形でそのことを表現します。
  • 要素に本質的に付随する追加情報の記述。XML スキーマで要素と属性の組み合わせを記述する例としては、tax 要素にcurrency 属性を定義するといったことが考えられます。リスト 4 は、tax 要素にcurrency 属性を定義した一例です。
リスト 4. 属性の定義
<xs:element name="tax">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:double">
<xs:attribute name="currency" type="xs:string" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>

UML 図では、このような属性をクラスの属性として表現します。ただし、UML のクラス図では、要素と属性を区別するしくみを作る必要があります。そのためには、UML 図で「属性」という特殊なプロトタイプを作成します。

3. 名前空間
名前空間は XML スキーマの非常に重要な概念であり、ビジネス概念の区分を示すという役割を果たします。UML 図では、各モジュールを別々のパッケージに入れるという形で名前空間を表現できます。

4. 数指定
たとえば、Order (ご注文)Item (品目)との関連付けに付随する数の指定(Order (ご注文) には多数のItem (品目) を含めることができる)を UML 図で表現できることについては、すでに見たとおりです。XML スキーマでは、maxOccurs キーワードとminOccurs キーワードを使って、要素や関連付けに付随する数指定を記述できます。

5. データ型の派生
XML スキーマでは、データ型の派生について、拡張による継承と制限による継承を認めています。拡張による継承は、ごく一般的なオブジェクト指向設計であり、UML でも抽象クラスという形で簡単に表現できます(図 2 にあるとおり、抽象クラスは斜体で書きます)。ただし、UML では制限による派生を表現するための手段がありません。

両者の隔たりの分析

XML スキーマの豊富な機能をすべて UML で表現できないのは明らかです。そのため、XML スキーマを UML でモデル化した後に、ある程度の手直しが必要になります。ここで問題点を整理すると、次のようになります。

  • 順序: XML スキーマでは順序が問題になりますが、UML の伝統的な対象分野では順序の指定を必要としません。
  • 属性:基本機能で見たとおり、UML 図では属性と子要素の区別がはっきりしません。
  • 制限による派生: 伝統的な UML 図では、抽象クラスとその実装を表現できますが、XML スキーマの汎用化テクニックの一部として制限を表現するための表記法が定められていません。
  • キー: XML スキーマには文書同士を結び付けるためのキーというしくみがありますが、UML の表記法ではそのキーを表現できません。

このように両者の隔たりを分析すると明らかなとおり、UML の表記法では、XML スキーマに用意されている機能をすべて取り込むことができません。しかし、UML プロファイルには、特定分野に対応した UML モデルを構築するための汎用の拡張メカニズムが用意されています。XML スキーマの設計という分野においても、基本的な UML モデルに見られる隔たりを埋めるために UML プロファイルを拡張できます。現に Dave Carlson 氏は、そのような XSD プロファイルの 1 つを自著「Modeling XML Applications with UML」の中ですでに公開しています。


ステレオタイプによって UML を拡張する

両者の隔たりの分析で見たとおり、XML スキーマの機能を UML で表現できない分野については、その隔たりを埋めるために UML プロファイルを拡張することが必要になります。UML プロファイルには、ステレオタイプ、タグ付き値 (プロパティー)、制約という 3 つの重要な項目があります。このうち、ステレオタイプは、UML の基本クラス (「クラス」など) に新しい意味を与えるためのしくみであり、UML 図では二重の大括弧 (<< >>) で名前を囲むようにします。

たとえば、税額に通貨単位を必ず明示するというビジネス要件があるとしましょう。そのための XML は次のようになります。

<tax currency="USD">7.60</tax>

XML スキーマでこの要件を書くには、tax (税額) 要素にcurrency (通貨単位) 属性を定義することになります(リスト 4 を参照)。これに相当する UML 図を作成するには、XML スキーマの属性を表す<<XSDattribute>> と、double というデータ型を表す<<XSDsimpleType>> という 2 つの新しいステレオタイプを作成します。私は Dave Carlson 氏が作成した、UML プロファイルに対する XSD 拡張を利用しました。属性を表す拡張は次のとおりです。

<<XSDattribute>> on a UML attribute or association end
use (prohibited | optional | required | fixed)

また、complexType Tax (税額) は、simpleType double をベースにしてcurrency (通貨単位)属性を追加したデータ型です。この新しいビジネス要件を UML 図で正確に表現することも、その逆に UML 図から XML スキーマを作成することも、ステレオタイプによって可能になります。UML 図で<<XSDattribute>> というステレオタイプを利用すれば、tax (税額) 要素にcurrency (通貨単位) 属性を追加したのと同じように、weight (重量) 要素にunit (重量単位) 属性を追加するといったこともできます。このように、両者の間に完全な双方向の対応関係を確立するには、XML スキーマのさまざまな機能に対応する UML の拡張機能を作成する必要があるわけです。

図 3. ステレオタイプを使った UML 図
ステレオタイプを使った UML 図

これに相当するスキーマは次のとおりです。

リスト 5. ShippingOrder.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    elementFormDefault="qualified" 
    attributeFormDefault="unqualified">
	<xs:include schemaLocation="DataTypes2.xsd"/>
	<xs:element name="shippingOrder">
	   <xs:complexType>
		<xs:sequence>
		   <xs:element name="shippingId"/>
		   <xs:element name="origin" type="Origin"/>
		   <xs:element name="destination" type="Destination"/>
		   <xs:element name="order" type="Order"/>
		</xs:sequence>
	   </xs:complexType>
	</xs:element>
</xs:schema>
リスト 6. DataTypes2.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    elementFormDefault="qualified" 
    attributeFormDefault="unqualified">
  <xs:complexType name="Order">
      <xs:sequence>
          <xs:element name="item" type="Item" maxOccurs="unbounded"/>
      </xs:sequence>
  </xs:complexType>
  <xs:complexType name="Item">
      <xs:sequence>
          <xs:element name="description" type="xs:string"/>
          <xs:element name="weight" type="Weight"/>
          <xs:element name="tax" type="Tax"/>
      </xs:sequence>
  </xs:complexType>
  <xs:complexType name="Address" abstract="true">
      <xs:sequence>
          <xs:element name="name" type="xs:string"/>
          <xs:element name="street" type="xs:string"/>
          <xs:element name="city" type="xs:string"/>
          <xs:element name="country" type="xs:string"/>
      </xs:sequence>
  </xs:complexType>
  <xs:complexType name="Origin">
      <xs:complexContent>
          <xs:extension base="Address"/>
      </xs:complexContent>
  </xs:complexType>
  <xs:complexType name="Destination">
      <xs:complexContent>
          <xs:extension base="Address"/>
      </xs:complexContent>
  </xs:complexType>
  <xs:complexType name="Tax">
      <xs:simpleContent>
          <xs:extension base="xs:double">
              <xs:attribute name="currency" type="xs:string" use="required"/>
          </xs:extension>
      </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="Weight">
          <xs:simpleContent>
              <xs:extension base="xs:double">
                  <xs:attribute name="unit" type="xs:double" use="required"/>
              </xs:extension>
          </xs:simpleContent>
  </xs:complexType>
</xs:schema>

結果として生成される XML インスタンス文書では、品目の税額の部分に必ず currency (通貨単位) という属性が入ることになります。

リスト 7. ShippingOrder2.xml
<?xml version="1.0" encoding="UTF-8"?>
<shippingOrder
xsi:noNamespaceSchemaLocation="C:\schemas\ShippingOrder.xsd">
<shippingId>09887</shippingId>
<origin>
<name>Ayesha Malik</name>
<street>100 Wall Street</street>
<city>New York</city>
<country>USA</country>
</origin>
<destination>
<name>Mai Madar</name>
<street>Liivalaia 33</street>
<city>Tallinn</city>
<country>Estonia</country>
</destination>
<order>
<item>
<description>Ten Strawberry Jam bottles</description>
<weight unit="kg">3.14</weight>
<tax currency="US">7.16</tax>
</item>
</order>
</shippingOrder>

UML モデルから XML スキーマを生成する

UML と XML スキーマの関係を取り上げれば、UML から XML スキーマへの対応関係を記述する標準的な方法があるだろうかという問題に当然行き着きます。その方法があれば、UML 図から XML スキーマを自動的に生成できるということになります。そうであれば、その機能を用意したベンダー・ツールやオープン・ソース・ツールが出てくることでしょう。その種のツールでは、UML のメタモデルを取り込んで XML スキーマを生成するのが理想的です。そのため、モデリング・ツール間でメタデータを簡単にやり取りするための標準規格として、XML Metadata Interchange (XMI) が策定されており、この規格はさらに、変換規則に基づいて UML 図から XML DTD を生成するという作業にも応用できるようになっています。

XMI (XML Metadata Interchange) の使用例

XMI を策定したのは、ベンダーに偏らない中立的な Object Management Group (OMG) という団体です。この規格は次の 3 つの標準仕様に基づいています。

  • XML: eXtensible Markup Language (拡張マーク付け言語: W3C の標準仕様)
  • UML: Unified Modeling Language (統一モデリング言語: OMG のモデリング用標準仕様)
  • MOF: Meta Object Facility (OMG のモデリング/メタデータ・リポジトリー用標準仕様)

XMI では、この 3 つの標準仕様を統合して、リポジトリー間でメタデータをやり取りするための新しい方法を定めています。

XML 形式のメタデータを生成し、そのメタデータを XML スキーマに変換する作業をツールによって自動的に実行するときに、バック・エンドで何が起きるのかを見るために、XMI の小さなサンプルをここで取り上げましょう。リスト 8 では、基本コア・モデル要素がShippingOrder (出荷票) になっています。この図からも分かるとおり、XMI のかなり冗長な記述方式では、UML モデルに含まれるそれぞれの項目をいちいち書き出していきます。

リスト 8. ArgoUML で作成した図 2 の UML モデルから hyperModel で生成した XMI の一部
<Foundation.Core.ModelElement.name>ShippingOrder</Foundation.Core.ModelElement.name>
<Foundation.Core.ModelElement.isSpecification xmi.value="false"/>
<Foundation.Core.GeneralizableElement.isRoot xmi.value="false"/>
<Foundation.Core.GeneralizableElement.isLeaf xmi.value="false"/>
<Foundation.Core.GeneralizableElement.isAbstract xmi.value="false"/>

TogetherJ、Rational Rose、ArgoUML といったほとんどのモデルからは XMI ファイルが生成されます。ちなみに、図 2 の UML 図は、ArgoUML (オープン・ソース) によって作成したものです。ArgoUML によって生成されるプロジェクト・ファイルには XMI ファイルが含まれています。このファイルを hyperModel というツールに取り込むと、対応するスキーマの項目が生成されます(hyperModel の開発者は Dave Carlson 氏です。UML による XML スキーマのモデル化についての論議を始めた人物であり、このテーマについての著書もあります)。私は hyperModel の 30 日評価版をダウンロードしましたが、もちろん別のツールを選んでもかまいません。ただし、XML の符号化方式と UML モデルが正しいことを確認する必要があります。たとえば、hyperModel は UML モデル 1.3 に対応しています。また、生成された XML スキーマをチェックして、変換結果が正確かどうかを常に確認する必要もあります。特に新しいデータ型を使用している場合はそのチェックが欠かせません。

ArgoUML で生成した XMI を hyperModel に取り込むと、リスト 9 の XML スキーマの項目が生成されます。この内容をよく見ると、図 2で示した ArgoUML の基本的な UML モデルが hyperModel によって正確に表現されていることを確認できます。この UML は 1 つのパッケージなので、生成された XML スキーマも 1 つの名前空間になっています。Origin (ご依頼元) などのデータ型も、ShippingOrderType (出荷票データ型) のもとで参照されています。

リスト 9. XMI によって生成した ShippingOrder 要素のデータ型
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    elementFormDefault="qualified">

  <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
  <!-- Class: ShippingOrderType  -->
  <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
  <xs:element name="ShippingOrder" type="ShippingOrderType"/>
   <xs:complexType name="ShippingOrderType">
      <xs:sequence>
         <xs:element name="shippingId" type="xs:int"/>
         <xs:element name="origin">
            <xs:complexType>
               <xs:sequence>
                  <xs:element ref="Origin"/>
               </xs:sequence>
            </xs:complexType>
         </xs:element>
         <xs:element name="destination">
            <xs:complexType>
               <xs:sequence>
                  <xs:element ref="Destination"/>
               </xs:sequence>
            </xs:complexType>
         </xs:element>
         <xs:element name="order">
            <xs:complexType>
               <xs:sequence>
                  <xs:element ref="Order"/>
               </xs:sequence>
            </xs:complexType>
         </xs:element>
      </xs:sequence>
   </xs:complexType>
</xs:schema>

まとめ

世界中の 7,000 以上の金融機関に取引や決済のための電子インフラを提供する SWIFT をはじめ、多くの巨大複合組織では、UML から XML スキーマへの変換処理によって XML 文書を作成しています。UML は、特に各業界の特殊なビジネス概念をモデル化するための一番簡単な方法です。このプロセスを定式化して最終的に自動化しようというのは、すっきりとした完全な変換処理を求める観点からすれば自然な欲求でしょう。そのために、この記事では XMI の使用例を取り上げ、hyperModel などのツールによって、UML メタモデルを記述した XMI から XML スキーマを生成できることを説明しました。とはいえ、すでに書いたとおり、UML モデルの妥当性については常に手直しとダブルチェックが必要です。UML から XML スキーマへの対応関係を完全に記述する方法は未完成ですが、XML スキーマをオブジェクト指向の手法でモデル化するための開始点として、UML が優れた方法であるのは間違いありません。XML スキーマを自動生成するツール (ベーダー・ツールやオープン・ソース・ツール)の開発がこのまま進めば、UML のクラス図は、ビジネス概念を XML ボキャブラリーの中に取り込むための標準的な方法になる可能性があります。

XML がソフトウェア・システムのあらゆる部分(データのやり取り、Web サービスのメッセージ、ビルド・スクリプトの記述など) に浸透しつつある今、XML スキーマをすっきりと簡単にモデル化する方法がどうしても必要になっています。その点、UML はオブジェクト指向システムのモデリング・ツールとしてすでに定評があり、開発者にとっても、ビジネス分析の担当者にとっても、ベンダーにとっても、XML スキーマを設計する手段としてたいへん魅力があります。各業界も消費者もそれぞれの存在意義やサービスを高めるために XML を利用し始めている現状からすれば、UML の利用もますます進んでいくのは間違いなさそうです。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML
ArticleID=258841
ArticleTitle=UML を用いた XML スキーマの設計
publish-date=02012003