(57)【要約】【課題】ソースモデルの更新によるターゲットモデルの変更とターゲットモデル独自の変更とを効率よくマージできるようにする。【解決手段】モデル編集装置１０において、モデル変換機能１１は、ＳＭ（ソースモデル）０をＴＭ（ターゲットモデル）０に変換し、ＴＤＭ（変更依存モデル）０を生成する。また、ＳＭ編集者がＳＭ０を更新してＳＭ１を生成すると、モデル変換機能１１は、ＳＭ１をＴＭ１に変換し、ＴＤＭ１を生成する。これとは別にＴＭ編集者がＴＭ０を編集してＴＭ０＿ｎを生成すると、Change要素登録機能１２が、ＴＭ０とＴＭ０＿ｎの差分Δ２をＴＤＭ０に登録してＴＤＭ０＿ｎを生成する。その後、マージ機能１３は、呼び出しに応じて、Δ１抽出機能１４が抽出したＴＤＭ０とＴＤＭ１の差分Δ１と、ＴＤＭ０＿ｎから抽出したΔ２とを、予め記憶された処理パターンに基づいてマージする。【選択図】図７
2008269136.tif 000002
【特許請求の範囲】
【請求項１】
モデル駆動型開発を支援する装置であって、
前記モデル駆動型開発においてソースモデルから生成されたターゲットモデルの変更のうち、当該ソースモデルの更新に起因する変更である第１の変更に関する第１の変更情報を取得する第１の取得部と、
前記ターゲットモデルの変更のうち、前記ソースモデルの前記更新に起因しない変更である第２の変更に関する第２の変更情報を取得する第２の取得部と、
前記第１の変更情報と前記第２の変更情報とを、予め記憶された前記第１の変更及び前記第２の変更の優先度に関する情報に基づいてマージするマージ部と
を備えた、装置。
【請求項２】
前記ソースモデルの更新前における前記ソースモデルの要素と前記ターゲットモデルの要素との対応関係を示す第１の構造化文書と、前記ソースモデルの更新後における当該対応関係を示す第２の構造化文書とを記憶する記憶部を更に備え、
前記第１の取得部は、前記第１の構造化文書と前記第２の構造化文書との差分を前記第１の変更情報として取得する、請求項１の装置。
【請求項３】
前記ソースモデルを構成する第１の要素と、前記ターゲットモデルを構成する第２の要素と、当該第２の要素の変更を示す第３の要素との対応情報を記憶する記憶部を更に備え、
前記第２の取得部は、前記対応情報から前記第３の要素を抽出することにより、前記第２の変更情報を取得する、請求項１の装置。
【請求項４】
前記優先度に関する情報は、マージの際に前記第１の変更が前記第２の変更よりも優先されるための条件を含む、請求項１の装置。
【請求項５】
前記優先度に関する情報は、マージの際に前記第１の変更が前記第２の変更よりも優先されるかどうかをユーザに問い合わせる旨の情報を含む、請求項１の装置。
【請求項６】
前記優先度に関する情報は、マージ処理に関する複数の規則を含み、当該複数の規則の各々は、識別子によって特定される、請求項１の装置。
【請求項７】
前記ターゲットモデルを構成する要素と前記識別子との対応情報を記憶する記憶部を更に備え、
前記マージ部は、前記第１の変更情報のうち前記要素の変更に関する変更情報と、前記第２の変更情報のうち前記要素の変更に関する変更情報とを、前記識別子によって特定される規則を用いてマージする、請求項６の装置。
【請求項８】
モデル駆動型開発を支援する方法であって、
第１のソースモデルを第１のターゲットモデルに変換するステップと、
前記第１のソースモデルの更新を行うことにより第２のソースモデルを生成するステップと、
前記第２のソースモデルを第２のターゲットモデルに変換するステップと、
前記第１のソースモデルの前記更新とは無関係に前記第１のターゲットモデルに変更を加えることにより第３のターゲットモデルを生成するステップと、
前記第１のターゲットモデルから前記第２のターゲットモデルへの変更である第１の変更に関する第１の変更情報と、前記第１のターゲットモデルから前記第３のターゲットモデルへの変更である第２の変更に関する第２の変更情報とを、予め記憶された当該第１の変更及び当該第２の変更の優先度に関する情報に基づいてマージするステップと
を含む、方法。
【請求項９】
前記優先度に関する情報は、マージの際に前記第１の変更が前記第２の変更よりも優先されるための条件を含む、請求項８の方法。
【請求項１０】
モデル駆動型開発を支援する装置としてコンピュータを機能させるプログラムであって、
前記コンピュータを、
前記モデル駆動型開発においてソースモデルから生成されたターゲットモデルの変更のうち、当該ソースモデルの更新に起因する変更である第１の変更に関する第１の変更情報を取得する第１の取得部と、
前記ターゲットモデルの変更のうち、前記ソースモデルの前記更新に起因しない変更である第２の変更に関する第２の変更情報を取得する第２の取得部と、
前記第１の変更情報と前記第２の変更情報とを、予め記憶された前記第１の変更及び前記第２の変更の優先度に関する情報に基づいてマージするマージ部と
して機能させる、プログラム。
【請求項１１】
前記優先度に関する情報は、マージの際に前記第１の変更が前記第２の変更よりも優先されるための条件を含む、請求項１０のプログラム。
【請求項１２】
前記優先度に関する情報は、マージの際に前記第１の変更が前記第２の変更よりも優先されるかどうかをユーザに問い合わせる旨の情報を含む、請求項１０のプログラム。
【請求項１３】
前記優先度に関する情報は、マージ処理に関する複数の規則を含み、当該複数の規則の各々は、識別子によって特定される、請求項１０のプログラム。
【請求項１４】
前記マージ部は、前記ターゲットモデルを構成する要素と前記識別子との対応情報を所定の記憶部から読み出し、前記第１の変更情報のうち当該要素の変更に関する変更情報と、前記第２の変更情報のうち当該要素の変更に関する変更情報とを、当該識別子によって特定される規則を用いてマージする、請求項１３のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、モデル駆動型開発を支援する装置及び方法に関する。特に、本発明は、モデル駆動型開発におけるモデルの変更をマージする装置及び方法に関する。
【背景技術】
【０００２】
複数の開発者が同じアプリケーションの開発に関わるコラボレーション開発環境では、各開発者が行った変更によるアプリケーションの差分をマージすることが重要になる。従来、このようなマージは、ＣＶＳ（Concurrent Versions System）やＲａｔｉｏｎａｌ（登録商標）等のツールにおけるソースコード間の差分を抽出する機能を用いて行われていた。
【０００３】
また、昨今、アプリケーション開発をスムーズに進めるため、アプリケーションの設計図であるモデルを記述するモデリングという作業が行われるようになっている。このモデリングを行うためのモデリング言語の代表的なものにＵＭＬ（Unified Modeling Language）がある。ＵＭＬは、ＯＭＧ（Object Management Group）によって標準化され、オブジェクト指向のアプリケーション開発におけるデファクトスタンダードとも言えるモデリング言語である。ＵＭＬでは、アプリケーションの流れや機能がダイヤグラムによって表現されるので、視覚的に分かり易いモデルが得られる。
【０００４】
従来、各作業者が直接編集した２つ又は３つのＵＭＬモデル間の差分を抽出することは行われている（例えば、非特許文献１参照）。この非特許文献１では、Eclipse compare supportツールを用いて差分を抽出している。
また、編集対象となるモデル及びそのモデルを所定の形式で表示するためのビューモデルを用いて対話的にアプリケーションソフトを作成するモデル編集システムにおいて、モデルの構造が変化した場合に効率的にビューモデルとモデル間の同期を取ることを可能とする技術も知られている（例えば、特許文献１参照）。
【０００５】
【非特許文献１】Kim Letkeman、“Comparing and merging UML models in IBM Rational Software Architect”、［online］、平成１７年７月１２日、［平成１９年４月９日検索］、インターネット＜URL：http://www-128.ibm.com/developerworks/rational/library/05/712_comp/＞及び＜URL：http://www-128.ibm.com/developerworks/rational/library/05/712_comp2/＞
【特許文献１】特開２００６−２６８７６４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ところで、近年のアプリケーション開発では、開発期間の短縮及び開発コストの低減が多くの開発者にとっての課題である。そこで、ＯＭＧは、モデルを中心にアプリケーションの開発を進めていくモデル駆動型アーキテクチャを提供している。このモデル駆動型アーキテクチャは、複数のモデリング環境におけるモデルをモデル変換によって連携可能とするアーキテクチャであり、ＣＩＭ（Computational Independent Model）、ＰＩＭ（Platform Independent Model）、ＰＳＭ（Platform Specific Model）の３層の論理的なモデルから構成される。ここで、ＣＩＭは、コンピュータ上での動作を意識しないモデルであり、例えば、ビジネスプロセス等である。ＰＩＭは、プラットフォームとは独立したモデルである。そして、ＰＳＭは、プラットフォームに特化したモデルであり、例えば、Ｊ２ＥＥ（Java 2 Enterprise Edition）のモデルである（Ｊａｖａ及びその他のＪａｖａを含む商標は、米国Sun Microsystems, Inc.の米国及びその他の国における登録商標又は商標）。このようなモデル駆動型アーキテクチャを用いたモデル駆動型開発により、抽象度の高いモデルから実装コードまでを全自動的又は半自動的に変換する仕組みが得られる。これにより、開発工数を削減でき、異なる環境やプラットフォームへ容易に移植できるようにもなる。
【０００７】
しかしながら、実際にモデル駆動型開発を行う場合、上位層で定義されたモデルは、必ず変更されるものとして捉える必要がある。加えて、下位層で定義されるモデルに対しても、上位層での変更とは関係なく、カスタマイズ等がなされるものである。
即ち、ある時点でモデル変換を行うと、生成元のモデル（ソースモデル）の更新による差分のインパクトが、生成先のモデル（ターゲットモデル）に対して与えられる。例えば、ＰＩＭレベルでの変更要求に基づく１つのモデル要素の追加が、その追加以前に自動生成されたＰＳＭレベルのコードに如何なるインパクトを及ぼすかを考える。モデル駆動型アーキテクチャには、上位モデルの情報を下位モデルへなるべく「仕様」として伝達するという特徴がある。従って、上位モデルの１つの変更により、下位モデルにおいて多くのインパクトが発生することもある。
また、既にモデル変換によって生成されたモデル及びコードに対して、各レベル（ＰＩＭ、ＰＳＭ）での変更要求等による編集がなされることもある。
このような場合に、上位モデルからのインパクトと下位モデルでの編集とをどのようにマージするかが問題となる。
【０００８】
モデル駆動型開発におけるモデル変換は、ターゲットモデルの初版を生成するという意味では有効である。しかしながら、実際のアプリケーション開発にモデル駆動型開発を適用した場合、度重なる変更要求に基づいた多くの変更を管理する手法が未だ整備されていないのが現状である。そのため、モデル駆動型開発を用いない場合に比べ、かえって全体のコストがかかってしまうことも多い。
【０００９】
ここで問題としているのは、上位モデルの変更と下位モデルの変更が独立に行われる状況である。ところが、非特許文献１の技術は、このような状況を前提としたものではない。
また、特許文献１の発明は、ビューモデルとモデル間の同期を取ることを主眼としており、上記問題を解決することはできない。
【００１０】
本発明の目的は、ソースモデルの更新によるターゲットモデルの変更とターゲットモデル独自の変更とを効率よくマージできるようにすることにある。
【課題を解決するための手段】
【００１１】
かかる目的のもと、本発明は、ソースモデルの更新によるターゲットモデルの変更とターゲットモデル独自の変更とを両者の優先度に基づいてマージするようにした。即ち、本発明の装置は、モデル駆動型開発を支援する装置であって、モデル駆動型開発においてソースモデルから生成されたターゲットモデルの変更のうち、ソースモデルの更新に起因する変更である第１の変更に関する第１の変更情報を取得する第１の取得部と、ターゲットモデルの変更のうち、ソースモデルの更新に起因しない変更である第２の変更に関する第２の変更情報を取得する第２の取得部と、第１の変更情報と第２の変更情報とを、予め記憶された第１の変更及び第２の変更の優先度に関する情報に基づいてマージするマージ部とを備えた、装置を提供する。
【００１２】
また、この装置は、ソースモデルの更新前におけるソースモデルの要素とターゲットモデルの要素との対応関係を示す第１の構造化文書と、ソースモデルの更新後におけるその対応関係を示す第２の構造化文書とを記憶する記憶部を更に備え、第１の取得部は、第１の構造化文書と第２の構造化文書との差分を第１の変更情報として取得する、ものであってもよい。
更に、この装置は、ソースモデルを構成する第１の要素と、ターゲットモデルを構成する第２の要素と、第２の要素の変更を示す第３の要素との対応情報を記憶する記憶部を更に備え、第２の取得部は、対応情報から第３の要素を抽出することにより、第２の変更情報を取得する、ものであってもよい。
更にまた、優先度に関する情報は、マージの際に第１の変更が第２の変更よりも優先されるための条件を含むものでもよいし、マージの際に第１の変更が第２の変更よりも優先されるかどうかをユーザに問い合わせる旨の情報を含むものでもよい。
【００１３】
加えて、優先度に関する情報は、マージ処理に関する複数の規則を含み、その複数の規則の各々は、識別子によって特定される、ものでもよく、この場合、この装置は、ターゲットモデルを構成する要素と識別子との対応情報を記憶する記憶部を更に備え、マージ部は、第１の変更情報のうち要素の変更に関する変更情報と、第２の変更情報のうち要素の変更に関する変更情報とを、識別子によって特定される規則を用いてマージする、ものであってもよい。
【００１４】
また、本発明は、モデル駆動型開発を支援する方法であって、第１のソースモデルを第１のターゲットモデルに変換するステップと、第１のソースモデルの更新を行うことにより第２のソースモデルを生成するステップと、第２のソースモデルを第２のターゲットモデルに変換するステップと、第１のソースモデルの更新とは無関係に第１のターゲットモデルに変更を加えることにより第３のターゲットモデルを生成するステップと、第１のターゲットモデルから第２のターゲットモデルへの変更である第１の変更に関する第１の変更情報と、第１のターゲットモデルから第３のターゲットモデルへの変更である第２の変更に関する第２の変更情報とを、予め記憶された第１の変更及び第２の変更の優先度に関する情報に基づいてマージするステップとを含む、方法も提供する。
【００１５】
更に、本発明は、モデル駆動型開発を支援する装置としてコンピュータを機能させるプログラムであって、コンピュータを、モデル駆動型開発においてソースモデルから生成されたターゲットモデルの変更のうち、ソースモデルの更新に起因する変更である第１の変更に関する第１の変更情報を取得する第１の取得部と、ターゲットモデルの変更のうち、ソースモデルの更新に起因しない変更である第２の変更に関する第２の変更情報を取得する第２の取得部と、第１の変更情報と第２の変更情報とを、予め記憶された第１の変更及び第２の変更の優先度に関する情報に基づいてマージするマージ部として機能させる、プログラムも提供する。
【発明の効果】
【００１６】
本発明によれば、ソースモデルの更新によるターゲットモデルの変更とターゲットモデル独自の変更とを効率よくマージできるようになる。
【発明を実施するための最良の形態】
【００１７】
以下、添付図面を参照して、本発明を実施するための最良の形態(以下、「実施の形態」という）について詳細に説明する。
図１は、モデル変換の入力となるソースモデルと、モデル変換の出力となるターゲットモデルと、各モデルの変更及びマージの処理について示した図である。初回のモデル変換に関しては、ソースモデルをＳＭ０、ターゲットモデルをＴＭ０と表記する。また、ソースモデルの編集作業を行う担当者（以下、「ＳＭ編集者」という）がＳＭ０を変更することで得られたソースモデルをＳＭ１、ＳＭ１をモデル変換することで得られたターゲットモデルをＴＭ１と表記する。更に、ターゲットモデルの編集作業を行う担当者（以下、「ＴＭ編集者」という）によるＴＭ０のｎ回目の変更によってＴＭ０＿ｎが得られるものとする。
【００１８】
ところで、ＴＭ１とＴＭ０＿ｎとから最新版のターゲットモデルであるＴＭ０１を生成するためには、ＳＭ編集者による変更に基づくターゲットモデルの変更とＴＭ編集者によるターゲットモデルの変更とをマージする必要がある。
本明細書では、前者の変更によって生じたターゲットモデルの初版からの差分をΔ１と表記し、後者の変更によって生じたターゲットモデルの初版からの差分をΔ２と表記する。図１では、ＴＭ０とＴＭ１の差分がΔ１に相当し、ＴＭ０とＴＭ０＿ｎの差分がΔ２に相当する。
【００１９】
ここで、ソースモデル及びターゲットモデルは、ソースモデルがターゲットモデルより上位であれば、モデル駆動型アーキテクチャにおける如何なるレベルのモデルであってもよいが、ターゲットモデルとしてソースコードを例にとり、Δ１及びΔ２について説明する。
図２−１にＴＭ０の例を示し、図２−２にＴＭ１の例を示し、図２−３にＴＭ０＿１の例を示す。
即ち、図２−１のソースコードの元となるモデルをＳＭ編集者が変更することによって新たに生成されたソースコードが、図２−２のソースコードである。図２−２では、メソッド１０１及び１０２内で、下線を施したような変更が加えられている。この場合、これらのメソッド１０１及び１０２がΔ１に相当する。
また、図２−１のソースコードのＴＭ編集者による１回目の編集で得られたソースコードが、図２−３のソースコードである。図２−３では、メソッド１０３及び１０４内で、下線を施したような変更が加えられている。この場合、これらのメソッド１０３及び１０４がΔ２に相当する。
【００２０】
尚、既存のＣＶＳやEclipse comparing supportツール等を用いてソースコードの差分を抽出することはできるが、そこには、ソースモデルの変更に基づく差分であるΔ１と、ターゲットモデルのレベルでの差分であるΔ２とが混在している。そこで、本実施の形態では、Δ１とΔ２とを区別して扱い、それらのマージを容易にかつ誤りなく行う。
具体的には、モデル駆動型開発において、変換依存モデル（以下、「ＴＤＭ」という）を生成し、これを用いてΔ１及びΔ２を抽出しマージする。
まず、ＴＤＭの生成について説明する。
図３は、モデル変換におけるＴＤＭの位置付けを例示した図である。ＴＤＭは、例えば、モデル変換ツール等に付随するＴＤＭ生成機能によって生成すればよい。図では、ＳＭ０からＴＭ０へモデル変換を行う際に、このモデル変換に対応するＴＤＭであるＴＤＭ０が生成される様子を示している。
【００２１】
ここで、ＴＤＭは、ソースモデルからターゲットモデルへのモデル変換におけるモデル要素単位のマッピング情報を持つ。モデル変換では、ソースモデルに含まれるモデル要素を変数として生成テンプレートに当てはめることで、ターゲットモデルが生成される。ＴＤＭで扱うマッピング情報は、このソースモデルのモデル要素がターゲットモデルのどのモデル要素に関係しているかを指す。
【００２２】
図４に、ＴＤＭのメタモデルを示す。ＴＤＭは、モデル変換における汎用的な構造となっている。
以下、ＴＤＭのメタモデルにおける各要素及び属性について説明する。
+DependencyModel
この要素は、ＴＤＭのルート要素である。通常、モデル変換を用いて開発されるシステムに関して１つのモデルインスタンスを持つ。もしくはモデル変換の対象がサブシステムに分割できる場合は、複数のモデルインスタンスを持つこともできる。
また、この要素は、次の属性を持つ。
-creationDate：ＴＤＭが生成された日付（モデル変換が最初に行われた日付）。
-modificationDate：ＴＤＭが最後に変更された日付。
-id：この要素が複数ある場合等に各要素を識別するために用いられるＩＤ。
【００２３】
+DependencyGroup
この要素は、ソースモデルに含まれる各モデル要素とターゲットモデルに含まれる各モデル要素のマッピングに関する変換の集合を示す。通常、モデル変換は、ソースモデルの一部の情報をテンプレートに当てはめてターゲットモデルのリソースを生成することにより行われる。例えば、ターゲットモデルがＪ２ＥＥのソースコードである場合、ＤＤＬ（Data Definition Language）、ＪＳＰ（JavaServer Pages）、Ｊａｖａのソースコード等が、それぞれテンプレートを使って生成される。ここで、例えば、複数生成されるＪＳＰファイルは、プログラムモデルの意図によってファイル内部の表現構造が異なる。但し、同じテンプレートから生成されたＪＳＰファイルは同じ形式の内部構造を持つ。そこで、同じテンプレートを用いるモデル要素の変換の集合という意味で、この要素が設けられている。
また、この要素は、次の属性を持つ。
-resourceType：ファイルリソースの種類（ＪＳＰ、Ｊａｖａのソースコード、ＤＤＬ、Ｐｒｏｐｅｒｔｙファイル等）。
-id：この要素が複数ある場合等に各要素を識別するために用いられるＩＤ。
【００２４】
+Dependency
この要素は、ソースモデルとターゲットモデルの間のモデル変換に関するファイル単位の依存関係を示す。即ち、テンプレートから生成される個々のファイル単位の依存関係である。
また、この要素は、次の属性を持つ。
-filePath：ファイルシステム上のファイル名を含むパス。
-id：この要素が複数ある場合等に各要素を識別するために用いられるＩＤ。
【００２５】
+Mapping
この要素は、Dependency要素で指定されたファイルに関し、ソースモデルとターゲットモデルをソースモデルのモデル要素単位で関連付けるマッピングを示す。子要素であるSourceModelPath要素及びTargetModelPath要素で指定されるパス間が、依存関係として関連付けられる。例えば、図２−２〜３のメソッド１０１〜１０４のレベルでのマッピングが行われる。また、この依存関係に対しＴＭ編集者によってなされた変更をChange要素によって保持することができるようになっている。
また、この要素は、次の属性を持つ。
-value：ソースモデルとターゲットモデルで変換に使われているモデル要素の値。
-id：この要素が複数ある場合等に各要素を識別するために用いられるＩＤ。
-strengthType：依存強度（以下を参照）。
依存強度は、マージの際にΔ１とΔ２が競合した場合、Δ１がどの程度優先されるかの強度である。この依存強度は、予め定められた規則に従ってモデル変換時にシステムが設定してもよいし、モデル変換後にＴＭ編集者等が設定してもよい。また、依存強度には、以下の４つのタイプがある。
・依存強度Ｈ（Ｈｉｇｈ）
このタイプは、Δ１がΔ２よりも必ず優先されるタイプである。
・依存強度Ｍ（Ｍｅｄｉｕｍ）
このタイプは、モデル要素が変更されていれば、Δ１がΔ２よりも優先され、モデル要素の子要素が変更されていれば、Δ２がΔ１よりも優先されるタイプである。
・依存強度Ｌ（ｌｏｗ）
このタイプは、Δ２がΔ１よりも必ず優先されるタイプである。
・依存強度Ｎ（Ｎｏｎｅ）
このタイプは、依存強度が不明であり、Δ１とΔ２の競合を解消するためにＴＭ編集者の判断を必要とするタイプである。
【００２６】
+SourceModelPath
この要素は、ソースモデル内のモデル要素の絶対パスを示す。
また、この要素は、次の属性を持つ。
-id：この要素が複数ある場合等に各要素を識別するために用いられるＩＤ。
-path：ソースモデル内のマッピング対象となるモデル要素を指定するパス（ＸＰａｔｈ、Ｊａｖａの要素パス等）。
【００２７】
+TargetModelPath
この要素は、ターゲットモデル内のモデル要素の絶対パスを示す。ターゲットモデルにおいて、マッピング対象のモデル要素の値に対してprefixとsuffixが存在すれば、これらを定義することも可能である。
また、この要素は、次の属性を持つ。
-id：この要素が複数ある場合等に各要素を識別するために用いられるＩＤ。
-path：ターゲットモデル内のマッピングの対象となるモデル要素を指定するパス（ＸＰａｔｈ、Ｊａｖａの要素パス等）。
-suffix：モデル変換によってMapping要素のvalue属性の値に付されたsuffix。
-prefix：モデル変換によってMapping要素のvalue属性の値に付されたprefix。
-scope：スコープ（以下を参照）。
スコープは、ソースモデルのモデル要素がターゲットモデルへどのようなスコープで変換されているか、という観点から、マッピングの関係を示す。スコープとしては次のいずれかのタイプを指定可能である。
・“elementOnly”：ターゲットモデル内のあるモデル要素のみを示す。
・“includeChildren”：ターゲットモデル内のあるモデル要素とその子要素を示す。
ＸＰａｔｈによって、上記２つのタイプの指定が可能となる。また、ターゲットモデルがＪａｖａの場合でも、Ｊａｖａの言語構造により、クラス、メソッド、宣言等はＸＭＬで表現できる。従って、ＸＰａｔｈによる表現が可能となるので、この指定は可能である。
【００２８】
+Change
この要素は、ＴＭ編集者によるマッピング関係の変更（Δ２）を記録する。通常は、ＣＶＳやＳｕｂｖｅｒｓｉｏｎ等のツール上で変更が記録され、ＴＤＭのマッピングに関係するかがチェックされた後、この要素が追加される。
また、この要素は、次の属性を持つ。
-changedType：変更のタイプ（“Update”又は“Delete”）。
-changedParamType：変更のタイプが“Update”の場合の変更後のパラメータの種類（TargetModelPath要素のscope属性の変更等）。
-changedParamValue：変更のタイプが“Update”の場合の変更後の値。
-changedDateTime：変更の日時。
【００２９】
+InputModels
この要素は、モデル変換における入力及び出力となるモデルを、ＴＤＭの視点での入力モデルとして示す。ここでは、ソースモデルとターゲットモデルが入力モデルとなる。
また、この要素は、次の属性を持つ。
-transformationType：利用されているモデル変換ツールの種類。
【００３０】
+TargetModel
この要素は、モデル変換における出力となるターゲットモデルを示す。
また、この要素は、次の属性を持つ。
-modelType：モデルの種類（例えば、ＸＭＬ、Ｊａｖａ、ＪＳＰ）。
-filePath：ファイルシステムにおけるターゲットモデルのファイルパス。
【００３１】
+SourceModel
この要素は、モデル変換における入力となるソースモデルを示す。
また、この要素は、次の属性を持つ。
-modelType：モデルの種類（例えば、ＸＭＬ、Ｊａｖａ、ＪＳＰ）。
-filePath：ファイルシステムにおけるソースモデルのファイルパス。
【００３２】
ここまでＴＤＭのメタモデルについて説明してきたが、次に、ＴＤＭの具体的な記述例を示す。
図５は、Ｊ２ＥＥアプリケーション等を対象とするＴＤＭの記述例である。この例は、ＴＤＭの部分的な例であるので、ターゲットモデルはＪａｖａファイルのみとなっているが、通常は、ｆａｃｅｓ−ｃｏｎｆｉｇ．ｘｍｌ等の設定ファイルや、ＪＳＰファイルもターゲットモデルとなる。
また、パスの指定には、ＵＭＬモデル等のＸＭＬで表現できるリソース（図５では、ソースモデル）については、標準化団体Ｗ３Ｃが提供しているＸＰａｔｈを用いている。また、Ｊａｖａファイル（図５では、ターゲットモデル）については、“{Class}#{Method}.{Field}”等の木構造を指す表記が使用可能である。ＪＳＰやＨＴＭＬに関しても木構造として同様な記述方法で示すことができる。
【００３３】
ところで、このＴＤＭの記述例において、マッピング対象のモデル要素は、“Ａｓｓｕｍｐｔｉｏｎ”と“ＩｔｅｍＡ”の２つである。このうち、“Ａｓｓｕｍｐｔｉｏｎ”は、依存強度Ｈが指定されているので、マージの際にΔ１がΔ２よりも優先されるようになっている。また、“ＩｔｅｍＡ”は、依存強度Ｌが指定されているので、マージの際にΔ２がΔ１よりも優先されるようになっている。
【００３４】
次に、ＴＤＭに対するΔ２の記録について説明する。
図６は、Change要素登録機能の振る舞いを例示した図である。初期状態においては、ＴＭ０と、ＴＭ０が生成される際に生成されたＴＤＭ０とが存在している。この状態で、（１）に示すように、ＴＭ０がＴＭ編集者によって変更され、ＴＭ０＿ｎが生成されたとする。すると、（２）に示すように、Change要素登録機能が呼び出される。そして、（３）に示すように、初期状態と最新状態との差分を抽出し、これがＴＤＭのマッピングに関連がある変更かどうかを判断して、Change要素を作成し追加する。
以上により、Δ２が自動抽出できるようになる。
【００３５】
次いで、ソースモデルの変更後のモデル変換によって生じるターゲットモデルの差分Δ１と、上記Δ２との競合の解決について詳細に説明する。
まず、図３に示したＴＤＭ生成機能を含むモデル変換機能と、図６に示したChange要素登録機能とを含むモデル編集装置１０を用いたＴＭ編集者によるマージ作業の流れについて述べる。図７は、このようなマージ作業の流れを示した図である。尚、図において、実線は、モデル変換時における変更管理のためのイベントの流れを示す。破線は、イベント以外の関連を示す。
まず、モデル編集装置１０には、ＴＭ０及びＴＤＭ０が保持されると共に、ＴＭ編集者の作業によってＴＭ０の最新版であるＴＭ０＿ｎが生成されているものとする。また、Change要素登録機能１２が、ＴＭ０とＴＭ０＿ｎの差分Δ２を常時抽出し、ＴＤＭ０に登録することでＴＤＭ０＿ｎを生成しているものとする。
【００３６】
このような状況で、ＳＭ編集者は、ソースモデルをＳＭ０からＳＭ１に変更すると、（１）に示すように、ＴＭ編集者にその旨を通知する。この通知を受けると、ＴＭ編集者は、（２）に示すように、モデル変換機能１１を呼び出し、ＳＭ１をこれに受け渡す。これにより、モデル変換機能１１は、ＳＭ１をＴＭ１に変換し、その際、ＴＤＭ１を生成する。次に、ＴＭ編集者は、ＴＭ０とＴＭ１の差分Δ１と、ＴＭ０とＴＭ０＿ｎの差分Δ２とをマージするため、（３）に示すように、マージ機能１３を呼び出す。これにより、マージ機能１３は、Δ１抽出機能１４を呼び出し、Δ１抽出機能１４は、ＴＤＭ０とＴＤＭ１からΔ１を抽出してマージ機能１３に伝える。その後、マージ機能１３は、後述する処理により、マージした結果であるＴＭ０１と、マージの記録であるマージログとを生成する。
そして、以上の処理の終了後、ＴＭ編集者は、マージログ及びＴＭ０１を見ながら、結果を確認する。もし依存強度がＮとなっていてＴＭ編集者によるマージ作業が必要である場合には、マージログの記述からＴＭ０１を修正していく。
【００３７】
次に、図７に示したモデル編集装置１０の機能及び動作について詳細に説明する。
まず、Change要素登録機能１２の動作について説明する。尚、この動作説明においては、ターゲットモデルを実装レベルのソースコードとする。
図８は、Change要素登録機能１２の動作を示したフローチャートである。
まず、Change要素登録機能１２は、ＴＭ編集者による変更前のソースコードと、ＴＭ編集者による変更後のソースコードとの差分を読み出す（ステップ２０１）。そして、差分が読み出されたかどうかを判定する（ステップ２０２）。ここで、差分が読み出されなければ、処理は終了する。差分が読み出されれば、ＴＤＭを読み込み、ＴＤＭに含まれるMapping要素の中から差分に関係するMapping要素を確認する（ステップ２０３）。即ち、差分の中には、モデル変換に関係のないものもあるので、ここでそのような差分を排除している。
【００３８】
その後、Change要素登録機能１２は、その差分がMapping要素に変更をもたらすようなものであるかどうかを判定する（ステップ２０４）。その結果、Mapping要素に変更をもたらすようなものでなければ、ステップ２０１に戻って、別の差分を読み込む。一方、Mapping要素に変更をもたらすようなものであれば、変更タイプを確認する（ステップ２０５）。
変更タイプが「更新」である場合は、更新に関する情報（Ｕｐｄａｔｅ情報）を取得し、更新を表すChange要素を生成する（ステップ２０６）。また、変更タイプが「削除」である場合は、削除に関する情報（Ｄｅｌｅｔｅ情報）を取得し、削除を表すChange要素を生成する（ステップ２０７）。そして、Change要素登録機能１２は、生成されたChange要素をＴＤＭに追加する（ステップ２０８）。
【００３９】
次に、マージ機能１３の詳細な機能構成について説明する。
図９は、マージ機能１３を独立した装置であるマージ装置３０で実現する場合のマージ装置３０の機能構成を示したブロック図である。
マージ装置３０は、ＴＤＭを記憶するＴＤＭ記憶部３１と、ＴＤＭからΔ１を取得するΔ１取得部３２と、ＴＤＭからΔ２を取得するΔ２取得部３３とを備える。また、Δ１とΔ２をマージするマージ部３４と、マージする際に参照される規則を記憶する規則記憶部３５と、マージ結果の反映対象であるターゲットモデルを記憶するターゲットモデル記憶部３６とを備える。
【００４０】
ＴＤＭ記憶部３１は、記憶部の一例であり、図４及び図５を参照して説明したＴＤＭを記憶する。例えば、ＳＭ０をＴＭ０に変換する際にＴＤＭ０が生成され、ＳＭ１をＴＭ１に変換する際にＴＤＭ１が生成されたとすると、これらの両方を記憶する。また、ＴＭ０を独自に修正してＴＭ０＿ｎを生成した場合は、ＴＭ０とＴＭ０＿ｎの差分がChange要素として登録されたＴＤＭ０＿ｎも記憶する。尚、本実施の形態では、ＴＤＭとしてＸＭＬ等の構造化文書で記述されたものを用いるが、必ずしも構造化文書でなくてもよく、その他の形式を採用してもよい。
Δ１取得部３２は、第１の取得部の一例であり、ソースモデルの変更によって生じたターゲットモデルの差分であるΔ１を取得する。このΔ１は、前述した通り、ＴＤＭ記憶部３１に記憶された旧版のＴＤＭ（例えば、ＴＤＭ０）と新版のＴＤＭ（例えば、ＴＤＭ１）とを、既存のツールを用いて比較することにより、取得することができる。尚、ＴＤＭ記憶部３１をマージ装置３０の外部に設けた場合、Δ１取得部３２は、既存のツールが抽出したΔ１を受け取る機能のみを実現するものと把握してもよい。
Δ２取得部３３は、第２の取得部の一例であり、ソースモデルの変更とは関係なくターゲットモデルに独自に加えられた変更による差分であるΔ２を取得する。このΔ２は、前述した通り、ＴＤＭ記憶部３１に記憶されたＴＤＭからChange要素を抽出することにより取得する。
【００４１】
マージ部３４は、規則記憶部３５に記憶された規則を必要に応じて参照してΔ１とΔ２をマージし、ターゲットモデル記憶部３６に記憶されたターゲットモデルに対し、マージ結果を反映させる。
規則記憶部３５は、Δ１とΔ２が競合した場合のために、Δ１とΔ２の優先度に関する情報の一例として、マージ処理に関する複数の規則を記憶している。そして、複数の規則は識別子の一例である依存強度によって特定できるようになっている。本実施の形態では、この依存強度をＴＤＭのMapping要素の属性として設定するが、ソースモデルの要素と依存強度の対応情報、又は、ターゲットモデルの要素と依存強度の対応情報をＴＤＭとは別に記憶する構成を採用してもよい。ここで、規則には、例えば、マージの際にΔ１をΔ２よりも優先させるべきかΔ２をΔ１よりも優先させるべきかといったものがある。また、どのような場合にΔ１をΔ２よりも優先させるべきでどのような場合にΔ２をΔ１よりも優先させるべきかといった条件を記憶してもよい。尚、この規則の具体例は後述する。
ターゲットモデル記憶部３６は、マージ結果が反映される前のターゲットモデルと、マージ結果を反映させたターゲットモデルとを記憶する。図７を参照して説明した例では、ＴＭ０＿ｎが前者であり、ＴＭ０１が後者である。
【００４２】
ここで、規則記憶部３５に記憶される内容について、具体的に説明する。
図１０は、Δ１とΔ２が競合した場合のマージにおける処理パターンを示している。従って、図１０の表を「処理パターン表」ともいう。図１０には、依存強度ごとに処理パターンを示している。
（ａ）は、依存強度Ｈの場合の処理パターン表である。既述の通り、依存強度Ｈでは、Δ１がΔ２よりも優先されるので、そのような優先順位に応じた処理パターンが定義されている。
（ｂ）は、依存強度Ｍの場合の処理パターン表である。既述の通り、依存強度Ｍでは、モデル要素の変更についてはΔ１がΔ２よりも優先され、その子要素の変更についてはΔ２がΔ１よりも優先されるので、そのような優先順位に応じた処理パターンが定義されている。
（ｃ）は、依存強度Ｌの場合の処理パターン表である。既述の通り、依存強度Ｌでは、Δ２がΔ１よりも優先されるので、そのような優先順位に応じた処理パターンが定義されている。
このように、依存強度Ｈ、Ｍ、Ｌについては、Δ１とΔ２の優先順位が予め決められていることになるので、依存強度の特徴を用いた自動的な処理が可能になる。
【００４３】
これに対し、（ｄ）は、依存強度Ｎの場合の処理パターン表である。既述の通り、依存強度Ｎでは、Δ１とΔ２の優先順位が不明なので、ＴＭ編集者によるマージ処理が必要となる旨が定義されている。尚、実際のモデル駆動型アーキテクチャを用いた開発では、開発の流れからデータを収集することで、なるべく依存強度Ｎの指定を減らしていくことが望ましいと言える。この場合、開発の流れからのデータの収集は、ＳＭ編集者及びＴＭ編集者が、ログ機能等を用いて出力された毎回のマージログに基づいて判断することで可能となる。
また、このように、依存強度を用いてマージを行うことにより、既存技術では不可能であったモデル駆動型開発におけるマージが可能となる。
【００４４】
次いで、マージ装置３０の動作について説明する。
図１１は、マージ装置３０の動作を示したフローチャートである。尚、ここでは、ＳＭ０がＴＭ０に変換され、ＳＭ１がＴＭ１に変換されているものとする。そして、この場合に、ＴＭ０とＴＭ１との差分であるΔ１と、ＴＭ０に対する独自の変更による差分であるΔ２とをマージすることを想定している。
まず、Δ１取得部３２は、ＴＤＭ記憶部３１からＴＤＭ０とＴＤＭ１とを読み込む（ステップ３０１）。次に、例えば、ＸＭＬ Ｄｉｆｆ等の差分抽出ツールを用いて、Δ１を１つ抽出する（ステップ３０２）。そして、Δ１が抽出されたかどうかを判定する（ステップ３０３）。ここで、Δ１が抽出されなければ、処理は終了する。Δ１が抽出されれば、Δ１取得部３２は、Δ１をマージ部３４に受け渡し、マージ部３４が、Δ１の変更タイプを抽出する（ステップ３０４）。
【００４５】
ここで、Δ１の変更タイプには、「Ａｄｄｉｔｉｏｎ」、「Ｕｐｄａｔｅ」、「Ｄｅｌｅｔｅ」がある。
そこで、マージ部３４は、まず、Δ１の変更タイプが「Ａｄｄｉｔｉｏｎ」であるかどうかを判定する（ステップ３０５）。「Ａｄｄｉｔｉｏｎ」であれば、マージ部３４は、Δ１をそのままＴＭ０（ＴＭ０＿ｎ）に追加する（ステップ３０６）。これは、モデル駆動型アーキテクチャでは、上位モデルの情報に基づいて下位モデルが生成されることから、上位モデルの変更の重要度が高いことを前提としている。その後、ステップ３０２に戻って次のΔ１の処理に移る。
また、ステップ３０５でΔ１の変更タイプが「Ａｄｄｉｔｉｏｎ」でないと判定された場合、マージ部３４は、Δ１の変更タイプが「Ｕｐｄａｔｅ」であるかどうかを判定する（ステップ３０７）。「Ｕｐｄａｔｅ」であれば、マージ部３４からΔ２取得部３３に制御が移り、Δ２取得部３３が、Δ２があるかどうかを判定する（ステップ３０８）。具体的には、Δ１が関係するMapping要素の子要素としてChange要素が存在するかどうかを判定する。その結果、Change要素が存在していなければ、Δ１に従ってＴＭ０（ＴＭ０＿ｎ）の要素を更新し（ステップ３０９）、ステップ３０２に戻って次のΔ１の処理に移る。
更に、ステップ３０７でΔ１の変更タイプが「Ｕｐｄａｔｅ」でもないと判定された場合、変更タイプは「Ｄｅｌｅｔｅ」である。そこで、マージ部３４からΔ２取得部３３に制御が移り、Δ２取得部３３が、Δ２があるかどうかを判定する（ステップ３１０）。具体的には、Δ１が関係するMapping要素の子要素としてChange要素が存在するかどうかを判定する。その結果、Change要素が存在していなければ、Δ１に従ってＴＭ０（ＴＭ０＿ｎ）の要素を削除し（ステップ３１１）、ステップ３０２に戻って次のΔ１の処理に移る。
【００４６】
ところで、ステップ３０８及びステップ３１０において、Δ２があると判定された場合は、Δ１とΔ２とが同じ要素について競合することになる。この場合は、図１０を参照して説明した処理パターン表に基づいた処理を行う（ステップ３１２）。
まず、ステップ３０８からステップ３１２に処理が進んできた場合について説明する。
この場合、Δ１は「Ｕｐｄａｔｅ」である。これに対し、Δ２が「Ｕｐｄａｔｅ」の場合と「Ｄｅｌｅｔｅ」の場合とでどのような処理を行うかを考えればよい。
依存強度Ｈの場合、Δ２が「Ｕｐｄａｔｅ」であれば、Δ２を無効化し、Δ１に従ってＴＭ０（ＴＭ０＿ｎ）の要素を更新する。また、Δ２が「Ｄｅｌｅｔｅ」であれば、削除された要素を復活させる必要があるので、Δ１に従ってＴＭ０（ＴＭ０＿ｎ）に要素を追加する。
依存強度Ｍの場合、Δ２が「Ｕｐｄａｔｅ」であれば、何もしない。また、Δ２が「Ｄｅｌｅｔｅ」であれば、削除された要素を復活させる必要があるので、Δ１に従ってＴＭ０（ＴＭ０＿ｎ）に要素を追加する。
依存強度Ｌの場合は、何もしない。
依存強度Ｎの場合は、例えばダイアログボックス等を表示してＴＭ編集者によるマージ処理を促す。
【００４７】
次に、ステップ３１０からステップ３１２に処理が進んできた場合について説明する。
この場合、Δ１は「Ｄｅｌｅｔｅ」である。これに対し、Δ２が「Ｕｐｄａｔｅ」の場合と「Ｄｅｌｅｔｅ」の場合とでどのような処理を行うかを考えればよい。
依存強度Ｈの場合、Δ２が「Ｕｐｄａｔｅ」であれば、Δ１に従ってＴＭ０（ＴＭ０＿ｎ）の要素を削除する。また、Δ２が「Ｄｅｌｅｔｅ」であれば、何もしない。
依存強度Ｍの場合、Δ２が「Ｕｐｄａｔｅ」であれば、Δ１に従ってＴＭ０（ＴＭ０＿ｎ）の要素を削除する。また、Δ２が「Ｄｅｌｅｔｅ」であれば、何もしない。
依存強度Ｌの場合は、何もしない。
依存強度Ｎの場合、Δ２が「Ｕｐｄａｔｅ」であれば、ダイアログボックス等を表示してＴＭ編集者にマージ処理を促す。また、Δ２が「Ｄｅｌｅｔｅ」であれば、何もしない。
【００４８】
最後に、本実施の形態を適用するのに好適なコンピュータのハードウェア構成について説明する。図１２は、このようなコンピュータのハードウェア構成の一例を示した図である。図示するように、コンピュータは、演算手段であるＣＰＵ(Central Processing Unit）１０ａと、Ｍ／Ｂ(マザーボード）チップセット１０ｂを介してＣＰＵ１０ａに接続されたメインメモリ１０ｃと、同じくＭ／Ｂチップセット１０ｂを介してＣＰＵ１０ａに接続された表示機構１０ｄとを備える。また、Ｍ／Ｂチップセット１０ｂには、ブリッジ回路１０ｅを介して、ネットワークインターフェイス１０ｆと、磁気ディスク装置（ＨＤＤ）１０ｇと、音声機構１０ｈと、キーボード／マウス１０ｉと、フレキシブルディスクドライブ１０ｊとが接続されている。
【００４９】
尚、図１２において、各構成要素は、バスを介して接続される。例えば、ＣＰＵ１０ａとＭ／Ｂチップセット１０ｂの間や、Ｍ／Ｂチップセット１０ｂとメインメモリ１０ｃの間は、ＣＰＵバスを介して接続される。また、Ｍ／Ｂチップセット１０ｂと表示機構１０ｄとの間は、ＡＧＰ（Accelerated Graphics Port）を介して接続されてもよいが、表示機構１０ｄがＰＣＩ Ｅｘｐｒｅｓｓ対応のビデオカードを含む場合、Ｍ／Ｂチップセット１０ｂとこのビデオカードの間は、ＰＣＩ Ｅｘｐｒｅｓｓ（ＰＣＩｅ）バスを介して接続される。また、ブリッジ回路１０ｅと接続する場合、ネットワークインターフェイス１０ｆについては、例えば、ＰＣＩ Ｅｘｐｒｅｓｓを用いることができる。また、磁気ディスク装置１０ｇについては、例えば、シリアルＡＴＡ（AT Attachment）、パラレル転送のＡＴＡ、ＰＣＩ（Peripheral Components Interconnect）を用いることができる。更に、キーボード／マウス１０ｉ、及び、フレキシブルディスクドライブ１０ｊについては、ＵＳＢ（Universal Serial Bus）を用いることができる。
【００５０】
ここで、本発明は、全てハードウェアで実現してもよいし、全てソフトウェアで実現してもよい。また、ハードウェア及びソフトウェアの両方により実現することも可能である。また、本発明は、コンピュータ、データ処理システム、コンピュータプログラムとして実現することができる。このコンピュータプログラムは、コンピュータにより読取り可能な媒体に記憶され、提供され得る。ここで、媒体としては、電子的、磁気的、光学的、電磁的、赤外線又は半導体システム（装置又は機器）、或いは、伝搬媒体が考えられる。また、コンピュータにより読取り可能な媒体としては、半導体、ソリッドステート記憶装置、磁気テープ、取り外し可能なコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、リジッド磁気ディスク、及び光ディスクが例示される。現時点における光ディスクの例には、コンパクトディスク−リードオンリーメモリ（ＣＤ−ＲＯＭ）、コンパクトディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）及びＤＶＤが含まれる。
【００５１】
このように、本実施の形態では、モデル変換時にＴＤＭを生成し、ソースモデルとターゲットモデルのマッピング情報を保持するようにした。これにより、Δ１とΔ２に関するツールによる変更管理の支援を可能にしている。Δ２に関しては、ＴＤＭのマッピング情報がなければ、ソースモデルとの関係が不明のままターゲットモデルを変更していくことになるが、本実施の形態によれば、そのような関係を維持することが可能となる。
また、本実施の形態では、依存強度が定義されたＴＤＭを用いたマージ機能により、ＴＭ編集者によるマージ作業を従来に比べて軽減することを可能にする。依存強度が予め正しく定義できる場合には、競合箇所に関するＴＭ編集者によるマージ作業を削減することもできる。
従って、本実施の形態によれば、モデル駆動型開発における変更管理作業の時間短縮と品質向上が可能になる。
【００５２】
以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態には限定されない。本発明の精神及び範囲から逸脱することなく様々に変更したり代替態様を採用したりすることが可能なことは、当業者に明らかである。
【図面の簡単な説明】
【００５３】
【図１】本発明の実施の形態における編集及びマージについて説明するための図である。
【図２−１】本発明の実施の形態におけるターゲットモデルとしてのソースコードの一例である。
【図２−２】本発明の実施の形態におけるターゲットモデルとしてのソースコードの一例である。
【図２−３】本発明の実施の形態におけるターゲットモデルとしてのソースコードの一例である。
【図３】本発明の実施の形態におけるＴＤＭの生成について説明するための図である。
【図４】本発明の実施の形態におけるＴＤＭのメタモデルを示した図である。
【図５】本発明の実施の形態におけるＴＤＭの記述例を示した図である。
【図６】本発明の実施の形態におけるChange要素の登録について説明するための図である。
【図７】本発明の実施の形態におけるマージ作業の流れを示した図である。
【図８】本発明の実施の形態におけるChange要素登録機能の動作を示したフローチャートである。
【図９】本発明の実施の形態におけるマージ装置の機能構成を示したブロック図である。
【図１０】本発明の実施の形態における処理パターン表の例を示した図である。
【図１１】本発明の実施の形態におけるマージ装置の動作を示したフローチャートである。
【図１２】本発明の実施の形態を適用可能なコンピュータのハードウェア構成を示した図である。
【符号の説明】
【００５４】
１０…モデル編集装置、１１…モデル変換機能、１２…Change要素登録機能、１３…マージ機能、１４…Δ１抽出機能
【図１】
2008269136.tif 000003
【図２−１】
2008269136.tif 000004
【図２−２】
2008269136.tif 000005
【図２−３】
2008269136.tif 000006
【図３】
2008269136.tif 000007
【図４】
2008269136.tif 000008
【図５】
2008269136.tif 000009
【図６】
2008269136.tif 000010
【図７】
2008269136.tif 000011
【図８】
2008269136.tif 000012
【図９】
2008269136.tif 000013
【図１０】
2008269136.tif 000014
【図１１】
2008269136.tif 000015
【図１２】
2008269136.tif 000016