JP3555858B2 - プログラムの編集方法、シングルパッケージ化システム、プログラム開発システム、プログラムの身元情報付加システム及び記憶媒体 - Google Patents
プログラムの編集方法、シングルパッケージ化システム、プログラム開発システム、プログラムの身元情報付加システム及び記憶媒体 Download PDFInfo
- Publication number
- JP3555858B2 JP3555858B2 JP2000082556A JP2000082556A JP3555858B2 JP 3555858 B2 JP3555858 B2 JP 3555858B2 JP 2000082556 A JP2000082556 A JP 2000082556A JP 2000082556 A JP2000082556 A JP 2000082556A JP 3555858 B2 JP3555858 B2 JP 3555858B2
- Authority
- JP
- Japan
- Prior art keywords
- name
- package
- class
- program
- scope
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims description 87
- 238000004806 packaging method and process Methods 0.000 title claims description 19
- 230000008569 process Effects 0.000 claims description 29
- 230000008859 change Effects 0.000 claims description 11
- 239000000284 extract Substances 0.000 claims 1
- 238000010586 diagram Methods 0.000 description 14
- 230000006870 function Effects 0.000 description 4
- 238000007689 inspection Methods 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 230000003068 static effect Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/468—Specific access rights for resources, e.g. using capability register
Description
【０００１】
【発明の属する技術分野】
本発明は、保護されるべきリソースを持つプログラムが不正なプログラムに呼ばれることを防止できるようにプログラムの編集を行うプログラム編集方法に関する。
【０００２】
【従来の技術】
Ｊａｖａは、一つのＪａｖａＶＭの中に、複数のプログラムが実行時にロードされて実行されるというユニークなプログラミング環境を持つ。このため、保護されるべきリソースを持つプログラム（以下、プログラムＡと称す）が、不正なプログラム（以下、プログラムＭと称す）に呼ばれることを防ぐためのメカニズムが必要である。保護することが必要なプログラムＡとしては、ローカルファイルなどをアクセスするシステムクラス群（ＦｉｌｅＩｎｐｕｔＳｔｒｅａｍ等）や、ユーザのプライバシー情報を管理しているクラス、署名されたことによってシステムクラスを呼ぶ権限を保持しているクラスなどがある。
【０００３】
プログラムの実行時にプログラムＡをプログラムＭから見えないようにする手段（動的なアクセス制限）としては、通常、次の二つの方法が使われる。
一つは、プログラムＡとプログラムＭが異なるアプリケーションである場合に、クラスローダを分離する方法である。Ｊａｖａのコードは全てクラス単位の ．ｃｌａｓｓ ファイルによって構成されており、クラスが必要になるとクラスローダ（Ｃｌａｓｓ Ｌｏａｄｅｒ）により動的にロードされる。クラスローダは、当該クラスのプリンシパル（Ｐｒｉｎｃｉｐａｌ）を見て、ロードして良いかどうかを決定する。
他の一つは、プログラムＡがシステムクラスである場合に、スタックインスペクションにより、プログラムＭのプリンシパルをテストする方法である。
【０００４】
しかしながら、クラスローダを分離する方法では、プログラムＡとプログラムＭとを同じウェブページ（ディレクトリ）に置いたならば、プログラムＭがプログラムＡのクラスローダを使用することができるため、アクセス制限を突破できてしまう。
また、スタックインスペクションを行う方法では、署名付きのプログラムＡがアクセスに必要な権限を取得した場合や、ローカルファイルからロードされたクラスに対しては、スタックインスペクションが適用されない。
【０００５】
プログラムの実行に先立ってプログラムＡを保護する手段（静的なアクセス制限）としては、名前スコープを用いてアクセスを制限する方法がある。名前スコープとは、フィールドやメソッドを参照できる範囲を定義するために、当該フィールドやメソッドにおいて宣言されるものである。すなわち、宣言された名前に応じて、他のプログラムからの参照（アクセス）を制御することができる。例えば、ｐｒｉｖａｔｅスコープは他のプログラムから直接参照することは一切できないし、反対に、ｐｕｂｌｉｃスコープは他のプログラムから自由に参照することができる。また、ｐａｃｋａｇｅスコープは、当該ｐａｃｋａｇｅスコープの宣言されたフィールドやメソッドと同一のパッケージ内からでなければ参照することができない。
【０００６】
名前スコープを用いる場合、プライベートと宣言されたフィールドやメソッドは、他のプログラムから直接アクセスされることがないことが保証されている。したがって、プログラムＡに関してプライベートと宣言することにより、プログラムＭからのアクセスを制限することができる。
しかしながら、プログラムが複数のクラスからなり、それらのクラス間にインタラクションが存在する以上、全てのフィールドやメソッドをプライベートと宣言することはできず、いくつかのフィールド及びメソッドは、ｐａｃｋａｇｅ以上（ｐａｃｋａｇｅ、ｐｒｏｔｅｃｔｅｄ、ｐｕｂｌｉｃのいずれか）のスコープを持たざるを得ない。
【０００７】
ｐａｃｋａｇｅスコープは、ＪＤＫ １．２．１までのＪａｖａプログラムでは、任意のプログラムＭが、自由に自分のパッケージを宣言することができる（ただし、パッケージ内だけで有効な名前の範囲に限られる）。このため、プログラムＭがプログラムＡと同じ名前のパッケージを宣言することによって、当該プログラムＡのパッケージに参加してしまう、いわゆる「Ｐａｃｋａｇｅ Ｊｏｉｎｉｎｇ Ａｔｔａｃｋ」が可能であった。すなわち、パッケージは、誤って名前が衝突してしまうことは防げるが、セキュリティ上のアクセスコントロールのメカニズムとしては不十分だった。
【０００８】
ＪＤＫ １．２．２では、一つのパッケージにおける署名者をただ一人だけとする１パッケージ１署名者の原則（Ｏｎｅ−Ｐａｃｋａｇｅ−Ｏｎｅ−Ｐｒｉｎｃｉｐａｌ Ｐｏｌｉｃｙ）が取りいれられたため、プログラムＡが署名されている限り、署名されていないプログラムＭがプログラムＡと同一のパッケージに参加することはできなくなった。従って、署名されたプログラムでは、パッケージと宣言されたフィールドやメソッドは不正なプログラムにアクセスされることはなくなった。このため、Ｐａｃｋａｇｅスコープは、セキュリティ上のアクセス制限の機能を果たせることとなった。
【０００９】
【発明が解決しようとする課題】
上述したように、Ｊａｖａにおいて、保護されるべきリソースを持つプログラムＡが不正なプログラムＭに呼ばれることを防ぐためのメカニズムとしては、名前スコープを用いた静的なアクセス制限手段を用いることが有効である。しかし、セキュリティ上のアクセス制限を実現するのは、プログラムＡに関してプライベートと宣言した場合か、署名されたプログラムＡに関してパッケージと宣言した場合に限られ、ｐｒｏｔｅｃｔｅｄやｐｕｂｌｉｃのスコープを持つクラス、フィールド及びメソッドについては、依然としてセキュリティ上の保護はない。
【００１０】
しかしながら、ある程度以上の大きなＪａｖａプログラムは、複数のパッケージからなることが多く、パッケージ間のインタラクションのために、いくつかのクラス、フィールドまたはメソッドをパブリックにせざるを得ない。したがって、そのようなプログラムでは、ｐｒｉｖａｔｅスコープやｐａｃｋａｇｅスコープを用いたアクセス制限を有効に活用することができない。
【００１１】
そこで本発明は、名前スコープを用いたアクセス制限を有効に活用して、保護されるべきリソースを持つプログラムが不正なプログラムに呼ばれることを防止できるようにＪａｖａプログラムを編集することを目的とする。
【００１２】
また、本発明は、Ｊａｖａにおけるｐａｃｋａｇｅスコープと同様の概念に基づくアクセス制御を実現するプログラミング言語において、保護されるべきリソースを持つプログラムが不正なプログラムに呼ばれることを防止できるようにプログラムを編集することを目的とする。
【００１３】
【課題を解決するための手段】
かかる目的のもと、本発明は、オブジェクト指向プログラミング言語で記述されたプログラムの編集方法において、このオブジェクト指向プログラミング言語は、一定の参照範囲を設定した場合にこの参照範囲内のみでの相互参照を認めるパッケージの概念を持っていること、及びアクセス要求者の身元を特定する身元情報に基づいてアクセス権限を取得するアクセス制御システムを持っていること、という二つの条件を満足する言語であり、複数のクラスにて構成されたアプリケーションプログラムに対し、各クラスに付されたパッケージ名を単一のパッケージ名に置き換えるステップと、前記クラス中の、アプリケーションプログラムの外部から参照されない内部化可能なデータにおける属性を、同一パッケージ内からの参照を受け付けるように変更するステップと、このパッケージ名の置き換えステップとこのデータ属性の変更ステップとを経たアプリケーションプログラムに対して、アクセス要求者の身元を特定する身元情報に基づくアクセス権限を取得させるステップとを含むことを特徴としている。
このような構成とすれば、システムクラスとの間で参照を行うような内部化可能でないメソッド、変数などを除き、同一パッケージ内からの参照を受け付けるように変更されたデータは、このアプリケーションプログラムと同一のアクセス権限を取得したプログラム以外からのアクセスは受け付けなくなる。そこで、一つのパッケージに対するアクセス権限の取得者を一つに限定する原則を採用すれば、このデータに対して、このアプリケーションプログラムの外部からのアクセスが一切できなくなるため、外部からの不正なアクセスを防止できる。
【００１４】
ここで、パッケージ名の置き換えステップによりパッケージ名を置き換えた結果、アプリケーションプログラム中の所定のクラスにおけるクラス名が同一となる場合に、このクラスのクラス名を変更するステップをさらに含むこととすることができる。
このような構成とすれば、異なるパッケージに同一のクラス名を持つクラスが存在している場合にも、このアプリケーションプログラムのシングルパッケージ化を行える点で好ましい。
【００１５】
このクラス名変更ステップは、所定のクラスのクラス名を変更するために、パッケージ名の置き換えステップによる変更前のこのクラスが属するパッケージ名に用いられた文字列を用いて新たなクラス名を生成することができる。
このような構成とすれば、衝突を回避する新たなクラス名を機械的に生成できる点で好ましい。パッケージ名に用いられた文字列を用いて新たなクラス名を生成する具体的な手法としては、例えば、パッケージ名のドットをアンダースコア（下線）に置き換えてそのまま用いるといった方法を採ることができる。また、確実に衝突を回避するために、どのクラス名にも現れない文字列を新たなクラス名に追加するようにしても良い。
【００１６】
またここで、パッケージ名を変更した際に重複するクラス名が存在するかどうかを検出せず、機械的に、このアプリケーションプログラム中のクラスのクラス名を、相互に重複しない固有のクラス名に変更するステップをさらに含むこととすることができる。
クラス名を変更する具体的な手法としては、例えば、各クラスに連続番号を振るといった方法を採ることができる。
【００１７】
また、本発明によれば、Ｊａｖａのプログラムをシングルパッケージ化する、次のようなシングルパッケージ化システムを実現することができる。すなわち、複数のクラスにて構成されたＪａｖａのプログラムを入力する入力手段と、この入力手段にて入力されたプログラム中の、各クラスが属するパッケージのパッケージ名を単一のパッケージ名に置き換えるパッケージ名置き換え手段と、前記クラス中の、このプログラムの外部から参照されない内部化可能なデータの名前スコープを、パッケージスコープに変更する名前スコープ変更手段と、このパッケージ名の置き換えとこの名前スコープの変更とが行われたプログラムを出力する出力手段とを備える。
このような構成とすれば、このプログラム中のメッセージや変数のうちで、このプログラムの中でのみ参照が行われるものに関しては、このプログラム全体を含む単一のパッケージの外部からのアクセスを受け付けなくなる。したがって、このプログラムに電子署名を施し、一つのパッケージにおける署名者をただ一人だけとする１パッケージ１署名者の原則を併せて採用することにより、このメッセージや変数に対して、このプログラムの外部からのアクセスが一切できなくなるため、外部からの不正なアクセスを防止できる。
【００１８】
したがって、このシングルパッケージ化システムは、パッケージ名の置き換えと名前スコープの変更とが行われたプログラムに対して、電子署名を行う電子署名手段をさらに備えた構成とすることができる。
【００１９】
さらに、このシングルパッケージ化システムは、クラス名及びクラス中の内部化可能なデータにおける名前スコープの名前リストを作成する名前リスト作成手段と、この名前リスト作成手段にて作成された名前リスト中において、パッケージ名置き換え手段によるパッケージ名の置き換えによって、同一となるクラス名を検出し、このクラス名の重複を回避するようにこの名前リストにおけるクラス名を変更する名前衝突回避手段とをさらに備え、名前スコープ変更手段は、この名前リストを参照して名前スコープを変更し、かつクラス名を衝突の回避されたクラス名に変更する構成とすることができる。
このような構成とすれば、シングルパッケージ化前のプログラムにおける異なるパッケージに同一のクラス名を持つクラスが存在している場合にも、このプログラムのシングルパッケージ化を行える点で好ましい。
【００２０】
また、本発明は、Ｊａｖａのプログラムを開発するためのプログラム開発システムにおいて、複数のクラスにて構成されたプログラムに対し、各クラスが属するパッケージのパッケージ名を単一のパッケージ名に置き換えるパッケージ名置き換え手段と、前記クラス中の、このプログラムの外部から参照されない内部化可能なデータの名前スコープを、パッケージスコープに変更する名前スコープ変更手段と、このパッケージ名の置き換えとこの名前スコープの変更が行われたプログラムに対して、電子署名を行う電子署名手段とを備えたことを特徴としている。
このような構成とすれば、Ｊａｖａによるプログラム開発の最終段階において、作成されたプログラムをシングルパッケージ化して電子署名を施すことができる点で好ましい。
【００２１】
ここで、クラス名及びクラス中の内部化可能なデータにおける名前スコープの名前リストを作成する名前リスト作成手段と、この名前リスト作成手段にて作成された名前リスト中において、パッケージ名置き換え手段によるパッケージ名の置き換えによって、同一となるクラス名を検出し、このクラス名の重複を回避するようにこの名前リストにおけるクラス名を変更する名前衝突回避手段とをさらに備え、名前スコープ変更手段は、この名前リストを参照して名前スコープを変更し、かつクラス名を衝突の回避されたクラス名に変更することとしている。
このような構成とすれば、シングルパッケージ化前のプログラムにおける異なるパッケージに同一のクラス名を持つクラスが存在している場合にも、このプログラムのシングルパッケージ化を行える点で好ましい。
【００２２】
また、本発明によれば、プログラムに対して身元情報を付加する、次のような身元情報付加システムを実現することができる。すなわち、一定の参照範囲を設定した場合にこの参照範囲内のみでの相互参照を認めるパッケージの概念を持ち、各々所定の当該パッケージに属する複数のクラスにて構成されたアプリケーションプログラムを入力する入力手段と、この入力手段にて入力されたこのアプリケーションプログラムにおける各クラスが属するパッケージのパッケージ名を単一のパッケージ名に置き換えるパッケージ名置き換え手段と、前記クラス中の、このアプリケーションプログラムの外部から参照されない内部化可能なデータにおける属性を、同一パッケージ内からの参照を受け付けるように変更する属性変更手段と、このパッケージ名の置き換えとこのデータ属性の変更とが行われたアプリケーションプログラムに対して、アクセス要求者の身元を特定する身元情報を付加してこの身元情報に基づくアクセス権限を取得させる身元情報付加手段と、この身元情報を付加されたアプリケーションプログラムを出力する出力手段とを備える。
このような構成とすれば、作成されたアプリケーションプログラムに対してアクセス権限を取得するための身元情報の付加を行う際に、このアプリケーションプログラムをシングルパッケージ化することができる点で好ましい。
【００２３】
ここで、この身元情報付加システムにて付加される身元情報として、電子署名を用いることができる。このようにすれば、既に現存する電子署名に基づいてアクセス権限を取得するアクセス制御システムに本発明を適用することができる点で好ましい。
【００２４】
また、本発明は、一定の参照範囲を設定した場合にこの参照範囲内のみでの相互参照を認めるパッケージの概念を持つオブジェクト指向プログラミング言語で記述されたプログラムを対象として、コンピュータに当該プログラムを編集させる編集プログラムにおいて、各々所定のパッケージに属する複数のクラスにて構成されたアプリケーションプログラムに対し、各クラスが属するパッケージのパッケージ名を単一のパッケージ名に置き換える処理と、前記クラス中の、このアプリケーションプログラムの外部から参照されない内部化可能なデータにおける属性を、同一パッケージ内からの参照を受け付けるように変更する処理とを含むことを特徴としている。
【００２５】
ここで、このパッケージ名の置き換え処理により、パッケージ名を置き換えた結果、このアプリケーションプログラム中の所定のクラスにおけるクラス名が同一となる場合に、このクラスのクラス名を変更する処理をさらに含むことができる。
これにより、異なるパッケージに同一のクラス名を持つクラスが存在している場合にも、このプログラムのシングルパッケージ化を行える点で好ましい。
【００２６】
また、本発明は、コンピュータに実行させるプログラムをこのコンピュータの入力手段が読取可能に記憶した記憶媒体において、このプログラムは、複数のクラスにて構成されたＪａｖａのアプリケーションプログラム中の、各クラスが属するパッケージのパッケージ名を単一のパッケージ名に置き換える処理と、前記クラス中の、このアプリケーションプログラムの外部から参照されない内部化可能なデータの名前スコープを、パッケージスコープに変更する処理とをこのコンピュータに実行させることを特徴としている。
このような構成とすれば、このプログラムをインストールした全てのコンピュータにおいて、Ｊａｖａのプログラムのシングルパッケージ化を行うことができる点で好ましい。
【００２７】
ここで、このパッケージ名の置き換え処理により、パッケージ名を置き換えた結果、このアプリケーションプログラム中の所定のクラスにおけるクラス名が同一となる場合に、このクラスのクラス名を変更する処理をさらに含むこととすることができる。
【００２８】
また、本発明は、コンピュータに、複数のクラスにて構成されたＪａｖａのアプリケーションプログラム中の、各クラスが属するパッケージのパッケージ名を単一のパッケージ名に置き換える処理と、前記クラス中の、このアプリケーションプログラムの外部から参照されない内部化可能なデータの名前スコープを、パッケージスコープに変更する処理とを実行させるプログラムを記憶する記憶手段と、この記憶手段からこのプログラムを読み出してこのプログラムを送信する送信手段とを備えたことを特徴としている。
このような構成とすることにより、このプログラムをダウンロードした全てのコンピュータにおいて、Ｊａｖａのプログラムのシングルパッケージ化を行うことができる点で好ましい。
【００２９】
ここで、このパッケージ名の置き換え処理により、パッケージ名を置き換えた結果、このアプリケーションプログラム中の所定のクラスにおけるクラス名が同一となる場合に、このクラスのクラス名を変更する処理をさらに含むこととすることができる。
【００３０】
【発明の実施の形態】
以下、添付図面に示す実施の形態に基づいてこの発明を詳細に説明する。
本発明によるプログラムのシングルパッケージ化は、次の三つの条件を満たすオブジェクト指向のプログラミング言語に対して実施することができる。すなわち、パッケージの概念を持っていること、アクセス要求者の身元を特定する情報に基づいてアクセス権限を取得するアクセス制御システムを持っていること、一つのパッケージに対するアクセス権限の取得者を一つに限定する原則を遵守することである。
【００３１】
ここで、パッケージとは、他のプログラムから参照できる範囲（ｖｉｓｉｂｉｌｉｔｙ）を定義する概念である。パッケージと宣言されたフィールドやメソッドは、当該フィールドやメソッドの置かれたパッケージ内からでなければ参照することができないこととする。ただし、ここで要求されるのは、アクセス権限を制御する機能であって、ここで述べたパッケージは、特定のプログラムにおける特定のフォーマットを指すものではない。したがって、実質的に上述した他のプログラムからの参照範囲を定義する機能を持つものであれば、その書式などは問わない。
【００３２】
また、アクセス要求者の身元を特定する情報としては、例えば、公開鍵暗号方式を応用したアクセス制御方式である電子署名を用いることができる。すなわち、電子署名に基づいてアクセス権限を取得するアクセス制御システムを持つことは、上記の条件を満たす。
【００３３】
さらにまた、一つのパッケージに対するアクセス権限の取得者を一つに限定するとは、例えば、電子署名を用いたアクセス制御を行うシステムでは、一つのパッケージに対する署名を一つに制限するということである。すなわち、所定のプログラムに対して署名がなされている場合は、署名されていない他のプログラムが当該署名されたプログラムと同一のパッケージに参加（アクセス）することを拒絶することを意味する。
【００３４】
このような条件を満足するプログラミング言語として、Ｊａｖａ １．２．２がある。そこで、本実施の形態では、Ｊａｖａ １．２．２を対象として本発明を適用した場合について説明する。以下、上述したパッケージも、Ｊａｖａにおける名前スコープの一つとしてのｐａｃｋａｇｅスコープを意味するものとする。ただし、本発明は、上記の条件を実質的に満足する全てのプログラミング言語に対して適用可能であることは言うまでもない。
【００３５】
図１は、本実施の形態におけるプログラムのシングルパッケージ化の方法を説明するフローチャートである。
図１を参照すると、本実施の形態によれば、まず、シングルパッケージ化の対象であるプログラム中の全てのパッケージ名を、単一のパッケージ名で置き換える（ステップ１０１）。例えば、所定のアプリケーションプログラムＡが、複数（ｋ個）のクラスとして開発され、Ｐ１、Ｐ２、…Ｐｋというパッケージに属しているものとする。この場合、これらのパッケージ名を単一のパッケージ名Ｐ０で置き換える。
【００３６】
また、当該プログラム中の全ての内部化可能な名前スコープをｐａｃｋａｇｅスコープで置き換える（ステップ１０２）。ここで、内部化可能な名前スコープとは、当該名前を持つフィールドやメソッドが当該プログラムの外部から参照されていないものであることを言う。上記プログラムＡの例では、パッケージＰ１、Ｐ２、…Ｐｋの各クラスが作成された時点で、パッケージ間あるいは他のプログラム（例えばシステムクラス）とのインタラクションのために、各パッケージには、ｐｕｂｌｉｃやｐｒｏｔｅｃｔｅｄな名前がいくつかある（これらを外部名と呼ぶことにする）。これらのうちで、当該プログラムＡの外部から参照されていないもの全てをｐａｃｋａｇｅスコープで置き換える。
なお、ステップ１０１、１０２の処理は、いずれを先に行っても良いし、並列に行っても良い。
【００３７】
次に、パッケージ名が置き換えられたことによってクラス名の衝突が発生したかどうかを調べ、衝突が発生したならば、当該クラス名を変更して当該衝突を回避する（ステップ１０３、１０４）。ここで、クラス名が衝突するとは、本来複数のパッケージにおいて別個に付されていたクラス名が、パッケージ名が置き換えられたことによって、同一の名前になって重複してしまうことである。例えば、シングルパッケージ化を行う前の２つのパッケージＰｉ、Ｐｊにおいて、名前Ｃを持つクラスがそれぞれ存在するとする（例えば、Ｐｉ．ＣとＰｊ．Ｃ）。この場合、パッケージ名を共通にすることによって、二つのクラス名が衝突してしまう（例えば、パッケージ名をＰ０とした場合、いずれのクラス名もＰ０．Ｃとなってしまう）。そこで、クラス名の衝突を回避するように名前の付け替えを行う。
【００３８】
クラス名の付け替え方法としては、種々の方法が考えられるが、ここでは、機械的な処理で実現できる次の方法を例示する。
まず、プログラムＡの中で、どのクラス名にも現れない文字（または文字列）を一つ選んでおき、これをαとする。このようなαが有限のプログラムで選べることは自明である。そして、Ｐｉ．ＣとＰｊ．Ｃの二つのクラスには、以下のようなクラス名を割り当てる。ただし、以下の説明において、「＋」は文字列の連結を表わし、ｒｅｐｌａｃｅ＿ｄｏｔ（β）は、文字列βの中のドット（．）を、下線（＿）に置き換えた文字列を表わす。
パッケージＰｉ中のクラスＣ（Ｐｉ．Ｃ）＆ｒａｒｒ；
クラス名α＋”＿”＋ｒｅｐｌａｃｅ＿ｄｏｔ（Ｐｉ）＋”＿”＋Ｃ
パッケージＰｊ中のクラスＣ（Ｐｊ．Ｃ）＆ｒａｒｒ；
クラス名α＋”＿”＋ｒｅｐｌａｃｅ＿ｄｏｔ（Ｐｊ）＋”＿”＋Ｃ
このようにして、新しいクラス名には、元のパッケージ名で用いられていた文字列とどのクラス名にも現れない文字とが当てられるため、名前が異なることとなり、衝突が回避される。
【００３９】
なお、上述したクラス名の変更方法は、一例に過ぎない。上記の例では元のパッケージ名におけるドットを下線に置き換えたが、他のどのような規則に基づく変更であってもかまわない。また、元のパッケージ名で用いられた文字列を用いるほか、連続番号を用いてクラス名を生成するなどの方法を用いることもできる。さらに、パッケージ名を置き換えたことによってクラス名の衝突が発生することを防ぐためには、上記のように衝突するクラス名を検出して当該クラス名を変更する他に、プログラム中の全てのクラスに対して、連続番号などを用いた重複のないクラス名を生成して付する用にしても良い。この場合、ステップ１０３の判断処理は不要となり、ステップ１０４において全てのクラスのクラス名を変更することとなる。
【００４０】
最後に、以上のようにして単一のパッケージ名で括られた当該プログラムに対して電子署名を行う（ステップ１０５）。電子署名は、プログラムをシングルパッケージ化する処理とは別個の処理であるが、本実施の形態におけるプログラムのシングルパッケージ化をセキュリティー手段として実効あらしめるために、必要不可欠な処理である。
すなわち、プログラムをシングルパッケージ化したのみでは、他のプログラムが当該プログラムと同一の名前のパッケージを宣言することによって当該プログラムに参加するＰａｃｋａｇｅ Ｊｏｉｎｉｎｇ Ａｔｔａｃｋを防止することができない。そこで、シングルパッケージ化によりパッケージ間相互の参照だけのために設定された外部名をｐａｃｋａｇｅスコープで置き換え、同一パッケージ以外からの参照ができないようにした上で、電子署名を行い、一つのパッケージにおける署名者を一人だけとする１パッケージ１署名者の原則に基づいてＰａｃｋａｇｅ Ｊｏｉｎｉｎｇ Ａｔｔａｃｋを防止する。これにより、パッケージ間相互の参照だけのために設定された外部名に関しては、外部からのアクセスを拒絶できることとなる。
【００４１】
図２は、上述したプログラムのシングルパッケージ化の処理を実行するシステムの構成例を説明する図である。このようなシステムは、ＪＤＫ（Ｊａｖａ Ｄｅｖｅｌｏｐｅｒｓ Ｋｉｔ）に組み込まれたり、生成されたアプリケーションプログラムに署名する電子署名システムの機能として設けられたりすることにより、実現される。
図２において、符号２１は第１の入力手段であり、複数のクラスからなるプログラムと当該プログラムのｍａｎｉｆｅｓｔを入力する。符号２２は名前リスト作成手段であり、入力したプログラムにおける全てのクラス名及び内部化可能な名前スコープの名前リストを作成する。符号２３は名前衝突回避手段であり、名前リスト作成手段２２によって作成された名前リスト中のクラス名を、衝突を回避するための名前に書き換える。符号２４は、名前リスト作成手段２２により作成され、名前衝突回避手段２３により名前の書き換えが行われた名前リストである。符号２５は第２の入力手段であり、再度当該プログラムを入力する。符号２６は名前置き換え手段であり、名前リスト２４を参照して当該プログラム中の内部化可能な名前スコープをｐａｃｋａｇｅスコープに置き換える。また、名前置き換え手段２６の処理において、当該プログラムを構成する各クラスのパッケージ名が単一のパッケージ名に変更される。この名前の置き換えによって当該プログラムのシングルパッケージ化が実行される。符号２７は出力手段であり、名前置き換え手段２６の処理によってシングルパッケージ化されたプログラム（Ｐ０）を出力する。符号２８は電子署名手段であり、出力されたプログラム（Ｐ０）に対して署名する。
これらの各構成要素は、上述したＪＤＫや電子署名システムを実装したコンピュータにおいて、プログラム制御されたＣＰＵ、ＲＡＭなどの内部メモリ、ハードディスクなどの外部記憶装置などを用いて実現される。
【００４２】
図２を参照して本実施の形態によるプログラムのシングルパッケージ化の処理の流れを説明する。
図２に示すシステムによる処理は、名前リスト２４を作成する処理と、作成された名前リスト２４に基づいてプログラム中の必要な名前を置き換える処理の二つの流れからなる。名前リスト２４を作成する処理では、まず、第１の入力手段２１が、処理対象である複数のクラスからなるプログラムと当該プログラムのｍａｎｉｆｅｓｔとを入力する。そして、名前リスト作成手段２２が、入力されたプログラム中の全てのクラス名及び内部化可能な全ての名前スコープを抽出して名前リスト２４を作成する。次に、名前衝突回避手段２３が、名前リスト２４の中から、パッケージ名を共通にした場合に衝突が発生するクラス名を検出する。そして、検出した名前を、衝突を回避するための名前に書き換える。ここで書き換えられる新しい名前は、上述したように、元のパッケージ名で用いられた文字列を用いる方法や、連続番号を用いる方法など種々の方法により生成することができる。
【００４３】
次に、第２の入力手段２５が、再度処理対象であるプログラムを読み込む。そして、名前置き換え手段２６が、名前リスト２４を参照して、入力されたプログラム中の内部化可能な名前スコープをｐａｃｋａｇｅスコープに置き換える。また、当該プログラムを構成する各クラスのパッケージ名を単一のパッケージ名に変更する。名前リスト２４に登録されているクラス名は、名前衝突回避手段２３によりパッケージ名を統一しても重複することがないように書き換えられているため、パッケージ名を変更してもクラス名の衝突は起こらない。この後、このようにしてシングルパッケージ化されたプログラムを出力手段２７が出力する。出力されたプログラムは、電子署名手段２８にて署名される。
以上のように、名前リスト２４を作成する処理と、プログラムの名前を実際に置き換える処理とに分けて実行するのは、プログラム中の名前の置き換えが必要な名前スコープを検出するために、一旦プログラム全体を見渡す必要があるためである。したがって、衝突が発生する名前スコープに限らず、全てのクラス名を変更する手法を取る場合は、名前リスト２４を作成する処理を行う必要はなく、第１の入力手段２１、名前リスト作成手段２２及び名前衝突回避手段２３を省略することができる。
【００４４】
次に、具体的なプログラムに対するシングルパッケージ化の例を示す。
図３は、本実施の形態によりプログラムがシングルパッケージ化される様子を示す図である。図４乃至図６は図３のシングルパッケージ化される前のプログラムにおける各クラスの内容を示す図、図７乃至図９はシングルパッケージ化された後の図４乃至図６に対応する各クラスの内容を示す図である。以下、これらの図を参照して説明する。
【００４５】
図３に示す例では、三つのクラスＸ、Ｙ、Ｘからなるアプリケーションプログラムをシングルパッケージ化する。処理対象である三つのクラスは、それぞれ、独立したパッケージｃｏｍ．ｉｂｍ．ｐ１、ｃｏｍ．ｉｂｍ．ｐ２、ｃｏｍ．ｉｂｍ．ｐ３に属している。
図４を参照すると、パッケージｃｏｍ．ｉｂｍ．ｐ１に属するクラスＸ（図４ではパッケージ名を付してｃｏｍ．ｉｂｍ．ｐ１．Ｘと表記）には、ｐｕｂｌｉｃスコープのメソッドが２個存在する。一つはパッケージｃｏｍ．ｉｂｍ．ｐ２への呼び出しメソッドであり、もう一つはシステムクラスから呼ばれるメソッドである。このうち、パッケージｃｏｍ．ｉｂｍ．ｐ２への呼び出しメソッドは内部化可能である。同様に、図５を参照すると、パッケージｃｏｍ．ｉｂｍ．ｐ２に属するクラスＹ（図５ではパッケージ名を付してｃｏｍ．ｉｂｍ．ｐ２．Ｙと表記）には、パッケージｃｏｍ．ｉｂｍ．ｐ３への呼び出しメソッドが存在する。また、図６を参照すると、パッケージｃｏｍ．ｉｂｍ．ｐ３に属するクラスＸ（図６ではパッケージ名を付してｃｏｍ．ｉｂｍ．ｐ３．Ｘと表記）には、パッケージｃｏｍ．ｉｂｍ．ｐ１への呼び出しメソッドが存在する。これらのメソッドは、いずれもｐｕｂｌｉｃスコープであり、かつ内部化可能である。
また、パッケージｃｏｍ．ｉｂｍ．ｐ１に属するクラスＸとパッケージｃｏｍ．ｉｂｍ．ｐ３に属するクラスＸとは、パッケージ名が共通となった場合にクラス名が重複することとなる。
【００４６】
以上のようなプログラムのシングルパッケージ化を行う。新たなパッケージ名はｃｏｍ．ｉｂｍ．ｐ０とする。
まず、上述したように、パッケージｃｏｍ．ｉｂｍ．ｐ１に属するクラスＸとパッケージｃｏｍ．ｉｂｍ．ｐ３に属するクラスＸのクラス名が衝突するので、衝突を回避するためにクラス名を変更する。ここで、どのクラス名にも現れない文字αとして、α＝”Ｆｏｏ”を用いる。これにより、パッケージｃｏｍ．ｉｂｍ．ｐ１のクラスＸのクラス名は、Ｆｏｏ＿ｃｏｍ＿ｉｂｍ＿ｐ１＿Ｘとなり、パッケージｃｏｍ．ｉｂｍ．ｐ３のクラスＸのクラス名は、Ｆｏｏ＿ｃｏｍ＿ｉｂｍ＿ｐ３＿Ｘとなって、衝突が回避された。
【００４７】
次に、内部化可能なｐｕｂｌｉｃスコープをｐａｃｋａｇｅスコープに変更する。図７を参照すると、図４におけるパッケージｃｏｍ．ｉｂｍ．ｐ２への呼び出しメソッドを含むｐｕｂｌｉｃスコープがｐａｃｋａｇｅスコープに変更され、呼び出しメソッドは同一パッケージのクラスＹへの呼び出しメソッドに変更されている。システムクラスから呼ばれるメソッドについては、内部化可能でないため、変更されていない。同様に、図８を参照すると、図５におけるパッケージｃｏｍ．ｉｂｍ．ｐ３への呼び出しメソッドを含むｐｕｂｌｉｃスコープがｐａｃｋａｇｅスコープに変更されている。また、図９を参照すると、図６におけるパッケージｃｏｍ．ｉｂｍ．ｐ１への呼び出しメソッドを含むｐｕｂｌｉｃスコープがｐａｃｋａｇｅスコープに変更されている。
【００４８】
以上のようにして、内部化可能な名前スコープが全てｐａｃｋａｇｅスコープに変更され、クラス名の衝突も回避されたので、当該プログラムのシングルパッケージ化が完了する。
上記の例では、シングルパッケージ化がソースファイルに対して行われる場合を前提にして説明した。上述のように、この処理は、クラス名、フィールド名、メソッド名の書き換えだけによって行われる。したがって、同じ処理をコンパイル済みのｃｌａｓｓファイルに適用しようとした場合、変更される部分は、Ｃｏｎｓｔａｎｔ Ｐｏｏｌだけであり、Ｂｙｔｅ Ｃｏｄｅの部分は変更の影響を受けない。すなわち、再コンパイルは不要である。このため、ソースコードを持たない他社製のライブラリを含むアプリケーションプログラムに対しても、全く同様にシングルパッケージ化を行なうことが可能であり、ほとんどの外部名を内部化することができることとなる。
【００４９】
【発明の効果】
以上説明したように、本発明によれば、名前スコープを用いたアクセス制限を有効に活用して、保護されるべきリソースを持つプログラムが不正なプログラムに呼ばれることを防止できるようにＪａｖａプログラムを編集することができる。
【００５０】
また、本発明によれば、Ｊａｖａにおけるｐａｃｋａｇｅスコープと同様の概念に基づくアクセス制御を実現するプログラミング言語において、保護されるべきリソースを持つプログラムが不正なプログラムに呼ばれることを防止できるようにプログラムを編集することができる。
【図面の簡単な説明】
【図１】本実施の形態におけるプログラムのシングルパッケージ化の方法を説明するフローチャートである。
【図２】本実施の形態におけるプログラムのシングルパッケージ化の処理を実行するシステムの構成例を説明する図である。
【図３】本実施の形態によりプログラムがシングルパッケージ化される様子を示す図である。
【図４】図３のシングルパッケージ化される前のプログラムにおけるクラスの内容を示す図であり、クラスｃｏｍ．ｉｂｍ．ｐ１．Ｘの内容を示す図である。
【図５】図３のシングルパッケージ化される前のプログラムにおけるクラスの内容を示す図であり、クラスｃｏｍ．ｉｂｍ．ｐ２．Ｙの内容を示す図である。
【図６】図３のシングルパッケージ化される前のプログラムにおけるクラスの内容を示す図であり、クラスｃｏｍ．ｉｂｍ．ｐ３．Ｘの内容を示す図である。
【図７】図３のシングルパッケージ化された後のプログラムにおけるクラスの内容を示す図であり、クラスｃｏｍ．ｉｂｍ．ｐ０．Ｆｏｏ＿ｃｏｍ＿ｉｂｍ＿ｐ１＿Ｘの内容を示す図である。
【図８】図３のシングルパッケージ化された後のプログラムにおけるクラスの内容を示す図であり、クラスｃｏｍ．ｉｂｍ．ｐ０．Ｙの内容を示す図である。
【図９】図３のシングルパッケージ化された後のプログラムにおけるクラスの内容を示す図であり、クラスｃｏｍ．ｉｂｍ．ｐ０．Ｆｏｏ＿ｃｏｍ＿ｉｂｍ＿ｐ３＿Ｘの内容を示す図である。
【符号の説明】
２１…第１の入力手段、２２…名前リスト作成手段、２３…名前衝突回避手段、２４…名前リスト、２５…第２の入力手段、２６…名前置き換え手段、２７…出力手段、２８…電子署名手段
【発明の属する技術分野】
本発明は、保護されるべきリソースを持つプログラムが不正なプログラムに呼ばれることを防止できるようにプログラムの編集を行うプログラム編集方法に関する。
【０００２】
【従来の技術】
Ｊａｖａは、一つのＪａｖａＶＭの中に、複数のプログラムが実行時にロードされて実行されるというユニークなプログラミング環境を持つ。このため、保護されるべきリソースを持つプログラム（以下、プログラムＡと称す）が、不正なプログラム（以下、プログラムＭと称す）に呼ばれることを防ぐためのメカニズムが必要である。保護することが必要なプログラムＡとしては、ローカルファイルなどをアクセスするシステムクラス群（ＦｉｌｅＩｎｐｕｔＳｔｒｅａｍ等）や、ユーザのプライバシー情報を管理しているクラス、署名されたことによってシステムクラスを呼ぶ権限を保持しているクラスなどがある。
【０００３】
プログラムの実行時にプログラムＡをプログラムＭから見えないようにする手段（動的なアクセス制限）としては、通常、次の二つの方法が使われる。
一つは、プログラムＡとプログラムＭが異なるアプリケーションである場合に、クラスローダを分離する方法である。Ｊａｖａのコードは全てクラス単位の ．ｃｌａｓｓ ファイルによって構成されており、クラスが必要になるとクラスローダ（Ｃｌａｓｓ Ｌｏａｄｅｒ）により動的にロードされる。クラスローダは、当該クラスのプリンシパル（Ｐｒｉｎｃｉｐａｌ）を見て、ロードして良いかどうかを決定する。
他の一つは、プログラムＡがシステムクラスである場合に、スタックインスペクションにより、プログラムＭのプリンシパルをテストする方法である。
【０００４】
しかしながら、クラスローダを分離する方法では、プログラムＡとプログラムＭとを同じウェブページ（ディレクトリ）に置いたならば、プログラムＭがプログラムＡのクラスローダを使用することができるため、アクセス制限を突破できてしまう。
また、スタックインスペクションを行う方法では、署名付きのプログラムＡがアクセスに必要な権限を取得した場合や、ローカルファイルからロードされたクラスに対しては、スタックインスペクションが適用されない。
【０００５】
プログラムの実行に先立ってプログラムＡを保護する手段（静的なアクセス制限）としては、名前スコープを用いてアクセスを制限する方法がある。名前スコープとは、フィールドやメソッドを参照できる範囲を定義するために、当該フィールドやメソッドにおいて宣言されるものである。すなわち、宣言された名前に応じて、他のプログラムからの参照（アクセス）を制御することができる。例えば、ｐｒｉｖａｔｅスコープは他のプログラムから直接参照することは一切できないし、反対に、ｐｕｂｌｉｃスコープは他のプログラムから自由に参照することができる。また、ｐａｃｋａｇｅスコープは、当該ｐａｃｋａｇｅスコープの宣言されたフィールドやメソッドと同一のパッケージ内からでなければ参照することができない。
【０００６】
名前スコープを用いる場合、プライベートと宣言されたフィールドやメソッドは、他のプログラムから直接アクセスされることがないことが保証されている。したがって、プログラムＡに関してプライベートと宣言することにより、プログラムＭからのアクセスを制限することができる。
しかしながら、プログラムが複数のクラスからなり、それらのクラス間にインタラクションが存在する以上、全てのフィールドやメソッドをプライベートと宣言することはできず、いくつかのフィールド及びメソッドは、ｐａｃｋａｇｅ以上（ｐａｃｋａｇｅ、ｐｒｏｔｅｃｔｅｄ、ｐｕｂｌｉｃのいずれか）のスコープを持たざるを得ない。
【０００７】
ｐａｃｋａｇｅスコープは、ＪＤＫ １．２．１までのＪａｖａプログラムでは、任意のプログラムＭが、自由に自分のパッケージを宣言することができる（ただし、パッケージ内だけで有効な名前の範囲に限られる）。このため、プログラムＭがプログラムＡと同じ名前のパッケージを宣言することによって、当該プログラムＡのパッケージに参加してしまう、いわゆる「Ｐａｃｋａｇｅ Ｊｏｉｎｉｎｇ Ａｔｔａｃｋ」が可能であった。すなわち、パッケージは、誤って名前が衝突してしまうことは防げるが、セキュリティ上のアクセスコントロールのメカニズムとしては不十分だった。
【０００８】
ＪＤＫ １．２．２では、一つのパッケージにおける署名者をただ一人だけとする１パッケージ１署名者の原則（Ｏｎｅ−Ｐａｃｋａｇｅ−Ｏｎｅ−Ｐｒｉｎｃｉｐａｌ Ｐｏｌｉｃｙ）が取りいれられたため、プログラムＡが署名されている限り、署名されていないプログラムＭがプログラムＡと同一のパッケージに参加することはできなくなった。従って、署名されたプログラムでは、パッケージと宣言されたフィールドやメソッドは不正なプログラムにアクセスされることはなくなった。このため、Ｐａｃｋａｇｅスコープは、セキュリティ上のアクセス制限の機能を果たせることとなった。
【０００９】
【発明が解決しようとする課題】
上述したように、Ｊａｖａにおいて、保護されるべきリソースを持つプログラムＡが不正なプログラムＭに呼ばれることを防ぐためのメカニズムとしては、名前スコープを用いた静的なアクセス制限手段を用いることが有効である。しかし、セキュリティ上のアクセス制限を実現するのは、プログラムＡに関してプライベートと宣言した場合か、署名されたプログラムＡに関してパッケージと宣言した場合に限られ、ｐｒｏｔｅｃｔｅｄやｐｕｂｌｉｃのスコープを持つクラス、フィールド及びメソッドについては、依然としてセキュリティ上の保護はない。
【００１０】
しかしながら、ある程度以上の大きなＪａｖａプログラムは、複数のパッケージからなることが多く、パッケージ間のインタラクションのために、いくつかのクラス、フィールドまたはメソッドをパブリックにせざるを得ない。したがって、そのようなプログラムでは、ｐｒｉｖａｔｅスコープやｐａｃｋａｇｅスコープを用いたアクセス制限を有効に活用することができない。
【００１１】
そこで本発明は、名前スコープを用いたアクセス制限を有効に活用して、保護されるべきリソースを持つプログラムが不正なプログラムに呼ばれることを防止できるようにＪａｖａプログラムを編集することを目的とする。
【００１２】
また、本発明は、Ｊａｖａにおけるｐａｃｋａｇｅスコープと同様の概念に基づくアクセス制御を実現するプログラミング言語において、保護されるべきリソースを持つプログラムが不正なプログラムに呼ばれることを防止できるようにプログラムを編集することを目的とする。
【００１３】
【課題を解決するための手段】
かかる目的のもと、本発明は、オブジェクト指向プログラミング言語で記述されたプログラムの編集方法において、このオブジェクト指向プログラミング言語は、一定の参照範囲を設定した場合にこの参照範囲内のみでの相互参照を認めるパッケージの概念を持っていること、及びアクセス要求者の身元を特定する身元情報に基づいてアクセス権限を取得するアクセス制御システムを持っていること、という二つの条件を満足する言語であり、複数のクラスにて構成されたアプリケーションプログラムに対し、各クラスに付されたパッケージ名を単一のパッケージ名に置き換えるステップと、前記クラス中の、アプリケーションプログラムの外部から参照されない内部化可能なデータにおける属性を、同一パッケージ内からの参照を受け付けるように変更するステップと、このパッケージ名の置き換えステップとこのデータ属性の変更ステップとを経たアプリケーションプログラムに対して、アクセス要求者の身元を特定する身元情報に基づくアクセス権限を取得させるステップとを含むことを特徴としている。
このような構成とすれば、システムクラスとの間で参照を行うような内部化可能でないメソッド、変数などを除き、同一パッケージ内からの参照を受け付けるように変更されたデータは、このアプリケーションプログラムと同一のアクセス権限を取得したプログラム以外からのアクセスは受け付けなくなる。そこで、一つのパッケージに対するアクセス権限の取得者を一つに限定する原則を採用すれば、このデータに対して、このアプリケーションプログラムの外部からのアクセスが一切できなくなるため、外部からの不正なアクセスを防止できる。
【００１４】
ここで、パッケージ名の置き換えステップによりパッケージ名を置き換えた結果、アプリケーションプログラム中の所定のクラスにおけるクラス名が同一となる場合に、このクラスのクラス名を変更するステップをさらに含むこととすることができる。
このような構成とすれば、異なるパッケージに同一のクラス名を持つクラスが存在している場合にも、このアプリケーションプログラムのシングルパッケージ化を行える点で好ましい。
【００１５】
このクラス名変更ステップは、所定のクラスのクラス名を変更するために、パッケージ名の置き換えステップによる変更前のこのクラスが属するパッケージ名に用いられた文字列を用いて新たなクラス名を生成することができる。
このような構成とすれば、衝突を回避する新たなクラス名を機械的に生成できる点で好ましい。パッケージ名に用いられた文字列を用いて新たなクラス名を生成する具体的な手法としては、例えば、パッケージ名のドットをアンダースコア（下線）に置き換えてそのまま用いるといった方法を採ることができる。また、確実に衝突を回避するために、どのクラス名にも現れない文字列を新たなクラス名に追加するようにしても良い。
【００１６】
またここで、パッケージ名を変更した際に重複するクラス名が存在するかどうかを検出せず、機械的に、このアプリケーションプログラム中のクラスのクラス名を、相互に重複しない固有のクラス名に変更するステップをさらに含むこととすることができる。
クラス名を変更する具体的な手法としては、例えば、各クラスに連続番号を振るといった方法を採ることができる。
【００１７】
また、本発明によれば、Ｊａｖａのプログラムをシングルパッケージ化する、次のようなシングルパッケージ化システムを実現することができる。すなわち、複数のクラスにて構成されたＪａｖａのプログラムを入力する入力手段と、この入力手段にて入力されたプログラム中の、各クラスが属するパッケージのパッケージ名を単一のパッケージ名に置き換えるパッケージ名置き換え手段と、前記クラス中の、このプログラムの外部から参照されない内部化可能なデータの名前スコープを、パッケージスコープに変更する名前スコープ変更手段と、このパッケージ名の置き換えとこの名前スコープの変更とが行われたプログラムを出力する出力手段とを備える。
このような構成とすれば、このプログラム中のメッセージや変数のうちで、このプログラムの中でのみ参照が行われるものに関しては、このプログラム全体を含む単一のパッケージの外部からのアクセスを受け付けなくなる。したがって、このプログラムに電子署名を施し、一つのパッケージにおける署名者をただ一人だけとする１パッケージ１署名者の原則を併せて採用することにより、このメッセージや変数に対して、このプログラムの外部からのアクセスが一切できなくなるため、外部からの不正なアクセスを防止できる。
【００１８】
したがって、このシングルパッケージ化システムは、パッケージ名の置き換えと名前スコープの変更とが行われたプログラムに対して、電子署名を行う電子署名手段をさらに備えた構成とすることができる。
【００１９】
さらに、このシングルパッケージ化システムは、クラス名及びクラス中の内部化可能なデータにおける名前スコープの名前リストを作成する名前リスト作成手段と、この名前リスト作成手段にて作成された名前リスト中において、パッケージ名置き換え手段によるパッケージ名の置き換えによって、同一となるクラス名を検出し、このクラス名の重複を回避するようにこの名前リストにおけるクラス名を変更する名前衝突回避手段とをさらに備え、名前スコープ変更手段は、この名前リストを参照して名前スコープを変更し、かつクラス名を衝突の回避されたクラス名に変更する構成とすることができる。
このような構成とすれば、シングルパッケージ化前のプログラムにおける異なるパッケージに同一のクラス名を持つクラスが存在している場合にも、このプログラムのシングルパッケージ化を行える点で好ましい。
【００２０】
また、本発明は、Ｊａｖａのプログラムを開発するためのプログラム開発システムにおいて、複数のクラスにて構成されたプログラムに対し、各クラスが属するパッケージのパッケージ名を単一のパッケージ名に置き換えるパッケージ名置き換え手段と、前記クラス中の、このプログラムの外部から参照されない内部化可能なデータの名前スコープを、パッケージスコープに変更する名前スコープ変更手段と、このパッケージ名の置き換えとこの名前スコープの変更が行われたプログラムに対して、電子署名を行う電子署名手段とを備えたことを特徴としている。
このような構成とすれば、Ｊａｖａによるプログラム開発の最終段階において、作成されたプログラムをシングルパッケージ化して電子署名を施すことができる点で好ましい。
【００２１】
ここで、クラス名及びクラス中の内部化可能なデータにおける名前スコープの名前リストを作成する名前リスト作成手段と、この名前リスト作成手段にて作成された名前リスト中において、パッケージ名置き換え手段によるパッケージ名の置き換えによって、同一となるクラス名を検出し、このクラス名の重複を回避するようにこの名前リストにおけるクラス名を変更する名前衝突回避手段とをさらに備え、名前スコープ変更手段は、この名前リストを参照して名前スコープを変更し、かつクラス名を衝突の回避されたクラス名に変更することとしている。
このような構成とすれば、シングルパッケージ化前のプログラムにおける異なるパッケージに同一のクラス名を持つクラスが存在している場合にも、このプログラムのシングルパッケージ化を行える点で好ましい。
【００２２】
また、本発明によれば、プログラムに対して身元情報を付加する、次のような身元情報付加システムを実現することができる。すなわち、一定の参照範囲を設定した場合にこの参照範囲内のみでの相互参照を認めるパッケージの概念を持ち、各々所定の当該パッケージに属する複数のクラスにて構成されたアプリケーションプログラムを入力する入力手段と、この入力手段にて入力されたこのアプリケーションプログラムにおける各クラスが属するパッケージのパッケージ名を単一のパッケージ名に置き換えるパッケージ名置き換え手段と、前記クラス中の、このアプリケーションプログラムの外部から参照されない内部化可能なデータにおける属性を、同一パッケージ内からの参照を受け付けるように変更する属性変更手段と、このパッケージ名の置き換えとこのデータ属性の変更とが行われたアプリケーションプログラムに対して、アクセス要求者の身元を特定する身元情報を付加してこの身元情報に基づくアクセス権限を取得させる身元情報付加手段と、この身元情報を付加されたアプリケーションプログラムを出力する出力手段とを備える。
このような構成とすれば、作成されたアプリケーションプログラムに対してアクセス権限を取得するための身元情報の付加を行う際に、このアプリケーションプログラムをシングルパッケージ化することができる点で好ましい。
【００２３】
ここで、この身元情報付加システムにて付加される身元情報として、電子署名を用いることができる。このようにすれば、既に現存する電子署名に基づいてアクセス権限を取得するアクセス制御システムに本発明を適用することができる点で好ましい。
【００２４】
また、本発明は、一定の参照範囲を設定した場合にこの参照範囲内のみでの相互参照を認めるパッケージの概念を持つオブジェクト指向プログラミング言語で記述されたプログラムを対象として、コンピュータに当該プログラムを編集させる編集プログラムにおいて、各々所定のパッケージに属する複数のクラスにて構成されたアプリケーションプログラムに対し、各クラスが属するパッケージのパッケージ名を単一のパッケージ名に置き換える処理と、前記クラス中の、このアプリケーションプログラムの外部から参照されない内部化可能なデータにおける属性を、同一パッケージ内からの参照を受け付けるように変更する処理とを含むことを特徴としている。
【００２５】
ここで、このパッケージ名の置き換え処理により、パッケージ名を置き換えた結果、このアプリケーションプログラム中の所定のクラスにおけるクラス名が同一となる場合に、このクラスのクラス名を変更する処理をさらに含むことができる。
これにより、異なるパッケージに同一のクラス名を持つクラスが存在している場合にも、このプログラムのシングルパッケージ化を行える点で好ましい。
【００２６】
また、本発明は、コンピュータに実行させるプログラムをこのコンピュータの入力手段が読取可能に記憶した記憶媒体において、このプログラムは、複数のクラスにて構成されたＪａｖａのアプリケーションプログラム中の、各クラスが属するパッケージのパッケージ名を単一のパッケージ名に置き換える処理と、前記クラス中の、このアプリケーションプログラムの外部から参照されない内部化可能なデータの名前スコープを、パッケージスコープに変更する処理とをこのコンピュータに実行させることを特徴としている。
このような構成とすれば、このプログラムをインストールした全てのコンピュータにおいて、Ｊａｖａのプログラムのシングルパッケージ化を行うことができる点で好ましい。
【００２７】
ここで、このパッケージ名の置き換え処理により、パッケージ名を置き換えた結果、このアプリケーションプログラム中の所定のクラスにおけるクラス名が同一となる場合に、このクラスのクラス名を変更する処理をさらに含むこととすることができる。
【００２８】
また、本発明は、コンピュータに、複数のクラスにて構成されたＪａｖａのアプリケーションプログラム中の、各クラスが属するパッケージのパッケージ名を単一のパッケージ名に置き換える処理と、前記クラス中の、このアプリケーションプログラムの外部から参照されない内部化可能なデータの名前スコープを、パッケージスコープに変更する処理とを実行させるプログラムを記憶する記憶手段と、この記憶手段からこのプログラムを読み出してこのプログラムを送信する送信手段とを備えたことを特徴としている。
このような構成とすることにより、このプログラムをダウンロードした全てのコンピュータにおいて、Ｊａｖａのプログラムのシングルパッケージ化を行うことができる点で好ましい。
【００２９】
ここで、このパッケージ名の置き換え処理により、パッケージ名を置き換えた結果、このアプリケーションプログラム中の所定のクラスにおけるクラス名が同一となる場合に、このクラスのクラス名を変更する処理をさらに含むこととすることができる。
【００３０】
【発明の実施の形態】
以下、添付図面に示す実施の形態に基づいてこの発明を詳細に説明する。
本発明によるプログラムのシングルパッケージ化は、次の三つの条件を満たすオブジェクト指向のプログラミング言語に対して実施することができる。すなわち、パッケージの概念を持っていること、アクセス要求者の身元を特定する情報に基づいてアクセス権限を取得するアクセス制御システムを持っていること、一つのパッケージに対するアクセス権限の取得者を一つに限定する原則を遵守することである。
【００３１】
ここで、パッケージとは、他のプログラムから参照できる範囲（ｖｉｓｉｂｉｌｉｔｙ）を定義する概念である。パッケージと宣言されたフィールドやメソッドは、当該フィールドやメソッドの置かれたパッケージ内からでなければ参照することができないこととする。ただし、ここで要求されるのは、アクセス権限を制御する機能であって、ここで述べたパッケージは、特定のプログラムにおける特定のフォーマットを指すものではない。したがって、実質的に上述した他のプログラムからの参照範囲を定義する機能を持つものであれば、その書式などは問わない。
【００３２】
また、アクセス要求者の身元を特定する情報としては、例えば、公開鍵暗号方式を応用したアクセス制御方式である電子署名を用いることができる。すなわち、電子署名に基づいてアクセス権限を取得するアクセス制御システムを持つことは、上記の条件を満たす。
【００３３】
さらにまた、一つのパッケージに対するアクセス権限の取得者を一つに限定するとは、例えば、電子署名を用いたアクセス制御を行うシステムでは、一つのパッケージに対する署名を一つに制限するということである。すなわち、所定のプログラムに対して署名がなされている場合は、署名されていない他のプログラムが当該署名されたプログラムと同一のパッケージに参加（アクセス）することを拒絶することを意味する。
【００３４】
このような条件を満足するプログラミング言語として、Ｊａｖａ １．２．２がある。そこで、本実施の形態では、Ｊａｖａ １．２．２を対象として本発明を適用した場合について説明する。以下、上述したパッケージも、Ｊａｖａにおける名前スコープの一つとしてのｐａｃｋａｇｅスコープを意味するものとする。ただし、本発明は、上記の条件を実質的に満足する全てのプログラミング言語に対して適用可能であることは言うまでもない。
【００３５】
図１は、本実施の形態におけるプログラムのシングルパッケージ化の方法を説明するフローチャートである。
図１を参照すると、本実施の形態によれば、まず、シングルパッケージ化の対象であるプログラム中の全てのパッケージ名を、単一のパッケージ名で置き換える（ステップ１０１）。例えば、所定のアプリケーションプログラムＡが、複数（ｋ個）のクラスとして開発され、Ｐ１、Ｐ２、…Ｐｋというパッケージに属しているものとする。この場合、これらのパッケージ名を単一のパッケージ名Ｐ０で置き換える。
【００３６】
また、当該プログラム中の全ての内部化可能な名前スコープをｐａｃｋａｇｅスコープで置き換える（ステップ１０２）。ここで、内部化可能な名前スコープとは、当該名前を持つフィールドやメソッドが当該プログラムの外部から参照されていないものであることを言う。上記プログラムＡの例では、パッケージＰ１、Ｐ２、…Ｐｋの各クラスが作成された時点で、パッケージ間あるいは他のプログラム（例えばシステムクラス）とのインタラクションのために、各パッケージには、ｐｕｂｌｉｃやｐｒｏｔｅｃｔｅｄな名前がいくつかある（これらを外部名と呼ぶことにする）。これらのうちで、当該プログラムＡの外部から参照されていないもの全てをｐａｃｋａｇｅスコープで置き換える。
なお、ステップ１０１、１０２の処理は、いずれを先に行っても良いし、並列に行っても良い。
【００３７】
次に、パッケージ名が置き換えられたことによってクラス名の衝突が発生したかどうかを調べ、衝突が発生したならば、当該クラス名を変更して当該衝突を回避する（ステップ１０３、１０４）。ここで、クラス名が衝突するとは、本来複数のパッケージにおいて別個に付されていたクラス名が、パッケージ名が置き換えられたことによって、同一の名前になって重複してしまうことである。例えば、シングルパッケージ化を行う前の２つのパッケージＰｉ、Ｐｊにおいて、名前Ｃを持つクラスがそれぞれ存在するとする（例えば、Ｐｉ．ＣとＰｊ．Ｃ）。この場合、パッケージ名を共通にすることによって、二つのクラス名が衝突してしまう（例えば、パッケージ名をＰ０とした場合、いずれのクラス名もＰ０．Ｃとなってしまう）。そこで、クラス名の衝突を回避するように名前の付け替えを行う。
【００３８】
クラス名の付け替え方法としては、種々の方法が考えられるが、ここでは、機械的な処理で実現できる次の方法を例示する。
まず、プログラムＡの中で、どのクラス名にも現れない文字（または文字列）を一つ選んでおき、これをαとする。このようなαが有限のプログラムで選べることは自明である。そして、Ｐｉ．ＣとＰｊ．Ｃの二つのクラスには、以下のようなクラス名を割り当てる。ただし、以下の説明において、「＋」は文字列の連結を表わし、ｒｅｐｌａｃｅ＿ｄｏｔ（β）は、文字列βの中のドット（．）を、下線（＿）に置き換えた文字列を表わす。
パッケージＰｉ中のクラスＣ（Ｐｉ．Ｃ）＆ｒａｒｒ；
クラス名α＋”＿”＋ｒｅｐｌａｃｅ＿ｄｏｔ（Ｐｉ）＋”＿”＋Ｃ
パッケージＰｊ中のクラスＣ（Ｐｊ．Ｃ）＆ｒａｒｒ；
クラス名α＋”＿”＋ｒｅｐｌａｃｅ＿ｄｏｔ（Ｐｊ）＋”＿”＋Ｃ
このようにして、新しいクラス名には、元のパッケージ名で用いられていた文字列とどのクラス名にも現れない文字とが当てられるため、名前が異なることとなり、衝突が回避される。
【００３９】
なお、上述したクラス名の変更方法は、一例に過ぎない。上記の例では元のパッケージ名におけるドットを下線に置き換えたが、他のどのような規則に基づく変更であってもかまわない。また、元のパッケージ名で用いられた文字列を用いるほか、連続番号を用いてクラス名を生成するなどの方法を用いることもできる。さらに、パッケージ名を置き換えたことによってクラス名の衝突が発生することを防ぐためには、上記のように衝突するクラス名を検出して当該クラス名を変更する他に、プログラム中の全てのクラスに対して、連続番号などを用いた重複のないクラス名を生成して付する用にしても良い。この場合、ステップ１０３の判断処理は不要となり、ステップ１０４において全てのクラスのクラス名を変更することとなる。
【００４０】
最後に、以上のようにして単一のパッケージ名で括られた当該プログラムに対して電子署名を行う（ステップ１０５）。電子署名は、プログラムをシングルパッケージ化する処理とは別個の処理であるが、本実施の形態におけるプログラムのシングルパッケージ化をセキュリティー手段として実効あらしめるために、必要不可欠な処理である。
すなわち、プログラムをシングルパッケージ化したのみでは、他のプログラムが当該プログラムと同一の名前のパッケージを宣言することによって当該プログラムに参加するＰａｃｋａｇｅ Ｊｏｉｎｉｎｇ Ａｔｔａｃｋを防止することができない。そこで、シングルパッケージ化によりパッケージ間相互の参照だけのために設定された外部名をｐａｃｋａｇｅスコープで置き換え、同一パッケージ以外からの参照ができないようにした上で、電子署名を行い、一つのパッケージにおける署名者を一人だけとする１パッケージ１署名者の原則に基づいてＰａｃｋａｇｅ Ｊｏｉｎｉｎｇ Ａｔｔａｃｋを防止する。これにより、パッケージ間相互の参照だけのために設定された外部名に関しては、外部からのアクセスを拒絶できることとなる。
【００４１】
図２は、上述したプログラムのシングルパッケージ化の処理を実行するシステムの構成例を説明する図である。このようなシステムは、ＪＤＫ（Ｊａｖａ Ｄｅｖｅｌｏｐｅｒｓ Ｋｉｔ）に組み込まれたり、生成されたアプリケーションプログラムに署名する電子署名システムの機能として設けられたりすることにより、実現される。
図２において、符号２１は第１の入力手段であり、複数のクラスからなるプログラムと当該プログラムのｍａｎｉｆｅｓｔを入力する。符号２２は名前リスト作成手段であり、入力したプログラムにおける全てのクラス名及び内部化可能な名前スコープの名前リストを作成する。符号２３は名前衝突回避手段であり、名前リスト作成手段２２によって作成された名前リスト中のクラス名を、衝突を回避するための名前に書き換える。符号２４は、名前リスト作成手段２２により作成され、名前衝突回避手段２３により名前の書き換えが行われた名前リストである。符号２５は第２の入力手段であり、再度当該プログラムを入力する。符号２６は名前置き換え手段であり、名前リスト２４を参照して当該プログラム中の内部化可能な名前スコープをｐａｃｋａｇｅスコープに置き換える。また、名前置き換え手段２６の処理において、当該プログラムを構成する各クラスのパッケージ名が単一のパッケージ名に変更される。この名前の置き換えによって当該プログラムのシングルパッケージ化が実行される。符号２７は出力手段であり、名前置き換え手段２６の処理によってシングルパッケージ化されたプログラム（Ｐ０）を出力する。符号２８は電子署名手段であり、出力されたプログラム（Ｐ０）に対して署名する。
これらの各構成要素は、上述したＪＤＫや電子署名システムを実装したコンピュータにおいて、プログラム制御されたＣＰＵ、ＲＡＭなどの内部メモリ、ハードディスクなどの外部記憶装置などを用いて実現される。
【００４２】
図２を参照して本実施の形態によるプログラムのシングルパッケージ化の処理の流れを説明する。
図２に示すシステムによる処理は、名前リスト２４を作成する処理と、作成された名前リスト２４に基づいてプログラム中の必要な名前を置き換える処理の二つの流れからなる。名前リスト２４を作成する処理では、まず、第１の入力手段２１が、処理対象である複数のクラスからなるプログラムと当該プログラムのｍａｎｉｆｅｓｔとを入力する。そして、名前リスト作成手段２２が、入力されたプログラム中の全てのクラス名及び内部化可能な全ての名前スコープを抽出して名前リスト２４を作成する。次に、名前衝突回避手段２３が、名前リスト２４の中から、パッケージ名を共通にした場合に衝突が発生するクラス名を検出する。そして、検出した名前を、衝突を回避するための名前に書き換える。ここで書き換えられる新しい名前は、上述したように、元のパッケージ名で用いられた文字列を用いる方法や、連続番号を用いる方法など種々の方法により生成することができる。
【００４３】
次に、第２の入力手段２５が、再度処理対象であるプログラムを読み込む。そして、名前置き換え手段２６が、名前リスト２４を参照して、入力されたプログラム中の内部化可能な名前スコープをｐａｃｋａｇｅスコープに置き換える。また、当該プログラムを構成する各クラスのパッケージ名を単一のパッケージ名に変更する。名前リスト２４に登録されているクラス名は、名前衝突回避手段２３によりパッケージ名を統一しても重複することがないように書き換えられているため、パッケージ名を変更してもクラス名の衝突は起こらない。この後、このようにしてシングルパッケージ化されたプログラムを出力手段２７が出力する。出力されたプログラムは、電子署名手段２８にて署名される。
以上のように、名前リスト２４を作成する処理と、プログラムの名前を実際に置き換える処理とに分けて実行するのは、プログラム中の名前の置き換えが必要な名前スコープを検出するために、一旦プログラム全体を見渡す必要があるためである。したがって、衝突が発生する名前スコープに限らず、全てのクラス名を変更する手法を取る場合は、名前リスト２４を作成する処理を行う必要はなく、第１の入力手段２１、名前リスト作成手段２２及び名前衝突回避手段２３を省略することができる。
【００４４】
次に、具体的なプログラムに対するシングルパッケージ化の例を示す。
図３は、本実施の形態によりプログラムがシングルパッケージ化される様子を示す図である。図４乃至図６は図３のシングルパッケージ化される前のプログラムにおける各クラスの内容を示す図、図７乃至図９はシングルパッケージ化された後の図４乃至図６に対応する各クラスの内容を示す図である。以下、これらの図を参照して説明する。
【００４５】
図３に示す例では、三つのクラスＸ、Ｙ、Ｘからなるアプリケーションプログラムをシングルパッケージ化する。処理対象である三つのクラスは、それぞれ、独立したパッケージｃｏｍ．ｉｂｍ．ｐ１、ｃｏｍ．ｉｂｍ．ｐ２、ｃｏｍ．ｉｂｍ．ｐ３に属している。
図４を参照すると、パッケージｃｏｍ．ｉｂｍ．ｐ１に属するクラスＸ（図４ではパッケージ名を付してｃｏｍ．ｉｂｍ．ｐ１．Ｘと表記）には、ｐｕｂｌｉｃスコープのメソッドが２個存在する。一つはパッケージｃｏｍ．ｉｂｍ．ｐ２への呼び出しメソッドであり、もう一つはシステムクラスから呼ばれるメソッドである。このうち、パッケージｃｏｍ．ｉｂｍ．ｐ２への呼び出しメソッドは内部化可能である。同様に、図５を参照すると、パッケージｃｏｍ．ｉｂｍ．ｐ２に属するクラスＹ（図５ではパッケージ名を付してｃｏｍ．ｉｂｍ．ｐ２．Ｙと表記）には、パッケージｃｏｍ．ｉｂｍ．ｐ３への呼び出しメソッドが存在する。また、図６を参照すると、パッケージｃｏｍ．ｉｂｍ．ｐ３に属するクラスＸ（図６ではパッケージ名を付してｃｏｍ．ｉｂｍ．ｐ３．Ｘと表記）には、パッケージｃｏｍ．ｉｂｍ．ｐ１への呼び出しメソッドが存在する。これらのメソッドは、いずれもｐｕｂｌｉｃスコープであり、かつ内部化可能である。
また、パッケージｃｏｍ．ｉｂｍ．ｐ１に属するクラスＸとパッケージｃｏｍ．ｉｂｍ．ｐ３に属するクラスＸとは、パッケージ名が共通となった場合にクラス名が重複することとなる。
【００４６】
以上のようなプログラムのシングルパッケージ化を行う。新たなパッケージ名はｃｏｍ．ｉｂｍ．ｐ０とする。
まず、上述したように、パッケージｃｏｍ．ｉｂｍ．ｐ１に属するクラスＸとパッケージｃｏｍ．ｉｂｍ．ｐ３に属するクラスＸのクラス名が衝突するので、衝突を回避するためにクラス名を変更する。ここで、どのクラス名にも現れない文字αとして、α＝”Ｆｏｏ”を用いる。これにより、パッケージｃｏｍ．ｉｂｍ．ｐ１のクラスＸのクラス名は、Ｆｏｏ＿ｃｏｍ＿ｉｂｍ＿ｐ１＿Ｘとなり、パッケージｃｏｍ．ｉｂｍ．ｐ３のクラスＸのクラス名は、Ｆｏｏ＿ｃｏｍ＿ｉｂｍ＿ｐ３＿Ｘとなって、衝突が回避された。
【００４７】
次に、内部化可能なｐｕｂｌｉｃスコープをｐａｃｋａｇｅスコープに変更する。図７を参照すると、図４におけるパッケージｃｏｍ．ｉｂｍ．ｐ２への呼び出しメソッドを含むｐｕｂｌｉｃスコープがｐａｃｋａｇｅスコープに変更され、呼び出しメソッドは同一パッケージのクラスＹへの呼び出しメソッドに変更されている。システムクラスから呼ばれるメソッドについては、内部化可能でないため、変更されていない。同様に、図８を参照すると、図５におけるパッケージｃｏｍ．ｉｂｍ．ｐ３への呼び出しメソッドを含むｐｕｂｌｉｃスコープがｐａｃｋａｇｅスコープに変更されている。また、図９を参照すると、図６におけるパッケージｃｏｍ．ｉｂｍ．ｐ１への呼び出しメソッドを含むｐｕｂｌｉｃスコープがｐａｃｋａｇｅスコープに変更されている。
【００４８】
以上のようにして、内部化可能な名前スコープが全てｐａｃｋａｇｅスコープに変更され、クラス名の衝突も回避されたので、当該プログラムのシングルパッケージ化が完了する。
上記の例では、シングルパッケージ化がソースファイルに対して行われる場合を前提にして説明した。上述のように、この処理は、クラス名、フィールド名、メソッド名の書き換えだけによって行われる。したがって、同じ処理をコンパイル済みのｃｌａｓｓファイルに適用しようとした場合、変更される部分は、Ｃｏｎｓｔａｎｔ Ｐｏｏｌだけであり、Ｂｙｔｅ Ｃｏｄｅの部分は変更の影響を受けない。すなわち、再コンパイルは不要である。このため、ソースコードを持たない他社製のライブラリを含むアプリケーションプログラムに対しても、全く同様にシングルパッケージ化を行なうことが可能であり、ほとんどの外部名を内部化することができることとなる。
【００４９】
【発明の効果】
以上説明したように、本発明によれば、名前スコープを用いたアクセス制限を有効に活用して、保護されるべきリソースを持つプログラムが不正なプログラムに呼ばれることを防止できるようにＪａｖａプログラムを編集することができる。
【００５０】
また、本発明によれば、Ｊａｖａにおけるｐａｃｋａｇｅスコープと同様の概念に基づくアクセス制御を実現するプログラミング言語において、保護されるべきリソースを持つプログラムが不正なプログラムに呼ばれることを防止できるようにプログラムを編集することができる。
【図面の簡単な説明】
【図１】本実施の形態におけるプログラムのシングルパッケージ化の方法を説明するフローチャートである。
【図２】本実施の形態におけるプログラムのシングルパッケージ化の処理を実行するシステムの構成例を説明する図である。
【図３】本実施の形態によりプログラムがシングルパッケージ化される様子を示す図である。
【図４】図３のシングルパッケージ化される前のプログラムにおけるクラスの内容を示す図であり、クラスｃｏｍ．ｉｂｍ．ｐ１．Ｘの内容を示す図である。
【図５】図３のシングルパッケージ化される前のプログラムにおけるクラスの内容を示す図であり、クラスｃｏｍ．ｉｂｍ．ｐ２．Ｙの内容を示す図である。
【図６】図３のシングルパッケージ化される前のプログラムにおけるクラスの内容を示す図であり、クラスｃｏｍ．ｉｂｍ．ｐ３．Ｘの内容を示す図である。
【図７】図３のシングルパッケージ化された後のプログラムにおけるクラスの内容を示す図であり、クラスｃｏｍ．ｉｂｍ．ｐ０．Ｆｏｏ＿ｃｏｍ＿ｉｂｍ＿ｐ１＿Ｘの内容を示す図である。
【図８】図３のシングルパッケージ化された後のプログラムにおけるクラスの内容を示す図であり、クラスｃｏｍ．ｉｂｍ．ｐ０．Ｙの内容を示す図である。
【図９】図３のシングルパッケージ化された後のプログラムにおけるクラスの内容を示す図であり、クラスｃｏｍ．ｉｂｍ．ｐ０．Ｆｏｏ＿ｃｏｍ＿ｉｂｍ＿ｐ３＿Ｘの内容を示す図である。
【符号の説明】
２１…第１の入力手段、２２…名前リスト作成手段、２３…名前衝突回避手段、２４…名前リスト、２５…第２の入力手段、２６…名前置き換え手段、２７…出力手段、２８…電子署名手段
Claims (15)
- オブジェクト指向プログラミング言語で記述されたプログラムのコンピュータによる編集方法において、
前記オブジェクト指向プログラミング言語は、一定の参照範囲を設定した場合に当該参照範囲内のみでの相互参照を認めるパッケージの概念を持ち、アクセス要求者の身元を特定する身元情報に基づいてアクセス権限を取得するアクセス制御を実現し、
前記コンピュータが、処理対象である複数のクラスからなるアプリケーションプログラムを入力し、当該アプリケーションプログラム中のクラス名と当該アプリケーションプログラムの外部から参照されていないデータの属性とを抽出して名前リストを作成し、当該名前リストを所定の記憶装置に格納するステップと、
前記コンピュータが、前記記憶装置に格納された前記名前リストに基づいて、前記アプリケーションプログラムに対して各クラスに付されたパッケージ名を単一のパッケージ名に置き換え、かつ前記アプリケーションプログラム中の前記外部から参照されていないデータの属性を同一パッケージ内からの参照を受け付けるように変更するステップと、
前記コンピュータが、前記パッケージ名の置き換え及び前記データ属性の変更とを施された前記アプリケーションプログラムに対して、アクセス要求者の身元を特定する身元情報に基づく前記アクセス権限を取得させるステップと
を含むことを特徴とするプログラムの編集方法。 - 前記コンピュータが、前記記憶装置に格納された名前リストに含まれる前記クラス名のうち、パッケージ名を共通にすると所定のクラス名が同一となる場合に、当該クラス名を変更し、当該記憶装置に格納するステップをさらに含むことを特徴とする請求項１に記載のプログラムの編集方法。
- 前記クラス名を変更して記憶装置に格納するステップでは、前記コンピュータが、変更対象である前記クラス名に対応するクラスが属するパッケージのパッケージ名に用いられた文字列を用いて、新たなクラス名を生成することを特徴とする請求項２に記載のプログラムの編集方法。
- 前記コンピュータが、前記記憶装置に格納された名前リストに含まれる前記クラス名を、相互に重複しない固有のクラス名に変更し、当該記憶装置に格納するステップをさらに含むことを特徴とする請求項１に記載のプログラムの編集方法。
- 複数のクラスにて構成されたＪａｖａのプログラムを入力する入力手段と、
前記入力手段にて入力された前記プログラム中の、各クラスが属するパッケージのパッケージ名を単一のパッケージ名に置き換えるパッケージ名置き換え手段と、
前記クラス中の、前記プログラムの外部から参照されないデータの名前スコープである内部化可能な名前スコープを、パッケージスコープに変更する名前スコープ変更手段と、
前記パッケージ名の置き換えと前記名前スコープの変更とが行われた前記プログラムを出力する出力手段とを備えたことを特徴とするシングルパッケージ化システム。 - 前記パッケージ名の置き換えと前記名前スコープの変更とが行われた前記プログラムに対して、電子署名を行う電子署名手段をさらに備えたことを特徴とする請求項５に記載のシングルパッケージ化システム。
- 前記クラスのクラス名及び前記クラス中の前記内部化可能な名前スコープの名前リストを作成する名前リスト作成手段と、
前記名前リスト作成手段にて作成された名前リスト中において、前記パッケージ名置き換え手段によるパッケージ名の置き換えによって、同一となるクラス名を検出し、当該クラス名の重複を回避するように当該名前リストにおける当該クラス名を変更する名前衝突回避手段とをさらに備え、
前記名前スコープ変更手段は、前記名前リストを参照して前記名前スコープを変更し、かつクラス名を衝突の回避されたクラス名に変更することを特徴とする請求項５に記載のシングルパッケージ化システム。 - Ｊａｖａのプログラムを開発するためのプログラム開発システムにおいて、
複数のクラスにて構成された前記プログラムに対し、各クラスが属するパッケージのパッケージ名を単一のパッケージ名に置き換えるパッケージ名置き換え手段と、
前記クラス中の、前記プログラムの外部から参照されないデータの名前スコープである内部化可能な名前スコープを、パッケージスコープに変更する名前スコープ変更手段と、
前記パッケージ名の置き換えと前記名前スコープの変更が行われた前記プログラムに対して、電子署名を行う電子署名手段とを備えたことを特徴とするプログラム開発システム。 - 前記クラスのクラス名及び前記クラス中の前記内部化可能な名前スコープの名前リストを作成する名前リスト作成手段と、
前記名前リスト作成手段にて作成された名前リスト中において、前記パッケージ名置き換え手段によるパッケージ名の置き換えによって、同一となるクラス名を検出し、当該クラス名の重複を回避するように当該名前リストにおける当該クラス名を変更する名前衝突回避手段とをさらに備え、
前記名前スコープ変更手段は、前記名前リストを参照して前記名前スコープを変更し、かつクラス名を衝突の回避されたクラス名に変更することを特徴とする請求項８に記載のプログラム開発システム。 - 一定の参照範囲を設定した場合に当該参照範囲内のみでの相互参照を認めるパッケージの概念を持ち、各々所定の当該パッケージに属する複数のクラスにて構成されたアプリケーションプログラムを入力する入力手段と、
前記入力手段にて入力された前記アプリケーションプログラムにおける各クラスが属するパッケージのパッケージ名を単一のパッケージ名に置き換えるパッケージ名置き換え手段と、
前記クラス中の、前記アプリケーションプログラムの外部から参照されないデータにおける属性を、同一パッケージ内からの参照を受け付けるように変更する属性変更手段と、
前記パッケージ名の置き換えと前記データ属性の変更とが行われた前記アプリケーションプログラムに対して、アクセス要求者の身元を特定する身元情報を付加して当該身元情報に基づくアクセス権限を取得させる身元情報付加手段と、
前記身元情報を付加されたアプリケーションプログラムを出力する出力手段とを備えたことを特徴とするプログラムの身元情報付加システム。 - 前記身元情報は、電子署名であることを特徴とする請求項１０に記載のプログラムの身元情報付加システム。
- コンピュータに、
一定の参照範囲を設定した場合に当該参照範囲内のみでの相互参照を認めるパッケージの概念を持つオブジェクト指向プログラミング言語で記述された複数のクラスからなるアプリケーションプログラムを入力し、当該アプリケーションプログラム中のクラス名と当該アプリケーションプログラムの外部から参照されていないデータの属性とを抽出して名前リストを作成し、当該名前リストを所定の記憶装置に格納する処理と、
前記記憶装置に格納された前記名前リストに基づいて、前記アプリケーションプログラムに対して各クラスに付されたパッケージ名を単一のパッケージ名に置き換え、かつ前記アプリケーションプログラム中の前記外部から参照されていないデータの属性を同一パッケージ内からの参照を受け付けるように変更する処理と、
前記パッケージ名の置き換え及び前記データ属性の変更とを施された前記アプリケーションプログラムに対して、アクセス要求者の身元を特定する身元情報に基づく前記アクセス権限を取得させる処理と
を実行させるプログラムを前記コンピュータが読み取り可能に記録したことを特徴とする記憶媒体。 - 前記プログラムは、前記記憶装置に格納された名前リストに含まれる前記クラス名のうち、パッケージ名を共通にすると所定のクラス名が同一となる場合に、当該クラス名を変更し、当該記憶装置に格納する処理を、前記コンピュータにさらに実行させることを特徴とする請求項１２に記載の記憶媒体。
- コンピュータに実行させるプログラムを当該コンピュータの入力手段が読取可能に記憶した記憶媒体において、
前記プログラムは、
複数のクラスにて構成されたＪａｖａのアプリケーションプログラム中の、各クラスが属するパッケージのパッケージ名を単一のパッケージ名に置き換える処理と、
前記クラス中の、前記アプリケーションプログラムの外部から参照されないデータの名前スコープである内部化可能な名前スコープを、パッケージスコープに変更する処理とを前記コンピュータに実行させることを特徴とする記憶媒体。 - 前記プログラムの前記パッケージ名の置き換え処理により、パッケージ名を置き換えた結果、前記アプリケーションプログラム中の所定のクラスにおけるクラス名が同一となる場合に、当該クラスのクラス名を変更する処理をさらに含むことを特徴とする請求項１４に記載の記憶媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000082556A JP3555858B2 (ja) | 2000-03-23 | 2000-03-23 | プログラムの編集方法、シングルパッケージ化システム、プログラム開発システム、プログラムの身元情報付加システム及び記憶媒体 |
| US09/816,954 US6792596B2 (en) | 2000-03-23 | 2001-03-23 | Method and system for protecting resource central programs |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000082556A JP3555858B2 (ja) | 2000-03-23 | 2000-03-23 | プログラムの編集方法、シングルパッケージ化システム、プログラム開発システム、プログラムの身元情報付加システム及び記憶媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001273131A JP2001273131A (ja) | 2001-10-05 |
| JP3555858B2 true JP3555858B2 (ja) | 2004-08-18 |
Family
ID=18599345
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000082556A Expired - Fee Related JP3555858B2 (ja) | 2000-03-23 | 2000-03-23 | プログラムの編集方法、シングルパッケージ化システム、プログラム開発システム、プログラムの身元情報付加システム及び記憶媒体 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6792596B2 (ja) |
| JP (1) | JP3555858B2 (ja) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7263722B1 (en) * | 1999-05-12 | 2007-08-28 | Fraunhofer Crcg, Inc. | Obfuscation of executable code |
| US7779039B2 (en) | 2004-04-02 | 2010-08-17 | Salesforce.Com, Inc. | Custom entities and fields in a multi-tenant database system |
| US8214799B2 (en) * | 2004-07-08 | 2012-07-03 | Microsoft Corporation | Providing information to an isolated hosted object via system-created variable objects |
| JP4669934B2 (ja) * | 2005-06-10 | 2011-04-13 | 国立大学法人 奈良先端科学技術大学院大学 | プログラム変換装置、実行支援装置、それらの方法およびそれらのコンピュータ・プログラム |
| EP1934812A4 (en) | 2005-09-09 | 2012-01-04 | Salesforce Com Inc | SYSTEMS AND METHODS FOR EXPORTING, PUBLICIZING, NAVIGATING AND INSTALLING APPLICATIONS ON DEMAND IN A MULTI-HOLDER DATABASE ENVIRONMENT |
| US7818733B2 (en) * | 2005-09-27 | 2010-10-19 | International Business Machines Corporation | Improving bundle control in computing environment |
| US20070094637A1 (en) * | 2005-10-24 | 2007-04-26 | International Business Machines Corporation | System, method, and computer program product for enabling coexistence of related software |
| DE102009052457A1 (de) * | 2009-11-09 | 2011-05-26 | Siemens Aktiengesellschaft | Verfahren und System zum Auslösen eines Namenskonfliktes |
| JP6102136B2 (ja) * | 2012-09-20 | 2017-03-29 | 日本電気株式会社 | モジュール管理装置、モジュール管理システム及びモジュール管理方法 |
| CN103560883B (zh) * | 2013-10-30 | 2016-08-31 | 南京邮电大学 | 一种基于用户权限的安卓应用程序间的安全性鉴定方法 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0546682A3 (en) * | 1991-12-12 | 1993-12-08 | Ibm | Parent class shadowing |
| US5581761A (en) | 1993-07-20 | 1996-12-03 | Sun Microsystems, Inc. | Methods and apparatus for providing an extensible set of auxiliary services for objects in an object-oriented system |
| JPH10187450A (ja) | 1996-11-07 | 1998-07-21 | Fujitsu Ltd | オブジェクト指向プログラム自動生成装置，自動生成方法およびそのプログラム記憶媒体 |
| US6339829B1 (en) * | 1998-07-30 | 2002-01-15 | International Business Machines Corporation | Method and apparatus to store extended security information in a data structure which shadows a java class object |
| US6260187B1 (en) * | 1998-08-20 | 2001-07-10 | Wily Technology, Inc. | System for modifying object oriented code |
| CA2255042C (en) * | 1998-11-30 | 2004-04-13 | Leonard W. Theivendra | Class loader |
| US6526571B1 (en) * | 1999-03-16 | 2003-02-25 | International Business Machines Corporation | Method for identifying calls in java packages whose targets are guaranteed to belong to the same package |
-
2000
- 2000-03-23 JP JP2000082556A patent/JP3555858B2/ja not_active Expired - Fee Related
-
2001
- 2001-03-23 US US09/816,954 patent/US6792596B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US6792596B2 (en) | 2004-09-14 |
| US20010025370A1 (en) | 2001-09-27 |
| JP2001273131A (ja) | 2001-10-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Stefan et al. | Flexible dynamic information flow control in Haskell | |
| Dean | Formal aspects of mobile code security | |
| Sabelfeld et al. | Declassification: Dimensions and principles | |
| Mettler et al. | Joe-E: A Security-Oriented Subset of Java. | |
| JP3786722B2 (ja) | デジタル署名を用いた進行オブジェクト指向型プログラムの有効利用方法および装置 | |
| Bokowski et al. | Confined types | |
| US6851108B1 (en) | Verifying intermediate language code | |
| JP4976991B2 (ja) | 情報処理装置、プログラム検証方法及びプログラム | |
| US7908640B2 (en) | Data handling apparatus and methods | |
| US7822723B2 (en) | Method, system, program and data structure for controlling access to sensitive functions | |
| Barnett et al. | 99.44% pure: Useful abstractions in specifications | |
| Bank | Java security | |
| Vitek et al. | Confined types | |
| Heule et al. | IFC inside: Retrofitting languages with dynamic information flow control | |
| JP3555858B2 (ja) | プログラムの編集方法、シングルパッケージ化システム、プログラム開発システム、プログラムの身元情報付加システム及び記憶媒体 | |
| Stefan et al. | Flexible dynamic information flow control in the presence of exceptions | |
| Deng et al. | SecChisel framework for security verification of secure processor architectures | |
| Bratus et al. | Implementing a vertically hardened DNP3 control stack for power applications | |
| Vassena et al. | On formalizing information-flow control libraries | |
| JP7040800B2 (ja) | コンピュータファイルメタデータの収集および表示を実施するためのアーキテクチャ、方法および装置 | |
| de Oliveira et al. | Weaving rewrite-based access control policies | |
| Cruz et al. | Type abstraction for relaxed noninterference | |
| Gregersen et al. | A dependently typed library for static information-flow control in Idris | |
| De Win et al. | How secure is AOP and what can we do about it? | |
| JP2004005441A (ja) | スクリプト処理装置、インタプリタ、スクリプト処理方法、スクリプト処理プログラム、およびスクリプトプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040115 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040210 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040401 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040423 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20040427 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040507 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |