(57)【要約】【課題】柔軟性を有したソフトウェアのソースコードの変更管理を行うことが可能なソフトウェアの並行開発における開発支援プログラム、開発支援方法及び開発支援システムを提供する。【解決手段】ＳＣＭリポジトリ１７に記憶されたプログラムを複数で並行開発するための開発支援プログラムが、サーバ１０及びクライアント２０に、サーバ１０のＳＣＭリポジトリ１７から変更対象のプログラムを読み出す操作に応じて、プログラムを変更操作で用いるクライアント２０の開発ワークスペース３０に記憶する読み出し手段２２と、読み出し手段２２にて記憶した開発ワークスペース３０のプログラムに対する変更操作に応じて、変更前のプログラムと比較して、プログラムの変更が確定される度合いを表す変更確度を算出する変更確度算出手段２５と、を実行させる。【選択図】図１
2010049419.tif 000002
【特許請求の範囲】
【請求項１】
共有の記憶部に記憶されたソフトウェアのソースコードを複数で並行開発するための開発支援プログラムであって、
コンピュータに、
前記共有の記憶部から変更対象の前記ソースコードを読み出す操作に応じて、前記ソースコードを、変更操作で用いる個別の記憶部に記憶する読み出しステップと、
前記読み出しステップにて記憶した前記個別の記憶部の前記ソースコードに対する前記変更操作に応じて、変更前の前記ソースコードと比較して、前記変更操作による前記ソースコードの変更が確定される度合いを表す変更確度を算出する変更確度算出ステップと、
を実行させることを特徴とする開発支援プログラム。
【請求項２】
前記コンピュータに、前記変更確度算出ステップにて算出した前記変更確度の度合いの大きさに応じて、変更後の前記ソースコードを表示エディタに表示する表示ステップを実行させること、
を特徴とする請求項１に記載の開発支援プログラム。
【請求項３】
前記コンピュータに、変更後の前記ソースコードを抽象化した有向グラフを生成して、前記変更対象のソースコードを抽象化した有向グラフに基づき、前記有向グラフの不整合を検出する不整合検出ステップを実行させ、
前記変更確度算出ステップは、前記不整合検出ステップにて検出した前記不整合に基づいて前記変更確度を算出すること、
を特徴とする請求項１に記載の開発支援プログラム。
【請求項４】
前記変更確度算出ステップは、前記不整合検出ステップにて検出した前記不整合と、前記ソースコードに対する前記変更操作からの経過時間とから、前記変更確度を算出すること、
を特徴とする請求項３に記載の開発支援プログラム。
【請求項５】
前記変更確度算出ステップは、所定の時間が経過したタイミングで、前記変更確度を算出すること、
を特徴とする請求項４に記載の開発支援プログラム。
【請求項６】
前記変更確度算出ステップは、前記ソースコードに対する前記変更操作をしてからの経過時間が所定の値より長いことを条件に、前記変更確度の度合いが大きくなるように前記変更確度を算出すること、
を特徴とする請求項４に記載の開発支援プログラム。
【請求項７】
前記変更確度算出ステップは、前記不整合検出ステップにて検出した前記不整合の数が所定の値より多いことを条件に、前記変更確度の度合いが小さくなるように前記変更確度を算出すること、
を特徴とする請求項４に記載の開発支援プログラム。
【請求項８】
前記表示ステップは、前記変更確度の度合いがより大きいほど、前記変更後のソースコードの変更箇所をより視認容易に表示すること、
を特徴とする請求項２に記載の開発支援プログラム。
【請求項９】
前記有向グラフは、編集対象を示すノードと、前記ノードの間の依存関係を示すエッジとからなり、
前記不整合検出ステップは、前記ノードごとに不整合を検出すること、
を特徴とする請求項３に記載の開発支援プログラム。
【請求項１０】
前記コンピュータに、複数の前記個別の記憶部に記憶された前記ソースコードに対する前記変更操作によって前記変更確度算出ステップにて算出した各々の前記変更確度から、共通変更確度を算出する共通変更確度算出ステップを実行させること、
を特徴とする請求項１に記載の開発支援プログラム。
【請求項１１】
前記コンピュータに、前記共通変更確度算出ステップにより算出された前記共通変更確度の度合いの大きさに応じて、前記ソースコードを変更した共通変更ソースコードを表示エディタに表示する表示ステップを実行させ、
前記表示ステップは、操作部の操作に応じて、変更後の前記ソースコードと、前記共通変更ソースコードとを比較して表示すること、
を特徴とする請求項１０に記載の開発支援プログラム。
【請求項１２】
共有の記憶部に記憶されたソフトウェアのソースコードを複数で並行開発するための開発支援プログラムであって、
コンピュータに、
前記共有の記憶部から変更対象の前記ソースコードを読み出す操作に応じて、前記ソースコードを、変更操作で用いる個別の記憶部に記憶する読み出しステップと、
前記読み出しステップにて記憶した前記個別の記憶部の前記ソースコードに対する前記変更操作に応じて、変更後の前記ソースコードを抽象化した有向グラフを生成して、前記変更対象のソースコードを抽象化した有向グラフに基づき、前記有向グラフの不整合を検出する不整合検出ステップと、
前記不整合検出ステップにて検出された不整合に基づいて、前記変更操作による前記ソースコードの変更が確定される度合いを表す変更確度を算出する変更確度算出ステップと、
前記変更確度算出ステップにて算出した前記変更確度の度合いの大きさに応じて、変更後の前記ソースコードを表示エディタに表示する表示ステップと、
を実行させることを特徴とする開発支援プログラム。
【請求項１３】
共有の記憶部に記憶されたソフトウェアのソースコードを複数で並行開発するための開発支援方法であって、
コンピュータが、
前記共有の記憶部から変更対象の前記ソースコードを読み出す操作に応じて、前記ソースコードを、変更操作で用いる個別の記憶部に記憶する読み出しステップと、
前記読み出しステップにて記憶した前記個別の記憶部の前記ソースコードに対する前記変更操作に応じて、変更前の前記ソースコードと比較して、前記変更操作による前記ソースコードの変更が確定される度合いを表す変更確度を算出する変更確度算出ステップと、
を含むことを特徴とする開発支援方法。
【請求項１４】
共有の記憶部に記憶されたソースコードを複数で並行開発するための開発支援システムであって、
コンピュータが、
前記共有の記憶部から変更対象の前記ソースコードを読み出す操作に応じて、前記ソースコードを、変更操作で用いる個別の記憶部に記憶する読み出し手段と、
前記読み出し手段にて記憶した前記個別の記憶部の前記ソースコードに対する前記変更操作に応じて、変更前の前記ソースコードと比較して、前記変更操作による前記ソースコードの変更が確定される度合いを表す変更確度を算出する変更確度算出手段と、
を備えることを特徴とする開発支援システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアの並行開発における開発支援プログラム、開発支援方法及び開発支援システムに関する。
【背景技術】
【０００２】
昨今、ソフトウェア開発において、複数人の開発者による並行開発が日常的に行われている。また、ソフトウェアの複雑化に伴い、ソースコード間の依存関係も複雑化している。複数人による並行開発では、各々の開発者が個別の環境にソースコードをチェックアウトし（取り出し）、同時に、同一のソースコードの同一箇所に対して異なる変更を行い、ソフトウェア構成管理（Ｓｏｆｔｗａｒｅ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ、ＳＣＭ）にチェックインする（戻す）段階で、複雑なマージ作業が生じる。このマージ作業は、手作業で行われたり、既存のマージツールを用いたりするが、手作業の場合には手間がかかる上に作業ミスが発生しやすい。また既存のマージツールも分かりにくいために、作業ミスが発生しやすい。そして、このような状況でマージ作業を行う結果、ソースコードが矛盾を含む状態になったり、先祖返りしたり等の問題が生じる。
【０００３】
このような並行開発におけるソフトウェアのソースコード管理については、例えば、共用データファイルを使用した方法が開示されている（特許文献１参照）。特許文献１に記載のデータファイルのバーチャル更新・照会方法は、データをユーザやテストケースごとに仮想的に更新・照会する仕組みであり、データテーブルに処理を選択するフラグを追加する仕組みと、再編成の仕組みとを提供するものである。しかし、特許文献１に記載のデータファイルのバーチャル更新・照会方法は、定期的に人手による再編成が必要であり、個別に持っているデータ間の不整合を、都度解決するものではない。
【０００４】
また、並行開発におけるソフトウェアのソースコード管理についての他のものとして、関連するファイルの整合性を考慮したサーバ資産管理プログラムが開示されている（例えば、特許文献２）。特許文献２に記載のサーバ資産管理プログラムは、サーバでチェックアウトのテーブルを管理し、チェックインがあった場合に、関連する他のユーザに通知する。また、編集されたことを通知し、他のユーザによる変更をロックしたり、チェックインでロックをはずしたりする。しかし、特許文献２に記載のサーバ資産管理プログラムは、編集開始時及びチェックインのタイミングで他のユーザに通知するものである。また、ファイル単位での仕組みである。
【０００５】
そして、上述の文献に記載のものは、いずれもソフトウェアの厳密な変更管理等を行うために用いるツールであり、そこまでの厳密な変更管理を行わなくてもよい開発や、開発の初期段階で複数の開発者が協調作業をする場合には、厳密な変更管理により逆に柔軟性に欠けて、開発が非効率的になるおそれがある。
【特許文献１】特開２００７−１４１０２２号公報
【特許文献２】特開２００６−１７８９０４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
そこで、本発明は、柔軟性を有したソフトウェアのソースコードの変更管理を行うことが可能なソフトウェアの並行開発における開発支援プログラム、開発支援方法及び開発支援システムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の１つの態様では、以下のような解決手段を提供する。
【０００８】
本発明の第１の形態によると、共有の記憶部に記憶されたソフトウェアのソースコードを複数で並行開発するための開発支援プログラムは、コンピュータに、共有の記憶部から変更対象のソースコードを読み出す操作に応じて、ソースコードを、変更操作で用いる個別の記憶部に記憶する読み出しステップを実行させる。いいかえれば、共有の記憶部から変更対象のソースコードを個別の記憶部にチェックアウトする。変更対象のソースコードとは、高級言語やオブジェクト指向で記述されたプログラムのソースコードや、プログラム設計図等をいう。そして、コンピュータに、読み出しステップにて記憶した個別の記憶部のソースコードに対する変更操作に応じて、変更前のソースコードと比較して、変更操作によるソースコードの変更が確定される度合いを表す変更確度を算出する変更確度算出ステップを実行させる。ソースコードの変更は、開発途上では、様々な変更を行うが、その変更は不確定である。そこで、変更操作によるソースコードの変更が確定される度合いを算出して、最終的にどのように変更されるかを推定するのである。そして、コンピュータに、変更確度算出ステップにて算出した変更確度の度合いの大きさに応じて、変更後のソースコードを表示エディタに表示する表示ステップを実行させる。
【０００９】
本発明の第２の形態によると、第１の形態に加えて、コンピュータに、変更後のソースコードを抽象化した有向グラフを生成して、変更対象のソースコードを抽象化した有向グラフに基づき、有向グラフの不整合を検出する不整合検出ステップを実行させる。ソースコードから有向グラフへは、周知な技術を用いて生成できる。有向グラフは、編集対象を示すノードと、ノードの間の依存関係を示すエッジとからなり、ノードごとに不整合を検出する。そして、変更確度算出ステップは、不整合検出ステップにて検出した不整合に基づいて変更確度を算出する。
【００１０】
本発明の第３の形態によると、第１の形態に加えて、コンピュータに、複数の個別の記憶部に記憶されたソースコードに対する変更操作によって変更確度算出ステップにて算出した各々の変更確度から、共通変更確度を算出する共通変更確度算出ステップを実行させる。そして、共通変更確度の度合いの大きさに応じて、変更後のソースコードを表示エディタに表示する表示ステップを実行させる。
【００１１】
また、本発明は別の形態として、上記のコンピュータ・プログラムの各ステップを含む方法としても提供可能である。更に別の形態として、上記のコンピュータ・プログラムを実行するシステムとしても提供可能である。
【発明の効果】
【００１２】
本発明によれば、コンピュータに、共有の記憶部から変更対象のソースコードを読み出す操作に応じて、ソースコードを、変更操作で用いる個別の記憶部に記憶する読み出しステップと、読み出しステップにて記憶した個別の記憶部のソースコードに対する変更操作に応じて、変更前のソースコードと比較して、変更操作によるソースコードの変更が確定される度合いを表す変更確度を算出する変更確度算出ステップと実行させる開発支援プログラム、方法及びシステムを提供することができる。よって、変更確度を用いることで、柔軟性を有したソースコードの変更管理を行うことができる。
【発明を実施するための最良の形態】
【００１３】
以下、本発明の実施形態について、図面に基づいて説明する。図１は、本実施形態に係る開発支援システム１の全体構成並びにサーバ１０及びクライアント２０の機能構成を示す図である。開発支援システム１は、サーバ１０、複数のクライアント２０及び通信ネットワーク５により構成される。図１に示すように、インターネット、社内ＬＡＮ等の通信回線である通信ネットワーク５を介して、サーバ１０と、クライアント２０とが通信可能に接続されている。
【００１４】
サーバ１０は、マスターソース等の管理対象のソースコードを記憶した、開発支援のためのサーバである。サーバ１０は、複数のクライアント２０に対して通信をすることで、複数のクライアント２０からのデータに基づき共通処理を実行する。クライアント２０は、例えば、パーソナルコンピュータ（ＰＣ）に代表されるコンピュータであり、通信ネットワーク５に接続可能であれば、通信は、有線であっても無線であってもよい。また、携帯可能な端末であってもよい。開発者は、具体的には、クライアント２０を用いて、例えば、プログラムのコーディングや設計等のソフトウェアの開発を行う。
【００１５】
サーバ１０は、制御部１１、記憶部１６、及び通信インタフェース部１９を備える。制御部１１は、ＳＣＭ制御手段１２、共通変更確度算出手段１３を有する。ＳＣＭ制御手段１２は、次に説明するＳＣＭリポジトリ１７（共有の記憶部）に関する制御を行う。共通変更確度算出手段１３については、後述する。
【００１６】
記憶部１６は、ＳＣＭリポジトリ１７、共有ワークスペース１８を有する。ＳＣＭリポジトリ１７は、ソフトウェア開発において必要な、設計情報や定義情報等の開発に関連するデータを格納し、これらのデータを一元的に管理するデータベースである。ここでは、後述する有向グラフで抽象化できるソフトウェアのプログラムソースを格納するものとして説明する。共有ワークスペース１８は、クライアント２０から受信したデータ等をクライアント２０の開発者ごとに記憶する記憶領域である。
【００１７】
通信インタフェース部１９は、通信ネットワーク５を介して複数のクライアント２０との通信を行うためのインタフェースである。
【００１８】
クライアント２０は、制御部２１、通信インタフェース部２９、表示部３２、操作部３４、及び記憶部３６を備える。制御部２１は、読み出し手段２２、有向グラフ生成手段２３、不整合検出手段２４、変更確度算出手段２５及び表示制御手段２６を有する。
【００１９】
読み出し手段２２は、操作部３４からの操作を受け付けて、サーバ１０に該当のソースコードのチェックアウトを依頼し、サーバ１０がＳＣＭリポジトリ１７から該当のソースコードを抽出して、サーバ１０から受信した当該ソースコードを、次に説明する開発ワークスペース３０（個別の記憶部）に記憶する。
【００２０】
有向グラフ生成手段２３は、開発ワークスペース３０に記憶されたソフトウェアのプログラムソースから、そのソースコードを抽象化したネットワーク構造を示す有向グラフを生成する。プログラムソースから有向グラフを生成する方法としては、プログラムスライシングの技術を代表とするプログラム解析技術を用いて実現できる。プログラムスライシングについての参考文献として、下村隆夫著「プログラムスライシング技術と応用」、共立出版、１９９５がある。
【００２１】
不整合検出手段２４は、変更したソースコードに関する不整合を検出する。変更確度算出手段２５は、変更したソースコードが確定される確度（度合い）である変更確度を算出する。表示制御手段２６は、表示部３２に表示する仮想共有エディタ３３に、ソースコードを表示するための制御を行う。
【００２２】
通信インタフェース部２９は、通信ネットワーク５を介してサーバ１０との通信を行うためのインタフェースをいう。表示部３２は、例えば、液晶ディスプレイ（ＬＣＤ）をいう。仮想共有エディタ３３は、変更したソースコードに関する他の開発者の変更状況を参照可能に表示するエディタである。操作部３４は、例えば、マウスやキーボードをいう。
【００２３】
記憶部３６は、開発ワークスペース３０を有する。開発ワークスペース３０は、変更するソースコードを記憶する領域である。開発ワークスペース３０は、ＳＣＭリポジトリ１７からチェックアウトしたソースコードを記憶し、ＳＣＭリポジトリ１７にチェックイン後は、初期化する。また、開発ワークスペース３０は、変更したソースコードの変更部分や、変更した時間等を一時的に記憶する記憶領域である。
【００２４】
次に、変更するソースコードとしてＪａｖａ（登録商標）プログラムを例にして、有向グラフとの関係について説明する。図２は、Ｊａｖａプログラムの開発時における、ソースコードと有向グラフとの関係を示す図である。
【００２５】
まず、図２（ａ）は、Ｊａｖａプログラムの例である。そして、図２（ｂ）は、図２（ａ）で示すＪａｖａプログラムを抽象化し、有向グラフに表したものである。ノード（図２（ｂ）中楕円で表示）は、編集対象でありノード型を持つ。また、エッジ（図２（ｂ）中矢印で表示）は、存在の依存関係を表す。つまり、矢印の先のノードは、矢印の元のノードがないと存在できない。そして、ノード型ごとに、エッジによって指すことのできるノード型のルールがある。ノード型のルールとは、例えば、以下の４つを指す。
１）クラス型ノードは、メソッド型ノードと宣言型ノードとを任意個含む。
２）クラス型ノードは、任意個の引数型ノードと宣言型ノードとを指す。
３）メソッド型ノードは、引数型ノードを１個のみ含み、任意個の宣言型ノードと任意個の文型ノードとを含む。
４）引数型ノードと宣言型ノードとは、任意個の文型ノードを指す。
【００２６】
次に、編集操作と、編集操作によって生じた不整合について説明する。図３は、有向グラフにおける不整合のケースを示す図である。図３（ａ）は、不整合の第１のケースを示す。ノード４０〜４３の４つのノードが示され、図３（ａ）に示すように、エッジによりノード間の依存関係が示されている場合に、ノード４２を削除する編集操作を行う。すると、ノード４２と、矢印の先がノード４２であるエッジ４４とが削除されるが、矢印の元がノード４２であるエッジ４５は、削除されずに残る。ここで、エッジ４５は、根元がないエッジであるので、依存関係を充足せず不整合が生じる。なお、図中のｎの数は、不整合のエッジの数である。
【００２７】
図３（ｂ）は、不整合の第２のケースを示す。「Ａ」で表されるノード４６は、そのノード型により２以上のエッジが存在することを前提とするノードである。ノード４６には、エッジによりノード４７、４８が関係付けられている。ここで、ノード４６に関係するノード４８を削除する編集操作を行うと、矢印の先がノード４８であるエッジが削除される。結果として、ノード４６に関係するエッジの数が、ノード４６のノード型によるルールから外れるため、不整合が生じる。
【００２８】
図３（ｃ）は、不整合の第３のケースを示す。「Ｂ」で表されるノード４９は、そのノード型により０又は１のエッジが存在することを前提とするノードである。ノード４９には、ノード５０が関係付けられている。ここで、ノード４９に関係するようにノード５１を追加する編集操作を行うと、矢印の先がノード５１であるエッジが追加される。結果として、ノード４９に関係するエッジの数が、ノード４９のノード型によるルールから外れるため、不整合が生じる。
【００２９】
図３（ｄ）は、不整合の第４のケースを示す。「Ｃ」で表されるノード５２は、ノード型が「ｉｎｔ」のノードに関係することを前提とするノードである。ノード５２には、ノード型が「ｉｎｔ」のノード５３が関係付けられている。このノード５２を、ノード型が「ｄｏｕｂｌｅ」のノードに関係することを前提とする「Ｄ」で表されるノード５４に変更する編集操作を行う。すると、ノード５４とノード型が「ｉｎｔ」であるノード５３との間には、不整合が生じる。
【００３０】
なお、その他の編集操作として、他のノードに関係しない、つまり他のノードに対してエッジにより関係付けられていないノードを新たに追加するような編集操作が考えられる。しかし、このようなノードを新たに追加する編集操作は、他の開発者に影響を与えないものであるため、不整合にカウントしない。
【００３１】
次に、図４及び図５に基づき、編集操作による変更確度の算出方法について説明する。図４は、変更確度の変化を示すグラフであり、図５は、変更確度を算出するための具体例を説明するための図である。変更確度とは、開発ワークスペース３０で行う個々の開発者による変更が、ＳＣＭリポジトリ１７にチェックインされる可能性を示す確率をいう。変更の有無は、正確には、実際にソースコードをチェックインした時点でないと分からないため、推定値である。変更確度は、変更されてからの経過時間と不整合の数とに基づき決定する。また、変更確度は、０から１までの数値で表され、変更がＳＣＭリポジトリ１７にチェックインされる可能性が大きいものほど、１に近づく。変更確度の性質として、以下の点が挙げられる。
１）最新のチェックアウト後に編集操作が行われていないものは、変更確度を０とする。
２）不整合の数が０の場合は、変更確度の最大が１である。また、不整合の数が多くなるほど、変更確度の最大・最小が０に近づく。
３）編集後の経過時間にかかわらず、変更確度は、不整合の数が少ない方が、不整合の数が多いものより必ず大きい。
４）不整合の数が同じ場合は、編集後の経過時間が長いものほど変更確度が大きい。
５）同一の変更に関しては、最新の変更確度のみを有効にする。
【００３２】
上述の変更確度の性質を満たす変更確度は、以下の式により求めることができる。ここで、追加、変更、削除等の編集操作ｏにより生じる不整合の数をｎとし、最初のチェックアウトをしてからの経過時間をＴとする。また、最初のチェックアウトをしてから編集操作ｏをするまでの経過時間をｔ（但し、ｔ＞Ｔはｔ＝Ｔ）とする。この場合、編集操作ｏの変更確度ｖは、
【数１】
2010049419.tif 000003
である。
【００３３】
上述の変更確度の性質を満たす変更確度は、式１の他、離散的に求めることも可能である。別の式による編集操作ｏの変更確度ｖは、
【数２】
2010049419.tif 000004
である。式１及び式２は、いずれも上述の変更確度の性質を満たすものである。なお、上述の変更確度の性質を満たすものであれば、式１及び式２に限らず、他の式により表されるものであってもよい。
【００３４】
図４（ａ）は、式１を、図４（ｂ）は、式２をグラフに表したものである。いずれも縦軸が変更確度ｖを、横軸が時間Ｔを表す。図４に示す変更確度のグラフにより、不整合の数ｎが少ないほど、またチェックアウトしてから時間が経過するほど、変更確度が１に近づき、編集操作ｏによる変更が、ＳＣＭリポジトリ１７にチェックインされる確率が高くなることが分かる。
【００３５】
次に、図５に基づき、具体例を用いて変更確度を算出する。編集対象のＪａｖａプログラムをチェックアウトした時刻を０とし、５分後に「ｃ」で表されるノードを削除し、１０分後に「ｅ」で表されるノードを追加する編集操作をした場合を考える。変更確度を計算する基準になる現在時刻は、チェックアウトした時刻から２０分後（Ｔ＝２０）である。この場合の編集操作による変更確度ｖは、例えば、式１を用いて、
【数３】
2010049419.tif 000005
【数４】
2010049419.tif 000006
で表すことができる。よって、Ｔ＝２０において、ノード「ｅ」の追加の操作が、ノード「ｃ」の削除の操作よりもＳＣＭリポジトリ１７に格納される確率が高いことを示している。
【００３６】
次に、図６から図１２を用いて、一連の処理の流れについて説明する。図６は、クライアント２０における全体の流れを示すフローチャートである。まず、ステップＳ１では、制御部２１は、図７に示すチェックアウト処理を行い、その後、処理をステップＳ２に移す。
【００３７】
ここで、図７に基づきチェックアウト処理を説明する。ステップＳ１０１では、制御部２１は、チェックアウトが初回か否かを判断する。チェックアウトが初回とは、開発ワークスペース３０に変更対象のソースコードであるＪａｖａプログラムが入っておらず、開発者が初めてチェックアウトする場合をいう。また、初回ではないとは、開発者が既にＪａｖａプログラムをＳＣＭリポジトリ１７からチェックアウトしたが、その後の編集操作を帳消しにしたいために再度ＳＣＭリポジトリ１７からＪａｖａプログラムをチェックアウトをする場合をいう。チェックアウトが初回である場合（ステップＳ１０１：ＹＥＳ）には、制御部２１は、処理をステップＳ１０３に移す。他方、チェックアウトが初回でない場合（ステップＳ１０１：ＮＯ）には、制御部２１は、処理をステップＳ１０２に移す。
【００３８】
ステップＳ１０２では、制御部２１は、チェックインされなかった編集操作の取り消しをサーバ１０に通知する。この処理により、サーバ１０では、後述する変更確度の通知等でクライアント２０から受信したデータを削除する。ステップＳ１０３では、制御部２１は、サーバ１０に対して、ＳＣＭリポジトリ１７から該当のＪａｖａプログラム（ソースコード）をチェックアウトする指示を出力する。そして、制御部２１（読み出し手段２２）は、サーバ１０のＳＣＭリポジトリ１７からチェックアウトしたＪａｖａプログラムを、開発ワークスペース３０に記憶する。また、制御部２１は、編集操作を初期化し、経過時間Ｔを０にリセットする。ステップＳ１０４では、制御部２１（有向グラフ生成手段２３）は、開発ワークスペース３０に記憶したＪａｖａプログラムを抽象化した有向グラフを生成する。その後、制御部２１は、本処理を終了する。
【００３９】
図６に戻り、ステップＳ２では、制御部２１は、開発者の編集操作があるか否か、つまり、制御部２１が、開発者からの編集操作を、操作部３４を介して受け付けたか否かを判断する。開発者の編集操作がある場合（ステップＳ２：ＹＥＳ）には、制御部２１は、処理をステップＳ２１に移す。他方、開発者の編集操作がない場合（ステップＳ２：ＮＯ）には、制御部２１は、処理をステップＳ３に移す。
【００４０】
ステップＳ２１では、制御部２１は、編集対象の削除に関するものであるか否かを判断する。削除に関するものである場合（ステップＳ２１：ＹＥＳ）には、制御部２１は、処理をステップＳ２２に移す。ステップＳ２２では、制御部２１は、ノードを削除すると共に、削除されるノードに関係付けられた他のノードの依存元から、削除されるノードを関係付けているエッジを削除し、処理をステップＳ２５に移す。他方、削除に関するものではない場合（ステップＳ２１：ＮＯ）には、制御部２１は、処理をステップＳ２３に移す。
【００４１】
ステップＳ２３では、制御部２１は、編集対象の変更に関するものであるか否かを判断する。変更に関するものである場合（ステップＳ２３：ＹＥＳ）には、制御部２１は、処理をステップＳ２４に移す。ステップＳ２４では、制御部２１は、変更内容にあわせて依存ルールを変更し、処理をステップＳ２５に移す。他方、変更に関するものではない場合（ステップＳ２３：ＮＯ）には、制御部２１は、処理をステップＳ２５に移す。
【００４２】
ステップＳ２５では、制御部２１は、新しい編集操作を追加する。そして、ステップＳ２６では、制御部２１は、有向グラフを更新する。開発者の編集操作により変更される対象について、有向グラフを更新することで、制御部２１は、変更した有向グラフに基づき変更確度を算出する。なお、データの保有方法として、削除の場合には、例えば、実際にデータを削除するのではなく、削除のフラグを付して表示上は削除されたように見せることが考えられる。また、変更後のＪａｖａプログラムのソースコードを表示する。ステップＳ２７では、制御部２１は、図８に示す不整合検出処理を行い、その後、処理をステップＳ６に移す。
【００４３】
ここで、図８に基づき、不整合検出処理について説明する。まず、ステップＳ１１１では、制御部２１は、全ての編集操作の計算が終了したか否かを判断する。１度に複数の変更が行われる場合もあるため、それらの全ての編集操作に関して処理をしたか否かを判断する。全ての編集操作の計算が終了した場合（ステップＳ１１１：ＹＥＳ）には、制御部２１は、本処理を終了する。他方、全ての編集操作の計算が終了していない場合（ステップＳ１１１：ＮＯ）には、制御部２１は、処理をステップＳ１１２に移す。
【００４４】
ステップＳ１１２では、制御部２１（不整合検出手段２４）は、編集されたノードに対する不整合の数ｎを算出する。不整合であるか否かは、上述の図３に示したケースに該当するか否かで判断する。また、不整合の数は、依存元がないエッジの数、及び編集されたノードのルールに違反するエッジの数の総和である。そして、ステップＳ１１３では、制御部２１は、ステップＳ１１２で算出された不整合の数ｎを、編集操作ごとに開発ワークスペース３０に記憶する。その後、制御部２１は、処理をステップＳ１１１に移して、全ての編集操作に関して処理をするまで、ステップＳ１１１からステップＳ１１３を繰り返す。
【００４５】
図６に戻って、ステップＳ３では、制御部２１は、サーバ１０からの通知があるか否かを判断する。サーバ１０からの通知とは、同一のＪａｖａプログラムに対する他の開発者の変更に関する通知である。通知がある場合（ステップＳ３：ＹＥＳ）には、制御部２１は、処理をステップＳ３１に移す。他方、通知がない場合は、制御部２１は、処理をステップＳ４に移す。ステップＳ３１では、制御部２１は、図９に示す共有エディタの表示処理を行い、その後、処理をステップＳ４に移す。
【００４６】
ここで、図９に基づき、共有エディタの表示処理について説明する。まず、ステップＳ１２１では、制御部２１は、サーバ１０から複数の通知がある場合に、通知に対する処理が全て終了したか否かを判断する。全て終了した場合（ステップＳ１２１：ＹＥＳ）には、制御部２１は、本処理を終了する。他方、全てについて終了していない場合（ステップＳ１２１：ＮＯ）には、制御部２１は、処理をステップＳ１２２に移す。
【００４７】
ステップＳ１２２では、制御部２１は、通知された編集操作が、開発者自身の操作であるか否かを判断する。開発者自身の操作である場合（ステップＳ１２２：ＹＥＳ）には、制御部２１は、処理をステップＳ１２１に移す。開発者自身の操作を除く他の開発者の編集操作に関するデータを抽出するための処理である。他方、開発者自身の操作ではない場合（ステップＳ１２２：ＮＯ）には、制御部２１は、処理をステップＳ１２３に移す。
【００４８】
ステップＳ１２３では、制御部２１（表示制御手段２６）は、通知された変更確度（後述する共通変更確度）と編集操作とに従って、変更内容を仮想共有エディタ３３に表示する。その後、制御部２１は、処理をステップＳ１２１に移し、通知に対する処理が全て終了するまで、ステップＳ１２１からステップＳ１２３の処理を繰り返す。このように、同一のＪａｖａプログラムに関して開発を行っている他の開発者の変更内容を、編集操作の単位で、変更確度に応じて仮想共有エディタ３３に表示するので、開発者は、他の開発者の変更内容を考慮しながら、自らの開発を行うことができる。
【００４９】
図６に戻って、ステップＳ４では、制御部２１は、チェックイン処理であるか否かを判断する。すなわり、操作部３４の操作により、制御部２１が、開発ワークスペース３０に記憶したＪａｖａプログラムをチェックインする指示を受け付けたか否かを判断する。チェックイン処理である場合（ステップＳ４：ＹＥＳ）には、制御部２１は、処理をステップＳ４１に移す。他方、チェックイン処理ではない場合（ステップＳ４：ＮＯ）には、制御部２１は、処理をステップＳ５に移す。ステップＳ４１では、制御部２１は、図１０に示すチェックイン処理を行い、その後、本処理を終了する。
【００５０】
ここで、図１０に基づき、チェックイン処理について説明する。まず、ステップＳ１３１では、制御部２１は、該当のＪａｖａプログラムをサーバ１０に送信することで、サーバ１０の制御部１１（ＳＣＭ制御手段１２）は、該当のＪａｖａプログラムをＳＣＭリポジトリ１７にチェックインする。そして、クライアント２０の制御部２１は、編集操作を初期化する。その後、ステップＳ１３２では、制御部２１は、サーバ１０にチェックインを通知する。その後、制御部２１は、本処理を終了する。
【００５１】
図６に戻って、ステップＳ５では、制御部２１は、チェックアウト処理であるか否かを判断する。すなわり、操作部３４の操作により、制御部２１が、Ｊａｖａプログラムが記憶された開発ワークスペース３０に、再度チェックアウトすることで、開発ワークスペース３０に記憶したＪａｖａプログラムを上書きするか否かを判断する。チェックアウト処理である場合（ステップＳ５：ＹＥＳ）には、制御部２１は、処理をステップＳ１に移し、上述の図７で説明したチェックアウト処理を行う。他方、チェックアウト処理ではない場合（ステップＳ５：ＮＯ）には、制御部２１は、処理をステップＳ６に移す。
【００５２】
ステップＳ６では、制御部２１は、図１１に示す変更確度の更新処理を行い、その後、処理をステップＳ２に移す。
【００５３】
ここで、図１１に基づき、変更確度の更新処理について説明する。まず、ステップＳ１４１では、制御部２１は、記憶した全ての編集操作に関して計算が終了したか否かを判断する。上述の図８のステップＳ１１３において、編集操作ごとに不整合の数ｎを開発ワークスペース３０に記憶しており、それら全てについて、変更確度の更新のための計算処理をしたか否かを判断する。全ての編集操作の計算が終了した場合（ステップＳ１４１：ＹＥＳ）には、制御部２１は、本処理を終了する。他方、全ての編集操作の計算が終了していない場合（ステップＳ１４１：ＮＯ）には、制御部２１は、処理をステップＳ１４２に移す。
【００５４】
ステップＳ１４２では、制御部２１は、１つの編集操作に対応する不整合の数ｎを取り出す。そして、ステップＳ１４３では、制御部２１（変更確度算出手段２５）は、不整合の数ｎと、経過時間Ｔとから、変更確度ｖを算出する。変更確度ｖの算出は、上述の式１又は式２を用いることで実施している。そして、ステップＳ１４４では、制御部２１は、前回の変更確度から、変更確度ｖの値が変化したか否かを判断する。変化があった場合（ステップＳ１４４：ＹＥＳ）には、制御部２１は、処理をステップＳ１４５に移す。他方、変化がなかった場合（ステップＳ１４４：ＮＯ）には、制御部２１は、処理をステップＳ１４１に移す。
【００５５】
ステップＳ１４５では、制御部２１は、サーバ１０に、編集操作のノードと変更確度ｖとを変更データとして送信する。その後、ステップＳ１４６では、制御部２１は、算出した変更確度ｖを編集操作ごとに開発ワークスペース３０に記憶する。その後、制御部２１は、処理をステップＳ１４１に移す。
【００５６】
このように、常に変更確度の算出が行われて、全クライアント２０に新しい変更確度が更新されるので、開発者は、他の開発者の新しい変更内容を参照することができる。また、変更確度の更新処理は、定期的なタイミングで行われるので、編集操作後の経過時間を考慮して変更確度の算出を行うことができる。
【００５７】
次に、図１２に基づき、サーバ１０における全体の処理の流れを説明する。ここで、ＳＣＭリポジトリ１７に記憶したＪａｖａプログラムのうち、チェックアウトしたＪａｖａプログラムがない状態から開始する。まず、ステップＳ２０１では、制御部１１は、例えば、共有ワークスペース１８に有する編集操作と変更確度との記憶領域を初期化し、本サービスを利用する全てのクライアント２０に対して変更がないことを通知する。次に、ステップＳ２０２では、制御部１１は、クライアント２０からチェックインの通知があったか否かを判断する。クライアント２０からのチェックイン通知は、上述の図１０のステップＳ１３２により行われる。チェックインの通知があった場合（ステップＳ２０２：ＹＥＳ）には、制御部１１は、処理をステップＳ２０１に移し、該当のＪａｖａプログラムに関する編集操作と変更確度との記憶領域を初期化する。他方、チェックインの通知がなかった場合（ステップＳ２０２：ＮＯ）には、制御部１１は、処理をステップＳ２０３に移す。
【００５８】
ステップＳ２０３では、制御部１１は、クライアント２０から編集操作の取り消し通知があったか否かを判断する。クライアント２０からの編集操作の取り消し通知は、上述の図７のステップＳ１０２により行われる。取り消し通知があった場合（ステップＳ２０３：ＹＥＳ）には、制御部１１は、処理をステップＳ２１０に移す。他方、取り消し通知がなかった場合（ステップＳ２０３：ＮＯ）には、制御部１１は、処理をステップＳ２０４に移す。
【００５９】
ステップＳ２０４では、制御部１１は、クライアント２０から変更確度の通知があったか否かを判断する。クライアント２０からの変更確度の通知は、上述の図１１のステップＳ１４５により行われる。変更確度の通知があった場合（ステップＳ２０４：ＹＥＳ）には、制御部１１は、処理をステップＳ２０５に移す。他方、変更確度の通知がなかった場合（ステップＳ２０４：ＮＯ）には、制御部１１は、処理をステップＳ２０２に移す。
【００６０】
ステップＳ２０５では、制御部１１は、通知された編集操作は存在するか否かを判断する。通知された編集操作が存在する場合（ステップＳ２０５：ＹＥＳ）には、制御部１１は、処理をステップＳ２０７に移す。他方、通知された編集操作が存在しない場合（ステップＳ２０５：ＮＯ）には、制御部１１は、処理をステップＳ２０６に移し、編集操作を追加する。
【００６１】
ステップＳ２０７では、制御部１１は、該当の編集操作に通知したクライアント２０を追加して、新しい変更確度を共有ワークスペース１８に記憶する。なお、既にクライアント２０のデータが共有ワークスペース１８に存在している場合には、該当のクライアント２０の変更確度に新しい変更確度を上書きする。
【００６２】
ステップＳ２０８では、制御部１１（共通変更確度算出手段１３）は、共通変更確度を算出する。複数のクライアント２０が存在している場合は、制御部１１は、複数の変更確度に基づいて共通変更確度を計算する。また、クライアント２０が１つである場合には、制御部１１は、クライアント２０の変更確度を共通変更確度とする。そして、制御部１１は、共通変更確度を全クライアント２０に通知する。その後、制御部１１は、処理をステップＳ２０２に移す。
【００６３】
ここで、共通変更確度について説明する。共通変更確度は、各開発者の変更確度を投影したものであり、同じ変更を複数の開発者が行った場合には、人数に応じて共通変更確度を変更する。この共通変更確度Ｖは、ある開発者ｉの変更確度をｖ（ｉ）として、例えば、次の式で表すことができる。
【数５】
2010049419.tif 000007
【００６４】
その他、次の式で表すことも可能である。
【数６】
2010049419.tif 000008
【００６５】
例えば、同一のＪａｖａプログラムの同一の位置に対して開発者ｘ、ｙ、ｚの３名が変更を行っており、ノードＸに対する変更確度が、開発者ｘは０．１、開発者ｙは０．５、開発者ｚは０．８であるとする。その場合、ノードＸの操作に対する共通変更確度Ｖは、式３を用いて、
【数７】
2010049419.tif 000009
になる。また、式４を用いると、
【数８】
2010049419.tif 000010
になる。つまり、共通変更確度Ｖは、同じ変更を複数の開発者が行った場合は、その中の最大の変更確度より大きい値を示すか、又は等しい値になる。
【００６６】
このように、共通変更確度をクライアント２０に通知するので、クライアント２０は、複数のクライアント２０での変更対象ソースコードの変更内容（共通変更ソースコード）を、共通変更確度に基づいて仮想共有エディタ３３に表示することができる。そして、開発者は、複数のクライアント２０での変更内容を考慮に入れて開発を行うことができる。
【００６７】
図１２に戻って、ステップＳ２１０では、制御部１１は、指定された編集操作から通知してきたクライアント２０のデータを削除する。次に、ステップＳ２１１では、制御部１１は、全てのクライアント２０のデータが削除されたか否かを判断する。全てのクライアント２０が削除された場合（ステップＳ２１１：ＹＥＳ）には、制御部１１は、処理をステップＳ２１２に移す。全てのクライアント２０が削除されていない場合（ステップＳ２１１：ＮＯ）には、制御部１１は、処理をステップＳ２０８に移す。
【００６８】
ステップＳ２１２では、制御部１１は、指定された編集操作を削除し、全クライアントに通知する。その後、制御部１１は、処理をステップＳ２０２に移す。
【００６９】
次に、ある開発者（開発者１とする）の編集操作による変更確度の計算を、具体例に基づき説明する。図１３は、Ｊａｖａプログラムに対する編集操作を行う具体例を示す。開発者１は、Ｓｔｅｐ１では、Ｊａｖａプログラムをチェックアウト後に、クラスＡのメソッド「ｍｅｔｈｏｄ１」の引数を削除する操作を行う（＃１）。次に、Ｓｔｅｐ２では、削除したクラスＡのメソッド「ｍｅｔｈｏｄ１」の引数に、別の引数を追加する操作を行う（＃２）。更に、Ｓｔｅｐ３では、クラスＡのメソッド「ｍｅｔｈｏｄ１」の文を変更し（＃３）、Ｓｔｅｐ４では、クラスＡのメソッド「ｍｅｔｈｏｄ１」の宣言を変更する操作を行う（＃４）。
【００７０】
この開発者１による編集操作は、図１４〜図１７に示す有向グラフによって表すことができる。図１４（ａ）は、Ｓｔｅｐ１による編集操作を含んで、有向グラフに表した図である。メソッド「ｍｅｔｈｏｄ１」の引数である「ｉｎｔ  ａ」を削除したことに伴い、依存元を「ｉｎｔ  ａ」のノードにした２つのエッジが不整合として、不整合の数ｎに表される。そして、変更確度ｖは、式２を用いて、例えば図１４（ｂ）に示すように算出できる。なお、式２のＣ１は６０分に、Ｃ２は２４時間にして算出している。
【００７１】
図１５（ａ）は、Ｓｔｅｐ２による編集操作を含んで、有向グラフに表した図である。メソッド「ｍｅｔｈｏｄ１」の引数の「ｉｎｔ  ａ」の削除は、引数「ｄｏｕｂｌｅ  ｄ」の追加によりノードが置き換えられている。しかし、置き換えられた引数型ノード「ｄｏｕｂｌｅ  ｄ」と２つの文型ノード「ｂ＝ａ＋１」、「ａ．ｍｅｔｈｏｄ１（３）」との依存関係が存在しないため、不整合の数ｎは、２のままである。変更確度ｖは、図１５（ｂ）に示すように、図１４（ｂ）と同一である。
【００７２】
図１６（ａ）は、Ｓｔｅｐ３による編集操作を含んで、有向グラフに表した図である。文「ｂ＝ａ＋１；」を文「ｂ＝ｄ＋１．０；」に変更することにより、ノード「ｄｏｕｂｌｅ  ｄ」とノード「ｂ＝ｄ＋１．０」との間に依存関係が成立するので、引数「ｄｏｕｂｌｅ  ｄ」の追加による不整合の数ｎが１つ減って１になる。また、文「ｂ＝ｄ＋１．０；」の追加によって、型の違いによる不整合が生じることで、文「ｂ＝ｄ＋１．０；」の変更による不整合の数ｎが１になる。変更確度ｖは、各々の編集操作ごとに図１６（ｂ）に示すように計算できる。
【００７３】
図１７（ａ）は、Ｓｔｅｐ４による編集操作を含んで、有向グラフに表した図である。宣言「ｉｎｔ  ｂ；」を宣言「ｄｏｕｂｌｅ  ｂ；」に変更することにより、ノード「ｄｏｕｂｌｅ  ｂ」とノード「ｂ＝ｄ＋１．０」との間に依存関係が成立するので、文「ｂ＝ｄ＋１．０；」の変更による不整合の数ｎが１つ減って０になる。また、宣言「ｉｎｔ  ｂ；」を宣言「ｄｏｕｂｌｅ  ｂ；」へ変更することによる不整合はない。更に、引数「ｄｏｕｂｌｅ  ｄ」の追加による不整合の数ｎは、１のままである。変更確度ｖは、各々の編集操作ごとに図１７（ｂ）に示すように計算できる。
【００７４】
以上、図１３から図１７で説明したＪａｖａプログラムの変更による変更確度ｖは、図１８に示すように経過時間と共に、変更確度が大きくなるように変化していく。つまり、時間の経過により、変更が確定（チェックイン）される確率が上昇する。
【００７５】
次に、図１９に基づき、開発者が作業を行うために視認する表示部３２の仮想共有エディタ３３での表示例について説明する。図１９（ａ）は、仮想共有エディタ３３が表示するローカルモードでの表示例を示す。ローカルモードは、通常のエディタ（編集画面）と同じで、開発者自身の変更内容のみを表示する。このローカルモードの画面では、開発者は自由に編集作業を行うことができる。ここで編集操作を行うことで、上述した変更確度を随時算出する。
【００７６】
図１９（ｂ）は、共有モードでの表示例を示す。共有モードは、他の開発者の変更内容を、変更確度（複数人の開発者による変更がある場合には、共通変更確度）に応じて表示する。例えば、変更確度が小さいものほど、淡い色で変更部分を表示し、変更確度が大きくなるにつれ濃い色で変更部分を表示してもよい。また、変更確度が小さいものほど、小さいフォントで変更部分を表示し、変更確度が大きくなるにつれ、大きいフォントで変更部分を表示してもよい。なお、開発者による編集を行うことができない参照画面である。また、図１９（ｂ）に示すように、例えば、カーソルを変更した場所にあてることで、各変更内容を表示して、開発者が必要に応じて詳細を見られるようにしてもよい。
【００７７】
図１９（ｃ）は、比較モードでの表示例を示す。比較モードは、ローカルモードでの画面と、共有モードでの画面との両方を左右に並べて出力することで、変更部分の対応を比較できるように表示するものである。この図１９で説明するように、各モードの切り替えは、仮想共有エディタ３３に配置された切り替えボタンによって、開発者が任意に切り替え可能にしてもよい。なお、図１９では、Ｊａｖａプログラムのソースコードを表示する例で説明したが、例えば、変更確度の計算過程で用いた有向グラフ等を、グラフィカルに表示してもよい。
【００７８】
上述した機能を利用できるものは、Ｊａｖａプログラムによるソースコードに限られない。次に、図２０では、オブジェクト指向のソフトウェア開発における、プログラム設計図の統一表記法であるＵＭＬ（Ｕｎｉｆｉｅｄ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇｕａｇｅ）モデルを、本発明に適用する場合について説明する。図２０（ａ）は、開発中のＵＭＬモデルを示す。このＵＭＬモデルは、クラスＢは、クラスＡから「継承」されており、クラスＣは、クラスＢの「部分」であることを示している。
【００７９】
図２０（ｂ）は、この図２０（ａ）に示されたＵＭＬモデルを有向グラフで表したものである。「汎化」や「集約」を表す記号（関連）も１つのノードとして表す。ここで、図２０（ｂ）は、
１）クラス型ノードは、関連型ノードを任意個含む。
２）クラス型ノードは、関連型ノードによって他のクラスに対する依存関係を持つ。
の２つのルールにより、生成した有向グラフである。
【００８０】
ＵＭＬモデルの編集操作による具体例について、図２１に基づき説明する。まず図２１（ａ）は、ＵＭＬモデル及び有向グラフを示し、図２１（ｂ）は、時間の経過に伴って変化する変更確度を示す。図２１（ａ）（１）は、図２０（ａ）で示されたＵＭＬモデルから、クラスＢを削除する操作を行った場合である（Ｓｔｅｐ１）。その場合、有向グラフからは、クラスＢのノードが削除されるため、依存元のないエッジが３つ残り、不整合の数ｎ＝３である。この３つの不整合の内訳は、２つの関連に関するものと、１つのクラスに関するものである。
【００８１】
次に、図２１（ａ）（２）は、３０分後に、更に「集約」の関連（◆）を削除する操作を行った場合である（Ｓｔｅｐ２）。この削除により、前回の不整合の関連（◆）への依存と、クラスＣへの依存との不整合がなくなるため、不整合の数ｎ＝１である。また、関連（◆）を削除すること自体での不整合は発生しない。図２１（ｂ）は、上述の２つの変更に伴う変更確度の変化を示す。なお、変更確度は、上述の式２を用いて行い、式２のＣ１は６０分に、Ｃ２は２４時間にして算出している。
【００８２】
最後に、サーバ１０及びクライアント２０のハードウェア構成について説明する。図２２は、本発明の実施形態に係るサーバ１０及びクライアント２０のハードウェア構成を示す図である。以下は、コンピュータを典型とする情報処理装置として全般的な構成を説明するが、専用機や組み込み型装置の場合、その環境に応じて必要最小限な構成を選択できることはいうまでもない。また、以下、クライアント２０を例に説明するが、サーバ１０も同様の構成を有する。
【００８３】
クライアント２０は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１０１０、バスライン１００５、通信Ｉ／Ｆ１０４０、メインメモリ１０５０、ＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ  Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）１０６０、パラレルポート１０８０、ＵＳＢポート１０９０、グラフィック・コントローラ１０２０、ＶＲＡＭ１０２４、音声プロセッサ１０３０、Ｉ／Ｏコントローラ１０７０、並びにキーボード及びマウス・アダプタ等１１００の入力手段を備える。Ｉ／Ｏコントローラ１０７０には、フレキシブル・ディスク（ＦＤ）ドライブ１０７２、ハード・ディスク１０７４、光ディスク・ドライブ１０７６、半導体メモリ１０７８、等の記憶手段を接続することができる。グラフィック・コントローラ１０２０には、表示装置１０２２が接続されている。また、オプションとして、音声プロセッサ１０３０には、増幅回路１０３２及びスピーカ１０３４が接続される。
【００８４】
ＢＩＯＳ１０６０は、クライアント２０の起動時にＣＰＵ１０１０が実行するブートプログラムや、クライアント２０のハードウェアに依存するプログラム等を格納する。ＦＤドライブ１０７２は、フレキシブル・ディスク１０７１からプログラム又はデータを読み取り、Ｉ／Ｏコントローラ１０７０を介してメインメモリ１０５０又はハード・ディスク１０７４に提供する。
【００８５】
光ディスク・ドライブ１０７６としては、例えば、ＤＶＤ−ＲＯＭドライブ、ＣＤ−ＲＯＭドライブ、ＤＶＤ−ＲＡＭドライブ、ＣＤ−ＲＡＭドライブを使用することができる。この際は各ドライブに対応した光ディスク１０７７を使用する必要がある。光ディスク・ドライブ１０７６は光ディスク１０７７からプログラム又はデータを読み取り、Ｉ／Ｏコントローラ１０７０を介してメインメモリ１０５０又はハード・ディスク１０７４に提供することもできる。
【００８６】
クライアント２０に提供されるコンピュータ・プログラムは、フレキシブル・ディスク１０７１、光ディスク１０７７、又はメモリカード等の記録媒体に格納されて利用者によって提供される。このコンピュータ・プログラムは、Ｉ／Ｏコントローラ１０７０を介して、記録媒体から読み出され、又は通信Ｉ／Ｆ１０４０を介してダウンロードされることによって、クライアント２０にインストールされ実行される。コンピュータ・プログラムが情報処理装置に働きかけて行わせる動作は、既に説明した装置における動作と同一であるので省略する。
【００８７】
上述のコンピュータ・プログラムは、外部の記憶媒体に格納されてもよい。記憶媒体としてはフレキシブル・ディスク１０７１、光ディスク１０７７、又はメモリカードの他に、ＭＤ等の光磁気記録媒体、テープ媒体を用いることができる。また、専用通信回線やインターネットに接続されたサーバシステムに設けたハード・ディスク又は光ディスク・ライブラリ等の記憶装置を記録媒体として使用し、通信回線を介してコンピュータ・プログラムをクライアント２０に提供してもよい。
【００８８】
以上の例は、クライアント２０について主に説明したが、コンピュータに、情報処理装置で説明した機能を有するプログラムをインストールして、そのコンピュータを情報処理装置として動作させることにより上記で説明した情報処理装置と同様な機能を実現することができる。従って、本発明において１つの実施形態として説明した情報処理装置は、方法及びそのコンピュータ・プログラムによっても実現可能である。
【００８９】
本発明のクライアント２０は、ハードウェア、ソフトウェア、又はハードウェア及びソフトウェアの組み合わせとして実現可能である。ハードウェアとソフトウェアの組み合わせによる実施では、所定のプログラムを有するコンピュータ・システムでの実施が典型的な例として挙げられる。係る場合、該所定のプログラムが該コンピュータ・システムにロードされ実行されることにより、該プログラムは、コンピュータ・システムに本発明に係る処理を実行させる。このプログラムは、任意の言語、コード、又は表記によって表現可能な命令群から構成される。そのような命令群は、システムが特定の機能を直接実行すること、又は（１）他の言語、コード、もしくは表記への変換、（２）他の媒体への複製、のいずれか一方もしくは双方が行われた後に、実行することを可能にするものである。もちろん、本発明は、そのようなプログラム自体のみならず、プログラムを記録した媒体を含むプログラム製品もその範囲に含むものである。本発明の機能を実行するためのプログラムは、フレキシブル・ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＤＶＤ、ハード・ディスク装置、ＲＯＭ、ＭＲＡＭ、ＲＡＭ等の任意のコンピュータ可読媒体に格納することができる。係るプログラムは、コンピュータ可読媒体への格納のために、通信回線で接続する他のコンピュータ・システムからダウンロードしたり、他の媒体から複製したりすることができる。また、係るプログラムは、圧縮し、又は複数に分割して、単一又は複数の記録媒体に格納することもできる。
【００９０】
以上、本発明を実施形態に則して説明したが、本発明は上述した実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施形態又は実施例に記載されたものに限定されるものではない。
【００９１】
本実施形態では、チェックアウトしてからの経過時間をＴとして、変更確度を算出した。しかし、例えば、最初のチェックインをしてからの経過時間をＴとして、変更確度を算出してもよい。
【００９２】
本実施形態では、ＳＣＭリポジトリへのチェックイン及びチェックアウト処理をクライアントからの操作によりサーバで処理を行うものとして説明した。しかし、これに限らず、クライアントから直接サーバに対して制御してもよい。また、本実施形態では、変更確度の算出をクライアントで行っていたが、クライアントでの変更内容をサーバに送信して、サーバで変更確度の算出を行ってもよい。
【００９３】
本実施形態では、サーバとクライアントとを別のハードウェアである場合を例に説明したが、同一のハードウェアであってもよい。この場合、記憶部に共有部分と開発者の個別部分とを設けることで、例えば、同一の開発者が複数のソースコードについての変更を行う場合であって、ソースコード同士が競合するような場合においても、本機能を用いることができる。
【００９４】
本実施形態では、チェックアウトしたソースコードから有向グラフを生成するものであったが、サーバにソースコードの有向グラフを生成して記憶しておき、ソースコードと共に有向グラフをチェックアウトしてもよい。
【図面の簡単な説明】
【００９５】
【図１】本実施形態に係る開発支援システムの全体構成並びにサーバ及びクライアントの機能構成を示す図である。
【図２】Ｊａｖａプログラムと当該Ｊａｖａプログラムを抽象化した有向グラフの例を示す図である。
【図３】有向グラフにおける不整合のケースを示す図である。
【図４】変更確度の変化を示すグラフである。
【図５】変更確度を算出するための具体例を示す図である。
【図６】クライアントにおける全体の流れを示すフローチャートである。
【図７】チェックアウト処理を示すフローチャートである。
【図８】不整合検出処理を示すフローチャートである。
【図９】共有エディタの表示処理を示すフローチャートである。
【図１０】チェックイン処理を示すフローチャートである。
【図１１】変更確度の更新処理を示すフローチャートである。
【図１２】サーバにおける全体の処理の流れを示すフローチャートである。
【図１３】ソースコードに対する編集操作を行う具体例を示す図である。
【図１４】有向グラフによる説明図である。
【図１５】有向グラフによる説明図である。
【図１６】有向グラフによる説明図である。
【図１７】有向グラフによる説明図である。
【図１８】ソースコードの変更による変更確度の時間経過による変化を示す図である。
【図１９】仮想共有エディタでの表示例を示す図である。
【図２０】ＵＭＬモデルと当該ＵＭＬモデルを抽象化した有向グラフの例を示す図である。
【図２１】ＵＭＬモデルの編集操作による具体例を示す図である。
【図２２】クライアントのハードウェア構成を示す図である。
【符号の説明】
【００９６】
１    開発支援システム
１０  サーバ
１１  制御部
１２  ＳＣＭ制御手段
１３  共通変更確度算出手段
１７  ＳＣＭリポジトリ
１８  共有ワークスペース
２０  クライアント
２１  制御部
２２  読み出し手段
２３  有向グラフ生成手段
２４  不整合検出手段
２５  変更確度算出手段
２６  表示制御手段
３０  開発ワークスペース
３３  仮想共有エディタ
３４  操作部
【図１】
2010049419.tif 000011
【図２】
2010049419.tif 000012
【図３】
2010049419.tif 000013
【図４】
2010049419.tif 000014
【図５】
2010049419.tif 000015
【図６】
2010049419.tif 000016
【図７】
2010049419.tif 000017
【図８】
2010049419.tif 000018
【図９】
2010049419.tif 000019
【図１０】
2010049419.tif 000020
【図１１】
2010049419.tif 000021
【図１２】
2010049419.tif 000022
【図１３】
2010049419.tif 000023
【図１４】
2010049419.tif 000024
【図１５】
2010049419.tif 000025
【図１６】
2010049419.tif 000026
【図１７】
2010049419.tif 000027
【図１８】
2010049419.tif 000028
【図１９】
2010049419.tif 000029
【図２０】
2010049419.tif 000030
【図２１】
2010049419.tif 000031
【図２２】
2010049419.tif 000032