(57)【要約】【課題】複数のＵＭＬ図の関係性を明確にして誤りや矛盾の発生を防ぐことができるＵＭＬモデル作成支援方法及びその装置を提供する。【解決手段】ＵＭＬモデル作成支援装置10は、ＵＭＬモデルが図と要素と関係とから構成され、ＵＭＬモデルの変更とはＵＭＬモデルを構成する図と要素と関係のうちの少なくとも何れか１つを追加或いは削除或いは更新することであるとした定義を記憶し、この定義に基づいて、作成中のＵＭＬモデルの変更を変更履歴ＤＢ14に記録すると共に、複数の変更の間の依存関係の情報を記録する。さらに、作成中のＵＭＬモデルを変更したときに、この変更と類似した他の変更を変更履歴ＤＢ14から検索すると共に、検索によって得られた類似している変更が影響を与えた他の変更を追跡し、将来発生する可能性がある変更を作成して開発者に提示する。【選択図】図６
2006235899.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ装置を使用してＵＭＬを用いて要求分析或いはシステム設計を行う場合のＵＭＬモデル作成支援方法であって、
前記コンピュータ装置は、
ＵＭＬモデルが、図と要素と関係とから構成されるものとした定義を記憶していると共に、
ＵＭＬモデルの変更とは、ＵＭＬモデルを構成する図と要素と関係のうちの少なくとも何れか１つを追加或いは削除或いは更新することであるとした定義を記憶し、
上記の定義に基づいて、作成中のＵＭＬモデルに対して行われた変更に関する情報を変更履歴として記録する
ことを特徴とするＵＭＬモデル作成支援方法。
【請求項２】
前記コンピュータ装置は、
前記ＵＭＬモデルの変更に関する情報を新たに記録したときに、該新たな変更に影響を与えている他の変更に関する情報の記録が存在する場合、該記録として存在する他の変更が前記新たに記録した変更に対して影響を与えたという依存関係の情報を記録する
ことを特徴とする請求項１に記載のＵＭＬモデル作成支援方法。
【請求項３】
前記コンピュータ装置は、
予め定義された変更の類似度に関する情報を記憶し、
作成中のＵＭＬモデルを変更したときに、該変更と類似した他の変更を、これらの変更の類似度を判定することで前記記録されている変更履歴から検索する
ことを特徴とする請求項２に記載のＵＭＬモデル作成支援方法。
【請求項４】
前記コンピュータ装置は、
作成中のＵＭＬモデルに対して新たに変更が加えられようとしたときに、該変更と類似した変更を前記変更の類似度を判定することで前記記録されている変更履歴から検索すると共に、該検索によって得られた類似している変更が影響を与えた他の変更を追跡し、将来発生する可能性がある変更を作成して提示する
ことを特徴とする請求項３に記載のＵＭＬモデル作成支援方法。
【請求項５】
ＵＭＬを用いて要求分析或いはシステム設計を行う場合のコンピュータ装置からなるＵＭＬモデル作成支援装置であって、
ＵＭＬモデルが図と要素と関係とから構成されるものとした定義と、ＵＭＬモデルの変更とはＵＭＬモデルを構成する図と要素と関係のうちの少なくとも何れか１つを追加或いは削除或いは更新することであるとした定義を記憶する記憶手段と、
上記の定義に基づいて、作成中のＵＭＬモデルに対して行われた変更に関する情報を変更履歴として記録する変更履歴記録手段とを備えている
ことを特徴とするＵＭＬモデル作成支援装置。
【請求項６】
前記変更履歴記録手段は、前記ＵＭＬモデルの変更に関する情報を新たに記録したときに、該変更に影響を与えている他の変更に関する情報の記録が存在する場合、該記録として存在する変更が前記新たに記録した変更に対して影響を与えたという依存関係の情報を記録する手段を有する
ことを特徴とする請求項５に記載のＵＭＬモデル作成支援装置。
【請求項７】
予め定義された変更の類似度に関する情報を記憶する手段と、
作成中のＵＭＬモデルを変更したときに、該変更と類似した他の変更を、これらの変更の類似度を判定することで前記変更履歴から検索する手段とを備えている
ことを特徴とする請求項６に記載のＵＭＬモデル作成支援装置。
【請求項８】
作成中のＵＭＬモデルに対して新たに変更が加えられようとしたときに、該変更と類似した変更を前記変更の類似度を判定することで前記変更履歴から検索し、該類似している変更が影響を与えた他の変更を追跡し、将来発生する可能性がある変更を作成して提示する手段を備えている
ことを特徴とする請求項７に記載のＵＭＬモデル作成支援装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータソフトウェアを開発する作業においてＵＭＬを用いて要求分析／システム設計作業、及びそれらの仕様書作成を支援するＵＭＬモデル作成支援方法及びその装置に関する。
【背景技術】
【０００２】
一般的にソフトウェア開発は、要求分析、システム設計、実装、テスト、移行などのフェーズに分類される。このため、ソフトウェア開発者は、それぞれのフェーズで開発対象のソフトウェアをそれぞれの役割に分かれて開発を行う。
【０００３】
要求分析とは、ソフトウェアを作りたいと考えている者（要求者）の考えを汲み取り、その要求を満たすためには、ソフトウェアがどのような機能を備えるべきかを分析することである。
【０００４】
システム設計では、分析して導き出された機能を実現するには、ソフトウェアがどのような構成をしていて、どのようにふるまう必要があるのかを検討する。
【０００５】
上記の要求分析、システム設計では、しばしぱモデリングと称される手法が有効であるとされている。それは、文章だけではなく、図を用いてシステムの静的な側面と動的な側面を表現することで、システムに対する理解が深まるからである。そのモデリングのための言語として、ＵＭＬ（Unified  Modeling Language）が提案されている。
【非特許文献１】小谷正行，落水浩一郎，“ＵＭＬ文書における変更作業支援のワークフローの自動生成法に関する研究”，目本ソフトウェア科学会第２０回大会，2003.09.
【非特許文献２】田原靖太，松下誠，井上克郎：“既存ソフトウェアの変更履歴を利用したソースコード修正支援手法の提案”，情報処理学会研究報告，2002-SE-136，Vol.2002，No.23，pp.57-64，2002.3.7
【非特許文献３】版管理ソフトウェア：ＣＶＳ、構成管理ソフトウェア：Rational ClearCase、TeleLogic CM Synergy（参考URL/http://www.atmarkit.co.jp/farc/rensai/config01/config01.html）
【非特許文献４】変更管理ソフトウェア：Rational ClearQuest、TeleLogic Synergy（参考URL/http://www.atmarkit.co.jp/farc/rensai/config03/config03.html）
【特許文献１】公開特許公報「特開２００１−１６６９２４」名称「ソフトウェア開発物管理装置および管理方法」
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ソフトウェア開発において、ＵＭＬを用いて要求分析やシステム設計をすることが多くなってきており、この場合、開発者はＵＭＬを用いてシステムをモデリングすることで、要求分析及びシステム設計を行う。
【０００７】
しかし、一般的にＵＭＬモデルはシステムの多様な側面を多数の図で表現しているため、作成の難易度が高く、管理が困難である。その結果、ＵＭＬモデルを作成する際、誤りや矛盾を含んでしまう可能性があった。
【０００８】
誤りや矛盾が発生する原因の１つとして、ＵＭＬで定義されている図が多数あるだけではなく、システムの１つの機能やその相関関係を表現するために複数の図が必要で、お互いに複雑な関係性を持っていることが挙げられる。
【０００９】
このため、複数のＵＭＬ図の関係性を明確にし、誤りや矛盾の発生を防ぎ、開発者が容易に短期間でＵＭＬモデルを作成できるように支援する仕組みが必要である。
【００１０】
本発明は上記の問題点に鑑みてなされたものであり、その目的とするところは、複数のＵＭＬ図の関係性を明確にして誤りや矛盾の発生を防ぐことができるＵＭＬモデル作成支援方法及びその装置を提供することである。
【課題を解決するための手段】
【００１１】
本発明は上記の目的を達成するために、コンピュータ装置を使用してＵＭＬを用いて要求分析或いはシステム設計を行う場合のＵＭＬモデル作成支援方法であって、前記コンピュータ装置は、ＵＭＬモデルが、図と要素と関係とから構成されるものとした定義を記憶していると共に、ＵＭＬモデルの変更とは、ＵＭＬモデルを構成する図と要素と関係のうちの少なくとも何れか１つを追加或いは削除或いは更新することであるとした定義を記憶し、上記の定義に基づいて、作成中のＵＭＬモデルに対して行われた変更に関する情報を変更履歴として記録するＵＭＬモデル作成支援方法を提案する。
【００１２】
本発明のＵＭＬモデル作成支援方法によれば、ソフトウェア開発者がコンピュータ装置を使用してＵＭＬを用いて要求分析或いはシステム設計を行っている際に、コンピュータ装置は、ＵＭＬモデルが図と要素と関係とから構成されるものとした定義と、ＵＭＬモデルの変更とはＵＭＬモデルを構成する図と要素と関係のうちの少なくとも何れか１つを追加或いは削除或いは更新することであるとした定義とに基づいて、ＵＭＬモデルの変更に関する情報を変更履歴として記録する。
【００１３】
これにより、ＵＭＬモデルを構成する図と要素と関係のうちの少なくとも何れか１つが追加或いは削除或いは更新されると、この変更に関する情報が変更履歴として記録される。
【００１４】
また、本発明は上記の目的を達成するために、ＵＭＬを用いて要求分析或いはシステム設計を行う場合のコンピュータ装置からなるＵＭＬモデル作成支援装置であって、ＵＭＬモデルが図と要素と関係とから構成されるものとした定義と、ＵＭＬモデルの変更とはＵＭＬモデルを構成する図と要素と関係のうちの少なくとも何れか１つを追加或いは削除或いは更新することであるとした定義を記憶する記憶手段と、上記の定義に基づいて、作成中のＵＭＬモデルに対して行われた変更に関する情報を変更履歴として記録する変更履歴記録手段とを備えているＵＭＬモデル作成支援装置を提案する。
【００１５】
本発明のＵＭＬモデル作成支援装置によれば、ソフトウェア開発者がＵＭＬを用いて要求分析或いはシステム設計を行っている際に、ＵＭＬモデルが図と要素と関係とから構成されるものとした定義と、ＵＭＬモデルの変更とはＵＭＬモデルを構成する図と要素と関係のうちの少なくとも何れか１つを追加或いは削除或いは更新することであるとした定義とに基づいて、ＵＭＬモデルの変更に関する情報を変更履歴として記録する。
【００１６】
これにより、ＵＭＬモデルを構成する図と要素と関係のうちの少なくとも何れか１つが追加或いは削除或いは更新されると、この変更に関する情報が変更履歴として記録される。
【発明の効果】
【００１７】
本発明によれば、上記の方法及び装置により支援を受けずにＵＭＬモデルを作成していた従来の場合には、ＵＭＬモデルを変更しなければならなかった部分を見落としてＵＭＬモデルの整合性を保てなくなり、誤りや矛盾が発生したり、後にその整合性を合わせようとして手戻りが発生したが、上記の方法及び装置によって支援を受けることにより、これらの誤りや矛盾及び手戻りの発生を防ぐことができ、ソフトウェア開発者はＵＭＬモデルを容易に短期間で作成することができるようになる。
【発明を実施するための最良の形態】
【００１８】
以下、図面を参照して本発明の一実施形態を説明する。
【００１９】
本実施形態では、ＵＭＬモデルが繰り返し変更され、洗練されていくという性質を利用し、ＵＭＬモデル作成を支援する方法を構築すると共に、この方法を実施する装置を構成した。
【００２０】
本実施形態では、まず、図１の表に示すようにＵＭＬモデルの構成やＵＭＬモデルの変更を定義する。即ち、一般的にＵＭＬでは、クラス図、オブジェクト図、パッケージ図、ユースケース図、コラボレーション図、ステートチャート図、アクティビティ図、コンポーネント図、配置図の９種類の図を定義している。
【００２１】
本実施形態において、ＵＭＬ図中に記述するものは、「要素」と「関係」の２種類であると定義する。「要素」には、図１の表に記載したものがあり、この表に記載した付属情報を保持する。また、「要素」の付属情報である操作／属性は、操作／属性の付属情報を保持する。「関係」は、図１の表に記載したものがあり、この表に記載した付属情報を保持する。
【００２２】
即ち、図１に示すように、「要素」としては、クラス、オブジェクト、パッケージ、ユースケース、アクタ、インターフェース、Ｎ項関連、アクティビティ、状態、初期状態、終了状態、履歴状態、連結点、動的選択点、フォーク、ジョイン、分岐、コントロールアイコン（イベント送信）、コントロールアイコン（イベント受信）、コンポーネント、ノードが定義される。
【００２３】
また、「関係」としては、関連、リンク、集約、コンポジション、汎化、依存、実現、メッセージ、遷移、コントロールフロー、オブジェクトフローが定義される。
【００２４】
さらに、「要素」の付属情報としては、名前、属性、操作、ステレオタイプ、entryアクション、exitアクション、doアクション、includeアクション、活性区間、生存線が定義される。
【００２５】
「関係」の付属情報としては、名前、ステレオタイプ、ロール名（親／子）、多重度（親／子）、関連名の方向、親子の方向、引数、戻り値、メッセージ線、トリガ、ガード、アクションが定義される。
【００２６】
操作の付属情報としては、名前、引数、戻り値、可視性、クラス操作（static）が定義される。
【００２７】
属性の付属情報としては、名前、型、初期値、可視性、クラス属性（static）が定義される。
【００２８】
また、「関係」は方向を持ち、方向を親・子と称する。ＵＭＬモデルを構成する構成物の関係は図２のようになり、「図」に対して「要素」と「関係」が従属し、これらの「要素」と「関係」のそれぞれに「付属情報」が従属する。
【００２９】
本発明では、図３の表に示すように、ＵＭＬモデルの変更を、図の追加或いは削除或いは更新（以下、追加／削除／更新と記す）、要素の追加／削除／更新、関係の追加／削除／更新のいずれかの変更操作のことであると定義する。
【００３０】
図の追加とは、図を新規に作成することである。同様に図の削除は、図を削除することである。図の更新とは、新たに要素や関係を追加すること、既に図に記載されている要素や関係を削除或いは更新（以下、削除／更新と記す）すること、あるいは図の種別を変更することである。
【００３１】
要素の追加とは、要素を新規に作成することである。同様に要素の削除は、要素を削除することである。要素の更新とは、要素が保持する付属情報（名前、属性、操作、ステレオタイプ、entryアクション、exitアクション、doアクション、includeアクション、活性区間、生存線）を追加／削除／更新すること、あるいは要素の種別を変更することである。
【００３２】
関係の追加とは、関係を新規に作成することである。同様に関係の削除は、関係を削除することである。関係の更新とは、関係が保持する付属情報（名前、多重度（親／子）、ロール名、関連名の方向、親子の向き、ステレオタイプ、引数、戻り値、メッセージ線、トリガ、ガード、アクション）を追加／削除／更新すること、あるいは関係の種別を変更することである。
【００３３】
要素の更新の中で、特別に操作／属性の更新はより詳細に、操作／属性の付属情報（名前、引数、戻り値、可視性、クラス操作(static)またはクラス属性(static)）を追加／削除／更新することであると定義する。
【００３４】
また、全ての変更は、変更操作・変更対象・変更内容・パラメータ・ターゲットで構成される。パラメータは、追加される場合は追加される情報、更新の場合は更新される情報を格納する。ただし、削除の場合は空欄である。ターゲットは、更新される場合は更新対象の情報、削除される場合は削除対象の情報を格納する。ただし、追加の場合は空欄である。
【００３５】
次に、本実施形態では、ＵＭＬモデルが変更された過程を追跡可能な履歴を記録する方法を定義している。ここで、ＵＭＬモデルの変更を追跡する意味について説明する。ＵＭＬモデルの変更を行った時、その変更を行った影響で別の変更が発生する場合がある。それは、ＵＭＬモデルの一部を変更したことで別の部分との整合性を取れなくなるからである。例えぱ、図４に示すように、ＵＭＬ図Ａを変更したとき、整合性を保つためにＵＭＬ図Ｂを変更したとする。このとき、同様にＵＭＬ図Ｃも変更しなければなかったが、開発者はそれに気づかず見落としてしまうと、後になって整合性を取るために手戻りが発生してしまうことになる。
【００３６】
つまり、ＵＭＬ図Ａの変更は、ＵＭＬ図Ｂ及びＵＭＬ図Ｃに対して影響を与え、これらの図に変更を発生させていることになり、本実施形態ではそのような変更の影響が伝播する関係を、追跡できるように変更履歴として定義している。
【００３７】
通常、変更履歴は図５のような木構造になる。例えば、変更101を行ったことによる影響により変更111〜113が生じた場合、これらの変更の関係を変更履歴として記録する。さらに、変更111を行ったことによる影響により変更121が生じた場合、変更112を行ったことによる影響により変更122,123が生じた場合、変更113を行ったことによる影響により変更124,125が生じた場合にはこれらの変更の関係を変更履歴として記録する。
【００３８】
次に、以上のような定義及び変更履歴を用いて、ＵＭＬモデルの作成を支援する方法及びその装置の一実施形態について説明する。本実施形態では、図６に示すように、ＵＭＬモデル作成部11、変更履歴記録部12、変更推測部13、変更履歴データベース（以下、変更履歴ＤＢと称する）14、キーボードやマウス等からなる操作部15、モニターディスプレイを含む表示部16を備えたコンピュータ装置によってＵＭＬモデル作成支援システム10を構成した。尚、ＵＭＬモデル作成支援システム10は予め設定されているコンピュータプログラムによって動作する。
【００３９】
（ＵＭＬモデル作成）
ＵＭＬモデル作成部11は、ＵＭＬモデル作成を担当し、ＵＭＬモデルが図と要素と関係とから構成されるものとした定義を記憶しており、通常のＵＭＬモデル作成機能に加えて、本実施形態において作成支援のために利用する情報入力の補助、本実施形態によって得られた情報を出力する機能を持つ。
【００４０】
（変更履歴記録）
変更履歴記録部12は、ＵＭＬモデルの変更とはＵＭＬモデルを構成する図と要素と関係のうちの少なくとも何れか１つを追加或いは削除或いは更新することであるとした定義を記憶しており、上記のように定義した変更履歴記録方法を用いて変更履歴を変更履歴ＤＢ14に記録する。
【００４１】
ＵＭＬモデル作成支援システム10の各部は図７に示すように動作する。即ち、開発者が操作部15を介してＵＭＬモデル作成部11において作成しているＵＭＬモデルに変更を加えたとき、変更されたＵＭＬモデル21に関する変更を変更履歴記録部12が変更履歴ＤＢ14に記録する。
【００４２】
変更を記録する方法は、事前に変更履歴記録部12が、自動的に記録するように設定しておく方法と開発者が変更を行ったときにこの変更を記録するように明示的に選択する方法の二種類があり、これらの何れかを操作部15から設定できるようになっている。
【００４３】
自動的に記録する場合は、開発者がＵＭＬモデルを変更したときに、変更履歴記録部12はその変更を自動的に変更履歴ＤＢ14に記録した後、直前に行った変更（既に変更履歴として記録されていた変更22）から影響を受けていると判断し、直前に行った変更22と今行った変更（変更されたＵＭＬモデル21から作成した変更23）との依存関係を変更履歴ＤＢ14に記録する。開発者が明示的に変更を記録した場合は、変更履歴記録部12はその変更23を変更履歴ＤＢ14に記録した後、開発者が変更履歴ＤＢ14の中から影響を受けている変更22を選択し、変更履歴記録部12が影響を受けている変更22と今行った変更23との依存関係を変更履歴ＤＢ14に記録する。
【００４４】
変更履歴記録処理の全体の流れは、図８に示す通りである。即ち、開発者が操作部15を介してＵＭＬモデル作成部11において作成しているＵＭＬモデルに変更を加えたとき（ＳＡ１）、ＵＭＬモデル作成部11は変更自動記録に設定されているか否かを判定し（ＳＡ２）、変更自動記録に設定されているときは、変更履歴記録部12によって、上記加えられた変更23の変更操作と、変更対象、変更内容、パラメータ、及びターゲットを変更履歴ＤＢ14に記録する（ＳＡ３）と共に、この変更23と直前に行った変更22との依存関係を変更履歴ＤＢ14に記録する（ＳＡ４）。
【００４５】
また、前記ＳＡ２の判定の結果、変更自動記録に設定されておらずに開発者が変更記録を行うように設定されているときは、変更履歴記録部12によって、開発者が明示的に選択した変更23、すなわち開発者が記録するものとして選択した変更操作、変更対象、変更内容、パラメータ、及びターゲットを変更履歴ＤＢ14に記録し（ＳＡ６）、さらに変更履歴記録部12は、影響を受けた変更22が変更履歴ＤＢ14に存在するか否かを判定し（ＳＡ７）、存在するときは影響を受けた変更22と開発者が明示的に選択した変更23との依存関係を変更履歴ＤＢ14に記録する（ＳＡ８）。
【００４６】
（変更推測）
変更推測部13は、図９に示すように、作成中のＵＭＬモデルに対して新たに変更が加えられたときに動作する。即ち、開発者が操作部15を介してＵＭＬモデル作成部11において作成しているＵＭＬモデルに対して新たに変更を加えたとき、新たに加えられた変更31によって発生する可能性がある変更32を変更推測部13が推測して作成し、これを表示部16を介して開発者に提示する。
【００４７】
変更推測部13を動作させる方法としては、事前に新たに変更が加えられたときに変更推測部13が自動的に推測を行うように設定しておく方法とソフトウェア開発者が変更推測部13に推測するように指示する方法の二種類の方法があり、これらの何れかを操作部15から設定できるようになっている。
【００４８】
変更推測部13は予め定義された変更の類似度に関する情報を記憶しており、変更推測部13が動作を開始すると、変更推測部13は、新たに加えられた変更31と類似している変更33を変更履歴ＤＢ14から検索する。ここでの検索とは、変更履歴ＤＢ14に記録されている変更の類似度を図１０のフローチャートに示す手順で判定し、予め定義した類似度に基づく判定基準を満たしている変更を、類似している変更として取得することである。尚、予め定義した類似度及びこれに基づく判定基準は、変更推測部13に予め記憶されている。
【００４９】
即ち、図１０のフローチャートに示すように、変更推測部13は変更の類似度を判定する際に、先ず、変更操作が一致しているか否かを判定し（ＳＢ１）、一致していないときは類似していないものとして類似度の判定処理を終了する。また、変更操作が一致しているときは、変更対象が一致しているか否かを判定し（ＳＢ２）、変更対象が一致しているときは、変更内容が一致しているか否かを判定する（ＳＢ３）。この判定の結果、変更内容が一致しているときのみ、この変更を類似している変更として取得する（ＳＢ４）。
【００５０】
また、前記ＳＢ２の判定の結果、変更対象が一致していないときは、変更推測部13は、変更対象の種別が一致しているか否かを判定し（ＳＢ５）、変更対象の種別が一致していないときは、類似していないものとして類似度の判定処理を終了する。また、変更対象の種別が一致しているときは、変更内容が一致しているか否かを判定し（ＳＢ６）、変更内容が一致していないときは、類似していないものとして類似度の判定処理を終了する。また、変更内容が一致しているときは、この変更を類似している変更として取得する（ＳＢ７）。
【００５１】
２つの変更が類似していると判定する基準は、「変更操作」、「変更対象」、「変更対象の種別」、「変更内容」が一致しているか否かである。ただし、類似している変更は、変更履歴ＤＢ14の中に複数存在する場合がある。
【００５２】
以下に判定基準を満たす場合の一例を挙げて説明する。「変更操作が一致」という判定基準は、例えば、変更操作が「追加」の変更に類似している変更を取得しようとしているときには、同じ「追加」を行っている変更がその基準を満たしていると判定する。「削除」及び「更新」の変更操作に関しても同様である。
【００５３】
「変更対象が一致」という判定基準は、例えば、ＵＭＬモデルの要素「クラス」の中の１つである「装置クラス」を変更対象としている変更に類似している変更を取得しようとしているときには、同じ「装置クラス」を変更対象としている変更がその基準を満たしていると判定する。
【００５４】
「変更対象の種別が一致」という判定基準は、例えば、ＵＭＬモデルの要素「クラス」の中の１つである「装置クラス」を変更対象としている変更に類似している変更を取得しようとしているときには、同じ種別のＵＭＬモデルの要素「クラス」を変更対象としている変更がその基準を満たしていると判定する。
【００５５】
「変更内容が一致」という判定基準は、例えば、ＵＭＬモデルの要素に対する変更内容「名前を更新する」の変更操作を行っている変更を取得しようとしているときには、同じ「名前を更新する」の変更内容の変更を行っている変更がその基準を満たしていると判定する。
【００５６】
また、変更推測部13は検索の結果、複数の類似した変更を取得する場合があり、それぞれの変更について以下のように動作する。
【００５７】
変更推測部13は、検索した結果類似していると判定された変更33から影響が伝播した変更34を追跡する。影響された変更が１つ以上存在するならば、変更推測部13は追跡した変更34のパラメータおよびターゲットと新たに加えられた変更31のパラメータおよびターゲットを入れ替え、新たに加えられた変更31の後に発生する可能性がある変更32を推測して作成し、これを表示部16を介して開発者に提示する。
【００５８】
変更推測処理の全体の流れは、図１１のフローチャートに示す通りである。即ち、開発者が操作部15を介してＵＭＬモデル作成部11において作成しているＵＭＬモデルに変更を加えたとき（ＳＣ１）、変更推測部13は変更自動推測に設定されているか否かを判定し（ＳＣ２）、変更自動推測に設定されていないときは後述するＳＣ９の処理に移行し、変更自動推測に設定されているときは、変更推測部13が類似している変更を変更履歴ＤＢ14から取得し（ＳＣ３）、取得した変更が１つ以上であるか否かを判定する（ＳＣ４）。
【００５９】
この判定の結果、取得した変更がない場合は処理を終了し、取得した変更が１つ以上存在する場合は、変更推測部13が取得した変更33（複数ある場合はそれぞれの変更）に基づいて影響された変更を追跡する（ＳＣ５）。この後、変更推測部13は、追跡して得られた変更34が１つ以上存在するか否かを判定し（ＳＣ６）、存在しないときは処理を終了し、追跡して得られた変更34が１つ以上存在するときは、変更推測部13が追跡して得られた変更34のパラメータおよびターゲットを、新たに行った変更31のパラメータおよびターゲットと入れ替えて、発生する可能性がある変更32を作成し（ＳＣ７）、作成した変更32を表示部16を介して開発者に提示する（ＳＣ８）。
【００６０】
また、上記ＳＣ２の判定の結果、変更自動推測に設定されているときは、開発者から変更推測が指示されたか否かを判定し（ＳＣ９）、変更推測が指示されたときは、変更推測部13が類似している変更を変更履歴ＤＢ14から取得し（ＳＣ１０）、取得した変更が１つ以上あるか否かを判定する（ＳＣ１１）。
【００６１】
この判定の結果、取得した変更がない場合は処理を終了し、取得した変更が１つ以上存在する場合は、変更推測部13が取得した変更33（複数ある場合はそれぞれの変更）に基づいて変更推測部13は影響された変更を追跡する（ＳＣ１２）。
【００６２】
この後、変更推測部13は、追跡して得られた変更34が１つ以上存在するか否かを判定し（ＳＣ１３）、存在しないときは処理を終了し、追跡して得られた変更34が１つ以上存在するときは、変更推測部13が追跡して得られた変更34のパラメータおよびターゲットを、新たに行った変更31のパラメータおよびターゲットと入れ替えて、発生する可能性がある変更32を作成し（ＳＣ１４）、作成した変更32を表示部16を介して開発者に提示する（ＳＣ１５）。
【００６３】
以上の二つの動作により、変更履歴を利用して開発者がＵＭＬモデルを作成することを支援する。これにより、上記の方法及び装置により支援を受けずにＵＭＬモデルを作成していた従来の場合には、ＵＭＬモデルを変更しなければならなかった部分を見落としてＵＭＬモデルの整合性を保てなくなり、誤りや矛盾が発生したり、後にその整合性を合わせようとして手戻りが発生したが、上記の方法及び装置によって支援を受けることにより、これらの誤りや矛盾及び手戻りの発生を防ぐことができ、ソフトウェア開発者はＵＭＬモデルを容易に短期間で作成することができるようになる。
【００６４】
従って、本実施形態によれば、複数のＵＭＬ図の関係性を明確にして誤りや矛盾の発生を防ぐことができる。
【実施例１】
【００６５】
以下、本発明の一実施例を説明する。本実施例では、図１２に示すように、装置200を管理するシステム（装置管理システム）300を開発する作業を行う際に前述したＵＭＬモデル作成支援装置10を使用する。この開発対象システム300は、データベース（ＤＢ）310を備え、「管理する装置をシステム自身に登録する」機能を持つ。
【００６６】
装置管理システム300が内部に保持するＤＢ310や管理する情報を設計するために、装置管理システム300の静的な構造を分析する必要がある。そのため、ＵＭＬを用いて装置管理システム300が保持するＤＢ310のテーブルを設計するための、クラス図の１つであるテーブル設計図（図１３）を作成する。
【００６７】
また、装置管理システム300が扱う情報の構造や属性を表現するための、クラス図の１つであるデータモデル図（図１４）も作成する。これらのデータモデル図とテーブル設計図は両方とも装置管理システム300が扱う情報を表現しているため、共通した部分が多い。
【００６８】
「管理する装置をシステム自身に登録する」機能を実現する動作を装置管理システム300に行わせる必要がある。そこで、ＵＭＬを用いてシーケンス図の１つである装置を登録するシーケンス図（図１５）を作成し、装置管理システム300のふるまいを分析する。
【００６９】
ソフトウェア開発が終了するまでに、ＵＭＬモデルは繰り返し変更される。その変更の履歴を記録する一例を以下に示す。
【００７０】
装置の機種名を登録するというふるまいが、作成したシーケンス図（図１５）には記述されていないことが開発の途中で判明したとする。図１５に示すシーケンス図には、ブラウザ401と、４つのオブジェクト「JSP」402、「service」403、「DAO」404、「Entity」405、及びブラウザ401に対応する活性区間406、「service」403に対応する活性区間407、「DAO」404に対応する活性区間408、「Entity」405に対応する活性区間409が記載されている。さらに、ブラウザ401に対応する活性区間406から「service」403に対応する活性区間407への「登録する」というメッセージ410と、「service」403に対応する活性区間407から「DAO」404に対応する活性区間408への「register(name,maxRate,minRate)」というメッセージ411、および「DAO」404に対応する活性区間408から「Entity」405に対応する活性区間409へのメッセージが記載されている。
【００７１】
そこで、図１６に示すように、装置の機種名を登録するふるまい（シーケンス図内のメッセージの更新）をシーケンス図に追加するという変更を行う。
【００７２】
ここで、シーケンス図に追加した「装置の機種名を登録するというふるまい」を実行するためには、装置管理システム300がその情報（機種名）を保持するテーブルを持っていなければならない。よって、図１７に示すように、テーブル設計図のクラスＥＱＵＩＰＭＥＮＴに「ＥＱＵＩＰＭＥＮＴ＿ＮＡＭＥ」を追加する変更を行う。
【００７３】
データモデル図も装置管理システム300が管理する情報を表現しているため、図１８に示すように、同様に、データモデル図のクラスＥｑｕｉｐｍｅｎｔにも「ｅｑｕｉｐｍｅｎｔＮａｍｅ」を追加する変更を行う。
【００７４】
本実施例では、開発者は上記の変更を変更履歴記録部12が記録するように選択したとする。ここで、装置200を登録するシーケンス図との整合性を保つために影響を受けて、テーブル設計図とデータモデル図の『機種名を追加する』という変更が発生したと開発者が判断し、開発者は図１９に示すような依存関係を記録するように変更履歴記録部12に指示を出した。以上が、変更履歴の記録を行う一例である。
【００７５】
同様に、引数を更新する変更(equipmentName を equipmentNumber)は、図２０のようになる。また、引数を削除する変更(equipmentName を削除)は、図２１のようになる。
【００７６】
次に、変更履歴を利用して本発明によるＵＭＬモデル作成支援装置10がＵＭＬモデルの作成を支援する一例を説明する。
【００７７】
上記と同様に、装置200の装置ＩＤを登録するというふるまいが、図１６に示したシーケンス図には記述されていないことが判明した場合の処理について述べる。この場合、開発者は、操作部15を介して、シーケンス図に対して、図２２に示すように、装置ＩＤを登録するふるまいを追加する変更（メッセージの更新）を行う。
【００７８】
ここで開発者が操作部15を介して変更推測部13に対してこの変更を推測するように指示を出したとすると、変更推測部13は上記の『装置ＩＤを登録するふるまいを追加する』という変更（図２３）と類似した変更があるかどうか、変更履歴ＤＢ14を検索する。
【００７９】
変更推測部13は、図２３の変更と類似している変更を変更履歴ＤＢ14から取得して、変更操作が一致するか否かを調べる。すると、図１９に記録してある変更はすべて変更操作が「更新」なので一致していることになる。次に、変更推測部13は、変更対象が一致しているか否かを調べる。すると、「（シーケンス図の）メッセージ（ｒｅｇｉｓｔｅｒ）」が一致していることがわかる。さらに、変更内容が一致するか否かを調べる。すると、変更内容「引数を追加する」が一致しているため、次の変更が類似していると判定でき、その変更を図２４のように取得する。
【００８０】
次に、変更推測部13は、取得した変更が影響を与えている変更を変更履歴ＤＢ14から追跡する。すると、図１９に記録してある「（データモデル図の）クラス（Ｅｑｕｉｐｍｅｎｔ）」の変更と「（テーブル設計図の）クラス（ＥＱＵＩＰＭＥＮＴ）」の変更の二つ影響を受けていることが追跡できる。
【００８１】
そこでＵＭＬモデル作成支援装置10の変更推測部13は、『クラス（Ｅｑｕｉｐｍｅｎｔ）に対して、属性「ｅｑｕｉｐｍｅｎｔＩＤ」を追加する』と『クラス（ＥＱＵＩＰＭＥＮＴ）に対して、属性「ＥＱＵＩＰＭＥＮＴ＿ＩＤ」を追加する』に相当するような変更が将来起こりうることを推測して、図２５に示すように、発生する可能性がある変更を作成（パラメータに「ｅｑｕｉｐｍｅｎｔＩＤに相当するもの」を代入したものを作成）し、これを表示部16を介して開発者に提示する。
【００８２】
開発者は、ここでＵＭＬモデル作成支援装置10から将来起こりうる変更を提示されたので、事前にその変更が起こるか確認することができる。よって、本来ならば行わなければならなかった変更を見落とし、ＵＭＬモデルの整合性が崩れてしまう可能性を防ぐことができる。
【００８３】
上記のように、本実施例によれば、複数のＵＭＬ図の関係性を明確にして誤りや矛盾の発生を防ぐことができる。
【００８４】
以上が、記録した変更履歴を用いて開発者がＵＭＬモデルを作成するのを支援する一例である。
【００８５】
以下に、前述した従来例と本実施形態との相違点を述べる。
【００８６】
非特許文献１に記載の技術との差異：非特許文献１に記載の技術は、ＵＭＬ文書のメタモデルを定義し、その依存関係を自動的に生成することで開発者の作業支援を行おうとしているが、本実施形態ではメタモデルとして現れない依存関係に注目して、それを利用している点において相違する。
【００８７】
非特許文献２に記載の技術との差異：非特許文献２に記載の技術は、ソースコードの変更履歴を利用して、ソースコードの修正を支援する技術であるが、本実施形態は、ソフトウェア開発においてＵＭＬなどのモデルが重要性を増しているという観点からＵＭＬモデルの作成支援を行う点において相違する。
【００８８】
非特許文献３に記載の技術との差異：非特許文献３に記載の技術では、版管理、構成管理ソフトウェアによって、変更の履歴を管理・追跡することができ、その履歴を利用するのはあくまで開発者自身であるが、本実施形態では、変更履歴を積極的に活用することにより、開発者の支援を行う点において相違する。
【００８９】
非特許文献４に記載の技術との差異：非特許文献４に記載の技術は、変更管理ソフトウェアによって、プロジェクトマネジメントの視点からＵＭＬモデルの変更を管理し、変更の依頼から実行までを計画的に行い、矛盾の発生・手戻りを防いでいるが、本実施形態では、主に開発者の視点から変更間の依存関係に着目し、この依存関係を利用してＵＭＬモデルの作成を支援する点において相違する。
【００９０】
特許文献１に記載の技術との差異：特許文献１では、その請求項８，９などで過去の成果物の変更情報を参照できる方式を提案しているが、変更情報を管理してそれを参照する方式に留まっている。しかし、本実施形態では、変更情報（変更履歴）を管理するだけではなく、変更情報を積極的に利用することによりソフトウェア開発作業を支援する点において相違する。
【図面の簡単な説明】
【００９１】
【図１】本発明の一実施形態におけるＵＭＬモデルの構成に関する定義を説明する図
【図２】本発明の一実施形態におけるＵＭＬモデルの構成を示す図
【図３】本発明の一実施形態におけるＵＭＬモデルの変更に関する定義を説明する図
【図４】ＵＭＬモデルの整合性を保てない場合の一例を説明する図
【図５】本発明の一実施形態における変更履歴を説明する図
【図６】本発明の一実施形態におけるＵＭＬモデル作成支援装置を示すブロック図
【図７】本発明の一実施形態における変更記録時の動作を説明する図
【図８】本発明の一実施形態における変更記録時の処理動作を説明するフローチャート
【図９】本発明の一実施形態における変更推測時の動作を説明する図
【図１０】本発明の一実施形態における類似変更取得時の判定処理動作を説明するフローチャート
【図１１】本発明の一実施形態における発生する可能性がある変更を作成する処理動作を説明するフローチャート
【図１２】本発明の一実施例における開発対象システムと装置を示す図
【図１３】本発明の一実施例におけるテーブル設計図
【図１４】本発明の一実施例におけるデータモデル図
【図１５】本発明の一実施例における装置を登録するシーケンス図
【図１６】本発明の一実施例における変更後のシーケンス図
【図１７】本発明の一実施例における変更後のテーブル設計図
【図１８】本発明の一実施例における変更後のデータモデル図
【図１９】本発明の一実施例における記録した変更履歴を説明する図
【図２０】本発明の一実施例における引数を更新する変更の一例を示す図
【図２１】本発明の一実施例における引数を削除する変更の一例を示す図
【図２２】本発明の一実施例における変更後のシーケンス図
【図２３】本発明の一実施例における検索対象の変更を示す図
【図２４】本発明の一実施例における類似変更の取得例を説明する図
【図２５】本発明の一実施例における発生する可能性がある変更の推測例を説明する図
【符号の説明】
【００９２】
１０…ＵＭＬモデル作成支援装置、１１…ＵＭＬモデル作成部、１２…変更履歴記録部、１３…変更推測部、１４…変更履歴ＤＢ、１５…操作部、１６…表示部、２１…変更されたＵＭＬモデル、２２…記録されていた変更、２３…作成した変更、３１…新たに加えられた変更、３２…発生する可能性がある変更、３３…類似している変更、３４…影響が伝播した変更、101,111〜113,121〜125…変更、200…装置、300…開発対象システム、310…データベース（ＤＢ）、401…ブラウザ、402〜405…オブジェクト、406〜409…活性区間、410〜412…メッセージ。
【図１】
2006235899.tif 000003
【図２】
2006235899.tif 000004
【図３】
2006235899.tif 000005
【図４】
2006235899.tif 000006
【図５】
2006235899.tif 000007
【図６】
2006235899.tif 000008
【図７】
2006235899.tif 000009
【図８】
2006235899.tif 000010
【図９】
2006235899.tif 000011
【図１０】
2006235899.tif 000012
【図１１】
2006235899.tif 000013
【図１２】
2006235899.tif 000014
【図１３】
2006235899.tif 000015
【図１４】
2006235899.tif 000016
【図１５】
2006235899.tif 000017
【図１６】
2006235899.tif 000018
【図１７】
2006235899.tif 000019
【図１８】
2006235899.tif 000020
【図１９】
2006235899.tif 000021
【図２０】
2006235899.tif 000022
【図２１】
2006235899.tif 000023
【図２２】
2006235899.tif 000024
【図２３】
2006235899.tif 000025
【図２４】
2006235899.tif 000026
【図２５】
2006235899.tif 000027