JP2007279883A - ファイル構成管理システム - Google Patents

Abstract

【課題】更新が必要な派生システムでの反映漏れを防止し、システム開発効率を向上させる。
【解決手段】データベースに、システム毎に含まれる全てのファイルについて記録したファイル情報テーブル２２と、派生元ファイルと派生先ファイルとの関係を記録した派生情報テーブル３１を設ける。また、他のシステムに属するファイルが自らのシステムのファイルと派生関係にある場合に、派生情報テーブル３１に基づいて他システムのファイルの更新情報を管理する更新情報テーブル２３を設ける。ファイル構成管理装置１は、システムを構成するファイルの状況を確認する際にファイル情報テーブル２２を検索し、該当ファイルの更新情報を更新情報テーブル２３より検索し、派生関係にあるファイルに更新が発生したことを表示するファイルリスト画面を表示する。また、更新情報の確認漏れを防ぐため、更新情報を確認済とする更新情報管理機能１３を設ける。
【選択図】図１

Description

本発明はファイル構成管理システムに関わり、特に複数のバージョンが存在するファイルの更新情報の管理方式に関する。

ソフトウェアシステム開発では、過去に開発したファイルをベースにして新たな開発が行われる。システムによっては、既存システムの基本構成をコピーして、新たな使用目的にあわせてファイルの構成を変更したり、新たなファイルを付加したり、もしくは既に存在するファイルを修正して使用し、新たなシステムを構築することが行われる。ファイル構成管理装置にも、システムのデータベースをコピーする機能が備わっている。

このように、あるシステムとそのシステムを構成するファイルをコピーして別のシステムを構築する場合、派生元ファイルと派生先ファイルに基づいて作成した派生先システムは、新たにファイル構成管理装置に１つのシステムとして登録され、派生元システムとは独立した構成管理が行われる。

ファイル構成管理装置の例として特許文献１の記載がある。この公知例では、システムを派生して新たなシステムを作成した場合、新たなシステムから派生元システムのファイルとの対応をとるため、派生元ファイルと派生先ファイルとの派生情報を保持している。これにより、更新情報を他システムと間で共有できる可能性を示している。

特開平８−３２０７８２号公報

上記のように、システムの派生を行い、派生元システム、派生先システムに独立して開発と保守が進められた場合、従来のファイル構成管理装置においては、それぞれのシステムごとに独立した構成管理を行うため、次のような問題が発生していた。

派生先システムには、派生元ファイルがそのまま用いられたり、その一部を修正したりして用いられている。このファイルが更新された場合、更新はこのファイルを含む派生システム全てにおいて必要な更新であるかも知れない。このため、システムに含まれるファイルが更新されたときには、派生先システムでも同様の更新が必要かを確認し、必要なら更新作業を行う必要がある。

派生先システムにおいてこの判断を行うためには、まず更新が行われていることを知る必要がある。また、更新が行われた派生元ファイルが、自らの派生先システムに含まれているか、含まれているならどのファイルかと言った情報を、全て手作業で調査する必要があった。これは、派生元システムと派生先システムが逆の場合でも全く同様である。派生先システムでの更新が、派生元システムに必要な更新かどうかを判断する必要がある。さらには、派生関係にあるシステムであれば、直接派生したシステムではなくとも、更新が必要かを判断する必要がある。

しかし、従来のファイル構成管理装置は派生元ファイルと派生先ファイルの関係をデータベース内に保持し、派生関係を表示する目的で用いてはいたものの、更新情報を伝達する目的で使用されてはいなかった。このため、ファイルの更新情報を派生関係にあるシステムに伝達することができず、本来必要であったはずの更新が、反映されずにおかれてしまっていた。また、もし本人への確認や、打合せなどの別の伝達手段で更新情報が伝わったとしても、派生先システムでファイルのパス構成に変更が加えられていれば、発生した更新情報が、派生先システム内のどのファイルに対応するものかを把握することは困難であった。さらに、更新が複数発生した場合、どの更新を反映する必要があり、またどの更新は反映する必要がないか、という判断が曖昧になり、結果的に必要な更新が行われない危険性があった。

特許文献１の場合にも、派生元ファイルと派生先ファイルとの派生情報は、派生関係を示すためにしか使用されていない。このため、派生関係にあるシステムが更新されたかといった情報の確認は、すべてユーザが行うほかなく、依然として反映すべき更新の確認漏れや、反映漏れが発生する可能性があった。

本発明の目的は、上記従来技術の問題点に鑑み、派生関係にあるシステム間でファイルの更新を伝達し、更新が必要な派生システムでの反映漏れを防止し、システム開発効率を向上できるファイル構成管理装置を提供することにある。

上記目的を達成するために、本発明は、ソフトウェアシステム毎に管理するシステムデータベースと、各システムに登録されたファイルの構成管理を行うファイル構成管理装置を備えるファイル構成管理システムにおいて、システム毎に含まれる全てのファイルについて記録したファイル情報テーブルと、派生関係にあるファイルについて派生元ファイルと派生先ファイルとの関係を記録した派生情報テーブルと、他システムに属するファイルが自システムのファイルと派生関係にある場合に、前記派生情報テーブルに基づいて他システムのファイルの更新情報を管理する更新情報テーブルを設け、前記ファイル構成管理装置は、システムを構成するファイルの状況を確認する際に、前記ファイル情報テーブルから該当ファイルを検索し、その更新情報を前記更新情報テーブルより検索することにより、派生関係にあるファイルに更新が発生したことを表示する機能を備えることを特徴とする。

これにより、更新情報の確認のため、前記更新情報テーブルに記録された更新情報の詳細を画面に表示することで、ユーザが更新の行われたファイルを確認し、当該ソフトウェアシステムに更新情報を反映する必要があるかどうかの判断を行う。反映が必要であれば更新を行う、といった更新情報の確認作業を容易に行える。また、更新情報の確認漏れを防ぐため、ユーザが更新情報の確認作業を完了し、更新情報を「確認済」状態へと変更できるようにし、「確認済」状態へ更新するまで、常に表示を行う。また、更新情報は確認済の後もデータベース内に残り、更新情報の確認履歴を保持しつづける。これにより、派生関係にあるシステムの更新情報を確実に取得し、反映することが可能となる。

本発明によれば、派生関係にあるサイトにおけるファイルの更新を伝達することができ、同様の更新が必要な派生サイトにおける反映モレを防ぎ、システム開発の効率を向上することが可能な効果がある。

はじめに、本発明のファイル構成管理装置に関わるシステムの全体構成の説明と言葉の定義を行う。

ソフトウェアのシステム開発では、ファイル構成管理装置が広く用いられている。システムは計算機とプログラムからなり、複数のファイルによって構成されている。ファイルには、プログラムファイルとデータファイルが含まれる。ファイル構成管理装置は、ファイルを登録するためのデータベースをもち、その登録ファイルを制御するための機能を有している。

登録ファイルの制御として、（１）ファイルのデータベースへの追加、（２）ファイルのデータベースからの削除、（３）データベース内にあるファイルの変更、（４）データベース内にあるファイルのパス変更、（５）データベースの新規作成が可能なものである。

システムに含まれるファイルは、ファイル構成管理装置によってシステムごとにまとめて管理される。各々のファイルは、ファイル構成管理装置によって開発バージョンの管理が行われる。このとき、ファイルにつけられるバージョンを「ファイルバージョン」と呼ぶ。また、各々のファイルだけでなく、それを組み合わせたシステムについても、ファイル構成管理装置によってバージョンの管理が行われる。本文中では、ファイルバージョンとの区別をつけるため、システムのバージョンを「システムバージョン」と呼ぶ。各システムバージョンは、必要なファイルの、必要なファイルバージョンの組合せによって構成されている。システムに修正を加える必要が生じた場合、ファイル単位では、対象となるファイルの修正が行われ、ファイルバージョンが更新される。また、システム全体としては修正後のファイルを含めた新たなシステム構成が構築され、これが新たなシステムバージョンとして管理される。

システム開発では、既存システムの基本構成をコピーして、新たな使用目的にあわせてファイルの構成を変更したり、新たなファイルを付加したり、もしくは既に存在するファイルを修正して使用し、新たなシステムを構築することが行われる。ファイル構成管理装置にも、システムのデータベースをコピーする機能が備わっている。このように、あるシステムとそのシステムを構成するファイルをコピーして別のシステムを構築することを、本文中ではシステムの「派生を行う」と表現し、元となったシステムを派生元システム、派生して作成したシステムを派生先システムと呼ぶ。また、そのシステムに含まれるファイルについても同様に、派生元ファイル、派生先ファイルと呼ぶ。また、派生元と派生先の関係にあることを、「派生関係にある」と表現する。このような派生に基づいて作成した派生先システムは、新たにファイル構成管理装置に１つのシステムとして登録され、派生元システムとは独立した構成管理が行われる。

以下、本発明の実施の形態について図面を参照しながら詳細に説明する。図１は一実施例によるファイル構成管理システムの全体構成を示す。本システムは、ファイル構成管理装置１、システムデータベース２、派生情報データベース３から構成されている。

ファイル構成管理装置１は、ユーザ１０からの処理要求を受け付けるための受け付け機能１１を有している。また、ユーザからの要求をうけて、システムデータベース２内のファイルデータを管理するためのファイルデータ管理機能１２、ファイルの派生情報とファイルの更新情報を管理する更新情報管理機能１３を有している。ユーザ画面表示機能１４は、ファイルデータ管理機能１２と更新情報管理機能１３からの要求をうけて、ユーザへの画面表示を行う。

システムデータベース２には、ファイル構成管理装置１にて管理されているソフトウェアシステムが、システムごとにシステムデータベース２０として記録されている。システムデータベース２０の各々には、ソフトウェアシステムに含まれるファイルデータ２１、システムに含まれるファイルの情報を記録したファイル情報テーブル２２、派生関係にあるファイルの更新情報を記録した更新情報テーブル２３が記録されている。

派生情報データベース３には、ファイルの派生関係を記録した派生情報テーブル３１が記録されている。

ユーザがファイル構成管理装置１にアクセスする際には、まず図２の初期画面が表示される。初期画面１００には、ファイル構成管理装置１にて管理が行われているシステム名称の一覧表示１０１と、そのシステム名称１０２と、システムを選択するためのチェックボックス１０３と、新規システムを作成するための新規作成ボタン１０４と、システム全体を派生して新たなシステムを作成するための派生作成ボタン１０５が表示される。この画面を表示するときの処理手続きを、図１により説明する。

ユーザ１０からファイル構成管理装置１に初期画面の表示要求があったとき、受け付け機能１１がその情報を受け付ける。受け付け機能１１は、ファイルデータ管理機能１２に対して、登録されているシステムの一覧を取得するよう要求を出す。ファイルデータ管理機能１２は、システムデータベース２にアクセスし、ファイル構成管理装置１にて管理が行われているシステム名称の一覧を取得し、ユーザ画面表示機能１４にシステム一覧を表示するように要求する。ユーザ画面表示機能１４はユーザに対して、システム一覧を含めた初期画面１００を表示する。

図２において、新規作成ボタン１０４を押すことによって、新たなソフトウェアシステムを作成することができる。新規作成ボタン１０４を押したときの処理手続きを、図１により説明する。

ユーザよりファイル構成管理装置１に新規システム作成要求があったとき、受け付け機能１１は、ファイルデータ管理機能１２に対して、新規システムを作成するように要求を出す。ファイルデータ管理機能１２は、システムデータベース２にアクセスし、新規システム用のデータベースを作成し、ユーザ画面表示機能１４に新規システムを含めたシステム一覧を表示するように要求する。ユーザ画面表示機能１４はユーザに対して、新規システムを含めたシステム一覧の初期画面１００を表示する。

図２において、派生を行いたいシステムのチェックボックス１０３にチェックを入れて、派生作成ボタン１０５を押すことによって、派生システムを作成することができる。派生作成ボタン１０５を押したときの処理手続きを、図１において説明する。

ユーザよりファイル構成管理装置１にソフトウェアシステムの派生要求があったとき、受け付け機能１１はファイルデータ管理機能１２に対して、システム派生を行うように要求を出す。同時に、更新情報管理機能１３に対して、システムの派生情報を記録するように要求を出す。

ファイルデータ管理機能１２は、システムデータベース２にアクセスし、派生元システムのデータベースを、派生先システムのデータベースとしてコピーし、ユーザ画面表示機能１４に派生先システムを含めたシステム一覧を表示するように要求する。同時に、更新情報管理機能１３は派生情報データベース３にアクセスし、派生情報テーブル３１に派生情報を記録する。ユーザ画面表示機能１４はユーザに対して、派生先システムを含めた初期画面を表示する。

図２において、システム名称１０２を選択することによって、選択したシステムのファイルリスト画面が表示される。図３はファイルリスト画面を示し、ファイルリスト画面３００には、参照しているシステム名称３０１、本システムのファイルリストおよびバージョン３０２、現在表示しているディレクトリ３０３を表示する。また、ファイルリストにあるファイルのうち、派生関係にあるファイルの更新情報があるファイルには、更新表示３０４が表示される。この更新表示３０４をクリックすることで、図４のファイル更新情報画面４００が表示される。

ファイルリスト画面３００にはファイルを選択するためのチェックボックス３０５が表示される。また、システム全体での更新情報の件数３０６が表示される。更新情報一覧ボタン３０７を押すことで、図５の更新情報一覧画面５００が表示される。また、ファイル操作用のボタンとして、ファイル追加ボタン３０８、ファイル削除ボタン３０９、ファイル修正ボタン３１０、ファイルパス修正ボタン３１１が表示される。

図３のファイルリスト画面３００を表示するときの処理手続きを、図１において説明する。ユーザが初期画面１０１（図２）よりシステム名称１０２を選択することで、受け付け機能１１は、ファイルデータ管理機能１２に対して、選択したシステム名称のファイル一覧を取得するように要求を出す。ファイルデータ管理機能１２は、システムデータベース２にアクセスし、システム名称のデータベースよりファイルリストを取得し、ユーザ画面表示機能１４にファイルリストを表示するように要求する。ユーザ画面表示機能１４はユーザに対して、ファイルリスト画面３００を表示する。

図３において、操作を行いたいファイルのチェックボックス３０５にチェックを入れて、いずれかの操作ボタンを押すことで、ファイルに対しての操作が行える。ここでは、ファイル修正ボタン３１０を押したときの処理手続きを、図１において説明する。

ユーザがチェックボックス３０５にチェックを入れて選択したファイルに対し、ファイル修正ボタン３１０を押す。受け付け機能１１はファイルデータ管理機能１２に対して、選択したシステム内の選択したファイルを修正するように要求を出し、それと同時に、更新情報管理機能１３に対して、ファイル更新情報を更新するように要求を出す。

まず、ファイルデータ管理機能１２は、システムデータベース２にアクセスし、システム名称のデータベースよりファイルを検索し、ファイルの修正処理を行う。同時に、更新情報管理機能１３は、派生情報データベース３内の派生情報テーブル３１にアクセスし、更新が行われたファイルと派生関係にあるファイルと、そのファイルを含むシステム名称の情報を取得する。そして、システムデータベース２内の、システム名称のデータベースに含まれている更新情報テーブル２３に対して、更新情報を記録する。

図３のファイル追加３０８、ファイル削除、ファイルパス変更３１１の各操作ボタンについても、同様の処理によりデータベースとテーブルが更新される。これらの機能によるデータベースやテーブルの更新手順の詳細は後述のフロー図により説明する。

図３のファイルリスト画面３００において更新表示３０４をクリックすることによって、図４のファイル更新情報画面が表示される。画面には現在のシステム名称４０１が表示され、また対象ファイルの更新情報４０２が表示される。画面には、ファイルリスト画面を表示するためのボタン４０３と、ファイルの更新情報を確認済に変更するための確認ボタン４０４が表示される。図４は対象ファイルが明確な場合に好都合である。

図４において、確認ボタン４０４を押したときの処理手続きを、図１により説明する。

ユーザが確認ボタン４０４を押すことで、受け付け機能１１は更新情報管理機能１２に対して、ファイル更新情報を確認済に更新するように要求を出す。更新情報管理機能１２は、システムデータベース２内の、システム名称のデータベースに含まれている更新情報テーブル２３を検索し、更新情報を確認済へと更新する。

図３のファイルリスト画面３００において更新情報一覧ボタン３０７をクリックすることによって、図５の更新情報一覧画面５００が表示される。画面には現在のシステム名称５０１が表示され、ソフトウェアシステムに含まれるファイルの更新情報５０２が表示される。画面には、ファイルリスト画面３００を表示するためのファイルリストボタン５０３と、ファイルの更新情報を確認済に変更するための確認ボタン５０４が表示される。図５において、確認ボタン５０４を押した場合も、図４の確認ボタン４０４を押した場合と同様の処理となる。図５は、対象ファイルが明確でない場合や、一覧画面を見たい場合に都合がよい。

システムデータベース２の各システムのデータベースは１つずつファイル情報テーブル２２を有し、データベース内のファイル情報を保持している。図６はファイル情報テーブルのデータ構成を示し、ファイルＩＤは、各システムのデータベース内のファイルに対して、データベース内で一意となるように割り振られる。ファイルパスは、データベース内でのファイルのパスを示している。バージョンは、現在登録されているファイルの最新バージョンを示している。

図７は更新情報テーブルのデータ構成を示している。更新情報テーブル２３は、各システムデータベース内に１つずつ存在し、派生関係にあるシステムでの更新情報を保持している。更新情報ＩＤは、更新情報１件ごとに一意に割り振られるＩＤである。ファイルＩＤは、本システムデータベースのファイル情報テーブル２２のファイルＩＤと対応しており、本システムでのファイルを示す。システム名称は、更新が発生したシステムの名称を示す。更新ファイルＩＤは、実際に更新されたファイルを示し、システム名称のシステムにおけるデータベース内のファイル情報テーブル２２と対応している。更新内容は、ファイルに対してどのような更新が行われたかを示す。バージョンは、本システムのファイルの最新バージョン（更新後のバージョン）を示す。確認フラグは、更新情報が確認済みであるかどうかを示す。

図８は派生情報テーブルのデータ構成を示す。派生情報テーブル３１は、派生情報管理データベース３内にあり、システム間で派生されたファイルの情報を保持している。システム名称は、派生されたファイルが含まれるシステム名称を示す。ファイルＩＤは、システム名称のデータベース内での派生ファイルを示し、ファイル情報テーブルと対応している。派生関係ファイル共通ＩＤは、派生関係をグループ化するための識別子で、同じ派生元から派生したファイルは全て同一の識別子となるように取得される。

図９はファイルリスト画面を表示するための処理フローを示す。ファイルリスト画面表示処理は、更新情報管理機能１３で実行され、表示要求はユーザ画面表示機能１４に対して実行される。

ユーザよりファイルリスト画面３００の表示要求を受けたとき（９−１）、派生情報管理機能１３は、ファイルデータ管理機能１２より、表示対象となるファイルの「表示対象ファイルＩＤ」と、「システム名称」を取得する（９−２）。まず、「システム名称」と一致するシステムのデータベースの『更新情報テーブル』を参照する（９−３）。次に、確認フラグが”確認済”でない更新情報の登録件数を計数する（９−４）。もし更新情報が全くない場合には、派生情報を表示する必要はないため、派生情報管理機能１３は処理を停止する（９−５）。登録情報があった場合には、計数した登録数をもとに、要確認件数３０６を表示するように、ユーザ画面表示機能１４へ要求する（９−６）。

次に、「表示対象ファイルＩＤ」と『更新情報テーブル』内の「ファイルＩＤ」とを比較し、一致する更新情報があるか検索する（９−７）。もし「ファイルＩＤ」が一致しない場合は、表示対象となるファイルに対する更新情報は存在しないため、更新表示は表示しない（９−８）。もし一致した場合は、一致した更新情報の「確認フラグ」が”確認済”であるかを確認する（９−９）。”確認済”となっていた場合、本更新情報は既に確認済であるため、更新表示は表示しない（９−１０）。もし”確認済”ではなかった場合、表示対象となるファイルに対して更新表示３０４をオンするように、ユーザ画面表示機能１４へ要求する（９−１１）。

これで１件の表示対象となるファイルに対する処理は停止し、次の表示対象となるファイルに対して処理を繰り返す（９−１２）。もし、全更新情報を参照し終えた場合、更新情報管理機能１３は処理を停止する。

図１０はファイル更新情報画面を表示するための処理フローを示す。ファイル更新情報画面の表示処理は、更新情報管理機能１３で実行され、処理中の表示要求はユーザ画面表示機能１４に対して実行される。

ユーザよりファイル更新情報画面４００の表示要求を受けたとき（１０−１）、更新情報管理機能１３は、ファイルデータ管理機能１２より、表示対象となるファイルの「表示対象システム名称」および「表示対象ファイルＩＤ」を取得する（１０−２）。まず、「システム名称」と一致するデータベースの『更新情報テーブル』を参照する（１０−３）。次に、確認フラグが”確認済”でない更新情報の登録数を計数する（１０−４）。もし更新情報が全くない場合には、更新がないことを表示（１０−５）するように、ユーザ画面表示機能１４へ要求したうえで更新情報管理機能１３は処理を停止する。登録情報があった場合には、計数した登録数をもとに、要確認件数３０６を表示するように、ユーザ画面表示機能１４へ要求する（１０−６）。

続いて、「表示対象ファイルＩＤ」を、『更新情報テーブル』より検索し、検索情報の「確認フラグ」を取得する（１０−７）。次に、「確認フラグ」が”確認済”となっているか確認する（１０−８）。”確認済”となっていた場合、本更新情報は既に確認済であるため、表示せずに本更新情報の処理は停止する（１０−９）。もし、「確認フラグ」が”確認済”ではなかった場合、『ファイル情報テーブル』を参照し「ファイルＩＤ」を検索、「ファイルパス」を取得する（１０−１０）。この「ファイルパス」および更新情報の「システム名称」「更新内容」「バージョン」を用いて、更新情報を表示するように、ユーザ画面表示機能１４へ要求する（１０−１１）。これで更新情報管理機能１３は処理を停止する。

更新情報一覧画面に、更新システムのデータベース内でのファイルパスを表示したい場合には、『更新情報テーブル』内の「更新ファイルＩＤ」をもとに、「システム名称」のデータベースの『ファイル情報テーブル』内にある「ファイルＩＤ」を検索することで、ファイルパスを取得することが可能である。

図１１は更新情報一覧画面を表示するための処理フローを示す。更新情報一覧画面５００の表示処理は、更新情報管理機能１３で実行され、処理中の表示要求はユーザ画面表示機能１４に対して実行される。

ユーザよりファイルリスト画面３００の表示要求を受けたとき（１１−１）、更新情報管理機能１３は、ファイルデータ管理機能１２より、「表示対象システム名称」を取得する（１１−２）。まず、「システム名称」と一致するサイトの『更新情報テーブル』を参照する（１１−３）。次に、確認フラグが”確認済”でない更新情報の登録数を計数する（１１−４）。もし更新情報が全くない場合には、更新がないことを表示（１１−５）するように、ユーザ画面表示機能１４へ要求したうえで更新情報管理機能１３は処理を停止する。登録情報があった場合には、計数した登録数をもとに、要確認件数３０６を表示するように、ユーザ画面表示機能１４へ要求する（１１−６）。

続いて、登録されている更新情報より「ファイルＩＤ」「確認フラグ」を取得する（１１−７）。次に、「確認フラグ」が”確認済”となっているか確認する（１１−８）。もし”確認済”となっていた場合、本更新情報は既に確認済であるため、表示せずに本更新情報の処理は停止し、次の更新情報を参照する（１１−９）。もし、「確認フラグ」が”確認済”ではなかった場合、『ファイル情報テーブル』を参照し「ファイルＩＤ」を検索、「ファイルパス」を取得する（１１−１０）。この「ファイルパス」および更新情報の「システム名称」「更新内容」「バージョン」を用いて、更新情報を表示するように、ユーザ画面表示機能１４へ要求する（１１−１１）。

これで１件の更新情報に対する処理は停止し、次の更新情報を参照する（１１−１２）。もし、全更新情報を参照し終えた場合、更新情報管理機能１３は処理を停止する。更新情報一覧画面５００に、更新システムのデータベース内でのファイルパスを表示したい場合には、『更新情報テーブル』内の「更新ファイルＩＤ」をもとに、「システム名称」のデータベースの『ファイル情報テーブル』内にある「ファイルＩＤ」を検索することで、ファイルパスを取得することが可能である。

図１２は、実際に複数システム間にてファイルを派生し、更新を行った例である。本例を用いて、派生情報テーブル３１、更新情報テーブル２３の更新手続き例を説明する。

まず、初期システムとして、「システムＡ」が存在する。これは、図１２の４つのファイルを含むシステムである。この「システムＡ」を派生し、「システムＢ」および「システムＣ」を作成する。

まず、システム全体の派生の前に、１ファイル単位で派生を行った場合を説明する。図１３は、１ファイル派生処理を行った際のテーブル更新手続きを示すフローである。ユーザより１ファイル派生要求を受けたとき（１３−１）、更新情報管理機能１３は、ファイルデータ管理機能１２より、「派生元システム名称」と「派生元ファイルＩＤ」、および「派生先システム名称」と「派生先ファイルパス」を取得する（１３−２）。派生先ではまだ「ファイルＩＤ」登録がなされていないため、派生先での「ファイルＩＤ」を取得する必要がある。

まず、「派生先システム名称」と一致するデータベースのファイル情報テーブル２２を参照する（１３−３）。次に、テーブル内で一意になるように「新規ファイルＩＤ」を取得する（１３−４）。次に、ファイル情報テーブル２２に「新規ファイルＩＤ」「派生先ファイルパス」および「バージョン」を初期バージョンである”１．１”として、新規情報登録する（１３−５）。次に、派生情報テーブル３１を参照し、「派生元システム名称」「派生元ファイルＩＤ」を検索する（１３−６）。情報がある場合、この情報より「派生元派生関係ファイル共通ＩＤ」を取得する（１３−７）。もし情報がない場合、テーブル内で一意になるように「新規派生関係ファイル共通ＩＤ」を取得する（１３−８）。

次に、「派生元システム名称」「派生元ファイルＩＤ」および「新規派生関係ファイル共通ＩＤ」を派生情報テーブル３１に新規情報登録する（１３−９）。次に、「派生先システム名称」「派生先ファイルＩＤ」および「派生先派生関係ファイル共通ＩＤ」として、「派生元派生関係ファイル共通ＩＤ」もしくは「新規派生関係ファイル共通ＩＤ」を用いて、派生情報テーブル３１に新規情報登録する（１３−１０）。

以上で更新情報管理機能１３は１ファイル派生の処理を完了し、処理停止する。もし、同時に複数のサイトを作成する場合には、本処理をサイト作成数繰り返すことで処理可能である。

この「１ファイル派生処理」に基づき、図１２において「システムデータベース派生処理」を行った際のテーブル更新手続きフローは図１４となる。

ユーザよりシステムデータベース派生要求を受けたとき（１４−１）、更新情報管理機能１３は、ファイルデータ管理機能１２より、「派生元システム名称」と、「派生先システム名称」を取得する（１４−２）。まず、「派生元システム名称」と一致するデータベースのファイル情報テーブル２２を参照し（１４−３）、このテーブル２２の登録情報を順次処理する。

ファイル情報テーブル２２より登録情報を選択し、「派生元ファイルＩＤ」と「派生元ファイルパス」を取得する（１４−４）。次に、「派生先ファイルパス」を、選択した登録情報の「派生元ファイルパス」と同一とする（１４−５）。次に、「派生元システム名称」「派生元ファイルＩＤ」「派生先システム名称」「派生先ファイルパス」により、図１３の「１ファイル派生処理」を実行する（１４−６）。これで、ファイル情報テーブル２２内の１つの登録情報について処理が終了したため、次の登録情報を処理する（１４−７）。

全ての登録情報を処理し終えたら、更新情報を引継ぐため、「派生元システム名称」の更新情報テーブル２３およびファイル情報テーブル２２を、「派生先システム名称」にコピーする（１４−８）。以上で更新情報管理機能１３はシステムデータベース派生の処理を完了し、処理停止する。もし、同時に複数のサイトを作成する場合には、本処理をサイト作成数繰り返すことで処理可能である。

次に、ファイルを新たに追加する場合を説明する。図１２の「システムＢ」に、ファイル”/.../yyy/mno.c”１２２を新たに追加した例である。

図１５はファイル追加処理のテーブル更新手続きフローを示す。ユーザよりファイル追加要求を受けたとき（１５−１）、更新情報管理機能１３は、ファイルデータ管理機能１２より、追加ファイルの「システム名称」と、「ファイルパス」を取得する（１５−２）。

まず、「システム名称」と一致するデータベース内のファイル情報テーブル２２を参照する（１５−３）。このデータベース内で一意となるように、「新規ファイルＩＤ」を取得する（１５−４）。次に、この「新規ファイルＩＤ」、「ファイルパス」および「バージョン」を初期バージョンの”１．１”として、派生情報テーブル３１に新規登録する（１５−５）。

以上で、更新情報管理機能１３はファイル追加処理を完了し、処理停止する。もし、同時に複数のファイルを追加した場合は、同様の処理をファイル数繰り返すことにより処理可能である。

図１６はファイルパス変更処理のテーブル更新手続きフローを示す。図１２のシステムＢにあるファイルパス”/.../xxx/ghi.c”を、ファイルパス”/.../yyy/ghi.c”に変更１２３した例である。ユーザよりファイルパス変更要求を受けたとき（１６−１）、更新情報管理機能１３は、ファイルデータ管理機能１２より、パス変更ファイルの「システム名称」「ファイルＩＤ」と、「変更後ファイルパス」を取得する（１６−２）。

まず、「システム名称」と一致するシステムのファイル情報テーブル２２を参照する（１６−３）。次に、「ファイルＩＤ」と一致する登録情報を検索する（１６−４）。次に、この登録情報の「ファイルパス」を、「変更後ファイルパス」に変更する（１６−５）。以上で更新情報管理機能１３はファイルパス変更処理を完了し、処理停止する。もし、同時に複数のファイルパスを変更した場合は、同様の処理をファイル数繰り返すことにより処理可能である。

図１７はファイル修正処理のテーブル更新手続きのフローを示す。図１２の「システムＢ」のファイル”/.../xxx/abc.c”を修正し、ファイルバージョンを１．２に変更１２４した例である。ユーザよりファイルパス変更要求を受けたとき（１７−１）、更新情報管理機能１３は、ファイルデータ管理機能１２より、修正ファイルの「修正システム名称」「修正ファイルＩＤ」「修正後バージョン」を取得する（１７−２）。

まず、派生情報テーブル３１を参照し、「修正システム名称」「修正ファイルＩＤ」と一致する派生情報を検索する（１７−３）。もし、派生情報がなかった場合、本ファイルは派生されていないため、処理停止する（１７−４）。派生情報があった場合は、派生情報より「修正派生関係ファイル共通ＩＤ」を取得する（１７−５）。次に、派生情報テーブル３１より「修正派生関係ファイル共通ＩＤ」と一致する登録情報を、登録順に検索する（１７−６）。

もし、新たな登録情報が発見できない場合、これ以上派生情報はないため、処理停止する（１７−７）。「修正派生関係ファイル共通ＩＤ」が発見された場合は、登録情報の「システム名称」「ファイルＩＤ」が「修正システム名称」「修正ファイルＩＤ」と一致するか確認する（１７−８）。一致した場合、この登録情報は修正ファイルそのものであるため、次の登録情報の検索に移行する（１７−９）。一致しない場合は、この登録情報の「サイト名称」を取得し、この「サイト名称」と一致するサイトの更新情報テーブル２３を参照する（１７−１０）。

次に、この更新情報テーブル２３にて一意となるように「新規更新情報ＩＤ」を取得する（１７−１１）。次に、「新規更新情報ＩＤ」「ファイルＩＤ」「修正システム情報」「修正ファイルＩＤ」「修正後バージョン」に加え、「修正内容」を”修正”、「確認フラグ」を”未確認”として更新情報テーブル２３に新規情報登録する（１７−１２）。これで、１つの派生関係にあるサイトに対する処理が終了したため、再び派生情報テーブルより「修正派生関係ファイル共通ＩＤ」の検索を行う（１７−１３）。

全て検索し、新たな登録情報が見つからなくなったら、更新情報管理機能１３はファイル修正処理を完了し、処理停止する。もし修正ファイルが複数存在する場合は、同様の処理をファイル数繰り返すことによって処理可能である。また、ファイルの更新が複数回実行された場合（１２−６）には、その都度、修正回数だけ上記処理を繰り返す。これにより、更新情報テーブル２３には同一ファイルに対して、更新後バージョンが異なる複数件の修正情報が登録される。

図１８はファイル削除処理のテーブル更新手続きフローを示す。図１２の「システムＣ」のファイル”/.../xxx/def.c”を削除１２５した例である。ユーザよりファイル削除要求を受けたとき（１８−１）、更新情報管理機能１３は、ファイルデータ管理機能１２より、削除ファイルの「削除システム名称」「削除ファイルＩＤ」を取得する（１８−２）。

まず、派生情報テーブル３１を参照し、「削除ファイルＩＤ」と一致する登録情報を検索する（１８−３）。派生情報がなかった場合、本ファイルは派生されていないため、処理停止する（１８−４）。派生情報が発見できた場合は、派生情報より「削除派生関係ファイル共通ＩＤ」を取得する（１８−５）。

次に、派生情報テーブル３１より「削除派生関係ファイル共通ＩＤ」と一致する登録情報を、登録順に検索する（１８−６）。もし、新たな登録情報が発見できない場合、本ファイルはこれ以上派生情報がないため、処理を停止する（１８−７）。発見された場合は、登録情報の「システム名称」「ファイルＩＤ」が「削除システム名称」「削除ファイルＩＤ」と一致するか確認する（１８−８）。一致した場合、この登録情報は削除ファイルそのものであるため、次の登録情報の検索に移行する（１８−９）。一致しない場合は、この登録情報の「システム名称」と一致するサイトの更新情報テーブル３１を参照する（１８−１０）。

次に、更新情報テーブル３１にて一意となるように「新規更新情報ＩＤ」を取得する（１８−１１）。次に、「新規更新情報ＩＤ」「ファイルＩＤ」「削除システム名称」「削除ファイルＩＤ」に加え、「更新内容」を”削除”、「バージョン」を”−”、「確認フラグ」を”未確認”として更新情報テーブル３１に新規情報登録する（１８−１２）。これで、１つの派生関係にあるサイトに対する処理が終了したため、再び派生情報テーブルより「削除派生関係ファイル共通ＩＤ」の検索を行う（１８−１３）。

全て検索し、新たな登録情報が見つからなくなったら、派生情報テーブル３１を参照し、「削除ファイルＩＤ」を含む登録情報を削除する（１８−１４）。以上で更新情報管理機能１３はファイル削除処理を完了し、処理停止する。もし、削除ファイルが複数存在する場合は、同様の処理をファイル数繰り返すことによって処理可能である。

最後に、ファイル更新情報画面４００もしくは更新情報一覧画面５００にて、確認済ボタンを押して更新情報を確認済状態に変更する例を説明する。図１９は更新情報を確認済み状態に変更するテーブル更新手続きのフローを示す。

ユーザより確認済反映要求を受けたとき（１９−１）、更新情報管理機能１３は、確認済反映情報の「システム名称」と、確認ボタンに与えられていた「更新情報ＩＤ」を取得する（１９−２）。まず、「システム名称」と一致するシステムの更新情報テーブルを参照する（１９−３）。次に、「更新情報ＩＤ」と一致する登録情報を検索する（１９−４）。次に、登録情報の「確認フラグ」を「確認済」に変更する（１９−５）。

以上で、更新情報管理機能１３は確認済反映処理を完了し、処理を停止する。もし、確認済反映処理対象ファイルが複数存在する場合は、同様の処理をファイル数繰り返すことによって処理可能である。

以上の説明に用いた実施例では、派生を行った順序は記録していなかったが、派生順序を記録することのできる構成も可能である。

図２０は、派生順を記録した派生情報テーブルの構成を示している。派生元システム名称、派生元ファイルＩＤ、派生元バージョンにより、派生元となったファイルが特定できる。同様に、派生先システム名称、派生先ファイルＩＤ、派生先バージョンにより、派生先でのファイルが特定できる。これにより、ファイルが派生された順序も記録することができる。

図２１は、派生順を記録した派生情報テーブルから、派生順をたどって図示したものである。図２０の派生情報を記録した派生情報テーブルを持つ場合は、正常をファイルの派生を行った順序を図２１のよう確認することができる。

本発明の一実施例によるファイル情報管理システムの構成図。 初期画面の表示例を示す説明図。 ファイルリスト画面の表示例を示す説明図。 ファイル更新情報画面の表示例を示す説明図。 更新情報一覧画面の表示例を示す説明図。 ファイル情報テーブルのデータ構成図。 更新情報テーブルのデータ構成図。 派生情報テーブルのデータ構成図。 ファイルリスト画面表示処理を示すフロー図。 ファイル更新情報画面表示処理示すフロー図。 更新情報一覧画面表示処理を示すフロー図。 システムデータベースの派生・更新例を示す説明図。 １ファイル派生処理時テーブル更新処理を示すフロー図。 データベース派生処理時テーブル更新処理を示すフロー図。 ファイル追加処理時テーブル更新処理を示すフロー図。 ファイルパス変更時処理時テーブル更新処理を示すフロー図。 ファイル修正処理時テーブル更新処理を示すフロー図。 ファイル削除処理時テーブル更新処理を示すフロー図。 更新情報確認時テーブル更新処理を示すフロー図。 派生順を記録した派生情報テーブルのデータ構成図。 ファイル派生順を記録した場合の派生関係の説明図。

符号の説明

１…ファイル構成管理装置、２…システムデータベース、３…派生情報データベース、１１…受付機能、１２…ファイルデータ管理機能、１３…更新情報管理機能、２１…ファイルデータ、２２…ファイル情報テーブル、２３…更新情報テーブル、３１…派生情報テーブル、１００…初期画面、１０１…システム名称一覧表示、１０２…システム名、１０３…チェックボックス、１０４…新規作成ボタン、１０５…派生作成ボタン、３００…ファイルリスト画面、３０１…システム名、３０２…ファイルリスト、３０３…表示ディレクトリ、３０４…更新表示、３０５…チェックボックス、３０６…更新情報件数、３０７…更新情報一覧ボタン、３０８…ファイル追加ボタン、３０９…ファイル削除ボタン、３１０…ファイル修正ボタン、３１１…ファイルパス変更ボタン、４００…ファイル更新情報画面、４０１…システム名称、４０２…ファイル更新情報、４０３…ファイルリスト画面表示ボタン、４０４…確認ボタン、５００…更新情報一覧画面、５０１…システム名称、５０２…ファイル更新情報、５０３…ファイルリスト画面表示ボタン、５０４…確認ボタン。

Claims (8)

1. ソフトウェアシステム毎に管理するシステムデータベースと、各システムに登録されたファイルの構成管理を行うファイル構成管理装置を備えるファイル構成管理システムにおいて、
   システム毎に含まれる全てのファイルについて記録したファイル情報テーブルと、派生関係にあるファイルについて派生元ファイルと派生先ファイルとの関係を記録した派生情報テーブルと、他システムに属するファイルが自システムのファイルと派生関係にある場合に、前記派生情報テーブルに基づいて他システムのファイルの更新情報を管理する更新情報テーブルを設け、
   前記ファイル構成管理装置は、システムを構成するファイルの状況を確認する際に、前記ファイル情報テーブルから該当ファイルを検索し、その更新情報を前記更新情報テーブルより検索することにより、派生関係にあるファイルに更新が発生したことを表示する機能を備えることを特徴とするファイル構成管理システム。
2. 請求項１において、前記派生関係にあるファイルの更新情報が未確認であると表示された場合に、外部から確認状態への変更を要求されると、前記更新情報テーブルの該当更新情報を確認済状態へと変更し、当該表示を停止することを特徴とするファイル構成管理システム。
3. 請求項１において、前記更新情報テーブルを与えられたシステム名称により参照し、確認フラグが未確認となっている更新情報について前記ファイル情報テーブルを検索し、該当するファイル情報とその未確認状態を示す警報を表示する機能を備えることを特徴とするファイル構成管理システム。
4. 請求項１において、前記更新情報テーブルを与えられたシステム名称により参照し、確認フラグが未確認となっている更新情報についてファイル管理テーブルを検索し、該当するファイル情報とその更新情報を全て表示する機能を有することを特徴とするファイル構成管理システム。
5. 請求項１において、与えられたシステム名称とファイル名称により前記更新情報テーブルを参照し、該当するファイル情報の更新情報を表示する機能を備えることを特徴とするファイル構成管理システム。
6. 請求項１において、前記派生情報テーブルは派生元ファイルと、当該派生元ファイルから直接派生を行った派生先ファイルとの関係を示す情報を記録し、派生を行った順序を記録可能にすることを特徴とするファイル構成管理システム。
7. ソフトウェアシステム毎に管理するシステムデータベースと、各システムに登録されたファイルの構成管理を行うファイル構成管理装置を備えるファイル構成管理システムにおいて、
   システム毎に含まれる全てのファイルについて記録したファイル情報テーブルと、派生関係にあるファイルについて派生元ファイルと派生先ファイルとの関係を記録した派生情報テーブルと、他システムに属するファイルが自システムのファイルと派生関係にある場合に、前記派生情報テーブルに基づいて他システムのファイルの更新情報を管理する更新情報テーブルを設け、
   前記ファイル構成管理装置は、ファイルデータ管理機能と派生情報管理機能を有し、ファイルリスト画面の表示要求を受けると前記派生情報管理機能が、ファイルデータ管理機能から表示対象となるファイルのＩＤと、システム名称を取得し、前記システム名称と一致する更新情報テーブルを参照してその確認フラグが確認済でない更新情報がある場合にはその要確認件数を表示することを特徴とするファイル構成管理システム。
8. 請求項７において、前記表示対象のファイルＩＤと前記更新情報テーブルのファイルＩＤを比較し、一致する更新情報がある場合は当該更新情報の確認フラグが確認済か否かを確認し、確認済でない場合に表示対象となるファイルに対して更新表示を要求することを特徴とするファイル構成管理システム。

Images