JPH08329138A - エンジニアリング支援システム - Google Patents

Abstract

(57)【要約】 【目的】 異なる部門ごとの円滑なコミュニケーション
を確保するとともに、また、必要なデータの適切な見極
めのできるエンジニアリング支援システムを提供する 【構成】 本発明は、エンジニアリング業務に関するデ
ータを一元的に記憶するデータベースと、このデータベ
ースに対してアクセスを行うユーザが、部門内に所属す
るか部門外に所属するかを識別するユーザ識別部２と、
このユーザ識別部３によって識別されたユーザが部門内
である場合に部門内ビューファイルを表示し、部門外で
ある場合に部門外ビューファイルを表示する表示部２
と、部門内のユーザがデータベースの内容を変更するご
とに該変更回数を記録し、また、前記データベースの内
容を確定した場合にその確定事実を記録し、これを部門
外のユーザに対して適宜表示する手段とからなるエンジ
ニアリング支援システムである。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、エンジニアリング支
援システムに関するものである。

【０００２】

【従来の技術】火力発電プラントのような大規模なシス
テムを対象としたエンジニアリング業務（設計、開発、
保守、管理業務など）においては、エンジニアリングの
フェーズごとに異なる部門で作業が進められる。一般的
に、それぞれのエンジニアリングで使用されるデータ
は、相互に関連が深く、上流のフェーズから下流のフェ
ーズに、さまざまな情報を付加しながら流されていく。

【０００３】ところで、このようなデータは、上流のフ
ェーズにおいて完全に定まってから下流のフェーズへ
と、移るとは限らない。つまり、ある一定の段階は、コ
ンカレントにエンジニアリングを行うことになる。この
ため、ある期間においては分岐したエンジニアリングを
許容し、それぞれのフェーズにおけるエンジニアリング
間のコミュニケーションを確保し、最終的に整合性の保
証された製品を作成することを支援することが必要であ
る。そこで、従来より、このような支援の一つとして、
エンジニアリングで使用するデータの一元管理技術が提
案されている。

【０００４】

【発明が解決しようとする課題】しかしながら、従来の
一元管理技術においては、以下のような問題があった。
すなわち、異なる部門に亘るエンジニアリングを行う場
合、データは部門内において変更が発生するとともに、
ある程度の段階で部門外に知らせる必要がある。このデ
ータは、必要な形式に加工され、他の部門で使用される
ため、部門外部に提出したリビジョンの管理と部門内部
のリビジョン管理とを区別して管理する必要があった。

【０００５】また、一般的に、それぞれの部門ごとにコ
ンカレントにデータベースの内容が変更される。したが
って、部門外でコンカレントにエンジニアリングを行っ
ているユーザーは、その変更があったことを知らず、ま
た、どのデータが信頼できるかわからないので、データ
が公開された時点で、作業の後戻りをしなければならな
いという問題があった。

【０００６】さらに、エンジニアリング業務では、デー
タ量が非常に膨大で、かつ、内容変更も頻繁に発生する
ので、管理を効率になされることが切望されていた。そ
こで、本発明は、かかる問題を解決するために、異なる
部門ごとの円滑なコミュニケーションを確保するととも
に、また、必要なデータの適切な見極めのできるエンジ
ニアリング支援システムを提供するものである。

【０００７】

【課題を解決するための手段】本発明は、複数の部門に
亘ってエンジニアリング業務をコンカレントに行う際の
エンジニアリング支援システムにおいて、前記エンジニ
アリング業務に関するデータを一元的に記憶するデータ
ベースに対しアクセスを行うユーザが所属する部門を識
別し、該部門を特定するユーザ識別部と、このユーザ識
別部によって特定された前記ユーザの所属する部門に対
応するビューファイルを表示する表示部と、一の部門に
所属するユーザによる前記データベースに対するアクセ
スに基づく前記データベースの内容の変更状況を他の部
門に所属するユーザに知らせるための手段とを具備した
エンジニアリング支援システムである。

【０００８】また、本発明は、複数の部門に亘ってエン
ジニアリング業務をコンカレントに行う際のエンジニア
リング支援システムにおいて、前記エンジニアリング業
務に関するデータを一元的に記憶するデータベースと、
このデータベースに対してアクセスを行うユーザの所属
する部門を識別し、該部門を特定するユーザ識別部と、
このユーザ識別部によって特定された前記ユーザの所属
する部門に対応するビューファイルを表示する表示部
と、一の部門に所属するユーザが、前記データベースの
内容を変更するごとに該変更回数を記録する手段と、前
記一の部門に所属するユーザが、前記データベースの内
容を確定した場合に、その確定事実を記録する手段と、
他の部門に所属するユーザに対応するビューファイルが
前記表示部により表示される際に、前記変更回数及び前
記確定事実を表示する手段を具備したエンジニアリング
支援システムである。

【０００９】さらに、本発明は、複数の部門に亘ってエ
ンジニアリング業務をコンカレントに行う際のエンジニ
アリング支援システムにおいて、前記エンジニアリング
業務に関するデータを一元的に記憶するデータベース
と、このデータベースに対してアクセスを行うユーザ
が、部門内に所属するユーザであるか部門外に所属する
ユーザであるかを識別するユーザ識別部と、このユーザ
識別部によって識別された前記ユーザが部門内に所属す
るユーザである場合に、部門内ビューファイルを表示す
る手段と、前記ユーザ識別部によって識別された前記ユ
ーザが部門外に所属するユーザである場合に、部門外ビ
ューファイルを表示する手段と、前記部門内に所属する
ユーザが、前記データベースの内容に対して編集を行
い、該内容が確定した場合には、該確定事実を前記デー
タベースに記録するデータ編集部と、このデータ編集部
により前記データベースの内容を変更するごとに該変更
回数を記録する手段とを具備し、前記部門外に所属する
ユーザが、前記表示部により前記部門外ビューファイル
を参照する場合に、前記変更回数及び前記確定事実が視
認することができるようにしたエンジニアリング支援シ
ステムである。

【００１０】

【作用】本発明によれば、多次元でリビジョン管理を行
いローカルリビジョンを部門外から参照できないように
することで、同一データベース上で複数の部門がコンカ
レントにエンジニアリング業務の開発を進めることがで
きる。また、公的なリビジョンによって複数に亘る各部
門の進捗状況を揃えることができる。

【００１１】また、公的なリビジョン（公開リビジョ
ン）を更新する際に、変更したデータがあるかどうかを
他の部門のユーザに知らせる。すなわち、部門外のユー
ザは、部門外ファイルを参照する際に、そのデータの変
更回数が表示されるため、そのデータの信頼性を伺うこ
とができ、データの信頼性の高いものから使用すること
ができるようになる。また、部門内のユーザによるデー
タベースの内容の確定は、その事実がデータベースに記
録され、部門外のユーザに示されるため、そのような内
容が確定したデータを容易に特定することができ、これ
によって部門間のコミュニケーションが円滑になり、エ
ンジニアリング業務の開発効率を向上させることができ
るようになる。

【００１２】

【実施例】以下、図面を参照しながら本発明の一実施例
について説明する。図１は、本発明のエンジニアリング
支援システムの構成を示す図である。同図において、ユ
ーザは、入力部（図示せず）からデータベース１をアク
セスすることにより、それを後述するビューファイルと
して表示部２から見ることができる。この場合、アクセ
スしたユーザが部門内に所属するユーザであるか、部門
外に所属するユーザであるかによって、ビューファイル
の内容は異なるものとなる。このユーザの識別は、ユー
ザ識別部３によって行われる。すなわち、ユーザ識別部
３は、部門ファイル１１を参照し、比較照合する。この
識別は、ユーザの最初の利用時に識別することで足り
る。

【００１３】図２は、部門ファイル１１に格納されてい
る部門データの一例を示す図である。同図に示すよう
に、部門データは、ユーザ名と所属、またその所属がＤ
Ｂに対して部門内であるか部門外であるかが記録されて
いる。したがって、“satou ”及び“yamada”は部門
Ａ、“suzuki”は部門Ｂ、“tanaka”は部門Ｃに所属す
るものとして識別されることになる。

【００１４】図１に戻り、このユーザ識別部３が、アク
セスしたユーザが部門内に所属すると判断した場合、部
門内ＤＢビュー作成部４ａにその旨通知する。部門内Ｄ
Ｂビュー作成部４ａは、カレントＤＢ１２を参照し、部
門内に所属するユーザのみが参照することのできる専用
のビュー（部門内ビュー）を作成する。ユーザは、これ
を表示部２から見ることができる。図３（ａ）は、部門
内ＤＢビューの一例を示す図である。

【００１５】部門内指定ファイル作成部５ａは、部門内
に所属するユーザが指定した時点におけるデータの内容
を履歴ＤＢ１３に記録された履歴内容を辿り、その履歴
内容に従ってカレントＤＢ１２の内容を参照しつつ、部
門内指定ファイルを作成する。そして、この部門内指定
ファイルに従って、部門内ＤＢビュー作成部４は、指定
した時点におけるビューを作成する。図４（ａ）は、カ
レントＤＢ１２の一例を示す図であり、図４（ｂ）は、
履歴ＤＢ１３の一例を示す図である。

【００１６】部門内差分確認部６ａでは、異なる時点ご
とにデータの差分を計算する。また、履歴ＤＢ１３の付
加情報によっては、差分の意味内容等をユーザに通知す
る。本実施例では、「コメント」を差分の意味内容とし
ている。

【００１７】部門内のユーザは、表示部２上に表示され
た部門内ビューに基づいて、カレントＤＢ１２に格納さ
れているデータの変更、レコードの追加、レコードの削
除等を、データ編集部７を用いて行うことができる。デ
ータの変更があった場合、データ編集部７はアクセスフ
ァイル１４に記録する。また、ユーザは、これ以上変更
することはないと判断したレコードに対して、ビューの
信頼度フィールドに確定したことを記録すべく、その旨
をデータ編集部７から与える。これを受けて、データ編
集部７は、アクセスファイルに対して、確定レコードの
ユニークＮｏを登録する。

【００１８】図５は、アクセスファイルの一例を示す図
である。アクセスファイル１４は、部門外に所属するユ
ーザがデータベースにアクセスするごとに使用するファ
イルであって、どの部門が履歴ＤＢ１３のどこまでを参
照したか等、ＤＢビューを作成するために必要なデータ
を記録している。本実施例では、リビジョンごとにレコ
ードをもち、確定レコードのユニークＮｏ、最新の履歴
日付、各レコードの変更回数を記録する。具体的には、 リビジョン＝カレントＤＢのリビジョン 確定レコード＝ユニークＮｏ 履歴日付＝最新の履歴日付 （ＧＩＤ，変更回数）＝（レコードＮＯ，該リビジョン
での変更回数） で構成されている。

【００１９】リビジョン承認部８は、部門外からアクセ
ス可能な公式リビジョン（公開リビジョン）の更新を行
うためのものである。この更新は、部門内のユーザのみ
によって行うことができる。リビジョン承認は、ＤＢの
属性「リビジョン」の値をすべて更新する。本実施例で
は、現在のリビジョン値に“１”を加えている。

【００２０】このリビジョン承認の際においては、カレ
ントＤＢ１２のデータ内容によって作成された部門外に
所属するユーザ用のビュー情報が格納されている。この
ビュー情報は、次の公開リビジョンが更新されるまで、
部門外ＤＢビューを作成するために用いられる。

【００２１】一方、ユーザ識別部３が、アクセスしたユ
ーザが部門外に所属すると判断した場合、部門外ＤＢビ
ュー作成部４ｂにその旨通知する。部門外ＤＢビュー作
成部４ｂは、カレントＤＢ１２を参照し、部門外に所属
するユーザのみが参照することのできる専用のビュー
（部門外ビュー）を作成する。ユーザは、上述して部門
内ビューの場合と同様に、これを表示部２から見ること
ができる。

【００２２】部門外指定ファイル作成部５ｂは、部門外
に所属するユーザがアクセスした時点におけるデータの
内容を履歴ＤＢ１３に記録された履歴内容を辿り、その
履歴内容に基づいてカレントＤＢ１２の内容を参照し
て、部門外指定ファイルを作成する。

【００２３】部門外差分確認部６ｂは、異なる公式リビ
ジョンの間で、その差分を求める。また、履歴ＤＢ１３
の付加情報によっては、差分の意味内容等をユーザに通
知する。本実施例では、「コメント」を差分の意味内容
としている。

【００２４】次に、各機能実現手段の詳細について説明
する。図６は、部門外ＤＢビュー作成５ｂの動作処理を
説明するための図である。ユーザが、データベースにア
クセスすると、アクセスファイルから得られる情報を、
ビューファイルに付加して部門外ビューを作成して、こ
れを表示部２上に表示する。ユーザ識別３により、デー
タベースにアクセスしたユーザが部門外に所属すると判
断した場合、以下のように動作する Ｓｔｅｐ１：信頼度の更新 ユーザとリビジョンが一致したアクセスファイルであっ
て、変更のあったＧＩＤとその変更回数とを参照するこ
とによって、ビューファイルの信頼度を更新する。本実
施例の場合、変更回数の値を信頼度とする。なお、（Ｇ
ＩＤ，変更回数）で示される「変更回数」になく、か
つ、確定レコードに記録されているユニークＮｏを持つ
ものに対しては、そのレコードの信頼度に“−１”を与
えておく。すなわち、本実施例では信頼度の“−１”は
これ以上変更することのないレコードの意味を持つ。

【００２５】Ｓｔｅｐ２：初アクセス 初めてアクセスされたかどうかを判断する。Ｓｔｅｐ１
で参照している「アクセスファイルのアクセス回数＝
０」である場合には、Ｓｔｅｐ３以降を実行する。「ア
クセスファイルのアクセス回数≠０」である場合には、
Ｓｔｅｐ４以降を実行する。

【００２６】Ｓｔｅｐ３：リビジョン差分表現 ここでは、どのリビジョンからどのリビジョンに変化し
たかということをユーザに示す。本実施例では、カレン
トＤＢ１２のリビジョンの値とそのリビジョンから“−
１”を加えた値をユーザに表示し、リビジョンの更新を
明示的に知らせる。

【００２７】Ｓｔｅｐ４：ビュー表示 図７に示すようなＤＢの変更があり、部門外に所属する
ユーザＡがアクセスした場合について説明する。

【００２８】同図（ａ）は「リビジョン承認」によりこ
のＤＢがリビジョン３．０なった場合のカレントＤＢの
内容を示す図である。また、同図（ｂ）は、部門内で変
更が発生した状態を示す図である。この時点において、
ユーザＡのアクセスファイルは、図５のようになってい
るとする。従って、本システムは、Ｓｔｅｐ１において
信頼度の更新を行い、さらに、アクセスファイルにある
ＧＩＤと変更回数を参照して、ビューファイルＧＩＤで
ある“ＭＪ０１Ｄ０２２”の信頼度を“２”、“ＰＤ０
１Ａ００１”、“ＰＤ０１Ａ０３３”及び“ＰＤ０１Ａ
０３４”の信頼度を“１”とすることになる。そして、
「変更回数」になく、かつ、確定レコードに記録してあ
る“ＭＨ０５Ａ０１１”及び“ＭＨ０５Ａ０２２”につ
いては信頼度を“−１”とする。このようにして作成さ
れた部門外ＤＢビューは、図３（ｂ）のようになる。

【００２９】図８は、部門内指定ファイル作成部５ａの
動作を説明するための図である。ユーザが日付又はリビ
ジョンを指定すると、その時点のデータを復元するもの
である。

【００３０】Ｓｔｅｐ１：指定種別 ユーザが指定した内容が、日付であるかリビジョンであ
るかを決定する。日付で指定した場合には、Ｓｔｅｐ２
ａへ進み、リビジョンで指定した場合には、Ｓｔｅｐ２
ｂへ進む。

【００３１】まず、日付指定の場合について説明する。 Ｓｔｅｐ２ａ：ｄａｙ＝入力された日付 入力された日付を変数day にセットする。

【００３２】Ｓｔｅｐ３ａ：カレントＤＢ１２のデータ
を読み込む。 カレントＤＢのデータを読み込み、履歴ＤＢ１３の付加
データを初期化する。 Ｓｔｅｐ４ａ：履歴ＤＢ１３においてカーソルを最新履
歴にセット 履歴ＤＢ１３のそれぞれのレコードを示すカーソルを最
新レコードにセットする。

【００３３】Ｓｔｅｐ５ａ及びＳｔｅｐ６ａ：日付の比
較参照 カーソルが示している履歴ＤＢ１３のレコードの属性
「履歴日付」の値と指定した日付を格納している変数da
y の値とを比較する。カーソルが示す日付の方が古い値
を示すものであれば終了し、同じ又は新しい日付を示す
ものであれば、Ｓｔｅｐ７ａへ進む。

【００３４】Ｓｔｅｐ７ａ：レコードの復元 カーソルが示す日付のレコードを復元する。このレコー
ドの復元について、図９を参照して説明する。図９は、
レコードの復元処理を説明するための図である。

【００３５】Ｓｔｅｐ７−１：履歴種別の値の判定 カーソルの示す履歴ＤＢ１３におけるレコードの属性
「履歴種別」の値を調べ、新規／追加を示す値の場合に
はＳｔｅｐ７−２ａへ、変更を示す値の場合にはＳｔｅ
ｐ７−２ｂへ、削除を示す値の場合にはＳｔｅｐ７−２
ｃへ進み、それぞれの処理を行う。

【００３６】Ｓｔｅｐ７−２ａ：同じユニークＮｏのレ
コードの削除 カーソルの示す履歴ＤＢ１３におけるレコードのユニー
クＮｏを検索キーとして、カレントＤＢ１２のデータ中
のレコードを検索する。そして、検索されたデータの属
性を初期化し、更新日からコメントまでをコピーする。

【００３７】Ｓｔｅｐ７−２ｂ：同じレコードＮｏのレ
コードとの置き換え カーソルの示す履歴ＤＢ１３におけるレコードのユニー
クＮｏを検索キーとしてカレントＤＢ１２のデータ中の
レコードを検索する。検索されたデータの必要な部分に
ついて、履歴ＤＢ１３におけるデータで置き換える。本
実施例においては、ＧＩＤから履歴種別までを置き換
え、更新者及びコメントの情報を付け加える。

【００３８】Ｓｔｅｐ７−２ｃ：レコードの追加 カレントＤＢ１２におけるデータにカーソルが示す履歴
ＤＢ１３のレコードを追加する。

【００３９】以上のサブステップにより、レコードは復
元されることになる。図８に戻り、Ｓｔｅｐ８ａについ
て説明する。 Ｓｔｅｐ８ａ：カーソルを一つ古いレコードへ移す。

【００４０】ここでは、図４（ａ）に示す内容をカレン
トＤＢ１２、同図（ｂ）に示す内容を履歴ＤＢ１３とし
て、９４／１２／０５の指定ファイルを作成する場合に
ついて説明する。

【００４１】まず、日付を選択し（Ｓｔｅｐ１）、“ｄ
ａｙ＝９４／１２／０１”とする（Ｓｔｅｐ２ａ）。カ
レントＤＢ１２を読み込む（Ｓｔｅｐ３ａ）。次に、履
歴ＤＢ１３の最新レコードを図４（ｂ）の“ＰＤ０１Ａ
０３４”としてカーソルをセットする（Ｓｔｅｐ４
ａ）。そして、カーソルが示すレコードの履歴日付は
“９４／１２／１０”であり、これは変数ｄａｙより新
しいと判断されるので（Ｓｔｅｐ５ａ）、Ｓｔｅｐ６へ
進むことになる。履歴種別が“１”、すなわち「変更」
であるので、カレントＤＢ１２におけるデータ中のユニ
ークＮｏ“ＰＤ０１Ａ０３４”のレコードの属性「名
称」から「更新日」までをカーソルの示すレコードの値
に置き換える（Ｓｔｅｐ７−２ｂ）。履歴ＤＢ１３のカ
ーソルを一つ古いレコード、すなわち、ユニークＮｏ
“ＰＤ０１Ａ０３３”へ移し、同様の処理を行う（Ｓｔ
ｅｐ７−２ａ）。この例の場合、Ｓｔｅｐ５ａでカーソ
ルが示すレコードの履歴日付がｄａｙより古いレコード
は、ユニークＮｏ“ＭＪ０１Ｄ０２２”，履歴日付“９
４／１２／０１”のレコードである。このレコードにカ
ーソルを移してからＳｔｅｐ５ａの判定で処理を終了す
る。このようにして得られる指定ファイルは図４（ｃ）
に示すようになる。

【００４２】以上のステップにより、部門内指定ファイ
ル作成部５ａは、部門内指定ファイルを指定された日付
に従って作成する。次に、Ｓｔｅｐ１においてリビジョ
ンが指定された場合について説明する。

【００４３】Ｓｔｅｐ２ｂ：入力されたリビジョン 入力されたリビジョンを変数rev にセットする。 Ｓｔｅｐ３ｂ及び４ｂは、上述したＳｔｅｐ３ａ及び４
ａと同じである。

【００４４】Ｓｔｅｐ５ｂ及び６ｂ：リビジョンの比較
参照 カーソルが示している履歴ＤＢのレコードの属性「リビ
ジョン」の値と指定したリビジョンを格納している変数
rev の値とを比較する。カーソルが示しているリビジョ
ンの方が古い値を示すものであれば終了し、同じ又は新
しいものを示すものであればＳｔｅｐ７ｂへ進む。な
お、Ｓｔｅｐ７ｂ以降は、上述のＳｔｅｐ７ａ以降のも
のと同じであるため、説明を省略する。

【００４５】部門外指定ファイル作成５ｂの動作処理
も、上述した部門内指定ファイル作成部５ａと、ほぼ同
様である。具体的には、上述した図８の動作処理のう
ち、Ｓｔｅｐ１を取り除いたＳｔｅｐ２ｂからＥＮＤま
で、及び図９に示す通りである。なお、部門外ユーザも
指定した時点の情報を参照することはできるが、公式な
リビジョンに限られる。

【００４６】次に、部門内差分確認部６ａの動作処理に
ついて説明する。図１０は、部門内差分確認部６ａの動
作処理を説明するための図である。 Ｓｔｅｐ１：指定入力 比較したい日付またはリビジョンを入力する。

【００４７】Ｓｔｅｐ２：入力された指定のセット 変数new-day ，old-day をセットする。 ｎｅｗ−ｄａｙ＝新しい方の指定 ｏｌｄ−ｄａｙ＝古い方の指定 Ｓｔｅｐ３：テンポラリファイル１ｔの作成 変数new-day を入力として部門内指定ファイルの作成を
行い、その結果をテンポラリファイルｔ１とする。

【００４８】Ｓｔｅｐ４：テンポラリファイルｔ２の作
成 変数old-day を入力として部門指定ファイルの作成を行
い、その結果をテンポラリファイルｔ２とする。

【００４９】Ｓｔｅｐ５：比較 テンポラリファイルｔ１とテンポラリファイルｔ２とに
存在するＧＩＤのすべてについてそれぞれ比較し、その
差分を記録する。本実施例の場合、データを比較する属
性は、ＧＩＤからリビジョンまでである。履歴ＤＢ１３
に記録されたコメント、変更者等の付加情報は、変数ol
d-day までのものから変数new-day までのものを引いた
ものとする。

【００５０】以上により、その内容の表示を行い（Ｓｔ
ｅｐ６）、最後にテンポラリファイルの削除を行って、
動作処理を終了する（Ｓｔｅｐ７） 次に、部門外差分確認部６ｂについて説明する。この部
門外差分確認部６ｂは、上述の部門内差分確認部６と同
様に、図１０に示した動作処理の手順に従って行われ
る。ただし、指定は、リビジョンのみである。

【００５１】次に、データ編集部８について説明する。
データ編集部８では、ユーザがデータベースに修正を加
える毎に以下の処理を実行する。 Ｓｔｅｐ１：カレントＤＢの変更 ユーザがエディタ（図示せず）によってデータの変更／
レコードの追加／レコードの削除等をした場合、システ
ムは、そのレコードに対して、３つの属性、すなわち、
「変更日」、「履歴日付」及び「履歴種別」の属性をセ
ットして、カレントＤＢ１２に登録する。ここで、属性
「変更日」には、そのレコードを変更／追加した日付が
セットされ、属性「履歴日付」には、同様に、そのレコ
ードを変更／追加した日付がセットされ、また、属性
「履歴種別」は、“０”がセットされる。

【００５２】Ｓｔｅｐ２：履歴ＤＢ１３への記録 カレントＤＢ１２に対してレコードの変更／追加／削除
等があるごとに、過去の古いデータを記録する（この内
容を図３（ｂ）に示す）。データの復元のために「履歴
日付」及び「履歴種別」をもち、変更時にユーザが理解
しやすいように更新者、コメントを記録できる。ここ
で、属性「変更日」には、カレントＤＢの修正前の「変
更日」フィールドの値がコピーされ、属性「履歴日付」
には、そのレコードを変更／追加／削除等した日付がセ
ットされる。また、属性「履歴種別」には、そのレコー
ドに対する修正が変更、追加又は削除のいずれの内容で
あるかがセットされる。ここでは、「新規」は“０”、
「変更」は“１”、「削除」は、“２”とする。さらに
履歴ＤＢ１３に対する付加情報として、本実施例では、
以下の２つの属性を設ける。すなわち、１つは、属性
「コメント」であり、公式リビジョンに対して変更した
理由、変更による波及先等が記述される。また、もう１
つは、属性「変更者」であり、データベースの変更者名
が記録される。

【００５３】Ｓｔｅｐ３：アクセスファイルの変更 アクセスファイル１１の内容“（ＧＩＤ，変更回数）”
を変更する。すでに変更があったＧＩＤをもつレコード
である場合には、現在の変更回数に値に“１”を加え、
また、初めての変更であればＧＩＤを登録するととも
に、その変更回数の値を“１”とする。部門内ＤＢビュ
ーの信頼度フィールドの値が“−１”（すなわち、「こ
れ以上変更しない」ことを示す）である場合には、確定
レコードに対して、そのユニークＮｏを記録する。

【００５４】次に、リビジョン承認部８について説明す
る。リビジョン承認部８によるリビジョンを承認するた
めの処理は、カレントＤＢ１２の属性「リビジョン」の
値を全て更新、すなわち、現在のリビジョンに対して１
を加える。このとき、新しいリビジョン用のビューファ
イル９を初期化する。また、確定レコードをコピーす
る。例えば、図４（ａ）に示すようなカレントＤＢ１２
の内容に対してリビジョン承認がなされるとすべてのレ
コードの属性は、「リビジョン」が“３．０”から
“４．０”に変更される。アクセスファイル１１は、 リビジョン＝４．０ 履歴日付＝００／００／００ 確定レコード＝ ＭＨ０５Ａ０１１，ＭＨ０５Ａ０２２，ＰＤ０１Ａ００
１ （ＧＩＤ， 変更回数）＝（００００００００，０） が作成されることになる。

【００５５】

【発明の効果】本発明によれば、部門内リビジョン（ロ
ーカルリビジョン）と公式リビジョン（公開リビジョ
ン）というような異なる次元のリビジョン管理を行な
い、一元的なデータベースを用いて、部門ごとに必要な
それぞれのビューで、コンカレントにエンジニアリング
業務を進める際に、データベースの内容の変更が何度も
発生する信頼度の低いデータを、他の部門のユーザに明
示的に知らせることができるようになる。

【００５６】また、ローカルユーザが、データベースの
内容をこれ以上変更しないことを保証する場合、そのレ
コードが確定したことも他の部門のユーザに明示的に知
らせることができるようなる。

【００５７】従って、信頼度が高く、かつ、確定したデ
ータから使用することができるので、信頼度の低いデー
タを使用したエンジニアリング部分の業務を先送りにす
ることができ、無駄な作業を軽減することができるよう
になる。

【００５８】さらに、リビジョン承認後、部門外のユー
ザが初めてデータベースにアクセスした際、リビジョン
が変更したことをユーザに明示的に知らせることによ
り、ユーザは、途中まで行なったエンジニアリングの修
正に迅速ににとりかかることができる。

【図面の簡単な説明】

【図１】 本発明のエンジニアリング支援システムの構
成を示す図。

【図２】 部門データの一例を示す図。

【図３】 部門内ＤＢビューの一例を示す図。

【図４】 カレントＤＢ及び履歴ＤＢの一例を示す図。

【図５】 アクセスファイルの一例を示す図。

【図６】 部門外ＤＢビュー作成５ｂの動作処理を説明
するための図。

【図７】 ビュー表示を説明するためのＤＢの内容の一
例を示す図。

【図８】 部門内指定ファイル作成部５ａの動作を説明
するための図。

【図９】 レコードの復元処理を説明するための図。

【図１０】 部門外指定ファイル作成部５ａの動作を説
明するための図。

【符号の説明】

１…データベース １１…部門ファイル １２…カレントＤＢ １３…履歴ＤＢ １４…アクセスファイル ２…表示部 ３…ユーザ識別部 ４ａ…部門内ＤＢビュー作成部 ４ｂ…部門外ＤＢビュー作成部 ５ａ…部門内指定ファイル作成部 ５ｂ…部門外内指定ファイル作成部 ６ａ…部門内差分確認部 ６ｂ…部門外差分確認部 ７…データ編集部 ８…リビジョン承認部 ９…ビューファイル

Claims (3)

【特許請求の範囲】
1. 【請求項１】複数の部門に亘ってエンジニアリング業務
   をコンカレントに行う際のエンジニアリング支援システ
   ムにおいて、 前記エンジニアリング業務に関するデータを一元的に記
   憶するデータベースに対しアクセスを行うユーザが所属
   する部門を識別し、該部門を特定するユーザ識別部と、 このユーザ識別部によって特定された前記ユーザの所属
   する部門に対応するビューファイルを表示する表示部
   と、 一の部門に所属するユーザによる前記データベースに対
   するアクセスに基づく前記データベースの内容の変更状
   況を他の部門に所属するユーザに知らせるための手段と
   を具備したことを特徴とするエンジニアリング支援シス
   テム。
2. 【請求項２】複数の部門に亘ってエンジニアリング業務
   をコンカレントに行う際のエンジニアリング支援システ
   ムにおいて、 前記エンジニアリング業務に関するデータを一元的に記
   憶するデータベースと、 このデータベースに対してアクセスを行うユーザの所属
   する部門を識別し、該部門を特定するユーザ識別部と、 このユーザ識別部によって特定された前記ユーザの所属
   する部門に対応するビューファイルを表示する表示部
   と、 一の部門に所属するユーザが、前記データベースの内容
   を変更するごとに該変更回数を記録する手段と、 前記一の部門に所属するユーザが、前記データベースの
   内容を確定した場合に、その確定事実を記録する手段
   と、 他の部門に所属するユーザに対応するビューファイルが
   前記表示部により表示される際に、前記変更回数及び前
   記確定事実を表示する手段を具備したことを特徴とする
   エンジニアリング支援システム。
3. 【請求項３】複数の部門に亘ってエンジニアリング業務
   をコンカレントに行う際のエンジニアリング支援システ
   ムにおいて、 前記エンジニアリング業務に関するデータを一元的に記
   憶するデータベースと、 このデータベースに対してアクセスを行うユーザが、部
   門内に所属するユーザであるか部門外に所属するユーザ
   であるかを識別するユーザ識別部と、 このユーザ識別部によって識別された前記ユーザが部門
   内に所属するユーザである場合に、部門内ビューファイ
   ルを表示する手段と、 前記ユーザ識別部によって識別された前記ユーザが部門
   外に所属するユーザである場合に、部門外ビューファイ
   ルを表示する手段と、 前記部門内に所属するユーザが、前記データベースの内
   容に対して編集を行い、該内容が確定した場合には、該
   確定事実を前記データベースに記録するデータ編集部
   と、 このデータ編集部により前記データベースの内容を変更
   するごとに該変更回数を記録する手段とを具備し、 前記部門外に所属するユーザが、前記表示部により前記
   部門外ビューファイルを参照する場合に、前記変更回数
   及び前記確定事実が視認することができることを特徴と
   するエンジニアリング支援システム。