JP2009129326A - ソフトウェア開発システム、そのアクセス制限方法、サーバ装置、プログラムおよび記憶媒体 - Google Patents

Abstract

【課題】機密情報へのアクセス制限を実現した上で、プログラムの開発作業を効率的に行える開発環境を備えたソフトウェア開発システムを提供する。
【解決手段】開発環境制御部２０４は、アクセス権判定部２０５により対象のソースコードのアクセス権を判断し、ソースコードがアクセス制限対象である場合、その制限に従い、ソースコードを表示するか、インターフェースのみに制限して表示するか、もしくは表示を行わない。また、対象のソースコードがアクセス制限の対象でない場合、外部インターフェースの利用を抽出し、その外部インターフェースの利用が可能な場合、ソースコードを表示し、利用が不可能な場合、インターフェースのみに制限して表示する。
【選択図】図２１

Description

本発明は、ソースファイルにアクセス権限を設定し、その権限に従って、ソースファイルへのアクセス制御を行うソフトウェア開発システム、そのアクセス制限方法、サーバ装置、プログラムおよび記憶媒体に関する。

ソフトウェアの開発において、外部のソフトウェア製造業者が製造したプログラムモジュールをプログラムの一部として組み込む場合がある。その際、プログラムモジュールが機密情報を含むものである場合、そのソースコードを開示する対象を、一部の開発者のみに限定する必要がある。

また逆に、外部のソフトウェア製造業者に一部のプログラムモジュールの製造を委託する場合もある。その際、開発するソフトウェアに、機密情報を含むプログラムモジュールがある場合、そのプログラムモジュールのソースコードを外部のソフトウェア製造業者に提供することはできない。

ソフトウェアの開発では、実行可能な全てのプログラムモジュールを提供する必要があるため、上記のような場合、ソースコードを提供する代わりに、コンパイルされたオブジェクトやライブラリを配布することが行われている。

しかし、ソースコードをコンパイルし、オブジェクトを作成、配布することは、コストのかかる作業である。また、ソースコードのバージョンに合わせて、コンパイルされたオブジェクトのバージョン管理を行う必要や、実行されるプラットフォームが複数ある場合、プラットフォーム毎にオブジェクトを用意する必要があった。

また、顧客データなど、セキュリティ上、データの持ち出しが制限されるデータを用いてソフトウェアを開発する場合、そのデータの利用が必要な場合がある。例えば、プログラムの不具合の解析作業で、実際の顧客データを必要とする場合があるが、その際、データの持ち出しが制限されるため、開発作業を実施する作業場所が制限されていた。

ところで、特許文献１に記載の「暗号解読コンパイラ」では、オブジェクトを配布する代わりに、暗号化したソースコードを配布し、コンパイラが暗号を解読してコンパイルすることで、オブジェクトを作成して配布する作業コストを減らす方法が公開されている。

また、特許文献２に記載の「ソフトウェアへのアクセスを許可する方法、システム、およびプログラム製品」では、開発ツールで開発対象のターゲット、つまり、ソースコードや、データなどに対して、アクセス制御を行う方法が公開されている。
特開２００１−１３４３３７号公報 特表２００５−５０６６０６号公報

しかしながら、上記従来の前者の場合、開発中のソースコードは、常に変化する可能性が高く、特に、プログラムのデバッグ作業中においては、修正作業が繰り返される。このため、そのたびに配布作業を行っていては、大きな時間的なコストが発生する。また、機密保護対象となるプログラムモジュール自身も含めて開発途中である場合、ソースコードを暗号化し、配布する作業を行うことには問題がある。

また、上記従来の後者の場合、ソフトウェアの開発においては、ソースコードをコンパイルし、プログラムの実行が行える環境が提供されなければならない。そのためには、ソースコードや、プログラムの動作に必要なデータを開発環境上に配置する必要がある。しかし、ソースコードや、データの配置が、ローカルの端末など、開発ツール以外から、容易にアクセス可能な場所にあっては、開発ツールでアクセス制限が行われていても、機密保持ができない。そのため、開発ツール以外からは直接アクセスできない場所に、ソースコードやデータが配置された開発環境を用意する必要がある。

また、ソフトウェア開発において、複数のプログラムモジュールを、複数の開発担当者が分担して作業を行うことになるが、機密情報を含むプログラムモジュールも、別のプログラムモジュールから利用されることになる。そのため、機密情報を含むプログラムモジュールの利用法を示すもの、つまりインターフェース定義は、利用されるためには公開されていなければならない。

しかし、インターフェースが公開されていると、そのモジュールが提供している機能を知ることができるため、このインターフェース定義そのものも、また機密情報である場合もある。そのため、機密保護の対象のインターフェースは、利用を許可した開発者のみに限定して公開する必要がある。また、その機密保護対象のインターフェースを利用しているプログラムモジュールには、そのインターフェースを利用したソースコードが記述されることになる。そこから、機密保護対象の機能や利用方法を知ることが可能になる。つまり、機密保護対象のインターフェースを利用しているプログラムモジュール自体も機密保護の対象とすべきである。

ここで、例えば、ソースコードへのアクセスを、開発者自身が担当するプログラムモジュールのみに限定する方法も考えられる。しかし、プログラムの開発、特に、プログラムの不具合を解析する作業においては、担当プログラムモジュール以外のプログラムモジュールの内容、つまり、ソースコードが参照可能であることは、解析作業を効率的に行うためには、非常に重要である。そのため、機密保護は必要な箇所にのみ限定的に行われることが好ましい。

そこで、本発明は、機密情報へのアクセス制限を実現した上で、プログラムの開発作業を効率的に行える開発環境を備えたソフトウェア開発システムを提供することを目的とする。同様に、本発明は、そのようなソフトウェア開発システムのアクセス制限方法、サーバ装置、プログラムおよび記憶媒体を提供することを目的とする。

本発明は、機密保護対象のプログラムモジュールのソースコードに対し、そのモジュールの利用が許可された開発者による機密保護対象のインターフェースへのアクセスは制限されない開発環境を備えたソフトウェア開発システムを提供することを他の目的とする。この場合、それ以外の開発者による機密保護対象のインターフェースへのアクセスは制限される。同様に、本発明は、そのようなソフトウェア開発システムのアクセス制限方法、サーバ装置、プログラムおよび記憶媒体を提供することを他の目的とする。

上記目的を達成するために、本発明のソフトウェア開発システムは、開発対象のソースコードを含む開発環境を備えたサーバ装置と、前記開発環境へのユーザインターフェースを備えたクライアント端末とを有するソフトウェア開発システムであって、前記サーバ装置は、当該サーバ装置に前記開発環境を構築する開発環境生成手段と、前記ソースコードに対するアクセス権情報を設定するアクセス権情報設定手段と、前記設定されたアクセス権情報を基に、前記ソースコードの表示方法を判断するアクセス権限判断手段とを備え、前記判断されたソースコードの表示方法に従って、前記クライアント端末における前記ソースコードの表示を制御することを特徴とする。

本発明のソフトウェア開発システムのアクセス制限方法は、開発対象のソースコードを含む開発環境を備えたサーバ装置と、前記開発環境へのユーザインターフェースを備えたクライアント端末とを有するソフトウェア開発システムのアクセス制限方法であって、前記サーバ装置は当該サーバ装置に前記開発環境を構築しておく開発環境生成ステップと、前記サーバ装置は前記ソースコードに対するアクセス権情報を設定しておくアクセス権情報設定ステップと、前記サーバ装置は前記設定されたアクセス権情報を基に、前記ソースコードの表示方法を判断するアクセス権限判断ステップと、前記サーバ装置は前記判断されたソースコードの表示方法に従って、前記クライアント端末における前記ソースコードの表示を制御する表示制御ステップとを有することを特徴とする。

本発明のサーバ装置は、開発対象のソースコードを含む開発環境を備え、前記開発環境へのユーザインターフェースを備えたクライアント端末と共にソフトウェア開発システムを構築するサーバ装置であって、当該サーバ装置に前記開発環境を構築する開発環境生成手段と、前記ソースコードに対するアクセス権情報を設定するアクセス権情報設定手段と、前記設定されたアクセス権情報を基に、前記ソースコードの表示方法を判断するアクセス権限判断手段とを備え、前記判断されたソースコードの表示方法に従って、前記クライアント端末における前記ソースコードの表示を制御することを特徴とする。

本発明のプログラムは、開発対象のソースコードを含む開発環境を備えたサーバ装置と、前記開発環境へのユーザインターフェースを備えたクライアント端末とを有するソフトウェア開発システムを制御するアクセス制限方法をコンピュータに実行させるプログラムにおいて、前記アクセス制限方法は、前記サーバ装置は当該サーバ装置に前記開発環境を構築しておく開発環境生成ステップと、前記サーバ装置は前記ソースコードに対するアクセス権情報を設定しておくアクセス権情報設定ステップと、前記サーバ装置は前記設定されたアクセス権情報を基に、前記ソースコードの表示方法を判断するアクセス権限判断ステップと、前記サーバ装置は前記判断されたソースコードの表示方法に従って、前記クライアント端末における前記ソースコードの表示を制御する表示制御ステップとを有することを特徴とする。

本発明の請求項１−５に係るソフトウェア開発システムによれば、機密情報へのアクセス制限を実現した上で、プログラムの開発作業を効率的に行える開発環境を備えることができる。また、機密保護対象のプログラムモジュールのソースコードに対し、その利用が許可された開発者には、機密保護対象のインターフェースへのアクセスは制限されない開発環境を備えたソフトウェア開発システムを提供することができる。この場合、それ以外の開発者では、機密保護対象のインターフェースへのアクセスも制限される。

このように、コンパイル済みのオブジェクトやデータの配布を必要とせずに、機密保護対象へのアクセス制限を行う開発環境の提供が可能になる。

さらに、開発作業を行う場所は限定されないため、顧客データなどの外部への持ち出し不可能なデータを用いた障害解析作業を、遠隔の環境から行うことができる。また、複数の開発拠点をまたがった分散開発作業が、機密保護を実現した上で可能となる。

さらに、担当者ごとに適切なアクセス制限が行われることになるため、１つの実行環境上で、プログラムの不具合の解析作業などを行う場合などの連携作業が、機密保護を実現した上で可能となる。また、ソースコードへの機密保護を実現しつつ、ソースコードのコンパイル、プログラムの実行が可能になり、オブジェクトやデータの配布を必要としない。

請求項６に係るソフトウェア開発システムによれば、クラス継承を含むプログラミング言語であっても、適切なアクセス制御を実現することができる。

請求項７に係るソフトウェア開発システムによれば、言語仕様上のアクセス制御機能において利用不可能なインターフェースを考慮した表示を行うことができる。請求項８に係るソフトウェア開発システムによれば、アクセス権を言語仕様のスコープと関連づけて容易に設定することができる。

請求項９に係るソフトウェア開発システムによれば、Ｃ言語などシンボルの名前空間が言語仕様上不明確な場合や、言語仕様上のアクセス制限機能がない場合においても、シンボルが定義されているスコープの特定を容易にできる。また、スコープ単位でのアクセス権の設定が可能になる。請求項１０に係るソフトウェア開発システムによれば、開発担当者単位でのアクセス制限を行うことが可能になる。請求項１１に係るソフトウェア開発システムによれば、機密情報への外部からのアクセスを防ぐことができる。

本発明のソフトウェア開発システム、そのアクセス制限方法、サーバ装置、プログラムおよび記憶媒体の実施の形態について図面を参照しながら説明する。

［第１の実施形態］
第１の実施形態では、プログラミング言語としてＪａｖａ（登録商標）を用いた、Ｗｅｂアプリケーションを開発する環境を例に、ソフトウェア開発システムを説明する。図１はＷｅｂアプリケーションの開発環境を備えたソフトウェア開発システムの構成を示す図である。ソフトウェア開発システムは、ネットワーク５０を介してサーバ２００およびクライアント端末１００が接続された構成を有する。

クライアント端末（コンピュータ）１００では、開発環境ＧＵＩ１０１が動作する。この開発環境ＧＵＩ１０１は、開発環境に対するユーザインターフェースを提供し、開発環境画面２１００（図４参照）を表示する。

クライアント端末１００とネットワーク５０で接続されたサーバ（コンピュータ）２００上には、リモート開発環境３００が搭載されている。リモート開発環境３００には、プログラムの動作環境である実行環境３１０、開発ツール３２０および開発対象のプログラムのソースコード３３０が含まれる。図１では、一般的なＷｅｂアプリケーションの開発と実行に必要な構成が示されている。

実行環境３１０は、Ｗｅｂアプリケーションを動作させるアプリケーションサーバ３１２、プログラムの実行ファイルであるクラスファイル３１１、およびデータベース３１３からなる。開発ツール３２０は、ソースコード３３０からクラスファイル３１１を生成するためのコンパイラ３２３、ソースコード３３０を編集するためのエディタ３２２、およびデバッグを行うためのデバッガ３２１からなる。

開発環境ＧＵＩ１０１は、サーバ２００上のクライアント通信部２０１とネットワーク５０を介して接続されている。開発環境ＧＵＩ１０１は、リモート開発環境３００を構築するための開発環境生成部２０２、およびリモート開発環境３００上で開発作業を行うための開発環境制御部２０４にアクセスする。これにより、ネットワーク５０を介してプログラムの開発作業を行うことができる開発環境が提供される。

この開発環境の実現方法として、この開発環境それ自体も、Ｗｅｂアプリケーションとして提供することができる。その場合、クライアント通信部２０１をＷｅｂアプリケーションサーバとする。開発環境生成部２０２および開発環境制御部２０４をそのＷｅｂアプリケーションサーバ上で動作するＷｅｂアプリケーションとする。開発環境ＧＵＩ１０１をＷｅｂブラウザとする。これにより、これらの機能を実現することが可能である。以降の説明では、この開発環境自体もＷｅｂアプリケーションとして構築されていることとして説明する。

本実施形態の開発環境では、上記機能の他にさらに、機密保護を実現するための機能が加わっている。まず、ログイン制御部２０３は、アクセスしたユーザを認証するための機能である。これは、通常のＷｅｂアプリケーションに含まれるユーザ認証機能と同等である。アクセス権判定部２０５は、ソースコード３３０に対するアクセス権の判定処理を行う。このアクセス権判定部２０５はアクセス権限判断手段に相当する。アクセス権情報２０６は、ソースコード３３０に対するアクセス権の設定を保持するデータを示す。また、アクセス権設定部２０７は、アクセス権情報２０６にユーザ単位のアクセス権の情報を設定するための機能を提供する。このアクセス権設定部２０７はアクセス権情報設定手段に相当する。

図２はリモート開発環境３００をサーバ２００上に構築する際のシーケンスを示す図である。まず、ユーザはプロジェクト一覧画面の表示を開発環境ＧＵＩ１０１に対して要求する（ステップＳ２０１）。開発環境ＧＵＩ１０１はクライアント通信部２０１に対してプロジェクト一覧画面の要求を送出する（ステップＳ２０２）。一般的に、ステップＳ２０２で送出される要求は、ＨＴＴＰのリクエストであり、プロジェクト一覧画面を示すＵＲＬとなる。次に、クライアント通信部２０１は開発環境生成部２０２に対してプロジェクト一覧画面の生成を要求する（ステップＳ２０３）。開発環境生成部２０２はプロジェクト一覧画面を生成する。そして、クライアント通信部２０１はこの生成された画面を開発環境ＧＵＩ１０１に対して送信する（ステップＳ２０４）。

図３は開発環境ＧＵＩ１０１で表示されるプロジェクト一覧画面２０００を示す図である。開発環境生成部２０２は、プロジェクト一覧画面２０００をＨＴＭＬで表現された画面として生成することになる。パネル２００１には、あらかじめ準備された開発プロジェクトの一覧が表示されている。

ユーザは、開発プロジェクトの一覧から開発環境の構築を行うプロジェクトを選択することができる。ボタン２００２は、選択されたプロジェクトの開発環境の構築を開始するボタンである。

ユーザは、パネル２００１内のプロジェクトを選択し、ボタン２００２を押下すると（図２のステップＳ２０５）、開発環境ＧＵＩ１０１は、クライアント通信部２０１に対して開発環境構築要求を送出する（ステップＳ２０６）。このステップＳ２０６で送出される要求もＨＴＴＰのリクエストである。このＨＴＴＰのリクエストには、選択されたプロジェクトの識別子が含まれることになる。この要求を受けたクライアント通信部２０１は、開発環境生成部２０２に対し、指定されたプロジェクトの開発環境の構築を要求する（ステップＳ２０７）。開発環境生成部２０２は、リモート開発環境３００をサーバ２００上に構築する。

リモート開発環境３００の構築は、例えば、構成管理システムなどで管理されている開発環境の構成物を取り出すことにより行われることになる。リモート開発環境３００の構築が完了すると、クライアント通信部２０１は、生成されたリモート開発環境３００へのユーザインターフェースの画面（開発環境画面２１００）へのリダイレクト要求を開発環境ＧＵＩ１０１に対して送信する。

ここで構築されるリモート開発環境３００は、ユーザごとに個別に開発作業を行う場合、ユーザごとに確保された領域に構築される。また、デバッグなどの解析作業を複数のユーザで行う場合、１つの環境を共有して利用することが行われる。ここでは、リモート開発環境３００は、プロジェクトを選択して構築される例を示したが、障害管理システムと連動し、障害情報に障害を発生させたデータやソースコードのバージョンを記録しておき、それを基に、リモート開発環境３００を構築する方法もある。

図４は開発環境ＧＵＩ１０１で表示される開発環境画面２１００を示す図である。この画面２１００は、プログラムの作成ツール、開発対象アプリケーションの実行制御ツールなどを提供しており、統合開発環境（ＩＤＥ）としての機能を有する。

パネル２１０１はアプリケーションサーバ３１２の制御機能を有する。パネル２１０２はデバッガ３２１の制御機能を有する。パネル２１０３はアプリケーションサーバ３１２の実行状態を示すスタックトレースの表示を行う。パネル２１０４は変数等のデバッガ３２１が出力する情報の表示を行う。パネル２１０５はソースコード３３０の編集機能を有する。パネル２１０６はソースコード３３０が格納されているディレクトリをブラウズ（閲覧）するための機能を有する。ボタン２１０７はソースコードの編集結果を保存する機能を有する。パネル２１０８はアプリケーションサーバ３１２のコンソール出力の表示を行う機能を有する。

図５は開発環境画面２１００の操作例として、ソースコード３３０をエディタパネル２１０５に表示する際のシーケンスを示す図である。ユーザがパネル２１０６で編集対象のソースファイルを選択すると（ステップＳ３０１）、開発環境ＧＵＩ１０１はクライアント通信部２０１に対して選択ファイルの読み込み要求を送出する（ステップＳ３０２）。クライアント通信部２０１は、開発環境制御部２０４に対して選択ファイルの読み込みを指示し（ステップＳ３０３）、開発環境制御部２０４は、エディタ３２２に選択ファイルを読み込む（ステップＳ３０４）。そして、開発環境制御部２０４は、選択ファイルの編集画面を生成してクライアント通信部２０１に送出し(ステップＳ３０５)、クライアント通信部２０１は開発環境ＧＵＩ１０１に画面を送信する（ステップＳ３０６）。この結果、選択したファイルの編集画面として、エディタパネル２１０５にソースコード３３０が表示される。

図６は開発環境画面２１００の操作例として、ソースコード３３０のコンパイルを行う際のシーケンスを示す図である。ここでは、エディタパネル２１０５に表示されているソースの編集後、保存ボタン２１０７を押したタイミングでコンパイルが実行される。

ユーザが保存ボタン２１０７を押下すると（ステップＳ４０１）、開発環境ＧＵＩ１０１はクライアント通信部２０１に対して変更保存要求を送出する（ステップＳ４０２）。クライアント通信部２０１は開発環境制御部２０４に対して変更の保存を指示し（ステップＳ４０３）、開発環境制御部２０４はエディタ３２２に変更保存を指示する（ステップＳ４０４）。さらに、開発環境制御部２０４はコンパイラ３２３に対して、保存したファイルのコンパイルを指示する（ステップＳ４０５）。そして、開発環境制御部２０４はコンパイル結果画面を作成し、クライアント通信部２０１に送信する（ステップＳ４０６）。

コンパイル結果画面は、例えば、コンパイルエラーがある場合、エディタパネル２１０５に表示されているソースコードのエラー箇所にマーキングが表示されている画面として生成される。クライアント通信部２０１は生成されたコンパイル結果画面を開発環境ＧＵＩ１０１に送信する（ステップＳ４０７）。これにより、エディタパネル２１０５には、コンパイル結果が表示される。

図７は開発環境画面２１００の操作例として、デバッガ操作を行う際のシーケンスを示す図である。まず、開発対象のプログラムの起動操作について説明する。ユーザはパネル２１０１で起動ボタンを押下すると（ステップＳ５０１）、開発環境ＧＵＩ１０１はクライアント通信部２０１に対してアプリケーションの起動要求を送出する（ステップＳ５０２）。そして、クライアント通信部２０１はアプリケーションサーバ３１２を起動する（ステップＳ５０３）。これにより、開発対象のプログラムが起動する。

次に、デバッガ操作の例として、メソッドの呼び出し前の状態から、デバッガのステップイン操作により、呼び出し後のメソッドに制御を移動させる場合を示す。

特定メソッドの呼び出し前の状態で、プログラムが実行を停止している場合、ユーザはデバッガパネル２１０２のステップインボタンを押す（ステップＳ５０４）。これにより、開発環境ＧＵＩ１０１はクライアント通信部２０１に対してステップイン要求を送出する（ステップＳ５０５）。クライアント通信部２０１は開発環境制御部２０４にステップインを指示する（ステップＳ５０６）。開発環境制御部２０４はデバッガ３２１に対してステップイン操作を実行する（ステップＳ５０７）。これを受けて、デバッガ３２１はアプリケーションサーバ３１２に対してステップインの実行制御を行う（ステップＳ５０８）。

次に、開発環境制御部２０４は、デバッガ３２１に対して現在停止中の箇所の情報（クラス、メソッド、行数）を取得する（ステップＳ５０９）。これは、呼び出されたメソッドの先頭行にあたる箇所となる。その情報を元に、開発環境制御部２０４はステップイン操作後の画面を作成（生成）する（ステップＳ５１０）。ここで、生成される画面は呼び出されたメソッドが表示されている編集画面となる。クライアント通信部２０１は生成された画面を開発環境ＧＵＩ１０１に送信する（ステップＳ５１１）。これにより、エディタパネル２１０５には、ステップイン後のソースコード３３０が表示される。

次に、ソースコード３３０に機密保護対象のソースコードが含まれ、それに対してアクセス制限を行う場合のアクセス権の設定方法について説明する。まず、アクセス制限対象のソースコードに対する、ユーザのアクセス権限の種類を説明する。ユーザのアクセス権限として、以下の３種類がある。

第１のアクセス権限として、「参照／編集可能権限」がある。この権限は機密保護対象のソースコードに対して編集・参照が許可される。対象のソースコードを開発している開発担当者や管理者にとっては、この権限が必要になる。

第２のアクセス権限として、「利用可能権限」がある。機密保護対象のソースコードの実装へのアクセスは許可されないが、インターフェースへのアクセスは許可される。機密保護対象のソースコードが提供している機能を、利用するプログラムを開発している担当者の場合、この権限が必要になる。

第３のアクセス権限として、「不許可」がある。機密保護対象のソースコードへの全てのアクセスが許可されない。また、機密保護対象のソースコードのインターフェースそのものを隠蔽するために、その機密保護対象のインターフェースを利用しているソースコードの実装部分へのアクセスも加えて許可されない。機密保護対象のソースコードの機能に関係しない担当者の権限はこれになる。

アクセス権限の設定は、機密保護対象を指定し、それについて、参照・編集可能なユーザ、あるいは利用可能なユーザを登録することで行われる。なお、「不許可」については、ここで設定されないユーザは全て不許可のユーザとなる。また、機密保護の範囲の指定方法には、ソースコードのクラスファイルを指定する方法と、クラスが含まれるパッケージ階層を指定する方法がある。

図８はアクセス権限を設定する操作が行われるときの動作シーケンスを示す図である。ユーザがアクセス権限の設定を開始すると（ステップＳ６０１）、開発環境ＧＵＩ１０１は、クライアント通信部２０１に対してアクセス権の設定対象を選択する画面を要求する（ステップＳ６０２）。そして、クライアント通信部２０１は、アクセス権設定部２０７に対してアクセス権設定対象選択画面の生成を指示する（ステップＳ６０３）。アクセス権設定部２０７によって生成された画面は、クライアント通信部２０１から開発環境ＧＵＩ１０１に送信される（ステップＳ６０４）。

図９は開発環境ＧＵＩ１０１で表示されるアクセス権設定対象選択画面２２００を示す図である。パネル２２０１は、アクセス権の設定対象のクラスがパッケージ階層のツリー構造で表示されることを示している。ユーザは、パネル２２０１からアクセス権を設定する対象を選択し、ボタン２２０４を押すことで、アクセス権の設定対象を指示する。

ここで、パッケージ２２０２を指定すると、アクセス権の設定範囲としてパッケージ階層を指定することになり、クラスファイル２２０３を直接指定すると、指定クラスをアクセス権の設定範囲に指定することになる。つまり、言語仕様で提供されている名前空間のスコープの単位でアクセス権の設定範囲を指定することになる。パッケージレベルでアクセス権を指定することで、そのパッケージ内に新規にクラスが生成された場合でも、新たにアクセス権を追加で設定することなくパッケージで定義されたアクセス権が有効になる。

図８に示すように、ユーザがアクセス権の設定対象を選択し、アクセス権設定ボタン２２０４を押下すると（ステップＳ６０５）、開発環境ＧＵＩ１０１はクライアント通信部２０１に対してアクセス権設定画面を要求する（ステップＳ６０６）。そして、クライアント通信部２０１はアクセス権設定部２０７に対してアクセス権設定画面の生成を指示する（ステップＳ６０７）。アクセス権設定部２０７によって生成された画面は、クライアント通信部２０１から開発環境ＧＵＩ１０１に送信される（ステップＳ６０８）。

図１０は開発環境ＧＵＩ１０１で表示されるアクセス権設定画面２３００を示す図である。フィールド２３０１には、選択されたアクセス権の設定対象であるパッケージあるいはクラスが表示される。フィールド２３０２は、参照／編集可能権限を与えるユーザを入力するフィールドである。ここに設定されたユーザに対し、参照／編集可能権限が与えられる。フィールド２３０３は利用可能権限を与えるユーザを入力するフィールドである。ここに設定されたユーザに対し、利用可能権限が与えられる。ボタン２３０４は、入力内容どおりに、権限の設定を実行するボタンである。

図８に示すように、ユーザがボタン２３０４を押下すると（ステップＳ６０９）、開発環境ＧＵＩ１０１はクライアント通信部２０１に対してアクセス権設定を要求する（ステップＳ６１０）。そして、クライアント通信部２０１は、アクセス権設定部２０７に対してアクセス権設定を指示し（ステップＳ６１１）、アクセス権設定部２０７はアクセス権情報２０６にアクセス権の設定を記録する。

図１１はアクセス権情報２０６で記録されている情報を示すテーブルである。「対象スコープ」のフィールド２５０１には、指定されたアクセス権設定対象のパッケージやクラスが設定される。「利用可」のフィールド２５０２には、利用可能権限が与えられたユーザが設定される。「編集可」のフィールド２５０３には、参照／編集可能権限が与えられたユーザが設定される。ここで、アクセス権限が設定されていないパッケージやクラスについては、アクセス権の制限は行われず、全ユーザがアクセス可能である。

ここで、前述したアクセス権の設定が行われた状態において、開発環境画面２１００でのソースコードがアクセス権限の違いによってどのように変わってくるかについて説明する。図１２はここで説明するクラスの関係をＵＭＬ（Unified Modeling Language）のクラス図の表記を用いて示す図である。

図中、白抜きの三角の接続線はクラスの継承関係を示す。破線の矢印の接続線は、矢印の方向への依存関係を示し、特に、ここではメソッドを呼び出すなど、矢印方向のクラスを利用していることを示している。

ここで、保護対象クラスＣｌａｓｓ Ａ（２６０１）において、Ｕｓｅｒ１に対して参照／編集可能権限を与え、Ｕｓｅｒ２に対して利用可能権限を与え、Ｕｓｅｒ３には権限を与えない（つまり不許可）場合について検討する。この場合、クラス継承機能を持つプログラミング言語で記述された、各クラスのソースコード３３０が開発環境画面２１００でどのように表示されるかを示す。

図１２のクラス図から、Ｃｌａｓｓ Ａ（２６０１）が機密保持対象のクラスであり、Ｃｌａｓｓ Ｂ１（２６０２）、Ｃｌａｓｓ Ｂ２（２６０３）がＣｌａｓｓ Ａ（２６０１）が提供している機能を利用するクラスである。Ｃｌａｓｓ Ｃ１（２６０４） 〜 Ｃｌａｓｓ Ｃ４（２６０７）は、Ｃｌａｓｓ Ｂ１（２６０２）、Ｃｌａｓｓ Ｂ２（２６０３）が提供している機能を利用するクラスである。そして、Ｕｓｅｒ１がＣｌａｓｓ Ａ（２６０１）の開発担当である。Ｕｓｅｒ２がＣｌａｓｓ Ｂ１（２６０２）、Ｃｌａｓｓ Ｂ２（２６０３）の開発担当である。Ｕｓｅｒ３がＣｌａｓｓ Ｃ１（２６０４） 〜 Ｃｌａｓｓ Ｃ４（２６０７）の開発担当ということになる。

図１３はＵｓｅｒ１の各クラスのソースコードを開いたときのエディタパネル２１０５での表示内容を示す図である。表示２７０１はＣｌａｓｓＤ１（２６０８）の表示を示す。表示２７０２はＣｌａｓｓ Ａ（２６０１）の表示を示す。表示２７０３はＣｌａｓｓ Ｂ２（２６０３）の表示を示す。表示２７０４はＣｌａｓｓ Ｄ２（２６０９）の表示を示す。表示２７０５はＣｌａｓｓ Ｂ１（２６０２）の表示を示す。なお、Ｃｌａｓｓ Ｃ１（２６０４） 〜 Ｃｌａｓｓ Ｃ４（２６０７）については、全てのユーザでアクセス制限がかからないので、ここでは図示していない。

また、図１４はＵｓｅｒ２の各クラスのソースコードを開いたときのエディタパネル２１０５での表示内容を示す図である。図１５はＵｓｅｒ３の各クラスのソースコードを開いたときのエディタパネル２１０５での表示内容を示す図である。図１４、図１５の各表示と図１２の各クラスとの対応は前述した図１３の場合と同様である。

アクセス制限の対象であるクラスＣｌａｓｓ Ａ（２６０１）の継承元のＣｌａｓｓ Ｄ１（２６０８）の表示においては、アクセス制限が行われず、各ユーザの表示２７０１、２８０１、２９０１は変わらない。

制限クラスＣｌａｓｓ Ａ（２６０１）の表示においては、ユーザごとに表示が変化する。Ｕｓｅｒ１の表示では、アクセス制限が行われず、全てが表示される（表示２７０２）。Ｕｓｅｒ２での表示は、インターフェースのみの表示となる（表示２８０２）。ｐｒｉｖａｔｅメンバの表示が制限され、ｐｕｂｌｉｃおよびｐｒｏｔｅｃｔｅｄのメンバについては、実装部分の表示が制限され、表示は宣言のみの形に変更されている（２行目〜９行目）。

Ｃｌａｓｓ Ａ（２６０１）でオーバライドしているＣｌａｓｓ Ｄ１（２６０８）のメソッド（表示２７０２の１５行目）では、オーバライド定義されていることを示すために、実装の表示は制限され、宣言のみの形に変更される（表示２８０２の１２行目）。Ｕｓｅｒ３の表示では、Ｃｌａｓｓ Ａ（２６０１）に対するアクセスは全て制限されてしまう（表示２９０２）。

制限クラスＣｌａｓｓ Ａ（２６０１）を継承したＣｌａｓｓ Ｂ２（２６０３）の表示では、Ｕｓｅｒ１，Ｕｓｅｒ２ともアクセス制限が行われない（表示２７０３，２８０３）。Ｕｓｅｒ３の表示では、Ｃｌａｓｓ Ｂ２（２６０３）がＣｌａｓｓ Ａ（２６０１）を利用しているので、アクセスが制限され、インターフェースのみの表示となる。前述の説明と同様、ｐｒｉｖａｔｅメンバの表示が制限され、ｐｕｂｌｉｃおよびｐｒｏｔｅｃｔｅｄのメンバについては、実装部分の表示が制限され、表示は宣言のみの形に変更されている（表示２９０３）。さらに、継承関係がＣｌａｓｓ Ａ（２６０１）の継承元であるＣｌａｓｓ Ｄ１（２６０８）に変更されて表示される（表示２９０３の１行目）。また、Ｃｌａｓｓ Ｂ２（２６０３）がオーバライドしているＣｌａｓｓ Ａ（２６０１）のメソッド（表示２８０３の１５行目）は隠蔽される。

制限クラスＣｌａｓｓ Ａ（２６０１）を利用しているＣｌａｓｓ Ｂ１（２６０２）の継承元であるＣｌａｓｓ Ｄ２（２６０８）の表示は、アクセス制限が行われないので、各ユーザの表示２７０４、２８０４、２９０４は変わらない。

制限クラスＣｌａｓｓ Ａ（２６０１）を利用しているＣｌａｓｓ Ｂ１（２６０２）の表示では、Ｕｓｅｒ１，Ｕｓｅｒ２ともアクセス制限は行われない（表示２７０５，２８０５）。Ｕｓｅｒ３の表示では、Ｃｌａｓｓ Ｂ２（２６０３）がＣｌａｓｓ Ａ（２６０１）を利用しているため、アクセスが制限され、インターフェースのみの表示となる。前述の説明と同様、ｐｒｉｖａｔｅメンバの表示が制限され、ｐｕｂｌｉｃおよびｐｒｏｔｅｃｔｅｄのメンバについては、実装部分の表示が制限され、表示は宣言のみの形に変更されている（表示２９０５）。また、インスタンス変数（表示２８０５の６〜８行目）は、Ｃｌａｓｓ Ａ（２６０１）のインスタンスであるため、ｐｕｂｌｉｃ／ｐｒｏｔｅｃｔｅｄを含め、全て表示されなくなっている。Ｃｌａｓｓ Ｂ１（２６０２）でオーバライドしているＣｌａｓｓ Ｄ２（２６０９）のメソッド（表示２８０５の１５行目）も、同じく、表示は宣言のみの形に変更されている（表示２９０５の８行目）。さらに、Ｃｌａｓｓ Ｂ１（２６０２）のメソッドｐｒｏＢ１（）（表示２７０５の１１行目）は、リターン値がＣｌａｓｓ Ａ（２６０１）であるため、表示されなくなっている。

上記の例で示すように、制限対象のインターフェースとは、クラス名、メソッド、定数、変数を意味する。実装へのアクセスが制限される場合、制限対象のインターフェースは、言語仕様上のアクセス権限で許可されるもの（ｐｕｂｌｉｃ／ｐｒｏｔｅｃｔｅｄ）について、実装が除外されたインターフェースの宣言のみの形で表示される。さらに、その表示の際、インターフェース宣言の要素に、権限のないクラスを含む場合、そのインターフェースの表示も制限される。これは、インターフェース宣言の要素（例えば、メソッドの引数や、リターン値のクラス）に対する利用権限がなければ、そのインターフェースそのものを利用することができないからである。

また、継承元に前述のクラスがある場合、そのクラスをスキップした継承関係に変更された形で表示が行われる。これは、アクセス権のないクラスが継承階層にあったとしても、アクセス可能なクラスへの継承関係はインターフェースを利用する側で認識される必要があるためである。

また、実装およびインターフェースのいずれも制限される場合、完全に表示されなくなる。例えば、図１５の表示２９０２では、表示できない旨のメッセージのみが表示されているが、別のプログラミング言語では、アセンブラ表示に切り替える等の表示方法も可能である。

つぎに、開発環境画面２１００でソースコードを表示する際のアクセス制限方法について説明する。

ユーザが開発環境ＧＵＩ１０１を利用する際、ユーザを特定するためのユーザ認証機能が最初に動作する。図１６はユーザ認証のシーケンスを示す図である。この動作は一般的なＷｅｂアプリケーションにおけるユーザ認証動作と同じである。

ユーザがユーザＩＤとパスワードを入力してログイン操作を行うと（ステップＳ７０１）、開発環境ＧＵＩ１０１はクライアント通信部２０１に対してログイン要求を行う（ステップＳ７０２）。そして、クライアント通信部２０１はログイン制御部２０３にログイン処理を依頼する。ログイン制御部２０３は認証を行い、認証がＯＫの場合、認証情報を記録する（ステップＳ７０３）。ここで、認証情報とは、ログインを行っているユーザを示す情報である。認証情報は、一般的にＨＴＴＰセッションやＨＴＴＰのクッキー情報などに記録される。

図１７はパネル２１０６でソースコード３３０が格納されているディレクトリを表示する際のアクセス制限の処理を示す図である。ユーザがパネル２１０６でディレクトリツリーを開く操作を行うなどのブラウズ操作を行うと（ステップＳ８０１）、開発環境ＧＵＩ１０１はクライアント通信部２０１に対してディレクトリツリー表示要求を行う（ステップＳ８０２）。そして、クライアント通信部２０１は開発環境制御部２０４にディレクトリツリー表示を指示する（ステップＳ８０３）。

開発環境制御部２０４は、ログイン制御部２０３に対して操作ユーザの取得を行う（ステップＳ８０４）。ログイン制御部２０３は、認証情報から操作ユーザを特定する。開発環境制御部２０４は、表示するディレクトリ内の各要素、つまり各クラスのソースファイル、およびパッケージに対応するディレクトリに対し、アクセス権判定部２０５へアクセス権の判断を依頼する（ステップＳ８０５）。

アクセス権判定部２０５は、対象のクラス名、ディレクトリ名に対してアクセス権の判断、つまりクラス名やディレクトリ名を表示してよいか否かの判断を行う。全ての要素のアクセス権判定が終了した後、開発環境制御部２０４は、アクセス権のある要素のみを表示するようにディレクトリツリー画面を生成する（ステップＳ８０６）。クライアント通信部２０１は、生成された画面を開発環境ＧＵＩ１０１に送信する（ステップＳ８０７）。

ここでは、ソースコードはファイルの形式で格納されている例で説明したが、クラスのソースコードとしては、ファイルではなく、例えばデータベースに格納される形態も存在する。その場合も、同様に、パッケージおよびクラスの単位で上記の処理が行われる。

図１８はステップＳ８０５におけるアクセス権判定部２０５によるアクセス権の判定処理手順を示すフローチャートである。まず、アクセス権判定部２０５は、アクセス権情報２０６を参照し、対象クラスがアクセス制限の対象のクラス（制限クラス）であるか否かを判定する（ステップＳ９０１）。制限クラスでない場合（ステップＳ９０１のＮＯ）、アクセス権判定部２０５は、クラス名を表示可能と判断し（ステップＳ９０６）、本処理を終える。

一方、制限クラスの場合（ステップＳ９０１のＹＥＳ）、アクセス権判定部２０５は、アクセス権情報２０６から、操作ユーザが対象クラスの参照／編集可能権限を持っているか否かを判断する（ステップＳ９０２）。操作ユーザが対象クラスに対する参照／編集可能権限があると判断された場合（ステップＳ９０２のＹＥＳ）、アクセス権判定部２０５はクラス名を表示可能と判断する（ステップＳ９０６）。

一方、参照／編集可能権限がない場合（ステップＳ９０２のＮＯ）、同様に、アクセス権判定部２０５は、アクセス権情報２０６から、利用可能権限があるか否かを判断する（ステップＳ９０３）。利用可能権限がない場合（ステップＳ９０３のＮＯ）、アクセス権判定部２０５は、クラス名を表示不可と判断する（ステップＳ９０７）。一方、利用可能権限がある場合（ステップＳ９０３のＹＥＳ）、さらに、アクセス権判定部２０５は、対象クラスが言語仕様上のアクセス権限（パッケージ外からそのクラスの利用可能か）があるか否かを判断する（ステップＳ９０４）。つまり、アクセス権判定部２０５は、ｐｕｂｌｉｃ／ｐｒｏｔｅｃｔｅｄであるクラスか否かを判断する。

言語仕様上のアクセス権限がある場合（ステップＳ９０４のＹＥＳ）、アクセス権判定部２０５は、クラス名を表示可能と判断する（ステップＳ９０６）。言語仕様上のアクセス権限がない場合（ステップＳ９０４のＮＯ）、アクセス権判定部２０５は、クラス名を表示不可と判断し（ステップＳ９０５）、本処理を終える。

ここで、ステップＳ９０２、９０３における、アクセス権情報２０６を参照してアクセス権判定を行う処理について、図１１のテーブルを例にさらに説明する。テーブルの１行目の情報から、対象クラスがｍｏｄｕｌｅＡ内のクラスであった場合、カラム２５０２の情報から、Ｕｓｅｒ２に利用可能権限、カラム２５０３の情報から、Ｕｓｅｒ１に参照／編集可能権限が設定されている。つまり、Ｕｓｅｒ２は利用権限，Ｕｓｅｒ１は参照／編集可能権限をもっていると判断される。

テーブルの２行目では、ｍｏｄｕｌｅＡ内のＣｌａｓｓＡ２に対してさらにアクセス権限の情報が設定されている。ＣｌａｓｓＡ２では、利用可能権限が設定されておらず、参照／編集可能権限にＵｓｅｒ１が設定されている。このとき、対象クラスがＣｌａｓｓＡ２の場合、アクセス権限を持つユーザはＵｓｅｒ１のみと判断され、Ｕｓｅｒ２は利用権限がないと判断される。つまり、スコープが重なる設定がアクセス権情報２０６に行われている場合、スコープ範囲の狭い方の設定が優先的に判定に用いられる。

また、ステップＳ９０１における、対象クラスがアクセス制限の対象のクラスであるか否かを判定する処理について、図１９および図１１を用いて説明する。図１９はステップＳ９０１の判定処理手順を示すフローチャートである。アクセス権判定部２０５は、まず、対象クラスのパッケージ階層を含めたフルクラス名を取得する（ステップＳ１００１）。この取得は、クラスファイル内で宣言されているパッケージの宣言のｐａｃｋａｇｅ文から可能である。

アクセス権判定部２０５は、フルクラス名に対し、カラム２５０１の対象スコープの文字列が前方一致で含まれているか否かを判別する（ステップＳ１００２）。このフルクラス名に対し、カラム２５０１の対象スコープの文字列が前方一致で含まれている場合（ステップＳ１００２のＹＥＳ）、アクセス権限の設定が行われており、アクセス権判定部２０５は、対象クラスが制限クラスであると判断する（ステップＳ１００３）。そして、前述したステップＳ９０２の処理に移行する。一方、含まれない場合（ステップＳ１００２のＮＯ）、アクセス権判定部２０５は、対象クラスが制限クラスではないと判断し（ステップＳ１００４）、前述したステップＳ９０６の処理に移行する。

図２０はエディタパネル２１０５でソースコードの内容を表示する際のアクセス制限の処理を示す図である。ここでは、デバッグ操作を行っており、メソッドの呼び出し先のソースにステップイン操作を行ったとき、ステップイン後のソースを表示する場合を例に説明する。

この処理では、図７で説明した処理にアクセス制限の処理が加わることになる。ステップＳ５０４、Ｓ５０５の処理は前述した図７と同じ処理である。なお、図７と同一の処理については同一のステップ番号が付されている。

ステップＳ５０６でクライアント通信部２０１からステップインが指示されると、開発環境制御部２０４は、まずログイン制御部２０３に対し、操作ユーザの取得を行う（ステップＳ１１０１）。そして、開発環境制御部２０４は、ステップイン実行を行う（ステップＳ５０７）。

開発環境制御部２０４は、現在停止中の箇所の情報を取得する（ステップＳ５０９）。ここで、停止中のクラスが特定される。開発環境制御部２０４は、そのクラスに対するアクセス権の判定処理をアクセス権判定部２０５に依頼する。（ステップＳ１１０２）。

アクセス権判定部２０５は、アクセス権の判定を行った結果、ソースコード３３０の表示方法を開発環境制御部２０４に返却する（ステップＳ１１０３）。

開発環境制御部２０４は、ステップイン操作後の画面を作成する際、アクセス権の判断結果を基に、図１４、図１５で示すようなアクセス権に従った表示画面を作成する（ステップＳ１１０４）。この処理は、ソースコード３３０をパネル２１０５に表示させる場合、全て同じように行われる。例えば、図５のエディタ操作時のシーケンスにおいては、ステップＳ３０３において同様のアクセス制限が行われることになる。逆に、ソースコードや、クラス名の表示を伴わない処理では、アクセス制限なしに実行が行われる。例えば、アクセス権がないクラスを含むプロジェクト全体に対してコンパイルを実行することが可能である。ただし、コンパイル結果の表示の際、アクセス権がないクラスについてはアクセス制限が行われることになる。

図２１はステップＳ１１０２の依頼に応じて行われるソースコード３３０の表示方法を決定する処理手順を示すフローチャートである。この処理では、ステップＳ１１０２の対象クラスがアクセス制限の対象のクラスであるか否かを判定し、その判定結果を基にソースコード３３０の表示方法を決定する。

まず、アクセス権判定部２０５は、対象のクラスがアクセス制限の対象のクラスであるか否かを判定する（ステップＳ１２０１）。この判定はステップＳ９０１で行う処理と同等である。

制限クラスであった場合（ステップＳ１２０１のＹＥＳ）、アクセス権判定部２０５は、操作ユーザが対象クラスの参照／編集可能権限を持っているか否かを判断する（ステップＳ１２０２）。この判断はステップＳ９０２で行う処理と同等である。対象クラスに対する参照／編集可能権限があると判断された場合（ステップＳ１２０２のＹＥＳ）、アクセス権判定部２０５は、対象クラスのソースコードを表示可能と判断する（ステップＳ１２０３）。この後、本処理を終える。

一方、参照／編集可能権限がない場合（ステップＳ１２０２のＮＯ）、アクセス権判定部２０５は、利用可能権限があるか否かを判断する（ステップＳ１２０４）。同じく、この判断はステップＳ９０３で行う処理と同等である。利用可能権限がない場合（ステップＳ１２０４のＮＯ）、アクセス権判定部２０５は、対象クラスのソースコードを表示不可と判断する（ステップＳ１２０５）。この後、本処理を終える。一方、利用可能権限がある場合（ステップＳ１２０４のＹＥＳ）、アクセス権判定部２０５は、ソースコードをインターフェースのみに制限して表示可能と判断する（ステップＳ１２０６）。この後、本処理を終える。

一方、対象のクラスが制限クラスでない場合（ステップＳ１２０１のＮＯ）、アクセス権判定部２０５は、対象クラスが外部参照しているクラスを抽出する（ステップＳ１２０７）。この外部参照しているクラスは外部インターフェースに相当する。また、ここで、「外部参照している」とは、具体的に、対象クラスが別クラスのメソッド呼び出しを行っている場合や、クラス内で定義されている変数、定数が別クラスのインスタンスであること、メソッドの引数や返り値が別クラスであることをいう。Ｊａｖａ（登録商標）言語の場合、クラスのｉｍｐｏｒｔ宣言を行っていることと同じ意味である。

これらは、ソースコード中にクラス名が記述されることになるため、そのクラス名を抽出する処理を行うことになる。アクセス権判定部２０５は、抽出された各クラスに対し、アクセス制限の対象のクラスであるか否か、また、アクセス制限対象のクラスの場合、操作ユーザが利用可能権限あるいは参照／編集可能権限を持っているか否かを判断する（ステップＳ１２０８）。この処理はステップＳ１２０１，Ｓ１２０２、Ｓ１２０４と同等の処理である。制限クラスではない場合、あるいは、制限クラスであるが、ユーザが利用可能権限、参照／編集可能権限を持っている場合、ステップＳ１２０９の処理に進む。アクセス権判定部２０５は、残りの抽出された全てのクラスについて、同じ検証を行うまで、ステップＳ１２０８の処理に戻る（ステップＳ１２０９）。

全てのクラスの検証が終了した場合（ステップＳ１２０９のＹＥＳ）、アクセス権判定部２０５は、対象クラスのソースコードを表示可能と判断する（ステップＳ１２１０）。この後、本処理を終える。

一方、ステップＳ１２０８において、制限クラスであり、操作ユーザが利用可能権限、参照／編集可能権限を持っていないと判断された場合、アクセス権判定部２０５は、ソースコードをインターフェースのみに制限して表示可能と判断する（ステップＳ１２１１）。この後、本処理を終える。こうして、ソースコードの表示制御が行われる。

さらに、ステップＳ１２０６、Ｓ１２１１でインターフェースのみに制限と判断された場合、表示すべきインターフェースを抽出する処理を行う。その処理を、図２２を用いて説明する。図２２はアクセス権判定部２０５によるソース表示方法の判断処理手順を示すフローチャートである。

アクセス権判定部２０５は、まず、対象クラスの全インターフェースから、言語仕様上のアクセス権が無いものを削除する（ステップＳ４１０１）。つまり、外部のクラスから利用できないｐｒｉｖａｔｅの要素を削除対象とする。なお、Ｊａｖａ（登録商標）言語の場合、パッケージ内のみで利用可能なｐａｃｋａｇｅ ｐｒｉｖａｔｅのアクセス権もあるが、一般にパッケージで１つのまとまった機能を提供することから、このアクセス権の要素もｐｒｉｖａｔｅに準じた扱いとする。このように、言語仕様上のアクセス制御機能において利用不可能なインターフェースを除外する。

つぎに、アクセス権判定部２０５は、残りの各インターフェースの宣言で用いられている要素として、用いられているクラス、つまり、インスタンス変数の型、クラス変数の型、メソッドの引数、メソッドのリターン値を抽出する（ステップＳ４１０２）。アクセス権判定部２０５は、これらのクラスがアクセス制限の対象のクラスであるか否か、また、アクセス制限対象のクラスの場合、操作ユーザが利用可能権限あるいは参照／編集可能権限を持っているか否かを判断する（ステップＳ４１０３）。

アクセス権判定部２０５は、抽出したクラスの中に、制限クラスであり、操作ユーザが利用可能権限、参照／編集可能権限を持っていないものがある場合（ステップＳ４１０３のＮＯ）は、そのインターフェースを表示対象から削除する（ステップＳ４１０４）。そして、アクセス権判定部２０５は、全てのインターフェースを検証したか否かを判別する(ステップＳ４１０５)。全てのインターフェースを検証していない場合、ステップＳ４１０２の処理に戻り、全てのインターフェースについて上記の処理を繰り返す（ステップＳ４１０５）。

一方、全てのインターフェースを検証すると、アクセス権判定部２０５は、本処理を終える。

さらに、継承関係を考慮した処理を続ける。図２３を用いてその処理を説明する。図２３はクラス継承時のアクセス権判定部２０５によるソース表示方法の判断処理手順を示すフローチャートである。まず、アクセス権判定部２０５は、対象のクラスが他のクラスを継承しているか否かを調べる（ステップＳ１３０１）。他のクラスを継承していない場合（ステップＳ１３０１のＮＯ）、アクセス権判定部２０５はそのまま本処理を終了する。一方、他のクラスを継承している場合（ステップＳ１３０１のＹＥＳ）、アクセス権判定部２０５は、その継承の階層にある全てのクラスを取得する（ステップＳ１３０２）。そして、アクセス権判定部２０５は、その階層中にアクセス権のないクラス、つまり、アクセス制限の対象となっているクラスであって、操作ユーザが利用権限、参照／編集可能権限を持っていないクラスがあるか否かを調べる（ステップＳ１３０３）。アクセス権のないクラスが含まれない場合（ステップＳ１３０３のＮＯ）、アクセス権判定部２０５は、本処理を終了する。

一方、アクセス権がないクラスが含まれる場合（ステップＳ１３０３のＹＥＳ）、アクセス権判定部２０５は、そのクラスが対象クラスの直接の継承元であるか否かを判別する（ステップＳ１３０４）。そのクラスが対象クラスの直接の継承元でない場合、アクセス権判定部２０５はステップＳ１３０７の処理に進む。一方、そのクラスが対象クラスの直接の継承元である場合（ステップＳ１３０４のＹＥＳ）、アクセス権判定部２０５は、対象クラスの継承元を、継承階層中でアクセス権がある最も近いクラス（クラス継承先）に変更する（ステップＳ１３０５）。これにより、操作ユーザに対しては、クラスの継承階層からアクセス権のないクラスが隠蔽される。

さらに、この隠蔽されたクラスが、継承階層中のアクセス権のあるメソッドをオーバライドしている場合、アクセス権判定部２０５は、そのオーバライドされているメソッドを、対象クラスでオーバライドしている形に変更する（ステップＳ１３０６）。これにより、アクセス権がないクラスが隠蔽さていても、当該メソッドがオーバライドされていることを示すことができる。

そして、アクセス権判定部２０５は、対象クラスがアクセス権のないクラスのメソッドをオーバライドしているか否かを判別する（ステップＳ１３０７）。対象クラスがアクセス権のないクラスのメソッドをオーバライドしている場合（ステップＳ１３０７のＹＥＳ）、アクセス権判定部２０５は、対象クラスから当該メソッドを削除する（ステップＳ１３０８）。この後、アクセス権判定部２０５は本処理を終了する。一方、対象クラスがアクセス権のないクラスのメソッドをオーバライドしていない場合、アクセス権判定部２０５は本処理を終了する。

このように、図２１および図２３の処理における判断結果から、表示方法が決定され、それに従って、開発環境制御部２０４はソースコード３３０の表示画面を作成する（ステップＳ５１０）。この表示方法の判断結果に対応し、開発環境制御部２０４が生成する表示画面を、再度、図１３〜図１５で示すソース例を用いて、説明する。対象クラスのソースコードが表示可能と判断される場合（例えば、ステップＳ１２０３）、図１３の表示２７０１に示すように、全てのソースコードが表示される。

インターフェースのみに制限される場合であって、クラス継承階層上のインターフェースの変更はないと判断される場合（例えば、ステップＳ１３０１のＮＯ）、図１４の表示２８０２で示すように、実装が削除され、宣言の形で表示される。さらに、表示内容は言語仕様におけるアクセス権があるもの（ｐｕｂｌｉｃ／ｐｒｏｔｅｃｔｅｄ）のみとなる。さらに、インターフェースの宣言の要素（インスタンス変数、クラス変数の型、メソッドの引数、リターン値）には、アクセス権のない別のインターフェースが含まれないこととなる。

例として、図１５の表示２９０５には、表示２７０５の４行目の定数宣言が表示されていないが、これはステップＳ４１０１の処理によるものである。また、表示２７０５の６〜８、１１行目にあたる部分も表示されていないが、これはステップＳ４１０４の処理によるものである。

インターフェースのみに制限され、クラス継承階層上のインターフェースの変更が行われると判断される場合（例えば、ステップＳ１３０４のＹＥＳ）、継承関係の変更が行われたインターフェースの表示となる。例として、図１５の表示２９０３で示すように、１行目の継承元がＣｌａｓｓ ＡからＣｌａｓｓ Ｄ１に変更されているが、これはステップＳ１３０５の処理に対応する。また、表示２７０３の１５行目でＣｌａｓｓ Ｂ２がＣｌａｓｓ Ａのメソッド ｐｒｏＡ（）をオーバライドしているが、表示２９０３ではその表示は削除されている。これはステップＳ１３０８の処理による。逆に、表示２９０３の１２行目でＣｌａｓｓ Ｄ１のメソッドｐｒｏＤ１（）がオーバライドされているように表示されているが、これは実際には隠蔽されたＣｌａｓｓ Ａがオーバライドしているメソッドである（表示２７０２の１５行目）。これはステップＳ１３０６の処理によるものである。

対象クラスのソースコードは表示不可と判断される場合（例えば、ステップＳ１２０５）、図１５の表示２９０２のように表示される。

また、パネル２１０５において、編集作業を行う際、入力中のクラスやメソッドの候補を表示し、ソースコードの入力作業の省力化を行う機能、いわゆるコードアシスト機能を提供する場合にも、同じようなアクセス権限に従った表示を行うことができる。

図２４はパネル２１０５でのコードアシスト機能の表示例を示す図である。パネル２４０１には、途中まで入力されたクラス名に対して入力可能な候補の一覧が表示されている。

図２５は入力可能な候補の一覧を作成する際の処理手順を示すフローチャートである。まず、開発環境制御部２０４は、全てのインターフェースをリストアップする（ステップＳ１４０１）。ここでいうインターフェースとは、クラス名の入力中の場合、クラスであり、メソッド名を入力中の場合、メソッドである。パネル２４０１の例では、全てのクラスがリストアップされている。

開発環境制御部２０４は、このインターフェース名が入力途中の文字列にマッチするか否かを判断する（ステップＳ１４０２）。マッチする場合（ステップＳ１４０２のＹＥＳ）、さらに、開発環境制御部２０４は、マッチしたインターフェースに対するアクセス権があるか否かを判断する（ステップＳ１４０３）。このステップＳ１４０３で行われる判断処理は、前述したアクセス権の判断処理と同様に行われる。即ち、クラス名の場合、図１８のステップＳ９０１〜Ｓ９０５の処理と同じである。また、メソッド名の場合、図２１のステップＳ１２０１〜１２１１、図２３のＳ１３０１〜Ｓ１３０８の結果得られる表示可能なインターフェースに、当該メソッドが含まれる場合、アクセス権があると判断される。

アクセス権があると判断された場合（ステップＳ１４０３のＹＥＳ）、開発環境制御部２０４は、表示する候補リストに、マッチしたインターフェースを追加する（ステップＳ１４０４）。

そして、開発環境制御部２０４は、全ての対象のインターフェースに対する処理が行われるまで、上記ステップＳ１４０２からの処理を繰り返す（ステップＳ１４０５）。全ての対象のインターフェースに対する処理が行われると、その結果得られる候補リストが表示されることになる。

また、アクセス制限が行われ、本来参照できないインターフェースがある場合、ソースコード中に、そのインターフェースの呼び出しが直接記述されることを防ぐことも可能である。ソースコードを保存するタイミングで、利用しているインターフェースを抽出し、上記コードアシストの処理で説明したように、インターフェースのリストアップ結果に含まれないインターフェースがある場合、保存を制限し、警告を表示することも可能である。

ところで、クラスの継承階層が多重継承になっている場合も同じ処理でアクセス権が判断される。図２６は多重継承の関係があるクラス階層の例をＵＭＬのクラス図の形式で示した図である。Ｊａｖａ（登録商標）言語の場合、実装の多重継承は不可能であるので、一方のクラスはインターフェースのみの継承として示されている。Ｃｌａｓｓ Ｂが多重継承の形となっており、Ｃｌａｓｓ Ｂは、Ｃｌａｓｓ Ａから実装を継承（ｅｘｔｅｎｄｓ）し、また、Ｃｌａｓｓ Ｄ２のインターフェースを継承（ｉｍｐｌｅｍｅｎｔｓ）している。

前述したＵｓｅｒ１、Ｕｓｅｒ２，Ｕｓｅｒ３について、同様に表示の違いを説明する。各ユーザのアクセス権は、Ｃｌａｓｓ Ａ（３００１）に対し、前述した図１１の説明と同様に設定されているとする。

Ｃｌａｓｓ Ｄ１（３００５）およびＣｌａｓｓ Ｄ２（３００６）は、全ユーザで同じように、全てのソースコードが表示される（図２７の表示３１０１〜３１０２、図２８の表示３２０１〜３２０２、図２９の表示３３０１〜３３０２参照）。図２７はＵｓｅｒ１の各クラスのソースコードを開いたときのエディタパネル２１０５での表示内容を示す図である。図２８はＵｓｅｒ２の各クラスのソースコードを開いたときのエディタパネル２１０５での表示内容を示す図である。図２９はＵｓｅｒ３の各クラスのソースコードを開いたときのエディタパネル２１０５での表示内容を示す図である。

Ｃｌａｓｓ Ｃ１（３００３）およびＣｌａｓｓ Ｃ２（３００４）についても、図示していないが、全ユーザで同じように全てのソースコードが表示される。

Ｃｌａｓｓ Ａ（３００１）については、前述した図１１に示すとおり、Ｕｓｅｒ１では全てのソースコードが表示される（図２７の表示３１０３）。また、Ｕｓｅｒ２ではインターフェースのみが表示され（図２８の表示３２０３）、Ｕｓｅｒ３ではこれらの情報は表示されない（図２９の表示３３０３）。

ここで、Ｃｌａｓｓ Ｂ（３００２）については、Ｕｓｅｒ１、Ｕｓｅｒ２では、同じように、全てのソースコードが表示される（図２７の表示３１０４、図２８の表示３２０４）。Ｕｓｅｒ３では（図２９の表示３３０４）、アクセス権のないＣｌａｓｓ Ａの継承関係にかかわる部分について、継承元がＣｌａｓｓ Ｄ１に変更され、Ｃｌａｓｓ ＡでオーバライドされていたＣｌａｓｓ Ｄ１のメソッドｐｒｏＤ１（）の宣言が追加されている。また、Ｃｌａｓｓ ＡのメソッドｐｒｏＡ（）のオーバライドは表示されない。これは前述の処理と同様である。Ｃｌａｓｓ Ｄ２に関連する部分も、実装が表示されず、インターフェースのみの宣言の表示（１５行目）となっている。これらの表示は、図２１のステップＳ１２０１〜１２１１、図２３のステップＳ１３０１〜Ｓ１３０８の処理で同様に行われる。

このように、第１の実施形態のソフトウェア開発システムによれば、機密情報へのアクセス制限を実現した上で、プログラムの開発作業が行える開発環境を備えることができる。また、機密保護対象のプログラムモジュールのソースコードに対し、その利用が許可された開発者には、機密保護対象のインターフェースへのアクセスが制限されない開発環境を提供することができる。この場合、それ以外の開発者では、機密保護対象のインターフェースへのアクセスも制限される。

従って、コンパイル済みのオブジェクトやデータの配布を必要とせずに、機密保護対象へのアクセス制限を行う開発環境の提供が可能になる。さらに、開発作業を行う場所は限定されないため、顧客データなどの外部への持ち出し不可能なデータを用いた障害解析作業を、遠隔の環境から行うことができる。また、複数の開発拠点をまたがった分散開発作業が、機密保護を実現した上で可能となる。さらに、担当者ごとに適切なアクセス制限が行われることになるので、１つの実行環境上で、プログラムの不具合の解析作業を行う場合などの連携作業が、機密保護を実現した上で可能となる。

また、ソースコードへの機密保護を実現しつつ、ソースコードのコンパイル、プログラムの実行が可能になり、オブジェクトやデータの配布を必要としない。また、クラス継承を含むプログラミング言語であっても、適切なアクセス制御が実現される。また、言語仕様上利用不可能なインターフェースを考慮した表示が行われる。また、アクセス権を言語仕様のスコープと関連づけて容易に設定することができる。

［第２の実施形態］
第２の実施形態では、プログラミング言語としてＣ言語を利用する場合について説明する。第１の実施形態のプログラミング言語として利用されるＪａｖａ（登録商標）言語との言語仕様の違いから、次の点について、考慮する必要がある。

まず、Ｃ言語では、関数や変数などのシンボルのスコープ範囲が明確でないことから、パッケージやクラス単位といった言語仕様で提供されるスコープを指定してアクセス権の適用範囲を指定できない。

また、Ｃ言語では、実装とは別に、宣言を別ファイルに記述することができる（ヘッダファイル）。また、言語仕様におけるアクセス制限（ｐｕｂｌｉｃやｐｒｏｔｅｃｔｅｄ）の概念がないため、外部向けのインターフェースと内部向けのインターフェースを区別できないことが挙げられる。なお、第２の実施形態におけるソフトウェア開発システムのシステム構成は前記第１の実施形態と同様である（図１参照）。

図３０は第２の実施形態におけるソースコードファイルの関係を示す図である。まず、図３０の各ソースファイルについて、各ユーザでの表示の違いについて説明する。点線の矢印で示されるｉｎｃｌｕｄｅは、ヘッダファイルをｉｎｃｌｕｄｅしていることを示す。点線の矢印で示されるｕｓｅは、別ファイルの関数を呼び出していることを示している。

アクセス制限の設定の方法では、前述したように、言語仕様におけるスコープの単位が存在しないので、ディレクトリ単位あるいはファイル単位で設定が行われる。また、言語仕様におけるアクセス制限の機能が存在しないので、利用者に公開したいインターフェースを独立したヘッダファイルとして作成する。そして、そのヘッダファイルに利用可能権限の設定を行うことで、アクセス制限を行うスコープ内の特定のインターフェースのみを利用可能として公開する。

図３１はこのようにして設定したスコープ単位のアクセス権情報を示すテーブルである。アクセス権情報のテーブル３８００において、「対象スコープ」のフィールド３８０１には、設定対象のディレクトリもしくはファイルが設定される。「利用可」のフィールド３８０２には、利用可能権限が与えられたユーザが設定される。「編集可」のフィールド３８０３には、参照／編集可能権限が与えられたユーザが設定される。図示しないフィールドの「スコープＩＤ」はこの設定レコードを示す識別子となる。このテーブル３８００は、前記第１の実施形態と同様、図８のシーケンスで示される方法で設定されることになる。

図３０、図３１に示すように、ディレクトリａ（３４０９）に対し、「編集可」のフィールド３８０３には、Ｕｓｅｒ１が設定されている。また、ディレクトリａ（３４０９）内のファイルａ．ｈ（３４０１）に対し、「利用可」のフィールド３８０２には、Ｕｓｅｒ２が設定されている。「編集可」のフィールド３８０３には、”ｐａｒｅｎｔ”が設定されている。この設定された”ｐａｒｅｎｔ”は、親の階層の定義、ここではディレクトリａ（３４０９）の設定に従うことを意味している。

この設定により、Ｕｓｅｒ１は無制限にアクセスが可能、Ｕｓｅｒ２はディレクトリａ（３４０９）内のうち、ファイルａ．ｈ（３４０１）に記述されているインターフェースのみアクセス可能、Ｕｓｅｒ３はディレクトリａ内へのファイルはアクセス不可能となる。

図３２はＵｓｅｒ１の表示内容を示す図である。図３３はＵｓｅｒ２の表示内容を示す図である。図３４はＵｓｅｒ３の表示内容を示す図である。図３２〜図３４には、このときの各ユーザの表示の違いが示されている。

ファイルａ．ｈ（３４０１）の内容は、Ｕｓｅｒ１、Ｕｓｅｒ２では、全て表示される（表示３５０１、３６０１）。Ｕｓｅｒ３では、アクセス制限され、ファイルａ．ｈ（３４０１）の内容は表示されない（表示３７０１）。

ファイルａ２．ｈ（３４０３）の内容は、Ｕｓｅｒ１では、全て表示される（表示３５０２）。Ｕｓｅｒ２、Ｕｓｅｒ３では、ファイルａ２．ｈ（３４０３）の内容はアクセス制限され、表示されない（表示３６０２、３７０２）。ファイルａ．ｃ（３４０２）も、Ｕｓｅｒ１では、全て表示される（表示３５０３）。Ｕｓｅｒ２、Ｕｓｅｒ３では、ファイルａ．ｃ（３４０２）はアクセス制限され、表示されない（表示３６０３、３７０３）。ファイルａ２．ｃ（３４０４）も同様、Ｕｓｅｒ１では、全て表示される（表示３５０４）。Ｕｓｅｒ２，Ｕｓｅｒ３では、ファイルａ２．ｃ（３４０４）の内容はアクセス制限され表示されない（表示３６０４、３７０４）。

ファイルｂ．ｈ（３４０５）は、インターフェースの宣言のみであるので、Ｕｓｅｒ１、Ｕｓｅｒ２、Ｕｓｅｒ３のいずれでも、その内容は全て表示される（表示３５０５、３６０５、３７０５）。ファイルｂ．ｃ（３４０６）は、ファイルａ．ｈで定義されているインターフェースへの呼び出しを含む実装ファイルである。このため、Ｕｓｅｒ１、Ｕｓｅｒ２では、その内容は全て表示されるが（表示３５０６、３６０６）、Ｕｓｅｒ３では、インターフェースのみに制限されてその内容は表示される（表示３７０６）。また、関数ｆｕｎｃ＿ｂ２（）（表示３５０６の９行目）は、引数にａ．ｈ（３４０１）で定義されている型ａ＿ｔを利用しているため、表示されるインターフェースから削除されている。

ファイルｃ．ｃ（３４０７）については、全てのユーザで表示は制限されない（表示３５０７、３６０７、３７０７）。

前述したように、Ｃ言語の場合、あるシンボル（関数、変数など）が含まれるディレクトリやファイルなどのスコープが言語仕様から明確には特定できない。アクセス権はスコープ単位で設定されるので、シンボルがどのスコープに属しているかを判断し、そのシンボルのアクセス権を判断する必要がある。

そこで、スコープ毎のアクセス権情報（図３１）とは別に、シンボル（インターフェース）毎にアクセス権情報のテーブル３９００（図３５参照）を保持する。図３５はシンボル毎のアクセス権情報を示すテーブルである。

このテーブル３９００は、テーブル３８００の利用権限が設定されている対象スコープ（フィールド３８０１）内のソースコードから、シンボルの宣言を抽出して作成されたものである。シンボルの宣言とは、外部のソースから利用されるインターフェース定義を記述したものである。ここでは、関数のプロトタイプ宣言、変数の外部宣言、構造体の定義、また、マクロ定義も宣言として扱うことにする。一般的に、これらはヘッダファイル（．ｈファイル）に記述される内容である。

各抽出したシンボル（フィールド３９０１）に対し、このシンボルの定義ファイル（フィールド３９０２）が記録されている。これにより、シンボル毎のアクセス権の情報（インターフェース毎のアクセス権情報）は、定義ファイル（フィールド３９０２）に対応するアクセス権情報をテーブル３８００から参照することで得られることになる。このテーブルは、外部ファイルから利用される可能性のあるシンボルのうち、アクセス制限が掛けられているシンボルが登録されているテーブルとなる。このように、インターフェース毎のアクセス権情報は、ソースコードのファイルから抽出されたインターフェース定義を、スコープ毎のアクセス権情報と関連付けて保持したものである。

テーブル３９００は、ソースコードのファイルを編集、保存したタイミングで更新される。これにより、新規に関数などを追加した場合にもアクセス権情報が同期して更新されることになる。図３６はソースコードのファイル保存時のシーケンスを示す図である。このシーケンスは図６のシーケンスとほぼ同じであるが、このシーケンスには、ステップＳ１９０１において、開発環境制御部２０４がアクセス権設定部２０７に対し、アクセス権情報の更新を要求する処理が追加されている。

図３７はアクセス権設定部２０７によるシンボル単位のアクセス権テーブルの更新処理手順を示すフローチャートである。まず、アクセス権設定部２０７は、スコープ単位のアクセス制限情報テーブル３８００を参照し、対象のファイルが対象スコープ（フィールド３８０１）に含まれるか否かを判断する（ステップＳ１５０１）。この判断は、対象スコープ（フィールド３８０１）がディレクトリもしくはファイルであるので、対象のファイルが、設定されているディレクトリに含まれるか、あるいは設定されているファイルと一致するか否かで行われる。

対象スコープに含まれる場合（ステップＳ１５０１のＹＥＳ）、アクセス権設定部２０７は、まず対象ファイルに含まれるシンボルの宣言を、対象ファイルを文法解析して抽出する。そして、アクセス権設定部２０７は、抽出したシンボルを、シンボル単位のアクセス制限情報テーブル３９００に登録する（ステップＳ１５０２）。この後、アクセス権設定部２０７は本処理を終える。なお、対象ファイルが、複数の対象スコープに含まれる場合、スコープ範囲の狭いほうが適用される。また、テーブル３９００に設定済みのシンボルが、対象ファイルに存在しない場合、テーブル３９００から削除される。

一方、保存対象ファイルが対象スコープに含まれない場合（ステップＳ１５０１のＮＯ）、アクセス権設定部２０７は、テーブル３９００の更新を行わない。そして、アクセス権設定部２０７は本処理を終える。

テーブル３９００の更新のタイミングとして、他に、テーブル３８００にアクセス権が定義されるタイミングで更新される場合もある。これは、アクセス制限の対象スコープを追加した場合に相当する。図８のステップＳ６１１において、アクセス権情報２０６の設定が行われるが、その際、テーブル３８００の更新を行う。さらに、追加された対象スコープ内の全ファイルに対し、図３７の処理を行ってテーブル３９００の更新を行う。

つぎに、第２の実施形態における、ソースコード３３０のディレクトリツリーをパネル２１０６に表示する際のアクセス制限の処理について説明する。図１７のシーケンスにおいて、ステップＳ８０５におけるアクセス権判定部２０５の処理が前記第１の実施形態と異なる。アクセス権判定部２０５は、ディレクトリ内に含まれる各ヘッダファイル、実装ファイル、ディレクトリに対してアクセス権を判定する。図３８はその際のアクセス権判定部２０５の処理手順を示すフローチャートである。

まず、アクセス権判定部２０５は、スコープ単位のアクセス制限情報テーブル３８００を参照し、対象ファイルがアクセス制限のスコープに含まれるファイルであるか否かを判定する（ステップＳ１６０１）。アクセス制限対象に含まれない場合（ステップＳ１６０１のＮＯ）、アクセス権判定部２０５は、ファイル名の表示を可能と判断し（ステップＳ１６０５）、本処理を終える。

一方、アクセス制限対象に含まれる場合（ステップＳ１６０１のＹＥＳ）、アクセス権判定部２０５は、テーブル３８００を参照し、操作ユーザが対象ファイルへの利用権限、あるいは参照／編集権限を有するか否かを判断する（ステップＳ１６０３）。

権限がある場合（ステップＳ１６０３のＹＥＳ）、アクセス権判定部２０５は、ファイル名の表示を可能と判断し（ステップＳ１６０５）、本処理を終える。一方、権限がない場合（ステップＳ１６０３のＮＯ）、アクセス権判定部２０５は、ファイル名を表示不可と判断し（ステップＳ１６０４）、本処理を終える。

また、ソースコード３３０をパネル２１０５で表示する際のアクセス制限の処理は次のようになる。図２０のシーケンスにおいて、ステップＳ１１０２におけるアクセス権判定部２０５の処理が前記第１の実施形態と異なる。図３９はその際のアクセス権判定部２０５によるアクセス制限処理手順を示すフローチャートである。アクセス権判定部２０５は、まず、スコープ単位のアクセス制限情報テーブル３８００を参照し、対象ファイルがアクセス制限のスコープに含まれるファイルであるか否かを判定する（ステップＳ１７０１）。

アクセス権判定部２０５は、アクセス制限対象に含まれる場合（ステップＳ１７０１のＹＥＳ）、アクセス制限情報テーブル３８００を参照し、操作ユーザが対象ファイルへの参照／編集権限を有する否かを判断する（ステップＳ１７０２）。

参照／編集権限がある場合（ステップＳ１７０２のＹＥＳ）、アクセス権判定部２０５は、対象ファイルの内容を表示可能と判断し（ステップＳ１７０５）、本処理を終える。一方、アクセス権がない場合（ステップＳ１７０２のＮＯ）、アクセス権判定部２０５は、アクセス制限情報テーブル３８００を参照し、操作ユーザが対象ファイルへの利用権限を有するか否かを判断する（ステップＳ１７０３）。

利用権限がある場合（ステップＳ１７０３のＹＥＳ）、アクセス権判定部２０５は、対象ファイルのソースコードの表示を、宣言のみに限定すると判断し（ステップＳ１７０６）、本処理を終える。一方、利用権限がない場合（ステップＳ１７０３のＮＯ）、アクセス権判定部２０５は、対象ファイルを表示不可と判断し（ステップＳ１７０４）、本処理を終える。

ステップＳ１７０１でアクセス制限対象に含まれない場合、アクセス権判定部２０５は、対象ファイル中の実装で外部のシンボルを参照している箇所、つまり外部ファイルで定義されている関数の呼び出し、変数の参照などを抽出する（ステップＳ１７０７）。この外部のシンボルを参照している箇所、つまり外部ファイルで定義されている関数の呼び出し、変数の参照などは、外部インターフェースに相当する。

アクセス権判定部２０５は、得られた外部参照している各シンボルに対し、アクセス制限情報テーブル３９００を参照し、シンボルに対する利用権限があるか否かを判断する（ステップＳ１７０８）。これは、テーブル３９００を参照し、判断対象のシンボルの定義ファイル（フィールド３９０２）を特定し、その定義ファイルの利用権限を、テーブル３８００を参照して特定することにより行われる。

シンボルに対するアクセス権がない場合（ステップＳ１７０８のＮＯ）、アクセス権判定部２０５は、ソースコードの表示を宣言のみに限定すると判断し（ステップＳ１７１１）、本処理を終える。一方、シンボルに対する利用権限がある場合、アクセス権判定部２０５は、残りの抽出された全てのシンボルについて、終わるまで同じ検証を行う（ステップＳ１７０９）。全てのシンボルの検証が終了した場合（ステップＳ１７０９のＹＥＳ）、アクセス権判定部２０５は、対象ファイルのソースコードを表示可能と判断し（ステップＳ１７１０）、本処理を終える。

さらに、ステップＳ１７０６、Ｓ１７１１で宣言のみに表示を制限すると判断された場合、表示すべきインターフェースを抽出する処理を行う。図４０は表示すべきインターフェースの抽出処理手順を示すフローチャートである。

アクセス権設定部２０７は、ソースコードから実装を除いた、宣言のみの状態、つまり関数宣言、変数宣言、構造体の定義またはマクロ定義のみの状態とし、各宣言について、それらの宣言で利用されている外部参照のシンボルを抽出する（ステップＳ４２０１）。

アクセス権設定部２０７は、テーブル３９００を参照し、シンボルに対する利用権限があるか否かを判断する（ステップＳ４２０２）。利用権限がない場合、アクセス権設定部２０７は、その宣言を表示対象から削除する（ステップＳ４２０３）。全ての宣言について検証を終えるまで上記の処理を繰り返す（ステップＳ４２０４）。

第２の実施形態におけるソフトウェア開発システムによれば、Ｃ言語などシンボルの名前空間が言語仕様上不明確な場合や、言語仕様上のアクセス制限機能がない場合においても、シンボルが定義されているスコープの特定を容易にすることができる。また、スコープ単位でのアクセス権の設定が可能になる。また、開発担当者単位でのアクセス制限を行うことが可能になる。また、機密情報への外部からのアクセスを防ぐことができる。

［第３の実施形態］
第３の実施形態として、アクセスの制限を、特定のユーザではなく、ユーザの操作場所（配置場所単位）で行う場合を示す。また、アクセス制限対象クラスにおいて、インスタンスの値を参照する際にアクセス制限を行う場合について説明する。例えば、顧客情報がデータベース３１３に含まれている場合、プログラムは顧客情報を表すクラスによりその情報にアクセスする場合、デバッガ上で顧客情報を表すクラスの値を参照することによる顧客情報の表示を制限する。なお、第３の実施形態におけるソフトウェア開発システムのシステム構成は前記第１の実施形態と同様である（図１参照）。

図４１は第３の実施形態におけるアクセス権情報２０６を示すテーブルである。フィールド４００１の「対象スコープ」は、図１１の対象スコープ（フィールド２５０１）と同じものである。フィールド４００２の「利用可」には、利用可能権限が与えられたＩＰアドレスが設定される。ＩＰアドレスには、アクセスを許可するネットワークを示すサブネットマスク値が設定されている。フィールド４００３の「編集可」にも、同様に、参照／編集可能権限が与えられたネットワークのＩＰアドレスが設定されている。

図４２はデバッグ時の動作例として、図４のパネル２１０４に、あるクラスの変数の値を表示する際の動作を示す図である。あるクラスで定義されている変数を参照することは、そのクラスに対する参照／編集権限がある場合に制限される。例えば、図１５の表示２９０５で示すように、Ｕｓｅｒ３はＣｌａｓｓ Ｂ１（２６０２）の実装を参照できないため、Ｃｌａｓｓ Ｃ１（２６０４）がＣｌａｓｓ Ｂ１（２６０２）のインスタンス変数を保持することになる。あるいは、メソッドのリターン値がＣｌａｓｓ Ｂ１（２６０２）のインスタンスである場合、それらの変数の値、あるいは、リターン値の参照は制限されることになる。

まず、ユーザが変数の参照操作を行うと（ステップＳ１８０１）、開発環境ＧＵＩ１０１はクライアント通信部２０１に対して変数参照要求を送出する（ステップＳ１８０２）。クライアント通信部２０１は開発環境制御部２０４に変数参照を指示する（ステップＳ１８０３）。開発環境制御部２０４は、デバッガ３２２に対して変数参照を実行させ、変数の値を取得する（ステップＳ１８０４）。

次に、開発環境制御部２０４は、クライアント通信部２０１からクライアント端末１００のＩＰアドレスを取得する（ステップＳ１８０５）。そして、開発環境制御部２０４は、アクセス権判定部２０５に対し、対象の変数が定義されているクラスを特定し、そのクラスのアクセス権の判断を依頼する（ステップＳ１８０６）。このとき行われるアクセス権の判断は、図２１の処理と同じである。操作ユーザが利用権限、あるいは参照／編集可能権限を有するか否かの判断は、ステップＳ１８０５で取得したクライアント端末１００のＩＰアドレスが、フィールド４００２、フィールド４００３のネットワークアドレスに含まれているか否かによって行われる。

そして、ステップＳ１８０７で対象クラスの表示方法が返却される。開発環境制御部２０４は、表示方法として、対象クラスのソースコードを表示可能である場合、変数表示画面にステップＳ１８０４で取得した変数値が表示された画面を生成し、それ以外、変数値が表示されない画面を生成する（ステップＳ１８０８）。生成された画面はクライアント通信部２０１から開発環境ＧＵＩ１０１に送信される（ステップＳ１８０９）。

第３の実施形態のソフトウェア開発システムによれば、アクセスの制限を、特定のユーザではなく、ユーザの操作場所で行う場合においても、前記第１の実施形態と同様の効果を得ることができる。

なお、本発明は、上記実施形態の構成に限られるものではなく、特許請求の範囲で示した機能、または本実施形態の構成が持つ機能が達成できる構成であればどのようなものであっても適用可能である。

また、本発明の目的は、以下の処理を実行することによって達成される。即ち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出す処理である。

この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。

また、プログラムコードを供給するための記憶媒体としては、次のものを用いることができる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等である。または、プログラムコードをネットワークを介してダウンロードしてもよい。

また、コンピュータが読み出したプログラムコードを実行することにより、上記実施の形態の機能が実現される場合も本発明に含まれる。加えて、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。

更に、前述した実施形態の機能が以下の処理によって実現される場合も本発明に含まれる。即ち、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行う場合である。

Ｗｅｂアプリケーションの開発環境を備えたソフトウェア開発システムの構成を示す図である。 リモート開発環境３００をサーバ２００上に構築する際のシーケンスを示す図である。 開発環境ＧＵＩ１０１で表示されるプロジェクト一覧画面２０００を示す図である。 開発環境ＧＵＩ１０１で表示される開発環境画面２１００を示す図である。 開発環境画面２１００の操作例として、ソースコード３３０をエディタパネル２１０５に表示する際のシーケンスを示す図である。 開発環境画面２１００の操作例として、ソースコード３３０のコンパイルを行う際のシーケンスを示す図である。 開発環境画面２１００の操作例として、デバッガ操作を行う際のシーケンスを示す図である。 アクセス権限を設定する操作が行われるときの動作シーケンスを示す図である。 開発環境ＧＵＩ１０１で表示されるアクセス権設定対象選択画面２２００を示す図である。 開発環境ＧＵＩ１０１で表示されるアクセス権設定画面２３００を示す図である。 アクセス権情報２０６で記録されている情報を示すテーブルである。 クラスの関係をＵＭＬ（Unified Modeling Language）のクラス図の表記を用いて示す図である。 Ｕｓｅｒ１の各クラスのソースコードを開いたときのエディタパネル２１０５での表示内容を示す図である。 Ｕｓｅｒ２の各クラスのソースコードを開いたときのエディタパネル２１０５での表示内容を示す図である。 Ｕｓｅｒ３の各クラスのソースコードを開いたときのエディタパネル２１０５での表示内容を示す図である。 ユーザ認証のシーケンスを示す図である。 パネル２１０６でソースコード３３０が格納されているディレクトリを表示する際のアクセス制限の処理を示す図である。 ステップＳ８０５におけるアクセス権判定部２０５によるアクセス権の判定処理手順を示すフローチャートである。 ステップＳ９０１の判定処理手順を示すフローチャートである。 エディタパネル２１０５でソースコードの内容を表示する際のアクセス制限の処理を示す図である。 ステップＳ１１０２の依頼に応じて行われるソースコード３３０の表示方法を決定する処理手順を示すフローチャートである。 アクセス権判定部２０５によるソース表示方法の判断処理手順を示すフローチャートである。 クラス継承時のアクセス権判定部２０５によるソース表示方法の判断処理手順を示すフローチャートである。 パネル２１０５でのコードアシスト機能の表示例を示す図である。 入力可能な候補の一覧を作成する際の処理手順を示すフローチャートである。 多重継承の関係があるクラス階層の例をＵＭＬのクラス図の形式で示した図である。 Ｕｓｅｒ１の各クラスのソースコードを開いたときのエディタパネル２１０５での表示内容を示す図である。 Ｕｓｅｒ２の各クラスのソースコードを開いたときのエディタパネル２１０５での表示内容を示す図である。 Ｕｓｅｒ３の各クラスのソースコードを開いたときのエディタパネル２１０５での表示内容を示す図である。 第２の実施形態におけるソースコードファイルの関係を示す図である。 スコープ単位のアクセス権情報を示すテーブルである。 Ｕｓｅｒ１の表示内容を示す図である。 Ｕｓｅｒ２の表示内容を示す図である。 Ｕｓｅｒ３の表示内容を示す図である。 シンボル毎のアクセス権情報を示すテーブルである。 ソースコードのファイル保存時のシーケンスを示す図である。 アクセス権設定部２０７によるシンボル単位のアクセス権テーブルの更新処理手順を示すフローチャートである。 アクセス権判定部２０５の処理手順を示すフローチャートである。 アクセス権判定部２０５によるアクセス制限処理手順を示すフローチャートである。 表示すべきインターフェースの抽出処理手順を示すフローチャートである。 第３の実施形態におけるアクセス権情報２０６を示すテーブルである。 デバッグ時の動作例として、図４のパネル２１０４に、あるクラスの変数の値を表示する際の動作を示す図である。

符号の説明

５０ ネットワーク
１００ クライアント端末
１０１ 開発環境ＧＵＩ
２００ サーバ
２０１ クライアント通信部
２０２ 開発環境生成部
２０４ 開発環境制御部
２０５ アクセス権判定部
２０６ アクセス権情報
２０７ アクセス権設定部
３００ リモート開発環境
３１０ 実行環境
３２０ 開発ツール
３３０ ソースコード
２１００ 開発環境画面

Claims (15)

1. 開発対象のソースコードを含む開発環境を備えたサーバ装置と、前記開発環境へのユーザインターフェースを備えたクライアント端末とを有するソフトウェア開発システムであって、
   前記サーバ装置は、
   当該サーバ装置に前記開発環境を構築する開発環境生成手段と、
   前記ソースコードに対するアクセス権情報を設定するアクセス権情報設定手段と、
   前記設定されたアクセス権情報を基に、前記ソースコードの表示方法を判断するアクセス権限判断手段とを備え、
   前記判断されたソースコードの表示方法に従って、前記クライアント端末における前記ソースコードの表示を制御することを特徴とするソフトウェア開発システム。
2. 前記アクセス権限判断手段は、前記アクセス権情報を基に、前記ソースコードを全て表示するか、インターフェースのみ表示するか、あるいは表示しないかを判断することを特徴とする請求項１記載のソフトウェア開発システム。
3. 前記アクセス権限判断手段は、前記ソースコードから外部インターフェースを抽出し、前記抽出した外部インターフェースが定義されているソースコードのアクセス権情報を基に、前記ソースコードの表示方法を判断することを特徴とする請求項２記載のソフトウェア開発システム。
4. 前記アクセス権限判断手段は、前記ソースコードから抽出した外部インターフェースがアクセス可能であると判断された場合、前記ソースコードを全て表示すると判断し、前記外部インターフェースがアクセス不可であると判断された場合、前記インターフェースのみ表示すると判断することを特徴とする請求項３記載のソフトウェア開発システム。
5. 前記アクセス権限判断手段は、前記インターフェースのみ表示すると判断した場合、当該インターフェースの要素に、前記アクセス不可である外部インターフェースを含まないインターフェースのみを表示対象とすることを特徴とする請求項４記載のソフトウェア開発システム。
6. 前記ソースコードがクラス継承機能を持つプログラミング言語で記述され、
   前記アクセス権限判断手段は、前記インターフェースのみ表示すると判断した場合、クラスの継承元が利用不可能なクラスである場合、それを除外したクラス継承階層に変更し、除外したクラスでオーバライド定義されていたメソッドを、クラス継承先に移動し、前記インターフェースに、利用不可能なクラスのメソッドのオーバライド定義が含まれる場合、当該メソッドを除外することを特徴とする請求項５記載のソフトウェア開発システム。
7. 前記ソースコードが言語仕様上のアクセス制御機能を持つプログラミング言語で記述され、
   前記アクセス権限判断手段は、前記インターフェースのみ表示すると判断した場合、前記言語仕様上のアクセス制御機能において利用不可能なインターフェースを除外することを特徴とする請求項４記載のソフトウェア開発システム。
8. 前記アクセス権情報は、プログラミング言語の言語仕様上における名前空間のスコープ単位で設定され、
   前記アクセス権限判断手段は、前記ソースコードの表示方法を判断する際、対象のインターフェースが前記名前空間に含まれるか否かを判断することを特徴とする請求項１記載のソフトウェア開発システム。
9. 前記アクセス権情報は、ディレクトリ単位もしくはファイル単位の、スコープ毎のアクセス権情報と、前記ソースコードのファイルから抽出されたインターフェース定義を、前記スコープ毎のアクセス権情報と関連付けて保持した、インターフェース毎のアクセス権情報とからなり、
   前記インターフェース毎のアクセス権情報は、前記スコープ毎のアクセス権情報でインターフェースのみアクセス可能と設定されているソースコードのファイルから抽出したインターフェース定義の情報を保持し、
   前記アクセス権限判断手段は、前記外部インターフェースのアクセス権限の判断を、前記インターフェース毎のアクセス権情報を基に行うことを特徴とする請求項５記載のソフトウェア開発システム。
10. 前記サーバ装置は、ユーザ認証手段を備え、
    前記アクセス権情報は、ユーザ単位のアクセス権を保持し、
    前記アクセス権限判断手段は、ユーザ単位のアクセス権限を判断することを特徴とする請求項１記載のソフトウェア開発システム。
11. 前記アクセス権情報は、前記クライアント端末の配置場所単位でアクセス権を保持し、
    前記アクセス権限判断手段は、前記クライアント端末の配置場所単位のアクセス権限を判断することを特徴とする請求項１記載のソフトウェア開発システム。
12. 開発対象のソースコードを含む開発環境を備えたサーバ装置と、前記開発環境へのユーザインターフェースを備えたクライアント端末とを有するソフトウェア開発システムのアクセス制限方法であって、
    前記サーバ装置は当該サーバ装置に前記開発環境を構築しておく開発環境生成ステップと、
    前記サーバ装置は前記ソースコードに対するアクセス権情報を設定しておくアクセス権情報設定ステップと、
    前記サーバ装置は前記設定されたアクセス権情報を基に、前記ソースコードの表示方法を判断するアクセス権限判断ステップと、
    前記サーバ装置は前記判断されたソースコードの表示方法に従って、前記クライアント端末における前記ソースコードの表示を制御する表示制御ステップとを有することを特徴とするソフトウェア開発システムのアクセス制限方法。
13. 開発対象のソースコードを含む開発環境を備え、前記開発環境へのユーザインターフェースを備えたクライアント端末と共にソフトウェア開発システムを構築するサーバ装置であって、
    当該サーバ装置に前記開発環境を構築する開発環境生成手段と、
    前記ソースコードに対するアクセス権情報を設定するアクセス権情報設定手段と、
    前記設定されたアクセス権情報を基に、前記ソースコードの表示方法を判断するアクセス権限判断手段とを備え、
    前記判断されたソースコードの表示方法に従って、前記クライアント端末における前記ソースコードの表示を制御することを特徴とするサーバ装置。
14. 開発対象のソースコードを含む開発環境を備えたサーバ装置と、前記開発環境へのユーザインターフェースを備えたクライアント端末とを有するソフトウェア開発システムを制御するアクセス制限方法をコンピュータに実行させるプログラムにおいて、
    前記アクセス制限方法は、
    前記サーバ装置は当該サーバ装置に前記開発環境を構築しておく開発環境生成ステップと、
    前記サーバ装置は前記ソースコードに対するアクセス権情報を設定しておくアクセス権情報設定ステップと、
    前記サーバ装置は前記設定されたアクセス権情報を基に、前記ソースコードの表示方法を判断するアクセス権限判断ステップと、
    前記サーバ装置は前記判断されたソースコードの表示方法に従って、前記クライアント端末における前記ソースコードの表示を制御する表示制御ステップとを有することを特徴とするプログラム。
15. 請求項１４記載のプログラムを格納することを特徴とするコンピュータで読み取り可能な記憶媒体。

Images