JP2011048796A

JP2011048796A - 意味モデル生成プログラムおよび意味モデル生成装置

Info

Publication number: JP2011048796A
Application number: JP2009198983A
Authority: JP
Inventors: Toru Eguchi; 亨江口
Original assignee: Fujitsu Computer Technologies Ltd
Current assignee: Fujitsu Computer Technologies Ltd
Priority date: 2009-08-28
Filing date: 2009-08-28
Publication date: 2011-03-10
Anticipated expiration: 2029-08-28
Also published as: JP5457761B2

Abstract

【課題】ソフトウェアのモデルを表すデータを、ソースコードの自動生成に適合するように生成し、ソフトウェアの生産性を向上させる。
【解決手段】メタモデルは、ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義を含み、ＵＭＬで表記された第１のクラス図により、ソフトウェアをメタモデル化して表すものである。プログラムにしたがってコンピュータは、メタモデルを取得し、ソフトウェアに含まれる部品を表す部品クラスを、メタ部品クラスのサブクラスとして定義することにより、ソフトウェアをメタモデルにしたがってモデル化したモデルを、部品クラスを含みＵＭＬで表記される第２のクラス図として生成する。コンピュータはさらに、部品クラスからメタ部品クラスへの汎化とメタモデルに基づいて、部品クラスが部品をモデル化したクラスであるという第２のクラス図の意味を形式言語により表す意味モデルを生成する。
【選択図】図１

Description

本発明は、ソフトウェア開発でのモデル化プロセスに関する。

ソフトウェア開発を支援するための様々な技術が開発されている。
例えば、オブジェクト指向言語で記述されたプログラムから、プログラムの構造を容易に理解できるオブジェクト図を出力する装置を実現することを目的とした、次のような技術が知られている。すなわち、ソースプログラムを入力とし、クラス定義情報抽出処理によりクラスの構造が抽出される。そして、クラスメソッド解析処理によりメンバデータの定義位置が決定され、クラス情報が生成され、オブジェクト図出力処理により出力装置を介してオブジェクト図が得られる。

また、図形情報の入力手段を表記法毎に開発する必要がなく、図形情報の入力手段を全表記法で共通化できるようにすることを目的とした、次のような技術も知られている。すなわち、メタモデル格納部がメタモデルを格納し、解析規則格納部が図形情報の解析のための複数の解析規則を格納する。そして、モデル操作部がモデルに含まれる要素等を規定した特定の表記法に従った図形情報を取得し、モデル生成部がメタモデルと図形情報の表記法に対応する解析規則とに基づいて図形情報を解析してモデルを生成する。

さらに、統一されたポリシーに基づくクラス図の作成を支援することを目的とした、次のような技術も知られている。すなわち、仕様書／設計書受付部により、開発対象のソフトウェアに関する作成済みの仕様書／設計書を受け付け、その中からシーケンス図を取り出す。また、クラス生成部により、シーケンス図を機能の種類毎に分類し、分類されたシーケンス図における機能で操作される対象を表す管理情報をクラスとするクラス図を生成する。そして、属性生成部により、シーケンス図の中からメッセージのパラメータを取得し、パラメータを対応するクラスの属性としてクラス図中に追加する。さらに、関連生成部により、属性を追加したクラス図から同じ属性を有するクラスの組を抽出し、それらのクラス間に関連を生成する。以上により、作成ポリシーを統一することができる。

特開平９−１８５４９７号公報特開２００７−１７２２２８号公報特開２００８−２８７３０５号公報

しかしながら、ソフトウェア開発においては人的能力に頼っている部分もいまだに多く残っており、ソフトウェアの生産性には改善の余地がある。そこで本発明は、ソフトウェア開発でのモデル化プロセスにおいて、ソフトウェアのモデルを表すデータを、ソースコードの自動生成に適合するように生成することで、ソフトウェアの生産性を向上させることを目的とする。

一態様において提供される意味モデル生成プログラムは、コンピュータにメタモデル取得ステップとクラス図生成ステップと意味モデル生成ステップを実行させる。
前記メタモデル取得ステップは、メタモデルを取得するステップである。なお、前記メタモデルは、ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義を含み、ＵＭＬで表記された第１のクラス図により、前記ソフトウェアをメタモデル化して表すものである。

前記クラス図生成ステップは、前記ソフトウェアに含まれる部品を表す部品クラスを、前記メタ部品クラスのサブクラスとして定義することにより、前記ソフトウェアを前記メタモデルにしたがってモデル化したモデルを、前記部品クラスを含み前記ＵＭＬで表記される第２のクラス図として生成するステップである。

前記意味モデル生成ステップは、前記部品クラスから前記メタ部品クラスへの汎化と前記メタモデルに基づいて、前記第２のクラス図における前記部品クラスが前記部品をモデル化したクラスであるという前記第２のクラス図の意味を所定の形式言語により表す意味モデルを生成するステップである。

上記意味モデル生成プログラムによれば、「部品クラスは部品をモデル化したクラスである」という意味を、意味モデルが明示している。したがって、上記意味モデル生成プログラムによれば、「どのクラスが何をモデル化しているのかを自動的に判別することができないために、適切なソースコードの自動生成が阻害される」といった問題が解決される。すなわち、上記のようにして生成される意味モデルは、ソースコードの自動生成に適しており、上記意味モデル生成プログラムは、ソフトウェアの生産性を向上させることができる。

第１実施形態によるソフトウェア開発支援の概要を説明する図である。第１のメタモデルを表すＵＭＬのクラス図である。第１のメタモデルにしたがう第１のモデルを表すＵＭＬのクラス図である。第１実施形態によるＤＳＭ支援装置およびその他の装置を示すブロック図である。コンピュータの構成図である。第１のメタモデルにしたがう第２のモデルを表すＵＭＬのクラス図である。第１と第２のモデルを統合したモデルにより設計されたソフトウェアの全体構造を示すＵＭＬのオブジェクト図である。図７のオブジェクト図に対応してソフトウェアの動作を定義するＵＭＬのシーケンス図である。第１と第２のモデルを統合したモデルを表すＸＭＬデータを示す図（その１）である。第１と第２のモデルを統合したモデルを表すＸＭＬデータを示す図（その２）である。第１と第２のモデルを統合したモデルを表すＸＭＬデータを示す図（その３）である。第１と第２のモデルを統合したモデルを表すＸＭＬデータを示す図（その４）である。第１実施形態によるモデル編集処理を説明する図である。第１実施形態による駆動順序定義処理を説明する図である。第１実施形態によるコード生成処理を説明する図である。第２のメタモデルを表すＵＭＬのクラス図である。第２のメタモデルにしたがうモデルを表すＵＭＬのクラス図である。図１４のモデルの利用例を示すＵＭＬのオブジェクト図である。第３のメタモデルを表すＵＭＬのクラス図である。第３のメタモデルにしたがうモデルを表すＵＭＬのオブジェクト図である。

以下、実施形態について、図面を参照しながら詳細に説明する。具体的には、まず図１〜５を参照して、メタモデルおよびモデルの例とともに第１実施形態の概要を説明し、次に図６〜１２を参照して、第１実施形態に関わる各種情報や各種処理の詳細を説明する。その後、図１３〜１７を参照して、他のメタモデルを用いる第２・第３実施形態についても説明する。最後に、その他の実施形態についても説明する。

図１は、第１実施形態によるソフトウェア開発支援の概要を説明する図である。なお、図１はＵＭＬ（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」クラス２１３から派生したクラスのオブジェクトを、部品クラスが有するように、ソフトウェアがモデル化されてもよい。

つまり、モデル図１０５中のクラスないしオブジェクトが何をモデル化したものであるかということは、直接的な派生か間接的な派生かを問わず、メタモデル１０１で定義されたクラスへの汎化に基づいて自動的に解釈可能である。よって、例えば部品クラスがメタ部品クラスから間接的に派生したものであっても、上記実施形態と同様に「ソースコード１０９の自動生成を可能とする」という効果が得られる。

また、メタモデル１０１は、ポートに関するクラスを含まなくてもよい。例えば第３実施形態のように、部品クラス（例えば「モータ」クラス１２１３）とインタフェースクラス（具体的には「データ」クラス１２０４）との間の関係を用いて、部品間のインタフェースを介した通信を表記することもできる。

なお、上記の説明においては、理解を容易とするために、例えば図３において汎化３０５と３０６を図示している。しかし、汎化３０５と３０６は、データとしてＤＳＭ支援装置１０４が生成し認識してさえいればよく、実施形態によっては、出力装置４０２に図形として表示されなくてもよい。

また、モデル１０６を記述する形式言語は、ＸＭＬでなくてもよい。ＸＭＬ以外の言語でモデル１０６を記述する場合は、図１のプロセスＰ１０２におけるコード生成は、ＸＳＬＴ技術以外の技術により行われる。

また、上記の実施形態は、メタモデル１０１と表記ルール１０２による制約を満たすようにＤＳＭ支援装置１０４がＵＭＬ図の作成をナビゲートする、いわば事前チェック型の実施形態である。しかし、ユーザが自由に作成したＵＭＬ図を、メタモデル１０１と表記ルール１０２に基づいてＤＳＭ支援装置１０４が事後的にチェックし、メタモデル１０１と表記ルール１０２による制約を満たさない箇所をエラーとして警告するような実施形態も可能である。

その場合、モデル作成部４１０は、例えばエラーが検出されなくなった段階のモデル図１０５を入力として受け取り、モデル図１０５からモデル１０６を作成してもよい。また、この事後チェック型の実施形態においては、モデル作成部４１０は、モデル図１０５からモデル１０６を作成するための中間データとして、例えば、モデル図１０５の図形的な特徴を表すＸＭＬデータを生成してもよい。

そして、モデル作成部４１０は、中間データとメタモデル１０１と表記ルール１０２に基づいて、最終的なモデル１０６を作成してもよい。中間データは、例えば、「どの矩形とどの矩形がどの線により接続されているか」といった図形的な特徴を表すものでもよい。モデル作成部４１０はメタモデル１０１と表記ルール１０２に基づいて、線や矩形の意味を解釈し、最終的なモデル１０６を作成することができる。

例えば、部品クラスに関しては、上記の事前チェック型の実施形態では、部品用メニュー提供部４０５が、部品クラスを新規作成するための指示を受け取り、当該指示を契機として、メタ部品クラスのサブクラスを部品クラスとしてクラス図内に作成する。それに対し、事後チェック型の実施形態では、部品用メニュー提供部４０５は、クラス図内に作成された任意のクラスからメタ部品クラスへの汎化を追加するための指示を受け取り、当該指示を契機として、上記任意のクラスを部品クラスとして定義しなおす。

インタフェースクラスに関しても同様のことが言える。つまり、事前チェック型の実施形態ではインタフェース用メニュー提供部４０７が、インタフェースクラスを新規作成するための指示を受け取り、当該指示を契機として、メタインタフェースクラスのサブクラスをインタフェースクラスとしてクラス図内に作成する。それに対し、事後チェック型の実施形態では、インタフェース用メニュー提供部４０７は、クラス図内に作成された任意のクラスからメタインタフェースクラスへの汎化を追加するための指示を受け取る。そして、インタフェース用メニュー提供部４０７は当該指示を契機として、上記任意のクラスクラスをインタフェースクラスとして定義しなおす。

最後に、上記の種々の実施形態に関して、さらに下記の付記を開示する。
（付記１）
コンピュータに、
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義を含み、ＵＭＬで表記された第１のクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを取得するメタモデル取得ステップと、
前記ソフトウェアに含まれる部品を表す部品クラスを、前記メタ部品クラスのサブクラスとして定義することにより、前記ソフトウェアを前記メタモデルにしたがってモデル化したモデルを、前記部品クラスを含み前記ＵＭＬで表記される第２のクラス図として生成するクラス図生成ステップと、
前記部品クラスから前記メタ部品クラスへの汎化と前記メタモデルに基づいて、前記第２のクラス図における前記部品クラスが前記部品をモデル化したクラスであるという前記第２のクラス図の意味を所定の形式言語により表す意味モデルを生成する意味モデル生成ステップと、
を実行させることを特徴とする意味モデル生成プログラム。
（付記２）
前記第１のクラス図は、前記部品間の通信のインタフェースをメタモデル化したメタインタフェースクラスの定義をさらに含み、
前記クラス図生成ステップは、
前記部品間の前記通信の前記インタフェースをモデル化したインタフェースクラスを、前記メタインタフェースクラスのサブクラスとして、前記第２のクラス図において定義するインタフェース定義ステップと、
前記インタフェースクラスとの間の関係を用いて、前記部品間の前記通信を前記第２のクラス図において表記するインタフェース表記ステップと、
を含み、
前記意味モデル生成ステップは、前記第２のクラス図における前記インタフェースクラスとの間の前記関係を、前記インタフェースクラスから前記メタインタフェースクラスへの汎化に基づいて、前記部品間の前記インタフェースを介した前記通信を意味する前記所定の形式言語の第１のコードで表現し、前記意味モデルに前記第１のコードを含めるインタフェース解釈ステップを含む、
ことを特徴とする付記１に記載の意味モデル生成プログラム。
（付記３）
前記第１のクラス図には、前記メタ部品クラスに含まれるクラスとして、メタ通信ポートクラスが定義されており、
前記クラス図生成ステップは、前記第２のクラス図において、前記部品クラスを、前記メタ通信ポートクラスまたは前記メタ通信ポートクラスのサブクラスとして定義される通信ポートクラスのいずれかのオブジェクトである通信ポートオブジェクトを含むように定義する通信ポート定義ステップをさらに含み、
前記インタフェース表記ステップは、前記部品クラスに含まれる前記通信ポートオブジェクトから前記インタフェースクラスへの依存を用いて、前記部品間の前記インタフェースを介した前記通信を前記第２のクラス図において表記するステップである、
ことを特徴とする付記２に記載の意味モデル生成プログラム。
（付記４）
前記インタフェース表記ステップは、前記部品クラスと前記インタフェースクラスとの間の関係を用いて、前記部品間の前記インタフェースを介した前記通信を前記第２のクラス図において表記するステップである、
ことを特徴とする付記２に記載の意味モデル生成プログラム。
（付記５）
前記クラス図生成ステップは、
前記部品クラスを新規作成するための第１の指示を受け取り、前記第１の指示を契機として、前記メタ部品クラスのサブクラスを前記部品クラスとして前記第２のクラス図内に作成する部品定義ナビゲーションステップ、または
前記第２のクラス図内に作成された任意の第１のクラスから前記メタ部品クラスへの汎化を追加するための第２の指示を受け取り、前記第２の指示を契機として、前記第１のクラスを前記部品クラスとして定義しなおす部品事後定義ステップ
を含むことを特徴とする付記１〜４のいずれか１項に記載の意味モデル生成プログラム。
（付記６）
前記インタフェース定義ステップは、
前記インタフェースクラスを新規作成するための第３の指示を受け取り、前記第３の指示を契機として、前記メタインタフェースクラスのサブクラスを前記インタフェースクラスとして前記第２のクラス図内に作成するインタフェース定義ナビゲーションステップ、または
前記第２のクラス図内に作成された任意の第２のクラスから前記メタインタフェースクラスへの汎化を追加するための第４の指示を受け取り、前記第４の指示を契機として、前記第２のクラスを前記インタフェースクラスとして定義しなおすインタフェース事後定義ステップ
を含むことを特徴とする付記２〜４のいずれか１項に記載の意味モデル生成プログラム。
（付記７）
前記第１のクラス図には、
部品同士が入れ子になってもよいことを示すための第１の集約関係と、
入れ子になった内部部品を有する外部部品の内部での、前記外部部品と前記内部部品との間の通信を表すためのメタ内部通信クラスと、
前記メタ部品クラスに前記メタ内部通信クラスが含まれることを示す第２の集約関係と、
が定義されており、
前記第２のクラス図において、前記部品クラスが複数あり、複数の前記部品クラスのうち前記外部部品をモデル化した外部部品クラスの中に、複数の前記部品クラスのうち前記内部部品をモデル化した内部部品クラスが入れ子になって含まれるとき、
前記クラス図生成ステップは、前記外部部品クラスと前記内部部品クラスの間に、前記メタ内部通信クラスに対応する関係である内部通信関係を定義する内部通信定義ステップを含み、
前記意味モデル生成ステップは、前記外部部品クラスと前記内部部品クラスそれぞれからの前記メタ部品クラスへの汎化と前記メタ内部通信クラスの定義とに基づいて、前記内部通信関係を、前記外部部品クラスと前記内部部品クラスの間の前記通信を意味する前記所定の形式言語の第２のコードで表現し、前記意味モデルに前記第２のコードを含める内部通信解釈ステップを含む、
ことを特徴とする付記１〜６のいずれか１項に記載の意味モデル生成プログラム。
（付記８）
前記意味モデル生成プログラムは前記コンピュータにさらに、前記第２のクラス図で定義された前記部品クラスのオブジェクトを定義するオブジェクト図に含まれるオブジェクト間の呼び出しを定義するシーケンス図を生成するシーケンス図生成ステップを実行させ、
前記意味モデル生成ステップは、前記シーケンス図の内容に基づいて、前記呼び出しの順序を前記所定の形式言語で表す第３のコードを生成し、前記第３のコードを前記意味モデルに含める第１の順序定義ステップを含む、
ことを特徴とする付記１〜７のいずれか１項に記載の意味モデル生成プログラム。
（付記９）
前記第１のクラス図には、前記メタ部品クラスに含まれるクラスとして、メタ呼び出しポートクラスが集約関係を使って定義されており、
前記クラス図生成ステップは、前記メタ呼び出しポートクラスまたは前記メタ呼び出しポートクラスのサブクラスのいずれかのオブジェクトである呼び出しポートオブジェクトを１つ以上備えるように前記部品クラスを定義する呼び出しポート定義ステップを含み、
前記意味モデル生成プログラムは前記コンピュータにさらに、前記第２のクラス図で定義された１つ以上の前記部品クラスの合計複数個のオブジェクトを定義するオブジェクト図において、前記オブジェクト図内の各オブジェクトがそれぞれ備える前記呼び出しポートオブジェクト間の関係を用いて、前記各オブジェクト間の呼び出しを表記する呼び出し表記ステップを実行させ、
前記意味モデル生成ステップは、前記オブジェクト図に表記された前記各オブジェクト間の前記呼び出しに基づいて、どのオブジェクトがどのオブジェクトを呼び出すかを前記所定の形式言語で表す第４のコードを生成し、前記意味モデルに前記第４のコードを含める第２の順序定義ステップを含む、
ことを特徴とする付記１〜７のいずれか１項に記載の意味モデル生成プログラム。
（付記１０）
コンピュータに、
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義と、前記部品間の通信のインタフェースをメタモデル化したメタインタフェースクラスの定義とを含み、ＵＭＬで表記されたクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを取得するメタモデル取得ステップと、
前記メタ部品クラスまたは前記メタ部品クラスのサブクラスをインスタンス化した少なくとも２つの部品オブジェクトと、前記メタインタフェースクラスまたは前記メタインタフェースクラスのサブクラスをインスタンス化したインタフェースオブジェクトと、前記少なくとも２つの部品オブジェクトの各々と前記インタフェースオブジェクトの間のリンクを含む、前記ＵＭＬで表記されるオブジェクト図を、前記ソフトウェアのモデルとして生成するオブジェクト図生成ステップと、
前記少なくとも２つの部品オブジェクトが前記メタ部品クラスから派生していることと、前記インタフェースオブジェクトが前記メタインタフェースクラスから派生していることと、前記リンクが存在することと、前記メタモデルとに基づいて、前記オブジェクト図は前記部品同士が前記インタフェースを介して通信することをモデル化しているという意味を所定の形式言語により表す意味モデルを生成する意味モデル生成ステップと、
を実行させることを特徴とする意味モデル生成プログラム。
（付記１１）
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義を含み、ＵＭＬで表記された第１のクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを格納する格納手段と、
前記格納手段から前記メタモデルを読み出して、前記ソフトウェアに含まれる部品を表す部品クラスを、前記メタ部品クラスのサブクラスとして定義することにより、前記ソフトウェアを前記メタモデルにしたがってモデル化したモデルを、前記部品クラスを含み前記ＵＭＬで表記される第２のクラス図として生成するクラス図生成手段と、
前記部品クラスから前記メタ部品クラスへの汎化と前記メタモデルに基づいて、前記第２のクラス図における前記部品クラスが前記部品をモデル化したクラスであるという前記第２のクラス図の意味を所定の形式言語により表す意味モデルを生成する意味モデル生成手段と、
を備えることを特徴とする意味モデル生成装置。
（付記１２）
コンピュータが、
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義を含み、ＵＭＬで表記された第１のクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを取得し、
前記ソフトウェアに含まれる部品を表す部品クラスを、前記メタ部品クラスのサブクラスとして定義することにより、前記ソフトウェアを前記メタモデルにしたがってモデル化したモデルを、前記部品クラスを含み前記ＵＭＬで表記される第２のクラス図として生成し、
前記部品クラスから前記メタ部品クラスへの汎化と前記メタモデルに基づいて、前記第２のクラス図における前記部品クラスが前記部品をモデル化したクラスであるという前記第２のクラス図の意味を所定の形式言語により表す意味モデルを生成する、
ことを特徴とする意味モデル生成方法。

１０１、１０１ａ〜１０１ｃメタモデル
１０２表記ルール
１０３ＵＭＬツール
１０４ＤＳＭ支援装置
１０５、１０５ａ〜１０５ｇモデル図
１０６、１０６ａモデル
１０７コード生成テンプレート
１０８コード生成装置
１０９ソースコード
１１０中間データ
２０１〜２１６、３０１、３０２、６０１、７０１、９０２〜９０４、１００１〜１００３、１２０１〜１２１６クラス
２５１〜２７２、３０５〜３０８、６１０、６１４、６１５、７０９、９０１、９０５〜９１０、１０１２〜１０１８、１２５１〜１２６９関係（汎化、関連、依存、集約、合成集約）
３０３、３０４、６０４〜６０９、７０５〜７０８、１００４〜１０１１、１１０６〜１１２１ポート
４０１入力装置
４０２出力装置
４０３モデル作成ナビゲーション部
４０４メニュー選択部
４０５部品用メニュー提供部
４０６ポート用メニュー提供部
４０７インタフェース用メニュー提供部
４０８内部部品用メニュー提供部
４０９タスク用メニュー提供部
４１０モデル作成部
４１１記憶装置
４１２モデル図格納部
４１３意味モデル格納部
４１４テンプレート格納部
４１５ソースコード格納部
４１６メタモデル格納部
５００コンピュータ
５０１ＣＰＵ
５０２ＲＯＭ
５０３ＲＡＭ
５０４通信インタフェース
５０５ハードディスク装置
５０６可搬型記憶媒体
５０７駆動装置
５０８バス
５０９ネットワーク
５１０プログラム提供者
６０２、６０３、７０２〜７０４、１１０１〜１１０５、１３０１〜１３１０オブジェクト
６１１〜６１３、７１０、１１２２〜１１２８、１３２１〜１３２５、１３３１〜１３３７リンク
８０１〜８０３活性期間
８０４、８０５呼び出し
１３４１〜１３４６コメント
１３５１〜１３５６点線

Claims

コンピュータに、
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義を含み、ＵＭＬで表記された第１のクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを取得するメタモデル取得ステップと、
前記ソフトウェアに含まれる部品を表す部品クラスを、前記メタ部品クラスのサブクラスとして定義することにより、前記ソフトウェアを前記メタモデルにしたがってモデル化したモデルを、前記部品クラスを含み前記ＵＭＬで表記される第２のクラス図として生成するクラス図生成ステップと、
前記部品クラスから前記メタ部品クラスへの汎化と前記メタモデルに基づいて、前記第２のクラス図における前記部品クラスが前記部品をモデル化したクラスであるという前記第２のクラス図の意味を所定の形式言語により表す意味モデルを生成する意味モデル生成ステップと、
を実行させることを特徴とする意味モデル生成プログラム。
前記第１のクラス図は、前記部品間の通信のインタフェースをメタモデル化したメタインタフェースクラスの定義をさらに含み、
前記クラス図生成ステップは、
前記部品間の前記通信の前記インタフェースをモデル化したインタフェースクラスを、前記メタインタフェースクラスのサブクラスとして、前記第２のクラス図において定義するインタフェース定義ステップと、
前記インタフェースクラスとの間の関係を用いて、前記部品間の前記通信を前記第２のクラス図において表記するインタフェース表記ステップと、
を含み、
前記意味モデル生成ステップは、前記第２のクラス図における前記インタフェースクラスとの間の前記関係を、前記インタフェースクラスから前記メタインタフェースクラスへの汎化に基づいて、前記部品間の前記インタフェースを介した前記通信を意味する前記所定の形式言語の第１のコードで表現し、前記意味モデルに前記第１のコードを含めるインタフェース解釈ステップを含む、
ことを特徴とする請求項１に記載の意味モデル生成プログラム。
前記第１のクラス図には、前記メタ部品クラスに含まれるクラスとして、メタ通信ポートクラスが定義されており、
前記クラス図生成ステップは、前記第２のクラス図において、前記部品クラスを、前記メタ通信ポートクラスまたは前記メタ通信ポートクラスのサブクラスとして定義される通信ポートクラスのいずれかのオブジェクトである通信ポートオブジェクトを含むように定義する通信ポート定義ステップをさらに含み、
前記インタフェース表記ステップは、前記部品クラスに含まれる前記通信ポートオブジェクトから前記インタフェースクラスへの依存を用いて、前記部品間の前記インタフェースを介した前記通信を前記第２のクラス図において表記するステップである、
ことを特徴とする請求項２に記載の意味モデル生成プログラム。
前記クラス図生成ステップは、
前記部品クラスを新規作成するための第１の指示を受け取り、前記第１の指示を契機として、前記メタ部品クラスのサブクラスを前記部品クラスとして前記第２のクラス図内に作成する部品定義ナビゲーションステップ、または
前記第２のクラス図内に作成された任意の第１のクラスから前記メタ部品クラスへの汎化を追加するための第２の指示を受け取り、前記第２の指示を契機として、前記第１のクラスを前記部品クラスとして定義しなおす部品事後定義ステップ
を含むことを特徴とする請求項１〜３のいずれか１項に記載の意味モデル生成プログラム。
前記インタフェース定義ステップは、
前記インタフェースクラスを新規作成するための第３の指示を受け取り、前記第３の指示を契機として、前記メタインタフェースクラスのサブクラスを前記インタフェースクラスとして前記第２のクラス図内に作成するインタフェース定義ナビゲーションステップ、または
前記第２のクラス図内に作成された任意の第２のクラスから前記メタインタフェースクラスへの汎化を追加するための第４の指示を受け取り、前記第４の指示を契機として、前記第２のクラスを前記インタフェースクラスとして定義しなおすインタフェース事後定義ステップ
を含むことを特徴とする請求項２または３に記載の意味モデル生成プログラム。
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義を含み、ＵＭＬで表記された第１のクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを格納する格納手段と、
前記格納手段から前記メタモデルを読み出して、前記ソフトウェアに含まれる部品を表す部品クラスを、前記メタ部品クラスのサブクラスとして定義することにより、前記ソフトウェアを前記メタモデルにしたがってモデル化したモデルを、前記部品クラスを含み前記ＵＭＬで表記される第２のクラス図として生成するクラス図生成手段と、
前記部品クラスから前記メタ部品クラスへの汎化と前記メタモデルに基づいて、前記第２のクラス図における前記部品クラスが前記部品をモデル化したクラスであるという前記第２のクラス図の意味を所定の形式言語により表す意味モデルを生成する意味モデル生成手段と、
を備えることを特徴とする意味モデル生成装置。