JP2021189879A - バージョン管理装置、バージョン管理方法及びソフトウェア開発装置 - Google Patents

Abstract

【課題】ソフトウェアの差分による判定だけではバージョン更新を誤判定する可能性があり、バージョンを正しく更新できないことがあった。【解決手段】バージョン管理装置３は、ソフトウェアファイル２５から、所定の命名規則で命名される識別子を用いて、一又は複数のソフトウェアユニットを抽出する抽出部３１と、バージョン更新条件３４１に、ソフトウェアファイル２５及びソフトウェアユニットの少なくとも一つの差分が該当することでソフトウェアファイル２５のバージョンが更新されたと判定した場合に、少なくとも一つ以上のバージョン判定条件３４２により判定した結果に基づいてソフトウェアファイル２５の更新可否を判定するバージョン更新判定部３２と、を備える。【選択図】図１

Description

本発明は、バージョン管理装置、バージョン管理方法及びソフトウェア開発装置に関する。

車両用組込みソフトウェアにおいて、ブロック線図の図示によるプログラミング（以下、「モデリング」と呼ぶ）は開発手法の一つとして一般的である。モデリングでは、作成したブロック線図プログラム（以下、「モデル」と呼ぶ）で要求機能をシミュレーションすることにより、下流工程での不具合検出による手戻りを減らし、開発工数を低減し、開発品質を向上させている。シミュレーションでは、ソフトウェアファイルを構成する最小管理単位であるソフトウェアユニットをシミュレーション範囲に応じて接続し、車両動作や制御要求を確認している。

ソフトウェア開発において、ソフトウェアの再利用を促進するためには、例えば、ソフトウェアから共通モジュールを抽出した最小単位での再利用が可能であるか、容易に再利用可能なソフトウェアを選択できるかが重要である。このため、ソフトウェアを構成管理（バージョン管理）することが必要であり、構成管理のヒューマンエラー防止、効率化等を目的として構成管理ツールを使用することが一般的に行われていた。

特許文献１には、ソフトウェアユニットのバージョン管理手法として、ソフトウェアユニットを識別する識別子を有し、ソフトウェアユニットのバージョン更新条件とソフトウェア差分によりバージョンを管理する手法が開示されている。

特開２０１９−１６８８８１号公報

モデリングで開発したファイルを監視する方法として、例えば、共有サーバ上でフォルダ管理したり、ファイル名にバージョン情報を付与して管理したりする方法がある。バージョンの採番方法として、例えば帳票による手作業での取得などがある。また、構成管理ツールを用いて、管理粒度として制御単位に分割したモデルをファイルごとにバージョン管理する方法がよく利用されており、ソフトウェアモジュールやユニットに通し番号や固有名称を付与し、管理する方法も利用されている。

しかし、車両制御装置のソフトウェアにおいて、開発者が開発したモデルには、類似処理が多くある。このため、特許文献１に開示された技術を用いてソフトウェアバージョンの更新可否を判断しても、ソフトウェア差分による判定だけではバージョン更新を誤判定する可能性があった。例えば、本来であればバージョンを更新すべき修正がソフトウェアファイルにされても、条件に合致しないとバージョンを正しく更新できない場合や、更新すべきでない修正がソフトウェアファイルにあった際に、バージョンが更新されることがあった。

本発明はこのような状況に鑑みて成されたものであり、ソフトウェアファイルのバージョンを正しく管理することを目的とする。

本発明に係るバージョン管理装置は、編集されたソフトウェアファイルから、所定の命名規則で命名される識別子を用いて、ソフトウェアファイルを構成する一又は複数のソフトウェアユニットを抽出する抽出部と、ソフトウェアファイル及びソフトウェアユニットのバージョンを更新する条件を定義するバージョン更新条件に、ソフトウェアファイル及びソフトウェアユニットの少なくとも一つの差分が該当することでソフトウェアファイルのバージョンが更新されたと判定した場合に、少なくとも一つ以上のバージョン判定条件により判定した結果に基づいてソフトウェアファイルのバージョンの更新可否を判定するバージョン更新判定部と、を備える。

本発明によれば、ソフトウェアファイルのバージョンを正しく管理できるようになる。
上記した以外の課題、構成及び効果は、以下の実施の形態の説明により明らかにされる。

本発明の第１の実施の形態に係るソフトウェア構成管理システムの構成図である。 本発明の第１の実施の形態に係る計算機のハードウェア構成例を示すブロック図である。 本発明の第１の実施の形態に係るソフトウェアファイルとソフトウェアユニットの関係性を示すブロック線図プログラム（モデル）の一例である。 本発明の第１の実施の形態に係るファイルデータベースの構成例を示す図である。 本発明の第１の実施の形態に係るソフトウェアバージョンの管理方法の例を示すフローチャートである。 本発明の第１の実施の形態に係るバージョン管理テーブルの一例を示す構成図である。 本発明の第１の実施の形態に係るバージョン更新条件の一例を示す図である。 本発明の第１の実施の形態に係るバージョン判定条件の説明図である。 本発明の第２の実施の形態に係るソフトウェア構成管理システムの構成図である。 本発明の第２の実施の形態に係るソフトウェア開発装置の全体構成例を示すブロック図である。

以下、本発明を実施するための形態について、添付図面を参照して説明する。本明細書及び図面において、実質的に同一の機能又は構成を有する構成要素については、同一の符号を付することにより重複する説明を省略する。

［第１の実施の形態］
図１は、第１の実施の形態に係るソフトウェア構成管理システム１の構成図である。
ソフトウェア構成管理システム１は、ソフトウェア開発装置２とバージョン管理装置３を備える。

＜ソフトウェア開発装置の構成例＞
始めに、ソフトウェア開発装置２の構成例について説明する。
ソフトウェア開発装置２は、編集部２１、表示部２２、操作部２３及び記憶部２４を備える。

編集部２１は、バージョン管理装置３にアクセスして、ファイルデータベース３５から所望のソフトウェアファイル２５を取得し、記憶部２４にソフトウェアファイル２５を保存する。そして、編集部２１は、操作部２３からの操作入力に従って、記憶部２４から読み出したソフトウェアファイル２５を編集する。編集部２１は、ソフトウェアファイル２５を編集後、編集後のソフトウェアファイル２５をバージョン管理装置３に戻す。

記憶部２４に保存されるソフトウェアファイル２５は、ファイルデータベース３５が管理する最小管理単位である複数のソフトウェアユニットＡ２５１〜Ｄ２５４を含んで構成される。編集部２１がソフトウェアファイル２５を編集する処理には、ソフトウェアユニットＡ２５１〜Ｄ２５４の少なくともいずれか一つを修正、削除、追加する変更、ソフトウェアファイル２５に新たなソフトウェアユニットを組み入れる変更等が含まれる。

表示部２２は、編集部２１が編集中のソフトウェアファイル２５に関する情報を表示する。ソフトウェアファイル２５に関する情報としては、ソフトウェアユニットＡ２５１〜Ｄ２５４の構成情報も含まれる。以下の説明でソフトウェアユニットＡ２５１〜Ｄ２５４を区別しない場合、「ソフトウェアユニット」と略記する。

操作部２３は、ユーザーがソフトウェアファイル２５を編集するための操作に用いられる。操作部２３から入力された操作によりソフトウェアファイル２５が編集され、編集中のソフトウェアファイル２５に関する情報が表示部２２に表示される。

＜バージョン管理装置の構成例＞
次に、バージョン管理装置３の構成例について説明する。
バージョン管理装置３は、抽出部３１、バージョン更新判定部３２、バージョン管理テーブル３３、条件管理テーブル３４及びファイルデータベース３５を備える。バージョン管理装置３は、ソフトウェアファイル２５の構成を管理する構成管理ツールの一例として用いられる。「ソフトウェアファイル２５の構成」には、ソフトウェアファイル２５のバージョン、ソフトウェアファイル２５に含まれるソフトウェアユニットの構成、及びソフトウェアユニットのバージョン等が含まれる。

抽出部（抽出部３１）は、ソフトウェア開発装置２の編集部２１から戻される、編集部２１により編集されたソフトウェアファイル（ソフトウェアファイル２５）から、所定の命名規則で命名される識別子を用いて、ソフトウェアファイル（ソフトウェアファイル２５）を構成する一又は複数のソフトウェアユニットを抽出する。そして、抽出部３１は、ソフトウェアファイル２５とソフトウェアユニットの各バージョンを管理するために、バージョン更新判定部３２を起動する。

始めに、バージョン更新判定部（バージョン更新判定部３２）は、ファイルデータベース（ファイルデータベース３５）に格納される編集前のソフトウェアファイル２５に対して、ソフトウェア開発装置２から戻された編集後のソフトウェアファイル２５の更新内容に基づき、バージョン更新の有無を判定する。この際、バージョン更新判定部３２は、ソフトウェアファイル（ソフトウェアファイル２５）及びソフトウェアユニットのバージョン（ソフトウェアユニットバージョン３３１）を更新する条件を定義するバージョン更新条件（バージョン更新条件３４１）に、ソフトウェアファイル（ソフトウェアファイル２５）及びソフトウェアユニットの少なくとも一つの差分が該当することでソフトウェアファイル（ソフトウェアファイル２５）のバージョンが更新されたか否かを判定する。そして、バージョン更新判定部（バージョン更新判定部３２）は、少なくとも一つの差分が該当することでソフトウェアファイル２５のバージョンが更新されたと判定した場合に、少なくとも一つ以上のバージョン判定条件（バージョン判定条件３４２）により判定した結果に基づいてソフトウェアファイル（ソフトウェアファイル２５）のバージョンの更新可否を判定する。

バージョン更新判定部３２により更新可否が判定されるバージョンには、ソフトウェアファイル２５のバージョン、ソフトウェアユニットごとのバージョンがある。
そして、バージョン管理部（バージョン管理テーブル３３）は、ソフトウェアファイル（ソフトウェアファイル２５）のバージョン、ソフトウェアユニットのバージョン（ソフトウェアユニットバージョン３３１）、及びソフトウェアユニットの構成要素から算出されたバージョン照合値（バージョン照合値３３２）を管理する。バージョン管理テーブル３３が管理するバージョン管理情報として、ソフトウェアユニットバージョン３３１及びバージョン照合値３３２が含まれる。

ソフトウェアユニットバージョン３３１は、例えば、ソフトウェアユニットのバージョンを表す。
バージョン照合値３３２は、バージョン更新判定部３２が、バージョン更新の可否を判定するために用いられる値であり、バージョン更新判定部３２により所定の演算処理で求められる。バージョン照合値３３２の詳細は、後述する図６にて説明する。
なお、バージョン管理テーブル３３の詳細な構成例は後述する図６に示すが、バージョン管理テーブル３３には、ソフトウェアファイル２５のバージョンも含まれる。

そこで、バージョン更新判定部３２は、条件管理テーブル３４に格納された各種の条件に基づいて、バージョン管理テーブル３３に格納されたソフトウェアユニットバージョン３３１の更新可否を判定する。

条件管理テーブル３４は、バージョン更新判定部３２が、抽出部３１によりソフトウェアファイル２５から抽出されたソフトウェアユニットに基づき、ソフトウェアファイル２５及びソフトウェアユニットのバージョン更新の可否を判定するために参照するテーブルである。条件管理テーブル３４には、バージョン更新条件３４１及びバージョン判定条件３４２が含まれる。

バージョン更新条件３４１は、バージョン更新判定部３２が、抽出部３１により抽出されたソフトウェアユニットの編集内容に基づいて、ソフトウェアファイル２５及びソフトウェアユニットのバージョンの更新可否を判定するために参照する情報である。後述する図７にて詳細を説明するが、バージョン更新条件（バージョン更新条件３４１）には、バージョン更新判定部（バージョン更新判定部３２）がバージョンの更新を可と判定するバージョン更新許可条件（バージョン更新許可条件群７１）と、バージョン更新判定部（バージョン更新判定部３２）がバージョンの更新を不可と判定するバージョン更新除外条件（バージョン更新除外条件群７０）とが含まれる。

バージョン判定条件３４２には、バージョン判定条件（１）３４３、バージョン判定条件（２）３４４が含まれる。バージョン判定条件（１）３４３、バージョン判定条件（２）３４４は、バージョン更新判定部３２が、バージョンの更新可否を判定した更新判定結果が妥当であるかを判定するために参照する情報である。条件管理テーブル３４には、２つのバージョン判定条件が設けられるが、３つ以上のバージョン判定条件が設けられることもある。

バージョン更新判定部３２は、始めに、バージョン更新条件３４１に基づき、ソフトウェアファイル２５とソフトウェアユニットのバージョンの更新有無を判定する。このため、バージョン更新判定部３２は、バージョン更新判定部（バージョン更新判定部３２）は、抽出部（抽出部３１）が抽出したソフトウェアユニットを含む編集前のソフトウェアファイル（ソフトウェアファイル２５）をファイルデータベース（ファイルデータベース３５）からから取得する。そして、バージョン更新判定部３２は、編集前のソフトウェアファイル２５と、編集後のソフトウェアファイル２５とを比較して差分をとり、この差分がバージョン更新条件３４１に該当するか否により、バージョン更新の有無を判定する。バージョン更新判定部３２がバージョンの更新が無いと判定した場合、ソフトウェアファイル２５のバージョンを更新することなく、ソフトウェア開発装置２で編集されたソフトウェアファイル２５をファイルデータベース３５に格納する。

一方、バージョン更新判定部３２は、バージョンの更新が有ると判定した場合、バージョン更新判定結果が正しいか否かを再判定する。そこで、バージョン更新判定部（バージョン更新判定部３２）は、バージョン判定条件（バージョン判定条件３４２）として規定される、抽出部（抽出部３１）が抽出したソフトウェアユニットの構成要素から算出したバージョン照合値と、バージョン管理部（バージョン管理テーブル３３）から読み出したバージョン照合値（バージョン照合値３３２）とを比較した比較結果に基づいてソフトウェアファイル（ソフトウェアファイル２５）のバージョンの更新可否を判定する。この際、バージョン更新判定部３２は、バージョン判定条件３４２（バージョン判定条件（１）３４３、（２）３４４を含む）に基づいて、抽出部３１が抽出したソフトウェアユニットから算出したバージョン照合値と、バージョン管理テーブル３３から読み出したバージョン照合値３３２とを比較し、再判定する。すなわち、バージョン更新判定部（バージョン更新判定部３２）は、ソフトウェアファイル（ソフトウェアファイル２５）又はソフトウェアユニットの変更内容が、バージョン判定条件（バージョン判定条件３４２）を満たすか否かを判定する。

そこで、バージョン更新判定部３２は、バージョン管理テーブル３３からバージョン管理情報として、ソフトウェアユニットバージョン３３１及びバージョン照合値３３２を取得する。この際、バージョン更新判定部（バージョン更新判定部３２）は、ファイルデータベース（ファイルデータベース３５）に格納されているソフトウェアユニットのバージョン（ソフトウェアユニットバージョン３３１）及びバージョン照合値（バージョン照合値３３２）をバージョン管理部（バージョン管理テーブル３３）から読み出す。

バージョン更新判定部（バージョン更新判定部３２）は、編集されたソフトウェアファイル（ソフトウェアファイル２５）が、バージョン更新条件（バージョン更新条件３４１）を満たし、かつバージョン判定条件（バージョン判定条件３４２）を満たした場合に、編集されたソフトウェアファイル（ソフトウェアファイル２５）又はソフトウェアユニットのバージョン（ソフトウェアユニットバージョン３３１）を更新する。そして、バージョン更新判定部（バージョン更新判定部３２）は、更新したバージョン、及び算出したバージョン照合値を、バージョン管理部（バージョン管理テーブル３３）に反映する。具体的には、バージョン更新判定部（バージョン更新判定部３２）は、バージョン判定条件（バージョン判定条件３４２）に基づき、ソフトウェアユニットから算出されたバージョン照合値と、バージョン管理部（バージョン管理テーブル３３）から読み出したバージョン照合値（バージョン照合値３３２）とが一致していれば、バージョン管理部（バージョン管理テーブル３３）に更新されたバージョンを反映せず、不一致であればバージョン管理部（バージョン管理テーブル３３）に更新されたバージョンを反映する。

ファイルデータベース３５は、様々なバージョンのソフトウェアファイル２５と、ソフトウェアファイル２５に所属するソフトウェアユニットを格納している。ファイルデータベース３５に格納されたソフトウェアファイル２５とソフトウェアユニットは、ソフトウェア開発装置２の編集部２１により適宜読み出される。バージョン更新判定部（バージョン更新判定部３２）は、バージョン更新の有無、及びバージョン更新の可否を判定した後、ソフトウェア開発装置２で編集されたソフトウェアファイル（ソフトウェアファイル２５）をファイルデータベース（ファイルデータベース３５）に格納する。すなわち、編集部２１により編集されたソフトウェアファイル２５とソフトウェアユニットが、抽出部３１、バージョン更新判定部３２を経てファイルデータベース３５に格納される。

＜計算機のハードウェア構成例＞
次に、ソフトウェア構成管理システム１の各装置を構成する計算機４０のハードウェア構成を説明する。
図２は、計算機４０のハードウェア構成例を示すブロック図である。計算機４０は、ソフトウェア開発装置２又はバージョン管理装置３として動作可能なコンピューターとして用いられるハードウェアの一例である。

計算機４０は、バス４４にそれぞれ接続されたＣＰＵ（Central Processing Unit）４１、ＲＯＭ（Read Only Memory）４２、及びＲＡＭ（Random Access Memory）４３を備える。さらに、計算機４０は、表示装置４５、入力装置４６、不揮発性ストレージ４７及びネットワークインターフェイス４８を備える。

ＣＰＵ４１は、本実施の形態に係る各機能を実現するソフトウェアのプログラムコードをＲＯＭ４２から読み出してＲＡＭ４３にロードし、実行する。ＲＡＭ４３には、ＣＰＵ４１の演算処理の途中で発生した変数やパラメーター等が一時的に書き込まれ、これらの変数やパラメーター等がＣＰＵ４１によって適宜読み出される。ただし、ＣＰＵ４１に代えてＭＰＵ（Micro Processing Unit）を用いてもよい。ソフトウェア開発装置２の場合、ＣＰＵ４１により編集部２１の機能が実現される。バージョン管理装置３の場合、ＣＰＵ４１により抽出部３１及びバージョン更新判定部３２の機能が実現される。

表示装置４５は、例えば、液晶ディスプレイモニターであり、計算機４０で行われる処理の結果等をユーザーに表示する。入力装置４６には、例えば、キーボード、マウス等が用いられ、ユーザーが所定の操作入力、指示を行うことが可能である。ソフトウェア開発装置２の場合、図１の表示部２２が表示装置４５に対応し、操作部２３が入力装置４６に対応する。バージョン管理装置３は、表示装置４５及び入力装置４６を備えなくてもよい。

不揮発性ストレージ４７としては、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フレキシブルディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ又は不揮発性のメモリ等が用いられる。この不揮発性ストレージ４７には、ＯＳ（Operating System）、各種のパラメーターの他に、計算機４０を機能させるためのプログラムが記録されている。ＲＯＭ４２及び不揮発性ストレージ４７は、ＣＰＵ４１が動作するために必要なプログラムやデータ等を記録しており、計算機４０によって実行されるプログラムを格納したコンピューター読取可能な非一過性の記憶媒体の一例として用いられる。ソフトウェア開発装置２の場合、記憶部２４が不揮発性ストレージ４７に構成される。バージョン管理装置３の場合、バージョン管理テーブル３３、条件管理テーブル３４及びファイルデータベース３５が不揮発性ストレージ４７に構成される。

ネットワークインターフェイス４８には、例えば、ＮＩＣ（Network Interface Card）等が用いられ、ＮＩＣの端子に接続されたＬＡＮ（Local Area Network）、専用線等を介して各種のデータを装置間で送受信することが可能である。ソフトウェア開発装置２とバージョン管理装置３には、それぞれ互いにデータを送受信可能とするネットワークインターフェイス４８が設けられる。編集部２１と、抽出部３１及びファイルデータベース３５との間で行われるデータの送受信は、各装置に設けられたネットワークインターフェイス４８を通じて行われる。

＜ソフトウェアファイルとソフトウェアユニットの関係性＞
図３は、ソフトウェアファイルとソフトウェアユニットの関係性を示すブロック線図プログラム（モデル）の一例である。ここでは、ソフトウェアファイル５０を表すモデルＡと、モデルＡに含まれる複数のソフトウェアユニットについて説明する。以下の説明では、モデルを用いて説明を進めていくが、モデル以外の他の形式で記述されたソフトウェアファイルにおいても本発明を適用可能である。

ここで、図１に示したソフトウェアファイル２５は、モデルＡのソフトウェア５０の構成が記述されたものである。また、図１に示したソフトウェアユニットは、それぞれ図３のモデルＡに含まれるソフトウェアユニット５１〜５４（識別子が、AAA_unit〜DDD_unit）に対応する。ソフトウェアユニット５１〜５４は、四則演算子や論理演算子を表すブロックの集合で構成されている。

モデルは、ソフトウェアユニット５１〜５４ごとに命名規則で付された名前を保有する。このため、各ソフトウェアユニット５１〜５４は、名前で識別される。図３に示すように各ソフトウェアユニット５１〜５４の末尾には、「_unit」が付されることで、ブロックの集合をソフトウェアユニットとした最小管理単位で管理される。今回の例では、命名規則により抽出する単位をソフトウェアファイルの最小管理単位であるソフトウェアユニットとしたが、他の管理単位（例えば、ファイルとユニットの間で、ユニットの構成を規定するブロック（不図示））に対しても本発明を適用可能である。

次に、ファイルデータベース３５の構成例について説明する。
図４は、ファイルデータベース３５の構成例を示す図である。

ファイルデータベース３５には、例えば、会社ごとに複数のリポジトリが設けられる。リポジトリとは、例えば、モデルの開発履歴を、モデルのバージョンごとに含むデータベースであり、モデルの開発単位で設けられる。

図４では、ファイルデータベース３５に、リポジトリＡ３５１と、リポジトリＢ３５２が存在しているとする。さらに、リポジトリＡ３５１と、リポジトリＢ３５２には、例えば、車種や車の構成要素（エンジン、ＥＣＵ、バッテリ、モーター）ごとに複数のディレクトリが設けられる。例えば、リポジトリＡ３５１には、ディレクトリ３５１ａとディレクトリ３５１ｂのように複数のディレクトリが存在する。

ディレクトリ３５１ａの構成を説明する。例えば、ディレクトリ３５１ａには、バージョンが異なる複数のモデルＡ及びモデルＢのソフトウェアファイル２５が格納されている。モデルＡの最新バージョンは“０１２”であり、旧バージョン（“０１１”など）も最新バージョンと同様にディレクトリ３５１ａに格納されている。モデルＢの最新バージョンは“００７”であり、旧バージョン（“００６”など）もディレクトリ３５１ａに格納されている。

なお、ディレクトリ３５１ｂ内にも、ディレクトリ３５１ａと同様に、所定のディレクトリ構成で複数のモデルが格納されている。また、リポジトリＢ３５２についても、ディレクトリは不図示とするが、バージョンが異なるモデルＣのソフトウェアファイル２５が格納される。

＜バージョン管理方法の説明＞
図５は、ソフトウェアバージョンの管理方法の例を示すフローチャートである。図５の左側には、ユーザーがソフトウェア開発装置２を操作してソフトウェアファイル２５を編集するユーザー動作の手順が示される。また、図５の右側には、バージョン管理装置３がソフトウェアファイル２５のバージョンを管理する手順が示される。

＜ＰＣを通じたユーザー動作＞
始めに、ユーザー（例えば、ソフトウェア開発者）がソフトウェア開発装置２を操作して行う、ユーザー動作及びソフトウェア開発装置２の処理について説明する。

ユーザーは、操作部２３（図１を参照）を通じてソフトウェアファイル２５を編集する（Ｓ１）。次に、ユーザーが、編集したソフトウェアファイル２５を、バージョン管理装置３のファイルデータベース３５に登録する依頼を行う（Ｓ２）。

ステップＳ２の依頼処理では、ユーザーがソフトウェアファイル２５のバージョンを、バージョン管理テーブル３３に反映するための依頼も兼ねている。そこで、ファイルデータベース３５へのソフトウェアファイル２５の登録依頼と、編集されたソフトウェアファイル２５とが、ソフトウェア開発装置２の編集部２１からバージョン管理装置３に送信される。

＜バージョン管理装置の動作＞
次に、バージョン管理装置３の動作例について説明する。
バージョン管理装置３の抽出部３１（図１を参照）は、ソフトウェア開発装置２の編集部２１からファイルデータベース３５へのソフトウェアファイル２５の登録依頼と、編集されたソフトウェアファイル２５とを受信する（Ｓ１１）。

次に、抽出部３１は、ソフトウェア開発装置２から受信したソフトウェアファイル２５から、予め設定した命名規則に基づいてソフトウェアユニットを抽出する（Ｓ１２）。そして、抽出部３１は、バージョン更新判定部３２を起動する（Ｓ１３）。

次に、バージョン更新判定部３２は、予め条件管理テーブル３４に登録されるバージョン更新条件３４１を取得する（Ｓ１４）。次に、バージョン更新判定部３２は、バージョン管理テーブル３３から、抽出部３１により抽出されたソフトウェアユニットに対応するソフトウェアユニットバージョン３３１を取得する（Ｓ１５）。バージョン更新判定部３２が取得するソフトウェアユニットバージョン３３１は、ソフトウェア開発装置２で編集されたソフトウェアファイル２５が含むソフトウェアユニットの各バージョンに該当する。

次に、バージョン更新判定部３２は、バージョン管理テーブル３３から読み出した情報（例えば、ソフトウェアユニットバージョン３３１）に基づいて、バージョンが付与されているソフトウェアファイル２５をファイルデータベース３５から取得する（Ｓ１６）。ただし、バージョン更新判定部３２は、ソフトウェア開発装置２によって編集されたソフトウェアファイル２５の名称に基づいて、ファイルデータベース３５から編集前のソフトウェアファイル２５を取得してもよい。

次に、バージョン更新判定部３２は、ソフトウェアファイル２５のバージョン更新判定を行う（Ｓ１７）。バージョン更新判定は、ステップＳ１１で抽出部３１が受信したソフトウェアファイル２５と、ステップＳ１６でバージョン更新判定部３２がファイルデータベース３５から取得したソフトウェアファイル２５との差分が、ステップＳ１５で取得したバージョン更新条件３４１に該当するか否かを判定する処理である。

バージョン更新判定部３２は、ソフトウェアファイル２５のバージョン更新なしと判定した場合、ステップＳ２１に処理を移す。

一方、バージョン更新判定部３２は、ソフトウェアファイル２５のバージョン更新ありと判定した場合、ステップＳ１７で行った差分手法の判定処理とは異なる少なくとも一つ以上の手法でソフトウェアファイル２５のバージョンを照合する（Ｓ１８）。この手法は、バージョン管理テーブル３３で保存しているバージョン照合値３３２と、バージョン判定条件３４３，３４４に基づいて算出した照合値とを比較することで行われる。ステップＳ１８で行われる照合は、照合時間や照合精度により、再照合に要する手法の数を変更することができる。ステップＳ１８で行われる照合処理の詳細については、図６以降で説明する。

ステップＳ１８の後、バージョン更新判定部３２は、ステップＳ１８で行われた照合処理の結果（「照合結果」と呼ぶ）を判定する（Ｓ１９）。バージョン更新判定部３２は、照合結果が、バージョン照合値３３２と一致したと判定した場合、バージョン更新なしと判定し、ステップＳ２１に処理を移す。

一方、バージョン更新判定部３２は、照合結果が、バージョン照合値３３２と不一致であると判定した場合、バージョン更新ありと判定する。そして、バージョン更新判定部３２は、ソフトウェアファイル２５のバージョンをバージョン管理テーブル３３に格納された情報から採番し、バージョン管理テーブル３３にソフトウェアファイル２５のバージョンを反映する（Ｓ２０）。さらに、バージョン更新判定部３２は、ユーザーにより編集されたソフトウェアユニットのバージョンを更新して、バージョン管理テーブル３３にソフトウェアユニットのバージョンを反映する

バージョン更新判定部３２は、バージョン管理テーブル３３へのバージョンの反映時に、ステップＳ１７，Ｓ１９で実施した判定結果についても反映する。そして、バージョン更新判定部３２は、判定結果が反映されたバージョン管理テーブル３３を次回の判定時に利用する。

最後に、バージョン更新判定部３２は、ステップＳ２で登録が依頼されたソフトウェアファイル２５をファイルデータベース３５に格納する（Ｓ２１）。この処理は、バージョン更新判定部３２が、ステップＳ１７でバージョン更新なしと判定した場合、ステップＳ１９で照合結果が、バージョン照合値３３２と一致したと判定した場合、又はステップＳ２０でソフトウェアファイル２５のバージョンを反映した場合のいずれかの後に行われる。

図５を参照して説明した各処理は、ユーザー動作とバージョン管理装置３の動作に分けられており、図５のステップＳ１１以降がバージョン管理装置３による自動化処理として記載されている。しかし、ユーザー動作とバージョン管理装置３の動作は、図５で分けられた処理に限定されるものではない。例えば、抽出部３１の機能をソフトウェア開発装置２が備えることで、ステップＳ１２のソフトウェアユニットの抽出処理をユーザー動作とし、抽出したソフトウェアユニットを含むソフトウェアファイルをソフトウェア開発装置２からバージョン管理装置３に送信するような処理として構成してもよい。このため、図５に示すフローチャートでは表されない他の処理についても、バージョン管理装置３で行われる自動化処理の一部として実施するように構成してもよい。

次に、図５のステップＳ１７〜Ｓ２０で行われる一連の処理について詳細な内容を説明する。
図６は、バージョン管理テーブル３３の一例を示す構成図である。図６では、ソフトウェアファイル２５として、モデルＡのバージョンを管理するバージョン管理テーブル３３を例示する。

バージョン管理テーブル３３は、ソフトウェアファイル２５の構成情報６１、バージョン情報６２で構成される。バージョン情報６２に含まれるソフトウェアユニットごとの同一列に、編集前のソフトウェアファイル２５に付された更新前のバージョン６４と、編集後のソフトウェアファイル２５に付された更新後のバージョン６３とが組になって格納される。例えば、構成情報６１に基づいて、モデルＡの管理者が「user1」であることが示される。更新前のソフトウェアファイル２５のバージョンを「ベースバージョン」と呼ぶ。図中では、「ベースバージョン」を「親」と言い換えて記載されている。そして、「親」の下には、「親」であるソフトウェアファイル２５が編集されたことで、ソフトウェアファイル２５の更新されたバージョンが格納される。モデルＡとして表されるソフトウェアファイル２５は、図５のステップＳ１９に示した処理により、照合値の照合結果が不一致と判定された場合に、バージョンが更新され、更新されたバージョンがバージョン管理テーブル３３に格納される。

バージョン情報６２の各行には、ソフトウェアユニットごとに、ソフトウェアユニット名、ソフトウェアユニットのバージョン、照合値１及び照合値２が組になって格納される。図６では、バージョン情報６２によりモデルＡを構成するソフトウェアユニット名が「AAA_unit」〜「GGG_unit」であることが示される。なお、図３では、モデルＡが「AAA_unit」〜「DDD_unit」のソフトウェアユニットを含んで構成されるものとして説明したが、図６では、モデルＡが「AAA_unit」〜「GGG_unit」のソフトウェアユニットを含んで構成されるものとする。

ここで、バージョン管理テーブル３３に更新されたバージョンが格納される様子について説明する。始めに、バージョン管理テーブル３３の列方向に注目する。
モデルＡのバージョンが、ベースバージョンから更新されると、更新されたバージョンがバージョン管理テーブル３３に反映される。例えば、１番目の列では、ベースバージョンにハイフン「−」が格納されている。この場合、新規作成されたソフトウェアファイルのバージョンが「０９Ａ」として、１番目の列に格納される。

また、２番目の列には、親であるソフトウェアファイルのベースバージョンが「０９Ａ」であり、編集されたソフトウェアファイル２５のバージョンが「１０Ａ」であることが示される。また、３番目の列には、親であるソフトウェアファイルのベースバージョンが「１０Ａ」であり、編集されたソフトウェアファイル２５のバージョンが「１０Ｂ」であることが示される。つまり、２番目の列で示される編集されたソフトウェアファイル２５が、３番目の列で示される編集されたソフトウェアファイル２５の親であることが分かる。

モデルＡのバージョンが更新されると、バージョン管理テーブル３３の右側に１列分の構成情報が追加される。そして、編集されたソフトウェアファイル２５の更新後のバージョンが、編集前のソフトウェアファイル２５の更新前のバージョンが格納された列と同じ列に格納される。モデルＡのバージョンが更新される度に、バージョン管理テーブル３３の右方向に列が追加される。図６では、ソフトウェアファイル２５のバージョンが更新された回数が７回あったことが示される。そして、バージョン管理テーブル３３の最も右側には、これからソフトウェアファイル２５のバージョンが更新されたときに追加される列が破線で表される。このようにバージョン管理テーブル３３は、ソフトウェアファイル２５の世代を管理している。

各ソフトウェアユニットには、バージョンが設定される。また、ソフトウェアユニットを構成するブロックに基づいて、照合値１及び照合値２が算出される。照合値１及び照合値２の算出は、バージョン更新判定部３２によって行われる。照合値は、構成要素の種類ごとの数、構成要素の数に重みを乗じて算出された要素値の和、及び要素値の積のうち、少なくとも一つを含む。

バージョン情報６２に示すように、ソフトウェアユニットごとに、ソフトウェアユニットのバージョン、照合値１及び照合値２が格納される。このため、バージョン更新判定部３２は、あるバージョンのソフトウェアファイルに所属するソフトウェアユニットのバージョン、照合値１及び照合値２を容易に取得できる。

例えば、「AAA_unit」の名称が付されたソフトウェアユニットに注目すると、図中に範囲６５で示すように、このソフトウェアユニットのバージョン（図１に示すソフトウェアユニットバージョン３３１に相当）が格納される。また、「BBB_unit」の名称が付されたソフトウェアユニットに注目すると、図中に範囲６６で示すように、このソフトウェアユニットの照合値１及び照合値２（図１に示すバージョン照合値３３２に相当）が格納される。例えば、ソフトウェアファイルのバージョンが、３番目の列に格納された「１０Ｂ」である場合、ソフトウェアユニット「DDD_unit」のバージョンは「０４０」であり、照合値１が「１７」、照合値２が「９９」である。

図７は、バージョン更新条件３４１の一例を示す図である。

バージョン更新条件３４１には、バージョン更新除外条件群７０と、バージョン更新許可条件群７１が含まれる。
バージョン更新判定部３２は、編集されたソフトウェアファイル２５又はソフトウェアユニットの変更内容がバージョン更新除外条件群７０に規定されるいずれかの条件に該当する場合には、編集されたソフトウェアファイル２５又はソフトウェアユニットのバージョン更新を不可（更新除外）と判定する。バージョン更新除外条件（バージョン更新除外条件群７０）は、ソフトウェアファイル（ソフトウェアファイル２５）の開閉、構成要素の位置の変更を含む。例えば、バージョン更新除外条件群７０には、バージョン更新除外条件１として規定されるソフトウェアファイル２５の開閉、バージョン更新除外条件２として規定される制御ブロック（ソフトウェアユニットの構成要素）の位置の変更の情報等がある。

バージョン更新判定部３２は、図５のステップＳ１７にてソフトウェアファイル２５のバージョン更新の有無を判定する際にバージョン更新条件３４１のバージョン更新除外条件群７０を参照する。そして、バージョン更新判定部３２は、ベースバージョンのソフトウェアファイルと、編集されたソフトウェアファイル２５との差分が、バージョン更新除外条件群７０に含まれる複数の更新除外条件（例えば、バージョン更新除外条件１，２，…）のいずれかにのみ該当する場合には、編集されたソフトウェアファイル２５のバージョン更新なしと判定する

一方、バージョン更新判定部３２は、編集されたソフトウェアファイル２５又はソフトウェアユニットの変更内容がバージョン更新許可条件群７１に規定される条件に該当する場合には、編集されたソフトウェアファイル２５又はソフトウェアユニットのバージョン更新ありと判定する。バージョン更新許可条件（バージョン更新許可条件群７１）は、構成要素の増減、構成要素の接続先の変更を含む。例えば、バージョン更新許可条件群７１には、バージョン更新許可条件１として規定される制御ブロックの増減、バージョン更新許可条件２として規定される制御ブロックの接続先の変更等がある。

バージョン更新判定部３２は、図５のステップＳ１７にてソフトウェアファイル２５のバージョン更新判定を行う際にバージョン更新条件３４１のバージョン更新許可条件群７１を参照する。そして、バージョン更新判定部３２は、ソフトウェアファイル２５のバージョン更新判定を行う際に、ベースバージョンのソフトウェアファイルと、編集されたソフトウェアファイル２５との差分が、バージョン更新許可条件群７１に含まれる複数の更新条件（例えば、バージョン更新許可条件１，２，…）のいずれかに該当する場合には、編集されたソフトウェアファイル２５のバージョンを更新する判定結果を得る。つまり、バージョン更新判定部３２は、ソフトウェアファイルの差分が、上述した更新除外条件に該当しても、更新条件に該当すれば、編集されたソフトウェアファイル２５のバージョンを更新する判定結果を得る。

図８は、バージョン判定条件の説明図である。

バージョン更新判定部３２は、図５のステップＳ１７でソフトウェアファイル２５のバージョン更新ありと判定した場合に、ステップＳ１８での別手法での照合、すなわちステップＳ１９での照合結果の判定を行う。図８では、識別子が「AAA_unit」であるソフトウェアユニット５１（図３を参照）に注目して、照合値１及び照合値２を説明する。ここでは、照合値１を用いた照合を第１の別手法での照合、照合値２を用いた照合を第２の別手法での照合と呼ぶ

ソフトウェアユニット５１の構成を管理するユニット構成管理テーブル９０は、例えば、バージョン更新判定部３２が図５のステップＳ１８，Ｓ１９での照合を行うたびにＲＡＭ４３に作成される。ユニット構成管理テーブル９０は、要素名、重み、要素数及び要素値の各フィールドで構成される。各要素は、図８の上側に示すようにブロック線図で表される。

要素名フィールドには、ソフトウェアユニットを構成する要素の名称が格納される。ソフトウェアユニットは、例えば、入力、出力、加算、減算、乗算、除算、ｉｆ判定、ゲイン、単位変換、…、フィードバックの要素のいずれかによって構成される。ソフトウェアユニットの機能によって、構成される要素数が異なる。

重みフィールドには、ソフトウェアユニットを構成する各要素に対応する重みが格納されている。本実施の形態では、要素ごとに異なる重みが設定される。ただし、複数の要素で同じ値の重みが設定されてもよい。
要素数フィールドには、ソフトウェアユニットを構成する要素の数が、要素名ごとに格納される。例えば、ソフトウェアユニット５１の入力が「２」、出力が「１」であることが示される。
要素値フィールドには、要素名ごとに設定される重みを要素数に掛けた値が要素値として格納される。

そして、ユニット構成管理テーブル９０の下部には、入出力数９３、要素和９４、要素積９５の項目が設けられる。入出力数９３、要素和９４、要素積９５は、図１に示したバージョン照合値３３２の一例である。

入出力数９３の項目には、ソフトウェアユニット５１の入出力数（Ｉ／Ｆ数）が格納される。上述したように、入力が「２」、出力が「１」であるので、入出力数は「３」である。
要素和９４の項目には、各要素９１に重み９２を加味した要素値の和が格納される。例えば、２＋２＋３＋０＋…＋２０＝４９が要素和となる。
要素積９５の項目には、各要素９１に重み９２を加味した要素値の積が格納される。ただし、要素積の演算に際して要素値が「０」は除かれる。例えば、２×２×３×５×８×９×２０＝８６４００が要素積となる。

上述した図６では、照合値１の例として要素和が用いられ、照合値２の例として要素積が用いられる。バージョン更新判定部３２は、抽出部３１から抽出されたソフトウェアユニット５１から算出した要素和及び要素積のうちの少なくとも一つと、ソフトウェアユニットバージョン３３１から読み出したソフトウェアユニット５１に対応する照合値とを比較する。ソフトウェアユニット５１のバージョン更新ありに該当する変更があれば、要素和及び要素積のうちの少なくとも一つが異なる。このように照合値が異なっていれば、バージョン更新判定部３２は、バージョン更新可と判定し、編集されたソフトウェアユニット５１及びソフトウェアファイル２５に対して適切なバージョンを付与する。このようにバージョン更新判定部３２が複数の照合値（観点）を比較することで、バージョン更新結果を高精度に判定することが可能となる。

なお、入出力数が、照合値３（不図示）として用いられてもよい。この場合、図６に示したバージョン管理テーブル３３には、照合値３を格納する行がソフトウェアファイルユニットごとに設けられる。そして、バージョン更新判定部３２は、抽出部３１から抽出されたソフトウェアユニット５１から算出した入出力数、要素和及び要素積のうちの少なくとも一つと、ソフトウェアユニットバージョン３３１から読み出したソフトウェアユニット５１に対応する照合値とを比較する。以降の処理については、照合値１，２の場合と同様である。

以上説明した第１の実施の形態に係るバージョン管理装置３では、ソフトウェア開発装置２によってソフトウェアファイル２５が編集されると、バージョン更新の有無を判定する。そして、バージョン更新判定部３２がバージョン更新ありと判定した場合に、バージョン更新の有無を判定した方法とは別の手法で編集内容を確認する。この際、バージョン更新判定部３２は、編集されたソフトウェアファイル２５から算出した照合値と、バージョン管理テーブル３３から読み出したバージョン照合値３３２とを比較し、照合値が一致すればバージョンを更新せず、照合値が不一致であればバージョンを更新する。

このようにバージョン更新判定部３２は、ソフトウェアファイル２５を構成する最小管理単位（例えば、ソフトウェアユニット）のバージョン更新の可否を正しく判定できる。このため、ソフトウェアユニットの構成管理やソフトウェア部品管理の精度が向上し、ソフトウェアファイル２５の再利用が容易となる。また、ソフトウェアファイル２５に対するわずかな変更に対して全てバージョンが更新されるのでなく、多数のバージョンが増えることを防ぐことが可能となる。

［第２の実施の形態］
次に、本発明の第２の実施の形態に係るソフトウェア構成管理システムについて、図９を参照して説明する。
図９は、ソフトウェア構成管理システム１Ａの全体構成例を示すブロック図である。

ソフトウェア構成管理システム１Ａは、ソフトウェア開発装置２、バージョン管理装置３Ａに加えてファイルサーバ１００を備える。
バージョン管理装置３Ａは、第１の実施の形態に係るバージョン管理装置３からファイルデータベース３５を除いた構成としている。
ファイルサーバ（ファイルサーバ１００）は、ファイルデータベース（ファイルデータベース１０１）を備える。ファイルデータベース１０１には、第１の実施の形態に係るファイルデータベース３５と同様にソフトウェアファイル２５を格納する。

ソフトウェア開発装置２は、ファイルサーバ１００にアクセスして、ファイルデータベース１０１に格納されているソフトウェアファイル２５を取得し、編集部２１がソフトウェアファイル２５を編集する。

バージョン管理装置３Ａのバージョン更新判定部（バージョン更新判定部３２）は、抽出部３１がソフトウェアファイル２５からソフトウェアユニットを抽出した後、バージョン更新の判定に際して、ファイルサーバ（ファイルサーバ１００）にアクセスする。そして、バージョン更新判定部（バージョン更新判定部３２）は、ファイルサーバ（ファイルサーバ１００）から、抽出部（抽出部３１）が抽出したソフトウェアユニットを含むソフトウェアファイル（ソフトウェアファイル２５）を取得する。その後、バージョン更新判定部３２は、図５のステップＳ１７〜Ｓ２０の処理を経て、バージョン更新の有無の判定、バージョン照合の可否を判定する。バージョン更新判定部３２は、更新したバージョンをバージョン管理テーブル３３に反映した後、編集されたソフトウェアファイル２５をファイルサーバ１００に出力する。ファイルサーバ１００のファイルデータベース１０１には、編集されたソフトウェアファイル２５が格納される。

以上説明した第２の実施の形態に係るソフトウェア構成管理システム１Ａでは、ファイルサーバ１００のファイルデータベース１０１に編集部２１及びバージョン更新判定部３２がそれぞれアクセスしてソフトウェアファイル２５を取得する構成とした。このような構成であっても、バージョン更新判定部３２は、編集されたソフトウェアファイル２５のバージョン更新の可否を正しく判定することができる。

［第３の実施の形態］
次に、本発明の第３の実施の形態に係るソフトウェア開発装置について、図１０を参照して説明する。
図１０は、ソフトウェア開発装置２Ａの全体構成例を示すブロック図である。

ソフトウェア開発装置２Ａは、上述した第１の実施の形態に係るソフトウェア開発装置２とバージョン管理装置３とを一つにまとめたものである。
このソフトウェア開発装置２Ａは、第１の実施の形態に係るソフトウェア開発装置２が有する編集部２１、表示部２２、操作部２３及び記憶部２４に加えて、抽出部２６、バージョン更新判定部２７、バージョン管理テーブル２８、条件管理テーブル２９及びファイルデータベース３０を備える。ソフトウェア開発装置２Ａが有する抽出部２６、バージョン更新判定部２７、バージョン管理テーブル２８、条件管理テーブル２９及びファイルデータベース３０の各機能は、第１の実施の形態に係るバージョン管理装置３が有する抽出部３１、バージョン更新判定部３２、バージョン管理テーブル３３、条件管理テーブル３４及びファイルデータベース３５の各機能と同様である。このため、バージョン更新判定部２７は、ファイルデータベース３０から、抽出部２６が抽出したソフトウェアユニットを含むソフトウェアファイル２５を取得することができる。また、バージョン更新判定部２７は、編集されたソフトウェアファイル２５を、バージョンの更新判定後に、ファイルデータベース１０１に格納することができる。

以上説明した第３の実施の形態に係るソフトウェア開発装置２Ａは、ファイルデータベース３０を備えているので、スタンドアロンで用いることが可能である。このため、編集部２１は、ネットワークを介さなくても、ソフトウェアファイル２５をファイルデータベース３０から取得したり、編集したソフトウェアファイル２５を抽出部２６に出力して、バージョン更新判定部２７にバージョンの更新可否を判定させたりすることができる。このため、秘密性が高いソフトウェアファイル２５が情報漏洩するリスクを避けることが可能となる。

なお、本発明は上述した各実施の形態に限られるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りその他種々の応用例、変形例を取り得ることは勿論である。
例えば、上述した各実施の形態は本発明を分かりやすく説明するために装置及びシステムの構成を詳細かつ具体的に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されない。また、ここで説明した実施の形態の構成の一部を他の実施の形態の構成に置き換えることは可能であり、さらにはある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加、削除、置換をすることも可能である。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１…ソフトウェア構成管理システム、２…ソフトウェア開発装置、３…バージョン管理装置、２１…編集部、２５…ソフトウェアファイル、３１…抽出部、３２…バージョン更新判定部、３３…バージョン管理テーブル、３４…条件管理テーブル、３５…ファイルデータベース、５０…ソフトウェア、５１…ソフトウェアユニット、６１…構成情報、６２…バージョン情報、７０…バージョン更新除外条件群、７１…バージョン更新条件群、９０…ユニット構成管理テーブル

Claims (13)

1. 編集されたソフトウェアファイルから、所定の命名規則で命名される識別子を用いて、前記ソフトウェアファイルを構成する一又は複数のソフトウェアユニットを抽出する抽出部と、
   前記ソフトウェアファイル及び前記ソフトウェアユニットのバージョンを更新する条件を定義するバージョン更新条件に、前記ソフトウェアファイル及び前記ソフトウェアユニットの少なくとも一つの差分が該当することで前記ソフトウェアファイルのバージョンが更新されたと判定した場合に、少なくとも一つ以上のバージョン判定条件により判定した結果に基づいて前記ソフトウェアファイルのバージョンの更新可否を判定するバージョン更新判定部と、を備える
   バージョン管理装置。
2. 前記ソフトウェアファイルのバージョン、前記ソフトウェアユニットのバージョン、及び前記ソフトウェアユニットの構成要素から算出されたバージョン照合値を管理するバージョン管理部を備え、
   前記バージョン更新判定部は、前記バージョン判定条件として規定される、前記抽出部が抽出した前記ソフトウェアユニットの構成要素から算出したバージョン照合値と、前記バージョン管理部から読み出した前記バージョン照合値とを比較した比較結果に基づいて前記ソフトウェアファイルのバージョンの更新可否を判定する
   請求項１に記載のバージョン管理装置。
3. 前記バージョン更新判定部は、編集された前記ソフトウェアファイルが、前記バージョン更新条件を満たし、かつ前記バージョン判定条件を満たした場合に、編集された前記ソフトウェアファイル又は前記ソフトウェアユニットのバージョンを更新し、更新したバージョン、及び算出したバージョン照合値を、前記バージョン管理部に反映する
   請求項２に記載のバージョン管理装置。
4. 前記バージョン更新判定部は、ファイルデータベースに格納されている前記ソフトウェアユニットの前記バージョン及び前記バージョン照合値を前記バージョン管理部から読み出し、前記ソフトウェアファイル又は前記ソフトウェアユニットの変更内容が、前記バージョン判定条件を満たすか否かを判定する
   請求項３に記載のバージョン管理装置。
5. 前記バージョン更新条件には、前記バージョン更新判定部が前記バージョンの更新を可と判定するバージョン更新許可条件と、前記バージョン更新判定部が前記バージョンの更新を不可と判定するバージョン更新除外条件とが含まれる
   請求項４に記載のバージョン管理装置。
6. 前記バージョン更新許可条件は、前記構成要素の増減、前記構成要素の接続先の変更を含む
   前記バージョン更新除外条件は、前記ソフトウェアファイルの開閉、前記構成要素の位置の変更を含む
   請求項５に記載のバージョン管理装置。
7. 前記バージョン更新判定部は、前記バージョン判定条件に基づき、前記ソフトウェアユニットから算出されたバージョン照合値と、前記バージョン管理部から読み出した前記バージョン照合値とが一致していれば、前記バージョン管理部に更新されたバージョンを反映せず、不一致であれば前記バージョン管理部に更新されたバージョンを反映する
   請求項６に記載のバージョン管理装置。
8. 前記照合値は、前記構成要素の種類ごとの数、前記構成要素の数に重みを乗じて算出された要素値の和、及び前記要素値の積のうち、少なくとも一つを含む
   請求項７に記載のバージョン管理装置。
9. 前記ファイルデータベースを備え、
   前記バージョン更新判定部は、前記抽出部が抽出した前記ソフトウェアユニットを含む編集前の前記ソフトウェアファイルを前記ファイルデータベースから取得する
   請求項５に記載のバージョン管理装置。
10. 前記バージョン更新判定部は、前記ファイルデータベースを備えるファイルサーバにアクセスし、前記ファイルサーバから、前記抽出部が抽出した前記ソフトウェアユニットを含む前記ソフトウェアファイルを取得する
    請求項５に記載のバージョン管理装置。
11. 前記バージョン更新判定部は、編集された前記ソフトウェアファイルを前記ファイルデータベースに格納する
    請求項９又は１０に記載のバージョン管理装置。
12. 編集されたソフトウェアファイルから、所定の命名規則で命名される識別子を用いて、前記ソフトウェアファイルを構成する一又は複数のソフトウェアユニットを抽出するステップと、
    前記ソフトウェアファイル及び前記ソフトウェアユニットのバージョンを更新する条件を定義するバージョン更新条件に、前記ソフトウェアファイル及び前記ソフトウェアユニットの少なくとも一つの差分が該当するかを判定するステップと、
    バージョン更新条件に、前記ソフトウェアファイル及び前記ソフトウェアユニットの少なくとも一つの差分が該当することで前記ソフトウェアファイルのバージョンが更新されたと判定した場合に、少なくとも一つ以上のバージョン判定条件により判定した結果に基づいて前記ソフトウェアファイルのバージョンの更新可否を判定するステップと、を含む
    バージョン管理方法。
13. 所定の命名規則で命名される識別子が付与された、一又は複数のソフトウェアユニットにより構成されるソフトウェアファイルを格納するファイルデータベースと、
    前記ファイルデータベースから読み出した前記ソフトウェアファイル、又は前記ソフトウェアユニットを編集する編集部と、
    前記編集部により編集されたソフトウェアファイルから前記識別子を用いて、前記ソフトウェアユニットを抽出する抽出部と、
    前記ソフトウェアファイル及び前記ソフトウェアユニットのバージョンを更新する条件を定義するバージョン更新条件に、前記ソフトウェアファイル及び前記ソフトウェアユニットの少なくとも一つの差分が該当することで前記ソフトウェアファイルのバージョンが更新されたと判定した場合に、少なくとも一つ以上のバージョン判定条件により判定した結果に基づいて前記ソフトウェアファイルのバージョンの更新可否を判定するバージョン更新判定部と、を備える
    ソフトウェア開発装置。

Images