(57)【要約】拡張されたUML表記を用いてXMLアプリケーションをモデル化する方法及び装置が開示されている。本発明は、一定属性コンパートメントと呼ばれる付加的なコンパートメントを含むようUMLモデルテンプレートを拡張する。前記一定属性コンパートメントは、XML要素の一定属性がUMLモデルにおいて明示的に表わされることを可能にする。それにより、開示されている前記UMLモデルは、オブジェクトの全てのインスタンスを通して一定なままである属性を表わすのに付加的な前記一定属性コンパートメントを用いて、XML要素とXML属性とを区別することが出来る。前記XML要素の前記一定属性と可変属性とを別々にモデル化することによって、XML要素のUMLモデル化は、より明瞭且つ読み取り可能になる。本発明は、適切なソフトウェアツールによるXMLスキーマ及びソースコードの自動生成を容易にする。
2005522760.tif 000002
【特許請求の範囲】
【請求項１】
UMLモデルを用いてXMLオブジェクトを表わす方法であって、
前記XMLオブジェクトを表わすUMLモデルユニットであって、複数のコンパートメントを持つUMLモデルユニットを供給するステップ、及び
前記XMLオブジェクトの一定属性と可変属性とを表わすために前記UMLモデルユニットにおいて別々のコンパートメントを供給するステップを有する方法。
【請求項２】
前記一定属性のコンパートメントは、オブジェクトの全てのインスタンスを通して一定なままである属性を記憶することを特徴とする請求項１に記載の方法。
【請求項３】
前記可変属性のコンパートメントは、オブジェクトの異なるインスタンスに対して異なる属性を記憶することを特徴とする請求項１に記載の方法。
【請求項４】
前記一定属性は、XMLスキーマコンポーネントの属性に自動的にマップされることを特徴とする請求項１に記載の方法。
【請求項５】
前記可変属性は、XMLスキーマコンポーネントの要素に自動的にマップされることを特徴とする請求項１に記載の方法。
【請求項６】
UMLモデルからXMLスキーマを生成する方法であって、
前記XMLオブジェクトの一定属性と可変属性とを表わすための別々のコンパートメントを持つ拡張されたUMLモデルを用いて前記XMLスキーマをモデル化するステップ、及び
前記モデル化されたXMLスキーマから前記XMLスキーマを自動的に生成するステップを有する方法。
【請求項７】
前記XMLスキーマを自動的に生成する前記ステップが、一定属性をXMLスキーマコンポーネントの属性にマップするステップを更に有することを特徴とする請求項６に記載の方法。
【請求項８】
前記XMLスキーマを自動的に生成する前記ステップが、可変属性をXMLスキーマコンポーネントの要素にマップするステップを更に有することを特徴とする請求項６に記載の方法。
【請求項９】
UMLモデルからソースコードを生成する方法であって、
前記XMLオブジェクトの一定属性と可変属性とを表わすために別々のコンパートメントを持つ拡張されたUMLモデルユニットを用いて前記ソースコードをモデル化するステップ、及び
前記モデル化されたXMLスキーマから前記ソースコードを自動的に生成するステップを有する方法。
【請求項１０】
前記ソースコードを自動的に生成する前記ステップが、一定属性をクラスの一定メンバ変数にマップするステップを更に有することを特徴とする請求項９に記載の方法。
【請求項１１】
前記ソースコードを自動的に生成する前記ステップが、可変属性をクラスの一定変数以外のメンバ変数にマップするステップを更に有することを特徴とする請求項９に記載の方法。
【請求項１２】
UMLモデルを用いてXMLオブジェクトを表わすシステムであって、
コンピュータ読み取り可能なコードを記憶するメモリ、及び
前記メモリに動作的に結合されるプロセッサを有し、前記プロセッサが、
前記XMLオブジェクトを表わすUMLモデルユニットであって、複数のコンパートメントを持つUMLモデルユニットを供給し、
前記XMLオブジェクトの一定属性と可変属性とを表わすために前記UMLモデルユニットにおいて別々のコンパートメントを供給するよう構成されるシステム。
【請求項１３】
UMLモデルからXMLスキーマを生成するシステムであって、
コンピュータ読み取り可能なコードを記憶するメモリ、及び
前記メモリに動作的に結合されるプロセッサを有し、前記プロセッサが、
前記XMLオブジェクトの一定属性と可変属性とを表わすための別々のコンパートメントを持つ拡張されたUMLモデルユニット用いて前記XMLスキーマをモデル化し、
前記モデル化されたXMLスキーマから前記XMLスキーマを自動的に生成するよう構成されるシステム。
【請求項１４】
UMLモデルからソースコードを生成するシステムであって、
コンピュータ読み取り可能なコードを記憶するメモリ、及び
前記メモリに動作的に結合されるプロセッサを有し、前記プロセッサが、
前記XMLオブジェクトの一定属性と可変属性とを表わすための別々のコンパートメントを持つ拡張されたUMLモデルユニット用いて前記XMLスキーマをモデル化し、
前記モデル化されたXMLスキーマから前記ソースコードを自動的に生成するよう構成されるシステム。
【請求項１５】
UMLモデルを用いてXMLオブジェクトを表わす製品であって、
その上で実施されるコンピュータ読み取り可能なコード手段を持つコンピュータ読み取り可能な媒体を有し、前記コンピュータ読み取り可能なプログラムコード手段が、
前記XMLオブジェクトを表わすUMLモデルユニットであって、複数のコンパートメントを持つUMLモデルユニットを供給するステップ、及び
前記XMLオブジェクトの一定属性と可変属性とを表わすために前記UMLモデルユニットにおいて別々のコンパートメントを供給するステップを有する製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、XMLアプリケーションをモデル化する方法及び装置に関し、より詳細には、UML表記を用いてXMLアプリケーションをモデル化する方法及び装置に関する。
【背景技術】
【０００２】
ワールド・ワイド・ウェブコンソーシアム(World Wide Web Consortium(W3C))によって推奨されている拡張可能なマーク付け言語(Extensible Markup Language(XML))は、テキスト情報を符号化するための普及している規格である。XML規格の解説については、例えば、Extensible Markup Language (XML) 1.0 W3C Recommendation, http://www.w3.org/TR/1998/REC-xml-19980210参照。XML規格は、XML使用可能アプリケーションが符号化情報のやりとりのために他に規格準拠のシステムと相互動作することを可能にする。
【０００３】
XMLが情報技術の専門家に普及するにつれて、XMLアプリケーションを正確にモデル化する能力がますます重要になっている。現在、ほとんどのXMLアプリケーションは、www.omg.org/umlに記載されている、オブジェクト管理グループ(OMG)によって規格化された統一モデル化言語(Unified Modeling Language(UML))を用いてモデル化されている。  
【０００４】
UML規格に基づいてモデル化されるアプリケーションのためのソースコードは、Java及びC++などの多数の一般的なプログラミング言語においては、利用可能なUMLツールを用いて自動的に生成され得ることから、UMLモデル化は、とりわけ望ましい。更に、XMLの文書型定義(Document Type Definition(DTD))が、利用可能なXMLメタデータ交換(XML Metadata Interchange(XMI))技術を用いて、UMLモデルから生成され得る。  
【０００５】
図１は、オブジェクトをモデル化するための現在のUML表記を図示している。図１に示されているように、クラス要素(class element)は、３つのコンパートメント１１０、１２０、１３０を持つユニット１００を用いるUMLで表される。クラス名コンパートメント１１０は、対応するクラスの名前を記録する。属性コンパートメント１２０は、１つ以上の属性名及びそれらの対応するタイプを示す。操作コンパートメント１３０は、１つ以上の操作名をそれらの対応する署名と共に示す。
【０００６】
UML規格は、元々、オブジェクト指向のアプリケーションをモデル化するために開発された。図１に示されている表記は、クラスが属性及び操作のセットを持つオブジェクト指向のアプリケーションにおけるオブジェクトのモデル化の場合にうまく機能する。しかしながら、分散コンピューティングの使用の増大に伴って、固有のクラス識別子などのクラスの一定属性が、このようなクラス又はこのクラスのインスタンスを識別するのに重要になっている。それ故、クラスの一定属性がUMLモデルにおいて明示的に示されることを可能にするUMLモデルの拡張の必要性がある。更に、XML文書又はアプリケーションのオブジェクトがより正確に表現されることを可能にする方法及び装置の必要性がある。  
【０００７】
UML又はUMLの変形体(variation)を用いてXMLアプリケーションをモデル化するための多くの技術が提案又は提唱されている。UMLを用いてXMLアプリケーションをモデル化するための従来の技術の解説については、例えばDavid CarlsonのModeling XML Applications with UML - Practical e-Business Applications, Addison-Wesley (2001)参照。XMLデータ自体は、動作(behavior)又は操作を持たず、属性及び要素しか持たない。一般に、XMLデータの基本ユニットは要素である。要素は、値若しくはそれ自体の属性（又は両方）を持つ。しかしながら、現在のUML表記においては、XMLの要素と属性とを区別することは困難である。なぜなら、典型的にはそれらが属性コンパートメント１２０内に置かれるからである。
【発明の開示】
【課題を解決するための手段】
【０００８】
広くは、拡張されたUML表記を用いてXMLアプリケーションをモデル化する方法及び装置が開示されている。本発明は、本明細書では一定属性コンパートメントと呼ばれる付加的なコンパートメントを含むようUMLモデルテンプレートを拡張する。前記一定属性コンパートメントは、XML要素の一定属性がUMLモデルにおいて明示的に表されることを可能にする。この方法において、開示されているUMLモデルは、一般にXML要素タイプの全てのインスタンスを通して一定なままである属性を記憶するのに付加的な前記一定属性コンパートメントを用いてXML要素とXML属性とを区別する。 
【０００９】
本発明は、前記XML要素タイプの要素と属性とを別々にモデル化することによって、XML要素のUMLモデル化をより明瞭に且つ読み取り可能にする。更に、本発明は、適切なソフトウェアツールによるXMLスキーマ及びソースコードの自動生成を容易にする。XMLスキーマを自動的に生成するのに本発明の拡張UMLモデルテンプレートを用いるXMLスキーマジェネレータ(XML schema generator)が開示されている。所与のプログラミング言語においてソースコードを生成するのに本発明の拡張UMLモデルテンプレートを用いるソースコードジェネレータが開示されている。
【００１０】
以下の詳細な説明及び図面を参照することによって、本発明のより完全な理解、並びに本発明の他の特徴及び利点のより完全な理解が得られるであろう。
【発明を実施するための最良の形態】
【００１１】
以下に記載されているように、本発明は、UMLモデルにおいてクラスの一定属性が明示的に示されることを可能にするようUMLモデルを拡張する。このようにして、本発明は、XML文書又はアプリケーションのオブジェクトがより正確に表現されることを可能にする方法及び装置を提供する。詳細には、開示されているUMLモデルは、一般にXML要素タイプの全てのインスタンスを通して一定なままである属性を収容する付加的な一定属性コンパートメントを挿入することによってXML要素とXML属性とを区別する。
【００１２】
UMLにおいては、属性はクラスのメンバ／データ変数である。これらの属性は、クラス識別名(class identification)などの一定属性とオブジェクトごとに異なる可変属性との２つのカテゴリに分けられ得る。ここで、我々が述べる属性は、UML属性であって、XML属性ではない。
【００１３】
UMLによるXMLアプリケーションのモデル化
UML又はUMLの変形体を用いてXMLアプリケーションをモデル化するための多くの技術が提案又は提唱されている。図２は、UMLを用いてXMLアプリケーションをモデル化するための１つの従来のアプローチを図示している。図２に示されているように、例示的なクラス名コンパートメント２１０は、対応するクラス又は要素の名前PatientNameを記録する。属性コンパートメント２２０中のlabelフィールド及びidフィールドは、要素PatientNameの属性を保持する。patient_nameフィールドは、要素PatientNameの値を保持する。図２に示されているように、XMLスキーマ２４０はUMLクラスモデル２００から手入力で生成される。操作コンパートメント２３０は、XMLオブジェクトのモデル化のためには用いられない。最後に、スキーマの実際のインスタンス２５０がXMLスキーマ２４０を用いて生成され得る。
【００１４】
図２に示されている第１アプローチでの問題は、属性コンパートメント２２０中のどのフィールドがXML要素又は属性にマップされるのかをモデル自体が示さないことにある。
【００１５】
図３は、UMLを用いてXMLアプリケーションをモデル化するための別の従来のアプローチを図示している。図３に示されているように、例示的なクラス名コンパートメント３１０は、対応するクラス又は要素の名前PatientNameを記録する。属性コンパートメント３２０中のlabelフィールド及びidフィールドは、要素PatientNameの属性を保持する。patient_nameフィールドは、要素PatientNameの値を保持する。図２の第１アプローチとは異なり、labelフィールド、idフィールド及びpatient_nameフィールドは、属性又は要素であるとしてマーク付けされる。図３に示されているように、XMLスキーマ３４０はUMLクラスモデル３００から手入力で生成される。操作コンパートメント３３０は、XMLオブジェクトのモデル化のためには用いられない。最後に、スキーマの実際のインスタンス３５０がXMLスキーマ３４０を用いて生成され得る。
【００１６】
図３に示されている第２アプローチでの問題は、モデルがあまりに冗長であり、そのターゲットを評価するために各UML属性にマッピングルールが適用されなければならないことにある。UML属性の使用法(usage)は指定され得ない。 
【００１７】
図４は、各XML要素を表わすのに２つのUMLユニットが用いられるUMLを用いてXMLアプリケーションをモデル化するための更に別の従来のアプローチを図示している。第１ユニット４００−１は、要素についての可変属性情報を保持し、第２ユニット４００−２は、要素についての一定属性情報を保持する。図４に示されているように、第１ユニット４００−１の例示的なクラス名コンパートメント４１０−１は、対応するクラス又は要素の名前PatientNameを記録する。属性コンパートメント４２０−１中のpatient_nameフィールドは、要素PatientNameの値を保持する。  
【００１８】
第２ユニット４００−２の属性コンパートメント４２０−２中のlabelフィールド及びidフィールドは、要素PatientNameの一定属性を保持する。図４に示されているように、XMLスキーマ４４０はUMLクラスモデル４００−１、２から自動的に生成され得る。操作コンパートメント４３０は、XMLオブジェクトのモデル化のためには用いられない。スキーマの実際のインスタンス（図示せず）はXMLスキーマ４４０を用いて生成され得る。
【００１９】
図４に示されている第３アプローチでの問題は、モデルが、属性を規定するのに別個の付加的なクラスを必要とすることにある。
【００２０】
XMLアプリケーションをモデル化するための拡張UML
図５は、XML要素をモデル化するための本発明による新しいUML表記を図示している。図５に示されているように、XML要素は、４つのコンパートメント５１０、５２０、５３０、５４０を持つUMLユニット５００を用いて表わされる。クラス名コンパートメント５１０は、対応するクラスの名前又はXML要素タイプを記録する。クラス名コンパートメント５１０は、XML構造におけるsimpleType及びcomplexTypeなどのステレオタイプが指定されることを可能にする（例えばXMLスキーマ定義言語、www.w3c.org/XML/Schema参照）。
【００２１】
一定属性コンパートメント５２０は、全てのPatientNameインスタンスを通して一定なままであろう一定属性を指定する。可変属性コンパートメント５３０は、異なるPatientNameインスタンスに対しては異なるであろう可変属性を指定する。操作コンパートメント５４０は、１つ以上の操作名をそれらの対応する戻りタイプ及びパラメータと共に示し、XMLタイプを規定する際には典型的には空である。コンパートメント５２０においては、<<0..1>>が、随意的なものとして属性ラベルの使用法を指定する。同様に、他の属性の使用法もまた指定され得る。括弧“<<
>>”内の数字は所与の属性の最大発生数及び最小発生数を指定する。
【００２２】
拡張UMLモデルのアプリケーション
ひとたび、UMLモデルが本発明に基づいてUMLモデルテンプレート５００を用いて構築されれば、XMLスキーマ及び所与のプログラミング言語におけるソースコードは、図６及び７に図示されているように付加的なマッピングルールと一緒に既存のツールを用いて自動的に生成され得る。
【００２３】
図６は、UMLモデルテンプレート５００を用いてXMLスキーマ６５０を生成するXMLスキーマジェネレータ６００を図示している。XMLスキーマジェネレータ６００は、例えば、当業者にとっては明らかであろうように、本発明の修正表記／テンプレートを取り入れるために本明細書で修正されているように、http://www.alphaworks.ibm.com/tech/xmiframeworkに記載されている、株式会社IBMから市販されているXMLメタデータ交換(XMI)ツールキット、又はwww.xmlmodeling.comに記載されている、株式会社XMLModelingから市販されているHyperModel(登録商標)アプリケーションなどの同様のツールを用いるコンピュータ又はワークステーションとして実施され得る。
【００２４】
１つの例示的な実施例においては、XMLスキーマジェネレータ６００は、そのステレオタイプに基づいてcomplexType、要素又はsimpleTypeなどのXMLスキーマコンポーネントにUMLクラスをマップする。一定属性は、このコンポーネントの属性にマップされる。同様に、可変属性は、このコンポーネントの要素にマップされる。
【００２５】
図７は、UMLモデルテンプレート５００を用いてJavaソースコード７５０−１、７５０−２を生成するソースコードジェネレータ７００を図示している。ソースコードジェネレータ７００は、例えば、当業者にとっては明らかであろうように、本発明の修正表記／テンプレートを取り入れるために本明細書で修正されているように、http://www.rational.comに記載されている、株式会社Rational Softwareから市販されているRational
Rose(登録商標)のツール、又はwww.popkin.comに記載されている、株式会社Popkin Softwareから市販されているSystem
Architect(登録商標)などの同様のツールを用いるコンピュータ又はワークステーションとして実施され得る。  
【００２６】
ここで図８を参照すると、本発明の実施例を実行するのに適した例示的なシステム８００のブロック図が示されている。システム８００は、図５乃至７に開示されている方法及びシステムの幾つか又は全てのために用いられ得る。システム８００は、コンピュータシステム８１０及びコンパクトディスク(登録商標)（ＣＤ）８５０を有する。コンピュータシステム８１０は、プロセッサ８２０、メモリ８３０及びビデオディスプレイ８４０を有する。
【００２７】
当業界では既知であるように、本明細書に記載されている方法及び装置は、その製品自体が、その上で実施されるコンピュータ読み取り可能なコード手段を持つコンピュータ読み取り可能な媒体を有する製品として配布され得る。コンピュータ読み取り可能なプログラムコード手段は、コンピュータシステム８１０などのコンピュータシステムと一緒に、本明細書に記載されている装置を作成する又は方法を行なうためのステップの全て又は幾つかを実行するよう動作可能である。コンピュータ読み取り可能な媒体は、記録可能な媒体（例えば、フロッピーディスク(登録商標)、ハードディスク、コンパクトディスク(登録商標)又はメモリカード）又は伝送媒体（例えば、光ファイバ、ワールド・ワイド・ウェブ、ケーブル、又は時分割多重接続、符号分割多重接続若しくは他の無線周波数チャネルを用いる無線チャネルを有するネットワーク）であり得る。コンピュータシステムでの使用に適した情報を記憶することが出来る既知の又は先進のあらゆる媒体が用いられ得る。コンピュータ読み取り可能なコード手段は、磁気媒体における磁気変動又はコンパクトディスク(登録商標)８５０などのコンパクトディスク(登録商標)の表面における高さ変動などの、コンピュータが命令及びデータを読み取ることを可能にする任意の機構である。
【００２８】
メモリ８３０は、プロセッサ８２０が本明細書に開示されている方法、ステップ及び機能を実施するよう構成する。メモリ８３０は、分散型のもの又はローカルなものであり得る。プロセッサ８２０は、分散型のもの又は単一のものであり得る。メモリ８３０は、電気的、磁気的若しくは光学的なメモリ又はこれら若しくは他のタイプの記憶装置の任意の組み合わせとして実施され得る。更に、「メモリ」という用語は、プロセッサ８１０によってアクセスされるアドレス指定可能な空間中のアドレスから読み取られ得る又は該アドレスに書き込まれ得るあらゆる情報を包含するよう十分に広く解釈されるべきである。この定義では、ネットワーク上の情報は依然としてメモリ８３０内にある。なぜならプロセッサ８２０はネットワークから情報を取り出すことが出来るからである。プロセッサ８２０を構成する各分散プロセッサは一般に該分散プロセッサ自身のアドレス指定可能なメモリ空間を含むことに注意されたい。コンピュータシステム８１０の幾つか又は全てが、特定用途集積回路又は汎用集積回路に組み込まれ得ることにも注意されたい。
【００２９】
ビデオディスプレイ８４０は、システム８００の人間のユーザと対話するのに適した任意のタイプのビデオディスプレイである。一般に、ビデオディスプレイ８４０は、コンピュータモニタ又は他の同様なビデオディスプレイである。
【００３０】
本明細書に図示され、記載されている実施例及び変形例は、単に本発明の原理を例示するだけのものであって、当業者によって本発明の範囲及び精神から外れることなしに様々な変形例が実施され得ることを了解されたい。  
【図面の簡単な説明】
【００３１】
【図１】現在のUMLモデルに基づいてオブジェクトを表わす従来のユニットを図示する。
【図２】UML又はUMLの変形体を用いてXMLアプリケーションをモデル化する第１の従来のアプローチを図示する。
【図３】UML又はUMLの変形体を用いてXMLアプリケーションをモデル化する第２の従来のアプローチを図示する。
【図４】UML又はUMLの変形体を用いてXMLアプリケーションをモデル化する第３の従来のアプローチを図示する。
【図５】XML要素をモデル化するための本発明による新たなUML表記を図示する。
【図６】本発明のUMLモデルテンプレートを用いてXMLスキーマを生成するXMLスキーマジェネレータを図示する。
【図７】本発明のUMLモデルテンプレートを用いて所与のプログラミング言語におけるソースコードを生成するソースコードジェネレータを図示する。
【図８】本発明の全て又は一部を実施するのに適したシステムのブロック図である。
【図１】
2005522760.tif 000003
【図２】
2005522760.tif 000004
【図３】
2005522760.tif 000005
【図４】
2005522760.tif 000006
【図５】
2005522760.tif 000007
【図６】
2005522760.tif 000008
【図７】
2005522760.tif 000009
【図８】
2005522760.tif 000010
【国際調査報告】
2005522760.tif 000011
2005522760.tif 000012