【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、システム開発対象業務を構成する構成要素に関する構成要素情報と、構成要素内、または、構成要素間の手続の起動連鎖を記録した手続連鎖情報を保持するシナリオとによって定義された要求仕様モデルを他の形式のモデルに変換する要求仕様モデル・他形式モデル変換装置及びその変換方法に関する。

【０００２】

【従来の技術】システム開発における要求仕様定義のための技術として、例えば、特開平９−８１６１１号公報に記載されるように、対象業務を構成する要素であるキャラクターを定義し、キャラクターに持たせるデータや手続きを使って実世界の業務をシーンと呼ばれるシナリオの断片的な具体例として入力していくことで要求仕様を定義していく技術がある。 ここでいうキャラクターとは、要求仕様中に出てくる「人」や具体的な「物」、その他概念的な「抽象物」である。 キャラクターは、その名称、そのイメージを表現する表示図形情報、保持する内部データ情報と内部手続情報を持っている。 キャラクターが保持する内部データ情報を属性といい、キャラクターが保持する内部手続情報をメッセージと言う。 また、シナリオとは、要求仕様の断片的な具体例である。
シナリオは、シーン及びそのシナリオに登場するキャラクタに関する情報を構成要素として持つ。 シーンとは、
キャラクター間の内部手続きの起動連鎖のことである。

【０００３】要求仕様定義技術で定義した要求仕様モデルファイルを、他形式のモデルファイルを扱うプログラムで利用できるように変換する技術として、要求仕様モデル・他形式モデル変換技術がある。 要求仕様モデル・
他形式モデル変換技術とは、上述したような要求仕様定義プログラムにより定義した要求仕様モデルのファイルを、別のプログラムが入力するための他の形式のモデルファイルのデータ形式に合せて変換し、そのプログラムが入力して編集し、表示装置に表示できるようにする技術である。 近年、これらの技術を適用したソフトウェア製品が実現されつつある。

【０００４】

【発明が解決しようとする課題】上述したような従来の要求仕様モデル・他形式モデル変換装置では、要求仕様モデルを構成するキャラクター及びシナリオが全て他形式モデルの要素として変換されていた。 そのため、要求仕様モデルから他形式モデルへ変換した後、不必要な他の形式モデルの要素を削除しなければならないといった問題があった。

【０００５】本発明の目的は、要求仕様モデルから他形式モデルに変換する時に、必要な他形式モデルの要素のみを生成することのできる要求仕様モデル・他形式モデル変換装置を提供することにある。

【０００６】

【課題を解決するための手段】上記目的を達成するために、本発明による要求仕様モデル・他形式モデル変換装置及び変換方法は、システム開発対象業務を構成する構成要素が保持する名称、データ名称及び手続き名称を記録した構成要素情報と、構成要素間の手続きの起動連鎖を記録した手続き起動連鎖情報、または構成要素内の手続きの起動連鎖を記録した手続き起動連鎖情報を保持するシナリオとによって定義された要求仕様モデルを他の形式のモデルに変換する要求仕様モデル・他形式モデル変換装置及び変換方法において、コンピュータ読み取り可能な記憶装置に格納され、要求仕様モデルからなる要求仕様モデルファイルを要求仕様モデルファイル入力手段から読み込む。 要求仕様モデルファイル入力手段が入力した要求仕様モデルファイルから得られる構成要素情報、構成要素が他形式モデルの要素となるか否かの判断材料となる構成要素種別を構成要素情報記憶手段に記憶する。 また、要求仕様モデルファイル入力手段が入力した要求仕様モデルファイルから得られるシナリオをシナリオ情報記憶手段に記憶する。 構成要素情報解析・生成手段は、構成要素情報記憶手段に格納された構成要素情報を基に、構成要素種別から構成要素が他形式モデルの要素となるか否かを判断し、他形式モデルの要素を生成する。 シナリオ情報解析・生成手段は、シナリオ情報記憶手段に格納されたシナリオを基に、他形式モデルの要素を生成する。 構成要素情報解析・生成手段、及びシナリオ解析・生成手段により生成された他形式モデルの要素は、他形式モデルファイル出力手段により統合され、
コンピュータ書込み可能な記憶装置に格納される。

【０００７】本発明による要求仕様モデル・他形式モデル変換装置は、他の観点によれば、コンピュータ読み取り可能な記憶装置に格納された要求仕様モデルファイルを読み込む要求仕様モデルファイル入力手段と、要求仕様モデルファイル入力手段より受け取ったキャラクター情報である、キャラクターを識別するキャラクター識別子、キャラクターの状態を表す値を格納する属性及びキャラクターの実行可能な動作を表すメッセージなどを記憶し、かつキャラクターが他形式モデルの要素となるか否かの判断材料となるキャラクター種別を記憶するキャラクター情報記憶手段と、要求仕様モデルファイル入力手段より受け取ったシナリオ情報である、シナリオを識別するシナリオ識別子、シナリオに登場するキャラクターを示すキャラクター識別子及びシナリオを構成するシーンなどを記憶するシナリオ情報記憶手段と、キャラクター情報記憶手段より取り出したキャラクター情報を基に、キャラクター種別からキャラクターが他形式モデルの要素となるか否かを判断し、他形式モデルの要素を生成するキャラクター情報解析・生成手段と、シナリオ情報記憶手段より取り出したシナリオ情報を基に、他形式モデルの要素を生成するシナリオ情報解析・生成手段と、キャラクター情報解析・生成手段及びシナリオ情報解析・生成手段より受け取った他形式モデルの要素を統合し、コンピュータ書込み可能な記憶装置に格納する他形式モデルファイル出力手段を備えることを特徴とする。

【０００８】

【発明の実施の形態】図１は、本実施の形態において要求仕様モデル変換処理を行う電子計算機の構成図である。 本実施例では、要求仕様モデルを、オブジェクト指向モデル化技法であるＵＭＬ（Unified Modeling Langu
age）が扱う形式であるＵＭＬモデルに変換する。 分析・設計手法である。 ＵＭＬに関する技術としては、例えば、Terry Quatrani, "Visual Modeling with Rational
Rose", ISBN:0-201-31016-3に記載された技術が知られている。

【０００９】ＵＭＬは、クラスやクラス間の関係を表現するクラス図、オブジェクト間の手続きであるシーンを時系列的な流れとして表現するシーケンス図、及びシステムの外部インタフェースを表現するユースケース図などの図によりモデルを表現する。 ＵＭＬモデルの構成要素には、開発対象システムを構成する要素であるオブジェクトやオブジェクトの集合であるクラスの他に、例えば、ユーザや既存システムなどのシステム外部にあり、
システムと情報交換を行うアクターや、アクターに対してシステムが何を行うかを示すためのものであるユースケースなどといったものがある。

【００１０】図１において、処理装置１０２は、パーソナルコンピュータ、あるいはワークステーションなどの計算機である。 処理装置１０２の主記憶装置又は処理装置１０２に接続される外部記憶装置上には、キャラクター情報を構成する要素であるキャラクターを識別するキャラクター名称、キャラクターの状態を表す値を格納する属性、及びキャラクターの実行可能な動作を表すメッセージを記憶し、かつキャラクターが他形式モデルの要素となるか否かの判断材料となるキャラクター種別を記憶するキャラクター情報記憶部１０５、シナリオ情報を構成する要素であるシナリオを識別するシナリオ識別子、シナリオに登場するキャラクターを示すキャラクター識別子、及びシナリオを構成するシーンを記憶するシナリオ情報記憶部１０６、キャラクター情報解析・生成部１０７が生成したクラス情報を記憶するクラス図情報記憶部１０９、キャラクター情報解析・生成部１０７が生成したアクター情報、シナリオ情報解析・生成部１０
８が生成したユースケース情報及び関連情報を記憶するユースケース図情報記憶部１１０、及びシナリオ情報解析・生成部１０８が生成したシーケンス図情報を記憶するシーケンス図情報一覧記憶部１１１の各記憶部が設けられる。

【００１１】処理装置１０２は、その機能として、コンピュータ読み取り可能な入力記憶装置１０１に格納された要求仕様モデルファイルを読み込む要求仕様モデルファイル入力部１０４、キャラクター情報記憶部１０５より取り出したキャラクター情報を基に、キャラクター種別からキャラクターがＵＭＬモデルの要素であるクラスとなるかアクターとなるかを判断し、ＵＭＬモデルのクラス情報又はアクター情報を生成するキャラクター情報解析・生成部１０７、シナリオ情報記憶部１０６より取り出したシナリオ情報を基に、ＵＭＬモデルのシーケンス図を生成するかまたはユースケース及び関連を生成するかを判断し、シーケンス図情報又はユースケース情報及び関連情報を生成するシナリオ情報解析・生成部１０
８、及びクラス図情報記憶部１０９、ユースケース図情報記憶部１１０、及びシーケンス図情報一覧記憶部１１
１より受け取ったＵＭＬモデルの要素を統合し、コンピュータ書込み可能な出力記憶装置１０３に格納するＵＭ
Ｌモデルファイル出力部１１２の各処理部を有する。 これらの処理部は、具体的には、処理装置１０２の主記憶装置、又は処理装置１０２に接続される外部記憶装置上に格納され、本実施の形態における要求仕様モデル・他形式モデル変換プログラムを構成するプログラムモジュールであり、処理装置１０２によって実行されることによりその機能が実現される。

【００１２】図２は、外部プログラムである要求仕様モデル作成プログラム２０１、処理装置１０１により実行される要求仕様モデル・他形式モデル変換プログラム２
０２、及び外部プログラムであるＵＭＬモデル入力プログラム２０３を接続し、要求仕様モデルファイル生成からＵＭＬモデルファイル生成までを行う手順を示した図である。 要求仕様モデル作成プログラム２０１は、要求仕様モデルファイルを生成するためのプログラムである。 入力記憶装置１０１には、要求仕様モデル作成プログラム２０１が作成した要求仕様モデルファイルが格納される。 要求仕様モデル・他形式モデル変換プログラム２０２は、入力記憶装置１０１に格納された要求仕様モデルファイルをＵＭＬモデルファイルに変換し、出力記憶装置１０３に格納する。 出力記憶装置１０３に格納されたＵＭＬモデルファイルは、別の外部プログラムであるＵＭＬモデル入力プログラム２０２が入力する。

【００１３】図３に、入力記憶装置１０１に格納された要求仕様モデルファイルの詳細を示す。

【００１４】要求仕様モデルファイル１９０１は、開発対象業務の構成要素であるキャラクターの情報を保持するキャラクター情報１９０２及び対象業務の具体例であるシナリオの情報を保持するシナリオ情報から構成される。

【００１５】キャラクター情報１９０２は、識別子であるキャラクター名称１９０３、キャラクター種別１９０
４、キャラクターの内部データを表わす属性１９０５、
及びキャラクターの内部手続きであるメッセージ１９０
８を有している。 属性１９０５は、識別子である属性名称１９０６及びデータ値を表わす属性値１９０７から構成される。 メッセージ１９０８は、識別子であるメッセージ名称１９１０から構成される。

【００１６】シナリオ情報１９１１は、識別子であるシナリオ名称１９１２、シナリオを構成するキャラクターの一覧を表わすシナリオ内キャラクター情報一覧１９１
３、及びシナリオ内でのキャラクター間の手続きの起動連鎖を表わすシーン情報１９１６から構成される。 シナリオ内キャラクター情報一覧１９１３は、キャラクター名称１９１４及びシナリオ上での配置位置を示す座標１
９１５の対のリストである。 シーン情報１９１６は、メッセージ送信により手続きの起動を要求するところのキャラクターを表わすメッセージ送信キャラクター名称１
９１７、メッセージを受け取り手続きの起動を行なうところのキャラクターを表わすメッセージ受信キャラクター名称１９１８及び起動される手続きを表わすメッセージ名称１９１９から構成される。

【００１７】図４に、キャラクター情報記憶部１０５に格納されるキャラクター情報３０１の詳細を示す。 キャラクター情報記憶部１０５には、キャラクター情報３０
１が格納される。 キャラクター情報３０１は、キャラクターの識別子であるキャラクター名称３０２、キャラクターが開発対象システム構成要素であるかそうでないかを示すためのキャラクター種別３０３、０個以上の属性３０４、及び０個以上のメッセージ３０７から構成される。 属性３０４は、識別子である属性名称３０５及び属性値３０６から構成される。 メッセージ３０７は、識別子であるメッセージ名称３０８から構成される。 属性名称３０５は、１つのキャラクター情報において一意である。 また、メッセージ名称３０８も、１つのキャラクター情報において一意である。

【００１８】本実施の形態では、キャラクターが開発対象システム構成要素であるか否かの区別は、特別な文字列がキャラクター種別３０３に格納されているか否で行う。 本実施の形態では、文字列“Ａｃｔｏｒ”を特別な文字列として用いることとする。

【００１９】図５に、シナリオ情報記憶部１０６に格納されるシナリオ情報４０１の詳細を示す。 シナリオ情報４０１は、シナリオの識別子であるシナリオ名称４０
２、シナリオを構成するキャラクターの一覧を示すシナリオ内キャラクター情報一覧４０３、及びシナリオを構成するシーンを表す０個以上のシーン情報４０６から構成される。

【００２０】シナリオ内キャラクター情報一覧４０３には、キャラクター名称４０４及び座標４０５が格納される。 キャラクター名称４０４は、キャラクター情報記憶部１０６に格納されたキャラクター情報のうち同一名称のものを指し示す。 要求仕様モデル作成プログラム２０
１及びシナリオ情報解析・生成部１０８などにおいてキャラクター名称４０４が指し示すキャラクター情報を取得する場合は、キャラクター情報記憶部１０６を逐次参照し、キャラクター名称４０４とキャラクター名称３０
２が同一であるか否かをチェックしていき、キャラクター情報３０１を取得する。

【００２１】シーン情報４０６には、メッセージ送信元のキャラクターを表すメッセージ送信キャラクター名称４０７、メッセージ受信先を表すメッセージ受信キャラクター名称４０８、及び送信されたメッセージを表すメッセージ名称４０９が格納される。 メッセージ送信キャラクター名称４０７及びメッセージ受信キャラクター名称４０８もまた、キャラクター情報記憶部１０６に格納されたキャラクター情報のうち同一名称のものを指し示す。 メッセージ名称４０９は、受信キャラクター名称４
０８が指し示すキャラクター情報の中のメッセージのうち同一名称のものを指し示す。

【００２２】なお、シナリオ名称４０２は、シナリオ情報記憶部１０６に格納された全てのシナリオ情報４０１
において一意である。

【００２３】図６は、シナリオ情報４０１とキャラクター情報３０１の関係を具体例を用いて示した関連図である。

【００２４】販売管理システムのシナリオ情報４０１には、シナリオ名称４０２として「販売管理システム」が格納されている。 シナリオ内キャラクター情報一覧４０
３には、キャラクター名称４０４として「業務担当」及び「顧客データベース」が格納されている。 キャラクター名称４０４「業務担当」は、座標（１０,２０）に、
キャラクター名称４０４「顧客データベース」は、座標（２０,２０）にそれぞれ位置する。 シーン情報４０６
には、メッセージ送信キャラクター名称４０７として「業務担当」、メッセージ受信キャラクター名称４０８
として「顧客データベース」、及びメッセージ名称４０
９として「顧客検索」が格納されている。

【００２５】キャラクター情報３０１ａには、キャラクター名称３０２ａとして「業務担当」、キャラクター種別３０３ａとして「Ａｃｔｏｒ」、及びメッセージ３０
７ａが格納されている。 メッセージ３０７ａには、メッセージ名称３０８ａとして「検索結果出力」が格納されている。 もう一つのキャラクター情報３０１ｂには、キャラクター名称３０２ｂとして「顧客データベース」、
キャラクター種別３０３ｂとして「非アクター」、及びメッセージ３０７ｂが格納されている。 メッセージ３０
７ｂには、メッセージ名称３０８ｂとして「顧客検索」
が格納されている。

【００２６】シナリオ内キャラクター情報一覧４０３に格納されたキャラクター名称４０４「業務担当」及びメッセージ送信キャラクター名称４０７は、キャラクター名称３０２ａ「業務担当」を格納するキャラクター情報３０１ａを指し示す。 同様に、キャラクター名称４０４
「顧客データベース」及びメッセージ受信キャラクター名称４０８「顧客データベース」はキャラクター情報３
０１ｂを指し示す。 また、メッセージ名称４０９「顧客検索」は、メッセージ３０７ｂを指し示す。

【００２７】図７は、クラス図情報記憶部１０９の詳細図である。 クラス図情報記憶部１０９には、キャラクター情報から生成して得られたクラス情報６０１が格納される。 クラス情報６０１は、クラスを識別するためのクラス名称６０２、クラスの状態を表すための０個以上の属性６０３、及び０個以上のメッセージ６０６から構成される。 属性６０３は、属性名称６０４及び属性値６０
５から構成される。 メッセージ６０６は、メッセージ名称６０７から構成される。

【００２８】図８は、ユースケース図情報記憶部１１０
の詳細図である。 ユースケース図情報記憶部１１０には、キャラクター情報から生成して得られたアクター情報７０１、シナリオ情報から生成して得られたユースケース情報７１１、及び関連情報７０８が格納される。

【００２９】アクター情報７０１は、アクターを識別するためのアクター名称７０２、アクターの状態を表す０
個以上の属性７０３、及び０個以上のメッセージ７０６
から構成される。 属性７０３は、属性名称７０４及び属性値７０５から構成される。 メッセージ７０６は、メッセージ名称７０７から構成される。

【００３０】ユースケース情報７１１は、識別子であるユースケース名称７１２及びユースケースが持つところのシーケンス図を表すシーケンス図情報７１３から構成される。

【００３１】関連情報７０８は、アクターとユースケースの関連を表すためのもので、関連するアクター名称７
０９及び関連するユースケース名称７１０から構成される。

【００３２】図９は、シーケンス図情報一覧記憶部１１
１の詳細図である。 シーケンス図情報一覧記憶部１１１
はシナリオ情報解析・生成部１０８が生成したシーケンス図情報（但しユースケース情報７１１に含まれるシーケンス図情報は除く）を格納するためのもので、０個以上のシーケンス図情報８０１が格納される。

【００３３】図１０に、図８のシーケンス図情報７１３
及び図９のシーケンス図情報８０１の詳細を示す。 シーケンス図情報記憶部１１１に格納されるシーケンス図情報８０１とユースケース情報７１１に格納されるシーケンス図情報７１３の構成は同じである。 シーケンス図情報７１３、８０１は、シーケンス名称９０１及び０個以上のシーン情報９０２から構成される。 シーン情報９０
２は、メッセージ送信オブジェクト名称９０３、メッセージ受信オブジェクト名称９０４、及びメッセージ名称９０５から構成される。

【００３４】なお、本実施の形態では、ユースケース名称７１２とシーケンス図情報７１３に格納されたシーケンス名称とを同じ名称にしている。 これは、ＵＭＬモデル入力プログラム２０２においてユースケースとシーケンス図の対応関係がより明確にするためである。

【００３５】図１１及び図１２は、シーケンス図情報７
１３とアクター情報７０１、クラス情報６０１との関係、関連情報７０８とアクター情報７０１、ユースケース情報７１１との関係を具体例を用いて示す図である。

【００３６】図１１においてシーケンス図情報７１３のシーケンス名称９０１には、「販売管理システム」が格納される。 シーン情報９０２には、メッセージ送信オブジェクト名称９０３として「業務担当」、メッセージ受信オブジェクト名称９０４として「顧客データベース」、メッセージ名称９０５として「顧客検索」が格納される。 アクター情報７０１には、アクター名称７０２
として「業務担当」が格納される。 メッセージ７０６には、メッセージ名称７０７として「検索結果出力」が格納される。 クラス情報６０１には、クラス名称６０２として「顧客データベース」が格納され、メッセージ６０
６には、メッセージ名称６０７として「顧客検索」が格納される。

【００３７】メッセージ送信オブジェクト名称９０３
「業務担当」は、同一名称のアクター情報７０１を指し示す。 メッセージ受信オブジェクト名称９０４「顧客データベース」は、クラス情報６０１を指し示す。 メッセージ９０５「顧客検索」は、メッセージ６０６を指し示す。

【００３８】図１２において関連情報７０８中の関連するアクター名称７０９「業務担当」は、アクター情報７
０１「業務担当」を指し示す。 また、関連するユースケース名称７１０「販売管理システム」は、ユースケース情報７１１「販売管理システム」を指し示す。 ユースケース情報７１１のユースケース名称７１２「販売管理システム」とシーケンス図情報７１３のシーケンス名称９
０１「販売管理システム」は同一である。

【００３９】以下、本実施の形態における要求仕様モデルファイルからＵＭＬモデルファイルへの変換処理（要求仕様モデル変換処理）について説明する。

【００４０】図１３は、処理装置１０２における要求仕様モデル変換処理の流れを示すフローチャートである。

【００４１】まず、要求仕様モデルファイル入力部１０
４は、入力記憶装置１０１に格納された要求仕様モデルファイル１９０１を入力し、要求仕様モデルファイル１
９０１からキャラクター情報１９０２を抽出し、キャラクター情報記憶部１０５にキャラクター情報３０１として格納する。 同様に、要求仕様モデルファイル１９０１
から抽出されるシナリオ情報１９１１は、シナリオ情報記憶部１０６にシナリオ情報４０１として格納される（ステップ１２０１）。

【００４２】次に、キャラクター情報解析・生成部１０
７は、キャラクター情報記憶部１０５に格納されたキャラクター情報３０１を参照し、クラス情報６０１、またはアクター情報７０１のいずれかを生成する。 クラス情報６０１を生成した場合、キャラクター情報解析・生成部１０７は、生成したクラス情報６０１をクラス図情報記憶部１０９に格納する。 一方、アクター情報７０１を生成した場合、キャラクター情報解析・生成部１０７
は、生成したアクター情報７０１をユースケース図情報記憶部１１０に格納する（ステップ１２０２）。

【００４３】次に、シナリオ情報解析・生成部１０８
は、シナリオ情報記憶部１０６に格納されたシナリオ情報４０１を元に、シーケンス図情報８０１の生成してシーケンス図情報一覧記憶部１１１への格納するか、あるいは、ユースケース情報７１１及び関連情報７０８を生成してユースケース図情報記憶部１１０へ格納する。 このステップでは、シーケンス図情報８０１とユースケース情報７１１のいずれか一方が生成される（ステップ１
２０３）。

【００４４】次に、ＵＭＬモデルファイル出力部１１２
は、クラス図情報記憶部１０９に格納されたクラス情報１０９、ユースケース図情報記憶部１１０に格納されたアクター情報７０１、ユースケース情報７１１、及び関連情報７０８、並びに、シーケンス図情報一覧記憶部１
１１に格納されたシーケンス図情報８０１を統合してＵ
ＭＬモデルファイルを生成し、出力記憶装置１０３に出力する（ステップ１２０４）。

【００４５】図１４は、ステップ１２０２の詳細なフローチャートである。

【００４６】ステップ１２０２では、まず、キャラクター情報記憶部１０５に格納されたキャラクター情報３０
１を逐次取得するため、キャラクター情報取得位置ポインタをキャラクター情報記憶部１０５の先頭位置に設定する（ステップ１３０１）。

【００４７】次に、キャラクター情報解析・生成部１０
７は、キャラクター情報取得位置ポインタで示されるキャラクター情報記憶部１０５の記憶位置にキャラクター情報３０１があるかどうかを調べる（ステップ１３０
２）。 キャラクター情報が無ければ、キャラクター情報解析・生成部１０７は、ステップ１２０２の処理を終了する。 キャラクター情報がある場合は、キャラクター情報解析・生成部１０７は、そのキャラクター情報３０１
を取得する（ステップ１３０３）。

【００４８】次に、キャラクター情報解析・生成部１０
７はキャラクター情報３０１のキャラクター種別３０３
を参照し、文字列“Ａｃｔｏｒ”の有無を調べる（ステップ１３０４）。 文字列“Ａｃｔｏｒ”がある場合、キャラクター情報解析・生成部１０７は、キャラクター情報３０１を元にアクター情報７０１を生成し、ユースケース図情報記憶部１１０に格納する。 具体的には、キャラクター情報解析・生成部１０７は、キャラクター情報記憶部１０５に格納されたキャラクター情報３０１からキャラクター名称３０２を取得し、アクター名称７０２
として格納する。 キャラクター情報３０１から属性名称３０５及び属性値３０６を取得し、アクター情報７０１
の属性名称７０４及び属性値７０５として格納する。 また、キャラクター情報３０１からメッセージ名称３０８
を取得し、アクター情報７０１のメッセージ名称７０７
として格納する（ステップ１３０５）。

【００４９】ステップ１３０４で文字列”Ａｃｔｏｒ”
がないと判断した場合、キャラクター情報解析・生成部１０７は、キャラクター情報３０１を元にクラス情報６
０１を生成し、クラス図情報記憶部１０９に格納する。
すなわち、キャラクター情報解析・生成部１０７は、キャラクター情報記憶部１０５に格納されたキャラクター情報３０１からキャラクター名称３０２を取得し、クラス名称６０２として格納する。 キャラクター情報３０１
から属性名称３０５及び属性値３０６を取得し、クラス情報６０１の属性名称６０４及び属性値６０５として格納する。 キャラクター情報３０１からメッセージ名称３
０８を取得し、クラス情報６０１のメッセージ名称６０
７として格納する（ステップ１３０６）。

【００５０】クラス情報６０１又はアクター情報７０１
を生成したら、キャラクター情報解析・生成部１０７
は、次のキャラクター情報３０１を取得するため、キャラクター情報取得位置ポインタをキャラクター情報１個分進める（ステップ１３０７）。 そして、キャラクター情報解析・生成部１０７は、ステップ１３０２、ステップ１３０３、ステップ１３０４、ステップ１３０５またはステップ１３０６、及びステップ１３０７を、全てのキャラクター情報を取得するまで繰り返す。

【００５１】図１５は、ステップ１２０３の詳細なフローチャートである。

【００５２】ステップ１２０３でシナリオ情報解析・生成部１０８は、まず、シナリオ情報記憶部１０６に格納されたシナリオ情報４０１を逐次取得するため、シナリオ情報取得位置ポインタにシナリオ情報記憶部１０６の先頭位置を設定する（ステップ１４０１）。

【００５３】次に、シナリオ情報解析・生成部１０８
は、シナリオ情報取得位置ポインタで示されるシナリオ情報記憶部１０６の記憶位置にシナリオ情報４０１があるかどうかを調べ、シナリオ情報４０１がなければステップ１２０３の処理を終了する（ステップ１４０２）。
シナリオ情報４０１があれば、シナリオ情報解析・生成部１０８は、そのシナリオ情報４０１を取得する（ステップ１４０３）。

【００５４】次に、シナリオ情報解析・生成部１０８
は、シナリオ情報４０１を元にシーケンス図情報８０１
を生成してシーケンス図情報一覧記憶部１１１へ格納するか、または、ユースケース情報７１１を生成してユースケース図情報記憶部１１０へ格納する（ステップ１４
０４）。

【００５５】続いて、シナリオ情報解析・生成部１０８
は、シナリオ情報取得位置ポインタをシナリオ情報１個分進める（ステップ１４０５）。 その後、シナリオ情報解析・生成部１０８は、ステップ１４０２、１４０３、
１４０４、及び１４０５の処理を、シナリオ情報記憶部１０６に格納された全てのシナリオ情報を参照し終えるまで行う。

【００５６】図１６は、ステップ１４０４の詳細なフローチャートである。

【００５７】ステップ１４０４でシナリオ情報解析・生成部１０８は、まず、シナリオ情報４０１中のシナリオ内キャラクター情報一覧４０３に格納された全てのキャラクター名称を取得するため、キャラクター名称取得位置ポインタに、そのシナリオ情報４０１内のシナリオ内キャラクター情報一覧４０３の先頭位置を設定する（ステップ１５０１）。

【００５８】シナリオ情報解析・生成部１０８は、キャラクター名称取得位置ポインタで示される位置にキャラクター名称４０４があるかどうかを調べる（ステップ１
５０２）。 キャラクター名称４０４がある場合、シナリオ情報解析・生成部１０８は、キャラクター名称４０４
を取得する（ステップ１５０３）。

【００５９】次に、シナリオ情報解析・生成部１０８
は、キャラクター情報記憶部１０５を先頭から逐次参照し、キャラクター名称４０４と同一名称のキャラクター情報３０１を取得する（ステップ１５０４）。

【００６０】続いて、シナリオ情報解析・生成部１０８
は、キャラクター情報３０１中のキャラクター種別３０
３を調べ、文字列“Ａｃｔｏｒ”の有無を調べる（ステップ１５０５）。

【００６１】文字列“Ａｃｔｏｒ”がある場合、シナリオ情報解析・生成部１０８は、ユースケース情報７１１
を生成し、ユースケース図情報記憶部１１０に格納する。 この処理において、シナリオ情報解析・生成部１０
８は、シナリオ情報記憶部１０６に格納されたシナリオ情報４０１からシナリオ名称を４０２取得し、ユースケース名称７１２としてユースケース情報７１１に格納する。 そして、次のようにしてシナリオ情報４０１からシーケンス図情報７１３を生成し、ユースケース情報７１
１に格納する。 まず、シナリオ情報解析・生成部１０８
は、シナリオ名称４０２をシーケンス名称９０１として格納する。 シナリオ情報４０１の各シーン情報４０６からメッセージ送信キャラクター名称４０７、メッセージ受信キャラクター名称４０８、及びメッセージ名称４０
９を取得し、それぞれメッセージ送信オブジェクト名称９０３、メッセージ受信オブジェクト名称９０４及びメッセージ名称９０５として格納してシーン情報９０２を生成する（ステップ１５０７）。 この後、シナリオ情報解析・生成部１０８は、関連情報７０８を生成する（ステップ１５０８）。

【００６２】ステップ１５０５で文字列“Ａｃｔｏｒ”
がみつからなかった場合、シナリオ情報解析・生成部１
０８は、次のキャラクター名称４０４を取得するためキャラクター名称取得位置ポインタを進める（ステップ１
５０６）。

【００６３】シナリオ情報解析・生成部１０８は、ステップ１５０２以降の処理をシナリオ内キャラクター情報一覧に格納された全てのキャラクター名称４０４を参照し終えるか、またはキャラクター名称４０４が指し示すキャラクター情報３０１のうち、キャラクター種別３０
３に文字列“Ａｃｔｏｒ”を持つものを見つけるまで行う。

【００６４】ステップ１５０２においてキャラクター名称取得位置ポインタで示される位置にキャラクター名称４０４がない場合、すなわち、全てのキャラクター名称４０４について、文字列“Ａｃｔｏｒ”がなかったとき、シナリオ情報解析・生成部１０８は、シーケンス図情報８０１を生成し、シーケンス図情報一覧記憶部１１
１に格納する。 この処理でシナリオ情報解析・生成部１
０８は、シナリオ名称４０２をシーケンス名称９０１として格納する。 そして、シナリオ情報４０１の各シーン情報４０６からメッセージ送信キャラクター名称４０
７、メッセージ受信キャラクター名称４０８、及びメッセージ名称４０９を取得し、それぞれメッセージ送信オブジェクト名称９０３、メッセージ受信オブジェクト名称９０４及びメッセージ名称９０５として格納してシーン情報９０２を生成する（ステップ１５０９）。

【００６５】図１７は、ステップ１５０８における関連情報の生成処理の詳細なフローチャートである。

【００６６】シナリオ情報解析・生成部１０８は、１個のシナリオ情報４０１中のシナリオ内キャラクター情報一覧４０３に格納された全てのキャラクター名称４０４
を取得するため、キャラクター名称取得位置ポインタに、シナリオ内キャラクター情報一覧４０３の先頭位置を設定する（ステップ１６０１）。

【００６７】次に、シナリオ情報解析・生成部１０８
は、キャラクター取得位置にキャラクター名称があるかどうかを調べ、キャラクター名称がなければこの処理を終了する（ステップ１６０２）。

【００６８】キャラクター名称があれば、シナリオ情報解析・生成部１０８は、シナリオ内キャラクター情報一覧４０３に格納されたキャラクター名称４０４を取得する（ステップ１６０３）。 そして、シナリオ情報解析・
生成部１０８は、キャラクター情報記憶部１０５を先頭から逐次参照し、取得したキャラクター名称４０４と同一名称のキャラクター情報３０１を取得する（ステップ１６０３）。

【００６９】次に、シナリオ情報解析・生成部１０８
は、取得したキャラクター情報が持つキャラクター種別３０３に文字列“Ａｃｔｏｒ”があるかどうかを調べる（ステップ１６０５）。 文字列“Ａｃｔｏｒ”がある場合、シナリオ情報解析・生成部１０８は、キャラクター名称３０２を関連するアクター名称７０９として、シナリオ名称４０２を関連するユースケース名称７１０として関連情報７０８を生成し、ユースケース図情報記憶部１１０に格納する（ステップ１６０６）。 ステップ１６
０５においてキャラクター種別３０３に文字列“Ａｃｔ
ｏｒ”がなかった場合、ステップ１６０６の処理は、スキップされる。

【００７０】次のキャラクター名称をシナリオ内キャラクター情報一覧から取得するため、キャラクター名称取得位置ポインタを進める（ステップ１６０７）。 以後、
ステップ１６０２以降の処理が、シナリオ内キャラクター情報一覧に格納された全てのキャラクター名称を参照し終えるまで繰り返される。

【００７１】図１８は、要求仕様作成プログラム２０１
で作成した要求仕様モデルの具体例である。

【００７２】キャラクターの一覧１７０１は、要求仕様モデルに属する全てのキャラクターを表示するためのものである。 この例では、要求仕様モデルには、キャラクター業務担当１７０２及びキャラクター顧客データベース１７０３が属している。 業務担当１７０２の詳細な情報は１７０４に表示される。 また、顧客データベース１
７０３の詳細な情報は１７０５に表示される。

【００７３】シナリオ販売管理システム１７０６には、
キャラクター業務担当１７０２及びキャラクター１７０
３「顧客データベース」が登場する。 １７０２及び１７
０３は、シナリオ販売管理システム１７０６を構成するシーンである。 シーン１７０７において、キャラクター１７０２「業務担当」からキャラクター１７０３「顧客データベース」に対してメッセージ「顧客検索」が渡される。 同様に、シーン１７０８において、キャラクター１７０３「顧客データベース」からキャラクター１７０
２「業務担当」に対してメッセージ「検索結果出力」が渡される。

【００７４】図１９は、図１８に示す要求仕様モデルを、処理装置１０２により変換して得たＵＭＬモデルである。

【００７５】キャラクター１７０３「顧客データベース」は、キャラクター種別に“Ａｃｔｏｒ”を持たないためクラス１８０２に変換される。 クラスは、クラス図１８０１に配置される。

【００７６】キャラクター１７０２「業務担当」はキャラクター種別に文字列“Ａｃｔｏｒ”を持つため、アクター１８０４に変換され、ユースケース図１８０３に配置される。

【００７７】シナリオ販売管理システム１７０６には、
キャラクター種別に“Ａｃｔｏｒ”を持つキャラクター１７０２である「業務担当」が登場するため、ユースケース１８０５に変換され、ユースケース図１８０３に配置される。 ユースケース１８０５はシーケンス図１８０
６を持つ。

【００７８】以上説明した実施の形態によれば、要求仕様モデルを他の形式のモデルに変換する際に、キャラクターやシナリオが他の形式モデル要素の生成対象であるかどうかを判定し、モデル要素の生成をおこなうので、
要求仕様モデルから他形式モデルに変換する時に、変換される他の形式モデルにおいて必要のない要素を生成することがなく、必要な他形式モデルの要素のみを生成することのできる。 このため、変換処理後に、生成された他の形式モデルにおいて不必要なの要素を削除するといった手間を省くことができる。

【００７９】

【発明の効果】以上説明したように、本発明によれば、
要求仕様モデルから他形式モデルへの変換時に、変換後のモデルで必要となる要素のみを生成することが可能となる。

【図面の簡単な説明】

【図１】本発明の実施の形態において要求仕様モデル変換処理を行うためのシステムの概略構成図である。

【図２】要求仕様モデル・他形式モデル変換プログラムと外部プログラムの連携を示す概略図である。

【図３】入力記憶装置に格納された要求仕様モデルファイルの詳細図である。

【図４】キャラクター情報記憶部の詳細図である。

【図５】シナリオ情報記憶部の詳細図である。

【図６】シナリオ情報とキャラクター情報の関係を示す関連図である。

【図７】クラス図情報記憶部の詳細図である。

【図８】ユースケース図情報記憶部の詳細図である。

【図９】シーケンス図情報一覧記憶部の詳細図である。

【図１０】シーケンス図情報の詳細図である。

【図１１】シーケンス図情報とクラス情報及びアクター情報との関係を示した情報関連図である。

【図１２】関連情報と、アクター情報及びユースケース情報との間の関係を示した情報関連図である。

【図１３】要求仕様モデル変換処理の概要を示すフローチャートである。

【図１４】クラス情報／アクター情報生成処理の詳細なフローチャートである。

【図１５】シーケンス図情報、またはユースケース情報及び関連情報生成処理の詳細なフローチャートである。

【図１６】シーケンス図情報、またはユースケース情報及び関連情報生成の詳細なフローチャートである。

【図１７】関連情報生成処理の詳細なフローチャートである。

【図１８】要求仕様モデル作成プログラムで作成した要求仕様モデルの説明図である。

【図１９】要求仕様モデル変換処理により変換して得られたＵＭＬモデルの説明図である。

【符号の説明】

１０１…入力記憶装置 １０２…処理装置 １０３…出力記憶装置 １０４…要求仕様モデルファイル入力部 １０５…キャラクター情報記憶部 １０６…シナリオ情報記憶部 １０７…キャラクター情報解析・生成部 １０８…シナリオ情報解析・生成部 １０９…クラス図情報記憶部 １１０…ユースケース図情報記憶部 １１１…シーケンス図情報記憶部 １１２…ＵＭＬモデルファイル出力部

───────────────────────────────────────────────────── フロントページの続き (72)発明者 佐藤 和宏 宮城県仙台市青葉区一番町二丁目４番１号 日立東北ソフトウェア株式会社内 (72)発明者 森田 真理 神奈川県川崎市幸区鹿島田890番地 株式 会社日立製作所情報システム事業部内 (72)発明者 橘 昌宏 神奈川県横浜市都筑区加賀原二丁目２番 株式会社日立製作所ビジネスシステム開発 センタ内 (72)発明者 湯浦 克彦 神奈川県横浜市都筑区加賀原二丁目２番 株式会社日立製作所ビジネスシステム開発 センタ内