JP3554056B2 - Software specification reuse support device - Google Patents

Software specification reuse support device Download PDF

Info

Publication number
JP3554056B2
JP3554056B2 JP00205695A JP205695A JP3554056B2 JP 3554056 B2 JP3554056 B2 JP 3554056B2 JP 00205695 A JP00205695 A JP 00205695A JP 205695 A JP205695 A JP 205695A JP 3554056 B2 JP3554056 B2 JP 3554056B2
Authority
JP
Japan
Prior art keywords
data
specification part
software
database
creation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
JP00205695A
Other languages
Japanese (ja)
Other versions
JPH08147152A (en
Inventor
万里 名取
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP00205695A priority Critical patent/JP3554056B2/en
Publication of JPH08147152A publication Critical patent/JPH08147152A/en
Application granted granted Critical
Publication of JP3554056B2 publication Critical patent/JP3554056B2/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Description

【０００１】
【産業上の利用分野】
本発明は、既存の仕様を再利用しつつ新たなソフトウェアの仕様を作成する過程において再利用する仕様の選択を支援するソフトウェア仕様再利用支援装置に関する。
【０００２】
【従来の技術】
ソフトウェア仕様再利用支援装置は、ユーザが既存のソフトウェアの仕様を再利用して、生産性、信頼性の高いソフトウェアを新たに開発する際に、利用される装置（以下、ユーザとは、既存の仕様データベースを用いて、新たに仕様を作成する者をさす）である。従来のソフトウェア仕様再利用支援装置における仕様再利用方式では、まず、類似する仕様を備えたソフトウェアの仕様を検索することに主眼がおかれる。また、仕様再利用の一般的な方式では、分野ごとの仕様のひな型を用意して、これを元に情報を追加して、新しい仕様を作成している。
【０００３】
仕様の検索方式は、開発するソフトウェアの要求を元に、大まかな機能の構成や、要求文に出現する類似した用語の数の観点から、類似する既存の仕様の検索を行なっていることが多い。しかしながら、同一分野のソフトウェアの開発において、例えば事務処理の顧客システムなどは、客先が異なっていても基本的な機能や使用される用語はほぼ共通しているので、仕様の再利用を行う際、使われる用語数による類似性判定の仕様の検索は有効ではない。
【０００４】
また、ひな型に情報を追加して仕様を作成する場合、全ての業務に関して、ひな型を十分に、矛盾なく用意することは困難である。また、ひな型を用いて新しい仕様を作成する場合、情報の追加や修正を行なうが、このように追加・修正される情報は、別の仕様作成においては重要な情報になる場合が多く、従来は、これらの情報を形式化する手段がなく、次の再利用に備えて蓄積しておくことが困難である。
【０００５】
また、ひな型の仕様も含めて、既存の仕様は、複数のファイルに分割されたり部品化されていることが多い。そして、それら部品となる仕様間の関係には、用語のつながりがある関係、上位下位の関係、類似性が高い関係などさまざまな関係が考えられる。しかしながら、従来の仕様再利用の方式では、仕様間（部品間）の関係に関する知識をノウハウとして蓄積する機構がなく、仕様を修正したり情報を付加したりする場合、一つの部品の変更によって、それが他の部品にどのように反映されるかが不明確であり、却って仕様の信頼性が低下する不具合があった。さらに、従来の仕様再利用の方式では、仕様の再利用に重要である作成手順などのノウハウも蓄積する機構がなかった。すなわち、どの既存の仕様部品を使うかに主眼がおかれ、どう使うかといった観点が欠如していた。従って、部品の使い方や作成手順によっては生産性が低下する場合があった。
【０００６】
また、繰り返し行われる再利用により、仕様間の関係に変化が生じる場合も多く、ユーザが仕様間の関係を適格に把握し、最適な再利用の仕方を選択することは、極めて困難であった。
【０００７】
【発明が解決しようとする課題】
以上説明したように、従来のソフトウェア仕様再利用支援装置では、蓄積された既存のソフトウェア仕様や部品仕様のうちから、開発すべきソフトウェアの要求を元に、大まかな機能の構成や出現する類似した用語の数の観点から、類似する仕様の検索を行なうことができるだけであり、既存の仕様間の関連あるいはその仕様の利用の仕方等については、全くサポートがなかったので、ソフトウェアを新たに開発する際、既存の仕様の有効活用の点、開発における生産性の点、開発した仕様の信頼性の点で問題があった。
【０００８】
本発明は、上記事情を考慮してなされたものであり、ユーザの仕様作成状況を認識して、過去の仕様の作成履歴や仕様部品間の関係の情報から、既存の仕様データベース内をどのように辿って再利用する仕様を決定すればよいのかという探索経路を生成して、それをユーザに提示することにより、再利用や変更する仕様および仕様部品の決定を支援し、ソフトウェアの仕様作成作業における生産性の向上と出来上がった仕様の信頼性の向上を図るソフトウェア仕様再利用支援装置を提供することを目的とする。
【０００９】
また、本発明は、上記事情を考慮してなされたものであり、ユーザの仕様作成状況を認識して、またユーザの再利用目的を考慮して、過去の仕様の作成履歴や仕様部品間の関係の情報から適切な仕様再利用のためのガイドを生成し、それをユーザに提示することにより、再利用や変更する仕様および仕様部品の決定を支援し、さらに仕様を再利用する際の作成手順や仕様間の関連知識などのノウハウをデータベースに蓄積することを支援し、ソフトウェアの仕様作成作業における生産性の向上と出来上がった仕様の信頼性の向上を図るソフトウェア仕様再利用支援装置を提供することを目的とする。
【００１０】
【課題を解決するための手段】
本発明に係るソフトウェア再利用支援装置は、過去に作成したソフトウェア仕様、該ソフトウェア仕様の作成履歴、および該ソフトウェア仕様間の関連情報を蓄積したデータベースと、前記データベースに蓄積されたソフトウェア仕様を利用して新たなソフトウェア仕様を作成するための仕様作成手段と、この仕様作成手段による現在の仕様作成状況を認識する認識手段と、前記仕様作成手段により行なわれた仕様作成の手順を作成履歴として前記データベースに蓄積する履歴作成手段と、前記データベース内を探索する際の経路を関連情報として前記データベースに蓄積する経路作成手段と、前記仕様作成状況、前記作成履歴、前記関連情報から、前記データベースに蓄積されたソフトウェア仕様を探索する経路を絞り込む探索経路絞り込み手段と、この探索経路絞り込み手段により絞り込まれた経路に基づいて前記データベースに蓄積されたソフトウェア仕様を探索する仕様データベース探索手段とを有することを特徴とする。好ましくは、前記仕様データベース探索手段の探索結果に基づいて、再利用できるソフトウェア仕様の候補を提示する提示手段をさらに有することを特徴とする。また、好ましくは、前記提示手段は、提示した再利用できるソフトウェア仕様の候補について、編集手順を提示することを特徴とする。
【００１１】
また、本発明に係るソフトウェア再利用支援装置は、外部から入力した、過去に作成したソフトウェア仕様、過去に作成したソフトウェア仕様の作成履歴、および過去に作成したソフトウェア仕様間の関連情報を蓄積するデータベースと、前記データベースに蓄積されたソフトウェア仕様を利用して新たなソフトウェア仕様を作成するための編集手段と、この編集手段による作成状況を認識する認識手段と、前記作成状況、ならびに前記データベースに蓄積された前記作成履歴および前記関連情報に基づいて、前記データベースに蓄積されたソフトウェア仕様のうち再利用できるソフトウェア仕様の候補を提示する提示手段とを有することを特徴とする。好ましくは、前記提示手段は、提示した再利用できるソフトウェア仕様の候補について、編集手順を提示することを特徴とする。
【００１２】
また、好ましくは、前記作成履歴は、ソフトウェア仕様名と該ソフトウェア仕様の作成順序とを記述した情報を含み、必要に応じ他のソフトウェア仕様間の利用関係をも記述した情報を含むものであることを特徴とする。
【００１３】
また、好ましくは、前記関連情報は、２以上のソフトウェア仕様についてそれらのソフトウェア仕様名とその関連の仕方をともに記述した情報を含むものであることを特徴とする。
【００１４】
また、本発明に係るソフトウェア再利用支援装置は、過去に作成したソフトウェア仕様、該ソフトウェア仕様の作成履歴、および該ソフトウェア仕様間の関連の種類を示すリンク情報を蓄積したデータベースと、前記データベースに蓄積されたソフトウェア仕様を利用して新たなソフトウェア仕様を作成するための仕様作成手段と、この仕様作成手段による現在の仕様作成状況を認識する認識手段と、前記仕様作成手段により行なわれた仕様作成の手順を作成履歴として前記データベースに蓄積する履歴作成手段と、前記仕様作成手段により作成されたソフトウェア仕様と、前記データベースに蓄積されたソフトウェア仕様との間の関連の種類をリンク情報として前記データベースに蓄積するリンク情報作成手段と、前記仕様作成状況、前記作成履歴、前記リンク情報、および指定された関連の種類とその優先度に基づき、前記データベースに蓄積されたソフトウェア仕様を再利用するためのガイド情報を生成する再利用ガイド生成手段とを有することを特徴とする。
【００１５】
好ましくは、前記関連の種類は、外部から任意に１種類または複数種類指定できるものであることを特徴とする。
【００１６】
また、好ましくは、前記関連の種類は、一方のソフトウェア仕様を利用して他方のソフトウェア仕様を作成できる関係にあることを示す作成履歴、一方のソフトウェア仕様の修正が他方のソフトウェア仕様に影響を与える関係にあることを示す修正影響、ソフトウェア仕様間に上位・下位の関係があることを示す親子、ソフトウェア仕様間に上位・下位以外の関係があることを示す関連、双方のソフトウェア仕様に共通の用語を使用されている関係にあることを示す用語のうち少なくとも１つを含むものであることを特徴とする。
【００１７】
また、好ましくは、前記再利用ガイド生成手段は、指定された関連の種類に作成履歴が含まれる場合、再利用できるソフトウェア仕様の候補を前記ガイド情報として生成することを特徴とする。
【００１８】
また、好ましくは、前記再利用ガイド生成手段は、指定された関連の種類に作成履歴が含まれる場合、再利用できるソフトウェア仕様の候補および該候補を用いた編集手順を前記ガイド情報として生成することを特徴とする。
【００１９】
また、好ましくは、前記再利用ガイド生成手段は、複数の関連の種類が指定された場合、各関連の種類に対応して生成したガイドを、指定された優先度の順に出力することを特徴とする。
【００２０】
また、好ましくは、前記作成履歴は、ソフトウェア仕様名と該ソフトウェア仕様の作成順序とを記述した情報を含み、必要に応じ他のソフトウェア仕様間の利用関係をも記述した情報を含むものであることを特徴とする。
【００２１】
また、好ましくは、前記リンク情報は、２以上のソフトウェア仕様についてそれらのソフトウェア仕様名とその関連の仕方をともに記述した情報を含むものであることを特徴とする。
【００２２】
また、好ましくは、前記データベースに蓄積された作成履歴およびリンク情報を編集するための手段をさらに有することを特徴とする。
【００２３】
【作用】
本発明のソフトウェア仕様再利用支援装置では、データベース内にソフトウェア仕様とともに、該ソフトウェア仕様の作成履歴、該ソフトウェア仕様間の関連情報を蓄積してあるので、仕様データベース内の関係が明らかになる。そして、新たな仕様の作成状況、上記作成履歴、上記関連情報に基づいて仕様データベースを探索するので、次に再利用できる仕様の候補を挙げること、次の作成手順を提示するなど、ユーザに有効なガイドを与えることができる。
【００２４】
このため本発明によれば、仕様作成の生産性が向上する、仕様間の関係がガイドによって示されるため、修正内容の影響範囲が明らかになり、仕様作成の信頼性が向上する、といった効果を奏する。
【００２５】
本実施例のソフトウェア仕様再利用支援装置では、過去の仕様の作成履歴や仕様部品間の関係の情報などのノウハウを蓄積してあるので、仕様データベース内の関係が明らかになるとともに、修正内容の影響範囲が明らかになる。そして、ソフトウェア開発における仕様作成工程において、ユーザの仕様作成状況を認識し、またユーザの再利用目的を考慮して、過去の仕様の作成履歴や仕様部品間の関係の情報などのノウハウから、再利用できる仕様の候補や作成手順、あるいは仕様間の関連性に関する情報などを適切な仕様再利用のためのガイドを生成し、それをユーザに提示することにより、再利用や変更する仕様および仕様部品の決定などを支援することができる。また、仕様を再利用する際の作成手順や仕様間の関連知識などのノウハウをデータベースに蓄積したり、自由に追加・修正したりする作業を支援することができる。
【００２６】
このため本発明によれば、仕様の有効活用を行なうことができ、ソフトウェアの仕様作成作業における生産性の向上と出来上がった仕様の信頼性の向上を図ることができる。
【００２７】
【実施例】
以下、図面を参照しながら本発明の実施例を説明する。
【００２８】
本実施例で、仕様とは、業務機能階層構造一覧表、画面遷移図、画面レイアウト、帳票レイアウト、ファイル関連図、画面とファイルの関連、性能用件、障害対策などを含むものとする。各種類の仕様は、複数の断片によって構成される。また、本発明は、上記の仕様の他に、ファイル名を持ったデータの集合であれば、テキスト、画像、図形など何にでも適用可能である。
【００２９】
（第１の実施例）
図１は、本発明の第１の実施例に係るソフトウェア仕様再利用支援装置の構成図である。同図に示すように、本実施例のソフトウェア仕様再利用支援装置は、入出力部１、処理部２、データベース３から構成されている。入出力部１からの指示・データ入力等により、処理部２が、データベース３をアクセスしながら、処理を進めていく。図１中の矢印は、データや制御信号の流れを示す。
【００３０】
入出力部１は、入力装置であるキーボード、出力装置であるＣＲＴ等からなり、ソフトウェアの仕様の入力や表示を行なうことができる。入力装置としては、いわゆるマウスを利用あるいは併用することもできる。出力装置としては、プリンタを利用あるいは併用することもできる。
【００３１】
処理部２は、ユーザインタフェース部１０、仕様エディタ部１１、仕様データベース探索支援部１２、ユーザ認識部１３、探索経路絞り込み部１４、履歴作成部１５、経路作成支援部１６からなる。処理部２は、例えばＣＰＵとメモリなどを用いて構成され、ソフトウェア処理によって機能が提供される。
【００３２】
データベース３は、仕様データベース３ａ、作成履歴データベース３ｂ、探索経路データベース３ｃからなる。詳細は後述するが、仕様データベース３ａは、過去に作成した仕様を蓄積しておくデータベースであり、作成履歴データベース３ｂは、過去に作成した仕様の手順である作成履歴を蓄積しておくデータベースであり、探索経路データベース３ｃは、仕様データベース３ａを探索するための探索経路を蓄積しておくデータベースである。
【００３３】
ユーザインタフェース部１０は、データベース３へアクセスし、内容を入出力部１へ表示する。また、仕様エディタ部１１、仕様データベース探索支援部１２、履歴作成部１５、経路作成支援部１６夫々についての起動、終了、実行内容の入出力部１への表示を行なう。
【００３４】
仕様エディタ部１１は、ソフトウェアを構成する仕様の記述を支援するためのものである。仕様データベース３ａに記述された過去の仕様の断片の読み込み・編集・保存を行なうことができる。
【００３５】
ここで、ソフトウェアを構成する仕様の記述とは、例えば図２、図３、図４に示すようなものであり、図２は、時間の流れにそって業務を分割した結果の記述の一例、図３は、分割された業務の処理の流れの画面遷移図による記述の一例、図４は、画面とファイルの処理の対応付けの記述の一例を夫々示している。
【００３６】
図２は、事務処理に係る時間的な順序関係を有する複数の業務を各時間帯毎の業務に分けて記述し、かつ各時間帯の業務を階層的に記述した業務鳥瞰図の一例であり、「ギフトシステム」を例に取り記述したものである。例えば、「シーズン業務」の時間ブロック中の「日次処理」の時間ブロックがさらに異なる時間帯の「日次開始処理」、「日中業務」および「日次終了処理」の三つのブロックに分割され、さらにこれらのうちの「日中業務」の時間ブロックが「受注入力」、「受注修正」、「マスタメンテナンス」、および「オンライン伝送」という四つのブロックに分割されることによって、これらの業務を適宜選択して定義できることを示している。
【００３７】
図３は、業務の流れを定義する画面遷移図の一例であり、図２と同様に「ギフトシステム」を例に取り記述したものである。この画面遷移図は、丸印で示す画面状態と矢印で示す遷移を有する。画面状態を表す丸印の近傍には画面状態の名称を記述し、遷移を表す矢印の近傍には画面遷移を引き起こす「事象」の名称と、その事象によって引き起こされる「動作」の名称を記述する。このような画面遷移図を用いて、ユーザは「受注入力」を行う際のアプリケーションの画面遷移を次のように定義することができる。すなわち、まず初期画面である「事前リスト照会」という画面状態から、「申込番号」の入力という事象が発生すると、「申込番号」を入力属性、「顧客情報」を出力属性とする「検索」動作を行い、また「電話番号」の入力という事象が発生すると、「電話番号」を入力属性、「顧客情報」を出力属性とする「検索」動作を行った後、「依頼主入力」という画面状態に遷移すると定義できる。その他の画面状態においても、同様にして画面遷移が行われ、最終的に「個別伝票入力」という画面状態に遷移することを定義できる。
【００３８】
図４は、画面メソッドとファイルメソッドとの関連を定義するメソッド結合図の一例であり、図２と同様に「ギフトシステム」を例に取り記述したものである。この関連は一つの画面メソッドとファイルメソッドのリストを持ち、関連図の左欄に一つの画面メソッド、右欄にファイルメソッドのリストを記述する。ユーザは、「事前リスト紹介」画面の「電話番号」を入力属性、「顧客情報」（住所、氏名、電話番号など）を出力属性とする「検索」メソッドは、「顧客マスタ」ファイルの「電話番号」を入力属性、「住所」、「氏名」を出力属性とする「検索」メソッドと、「事前マスタ」ファイルの「電話番号」を入力属性、「住所」、「氏名」を出力属性とする「検索」メソッドとの二つに関連を持つことを表すことができる。
【００３９】
仕様データベース探索支援部１２は、ユーザインタフェース部１０から仕様データベース３をアクセスしたり、仕様エディタ部１１において仕様を再利用する際に、適切な仕様部品を仕様データベース３ａから探索するために、ユーザ認識部１３を起動させ、探索経路絞り込み部１４で作成した仕様データベース３内を探索するための経路を、ユーザインタフェース部１０を介して入出力部１に提示する。
【００４０】
ユーザ認識部１３は、ユーザが現在作成している仕様のシステム名や該当する機能名などの作成状況を認識するための処理を行う。
【００４１】
探索経路絞り込み部１４は、ユーザ認識部１３により認識されたユーザの作成状況の情報と、過去に作成した仕様の作成履歴と、過去に作成した仕様間の関連情報に基づいて、仕様データベース３ａから次に参照すべき１つまたは複数の仕様部品の候補を検索し、あるいは次に何の仕様を作成すべきかという指示を作成する。
【００４２】
履歴作成部１５は、ユーザが作成した仕様の作成手順のデータを作成履歴データベース３ｂに蓄積する。作成履歴は、アプリケーションシステムごとに、作成した順番に、再利用した仕様部品、合成を行なった仕様部品があれば記述する。
【００４３】
以下に、作成履歴の一例を示す。番号は、作成された順番を表す。
１．受注入力オプション
２．受注入力ベース＋受注入力オプション→受注入力
３．受注入力→受注修正
４．受注入力→受注照会
上記の例の場合は、はじめに「受注入力オプション」の仕様部品を作成し、次に「受注入力ベース」と「受注入力オプション」を合成した結果を再利用して、「受注入力」を作成したことを示す。また、次に「受注入力」を再利用して「受注修正」の仕様部品を作成し、その次に「受注入力」を再利用して「受注照会」の仕様部品を作成したことを示している。
【００４４】
経路作成支援部１６は、ユーザからの指示によって、既存の仕様部品間の関係あるいは作成した仕様間の関係など、仕様データベースを探索する際の有効な情報の記述を支援し、探索経路データベース３ｃに蓄積する。探索経路に記述する内容は、アプリケーションシステムごとに、仕様部品間の上位・下位関係、仕様部品間に関連があるという関係を記述する。
【００４５】
以下に、探索経路の例を示す。
・親リンク（Ａ、受注入力画面遷移図、事前リスト照会画面）
・親リンク（Ａ、受注入力画面遷移図、ご依頼主入力画面）
・関連リンク（Ａ、受注入力時間ブロック図、受注入力画面遷移図）
・関連リンク（Ａ、事前リスト照会画面、事前リスト照会画面データ・メソッド図）
なお、各リンクにおいて、Ａは、Ａアプリケーションを示すものとする、
上記の例は、「受注入力画面遷移図」が「事前リスト照会画面」の上位の関係にあり、「受注入力画面遷移図」が「ご依頼主入力画面」の上位の関係にあり、「受注入力時間ブロック図」と「受注入力画面遷移図」に関連があり、「事前リスト照会画面」と「事前リスト照会画面データ・メソッド図」に関連があることを示している。
【００４６】
ここで、仕様データベース３ａは、過去に作成した仕様を蓄積しておくデータベースである。仕様データベースは、仕様の種類に合わせて分類・体系化が可能である。図５に、仕様データベース３ａの一例を概念的に示す（すなわち、図５は仕様の作成者による仕様間の関係のイメージを表現したものである）。例えば事務処理の分野では、アプリケーションシステム毎に仕様を分割し、さらに、時間の流れにそった業務分割を示す仕様、画面の遷移を示す仕様、画面とファイルの関係を示す仕様などに分類することができる。また、各分類ごとに、基本的な仕様部品とオプション的な仕様部品に分類することができる。
【００４７】
さらに図６には、仕様データベースの構造の一例を示す。図中の＜ ＞は、ディレクトリを示す。この仕様データベースは、アプリケーション毎のディレクトリを持つ。各ディレクトリは、サブディレクトリを持つことができる（サブディレクトリは、親ディレクトリに対して、ネストして表現している）。ディレクトリ名は、ユーザが自由に決めることができる。ディレクトリの数も、自由に利用できる。各ディレクトリには、ファイルとサブディレクトリを持つことができる。 図７には、図６の仕様データベース中の＜Ａアプリケーションシステム＞のサブディレクトリである＜仕様分類その１＞の内部の構造の一例を示す。この＜仕様分類その１＞は、ギフトシステム枠組、シーズン締め業務枠組…などのファイルと、＜基本＞、＜オプション＞のサブディレクトリを持つことを示している。
【００４８】
また、図７は、上のファイル間の関係を示したものであるが、この情報は、探索経路データベース３ｃに、アプリケーション毎に記述する。仕様データベースは、一般のファイルシステムと同じものを想定しており、仕様間には、さまざまな意味情報を持っている。これらの意味情報を記述できる枠組が、探索経路データベース３ｃであり、後からでも追加して、関係データを記述することができる。
【００４９】
図８、図９には、図６の仕様データベース中の＜Ａアプリケーションシステム＞のサブディレクトリである、＜仕様分類その２＞と＜仕様分類その３＞の内部の構造の一例を夫々示す。
【００５０】
基本となる仕様部品とオプションとなる仕様部品と、これらを用いて作成した仕様分類その１〜その３に含まれる仕様との関係は、作成履歴に記述する。また、仕様分類内の上位・下位関係、仕様分類間の部品の関連の関係については、探索経路（親リンク、子リンク、関連リンク）にて記述する。
【００５１】
各仕様分類の記述例、および部品間の関連の例を、図１０、図１１、図１２に示す。
【００５２】
作成履歴データベース３ｂは、過去に作成した仕様の手順である作成履歴を蓄積しておくデータベースである。作成履歴データベース３ｂは、作成履歴データをアプリケーション毎に分類する。
【００５３】
探索経路データベース３ｃは、探索経路絞り込み部１４及び経路作成支援部１６で作成された、仕様データベースを探索するための探索経路を、蓄積しておくデータベースである。探索経路データベース３ｃは、探索経路データをアプリケーション毎に分類する。例えば、図５の表すアプリケーションシステムの探索経路は、図１０、図１１、図１２に示したように、上位・下位関係を示すものと、探索経路作成支援部１６の記述で示したように仕様間の関連を示すものである。図１０では、「ギフトシステム」を記述した仕様が、「シーズン中業務」、「シーズン締め業務」、「シーズンオフ業務」、「シーズン開始業務」の仕様を持つことを示す。さらに「シーズン中業務」が、「受注入力」、「受注修正」、「受注照会」の仕様をもつことを示す。これらの関係は、親リンクを用いて記述する。
【００５４】
図１１は、「受注入力」、「受注修正」、「受注照会」の仕様部品があることを示す。また、「受注入力」は、「事前リスト照会画面」、「ご依頼主入力画面」、「お届け商品入力画面」の仕様を持つことを示す。「事前リスト照会画面」は、「事前リスト照会フィールド移動」の仕様を持つことを示す。これらの関係は、親リンクを用いて記述する。
【００５５】
図１２は、「事前リスト照会画面」と「事前マスタファイル」と「実績顧客マスタファイル」の仕様部品があることを示す。また、「事前リスト照会画面」は「顧客データ検索」と「顧客データ表示」の仕様を持っている。「事前マスタファイル」は、「事前申込顧客データ検索」と「事前申込顧客データ表示」の仕様を持つことを示す。「実績顧客マスタファイル」は「実績顧客データ検索」と「実績顧客データ表示」の仕様を持つことを示す。これらの関係は、親リンクを用いて記述する。
【００５６】
一方、「顧客データ検索」は「事前申込顧客データ検索」と「実績顧客データ検索」と同じ「検索」を記述した仕様であり、関連があるため、関連リンクを用いて記述する。同様に、「顧客データ表示」は「事前申込顧客データ検索」と「実績顧客データ検索」と関連を関連リンクを用いて記述する。
【００５７】
また、図１０の「受注入力」の仕様と図１１の「受注入力」の仕様が関連がある場合、および図１１の「事前リスト照会画面」の仕様と図１２の「事前リスト照会画面」の仕様が関連がある場合は、次のように関連リンクを用いて記述する。
【００５８】
・関連リンク（Ａ、（分類１）受注入力、（分類２）受注入力）
・関連リンク（Ａ、（分類２）事前リスト照会画面、（分類３）事前リスト照会画面）
次に、このような構成のソフトウェア仕様再利用支援装置の動作について説明する。図１３、図１４（ａ），（ｂ）、図１５（ａ），（ｂ），（ｃ）に、本実施例のソフトウェア仕様再利用支援装置の動作のフローチャートを示す。
【００５９】
まず、入出力部１から、ユーザからの指示により、ユーザ・インタフェース部１は起動する（ステップＰ１）。
【００６０】
ユーザ・インタフェース部１が起動すると、ユーザからの指示により、仕様エディタ部１１、仕様データベース探索支援部１２、履歴作成部１５、経路作成支援部１６のいずれかが起動されるかまたは、データベース３へアクセスする（ステップＳ１〜Ｓ４）。
【００６１】
仕様エディタ部１１が起動すると（ステップＳ１０）、仕様の編集画面が起動される（ステップＳ１１）。ユーザの指示によって、仕様エディタ部１１では、図２、図３、図４のような仕様を作成する（ステップＳ１２）。仕様データベース３ａから再利用したい仕様部品をロードして（ステップＳ１３〜Ｓ１４）、ユーザの指示により編集する。ユーザの指示により、仕様エディタ部１１での作成が終了すると（ステップＳ１５）、履歴編集画面を起動し、履歴作成の支援を行なう（ステップＳ１６〜Ｓ１７）。ユーザの指示により、履歴の作成が終了すると、経路編集画面を起動し、経路作成の支援を行なう（ステップＳ１７〜Ｓ１８）。ユーザの指示により、経路の作成が終了すると、ユーザ・インタフェース部の起動状態に戻る（ステップＳ１９）。
【００６２】
仕様データベース探索支援部１２が起動すると（ステップＳ２０）、ユーザ認識部１３を起動して、ユーザの仕様作成状況を認識する（ステップＳ２１（処理ａ））。続いて、探索経路絞り込み部１４が起動する（ステップＳ２２）。探索経路作成部１４によって、探索経路データが渡されると（ステップＳ２３（処理ｂ），Ｓ２４）、その情報をユーザインタフェース１０を通してユーザに提示し、ユーザインタフェースの起動状態に戻る（ステップＳ２５（処理ｅ））。
【００６３】
上記ステップＳ２１にて、ユーザ認識部１３が起動されると、ユーザの現在の仕様作成状況を認識し、そのデータを探索経路絞り込み部１４に渡す。ユーザの現在の仕様作成状況の認識の動作（処理ａ）については、図１６のフローチャートに示す。最新の作成履歴をデータベースより認識する（ステップＳ２１０）。最も新しい仕様について仕様名を提示する（ステップＳ２１１）。確認入力があった場合は終了する（ステップＳ２１２）。そうでない場合は、別の仕様名の入力を待ち（ステップＳ２１３）、再度確認入力を待つ。
【００６４】
上記ステップＳ２３にて、探索経路絞り込み部１４にユーザの仕様作成情報が渡されると、作成履歴データベース３ｂ及び探索経路データベース３ｃから、該当する情報を次の手順で検索し、このユーザに適したデータベース探索経路を生成し、そのデータを仕様データベース探索支援部１２に渡す。探索経路の生成の動作（処理ｂ）については、図１７のフローチャートに示す。ユーザの仕様作成状況により作成した仕様（部品）のリストａを作成する（ステップＳ２３０）。参照している仕様の作成履歴から、既に作成した仕様（部品）のリストｂを作成する（ステップＳ２３１）。リストｂからリストａの要素を取り除いて、未作成の仕様（部品）のリストαを作成する（ステップＳ２３２）。リストαの要素を作成した履歴のリストβを、参照している仕様の作成履歴より抽出する（ステップＳ２３３）。探索経路データベース３ｃより、作成中の仕様と同じ仕様名のコースγを抽出する（ステップＳ２３４）。リストα、リストβ、コースγを探索経路データとして、次の工程に渡す（ステップＳ２３５）。
【００６５】
ここで、ユーザの作成状況は、（分類２）「受注入力」を作成終了したところであるとする。参照している作成履歴は、以下に示す内容であると仮定する。
【００６６】
１．（分類２）受注入力オプション
２．（分類２）受注入力ベース＋（分類２）受注入力オプション→（分類２）
受注入力
３．（分類２）受注入力→（分類２）受注修正
４．（分類２）受注入力→（分類２）受注照会
また、参照する仕様データベースの内容は、図５〜図８であるとする。また、探索経路は、上述した親リンク、関連リンクの内容であると仮定する。
【００６７】
すると、フローチャート図１７において、
・α：［（分類２）受注修正，（分類２）受注照会］
・β：［［［（分類２）受注入力］、［（分類２）受注修正］］、［［（分類２）受注入力］、［（分類２）受注照会］］］
・γ：
親リンク（（分類２）受注入力，（分類２）事前リスト照会画面）
親リンク（（分類２）受注入力，（分類２）ご依頼主入力画面）
親リンク（（分類２）受注入力，（分類２）お届け商品入力画面）
関連リンク（（分類１）受注入力，（分類２）受注入力）
である。
【００６８】
よって、仕様データベース探索支援部１２でユーザに提示される情報としては、 ＜作成履歴から＞
・「（分類２）受注入力を再利用して、（分類２）受注修正が作成できます。
」・「（分類２）受注入力を再利用して、（分類２）受注照会が作成できます。」 ＜探索経路から＞
・「（分類２）受注入力は、（分類２）事前リスト照会画面を要素として持ちます。」
・「（分類２）受注入力は、（分類２）ご依頼主入力画面を要素として持ちます。」
・「（分類２）受注入力は、（分類２）お届け商品入力画面を要素として持ちます。」
・「（分類１）受注入力と（分類２）受注入力は関連があります。」
などとなる。
【００６９】
履歴作成部１５が起動されると（ステップＳ３０（処理ｃ−１））、履歴の作成支援を行なって、ユーザの指示により、ユーザの仕様作成手順を作成履歴データベース３ｂに蓄積する（ステップＳ３１（処理ｃ−２））。ユーザの指示により編集が終了すると、ユーザ・インタフェース部の起動状態に戻る（ステップＳ３２）。
【００７０】
経路作成支援部１６が起動されると（ステップＳ４０（処理ｄ−１））、経路作成支援を行ない、ユーザの指示により、仕様間の関係や参照すべき仕様の範囲のノウハウを探索経路データベース３ｃに蓄積する（ステップＳ４１（処理ｄ−２））。ユーザの指示により編集終了すると、ユーザ・インタフェース部の起動状態に戻る（ステップＳ４２）。
【００７１】
ユーザにより仕様データベース３へのアクセスが選択されると（ステップＳ４，Ｓ５０）、仕様ＤＢへの参照、ロード、修正、新規ファイル作成などの支援を行なう（ステップＳ５１，Ｓ５２）。ユーザの指示によりアクセスが終了すると、ユーザ・インタフェース部の起動状態に戻る（ステップＳ５３）。
【００７２】
入出力部１からユーザの指示によって、ユーザ・インタフェース部は終了する（ステップＳ４，Ｓ５０，Ｓ５４）。
【００７３】
さて、上記ステップＳ２０にて、仕様データベース探索支援部１２が起動され、前述のようにして探索経路データが得られると、上記ステップＳ２５にてその情報をユーザインタフェース１０を通してユーザに提示し、ユーザとの対話が行われる。このユーザへの探索経路データの提示（処理ｅ）については、図１８のフローチャートに示す。
【００７４】
まず、探索経路メニューとして、
▲１▼（参照システム）の履歴
▲２▼（現在使用可能な）仕様部品の候補
▲３▼関連した仕様部品
▲４▼上位の仕様部品
が提示される（ステップＳ２５０）。
【００７５】
履歴（▲１▼）が選択された場合、これを提示する（ステップＳ２５１１）。
【００７６】
仕様部品の候補（▲２▼）が選択された場合、これを提示する（ステップＳ２５２１）。
【００７７】
関連した仕様部品（▲３▼）が選択された場合、コースγより、関連リンクで結ばれた仕様名を抽出する（ステップＳ２５３０）。関連仕様名の提示を行う（ステップＳ２５３１）。リンク探索を拡張したい場合に、仕様の入力があったとき、コースの抽出を行い（ステップＳ２５３３）、上記ステップＳ２５３０から同様に処理を行う。
【００７８】
上位の仕様部品（▲４▼）が選択された場合、コースγより、親リンクで結ばれた仕様名を抽出する（ステップＳ２５４０）。上位仕様名の提示を行う（ステップＳ２５４１）。リンク探索を拡張したい場合に、仕様の入力があったとき、コースの抽出を行い（ステップＳ２５４３）、上記ステップＳ２５３０から同様に処理を行う。
【００７９】
以上のように、本実施例のソフトウェア仕様再利用支援装置によれば、データベース内にソフトウェア仕様とともに、該ソフトウェア仕様の作成履歴、該ソフトウェア仕様間の関連情報を蓄積してあるので、仕様データベース内の関係が明らかになり、次に再利用できる仕様の候補を挙げること、次の作成手順をガイドすることができるため、仕様作成の生産性が向上する。また、仕様間の関係がガイドによって示されるため、修正内容の影響範囲が明らかになり、仕様作成の信頼性が向上する。
【００８０】
（第２の実施例）
次に、本発明の第２の実施例を説明する。
【００８１】
本実施例は、概略的には、第１の実施例を機能拡張したものである。すなわち、まず、本実施例では、第１の実施例における探索経路データベースの記述を拡張し、仕様間にどのような関係が存在するかを示す情報であるリンク属性を任意に設定できるようにするとともに、同じリンク属性を持つもので互いに関連するものは、複数仕様と複数仕様との間の関係として記述できるようにしている。本実施例では、これを、リンクデータベースと呼ぶ。
【００８２】
また、本実施例では、第１の実施例における仕様データベース探索支援部によるユーザへの情報提示機能をさらに拡張し、ユーザがリンク属性の種類を優先度とともに自由に指定できるようにするとともに、これに応じて既存の仕様を再利用する際の支援とするためのガイド情報を生成するようにしている。本実施例では、仕様データベース再利用支援部と呼ぶ。
【００８３】
また、本実施例では、仕様作成状況を随時格納していく３つのスロットを持つワーキングメモリを設け、第１の実施例ではマニュアル操作を想定していた履歴作成部に対し、自動的に作成履歴を生成・登録できるようにしている。本実施例では、作成履歴生成部と呼ぶ。
【００８４】
本実施例において、仕様とは、第１の実施例と同様の概念を含むが、リンクデータベースにより仕様間の関係の表し方を拡張しているので、これに応じて扱うことのできる仕様の構造も拡張することができる。
【００８５】
図１９は、本実施例に係るソフトウェア仕様再利用支援装置の構成図である。同図に示すように、本実施例のソフトウェア仕様再利用支援装置は、入出力部１０１、処理部１０２、データベース１０３から構成されている。入出力部１０１からの指示・データ入力等により、処理部１０２が、データベース１０３をアクセスしながら、処理を進めていく。図１９中の矢印は、データや制御信号の流れを示す。
【００８６】
入出力部１０１は、入力装置であるキーボード、出力装置であるＣＲＴ等からなり、ソフトウェアの仕様の入力や表示を行なうことができる。入力装置としては、いわゆるマウスを利用あるいは併用することもできる。出力装置としては、プリンタを利用あるいは併用することもできる。
【００８７】
処理部１０２は、ユーザインタフェース部１１０、ワーキングメモリ部１２０、仕様エディタ部１３０、仕様データベース再利用支援部１４０、再利用ノウハウ獲得部１５０からなる。処理部１０２は、例えばＣＰＵとメモリなどを用いて構成され、ソフトウェア処理によって機能が提供される。
【００８８】
データベース１０３は、仕様データベース１６０、再利用ノウハウデータベース１７０からなる。
【００８９】
再利用ノウハウデータベース１７０は、作成履歴データベース１７１と仕様間関係知識データベース１７２からなる。さらに、仕様間関係知識データベース１７２は、リンクデータベース１７３とリンク属性データベース１７４からなる。詳細は後述するが、仕様データベース１６０は、過去に作成した仕様を蓄積しておくデータベースであり、作成履歴データベース１７１は、過去に作成した仕様の手順である作成履歴を蓄積しておくデータベースである。また、リンクデータベース１７３は、仕様部品が持つ仕様間の関係を記述したデータベースであり、リンク属性データベース１７４は、リンクデータベース１７３に記述された仕様間の関連における属性の種類を記述したデータベースである。
【００９０】
ユーザインタフェース部１１０は、仕様データベース１６０へアクセスし、内容を入出力部１０１へ表示する。また、仕様エディタ部１３０、仕様データベース再利用支援部１４０、再利用ノウハウ獲得部１５０夫々についての起動、終了、実行内容の入出力部１０１への表示を行なう。
【００９１】
仕様エディタ部１３０は、テキストエディタや図形作成エディタなど、仕様を作成する上で必要なエディタを呼び出し、ソフトウェアを構成する仕様の記述の支援を行う。また、仕様データベース１６０に蓄積されたファイルの読み込み／編集／保存を行うことができる。
【００９２】
ワーキングメモリ部１２０は、ユーザが仕様エディタ部１３０を通して行う仕様ファイルの読み込み・合成・保存などの操作を記録する。ワーキングメモリ部１２０は、作成中のシステム全体を指すアプリケーション名を記述するＷＭ１スロットと、ＷＭ１スロットに記述されたアプリケーションのうち、現在までに作成済みの仕様名のリストを記述するＷＭ２スロットと、仕様作成の作業過程を一時的に記憶するＷＭ３スロットから構成される。
【００９３】
仕様データベース再利用支援部１４０は、ユーザ認識部１４１、再利用ノウハウ種類選択部１４２、再利用ガイド生成部１４３、再利用ガイド提示部１４４から構成され、ユーザに対して、再利用する仕様を選択するためのガイドを生成し提示する。
【００９４】
ユーザ認識部１４１は、ユーザが現在作成している仕様のシステム名や該当する機能名などの作成状況を認識する。
【００９５】
再利用ノウハウ種類選択部１４２は、リンク属性データベース１７４に記述された再利用ノウハウの種類をユーザに提示し、再利用の目的にあったノウハウの種類とそれらの優先度の入力を支援し、入力したデータを再利用ガイド生成部１４３に受け渡す。
【００９６】
再利用ガイド生成部１４３は、ユーザ認識部１４１により得られたユーザの作成状況と、再利用ノウハウ種類選択部１４２から渡されたノウハウの種類およびそれらの優先度によって、再利用ノウハウデータベース１７０に記述された作成履歴、仕様間の関連知識などのノウハウから、適切なノウハウを選択し、ユーザが再利用すべき１つまたは複数の仕様部品の候補をあげ、または次に何の仕様を作成すべきかなどの提示からなるガイドを作成する。
【００９７】
再利用ガイド提示部１４４は、再利用ガイド生成部１４３によって作成されたガイドをユーザインタフェースを通してユーザに提示または出力する。
【００９８】
再利用ノウハウ獲得部１５０は、作成履歴生成部１５１、ノウハウ種類選択部１５２、ノウハウデータ作成部１５３から構成され、ユーザが再利用を行うことによって得られたノウハウを登録することを支援する。
【００９９】
作成履歴生成部１５１は、ワーキングメモリ部１２０のＷＭ３スロットにおいて、内容が「保存」されるごとに、そこまでの作業過程を作成履歴データベース１７１に蓄積する。
【０１００】
例えば、
Ａファイル読み込み
Ｂファイル合成
Ｃファイルに保存
というように、ワーキングメモリに記述された場合の履歴は、
Ａファイル＋Ｂファイル→Ｃファイル
となる。履歴の蓄積が１回終了すると、ワーキングメモリのＷＭ３の内容をリセットする。
【０１０１】
ノウハウ種類選択部１５２は、ユーザが再利用ノウハウを蓄積したいか、または修正したい場合、ユーザの指示によって、リンク属性データベース１７４に記述されたノウハウの種類を提示し、選択されたノウハウの種類名または新規ノウハウの種類名をノウハウデータ作成部１５３に渡す。
【０１０２】
ノウハウデータ作成部１５３は、ノウハウ種類選択部１５２から送られたノウハウの種類名または新規ノウハウの種類名をユーザに提示する。次に、ユーザが入力したノウハウ情報を、リンクデータベース１７３に追加・編集・削除する。
【０１０３】
仕様データベース１６０は、過去に作成した仕様を蓄積しておくデータベースである。仕様データベース１６０は、仕様の種類に合わせて分類・体系化が可能である。
【０１０４】
再利用ノウハウデータベース１７０は、作成履歴データベース１７１と仕様間関係知識データベース１７２から構成される。
【０１０５】
作成履歴データベース１７１は、過去に作成した仕様の作成手順である作成履歴を蓄積しておくデータベースである。以下に、作成履歴の一例を示す。番号は、作成された順番を表す。
【０１０６】
１． →受注入力オプション（Ａシステム，画面遷移図）
２．受注入力基本（Ａシステム，画面遷移図）
＋受注入力オプション（Ａシステム，画面遷移図）
→受注入力実業務（Ａシステム，画面遷移図）
３．受注入力実業務（Ａシステム，画面遷移図）
→受注修正実業務（Ａシステム，画面遷移図）
４．受注入力実業務（Ａシステム，画面遷移図）
→受注照会実業務（Ａシステム，画面遷移図）
この例は、ある百貨店Ａの「ギフトシステム」の仕様作成の手順を示したものである。「ギフトシステム」は、受注内容をファイルに書き込む「受注入力」という業務を、百貨店が異なっても備えている。「受注入力オプション（Ａシステム，画面遷移図）」とは、百貨店Ａの受注入力の業務の画面遷移図のうち、百貨店ごとに異なった補助的な部分を示している。
【０１０７】
「受注入力基本（Ａシステム，画面遷移図）」とは、受注入力のうち、百貨店が異なっても共通した業務の画面遷移図を表している。
【０１０８】
「受注入力実業務（Ａシステム，画面遷移図）」とは、ある百貨店Ａの受注入力の業務の画面遷移図全体を表している。
【０１０９】
同様に、「受注修正実業務（Ａシステム，画面遷移図）」、「受注照会実業務（Ａシステム，画面遷移図）」は、それぞれ、ある百貨店Ａの受注修正業務、受注紹介業務の画面遷移図全体を表している。
【０１１０】
上記の作成履歴では、次のことを示している。はじめに「受注入力オプション（Ａシステム，画面遷移図）」の画面遷移図を作成する。次に、「受注入力基本（Ａシステム，画面遷移図）」と「受注入力オプション（Ａシステム，画面遷移図）」を合成した結果を再利用して、「受注入力実業務（Ａシステム，画面遷移図）」を作成したことを示す。次に、「受注入力実業務（Ａシステム，画面遷移図）」を再利用して、「受注修正実業務（Ａシステム，画面遷移図）」の画面遷移図を作成し、その次に、「受注入力実業務（Ａシステム，画面遷移図）」を再利用して、「受注照会実業務（Ａシステム，画面遷移図）」の画面遷移図を作成したことを示している。
【０１１１】
ここでは仕様の例として画面遷移図を挙げたが、仕様としては前述したように、ファイル名などの識別が可能なデータであればよい。
【０１１２】
仕様間関係知識データベース１７２は、リンクデータベース１７３と、リンク属性データベース１７４から構成される。
【０１１３】
リンクデータベース１７３とは、仕様部品が持つ仕様間の関係を記述する。リンクデータベース１７３のフォーマットは、次の通りである。
［［仕様１，仕様２，仕様３，…］，［仕様ａ，仕様ｂ，仕様ｃ，…］，［属性α，属性β，属性γ，…］］
これは、仕様１，仕様２，仕様３，…が、仕様ａ，仕様ｂ，仕様ｃ，…と、属性α，属性β，属性γ，…からなる関係があることを示す。
【０１１４】
以下に、リンクデータベース１７３の記述例を示す。
ａ） ［［受注入力実業務（Ａシステム，画面遷移図）］，［事前リスト照会画面（Ａシステム，画面レイアウト），ご依頼主入力画面（Ａシステム，画面レイアウト）］，［親子］］
ｂ） ［［受注入力実業務（Ａシステム，画面遷移図）］，［事前リスト帳票（Ａシステム，画面レイアウト），受注リスト帳票（Ａシステム，画面レイアウト）］，［関連］］
ｃ） ［［受注入力業務分割図（Ａシステム，業務分割図）］，［受注入力実業務（Ａシステム，画面遷移図）］，［修正影響，用語（受注入力）］］
上記ａの例は、Ａシステムの「受注入力実業務」という画面遷移図が、Ａシステムの「事前リスト照会画面」および「ご依頼主入力画面」という画面レイアウトと親子関係にあることを示している。
【０１１５】
上記ｂの例は、Ａシステムの「受注入力実業務」という画面遷移図が、Ａシステムの「事前リスト帳票」および「受注リスト帳票」という画面レイアウトと関連があることを示している。ここでの「関連」とは、特別な属性がなく、単に関連を持つことのみを表す。
【０１１６】
上記ｃの例では、「受注入力業務分割図」という業務分割図が、Ａシステムの「受注入力実業務」という画面遷移図と、どちらかを修正するとその影響があること、および「受注入力」という用語で共通していることを示している。
【０１１７】
リンク属性データベース１７４は、リンクデータベース１７３で記述した仕様間の関連における属性の種類を記述したものである。
【０１１８】
以下に、属性の種類の例を示す。
−作成履歴
−修正影響
−関連
−用語
−親子
上記の「関連」については、「関連（大）」「関連（中）」「関連（小）」などのように、関連の程度を細分化した属性を設けても良い。また、上記の他にも様々な属性の種類を任意に指定することができる。
【０１１９】
次に、このような構成のソフトウェア仕様再利用支援装置の動作について説明する。図２０〜図２３に、本実施例のソフトウェア仕様再利用支援装置の動作のフローチャートを示す。
【０１２０】
まず、入出力部１０１から、ユーザからの指示により、ユーザ・インタフェース部１１０が起動する（ステップＰ１０１）。
【０１２１】
ユーザ・インタフェース部１１０が起動すると、ユーザからの指示により、仕様エディタ部１３０、仕様データベース再利用支援部１４０、再利用ノウハウ獲得部１５０のいずれかが起動する（ステップＳ１０１〜Ｓ１０３）。
【０１２２】
仕様エディタ部１３０が起動すると（ステップＳ１１０）、ワーキングメモリ部１２０が起動され（ステップＳ１１１）、仕様作成を行なうシステム全体の名称（アプリケーション名）をユーザから入力させ、ＷＭ１スロットに記述する（ステップＳ１１２）。そして、仕様の編集画面が起動される（ステップＳ１１３）。ユーザの指示によって、仕様エディタ部１３０では、所望の仕様を作成する（ステップＳ１１４）。また、仕様データベース１６０から再利用したい仕様部品のファイルをロードし、ユーザの指示により編集・合成を行ない、保存を行なう（ステップＳ１１５，Ｓ１１６，Ｓ１１８）。ワーキングメモリ部１２０のＷＭ２スロットには作成された仕様ファイルの名前リストが記述され（ステップＳ１１９）、ＷＭ３スロットには仕様エディタ部１３０で実行された作業内容のうち、ファイルのロード・合成・保存が記録される（ステップＳ１１７）。
【０１２３】
さて、ワーキングメモリ部１２０において、「ファイルの保存」が記述されると（ステップＳ１１９）、再利用ノウハウ獲得部１５０の作成履歴生成部１５１が起動され（ステップＳ１２０）、ワーキングメモリ内の作業過程を、作成履歴として、作成履歴データベース１７１に記述する（ステップＳ１２１（処理ｓ））。記述が終了した後、仕様作成状態に戻る場合、ステップＳ１１４に移り、仕様エディタ部１３０を終了する場合、ステップＰ１０１に戻り、（ステップＳ１２２）。
【０１２４】
ここで、ステップＳ１２１の作成履歴の生成から登録までの動作（処理ｓ）の一例を図２４のフローチャートに示す。まず、ワーキングメモリのＷＭ３（作業過程）を読み込む（ステップＳ５００）。先頭行から一行ずつ読み込み（ステップＳ５０１）、「○○ファイル読み込み」と記述されている場合（ステップＳ５０２）、「○○ファイル」と変換し（ステップＳ５０５）、「○○ファイル合成」と記述されている場合（ステップＳ５０３）、「＋○○ファイル」と変換し（ステップＳ５０６）、「○○ファイル保存」と記述されている場合（ステップＳ５０４）、「→○○ファイル」と変換する（ステップＳ５０７）。ただし、上記の○○は、ファイル名を表す。そして、ＷＭ３が空行でない場合、ステップＳ５０１以降の処理を繰り返し（ステップＳ５０８）、空行の場合（ステップＳ５０８）、変換結果を作成履歴データベース１７１に記述する（ステップＳ５０９）。
【０１２５】
一方、仕様データベース再利用支援部１４０が起動すると（ステップＳ１３０）、ユーザ認識部１４１を起動して（ステップＳ１３１）、ユーザの仕様作成状況を認識し（ステップＳ１３２（処理ｔ））、その結果を再利用ガイド生成部１４３に渡す。
【０１２６】
続いて、再利用ノウハウ種類選択部１４２を起動して（ステップＳ１３３）、ユーザに、再利用したいノウハウの種類とノウハウの優先度を決定させ、その結果を再利用ガイド生成部１４３に渡す。なお、予め再利用したいノウハウの種類とノウハウの優先度を設定しておき、このステップを省略できるようにしても良い。
【０１２７】
再利用ガイド生成部１４３に、ユーザの作成状況と、再利用するノウハウの種類と優先度が渡され、起動されると（ステップＳ１３４）、再利用ノウハウデータベース１７０の作成履歴データベース１７１とリンクデータベース１７３から、このユーザに適したデータベース再利用のガイド情報を生成し（ステップＳ１３５（処理ｕ））、そのデータを再利用ガイド提示部１４４に渡す。
【０１２８】
次に、再利用ガイド提示部１４４によって、生成されたガイドをユーザ・インタフェース部１１０を通してユーザに提示し（ステップＳ１３６）、ユーザ・インタフェースの起動状態に戻る（ステップＰ１０１）。
【０１２９】
ここで、ステップＳ１３２のユーザの現在の仕様作成状況の認識の動作（処理ｔ）の一例を図２５のフローチャートに示す。まず、ワーキングメモリのＷＭ３（作業過程）を読み込む（ステップＳ３０１）。先頭行から一行ずつ読み込み（ステップＳ３０２）、「○○ファイル読み込み」と記述されている場合に（ステップＳ３０３）、「○○ファイル」を現在作成中の仕様の名称としてユーザに提示する（ステップＳ３０４）。確認入力があった場合（ステップＳ３０５）、終了する。そうでない場合は（ステップＳ３０５）、別の仕様名の入力を待ち（ステップＳ３０６）、再度確認入力を待つ（ステップＳ３０５）。
【０１３０】
次に、ステップＳ１３５のガイドの生成動作（処理ｕ）の一例を図２６〜図２９のフローチャートに示す。まず、ワーキングメモリのＷＭ２（既に作成されている仕様のリスト）を読み込む（ステップＳ４００）。前述の処理ｔで得られた（作成中の仕様の）仕様名を認識する（ステップＳ４０１）。作成履歴データベース１７１を読み込む（ステップＳ４０２）。
【０１３１】
そして、一履歴ずつ読み込み（ステップＳ４０３）、左辺の要素が１つでもＷＭ２の要素となっており、かつ、右辺の要素がすべてＷＭ２に含まれないものである場合に（ステップＳ４０４，Ｓ４０５）、該当する式を一時的にファイルαに追加する（ステップＳ４０６）。ステップＳ４０３〜ステップＳ４０６の処理を、履歴読み込みが終了するまで繰り返す（ステップＳ４０７）。
【０１３２】
次に、ファイルαの履歴を一履歴ずつ読み込み（ステップＳ４０８）、左辺の要素でＷＭ２に含まれない要素がある場合に、これを要素ｅとし（ステップＳ４０９）、作成履歴データベース１７１を一履歴ずつ検索し（ステップＳ４１０）、上記の要素ｅが右辺にある場合に（ステップＳ４１１）、該当する式を一時的にファイルβに追加する（ステップＳ４１２）。ステップＳ４０８〜ステップＳ４１２の処理を、履歴検索が終了するまで繰り返し（ステップＳ４１３）、その後、ファイルαとファイルβを合わせて、記述された順にソートし、これをファイルγとする（ステップＳ４１４）。
【０１３３】
次に、前述の処理ｔで得られた現在作成中の仕様の仕様名を認識し、これを“ＳＰＥＣ”に代入する（ステップＳ４１５）。リンクデータベース１７３を読み込む（ステップＳ４１６）。リンクデータベース１７３のノウハウを１件ずつ読み込み（ステップＳ４１７）、ノウハウ中に“ＳＰＥＣ”が示す仕様名と同じものが出現した場合に（ステップＳ４１８）、該当するノウハウの式を一時的にファイルθに追加し（ステップＳ４１９）、ユーザが指定したノウハウの属性の種類と順序を読み込み（ステップＳ４２０）、ファイルθのノウハウを１件ずつ読み込む（ステップＳ４２１）。ステップＳ４１７〜ステップＳ４２１の処理を、ユーザが指定した属性のノウハウである間繰り返し（ステップＳ４２２）、その後、該当するノウハウの式をファイルλに追加する（ステップＳ４２３）。
【０１３４】
次に、ユーザが指定した（優先度順に並んでいる）ノウハウ属性から一属性ずつ読み込み（ステップＳ４２４）、属性が「作成履歴」である場合に（ステップＳ４２５）、ファイルμにファイルγを追加する（ステップＳ４２６）。
【０１３５】
属性の読み込みが終了した場合（ステップＳ４２７）、ファイルμの内容をガイドとし（ステップＳ４３３）、一時的に作成したファイルα，β，γ，θ，λ，μを削除した後、終了する（ステップＳ４３４）。
【０１３６】
属性の読み込みが終了していない場合（ステップＳ４２７）、ファイルλの１件目から該当する属性のノウハウを読み込み（ステップＳ４２８）、ファイルλが空になった場合、ファイルμの内容をガイドとし（ステップＳ４３３）、一時的に作成したファイルα，β，γ，θ，λ，μを削除した後、終了する（ステップＳ４３４）。一方、空になっていない場合（ステップＳ４２９）、ファイルμに追加し（ステップＳ４３０）、ファイルλから現在読み込んだノウハウを削除し（ステップＳ４３１）、ファイルλの最終行までチェックが終了していない場合は（ステップＳ４３２）、ステップ４２８に戻り、ファイルλの最終行までチェックが終了した場合は（ステップＳ４３２）、ステップ４２４に戻る。
【０１３７】
また、再利用ノウハウ獲得部１５０が起動されると（ステップＳ１４０）、ノウハウ種類選択部１５２が起動され（ステップＳ１４１）、リンク属性データベース１７４に記述された内容が読み込まれ、ユーザ・インタフェースを通して提示される。ユーザの指示により、ノウハウの種類が選択されるか、または新規ノウハウの種類が登録される（ステップＳ１４２）。新規ノウハウの種類は、リンク属性データベースに記述される。
【０１３８】
ノウハウ種類選択部１５２によって、ユーザが、ノウハウの種類の指定、または新規ノウハウの種類名を指定すると、ノウハウデータ作成部１５３が起動される（ステップＳ１４３）。
【０１３９】
次に、エディタを用いて、指定したノウハウの種類のノウハウをユーザが記述し（ステップＳ１４４）、作成履歴データベース１７１またはリンクデータベース１７３に記述する（ステップＳ１４５）。または、過去に記述したノウハウを、作成履歴データベース１７１またはリンクデータベース１７３から呼び出し、エディタによって編集・削除を行なう（ステップＳ１４４，Ｓ１４５）。
【０１４０】
ユーザの指示により編集が終了すると（ステップＳ１４６）、ユーザ・インタフェース部１１０の起動状態に戻る（ステップＰ１０１）。
【０１４１】
なお、入出力部１０１からユーザの指示によって、ユーザ・インタフェース部１１０は終了する（ステップＳ１０４）。
【０１４２】
次に、上記のガイドを生成する処理の具体例を示す。
【０１４３】
ここでは、ユーザの作成状況が、あるＢシステムの画面遷移図である受注入力実業務を作成完了したところであるとする。また、Ｂシステムについては、受注入力オプション、受注入力基本の画面遷移図が既に作成されているとする。再利用する対象として、既に作成が終了しているＡシステムの仕様と再利用ノウハウを利用するものとする。Ａシステムの再利用ノウハウである作成履歴、リンクデータベース、リンク属性データベースは、それぞれ以下に示す内容であるとする。
【０１４４】
＜作成履歴の一例＞
１． →受注入力オプション（Ａシステム，画面遷移図）
２．受注入力基本（Ａシステム，画面遷移図）
＋受注入力オプション（Ａシステム，画面遷移図）
→受注入力実業務（Ａシステム，画面遷移図）
３．受注入力実業務（Ａシステム，画面遷移図）
→受注修正実業務（Ａシステム，画面遷移図）
４．受注入力実業務（Ａシステム，画面遷移図）
→受注照会実業務（Ａシステム，画面遷移図）
５． →実績入力オプション（Ａシステム，画面遷移図）
６．受注入力実業務（Ａシステム，画面遷移図）
＋実績入力オプション（Ａシステム，画面遷移図）
→実績入力実業務（Ａシステム，画面遷移図）
＜リンクデータベースの一例＞
ａ） ［［受注入力実業務（Ａシステム，画面遷移図）］，［事前リスト照会画面（Ａシステム，画面レイアウト），ご依頼主入力画面（Ａシステム，画面レイアウト）］，［親子］］
ｂ） ［［受注入力実業務（Ａシステム，画面遷移図）］，［事前リスト帳票（Ａシステム，画面レイアウト），受注リスト帳票（Ａシステム，画面レイアウト）］，［関連］］
ｃ） ［［受注入力業務分割図（Ａシステム，業務分割図）］，［受注入力実業務（Ａシステム，画面遷移図）］，［修正影響，用語（受注入力）］］
＜リンク属性データベースの一例＞
作成履歴
修正影響
関連
用語
親子
今、ユーザがノウハウ種類選択において、ノウハウの種類と優先度を次のように設定したものとする。
【０１４５】
＜設定例１＞
優先順位１：作成履歴
優先順位２：修正影響
優先順位３：関連
優先順位４：用語
優先順位５：親子
＜設定例２＞
優先順位１：関連
優先順位２：用語
優先順位３：修正影響
優先順位４：作成履歴
ここで、前述した図２５〜図２８のフローチャートに示す手順を実行し、次のｉ，ｉｉ，ｉｉｉ の手順を実行する。
【０１４６】
ｉ）ＷＭ２＝既に作成してある仕様のリストの認識
ｉｉ）ＷＭ３の内容から、現在作成中または作成終了直後の仕様名の認識
ｉｉｉ ）作成履歴のうち、
左辺に要素が１つでもＷＭ２に含まれ、かつ、右辺の要素がＷＭ２に含まれないもの（すなわち、既に作成した仕様を使って未作成の仕様を作成する手順を示した式）
および
上記の式の左辺の要素で、ＷＭ２に含まれていない要素が、右辺に含まれているもの（すなわち、上記の式において合成を成立させる要素を作成するための手順を示した式）
を抽出し、記述された順にソートする。
【０１４７】
この結果、抽出しソートされた作成履歴は次のようになる。
＜作成履歴＞
１．受注入力実業務（Ａシステム，画面遷移図）
→受注修正実業務（Ａシステム，画面遷移図）
２．受注入力実業務（Ａシステム，画面遷移図）
→受注照会実業務（Ａシステム，画面遷移図）
３． →実績入力オプション（Ａシステム，画面遷移図）
４．受注入力実業務（Ａシステム，画面遷移図）
＋実績入力オプション（Ａシステム，画面遷移図）
→実績入力実業務（Ａシステム，画面遷移図）
よって、再利用ガイド生成部１４３で生成されるガイドとしては、例えば以下に示すようなものが生成され、出力される。
【０１４８】
＜設定例１に対応するガイド＞
１．Ａシステムの画面遷移図である受注入力実業務を再利用して、Ａシステムの画面遷移図である受注修正実業務を作成する。
２．Ａシステムの画面遷移図である受注入力実業務を再利用して、Ａシステムの画面遷移図である受注照会実業務を作成する。
３．Ａシステムの画面遷移図である受注入力オプションを作成する。
４．Ａシステムの画面遷移図である受注入力実業務とＡシステムの画面遷移図である実績入力実業務を作成する。
５．Ａシステムの業務分割図である受注入力業務分割図と修正影響という関係があります。
６．Ａシステムの帳票レイアウトである事前リスト帳票、および同受注リスト帳票（Ａシステム，帳票レイアウト）と、関連があります。
７．Ａシステムの業務分割図である受注入力業務分割図と用語「受注入力」で関連があります。
８．Ａシステムの帳票レイアウトである事前リスト照会画面、および同ご依頼主入力画面と親子関係があります。
【０１４９】
このガイド中のメッセージ１〜４は作成履歴の指定に対応し、メッセージ５は修正影響に対応し、メッセージ６は関連に対応し、メッセージ７は用語に対応し、メッセージ７は親子に対応する。
【０１５０】
また、上記の例では、指定された属性の種類夫々に対応する各メッセージは、設定された優先度の順に出力されている。
【０１５１】
＜設定例２に対応するガイド＞
１．Ａシステムの帳票レイアウトである事前リスト帳票、および同受注リスト帳票（Ａシステム，帳票レイアウト）と、関連があります。
２．Ａシステムの業務分割図である受注入力業務分割図と用語「受注入力」で関連があります。
３．Ａシステムの業務分割図である受注入力業務分割図と修正影響という関係があります。
４．Ａシステムの画面遷移図である受注入力実業務を再利用して、Ａシステムの画面遷移図である受注修正実業務を作成する。
５．Ａシステムの画面遷移図である受注入力実業務を再利用して、Ａシステムの画面遷移図である受注照会実業務を作成する。
６．Ａシステムの画面遷移図である受注入力オプションを作成する。
７．Ａシステムの画面遷移図である受注入力実業務とＡシステムの画面遷移図である実績入力実業務を作成する。
【０１５２】
このガイド中のメッセージ１は関連の指定に対応し、メッセージ２は用語に対応し、メッセージ３は修正影響に対応し、メッセージ４〜７は作成履歴に対応する。ここでは、親子の指定がないので、設定例１に対応するガイドにおけるメッセージ８に該当するものは出力されていない。
【０１５３】
なお、作成履歴の指定に対応するガイドとして、再利用する候補だけ提示しても良い。
【０１５４】
また、作成履歴の指定に対応するガイドとして、再利用する複数の候補だけ提示し、ユーザの候補指定入力を待ち、指定された候補についてのみ、その利用の仕方を提示するようにしても良い。
【０１５５】
その他、種々のガイドの生成・提示の方法が実施可能である。
【０１５６】
以上のように、本実施例のソフトウェア仕様再利用支援装置によれば、過去の仕様の作成履歴や仕様部品間の関係の情報などのノウハウを蓄積してあるので、仕様データベース内の関係が明らかになるとともに、修正内容の影響範囲が明らかになる。そして、ソフトウェア開発における仕様作成工程において、ユーザの仕様作成状況を認識し、またユーザの再利用目的を考慮して、過去の仕様の作成履歴や仕様部品間の関係の情報などのノウハウから、再利用できる仕様の候補や作成手順、あるいは仕様間の関連性に関する情報など適切な仕様再利用のためのガイドを生成し、それをユーザに提示することにより、再利用や変更する仕様および仕様部品の決定を支援することができる。また、仕様を再利用する際の作成手順や仕様間の関連知識などのノウハウをデータベースに蓄積したり、自由に追加・修正したりする作業を支援することができる。
【０１５７】
したがって、仕様の有効活用を行なうことができ、ソフトウェアの仕様作成作業における生産性の向上と出来上がった仕様の信頼性の向上を図ることができる。 （変形例）
ところで、第１の実施例では、履歴作成部は手動モードを前提に説明したが、第２の実施例のようにして自動モードにしても構わない。また、自動モードと手動モードを切り換えて使用できるようにしても良い。
【０１５８】
第２の実施例では、作成履歴生成部は自動モードを前提に説明したが、第１の実施例のように手動モードにしても構わない。また、自動モードと手動モードを切り換えて使用できるようにしても良い。
【０１５９】
また、本発明は上述した各実施例に限定されるものではなく、その要旨を逸脱しない範囲で、種々変形して実施することができる。
【０１６０】
【発明の効果】
本発明によれば、既に作成した仕様の作成履歴や仕様部品間の関係を示す情報を蓄積する機構を設け、それら情報に基づきユーザの仕様作成状況や再利用目的に応じて仕様の再利用を支援することができるので、ソフトウェア開発における仕様作成工程において、仕様の有効活用が行なえ、生産性の向上と出来上がった仕様の信頼性の向上を図ることができる。
【０１６１】
また、本発明によれば、仕様の作成履歴や仕様部品間の関係の情報をデータベースに蓄積したり、自由に追加・修正したりする作業を支援することができるので、ソフトウェア開発における仕様作成工程において、仕様のさらなる有効活用が行なえ、生産性の向上と出来上がった仕様の信頼性のさらなる向上を図ることができる。
【図面の簡単な説明】
【図１】本発明の第１の実施例に係るソフトウェア仕様再利用支援装置の構成を示すブロック図
【図２】図１の仕様エディタ部によって記述できる仕様の記述の一例を示す図
【図３】図１の仕様エディタ部によって記述できる仕様の記述の他の例を示す図
【図４】図１の仕様エディタ部によって記述できる仕様の記述のさらに他の例を示す図
【図５】仕様データベース内の構成の一例を示す概念図
【図６】仕様データベースの構造の一例を示す図
【図７】図６の仕様データベースの内部の構造を示す図
【図８】図６の仕様データベースの内部の構造を示す図
【図９】図６の仕様データベースの内部の構造を示す図
【図１０】仕様データベースを構成する仕様の分類の一例を示す図
【図１１】仕様データベースを構成する仕様の分類の一例を示す図
【図１２】仕様データベースを構成する仕様の分類の一例を示す図
【図１３】同実施例のソフトウェア仕様再利用支援装置の動作を示すフローチャート
【図１４】同実施例のソフトウェア仕様再利用支援装置の動作を示すフローチャート
【図１５】同実施例のソフトウェア仕様再利用支援装置の動作を示すフローチャート
【図１６】ユーザの仕様作成状況を認識する手順を示すフローチャート
【図１７】探索経路データを生成する手順を示すフローチャート
【図１８】ユーザに探索経路情報を提示したあとのユーザとシステムとの対話の手順を示すフローチャート
【図１９】本発明の第２の実施例に係るソフトウェア仕様再利用支援装置の構成を示すブロック図
【図２０】同実施例のソフトウェア仕様再利用支援装置の動作を示すフローチャート
【図２１】同実施例のソフトウェア仕様再利用支援装置の動作を示すフローチャート
【図２２】同実施例のソフトウェア仕様再利用支援装置の動作を示すフローチャート
【図２３】同実施例のソフトウェア仕様再利用支援装置の動作を示すフローチャート
【図２４】作成履歴の生成と登録を行う手順を示すフローチャート
【図２５】ユーザの仕様作成状況を認識する手順を示すフローチャート
【図２６】再利用ガイドを生成する手順を示すフローチャート
【図２７】再利用ガイドを生成する手順を示すフローチャート
【図２８】再利用ガイドを生成する手順を示すフローチャート
【図２９】再利用ガイドを生成する手順を示すフローチャート
【符号の説明】
１…入出力部、２…処理部、１０…ユーザ・インタフェース部、１１…仕様エディタ部、１２…仕様データベース探索支援部、１３…ユーザ認識部、１４…探索経路絞り込み部、１５…履歴作成部、１６…経路作成支援部、３…データベース、３ａ…仕様データベース、３ｂ…作成履歴データベース、３ｃ…探索経路データベース、１０１…入出力部、１０２…処理部、１０３…データベース、１１０…ユーザインタフェース部、１２０…ワーキングメモリ部、１３０…仕様エディタ部、１４０…仕様データベース再利用支援部、１５０…再利用ノウハウ獲得部、１４１…ユーザ認識部、１４２…再利用ノウハウ種類選択部、１４３…再利用ガイド生成部、１４４…再利用ガイド提示部、１５１…作成履歴生成部、１５２…ノウハウ種類選択部、１５３…ノウハウデータ作成部、１６０…仕様データベース、１７０…再利用ノウハウデータベース、１７１…作成履歴データベース、１７２…仕様間関係知識データベース、１７３…リンクデータベース、１７４…リンク属性データベース[0001]
[Industrial applications]
The present invention relates to a software specification reuse support device that supports selection of a specification to be reused in a process of creating a new software specification while reusing an existing specification.
[0002]
[Prior art]
A software specification reuse support device is a device used when a user reuses existing software specifications and newly develops software with high productivity and reliability (hereinafter, the user is an existing user). A person who creates a new specification using the specification database). In the specification reuse system of the conventional software specification reuse support apparatus, first, the main focus is on searching for software specifications having similar specifications. In a general method of specification reuse, a model of a specification for each field is prepared, and information is added based on the template to create a new specification.
[0003]
In the specification search method, based on the requirements of the software to be developed, similar existing specifications are often searched from the viewpoint of the rough function configuration and the number of similar terms appearing in the request sentence. . However, in the development of software in the same field, for example, in customer systems for office work, basic functions and terms used are almost the same even if the customer is different. However, searching for specifications for similarity determination based on the number of terms used is not effective.
[0004]
In addition, when creating a specification by adding information to a model, it is difficult to prepare a model sufficiently and consistently for all tasks. In addition, when creating a new specification using a template, information is added or modified, but the information added or modified in this way is often important information in the creation of another specification. However, there is no means for formalizing such information, and it is difficult to store the information in preparation for the next reuse.
[0005]
Also, existing specifications, including template specifications, are often divided into a plurality of files or made into parts. Various relations such as a relation having a connection of terms, a higher and lower relation, and a relation having a high similarity can be considered as the relation between the specifications as the parts. However, in the conventional method of reusing specifications, there is no mechanism for accumulating knowledge about the relationship between specifications (between parts) as know-how. When a specification is modified or information is added, a change in one part requires It is unclear how it is reflected on other parts, and on the contrary, the reliability of the specification is reduced. Furthermore, in the conventional method of reusing specifications, there is no mechanism for accumulating know-how such as a creation procedure which is important for reusing specifications. In other words, the focus was on which existing specification part to use, and there was no perspective on how to use it. Therefore, the productivity may be reduced depending on the use of parts and the preparation procedure.
[0006]
In addition, the relationship between specifications often changes due to repeated reuse, and it is extremely difficult for a user to properly grasp the relationship between specifications and select an optimal reuse method. .
[0007]
[Problems to be solved by the invention]
As described above, in the conventional software specification reuse support device, based on the requirements of software to be developed, out of the accumulated existing software specifications and component specifications, a rough configuration of functions and similar appearances appearing. From the viewpoint of the number of terms, it is only possible to search for similar specifications, and there was no support at all for the relationship between existing specifications or how to use those specifications. In this case, there were problems in terms of effective use of existing specifications, productivity in development, and reliability of developed specifications.
[0008]
The present invention has been made in consideration of the above circumstances, and recognizes a user's specification creation situation, and determines how an existing specification database is created based on past specification creation history and information on the relationship between specification parts. Generates a search path to determine the specifications to be reused by following the steps described above, and presents it to the user to support the determination of specifications and specification parts to be reused or changed, and to create software specifications. It is an object of the present invention to provide a software specification reuse support device for improving the productivity and reliability of a completed specification.
[0009]
In addition, the present invention has been made in consideration of the above circumstances, and recognizes the specification creation situation of the user, and also considers the user's reuse purpose, and takes into account the past specification creation history and By generating a guide for appropriate specification reuse from the relationship information and presenting it to the user, it assists in the determination of specifications and specification parts to be reused or changed, and is created when specifications are reused. Provide a software specification reuse support device that supports the accumulation of know-how such as the related knowledge between procedures and specifications in a database, and improves the productivity in software specification creation work and the reliability of completed specifications. The purpose is to:
[0010]
[Means for Solving the Problems]
The software reuse support apparatus according to the present invention uses a software specification created in the past, a creation history of the software specification, and a database storing related information between the software specifications, and a software specification stored in the database. Specification creating means for creating a new software specification, a recognizing means for recognizing a current specification creation state by the specification creating means, and a database of the specification creation procedure performed by the specification creating means as a creation history. History creation means for accumulating in the database, a path creation means for accumulating in the database a path for searching in the database as related information, and a specification creation status, the creation history, and the related information stored in the database. Path narrowing down the path to search for software specifications And means, and having a specification database search means for searching for a software specification stored in the database based on the narrowed path by the searched route narrowing means. Preferably, there is further provided a presenting means for presenting a reusable software specification candidate based on a search result of the specification database searching means. Preferably, the presenting means presents an editing procedure for the presented reusable software specification candidate.
[0011]
Further, the software reuse support device according to the present invention, A database that stores externally input software specifications created in the past, creation history of software specifications created in the past, and related information between software specifications created in the past, and software specifications stored in the database. Editing means for creating a new software specification by utilizing, recognition means for recognizing the creation status by the editing means, the creation status, and Stored in the database Based on the creation history and the related information, The database And a presentation means for presenting a reusable software specification candidate among the software specifications stored in the storage device. Preferably, the presenting means presents an editing procedure for the presented reusable software specification candidate.
[0012]
Preferably, the creation history includes information describing a software specification name and a creation order of the software specifications, and includes information describing a use relationship between other software specifications as necessary. And
[0013]
Preferably, the related information includes information describing two or more software specifications together with their software specification names and how to relate them.
[0014]
The software reuse support apparatus according to the present invention further includes a database storing accumulated software specifications, a creation history of the software specifications, and link information indicating a type of association between the software specifications, and a database stored in the database. Specification creating means for creating a new software specification using the software specification, a recognizing means for recognizing a current specification creation state by the specification creating means, and a specification creating means for performing specification creation performed by the specification creating means. History creation means for accumulating procedures in the database as creation history, and the type of association between the software specifications created by the specification creation means and the software specifications accumulated in the database as link information in the database Link information creating means, Reusable guide generation means for generating guide information for reusing the software specifications stored in the database based on the configuration history, the link information, and the specified type of association and its priority. Features.
[0015]
Preferably, one or more of the related types can be arbitrarily designated from the outside.
[0016]
Also, preferably, the type of association is a creation history indicating that there is a relationship in which one software specification can be used to create another software specification, and a modification of one software specification affects the other software specification. Modification effect indicating that there is a relationship, parent and child indicating that there is a higher / lower relationship between software specifications, association indicating that there is a relationship other than higher / lower between software specifications, terms common to both software specifications That you are in a relationship that is used Indicating terms And at least one of the following.
[0017]
Preferably, the reusable guide generation unit generates a reusable software specification candidate as the guide information when the specified association type includes a creation history.
[0018]
Preferably, when the specified association type includes a creation history, the reuse guide generation unit generates, as the guide information, a candidate for a reusable software specification and an editing procedure using the candidate. It is characterized by.
[0019]
Preferably, when a plurality of association types are specified, the reuse guide generation unit outputs guides generated corresponding to each of the association types in the order of the specified priority. I do.
[0020]
Preferably, the creation history includes information describing a software specification name and a creation order of the software specifications, and includes information describing a use relationship between other software specifications as necessary. And
[0021]
Preferably, the link information includes information describing two or more software specifications together with their software specification names and how to relate them.
[0022]
Preferably, the apparatus further comprises means for editing the creation history and link information stored in the database.
[0023]
[Action]
In the software specification reuse support device of the present invention, since the creation history of the software specifications and the related information between the software specifications are accumulated together with the software specifications in the database, the relationship in the specification database becomes clear. Then, since the specification database is searched based on the creation status of the new specification, the above-mentioned creation history, and the above-mentioned related information, it is effective for the user to list the next reusable specification candidate and to present the next creation procedure. Guide can be given.
[0024]
For this reason, according to the present invention, the productivity of specification creation is improved, and the relationship between specifications is indicated by a guide, so that the range of influence of the correction contents becomes clear, and the reliability of specification creation is improved. Play.
[0025]
In the software specification reuse support apparatus of the present embodiment, know-how such as past specification creation history and information on the relation between specification parts is accumulated, so that the relation in the specification database is clarified and the correction contents are corrected. The range of influence becomes clear. Then, in the specification creation process in software development, the user's specification creation status is recognized, and in consideration of the user's re-use purpose, the know-how such as the past specification creation history and information on the relationship between the specification parts is used. Generate guides for appropriate specification reuse, including information on candidate specifications and creation procedures that can be used, or information on the relevance between specifications, and present them to users, thereby reusing or changing specifications and specification parts. Can help with the decision. In addition, it is possible to support the work of accumulating know-how such as a preparation procedure for reusing specifications and related knowledge between specifications in a database, and freely adding and modifying.
[0026]
For this reason, according to the present invention, specifications can be effectively used, and productivity in software specification creation work and reliability of completed specifications can be improved.
[0027]
【Example】
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
[0028]
In this embodiment, the specifications include a business function hierarchical structure list, a screen transition diagram, a screen layout, a form layout, a file relation diagram, a relationship between a screen and a file, a performance requirement, a fault measure, and the like. Each type of specification is composed of a plurality of fragments. Further, the present invention can be applied to any data such as texts, images, figures, and the like, as long as they are sets of data having file names in addition to the above specifications.
[0029]
(First embodiment)
FIG. 1 is a configuration diagram of a software specification reuse support device according to a first embodiment of the present invention. As shown in FIG. 1, the software specification reuse support device of the present embodiment includes an input / output unit 1, a processing unit 2, and a database 3. In response to an instruction, data input, or the like from the input / output unit 1, the processing unit 2 proceeds with processing while accessing the database 3. Arrows in FIG. 1 indicate flows of data and control signals.
[0030]
The input / output unit 1 includes a keyboard as an input device, a CRT as an output device, etc., and can input and display software specifications. As an input device, a so-called mouse can be used or used together. As the output device, a printer can be used or used together.
[0031]
The processing unit 2 includes a user interface unit 10, a specification editor unit 11, a specification database search support unit 12, a user recognition unit 13, a search route narrowing unit 14, a history creation unit 15, and a route creation support unit 16. The processing unit 2 is configured using, for example, a CPU and a memory, and functions are provided by software processing.
[0032]
The database 3 includes a specification database 3a, a creation history database 3b, and a search route database 3c. Although details will be described later, the specification database 3a is a database for storing specifications created in the past, and the creation history database 3b is a database for storing a creation history that is a procedure of specifications created in the past. The search route database 3c is a database that stores search routes for searching the specification database 3a.
[0033]
The user interface unit 10 accesses the database 3 and displays the contents on the input / output unit 1. In addition, the specification editor unit 11, the specification database search support unit 12, the history creation unit 15, and the route creation support unit 16 start, end, and display the execution contents on the input / output unit 1.
[0034]
The specification editor unit 11 is for supporting the description of the specifications constituting the software. It is possible to read, edit, and save fragments of past specifications described in the specification database 3a.
[0035]
Here, the description of the specifications constituting the software is, for example, as shown in FIGS. 2, 3, and 4. FIG. 2 is an example of a description of a result obtained by dividing a business along a flow of time. FIG. 3 shows an example of a screen transition diagram description of the processing flow of the divided business, and FIG. 4 shows an example of the description of the correspondence between the screen and the file processing.
[0036]
FIG. 2 is an example of a task bird's-eye view in which a plurality of tasks having a temporal order relationship related to office work are described separately for each time slot, and the tasks in each time slot are hierarchically described. This is described using "gift system" as an example. For example, the time block of “daily processing” in the time block of “season work” is further divided into three blocks of “daily start processing”, “day work” and “daily end processing” in different time zones In addition, the time block of “intraday business” is divided into four blocks of “order entry”, “order correction”, “master maintenance”, and “online transmission”. It shows that it can be selected and defined as appropriate.
[0037]
FIG. 3 is an example of a screen transition diagram for defining a business flow, which is described using “gift system” as an example, as in FIG. This screen transition diagram has a screen state indicated by a circle and a transition indicated by an arrow. The name of the screen state is described near the circle representing the screen state, and the name of the "event" causing the screen transition and the name of the "action" caused by the event are described near the arrow representing the transition. . Using such a screen transition diagram, the user can define the screen transition of the application when performing “order entry” as follows. That is, first, when an event of inputting an "application number" occurs from a screen state of "initial list inquiry" which is an initial screen, a "search" operation using "application number" as an input attribute and "customer information" as an output attribute. If a "phone number" input event occurs, a "search" operation with "phone number" as an input attribute and "customer information" as an output attribute is performed, and then a screen state of "client input" Can be defined. In other screen states as well, screen transition is performed in the same manner, and it can be defined that the screen state finally changes to the screen state of “individual slip input”.
[0038]
FIG. 4 is an example of a method combination diagram that defines the relationship between the screen method and the file method, and is described using a “gift system” as an example as in FIG. This association has one screen method and a list of file methods, and describes one screen method in the left column and a list of file methods in the right column of the association diagram. The user uses the “search” method in which the “telephone number” on the “advance list introduction” screen has an input attribute and “customer information” (address, name, telephone number, etc.) as an output attribute. "Search" method with "Number" as input attribute and "Address" and "Name" as output attributes, and "Phone number" of "Preliminary Master" file as input attribute and "Address" and "Name" as output attributes It can be shown that it has two relations with the "search" method.
[0039]
When accessing the specification database 3 from the user interface unit 10 or reusing the specifications in the specification editor unit 11, the specification database search support unit 12 searches for the appropriate specification parts from the specification database 3a. The unit 13 is activated, and a route for searching the specification database 3 created by the search route narrowing unit 14 is presented to the input / output unit 1 via the user interface unit 10.
[0040]
The user recognizing unit 13 performs a process for recognizing a creation status such as a system name of a specification currently created by the user and a corresponding function name.
[0041]
The search path narrowing unit 14 reads the specification status of the user recognized by the user recognition unit 13, the generation history of the specifications created in the past, and the related information between the specifications created in the past, from the specification database 3 a. One or more specification part candidates to be referred to next are searched for, or an instruction indicating what specification should be created next is created.
[0042]
The history creating unit 15 accumulates data of the procedure for creating the specifications created by the user in the creation history database 3b. The creation history describes, for each application system, in the order of creation, if there is a reused specification component or a synthesized specification component.
[0043]
The following is an example of the creation history. The number indicates the order of creation.
1. Order entry option
2. Order entry base + order entry option → order entry
3. Order entry → Order modification
4. Order entry → Order inquiry
In the case of the above example, first create the specification parts of the "order entry option" and then create the "order entry" by reusing the result of combining the "order entry base" and the "order entry option" It indicates that. In addition, it is shown that the specification part of "order correction" was created by reusing "order entry" and then the specification part of "order inquiry" was reused by reusing "order entry". I have.
[0044]
The route creation support unit 16 supports description of effective information when searching the specification database, such as the relationship between existing specification parts or the relationship between created specifications, according to an instruction from the user. accumulate. The content described in the search path describes, for each application system, a higher-order / lower-order relationship between specification components and a relationship that there is a relationship between specification components.
[0045]
The following is an example of a search route.
-Parent link (A, order entry screen transition diagram, prior list inquiry screen)
・ Parent link (A, order entry screen transition diagram, client input screen)
-Related links (A, order entry time block diagram, order entry screen transition diagram)
・ Related link (A, prior list inquiry screen, prior list inquiry screen data / method diagram)
In each link, A indicates an A application.
In the above example, the "order entry screen transition diagram" has a higher relationship with the "priority list inquiry screen", the "order entry screen transition diagram" has a higher relationship with the "client input screen", and the "order It shows that there is a relationship between the "input time block diagram" and the "order entry screen transition diagram", and that it is related to the "prior list inquiry screen" and "prior list inquiry screen data / method diagram".
[0046]
Here, the specification database 3a is a database that stores specifications created in the past. The specification database can be classified and systematized according to the type of specification. FIG. 5 conceptually shows an example of the specification database 3a (that is, FIG. 5 shows an image of a relationship between specifications by a creator of the specification). For example, in the field of business processing, specifications should be divided for each application system, and further classified into specifications indicating business division along time, specifications indicating screen transitions, and specifications indicating the relationship between screens and files. Can be. In addition, for each classification, it can be classified into basic specification parts and optional specification parts.
[0047]
FIG. 6 shows an example of the structure of the specification database. <> In the figure indicates a directory. This specification database has a directory for each application. Each directory can have subdirectories (the subdirectories are nested with respect to the parent directory). The directory name can be freely determined by the user. The number of directories is also freely available. Each directory can have files and subdirectories. FIG. 7 shows an example of the internal structure of <specification class 1> which is a subdirectory of <A application system> in the specification database of FIG. This <specification category 1> indicates that the file has a file such as a gift system framework, a seasonal closing framework, and so on, and subdirectories of <basic> and <option>.
[0048]
FIG. 7 shows the relationship between the above files, and this information is described in the search path database 3c for each application. The specification database is assumed to be the same as a general file system, and has various semantic information between specifications. A framework in which these pieces of semantic information can be described is the search route database 3c, and related data can be additionally described later.
[0049]
8 and 9 show examples of the internal structure of <specification class 2> and <specification class 3>, which are subdirectories of <A application system> in the specification database of FIG. 6, respectively.
[0050]
The relationship between the basic specification parts, the optional specification parts, and the specifications included in the specification classifications Nos. 1 to 3 created using them is described in the creation history. Further, the upper / lower relations within the specification classification and the relation of parts relation between the specification classifications are described by a search route (parent link, child link, related link).
[0051]
FIGS. 10, 11, and 12 show examples of description of each specification class and examples of relationships between parts.
[0052]
The creation history database 3b is a database that stores a creation history that is a procedure of specifications created in the past. The creation history database 3b classifies the creation history data for each application.
[0053]
The search route database 3c is a database that stores search routes for searching the specification database created by the search route narrowing unit 14 and the route creation support unit 16. The search route database 3c classifies the search route data for each application. For example, the search route of the application system shown in FIG. 5 has a higher order / lower order relationship as shown in FIGS. 10, 11 and 12, and a specification route as shown in the description of the search route creation support unit 16. It shows the relationship between them. FIG. 10 shows that the specifications describing the “gift system” have the specifications of “work during the season”, “season closing work”, “season off work”, and “season start work”. Furthermore, it shows that the "work during the season" has the specifications of "order entry", "order modification", and "order inquiry". These relationships are described using parent links.
[0054]
FIG. 11 shows that there are specification parts of “order input”, “order correction”, and “order inquiry”. Further, “input of order” indicates that it has specifications of “preliminary list inquiry screen”, “client input screen”, and “delivery product input screen”. The “pre-list inquiry screen” indicates that it has the specification of “move pre-list inquiry field”. These relationships are described using parent links.
[0055]
FIG. 12 shows that there are specification parts of the “priority list inquiry screen”, the “priority master file”, and the “actual customer master file”. Further, the "priority list inquiry screen" has specifications of "customer data search" and "customer data display". The “advance master file” indicates that it has the specifications of “advance application customer data search” and “advance application customer data display”. The “actual customer master file” has the specifications of “actual customer data search” and “actual customer data display”. These relationships are described using parent links.
[0056]
On the other hand, the “customer data search” is a specification that describes the same “search” as the “advanced customer data search” and the “result customer data search”, and is described using a related link because it is related. Similarly, the “customer data display” describes the relationship between “advanced customer data search” and “result customer data search” using related links.
[0057]
Further, when there is a relationship between the specification of “order entry” in FIG. 10 and the specification of “order entry” in FIG. 11, the specification of “prior list inquiry screen” in FIG. If the specifications are related, describe them using the related links as follows.
[0058]
-Related links (A, (Category 1) Order entry, (Category 2) Order entry)
-Related links (A, (Category 2) prior list inquiry screen, (Category 3) prior list inquiry screen)
Next, the operation of the software specification reuse support device having such a configuration will be described. FIGS. 13, 14 (a), (b), and FIGS. 15 (a), (b), (c) show flowcharts of the operation of the software specification reuse support device of this embodiment.
[0059]
First, the user interface unit 1 is activated by the user's instruction from the input / output unit 1 (step P1).
[0060]
When the user interface unit 1 is started, any one of the specification editor unit 11, the specification database search support unit 12, the history creation unit 15, and the route creation support unit 16 is started or the database 3 is entered according to an instruction from the user. Access (steps S1 to S4).
[0061]
When the specification editor unit 11 is started (Step S10), a specification editing screen is started (Step S11). According to the user's instruction, the specification editor unit 11 creates specifications as shown in FIGS. 2, 3, and 4 (step S12). The specification parts to be reused are loaded from the specification database 3a (steps S13 to S14) and edited according to the user's instruction. When the creation by the specification editor unit 11 is completed according to the user's instruction (step S15), a history editing screen is activated to support the history creation (steps S16 to S17). When the creation of the history is completed according to the user's instruction, the route edit screen is activated to support the route creation (steps S17 to S18). Upon completion of the route creation according to the user's instruction, the process returns to the activation state of the user interface unit (step S19).
[0062]
When the specification database search support unit 12 is activated (step S20), the user recognition unit 13 is activated to recognize the specification creation status of the user (step S21 (process a)). Subsequently, the search route narrowing unit 14 is activated (Step S22). When the search route data is passed by the search route creating unit 14 (steps S23 (process b), S24), the information is presented to the user through the user interface 10, and the process returns to the activated state of the user interface (step S25 (process e)). )).
[0063]
In step S21, when the user recognition unit 13 is activated, the current specification creation status of the user is recognized, and the data is passed to the search route narrowing unit 14. The operation (process a) for recognizing the current specification creation status of the user is shown in the flowchart of FIG. The latest creation history is recognized from the database (step S210). A specification name is presented for the newest specification (step S211). If there is a confirmation input, the process ends (step S212). If not, it waits for the input of another specification name (step S213) and waits for the confirmation input again.
[0064]
In step S23, when the user's specification creation information is passed to the search route narrowing unit 14, the corresponding information is searched from the creation history database 3b and the search route database 3c in the following procedure, and a database suitable for this user is obtained. A search route is generated, and the data is passed to the specification database search support unit 12. The operation of generating the search route (process b) is shown in the flowchart of FIG. A list a of the specifications (parts) created according to the specification creation status of the user is created (step S230). A list b of specifications (parts) that have already been created is created from the creation history of the referenced specification (step S231). The elements of the list a are removed from the list b, and a list α of unprepared specifications (parts) is created (step S232). A list β of the history in which the elements of the list α are created is extracted from the creation history of the referenced specification (step S233). A course γ having the same specification name as the specification being created is extracted from the search path database 3c (step S234). The list α, the list β, and the course γ are passed to the next step as search route data (step S235).
[0065]
Here, it is assumed that the creation status of the user has just completed the creation of (category 2) “order entry”. It is assumed that the creation history referred to has the following contents.
[0066]
1. (Category 2) Order entry option
2. (Category 2) Order entry base + (Category 2) Order entry option → (Category 2)
Order entry
3. (Category 2) Order entry → (Category 2) Order correction
4. (Category 2) Order entry → (Category 2) Order inquiry
The contents of the specification database to be referred to are shown in FIGS. It is also assumed that the search route is the content of the above-described parent link and related link.
[0067]
Then, in the flowchart in FIG.
-Α: [(Category 2) Order correction, (Category 2) Order inquiry]
.Beta .: [[(Category 2) Order Entry], [(Category 2) Order Entry Correction]], [[(Category 2) Order Entry], [(Category 2) Order Ref]]]
・ Γ:
Parent link ((Category 2) Order input, (Category 2) Advance list inquiry screen)
Parent link ((Category 2) Order input, (Category 2) Requester input screen)
Parent link ((Category 2) Order input, (Category 2) Delivery product input screen)
Related links ((Category 1) Order entry, (Category 2) Order entry)
It is.
[0068]
Therefore, the information presented to the user in the specification database search support unit 12 includes <from creation history>.
・ “(Category 2) Order input can be reused to create (Category 2) order correction.
"・ ((Category 2) Order input can be reused to create (Category 2) order inquiry.) <From search route>
・ "(Category 2) Order input has (Category 2) prior list inquiry screen as an element."
-"(Category 2) Order entry has (Category 2) Requester input screen as an element."
・ "(Category 2) Order entry has (Category 2) delivery product input screen as an element."
・ "(Category 1) Order entry and (Category 2) order entry are related."
And so on.
[0069]
When the history creation unit 15 is activated (step S30 (process c-1)), the history creation is supported, and the specification creation procedure of the user is stored in the creation history database 3b in accordance with the user's instruction (step S31 (step S31)). Process c-2)). When the editing is completed by the user's instruction, the process returns to the activation state of the user interface unit (step S32).
[0070]
When the route creation support unit 16 is activated (step S40 (process d-1)), the route creation support unit 16 performs route creation support and, based on a user's instruction, determines the relationship between specifications and know-how in the range of specifications to be referred to in the search route database 3c. (Step S41 (process d-2)). When the editing is completed according to the user's instruction, the process returns to the activation state of the user interface unit (step S42).
[0071]
When access to the specification database 3 is selected by the user (steps S4 and S50), support such as reference to the specification DB, loading, modification, and creation of a new file is performed (steps S51 and S52). When the access is terminated by the user's instruction, the state returns to the activated state of the user interface unit (step S53).
[0072]
The user interface unit is terminated by the user's instruction from the input / output unit 1 (steps S4, S50, S54).
[0073]
Now, in step S20, the specification database search support unit 12 is activated, and when the search route data is obtained as described above, the information is presented to the user through the user interface 10 in step S25, and Dialogue takes place. The presentation of the search route data to the user (process e) is shown in the flowchart of FIG.
[0074]
First, as a search route menu,
(1) (Reference system) history
(2) Candidate for specification parts (currently available)
(3) Related specification parts
4) Top specification parts
Is presented (step S250).
[0075]
When the history (1) is selected, it is presented (step S2511).
[0076]
If a candidate for specification parts ((2)) is selected, this is presented (step S2521).
[0077]
When the related specification part (3) is selected, the specification name linked by the related link is extracted from the course γ (step S2530). The related specification name is presented (step S2531). If it is desired to extend the link search and a specification is input, a course is extracted (step S2533), and the same processing is performed from step S2530.
[0078]
When the upper specification part (4) is selected, the specification name connected by the parent link is extracted from the course γ (step S2540). The upper specification name is presented (step S2541). If it is desired to extend the link search and a specification is input, a course is extracted (step S2543), and the same processing is performed from step S2530.
[0079]
As described above, according to the software specification reuse support device of the present embodiment, since the creation history of the software specifications and the related information between the software specifications are stored together with the software specifications in the database, Becomes clear, and the next generation procedure can be guided by selecting the next reusable specification candidate, thereby improving the productivity of specification generation. Further, since the relationship between the specifications is indicated by the guide, the range of influence of the correction contents becomes clear, and the reliability of the specification creation is improved.
[0080]
(Second embodiment)
Next, a second embodiment of the present invention will be described.
[0081]
This embodiment is a general extension of the first embodiment. That is, in the present embodiment, first, the description of the search route database in the first embodiment is extended so that a link attribute, which is information indicating what relationship exists between specifications, can be arbitrarily set. In addition, those having the same link attribute and relating to each other can be described as a relationship between a plurality of specifications. In the present embodiment, this is called a link database.
[0082]
Further, in this embodiment, the function of presenting information to the user by the specification database search support unit in the first embodiment is further extended so that the user can freely specify the type of the link attribute together with the priority. , Guide information for supporting the reuse of existing specifications is generated. In this embodiment, it is called a specification database reuse support unit.
[0083]
Further, in the present embodiment, a working memory having three slots for storing the specification creation status as needed is provided. Can be generated and registered. In this embodiment, it is called a creation history generation unit.
[0084]
In the present embodiment, the specification includes the same concept as in the first embodiment, but since the way of expressing the relationship between the specifications is extended by the link database, the structure of the specification that can be handled accordingly. Can also be extended.
[0085]
FIG. 19 is a configuration diagram of the software specification reuse support device according to the present embodiment. As shown in the figure, the software specification reuse support apparatus of the present embodiment includes an input / output unit 101, a processing unit 102, and a database 103. In response to an instruction or data input from the input / output unit 101, the processing unit 102 proceeds with processing while accessing the database 103. Arrows in FIG. 19 indicate flows of data and control signals.
[0086]
The input / output unit 101 includes a keyboard as an input device, a CRT as an output device, and the like, and can input and display software specifications. As an input device, a so-called mouse can be used or used together. As the output device, a printer can be used or used together.
[0087]
The processing unit 102 includes a user interface unit 110, a working memory unit 120, a specification editor unit 130, a specification database reuse support unit 140, and a reuse know-how acquisition unit 150. The processing unit 102 is configured using, for example, a CPU and a memory, and the function is provided by software processing.
[0088]
The database 103 includes a specification database 160 and a reuse know-how database 170.
[0089]
The reuse know-how database 170 includes a creation history database 171 and an inter-specification relationship knowledge database 172. Further, the specification-specific relationship knowledge database 172 includes a link database 173 and a link attribute database 174. Although the details will be described later, the specification database 160 is a database for storing specifications created in the past, and the creation history database 171 is a database for storing a creation history that is a procedure of specifications created in the past. . The link database 173 is a database describing the relationship between the specifications of the specification parts, and the link attribute database 174 is a database describing the types of attributes in the association between the specifications described in the link database 173.
[0090]
The user interface unit 110 accesses the specification database 160 and displays the contents on the input / output unit 101. In addition, activation, termination, and execution contents of the specification editor unit 130, the specification database reuse support unit 140, and the reuse know-how acquisition unit 150 are displayed on the input / output unit 101.
[0091]
The specification editor unit 130 calls an editor such as a text editor or a graphic creation editor necessary for creating the specification, and supports the description of the specification constituting the software. Further, it is possible to read / edit / save files stored in the specification database 160.
[0092]
The working memory unit 120 records operations such as reading, combining, and saving of a specification file performed by the user through the specification editor unit 130. The working memory unit 120 includes a WM1 slot that describes an application name indicating the entire system being created, a WM2 slot that describes a list of specification names created so far among the applications described in the WM1 slot, and a specification. It consists of WM3 slots for temporarily storing the creation process.
[0093]
The specification database reuse support unit 140 includes a user recognition unit 141, a reuse know-how type selection unit 142, a reuse guide generation unit 143, and a reuse guide presentation unit 144, and selects a specification to be reused for the user. Generate and present a guide for doing so.
[0094]
The user recognizing unit 141 recognizes the creation status such as the system name of the specification currently created by the user and the corresponding function name.
[0095]
The reuse know-how type selection unit 142 presents the type of reuse know-how described in the link attribute database 174 to the user, assists in inputting the types of know-how for the purpose of reuse and their priorities, and performs input. The generated data is transferred to the reuse guide generation unit 143.
[0096]
The reuse guide generation unit 143 describes the user creation status obtained by the user recognition unit 141, the types of know-how passed from the reuse know-how type selection unit 142, and their priorities, in the reuse know-how database 170. From the know-how such as the created creation history and the related knowledge between the specifications, select appropriate know-how, give one or more specification parts candidates to be reused by the user, or what specifications should be created next Create a guide consisting of presentations.
[0097]
The reuse guide presentation unit 144 presents or outputs the guide created by the reuse guide generation unit 143 to the user through the user interface.
[0098]
The reuse know-how acquisition unit 150 includes a creation history generation unit 151, a know-how type selection unit 152, and a know-how data creation unit 153, and assists a user in registering know-how obtained by performing reuse.
[0099]
The creation history generation unit 151 accumulates the work process up to that point in the creation history database 171 every time the content is "saved" in the WM3 slot of the working memory unit 120.
[0100]
For example,
Read A file
B file synthesis
Save to C file
So, the history when described in the working memory,
A file + B file → C file
It becomes. When the accumulation of the history is completed once, the contents of the WM3 in the working memory are reset.
[0101]
When the user wants to accumulate or modify the reuse know-how, the know-how type selection unit 152 presents the type of the know-how described in the link attribute database 174 according to the user's instruction, and displays the type name or the type of the selected know-how. The type name of the new know-how is passed to the know-how data creation unit 153.
[0102]
The know-how data creation unit 153 presents the type name of the know-how or the type name of the new know-how sent from the know-how type selection unit 152 to the user. Next, the know-how information input by the user is added, edited, and deleted to the link database 173.
[0103]
The specification database 160 is a database that stores specifications created in the past. The specification database 160 can be classified and systematized according to the type of specification.
[0104]
The reuse know-how database 170 includes a creation history database 171 and an inter-specification relationship knowledge database 172.
[0105]
The creation history database 171 is a database that stores a creation history, which is a procedure for creating specifications created in the past. The following is an example of the creation history. The number indicates the order of creation.
[0106]
1. → Order input option (A system, screen transition diagram)
2. Basic order entry (A system, screen transition diagram)
+ Order input option (A system, screen transition diagram)
→ Order input actual work (A system, screen transition diagram)
3. Order input actual work (A system, screen transition diagram)
→ Accepted order correction work (A system, screen transition diagram)
4. Order input actual work (A system, screen transition diagram)
→ Order inquiry actual work (A system, screen transition diagram)
This example shows a procedure for creating specifications of a “gift system” of a department store A. The "gift system" has a task of "order entry" for writing the contents of an order to a file, even if the department store is different. The “order entry option (A system, screen transition diagram)” indicates a different auxiliary part for each department store in the screen transition diagram of the order entry business of the department store A.
[0107]
“Order entry basics (A system, screen transition diagram)” indicates a screen transition diagram of a common business in the order entry even if the department store is different.
[0108]
The “order input actual operation (A system, screen transition diagram)” represents the entire screen transition diagram of the order entry operation of a department store A.
[0109]
Similarly, the “order modification actual business (A system, screen transition diagram)” and the “order inquiry actual business (A system, screen transition diagram)” are screen transitions of the order modification business and order introduction business of a department store A, respectively. It represents the whole figure.
[0110]
The above creation history indicates the following. First, a screen transition diagram of “order entry option (A system, screen transition diagram)” is created. Next, the result of synthesizing the "order entry basic (A system, screen transition diagram)" and the "order entry option (A system, screen transition diagram)" is reused, and the "order entry actual work (A system, screen transition diagram) Transition diagram) "has been created. Next, a screen transition diagram of the "order correction actual business (A system, screen transition diagram)" is created by reusing the "order entry actual business (A system, screen transition diagram)". This shows that a screen transition diagram of “order inquiry actual job (A system, screen transition diagram)” is created by reusing “order entry actual job (A system, screen transition diagram)”.
[0111]
Here, a screen transition diagram is given as an example of the specification, but the specification may be any data that can be identified, such as a file name, as described above.
[0112]
The specification-specification knowledge database 172 includes a link database 173 and a link attribute database 174.
[0113]
The link database 173 describes the relationship between the specifications of the specification parts. The format of the link database 173 is as follows.
[[Spec 1, spec 2, spec 3, ...], [spec a, spec b, spec c, ...], [attribute α, attribute β, attribute γ, ...]]
This indicates that the specifications 1, the specifications 2, the specifications 3,... Have a relationship of the specifications a, the specifications b, the specifications c,.
[0114]
Hereinafter, a description example of the link database 173 will be described.
a) [[Order receiving actual work (A system, screen transition diagram)], [Advance list inquiry screen (A system, screen layout), client input screen (A system, screen layout)], [parent and child]]
b) [[Order input actual work (A system, screen transition diagram)], [Advance list form (A system, screen layout), order list form (A system, screen layout)], [Related]]
c) [[Order entry business division diagram (A system, business division diagram)], [Order entry actual business (A system, screen transition diagram)], [Modification effect, term (order entry)]]
The example a above shows that the screen transition diagram of the “order entry actual work” of the A system has a parent-child relationship with the screen layout of the “prior list inquiry screen” and the “client input screen” of the A system. I have.
[0115]
The example of the above b shows that the screen transition diagram of “Actual input business” of the A system is related to the screen layouts of “Advance list form” and “Order list form” of the A system. Here, “relation” indicates that there is no special attribute, but only that there is a relationship.
[0116]
In the example of the above c, the business division diagram called “order entry business division diagram” is different from the screen transition diagram of “order entry actual business” in the A system, and if any of them is modified, the change is affected. Indicates that they are common.
[0117]
The link attribute database 174 describes the types of attributes in association between specifications described in the link database 173.
[0118]
The following shows examples of the types of attributes.
-Creation history
-Modification effects
-Related
-Terms
-Parent and child
Regarding the above-mentioned “relation”, an attribute may be provided in which the degree of the relation is subdivided, such as “relation (large)”, “relation (medium)”, “relation (small)”. In addition to the above, various types of attributes can be arbitrarily specified.
[0119]
Next, the operation of the software specification reuse support device having such a configuration will be described. 20 to 23 show flowcharts of the operation of the software specification reuse support device of the present embodiment.
[0120]
First, the user interface unit 110 is activated by the user's instruction from the input / output unit 101 (step P101).
[0121]
When the user interface unit 110 is activated, one of the specification editor unit 130, the specification database reuse support unit 140, and the reuse know-how acquisition unit 150 is activated by an instruction from the user (steps S101 to S103).
[0122]
When the specification editor unit 130 is activated (step S110), the working memory unit 120 is activated (step S111), and the user inputs the name (application name) of the entire system for creating the specification and describes it in the WM1 slot (step S112). ). Then, the specification editing screen is activated (step S113). According to the user's instruction, the specification editor unit 130 creates a desired specification (step S114). In addition, a file of a specification component to be reused is loaded from the specification database 160, edited / combined according to a user's instruction, and saved (steps S115, S116, S118). The name list of the created specification file is described in the WM2 slot of the working memory unit 120 (step S119), and in the WM3 slot, of the work contents executed by the specification editor unit 130, loading, combining, and saving of a file are performed. It is recorded (step S117).
[0123]
Now, when "save file" is described in the working memory unit 120 (step S119), the creation history generation unit 151 of the reuse know-how acquisition unit 150 is activated (step S120), and the work process in the working memory is started. The creation history is described in the creation history database 171 (step S121 (process s)). After the description is completed, when returning to the specification creation state, the process proceeds to step S114, and when ending the specification editor unit 130, the process returns to step P101 (step S122).
[0124]
Here, an example of the operation (processing s) from generation of the creation history to registration in step S121 is shown in the flowchart of FIG. First, WM3 (work process) in the working memory is read (step S500). The line is read line by line from the first line (step S501), and if "file read" is described (step S502), it is converted to "file" (step S505) and described as "composite file". If it is included (step S503), it is converted to "+ OO file" (step S506), and if it is described as "save OO file" (step S504), it is converted to "→ OO file" (step S504). S507). However, the above OO represents a file name. If the WM3 is not a blank line, the processing after step S501 is repeated (step S508). If the WM3 is a blank line (step S508), the conversion result is described in the creation history database 171 (step S509).
[0125]
On the other hand, when the specification database reuse support unit 140 is activated (step S130), the user recognition unit 141 is activated (step S131), and the user's specification creation status is recognized (step S132 (process t)). This is passed to the reuse guide generation unit 143.
[0126]
Subsequently, the reuse know-how type selection unit 142 is activated (step S133), and the user is caused to determine the type of know-how to be reused and the priority of the know-how, and passes the result to the reuse guide generation unit 143. Note that the type of know-how to be reused and the priority of know-how may be set in advance, so that this step may be omitted.
[0127]
The creation status of the user, the type and priority of the know-how to be reused are passed to the reuse guide generation unit 143, and when the user is started (step S134), the creation history database 171 and the link database 173 of the reuse know-how database 170 are activated. Then, guide information for database reuse suitable for the user is generated (step S135 (processing u)), and the data is passed to the reuse guide presentation unit 144.
[0128]
Next, the generated guide is presented to the user through the user interface unit 110 by the reuse guide presenting unit 144 (step S136), and the state returns to the activated state of the user interface (step P101).
[0129]
Here, an example of the operation (process t) of recognizing the current specification creation status of the user in step S132 is shown in the flowchart of FIG. First, the WM3 (work process) in the working memory is read (step S301). The line is read line by line from the first line (step S302), and when "read OO file" is described (step S303), "OO file" is presented to the user as the name of the specification currently being created (step S304). ). If there is a confirmation input (step S305), the process ends. If not (step S305), the process waits for the input of another specification name (step S306), and waits for the confirmation input again (step S305).
[0130]
Next, an example of the guide generation operation (process u) in step S135 is shown in the flowcharts of FIGS. First, WM2 (a list of specifications that have already been created) in the working memory is read (step S400). The specification name (of the specification being created) obtained in the above process t is recognized (step S401). The creation history database 171 is read (step S402).
[0131]
Then, the history is read one by one (step S403). If at least one element on the left side is an element of WM2 and all the elements on the right side are not included in WM2 (steps S404 and S405), The corresponding expression is temporarily added to the file α (step S406). The processing of steps S403 to S406 is repeated until reading of the history is completed (step S407).
[0132]
Next, the history of the file α is read one by one (step S408). If there is an element on the left side that is not included in the WM2, this is set as an element e (step S409), and the creation history database 171 is read one by one. A search is performed (step S410), and if the above element e is on the right side (step S411), the corresponding expression is temporarily added to the file β (step S412). The processing from step S408 to step S412 is repeated until the history search is completed (step S413). Thereafter, the file α and the file β are sorted and sorted in the order described, and this is set as a file γ (step S414).
[0133]
Next, the specification name of the specification currently being created obtained in the above-described processing t is recognized, and this is substituted for “SPEC” (step S415). The link database 173 is read (step S416). The know-how of the link database 173 is read one by one (step S417), and when the same name as the specification name indicated by “SPEC” appears in the know-how (step S418), the formula of the relevant know-how is temporarily stored in the file θ. Then, the type and order of the attributes of the know-how specified by the user are read (step S420), and the know-how of the file θ is read one by one (step S421). The processes of steps S417 to S421 are repeated while the know-how of the attribute designated by the user is provided (step S422), and thereafter, the formula of the relevant know-how is added to the file λ (step S423).
[0134]
Next, the attributes are read one by one from the know-how attributes designated by the user (arranged in order of priority) (step S424). If the attribute is "creation history" (step S425), the file γ is added to the file μ. (Step S426).
[0135]
When the reading of the attributes is completed (step S427), the contents of the file μ are used as a guide (step S433), and the temporarily created files α, β, γ, θ, λ, μ are deleted, and then the processing ends (step S427). S434).
[0136]
If the reading of the attribute is not completed (step S427), the know-how of the corresponding attribute is read from the first file λ (step S428). If the file λ becomes empty, the contents of the file μ are used as a guide ( (Step S433), and deletes the temporarily created files α, β, γ, θ, λ, and μ, and ends (Step S434). On the other hand, if it is not empty (step S429), it is added to the file μ (step S430), the know-how currently read from the file λ is deleted (step S431), and the check has not been completed up to the last line of the file λ. In this case (step S432), the process returns to step 428. If the check is completed up to the last line of the file λ (step S432), the process returns to step 424.
[0137]
When the reuse know-how acquisition unit 150 is started (step S140), the know-how type selection unit 152 is started (step S141), the content described in the link attribute database 174 is read, and presented through the user interface. You. According to the user's instruction, the type of know-how is selected or the type of new know-how is registered (step S142). The type of the new know-how is described in the link attribute database.
[0138]
When the user specifies the type of know-how or the name of the type of new know-how by the know-how type selection unit 152, the know-how data creation unit 153 is activated (step S143).
[0139]
Next, using an editor, the user describes know-how of the type of the designated know-how (step S144), and describes the know-how in the creation history database 171 or the link database 173 (step S145). Alternatively, the know-how described in the past is called from the creation history database 171 or the link database 173, and edited / deleted by an editor (steps S144 and S145).
[0140]
When the editing is completed by the user's instruction (step S146), the process returns to the activated state of the user interface unit 110 (step P101).
[0141]
Note that the user interface unit 110 ends in response to a user instruction from the input / output unit 101 (step S104).
[0142]
Next, a specific example of the process of generating the above guide will be described.
[0143]
Here, it is assumed that the creation status of the user has just completed creation of an order entry actual job, which is a screen transition diagram of a certain B system. It is also assumed that a screen transition diagram of the order entry option and the order entry basic has already been created for the system B. It is assumed that the specifications and reuse know-how of the system A that has already been created are to be reused. The creation history, link database, and link attribute database, which are the reuse know-how of the system A, have the following contents, respectively.
[0144]
<Example of creation history>
1. → Order input option (A system, screen transition diagram)
2. Basic order entry (A system, screen transition diagram)
+ Order input option (A system, screen transition diagram)
→ Order input actual work (A system, screen transition diagram)
3. Order input actual work (A system, screen transition diagram)
→ Accepted order correction work (A system, screen transition diagram)
4. Order input actual work (A system, screen transition diagram)
→ Order inquiry actual work (A system, screen transition diagram)
5. → Result input option (A system, screen transition diagram)
6. Order input actual work (A system, screen transition diagram)
+ Result input option (A system, screen transition diagram)
→ Actual input actual work (A system, screen transition diagram)
<Example of link database>
a) [[Order receiving actual work (A system, screen transition diagram)], [Advance list inquiry screen (A system, screen layout), client input screen (A system, screen layout)], [parent and child]]
b) [[Order input actual work (A system, screen transition diagram)], [Advance list form (A system, screen layout), order list form (A system, screen layout)], [Related]]
c) [[Order entry business division diagram (A system, business division diagram)], [Order entry actual business (A system, screen transition diagram)], [Modification effect, term (order entry)]]
<Example of link attribute database>
Creation history
Modification impact
Relation
the term
Parent and child
Now, it is assumed that the user has set the type of know-how and the priority in the know-how type selection as follows.
[0145]
<Setting example 1>
Priority 1: Creation history
Priority 2: Modification impact
Priority 3: Related
Priority 4: Terminology
Priority 5: Parent and child
<Setting example 2>
Priority 1: Related
Priority 2: Terminology
Priority 3: Modification impact
Priority 4: Creation history
Here, the procedure shown in the flowcharts of FIGS. 25 to 28 is executed, and the following steps i, ii, and iii are executed.
[0146]
i) WM2 = Recognition of list of specifications already created
ii) Recognition of the specification name that is currently being created or immediately after creation from the contents of WM3
iii) In the creation history,
One that includes at least one element on the left side in WM2 and does not include the element on the right side in WM2 (that is, an expression showing a procedure for creating an uncreated specification using an already created specification)
and
Elements on the left side of the above equation that are not included in WM2 but are included on the right side (that is, an equation showing a procedure for creating an element for achieving composition in the above equation)
And sort them in the order described.
[0147]
As a result, the creation history extracted and sorted is as follows.
<Creation history>
1. Order input actual work (A system, screen transition diagram)
→ Accepted order correction work (A system, screen transition diagram)
2. Order input actual work (A system, screen transition diagram)
→ Order inquiry actual work (A system, screen transition diagram)
3. → Result input option (A system, screen transition diagram)
4. Order input actual work (A system, screen transition diagram)
+ Result input option (A system, screen transition diagram)
→ Actual input actual work (A system, screen transition diagram)
Therefore, as the guide generated by the reuse guide generating unit 143, for example, the following is generated and output.
[0148]
<Guide corresponding to setting example 1>
1. The order input actual business, which is the screen transition diagram of the A system, is reused to create the order correction actual business, which is the screen transition diagram of the A system.
2. An order input actual operation, which is a screen transition diagram of the A system, is created by reusing the actual order input operation, which is a screen transition diagram of the A system.
3. An order input option, which is a screen transition diagram of the system A, is created.
4. An order input actual business, which is a screen transition diagram of the A system, and an actual input actual business, which is a screen transition diagram of the A system, are created.
5. There is a relationship with the order entry business division diagram, which is the business division diagram of system A, and the effect of correction.
6. It is related to the advance list form, which is the form layout of the A system, and the same order list form (A system, form layout).
7. It is related to the order entry business division diagram, which is the business division diagram of the A system, by the term "order entry".
8. There is a parent-child relationship with the advance list inquiry screen, which is the form layout of the A system, and the client input screen.
[0149]
Messages 1 to 4 in this guide correspond to the designation of the creation history, message 5 corresponds to the modification effect, message 6 corresponds to the association, message 7 corresponds to the term, and message 7 corresponds to the parent and child.
[0150]
Further, in the above example, each message corresponding to each type of the specified attribute is output in the order of the set priority.
[0151]
<Guide corresponding to setting example 2>
1. It is related to the advance list form, which is the form layout of the A system, and the same order list form (A system, form layout).
2. It is related to the order entry business division diagram, which is the business division diagram of the A system, by the term "order entry".
3. There is a relationship with the order entry business division diagram, which is the business division diagram of system A, and the effect of correction.
4. The order input actual business, which is the screen transition diagram of the A system, is reused to create the order correction actual business, which is the screen transition diagram of the A system.
5. An order input actual operation, which is a screen transition diagram of the A system, is created by reusing the actual order input operation, which is a screen transition diagram of the A system.
6. An order input option, which is a screen transition diagram of the system A, is created.
7. An order input actual business, which is a screen transition diagram of the A system, and an actual input actual business, which is a screen transition diagram of the A system, are created.
[0152]
Message 1 in this guide corresponds to the designation of the association, message 2 corresponds to the term, message 3 corresponds to the modification effect, and messages 4 to 7 correspond to the creation history. Here, since there is no designation of the parent and child, a message corresponding to the message 8 in the guide corresponding to the setting example 1 is not output.
[0153]
Note that only candidates to be reused may be presented as guides corresponding to the specification of the creation history.
[0154]
Alternatively, as a guide corresponding to the specification of the creation history, a plurality of candidates to be reused may be presented, a user's candidate designation input may be waited, and a method of using only the designated candidate may be presented.
[0155]
In addition, various guide generation / presentation methods can be implemented.
[0156]
As described above, according to the software specification reuse support apparatus of the present embodiment, know-how such as past specification creation history and information on the relation between specification parts is accumulated, so that the relation in the specification database is clear. , And the scope of the amendment will become clear. Then, in the specification creation process in software development, the user's specification creation status is recognized, and in consideration of the user's re-use purpose, the know-how such as the past specification creation history and information on the relationship between the specification parts is used. Generates an appropriate specification reuse guide, such as information on candidate specifications and creation procedures that can be used, and information on the relevance between specifications, and presents it to the user. Can help with decisions. In addition, it is possible to support the work of accumulating know-how such as a preparation procedure for reusing specifications and related knowledge between specifications in a database, and freely adding and modifying.
[0157]
Therefore, the specifications can be effectively utilized, and the productivity in the software specification creation work and the reliability of the completed specifications can be improved. (Modification)
By the way, in the first embodiment, the description has been made on the assumption that the history creating unit is in the manual mode. However, the history creating unit may be in the automatic mode as in the second embodiment. Further, the automatic mode and the manual mode may be switched for use.
[0158]
In the second embodiment, the creation history generation unit has been described on the premise of the automatic mode, but may be in the manual mode as in the first embodiment. Further, the automatic mode and the manual mode may be switched for use.
[0159]
Further, the present invention is not limited to the above-described embodiments, and can be variously modified and implemented without departing from the gist thereof.
[0160]
【The invention's effect】
According to the present invention, a mechanism is provided for accumulating information indicating the creation history of already created specifications and the relationship between specification parts, and based on such information, the specification can be reused in accordance with the user's specification creation status or the purpose of reuse. Since the support can be provided, the specifications can be effectively used in the specification creation process in software development, and the productivity and the reliability of the completed specifications can be improved.
[0161]
Further, according to the present invention, it is possible to accumulate a specification creation history and information on the relationship between specification parts in a database, and to support an operation of freely adding and modifying the specification. In this case, the specifications can be further effectively utilized, and the productivity and the reliability of the completed specifications can be further improved.
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating a configuration of a software specification reuse support device according to a first embodiment of the present invention.
FIG. 2 is a diagram showing an example of description of a specification that can be described by a specification editor unit of FIG. 1;
FIG. 3 is a diagram showing another example of description of a specification that can be described by the specification editor unit of FIG. 1;
FIG. 4 is a diagram showing still another example of description of a specification that can be described by the specification editor unit of FIG. 1;
FIG. 5 is a conceptual diagram showing an example of a configuration in a specification database.
FIG. 6 is a diagram showing an example of the structure of a specification database.
FIG. 7 is a diagram showing the internal structure of the specification database of FIG. 6;
8 is a diagram showing the internal structure of the specification database of FIG.
9 is a diagram showing the internal structure of the specification database in FIG.
FIG. 10 is a diagram showing an example of a classification of specifications constituting a specification database.
FIG. 11 is a diagram showing an example of a classification of specifications constituting a specification database.
FIG. 12 is a diagram showing an example of a classification of specifications constituting a specification database.
FIG. 13 is a flowchart showing the operation of the software specification reuse support apparatus of the embodiment.
FIG. 14 is a flowchart showing the operation of the software specification reuse support device of the embodiment.
FIG. 15 is a flowchart showing the operation of the software specification reuse support device of the embodiment.
FIG. 16 is a flowchart showing a procedure for recognizing a user's specification creation status;
FIG. 17 is a flowchart showing a procedure for generating search route data;
FIG. 18 is a flowchart showing a procedure of a dialog between the user and the system after presenting the search route information to the user;
FIG. 19 is a block diagram showing a configuration of a software specification reuse support device according to a second embodiment of the present invention.
FIG. 20 is a flowchart showing the operation of the software specification reuse support apparatus of the embodiment.
FIG. 21 is a flowchart showing the operation of the software specification reuse support device of the embodiment.
FIG. 22 is a flowchart showing the operation of the software specification reuse support device of the embodiment.
FIG. 23 is a flowchart showing the operation of the software specification reuse support device of the embodiment.
FIG. 24 is a flowchart showing a procedure for generating and registering a creation history.
FIG. 25 is a flowchart showing a procedure for recognizing a user's specification creation status;
FIG. 26 is a flowchart showing a procedure for generating a reuse guide.
FIG. 27 is a flowchart showing a procedure for generating a reuse guide.
FIG. 28 is a flowchart showing a procedure for generating a reuse guide.
FIG. 29 is a flowchart showing a procedure for generating a reuse guide.
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 1 ... Input / output part, 2 ... Processing part, 10 ... User interface part, 11 ... Specification editor part, 12 ... Specification database search support part, 13 ... User recognition part, 14 ... Search route narrowing part, 15 ... History creation part , 16: route creation support unit, 3: database, 3a: specification database, 3b: creation history database, 3c: search route database, 101: input / output unit, 102: processing unit, 103: database, 110: user interface unit, 120: Working memory unit, 130: Specification editor unit, 140: Specification database reuse support unit, 150: Reuse know-how acquisition unit, 141: User recognition unit, 142: Reuse know-how type selection unit, 143: Reuse guide generation Section, 144: reuse guide presentation section, 151: creation history generation section, 152: know-how type selection , 153 ... know-how data generation unit, 160 ... specification database, 170 ... re-use know-how database, 171 ... create history database, 172 ... Specifications relations between knowledge database, 173 ... link database, 174 ... link attribute database

Claims (3)

上位・下位関係を有する複数の仕様部品データを含む過去に作成した第１のソフトウェア仕様データを利用して新たな第２のソフトウェア仕様データの作成を支援するソフトウェア仕様再利用支援装置であって、
前記第１のソフトウェア仕様データについて、少なくとも、前記複数の仕様部品データ間の上位・下位関係を表す第１の情報を記憶する第１の記憶手段と、
一方の仕様部品データを利用して他方の仕様部品データを作成できる関係にある仕様部品データ間の利用関係を表す第２の情報と、前記複数の仕様部品データの作成順序とを含む前記第１のソフトウェア仕様データの作成履歴を記憶する第２の記憶手段と、
前記複数の仕様部品データのうちの第１の仕様部品データの仕様部品名をもつ前記第２のソフトウェア仕様データの第２の仕様部品データを作成する仕様作成手段と、
前記作成順序が前記第１の仕様部品データよりも後の仕様部品データの仕様部品名のリストを作成する手段と、
前記第２の情報を基に、前記リスト上の各仕様部品データを作成する際に利用された仕様部品データの仕様部品名を求める第１の探索手段と、
前記第１の情報を基に、前記第１の仕様部品データの下位にある仕様部品データの仕様部品名を求める第２の探索手段と、
前記第１の探索手段で求めた仕様部品名であって、前記第２の仕様部品データ作成後に作成する仕様部品データを作成する際に再利用可能な仕様部品データの仕様部品名を含む第１のガイド情報と、前記第２の探索手段で求めた仕様部品名であって、前記第２の仕様部品データ作成後に作成すべき仕様部品データの仕様部品名を含む第２のガイド情報のうちの少なくとも１つを出力する出力手段と、
を具備したことを特徴とするソフトウェア仕様再利用支援装置。A software specification reuse support device that supports creation of new second software specification data using previously created first software specification data including a plurality of specification component data having a higher / lower relationship,
First storage means for storing at least first information indicating a higher-order / lower-order relationship between the plurality of specification component data, for the first software specification data;
The first information including second information indicating a use relationship between specification component data in a relationship that can create the other specification component data using one specification component data, and a generation order of the plurality of specification component data. Second storage means for storing a creation history of software specification data of
Specification creating means for creating second specification part data of the second software specification data having a specification part name of the first specification part data of the plurality of specification part data;
Means for creating a list of specification part names of specification part data in which the generation order is later than the first specification part data;
First search means for obtaining a specification part name of specification part data used when creating each specification part data on the list based on the second information;
Second search means for obtaining a specification part name of specification part data below the first specification part data based on the first information;
A first specification part name obtained by the first search means, the specification part name including a specification part name of specification part data which can be reused when generating specification part data to be generated after the second specification part data is generated; And the second guide information, which is the specification part name obtained by the second search means and which includes the specification part name of the specification part data to be created after the creation of the second specification part data. Output means for outputting at least one;
A software specification reuse support device comprising: 上位・下位関係を有する複数の使用部品データを含む過去に作成した第１のソフトウェア仕様データを利用して新たな第２のソフトウェア仕様データの作成を支援するソフトウェア仕様再利用支援装置であって、
前記第１のソフトウェア仕様データについて、前記複数の仕様部品データ間の上位・下位関係を表す第１の情報を記憶する第１の記憶手段と、
一方の仕様部品データを利用して他方の仕様部品データを作成できる関係にある仕様部品データ間の利用関係を表す第２の情報と、前記複数の使用部品データの作成順序を含む前記第１のソフトウェア仕様データの作成履歴を記憶する第２の記憶手段と、
一方の仕様部品データの修正が他方の仕様部品データに影響を与える関係にある仕様部品データ間の修正影響関係を表す第３の情報と、前記上位・下位関係以外の関係にある仕様部品データ間の関連関係を表す第４の情報と、双方の仕様部品データに共通の用語が仕様されている関係にある仕様部品データ間の用語関係を表す第５の情報のうちの少なくとも１つを記憶する第３の記憶手段と、
前記複数の仕様部品データのうちの第１の仕様部品データの仕様部品名をもつ前記第２のソフトウェア仕様データの第２の仕様部品データを作成する仕様作成手段と、
前記作成順序が前記第１の仕様部品データよりも後の仕様部品データの仕様部品名のリストを作成する手段と、
前記第２の情報を基に、前記リスト上の各仕様部品データを作成する際に利用された仕様部品データの仕様部品名を求める第１の探索手段と、
前記第１の情報を基に、前記第１の仕様部品データの下位にある仕様部品データの仕様部品名を求める第２の探索手段と、
上位・下位関係と利用関係と修正影響関係と関連関係と用語関係のうち指定された関係の種類とその優先度に基づき、前記第１の探索手段で求めた仕様部品名であって、前記第２の仕様部品データ作成後に作成する仕様部品データを作成する際に再利用可能な仕様部品データの仕様部品名を含む第１のガイド情報と、前記第２の探索手段で求めた仕様部品名であって、前記第２の仕様部品データ作成後に作成すべき仕様部品データの仕様部品名を含む第２のガイド情報と、前記第１の仕様部品データと前記修正影響関係にある仕様部品データの仕様部品名を含む第３のガイド情報と、前記第１の仕様部品データと前記関連関係にある仕様部品データの仕様部品名を含む第４のガイド情報と、前記仕様部品データと前記用語関係にある仕様部品データの仕様部品名を含む第５のガイド情報のうちの少なくとも１つを出力する出力手段と、
を具備したことを特徴とするソフトウェア仕様再利用支援装置。A software specification reuse support device that supports creation of new second software specification data using previously created first software specification data including a plurality of used component data having a higher / lower relationship,
First storage means for storing, for the first software specification data, first information indicating an upper / lower relationship between the plurality of specification component data;
The second information indicating the use relationship between the specification component data in a relationship in which one specification component data can be used to create the other specification component data, and the first information including a generation order of the plurality of use component data. Second storage means for storing a creation history of software specification data;
A third information indicating a modification influence relationship between the specification component data in which the modification of one specification component data affects the other specification component data; And at least one of fifth information indicating a term relationship between specification part data in a relation in which a term common to both specification part data is specified is stored. Third storage means;
Specification creating means for creating second specification part data of the second software specification data having a specification part name of the first specification part data of the plurality of specification part data;
Means for creating a list of specification part names of specification part data in which the generation order is later than the first specification part data;
First search means for obtaining a specification part name of specification part data used when creating each specification part data on the list based on the second information;
Second search means for obtaining a specification part name of specification part data below the first specification part data based on the first information;
A specification part name obtained by the first search means based on a type of a specified relation among a higher-order relation, a lower-order relation, a use relation, a relation relation, and a term relation and a priority thereof; The first guide information including the specification part name of the specification part data which can be reused when the specification part data created after the second specification part data is created, and the specification part name obtained by the second search means. The second guide information including the specification part name of the specification part data to be created after the creation of the second specification part data; and the specification of the specification part data having the correction influence relationship with the first specification part data. Third guide information including a part name, fourth guide information including a specification part name of the specification part data having the relation with the first specification part data, and the term relation with the specification part data. Specification parts And output means for outputting at least one of the fifth guide information including a specification part name of over data,
A software specification reuse support device comprising: 前記出力手段は、上位・下位関係と利用関係と修正影響関係と関連関係と用語関係のなかから複数種類の関係が指定されたとき、前記第１乃至第５のガイド情報のうち、指定された各種類の関係に対応するガイド情報を、指定された優先度の順に出力することを特徴とする請求項２記載のソフトウェア仕様再利用支援装置。The output unit, when a plurality of types of relations are specified from among the upper / lower relations, the usage relations, the modification influence relations, the relation relations, and the term relations, are designated among the first to fifth guide information. 3. The software specification reuse support device according to claim 2, wherein guide information corresponding to each type of relationship is output in the order of designated priority.
JP00205695A 1994-09-19 1995-01-10 Software specification reuse support device Expired - Lifetime JP3554056B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP00205695A JP3554056B2 (en) 1994-09-19 1995-01-10 Software specification reuse support device

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP6-223576 1994-09-19
JP22357694 1994-09-19
JP00205695A JP3554056B2 (en) 1994-09-19 1995-01-10 Software specification reuse support device

Publications (2)

Publication Number Publication Date
JPH08147152A JPH08147152A (en) 1996-06-07
JP3554056B2 true JP3554056B2 (en) 2004-08-11

Family

ID=26335370

Family Applications (1)

Application Number Title Priority Date Filing Date
JP00205695A Expired - Lifetime JP3554056B2 (en) 1994-09-19 1995-01-10 Software specification reuse support device

Country Status (1)

Country Link
JP (1) JP3554056B2 (en)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3582962B2 (en) * 1997-07-28 2004-10-27 株式会社東芝 Editing device, editing method, and recording medium
JP4390402B2 (en) 2001-03-29 2009-12-24 富士通株式会社 Knowledge information management method, knowledge information utilization method, and knowledge information management device
JP4706001B2 (en) * 2004-12-15 2011-06-22 信夫 濱田 Design computer programs
JP5236564B2 (en) 2009-04-20 2013-07-17 株式会社日立製作所 Software reuse support method and apparatus
JP5615249B2 (en) 2011-10-31 2014-10-29 富士通株式会社 Association program, association method, and association apparatus
JP6120607B2 (en) * 2013-02-22 2017-04-26 三菱電機株式会社 Requirement detection apparatus and requirement detection program

Also Published As

Publication number Publication date
JPH08147152A (en) 1996-06-07

Similar Documents

Publication Publication Date Title
JPH04102171A (en) Device and method for processing information
EP0989500A2 (en) File management system and its method and storage medium
US5590270A (en) Method and apparatus for detecting a lower level software reusable product in generating an upper level software product from a lower level software product and changing the upper level software product
JP3181994B2 (en) How to automatically create job flow specifications
JP2001014196A (en) Method and device for processing data and storage medium
JP3554056B2 (en) Software specification reuse support device
JP4404930B2 (en) Information processing apparatus, control method therefor, information processing system, program, and computer-readable recording medium
JP2001014152A (en) Method and device for data processing, and storage medium
JP2000339306A (en) Document preparing device
JP2000035961A (en) Sgml editor and using method therefor
JP2000003366A (en) Document registration method, document retrieval method, execution device therefor and medium having recorded its processing program thereon
JP4325790B2 (en) Method and apparatus for reflecting data in database and program thereof
JP2003241964A (en) Software maintenance data generation device and generation program
JPS62197826A (en) Production of system flow specifications
JP4255538B2 (en) Structured document storage and retrieval device
JPH06214768A (en) Program part generation method and automatic program generation method
JP2010157165A (en) Information processor, information processing method, and program
JP3445910B2 (en) Document summarization synthesizer
JP2009003780A (en) Module management method, module management device, module management system, and module management program
JPH05307472A (en) Program parts information reusing device
JPH09185537A (en) Overall job information system
JP6029641B2 (en) Document creation support apparatus and document creation support method
JP4026955B2 (en) File management apparatus, file management method, and storage medium
JPH11212694A (en) Information processing system
JPH10161996A (en) Method and device for preparing document

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20040127

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20040324

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20040420

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20040506

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090514

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090514

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100514

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100514

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110514

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110514

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120514

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120514

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130514

Year of fee payment: 9

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130514

Year of fee payment: 9

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140514

Year of fee payment: 10

EXPY Cancellation because of completion of term