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がいかに有効な手段になるかを示したいと思います。

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

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

モデル化の価値

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

相互補完の関係

たとえば、BALTIC Shipping社の営業部長から、社内の各種システムで情報をやり取りするためのXMLスキーマのモデル化を依頼されたとしましょう。まずは、この業種にかかわるビジネス概念について話し合う必要があります。紙に大まかな流れを書くこともできますが、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) との対応関係を表現したものです。

                
<?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" というコードを入れてあります。

                
<?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文書を次のように生成できます。

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

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

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

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

                
<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の拡張機能を作成する必要があるわけです。

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

                
<?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>

                
<?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 (通貨単位) という属性が入ることになります。

                
<?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モデルに含まれるそれぞれの項目をいちいち書き出していきます。

                <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 (出荷票データ型) のもとで参照されています。

                
<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の利用もますます進んでいくのは間違いなさそうです。

参考文献

• XMLモデリングに関するサイトをチェックしてください。UMLからXMLへのモデリングを応用した多数のアプリケーションが紹介されています。
  
  
• Dave Carlson氏の好著「Modeling XML Applications with UML: Practical e-Business Applications」をじっくり研究してください。
  
  
• Dave Carlson氏の 「Modeling XML Vocabularies with UML」という3回シリーズの記事をお読みください。
  
  
• Will Provost氏のXML.comの記事 「UML for W3C Schema Design」をご覧ください。
  
  
• UMLとXMIを利用してソフトウェアを作成しているある組織の例について、Cameron Laird氏の「XMI and UML combine to drive product development」(developerWorks、2001年10月)をお読みください。
  
  
• Granville Miller氏のdeveloperWorks記事、『Javaモデリング』をチェックしてください。シーケンス図の書き方 (2001年5月) から始めて、UML関連のテーマを幅広く取り上げています。
  • UMLワークブック: 第1回 シーケンス・ダイアグラムへの招待
  • UMLワークブック: 第2回 シーケンス・ダイアグラムの条件付きロジック
  • UMLワークブック: 第3回 ユース・ケース・モデリングにおけるユーザー・インターフェース・ロジック
  • ホロニックなソフトウェア開発 声明書
  • ホロニックなソフトウェア開発 第2回 要件収集: ジョブに最適のプロセスを
  
  
  
• オブジェクト指向フレームワークを使って、拡張性と柔軟性とモジュラー性の高いXMLスキーマを設計する方法について、この記事の著者が書いた「Create flexible and extensible XML schemas」(developerworks、2002年10月) をお読みください。
  
  
• XMLに関する参考文献がdeveloperWorksXML zone に多数あります。
  
  
• IBM WebSphere Studio（日本語サイト） は、Javaと他の言語の両方でXML開発を自動化するツールのスイートを提供します。WebSphere Application Server と密接に統合されていますが、他のJ2EEサーバーと一緒に使用することもできます。
  
  
• XMLおよびその関連テクノロジーのIBM Certified Developer になる方法をお調べください。
  
  

著者について

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

この記事を評価する

コメント

上に戻る

目次

• UMLとXMLスキーマの相互補完の関係
• ステレオタイプによってUMLを拡張する
• UMLモデルからXMLスキーマを生成する
• まとめ
• 参考文献
• 著者について
• コメント