本発明は、複数のデータモデル間に跨るデータ整合性の検証を行うための、ＵＭＬ（Unified Modeling Language）に代表されるモデリング言語のアクティビティ図の解析技術に関するものである。

ソフトウェアシステムの開発において、標準モデリング言語であるＵＭＬ（Unified Modeling Language）を用いたコンポーネントベース開発が広く行われている。 コンポーネントが提供する操作の振る舞いの仕様定義には、アクティビティ図が広く用いられている。 複数のコンポーネントを統合する際には、各コンポーネントのアクティビティモデルの振る舞いの組み合わせが、システム内のデータの整合性を保っているか否かを確認する必要がある。

図１７の例を用いて説明する。 図１７のパッケージ１７０１は、ソフトウェアシステムを表し、インテグレータ１７０４によって統合された、４つのインターフェースと、各インターフェースを実現する４つのコンポーネントから構成される。 １７０２と１７０３は各々、コンポーネントＷＳＤｅｐｌｏｙｍｅｎｔＡｇｅｎｔの操作ｓｙｓＤｅｐｌｏｙＷＳ、コンポーネントＮｏｄｅの操作ｄｅｐｌｏｙＷＳの振る舞いを記述するアクティビティである。 参照制約１７０５は、ＷＳＬｏｃａｔｏｒインスタンスの属性ｗｓＤｅｆＩＤと同じ値を属性ｉｄに持つＷＳＤｅｆインスタンスが存在する、という整合性制約を表している。

アクティビティ１７０２と１７０３には、各種のアクションが記述されている。 パラメータ１７１１で受け取った値をアクション１７０６で変数Ｖａｒに書き込み、アクション１７０７で読み出す。 その値を、アクション１７０８で引数ｗｓＤｅｆＩＤに指定して、操作ｗｓＤｅｆＲｅｇｉｓｔｅｒｅｄを呼び出す。 この操作は、パラメータｗｓＤｅｆＩＤの値を属性ｉｄに持つＷＳＤｅｆインスタンスの存在を照合する。 その後、変数Ｖａｒの値をアクション１７０９で読み出し、その値を、アクション１７１０で引数ｗｓＤｅｆＩＤに指定して、操作ｄｅｐｌｏｙＷＳを呼び出す。 アクティビティ１７０３は、パラメータｗｓＤｅｆＩＤの値を、アクション１１３でオブジェクトの属性ｉｄに書き込み、そのオブジェクトを引数ｌｏｃａｔｏｒに指定して、操作ａｄｄＬｏｃａｔｏｒを呼び出す。 この操作は、パラメータｌｏｃａｔｏｒの属性ｉｄの値を、ＷＳＬｏｃａｔｏｒインスタンスの属性ｗｓＤｅｆＩＤに代入する。 アクティビティ１７０２と１７０３の組み合わせは、代入操作ａｄｄＬｏｃａｔｏｒを呼び出す前に、照合操作ｗｓＤｅｆＲｅｇｉｓｔｅｒｅｄを呼び出すことによって、参照制約１７０５の整合性を保証している。 ここで吹き出し１７１５と１７１６は、照合と代入を説明するためにモデルに加えた注釈である。

モデルベースの開発では、仕様定義段階でデータの整合性を確保することが重要である。

コンポーネントを統合するインテグレータ１７０４は，システムが提供する機能毎に、コンポーネントのアクティビティの組み合わせが、データの整合性制約を満たしているか、確認を行う。 しかしモデルの詳細な知識は各ＳＣの開発者に分散しており、更にモデルの組み合わせは各システム機能に対応して数多く存在する。 従って、人手で誤りなく網羅的に整合性を確認することは困難である。

非特許文献１と非特許文献２では、アクティビティの構成要素であるアクション記述の列＜ｎ，ａｃt＞＋の，データ整合性の自動検証方法が提案されている。 ここでｎはアクションａｃtの実行回数であり，ａｃtがループ中で実行される場合にはｎ＞０である。 列中のアクションの実行によって、データ整合性が破壊される恐れがある。 そこでアクションの種別毎に、整合性を満たすために必要な補完アクションを定義して、列上の各要素の補完アクションが列に包含される場合に、整合性制約が保たれると判定する。 各アクションと、その補完アクションの記述の対応は，アクションの引数として与えるインスタンスの参照から特定される。 例えば分類子ｃｌｆｒのインスタンスｏの生成を表すアクション記述ｏ：＝ＣｒｅａｔｅＯｂｊｅｃｔ（ｃｌｆｒ）の補完アクションの記述は、次の２つである。 第一は、ｃｌｆｒの必須属性ａｔｔに値ｖを設定するＡｄｄＳｔｒｕｃｔｕｒａｌＦｅａｔｕｒｅ（ｏ，ａｔ，ｖ）である。 第二は、必須の関連ａｓに対応して，クラスｃのインスタンスｏ２との間にリンクを生成する＜ｍｉｎ（ｃ，ａｓ），ＣｒｅａｔｅＬｉｎｋ（ａｓ，ｐ，ｏ，ｐ２，ｏ２）＞である。 ここで、ｍｉｎ（ｃ，ａｓ）は関連の多重度の下限を表わし、ｐ、ｐ２はリンク端である。

前述の非特許文献１と非特許文献２で述べられている技術は、単一のデータモデルの整合性に関するアクション記述列の検証を目的としており、前述の参照制約１７０５のように、複数のデータモデル間に跨るデータ整合性の検証には適用することが出来ない。

本発明は、係る課題に鑑みなされたものであり、アクティビティ図を対象として、複数のデータモデル間に跨るデータ整合性の検証を行う機能を持つモデリング言語設計支援装置及びその制御方法を提供しようとするものである。

この課題を解決するため、例えば本発明の設計支援装置は以下の構成を備える。 すなわち、
アクション記述を含む、モデリング言語で記述されたモデルを入力として、前記アクション記述を解析し、前記アクション記述と検証項目の整合性を検証する設計支援装置であって、
検証すべき検証項目を指定する指定手段と、
指定された前記検証項目と入力されたモデルに含まれるアクション記述との整合性を検証して、検証結果情報を生成する検証手段と、
前記入力されたモデルと前記検証結果情報とを表示する表示手段とを有する。

本発明によれば、多数のアクティビティ図を対象として、複数のデータモデル間に跨るデータ整合性を、誤りなく網羅的に確認することが出来る。

実施形態におけるＵＭＬ設計ツールのシステム構成図。

実施形態におけるソフトウェア構成図。

実施形態におけるＵＭＬ設計ツールの表示画面。

実施形態におけるＵＭＬ設計ツールの表示画面。

実施形態における検証プロパティ指定部の処理を示すフローチャート。

実施形態における検証部の処理を示すフローチャート。

実施形態における依存の解析サブルーチンのフローチャート。

実施形態における変数定義の解析サブルーチンのフローチャート。

実施形態におけるデータ伝搬の説明図。

実施形態におけるデータ伝搬の説明図。

実施形態におけるデータ伝搬の説明図。

実施形態におけるデータ伝搬の説明図。

実施形態における到達定義の解析サブルーチンのフローチャート。

実施形態における到達定義の取得サブルーチンのフローチャート。

実施形態におけるアクション実行履歴の計算サブルーチンのフローチャート。

実施形態における整合性の検証サブルーチンのフローチャート。

実施形態におけるＵＭＬモデルの説明図。

実施形態におけるアクティビティ図の要素の説明図。

以下、添付図面に従って本発明に係る実施形態を詳細に説明する。

図１は、本発明のＵＭＬ設計ツールとして機能するコンピュータ１００の構成を示している。 中央ユニット１０１はコンピュータ１００を制御する電子回路を収容する。 モニタ１０２はスクリーン１０３上にイメージを表示するために使用される。 キーボード１０４とマウス１０５は、ユーザの入力操作を受け付けるために使用される。 コンピュータ１００内には、ＣＰＵ、ＲＯＭ、ＲＡＭ、ハードディスク装置、表示コントローラ等を内蔵し、電源投入した際に、ＣＰＵがＲＯＭに格納されたブートプログラムに従い、ハードディスクに格納されたオペレーティングシステム（ＯＳ）をＲＡＭにロードし、しかる後、ＵＭＬ設計ツールに係るアプリケーションをハードディスクからＲＡＭにロードし実行することで、このコンピュータ１００がＵＭＬ設計ツール（モデリング言語の設計支援装置）として機能することとになる。

実施形態のＵＭＬ設計ツールのソフトウェア構成を図２に示す。 ＵＭＬモデル２０１は、ＸＭＩ等の形式でコンピュータ１００のストレージ（例えばハードディスク等）に保持される。 検証プロパティ指定部２０２は、ＵＭＬモデル２０１のクラス図の整合性制約を検証するために必要な、検証プロパティ２０３を指定し、コンピュータ１００のストレージ上に格納する。 検証部２０６は、検証プロパティ２０３を用いてＵＭＬモデル２０１の検証を行い、その結果を検証結果情報２０７としてコンピュータ１００のストレージ上に格納する。 ＵＭＬモデル２０１、検証プロパティ２０３、検証結果情報２０７は、ネットワーク上のサーバストレージに保持されても良い。 モデル表示処理部２０４は、ＵＭＬモデル２０１、検証プロパティ２０３、検証結果情報２０７から生成したイメージを、モニタ２０５に表示する。

図３は、表示処理部２０４によってモニタ２０５上に表示される、ＵＭＬ設計ツールの表示Ｗｉｎｄｏｗ３００の構成を示している。 構成Ｖｉｅｗ３０１には、ＵＭＬモデルの構成に従って、システム、パッケージ、インターフェース、操作、コンポーネント、クラス、等のモデル要素が階層的に表示される。 振る舞いＶｉｅｗ３０２には、ユーザがマウス１０５を用いて、構成Ｖｉｅｗ３０１上で選択した操作の振る舞いモデルが表示される。 図３では構成Ｖｉｅｗ３０１上でコンポーネントＣＰ１の操作Ｏｐ１が選択されており（破線の枠によってそのことが表現されている）、振る舞いＶｉｅｗ３０２にはコンポーネントＣＰ１の操作Ｏｐ１の振る舞いを示すアクティビティが表示されている。 検証プロパティＶｉｅｗ３０３には、検証項目としての検証範囲とアクション順序制約（アクション記述制約とも言う）が表示される。 振る舞いモデルから導出されるデータへのアクセス情報として、入力パラメータの属性値をクラスのインスタンスの属性へ代入する代入情報や、出力パラメータの属性値をクラスのインスタンスの属性として取得する取得情報がある。 また、入力パラメータの属性値を属性に持つクラスのインスタンスを削除する削除情報や、そのようなクラスのインスタンスの存在を照合し、照合結果を出力パラメータの属性値とする照合情報がある。

アクティビティの構成要素を、図１８に示す。 アクティビティは、ノードとエッジで構成されるグラフである。 ノードは、制御点を表すＣｏｎｔｒｏｌＮｏｄｅ、オブジェクトを表すＯｂｊｅｃｔＮｏｄｅ、処理を表すＥｘｅｃｕｔａｂｌｅＮｏｄｅに分類される。 エッジは制御点間の有向リンクを表すＣｏｎｔｒｏｌＦｌｏｗ、またはオブジェクト間の有向リンクを表すＯｂｊｅｃｔＦｌｏｗに分類される。 Ａｃｔｉｏｎは単一の処理を表し、ＳｔｒｕｃｔｕｒａｌＡｃｔｉｖｉｔｙＮｏｄｅは複数のノードを組み合わせた処理を表す。 Ｖａｒｉａｂｌｅは一時的な情報を保持するローカル変数である。 Ａｃｔｉｏｎの分類１−５は各々、オブジェクトの生成・消滅、属性値の追加・削除・取得、変数値の追加・削除・取得，値の指定、操作の呼び出しを表す。

検証プロパティＶｉｅｗ３０３のアクション順序制約は、整合性を保つために振る舞いモデルが満たすべき性質を表わす制約であり、各制約は、アクションの実行順序と、アクションに与える引数の間の関係から成る。 図３では制約３０８、制約３０９の２つの制約が表示されている。 制約３０８は、コンポーネントＣＰ５の操作ｏｐ５に、引数ｚを与えて呼び出すアクションに先立ち、コンポーネントＣＰ４の操作ｏｐ４に、引数ｘとｙを与えて呼び出すアクションが実行され、引数ｘの属性ａｔｔ１とｚの値が等しいことを表す。 ユーザがマウス１０５を用いて、制約の追加ボタン３０６を押下して制約を追加し、キーボード１０４を用いて、制約の内容を指定する。 また、制約の削除ボタン３０７を押下して、制約を削除する。 なお、ＵＭＬモデル２０１の内容を元に、検証プロパティ指定部２０２がアクション順序制約を自動的に生成しても良い。

検証プロパティＶｉｅｗ３０３の検証範囲は、アクション順序制約の検証を行う範囲を指定する。 ユーザが検証範囲の生成ボタン３０４を押下することにより、検証プロパティ指定部２０２が、振る舞いＶｉｅｗ３０２に表示されている振る舞いのコールグラフを生成し、表示処理部２０４がモニタ２０５に表示する。

ユーザがマウス１０５を用いて、検証の実行ボタン３０５を押下することにより、検証部２０６が、検証範囲に表示されたコールグラフに含まれるアクティビティの組み合わせに対して、選択されたアクション順序制約の検証を実行する。 検証部２０６は、検証結果情報２０７、検証結果と反例情報を生成し、さらに図４の画面に遷移して、表示処理部２０４が検証結果４１０と、反例情報４１１、４１２を表示する。 検証結果４１０は、検証範囲に含まれるアクティビティの組み合わせが、制約４０８を満たさないことを表しており、反例情報４１１、４１２は、アクティビティ中の各制御ノード上の、アクションの実行履歴を示している。 反例情報４１１は、ＣＰ４の操作ｏｐ４が未実行で、かつＣＰ５の操作ｏｐ５が実行済みであることを表している。 このように図４の表示内容から、ユーザは制約の検証結果と、その反例情報を得ることが出来る。

検証プロパティ指定部２０２の、検証範囲のコールグラフの生成処理のフローを図５に示す。 ５０１において、検証プロパティ指定部２０２は、各操作が呼び出す操作集合を保持するコールグラフＣＧと、操作キューｑを空に初期化する。 次で、５０２において、構成Ｖｉｅｗ３０２で選択された操作をキューｑに詰める。 そしてキューｑが空になるまで、５０３から５０９の処理を繰り返す。 先ず５０３において、キューｑから操作ｏｐを取り出し、５０４において操作ｏｐの振る舞いを記述するアクティビティを解析する。 アクティビティ中で呼び出す他の全ての操作ｏｐ'について、５０６でｏｐとｏｐ'の組をＣＧに追加し、５０７でｏｐ'をキューｑに詰める。 以上の処理によって、検証プロパティＶｉｅｗ３０３に示されている検証範囲のコールグラフの情報が生成される。

検証部２０６の処理フローを図６に示す。 検証部２０６は、先ず６０１において、アクティビティ中のＯｂｊｅｃｔＮｏｄｅの依存関係を保持するＩＮ、ＯＵＴ、ＯｂｊｅｃｔＮｏｄｅの到達定義を保持するＤＥＦ、アクションの実行履歴を保持するＨＩＳＴの各々を、空に初期化する。 次に６０２から６０６において、コールグラフに含まれる各アクティビティについて、６０３でアクティビティ中の各ノードに到達する変数定義ノードを保持するＲＥＡＣＨを空に初期化する。 そして６０４で変数定義の解析サブルーチンを呼び出し、ＲＥＡＣＨを求める。 ６０５で依存の解析サブルーチンを呼び出し、ＩＮとＯＵＴを求める。 次に６０７から６０９で、コールグラフに含まれる各アクティビティについて、６０８で到達定義の解析サブルーチンを呼び出し、ＤＥＦを求める。 さらに６１０において、アクション実行履歴の計算サブルーチンを呼び出し、ＨＩＳＴを求める。 ６１０のＣＯＮＳは、検証対象のアクション順序制約である。 最後に６１１で整合性の検証サブルーチンを呼び出す。

アクティビティ中のＯｂｊｅｃｔＮｏｄｅ間には、３種類のデータ伝搬により、依存関係が発生する。 第一の伝搬は、図９の例に示すようにＯｂｊｅｃｔＦｌｏｗによって表現される。 Ｐｉｎ１とＰｉｎ２の２つのＯｂｊｅｃｔＮｏｄｅの間に、依存関係が存在する。 第二の伝搬は、図１０の例に示すＯｂｊｅｃｔＮｏｄｅの属性の書き込みと、図１１の例に示すＯｂｊｅｃｔＮｏｄｅの属性の読込によって表現される。 図１０の書き込みの例では、ｖａｌｕｅノードの値がｒｅｓｕｌｔノードの属性ｐｒｏｐに伝搬し、ｏｂｊｅｃｔノードのｐｒｏｐ以外の属性の値が、ｒｅｓｕｌｔノードの対応する属性に伝搬する。 第三の伝搬は、図１２の例に示す、変数値の書き込みと読み出しの組み合わせによって表現される。 図１１で、先行するＡｄｄＶａｒｉａｂｌｅＶａｌｕｅＡｃｔｉｏｎノードで変数ｖａｒにｖａｌｕｅノード値の書き込みを行い、後続のＲｅａｄＶａｒｉａｂｌｅＡｃｔｉｏｎで変数ｖａｒの値の読み出しを行うフローが表現されている。 この場合に、ｖａｌｕｅノードの値がｖａｒを介してｒｅｓｕｌｔノードに伝搬する。

依存の解析サブルーチンでは、指定されたアクティビティａｃｔ中の、オブジェクトを表すＯｂｊｅｃｔＮｏｄｅの各々について、上記の３種類のデータ伝搬により発生する依存関係ＩＮ、ＯＵＴを求める。 依存の解析サブルーチンのフローチャートを図７に示す。 ７０１から７３６において、アクティビティ中の全てのＥｘｅｃｕｔａｂｌｅノードｅｘｅｃ＿ｎｄについて、依存関係を求める。

先ず７０２から７１７において、第一の伝搬による依存関係を求める。 ｅｘｅｃ＿ｎｄの全てのｎｄ∈Ｐｉｎ∪ＥｘｐａｎｓｉｏｎＮｏｄｅについて、７０３から７０９で、ｎｄの全ての入力フローｉｎ＿ｆｌｏｗを処理する。 ７０４でｉｎ＿ｆｌｏｗの始点をｓｒｃ＿ｎｄとして求め、７０５から７０８まで、ｎｄの全ての属性ｐｒｏｐについて、処理を行う。 ７０６で（ｎｄ，ｐｒｏｐ）の入力の依存として、（ｓｒｃ＿ｎｄ，ｐｒｏｐ）をＩＮに追加し、７０７で（ｓｒｃ＿ｎｄ，ｐｒｏｐ）の出力の依存として、（ｎｄ，ｐｒｏｐ）をＯＵＴに追加する。 出力フローについても同様に、７１０から７１６で、ｎｄの全ての出力フローｏｕｔ＿ｆｌｏｗを処理する。 ７１１でｏｕｔ＿ｆｌｏｗの終点をｄｓｔ＿ｎｄとして求め、７１２から７１５まで、ｎｄの全ての属性ｐｒｏｐについて、処理を行う。 ７１３で（ｎｄ，ｐｒｏｐ）の出力の依存として、（ｄｓｔ＿ｎｄ，ｐｒｏｐ）をＯＵＴに追加し、７１４で（ｄｓｔ＿ｎｄ，ｐｒｏｐ）の入力の依存として、（ｎｄ，ｐｒｏｐ）をＩＮに追加する。 ｎｄが属性を持たない場合、ｐｒｏｐの代わりにｎｕｌｌを指定する。

次に７１８から７２９の処理で、第二の伝搬による依存関係を求める。 ７１８で、ｅｘｅｃ＿ｎｄが属性の書き込みを行うＡｄｄＳｔｒｕｃｔｕｒａｌＦｅａｔｕｒｅＶａｌｕｅＡｃｔｉｏｎである場合に、７１９でｅｘｅｃ＿ｎｄからＯｂｊ、Ｖａｌ、Ｒｅｓｕｌｔ、Ｐｒｏｐを求める。 これらは其々、図１０のｏｂｊｅｃｔノード、ｖａｌｕｅノード、ｒｅｓｕｌｔノード、属性ｐｒｏｐに対応する。 ７２０において、（Ｒｅｓｕｌｔ，Ｐｒｏｐ）の入力の依存として（Ｖａｌ，ｎｕｌｌ）をＩＮに追加し、７２１において、（Ｖａｌ，ｎｕｌｌ）の出力の依存として（Ｒｅｓｕｌｔ，Ｐｒｏｐ）をＯＵＴに追加する。 そして７２２から７２５で、ＲｅｓｕｌｔのＰｒｏｐ以外の全ての属性Ｐｒｏｐ'について処理を行う。 ７２３で（Ｒｅｓｕｌｔ，Ｐｒｏｐ'）の入力の依存として（Ｏｂｊ，Ｐｒｏｐ'）をＩＮに追加し、７２４において、（Ｏｂｊ，Ｐｒｏｐ'）の出力の依存として（Ｒｅｓｕｌｔ，Ｐｒｏｐ'）をＯＵＴに追加する。 ７２６で、ｅｘｅｃ＿ｎｄが属性の読み出しを行うＲｅａｄＳｔｒｕｃｔｕｒａｌＦｅａｔｕｒｅＡｃｔｉｏｎである場合に、７２７でｅｘｅｃ＿ｎｄからＯｂｊ、Ｒｅｓｕｌｔ、Ｐｒｏｐを求める。 これらは其々、図１１のｏｂｊｅｃｔノード、ｒｅｓｕｌｔノード、属性ｐｒｏｐに対応する。 ７２８において、（Ｒｅｓｕｌｔ，ｎｕｌｌ）の入力の依存として（Ｏｂｊ，Ｐｒｏｐ）をＩＮに追加し、７２９において、（Ｏｂｊ，Ｐｒｏｐ）の出力の依存として（Ｒｅｓｕｌｔ，ｎｕｌｌ）をＯＵＴに追加する。

最後に７３０から７３５の処理で、第三の伝搬による依存関係を求める。 ７３０で、ｅｘｅｃ＿ｎｄが変数値の読み出しを行うＲｅａｄＶａｒｉａｂｌｅＡｃｔｉｏｎである場合に、７３１でｅｘｅｃ＿ｎｄからＲｅｓｕｌｔを求める。 これは、図１２のｒｅｓｕｌｔノードに対応する。 ７３２から７３５で、ＲＥＡＣＨに含まれる、ｅｘｅｃ＿ｎｄに到達する全ての変数定義ノードｖａｌ＿ｎｄについて、処理を行う。 ７３３で（Ｒｅｓｕｌｔ，ｎｕｌｌ）の入力の依存として（ｖａｌ＿ｎｄ．ｖａｌｕｅ，ｎｕｌｌ）をＩＮに追加し、７３４において、（ｖａｌ＿ｎｄ．ｖａｌｕｅ，ｎｕｌｌ）の出力の依存として（Ｒｅｓｕｌｔ，ｎｕｌｌ）をＯＵＴに追加する。 ｖａｌ＿ｎｄ． ｖａｌｕｅは、図１２のｖａｌｕｅノードに対応する。

変数定義の解析サブルーチンは、指定されたアクティビティａｃｔ中の各ノードに到達する変数定義ノードを保持するＲＥＡＣＨを計算する。 変数の書き込みは、他の箇所での書き込みや削除，消去によって無効化される可能性がある。 そこで変数定義の解析サブルーチンでは、アクティビティ中の各ノードにおいて無効化されるノードを保持するＫＩＬＬを最初に計算する。 変数定義の解析サブルーチンのフローチャートを図８に示す。 ８０１において、ＫＩＬＬを空に初期化する。 ８０２から８０７において、ａｃｔ中の全てのアクションｎｄ１とｎｄ２の組み合わせについて、処理を行う。 ８０４でｎｄ１が、変数に書き込みを行うＡｄｄＶａｒｉａｂｌｅＶａｌｕｅＡｃｔｉｏｎ、変数値の消去、削除を行うＲｅｍｏｖｅＶａｒｉａｂｌｅＶａｌｕｅＡｃｔｉｏｎ、ＣｌｅａｒＶａｒｉａｂｌｅＡｃｔｉｏｎの何れに該当するか確認する。 さらにｎｄ２がＡｄｄＶａｒｉａｂｌｅＶａｌｕｅＡｃｔｉｏｎであり、ｎｄ１とｎｄ２の変数が等しい場合に、８０５で、ｎｄ２を、ｎｄ１で無効化される変数定義ノードとして、ＫＩＬＬに追加する。 ８０８から８２１で、ＲＥＡＣＨが定常値になるまで繰り返し計算を行う。 先ず８０８で、ＲＥＡＣＨの値を、前回の繰り返し時のＲＥＡＣＨの値を保持するＲＥＡＣＨ'に設定する。 繰り返しの初回のＲＥＡＣＨ'の値は空である。 その後にＲＥＡＣＨ'を空に初期化する。 ８０９から８２０において、ａｃｔの全てのｎｄ∈ＣｏｎｔｒｏｌＮｏｄｅ∪ＥｘｅｃｕｔａｂｌｅＮｏｄｅと、ｎｄの全ての制御フロー上の直前ノードｐｒｅｖ＿ｎｄについて、処理を行う。 ８１１でｐｒｅｖ＿ｎｄがＡｄｄＶａｒｉａｂｌｅＶａｌｕｅＡｃｔｉｏｎの場合は、８１２で、ｎｄに到達する変数定義を行うノードとして、ｐｒｅｖ＿ｎｄをＲＥＡＣＨ'に追加する。 ８１３から８１５において、ＲＥＡＣＨに含まれる、ｐｒｅｖ＿ｎｄに到達する全ての変数定義ノードｒｅａｃｈ＿ｎｄについて、処理を行う。 ８１４において、ｎｄに到達するノードとして、ｒｅａｃｈ＿ｎｄをＲＥＡＣＨ'に追加する。 ８１６から８１８において、ＫＩＬＬに含まれる、ｐｒｅｖ＿ｎｄで無効化される全ての変数定義ノードｋｉｌｌ＿ｎｄについて、処理を行う。 ｋｉｌｌ＿ｎｄはｎｄに到達しないので、８１７でｋｉｌｌ＿ｎｄをＲＥＡＣＨ'から削除する。

到達定義の解析サブルーチンのフローチャートを図１３に示す。 指定されたアクティビティａｃt中の全ての組（ｎｄ，ｐｒｏｐ）∈（ＯｂｊｅｃｔＮｏｄｅ，Ｐｒｏｐｅｒｔｙ）について、１３０２で到達定義の取得サブルーチンを呼び出し、（ｎｄ，ｐｒｏｐ）のに到達するデータの定義を求める。

到達定義の取得サブルーチンのフローチャートを図１４に示す。 到達定義の取得サブルーチンは、再帰的に動作する。 １４０１において、指定された（ｎｄ'，ｐｒｏｐ'）∈（ＯｂｊｅｃｔＮｏｄｅ，Ｐｒｏｐｅｒｔｙ）について到達定義を取得済みの場合は、１４２５において、（ｎｄ'，ｐｒｏｐ'）の到達定義を保持する変数Ｄｅｆに、取得済みの値を設定する。 一方未取得の場合は、１４０２で、Ｄｅｆを空に初期化し、（ＯｂｊｅｃｔＮｏｄｅ，Ｐｒｏｐｅｒｔｙ）を詰めるキューｑを空に初期化した後、ｑに（ｎｄ'，ｐｒｏｐ'）を詰める。 そしてｑが空になるまで、１４０３から１４２４の処理を繰り返す。 １４０４において、ｑから（ｎｄ，ｐｒｏｐ）∈（ＯｂｊｅｃｔＮｏｄｅ，Ｐｒｏｐｅｒｔｙ）を取得し、１４０５でＤｅｆに追加する。

１４０６から１４０９まで、ＩＮに保持されている（ｎｄ，ｐｒｏｐ）の全ての入力の依存（ｓｒｃ＿ｎｄ，ｓｒｃ＿ｐｒｏｐ）について処理を行い、ｎｄと同一のアクティビティ内の到達定義を求める。 １４０７で（ｓｒｃ＿ｎｄ，ｓｒｃ＿ｐｒｏｐ）がＤｅｆに含まれない場合に、１４０８で（ｓｒｃ＿ｎｄ，ｓｒｃ＿ｐｒｏｐ）をｑに詰める。

１４１０から１４１７において、ｎｄがアクティビティの入力パラメータである場合に、該アクティビティの呼び出し元の到達定義を解析する。 １４１１から１４１７において、ＣＧに含まれる操作ｏｐ1とｏｐ２の組（ｏｐ1，ｏｐ２）の中で、ｏｐ２の振る舞いを表すアクティビティにｎｄが含まれるような、全てのｏｐ１について、処理を行う。 １４１２から１４１６において、ｏｐ１のアクティビティの中で、ｎｄが含まれるアクティビティの操作を呼び出す、全てのアクションａｃｔについて、処理を行う。 １４１３で、ｎｄに対応するａｃｔのパラメータのＯｂｊｅｃｔＮｏｄｅをＣａｌｌｅｒ＿ｎｄとして取得する。 そして１４１４で、到達定義の取得サブルーチンを再帰的に呼び出し、（Ｃａｌｌｅｒ＿ｎｄ，ｐｒｏｐ）の到達定義を取得し、変数ｄｅｆｓに格納する。 さらに１４１５で、ｄｅｆｓの要素全てをＤｅｆに追加する。

１４１８から１４２４において、ｎｄが操作呼び出しの出力パラメータを表すＯｂｊｅｃｔＮｏｄｅである場合に、呼び出し先の操作の到達定義を解析する。 １４１９において、呼び出される操作をＣａｌｌｅｅ＿ｏｐとする。 １４２０において、Ｃａｌｌｅｅ＿ｏｐの振る舞いをモデル化するアクティビティが存在する場合に、１４２１から１４２４で、Ｃａｌｌｅｅ＿ｏｐのアクティビティの、ｎｄと同名の出力パラメータを表す全てのＣａｌｌｅｅ＿ｎｄについて処理を行う。 １４２２において、到達定義の取得サブルーチンを再帰的に呼び出し、（Ｃａｌｌｅｅ＿ｎｄ，ｐｒｏｐ）の到達定義を取得し、変数ｄｅｆｓに格納する。 さらに１４２３で、ｄｅｆｓの要素全てをＤｅｆに追加する。

１４０３で、ｑが空の場合は、１４２６でＤｅｆの要素を全てＤＥＦに登録し、Ｄｅｆをリターンする。

アクション実行履歴の計算サブルーチンは、各アクティビティの制御ノードにおける、アクションの実行履歴ＨＩＳＴを計算する。 図１５にその処理フローを示す。 アクション実行履歴の計算サブルーチンでは、先ず１５０１において、繰り返し計算の途中結果を保持するＨＩＳＴ'を空に設定する。 １５０２から１５０９において、コールグラフＣＧに含まれる全ての操作のアクティビティの、操作呼び出しｎｄについて、計算を行う。 １５０５において、ｎｄが呼び出す操作が、アクション順序制約ＣＯＮＳに含まれる操作の何れかである場合に、１５０６で、ｎｄにおけるアクション実行履歴として、ｎｄをＨＩＳＴに追加する。 ここでアクション順序制約ＣＯＮＳに含まれる操作とは、図４の制約４０８の場合では、ｏｐ４とｏｐ５である。 次に、１５１０から１５２２まで、ＨＩＳＴとＨＩＳＴ'が等しくなるまで計算を繰り返す。 先ず１５１１で、ＨＩＳＴ'にＨＩＳＴの値を設定する。 １５１２から１５２２において、コールグラフＣＧに含まれる全ての操作のアクティビティａｃｔに含まれる、全ての制御ノードｎｄ∈ＣｏｎｔｒｏｌＮｏｄｅ∪ＥｘｅｃｕｔａｂｌｅＮｏｄｅについて、１５１５から１５１９の処理を行う。 ｎｄの全ての直前ノードｐｒｅｖ＿ｎｄについて、ＨＩＳＴに登録されているｐｒｅｖ＿ｎｄのアクション実行履歴を、１５１７で、ｎｄの新たなアクション実行履歴としてＨＩＳＴに追加する。

整合性の検証サブルーチンは、ＣＧに含まれるアクティビティと、アクション順序制約ＣＯＮＳの整合性を検証する。 整合性の検証サブルーチンのフローチャートを図１６に示す。 １６０１から１６２１において、コールグラフＣＧに含まれる全ての操作のアクティビティａｃｔに含まれる、全ての制御ノードｎｄ∈ＣｏｎｔｒｏｌＮｏｄｅ∪ＥｘｅｃｕｔａｂｌｅＮｏｄｅについて、１６０４から１６１８の処理を行う。 １６０４から１６１８において、ＨＩＳＴに含まれるｎｄのアクション実行履歴ｈｉｓｔの全ての要素ｎｄ'について、処理を行う。 １６０５において、ｎｄ'の操作がＣＯＮＳの後続操作と等しい場合には、１６０６でＣＯＮＳの後続操作に指定されたパラメータをＰａｒａｍ２、ＣＯＮＳの後続操作に指定された属性をＰｒｏｐ２に代入する。 ここで図４の制約４０８の場合では、ＣＯＮＳの後続操作はｏｐ５であり、後続操作に指定されたパラメータはｚであり、後続操作に指定された属性はｎｕｌｌである。 １６０７において、ｎｄ'の、Ｐａｒａｍ２に相当するＰｉｎをＰｉｎ２とし、１６０８で変数Ｒｅａｃｈ１を空に初期化し、１６０９で変数Ｒｅａｃｈ２に、ＤＥＦに保存された（Ｐｉｎ２，Ｐｒｏｐ２）の到達定義を設定する。 そして１６１０から１６１５において、ｈｉｓｔに含まれるｎｄ'以外の全ての要素ｎｄ''について処理を行う。 １６１１でｎｄ''の操作がＣＯＮＳの先行操作と等しい場合に、１６１２で、ＣＯＮＳの先行操作に指定されたパラメータをＰａｒａｍ１、ＣＯＮＳの後続操作に指定された属性をＰｒｏｐ１とする。 ここで図４の制約４０８の場合では、ＣＯＮＳの先行操作はｏｐ４であり、後続操作に指定されたパラメータはｘであり、後続操作に指定された属性はａｔｔ１である。 １６１３において、ｎｄ''の、Ｐａｒａｍ１に相当するＰｉｎをＰｉｎ１とし、１６１４で、Ｒｅａｃｈ１に、ＤＥＦに保存された（Ｐｉｎ１，Ｐｒｏｐ１）の到達定義を追加する。 そして１６１６において、集合Ｒｅａｃｈ１とＲｅａｃｈ２が素である場合に、検証結果をＩＮＣＯＲＲＥＣＴと判定する。

表示処理部２０４は、検証部２０６が出力する検証結果を、表示Ｗｉｎｄｏｗ３００に表示し、アクション実行履歴ＨＩＳＴの内容を、反例情報として表示Ｗｉｎｄｏｗ３００に表示する。 反例情報は、図４に示すように、アクティビティ中の各制御ノードｎの各々に、ｎのアクション実行履歴を表示する。 図４の例において、アクション実行履歴が「ＣＰ５．ｏｐ５」と表示されている３つのノードで、アクション順序制約４０８が破壊されていることが分かる。 これらの、検証結果がＩＮＣＯＲＲＥＣＴとなった箇所を、強調表示しても良い。 以上を実現する、表示処理部２０４に関わる処理フローは述べないが、既存の技術を用いて、容易に実現することが出来る。

本実施形態では、アクティビティ図を対象として、複数のデータモデル間に跨るデータ整合性を自動で検証し、その検証結果と反例情報を、ＵＭＬ設計ツールに表示する。 従ってユーザは、ＵＭＬ設計ツール上に表示されるこれらの情報から、モデルの整合性を、誤りなく網羅的に確認することが出来る。

なお本実施形態では、アクティビティ図を用いて説明を行ったが、提案するアルゴリズムは、アクション記述に基づいており、アクティビティ図に限らず、アクションを用いて記述する状態遷移等の他のモデルにも、応用可能である。 各モデルの記法に合わせてアルゴリズムの表現に変更を加えることで、同様に各アルゴリズムを構成することが出来る。

（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。 即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。