JP3716091B2

JP3716091B2 - Requirement specification model / other format model conversion apparatus and method

Info

Publication number: JP3716091B2
Application number: JP03836198A
Authority: JP
Inventors: 宣郎森山; 直樹五十嵐; 和宏佐藤; 真理森田; 昌宏橘; 克彦湯浦
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1998-02-20
Filing date: 1998-02-20
Publication date: 2005-11-16
Anticipated expiration: 2018-02-20
Also published as: JPH11237979A

Description

【０００１】
【発明の属する技術分野】
本発明は、システム開発対象業務を構成する構成要素に関する構成要素情報と、構成要素内、または、構成要素間の手続の起動連鎖を記録した手続連鎖情報を保持するシナリオとによって定義された要求仕様モデルを他の形式のモデルに変換する要求仕様モデル・他形式モデル変換装置及びその変換方法に関する。
【０００２】
【従来の技術】
システム開発における要求仕様定義のための技術として、例えば、特開平９−８１６１１号公報に記載されるように、対象業務を構成する要素であるキャラクターを定義し、キャラクターに持たせるデータや手続きを使って実世界の業務をシーンと呼ばれるシナリオの断片的な具体例として入力していくことで要求仕様を定義していく技術がある。ここでいうキャラクターとは、要求仕様中に出てくる「人」や具体的な「物」、その他概念的な「抽象物」である。キャラクターは、その名称、そのイメージを表現する表示図形情報、保持する内部データ情報と内部手続情報を持っている。キャラクターが保持する内部データ情報を属性といい、キャラクターが保持する内部手続情報をメッセージと言う。また、シナリオとは、要求仕様の断片的な具体例である。シナリオは、シーン及びそのシナリオに登場するキャラクタに関する情報を構成要素として持つ。シーンとは、キャラクター間の内部手続きの起動連鎖のことである。
【０００３】
要求仕様定義技術で定義した要求仕様モデルファイルを、他形式のモデルファイルを扱うプログラムで利用できるように変換する技術として、要求仕様モデル・他形式モデル変換技術がある。要求仕様モデル・他形式モデル変換技術とは、上述したような要求仕様定義プログラムにより定義した要求仕様モデルのファイルを、別のプログラムが入力するための他の形式のモデルファイルのデータ形式に合せて変換し、そのプログラムが入力して編集し、表示装置に表示できるようにする技術である。近年、これらの技術を適用したソフトウェア製品が実現されつつある。
【０００４】
【発明が解決しようとする課題】
上述したような従来の要求仕様モデル・他形式モデル変換装置では、要求仕様モデルを構成するキャラクター及びシナリオが全て他形式モデルの要素として変換されていた。そのため、要求仕様モデルから他形式モデルへ変換した後、不必要な他の形式モデルの要素を削除しなければならないといった問題があった。
【０００５】
本発明の目的は、要求仕様モデルから他形式モデルに変換する時に、必要な他形式モデルの要素のみを生成することのできる要求仕様モデル・他形式モデル変換装置を提供することにある。
【０００６】
【課題を解決するための手段】
上記目的を達成するために、本発明による要求仕様モデル・他形式モデル変換装置及び変換方法は、システム開発対象業務を構成する構成要素が保持する名称、データ名称及び手続き名称を記録した構成要素情報と、構成要素間の手続きの起動連鎖を記録した手続き起動連鎖情報、または構成要素内の手続きの起動連鎖を記録した手続き起動連鎖情報を保持するシナリオとによって定義された要求仕様モデルを他の形式のモデルに変換する要求仕様モデル・他形式モデル変換装置及び変換方法において、コンピュータ読み取り可能な記憶装置に格納され、要求仕様モデルからなる要求仕様モデルファイルを要求仕様モデルファイル入力手段から読み込む。要求仕様モデルファイル入力手段が入力した要求仕様モデルファイルから得られる構成要素情報、構成要素が他形式モデルの要素となるか否かの判断材料となる構成要素種別を構成要素情報記憶手段に記憶する。また、要求仕様モデルファイル入力手段が入力した要求仕様モデルファイルから得られるシナリオをシナリオ情報記憶手段に記憶する。構成要素情報解析・生成手段は、構成要素情報記憶手段に格納された構成要素情報を基に、構成要素種別から構成要素が他形式モデルの要素となるか否かを判断し、他形式モデルの要素を生成する。シナリオ情報解析・生成手段は、シナリオ情報記憶手段に格納されたシナリオを基に、他形式モデルの要素を生成する。構成要素情報解析・生成手段、及びシナリオ解析・生成手段により生成された他形式モデルの要素は、他形式モデルファイル出力手段により統合され、コンピュータ書込み可能な記憶装置に格納される。
【０００７】
本発明による要求仕様モデル・他形式モデル変換装置は、他の観点によれば、コンピュータ読み取り可能な記憶装置に格納された要求仕様モデルファイルを読み込む要求仕様モデルファイル入力手段と、要求仕様モデルファイル入力手段より受け取ったキャラクター情報である、キャラクターを識別するキャラクター識別子、キャラクターの状態を表す値を格納する属性及びキャラクターの実行可能な動作を表すメッセージなどを記憶し、かつキャラクターが他形式モデルの要素となるか否かの判断材料となるキャラクター種別を記憶するキャラクター情報記憶手段と、要求仕様モデルファイル入力手段より受け取ったシナリオ情報である、シナリオを識別するシナリオ識別子、シナリオに登場するキャラクターを示すキャラクター識別子及びシナリオを構成するシーンなどを記憶するシナリオ情報記憶手段と、キャラクター情報記憶手段より取り出したキャラクター情報を基に、キャラクター種別からキャラクターが他形式モデルの要素となるか否かを判断し、他形式モデルの要素を生成するキャラクター情報解析・生成手段と、シナリオ情報記憶手段より取り出したシナリオ情報を基に、他形式モデルの要素を生成するシナリオ情報解析・生成手段と、キャラクター情報解析・生成手段及びシナリオ情報解析・生成手段より受け取った他形式モデルの要素を統合し、コンピュータ書込み可能な記憶装置に格納する他形式モデルファイル出力手段を備えることを特徴とする。
【０００８】
【発明の実施の形態】
図１は、本実施の形態において要求仕様モデル変換処理を行う電子計算機の構成図である。本実施例では、要求仕様モデルを、オブジェクト指向モデル化技法であるＵＭＬ（Unified Modeling Language）が扱う形式であるＵＭＬモデルに変換する。分析・設計手法である。ＵＭＬに関する技術としては、例えば、Terry Quatrani, "Visual Modeling with Rational Rose", ISBN:0-201-31016-3に記載された技術が知られている。
【０００９】
ＵＭＬは、クラスやクラス間の関係を表現するクラス図、オブジェクト間の手続きであるシーンを時系列的な流れとして表現するシーケンス図、及びシステムの外部インタフェースを表現するユースケース図などの図によりモデルを表現する。ＵＭＬモデルの構成要素には、開発対象システムを構成する要素であるオブジェクトやオブジェクトの集合であるクラスの他に、例えば、ユーザや既存システムなどのシステム外部にあり、システムと情報交換を行うアクターや、アクターに対してシステムが何を行うかを示すためのものであるユースケースなどといったものがある。
【００１０】
図１において、処理装置１０２は、パーソナルコンピュータ、あるいはワークステーションなどの計算機である。処理装置１０２の主記憶装置又は処理装置１０２に接続される外部記憶装置上には、キャラクター情報を構成する要素であるキャラクターを識別するキャラクター名称、キャラクターの状態を表す値を格納する属性、及びキャラクターの実行可能な動作を表すメッセージを記憶し、かつキャラクターが他形式モデルの要素となるか否かの判断材料となるキャラクター種別を記憶するキャラクター情報記憶部１０５、シナリオ情報を構成する要素であるシナリオを識別するシナリオ識別子、シナリオに登場するキャラクターを示すキャラクター識別子、及びシナリオを構成するシーンを記憶するシナリオ情報記憶部１０６、キャラクター情報解析・生成部１０７が生成したクラス情報を記憶するクラス図情報記憶部１０９、キャラクター情報解析・生成部１０７が生成したアクター情報、シナリオ情報解析・生成部１０８が生成したユースケース情報及び関連情報を記憶するユースケース図情報記憶部１１０、及びシナリオ情報解析・生成部１０８が生成したシーケンス図情報を記憶するシーケンス図情報一覧記憶部１１１の各記憶部が設けられる。
【００１１】
処理装置１０２は、その機能として、コンピュータ読み取り可能な入力記憶装置１０１に格納された要求仕様モデルファイルを読み込む要求仕様モデルファイル入力部１０４、キャラクター情報記憶部１０５より取り出したキャラクター情報を基に、キャラクター種別からキャラクターがＵＭＬモデルの要素であるクラスとなるかアクターとなるかを判断し、ＵＭＬモデルのクラス情報又はアクター情報を生成するキャラクター情報解析・生成部１０７、シナリオ情報記憶部１０６より取り出したシナリオ情報を基に、ＵＭＬモデルのシーケンス図を生成するかまたはユースケース及び関連を生成するかを判断し、シーケンス図情報又はユースケース情報及び関連情報を生成するシナリオ情報解析・生成部１０８、及びクラス図情報記憶部１０９、ユースケース図情報記憶部１１０、及びシーケンス図情報一覧記憶部１１１より受け取ったＵＭＬモデルの要素を統合し、コンピュータ書込み可能な出力記憶装置１０３に格納するＵＭＬモデルファイル出力部１１２の各処理部を有する。これらの処理部は、具体的には、処理装置１０２の主記憶装置、又は処理装置１０２に接続される外部記憶装置上に格納され、本実施の形態における要求仕様モデル・他形式モデル変換プログラムを構成するプログラムモジュールであり、処理装置１０２によって実行されることによりその機能が実現される。
【００１２】
図２は、外部プログラムである要求仕様モデル作成プログラム２０１、処理装置１０１により実行される要求仕様モデル・他形式モデル変換プログラム２０２、及び外部プログラムであるＵＭＬモデル入力プログラム２０３を接続し、要求仕様モデルファイル生成からＵＭＬモデルファイル生成までを行う手順を示した図である。要求仕様モデル作成プログラム２０１は、要求仕様モデルファイルを生成するためのプログラムである。入力記憶装置１０１には、要求仕様モデル作成プログラム２０１が作成した要求仕様モデルファイルが格納される。要求仕様モデル・他形式モデル変換プログラム２０２は、入力記憶装置１０１に格納された要求仕様モデルファイルをＵＭＬモデルファイルに変換し、出力記憶装置１０３に格納する。出力記憶装置１０３に格納されたＵＭＬモデルファイルは、別の外部プログラムであるＵＭＬモデル入力プログラム２０２が入力する。
【００１３】
図３に、入力記憶装置１０１に格納された要求仕様モデルファイルの詳細を示す。
【００１４】
要求仕様モデルファイル１９０１は、開発対象業務の構成要素であるキャラクターの情報を保持するキャラクター情報１９０２及び対象業務の具体例であるシナリオの情報を保持するシナリオ情報から構成される。
【００１５】
キャラクター情報１９０２は、識別子であるキャラクター名称１９０３、キャラクター種別１９０４、キャラクターの内部データを表わす属性１９０５、及びキャラクターの内部手続きであるメッセージ１９０８を有している。属性１９０５は、識別子である属性名称１９０６及びデータ値を表わす属性値１９０７から構成される。メッセージ１９０８は、識別子であるメッセージ名称１９１０から構成される。
【００１６】
シナリオ情報１９１１は、識別子であるシナリオ名称１９１２、シナリオを構成するキャラクターの一覧を表わすシナリオ内キャラクター情報一覧１９１３、及びシナリオ内でのキャラクター間の手続きの起動連鎖を表わすシーン情報１９１６から構成される。シナリオ内キャラクター情報一覧１９１３は、キャラクター名称１９１４及びシナリオ上での配置位置を示す座標１９１５の対のリストである。シーン情報１９１６は、メッセージ送信により手続きの起動を要求するところのキャラクターを表わすメッセージ送信キャラクター名称１９１７、メッセージを受け取り手続きの起動を行なうところのキャラクターを表わすメッセージ受信キャラクター名称１９１８及び起動される手続きを表わすメッセージ名称１９１９から構成される。
【００１７】
図４に、キャラクター情報記憶部１０５に格納されるキャラクター情報３０１の詳細を示す。キャラクター情報記憶部１０５には、キャラクター情報３０１が格納される。キャラクター情報３０１は、キャラクターの識別子であるキャラクター名称３０２、キャラクターが開発対象システム構成要素であるかそうでないかを示すためのキャラクター種別３０３、０個以上の属性３０４、及び０個以上のメッセージ３０７から構成される。属性３０４は、識別子である属性名称３０５及び属性値３０６から構成される。メッセージ３０７は、識別子であるメッセージ名称３０８から構成される。属性名称３０５は、１つのキャラクター情報において一意である。また、メッセージ名称３０８も、１つのキャラクター情報において一意である。
【００１８】
本実施の形態では、キャラクターが開発対象システム構成要素であるか否かの区別は、特別な文字列がキャラクター種別３０３に格納されているか否で行う。本実施の形態では、文字列“Ａｃｔｏｒ”を特別な文字列として用いることとする。
【００１９】
図５に、シナリオ情報記憶部１０６に格納されるシナリオ情報４０１の詳細を示す。シナリオ情報４０１は、シナリオの識別子であるシナリオ名称４０２、シナリオを構成するキャラクターの一覧を示すシナリオ内キャラクター情報一覧４０３、及びシナリオを構成するシーンを表す０個以上のシーン情報４０６から構成される。
【００２０】
シナリオ内キャラクター情報一覧４０３には、キャラクター名称４０４及び座標４０５が格納される。キャラクター名称４０４は、キャラクター情報記憶部１０６に格納されたキャラクター情報のうち同一名称のものを指し示す。要求仕様モデル作成プログラム２０１及びシナリオ情報解析・生成部１０８などにおいてキャラクター名称４０４が指し示すキャラクター情報を取得する場合は、キャラクター情報記憶部１０６を逐次参照し、キャラクター名称４０４とキャラクター名称３０２が同一であるか否かをチェックしていき、キャラクター情報３０１を取得する。
【００２１】
シーン情報４０６には、メッセージ送信元のキャラクターを表すメッセージ送信キャラクター名称４０７、メッセージ受信先を表すメッセージ受信キャラクター名称４０８、及び送信されたメッセージを表すメッセージ名称４０９が格納される。メッセージ送信キャラクター名称４０７及びメッセージ受信キャラクター名称４０８もまた、キャラクター情報記憶部１０６に格納されたキャラクター情報のうち同一名称のものを指し示す。メッセージ名称４０９は、受信キャラクター名称４０８が指し示すキャラクター情報の中のメッセージのうち同一名称のものを指し示す。
【００２２】
なお、シナリオ名称４０２は、シナリオ情報記憶部１０６に格納された全てのシナリオ情報４０１において一意である。
【００２３】
図６は、シナリオ情報４０１とキャラクター情報３０１の関係を具体例を用いて示した関連図である。
【００２４】
販売管理システムのシナリオ情報４０１には、シナリオ名称４０２として「販売管理システム」が格納されている。シナリオ内キャラクター情報一覧４０３には、キャラクター名称４０４として「業務担当」及び「顧客データベース」が格納されている。キャラクター名称４０４「業務担当」は、座標（１０,２０）に、キャラクター名称４０４「顧客データベース」は、座標（２０,２０）にそれぞれ位置する。シーン情報４０６には、メッセージ送信キャラクター名称４０７として「業務担当」、メッセージ受信キャラクター名称４０８として「顧客データベース」、及びメッセージ名称４０９として「顧客検索」が格納されている。
【００２５】
キャラクター情報３０１ａには、キャラクター名称３０２ａとして「業務担当」、キャラクター種別３０３ａとして「Ａｃｔｏｒ」、及びメッセージ３０７ａが格納されている。メッセージ３０７ａには、メッセージ名称３０８ａとして「検索結果出力」が格納されている。もう一つのキャラクター情報３０１ｂには、キャラクター名称３０２ｂとして「顧客データベース」、キャラクター種別３０３ｂとして「非アクター」、及びメッセージ３０７ｂが格納されている。メッセージ３０７ｂには、メッセージ名称３０８ｂとして「顧客検索」が格納されている。
【００２６】
シナリオ内キャラクター情報一覧４０３に格納されたキャラクター名称４０４「業務担当」及びメッセージ送信キャラクター名称４０７は、キャラクター名称３０２ａ「業務担当」を格納するキャラクター情報３０１ａを指し示す。同様に、キャラクター名称４０４「顧客データベース」及びメッセージ受信キャラクター名称４０８「顧客データベース」はキャラクター名称３０２ｂを指し示す。また、メッセージ名称４０９「顧客検索」は、メッセージ３０７ｂを指し示す。
【００２７】
図７は、クラス図情報記憶部１０９の詳細図である。クラス図情報記憶部１０９には、キャラクター情報から生成して得られたクラス情報６０１が格納される。クラス情報６０１は、クラスを識別するためのクラス名称６０２、クラスの状態を表すための０個以上の属性６０３、及び０個以上のメッセージ６０６から構成される。属性６０３は、属性名称６０４及び属性値６０５から構成される。メッセージ６０６は、メッセージ名称６０７から構成される。
【００２８】
図８は、ユースケース図情報記憶部１１０の詳細図である。ユースケース図情報記憶部１１０には、キャラクター情報から生成して得られたアクター情報７０１、シナリオ情報から生成して得られたユースケース情報７１１、及び関連情報７０８が格納される。
【００２９】
アクター情報７０１は、アクターを識別するためのアクター名称７０２、アクターの状態を表す０個以上の属性７０３、及び０個以上のメッセージ７０６から構成される。属性７０３は、属性名称７０４及び属性値７０５から構成される。メッセージ７０６は、メッセージ名称７０７から構成される。
【００３０】
ユースケース情報７１１は、識別子であるユースケース名称７１２及びユースケースが持つところのシーケンス図を表すシーケンス図情報７１３から構成される。
【００３１】
関連情報７０８は、アクターとユースケースの関連を表すためのもので、関連するアクター名称７０９及び関連するユースケース名称７１０から構成される。
【００３２】
図９は、シーケンス図情報一覧記憶部１１１の詳細図である。シーケンス図情報一覧記憶部１１１はシナリオ情報解析・生成部１０８が生成したシーケンス図情報（但しユースケース情報７１１に含まれるシーケンス図情報は除く）を格納するためのもので、０個以上のシーケンス図情報８０１が格納される。
【００３３】
図１０に、図８のシーケンス図情報７１３及び図９のシーケンス図情報８０１の詳細を示す。シーケンス図情報記憶部１１１に格納されるシーケンス図情報８０１とユースケース情報７１１に格納されるシーケンス図情報７１３の構成は同じである。シーケンス図情報７１３、８０１は、シーケンス名称９０１及び０個以上のシーン情報９０２から構成される。シーン情報９０２は、メッセージ送信オブジェクト名称９０３、メッセージ受信オブジェクト名称９０４、及びメッセージ名称９０５から構成される。
【００３４】
なお、本実施の形態では、ユースケース名称７１２とシーケンス図情報７１３に格納されたシーケンス名称とを同じ名称にしている。これは、ＵＭＬモデル入力プログラム２０２においてユースケースとシーケンス図の対応関係がより明確にするためである。
【００３５】
図１１及び図１２は、シーケンス図情報７１３とアクター情報７０１、クラス情報６０１との関係、関連情報７０８とアクター情報７０１、ユースケース情報７１１との関係を具体例を用いて示す図である。
【００３６】
図１１においてシーケンス図情報７１３のシーケンス名称９０１には、「販売管理システム」が格納される。シーン情報９０２には、メッセージ送信オブジェクト名称９０３として「業務担当」、メッセージ受信オブジェクト名称９０４として「顧客データベース」、メッセージ名称９０５として「顧客検索」が格納される。アクター情報７０１には、アクター名称７０２として「業務担当」が格納される。メッセージ７０６には、メッセージ名称７０７として「検索結果出力」が格納される。クラス情報６０１には、クラス名称６０２として「顧客データベース」が格納され、メッセージ６０６には、メッセージ名称６０７として「顧客検索」が格納される。
【００３７】
メッセージ送信オブジェクト名称９０３「業務担当」は、同一名称のアクター情報７０１を指し示す。メッセージ受信オブジェクト名称９０４「顧客データベース」は、クラス情報６０１を指し示す。メッセージ９０５「顧客検索」は、メッセージ６０６を指し示す。
【００３８】
図１２において関連情報７０８中の関連するアクター名称７０９「業務担当」は、アクター情報７０１「業務担当」を指し示す。また、関連するユースケース名称７１０「販売管理システム」は、ユースケース情報７１１「販売管理システム」を指し示す。ユースケース情報７１１のユースケース名称７１２「販売管理システム」とシーケンス図情報７１３のシーケンス名称９０１「販売管理システム」は同一である。
【００３９】
以下、本実施の形態における要求仕様モデルファイルからＵＭＬモデルファイルへの変換処理（要求仕様モデル変換処理）について説明する。
【００４０】
図１３は、処理装置１０２における要求仕様モデル変換処理の流れを示すフローチャートである。
【００４１】
まず、要求仕様モデルファイル入力部１０４は、入力記憶装置１０１に格納された要求仕様モデルファイル１９０１を入力し、要求仕様モデルファイル１９０１からキャラクター情報１９０２を抽出し、キャラクター情報記憶部１０５にキャラクター情報３０１として格納する。同様に、要求仕様モデルファイル１９０１から抽出されるシナリオ情報１９１１は、シナリオ情報記憶部１０６にシナリオ情報４０１として格納される（ステップ１２０１）。
【００４２】
次に、キャラクター情報解析・生成部１０７は、キャラクター情報記憶部１０５に格納されたキャラクター情報３０１を参照し、クラス情報６０１、またはアクター情報７０１のいずれかを生成する。クラス情報６０１を生成した場合、キャラクター情報解析・生成部１０７は、生成したクラス情報６０１をクラス図情報記憶部１０９に格納する。一方、アクター情報７０１を生成した場合、キャラクター情報解析・生成部１０７は、生成したアクター情報７０１をユースケース図情報記憶部１１０に格納する（ステップ１２０２）。
【００４３】
次に、シナリオ情報解析・生成部１０８は、シナリオ情報記憶部１０６に格納されたシナリオ情報４０１を元に、シーケンス図情報８０１の生成してシーケンス図情報一覧記憶部１１１への格納するか、あるいは、ユースケース情報７１１及び関連情報７０８を生成してユースケース図情報記憶部１１０へ格納する。このステップでは、シーケンス図情報８０１とユースケース情報７１１のいずれか一方が生成される（ステップ１２０３）。
【００４４】
次に、ＵＭＬモデルファイル出力部１１２は、クラス図情報記憶部１０９に格納されたクラス情報１０９、ユースケース図情報記憶部１１０に格納されたアクター情報７０１、ユースケース情報７１１、及び関連情報７０８、並びに、シーケンス図情報一覧記憶部１１１に格納されたシーケンス図情報８０１を統合してＵＭＬモデルファイルを生成し、出力記憶装置１０３に出力する（ステップ１２０４）。
【００４５】
図１４は、ステップ１２０２の詳細なフローチャートである。
【００４６】
ステップ１２０２では、まず、キャラクター情報記憶部１０５に格納されたキャラクター情報３０１を逐次取得するため、キャラクター情報取得位置ポインタをキャラクター情報記憶部１０５の先頭位置に設定する（ステップ１３０１）。
【００４７】
次に、キャラクター情報解析・生成部１０７は、キャラクター情報取得位置ポインタで示されるキャラクター情報記憶部１０５の記憶位置にキャラクター情報３０１があるかどうかを調べる（ステップ１３０２）。キャラクター情報が無ければ、キャラクター情報解析・生成部１０７は、ステップ１２０２の処理を終了する。キャラクター情報がある場合は、キャラクター情報解析・生成部１０７は、そのキャラクター情報３０１を取得する（ステップ１３０３）。
【００４８】
次に、キャラクター情報解析・生成部１０７はキャラクター情報３０１のキャラクター種別３０３を参照し、文字列“Ａｃｔｏｒ”の有無を調べる（ステップ１３０４）。文字列“Ａｃｔｏｒ”がある場合、キャラクター情報解析・生成部１０７は、キャラクター情報３０１を元にアクター情報７０１を生成し、ユースケース図情報記憶部１１０に格納する。具体的には、キャラクター情報解析・生成部１０７は、キャラクター情報記憶部１０５に格納されたキャラクター情報３０１からキャラクター名称３０２を取得し、アクター名称７０２として格納する。キャラクター情報３０１から属性名称３０５及び属性値３０６を取得し、アクター情報７０１の属性名称７０４及び属性値７０５として格納する。また、キャラクター情報３０１からメッセージ名称３０８を取得し、アクター情報７０１のメッセージ名称７０７として格納する（ステップ１３０５）。
【００４９】
ステップ１３０４で文字列”Ａｃｔｏｒ”がないと判断した場合、キャラクター情報解析・生成部１０７は、キャラクター情報３０１を元にクラス情報６０１を生成し、クラス図情報記憶部１０９に格納する。すなわち、キャラクター情報解析・生成部１０７は、キャラクター情報記憶部１０５に格納されたキャラクター情報３０１からキャラクター名称３０２を取得し、クラス名称６０２として格納する。キャラクター情報３０１から属性名称３０５及び属性値３０６を取得し、クラス情報６０１の属性名称６０４及び属性値６０５として格納する。キャラクター情報３０１からメッセージ名称３０８を取得し、クラス情報６０１のメッセージ名称６０７として格納する（ステップ１３０６）。
【００５０】
クラス情報６０１又はアクター情報７０１を生成したら、キャラクター情報解析・生成部１０７は、次のキャラクター情報３０１を取得するため、キャラクター情報取得位置ポインタをキャラクター情報１個分進める（ステップ１３０７）。そして、キャラクター情報解析・生成部１０７は、ステップ１３０２、ステップ１３０３、ステップ１３０４、ステップ１３０５またはステップ１３０６、及びステップ１３０７を、全てのキャラクター情報を取得するまで繰り返す。
【００５１】
図１５は、ステップ１２０３の詳細なフローチャートである。
【００５２】
ステップ１２０３でシナリオ情報解析・生成部１０８は、まず、シナリオ情報記憶部１０６に格納されたシナリオ情報４０１を逐次取得するため、シナリオ情報取得位置ポインタにシナリオ情報記憶部１０６の先頭位置を設定する（ステップ１４０１）。
【００５３】
次に、シナリオ情報解析・生成部１０８は、シナリオ情報取得位置ポインタで示されるシナリオ情報記憶部１０６の記憶位置にシナリオ情報４０１があるかどうかを調べ、シナリオ情報４０１がなければステップ１２０３の処理を終了する（ステップ１４０２）。シナリオ情報４０１があれば、シナリオ情報解析・生成部１０８は、そのシナリオ情報４０１を取得する（ステップ１４０３）。
【００５４】
次に、シナリオ情報解析・生成部１０８は、シナリオ情報４０１を元にシーケンス図情報８０１を生成してシーケンス図情報一覧記憶部１１１へ格納するか、または、ユースケース情報７１１を生成してユースケース図情報記憶部１１０へ格納する（ステップ１４０４）。
【００５５】
続いて、シナリオ情報解析・生成部１０８は、シナリオ情報取得位置ポインタをシナリオ情報１個分進める（ステップ１４０５）。その後、シナリオ情報解析・生成部１０８は、ステップ１４０２、１４０３、１４０４、及び１４０５の処理を、シナリオ情報記憶部１０６に格納された全てのシナリオ情報を参照し終えるまで行う。
【００５６】
図１６は、ステップ１４０４の詳細なフローチャートである。
【００５７】
ステップ１４０４でシナリオ情報解析・生成部１０８は、まず、シナリオ情報４０１中のシナリオ内キャラクター情報一覧４０３に格納された全てのキャラクター名称を取得するため、キャラクター名称取得位置ポインタに、そのシナリオ情報４０１内のシナリオ内キャラクター情報一覧４０３の先頭位置を設定する（ステップ１５０１）。
【００５８】
シナリオ情報解析・生成部１０８は、キャラクター名称取得位置ポインタで示される位置にキャラクター名称４０４があるかどうかを調べる（ステップ１５０２）。キャラクター名称４０４がある場合、シナリオ情報解析・生成部１０８は、キャラクター名称４０４を取得する（ステップ１５０３）。
【００５９】
次に、シナリオ情報解析・生成部１０８は、キャラクター情報記憶部１０５を先頭から逐次参照し、キャラクター名称４０４と同一名称のキャラクター情報３０１を取得する（ステップ１５０４）。
【００６０】
続いて、シナリオ情報解析・生成部１０８は、キャラクター情報３０１中のキャラクター種別３０３を調べ、文字列“Ａｃｔｏｒ”の有無を調べる（ステップ１５０５）。
【００６１】
文字列“Ａｃｔｏｒ”がある場合、シナリオ情報解析・生成部１０８は、ユースケース情報７１１を生成し、ユースケース図情報記憶部１１０に格納する。この処理において、シナリオ情報解析・生成部１０８は、シナリオ情報記憶部１０６に格納されたシナリオ情報４０１からシナリオ名称を４０２取得し、ユースケース名称７１２としてユースケース情報７１１に格納する。そして、次のようにしてシナリオ情報４０１からシーケンス図情報７１３を生成し、ユースケース情報７１１に格納する。まず、シナリオ情報解析・生成部１０８は、シナリオ名称４０２をシーケンス名称９０１として格納する。シナリオ情報４０１の各シーン情報４０６からメッセージ送信キャラクター名称４０７、メッセージ受信キャラクター名称４０８、及びメッセージ名称４０９を取得し、それぞれメッセージ送信オブジェクト名称９０３、メッセージ受信オブジェクト名称９０４及びメッセージ名称９０５として格納してシーン情報９０２を生成する（ステップ１５０７）。この後、シナリオ情報解析・生成部１０８は、関連情報７０８を生成する（ステップ１５０８）。
【００６２】
ステップ１５０５で文字列“Ａｃｔｏｒ”がみつからなかった場合、シナリオ情報解析・生成部１０８は、次のキャラクター名称４０４を取得するためキャラクター名称取得位置ポインタを進める（ステップ１５０６）。
【００６３】
シナリオ情報解析・生成部１０８は、ステップ１５０２以降の処理をシナリオ内キャラクター情報一覧に格納された全てのキャラクター名称４０４を参照し終えるか、またはキャラクター名称４０４が指し示すキャラクター情報３０１のうち、キャラクター種別３０３に文字列“Ａｃｔｏｒ”を持つものを見つけるまで行う。
【００６４】
ステップ１５０２においてキャラクター名称取得位置ポインタで示される位置にキャラクター名称４０４がない場合、すなわち、全てのキャラクター名称４０４について、文字列“Ａｃｔｏｒ”がなかったとき、シナリオ情報解析・生成部１０８は、シーケンス図情報８０１を生成し、シーケンス図情報一覧記憶部１１１に格納する。この処理でシナリオ情報解析・生成部１０８は、シナリオ名称４０２をシーケンス名称９０１として格納する。そして、シナリオ情報４０１の各シーン情報４０６からメッセージ送信キャラクター名称４０７、メッセージ受信キャラクター名称４０８、及びメッセージ名称４０９を取得し、それぞれメッセージ送信オブジェクト名称９０３、メッセージ受信オブジェクト名称９０４及びメッセージ名称９０５として格納してシーン情報９０２を生成する（ステップ１５０９）。
【００６５】
図１７は、ステップ１５０８における関連情報の生成処理の詳細なフローチャートである。
【００６６】
シナリオ情報解析・生成部１０８は、１個のシナリオ情報４０１中のシナリオ内キャラクター情報一覧４０３に格納された全てのキャラクター名称４０４を取得するため、キャラクター名称取得位置ポインタに、シナリオ内キャラクター情報一覧４０３の先頭位置を設定する（ステップ１６０１）。
【００６７】
次に、シナリオ情報解析・生成部１０８は、キャラクター取得位置にキャラクター名称があるかどうかを調べ、キャラクター名称がなければこの処理を終了する（ステップ１６０２）。
【００６８】
キャラクター名称があれば、シナリオ情報解析・生成部１０８は、シナリオ内キャラクター情報一覧４０３に格納されたキャラクター名称４０４を取得する（ステップ１６０３）。そして、シナリオ情報解析・生成部１０８は、キャラクター情報記憶部１０５を先頭から逐次参照し、取得したキャラクター名称４０４と同一名称のキャラクター情報３０１を取得する（ステップ１６０３）。
【００６９】
次に、シナリオ情報解析・生成部１０８は、取得したキャラクター情報が持つキャラクター種別３０３に文字列“Ａｃｔｏｒ”があるかどうかを調べる（ステップ１６０５）。文字列“Ａｃｔｏｒ”がある場合、シナリオ情報解析・生成部１０８は、キャラクター名称３０２を関連するアクター名称７０９として、シナリオ名称４０２を関連するユースケース名称７１０として関連情報７０８を生成し、ユースケース図情報記憶部１１０に格納する（ステップ１６０６）。ステップ１６０５においてキャラクター種別３０３に文字列“Ａｃｔｏｒ”がなかった場合、ステップ１６０６の処理は、スキップされる。
【００７０】
次のキャラクター名称をシナリオ内キャラクター情報一覧から取得するため、キャラクター名称取得位置ポインタを進める（ステップ１６０７）。以後、ステップ１６０２以降の処理が、シナリオ内キャラクター情報一覧に格納された全てのキャラクター名称を参照し終えるまで繰り返される。
【００７１】
図１８は、要求仕様作成プログラム２０１で作成した要求仕様モデルの具体例である。
【００７２】
キャラクターの一覧１７０１は、要求仕様モデルに属する全てのキャラクターを表示するためのものである。この例では、要求仕様モデルには、キャラクター業務担当１７０２及びキャラクター顧客データベース１７０３が属している。業務担当１７０２の詳細な情報は１７０４に表示される。また、顧客データベース１７０３の詳細な情報は１７０５に表示される。
【００７３】
シナリオ販売管理システム１７０６には、キャラクター業務担当１７０２及びキャラクター１７０３「顧客データベース」が登場する。１７０２及び１７０３は、シナリオ販売管理システム１７０６を構成するシーンである。シーン１７０７において、キャラクター１７０２「業務担当」からキャラクター１７０３「顧客データベース」に対してメッセージ「顧客検索」が渡される。同様に、シーン１７０８において、キャラクター１７０３「顧客データベース」からキャラクター１７０２「業務担当」に対してメッセージ「検索結果出力」が渡される。
【００７４】
図１９は、図１８に示す要求仕様モデルを、処理装置１０２により変換して得たＵＭＬモデルである。
【００７５】
キャラクター１７０３「顧客データベース」は、キャラクター種別に“Ａｃｔｏｒ”を持たないためクラス１８０２に変換される。クラスは、クラス図１８０１に配置される。
【００７６】
キャラクター１７０２「業務担当」はキャラクター種別に文字列“Ａｃｔｏｒ”を持つため、アクター１８０４に変換され、ユースケース図１８０３に配置される。
【００７７】
シナリオ販売管理システム１７０６には、キャラクター種別に“Ａｃｔｏｒ”を持つキャラクター１７０２である「業務担当」が登場するため、ユースケース１８０５に変換され、ユースケース図１８０３に配置される。ユースケース１８０５はシーケンス図１８０６を持つ。
【００７８】
以上説明した実施の形態によれば、要求仕様モデルを他の形式のモデルに変換する際に、キャラクターやシナリオが他の形式モデル要素の生成対象であるかどうかを判定し、モデル要素の生成をおこなうので、要求仕様モデルから他形式モデルに変換する時に、変換される他の形式モデルにおいて必要のない要素を生成することがなく、必要な他形式モデルの要素のみを生成することのできる。このため、変換処理後に、生成された他の形式モデルにおいて不必要なの要素を削除するといった手間を省くことができる。
【００７９】
【発明の効果】
以上説明したように、本発明によれば、要求仕様モデルから他形式モデルへの変換時に、変換後のモデルで必要となる要素のみを生成することが可能となる。
【図面の簡単な説明】
【図１】本発明の実施の形態において要求仕様モデル変換処理を行うためのシステムの概略構成図である。
【図２】要求仕様モデル・他形式モデル変換プログラムと外部プログラムの連携を示す概略図である。
【図３】入力記憶装置に格納された要求仕様モデルファイルの詳細図である。
【図４】キャラクター情報記憶部の詳細図である。
【図５】シナリオ情報記憶部の詳細図である。
【図６】シナリオ情報とキャラクター情報の関係を示す関連図である。
【図７】クラス図情報記憶部の詳細図である。
【図８】ユースケース図情報記憶部の詳細図である。
【図９】シーケンス図情報一覧記憶部の詳細図である。
【図１０】シーケンス図情報の詳細図である。
【図１１】シーケンス図情報とクラス情報及びアクター情報との関係を示した情報関連図である。
【図１２】関連情報と、アクター情報及びユースケース情報との間の関係を示した情報関連図である。
【図１３】要求仕様モデル変換処理の概要を示すフローチャートである。
【図１４】クラス情報／アクター情報生成処理の詳細なフローチャートである。
【図１５】シーケンス図情報、またはユースケース情報及び関連情報生成処理の詳細なフローチャートである。
【図１６】シーケンス図情報、またはユースケース情報及び関連情報生成の詳細なフローチャートである。
【図１７】関連情報生成処理の詳細なフローチャートである。
【図１８】要求仕様モデル作成プログラムで作成した要求仕様モデルの説明図である。
【図１９】要求仕様モデル変換処理により変換して得られたＵＭＬモデルの説明図である。
【符号の説明】
１０１…入力記憶装置
１０２…処理装置
１０３…出力記憶装置
１０４…要求仕様モデルファイル入力部
１０５…キャラクター情報記憶部
１０６…シナリオ情報記憶部
１０７…キャラクター情報解析・生成部
１０８…シナリオ情報解析・生成部
１０９…クラス図情報記憶部
１１０…ユースケース図情報記憶部
１１１…シーケンス図情報記憶部
１１２…ＵＭＬモデルファイル出力部[0001]
BACKGROUND OF THE INVENTION
The present invention provides a requirement specification defined by component information relating to components constituting a system development target business, and a scenario holding procedure chain information in which a sequence of procedures in a component or between procedures is recorded. The present invention relates to a required specification model / another format model conversion apparatus and a conversion method thereof for converting a model into a model of another format.
[0002]
[Prior art]
As a technique for defining required specifications in system development, for example, as described in Japanese Patent Laid-Open No. 9-81611, a character that is an element constituting a target business is defined, and data and procedures that the character has are used. There is a technology that defines requirements specifications by inputting real-world operations as fragmented concrete examples of scenarios called scenes. Characters here are "persons", specific "things", and other conceptual "abstract objects" that appear in the required specifications. The character has its name, display graphic information representing the image, internal data information to be held, and internal procedure information. The internal data information held by the character is called an attribute, and the internal procedure information held by the character is called a message. A scenario is a specific example of a requirement specification. A scenario has information about a scene and characters appearing in the scenario as constituent elements. A scene is an activation sequence of internal procedures between characters.
[0003]
As a technology for converting a requirement specification model file defined by a requirement specification definition technology so that it can be used by a program that handles a model file of another format, there is a requirement specification model / other format model conversion technology. Requirement specification model / other format model conversion technology means that a requirement specification model file defined by the requirement specification definition program as described above is matched with the data format of another format model file to be input by another program. This is a technology that allows the program to be converted, input and edited, and displayed on a display device. In recent years, software products to which these technologies are applied are being realized.
[0004]
[Problems to be solved by the invention]
In the conventional requirement specification model / other format model conversion apparatus as described above, the characters and scenarios constituting the requirement specification model are all converted as elements of the other format model. For this reason, there is a problem in that after conversion from the required specification model to another format model, elements of other unnecessary format models must be deleted.
[0005]
An object of the present invention is to provide a required specification model / other format model conversion apparatus capable of generating only necessary other format model elements when converting from a required specification model to another format model.
[0006]
[Means for Solving the Problems]
In order to achieve the above object, the required specification model / another format model conversion apparatus and conversion method according to the present invention provide component information in which a name, a data name, and a procedure name held by a component constituting a system development target job are recorded. And other types of requirement specification models defined by the procedure activation chain information that records the procedure activation chain between components, or the scenario that retains the procedure activation chain information that records the procedure activation chain in the component In the required specification model / other format model conversion apparatus and conversion method for converting to the above model, a required specification model file that is stored in a computer-readable storage device and includes the required specification model is read from the required specification model file input means. The component information obtained from the requirement specification model file input by the requirement specification model file input means, and the component type used as a material for determining whether or not the component is an element of another format model are stored in the component information storage means. . The scenario obtained from the requirement specification model file input by the requirement specification model file input means is stored in the scenario information storage means. The component element information analysis / generation unit determines whether the component element is an element of another format model based on the component element type based on the component element information stored in the component element information storage unit. Generate an element. The scenario information analysis / generation unit generates an element of another format model based on the scenario stored in the scenario information storage unit. The elements of the other format model generated by the component information analysis / generation means and the scenario analysis / generation means are integrated by the other format model file output means and stored in a computer-writable storage device.
[0007]
According to another aspect of the requirement specification model / other format model conversion apparatus according to the present invention, a requirement specification model file input means for reading a requirement specification model file stored in a computer-readable storage device, and a requirement specification model file input The character information received from the means is stored as a character identifier for identifying the character, an attribute for storing a value indicating the character state, a message indicating an executable action of the character, etc. Character information storage means for storing the character type as a material for determining whether or not it is, scenario information that is scenario information received from the required specification model file input means, a scenario identifier that identifies the scenario, and a character identifier that indicates the character that appears in the scenario And Based on the scenario information storage means for storing the scenes that make up the scenario and the character information extracted from the character information storage means, it is determined whether the character is an element of the other form model from the character type, and the other form model Information analysis / generation means for generating elements, scenario information analysis / generation means for generating elements of other format models based on scenario information extracted from scenario information storage means, character information analysis / generation means and scenarios Other format model file output means for integrating the elements of other format models received from the information analysis / generation means and storing them in a computer-writable storage device is provided.
[0008]
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 is a configuration diagram of an electronic computer that performs required specification model conversion processing in the present embodiment. In this embodiment, the requirement specification model is converted into a UML model that is a format handled by UML (Unified Modeling Language), which is an object-oriented modeling technique. This is an analysis and design method. As a technique related to UML, for example, a technique described in Terry Quatrani, “Visual Modeling with Rational Rose”, ISBN: 0-201-31016-3 is known.
[0009]
UML is modeled by diagrams such as class diagrams that represent classes and relationships between classes, sequence diagrams that represent scenes that are procedures between objects as a time-series flow, and use case diagrams that represent external interfaces of the system. Express. The components of the UML model include, for example, an object that is an element constituting the development target system and a class that is a set of objects. , Use cases that are intended to show the actor what the system does.
[0010]
In FIG. 1, a processing device 102 is a personal computer or a computer such as a workstation. On the main storage device of the processing device 102 or an external storage device connected to the processing device 102, a character name for identifying a character that is an element constituting character information, an attribute for storing a value indicating a character state, and a character A character information storage unit 105 that stores a message that represents an action that can be performed and stores a character type that is used as a material for determining whether or not a character is an element of another format model. A scenario that is an element constituting scenario information A scenario identifier for identifying a character, a character identifier indicating a character appearing in the scenario, a scenario information storage unit 106 for storing scenes constituting the scenario, and a class diagram information storage for storing class information generated by the character information analysis / generation unit 107 Part 109, character information solution A use case diagram information storage unit 110 that stores actor information generated by the generation unit 107, use case information generated by the scenario information analysis / generation unit 108, and related information, and a sequence diagram generated by the scenario information analysis / generation unit 108 Each storage unit of the sequence diagram information list storage unit 111 that stores information is provided.
[0011]
Based on the character information extracted from the required specification model file input unit 104 and the character information storage unit 105 for reading the required specification model file stored in the computer-readable input storage device 101, the processing device 102 functions as a character. A scenario extracted from the character information analysis / generation unit 107 and the scenario information storage unit 106 that determines whether the character is a class that is an element of the UML model or an actor from the type, and generates class information or actor information of the UML model Based on the information, it is determined whether to generate a sequence diagram of the UML model or to generate a use case and a relationship, and a scenario information analysis / generation unit 108 and a class for generating the sequence diagram information or the use case information and the related information Figure information storage unit 1 9. Each processing unit of the UML model file output unit 112 that integrates the elements of the UML model received from the use case diagram information storage unit 110 and the sequence diagram information list storage unit 111 and stores them in the computer readable output storage device 103 Have Specifically, these processing units are stored in the main storage device of the processing device 102 or an external storage device connected to the processing device 102, and the required specification model / other format model conversion program in the present embodiment is stored. It is a program module to be configured, and its function is realized by being executed by the processing device 102.
[0012]
FIG. 2 shows a connection between a requirement specification model creation program 201 that is an external program, a requirement specification model / other format model conversion program 202 that is executed by the processing apparatus 101, and a UML model input program 203 that is an external program. It is the figure which showed the procedure which performs from file generation to UML model file generation. The requirement specification model creation program 201 is a program for generating a requirement specification model file. The input storage device 101 stores a requirement specification model file created by the requirement specification model creation program 201. The required specification model / other format model conversion program 202 converts the required specification model file stored in the input storage device 101 into a UML model file and stores it in the output storage device 103. The UML model file stored in the output storage device 103 is input by the UML model input program 202 which is another external program.
[0013]
FIG. 3 shows details of the required specification model file stored in the input storage device 101.
[0014]
The requirement specification model file 1901 includes character information 1902 that holds information on characters that are components of a development target business, and scenario information that holds information on scenarios that are specific examples of the target business.
[0015]
The character information 1902 includes a character name 1903 that is an identifier, a character type 1904, an attribute 1905 that represents internal data of the character, and a message 1908 that is an internal procedure of the character. The attribute 1905 includes an attribute name 1906 that is an identifier and an attribute value 1907 that represents a data value. The message 1908 includes a message name 1910 that is an identifier.
[0016]
The scenario information 1911 includes a scenario name 1912 as an identifier, a scenario character information list 1913 representing a list of characters constituting the scenario, and scene information 1916 representing a sequence of procedures between characters in the scenario. The in-scenario character information list 1913 is a list of a pair of a character name 1914 and coordinates 1915 indicating an arrangement position on the scenario. The scene information 1916 represents a message transmission character name 1917 representing a character that requests activation of a procedure by message transmission, a message reception character name 1918 representing a character that receives a message and activates the procedure, and a procedure to be activated. It consists of a message name 1919.
[0017]
FIG. 4 shows details of the character information 301 stored in the character information storage unit 105. Character information 301 is stored in the character information storage unit 105. Character information 301 includes a character name 302 that is a character identifier, a character type 303 for indicating whether or not the character is a system component to be developed, zero or more attributes 304, and zero or more messages 307. Composed. The attribute 304 includes an attribute name 305 and an attribute value 306 that are identifiers. The message 307 includes a message name 308 that is an identifier. The attribute name 305 is unique in one piece of character information. The message name 308 is also unique in one character information.
[0018]
In the present embodiment, whether or not a character is a development target system component is determined based on whether or not a special character string is stored in the character type 303. In the present embodiment, the character string “Actor” is used as a special character string.
[0019]
FIG. 5 shows details of the scenario information 401 stored in the scenario information storage unit 106. The scenario information 401 includes a scenario name 402 as a scenario identifier, a character information list 403 in a scenario indicating a list of characters constituting the scenario, and zero or more scene information 406 representing scenes constituting the scenario.
[0020]
The character name 404 and the coordinates 405 are stored in the character information list 403 in the scenario. The character name 404 indicates the same name among the character information stored in the character information storage unit 106. When acquiring the character information indicated by the character name 404 in the requirement specification model creation program 201 and the scenario information analysis / generation unit 108, the character name 404 and the character name 302 are the same by sequentially referring to the character information storage unit 106. The character information 301 is acquired.
[0021]
The scene information 406 stores a message transmission character name 407 representing a message transmission source character, a message reception character name 408 representing a message reception destination, and a message name 409 representing a transmitted message. The message transmission character name 407 and the message reception character name 408 also indicate characters having the same name among the character information stored in the character information storage unit 106. The message name 409 indicates a message having the same name among the messages in the character information indicated by the received character name 408.
[0022]
The scenario name 402 is unique among all scenario information 401 stored in the scenario information storage unit 106.
[0023]
FIG. 6 is a related diagram showing the relationship between the scenario information 401 and the character information 301 using a specific example.
[0024]
In the scenario information 401 of the sales management system, “sales management system” is stored as the scenario name 402. In the in-scenario character information list 403, “business charge” and “customer database” are stored as character names 404. The character name 404 “business manager” is located at coordinates (10, 20), and the character name 404 “customer database” is located at coordinates (20, 20). In the scene information 406, “business manager” is stored as the message transmission character name 407, “customer database” is stored as the message reception character name 408, and “customer search” is stored as the message name 409.
[0025]
In the character information 301a, “task charge” as the character name 302a, “Actor” as the character type 303a, and a message 307a are stored. The message 307a stores “search result output” as the message name 308a. The other character information 301b stores “customer database” as the character name 302b, “non-actor” as the character type 303b, and a message 307b. The message 307b stores “customer search” as the message name 308b.
[0026]
The character name 404 “business person in charge” and the message transmission character name 407 stored in the in-scenario character information list 403 indicate the character information 301a in which the character name 302a “business person in charge” is stored. Similarly, the character name 404 “customer database” and the message receiving character name 408 “customer database” are characters. name 30 2 Point to b. The message name 409 “customer search” indicates the message 307b.
[0027]
FIG. 7 is a detailed diagram of the class diagram information storage unit 109. The class diagram information storage unit 109 stores class information 601 obtained from character information. The class information 601 includes a class name 602 for identifying a class, zero or more attributes 603 for representing the state of the class, and zero or more messages 606. The attribute 603 includes an attribute name 604 and an attribute value 605. The message 606 includes a message name 607.
[0028]
FIG. 8 is a detailed diagram of the use case diagram information storage unit 110. The use case diagram information storage unit 110 stores actor information 701 generated from character information, use case information 711 generated from scenario information, and related information 708.
[0029]
The actor information 701 includes an actor name 702 for identifying an actor, zero or more attributes 703 representing the actor state, and zero or more messages 706. The attribute 703 includes an attribute name 704 and an attribute value 705. The message 706 is composed of a message name 707.
[0030]
The use case information 711 includes a use case name 712 that is an identifier and sequence diagram information 713 that represents a sequence diagram that the use case has.
[0031]
The related information 708 represents the relationship between an actor and a use case, and is composed of a related actor name 709 and a related use case name 710.
[0032]
FIG. 9 is a detailed diagram of the sequence diagram information list storage unit 111. The sequence diagram information list storage unit 111 is for storing the sequence diagram information generated by the scenario information analysis / generation unit 108 (excluding the sequence diagram information included in the use case information 711), and includes zero or more sequence diagrams. Information 801 is stored.
[0033]
FIG. 10 shows details of the sequence diagram information 713 in FIG. 8 and the sequence diagram information 801 in FIG. The configuration of the sequence diagram information 801 stored in the sequence diagram information storage unit 111 and the sequence diagram information 713 stored in the use case information 711 are the same. The sequence diagram information 713 and 801 includes a sequence name 901 and zero or more scene information 902. The scene information 902 includes a message transmission object name 903, a message reception object name 904, and a message name 905.
[0034]
In the present embodiment, the use case name 712 and the sequence name stored in the sequence diagram information 713 are the same name. This is to make the correspondence between the use case and the sequence diagram clearer in the UML model input program 202.
[0035]
11 and 12 are diagrams showing the relationship between the sequence diagram information 713 and the actor information 701 and the class information 601 and the relationship between the related information 708 and the actor information 701 and the use case information 711 using specific examples.
[0036]
In FIG. 11, “sales management system” is stored in the sequence name 901 of the sequence diagram information 713. In the scene information 902, “business staff” is stored as the message transmission object name 903, “customer database” is stored as the message reception object name 904, and “customer search” is stored as the message name 905. In the actor information 701, “business charge” is stored as the actor name 702. The message 706 stores “search result output” as the message name 707. The class information 601 stores “customer database” as the class name 602, and the message 606 stores “customer search” as the message name 607.
[0037]
The message transmission object name 903 “business person in charge” indicates the actor information 701 having the same name. The message reception object name 904 “customer database” indicates the class information 601. Message 905 “customer search” points to message 606.
[0038]
In FIG. 12, the related actor name 709 “business person in charge” in the related information 708 indicates the actor information 701 “business person in charge”. Further, the related use case name 710 “sales management system” indicates use case information 711 “sales management system”. The use case name 712 “sales management system” of the use case information 711 and the sequence name 901 “sales management system” of the sequence diagram information 713 are the same.
[0039]
Hereinafter, the conversion process (required specification model conversion process) from the required specification model file to the UML model file in the present embodiment will be described.
[0040]
FIG. 13 is a flowchart showing a flow of required specification model conversion processing in the processing apparatus 102.
[0041]
First, the required specification model file input unit 104 inputs the required specification model file 1901 stored in the input storage device 101, extracts character information 1902 from the required specification model file 1901, and stores character information 301 in the character information storage unit 105. Store as. Similarly, scenario information 1911 extracted from the requirement specification model file 1901 is stored as scenario information 401 in the scenario information storage unit 106 (step 1201).
[0042]
Next, the character information analysis / generation unit 107 refers to the character information 301 stored in the character information storage unit 105 and generates either class information 601 or actor information 701. When the class information 601 is generated, the character information analysis / generation unit 107 stores the generated class information 601 in the class diagram information storage unit 109. On the other hand, when the actor information 701 is generated, the character information analysis / generation unit 107 stores the generated actor information 701 in the use case diagram information storage unit 110 (step 1202).
[0043]
Next, the scenario information analysis / generation unit 108 generates the sequence diagram information 801 based on the scenario information 401 stored in the scenario information storage unit 106 and stores it in the sequence diagram information list storage unit 111, or The use case information 711 and the related information 708 are generated and stored in the use case diagram information storage unit 110. In this step, either the sequence diagram information 801 or the use case information 711 is generated (step 1203).
[0044]
Next, the UML model file output unit 112 includes class information 109 stored in the class diagram information storage unit 109, actor information 701, use case information 711, and related information 708 stored in the use case diagram information storage unit 110. In addition, the sequence diagram information 801 stored in the sequence diagram information list storage unit 111 is integrated to generate a UML model file, which is output to the output storage device 103 (step 1204).
[0045]
FIG. 14 is a detailed flowchart of step 1202.
[0046]
In step 1202, first, in order to sequentially acquire the character information 301 stored in the character information storage unit 105, the character information acquisition position pointer is set to the head position of the character information storage unit 105 (step 1301).
[0047]
Next, the character information analysis / generation unit 107 checks whether the character information 301 exists at the storage position of the character information storage unit 105 indicated by the character information acquisition position pointer (step 1302). If there is no character information, the character information analysis / generation unit 107 ends the process of step 1202. If there is character information, the character information analysis / generation unit 107 acquires the character information 301 (step 1303).
[0048]
Next, the character information analysis / generation unit 107 refers to the character type 303 of the character information 301 and checks whether there is a character string “Actor” (step 1304). When there is a character string “Actor”, the character information analysis / generation unit 107 generates the actor information 701 based on the character information 301 and stores it in the use case diagram information storage unit 110. Specifically, the character information analysis / generation unit 107 acquires the character name 302 from the character information 301 stored in the character information storage unit 105 and stores it as the actor name 702. The attribute name 305 and the attribute value 306 are acquired from the character information 301 and stored as the attribute name 704 and the attribute value 705 of the actor information 701. Also, the message name 308 is acquired from the character information 301 and stored as the message name 707 of the actor information 701 (step 1305).
[0049]
If it is determined in step 1304 that there is no character string “Actor”, the character information analysis / generation unit 107 generates class information 601 based on the character information 301 and stores it in the class diagram information storage unit 109. That is, the character information analysis / generation unit 107 acquires the character name 302 from the character information 301 stored in the character information storage unit 105 and stores it as the class name 602. The attribute name 305 and the attribute value 306 are acquired from the character information 301 and stored as the attribute name 604 and the attribute value 605 of the class information 601. The message name 308 is acquired from the character information 301 and stored as the message name 607 of the class information 601 (step 1306).
[0050]
When the class information 601 or the actor information 701 is generated, the character information analysis / generation unit 107 advances the character information acquisition position pointer by one character information in order to acquire the next character information 301 (step 1307). Then, the character information analysis / generation unit 107 repeats Step 1302, Step 1303, Step 1304, Step 1305 or Step 1306, and Step 1307 until all the character information is acquired.
[0051]
FIG. 15 is a detailed flowchart of step 1203.
[0052]
In step 1203, the scenario information analysis / generation unit 108 first sets the start position of the scenario information storage unit 106 in the scenario information acquisition position pointer in order to sequentially acquire the scenario information 401 stored in the scenario information storage unit 106 ( Step 1401).
[0053]
Next, the scenario information analysis / generation unit 108 checks whether the scenario information 401 exists in the storage position of the scenario information storage unit 106 indicated by the scenario information acquisition position pointer. The process ends (step 1402). If the scenario information 401 exists, the scenario information analysis / generation unit 108 acquires the scenario information 401 (step 1403).
[0054]
Next, the scenario information analysis / generation unit 108 generates the sequence diagram information 801 based on the scenario information 401 and stores it in the sequence diagram information list storage unit 111 or generates the use case information 711 to use the use case. It stores in the figure information storage unit 110 (step 1404).
[0055]
Subsequently, the scenario information analysis / generation unit 108 advances the scenario information acquisition position pointer by one scenario information (step 1405). Thereafter, the scenario information analysis / generation unit 108 performs the processing of steps 1402, 1403, 1404, and 1405 until all the scenario information stored in the scenario information storage unit 106 has been referred to.
[0056]
FIG. 16 is a detailed flowchart of step 1404.
[0057]
In step 1404, the scenario information analysis / generation unit 108 first acquires all the character names stored in the in-scenario character information list 403 in the scenario information 401. The top position of the scenario character information list 403 is set (step 1501).
[0058]
The scenario information analysis / generation unit 108 checks whether or not the character name 404 exists at the position indicated by the character name acquisition position pointer (step 1502). If there is a character name 404, the scenario information analysis / generation unit 108 acquires the character name 404 (step 1503).
[0059]
Next, the scenario information analysis / generation unit 108 sequentially refers to the character information storage unit 105 from the top, and acquires character information 301 having the same name as the character name 404 (step 1504).
[0060]
Subsequently, the scenario information analysis / generation unit 108 checks the character type 303 in the character information 301 and checks whether or not the character string “Actor” exists (step 1505).
[0061]
When there is a character string “Actor”, the scenario information analysis / generation unit 108 generates use case information 711 and stores it in the use case diagram information storage unit 110. In this processing, the scenario information analysis / generation unit 108 acquires the scenario name 402 from the scenario information 401 stored in the scenario information storage unit 106 and stores it in the use case information 711 as the use case name 712. Then, the sequence diagram information 713 is generated from the scenario information 401 as follows and stored in the use case information 711. First, the scenario information analysis / generation unit 108 stores the scenario name 402 as the sequence name 901. A message transmission character name 407, a message reception character name 408, and a message name 409 are acquired from each scene information 406 of the scenario information 401, and stored as a message transmission object name 903, a message reception object name 904, and a message name 905, respectively. Information 902 is generated (step 1507). Thereafter, the scenario information analysis / generation unit 108 generates related information 708 (step 1508).
[0062]
When the character string “Actor” is not found in step 1505, the scenario information analysis / generation unit 108 advances the character name acquisition position pointer to acquire the next character name 404 (step 1506).
[0063]
The scenario information analysis / generation unit 108 finishes referring to all the character names 404 stored in the in-scenario character information list for the processing after step 1502 or character type 303 among the character information 301 indicated by the character name 404. Until the one having the character string “Actor” is found.
[0064]
If there is no character name 404 at the position indicated by the character name acquisition position pointer in step 1502, that is, if there is no character string “Actor” for all the character names 404, the scenario information analysis / generation unit 108 selects the sequence diagram. Information 801 is generated and stored in the sequence diagram information list storage unit 111. In this process, the scenario information analysis / generation unit 108 stores the scenario name 402 as the sequence name 901. Then, a message transmission character name 407, a message reception character name 408, and a message name 409 are acquired from each scene information 406 of the scenario information 401, and stored as a message transmission object name 903, a message reception object name 904, and a message name 905, respectively. To generate scene information 902 (step 1509).
[0065]
FIG. 17 is a detailed flowchart of the related information generation processing in step 1508.
[0066]
The scenario information analysis / generation unit 108 acquires all the character names 404 stored in the in-scenario character information list 403 in one scenario information 401. Therefore, the in-scenario character information list 403 is set in the character name acquisition position pointer. Is set (step 1601).
[0067]
Next, the scenario information analysis / generation unit 108 checks whether or not there is a character name at the character acquisition position. If there is no character name, the process ends (step 1602).
[0068]
If there is a character name, the scenario information analysis / generation unit 108 acquires the character name 404 stored in the in-scenario character information list 403 (step 1603). Then, the scenario information analysis / generation unit 108 sequentially refers to the character information storage unit 105 from the top, and acquires character information 301 having the same name as the acquired character name 404 (step 1603).
[0069]
Next, the scenario information analysis / generation unit 108 checks whether or not there is a character string “Actor” in the character type 303 included in the acquired character information (step 1605). When there is the character string “Actor”, the scenario information analysis / generation unit 108 generates the related information 708 using the character name 302 as the related actor name 709 and the scenario name 402 as the related use case name 710, and the use case diagram The information is stored in the information storage unit 110 (step 1606). If there is no character string “Actor” in the character type 303 in step 1605, the processing in step 1606 is skipped.
[0070]
In order to acquire the next character name from the character information list in the scenario, the character name acquisition position pointer is advanced (step 1607). Thereafter, the processing after Step 1602 is repeated until all the character names stored in the character information list in the scenario are referred to.
[0071]
FIG. 18 is a specific example of a requirement specification model created by the requirement specification creation program 201.
[0072]
The character list 1701 is for displaying all the characters belonging to the required specification model. In this example, the character specification staff 1702 and the character customer database 1703 belong to the required specification model. Detailed information of the business person in charge 1702 is displayed in 1704. Detailed information of the customer database 1703 is displayed in 1705.
[0073]
In the scenario sales management system 1706, a character business charge 1702 and a character 1703 “customer database” appear. Reference numerals 1702 and 1703 denote scenes constituting the scenario sales management system 1706. In the scene 1707, the message “customer search” is passed from the character 1702 “business manager” to the character 1703 “customer database”. Similarly, in the scene 1708, the message “search result output” is passed from the character 1703 “customer database” to the character 1702 “business staff”.
[0074]
FIG. 19 is a UML model obtained by converting the required specification model shown in FIG.
[0075]
Since the character 1703 “customer database” does not have “Actor” as the character type, it is converted into a class 1802. Classes are arranged in a class diagram 1801.
[0076]
Since the character 1702 “business person in charge” has the character string “Actor” as the character type, it is converted into an actor 1804 and arranged in the use case diagram 1803.
[0077]
In the scenario sales management system 1706, “business person in charge”, which is a character 1702 having “Actor” as the character type, appears and is converted into a use case 1805 and arranged in a use case diagram 1803. The use case 1805 has a sequence diagram 1806.
[0078]
According to the embodiment described above, when converting a required specification model to a model of another format, it is determined whether a character or a scenario is a generation target of another format model element, and generation of a model element is performed. Therefore, when converting from the required specification model to the other format model, it is possible to generate only the elements of the necessary other format model without generating unnecessary elements in the other format model to be converted. For this reason, it is possible to save the trouble of deleting unnecessary elements in other generated formal models after the conversion process.
[0079]
【The invention's effect】
As described above, according to the present invention, at the time of conversion from a required specification model to another format model, it is possible to generate only elements necessary for the converted model.
[Brief description of the drawings]
FIG. 1 is a schematic configuration diagram of a system for performing required specification model conversion processing in an embodiment of the present invention.
FIG. 2 is a schematic diagram showing cooperation between a required specification model / another format model conversion program and an external program.
FIG. 3 is a detailed view of a requirement specification model file stored in an input storage device.
FIG. 4 is a detailed view of a character information storage unit.
FIG. 5 is a detailed diagram of a scenario information storage unit.
FIG. 6 is a relation diagram showing a relationship between scenario information and character information.
FIG. 7 is a detailed diagram of a class diagram information storage unit;
FIG. 8 is a detailed view of a use case diagram information storage unit;
FIG. 9 is a detailed diagram of a sequence diagram information list storage unit;
FIG. 10 is a detailed diagram of sequence diagram information.
FIG. 11 is an information relation diagram showing a relationship between sequence diagram information, class information, and actor information.
FIG. 12 is an information related diagram showing a relationship between related information and actor information and use case information.
FIG. 13 is a flowchart showing an outline of required specification model conversion processing;
FIG. 14 is a detailed flowchart of class information / actor information generation processing;
FIG. 15 is a detailed flowchart of sequence diagram information or use case information and related information generation processing;
FIG. 16 is a detailed flowchart of generating sequence diagram information or use case information and related information.
FIG. 17 is a detailed flowchart of related information generation processing;
FIG. 18 is an explanatory diagram of a requirement specification model created by a requirement specification model creation program.
FIG. 19 is an explanatory diagram of a UML model obtained by conversion through a required specification model conversion process.
[Explanation of symbols]
101 ... Input storage device
102. Processing device
103 ... Output storage device
104 ... Required specification model file input section
105 ... Character information storage
106 ... scenario information storage unit
107 ... Character information analysis / generation unit
108 ... scenario information analysis / generation unit
109 ... Class diagram information storage unit
110 ... Use case diagram information storage unit
111 ... Sequence diagram information storage unit
112 ... UML model file output part

Claims

Constituent element information that holds the character name, message name, and scenario name of the character that is a constituent element of the system development target business and is stored in the constituent elements constituting the system development target business, and a procedure start-up chain between the above constituent elements Requirement specification model that converts a requirement specification model defined by a procedure holding sequence information that records the procedure activation chain information that records the procedure activation chain information in the above components into a model of another format In other format model converter,
Requirement specification model file input means for reading a requirement specification model file consisting of the above requirement specification model, stored in a computer-readable storage device,
The component information obtained from the requirement specification model file input by the requirement specification model file input means is stored, and the component type used as a material for determining whether the component is an element of another format model is stored Component information storage means for
Scenario information storage means for storing a scenario obtained from the requirement specification model file input by the requirement specification model file input means;
A configuration for determining whether or not the component element is an element of another format model from the component element type based on the component element information stored in the component element information storage unit, and generating an element of the other format model Element information analysis / generation means,
Based on the scenario stored in the scenario information storage means, scenario information analysis / generation means for generating an element of another format model,
Characterized in that it comprises other format model file output means that integrates the elements of the other format model received from the component element information analysis / generation means and the scenario analysis / generation means and stores them in a computer-writable storage device. Requirement specification model / other format model conversion device.

Constituent element information that holds the character name, message name, and scenario name of the character that is a constituent element of the system development target business and is stored in the constituent elements constituting the system development target business, and a procedure start-up chain between the above constituent elements Requirement specification model that converts the requirement specification model defined by the procedure invocation sequence information that records the procedure or the scenario that retains the procedure invocation sequence information that records the procedure invocation sequence in the above components into another model -In other format model conversion method,
A requirement specification model file that holds the requirement specification model stored in a computer-readable storage device is read,
Determine whether the component is an element of the other format model from the component type and generate an element of the other format model.
Determine whether the scenario is an element of the other format model from the component type of the component that constitutes the above scenario, and generate the element of the other format model,
Requirement specification model / other format model characterized in that elements of other format model generated from the component information and elements of other format model generated based on the scenario are integrated and stored in a computer-writable storage device Conversion method.