(57)【要約】【課題】  メタモデルを拡張定義することにより、モデリング言語による記述能力を高めることができるシステム設計装置及び方法を提供する。【解決手段】  一実施形態に係るシステム設計装置は、メタモデル定義部と、モデル構築部と、スクリプトファイル生成部と、を備える。メタモデル定義部は、モデリング言語により記述された第１のメタモデルに基づいて、第２のメタモデルを生成する。第２のメタモデルは、第１のメタモデルと、制約条件を記述する制約条件クラスのメタモデルと、関係クラス（Trace）に対して、制約条件の有無を区別するため、制約条件クラスと関係クラスとの間の関連（Association）を定義するメタモデルと、を含む。モデル構築部は、第２のメタモデルに従ってモデルを構築する。スクリプトファイル生成部は、モデルに対応するスクリプトファイルを生成する。
2017072969.tif 000002
【特許請求の範囲】
【請求項１】
モデリング言語により記述された第１のメタモデルに基づいて、前記第１のメタモデルと、制約条件を記述する制約条件クラスのメタモデルと、関係クラス（Trace）に対して、前記制約条件の有無を区別するため、前記制約条件クラスと前記関係クラスとの間の関連（Association）を定義するメタモデルと、
を含む第２のメタモデルを生成するメタモデル定義部と、
前記第２のメタモデルに従ってモデルを構築するモデル構築部と、
前記モデルに対応するスクリプトファイルを生成するスクリプトファイル生成部と、
を備えるシステム設計装置。
【請求項２】
前記第２のメタモデルは、前記制約条件クラスの属性として、前記制約条件の種類と、前記制約条件の可変性と、の少なくとも一方を含む
請求項１に記載のシステム設計装置。
【請求項３】
前記第２のメタモデルは、最上位クラスの属性として、バージョン情報を含む
請求項１又は請求項２に記載のシステム設計装置。
【請求項４】
前記第２のメタモデルは、要求の分解関係を定義する分解関係クラスのメタモデルを含む
請求項１乃至請求項３のいずれか１項に記載のシステム設計装置。
【請求項５】
前記第２のメタモデルは、各関係の貢献度を定義する貢献度クラスのメタモデルを含む
請求項１乃至請求項４のいずれか１項に記載のシステム設計装置。
【請求項６】
前記第２のメタモデルに従って定義された前記モデルを、スクリプト言語として記述するための記述様式を定義する、モデル記述言語を生成するモデル記述言語生成部を備える
請求項１乃至請求項５のいずれか１項に記載のシステム設計装置。
【請求項７】
前記スクリプトファイルを実行する動的モデル実行部を備える
請求項１乃至請求項６のいずれか１項に記載のシステム設計装置。
【請求項８】
前記モデルの変更内容を、前記関係クラスに対する前記制約条件の有無に基づいて分析する変更分析部を備える
請求項１乃至請求項７のいずれか１項に記載のシステム設計装置。
【請求項９】
前記変更分析部による分析結果に基づいて、前記モデルを更新するモデル更新部を備える
請求項８に記載のシステム設計装置。
【請求項１０】
前記モデルをリレーショナルデータベースに格納するための変換ルールを生成する変換ルール生成部を備える
請求項１乃至請求項９のいずれか１項に記載のシステム設計装置。
【請求項１１】
前記変換ルールに従って、前記モデルに対応するリレーショナルデータベースのテーブルを構築するテーブル構築部を備える
請求項１０に記載のシステム設計装置。
【請求項１２】
前記モデルを表示する表示装置を備える
請求項１乃至請求項１１のいずれか１項に記載のシステム設計装置。
【請求項１３】
モデリング言語により記述された第１のメタモデルに基づいて、前記第１のメタモデルと、制約条件を記述する制約条件クラスのメタモデルと、関係クラス（Trace）に対して、制約条件の有無を区別するため、前記制約条件クラスと関係クラス間の関連（Association）を定義するメタモデルと、を含む第２のメタモデルを生成する工程と、
前記第２のメタモデルに従ってモデルを構築する工程と、
前記モデルに対応するスクリプトファイルを生成する工程と、
を備えるシステム設計方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、システム設計装置及び方法に関する。
【背景技術】
【０００２】
近年、システムの設計のために、ＵＭＬ（Unified Modeling Language）やＳｙｓＭＬ（System Modeling Language）などのモデリング言語が利用されている。ＵＭＬは、汎用モデリング言語であり、ソフトウェアの設計や、ソースコードの自動生成が可能である。ＳｙｓＭＬは、ＵＭＬを拡張したものであり、ＵＭＬに対して、機能要求を定義する要求図（Requirement diagram）や、動的モデルを定義するパラメトリック図（Parametric diagram）が追加されている。ＳｙｓＭＬを利用することにより、動的モデル（例えば、シミュレーションや最適計算のためのモデル）を設計することができる。【０００３】
しかしながら、ＵＭＬやＳｙｓＭＬのモデルを記述する文法や仕様を定義するメタモデルの現状仕様は、下記の４つのモデル記述不足点を挙げられる。その１、要求モデルとその要求を満たす（Satisfy）等のモデル要素間の関係を定義する関係クラス（Trace）には、制約条件のあり・なしを区別して定義することはできない問題がある。その２、全てのモデル要素にバージョン情報を付与できない問題がある。その３、要求定義モデル定義には、要求間の分解関係、所謂、“ＯＲ”の論理和（Disjunction）関係を定義できない問題がある。その４、前記関係クラス（Trace）には、それぞれのモデル要素と要求間の関係の重み付けをできない問題がある。なお、関係クラス（Trace）及びその１、その３、その４については非特許文献１を参照し、その２は非特許文献２を参照する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−９２２２８号公報
【非特許文献】
【０００５】
【非特許文献１】OMG Systems Modeling Language Version1.3
【非特許文献２】ISO/IEC 19505-2：UML Superstructure version2.4
【発明の概要】
【発明が解決しようとする課題】
【０００６】
モデリング言語のメタモデルを拡張定義することにより、モデリング言語による記述能力を高めることができるシステム設計装置及び方法を提供する。
【課題を解決するための手段】
【０００７】
一実施形態に係るシステム設計装置は、メタモデル定義部と、モデル構築部と、スクリプトファイル生成部と、を備える。メタモデル定義部は、モデリング言語により記述された第１のメタモデルに基づいて、第２のメタモデルを生成する。第２のメタモデルは、第１のメタモデルと、制約条件を記述する制約条件クラスのメタモデルと、関係クラス（Trace）に対して、制約条件の有無を区別するため、前記制約条件クラスと関係クラス間の関連（Association）を定義するメタモデルと、を含む。モデル構築部は、第２のメタモデルに従ってモデルを構築する。スクリプトファイル生成部は、モデルに対応するスクリプトファイルを生成する。
【図面の簡単な説明】
【０００８】
【図１】メタモデル、モデル、及びデータ（インスタンス）の関係を示す図。
【図２】クラス、属性、アトリビュートの関係を示す図。
【図３】システム設計装置の機能構成を示す図。
【図４】システム設計装置を構成するコンピュータの一例を示す図。
【図５】関係クラスのメタモデルの一例を示す図。
【図６】第１の拡張方法により生成された拡張メタモデルに従って構築された拡張モデルの一例を示す図。
【図７】第２の拡張方法により生成された拡張メタモデルの一例を示す図。
【図８】第２の拡張方法により生成された拡張メタモデルに従って構築された拡張モデルの一例を示す図。
【図９】第３の拡張方法により生成された拡張メタモデルに従って構築された拡張モデルの一例を示す図。
【図１０】第４の拡張方法により生成された拡張メタモデルに従って構築された拡張モデルの一例を示す図。
【図１１】モデル記述言語の一例を示す図。
【図１２】スクリプトファイルの一例を示す図。
【図１３】ユーザがモデル記述言語を選択可能なＧＵＩの操作画面の一例を示す図。
【図１４】変更内容の分析処理の一例を示すフローチャート。
【図１５】ユーザが更新対象を選択可能なＧＵＩの操作画面の一例を示す図。
【図１６】変換ルールの仕様の一例を示す図。
【図１７】変換ルールの仕様の一例を示す図。
【図１８】モデル要素に対応するテーブルの一例を示す図。
【図１９】ユーザがテーブルを構築可能なＧＵＩの操作画面の一例を示す図。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態について図面を参照して説明する。
【００１０】
システム設計装置の実施形態について、図１〜図１９を参照して説明する。まず、本実施形態におけるモデルの概念について説明する。
【００１１】
図１は、メタモデル、モデル、及びデータ（インスタンス）の関係を示す図である。
【００１２】
メタモデル２０１は、モデル２０２を記述するための文法や仕様を定める上位モデルである。メタモデル２０１は、モデルのモデルと称される。定義例２０４は、クラスのメタモデルの定義の一例である。定義例２０４は、クラスには、名称が必須であり、属性（Property）及び操作（Operation）が定義されることを示している。
【００１３】
モデル２０２は、ソフトウェアなどのシステムの設計図に相当するものであり、要求図やブロック図などの各種の図（モデル要素）により構成される。モデル２０２は、メタモデル２０１の定義に従って構築される。定義例２０５は、定義例２０４に従って定義されたクラス（モデル）の定義の一例である。定義例２０５は、クラスの名称が「二輪車」であり、このクラスには属性として「色」及び「最高速度」が定義され、操作として「走る距離を計算（）」が定義されていることを示している。
【００１４】
データ２０３は、モデル２０２の定義に従って定義された実際のデータである。定義例２０６は、定義例２０５に従って定義された二輪車クラスの実際のデータの定義の一例である。定義例２０６は、データの名称が「花子さんの二輪車」であり、「色」が赤、「最高速度」が５０ｋｍ／ｈであることを示している。
【００１５】
図２は、クラス、属性、アトリビュートの関係を示す図である。
【００１６】
上述の通り、クラスには、属性が定義される。クラス及び属性は、名称やデータ型などの定義項目を有する。以下、クラス及び属性の個々の定義項目をアトリビュートと称し、アトリビュートの集合をアトリビュートセットと称する。クラス及び属性は、それぞれのアトリビュートセットを用いて定義される。
【００１７】
図２の例では、クラス３０１は、ID，Name，descriptionなどのアトリビュートを含むアトリビュートセット３０３を用いて定義される。具体的には、クラス３０１のエンティティ３０２は、アトリビュートセット３０３により定義される。
【００１８】
また、クラス３０１の属性は、ID，Name，descriptionなどのアトリビュートを含むアトリビュートセット３０５を用いて定義される。具体的には、クラス３０１の属性のエンティティ３０４は、アトリビュートセット３０５により定義される。
【００１９】
なお、図２のアトリビュートセット３０３，３０４に含まれるversionは、本実施形態に係るシステム設計装置により新たに定義可能となったアトリビュートである。versionについて、詳しくは後述する。
【００２０】
次に、本実施形態に係るシステム設計装置について、図３を参照して説明する。図３は、システム設計装置の機能構成を示す図である。図３に示すように、システム設計装置は、メタモデル定義部１と、モデル構築部２と、モデル記述言語生成部３と、スクリプトファイル生成部４と、動的モデル実行部５と、変更分析部６と、モデル更新部７と、変換ルール生成部８と、テーブル構築部９と、ＤＢ（データベース）１０と、を備える。
【００２１】
メタモデル定義部１は、入力された既存メタモデル（第１のメタモデル）に基づいて、拡張メタモデル（第２のメタモデル）を生成する。既存メタモデルとは、ＵＭＬやＳｙｓＭＬで記述されるモデルの、記述仕様を定義する既存のメタモデルのことである。拡張メタモデルとは、既存メタモデルを拡張定義したメタモデルのことである。メタモデル定義部１は、既存メタモデルにクラスや属性を拡張定義することにより、拡張メタモデルを生成する。
【００２２】
モデル構築部２は、メタモデル定義部１が生成した拡張メタモデルに従って、モデルを構築（定義）する。以下、モデル構築部２が構築したモデルを、拡張モデルと称する。モデル構築部２は、拡張モデルを編集することができる。
【００２３】
モデル記述言語生成部３は、メタモデル定義部１が生成した拡張メタモデルに基づいて、モデル記述言語を生成する。モデル記述言語は、拡張メタモデルに従って定義された拡張モデルを、実行可能なスクリプト言語として記述するための記述様式を定義したものである。
【００２４】
スクリプトファイル生成部４は、モデル構築部２が構築した拡張モデルと、モデル記述言語生成部３が生成したモデル記述言語と、に基づいて、拡張モデルに対応する、実行可能なスクリプトファイル（Script File）を生成する。
【００２５】
動的モデル実行部５は、スクリプトファイル生成部４が生成したスクリプトファイルを実行する。スクリプトファイルの実行は、拡張モデルの実行に相当する。
【００２６】
変更分析部６は、モデル構築部２により編集された拡張モデルの変更内容を分析する。
【００２７】
モデル更新部７は、変更分析部６による変更内容の分析結果に基づいて、拡張モデルを更新する。
【００２８】
変換ルール生成部８は、モデル構築部２が構築した拡張モデルを、リレーショナルＤＢに格納するための変換ルールを生成する。
【００２９】
テーブル構築部９は、変換ルール生成部８が生成した変換ルールに従って、拡張モデルに対応するテーブルを構築する。
【００３０】
ＤＢ１０は、テーブル構築部９が構築したテーブルを格納するリレーショナルデータベースである。
【００３１】
なお、システム設計装置の各機能構成について、詳しくは後述する。
【００３２】
次に、本実施形態に係るシステム設計装置のハードウェア構成について、図４を参照して説明する。本実施形態に係るシステム設計装置は、コンピュータ１００により構成される。コンピュータ１００には、サーバ、クライアント、マイコン、及び汎用コンピュータなどが含まれる。
【００３３】
図４は、コンピュータ１００の一例を示す図である。図４のコンピュータ１００は、ＣＰＵ（中央演算装置）１０１と、入力装置１０２と、表示装置１０３と、通信装置１０４と、記憶装置１０５と、を備える。プロセッサ１０１、入力装置１０２、表示装置１０３、通信装置１０４、及び記憶装置１０５は、バス１０６により相互に接続されている。
【００３４】
プロセッサ１０１は、コンピュータ１００の制御装置及び演算装置を含む電子回路である。プロセッサ１０１は、バス１０６を介して接続された各装置（例えば、入力装置１０２、通信装置１０４、記憶装置１０５）から入力されたデータやプログラムに基づいて演算処理を行い、演算結果や制御信号を、バス１０６を介して接続された各装置（例えば、表示装置１０３、通信装置１０４、記憶装置１０５）に出力する。具体的には、プロセッサ１０１は、コンピュータ１００のＯＳ（オペレーティングシステム）や、システム設計プログラムなどを実行し、コンピュータ１００を構成する各装置を制御する。
【００３５】
システム設計プログラムとは、コンピュータ１００に、システム設計装置の上述の各機能構成を実現させるプログラムである。システム設計プログラムは、一時的でない有形のコンピュータ読み取り可能な記憶媒体に記憶される。上記の記憶媒体は、例えば、光ディスク、光磁気ディスク、磁気ディスク、磁気テープ、フラッシュメモリ、半導体メモリであるが、これに限られない。プロセッサ１０１がシステム設計プログラムを実行することにより、コンピュータ１００がシステム設計装置として機能する。
【００３６】
入力装置１０２は、コンピュータ１００に情報を入力するための装置である。入力装置１０２は、例えば、キーボード、マウス、及びタッチパネルであるが、これに限られない。ユーザは、入力装置１０２を用いることにより、既存メタモデルなどの情報を入力することができる。
【００３７】
表示装置１０３は、画像や映像を表示するための装置である。表示装置１０３は、例えば、ＬＣＤ（液晶ディスプレイ）、ＣＲＴ（ブラウン管）、及びＰＤＰ（プラズマディスプレイ）であるが、これに限られない。表示装置１０３は、システム設計装置に入力されたデータ（既存メタモデルなど）、システム設計装置により生成されたデータ（拡張メタモデル、拡張モデル、モデル記述言語、及びスクリプトファイルなど）、及びユーザがシステム設計装置を操作するためのＧＵＩ（Graphical User Interface）などを表示する。
【００３８】
通信装置１０４は、コンピュータ１００が外部装置と無線又は有線で通信するための装置である。通信装置１０４は、例えば、モデム、ハブ、及びルータであるが、これに限られない。
【００３９】
記憶装置１０５は、コンピュータ１００のＯＳや、システム設計プログラム、システム設計プログラムの実行に必要なデータ、及びシステム設計プログラムの実行により生成されたデータなどを記憶する記憶媒体である。記憶装置１０５には、主記憶装置と外部記憶装置とが含まれる。主記憶装置は、例えば、ＲＡＭ、ＤＲＡＭ、ＳＲＡＭであるが、これに限られない。また、外部記憶装置は、例えば、ハードディスク、光ディスク、フラッシュメモリ、及び磁気テープであるが、これに限られない。ＤＢ１０は、記憶装置１０５上に構築されてもよいし、外部のサーバ上に構築されてもよい。
【００４０】
なお、コンピュータ１００は、プロセッサ１０１、入力装置１０２、表示装置１０３、通信装置１０４、及び記憶装置１０５を、それぞれ１つ又は複数備えてもよいし、プリンタやスキャナなどの周辺機器を接続されていてもよい。
【００４１】
また、システム設計装置は、単一のコンピュータ１００により構成されてもよいし、相互に接続された複数のコンピュータ１００からなるシステムとして構成されてもよい。
【００４２】
さらに、システム設計プログラムは、コンピュータ１００の記憶装置１０５に予め記憶されていてもよいし、コンピュータ１００の外部の記憶媒体に記憶されていてもよいし、インターネット上にアップロードされていてもよい。いずれの場合も、システム設計プログラムをコンピュータ１００にインストールして実行することにより、システム設計装置の機能が実現される。
【００４３】
以下、システム設計装置の各機能構成について、図５〜図１９を参照して詳細に説明する。
【００４４】
（メタモデル定義部１及びモデル構築部２）
メタモデル定義部１による既存メタモデルの拡張方法（拡張メタモデルの生成方法）について説明する。以下では、４つの拡張方法について、それぞれ説明する。
【００４５】
（第１の拡張方法）
一般に、メタモデルには、要求図と、他の図（ブロック図（Block diagram）やパラメトリック図）と、の間の関係を定義する関係クラス（Trace）のメタモデルが設けられている。
【００４６】
図５は、関係クラスのメタモデルの一例を示す図である。図５の例では、既存メタモデルとして、関係クラス（Trace）４０１とその下位クラスとして、DerivedReqt，Copy，Verify，Satisfyが設けられている。Satisfy（以下、「満たす関係」という）は、要求と、その要求を満足させるモデル要素と、の関係を示している。
【００４７】
従来、満たす関係では、モデル要素が満足させる要求に対して、制約条件があるか否か区別できなかった。そこで、第１の拡張方法では、メタモデル定義部１は、図５に４０２示すように、制約条件クラス（Condition）のメタモデルを定義（追加）し、関係クラスに対する制約条件の有無を区別するため、制約条件クラスと関係クラス間の関連のメタモデルを拡張定義する。制約条件クラス(Condition)は、要求に対する制約条件を記述するためのクラスである。
【００４８】
図５の例では、制約条件クラス４０２のアトリビュートセット（Condition_attribute）には、制約条件の可変性（constantCondition）と、名称（Name）と、制約条件の種類（Type）と、が含まれる。
【００４９】
制約条件の可変性は、boolean型であり、例えば、時間軸に不変な場合（すなわち、経時的に変化しない場合）にTrue、それ以外の場合にFalseと定義される。
【００５０】
制約条件の種類は、ConditionType（選択肢型）であり、選択肢として、pre_cal_condition，pre_env_condition，trigger，post_cal_condition，post_env_condition，functional_typeを含んでいる。
【００５１】
このように、メタモデル定義部１が制約条件クラスのメタモデルを拡張定義することにより、既存メタモデルと、制約条件を記述する制約条件クラスのメタモデルと、要求とその要求を満たす等のためのモデル要素間との関係を定義する関係クラス（Trace）に対して、制約条件の有無を区別するため、制約条件クラスと関係クラス間の関連（Association）を定義するメタモデルと、を含む拡張メタモデルが生成される。なお、制約条件クラスの属性及びアトリビュートは、図５の例に限られず、任意に設計可能である。
【００５２】
図６は、第１の拡張方法により生成された拡張メタモデルに従って構築された拡張モデルの一例を示す図である。図６の例では、要求図５０１とブロック図５０３との間には、制約条件付きの満たす関係（satisfyWithCondition）５０２が定義されている。制約条件付きの満たす関係５０２は、制約条件クラス５０４（Condition1）を参照している。制約条件クラス５０４（Condition1）には、各属性の名称、属性の説明、及び制約条件が記述されている。また、制約条件クラス５０４は、計算を行うパラメトリック図５０５を参照している。
【００５３】
パラメトリック図５０５は、入力（ｌ，ｔ，ｖ）と、出力（ａ）と、計算式と、を定義している。計算式は、例えば、ＭａｔｈＭＬ（Mathematical Markup Language）により記述される。
【００５４】
このように、第１の拡張方法により生成された拡張メタモデルを用いることにより、モデル構築部２は、制約条件がない満たす関係（satisfy）と、制約条件付きの満たす関係（satisfyWithCondition）と、がそれぞれ定義された拡張モデルを構築することができる。これにより、各要求に対して、制約条件があるか否か区別したり、制約条件の内容を定義したりすることができる。
【００５５】
（第２の拡張方法）
第２の拡張方法では、メタモデル拡張部１は、既存メタモデルの最上位クラスのメタモデルのアトリビュートに、メタモデルのバージョン情報を拡張定義（追加）する。これにより、最上位クラスのメタモデルのアトリビュートにバージョン情報が含まれた拡張メタモデルが生成される。
【００５６】
図７は、第２の拡張方法により生成された拡張メタモデルの一例を示す図である。図７において、最上位クラスは、Classifierであり、その下位クラスとして、Datatype，Class，Associationなどが既存メタモデルに定義されている。第２の拡張方法によってClassifierには、アトリビュートとしてバージョン情報（version）が拡張定義されている。
【００５７】
図８は、第２の拡張方法により生成された拡張メタモデルに従って構築された拡張モデルの一例を示す図である。図８に示すように、拡張モデルの各モデル要素５０１〜５０５には、いずれもバージョン情報が記載されている。これは、最上位クラスに追加定義されたバージョン情報が継承されたためである。また、５０１〜５０５に定義する各要素、例えば、５０４に定義する属性の“airPressure”にもバージョン情報を定義できる。記述例は、図１２の行１０に示す。
【００５８】
このように、第２の拡張方法により生成された拡張メタモデルを用いることにより、モデル構築部２は、各モデル要素がバージョン情報を有する拡張モデルを構築することができる。これにより、拡張モデルの更新や管理を効率的に行うことができる。
【００５９】
（第３の拡張方法）
第３の拡張方法では、メタモデル定義部１は、分解関係クラス（Decompose）のメタモデルを拡張定義（追加）する。分解関係クラスは、要求の分解関係（論理和）を定義するクラスであり、図５に示すように、関係クラスの下位クラスとして追加される。これにより、既存メタモデルと、分解関係クラスのメタモデルと、を含む拡張メタモデルが生成される。
【００６０】
図９は、第３の拡張方法により生成された拡張メタモデルに従って構築された拡張モデルの一例を示す図である。図９の例では、要求４２０１（Re1）は、要求４２０２（Re2）と、要求４２０３（Re3）と、に分解されている。これは、要求４２０１は、要求４２０２又は要求４２０３を満足することにより、満たされることを示している。
【００６１】
このように、第３の拡張方法により生成された拡張メタモデルを用いることにより、モデル構築部２は、要求の分解関係が定義された拡張モデルを構築することができる。
【００６２】
（第４の拡張方法）
第４の拡張方法では、メタモデル定義部１は、図５に示すように、貢献度クラス（Contribution）のメタモデルを拡張定義（追加）する。貢献度クラスは、DerivedReqt，Copy，Verify，Satisfy，satisfyWithCondition，Decomposeなどの各関係の貢献度を定義するクラスであり、図５に示すように、関係クラスに関連づけられる。貢献度クラスには、属性として、重み（Weight）が定義される。重みは、例えば、各関係の変更コストであるが、これに限られない。これにより、既存メタモデルと、貢献度クラスと、を含む拡張メタモデルが生成される。
【００６３】
図１０は、第４の拡張方法により生成された拡張メタモデルに従って構築された拡張モデルの一例を示す図である。図１０において、ｘは分解関係４２０４の重みであり、ｙは分解関係４２０５の重みである。また、ｍは、機能ブロック４２０６（Block2）と要求４２０３（Re3）と、の間の満たす関係４２０７の重みであり、ｎは、機能ブロック４２０８（Block3）と要求４２０３（Re3）と、の間の満たす関係４２０９の重みである。各重みは、任意に設定可能である。重みは、例えば、１以上１０以下の整数の中から選択可能であってもよい。
【００６４】
このように、第４の拡張方法により生成された拡張メタモデルを用いることにより、モデル構築部２は、各関係の重みが定義された拡張モデルを構築することができる。重みとして、各関係の変更コストを定義すると、モデルの変更コストを容易に計算し、変更の管理効率を向上させることができる。
【００６５】
なお、メタモデル定義部１は、上述の第１の拡張方法乃至第４の拡張方法を、個々に利用してもよいし、２つ以上組み合わせて利用してもよい。
【００６６】
また、メタモデル定義部１及びモデル構築部２は、既存メタモデル、拡張メタモデル、拡張モデルなどを、表示装置１０３により表示させてもよい。さらに、モデル構築部２は、既存メタモデルに従ってモデルを構築し、構築したモデルを表示装置１０３により表示させてもよい。
【００６７】
（モデル記述言語生成部３）
モデル記述言語生成部３は、拡張メタモデルに基づいて、モデル記述言語を生成する。以下では、モデル記述言語を、ＭＴＬ４Ｓｙｓ（Model Transformation Language for SysML）と称する。図１１は、ＭＴＬ４Ｓｙｓの一例を示す図である。以下、図１１のＭＴＬ４Ｓｙｓの各行について説明する。
【００６８】
第１行は、各要求図を、要求型のクラスとして記述することを定義している。
【００６９】
第２行は、各ブロック図を、ブロック型のクラスとして記述することを定義している。
【００７０】
第３行は、要求クラスと、ブロッククラスと、の間の関係を、満たす関係（satisfy）又は条件付きの満たす関係（satisfyWithConstraint）として記述することを定義している。第３行において、条件付きの満たす関係は、参照先となる制約条件クラスのＩＤ、例えばCondition1と共に定義されている。
【００７１】
第４行は、制約条件を、制約条件クラスとして記述することを定義している。
【００７２】
第５行は、制約条件のアトリビュート（定義項目）を、制約条件クラスの属性（property）として記述することを定義している。
【００７３】
第６行は、制約条件のconstantTypeアトリビュートを、制約条件クラスのconstantType属性として記述することを定義している。
【００７４】
第７行は、制約条件のTypeアトリビュートを、制約条件クラスのconditionTypeのアトリビュートとして記述することを定義している。
【００７５】
第８行は、操作（operation）などを記述するパラメトリック図を、機能（Function）クラスとして記述することを定義している。
【００７６】
第９行は、操作の入力（input）を、機能クラスのパラメータとして記述することを定義している。
【００７７】
第１０行は、操作の出力（output）を、機能クラスの出力（return）として記述することを定義している。
【００７８】
第１１行は、操作の事前計算数式（formula.preCal）を、パラメータ及び事前計算条件（pre_cal_condition）を用いる機能クラスの事前計算数式とし、事前計算結果をpre_resultとして記述することを定義している。
【００７９】
第１２行は、操作の計算数式（formula）は、パラメート及び事前計算結果（pre_result）を用いる機能クラスの計算数式とし、計算結果をresultとして記述することを定義している。
【００８０】
第１３行は、操作の事後計算数式を、パラメータ及び事前計算条件を用いる機能クラスの事後計算数式とし、事後計算結果をafter_resultとして記述することを定義している。
【００８１】
第１４行は、ＵＭＬの全てのモデル要素に付与するバージョン情報（version）を、対応するモデル要素のバージョン情報として記述することを定義している。
【００８２】
このように、ＭＴＬ４Ｓｙｓでは、スクリプト言語による拡張モデルの記述仕様が定義されている。モデル記述言語生成部３は、拡張メタモデルに基づいて、このようなＭＴＬ４Ｓｙｓを自動的に生成することができる。
【００８３】
なお、モデル記述言語生成部３は、こうして生成したＭＴＬ４Ｓｙｓを、表示装置１０３に表示させてもよい。
【００８４】
（スクリプトファイル生成部４）
図１２は、スクリプトファイル生成部４により生成されたスクリプトファイルの一例を示す図である。図１２のスクリプトファイルは、図６の拡張モデルに対応している。以下、図１２のスクリプトファイルの各行について説明する。
【００８５】
第行１は、このスクリプトファイルの記述仕様（ＭＴＬ４Ｓｙｓ）と、そのバージョン情報（version）と、を記述する。
【００８６】
第２行〜第４行は、要求図５０１を記述している。
【００８７】
第５行〜第８行は、ブロック図５０３を記述している。
【００８８】
第９行〜第２９行は、制約条件クラス５０４と、パラメトリック図５０５と、を記述している。具体的には、以下の通りである。
【００８９】
第９行は、制約条件クラスを定義している。
【００９０】
第１０行〜第１４行は、制約条件クラス５０４のairPressure属性を定義している。より詳細には、第１１行は、airPressure属性のconstantTypeの値を記述し、第１２行は、conditionTypeの値を記述し、第１３行は、制約値及び単位を記述している。
【００９１】
第１５行〜第２０行は、制約条件クラス５０４の属性ｌを定義している。より詳細には、第１５行は、属性ｌの名称（name）、名称言語（lang）、及びｉｄを定義している。第１６行は、属性ｌのアトリビュートdescriptionの値を記述している。第１７行は、アトリビュートconstantTypeの値（false）を記述している。第１８行は、アトリビュートconditionTypeの値（pre_cal_condition）を記述している。第１９行は、制約条件（＞１０００）と、その単位（ｍ）と、を記述している。
【００９２】
第２１行及び第２２行は、それぞれ、制約条件クラス５０４のアトリビュートt，vを記述する概要を示す。アトリビュートt，vの記述仕様は、第１５行〜第２０行に示す属性ｌの記述仕様と同様である。
【００９３】
第２３行〜第２８行は、パラメトリック図５０５を記述している。より詳細には、第２３行は、パラメトリック図５０５のクラスを定義し、第２４行は、パラメトリック図５０５の入力パラメータを記述している。第２４行では、各パラメータを定義するアトリビュートのＩＤが用いられている。
【００９４】
第２５行は、パラメトリック図５０５の出力を記述している。第２６行及び第２７は、数式を定義するformulaの例を記述している。第２６行では、MathMLを利用して数式formula1が直接記述され、第２７行では、別途定義された数式（Math1）のＩＤを参照している。図１２の例では、参照する数式Math1は、第３０行で定義されている。数式を定義するformulaは、第２６行と第２７行のいずれかの仕様を利用して記述する。
【００９５】
スクリプトファイル生成部４は、ＭＴＬ４Ｓｙｓと、拡張モデルと、に基づいて、上記のようなスクリプトファイルを自動的に生成することができる。スクリプトファイル生成部４が生成したスクリプトファイルは、動的モデル実行部５により実行される。動的モデル実行部５は、スクリプトファイルを実行する際、スクリプトファイルの実行過程や実行結果を、表示装置１０３に表示させてもよい。
【００９６】
なお、各モデル要素のバージョン情報は省略されてもよい。その際は、ディフォールトのバージョン情報として、例えば、第１行におけるMTLSysのバージョン情報を利用することが出来る。また、スクリプトファイル生成部４は、こうして生成したスクリプトファイルを、表示装置１０３に表示させてもよい。さらに、図１２の例では、スクリプトファイルは、ＸＭＬ（eXtensible Markup Language）形式を利用して記述されているが、ＲＤＦ（Resource Description Framework）などの、他のモデル記述言語（記述形式）を用いて記述されてもよい。
【００９７】
図１３は、ユーザがモデル記述言語を選択可能なＧＵＩの操作画面の一例を示す図である。図１３の操作画面は、表示装置１０３に表示される。ユーザは、入力装置１０２により、ＧＵＩの各種の操作を実行する。ここで、図１３の操作画面を利用したスクリプトファイルの生成方法について説明する。
【００９８】
ユーザは、参照釦１２０１をクリックし、選択可能な拡張モデルを表示させ、表示された拡張モデルの中からスクリプトファイルの生成対象となる拡張モデルを選択する。
【００９９】
次に、ユーザは、選択可能な記述形式（モデル記述言語）の中から、使用するモデル記述言語を選択する。図１３の例では、選択可能なモデル記述言語の一覧が、プルダウンリスト１２０２で表示されている。図１３の例では、選択可能なモデル記述言語として、ＭＴＬ４Ｓｙｓと、ＳｙｓＭＬを記述するＸＭＩ（XML Metadata Interchange）と、が表示されているが、上述の通り、ＲＤＦやＸＭＬが選択可能であってもよい。
【０１００】
そして、ユーザが実行釦１２０３をクリックすると、ユーザに選択されたモデル記述言語に従って、スクリプトファイル生成部４が、図１２に示したようなスクリプトファイルを生成する。生成されたスクリプトファイルは、記憶装置１０５に保存される。なお、図１３において、選択可能な拡張モデルやモデル記述言語は、ディフォールト値が設定されていてもよい。
【０１０１】
（変更分析部６）
変更分析部６は、モデル構築部２が、構築済みの拡張モデルを編集すると、拡張モデルの変更内容を分析する。図１４は、変更分析部６による変更内容の分析処理の一例を示すフローチャートである。
【０１０２】
モデル構築部２が拡張モデルを編集すると、変更分析部６は、まず、変更内容集合｛Ｍ｝を作成する（ステップＳ８０１）。変更内容集合｛Ｍ｝は、変更された全内容（クラス、属性、及びクラス間の関係など）を含む集合である。
【０１０３】
次に、変更分析部６は、変更内容集合｛Ｍ｝に、satisfyGを定義するクラス又は関係が含まれているか判定する（ステップＳ８０２）。ここでいうsatisfyGは、satisfy（満たす関係）またはsatisfyWithCondition（条件付きの満たす関係）のことである。
【０１０４】
変更内容集合｛Ｍ｝に、satisfyGを定義するクラス又は関係が含まれていない場合（ステップＳ８０２のｎｏ）、変更分析部６は、分析処理を終了する。一方、変更内容集合｛Ｍ｝に、satisfyGを定義するクラス又は関係が含まれている場合（ステップＳ８０２のｙｅｓ）、分析処理は、ステップＳ８０３に進む。
【０１０５】
ステップＳ８０３において、変更分析部６は、変更内容集合｛Ｍ｝から、satisfyGが定義されたクラスを抽出し、satisfyG集合φ＝｛cls_1, cls_2,…,cls_n｝を作成する。satisfyG集合φは、抽出されたクラスのＩＤ（cls_i）を含む集合である。
【０１０６】
次に、変更分析部６は、satisfyG集合φから１つのクラスcls_iを選択する（ステップＳ８０４）。
【０１０７】
そして、変更分析部６は、選択したクラスcls_iに、クラスcls_i’があるか判定する（ステップＳ８０５）。ここでいうクラスcls_i’とは、クラスcls_iに対してsatisfyGの関係を定義されたクラスのうち、satisfyG集合φに含まれないクラスのことである。
【０１０８】
クラスcls_i’がない場合（ステップＳ８０５のｎｏ）、分析処理はステップＳ８０７に進む。
【０１０９】
一方、クラスcls_i’がある場合（ステップＳ８０５のｙｅｓ）、変更分析部６は、クラスcls_i’を、変更候補クラス集合｛cls_tbm｝に追加する（ステップＳ８０６）。その後、分析処理は、ステップＳ８０７に進む。
【０１１０】
ステップＳ８０７において、変更分析部６は、satisfyG集合φに含まれる全てのクラスcls_iについて、ステップＳ８０５，Ｓ８０６の処理が終了したか判定する。未処理のクラスcls_iがある場合（ステップＳ８０７のｎｏ）、分析処理はステップＳ８０４に戻り、変更分析部６は、次に処理するクラスcls_iを選択する。一方、全てのクラスcls_iについて、処理が終了した場合（ステップＳ８０７のｙｅｓ）、分析処理はステップＳ８０８に進む。
【０１１１】
ステップＳ８０８において、変更分析部６は、変更候補クラス集合｛cls_tbm｝に、satisfyWithConditionの関係が定義されたクラスがあるか判定する。satisfyWithConditionの関係が定義されたクラスが無かった場合（ステップＳ８０８のｎｏ）、変更分析部６は、分析処理を終了する。一方、satisfyWithConditionの関係が定義されたクラスがあった場合（ステップＳ８０８のｙｅｓ）、分析処理はステップＳ８０９に進む。
【０１１２】
ステップＳ８０９において、変更分析部６は、変更候補クラス集合｛cls_tbm｝から、satisfyWithConditionの関係が定義されたクラスを抽出し、制約条件集合｛Condition_cls｝を作成する。制約条件集合｛Condition_cls｝は、抽出された各クラスのsatisfyWithConditionを定義する制約条件クラスの集合である。
【０１１３】
その後、変更分析部６は、制約条件集合｛Condition_cls｝に含まれ、かつ、変更内容集合｛Ｍ｝に含まれないクラスを抽出し、抽出したクラスを変更候補クラス集合｛cls_tbm｝に追加し（ステップＳ８１１）、分析処理を終了する。
【０１１４】
以上の分析処理により、変更分析部６は、分析結果として、変更候補クラス集合｛cls_tbm｝を出力する。以上の説明からわかるように、変更候補クラス集合｛cls_tbm｝には、拡張モデルの変更によって影響される、関係クラスなどの一般のクラスと、制約条件クラスと、が含まれる。変更分析部６は、これらのクラスを変更対象として自動的に抽出することができる。
【０１１５】
（モデル更新部７）
モデル更新部７は、モデル構築部２により編集された拡張モデルのうち、変更分析部６により抽出された変更対象を更新（変更）する。モデル更新部７は、全ての変更対象を更新してもよいし、ユーザにより選択された変更対象のみを更新してもよい。図１５は、ユーザが更新対象を選択可能なＧＵＩの操作画面の一例を示す図である。図１５の操作画面は、表示装置１０３に表示される。ユーザは、入力装置１０２により、ＧＵＩの各種の操作を実行する。ここで、図１５の操作画面を利用した拡張モデルの更新方法について説明する。
【０１１６】
ユーザは、まず、操作画面に表示された変更候補クラス集合｛cls_tbm｝の中から、更新したいクラスを選択する。図１５の例では、一般のクラス候補９０１と、制約条件クラス候補９０２と、がそれぞれリストとして表示されている。クラス候補９０１には、例えばclass1，class3，class6が含まれている。また、制約条件クラス候補９０２には、例えばCondition_class1，Condition_class3，Condition_classXが含まれている。
【０１１７】
図１５の例では、class1と、class1に関連づけられたCondition_class1と、ユーザにより選択されたCondition_classXと、が選択されている。一般クラスと、制約条件クラスと、はそれぞれユーザにより選択されてもよいし、ユーザにより選択された一般クラス（又は制約条件クラス）に関連づけられた制約条件クラス（又は一般クラス）がモデル更新部７により自動的に選択されてもよい。ユーザは、選択釦９０３をクリックすることにより、選択内容を決定する。
【０１１８】
図１５の操作画面の右側には、ユーザにより選択された更新対象（class1，Condition_class1，Condition_classX）が表示されている。ユーザがこれらの更新対象を選択すると、モデル更新部７は、選択された更新対象を、拡張モデルの編集内容に応じて変更する。図１５の例では、class1と、Condition_class1と、が選択され、変更されている。
【０１１９】
その後、ユーザが更新釦９０４をクリックすると、モデル更新部７は、更新対象の変更内容を、編集された拡張モデルに追加する。これにより、拡張モデルが更新される。この際、モデル更新部７は、更新したクラスのバージョン情報を自動的に更新するのが好ましい。例えば、変更前のバージョンがＮである場合、変更後のクラスのバージョンをＮ＋１にすることが考えられる。また、モデル更新部７は、変更したクラスの下位クラスのバージョン情報を更新してもよい。例えば、変更したクラスの下位クラスのバージョンを全部プラス１にしてもよい。
【０１２０】
（変換ルール生成部８）
変換ルール生成部８は、拡張メタモデルに基づいて、拡張モデルに含まれる要求図、ブロック図、制約条件クラス、及びパラメトリック図を、リレーショナルデータベースに保存するための変換ルールを生成する。図１６及び図１７は、変換ルール生成部８が生成した変換ルールの仕様の一例を示す図である。
【０１２１】
図１６に示すように、要求テーブル（re_tbl）１００１は、拡張メタモデルに従って記述される要求図（RE）を保存する。要求テーブル１００１は、ID，name，description，superRequirement，versionのコラムを有する。IDのコラムには、要求図のＩＤが格納される。nameのコラムには、要求図の名称が格納される。descriptionのコラムには、要求図の説明が格納される。superRequirementのコラムには、要求図が継承関係を有する親要求が格納される。versionのコラムには、要求図のバージョン情報が格納される。
【０１２２】
パラメトリックテーブル（parametric_tbl）１００２は、拡張メタモデルに従って記述されるパラメトリック図（Parametric）を保存する。パラメトリックテーブル１００２は、ID (PK)，name，description，Input，Output，formula， versionのコラムを有する。ID (PK)のコラムには、パラメトリック図のＩＤが格納される。また、ＩＤコラムはプライムキーとして設定することができる。Nameのコラムには、パラメトリック図の名称が格納される。descriptionのコラムには、パラメトリック図の説明が格納される。Inputのコラムには、パラメトリック図の入力に関する情報が格納される。図１６の例では、入力に関する情報として、変数名（val1）と、変数の型（datatype）と、単位（unit）と、が格納されている。Outputのコラムには、パラメトリック図の出力に関する情報が格納される。図１６の例では、出力に関する情報として、変数名（val2）と、変数の型（datatype）と、単位（unit）と、が格納されている。formulaのコラムには、パラメトリック図の計算式が格納される。図１６の例では、計算式はMathMLの形式で格納される。versionのコラムには、パラメトリック図のバージョン情報が格納される。
【０１２３】
図１７に示すように、ブロックテーブル（block_tbl）１００３は、拡張メタモデルに従って記述されるブロック図（block）を保存する。ブロックテーブル１００３は、ID（PK），name，Condition（id，FK），Operation（id，FK），attribute，description，super，versionのコラムを有する。IDのコラムには、ブロック図のＩＤが格納される。また、ＩＤコラムはプライムキーとして設定することができる。nameのコラムには、ブロック図の名称が格納される。Conditionのコラムには、後述する制約条件テーブル１００４のIDが格納される。Operationのコラムには、パラメトリックテーブル１００２のIDが格納される。attributeのコラムには、後述するアトリビュートテーブル１００５のIDのリストが格納される。descriptionのコラムには、ブロック図の説明が格納される。superのコラムには、ブロック図が継承関係を有する親ブロック（super）のIDが格納される。versionのコラムには、ブロック図のバージョン情報が格納される。
【０１２４】
制約条件テーブル（Condition_tbl）１００４は、拡張メタモデルに従って記述される制約条件（Condition）を保存する。制約条件テーブル１００４は、ID（PK），name，description，Attribute，Formula（id，FK），super，versionのコラムを有する。IDのコラムには、制約条件のＩＤが格納される。また、ＩＤコラムはプライムキーとして設定することができる。nameのコラムには、制約条件の名称が格納される。descriptionのコラムには、制約条件の説明が格納される。Attributeのコラムには、アトリビュートテーブル１００５のIDのリスト（List_of_id）が格納される。Formulaのコラムには、パラメトリックテーブル１００２のIDが格納される。superのコラムには、ブロック図が継承関係を有する親ブロック（super）のIDが格納される。versionのコラムには、ブロック図のバージョン情報が格納される。
【０１２５】
アトリビュートテーブル（attribute_tbl）１００５は、拡張メタモデルに従って記述される制約条件及びブロック図に記述するアトリビュートを保存する。アトリビュートテーブル１００５は、ID（PK），name，description，constantType，ConditionType，versionのコラムを有する。IDのコラムには、アトリビュートのＩＤが格納される。また、ＩＤコラムはプライムキーとして設定することができる。nameのコラムには、アトリビュートの名称が格納される。descriptionのコラムには、アトリビュートの説明が格納される。constantTypeのコラムには、制約条件の可変性が格納される。ConditionTypeのコラムには、制約条件の種類が格納される。versionのコラムには、アトリビュートのバージョン情報が格納される。
【０１２６】
（テーブル構築部９）
テーブル構築部９は、上記のような仕様を有する変換ルールに従って、拡張モデルに対応する各種のテーブルを自動的に構築し、構築したテーブルをＤＢ１０に格納する。図１８は、テーブル構築部９により構築された、モデル要素に対応するテーブルの一例を示す図である。図１８のテーブルは、図８の拡張モデルに対応している。
【０１２７】
図１８に示すように、ブロック５０３の定義は、ブロックテーブル１１０１の１行目に格納されている。制約条件クラス５０４の定義は、制約条件テーブル１１０２の１行目に格納されている。制約条件クラス５０４のアトリビュートであるairPressure，lの定義は、それぞれアトリビュートテーブル１１０３の１行目，２行目に格納されている。パラメトリック図５０５の定義は、パラメトリックテーブル１１０４の１行目に格納されている。
【０１２８】
上述の通り、制約条件テーブル１１０２のattributeのコラムには、アトリビュートテーブル１１０３のID（attr1，Attr2）が格納されている。また、制約条件テーブル１１０２のFormulaのコラムには、パラメトリックテーブル１１０４のID（Para_001）が格納されている。
【０１２９】
テーブル構築部９が構築したテーブルは、ＤＢ１０に格納される。なお、ＤＢ１０には、複数の拡張モデルが、テーブルとして格納されてもよい。
【０１３０】
図１９は、ユーザがテーブルを構築可能なＧＵＩの操作画面の一例を示す図である。図１９の操作画面は、表示装置１０３に表示される。ユーザは、入力装置１０２により、ＧＵＩの各種の操作を実行する。ここで、図１９の操作画面を利用したテーブルの構築方法について説明する。
【０１３１】
ユーザは、選択釦１３０１をクリックし、選択可能な拡張モデルのモデル要素（要求図、ブロック図など）を表示させ、表示されたモデル要素の中から、テーブルを構築するモデル要素を選択する。
【０１３２】
図１９の例では、操作画面にはメタモデル表示部１３０２が設けられている。メタモデル表示部１３０２には、１３０１で選択されたモデル要素に対応する拡張メタモデル（例えば、ブロック図の拡張メタモデルなど）が表示される。メタモデル表示部１３０２に表示された拡張メタモデルは、ユーザの操作により編集可能であってもよい。
【０１３３】
次に、ユーザは、構築するテーブルの名称を、テーブル名入力欄１３０３に入力する。図１９の例では、テーブルの名称はblock_tblに指定されている。
【０１３４】
続いて、１３０１で選択したモデル要素に対して、前述の変換ルールに従ってテーブル生成のＳＱＬ文（Structured Query Language）を自動的に生成し、変換ルール欄１３０４において表示と編集をする。変換ルール生成部８は、ユーザにより指定された内容に従って、変換ルールを生成する。また、ユーザにより指定された変換ルールが生成済みの場合、変換ルール欄１３０４に、生成済みの変換ルールが表示されてもよい。さらに、変換ルール欄１３０４に表示された変換ルールは、ユーザの操作により編集可能であってもよい。
【０１３５】
そして、ユーザが保存釦１３０５をクリックすると、テーブル構築部９は、変換ルール欄１３０４に表示された変換ルールに従って、ユーザに選択されたモデル要素に対応するテーブルを構築する。こうして構築されたテーブルは、ＤＢ１０に格納される。
【０１３６】
以上説明した通り、本実施形態に係るシステム設計装置は、既存メタモデルに対して、制約条件を記述する制約条件クラスのメタモデルと、関係クラスに対して、前記制約条件の有無を区別するため、前記制約条件クラスと前記関係クラスとの間の関連（Association）を定義するメタモデルと、バージョン情報のメタモデルと、分解関係クラスのメタモデルと、貢献度クラスのメタモデルなどを、拡張定義することができる。これにより、ＵＭＬやＳｙｓＭＬなどのモデリング言語による記述能力を高めることができる。
【０１３７】
また、上記の拡張定義により、モデルの更新管理や統合設計が容易になるため、システムを効率的に開発したり、開発コストや保守コストを削減したりすることができる。
【０１３８】
なお、本発明は上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素を適宜組み合わせることによって種々の発明を形成できる。また例えば、各実施形態に示される全構成要素からいくつかの構成要素を削除した構成も考えられる。さらに、異なる実施形態に記載した構成要素を適宜組み合わせてもよい。
【符号の説明】
【０１３９】
１：メタモデル定義部、２：モデル構築部、３：モデル記述言語生成部、４：スクリプトファイル生成部、５：動的モデル実行部、６：変更分析部、７：モデル更新部、８：変換ルール生成部、９：テーブル構築部、１０：ＤＢ、１００：コンピュータ、１０１：プロセッサ、１０２：入力装置、１０３：表示装置、１０４：通信装置、１０５：記憶装置
【図１】
2017072969.tif 000003
【図２】
2017072969.tif 000004
【図３】
2017072969.tif 000005
【図４】
2017072969.tif 000006
【図５】
2017072969.tif 000007
【図６】
2017072969.tif 000008
【図７】
2017072969.tif 000009
【図８】
2017072969.tif 000010
【図９】
2017072969.tif 000011
【図１０】
2017072969.tif 000012
【図１１】
2017072969.tif 000013
【図１２】
2017072969.tif 000014
【図１３】
2017072969.tif 000015
【図１４】
2017072969.tif 000016
【図１５】
2017072969.tif 000017
【図１６】
2017072969.tif 000018
【図１７】
2017072969.tif 000019
【図１８】
2017072969.tif 000020
【図１９】
2017072969.tif 000021
【国際調査報告】
2017072969.tif 000022
2017072969.tif 000023