JP2010522397A - チーム環境におけるコラボレーション開発情報の使用 - Google Patents

Abstract

チームソフトウェア開発環境においてコラボレーション開発情報ストアを提供し、そのストアとやりとりする種々のテクノロジおよび手法が開示されている。サブミッションサービスは、複数ユーザによって使用される中央情報ストアに置かれているアプリケーションのアクティブメタモデルを更新する。ある特定ソフトウェア開発環境で動作している通知サービスはアクティブメタモデルに変更が行なわれたとの通知を受信する。通知サービスから受信した情報は、そのあと、その特定ソフトウェア開発環境においてディスプレイを更新するために使用される。データベースサーバ側には、複数ユーザによって開発中のアプリケーションのアクティブメタモデル情報を、その情報が変更されると受信する受信サービスが提供されている。受信したメタモデル情報を特定リレーショナルデータベース構造にストアするストレージサービスが提供されており、特定リレーショナルデータベース構造は、特定リレーショナルデータベース構造に変更を行なわなくてもアーティファクトの追加を可能にするように動作可能になっている。

Description

ソフトウェアアプリケーションが実行されるためにはそのアプリケーションはソースコードからマシン命令に変換されていなければならない。この変換プロセスは「コンパイル」と呼ばれている。コンパイル期間、最初にソースコードは言語にとらわれない(language-agnostic) およびマシンにとらわれない(machine-agnostic)命令セットに変換され、この命令セットは「中間コード」と呼ばれることもある。次に、この中間コードは、特定アプリケーションがそこで実行される特定コンピュータプラットフォームに固有のマシン命令に変換される。コンパイルはシングルコンピュータ上で行なわれるのが一般的であり、コンパイルが完了した時点で、コンパイルプロセスによって生成された中間コードは破棄される。従って、その後の開発プロセスでこの中間コードから得られた有用な情報はすべて失われている。

多くの場合、ソフトウェアアプリケーションはチームベースの環境で開発されている。これらのチームは、複数の役割をもち、全体的プロジェクト目標をサポートしているチームメンバで構成されている。各チームメンバは、ソフトウェア開発アプリケーションを各自のローカルコンピュータ上で実行しているのが一般的である。ある特定チームメンバがプログラムをコンパイルし、コードアナライザ(code analyzer)を実行してパフォーマンスを分析し、デバッギングまたはその他の開発関連タスクを実行するとき、これらのプロセスの結果として得られた詳細はそのチームメンバのローカルコンピュータにストアされているのが一般的である。チーム全体がアクセスできるソースコード制御サーバにそのチームメンバがソースコードをサブミットしている間に、開発プロセスの結果として得られ、サーバにチェックインされるバージョンとなった種々のシステム生成アーティクラフト(system generated artifact)は失われるか、容易に配信できないのが一般的である。このことは、これらの結果にアクセスすると得られるどのような恩恵も他のチームメンバが得られないことを意味している。例えば、チームメンバのある開発者が与えられたアプリケーションで作業しているとき、その開発者はコードプロファイラ(code profiler)を使用して、そのアプリケーションのパフォーマンスを分析することがある。このようにして、開発者はアプリケーションのパフォーマンスに関する具体的知識を得ている。アプリケーションをプロファイリングすることからアーティファクトを作成することによって得られたアーティファクトと知識はその開発者独自のものであり、共有が容易になっていない。

さらに、自分に割り当てられた役割を実行している過程で、チームメンバは、ソースコード自体のほかに、モデル、ダイヤグラム、ワークアイテムなどの、プロジェクトに関係する他のアーティファクトを作成することがよくある。システム生成アーティファクトとまったく同じように、多くの場合、これらのユーザ作成アーティファクトも特定のチームメンバのコンピュータにだけストアされるか、失われるか、あるいは他のチームメンバへの配信が容易になっていない。従って、チーム環境で開発中の特定のソフトウェア開発プロジェクトに関係する大量の有用な開発データとアーティファクトは、種々のチームメンバのコンピュータ間に分散されており、そのためにチーム全体によるアクセスが不可能であるか、あるいは永久に失われている。

チームソフトウェア環境においてコラボレーション開発情報ストアを提供し、そのストアとやりとりする種々のテクノロジおよび手法が開示されている。サブミッションサービスは、複数のユーザによって使用される中央情報ストア内のアプリケーションのアクティブメタモデルを更新する。特定のソフトウェア開発環境で動作している通知サービスは、アクティブメタモデルに変更が行なわれたとの通知を受信する。通知サービスから受信した情報は、そのあと、特定のユーザによって使用中の特定ソフトウェア開発環境においてディスプレイを更新するために使用される。一例（この例に限定されない）として、情報は、別のチームメンバのアクションの結果として発生した、その特定コードに関連するなんらかのものを注記するコードを特定ユーザがタイプしているとき表示することができる。

データベースサーバ側には、複数のユーザによって開発中のアプリケーションのアクティブメタモデル情報を、その情報が変更されたとき受信する受信サービスが提供されている。ストレージサービスは受信したアクティブメタモデル情報を特定のリレーショナルデータベース構造にストアするために提供され、特定リレーショナルデータベースは、その特定リレーショナルデータベースに変更を行なわなくてもアーティファクトが追加されるのを可能にするように動作可能になっている。

この概要説明は、「詳細説明」に詳しく下述されている概念のいくつかを選んで簡単に紹介したものである。この概要説明は、請求項に記載した主題のキーとなる特徴または基本的特徴を特定するものでも、請求項に記載した主題の範囲を判断するときの一助として使用されるものでもない。

コラボレーション開発情報ストアを使用したコンピュータシステムを示す概略図である。 図１のシステムの一実施形態のサブミッションおよび通知アプリケーションを示す概略図である。 図１のシステム上で動作する一実施形態のメタモデルストレージアプリケーションを示す概略図である。 図１のシステムのハイレベルステージを示す一実施形態のプロセスフロー図である。 中央情報ストアに置かれたアプリケーションのアクティブメタモデルとやりとりする際に関係するステージを示す一実施形態のプロセスフロー図である。 図１のシステムの一実施形態における中央情報ストアに収められたエレメント固有フィールドを示す図である。 図６に図示のエレメント固有フィールドを使用して定義された例示のエレメント定義を示す図である。 図１のシステムの一実施形態において中央情報ストアに収められたコネクション固有フィールドを示す図である。 図８に図示のコネクション固有フィールドを使用して定義された例示のコネクション定義を示す図である。 図１のシステムの一実施形態においてコネクション定義と共に使用できる特殊なプロパティを示す図である。 図１のシステムの一実施形態のコンピュータシステムを示す概略図である。

本発明の原理の理解を深めるために、以下では、図面および図面を説明するために使用される特有の表現で図示した実施形態を参照して説明する。なお、当然に理解されるように、本発明の範囲はこれによって限定されるものではない。下述する実施形態のいかなる改変およびさらなる変更も、および本明細書に記載されている原理をより詳細に適用することも、この分野の精通者ならば普通に行なうように、本発明の意図とするものである。

システムは、広い意味でソフトウェア開発アプリケーションとして説明することができる。本明細書に記載されている手法の１つまたは２つ以上は、MICROSOFT（登録商標）VISUAL STUDIO（登録商標）などのソフトウェア開発プログラム内のフィーチャとして実現することも、チーム環境においてソフトウェア開発プロセスにかかわりのある他のタイプのプログラムまたはサービスからのフィーチャとして実現することもできる。

一実施形態において、開発者および／または他のユーザのチームによって開発中の特定のソフトウェアアプリケーションに関するリアルタイムのアクティブメタモデル情報をストアするために中央データベースまたは他の情報ストアを使用するシステムが提供されている。本明細書の中で用いられている「アクティブメタモデル(active meta-model)」という用語は、アプリケーションのカレントステート、アプリケーションの構造、およびアプリケーションがどのように展開したかのヒストリを反映しているシステム生成アーティファクト(system-generated artifact)およびユーザ生成アーティファクト(user-generated artifact)を意味している。システム生成アーティファクトには、アプリケーション構造、中間コード、注釈、およびシステムが生成するその他の解析データが含まれている。ユーザ生成アーティファクトには、基礎となるアプリケーション構造と潜在的に関連づけられる可能性のあるワークアイテム、プロジェクトプラン、ダイヤグラム、ある種のコードを説明した注釈などが含まれている。そのあと、中央データベースは開発者のチームによって使用中のソフトウェア開発アプリケーションによってアクセスされ、チームが亜アクティブメタモデル情報にアクセスできるようにする。この情報にアクセスできるようにすると、開発者は、他の人々のチームによって開発中のアプリケーションのアクティブステートに関するリアルタイムの関連情報を得ることができる。一例（この例に限定されない）として、この情報には、開発者Ａが自分のコードからコールしようとしているコードのある部分が、開発者Ｂによって実行中のコードプロファイリングプロセス(code profiling process)によって「遅速(slow)」とマークされたことを開発者Ａに通知することを含めることができる。一実施形態では、これは、あるコードモジュール、タイプ、メソッドなどのパフォーマンス特性をメタ表現(meta representation)と関連付けることによって行なわれる。従って、開発者Ｂが問題のメソッドへのコールを追加すると、Ａによって追加された関連のパフォーマンスデータを見つけることができ、アクションをとることができる。

図１に示すように、システムの１または２以上の部分を実現するために使用する例示のコンピュータシステムは、中央情報ストア１０、ネットワーク１２、および開発マシン１４ａ、１４ｂ、および１４ｃのような１または２以上の開発マシンを備えている。開発マシンは、ソフトウェアアプリケーションを書く目的でソフトウェア開発者によって使用されるコンピュータである。中央情報ストア１２は、データをストアし、他のネットワークリソースがそのデータにアクセスするのを可能にする１または２以上のコンピュータを含んでいる。一実施形態では、中央情報ストア１２は、チーム環境において複数のユーザによって開発中のアプリケーションのアクティブメタモデル情報(active meta-model information)をストアしている。一実施形態では、より大規模なプロジェクトでより多くのピアツーピアレベルの共有に参加するのを可能にし、および／または中央ストアを使用しない実施形態を可能にする、といった目的のために、代替的にまたは付加的に、ローカル中央情報ストア１２を開発マシン１４ａ、１４ｂ、および１４ｃの１または２以上にストアしておくことができる。ネットワーク１２は、開発マシン１４ａ、１４ｂ、１４ｃと中央情報ストア１０との間のコミュニケーションを提供するために使用される。ネットワーク１２は、ワイヤードまたはワイヤレスコネクションを使用してローカルエリアネットワーク、ワイドエリアネットワーク、インターネット上のネットワークとして実現することも、および／またはコンピュータソフトウェア分野の通常知識者ならば行うように他の変種ネットワークにおいて実現することも可能である。

次に、図１に引き続き図２を参照して説明すると、コンピューティングデバイス６００上で稼動するサブミッションおよび通知アプリケーション２００(submission and notification application)が示されている。このサブミッションおよび通知アプリケーション２００は、コンピューティングデバイス６００（図１１）に置かれているアプリケーションプログラムの１つである。一実施形態では、サブミッションおよび通知アプリケーション２００は開発ワークステーション１４Ａ、１４Ｂ、または１４Ｃ（図１）の１つまたは２つ以上に置かれている。なお、当然に理解されるように、サブミッションおよび通知アプリケーション２００は、代替的にまたは付加的に、１または２以上のコンピュータ上にコンピュータ実行可能命令として具現化することも、および／または図１に図示のものとは異なる変種で実現することも可能である。代替的にまたは付加的に、サブミッションおよび通知アプリケーション２００の１または２以上の部分は、システムメモリ６０４（図１１）の部分にすることも、他のコンピュータおよび／またはアプリケーション６１５（図１１）上のものにすることも、コンピュータソフトウェア分野の知識者ならば行なうような他の変種にすることも可能である。サブミッションおよび通知アプリケーション２００は、本明細書に記載した手法の一部または全部の実行を担当するプログラムロジック２０４を含んでいる。プログラムロジック２０４には、アプリケーションのアクティブメタモデル（例：中間コード、注釈、ユーザ生成アーティファクトなど）の少なくとも一部を、複数のユーザによる使用のために中央情報ストアにサブミットするように動作可能であるサブミッションサービスを提供するためのロジック２０６、アクティブメタモデルの変更（プロセスによる、ユーザによる、など）に関する通知を受信するように動作可能である通知サービスを提供するためのロジック２０８、メタモデル情報をユーザに表示するように通知サービスをさらに動作可能にするためのロジック２１０、通知サービスを開発環境に組み入れてメタモデル情報がその環境で表示されるようにするためのロジック２１２、およびアプリケーションを動作させるためのその他のロジック２２０が含まれている。一実施形態では、プログラムロジック２０４は、プログラムロジック２０４の中でプロシージャへのシングルコールを使用するといったように、別のプログラムからプログラムでコールされるように動作可能になっている。

次に、図１に引き続き図３を参照して説明すると、コンピューティングデバイス６００（図１１）上で稼動するメタモデルストレージアプリケーション２４０が示されている。メタモデルストレージアプリケーション２４０は、コンピューティングデバイス６００上に置かれているアプリケーションプログラムの１つである。なお、当然に理解されるように、メタモデルストレージアプリケーション２４０は、代替的にまたは付加的に、１または２以上のコンピュータ上のコンピュータ実行可能命令として具現化することも、および／または図１１に図示のものとは異なる変種で具現化することも可能である。代替的にまたは付加的に、メタモデルストレージアプリケーション２４０の１または２以上の部分は、システムメモリ６０４（図１１）の部分にすることも、他のコンピュータおよび／またはアプリケーション６１５（図１１）上のものにすることも、コンピュータソフトウェア分野の知識者ならば行なうような他の変種にすることも可能である。

タモデルストレージアプリケーション２４０は、本明細書に記載した手法の一部または全部の実行を担当するプログラムロジック２４４を含んでいる。プログラムロジック２４４には、複数のユーザによって開発中のアプリケーションのアクティブメタモデル情報を受信する受信サービスを提供するためのロジック２４６、特定リレーショナルデータベース構造に変更を行なわなくてもアーティファクトが追加されるのを可能にするように動作可能である特定リレーショナルデータベース構造内に受信したアクティブメタモデル情報をストアするように動作可能であるストレージサービスを提供するためのロジック２４８、アクティブメタモデル情報をリトリーブするリクエストを、アクティブメタモデルに対する変更を１または２以上のクライアントデバイスに通知するように動作可能である通知サービスから受信するためのロジック２５０、特定エレメントを識別する名前およびそのエレメントを記述したデータを特定リレーショナルデータベース構造にストアすることを可能にするためのロジック２５２、特定のコネクションを識別する名前、その特定コネクションを記述したデータ、その特定コネクションのソース、およびその特定コネクションのデスティネーションを特定リレーショナルデータベース構造にストアすることを可能にするためのロジック２５４、特定コネクションに関する関連性情報を収めているフィールドを特定リレーショナルデータベース構造にストアすることを可能にするためのロジック２５６、およびアプリケーションを動作させるための他のロジック２６０が含まれている。一実施形態では、プログラムロジック２４４は、プログラムロジック２４４の中でプロシージャへのシングルコールを使用するといったように、別のプログラムからプログラミングによってコールされるように動作可能になっている。

次に、図１に引き続き図４−５を参照して、図１のシステムの１または２以上の実施形態を実現するためのステージについて詳しく説明する。図４は、図１のシステムの１実施形態のハイレベルステージを示すプロセスフロー図である。一形態では、図４のプロセスは、少なくともその一部がコンピューティングデバイス６００の動作ロジックに実現されている。図４に示すステップはある順序で記載されているが、当然に理解されるように、これらのステップはどの順序で実行されるとも、および／または相互に同時に実行されることも、まったく実行されないことも可能である。このプロセスはスタートポイント２７０からスタートし、チーム環境において複数のユーザが開発中のシステム生成アーティファクトとユーザ生成アーティファクトを表すために使用されるエレメントおよび関連性(relevancy)のダイナミック定義用のフレームワークを提供する（ステージ２７２）。システム生成アーティファクトおよびユーザ生成アーティファクトは、各チームメンバがアーティファクトを作成および／または変更すると中央情報ストアにアクティブメタモデルとしてストアされる（ステージ２７４）。各チームメンバによって使用されるソフトウェア開発アプリケーションは中央情報ストアと定期的にやりとりして、アクティブメタモデルに行なわれた関連の更新を特定する（ステージ２７６）。更新された情報は、問題や特定のチームメンバが現在行なっているなんらかのものに役立つような情報をその特定チームメンバに通知するといった目的のために使用される（ステージ２７８）。このプロセスはエンドポイント２８０で終了する。

図５は、中央情報ストアに置かれたアプリケーションのアクティブメタモデルとやりとりする際にかかわりのあるステージを示す一実施形態のプロセスフロー図である。一形態において、図５のプロセスは、少なくともその一部がコンピューティングデバイス６００（図１１）の動作ロジックに実装されている。図５に示すステップはある順序で記載されているが、当然に理解されるようにこれらのステップはどの順序で実行されるとも、および／または相互に同時に実行されることも、まったく実行されないことも可能である。このプロセスはスタートポイント２９０からスタートし、ソフトウェア開発アプリケーションのコンポーネントなどのサブミッションサービスと通信して、中央情報ストアに置かれたアプリケーションのアクティブメタモデルを更新する（ステージ２９２）。一実施形態では、これらの更新は、それぞれの各チームメンバが特定のソフトウェアアプリケーションをさらに開発するたびにそのチームメンバのワークステーションによって送信される。任意のどの瞬時においても、それぞれのチームメンバのワークステーションの１または２以上は、アクティブメタモデルに対する変更の通知を通知サービスから受信することができる（ステージ２９４）。これらの変更は、特定チームメンバ自身によって、または別のチームメンバによって行なわれた作業がきっかけになることがある。通知は変更だけに限らず、その変更を越えて構成可能にできるので、さまざまな理由で特定のイベントが発生したことをその基礎となる情報と一緒に示すことができる。例えば、対応する通知および人々を特定するために使用されるロジックは、ポリシに基づいて限定することも、および／または拡張することもできる。これの例として、一年前にあるコードセクションで作業していた開発者は、行なわれたばかりの仕様の変更の更新通知を受信しないことがあるが、２週間前にソースコードで作業していた開発者は、だれに、そしていつ通知すべきかを示すシステムワイドのセッティングに基づいて更新通知を受信することになる。

通知サービスは、それぞれのチームメンバによって使用されるソフトウェア開発アプリケーションにおけるディスプレイを、変更を記述した該当の情報で更新するために使用される（ステージ２９６）。一実施形態では、ソフトウェア開発アプリケーションはアクティブメタモデルに対する変更をインターセプトして分析したあと、いつ、どのような方法でユーザに通知するかを判断する。別の実施形態では、ソフトウェア開発アプリケーションは通知を受信するが、その通知をフィルタリングおよび／または解釈することなく表示するだけである。ユーザに表示できるタイプの情報のいくつかの例（これらの例に限定されない）として、ポリシ違反アラート(policy violation alert)、従属関係アラート(dependency alert)、パフォーマンスアラート(performance alert)、修正アラート(modification alert)などがある（ステージ２９６）。ポリシ違反アラートは、システムに対してセットされたポリシに違反するような形でアクティブメタモデルに影響する変更をユーザが行なったことを示すことができる。従属関係アラートは、いま変更しようとしているあるコードが使用可能でなくなったなんらかのもの、「遅速」とマークされたなんらかのもの、別のユーザによって現在編集中であるなんらかのもの、などに従属していることをユーザに知らせることができる。パフォーマンスアラートは、同じコードが、そのコードで以前に作業していた別のユーザによって実行が遅速とマークされたことをユーザに知らせることができる。これらは、中央情報ストアに置かれたアクティブメタモデルを分析したときシステムから出されるタイプの情報の例をいくつか挙げたものにすぎず、これらの例に限定されない。このプロセスはエンドポイント２９８で終了する。

次に、図６−１０を参照して説明すると、中央情報ストアに置かれていて、チーム開発環境で使用されるアクティブメタモデルを実現するために使用できる例示のデータベース構造を示すためにいつかの図が使用されている。図６は、図１のシステムの一実施形態において中央情報ストアに置かれたエレメント固有フィールド(element-specific field)３５０を示す図である。一実施形態において、抽象ストレージ定義(abstract storage definition)が必要であるのは、プログラムと注釈が幅広く変化するからである。しかし、一実施形態に関して本明細書に記載されているスキーマの全体構造に限定されず、本明細書に記載されている手法の一部または全部を実現するためにその他の種々データベーススキーマを使用することも可能である。一実施形態において、エレメントは、中央情報ストアにおいて名詞として使用される総称アイテム(generic item)である。エレメントの例をいくつか挙げると、メソッド、タイプ、アセンブリ、メタデータ属性などがあるが、これらの例に限定されない。個々のエレメントは、その一般的定義において必要とされるだけプロパティをいくつでももつことができる。各ツール、ベンダ、および／またはシステムはエレメントをダイナミックに定義して、必要に応じてデータを提供することができる。各エレメントは、名前フィールド３５２をデータフィールド３５４と共に収めている。名前フィールド３５２は、システム内のエレメントを記述したストリングである。データフィールド３５４は、エレメントに関する詳細をストアするバイナリパケットである。

図７は、一実施形態においてアセンブリを定義するために使用されているエレメントの例を示す図である。プログラム構造は、一般的システム提供情報の一部である。アセンブリは、データストアによってエレメントとして参照されないが、ベンダおよび／またはシステムからのツールは、必要に応じてこれらのアセンブリエレメントに注釈を付けることができる。これにより、この特定アセンブリの低レベル部分で作業している開発者のほうは、関連情報を得ることができる。システムに共有エレメントがないと、ローカルデスクトップ上でアセンブリから作業しているツール間の関連性は、そのアセンブリに対してたまたま起っている小さなアーティファクトおよび／または作業と相関付けることが困難になる。例えば、開発者Ｘがメソッド１に対するテストケースで作業しており、そのメソッドはクラスの一部であり、クラスは名前空間の一部であり、名前空間はアセンブリＺの一部であり、アセンブリＺはテストカバレッジ(test coverage)をまったく必要としないとマークされていると想定する。システムは、アセンブリＺで要求条件を定義しているユーザに、開発者Ｘのデスクトップでなにが起こっていたかの具体的知識がなくても、書かれているテストケースが必須でないことを開発者Ｘに通知することが可能になる。

次に、図８を参照して説明すると、図８は、一実施形態において中央情報ストアに置かれているコネクション特定フィールド(connection-specific field)４００を示す図である。一実施形態において、コネクションは中央情報ストアにおいて動詞として使用される総称アイテムである。コネクションの例をいつか挙げると、depends（従属）、contains（収容）、authored（作成）などがあるが、これらの例に限定されない。コネクションは２またはそれ以上のエレメントを関係付けるために使用される。各コネクションはソースフィールド４０２とデスティネーションフィールド４０４を収めている。図９は、“depends”コネクションタイプを定義するために使用されているコネクションの例を示す図である。中央情報ストアは、定義したタイプ間の関連性の表現に依存している。これらの関連性は、名詞間のダイナミック作業リンク(dynamic working link)の働きをし、付加的関係ディメンション(additional dimension of relation)を提供する。例えば、アセンブリＡをエレメントとしてもち、クラスＺをエレメントとして持っていると想定する。両方とも、システムがツールからの注釈を共有ストア内に反映したあと、その注釈をアセンブリＡおよびクラスＺと関連付けることができる。しかし、タイプ“contains”のコネクションは、さらに、アセンブリＡがクラスＺを収容していることを表すので、コネクションがないと、この関連性が不可能になることがある場合に関連性ルックアップ(associative lookups)を行なうことができる。一実施形態では、ダイナミック関係は、それ自体ダイナミックに定義される。

図１０は、図１のシステムの一実施形態においてコネクション定義と共に使用できる特殊関連性プロパティ(special relevancy property)を示す図５００である。一実施形態では、関連性はすべてのコネクションと関連付けられた特殊なプロパティである。一般的には、関連性は２エレメント間の関係がエレメント間の関係に対してどれだけ重要であるかを表している。２エレメント間の関係に対する関連性値はエレメント間のコネクションに割り当てられる。関連性単位(relevancy unit)は、コネクションに注目する個々のベンダによって定義することも、および／またはシステムによって定義することもできる。中央情報ストアに対して変更が行なわれると、データとその効果の総合的使用はストアによって反映される。関連性は、アーティファクト間の動詞の重み付けを可能にするメカニズムを提供する。このようにすると、システムは種々の形態の関係について異なる使い方をすることができる。一実施形態では、関連性がシステムの重要な部分となっているのは、アイテム間の関連付けが数１０万の数になることがあるからである。その他の実施形態では、関連性はそれほど重要でなく、および／または使用されないことさえある。

一実施形態において、トラスト(trust)は、システムによってユーザ、ベンダおよび／またはベンダ提供ツールに与えられる付加的特殊プロパティである。システムのデータが展開されると共に、ツールとユーザの発見(finding)は経時的に変化していく。ツールが不正確であると判明した場合は、特定のベンダ、ツールまたはユーザに関連付けられたデフォルトのトラストウェイトが変更されることがある。そのようにすることは、関連性計算が変更され、トラストファクタの倍率に応じてその計算を正または負に重み付けすることを意味している。例えば、コードのスタティック分析を使用すると、テストケースと開発メソッドとのコール関係を調べることによってテストケースとコードの間のリンクを見つけることができる。この例では、ツールＸはこれらの関係を調べ、スタティック関係に基づいてテストコードと開発メソッドの間のリンクを追加する。デフォルトでは、システムはこれらの関係を調べ、これらのリンクによって接続されたモジュールに対する変更をユーザに通知する。テストＡが開発メソッドＢをコールし、メソッドＢが変化したときは、Ａの作成者に通知されるはずである。しかし、開発サイクルが進捗するのに伴い、変更が通知されるユーザは、気にしていないときになん度も、通知されることがある。これは、コネクションがより重要であるか、より重要でないかを意味する可能性のある追加のファクタ（コード複雑性、コール数など）をツールＸが考慮しないためである。ユーザからのネガティブフィードバックのすべてに起因して、アドミニストレータまたはシステムはツールＸのトラストレーティングを低くすることができる。直接的結果として、ユーザに変更が通知される対象となる計算が行なわれるとき、ツールＸのリンクからの２ユーザ間のコネクションはツールＹについては異なったレーティングがされ、その場合には、ツールＸの情報はトラストが低下することになる。

図１１に示すように、システムの１または２以上の部分を実現するために使用する例示のコンピュータシステムは、コンピューティングデバイス６００のようなコンピューティングデバイスを含んでいる。その最も基本的な構成では、コンピューティングデバイス６００は、少なくとも１つの処理ユニット６０２とメモリ６０４を装備しているのが代表的である。コンピューティングデバイスの正確な構成とタイプに応じて、メモリ６０４は揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュメモリなど）またはこれらの２つを組み合わせたものにすることができる。この最も基本的な構成は図１に破線６０６で示されている。

さらに、デバイス６００は、追加の特徴／機能を備えていることもある。例えば、デバイス６００は、追加のストレージ（取り外し可能および／または取り外し不能）を装備していることもあり、その中には磁気または光学ディスクまたはテープが含まれているが、これらに限定されない。このような追加ストレージは図１１に取り外し可能ストレージ６０８と取り外し不能ストレージ６１０で示されている。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュールまたはその他のデータなどの情報をストアするためのなんらかの方法またはテクノロジで実現された揮発性および不揮発性の取り外し可能および取り外し不能の媒体が含まれている。メモリ６０４、取り外し可能ストレージ６０８および取り外し不能ストレージ６１０は、いずれもコンピュータ記憶媒体の一例である。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリテクノロジ、ＣＤ−ＲＯＭ、ＤＶＤ(digital versatile disk)またはその他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたはその他の磁気ストレージデバイス、または望みの情報をストアするために使用可能で、デバイス６００によってアクセス可能であるその他のいずれかの媒体が含まれているが、これらに限定されない。このようなコンピュータ記憶媒体は、いずれもデバイス６６０の一部になっていることがある。

コンピューティングデバイス６００は、コンピューティングデバイス６００が他のコンピュータ／アプリケーション６１５と通信するのを可能にする１または２以上の通信コネクションを備えている。デバイス６００は、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイスなどの入力デバイス６１２を備えていることもある。ディスプレイ、スピーカ、プリンタなどの出力デバイスが装備されていることもある。これらのデバイスはこの分野では周知であるので、ここで詳細に説明することは省略する。一実施形態では、コンピューティングデバイス６００は、サブミッションおよび通知アプリケーション２００およびメタモデルストレージアプリケーション２４０を備えている。

以上、構造上の特徴および／または方法上のアクトに特有の表現で主題を説明してきたが、当然に理解されるように、請求項に記載した主題は上述した特定の特徴またはアクトに限定されない。むしろ、上述した特定の特徴およびアクトは、請求項を実現する形態の例として開示されたものである。本明細書および／または請求項に記載されている実施形態の精神の範囲内に属する等価物、変更および改良は、すべて保護の対象となるものである。

例えば、コンピュータソフトウェア分野の通常知識者ならば認識されるように、本明細書に説明されている例の中で記載されているクライアントおよび／またはサーバ構成、ユーザインタフェーススクリーンコンテンツ、および／またはデータレイアウトは、１または２以上のコンピュータ上で異なる編成にして、例に示したものとは少ない、または付加的オプションまたは特徴を含めることが可能である。

１０ 中央情報ストア
１２ ネットワーク
１４ａ、１４ｂ、１４ｃ 開発マシン
１４Ａ、１４Ｂ、１４Ｃ 開発者マシン
２００ サブミッションおよび通知アプリケーション
２０４、２４４ プログラムロジック
２０６、２４６ ユーザ
２０８、２５０ アクティブメタモデル
２１０、２１２、２２０ ロジック
２４０ メタモデルストレージアプリケーション
２４８ 特定リレーショナルデータベース構造
２５２ エレメント
２５４、２５６ 特定コネクション
２６０ アプリケーション
３５０ エレメント固有フィールド
３５２ 名前フィールド
３５４ データフィールド
４０２ ソースフィールド
４０４ デスティネーションフィールド
６００ コンピューティングデバイス
６０４ システムメモリ
６０８ 取り外し可能ストレージ
６１０ 取り外し不能ストレージ
６１１ 出力デバイス
６１２ 入力デバイス
６１５ コンピュータおよび／またはアプリケーション

Claims (20)

1. コンピュータ実行可能命令を収めたコンピュータ可読媒体であって、前記コンピュータ実行命令は、
   アプリケーションのアクティブメタモデルの少なくとも一部を、複数のユーザによる使用のためにサブミットするように動作可能であるサブミッションサービスを提供するステップと、
   アクティブメタモデルの変更に関する通知を受信するように動作可能である通知サービスを提供するステップと、
   をコンピュータに実行させるためのものであることを特徴とするコンピュータ可読媒体。
2. 通知サービスは、プロセスによって行なわれた変更を受信するように動作可能であることを特徴とする請求項１に記載のコンピュータ可読媒体。
3. 通知サービスは、ユーザの操作によって行なわれた変更を受信するように動作可能であることを特徴とする請求項１に記載のコンピュータ可読媒体。
4. アクティブメタモデルは中間コードを収めていることを特徴とする請求項１に記載のコンピュータ可読媒体。
5. アクティブメタモデルは注釈を収めていることを特徴とする請求項１に記載のコンピュータ可読媒体。
6. アクティブメタモデルはユーザ生成アーティファクトを収めていることを特徴とする請求項１に記載のコンピュータ可読媒体。
7. 通知サービスは、さらに、複数のユーザのうちの特定ユーザにメタモデル情報を表示するように動作可能であることを特徴とする請求項１に記載のコンピュータ可読媒体。
8. 通知サービスは、開発環境に組み込まれてメタモデル情報が開発環境において表示されるように動作可能であることを特徴とする請求項１に記載のコンピュータ可読媒体。
9. コンピュータ実行可能命令を収めたコンピュータ可読媒体であって、前記コンピュータ実行命令は、
   複数のユーザによって開発中のアプリケーションのアクティブメタモデル情報を受信するように動作可能である受信サービスを提供するステップと、
   特定のリレーショナルデータベース構造に変更を行なわなくてもアーティファクトの追加を可能にするように動作可能である特定のリレーショナルデータベース構造内に、受信したアクティブメタモデル情報をストアするように動作可能であるストレージサービスを提供するステップと、
   をコンピュータに実行させるためのものであることを特徴とするコンピュータ可読媒体。
10. アクティブメタモデル情報をリトリーブするリクエストを通知サーバから受信するステップを、コンピュータに実行させるためのコンピュータ実行可能命令をさらに収めており、前記通知サービスは、アクティブメタモデルに対する変更を１または２以上のクライアントデバイスに通知するように動作可能であることを特徴とする請求項９に記載のコンピュータ可読媒体。
11. 特定リレーショナルデータベース構造は、特定エレメントを識別する名前およびそのエレメントを記述したデータをストアするように動作可能であることを特徴とする請求項９に記載のコンピュータ可読媒体。
12. 特定リレーショナルデータベース構造は、特定コネクションを識別する名前、特定コネクションを記述したデータ、特定コネクションのソース、および特定コネクションのデスティネーションをストアするように動作可能であることを特徴とする請求項９に記載のコンピュータ可読媒体。
13. 特定リレーショナルデータベース構造は、特定コネクションに関する関連性情報をストアするように動作可能であることを特徴とする請求項１２に記載のコンピュータ可読媒体。
14. ソフトウェア開発アプリケーションを提供するための方法であって、
    複数のユーザによって使用される中央情報ストアに置かれたアプリケーションのアクティブメタモデルを更新するためにサブミッションサービスと通信するステップと、
    アクティブメタモデルに対する変更の通知を通知サービスから受信するステップと、
    ソフトウェア開発アプリケーションにおいてディスプレイを更新するために通知サービスを使用するステップと、
    を含むことを特徴とする方法。
15. サブミッションサービスは、ソフトウェア開発アプリケーションのコンポーネントであることを特徴とする請求項１４に記載の方法。
16. 通知サービスは、ポリシ違反アラートを提供することを特徴とする請求項１４に記載の方法。
17. 通知サービスは、従属関係アラートを提供することを特徴とする請求項１４に記載の方法。
18. 通知サービスは、パフォーマンスアラートを提供することを特徴とする請求項１４に記載の方法。
19. 通知サービスは、アプリケーションコードが別のユーザによって現在修正中であることを知らせるアラートを提供することを特徴とする請求項１４に記載の方法。
20. 請求項１４に記載のステップをコンピュータに実行させるためのコンピュータ実行可能命令を収めていることを特徴とするコンピュータ可読媒体。

Images