(57)【要約】本発明は、コンピュータシステムにより実施されるためのコンピュータプロジェクトを開発する方法に関し、その方法は、提供すべき機能をカタログ化するための機能分析の段階、それらの機能を遂行するようにコンピュータ手段を利用して該プロジェクトのコンポーネントを作成する段階、この作成段階時に作成されたコンポーネントの同じシステム上での宣言の段階、および該コンポーネントをシステムによるそれらの実施のためにシステムのメモリ領域内にロードする段階を含み、・コンポーネント作成段階時に、各機能がそれに関連づけられたコンポーネントにより完全に遂行され、・コンポーネント宣言段階時に、作成された各コンポーネントが１つのシステムローディング・コンポーネントに対して宣言され、・コンポーネントロード段階時に、ロードされたコンポーネントにより要求される各機能に関連して、該機能を提供するコンポーネントを自動サーチする手段が設けられる、ことを特徴とする。【特許請求の範囲】
【請求項１】
コンピュータシステムにより実行されるためのコンピュータプロジェクト（Ｐ１， Ｐ２）を開発する方法であって、その方法は、提供すべき機能をカタログ化するための機能分析の段階（６０１） 、それらの機能を遂行するようにコンピュータ手段を利用して該プロジェクトのコンポーネント（Ｃ１， Ｃ２）を作成する段階、この作成段階時に作成されたコンポーネントの同じシステム上での宣言の段階、および該コンポーネントをシステムによるそれらの実施のためにシステムのメモリ領域内にロードする段階を含み、
・コンポーネント作成段階時に、各機能がそれに関連づけられたコンポーネントにより完全に遂行され、
・コンポーネント宣言段階時に、作成された各コンポーネントが１つのシステムローディング・コンポーネントに対して宣言され、
・コンポーネントロード段階時に、ロードされたコンポーネントにより要求される各機能に関連して、該機能を提供するコンポーネントを自動サーチする手段（ＧＤ）が設けられる、
ことを特徴とする方法。
【請求項２】
前記自動サーチがある条件を考慮しながら行われることを特徴とする、請求項１に記載の方法。
【請求項３】
前記条件が、各コンポーネントに個別的に関連づけられた特性のファンクションとして表される基準のファンクションとして表されることを特徴とする、請求項２に記載の方法。
【請求項４】
コンポーネントの作成時に、下記工程を実施することを特徴とする、請求項１〜３のいずれかに記載の方法：
・そのコンポーネントの「インターフェース」部（ＩＮＴ） を構成するための、該コンポーネントのインターフェース・ソースファイルの作成（６０２） 、
・そのコンポーネントの「実現」部（ＩＭＰ） を構成するための、該コンポーネントの機能の実現を可能にする、少なくとも１つのコード・ソースファイルの作成（６０３） 。
【請求項５】
コンポーネントの「実現」部を構成するために作成された各コード・ソースファイルが、任意のプログラミング言語で公式化することができることを特徴とする、請求項４に記載の方法。
【請求項６】
各コンポーネントが、それに関連づけられた機能を、ソフトウェアおよび／またはハードウェア手段を展開することによって遂行することができることを特徴とする、請求項４または５にに記載の方法。
【請求項７】
各コンポーネントのインターフェース・ファイルが、該コンポーネントにより遂行される機能の記述を、この機能がそのコンポーネントにより遂行される様式から独立して含んでいることを特徴とする、請求項３〜６のいずれかに記載の方法。
【請求項８】
インターフェース・ファイルが、そのコンポーネントがそれ自体の機能を遂行するために他の機能からインポートする必要がある機能の記述も含んでいることを特徴とする、請求項７に記載の方法。
【請求項９】
各コンポーネン（Ｃ１）が、同じ機能をエクスポートする別のコンポーネント（Ｃ’１） により動的に置換されうることを特徴とする、請求項１〜８のいずれかに記載の方法。
【請求項１０】
前記置換が下記工程を展開することを特徴とする、請求項９に記載の方法：
・置換されるコンポーネントの現在の状態の保存、
・新たなコンポーネントのロードと初期化、
・新たなコンポーネントへの、置換されるコンポーネントの現在の状態の伝送、
・その機能を呼出すコンポーネントと新たなコンポーネントとの間の通信チャネルの確立、
・置換されるコンポーネントのアンロード。
【請求項１１】
新たなコンポーネントのロードまたは初期化が正しく実行されない場合、エラーメッセージの復帰手段が設けられることを特徴とする、請求項１０に記載の方法。
【請求項１２】
コンポーネントの作成時に、下記工程も実施されることを特徴とする、請求項８〜１１のいずれかに記載の方法：
・下記が明記されたメイクファイルの作成（６０４） ：
‥コード・ソースファイル作成工程時に作成されたソースファイルに使用した言語、
‥コンポーネントの「実現」部に対応するコード・ソースファイル、
・コンポーネントのプロトタイプの作成（６０５） 、
・実行可能なコンポーネント・プロトタイプを生成するような、コンポーネントの「インターフェース」部と「実現」部との間のリンクの編集（６０６） 、
・コンポーネントを別個にコンパイルし、コンポーネントの「インターフェース」部のインターフェース・ソースファイル並びにコンポーネントの「実現」部の単一のまたはそれぞれのコード・ソースファイルのためのそれぞれのオブジェクト・ファイルを構成するような、メイクファイルの展開（６０９） 、
．前工程中に作成されたオブジェクト・ファイルの実行可能な単一モジュールへのカプセル化（６１０） 。
【請求項１３】
コンポーネントのプロトタイプの作成時に、下記を含むプロトタイプを作成することを特徴とする、請求項１２に記載の方法：
・コンポーネントのインターフェース・ソースファイルのコンパイルから生ずるオブジェクト・インターフェース、
・コンポーネントの「実現」部の各コード・ソースファイルに関するプロトタイプ・オブジェクト・ファイル。
【請求項１４】
コンポーネントのインターフェース・ソースファイルのコンパイル時に、下記が実施されることを特徴とする、請求項１３に記載の方法：
・インターフェースのソースファイルの一貫性の分析および検証、
・インターフェースのソースファイルの２値データへの翻訳、
・コンポーネントがインポートすべき機能を呼出すような少なくとも１つのファイルの自動生成。
【請求項１５】
実行可能なコンポーネント・プロトタイプを生成するようにコンポーネントの「インターフェース」部と「実現」部との間のリンクを編集する工程の後、自動完全性試験工程（６０７） を実施し、その間にプロジェクトが無矛盾で、かつ閉じられているか否かを検証することを特徴とする、請求項１２〜１４のいずれかに記載の方法。
【請求項１６】
自動完全性試験時に、プロジェクトに要求される各機能ごとに、アクセス可能なコンポーネントのリストの中から、該機能を遂行するコンポーネントを探す自動サーチを行うことを特徴とする、請求項１５に記載の方法。
【請求項１７】
要求された機能を遂行する幾つかのコンポーネントが識別された場合、これらのコンポーネントの中から特定の１つのコンポーネントを選択することができることを特徴とする、請求項１６に記載の方法。
【請求項１８】
完全性試験でプロジェクトが正しく閉じられていないことが明らかになった場合、いくつかのコンポーネントの修正および／またはいくつかのコンポーネントの追加が可能となるように、矛盾を指摘するエラーメッセージが発行されることを特徴とする、請求項１６または１７に記載の方法。
【請求項１９】
システム内にロードされた各コンポーネントごとに、そのコンポーネントがそれ自体の機能を遂行するよう他のコンポーネントからインポートする必要がある機能の記述が、前記の自動コンポーネントサーチ手段（ＧＤ）に永久にアクセス可能であることを特徴とする、請求項１２〜１８に記載の方法。
【請求項２０】
前工程中に作成されたオブジェクト・ファイルの実行可能な単一モジュールへのカプセル化（６１０） 時に、プロジェクトの各種インターフェース部により供給された全ての機能が実際に関連ソースファイル内に完全に記述され、かつコンパイルずみであることを検証することを特徴とする、請求項１２〜１９に記載の方法。
【請求項２１】
方法が、システムにロードされたコンポーネントのマップ（Ｇ） の、システムのランダムアクセスメモリ領域内での格納、を含むことを特徴とする、請求項１２〜２０に記載の方法。
【請求項２２】
前記マップは、ある呼出しコンポーネントがある機能を呼出す時に、該マップのあるコンポーネントが呼出された機能を供給することができるか否かを決定するよう調べるためであることを特徴とする、請求項２１に記載の方法。
【請求項２３】
前記マップを調べることができるのが、前記の自動コンポーネントサーチ手段（ＧＤ）であることを特徴とする、請求項２２に記載の方法。
【請求項２４】
前記マップが、システム内にロードされたコンポーネントのファンクションとして、システムの動作中にリアルタイムで更新されることを特徴とする、請求項２１〜２３のいずれかに記載の方法。
【請求項２５】
各コンポーネントが、そのコンポーネントの他のコンポーネントへのアクセスの可能性を、該他のコンポーネントのそれぞれの特権レベルのファンクションとして決定する特権レベルに関連づけることができることを特徴とする、請求項１〜２４のいずれか記載の方法。
【請求項２６】
各コンポーネントを、そのコンポーネントが提供する機能がコンピュータプロジェクトの動作にとって必要なくなった場合に自動的にアンロードする手段が設けられていることを特徴とする、請求項１〜２５のいずれかに記載の方法。
【請求項２７】
前記手段が各コンポーネントの利用カウンタを含むことを特徴とする、請求項２６に記載の方法。
【請求項２８】
前記カウンタが、そのカウンタが関連づけられたコンポーネントの機能をインポートしたコンポーネントの数を計数し、その利用カウンタの値が零に低下したらすぐに該コンポーネントをアンロードすることを特徴とする、請求項２７に記載の方法。
【請求項２９】
前記アンロードされたコンポーネントが使用していた資源を自動的に解放する手段（ＧＤ）が設けられていることを特徴とする、請求項２８に記載の方法。
【発明の詳細な説明】
【０００１】
【序説】
本発明は、広義には、ユーザがコンピュータハードウェアと相互作用するのを可能にするソフトウェアに関する。
【０００２】
より正確には、本発明は、今日の最も強力なオペレーティングシステムですら想像できない柔軟性 （フレキシビリティ） と実行速度の品質を提供するオペレーティングシステムを含んだソフトウェアシステムに関する。
【０００３】
本発明はまたかかるシステムに関連する方法にも関する。
また、後でわかるように、本発明は、オンボード（ｏｎ−ｂｏａｒｄ）コンピュータシステムに関連するアプリケーションの開発に適用することが有利である （但し、それに限定されない） 。
【０００４】
オペレーティングシステムはあらゆるソフトウェアシステムの必須要素であって、コンピュータシステムのハードウェア構成要素と直接相互作用する部分を構成していることを想起されたい。
【０００５】
開発チームによるアプリケーションの創作を可能し、かつユーザによるそれらのアプリケーションの実行を可能にする数多くのオペレーティングシステムが既に知られている。
【０００６】
現在あるオペレーティングシステムは、下記の２つの主な種類に大まかに分けることができる。
【０００７】
【モノリシック・アーキテクチャ】
第１の種類は、モノリシック・アーキテクチャ・オペレーティングシステムからなる。かかるシステムは、下記の３つの主なレイヤ（層）を含んだ、単一のソフトウェアセットを構成する。
【０００８】
・システムのカーネル （核） に対応する、いわゆるボトム（下部）レイヤ。カーネルは、システムのメモリ内に永久にロードされていて、全てのアプリケーションパッケージにより使用されうる、受動的かつ特権的コード・セットであると定義しうる。
【０００９】
その本質的な使命は、システムの共有資源 （メモリ、プロセッサ、周辺装置） の使用を規制することである。この使命を果たすため、カーネルは、下記機能を含むいくつかの重要な機能（ファンクショナリティ， ｆｕｎｃｔｉｏｎａｌｉｔｉｅｓ）を提供する：
‥メモリの管理 （アプリケーション間でメモリ資源をそれらのリクエストのファンクションとして分配する等） 、
‥手続きの管理 （スケジューリング、プロセッサへのアクセスの管理、マルチタスク管理等） 、
‥周辺装置のドライバの管理、
‥ファイルの管理 （名前、アドレス等）
‥ユーザの管理 （アクセス、プロファイル等） 。
【００１０】
・ユーザがシステムへの指令を入力したり、カーネルに与えられるリクエストを入力するために相互作用することができる、アプリケーションに振り向けられた、いわゆるトップ （上部） レイヤ、
・中間レベルのいわゆるライブラリ、これはレイヤと見なされる場合があり、その中に反復する機能が、それらの素早い実行を可能にするように一緒に集められている。
【００１１】
このようなモノリシックアーキテクチャを本書に添付する図１に模式的に示す。この図は、Ｋ （カーネル） 、Ｌ （ライブラリ） およびＡ （アプリケーション） の各レイヤからなる、中心に集まる階層型の配置を示している。
【００１２】
各「レイヤ」の定義により、そのオペレーティングシステムの要素 （エレメント） 間の通信を階層化することが可能となり、最下層のレイヤは、より上層レベルのレイヤにより呼出すことができる「特権」レイヤであると定義される。
【００１３】
従って、これらの最下層レイヤは同じ特権 （プリビレッジ） を共有する種類のソフトウェア要素である。また、特権とは、そのコンピュータシステムのいくつかの資源（リソース）（ハードウェア資源またはソフトウェア資源） を使用する能力であると定義されうる。
【００１４】
既に述べたように、このようなモノリシックアーキテクチャに従って構築されたシステムは単一のソフトウェアセットを構成し、それは「ブロック的に（ｂｌｏｃｋｗｉｓｅ） 」コンパイル可能である。
【００１５】
この構成の１つの利点は、システムが一般に安定で速いことである。
しかし、このようなオペレーティングシステムは、システムの柔軟性とアップグレード可能性に関して著しい制限を示す。
【００１６】
実際、カーネルの修正は体系的にそのカーネルの完全な再コンパイルを伴う。従って、修正ごとにシステムの全体の受入れを保証し直す必要がある。
また、このシステムの柔軟性の欠如は、システムのアップグレードが厄介で複雑になり、そのメンテナンスが高価になる点でも不利である。さらに、このシステムは、継続的な「アドオン」によって不安定になることがある。
【００１７】
さらに、オンボード・コンピュータシステムの場合 （即ち、少なくとも一部が車両、携帯電話等といった移動ハードウェア内に組み込まれるものである場合） 、この柔軟性の欠如が極めて不利となって現れることがある。なぜなら、それによって、コンピュータシステムのある数の特性を事前に固定すること （実行速度またはメモリのサイズ等を特権化することなど） も必要になるからである。
【００１８】
実際、オンボードアプリケーションの多様性のため、プログラマは関係するコンピュータシステムの雑多なリクエストに直面することが多く、システムの主な特性を自由に定義し、かつアップグレードすることが可能であることは有利であろう。
【００１９】
従って、モノリシック・オペレーティングシステムの柔軟性の欠如に主に起因する、上に示唆した欠点のため、このモノリシック・アーキテクチャは、本質的にソフトウェアまたはハードウェアの著しいアップグレードを必要としないアプリケーション用であり、オンボードシステムにはあまり向いていない。
【００２０】
【マイクロカーネル・アーキテクチャ】
この制限を軽減する試みとして、オペレーティングシステムに対する別の種類のアーキテクチャが考案された。それらは、図２に示されるもののように、マイクロカーネル型のシステムである。
【００２１】
この図は、マイクロカーネルシステムが、モノリシックシステムのように、オペレーティングシステムの「コア」を構成する中心カーネルを包囲した同心レイヤから成り立つことを示している。
【００２２】
カーネル要素ＭＫは、ここでは、システムの動作に必要な必須機能、即ち、下記の機能、だけを果たす「マイクロカーネル」に縮小されている：
・メモリの管理、
・手続き、少なくともタスクの切替えに関係する、いわゆる低レベル手続きの管理。ある種のマイクロカーネルシステムはサーバの助けを借りて高レベル手続きを管理するが、別のものはマイクロカーネルそれ自体によってそれらを管理することを指摘しておく、
・ポート（メールボックス）の管理およびメッセージの受け渡し、
・各種ドライバ間でのハードウェア資源の割当ての仲裁（ドライバはカードまたは任意の周辺装置の動作を制御するプログラムであると定義される）。
【００２３】
モノリシックシステムのカーネルによって従来より遂行されてきた上記以外の機能は、サーバＳにより遂行される。これらのサーバは、上部レイヤのアプリケーションＡとマイクロカーネルＭＫを直接包囲しているライブラリーのレイヤＬとの間の中間レイヤを形成している。それらは、アプリケーションＡより優先順位を得ている。
【００２４】
このようなマイクロカーネル・アーキテクチャにより、システム全体を再コンパイルすることを必要とせずにオペレーティングシステムをアップグレードすることが可能となる；従って、この第２の種類のオペレーティングシステムでは、モノリシックシステムに比べてある種の柔軟性が得られる。
【００２５】
しかし、この種類のアーキテクチャはなお、中心カーネルの周囲にレイヤが引き続く構成をとり、オペレーティングシステムの内部での全ての通信の交換はマイクロカーネルを必ず通過しなければならない。
【００２６】
実際、このシステムの引き続いたレイヤは、モノリシックシステムの場合より数が多いだけに、それらのレイヤを通る通信の通過は追加の処理を生じさせ、システムの全体的な動作を遅くする。
【００２７】
また、その結果、システムの何か新たな開発のためにはこれらの通信の交換を最適化する必要があり、それによってプログラマの作業は複雑になる。
従って、マイクロカーネルシステムは、モノリシックシステムに比べればより大きな柔軟性を与えるものの、より冗長な処理演算を伴い、不完全な解決策でしかない。
【００２８】
【既存のアーキテクチャに関する追加コメント】
さらに、現今のシステム （モノリシックおよびマイクロカーネル） はすべてカーネル要素を中心とし、その周囲に引き続くレイヤが予め決められたアクセス特権のファンクションとして階層化されている。
【００２９】
実際、これらの全てのシステムにおいて、各プログラムはシステムそれ自体に固有の不変タイポロジーに従って所定のレイヤと組織的に関連づけられるので、このプログラムはプログラマのコントロールを超えた特権レベルを組織的に伴うことになり、それにより既存システムに共通する第１の欠点となる。
【００３０】
従って、プログラムは例えば次のようになることがある：
・「カーネル」もしくは「スーパバイザ （監視プログラム） 」もしくは「システム」コード （ハードウェアとの相互作用を管理する特権コード） 、
・受動的機能 （数学的、ビデオ圧縮解除など） の「ライブラリ」要素、
・アプリケーションパッケージコード。
【００３１】
このような多様なタイプのコードは、しばしば異なるファイル形式に対応し、オペレーティングシステムの異なる要素により別個に管理される。
また、そうなると、システムにインストールされた全てのプログラムを単一のツールで表示することが可能でなくなり；同様に、システムの動作中には、１つのオペーク （不透明） で分割できないブロックを構成する「カーネル」部分を交換することも一般には可能でなくなる。
【００３２】
その結果、これらの多様なタイプのコードを作成し、デバッグするのに異なるツールを使用しなければならないことになり、それによりあらゆる場合の開発作業が複雑になる；これが既存システムに共通する第２の欠点である。
【００３３】
また、既存システムのカーネルがシステムの絶対中心を構成することは当然である。このカーネルは、その特権レベルの力により特殊なステータスを有し；これはシステムの最小携帯部分を構成し、簡単に修正することはできない。
【００３４】
さらに、既存のソフトウェアシステムに共通の別の特徴は、それらの設計が下記によって行われてきたことである：
・果たすべき機能に関してシステムを記述することを可能にし、それにより非常に直感的ですぐに理解できる記述レベルを構成する、機能分析の段階、
・それに続く書込みとプログラム類のコンパイル、その間にこの理解容易性と読み易さのレベルは悪い方に変化する。プログラム類は、その動作様式が予め決まっているオペークセットを構成する。
【００３５】
これらのシステムのプログラム類は、「オートマトン」としてオン・リクエスト（ｏｎ ｒｅｑｕｅｓｔ）で動作し、カーネルは単にアプリケーションが表す要求 （ニーズ） のファンクションとして反応に作用する。
【００３６】
従って、カーネルは、資源 （リソース） に合わせて作り、システムの全体的な動作を改善するために最適化ファンクションを使用することができるももの、常にアプリケーションが表す要求に関して下流側で、反応に作用する。これは、既存システムの別の本質的な制限となる。
【００３７】
後でわかるように、他方で本発明の場合は、システムの全てのコンポーネントの動作様式が統合され、機能分析段階時に確立された機能リンクがシステムのアーキテクチャ内に保存される。
【００３８】
従って、Ｊａｖａ（登録商標）言語により代表されるような既知のシステムに対して、エンティティ間の関係を確立する場合にある程度の追加の柔軟性を与えることが有利となろう。上記言語の記述は、２００１年３月７日現在でインターネットアドレス ＜ｈｔｔｐ：／／ｍａｔｈ．ｈｗｓ．ｅｄｕ／ｅｃｋ／ｃｓ１２４／ｄｏｗｎｌｏａｄｓ／Ｊａｖａｎｏｔｅｓ３．ｐｄｆ＞ にてアクセスできる、Ｄ．Ｊ． ＥＣＫ −ニューヨーク州Ｇｅｎｅｖａのホバート・アンド・ウイリアム・スミス・カレッジの数学・コンピュータサイエンス部− による「Ｊａｖａ（登録商標）を用いたプログラミングの入門、バージョン３．０ 、２０００年夏」と題する文書（ＵＳ ２４／０５／２０００） に見られよう。
【００３９】
「エンティティ」なる用語は、既知言語 （例えばＪａｖａ（登録商標））の場合、展開することができるオブジェクトおよびクラスを意味すると理解すべきである。
Ｊａｖａ（登録商標）言語の場合、実際、あるエンティティがその動作に必要な他のいくつかのエンティティを実際に呼出すことができるなら、プログラマは、そのある呼出しエンティティを適正に動作可能にするため、どのエンティティをシステムのランダムアクセスメモリ中へロードすべきかを必ずはっきり明記しなければならない。
【００４０】
従って、このタイプの既知言語は、オブジェクト・アーキテクチャに関していくらかの柔軟性を実際に与えるものの、特定のエンティティを設計から正しく選択することを強要し、それによりシステムの柔軟性を大きく制限することは明らかである。
【００４１】
さらに、このような既知のシステムは、ローディング動作中はいかなるエラーメッセージも復帰させないので、欠陥エンティティまたはその役割を果たすことができないエンティティが、システム内にロードされてしまう可能性がある。また、そのエンティティの欠陥に気づくのが、システムの全体の動作中、または特別にスケジュールしなければならない試験動作中だけなる。
【００４２】
【発明の目的】
本発明の主な目的は、現今の最も強力なオペレーティングシステムでさえ考えられないような柔軟性と実行速度の品質を与えるオペレーティングシステムを提案することである。
【００４３】
本発明の別の目的は、全ての既存システムに関して上に示唆した欠点を克服することをさらに可能にするソフトウェアシステムを提案することである。
本発明のさらに別の目的は、オンボードシステムの設計に固有の制約に合わせたソフトウェアの解決法を提供することである。
【００４４】
これらの目的を達成するため、本発明は、コンピュータシステムにより実行されるためのコンピュータプロジェクトを開発する方法を提案する。その方法は、提供すべき機能をカタログ化するための機能分析の段階、それらの機能を遂行するようにコンピュータ手段を利用して該プロジェクトのコンポーネントを作成する段階、この作成段階時に作成されたコンポーネントの同じシステム上での宣言（ｄｅｃｌａｒａｔｉｏｎ）の段階、および該コンポーネントをシステムによるそれらの実施のためにシステムのメモリ領域内にロードする段階を含み、
・コンポーネント作成段階時に、各機能がそれに関連づけられたコンポーネントにより完全に遂行され、
・コンポーネント宣言段階時に、作成された各コンポーネントが１つのシステムローディング・コンポーネントに対して宣言され、
・コンポーネントロード段階時に、ロードされたコンポーネントにより要求される各機能に関連して、該機能を提供するコンポーネントを自動的にサーチする手段が設けられる、
ことを特徴とする。
【００４５】
本発明に係る方法の好ましいが制限ではない態様は次の通りである：
・前記自動的なサーチは、条件を考慮しながら行われる。
・前記条件は、各コンポーネントに個別的に関連づけられた特性のファンクションとして表される基準のファンクションとして表される
・コンポーネントの作成時に、下記工程を実施する：
‥そのコンポーネントの「インターフェース」部を構成するための、該コンポーネントのインターフェース・ソースファイルの作成、
‥そのコンポーネントの「実現」部を構成するための、該コンポーネントの機能の実現を可能にする少なくとも１つのコード・ソースファイルの作成。
【００４６】
・コンポーネントの「実現」部を構成するために作成された各コード・ソースファイルは、任意のプログラミング言語で公式化することができる。
・各コンポーネントは、それに関連づけられた機能を、ソフトウェアおよび／またはハードウェア手段を展開することによって遂行することができる。
【００４７】
・各コンポーネントのインターフェース・ファイルは、該コンポーネントにより遂行される機能の記述を、この機能がそのコンポーネントにより遂行される様式から独立して含んでいる。
【００４８】
・インターフェース・ファイルは、そのコンポーネントがそれ自体の機能を遂行するために他の機能からインポートする必要がある機能の記述もまた、含んでいる。
【００４９】
・各コンポーネントは、同じ機能をエクスポートする別のコンポーネントにより動的に置換されうる。
・前記置換は下記工程を展開する：
‥置換されるコンポーネントの現在の状態の保存（セーブ）、
‥新たなコンポーネントのロードと初期化、
‥新たなコンポーネントへの、置換されるコンポーネントの現在の状態の伝送、
‥その機能を呼出すコンポーネントと新たなコンポーネントとの間の通信チャネルの確立、
‥置換されるコンポーネントのアンロード。
【００５０】
・新たなコンポーネントのロードまたは初期化が正しく実行されない場合、エラーメッセージの復帰手段が設けられる。
・コンポーネントの作成時に、下記工程も実施される：
‥下記が明記されたメイクファイル（ｍａｋｅｆｉｌｅ）の作成：
…コード・ソースファイル作成工程時に作成されたソースファイルに使用した言語、
…コンポーネントの「実現」部に対応するコード・ソースファイル、
‥コンポーネントのプロトタイプの作成、
‥実行可能なコンポーネント・プロトタイプを生成するような、コンポーネントの「インターフェース」部と「実現」部との間のリンクの編集、
‥コンポーネントを別個にコンパイルし、コンポーネントの「インターフェース」部のインターフェース・ソースファイル並びにコンポーネントの「実現」部の単一のまたはそれぞれのコード・ソースファイルのためのそれぞれのオブジェクト・ファイルを構成するような、メイクファイルの展開、
‥前工程中に作成されたオブジェクト・ファイルの実行可能な単一モジュールへのカプセル化。
【００５１】
・コンポーネントのプロトタイプの作成時に、下記を含むプロトタイプを作成する：
‥コンポーネントのインターフェース・ソースファイルのコンパイルから生ずるオブジェクト・インターフェース、
‥コンポーネントの「実現」部の各コード・ソースファイルに関するプロトタイプ・オブジェクト・ファイル。
【００５２】
・コンポーネントのインターフェース・ソースファイルのコンパイル時に、下記が実施される：
‥インターフェースのソースファイルの一貫性の分析および検証、
‥インターフェースのソースファイルの２値データへの翻訳、
‥コンポーネントがインポートすべき機能を呼出すような少なくとも１つのファイルの自動生成。
【００５３】
・実行可能なコンポーネント・プロトタイプを生成するようにコンポーネントの「インターフェース」部と「実現」部との間のリンクを編集する工程の後、自動完全性試験工程を実施し、その間にプロジェクトが無矛盾で、かつ閉じられているか否かを検証する。
【００５４】
・自動完全性試験時に、プロジェクトに要求される各機能ごとに、アクセス可能なコンポーネントのリストの中から、該機能を遂行するコンポーネントを探す自動サーチを行う。
【００５５】
・要求された機能を遂行する幾つかのコンポーネントが識別された場合に、これらのコンポーネントの中から特定の１つのコンポーネントを選択することができる。
【００５６】
・完全性試験でプロジェクトが正しく閉じられていないことが明らかになった場合、いくつかのコンポーネントの修正および／またはいくつかのコンポーネントの追加が可能となるよう、矛盾を指摘するエラーメッセージが発行される。
【００５７】
・システム内にロードされた各コンポーネントごとに、そのコンポーネントがそれ自体の機能を遂行するよう他のコンポーネントからインポートする必要がある機能の記述が、前記の自動コンポーネントサーチ手段に永久にアクセス可能である。
【００５８】
・前工程中に作成されたオブジェクト・ファイルを実行可能な単一モジュールにカプセル化する時に、プロジェクトの各種インターフェース部により供給された全ての機能が実際に関連ソースファイル内に完全に記述され、かつコンパイルずみであることを検証する。
【００５９】
・方法が、システム内にロードされたコンポーネントのマップの、システムのランダムアクセスメモリ領域内での格納を含む。
・前記マップは、ある呼出しコンポーネントがある機能を呼出す時に、該マップのあるコンポーネントが呼出された機能を供給することができるか否かを決定するよう調べるためである。
【００６０】
・前記マップを調べることができるのが、前記の自動コンポーネントサーチ手段である。
・前記マップが、システム内にロードされたコンポーネントのファンクションとして、システムの動作中にリアルタイムで更新される。
【００６１】
・各コンポーネントが、そのコンポーネントの他のコンポーネントへのアクセスの可能性を、該他のコンポーネントのそれぞれの特権レベルのファンクションとして決定する特権レベルに関連づけることができる。
【００６２】
・各コンポーネントを、そのコンポーネントが提供する機能がコンピュータプロジェクトの動作に必要なくなった場合に自動的にアンロードする手段が設けられている。
【００６３】
・前記手段が各コンポーネントの利用カウンタ（計数器）を含む。
・前記カウンタが、そのカウンタが関連づけられたコンポーネントの機能をインポートしたコンポーネントの数を計数し、その利用カウンタの値が零に低下したらすぐに該コンポーネントをアンロードする。
【００６４】
・前記アンロードされたコンポーネントが使用していた資源を自動的に解放する手段が設けられている。
本発明に係るシステムの他の態様、目的および利点は、添付図面を参照した、本発明の１実施態様に関する以下の説明を読むと、より明らかとなろう。
【００６５】
【システムの一般的な紹介】
既存システムは、モノリシックとマイクロカーネルのいずれであろうと、プログラム類を、それらが関連づけられたシステムレイヤのファンクションとして系統的に区別してしまうことは既に述べた。
【００６６】
本発明に係るシステムは、プログラム類をこのように区別することはない。反対に、本発明の場合、オペレーティングシステムは、全体が非階層的コンポーネントからなる。従って、オリジナルな特徴によると、本発明に係るシステムは、層状（レイヤ）構造を示さない。
【００６７】
また、ソフトウェアシステムのプログラマは、本発明の場合、システムの各コンポーネントを、残りのコンポーネントと通信するように特定の特権レベル（この特権レベルは、現状技術のシステムで従来より使用されてきたもの−「カーネル」、「ライブラリ」、「アプリケーションパッケージ」−に対応する場合もあり、またはオン・リクエストで作成されたものである場合もある）と関連づける可能性を保持しているが、プログラマは、各コンポーネントについてそのような関連づけを行ったりすること、またはその他、各コンポーネントについて任意の望ましい特権レベルを選択することが自由にできる。
【００６８】
「プログラマ」なる用語は、一人の人または１つの開発チームに関係すると定義される。本発明に係るシステムの主な利点は、後で理解されるように、開発チームを可能な最も効果的なやり方で作業させることを可能にし、各開発者が１つのコンポーネントを開発することによって１つのアプリケーションの１つの機能に責任を持つことができるようにすることである。また、本発明に係るシステムにより提供される特権の詳しい管理は、例えば、下記のように、数多くの可能性を切り開く：
・「非特権」モードでのコンポーネントの作成、開発および完全な試験（アプリケーションパッケージ）、および開発が終了し、完全に妥当性確認された後、「特権」モードでのターゲット上でのその利用（システム）。この手法は、アプリケーションフォームで「ドライバ」を設計し、その後にそれを「システム」モードで、モノリシックカーネルに等しい性能レベルで利用することを可能にすることにより、マイクロカーネルシステムと同じ微調整の柔軟性を可能にする。
【００６９】
・同じタイプの１群のコンポーネント（例、”ｃｏｄｅｃ” 、データコーダ／デコーダの群） の中で異なる特権を割り当てる可能性：速度のための、システムコンポーネント形態の単純なコンポーネント （例、 ＧＩＦ ”ｃｏｄｅｃ”） と；それほど速くないが、安全で、完全な耐故障性を与える、ユーザコンポーネント形態の複雑なコンポーネント （例、ＨＴＭＬ ”ｃｏｄｅｃ”またはＭａｃｒｏｍｅｄｉａ Ｆｌａｓｈ （登録商標））の両方の利用。
【００７０】
ケースバイケース基準でこの選択を行うことにより、プログラマは彼のシステムを完全に彼の目的のファンクションとして構築することが可能になる。
図３ａ〜３ｃは、本発明に係るシステムのアーキテクチャの概要を示す。このシステムは、もっぱらコンポーネントを基準として具体化され、カーネルやマイクロカーネルのような「中心」要素を含んでいない。
【００７１】
後でわかるように、これらのコンポーネントのそれぞれは、システム内でそれ自体で存在し、それらの作成、コンパイル、システム内のメモリへのロードおよびアンロードは、互いから独立して行うことができ、それにより下記が可能となる：
・リブートすることなく、システムの動的更新 （新バージョン、バグの訂正、等） を行う、
・ソフトウェアシステムの設計中に、そのソフトウェアシステムによるハードウェアの抽象化におけるあまり軽便ではない （重い） 「スタンス」を、ハードウェア管理ポリシーを末端製品自体の要求のファンクションとして変化させる可能性を与えることによって回避する。
【００７２】
カーネルならびに大部分のプログラムが多数 （または複数） の機能を遂行する従来のオペレーティングシステムとは異なり、本発明に係るシステムの各コンポーネントは、単一の機能の専用になっている。
【００７３】
また、それに関連づけられる機能を遂行するため、各コンポーネントは、１または２以上の他のコンポーネントによる１または２以上の他の機能の実行を要求することができる。
【００７４】
従って、動作するために、本発明に係るシステムは、そのメモリ内にロードされた各所定コンポーネントを、その所定コンポーネント自体の動作に要求される機能を遂行する他のコンポーネントと通信させる。
【００７５】
そのため、図３ａ〜３ｃは、あるいくつかのコンポーネント間で、それらが相互に機能を通信するのを可能にするように、システムによって確立された通信チャネルを示す矢印を含んでいる。
【００７６】
これらの図はまた、システムのアーキテクチャの動的性質も示し、図３ｃに示すように、コンポーネント３１は、他のどのコンポーネントも変化させることを必要とせずに、同じ機能を遂行するようにコンポーネント３２で置換することが可能である。これらの態様は後で詳しく説明する。
【００７７】
【コンポーネント−一般的考察】
◆一般的定義
コンポーネントは本発明に係るシステムの基本的な要素であるので、それを正確に定義することが重要であるのは当然である。
【００７８】
本発明の意味におけるコンポーネントとは、隔離された、独立かつ自律的なコード要素である。後でより詳しく説明するように、本発明に係るシステムの各コンポーネントは、下記の特性を有する：
・それ（各コンポーネント）は、それが振り向けられたある特有の機能を遂行する。
【００７９】
・それは、この機能を完全に遂行する。ある所定の機能が単一のコンポーネント内で実行される。これは、アプリケーションまたは任意の他のプログラムの操作中に、ある所定の機能を変更したい場合、２以上のコンポーネントを修正または置換せずにすむことを可能にする。
【００８０】
・オブジェクト・フィロソフィに関する限り、ある所定機能があるコンポーネントにより遂行される方法は、この機能を使用する残りのコンポーネントには知られない。
【００８１】
・各コンポーネントは、そのコンポーネントのカプセル（コンポーネントの「モジュール」と呼ばれる）にリンクさせることができる、別個の実行可能なファイルを形成するように、独立してコンパイルされる。コンパイル中に、コンポーネント間のリンクの編集はない。これにより、特に従来のシステムでは「カーネル」に割り当てられていた、システムの必須機能を遂行するコンポーネントに関して、これまで知られていなかった柔軟性が可能となる。
【００８２】
・各コンポーネントは、そのモジュール内にカプセル化された実行可能なコードと関連づけられ、それには同様に個々にそのコンポーネントと関連づけられる１つのインターフェースが使われる。１つのコンポーネントの設計中に、設計者は、そのコンポーネントのインターフェースのソースバージョンを構成するテキストファイル内に、そのコンポーネントが供給する機能を、本出願人によりこの目的のために特別に設計された記述言語を用いて記述する。この記述は、そのコンポーネントに関してシステムに利用可能となる唯一の情報である。このようなカプセル化は、システムのコンポーネント間の制御できない相互依存や「エッジ効果」がないことを保証する。
【００８３】
本発明に係るシステムの１つのコンポーネントは、従って、１つのインターフェースを使ってシステムの残りから隔離された、完全にカプセル化された（モジュール内に）ソフトウェア・オブジェクトであり、このインターフェースは、後からわかるように、下記の特性を有する：
・再利用性とモジュール性（１つ及び同じコンポーネントを各種アプリケーション−またはより一般的には各種プログラム−内で展開することができる）、
・環境の独立性（各コンポーネントが独立して形成され、システム内で独立してロードおよびアンロードされうる）、
・動的リンク（各コンポーネントは、組織的ではなく、オン・リクエストで介入する） 、
・および所定の機能内での特殊化。
【００８４】
１つのコンポーネントＣは、図４に示すように、下記の２つの主要部分からなる：
・このコンポーネントに関連づけられた機能の実現を可能にする部分ＩＭＰ。この部分は、慣行としてコンポーネントの「実現部」と呼ばれよう。この部分は、コンポーネントの機能を遂行するために実行されるコード、および／またはハードウェア要素上でのハードウェア実施に対応する。「コード」なる用語は、コンポーネントに関連づけられた機能を遂行することを意図し、この目的のために１または２以上の関数（ファンクション）を実行する、自体公知の任意の言語で書かれうる１または２以上のプログラムを意味すると理解される。
【００８５】
・および、コンポーネントの「インターフェース」部分ＩＮＴ。これは、システムの残りのコンポーネントとの対話を可能にする記述部分である。
◆コンポーネントのカプセル化
各コンポーネントは、そのコンポーネントのインターフェースおよびコードに対応するオブジェクト・ファイルをリンクする１つの実行可能ファイルである「モジュール」内にカプセル化される。後からわかるように、このファイルは、本発明に係るシステムを構成する残りのコンポーネントから独立して、各コンポーネントごとに自律的に形成される。
【００８６】
１つのコンポーネントを形成するには、その実行中に使用することが必要となる、そのコンポーネントに対して外部の機能とその結果を定義する必要がある。これは、慣用の機能分析スキームの範疇に入る。
【００８７】
他方、当然ながら、本発明に係るシステムは、そのコンポーネントの実行領域までは、この機能分析段階から生まれる意味情報を保存する。
これは、著しくシステムのアップグレードを容易にし、かつその読み易さを増大させる。
【００８８】
コンポーネントに対して外部の機能は、本出願人により作成され、先に示唆した従属性言語（ｄｅｐｅｎｄｅｎｃｉｅｓ ｌａｎｇｕａｇｅ） を用いて、コンポーネントのインターフェース・ソースファイル内に記述される。
【００８９】
より正確には、１つのコンポーネントＣに関連づけられた各インターフェース・ソースファイルＩＮＴは、このコンポーネントを完全に記述することを可能にする。それは、それが他のコンポーネントからインポートしなければならないインターフェース要素と、それが他のコンポーネントにエクスポートするインターフェース要素とを記述する。
【００９０】
このファイルは、後述する図５に概要を示すように、実現部ＩＭＰのコードに（換言すると、そのコンポーネントの実現部のソースファイルのそれぞれに）対応するオブジェクト・ファイルにコンパイル（メイクファイルとも呼ばれるコンパイル化ファイルＭＦを用いて）およびリンクされ、そのコンポーネントの実行可能なバージョンを構成するコンポーネントのモジュールＭを形成する。インターフェース・ソースファイルを作成するのに使用する従属性言語は本明細書において後で説明する。
【００９１】
モジュールＭは次いで、後で詳述するように、ターゲット５０ （ターゲットは、その上で本発明に係るシステムが動作するコンピュータハードウェアであると定義される） 上にロードされて、このターゲット上に存在する残りのコンポーネントにより直ちに認識されることができる。
【００９２】
◆コンポーネントの実現部
実現部ＩＭＰは、コンポーネントの操作上のコアである。これは、そのコンポーネントの機能の有効な実現を可能にする部分である。この機能は、コードにより展開されるファンクションに従って、実現部により多様な手法で実現することができる。
【００９３】
即ち、各種のコンポーネントが異なる基準を考慮しながら、それぞれ１つの同じ機能を実現することができる。それらの基準は、そのコンポーネントが関与するアプリケーションもしくはプログラムの設計中に予め定めてもよく、またはアプリケーションの実際の実行中に動的に定めてもよい。
【００９４】
これらの基準は、コンポーネントのインターフェースと関連づけられた、本明細書において後で説明する特性（例えば、ボイド、チャー（ｃｈａｒ）等） の形態で記述される。
【００９５】
基準は、これらの１つの特性のファンクションとして表現され、その特性が定義されるのは、その機能をエクスポートするコンポーネントのインターフェース内、ある比較演算子をこの特性ならびに比較値と関連づけて （後述するように、＜、＞、＝等） その機能をインポートするコンポーネントのインターフェース内である。
【００９６】
また、システムまたはアプリケーションを、そのコンポーネントに対して外部の基準 （例えば、ハードウェア） のファンクションとして、またはシステムおよび実行中のアプリケーションの現状のファンクションとして、静的または動的に適合させることも可能である。
【００９７】
従って、各コンポーネントのインターフェースファイルは一組のメタ情報（ｍｅｔａ−ｉｎｆｏｒｍａｔｉｏｎ）を供給し、このメタ情報は、後からわかるように、システムの特定のコンポーネント （従属性管理プログラム＜ｄｅｐｅｎｄｅｎｃｉｅｓ ｍａｎａｇｅｒ＞） が、先に示唆した基準 （それらの基準はそのコンポーネントのバージョン、このコンポーネントの位置、システムの状態のデータ項目等に関連しうる） のファンクションとして、それらのコンポーネント間の関係を適切に管理するのを可能にする。
【００９８】
各機能が１つのコードにより独自に実現 （その機能の「ソフトウェア」実現） されうるなら、その機能を遂行するための少なくとも１つのハードウェア要素 （その機能の「ハードウェア」実現） を伴うことが可能であることもまた指摘される。
【００９９】
◆コンポーネントのインターフェース部
インターフェース部は、そのコンポーネントによりどの機能が供給されるか、およびその実行中にどの機能をそれに供給しなければならないかを、正確に記述することを可能にする。
【０１００】
それは、本出願人により開発された従属性言語（ｄｅｐｅｎｄｅｎｃｉｅｓ ｌａｎｇｕａｇｅ） で、そのコンポーネントへの入力 （インプット） として供給される必要があるデータのフォーマット、およびそのコンポーネントにより出力 （アウトプット） されるデータのフォーマットを定義する。このフォーマットは、既に実現された機能だけに （その機能が実現部により実現される途中ではなく） 依存する。
【０１０１】
このインターフェース部は、そのコンポーネントにより実現された機能の記述を、この機能が実現部により実現される様式とは独立して構築することを可能にする。実際、あるコード （またはあるプログラムされたハードウェア要素） によるその機能の展開のモードが何であろうと、この機能は同一のままである。それは同じ処理操作を実行し、入力時に同じ情報を要求し、出力時に同じデータを供給する。
【０１０２】
従って、インターフェース部はシステムのアップグレードを可能にする。ある機能のソフトウェア実施 （その実現部がコードからなるコンポーネントに対応する） は、こうして後でハードウェア実施により実現されよう。
【０１０３】
この場合、対応するコンポーネントは１つのインターフェースファイルを含むが、その実現部はハードウェア要素との連係を記述する非常に簡単なプログラムからなる。
【０１０４】
逆に、ハードウェア実施は、残りのコンポーネントに影響を全く及ぼさずに、ある機能のあるソフトウェア実施と置換することができる。
インターフェースは、そのコンポーネントのモジュールの記述内に「インターフェース」なるキーワードで定義される。
【０１０５】
次の表は、ある機能の各種の特性を記述する；これらの特性は、そのコンポーネントにより要求される機能 （方向＝インポート） またはその機能が供給する機能 （方向＝エクスポート） に関係しうる。
【０１０６】
【表１】
2004503866.tif 000002
【０１０７】
インターフェースは、各種の特性を用いてそのテキストファイル中に定義されうる。１例を以下に示す。
【０１０８】
【数１】
2004503866.tif 000003
【０１０９】
→インターフェースの特性：
インターフェースの特性により、本明細書で先に示唆した基準を定義することが可能となる。これらは、Ｃ言語 （登録商標） におけるように、タイプされる。次の表は各種種類の特性を記述する。
【０１１０】
【表２】
2004503866.tif 000004
【０１１１】
下記の拡張子をこれらの特性と関連づけることができる
【０１１２】
【表３】
2004503866.tif 000005
【０１１３】
インターフェースファイルにおける従属性の記述中に、演算子はインターフェースの特性を明記するのを可能にする。従って、演算子が別のインターフェースのインポートを許可するのを可能にするのは、この他のインターフェースの特性の値がある十分に定義された基準に対応する場合だけである。
【０１１４】
下記の演算子をインターフェースの特性と関連づけることができる。
【０１１５】
【表４】
2004503866.tif 000006
【０１１６】
キーワード ”ｕｎｄｅｆ”を特性またはファンクションの比較値として使用することができる。後述する実施例では、考慮したコンポーネントは、その値が正確に２でなければならない ｍａｉｎＴｙｐｅ という名前の３２ビット整数特性を含む、ｃｏｄｅｃ という名前のインターフェースを必要とする。このインターフェースは、パラメータとして文字列を取り、３２ビット符号つき整数に復帰する機能Ｆｕｎｃ｛｝を保証しなければならない。
【０１１７】
【数２】
2004503866.tif 000007
【０１１８】
従って、この機能の供給と要求は、供給または要求されたプログラミング・インターフェースの記述を介してなされる。例えば、あるコンポーネントが、「スケジューラ」プログラミング・インターフェース （スケジューラは、手続きおよびスレッドの作成／破壊／操作ならびにそれらの同期を可能にする） を供給する一方で、「メモリ」インターフェース （メモリ管理） 、「タイマ」インターフェース （所定時間後にある手続きを中断し、次の手続きに進むためにスケジューラにより要求される、時間カウンタの管理） 、等を要求することができる。
【０１１９】
これらのプログラミング・インターフェースは、下記の両方を含んでいてもよい：
・特性 （バージョン、メモリ管理のタイプ、順序づけ （シーケシング） の特性、等） 、
・およびそのコンポーネントの実行のために呼び出される方法 （ファンクション） 。
【０１２０】
特性は、あるインターフェースの供給中と要求中の両方に使用することができる。従って、あるコンポーネントに関連づけられたメモリインターフェースがそのバージョン１．５．２ にあること （インターフェースの供給中に表現される特性） ；あるいは、そのバージョンが少なくとも１．０．０ であるが、バージョン１．０．４ ではない （それが不可避的な「バグ」を有することが知られているため） メモリインターフェースに対するリクエストがあること （インターフェース・リクエスト中に表現される特性） を表現することが可能である。
【０１２１】
また、このインターフェースの内容 （特性および方法） は、この目的のために本出願人により作成された言語を用いてプログラマにより書かれた記述を構成する。
【０１２２】
この言語は、従属性のコンパイラにより２進形でコンパイルされ、その２進形は、そのコンポーネントのコードおよび付随データと同じ容量で、モジュールにより構成される実行可能なコンポーネントの内部に含まれる。
【０１２３】
この２進形は、要求された機能に応じて複数のコンポーネントを相互リンクさせるように、実行時に（ｏｎ ｅｘｅｃｕｔｉｏｎ）システムにより容易に利用可能である。
この言語はまた、そのコンポーネントが含んでいるコードがどのタイプであるか （「システム」またはその他、「受動的」 （ライブラリ） もしくは「能動的」 （アプリケーション） 、等） 、およびある所定ファンクションにアクセスできるのがどのタイプのコードであるか （例えば、「システム」呼出し者（ｃａｌｌｅｒ）に対してシステムの「危険」ファンクションを制限することを可能にする） を明記するのにも使用される；これにより、最も最適な通信手段を選択することが可能となる。
【０１２４】
【コンポーネント類−作成とシステムへのロード】
次に図６を参照すると、本発明に係るシステムのある１つのコンポーネントの作成工程が、本発明に係るシステム内でのその実施と一緒にそこに説明されている。
【０１２５】
この図６は、各カラムが本発明に係るシステムのコンポーネントの作成および展開に使用される各種要素を示す論理チャートである。従って、この表は、左から右へ下記のカラムからなる：
・コンポーネントそれ自体に対応する２つのカラム ”ＣＯＭＰ” 。最も左側のカラム ”ＩＮＴ”はインターフェース部に対応するのに対し、次のカラム ”ＩＭＰ”は実現部に対応する。
【０１２６】
・コンポーネント・コンパイルファイルであるメイクファイルのためのカラム ”ＭＦ” 。
・コンポーネントのコンパイルのために本出願人により特別に開発された要素である従属性コンパイラ（ｄｅｐｅｎｄｅｎｃｉｅｓ ｃｏｍｐｉｌｅｒ） であるコンポーネント設計要素に対応するカラム ”ＣＯＭＰＩＬ ＤＥＰ” 。
【０１２７】
・そのコンポーネントのコードを構成する既知タイプのファイルのコンパイラに対応するカラム ”ＣＯＭＰＩＬ ＣＯＤＥ”。
・リンク・エディタ （連係編集プログラム） に対応するカラム ”ＬＩＮＫ” 。
【０１２８】
・あるプロジェクト （後で定義する概念） の設計中に役割を担う本発明に係るシステムの特定の開発ツールに対応するカラム ”ＫＢＩＭ” 。
・従属性管理プログラム （またはＧＤ） と呼ばれる、本発明に係るシステムの特定の１コンポーネントに専用のカラム ”ＧＤ” 。このコンポーネントは、後でわかるように、本発明に係るシステムのコアを構成するが、現状技術のカーネルおよびマイクロカーネルとは完全に異なるものである。
【０１２９】
・本発明に係るシステムの特定の複数のコンポーネント、ローダ、に対応するカラム ”ＬＯＡＤ” 。これらのコンポーネントは、システムのコンポーネントをターゲットのランダムアクセスメモリ領域内にロードするのを可能にする。
【０１３０】
・上述した各種段階の表示を与える右側のカラム。
◆コンポーネントの作成
ここで、我々は「プロジェクト」の一般的概念を定義する。プロジェクトは、本発明に係るシステム内で共通の或る目標を有する一組のコンポーネント群を意味する。従って、１つのプロジェクトは１つのアプリケーションに対応することができるが、より一般的には、あるコンピュータシステムにより実行されうる、アプリケーションとは異なる任意のタイプのプログラムにも対応することができる （例えば、周辺管理プログラム） 。
【０１３１】
本発明に係るシステム内で実施するためのプロジェクトを作成する前に、６０１ で機能分析 （ＡＦ） の段階を常法により行う。
この段階は、要求される各種コンポーネント、それらのそれぞれの機能、およびこれらの機能のそれぞれに関連するニーズ （他のコンポーネントにより提供されなければならない機能） を定義することを可能にする。後でわかるように、プロジェクトにいくつかの機能を付与するためにシステム内に既にロードされているコンポーネントを使用することができる。
【０１３２】
この事前分析を行って、コンポーネントに関するニーズがわかったら、プログラマは各コンポーネントごとに工程 ６０２〜６０６ を順に行う。
・６０２ では、本出願人が開発した従属性言語でそのコンポーネントの特徴が記述されているコンポーネントのインターフェース・ソースファイルを作成する。この言語の特徴とその主な可能性は本明細書において後で説明する。
【０１３３】
・６０３ で、プログラマは次にコード、即ち、そのコンポーネントの機能を提供するのを可能にするソースファイルを、既知タイプのものでもよい１または２以上の言語で作成する。この工程中に、そのコンポーネントによりエクスポートされるファンクションは、プロトタイプに関してのみ定義され、対応するコードは書き込まれない。
【０１３４】
ある機能は、進行中の手続きをターゲットのプロセッサ、図形表示装置等へのそれらのアクセスを管理するようにスタートアップする際に、引き受けるべき処理または操作 （機能の記述はフランス語で記述されよう） 、例えば、メモリの管理、に対応することが明記される。我々がファンクションを呼出すのは、やはり処理操作を引き受けるソフトウェアコード部分である。ファンクションは、機能 （従って、その名称） のプログラミング言語へのソフトウェア翻訳である。
【０１３５】
全てのプログラミング言語において、ファンクションは我々のシステムと非常に類似のやり方で引き受けられる。それは下記を含む：
‥入力および出力パラメータ （それらの名前およびそれらのタイプ） を定義するプロトタイプ。このプロトタイプは我々のコンポーネントのインターフェース部にリンクさせることができる （その役割は同一） 。
【０１３６】
‥コード部分。この部分は、データ上で処理を行い、従って、出力時に供給されるべき結果を決めることを可能にする。
また、ファンクションのプロトタイプがファンクションの名前、その入力パラメータ （それらの名前およびそれらのタイプ） 、ならびにそのファンクションにより復帰された結果の情報のタイプを定義することも明記される。
【０１３７】
・６０４ でプログラマは特に下記を明記したメイクファイルを作成する：
‥前工程６０３ 中に作成されたソースファイルに用いた言語、
‥そのコンポーネントの実現部に対応するソースファイル、
‥コンパイル・オプション。
【０１３８】
・６０５ で、プログラマは、従属性のコンパイラと使用した言語に対応するコンパイラとで、下記を含む該コンポーネントのプロトタイプを作成する：
‥従属性のコンパイラによる、６０２ で作成されたコンポーネントのインターフェース・ソースファイルのコンパイルから生じたオブジェクト・インターフェース。このインターフェースのコンパイルのために、従属性のコンパイラはインターフェースのソースファイルのテキストを解析し、その一貫性を検証し、次にそれをＧＤにとって理解可能な２値データに翻訳する。従属性のコンパイラは、そのインターフェースで引用され、該コンポーネントに供給されるべき機能を呼出すためのファイルを自動的に形成する。
【０１３９】
これらのファイルは、従属性のコンパイラにより形成された「組込み」タイプ（”ｉｎｃｌｕｄｅ” ｔｙｐｅ）のファイルである。各コード実施言語ごとに１つの「組込み」ファイルが形成される。これらのファイルの役割は、そのコンピュータシステム内で、名前づけスペース （即ち、対応がそれと関連づけられる文脈） を、該コンポーネントのそれの外部で、かつそれとは別個に定義することであり、それによって、コンポーネントがそのインターフェース内で要求した機能にアクセスすることが可能となる。従って、これらの「組込み」ファイルのそれぞれは、インターフェース内でなされたリクエストを、その「組込み」ファイルが関連づけられる実施言語が使用することができる構造および名前に翻訳するように、コンポーネントのインターフェースにより呼出されることができる構造を定義する。
【０１４０】
‥６０３ で作成された各ソースファイルのためのオブジェクト・ファイル；この接続部では、各オブジェクト・ファイルはそのファンクションが完全には書き込まれていないプロトタイプ・ソースファイルに対応する。
【０１４１】
・６０６ では、プログラマは次に、該コンポーネントの実現部のオブジェクト・インターフェースとオブジェクト・ファイルとの間のリンクを、実行可能なコンポーネント・プロトタイプを形成するように編集する。
【０１４２】
次に、６０７ で、構想したプロジェクトのためにこうして開発されたプロトタイプ・コンポーネントのセット全体について、ＫＢＩＭが完全性試験（ｉｎｔｅｇｒｉｔｙ ｔｅｓｔ）を行い、作成されたプロジェクトが無矛盾で閉じている （即ち、プロジェクトに要求された全ての機能がこのプロジェクト内に存在している） ことを検証する。
【０１４３】
完全性試験中に、ＫＢＩＭには全てのコンポーネントのインターフェースのリストと記述が供給される。従って、ＫＢＩＭは、これらのコンポーネントの中から、そのプロジェクトに要求された機能を遂行するコンポーネントをサーチすることができる。いくつかのコンポーネントが要求された機能を遂行する場合には、ＫＢＩＭはこれらのコンポーネント間での選択をプログラマに迫る。ＫＢＩＭにより自動的に見出されたか、またはプログラマにより指定されたコンポーネントは次いで、プロジェクトを構成するコンポーネント群に追加される。この新たなコンポーネントは、ＫＢＩＭが解明しようとする他の機能を要求することもできる。こうして、ＫＢＩＭは、あるプロジェクトに要求された複数の機能の大部分を自動的に解明することを可能にする。
【０１４４】
プロジェクトが正しく閉じられていない場合、ＫＢＩＭはプログラマに矛盾を表示するエラーメッセージを発行し、プログラマはアプリケーションの一部のコンポーネントの修正および／もしくは何らかのコンポーネントの追加を行うように工程 ６０２〜６０６ の手順を再実行することになる；プロジェクトが無矛盾で閉じられている場合、プログラマは６０８ で、そのコンポーネントの実現部のコードのファンクションのプロトタイプを、それらのファンクションの完全バージョンをこの実現部のソースファイル内に書き込むことによって完成させる。
【０１４５】
６０９ では、プログラマはメイクファイルを展開して、そのコンポーネントの機能の実行を可能にするオブジェクト・ファイルをコードに対して作成するように、各コンポーネントを別々にコンパイルする。この工程中に、メイクファイルは従属性コンパイラならびにコードを公式化するのに用いた１または２以上の言語のコンパイラの関与を生ずる。工程６０８ および６０９ は、現在開発中のプロジェクトのコンポーネントごとに繰り返される。
【０１４６】
６１０ で、プログラムは次にリンクエディタを展開して、各コンポーネントごとに実行可能なモジュールを作成する。このモジュールはコンパイル工程６０５ および６０９ で作成されたオブジェクト・ファイルのセットと関連づけられる （オブジェクト・インターフェースは工程６０５ で作成されたものであり、コードに関連づけられたオブジェクト・ファイルは工程６０９ で作成されたものである） 。
【０１４７】
コンポーネントのモジュール内でのカプセル化に対応するこのリンク編集中に、エディタはそのプロジェクトの各種インターフェースにより供給される全ての機能が関連ソースファイル中に実際に完全に記述されており、かつコンパイルされたことを検証する。
【０１４８】
◆コンポーネントの宣言
こうして、プロジェクトの各コンポーネントごとに実行可能な１つのモジュールが作成されたら、プログラマは、これらのコンポーネントがシステムによる考慮に入れられるように、それらのコンポーネントの存在を宣言しなければならない。この宣言は６１１ で行われ、この工程中に、プログラマは各コンポーネントを１つの「ローダ」に対して宣言する。ローダそれら自体は本発明に係るシステムの特有のコンポーネント群である。
【０１４９】
この工程６１１ 中に、あるコンポーネントの宣言相手であるローダは、そのローーダに宣言された複数のコンポーネントのセットを一緒に集めた、該ローダの個別リスト内に、そのコンポーネントを格納する。
【０１５０】
この工程６１１ はまた、現在開発中のプロジェクトに全体的に関係する工程でもあり、あるプロジェクトに関して開発された複数のコンポーネントのセットは、少なくとも１つのローダに対して宣言される。ここで、各ローダは、このローダに関連づけられたコンポーネントが格納されるコンピュータシステムの媒体 （ディスク、ネットワーク等） に対応する。
【０１５１】
◆コンポーネントのシステムへのロード
以上に説明したのは、いくつかのコンポーネントを含みうる１つの「プロジェクト」を作成および宣言する工程であった。次に、以下には、図６の下部に示されている、これらのコンポーネントの展開について説明する。
【０１５２】
６２０ では、１つのコンポーネントＣ１が、それが必要とする機能Ｆ１を呼出す。
この呼出しには、下記の２つの可能性がある：
・機能Ｆ１を、コンポーネントＣ１のインターフェースにおける ”ｌｏａｄｔｉｍｅ” 特性 （”ｌｏａｄｔｉｍｅ”特性については上述した） により定義する。この場合、ＧＤは、コンポーネントＣ１のロード前にこの機能Ｆ１を遂行するコンポーネントをサーチして、システム内にロードすることになる。
【０１５３】
‥このコンポーネントそれ自体が ”ｌｏａｄｔｉｍｅ” 機能を要求する場合には、ＧＤは、やはりコンポーネントＣ１のロード前に、この機能を遂行するのに必要なコンポーネントもロードすることになる。こうして、ＧＤは、それが遭遇することになる各種の ”ｌｏａｄｔｉｍｅ” 機能を遂行するのに必要な全てのコンポーネントを反復してロードすることになる（どのようにしてコンポーネントをシステム内にロードするかについては、後でさらに説明する）。
【０１５４】
・機能Ｆ１を ”ｒｕｎｔｉｍｅ”特性により定義する （”ｒｕｎｔｉｍｅ” 特性については上述した） 。その後、コンポーネントＣ１は、ＧＤにより供給される別の機能 ”ｄｅｐｍｇｒ” に明示コール（ｅｘｐｌｉｃｉｔ ｃａｌｌ） をして ”ｒｕｎｔｉｍｅ”機能Ｆ１を呼出さなければならない。こうするためには、”ｄｅｐｍｇｒ”機能は、Ｃ１のインターフェースの ”ｌｏａｄｔｉｍｅ” 特性と共に宣言されることが絶対に必要であり、それにより、Ｃ１がロードされて初期化された後すぐに、このインターフェースを使用することが可能となる （上の ”ｌｏａｄｔｉｍｅ” 機能の処理を参照） 。
【０１５５】
その後、Ｃ１は、６２０ で呼出された ”ｒｕｎｔｉｍｅ”機能Ｆ１を、それがこの機能を使用すべき正確な時点でインポートすることができる。その後、この機能Ｆ１を遂行するコンポーネントが、ＧＤによりロードされることになる。このコンポーネントが、それがロードされる時点で或る機能を必要とする （そのインターフェース内の宣言された機能 ”ｌｏａｄｔｉｍｅ”）場合には、この ”ｌｏａｄｔｉｍｅ” 機能を遂行するコンポーネントもロードされることになる。
【０１５６】
こうして、ＧＤは、それが遭遇する各種の ”ｌｏａｄｔｉｍｅ” 機能を遂行するのに必要な全てのコンポーネントを反復してロードすることになる（どのようにしてコンポーネントをシステム内にロードするかについては、後でさらに説明する）。従って、６２０ で最初に要求された機能Ｆ１がＣ１に対して利用可能となるのは、その解析中に遭遇した全ての ”ｌｏａｄｔｉｍｅ” 機能も解明された場合だけになろう。Ｃ１によるロード時に要求された何か１つの機能 （宣言された機能 ”ｌｏａｄｔｉｍｅ”）が解明されない場合には、Ｃ１はロードされないことになる。実際、Ｃ１は、それが要求する別の機能を使用することができないため、その機能上の使命を遂行することができなくなる。
【０１５７】
Ｃ１がインポートする必要がある機能が、Ｃ１が属し、かつそれと共にＣ１がシステムのローダの１つに対して宣言されるプロジェクトのコンポーネントの１つにより遂行されない場合には、後でわかるように、システムは、別のプロジェクトにおいて、この機能をＣ１に供給することを可能にするコンポーネントを識別する。
【０１５８】
これらの目的のため、システムのランダムアクセスメモリに永久にロードされるＧＤは、その「リンクグラフ（ｌｉｎｋ ｇｒａｐｈ）」を介して、このリンクグラフのコンポーネントのいずれかのインターフェース・オブジェクト・ファイルが、このコンポーネントがＣ１により要求された機能を供給することを示すか否かについてサーチする。
【０１５９】
こうするために、ＧＤは、インターフェースファイルの「２進」バージョンを解釈（ｉｎｔｅｒｐｒｅｔ） する。このバージョンは、実行可能なコンポーネント中に格納されていて、実行時には「ローダ」コンポーネントによってＧＤにロード／伝送される。
【０１６０】
ＧＤはまず、要求 （インポート） されたものと同じ名前を有するインターフェースをサーチする。それを見つけた時には、ＧＤは次に、それらのインターフェース内で、要求された機能の全ての特性が存在することと、あらゆる制約および条件 （０．６．２ より高いバージョン、等） が満たされていることを検証する。
【０１６１】
ＧＤリンクグラフは、システムにロードされているコンポーネント類、即ち、工程６１１ に関して上述したように宣言されているだけでなく、そのオブジェクト・インターフェースファイルがターゲットのランダムアクセスメモリ領域中にインポートずみであり、かつ供給および／もしくは要求された機能を交換するようにリンクグラフの他のコンポーネントに接続されているコンポーネント類、のリストである。
【０１６２】
従って、ターゲットのランダムアクセスメモリ領域内に格納されているリンクグラフは、ロードされたコンポーネント類の瞬時イメージであり、このリンクグラフは動的に適合させることができる。このリンクグラフは一意的であり、ＧＤと関連づけられ、ＧＤはこのリンクグラフの情報にアクセスできる。
【０１６３】
工程６２１ 中にＧＤが、Ｃ１により呼出された機能がリンクグラフのコンポーネントのいずれかにより供給される （そのコンポーネントを「呼出されたコンポーネント」Ｃ２と称し、一方、Ｃ１は「呼出しコンポーネント」である） と決定した場合には、それは、６２７ でコンポーネントＣ１中にコンポーネントＣ２の特徴をインポートすることにより、このコンポーネントＣ２とコンポーネントＣ１との間の通信チャネルを確立する。
【０１６４】
より正確には、ＧＤは、引き受けるべきインポートに関してビュー （視点） を提供する「ビュー」と呼ばれるデータ構造をＣ１のために構築する。この「ビュー」は、インポートされるファンクションに対する （またはそれらのファンクションに到達するのを間接的に可能にするコード、例えば、システムコール、スレッドの移行等に対する） 特性ならびにポインタの値を含む。この「ビュー」は、「組込み」ファイル内で従属性のコンパイラにより形成された要素から直接的に発生する。
【０１６５】
一方、ＧＤが６２１ において、Ｃ１により呼出された機能がリンクグラフのコンポーネントのいずれによっても供給されないと決定した場合には、ＧＤはシステムのローダのリスト類を次々と問い合わせて、これらのローダに対して宣言されたコンポーネントのいずれかがＣ１により要求された機能を提供するか否かを決定するようにする。このローダの問い合わせは工程６２２ で示される。
【０１６６】
この問い合わせ中、ＧＤは、各「ローダ」が見るコンポーネント類をリスト化するのに必要なファンクションを有する「ローダ」機能を用いる。この「ローダ」機能は、ＧＤが、そのローダの１コンポーネントによりエクスポートされる機能を、インポートすることが求められている機能と比較するのを可能にする。それはまた、ＧＤが、ローダが関係づけられている媒体からターゲットのランダムアクセスメモリへの個々のコンポーネントのロードおよびアンロードを行うことも可能にする。
【０１６７】
本発明に係るシステムのローダのそれぞれは、コンポーネントの格納を可能にする特定の媒体と関連づけられていることを明記しておく。従って、各ローダは、例えばＣＤ−ＲＯＭ型の１つのメモリディスクと、または任意の他の記録支持体と関連づけることができよう。複数のローダは、特に図７を参照すると例示されていよう。
【０１６８】
このような１つのコンポーネントがシステムのいずれかのローダのリスト中に位置する場合 （工程６２３）、そのリストがそのようなコンポーネントを含んでいる第１のローダが、６２５ で、識別されたコンポーネントＣ２のオブジェクト・インターフェースを従属性管理プログラムに伝送し、ＧＤそれ自体は、６２６ で、このコンポーネントＣ２の「ビュー」をコンポーネントＣ１に伝送する （工程６２７）。
【０１６９】
Ｃ２の「ビュー」は、コンポーネントＣ２のロードによって、ＧＤにより動的に作成されるシステムメモリ領域内にＧＤによって既に格納されている。このメモリ領域は、このコンポーネントがアンロードされると同時に破壊されることになる。この領域は、それにアクセスできるコンポーネントと同じアドレス空間内に位置する。
【０１７０】
一方、要求された機能を供給するコンポーネントをローダのいずれかのリスト中で識別するためのＧＤのサーチが、工程６２３ において実りのある結果を生まずに終わった場合には、システムは６２４ で停止する。
【０１７１】
いずれにしても、システムのランダムアクセスメモリ中へのコンポーネントＣ１のロードは、上述したように、コンポーネントＣ１の操作のために要求される機能Ｆ１を提供するコンポーネントＣ２を探すＧＤによる自動サーチを生ずる。
【０１７２】
また、コンポーネントＣ１が、１つだけでなく、いくつかの機能を呼出す場合には、ＧＤは同様に、これらの要求された複数の機能を提供する複数のコンポーネントを探す自動サーチを行うことになる。
【０１７３】
本発明に係るシステムは、既知システムに比べて、より大きな程度の柔軟性を提供することは認められよう。
実際、複数のエンティティと共に構築された既知システムの場合、プログラマは各所定の呼出しエンティティごとに、該呼出しエンティティの動作に必要で、この呼出しエンティティの適正な動作のためにシステム内にロードしなければならない、システムの残りのエンティティのリストを明記しなければならない。
【０１７４】
従って、このような既知システムの場合、エンティティのニーズ（要求）は一般に機能に関して表現されるのではなく、特定のエンティティに関して表現される（これは、例えばＪａｖａ（登録商標）言語についてあてはまる） 。
【０１７５】
また、本発明の場合、いくつかの異なるコンポーネントのそれぞれは、それらの異なるコンポーネントが同じ機能を提供する限り、１つの呼出しコンポーネントＣ１と関連づけられる傾向がある。
【０１７６】
また、本発明の別の利点は、それらのコンポーネント類に関連づけることができる基準から派生し、これらの基準は、第１のコンポーネントにより要求されたある機能を提供するコンポーネント類を探すＧＤの自動サーチ中にＧＤにより考慮される。
【０１７７】
実際には、このコンポーネント類のサーチ中に、ＧＤは要求された機能を提供するコンポーネントだけを探すのではなく、より正確には、本明細書で前に述べた基準に従って表現された特定の条件と関連づけてその機能を提供するコンポーネントを探すのである。
【０１７８】
既存の言語 （例えば、Ｊａｖａ（登録商標）言語タイプ） の場合、実際、プログラマは呼出しエンティティと呼出されるエンティティとの間の明示リンクを絶対に作成しなければならない。従って、この種の既知システムの展開は、本発明と同程度の柔軟性をどのようにしても提供しないことは明らかであり、ＧＤに選択の可能性を与えるように、要求された機能を提供するコンポーネントを異なるやり方で同じ機能を遂行する別のコンポーネントで置換したり、或いはその機能を遂行する新たなコンポーネントを追加したりすることがある、メンテナンスやアップグレード （例えば、バージョンを高くするための） に対して、本発明の方がずっと適している。
【０１７９】
従って、本発明は、１つだけ、または２以上の、所望のコンポーネントを随意に置換することができる、極めてアップグレード性の高いシステムを構築することを可能にする。
【０１８０】
各置換されたコンポーネントは、置換された古いコンポーネントにより既に提供されていた機能を提供する。
しかし、この機能を遂行するための特定の手段は、それらがソフトウェアおよび／またはハードウェアのいずれであろうと随意に適合させることができる。
【０１８１】
各種サイト上にインストールされたシステムのネットワークのメンテナンス、またはその他、そのアップグレードのために中心サイト （中心側） に物理的に戻すことを人が望まない携帯装置セット （例えば、携帯電話または携帯ツール） のメンテナンス、といったアプリケーションの枠組み内において、この可能性は特に有益である。
【０１８２】
例えば、上述したタイプの装置にインストールされたアプリケーションは、ある中心サイトから、これらの装置上に１または２以上の新たなコンポーネントをダウンロードするだけでアップグレードすることができ、そうするのに、あらゆる場所に散らばっている可能性がある装置を物理的に移動する必要がなくなる。
【０１８３】
さらに、これらのコンポーネントの交換は、それらを展開するコンピュータシステムの再コンパイルを必要としない。
Ｃ１が要求した機能を提供するコンポーネントＣ２が識別され （恐らく、（１） のインターフェースにより要求される条件を満たす基準によって） 、かつＣ２の特徴が６２７ でＣ１にインポートされた場合には、コンポーネントＣ２がリンクグラフの一部を既に形成しているか否かに応じて、従属性管理プログラムが異なる動作をすることになる （工程６２８）。
【０１８４】
Ｃ２が既にリンクグラフに属している場合には、ＧＤは、Ｃ１とＣ２との間の通信チャネルを作成するために直接工程６３３ に進む。こうするには、システムは後述する４種類の通信モードのいずれかを使用するか、或いはＣ１および／またはＣ２のインターフェース内で明記された特徴のファンクションとして特別に作成された特定モードを使用する。
【０１８５】
→直接呼出し （ダイレクトコール） ：
これは最も速い方法である。要求された機能または方法は直接呼出され、その結果は直接戻される。中間コードは全くない。２つのコンポーネントが同じマシン上の同じアドレス空間内にあり、かつ同じ特権レベルにある場合に、従属性管理プログラムはこの手段を選択する。
【０１８６】
アドレス空間は、コードアドレスまたはデータアドレスがこの領域にアクセスする全てのコンポーネントに対して意味を有する論理メモリ領域であると定義される。そのコードまたはデータへのポインタが、１つのコンポーネントから他のコンポーネントへとそのまま伝送されることができ、その値を修正することなく、それは同じデータへのアクセスを可能にする。
【０１８７】
本発明において、「アドレス空間」なる用語はまた共通特権の意味も包含し、アドレス空間は、同じ特権レベルを有する「空間」または１クラスのオブジェクト群を定義し：従って、１つおよび同じアドレス空間の指されたオブジェクト（ｐｏｉｎｔｅｄ−ａｔ ｏｂｊｅｃｔｓ）へは、各種のコンポーネントが同じようにしてアクセスすることができる。
【０１８８】
また、こうして、例えば、より低い特権レベルの「ユーザ」空間や、より高いレベルの「スーパバイザ」空間を定義することも可能である。
各手続きの「ユーザ」空間と「スーパバイザ」 （システム） 空間との間のポインタの一貫性 （無矛盾） は、 （同時に両方の空間にアクセスできるコンピュータシステムのプロセッサ） によりコンパイルされるが、「ユーザ」コードは「スーパバイザ」空間内に位置するデータを参照することはできない。
【０１８９】
特権はコンポーネント間のアクセスの可能性である；ソースインターフェースでは、下記の特権レベルを使用することができる。
【０１９０】
【表５】
2004503866.tif 000008
【０１９１】
あるコンポーネントにこれらの特権レベルのいずれかを割り当てるため、プログラマは、下記タイプのテキスト内部に含まれている、そのコンポーネントのモジュールの定義内に、対応するパラメータを固定する：
【０１９２】
【数３】
2004503866.tif 000009
【０１９３】
即ち、一般に、個々の各コンポーネントにある所定の特権レベルを関連づけることが可能であり、その特権レベルは、このコンポーネントの他のコンポーネントへのアクセスの可能性を、該他のコンポーネントのそれぞれの特権レベルのファンクションとして決定する。
【０１９４】
換言すると、あるコンポーネントへの特権レベルの関連づけは、このコンポーネントに、ある種のコンポーネントのインターフェースによって提供される機能を「見る」可能性を、これら他のコンポーネントに実際に関連づけられた特権レベルのファンクションとして付与する。
【０１９５】
また、後でわかるように、各種コンポーネントに個別的に関連づけることができる特権レベルにより確立される、コンポーネント間のアクセスのこの階層構造を、ある種の特定のコンポーネントと個々に関連づけられた演算子によって「短絡回路化」する （回避する） ことができる。
【０１９６】
このような呼出しの例は次の通りである：
・スーパバイザ・コンポーネントからスーパバイザ・コンポーネントへ、
・ユーザ・コンポーネント （即ち、より低い特権レベル） から、同じアドレス空間内のユーザ・コンポーネントへ （そのようなアプリケーションは共用かつ受動ファンクションのライブラリを管理するコンポーネントを用いる） 。
【０１９７】
この方法は、メモリ・コンポーネントが保護を付与しない場合に採用される唯一の方法であり、これは恐らく、このシステムを製品として構築するエンジニアが選択する方法であり、こうすると、保護がないため、極めて高速のシステムとなる。
【０１９８】
メモリ・コンポーネントは、このコンポーネントが「システム」型のたった１つのアドレス空間を提供する場合に、保護を「付与」しない。この種のメモリ管理は保護 （同じ空間内で動作し、他のコンポーネントに属するコードまたはデータを破壊または修正する可能性のある全てのもの） を提供しないが、”ＭＭＵ”（メモリ管理ユニット） を全く有していないある種のターゲット上で可能な唯一のものである。
【０１９９】
→システムコール
アピールはシステムコールに向けられる。システムコールは、パラメータをユーザ・スタックからスーパバイザ・スタックに転送し、特権のレベルを変化させ、呼出し （コール） をなし、より低い特権レベルに戻し、そして結果を直接復帰させる。
【０２００】
この方法は、ユーザ・コンポーネント （非特権化） がスーパバイザ・コンポーネントの機能を、この機能が非特権化コンポーネントにそれを使用することを許可することを条件として要求する場合に選択される。
【０２０１】
この許可は、キーワード ”ｐｒｏｍｏｔｅ”を介して、従属性記述言語のレベルでなされる。また、より一般的には、下記のキーワードを１つのコンポーネントに関連づけることができる （本出願人により開発された言語の構文では、キーワード類は、その動作方式をそれらが変更すべき特性または方法の前に単に接頭辞として付加されるだけである） 。
【０２０２】
【表６】
2004503866.tif 000010
【０２０３】
即ち、キーワード ”ｐｒｏｍｏｔｅ”を介して展開される、上に示唆した許可により、あるコンポーネントが、その特権レベルがそれにアクセスを許さない別のコンポーネントにアクセスするのを個別的に許可するために、他所で既に確立された特権レベルを「短絡回路化」することが可能となる。
【０２０４】
→スレッドの移行
本発明に係るシステムは、実行スレッドの論理管理 （識別子、優先順位、システムスタック等） を、その物理的管理 （プロセッサコンテキスト、ユーザスタック、そのスレッドが収容されているアドレス空間、等） から切り離す。
【０２０５】
あるコンポーネントが別のアドレス空間に位置するファンクションを要求し、それを同期的に行う （呼出し側は結果まではブロックされる） 場合、呼出し側は呼出された側の中に「移行」し、その処理を行う。
【０２０６】
このために、スレッドの論理部分は、その現在の物理的部分を「積み重ね」、呼出された側のアドレス空間内に作成された新たな物理的部分に加わる。
その後、所望の機能のコードが、呼出された側のコンテキスト内で （即ち、同じアドレス空間および同じ含有手続き内で） 、但し、呼出し側の論理スレッド内で実行される。ファンクションが終了したら、呼出しスレッドは、その元の物理的部分を「積み重ねから取り出し」、再び呼出し側に「移行」させる。
【０２０７】
このスレッド移行コードは、パラメータの両方向への送信、パラメータとして供給されたメモリ領域、ストリング等の複写や再マッピングにも責任をもつ。
このメカニズムは、メッセージを構成し、そのメッセージを呼出されたコンポーネント内のスレッドに送信し、呼出し側のスレッドを中断し、呼出された側でメッセージを分解し、所望のファンクションを実行し、結果に関する別のメッセージを再構成し、呼出し側を復活させ、呼出された側を再び中断することからなる、従来のずっと高価な方法を避ける。
【０２０８】
このメカニズムはまた、優先順位の反転 （本発明では、呼出された機能は呼出し側の優先順位で実行される） 、資源の計算 （計算時間が呼出し側でカウントダウンされる） ならびに、呼出されたコンポーネントのスレッド類の「プール」を保持する必要性、といったメッセージの同期移動に関係する多くの問題も回避する。前記プールのスレッド類は、呼出しを受けるまでは、不必要なメモリ資源を取りながら休眠しており、その後、呼出しの洪水があるとスレッドの数は不十分となる （本発明では、呼出し側は呼出された側に移行し、常に正確な数の要求されたスレッドがある） 。
【０２０９】
この方法は、アドレス空間の外側での最も普通の場合の呼出し：同じマシン上での同期呼出し、を大いに最適化する。
→メッセージの移動
この方法が組織的に採用される、例えば、マイクロカーネルに基づくシステムの場合とは異なり、該方法は、下記のような、上記カテゴリに含まれない呼出しに対してだけ使用される：
・非同期構内 （ローカル） 呼出し （呼出し側が、結果までの間ブロックされたままではない） 、
・別のマシンへの遠隔呼出し。
【０２１０】
メッセージの移動は、メッセージ内に供給されたパラメータをコード化し、メッセージを宛先コンポーネントに経路指定 （ルーティング） し、それを復号 （デコード化） し、ファンクションを実行し、結果を別のメッセージ中に格納し、呼出し側に戻すことからなる。この方法は、上述した通り、何らかの方法でのネットワークパケットの構築を必要とする、非同期呼出し （結果メッセージが後で送られる） や遠隔呼出しに特に適合している。
【０２１１】
図６を参照した説明に戻ると、１つの通信チャネルの作成が、呼出されたコンポーネントＣ２の実現部において呼出しコンポーネントＣ１を記録するためのファンクションの呼出しと関連づけられる。
【０２１２】
Ｒｅｇｉｓｔｅｒ（）と呼ばれるこのファンクションは、システムの全てのコンポーネントにより供給される「コンポーネント」機能の一部を、それら自体の特定の機能に加えて、形成する。この「コンポーネント」機能は下記の４つのファンクションを含む：
・初期化、
・脱初期化（ｄｅｉｎｉｔｉａｌｉｚａｔｉｏｎ）、
・記録、
・脱記録（ｄｅｒｅｃｏｒｄｉｎｇ） 。
【０２１３】
今、ＧＤが６２８ で、コンポーネントＣ２がリンクグラフの一部を形成していないと決定した場合、６２９ で、ＧＤはこのコンポーネントＣ２のローダを呼出して、Ｃ２をターゲットのランダムアクセスメモリ中に持っていき、６３０ でＣ２を初期化するためのファンクションを呼出し、６３１ でリンクグラフを更新するようにする。
【０２１４】
かくして、図７はリンクグラフＧ を示し、このリンクグラフＧ の中に、ＧＤは第１のローダのメモリ位置７２から１つのコンポーネントまたは１セットの複数のコンポーネントＰ２をインポートすることができ、こうして、リンクグラフ中に既に存在しているコンポーネントＣ１ （Ｃ１は、それがその一部を形成するプロジェクトＰ１を持つ別のローダのメモリ領域７１から既にインポートずみ） を、ローダの中からサーチする工程６２３ 中にＣ１が要求する機能を与えるとしてＧＤにより識別された呼出されたコンポーネントＣ２に接続することが可能となる。
【０２１５】
実際、６０７ でＫＢＩＭにより行われる完全性試験 （図６参照） 中に、ＫＢＩＭはあるコンポーネントにより呼出された各機能が、厳密には１つの同じプロジェクトの１つのコンポーネントによって提供されないが、より一般的にはそのソフトウェアシステム中にロードされた１つのコンポーネントにより提供されることを検証することを想起されたい。
【０２１６】
再び図６に戻ると、工程６３１ は既に説明した工程６３３ につながる。
この場合も、コンポーネントＣ１により呼出されたコンポーネントＣ２のロードは記述されたのに対して、コンポーネントＣ１はそれ自体は別のコンポーネントにより呼出されたこと、およびシステムをブートする時にそれらの機能の呼出しを開始することが必要であったことはいうまでもない。
【０２１７】
この目的のため、アプリケーションを開始する時に、ＧＤは「対話」機能を要求し、この機能を供給するコンポーネントをサーチする。ＧＤはまた、この機能を要求するコンポーネントをインポートすることもできる。どの場合でも、「対話」機能は別のコンポーネントを呼出し、その別のコンポーネントが今度は少なくとも１つの他のコンポーネントを呼出すであろう。
【０２１８】
【従属性管理プログラム】
従属性管理プログラム（ｄｅｐｅｎｄｅｎｃｉｅｓ ｍａｎａｇｅｒ）が本発明に係るシステム内に永久にロードされるコンポーネントであることは既に述べた。それは、１つのアプリケーションを構成する各種コンポーネント間のリンクを構築することを可能にし；これらのリンクはそれらのコンポーネントのインターフェースから確立される。
【０２１９】
本発明の有利な側面によると、アプリケーションおよびシステムの動作に関して有用なコンポーネントだけがロードされ、こうして必要な資源が最適化される。この最適化は下記モードのいずれかに従って達成することができる。
【０２２０】
◆実行中のコンポーネントの自動ロード
１つのコンポーネントを実行させるようにロードする時に、従属性管理プログラムはそのインターフェース内に表現されているようなその従属性を分析して、その中に表現されている全ての従属性を自動的に解明しようとする。即ち、それが必要とする全ての機能を持つコンポーネントを供給しようとし、さらに、こうして展開された全てのコンポーネントに同様に、それが必要とする機能を供給しようとすることにより、従属性のシステムを「閉鎖」しようとする。
【０２２１】
ＧＤは次に、その特性が ”ｌｏａｄｔｉｍｅ” であるインポートされたインターフェースを解明するコンポーネントをリンクグラフ中に自動的にロードし、さらにそれらの従属性を解明し、これらの各種コンポーネント間の通信チャネルをそれらのそれぞれの位置のファンクションとして作成する。
【０２２２】
こうして、上に定義した任意の通信モードに従って通信チャネルを作成することができ；それは、関連パラメータを持つ機能を呼出すことと、その機能により実施された処理から生ずる復帰 （戻り） 値を回収することとが可能な、任意のデータ伝送経路 （各通信モードに特有の） からなる。
【０２２３】
通信チャネルが作成されるとすぐに、それらのコンポーネントは相互に直接通信することができる。
◆コンポーネントの動的ロードおよびアンロード
インポートされたインターフェースが ”ｒｕｎｔｉｍｅ”特性を有する場合、このインターフェースを使用するコンポーネントが、このインターフェースを実施するコンポーネントのロードを要求することになるのは、このコンポーネントがそのインターフェースに関連づけられた機能を必要とする場合だけである。従って、この ”ｒｕｎｔｉｍｅ”特性は、既に述べた ”ｌｏａｄｔｉｍｅ” 特性に対する代替物となる。
【０２２４】
この管理は、ロードしなければならないインターフェースの実施の特性を、その機能を要求するコンポーネントをロードする時には知られていない動的パラメータのファンクションとして正確に決定することを可能にする。
【０２２５】
例えば、ある ”ｔｅｘｔ” コンポーネントがｃｏｄｅｃ インターフェースをインポートして、それが受取るファイルを圧縮解除 （復元） するようにでき、この ”ｔｅｘｔ” コンポーネントはいくつかのタイプのファイルを受取ることができる。
【０２２６】
１つのファイルの受取り中、”ｔｅｘｔ”コンポーネントは、このファイルの圧縮解除に適合したｃｏｄｅｃ インターフェースを、例えば、その拡張子のファンクションとしてサーチすることができる。こうするため、それは従属性管理プログラムのＱｕｅｒｙ（） 機能を使用し、サーチパラメータをそれに送る。
【０２２７】
次に、それは、Ｏｐｅｎ（）機能を用いて該コンポーネントをロードするように従属性管理プログラムに命令することができる。それは、その後、このコンポーネントのｃｏｄｅｃ インターフェースを用いてファイルを圧縮解除することができる。
【０２２８】
圧縮解除が終了したら、”ｔｅｘｔ”コンポーネントは、使用したｃｏｄｅｃ コンポーネントのアンロードを要求することができる。
こうして、１つのコンポーネントを動的にロードすることができる。この可能性により、コンポーネント類は、それらがある処理を行うのに必要である場合だけにロードすることが可能となる。その後、その処理が終了した後は、そのコンポーネントをアンロードすることができる。
【０２２９】
別の例によると、アプリケーションはそのロード中に画像 （イメージ） を表示するが、その後はこのフォーマットのイメージを処理する必要性がないか、または例外的にのみイメージを処理することができる。
【０２３０】
従って、このアプリケーションは、イメージフォーマットを処理するためのコンポーネントを動的にロードして、それにイメージを表示するようにファイル処理するよう要求した後、このコンポーネントをアンロードすることができる。このコンポーネントは、それが厳密に要求される場合だけにメモリ内にロードされるので、ある所定時点で引き受けるべき処理操作のファンクションとして、各種コンポーネントの中でメモリ資源を共有することが可能となる。
【０２３１】
従って、この方法は、必要なメモリ資源のかなりの縮小を可能にする。
従属性管理プログラムはまた、コンポーネント類のロードおよびアンロードを、それらの使用の統計量およびメモリ資源のファンクションとして自動的に管理することもできる。そうなると、この管理はアプリケーションのプログラマに対して完全に透明になる （気付かれなくなる） 。
【０２３２】
図８の図表は、メモリ資源の少ないシステム上でのコンポーネントの動的管理の利点を示す。この例では、アプリケーションはＧＩＦ とＪＰＥＧの２つのイメージを表示する。各イメージは逐次的に処理され、それにより複数のコンポーネントを動的にロードおよびアンロードすることが可能となる。
【０２３３】
この例において、コンポーネントの動的ロードおよびアンロードは、必要となる最大メモリ資源の減少を可能にする。
さらに、ほとんどの場合、このロードおよびアンロードは、性能に関して気付かれることがない。
【０２３４】
実際、コンポーネントのモジュールのサイズは小さい （数百バイトないし数キロバイトのオーダーのサイズ） 。従って、それらのメモリへのロード操作は、非常に高速で行われるものとなる。さらに、大部分のアプリケーションは順次処理操作を実行し、しばしば入力情報は人間のユーザにより供給され、出力情報がそのユーザに供給される。
【０２３５】
よって、人のスケールでは、１コンポーネントのロードとアンロードに必要となる数マイクロ秒は全く気づかれないが、図８に示した例の場合、操作は下記の順序に従って行われる：
・１つのイメージのロード （ＪＰＥＧコードのロード） 、
・このイメージのスクリーン上での表示、
・ユーザ、
・別のイメージのロード （ＪＰＥＧコードのアンロードとＧＩＦ コードのロード） 、・この別のイメージの表示。
【０２３６】
ロードおよびアンロード時間は、残りの処理操作に比べて、微々たる長さである。
◆従属性管理プログラムによる資源の最適化
従属性管理プログラムは、各コンポーネントごとに１つの利用カウンタを管理する。このカウンタは、そのコンポーネントの「インポータ（ｉｍｐｏｒｔｅｒ）」、即ち、そのカウンタが関連づけられているコンポーネントからある機能をインポートするコンポーネント、の数を計数する。コンポーネントは、その利用カウンタがゼロに減少したらすぐにアンロードされる。
【０２３７】
コンポーネントがもはや使用されない場合、従属性管理プログラムは、このコンポーネントのために用いられた資源を自動的に解放する。
従って、本発明は、システムの一般的な動作方式に負担をかけずに、システムにより展開される資源の特に効果的な最適化を可能にすることは認められよう。
【０２３８】
実際、既知のシステムは、一般にコンポーネント類の状態を検証するための周期的手段を展開し、この手段は、アンロードしなければならないコンポーネントを識別するよう定期的に「乗っ取る （ｔａｋｅ ｏｖｅｒ）」特定のタスクによって展開される。
【０２３９】
このような周期的な検証タスクは、コンポーネントの修正状態を良好な反応性で追跡することができないので、リアルタイムにはあまり適していない。
さらに、この種の動作方式は、検証タスクの存在のために、マルチタスク環境を要求する。
【０２４０】
周期的検証を展開するこの種の操作方式の１例がＪａｖａ（登録商標）言語に見られよう。検証タスクは「不要部分コレクタ（ｇａｒｖａｇｅ ｃｏｌｌｅｃｔｏｒ） 」タイプの要素を展開する。
◆ハードウェア要素が引き受ける機能に関する詳細
あるコンポーネントの実現部はコード （これはそのコンポーネントの機能を遂行するように１または２以上のプログラムを含む） に対応することができるが、電子回路を含むハードウェア要素に基づくハードウェア実施にも対応しうることは既に述べた。
【０２４１】
即ち、ある機能を、電子回路 （例えば、ビデオ圧縮解除回路） を使用することでそれを実施するコンポーネントＣ１によって引き受けることができる。しかし、この機能を、ソフトウェアだけに基づいてそれを実施する別のコンポーネントＣ１によって引き受けることもできる。あるアプリケーションに対して、その電子回路が実際に存在し、それが正確に動作する場合には、システムはそのコンポーネントＣ１を使用しよう。他方、その電子回路が存在しないか、それが正確には動作しない場合には、システムは、残りのコンポーネントには透明なようにして、別のコンポーネントＣ１’ を使用しよう。どの場合も、その機能は引き受けられる。
【０２４２】
同様に、ある機能が今日はソフトウェアコードにより引き受けられても、その後に、残りのコンポーネントに対して完全に透明なようにして、電子回路を用いてそれを実施する別のコンポーネントにより引き受けられることもある。
【０２４３】
図９の図表は、あるコンポーネントＣ１から、同じ機能をエクスポートする別のコンポーネントＣ’１ への置換を示す。
９００ に示すようにＣ１は現在実行中のコンポーネントであるが、Ｃ１との通信のためのチャネルを有し、従ってリンクグラフ内でそれにリンクされている別のコンポーネントＣ２が、９０１ でＧＤに、Ｃ１をＣ’１ と交換するように要求する。
【０２４４】
次に、ＧＤはＣ１に、その現状（現在の状態）を保存（セーブ）するように要求し （工程９０２ で） 、これは９０３ でＣ１により引き受けられる。ＧＤは次に、Ｃ’１ をロードし、初期化する（９０４および９０５）。
【０２４５】
Ｃ’１ のロードまたは初期化が正しく行われない場合 （工程９０６）、ＧＤはエラーを要求コンポーネントＣ２に戻す。
Ｃ’１ のロードと初期化が正しく行われた場合、ＧＤは９０８ で、Ｃ１の現状をＣ’１ に伝え、Ｃ’１ が同じ状態になるようにする。
【０２４６】
これらの目的のため、Ｃ’１ は伝えられた現状を解釈し（９０９） 、そしてそれを受諾または拒絶する（９１０） 。Ｃ’１ がそれを拒絶した場合、ＧＤはＣ’１ をアンロードし（９１１） 、それを脱初期化する（９１２） 。その後、ＧＤはエラーメッセージを要求コンポーネントＣ２に戻す（９１３および９１４）。
【０２４７】
一方、Ｃ’１ がＣ１の現状を受諾した場合、ＧＤはそのグラフを、その中のＣ１をＣ’１ で置換することにより更新する（９１６） 。その後、ＧＤはＣ’１ のための通信チャネルを再構築する（９１７） ；これらのチャネルはＣ１のために使用されていたものである。その後、ＧＤはＣ１を脱初期化およびアンロードする（９１８および９１９）。
【０２４８】
置換が正しく行われたら、ＧＤはそのことをＣ２に通知し（９２０， ９２１）；Ｃ２はその処理を続けることができる。
上述したのは本発明に係るシステムの原理と、その応用 （とりわけ、図６に関して） であった。
【０２４９】
図６の工程６２７ に等価の工程において、コンポーネントＣ１のインターフェースを、ＧＤがＣ１によってインポートされた機能をエクスポートするコンポーネントをサーチする時に、それがシステム内にロードされたコンポーネント類のセットの中からそのサーチを続けて、Ｃ１にこの機能をエクスポートするリンクグラフの各コンポーネントの「ビュー」を送信するようにパラメータ化することも可能であることを明記しておこう。
【０２５０】
パラメータ化された選択基準のファンクションとして、Ｃ１は次に、ＧＤによって識別されたものの中からそのための適切なコンポーネントを選択することができよう。
【０２５１】
本発明に係るシステムは、その現在のバージョンでは、図１０ａに示すように、最小４つのコンポーネントが動作することを要求することも明記しておこう （図中、矢印はコンポーネント間で送信される機能を示す−従って、この種の図はリンクグラフの表示である） 。
【０２５２】
これらは下記のコンポーネントである：
・既に述べたように、システムの動作を開始させるのに必要な ”ｉｎｔｅｒａｃｔｉｏｎ” （対話） 、
・ ”ｉｎｔｅｒａｃｔｉｏｎ”により呼出され、それ自体が次の２つのコンポーネントを呼出す ”ｓｈｕｔｔｌｅ” （シャトル） 、
・ＧＤ，
・そして最後に、やはり同様にＧＤを呼出す、いわゆるメモリコンポーネントまたはメモリ管理コンポーネントである ”ＶＭＭ”。
【０２５３】
図１０ｂは、マルチスレッド （多スレッド） 管理が可能となるように、 ”ＣＰＵ”，　”ＴＩＭＥＲ３” および ”ＳＣＨＥＤ”の３つのコンポーネントが加わったシステムの同様の最小構成を示す。
【０２５４】
最後に図１０ｃは、小さなアプリケーションを構成する本発明に係るシステムのより高度の構成を示す。
この図において、　”ｉｎｔｅｒａｃｔｉｏｎ” コンポーネントは、ネットワーク全体でデータを交換するように通信のための ”ＣＯＭ”コンポーネントを使用し、また図形プレゼンテーションを表示するために ”ＧＵＩ” （図形インターフェース） コンポーネントを使用する。
【０２５５】
”ＭＯＵＳＥ” コンポーネントは、マウス周辺装置を管理することを可能にする。それは、この周辺装置の状態の変化 （移動、ボタン上のクリック） に関する情報を伝える。”ＧＵＩ” コンポーネントは、”ＩＮＴＥＲＡＣＴＩＯＮ” コンポーネントにより要求された表示を実施するために ”ＷＩＮＤＯＷ” および ”ＢＵＴＴＯＮ” コンポーネントを使用する。
【０２５６】
”ＷＩＮＤＯＷ”および ”ＢＵＴＴＯＮ” コンポーネントは、それらのそれぞれの表示領域にイメージを表示するために、ＧＩＦ およびＪＰＥＧ ｃｏｄｅｃコンポーネントを使用する。ＧＵＩ， ＣＯＭ， ＷＩＮＤＯＷ， ＢＵＴＴＯＮ， ＧＩＦ およびＪＰＥＧコンポーネントはまた、システムの基本コンポーネントの機能も使用する。しかし、これらの機能に対応するリンクは、図１０ｃ の図表には、この図に負担を与えないように表示していない。
【０２５７】
コンポーネント類はドメインに分類される。ドメインは、特権のレベルには対応しないが、使用のタイプに対応するカテゴリである。各種のドメインを、ある種の関連コンポーネントと共に示すと、次の通りである。
【０２５８】
【表７】
2004503866.tif 000011
【０２５９】
本発明に係るシステムの全てのコンポーネントが同じフォーマットに従って実現されるため、このシステムは全コンポーネントを同じように管理し、上述したコンポーネントの有利な特性は、それらの特権レベルに関係なく、全コンポーネントに対して同様に当てはまることに留意されよう。
【０２６０】
最後に、本発明に係るシステムにより下記の点が可能となることは明らかである：
・プログラマにとって、オペレーティングシステムの全ての要素を、それらの特権レベルに関係なく、概観できること。
【０２６１】
・これらの各種の要素を作成するのに同じツールを使用できること。
・各種部分間の相互接続を制限なしに行えること。システムのパワーはそのコンポーネントの数により表されるのではなく、可能な相互接続の数により表される。従来のシステム （モノリシックとマイクロカーネルの両方） では、各種部分の間の通信手段は制限され、固定されている。ある任意のボトルネックを経て進むことが組織的に必要である （カーネルの場合、これがモノリシックカーネルまたはマイクロカーネル等のどれであろうと、システムの呼出しは数が制限される） 。従属性の管理と通信手段の動的作成とにより、この制限を克服することが可能となる。
【０２６２】
・全てのコードのタイプに等しい特性を提供できること。本発明の場合、実際、アプリケーション類のカーネルモジュール、ライブラリ、さらには「プラグイン」を管理するためのシステムを設計する必要はもはやない。この全てがコンポーネント管理システムにより置換される。
【０２６３】
・将来は、遂行されることが必要な機能と同じだけ多くのコンポーネントを作成できること。これは、本発明に係るシステムを完全にアップグレード可能にすることができる。
【０２６４】
さらに、上記説明に見られたように、多くの場合にエラーメッセージを戻すことにより、本発明は開発者に対して多大なる読み易さと反応性を示す。
実際、コンポーネントのロード中、ファンクション（Ｉｎｉｔ）がこのコンポーネントのために自動的に実行される。ロードされたコンポーネントの動作に必要なコンポーネント類のセットが実際にシステム内にロードされていることを、このファンクション（Ｉｎｉｔ）が検証する。この検証が満足できない （少なくとも１つの要求された機能が遂行されないか、または要求された機能を提供するあるコンポーネントが欠陥のあるハードウェア要素に関連づけられる等） 場合、エラーメッセージが呼出し側に戻される。
【０２６５】
さらに、呼出されたコンポーネントが欠陥のある要素 （ハードウェアおよび／またはソフトウェア） に関連づけられた場合、それは自動的にシステムのランダムアクセスメモリ中にアンロードされる。
【０２６６】
また、図９を参照すると、コンポーネントが呼出される場合にもエラーメッセージが戻されることが見られた。
即ち、呼出しコンポーネントの動作に関して、あるハードウェアまたはソフトウェア要素が存在しないか、または欠陥がある場合、エラーメッセージは、システムの完全な試験操作を必要とせずに、それを忠告するようにする。
【図面の簡単な説明】
【図１】モノリシック・アーキテクチャを模式的に示す。
【図２】マイクロカーネル・システムを模式的に示す。
【図３】図３ａ〜３ｃは、本発明に係るオペレーティングシステムの三つの概略図である。
【図４】本発明に係るシステムの１コンポーネントの概略図である。
【図５】そのようなコンポーネントを公式化する工程の概略図である。
【図６】本発明に係るオペレーティングシステムの１コンポーネントの作成および展開を示す論理チャートである。
【図７】本発明に係るシステムのソフトウェアコンポーネントを割り当ておよびロードするモードを示す。
【図８】本発明に係るシステムのコンポーネントの動的ロードおよびアンロード中のメモリ消費の減少を示す。
【図９】本発明に係るシステムの１コンポーネントの動的置換を示す論理チャートである。
【図１０】図１０ａ、１０ｂ、および１０ｃは、本発明に係るシステムにロードされたコンポーネントの三つのマップである。図１０ａは、本発明に係るシステムの初期動作に厳密に必要なコンポーネントだけがロードされる最小構成に対応する。図１０ｂは、さらにマルチスレッド（多重糸）管理を可能にする基本構成に対応する。図１０ｃは、本発明に係るシステムの拡張バージョンに対応する。
【図６】
2004503866.tif 000012
【図８】
2004503866.tif 000013
【国際公開パンフレット】
2004503866.tif 000014
2004503866.tif 000015
2004503866.tif 000016
2004503866.tif 000017
2004503866.tif 000018
2004503866.tif 000019
2004503866.tif 000020
2004503866.tif 000021
2004503866.tif 000022
2004503866.tif 000023
2004503866.tif 000024
2004503866.tif 000025
2004503866.tif 000026
2004503866.tif 000027
2004503866.tif 000028
2004503866.tif 000029
2004503866.tif 000030
2004503866.tif 000031
2004503866.tif 000032
2004503866.tif 000033
2004503866.tif 000034
2004503866.tif 000035
2004503866.tif 000036
2004503866.tif 000037
2004503866.tif 000038
2004503866.tif 000039
2004503866.tif 000040
2004503866.tif 000041
2004503866.tif 000042
2004503866.tif 000043
2004503866.tif 000044
2004503866.tif 000045
2004503866.tif 000046
2004503866.tif 000047
2004503866.tif 000048
2004503866.tif 000049
2004503866.tif 000050
2004503866.tif 000051
2004503866.tif 000052
2004503866.tif 000053
2004503866.tif 000054
2004503866.tif 000055
2004503866.tif 000056
2004503866.tif 000057
2004503866.tif 000058
2004503866.tif 000059
2004503866.tif 000060
2004503866.tif 000061
2004503866.tif 000062
2004503866.tif 000063
2004503866.tif 000064
2004503866.tif 000065
2004503866.tif 000066
2004503866.tif 000067
2004503866.tif 000068
2004503866.tif 000069
2004503866.tif 000070
2004503866.tif 000071
2004503866.tif 000072
2004503866.tif 000073
2004503866.tif 000074
2004503866.tif 000075
2004503866.tif 000076
2004503866.tif 000077
2004503866.tif 000078
2004503866.tif 000079
2004503866.tif 000080
2004503866.tif 000081
【国際調査報告】
2004503866.tif 000082
2004503866.tif 000083
2004503866.tif 000084
2004503866.tif 000085
2004503866.tif 000086
2004503866.tif 000087
2004503866.tif 000088
2004503866.tif 000089