(57)【特許請求の範囲】
【請求項１】
コンピュータに、
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義を含み、ＵＭＬで表記された第１のクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを取得するメタモデル取得ステップと、
前記ソフトウェアに含まれる部品を表すどの部品クラスも前記メタ部品クラスのサブクラスとして表記せよ、という制約条件のもとで、ユーザからの入力に基づいて各部品クラスを定義することにより、前記ソフトウェアを前記メタモデルに適合するようにモデル化したモデルを、各部品クラスを含み前記ＵＭＬで表記される第２のクラス図として生成するクラス図生成ステップと、
各部品クラスから前記メタ部品クラスへの、前記制約条件にしたがって表記された汎化と、前記メタモデルとに基づいて、前記第２のクラス図における各部品クラスが各部品をモデル化したクラスであるという前記第２のクラス図の意味を所定の形式言語により表す意味モデルを生成する意味モデル生成ステップと、
を実行させることを特徴とする意味モデル生成プログラム。
【請求項２】
前記第１のクラス図は、前記部品間の通信のインタフェースをメタモデル化したメタインタフェースクラスの定義をさらに含み、
前記クラス図生成ステップは、
前記部品間の前記通信の前記インタフェースをモデル化したインタフェースクラスを、前記メタインタフェースクラスのサブクラスとして、前記第２のクラス図において定義するインタフェース定義ステップと、
前記インタフェースクラスとの間の関係を用いて、前記部品間の前記通信を前記第２のクラス図において表記するインタフェース表記ステップと、
を含み、
前記意味モデル生成ステップは、前記第２のクラス図における前記インタフェースクラスとの間の前記関係を、前記インタフェースクラスから前記メタインタフェースクラスへの汎化に基づいて、前記部品間の前記インタフェースを介した前記通信を意味する前記所定の形式言語のコードで表現し、前記意味モデルに前記コードを含めるインタフェース解釈ステップを含む、
ことを特徴とする請求項１に記載の意味モデル生成プログラム。
【請求項３】
コンピュータに、
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義と、前記部品間の通信のインタフェースをメタモデル化したメタインタフェースクラスの定義を含み、さらに前記メタ部品クラスに含まれるクラスとしてメタ通信ポートクラスを定義しており、ＵＭＬで表記された第１のクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを取得するメタモデル取得ステップと、
前記ソフトウェアに含まれる部品を表す部品クラスを、前記メタ部品クラスのサブクラスとして定義することにより、前記ソフトウェアを前記メタモデルにしたがってモデル化したモデルを、前記部品クラスを含み前記ＵＭＬで表記される第２のクラス図として生成するクラス図生成ステップであって、
前記部品間の前記通信の前記インタフェースをモデル化したインタフェースクラスを、前記メタインタフェースクラスのサブクラスとして、前記第２のクラス図において定義するインタフェース定義ステップと、
前記第２のクラス図において、前記部品クラスを、前記メタ通信ポートクラスまたは前記メタ通信ポートクラスのサブクラスとして定義される通信ポートクラスのいずれかのオブジェクトである通信ポートオブジェクトを含むように定義する通信ポート定義ステップと、
前記部品クラスに含まれる前記通信ポートオブジェクトから前記インタフェースクラスへの依存を用いて、前記部品間の前記インタフェースを介した前記通信を前記第２のクラス図において表記するインタフェース表記ステップ
を含むクラス図生成ステップと、
前記部品クラスから前記メタ部品クラスへの汎化と前記メタモデルに基づいて、前記第２のクラス図における前記部品クラスが前記部品をモデル化したクラスであるという前記第２のクラス図の意味を所定の形式言語により表す意味モデルを生成する意味モデル生成ステップであって、
前記第２のクラス図における前記インタフェースクラスへの前記依存を、前記インタフェースクラスから前記メタインタフェースクラスへの汎化に基づいて、前記部品間の前記インタフェースを介した前記通信を意味する前記所定の形式言語のコードで表現し、前記意味モデルに前記コードを含めるインタフェース解釈ステップ
を含む意味モデル生成ステップと、
を実行させることを特徴とする意味モデル生成プログラム。
【請求項４】
前記クラス図生成ステップは、
前記部品クラスを新規作成するための第１の指示を受け取り、前記第１の指示を契機として、前記メタ部品クラスのサブクラスを前記部品クラスとして前記第２のクラス図内に作成する部品定義ナビゲーションステップ、または
前記第２のクラス図内に作成された任意の第１のクラスから前記メタ部品クラスへの汎化を追加するための第２の指示を受け取り、前記第２の指示を契機として、前記第１のクラスを前記部品クラスとして定義しなおす部品事後定義ステップ
を含むことを特徴とする請求項１〜３のいずれか１項に記載の意味モデル生成プログラム。
【請求項５】
前記インタフェース定義ステップは、
前記インタフェースクラスを新規作成するための第３の指示を受け取り、前記第３の指示を契機として、前記メタインタフェースクラスのサブクラスを前記インタフェースクラスとして前記第２のクラス図内に作成するインタフェース定義ナビゲーションステップ、または
前記第２のクラス図内に作成された任意の第２のクラスから前記メタインタフェースクラスへの汎化を追加するための第４の指示を受け取り、前記第４の指示を契機として、前記第２のクラスを前記インタフェースクラスとして定義しなおすインタフェース事後定義ステップ
を含むことを特徴とする請求項２または３に記載の意味モデル生成プログラム。
【請求項６】
前記第１のクラス図は、前記部品に特徴を与えるパラメタをメタモデル化したメタパラメタクラスの定義と、実行可能な実体をメタモデル化したメタ実行可能実体クラスの定義をさらに含み、
前記メタ部品クラスが前記メタパラメタクラスを含み得ることを示す集約と、前記メタ部品クラスが前記メタ実行可能実体クラスを含むことを示す集約が、前記第１のクラス図において定義されており、
前記クラス図生成ステップは、
前記部品クラスで定義される属性を前記メタパラメタクラスと対応づけるための第１の所定の表記を、前記第２のクラス図に付加するか否かを、前記ユーザからの入力に基づいて決める第１の決定ステップと、
前記部品クラスで定義される操作を前記メタ実行可能実体クラスと対応づけるための第２の所定の表記を、前記第２のクラス図に付加するか否かを、前記ユーザからの入力に基づいて決める第２の決定ステップ
を含み、
前記意味モデル生成ステップは、
各部品クラスで定義される各属性のうち、前記第１の所定の表記により前記メタパラメタクラスと対応づけられている属性について、当該属性が当該部品に特徴を与えることを示すコードを生成し、該生成したコードを前記意味モデルに含める属性解釈ステップと、
各部品クラスで定義される各操作のうち、前記第２の所定の表記により前記メタ実行可能実体クラスと対応づけられている操作について、当該操作が、外部から当該部品を駆動するために外部から呼び出し可能な、パブリックな操作であることを示すコードを生成し、該生成したコードを前記意味モデルに含める操作解釈ステップ
を含む
ことを特徴とする請求項１または２に記載の意味モデル生成プログラム。
【請求項７】
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義を含み、ＵＭＬで表記された第１のクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを格納する格納手段と、
前記格納手段から前記メタモデルを読み出して、前記ソフトウェアに含まれる部品を表すどの部品クラスも前記メタ部品クラスのサブクラスとして表記せよ、という制約条件のもとで、ユーザからの入力に基づいて各部品クラスを定義することにより、前記ソフトウェアを前記メタモデルに適合するようにモデル化したモデルを、各部品クラスを含み前記ＵＭＬで表記される第２のクラス図として生成するクラス図生成手段と、
各部品クラスから前記メタ部品クラスへの、前記制約条件にしたがって表記された汎化と、前記メタモデルとに基づいて、前記第２のクラス図における各部品クラスが各部品をモデル化したクラスであるという前記第２のクラス図の意味を所定の形式言語により表す意味モデルを生成する意味モデル生成手段と、
を備えることを特徴とする意味モデル生成装置。
【請求項８】
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義と、前記部品間の通信のインタフェースをメタモデル化したメタインタフェースクラスの定義を含み、さらに、前記メタ部品クラスに含まれるクラスとしてメタ通信ポートクラスを定義しており、ＵＭＬで表記された第１のクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを格納する格納手段と、
前記格納手段から前記メタモデルを読み出して、前記ソフトウェアに含まれる部品を表す部品クラスを、前記メタ部品クラスのサブクラスとして定義することにより、前記ソフトウェアを前記メタモデルにしたがってモデル化したモデルを、前記部品クラスを含み前記ＵＭＬで表記される第２のクラス図として生成するクラス図生成手段であって、
前記部品間の前記通信の前記インタフェースをモデル化したインタフェースクラスを、前記メタインタフェースクラスのサブクラスとして、前記第２のクラス図において定義するインタフェース定義手段と、
前記第２のクラス図において、前記部品クラスを、前記メタ通信ポートクラスまたは前記メタ通信ポートクラスのサブクラスとして定義される通信ポートクラスのいずれかのオブジェクトである通信ポートオブジェクトを含むように定義する通信ポート定義手段と、
前記部品クラスに含まれる前記通信ポートオブジェクトから前記インタフェースクラスへの依存を用いて、前記部品間の前記インタフェースを介した前記通信を前記第２のクラス図において表記するインタフェース表記手段
を含むクラス図生成手段と、
前記部品クラスから前記メタ部品クラスへの汎化と前記メタモデルに基づいて、前記第２のクラス図における前記部品クラスが前記部品をモデル化したクラスであるという前記第２のクラス図の意味を所定の形式言語により表す意味モデルを生成する意味モデル生成手段であって、
前記第２のクラス図における前記インタフェースクラスへの前記依存を、前記インタフェースクラスから前記メタインタフェースクラスへの汎化に基づいて、前記部品間の前記インタフェースを介した前記通信を意味する前記所定の形式言語のコードで表現し、前記意味モデルに前記コードを含めるインタフェース解釈手段
を含む意味モデル生成手段と、
を備えることを特徴とする意味モデル生成装置。
【請求項９】
前記第１のクラス図は、前記部品に特徴を与えるパラメタをメタモデル化したメタパラメタクラスの定義と、実行可能な実体をメタモデル化したメタ実行可能実体クラスの定義をさらに含み、
前記メタ部品クラスが前記メタパラメタクラスを含み得ることを示す集約と、前記メタ部品クラスが前記メタ実行可能実体クラスを含むことを示す集約が、前記第１のクラス図において定義されており、
前記クラス図生成手段は、
前記部品クラスで定義される属性を前記メタパラメタクラスと対応づけるための第１の所定の表記を、前記第２のクラス図に付加するか否かを、前記ユーザからの入力に基づいて決める第１の決定手段と、
前記部品クラスで定義される操作を前記メタ実行可能実体クラスと対応づけるための第２の所定の表記を、前記第２のクラス図に付加するか否かを、前記ユーザからの入力に基づいて決める第２の決定手段
を含み、
前記意味モデル生成手段は、
各部品クラスで定義される各属性のうち、前記第１の所定の表記により前記メタパラメタクラスと対応づけられている属性について、当該属性が当該部品に特徴を与えることを示すコードを生成し、該生成したコードを前記意味モデルに含める属性解釈手段と、
各部品クラスで定義される各操作のうち、前記第２の所定の表記により前記メタ実行可能実体クラスと対応づけられている操作について、当該操作が、外部から当該部品を駆動するために外部から呼び出し可能な、パブリックな操作であることを示すコードを生成し、該生成したコードを前記意味モデルに含める操作解釈手段
を含む
ことを特徴とする請求項７に記載の意味モデル生成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア開発でのモデル化プロセスに関する。
【背景技術】
【０００２】
ソフトウェア開発を支援するための様々な技術が開発されている。
例えば、オブジェクト指向言語で記述されたプログラムから、プログラムの構造を容易に理解できるオブジェクト図を出力する装置を実現することを目的とした、次のような技術が知られている。すなわち、ソースプログラムを入力とし、クラス定義情報抽出処理によりクラスの構造が抽出される。そして、クラスメソッド解析処理によりメンバデータの定義位置が決定され、クラス情報が生成され、オブジェクト図出力処理により出力装置を介してオブジェクト図が得られる。
【０００３】
また、図形情報の入力手段を表記法毎に開発する必要がなく、図形情報の入力手段を全表記法で共通化できるようにすることを目的とした、次のような技術も知られている。すなわち、メタモデル格納部がメタモデルを格納し、解析規則格納部が図形情報の解析のための複数の解析規則を格納する。そして、モデル操作部がモデルに含まれる要素等を規定した特定の表記法に従った図形情報を取得し、モデル生成部がメタモデルと図形情報の表記法に対応する解析規則とに基づいて図形情報を解析してモデルを生成する。
【０００４】
さらに、統一されたポリシーに基づくクラス図の作成を支援することを目的とした、次のような技術も知られている。すなわち、仕様書／設計書受付部により、開発対象のソフトウェアに関する作成済みの仕様書／設計書を受け付け、その中からシーケンス図を取り出す。また、クラス生成部により、シーケンス図を機能の種類毎に分類し、分類されたシーケンス図における機能で操作される対象を表す管理情報をクラスとするクラス図を生成する。そして、属性生成部により、シーケンス図の中からメッセージのパラメータを取得し、パラメータを対応するクラスの属性としてクラス図中に追加する。さらに、関連生成部により、属性を追加したクラス図から同じ属性を有するクラスの組を抽出し、それらのクラス間に関連を生成する。以上により、作成ポリシーを統一することができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平９−１８５４９７号公報
【特許文献２】特開２００７−１７２２２８号公報
【特許文献３】特開２００８−２８７３０５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、ソフトウェア開発においては人的能力に頼っている部分もいまだに多く残っており、ソフトウェアの生産性には改善の余地がある。そこで本発明は、ソフトウェア開発でのモデル化プロセスにおいて、ソフトウェアのモデルを表すデータを、ソースコードの自動生成に適合するように生成することで、ソフトウェアの生産性を向上させることを目的とする。
【課題を解決するための手段】
【０００７】
一態様において提供される意味モデル生成プログラムは、コンピュータにメタモデル取得ステップとクラス図生成ステップと意味モデル生成ステップを実行させる。
前記メタモデル取得ステップは、メタモデルを取得するステップである。なお、前記メタモデルは、ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義を含み、ＵＭＬで表記された第１のクラス図により、前記ソフトウェアをメタモデル化して表すものである。
【０００８】
前記クラス図生成ステップは、前記ソフトウェアに含まれる部品を表す部品クラスを、前記メタ部品クラスのサブクラスとして定義することにより、前記ソフトウェアを前記メタモデルにしたがってモデル化したモデルを、前記部品クラスを含み前記ＵＭＬで表記される第２のクラス図として生成するステップである。
【０００９】
前記意味モデル生成ステップは、前記部品クラスから前記メタ部品クラスへの汎化と前記メタモデルに基づいて、前記第２のクラス図における前記部品クラスが前記部品をモデル化したクラスであるという前記第２のクラス図の意味を所定の形式言語により表す意味モデルを生成するステップである。
【発明の効果】
【００１０】
上記意味モデル生成プログラムによれば、「部品クラスは部品をモデル化したクラスである」という意味を、意味モデルが明示している。したがって、上記意味モデル生成プログラムによれば、「どのクラスが何をモデル化しているのかを自動的に判別することができないために、適切なソースコードの自動生成が阻害される」といった問題が解決される。すなわち、上記のようにして生成される意味モデルは、ソースコードの自動生成に適しており、上記意味モデル生成プログラムは、ソフトウェアの生産性を向上させることができる。
【図面の簡単な説明】
【００１１】
【図１】第１実施形態によるソフトウェア開発支援の概要を説明する図である。
【図２】第１のメタモデルを表すＵＭＬのクラス図である。
【図３】第１のメタモデルにしたがう第１のモデルを表すＵＭＬのクラス図である。
【図４】第１実施形態によるＤＳＭ支援装置およびその他の装置を示すブロック図である。
【図５】コンピュータの構成図である。
【図６】第１のメタモデルにしたがう第２のモデルを表すＵＭＬのクラス図である。
【図７】第１と第２のモデルを統合したモデルにより設計されたソフトウェアの全体構造を示すＵＭＬのオブジェクト図である。
【図８】図７のオブジェクト図に対応してソフトウェアの動作を定義するＵＭＬのシーケンス図である。
【図９Ａ】第１と第２のモデルを統合したモデルを表すＸＭＬデータを示す図（その１）である。
【図９Ｂ】第１と第２のモデルを統合したモデルを表すＸＭＬデータを示す図（その２）である。
【図９Ｃ】第１と第２のモデルを統合したモデルを表すＸＭＬデータを示す図（その３）である。
【図９Ｄ】第１と第２のモデルを統合したモデルを表すＸＭＬデータを示す図（その４）である。
【図１０】第１実施形態によるモデル編集処理を説明する図である。
【図１１】第１実施形態による駆動順序定義処理を説明する図である。
【図１２】第１実施形態によるコード生成処理を説明する図である。
【図１３】第２のメタモデルを表すＵＭＬのクラス図である。
【図１４】第２のメタモデルにしたがうモデルを表すＵＭＬのクラス図である。
【図１５】図１４のモデルの利用例を示すＵＭＬのオブジェクト図である。
【図１６】第３のメタモデルを表すＵＭＬのクラス図である。
【図１７】第３のメタモデルにしたがうモデルを表すＵＭＬのオブジェクト図である。
【発明を実施するための形態】
【００１２】
以下、実施形態について、図面を参照しながら詳細に説明する。具体的には、まず図１〜５を参照して、メタモデルおよびモデルの例とともに第１実施形態の概要を説明し、次に図６〜１２を参照して、第１実施形態に関わる各種情報や各種処理の詳細を説明する。その後、図１３〜１７を参照して、他のメタモデルを用いる第２・第３実施形態についても説明する。最後に、その他の実施形態についても説明する。
【００１３】
図１は、第１実施形態によるソフトウェア開発支援の概要を説明する図である。なお、図１はＵＭＬ（Unified Modeling Language）のユースケース図の形式で表現されている。
【００１４】
プロセスＰ１０１において、ソフトウェアのメタモデル１０１と、メタモデル１０１とモデルの間の関連付けのための表記ルール１０２を用いて、ＵＭＬツール１０３とＤＳＭ（Domain-Specific Modeling）支援装置１０４が協働してモデル編集処理を行う。
【００１５】
なお、メタモデル１０１はＵＭＬで表記されており、予め用意されている。メタモデル１０１の具体例は、図２とともに後述する。メタモデル１０１は、他の実施形態では、図１３や１６に示すようなものでもよい。
【００１６】
また、表記ルール１０２は、「ソフトウェアのモデルを表すＵＭＬの図（クラス図やオブジェクト図など）が、メタモデル１０１と適合するためには、どのように表記されていなくてはならないのか」ということを表すルールである。つまり、表記ルール１０２は制約条件の一種である。
【００１７】
表記ルール１０２は、制御ロジックとしてＤＳＭ支援装置１０４内に予め組み込まれていていてもよい。あるいは、表記ルール１０２は、所定の形式のデータとして表現されて記憶装置に格納され、ＤＳＭ支援装置１０４により読み取られてもよい。そして、ＤＳＭ支援装置１０４が、読み取った表記ルール１０２にしたがって動作してもよい。
【００１８】
プロセスＰ１０１の結果、ＵＭＬで表記されたモデル図１０５と、ＸＭＬ（eXtensible Markup Language）で表記されたモデル１０６が出力される。すると、出力されたモデル１０６と、予め用意されたコード生成テンプレート１０７を用いて、プロセスＰ１０２において、コード生成装置１０８がコード生成処理を行う。
【００１９】
その結果、Ｃ、Ｃ＋＋、Ｊａｖａ（登録商標）などの所定のプログラミング言語によるソースコード１０９が出力される。なお、コード生成テンプレート１０７は、ＸＳＬ（eXtensible Stylesheet Language）で表記されており、プログラミング言語に応じて個々に予め用意されている。
【００２０】
第１実施形態によれば、メタモデル１０１と表記ルール１０２が制約条件として利用され、制約条件を満たすモデル図１０５が生成される。また、モデル図１０５が表しているモデルの意味は、メタモデル１０１および表記ルール１０２にしたがって解釈され、ＸＭＬ形式のモデル１０６として表現される。
【００２１】
つまり、モデル１０６は、意味的にはモデル図１０５と等価であり、上記制約条件を満たす。換言すれば、意味モデルとしてのモデル１０６が表す内容は、図形として視覚的にモデル図１０５に表現されている。
【００２２】
そして、コード生成装置１０８は、所望のプログラミング言語に応じた適切なコード生成テンプレート１０７を入力として受け取ることで、制約条件を満たすモデル１０６から、所望のプログラミング言語のソースコード１０９を出力することができる。つまり、第１実施形態のＵＭＬツール１０３とＤＳＭ支援装置１０４は、ソースコード１０９の自動生成に適合するように制約条件のもとでモデル１０６を生成することで、ソフトウェアの生産性を向上させることができる。
【００２３】
続いて、図１に概要を示した第１実施形態が好適に適用される環境および分野について説明する。
第１実施形態によれば、汎用言語であるＵＭＬを使用することの利点を活かしつつＤＳＭによるソフトウェアの開発を行うという、従来は困難であったことが可能となる。以下、第１実施形態の特長の理解を助けるため、ＵＭＬの使用とＤＳＭによるソフトウェア開発ついて説明する。
【００２４】
ＵＭＬを使用したソフトウェア設計には、下記（ａ１）〜（ａ３）のような利点がある。
（ａ１）ＵＭＬは、ソフトウェアの設計者やプログラマ（以下まとめて「ユーザ」ともいう）の多くに受け入れられている。そのため、多くのユーザは既にＵＭＬを使用したソフトウェア開発に関するノウハウや知識を蓄積している。
【００２５】
（ａ２）ＵＭＬによる各種の図を作成するためのエディタも実際に使用されている。上記（ａ１）に述べたノウハウや知識の中には、これらのエディタの操作方法に関するものも含まれる。
【００２６】
（ａ３）ＵＭＬは汎用の言語なので、分野によらず利用可能である。例えば、車両用の組み込みシステム、医療用システム、金融システムなどの分野の違いによらず、ＵＭＬは利用可能である。
【００２７】
しかしながら、ＵＭＬを使用することは、必ずしもソフトウェアの生産性向上に直結する訳ではない。その理由は次のとおりである。
一般に、ソフトウェアはＣ、Ｃ＋＋、Ｊａｖａ（登録商標）等のプログラミング言語で記述され、これらのプログラミング言語はキャラクタベースのテキスト言語である。それに対し、ＵＭＬは非テキスト言語である。
【００２８】
非テキスト言語には、例えば状態遷移を表す表（テーブル）の形でソフトウェアの構造や動作を表現する言語も含まれるが、ＵＭＬは図形の組み合わせでソフトウェアの構造や動作を表現する図形言語である。ＵＭＬ等の非テキスト言語をソフトウェアの設計において利用する場合においても、結局はテキスト言語のソースコードが作成される。
【００２９】
しかし、従来の設計手法にしたがって非テキスト言語（すなわち図形や表）で表現された内容は、ソフトウェアを実装するための参照情報として存在するにすぎず、ソースコードを自動生成するには情報不足であった。そのため、従来は、たとえソフトウェア開発においてＵＭＬが利用されているとしても、実際のソースコードを得るにはプログラマが手作業を行う必要があり、人的能力に依存する部分が残っていた。すなわち、ＵＭＬの使用が、それだけで必ずしもソフトウェアの生産性や品質の著しい向上をもたらすとは限らない。
【００３０】
このように、ＵＭＬには様々な利点があるものの、ＵＭＬの使用が必ずしも生産性や品質の著しい向上に結びつくとは限らない。そこで、ソフトウェア開発の別の手法として、ＤＳＭが提唱されている。
【００３１】
ＤＳＭは、ソフトウェア開発の対象を、特定のドメイン（例えば車両用、医療用、金融用などの特定の分野）に絞り込む手法である。ＤＳＭでは、テキスト言語によるソースコードを自動的に生成するための情報を十分に含むように、当該特定のドメインに特化して、図形や表などの非テキスト言語が定義される。
【００３２】
そして、ＤＳＭでは、ドメイン固有の非テキスト言語（つまりDomain-Specific Language；ＤＳＬ）により、特定のドメイン用のソフトウェアの設計に関わる情報が表現される。ドメインを絞り込むことで、ドメイン固有の非テキスト言語の記述能力を、テキスト言語によるソースコードの自動生成が可能なレベルにまで引き上げられるので、ＤＳＭによればソースコードの自動生成が可能である。
【００３３】
ところが、ＤＳＭには下記（ｂ１）〜（ｂ５）のような欠点がある。
（ｂ１）ドメイン固有の非テキスト言語を編集するには、市販の汎用エディタ（例えば汎用言語であるＵＭＬ用のエディタ）を利用することができないため、ドメイン固有のエディタが必要である。
【００３４】
（ｂ２）ドメイン固有のエディタは、汎用品ではなく専用品であるがゆえに、エディタ自体の開発に多額の費用がかかる。
【００３５】
（ｂ３）ドメイン固有の非テキスト言語の文法（シンタックス）およびドメイン固有のエディタの操作方法を、ユーザがドメインごとに習得する必要があるため、時間的・金銭的なコストがかかる。
【００３６】
（ｂ４）ユーザは、ＵＭＬ等の汎用的な非テキスト言語を利用した開発のノウハウを蓄積しているかもしれないが、汎用的な非テキスト言語に関して蓄積された知識やノウハウは、ドメイン固有の非テキスト言語に直接適用可能なものではない。
【００３７】
（ｂ５）例えば、ＵＭＬを用いて設計された既存のソフトウェアと類似する部分を含む新規ソフトウェアをＤＳＭにより開発しようとする場合であっても、既存のソフトウェアのために作成された資産（ＵＭＬで記述された設計情報など）は流用不能である。そのため、既存の資産を活かすことができず、既存の資産を移行するための費用もかかってしまう。
【００３８】
ここで、ＤＳＭの上記（ｂ１）〜（ｂ５）の欠点はすべて汎用性のなさに起因することに注目すると、ＵＭＬなどの汎用的な言語を利用してＤＳＭによるソフトウェア開発を行うことが可能になれば、ＵＭＬとＤＳＭの双方の利点を活かせると期待される。つまり、既存の資源（ユーザの知識やノウハウ、エディタ、設計情報など）を活かしつつ、ＤＳＭによるソースコードの自動生成によって、ソフトウェア開発の生産性を向上させ、ソフトウェアの品質を安定して高く保つことができるようになる、と期待される。第１実施形態の目的の１つは、このような期待を実現することである。
【００３９】
ＵＭＬとＤＳＭの両立のための具体的手法としては、第１実施形態に対する比較例として、例えば、ＵＭＬプロファイル技術によりＵＭＬを拡張し、ドメイン固有の意味をクラスに付与するために、クラスに対してステレオタイプを指定することも考えられる。
【００４０】
この比較例によれば、上記（ｂ１）で述べたような専用のエディタの代用品として既存のＵＭＬエディタを利用することができる。また、ソフトウェア設計者は、ＵＭＬの利点を活かしつつ、ステレオタイプに基づいてＤＳＭによるソフトウェア設計を行うことができる。つまり、この比較例によれば、上記（ｂ１）〜（ｂ５）の欠点を克服することが可能である。
【００４１】
しかしながら、上記比較例には、「代償として、設計の自由度が奪われてしまう」という、新たな欠点が生じる。つまり、上記比較例では、ＤＳＭによる設計のためにステレオタイプが利用されているので、設計者が他の目的でステレオタイプをクラスに付加して利用することができなくなってしまい、その分、設計の自由度がなくなってしまう。
【００４２】
それに対し第１実施形態では、ステレオタイプとは別の仕組み（具体的にはメタモデル１０１と表記ルール１０２）によって、クラスの意味を判別可能とし、ＵＭＬを使ったＤＳＭによる設計を可能としている。したがって、第１実施形態によれば、ユーザは任意の目的のためにステレオタイプをクラスに付加することができ、設計の自由度が保たれる。また、第１実施形態もＵＭＬを利用するものなので、上記（ｂ１）〜（ｂ５）の欠点は克服される。
【００４３】
第１実施形態は、ＤＳＭによる設計にだけ適用可能なものではないが、上記のとおりＵＭＬとＤＳＭの両立のための具体的手法の一例である。したがって、第１実施形態によれば、上記（ａ１）〜（ａ３）のようなＵＭＬの利点や既存資産を活かしつつ、ＤＳＭによるソフトウェア設計を可能とすることで、ソフトウェアの自動生成を可能とすることができる。
【００４４】
その結果、第1実施形態においては、ソフトウェアの生産性向上・品質向上・品質安定化といった効果が得られる。また、上記比較例と比べると、第１実施形態にはさらに、「上記効果を奏するために設計の自由度を犠牲にせずに済む」という、有利な特徴もある。
【００４５】
さて、以上のような利点を有する第１実施形態について、以下ではより詳しく説明していく。
まず、図２と図３を参照して、図１のメタモデル１０１と表記ルール１０２の具体例を説明する。図２は、第１のメタモデルを表すＵＭＬのクラス図であり、図３は、第１のメタモデルにしたがう第１のモデルを表すＵＭＬのクラス図である。
【００４６】
なお、以下では表記の簡略化のため、「ＸＸＸ」という名前のクラスを「『ＸＸＸ』クラス」と呼び、「ＹＹＹ」という名前のオブジェクトを「『ＹＹＹ』オブジェクト」と呼ぶことがある。
【００４７】
図２に示す第１のメタモデル１０１ａは、予め用意される図１のメタモデル１０１の一例であり、ＵＭＬのクラス図の形で図２に図示されている。
第１のメタモデル１０１ａは、ソフトウェアが含む部品（ソフトウェア・コンポーネント）をメタモデル化したクラス（以下、一般名称として「メタ部品クラス」という）の定義を含む。また、第１のメタモデル１０１ａは、２つの部品間の通信のインタフェースをメタモデル化したクラス（以下、一般名称として「メタインタフェースクラス」という）の定義も含む。また、以下では部品とインタフェースをモデル化したクラスをそれぞれ、一般名称として「部品クラス」および「インタフェースクラス」ということもある。
【００４８】
なお、図２では、各クラスの属性やメソッドは適宜省略されている。また、図２では、各属性と各関係（relationship）の可視性（visibility）として、それぞれプライベートであることを示す「-」とパブリックであることを示す「+」が指定されているが、可視性は、実施形態に応じて適宜指定することができる。
【００４９】
具体的には、第１のメタモデル１０１ａは、以下の各クラスの定義を含む。
ソフトウェアの部品のメタモデル化のために、「ComponentType」クラス２０１と「CompositionType」クラス２０２と「ComponentPrototype」クラス２０３が定義されている。「ComponentType」クラス２０１と「CompositionType」クラス２０２には、メタモデルで定義されたクラスであることを示す<<KeyElement>>というステレオタイプが付けられている。
【００５０】
なお、第１実施形態では、第１のメタモデル１０１ａ内のいくつかの基本的なクラスに<<KeyElement>>というステレオタイプを付加することで、コード生成装置１０８がコード生成時に第１のメタモデル１０１ａを解釈しやすいようにしている。つまり、図１のプロセスＰ１で、メタモデル１０１と表記ルール１０２にしたがうモデル１０６からソースコード１０９を生成するとき、コード生成装置１０８は、モデル１０６と結び付けられたメタモデル１０１の解釈も行う。その際に、<<KeyElement>>というステレオタイプは、コード生成装置１０８に対して解釈の手がかりを与える。
【００５１】
なお、メタモデルは個々のユーザが定義するものではない。つまり、図２の各クラスは、個々のユーザが定義するものではない。したがって、第１のメタモデル１０１ａに含まれるクラスにステレオタイプが付与されていても、ユーザの設計の自由度を束縛することにはならない。
【００５２】
「CompositionType」クラス２０２は上記メタ部品クラスの一例である。「CompositionType」クラス２０２のスーパクラスである「ComponentType」クラス２０１は、メタ部品クラスをさらに抽象化したアブストラクトクラスであるから、メタ部品クラスの一種であるとも言える。「ComponentType」クラス２０１には、複数のインスタンスを持ってもよいか否かを示す「supportMultipleInstantiation」という名前のブール（boolean）型の変数が、属性として定義されている。「ComponentPrototype」クラス２０３は、部品間の入れ子関係のメタモデル化のために定義されている。
【００５３】
また、部品がパラメタを有してもよいことをメタモデル化するために、「ConfigParam」クラス２０４が定義されている。パラメタには名前があり、値が設定されることをメタモデル化して、「ConfigParam」クラス２０４には、「name」という名前の文字列（string）型の変数と、「value」という名前の変数が、属性として定義されている。パラメタの型は、ユーザにより定義される個々のクラスにおいて任意に設定されうるので、第１のメタモデル１０１ａ内の「ConfigParam」クラス２０４内では「value」属性の型は指定されていない。
【００５４】
そして、ソフトウェアの部品は実行可能な部品であるということをメタモデル化するために、実行可能な実体（エンティティ）をメタモデル化した「RunnableEntity」クラス２０５が定義されている。そして、実行可能な実体には当該実体を呼び出すためのシンボルが割り当てられることのメタモデルとして、「RunnableEntity」クラス２０５では、「symbol」という名前の文字列型の変数が属性として定義されている。
【００５５】
また、タスクが部品を駆動することをメタモデル化するために、「Task」クラス２０６と「RunnableConnector」クラス２０７が定義されている。「Task」クラス２０６にも、第１のメタモデル１０１ａ中で定義されたクラスであることを示すための<<KeyElement>>というステレオタイプが付加されている。
【００５６】
タスクが所定の周期で部品を駆動する能力があることのメタモデルとして、「Task」クラス２０６には、上記所定の周期を示す「elapse」という名前の整数型の変数が属性として定義されている。また、タスクが部品を駆動する最初のタイミングが任意に指定されうることのメタモデルとして、上記最初のタイミングを示す「initTimer」という名前の整数型の変数も、「Task」クラス２０６の属性として定義されている。
【００５７】
また、第１のメタモデル１０１ａにおいて部品間の通信は、通信のインタフェースと、部品が備える通信用の入出力ポートと、入出力ポート間の接続をそれぞれメタモデル化することで、メタモデル化されている。なお、第１実施形態において、部品間の「通信」とは、ソフトウェアの部品間でのメッセージパッシング、すなわちデータ入出力を意味する。また、「ポート」も、物理的存在のことではなく、ソフトウェア上の仮想的なポートを意味する。同様に、「インタフェース」も、物理的存在ではなく、「通信」におけるデータ形式を意味し、ソフトウェア上のインタフェースのことを指している。
【００５８】
具体的には、第１のメタモデル１０１ａにおいて、インタフェースのメタモデル化のために、「Interface」クラス２０８と「SenderReceiverInterface」クラス２０９が定義されている。「SenderReceiverInterface」クラス２０９は、<<KeyElement>>というステレオタイプが付けられており、上記メタインタフェースクラスの一例である。「Interface」クラス２０８は、「Interface」クラス２０８を汎化したアブストラクトクラスであるから、メタインタフェースクラスの一種であるとも言える。
【００５９】
また、上記のとおりインタフェースはデータ形式のことであり、より具体的には、個々のデータ要素の集合体である。そこで、インタフェースに含まれる個々のデータ要素をメタモデル化した「DataElementPrototype」クラス２１０も定義されている。
【００６０】
また、部品が他の部品と通信するときのソフトウェア上の仮想的な入出力ポートは、「Port」クラス２１１としてメタモデル化されている。そして、「Port」クラス２１１には２つのサブクラスがある。１つは、他の部品からのメッセージを受ける入力ポートをメタモデル化した「RequesterPort」クラス２１２であり、もう１つは、他の部品へのメッセージを送り出す出力ポートをメタモデル化した「ProviderPort」クラス２１３である。
【００６１】
さらに、ポート間の接続は「Connecter」クラス２１４としてメタモデル化されている。なお、「Connecter」クラス２１４には２つのサブクラスがある。
１つは、入れ子関係にない部品同士のポート間の接続をメタモデル化した「AssemblyConnector」クラス２１５である。もう１つは、入れ子関係にある外部部品と内部部品（換言すれば親部品と子部品）のポート間の接続をメタモデル化した「DelegateConnector」クラス２１６である。
【００６２】
また、上記の各クラス間には、以下のような関係が定義されている。図１には、各関係に適宜ロール名も付けて図示している。なお、関連（association）を示す線における矢印は、誘導可能性（navigability）を示し、換言すれば、参照の方向を示す。
【００６３】
汎化（generalization）２５１は、「ComponentType」クラス２０１が「CompositionType」クラス２０２のスーパクラスであることを示す。関連２５２は、「ComponentPrototype」クラス２０３が「ComponentType」クラス２０１を「typeRef」というロール名で参照することを示し、多重度は「1」である。また、多重度が「0..*」の集約（aggregation）２５３は、「CompositionType」クラス２０２が、「component」というロール名で「ComponentPrototype」クラス２０３を任意の個数含みうることを示す。
【００６４】
また、多重度が「0..*」の集約２５４は、「ComponentType」クラス２０１が「ConfigParam」クラス２０４を任意の個数含みうることを示す。そして、多重度が「1..*」の集約２５５は、「ComponentType」クラス２０１が「RunnableEntity」クラス２０５を１つ以上の任意の個数含むことを示す。つまり、集約２５４と集約２５５は、部品がパラメタを含みうることと、部品が実行可能であることをメタモデル化したものである。
【００６５】
そして、実行可能な実体は、他の実行可能な実体を呼び出したり自分自身を再帰的に呼び出したりすることができる。このことをメタモデル化したものが、「RunnableEntity」クラス２０５から「RunnableEntity」クラス２０５自身への、「call」というロール名での参照を表す関連２５６である。
【００６６】
そして、タスクが部品を呼び出して駆動することは、タスクと部品との間の接続を表す集約２５７と関連２５８によりメタモデル化される。具体的には、集約２５７は、「Task」クラス２０６が１つ以上の任意の個数の「RunnableConnector」クラス２０７を含むことを示す、多重度が「1..*」の集約である。また、関連２５８は、「RunnableConnector」クラス２０７が「RunnableEntity」クラス２０５を「runnable」というロール名で参照することを示す、多重度が「1」の関連である。集約２５７と関連２５８により、１つのタスクが１つ以上の部品のそれぞれを呼び出して駆動することがメタモデル化されている。
【００６７】
また、部品がポートを持ちうることのメタモデルとして、多重度が「0..*」の集約２５９は、「ComponentType」クラス２０１が「Port」クラス２１１を含みうることを示す。「ComponentType」クラス２０１にとっての「Port」クラス２１１のロール名は「ports」であり、「Port」クラス２１１にとっての「ComponentType」クラス２０１のロール名は「component」である。
【００６８】
汎化２６０と汎化２６１はそれぞれ、「RequesterPort」クラス２１２と「ProviderPort」クラス２１３が「Port」クラス２１１のサブクラスであることを示す。
多重度が「1」の関連２６２は、「Port」クラス２１１が「interfaceRef」というロール名で「Interface」クラス２０８を参照することを示す。関連２６２は、２つのポート間の通信が、当該２つのポートに適合する所定のインタフェースによって行われることをメタモデル化したものである。
【００６９】
そして、汎化２６３は、「Interface」クラス２０８が「SenderReceiverInterface」クラス２０９のスーパクラスであることを示す。
また、多重度が「0..*」の合成集約（composition）２６４は、「SenderReceiverInterface」クラス２０９が「DataElementPrototype」クラス２１０を任意の個数含みうることを示す。すなわち、合成集約２６４は、インタフェースが個々のデータ要素の集合体であることをメタモデル化したものである。
【００７０】
なお、「DataElementPrototype」クラス２１０にとっての「SenderReceiverInterface」クラス２０９は「interface」というロール名を持つ。また、「SenderReceiverInterface」クラス２０９にとっての「DataElementPrototype」クラス２１０は「dataElement」というロール名を持つ。
【００７１】
そして、ポート間の接続に関しては、以下のような関係が定義されている。すなわち、汎化２６５と汎化２６６はそれぞれ、「AssemblyConnector」クラス２１５と「DelegateConnector」クラス２１６が「Connecter」クラス２１４のサブクラスであることを示す。
【００７２】
また、いずれも多重度が「0..*」の集約２６７と集約２６８は、「CompositionType」クラス２０２が「AssemblyConnector」クラス２１５と「DelegateConnector」クラス２１６をそれぞれ任意の個数含みうることを示す。集約２６７と集約２６８は、部品同士が接続されうること（すなわち部品同士が通信可能であること）をメタモデル化したものである。
【００７３】
また、それぞれ多重度が「1」の関連２６９と関連２７０は、「AssemblyConnector」クラス２１５が示す接続を、当該接続の両端のポートに対応付ける。つまり、関連２６９は、部品間の通信のための接続を示す「AssemblyConnector」クラス２１５が、通信におけるデータの出力元のポートとして、「Port」クラス２１１を「pPortRef」というロール名で参照することを示している。同様に、関連２７０は、「AssemblyConnector」クラス２１５が、通信におけるデータの入力先のポートとして「Port」クラス２１１を「rPortRef」というロール名で参照することを示している。
【００７４】
同様に、それぞれ多重度が「1」の関連２７１と関連２７２は、「DelegateConnector」クラス２１６が示す接続を、当該接続の両端のポートに対応付ける。つまり、関連２７１は、入れ子関係にある外部部品と内部部品の間の接続を示す「DelegateConnector」クラス２１６が、内部部品側のポートとして、「Port」クラス２１１を「innerPortRef」というロール名で参照することを示している。同様に、関連２７２は、「DelegateConnector」クラス２１６が、外部部品側のポートとして、「Port」クラス２１１を「outerPortRef」というロール名で参照することを示している。
【００７５】
以上のとおり、第１のメタモデル１０１ａによれば、部品をメタモデル化した「CompositionType」クラス２０２は「ComponentType」クラス２０１のサブクラスである。よって、「CompositionType」クラス２０２は、「RunnableEntity」クラス２０５を含み、「ConfigParam」クラス２０４と「Port」クラス２１１を含みうる。
【００７６】
つまり、第１のメタモデル１０１ａは、部品は駆動可能であること、部品はパラメタを含みうること、および部品は他の部品と通信するためのポートを含みうることを表している。そして、部品が含みうるポートとは、具体的には、「RequesterPort」クラス２１２に対応する入力ポートか、「ProviderPort」クラス２１３に対応する出力ポートである。
【００７７】
また、第１のメタモデル１０１ａは、いくつかのデータ要素の集合体として定義されるインタフェースを、「SenderReceiverInterface」クラス２０９と「DataElementPrototype」クラス２１０によりメタモデル化している。そして、「SenderReceiverInterface」クラス２０９を汎化した「Interface」クラス２０８を「Port」クラス２１１が参照していることは、２つのポート間の通信が、何らかの所定のインタフェースを介して行われることをメタモデル化したものである。
【００７８】
また、各部品は、入れ子関係にない他の部品との間がポートを介して接続されるかもしれない。このことは、「CompositionType」クラス２０２が「AssemblyConnector」クラス２１５を含みうると示す集約２６７により、メタモデル化されている。
【００７９】
さらに、部品同士の入れ子関係が可能であるということが次のようにメタモデル化されている。すなわち、部品をメタモデル化した「CompositionType」クラス２０２を汎化した「ComponentType」クラス２０１を「ComponentPrototype」クラス２０３が参照しており、その「ComponentPrototype」クラス２０３が「CompositionType」クラス２０２に含まれることを集約２５３が示す。これにより、外部部品に内部部品が含まれる入れ子関係が可能であるということがメタモデル化される。
【００８０】
そして、外部部品と内部部品それぞれのポート間が接続されることで、外部部品と内部部品との間の通信が可能であることは、任意の部品同士がポート間の接続により通信可能であることと同様である。
【００８１】
つまり、外部部品と内部部品それぞれのポート間の接続は、「DelegateConnector」クラス２１６によりメタモデル化されている。外部部品と内部部品がポートを介して接続されうることは、「CompositionType」クラス２０２が「DelegateConnector」クラス２１６を含みうることを示す集約２６８により、メタモデル化されている。
【００８２】
続いて、図１のメタモデル１０１として図２の第１のメタモデル１０１ａが使われる場合の、図１のモデル図１０５の具体例を、図３を参照して説明する。図３に示すのは、第１のメタモデル１０１ａにしたがうモデル図１０５ａであり、具体的には、第１実施形態の表記ルール１０２にしたがって拡張されたＵＭＬのクラス図である。なお、以下では、拡張されたクラス図およびオブジェクト図のことも、単に「クラス図」および「オブジェクト図」という。
【００８３】
なお、後述するように、モデル図１０５はクラス図だけに限られず、オブジェクト図やシーケンス図などでもよい。また、複数のモデル図１０５により１つのモデルが表されてもよい。
【００８４】
モデル図１０５ａは、図１のプロセスＰ１０１の結果として作られる。詳細は図１０とともに後述するが、プロセスＰ１０１は、ＵＭＬツール１０３とＤＳＭ支援装置１０４が協働して、制約条件のもとでユーザからの指示に応じてソフトウェアのモデルを編集する処理である。プロセスＰ１０１でＵＭＬツール１０３とＤＳＭ支援装置１０４は、編集したモデルを、ＵＭＬデータであるモデル図１０５、およびＸＭＬデータであるモデル１０６の形で出力する。つまり、図３のモデル図１０５ａは、制約条件を満たすクラス図である。
【００８５】
具体的には、図３のモデル図１０５ａは、第１のメタモデル１０１ａに含まれる「CompositionType」クラス２０２と「SenderReceiverInterface」クラス２０９を含む。なお、図３では、第１のメタモデル１０１ａが「メタモデル」という名のパッケージに含まれるものとして、「メタモデル::CompositionType」のようにパスを使ってクラス名を表現している。
【００８６】
モデル図１０５ａは、ユーザ定義の２つのクラス、すなわち、「部品A」クラス３０１と「インタフェースA」クラス３０２を含む。「部品A」クラス３０１は、「受信ポート」および「送信ポート」という名前の２つのポート３０３と３０４を含む。
【００８７】
なお、以下ではポート３０３と３０４をそれぞれ「『受信ポート』ポート」と「『送信ポート』ポート」という。同様に、「ＺＺＺ」という名前でインスタンス化された、「Port」クラス２１１のサブクラスのオブジェクトを「『ＺＺＺ』ポート」という。
【００８８】
第１実施形態において、第１のメタモデル１０１ａにおける「RequesterPort」クラス２１２のオブジェクトは、図３の「受信ポート」ポート３０３のように、矩形の中に逆Ｖ字を書いた記号で表記される。そして、第１のメタモデル１０１ａにおける「ProviderPort」クラス２１３のオブジェクトは、図３の「送信ポート」ポート３０４のように、矩形の中に黒い三角形を描いた記号で表記される。
【００８９】
また、モデル図１０５ａでは、「部品A」クラス３０１が「CompositionType」クラス２０２のサブクラスであることを示す汎化３０５が定義されている。同様に、モデル図１０５ａでは、「インタフェースA」クラス３０２が「SenderReceiverInterface」クラス２０９のサブクラスであることを示す汎化３０６も定義されている。
【００９０】
さらに、モデル図１０５ａでは、「受信ポート」ポート３０３から「インタフェースA」クラス３０２への依存３０７と、「送信ポート」ポート３０４から「インタフェースA」クラス３０２への依存３０８が定義されている。
【００９１】
以上のような内容を持つモデル図１０５ａは、図２の第１のメタモデル１０１ａおよび図１の表記ルール１０２に適合する。換言すれば、モデル図１０５ａは、第１のメタモデル１０１ａにしたがって作成されたモデルを表すＵＭＬのクラス図であり、表記ルール１０２が表す制約条件を満たしている。具体的には以下の（ｃ１）〜（ｃ７）のとおりである。
【００９２】
（ｃ１）表記ルール１０２は、「部品をモデル化したクラスは、『CompositionType』クラス２０２のサブクラスとして表記せよ」というルールを含む。モデル図１０５ａは表記ルール１０２にしたがって表記されている。
【００９３】
すなわち、「部品A」クラス３０１が「CompositionType」クラス２０２のサブクラスであることが、汎化３０５の線によって図３のクラス図上で表記されている。その結果、モデル図１０５ａでは、「『部品A』クラス３０１は、（インタフェースなどではなく）部品をモデル化したクラスである」という意味が示されている。
【００９４】
（ｃ２）第１のメタモデル１０１ａによれば、図２に示したとおり、「ComponentType」クラス２０１とそこから派生するクラスは、「Port」クラス２１１を含みうる。よって、モデル図１０５ａにおいて、「部品A」クラス３０１が「受信ポート」ポート３０３と「送信ポート」ポート３０４を含むことは、図２の第１のメタモデル１０１ａと適合している。
【００９５】
（ｃ３）表記ルール１０２は、「インタフェースをモデル化したクラスは、『SenderReceiverInterface』クラス２０９のサブクラスとして表記せよ」というルールを含む。モデル図１０５ａは表記ルール１０２にしたがって表記されている。
【００９６】
すなわち、「インタフェースA」クラス３０２が「SenderReceiverInterface」クラス２０９のサブクラスであることが、汎化３０６の線によって図３のクラス図上で表記されている。その結果、モデル図１０５ａでは、「『インタフェースA』クラス３０２は、（部品などではなく）インタフェースをモデル化したクラスである」という意味が示されている。
【００９７】
（ｃ４）表記ルール１０２は、「あるインタフェースを介したポート間の通信は、通信の両端のポートに相当する２つのオブジェクトから、同じ１つのインタフェースのクラスへの依存により表記せよ」というルールを含む。モデル図１０５ａは表記ルール１０２にしたがって表記されている。
【００９８】
つまり、「部品A」クラス３０１の「受信ポート」ポート３０３への入力が、「インタフェースA」クラス３０２によりモデル化されるインタフェースを介して行われるということが、モデル図１０５ａでは依存３０７により表記されている。同様に、「部品A」クラス３０１の「送信ポート」ポート３０４からの出力が、「インタフェースA」クラス３０２によりモデル化されるインタフェースを介して行われるということが、モデル図１０５ａでは依存３０８により表記されている。
【００９９】
したがって、「部品A」クラス３０１のインスタンス間の通信が、「インタフェースA」クラス３０２によりモデル化されているインタフェースを介して行われるということが、モデル図１０５ａにおいては依存３０７と３０８により表されている。
【０１００】
（ｃ５）表記ルール１０２は、「部品をモデル化したクラス内でユーザが定義した属性に対し、第１のメタモデル１０１ａの『ConfigParam』クラス２０４と同名の<<ConfigParam>>というステレオタイプを付加してもよい」というルールを含む。そして、表記ルール１０２は、「<<ConfigParam>>というステレオタイプが付加された属性は、当該部品を利用する際に当該部品に特徴を与えるパラメタであることを意味する」という、意味の解釈に関するルールも含む。
【０１０１】
モデル図１０５ａは表記ルール１０２にしたがって表記されており、「部品A」クラス３０１において、ユーザが定義した「パラメタ」という名前の整数型の属性には、<<ConfigParam>>というステレオタイプが付加されている。なお、「部品A」クラス３０１自体に対してステレオタイプが付加される訳ではないので、ユーザは、「部品A」クラス３０１に任意のステレオタイプを付加する自由を依然として持っている。
【０１０２】
（ｃ６）表記ルール１０２は、「部品をモデル化したクラス内でユーザが定義したパブリックな操作に対し、第１のメタモデル１０１ａの『RunnableEntity』クラス２０５と同名の<<RunnableEntity>>というステレオタイプを付加してもよい」というルールを含む。
【０１０３】
そして、表記ルール１０２は、「<<RunnableEntity>>というステレオタイプが付加された操作は、当該部品を駆動するために外部のタスクから呼び出し可能なパブリックな操作である」という、意味の解釈に関するルールも含む。具体的には、表記ルール１０２によれば、<<RunnableEntity>>というステレオタイプが付加された操作は「RunnableEntity」クラス２０５のインスタンスとして解釈される。
【０１０４】
モデル図１０５ａは表記ルール１０２にしたがって表記されており、「部品A」クラス３０１において、ユーザが定義した「実行ポイント」という名前の、返り値を持たない関数には、<<RunnableEntity>>というステレオタイプが付加されている。なお、「部品A」クラス３０１自体に対してステレオタイプが付加される訳ではないので、ユーザは、「部品A」クラス３０１に任意のステレオタイプを付加する自由を依然として持っている。
【０１０５】
（ｃ７）第１のメタモデル１０１ａによれば、図２に示したとおり、「SenderReceiverInterface」クラス２０９が「DataElementPrototype」クラス２１０を含みうる。
よって、モデル図１０５ａにおいて、「SenderReceiverInterface」クラス２０９のサブクラスである「インタフェースA」クラス３０２が２つのデータ要素を属性として含むことは、第１のメタモデル１０１ａと適合している。つまり、「インタフェースA」クラス３０２の属性として定義された「要素1」および「要素2」という名前の整数型の２つの属性は、メタモデルにおける「DataElementPrototype」クラス２１０が、モデルにおいてインスタンス化されたものである。
【０１０６】
以上の（ｃ１）〜（ｃ７）のように、表記ルール１０２は、メタモデル１０１にしたがったモデル図１０５における表記の文法（シンタックス）を規定する。また、メタモデル１０１と表記ルール１０２は、当該文法にしたがって表記されたＵＭＬの図の意味（セマンティクス）も規定している。
【０１０７】
そして、図１のプロセスＰ１０１において、ＵＭＬツール１０３とＤＳＭ支援装置１０４は協働して、上記の（ｃ１）〜（ｃ７）で説明したように制約条件に適合するようにモデル図１０５を作成する。以下、図４を参照して、ＵＭＬツール１０３、ＤＳＭ支援装置１０４、およびコード生成装置１０８についてさらに詳しく説明する。
【０１０８】
図４は、第１実施形態によるＤＳＭ支援装置およびその他の装置を示すブロック図である。図４には、図１のＵＭＬツール１０３、ＤＳＭ支援装置１０４、コード生成装置１０８と、その他の装置が図示されている。
【０１０９】
図４において、入力装置４０１は、キーボード、マウス等のポインティングデバイス、タッチパネル、マイクなど、ユーザからの入力を受け付けるための装置である。また、出力装置４０２は、ＵＭＬの各種の図（クラス図、オブジェクト図、シーケンス図など）の図形を表示するディスプレイや、これらの図を印刷するプリンタなどの装置である。
【０１１０】
ＵＭＬツール１０３は、入力装置４０１および出力装置４０２と接続された（あるいは入力装置４０１と出力装置４０２を備える）コンピュータがプログラムを実行することで実現される。
【０１１１】
具体的には、ＵＭＬツール１０３は、入力装置４０１および出力装置４０２との間のユーザインタフェースを提供する。そして、ＵＭＬツール１０３は、入力装置４０１とユーザインタフェースを介してユーザから与えられる指示に応じて、ＵＭＬの各種の図（クラス図、オブジェクト図、シーケンス図など）を出力装置４０２に出力する。ＵＭＬツール１０３は、例えば上記（ａ２）で述べたのと同様のエディタであってもよい。
【０１１２】
また、第１実施形態におけるＤＳＭ支援装置１０４は、具体的には、コンピュータがプログラムを実行することにより実現される。第１実施形態においてＤＳＭ支援装置１０４を実現するプログラムは、ＵＭＬツール１０３を実現するプログラムに対するアドオンプログラムである。もちろん、実施形態によっては、ＵＭＬツール１０３とＤＳＭ支援装置１０４の機能を併せて実現するプログラムをコンピュータが実行することで、ＵＭＬツール１０３とＤＳＭ支援装置１０４が１つに統合されてもよい。
【０１１３】
ＤＳＭ支援装置１０４は、具体的には、図４に示すようにモデル作成ナビゲーション部４０３を備える。モデル作成ナビゲーション部４０３は、メタモデル１０１と表記ルール１０２に基づいて、ＵＭＬツール１０３の動作に制約をかける。
【０１１４】
具体的には、モデル作成ナビゲーション部４０３は、メニュー選択部４０４、部品用メニュー提供部４０５、ポート用メニュー提供部４０６、インタフェース用メニュー提供部４０７、内部部品用メニュー提供部４０８およびタスク用メニュー提供部４０９を備える。また、ＤＳＭ支援装置１０４はさらに、ＸＭＬなどの所定の言語によって図１のモデル１０６を作成するモデル作成部４１０を備える。
【０１１５】
なお、第１実施形態において、図１の表記ルール１０２は、ＤＳＭ支援装置１０４内の各コンポーネントに、制御ロジックとして組み込まれている。ＤＳＭ支援装置１０４の動作の詳細は、図１０および１１とともに後述する。
【０１１６】
また、例えばハードディスク装置やＲＡＭ（Random Access Memory）などの記憶装置４１１が設けられている。記憶装置４１１は、モデル図格納部４１２、意味モデル格納部４１３、テンプレート格納部４１４、ソースコード格納部４１５およびメタモデル格納部４１６を備える。
【０１１７】
モデル図格納部４１２は、図１のプロセスＰ１０１で作成・編集される、ＵＭＬで表記された、図１のモデル図１０５（具体例は、例えば図３のモデル図１０５ａ）を格納する。意味モデル格納部４１３は、同じくプロセスＰ１０１で作成・編集され、モデル図１０５の意味をＸＭＬにより表す、図１のモデル１０６（具体例は、例えば図９Ａ〜９Ｄのモデル１０６ａ）を格納する。
【０１１８】
テンプレート格納部４１４は、ＸＳＬで表されて予め用意された、図１のコード生成テンプレート１０７を格納する。ソースコード格納部４１５は、図１のプロセスＰ１０２で生成される、Ｃ＋＋やＪａｖａ（登録商標）等のプログラミング言語のソースコード１０９を格納する。
【０１１９】
メタモデル格納部４１６は、ＵＭＬで表記されて予め用意された、図１のメタモデル１０１（具体例は、例えば図２の第１のメタモデル１０１ａ）を格納する。
以上の各部の動作は、詳しくは図１０〜１２とともに説明するが、概要は以下のとおりである。
【０１２０】
モデル作成ナビゲーション部４０３は、メタモデル１０１と表記ルール１０２にしたがって制約条件を満たしつつソフトウェアをモデル化するための、各種メニューを提供する。具体的には、モデル作成ナビゲーション部４０３は、ＵＭＬツール１０３の動作に制約をかけるため、ＵＭＬツール１０３を監視する。
【０１２１】
そして、入力装置４０１がユーザからの入力をＵＭＬツール１０３へ渡すと、その入力を契機としてモデル作成ナビゲーション部４０３は、入力の内容に応じて内部の適宜のコンポーネントを呼び出して処理を行わせる。また、モデル作成ナビゲーション部４０３は、処理の結果に基づいてモデル１０６を作成あるいは編集するよう、モデル作成部４１０に命令し、モデル作成部４１０はモデル１０６を作成あるいは編集する。
【０１２２】
具体的には、モデル作成ナビゲーション部４０３は、部品全般、ポート、インタフェース、内部部品、タスクそれぞれのモデル化のための各メニューと、メニュー選択のユーザインタフェースを提供する。ＵＭＬツール１０３が受け取った入力がメニュー選択のための入力であれば、モデル作成ナビゲーション部４０３においてメニュー選択部４０４が、選択されたメニューに対応するコンポーネントを呼び出す。
【０１２３】
なお、モデル作成ナビゲーション部４０３は、例えば、後述の図１１の駆動順序定義処理のためのメニューなど、上記以外の他のメニューをさらに提供してもよいが、図４では紙幅の都合上、他のメニューに関わるコンポーネントは図示を省略している。
【０１２４】
さて、部品のモデル化のためのメニューを選択する入力をＵＭＬツール１０３が受け取った場合、メニュー選択部４０４は、部品用メニュー提供部４０５を呼び出す。また、ポートのモデル化のためのメニューを選択する入力をＵＭＬツール１０３が受け取った場合、メニュー選択部４０４は、ポート用メニュー提供部４０６を呼び出す。
【０１２５】
同様に、インタフェースのモデル化のためのメニューを選択する入力をＵＭＬツール１０３が受け取った場合、メニュー選択部４０４は、インタフェース用メニュー提供部４０７を呼び出す。そして、内部部品のモデル化のためのメニューを選択する入力をＵＭＬツール１０３が受け取った場合、メニュー選択部４０４は、内部部品用メニュー提供部４０８を呼び出す。また、タスクのモデル化のためのメニューを選択する入力をＵＭＬツール１０３が受け取った場合、メニュー選択部４０４は、タスク用メニュー提供部４０９を呼び出す。
【０１２６】
そして、各メニューが選択された後で、各メニューにおける詳細設定のための入力をＵＭＬツール１０３が受け取った場合、モデル作成ナビゲーション部４０３は、当該メニューに対応するコンポーネントに入力内容を渡す。
【０１２７】
例えば、部品用のメニューが選択された後、部品をモデル化したクラスを新規作成するための入力をＵＭＬツール１０３が受け取ったら、その入力をモデル作成ナビゲーション部４０３がフックして、部品用メニュー提供部４０５に渡す。そして、部品用メニュー提供部４０５は、入力にしたがってクラスを新規作成する。
【０１２８】
その際、部品用メニュー提供部４０５は、ＵＭＬで表記されメタモデル格納部４１６に格納された図１のメタモデル１０１を読み出す。そして、部品用メニュー提供部４０５は、制御ロジックとして部品用メニュー提供部４０５自身に組み込まれている図１の表記ルール１０２と、読み出したメタモデル１０１にしたがって、制約をかけながら、部品をモデル化したクラスを新規作成する。
【０１２９】
新規作成されたクラスの情報は、部品用メニュー提供部４０５を含むモデル作成ナビゲーション部４０３からＵＭＬツール１０３へと通知される。すると、ＵＭＬツール１０３は、通知された情報に基づいて、新規作成されたクラスを表す図形を出力装置４０２に出力させる。例えば、ＵＭＬツール１０３は、新規作成されたクラスを示す矩形をディスプレイに描画するとともに、図３の汎化３０５の線をディスプレイに描画するよう、出力装置４０２に命令する。
【０１３０】
また、新規作成されたクラスの情報は、モデル作成部４１０にも通知される。すると、モデル作成部４１０は、通知された情報に基づいて、新規作成されたクラスに対応するＸＭＬコードを生成することで、モデル１０６を随時編集してゆく。
【０１３１】
以上、部品のモデル化のためのメニューを例として部品用メニュー提供部４０５に関わる動作を説明したが、他のメニューについても同様である。
つまり、入力装置４０１からの入力がＵＭＬツール１０３を介してモデル作成ナビゲーション部４０３に入力される。そして、各メニューに対するコンポーネントの制御下で、ＵＭＬの図形に関する情報がＵＭＬツール１０３に戻され、ＵＭＬツール１０３が図形を出力装置４０２に出力させ、ＵＭＬの図形に対応する意味を表すモデル１０６がモデル作成部４１０により編集される。
【０１３２】
以上のようにして、入力装置４０１とＵＭＬツール１０３を介した入力に基づいて、モデルが作成され、編集される。つまり、部品、ポート、インタフェース、内部部品、タスクなどが、適宜、作成ないし編集されることで、モデル全体の編集が行われる。
【０１３３】
その結果として最終的に得られたモデル図１０５は、ＵＭＬツール１０３を介してモデル図格納部４１２に格納される。同様に、最終的に得られたモデル１０６は、モデル作成部４１０から意味モデル格納部４１３に出力され、格納される。
【０１３４】
すると、図１のプロセスＰ１０２に示すように、コード生成装置１０８が意味モデル格納部４１３からモデル１０６を読み出し、テンプレート格納部４１４からコード生成テンプレート１０７を読み出して、ソースコード１０９を生成する。そして、コード生成装置１０８は生成したソースコード１０９をソースコード格納部４１５に格納する。
【０１３５】
したがって、ドメインに特有の事項を組み込んだメタモデル１０１が予め作成されていれば、ＤＳＭ支援装置１０４による制約条件の適用下において、ＵＭＬツール１０３を介して、ＵＭＬを用いたＤＳＭによるモデル作成が可能となる。そして、メタモデル１０１と表記ルール１０２にしたがった解釈のもとでモデル図１０５と意味的に等価なモデル１０６からは、自動的にソースコード１０９が生成される。
【０１３６】
よって、第１実施形態によれば、ＵＭＬを使用する際の上記（ａ１）〜（ａ３）の利点を活かしつつ、ＤＳＭによる設計における（ｂ１）〜（ｂ５）のような欠点を克服することができる。
【０１３７】
また、図３に関して説明したように、第１実施形態では、ユーザ定義のクラスに対してステレオタイプを付加しなくても、例えば汎化関係などからモデル図１０５における矩形や線の意味が自動的に解釈可能である。したがって、第１実施形態には、上記比較例と比べて設計の自由度が大きいという利点もある。
【０１３８】
ところで、図４に示す各ブロックを実現するハードウェアは、例えば図５に示すものでもよい。例えば、図４のＵＭＬツール１０３、ＤＳＭ支援装置１０４およびコード生成装置１０８は、１台のコンピュータにより実現されてもよく、入力装置４０１、出力装置４０２および記憶装置４１１が当該コンピュータに備えられていてもよい。図５はそのような場合の例を示す。
【０１３９】
図５は、コンピュータの構成図である。図５のコンピュータ５００は、ＣＰＵ（Central Processing Unit）５０１と、ＲＯＭ（Read Only Memory）５０２と、ＲＡＭ５０３と、通信インタフェース５０４を備える。また、コンピュータ５００は、図４に示した入力装置４０１と出力装置４０２を備える。コンピュータ５００はさらに、ハードディスク装置５０５と、コンピュータ読み取り可能な可搬型記憶媒体５０６の駆動装置５０７を備える。
【０１４０】
実施形態によっては、ハードディスク装置５０５のような磁気記憶装置に代えて、あるいはハードディスク装置５０５とともに、フラッシュメモリ等の不揮発性の半導体メモリ装置をコンピュータ５００が備えていてもよい。また、可搬型記憶媒体５０６としては、例えば、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disk）などの光ディスク、光磁気ディスク、磁気ディスク、フラッシュメモリ等の半導体メモリカードなどが利用可能である。
【０１４１】
そして、ＣＰＵ５０１、ＲＯＭ５０２、ＲＡＭ５０３、通信インタフェース５０４、入力装置４０１、出力装置４０２、ハードディスク装置５０５および駆動装置５０７は、バス５０８により接続されている。また、コンピュータ５００は、通信インタフェース５０４を介してネットワーク５０９に接続されている。
【０１４２】
ネットワーク５０９は、ＬＡＮ（Local Area Network）やインターネットなど、任意のネットワークである。ネットワーク５０９には、プログラム提供者５１０のコンピュータが接続されていてもよい。
【０１４３】
図４のＵＭＬツール１０３とＤＳＭ支援装置１０４とコード生成装置１０８は、いずれも、ＣＰＵ５０１がプログラムをＲＡＭ５０３にロードし、ＲＡＭ５０３をワークエリアとして利用しながらプログラムを実行することにより、実現される。
【０１４４】
ＵＭＬツール１０３とＤＳＭ支援装置１０４とコード生成装置１０８をそれぞれ実現するための各プログラムは、ＲＯＭ５０２またはハードディスク装置５０５に予め記憶されていてもよい。あるいは、各プログラムは、可搬型記憶媒体５０６に記憶され、駆動装置５０７にセットされた可搬型記憶媒体５０６から一旦ハードディスク装置５０５へ読み出されてもよい。または、各プログラムは、プログラム提供者５１０から提供され、ネットワーク５０９と通信インタフェース５０４を介してコンピュータ５００にダウンロードされてもよい。
【０１４５】
また、図４の記憶装置４１１は、ＲＯＭ５０２、ＲＡＭ５０３、ハードディスク装置５０５、上記の不図示の不揮発性の半導体メモリ装置および可搬型記憶媒体５０６のうち１つ以上のものを任意に組み合わせて実現することができる。
【０１４６】
なお、図５はハードウェア構成の一例にすぎず、実施形態によっては、ＵＭＬツール１０３、ＤＳＭ支援装置１０４およびコード生成装置１０８が複数のコンピュータに分散されていてもよい。
【０１４７】
続いて、図６〜１２を参照して、以上説明した第１実施形態について、さらに詳しく説明する。
図６は、第１のメタモデルにしたがう第２のモデルを表すＵＭＬのクラス図である。図２の第１のメタモデル１０１ａからは、図３のモデル図１０５ａのほかに、例えば図６のモデル図１０５ｂのように、入れ子になった部品を定義するモデルを表すクラス図を作成することもできる。つまり、図１のプロセスＰ１０１では、第１のメタモデル１０１ａと表記ルール１０２により定義される制約条件を満たすモデル図１０５として、図６の第２のメタモデル１０１ｂが作られてもよい。
【０１４８】
モデル図１０５ｂは、図３のモデル図１０５ａと同様に、第１のメタモデル１０１ａに含まれる「CompositionType」クラス２０２と「SenderReceiverInterface」クラス２０９を含む。また、第２のメタモデル１０１ｂは、モデル図１０５ａと同様に、「インタフェースA」クラス３０２を含む。そして、図３と同様に図６でも、「インタフェースA」クラス３０２が「SenderReceiverInterface」クラス２０９のサブクラスであることが汎化３０６の線により示されている。
【０１４９】
さらに、モデル図１０５ｂは、ユーザ定義の「部品B」クラス６０１を含む。「部品B」クラス６０１は、図３のモデル図１０５ａで定義されている「部品A」クラス３０１の２つのオブジェクト、すなわち「P1」オブジェクト６０２と「P2」オブジェクト６０３を含む。また、「部品B」クラス６０１は、「入力1」ポート６０４および「出力1」ポート６０５を含む。
【０１５０】
なお、「入力1」ポート６０４は、第１のメタモデル１０１ａにおける「RequesterPort」クラス２１２のオブジェクトなので、矩形の中に逆Ｖ字を書いた記号で表記されている。また、「出力1」ポート６０５は、第１のメタモデル１０１ａにおける「ProviderPort」クラス２１３のオブジェクトなので、矩形の中に黒い三角形を描いた記号で表記されている。
【０１５１】
図３に示すように「部品A」クラス３０１は２つのポートを含むので、「部品A」クラス３０１のインスタンスである図６の「P1」オブジェクト６０２と「P2」オブジェクト６０３も、それぞれ２つのポートを含む。すなわち、「P1」オブジェクト６０２は「受信ポート」ポート６０６と「送信ポート」ポート６０７を含み、「P2」オブジェクト６０３は「受信ポート」ポート６０８と「送信ポート」ポート６０９を含む。
【０１５２】
また、モデル図１０５ｂでは、「部品B」クラス６０１が「CompositionType」クラス２０２のサブクラスであることを示す汎化６１０が定義されている。汎化６１０により、「部品B」クラス６０１はインタフェースなどではなく部品をモデル化したクラスであるという意味が、モデル図１０５ｂ上で表される。
【０１５３】
そして、モデル図１０５ｂでは、「入力1」ポート６０４と「受信ポート」ポート６０６の間のリンク６１１が定義されている。さらに、「送信ポート」ポート６０７と「受信ポート」ポート６０８の間のリンク６１２と、「送信ポート」ポート６０９と「出力1」ポート６０５の間のリンク６１３も定義されている。
【０１５４】
また、モデル図１０５ｂでは、「入力1」ポート６０４から「インタフェースA」クラス３０２への依存６１４と、「出力1」ポート６０５から「インタフェースA」クラス３０２への依存６１５も定義されている。
【０１５５】
以上のような内容を持つモデル図１０５ｂは、図２の第１のメタモデル１０１ａおよび図１の表記ルール１０２に適合する。換言すれば、モデル図１０５ｂは、第１のメタモデル１０１ａにしたがって作成されたモデルを表すＵＭＬのクラス図であり、表記ルール１０２が表す制約条件を満たしている。具体的には以下の（ｄ１）〜（ｄ８）のとおりである。
【０１５６】
（ｄ１）図３に関する（ｃ１）と同様に、モデル図１０５ｂでは、「『部品B』クラス６０１は部品をモデル化したクラスである」という意味が、汎化６１０により示されている。
【０１５７】
（ｄ２）図３に関する（ｃ２）と同様に、モデル図１０５ｂにおいて、「部品B」クラス６０１が「入力1」ポート６０４と「出力1」ポート６０５を含むことは、図２の第１のメタモデル１０１ａと適合している。
【０１５８】
（ｄ３）図３に関する（ｃ３）と同様に、「『インタフェースA』クラス３０２はインタフェースをモデル化したクラスである」という意味が汎化３０６により示されている。
【０１５９】
（ｄ４）図３に関する（ｃ４）と同様に、「部品B」クラス６０１の「入力1」ポート６０４への入力が、「インタフェースA」クラス３０２によりモデル化されるインタフェースを介して行われるということが、依存６１４により表記されている。また、「部品B」クラス６０１の「出力1」ポート６０５からの出力が、「インタフェースA」クラス３０２によりモデル化されるインタフェースを介して行われるということが、依存６１５により表記されている。
【０１６０】
（ｄ５）図３に関する（ｃ６）と同様に、「部品B」クラス６０１において、ユーザが定義した「実行ポイント」という名前の、返り値を持たない関数には、<<RunnableEntity>>というステレオタイプが付加されている。
【０１６１】
（ｄ６）表記ルール１０２は、「入れ子関係にある外部部品と内部部品の間の通信は、外部部品と内部部品各々のポートを示す２つのオブジェクト間のリンクにより表記せよ」というルールを含む。より正確には、表記ルール１０２は、「外部部品と内部部品の間の通信を表記する上記リンクとしては、『RequesterPort』クラス２１２のインスタンス同士または『ProviderPort』クラス２１３のインスタンス同士の間のリンクのみが許される」というルールを含む。
【０１６２】
また、表記ルール１０２は、「外部部品と内部部品各々のポートを示す２つのオブジェクト間のリンクは、第１のメタモデル１０１ａにおける『DelegateConnector』クラス２１６のインスタンスであり、外部部品と内部部品の間の通信を意味する」という、意味の解釈に関するルールも含む。
【０１６３】
モデル図１０５ｂ中のリンク６１１は、外部部品のポートを示す「入力1」ポート６０４と、内部部品のポートを示す「受信ポート」ポート６０６を接続するリンクである。また、「入力1」ポート６０４と「受信ポート」ポート６０６はともに「RequesterPort」クラス２１２のインスタンスである。よって、リンク６１１は表記ルール１０２に適合している。
【０１６４】
また、モデル図１０５ｂ中のリンク６１３は、外部部品のポートを示す「出力1」ポート６０５と、内部部品のポートを示す「送信ポート」ポート６０９と接続するリンクである。そして、「出力1」ポート６０５と「送信ポート」ポート６０９はともに「ProviderPort」クラス２１３のインスタンスである。よって、リンク６１３は表記ルール１０２に適合する。
【０１６５】
そして、図４のモデル作成部４１０は、表記ルール１０２にしたがって、「リンク６１１とリンク６１３は、『DelegateConnector』クラス２１６のインスタンスであり、外部部品と内部部品の間の通信を意味する」と解釈する。
【０１６６】
（ｄ７）表記ルール１０２は、「入れ子関係にない２つの部品間の通信は、一方の部品が有する『ProviderPort』クラス２１３のオブジェクトと、他方の部品が有する『RequesterPort』クラス２１２のオブジェクトとの間のリンクにより表記せよ」というルールを含む。また、表記ルール１０２は、上記のようなリンクを、「第１のメタモデル１０１ａにおける『AssemblyConnector』クラス２１５のインスタンスであり、入れ子関係にない２つの部品間の通信を意味する」という意味に解釈するルールも含む。
【０１６７】
モデル図１０５ｂ中のリンク６１２は、入れ子関係にない「P1」オブジェクト６０２と「P2」オブジェクト６０３の間のリンクである。正確には、リンク６１２は、「P1」オブジェクト６０２が有する「送信ポート」ポート６０７と、「P2」オブジェクト６０３が有する「受信ポート」ポート６０８との間のリンクである。つまり、リンク６１２は、「P1」オブジェクト６０２が有する「ProviderPort」クラス２１３のオブジェクトと、「P2」オブジェクト６０３が有する「RequesterPort」クラス２１２のオブジェクトとの間のリンクである。よってリンク６１２は表記ルール１０２に適合する。
【０１６８】
そして、図4のモデル作成部４１０は、表記ルール１０２にしたがって、「リンク６１２は、『AssemblyConnector』クラス２１５のインスタンスであり、入れ子関係にない２つの部品間の通信を意味する」と解釈する。
【０１６９】
（ｄ８）表記ルール１０２は、「部品間の通信を表記するためのポート間のリンクは、出力元のポートと出力先のポートが同じインタフェースクラスに対して依存関係を有していなくてはならない」というルールを含む。実施形態によっては、「出力元のポートが依存する第１のインタフェースクラスまたはそのサブクラスである第２のインタフェースクラスに対して、出力先のポートが依存関係を有していなくてはならない」というルールを表記ルール１０２が含んでもよい。
【０１７０】
モデル図１０５ｂにおいて、「P1」オブジェクト６０２と「P2」オブジェクト６０３はともに図３で定義された「部品A」クラス３０１のインスタンスである。よって、「受信ポート」ポート６０６への入力と「送信ポート」ポート６０７からの出力は、いずれも、図３の定義のとおり、「インタフェースA」クラス３０２で定義されるインタフェースによるものである。同様に、「受信ポート」ポート６０８への入力と「送信ポート」ポート６０９からの出力も、「インタフェースA」クラス３０２で定義されるインタフェースによるものである。
【０１７１】
また、図６で定義されているように、「部品B」クラス６０１の「入力1」ポート６０４への入力と、「部品B」クラス６０１の「出力1」ポート６０５からの出力も、「インタフェースA」クラス３０２で定義されるインタフェースによるものである。
【０１７２】
以上から、リンク６１１、６１２、６１３のいずれにおいても、出力元のポートと出力先のポートが同じインタフェースクラスに対して依存関係を有している。したがって、リンク６１１、６１２、６１３はいずれも、表記ルール１０２に適合する。
【０１７３】
以上の（ｄ１）〜（ｄ８）で説明した制約条件を満たすように、図１のプロセスＰ１０１において、ＵＭＬツール１０３とＤＳＭ支援装置１０４は協働して、モデル図１０５ｂを作成する。
【０１７４】
例えば、同じ「ProviderPort」クラス２１３のインスタンスである「送信ポート」ポート６０７と「送信ポート」ポート６０９の間にリンクを作成しようとする入力を、図４の入力装置４０１を介してＵＭＬツール１０３が受け取っても、その入力は無効化される。つまり、上記（ｄ７）の表記ルール１０２に適合しないリンクを作成しようとする入力は、ＤＳＭ支援装置１０４により「不正な入力である」と判断され、ＵＭＬの図には反映されない。この場合、ＤＳＭ支援装置１０４は、「不正な入力なので入力内容はＵＭＬの図には反映されない」という旨の警告を、ＵＭＬツール１０３を介して出力装置４０２に出力してもよい。
【０１７５】
続いて、図７を参照して図１のモデル図１０５の他の例を説明する。
図７は、第１と第２のモデルを統合したモデルにより設計されたソフトウェアの全体構造を示すＵＭＬのオブジェクト図である。つまり、図７は、図２のモデル図１０５ａおよび図６のモデル図１０５ｂを統合したモデルに基づくオブジェクト図の形で、第１のメタモデル１０１ａにしたがうモデル図１０５ｃが表現されている。
【０１７６】
モデル図１０５ａは、図３のモデル図１０５ａと同様に、第１のメタモデル１０１ａに含まれる「CompositionType」クラス２０２を含む。
また、モデル図１０５ａは、<<TopLevel>>というステレオタイプが付加された「ソフトウェア全体」クラス７０１を含む。「ソフトウェア全体」クラス７０１は、１つのソフトウェアにつき１つのインスタンスしか持たない、ソフトウェアの最上位のメインルーチンに相当する特殊なクラスである。
【０１７７】
よって、「ソフトウェア全体」クラス７０１に<<TopLevel>>というステレオタイプを付加したとしても、「ソフトウェア全体」クラス７０１内部に含まれる個々のクラスには、依然としてユーザが自由にステレオタイプを付加することが可能である。つまり、「ソフトウェア全体」クラス７０１に<<TopLevel>>というステレオタイプを付加することは、上記比較例のように設計の自由度を束縛することには当たらない。
【０１７８】
「ソフトウェア全体」クラス７０１は、図３のモデル図１０５ａで定義された「部品A」クラス３０１のインスタンスである「PART1」オブジェクト７０２を含む。また、「ソフトウェア全体」クラス７０１は、図６のモデル図１０５ｂで定義された「部品B」クラス６０１のインスタンスである「PART2」オブジェクト７０３も含む。図６のとおり、「部品B」クラス６０１は「部品A」クラス３０１の２つのインスタンスを含むので、「ソフトウェア全体」クラス７０１は、「部品A」クラス３０１のインスタンスを合計で３つ含むこととなる。
【０１７９】
また、「ソフトウェア全体」クラス７０１は、第１のメタモデル１０１ａで定義されている「Task」クラス２０６のインスタンスである「T1」オブジェクト７０４を含む。「T1」オブジェクト７０４には、第１のメタモデル１０１ａで定義されたクラスのオブジェクトである。
【０１８０】
また、「部品A」クラス３０１のインスタンスである「PART1」オブジェクト７０２は、図３における「部品A」クラス３０１の定義のとおり、２つのポート（すなわち「受信ポート」ポート７０５と「送信ポート」ポート７０６）を有する。そして、「部品B」クラス６０１のインスタンスである「PART2」オブジェクト７０３は、図６における「部品B」クラス６０１の定義のとおり、２つのポート（すなわち「入力1」ポート７０７と「出力1」ポート７０８）を有する。
【０１８１】
なお、「ソフトウェア全体」クラス７０１がソフトウェアの部品であることは、「ソフトウェア全体」クラス７０１から「CompositionType」クラス２０２への汎化７０９により表されている。
【０１８２】
また、「ソフトウェア全体」クラス７０１内における「PART1」オブジェクト７０２と「PART2」オブジェクト７０３の間の通信は、「送信ポート」ポート７０６と「入力1」ポート７０７との間のリンク７１０により表されている。図３と図６の定義から明らかなように、リンク７１０は、図６に関して説明した（ｄ７）と（ｄ８）の表記ルール１０２に適合する。
【０１８３】
つまり、図４のＤＳＭ支援装置１０４は、リンクを作成しようとする指示のための入力に対して制約をかけることで、表記ルール１０２に適合するリンク７１０の作成を許し、表記ルール１０２に適合しないリンクの作成を拒絶する。それにより、表記ルール１０２に適合するモデル図１０５ｃが作成される。
【０１８４】
続いて、図８を参照して図１のモデル図１０５のさらに別の例を説明する。
図８は、図７のオブジェクト図に対応してソフトウェアの動作を定義するＵＭＬのシーケンス図である。ＵＭＬツール１０３とＤＳＭ支援装置１０４が協働して図１のプロセスＰ１０１で編集するＵＭＬの図の中には、図８のモデル図１０５ｄのようなシーケンス図も含まれる。
【０１８５】
図８には、図７の「T1」オブジェクト７０４と「PART1」オブジェクト７０２と「PART2」オブジェクト７０３それぞれのライフラインを示す破線と、それぞれの活性期間（activation）８０１、８０２および８０３が定義されている。
【０１８６】
また、図８には、「T1」オブジェクト７０４の活性期間８０１の初めの方で、「T1」オブジェクト７０４が「PART1」オブジェクト７０２を呼び出すことを示す呼び出し（call）８０４も定義されている。そして、その後「T1」オブジェクト７０４が「PART2」オブジェクト７０３を呼び出すことを示す呼び出し８０５も定義されている。つまり、モデル図１０５ｄは、「PART1」オブジェクト７０２が先に駆動され、「PART2」オブジェクト７０３が後に駆動されるという駆動の順序を定義している。
【０１８７】
呼び出し８０４のラベルは、図３の「部品A」クラス３０１において<<RunnableEntity>>というステレオタイプ付きで定義されている「実行ポイント」という操作を示している。また、呼び出し８０５のラベルは、図６の「部品B」クラス６０１において<<RunnableEntity>>というステレオタイプ付きで定義されている「実行ポイント」という操作を示している。なお、呼び出し８０４と８０５のラベルが同じなのは、偶然「部品A」クラス３０１と「部品B」クラス６０１で同名の操作が定義されているからである。
【０１８８】
図８のモデル図１０５ｄの作成にあたってＤＳＭ支援装置１０４が適用する制約条件としての表記ルール１０２は、例えば、下記（ｅ１）〜（ｅ２）のようなルールである。
（ｅ１）表記ルール１０２は、「シーケンス図において、呼び出しを示す矢印の呼び出し元は、第１のメタモデル１０１ａにおける『Task』クラス２０６のインスタンスまたは部品クラスで定義された操作でなくてはならない」というルールを含む。
【０１８９】
図８において、呼び出し８０４と８０５の呼び出し元は、いずれも「Task」クラス２０６のインスタンスである「T1」オブジェクト７０４である。よって、図８のモデル図１０５ｄは、表記ルール１０２に適合する。
【０１９０】
（ｅ２）表記ルール１０２は、「シーケンス図において、呼び出しのラベルは、外部から呼び出し可能であることを示す<<RunnableEntity>>というステレオタイプが付加された操作の名前でなくてはならない」というルールを含む。
【０１９１】
上記のとおり、呼び出し８０４と８０５のラベルである２つの「実行ポイント」は、それぞれ、図３と図６の定義において<<RunnableEntity>>というステレオタイプが付加された操作の名前である。よって、図８のモデル図１０５ｄは、表記ルール１０２に適合する。
【０１９２】
以上の（ｅ１)〜（ｅ２）で説明した制約条件を満たすように、図１のプロセスＰ１０１において、ＵＭＬツール１０３とＤＳＭ支援装置１０４は協働して、モデル図１０５ｄを作成する。
【０１９３】
例えば、図３のモデル図１０５ａにおいて、仮に、「部品A」クラス３０１にさらに別の操作が定義されているものとし、便宜上、その操作の名前が「処理a」であるとする。また、「処理a」という操作に対しては、<<RunnableEntity>>というステレオタイプが付加されていないとする。
【０１９４】
以上の仮定のもとで、呼び出し８０４のラベルとして「処理a」を指定しようとする入力を、入力装置４０１およびＵＭＬツール１０３を介してＤＳＭ支援装置１０４が受け取るとする。すると、モデル作成ナビゲーション部４０３は、入力が（ｅ２）の制約に反することを検出する。制約違反の検出に応じて、モデル作成ナビゲーション部４０３は、例えば、ＵＭＬツール１０３を介して出力装置４０２に「不正な入力なので、別のラベルを指定せよ」という警告を表示させてもよい。
【０１９５】
続いて、図９Ａ〜９Ｄを参照して、図１のモデル１０６の例を説明する。
図９Ａ〜９Ｄは、第１と第２のモデルを統合したモデルに対応するＸＭＬデータを示す図である。図示の都合上４枚の図に分けて示してあるが、図９Ａ〜９Ｄ全体で、図３、６〜８を統合したモデルを表す１つのＸＭＬ文書となっており、図９Ａ〜９Ｄに示すモデル１０６ａは、図１のモデル１０６の一例である。
【０１９６】
このように、複数枚にわたるＵＭＬのモデル図１０５（例えば図３、６〜８）が全体として、１つのソフトウェアのモデルを表し、１つのモデル１０６（例えば図９Ａ〜９Ｄ）に対応していてもよい。なお、参照の便宜のため、図９Ａ〜９Ｄでは左側に行番号を示してある。
【０１９７】
なお、実施形態に応じてモデル１０６ａでは任意の要素名を第１のメタモデル１０１ａの各クラスに対応付けて使うことができる。以下では、「-REF」で終わる要素名は参照を表すものとする。
【０１９８】
図９Ａ〜９Ｄに示すモデル１０６ａは、具体的には以下の（ｆ１）〜（ｆ３５）に述べる内容を有する。
（ｆ１）モデル１０６ａのルート要素は、「PACKAGE」要素である（１〜８６行目）。１行目に示すように、「PACKAGE」要素には、「テスト」という名前を示す「Name」属性と、最上位要素であることを示す「TopLevelPackage」属性が指定されている。
【０１９９】
また、「PACKAGE」要素は４つの子要素を有する。最初の３つの子要素は、図２の第１のメタモデル１０１ａの「CompositionType」クラス２０２に対応する「COMPOSITION-TYPE」要素である。４つ目の子要素は、第１のメタモデル１０１ａの「SenderReceiverInterface」クラス２０９に対応する「SENDER-RECEIVER-INTERFACE」要素である。
【０２００】
（ｆ２）「PACKAGE」要素の子要素のうち、１つ目の「COMPOSITION-TYPE」要素は、２〜２８行目に当たり、「CompositionType」クラス２０２のサブクラスとして定義された図７の「ソフトウェア全体」クラス７０１を表す。そのため、２行目では、「ソフトウェア全体」クラス７０１のクラス名が「COMPOSITION-TYPE」要素の「Name」属性の値として指定されている。また、「ソフトウェア全体」クラス７０１には<<TopLevel>>というステレオタイプが付加されているので、２行目では「COMPOSITION-TYPE」要素の「TopLevel」属性の値が「True」となっている。
【０２０１】
つまり、図４のモデル作成部４１０は図１のプロセスＰ１０１で、図７の汎化７０９に基づいて、モデル１０６ａにおいて「ソフトウェア全体」クラス７０１を「COMPOSITION-TYPE」要素として表現する。また、モデル作成部４１０は図７の<<TopLevel>>というステレオタイプに基づいて、「COMPOSITION-TYPE」要素の「TopLevel」属性を設定する。それにより、モデル作成部４１０は、「『ソフトウェア全体』クラス７０１は最上位の部品を表す」という意味をモデル１０６ａ上で表す。
【０２０２】
（ｆ３）「PACKAGE」要素の子要素のうち、２つ目の「COMPOSITION-TYPE」要素は、２９〜４４行目に当たり、「CompositionType」クラス２０２のサブクラスとして定義された図３の「部品A」クラス３０１を表す。そのため、２９行目では、「部品A」クラス３０１のクラス名が「COMPOSITION-TYPE」要素の「Name」属性の値として指定されている。
【０２０３】
上記（ｆ２）と同様、モデル作成部４１０は、図３の汎化３０５に基づいて、モデル１０６ａにおいて「部品A」クラス３０１を「COMPOSITION-TYPE」要素として表現することで、「『部品A』クラス３０１は部品を表す」という意味をモデル１０６ａ上で表す。
【０２０４】
（ｆ４）「PACKAGE」要素の子要素のうち、３つ目の「COMPOSITION-TYPE」要素は、４５〜７４行目に当たり、「CompositionType」クラス２０２のサブクラスとして定義された図６の「部品B」クラス６０１を表す。そのため、４５行目では「部品B」クラス６０１のクラス名が「COMPOSITION-TYPE」要素の「Name」属性の値として指定されている。
【０２０５】
上記（ｆ２）と同様、モデル作成部４１０は、図６の汎化６１０に基づいて、モデル１０６ａにおいて「部品B」クラス６０１を「COMPOSITION-TYPE」要素として表現することで、「『部品B』クラス６０１が部品を表す」という意味をモデル１０６ａ上で表す。
【０２０６】
（ｆ５）「PACKAGE」要素の４つ目の子要素である「SENDER-RECEIVER-INTERFACE」要素は、７５〜８５行目に当たり、「SenderReceiverInterface」クラス２０９のサブクラスとして定義された図３と図６の「インタフェースA」クラス３０２を表す。そのため、７５行目では、「インタフェースA」クラス３０２のクラス名が「SENDER-RECEIVER-INTERFACE」要素の「Name」属性の値として指定されている。
【０２０７】
上記（ｆ２）と同様、モデル作成部４１０は、図３と図６の汎化３０６に基づいて、モデル１０６ａにおいて「インタフェースA」クラス３０２を「SENDER-RECEIVER-INTERFACE」要素として表現する。それにより、モデル作成部４１０は、「『インタフェースA』クラス３０２がインタフェースを表す」という意味をモデル１０６ａ上で表す。
【０２０８】
（ｆ６）上記（ｆ２）の「COMPOSITION-TYPE」要素（２〜２８行目）は、５つの子要素を持つ。
１つ目の子要素は、３行目に示す空の「SUPER-ELEMENT」要素であり、空であることによって、図７の「ソフトウェア全体」クラス７０１が「CompositionType」クラス２０２から直接派生していることを表す。２つ目と３つ目の子要素は、第１のメタモデル１０１ａの「ComponentPrototype」クラス２０３に対応する２つの「COMPONENT-PROTOTYPE」要素（４〜６行目と７〜９行目）である。
【０２０９】
４つ目の子要素は、第１のメタモデル１０１ａの「AssemblyConnector」クラス２１５に対応する「ASSEMBLY-CONNECTOR」要素（１０〜１３行目）である。５つ目の子要素は、第１のメタモデル１０１ａの「Task」クラス２０６に対応する「TASK」要素（１４〜２７行目）である。
【０２１０】
（ｆ７）第１のメタモデル１０１ａでは、「CompositionType」クラス２０２が「ComponentPrototype」クラス２０３を含みうることを、集約２５３が示している。そして図７のモデル図１０５ｃは、この第１のメタモデル１０１ａと表記ルール１０２にしたがって表記されており、「ソフトウェア全体」クラス７０１は「PART1」オブジェクト７０２と「PART2」オブジェクト７０３を含む。
【０２１１】
以上の構造に対応して、モデル１０６ａでは、「ソフトウェア全体」クラス７０１に対応する上記（ｆ２）の「COMPOSITION-TYPE」要素（２〜２８行目）が、２つのオブジェクトに対応する２つの「COMPONENT-PROTOTYPE」要素（４〜６行目と７〜９行目）を子要素として持つ。
【０２１２】
（ｆ８）上記（ｆ６）と（ｆ７）で述べた１つ目の「COMPONENT-PROTOTYPE」要素（４〜６行目）は「PART1」オブジェクト７０２に対応するので、この「COMPONENT-PROTOTYPE」要素の「Name」属性には、オブジェクト名である「PART1」が指定されている（４行目）。
【０２１３】
また、第１のメタモデル１０１ａの関連２５２は、「ComponentPrototype」クラス２０３が「ComponentType」クラス２０１を参照することを示す。よって、第１のメタモデル１０１ａと表記ルール１０２にしたがって表記されたモデル図１０５ｃの意味を表すモデル１０６ａでは、「ComponentType」クラス２０１への参照を示す「COMPONENT-TYPE-REF」要素を、「COMPONENT-PROTOTYPE」要素が含む。具体的には、４〜６行目の「COMPONENT-PROTOTYPE」要素は、５行目に示す「COMPONENT-TYPE-REF」要素を含む。
【０２１４】
（ｆ９）この５行目の「COMPONENT-TYPE-REF」要素は、親要素である「COMPONENT-PROTOTYPE」要素（４〜６行目）が表す「PART1」オブジェクト７０２のクラスを示す情報を内容として含む。
【０２１５】
なお、「PART1」オブジェクト７０２は「部品A」クラス３０１に属し、「部品A」クラス３０１は「CompositionType」クラス２０２のサブクラスであり、「CompositionType」クラス２０２は「ComponentType」クラス２０１のサブクラスである。よって、「ComponentType」クラス２０１への参照を示す「COMPONENT-TYPE-REF」要素によって、モデル１０６ａ上で、「COMPONENT-PROTOTYPE」要素（４〜６行目）に対応する「PART1」オブジェクト７０２のクラスを示すことができる。
【０２１６】
具体的には、５行目の「COMPONENT-TYPE-REF」要素は、「/テスト/部品A」という、パッケージ名（１行目の「Name」属性の値）とクラス名（２９行目の「Name」属性の値）をスラッシュで結合したパスにより、「PART1」オブジェクト７０２のクラスを示す。パスがスラッシュから始まっているのは絶対パスであるためである。
【０２１７】
（ｆ１０）上記（ｆ６）と（ｆ７）で述べた２つ目の「COMPONENT-PROTOTYPE」要素（７〜９行目）は「PART2」オブジェクト７０３に対応するので、この「COMPONENT-PROTOTYPE」要素の「Name」属性には、オブジェクト名である「PART2」が指定されている（７行目）。そして、上記（ｆ８）と同様に、７〜９行目の「COMPONENT-PROTOTYPE」要素は、８行目に示す「COMPONENT-TYPE-REF」要素を含む。
【０２１８】
また、８行目の「COMPONENT-TYPE-REF」要素は、上記（ｆ９）と同様に、「PART2」オブジェクト７０３のクラスを示す情報を内容として含む。すなわち、パッケージ名（１行目の「Name」属性の値）とクラス名（４５行目の「Name」属性の値）を結合した「/テスト/部品B」というパスを、８行目の「COMPONENT-TYPE-REF」要素が内容として含む。
【０２１９】
（ｆ１１）第１のメタモデル１０１ａにおいて「AssemblyConnector」クラス２１５からは、「Port」クラス２１１への参照を示す関連２６９と関連２７０の２本の線が出ている。よって、上記（ｆ６）で述べた、「AssemblyConnector」クラス２１５に対応する「ASSEMBLY-CONNECTOR」要素（１０〜１３行目）は、関連２６９と関連２７０に対応する２つの子要素（１１行目と１２行目）を持つ。
【０２２０】
そして、図７のリンク７１０は、上記（ｄ７）と（ｄ８）の表記ルール１０２に適合している。上記（ｄ７）によれば、「AssemblyConnector」クラス２１５のインスタンスたるリンクの両端は、「ProviderPort」クラス２１３と「RequesterPort」クラス２１２のオブジェクトである。よって、「ASSEMBLY-CONNECTOR」要素（１０〜１３行目）の２つの子要素とは、「ProviderPort」クラス２１３と「RequesterPort」クラス２１２各々への参照を示す「PROVIDER-PORT-REF」要素（１１行目）と「REQUESTER-PORT-REF」要素（１２行目）である。
【０２２１】
つまり、１０〜１３行目の「ASSEMBLY-CONNECTOR」要素は、「ProviderPort」クラス２１３のオブジェクトである「送信ポート」ポート７０６と、「RequesterPort」クラス２１２のオブジェクトである「入力1」ポート７０７の間の、リンク７１０を示す。そして、「PROVIDER-PORT-REF」要素（１１行目）と「REQUESTER-PORT-REF」要素（１２行目）という２つの子要素が、リンク７１０の両端のポートを示す。なお、１０行目に示すように、「ASSEMBLY-CONNECTOR」要素の「Name」属性には、リンク７１０に割り当てられた図７には不図示の「asmConn_1」という名前が指定されている。
【０２２２】
（ｆ１２）上記（ｆ１１）で述べた「PROVIDER-PORT-REF」要素（１１行目）は、リンク７１０が表す通信の出力元の「送信ポート」ポート７０６の定義を示す情報を内容として含む。具体的には、１１行目の「PROVIDER-PORT-REF」要素は上記（ｆ９）と同様に、「/テスト/部品A/送信ポート」というパスにより、「送信ポート」ポート７０６の定義への参照を示す。このパスは、パッケージ名（１行目の「Name」属性の値）とクラス名（２９行目の「Name」属性の値）とクラス内で定義されたポート名（４１行目の「Name」属性の値）をスラッシュで結合したものである。
【０２２３】
（ｆ１３）上記（ｆ１１）で述べた「REQUESTER-PORT-REF」要素（１２行目）は、上記（ｆ１２）と同様に、リンク７１０が表す通信の出力先の「入力1」ポート７０７の定義を示す「/テスト/部品B/入力1」というパスを内容として含む。このパスは、パッケージ名（１行目の「Name」属性の値）とクラス名（４５行目の「Name」属性の値）とクラス内で定義されたポート名（５５行目の「Name」属性の値）をスラッシュで結合したものである。
【０２２４】
（ｆ１４）上記（ｆ６）で述べた「TASK」要素（１４〜２７行目）は、第１のメタモデル１０１ａの「Task」クラス２０６のインスタンスである図７の「T1」オブジェクト７０４を表す。よって、１４行目のとおり「TASK」要素の「Name」属性には、「T1」オブジェクト７０４の名前「T1」が指定されている。そして、図８に示す２つの呼び出し８０４と８０５に対応して、「TASK」要素（１４〜２７行目）は２つの子要素を有する。
【０２２５】
（ｆ１５）「TASK」要素の１つ目の子要素は、「部品A」クラス３０１のオブジェクトである「PART1」オブジェクト７０２への呼び出し８０４に対応する。呼び出し８０４により呼び出されるのは、具体的には、図３のモデル図１０５ａにおいて「部品A」クラス３０１の操作として定義され、<<RunnableEntity>>というステレオタイプが付加された、「実行ポイント」という名前の関数である。
【０２２６】
ここで、<<RunnableEntity>>というステレオタイプが付加された関数は、上記（ｃ６）の表記ルール１０２に基づき「RunnableEntity」クラス２０５のインスタンスとしてモデル作成部４１０により解釈される。つまり、「Task」クラス２０６の「T1」オブジェクト７０４からの「実行ポイント」という名前の関数に対する呼び出し８０４は、図２の第１のメタモデル１０１ａによれば、「RunnableConnector」クラス２０７に相当する。
【０２２７】
よって、「TASK」要素（１４〜２７行目）は、呼び出し８０４に対応する１つ目の子要素として、具体的には「RunnableConnector」クラス２０７に対応する「RUNNABLE-ENTITY-CONNECTOR」要素（１５〜２０行目）を有する。なお、１５〜２０行目の「RUNNABLE-ENTITY-CONNECTOR」要素の「Name」属性には、呼び出し８０４に割り当てられた図８には不図示の「runEntConn_0」という名前が指定されている（１５行目）。
【０２２８】
（ｆ１６）また、１５〜２０行目の「RUNNABLE-ENTITY-CONNECTOR」要素は、４つの子要素を有する。
１つ目の子要素は、１６行目の「NO」要素であり、図８のシーケンス図の形式のモデル図１０５ｄで定義された実行順序を表す。呼び出し８０４は１番目の呼び出しなので、１６行目の「NO」要素の内容は「1」である。
【０２２９】
２つ目の子要素は、１７行目の「SYMBOL」要素であり、呼び出し先の操作の名前を表す。換言すれば、<<RunnableEntity>>というステレオタイプが付加され、「Task」クラス２０６のオブジェクトから呼び出し可能な関数の名前は、「RunnableEntity」クラス２０５の「symbol」属性の値に相当し、モデル１０６ａでは「SYMBOL」要素により表される。呼び出し８０４の呼び出し先は「部品A」クラス３０１で定義された「実行ポイント」という名前の関数なので、１７行目の「SYMBOL」要素の内容は「実行ポイント」である。
【０２３０】
３つ目の子要素は、１８行目の「PARAMETER」要素であり、呼び出し先の操作に与える引数を表す。「実行ポイント」という関数は引数を持たないので「PARAMETER」要素の内容は空である。
【０２３１】
４つ目の子要素は、１９行目の「COMPONENT-TYPE-REF」要素であり、呼び出し先のオブジェクトが属するクラスを表す。呼び出し８０４の呼び出し先の「PART1」オブジェクト７０２は、図７で定義されているとおり「部品A」クラス３０１のオブジェクトである。よって、１９行目の「COMPONENT-TYPE-REF」要素は、上記（ｆ９）で説明した５行目と同様にパス形式で表現された「/テスト/部品A」という値を内容として持つ。
【０２３２】
なお、図２の第１のメタモデル１０１ａの集約２５５によれば、「RunnableEntity」クラス２０５は、メタ部品クラスの一種である「ComponentType」クラス２０１に含まれる。よって、第１実施形態では、「ComponentType」クラス２０１への参照を意味する「COMPONENT-TYPE-REF」要素により、呼び出し先の関数が定義されたクラス（すなわち呼び出し先のオブジェクトが属するクラス）がモデル１０６ａ上で表現される。
【０２３３】
（ｆ１７）１４〜２７行目の「TASK」要素は、上記（ｆ１５）と（ｆ１６）で述べた１つ目の「RUNNABLE-ENTITY-CONNECTOR」要素（１５〜２０行目）と同様に、２つ目の「RUNNABLE-ENTITY-CONNECTOR」要素（２１〜２６行目）を含む。２つ目の「RUNNABLE-ENTITY-CONNECTOR」要素は、図８の呼び出し８０５に対応するので、呼び出し８０５に割り当てられた「runEntConn_1」という名前が「Name」属性に指定されている。
【０２３４】
また、呼び出し８０５は２番目の呼び出しなので、子要素たる「NO」要素（２２行目）は「2」という内容を持つ。
そして、呼び出し８０５の呼び出し先である「PART2」オブジェクト７０３は、図６のモデル図１０５ｂで定義された「部品B」クラス６０１のオブジェクトであり、呼び出し８０５の呼び出し先関数の名前は「実行ポイント」である。よって、２つ目の「RUNNABLE-ENTITY-CONNECTOR」要素は、「実行ポイント」という内容を有する「SYMBOL」要素を子要素として持つ（２３行目）。なお、「部品B」クラス６０１の「実行ポイント」という関数も引数を持たないので、「RUNNABLE-ENTITY-CONNECTOR」要素は、空の「PARAMETER」要素を子要素として持つ（２４行目）。
【０２３５】
また、「部品B」クラス６０１を表すために上記（ｆ１０）と同様のパス形式の「/テスト/部品B」という値を内容として持つ「COMPONENT-TYPE-REF」要素（２５行目）も、「RUNNABLE-ENTITY-CONNECTOR」要素に子要素として含まれる。
【０２３６】
（ｆ１８）上記（ｆ３）で簡単に述べたように、ルート要素（つまり「PACKAGE」要素）の子要素として、２９〜４４行目には図３の「部品A」クラス３０１を表す「COMPOSITION-TYPE」要素が含まれる。この「COMPOSITION-TYPE」要素は、５つの子要素を有する。
【０２３７】
（ｆ１９）２９〜４４行目の「COMPOSITION-TYPE」要素の１つ目の子要素は、「部品A」クラス３０１が図３に示すように「CompositionType」クラス２０２から直接派生していることを表す空の「SUPER-ELEMENT」要素（３０行目）であり、３行目と同様である。
【０２３８】
（ｆ２０）２９〜４４行目の「COMPOSITION-TYPE」要素の２つ目の子要素は、「部品A」クラス３０１において<<ConfigParam>>というステレオタイプが付加された属性を表す「COMFIG-PARAM」要素である（３１〜３４行目）。つまり、第１のメタモデル１０１ａにおいて「ComponentType」クラス２０１が「ConfigParam」クラス２０４を含みうることに対応する上記（ｃ５）の表記ルール１０２にしたがって、モデル作成部４１０は「COMFIG-PARAM」要素を生成する。
【０２３９】
具体的には、図３において「部品A」クラス３０１では、<<ConfigParam>>というステレオタイプが付加された属性が１つだけ定義されており、その属性に関して、名前は「パラメタ」、型は整数型、デフォルト値は未設定である。よって、３１〜３４行目の「COMFIG-PARAM」要素には、「Name」属性に「パラメタ」という値が設定されている（３１行目）。また、「COMFIG-PARAM」要素は、「int」という値を有し整数型を示す「TYPE」要素（３２行目）と、デフォルト値が未設定であることを示す空の「DEFAULT-VALUE」要素（３３行目）を、子要素として持つ。
【０２４０】
（ｆ２１）２９〜４４行目の「COMPOSITION-TYPE」要素の３つ目の子要素は、「部品A」クラス３０１において<<RunnableEntity>>というステレオタイプが付加された操作を表す「RUNNABLE-ENTITY」要素である（３５〜３６行目）。つまり、第１のメタモデル１０１ａにおいて「ComponentType」クラス２０１が「RunnableEntity」クラス２０５を含むことに対応する上記（ｃ６）の表記ルール１０２にしたがって、モデル作成部４１０は「RUNNABLE-ENTITY」要素を作成する。
【０２４１】
具体的には、図３において「部品A」クラス３０１では、<<RunnableEntity>>というステレオタイプが付加された操作が１つだけ定義されており、その操作の名前が「実行ポイント」である。よって、３５〜３６行目の「RUNNABLE-ENTITY」要素には、「Name」属性に「実行ポイント」という値が設定されている。
【０２４２】
（ｆ２２）２９〜４４行目の「COMPOSITION-TYPE」要素の４つ目の子要素は、「部品A」クラス３０１が有する「RequesterPort」クラス２１２のオブジェクトを表す「REQUESTER-PORT」要素（３７〜４０行目）である。図３のモデル図１０５ａによれば、「部品A」クラス３０１は「RequesterPort」クラス２１２のオブジェクトを１つ含み、そのオブジェクトの名前は「受信ポート」である。よって、「REQUESTER-PORT」要素には、「Name」属性に「受信ポート」という値が設定されている（３７行目）。
【０２４３】
また、モデル図１０５ａには、「受信ポート」ポート３０３から「インタフェースA」クラス３０２への依存３０７が定義されている。よって、モデル作成部４１０は依存３０７に基づいて、「REQUESTER-PORT」要素の子要素として、「INTERFACE-REF」要素（３８行目）を作成する。「INTERFACE-REF」要素は、第１のメタモデル１０１ａにおける「Port」クラス２１１から「Interface」クラス２０８への参照を示す関連２６２に対応する。「INTERFACE-REF」要素の内容は、５行目などと同様のパス形式で表現された「/テスト/インタフェースA」という値である。
【０２４４】
なお、図２では省略されているが、例えば「RequesterPort」クラス２１２には入力キューの長さを示す整数型の属性が定義されていてもよい。すると、「RequesterPort」クラス２１２のインスタンスである「受信ポート」ポート３０３でも入力キューの長さが設定されることになる。すると、設定された長さに基づいて、モデル作成部４１０は「REQUESTER-PORT」要素の子要素として「QUEUE-LENGTH」要素（３９行目）を作成する。図９Ｂの例では「QUEUE-LENGTH」要素は「0」という値を内容として持つ。
【０２４５】
（ｆ２３）２９〜４４行目の「COMPOSITION-TYPE」要素の４つ目の子要素は、「部品A」クラス３０１が有する「ProviderPort」クラス２１３のオブジェクトを表す「PROVIDER-PORT」要素（４１〜４３行目）である。図３のモデル図１０５ａによれば、「部品A」クラス３０１は「ProviderPort」クラス２１３のオブジェクトを１つ含み、そのオブジェクトの名前は「送信ポート」である。よって、「PROVIDER-PORT」要素には、「Name」属性に「送信ポート」という値が設定されている（４１行目）。
【０２４６】
また、モデル図１０５ａには、「送信ポート」ポート３０４から「インタフェースA」クラス３０２への依存３０８が定義されている。よって、モデル作成部４１０は依存３０８に基づいて、「PROVIDER-PORT」要素の子要素として、３８行目と同様の「INTERFACE-REF」要素を作成する。
【０２４７】
（ｆ２４）上記（ｆ４）で簡単に述べたように、ルート要素（つまり「PACKAGE」要素）の子要素として、４５〜７４行目には図６の「部品B」クラス６０１を表す「COMPOSITION-TYPE」要素が含まれる。この「COMPOSITION-TYPE」要素は９個の子要素を有する。
【０２４８】
（ｆ２５）「部品B」クラス６０１を示す「COMPOSITION-TYPE」要素の１つ目の子要素は、「部品B」クラス６０１が「CompositionType」クラス２０２から直接派生していることを表す空の「SUPER-ELEMENT」要素（４６行目）であり、３０行目と同様である。
【０２４９】
（ｆ２６）「部品B」クラス６０１を示す「COMPOSITION-TYPE」要素の２つ目と３つ目の子要素は、「部品B」クラス６０１が「P1」オブジェクト６０２と「P2」オブジェクト６０３を含むことを表す２つの「COMPONENT-PROTOTYPE」要素である。１つ目（４７〜４９行目）は「P1」オブジェクト６０２に対応し、２つ目（５０〜５２行目）は「P2」オブジェクト６０３に対応する。これら２つの「COMPONENT-PROTOTYPE」要素は、上記（ｆ７）〜（ｆ１０）で説明した２〜２８行目の「COMPOSITION-TYPE」要素の子要素（４〜６行目と７〜９行目）と同じ形式なので、詳しい説明は省略する。
【０２５０】
（ｆ２７）「部品B」クラス６０１を示す「COMPOSITION-TYPE」要素の４つ目の子要素（５３〜５４行目）は、上記（ｆ２１）で説明した、３５〜３６行目の「RUNNABLE-ENTITY」要素と同様の「RUNNABLE-ENTITY」要素であるので、詳しい説明は省略する。
【０２５１】
（ｆ２８）「部品B」クラス６０１を示す「COMPOSITION-TYPE」要素の５つ目の子要素（５５〜５８行目）は、上記（ｆ２２）で説明した、３７〜４０行目の「REQUESTER-PORT」要素と同様の「REQUESTER-PORT」要素であるので、詳しい説明は省略する。
【０２５２】
（ｆ２９）「部品B」クラス６０１を示す「COMPOSITION-TYPE」要素の６つ目の子要素（５９〜６１行目）は、上記（ｆ２３）で説明した、４１〜４３行目の「PROVIDER-PORT」要素と同様の「PROVIDER-PORT」要素であるので、詳しい説明は省略する。
【０２５３】
（ｆ３０）「部品B」クラス６０１を示す「COMPOSITION-TYPE」要素の７つ目の子要素（６２〜６５行目）は、１０〜１３行目の「ASSEMBLY-CONNECTOR」要素と類似の「ASSEMBLY-CONNECTOR」要素である。１０〜１３行目の「ASSEMBLY-CONNECTOR」要素は、上記（ｆ１１）〜（ｆ１３）で詳しく説明したとおりである。よって、６２〜６５行目の「ASSEMBLY-CONNECTOR」についての詳しい説明は省略するが、図６のモデル図１０５ｂにおける「部品B」クラス６０１の内部のリンク６１２に基づき、モデル作成部４１０が６２〜６５行目の「ASSEMBLY-CONNECTOR」要素を生成する。
【０２５４】
なお、６２〜６５行目の「ASSEMBLY-CONNECTOR」要素の子要素（６３行目と６４行目）では、１１行目と１２行目とは異なり、相対パスが使われている。すなわち、６３行目では、「部品B」クラス６０１のレベルを起点とした「P1/送信ポート」という相対パスの形でパスが表現されている。この相対パスは、「部品B」クラス６０１の内部部品に当たる「P1」オブジェクト６０２のオブジェクト名である「P1」と、「P1」オブジェクト６０２が含む「送信ポート」ポート６０７の名前である「送信ポート」をスラッシュで結合したものである。６４行目でも同様に、相対パスの形式でパスが表現されている。
【０２５５】
（ｆ３１）「部品B」クラス６０１を示す「COMPOSITION-TYPE」要素の８つ目の子要素は、「DelegateConnector」クラス２１６のインスタンスとしてのリンク６１１を表す「DELEGATION-CONNECTOR」要素（６６〜６９行目）である。なお、６６行目に示すように、この「DELEGATION-CONNECTOR」要素の「Name」属性には、リンク６１１に割り当てられた図６には不図示の「delConn_0」という名前が指定されている。
【０２５６】
第１のメタモデル１０１ａにおいて「DelegateConnector」クラス２１６からは、「Port」クラス２１１への参照を示す関連２７１と関連２７２の２本の線が出ている。よって、「DelegateConnector」クラス２１６に対応する「DELEGATION-CONNECTOR」要素（６６〜６９行目）は、２つの子要素（６７行目と６８行目）を持つ。
【０２５７】
つまり、「DELEGATION-CONNECTOR」要素は、「innerPortRef」というロール名で「Port」クラス２１１を参照する関連２７１に対応して、内部部品側のポートへの参照を表す「INNER-PORT-REF」要素（６７行目）を１つ目の子要素として持つ。「INNER-PORT-REF」要素の内容は、リンク６１１に関わる内部部品側のポート（すなわち「受信ポート」ポート６０６）を特定するための「/テスト/部品B/P1/受信ポート」というパスである。
【０２５８】
同様に、「DELEGATION-CONNECTOR」要素は、「outerPortRef」というロール名で「Port」クラス２１１を参照する関連２７２に対応して、外部部品側のポートへの参照を表す「OUTER-PORT-REF」要素（６８行目）を２つ目の子要素として持つ。「OUTER-PORT-REF」要素の内容は、リンク６１１に関わる外部部品側のポート（すなわち「入力1」ポート６０４）を特定するための「/テスト/部品B/入力1」というパスである。
【０２５９】
（ｆ３２）「部品B」クラス６０１を示す「COMPOSITION-TYPE」要素の９つ目の子要素は、「DelegateConnector」クラス２１６のインスタンスとしてのリンク６１３を表す「DELEGATION-CONNECTOR」要素（７０〜７３行目）である。７０〜７３行目の「DELEGATION-CONNECTOR」要素の内容は、上記（ｆ３１）で説明した６６〜６９行目の「DELEGATION-CONNECTOR」要素の内容と類似なので、詳しい説明は省略する。
【０２６０】
（ｆ３３）上記（ｆ５）で簡単に述べたように、ルート要素（つまり「PACKAGE」要素）の子要素として、７５〜８５行目には図３および図６の「インタフェースA」クラス３０２を表す「SENDER-RECEIVER-INTERFACE」要素が含まれる。「SENDER-RECEIVER-INTERFACE」要素の「Name」属性には、「インタフェースA」クラス３０２のクラス名である「インタフェースA」が指定されている。そして、この「SENDER-RECEIVER-INTERFACE」要素は、３つの子要素を有する。
【０２６１】
（ｆ３４）「SENDER-RECEIVER-INTERFACE」要素の１つ目の子要素は、「インタフェースA」クラス３０２が「SenderReceiverInterface」クラス２０９から直接派生していることを表す空の「SUPER-ELEMENT」要素であり、３行目と同様である。
【０２６２】
（ｆ３５）「SENDER-RECEIVER-INTERFACE」要素の２つ目と３つ目の子要素は、第１のメタモデル１０１ａにおいて「SenderReceiverInterface」クラス２０９が「DataElementPrototype」クラス２１０を含むことに対応した「DATA-ELEMENT」要素である。具体的には、図３に示すように「インタフェースA」クラス３０２は、「DataElementPrototype」クラス２１０のインスタンスに相当する２つの属性を有する。すなわち、「要素1」という名前で整数型の属性と、「要素2」という名前で整数型の属性を、「インタフェースA」クラス３０２は持っている。
【０２６３】
そのためモデル作成部４１０は、「インタフェースA」クラス３０２を表す「SENDER-RECEIVER-INTERFACE」要素の子要素として、「要素1」という名前の属性に対応する「DATA-ELEMENT」要素（７７〜８０行目）を作成する。そしてモデル作成部４１０は、「DATA-ELEMENT」要素の「Name」属性の値として「要素1」という名前を設定する。また、モデル作成部４１０は、「DATA-ELEMENT」要素の子要素として、整数型を示す「int」という内容を持つ「TYPE」要素と、デフォルト値が未設定であることを示す空の「DEFAULT-VALUE」要素を作成する。
【０２６４】
同様に、モデル作成部４１０は、「インタフェースA」クラス３０２の「要素2」という名前の属性に対応して、「SENDER-RECEIVER-INTERFACE」要素の子要素として２つ目の「DATA-ELEMENT」要素（８１〜８４行目）も作成する。
【０２６５】
以上（ｆ１）〜（ｆ３５）として列挙して説明したように、モデル作成部４１０は、第１のメタモデル１０１ａと表記ルール１０２にしたがって、モデル図１０５ａ〜１０５ｄから、モデル図１０５ａ〜１０５ｄの意味を表すＸＭＬ形式のモデル１０６ａを生成する。
【０２６６】
続いて、クラス図とシーケンス図を使ってモデルを定義する場合の図１のプロセスＰ１０１の詳細を、図１０と図１１をそれぞれ参照して説明する。なお、オブジェクト図の形でモデルを定義する場合については、ＤＳＭ支援装置１０４が行う処理は図１０の処理と類似なので詳しい説明を割愛する。いずれにしろＤＳＭ支援装置１０４は、メタモデル１０１と表記ルール１０２にしたがってＵＭＬ図（つまりモデル図１０５）が作成されるように、ナビゲーションを行う。
【０２６７】
図１０は、第１実施形態によるモデル編集処理を説明する図である。なお、図１０はＵＭＬのアクティビティ図の形式で表現されている。
ステップＳ１０１でメニュー選択部４０４は、メタモデル１０１を選択するためのメニューを、ＵＭＬツール１０３を介して出力装置４０２に表示させる。そして、入力装置４０１とＵＭＬツール１０３を介して、メタモデル１０１を選択する入力をモデル作成ナビゲーション部４０３が受け取る。すると、モデル作成ナビゲーション部４０３は、受け取った入力にしたがって、選択されたメタモデル１０１をメタモデル格納部４１６から読み出す。
【０２６８】
なお、読み出されたメタモデル１０１は、部品用メニュー提供部４０５、ポート用メニュー提供部４０６、インタフェース用メニュー提供部４０７、内部部品用メニュー提供部４０８およびタスク用メニュー提供部４０９から参照可能である。
【０２６９】
次のステップＳ１０２は、ステップＳ１０１からの処理の流れと後述のステップＳ１１６からの処理の流れの合流点を示すマージノードである。
続いて、ステップＳ１０３でメニュー選択部４０４は、処理を選択するためのメニューを、ＵＭＬツール１０３を介して出力装置４０２に表示させる。そして、処理の種類を指定する入力が、入力装置４０１とＵＭＬツール１０３を介してモデル作成ナビゲーション部４０３のメニュー選択部４０４に与えられると、処理はステップＳ１０４に移行する。
【０２７０】
ステップＳ１０４でメニュー選択部４０４は、ステップＳ１０３で選択された処理が部品作成処理であるか否かを判断する。部品作成処理が選択された場合、メニュー選択部４０４は部品用メニュー提供部４０５を呼び出し、処理はステップＳ１０５に移行する。他方、部品作成処理が選択されたのではない場合、処理はステップＳ１１７に移行する。
【０２７１】
ステップＳ１０５で部品用メニュー提供部４０５は、新たな部品クラスを作成する。例えば、図３において「部品A」クラス３０１を新たな部品クラスとして作成する場合を例に説明すると、ステップＳ１０５で部品用メニュー提供部４０５は、ＵＭＬツール１０３を介して次のように動作し、クラス図（つまりモデル図１０５ａ）を編集する。
【０２７２】
すなわち、部品用メニュー提供部４０５は、第１のメタモデル１０１ａ内の「CompositionType」クラス２０２を作成中のクラス図に既にコピーしたか否かを判断する。そして、まだコピーしていなければ、部品用メニュー提供部４０５は、第１のメタモデル１０１ａから「CompositionType」クラス２０２を読み出し、ＵＭＬツール１０３を介して、作成中のクラス図に「CompositionType」クラス２０２をコピーする。
【０２７３】
そして、新たな部品のクラス用にクラスを表す矩形を作図し、当該矩形から「CompositionType」クラス２０２への汎化３０５の線を引くように、部品用メニュー提供部４０５はＵＭＬツール１０３に命令する。その結果、ＵＭＬツール１０３を介して出力装置４０２には、上記矩形と汎化３０５の線が出力される。
【０２７４】
また、部品用メニュー提供部４０５は、ＵＭＬツール１０３を介して、上記の矩形が表すクラスのクラス名、属性、および操作を指定する入力を受け付け、受け付けた結果を作成中のクラス図に反映して出力装置４０２に出力させる。
【０２７５】
部品用メニュー提供部４０５はさらに、作成されたクラスの情報をモデル作成部４１０に通知する。すると、モデル作成部４１０は通知された情報に対応するＸＭＬコードを生成することでモデル１０６を作成および編集する。例えば、ステップＳ１０５で図３の「部品A」クラス３０１が作成される場合、モデル作成部４１０は図９Ｂの２９、３０、４４行目のコードを生成してモデル１０６ａに追加する。
【０２７６】
続くステップＳ１０６で部品用メニュー提供部４０５は、ステップＳ１０５で作成したクラスが表す部品が最上位部品か否かを、入力装置４０１からＵＭＬツール１０３を介して与えられる入力に基づいて判断する。例えば、部品用メニュー提供部４０５は、ＵＭＬツール１０３を介して出力装置４０２にダイアログを表示させ、ステップＳ１０５で作成したクラスが表す部品が最上位部品か否かをユーザに入力させ、その入力に基づいて判断を行う。
【０２７７】
ステップＳ１０５で作成したクラスが表す部品が最上位部品であれば、処理はステップＳ１０７に移行し、最上位部品でなければ、処理はマージノードのステップＳ１０８を経て次のステップＳ１０９へと進む。
【０２７８】
ステップＳ１０７で部品用メニュー提供部４０５は、最上位部品設定処理を行う。例えば、ステップＳ１０５で図７の「ソフトウェア全体」クラス７０１が作成される場合、ステップＳ１０６では、「ソフトウェア全体」クラス７０１が最上位部品であるという指示が入力される。したがって、ステップＳ１０７で部品用メニュー提供部４０５は、ＵＭＬツール１０３を介して、「ソフトウェア全体」クラス７０１に<<TopLevel>>というステレオタイプを付加する。
【０２７９】
また、部品用メニュー提供部４０５は、ステップＳ１０５で作成したクラスが表す部品が最上位部品であることを、モデル作成部４１０に通知する。モデル作成部４１０は通知に応じてモデル１０６を編集する。例えば、ステップＳ１０５で「ソフトウェア全体」クラス７０１が作成される場合、ステップＳ１０７でモデル作成部４１０は、図９Ａの２行目に示す「COMPOSITION-TYPE」要素に「TopLevel」属性を追加し、「TopLevel」属性に「True」という値を設定する。
【０２８０】
ステップＳ１０７の実行後、処理はステップＳ１０８に移行する。ステップＳ１０８はステップＳ１０６からの処理の流れとステップＳ１０７からの処理の流れの合流地点を示すマージノードであり、続いて処理はステップＳ１０９に移行する。
【０２８１】
ステップＳ１０９で部品用メニュー提供部４０５は、クラス内で定義された属性に<<ConfigParam>>というステレオタイプを指定するか否かを、入力装置４０１からＵＭＬツール１０３を介して与えられる入力に基づいて判断する。
【０２８２】
例えば、部品用メニュー提供部４０５は、ＵＭＬツール１０３を介して出力装置４０２にダイアログを表示させてもよい。つまり、部品用メニュー提供部４０５は、ステップＳ１０５で作成されたクラスにおいてステップＳ１０５で定義された属性の中から、<<ConfigParam>>というステレオタイプを付加する属性をユーザに選択させるためのダイアログを提供してもよい。
【０２８３】
そして、<<ConfigParam>>というステレオタイプを付加する対象の属性があれば、処理はステップＳ１１０へ移行し、<<ConfigParam>>というステレオタイプをどの属性にも付加しない場合は、処理はマージノードのステップＳ１１１を経て次のステップＳ１１２へと進む。
【０２８４】
ステップＳ１１０で部品用メニュー提供部４０５は、パラメタ設定処理を行う。例えばステップＳ１０５で図３の「部品A」クラス３０１が作成され、ステップＳ１０９で「部品A」クラス３０１の「パラメタ」という名前の属性に対して<<ConfigParam>>というステレオタイプを付加するよう指示する入力が与えられたとする。するとステップＳ１１０で部品用メニュー提供部４０５は、ＵＭＬツール１０３を介して、指定された「パラメタ」という名前の属性に対して、<<ConfigParam>>というステレオタイプを付加する。
【０２８５】
また、部品用メニュー提供部４０５は、<<ConfigParam>>というステレオタイプを付加する対象の属性をモデル作成部４１０に通知する。上記の「部品A」クラス３０１の例の場合、モデル作成部４１０は通知に基づいて図９Ｂの３１〜３４行のＸＭＬコードを生成し、モデル１０６ａに追加する。
【０２８６】
そして、処理はマージノードのステップＳ１１１を経て次のステップＳ１１２へと進む。
ステップＳ１１１は、ステップＳ１０９からの処理の流れとステップＳ１１０からの処理の流れの合流地点を示すマージノードであり、続いて処理はステップＳ１１２に移行する。
【０２８７】
ステップＳ１１２で部品用メニュー提供部４０５は、クラス内で定義された操作に<<RunnableEntity>>というステレオタイプを指定するか否かを、入力装置４０１からＵＭＬツール１０３を介して与えられる入力に基づいて判断する。すなわち、部品用メニュー提供部４０５は、クラス内で定義された操作を、外部からの呼び出しにより部品を駆動するための実行ポイントとして規定するか否かを、ステップＳ１１２で判断する。
【０２８８】
例えば、部品用メニュー提供部４０５は、ＵＭＬツール１０３を介して出力装置４０２にダイアログを表示させてもよい。つまり、部品用メニュー提供部４０５は、ステップＳ１０５で作成されたクラスにおいてステップＳ１０５で定義された操作の中から、<<RunnableEntity>>というステレオタイプを付加する操作をユーザに選択させるためのダイアログを提供してもよい。
【０２８９】
そして、<<RunnableEntity>>というステレオタイプを付加する対象の操作があれば、処理はステップＳ１１３へ移行し、<<RunnableEntity>>というステレオタイプをどの操作にも付加しない場合は、処理はマージノードのステップＳ１１４を経て次のステップＳ１１５へと進む。
【０２９０】
ステップＳ１１３で部品用メニュー提供部４０５は、実行ポイント設定処理を行う。例えばステップＳ１０５で図３の「部品A」クラス３０１が作成されたとする。そして、ステップＳ１１２で、「部品A」クラス３０１の「実行ポイント」という名前の操作に対して、<<RunnableEntity>>というステレオタイプを付加するよう指示する入力が与えられたとする。するとステップＳ１１３で部品用メニュー提供部４０５は、指定された「実行ポイント」という名前の操作に対して、ＵＭＬツール１０３を介して<<RunnableEntity>>というステレオタイプを付加する。
【０２９１】
また、部品用メニュー提供部４０５は、<<RunnableEntity>>というステレオタイプを付加する対象の操作をモデル作成部４１０に通知する。上記の「部品A」クラス３０１の例の場合、モデル作成部４１０は通知に基づいて図９Ｂの３５〜３６行のＸＭＬコードを生成し、モデル１０６ａに追加する。
【０２９２】
そして、処理はマージノードのステップＳ１１４を経て次のステップＳ１１５へと進む。
ステップＳ１１４は、ステップＳ１１２からの処理の流れとステップＳ１１３からの処理の流れの合流地点を示すマージノードであり、続いて処理はステップＳ１１５に移行する。
【０２９３】
ステップＳ１１５で部品用メニュー提供部４０５は、ステップＳ１０５で作成されたクラスにポートを作成するか否かを、入力装置４０１からＵＭＬツール１０３を介して与えられる入力に基づいて判断する。例えば、部品用メニュー提供部４０５は、ＵＭＬツール１０３を介して出力装置４０２にダイアログを表示させ、ポートを作成するか否かをユーザに指定させてもよい。
【０２９４】
ポートを作成しない場合、処理はステップＳ１１６に進み、ポートを作成する場合、処理はステップＳ１１９に進む。
ステップＳ１１６では、モデル図１０５の編集を終了するよう指示する入力が入力装置４０１とＵＭＬツール１０３を介して与えられたか否かをメニュー選択部４０４が判断する。編集を終了するよう指示する入力が与えられた場合、図１０の処理は終了する。編集を終了するよう指示する入力が与えられていない場合、処理はステップＳ１０２に戻る。
【０２９５】
さて、メニュー選択部４０４は、「ステップＳ１０３で選択された処理は部品作成処理ではない」と上記のステップＳ１０４において判断した場合、ステップＳ１１７で、「ステップＳ１０３で選択された処理がポート作成処理か否か」を判断する。ポート作成処理が選択された場合、メニュー選択部４０４はポート用メニュー提供部４０６を呼び出し、処理はステップＳ１１８に移行する。他方、ポート作成処理が選択されたのではない場合、処理はステップＳ１２６に移行する。
【０２９６】
ステップＳ１１８でポート用メニュー提供部４０６は、ポートのオブジェクトを作成する対象となる部品のクラスを選択する。例えば、ポート用メニュー提供部４０６は、ポートのオブジェクトを作成する部品のクラスを選択するようユーザに求めるダイアログを、ＵＭＬツール１０３を介して出力装置４０２に出力させる。そして、ポート用メニュー提供部４０６は、ダイアログに対するユーザの入力を、入力装置４０１とＵＭＬツール１０３を介して受け取り、入力にしたがって、ポートのオブジェクトを作成する対象のクラスを選択する。そして、処理はステップＳ１１９に移行する。
【０２９７】
ステップＳ１１９はステップＳ１１５からの処理の流れとステップＳ１１８からの処理の流れの合流地点を示すマージノードである。
なお、ステップＳ１１５からの処理の流れでは、ポートを作成する対象はステップＳ１０５で作成されたクラスであり、ステップＳ１１８からの処理の流れでは、ポートを作成する対象はステップＳ１１８で選択されたクラスである。よって、ステップＳ１１９に続いてステップＳ１２０が実行される際には、ポートを作成する対象は一意に決まっている。
【０２９８】
ステップＳ１２０では、ステップＳ１０５で作成されたか、またはステップＳ１１８で選択された部品のクラスを対象として、ポート用メニュー提供部４０６がポート作成処理を行う。ポート作成処理は、例えば、次の（ｇ１）〜（ｇ４）のような処理を含む。
【０２９９】
（ｇ１）作成するポートの数と種類と名前を指定するようにユーザに促すダイアログを、ＵＭＬツール１０３を介して出力装置４０２に出力させる処理。
（ｇ２）ダイアログへの入力を、入力装置４０１とＵＭＬツール１０３を介して受け取り、入力にしたがってポートを定義する処理。
【０３００】
（ｇ３）定義したポートを表す図形を出力装置４０２に出力するよう、ＵＭＬツール１０３に命令する処理。
（ｇ４）定義したポートの情報をモデル作成部４１０に通知する処理。
【０３０１】
なお、上記（ｇ１）において、ポートの種類とは、図２の第１のメタモデル１０１ａの例で説明すると、データを受ける側の「RequesterPort」クラス２１２なのか、データを出力する側の「ProviderPort」クラス２１３なのか、という種別のことである。また、図２において集約２５９の多重度が「0..*」なので、１つの部品クラスは任意の個数のポートを持つことができる。よって、ステップＳ１２０では、上記（ｇ１）のように、作成するポートの数をダイアログにて指定可能としてもよい。
【０３０２】
また、上記（ｇ４）で通知された情報に基づいて、モデル作成部４１０はモデル１０６を編集する。例えば、ステップＳ１２０で図６の「入力1」ポート６０４と「出力1」ポート６０５が作成された場合、モデル作成部４１０は図９Ｃの５５、５７〜５９、６１行のＸＭＬコードを生成し、モデル１０６ａに追加する。
【０３０３】
ステップＳ１２０に続くステップＳ１２１において、ポート用メニュー提供部４０６は、ステップＳ１２０で作成したポートが使うインタフェースのクラスが作成済みか否かを判断する。
【０３０４】
例えば、ポート用メニュー提供部４０６は、「ステップＳ１２０で作成したポートが使うインタフェースのクラスは作成済みか否か」をユーザに尋ねるダイアログを、ＵＭＬツール１０３を介して出力装置４０２に出力させてもよい。作成したポート用のインタフェースのクラスが作成済みの場合、処理はステップＳ１２２に移行し、未作成の場合は処理がステップＳ１２３に移行する。
【０３０５】
ステップＳ１２２でポート用メニュー提供部４０６は、作成済みのクラスの中から、ステップＳ１２０で作成したポートが使うインタフェースのクラスを選択する。
例えば、ポート用メニュー提供部４０６は、インタフェースのクラスを選択するようユーザに求めるダイアログを、ＵＭＬツール１０３を介して出力装置４０２に出力させる。そして、ポート用メニュー提供部４０６は、ダイアログに対するユーザの入力を、入力装置４０１とＵＭＬツール１０３を介して受け取り、入力にしたがって、ポートが使うインタフェースのクラスを選択する。
【０３０６】
ステップＳ１２２の実行後、次のステップＳ１２５へと制御が移る。
また、ステップＳ１２３では、ポート用メニュー提供部４０６がインタフェース用メニュー提供部４０７を呼び出し、インタフェース用メニュー提供部４０７が新たなインタフェースクラスを作成する。例えば、図３において「インタフェースA」クラス３０２を新たに作成する場合を例に説明すると、ステップＳ１２３でインタフェース用メニュー提供部４０７は、ＵＭＬツール１０３を介して次のように動作し、クラス図（つまりモデル図１０５ａ）を編集する。
【０３０７】
すなわち、インタフェース用メニュー提供部４０７は、第１のメタモデル１０１ａ内の「SenderReceiverInterface」クラス２０９を作成中のクラス図に既にコピーしたか否かを判断する。そして、まだコピーしていなければ、インタフェース用メニュー提供部４０７は第１のメタモデル１０１ａから「SenderReceiverInterface」クラス２０９を読み出し、ＵＭＬツール１０３を介して、作成中のクラス図に「SenderReceiverInterface」クラス２０９をコピーする。
【０３０８】
そして新たなインタフェースクラス用にクラスを表す矩形を作図し、当該矩形から「SenderReceiverInterface」クラス２０９への汎化３０６の線を引くように、インタフェース用メニュー提供部４０７はＵＭＬツール１０３に命令する。その結果、ＵＭＬツール１０３を介して出力装置４０２には、上記矩形と汎化３０６の線が出力される。
【０３０９】
また、インタフェース用メニュー提供部４０７は、ＵＭＬツール１０３を介して、上記の矩形が表すクラスのクラス名を指定する入力を受け付け、受け付けた結果を作成中のクラス図に反映して出力装置４０２に出力させる。
【０３１０】
インタフェース用メニュー提供部４０７はさらに、作成されたクラスの情報をモデル作成部４１０に通知する。すると、モデル作成部４１０は通知された情報に対応するＸＭＬコードを生成することでモデル１０６を作成および編集する。例えば、ステップＳ１２３で図３の「インタフェースA」クラス３０２が作成される場合、モデル作成部４１０は図９Ｄの７５、７６、８５行のコードを生成してモデル１０６ａに追加する。
【０３１１】
次のステップＳ１２４でインタフェース用メニュー提供部４０７は、ステップＳ１２３で作成したインタフェースクラスに含まれるデータ要素を作成する。
図２の第１のメタモデル１０１ａによれば、「SenderReceiverInterface」クラス２０９は「DataElementPrototype」クラス２１０を含みうる。よって、「SenderReceiverInterface」クラス２０９のサブクラスとして定義されるインタフェースクラスは、データ要素を含みうる。
【０３１２】
そこで、このような第１のメタモデル１０１ａにしたがってステップＳ１２４でインタフェース用メニュー提供部４０７は、ステップＳ１２３で作成したインタフェースクラスの属性として、「DataElementPrototype」クラス２１０のインスタンスを作成する。すなわち、インタフェース用メニュー提供部４０７は、ステップＳ１２３で作成したクラスの属性として、インタフェースクラスの有するデータ要素を、ＵＭＬツール１０３を介して作成する。
【０３１３】
例えば、インタフェース用メニュー提供部４０７は、データ要素の個数と、その個数分のデータ要素の名前および型をユーザに入力させるためのダイアログを、ＵＭＬツール１０３を介して出力装置４０２に出力させてもよい。そして、インタフェース用メニュー提供部４０７はダイアログに対する入力を、入力装置４０１とＵＭＬツール１０３を介して受け取る。
【０３１４】
そして、インタフェース用メニュー提供部４０７は、ステップＳ１２３で作成したクラスに、受け取った入力にしたがって属性を設定するようＵＭＬツール１０３に命令する。すると、出力装置４０２には、入力にしたがって属性の名前と型が出力される。
【０３１５】
実施形態によっては、名前と型だけでなく、属性のデフォルト値や可視性に関する入力をさらにインタフェース用メニュー提供部４０７が受け付けてもよい。また、ステップＳ１２４でデータ要素の個数として「0」が入力されても、インタフェース用メニュー提供部４０７は、図２の合成集約２６４の「0..*」という多重度に基づいて、入力は適正であると判断する。その結果、１つもデータ要素が作成されないという場合もありうる。
【０３１６】
なお、ステップＳ１２４の動作の具体例を挙げれば下記のとおりである。すなわち、図３の例では、「インタフェースA」クラス３０２が有するデータ要素の個数として「2」が入力され、１つ目のデータ要素の名前と型として「要素1」と「int」が入力され、２つ目のデータ要素の名前と型として「要素2」と「int」が入力される。その結果、「インタフェースA」クラス３０２には「要素1」と「要素2」という名前の２つの属性が設定され、出力装置４０２には図３の「インタフェースA」クラス３０２のように表示される。
【０３１７】
また、ステップＳ１２４ではさらに、インタフェース用メニュー提供部４０７が、受け取った入力の内容をモデル作成部４１０に通知する。モデル作成部４１０は通知に応じてモデル１０６を編集する。例えば、図３の例では、モデル作成部４１０は、図９Ｄの７７〜８４行のＸＭＬコードを生成し、モデル１０６ａに追加する。
【０３１８】
以上のような一連の処理がステップＳ１２４で実行された後、次のステップＳ１２５へと制御が移る。
ステップＳ１２５でポート用メニュー提供部４０６は、ステップＳ１２０で作成したポートの各々を、ステップＳ１２２で選択されたか、またはステップＳ１２３で作成されたインタフェースクラスに接続する処理を行う。具体的には、ポート用メニュー提供部４０６は、ポートのオブジェクトからインタフェースクラスへの依存の追加をＵＭＬツール１０３に命令するとともに、依存の追加をモデル作成部４１０に通知する。
【０３１９】
例えば、図３の例で、「受信ポート」ポート３０３がステップＳ１２０で作成され、「インタフェースA」クラス３０２がステップＳ１２２で選択されるかステップＳ１２３で作成されたとする。
【０３２０】
この場合、ステップＳ１２５でポート用メニュー提供部４０６は、依存３０７を追加するようＵＭＬツール１０３に命令するので、結果として、出力装置４０２には依存３０７が表示される。また、ポート用メニュー提供部４０６が依存３０７の追加をモデル作成部４１０に通知するので、モデル作成部４１０は、図９Ｂの３８行のＸＭＬコードを生成し、モデル１０６ａに追加する。
以上のステップＳ１２５の実行後、処理はステップＳ１１６に移行する。
【０３２１】
さて、メニュー選択部４０４は、「ステップＳ１０３で選択された処理はポート作成処理ではない」と上記のステップＳ１１７で判断した場合、ステップＳ１２６で、「ステップＳ１０３で選択された処理がインタフェース作成処理か否か」を判断する。インタフェース作成処理が選択された場合、メニュー選択部４０４はインタフェース用メニュー提供部４０７を呼び出し、処理はステップＳ１２７に移行する。他方、インタフェース作成処理が選択されたのではない場合、処理はステップＳ１２９に移行する。
【０３２２】
ステップＳ１２７では、インタフェース用メニュー提供部４０７がインタフェースクラスを作成する。ステップＳ１２７はステップＳ１２３と同様なので、詳しい説明は省略する。
【０３２３】
ステップＳ１２７に続いて、ステップＳ１２８でインタフェース用メニュー提供部４０７は、データ要素作成処理を行う。ステップＳ１２８はステップＳ１２４と同様なので、詳しい説明は省略する。ステップＳ１２８の実行後、処理はステップＳ１１６に移行する。
【０３２４】
さて、メニュー選択部４０４は、「ステップＳ１０３で選択された処理はインタフェース作成処理ではない」と上記のステップＳ１２６で判断した場合、ステップＳ１２９で、「ステップＳ１０３で選択された処理が内部部品作成処理か否か」を判断する。内部部品作成処理が選択された場合、メニュー選択部４０４は内部部品用メニュー提供部４０８を呼び出し、処理はステップＳ１３０に移行する。他方、内部部品作成処理が選択されたのではない場合、処理はステップＳ１３４に移行する。
【０３２５】
ステップＳ１３０で内部部品用メニュー提供部４０８は、内部部品のクラスを選択する。
例えば、内部部品用メニュー提供部４０８は、定義済みの部品クラスの中から、内部部品として使う部品のクラスを選択するようユーザに求めるダイアログを、ＵＭＬツール１０３を介して出力装置４０２に出力させてもよい。そして、内部部品用メニュー提供部４０８は、ダイアログに対する入力を、入力装置４０１からＵＭＬツール１０３を介して受け取り、受け取った入力にしたがって内部部品のクラスを選択してもよい。
【０３２６】
例えば、図６の例において、「部品B」クラス６０１の内部部品である「P1」オブジェクト６０２が作成される場合、ステップＳ１３０では、「P1」オブジェクト６０２が属する図３の「部品A」クラス３０１が選択される。
【０３２７】
続いてステップＳ１３１で内部部品用メニュー提供部４０８は、内部部品のオブジェクトを作成する。具体的には、内部部品用メニュー提供部４０８は以下の（ｈ１）〜（ｈ５）のような処理を行う。なお、以下の（ｈ１）〜（ｈ５）の説明では、図６において「部品B」クラス６０１の内部部品として「P1」オブジェクト６０２が作成される場合を例として挙げる。
【０３２８】
（ｈ１）内部部品用メニュー提供部４０８は、ＵＭＬツール１０３に、ステップＳ１３０で内部部品のクラスとして選択されたクラスをインスタンス化してオブジェクトを作成するよう命令する。
【０３２９】
その結果、例えば、図３の「部品A」クラス３０１から図６の「P1」オブジェクト６０２が作成される。なお、図３のとおり「部品A」クラス３０１が「受信ポート」ポート３０３と「送信ポート」ポート３０４を持つことが定義されているので、図６に示すように、「P1」オブジェクト６０２は「受信ポート」ポート６０６と「送信ポート」ポート６０７を有する。ただし、この段階ではまだ「P1」というオブジェクト名は付けられていない。
【０３３０】
（ｈ２）内部部品用メニュー提供部４０８は、作成したオブジェクトの名前を指定する入力を入力装置４０１からＵＭＬツール１０３を介して受け取るとともに、作成したオブジェクトに当該名前を付けるよう、ＵＭＬツール１０３に命令する。例えば、「P1」という名前が図６の「P1」オブジェクト６０２に付けられる。
【０３３１】
（ｈ３）内部部品用メニュー提供部４０８は、内部部品を含める外部部品を選択する。例えば、内部部品用メニュー提供部４０８は、上記（ｈ１）で作成したオブジェクトを含ませる外部部品のクラスを指定するようユーザに促すダイアログを、ＵＭＬツール１０３を介して出力装置４０２に出力させる。そして、内部部品用メニュー提供部４０８は、ＵＭＬツール１０３を介してダイアログに対する入力装置４０１からの入力を受け取り、受け取った入力にしたがって外部部品のクラスを選択する。例えば、内部部品用メニュー提供部４０８は、外部部品のクラスとして図６の「部品B」クラス６０１を選択する。
【０３３２】
（ｈ４）内部部品用メニュー提供部４０８は、上記（ｈ３）で選択した外部部品のクラスに、上記（ｈ１）で作成した内部部品のオブジェクトを含ませるよう、ＵＭＬツール１０３に命令する。その結果、例えば、図６のとおり「P1」オブジェクト６０２が「部品B」クラス６０１に含まれることとなり、出力装置４０２は「部品B」クラス６０１の矩形の中に「P1」オブジェクト６０２の矩形を表示する。
【０３３３】
（ｈ５）内部部品用メニュー提供部４０８は、上記（ｈ１）〜（ｈ４）の結果定義された部品間の入れ子関係をモデル作成部４１０に通知し、モデル作成部４１０は通知に基づいてモデル１０６を編集する。例えば、「部品B」クラス６０１と「P1」オブジェクト６０２について通知された入れ子関係と、「P1」オブジェクト６０２のオブジェクト名として通知された「P1」という名前に基づいて、モデル作成部４１０は、モデル１０６ａを編集する。具体的には、モデル作成部４１０は、図９Ｃの４７〜４９行のＸＭＬコードを生成してモデル１０６ａに追加する。
【０３３４】
例えば上記の（ｈ１）〜（ｈ５）のような処理がステップＳ１３１で行われると、続いて、処理はステップＳ１３２に移行する。
ステップＳ１３２で内部部品用メニュー提供部４０８は、デレゲートコネクタ作成処理を行う。すなわち、図２の第１のメタモデル１０１ａの「DelegateConnector」クラス２１６のインスタンスとしての、外部部品のポートと内部部品のポートとの間のリンクを、内部部品用メニュー提供部４０８は作成する。例えば、内部部品用メニュー提供部４０８は、ステップＳ１３１で図６の「P1」オブジェクト６０２を作成した場合、ステップＳ１３２ではリンク６１１を作成する。
【０３３５】
なお、図２の第１のメタモデル１０１ａにおける集約２５９の「0..*」という多重度が示すように、内部部品と外部部品は、いずれも、ポートを持たないかもしれないし、１個以上の任意の個数のポートを持つかもしれない。よって、ステップＳ１３２では、結果的にはリンクが作成されないこともあるし、１本または複数本のリンクが作成されることもある。
【０３３６】
具体的には、内部部品用メニュー提供部４０８は、ステップＳ１３１で作成した内部部品のポートを、上記（ｈ３）で選択した外部部品のポートと接続するためのユーザインタフェースを、ＵＭＬツール１０３を介して提供する。当該ユーザインタフェースは、例えば、内部部品と外部部品のポート同士を接続するか否かをユーザに尋ねるダイアログを含んでもよい。また、当該ユーザインタフェースは、接続対象の内部部品と外部部品のポートの組を、ＵＭＬツール１０３を介してユーザに指定させる機能を有する。
【０３３７】
内部部品用メニュー提供部４０８は、入力装置４０１からＵＭＬツール１０３と上記ユーザインタフェースを介して与えられた入力を受け取り、入力が上記（ｄ６）と（ｄ８）の制約を満たすか否を判断する。内部部品用メニュー提供部４０８は、入力が（ｄ６）と（ｄ８）の制約を満たせば入力にしたがってリンクを作成し、逆に、入力が（ｄ６）と（ｄ８）の制約を満たさなければ、ＵＭＬツール１０３を介して出力装置４０２に警告を表示させる。
【０３３８】
以上のとおりステップＳ１３２では、場合によってはリンクが作成されず、場合によっては１本以上のリンクが作成される。リンクが作成される場合は、上記の制御により、当該リンクは（ｄ６）と（ｄ８）の制約を満たす。
【０３３９】
さらに、ステップＳ１３２で内部部品用メニュー提供部４０８は、作成したリンクの情報をモデル作成部４１０に通知する。モデル作成部４１０は通知にしたがってＸＭＬコードを生成しモデル１０６を編集する。例えば、図６のリンク６１１が作成された場合、モデル作成部４１０は図９Ｃの６６〜６９行目のＸＭＬコードを生成してモデル１０６ａに追加する。
【０３４０】
次に、ステップＳ１３３で内部部品用メニュー提供部４０８は、アセンブリコネクタ作成処理を行う。すなわち、図２の第１のメタモデル１０１ａの「AssemblyConnector」クラス２１５のインスタンスとしての、内部部品同士のポート間のリンクを、内部部品用メニュー提供部４０８は作成する。例えば、図６の「P1」オブジェクト６０２が作成済みの状況で「P2」オブジェクト６０３がステップＳ１３１で作成された場合、ステップＳ１３３で内部部品用メニュー提供部４０８は、リンク６１２を作成する。
【０３４１】
なお、図２の第１のメタモデル１０１ａにおける集約２５９の「0..*」という多重度が示すように、内部部品は、ポートを持たないかもしれないし、１個以上の任意の個数のポートを持つかもしれない。よって、ステップＳ１３３では、結果的にはリンクが作成されないこともあるし、１本または複数本のリンクが作成されることもある。
【０３４２】
具体的には、内部部品用メニュー提供部４０８は、ステップＳ１３１で作成した内部部品のポートを、上記（ｈ３）で選択した外部部品のポート内の既存の他の内部部品のポートと接続するためのユーザインタフェースを、ＵＭＬツール１０３を介して提供する。当該ユーザインタフェースは、例えば、内部部品同士のポート間を接続するか否かをユーザに尋ねるダイアログを含んでもよい。また、当該ユーザインタフェースは、接続対象の２つの内部部品それぞれのポートを、ＵＭＬツール１０３を介してユーザに指定させる機能を有する。
【０３４３】
内部部品用メニュー提供部４０８は、入力装置４０１からＵＭＬツール１０３と上記ユーザインタフェースを介して与えられた入力を受け取り、入力が上記（ｄ７）と（ｄ８）の制約を満たすか否を判断する。内部部品用メニュー提供部４０８は、入力が（ｄ７）と（ｄ８）の制約を満たせば入力にしたがってリンクを作成し、逆に、入力が（ｄ７）と（ｄ８）の制約を満たさなければ、ＵＭＬツール１０３を介して出力装置４０２に警告を表示させる。
【０３４４】
以上のとおりステップＳ１３３では、場合によってはリンクが作成されず、場合によっては１本以上のリンクが作成される。リンクが作成される場合は、上記の制御により、当該リンクは（ｄ７）と（ｄ８）の制約を満たす。
【０３４５】
さらに、ステップＳ１３３で内部部品用メニュー提供部４０８は、作成したリンクの情報をモデル作成部４１０に通知する。モデル作成部４１０は通知にしたがってＸＭＬコードを生成しモデル１０６を編集する。例えば、図６のリンク６１２が作成された場合、モデル作成部４１０は図９Ｃの６２〜６５行目のＸＭＬコードを生成してモデル１０６ａに追加する。
【０３４６】
以上の一連の処理が実行された後、処理はステップＳ１１６に移行する。
さて、メニュー選択部４０４は、「ステップＳ１０３で選択された処理は内部部品作成処理ではない」と上記ステップＳ１２９で判断した場合、タスク用メニュー提供部４０９を呼び出し、処理はステップＳ１３４に移行する。そして、ステップＳ１３４でタスク用メニュー提供部４０９はタスク作成処理を行う。
【０３４７】
すなわち、タスク用メニュー提供部４０９は、第１のメタモデル１０１ａの「Task」クラス２０６をインスタンス化したオブジェクトを作成することで、新たなタスクを作成する。
【０３４８】
すなわち、タスク用メニュー提供部４０９は、ＵＭＬツール１０３を介して、「Task」クラス２０６をインスタンス化して新たなオブジェクトを作成し、入力装置４０１からの入力にしたがってオブジェクトに名前を付ける。そして、タスク用メニュー提供部４０９は、作成したタスクのオブジェクトを表す図形を、ＵＭＬツール１０３を介して出力装置４０２に出力させる。
【０３４９】
例えば、タスク用メニュー提供部４０９は、図７の「T1」オブジェクト７０４を作成し、入力装置４０１からの入力にしたがって「T1」というオブジェクト名を付ける。そして、ＵＭＬツール１０３を介してタスク用メニュー提供部４０９は、出力装置４０２に、「T1」オブジェクト７０４を示す矩形を図７のようにモデル図１０５ｃ上に表示させる。
【０３５０】
また、ステップＳ１３４でタスク用メニュー提供部４０９はさらに、作成したタスクのオブジェクトに関する情報をモデル作成部４１０に通知する。モデル作成部４１０は通知された情報に基づいてＸＭＬコードを生成し、モデル１０６を編集する。例えば、図７の「T1」オブジェクト７０４が作成された場合、モデル作成部４１０は図９Ａの１４行目と２７行目のＸＭＬコードを生成し、モデル１０６ａに追加する。
【０３５１】
以上の一連の処理の実行後、処理はステップＳ１１６に移行する。
なお、図１０に関しては、説明の簡略化のため、メニューには部品作成処理、ポート作成処理、インタフェース作成処理、内部部品作成処理およびタスク作成処理のみが含まれると仮定している。そのため、ステップＳ１２９からステップＳ１３４へ上記のように処理が移行する。
【０３５２】
しかし、実施形態によっては、さらに別種の処理があってもよく、それに応じてメニュー選択部４０４による処理分岐制御が図１０に示すフローチャートと異なっていてもよい。例えば、モデル作成ナビゲーション部４０３は下記（ｉ１）〜（ｉ３）などのメニューをさらに提供してもよい。
（ｉ１）作成済みのインタフェースクラスにおいて、データ要素の追加・編集・削除を行うためのメニュー。
（ｉ２）作成済みの部品クラスにおいて、ポートの追加・削除を行うためのメニュー。
（ｉ３）リンクの追加・削除・繋ぎなおしのためのメニュー。
（ｉ４）ポートのオブジェクトとインタフェースのクラスの間の依存を設定しなおすためのメニュー。
（ｉ５）作成済みの部品クラス内の属性・操作・ステレオタイプに関して、追加・編集・削除を行うためのメニュー。
【０３５３】
例えば上記（ｉ１）〜（ｉ５）のようなメニューが存在する場合、モデル作成ナビゲーション部４０３は上記（ｉ１）〜（ｉ５）のメニューにおける処理結果をモデル作成部４１０に通知し、モデル作成部４１０は通知にしたがってモデル１０６ａを編集する。
【０３５４】
また、部品作成処理、ポート作成処理、インタフェース作成処理および内部部品作成処理はクラス図の編集に関連する処理である。しかし、モデル作成ナビゲーション部４０３は、オブジェクト図の編集に関する各種メニューも同様に提供することができる。
【０３５５】
例えば、定義済みの部品クラスをインスタンス化したオブジェクトを作成するメニュー、作成された部品のオブジェクト同士をポート間のリンクにより接続するメニューなどをモデル作成ナビゲーション部４０３は提供してもよい。そして、モデル作成ナビゲーション部４０３は、リンクの接続においては、上記（ｄ７）と（ｄ８）の制約条件が満たされるか否かの確認を行う。
【０３５６】
また、モデル作成ナビゲーション部４０３は、図７の「ソフトウェア全体」クラス７０１のように<<TopLevel>>というステレオタイプが付加された特殊なクラスのインスタンスを、オブジェクト図内に１つ作成するメニューを提供してもよい。
【０３５７】
ところで、ソフトウェアのモデルの静的な側面はクラス図やオブジェクト図により表されるが、動的な一側面は、図８のようにシーケンス図を使って表現することができる。第１実施形態のＤＳＭ支援装置１０４は、シーケンス図を使ったモデル化にも対応している。
【０３５８】
図１１は、第１実施形態による駆動順序定義処理を説明する図である。つまり、図１１の駆動順序定義処理は、タスクから部品を駆動する順序を図８のようにシーケンス図を使って定義する処理である。なお、図１１もＵＭＬのアクティビティ図の形式で表現されている。
【０３５９】
図８のようにシーケンス図を使ってモデル化の作業を行うためのメニューを選択する入力を、図４の入力装置４０１とＵＭＬツール１０３を介してＤＳＭ支援装置１０４のモデル作成ナビゲーション部４０３が受け取ると、図１１の駆動順序定義処理が開始される。
【０３６０】
ステップＳ２０１でモデル作成ナビゲーション部４０３は、作成済みのモデル図１０５の中からタスクを選択するようにユーザに促す表示（例えばダイアログの表示）を、ＵＭＬツール１０３を介して行う。そして、モデル作成ナビゲーション部４０３は、入力装置４０１とＵＭＬツール１０３を介してタスクを選択する入力を受け取る。
【０３６１】
例えば、図８の例では、図７のモデル図１０５ｃで定義済みの「Task」クラス２０６の「T1」オブジェクト７０４を指定する入力を、ステップＳ２０１でモデル作成ナビゲーション部４０３が受け取る。ステップＳ２０１でモデル作成ナビゲーション部４０３は、例えば、「Task」クラス２０６以外のクラスのオブジェクトが指定されたら、ＵＭＬツール１０３を介して出力装置４０２に警告を出力してもよい。
【０３６２】
次のステップＳ２０２は、ステップＳ２０１からの処理の流れと後述のステップＳ２０５からの処理の流れが合流するマージノードである。
ステップＳ２０２の次のステップＳ２０３で、モデル作成ナビゲーション部４０３は、ステップＳ２０１で選択されたタスクから駆動する部品を選択する。例えば、モデル作成ナビゲーション部４０３は、作成済みのモデル図１０５の中から駆動対象の部品のオブジェクトを選択するように、ユーザに促す表示（例えばダイアログの表示）を、ＵＭＬツール１０３を介して行う。そして、モデル作成ナビゲーション部４０３は、入力装置４０１とＵＭＬツール１０３を介して部品のオブジェクトを選択する入力を受け取り、入力にしたがってオブジェクトを選択する。
【０３６３】
例えば、図８の例では、図７のモデル図１０５ｃで定義済みの「PART1」オブジェクト７０２を指定する入力を、ステップＳ２０３でモデル作成ナビゲーション部４０３が受け取る。
【０３６４】
ステップＳ２０３でモデル作成ナビゲーション部４０３は、例えば、「CompositionType」クラス２０２のサブクラスのオブジェクト以外を指定する入力を不正な入力として拒絶してもよい。また、モデル作成ナビゲーション部４０３は、指定されたオブジェクトのクラスにおいて、<<RunnableEntity>>というステレオタイプが付けられた操作が定義されていない場合、入力が不正であると見なす。そして、モデル作成ナビゲーション部４０３は、不正な入力に対して、ＵＭＬツール１０３を介して出力装置４０２に警告を出力してもよい。
【０３６５】
部品のオブジェクトが選択されると、続いてステップＳ２０４において、モデル作成ナビゲーション部４０３は、ステップＳ２０１で選択されたタスクとステップＳ２０３で選択された部品の接続処理を行う。すなわち、モデル作成ナビゲーション部４０３は、下記（ｊ１）〜（ｊ４）のような処理を行う。
【０３６６】
（ｊ１）モデル作成ナビゲーション部４０３は、選択されたタスクから呼び出す操作を指定するようユーザに促す表示（例えばダイアログの表示）を、ＵＭＬツール１０３を介して行う。そして、モデル作成ナビゲーション部４０３は、入力装置４０１とＵＭＬツール１０３を介して、指定された操作の名前を受け取る。例えば、図８の「PART1」オブジェクト７０２がステップＳ２０３で選択された場合、モデル作成ナビゲーション部４０３は「実行ポイント」という操作名を受け取る。
【０３６７】
（ｊ２）モデル作成ナビゲーション部４０３は、ＵＭＬツール１０３を介して入力装置４０１から、矢印の起点と終点を示す入力を受け取る。なお、モデル作成ナビゲーション部４０３は、ステップＳ２０１で選択したタスクの活性期間の範囲内のみが矢印の起点として指定可能なように、かつステップＳ２０３で選択した部品の活性期間の範囲内のみが矢印の終点として指定可能なように、制約をかける。
【０３６８】
例えば、呼び出し８０４の起点と終点を示す入力をモデル作成ナビゲーション部４０３は受け取る。呼び出し８０４の矢印の起点は、ステップＳ２０１で選択された「T1」オブジェクト７０４の活性期間８０１の範囲内であり、呼び出し８０４の矢印の終点は、ステップＳ２０３で選択された「PART1」オブジェクト７０２の活性期間８０２の範囲内である。
【０３６９】
（ｊ３）上記（ｊ１）で指定された名前をラベルとして有し、上記（ｊ２）で指定された起点から終点へ向かう矢印を、作成中のシーケンス図に追加するように、モデル作成ナビゲーション部４０３はＵＭＬツール１０３に命令する。ＵＭＬツール１０３は、呼び出しを示す矢印を、命令にしたがってシーケンス図に追加し、出力装置４０２は追加された矢印とラベルを表示する。例えば、図８の呼び出し８０４の矢印とラベルが出力装置４０２に表示される。
【０３７０】
（ｊ４）モデル作成ナビゲーション部４０３は上記（ｊ３）で追加した呼び出しの内容および順序をモデル作成部４１０に通知する。するとモデル作成部４１０は、通知された内容にしたがってモデル１０６を編集する。例えば、図８の呼び出し８０４が追加された場合、モデル作成部４１０は図９Ａの１５〜２０行目のＸＭＬコードを生成し、モデル１０６ａに追加する。仮に、先に呼び出し８０５が定義された後で呼び出し８０４が追加された場合には、モデル作成部４１０は、図９Ａの既存の２２行目の「NO」要素の値を「1」から「2」に書き直し、新たな１６行目の「NO」要素の値を「1」に設定する。
【０３７１】
以上の（ｊ１）〜（ｊ４）のような処理がステップＳ２０４で行われると、処理はステップＳ２０５に移行する。
ステップＳ２０５でモデル作成ナビゲーション部４０３は、駆動順序定義処理を終了するよう指示する終了指示が入力装置４０１とＵＭＬツール１０３を介して入力されたか否かを判断する。終了指示が入力された場合、シーケンス図の形で作成された最終的なモデル図１０５は、ＵＭＬツール１０３を介してモデル図格納部４１２に格納され、図１１の駆動順序定義処理は終了する。終了指示が入力されなければ、制御はステップＳ２０２のマージノードに戻り、再度ステップＳ２０３から処理が繰り返される。
【０３７２】
図１２は、第１実施形態によるコード生成処理を説明する図である。なお、図１２もＵＭＬのアクティビティ図の形式で表現されている。
ステップＳ３０１でコード生成装置１０８は、メタモデル１０１と表記ルール１０２にしたがって作成されたモデル１０６の入力を受け付ける。具体的には、コード生成装置１０８は図４の意味モデル格納部４１３に格納されているモデル１０６を読み出す。
【０３７３】
そして、ステップＳ３０２においてコード生成装置１０８は、モデル１０６を中間データ１１０に変換する。中間データ１１０は、コード生成に必要な情報を、コード生成にとって扱いやすくまとめたデータ群を含み、ＸＭＬデータである。第１実施形態では、ＸＳＬＴ（XSL Transformations）によるコード生成のためにステップＳ３０２が行われる。
【０３７４】
なお、モデル１０６の形式（すなわちＸＭＬデータであるモデル１０６のスキーマ）は実施形態に応じて様々であり、スキーマによってはステップＳ３０２が省略可能なこともある。
【０３７５】
最後に、ステップＳ３０３でコード生成装置１０８はコード生成処理を行う。すなわち、コード生成装置１０８は、図４のテンプレート格納部４１４からコード生成テンプレート１０７を読み出し、ＸＭＬ形式の中間データ１１０にＸＳＬ形式のコード生成テンプレート１０７を適用することで、ソースコード１０９を生成する。
【０３７６】
なお、コード生成テンプレート１０７を差し替えることにより、生成するソースコード１０９の言語を変更することが可能である。例えば、Ｊａｖａ（登録商標）用のコード生成テンプレート１０７を用いれば、Ｊａｖａ（登録商標）で書かれたソースコード１０９が生成され、Ｃ＋＋用のコード生成テンプレート１０７を用いれば、Ｃ＋＋で書かれたソースコード１０９が生成される。実施形態によっては、コード生成テンプレート１０７を選択する入力を、ステップＳ３０３でコード生成装置１０８が入力装置４０１から受け付けてもよい。
【０３７７】
以上のとおり詳細に説明した第１実施形態について概観すると、次のとおりである。
第１実施形態において、メタモデル１０１は、ＵＭＬで表記された第１のクラス図によりソフトウェアをメタモデル化して表す。そして、メタモデル１０１は、ソフトウェアが含む部品をメタモデル化したメタ部品クラス（例えば「CompositionType」クラス２０２）の定義を含む。ＤＳＭ支援装置１０４のモデル作成ナビゲーション部４０３は、図１０のステップＳ１０１に示すように、メタモデル１０１を取得するメタモデル取得ステップを実行する。
【０３７８】
さらに、モデル作成ナビゲーション部４０３内の部品用メニュー提供部４０５は、図１０のステップＳ１０５に示すように、クラス図生成ステップを実行する。つまり、部品用メニュー提供部４０５は、ソフトウェアに含まれる部品を表す部品クラス（例えば「部品A」クラス３０１）を、メタ部品クラス（例えば「CompositionType」クラス２０２）のサブクラスとして定義する。それにより、部品用メニュー提供部４０５は、ソフトウェアをメタモデルにしたがってモデル化したモデルを、部品クラスを含みＵＭＬで表記される第２のクラス図（例えばモデル図１０５ａ）として生成する。
【０３７９】
また、部品用メニュー提供部４０５は作成した部品クラスに関する情報をモデル作成部４１０に通知する。そして、モデル作成部４１０は通知された情報にしたがって、第２のクラス図（例えばモデル図１０５ａ）の意味を所定の形式言語（例えばＸＭＬ）により表す意味モデル（例えばモデル１０６ａ）を生成する。意味モデルの生成は、部品クラスからメタ部品クラスへの汎化（例えば図３の汎化３０６）とメタモデルに基づく。また、上記「意味」とは、具体的には、「第２のクラス図における部品クラスが（インタフェースなどではなく）部品をモデル化したクラスである」という意味である。
【０３８０】
また、第１実施形態では、メタモデル１０１を示す第１のクラス図は、部品間の通信のインタフェースをメタモデル化したメタインタフェースクラス（例えば「SenderReceiverInterface」クラス２０９）の定義をさらに含む。
【０３８１】
そして、第２のクラス図の生成において、インタフェース用メニュー提供部４０７は、部品間の通信のインタフェースをモデル化したインタフェースクラス（例えば「インタフェースA」クラス３０２）を、メタインタフェースクラスのサブクラスとして定義する。なお、インタフェースクラスは、第２のクラス図（例えばモデル図１０５ａ）において定義される。また、第２のクラス図の生成においてインタフェース用メニュー提供部４０７はさらに、インタフェースクラスとの間の関係（例えば依存３０７や３０８）を用いて、部品間の前記通信を前記第２のクラス図において表記する。
【０３８２】
そして、意味モデルとしてモデル１０６を生成するにあたり、モデル作成部４１０は、例えば依存３０７などの上記関係を、部品間のインタフェースを介した通信を意味する所定の形式言語のコード（例えば図９Ｂの３７〜４０行）で表現する。なお、このコードは、インタフェースクラスからメタインタフェースクラスへの汎化（例えば汎化３０６）に基づいて生成される。そして、モデル作成部４１０は、意味モデルとしてのモデル１０６に、当該コードを含める。
【０３８３】
第１実施形態ではさらに、メタモデル１０１を示す第１のクラス図には、メタ部品クラス（例えば「CompositionType」クラス２０２）に含まれるクラスとして、メタ通信ポートクラス（例えば「Port」クラス２１１とそのサブクラス）が定義されている。
【０３８４】
よって、上記第２のクラス図（例えばモデル図１０５ａ）の生成にあたり、ポート用メニュー提供部４０６は、部品クラス（例えば「部品A」クラス３０１）を、メタ通信ポートクラスのオブジェクトである通信ポートオブジェクトを含むように定義してもよい。通信ポートオブジェクトの具体例は、図３の「受信ポート」ポート３０３と「送信ポート」ポート３０４である。なお、実施形態によっては、通信ポートオブジェクトは、メタ通信ポートクラスのサブクラスとしてモデル図１０５などで定義される通信ポートクラスのオブジェクトでもよい。
【０３８５】
こうして部品クラスが通信ポートオブジェクトを含むように定義される場合、ポート用メニュー提供部４０６は、次のように動作する。すなわち、ポート用メニュー提供部４０６は、通信ポートオブジェクトからインタフェースクラスへの依存（例えば依存３０７）を用いて、部品間のインタフェースを介した通信を第２のクラス図（例えばモデル図１０５ａ）において表記する。
【０３８６】
また、第１実施形態では、メタモデル１０１を表す第１のクラス図には、部品同士が入れ子になってもよいことを示すための第１の集約関係（例えば集約２５３）も定義されている。さらに、第１のクラス図には、入れ子になった内部部品を有する外部部品の内部での、外部部品と内部部品との間の通信を表すためのメタ内部通信クラスとして、例えば「DelegateConnector」クラス２１６も定義されている。そして、メタ部品クラスにメタ内部通信クラスが含まれることを示す第２の集約関係（例えば集約２６８）も定義されている。
【０３８７】
したがって、第１実施形態では、内部部品用メニュー提供部４０８が次のように動作することができる。なお、ソフトウェアのモデルを表す第２のクラス図（例えばモデル図１０５ｂ）において部品クラスが複数あり、そのうち外部部品クラスの中に、内部部品クラスが入れ子になって含まれるとする。外部部品クラスの例は、「部品B」クラス６０１であり、内部部品クラスの例は「部品A」クラス３０１である。
【０３８８】
このとき、内部部品用メニュー提供部４０８は、外部部品クラスと内部部品クラスの間に、メタ内部通信クラス（例えば「DelegateConnector」クラス２１６）に対応する関係である内部通信関係（例えばリンク６１１）を定義する。
【０３８９】
すると、モデル作成部４１０は、モデル１０６の生成において、内部通信関係を、外部部品クラスと内部部品クラスの間の通信を意味する所定の形式言語のコード（例えば図９Ｃの６６〜６９行目）で表現し、意味モデルに当該コードを含める。当該コードは、外部部品クラスと内部部品クラスそれぞれからのメタ部品クラスへの汎化（例えば汎化３０５と汎化６１０）とメタ内部通信クラスの定義とに基づき生成される。
【０３９０】
また、第１実施形態では、モデル図１０５ａや１０５ｂのようなクラス図で定義された部品クラスのオブジェクトを定義する図７のモデル図１０５ｃようなオブジェクト図に含まれるオブジェクト間の呼び出しを定義するシーケンス図も生成される。例えば、モデル作成ナビゲーション部４０３が図８のようなモデル図１０５ｄを、制約をかけてナビゲーションしながら生成する。
【０３９１】
すると、モデル作成部４１０は、シーケンス図の内容に基づいて、呼び出しの順序を所定の言語で表すコード（例えば図９Ａの１５〜２６行目）を生成し、当該コードを意味モデルとしてのモデル１０６に含める。
【０３９２】
続いて、図２の第１のメタモデル１０１ａ以外のメタモデルを用いる他の実施形態について説明する。具体的には、図１３〜１５を参照して第２実施形態について説明し、図１６〜１７を参照して第３実施形態について説明する。
【０３９３】
なお、以下に説明する第２・第３実施形態においても、第１実施形態に関して図１を参照して説明した全体的な処理の流れは変わらない。また、図４と類似のＤＳＭ支援装置１０４や記憶装置４１１により、図１のプロセスＰ１０１におけるモデル編集処理が行われる。
【０３９４】
ただし、メタモデル１０１の違いに応じて、表記ルール１０２やコード生成テンプレート１０７の具体的内容には差があり、また、図４のモデル作成ナビゲーション部４０３内の各コンポーネントの動作にも、メタモデルの特徴に応じて多少の差がある。以下では、第２・第３実施形態について、第１実施形態との差を中心に説明し、第１実施形態と同様の点については説明を適宜省略する。
【０３９５】
図１３は、第２のメタモデルを表すＵＭＬのクラス図である。第２のメタモデルは第１のメタモデルの一部を変更したものなので、変更点を中心に説明し、共通点の説明は適宜省略する。
【０３９６】
図１３の第２のメタモデル１０１ｂには、図２の第１のメタモデル１０１ａのうち、「RunnableEntity」クラス２０５およびそれにつながる集約２５５、関連２５６、関連２５８が存在しない。
【０３９７】
また、第１のメタモデル１０１ａでは、「Task」クラス２０６と「RunnableConnector」クラス２０７の間の集約２５７の多重度が「1..*」だが、第２のメタモデル１０１ｂでは多重度が異なる。すなわち、第２のメタモデル１０１ｂでは、「Task」クラス２０６が１つの「RunnableConnector」クラス２０７を含むことを示す、多重度が「1」の集約９０１が、「Task」クラス２０６と「RunnableConnector」クラス２０７の間に定義されている。
【０３９８】
そして、第２のメタモデル１０１ｂでは、さらに「RunnableEntityPort」クラス９０２と「PrevPort」クラス９０３と「NextPort」クラス９０４が定義されている。そして、「RunnableEntityPort」クラス９０２が「PrevPort」クラス９０３のスーパクラスであることを示す汎化９０５と、「RunnableEntityPort」クラス９０２が「NextPort」クラス９０４のスーパクラスであることを示す汎化９０６も定義されている。
【０３９９】
第２のメタモデル１０１ｂではさらに、「RunnableConnector」クラス２０７が「RunnableEntityPort」クラス９０２を「prevPort」というロール名で参照することを示す関連９０７が定義されている。また、「RunnableConnector」クラス２０７が「RunnableEntityPort」クラス９０２を「nextPort」というロール名で参照することを示す関連９０８も定義されている。
【０４００】
また、第２のメタモデル１０１ｂでは、メタ部品クラスとしての「CompositionType」クラス２０２を汎化した「ComponentType」クラス２０１が「PrevPort」クラス９０３を１つ含みうることを示す、多重度が「0..1」の集約９０９が定義されている。同様に、「ComponentType」クラス２０１が「NextPort」クラス９０４を１つ含みうることを示す、多重度が「0..1」の集約９１０も定義されている。
【０４０１】
以上のように定義された第２のメタモデル１０１ｂの、第１のメタモデル１０１ａとの意味的な違いは以下のとおりである。
第１のメタモデル１０１ａは、オブジェクトの駆動順序を図８のようなシーケンス図により定義するためのメタモデルである。それに対し、第２のメタモデル１０１ｂは、オブジェクトの駆動順序を後述の図１５のようなオブジェクト図により定義するためのメタモデルである。そして、「RunnableEntityPort」クラス９０２は、オブジェクトの駆動順序を示すためのポートをメタモデル化したものである。
【０４０２】
すなわち、第２のメタモデル１０１ｂでは、まずタスクが起動し、部品のオブジェクトのうち最初の１つをタスクが呼び出して駆動することが、以下の（ｋ１）〜（ｋ３）の点によりメタモデル化されている。
（ｋ１）集約９０１の多重度が「1」であること。
（ｋ２）「Task」クラス２０６と集約９０１で結ばれた「RunnableConnector」クラス２０７から「RunnableEntityPort」クラス９０２への参照を示す関連９０７が定義されていること。
（ｋ３）「CompositionType」クラス２０２は、関連９０７により「RunnableConnector」クラス２０７から参照される「RunnableEntityPort」クラス９０２のサブクラスである「PrevPort」クラス９０３のオブジェクトを１つ含みうること。
なお、上記（ｋ３）の点は、「CompositionType」クラス２０２が「ComponentType」クラス２０１のサブクラスであることから明らかである。
【０４０３】
そして、第２のメタモデル１０１ｂではさらに、オブジェクトが駆動順序にしたがって順次、次のオブジェクトを呼び出して駆動する能力があることが、以下の（ｌ１）〜（ｌ４）の点によりメタモデル化されている。
（ｌ１）メタ部品クラスである「CompositionType」クラス２０２が、１つの「NextPort」クラス９０４を含みうること。
（ｌ２）「NextPort」クラス９０４のスーパクラスである「RunnableEntityPort」クラス９０２は、関連９０８が示すように、「RunnableConnector」クラス２０７から「nextPort」のロール名で参照されること。
（ｌ３）「RunnableConnector」クラス２０７は、関連９０７に示すように「prevPort」という別のロール名によっても「RunnableEntityPort」クラス９０２を参照すること。
（ｌ４）メタ部品クラスである「CompositionType」クラス２０２は、関連９０７により参照される「RunnableEntityPort」クラス９０２のサブクラスである「PrevPort」クラス９０３のオブジェクトを１つ含みうること。
なお、上記（ｌ１）と（ｌ４）の点は、「CompositionType」クラス２０２が「ComponentType」クラス２０１のサブクラスであることから明らかである。
【０４０４】
以上を換言すれば、第２のメタモデル１０１ｂは、各オブジェクトが、当該オブジェクトを駆動する他のオブジェクト（またはタスク）と接続されるポートと、当該オブジェクトが駆動する次のオブジェクトと接続されるポートを含むことをメタモデル化している。よって、第２のメタモデル１０１ｂによれば、部品のオブジェクト間の駆動順序をポート間の接続により表すことができるので、オブジェクト図により駆動順序をモデル化することが可能となる。
【０４０５】
図１４は、第２のメタモデルにしたがう第３のモデルを表すＵＭＬのクラス図である。図３と同様に図１４のモデル図１０５ｅには、メタ部品クラスおよびメタインタフェースクラスとして、図１３の第２のメタモデル１０１ｂで定義された「CompositionType」クラス２０２と「SenderReceiverInterface」クラス２０９が含まれる。
【０４０６】
モデル図１０５ａは、ユーザ定義の３つのクラス、すなわち、「部品1」クラス１００１と「部品2」クラス１００２と「インタフェース1」クラス１００３を含む。
「部品1」クラス１００１は、「RequesterPort」クラス２１２のオブジェクトである「in」ポート１００４と、「ProviderPort」クラス２１３のオブジェクトである「out」ポート１００５を含む。また、「部品1」クラス１００１は、「PrevPort」クラス９０３のオブジェクトである「prev」ポート１００６と、「NextPort」クラス９０４のオブジェクトである「next」ポート１００７を含む。
【０４０７】
同様に、「部品2」クラス１００２は、「RequesterPort」クラス２１２のオブジェクトである「in」ポート１００８と、「ProviderPort」クラス２１３のオブジェクトである「out」ポート１００９を含む。また、「部品2」クラス１００２は、「PrevPort」クラス９０３のオブジェクトである「prev」ポート１０１０と、「NextPort」クラス９０４のオブジェクトである「next」ポート１０１１を含む。
【０４０８】
また、モデル図１０５ｅでは、「部品1」クラス１００１が「CompositionType」クラス２０２のサブクラスであることを示す汎化１０１２が定義されている。同様に、「部品2」クラス１００２が「CompositionType」クラス２０２のサブクラスであることを示す汎化１０１３も定義されている。さらに、「インタフェース1」クラス１００３が「SenderReceiverInterface」クラス２０９のサブクラスであることを示す汎化１０１４も定義されている。
【０４０９】
そして、モデル図１０５ｅでは、「in」ポート１００４から「インタフェース1」クラス１００３への依存１０１５と、「out」ポート１００５から「インタフェース1」クラス１００３への依存１０１６が定義されている。同様に、「in」ポート１００８から「インタフェース1」クラス１００３への依存１０１７と、「out」ポート１００９から「インタフェース1」クラス１００３への依存１０１８も定義されている。
【０４１０】
モデル図１０５ｅは、第２のメタモデル１０１ｂおよび表記ルール１０２に適合するクラス図であり、具体的には図３に関して説明した（ｃ１）〜（ｃ４）と同様の制約条件を満たす。モデル図１０５ｅが制約条件を満たすのは、ＤＳＭ支援装置１０４が第２のメタモデル１０１ｂと表記ルール１０２に基づいて制約をかけながらモデル図１０５ｅの作成および編集を行うからである。
【０４１１】
なお、説明の簡略化のため、図１４では<<ConfigParam>>というステレオタイプと、各クラス内の属性および操作については省略して示している。しかし、図３の例と同様に、（ｃ５）と（ｃ７）の制約条件も満たすように、ＤＳＭ支援装置１０４が制約をかけながらモデル図１０５ｅを作成するので、モデル図１０５ｅは（ｃ５）と（ｃ７）の制約条件も満たす。
【０４１２】
図１５は、上記の図１４のモデルの利用例を示すＵＭＬのオブジェクト図である。図１５のモデル図１０５ｆは、第２のメタモデル１０１ｂにしたがうモデルをオブジェクト図の形で表現したものである。
【０４１３】
モデル図１０５ｆは、第２のメタモデル１０１ｂの「Task」クラス２０６をインスタンス化した「T1」オブジェクト１１０１を含む。
また、モデル図１０５ｆは、モデル図１０５ｅで定義された「部品1」クラス１００１をインスタンス化した「B1」オブジェクト１１０２と、「部品2」クラス１００２をインスタンス化した「B2」オブジェクト１１０３を含む。モデル図１０５ｆはさらに、「部品1」クラス１００１をインスタンス化した「B11」オブジェクト１１０４と、「部品2」クラス１００２をインスタンス化した「B22」オブジェクト１１０５も含む。
【０４１４】
図１４に示すように「部品1」クラス１００１と「部品2」クラス１００２はそれぞれ４つのポートを含む。したがって、「B1」オブジェクト１１０２は、「prev」ポート１１０６、「next」ポート１１０７、「in」ポート１１０８および「out」ポート１１０９を含む。
【０４１５】
同様に、「B2」オブジェクト１１０３は、「prev」ポート１１１０、「next」ポート１１１１、「in」ポート１１１２および「out」ポート１１１３を含む。同様に、「B11」オブジェクト１１０４は、「prev」ポート１１１４、「next」ポート１１１５、「in」ポート１１１６および「out」ポート１１１７を含む。同様に、「B22」オブジェクト１１０５は、「prev」ポート１１１８、「next」ポート１１１９、「in」ポート１１２０および「out」ポート１１２１を含む。
【０４１６】
そして、モデル図１０５ｆには、部品の駆動順序を示すための複数のリンクが定義されている。すなわち、「T1」オブジェクト１１０１と「prev」ポート１１０６の間のリンク１１２２は、まず「T1」オブジェクト１１０１が「B1」オブジェクト１１０２を駆動することを示す。そして、「next」ポート１１０７と「prev」ポート１１１０の間のリンク１１２３は、次に「B1」オブジェクト１１０２が「B2」オブジェクト１１０３を駆動することを示す。
【０４１７】
また、「next」ポート１１１１と「prev」ポート１１１４の間のリンク１１２４は、続いて「B2」オブジェクト１１０３が「B11」オブジェクト１１０４を駆動することを示す。さらに、「next」ポート１１１５と「prev」ポート１１１８の間のリンク１１２５は、最後に「B11」オブジェクト１１０４が「B22」オブジェクト１１０５を駆動することを示す。「B22」オブジェクト１１０５は他のオブジェクトを駆動しないので、「next」ポート１１１９はどこにもリンクされていない。
【０４１８】
さらに、モデル図１０５ｆでは、部品間の通信（換言すればデータの流れ）を示す複数のリンクも定義されている。すなわち、モデル図１０５ｆには、「out」ポート１１０９と「in」ポート１１１２の間のリンク１１２６が定義されている。同様に、「out」ポート１１１３と「in」ポート１１１６の間のリンク１１２７、および「out」ポート１１１７と「in」ポート１１２０の間のリンク１１２８も定義されている。
【０４１９】
これらのリンク１１２６〜１１２８は、上記（ｄ７）と（ｄ８）を満たす。すなわち、リンク１１２６〜リンク１１２８はいずれも、「RequesterPort」クラス２１２と「ProviderPort」クラス２１３のオブジェクト間のリンクであり、同じ「インタフェース1」クラス１００３に依存するポート間のリンクである。
【０４２０】
なお、駆動順序を示す上記のリンク１１２２〜１１２５は、第２のメタモデル１０１ｂと表記ルール１０２にしたがって、下記（ｍ１）〜（ｍ３）に説明する制約条件を満たすように作成されている。
【０４２１】
（ｍ１）表記ルール１０２は、最初にタスクが部品のオブジェクトを駆動するという意味を表すための、「『Task』クラス２０６のオブジェクトからリンク可能なのは、『PrevPort』クラス９０３のオブジェクトのみである」というルールを含む。リンク１１２２はこのルールに適合する。
【０４２２】
また、このルールは、第２のメタモデル１０１ｂでは、「Task」クラス２０６に含まれる「RunnableConnector」クラス２０７から「PrevPort」クラス９０３のスーパクラスである「RunnableEntityPort」クラス９０２への参照（つまり関連９０７）に対応する。つまり、モデル作成部４１０は、「Task」クラス２０６のオブジェクトから「PrevPort」クラス９０３のオブジェクトへのリンクを、「RunnableConnector」クラス２０７のインスタンスとして解釈し、その解釈にしたがってモデル１０６を編集する。
【０４２３】
また、モデル作成ナビゲーション部４０３は、「NextPort」クラス９０４や「RequesterPort」クラス２１２や「ProviderPort」クラス２１３のオブジェクトに「T1」オブジェクト１１０１を接続しようとする入力を、上記のルールに基づいて拒絶する。こうしてモデル作成ナビゲーション部４０３は、表記ルール１０２に適合するようにモデル図１０５ｆを編集する。
【０４２４】
（ｍ２）表記ルール１０２は、「『PrevPort』クラス９０３のインスタンスは、『NextPort』クラス９０４または『Task』クラス２０６のインスタンスとしかリンクすることができない」というルールを含む。表記ルール１０２はさらに、「『NextPort』クラス９０４のインスタンスは、『PrevPort』クラス９０３のインスタンスとしかリンクすることができない」というルールを含む。
【０４２５】
モデル作成ナビゲーション部４０３がこの２つのルールも制約条件として用いながらモデル図１０５ｆの編集を行うので、リンク１１２２〜１１２５は、この２つのルールに適合している。
【０４２６】
（ｍ３）表記ルール１０２は、第１のオブジェクト内の「NextPort」クラス９０４のインスタンスと第２のオブジェクト内の「PrevPort」クラス９０３のインスタンスの間にリンクがある場合の、当該リンクの意味の解釈も与える。すなわち、表記ルール１０２は、「当該リンクは、『RunnableConnector』クラス２０７のインスタンスに相当し、第１のオブジェクトが第２のオブジェクトを駆動することを示す」という解釈を規定する。
【０４２７】
モデル作成部４１０は、この解釈にしたがって駆動順序を示すＸＭＬコードを生成することにより、モデル１０６を編集する。
したがって、例えばリンク１１２３は、「RunnableConnector」クラス２０７のインスタンスとしてモデル作成部４１０に解釈される。また、リンク１１２３の一端である「next」ポート１１０７は、リンク１１２３にとっては、第２のメタモデル１０１ｂの関連９０８に示す「nextPort」というロール名で参照されるポートである。同様に、リンク１１２３の他端である「prev」ポート１１１０は、リンク１１２３にとっては、関連９０７に示す「prevPort」というロール名で参照されるポートである。
【０４２８】
モデル作成部４１０は上記の解釈にしたがうことにより、「『B1』オブジェクト１１０２、『B2』オブジェクト１１０３、『B11』オブジェクト１１０４、『B22』オブジェクト１１０５という順序で駆動される」という意味をモデル１０６上に表現する。
【０４２９】
以上説明したように、第２のメタモデル１０１ｂに対応する表記ルール１０２の内容は、第１のメタモデル１０１ａに対応する表記ルール１０２とは一部異同がある。
具体的には、第２実施形態では、第２のメタモデル１０１ｂを表すクラス図には、メタ部品クラスに含まれるクラスとして、メタ呼び出しポートクラスが集約関係を使って定義されている。例えば、図１３では「RunnableEntityPort」クラス９０２のサブクラスである「PrevPort」クラス９０３と「NextPort」クラス９０４が、メタ呼び出しポートクラスとして、集約９０９と９１０を使って定義されている。
【０４３０】
よって、モデル図１０５ｅのようなクラス図の生成にあたり、部品用メニュー提供部４０５は、メタ呼び出しポートクラスのオブジェクトである呼び出しポートオブジェクトを１つ以上備えるように部品クラスを定義する。実施形態によっては、メタ呼び出しポートクラス（例えば「PrevPort」クラス９０３と「NextPort」クラス９０４）のサブクラスのオブジェクトを、呼び出しポートオブジェクトとして部品クラスが備えるように、部品用メニュー提供部４０５が定義してもよい。
【０４３１】
その結果、図１４のようなクラス図で定義された１つ以上の部品クラスの合計複数個のオブジェクトを定義するオブジェクト図（例えばモデル図１０５ｆ）において、各オブジェクト間の呼び出しを表記することができるようになる。すなわち、オブジェクト図内の各オブジェクトがそれぞれ備える呼び出しポートオブジェクト間の関係（リンク１１２３〜１１２５など）を用いることで、各オブジェクト間の呼び出しを表記することができる。
【０４３２】
あわせて、モデル作成部４１０は、図１５のようなオブジェクト図に表記された各オブジェクト間の呼び出しに基づいて、どのオブジェクトがどのオブジェクトを呼び出すかを所定の形式言語で表すコードを生成する。そして、モデル作成部４１０は、意味モデルとしてのモデル１０６に、生成した当該コードを含める。
【０４３３】
このように、順序定義の点で第１実施形態と第２実施形態には差があり、その差に応じて、表記ルール１０２の内容にも異動がある。しかし、メタモデル１０１ごとに予め決められた表記ルール１０２にしたがって制約をかけながら、ＤＳＭ支援装置１０４がモデル図１０５とモデル１０６を編集するという点には、第１実施形態と第２実施形態の間で何ら変わりはない。
【０４３４】
続いて、図１６〜１７を参照して第３実施形態について説明する。
図１６は、第３のメタモデルを表すＵＭＬのクラス図である。図１６に示す第３のメタモデル１０１ｃは、例えばロボット制御のドメインに好適である。
【０４３５】
第３のメタモデル１０１ｃは、ソフトウェアのモデルを表すＵＭＬのオブジェクト図において矩形で表される対象をメタモデル化したクラスである「ブロック」クラス１２０１の定義を含む。矩形で表される対象には名前を付けることができることを表すため、「ブロック」クラス１２０１は、「名前」という名前の属性を持つ。
【０４３６】
また、第３のメタモデル１０１ｃは、タスクをメタモデル化した「タスク」クラス１２０２と、メタ部品クラスである「機能」クラス１２０３と、メタインタフェースクラスである「データ」クラス１２０４の定義も含む。換言すれば、「機能」クラス１２０３は、ソフトウェアの部品の様々な機能を抽象化してメタモデル化したクラスである。また、「データ」クラス１２０４は、部品間で入出力されるデータの形式によって部品間の通信インタフェースが規定されるという観点から、種々のデータをインタフェースとして捉えてメタモデル化したクラスである。
【０４３７】
なお、「タスク」クラス１２０２は、タスクを実行する周期と、タスクが最初に起動するタイミングを示すための２つの属性を有し、それぞれの名前は「発火周期」と「初期カウンタ」である。また、「データ」クラス１２０４は、「データ」クラス１２０４が表すインタフェースの型を示すための、「データ型」という名前の属性を有する。
【０４３８】
第３のメタモデル１０１ｃはさらに、ソフトウェアのモデルを表すＵＭＬのオブジェクト図において各種の線で表される対象をメタモデル化したクラスである「コネクタ」クラス１２０５の定義を含む。
【０４３９】
より具体的には、第３のメタモデル１０１ｃは、オブジェクト図において誘導可能性を示す矢印付きのリンクにより実行順序とデータの入出力を表現することをメタモデル化している。そのため、第３のメタモデル１０１ｃは、「コネクタ」クラス１２０５のサブクラスとして定義される「実行順番」クラス１２０６と「データアクセス」クラス１２０７を含む。そして、「データアクセス」クラス１２０７は、「Read」（読み出し）か「Write」（書き込み）か、というデータアクセスのタイプを表すための「アクセスタイプ」という名前の属性を有する。
【０４４０】
また、第３のメタモデル１０１ｃは、ＵＭＬのオブジェクト図にコメントが付けられることを表す「コメント」クラス１２０８の定義も含む。「コメント」クラス１２０８は「説明文」という名前の属性を有する。すなわち、「説明文」属性の値である文字列が、コメントとしてＵＭＬのオブジェクト図に付けられる。
【０４４１】
さらに、第３のメタモデル１０１ｃは、「機能」クラス１２０３から直接派生したサブクラスとして、「アクチュエータ」クラス１２０９、「演算」クラス１２１０、「センサ」クラス１２１１各々の定義も含む。そして、第３のメタモデル１０１ｃは、「機能」クラス１２０３から間接的に派生したサブクラスの定義も含む。具体的には、第３のメタモデル１０１ｃは、「ＬＣＤ」（Liquid Crystal Display）クラス１２１２、「モータ」クラス１２１３、「グラフ特性」クラス１２１４、「光センサ」クラス１２１５、「タッチセンサ」クラス１２１６各々の定義も含む。
【０４４２】
第３のメタモデル１０１ｃによれば、上記のクラス間に以下のような各種の関係が定義されている。
すなわち、汎化１２５１、１２５２および１２５３は、「タスク」クラス１２０２、「機能」クラス１２０３および「データ」クラス１２０４がそれぞれ「ブロック」クラス１２０１のサブクラスであることを示す。また、汎化１２５４と１２５５は、「実行順番」クラス１２０６と「データアクセス」クラス１２０７がそれぞれ「コネクタ」クラス１２０５のサブクラスであることを示す。
【０４４３】
さらに、汎化１２５６、１２５７および１２５８は、「アクチュエータ」クラス１２０９、「演算」クラス１２１０および「センサ」クラス１２１１がそれぞれ「機能」クラス１２０３のサブクラスであることを示す。
【０４４４】
また、汎化１２５９と１２６０は、「ＬＣＤ」クラス１２１２と「モータ」クラス１２１３がそれぞれ「アクチュエータ」クラス１２０９のサブクラスであることを示す。同様に、汎化１２６１は「グラフ特性」クラス１２１４が「演算」クラス１２１０のサブクラスであることを示す。また、汎化１２６２と１２６３は「光センサ」クラス１２１５と「タッチセンサ」クラス１２１６がそれぞれ「センサ」クラス１２１１のサブクラスであることを示す。
【０４４５】
そして、いずれも多重度が「1」の関連１２６４と１２６５は、「実行順番」クラス１２０６が「ブロック」クラス１２０１をそれぞれ「prev」と「next」というロール名で参照可能なことを表す。関連１２６４と１２６５は、ソフトウェアのモデルを表す図において、「実行順番」クラス１２０６のインスタンスを表現する線の両端が「ブロック」クラス１２０１（またはそのサブクラス）のインスタンスであることを表す。
【０４４６】
多重度が「0..*」の関連１２６６は、「ブロック」クラス１２０１が「comment」というロール名で「コメント」クラス１２０８を参照することを表す。関連１２６６は、ソフトウェアのモデルを表す図において、「ブロック」クラス１２０１（またはそのサブクラス）のインスタンスを表す矩形には、任意の個数のコメントを付加しうることを表す。
【０４４７】
同様に、多重度が「0..*」の関連１２６７は、「コネクタ」クラス１２０５が「comment」というロール名で「コメント」クラス１２０８を参照することを示す。関連１２６７は、ソフトウェアのモデルを表す図において、「コネクタ」クラス１２０５（またはそのサブクラス）のインスタンスを表す線には、任意の個数のコメントを付加しうることを表す。
【０４４８】
いずれも多重度が「1」の関連１２６８と１２６９は、「データアクセス」クラス１２０７が、「data」と「function」というロール名でそれぞれ「データ」クラス１２０４と「機能」クラス１２０３を参照可能なことを表す。関連１２６８と１２６９は、ソフトウェアのモデルを表す図で、「データアクセス」クラス１２０７のインスタンスを表す線が、「機能」クラス１２０３（またはそのサブクラス）と「データ」クラス１２０４のインスタンス同士を結ぶことに対応する。つまり、関連１２６８と１２６９は、（ソフトウェアの部品のモデルとしての）ある機能から、（インタフェースのモデルとしての）あるデータへのアクセスが「データアクセス」クラス１２０７によりメタモデル化されていることを示す。
【０４４９】
ところで、第３のメタモデル１０１ｃでは、「機能」クラス１２０３から間接的に派生している５つのクラスが、コンクリートクラスとして定義されている。すなわち、第３のメタモデル１０１ｃは、ユーザがクラスを定義する必要なしにオブジェクト図の形でソフトウェアの部品をモデル化することができるように、「光センサ」クラス１２１５等の具体的なクラスの定義を含んでいる。この点は、第１・第２のメタモデル１０１ａ・１０１ｂと第３のメタモデル１０１ｃとの違いである。
【０４５０】
すなわち、第１・第２のメタモデル１０１ａ・１０１ｂでは、ユーザがクラス図の形でソフトウェアをモデル化すること（すなわち、メタ部品クラスから派生するユーザ定義のサブクラスにより部品がモデル化されること）が前提となっている。よって、第１・第２のメタモデル１０１ａ・１０１ｂによれば、ある程度ドメインが絞られた範囲の中でユーザにクラス設計の自由度を与えることができる。
【０４５１】
それに対し、第３のメタモデル１０１ｃにおけるメタ部品クラスは、「光センサ」クラス１２１５等のドメイン固有のコンクリートクラスを含み、ユーザはクラスを定義しなくても迅速にソフトウェアをモデル化することができる。
【０４５２】
換言すれば、第１・第２のメタモデル１０１ａ・１０１ｂを使ったモデル化は、ユーザがクラス定義をカスタマイズしながらＤＳＭ設計を行うこと可能とする。他方で、第３のメタモデル１０１ｃを使ったモデル化は、ドメインに合わせて予め定義されたオーダメイドのクラスを使ったＤＳＭ設計を可能とする。なお、第３実施形態においても、第３のメタモデル１０１ｃを使ってユーザが「機能」クラス１２０３のサブクラスとして部品クラスを定義してもよい。
【０４５３】
どのようなタイプのメタモデルが好ましいかは、設計対象のソフトウェアの適用分野などに応じて様々であるが、メタモデルのタイプに応じて、第１〜第３実施形態あるいはその変形例の中から、適した実施形態を選んで適用することが可能である。
【０４５４】
さて次に、上記の第３のメタモデル１０１ｃにしたがったソフトウェアのモデル化の例について説明する。
図１７は、第３のメタモデルにしたがうモデルを表すＵＭＬのオブジェクト図である。図１７のモデル図１０５ｇは、明るさに基づいて路面上に引かれた白線を判別し、白線の右端を探してトレースしながら白線に沿って走る、後輪駆動・前輪ステアリングの自走式の車ロボットの制御用ソフトウェアのモデルを表すオブジェクト図の例である。
【０４５５】
モデル図１０５ｇは、「タスク」クラス１２０２の「ステアリングタスク」オブジェクト１３０１を含む。「ステアリングタスク」オブジェクト１３０１は前輪の制御用タスクをモデル化したものである。
【０４５６】
モデル図１０５ｇはさらに、「光センサ」クラス１２１５の「LightSensor1」オブジェクト１３０２と、「グラフ特性」クラス１２１４の「ハンドル切り量」オブジェクト１３０３と「モータ」クラス１２１３の「ハンドル駆動」オブジェクト１３０４を含む。また、モデル図１０５ｇは、「データ」クラス１２０４の「路面の明るさ」オブジェクト１３０５と「ハンドルモータ駆動量」オブジェクト１３０６を含む。
【０４５７】
また、モデル図１０５ｇは、「タスク」クラス１２０２の「タイヤ駆動タスク」オブジェクト１３０７も含む。「タイヤ駆動タスク」オブジェクト１３０７は後輪の制御用タスクをモデル化したものである。
【０４５８】
そして、モデル図１０５ｇは、「グラフ特性」クラス１２１４の「スピード制御量」オブジェクト１３０８と、「モータ」クラス１２１３の「後輪タイヤ駆動」オブジェクト１３０９と、「データ」クラス１２０４の「タイヤ駆動量」オブジェクト１３１０を含む。
【０４５９】
モデル図１０５ｇには、「実行順番」クラス１２０６のインスタンスとして矢印で示されるリンクが含まれる。矢印の根元側と先端側はそれぞれ、第３のメタモデル１０１ｃにおける関連１２６４と１２６５に対応し、矢印の根元側のオブジェクトから先端側のオブジェクトが呼び出され、駆動される。
【０４６０】
具体的には、「ステアリングタスク」オブジェクト１３０１が「LightSensor1」オブジェクト１３０２を駆動することをリンク１３２１が示す。また、「LightSensor1」オブジェクト１３０２が「ハンドル切り量」オブジェクト１３０３を駆動することをリンク１３２２が示す。そして、「ハンドル切り量」オブジェクト１３０３が「ハンドル駆動」オブジェクト１３０４を駆動することをリンク１３２３が示す。
【０４６１】
同様に、「タイヤ駆動タスク」オブジェクト１３０７が「スピード制御量」オブジェクト１３０８を駆動することをリンク１３２４が示す。そして、「スピード制御量」オブジェクト１３０８が「後輪タイヤ駆動」オブジェクト１３０９を駆動することをリンク１３２５が示す。
【０４６２】
また、モデル図１０５ｇには、「データアクセス」クラス１２０７のインスタンスとして矢印で示されるリンクも含まれる。「データ」クラス１２０４のインスタンスから「機能」クラス１２０３のサブクラスのインスタンスへの矢印で示されるリンクは、機能がデータを読み込む「Read」アクセスを示す。逆方向の矢印で示されるリンクは、機能がデータを書き出す「Write」アクセスを示す。
【０４６３】
具体的には、「LightSensor1」オブジェクト１３０２から「路面の明るさ」オブジェクト１３０５への書き出しをリンク１３３１が表し、「路面の明るさ」オブジェクト１３０５の「ハンドル切り量」オブジェクト１３０３への読み込みをリンク１３３２が表す。また、「ハンドル切り量」オブジェクト１３０３から「ハンドルモータ駆動量」オブジェクト１３０６への書き出しをリンク１３３３が表す。そして、「ハンドルモータ駆動量」オブジェクト１３０６の「ハンドル駆動」オブジェクト１３０４への読み込みをリンク１３３４が表す。
【０４６４】
「ハンドルモータ駆動量」オブジェクト１３０６はさらに「スピード制御量」オブジェクト１３０８にも読み込まれ、リンク１３３５はその読み込みを表す、また、「スピード制御量」オブジェクト１３０８から「タイヤ駆動量」オブジェクト１３１０への書き出しをリンク１３３６が表し、「タイヤ駆動量」オブジェクト１３１０の「後輪タイヤ駆動」オブジェクト１３０９への読み込みをリンク１３３７が表す。
【０４６５】
また、モデル図１０５ｇには、「コメント」クラス１２０８のインスタンスとしてのコメント１３４１〜１３４６も含まれる。例えば、コメント１３４１は「ハンドル切り量」オブジェクト１３０３に対して付加されているので、「ハンドル切り量」オブジェクト１３０３と点線１３５１で結ばれている。
【０４６６】
同様に、コメント１３４２〜１３４６はそれぞれ点線１３５２〜１３５６によって、「スピード制御量」オブジェクト１３０８、リンク１３２４、リンク１３３６、「タイヤ駆動量」オブジェクト１３１０、リンク１３３７と結ばれている。これらの点線１３５１〜１３５６は、第３のメタモデル１０１ｃにおける関連１２６６または関連１２６７に相当する。
【０４６７】
以上のような図形を含むモデル図１０５ｇは、より具体的には以下のような制御のモデルである。
すなわち、前輪の制御のための「ステアリングタスク」オブジェクト１３０１が「LightSensor1」オブジェクト１３０２を呼び出し、「LightSensor1」オブジェクト１３０２は路面の明るさを感知し、感知した路面の明るさを「路面の明るさ」オブジェクト１３０５に書き出す。また、「LightSensor1」オブジェクト１３０２は「ハンドル切り量」オブジェクト１３０３を駆動する。
【０４６８】
すると、「ハンドル切り量」オブジェクト１３０３は、「路面の明るさ」オブジェクト１３０５を読み込み、読み込んだデータからハンドルモータ駆動量を導き出す。具体的には、「ハンドル切り量」オブジェクト１３０３は、コメント１３４１に記してあるように、明るくなったら右へ、暗くなったら左へ、ハンドルを切るよう決定し、決定した結果を「ハンドルモータ駆動量」オブジェクト１３０６に書き出す。また、「ハンドル切り量」オブジェクト１３０３は、「ハンドル駆動」オブジェクト１３０４を駆動する。
【０４６９】
すると、「ハンドル駆動」オブジェクト１３０４は「ハンドルモータ駆動量」オブジェクト１３０６を読み込み、「ハンドル切り量」オブジェクト１３０３が決定した結果にしたがって、ハンドルのモータを駆動させる制御を行う。その結果、コメント１３４１に記すとおり、ロボットは路面上の白線の端に沿って進むことができる。
【０４７０】
また、前輪の制御と並行して、後輪の制御も行われる。具体的にはまず「タイヤ駆動タスク」オブジェクト１３０７が「スピード制御量」オブジェクト１３０８を呼び出す。なお、この呼び出しを示すリンク１３２４には、リンク１３２４が実行順序を表すコネクタであることを示すコメント１３４３が付加されている。
【０４７１】
「タイヤ駆動タスク」オブジェクト１３０７から呼び出された「スピード制御量」オブジェクト１３０８は、「ハンドルモータ駆動量」オブジェクト１３０６を読み込む。コメント１３４２に記すように、「スピード制御量」オブジェクト１３０８は、「ハンドルモータ駆動量」オブジェクト１３０６が示す量に比例してスピードを制御する（具体的には、例えば、ハンドルを増し切りするにしたがってスピードを落とすなどの制御を行う）。
【０４７２】
「スピード制御量」オブジェクト１３０８は、「ハンドルモータ駆動量」オブジェクト１３０６に基づいて、スピードの制御のために具体的にはタイヤの駆動量を決定し、決定した結果を「タイヤ駆動量」オブジェクト１３１０に書き込む。なお、この書き込みを表すリンク１３３６にはコメント１３４４が付けられている。そして、リンク１３３６は機能のデータに対する「Write」アクセスを表すコネクタである、ということがコメント１３４４として記されている。
【０４７３】
また、「スピード制御量」オブジェクト１３０８は、「後輪タイヤ駆動」オブジェクト１３０９を呼び出し、駆動する。駆動された「後輪タイヤ駆動」オブジェクト１３０９は、「タイヤ駆動量」オブジェクト１３１０を読み込む。なお、この読み込みを表すリンク１３３７にはコメント１３４６が付けられている。そして、リンク１３３７は機能のデータに対する「Read」アクセスを表すコネクタである、ということがコメント１３４６として記されている。
【０４７４】
「タイヤ駆動量」オブジェクト１３１０を読み込んだ「後輪タイヤ駆動」オブジェクト１３０９は、後輪のタイヤを駆動する制御を行う。すなわち、コメント１３４５に記すように、部品間のインタフェースとしての「タイヤ駆動量」オブジェクト１３１０を介して、「スピード制御量」オブジェクト１３０８から、決定されたタイヤ駆動量が、「後輪タイヤ駆動」オブジェクト１３０９に伝えられる。
【０４７５】
以上のようなロボットの制御ソフトウェアのモデルの編集に際して、第３実施形態のＤＳＭ支援装置１０４は、第１実施形態とは多少異なる振る舞いをする。以下、第１実施形態と異なる点について説明する。
【０４７６】
第３実施形態におけるＤＳＭ支援装置１０４は、図４に示す第１実施形態のＤＳＭ支援装置１０４と類似しているが、モデル作成ナビゲーション部４０３内の各コンポーネントの動作が第１実施形態とは異なる。
【０４７７】
例えば、ソフトウェアのモデルを編集する処理において、部品用メニュー提供部４０５は、ＵＭＬのオブジェクト図上で、第３のメタモデル１０１ｃ内で「機能」クラス１２０３のサブクラスとして定義されたコンクリートクラスをインスタンス化する。
【０４７８】
例えば、部品用メニュー提供部４０５は、「ＬＣＤ」クラス１２１２、「モータ」クラス１２１３、「グラフ特性」クラス１２１４、「光センサ」クラス１２１５および「タッチセンサ」クラス１２１６のみを、作成可能な部品の選択肢として提示してもよい。選択肢の提示は、ＵＭＬツール１０３を介して行われ、部品用メニュー提供部４０５は選択肢の中から１つを選択する入力を、入力装置４０１からＵＭＬツール１０３を介して受け取ってもよい。
【０４７９】
そして、部品用メニュー提供部４０５は、選択されたクラスをインスタンス化して新規オブジェクトを作成し、ＵＭＬのオブジェクト図に追加するようＵＭＬツール１０３に命令する。また、部品用メニュー提供部４０５は、作成したオブジェクトのクラスを、入力装置４０１からＵＭＬツール１０３を介して指定されるオブジェクト名とともに、モデル作成部４１０に通知する。
【０４８０】
例えば、「LightSensor1」オブジェクト１３０２の作成に際しては、新規作成されたオブジェクトは「光センサ」クラス１２１５のインスタンスであり「LightSensor1」という名前であるということが、モデル作成部４１０に通知される。
【０４８１】
モデル作成部４１０は、第３のメタモデル１０１ｃから、「光センサ」クラス１２１５が「機能」クラス１２０３から間接的に派生していることを認識する。つまり、モデル作成部４１０は、作成された「LightSensor1」オブジェクト１３０２がインタフェースとしてのデータなどではなく、ソフトウェアの部品の一種であることを認識する。モデル作成部４１０はその認識に基づいて、「LightSensor1」オブジェクト１３０２を表すＸＭＬコードを生成することでモデル１０６を編集する。
【０４８２】
このように、第３実施形態では、第３のメタモデル１０１ｃ中で定義されているメタ部品クラスでもあるコンクリートクラスが、そのままソフトウェアの部品を表す部品クラスとして使用可能である。よって、第１実施形態のように部品用メニュー提供部４０５が部品クラスからメタ部品クラスへの汎化を追加するといった処理は、第３実施形態では省略される。
【０４８３】
インタフェースとしての「データ」クラス１２０４のオブジェクトの作成についても同様である。つまり、第３実施形態では、第３のメタモデル１０１ｃ内の「データ」クラス１２０４がコンクリートクラスなので、インタフェース用メニュー提供部４０７は、メタインタフェースクラスへの汎化を追加する処理を行わなくてよい。
【０４８４】
インタフェース用メニュー提供部４０７は、ＵＭＬツール１０３を介して単に「データ」クラス１２０４をインスタンス化することで、例えば「路面の明るさ」オブジェクト１３０５をモデル図１０５ｇに追加する。そして、インタフェース用メニュー提供部４０７は、追加した「路面の明るさ」オブジェクト１３０５のオブジェクト名と所属クラスをモデル作成部４１０に通知する。
【０４８５】
モデル作成部４１０は、第３のメタモデル１０１ｃから「データ」クラス１２０４がメタインタフェースクラス兼インタフェースクラスであることを認識するので、「路面の明るさ」オブジェクト１３０５がインタフェースをモデル化したものであると認識する。モデル作成部４１０はその認識に基づいて、「路面の明るさ」オブジェクト１３０５を表すＸＭＬコードを生成することでモデル１０６を編集する。
【０４８６】
また、第３のメタモデル１０１ｃはポートをメタモデル化したクラスを含まないので、第３実施形態ではポート用メニュー提供部４０６は省略されてよい。その代わり、モデル作成ナビゲーション部４０３は、インタフェースとしての「データ」クラス１２０４のオブジェクトを介した部品間のデータ入出力に関して、以下のように制約をかける。
【０４８７】
すなわち、モデル作成ナビゲーション部４０３は、ソフトウェアのモデルを表すＵＭＬのオブジェクト図（例えば図１７のモデル図１０５ｇ）上において、「データ」クラス１２０４のオブジェクトと接続されるリンクに制約をかける。具体的には、第３のメタモデル１０１ｃの関連１２６８と１２６９が示すように、第３実施形態の表記ルール１０２によれば、「データ」クラス１２０４のオブジェクトとリンク可能なのは「機能」クラス１２０３から派生したクラスのオブジェクトのみである。
【０４８８】
よって、モデル作成ナビゲーション部４０３は、第３のメタモデル１０１ｃと表記ルール１０２にしたがって、制約を満たすリンクを作成しようとする入力のみを許す。制約を満たさないリンクを作成しようとする入力を入力装置４０１からＵＭＬツール１０３を介して受け取った場合、モデル作成ナビゲーション部４０３は、例えばＵＭＬツール１０３を介して出力装置４０２に警告を表示させてもよい。
【０４８９】
例えば、入力装置４０１からＵＭＬツール１０３を介して、「路面の明るさ」オブジェクト１３０５と「ハンドルモータ駆動量」オブジェクト１３０６をリンクで接続しようとする入力を受け取った場合、モデル作成ナビゲーション部４０３は入力を拒絶する。
【０４９０】
また、第３実施形態におけるタスク用メニュー提供部４０９は、例えば、部品の駆動順序を指定するようユーザに促すダイアログを、ＵＭＬツール１０３を介して出力装置４０２に表示させてもよい。そして、タスク用メニュー提供部４０９は、ダイアログに対する入力にしたがってリンク１３２１等を追加し、追加したリンクの情報をモデル作成部４１０に通知し、モデル作成部４１０は通知された情報にしたがってモデル１０６を編集してもよい。
【０４９１】
例えば、図１７に示す各オブジェクトが作成済みの状態で、タスク用メニュー提供部４０９は、「タイヤ駆動タスク」オブジェクト１３０７、「スピード制御量」オブジェクト１３０８、「後輪タイヤ駆動」オブジェクト１３０９を順に指定する入力を受け取る。すると、タスク用メニュー提供部４０９は、指定された順序の先頭が「タスク」クラス１２０２のオブジェクトであるか否か、また、２番目以降のオブジェクトは「機能」クラス１２０３から派生したクラスのオブジェクトであるか否かをチェックする。
【０４９２】
この例ではチェックされる条件（すなわちモデル図１０５ｃと表記ルール１０２により示される制約条件）が満たされている。よって、タスク用メニュー提供部４０９は、入力にしたがって、モデル図１０５ｇ上にリンク１３２４と１３２５を追加し、追加したリンク１３２４と１３２５の情報（例えばリンクの始点と終点の両オブジェクトを識別する情報）をモデル作成部４１０に通知する。
【０４９３】
そして、モデル作成部４１０は、通知された情報にしたがって実行順序を示すＸＭＬコードを生成することで、モデル１０６を編集する。
なお、本発明は上記の実施形態に限られるものではなく、様々に変形可能である。以下にその例をいくつか述べる。
【０４９４】
メタモデル１０１は、上記の例に限らない。例えば、ソフトウェアの部品間の通信のインタフェースをメタモデル化することは、必ずしも必要という訳ではない。メタインタフェースクラスの定義を含まないメタモデルであっても、ユーザ定義のクラスからメタ部品クラスへの汎化により、ユーザ定義のクラスを「部品を意味するクラス」として自動的に解釈してソースコードを自動生成することを可能とする。
【０４９５】
また、上記の例ではメタモデル１０１内の個々のクラスの詳細な属性と操作については省略したが、ドメインに応じて適宜メタモデル１０１内のクラスで属性と操作が定義されていてよい。
【０４９６】
また、例えば図３では、第１のメタモデル１０１ａで定義された「CompositionType」クラス２０２と「SenderReceiverInterface」クラス２０９から「部品A」クラス３０１と「インタフェースA」クラス３０２がそれぞれ直接派生している。しかし、メタモデル１０１中で定義されたメタ部品クラスから間接的に派生したクラスが、部品クラスとしてモデル図１０５で定義されてもよい。同様に、メタモデル１０１中で定義されたメタインタフェースクラスから間接的に派生したクラスが、インタフェースクラスとしてモデル図１０５で定義されてもよい。
【０４９７】
同様のことはポートについても言える。すなわち、図３の「受信ポート」ポート３０３と「送信ポート」ポート３０４は、第１のメタモデル１０１ａで定義された「RequesterPort」クラス２１２と「ProviderPort」クラス２１３のオブジェクトである。しかし、「RequesterPort」クラス２１２や「ProviderPort」クラス２１３から派生したクラスのオブジェクトを、部品クラスが有するように、ソフトウェアがモデル化されてもよい。
【０４９８】
つまり、モデル図１０５中のクラスないしオブジェクトが何をモデル化したものであるかということは、直接的な派生か間接的な派生かを問わず、メタモデル１０１で定義されたクラスへの汎化に基づいて自動的に解釈可能である。よって、例えば部品クラスがメタ部品クラスから間接的に派生したものであっても、上記実施形態と同様に「ソースコード１０９の自動生成を可能とする」という効果が得られる。
【０４９９】
また、メタモデル１０１は、ポートに関するクラスを含まなくてもよい。例えば第３実施形態のように、部品クラス（例えば「モータ」クラス１２１３）とインタフェースクラス（具体的には「データ」クラス１２０４）との間の関係を用いて、部品間のインタフェースを介した通信を表記することもできる。
【０５００】
なお、上記の説明においては、理解を容易とするために、例えば図３において汎化３０５と３０６を図示している。しかし、汎化３０５と３０６は、データとしてＤＳＭ支援装置１０４が生成し認識してさえいればよく、実施形態によっては、出力装置４０２に図形として表示されなくてもよい。
【０５０１】
また、モデル１０６を記述する形式言語は、ＸＭＬでなくてもよい。ＸＭＬ以外の言語でモデル１０６を記述する場合は、図１のプロセスＰ１０２におけるコード生成は、ＸＳＬＴ技術以外の技術により行われる。
【０５０２】
また、上記の実施形態は、メタモデル１０１と表記ルール１０２による制約を満たすようにＤＳＭ支援装置１０４がＵＭＬ図の作成をナビゲートする、いわば事前チェック型の実施形態である。しかし、ユーザが自由に作成したＵＭＬ図を、メタモデル１０１と表記ルール１０２に基づいてＤＳＭ支援装置１０４が事後的にチェックし、メタモデル１０１と表記ルール１０２による制約を満たさない箇所をエラーとして警告するような実施形態も可能である。
【０５０３】
その場合、モデル作成部４１０は、例えばエラーが検出されなくなった段階のモデル図１０５を入力として受け取り、モデル図１０５からモデル１０６を作成してもよい。また、この事後チェック型の実施形態においては、モデル作成部４１０は、モデル図１０５からモデル１０６を作成するための中間データとして、例えば、モデル図１０５の図形的な特徴を表すＸＭＬデータを生成してもよい。
【０５０４】
そして、モデル作成部４１０は、中間データとメタモデル１０１と表記ルール１０２に基づいて、最終的なモデル１０６を作成してもよい。中間データは、例えば、「どの矩形とどの矩形がどの線により接続されているか」といった図形的な特徴を表すものでもよい。モデル作成部４１０はメタモデル１０１と表記ルール１０２に基づいて、線や矩形の意味を解釈し、最終的なモデル１０６を作成することができる。
【０５０５】
例えば、部品クラスに関しては、上記の事前チェック型の実施形態では、部品用メニュー提供部４０５が、部品クラスを新規作成するための指示を受け取り、当該指示を契機として、メタ部品クラスのサブクラスを部品クラスとしてクラス図内に作成する。それに対し、事後チェック型の実施形態では、部品用メニュー提供部４０５は、クラス図内に作成された任意のクラスからメタ部品クラスへの汎化を追加するための指示を受け取り、当該指示を契機として、上記任意のクラスを部品クラスとして定義しなおす。
【０５０６】
インタフェースクラスに関しても同様のことが言える。つまり、事前チェック型の実施形態ではインタフェース用メニュー提供部４０７が、インタフェースクラスを新規作成するための指示を受け取り、当該指示を契機として、メタインタフェースクラスのサブクラスをインタフェースクラスとしてクラス図内に作成する。それに対し、事後チェック型の実施形態では、インタフェース用メニュー提供部４０７は、クラス図内に作成された任意のクラスからメタインタフェースクラスへの汎化を追加するための指示を受け取る。そして、インタフェース用メニュー提供部４０７は当該指示を契機として、上記任意のクラスクラスをインタフェースクラスとして定義しなおす。
【０５０７】
最後に、上記の種々の実施形態に関して、さらに下記の付記を開示する。
（付記１）
コンピュータに、
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義を含み、ＵＭＬで表記された第１のクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを取得するメタモデル取得ステップと、
前記ソフトウェアに含まれる部品を表す部品クラスを、前記メタ部品クラスのサブクラスとして定義することにより、前記ソフトウェアを前記メタモデルにしたがってモデル化したモデルを、前記部品クラスを含み前記ＵＭＬで表記される第２のクラス図として生成するクラス図生成ステップと、
前記部品クラスから前記メタ部品クラスへの汎化と前記メタモデルに基づいて、前記第２のクラス図における前記部品クラスが前記部品をモデル化したクラスであるという前記第２のクラス図の意味を所定の形式言語により表す意味モデルを生成する意味モデル生成ステップと、
を実行させることを特徴とする意味モデル生成プログラム。
（付記２）
前記第１のクラス図は、前記部品間の通信のインタフェースをメタモデル化したメタインタフェースクラスの定義をさらに含み、
前記クラス図生成ステップは、
前記部品間の前記通信の前記インタフェースをモデル化したインタフェースクラスを、前記メタインタフェースクラスのサブクラスとして、前記第２のクラス図において定義するインタフェース定義ステップと、
前記インタフェースクラスとの間の関係を用いて、前記部品間の前記通信を前記第２のクラス図において表記するインタフェース表記ステップと、
を含み、
前記意味モデル生成ステップは、前記第２のクラス図における前記インタフェースクラスとの間の前記関係を、前記インタフェースクラスから前記メタインタフェースクラスへの汎化に基づいて、前記部品間の前記インタフェースを介した前記通信を意味する前記所定の形式言語の第１のコードで表現し、前記意味モデルに前記第１のコードを含めるインタフェース解釈ステップを含む、
ことを特徴とする付記１に記載の意味モデル生成プログラム。
（付記３）
前記第１のクラス図には、前記メタ部品クラスに含まれるクラスとして、メタ通信ポートクラスが定義されており、
前記クラス図生成ステップは、前記第２のクラス図において、前記部品クラスを、前記メタ通信ポートクラスまたは前記メタ通信ポートクラスのサブクラスとして定義される通信ポートクラスのいずれかのオブジェクトである通信ポートオブジェクトを含むように定義する通信ポート定義ステップをさらに含み、
前記インタフェース表記ステップは、前記部品クラスに含まれる前記通信ポートオブジェクトから前記インタフェースクラスへの依存を用いて、前記部品間の前記インタフェースを介した前記通信を前記第２のクラス図において表記するステップである、
ことを特徴とする付記２に記載の意味モデル生成プログラム。
（付記４）
前記インタフェース表記ステップは、前記部品クラスと前記インタフェースクラスとの間の関係を用いて、前記部品間の前記インタフェースを介した前記通信を前記第２のクラス図において表記するステップである、
ことを特徴とする付記２に記載の意味モデル生成プログラム。
（付記５）
前記クラス図生成ステップは、
前記部品クラスを新規作成するための第１の指示を受け取り、前記第１の指示を契機として、前記メタ部品クラスのサブクラスを前記部品クラスとして前記第２のクラス図内に作成する部品定義ナビゲーションステップ、または
前記第２のクラス図内に作成された任意の第１のクラスから前記メタ部品クラスへの汎化を追加するための第２の指示を受け取り、前記第２の指示を契機として、前記第１のクラスを前記部品クラスとして定義しなおす部品事後定義ステップ
を含むことを特徴とする付記１〜４のいずれか１項に記載の意味モデル生成プログラム。
（付記６）
前記インタフェース定義ステップは、
前記インタフェースクラスを新規作成するための第３の指示を受け取り、前記第３の指示を契機として、前記メタインタフェースクラスのサブクラスを前記インタフェースクラスとして前記第２のクラス図内に作成するインタフェース定義ナビゲーションステップ、または
前記第２のクラス図内に作成された任意の第２のクラスから前記メタインタフェースクラスへの汎化を追加するための第４の指示を受け取り、前記第４の指示を契機として、前記第２のクラスを前記インタフェースクラスとして定義しなおすインタフェース事後定義ステップ
を含むことを特徴とする付記２〜４のいずれか１項に記載の意味モデル生成プログラム。
（付記７）
前記第１のクラス図には、
部品同士が入れ子になってもよいことを示すための第１の集約関係と、
入れ子になった内部部品を有する外部部品の内部での、前記外部部品と前記内部部品との間の通信を表すためのメタ内部通信クラスと、
前記メタ部品クラスに前記メタ内部通信クラスが含まれることを示す第２の集約関係と、
が定義されており、
前記第２のクラス図において、前記部品クラスが複数あり、複数の前記部品クラスのうち前記外部部品をモデル化した外部部品クラスの中に、複数の前記部品クラスのうち前記内部部品をモデル化した内部部品クラスが入れ子になって含まれるとき、
前記クラス図生成ステップは、前記外部部品クラスと前記内部部品クラスの間に、前記メタ内部通信クラスに対応する関係である内部通信関係を定義する内部通信定義ステップを含み、
前記意味モデル生成ステップは、前記外部部品クラスと前記内部部品クラスそれぞれからの前記メタ部品クラスへの汎化と前記メタ内部通信クラスの定義とに基づいて、前記内部通信関係を、前記外部部品クラスと前記内部部品クラスの間の前記通信を意味する前記所定の形式言語の第２のコードで表現し、前記意味モデルに前記第２のコードを含める内部通信解釈ステップを含む、
ことを特徴とする付記１〜６のいずれか１項に記載の意味モデル生成プログラム。
（付記８）
前記意味モデル生成プログラムは前記コンピュータにさらに、前記第２のクラス図で定義された前記部品クラスのオブジェクトを定義するオブジェクト図に含まれるオブジェクト間の呼び出しを定義するシーケンス図を生成するシーケンス図生成ステップを実行させ、
前記意味モデル生成ステップは、前記シーケンス図の内容に基づいて、前記呼び出しの順序を前記所定の形式言語で表す第３のコードを生成し、前記第３のコードを前記意味モデルに含める第１の順序定義ステップを含む、
ことを特徴とする付記１〜７のいずれか１項に記載の意味モデル生成プログラム。
（付記９）
前記第１のクラス図には、前記メタ部品クラスに含まれるクラスとして、メタ呼び出しポートクラスが集約関係を使って定義されており、
前記クラス図生成ステップは、前記メタ呼び出しポートクラスまたは前記メタ呼び出しポートクラスのサブクラスのいずれかのオブジェクトである呼び出しポートオブジェクトを１つ以上備えるように前記部品クラスを定義する呼び出しポート定義ステップを含み、
前記意味モデル生成プログラムは前記コンピュータにさらに、前記第２のクラス図で定義された１つ以上の前記部品クラスの合計複数個のオブジェクトを定義するオブジェクト図において、前記オブジェクト図内の各オブジェクトがそれぞれ備える前記呼び出しポートオブジェクト間の関係を用いて、前記各オブジェクト間の呼び出しを表記する呼び出し表記ステップを実行させ、
前記意味モデル生成ステップは、前記オブジェクト図に表記された前記各オブジェクト間の前記呼び出しに基づいて、どのオブジェクトがどのオブジェクトを呼び出すかを前記所定の形式言語で表す第４のコードを生成し、前記意味モデルに前記第４のコードを含める第２の順序定義ステップを含む、
ことを特徴とする付記１〜７のいずれか１項に記載の意味モデル生成プログラム。
（付記１０）
コンピュータに、
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義と、前記部品間の通信のインタフェースをメタモデル化したメタインタフェースクラスの定義とを含み、ＵＭＬで表記されたクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを取得するメタモデル取得ステップと、
前記メタ部品クラスまたは前記メタ部品クラスのサブクラスをインスタンス化した少なくとも２つの部品オブジェクトと、前記メタインタフェースクラスまたは前記メタインタフェースクラスのサブクラスをインスタンス化したインタフェースオブジェクトと、前記少なくとも２つの部品オブジェクトの各々と前記インタフェースオブジェクトの間のリンクを含む、前記ＵＭＬで表記されるオブジェクト図を、前記ソフトウェアのモデルとして生成するオブジェクト図生成ステップと、
前記少なくとも２つの部品オブジェクトが前記メタ部品クラスから派生していることと、前記インタフェースオブジェクトが前記メタインタフェースクラスから派生していることと、前記リンクが存在することと、前記メタモデルとに基づいて、前記オブジェクト図は前記部品同士が前記インタフェースを介して通信することをモデル化しているという意味を所定の形式言語により表す意味モデルを生成する意味モデル生成ステップと、
を実行させることを特徴とする意味モデル生成プログラム。
（付記１１）
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義を含み、ＵＭＬで表記された第１のクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを格納する格納手段と、
前記格納手段から前記メタモデルを読み出して、前記ソフトウェアに含まれる部品を表す部品クラスを、前記メタ部品クラスのサブクラスとして定義することにより、前記ソフトウェアを前記メタモデルにしたがってモデル化したモデルを、前記部品クラスを含み前記ＵＭＬで表記される第２のクラス図として生成するクラス図生成手段と、
前記部品クラスから前記メタ部品クラスへの汎化と前記メタモデルに基づいて、前記第２のクラス図における前記部品クラスが前記部品をモデル化したクラスであるという前記第２のクラス図の意味を所定の形式言語により表す意味モデルを生成する意味モデル生成手段と、
を備えることを特徴とする意味モデル生成装置。
（付記１２）
コンピュータが、
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義を含み、ＵＭＬで表記された第１のクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを取得し、
前記ソフトウェアに含まれる部品を表す部品クラスを、前記メタ部品クラスのサブクラスとして定義することにより、前記ソフトウェアを前記メタモデルにしたがってモデル化したモデルを、前記部品クラスを含み前記ＵＭＬで表記される第２のクラス図として生成し、
前記部品クラスから前記メタ部品クラスへの汎化と前記メタモデルに基づいて、前記第２のクラス図における前記部品クラスが前記部品をモデル化したクラスであるという前記第２のクラス図の意味を所定の形式言語により表す意味モデルを生成する、
ことを特徴とする意味モデル生成方法。
【符号の説明】
【０５０８】
１０１、１０１ａ〜１０１ｃ  メタモデル
１０２  表記ルール
１０３  ＵＭＬツール
１０４  ＤＳＭ支援装置
１０５、１０５ａ〜１０５ｇ  モデル図
１０６、１０６ａ  モデル
１０７  コード生成テンプレート
１０８  コード生成装置
１０９  ソースコード
１１０  中間データ
２０１〜２１６、３０１、３０２、６０１、７０１、９０２〜９０４、１００１〜１００３、１２０１〜１２１６  クラス
２５１〜２７２、３０５〜３０８、６１０、６１４、６１５、７０９、９０１、９０５〜９１０、１０１２〜１０１８、１２５１〜１２６９  関係（汎化、関連、依存、集約、合成集約）
３０３、３０４、６０４〜６０９、７０５〜７０８、１００４〜１０１１、１１０６〜１１２１  ポート
４０１  入力装置
４０２  出力装置
４０３  モデル作成ナビゲーション部
４０４  メニュー選択部
４０５  部品用メニュー提供部
４０６  ポート用メニュー提供部
４０７  インタフェース用メニュー提供部
４０８  内部部品用メニュー提供部
４０９  タスク用メニュー提供部
４１０  モデル作成部
４１１  記憶装置
４１２  モデル図格納部
４１３  意味モデル格納部
４１４  テンプレート格納部
４１５  ソースコード格納部
４１６  メタモデル格納部
５００  コンピュータ
５０１  ＣＰＵ
５０２  ＲＯＭ
５０３  ＲＡＭ
５０４  通信インタフェース
５０５  ハードディスク装置
５０６  可搬型記憶媒体
５０７  駆動装置
５０８  バス
５０９  ネットワーク
５１０  プログラム提供者
６０２、６０３、７０２〜７０４、１１０１〜１１０５、１３０１〜１３１０  オブジェクト
６１１〜６１３、７１０、１１２２〜１１２８、１３２１〜１３２５、１３３１〜１３３７  リンク
８０１〜８０３  活性期間
８０４、８０５  呼び出し
１３４１〜１３４６  コメント
１３５１〜１３５６  点線
【図１】
0005457761.tif 000002
【図２】
0005457761.tif 000003
【図３】
0005457761.tif 000004
【図４】
0005457761.tif 000005
【図５】
0005457761.tif 000006
【図６】
0005457761.tif 000007
【図７】
0005457761.tif 000008
【図８】
0005457761.tif 000009
【図９Ａ】
0005457761.tif 000010
【図９Ｂ】
0005457761.tif 000011
【図９Ｃ】
0005457761.tif 000012
【図９Ｄ】
0005457761.tif 000013
【図１０】
0005457761.tif 000014
【図１１】
0005457761.tif 000015
【図１２】
0005457761.tif 000016
【図１３】
0005457761.tif 000017
【図１４】
0005457761.tif 000018
【図１５】
0005457761.tif 000019
【図１６】
0005457761.tif 000020
【図１７】
0005457761.tif 000021