(57)【要約】【課題】設計情報の検証を、自動的に、かつ設計情報のスキーマの定義に依存することなく行うことのできる設計情報検証装置を提供する。【解決手段】標準スキーマの情報が割り当てられた複数の項目に一つの画面遷移に関係するクラスをそれぞれ記述して、標準スキーマの情報と設計情報のスキーマの情報とのマッピングを定義した表形式の設計仕様を作成する。設計情報を検証するためのルールとして、標準スキーマの情報に基づく検証ルールを予め作成しておき、検証を実行するとき、検証ルールを、設計仕様にて定義されたマッピングに基づいて設計情報のスキーマの情報を用いた表現に変更し、この変更された検証ルールに基づいて設計情報の検証を行う。【選択図】図１
2006139616.tif 000002
【特許請求の範囲】
【請求項１】
第１のスキーマの情報が割り当てられた複数の項目に、一つの画面遷移に関係する設計情報をそれぞれ記述して、前記第１のスキーマの情報と前記設計情報の第２のスキーマの情報とのマッピングを定義した表形式の設計仕様を含む設計情報を格納する設計情報格納手段と、
前記第１のスキーマの情報を用いて作成された、前記設計情報を検証するための検証ルールが格納された検証ルール格納手段と、
前記設計情報格納手段に格納された前記設計情報に対する検証の指示が発生したとき、前記検証ルール格納手段に格納された検証ルールを、前記設計仕様にて定義された前記マッピングに基づいて前記第２のスキーマの情報を用いた検証ルールに変更し、この変更された検証ルールにより前記設計情報の検証を行う検証手段と
を具備することを特徴とする設計情報検証装置。
【請求項２】
前記検証ルール格納手段に格納された検証ルールが、前記設計情報を前記項目の単位で検証するためのルールであることを特徴とする請求項１に記載の設計情報検証装置。
【請求項３】
第１のスキーマの情報が割り当てられた複数の項目に、一つの画面遷移に関係する設計情報をそれぞれ記述して、前記第１のスキーマの情報と前記設計情報の第２のスキーマの情報とのマッピングを定義した表形式の設計仕様を設計情報格納手段に格納しておくとともに、前記第１のスキーマの情報を用いて作成された、前記設計情報を検証するための検証ルールを検証ルール格納手段に格納しておき、前記設計情報に対する検証の指示が発生したとき、検証手段により、前記検証ルール格納手段に格納された検証ルールを、前記設計仕様にて定義された前記マッピングに基づいて前記第２のスキーマの情報を用いた検証ルールに変更し、この変更された検証ルールにより前記設計情報の検証を行うことを特徴とする設計情報検証方法。
【請求項４】
前記検証ルール格納手段に格納された検証ルールが、前記設計情報を前記項目の単位で検証するためのルールであることを特徴とする請求項３に記載の設計情報検証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、開発すべきソフトウェアの設計情報の品質を確保するために、その設計情報の検証を行う設計情報検証装置および設計情報検証方法に関する。
【背景技術】
【０００２】
一般に、ソフトウェアの設計ツールには設計情報の検証機能が組み込まれている。このような設計ツールに組み込まれた検証機能は、ダイアグラム間の整合性といったような大きな枠組みでの検証を行うことに止まるものであり、たとえば、一つの画面遷移に関係するクラスの関係といったような、詳細な設計内容にまで踏み込んだ検証を行うものではない。
【０００３】
詳細な設計内容にまで踏み込んだ検証を行う方法として、クラス間の相互作用情報を設計者に掲示するなどして、モデルに分類されたクラス間の関連付けの検証作業を支援するシステムなどが挙げられる（例えば特許文献１を参照）。
【特許文献１】特開２００４−１１０４１５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１の技術は、設計情報の検証を自動的に行うというものではない。そこで、設計情報の検証ルールをあらかじめ定義しておき、この検証ルールに則って設計情報の検証を自動的に行う方法が考えられるが、この場合、そのルールの表現と設計情報の表現との間に整合性が確保されていることが必要となる。しかし、設計情報を管理するためのスキーマの定義は部署やプロジェクトごとに異なることが普通であるため、検証ルールを用いて設計情報の検証を行う汎用的な検証装置の実現は困難であった。
【０００５】
本発明は、このような点に鑑みてなされたものであり、設計情報の検証を、自動的に、かつ設計情報のスキーマの定義に依存することなく行うことのできる設計情報検証装置および設計情報検証方法を提供することを目的としている。
【課題を解決するための手段】
【０００６】
上記の課題を解決するために、この発明の設計情報検証装置は、第１のスキーマの情報が割り当てられた複数の項目に、一つの画面遷移に関係する設計情報をそれぞれ記述して、第１のスキーマの情報と設計情報の第２のスキーマの情報とのマッピングを定義した表形式の設計仕様を含む設計情報を格納する設計情報格納手段と、第１のスキーマの情報を用いて作成された、設計情報を検証するための検証ルールが格納された検証ルール格納手段と、設計情報格納手段に格納された設計情報に対する検証の指示が発生したとき、検証ルール格納手段に格納された検証ルールを、設計仕様にて定義されたマッピングに基づいて第２のスキーマの情報を用いた検証ルールに変更し、この変更された検証ルールにより設計情報の検証を行う検証手段とを具備するものである。
【発明の効果】
【０００７】
本発明の設計情報検証装置および設計情報検証方法によれば、設計情報の検証を、自動的に、かつ設計情報のスキーマの定義に依存することなく行うことができる。
【発明を実施するための最良の形態】
【０００８】
以下、図面を参照して本発明の実施の形態を説明する。
【０００９】
図１は、本発明の一実施形態に係る設計情報検証装置の全体の構成を示すブロック図である。
【００１０】
同図に示すように、この設計情報検証装置１００は、全体制御部１、入力制御部２、出力制御部３、設計情報の選択・入力部４、設計情報検証部５、設計情報データベース（以下、設計情報ＤＢと記述）６、設計情報検証ルールデータベース（以下、設計情報検証ルールＤＢと記述）７、設計情報メタデータデータベース（以下、設計情報メタデータＤＢと記述）８などを備えている。この設計情報検証装置１００は、具体的には、ＣＰＵ（Central Processing Unit）、メモリ、ＨＤＤ（Hard Disk Drive）、入力装置、出力装置などのコンピュータのハードウェア要素と、ＯＳ（Operating System）、その上で動作するアプリケーションプログラムなどのソフトウェア要素とで構成される。設計情報ＤＢ６、設計情報検証ルールＤＢ７、設計情報メタデータＤＢ８は、コンピュータシステムのメモリやＨＤＤなどのハードウェアである記憶部に構築される。
【００１１】
全体制御部１は入力制御部２、出力制御部３、設計情報の選択・入力部４および設計情報検証部５の間でデータや命令などの受け渡しを制御する。入力制御部２は図示せぬキーボードやマウスなどの入力装置からの入力を制御する。出力制御部３は設計情報、設計情報検証ルール、検証結果などを図示せぬ表示装置に表示する制御を行う。設計情報の選択・入力部４は設計情報ＤＢ６への設計情報の格納や設計情報ＤＢ６に格納されている設計情報の選択や更新などの命令を実行する手段である。設計情報検証部５は設計情報検証ルールＤＢ７に格納された設計情報検証ルールに従って設計情報を検証する手段である。設計情報ＤＢ６は設計情報が格納されるデータベースである。設計情報検証ルールＤＢ７はその設計情報を検証するためのルールが格納されるデータベースである。設計情報メタデータＤＢ８は設計情報検証ルールの表現に用いられている標準スキーマ（第１のスキーマの情報）と、設計情報の表現に用いられているスキーマ（第２のスキーマの情報）とのマッピングを定義するための情報（設計情報メタデータ）が格納されるデータベースである。
【００１２】
図２は設計情報検証部５の構成を示すブロック図である。
【００１３】
同図に示すように、設計情報検証部５は、検証エンジン１１、設計情報展開部１２、検証ルール展開部１３および設計検証実行部１４を備えている。
【００１４】
検証エンジン１１は、外部との入出力を司るとともに、設計情報展開部１２、検証ルール展開部１３、設計検証実行部１４の動作を統括的に制御する手段である。検証エンジン１１は、検証対象として指定された設計情報を設計検証実行部１４での検証処理に適したデータ構造に変換して設計情報展開部１２に展開する。また、検証エンジン１１は設計情報検証ルールＤＢ７から読み込んだ設計情報検証ルールを設計情報のスキーマに合わせた表現に変更して検証ルール展開部１３に展開する。検証エンジン１１は、検証実行に際して、設計情報展開部１２に展開された設計情報および検証ルール展開部１３に展開された設計情報検証ルールをそれぞれ読み出して設計検証実行部１４に与える。設計検証実行部１４は検証エンジン１１より設計情報および設計情報検証ルールを受け取り、設計情報検証ルールによる設計情報の検証を実行する。
【００１５】
次に、設計情報について説明する。  
設計情報には、ユースケース図および画面遷移図をデータベース化した設計情報のほか、一つの画面遷移に関係するクラスを一行にならべた表形式の設計仕様などがある。
【００１６】
図３はユースケース図の例である。このユースケースは会員制のオンライン購買システムを題材とするものである。このシステムでは、ユーザ登録やユーザ情報の変更、退会の処理に関しては、直接オンライン上でユーザが行うのではなく、郵送により本人証明を要求するものとなっている。このため、ユーザ管理４１は郵送による連絡を受けた顧客担当員４２が行う。オンラインでの購入はインターネットを介して、ユーザ４３が直接行えるものとするが、インターネット環境がない顧客、もしくは一時的に使えない環境下におかれた顧客のため、電話での購入申し込みも受け付けるものとする。この場合、ユーザ本人に代わって、顧客担当４２が購入の入力を行う。このため、オンライン購入４４は、ユーザ４３および顧客担当４２が行えるものとする。ここで、ユーザ管理４１とオンライン購入４４がユースケース、顧客担当員４２、ユーザ４３がアクターに相当する。
【００１７】
図４は図３に示したユースケース図のスキーマ情報およびその設計情報を示す図である。同図に示すように、図３に示したユースケース図のスキーマ情報は、ユースケースを表現するスキーマ５１、アクターを表現するスキーマ５２、これらの間の関係を表現するスキーマ５３により構成される。ユースケースを表現するスキーマ５１はユースケースＩＤとユースケース名からなる。アクターを表現するスキーマ５２はアクターＩＤとアクター名からなる。関係を表現するスキーマ５３はユースケースＩＤ、アクターＩＤ、これらの関連の種別を示す情報からなる。５１Ａ、５２Ａ、５３Ａは、これらのスキーマに基づき、図３のユースケース図をデータベース化した設計情報である。
【００１８】
図５は図３に示したユースケース図におけるユーザ管理４１のユースケースの一部に関する画面遷移図の例である。この例では、初期メニューとして、ユーザ情報管理メニュー６１が表示される。このユーザ情報管理メニュー６１上で「ユーザ登録」のボタンを押下することにより、ユーザ情報入力画面６２へと画面表示が切り替わる。このユーザ情報入力画面６２上で新規に登録するユーザの情報を入力し、「登録」ボタンを押下することにより、さらにユーザ情報登録確認画面６３へと画面が遷移する。この画面において入力内容を確認し、正しいことが確認できたら、「確認」ボタンを押下する。これにより、実際にユーザ登録の処理が実行される。ユーザ登録処理が正常に終了すると、画面はユーザ情報登録完了画面６４へと遷移し、異常終了すると、ユーザ登録エラー画面６５へと遷移する。
【００１９】
図６は図５に示した画面遷移図のスキーマ情報およびその設計情報を示す図である。同図に示すように、図６に示した画面遷移図のスキーマ情報は、上記の各画面６１、６２、６３、６４、６５を表現するスキーマ７１と、これらの画面間の遷移を表現するスキーマ７２により構成される。画面を表現するスキーマ７１は図面ＩＤとその画面名で構成される。画面間の遷移を表現するスキーマ７２は図面ＩＤ、遷移元画面ＩＤ、遷移先画面ＩＤ、画面遷移のトリガ、遷移条件で構成される。７１Ａ、７２Ａは、これらのスキーマに基づき、図６の画面遷移図をデータベース化した設計情報である。
【００２０】
設計情報ＤＢ６には、上記のユースケース図、画面遷移図をデータベース化した設計情報のほか、図７に示すように、一つの画面遷移に関係するクラスを一行にならべた表形式の設計仕様が格納される。
【００２１】
図７に示した表形式の設計仕様は、図８に示すように、設計情報メタデータＤＢ８に格納されている、標準スキーマと設計情報のスキーマとのマッピングを定義するための情報をベースに開発者９により作成されたものである。このスキーマのマッピングのための情報は、各々の項目に標準スキーマの情報が割り当てられた表の形式で与えられている。開発者９は、この表の各項目に割り当てられた標準スキーマの情報と設計情報のスキーマの情報との整合をとりなから、それらの項目に一つの画面遷移に関係するクラスをそれぞれ記述して一行に並べた表形式の設計仕様を作成する。一般に、設計情報を管理するためのスキーマの定義は部署やプロジェクトごとに異なる。これに対して設計情報検証ルールは標準スキーマをベースに作成されたものであるから、設計情報の検証にそのまま用いることはできない。そこで図８に示すスキーマのマッピングのための情報をベースとする表形式の設計仕様を作成することで、設計情報のスキーマの情報と標準スキーマの情報とのマッピングが定義され、設計情報のスキーマに依存しない検証が実現される。
【００２２】
図７の設計仕様によれば、標準スキーマの「ユースケース」は設計情報のスキーマの「ユーザ情報を登録管理する」「オンライン購入する」に対応し、標準スキーマの「アクター」は設計情報のスキーマの「顧客」「顧客管理担当」に対応し、標準スキーマの「リクエスト発生画面」「遷移先画面」は設計情報のスキーマの「ユーザ情報管理メニュー」「ユーザ情報入力画面」「ユーザ情報登録確認画面」「ユーザ情報登録完了画面」「ユーザ登録エラー画面」に対応し、標準スキーマの「リクエスト」は設計情報のスキーマの画面遷移のトリガである「「ユーザ登録」ボタン押下」「「登録」ボタン押下」「「確認」ボタン押下」「「メニューへ戻る」ボタン押下」に対応し、標準スキーマの「遷移条件」は設計情報のスキーマの「登録完了」「登録異常」に対応することが定義される。
【００２３】
スキーマのマッピングのための情報は複数容易されており、開発者９はその中で使用するマッピング情報をその番号により指定することができる。図７に示した設計情報は番号＝１のマッピング情報に基づいて作成されたものである。図９は番号＝２のマッピング情報に基づいて作成された設計情報の例である。
【００２４】
図１０は設計情報検証ルールの例を示す図である。この例では設計情報検証ルールが日本語で記述されているが、実際には処理のパターン化が可能であり、自然言語での定義は必須ではない。
【００２５】
番号１のルールは、設計情報のユースケースに関わる内容の検証項目である。図７の設計情報において検証対象となるユースケースは「ユーザ情報を登録管理する」の一項目のみである。比較対象は「ユースケース図」であり、検証内容は「該当するユースケースが定義されていること」である。該当するユースケースが定義されているかどうかは、ユースケース図のデータベース（図４）を参照することによって検証することができる。
【００２６】
番号２のルールは、設計情報のアクターに関わる内容の検証項目である。図７の設計情報において検証対象となるアクターは「顧客管理担当」の一項目のみである。比較対象は「ユースケース図」であり、検証内容は「該当するアクターが定義されていること」である。該当するアクターが定義されているかどうかは、ユースケース図のデータベース（図４）を参照することによって検証することができる。
【００２７】
番号３のルールは、リクエスト発生画面に関わる内容の検証項目である。比較対象は「画面遷移図」であり、検証内容は「該当する画面が定義されていること」である。該当するリクエスト発生画面が定義されているかどうかは、画面遷移図のデータベース（図６）を参照することによって検証することができる。
【００２８】
番号４のルールは、遷移先画面に関わる内容の検証項目である。比較対象は「画面遷移図」であり、検証内容は「該当する画面が定義されていること」である。該当する遷移先画面が定義されているかどうかは、画面遷移図のデータベース（図６）を参照することによって検証することができる。
【００２９】
番号５のルールは、画面の遷移条件に関わる内容の検証項目である。比較対象は「サービス」であり、検証内容は「遷移条件がある場合、サービスが定義されていること」である。画面を遷移させるための条件があるということは、すなわちその前に何らかの分岐を発生させる処理があるということである。このため、図７において遷移条件が記述されている３行目、４行目では、同一行に処理の本体である「サービス」が記述されていなければならない。
【００３０】
番号６のルールは、リクエスト発生画面に関わる内容の検証項目である。比較対象は「遷移先画面」であり、検証内容は「リクエスト発生画面は、いずれかの遷移先画面となっていること」である。リクエスト発生画面がいずれかの遷移先画面となっているかどうかは、画面遷移図のデータベース（図６）を参照することによって検証することができる。
【００３１】
次に、この設計情報検証装置１００の動作を説明する。  
図１１は設計情報検証装置１００による設計情報の検証動作のフローチャートである。
【００３２】
まず、開発者９は、検証の対象となる設計情報を選択する（ステップ１０１）。この選択は、具体的には、開発者９が図示せぬキーボードやマウスなどの入力装置を操作して検証対象となる設計情報を選択するコマンドを入力することで行われる。全体制御部１は、そのコマンドを入力制御部２を通じて受け取り、設計情報の選択・入力部４に渡す。設計情報の選択・入力部４はそのコマンドに基づいて該当する設計情報のうちの表形式の設計仕様を設計情報ＤＢ６から読み出す。
【００３３】
設計情報ＤＢ６から読み出された表形式の設計仕様は出力制御部３を介して図示せぬ表示装置に表示される(ステップ１０２)。このとき表示画面には、表示中の設計情報に対する検証実行を指示するための検証実行ボタンが表示され、この検証実行ボタンが開発者９によって操作されると、全体制御部１は、設計情報検証部５に対して検証実行コマンドを与える(ステップ１０３)。
【００３４】
設計情報検証部５は、検証実行コマンドを受けると、設計情報の選択・入力部４によって設計情報ＤＢ６から読み出された設計情報を、検証エンジン１１にて検証に適したデータ構造に変換して設計情報展開部１２に展開するとともに(ステップ１０４)、設計情報検証ルールＤＢ７から設計情報検証ルールを読み出し(ステップ１０５)、その設計情報検証ルールの記述を、設計仕様に定義されている標準スキーマの情報と設計情報のスキーマの情報とのマッピングに基づいて、設計情報のスキーマの情報を用いた表現に変更して(ステップ１０６) 、検証ルール展開部１３に展開する。
【００３５】
たとえば、図１０の番号１のルールである「該当するユースケースが定義されていること」は「ユーザ情報を登録管理するが定義されていること」「オンライン購入するが定義されていること」という表現に変更される。番号２のルールである「該当するアクターが定義されていること」は「顧客が定義されていること」「顧客管理担当が定義されていること」という表現に変更される。番号３のルールである「該当する画面が定義されていること」は「ユーザ情報管理メニューが定義されているか」「ユーザ情報入力画面が定義されているか」などに変更される。
【００３６】
続いて、設計情報検証部５は、検証エンジン１１を起動して検証動作を開始する。検証エンジン１１は、設計情報展開部１２に展開された設計情報と、検証ルール展開部１３に展開された設計情報検証ルールを設計検証実行部１４に一つずつ与えて、設計情報の検証を実行する（ステップ１０７）。検証エンジン１１は設計検証実行部１４による検証の結果を取得すると、その結果を全体制御部１に返す。全体制御部１は受け取った検証結果を出力制御部３を通じて図示せぬ表示装置に表示して、開発者９に通知する（ステップ１０８）。ここで、検証においては、どのルールによるどの位置での検証でエラーが発生したかが分かるので、エラーの発生した設計情報の位置およびエラー内容を検証結果に含めて出力することができる。
【００３７】
以上のように本実施形態の設計情報検証装置１００によれば、設計情報の検証を、あらかじめ定義されたルールに則って自動的に、かつ個々の画面遷移に関係するユースケース、アクター、リクエスト発生画面、遷移先画面、遷移条件、リクエスト発生画面といった細かい単位で行うことができる。
【００３８】
また、この実施形態の設計情報検証装置１００によれば、スキーマのマッピングのための情報をベースとする表形式の設計仕様を作成することによって、設計情報のスキーマと標準スキーマとのマッピングを定義することができ、設計情報のスキーマに依存しない検証が実現される。
【００３９】
なお、本発明は、上述の実施形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。
【図面の簡単な説明】
【００４０】
【図１】本発明の一実施形態に係る設計情報検証装置の全体の構成を示すブロック図である。
【図２】図１の設計情報検証部の構成を示すブロック図である。
【図３】ユースケース図の例を示す図である。
【図４】図３に示したユースケース図のスキーマ情報および設計情報を示す図である。
【図５】図３に示したユースケース図におけるユーザ管理のユースケースの一部に関する画面遷移図である。
【図６】図５に示した画面遷移図のスキーマ情報および設計情報を示す図である。
【図７】表形式の設計仕様の例を示す図である。
【図８】標準スキーマと設計情報のスキーマとのマッピングを定義するための情報を示す図である。
【図９】表形式の別の設計仕様の例を示す図である。
【図１０】設計情報検証ルールの例を示す図である。
【図１１】図１の設計情報検証装置による設計情報の検証動作のフローチャートである。
【符号の説明】
【００４１】
１・・・・全体制御部
２・・・・入力制御部
３・・・・出力制御部
４・・・・設計情報の選択・入力部
５・・・・設計情報検証部
６・・・・設計情報ＤＢ
７・・・・設計情報検証ルールＤＢ
８・・・・設計情報メタデータＤＢ
【図１】
2006139616.tif 000003
【図２】
2006139616.tif 000004
【図３】
2006139616.tif 000005
【図４】
2006139616.tif 000006
【図５】
2006139616.tif 000007
【図６】
2006139616.tif 000008
【図７】
2006139616.tif 000009
【図８】
2006139616.tif 000010
【図９】
2006139616.tif 000011
【図１０】
2006139616.tif 000012
【図１１】
2006139616.tif 000013