(57)【要約】【課題】  開発プロセスの各段階における成果物について、修正された成果物により影響される他の成果物を通知することにより、ソフトウェアの開発を支援すること。【解決手段】  ソフトウェアの要求を記述した要求記述文書、該要求記述文書から作成される設計モデル、および、該設計モデルから作成されるプログラムコードである成果物の開発を支援する開発支援方法であって、コンピュータが、成果物および成果物間の対応情報を記憶部に格納する手順と、修正する成果物の入力を受け付ける修正受付手順と、修正受付手順により受け付けた成果物を起点として、記憶手順に格納された成果物間の対応情報を辿ることにより、修正する成果物が影響する他の成果物を追跡する修正追跡手順と、修正追跡手順により追跡された成果物を通知する修正通知手順と、を実行することを特徴とする。【選択図】      図１
2007122135.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアの要求を記述した要求記述文書、該要求記述文書から作成される設計モデル、および、該設計モデルから作成されるプログラムコードである成果物の開発を支援する開発支援装置であって、
成果物および成果物間の対応情報を格納する記憶部と、
修正する成果物の入力を受け付ける修正受付部と、
前記修正受付部により受け付けた成果物を起点として、前記記憶部に格納された成果物間の対応情報を辿ることにより、修正する成果物が影響する他の成果物を追跡する修正追跡部と、
前記修正追跡部により追跡された成果物を通知する修正通知部と、
を有することを特徴とする開発支援装置。
【請求項２】
要求記述文書の入力を受け付ける要求記述文書入力部と、
前記要求記述文書入力部により入力された要求記述文書を、要求記述文書に適用する変換ルールに基づいて、設計モデルに変換する設計モデル変換部と、
前記設計モデル変換部により変換された設計モデルを、設計モデルに適用する変換ルールに基づいて、プログラムコードに変換するプログラムコード変換部とを有し、
前記記憶部は、前記設計モデル変換部において前記要求記述文書から前記設計モデルに変換された際の対応情報、ならびに、前記プログラムコード変換部において前記設計モデルから前記プログラムコードに変換された際の対応情報を、成果物間の対応情報として格納すること
を特徴とする請求項１に記載の開発支援装置。
【請求項３】
要求記述文書の入力を受け付ける前記要求記述文書入力部と、
要求記述文書に対応する設計モデルの入力を受け付ける設計モデル入力部と、
設計モデルに対応するプログラムコードの入力を受け付けるプログラムコード入力部とを有し、
前記記憶部は、前記設計モデル入力部において前記要求記述文書および前記設計モデルが入力された際の対応情報、ならびに、前記プログラムコード入力部において前記設計モデルおよび前記プログラムコードが入力された際の対応情報を、成果物間の対応情報として格納すること
を特徴とする請求項１に記載の開発支援装置。
【請求項４】
前記修正受付部は、所定の要求記述文書の修正の入力を受け付け、
前記修正追跡部は、前記記憶部に格納された成果物間の対応情報を参照し、所定の要求記述文書に対応する設計モデル、および、設計モデルに対応するプログラムコードを追跡し、
前記修正通知部は、前記修正追跡部が追跡した設計モデル、および、プログラムコードを通知すること
を特徴とする請求項１ないし請求項３のいずれか１項に記載の開発支援装置。
【請求項５】
前記修正追跡部は、所定の要求記述文書から追跡したプログラムコードを起点として、起点のプログラムコードに対応する設計モデル、および、設計モデルに対応する要求記述文書を追跡し、
前記修正通知部は、前記修正追跡部が追跡した要求記述文書を通知すること
を特徴とする請求項４に記載の開発支援装置。
【請求項６】
前記修正受付部は、所定の設計モデルの修正の入力を受け付け、
前記修正追跡部は、前記記憶部に格納された成果物間の対応情報を参照し、所定の設計モデルに対応する要求記述文書、および、所定の設計モデルに対応するプログラムコードを追跡し、
前記修正通知部は、前記修正追跡部が追跡した要求記述文書、および、プログラムコードを通知すること
を特徴とする請求項１ないし請求項３のいずれか１項に記載の開発支援装置。
【請求項７】
前記修正追跡部は、所定の要求記述文書から追跡した要求記述文書、および、プログラムコードを起点として、起点の要求記述文書に対応する設計モデル、および、起点のプログラムコードに対応する設計モデルを追跡し、
前記修正通知部は、前記修正追跡部が追跡した設計モデルを通知すること
を特徴とする請求項６に記載の開発支援装置。
【請求項８】
前記修正受付部は、所定のプログラムコードの修正の入力を受け付け、
前記修正追跡部は、前記記憶部に格納された成果物間の対応情報を参照し、所定のプログラムコードに対応する設計モデル、および、設計モデルに対応する要求記述文書を追跡し、
前記修正通知部は、前記修正追跡部が追跡した設計モデル、および、要求記述文書を通知すること
を特徴とする請求項１ないし請求項３のいずれか１項に記載の開発支援装置。
【請求項９】
前記修正追跡部は、所定のプログラムコードから追跡した要求記述文書を起点として、起点の要求記述文書に対応する設計モデル、および、設計モデルに対応するプログラムコードを追跡し、
前記修正通知部は、前記修正追跡部が追跡したプログラムコードを通知すること
を特徴とする請求項８に記載の開発支援装置。
【請求項１０】
前記修正受付部は、所定の成果物の修正の入力を受け付け、
前記修正通知部は、以前通知した成果物と前記修正受付部が受け付けた所定の成果物とが一致したときには、その旨を修正の衝突として警告すること
を特徴とする請求項１ないし請求項９のいずれか１項に記載の開発支援装置。
【請求項１１】
開発支援装置は、前記修正受付部が受け付けた修正される成果物について修正前の内容および修正後の内容を対比する表示、および、前記修正通知部が通知する成果物の表示を併せて行う手段を有することを特徴とする請求項１ないし請求項１０のいずれか１項に記載の開発支援装置。
【請求項１２】
前記修正受付部は、修正する前の成果物の入力を受け付け、
前記修正追跡部は、前記修正受付部が受け付けた修正する前の成果物が修正されたとみなして、影響する他の成果物を追跡し、
前記修正通知部は、前記修正追跡部が追跡した成果物を、成果物の修正前に通知すること
を特徴とする請求項１ないし請求項１１のいずれか１項に記載の開発支援装置。
【請求項１３】
ソフトウェアの要求を記述した要求記述文書、該要求記述文書から作成される設計モデル、および、該設計モデルから作成されるプログラムコードである成果物の開発を支援する開発支援方法であって、
コンピュータが、
成果物および成果物間の対応情報を記憶部に格納する手順と、
修正する成果物の入力を受け付ける修正受付手順と、
前記修正受付手順により受け付けた成果物を起点として、記憶手順に格納された成果物間の対応情報を辿ることにより、修正する成果物が影響する他の成果物を追跡する修正追跡手順と、
前記修正追跡手順により追跡された成果物を通知する修正通知手順と、
を実行することを特徴とする開発支援方法。
【請求項１４】
コンピュータは、
要求記述文書の入力を受け付ける要求記述文書入力手順と、
前記要求記述文書入力手順により入力された要求記述文書を、要求記述文書に適用する変換ルールに基づいて、設計モデルに変換する設計モデル変換手順と、
前記設計モデル変換手順により変換された設計モデルを、設計モデルに適用する変換ルールに基づいて、プログラムコードに変換するプログラムコード変換手順とを実行し、
前記記憶部は、前記設計モデル変換手順において前記要求記述文書から前記設計モデルに変換された際の対応情報、ならびに、前記プログラムコード変換手順において前記設計モデルから前記プログラムコードに変換された際の対応情報を、成果物間の対応情報として格納すること
を特徴とする請求項１３に記載の開発支援方法。
【請求項１５】
コンピュータは、
要求記述文書の入力を受け付ける前記要求記述文書入力手順と、
要求記述文書に対応する設計モデルの入力を受け付ける設計モデル入力手順と、
設計モデルに対応するプログラムコードの入力を受け付けるプログラムコード入力手順とを実行し、
前記記憶部は、前記設計モデル入力手順において前記要求記述文書および前記設計モデルが入力された際の対応情報、ならびに、前記プログラムコード入力手順において前記設計モデルおよび前記プログラムコードが入力された際の対応情報を、成果物間の対応情報として格納すること
を特徴とする請求項１３に記載の開発支援方法。
【請求項１６】
請求項１３ないし請求項１５のいずれか１項に記載の開発支援方法をコンピュータに実行させるための開発支援プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアの開発支援装置、開発支援方法、および、開発支援プログラムに関する。
【背景技術】
【０００２】
ソフトウェアの開発プロセスは、要求記述文書の作成、その要求記述文書から設計モデルの作成、および、その設計モデルからプログラムコードの作成というように、作成された各成果物によって区切られる多段階のプロセスからなりたっている。なお、要求記述文書、設計モデル、プログラムコードの順に、人間の理解しやすい形式で記述されている。これらの成果物の作成について、部分的にコンピュータによって作成するしくみが、いくつか提案されている。
【０００３】
まず、ソフトウェアの要求記述文書から設計モデルを作成する方法としては、例えば特許文献１に記載されているオブジェクト指向設計支援装置がある。これは、要求記述文書であり、ＵＭＬ（Unified Model Language）の記法であるユースケースのシナリオ構文と、ソフトウェア設計モデルの構文の対応関係を予め定義することで、ユースケースシナリオからソフトウェア設計モデルへの変換を実現するものである。
【０００４】
次に、設計モデルからプログラムコードを作成する方法としては、非特許文献１に示されるようなモデル駆動の開発手法などがある。これらの方法では、まず開発プラットフォームに依存しない設計モデルを、開発プラットフォームに依存する設計モデルに変換し、さらに開発プラットフォームに依存する設計モデルを、プログラムコードに変換する作業を行う。変換には、設計モデルのメタ情報と、メタ情報間の変換ルールを用いる。
【特許文献１】特開平１０−２４０５１０号公報
【非特許文献１】David S. Frankel著、“Model Driven Architecture(TM)”、John Wiley & Sons Inc、ISBN: 0471319201
【発明の開示】
【発明が解決しようとする課題】
【０００５】
なお、開発プロセスの各段階における成果物の作成者は、専門家ごとに異なっていることが多い。例えば、顧客が要求記述文書を作成し、システムエンジニアが設計モデルを作成し、プログラマがプログラムコードを作成する。ここで、成果物のいずれかに修正がなされたときには、関連する他の成果物にもその修正が影響する。例えば、要求記述文書において１つの機能が追加されたときには、その要求記述文書から作成された設計モデル、および、その設計モデルから作成されたプログラムコードに対して、追加された機能に関する修正が必要となる。
【０００６】
なお、自動的に作成された成果物は、プログラムコードにおける関数名などのように、それだけで動作するものではない。例えば、プログラマは、自動的に作成されたプログラムコードの関数名をもとに、その関数名に対応する関数の内容をプログラムコードに補充することにより、プログラムコードを完成させる。よって、修正された最新の成果物に対して、成果物の自動作成処理を適用するだけでは、プログラムコードは完成しない。
【０００７】
そこで、システムエンジニアは、修正された要求記述文書に影響される設計モデルを修正し、プログラマは、修正された設計モデルに影響されるプログラムコードを修正する。ここで、システムエンジニアは修正された要求記述文書が影響する設計モデルを修正対象として知る必要があり、プログラマは修正された設計モデルが影響するプログラムコードを修正対象として知る必要がある。しかし、前記した従来の成果物の自動作成は、修正対象を提示することはできなかった。そのため、例えば、システムエンジニアおよびプログラマが、顧客による要求記述文書の修正を、成果物に反映することが困難であった。
【０００８】
そこで、本発明は、前記した問題を解決し、開発プロセスの各段階における成果物について、修正された成果物により影響される他の成果物を通知することにより、ソフトウェアの開発を支援することを主な目的とする。
【課題を解決するための手段】
【０００９】
本発明は、ソフトウェアの要求を記述した要求記述文書、該要求記述文書から作成される設計モデル、および、該設計モデルから作成されるプログラムコードである成果物の開発を支援する開発支援装置であって、成果物および成果物間の対応情報を格納する記憶部と、修正する成果物の入力を受け付ける修正受付部と、前記修正受付部により受け付けた成果物を起点として、前記記憶部に格納された成果物間の対応情報を辿ることにより、修正する成果物が影響する他の成果物を追跡する修正追跡部と、前記修正追跡部により追跡された成果物を通知する修正通知部と、を有することを特徴とする。その他の手段は、後記する。
【発明の効果】
【００１０】
本発明により、生成後の各コンテンツを修正した際の影響波及範囲の追跡ができる。これにより、要求提供者（顧客）と開発者の認識違いや仕様の漏れを軽減し、ソフトウェアの品質を向上する。
【発明を実施するための最良の形態】
【００１１】
以下、Ｗｅｂアプリケーション開発の例を用いて本発明の一実施形態を図面により詳細に説明する。
【００１２】
図１は、本実施形態におけるソフトウェア開発支援手法の全体作業フローを示す。まず、開発者は、ソフトウェアの仕様を定義する要求記述文書を作成する（ステップ１０１）。システムは、開発者が作成した要求記述文書に対し、第１変換ルール１２１を用いて第１設計モデルに変換する（ステップ１０２）。この際、システムは、変換の履歴を第１変換履歴１３１としてデータベースに記録する。
【００１３】
第１変換が完了した後、システムは要求−第２変換対応ルール１２２を用いて、第１設計モデルの要素に、第２変換ルール１２３への対応関係を付ける（ステップ１０４）。この際、システムは、関係付けの履歴を要求−第２変換対応履歴１３２としてデータベースに記録する。
【００１４】
次に、システムは、ステップ１０４で行った第１設計モデルと第２変換ルール１２３との対応関係を参照し、第２変換ルール１２３を用いて第１設計モデルを第２設計モデルに変換する（ステップ１０５）。この際、システムは、変換の履歴を第２変換履歴１３３としてデータベースに記録する。
【００１５】
システムは、ステップ１０４とステップ１０５をｎの値を１ずつインクリメントしてＮになるまで反復し（ステップ１０３）、開発者は、システムが提示する変換の過程を監視しながら、必要に応じて設計モデルを修正することができる。開発者は、最終的な設計モデルとしてプログラムコードを獲得する（ステップ１０６）。プログラムコード獲得後、開発者は、プログラムコードを実行環境にデプロイしてアプリケーションを起動し、仕様実現の評価などを行う（ステップ１０７）。
【００１６】
仕様実現の評価結果を受け、以下ではステップ１０６までに獲得したアプリケーションの修正作業を行う。
【００１７】
まず、開発者は要求記述文書、設計モデル、プログラムコードのいずれかに対して修正を行う（ステップ１０９）。システムは、開発者による修正を検知し、前記修正によって影響を受ける可能性のある、他の開発成果物を検出して開発者に通知する（ステップ１１０）。
【００１８】
開発者は、システムが通知した開発成果物を確認し、前記修正と整合をとるために必要な修正作業を行う（ステップ１１１）。開発者は、ステップ１０９からステップ１１１を反復し（ステップ１０８）、修正によって必要になる修正作業により、さらに必要になる修正作業を追跡しながら、アプリケーション全体の修正を完了させる。
【００１９】
図２は、図１に記載したソフトウェア開発支援手法の全体作業フローにおいて、外部システム２２１からインポートできる情報があるケースを示す。
【００２０】
まず、外部システム２２１に既存の要求記述文書がある場合、開発者は、外部システムから要求記述文書をインポートする（ステップ２０１）。また、外部システム２２１に既存の第１設計モデルがある場合、開発者は、システムが提供するユーザインタフェースを用いて、要求記述文書と既存の第１設計モデルの関係付けを行う（ステップ２０２）。この際、システムは、開発者が行った関係付けを第１（第ｎ）変換履歴２３１として記録する。以下、図１のステップ１０３〜ステップ１０６を実行する。
【００２１】
以上のように作業を行うことで、既存の要求記述文書や設計モデルがある場合でも、図１に示した全体作業フローと同様に開発を進めることができる。
【００２２】
図３は、本実施形態のソフトウェア構成を示すブロック図であり、３段階の変換を行う場合の例を示す。ここで、第３設計モデルはソフトウェアの実装であるプログラムコードに相当する。
【００２３】
まず、本実施形態におけるソフトウェアは、要求記述文書ＤＢ３１１を有する要求記述文書管理処理部３０１、第１設計モデルＤＢ３１２を有する第１設計モデル管理処理部３０２、第２設計モデルＤＢ３１３を有する第２設計モデル管理処理部３０３、プログラムコードＤＢ３１４を有するプログラムコード管理処理部３０４を持つ。また要求記述文書を第１設計モデルに変換する第１変換処理部３２１、第１設計モデルを第２設計モデルに変換する第２変換処理部３２２、第２設計モデルをプログラムコードに変換する第３変換処理部３２３を持つ。
【００２４】
各変換処理部は、変換方法を定義する第１変換ルール３３１、第２変換ルール３３３、第３変換ルール３３５、および、変換の履歴を記録する第１変換履歴３３２、第２変換履歴３３４、第３変換履歴３３６を持つ。また、要求記述文書管理処理部３０１は、要求記述文書の構文パターンに対する第２変換ルールの適用関係をルール化した要求−第２変換対応ルール３５１と、その適用履歴である要求−第２変換適用履歴３５２を持つ。
【００２５】
要求記述文書管理処理部３０１、第１設計モデル管理処理部３０２、第２設計モデル管理処理部３０３は、それぞれ開発者向けのユーザインタフェース３４１を持つ。第３変換処理部が変換し、プログラムコードＤＢ３１４に格納したプログラムコードは、デプロイ管理処理部３２４により、アプリケーション管理処理部３０５が有するアプリケーション格納ＤＢ３１５にデプロイされ、評価用のユーザインタフェース３４２で評価できるようになる。
【００２６】
図４は、本実施形態のハードウェア構成を示すブロック図である。計算機は、ＣＰＵ４０１、主記憶装置４０２、ネットワーク接続装置４０３を内部構成として持ち、外部機器としてディスプレイ４０４、外部記憶装置４０５、キーボードやマウスなどのデータ入力手段４０６を持つ。本実施形態をネットワーク環境上で運用する場合は、ネットワーク接続装置４０３を外部のネットワークに接続して利用する。
【００２７】
図５は、要求記述文書５０１を第１変換ルール３３１に基づいて第１設計モデル５１１に変換する例を示す。要求記述文書５０１は、要求ＩＤ５０２、要求の名称５０３、およびステップ番号により順序立てて構成する要求の説明５０４からなる。第１設計モデル５１１は、本実施形態では、ソフトウェアが持つデータとエンティティを表現するユーザ情報のモデル５１２である。ただし、本実施形態における第１設計モデル５１１は、生成するアプリケーションのプラットフォームに依存しないソフトウェアの仕様を表現するモデルであることを満たせば、表現の方法は任意である。
【００２８】
ステップ番号により順序立てて構成する要求の説明５０４は、図５に示すように制限のない自然語で記述したものから言語処理によって後記の図８、図１０に示すような構文パターンを抽出するアプローチと、開発者が要求記述文書を作成する段階から記述方法に制限を加えることで構文パターンを抽出し易くするアプローチのどちらを採っても構わない。
【００２９】
また、第１設計モデル５１１には、図１に記載した作業ステップ１０４において決定した第２変換ルールへの対応関係が、《》で括られたパターン名５１３として付加される。
【００３０】
本実施形態をソフトウェア開発支援ツールとして実現した場合、図５は、図１に記載した要求記述文書管理処理部３０１と第１設計モデル管理処理部３０２が開発者に提供するユーザインタフェース３４１のツール画面に相当する概念図である
【００３１】
図６は、第１設計モデル６０１を第２変換ルール３３３に基づいて第２設計モデル６１１に変換する例である。第１設計モデル６０１が生成するアプリケーションのプラットフォームに依存しない情報のみで構成されるのに対し、第２設計モデル６１１は、生成するアプリケーションのプラットフォームに依存する情報も持つ。図６では、パターン名６０３が付されたユーザ情報６０２を表す第１設計モデルが、第２変換ルール３３３を介して、Ｗｅｂアプリケーション６１２やデータベースシステム６１３といったプラットフォーム固有の情報により特徴付けられる。
【００３２】
また、第２設計モデル６１１には、図１に記載した作業ステップ１０４において決定した第３変換ルールへの対応関係が、《》で括られたパターン名６１４として付加される。ただし、図６の例では第３設計モデルはプログラムコードに相当するため、要求記述文書から変換ルールへの対応関係を導出することはせず、事前に定義された第２設計モデルのタイプがパターン名として付加される。図６では、パターン名６１４の一例として、《ｈｏｇｅ》と示して略す。
【００３３】
本実施形態をソフトウェア開発支援ツールとして実現した場合、図６は、図１に記載した第１設計モデル管理処理部３０２と第２設計モデル管理処理部３０３が開発者に提供するユーザインタフェース３４１のツール画面に相当する概念図である
【００３４】
図７は、第２設計モデル７０１を第３変換ルール３３５に基づいてプログラムコード７１１に変換する例である。第２設計モデル７０１は、プログラムの実装であるファイル７１２やパッケージ、リレーショナルデータベースのテーブル７１３に直接対応付けられる。第２設計モデル７０１は、パターン名７０４が付されたモデル７０２であり、対応関係は第３変換ルール３３５が保持する。
【００３５】
本実施形態をソフトウェア開発支援ツールとして実現した場合、図７は、図３に記載した第２設計モデル管理処理部３０３とプログラムコード管理処理部３０４が開発者に提供するユーザインタフェース３４１のツール画面に相当する概念図である
【００３６】
図８は、第１変換処理部３２１が利用し、本実施形態の特徴となる要求−第２変換対応ルール３５１を示す。要求−第２変換対応ルール３５１は、要求−第２変換対応ルール３５１を一意に示すルールＩＤ８１１、要求記述文書の各ステップに対する語彙タイプ８１２とその値８１３の組からなる要求記述の構文パターン８１４、要求−第２変換対応ルール３５１が前提とする（関係する）第１変換ルールを一意に示すＩＤ８１５、要求記述の構文パターン８１４と関係付ける第２変換ルールを一意に示す第２変換ルール名８１６により表現する。要求−第２変換対応ルール３５１により、本実施形態では、第１設計モデルに第２変換ルールを付加するための情報を要求記述文書から抽出し、第１変換から第３変換までをシームレスに関係付けることが可能となる。
【００３７】
図９は、要求記述文書管理処理部３０１が利用する要求−第２変換対応履歴３５２を示す。要求−第２変換対応履歴３５２は、要求−第２変換対応ルール３５１を実際に適用した際の適用履歴を記録するものであり、要求−第２変換対応ルール３５１を適用した要求記述を一意に示す要求ＩＤ９１１とステップＩＤ９１２、適用される第２変換ルールを一意に示す変換ルール名９１３と適用対象の第１設計モデルを一意に示す適用対象モデルＩＤ９１４からなる。
【００３８】
図１０は、第１変換処理部３２１が利用する第１変換ルール３３１を示す。第１変換ルール３３１は、ルールＩＤ１０１１、要求記述文書の各ステップに対する語彙タイプ１０１３とその値１０１４の組からなる要求記述の構文パターン１０１２、構文パターン１０１２に該当する要求記述のステップにより適用を決定する変換アクション１０１５、および第１変換ルール間の依存関係を示す依存ルール１０１６により表現する。
【００３９】
各ルールは、要求記述文書のステップが、要求記述の構文パターン１０１２を満たす場合、変換アクション１０１５が示す第１設計モデルを出力することを定義する。また、ルール間に依存関係が生じる場合があるため、その場合は依存ルール１０１６として定義し、第１変換処理部３２１が依存関係の解決を行う。
【００４０】
図１１は、第１変換処理部３２１が利用する第１変換履歴３３２を示す。第１変換履歴３３２は、第１変換ルール３３１を実際に適用した際の適用履歴を記録するものであり、第１変換ルール３３１の構文パターンに該当した要求記述を一意に示す要求ＩＤ１１１１とステップＩＤ１１１２、適用した第１変換ルールを一意に示す適用ルールＩＤ１１１３、変換により生成した第１設計モデルを一意に示すモデルＩＤ１１１４、クラスやメソッドなどモデルの粒度を示す種別１１１５、名称１１１７の組である変換後設計モデル情報１１１６からなる。
【００４１】
図１２は、第２変換処理部３２２が利用する第２変換ルール３３３を示す。第２変換ルール３３３は、第２変換ルール３３３を一意に示すルールＩＤ１２１１と変換ルール名１２１２、第２変換ルール３３３が適用された際に適用されるアクション種別１２１３、変換もしくは生成される変換後設計モデル１２１４、第２設計モデルの特性を示す変換後設計モデルタイプ１２１５の組からなる変換アクション１２１６により表現する。
【００４２】
各ルールは、第１設計モデルに変換ルール名１２１２から特定される適用パターンが適用された場合、第１設計モデルから変換される第２設計モデルのモデル構成を定義する。ここで、本来、変換後設計モデルタイプ１２１５は要求記述文書から導出するが、本例では、第３設計モデルはプログラムコードに相当するため、要求記述文書から変換ルールへの対応関係を導出することはせず、事前に定義された第２設計モデルのモデルタイプを利用するものとする。
【００４３】
図１３は、第２変換処理部３２２が利用する第２変換履歴３３４を示す。第２変換履歴３３４は、第２変換ルール３３３を実際に適用した際の適用履歴を記録するものであり、変換前の第１設計モデルを一意に示すクラスＩＤ１３１１、適用した第２変換ルールを一意に示す適用ルールＩＤ１３１２と、変換したモデルの種別１３１３、変換後の第２設計モデルを一意に示すＩＤ１３１４、名称１３１５、モデルタイプ１３１６の組である変換後設計モデル情報１３１７からなる。
【００４４】
図１４は、第３変換処理部３２３が利用する第３変換ルール３３５を示す。第３変換ルール３３５は、第３変換ルール３３５を一意に示すルールＩＤ１４１１、変換前の第２設計モデルの属性を示すモデルタイプ１４１２、モデルタイプと対応して適用するために予め用意されたテンプレートファイル１４１３、可変パラメータ１４１４により表現する。テンプレートファイル１４１３は、モデルタイプ１４１２ごとに用意するプログラムコードの雛形であり、カスタマイズ可能な箇所を可変パラメータ１４１４として予め持っている。第３変換ルール３３５では、ルール情報として、可変パラメータ１４１４の値を定義することもできる。
【００４５】
図１５は、第３変換処理部３２３が利用する第３変換履歴３３６を示す。第３変換履歴３３６は、第３変換ルール３３５を実際に適用した際の適用履歴を記録するものであり、第３変換ルール３３５を適用した第２設計モデルを一意に決定するモデルＩＤ１５１１とモデル名称１５１２、適用した第３変換ルール３３５を一意に示す適用ルールＩＤ１５１３、適用の結果として生成されたプログラムコードの生成ファイル１５１４からなる。
【００４６】
図１６に、第１変換履歴３３２、第２変換履歴３３４、第３変換履歴３３６、および要求−第２変換適用履歴３５２の対応関係を簡単な例にて示す。図中、第１変換履歴３３２と要求−第２変換適用履歴３５２には、要求ＩＤとステップＩＤによるリンク１６０１と、生成モデルＩＤによるリンク１６０２がある。
【００４７】
また、要求−第２変換適用履歴３５２と第２変換履歴３３４には、適用対象モデルＩＤによるリンク１６０３と、適用パターンによるリンク１６０４がある。さらに、第２変換履歴３３４と第３変換履歴３３６には、生成モデルＩＤによるリンク１６０６がある。本実施形態では、これらのリンクを辿ることで、要求記述文書、分析レベルの異なる複数の設計モデル、プログラムコードの追跡可能性を確立する。さらに、リンク１６０５およびリンク１６０７がある。リンク１６０５は、設計モデル間の対応情報を、リンク１６０７は、設計モデルおよびプログラムコードの対応情報を、それぞれ示す。
【００４８】
前記説明をもとに、開発者が利用する開発ユーザインタフェース３４１の画面例を説明する。
【００４９】
図１７は、要求記述文書管理処理部３０１が開発ユーザインタフェース３４１に提供する要求記述文書管理ＧＵＩであり、選択した要求項目に影響を与える第１設計モデル、第２設計モデル、プログラムコードの修正を参照しつつ要求シナリオを修正する場合に利用する画面１７０１である。
【００５０】
画面１７０１は、開発中のソフトウェアに対する要求シナリオ項目の一覧を表示する要求項目一覧フレーム１７１１と、メニューバー１７１２と、一覧から選択した要求項目のステップを表示する要求ステップ一覧フレーム１７１３と、要求シナリオを修正する際の参照情報を表示する参照情報表示フレーム１７１４からなる。
【００５１】
要求ステップ一覧フレーム１７１３は、ステップＩＤ１７２１、シナリオ文書１７２２と、第１設計モデル、第２設計モデル、プログラムコードごとに、要求記述文書に影響を与え得る修正が行われている件数をカウントアップして表示する列１７２３〜１７２５を持つテーブルを表示する。また、参照情報表示フレーム１７１４は、要求ステップ一覧フレーム１７１３のテーブル列１７２３〜１７２５から選択した第１設計モデル、第２設計モデル、プログラムコードいずれかの修正の詳細を表示する。
【００５２】
開発者は、参照情報表示フレーム１７１４に表示される第１設計モデル、第２設計モデル、プログラムコード１７３１の修正情報１７３２を確認しながら、適切な要求記述文書の修正該当要求ステップの直接更新やステップの追加・削除１７３３を行うことができる。
【００５３】
図１８は、図１７と同様に、要求記述文書管理処理部３０１が開発ユーザインタフェース３４１に提供する要求記述文書管理ＧＵＩであり、選択した要求項目への修正が影響を与える第１設計モデル、第２設計モデル、プログラムコードを追跡する場合に利用する画面１８０１である。
【００５４】
画面１８０１は、図１７と同様に、要求項目一覧フレーム１８１１と、要求ステップ一覧フレーム１８１３と、参照情報表示フレーム１８１４からなる。要求ステップ一覧フレーム１８１３は、ステップＩＤ１８２１、シナリオ文書１８２２と、第１設計モデル、第２設計モデル、プログラムコードごとに、要求項目への修正が影響を与えるモデル数およびモジュール数をカウントアップして表示する列１８２３〜１８２５を持つテーブルを表示する。
【００５５】
また、参照情報表示フレーム１８１４は、要求ステップ一覧フレーム１８１３のテーブル列１８２３〜１８２５から選択した第１設計モデル、第２設計モデル、プログラムコードいずれかの影響波及対象へのインデックス１８３１とトレース実行ボタン１８３２を表示する。開発者は、図１７で行った要求記述への修正によって影響を受ける第１設計モデル、第２設計モデル、プログラムコードを、図１８によって追跡することができる。
【００５６】
なお、図１７と図１８の切り替えは、両画面が共通して持つメニューバー１７１２および１８１２によって行う。
【００５７】
図１９は、プログラムコード管理処理部３０４が開発ユーザインタフェース３４１に提供するプログラムコード管理ＧＵＩであり、選択したプログラムモジュールに影響を与える要求記述、第１設計モデル、第２設計モデルの修正を参照しつつプログラムコードを修正する場合に利用する画面１９０１である。
【００５８】
画面１９０１は、開発中のソフトウェアにおけるモジュールの一覧を表示するモジュール一覧フレーム１９１１と、一覧から選択したモジュールの実装コードを表示もしくは編集するコード表示編集フレーム１９１２と、メニューバー１９１３と、プログラムコードを修正する際の参照情報を表示する参照情報表示フレーム１９１４からなる。
【００５９】
参照情報表示フレーム１９１４は、選択中のモジュールとメソッドの名称１９３１、選択中のモジュールに関係する修正情報へのインデックス１９３２、および前記インデックス１９３２から選択した修正情報の詳細修正前と修正後１９３３を表示する。
【００６０】
また、同様の情報は、コード表示編集フレーム１９１３に表示するコード１９２１もしくは影響範囲１９２２に、コメント文１９２３，１９２４として挿入することも可能である。開発者は、参照情報表示フレーム１９１４に表示される要求記述、第１設計モデル、第２設計モデルの修正情報１９３３を確認しながら、適切なコード修正を行うことができる。
【００６１】
図２０は、図１９と同様に、プログラムコード管理処理部３０４が開発ユーザインタフェース３４１に提供するプログラムコード管理ＧＵＩであり、選択したプログラムコードへの修正が影響を与える要求記述、第１設計モデル、第２設計モデルを追跡する場合に利用する画面２００１である。
【００６２】
画面２００１は、図１９と同様に、モジュール一覧フレーム２０１１、コード表示編集フレーム２０１２と、参照情報表示フレーム２０１４からなる。参照情報表示フレーム２０１４は、選択中のプログラムとメソッドの名称２０３１、選択中のモジュールを修正した際に影響が及ぶ要求記述、第１設計モデル、第２設計モデルへのインデックス２０３２とトレース実行ボタン２０３３を表示する。開発者は、図１９で行ったプログラムコードへの修正によって影響を受ける要求記述、第１設計モデル、第２設計モデルを、図２０によって追跡することができる。
【００６３】
なお、図１９と図２０の切り替えは、両画面が共通して持つメニューバー１９１３および２０１３によって行う。
【００６４】
図２１は、図３の構成に、成果物への修正に関する手段を追加した構成図である。
【００６５】
要求記述文書入力部１０は、ソフトウェアの要求を自然語で記述した要求記述文書の入力を受け付ける。要求記述文書格納部１２は、要求記述文書を格納する。
【００６６】
設計モデル入力部２０は、インポートとして設計モデルの入力を受け付ける。設計モデルは、分析レベルの異なる複数段階のモデルによって構成されてもよい。設計モデル変換部２２は、要求記述文書から設計モデルに変換する。変換は、要求記述文書に適用する変換ルールに基づいて行われる。設計モデル格納部２４は、設計モデルを格納する。設計モデル格納部２４は、変換前の要求記述文書および変換後の設計モデルの対応関係も併せて格納する。この対応関係を参照することにより、整合性と追跡可能性を維持する。
【００６７】
プログラムコード入力部３０は、インポートとしてソフトウェアの実装であるプログラムコードの入力を受け付ける。プログラムコード変換部３２は、設計モデルからプログラムコードに変換する。変換は、設計モデルに適用する変換ルールに基づいて行われる。プログラムコード格納部３４は、プログラムコードを格納する。プログラムコード格納部３４は、変換前の設計モデルおよび変換後のプログラムコードの対応関係も併せて格納する。
【００６８】
修正受付部４０は、ユーザからの既存の成果物への修正を受け付ける。
【００６９】
修正追跡部４２は、受け付けた修正が影響する成果物を追跡する。追跡は、設計モデル格納部２４およびプログラムコード格納部３４に格納されている成果物間の対応関係を、リンクとして辿ることにより実現される。追跡する契機は、修正前（事前実行）、または、修正後（事後実行）である。修正追跡部４２は、追跡を繰り返し実行することで、開発者が過去に行った修正によって必要となる修正を行うことによって新たに修正が必要となる成果物を、発見する。
【００７０】
修正通知部４４は、修正が影響する成果物をユーザに通知する。修正が影響する成果物を開発者が別途に修正しようとした際、先に行われた修正により、情報の不整合が発生する可能性があることを開発者に通知する。
【００７１】
設計モデル変換部２２およびプログラムコード変換部３２は、各成果物について、変換前から変換後のものを作成する。これにより、要求記述文書から設計モデルおよびプログラムコードの生成作業を自動化することでソフトウェアの開発生産性を向上する。
【００７２】
設計モデル変換部２２は、要求記述文書に記述される非機能要件を参照してもよい。非機能要件とは、機能を追加するのではなく、既定の機能に対する改良的な要望である。例えば、印刷画面において新たな情報を印刷する機能を追加することは機能要件となり、印刷画面において印刷速度を向上することは、性能向上にあたり、非機能要件である。
【００７３】
非機能要件を成果物に反映する手段として、例えば、成果物が設計モデルであるときに、設計モデルのデザインパターンを選択することが挙げられる。デザインパターンは、プログラムコードの基本的な枠組みである。同じ機能を実装するときでも、デザインパターンが異なると、実装されたプログラムコードは、外観上大きく異なることもある。
【００７４】
デザインパターンには、プログラムコードの量が少なく保守性に優れるものや、プログラムコードの量は多くなるものの処理速度に優れるものなど、様々なものがある。そこで、あらかじめ非機能要件およびデザインパターンの対応情報を定義しておき、その対応情報に基づいて、要求記述文書に記述される非機能要件から、設計モデルのデザインパターンを特定してもよい。対応情報は、例えば、開発コストを抑えるという非機能要件およびプログラムコードの量が少ないデザインパターンの対応などが挙げられる。これにより、要求記述文書に忠実な成果物を作成することを支援できる。
【００７５】
図２２は、設計モデルに付されるタグ情報の説明図である。まず、設計モデル変換部２２は、要求記述文書に記述された要求のうち、プログラムコードに反映する要求をタグ情報として設計モデルに付す。次に、プログラムコード変換部３２は、タグ情報を参照して要求からプログラムコードへ変換する。これにより、要求記述文書に記述された要求を忠実にプログラムコードに反映することができる。なお、比較例として、要求記述文書から設計モデルに変換する手段、および、設計モデルからプログラムコードに変換する手段を、単に組み合わせると、要求記述文書に記述されたプログラムコードに反映する要求は、設計モデルに変換する時点で抜け落ちてしまう。
【００７６】
図２３は、設計モデルの段階数を示す説明図である。図２３（ａ）は１段の設計モデル、図２３（ｂ）は３段の設計モデルを示す。１段の設計モデルは、変換回数が少なくて済むため、処理速度に優れる。３段の設計モデルは、同じ種類の複数の設計モデルを１つの設計モデルにまとめやすくなり、メモリ使用量を抑制できる。
【００７７】
図２４から図２６は、修正受付部４０によって受け付けた修正を、修正追跡部４２が追跡する様子を示す説明図である。図２４は要求記述文書への修正を示し、図２５は設計モデルへの修正を示し、図２６はプログラムコードへの修正を示す。各図においてノードは、成果物（要求記述文書、設計モデル、プログラムコード）を示す。ノード間のリンクは、変換に関する対応情報を示す。
【００７８】
図２４（ａ）を参照して、要求記述文書への修正を説明する。修正受付部４０が要求記述文書Ｒ１への修正を受け付けると、修正追跡部４２は、要求記述文書Ｒ１からリンクのある設計モデルＣ１，Ｃ２を追跡する。修正追跡部４２は、追跡した設計モデルＣ１，Ｃ２からリンクのあるプログラムコードＰ１，Ｐ２を追跡する。
【００７９】
図２４（ｂ）は、図２４（ａ）によって追跡されたノードを、再帰的に追跡する様子を示す説明図である。修正追跡部４２は、追跡されたノードについて、追跡に使用したリンク以外のリンクを有するプログラムコードＰ２について、図２４（ａ）とは逆方向にリンクを追跡する。これにより、修正追跡部４２は、影響範囲として、設計モデルＣ３および要求記述文書Ｒ３を取得する。
【００８０】
図２５（ａ）を参照して、設計モデルへの修正を説明する。修正受付部４０が設計モデルＣ１への修正を受け付けると、修正追跡部４２は、設計モデルＣ１からリンクのある要求記述文書Ｒ１、および、プログラムコードＰ１，Ｐ２を追跡する。
【００８１】
図２５（ｂ）は、図２５（ａ）によって追跡されたノードを、再帰的に追跡する様子を示す説明図である。修正追跡部４２は、追跡されたノードについて、追跡に使用したリンク以外のリンクを有する要求記述文書Ｒ１、および、プログラムコードＰ２について、図２５（ａ）とは逆方向にリンクを追跡する。これにより、修正追跡部４２は、影響範囲として、設計モデルＣ２，Ｃ３を取得する。
【００８２】
図２６（ａ）を参照して、プログラムコードへの修正を説明する。修正受付部４０がプログラムコードＰ１への修正を受け付けると、修正追跡部４２は、プログラムコードＰ１からリンクのある設計モデルＣ１を追跡する。修正追跡部４２は、追跡した設計モデルＣ１からリンクのある要求記述文書Ｒ１を追跡する。
【００８３】
図２６（ｂ）は、図２４（ａ）によって追跡されたノードを、再帰的に追跡する様子を示す説明図である。修正追跡部４２は、追跡されたノードについて、追跡に使用したリンク以外のリンクを有する要求記述文書Ｒ１について、図２４（ａ）とは逆方向にリンクを追跡する。これにより、修正追跡部４２は、影響範囲として、設計モデルＣ２およびプログラムコードＰ２を取得する。
【００８４】
図２４から図２６に示したように、修正されたノードからリンクを次々に辿ることにより、修正されたノードが影響するノードを取得する。これにより、ユーザは、修正された成果物が影響する他の成果物を知ることができるので、成果物間の修正内容の不整合を、修正の事前に確認することができる。
【図面の簡単な説明】
【００８５】
【図１】本発明の一実施形態に関する全体の作業を示すフローチャートである。
【図２】本発明の一実施形態に関する既存情報がある場合の全体の作業を示すフローチャートである。
【図３】本発明の一実施形態に関するソフトウェア構成を示す構成図である。
【図４】本発明の一実施形態に関するハードウェア構成を示す構成図である。
【図５】本発明の一実施形態に関する第１変換の流れを示す説明図である。
【図６】本発明の一実施形態に関する第２変換の流れを示す説明図である。
【図７】本発明の一実施形態に関する第３変換の流れを示す説明図である。
【図８】本発明の一実施形態に関する要求−第２変換対応ルールを示す構成図である。
【図９】本発明の一実施形態に関する要求−第２変換適用履歴を示す構成図である。
【図１０】本発明の一実施形態に関する第１変換ルールを示す構成図である。
【図１１】本発明の一実施形態に関する第１変換履歴を示す構成図である。
【図１２】本発明の一実施形態に関する第２変換ルールを示す構成図である。
【図１３】本発明の一実施形態に関する第２変換履歴を示す構成図である。
【図１４】本発明の一実施形態に関する第３変換ルールを示す構成図である。
【図１５】本発明の一実施形態に関する第３変換履歴を示す構成図である。
【図１６】本発明の一実施形態に関する変換トレースの例を示す説明図である。
【図１７】本発明の一実施形態に関する要求記述文書管理ＧＵＩ（要求記述文書の修正）を示す画面図である。
【図１８】本発明の一実施形態に関する要求記述文書管理ＧＵＩ（修正後の追跡）を示す画面図である。
【図１９】本発明の一実施形態に関するプログラムコード管理ＧＵＩ（プログラムコードの修正）を示す画面図である。
【図２０】本発明の一実施形態に関するプログラムコード管理ＧＵＩ（修正後の追跡）を示す画面図である。
【図２１】本発明の一実施形態に関する成果物への修正に関する手段を追加したソフトウェア構成を示す構成図である。
【図２２】本発明の一実施形態に関する設計モデルに付されるタグ情報を示す説明図である。
【図２３】本発明の一実施形態に関する設計モデルの段階数を示す説明図である。
【図２４】本発明の一実施形態に関する要求記述文書への修正を示す説明図である。
【図２５】本発明の一実施形態に関する設計モデルへの修正を示す説明図である。
【図２６】本発明の一実施形態に関するプログラムコードへの修正を示す説明図である。
【符号の説明】
【００８６】
１０    要求記述文書入力部
１２    要求記述文書格納部
２０    設計モデル入力部
２２    設計モデル変換部
２４    設計モデル格納部
３０    プログラムコード入力部
３２    プログラムコード変換部
３４    プログラムコード格納部
４０    修正受付部
４２    修正追跡部
４４    修正通知部
【図１】
2007122135.tif 000003
【図２】
2007122135.tif 000004
【図３】
2007122135.tif 000005
【図４】
2007122135.tif 000006
【図５】
2007122135.tif 000007
【図６】
2007122135.tif 000008
【図７】
2007122135.tif 000009
【図８】
2007122135.tif 000010
【図９】
2007122135.tif 000011
【図１０】
2007122135.tif 000012
【図１１】
2007122135.tif 000013
【図１２】
2007122135.tif 000014
【図１３】
2007122135.tif 000015
【図１４】
2007122135.tif 000016
【図１５】
2007122135.tif 000017
【図１６】
2007122135.tif 000018
【図１７】
2007122135.tif 000019
【図１８】
2007122135.tif 000020
【図１９】
2007122135.tif 000021
【図２０】
2007122135.tif 000022
【図２１】
2007122135.tif 000023
【図２２】
2007122135.tif 000024
【図２３】
2007122135.tif 000025
【図２４】
2007122135.tif 000026
【図２５】
2007122135.tif 000027
【図２６】
2007122135.tif 000028