JP2004110415A - ソフトウェア開発支援装置とコンピュータプログラム - Google Patents

Abstract

【課題】モデル分類されたクラスの関連付けを精度良く検証することができ、設計者に拠らない均質なソフトウェア設計情報を得ることのできるソフトウェア開発支援装置を提供する。
【解決手段】ユーザに、任意のクラス間関連情報とクラス情報を指定させるとともに、過去の設計事例から抽出した相互作用パターン情報を指定させる。指定されたクラス間関連情報とクラス情報から前記指定された相互作用パターン情報のパターンを満たすクラスとメソッドを抽出してクラス間相互作用情報を生成する。このクラス間相互作用情報を設計者が参照しながら、ＭＶＣモデルやＤＥＳｅＲＶモデルなどのモデルに分類されたクラス間の関連付けを検証することで、設計者に拠らない均質なソフトウェア設計情報が得られる。
【選択図】　　　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、例えばＷｅｂアプリケーションソフトウェアなどのソフトウェアを開発するためのソフトウェア開発支援装置とコンピュータプログラムに関するものである。
【０００２】
【従来の技術】
オブジェクト指向によるソフトウェア開発においては、プログラムの再利用性を高めてプログラム生成労力を軽減する様々な試みがなされてきた。特に、近年のコンピュータ・ハードウェアの進歩に伴うソフトウェアの肥大化により、その要請は切実なものとなっている。オブジェクト指向によるソフトウェア開発支援装置に関する従来技術には以下の特許文献１、特許文献２がある。
【０００３】
【特許文献１】
特開平９−２９２９８１号公報
【０００４】
特許文献１の発明のオブジェクト指向システム分析設計支援装置は、分析設計対象業務において特定のイベントにより行われる一連の操作内容を記述したシナリオ情報より一連の操作手順を読み込み、読込んだ各操作とエンティティオブジェクトとの使用関係を定義し、定義した各操作のオブジェクトの中からエンティティオブジェクトまたは制御オブジェクトを選出・確定し、確定したオブジェクトを用いてイベントトレース図を生成する技術が開示されている。これにより、より適切なオブジェクトに操作を配分したイベントトレース図を生成できる、としている。
【０００５】
【特許文献２】
特開平１０−２３２７７０４号公報
【０００６】
特許文献２の発明のオブジェクト指向仕様書生成装置は、業務システムの関連図の仕様書フレームを、生成済みの業務構造図および管理対象図をもとにして自動生成する技術が開示されている。
【０００７】
ところで、再利用性の高いプログラムを開発する手法の一つとして、アプリケーション・アーキテクチャの採用が挙げられる。アプリケーション・アーキテクチャとは、アプリケーションの構造を抽象的に表したもので、アプリケーション全体における各要素の役割分担を明確にするものである。
【０００８】
アプリケーションの各要素の役割分担が明確になると、各要素の組み合わせが容易にできるようになり、また、要素ごとの設計・開発作業の分担や、要素の再利用までもが可能になる。
【０００９】
代表的なアプリケーション・アーキテクチャの一つにＭＶＣモデルがある。このＭＶＣモデルは、アプリケーションをＭｏｄｅｌ（ロジック）、Ｖｉｅｗ（プレゼンテーション）、Ｃｏｎｔｒｏｌｌｅｒ（通信、制御）の三つの要素に分類したアーキテクチャであり、特にＧＵＩ（グラフィカル・設計者・インタフェース）を通じて設計者との対話環境を実現するアプリケーションを開発する場合に適するものである。
【００１０】
例えばオブジェクト指向型のアプリケーションソフトウェアを実際に開発する実装段階では、細分化したクラス群を、上記ＭＶＣモデルのいずれかの要素に分類することになる。
【００１１】
この分類作業は、ソフトウェア開発者自身が独自の判断で行うため、同一あるいは類似するプログラムであっても人によって分類が異なる場合もある。この場合、類似するソフトウェアを同じ区分で管理することができなくなり、再利用性が低下する。
【００１２】
一方、アプリケーション・アーキテクチャの要素区分を細かくすればするほど、同じ区分内のソフトウェア同士の類似性が向上し、ソフトウェアの再利用性が高まるものの、細かな一つ一つのクラスを細かく分類された要素に分類するための分類作業がソフトウェア開発者の負担になり、作業効率が低下するという問題がある。また、あまり細かな要素区分ではアプリケーション・アーキテクチャとしての汎用性が低下するという問題も生じてくる。
【００１３】
【発明が解決しようとする課題】
本発明者らは、ＭＶＣで分類されているクラス群をＤＥＳｅＲＶで分類または分割し直すことで、アプリケーション・アーキテクチャの汎用性とプログラムの再利用性とを両立させる仕組みを検討している。すなわち、ＤＥＳｅＲＶモデルでは、モデル（Ｍ）を一時的データであるデータセットおよび永続的データであるエンティティ（ＤＥ）へ、ビュー（Ｖ）をプレゼンテーションの機能をするビューへ（Ｖ）、コントローラ（Ｃ）を業務処理の機能をするサービス（Ｓｅ）およびイベントハンドラの機能をするリクエストハンドラ（Ｒ）へ分類する。
【００１４】
しかしながら、アプリケーション・アーキテクチャの要素区分をＭＶＣモデル、ＤＥＳｅＲＶモデルのような一定のルールに従ってクラス分類し、これによって得たクラス間の関連を所定の関連付けルールに従って自動生成するようにした場合、不要な関連付けも付与されてしまい、このクラス間の不要な関連付けによってソフトウェアの再利用性の劣化するおそれがあった。そこで、自動生成されたクラス間の関連情報を人間が検証する必要がある。しかし、人間による検証では精度的、効率的に限界があり、均質なソフトウェア設計情報を得ることが困難であるという課題があった。
【００１５】
そして、このような課題やこの課題を解決するための手段について、上記の特許文献１、特許文献２には何ら記載されていない。
【００１６】
本発明はこのような課題を解決するためになされたもので、モデル分類されたクラスの関連付けを精度良く検証することができ、設計者に拠らない均質なソフトウェア設計情報を得ることのできるソフトウェア開発支援装置とコンピュータプログラムの提供を目的とする。
【００１７】
【課題を解決するための手段】
上記した目的を達成するために、本発明のソフトウェア開発支援装置は、モデル分類されたクラスごとの設計情報であるクラス情報と前記クラス間の関連を表すクラス間関連情報とが記憶される設計情報記憶手段と、前記クラス間の相互作用のパターンを表す相互作用パターン情報が記憶される相互作用パターン記憶手段と、前記設計情報記憶手段の中から任意のクラス間関連情報とクラス情報を指定させるとともに前記相互作用パターン記憶手段の中から任意の相互作用パターン情報を指定させ、前記指定されたクラス間関連情報とクラス情報から前記指定された相互作用パターン情報のパターンを満たすクラスとメソッドを抽出してクラス間相互作用情報を生成するクラス間相互作用生成手段とを具備することを特徴とする。
【００１８】
この発明は、過去の設計事例から抽出した相互作用パターンに則って生成されたクラス間相互作用情報を設計者が参照しながら、ＭＶＣモデルやＤＥＳｅＲＶモデルなどのモデルに分類されたクラス間の関連付けを精度良く検証することができ、設計者に拠らない均質なソフトウェア設計情報が得られる。
【００１９】
また、本発明のソフトウェア開発支援装置は、上記の構成に加えて、前記クラス間相互作用生成手段により生成された前記クラス間相互作用情報に基づいてクラス間関連情報を生成するクラス間関連情報生成手段と、クラス間関連情報生成手段により生成されたクラス間関連情報と前記設計情報記憶手段に記憶されているクラス間関連情報とを比較して相違点を抽出し、その相違点に対して指定された処理を、前記設計情報記憶手段に記憶されているクラス間関連情報に対して実施するクラス間関連情報比較手段とをさらに具備するものである。
【００２０】
この発明では、クラス間相互作用情報から、設計情報記憶手段に記憶されているクラス間関連情報と比較可能なクラス間関連情報を生成する。各々のクラス間関連情報を比較して得られた相違点に対して設計者により指定された処理を、設計情報記憶手段にソフトウェア設計情報として記憶されているクラス間関連情報に対して実施する。これによって、モデル分類されたクラス間の関連情報を精度良く検証することができ、設計者に拠らない均質なクラス間関連情報が得られる。
【００２１】
さらに、本発明のソフトウェア開発支援装置は、上記の構成に加えて、前記設計情報記憶手段に記憶されたクラス情報およびクラス間関連情報から、前記ソフトウェア設計情報の分類モデルごとの図表を生成する図表化手段をさらに具備するものである。
【００２２】
この発明によれば、ソフトウェア設計情報の検証に用いることのできる、ソフトウェア設計情報の分類モデルごとの図表が容易に得られ、検証の効率および精度を向上できる。
【００２３】
さらに、このソフトウェア開発支援装置は、上記の構成に加えて、ＭＶＣ（モデル・ビュー・コントローラ）のモデルで分類された前記クラスのうちのＭ（モデル）を一時的データであるＤ（データセット）と永続的データであるＥ（エンティティ）とに分類するとともに、前記ＭＶＣのモデルで分類された前記クラスのうちのＶ（ビュー）をＶ（ビュー）として、かつＣ（コントローラ）を業務処理の機能をするＳ（サービス）とイベントハンドラの機能をするＲ（リクエストハンドラ）とに分類し、この分類された各クラスに関する情報をクラス情報として前記設計情報記憶手段に記憶させる分類手段と、前記分類手段により分類された各クラスを分類元の各クラスの関連付けに基づいて関連付け、この関連付けの結果をクラス間関連情報として前記設計情報記憶手段に記憶させるクラス関連付け手段とをさらに有するものであってよい。
【００２４】
この発明によれば、ＭＶＣのモデルのクラスの設計情報をＤＥＳｅＲＶモデルのクラスの設計情報に変換して、この変換されたＤＥＳｅＲＶモデルのクラスの設計情報の検証を精度良く行うことが可能になる。
【００２５】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して詳細に説明する。
【００２６】
（第１の実施形態）
本発明の第１の実施形態に係るソフトウェア開発支援装置は、たとえばパーソナルコンピュータ、ワークステーション、汎用コンピュータなどのコンピュータを用いて実現される。
【００２７】
コンピュータは、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）、主記憶であるＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）、入力デバイス、表示デバイス、インターフェース、ストレージデバイス、通信デバイス、システムバスを備えて構成される。
【００２８】
なお、以下述べる「手段」や「機構」と呼ぶものは、このコンピュータ上においてプログラムによって実現される機能を指す。「データベース」と呼ぶものはたとえばコンピュータ上においてプログラムを実行することでストレージデバイスやＲＡＭなどの記憶装置を用いて実現される機能を指す。
【００２９】
図１に、このコンピュータを用いて実現された本発明の第１の実施形態であるソフトウェア開発支援装置１０１の構成を示す。
【００３０】
同図に示すように、このソフトウェア開発支援装置１０１は、入力制御手段２１、出力制御手段２２、設計支援機構２３、ＭＶＣあるいはＤＥＳｅＲＶモデルの設計情報データベース２４、相互作用パターン情報データベース２５、相互作用パターン情報登録管理手段２９、表示テンプレートデータベース３０、および表示テンプレート登録管理手段３１を備える。
【００３１】
入力制御手段２１は、設計者であるユーザ２６からの入力を取得し、設計支援機構２３の制御手段２７に引き渡す手段である。
【００３２】
出力制御手段２２は、設計支援機構２３の制御手段２７からの情報をユーザ２６に出力情報として引き渡す手段である。
【００３３】
設計支援機構２３は、入力制御手段２１から入力情報を受け取り、クラス間相互作用情報を生成し、設計情報データベース２４へ蓄積する機構である。設計支援機構２３は、生成したクラス間相互作用情報などを必要に応じて出力制御手段２２へ引き渡す。設計支援機構２３は詳細には制御手段２７、クラス間相互作用生成手段２８、クラス間関連生成手段３６、クラス間関連比較手段３７、図表化手段４０を有している。
【００３４】
クラス間相互作用生成手段２８は、ユーザ２６により指定されたクラス情報、クラス間関連情報および相互作用パターン情報から、シーケンス図からなるクラス間相互作用情報の自動生成を行う。クラス間相互作用生成手段２８は、それらのクラス情報、クラス間関連情報および相互作用パターン情報をユーザ２６に入力制御手段２１を通じて指定させる機能を備える。
【００３５】
制御手段２７は、入力制御手段２１やクラス間相互作用生成手段２８からの入力情報を受け取り、ステータスに応じて他の手段に情報を引き渡す。また、必要に応じて各手段で生成された情報を受け取り、出力制御手段２２を通じてユーザ２６に引き渡す。
【００３６】
クラス間関連生成手段３６は、クラス間相互作用生成手段２８により生成されたクラス間相互作用情報に基づいてクラス間関連情報を自動生成する手段である。
【００３７】
クラス間関連比較手段３７は、クラス関連付け手段３４により生成され、設計情報データベース２４に記憶されているクラス間関連情報とクラス間関連生成手段３６により生成されたクラス間関連情報とを比較して相違点を抽出し、その相違点に対して指定された処理を設計情報データベース２４に記憶されているクラス間関連情報に対して実施する手段である。
【００３８】
図表化手段４０は、ユーザ２６により選択されたクラス情報、クラス間関連情報および表示テンプレートから、設計情報の分類モデルごとの図表（仕様書）を自動生成する手段である。生成された図表（仕様書）はたとえばファイルとしてストレージデバイスに保存したり、表示デバイスに表示させることができる。
【００３９】
設計情報データベース２４は、たとえばＭＶＣモデルあるいはＤＥＳｅＲＶモデルなどのクラスの設計情報として、クラス間関連情報、クラス情報、クラス間相互作用情報が蓄積されるデータベースである。
【００４０】
クラス間関連情報は、クラス間における関連の有無、および関連がある場合にはその種別を表す情報である。
【００４１】
クラス情報は、クラスが属する分類、クラス名、属性名、操作名、属性及び操作の型や引数、説明に関する情報をクラス単位に記述した情報である。
【００４２】
クラス間相互作用情報は、クラス間の相互作用を表す情報であり、対応する相互作用パターン情報、オブジェクトに対応するクラス名、メッセージ名などからなる。
【００４３】
相互作用パターン情報データベース２５は、過去の設計事例から抽出した相互作用パターン情報を蓄積するデータベースである。相互作用パターンは、オブジェクト間の一続きのシーケンスを、各オブジェクトが属する分類とメッセージの送付元及び送付先ならびに送付順について整理したものである。
【００４４】
相互作用パターン情報登録管理手段２９は、相互作用パターン情報データベース２５への相互作用パターン情報の登録・管理を行うものである。
【００４５】
表示テンプレートデータベース３０は、設計情報を分類モデルごとに図表化するための記述の雛型として用いられる表示テンプレートが蓄積されるデータベースである。
【００４６】
表示テンプレート登録管理手段３１は、表示テンプレートデータベース３０への表示テンプレートの登録・管理を行う手段である。
【００４７】
次に、このソフトウェア開発支援装置１０１の動作を説明する。
【００４８】
図２から図５にＭＶＣモデルのクラス間関連情報５５、クラス情報５６、相互作用パターン情報５８、クラス間相互作用情報５７の例を示し、図６から図９にはＤＥＳｅＲＶモデルのクラス間関連情報５５、クラス情報５６、相互作用パターン情報５８、クラス間相互作用情報５７の例を示す。
【００４９】
まず、クラス間相互作用生成手段２８は、クラス間相互作用情報５７の自動生成のための条件となるクラス間関連情報５５、クラス情報５６、および相互作用パターン情報５８をユーザ２６に指定させる。これは、たとえばクラス間相互作用情報５７の自動生成のための条件をユーザ２６に指定させるためのフォームを表示装置に表示させ、そのフォームに入力された情報を入力制御手段２１を通じて取り込むことなどによって行われる。
【００５０】
次に、クラス間相互作用生成手段２８は、ユーザ２６によって指定されたクラス情報５６およびクラス間関連情報５５に、相互作用パターン情報５８の相互作用パターンを満たすものがあるか調べる。
【００５１】
相互作用パターンを満たすものとは、以下の２つの条件を満足するクラスおよびメソッドのことである。
【００５２】
条件１：クラス情報５６およびクラス間関連情報５５から抽出できるクラスの組に相互作用パターンの関連に対応する関連が存在する。
【００５３】
条件２：条件１で抽出したクラスの組における各クラスに相互作用パターンに対応するメソッドがある。
【００５４】
（条件１について）
オブジェクト指向での一般的なルールによれば、相互作用パターンにおいてメッセージのやりとりがあるオブジェクト（クラス）間には関連が存在するということができる。
【００５５】
たとえば、ＤＥＳｅＲＶモデルを用いた場合で、図１０に示す相互作用パターン５８が指定されているものとし、その中の一部５９を取り上げて考える。この相互作用パターンの部分５９では「Ｒ＿１」のクラスから「Ｄ＿１」のクラスにメッセージが送られている。このメッセージを送るためにはオブジェクト指向の一般的にルールに則ると、「Ｒ＿１」と「Ｄ＿１」のクラス間に関連が存在する必要がある。これを条件ａとする。
【００５６】
次に、指定されているクラス間関連情報５５から条件ａを満たすクラスの組を抽出する。図１１に、抽出したクラスの関連図４６とそのデータ構造４７の例を示す。ここで関連のあるクラス同士は線で結ばれている。ここでは「データセットａ」のクラスと「Ａハンドラ」のクラスとの間には関連があるが、「データセットｂ」のクラスと「Ａハンドラ」のクラスとの間には関連がないことを示している。したがって、条件ａを満たすクラスの組は「Ｒ＿１：Ａハンドラ、Ｄ＿１：データセットａ」となる。
【００５７】
なお、クラスの組は複数あってもかまわない。たとえば「Ａハンドラ」のクラスと「データセットｂ」のクラスとの間に関連が存在する場合には、条件ａを満たすクラスの組は「Ｒ＿１：Ａハンドラ、Ｄ＿１：データセットａ」と「Ｒ＿１：Ａハンドラ、Ｄ＿１：データセットｂ」となる。
【００５８】
同様の判断を図１０に示す相互作用パターンに現れる各クラスに対して実行して行くと、条件ａを満たすクラスの組として、結果的に以下のものを取得することができる。
【００５９】
「Ｖ＿１：画面Ｘ、Ｒ＿１：Ａハンドラ、Ｄ＿１：データセットａ、Ｓｅ＿１：サービス▲１▼、…、Ｖ＿２：画面Ｙ」
【００６０】
（条件２について）
続いて、抽出した組の各クラスに相互作用パターンに対応するメソッドがあるかどうかを判定する。
【００６１】
オブジェクト指向での一般的なルールによれば、図１０に示す一部の相互作用パターン５９の場合では、メッセージの受け手である「Ｄ＿１」クラスに「（２）」に相当するメソッドが存在する必要がある。
【００６２】
このメソッドが存在していれば、条件ａを満たすクラスの組として判定されたものに当該メソッドを加え、これをクラス間相互作用情報５７の候補とする。メソッドが存在していなければ、条件ａを満たすものとして判定されていたクラスの組を候補から削除する。
【００６３】
例として、先ほど抽出したクラスの組では「Ｄ＿１」クラスに相当するのは「データセットａ」クラスであった。そこで、クラス情報５６を調べ、「データセットａ」クラスに「（２）」に相当するメソッドが存在するかどうかを調べる。ここで「データセットａ」が図１２に示すように定義されているとすると、「（２）」に相当するメソッドとして「操作１」「操作２」の２つが考えられる。
したがって、クラス間相互作用情報５７の候補は以下のものになる。
「Ｖ＿１：画面Ｘ、Ｒ＿１：Ａハンドラ、Ｄ＿１：データセットａ、Ｓｅ＿１：サービス▲１▼、…、Ｖ＿２：画面Ｙ、…、（２）：操作１、…」
「Ｖ＿１：画面Ｘ、Ｒ＿１：Ａハンドラ、Ｄ＿１：データセットａ、Ｓｅ＿１：サービス▲１▼、…、Ｖ＿２：画面Ｙ、…、（２）：操作２、…」
【００６４】
なお、ここまでの説明では、クラス間相互作用情報５７の候補は一つであったが、クラス間相互作用情報５７の候補が複数ある場合には「（２）」に対応するメソッドが２つあるため、抽出されているクラス間相互作用情報５７の候補のすべてに対して「操作１」「操作２」の場合を追加する。したがって、クラス間相互作用情報５７の候補の数は「（２）」について検討する前の２倍となる。
【００６５】
同様に、対応するメソッドの有無を相互作用パターンに存在するすべてのメソッドに対して確認して行き、最終的に得られたクラスとメソッドとの組を、最終的に生成されたクラス間相互作用情報５７とする。
【００６６】
なお、前記の説明では、全オブジェクト（クラス）について条件１をチェックした後、条件２をチェックするという手順を述べたが、個々のオブジェクト（クラス）毎に条件１のチェックと条件２のチェックを繰り返してもよい。
【００６７】
このように、クラス間相互作用生成手段２８は、クラス情報５６とクラス間関連情報５５に相互作用パターンを満たすクラスとメソッドを抽出する。これにより、たとえば図７あるいは図１１に示すようなシーケンス図からなるクラス間相互作用情報５７が得られ、設計情報データベース２４に蓄積される。
【００６８】
このように、この実施形態のソフトウェア開発支援装置１０１では、過去の設計事例から抽出した相互作用パターンに則って作成されたクラス間相互作用情報５７を設計者（ユーザ２６）が参照して、ＭＶＣモデルやＤＥＳｅＲＶモデルのクラスの関連付けを精度良く検証することができ、設計者に拠らない均質な設計情報が得られる。
【００６９】
次に、このソフトウェア開発支援装置１０１におけるクラス間関連生成手段３６およびクラス間関連比較手段３７の動作について説明する。
【００７０】
クラス間関連生成手段３６は、クラス間相互作用生成手段２８により生成されたクラス間相互作用情報５７に基づいてクラス間関連情報５５’を生成する。
【００７１】
図２７に、ＤＥＳｅＲＶモデルのクラス間相互作用情報５７からクラス間関連生成手段３６によって自動生成されたクラス間関連情報５５’の例を示す。このように、クラス間相互作用情報５７においてメッセージのやりとりが存在するオブジェクトの属するクラス間には関連が存在する、というルールに従って、クラス間関連情報５５’の自動生成が行われる。
【００７２】
この後、クラス間関連比較手段３７は、クラス間関連生成手段３６により生成されたクラス間関連情報５５’と、設計情報データベース２４に格納されている対応するクラス間関連情報５５とを比較して異なる点を抽出する。
【００７３】
図２８に、上記２つのクラス間関連情報５５、５５’の例を示す。この例での相違点は、図中（ａ）に示すクラス間関連情報５５には無かった各種情報紹介ハンドラと残高紹介画面との関連が図中（ｂ）に示すクラス間関連情報５５’に存在している点と、図中（ａ）に示すクラス間関連情報５５には存在する残高検索条件入力データと残高紹介画面との関連が図中（ｂ）に示すクラス間関連情報５５’に存在しない点の２点である。
【００７４】
このように双方のクラス間関連情報５５、５５’に相違点がある場合、クラス間関連比較手段３７は、その相違点に対してユーザ２６により指定された処理を、設計情報データベース２４に格納されている対応するクラス間関連情報５５に対して実施する。たとえば、（ａ）のクラス間関連情報５５の内容で統一したり、（ｂ）のクラス間関連情報５５’の内容で統一する、といった事項をユーザ２６が事前にあるいは相違点が確認された時点で指定し、クラス間関連比較手段３７がこの指定に従って、設計情報データベース２４に格納されているクラス間関連情報５５に対する処理を実施する。
【００７５】
これによって、設計情報データベース２４に設計情報として格納されているクラス間関連情報５５についての検証の精度が向上するとともに、設計者（ユーザ２６）に拠らない均質な設計情報が得られる。
【００７６】
次に、このソフトウェア開発支援装置１０１の図表化手段４０の動作について説明する。
【００７７】
図表化手段４０は、ＤＥＳｅＲＶ設計情報データベース２４Ｂの中からユーザ２６により選択されたクラス情報５６、クラス間関連情報５５およびクラス間相互作用情報５７と、表示テンプレートデータベース３０の中からユーザ２６により選択された表示テンプレートとに基づいて設計モデルごとの構成要素情報の図表（仕様書）を生成する。
【００７８】
図２９から図３３に、ＤＥＳｅＲＶモデルの各設計モデルの構成要素情報の図表の例を示す。ここで、図２９はビューＶの画面一覧表、図３０はサービスＳｅの一覧表、図３１はリクエストハンドラＲの一覧表、図３２はエンティティＥの一覧表、図３３はデータセットＤの一覧表の例である。
【００７９】
制御手段２７は、このように生成された設計モデルごとの構成要素情報の図表を出力制御手段２２を通じてユーザ２６に出力する。たとえば表示デバイスに表示してユーザ２６に掲示する。
【００８０】
ユーザ２６は表示された設計モデルごとの構成要素情報の図表に対して検証を行い、修正すべき箇所があれば、入力デバイスを使って修正内容を入力する。制御手段２７は入力された変更を、ＤＥＳｅＲＶ設計情報データベース２４Ｂに登録されているクラス情報５６、クラス間関連情報５５、クラス間相互作用情報５７に反映する。
【００８１】
このように本実施形態によれば、ソフトウェア開発における設計モデルごとの構成要素情報の図表（仕様書）を自動生成してユーザ２６に掲示することで、設計情報の検証、修正作業の容易化、精度向上を図ることができる。
【００８２】
（第２の実施形態）
次に、本発明の第２の実施形態であるソフトウェア開発支援装置を説明する。
【００８３】
図１３に、この第２の実施形態であるソフトウェア開発支援装置１０２の構成を示す。
【００８４】
同図に示すように、このソフトウェア開発支援装置１０２は、入力制御手段２１と、出力制御手段２２、設計支援機構２３、クラス分類の対象となるＭＶＣモデルで分類されたクラスによる設計情報が蓄積されるＭＶＣ設計情報データベース２４Ａ、ＭＶＣモデルのクラスをＤＥＳｅＲＶモデルのクラスに分類した結果が蓄積されるＤＥＳｅＲＶ設計情報データベース２４Ｂ、相互作用パターン情報データベース２５、相互作用パターン情報登録管理手段２９、表示テンプレートデータベース３０、表示テンプレート登録管理手段３１とを備える。
【００８５】
入力制御手段２１は、ユーザ２６からの入力情報を取得し、設計支援機構２３の制御手段２７に引き渡す手段である。
【００８６】
出力制御手段２２は、設計支援機構２３の制御手段２７からの情報をユーザ２６に出力情報として引き渡す手段である。
【００８７】
設計支援機構２３は、ＭＶＣモデルで分類されたクラスをＤＥＳｅＲＶのクラスに分類し直すための手段として、クラス取込手段３２、クラス分類手段３３、クラス関連付け手段３４、クラス識別手段３５を有し、さらに、制御手段２７、クラス間相互作用生成手段２８、クラス間関連生成手段３６、クラス間関連比較手段３７、図表化手段４０を有している。
【００８８】
クラス取込手段３２は、たとえば記憶媒体読み書き装置によって着脱自在な記憶媒体から読み込まれたＭＶＣモデルのクラスの設計情報をＭＶＣ設計情報データベース２４Ａに保存する手段である。
【００８９】
クラス分類手段３３は、ＭＶＣモデルのクラスの設計情報に含まれるクラスをＤＥＳｅＲＶモデルのクラスに分類する手段である。
【００９０】
クラス関連付け手段３４は、ＭＶＣモデルのクラスの設計情報から関連付け情報を抽出し、これをＤＥＳｅＲＶモデルのクラスの設計情報に反映させる手段である。
【００９１】
クラス識別手段３５は、ＭＶＣモデルのクラスの設計情報からクラス識別子を抽出して、ＤＥＳｅＲＶモデルのクラスの設計情報に反映させる手段である。
【００９２】
ＤＥＳｅＲＶモデルのクラスに分類された設計情報はＤＥＳｅＲＶ設計情報データベース２４Ｂに格納される。
【００９３】
クラス間相互作用生成手段２８は、ユーザ２６により指定されたクラス情報、クラス間関連情報および相互作用パターン情報からクラス間相互作用情報の自動生成を行う。クラス間相互作用生成手段２８は、それらのクラス情報、クラス間関連情報および相互作用パターン情報をユーザ２６に入力制御手段２１を通じて指定させる機能を備える。
【００９４】
クラス間関連生成手段３６は、クラス間相互作用生成手段２８により生成されたクラス間相互作用情報に基づいてクラス間関連情報を自動生成する手段である。
【００９５】
クラス間関連比較手段３７は、クラス関連付け手段３４により生成され、ＤＥＳｅＲＶ設計情報データベース２４Ｂに記憶されているクラス間関連情報とクラス間関連生成手段３６により生成されたクラス間関連情報とを比較して相違点を抽出し、その相違点に対して指定された処理を、ＤＥＳｅＲＶ設計情報データベース２４Ｂに記憶されているクラス間関連情報に対して実施する手段である。
【００９６】
図表化手段４０は、ユーザ２６により選択されたクラス情報、クラス間関連情報および表示テンプレートから、設計情報の分類モデルごとの図表（仕様書）を自動生成する手段である。生成された図表（仕様書）はたとえばファイルとしてストレージデバイスに保存したり、表示デバイスに表示させることができる。
【００９７】
ＭＶＣ設計情報データベース２４Ａは、ＭＶＣモデルのクラスの設計情報として、クラス間関連情報、クラス情報、クラス間相互作用情報が蓄積されるデータベースである。
【００９８】
ＤＥＳｅＲＶ設計情報データベース２４Ｂは、ＤＥＳｅＲＶモデルのクラスの設計情報として、クラス間関連情報、クラス情報、クラス間相互作用情報が蓄積されるデータベースである。
【００９９】
クラス間関連情報は、クラス間における関連の有無、および関連がある場合にはその種別を表す情報である。
【０１００】
クラス情報は、クラスが属する分類、クラス名、属性名、操作名、属性及び操作の型や引数、説明に関する情報をクラス単位に記述したものである。
【０１０１】
クラス間相互作用情報は、クラス間相互作用を表す情報であり、対応する相互作用パターン情報、オブジェクトに対応するクラス名、メッセージ名からなる。相互作用パターン情報データベース２５は、過去の設計事例から抽出した相互作用パターン情報を蓄積するデータベースである。相互作用パターンとは、オブジェクト間の一続きのシーケンスを、各オブジェクトが属する分類とメッセージの送付元及び送付先ならびに送付順について整理したものである。
【０１０２】
相互作用パターン情報登録管理手段２９は、相互作用パターン情報データベース２５への相互作用パターン情報の登録・管理を行うものである。
【０１０３】
表示テンプレートデータベース３０は、設計情報を分類モデルごとに図表化するための記述の雛型として用いられる表示テンプレートが蓄積されるデータベースである。
【０１０４】
表示テンプレート登録管理手段３１は、表示テンプレートデータベース３０への表示テンプレートの登録・管理を行う手段である。
【０１０５】
次に、ＭＶＣモデルの３つのクラス分類をＤＥＳｅＲＶモデルの５つのクラス分類に変換する動作を説明する。
【０１０６】
図１４はＭＶＣモデルによるクラス図とＤＥＳｅＲＶモデルによるクラス図との関係を示す図である。
【０１０７】
同図に示すように、ＭＶＣモデルは、ソフトウェアのロジックを担当するモデルＭ、ソフトウェアの通信・制御を担当するコントローラＣ、およびソフトウェアのプレゼンテーションを担当するビューＶなどにクラスを分類したものである。
【０１０８】
これに対してＤＥＳｅＲＶモデルは、データセットＤ、エンティティＥ、サービスＳ、リクエストハンドラＲ、およびビューＶにクラス分類したものである。すなわち、ＭＶＣのモデルＭは、一時的なデータであるデータセットＤと、永続的なデータであるエンティティＥとの２つのクラスに分類される（図中矢印▲１▼）。このような小分類にすると、データ特性ごとに別個のクラスとなるため、ソフトウェア開発における要素の再利用性を高めることができる。
【０１０９】
ＭＶＣのコントローラＣは、このコントローラＣの機能から業務処理を抽出したサービスＳと、同じくイベント受信処理を抽出したリクエストハンドラＲとの２つのクラスに分類される（図中矢印▲２▼）。このような小分類にすると、制御の機能によって別個のクラスとなるため、ソフトウェア開発における要素の再利用性を高めることができる。
【０１１０】
ビューＶは、小さく分類せずにそのままビューＶとして１つのクラスを維持する。なお、ＧＵＩに特化したソフトウェアを開発する場合は、見た目に関するオブジェクトが多く複雑になるため、ビューＶを２以上のクラスに分類してもよい。
【０１１１】
なお、本実施形態のモデルでは、５つのクラスに分類しているが、新たな機能に対応させて６以上のクラスに細分化することも可能である。ただし、ソフトウェア開発の効率を考えた場合、クラスをあまり細分化しすぎると、分類作業自体に労力がかかってしまい、よい結果が得られないこともある。
【０１１２】
次に、図１５および図１６を参照してクラスの小分類化について具体的に説明する。
【０１１３】
図１５は例えば銀行顧客管理システムなどを開発するにあたり、ＭＶＣモデルに従い分類したクラスの一例を示す図、図１６は図１５をＤＥＳｅＲＶモデルに従い再分類したクラスの一例を示す図である。
【０１１４】
銀行顧客管理システムを開発する場合に、同システムをＭＶＣモデルに従って分類すると、図１５に示すように、顧客管理データ４１と、顧客データを制御する顧客管理制御４２と、顧客データを表示する顧客管理画面４３の３つのクラスに分類される。すなわち、顧客管理データはＭＶＣモデルにおけるモデルＭに分類され、顧客管理制御４２はコントローラＣに分類され、顧客管理画面４３はビューＶに分類される。
【０１１５】
顧客管理データ４１のクラスは属性３８と操作３９とに区分されている。属性３８は、ＩＤ、氏名および連絡先などの要素を有している。操作３９は、データ取得およびデータ設定などの要素を有している。
【０１１６】
顧客管理制御４２のクラスは操作３９のみに区分されている。操作３９は、入力、登録、検索および削除などの要素を有している。
【０１１７】
顧客管理画面４３のクラスは、操作３９のみに区分されている。操作３９は、Ｏｐｅｎ、ＣｌｏｓｅおよびＵｐｄａｔｅなどの要素を有している。
【０１１８】
この銀行顧客管理システムのクラスをＤＥＳｅＲＶで再分類した場合、図１６に示すように、ＭＶＣモデルにおけるモデルＭに属する顧客管理データ４１は、データセットＤに属する顧客検索条件データ４４、顧客登録内容データ４５、銀行員検索条件データ４６、銀行員登録内容データ４７、管理者検索条件データ４８および管理者登録内容データ４９の６つのクラスと、データセットに属する顧客マスタエンティティ５０、管理者マスタエンティティ５１および銀行員マスタエンティティ５２の３つのクラスに分類される。
【０１１９】
また、ＭＶＣモデルにおけるコントローラに属する顧客管理制御４２は、サービスに属する顧客管理サービス５３と、リクエストハンドラに属する顧客管理ハンドラ５４の２つのクラスに分類される。
【０１２０】
ただし、ＭＶＣモデルにおけるビューに属する顧客管理画面４３は、１対１に分類され、そのまま顧客管理画面４３のクラスとなる。これは前述の最適化を考慮したものである。
【０１２１】
次に、この第２の実施形態であるソフトウェア開発支援装置１０２においてＭＶＣモデルからＤＥＳｅＲＶモデルへのクラス変換を行うときの動作を説明する。
【０１２２】
図１７は、このＭＶＣモデルからＤＥＳｅＲＶモデルへのクラス変換処理の流れを示すフローチャートである。
【０１２３】
ユーザ２６によるキーボードまたはマウスからの変換処理開始の指示を入力制御手段２１を介して制御手段２７が受け取ると、制御手段２７は、クラス取込手段３２に処理開始を指示する。
【０１２４】
制御手段２７からの指示により、クラス取込手段３２は、クラス取込処理を実行する（ステップＳ６１（以下Ｓ６１と称する。））。
【０１２５】
クラス取込処理が終了すると、制御手段２７は、クラス分類全てが分類されたか否かの判断を行う（Ｓ６２）。
【０１２６】
全ての分類が終了した場合（Ｓ６２のＹＥＳ）、制御手段２７は変換処理を終了する。全ての分類が終了していない場合（Ｓ６２のＮＯ）、制御手段２７はクラス分類手段３３へ処理を指示する（Ｓ６３）。
【０１２７】
クラス分類手段３３は、この指示にしたがってクラス分類処理を実行し、ＭＶＣ設計情報データベース２４Ａに記憶されているＭＶＣモデルのクラスの設計情報のクラスのうち、モデルを一時的データであるデータセットおよび永続的データであるデータセットへ、ビューをプレゼンテーションの機能をするビューへ、コントローラを業務処理の機能をするサービスおよびイベントハンドラの機能をするリクエストハンドラへ分類してＤＥＳｅＲＶモデルのクラスの設計情報を生成する（Ｓ６３）。
【０１２８】
クラス分類処理が終了すると、制御手段２７は、ＤＥＳｅＲＶモデルのクラスの設計情報に新規クラスが追加されているか否かの判定を行う（Ｓ６４）。
【０１２９】
この判定の結果、新規クラスが追加されている場合（Ｓ６４のＹＥＳ）、制御手段２７はクラス識別手段３５へ処理を指示する。この指示により、クラス識別手段３５は、クラス識別処理を実行する（Ｓ６５）。
【０１３０】
クラス識別処理が終了すると、制御手段２７は、ＭＶＣモデルと５分類モデルの関係から、ＭＶＣモデルのクラスの設計情報が有する関連付けをＤＥＳｅＲＶモデルのクラスの設計情報に適用できるか否かの判定を行う（Ｓ６６）。
【０１３１】
関連付けを適用できる場合（Ｓ６６のＹＥＳ）、制御手段２７は、クラス関連付け手段３４へ処理を指示する。この指示により、クラス関連付け手段３４はクラス関連付け処理を実行する（Ｓ６７）。
【０１３２】
クラス関連付け処理が終了すると、制御手段２７はステップＳ６８の処理を実行する（Ｓ６８）。
【０１３３】
すなわち、ステップＳ６４において新規クラスを追加していない場合（Ｓ６４のＮＯ）、ＭＶＣモデルのクラスの設計情報が持っていた関連付けを適用できない場合（Ｓ６６のＮＯ）およびクラス関連付け処理が終了した場合（Ｓ６７）、制御手段２７は、出力制御手段２２を通じて、ユーザ２６に対し導出したクラス分類を修正する必要があるか否かの判断を促し、ユーザ２６からの指示を待つ（Ｓ６８）。
【０１３４】
ユーザ２６からの指示が、クラス分類の修正である場合（Ｓ６８のＹＥＳ）、制御手段２７はクラス識別手段３５へ処理を指示する。この指示によりクラス識別手段３５はクラス識別処理を実行する（Ｓ６９）。
【０１３５】
クラス識別処理が終了するか、あるいは、クラス分類の修正なしの場合（Ｓ６８のＮＯ）、制御手段２７は処理成果物であるＤＥＳｅＲＶモデルのクラス設計情報をＤＥＳｅＲＶ設計情報データベース２４Ｂに蓄積し、ステップＳ６２の処理に戻る（Ｓ７０）。
【０１３６】
以上のステップを全て終了すると、全ての変換作業を終えたＤＥＳｅＲＶモデルのクラスの設計情報がＤＥＳｅＲＶ設計情報データベース２４Ｂに格納される。
【０１３７】
次に、クラス取込手段３２によるクラス取込処理について説明する。
【０１３８】
クラス取込手段３２は、制御手段２７を介してＭＶＣモデルのクラスの設計情報を記憶媒体から読み込む。
【０１３９】
クラス取込手段３２は、記憶媒体から読み込んだＭＶＣモデルのクラスの設計情報を、ＭＶＣ設計情報データベース２４Ａに記憶させる。
【０１４０】
取り込まれるＭＶＣモデルのクラスの設計情報は、クラス図を構成する要素の情報であり、具体的には、図１８に示すように、クラス名、パッケージ、種別、属性、操作、他クラスとの関連などがある。ここでクラス名とは、クラスを識別する名前のことである。パッケージとは、クラスが属するパッケージのことである。種別とは、ＭＶＣモデルにおけるモデル、ビュー、コントローラの中のいずれかの分類種別のことである。属性とは、そのクラスが持つデータのことであり、型や可視性などの補足情報も含まれる。操作とは、そのクラスが行う操作のことであり、返り値や引数などの補足情報も含まれる。他クラスとの関連とは、オブジェクト指向プログラミングにおける利用、関係、承継などのことである。
【０１４１】
記憶媒体から読み込む情報は任意の形式とする。一例としては、例えばＸＭＬ形式（ｅＸｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）、Ｒａｔｉｏｎａｌ　Ｒｏｓｅ（登録商標）固有のデータ形式、ＣＳＶ形式などが考えられる。
【０１４２】
ＭＶＣ設計情報データベース２４Ａに記憶されたＭＶＣモデルのクラスの設計情報は、他の処理において複数回参照されるので、作業が終了するまで初期の内容を維持したまま保存されていることが必要である。クラス取込手段３２がＭＶＣモデルのクラスの設計情報をＭＶＣ設計情報データベース２４Ａに記憶させる形式は、記憶媒体に格納されていた形式と必ずしも同一である必要はなく、独自の形式に変換して記憶させてもよい。
【０１４３】
次に、前記のクラス分類手段３３によるクラス分類処理（Ｓ６３）について説明する。
【０１４４】
クラス分類手段３３は、ＭＶＣモデルのクラスの設計情報を、新たな５つの分類からなるＤＥＳｅＲＶモデルのクラスの設計情報に小分類化する。
【０１４５】
すなわち、クラス分類手段３３は、制御手段２７からの指示を受けると、ＭＶＣ設計情報データベース２４ＡよりＭＶＣモデルに分類されているクラスの設計情報を取り込み、ＭＶＣモデルのクラスの設計情報のうち、コントローラＣを、リクエストハンドラＲとサービスＳとに小分類化する。
【０１４６】
次に、クラス分類手段３３は、取り込んだＭＶＣモデルのクラスの設計情報のうち、モデルＭをデータセットＤとエンティティＥとに小分類化する。
【０１４７】
さらに、クラス分類手段３３は、ＭＶＣモデルのクラスの設計情報のうちビューＶをそのまま新たな５分類の１つであるビューＶとして分類する。
【０１４８】
最後に、クラス分類手段３３は、ＭＶＣモデルのクラスの設計情報と、新たに５分類に分類されたＤＥＳｅＲＶモデルのクラスの設計情報とを比較して整合性をチェックする。
【０１４９】
ここで、図１９および図２０を参照して、コンピュータの画面上での操作に応じて行われるクラス分類処理について説明する。図１９はコントローラＣのクラス分類処理を実行する際の表示画面の例を示す図、図２０はモデルＭのクラス分類処理を実行する際の表示画面の例を示す図である。
【０１５０】
クラス分類処理の際、図１９に示すように、モニタ画面１１０には、コントローラＣに属する顧客管理制御４２のクラスを示すウィンドウ１１８ａと、コントローラＣから小分類化されたサービスＳに属する顧客管理サービス５３のクラスを示すウィンドウ１１８ｂ、同じく小分類化されたリクエストハンドラＲに属する顧客管理ハンドラ５４のクラスを示すウィンドウ１１８ｃとが表示される。
【０１５１】
顧客管理制御４２のクラスを示すウィンドウ１１８ａには、操作窓１１１ａ、属性窓１１２ａ、分類のボタン１１３ａおよび識別子１１９ａなどが表示される。
【０１５２】
顧客管理サービス５３のクラスを示すウィンドウ１１８ｂには、操作窓１１１ｂ、属性窓１１２ｂ、追加のボタン１１３ｂおよび識別子１１９ｂなどが表示される。
【０１５３】
顧客管理ハンドラ５４のクラスを示すウィンドウ１１８ｃには、操作窓１１１ｃ、属性窓１１２ｃ、追加のボタン１１３ｃおよび識別子１１９ｃなどが表示される。
【０１５４】
操作窓１１１ａには、顧客管理制御４２のクラスにおける操作３９の要素である入力１１４ａ、登録１１５ａおよび検索１１６などが表示される。
【０１５５】
操作窓１１１ｂには、顧客管理サービス５３のクラスにおける操作３９の要素である登録１１５ｂなどが表示される。
【０１５６】
また、操作窓１１１ｃには、顧客管理ハンドラ５４のクラスにおける操作３９の要素である顧客情報入力１１４ｃおよび顧客情報管理選択１１７などが表示される。
【０１５７】
ユーザ２６が、マウスにより顧客管理制御４２のクラスにおける操作３９の要素である入力１１４ａをクリックし、顧客管理ハンドラ５４のクラスにおける操作３９の要素へドラッグ＆ドロップ操作を行い、キーボードにより名称を変更する操作を行うと、制御手段２７は、入力制御手段２１を通じて指示を受け取り、クラス分類手段３３に対して、入力１１４ａを顧客管理ハンドラ５４のクラスにおける操作３９の要素へ分類して名称を変更するように指示を出す。そして、制御手段２７は、出力制御手段２２に対して、入力１１４ａの表示を反転させるとともに、名称が変更された入力１１４ａである顧客情報入力１１４ｃを顧客管理ハンドラ５４のクラスにおける操作窓１１１ｃに表示するように指示する（図中矢印▲１▼）。
【０１５８】
同様に、ユーザ２６が、マウスにより顧客管理制御４２のクラスにおける操作３９の要素である登録１１５ａをクリックし、顧客管理サービス５３のクラスにおける操作３９の要素へドラッグ＆ドロップ操作を行うと、制御手段２７は、入力制御手段２１を通じて指示を受け取り、クラス分類手段３３に対して、登録１１５ａを顧客管理サービス５３のクラスにおける操作３９の要素へ分類するように指示を出す。そして、制御手段２７は、出力制御手段２２に対して、登録１１５ａの表示を反転させるとともに、登録１１５ｂを顧客管理サービス５３のクラスにおける操作窓１１１ｂに表示するように指示する（図中矢印▲２▼）。
【０１５９】
ユーザ２６によりキーボードあるいはマウスが操作されて分類処理終了の指示が行われると、制御手段２７は、入力制御手段２１を通じて指示を受け取り、クラス分類手段３３に対してモニタ画面１１０に表示されたクラス情報５６をＤＥＳｅＲＶモデルのクラスの設計情報としてＤＥＳｅＲＶ設計情報データベース２４Ｂに記憶させるように指示を出す。
【０１６０】
ユーザ２６によりマウスにて追加のボタン１１３ｂがクリックされ、ユーザ２６からサービスに属するクラスを追加する指示が行われると、制御手段２７は、入力制御手段２１を通じて指示を受け取り、クラス分類手段３３に対して、サービスに新たなクラスを追加するように指示する。そして、制御手段２７は、出力制御手段２２に対し、サービス内に新たなクラスを表すウィンドウ１１８ｄを表示するように指示する。これはリクエストハンドラに係る追加指示においても同様である。
【０１６１】
クラス分類の際、図２０に示すように、モニタ画面１２０には、モデルＭに属する顧客管理データ４１のクラスを示すウィンドウ１２８ａと、モデルＭから小分類化されたデータセットＤに属する顧客検索条件データ４４のクラスを示すウィンドウ１２８ｂと、同じく小分類化されたデータセットＤに属する顧客マスタエンティティ５０のクラスを示すウィンドウ１２８ｃとが表示される。
【０１６２】
顧客管理データ４１のクラスを示すウィンドウ１２８ａには、操作窓１２１ａ、属性窓１２２ａ、分類のボタン１２３ａおよび識別子１２９ａなどが表示される。
【０１６３】
顧客検索条件データ４４のクラスを示すウィンドウ１２８ｂには、操作窓１２１ｂ、属性窓１２２ｂ、追加のボタン１２３ｂおよび識別子１２９ｂなどが表示される。
【０１６４】
顧客マスタエンティティ５０のクラスを示すウィンドウ１２８ｃには、操作窓１２１ｃ、属性窓１２２ｃ、追加のボタン１２３ｃおよび識別子１２９ｃなどが表示される。
【０１６５】
操作窓１２１ａには、顧客管理データ４１のクラスにおける操作３９の要素であるデータ設定１２４ａおよびデータ取得１２５ａなどが表示される。
【０１６６】
操作窓１２２ａには、顧客管理データ４１のクラスにおける属性３８の要素であるＩＤ１２６ａ、氏名１２７ａおよび連絡先１３０ａなどが表示される。
【０１６７】
操作窓１２１ｃには、顧客マスタエンティティ５０のクラスにおける操作３９の要素であるデータ設定１２４ｃおよびデータ取得１２５ｃなどが表示される。また、操作窓１２２ｃには、顧客マスタエンティティ５０における属性３８の要素であるＩＤ１２６ｃ、氏名１２７ｃおよびパスワード１３０ｃなどが表示される。
【０１６８】
ユーザ２６が、マウスにより顧客管理データ４１のクラスにおける操作３９の要素であるデータ設定１２４ａおよびデータ取得１２５ａをクリックし、顧客マスタエンティティ５０のクラスにおける操作３９の要素へドラッグ＆ドロップ操作を行うと、制御手段２７は、入力制御手段２１を通じて指示を受け取り、クラス分類手段３３に対して、データ設定１２４ａおよびデータ取得１２５ａを顧客マスタエンティティ５０のクラスにおける操作３９の要素へ分類するように指示を出す。そして、制御手段２７は、出力制御手段２２に対して、データ設定１２４ａおよびデータ取得１２５ａの表示を反転させるとともに、データ設定１２４ｃおよびデータ取得１２５ｃを顧客マスタエンティティ５０のクラスにおける操作窓１２１ｃに表示するように指示する（図中矢印▲１▼）。
【０１６９】
同様に、ユーザ２６が、マウスにより顧客管理データ４１のクラスにおける属性３８の要素であるＩＤ１２６ａおよび氏名１２７ａをクリックし、顧客マスタエンティティ５０のクラスにおける属性３８の要素へドラッグ＆ドロップ操作を行うと、制御手段２７は、入力制御手段２１を通じて指示を受け取り、クラス分類手段３３に対して、ＩＤ１２６ａおよび氏名１２７ａを顧客マスタエンティティ５０のクラスにおける属性３８の要素へ分類するように指示する。そして、制御手段２７は、出力制御手段２２に対して、ＩＤ１２６ａおよび氏名１２７ａの表示を反転させるとともに、ＩＤ１２６ｃおよび氏名１２７ｃを顧客マスタエンティティ５０のクラスにおける属性窓１２２ｃに表示するように指示する（図中矢印▲２▼）。
【０１７０】
ユーザ２６によりキーボードあるいはマウスが操作されて分類処理終了の指示が行われると、制御手段２７は、入力制御手段２１を通じて指示を受け取り、クラス分類手段３３に対してモニタ画面１２０に表示されたクラス情報５６をＤＥＳｅＲＶモデルのクラスの設計情報としてＤＥＳｅＲＶ設計情報データベース２４Ｂに記憶させるように指示を出す。
【０１７１】
ユーザ２６によりマウスにて追加のボタン１２３ｂがクリックされ、ユーザ２６からデータセットＤに属するクラスを追加する指示が行われると、制御手段２７は、入力制御手段２１を通じて指示を受け取り、クラス分類手段３３に対して、データセットＤに新たなクラスを追加するように指示する。そして、制御手段２７は、出力制御手段２２に対して、データセット内に新たなクラスを表すウィンドウ１２８ｄを表示するように指示する。これは、データセットＤに係る追加指示においても同様である。
【０１７２】
また、ユーザ２６によりキーボードの操作が操作されて顧客マスタエンティティ５０のクラスにおける属性３８にパスワード１３０ｃの要素を追加する指示が行われると、制御手段２７は、入力制御手段２１を通じて指示を受け取り、クラス分類手段３３に対して、パスワード１３０ｃを顧客マスタエンティティ５０のクラスにおける属性３８に追加するように指示する。そして、制御手段２７は、出力制御手段２２に対して、パスワード１３０ｃを顧客マスタエンティティ５０のクラスにおける属性３８の属性窓１２２ｃに表示するように指示する。
【０１７３】
次に、図２１を参照してクラス関連付け手段３４によるクラス関連付け処理（Ｓ６７）について説明する。
【０１７４】
クラス関連付け手段３４は、ＭＶＣモデルのクラスの関連付けを以下のように行う。
【０１７５】
制御手段２７から処理の指示を受けると、クラス関連付け手段３４は、ＭＶＣ設計情報データベース２４Ａに記憶されているＭＶＣモデルのクラスの設計情報をコンピュータ内のメモリ（ＲＡＭ）に読み込む（Ｓ１３１）。
【０１７６】
ＭＶＣモデルのクラスの設計情報がメモリ上に読み込まれると、クラス関連付け手段３４は、メモリ上のＭＶＣモデルのクラスの設計情報からＭＶＣモデルにおけるクラスの関連付け情報を抽出する（Ｓ１３２）。
【０１７７】
クラスの関連付け情報を抽出すると、クラス関連付け手段３４は、自身にプログラムされている関連付けルールにしたがって抽出した関連付け情報を変換する（Ｓ１３３）。
【０１７８】
関連付け情報の変換後、新たな関連付けを適用したクラス情報５６がモニタに表示される（Ｓ１３４）。
【０１７９】
ユーザ２６によってキーボードまたはマウスなどから修正指示が行われた場合（Ｓ１３５のＹＥＳ）、クラス関連付け手段３４は、その修正指示を入力制御手段２１および制御手段２７を介して修正情報として受け取り、メモリ上の該当関連付け情報を修正する（Ｓ１３６）。
【０１８０】
また、ユーザ２６によりキーボードまたはマウスなどから処理続行が指示された場合（Ｓ１３５のＮＯ）、および上記メモリ上の関連付け情報が修正された場合（Ｓ１３６）、クラス関連付け手段３４は、メモリ上の関連付け情報をＤＥＳｅＲＶモデルのクラスの設計情報に適用してＤＥＳｅＲＶ設計情報データベース２４Ｂに記憶させる（Ｓ１３７）。
【０１８１】
ここで、図２２を参照してクラス関連付け手段３４に定義されている関連付けルールについて説明する。
【０１８２】
関連付けルールは、ＭＶＣモデルにおける各クラス間の関連と、ＤＥＳｅＲＶモデルにおける各クラス間の関連との関係を定義したものである。
【０１８３】
具体的には、変換元のＭＶＣモデルのＭＶＣモデルのクラスの設計情報のクラスにおいてコントローラＣとモデルＭが関連付けられていた場合、クラス関連付け手段３４は、「関連のあるＣ、Ｍから分類したＲ、Ｄ間を関連付ける」というルールを適用し、ＤＥＳｅＲＶモデルのクラスの設計情報のクラスにおけるリクエストハンドラＲとデータセットＤを関連付ける（１４１）。
【０１８４】
同様に、変換元のＭＶＣモデルのＭＶＣモデルのクラスの設計情報のクラスにおいてコントローラＣとモデルＭが関連付けられていた場合、クラス関連付け手段３４は、「関連のあるＣ、Ｍから分類したＲ、Ｖ間を関連付ける」というルールを適用し、ＤＥＳｅＲＶモデルのクラスの設計情報のクラスにおけるサービスＳとエンティティＥを関連付ける（１４３）。ＭＶＣモデルのクラスの設計情報のクラスにおいてコントローラＣとビューＶが関連付けられていた場合も同様である（１４４）。
【０１８５】
また、関連付けるべきクラスがリクエストハンドラＲとサービスＳである場合、クラス関連付け手段３４は、「同じＣから分類したＲ、Ｓ間を関連付ける」というルールを適用し、ＤＥＳｅＲＶモデルのクラスの設計情報のクラスにおけるリクエストハンドラＲとサービスＳを関連付ける（１４２）。関連付けるべきクラスがリクエストハンドラＲ同士である場合も同様である（１４）。
【０１８６】
図２３は、ＭＶＣモデルをＤＥＳｅＲＶモデルに変換した状態を示す図である。図２４は２つのモデルＭ１およびモデルＭ２、１つのコントローラＣ１および２つのビューＶ１およびビューＶ２の各クラスに分類されたＭＶＣモデルの例である。図２５は図２２に示した関連付けルールを用いて関連付けを行った状態を示す図であり、図２６は図２５の状態から手動修正を行って不要な関連付けを取り除いた状態を示す図である。
【０１８７】
図２３に示すように、モデルＭ１、コントローラＣ１およびビューＶ１からなる変換元のＭＶＣモデルは、データセットＤ１〜Ｄ３、エンティティＥ１〜Ｅ２、サービスＳ１、リクエストハンドラＲ１およびビューＶ１からなる５分類によるモデルに変換されている。変換前のクラスＣ１とクラスＭ１の関連（図中▲１▼）は、変換後のクラスＲ１とクラスＤ１〜Ｄ３の関連（図中▲２▼〜▲４▼）ならびにクラスＳ１とクラスＥ１〜Ｅ２の関連（図中▲５▼、▲６▼）に変換されている。すなわち、１つの関連付けが５つの関連付けに変換されている。
【０１８８】
ここで、変換前のクラスが５つある場合の変換について説明する。図２４に示すＭＶＣモデルは、図２３に示したＭＶＣモデルよりもクラス間の関連付けの数が多くなっている。そのため、図２４のクラス図に図２２の関連付けルールを機械的に適用すると、図２２に示す関係を有するクラス間全てに関連付けがなされ、変換後のクラス図は図２５に示すように各クラスよりの関連付けを示す線が双方に伸びて関連付けが複雑になる。
【０１８９】
例えば、図２４におけるコントローラのクラスＣ１は、変換の結果、図２５に示す３つのサービスのクラスＳ１１、Ｓ１２、Ｓ２１と、２つのリクエストハンドラのクラスＲ１、Ｒ２に細分化されている。また、図２４におけるビューＶ１およびＶ２は、変換の結果、図２５においてもそのままビューＶ１およびＶ２として維持されている。そして、リクエストハンドラのクラスＲ１、Ｒ２は、ビューのクラスＶ１、Ｖ２とそれぞれ関連付けられている。すなわち、クラスＲ１、クラスＲ２、クラスＶ１およびクラスＶ２の間で、４つの関連付けが行われたことになる。
【０１９０】
しかし、ソフトウェアの機能として必要な関連付けは、クラスＲ１とクラスＶ１、クラスＲ２とクラスＶ２の関連付けのみであり、他の２つの関連付けは本来不要のものである。
【０１９１】
図２５における他のクラスについても同様である。例えば、クラスＲ１は、クラスＳ１１、クラスＳ１２、クラスＳ２１、クラスＤ１１、クラスＤ１２およびクラスＤ２１とも関連付けられているが、本来リクエストハンドラとして１つの機能だったクラスをクラスＲ１とクラスＲ２に分けているのであるから、それぞれに対応するデータセットのクラスおよびサービスのクラスとのみ関連付ければ足りるものである。
【０１９２】
リクエストハンドラをクラスＲ１とクラスＲ２に分類し、ビューをクラスＶ１とクラスＶ２に分類したのは、機能ごとに小分類化してソフトウェアの再利用を図るためである。しかし、分類したクラス全てを関連付けるとすると、ソフトウェアの再利用化は図れても、クラス間のやり取りを変換前よりも増やしたことになり、これではソフトウェア開発の難度が以前よりも増してしまうことになる。そこで、このソフトウェア開発支援装置では、関連付けを修正し不要な関連付けを削除するためのエディタの機能を用意している。具体的には、図９および図１０に示すようなＧＵＩ環境においてマウスなどによりドラッグ＆ドロップ操作をすることにより実現される。
【０１９３】
図２６は図２５に示したクラス図についてユーザ２６が関連付けを修正した状態を示す図である。
【０１９４】
例えば、図２５に示したクラス図でのクラスＲとクラスＳの関連付けについてみると、クラスＲ１はクラスＳ１１、クラスＳ１２およびクラスＳ２１の全てと関連付けられていたが、この図２６に示すクラス図では、クラスＳ１１およびクラスＳ１２とのみ関連付けられており、３つのクラスＳ１１、Ｓ１２、Ｓ２１から２つのクラスＳ１１、Ｓ１２に整理されていることがわかる。
【０１９５】
同様に、図２５に示すクラス図でのクラスＳとクラスＥの関連付けについてみると、クラスＳ１１は、クラスＥ１１１、クラスＥ１１２、クラスＥ１２１およびクラスＥ２１１の全てと関連付けられていたが、図２６に示すクラス図では、クラスＥ１１１およびクラスＥ１１２とのみ関連付けられており、４つのクラスＥ１１１、Ｅ１１２、Ｅ１２１、Ｅ２１１から２つのクラスＥ１１１、Ｅ１１２に整理されていることがわかる。
【０１９６】
次に、図１５および図１６を参照しながらクラス識別手段３５による処理（Ｓ６５、Ｓ６９）について説明する。
【０１９７】
クラス識別手段３５は、分類した各クラスに対して、そのクラスがデータセット、エンティティ、サービス、リクエストハンドラおよびビューのいずれに属するかを示す識別子を付ける手段である。
【０１９８】
例えば、図１６のデータセットについてみると、クラス識別手段３５は、図１５における変換元であるモデルの「＜＜Ｍｏｄｅｌ＞＞」という識別子に基づき、図１６におけるデータセットの各クラスに「＜＜ＤａｔａＳｅｔ＞＞」という識別子を付し、各クラスがデータセットに分類されていることが一目で判別できるようにする。
【０１９９】
本実施形態では、ＵＭＬ（Ｕｎｉｆｉｅｄ　Ｍｏｄｅｌｉｎｇ　Ｌａｎｇｕａｇｅ）の表記であるステレオタイプを活用した識別子と、接尾語を合わせる識別子の２通りを採用している。
【０２００】
ステレオタイプを活用した識別子とは、ＵＭＬ表記法に則った識別子であり、図１６における「＜＜Ｄａｔａ　Ｓｅｔ＞＞」「＜＜Ｅｎｔｉｔｙ＞＞」などがこれに該当する。語尾を合わせる識別子は、図１６における「○○データ」「○○エンティティ」などがこれに該当する。
【０２０１】
クラス識別手段３５は、ＭＶＣモデルと新たな５分類モデルの関係に基づいて、ステレオタイプを活用した識別子を、分類処理がなされた設計情報に対して適用する。例えば、図１９において、クラス識別手段３５は、顧客管理サービス５３のクラスを示すウィンドウ１１８ｂに、「＜＜Ｓｅｒｖｉｃｅ＞＞」の識別子１１９ｂを表示する処理を制御手段２７に指示し、また、顧客管理ハンドラ５４のクラスを示すウィンドウ１１８ｃに、「＜＜Ｒｅｑｕｅｓｔ　ｈａｎｄｌｅｒ＞＞」の識別子１１９ｃを表示する処理を制御手段２７に指示する。
【０２０２】
また、クラス識別手段３５は、語尾を合わせる識別子についてユーザ２６がキーボードなどにより識別子を付す指示を発すると、入力制御手段２１を通じて指示内容を受け取り、識別子を表示する処理を制御手段２７に指示する。
【０２０３】
次に、この第２の実施形態であるソフトウェア開発支援装置１０２においてクラス間関連の検証に係る動作について説明する。
【０２０４】
まず、クラス間相互作用生成手段２８は、前記第１の実施形態と同様に、ＤＥＳｅＲＶ設計情報データベース２４Ｂの中からクラス間相互作用情報５７の自動生成のための条件となるクラス間関連情報５５およびクラス情報５６をユーザ２６に指定されるとともに、相互作用パターン情報データベース２５の中から任意の相互作用パターン情報５８をユーザ２６に指定させる。
【０２０５】
次に、クラス間相互作用生成手段２８は、ユーザ２６によって指定されたクラス情報５６およびクラス間関連情報５５に、相互作用パターン情報５８の相互作用パターンを満たすものがあるか調べる。相互作用パターンを満たすものが存在する場合は、クラス間相互作用生成手段２８は、クラス情報５６とクラス間関連情報５５から相互作用パターンを満たすクラスとメソッドを抽出し、たとえば図５あるいは図９に示すようなシーケンス図からなるクラス間相互作用情報５７を生成し、ＤＥＳｅＲＶ設計情報データベース２４Ｂに蓄積する。
【０２０６】
クラス間関連生成手段３６は、前記のようにしてクラス間相互作用生成手段２８により生成されたクラス間相互作用情報５７に基づいてクラス間関連情報５５’を生成する。
【０２０７】
図２７に、ＤＥＳｅＲＶモデルのクラス間相互作用情報５７からクラス間関連生成手段３６によって自動生成されたクラス間関連情報５５’の例を示す。このように、クラス間相互作用情報５７においてメッセージのやりとりが存在するオブジェクトの属するクラス間には関連が存在する、というルールに従って、クラス間関連情報５５’の自動生成が行われる。
【０２０８】
この後、クラス間関連比較手段３７は、クラス間関連生成手段３６により生成されたクラス間関連情報５５’と、クラス関連付け手段３４によって生成され、ＤＥＳｅＲＶ設計情報データベース２４Ｂに格納されている対応するクラス間関連情報５５とを比較して異なる点を抽出する。
【０２０９】
図２８に、上記２つのクラス間関連情報５５、５５’の例を示す。この例での相違点は、図中（ａ）に示すクラス間関連情報５５には無かった各種情報紹介ハンドラと残高紹介画面との関連が図中（ｂ）に示すクラス間関連情報５５’に存在している点と、図中（ａ）に示すクラス間関連情報５５には存在する残高検索条件入力データと残高紹介画面との関連が図中（ｂ）に示すクラス間関連情報５５’に存在しない点の２点である。
【０２１０】
このように双方のクラス間関連情報５５、５５’に相違点がある場合、クラス間関連比較手段３７は、その相違点に対してユーザ２６により指定された処理を、設計情報データベース２４に格納されている対応するクラス間関連情報５５に対して実施する。たとえば、（ａ）のクラス間関連情報５５の内容で統一したり、（ｂ）のクラス間関連情報５５’の内容で統一する、といった事項をユーザ２６が事前にあるいは相違点が確認された時点で指定し、クラス間関連比較手段３７がこの指定に従って、ＤＥＳｅＲＶ設計情報データベース２４Ｂに格納されているクラス間関連情報５５に対する処理を実施する。
【０２１１】
これによって、ＤＥＳｅＲＶ設計情報データベース２４Ｂに設計情報として格納されているクラス間関連情報５５についての検証の精度が向上するとともに、設計者（ユーザ２６）に拠らない均質な設計情報が得られる。
【０２１２】
次に、このソフトウェア開発支援装置１０２の図表化手段４０の動作について説明する。
【０２１３】
図表化手段４０は、ＤＥＳｅＲＶ設計情報データベース２４Ｂの中からユーザ２６により選択されたクラス情報５６、クラス間関連情報５５およびクラス間相互作用情報５７と、表示テンプレートデータベース３０の中からユーザ２６により選択された表示テンプレートとに基づいて設計モデルごとの構成要素情報の図表（仕様書）を生成する。
【０２１４】
図２９から図３３に、ＤＥＳｅＲＶモデルの各設計モデルごとの構成要素情報の図表の例を示す。ここで、図２９はビューＶの一覧表、図３０はサービスＳｅの一覧表、図３１はリクエストハンドラＲの一覧表、図３２はエンティティＥの一覧表、図３３はデータセットＤの一覧表の例である。
【０２１５】
制御手段２７は、このように生成された設計モデルごとの構成要素情報の図表を出力制御手段２２を通じてユーザ２６に出力する。たとえば表示デバイスに表示してユーザ２６に掲示する。
【０２１６】
ユーザ２６は表示された設計モデルごとの構成要素情報の図表に対して検証を行い、修正すべき箇所があれば、入力デバイスを使って修正内容を入力する。制御手段２７は入力された変更を、ＤＥＳｅＲＶ設計情報データベース２４Ｂに登録されているクラス情報５６、クラス間関連情報５５、クラス間相互作用情報５７に反映する。
【０２１７】
このように本実施形態によれば、ソフトウェア開発における設計モデルごとの構成要素情報の図表（仕様書）を自動生成してユーザ２６に掲示することで、設計情報の検証、修正作業の容易化、精度向上を図ることができる。
【０２１８】
上記実施形態におけるソフトウェア（プログラム）は、コンピュータが読み出し可能で着脱自在な記憶媒体に記憶されていてもよく、また、ソフトウェア（プログラム）単体として伝送されるものでもよい。この場合、記憶媒体に記憶されたソフトウェア（プログラム）をコンピュータが読み出したり、ＬＡＮやインターネッ上のサイト（サーバ）からダウンロードしてインストールすることにより、各実施形態における処理が可能になる。
【０２１９】
つまり、本発明におけるソフトウェア（プログラム）は、コンピュータと独立した記憶媒体に記憶されているものだけに限らず、ＬＡＮやインターネットなどの伝送媒体を介して流通されるものも含まれる。
【０２２０】
また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワークソフトなどのＭＷ（ミドルウェア）などが本実施形態を実現するための各処理の一部を実行してもよい。
【０２２１】
なお、コンピュータは、記憶媒体に記憶されたプログラムに基づき、本実施形態における各処理を実行するものであって、パソコンなどの一つからなる装置、複数の装置がネットワーク接続されたシステムなどのいずれの構成であっても良い。
【０２２２】
【発明の効果】
以上説明したように本発明によれば、ＭＶＣモデルやＤＥＳｅＲＶモデルなどのモデル分類されたクラス間の関連情報を精度良く検証することができ、設計者に拠らない均質なソフトウェア設計情報が得られる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態であるソフトウェア開発支援装置の構成を示すブロック図である。
【図２】ＭＶＣモデルのクラス間関連情報の例を示す図である。
【図３】ＭＶＣモデルのクラス情報の例を示す図である。
【図４】ＭＶＣモデルの相互作用パターン情報の例を示す図である。
【図５】ＭＶＣモデルのクラス間相互作用情報の例を示す図である。
【図６】ＤＥＳｅＲＶモデルのクラス間関連情報の例を示す図である。
【図７】ＤＥＳｅＲＶモデルのクラス情報の例を示す図である。
【図８】ＤＥＳｅＲＶモデルの相互作用パターン情報の例を示す図である。
【図９】ＤＥＳｅＲＶモデルのクラス間相互作用情報の例を示す図である。
【図１０】相互作用パターンの別の例を示す図である。
【図１１】クラス間関連情報から抽出したクラスの関連図とそのデータ構造の例を示す図である。
【図１２】データセットクラスのクラス情報の例を示す図である。
【図１３】本発明の第２の実施形態であるソフトウェア開発支援装置の構成を示すブロック図である。
【図１４】ＭＶＣモデルによるクラス図とＤＥＳｅＲＶモデルによるクラス図との関係を示す図である。
【図１５】開発対象システムをＭＶＣモデルに従い分類したクラスの例を示す図である。
【図１６】図１５のＭＶＣモデルのクラスをＤＥＳｅＲＶモデルに従い再分類したクラスの例を示す図である。
【図１７】このソフトウェア開発支援装置でのＭＶＣモデルからＤＥＳｅＲＶモデルへのクラス変換処理の流れを示すフローチャートである。
【図１８】ＭＶＣモデルのクラスの設計情報の例を示す図である。
【図１９】コントローラのクラス分類処理の際の表示画面の例を示す図である。
【図２０】モデルのクラス分類処理の際の表示画面の例を示す図である。
【図２１】クラス関連付け手段によるクラス関連付け処理の流れを示すフローチャートである。
【図２２】クラス関連付け手段の関連付けルールを示す図である。
【図２３】ＭＶＣモデルからＤＥＳｅＲＶモデルへの変換例を示す図である。
【図２４】ＤＥＳｅＲＶモデルへの変換対象であるＭＶＣモデルの例を示す図である。
【図２５】図２４の変換対象ＭＶＣモデルに対して関連付けルールを用いて関連付けを行った結果を示す図である。
【図２６】図２５のクラス関連図に対して手動修正を行って不要な関連付けを取り除いた結果を示す図である。
【図２７】ＤＥＳｅＲＶモデルのクラス間相互作用情報からクラス間関連生成手段によって自動生成されたクラス間関連情報の例を示す図である。
【図２８】クラス間関連比較手段によって比較される２つのクラス間関連情報の例を示す図である。
【図２９】ビューＶの一覧表の例を示す図である。
【図３０】サービスＳｅの一覧表の例を示す図である。
【図３１】リクエストハンドラＲの一覧表の例を示す図である。
【図３２】エンティティＥの一覧表の一覧表の例を示す図である。
【図３３】データセットＤの一覧表の例を示す図である。
【符号の説明】
２１・・・・入力制御手段、２２・・・・出力制御手段、２３・・・・設計支援機構、２４・・・・設計情報データベース、２４Ａ・・・・ＭＶＣ設計情報データベース、２４Ｂ・・・・ＤＥＳｅＲＶ設計情報データベース、２５・・・・相互作用パターン情報データベース、２７・・・・制御手段、２８・・・・クラス間相互作用生成手段、３０・・・・表示テンプレートデータベース、３１・・・・表示テンプレート登録管理手段、３２・・・・クラス取込手段、３３・・・・クラス分類手段、３４・・・・クラス関連付け手段、３５・・・・クラス識別手段、３６・・・・クラス間関連生成手段、３７・・・・クラス間関連比較手段、４０・・・・図表化手段、５５・・・・クラス間関連情報、５６・・・・クラス情報、５７・・・・クラス間相互作用情報、５８・・・・相互作用パターン情報、１０１・・・・ソフトウェア開発支援装置、１０２・・・・ソフトウェア開発支援装置

Claims (5)

1. モデル分類されたクラスごとの設計情報であるクラス情報と前記クラス間の関連を表すクラス間関連情報とが記憶される設計情報記憶手段と、前記クラス間の相互作用のパターンを表す相互作用パターン情報が記憶される相互作用パターン記憶手段と、
   前記設計情報記憶手段の中から任意のクラス間関連情報とクラス情報を指定させるとともに前記相互作用パターン記憶手段の中から任意の相互作用パターン情報を指定させ、前記指定されたクラス間関連情報とクラス情報から前記指定された相互作用パターン情報のパターンを満たすクラスとメソッドを抽出してクラス間相互作用情報を生成するクラス間相互作用生成手段と
   を具備することを特徴とするソフトウェア開発支援装置。
2. 前記クラス間相互作用生成手段により生成されたクラス間相互作用情報に基づいてクラス間関連情報を生成するクラス間関連情報生成手段と、クラス間関連情報生成手段により生成されたクラス間関連情報と前記設計情報記憶手段に記憶されているクラス間関連情報とを比較して相違点を抽出し、その相違点に対して指定された処理を、前記設計情報記憶手段に記憶されているクラス間関連情報に対して実施するクラス間関連情報比較手段と
   をさらに具備することを特徴とする請求項１に記載のソフトウェア開発支援装置。
3. 前記設計情報記憶手段に記憶されたクラス情報およびクラス間関連情報から、前記ソフトウェア設計情報の分類モデルごとの図表を生成する図表化手段をさらに具備することを特徴とする請求項１または２に記載のソフトウェア開発支援装置。
4. ＭＶＣ（モデル・ビュー・コントローラ）のモデルで分類された前記クラスのうちのＭ（モデル）を一時的データであるＤ（データセット）と永続的データであるＥ（エンティティ）とに分類するとともに、前記ＭＶＣのモデルで分類された前記クラスのうちのＶ（ビュー）をＶ（ビュー）として、かつＣ（コントローラ）を業務処理の機能をするＳ（サービス）とイベントハンドラの機能をするＲ（リクエストハンドラ）とに分類し、この分類された各クラスのクラス情報を前記設計情報記憶手段に記憶させる分類手段と、
   前記分類手段により分類された各クラスを分類元の各クラスの関連付けに基づいて関連付け、この関連付けの結果をクラス間関連情報として前記設計情報記憶手段に記憶させるクラス関連付け手段と
   をさらに有することを特徴とする請求項１ないし３のいずれか１項に記載のソフトウェア開発支援装置。
5. コンピュータを、
   モデル分類されたクラスごとの設計情報であるクラス情報と前記クラス間の関連を表すクラス間関連情報とが記憶される設計情報記憶手段と、
   前記クラス間の相互作用のパターンを表す相互作用パターン情報が記憶される相互作用パターン記憶手段と、
   前記設計情報記憶手段の中から任意のクラス間関連情報とクラス情報を指定させるとともに前記相互作用パターン記憶手段の中から任意の相互作用パターン情報を指定させ、前記指定されたクラス間関連情報とクラス情報から前記指定された相互作用パターン情報のパターンを満たすクラスとメソッドを抽出してクラス間相互作用情報を生成するクラス間相互作用生成手段
   として機能させるためのコンピュータプログラム。

Images