NIEM IEPD を作成する: 第 1 回 NIEM 情報交換モデルの作成

米国政府機関の間での XML 情報交換を設計する

NIEM (National Information Exchange Model) は、米国政府とその情報交換先との間での最も重要な XML ベースの情報交換標準として、急速にその地位を固めつつあります。4 回連載の 1 回目となるこの記事では、初めに NIEM 情報交換の定義プロセスについて概説した後、早速最初のステップに取り掛かります。最初のステップは、NIEM のモデリングの概念に特に配慮しながら UML を使って情報交換のモデルを作成することです。このプロセスを、単純な事例研究を用いて説明します。

2010年 5月 18日: 「はじめに」、「まとめ」、および「参考文献」の各セクションに、連載第 4 回のリンクを追加。

2010年 3月 09日: 「はじめに」、「まとめ」、および「参考文献」の各セクションに、連載第 3 回のリンクを追加。

2010年 2月 09日: 「はじめに」、「まとめ」、および「参考文献」の各セクションに、連載第 2 回のリンクを追加。

Priscilla Walmsley, Managing Director, Datypic

Photo of Priscilla WalmsleyPriscilla Walmsley は、Datypic の取締役兼シニア・コンサルタントです。彼女の専門は XML 技術、設計、および実装で、最近では (Trusted Federal Systems を通じて) 米国司法省に協力し、NIEM ベースの IEPD フレームワーク、LEXS に取り組みました。著書には『Definitive XML Schema』(Prentice Hall、2001年)、『XQuery』(O'Reilly Media、2007年) があります。また、『Web Service Contract Design and Versioning for SOA』(Prentice Hall、2008年) の共著者でもあります。



2010年 5月 17日 (初版 2010年 1月 19日)

NIEM (National Information Exchange Model) は、米国政府が後援する、公共および民間部門の組織間での情報共有を促進するためのイニシアチブです。当初、その焦点は法執行、公安、危機管理に置かれていましたが、NIEM は他の分野 (ドメイン) にも拡大され続けています。米国司法省と米国国土安全保障省、そして米国政府のその他の部門で新しく開始される XML イニシアチブでは、NIEM を共通の基本データ・モデルおよび方法論として使用し、データおよびソフトウェアの相互運用性の促進、情報交換アプリケーションの設計および開発時間の短縮を図るとともに、さまざまなプロジェクトで知的資本とスキルを再利用できるようにしています。

NIEM はフレームワークとして表現されます。その理由は、NIEM は単なる情報交換のための XML 語彙ではなく、以下のコンポーネントを備えているためです。

  • NIEM コア。XML ベースの共通データ・モデルとして、人や場所、活動、組織などの汎用オブジェクトを記述するためのデータ・コンポーネントを提供します。
  • ドメイン。個々の使用事例に合わせて作成された XML データ・モデルです。ドメインの例には、司法、入国管理、危機管理などがあります。
  • 共通モデルおよびドメイン固有のモデルが提供する基本要素を使用および拡張し、情報交換パッケージと呼ばれる完全な情報交換に変換するための方法論
  • 情報交換パッケージの開発、検証、文書化、および共有を支援するためのツール
  • 指導および支援を行い、NIEM の進化を監視する管理機構

4 回連載の第 1 回目となるこの記事では、NIEM の概要を説明し、UML (Unified Modeling Language) を使用して NIEM IEPD (Information Exchange Package Documentation) のモデルを作成する方法を説明します。作業用の UML モデルと完成版 UML モデルは「ダウンロード」セクションから入手できます。

NIEM の利用方法

NIEM XML データ・モデルは、共通オブジェクトの基本要素を提供します。これらの要素はかなり細分化されていることも (「個人の名前」や「誕生日」など)、それより遥かに複雑なコンポーネント (「逮捕」、「訴訟」など) であることもあります。けれども NIEM モデル自体が「逮捕報告書」や「疑わしい取引の報告書」のような完結した情報交換メッセージを定義することはありません。NIEM は特定のメッセージ・タイプも、XML 文書のルート要素も指定していません。

NIEM を実際に使用するには、IEPD を作成する必要があります。IEPD が NIEM コア・モデルやドメイン・モデルから必要なコンポーネントを取得し、これらのコンポーネントを拡張して情報交換を完成させます。IEPD は、以下の成果物で構成されます。

  • 情報交換で使用される NIEM モデルのサブセットを定義する XML スキーマ。サブセット・スキーマと呼ばれます。
  • 情報交換のルート要素を定義するスキーマ。交換スキーマと呼ばれます。
  • NIEM モデルの拡張を定義するスキーマ。拡張スキーマと呼ばれます。
  • 情報交換の資料。例えば UML 図、説明的記述、サンプルなどがあります。

IEPD の開発

情報交換プロジェクトにおける最初のタスクは、該当する要件を収集し、分析することです。NIEM では要件の定義方法を規定していないので、このプロセスについては説明しません。この記事では、皆さんが実際に IEPD の作成に取り掛かる前に、どのデータ要素を交換したいのか、データ要素をどのようなタイプのメッセージに構造化するのかについて考えがまとまっていることを前提とします。

この連載の記事では、単純な例を用いて IEPD の開発手順を初めから終わりまで説明し、最終的に完全な IEPD に仕上げます。例として用いる事例研究では、登録車両を対象とした単純な盗難報告書を実装します。仮定として、現地の警察はこの盗難報告書を使用して、自動車管理局や市の自転車登録局などの関係機関に自動車および自転車の盗難を報告します。私は要件を収集する段階で、共有する必要のあるデータに関する一般情報を収集し、その情報を基に、この例に必要なメッセージ・タイプは盗難報告書だけであると判断しました。けれども実際には、IEPD の多くは複数の関連するメッセージ・タイプで構成されます。

NIEM の主要目的は、データの相互運用性です。したがって、新しい IEPD を一から作成する前に、既存の IEPD を再利用できないかどうかを検討することに意味があります。NIEM では、他の組織から提出された既存の IEPD を検索できる、IEPD 情報センターを用意しています。IEPD 情報センターへのリンクは、「参考文献」を参照してください。

既存の IEPD のなかに要求を満たす IEPD のなかに要求を満たす IEPD が見つからない場合には、新しく IEPD を作成しなければなりません。新しい NIEM IEPD を開発するには、以下の 5 つのステップに従います。

  1. 情報交換のモデルを作成する
  2. 作成した情報交換モデルを NIEM データ・モデルにマッピングする
  3. 情報交換で使用する NIEM モデルのサブセットを作成する
  4. カスタム・コンポーネントを記述する交換スキーマと拡張スキーマを作成する
  5. 該当するすべての成果物を 1 つの IEPD にアセンブルする

この記事で説明するのはステップ 1 です。連載の以降の記事で、ステップ 2 からステップ 5 までを説明します。既存の IEPD を再利用することにしたとしても、使用する IEPD の内容と構造を理解する上でこの連載が参考になります。


NIEM モデルの概要

情報交換のモデルの作成に取り掛かる前に NIEM データ・モデルの構造を理解しておくと、モデルを作成しやすくなります。NIEM が定義する概念 (型、プロパティー、関連など) は、他のデータ・モデリング・パラダイムを参考にすると理解しやすいはずです。

NIEM モデルの概念

型は有形の対象も、無形の対象も表します。NIEM モデルの最も基本的な型には PersonTypeActivityTypeItemTypeLocationTypeOrganizationType があります。その他にも数千の型があり、その細分度もさまざまです。NIEM モデルの型は、他のモデリング・パラダイムでのクラス、あるいはエンティティーに該当します。

プロパティーは型の属性で、プロパティー自体に複合型を含めることもできます。例えば、PersonNamePersonType のプロパティーですが、このプロパティー自体にも PersonNameType 型が含まれています。さらにこの PersonNameType 型も独自の構造をしており、PersonGivenNamePersonSurName などが含まれています。

ある型から別の型を派生させた場合、その型のプロパティーを継承させることができます。これは、オブジェクト指向モデルでの汎化のようなものです。例えば一般的な型である ItemType には、VehicleTypeJewelryType、および RealEstateType をはじめ、多数の派生型があります。

関連とは、2 つの型の間にある関係のことです。例えば IncidentPerson の間や、PersonLocation の間には関連がある可能性があります。NIEM では、関連とそれに関連する型とは切り離されます。

ロールは、ある型が特定のコンテキストで持つ可能性がある一時的な所属を表します。盗難事件を例にとると、個人が持つロールには Victim (被害者)、Subject (容疑者)、または Witness (目撃者) が考えられます。

増補 (augmentation) とは、再利用および共有できるプロパティーを集めたバンドルのことです。それぞれの IEPD で使用されるというよりは、NIEM ドメイン・モデルで一般的に使用されます。

メタデータは、メッセージの内容に関する情報です (その情報がいつ収集されたのか、その情報にどれだけの信頼性があるのかなど)。NIEM モデルには、データとメタデータとの関連付けに関する特殊な規定が設けられています。

XML での NIEM モデル

NIEM モデルは完全に W3C XML Schema 文書一式として実装されています。どれが型で、どれが関連であるかなどは、XML Schema 内のアノテーションと参照によって指定されていますが、幸い、モデルをナビゲートするのに XML Schema 文書自体を読む必要はありません。NIEM には見た目にわかりやすい方法でモデルを検索し、ナビゲートするためのツールがあるからです。

通常、NIEM の型は XML Schema の複合型として実装され、これらの型に含まれる要素がプロパティーとなります。リスト 1 に、あるアクティビティーを ActivityType という複合型を使って表す方法を示します。ここでは、ActivityIdentification および ActivityCategoryText などのプロパティーが子要素として実装されています。

リスト 1. XML Schema での NIEM ActivityType の実装 (一部)
<xsd:complexType name="ActivityType">
 <xsd:complexContent>
  <xsd:extension base="s:ComplexObjectType">
   <xsd:sequence>
    <xsd:element ref="nc:ActivityIdentification" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element ref="nc:ActivityCategoryText" minOccurs="0" maxOccurs="unbounded"/>
    <!-- ... -->
   </xsd:sequence>
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

NIEM では、XML Schema 拡張を使用して型を派生させます。リスト 2 に、ActivityType から、より具体的なアクティビティー (AssessmentType 複合型) を派生させる方法を示します。

リスト 2. XML Schema での NIEM の型の派生
<xsd:complexType name="AssessmentType">
 <xsd:complexContent>
  <xsd:extension base="nc:ActivityType">
   <xsd:sequence>
    <xsd:element ref="nc:AssessmentScoreText" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element ref="nc:AssessmentFee" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element ref="nc:AssessmentProgram" minOccurs="0" maxOccurs="unbounded"/>
    <!-- ... -->
   </xsd:sequence>
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

関連は、それが関連付ける型への参照が含まれる特殊な種類の複合型です。リスト 3 に、個人とアクティビティーとの間の関連 (ActivityPersonAssociationType) を実装する方法を示します。すべての関連型は、NIEM コアである AssociationType を (直接または間接的に) 継承します。

リスト 3. XML Schema での NIEM 関連型
<xsd:complexType name="ActivityPersonAssociationType">
 <xsd:complexContent>
  <xsd:extension base="nc:AssociationType">
   <xsd:sequence>
    <xsd:element ref="nc:ActivityReference" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element ref="nc:PersonReference" minOccurs="0" maxOccurs="unbounded"/>
   </xsd:sequence>
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

情報交換のモデルの作成

NIEM では、XML 情報交換のモデルを作成するために特定の手順やダイアグラムの類を使用することも、さらには XML 情報交換のモデルを作成することさえも要件としていません。それでも、モデルの作成は IEPD を設計する上で重要なステップです。モデルの作成プロセスによって要件が具体化され、その結果、ビジネス・ユーザーと技術ユーザーの両方にとって役立つ資料が完成します。さらに IEPD 作成プロセスの以降のステップでも、モデルは有用な情報となります。

モデリング・パラダイムを選択する

UML ツールの使用

UML を使用することにした場合、IBM® Rational® Modeler や ArgoUML などのXMI 対応の UML ツールを利用できるという利点があります。XMI によって、マッピング・スプレッドシートを自動的に生成し、次のステップで使用できるためです。この記事では、オープンソースの UML エディターである ArgoUML を使用しました。

モデリング・パラダイムの有力候補は UML、具体的には UML クラス図です。UML の概念は、NIEM モデルの概念に容易に対応させることができるからです。もちろんユース・ケース図やシーケンス図などの他の UML の図を作成して情報交換を文書化することもできますが、クラス図は IEPD 開発プロセスにとりわけ重要であることから、この記事では UML クラス図に焦点を絞ります。

モデルを作成する最善の方法は、最初は NIEM モデルに合わせようとはせずに、モデルのドラフトを単独で作成することです。この時点では、NIEM 流のやり方に過度に影響されることなく、それぞれのビジネス・ニーズに最適なモデルにしてください。IEPD プロセスの後のほうで、NIEM とより協調させるためにモデルに多少の変更を加えるのは (それが妥当な場合には) 珍しいことではありません。ただし、独自のモデルと NIEM モデルとの間には必ず違いがあるものです。

型とプロパティー

この記事では UML のモデリングに関するすべてを紹介することはできないため、ここでは NIEM に特有の内容に焦点を絞ります。ご想像のとおり、クラス図のなかで NIEM の型を表すのはクラスです。そしてクラスの属性が、プロパティーを表します。

この事例研究で交換する必要があるとして私が判断したクラスは、Theft (盗難事件)、MotorVehicle (自動車)、Bicycle (自転車)、Victim (被害者)、Witness (目撃者)、TheftLocation (盗難場所) です。図 1 に、これらの型をそれぞれのプロパティーと併せて示します (図 1 をテキストで表現したものを見る)。

図 1. 型およびプロパティーからなる初期の UML モデル
型 (Theft、MotorVehicle、Bicycle、Victim、Witness、TheftLocation) および各型のプロパティーで構成された初期の UML モデル
型 (Theft、MotorVehicle、Bicycle、Victim、Witness、TheftLocation) および各型のプロパティーで構成された初期の UML モデルのテキスト・バージョン (図 1)

リスティングを見るにはここをクリック

型 (Theft、MotorVehicle、Bicycle、Victim、Witness、TheftLocation) および各型のプロパティーで構成された初期の UML モデルのテキスト・バージョン (図 1)

_____________________
|    TheftLocation   |  ___________________________ 
|____________________|  |       TheftLocation      |
| Address : string   |  |__________________________|                _________________________   _________________________
| City : string      |  | TheftDateTime : dateTime |                |     MotorVehicle       |  |        Bicycle         |
| State : string     |  |__________________________|                |________________________|  |________________________|
| ZipCode : string   |                                              | SerialNumber : integer |  | SerialNumber : integer |
| CountyCode : code  |                                              | Description : string   |  | Description : string   |
|____________________|                                              | Color : string         |  | Color : string         |
            _________________________   _________________________   | LicensePlate : string  |  | IsRegistered : boolean |
            |         Victim         |  |        Witness         |  | VehicleCategory : code |  |________________________|
            |________________________|  |________________________|  |________________________|
            | FirstName : string     |  | FirstName : string     |
            | LastName : string      |  | LastName : string      |
            | DriverLicense : string |  | DriverLicense : string |
            |________________________|  | Account : string       |
                                        |________________________|

プロパティーのデータ型を指定する際には、XML Schema の基本データ型を使用すると役立ちます。その理由は、プロパティーは最終的に XML Schema で表されるので、作成する独自のモデルのプロパティーに基本データ型を使用すれば、データ型の共通セットを使用する際に、既存の NIEM モデルが独自のモデルに適合するかどうかを容易に判断できるためです。表 1 に、最もよく使用されている XML Schema のデータ型を記載します。

表 1. よく使用される XML Schema のデータ型
データ型の名前説明
string任意のテキスト・ストリングabc, this is a string
integer任意の大きさの整数1, 2
decimal10 進数1.2, 5.0
dateYYYY-MM-DD 形式の日付2009-12-25
timeHH:MM:SS 形式の時刻 (24 時間形式の時計)12:05:04
booleantrue または false の値true, false

一部のプロパティーには有効な値の列挙型リスト (別名、コード・リスト) がある場合もあります。コード・リストの値は UML モデルでコメントに記述することも、別個のシステム・ドキュメントに文書化することもできます。この例ではモデルを簡潔にしておくために、コード・リストを持つプロパティーは単にデータ型 code を持つプロパティーとして記載し、その有効な値については、IEPD プロセスの次のステップで作成するマッピング・スプレッドシートに記録することにします。

汎化とロール

NIEM モデルは汎化を利用します。作成するモデルでも、汎化を適用できる場合には汎化を使用してください。この事例研究の場合、MotorVehicleBicycle はどちらも盗まれる可能性のある具体的なプロパティーです。したがって、この 2 つが含まれる包括的な Property クラスを追加し、そこから MotorVehicleBicycle を派生させることにします。こうすることによって、SerialNumber などの共通プロパティーは一度定義するだけで済みます。さらに、Theft クラスには Property クラスを関連付ければよいことになるため、関連が単純になります。

Victim (被害者) と Witness (目撃者) にも、これと同じルールを適用できそうです。結局のところ、この 2 つは単に特定の状況に置かれた人を表しているにすぎません。その一方、その個人が目撃者であるか、被害者であるかという状態は一時的なものなので、この状態は個人のロールとして表したほうが適切です。実際この例では、特定の窃盗事件で、一人の個人が被害者と目撃者の両方になり得ます。その場合、2 つのロールを持つ一人の個人だけを表したいと思うはずです。私はこのような複数のロールを持つ個人を表すために、Person という別個のクラスをモデルに追加し、Victim クラスおよび Witness クラスとの関連を作成しました。関連には Role Of Person というラベルを付け、これが通常の関連ではなく、ロールによる関連付けであることを示しています。

図 2 は、汎化とロールを追加した後のモデルです (図 2 をテキストで表現したものを見る)。

図 2. 汎化およびロールを追加した UML モデル
汎化 (Property、Person) およびロール (Victim、Witness、MotorVehicle、Biycle) を追加した UML モデル
汎化 (Property、Person) およびロール (Victim、Witness、MotorVehicle、Biycle) を追加した UML モデルのテキスト・バージョン (図 2)

リスティングを見るにはここをクリック

汎化 (Property、Person) およびロール (Victim、Witness、MotorVehicle、Biycle) を追加した UML モデルのテキスト・バージョン (図 2)

_____________________
|    TheftLocation   |  ___________________________ 
|____________________|  |          Theft           |
| Address : string   |  |__________________________|                       _________________________
| City : string      |  | TheftDateTime : dateTime |                       |       Property         |
| State : string     |  |__________________________|                       |________________________|
| ZipCode : string   |                                                     | SerialNumber : integer |
| CountyCode : code  |                                                     | Description : string   |
|____________________|                                                     | Color : string         |
                        ____________   ___________________                 |________________________|
                       |   Victim   |  |    Witness       |                        ^           ^
                       |____________|  |__________________|                        |           |
                       |            |  | Account : string |                        |           |
                       |____________|  |__________________|                        |           |
                           |                  |                  _________________________   _________________________
                           | 1                | 1                |     MotorVehicle       |  |        Bicycle         |
                           |                  |                  |________________________|  |________________________|
                           | RoleofPerson     | RoleofPerson     | LicensePlate : string  |  | IsRegistered : boolean |
                           |                  |                  | VehicleCategory : code |  |________________________|
                           | 1                | 1                |________________________|
                           |                  |             
                        _________________________ 
                        |         Person         |
                        |________________________|
                        | FirstName : string     |
                        | LastName : string      |
                        | DriverLicense : string |
                        |________________________|

関係

UML では関係を表す方法として、集約、コンポジション、関連の 3 つを使用します。

集約とコンポジションの関係は一般に、あるクラスが別のクラスの下位に属する “has a” 関係を表します。この例の場合、PersonPersonName との間には “has a” 関係があります。PersonName クラスは、個人が関連付けられていなければ意味がありません。集約とコンポジションは、NIEM では同じように扱われます。最終的な XML 構造では、従属クラスは他のクラスのなかに入れられます。例えば、PersonName 要素は Person 要素のなかに入れられることになります。

一方、関連はそれぞれに独立した 2 つのクラスの関係を表します。この事例研究の場合で言うと、TheftTheftLocation はそれぞれに別個のクラスであり、一方のクラスがなくても、他方の存在には影響しません。これらの関係をモデルで表すには、UML の一般的な関連を使用することができます。または関連自体に追加プロパティーが関連付けられている場合には、別個の関連クラスをモデルに追加することができます。いずれにしても、NIEM XML 構造では各クラスが個別の要素として表され、それぞれのクラスが持つ独自の関連要素に、そのクラスに関連付けられた要素への参照が含まれることになります (この事例研究の場合は TheftTheftLocation)。

この事例研究では、コンポジションを使用して PersonPersonName の関係を表し、その他のクラスの相互関係については、UML の単純な関連を使用します。図 3 に、これらの関係を追加したモデルを示します (図 3 をテキストで表現したものを見る)。

図 3. 関係を追加した UML モデル
関係 (集約、コンポジション、関連) を追加した UML モデル
関係 (集約、コンポジション、関連) を追加した UML モデルのテキスト・バージョン (図 3)

リスティングを見るにはここをクリック

関係 (集約、コンポジション、関連) を追加した UML モデルのテキスト・バージョン (図 3)

_____________________
|    TheftLocation   |         ___________________________ 
|____________________|         |          Theft           | 1             1  _________________________
| Address : string   | 1   1 * |__________________________|__________________|       Property         |
| City : string      |_________| TheftDateTime : dateTime |                  |________________________|
| State : string     |         |__________________________|                  | SerialNumber : integer |
| ZipCode : string   |         |                     |                       | Description : string   |
| CountyCode : code  |         | 1                 1 |                       | Color : string         |
|____________________|         |                     |                       |________________________|
                               |                     |                             ^           ^
                               | 1             0..*  |                             |           |
                        ____________   ___________________                         |           |
                       |   Victim   |  |    Witness       |                        |           |
                       |____________|  |__________________|      _________________________   _________________________
                       |            |  | Account : string |      |     MotorVehicle       |  |        Bicycle         |
                       |____________|  |__________________|      |________________________|  |________________________|
                           |                  |                  | LicensePlate : string  |  | IsRegistered : boolean |
                           | 1                | 1                | VehicleCategory : code |  |________________________|
                           |                  |                  |________________________|
                           | RoleofPerson     | RoleofPerson     
                           |                  |                  
                           | 1                | 1                
                           |                  |             
                        _________________________ 
                        |         Person         |                    _____________________ 
                        |________________________|   1  PersonName  1 |    PersonName      |
                        | DriverLicense : string |<>__________________|____________________|
                        |                        |                    | FirstName : string |
                        |________________________|                    | LastName : string  |
                                                                      |____________________|

ルートを選ぶ

すべての XML メッセージにはルートが 1 つ存在していなければなりません。通常、XML 情報交換ごとに 1 つの焦点、またはメッセージの目的があります。この事例研究でこれに該当するのは、盗難報告書そのものです。そこでこのモデルには、TheftReport に対応するクラスを TheftReportDate プロパティーと併せて追加します。TheftReportTheft の間には、盗難報告書が一連の盗難事件で構成されることを示すために集約の関係を作成します。

図 4 に完成した UML モデルを示します。このモデルはまだ完璧ではありませんが、この時点では完璧である必要はありません。通常は、IEPD 開発プロセス全体を通して、モデルに繰り返し変更を加えていくことになります。例えば、NIEM モデルに適合するように必要に応じて構造や名前を変更すると便利な場合もあります (図 4 をテキストで表現したものを見る)。

図 4. 完成した UML モデル
完成した UML モデル (TheftReport クラスを追加)
完成した UML モデル (TheftReport クラスを追加) のテキスト・バージョン (図 4)

リスティングを見るにはここをクリック

完成した UML モデル (TheftReport クラスを追加) のテキスト・バージョン (図 4)

                          _________________________ 
                          |      TheftReport       |
                          |________________________|
                          | TheftReportDate : date |
                          |________________________|
                                    ^
                                    V 1
                                    |
                                    |
                                    |
_____________________               | 1..*
|    TheftLocation   |         ___________________________ 
|____________________|         |          Theft           | 1             1  _________________________
| Address : string   | 1   1 * |__________________________|__________________|       Property         |
| City : string      |_________| TheftDateTime : dateTime |                  |________________________|
| State : string     |         |__________________________|                  | SerialNumber : integer |
| ZipCode : string   |         |                     |                       | Description : string   |
| CountyCode : code  |         | 1                 1 |                       | Color : string         |
|____________________|         |                     |                       |________________________|
                               |                     |                             ^           ^
                               | 1              0..* |                             |           |
                        ____________   ___________________                         |           |
                       |   Victim   |  |    Witness       |                        |           |
                       |____________|  |__________________|      _________________________   _________________________
                       |            |  | Account : string |      |     MotorVehicle       |  |        Bicycle         |
                       |____________|  |__________________|      |________________________|  |________________________|
                           |                  |                  | LicensePlate : string  |  | IsRegistered : boolean |
                           | 1                | 1                | VehicleCategory : code |  |________________________|
                           |                  |                  |________________________|
                           | RoleofPerson     | RoleofPerson     
                           |                  |                  
                           | 1                | 1                
                           |                  |             
                        _________________________ 
                        |         Person         |                    _____________________ 
                        |________________________|   1  PersonName  1 |    PersonName      |
                        | DriverLicense : string |<>------------------|____________________|
                        |                        |                    | FirstName : string |
                        |________________________|                    | LastName : string  |
                                                                      |____________________|

今回のまとめと次のステップ

この記事では、NIEM IEPD を作成するために必要な手順の概要を説明し、その最初のステップであるモデルの作成について詳しく検討しました。今回の作業によって完成したのは UML モデルのたたき台です。今後、このモデルを使用して IEPD の開発を続けます。今回のように、モデルを作成する過程でロールや XML Schema データ型などの NIEM を対象とした概念を使用することで、IEPD 開発プロセスの残りの作業が容易になります。

連載の次回の記事では 2 番目と 3 番目のステップとして、マッピングおよびサブセットの作成について説明します。UML モデルを NIEM にマッピングするコンポーネント・マッピング・テンプレートの作成方法、そしてマッピングに合わせて NIEM モデルのサブセットを生成する方法を学んでください。


ダウンロード

内容ファイル名サイズ
Final ArgoUML model from this articleniem1.zip12KB
Final XMI model from this articleniem1.xmi.zip4KB

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

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=480441
ArticleTitle=NIEM IEPD を作成する: 第 1 回 NIEM 情報交換モデルの作成
publish-date=05172010