(57)【要約】【課題】  本発明は、ＵＭＬを用いたシステム開発において、作成モデルのレビュー前後に、モデルの完成度、品質を自動的にチェックするレビュー支援装置を提供する。【解決手段】  ＵＭＬによるモデリングのレビューを支援するレビュー支援装置であって、予めモデルの正当性を評価するチェック項目と内容を定義したルールをルールデータベースに設定しておき、ユーザによるモデルの作成入力を受けて、ルールデータベースを参照してそのチェック条件に基づいて作成モデルをチェックし、チェック結果を出力することを特徴とする。【選択図】図１
2007265005.tif 000002
【特許請求の範囲】
【請求項１】
ＵＭＬによるモデリングのレビューを支援するレビュー支援装置であって、
予めモデルの正当性を評価するチェック項目と内容を定義したルールをルールデータベースに設定するルール設定手段と、
前記モデルを作成し入力するモデル入力手段と、
前記ルールデータベースを参照し、前記モデル入力手段によって入力されたモデルを前記チェック条件に基づいてチェックするルールチェック手段と、
前記ルールチェック手段によってチェックされた前記モデルの評価結果を出力する結果出力手段と、
を有することを特徴とするレビュー支援装置。
【請求項２】
前記ルールチェック手段において、前記ルールデータベースのチェック項目毎にルールに違反したエラー回数を記録し、次回以降、当該エラー回数の多い項目順にチェックすることを特徴とする請求項１に記載のレビュー支援装置。
【請求項３】
前記ルールデータベースに予めチェック項目に重み付けを設定しておき、前記ルールチェック手段において、重み付けがなされた項目を優先的にチェックすることを特徴とする請求項１に記載のレビュー支援装置。
【請求項４】
ＵＭＬによるモデリングのレビューを支援するレビュー支援方法であって、
予めモデルの正当性を評価するチェック項目と内容を定義したルールをルールデータベースに設定するルール設定ステップと、
前記モデルを作成し入力するモデル入力ステップと、
前記ルールデータベースを参照し、前記モデル入力ステップにおいて入力されたモデルを前記チェック条件に基づいてチェックするルールチェックステップと、
前記ルールチェックステップにおいてチェックされた前記モデルの評価結果を出力する結果出力ステップと、
を有することを特徴とするレビュー支援方法。
【請求項５】
ＵＭＬによるモデリングのレビューを支援するレビュー支援プログラムであって、
コンピュータに、
予めモデルの正当性を評価するチェック項目と内容を定義したルールをルールデータベースに設定するルール設定ステップと、
前記モデルを作成し入力するモデル入力ステップと、
前記ルールデータベースを参照し、前記モデル入力ステップにおいて入力されたモデルを前記チェック条件に基づいてチェックするルールチェックステップと、
前記ルールチェックステップにおいてチェックされた前記モデルの評価結果を出力する結果出力ステップと、
を実行させるレビュー支援プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
ＵＭＬ（(Unified Modeling Language）を用いたソフト開発やハード開発において、モデリングをレビューするにあたって、ＵＭＬモデルの完成度および品質をチェックする技術を提供する。
【背景技術】
【０００２】
オブジェクト指向によるシステム開発では、オブジェクト群の構造、オブジェクト間でのメッセージ交換など様々な視点からオブジェクトを捉え、ダイアグラム（モデル図）を使って表すことが一般的になされている。しかし、このモデル図を正確に読み取るためには、モデル図の描き方のルールが決まっている必要があり、そのルールを定めた表記法としてＵＭＬが提案され、オブジェクト指向のソフトウェア開発におけるプログラム設計図の統一表記法として普及している（例えば、非特許文献１）。
【０００３】
図９のフロー図を用いて、上記ＵＭＬのモデリング作業を説明する。図に示すように、ＵＭＬのモデルを作成（ステップＳ１０１）の後、レビューのプロセスにおいて（Ｓ１０２）、その内容を精査し判定することによって（Ｓ１０３）、内容に問題があると、レビューアーはそれを指摘し、作成者はモデルにフィードバックをかける（Ｓ１０４）。ＵＭＬの動作としては、これらのプロセスを繰り返し、モデルをブラッシュアップすることによって最終的にモデルを完成させている。ＵＭＬは、ダイアグラムの表記法であるため、規約に基づいたモデリングを行えば、モデルとして問題がないことになる。
【０００４】
しかしながら、意図したモデル化がなされているか否かについては、仕様とモデルの両方から見る必要があり、現状では、その作業を人間がレビューしているため、以下のような様々な問題を抱えている。
（１）モデルのレビューへの移行の判断は、作成者自身で主観的に行っているが、そのタイミングをどうするかが問題となっている。完成度の低いモデルであれば、レビューに時間がかかるし、必然的に、上記フローの繰り返しが多くなって非効率となる。また、ＵＭＬのモデルの完成度を評価する手段がないため、どの時点でモデルをレビューすべきかという判断は作成者の経験や勘に頼らざるを得ず、とくに、スキルの乏しい初心者には困難な作業となる。
（２）また、ＵＭＬによるモデリングにおいて、モデルの品質を測る手段は唯一レビュー以外になく、レビュー前後にモデルの品質をチェックすることはできない。
（３）さらに、レビューによるモデルの評価は、レビューアーによる主観的な評価が行われているため、レビューアーの資質に左右されてしまう。
【非特許文献１】児玉公信著、「ＵＭＬモデリングの本質」、日経バイト社、２００４年４月１２日発行
【発明の開示】
【発明が解決しようとする課題】
【０００５】
以上のように従来のＵＭＬを用いたソフトウェア開発においては、ＵＭＬモデルの完成度、品質をどう判断するかが大きな問題となっている。そこで、これらの問題を解決するため、本発明では、レビュー前後に、モデルの完成度、品質を自動的にチェックするレビュー支援装置を提供する。
【課題を解決するための手段】
【０００６】
第一の発明は、ＵＭＬによるモデリングのレビューを支援するレビュー支援装置であって、予めモデルの正当性を評価するチェック項目と内容を定義したルールをルールデータベースに設定するルール設定手段と、前記モデルを作成し入力するモデル入力手段と、前記ルールデータベースを参照し、前記モデル入力手段によって入力されたモデルを前記チェック条件に基づいてチェックするルールチェック手段と、前記ルールチェック手段によってチェックされた前記モデルの評価結果を出力する結果出力手段と、を有することを特徴とするレビュー支援装置に関する。
【０００７】
すなわち、第一の発明によれば、ルール設定手段が、ＵＭＬによるモデルの正当性を評価するチェック項目と内容に関する条件を予めルールデータベースに設定し、ルールチェック手段が、ルールデータベースのチェック項目と内容に基づいて、ユーザが作成入力したＵＭＬモデルをチェックし、結果出力手段が、表示装置などの出力装置にルール通りか否かの評価結果を出力する構成としたことによって、従来定性的であったＵＭＬモデルの完成度および品質の評価を定量的に把握でき、作成モデルの出来具合のレビューを確かなものとするレビュー支援装置を提供される。
【０００８】
第二の発明は、前記ルールチェック手段において、前記ルールデータベースのチェック項目毎にルールに違反したエラー回数を記録し、次回以降、当該エラー回数の多い項目順にチェックすることを特徴とする上記第一の発明に記載のレビュー支援装置に関する。
【０００９】
すなわち、第二の発明によれば、ルールチェック手段が、チェック項目毎にルールに違反したエラー回数をチェックして、次回以降、エラー回数の多い項目順に優先的にチェックすることになるため、早期にエラーの発見ができる。
【００１０】
第三の発明は、前記ルール定義テーブルに予めチェック項目に重み付けを設定しておき、前記ルールチェック手段において、重み付けがなされた項目を優先的にチェックすることを特徴とする上記第一の発明に記載のレビュー支援装置に関する。
【００１１】
すなわち、第三の発明によれば、ルールデータベースにおいて予めチェック項目に重み付けが設定され、チェック時に、優先的に重み付のなされた項目がチェックされ、強化したい特定箇所を重点的にチェックできることとなる。
【発明の効果】
【００１２】
以上、本発明によれば以下の効果が生じる。
（１）ルール設定手段が、ＵＭＬによるモデルの正当性を評価するチェック項目と内容に関する条件を予めルールデータベースに設定し、ルールチェック手段が、ルールデータベースのチェック項目と内容に基づいて、ユーザが作成入力したＵＭＬモデルをチェックし、結果出力手段が、表示装置などの出力装置にルール通りか否かの評価結果を出力する構成としたことによって、従来定性的であったＵＭＬモデルの完成度および品質の評価を定量的に把握でき、作成モデルの出来具合のレビューを確かなものとするレビュー支援装置を提供される。
（２）ルール違反回数を累積することでモデル品質の数値化が可能となる。ルールに重み付けするため、強化したい特定箇所を重点的にチェックでき、また、違反回数分析結果をルールデータベース（ＤＢ）に反映することで出現頻度の多い違反からチェックすることで、早期のエラー発見を可能とする。
【発明を実施するための最良の形態】
【００１３】
以下、図面にもとづいて本発明の実施形態を説明する。
【００１４】
図１は、本発明の実施の形態になるレビュー支援装置の基本構成を示す。レビュー支援装置１は、図示していないが、ＣＰＵ、メモリ、および入出力装置を備えたコンピュータであり、作成されたＵＭＬモデルをルールに沿って自動的にチェックし、チェック結果をデジタルに算出し、モデルの完成度、品質の判断を可能とするレビューを支援する装置であり、作成したＵＲＬモデルをチェックするレビュー支援プログラム１０が内部の補助記憶部に内蔵されている。
【００１５】
また、外部記憶装置２０を備え、ＵＭＬモデルの要素とその内容が記述されたモデルデータベース（ＤＢ）２１、およびＵＭＬモデルをチェックするルールが予め設定されたルールデータベース（ＤＢ）２２が格納されている。
【００１６】
さらに、レビュー支援プログラム１０は、対象とするシステム開発にあたり、ＵＭＬを用いてモデリングする場合に、従来人間がチェックするポイントがルール化されたガイドラインからＵＭＬモデルのチェック項目を抽出してルールＤＢ２２としてデータベース化するルール設定手段１１、入力装置からＵＭＬモデルを作成入力する（通常はモデリングツールによる）モデル入力手段１２、定義されたルールに基づいて入力されたＵＭＬモデルの完成度や品質をチェックするルールチェック手段１３、およびルール違反した場合の内容と総合結果を表示装置などに出力する結果出力手段１４とから構成されている。
【００１７】
なお、レビュー支援プログラム１０は、装置起動時に、格納された補助記憶部（図示していない）からメモリ３にロードされ、ＣＰＵ２によって各手段が実行される。また、当該プログラムは、フレキシブルディスク、コンパクトディスク、ＲＯＭ（Read Only Memory）等のコンピュータ読み取り可能な記録媒体に記録され、とくに、図には示していないが、内蔵あるいは外部接続された媒体読取装置にセットし、インストールすることによって実行可能な状態としてもよい。
【００１８】
図２は、本発明の実施の形態になるモデルチェックを自動化するレビュー支援装置の機能図を示す。レビュー支援装置１の本機能図は、ＵＭＬのユースケース図において表現されたものである。実施例では、アクターＸのモデル作成者からレビュー支援装置１に要求する機能として、「Ａ：モデルの完成度をチェックする機能」と、「Ｂ：モデルの品質をチェックする機能」とがあることを示している。
【００１９】
レビュー支援装置１が提供するチェック機能の概略を以下に説明する。まず、モデルの品質を判断する各種のモデリングルールをルール定義ＤＢ２２として制定し、そのルール定義ＤＢ２２に則った品質判断を行う。そして、ルールの内容によって、ポイント（評価点）の重み付けを行い、違反したルールのトータルのポイントを総合判断として、リリース可能か否か、または、レビュー可能か否か等の結果をモデルの作成者に提示する。モデル作成者は、その結果を判断材料にモデルの完成度、品質を判断する。また、ルール違反の部分は、メッセージなどで表示し、品質改善を促す。
【００２０】
図３は、本発明の実施の形態になるモデル品質をチェックするルールデータベースの構成例を示す。ルールデータベース２２は、「項番」、モデルの「チェック項目」、モデルチェックの重要度を示す「レベル」、チェックする際の条件を示す「処理方法」、チェック項目を評価する「評価点」、およびチェック時にルール違反した「エラー回数」の項目からなる複数のレコードから構成されている。
【００２１】
なお、「レベル」は、チェックの重要度のレベルを示し、「Ｎ」はノート（注記）レベル、「Ｗ」は警告レベルで、ルール違反の場合には、警告メッセージ表示とする。また、図にはないが、他に「Ｅ」エラーレベルとし、エラーメッセージ表示とする。「評価点」は重要度を加味して項目間の相対評価値を示している。点数が高くなる程、チェックの優先度が高くなる。「エラー回数」はルール違反時にカウントし、累積記録される。
【００２２】
実施例において、第一のレコードでは、チェック項目は「ダイアグラムのノート」で、レベルは「Ｎ」、処理方法は「対象ダイアグラム図のノートの有無をチェックし、値が空の場合はチェック対象とする」、評価点は「１」、およびエラー回数は「３」となっている。
【００２３】
また、第二のレコードでは、チェック項目は「パッケージ内の同一要素名／ダイアグラム名」で、レベルは「Ｗ」、処理方法は、チェック項目が（同一要素名の存在）である場合、「同パッケージ内で同一の要素名を持つ要素を抽出し、親要素が存在しない、または、親要素名が存在し、かつ要素名が存在する、ことについてチェックし、条件が一致すればチェック対象とする」、または、チェック項目が（ダイアグラム名の存在）である場合、同パッケージ内で同一のダイアグラム名を持つダイアグラムを抽出し、一致したダイアグラムをチェック対象とする」、評価点は「３」、およびエラー回数は「５」となっている。
【００２４】
さらに、第三のレコードでは、チェック項目は「要素の説明」で、レベルは「Ｗ」、処理方法は「対象要素のノートの有無をチェックし、値が空の場合にチェック対象とする」、評価点は「３」、およびエラー回数は「２」となっている。
【００２５】
図４は、本発明の実施の形態になるモデル品質をチェックするモデルデータベースの構成例を示す。モデルデータベース２１は、ＵＭＬの各要素のデータが格納され、「フィールド名」に要素名が、「データ型」および「バイト数」で規定されるデータが格納される。実施例では、例えば、項番１に、４バイト内の自動割付ナンバによるパッケージＩＤ、項番２に、２５５バイト内のテキストモードによる親パッケージ名、・・・、項番６に、６５５３５バイト内のメモモードによるノートが格納されていること示している。
【００２６】
レビュー支援装置１は、モデルＤＢ２１からチェック対象となるダイアグラムノートを検索し、その内容から情報が入っているかどうかをチェックすることとなる。
【００２７】
図５は、本発明の実施の形態になるＵＲＬモデルの品質チェックの概念を表すフローを示す。まず、ステップＳ１１において、ユーザ（モデル作成者）によってＵＭＬモデルが入力される。この場合、通常は、ＵＲＬのモデリングツールを使用しての入力作業となる。つぎに、ステップＳ１２において、作成したモデルの完成度について、レビュー支援装置１のルールデータベース（ＤＢ）２２を参照して品質チェックする。
【００２８】
ステップＳ１２で、ルールデータベース２２の参照ルール項目に違反があれば、ステップＳ１１に戻り、モデリングをやり直す。ルール違反がなければ、ステップＳ１３において、レビューの処理を行う。そして、ステップＳ１４のレビュー結果の判定においてＯＫであれば、ステップＳ１５において、再度、レビュー支援装置１のルールデータベース２２を参照して、レビュー後のチェック漏れを防止するチェックを行う。完成度が未だルールに違反したものであれば、ステップＳ１６において、レビューの指摘結果をルールデータベース２２にフィードバックするとともに、ステップＳ１３以降のレビューの処理および品質評価の処理が繰り返えされる。そして、ステップＳ１５の品質評価で最終的にレビューの全指摘事項がクリアされたときに、当該ＵＭＬモデルは、リリース可能と判定し、終了となる。
【００２９】
以上のように、レビュー前に完成度を測り、その結果からレビュー可能かどうかを判断することにより、効率的なフローを構築できる。また、レビュー後もレビューの抜けをチェックし、リリース可能かどうかのサインオフチェックが可能となる。
【００３０】
図６は、本発明の実施の形態になるＵＲＬモデルの品質チェックの処理フロー（その１）を示す。本フローは、モデルデータベース（ＤＢ）２１から対象となるモデル情報を検索し、その内容をルールＤＢのルールと比較して違反かどうかをチェックするフローを示している。
【００３１】
まず、ステップＳ２１において、ルールＤＢ２２をレビュー支援装置１のメモリに読み込み、ステップＳ２２において、モデルＤＢ２１からモデル情報を検索する。ステップＳ２３において、モデル情報の内容をルールＤＢ２２のルールとつき合わせて、違反か否かのチェックを行う。ステップＳ２４において、全ルールのチェック項目が完了するまで以上の処理を繰り返す。
【００３２】
図７は、本発明の実施の形態になるＵＲＬモデルの品質チェックの処理フロー（その２）を示す。まず、ステップＳ３１において、ユーザ（モデル作成者）によるモデル入力を受け、ステップＳ３２において、ルールＤＢ２２をメモリに読み込み、ステップＳ３３において、ユーザの作成したモデルについてルールＤＢ２２の各ルール項目をチェックする。つぎに、ステップＳ３４において、各ルール項目についてルール違反があるか否かを判定する。その結果、ルール違反であれば、ステップＳ３５において、違反の累積ポイントが加算され、ステップＳ３６において、メッセージが出力される。
【００３３】
ステップＳ３４でルール違反がなければ、次のルールチェックに移る。さらに、ステップＳ３７における全ルール項目終了となるまで、ステップＳ３３以降の処理が繰り返される。そして、ステップＳ３８において、累積ポイント（評価点）などのルールチェックの結果を表示装置に出力する。
【００３４】
なお、結果出力では、ルール違反の内容と総合結果が出力される。例えば、○○点以上はリリース不可とか、○○点以上はレビュー不可という基準を設けておくことで、モデルの品質や完成度が客観的に判断可能となる。
【００３５】
以上のように、本実施例では、ＵＭＬのモデルとモデルＤＢ２１とを読み込み、項目毎にルールをチェックし、違反しているルールについてのポイント累積を行って、最終的なポイントによってモデルの品質及び完成度を測ることが可能となる。
【００３６】
例えば、「ＵＭＬのモデルの各要素に名前が付けられていること」というルールがあった場合、ＵＭＬモデルの全ての要素に対して、名前が付けられていることをチェックする。このようなルールを全て、チェックした結果を判定して、モデルの完成度、品質をトータルに表現することができる。
【００３７】
図８は、本発明の実施の形態になるＵＲＬモデルの品質チェック結果出力例を示す。図のように、モデルチェック状態欄には、「モデルチェックが完了しました。」と表示され、結果内容欄には、実行日時、ユースケース／クラス／シーケンスなどのダイヤグラム種別、エラーレベル／警告レベルなどのチェックレベル、エラー数／警告数／ノート数などの件数、「正常に終了しました。」などのメッセージが表示されている。また、画面の下部には、「保存」および「閉じる」ボタンが設けている。
【図面の簡単な説明】
【００３８】
【図１】本発明の実施の形態になるレビュー支援装置の基本構成を示す図である。
【図２】本発明の実施の形態になるモデルチェックを自動化するレビュー支援装置の機能図である。
【図３】本発明の実施の形態になるモデル品質をチェックするルールデータベースの構成例を示す図である。
【図４】本発明の実施の形態になるモデル品質をチェックするモデルデータベースの構成例を示す図である。
【図５】本発明の実施の形態になるＵＲＬモデルの品質チェックの概念を表すフローを示す図である。
【図６】本発明の実施の形態になるＵＲＬモデルの品質チェックの処理フロー( その１) を示す図である。
【図７】本発明の実施の形態になるＵＲＬモデルの品質チェックの処理フロー（その２）を示す図である。
【図８】本発明の実施の形態になるＵＲＬモデルの品質チェック結果出力例を示す図である。
【図９】従来のＵＲＬによるモデリングのフロー
【符号の説明】
【００３９】
１  レビュー支援装置
１０  レビュー支援プログラム
１１  ルール設定手段
１２  モデル入力手段
１３  ルールチェック手段
１４  結果出力手段
２０  外部記憶装置
２１  モデルデータベース（ＤＢ）
２２  ルールデータベース（ＤＢ）
【図１】
2007265005.tif 000003
【図２】
2007265005.tif 000004
【図３】
2007265005.tif 000005
【図４】
2007265005.tif 000006
【図５】
2007265005.tif 000007
【図６】
2007265005.tif 000008
【図７】
2007265005.tif 000009
【図８】
2007265005.tif 000010
【図９】
2007265005.tif 000011