JP2001318812A

JP2001318812A - 性能評価モデル生成装置および性能評価モデル生成方法

Info

Publication number: JP2001318812A
Application number: JP2000138391A
Authority: JP
Inventors: Toshihiko Nakamura; 寿彦中村
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2000-05-11
Filing date: 2000-05-11
Publication date: 2001-11-16
Also published as: US20020022942A1

Abstract

(57)【要約】【課題】ＵＭＬモデルから性能評価モデルを自動的に生
成できるようにし、性能評価モデルの作成にかかる時間
およびコストを削減する。【解決手段】利用者は変換規則編集部３を使用して変換
規則を入力し、変換規則格納部４に格納する。ＵＭＬモ
デル解析部１はＵＭＬモデル５を入力して解析し、変換
処理部２はＵＭＬモデル解析部１による解析結果を変換
規則格納部４の変換規則に従って変換して性能評価モデ
ル６を生成する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は性能評価モデル生成
装置および性能評価モデル生成方法に関し、特にＵＭＬ
（ＵｎｉｆｉｅｄＭｏｄｅｌｉｎｇＬａｎｇｕａｇ
ｅ）モデルから性能評価モデルを生成する性能評価モデ
ル生成装置および性能評価モデル生成方法に関する。

【０００２】

【従来の技術】製品サイクルの短期化のため、サービス
分析から実現までの時間的短縮が望まれている。また、
組み込み機器分野においては、情報端末の普及によっ
て、より多機能かつ高機能なシステムが求められ、ま
た、システムＬＳＩ（ＬａｒｇｅＳｃａｌｅｄＩｎ
ｔｅｇｒａｔｉｏｎ）の登場によって、ハードウェアと
ソフトウェアとをより密にシステム設計する必要が生じ
ている。

【０００３】このような状況の下で、システム構成を決
めて実装した後に評価を行っているようでは、時間的な
短縮は望めない。そこで、システム構成を決定するに当
たって、実装することなく性能などの見積もりを行う必
要性が生じてくる。このニーズに対して、待ち行列理論
を使った性能評価ツールが使われている。このような性
能評価ツールでは、システムに入力されるジョブを待ち
行列を使ってプロセッサに割り当てるという性能評価モ
デルを作成し、処理速度などのパラメータを与えること
で性能評価を行っている。この性能評価モデルを使った
性能評価は、性能評価モデルを作成するコストが高いた
め、強力な性能評価ができるにもかかわらず、広く使わ
れるに至っていない。

【０００４】特開平７−８４８３１号公報では、このよ
うな性能評価の支援手法として、過去に性能評価したモ
デル（性能評価モデル）をデータベースに保持し、以降
の設計モデルの作成に役立てるようなツールが提案され
ている。このツールでは、性能評価をある一定期間続け
ることでツールに依存することなく性能評価モデルが蓄
積されて、設計モデルの作成が容易になるというメリッ
トが得られる。

【０００５】

【発明が解決しようとする課題】しかし、上述した従来
のツールによっても、システムをゼロから開発する場合
で、性能評価モデルに類似のものがないときには、性能
評価モデルをゼロから作成する必要があるため、性能評
価モデルを作成するコストが高いという問題点に関して
はなんら解決されていなかった。

【０００６】本発明の目的は、モデル作成のための事実
上の標準言語であるＵＭＬで記述されたＵＭＬモデルか
ら性能評価モデルを自動的に生成する性能評価モデル生
成装置を提供することにある。

【０００７】また、本発明の他の目的は、ＵＭＬで記述
されたＵＭＬモデルから性能評価モデルを自動的に生成
する性能評価モデル生成方法を提供することにある。

【０００８】

【課題を解決するための手段】本発明の性能評価モデル
生成装置は、変換規則を格納する変換規則格納部と、Ｕ
ＭＬモデルを入力して解析するＵＭＬモデル解析部と、
前記ＵＭＬモデル解析部による解析結果を前記変換規則
格納部に格納された変換規則に従って変換して性能評価
モデルを生成する変換処理部とを有することを特徴とす
る。

【０００９】また、本発明の性能評価モデル生成装置
は、利用者からの変換規則を入力する変換規則編集部
と、前記変換規則編集部により入力された変換規則を格
納する変換規則格納部と、ＵＭＬモデルを入力して解析
するＵＭＬモデル解析部と、前記ＵＭＬモデル解析部に
よる解析結果を前記変換規則格納部に格納された変換規
則に従って変換して性能評価モデルを生成する変換処理
部とを有することを特徴とする。

【００１０】さらに、本発明の性能評価モデル生成方法
は、ＵＭＬモデルの拡張記法を使い、ハードウェアリソ
ースに割り付ける表記を定め、その表記に従ったＵＭＬ
モデルから性能評価モデルへの変換規則を決め、この変
換規則によってＵＭＬモデルから系統的に性能評価モデ
ルを作成することを特徴とする。

【００１１】さらにまた、本発明の性能評価モデル生成
方法は、シーケンス図の最初のメッセージをカレントメ
ッセージにセットする工程と、シーケンス図のカレント
メッセージに着目する工程と、送信先オブジェクトを定
義するクラスのタイプおよび属性を調査する工程と、送
信元オブジェクトを定義するクラスのタイプおよび属性
を調査する工程と、送信元オブジェクトおよび送信先オ
ブジェクトを定義するクラスのタイプに基づいて変換規
則を検索する工程と、検索された変換規則に従ってカレ
ントメッセージを性能評価ツールのノードに変換し配置
する工程と、カレントメッセージの次のメッセージがあ
るかどうかを判定する工程と、次のメッセージがあれば
これをカレントメッセージとして制御を前記カレントメ
ッセージに着目する工程に戻す工程とを含むことを特徴
とする。特に、前記クラスタイプおよび属性を調査する
工程が、さらに、オブジェクトに着目する工程と、オブ
ジェクトを定義するクラスに着目する工程と、オブジェ
クトから対応するクラスを探し該クラスに繋がるリソー
ス関連線を探す工程と、リソース関連線が存在するかど
うかを判定する工程と、リソース関連線が存在すればリ
ソース関連のあるリソースクラスのタイプおよび属性を
クラスのタイプおよび属性として保存する工程と、リソ
ース関連線が存在しなければ元のクラスのタイプおよび
属性をクラスのタイプおよび属性として保存する工程と
からなることを特徴とする。

【００１２】一方、本発明の記録媒体は、コンピュータ
を、変換規則を格納する変換規則格納部，ＵＭＬモデル
を入力して解析するＵＭＬモデル解析部，および前記Ｕ
ＭＬモデル解析部による解析結果を前記変換規則格納部
に格納された変換規則に従って変換して性能評価モデル
を生成する変換処理部として機能させるためのプログラ
ムを記録する。

【００１３】また、本発明の記録媒体は、コンピュータ
を、利用者からの変換規則を入力する変換規則編集部，
前記変換規則編集部により入力された変換規則を格納す
る変換規則格納部，ＵＭＬモデルを入力して解析するＵ
ＭＬモデル解析部，および前記ＵＭＬモデル解析部によ
る解析結果を前記変換規則格納部に格納された変換規則
に従って変換して性能評価モデルを生成する変換処理部
として機能させるためのプログラムを記録する。

【００１４】

【発明の実施の形態】以下、本発明の実施の形態につい
て図面を参照して詳細に説明する。

【００１５】（１）第１の実施の形態図１は、本発明の第１の実施の形態に係る性能評価モデ
ル生成装置の構成を示すブロック図である。本実施の形
態に係る性能評価モデル生成装置は、ＵＭＬモデル５を
入力して解析するＵＭＬモデル解析部１と、ＵＭＬモデ
ル解析部１による解析結果を変換規則格納部４に格納さ
れた変換規則に従って変換して性能評価モデル６を生成
する変換処理部２と、利用者からの変換規則を入力する
変換規則編集部３と、変換規則編集部３により入力され
た変換規則を格納する変換規則格納部４とから構成され
ている。なお、図１中、符号７はＵＭＬモデル５を生成
するＵＭＬモデル入力ツール、８は性能評価モデル６を
性能評価する性能評価ツールをそれぞれ示す。

【００１６】図２は、システムの動作を記述したＵＭＬ
モデル５から性能評価モデル６を系統的に生成する性能
評価モデル生成方法を説明する図である。ＵＭＬモデル
５は、全てＵＭＬという統一モデリング言語の規格に従
った記法で記述する。システムの動作は、動的な振る舞
いを表すシーケンス図５１と、システムの静的な特徴を
表すクラス図５２とで表現される。第１の実施の形態で
は、ＵＭＬモデル５の記述単位として、ＵＭＬモデル５
をパッケージ５０という単位に分割する。つまり、ＵＭ
Ｌモデル５は１つ以上のパッケージ５０から構成され、
パッケージ５０毎にシーケンス図５１およびクラス図５
２を用意する。また、１つのパッケージ５０内のシーケ
ンス図５１およびクラス図５２から生成される性能評価
モデル６の単位を、性能評価サブモデル６０と呼ぶ。つ
まり、性能評価モデル６は、１つ以上の性能評価サブモ
デル６０から構成されている。

【００１７】図３を参照すると、シーケンス図５１は、
システムの動的な関係をモデル化した図である。シーケ
ンス図５１の構成要素の中で、性能評価サブモデル６０
の作成に関係するものには、オブジェクトＯｂ０１〜Ｏ
ｂ０６と、メッセージＭ０１〜Ｍ０７とがある。オブジ
ェクトＯｂ０１〜Ｏｂ０６は、機能単位に登場するクラ
スのインスタンスである。具体的には、後述する図４の
クラス図５２中に対応するクラスＣ０１〜Ｃ０５のイン
スタンスである。メッセージＭ０１〜Ｍ０７は、クラス
Ｃ０１〜Ｃ０５の実際の動作手順を時系列に沿って配置
したものであり、上の方が相対的に早い時間を表してい
る。破線矢印で示されたものは、手続き呼び出しの戻り
を示している。戻りの破線矢印は省略してもよい。

【００１８】図４は、クラス図５２およびクラス図５２
に対して性能評価サブモデル６０を作成するために行わ
れる拡張表記を説明する図である。クラス図５２は、シ
ステムを構成するクラスの静的な関連を示した図であ
る。クラスは、モデリングに使用されるモデル要素であ
り、システムを構成する通常のオブジェクト指向設計で
使われるクラス（以下、システムクラスという）と、ハ
ードウェアリソースを表すクラス（以下、リソースクラ
スという）とに大きく区別され、それぞれさらに細かく
分類される。この分類については、以下の[クラスの分
類]で詳しく説明する。図４においては、クラスＣ０１
〜Ｃ０５がシステムクラスである。性能評価のためにク
ラス図５２に付加する拡張表記は、１つが、処理に必要
なハードウェアリソースを表すリソースクラスＣ１１，
Ｃ１２，Ｃ１３として記述する。もう１つは、これらの
ハードウェアリソースへの関連記述であり、これをリソ
ース関連線Ｌ０１，Ｌ０２，Ｌ０３と名付ける。また、
関連自体をリソース関連と名付け、システムクラスＣ０
２，Ｃ０３，Ｃ０４をリソース関連線Ｌ０１，Ｌ０２，
Ｌ０３を使ってリソースクラスＣ１１，Ｃ１２，Ｃ１３
と結び付けることで、リソースクラスＣ１１，Ｃ１２，
Ｃ１３のハードウェアリソースにシステムクラスＣ０
２，Ｃ０３，Ｃ０４を割り付けるという意味づけをす
る。このリソース関連により、性能評価サブモデル６０
の生成を可能としている。

【００１９】変換規則格納部４中の変換規則は、以下に
示す[クラスの分類]と、[性能評価モデルの変換規則]と
で構成されている。

【００２０】[クラスの分類] ◎システムクラス・タイプ＜＜Ａｃｔｉｖｅ＞＞のクラス通常のクラス。属性およびメソッドを持ち、自立的に動
作するクラス。

【００２１】・タイプ＜＜Ｄａｔａ＞＞のクラス属性が中心のクラス。メソッドは、所有する属性の読み
書きのみに限定されている。

【００２２】・タイプ＜＜Ｉｎｔｅｒｆａｃｅ＞＞のク
ラスタイプ＜＜Ｉｎｔｅｒｆａｃｅ＞＞のクラスは、パッケ
ージ５０内に唯一のクラスであり、外部パッケージから
カレントパッケージへの全てのメッセージを受け取り、
カレントパッケージ内の各クラスにメッセージを送出す
る。

【００２３】・タイプ＜＜Ａｃｔｏｒ＞＞のクラスタイプ＜＜Ａｃｔｏｒ＞＞のクラスは、システムの外部
に存在し、外部からシステム内に何らかの働きかけを行
うクラスの一種である。アクターがシステム内部にも記
憶域を持つ場合、クラス図５２にタイプ＜＜Ａｃｔｏｒ
＞＞のクラスとタイプ＜＜Ｓｔｏｒａｇｅ＞＞のクラス
とのクラス関連を記述する関係上、アクターの記述が必
要となる（後述する[変換規則]のａ．アクターを参
照）。これ以外の場合、クラス図５２にアクターの記述
がなくてもよい。

【００２４】◎リソースクラスリソースクラスは、ハードウェアリソースを表すクラス
である。リソースクラスには、性能評価サブモデル６０
に対応するノード群がある。ハードウェアリソースの占
有時間など、変換したノードに設定すべきパラメータを
クラスの属性に記述し、そのパラメータを使って性能評
価サブモデル６０のノードに変換する。性能評価の対象
にする必要がない場合、評価対象外と記し、性能評価サ
ブモデル６０のノードは生成しない。リソースクラスが
対応する性能評価サブモデル６０のノード群の例を、図
７に示す。

【００２５】・タイプ＜＜Ｓｔｏｒａｇｅ＞＞のクラスタイプ＜＜Ｓｔｏｒａｇｅ＞＞のクラスは、ハードウェ
アリソースの中で記憶域を定義するクラスである。記
憶域の種類や性質に応じて、タイプ＜＜Ｓｔｏｒａｇｅ
＞＞でさまざまなクラスを定義する。

【００２６】・タイプ＜＜Ｐｒｏｃｅｓｓｉｎｇ＞＞の
クラスタイプ＜＜Ｐｒｏｃｅｓｓｉｎｇ＞＞のクラスは、ハー
ドウェアリソースの中で実際の処理をするハードウェア
を定義するクラスである。ソフトウェア処理の場合のＣ
ＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉ
ｔ）も、このクラスで定義する。

【００２７】[性能評価モデルへの変換規則]メッセージ
の送信元オブジェクトおよび送信先オブジェクトを定義
するクラスのタイプに応じて、以下の変換規則を適用す
る。クラスのタイプを追加することで、この変換規則を
追加することが可能となる。以下、「送信元オブジェク
トを定義するクラスのタイプ → 送信先オブジェクト
を定義するクラスのタイプ」という形式で変換規則を記
述する。

【００２８】ａ．「タイプ＜＜Ａｃｔｏｒ＞＞ → 任
意のクラスタイプ」タイプ＜＜Ａｃｔｏｒ＞＞のクラスが最初のメッセージ
を送信する送信元オブジェクトになっている場合、デー
タの発生源であるソースノードに変換する。

【００２９】ｂ．「外部パッケージの任意のクラスタイ
プ → カレントパッケージのタイプ＜＜Ｉｎｔｅｒｆ
ａｃｅ＞＞」カレントパッケージのタイプ＜＜Ｉｎｔｅｒｆａｃｅ＞
＞のクラスに対するメッセージは、データの入り口であ
るエンターノードに変換する。

【００３０】ｃ．「カレントパッケージのタイプ＜＜Ｉ
ｎｔｅｒｆａｃｅ＞＞ → 外部パッケージの任意のク
ラスタイプ」カレントパッケージのタイプ＜＜Ｉｎｔｅｒｆａｃｅ＞
＞のクラスから外部パッケージへのメッセージは、デー
タの出口であるリターンノードに変換する。

【００３１】ｄ．「任意のクラスタイプ → タイプ＜
＜Ｐｒｏｃｅｓｓｉｎｇ＞＞」タイプ＜＜Ｐｒｏｃｅｓｓｉｎｇ＞＞のクラスが定義す
るリソースノードを配置する。

【００３２】ｅ．「任意のクラスタイプ → タイプ＜
＜Ｓｔｏｒａｇｅ＞＞」タイプ＜＜Ｓｔｏｒａｇｅ＞＞のクラスが定義するリソ
ースノードを配置する。

【００３３】ｆ．「任意のクラスタイプ → 外部パッ
ケージのタイプ＜＜Ｉｎｔｅｒｆａｃｅ＞＞」外部パッケージのタイプ＜＜Ｉｎｔｅｒｆａｃｅ＞＞の
クラスがメッセージを受け取る場合、外部パッケージに
対する処理の依頼であるので、その外部パッケージに対
応する性能評価サブモデル６０に変換する。これに続く
メッセージが、カレントメッセージと逆方向になってい
る場合、これに続くメッセージを無視する。

【００３４】ｇ．破線矢印破線矢印のメッセージは、それ自体省略しても可能なも
のである。よって、このメッセージは、変換の際に無視
することができる。

【００３５】ｈ．終了処理最後のメッセージでシンクノードまたはリターンノード
が配置されない場合、このどちらかのノードを配置し、
性能評価サブモデル６０を完結させる。どちらのノード
を配置するかは、変換した性能評価サブモデル６０の最
初のノードに着目し、シンクノードの場合はソースノー
ド、エンターノードの場合はリターンノードを配置す
る。

【００３６】図５を参照すると、性能評価サブモデル６
０は、システム構成をノードで表現する。ノードは、大
別すると、システムの処理フロー自体を表すノードと、
処理フローで利用されるハードウェアリソースを表すノ
ードとに区別できる。図５中の性能評価サブモデル６０
では、前者が下側に、後者が上側に記述されている。シ
ステムの処理フローを表現するノードは、そのフローを
ノード間の結線で表現している。このようなノードに
は、ハードウェアを消費する「処理」を表すサービスノ
ード，データの入力を表すソースノード，処理の終了を
表すシンクノードなどがある。一方、ハードウェアリソ
ースを表すノードとして、ハードウェアに相当するリソ
ースノードがある。リソースノードは、サービスノード
での処理によって消費される。この消費時間，優先順位
などを動的パラメータ６１として設定する。さらに、入
力されるデータのパラメータを加えて、性能評価サブモ
デル６０が生成できる。

【００３７】図５は、性能評価サブモデル６０の一例を
記述する図である。なお、ここでは、性能評価ツール８
として、待ち行列理論を使ったＳＥＳ／Ｗｏｒｋｂｅｎ
ｃｈ（ＳＥＳ社の登録商標）を想定している。この性能
評価サブモデル６０には、処理する側のノードとして、
上部に、ＣＰＵを表すサービスノードＮ０１が記述され
ている。一方、処理フローを表すノードとして、下部
に、ＣＰＵを消費するサービスノードＮ０３と、ＣＰＵ
とは無関係に時間を消費するサービスノードＮ０５と、
システムに入力されるデータに関連するソースノードＮ
０２およびシンクノードＮ０８と、その他のノードとし
て、性能評価サブモデル６０への参照を表すサブモデル
ノードＮ０７，リソース管理のアロケートノードＮ０
４，リリースノードＮ０６と、そして、その間の結線３
１１〜３１６が記述されている。最後に、上部と下部と
を結び付ける記述として、動的パラメータ６１が設定さ
れている。変換では、リソース管理のアロケートノード
Ｎ０４，メモリアクセスを表すサービスノードＮ０５，
およびリリースノードＮ０６という一連のノードを排他
アクセスＭｅｍｏｒｙのモデルとしてあらかじめ用意し
ておき、これらをセットにして変換規則を適用する。図
５にあるノード以外に、他の性能評価サブモデル６０か
らデータの流れを引き継ぐエンターノードおよびリター
ンノードがある。

【００３８】[性能評価サブモデルへの変換手順]図６
は、性能評価サブモデル６０への変換手順を表すフロー
チャートである。性能評価サブモデル６０は、あるパッ
ケージ５０に着目し、そのパッケージ５０のシーケンス
図５１およびクラス図５２から変換して生成される。こ
の着目しているパッケージ５０をカレントパッケージと
呼び、それ以外のパッケージ５０を外部パッケージと呼
ぶ（図４参照）。

【００３９】図６を参照すると、変換処理部２の処理
は、カレントメッセージセットステップＳ１０１と、カ
レントメッセージ着目ステップＳ１０２と、送信元オブ
ジェクトのクラスタイプおよび属性調査ステップＳ１０
３と、送信先オブジェクトのクラスタイプおよび属性調
査ステップＳ１０４と、変換規則検索ステップＳ１０５
と、ノード生成・連結ステップＳ１０６と、次メッセー
ジ有無判定ステップＳ１０７と、オブジェクト着目ステ
ップＳ１０８と、クラス着目ステップＳ１０９と、リソ
ース関連探索ステップＳ１１０と、リソース関連有無判
定ステップＳ１１１と、リソース関連先クラスタイプお
よび属性保存ステップＳ１１２と、自クラスタイプおよ
び属性保存ステップＳ１１３とからなる。

【００４０】次に、このように構成された第１の実施の
形態に係る性能評価モデル生成装置の動作について、第
１の実施の形態に係る性能評価モデル生成方法とともに
説明する。

【００４１】ここでは、図３のシーケンス図５１および
図４のクラス図５２からメッセージを時系列に沿って図
５の性能評価サブモデル６０に変換する例について説明
する。

【００４２】利用者は、変換規則編集部３を使用して、
あらかじめ変換規則を編集して変換規則格納部４に格納
しておく。ここでは、既述した変換規則ａ．〜ｈ．が格
納されたものとする。

【００４３】一方、ＵＭＬモデル解析部１は、ＵＭＬモ
デル入力ツール７を使って生成されたＵＭＬモデル５を
入力して解析する。詳しくは、性能評価サブモデル６０
に変換するために不必要な情報を削除し、必要な情報が
揃っているかどうかをチェックし、必要な情報が揃って
いたならば変換処理部２に解析結果を渡す。

【００４４】変換処理部２は、ＵＭＬモデル解析部１か
ら渡された解析結果中の、シーケンス図５１の最初のメ
ッセージＭ０１をカレントメッセージにセットする（ス
テップＳ１０１）。

【００４５】次に、変換処理部２は、シーケンス図５１
のカレントメッセージＭ０１に着目する（ステップＳ１
０２）。

【００４６】続いて、変換処理部２は、カレントメッセ
ージＭ０１の送信元オブジェクトＯｂ０１を定義するシ
ステムクラスのタイプおよび属性を調査する（ステップ
Ｓ１０３）。

【００４７】詳しくは、変換処理部２は、まず、送信元
オブジェクトＯｂ０１に着目し（ステップＳ１０８）、
名前「ａｃｔｏｒ」に基づいて送信元オブジェクトＯｂ
０１を定義するクラス（ここでは、アクターはシステム
内部に記憶域を持たないものとし、図４中には対応する
クラスが図示されていない）に着目する（ステップＳ１
０９）。次に、そのクラスに繋がるリソース関連線を探
す（ステップＳ１１０）。リソース関連線が存在しない
ので（ステップＳ１１１）、元のクラスのタイプ＜＜Ａ
ｃｔｏｒ＞＞および属性をタイプおよび属性としてその
まま保存する（ステップＳ１１３）。

【００４８】次に、変換処理部２は、カレントメッセー
ジＭ０１の送信先オブジェクトＯｂ０２を定義するクラ
スＣ０１のタイプおよび属性を調査する（ステップＳ１
０４）。

【００４９】詳しくは、変換処理部２は、まず、送信先
オブジェクトＯｂ０２に着目し（ステップＳ１０８）、
名前「ＭａｉｎＰ」に基づいて送信先オブジェクトＯｂ
０２を定義するシステムクラスＣ０１に着目する（ステ
ップＳ１０９）。次に、システムクラスＣ０１に繋がる
リソース関連線を探す（ステップＳ１１０）。リソース
関連線が存在しないので（ステップＳ１１１）、元のシ
ステムクラスＣ０１のタイプ＜＜Ｉｎｔｅｒｆａｃｅ＞
＞および属性をシステムクラスＣ０１のタイプおよび属
性としてそのまま保存する（ステップＳ１１３）。

【００５０】続いて、変換処理部２は、送信元オブジェ
クトＯｂ０１を定義するクラスのタイプ＜＜Ａｃｔｏｒ
＞＞および送信先オブジェクトＯｂ０２を定義するシス
テムクラスＣ０１のタイプ＜＜Ｉｎｔｅｒｆａｃｅ＞＞
に基づいて、変換規則格納部４から変換規則ａ．を検索
する（ステップＳ１０５）。

【００５１】続いて、変換処理部２は、検索された変換
規則ａ．「アクターが最初のメッセージを送信するオブ
ジェクトになっている場合、データの発生源であるソー
スノードに変換する。」に基づいて、ソースノードＮ０
２に変換して性能評価サブモデル６０に配置する（ステ
ップＳ１０６）。

【００５２】次に、変換処理部２は、シーケンス図５１
の次のメッセージの存在を調査し（ステップＳ１０
７）、次のメッセージＭ０２があるので、ステップＳ１
０２に制御を戻す。

【００５３】変換処理部２は、次のメッセージＭ０２を
カレントメッセージにセットして着目する（ステップＳ
１０２）。

【００５４】次に、変換処理部２は、メッセージＭ０２
の送信元オブジェクトＯｂ０２を定義するシステムクラ
スのタイプおよび属性を調査する（ステップＳ１０
３）。

【００５５】詳しくは、変換処理部２は、まず、送信元
オブジェクトＯｂ０２に着目し（ステップＳ１０８）、
名前「ＭａｉｎＰ」に基づいて送信元オブジェクトＯｂ
０２を定義するシステムクラスＣ０１に着目する（ステ
ップＳ１０９）。次に、システムクラスＣ０１に繋がる
リソース関連線を探す（ステップＳ１１０）。リソース
関連線が存在しないので（ステップＳ１１１）、元のシ
ステムクラスＣ０１のタイプ＜＜Ｉｎｔｅｒｆａｃｅ＞
＞および属性をシステムクラスＣ０１のタイプおよび属
性としてそのまま保存する（ステップＳ１１３）。

【００５６】続いて、変換処理部２は、メッセージＭ０
２の送信先オブジェクトＯｂ０３を定義するシステムク
ラスのタイプおよび属性を調査する（ステップＳ１０
４）。

【００５７】詳しくは、変換処理部２は、まず、送信先
オブジェクトＯｂ０３に着目し（ステップＳ１０８）、
名前「Ｍａｉｎ」に基づいて送信先オブジェクトＯｂ０
３を定義するシステムクラスＣ０２に着目する（ステッ
プＳ１０９）。次に、システムクラスＣ０２に繋がるリ
ソース関連線を探す（ステップＳ１１０）。リソース関
連線Ｌ０１が存在するので（ステップＳ１１１）、リソ
ース関連のあるリソースクラスＣ１１のタイプ＜＜Ｐｒ
ｏｃｅｓｓｉｎｇ＞＞および属性「評価対象」をシステ
ムクラスＣ０２のタイプとして保存する（ステップＳ１
１２）。

【００５８】次に、変換処理部２は、送信元オブジェク
トＯｂ０２を定義するシステムクラスＣ０１のタイプ＜
＜Ｉｎｔｅｒｆａｃｅ＞＞および送信先オブジェクトＯ
ｂ０３を定義するシステムクラスＣ０２のタイプ＜＜Ｐ
ｒｏｃｅｓｓｉｎｇ＞＞に基づいて、変換規則格納部４
から変換規則ｄ．を検索する（ステップＳ１０５）。

【００５９】続いて、変換処理部２は、変換規則ｄ．
「タイプ＜＜Ｐｒｏｃｅｓｓｉｎｇ＞＞のクラスが定義
するリソースノードを配置する。」を適用して、図７に
示すように、タイプ＜＜Ｐｒｏｃｅｓｓｉｎｇ＞＞のリ
ソースクラスＣ１１が定義するリソースノードＮ０１に
変換して配置する（ステップＳ１０６）。

【００６０】次に、変換処理部２は、シーケンス図５１
の次のメッセージの存在を調査し（ステップＳ１０
７）、次のメッセージＭ０３があるので、ステップＳ１
０２に制御を戻す。

【００６１】続いて、変換処理部２は、次のメッセージ
Ｍ０３をカレントメッセージにセットして着目する（ス
テップＳ１０２）。

【００６２】次に、変換処理部２は、メッセージＭ０３
の送信元オブジェクトＯｂ０３を定義するシステムクラ
スのタイプおよび属性を調査する（ステップＳ１０
３）。

【００６３】詳しくは、変換処理部２は、まず、送信元
オブジェクトＯｂ０３に着目し（ステップＳ１０８）、
名前「Ｍａｉｎ」に基づいて送信元オブジェクトＯｂ０
３を定義するシステムクラスＣ０２に着目する（ステッ
プＳ１０９）。次に、システムクラスＣ０２に繋がるリ
ソース関連線を探す（ステップＳ１１０）。リソース関
連線Ｌ０１が存在するので（ステップＳ１１１）、リソ
ース関連のあるリソースクラスＣ１１のタイプ＜＜Ｐｒ
ｏｃｅｓｓｉｎｇ＞＞および属性「評価対象」をシステ
ムクラスＣ０２のタイプおよび属性として保存する（ス
テップＳ１１２）。

【００６４】続いて、変換処理部２は、メッセージＭ０
３の送信先オブジェクトＯｂ０４を定義するシステムク
ラスのタイプおよび属性を調査する（ステップＳ１０
４）。

【００６５】詳しくは、変換処理部２は、まず、送信先
オブジェクトＯｂ０４に着目し（ステップＳ１０８）、
名前「Ａ」に基づいて送信先オブジェクトＯｂ０４を定
義するシステムクラスＣ０３に着目する（ステップＳ１
０９）。次に、システムクラスＣ０３に繋がるリソース
関連線を探す（ステップＳ１１０）。リソース関連線Ｌ
０２が存在するので（ステップＳ１１１）、リソース関
連のあるリソースクラスＣ１２のタイプ＜＜Ｓｔｏｒａ
ｇｅ＞＞および属性「評価対象外」をシステムクラスＣ
０３のタイプおよび属性として保存する（ステップＳ１
１２）。

【００６６】次に、変換処理部２は、送信元オブジェク
トＯｂ０３を定義するシステムクラスＣ０２のタイプ＜
＜Ｐｒｏｃｅｓｓｉｎｇ＞＞および送信先オブジェクト
Ｏｂ０４を定義するシステムクラスＣ０３のタイプ＜＜
Ｓｔｏｒａｇｅ＞＞に基づいて、変換規則格納部４から
変換規則ｅ．を検索する（ステップＳ１０５）。

【００６７】続いて、変換処理部２は、変換規則ｅ．
「タイプ＜＜Ｓｔｏｒａｇｅ＞＞のクラスが定義するリ
ソースノードを配置する。」を適用して、図７に示すよ
うに、タイプ＜＜Ｓｔｏｒａｇｅ＞＞のクラスＣ１２が
定義するリソースノード群Ｎ０４，Ｎ０５，Ｎ０６に変
換し、リソースクラスＣ１２の属性が「評価対象」とな
っているので、ノード群Ｎ０４，Ｎ０５，Ｎ０６を評価
対象サブモデル６０に配置する（ステップＳ１０６）。

【００６８】次に、変換処理部２は、シーケンス図５１
の次のメッセージの存在を調査し（ステップＳ１０
７）、次のメッセージＭ０４があるが、破線矢印のメッ
セージであるので、これを無視し、さらに次のメッセー
ジの存在を調査し、メッセージＭ０５があるので、ステ
ップＳ１０２に制御を戻す。

【００６９】変換処理部２は、次のメッセージＭ０５を
カレントメッセージにセットして着目する（ステップＳ
１０２）。

【００７０】次に、変換処理部２は、カレントメッセー
ジＭ０５の送信元オブジェクトＯｂ０３を定義するシス
テムクラスのタイプおよび属性を調査する（ステップＳ
１０３）。

【００７１】詳しくは、変換処理部２は、まず、送信元
オブジェクトＯｂ０３に着目し（ステップＳ１０８）、
名前「Ｍａｉｎ」に基づいて送信元オブジェクトＯｂ０
３を定義するシステムクラスＣ０２に着目する（ステッ
プＳ１０９）。次に、システムクラスＣ０２に繋がるリ
ソース関連線を探す（ステップＳ１１０）。リソース関
連線Ｌ０１が存在するので（ステップＳ１１１）、リソ
ース関連のあるリソースクラスＣ１１のタイプ＜＜Ｐｒ
ｏｃｅｓｓｉｎｇ＞＞および属性「評価対象」をシステ
ムクラスＣ０２のタイプおよび属性として保存する（ス
テップＳ１１２）。

【００７２】続いて、変換処理部２は、メッセージＭ０
５の送信先オブジェクトＯｂ０５を定義するシステムク
ラスのタイプおよび属性を調査する（ステップＳ１０
４）。

【００７３】詳しくは、変換処理部２は、まず、送信先
オブジェクトＯｂ０５に着目し（ステップＳ１０８）、
名前「Ｂ」に基づいて送信先オブジェクトＯｂ０５を定
義するシステムクラスＣ０４に着目する（ステップＳ１
０９）。次に、システムクラスＣ０４に繋がるリソース
関連線を探す（ステップＳ１１０）。リソース関連線Ｌ
０３が存在するので（ステップＳ１１１）、リソースク
ラスＣ１３のタイプ＜＜Ｓｔｏｒａｇｅ＞＞および属性
「評価対象外」をシステムクラスＣ０４のタイプおよび
属性として保存する（ステップＳ１１２）。

【００７４】次に、変換処理部２は、送信元オブジェク
トＯｂ０３を定義するシステムクラスＣ０２のタイプ＜
＜Ｐｒｏｃｅｓｓｉｎｇ＞＞および送信先オブジェクト
Ｏｂ０５を定義するシステムクラスＣ０４のタイプ＜＜
Ｓｔｏｒａｇｅ＞＞に基づいて、変換規則格納部４から
変換規則ｅ．を検索する（ステップＳ１０５）。

【００７５】続いて、変換処理部２は、変換規則ｅ．を
適用しようとするが、システムクラスＣ０４の属性が
「評価対象外」となっているので、ノードへの変換を行
わずに性能評価サブモデル６０に配置しない（ステップ
Ｓ１０６）。

【００７６】次に、変換処理部２は、シーケンス図５１
の次のメッセージの存在を調査し（ステップＳ１０
７）、次のメッセージＭ０６があるので、ステップＳ１
０２に制御を戻す。

【００７７】次に、変換処理部２は、シーケンス図５１
のカレントメッセージＭ０６に着目する（ステップＳ１
０２）。

【００７８】続いて、変換処理部２は、メッセージＭ０
６の送信元オブジェクトＯｂ０３を定義するシステムク
ラスのタイプおよび属性を調査する（ステップＳ１０
３）。

【００７９】詳しくは、変換処理部２は、まず、送信元
オブジェクトＯｂ０３に着目し（ステップＳ１０８）、
名前「Ｍａｉｎ」に基づいて送信元オブジェクトＯｂ０
３を定義するシステムクラスＣ０２に着目する（ステッ
プＳ１０９）。次に、システムクラスＣ０２に繋がるリ
ソース関連線を探す（ステップＳ１１０）。リソース関
連線Ｌ０１が存在するので（ステップＳ１１１）、リソ
ース関連のあるリソースクラスＣ１１のタイプ＜＜Ｐｒ
ｏｃｅｓｓｉｎｇ＞＞および属性「評価対象」をシステ
ムクラスＣ０２のタイプおよび属性として保存する（ス
テップＳ１１２）。

【００８０】次に、変換処理部２は、メッセージＭ０６
の送信先オブジェクトＯｂ０６を定義するシステムクラ
スのタイプおよび属性を調査する（ステップＳ１０
４）。

【００８１】詳しくは、変換処理部２は、まず、送信先
オブジェクトＯｂ０６に着目し（ステップＳ１０８）、
名前「ｓｕｂＰ」に基づいて送信先オブジェクトＯｂ０
６を定義するシステムクラスＣ０５に着目する（ステッ
プＳ１０９）。次に、システムクラスＣ０５に繋がるリ
ソース関連線を探す（ステップＳ１１０）。リソース関
連線が存在しないので（ステップＳ１１１）、元のシス
テムクラスＣ０５のタイプ＜＜Ｉｎｔｅｒｆａｃｅ＞＞
および属性をシステムクラスＣ０５のタイプおよび属性
として保存する（ステップＳ１１３）。

【００８２】次に、変換処理部２は、送信元オブジェク
トＯｂ０３を定義するシステムクラスＣ０３のタイプ＜
＜Ｐｒｏｃｅｓｓｉｎｇ＞＞および送信先オブジェクト
Ｏｂ０６を定義するシステムクラスＣ０５のタイプ＜＜
Ｉｎｔｅｒｆａｃｅ＞＞に基づいて、変換規則格納部４
から変換規則ｆ．を検索する（ステップＳ１０５）。

【００８３】続いて、変換処理部２は、変換規則ｆ．を
適用して、外部パッケージのタイプ＜＜Ｉｎｔｅｒｆａ
ｃｅ＞＞のクラスがメッセージを受け取る場合、外部パ
ッケージに対する処理の依頼であるので、その外部パッ
ケージに対応する性能評価サブモデル６０のノードＮ０
７に変換し配置する（ステップＳ１０６）。このノード
Ｎ０７は、タイプ＜＜Ｉｎｔｅｒｆａｃｅ＞＞のシステ
ムクラスＣ０５が属するパッケージ５０を表している。

【００８４】次に、変換処理部２は、シーケンス図５１
の次のメッセージの存在を調査し、次のメッセージＭ０
７があるが、破線矢印のメッセージであるので、これを
無視し、さらに次のメッセージの存在を調査し、メッセ
ージがないと判断する（ステップＳ１０７）。

【００８５】最後に、変換処理部２は、性能評価サブモ
デル６０がシンクノードまたはリターンノードで完結し
ていないので、変換規則ｈ．により、性能評価サブモデ
ル６０に終了処理を加える。この性能評価サブモデル６
０では、最初のオブジェクトＯｂ０１をソースノードＮ
０２としたので、シンクノードＮ０８を配置し、性能評
価サブモデル６０を完結させる。

【００８６】なお、第１の実施の形態では、変換規則
ａ．〜ｈ．が変換規則格納部４に格納されているものと
したが、変換規則は変換規則編集部３により変換規則格
納部４に追加および変更可能となっているので、上記に
示した変換規則以外に従った変換も可能であることはい
うまでもない。

【００８７】また、第１の実施の形態では、１つのパッ
ケージ５０の性能評価サブモデル６０について説明した
が、この処理を繰り返すことにより複数の性能評価サブ
モデル６０からなる性能評価モデル６の全体が同様にし
て得られることはいうまでもない。

【００８８】第１の実施の形態では、通常のシステム分
析およびシステム設計で行われるような機能的な観点か
らＵＭＬモデル５を作成し、ハードウェアリソースを表
すリソースクラスと、システムクラスとリソースクラス
との関連を示すリソース関連線とを追加することで、性
能評価モデル６を生成することが可能となる。これによ
り、ＵＭＬモデル５の作成と性能評価モデル６の作成と
の距離が縮まり、最終的に、性能評価モデル６の作成時
間および作成コストを軽減することが可能となる。

【００８９】（２）第２の実施の形態図８を参照すると、本発明の第２の実施の形態に係る性
能評価モデル生成装置は、図１に示した第１の実施の形
態に係る性能評価モデル生成装置に対して、性能評価モ
デル生成プログラムを記録した記録媒体１００を備える
点のみが異なっている。この記録媒体１００は、磁気デ
ィスク，半導体メモリ，その他の記録媒体であってよ
い。

【００９０】性能評価モデル生成プログラムは、記録媒
体１００からコンピュータでなる性能評価モデル生成装
置に読み込まれ、ＵＭＬモデル解析部１，変換処理部
２，変換規則編集部３，および変換規則格納部４として
動作する。各部１〜４の動作は、第１の実施の形態に係
る性能評価モデル生成装置における対応する各部１〜４
と全く同様になるので、その詳しい説明を割愛する。

【００９１】

【発明の効果】第１の効果は、システムの分析および設
計で広く使われているＵＭＬモデルを元に、性能評価モ
デルを作成することにより、性能評価モデルの作成が容
易になり、性能評価モデルの作成にかかる時間の削減、
つまりコストの削減ができることである。

【００９２】その理由は、ＵＭＬモデルで純粋に機能モ
デルを作成する部分に関しては、これまでのシステム設
計の手法をほぼそのまま流用でき、ＵＭＬモデルを元に
してハードウェアリソースとの対応を考えるだけで性能
評価モデルが生成できるためである。

【００９３】第２の効果は、システムのＵＭＬモデルに
誤りが無ければ、性能評価モデルの作成時点で起こりう
る性能評価モデルの作成誤りをなくすことが可能となる
ことである。

【００９４】その理由は、ＵＭＬモデルに誤りがなく、
そのＵＭＬモデルから系統的に性能評価モデルを作成す
るため、性能評価モデルの作成時に起こりうる単純な誤
り，勘違いなどを防ぐことが可能となるからである。

【００９５】第３の効果は、性能評価ツールの違いを越
えて、既存のモデルや他の人が作成したモデルを広く参
照することが容易になることである。

【００９６】その理由は、機能モデルとしてＵＭＬとい
う統一モデリング言語を使うことにより、異なる性能評
価ツール間でも同一のＵＭＬモデルを使ってシステムを
表現できるためである。性能評価モデルは、一般的に、
独自のフォーマットでモデルを記述する必要があり、こ
のモデルは一般的に各ツールで異なっている。本発明に
よれば、ＵＭＬモデルという統一表記法でシステムの機
能モデルを入力し、性能評価をするため、システムの機
能モデルの入力も一般的なツールが使え、性能評価ツー
ルの違いを越えて、既存資産の流用も容易となるからで
ある。

【図面の簡単な説明】

【図１】本発明の第１の実施の形態に係る性能評価モデ
ル生成装置の構成を示すブロック図である。

【図２】第１の実施の形態に係る性能評価モデル生成方
法の概要を説明する図である。

【図３】図２中のシーケンス図の内容を例示する図であ
る。

【図４】図２中のクラス図の内容を例示する図である。

【図５】図２中の性能評価サブモデルの内容を例示す
る。

【図６】第１の実施の形態に係る性能評価モデル生成方
法の手順を示すフローチャートである。

【図７】リソースクラスに対応するノード群を例示する
図である。

【図８】本発明の第２の実施の形態に係る性能評価モデ
ル生成装置の構成を示すブロック図である。

【符号の説明】

１ＵＭＬモデル解析部２変換処理部３変換規則編集部４変換規則格納部５ＵＭＬモデル６性能評価モデル７ＵＭＬモデル入力ツール８性能評価ツール５０パッケージ５１シーケンス図５２クラス図６０性能評価サブモデル６１動的パラメータ１００記録媒体３１１〜３１６結線Ｃ０１〜Ｃ０５システムクラスＣ１１〜Ｃ１３リソースクラスＬ０１〜Ｌ０３リソース関連線Ｍ０１〜Ｍ０７メッセージＯｂ０１〜Ｏｂ０６オブジェクトＳ１０１カレントメッセージセットステップＳ１０２カレントメッセージ着目ステップＳ１０３送信元オブジェクトのクラスタイプおよび属
性調査ステップＳ１０４送信先オブジェクトのクラスタイプおよび属
性調査ステップＳ１０５変換規則検索ステップＳ１０６ノード変換・配置ステップＳ１０７次メッセージ有無判定ステップＳ１０８オブジェクト着目ステップＳ１０９クラス着目ステップＳ１１０リソース関連探索ステップＳ１１１リソース関連有無判定ステップＳ１１２リソース関連先クラスタイプおよび属性保存
ステップＳ１１３自クラスタイプおよび属性保存ステップ

Claims

【特許請求の範囲】

【請求項１】変換規則を格納する変換規則格納部と、Ｕ
ＭＬモデルを入力して解析するＵＭＬモデル解析部と、
前記ＵＭＬモデル解析部による解析結果を前記変換規則
格納部に格納された変換規則に従って変換して性能評価
モデルを生成する変換処理部とを有することを特徴とす
る性能評価モデル生成装置。
【請求項２】利用者からの変換規則を入力する変換規則
編集部と、前記変換規則編集部により入力された変換規
則を格納する変換規則格納部と、ＵＭＬモデルを入力し
て解析するＵＭＬモデル解析部と、前記ＵＭＬモデル解
析部による解析結果を前記変換規則格納部に格納された
変換規則に従って変換して性能評価モデルを生成する変
換処理部とを有することを特徴とする性能評価モデル生
成装置。
【請求項３】ＵＭＬモデルの拡張記法を使い、ハードウ
ェアリソースに割り付ける表記を定め、その表記に従っ
たＵＭＬモデルから性能評価モデルへの変換規則を決
め、この変換規則によってＵＭＬモデルから系統的に性
能評価モデルを作成することを特徴とする性能評価モデ
ル生成方法。
【請求項４】シーケンス図の最初のメッセージをカレン
トメッセージにセットする工程と、シーケンス図のカレ
ントメッセージに着目する工程と、送信先オブジェクト
を定義するクラスのタイプおよび属性を調査する工程
と、送信元オブジェクトを定義するクラスのタイプおよ
び属性を調査する工程と、送信元オブジェクトおよび送
信先オブジェクトを定義するクラスのタイプに基づいて
変換規則を検索する工程と、検索された変換規則に従っ
てカレントメッセージを性能評価ツールのノードに変換
し配置する工程と、カレントメッセージの次のメッセー
ジがあるかどうかを判定する工程と、次のメッセージが
あればこれをカレントメッセージとして制御を前記カレ
ントメッセージに着目する工程に戻す工程とを含むこと
を特徴とする性能評価モデル生成方法。
【請求項５】前記クラスタイプおよび属性を調査する工
程が、さらに、オブジェクトに着目する工程と、オブジ
ェクトを定義するクラスに着目する工程と、オブジェク
トから対応するクラスを探し該クラスに繋がるリソース
関連線を探す工程と、リソース関連線が存在するかどう
かを判定する工程と、リソース関連線が存在すればリソ
ース関連のあるリソースクラスのタイプおよび属性をク
ラスのタイプおよび属性として保存する工程と、リソー
ス関連線が存在しなければ元のクラスのタイプおよび属
性をクラスのタイプおよび属性として保存する工程とか
らなる請求項４記載の性能評価モデル生成方法。
【請求項６】コンピュータを、変換規則を格納する変換
規則格納部，ＵＭＬモデルを入力して解析するＵＭＬモ
デル解析部，および前記ＵＭＬモデル解析部による解析
結果を前記変換規則格納部に格納された変換規則に従っ
て変換して性能評価モデルを生成する変換処理部として
機能させるためのプログラムを記録した記録媒体。
【請求項７】コンピュータを、利用者からの変換規則を
入力する変換規則編集部，前記変換規則編集部により入
力された変換規則を格納する変換規則格納部，ＵＭＬモ
デルを入力して解析するＵＭＬモデル解析部，および前
記ＵＭＬモデル解析部による解析結果を前記変換規則格
納部に格納された変換規則に従って変換して性能評価モ
デルを生成する変換処理部として機能させるためのプロ
グラムを記録した記録媒体。