JP2007179165A - Ｕｍｌ設計モデルから、確率的な性能評価モデルを導出するコンピュータ・プログラムおよび確率的な性能評価モデルを導出する方法 - Google Patents

Abstract

【課題】ＵＭＬ設計モデルを、確率的な性能評価モデルに変換するコンピュータ・プログラムを提供する。
【解決手段】該コンピュータ・プログラムは、呼び出しグラフを、２分木構造を持った構文木に変換する手段２２１と、プロトコル状態図をプロセス式に変換する手段２２２と、アクティビティ図を確率付プロセス式に変換する手段２２３と、前記プロトコル状態図のプロセス式と、前記アクティビティ図の確率付プロセス式を合成して、クラスの確率付プロセス式を求める手段と、前記構文木と、前記クラスの確率付プロセス式から、システム全体の確率付プロセス代数式２２４を求める手段を有する。
【選択図】図２

Description

本発明は、ＵＭＬ（Unified Modeling Language）で記述された処理フローの個々の処理ステップに、基本的な性能指標に関する注釈をつけた設計モデルを入力として用い、そこから定量的な性能評価のための数学的モデルを自動的に導出する装置、及び導出するプログラムに関する。

システムの定量的な性質を見積もり・検証するという目的のため、時間／確率付き・ペトリネット、 時間／確率付きプロセス代数などのいくつかの形式的な手法が確立されている。ペトリネットとプロセス代数は、いずれもソフトウェアのような制御フローを自然に表現できる形式的手法である。どちらも、処理時間に関する情報を付加した拡張が複数提案されている。これら拡張された記述を元に、マルコフ連鎖などの確率過程、あるいは時間付きオートマトンなどの数学的形式化を基礎とした解析手法が確立されており、システムの性能評価に適用可能なツールが開発されている。

以上のような形式的手法とは別に、“UML Profile for Schedulability, Performance and Time”（ＵＭＬ−ＳＰＴ) と呼ばれるＵＭＬ拡張仕様がＯＭＧ（Object Management Group）において標準化されている。これは、ＵＭＬ図に対して、処理時間や性能に関する注釈を記述するための仕様である。ＵＭＬ−ＳＰＴによる注釈を用いて、システム全体や特定の処理のステップについて、必用な処理時間の見積り・その他の性能指標に関して、ある程度形式的かつ統一的な記述を行うことによって、開発者間でこれらの情報に対する意志の疎通を促すことができる。

関連する既存の研究として、非特許文献１および２では、ＵＭＬのステート図およびアクティビティ図からプロセス代数に基づく性能評価モデルを自動導出している。ただし、これらの手法では、１枚の図から１つの評価モデルを導出する方法しか言及されておらず、複数の図の連携によって表現される挙動については考慮されていない。非特許文献３、４および５では、アクティビティ図、ステート図、ユースケース図等の間の連携を考慮した、ペトリネットへの変換手法が述べられている。この手法では、「アクティビティ図Ａがアクティビティ図Ｂを呼び出す」といった連携の関係を、ペトリネットのトポロジの結合として表現している。しかし、この手法では、呼び出される挙動の振る舞いが、呼び出し側の与えるパラメタに依存する関数呼び出し等のケースを表現できない。また、現実のシステム開発工程では、同等の振る舞いをする複数の構成要素を「クラスとインスタンス」の関係で表現することが一般的であるが、この手法ではそのような関係を表現できない。

特許文献１は、注釈付きＵＭＬモデルから性能評価モデルを自動導出する手法であるが、クラス図と一部シーケンス図しか考慮されていないので、性能評価モデルが、詳細化されていないという問題がある。また、このことは、ＵＭＬモデルの振る舞いが、求めた性能評価モデルの振る舞いと一致しない事態を招く恐れがあり、これを補正するために、エンジニアが、パラメータの付与等の作業をする必要がある。
特開２００１−３１８８１２号公報 S. Gilmore and L. Kloul. A unified approach to performance modeling and verification, May 2003. Paper presented at Dagstuhl seminar on "Probabilistic Methods in Verification and Planning". C. Canevet et al. Analysing UML 2.0 activity diagrams in the software performance engineering process. In Proc. 4th Intl. Workshop on Soft. and Perf., pages 74?78, 2004. Simona Bernardi et al. From UML sequence diagrams and statecharts to analysable petri net models. In Proc. 3rd Intl. Workshop on Software and Performance, pages 35?45, 2002. Juan Pablo L´opez-Grao et al. From UML activity diagrams to stochastic petri nets: application to software performance engineering. SIGSOFT Softw. Eng. Notes, 29(1), 2004. Jos´e Merseguer and Javier Campos. Exploring roles for the UML diagrams in software performance engineering. In Proc. 2003 Intl. Conf. on Software Engineering Research and Practice (SERP’03), pages 43?47, June 2003. InternalNote: Submitted by: jcampos@unizar.es.

専門的な知識を持たないエンジニアがＵＭＬに基づいて性能評価を行うためには、ＵＭＬモデルから性能評価モデルを自動導出する手法が必要となる。また、ＵＭＬを用いた現実の開発工程では、クラスを用いたコンポーネントベースのモデリングが一般的なため、そのような開発プロセスを考慮しなければならない。ＵＭＬによるモデリングとＵＭＬ−ＳＰＴ等による注釈を用いることが有用であると考えられる。しかし、ＵＭＬ−ＳＰＴの仕様では、注釈の記述箇所や書式は定められているものの、それらの厳密な意味については規定されておらず、付加した注釈から性能評価を得られるわけではない。

上記課題を解決するため、本発明においては、ＵＭＬ設計モデルを、確率的な性能評価モデルに変換するコンピュータ・プログラムを提供する。該コンピュータ・プログラムは、コンピュータを、呼び出しグラフを、２分木構造を持った構文木に変換する手段と、プロトコル状態図をプロセス式に変換する手段と、アクティビティ図を確率付プロセス式に変換する手段と、前記プロトコル状態図のプロセス式と、前記アクティビティ図の確率付プロセス式を合成して、クラスの確率付プロセス式を求める手段と、前記構文木と、前記クラスの確率付プロセス式から、システム全体の確率付プロセス代数式を求める手段として機能させる。該コンピュータ・プログラムにより、専門的な知識を持たないエンジニアでも、ＵＭＬモデルから性能評価モデルを容易に導出することができる。

以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせは、発明の内容を理解しやすくするためのものもあり、その全てが発明の解決手段に必須であるとは限らない。

以下の実施の形態では、主に方法またはシステムについて説明するが、当業者であれば明らかなとおり、本発明はコンピュータで使用可能なプログラムとしても実施できる。したがって、本発明は、ハードウェアとしての実施形態、ソフトウェアとしての実施形態またはソフトウェアとハードウェアとの組合せの実施形態をとることができる。プログラムは、ハードディスク、ＣＤ−ＲＯＭ、光記憶装置または磁気記憶装置等の任意のコンピュータ可読媒体に記録できる。

図１は、ＵＭＬ設計モデルから、確率的な性能評価モデルを導出するシステムが作動するハードウェア構成１００の概略を示している。中央演算処理装置であるＣＰＵ１０１は各種オペレーティング・システムの制御下で様々なプログラムを実行する。ＣＰＵ１０１はバス１０２を介して、メモリ１０３、ディスク１０４、ディスプレイ・アダプタ１０５、ユーザ・インタフェース１０６およびネットワーク・インタフェース１０７と相互接続される。なお、ネットワーク・インタフェース１０７は必須の構成要素ではないが、本発明が分散環境を実施される場合に必要となる。ディスク１０４には、本発明を実現するためのシステムとしてコンピュータを機能させるためのソフトウェア、オペレーティング・システムおよび本発明を実行するためのプログラム等が含まれる。

ユーザ・インタフェース１０６を通して、キーボード１０９およびマウス１１０に接続され、ディスプレイ・アダプタ１０５を通してディスプレイ装置１０８に接続され、ネットワーク・インタフェース１０７を通してネットワーク１１１に接続される。このハード構成１００は、コンピュータ・システム、バス配置およびネットワーク接続の一実施形態の例にすぎず、本発明の特徴は、さまざまなシステム構成で、同一の構成要素を複数有する形態で、または、ネットワーク上にさらに分散された形態でも実現することができる。

図２は、ＵＭＬ設計モデルから、確率的な性能評価モデルを導出するシステムの機能およびデータを概念的に表したものである。２０１はＵＭＬモデルを入力するツールである。ディスク２１０には、ＵＭＬ−ＳＰＴモデルが登録されている。ディスク２１０のＵＭＬ−ＳＰＴモデルの内容は、ＵＭＬ設計図２１１と、性能指標注釈２１２などである。２２０はＵＭＬモデルを確率付きプロセス代数に変換するＵＭＬモデル変換器である。ＵＭＬモデル変換器２２０は、呼び出しグラフ変換器２２１、プロトコル状態変換器２２２、およびアクティビティ図変換器２２３を含む。呼び出しグラフ変換器２２１は、クラスの呼び出しグラフから、２分木構造を持った構文木に変換し、プロセス式表現を求める。プロトコル状態変換器２２２は、プロトコル状態図から、プロセス代数を作成する。アクティビティ図変換器２２３は、メソッドの具体的な振る舞いを記述するＵＭＬ２．０のアクティビティ図から、プロセス式を作成する。最後に、プロトコル状態図から得られたプロセス式と、アクティビティ図から得られたプロセス式を合成し、さらに、２分木構造を持った構文木と合成して、システム全体の確率付きプロセス代数式２２４を求める。その後、プロセス代数式２２４は、プロセス代数表現から、確率モデル変換によって、連続マルコフ鎖のモデルに変換したり、その他の変換機構によって、システムの性能評価が行われる（２３０）。

図3は、ＵＭＬ設計モデルから、確率的な性能評価モデルを導出する処理フロー３００を例示したものである。ステップ３０１で処理を開始する。ステップ３０２では、ＵＭＬモデルが読み込まれる。このＵＭＬモデルは、ＵＭＬ−ＳＰＴモデルであり、ＵＭＬ設計図や性能指標注釈などが含まれる。ステップ３０３では、呼び出しグラフが作成される。なお、ＵＭＬ２．０の仕様で定義されているアクティビティ図の構成要素には、他のクラスのメソッド呼び出しを表す「操作呼び出しアクション」が含まれているので、クラスの呼び出しグラフは、この「操作呼び出しアクション」に基づいて、クラス間の連携関係を抽出して作成することが可能である。次にステップ３０４では、呼び出しグラフを、２分木構造を持った構文木に変換する。ステップ３０５では、プロトコル状態図をプロセス式に変換する。ステップ３０６では、アクティビティ図を確率付プロセス式に変換する。ステップ３０７では、ステップ３０５で求めたプロトコル状態図のプロセス式と、ステップ３０６で求めたアクティビティ図の確率付プロセス式を合成して、クラスの確率付プロセス式を求める。ステップ３０８では、ステップ３０４で求めた構文木と、ステップ３０７で合成したクラスの確率付きプロセスから、システム全体の確率付プロセス代数式を求める。ステップ３０９で処理を終了する。

図４は、図２の構成を用いて、プロセス式を導出する対象となるシステム４００を例示する。図４では、４０１がスキャナ（Scanner）、４０２がバッファ（Buffer）、および４０３がプリンタ（Printer）からなるシステム４００が表されている。なお、図４のシステム４００は、本発明が適用される一例であって、本発明の適用範囲が、これに限定されるものではない。システム４００では、スキャナ４０１で読み取った原稿のデータをバッファ４０２に保存し、プリンタ４０３がバッファ４０２のデータを取り出して印刷する。スキャナ４０１とプリンタ４０３は、それぞれ独立に動作するので、システム４００は、並列に動作するシステムである。また、バッファ４０２は、ここでは、原稿３ページ分のデータを保持できるものとする。

図５から図７は、図４のシステム４００の構造と振る舞いを示したＵＭＬモデルの例である。図５のＵＭＬモデルはスキャナ５０１、バッファ５０２、およびプリンタ５０３という３つのコンポーネント（クラス）を定義しており、スキャナ５０１はputPageメソッド５０４というインタフェースによってバッファ５０２と結合され、プリンタ５０３はgetPageメソッド５０５というインタフェースによってバッファ５０２と結合されている。また、スキャナ５０１はstartScanメソッドを持ち、プリンタ５０３はstartPrintメソッドを持っている。

図６は、各コンポーネントのプロトコル状態図を示したものである。プロトコル状態図は、状態遷移のラベルとしてメソッド名を持つ状態遷移図である。例えば、プロトコル状態図の状態Ｓ1からＳ2への遷移があり、その遷移にラベルｆが付いているということは、メソッドｆの呼び出しによってクラスの状態がＳ1からＳ2 へと変化することを意味する。スキャナのプロトコル状態図（図６（ａ））では、startScanメソッドの呼び出しを任意の回数受け付けることを示している。同様に、プリンタのプロトコル状態図（図６（ｃ））では、startPrintメソッドの呼び出しを任意の回数受け付けることを示している。

一方、バッファのプロトコル状態図（図６（ｂ））は、初期状態に加えＳ0、Ｓ1、Ｓ2、およびＳ3の４つの状態を持っている。状態Ｓi はバッファにi個のデータが保持されている状態を表す。バッファの状態はputPageメソッドが呼び出されることによってＳi からＳi+1 に遷移し、getPageメソッドによってＳiからＳi-1に遷移する。状態Ｓ0はバッファが空であることを表す状態なので、この状態ではgetPageメソッドの呼び出しを受け付けることができない。状態Ｓ0でプリンタがgetPageメソッドを呼び出したとすると、この呼び出しは、状態がＳ1以上に遷移するまで待たされる。同様にＳ3はバッファのデータが一杯になった状態なので、Ｓ3ではputPageメソッドを受け付けることができない。

図７は、各メソッドを定義するアクティビティ図である。図７（ａ）では、スキャナのstartScanメソッドは、scanPageアクションと、バッファのputPage メソッドを呼ぶアクションの２つを繰り返すループとなっている。ここで、scanPageアクションには、このアクションの実行に要する時間がＵＭＬ−ＳＰＴの記法(ＵＭＬ−ＳＰＴで定義されたステレオタイプ《Pastep》) で注釈されている。この注釈は、scanPageアクションの実行には平均でｔ1 秒の時間を要すること、および実行時間のばらつきは指数分布(exponential) に従うことを表している。図７（ｃ）では、プリンタのprintPageも同様に、getPageメソッドの呼び出しとprintPageアクションの２つの繰り返しがアクティビティ図として表現されており、printPageアクションの実行に平均でｔ2秒の時間を要することが注釈されている。図７（ｂ）では、バッファにおいて、putPage メソッドは、enqueueアクションが平均ｔ3秒かかる。getPageメソッドは、putPageメソッドとほぼ同等のものなので、ここでは説明を省略している。

ここからは、具体的なプロセス代数を導出する方法を説明する。ＵＭＬ２．０の仕様で定義されているアクティビティ図の構成要素には、他のクラスのメソッド呼び出しを表現する「操作呼び出しアクション」が含まれている。本発明では、入力ＵＭＬモデルに含まれる操作呼び出しアクションに基づいて、クラス間の連携関係を抽出し、それを確率付きプロセス代数のプロセス間通信を表す式に変換する。クラス間の連携関係は、ＵＭＬモデルに含まれる各クラスごとに、そのクラスに属するアクティビティ図 が持つ「操作呼び出しアクション」を列挙し、呼び出されるクラスが何であるかを見ることによって、クラス間の「呼ぶ、呼ばれる」という関係を呼び出しグラフ (static call graph) として表現することで抽出する。なお、Ｃ言語のソース・プログラムから static call graph を抽出するツールがあるが、これと同等のことを ＵＭＬに応用して、クラス間の連携関係を、抽出できる。

本発明で用いるプロセス代数の定義を表１に示す。なお、Ｐ｜_L Ｑ はＰとＱという２つのプロセスが並列に動作しながらL に現れるアクションで同期を取る、という動作を表し、クラス間の連携を表現するための構文要素である。

本発明で用いるプロセス代数において、プロセス間の通信は２分木構造を持った構文木として表現され、個々の通信はアクションの名前に基づいて行われる。一方、ＵＭＬモデルでの操作呼び出しアクションに基づく連携は一般にはグラフ構造の形をとり、また、同名のメソッドが異なった引数で呼び出される場合がありうる。このため、モデルから抽出された呼び出しグラフからプロセス式への変換は、（ｉ）各メソッドの呼び出しに対して異なったアクション名を割り当てる、（ｉｉ）グラフ構造を２分木構造に変換する、という操作が最初の手順となる。

図８は、呼び出しグラフからプロセス式に変換する過程を理解するための例を示す。図８（ａ）には、Ｃ1、Ｃ2、Ｃ3、Ｃ4、およびＣ5という５つのクラスとｆ1、ｆ2、ｆ3、ｆ4、およびｆ5という５つのメソッドからなる呼び出しグラフである。また、メソッドｆ3 はＣ2とＣ3からそれぞれ異なる引数で呼び出されている。このグラフの中で、クラスＣ1は他のどのクラスからも呼び出されていない。以下、呼び出しグラフのこのような節を、グラフの「根」と呼ぶこととする。また、クラスＣ5は他のどのクラスのメソッドも呼び出していない。以下、このような節をグラフの「葉」と呼ぶこととする。一般に呼び出しグラフの根と葉はそれぞれ複数存在してもよい。

図9は、呼び出しグラフからプロセス式に変換する過程の例を示す処理フロー９００である。処理フロー９００はステップ９０１で処理を開始する。ステップ９０２では、グラフの各根から葉に至る、全てのパスを列挙する。ステップ９０３では、ステップ９０２で列挙されたパスの各枝に対し、一意な識別番号である「メソッド呼び出し番号」を割り当てる。このとき、メソッド呼び出し番号とメソッド呼び出し階層の対応関係を保持しておく（図８（ｂ））。これまでの処理により、元の呼び出しグラフにおけるメソッドの引数や呼び出しパスの差異を反映して、同一のメソッドに対して複数個の番号が割り当てられる。すなわち、このプロセス式に変換する過程では、メソッドの引数や呼び出しパスの差異を区別する。例えば図８（ｃ）のグラフ構造と図８（ｂ）の対応関係を見ると、メソッドｆ3の２つの呼び出しに対して２と５、メソッドｆ5の２つの呼び出しパスに対して３と６という番号が割り当てられている。ステップ９０４で、上記の手順で得られたグラフを、プロセス式に対応する２分木に変換する。この２分木は、葉要素がＮ1｜_φ・・・｜_φＲkというプロセスの並列結合を持ち、葉以外の節が、各メソッド呼び出し番号ｉについてｉ、ｉ_endという２つの名前を持った集合をデータとする２分木となる。ここで、iはメソッド呼出し番号iに対応するメソッドの開始を表すアクション名、ｉ_endは同メソッドの終了を表すアクション名である。この２分木はクラス間の並列結合を
表すプロセス式の構文木と１対１に対応するので、ステップ９０５で、２文木を、プロセス式に変換する（図９（ｄ））。

図１０は、図８および図９と同様の処理を、図４のシステム４００に適用した例である。図１０（ａ）は、スキャナ、バッファ、およびプリンタという３つのクラスと、putPageとgetPageの２つのメソッドからなる呼び出しグラフである。図１０（ｂ）では、スキナからバッファへのputPage メソッドの呼び出しに対しメソッド呼出し番号１ を、プリンタからバッファへのgetPageの呼び出しに対しメソッド呼出し番号２を、それぞれ割り当てている。図１０（ｃ）では、図１０（ａ）のメソッド名を、対応するメソッド呼び出し番号で置き換えている。図１０（ｃ）を二分木表現に変換したものが図１０（ｄ）であり、次のプロセス式表現が得られる。
Buffer｜_{｛１,２,１end,２end｝} (Scanner｜_φ Printer)

クラスのプロセス式への変換は、次の手順に基づいて行う。（１）各クラスの振る舞いを定義するプロトコル状態図を、プロセス式に変換する。（２）クラスが持つ各メソッドの振る舞いを定義するアクティビティ図を、プロセス式に変換する。（３）前記（１）および（２）の結果を合成することによって、各クラスの振る舞いを表現するプロセス式を得る。

プロトコル状態図からプロセス式への変換について図１１で説明する。プロトコル状態図は、状態遷移のラベルとしてメソッド名を持つ状態遷移図である。プロトコル状態図の状態Ｓ1からＳ2への遷移があり、その遷移にラベルｆが付いているということは、メソッドｆの呼び出しによってクラスの状態がＳ1からＳ2へと変化することを意味する。このようにして、プロトコル状態図であるクラスが受け付けることのできるメソッド呼び出しの種類や順序などを表現することができる。例えば図１１（ａ）は、図８のクラスＣ4 のプロトコル状態図であり、Ｃ4はメソッドｆ3の呼び出しを任意の回数受け付けることを表している。より複雑な例として、図１１（ｂ）は「ファイル」を表すクラスのプロトコル状態図である。「ファイル」は最初にメソッドopenを受け付け、メソッドreadまたはwriteを任意回数受け付けた後close を受け付けて、再びopenを受け付けることのできる初期状態に戻ることが表現されている。プロトコル状態図からプロセス式への変換は、最初に状態図の遷移ラベルであるメソッド名をメソッド呼び出し番号に置き換えることから始める。例えば、図８（ｂ）よりメソッドｆ3に対応するメソッド呼び出し番号は２と５なので、図１１（ａ）のＣ4の状態図は図１２に変換される。

このように変換されたプロトコル状態図を、図１３の処理フロー１３００に沿って、グラフの深さ優先探索によってプロセス式に変換する。処理フロー１３００は、ステップ１３０１で処理を開始する。ステップ１３０２で、プロトコル状態図の初期状態から探索を開始する。ステップ１３０３で、訪れた状態図の状態をＳとして、状態Ｓがループを形成する状態、すなわち、状態Ｓから遷移する途中に再び状態Ｓとなるような状態遷移列が存在し、かつ過去一度でも状態Ｓを訪れたことがあるか判定する。ステップ１３０３で、状態Ｓがループを形成すると判断された場合（ＹＥＳ）、ステップ１３０４で、Ｓを変数ＸSに変換する。一方、ステップ１３０３で、状態Ｓがループを形成しないと判断された場合（ＮＯ）、ステップ１３０５に進む。ステップ１３０５では、Ｓから出ている遷移先の状態をＳ1、Ｓ2、・・、Ｓkとし、メソッド呼出し番号である遷移のラベルをｎ₁、ｎ₂、・・、ｎ_k（ｎ_iは整数）として、最初に各遷移先の状態Ｓiを変換し、換結果のプロセス式をＱiとする。ステップ１１０６で、各ラベルｎ_iを、アクションの列ｎ’_ｉ・ ｎ_ｉstart ・ ｎ’_ｉwait ・ ｎ_ｉendに変換する。ステップ１３０７で、変換されたアクション列をＱiの先頭に付加し、プロセス式Ｐ_ｉ≡ｎ’_ｉ ・ ｎ_ｉstart ・ ｎ’_ｉwait ・ ｎ_ｉend ・Ｑ_ｉを得る。
なお、ｎ_ｉはメッセージの送出、ｎ’_ｉはメッセージの受け取りを表す。ステップ１３０８で、全てのＰi（i = 1、2、・・、k) を＋で結合し、プロセス式Ｐ_S≡Ｐ1＋Ｐ2＋・・＋Ｐkを得る。ステップ１３０８で、もしＳがループを形成する状態なら、Ｐ_Sに現れる変数Ｘ_Ｓをμ演算子で束縛し、μＸ・Ｐ_Ｓを変換結果とする。そうでなければ、Ｐ_Ｓを変換結果とする。ステップ１３０９で処理を終了する。

図１３の処理フローから、例えば、図１２の状態図からは、次のようなプロセス式が得られる。μＸ_Ｓ1・2’・2_start・2’_wait・2_end・Ｘ_Ｓ1＋5’・5_start・5’_wait・5_end・Ｘ_Ｓ1

次に、図１３の処理フローに従い、図６（ｂ）におけるバッファのプロトコル状態図の変換例を示す。図１４は、図５にあるバッファ・コンポーネントのプロトコル状態図を元に、遷移のラベルを対応するメソッド呼出し番号（putPage = 1、getPage = 2）で置き換えて得られた状態図である。いま、状態ｓからプロセス式への変換を[[ｓ]]と書くことにすると、この状態図の変換は次のようになる。
初期状態からｓ0への遷移にはラベルが付かないため、初期状態の変換結果はＳ0の変換結果に等しいので、[[●]]＝[[Ｓ0]]となる。
Ｓ0はまだ一度も訪れていない状態であり、Ｓ0はループを形成する状態なので、[[Ｓ1]]に現れる変数Ｘ_Ｓ0 は、μＸ_Ｓ0で束縛される。従って、[[Ｓ0]]＝μＸ_Ｓ0・1’・１_start・１’_wait・１_end[[Ｓ0]]となる。Ｓ1からＳ2への遷移に対応する式は、[[Ｓ0]]の変換と同様となる。Ｓ1からＳ2への遷移に対応する式は、Ｓ0は既に訪れた状態なので、変数Ｘ_Ｓ0に変換される。従って、[[Ｓ1]]＝μＸ_Ｓ1 (1’ ・1_start・1’_wait・1_end・ [[Ｓ2]]+2’ ・2_start・・2’_wait・2_end・Ｘ_Ｓ0)となる。[[Ｓ2]]は[[Ｓ1]]と同様なので、 [[Ｓ2]]＝μＸ_Ｓ2 (1’・1_start・1’_wait・1_end・ [[Ｓ3]]+2’・2_start・2’_wait・2_end・Ｘ_Ｓ1)となる。
[[Ｓ3]]は、Ｓ3からＳ2への遷移に対応する式である。Ｓ3はループを形成する状態であるが、[[Ｓ3]]の結果には、変数Ｘ_Ｓ3は現われないため、μＸ_Ｓ3による束縛は行われない。従って、 [[Ｓ3]]＝2’・2_start・2’_wait・2_end・Ｘ_Ｓ2となる。

以上の等式を全て展開すると、図１４の状態図を変換した結果のプロセス式として、次の式が得られる。
Buffer_PSM ≡μＸ_Ｓ0・1’・1_start・1’_wait・1_end・μＸ_Ｓ1・(1’・1_start・1’_wait・1_end・μＸ_Ｓ2・(1’・1_start・1’_wait・1_end・2’・2_start・2’_wait・2_end・Ｘ_Ｓ2＋2’・2_start・2’_wait・2_end・Ｘ_Ｓ1)+2’・2_start・2’_wait・2_end・Ｘ_Ｓ0)

次に、アクティビティ図からプロセス式への変換について説明する。メソッドの具体的な振る舞いを記述する表現としてＵＭＬ２．０のアクティビティ図を用いる。そのため、一つの「メソッド呼出し番号」に対して一つの対応するアクティビティ図が存在する。ＵＭＬ２．０のアクティビティ図は、アクティビティ・ノードとアクティビティ・エッジからなる有向グラフとして定義されている。アクティビティ・ノードはＵＭＬ２．０の仕様では数十種類が定義されているが、ここでは、性能評価に直接関わる「基本アクションノード」「メソッド呼び出しノード」「分岐・マージノード」「フォーク・ジョインノード」「アクティビティ開始・終了ノード」のみを扱う。また、各基本アクションには、アクションの実行に要する時間がＵＭＬ−ＳＰＴ等の記法で注釈されている。

アクティビティ図をプロセス代数の構文木に変換するため、次の手順をとる。
（１）アクティビティ図に前処理を施し、以下の制約を満たす図に変換する。（ｉ）アクティビティ図の「アクティビティ開始ノード」は唯一つである。（ii）各「基本アクションノード」「メソッド呼び出しノード」は唯一の入力エッジと出力エッジを持つ。（iii）各「分岐ノード」と「フォークノード」は２つの出力エッジを持つ。
（２）（１）で得られたアクティビティ図の構造を、表２で定義される構文（規則）に従って構文木による表現に変換する。

（３）（２）で得られた木表現をプロセス式に変換する。

ＵＭＬ２．０の仕様では、アクティビティ図が複数の「アクティビティ開始ノード」を持つ場合はそれぞれの開始ノードから並列に処理が開始される。アクションノードに複数の入力エッジがある場合は、「ジョインノード」と同様に扱われる。そして、アクションノードから複数の出力エッジが出ている場合は「フォークノード」と同様に扱われるものとして定義されている。また、３つ以上の出力がある分岐・フォークは出力が２つの分岐・フォークを多段に設けることによって表現できる。上記（１）の処理は、この定義に従って適当な箇所に分岐・フォーク・ジョインノードを挿入するものである。

上記（２）で得られたアクティビティ図の木表現からプロセス式の変換は、図１５の処理フロー１５００で実行される。処理フロー１５００は、ステップ１５０１で、処理を開始する。ステップ１２０２で、アクティビティ開始ノードから探索を開始する。ステップ１５０３で、訪れたノードに対して、一意な識別子を割り当てる。この識別子をlと表記する。ステップ１５０４で、訪れたノードの種類によって、次の場合分けを行い、割り当てられた識別子lを付加して変換する。
「アクティビティ終了ノードノード」の場合、Final_l に変換する。
「アクティビティ開始ノードノード」の場合はinit_l に変換し、後続の変換結果をA としてinitl_l→A に変換する。
「基本アクションノード」の場合は、注釈として付加された時間がt であるとした時、ノードを(a,1/t)_l に変換し、後続の変換結果をA として(a,1/t )_l → A に変換する。「メソッド呼び出しノード」の場合は、呼び出されるメソッドがf であり、その「メソッド呼び出し番号」がn であるとした時、ノードをcall(n)_lに変換し、後続の変換結果をA としてcall(n)_l → A に変換する。「分岐ノード」の場合は、後続する２つの分岐の変換結果をA1、A2 としてDecision(A1、A2)_lに変換する。「フォークノード」の場合は、後続する２つの並列実行の変換結果をA1、A2 としてFor
k(A1,A2)_l に変換する。「ジョインノード」の場合は、このノードを最初に訪れた場合、ノードをjoin_l に変換し、後続の変換結果をA としてjoin_l→A に変換する。既に訪れたことのあるノードの場合、ノードをJoin_l に変換する。
「マージノード」の場合は、このノードを最初に訪れた場合、ノードをmerge_l に変換し、後続の変換結果をA としてmerge_l→A に変換する。既に訪れたことのあるノードの場合、そのノードがループを形成するノードであれば、BwdMerge_l に変換する。そうでない場合はFwdMerge_l に変換する。
ステップ１５０５で、変換してないノードがあるか判定する。ステップ１５０５で、変換してないノードがあると判断された場合は（ＹＥＳ）、ステップ１５０２に戻り、変換処理を続ける。ステップ１５０５で、変換してないノードがないと判断された場合は（ＮＯ）、ステップ１５０６に進んで、処理を終了する。

なお、上記（３）の木表現からプロセス式への変換は、表３の定義に従って行われる。表３中、merge_l→Aの規則では、変換の結果を、ラベルlをキーとしてΠ（というメモリに記憶しておく。

全ての変換が終了した時点で、FwdMerge_lは、Πに記憶された対応するプロセス式Π(l)で置き換えられる。Fork(A1、A2)_l の規則に現れる次の等式は、プロセスの並列結合を構築する演算子である。

図７に記載されたシステムについてのバッファのputPageメソッドのアクティビティ図を次のように変換する。
init_l1→(enqueue、1/t3)_l2 → Final_l3
ここで、(enqueue、1/t3)_l2 は、enqueueメソッドのアクションの実行に平均t3秒かかるという注釈を反映している。このように表現されたアクティビティ図は、表３の規則に従って、次のプロセス式に変換されるPputPage≡［init_l1→ (enqueue, 1/t3 )_l2→Final_l3］
= ［（enqueue、 1/t3 )_l2 → Final_l3）
= (1/t3)・［Final_l3］ = (1/t3 )・end・stop
また、Scanner コンポーネントのstartScanメソッドのアクティビティ図は、次の木表現に変換される。
init_l4→merge_l5 → (scanPage、1/t1)_l6 → call(1)_l7 → Merge_l5 (scanPage、1/t1 )_l6 は、scanPageメソッドのアクションの実行に平均t1 秒かかるという注釈を反映している。また、call(1)_l7 は、putPage を呼び出すアクションに対応している。カッコ内の数字1 はScanner からputPage の呼び出しに対応するメソッド呼び出し番号である。ループの起点となるマージノードは、merge_l5とMerge_l5の２つの要素に変換され、これらはいずれも同じラベルl5 を持つことで、元のアクティビティ図で同一のノードであったことが示されている。この木表現から、プロセス式は次のように変換される。
P_startScan≡［init_l4→merge_l5→(scanPage、1/t1 )_l6 → call(1)_l7 → Merge_l5］
= ［merge_l5 → (scanPage; 1/t1 )_l6 → call(1)_l7 → Merge_l5］
= μＸ_l5［(scanPage; 1/t1 )_l6 → call(1)_l7 → Merge_l5］
= μＸ_l5・(1/t1 )・［call(1)_l7 → Merge_l5］
= μＸ_l5・( 1/t1 )・1_begin・1’_end・［Merge_l5］
= μＸ_l5・( 1/t1 )・1_begin・1’_end・Ｘ_l5
同様に、Printer のstartPrintメソッドからは、次のプロセス式が得られる。
PstartPrint ≡ μＸ_l6・2_begin・2’_end・(1/t2)・Ｘ_l6

次に、プロトコル状態図とアクティビティ図の合成について説明する。クラスからプロセス式への変換の最後の過程として、プロトコル状態図から得られたプロセス式と、各アクティビティ図から得られたプロセス式を合成する。この合成は次のように実現される。今、あるアクティビティ図Ａに対応するメソッド呼び出し番号がｎ_Aであり、Ａを変換した結果のプロセス式がＰ_Aであるとする。この時、メソッド呼び出し番号_Aにより、Ｐ_A と関連付け、次のように変換する。（１）Ｐ_Aに現れるend・stopを、プロセスｎ_Ａwait・Ｘn_Aで置き換え、結果をP’_Aとする。（２）
上記P’A の先頭にμXn_A・n’_Ａstartを付加し、P”_A≡μXn_A・n_Ａstart・P’_Aとする。各アクティビティ図に対応するプロセス式を上記のように変換した後、次のようなプロセスの並列結合によって、クラス全体の振る舞いを表すプロセス式を得る
C≡Ｐ_PMS｜｛n_１start,n_１wait,・・・，n_ｋstart,n_ｋwait｝(Ｐ”_A1｜_φ Ｐ”_A2｜_φ・・・｜_φ Ｐ”_{Ａ k})
ここで、Ｐ_PSM はプロトコル状態図を変換した結果のプロセス式、ｎ₁,・・・,ｎ_kはメソッド呼び出し番号であり、各Ｐ_Aiはメソッド呼び出し番号i に対応するアクティビティ図の変換結果である。

図４のシステムのバッファの変換例として、バッファのコンポーネントの振る舞いを表すプロセス式は、次のように得られる。最初に、putPageメソッドのアクティビティ図から得られたプロセス式Ｐ_putPage を以下のように変換し、最終的にＰ”_putPage を得る。まず、Ｐ_putPage ≡ ( 1/t3 )・end・stopである。ここでend・stopを1_wait・X₁で置き換える。そうするとP’ _putPage ≡ ( 1/t3 )・1_wait・X₁となる。つぎに、先頭にμX₁・1’_startを付加すると、Ｐ” _putPage ≡μX₁・1’_start・( 1/t3 )・1_wait・X₁となる。また、getPageメソッドからも同様なプロセス式Ｐ”_getPageが得られたとする。これと、Bufferのプロトコル状態図から得られたプロセス式Buffer_PSM≡μX_Ｓ0・1’・1_start・1’ _wait・1_end・μX_Ｓ1・(1’・1_start・1’ _wait・1_end・μX_Ｓ2・(1’・1_start・1’_wait・1_end・2’・2_start・2’_wait・2_end・X_Ｓ2 + 2’・2_start・2’_wait・2_end・X_Ｓ1 )+ 2’・2_start・2’_wait・2_end・X_Ｓ0 )を、以下のように結合することで、バッファのプロセス式を得る。
Buffer ≡ Buffer_PSM｜_{｛１start,１wait,２start,２wait｝} (P”_putPage｜_φ P”_getPage)

このプロセスの動作は次のようになる。最初に、バッファを使用するプロセスが、バッファのメソッド呼び出しに対応するアクションを実行する。例えば、今スキャナのプロセスがアクション「1」を実行したとする。このアクションと、Buffer_PSMの1’ アクションの間で同期がとられ、Buffer_PSM は、1’に続くアクションである1_start を実行する。1_start は、P”_putPageの1’startと同期するため、P”_putPageはそれに続く時間付きアクション( 1/t3 )を実行する。その後、P”_putPage の1_wait アクションとBuffer_PSM の1’_wait アクションが同期しBuffer_PSM は1_end によってScanner に実行完了を通知する。それと同時に、P”_putPage は再び1’_start による同期を待つ状態に戻る。

システム全体のプロセス代数は、上記バッファと同様にスキャナとプリンタのプロセス式を求め、図１０（ｄ）の式 Buffer｜_{｛１,２,１end,２end｝} (Scanner｜_φ Printer)に代入して求めることができる。

本発明を用いることによって、ペトリネットやプロセス代数などの性能評価に関する理論の専門知識を持たない性能開発者が、UML による設計記述を元に性能評価を行うことが可能になる。これによって、システム開発者がシステムの設計段階で性能に関する評価を手軽に実施することができる。また、本発明においてシステム開発者が記述するものはUML 設計図と性能注釈のみである。このため、性能評価のためだけに用いる特殊な設計モデルを用意する必要がなくなるため、一般的なシステムの開発プロセスに性能評価を自然に導入することが可能になる。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

ＵＭＬ設計モデルから、確率的な性能評価モデルを導出するシステムが作動するハードウェア構成１００の概略を示している。 ＵＭＬ設計モデルから、確率的な性能評価モデルを導出するシステムの機能およびデータ ＵＭＬ設計モデルから、確率的な性能評価モデルを導出する処理フロー３００を例示しものである。 プロセス式を導出する対象となるシステム４００を例示する。 システム４００のＵＭＬモデルの一例 図６は、各コンポーネントのプロトコル状態図を 各メソッドを定義するアクティビティ図 呼び出しグラフからプロセス式に変換する過程の例 呼び出しグラフからプロセス式に変換する過程の例 システム４００について、呼び出しグラフからプロセス式に変換する過程の例 プロトコル状態図の例 プロトコル状態図を変換した例 プロトコル状態図を、プロセス式に変換する処理フローの一例 バッファ・コンポーネントのプロトコル状態図を置き換えた一例 アクティビティ図の木表現からプロセス式の変換処理の一例

Claims (15)

1. コンピュータに、クラスのプロトコル状態図およびアクティビティ図を含むＵＭＬ設モデルを、確率的な性能評価モデルに変換させるコンピュータ・プログラムであって、
   前記コンピュータを
   呼び出しグラフを、２分木構造を持った構文木に変換する手段と、
   プロトコル状態図をプロセス式に変換する手段と、
   アクティビティ図を確率付プロセス式に変換する手段と、
   前記プロトコル状態図のプロセス式と、前記アクティビティ図の確率付プロセス式を成して、クラスの確率付プロセス式を求める手段と、
   前記構文木と、前記クラスの確率付プロセス式から、システム全体の確率付プロセス数式を求める手段と
   して機能させるためのコンピュータ・プログラム。
2. 前記呼び出しグラフは、アクティビティ図からクラス間の呼び出しにもとづいたグラである、請求項１に記載のコンピュータ・プログラム。
3. 前記呼び出しグラフを作成する手段は、同一メソッドに対し、メソッド呼び出しの引の違いで、メソッド呼び出しを区別することを特徴とする、請求項２に記載のコンピュタ・プログラム。
4. 前記呼び出しグラフを作成する手段は、同一メソッドに対し、呼び出しパスの違いでメソッド呼び出しを区別することを特徴とする、請求項２に記載のコンピュータ・プロラム。
5. 前記プロトコル状態図を変換する手段は、遷移先の状態をＳ1、Ｓ2、・・、Ｓkとし、メソッド呼出し番号である遷移のラベルをｎ1、ｎ2、・・、ｎkとして、最初に各遷移先の状態を変換することを特徴とする請求項１に記載のコンピュータ・プログラム。
6. 前記アクティビティ図を変換する手段は、アクティビティ開始ノードから探索を開始し、訪れたノードに対して、一意な識別子を割り当てることを特徴とする請求項１に記載のコンピュータ・プログラム。
7. 前記クラスの確率付プロセス式を求める手段は、メソッド呼出し番号により、アクティビティ図の確率付プロセス式を関連付けることを特徴とする請求項１に記載のコンピュータ・プログラム。
8. 請求項１乃至７に記載のいずれかに記載のコンピュータ・プログラムを記録した、コンピュータ読み取り可能な記録媒体。
9. クラスのプロトコル状態図およびアクティビティ図を含むＵＭＬ設計モデルを、確率的な性能評価モデルに変換する方法であって、
   呼び出しグラフを、２分木構造を持った構文木に変換するステップと、
   プロトコル状態図をプロセス式に変換するステップと、
   アクティビティ図を確率付プロセス式に変換するステップと、
   前記プロトコル状態図のプロセス式と、前記アクティビティ図の確率付プロセス式を合成して、クラスの確率付プロセス式を求めるステップと、
   前記構文木と、前記クラスの確率付プロセス式から、システム全体の確率付プロセス代数式を求めるステップと
   を有する方法。
10. 前記呼び出しグラフは、アクティビティ図からクラス間の呼び出しにもとづいたグラである、請求項１に記載の方法。
11. 前記呼び出しグラフを作成するステップは、同一メソッドに対し、メソッド呼び出し引数の違いで、メソッド呼び出しを区別することを特徴とする、請求項２に記載の方法。
12. 前記呼び出しグラフを作成するステップは、同一メソッドに対し、呼び出しパスの違で、メソッド呼び出しを区別することを特徴とする、請求項２に記載の方法。
13. 前記プロトコル状態図を変換するステップは、遷移先の状態をＳ1、Ｓ2、・・、Ｓkとし、メソッド呼出し番号である遷移のラベルをｎ1、ｎ2、・・、ｎkとして、最初に各遷移先状態を変換することを特徴とする請求項１に記載の方法。
14. 前記アクティビティ図を変換するステップは、アクティビティ開始ノードから探索を始し、訪れたノードに対して、一意な識別子を割り当てることを特徴とする請求項１に載の方法。
15. 前記クラスの確率付プロセス式を求めるステップは、メソッド呼出し番号により、アクティビティ図の確率付プロセス式を関連付けることを特徴とする請求項１に記載の方法。

Images