成果報告書財団法人日本規格協会

平成１３年度
経済産業省委託
文字・画像・データ構造等の標準化に関する調査研究
（業務オブジェクトフレームワーク標準化調査研究委員会）
成果報告書
平成１４年３月
財団法人
日本規格協会
情報技術標準化研究センター
□この調査研究は、平成 1３年度に当協会が経済産業省から委託を受けて実施し
た「業務オブジェクトフレームワーク標準化調査研究委員会」の成果をとりま
とめたものです。
□この報告書に添付している JIS 原案は、JIS 制定の審議の過程において変更が
あり得ます。
また、ISO での今後の国際的審議の結果、変更されることがあります。
目次
1. はじめに
-----------------------------------------------------------------------------
1
2. 本年度活動の概要 ----------------------------------------------------------------2.1 活動概要 --------------------------------------------------------------------------
3
3
2.2 委員会開催状況 ----------------------------------------------------------------2.3 委員会名簿 -----------------------------------------------------------------------
4
5
3. 本年度の成果 ----------------------------------------------------------------------3.1 本年度成果概要 -------------------------------------------------------------3.2 ISO/IEC 11179-1､-2 の JIS 化 -------------------------------------------
6
6
8
3.3
3.4
IS 6523 JIS 化検討結果 ---------------------------------------------------SC32NWI の採択経過 ------------------------------------------------------
9
12
4. モデル共有技術の標準化動向解説 ------------------------------------------4.1 モデル化手法の標準化動向の解説------------------------------------------4.2 OMG における標準化動向の解説-------------------------------------------4.3 MOF/XMI の解説---------------------------------------------------------------4.4 EDOC の解説--------------------------------------------------------------------4.5 データ要素の命名法の考察----------------------------------------------------
15
16
22
29
38
50
5. 今後の課題
60
---------------------------------------------------------------------------
附属資料
附属資料 1：JIS 原案（ISO／IEC 11179-1，-2 対応）
JIS X xxxx-1 データ要素の仕様第 1 部：データ要素の仕様に関する枠組み
JIS X xxxx-2 データ要素の仕様
附属資料 2：NWI プロポーザル
第 2 部：データ要素分類
i
1．はじめに
平成 13 年度は、本委員会が関連する標準化活動に具体的成果がでた画期的な年であった。
その一つは、ISI/IEC SC32 に対して日本から提案した NWI (New Work Item： Framework for
Registering Business Object)が正式に採択されたことである。もう一つは、OMG に CBOP
から提案していたオブジェクトパターン（BFOP）が UML Profile for EDOC に正式採用さ
れたことである。いずれも 2 年以上の説得と調整の期間を費やしたものである。
SC32 に対する NWI（Framework for Registering Business Object）は、インターネット
による企業間連携を効率的に実現する上で、情報要素や業務モデルの共有を可能とする基
盤となるものである。各方面で議論されているモデルやデータの標準を登録するメタモデ
ルの体系化を図りながら、乱立する標準群を一定の枠組みで捉えてその相互利用促進を図
るものである。各標準化グループが異口同音のように提案するレジストリやディクショナ
リの相互運用が課題となっているからである。因みに、企業ビジネスプロセスの連携、あ
るいは装置プロセスの連携を目的にレジストリ（ディクショナリ）構築を議論している標
準化グループには、ISO/TC154（EDIFACT、BSR）、ISO/TC184（PDES/STEP）、ISO/TC127（土
木工学）、ISO/TC68(銀行業務)、また、ISO 外部でも、EBWG（ebXML の後継）や OMG、EAN、
UCC/GCI などがある。いずれもレジストリと情報要素の登録を議論している。
SC32 における NWI 提案については、米国、英国、カナダ、中国、韓国、日本、が作業参
画を表明しており、特に、米国は SC32 の次世代の課題として歓迎している。すでに、中国
は武漢大学のメンバが具体的な提案提出の準備を進めている。
一方、CBOP（ビジネスオブジェクト推進協議会）を窓口として進めてきた UML Profile
EDOC に対する提案は、UML に予め用意しておくべき抽象的なオブジェクト（Stereotype）
にオブジェクトパターンを盛り込むことを主張したもので、OMG の中にオブジェクトパター
ンの重要性を認識させるものとなった。目下、UML の改定と MOF の改定が並行して進められ
ているが、SC32 の NWI との整合性確保、つまり SC32・NWI の作業の一部(MOF 改定)を、OMG
のタスクフォースで分担することも決定されている（2002 年 2 月 OMG アナハイム TC プレナ
リ会議）。
本委員会の目的は、特に「情報要素や業務モデル」に関する標準化について、①情報収
集と動向分析を行うこと、②国際提案などの準備活動を展開すること、③SC32 活動の国内
展開を図ることにある。
本委員会のメンバは、ISO/SC32WG1、同 WG1、TC184、UN/CEFACT、ECOM、CBOP などの活動
に深く関与しているメンバである。ISO 活動だけでなく、OMG、UN/CEFACT、EAN/UCC などの
コンソーシアムの活動においても情報収集以上の活動を展開している。
1
因みに、ISO/SC32 への NWI 提案と OMG への UML Profile for EDOC 提案は、実質的に本委
員会のメンバが中心となっている（管理工学研究所、テクノロジックアーツ、富士通、日
立、ECOM、東京国際大学など）。また、同じメンバが UN/CEFACT の TMWG や EBWG に参画して
積極的な活動を展開し、モデリング技術における日本技術者の能力をアピールしている。
本年度の成果は、ISO 活動に対応する規格調査会の国内委員会、あるいは個々のコンソー
シアムのそれぞれには期待できないハブとしての役割の成果ともいえる。 OMG の ISO 協力
の取り付け、SC32 メンバの UN/CEFACT での活躍などは、本委員会による情報交換がなけれ
ば実現し得なかったものといえる。
SC32 活動の国内展開については、IS11179 規格の JIS 化も行った。本年度は、その第 1
部と、第 2 部の JIS 原案を作成した。（規格本体の第 3 部は、目下、改定作業中でありその
規格化を待って JIS 化を進める）。
さらに、情報要素関係の規格について、本年度、IS6523（企業コード）の JIS 化検討も
行った。企業コードに限らず、国際規格（IS）にあって JIS にないものが多数存在してい
るようである（性別コードなど）。今後、その実体を明らかにし JIS 化の必要なものについ
て提案していきたい。
この他、本委員会に関連する活動として、経済産業省からの情報要素関係の標準化の状
況に関する質問に対して回答すべく、わが国の状況把握と、国際への提案可能性について
議論するため、SC32 だけでなく、SC7、SC36、TC154、ECOM、OMG、XBRL、などのメンバによ
る非公式な懇談会「情報要素関係標準化懇談会」
を INSTAC で開催した（13 年 10 月―12 月）。
同懇談会は、今後も継続するものとなった。
同懇談会で議論された課題の一つは、日本の標準化の進め方に関するものであり、国際
性の欠如や、デジューレ標準化活動とデファクト活動の連携などである。また、
「日本」を
明示的に強調しすぎることはないまでも、国際標準化にける日本の地位の確保を、特に、
アジアをベースに展開する重要性であった。
本委員会は本年度で終了するが、メンバ構成の利点を生かした他の委員会により、ハブと
しての役割を展開すると共に、本格化する SC32 における NWI 作業の推進と、IS11179 規格
とその関連規格の JIS 化を推進されることを望む。
平成 14 年 3 月
委員長
2
堀内
一
2．本年度活動の概要
2.1 活動概要
【SC32NWI 提案】
本年度、本委員会は、SC32 に対する NWI 提案の採択に向けて SC32 のニューヨーク会議、及
びビクトリア（カナダ）会議でのプレゼン及びチュートリアル準備の支援を行った。また、
OMG の UML profile EDOC の提案や調整会議についても、その方向付けや資料準備について
支援をおこなった。
SC32 への NWI 提案は、ビクトリア会議のプレナリで承認され（H13
年 10 月）、JTC1 の投票により承認された（H14 年 2 月）。
【IS11179 の JIS 化】
SC32 が担当する規格 IS11179 について、その第 1 部と第 2 部の JIS 原案を作成した。第
3 部については、本年度中の着手が難しくなったこともあって、次年度へ繰越となった。
【IS6523JIS 化検討】
IS6523（企業コード）の JIS 化の必要性について検討した。
【OMG 及び UN/CEFACT への提案の支援と動向調査】
本年度、本委員会のメンバは、ISO 以外の次のような国際会議へ出席した。本委員会は、
そこで活動の方向付け議論や資料準備について支援を行った。
（１）UN/CEFACT の TMWG 会議、EBWG 会議
ダラス TMWG 会議（H13 年 3 月）、香港会議（H13 年 11 月）、シアトル会議（H14 年 1 月）。
特に、TMWG で議論されている UMM（UN/CEFACT Modeling Methodology）や BPM（Business
Process
Modeling）においてオブジェクトパターン技術での貢献を行っている。
（２）OMG TC 会議
アーバイン会議（H13 年 3 月）、ダブリン会議（H13 年 11 月）、アナハイム会議（H14 年
2 月）
UML profile for EDOC の RFP への応募は CBOP 名で行っているが、IBM、Unisys,
DataAccess, SunMicro、Fujitsu らと一緒に提案の一本化のための調整を行ってきた。
その推進者は本委員会のメンバである。
3
2.2 委員会開催状況
日
時
主
な
実
施
内
容
・今年度活動計画確認
第
第
第
第
１回
２回
３回
４回
５月１０日
６月１４日
・ebXML ウイーン会議報告
・11179-1,-2JIS 化方針、6523JIS 化方針、NWI 方針
７月５日
・11179JIS 化検討（分担等）
・NWI ベースドキュメント検討
８月２日
・11179 用語訳検討、NWI ベースドキュメント検討
・TMWG ダブリン会議報告
・11179-3FCD 精査（ad hoc）
第
第
第
第
第
５回
６回
７回
８回
９回
８月１０日
９月６日
・11179JIS 原案検討、6523JIS 化検討
・NWI 日本提案審議
１０月１１日
・来年度委員会活動検討
・11179-5 の命名規則検討
１１月１５日
・SC32 カナダ会議報告
・6523JIS 化検討
１２月１３日
・11179JIS 原案検討
・UDDI 研究会
・NWI の登録メカニズム原案作成検討（ad hoc）
第１０回
第１１回
第１２回
１月７日
１月１０日
・11179JIS 原案最終案検討
・報告書骨子検討
２月１４日
・11179 に関する用語委員会結果報告と JIS 案への反映
・OMG TC 会議報告、ソウル会議対処方針
・報告書まとめ
第１３回
３月１４日
4
2.3
委員名簿
（平成１４年３月現在）
委員長
堀内
一
東京国際大学商学部経営情報学科
幹事
大林
正晴
株式会社管理工学研究所
委員
石田
厚子
株式会社日立製作所ﾋﾞｼﾞﾈｽｿﾘｭｰｼｮﾝ開発本部企画部
太田
可允
駿河台大学
木戸
達雄
経済産業省産業技術環境局標準課情報電気標準化推進室
木下
貴史
株式会社野村総合研究所情報・通信ｺﾝｻﾙﾃｨﾝｸﾞ二部
児玉
公信
株式会社ｴﾇ･ｹｰ･ｴｸｻ技術部
小林
佳文
株式会社ｲﾝﾃﾘｼﾞｪﾝﾄ・ﾓﾃﾞﾙ
齋藤
静一
佐藤
誠
財団法人流通ｼｽﾃﾑ開発ｾﾝﾀｰ流通ｺｰﾄﾞｾﾝﾀｰ
高崎商科大学
白鳥
孝明
日本ｱｲ･ﾋﾞｰ･ｴﾑ株式会社ｿﾌﾄｳｪｱ開発研究所
菅又
久直
電子商取引推進機構
鈴木
健司
東京国際大学人間社会学部
関口
裕
長瀬
嘉秀
ＯＢＳ
社団法人電子情報技術産業協会標準･技術部
株式会社ﾃｸﾉﾛｼﾞｯｸｱｰﾄ
羽生田栄一
株式会社豆蔵
藤川
泰之
富士通株式会社ﾌﾟﾛｼﾞｪｸﾄA-XML
松本
聡
JNTｼｽﾃﾑ株式会社ｼｽﾃﾑｲﾝﾃｸﾞﾚｰｼｮﾝ部
森田
勝弘
ｱｸｾﾝﾁｭｱ株式会社
森
宗正
規格調整委員
山田
喜彦
株式会社ｼｰｴｰｼｰ技術研究室
原
潔
日本ﾕﾆｼｽ株式会社Ｅﾋﾞｼﾞﾈｽ技術部
三木
良治
中小企業総合事業団商品コード情報ｾﾝﾀｰ
経済省
深沢
太郎
経済産業省産業技術環境局標準課情報電気標準化推進室
事務局
山中
正幸
財団法人日本規格協会情報技術標準化研究ｾﾝﾀ-
5
3. 本年度の成果
3.1 本年度成果概要
本委員会は、平成 13 年度、次のような事項について SC32WG2 国内委員会、SC32WG1 国内
委員会、ECOM、CBOP などと連携・協調し、次のような成果を得た。
（１） SC32 NWI 提案の採択
SC32WG2 国内委員会では、平成 12 年１月に SC32
サンタフェ会議で提出した NWI
（Framework for Identification & Classification）について、13 年 10 月のカナダ・ビ
クトリア会議のプレナリで採択され、JTC1 投票で参画 6 カ国を得て承認された（プロジェ
クト参画国：米国、英国、カナダ、中国、韓国、日本）。
次回のソウル会議（14 年 5 月）で正式にプロジェクト発足となる。日本はプロジェクト
エディタとなる。既に、中国は提案を準備中とのこと、韓国もその意向である。日・中・
韓の連携が期待できる。
（２） 11179 規格の JIS 原案作成
本委員会では、11179 規格の JIS 化を目指している。本体の 11179-3（第 3 部）の改定
が SC32 で継続中であることから、本年度は、第 1 部と第 2 部の JIS 原案の作成を行った。
原案については、附属資料-１を参照頂きたい。
（３） IS6523 規格 JIS 化の検討
企業識別コード（IS6523）について、その JIS 化の必要性を検討した。既に国内でも広
く利用されていながら、JIS が存在しないことは不自然であるが、その登録サービスを行
う機関の所在が決まれば、JIS 化を進めるべきである、という結論を得た。
（４） UML Profile for EDOC
CBOP を窓口に進めてきた、OMG の RFP( UML Profile for EDOC)へ、BFOP（Business Function
Object Pattern）提案が 13 年 11 月に正式採択された。その提案には本委員会のメンバの
多くが関与してきた。
（５） UN./CEFACT
TMWG へのフードバック
UN/CEFACT の TMWG（Technique & Methodologies Working Group）は、UML をベースとし
た企業間協調のモデル開発方法論を検討中である。本年度、本委員会からは、SC32 の NWI
との協調、及び UML Profile for EDOC に提案したオブジェクトパターンの適用に関する
貢献を行い、TMWG N090R9 ドキュメントに反映された。
6
本委員会の相関
本委員会は、その目的達成のために積極的に内外の関連団体、標準化グループと連携し
ている。
図 3.1-1 はそれらの関係を図示したものである。
OMG
ISO/IEC JTC1 SC32
UN/CEFACT
TMWG
ebXML
GCI
TC154 （BSR）
11179支援
11179国内標準化
NWI提案
MOF/XMI PAS推進
BSRへのコメント
UML Profile
for EODC提
案
本委員会
パターン技術支援
CBOP
パターン技術支援
ECOM
コンポーネント取
引モデルで協調
EJBコンソーシアム
（財）流通システム開発センタ
商取引モデル委員会
図 3.1-1 委員会関係図
7
8
3.2 ISO/IEC 11179-1､-2 の JIS 化
3.2.1 経緯
ISO/IEC JTC1 配下の SC32/WG2 で標準化活動が行われている ISO/IEC 11179 の規格群は、
メタデータを含めてデータ要素の構成の基本的な側面を規定し、次の６部構成からなる。
− 第１部：枠組み（Framework for the specification and standardization of data elements）
− 第２部：データ要素の分類（Classification for data elements）
− 第３部：データ要素の基本属性（Basic attributes of data elements）
− 第４部：データ定義記述のための規則及び指針
（Rules and guidelines for the formulation of data elements）
− 第５部：データ要素の名前付け及び識別の原則
（Naming and identification principles for data elements）
− 第６部：データ要素の登録（Registration of data elements）
これらの ISO/IEC 11179 の規格群は、電子データ交換による情報またはデータの交換を円滑す
るためにメタデータを含めてデータ要素の仕様を規定するものであり、本委員会のテーマである
業務オブジェクトフレームワーク標準化におけるメタデータ標準化と密接な関係がある。そこで、
1999 年、2000 年に IS 第１版としてそれぞれ出版された第１部、第２部を JIS 化することにし、
本委員会のもとに JIS 原案検討作業部会を設置し JIS 原案の作成を行った。
JIS 原案の作成のあたっては、早期の JIS 化をはかるために要約 JIS とすることにし、規格の
内容で、日本語化しておいた方が有益な規格の部分（用語・規定内容）については翻訳し、解説
で記述した。
3.2.2
用語委員会での審議状況
作成した JIS 原案を用語委員会で審議した結果、特に調整となった用語は次の通りである。
（１）構成要素（component）
component を“構成要素”とすることは、data element を“データ要素”とすることと混乱
しないかという不安が指摘されたが、その不安はないということで原案通り了承された。
（２）登録簿内容（registry）
registry を“登録簿内容”とするのは誤解されやすいという指摘があった。この用語は原案作
成部会でも議論があったところであるが、別の用語 register では“器、入れ物”を指してい
ることから“登録簿”とし、ここでの registry は“登録簿の内容”を指していることから“登
録簿内容”とすることで原案通り了承された。
（３）データ管理者（data steward）を“データ幹事”に修正
“データ管理者”というと database manager のようなものと誤解されやすく、“データ資
源管理者”ではどうかという指摘があった。データベース分野の“data administrator”又は
“database administrator”が一般的で、“data steward”というのは馴染みのない用語であ
り、原案作成部会では、data administrator と同じと解釈し、“データ管理者”とした。しか
し、審議結果“data administrator”という用語を使用しないで、“data steward”としてい
ることから、用語を変えたほうがよいという意見に従い、提案された“データ幹事”に修正
することにした。
8
3.3
IS 6523 JIS 化検討結果
3.3.1
概要
この規格は、EDI では必須となる「企業識別コード」の標準化に関する規格であり、「組織及
び組織内部門識別の構造(Structure for the identification of organizations and
organization parts) 」というタイトルが付けられている。企業識別コードの定義とコード体
系、そしてコード化国際間識別（ICD）と称する３桁の数字の登録に関して規定している。
国際的には現在、複数の「民間管理による企業識別コード」が使用されており、異なる民間管
理の企業コード間には互換性がない。わが国では、共通取引先コード（(財)流通システム開発セ
ンター）、標準企業コード（(財)日本情報処理開発協会）、日本輸出入者コード（(財)日本貿易
関係手続簡易化協会）及び全国金融機関番号（全国銀行協会連合会）など多種類の「企業コー
ド」が使用されているが、共通運用できるのは共通取引先コードと標準企業コードのみで、他は
互換性がない。
これら互換性のない既存の企業コードの先頭に、３桁の数字（これが ICD である）を付加する
ことで、国際的に互換性のある企業コードを、既存の企業コードを用いて実現しようとする規格
である。すでに、国際的に有力な企業コードであるダンズナンバー（米国ダンズ社管理）、ＥＡ
Ｎロケーション番号（(財)流通システム開発センターのＧＬＮと同一のもの）、標準企業コード
など、多数の企業コードが登録され、ICD 値が与えられている。
ＩＳ６５２３には第１部と第２部があり、第１部では企業識別コードの定義とコード体系が規
定され、第２部ではＩＣＤの登録管理について規定されている。
3.3.2
コード体系
企業識別は、図−１に示すコード体系（構造）で行うとしている。
「ICD」＋「組織識別コード」＋「組織内部門識別コード」＋「OPIS」
図−１
企業識別の構造
上記の内、「組織識別コード」＋「組織内部門識別コード」＋「OPIS」の部分を「組織識別体
系」と呼び、既存の企業コードに対応させる。「OPIS」は特殊な補助コードで、通常省略可能で
ある。「ICD」は組織識別体系に対して、ユニークに３桁の数字を割振る。
「組織識別コード」と「組織内部門識別コード」はともに最大３５桁の可変長文字列で、２バ
イト文字の使用も可能である。「OPIS」は１桁固定の文字列である。
さらに、「ICD」を始めとする４っつの要素は、図−１の順番でなくてもよく、例えば、「組
織内部門識別コード」＋「組織識別コード」の順でもよい。また、４つの要素を別々のデータ項
目にすることもでき、例えば、「ICD」だけを別のデータ項目にすることもできる。こうするこ
とで、既存の企業コードを広くカバーすることができる。
3.3.3
「ICD」の登録管理
9
「ICD」は、既存の企業コードにユニークに３桁の数字を割振るために、登録制である。この
登録管理は、以下のようにして行う。
（１）登録機関（RA）
登録要求（申請という）のあった企業コード（組織識別体系という）の「ICD」の値を決定
し、割当てる機関で１カ所に限定されている。イギリス規格協会が担うと規定されている。
（２）支援機関（SA）
「ICD」が必要な企業コードの管理者が直接 RA に申請することは許されず、必ず SA を通じ
て申請しなければならないことになっている。さらに、RA がたまたま企業コードの管理者の場
合は、自身の管理する企業コードの「ICD」取得申請は、別の RA を通さなければならない。Ｒ
Ａは複数存在するが、以下の機関に限定されている。
・
ISO の技術委員会か専門委員会
・
ISO のナショナル・メンバー・ボデイ（わが国では JISC）
・
ISO とリエゾン関係にある国際機関（例えば、国連 CEFACT）
（３）発行機関（IO：一般の企業コード管理機関）
IO は、既存の企業コードの管理機関である。IO は、直接ＲＡに「ICD」の割当て要求を申請
することはできず、SA に申請の代行をたのまなければならない。
SA は、申請代行をたのまれた IO（企業コード管理機関）の審査を行い、「ICD」の割当てが
妥当である場合のみ、RA に対して割当て要求を行う。
3.3.4
今後の課題
（１）企業コードの重要性
企業コードは、EDI のメッセージ内でプレイヤー（発注者や受注者）を特定するのに用いる、
もっとも重要なコードである。企業コードの利用はこれに留まらない。ときには、納品先など
の場所の特定に使うこともある。
さらに、一般的に単品識別製品コードに用いる。通常製品メーカーは、自社製品の製品コー
ド（商品コード）を独自に決める。従って、異なる製品メーカー間では、製品コードがユニー
クになっていない。そこで、製品メーカーの企業コードと組み合わせることで、製品コードを
ユニークにする。実際に、わが国の電子業界で使われているほか、JAN コードも同じ原理の商
品コードである。
EDI の広範な普及のために、企業コードの共通化は極めて重要であり、わが国でも民間レベ
ルで、標準化とその普及による企業コードの共通化が積極的に推進されている。
（２）IS6523 の JIS 化の必要性
前述したように、わが国では民間レベルで企業コードの共通化が積極的に推進されているが、
複数のグループが推進しており、そのグループ間では互換性がない。さらに、国際的にも複数
のグループが推進しており、全体として共通化というレベルに達していない。
ＩＳ６５２３は、現段階で考えうるこの問題の解決策としては、最良の手法と思われる。実
際に、冒頭で述べた標準企業コード、ダンズナンバー、EAN ロケーション番号などの国際的に
10
有力な企業コードが、このルールに基づく登録を実施している。今後の EDI のグローバル化の
ために、企業コードの国際的共通化は必要不可欠であり、当分の間 IS6523 に基づく共通化が
実行されるだろう。
この限りでは、IS6523 の JIS 化の動機としては希薄である。しかし、国際強調を国是として
いるわが国が IS6523 の JIS 化していないのは実害がない（わが国がオリジナルである標準企
業コードは、すでに登録されている）とは言え、あまりにも格好が悪いと言うべきである。
実際には実害がないわけではない。JIS 化していないのが主たる理由になって、わが国には
IS6523 でいう SA がない。そのため、標準企業コードの登録は、ＳＡである国連 CEFACT に申請
をお願いした経緯がある。
世界有数の情報化大国に、SA がないというのは、如何なものであろうか。欧米の主要な情報
化先進国は、IS6523 を認知するとともに SA を設立している。この先、例えば全国金融機関番
号を登録する必要性が出てきたとき、また、国連 CEFACT に申請をお願いするのであろうか。
様々な状況を総合すれば、IS6523 の JIS 化は必要不可欠である。
（３）JIS 化に際しての考慮点
IS6523 を JIS 化すれば、当然のこととして、ＳＡを設立しなければならない。逆に、ＳＡの
設立がＪＩＳ化の大きな目的になる。IS6523 の規定から考えると、ｊｉｓｃ（日本工業標準調
査会）が、唯一のＳＡの候補である。そこで第一に、実際の運用も含めて、その可能性を検討
する必要がある。
11
3.4
SC32NWI の採択経過
3.4.1 ISO/IEC SC32 への NWI の経緯
SC32（Data Management & Interchange）は、旧 SC21、旧 SC30、及び旧 SC14 を統合して
平成 10 年に JTC1 の下に発足した。特に、SC32WG2（metadata）は米国を中心とした旧 SC14
のメンバが中心となりデータ要素のメタデータの標準化を進めてきた。電子商取引を主体
とする企業間ビジネス連携は、単に、構造を持たないデータ要素だけの標準化では不十分
であることから、構造をもつ情報要素として、モデルやソフトウェアを含むオブジェクト
標準化の発展性を必要としていた。
国内では、平成 9 年に発足したビジネスオブジェクト推進協議会や OMG がビジネスオブ
ジェクトの共有を目標に標準化作業を始めていた。そこで、本委員会の前身となる「情報
資源スキーマ委員会」と SC32WG2 国内委員会は、共同で「ビジネスオブジェクトの登録を
可能する標準化作業の提案を目的に準備を始めた。
平成 12 年 1 月、 SC32 サンタフェ会議に NWI （ Framework for Identification &
Classification）として提案を行った。その結果は「Study Period を置く」というもので、
1 年半の調査研究活動が承認された。
平成 12 年 4 月の NY での WG2 会議、同年 11 月のヘルシンキでの SC 会議、13 年 5 月の
NY での WG2 会議 NY 会議で、タイトルを、「Framework for Registering Business Object」
としスコープの限定を図ることにした。平成 13 年 10 月のビクトリア（カナダ）の SC 会議
で承認を得た。同時に JTC1 の投票に移り 14 年 3 月の投票結果により、6 カ国の参画を得て
承認された。
3.4.2
NWI 提案の背景
日本から提案した NWI は最終的に「Framework for Registering Business Object」とし
て承認された。その背景には、ネットワークを介した企業間連携における情報共有やソフ
トウェア連携を目的としたメタ情報標準化活動の乱立の動きがあり、それらの相互運用を
可能とする基盤の必要性が重視されてきたことにある。
表 3.4-1 は、特に、情報要素やモデルの共有に関する標準化活動を行っている ISO 内
外の組織とその組織が取り組んでいる課題を示すものである。
多くの標準化グループが、メタモデル（レジストリ）の標準化を対象としていることが
分かる。
12
表 3.4-1
情報要素関係標準化活動とその対象
Organization ISO ISO ISO ISO AR Eb
SC32 TC TC TC TS XML
Rosett CPFR SCOR UN/ EAN OMG
aNet
GCI
XBRL
CEF
68 154 184
ACT
TMW
Topics
G
Business
X
X
codes
X
X
Information
X
X
Identification
X
X
X
X
X
X
X
X
X
Elements
Interchange
X
X
X
X
X
X
X
X
X
X
X
format
Domain Models
X
Business
X
X
X
X
X
Protocols
Best Practices
Metamodel
X
X
X
X
X
X
X
Methodology
X
X
X
X
X
X
Information View
3.4.3
X
X
NWI のベースドキュメントの骨子
SC32WG2 における NWI に対する「Study Period」の期間中に WG2 内で議論された結果を
日本が中心となってまとめ提案のベースドキュメントとした。提案の骨子はメタモデルの
体系化とその標準化にある。次のようなメタモデルの標準化を行う。
（1）MOF をベースとしたメタモデル管理のためのメタモデル（メタメタモデル）
（2）異なるモデル間のマッピングを可能とするメタモデル
（3）モデルあるいは情報要素定義のための規範的モデル化要素のためのメタモデル
（4）モデルあるいは情報要素定義のための識別・分類体系のためのメタモデル
それらメタモデルの関係を図示したものが、図 3.4.1 である。またそれらのメタモデルに
よって実現されるレジストリ相互運用を示したものが、図 3.4.2 である。
なお、NWI のベースドキュメントを附属資料-2 に添付する。
13
Metamodel Framework
Standard Meta-meta model
Metamodel
for
Mapping Models
Common
Identification
&
Classification
Metamodel for
Registering
Objects
Common
Domain
Business Objects
図 3.4-1
Specific
Common
Model
Constructs
SC32 NWI の狙い
Software
Component
Registry
CommonContent
ISO 11179
Registries
Common Content
OASIS/ebXML
Registries
UDDI
Registries
Metamodel FW
Business Object
Registry
Common Content
Common Content
CASE Tool
Repositories
Common Content
Ontological
Registries
Database
Catalogs
Common Content
Common Content
図 3.4−2 メタモデルフレームワークによるレジストリ連携
14
4. モデル共有技術の標準化動向の解説
本委員会の目的の一つは、情報要素、モデル関係の標準化動向を調査することにある。
本年度は、次のものを解説する。
UN/CEFCAT TMWG によるモデル化方法論 UMM（UN/CEFACT
Modeling Methodology）
ISO SC32 に対する NWI 提案のベースとなっている MOF/XMI と、
OMG の活動として一つの成果を挙げた UML profile for EDOC
いずれも、業務オブジェクトモデルや情報要素の共有を進めるための基盤技術となるもの
である。図 4-1 は、モデル、ソフトウェアあるいはドキュメント（View）などのオブジェ
クトを共有するための基盤概念を示すものである。
UMM（UN/CEFACT
Modeling Methodology）は、電子商取引におけるビジネス協調のプ
ロセスモデルを UML をベースに作成するための方法論である。
MOF（Meta Object Facility）は、共有対象としてのモデル、ソフトウェアあるいはド
キュメント（View）の構造とその組成、またモデルを開発するために使用されるモデル化
機能（UML）が持つメタモデルなどを、統一的に記述したメタモデル（メタメタモデル）の
操作・蓄積機能を提供するものである。したがって、MOF はレジストリまたはリポジトリと
呼ばれるものとなる。
UML
Profile
は modeling Facility （モデル化機能）としての UML に対して、単なる
ダイアグラム記法としての機能だけでなく、モデル化要素（Modeling Constructs）の標準
形を用いてモデル開発ができる機能を具備させるものである。
MetaMetaModels
(MOF +CWM)
MetaModeling
(MOF)
Facilities
Identification & Classification
MetaModel
Interchange
Facilities
(XMI)
MetaModels (UML/MM + MOF )
Registration
Procedure
Software
Model
Views
Modeling Constructs
UMM
Modeling Facilities (UML)
Basic Defining Scheme (IS11179)
図 4-1 オブジェクトを共有するための基盤概念
15
4.1
モデル化手法（UMM）の標準化動向
モデリング技術は、システム設計手法として情報技術分野に取り入れられ、ビジネスア
プリケーションの開発、そして企業内アプリケーションの統合に寄与してきた。企業間で
ビジネスプロセスを共有し、WEB 上での電子ビジネスコラボレーションの実現が間じかに
なった現在、モデリング技術は異なる企業のアプリケーション同士のシームレスなプロセ
ス遂行のため、その標準化が待望されている。
UN/CEFACT (国連/貿易手続き・電子ビジネスセンター) モデリング手法 (UMM :
UN/CEFACT Modelling methodology)は、既存の EDI および ebXML も含む次世代の EDI
をサポートするために、企業間のビジネスプロセスをモデリングする手法である。基本的
には、Rational Corporation の開発した Unified Process の枠組みに基づき、企業間ビジ
ネスプロセスのモデリングに関する要求を満足するように構成されている。
UMM は、「ビジネストランザクションの記述に必要不可欠な、取引上の意思決定およ
び企業間の契約締結の側面に限定してビジネストランザクションを表現する」もので「情
報交換を伴うビジネスプロセスをプロトコルや実装に依存しない方法で指定 / モデリング
するための手順を提供する。これは、オープン edi における BOV（Business Operational
View:事業運用ビュー）の範疇であり、基本的に FSV（Functional Service View:機能サー
ビスビュー）の範疇は UMM の対象外である。
（１）UMM のワークフロー
具体的に、UMM が対象とするワークフローを以下に整理する。
i.
ビジネスモデリング (Business Modelling):
このワークフローでは、企業間プロジェ
クトに用いる組織的なコンテキストを提供する。具体的には UML パッケージとして
表現されたモデルアーキテクチャとして Business Domain View を定義する。同時
に、初期のユースケースを作成する。通常、ビジネスのユースケースは、取引アクテ
ィビティ図の第 1 レベルの図案として提供される。
ii.
要件定義 (Requirements): このワークフローでは、企業間プロジェクトに関する必要
条件を理解するための重要な情報として、取引モデルが使用するキーコンセプトのそ
れぞれに対して解説し、ユースケース図を作成する。通常、ここでアクティビティ図
の第 1 レベルに対してさらに検討が加えられ、新たなユースケースが発見される。こ
うしたユースケース、および結果として得られるアクティビティ図にはプロジェクト
スポンサーの意向や企業の要求が大きく反映される。さらに、ここでビジネスエンテ
ィティが定義され、これは後工程で分析されビジネスオブジェクトとして定義し直さ
れる。
iii.
分析(Analysis): このワークフローでは、要件定義されたユースケースに対して検討
が加えられる。すなわち、発生する可能性のある事がらを詳細に検討し、ユースケー
16
スをさらに具体化し、活動中に生成された高レベルのオブジェクトを識別する。また、
必要に応じてこれらのオブジェクトに対してクラス図を作成する。
iv.
設計 (Design):このワークフローでは、当初作成したクラス図に検討が加えられる。
すなわち、関与するエンティティクラスを識別し、オブジェクト同士がどのように連
携しているかについて調べ、各オブジェクトが遷移することのできる状態等について
検討を行う。さらに、本ワークフローでは、情報モデルを詳細に決定し、全てのクラ
スモデルに対してビジネスオブジェクトを適用し、サービスプロトコルのシンタック
スおよびセマンティクスの詳細を決定し、ビジネスサービスインタラクション
(Business Service Interaction) の各パターンを適用する。ビジネスオブジェクトライ
ブラリの内容は、今日多くの業界で用いられている既存のビジネスオブジェクトを辞
書 (Lexicon)の内容に照らし合わせて解析して、作成される。情報モデルと、同一の
業種および他業種で保管されているその他のモデルを統合するには、まずは両者の間
で調整を行う必要がある。
これらの各ワークフロー内には生み出される成果物が想定されている（図 4.1-1）。こう
した文書にはテンプレートが用意されていて、これらの成果物が作成しやすくなっている。
全てのプロセスは相互に影響しあっていて、追加や変更が発見され次第、その他のワーク
フロー内で確認され取り込まれる。
レキシコン(Lexicon)
コアコンポーネント
(Core Component)
コアプロセス
(Core Processes)
業務知識
ビジネスモデリング結果
パッケージ
アクティビティ図
ユースケース図
ユースケース記述
概念アクティビティ記述
アクティビティ図
ビジネスオブジェクト
(Business Objects)
ビジネスプロセス
(Business Processes)
分析結果
要求仕様結果
概念ユースケース図
概念ユースケース記述
ライブラ(Library)
設計結果
コラボレーション図
（オプショナル）
シーケンス図
（オプショナル）
シーケンス図
概念クラス図
最終クラス図
Business Process and Information Models
図 4.1-1
UN/CEFACT モデリング手法のﾜｰｸﾌﾛｰと成果物
17
図 4.1-1 にある通り、成果物である「ユースケース図」や「アクティビティ図」等はＵＭ
Ｌで定義された記法に準拠している。UMM は、オープン edi シナリオの仕様を形式的に記述
するために UML (Unified Modelling Language) を採用している。本図の考え方は、基本的
に ebXML 仕様でも踏襲されている。図中にある通り、UMM では、各モデリングのワーク
フローで、「辞書 (lexicon)」と呼ばれるところに格納されている共通に使えるデータおよ
びプロセスの定義を再利用する。ebXML 仕様では、「辞書 (lexicon)」を「コアライブラリ
（Core Library）」と読み替えているが、基本的発想は同じである。ここには、業界毎にま
とめられた関係やクロスリファレンスも蓄積され、特定の企業または業界で用いられる言
葉と UML モデルの間の橋渡しがなされる。
（２） UMM フレームワーク
UMM フレームワーク (Unified Modeling Methodology Framework) は、ワークフロー
の各フェーズに含まれるメソッドの使用法および相互関係、パターン、およびモデルの成
果物を定義している。各フェーズにおいて、適切に定義されたセマンティクスを持ったモ
デリング要素を使用し、パターンに対して、決められたメソドロジーが適用される。
（表 4.1-1）
18
表 4.1-1
ワークフロー
UMM フレームワーク
方法
Model Artifacts [UML]
パーターン
（Pattern）
ビジネスモデリ
•
ング
Business
•
Modelling
•
•
ビジネスﾊﾟﾀｰﾝ
事業ドメインビュー
Analysis）
（Business
(Business Domain View : BDV)
ユースケース分析（Use
Patterns ,TBD
•
Case Analysis）
））
ドメイン分析（Domain
パッケージ]
•
プロセスの発見
•
アクティビティモデリン
•
Business
Requirements
•
•
•
ビジネスコラ
ビジネス要件ビュー
Gathering）
ボレーション
(Business Requirement View, BRV)
ユースケース分析 (Use
(Business
•
Case Analysis)
Collaboration,
プロセス分析 (Process
TBD)
要求収集 (Requirements
ビジネスプロセス (Business Process(es))
[UML のユースケース図]
•
Analysis)
•
プロセス（Process(es)） [UML のユースケー
ス図とアクティビティ図]
グ（Activity Modeling）
要求定義
プロセスエリア（Process Area） [UML のパ
ッケージ]
（Process Discovery）
•
ビジネスエリア（Business Area） [UML の
ビジネスコラボレーションユースケース
（Business Collaboration Use Case）
•
アクティビティモデリン
グ（Activity Modeling）
ビジネスコラボレーション（ Business
Collaboration） [コラボレーションユースケ
ース]
分析
•
Analysis
•
•
•
ビジネストラ
ビジネストランザクションビュー
Analysis)
ンザクション
(Business Transction View, BTV)
アクティビティモデリン
モデリングﾊﾟﾀ
•
グ（Activity Modeling）
ｰﾝ (Business
(Business Collaboration Protocol) [UML のア
概念クラスモデリング
Transaction
クティビティ図]
(Conceptual
Modelling
プロセス分析 (Process
Class
•
Patterns)
Modeling)
ビジネスコラボレーションプロトコル
ビジネストランザクション (Business
Transactions) [UML のアクティビティ図]
•
概念的なビジネス文書(Business Documents
(conceptual)) [UML のクラズ図]
設計
•
プロセス分析 (Process
•
Analysis)
Design
•
コラボレーションモデリ
ン
グ
(Collaboration
Modelling)
•
•
メッセージシーケンス
(Message Sequencing)
情報モデリング
(Information
•
ビジネスサー
ビスインタラ
クションﾊﾟﾀｰﾝ
(Business
Service
Interaction
Patterns)
情報モデルﾊﾟﾀ
ｰ
ﾝ
(Information
Modelling
Patterns)
19
ビジネスサービスビュー
(Busienss Service View, BSV)
•
サービスコラボレーション(Service
Collaboration) [UML のオブジェクトコラボレ
ーション図]
•
ネットワークコンポーネント (Network
Component) [UML のクラス図]
•
Modelling)
メッセージモデリング
(Message
Modelling)
(実装プロトコル非依存)
•
ビジネスサービス(Business Service [UML の
クラズ図]
•
サービストランザクション (Service
Transactions) [[UML のシーケンス図]
•
詳細なビジネス文書(Business Documents)
[UML のクラス図]
•
実装
メッセージトランザクシ
Implementatio
ョ
n
Translation)
•
ン
•
(Message
•
ソフトウェア開発
(Software Development)
メッセージ設
計
規
則
(Message
Design Rules)
UML/XML マ
ッピング
(UML to XML
Mapping)
機能サービスビュー
(Function Service View, FSV)
•
コンポーネント図(Component Diagrams)
•
メッセージ仕様(Message Specifications)
•
ソフトウェアコンポーネント (Software
Components)
（３） UMM メタモデル
UMM では、プロセスモデルは UML (Unified Modeling Language) および OCL
(Object Constraint Language) を用いて表現される。ただし、プロセスモデル (取引相手
のインタフェースを通じて交信するオブジェクトの構造および動作に関する仕様) は、特定
業務分野に特化したものであるため、UML メタモデル (UML モデリング言語を定義する
モデル) が「ステレオタイピング」として知られる拡張メカニズムを使用して拡張され、そ
の領域に固有のシンタックスおよびセマンティクスを追加する。したがって、特定のビジ
ネスプロセス領域のシンタックスおよびセマンティックスを UML を用いてステレオタイ
ピングすることによって、ビジネスプロセスのメタモデルは UML メタモデルの拡張とし
て定義されることになる。
UMM では、オブジェクト指向のモデルとしてビジネスプロセスを表現できる UML メ
タモデル拡張の精密な定義を行っている。この拡張されたメタモデルは電子商取引メタモ
デル (e-Business Process Metamodel) と呼ばれ、ebXML 仕様においても、このメタモデ
ルをそのまま踏襲するようにしている。
メタモデルは以下の各ビューに分類されるため、いろいろな角度から各プログラムモデ
ルを確認することができる。
•
事業ドメインビュー (Business Domain View) メタモデル - 業種および取引分野
ごとにビジネスプロセスを分類する。
•
ビジネス要件ビュー (Business Requirement View) メタモデル – ビジネスプロ
セスモデルを表現するビューの一つで、ビジネストランザクションおよびその相互
関係に対するユースケースのシナリオ、入力、出力、拘束条件、およびシステムの
境界領域を表現する。
20
•
ビジネストランザクションビュー (Business Transaction View) メタモデル – ビ
ジネスモデルを表現するビューの一つで、取引情報の要素、および取引活動に伴う
各役割間の情報の流れのセマンティクスを表現する。
•
ビジネスサービスビュー (Business Service View) メタモデル – ビジネスプロセ
スモデルを表現するビューの一つで、ビジネスプロセスを実行し、有効化するため
に必要な相互作用として、ネットワークコンポーネントのサービスおよびエージェ
ント、およびそれらの間でのメッセージ (情報) のやり取りを指定する。
（４） UMM パターン
パターンは、再利用可能なビジネスプロセスを一般化、抽象化したもので、多くの領域
に適用可能な雛形となる。パターンは、特定のビジネスプロセスのシナリオの必要条件を
満たした記述構造になっており、ビジネスプロセスの共通表現に対してメタモデルを適用
したものである。この共通表現は、特定のビジネスプロセス領域に対して適用される共通
の構造およびセマンティクスを記述したものである。
以上、UN/CEFACT モデリング手法の概要につき解説した。当手法は大筋が平成 12 年ま
でにかたまり、それ以降 ebXML ビジネスプロセス関連仕様に採用されてきている。なお、
ebXML 仕様に具体的に適用する過程で、更に標準化すべき事項が多々指摘され、平成 14
年 3 月現在も未だ開発途上にある。
現在における主要な課題は次の 2 点である。
① ビジネスコラボレーションパターン
② ビジネス情報モデルとビジネスオブジェクト
21
4.2 OMG 標準化動向
4.2.1 概要
OMG は、オープンメンバシップの非営利団体で、企業のアプリケーションに対する相互運用
が可能な標準仕様を作成し保守するための活動を続けている。メンバには、コンピュータ業界の
主要な企業が加盟し、新興の企業やユーザ企業も多く参加している。特に、ビジネス環境の急速
な変化に対応するために、また激しい競争に負けないようにするために、各メンバは企業の将来
を担って参加している。これまでも、インターネット関連、実時間処理、組み込み型システム等
で活発な貢献がなされ成果を上げてきた。
OMG は、CORBA, OMG IDL, IIOP, UML, MOF, XMI, CWM, OMA を含む、企業にもっとも影
響力のある仕様のいくつかを開発してきた。２０００年に議論が始まった MDA は、次世代の相
互結合システムを定義するもので、医療、製造、通信など多くの分野で、ドメイン固有の機能、
及び相互運用フレームワークを提供するものである。
OMG では、３∼４ヶ月に１回のペースで TC（Technical Committee）会議を開催している。
２００１年度は、５回の TC 会議が開かれている。２００２年２月に、アナハイムで開催された
TC 会議の概要は、以下のとおりである。
（１）リエゾン会議
リエゾン会議は、ダブリン会議に引き続き、Bryan Wood が議長代理をつとめて開かれた。今
後は、Bryan と Tom Rutt（富士通）が、共同議長となることになった。長年議長を務めた Henry
Lowe が昨年亡くなられたので、OMG としての体制が懸案となっていたが、当面、ISO/IEC・ITU
関係の問題は、OMG 会長の Richard Soley が、その他のリエゾンは、Fred Waskiewicz が責任
をもつことが報告された。
ISO/IEC/JTC1 SC32 関係では、日本から提案している NWI：”Framework for Registering
Business Objects”について、OMG の MOF２の RFP と連携して進める方針であることを報告し
た（プレナリでも報告された）。なお、MOF の PAS 提案は、Explanatory Report を OMG から
提出するのを待っている状態であることが再度確認された。
（２）ADTF 会議（Analysis and Design Task Force）
各 CWM RTF、UML RTF、XMI RTF、MOF RTF、RT WG の進捗報告があった。特に、MOF1.5
の RTF（議長 Sridhar Iyengar）では、報告期限を 2002 の７月 1 日まで延期する動議がだされ
承認された。なお、あらたにメンバーのチャーターがあり、CBOP から大林が加わることが承
認された。
MOF2．0 の Query/Views/Transformation RFP の発表が、Wim Bast（Compuware）からあり、
CWM の Transformation をモデルの変換まで拡張することの要件などが説明された。これは、日
本からの NWI 提案の内容の一部にあたるものである。会議の後、Wim には、NWI 提案のことを
伝え、提案の内容をメールで送ることにした。
22
MOF2.0 の Core RFP サブミッションの事前説明があった。UML2．0 Infrastructure のサブミ
ッションの内容を反映して、MOF2．0 の Core を決める方針が示された。
UML2．0 Superstructure 改定サブミッションの進捗状況の発表が、３つのチーム（U2P、Fujitsu、
２U）からあり討議がおこなわれた。富士通からは、シーケンス図を、表形式で管理するための
仕様が提案されている。Superstructure の改定サブミッションの提出期限は８月。
UML2．0 Infrastructure の改定サブミッションの進捗状況の発表で、“３C”チームの提案と
“U2P”チームの提案とのすりあわせを行っていることが報告された。Infrastructure の改定サ
ブミッションは、６月。
また、Ed Seidewitz から、Infrastructure のメタレイヤーの考え方についての発表があり、core
と Kernel の関係、M3 と M2 の関係、記法と意味の関係などの解釈についての提案があった。
MOF2.0 が、M2 レイヤーに位置付けられており議論をよんだ。
（３）プレナリ及び所感
今回の OMG アナハイム TC（プラットホーム）会議では、サブミッションの採択案件が、1
件（CORBA Firewall Traversal Final Submission）だけで、その他は、CWM1．1 RTF、Components
FTF、CORBA Core RTF、IDL to Java RTF、Interoperability RTF、 Persistent State Service(PSS)
の各 RTF、FTF 最終報告が承認されただけで、議論をよぶような案件はなかった。
CORBA 関係の新しい動きとしては、CORBA と WSDL-SOAP、WSDL と CORBA-SOAP と
の連携の RFP が承認された。
UML Profile 関係では、Modeling QoS and Fault Tolerance の RFP と System Engineering RFI
が承認された。
ドメインの TC 会議では、Common Enterprise Models、C4I、Life Sciences Research、
Manufacturing、Space、Telecommunications、Transportation などの DTF から、会議の成果報
告があった。SIG では、Super Distributed Objects(SDO)、System Engineering などの会議の成
果報告があった。特に、Manufacturing の DTF は、System Engineering の観点や MDA などの
議論が活発のようである。一方、Finance 及び、Healthcare の DTF は、参加者が少なく体制を
立て直す必要があることが報告された。
ドメインの TF、SIG では、MDA の概念を取り入れる方向の議論がそれぞれのドメインで行わ
れている。
新しい動きとしては、CEM DTF、EC DTF、EAI DSIG を統合して、Business Enterprise
Integration(BEI) DTF とする動議がだされ承認された。
また、SECSIG が、ＯＭＧSecurity に関連する問題を、他のグループ（NAI Labs, National
Security Agency(NSA), Realtime, ORB/OS EC, EAI, CEM, SAML, OAISIS,CEMDTF など）との
共同の会議を連日開いて集中的に討議を行っていた。Security の問題が、ますます重要な課題と
なっていることが伺える。
23
4.2.2
MDA
（１）背景
計算インフラは、さまざまな方向にその範囲を拡大しつつある。新しいプラットホームとアプ
リケーションは、レガシーシステムと相互運用しなければならない。バーチャル企業が、複数企
業にまたがっている場合もある。インターネットは、すべての組織の隅々まで広がるように新し
い統合の挑戦を課している。その方向であたらしい実装プラットホームが作りつづけられ、さら
なる大きな要求が生じつづけている。
コンピュータアーキテクチャの台頭は、どの企業も技術の選択に困惑する状況である。それら
の投資を抑え、柔軟性を最大にするため、イーサーネットやＵＳＢのようなオープンな相互運用
標準を実装したハードウェアが、そして、ＣＯＲＢＡのようにオープンなインタフェースをもつ
ソフトウェアが採用されてきた。それは、現在の激しい技術革新、ビジネスの変化、マルチベン
ダ環境では、妥当な選択である。しかし、コンピュータとネットワークは、より速く、より安く、
相互連結の標準を発展させなければならない。新しい技術は、つねに、新しいアプリケーション
の登場を喚起する。いかにその潮流が速いかは、最近のＸＭＬの台頭をみればあきらかである。
標準化を基礎にした厳格な業務の情報システムを、新しい能力のハードウェアとソフトウェア
プラットホームの上で、どのように構築するかが課題である。現在、ＯＭＧは、MDA（the Model
Driven Architecture™.）でその具体的解決方法を提唱している。MDA は、発展するアプリケー
ションドメイン、例えば、企業のリソース計画、航空管制、人間ゲノム研究などの標準の発展を
支援する。それらの発展性や必要性に合わせていける標準をつくれば、多種のミドルウェアの出
現や技術の変化に苦労する必要はなくなる。
OMG のモデル駆動アーキテクチャ（MDA）は、配置、統合、アプリケーション管理、オープ
ンな標準だけでなく、設計の完全なライフサイクルについて言及する。MDA ベースの標準は、
それらが既存のものであれ、現在開発中のものであれ、将来開発するものでも、それらの統合を
可能にする仕組を提供する。
（２）確固たる基礎の上に構築
OMG は、オープンな採択プロセスを経て標準を作成し、その標準に適合した製品が市場にで
ることを推進する。MDA の標準化は、そのような標準化プロセスを踏襲した、重要で、革新的
な最先端のステップであり、これまでに開発された OMG 標準の確固とした基礎の上に構築され
る。具体的には、ソフトウェア開発企業に広く普及している、さまざまな場面に適用可能なモデ
ル記法である UML、XML を使用したモデルの格納と交換のための標準である XMI（メタデータ
交換）、そして、最もオープンなミドルウェア標準 CORBA などである。
OMG の MDA は、仕様の背後にある基本的なロジックを、それを実装する特定のミドルウェ
アの仕様から分離する。これには、新しい相互運用、配置技術に関する仕様の開発と配布を含む
が、すでに実証されたビジネスモデルをベースにしたものである。新しいプラットホームへの統
合化の場合にも、MDA を使用することにより、既存のプラットホームをベースとした既存のビ
24
ジネスロジックに関しては、これまでの投資を維持することができる。MDA は、今日の高度に
ネットワーク化された、常に変化するシステム環境で、以下を達成するためのアーキテクチャを
提供するものである。
•
互換性、アプリケーションの再利用を増し、現在の、そして未来のアプリケーション開
発と管理のコストと複雑さを減らす。
•
複数のプラットホームでの相互運用性を達成する厳格な方法を採用する。マルチ実装技
術をベースにした標準を保証するため、すべてが、同一のビジネス機能をもつ。
•
プラットホーム独立性は、時間、コスト及び複雑さを大幅に短縮し、これから導入する
さまざまなプラットホームに対して、アプリケーションの再構築を可能とする。
•
ドメインの仕様定義、ドメイン固有のモデルを介して、新しい多くのプラットホーム上
で企業固有のアプリケーションのすばやい実装を可能とする。
•
生産性、開発者、設計者、及びシステム管理者が満足できる言語や概念を使用でき、チ
ーム間のつなぎ目のない連携と統合を可能にする。
（３）最低ラインの利益
MDA の利点は、ビジネスリーダと開発者にも、以下のように重要である。
•
アプリケーションライフサイクルを通じたコストを減らす。
•
新しいアプリケーションに対して、開発時間を短縮する。
•
アプリケーションの品質を改善する。
•
売上と技術上の資源を増す。
•
発生する技術上の利点を、すばやく、既存システムに取り入れる。
MDA は、際限のない新たなプラットホームの出現に対応して、システムのインフラから独立
した確固としたフレームワークを与える。既存の技術の資産を保持し、あるいはてこにして、よ
りよい、より速い、より安いシステム統合の戦略を立てることを可能にする。
（４）モデル駆動アーキテクチャ：
情報システムの責任者は、組織の根本的な効率化に影響する内部ビジネスシステムの統合にク
リティカルな機会をもつ。長期的な視点をもつアーキテクチャで、すでに構築したものと、今構
築中のものと、これから構築する予定のものとを統合しなければならない。顧客、サプライヤー、
ビジネスパートナーのものと、自社のシステムとを統合するには、適当な業界標準を採用するこ
とが重要な決定である。ビジネス統合戦略としては、少なくとも、これからの２０年間の将来に
25
運用できるもので、同時に、既存のビジネス操作が継続され、発展することを許すようなもので、
しかも、技術やベンダーに中立的なプラットホームに実現されなければならない。
今日、複数の企業標準、CORBA、EJB/J2EE、.NET、XML/:SOAP が不幸にも存在し、そし
て将来、さらに増える可能性がある。現在、OMG の MDA イニシアチブでは、共通の傘アプロ
ーチをとり、統合を基礎にした標準を選択し、相互の調和に努力している。OMG の MDA は、
既存の標準化イニシアチブを支持し、それらを容易に取り入れることにより、異なる基盤技術を
用いて構築されたサブシステムの自動的な統合を促進する。
（５）OMG モデル駆動アーキテクチャ（MDA）：
システムをどう構築するかに対して、 MDA は、オープンでベンダーに中立的なアプローチを
提供する。OMG が築いたモデリング標準化の成果、すなわち、UML（Unified Modeling Language）、
MOF（Meta-Object Facility）、CWM（Warehouse Meta-model）の標準を基礎に相互運用性に
挑戦するアプローチである。
それらのモデリング標準を用いて構築されたプラットホーム独立のアプリケーションとして
記述される。主要なオープンな、あるいは、特定のプラットホームとしては、CORBA、Java、.NET、
XMI/XML、Web ベースなどのプラットホームがある。さらに、新しいプラットホーム及び技術
が生まれることも予想される。MDA は、新しい仕様の迅速な開発を可能とし、それらを用いた、
統合のプロセスを合理化する。MDA は、アプリケーション相互運用性と将来の可搬性のため、
ミドルウェアを超えて有効な構造化された解決策を提供する。UML でアプリケーションとプラ
ットホーム記述を作成することは、アプリケーション品質と可搬性にさらなる利益をもたらし、
十分、コストと市場に出すまでの時間を短縮できる。
このアーキテクチャは、OMG ですでに定義され普及しているサービスのすべてを包含してい
る。それらのサービスの多くのコアになるロジックは、すでに複数の実装技術に対して利用可能
である。例えば、Sun の J2EE プラットホームは、Java インタフェースを使用し、CORBA の
長いトランザクションやセキュリティサービスに対応している。もっとも重要なことは、特定の
仮想企業のために、MDA が標準的なドメインモデルを生成し、ドメインモデルを標準化するこ
とである。それらの標準化されたモデルは、複数のプラットホームで、現在、あるいは将来、実
現可能である。複数プラットホーム統合問題や、プラットホーム技術での変更の流行の不確定さ
に対して、IT 投資を抑えることが容易になる。
26
図 4.2-1 ＭＤＡの概念図
図 4.2-1 は、MDA の考え方を示した図である。MDA の中核は、言語や、ベンダーや、そして
ミドルウェアに対して中立であり、分散エンタプライズコンピューティング基盤の技術非依存
（PIM）のモデル定義である。
OMG の UML が組み込まれているので、EJB(Enterprise JavaBeans)のようなコンポーネント
ベースシステムや Web サービスを含む疎結合のメッセージベースシステムを表現できる。今日
の市場に出ている多種のアーキテクチャに対して、共通に認識されている概念を含む。
統一モデリング言語、UML は、分析と設計時に標準的な方法で、モデルを構築し、視覚化し、
開発し、操作することを可能にする。建物の青写真がオフィスビルのために作られるように、
UML モデルは、コード化される前に、アプリケーション設計の妥当性を評価し、吟味すること
を可能にし、そうして、変更が容易になり、開発費用を低く抑える。さらに、CWM（共通ウェ
アハウスメタデータ）は、データモデル（スキーマ）、スキーマ変換モデル、OLAP、及びデー
タマイニングモデルをどのように表現するかを標準化したものである。MOF（メタモデル機能）
は、リポジトリの中でモデルを操作するための機能を標準化したものである。そして、最後に、
XMI（XML メタデータ交換）は、MOF と人気の高い言語 XML をベースにしたモデルのための
交換形式である。
最終的な目標が、CCM、EJB、MTS、又は、その他のコンポーネント、又は、トランザクシ
ョンナルベースのプラットホームであっても、MDA ベースのアプリケーションを構築するとき
27
の最初のステップは、適当なコアモデルの用語を用いて UML で表現されたプラットホーム独立
のアプリケーションモデルを作成することである。プラットホーム専門家が、この一般的なアプ
リケーションモデルを CCM、EJB、又は MTS などの特定のプラットホームを目標にしたものに
変換する。標準的なマッピングは、変換の作業を自動化するツールを可能とする。図１は、これ
らの目標プラットホームは、コアの周りの薄いリングの部分に相当する。
プラットホーム独立モデルから、特定のプラットホームへのマップがされる時、我々は、その
プラットホームに固有な成果物（IDL、配置説明書、など）だけでなく、プラットホームに固有
の UML モデルも生成する。我々は、このやり方を採用する。なぜなら、UML モデルが、IDL や
XML よりは、より豊富な、プラットホーム固有のソリューションの意味論を表現できるからで
ある。
マッピングステップの自動化を最大にすることが目標である。しかし、ほとんどのケースは、
特に、MDA ツールなしでは人手によるコーディングが必要になる。ユーザとツール開発者は、
アプリケーションの意味のモデル化の経験と技術を蓄積して、よりよい開発ができるようになる
に従って、必要な資金の合計を減らせるようになる。
プラットホームに特化のモデルは、アプリケーションのビジネス的側面、及び技術的な実行時
の意味の両方を忠実に表現する。それは、また UML モデルであるが、（変換ステップのため）
UML の方言（プロファイル）で表現される。目標のプラットホームの技術的な実行時の要素を、
正確に反映したものである。プラットホーム独立のオリジナルのモデルの意味は、プラットホー
ム固有のモデルの中で実行される。
つぎのステップは、アプリケーションコード自体を生成することである。コンポーネント環境
に対して、システムは、多くのタイプのコードと構成ファイルを生成しなければならいない。構
成ファイルには、インタフェースファイル、コンポーネント定義ファイル、プログラムコードフ
ァイル、コンポーネント構成ファイル、及びアセンブリ構成ファイルなどを含む。プラットホー
ムに特化した UML 方言が、より完全に、実際のプラットホーム環境を反映すれば、アプリケー
ションの意味や実行時の振る舞いをより完全にプラットホームに特化したアプリケーションモ
デルの中に含ませることができる。そして、生成されるコードは、より完全なものになる。十分
に成熟した MDA 環境では、コード生成が価値あるものになり、あるいは、おそらく、それは、
ある種の自動生成においてであろうが、しかし、初期の実装の時でさえ、開発プロジェクトを単
純化し、それらのアプリケーションのプラットホーム独立な観点、及びプラットホーム固有の観
点を取り扱うためのアーキテクチャを提示する。
28
4.3 MOF／XMI 概説
4.3.1 メタモデルの概念
4.3.1.1 背景
近年、ビジネスプロセスや情報システムを俯瞰・分析・設計するための手法として、オ
ブジェクト指向に基づいたモデリング手法が急速に普及しつつある。特にＯＭＧ(Object
Management Group)が策定したモデリング言語ＵＭＬ(Unified Modeling Language)は、
いまやモデリング言語のデファクトスタンダードとして広く普及している。すでに多くの
ベンダがＵＭＬベースのモデリングツールを販売しており、ＵＭＬ関連書籍が毎年活発に
出版されている状況である。
また、最近では、1999 年 11 月に UN/CEFACT と OASIS が共同で設立した、ebXML が、
ｅビジネスのための XML 利用のためのフレームワーク仕様化を進めている。ebXML には、
国際標準化団体、各国の標準化機関、国際的民間コンソーシアム、企業などが多数参加し
ている。この仕様のモデリング手法として、UN の UMM（UMM：UN/CEFACT Modeling
Methodology）が利用されている。
このようにモデリング手法（言語）が活発に利用されるなかで、本書では、モデリング
言語のバックボーンである「メタモデル」と、メタモデルを記述するための仕様である MOF
について解説する。
4.3.1.2 メタモデルとは
メタモデルとは、ひとことでいうと、「モデリング手法／言語のセマンティクスを規定し
ているモデル」である。たとえば、オブジェクト指向モデリングでは「クラス」なるもの
が登場し、その「クラス」は、複数個の「属性」と複数個の「操作」を持つことができる
のが普通である。また、「クラス」どうしを「関係」で関連つけや、「クラス」間の「継承
関係」を設定することができる。ここで出てきた「クラス」、「属性」
「関係」や、それらの
関係（「クラス」は「属性」を持つ、など）を定義したものがメタモデルである。
29
4.3.1.3 メタ階層
モデリング手法とメタモデルとの関係をより明確にするため、ＯＭＧの”4-layer model”
（下図）で説明する
Layer
Spec
M3
MOF
Meta-meta
Example
model
M2
M1
Meta-Model UML Metamodel,
Model
MetaClass(“Class”,
IDL Metamodel
[MetaAttr(“name”,String),
CWM Metamodel
MetaAttr(“Attributes”,List<”Attribute”>)])
…
MetaClass(“Attribute”,…)
UML Models
Class(“StockQuote”,
IDL Models
[Attribute(“company”, String),
Attribute(“price”,FixedPoint)]
…
M0
Information Instance(data)
SotckQuote(“Sunbeam Harvesters”,98.77)
StockQuote(“Ace Taxi CabLtd”,12.32)
…
図 4.3-1
4-layer model
この図は、メタモデル、モデリング手法、モデリング手法で記述されたモデル、および、
モデルで表現された対象の実データの関係（メタ階層）を表現している。図の例に従って、
実世界（会社と株価）をオブジェクト指向のモデリング手法(例えば UML)でモデル化する
ことを考えよう。モデル化の結果として、「会社名(name)」「株価(price)」を属性として持
つ「会社(company)」クラスが切り出されたとする。この「会社と株価」モデルは M1 層に
該当する。また、そのモデルで規定された実世界のデータ（会社名 A、株価$98.77）が M0
層に相当する。一方、モデル(M1)も一定のルール（モデリング手法）に基づいて記述され
ている。上記の例でいえば「クラス(Class)」や「属性(Attribute)」といった概念、および
「属性として持つ」などの概念間の関係である。これらのルールを規定しているのが M2
層、メタモデルである。さらにメタモデルを記述するルール（メタメタモデル）も必要で
あり、M3 層がそれに相当する。MOF はこの M3 層の技術である。論理的にはメタメタモ
デルを記述するルールも必要であって、メタ階層が無限に続くことになる。しかし、MOF
では、MOF 自体が MOF で記述されているため、M3 以上の無限連鎖は不要になっている。
30
4.3.1.4 メタモデルの例
①
ＵＭＬメタモデル
この例は、UML のセマンティクスを規定する UML メタモデルの一部である（静的
モデルの一部）。
図 4.3-2 UML メタモデル（部分）
31
②
ｅｂＸＭＬビジネスプロセス
ebXML の各種仕様のうち、ビジネスプロセスに関するメタモデルの一部である。
n a m e : stri n g
B u si n e ss
P artn e r Ro l e
+p a rtn e rsn
1
A u th o ri ze d Ro l e
+p e rfo rm e d B y
M u l ti P a rty
+ co l l a b o ra ti o n
Co l l a b o ra ti o n
n
1
P e rfo rm s
n a m e : stri n g
1
+p e rfo rm e rs
+p e rfo rm e rs
n
n a m e : stri n g
i sIn i ti a to r : B o o l e a n
+a u th o ri ze d R ol e
+ro l e
1
n
1
+fro m
+co l l a b o ra ti o n
n
n
in
1
n
+e n te ri n g +fro m
T ra n si ti o n
1
+sta te s
o n In i ti a ti o n : B o o l e a n
+e x i ti n g o u t +to
co n d i ti o n G u a rd : S ta tu s
co n d i ti o n E xp re ssi o n : E xp re ssi o n n
1
B u si n e ssS ta te
+co l l a b o ra ti o n
n
C o mp l e ti o nS ta te
S ta rt
+u se s
1
Jo i n
Fo rk
g u a rd Co n d i ti o n : S ta tu s
1
n a m e : stri n g
p a tte rn : stri n g
ti m e T o P e rfo rm : T i m e
p re Co n d i ti o n : S tri n g
p o stCo n d i ti o n : S tri n g
b e g i n sWh e n : S tri n g
e n d sWh e n : S tri n g
1
+to
1
B i n a ryCo l l a b o ra ti o n
n a m e : stri n g
n
n a m e : stri n g
w a i tFo rA ll : B o ol e a n
n
B u si n e ssA cti vi ty
n a me : stri n g
S u cce ss
Fa i l u re
+u se d B y
n
B usi n e ss Tra n sa c ti o n
n a m e : stri n g
p a tte rn : stri n g
i sG u a ra n te e d De l i ve ryRe q u i re d : B o o l e a n +u se s
p r e Co n d i ti on : S tri n g
+a cti vi ti e s n
p o stCo n d i ti o n : S tri n g
1
b e g i nsWh en : S tri n g
e n d sWh e n : S tri n g
+tra n sa c ti o n
+tra n sa cti o n
1
B u si n e ssT ra n sa cti o n A cti vi ty
Co l l a b o ra ti o n A cti vi ty
ti m e T o P erfo rm : T i m e
i sCo n cu rr e n t : B o o l e a n
i sL eg a l l y Bi n d i n g : B o o l e an
<<E n u m e ra ti o n >>
S ta tu s
1
B u si n e ssA cti o n
S u cce ss
B u si n e ssFa i l u re
Te c h ni ca l Fa i l u re
A n yFa i l u re
n a m e : stri n g
i sIn te l l i g i b l e Ch e ckRe q u i re d : B o o l e a n
i sA u th o ri za ti o n Re q u i re d : B o o l e a n
ti m e T o A ckn o wl e d g e Re ce i p t : T i m e
i sNo n Re p u d i a ti o n Re q u i re d : B o o l e a n
i sNo n Re p u d i a ti o n O fRe ci e p tRe q u i re d : B o o l e a n
+re q u e ste r
1
+re sp o n d e r
1
Re q u e st i n g Bu si n essA cti vi ty
Re sp o nd i n g Bu si n essA cti vi ty
ti m e T o A ckn o wl e d g e A cce p ta n ce : T i m e
+re q u e sti n g
0 ..1
0 ..1
+re sp on d i n g
n+d o cu m e n tE n ve l o p e
+d o cu m e n tE n ve l o p e1
Do cu m e n tE n ve l o p e
i sP o si ti ve Re sp o n se : B o o l e a n
Do cS e cu ri ty
i sCo n fi de n ti a l : B o o l e a n
i sT a m p e rP ro o f : B o o l e a n
i sA u th e n ti ca te d : B o o l e a n
+d o cu m e n tE n ve l o p e
1
+b u si n e ssDo cu m e n t
1
+a tta ch m e n t
n
A ttac h m e n t
n a m e : S tri n g
m i m e T yp e : S tri n g
sp e ci fi ca ti o n : URI
ve rsi o n : S tri n g
図 4.3-3
n
+d o cu m e n tE n ve l o p e
ebXML ビジネスプロセス
32
B u si n e ssDo cu m e n t
n a m e : S tri n g
sp e ci fi ca ti o n L o ca ti o n : URI
0 ..1 sp ec i fi cati o n El e m e n t : S tri n g
+a tta ch m e n t
co n d i ti o n E xp re ssi o n : E xp re ssi o n
+b u si n e ssDo cu m e n t
n
メタモデル（部分）
4.3.1.5
メタモデル／メタメタモデルの重要性
メタモデルおよびメタメタモデルの意義について、まとめておく。
メタモデルは、モデリング手法のセマンティクスを規定した仕様という意味で重要であ
る。また、実用的見地から見ると、モデリング手法のメタモデル図を一瞥することで、そ
のモデリング手法の記述能力の範囲、記述ルールについての概要が理解できる利点がある。
メタメタモデルは、このモデリング手法の中核ともいうべきメタモデル自体の表現手段で
ある。メタメタモデルを標準化することで、メタモデルの定義、記述方法の標準化が可能
となる。さらにモデル間の情報交換が容易になる。
4.3.2
MOF
4.3.2.1 ＭＯＦの沿革
MOF(Meta Object Facility)は、OMG で標準化されたメタモデル記述仕様である。1997
年に MOF V1.0 が発行され、現在の最新版は MOF V1.3(2000 年 5 月)である。
4.3.2.2 ＭＯＦの構成
下図は MOF 仕様の概要である。
ModelElement
TypeｄElement
Namespace
Constraint
Tag
Import
Feature
GeneralizableElement
Parameter
Constant
TypeAlias
BehavioralFeature
StructuralFeature
Package
AssociationEnd
Classifier
Operation
Association
DataType
Class
<<MofExeption>>
Exception
<<MofAttribute>>
Attribute
Reference
6
図 4.3-4
MOF モデル
図内のオブジェクトは、メタモデルを記述するために用いられるオブジェクト群であ
る。主要なものについて簡単に説明する。
33
Class
メタモデルにおけるオブジェクト（メタクラス）を表現する
Association メタクラスどうしの関係を表現する
Attribute
メタクラスが持つ属性を表現する
Operation
メタクラスが持つ操作を表現する
Package
メタクラスのグルーピングを表現する
4.3.2.3 ＭＯＦで定義されたメタモデルの例
以下の OMG 仕様のメタモデルは MOF で記述されている。
・UML
・ＭＯＦ
メタモデルの例については図 4.3-2 参照。
MOF モデル自体が MOF で記述されている（図 4.3-4）。
・ＣＷＭ(Common Warehose Meatadata)
CWM はデータウェアハウス間のメタデータの相互運用性を図るために策定された
OMG の仕様である。異なったフォーマットを持つデータ資源（UML モデル、Java クラ
ス、リレーショナルモデル（RDB）、ＩＭＳ、など）のメタデータをＭＯＦベースで記述
している。下図は、リレーショナルモデルの一部である。
図 4.3-5
CWM メタモデル（部分）
4.3.2.4 ＭＯＦ関連製品
MOF に準拠した製品は、OMG ジャパンのサイト
http://www.omgj.org/technology/products/mof.html
に掲載されている。2002/3 現在で 12 製品がリストされている。
34
4.3.3
XMI
4.3.3.1 ＸＭＩの沿革
XMI(XMI based Metadata Interchange)は、OMG で標準化された、モデル情報をテキ
ストストリームで交換するための仕様である。1999 年に XMI V1.0 が発行され、現在の最
新版は XMI V1.2(2000 年 11 月)である。
4.3.3.2 ＸＭＩとＭＯＦ
ＸＭＩはＭＯＦで定義されたメタモデル、およびそのメタモデルにしたがって記述され
たモデル情報を交換するための仕様である。ＸＭＩ仕様では、ＭＯＦベースのメタモデル
の定義情報から、メタモデルに対応したＸＭＬ−ＤＴＤを機械的に生成するルールが規定
されている。（ＸＭＬ−ＤＴＤとは、ＸＭＬ世界におけるスキーマ定義体である）。したが
って、ＭＯＦでメタモデルを規定しさえすれば、ＸＭＬ−ＤＴＤも自動的に規定されたこ
とになる。
このＸＭＬ−ＤＴＤがあれば、先のメタモデルに従って記述されたモデル情報をＸＭＬ
形式で表現することができる。このＸＭＬ情報は、メタモデルを共有する手法・ツール間
で共通であるため、情報の交換が可能となる。以下に、4-layer model と XMI の関係を図
で示す。
Spec
Layer
Example
XMI
M
3
Metameta
model
MOF
M
2
MetaModel
UML
Metamodel,
IDL Metamodel
CWM
Metamodel
…
UML Models
IDL Models
M
1
M
0
Model
Informati
on
Instance(data)
MetaClass(“Class”,
[MetaAttr(“name”,String),
MetaAttr(“Attributes”,List<”Attribute”
>)])
MetaClass(“Attribute”,…)
XML DTD
Class(“StockQuote”,
[Attribute(“company”, String),
Attribute(“price”,FixedPoint)]
…
XML
SotckQuote(“Sunbeam
Harvesters”,98.77)
StockQuote(“Ace Taxi CabLtd”,12.32)
…
<!ELEMENT Class
(name,Attribute*)>
<Class>StockQuote
<Attribute>company</Attribute>
<Attribute>price</Attribute>
</Class>
7
図 4.3-6 4-layer model と XMI の関係
4.3.3.3 ＸＭＩの例（ＵＭＬ−ＸＭＩ）
もっともポピュラーなＵＭＬ用のＸＭＩを例としてあげる。先に、ＵＭＬメタモデルの
35
一部を例示したが、その部分のごく一部の”BehavioralFeature”(オペレーションの上位概
念)に対応するＸＭＩ−ＤＴＤとＸＭＩを下図に示す。
<!ELEMENT UML:BehavioralFeature (UML:ModelElement.name |
UML:ModelElement.visibility |
UML:Feature.ownerScope |
UML:BehavioralFeature.isQuery |
XMI.extension |
UML:ModelElement.binding |
（途中省略）
UML:Feature.owner |
UML:Feature.classifierRole |
UML:BehavioralFeature.raisedException |
UML:ModelElement.taggedValue |
UML:BehavioralFeature.parameter)* >
図 4.3-7 DTD とメタモデルとの対応
DTD とメタモデルとの対応について説明する。
Behavioral Feature が持つ属性は、isQuery(4 行目)、および、最後の行の、Behavioral
Feature が複数の parameter を保持できる部分のみである。それ以外の属性は、継承関係
の上位メタクラスが保持する属性である。XML-DTD では、オブジェクト指向の「継承」
にあたる記法がないため、上位オブジェクトから引き継いだ属性についても、すべて列挙
する必要がある。１行目の name は Model Element から、Scope Kind, Visibility Kind は
直上の Feature から継承したものである。
ＵＭＬメタモデルとＵＭＬ−ＸＭＩのＤＴＤが対応している様子が理解いただけたと思
う。
36
4.3.3.4 ＸＭＩが利用可能な製品(開発中含む)
XMI に対応したモデリングツール／リポジトリ製品を以下に示す。
(OMG 公式サイト http://www.omg.org/technology/xml/index.htm より)
ベンダ名
ツール名
備考／URL
IBM
XMIToolkit
IBM WebSphere, VisualAge for Java and XMI
for Rose toolkit
http://www.alphaworks.ibm.com
Unisys
UREP
http://www.unisys.com/marketplace/urep
Unisys
Unisys XMI for
http://www.rational.com
Rose
Oracle
Designer 2000
http://www.oracle.com
Softeam
objecteering
http://www.objecteering.com
togethersoft
Together/E
http://www.togethersoft.com
Meta
metadata bridges
http://www.metaintegration.net
Argo/UML
Argo/UML
http://www.argouml.org
Argo/UML
NSUML library
http://www.nsuml.sourceforge.net
DSTC
dMOF
http://www.dstc.edu.au
Integration
Technology Inc
4.3.3.5 ＸＭＩの今後(2002/3 現在)
最近、W3C において、ＤＴＤに変わるＸＭＬ用の新しいスキーマ仕様 XMLschema が勧
告となった。XMI においても XMLschema 対応仕様 XMI Production of XML Schema の
策定が開始している。
XMI 自身の V1.3 へのリビジョンアップ作業も開始している。また、MOF 2.0 に対応し
た XMI に対する議論も開始した。
4.3.4
参考 URL
OMG http://www.omg.org
OMG ジャパン http://www.omgj.org
OMG 仕様(UML/MOF/XMI/CWM についての仕様、解説、製品情報など
ebXML http://www.ebxml.org
以上
37
4.4 EDOC 概説
OMG（Object Management Group）で 2001 年 11 月に標準として採択された EDOC
（Enterprise Distributed Object Computing）、すなわちエンタープライズ分散オブジェク
トコンピューティングの概念と UML について解説していく。
4.4.1
EDOC とは
エンタープライズシステムには、ビジネスプロセスと直結したシステム機能が必要であ
る。そして、オブジェクトモデルは、ビジネスプロセスと連動しているべきだ。このモデ
ルは、シームレスに実装アーキテクチャへと実装される。エンタープライズシステムの実
装環境には、ラージスケールに分散されて、多くの並列処理要求、膨大なデータ管理が必
要である。イベントドリブンで、トランザクションによるアーキテクチャである。
このような環境の EDOC にもっとも重要な要素は、ビジネスプロセスである。ビジネス
側からの要求仕様上の機能は、ビジネスプロセスとして実現できる。例えば、取引におい
て、売り手と買い手があったとする。そして、買い手は売り手に注文をだす。この注文に
よって、売り手のビジネスプロセスが処理を行う。このビジネスプロセスは、CORBA など
EDOC におけるビジネスオブジェクトとして実装されるのだ。
ビジネスシステムを開発するためには、この要求仕様をモデリングする必要がある。UML
（Unified Modeling Language）によってモデリングする。そして、EDOC 用の UML の
拡張セットが UML Profile for EDOC である。
そして、このビジネスモデルは、実装技術であるコンポーネントにマッピングすること
が可能でなくてはならない。コンポーネントとは、EJB（Enterprise JavaBeans）や CCM
（CORBA Component Model）のことを言う。ビジネスプロセスは、単なるビジネスオブ
ジェクトだけではなく、コンポーネントとして動作するようになる。
4.4.2
EDOC の要素
EDOC に必要な要素を４つ上げる。
・ビジネスエンティティ
・ビジネスプロセス
・ビジネスルール
・ビジネスイベント
ビジネスモデルを整理していくときに、これらの要素はどれもが必要なものである。ビジ
ネスエンティティとは、データベースの ER（Entity-Relationship）モデルにおける、デー
タストアに相当する。そして、ビジネスルールをビジネスオブジェクトに組み込むことで
プロセスは正確に動作するようになる。イベントは、ビジネス上の出来事であり、それが
起きたことによって、別プロセスに処理が移動したり、新しいフローが発生したりする。
これら４つの要素がビジネスモデルを構成していく。
4.4.3
ビジネスシステムの環境
今日のビジネスシステムは、アウトソーシング、サプライチェーン、E コマースなどに代
表される。それぞれ、B2B（Business To Business）
、B2C（Business To Customer）など、
38
登場人物、すなわちアクター間の関係が重要である。例えば、顧客が E コマースで PC を
購入する場合を考えてみる。顧客とシステムのやりとりがどうなっているかがアクター間
の関係である。その関係を、ビジネスコラボレーション（協調）と呼ぶ。
そして、ビジネス機能が正確に実現されること、誰が起動するのか、どのようなシーケ
ンスになっているかなど、サービスを組み立てるプロセスエンジニアリングが重要である。
さらに、すべての要素は、ビジネス環境の変化に瞬時に対応できなくてはならない。
4.4.4
ECA（Enterprise Collaboration Architecture）
これらに対応したアーキテクチャとして、UML Profile for EDOC の提案者チーム（Sun、
富士通、Data Access Technology、Genesis Development、EDS、Open-IT、SINTEF、
CBOP）は、ECA を考案した。
ECA とは、フレキシブルで再利用可能なビジネスコラボレーションのアーキテクチャで
ある。それらは、B2B／B2C、EAI（Enterprise Application Integration）、ミドルウエア
（メッセージングサービスなど）、パラダイム（同期／非同期など）を含んでいる。
そして、再利用可能にする技術としては、パターン技術による設計、コンポーネント、
コンポーネントモデル、相互作用が可能なビジネスコンポーネントとサービスである。そ
して、相互作用が可能なコラボレーションによるインフラ、ビジネスコンポーネントによ
り、新たな市場が生まれるのである。
4.4.5
ECA の概要
それでは、ECA を構成する要素を図 4.4-1 に示す。
ビジネスプロセス
コラボレーション
ロール
ビジネスオブジェクト
ビジネスイベント
コンポーネントモデル
図 4.4-1 ECA の要素
この図は、各要素をメタモデルとして表している。メタモデルについては前章で解説し
ているが、抽象的に物事を考えなければいけないので、難しいかもしれない。図１では、
ビジネスプロセスはコラボレーションによってつながっている。コラボレーションロール
を持っている。ロールは、ビジネスエンティティなどのビジネスオブジェクトとして振る
舞う。そして、ビジネスオブジェクトがイベントを引き起こすと、ビジネスプロセスを起
39
動する。また、ビジネスオブジェクトはコンポーネントモデルとなることもある。
ここでは、コラボレーションについて詳しく見てみる。コラボレーションは、メッセー
ジフローなどのビジネスプロセス間のやりとりを記述できる。そして、プロセスはロール
をいくつか持っている。例えば、顧客は買い手というロール（役割）を持っているのと同
時に（銀行からの）引き出しというロールも行う。
引き出し
買い手
顧客
銀行
供給者
図 4.4-2 ロール
そして、ロールの振る舞いを記述するモデルをロールモデルと呼ぶ。このロール自身もコ
ラボレーションである。コラボレーションで定義できるものは以下になる。
・オブジェクトの目的
・コラボレーションを目的とするコンテキストで書くオブジェクトがどういった責任を持
っているか。
・オブジェクト通信としてつないでいるリンク
・共通目的を得るためのオブジェクト間のメッセージフロー
そして、コラボレーションの機能を以下に挙げる。
・インターラクションを実装
・エンタープライズコンピューティングのすべてのレイヤに適用可能。レイヤ間のマッピ
ングトレースができる。
・ファシリティの再利用
・よりよい精度に改良する。
・仕様とインスタンスの両方のレベルで使える。
・マッピング可能
・ビジネスオブジェクト
・RM-ODP のビューポイント
・主なコンピューティングパラダイム（同期／非同期／イベント）
・主なコンポーネントモデル（CORBA、EJB、COM）
4.4.7 コラボレーション
（１）パターン
UML でいうコラボレーションの代表的な例は、コラボレーション図で表すモデルである。
例えば、図 4.4-3 のようになる。各オブジェクト間のメッセージの流れを示している。メッ
セージが入ってくると、コラボレーションして動作していく。顧客オブジェクトは、注文
において、価格を受け入れて注文が成立すると、銀行オブジェクトにその代金を払い込む。
１．価格受入
２．振込
：銀行
：顧客
図 4.4-3 コラボレーション図
40
最新の UML1.3 では、コラボレーション図にクラスが記述できるようになった。今までは、
インスタンスレベルのオブジェクトしか扱えなかったが、これで仕様レベルも記述可能だ。
コラボレーションとして扱うものに、パターンもある。UML では、デザインパターンな
どのパターンをコラボレーションとしている。パターンを表すのに、パラメータ化コラボ
レーション図を使う。図 4.4-4 に基本的な使い方を示す。
Manager
Subject
Subject
Observer
Observer
Observer
View
図 4.4-4 パラメータ化コラボレーション図
このパターンは、GoF のデザインパターン*1 の中の Observer パターンを示している。
Manager、View というクラスがそれぞれ Subject、Observer という Observer パターンの
クラスにあたる。すなわち、クラス名が置換されているのである。このパターン表記を展
開すると、図 4.4-5 のようなモデルになる。Observer パターンのコンクリート Subject が
Manager、コンクリート Observer が View になっている、
Subject
Observer
attach(Observer)
Updete（）
observer
detach(Observer)
notify()
View
subject
observerState
Manager
update()
subjectState
getState ()
図 4.4-5 Manager/View モデルの展開
次に、EDOC のためのビジネスプロセスに関してのパターンについて、見ていく。図 4.4-6
は、注文プロセスパターンを顧客／供給者というモデルに適用している。
41
買い手
注文プロセス
売り手
顧客
供給者
図 4.4-6 パラメータ化コラボレーション
注文
買い手
売り手
図 4.4-7 注文プロセスパターン
この注文プロセスパターンとは、図 4.4-7 のようになっている。注文における、買い手と
売り手の関係をパターンとして定義している。モデルを再利用可能な形態として、パター
ンとして表している。
注文
顧客
供給者
買い手
売り手
図 4.4-8 顧客／供給者モデル
このモデルのパターンを展開すると図 4.4-8 のようになる。供給者と顧客の間には、それ
ぞれ売り手、買い手といった関連がある。ここでは、ビジネスプロセスのモデリングをし
ているので関連ではなく、ロールということになる。
さらに、金銭取引プロセスパターンと振込プロセスパターンを図 4.4-9、図 4.4-10 に示す。
それぞれは、単純なパターンになっているが、それを複数適用すると図 4.4-11 のようにな
る。
金銭取引
払い込み
引き出し
図 4.4-9 金銭取引プロセスパターン
42
振込
振込依頼
図 4.4-10
買い手
振込受取
振込プロセスパターン
注文プロセス
売り手
顧客
供給者
払い込み
引き出し
金銭取引プロセス
払い込み
引き出し
顧客の銀行
供給者の銀行
振込依頼
振込プロセス
図 4.4-11
振込受取
購買モデル
顧客と供給者に、注文プロセスパターンを適用して、顧客と供給者の関係すなわち注文プ
ロセスのコラボレーションを作り上げている。顧客と顧客の銀行には、金銭取引プロセス
パターンで、顧客が銀行に注文代金を払い込むプロセスを表している。そして、銀行間で
は、振込プロセスパターンによって振込処理を、最後に供給者は自分の口座を持っている
銀行から代金を引き出す。
さらに、すべてのパターンを展開してオブジェクトモデルにすると図 4.4-12 のようになる。
43
購買プロセス
注文
顧客
売り手
買い手
払い込み
供給者
引き出し
金銭取引
金銭取引
引き出し
払い込み
顧客の銀行
振込
振込依頼
図 4.4-12
振込受取
供給者の銀行
展開された購買モデル
今説明したモデルのパターンによるメタ化をひもといた。このレベルのオブジェクトモデ
ルでは再利用を引き出すことは難しい。しかし、パターンを導入して同じパターンが複数
使われていればパターン部分が再利用される。
このモデルは、パターンを一階層だけ適用しているが、これが複数階層パターンを適用し
ていくことになると、さらに再利用性が増し、有用性がアップする。
（２）ロールモデル
ロールによるモデリングは、最近、よく利用されるようになってきた。ロールにモデリン
グと従来の方法との違いを図 4.4-13 にしめした。会社などの組織のオブジェクトモデルを
考えてみる。従来、従業員、部長、課長、プロジェクトリーダーなどその分類を考えると
図 4.4-13 のようになった。ところがこのモデルだと、課長とプロジェクトリーダーを兼務
した場合に、煩雑になる。ここでロールモデルを使うと、会社員オブジェクトが課長は従
業員を管理するという関係の場合のロール、プロジェクトリーダーはプロジェクトという
関係の場合のロールとして使い分けることができる。クラスを新たに作成するのではなく、
ロールを持たせることによって、モデルを整理する。
44
会社員
部長
プロジェクト
リーダ
課長
従業員
プロジェクト
従業員の管理
会社員
課長
プロジェクトリーダー
図 4.4-13 ロールモデリング
それでは次に、パターンをロールモデルとして扱うとどうなるだろう。図 4.4-14 は、買
い手と売り手を UML1.3 のロール表記を使って表している。ロールは、オブジェクト名：
クラス名／ロール名という構文で書くことができる。注文プロセスパターンとして図 4.4-7
で定義したコラボレーションをロールモデルで表した。
/売り手
/買い手
売り手＿買い手
買い手＿売り手
<<interface>>
売り手＿買い手
<<interface>>
買い手＿売り手
AcceptOffer
MakeOffer
MakeCounterOffer
AcceptCounterOffer
RejectOffer
図 4.4-14
ロールモデル
さらに、このロールモデルを顧客／供給者モデルに適用すると。図 4.4-15 のようになる。
顧客／買い手
注文
供給者／売り手
図 4.4-15 ロールモデルの適用
クラス名の次に／ロール名を追加している。さらに、ロール間のフローは図 4.4-16 のよう
45
にシーケンス図とコラボレーション図で表すことができる。
シナリオ：１
/買い手
シナリオ：２
/売り手
/売り手
/買い手
１：makeOffer
/買い手
１：makeOffer
２：makeCounterOffer
２：makeCounterOffer
３：acceptCounterOffer
３：rejectCounterOffer
１：makeOffer
１：makeOffer
２：makeCounterOffer
２：makeCounterOffer
２：acceptOffer
/売り手
/売り手
１：makeOffer
１：makeOffer
２：acceptOffer
/買い手
シナリオ：３
/買い手
/売り手
３：acceptCounterOffer
/売り手
/買い手
３：rejectCounterOffer
図 4.4-16 ロールのシーケンス
これらは、注文というコラボレーションのフローをシナリオで表している。シナリオ１は、
買い手が売り手に価格を提示して、売り手は価格を受け入れられるかを返している。この
ように、ロールのフローはシーケンス図を使って表し、複数のシナリオを書くことができ
る。
4.4.8
UML Profile for EDOC 仕様
ここから具体的な EDOC の仕様を見ていく。EDOC の基盤となっている考え方は、ISO
の標準になっている RM-ODP である。RM-ODP は、システムを５つのビューポイントに
よって捉えている。そして、ロールベースのモデリングを行っていく。EDOC では、RM-ODP
に各要素を以下のように分類している。
エンタープライズビューポイントは、CCA すなわちコンポーネント表記、プロセス、エ
ンティティ、リレーションシップ、イベントによって、モデルを表す。コンピュテーショ
ナルビューポイントは、CCA、エンティティ、イベントなどである。そして、エンジニア
リングで、実装非依存のモデルへマッピングしてから、最終的にテクノロジビューポイン
トによって、EJB などの実装環境へマッピングする。この考え方は、OMG の今後の方針
である MDA（Model-Driven Architecture）モデル駆動アーキテクチャの基礎となってい
る。
46
Enterprise viewpoint
(CCA, Processes, Entities, Relationships, Events)
Part I: ECA
Information viewpoint
Computational viewpoint
(Entities, Relationships)
(CCA, Entities, Events)
Engineering viewpoint
(Technology abstraction: FCM)
Part II:
ECA to
technology
mappings
Part I:Technology
Specific Models
Technology viewpoint
(UML for J2EE/EJB/JMS, CORBA 3/CCM, COM, SOAP, ebXML)
Part I: Patterns - applied to all viewpoints
この EDOC 表記の中で、代表的な参照表記を以下に示す。EDOC はあくまでも、UML
Profile なので、仕様自身では特別な図形は定義していない。ステレオタイプとタグ付き値
で表現する。しかし、現実的には見づらいので、これらに対応した表記を用いる。EDOC
仕様では、参照表記として、次のような書き方を掲載している。
47
same day radiological examination receptionprocess
same day radiological
examination reception
go to the reception desk
of the radiological
department
IDcardInfo
PatientInfo
notify arrival
scan ID card
certify patient
IDcardInfo
Patient
/Outpatient
Staff/RadStaff
ScanIDCard
IDcardInfo
PatientCertification
PatientInfo
Patient
Certification
emergency
cancellation
of examination
get examination
order
GetExamOrder
RadTechnologist
/ExamReception
PatientInfo
ExamOrder
assess before
examination
patient status
not suitable
instruct to take
other examinations
GetExamOrder
RadTechnologist
/ExamReception
ExamOrder
waiting for
examination
confirm
examination order
examination
performed
assign
examined images
ExamOrder
RadTechnologist
/ExamReception
examination suitable
RadTechnologist
/ExamReception
instruct to enter
examination room
Patient
/Outpatient
enter into
examination room
ビジネスプロセス
<<Entity Data>>
<<Entity Data>>
DirectInfo
PlacerInfo
<<Entity Data>>
<<Entity>>
<<Entity Data>>
ExamOrderDat
ExamOrder Compo nent
InterpretOrderText
<<Entity Data>>
<<Entity Data>>
ExamOrder
Sub-OrderInfo
<<Key>>
Exam Order Key
<<Key Attribute>>
OrderNo
コンポーネント（コンポーネント）
48
ScanIDCard
SｃanIDcardReception：
ScanIDcard：：
ScanIDcardReception
GetIDcardInfo
GetIDcardInfoReception ：
GetIDcardInfo：：
GetIDcardInfoReception
GetIDcardInfoRequest：
GetIDcardInfo ：：
GetIDcardInfoRequest
コンポーネント（プロセス）
GetIDcardInfo
IDcardInfo
GetIDcardInfoRequest
responderRole
GetIDcardInfoReceptio ｎ
initiatorRole
GetIDcardInfoRequest
<<initiates>>
GetIDcardInfoRequest
<<responds>>
IDcardInfo
コンポーネントのメッセージフロー
4.4.9 参考文献
・コンピューターサイエンス誌 bit 2000.9 月号共立出版
・コンポーネントモデリングガイドピアソンエデュケーション
・UML Profile for EDOC OMG
49
4.5 データ要素の命名法則に関する考察
4.5.1 この考察の位置付け
ISO/IEC JTC1 配下の SC32 WG2 で標準化活動を行っている ISO/IEC 11179 の規
格群はメタデータを含めてデータ要素の基本的な側面を規定している。その中で、第
5 部は「データ要素の名前付け及び識別の原則」
（Naming and identification principle
for data element）がある。この部に関しては現在 CD として検討中であるが、日本、
韓国、中国をはじめとする表意文字使用圏においては、現在検討中の CD では、対応
不能部分が存在することから 2001 年の SC32 Victoria 会議において Annex を付加す
ることとなった。
この考察は、11179-5 の Annex として検討中のものである。
4.5.2 言語と文字
「一般に、地球上のある種族の話す言語と、その種族に属する人々のものの見かた
考え方とは深い関係がある。フランス人のものの考え方とフランス語は深いかかわり
がある、ドイツ人のものの考え方とドイツ語は切り離せない。これは言うまでもない
当然のことだから、西洋の言語を学んだ者ならだれでもわかっている。国語と国民性
の因縁の深さは当然である。それをわかっていながら、言語と文字とのかかわりにつ
いては、なんら必然的なものではなく、ごくごく疎なものである考える傾向があった。
これもまた当然であった。西洋の言語学は、人類が話す言語はこれをきわめて重大視
するが、文字については、これをただ言語のかげとしてみなしてすこしも問題にしな
かった。」なぜなら、西洋の言語は音標文字であるアルファベットのつづりで表現さ
れており、漢字の持つような複雑な意味のある構造を持っていないからである。
「西洋の言語学は、言語を、種族の精神と深くかかわるものとして、きわめて重要
視する。反して、文字を軽視、あるいはほとんど無視する。実際に西洋の言語におい
て文字のしめる位置はごく軽いものである。西洋の言語学は西洋の言葉を研究対象と
して生まれかつ発達したものである。」
以上引用高島俊男著「漢字と日本人」（文春新書より）
また、この文章の基本的な部分も上記の引用である。
11179-5 の基本も西洋の言語学に根ざしている。したがって、語の並び順に関して
はその規定が明確であるが、文字に関する規定はまったくなされていない。ここに、
日本語や韓国語、中国語に対して 11179-5 の構造が示し得ない大きな問題が存在する。
「言語と文字とは非常に関係が深いものである。」という前提に立って、11179-5
について言及する。
まず、言語の分類について概観する。
（1）言語の分類
世界の言語を分類すると、基本的に次の 3 種類となる。
50
支那西蔵言語族 Sino – Tibbettan Languages
中国語（Chinese Language）、タイ語（Thai Language）、ビルマ語（Burma
Language）など
インド・ヨーロッパ言語族 Indo – European Language
ラテン語（Latin Language）、英語（English Language）、スペイン語（Spanish
Language）、フランス語（French Language）など
分類不能な言語 Other Languages
日本語（Japanese Language）、バスク語（Basque Language）など
これらは、発生した場所や基本文法、文字などで分類される。日本語は漢語（漢字）
を使用するが、言語の分類としては、漢語とはまったく異なる。
インド・ヨーロッパ言語族の言語と支那西蔵言語族の言語では文法上は類似点が多
い。例えば、動詞と目的語の位置関係、助動詞の位置、前置詞の存在などである。
修飾語は、どの言語でも一般的に被修飾語の前に付けられるが、時点を表す修飾語
は西洋語では最後につけられる場合が多い。
一方、日本語とインド・ヨーロッパ言語族の言語の類似点は、動詞の変化であり、
複音節での単語の形成である。この音節の問題が言葉の形成では大きな要因となる。
（2）文字の分類
文字の分類は基本的に、音標文字、表意文字に分類されるが、この表意文字という
概念は必ずしも正しくない。なぜなら、漢字の一字は意味と並んでことば（単語）を
表現しているからである。
それでは、表意文字とは何か、代表的な表意文字は数字である。
１、2、3 はそれぞれの言語によって発音は違うが、１、2、3 という意味は同じで
あり、意味のみを表現している。特定の発音を持たない、特定の語を表記したもので
はない。
音標文字は意味にかかわりなく、音のみをしるす文字である。日本語は基本的には
文字を持たなかったが、中国とのかかわりにより漢字の使用と漢字を下にした「カタ
カナ」、「ひらがな」という音標文字を併用する特殊な文字使用国となった。
（3）音節による分類
音節とは、人が言葉をしゃべる際に口から出てくる音の最小の単位である。漢語は、
一語一音節一字という形態からなっている。西洋の言葉は、これとはまったく異なる
音節を持っている。日本の言葉の音節は、非常に単純である。
漢語は、一語一音節という特徴を持っている。また、漢語の基本は「組み合わせ語」、
「複合語」、「熟語」であり、その構造の基本は「動賓構造」となっている。「組み
合わせ語」が基本となっているということは、西洋の言葉で言う「単語」とは、まっ
たく異なる概念であることを示している。
51
したがって、単語という概念は西洋の言語分析からの概念であり、この単語という
概念を漢語の説明に適用するのは困難である。
ここが、11179-5 の各語の分類が漢語（漢字）を使用している、中国語、韓国語、
日本語へ適用した場合に齟齬が起きる最大の要因となる。
（4）単語概念の違い
簡単に言えば、「英語は一つ一つの単語が独自のつづりを持つ」、「漢語の一つ一
つの単語はそれぞれ独自の文字を持つ」ということである。したがって、 Chinese
Characters というよりはむしろ考え方としては Chinese Spellings と考えた方がよい。
漢語は、ひとつの文字で意味を持ち、一音節なのだが、これが二つ集まって安定す
る。日本語で言う「熟語」となって安定する。したがって、二音（二文字）の組み合
わせ語が非常に多くなる。
たとえば、漢語「考」、「試」はひとつの単語である。「考」も「試」意味は日本
語では「しけん」、英語では「examination」である。同時に「考試」も「examination」
という意味を持った単語である。
したがって、したがって、漢語の基本は「組み合わせ語」、「複合語」、「熟語」
である。
（5）英語単語と漢語の対応
明治維新以降の西洋語の日本語化が急速に起きた。政治、法律、経済産業、建築、
交通、通信などほとんどの生活分野で西洋語の日本語化を行った。それらには、基本
的に漢語が使用された。
例えば、経済産業の分野では、会社、企業、銀行、保険、信託、証券、不動産、金
融、機械、輸送、経理、営業、総務、企画などである。
これらの和製漢語が明治維新以後に作られたのは、江戸時代まではそれらの概念が
なかったもの、概念があっても言葉を新しく作った場合もある。例えば「債権」、「債
務」とういう言葉は和製漢語であるが、これらにはもともと「貸す」とか「借りる」
とかいう言葉が対応していたが、法律的な根拠を明確にするために、「債権」、「債
務」という言葉を作ったのである。これらの翻訳漢語は中国でも使用された。当然、
中国で作られた翻訳漢語も多い。
ここで、指摘したいのは多くのビジネス用語は翻訳漢語が多く使われているという
ことである。ビジネス用語に翻訳漢語が多く使われているということは、情報システ
ムにかかわる用語の多く（ほとんど）は、対応する西洋語が存在するということであ
る。
（6）意味構造のずれ
一方、概念的なものを分類表現する際に、同じ文字でありながら、漢語の文字の持
つ意味構造と、西洋の言葉の意味構造で大きな差を持つ場合がある。例えば、「かず」
52
という概念は日本語が旧来持っていた意味「物の多少を算（カゾ）えたもの」1 と同時
に西洋語の導入によって加わった概念「〔数学で〕自然数およびその概念を順次拡張
して得られる整数・有理数・実数・複素数などいずれか一つの範囲を定めて数学の
ある理論を展開する時に、その範囲に属する一つひとつの要素の称。」2 の 2 つの意味
を持つ。
したがって、日本語（多分、中国語も韓国語も）「数」という概念はすべての「物
の多少を算（カゾ）えたもの」の概念を表現する。英語で言う「Measure」、
「Quantity」
という概念は存在しない。
4.5.3 ISO/IEC 11179-5 との対応
（1） ISO/IEC 11179-5 の概要
11179-5: Naming and identification principles for data elements
（データ要素の名称と定義の原則）このパートでは、データ要素の命名と識別にかん
するガイダンスを述べている。データ要素定義全体に関する明示や識別することを典
型的なデータ要素によって行っている。
11179-5 は、厳格に構造化されたデータ項目の命名を協定するガイドラインである。
これらの規則は、データのネーミング規定を形成する。この規則によれば、名前が
単純化されたシンタックスを使用するために、容易にオリジナル（英語）以外の言葉
に翻訳することができる。シンタックス的な意味論的な、そして語彙（Lexical）的な
規則が、企業あるいは標準化団体のような組織によって変化させることができる。
下記のように、各データ項目、そのコンテキスト内の構造のセットから選ばれた 1
セットの項目から形成される。
データ項目名は、項目、割り当てられた意味（意味論 Semantics）および名前の関
係詞または絶対的なポジション（シンタックス Syntax）の名前から形成される。そ
れらは、語彙の規則を受け、分離記号で分離される。
・名前部分の意味論
各部分は、個別の言葉から構成される。ISO/IEC 11179-5 に記述された部分は次の
とおりである。
・オブジェクト・クラス用語
オブジェクト・クラスは、コンテキストの中でアクティビティ、オブジェクト
を表すデータ項目の部品である。ER モデルにおけるエンティティの属性は、方
法論を適用することにより、お互いに関係のあるデータ項目と一致する。
オブジェクト・モデルでは、データエレメントがオブジェクト属性として表現
1
2
Shin Meikai Kokugo Dictionary, 5th edition (C) Sanseido Co., Ltd.」
同上
53
される。
モデルが、データ項目にある種類の分類案を提供する。データ項目が、オブジ
ェクト・クラス用語をモデル・エンティティにマップすることによって、エンテ
ィティがその名前を示し、それらの関連するモデリングと同一視される。
この標準によって、データ項目の中で、概念の領域、データエレメント概念お
よびデータ要素は、オブジェクト・クラス用語を含んでいる。データ・バリュー・
ドメインは、オブジェクト・クラス用語を含んでいる場合も、含んでいない場合
もある。
従業員姓
原価予算期間合計額
木高さ計測単位
メンバー姓
この中で、従業員、原価、木およびメンバーがオブジェクト・クラス用語であ
る。
・プロパティ用語
プロパティ用語は、プロパティの分類の中の 1 セットの名前の部品から構成され
る。たとえば、データ要素の中で、
従業員姓
原価予算期間合計額
木高さ計測単位
メンバー姓
姓、合計額、および高さがプロパティ用語である。
オブジェクト・クラス用語およびプロパティ用語の両データ要素は、名前を形成
するために使用される。また、2 つの構造のセットからデータ項目のデータに関
する分類の補足的な方法を提供する。
・リプレゼンテーション用語
リプレゼンテーション用語は、データ項目の表現形式について、記述するデー
タ項目名の一部である。各用語は、管理された単語のリストまたは分類から構成
されている。リプレゼンテーション用語は、次のような表現形式で分類される。
・名前
・額
・計量単位
・番号
・数量
・テキスト
この用語は、データ項目の有効な値のセットの形式について記述する。多くの場
合、リプレゼンテーション用語はプロパティ用語の一部で冗長の場合がある。こ
れが生じる場合、構造化した名前の中で除去される場合がある。これは命名協定
の中でルールとして確立することができる。
54
たとえば、データ要素の中で、
従業員姓（Last Name）
木高さ計測単位
においては、項目として計測単位および Name がリプレゼンテーション用語で
ある。Last Name はプロパティ用語である。
・修飾用語
ユニークにデータ項目を識別するのに必要な場合、修飾用語はオブジェクト・
クラス用語、プロパティ用語およびリプレゼンテーション用語に付けられる場合
がある。これらの修飾用語はコンテキストに特有の構造のセットに由来する。命
名協定の規則では、修飾用語の数の制限が推奨される。
たとえば、データ要素において、
原価予算期間合計額
において、予算および期間が修飾語である。
原文註：修飾語の用語の制限は、シノニムの除去によりデータ項目の再使用の冗
長性および発生の増加率を抑えることを支援する。これは、オブジェクト・クラ
ス用語、プロパティ用語、リプレゼンテーション用語にも適用できる。用語辞書
のメカニズムはこの努力を支援する。
セパレータ
名前の分離は、セパレータによって定められる。
a) 意味的には意味のないセパレータ
命名規則に拠れば、部分の意味的な関係にかかわらず、1 つのブランク・スペー
スあるいはハイフン、下線（Underscore）をセパレータとして使用する。この
ような規則はデータ項目の名前の構成を単純化する。
b) 意味論的意味を持つセパレータ
意味論的意味とは、セパレータに使う記号を変えることによって、意味を持たせ
る方法である。
たとえば、データ要素において、
原価-予算_期間-合計-額
この場合、セパレータは修飾語には下線が、他の名前の部分はハイフンが使用さ
れている。（ただし、ハイフンは多くの場合、DBMS では使用できない。）
筆者註：日本語のデータ項目も基本的には単語であるので、下線での分離が可能で
ある。11179-5 が標準化された場合、従来 CII などで実施していたセパレータなし
のデータ項目名はすべて変更を余儀なくされる可能性が大きい。XML/EDI の標準
化団体である ebXML もこの方式を採用している。
55
名前のフォーマットを管理する法則
シンタックスの法則
シンタックスの法則は、名前の配置を指定する。この配置には相対的な配置と、
絶対的な配置がある。また、2 つのコンビネーションを使用する場合がある。
・相対的な配置
相対的な配置では、たとえばオブジェクト・クラス用語の前に修飾語が現れる場
合があることも認める。
・絶対的な配置
絶対的な配置は、固定的な配置を前提とする。たとえば、プロパティ用語は常に
名前の最後の部分であることを要求する。
語彙の法則
語彙の法則は、好ましい用語および好ましくない用語、同意語、略語、長さ、ス
ペル、許容可能な文字のセットなどを取り決めることである。
命名協定の XML への適用
今までの規則を XML へのデータ項目名へ適用することは容易である。
例：XML タグのデータエレメント名のためのネーミング協定
これらの規則はすでに記述されたガイドラインによる。サンプルも示す。XML 特定
の語彙の制限によってのみ記述された規則と異なる。
1) 意味的ルール
a.
オブジェクト・クラスは、論議域に興味のあるものを表し、たとえば、その
一般的モデルで見つかる場合がある。
[例]
原価
b.
1 個のオブジェクト・クラス用語は必ず存在しなければならない。
c.
プロパティ用語はプロパティシステム構造のセットに由来しなければならな
い。また、データのカテゴリーを表わさなければならない。
［例］
合計額
d.
1 個のプロパティ用語必ず存在しなければならない。
e.
サブジェクト・エリアで決定され、データ・エレメントについて記述され、
かつ指定されたコンテキストをユニークにでするために、修飾語は付け加え
られる。修飾語の順序は重要ではない。修飾語はオプションである。
［例］
予算期間
56
f.
データ・エレメントの有効な値セットの表現はリプレゼンテーション用語で
記述される。
g.
1 個のリプレゼンテーション用語は必ず存在しなければならない。
［例］
金額
2）シンタックス・ルール
a.
オブジェクト・クラス用語は名前の中で 1 番目（左端）に位置されなけれ
ばならない。
b.
修飾語は修飾される部分に先行しなければならない。修飾語の順序はデー
タ・エレメント名を区別するために使用されなくてはならない。
c.
プロパティ用語はその次に位置されなければならない。
d.
リプレゼンテーション用語は最後に位置されなければならない。リプレゼ
ンテーション用語の単語がプロ p ティ用語の任意の単語として余分の場合、
その発生は削除される。
［例］
原価予算期間合計金額
3）語彙のルール
a.
名詞は単数形のみで使用される。動詞（もしあれば）は現在時制である。
b.
名前のパートおよび複数単語の用語は下線（underscore）によって分離され
る。スペースまたは特殊文字は許可されない。
c.
名前の用語はすべて大文字を使用する。注:XML 名はケースに敏感である。1
つのケースに名前を制限することは可能な混乱を最小限にする。
d.
省略語、頭文字およびイニシャルは許される。
e.
言葉は文字および数だけが許される。
［例］
COST_BUDGET_PERIOD_TOTAL_AMOUNT
4）ユニーク性のルール
すべての名前は DTD 内部でユニークでなくてはならない。
5）使用例
この例において、データ・エレメント名は XML 要素タグの中で使用される。省略
語形が適用されている。
< !ELEMENT COST_BUDGET_PD_TOTAL_AMT (#PCDATA) >
（2） ISO/IEC 11179-5 の日本語への適用とその問題点
57
11179-5 では、用語をオブジェクト・クラス用語、プロパティ用語、リプレゼンテ
ーション用語、修飾用語に分類し、その基本構造はオブジェクト・クラス用語、プロ
パティ用語、リプレゼンテーション用語の順となる。
オブジェクト・クラス用語は、データ要素において、その活動あるいはオブジェク
トを表現したものである。オブジェクト・クラス用語は、エンティティ名（クラス名）
を写像する場合が多く、業務の概念、アクティビティなどを表現する。したがって、
その多くは西洋語を下にした和製漢語で表現される場合が多い。この用語はエンティ
ティ（クラス）の主体を表現する。
修飾用語は、オブジェクト・クラス用語、プロパティ用語、リプレゼンテーション
用語を修飾する形容詞的な用語である。形容詞が付く位置は、基本的に言語の分類に
関係なく被修飾語の前に付けられる場合が多いので、大きな問題とはならない。
ところが、プロパティ用語、リプレゼンテーション用語は用語上、用語の分類概念
を表現するので、問題が発生する。「英語は一つ一つの単語が独自のつづりを持つ」
のに対し、漢語は、ひとつの文字で意味を持ち、一音節なのだが、これが二つ集まっ
て安定する。日本語で言う「熟語」となって安定する。したがって、二音（二文字）
の組み合わせ語が非常に多くなる。
かつ、分類上の概念が違っているので、この部分を完全に適用するのは困難になる。
リプレゼンテーション用語では、先に説明した概念的相違が大きな問題となってくる。
例えば、額は、一定の金額を示すものである。
リプレゼンテーション用語「Amount」は、「a quantity or degree of something,
considered as a unit or total. 何かの量か度合い、1 つの単位あるいは合計と見なされ
るもの」であろう。
例えば、これを「金額」とした場合、日本語の解釈では、「具体的な数字によって
示される金銭の量」であり、これを ebXML の定義のように「通貨単位を用いて金額
を指定する」とすれば、ほぼ英語の解釈と一致する。
「数」、「Measure」、「Quantity」の場合は前述したようにさらに複雑である。
その根本の要因は、「単語」の考え方が西洋の言語と漢語とで基本的に違うところ
にある。
4.5.3 結論
漢語を基本的に使用した場合、プロパティ用語、リプレゼンテーション用語が明確
に分離できる場合もあれば、熟語として分離できない場合も漢語では発生してくるの
である。
漢語（漢字）を使用する場合には、この用語の分類を基本的には保持しながら熟語
の場合にはリプレゼンテーション用語の概念を省略するという形態を取らざるをえな
い。
このことは、11179-5 の本文で言う、
「Note that Last Name is a property term. One
occurrence of the redundant word Name is removed to promote clarity.」とはまっ
58
たく異なる概念である。
このような考え方をもとに、ISO/IEC 11179-5 に対する日本語および漢語の命名に
ついてさらに検討を深める必要がある。
以上
59
5.
今後の課題
本委員会は本年度をもって終了するが、今後の主な課題と作業内容は次のようなもので
ある。これらの課題は関連する委員会に引継いで推進されることを望む。
5.1
SC32 NWI の推進
平成 14 年 5 月のソウル会議から始まる NWI プロジェクトのエディタとして、既に予定
される中国からの提案や OMG にける MOF 拡張（MOF2.0 ）などとの整合性確保の調整
と作業を進める必要がある。
5.2
JIS 化の推進
（1）IS11179-の JIS 化
本年度、第 1 部と第 2 部に関する JIS 原案を作成した。今後、SC32 で規格改定の進
捗をにらみながら、他の部分についても引き続き JIS 化を進める必要がある。
（2）MOF/XMI の TR 化
NWI 提案のベースとなっているだけでなく、広く普及しつつある MOF/XMI につい
て、JIS 化の一環として、TR（技術報告）化を進める必要がある。
（3）IS6523 の JIS 化
本年度、その必要性を吟味した企業識別コード（IS6523）について、H14 年度は JIS
化を進める必要がある。
（4）情報要素関係規格における国際規格と JIS の対応実態調査
コード類など、情報共有の基礎となる情報要素規格で、ISO にありながら JIS にな
いような規格の実体を明らかにする必要がある。
5.3 MOF 拡張における OMG と ISO 連携の推進
OMG では、MOF 拡張作業を SC32 の NWI 推進と歩調をあわせて進めることを公表
している。本委員会のメンバが中心となって、その仲介作業を行う必要がある。
5.4 UN/CEFACT
TMWG、EBWG への参画と貢献
EC 関係の標準化は、UN/CEFACT と OASIS に統合されつつある。ECOM が窓口と
なっている TMWG 作業や EBWG 作業への参画は、SC32
NWI プロジェクトの推
進やその成果の活用のためにも不可欠である。本年度に引き続き積極的に関与しなが
ら貢献を行う必要がある。TMWG が策定中の方法論 UMM については、将来、JIS
化（TR 化）も視野にいれる必要がある。
以上
60

Download Report