JP2000501865A - 通信システムのためのシステムプラットホーム - Google Patents

Abstract

(57)【要約】 加入者サービスを提供する、電気通信システムのためのオブジェクト指向システムプラットホームは、ベースサービスおよび付加サービスを提供するベース機能および付加機能の形式のアプリケーションを含有する上部レイヤを含む。このレイヤは、ベースオブジェクト（２０２）および拡張オブジェクト（２０４、２０６、２０８）によって実現される。ベースオブジェクトは、将来拡張される必要がありうる機能を実現するオブジェクトタイプであり、それぞれのオブジェクトタイプは、他のベースオブジェクトとの最小の調整により行われうる特定のタスクのために設計されている。拡張オブジェクトは拡張機能を実現するオブジェクトタイプであり、該拡張機能は、ベース機能の拡張であり、かつ、新しいサービスの追加と、すでに実現され供給されているシステムのソフトウェアを変更することのない現存のサービスの変更および拡張と、を可能ならしめる。

Description

【発明の詳細な説明】 通信システムのためのシステムプラットホーム 発明の技術分野 本発明は、一般的には、加入者サービスを提供する電気通信システムのための オブジェクト指向（ｏｂｊｅｃｔ ｏｒｉｅｎｔｅｄ）システムプラツトホーム に関する。そのようなプラットホームは、一般に、下部レイヤ内のオペレーティ ングシステムと、その上に配置され資源オブジェクトの形式の適切な電気通信抽 象物を含むアプリケーションプラットホームと、ベースサービス（ｂａｓｅｓｅ ｒｖｉｃｅ）および付加サービス（ｓｕｐｐｌｅｍｅｎｔａｒｙｓｅｒｖｉｃｅ ）を提供するベース機能および付加機能の形式の所望アプリケーションを含むそ の上の上部レイヤと、を含むものとして説明することができる。 通信システムにより提供される加入者サービスは、システムのベース機能およ び付加機能のそれぞれにより提供される、ベースサービスおよび付加サービスを 含むことができる。システムの付加機能は、任意選択的なものであり、マーケッ トに依存するものであって、ベースサービスを提供するシステムが供給され終わ った後に顧客へ供給されうる。後には、コールウェイティングおよびコール再送 のような加入者サービスが使用中である場合がしばしば現れる。 関連技術の説明 付加サービスはしばしば、ベースサービスを提供するシステムがすでに展開さ れかつ供給され終わった時に導入される。その場合、システムを更新する伝統的 な方法は、現存のインプリメンテーションを編集し且つ再コンパイルして、それ が新しい付加機能をもサポートし、それが新しい拡張機能（ｅｘｔｅｎｓｉｏｎ ｆｕｎｃｔｉｏｎ）と現存の拡張機能との間の調整を処理するようにする。 米国特許第５，０５７，９９６号および第５，１３６，７１２号には、ハード ウェアレイヤと、オペレーティングシステム機能を有するレイヤと、ソフトウェ アレイヤと、を含むオブジェクト指向オペレーティングシステムが説明されてい る。特定のオブジェクトへのアクセスは、システム内の対応する資源の使用のた めに必要である。それらのオブジェクトは、それぞれのオブジェクトタイプのた めのオペレーションを定める一貫したデータ構造および一貫したメソッド（ｍｅ ｔｈｏｄ）を有する。このシステムは、オペレーティングシステムのコアを変更 することなく新しいオブジェクトタイプを発生させるルーチンを許容する。 米国特許第５，４２１，０１５号には、オブジェクトタイプの拡張可能な組と 、対応するオブジェクト管理プログラムの組と、を含むオブジェクト指向データ 処理システムが説明されている。 要約 本発明の一般的主要目的は、通信システムにおいて、システムの付加機能の管 理、すなわち、任意選択的でありマーケットに依存する、または、ベースサービ スを提供するシステムが供給を終わった後に顧客へ供給される、システムの部分 、をより効率的にすることである。 もっと限定された目的は、この効率を、すでに実現され供給されている機能の ソフトウェアを変化させる必要なく、システムにより提供されるサービスの変更 および拡張を可能ならしめることにより達成することである。 以下に現れるこれらの目的および他の目的は、本特許の請求の範囲に記載され ている特徴により達成された。 序論のようにして定められる種類のシステムプラットホームにおいては、上部 レイヤは、ベースオブジェクトおよび拡張オブジェクトにより実現される。ベー スオブジェクトとは、将来拡張する必要のあるベース機能を実現する、１つまた はそれ以上のメソッドを含むオブジェクトタイプであり、拡張オブジェクトとは 、ベース機能の拡張である拡張機能のインプリメンテーションを可能ならしめる 、１つまたはそれ以上のメソッドを含むオブジェクトタイプである。それぞれの ベースオブジェクトタイプは、他のベースオブジェクトとの最小の調整により行 われうる特定のタスクのために設計される。拡張オブジェクトは、すでに実現さ れ供給されているサービスのソフトウェアを変化させることなく、新しいサービ スと、現存のサービスの変更および拡張と、の追加を許容するように設計される 。拡張オブジェクトはまた、拡張機能の拡張を形成する拡張機能を実現するオブ ジェクトタイプをも、また、付加サービス間の相互作用を処理する、拡張機能を 処 理する相互作用を実現するオブジェクトタイプをも含むことができる。 拡張オブジェクトは、変更されるべきベースオブジェクトに動的に結合された 、動作中のシステムへの拡張の導入を可能にする。 拡張は構成可能であり、すなわち、プラットホームにより処理される、拡張の 適正な起動（ａｃｔｉｖａｔｉｏｎ）／動作停止（ｄｅａｃｔｉｖａｔｉｏｎ） のためのコードを設計者自身が設計する必要なく、実行時に総称的にシステムの 変更を追加および除去することを可能にする。 含まれているオブジェクトタイプの動態は、その中のそれぞれのメソッドの動 態を有限な状態マシンとして記述することにより定められる。この状態マシンは 、有限数の状態と、これらの状態間の遷移とから成り、そこで前記メソッドを定 めるコードが実行される。拡張はそれらの状態において追加され、その場合それ らは次に拡張の制御を引き継ぎ、それ自身の拡張を完了した後に、それを他の、 または同じ拡張点へ復帰させる。 ベースオブジェクトタイプおよび拡張オブジェクトタイプは、システムの現存 のインプリメンテーションを変更する必要なくシステムの変更および拡張を可能 にする拡張概念をサポートする。さらに詳述すると、これは、特定の所定拡張点 における拡張制御を引き継ぐことによりシステムの動態を間接的に変更する、シ ステムにおける拡張の定義のみをロードすることにより達成される。 拡張オブジェクトのための仕様は、拡張オブジェクトにおけるいずれの拡張点 において拡張が制御を引き継ぐものと仮定され、いずれの拡張点においてそれが 制御を復帰させうるかを定める。 拡張オブジェクトが制御を引き継いだ時、あらかじめ定められた拡張メソッド が実行を開始する。 実行時のシステムは、拡張オブジェクトの作成と、前述の拡張点におけるそれ らの拡張オブジェクトの拡張メソッドの呼出しと、を処理する。 拡張オブジェクトは、拡張が制御を引き継ぐ相手であるベースオブジェクトま たは拡張オブジェクトのアトリビュート（ａtｔｒｉｂｕｔｅ）およびメソッド へのアクセスを有する。これらのアトリビュートおよびメソッドは、アクセスさ れうるオブジェクトタイプの仕様に宣言されているもののみを含めばよい。 オブジェクトタイプの仕様にはまた、仕様内のアトリビュートおよびメソッド の特定の部分集合のみが、ある拡張点において制御を引き継ぐ拡張のために利用 可能であると定めることにより、それぞれの拡張点に対するアクセス制限が定め られる。 拡張可能なオブジェクトのためのオブジェクトタイプ仕様は、その拡張可能な オブジェクトの拡張にとって明らかでありかつ利用可能である情報の量の範囲を 定めるインタフェースのように働く。拡張概念と共に用いられるインタフェース レイヤは、それぞれの拡張ビュー（ｅｘｔｅｎｓｉｏｎ ｖｉｅｗ）が拡張可能 オブジェクトの仕様内の情報の部分集合を定めている該拡張ビューにより定めら れ、該部分集合は、該ビューを用いて拡張によりアクセスされうるべきものであ る。 ベースオブジェクトに対しては、一方においては拡張にとって利用可能な状態 、アトリビュート、およびメソッドを示すインタフェースの記述として働き、他 方においてはベースオブジェクトのインスタンスの作成を必要とするクライアン トオブジェクトに関するインタフェースを定める、仕様が存在する。このインタ フェースは、新しいインスタンスを作成する時いずれのパラメータが用いられう るかを決定するベースオブジェクトタイプのメソッドにより定められる。 前記仕様は、ベースオブジェクトタイプの動態の高レベルの記述を与えるが、 オブジェクトタイプの機能の理解を得るために不必要なインプリメンテーション の詳細は省いている。 ベースオブジェクトにより用いられる基礎的なオブジェクト論理により作成さ れる抽象レイヤと、該オブジェクト論理の使用を含むベースオブジェクトにおけ るローカルメソッドとは、高抽象レベルに対して寄与する。 仕様における適度の抽象レベルは、仕様内のベースオブジェクトの待ち状態（ ｗａｉｔ ｓｔａｔｅ）と、ベースオブジェクトの機能を理解するために重要で ある、恐らくはある選択された非待ち状態と、を示すことにより得られる。示さ れた状態間における実行のためのコードは、仕様内に宣言されているが必ずしも 動態を指定されてはいないローカルメソッドへ導入される。仕様内に示されるべ きことは、オブジェクトタイプのいずれの部分が将来拡張を受けるうるかを考 慮して判断される。 全ての状態、待ち状態および非待ち状態の双方、および全ての明示的に命名さ れた拡張点は、メソッド仕様内に示される。アクションコードは、ローカルメソ ッドにおける状態遷移において用いられる。もし動態のある部分が拡張可能であ る必要がなければ、これらは全体として、仕様において、または実現システムに おいて、またはインプリメンテーションレベルにおいて定められるローカルメソ ッド内へ導入される。 オブジェクトタイプの実現システムは、拡張可能である必要のない、または拡 張可能でありえない、ベースオブジェクトの部分であって、それらの部分は高レ ベルの記述を作成するために仕様内に示される必要はないが、インプリメンテー ション言語を直接用いる代わりに定義を与えることが好ましい前記部分のために 用いられる。実現システム内には、アクションコードを導入するローカルメソッ ドの定義が導入される。この実現システム内には、仕様内に含まれる動態の定義 をオーバライドしつつ、さらに詳細な動態の定義が与えられ、それは、仕様内に 与えられている動態仕様の精密化を意味する。 本発明による拡張概念は、いくつかの価値ある性質を有する。それは、変更を 行うきめの細かい方法であり、それが必ずしも全体の方法をオーバライドしない ことにより、それは大抵のオブジェクト指向形式において利用可能な機構である 。代わりに、オーバライドは、メソッド内のある拡張点において行われうる。拡 張概念は、展開可能な状態で供給されたシステム内に多くの付加機能を導入する ことにより生じる複雑性を処理するフレームワークを形成する。これは、それぞ れの拡張により別個に行われる変更を記述することにより可能にされ、その後拡 張は、必要があるときは、順番に調整されうる。付加機能間のそのような調整は また、別個の拡張として、個の場合には付加機能の拡張として、表すこともでき る。これは、システムのオプション部分と、それらの部分のモジュール的な依存 性と、を管理することを可能にする。 図面の簡単な説明 本発明を以下に、添付図面を参照しつつさらに詳細に説明する。添付図面にお いて、 図１は、加入者サービスを提供しうる電気通信システムのためのシステムプラ ットホームを概略的に示し、 図２は、本発明による拡張概念に用いられる概念間の関係を示すための図であ り、 図３は、拡張概念を概観的に示し、 図４から図６までは、ベースオブジェクトの仕様、実現システム、および拡張 図のそれぞれの例を示し、 図７から図９までは、拡張オブジェクトの仕様、実現システム、および拡張図 のそれぞれの例を示し、 図１０は、ベースオブジェクト、拡張オブジェクト、および拡張図、ならびに オブジェクトタイプ仕様、オブジェクトタイプ実現システム、およびオブジェク トタイプインプリメンテーションの、要約した概観を与えるための図であり、 図１１から図１４までは、拡張機構の使用を説明する例を示す図であり、 図１１は、無条件拡張の場合を示し、 図１２は、条件付き拡張の場合を示し、 図１３は、イベント拡張を意味する場合を示し、 図１４は、同じ拡張点におけるいくつかの拡張を有する場合を示す。 実施例の詳細な説明 図１を参照すると、電気通信システムのためのシステムプラットホームは、い くつかの機能、すなわちレイヤを含む。これらのレイヤは、下部レイヤ１０２内 のオペレーティングシステムと、その上に配置され、資源オブジェクトの形式の 適切な電気通信抽象物を含むアプリケーションプラットホーム１０４と、その上 の、ベースサービスおよび付加サービスを提供するベース機能および付加機能の 形式の所望のアプリケーションを含むレイヤ１０６と、を含むものとして説明さ れうる。 今後レイヤ１０６内に含まれる異なるタイプのオブジェクトを定義するために 、「カテゴリ」という概念を使用する。さらに詳述すると、「カテゴリ」はオブ ジェクトを構文的に特徴づけるが、それはまた、システムアーキテクチャ内にお けるオブジェクトの位置および機能をも特徴づける。ＢＡＳＥおよびＥＸＴＥＮ Ｓ ＩＯＮとそれぞれ命名される２つのカテゴリの、以下においてさらに詳述するオ ブジェクトタイプは、レイヤ１０６のインプリメンテーション内に含まれる。こ れらのオブジェクトのインスタンスは、以下においてベースオブジェクトおよび 拡張オブジェクトと命名される。 さらに、以下には、非同期メッセージの送出に命名するために用いられる「イ ベント」という概念がある。オブジェクトは、「イベント」の監視を要求し、そ してそれを待つことができる。イベントは、オブジェクトタイプの記述内の「Ｅ ＶＥＮＴ」部分において宣言される。レイヤ１０６内においては、動態はイベン トにより駆動され、すなわちオブジェクトは非同期メッセージの受信に反応する 。イベントはしばしば、オブジェクトが実行するプロセスへプロセス間通信リン クを経て到達するメッセージの結果として発生せしめられる。ここでは、プロセ スとは、実行されているプログラムを意味する。以下においてはまた、実行スレ ッドという命名が、プロセス内の実行経路のために用いられる。それぞれの実行 スレッド（ｔｈｒｅａｄ）は、それ自身のスタックおよびプログラムカウンタを 有するが、同じプロセス内の全てのスレッドは、同じプロセスデータ（ヒープ： ｈｅａｐ）を共有する。 それぞれのベースオブジェクトタイプは、電話システムにおける呼のセットア ップの管理のような特定のタスクを行うために設計される。そのようなタスクが 行われるべき時は、ベースオブジェクトタイプのインスタンスが作成される。こ のオブジェクトは、その時タスクがどのように行われるべきかについて制御する 。タスクを行うために、資源がどのように操作されるかなどの、低レベルにおけ る詳細は、他のカテゴリの、例えば、カテゴリ「ＥＶＥＮＴＧＥＮＥＲＡＴＯＲ 」のオブジェクトに対してメソッド呼を送出するベースオブジェクトにより処理 される。このカテゴリのオブジェクトタイプは、呼び出される、または、それら のユーザにイベントを発生することにより知らせる、資源または基本的サービス を表す。 ベースオブジェクトタイプは、それらのそれぞれのタスクが、システム内にお いて進行中の他のタスクとの最小の調整により、すなわち、ベースオブジェクト 間の最小の調整により、行われることを可能にすべく設計されるよう意図される 。 これは、ベースカテゴリおよび拡張カテゴリの性質に反映される：それぞれのベ ースオブジェクトは、半並列実行スレッド内において実行され、ベースオブジェ クトも拡張オブジェクトも外部から呼び出されるべきメソッドを有しえず、それ らはイベントを発生しえない。これらの性質は、以下においてさらに詳述される 。 ベースカテゴリおよび拡張カテゴリのもう１つの重要な特徴は、それらが拡張 概念をサポートし、システムの動態が、システムの現存のインプリメンテーショ ンを変更する必要なく変更され拡張されうるようにすることである。代わりに、 その動態の変更および拡張は、システムにおける拡張のみをロードすることによ り達成される。特定の決定された拡張点において実行制御を引き継ぐことにより 、拡張概念を用い、これらの拡張は次にシステムの動態を間接的に変更する。 ベースカテゴリは、将来拡張される必要がありうるベース機能性、いわゆるベ ース機能、を実現するオブジェクトタイプのために用いられるべきである。拡張 カテゴリは、これらのベース機能の拡張、いわゆる拡張機能、を実現するオブジ ェクトタイプのために用いられる。 オブジェクトタイプの動態は、今後「設計言語（ｄｅｓｉｇｎｌａｎｇｕａｇ ｅ）」と呼ぶオブジェクトモデリングのための特定の設計言語を用いることによ り、有限状態マシンを有するそれぞれのメソッドの動態を記述することによって 定義される。そのような有限状態マシンは、有限数の状態と、これらの状態間の 遷移と、から成り、この場合コードは遷移作用として実行される。従って、拡張 を追加するための大抵の固有点、すなわち拡張点は、それらの状態である。拡張 は、拡張点において拡張制御を引き継ぎ、その制御を、同じメソッドにおける他 の拡張点、または同じ拡張点へ復帰させるように設計されうる。この観点から拡 張は、状態マシンへの、新しい状態および状態遷移の追加とみなしうる。その時 、これらの状態および状態遷移は、この状態マシンの現存の状態遷移を変更する 。 メソッドにおける全ての状態は常に拡張点として用いられうるが、新しい状態 を導入することなく、拡張点、いわゆる明示的に命名された拡張点、を明示的に 指定することもできる。 拡張点は、それらが、該点からの拡張、ある点における拡張の終了、を可能に するかどうか、または、それらが両目的のために用いられうるかどうか、に関し て分類される。これらの点のために、今後以下の命名が用いられる。 −引き継ぎ点（ｔａｋｅ ｏｖｅｒ ｐｏｉｎｔ）、すなわちＴＯＰ、これは 、拡張制御が拡張オブジェクトの拡張メソッドへ送信されうる拡張点である。 −継続点（ｃｏｎｔｉｎｕａｔｉｏｎ ｐｏｉｎｔ）、すなわちＣＯＰ、これ は、拡張メソッドから実行制御が再転送されうる拡張点である。 −引き継ぎおよび継続点、すなわちＴＯＰ ＣＯＰ、これは、引き継ぎ点およ び継続点の双方として用いられうる拡張点である。 初めから（デフォルト（ｄｅｆａｕｌｔ））、オブジェクトにおける全ての状 態は、引き継ぎおよび継続点である。しかし、これは、もし全ての拡張に対して 制限を行う必要があれば、オブジェクトタイプの仕様において変更されうる。同 じ種類の拡張は、拡張ビュー（ｅｘｔｅｎｓｉｏｎ ｖｉｅｗ）においても行う ことができ、その概念は以下において詳述される。 拡張概念はまた、拡張から拡張への定義をも許容する。実際、拡張は、拡張の 連鎖、またはレイヤ、を作成することにより、任意数のレベル上で定義されうる 。従って、例えば、拡張連鎖内の「最上部」拡張と、拡張の全連鎖と、の間の区 別を可能にするために用語を定義することが必要である。 「ベースオブジェクト」という概念は、拡張されていない原ベース機能を含む オブジェクトを表示するために用いられる。もし誤解の危険があれば、「原（ｏ ｒｉｇｉｎａｌ）ベースオブジェクト」という命名が用いられる。 拡張は、「拡張オブジェクト」と呼ばれる。 イミーディエイトベース（ｉｍｍｅｄｉａｔｅ ｂａｓｅ）という概念は、拡 張が開始されるベースオブジェクトまたは拡張オブジェクトに関し、すなわち、 拡張はそのイミーディエイトベースから引き継ぎを行う。 もっと総称的な命名であるベースは、拡張の全連鎖を意味するために用いられ 、原ベースオブジェクトに対してある拡張オブジェクトが拡張を形成する該原ベ ースオブジェクトを含む。もし誤解の危険があれば、「全ベース」という命名が 用いられる。 上述のことは図２に示されており、そこでは、オブジェクト２０２、すなわち 「ベースオブジェクト」が、原ベースオブジェクトである。ベースオブジェクト ２０２に対しては、拡張オブジェクト２０４および２０６、すなわち「拡張オブ ジェクト₁」および「拡張オブジェクト₂」がリンクされうる。拡張オブジェクト ２０６は、さらなる拡張オブジェクト２０８、すなわち「拡張オブジェクト₂₁」 のイミーディエイトベースである。ベースオブジェクト２０２および拡張オブジ ェクト２０６は、拡張オブジェクト２０８のベースを形成する。 拡張オブジェクトのための仕様は、拡張が制御を引き継ぐ点と考えられる、拡 張オブジェクトにおける拡張点と、いずれの拡張オブジェクトにおいてそれが該 制御を復帰させうるかと、を定める。拡張オブジェクトが該制御を得た時、それ は、実行を開始する予め定められた拡張メソッド、すなわちＥＸＴＥＮＳＩＯＮ ＭＥＴＨＯＤである。実行時のシステムは、拡張オブジェクトの作成を担任し 、与えられた拡張点においてそれらの拡張オブジェクトの拡張メソッドを呼出す 。 以上から明らかになったように、拡張オブジェクトはさらに自身も拡張を有し うる。拡張メソッドはこのようにして、ベースメソッドから、または他の拡張メ ソッドから、常に暗黙に呼出される。 拡張オブジェクトは、拡張されたオブジェクト、すなわち、拡張が制御を受取 った相手であるベースオブジェクトまたは拡張オブジェクト、のアトリビュート およびメソッドへのアクセスを有する。しかし、このアクセスを制限するある方 法が存在する。まず、アクセスされうるのは、オブジェクトタイプ仕様において 宣言されたアトリビュートおよびメソッドのみである。実現システムにおいての み宣言されているアトリビュートおよびメソッドは、拡張のためには利用しえな い。仕様においてはさらに、仕様内のアトリビュートおよびメソッドのある部分 集合のみが、ある拡張点において制御を受取った拡張のために利用可能であるこ とを定めることにより、それぞれの拡張点のためのアクセス制限を定めうる。 このようにして、拡張可能オブジェクトのためのオブジェクトタイプ仕様は、 このベースオブジェクトの拡張のために明らかであり且つ利用可能である情報の 量を制限するインタフェースとして働く。しかし、拡張概念と共に用いられる特 殊インタフェースレイヤが存在し、これは、拡張ビューにより定められるインタ フェースである。拡張ビューは、このビューを用いる拡張によりアクセスされう べき拡張可能オブジェクトの仕様内の情報の部分集合を定義する。 図３は、拡張原理を示す。図３において、ブロック３０２はベースオブジェク トの仕様を表し、ブロック３０４は拡張オブジェクトの仕様を表す。仕様３０２ は、ブロック３０６により表されるボディメソッド（ｂｏｄｙ ｍｅｔｈｏｄ） 、すなわち「ＢＯＤＹ」を含み、ブロック３０６内には、４つの状態を有する有 限状態マシン３０８が示されている。これらの状態は、２つの拡張点ｓ１および ｓ２を含む。ブロック３１０により示されている拡張ビュー内には、点ｓ１およ びｓ２が、それぞれ引き継ぎ点および継続点として宣言され、「ＴＯＰ ｓ１； 」および「ＣＯＰ ｓ２；」により示されている。ブロック３１２は、示されて いる５つの状態を有する有限状態マシンにより、ベースオブジェクトの仕様内の さらなるメソッド「Ｍｅｔｈｏｄ ｍ１」を表している。 拡張オブジェクトの仕様３０４は、拡張メソッド「ＥＸＴＥＮＳＩＯＮ ＭＥ ＴＨＯＤ ｅｘｔ１」を含み、これは、ブロック３１４内に、開始状態ｔおよび 終了状態ｓ２を含む３つの状態を有する有限状態マシンを含んでいるように示さ れている。ブロック３１６内には、さらなる拡張メソッド「ＭＥＴＨＯＤ ｅｘ ｔ２」が、４つの状態を含んでいるように示されている。 拡張点ｓ１およびｓ２は、拡張ビュー３１０を経て拡張オブジェクトから見ら れうる。ベースオブジェクトのメソッド３０８が状態ｓ１に到達した時、実行制 御は矢印３１８により示されているように、拡張メソッドｅｘｔ１へ接続される 。拡張メソッドｅｘｔ１は、そのオリジンｔの状態から実行を開始する。実行が 最終的に拡張内の状態ｓ２に到達した時、制御は、矢印３２０に従ってベースへ 復帰接続され、ベースは状態ｓ２からのその実行を継続する。これは、実行時シ ステムにより行われ、すなわち、拡張の設計者が、これを拡張内の宣言における 以外の設計者のコードにより明示的に管理する必要はない。 前述のように、カテゴリＢＡＳＥは、ベース機能、後に実行されうる機能、を モデル化するために用いられるオブジェクトタイプカテゴリである。ベースオブ ジェクトは、ある特定の性質を有する。１つの重要な性質は、ベースオブジェク トの実行が、常に半並列制御スレッドにおいて行われることである。ベースオブ ジェクトの目的は、システム内において並列に進行しうる他のタスクと無関係に 生じるタスクを行うことであるので、これは自然なことである。実行中に、オブ ジェクトは待ち状態に入ることができ、待ち状態は、後に制御が他のスレッドへ 転送されるまで実行がされている状態である。実行は、待ち状態において待たれ ていたイベントが受信された時に再開される。 ユーザの観点からは、この性質は、現実行スレッド内に新しいベースオブジェ クトインスタンスを作成することにより達成することができ、新しいスレッドに おける後の実行のための、このベースオブジェクトインスタンスのボディメソッ ド「ＢＯＤＹ」をスケジュールする。スレッドスイッチングは、最初の現スレッ ドが待ち状態に入った時に行われる。このステップにおいては、新しく作成され たスレッドは、実行を開始する機会を得る。しかし、プロセス内に他のスレッド もありえ、それらも実行を開始する準備を完了しているので、新しいスレッドが 正確にこの瞬間に実行を開始する保証はない。保証されているのは、それが遅か れ早かれ実行を開始することのみである。 新しいスレッドの作成に関連して、新しく作成されるオブジェクトインスタン スの基準への復帰が行われる。この基準は、後に、スレッドが終了した時に常に 現れるイベントを待つことにより、作成されたスレッドの終了に同期して用いら れる。その基準はまた、アーギュメントとして用いられ、またはアトリビュート 内に記憶されうるが、それはいかなる他の目的にも用いられるべきでない。 ベースオブジェクトのもう１つの重要な性質は、ベースオブジェクトのアトリ ビュートおよびメソッドが、ベースオブジェクトの拡張オブジェクト以外の全て の他のオブジェクトに対して隠されていることである。 ベースオブジェクトに対しては、仕様と、実現システムの記述と、の双方があ りえ、双方が設計言語を用いた動態の記述を含む。仕様の目的は、主としてベー スオブジェクトのインタフェース記述として作用することである。この仕様が関 連するベースオブジェクトに対しては、異なる種類のクライアントが存在する。 第１に、ベースオブジェクトの動態を拡張する拡張オブジェクトが存在する。 これらに対しては、仕様は、拡張が利用しうる状態、アトリビュート、およびメ ソッドを示すインタフェース記述として作用する。さらなるアクセス制限も、そ れらが用いる拡張ビューにより拡張のために導入されうるが、それらは、ベース オブジェクトの仕様内に示されているものより多くにはアクセスしえない。 第２に、仕様は、ベースオブジェクトのインスタンスを作成することを必要と するクライアントオブジェクトに向けてのインタフェースを定める。このインタ フェースは、ベースオブジェクトタイプのメソッドにより定められる。それらの メソッドは、新しい拡張スレッドが上述により作成されるべき時に、新しいイン スタンスの作成において用いられうるパラメータを決定する。 仕様のもう１つの目的は、ベースオブジェクトタイプの動態の高レベルの記述 を与えると共に、オブジェクトタイプの機能の理解を得るために不必要である、 インプリメンテーションの細部を省略することである。高い抽象レベルは、ベー スオブジェクトにより用いられる、基礎を成すオブジェクト論理により作成され た抽象レイヤにより部分的に与えられるが、またオブジェクト論理の使用を含む ベースオブジェクトにおけるローカルメソッドによっても与えられる。仕様にお ける適正な抽象レベルは、ベースオブジェクトの機能の理解のために基本的であ る、仕様内のベースオブジェクトの待ち状態と、恐らくはある選択された非待ち 状態と、を示すためのものでありうる。その場合、示された状態間において実行 するためのコードは、仕様内に宣言されているが必ずしも動態を指定されてはい ないローカルメソッド内へ導入されうる。 仕様内に何を示すべきか、および何を示すべきでないか、を決定すべき時は、 オブジェクトタイプのいずれの部分が将来拡張を受けうるかについて考慮しなけ ればならない。仕様を最も拡張可能であるようにする方策は、ＢＯＤＹメソッド の仕様内の全ての状態、待ち状態および非待ち状態の双方、および全ての明示的 に命名された拡張点、を示すこと、かつ、ローカルメソッドにおいて、状態遷移 のために用いられるアクションコードのみをカプセル化すること、である。もし 一方、動態のある部分が拡張可能である必要のないことが決定されれば、これら の部分は全体としてローカルメソッドへ導入されうる。これらのローカルメソッ ドはそこで、仕様において、または実現システムにおいて、またはインプリメン テーションレベルにおいてさえ、定められうる。しかし、もしそれらが仕様から 呼出されるべきであれば、それらは仕様内に宣言されていなければならない。 オブジェクトタイプの実現システムの目的は、それらの実現システムが、拡張 可能である必要のない、または拡張可能でありえない、また、高レベルの記述を 作成するために仕様内に示す必要はないが、インプリメンテーション言語の使用 の代わりに設計言語による定義が選択される、ベースオブジェクトの部分のため に用いられるべきことである。アクションコードをカプセル化するローカルメソ ッドの定義は、ここに配置されうる。実現システムにおいては、仕様内に含まれ る動態の定義を省き、もっと詳細な定義を与えることも可能である。そのような 新しく定められた動態の定義は、仕様内に与えられる動態仕様の精密化であるべ きである。 実現システム内に定められている、または宣言されている、メソッド、アトリ ビュート、または状態は、このオブジェクトタイプの拡張のためには利用しえな いことを強調しておかなければならない。それは単に、拡張に対して明らかにさ れたオブジェクトタイプ仕様内の情報に過ぎない。 設計言語での仕様のみを用い、この言語での実現システムを用ないで、ベース オブジェクトの全体を指定することも可能である。この場合、インプリメンテー ション言語は、これが適切である、仕様内で呼出されるアクションメソッドのあ るものを定義するために用いられうる。しかし、イベントのモニタリング「ＭＯ ＮＩＴＯＲ」およびモニタリング停止「ＳＴＯＰ ＭＯＮＩＴＯＲ」は、仕様内 、または実現システム内のいずれかで、設計言語により行われなければならない 。もしオブジェクトの「作成／除去」が設計言語により行われるならば、同様に して、同じオブジェクトのための対応するメッセージ「除去／新規」は、仕様内 、または実現システム内のいずれかで、設計言語により行われなければならない 。それと対照的に、もし作成／除去がインプリメンテーション言語により行われ るならば、対応する除去／新規もまたインプリメンテーション言語により行われ なければならない。 オブジェクトのボディメソッドＢＯＤＹに対しては、たとえ、もし動態の定義 が、実現システムにおいて極めて簡単でありえ、またオーバライドされえたとし ても、仕様内に設計言語による動態の定義を与えなければならない。ベースオブ ジェクトにおける他のメソッドに対しては、前述のように、設計言語の使用は任 意選択的なものである。 図４および図５には、ベースオブジェクトタイプのオブジェクト 「ｔｈｅＢａｓｅ」の、仕様および実現システムの例がそれぞれ与えられている 。 図４に示されている仕様内には、ボディメソッド「ＢＯＤＹｍｅｔｈｏｄ」の 動態が、第１２行から定義されている。しかし、メソッド「ｍｅｔｈｏｄ１」お よび「ｍｅｔｈｏｄ２」および「ＣＯＮＳＴＲＵＣＴＯＲ」は、第７行から宣言 されているのみである。ＣＯＮＳＴＲＵＣＴＯＲは、オブジェクトタイプのイン スタンスが作成される時に実行されるメソッドである。 図５に示されている実現システム内には、第２行からメソッド 「ＣＯＮＳＴＲＵＣＴＯＲ」、「ｍｅｔｈｏｄ１」および「ｍｅｔｈｏｄ２」の 動態が定められている。ボディメソッドは、仕様内の１つとして第２２行に述べ られている。 前述のように、ベースオブジェクトタイプの仕様は、そのクライアントのため のインタフェース記述として役立つ。拡張ビューもまた、一種のインタフェース 記述である。それらは、拡張可能なオブジェクトへの、それらの拡張のためのア クセスをさらに制限するために用いられる。 特殊インタフェースレイヤを有する目的は、あるオブジェクトに対してなされ うる拡張に関して、あるさらなる監視を行うことである。異なる目的のためには 、異なる拡張ビューが作成されうる。もし例えば、あるビューが、デビティング 機能（ｄｅｂｉｔｉｎｇ ｆｕｎｃｔｉｏｎ）および統計機能の使用のために設 計されていれば、拡張オブジェクトの状態およびアトリビュートの小さい部分集 合のみを示せば十分でありうる。もう１つの用途は、機能の異なる部分に対して 異なるビューを定め、あるビューの拡張の使用が、拡張されたオブジェクトのあ る機能のみがが変更されていることを意味するようにすることである。この情報 および類似した情報は、システム内へ新しい拡張機能を導入する時、実現する必 要がありうる拡張機能間の調整を調査する時に、価値を有しうる。 このようにして、ベースオブジェクトは、いくつかの異なる拡張ビューを有し うる。しかし、それぞれの拡張オブジェクトは、特定の拡張ビューのために設計 される。拡張ビューは、さまざまな解析目的のために設計相中においてのみ用い られ、実行時の環境内に別個のユニットとして存在することはない。 図６には、図４におけるベースオブジェクトタイプのオブジェクト ｔｈｅＢａｓｅの拡張ビューの例が示されている。拡張ビューは、拡張可能オブ ジェクトの仕様の制限されたビューを作成するために用いられる。拡張ビューは 、ベースオブジェクトにおいてすでに利用可能でない情報を定めることはできな い。それらは、さらなる制限を追加し、ベースオブジェクトにおいてすでに明ら かになっている情報を隠しうるのみである。ベースオブジェクトにおいてすでに 指定されている制限は、オーバライドされえない。 拡張ビュー内には、まず、拡張によって得られるべきベースオブジェクトにお けるメソッドおよびアトリビュートのリストが与えられる（図６の第３行ないし 第６行参照）。このリストは、そのベースオブジェクト内に存在するアトリビュ ートおよびメソッドの部分集合を定めている。そして、拡張に利用しうべき拡張 点がリストされている。ビュー内のそれぞれの拡張点に対しては、以下の情報が 指定されている。 −拡張点の名称（図６内の第７行、第１１行、第１５行、および第１８行のそ れぞれを参照）：それぞれ、ＴＯＰ ＷＡＩＴ ＳＴＡＴＥ、ＴＯＰ ＣＯＰＳ ＴＡＴＥ、ＴＯＰ ＳＴＡＴＥ、およびＣＯＰ ＳＴＡＴＥ。拡張点は状態であ るので、名称内には、キーワードＳＴＡＴＥおよびＷＡＩＴ ＳＴＡＴＥが、そ れぞれ与えられている。明示的に命名された拡張点に対しては、そのような情報 は与えられない。さらに、命名は拡張点のタイプを含み、すなわち、引き継ぎ点 ＴＯＰ、継続点ＣＯＰ、または引き継ぎおよび継続点ＴＯＰ ＣＯＰが述べられ ている。前述のように、ベースオブジェクトの全ての拡張点は、引き継ぎおよび 継続点のタイプのものである。ここでは、拡張点は、引き継ぎ点としてのみ、ま たは継続点としてのみ、使用しうるように制限されうる。しかし、もし基本的設 定が用いられるべきであれば、キーワードＴＯＰ ＣＯＰは与えられなければな らない。 −それぞれの引き継ぎ点に対しては、指定された引き継ぎ点から開始される拡 張メソッドが利用しうるベースオブジェクト内のアトリビュートおよびメソッド のリストがある（図６内の第９行、第１２ないし１３行、および第１６行参照） 。このリストは、拡張ビューの初めにリストされているアトリビュートおよびメ ソ ッドの部分集合である。 −それぞれの引き継ぎ点に対しては、許容される継続点ＣＯＰが与えられてい る（図６内の第８行参照）。この情報は、いずれの拡張点において、現引き継ぎ 点における制御を引き継ぐ拡張が継続することを許容されるか、を決定するため に用いられる。 −それぞれの引き継ぎ点に対しては、ベースオブジェクトの諸状態における分 岐のために用いられる式のタイプが示されている。これは、非待ち状態に対して のみ関係がある。 拡張ビュー内のベースオブジェクトにおけるメソッドのローカル変数を参照す ることは不可能である。 拡張概念はまた、拡張への拡張をも許容するので、拡張ビューは、ベースオブ ジェクトと、拡張オブジェクトと、の双方に対して作成されうる。 拡張オブジェクトに対しては、ベースオブジェクトに対してと同じ制限が有効 である。それらの数は、それらの拡張以外のオブジェクトによってはアクセスさ れえない。 拡張オブジェクトに対してはまた、仕様および実現システムの双方が与えられ うる。拡張オブジェクトの拡張メソッドに対しては、仕様内の設計言語による動 態の定義を与えなければならないが、この定義は極めて簡単でありえ、それは実 現システムにおいてオーバライドされえない。拡張オブジェクトにおける他のメ ソッドに対しては、設計言語の使用は任意選択的である。 図７、図８、および図９には、拡張タイプのオブジェクト 「ｔｈｅＥｘｔＯｂｊ」の仕様と、同じオブジェクトの実現システムと、問題の オブジェクトの拡張ビューと、がそれぞれ与えられている。 拡張は、カテゴリＥＸＴＥＮＳＩＯＮのオブジェクト内にカプセル化されてい る。拡張オブジェクトの仕様（図７参照）は、拡張オブジェクトにより用いられ るビュー（第３行参照）と、いずれの引き継ぎ点において、その拡張メソッドが 制御を引き継ぐか（第８行参照）と、拡張メソッドのための優先クラス（第７行 参照）と、を定めている。いくつかの異なる拡張オブジェクトは、ベースオブジ ェクトの同じビューを用いうる。多重拡張は、同じオブジェクト内の同じ拡張点 からさえ開始されうる。 拡張オブジェクトにおけるメソッドは、常にベースオブジェクトと同じスレッ ド内において実行される。ベースオブジェクトにおいて行われるイベントの全て のモニタリングは、さらに拡張メソッドにおいても有効である。換言すれば、イ ベント発生器の識別が、拡張メソッドによりビューを経て利用しうるようにされ ている限り、拡張メソッドは、ベースオブジェクトにおいてモニタされたイベン トを受信しうる。 ＥＸＴＥＮＳＩＯＮ ＭＥＴＨＯＤＳのための仕様内の状態は、ベースオブジ ェクトのＢＯＤＹメソッドの仕様内の状態と同様にして、引き継ぎおよび継続点 として用いられうる。拡張メソッドの実現システム（図８参照）は、いくつかの 状態を同様にして追加することができる（第２行および第８行参照）が、再びそ れらは他の拡張にとっては利用不可能である。 拡張オブジェクトｔｈｅＥｘｔＯｂｊに対するさらなる拡張は、図９に与えら れている拡張ビューに示されている所に従って、フレームの形式においてのみ行 われうる。 図１０は、概念ベースオブジェクト、拡張オブジェクト、および拡張ビュー、 ならびにオブジェクトタイプの仕様、実現システム、およびインプリメンテーシ ョンの間の関係を要約した概観を与える。図１０において、スタックブロック１ ００２は、設計言語による仕様１００４および実現システム１００６と、ターゲ ット言語によるインプリメンテーション１００８と、を示している。同様にして 、ブロック１０１０は、設計言語による仕様１０１２および実現システム１０１ ４と、ターゲット言語によるインプリメンテーション１０１６と、を示している 。 ベースオブジェクトの仕様１００４は、オブジェクトタイプの機能の総合的理 解を得るために用いられうる、適切に高い抽象レベルの仕様である。この仕様は 、アトリビュートおよびメソッド双方のシグネチャ宣言ならびにメソッド（の部 分集合）の動態仕様を含む。ＢＯＤＹメソッドの動態仕様内に示されている全て の状態は、拡張により用いられうる。 ベースオブジェクトの実現システム１００６は、オブジェクトタイプの動態の さらに詳細な記述を有する。それは、オブジェクトタイプ仕様内のメソッドの動 態の定義をオーバライドしうる。この実現システムもまた、宣言されたメソッド の動態を定義しうるが、仕様内に指定されている動態は定義しえない。実現シス テムに対してローカルな新しいアトリビュートおよびメソッドは、追加可能であ る。実現システム内に追加された情報は、拡張には利用しえない。１つの仕様は 、１つより多くの実現システムを有する。 ターゲット言語によるベースオブジェクトタイプのインプリメンテーション１ ００８は、オブジェクトタイプの完全なインプリメンテーションである。それは 、ターゲット言語（Ｃ＋＋）により発生せしめられ、かつ、任意選択的に、手書 きされたソースコードから成る。この発生せしめられた部分は、インプリメンテ ーションが、オブジェクトタイプ仕様による拡張のために準備されていることを 保証する。インプリメンテーションコードは、オブジェクトタイプ仕様、また、 任意選択的に、設計言語によるオブジェクトタイプの、１つまたはそれ以上の実 現システム、を用いることにより発生せしめられる。 １０１８および１０２０には、ベースオブジェクトタイプ仕様１００４の拡張 ビューが示されている。同じオブジェクトタイプ仕様のいくつかのビューがあり うるが、それぞれのビューは常に、正確に１つのオブジェクトタイプ仕様のため に設計されている。新しいビューは、ベースオブジェクトの仕様、実現システム 、またはインプリメンテーションに影響を与えることなく作成されうる。ベース オブジェクトタイプ仕様１００４と、そのビュー１０１８および１０２０とは、 拡張オブジェクトタイプを設計する時に用いられる。 拡張オブジェクトタイプの仕様１０１２は、ベースオブジェクトタイプの仕様 と同じ高い抽象レベルで、拡張オブジェクトを指定する。拡張オブジェクトタイ プの実現システム１０１４およびインプリメンテーション１０１６もまた、ベー スオブジェクトタイプに対してと同様に現れる。 拡張オブジェクトタイプのためのそれぞれの仕様は、常に正確に１つの拡張ビ ュー１０２２を用いることにより設計される。ベースオブジェクトタイプにおけ る場合との類似により、１つの拡張オブジェクトタイプにたいしては１つまたは それ以上の拡張ビューが定められうる。 コード発生に関しては、以下のことを述べることができる。ターゲット言語 （Ｃ＋＋）によるコードは、オブジェクトタイプの仕様および実現システムのた めに発生せしめられうる。仕様内のＣＯＮＳＴＲＵＣＴＯＲ、ＢＯＤＹ、および 拡張メソッドを含む全てのメソッドは、実現システム内において繰返されなけれ ばならない。ベースオブジェクトタイプのそれぞれの実現システムと、拡張オブ ジェクトタイプのそれぞれの実現システムとは、以下のルールに従わなければな らない。 −仕様内に示されているそれぞれのメソッドシグネチャ （ｍｅｔｈｏｄｎａｍｅ ｄｏｍ ＦｏｒｍａｌＡｒｇｕｍｅｎｔｓ 〔ＲＥＴＵＲＮＳ ｄｏｍ Ｔｙｐｅ〕部分）は、実現システム内にも常に存在 しなければならない。この要求は、以下に説明される方法の１つにより達成され うる。 ここでは、シグネチャは、問題となっているエレメント、ここではメソッド、 を、その名称、アーギュメントのタイプ、およびリターン値のタイプから開始す ることにより識別する概念を意味する。 −もしメソッドのシグネチャのみが、仕様内に述べられていれば、ＢＯＤＹメ ソッドは（ｄｏｍ ＢｅｈａｖｉｏｕｒＢｏｄｙ、すなわちＩＳ ＢＥＧＩＮ． ．．ＥＮＤ部分）、省略され、または実現システム内に述べられうる。 もしＢＯＤＹメソッドが実現システム内において省略されれば、該メソッドの フレームワークのみがターゲット言語により実現される。 −もしＢＯＤＹメソッドが実現システム内に述べられていれば、完全なコード がターゲット言語により発生せしめられる。 −もしＢＯＤＹメソッドがすでに仕様内に存在すれば、キーワードＡＳ ＳＰ ＥＣＩＦＩＣＡＴＩＯＮは、実現システム内のＢＯＤＹメソッドが仕様における と正確に同じであることを示すために、実現システム内において用いられうる。 この場合にも、完全なターゲット言語のコードが発生せしめられる。このコード は、手動による変更または追加のためには利用されえない。 −もし仕様および実現システムの双方が、同じメソッドのためのＢＯＤＹメソ ッドを定義していれば、完全なコードは実現システム内に述べられているＢＯＤ Ｙメソッドから発生せしめられる。これは、実現システム内に定義されている動 態が、仕様内に述べられている動態を常にオーバライドすることを意味する。 仕様内に述べられているアトリビュートは、実現システム内において繰返され るべきではない。実現システム内に述べられているメソッドの定義が、仕様内の 対応する定義を完全にオーバライドする事実により、仕様内に述べられているロ ーカル変数もまた実現システム内において繰返されなければならない。 以下には、図１１から図１４までを参照しつつ、拡張機構の使用を示すある例 が説明される。 図１１には、無条件拡張の例が示されている。この例は、ベースオブジェクト および拡張オブジェクトのそれぞれの仕様が、図示されているように述べられて いるという仮定から出発する。そこに示されていない拡張ビューには、ＴＯＰと して１１０２に示されている状態解析と、ＣＯＰとして１１０４および１１０６ に示されている状態呼出しと、がさらに述べられている。 実行が、ＴＯＰとして宣言されている状態に到達した時は、一般に全ての拡張 オブジェクトがチェックされる。もし現在のＴＯＰ状態から出発する拡張メソッ ドがあれば、その拡張メソッドが呼出される。実行時システムは、それに対して 、拡張オブジェクトの拡張メソッドの最初の呼出しの前のある時点に、対応する 拡張オブジェクトが作成されていることを知る。もしそれがベースの実行中にお いて拡張メソッドが呼出された初回でなければ、拡張オブジェクトの古いインス タンスが再び用いられうる。このオブジェクトは従って、同じベースの実行中に おけるその拡張メソッドの呼出し間の状態へ復帰する。拡張オブジェクトタイプ のインスタンスは、それぞれのベースオブジェクトに対して作成され、すなわち 、拡張オブジェクトは２つのベースによって共有されることはない。 図１１に与えられている例においては、矢印１１０８によって示されている、 拡張メソッドへの遷移が、ベースの実行が状態１１０２の解析に到達する毎に無 条件に常に行われる。 拡張メソッドの実行を終了するさまざまな方法が存在する。第１に、全実行ス レッドの実行を終了するために、ＥＸＩＴが用いられうる。第２に、拡張からの 制御の、その制御を行っていたベースへの復帰を表示するために用いられる、Ｂ ＡＣＫ（ＴＯ ＢＡＳＥ）と命名されている特定の可能性も存在する。第３に、 通常の終了状態が用いられうるが、拡張メソッドにおいて用いられると、それは 特定の意味を有する。この場合は、拡張メソッドの終了状態と同じ名称を有する ベースは、ＣＯＰ状態になっていなければならない。実行がこの終了状態に到達 した時は、拡張メソッドにおける実行は中断され、実行はベースにおけるＣＯＰ 状態において継続される。 拡張が開始されたベースにおける状態へのＥＸＩＴと、ＢＡＣＫとの相違は、 もし１つより多くの拡張が制御を同じＴＯＰへ引き継げば起こることにある。Ｂ ＡＣＫが用いられた時は、次の実行が代わりに実行される。最高優先順位のクラ スにおける拡張は、常に最初に実行され、もし同じ優先順位のクラス内に１つよ り多くの拡張が存在すれば、それらは通常任意の順序で実行される。しかし、も し拡張間にある実行順序を設定した、干渉拡張エンティティが存在すれば、それ らはこの順序で実行される。 もしＥＸＩＴが、実行が開始されるベースにおけるＴＯＰ状態に対して行われ れば、ベースのＴＯＰ状態は、同様に再び実行される全ての連結された拡張と共 に再び実行される。 図１２には、条件付き拡張の例が示されている。条件付き拡張とは、ある条件 が満たされたときにのみ実行される拡張である。この場合は、拡張メソッドの原 状態に関連するＣＡＳＥ式により指定される。この例は、ベースオブジェクトお よび拡張オブジェクトのそれぞれの仕様が、図示されているように示されている という仮定から出発する。図示されていない拡張ビューには、状態解析がＴＯＰ としてさらに述べられており、ａおよびｂはベースオブジェクト内のアトリビュ ートである。 ベースオブジェクトが、１２０２における状態解析に到達すると、拡張がこの ＴＯＰ点から開始されることになる。次に、拡張メソッドはその実行を、１２０ ４に示されている拡張メソッドの初期状態に関連するＣＡＳＥ式により開始する 。この式の値は、フローを分岐するために用いられる。 この場合、それは、１２０６に示されている、ベースにおけるＣＡＳＥ式の値 に関する単純なＲＥＳＵＬＴの問題である。式（ａ＋ｂ）が計算される。もしそ の値が３であれば、１２０８に示されている、値３により指示される分岐が選択 され、実行は拡張内において継続される。そうでない場合は、１２１０に示され ているＤＥＦＡＵＬＴ分岐が選択され、実行制御はベースへ復帰せしめられる。 その時ベースは、ＣＡＳＥ式を再評価しなければならず、それにより適切な分岐 によって継続することができる。 上述の例においては、拡張メソッドの原状態に関連するＣＡＳＥ式は極めて簡 単なものであった。しかし、それはスカラータイプの任意の式でありうる。 ＲＥＳＵＬＴは、拡張がベース内の非待ち状態におけるＣＡＳＥ式の結果を参 照することを可能にするために用いられる。ＲＥＳＵＬＴは、それぞれの式にお いて用いられるが、その値は、全拡張メソッドの実行中には変更されえない。も し適する分岐またはＤＥＦＡＵＬＴ分岐がなければ、エラーが存在する。もし拡 張メソッドが、ベースと同じ値をもつ分岐を有すれば、拡張メソッドはベースを オーバライドする。 もし拡張が、ベースにおける待ち状態から開始されれば、拡張メソッドの原状 態は同様に、待たれるさらなるイベントを指定する待ち状態でなければならない 。待ち状態においては、全ての拡張メソッドのための全ての予期される状態が、 この段階において単純なＷＡＩＴ−ＦＯＲ−ＥＶＥＮＴ内に収集される。 図１３は、イベント拡張の例を示し、ベースオブジェクトおよび拡張オブジェ クトの仕様が図におけると同様であるという仮定から出発する。さらに状態Ｒｉ ｎｇ Ｂは、図示されていない拡張ビュー内のＴＯＰとして指定されている。 ベースオブジェクトが、１３０２に示されている状態Ｒｉｎｇ Ｂに到達した 時は、このＴＯＰ点から開始される拡張が存在することが見出される。その時、 実行時システムは、拡張オブジェクトから、モニタされるべきイベントに関する 情報を収集し、この情報を待ち状態情報と共にベースオブジェクト内へ供給しな ければならない。そのようにして、複合待ち状態が作成され、かつ導入される。 その時現れるイベントに依存して、拡張またはベースが実行される。もし１３０ ４に示されているＢｌｏｃｋ Ｅｖが拡張内に指定されていれば、拡張メソッド が実行される。ベース内に指定され、１３０６に示されているＯｆｆ ｈｏｏｋ がもし受信されれば、ベースが実行される。 ２つの拡張が同じイベント、その上ベースと同じイベント、を待つことがあり うる。その場合は、最高優先順位を有する拡張が実行される。 拡張および待ち状態は、ＢＡＣＫ（ＴＯ ＢＡＳＥ）を実行しえず、それらは 、ベースにおけるＣＯＰ状態またはＥＸＩＴへ継続しなければならない。もし拡 張メソッドの実行が、拡張メソッドの原状態（例えば、上述の例における Ｓｔａｒｔ）へ復帰すれば、拡張メソッドは再び実行されるが、今回は拡張メソ ッドにおいて指定されたイベントのみが待たれる。もし「全」待ち状態が再び導 入されるべきであれば、待ち状態は、ベース内のＴＯＰ ＣＯＰ点として定めら れなければならず、ＴＯＰ ＣＯＰ状態「への継続（ｃｏｎｔｉｎｕｅ ｔｏ） 」は、拡張メソッド内に述べられていなければならない。 ベースオブジェクト内の１つの同じＴＯＰ点への、もっと多くの拡張が存在す ることも可能である。この場合、全ての拡張オブジェクトは、特定の優先順位に 従って編成されなければならず、実行はこの優先順位に従って行われ、すなわち 、最高優先順位を有する拡張オブジェクトは最初に実行される。もしこの拡張が 、その実行制御をベースへ復帰させれば、次の最高優先順位を有する拡張オブジ ェクトが実行される。もし全ての拡張が実行制御を復帰させれば、ベースもまた 実行される。 もし拡張メソッドが、ベース内の継続点へ継続されれば、それ以上の拡張メソ ッドは管理されない。実行はベース内へ極めて簡単に継続される。「継続される 」状態は、もちろん拡張を有しうる。もしこの場合であれば、全ては新たに開始 される。 図１４には、１４０２、１４０４、および１４０６にそれぞれ示されている３ つの拡張メソッドｍ２、ｍ３、およびｍ４と、１４１０に示されている拡張点Ｒ を有する、１４０８に示されているベースと、が与えられており、拡張点Ｒは、 １４１２に示されているように、ＴＯＰ ＣＯＰとして宣言されている。 第１拡張は、矢印１４１４により示されている、ベース内のＴＯＰ ＣＯＰ「 への継続」を行う。他の２つの拡張フローは、１４１６および１４１８にそれぞ れ示されているように、ＴＯＰ ＣＯＰ状態１４１０からの引き継ぎを行う。拡 張メソッドｍ３は、ＢＡＣＫを用いることにより実行制御をベースへ復帰させる 。もしｍ３がｍ４よりも高い優先順位を有すれば、１４２０に示されているよ うに、ｍ３が実行制御を復帰させるという条件のもとで、ｍ３がまず実行され、 ｍ４は続いて実行される。もしｍ４がｍ３よりも高い優先順位を有すれば、ｍ４ のみが実行される。この場合、ｍ４がベースへ復帰しない事実により、ｍ３が実 行される可能性はない。 付加機能間の相互作用を管理する相互作用管理拡張機能を実現するオブジェク トタイプも存在しうる。相互作用付加機能の使用は、例えば、以前のスウェーデ ン特許出願９３ ０２０２４−６および９４ ００２０９−４に説明されている 。そこに含まれている図１５ａ／ｌ５ｂに関連して後の出願に、ベース機能によ り行われるとして説明されている処置は、このようにして相互作用拡張オブジェ クトにより行われうる。それに関連して、図１４に関して上述された、ベースオ ブジェクト内の１つの同じＴＯＰ点に対する多くの拡張の連結に関する概念が、 例えば用いられうる。すなわち、相互作用拡張オブジェクトは、２つの相互作用 する拡張機能のそれぞれの１つを表す２つの拡張オブジェクトとして、ベースオ ブジェクト内の同じＴＯＰ点に連結されうる。相互作用問題の解決に関するさら なる情報については、上述のスウェーデン特許出願を参照されたい。

【手続補正書】特許法第１８４条の８第１項 【提出日】１９９８年３月１２日（１９９８．３．１２） 【補正内容】 請求の範囲 1. 加入者サービスを提供し、かつ、いくつかの機能レイヤ、すなわち、オペ レーティングシステム機能を有する１つのレイヤ（１０２）と、その上に配置さ れ、資源オブジェクトの形式の電気通信抽象物を含むアプリケーションプラット ホーム（１０４）と、その上の、ベースサービスおよび付加サービスを提供する ベース機能および付加機能の形式の所望のアプリケーションを含む最上部レイヤ （１０６）と、を含むオブジェクト指向システムプラットホームを有する、電気 通信システムにおいて、 前記加入者サービスを変更し、かつ拡張する方法であって、 前記最上部レイヤ内に、 将来拡張される必要がありうるベース機能を実現するオブジェクトタイプであ り、他のベースオブジェクトとの最小の調整により行われうる特定のタスクのた めに設計されている、ベースオブジェクトと、 前記ベース機能の拡張を行い、かつ、新しいサービスの追加と、すでに実現さ れ供給されているシステムのソフトウェアを変更することのない現存のサービス の変更および拡張と、を可能ならしめる、拡張機能を実現するオブジェクトタイ プである拡張オブジェクトと、 を備えるステップと、 変更されるべきベースオブジェクトに対して動的に結合されている動作中のシ ステム内への拡張の導入と、それぞれの拡張を起動／動作停止するための特定の サポートをプログラムすることのない、実行時における、前記システムの変更の 総称的な追加および除去と、を可能ならしめる前記拡張オブジェクトを設計する ステップと、 含まれているベースオブジェクトタイプおよび拡張オブジェクトタイプの動態 を、有限数の状態と、これらの状態間の遷移と、から成る有限状態マシンとして のそれぞれの含まれているメソッドの動態を記述することにより定めるステップ と、 前記遷移においてコードを遷移作用として実行するステップと、 実行制御をある拡張点において引き継ぎ、かつ該制御を同じメソッドにおける 別の拡張点または同じ拡張点へ復帰させる前記状態において前記拡張を追加する ステップと、 を含む、前記方法。 2. 拡張機能（２０８）を実現するオブジェクトタイプである拡張オブジェク トであって、それらが前記拡張機能に対する拡張を形成する該拡張オブジェクト をさらに実現するステップを含む、請求項１に記載の方法。 3. 付加サービス間の相互作用を管理する、相互作用管理拡張機能を実現する オブジェクトタイプである拡張オブジェクトをさらに実現するステップを含む、 請求項１または請求項２に記載の方法。 4. 特定の所定の拡張点において拡張制御を引き継ぐことにより前記システム の動態を間接的に変更する、前記システム内へ前記拡張の定義のみをロードする ステップを含む、請求項１から請求項３までのいずれかに記載の方法。 5. 拡張オブジェクトのための仕様内に、該拡張オブジェクト内のいずれの拡 張点において前記拡張が前記制御を引き継ぐと仮定されているかを、また、いず れの拡張点においてそれが前記制御を復帰させうるかを、定めるステップを含む 、請求項１から請求項４までのいずれかに記載の方法。 6. 拡張オブジェクトが前記制御を引き継いだ時、あらかじめ定められている 拡張メソッドにより実行を開始するステップを含む、請求項５に記載の方法。 7. 実行時システムにより、拡張オブジェクトの作成と、前述の拡張点におけ る該拡張オブジェクトの拡張メソッドの呼出しと、を処理するステップを含む、 請求項５または請求項６に記載の方法。 8. 前記拡張が前記ベースオブジェクトまたは前記拡張オブジェクトから前記 制御を引き継ぐ、該ベースオブジェクトまたは該拡張オブジェクトのアトリビュ ートおよびメソッドへのアクセスを拡張オブジェクトに対して与えるステップを 含む、請求項１から請求項７までのいずれかに記載の方法。 9. 全ての前記アトリビュートおよびメソッドを、アクセス可能なオブジェク トタイプ仕様内に宣言するステップを含む、請求項８に記載の方法。 10. 前記オブジェクトタイプ仕様内にまた、ある拡張点において前記制御を引 き継ぐ拡張のために、前記仕様内の前記アトリビュートおよびメソッドの特定の 部分集合のみが利用されうることを定めることにより、それぞれの拡張点のため のアクセス制限を定めるステップを含む、請求項５から請求項９までのいずれか に記載の方法。 11. 可能オブジェクトのための前記オブジェクトタイプ仕様を、前記拡張可能 オブジェクトの拡張にとって明らかであり且つ利用可能である情報の量の範囲を 定めるインタフェースのように働くものとして備えるステップを含む、請求項４ から請求項１０までのいずれかに記載の方法。 12. 拡張ビューを用いて拡張によりアクセスされうべき拡張可能オブジェクト の仕様内の情報の部分集合をそれぞれの前記拡張ビューが定めている該拡張ビュ ーにより定められる、インタフェースレイヤを実現するステップを含む、請求項 １１に記載の方法。 13. ベースオブジェクトのために、前記拡張が利用しうる状態、アトリビュー ト、およびメソッドを示すインタフェース記述として働き、かつ、前記ベースオ ブジェクトのインスタンスを作成することを必要とするクライアントオブジェク トに向けてのインタフェースを定める、仕様を備えるステップであって、該イン タフェースが、新しいインスタンスを作成する時に用いられるべきパラメータを 決定する前記ベースオブジェクトタイプのメソッドにより定められる、該ステッ プを含む、請求項１から請求項１２までのいずれかに記載の方法。 14. 前記オブジェクトタイプの機能の理解を得るために必要でないインプリメ ンテーションの細部を省きつつ、前記ベースオブジェクトタイプの動態の高レベ ルの記述を与えるための前記仕様を実現するステップを含む、請求項１３に記載 の方法。 15. 前記ベースオブジェクトにより用いられるオブジェクト論理と、該オブジ ェクト論理の使用を含む前記ベースオブジェクトにおけるローカルメソッドと、 により抽象レイヤを作成するステップを含む、請求項１４に記載の方法。 16. 前記ベースオブジェクトの待ち状態と、もしあれば、前記ベースオブジェ クトの機能を理解するために重要である選択された非待ち状態と、を仕様内に示 し、かつ、前記仕様内に宣言されているローカルメソッド内へ前記状態間におけ る実行のためのコードを導入するステップを含む、請求項１５に記載の方法。 17. 将来拡張を受けそうなオブジェクトタイプの部分を考慮しつつ、前記仕様 の内容を決定するステップを含む、請求項１６に記載の方法。 18. 全ての状態、待ち状態および非待ち状態、および全ての明示的に命名され た拡張点を、メソッド仕様内に示し、かつ、ローカルメソッドにおける状態遷移 においてアクションコードを用いるステップを含む、請求項１７に記載の方法。 19. 拡張可能である必要のない動態の部分を認識し、これらの部分を全体とし て、仕様または実現システムにおいて、またはインプリメンテーションレベルに おいて定められるローカルメソッド内へ導入するステップを含む、請求項１８に 記載の方法。 20. 拡張可能である必要のない、または拡張可能でありえない、かつ、高レベ ルの記述を作成するために仕様内に示される必要はないがインプリメンテーショ ン言語を直接用いる代わりに定義を与えることが好ましい、ベースオブジェクト の部分のために、前記オブジェクトタイプの実現システムを用いるステップを含 む、請求項１９に記載の方法。 21. 前記実現システム内に、アクションコードを導入するローカルメソッドの 定義を含めるステップを含む、請求項２０に記載の方法。 22. 仕様内に指定されている動態の精密化を意味する詳細な動態の定義を、前 記仕様内に含まれている動態の定義をオーバライドしつつ、前記実現システム内 に含めるステップを含む、請求項２０または請求項２１に記載の方法。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，Ｓ Ｚ，ＵＧ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ， ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，Ｇ Ｅ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ， ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，Ｐ Ｌ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ， ＶＮ (72)発明者 チュン，エウイ，スク アメリカ合衆国62154 マサチューセッツ 州ウォルサム，スターンズ ヒル ロード 2209

Claims (1)

1. 【特許請求の範囲】 1. 加入者サービスを提供する、電気通信システムのためのオブジェクト指向 システムプラットホームであって、該プラットホームは、いくつかの機能レイヤ 、すなわち、オペレーティングシステム機能を有する１つのレイヤ（１０２）と 、その上に配置され、資源オブジェクトの形式の電気通信抽象物を含むアプリケ ーションプラットホーム（１０４）と、その上の、ベースサービスおよび付加サ ービスを提供するベース機能および付加機能の形式の所望のアプリケーションを 含む最上部レイヤ（１０６）と、を含み、該最上部レイヤが、ベースオブジェク ト（２０２）および拡張オブジェクト（２０４、２０６、２０８）によって構成 され、 前記ベースオブジェクトが、将来拡張される必要がありうるベース機能を実現 するオブジェクトタイプであり、それぞれのベースオブジェクトタイプが、他の ベースオブジェクトとの最小の調整により行われうる特定のタスクのために設計 されており、 前記拡張オブジェクトが拡張機能を実現するオブジェクトタイプであり、該拡 張機能が、前記ベース機能の拡張であり、かつ、新しいサービスの追加と、すで に実現され供給されているシステムのソフトウェアを変更することのない現存の サービスの変更および拡張と、を可能ならしめている、 ことを特徴とする、前記システムプラットホーム。 2. 前記拡張オブジェクトがまた、拡張機能（２０８）を実現するオブジェク トタイプを含み、それらが前記拡張機能に対する拡張を形成することを特徴とす る、請求項１に記載のシステムプラットホーム。 3. 前記拡張オブジェクトがまた、相互作用管理拡張機能を実現するオブジェ クトタイプを含み、それらが付加サービス間の相互作用を管理することを特徴と する、請求項１または請求項２に記載のシステムプラットホーム。 4. 前記拡張オブジェクトが、動作中のシステム内への拡張の導入を可能なら しめるために設計されており、それらが変更されるべき前記ベースオブジェクト に対して動的に結合されていることを特徴とする、請求項１から請求項３までの いずれかに記載のシステムプラットホーム。 5. 前記拡張が、それぞれの拡張を起動／動作停止するための特定のサポート をプログラムすることなく、実行時に、総称的に前記システムの変更の追加およ び除去を可能にするように設計されていることを特徴とする、請求項４に記載の システムプラットホーム。 6. 含まれているベースオブジェクトタイプおよび拡張オブジェクトタイプの 動態が、有限数の状態と、これらの状態間の遷移と、から成る有限状態マシンに 含まれているそれぞれのメソッドの動態を記述することにより定められ、コード が遷移作用として実行され、前記拡張が、実行制御をある拡張点において引き継 ぎ、かつ該制御を同じメソッドにおける別の拡張点または同じ拡張点へ復帰させ る状態において追加されることを特徴とする、請求項５に記載のシステムプラッ トホーム。 7. 前記ベースオブジェクトタイプおよび拡張オブジェクトタイプが、前記シ ステムの現存のインプリメンテーションを変更する必要なく、特定の所定の拡張 点において拡張制御を引き継ぐことにより前記システムの動態を間接的に変更す る、前記システム内へ前記拡張の定義のみをロードすることにより、前記システ ムの変更および拡張を可能にする拡張概念をサポートすることを特徴とする、請 求項１から請求項６までのいずれかに記載のシステムプラットホーム。 8. 拡張オブジェクトのための仕様が、該拡張オブジェクト内のいずれの拡張 点において前記拡張が前記制御を引き継ぐと仮定されているかを、また、いずれ の拡張点においてそれが前記制御を復帰させうるかを、定めていることを特徴と する、請求項１から請求項７までのいずれかに記載のシステムプラットホーム。 9. 拡張オブジェクトが前記制御を引き継いだ時、あらかじめ定められている 拡張メソッドが実行を開始することを特徴とする、請求項８に記載のシステムプ ラットホーム。 10. 実行時システムが、拡張オブジェクトの作成と、前述の拡張点における該 拡張オブジェクトの拡張メソッドの呼出しと、を処理することを特徴とする、請 求項８または請求項９に記載のシステムプラットホーム。 11. 前記拡張が前記ベースオブジェクトまたは前記拡張オブジェクトから前記 制御を引き継ぐ、該ベースオブジェクトまたは該拡張オブジェクトのアトリビュ ートおよびメソッドへのアクセスを拡張オブジェクトが有することを特徴とする 、請求項１から請求項１２までのいずれかに記載のシステムプラットホーム。 12. 前記アトリビュートおよびメソッドが、アクセスされうるオブジェクトタ イプ仕様内に宣言されているもののみを含むことを特徴とする、請求項１１に記 載のシステムプラットホーム。 13. 前記オブジェクトタイプ仕様内にまた、ある拡張点において前記制御を引 き継ぐ拡張のために、前記仕様内の前記アトリビュートおよびメソッドの特定の 部分集合のみが利用されうることを定めることにより、それぞれの拡張点のため のアクセス制限が定められていることを特徴とする、請求項８から請求項１２ま でのいずれかに記載のシステムプラットホーム。 14. 拡張可能オブジェクトのための前記オブジェクトタイプ仕様が、前記拡張 可能オブジェクトの拡張にとって明らかであり且つ利用可能である情報の量の範 囲を定めるインタフェースのように働くことを特徴とする、請求項７から請求項 １３までのいずれかに記載のシステムプラットホーム。 15. 前記拡張概念と共に用いられ、かつ、拡張ビューを用いて前記拡張により アクセスされうべき拡張可能オブジェクトの仕様内の情報の部分集合をそれぞれ の前記拡張ビューが定めている該拡張ビューにより定められる、インタフェース レイヤを特徴とする、請求項１４に記載のシステムプラットホーム。 16. ベースオブジェクトのために、一方では、前記拡張が利用しうる状態、ア トリビュート、およびメソッドを示すインタフェース記述として働き、他方では 、前記ベースオブジェクトのインスタンスを作成することを必要とするクライア ントオブジェクトに向けてのインタフェースを定める、仕様が存在し、該インタ フェースが、新しいインスタンスを作成する時に用いられうるパラメータを決定 する前記ベースオブジェクトタイプのメソッドにより定められることを特徴とす る、請求項１から請求項１５までのいずれかに記載のシステムプラットホーム。 17. 前記仕様が、前記オブジェクトタイプの機能の理解を得るために必要でな いインプリメンテーションの細部を省きつつ、前記ベースオブジェクトタイプの 動態の高レベルの記述を与えていることを特徴とする、請求項１６に記載のシス テムプラットホーム。 18. 前記ベースオブジェクトにより用いられる基礎を成すオブジェクト論理に より作成される抽象レイヤと、該オブジェクト論理の使用を含む前記ベースオブ ジェクトにおけるローカルメソッドとが、高抽象レベルに寄与することを特徴と する、請求項１７に記載のシステムプラットホーム。 19. 仕様における適度の抽象レベルが、該仕様内の前記ベースオブジェクトの 待ち状態と、前記ベースオブジェクトの機能を理解するために重要である、恐ら くはある選択された非待ち状態と、を示すことにより得られ、該示された状態間 における実行のためのコードが、仕様内に宣言されているが必ずしも動態を指定 されてはいないローカルメソッドへ導入されることを特徴とする、請求項１８に 記載のシステムプラットホーム。 20. 前記仕様内に示されるべき事柄の判断が、前記オブジェクトタイプのいず れの部分が将来拡張を受けうるかの考慮を含むことを特徴とする、請求項１９記 載のシステムプラットホーム。 21. 全ての状態、待ち状態および非待ち状態の双方、および全ての明示的に命 名された拡張点が、メソッド仕様内に示され、アクションコードが、ローカルメ ソッドにおける状態遷移において用いられることを特徴とする、請求項２０に記 載のシステムプラットホーム。 22. もし動態のある部分が拡張可能である必要がなければ、これらが全体とし て、仕様において、または実現システムにおいて、またはインプリメンテーショ ンレベルにおいて定められるローカルメソッド内へ導入されることを特徴とする 、請求項２０に記載のシステムプラットホーム。 23. 前記オブジェクトタイプの実現システムが、拡張可能である必要のない、 または拡張可能でありえないベースオブジェクトの部分であって、それらの部分 は高レベルの記述を作成するために仕様内に示される必要はないがインプリメン テーション言語を直接用いる代わりに定義を与えることが好ましい前記部分のた めに用いられることを特徴とする、請求項２２に記載のシステムプラットホーム 。 24. 前記実現システム内に、アクションコードを導入するローカルメソッドの 定義が導入されることを特徴とする、請求項２３に記載のシステムプラットホー ム。 25. 仕様内に与えられている動態仕様の精密化を意味するさらに詳細な動態の 定義が、前記仕様内に含まれる動態の定義をオーバライドしつつ、前記実現シス テム内に与えられることを特徴とする、請求項２３または請求項２４に記載のシ ステムプラットホーム。