JPH06510150A - 通信スィッチングシステムのソフトウエア構造 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるため要約のデータは記録されません。

Description

【発明の詳細な説明】 通信スイッチングシステムのソフトウェア構造発明の背景 この特許文書の開示の一部には、著作権法の対象となっている題材が含まれてい る。該著作権所有者は、特許商標庁てあきらかなように、特許出願及び記録、特 許文書或いは特許開示のいずれか一方による複写再生には異議を存しない。しか し、他の点では全ての著作権か保持本発明は通信スイッチングシステムに関し、 更に詳細には、通信スイッチングシステムのプロセス制御ソフトウェアの構造と 開発に関する。

関連技術の記述 通信スイッチングシステムにより制御される、保持されたプログラム用のアプリ ケーションプログラム及びソフトウニアーチテクチャ−上の構造の開発は、歴史 的に複雑で時間のかかる仕事であった。該プロセスは、システムか作動するハー ドウェアでの実際のリアル−タイムコードのテストに供給されるサービスの相互 作用及び動作を規定する機能的仕様の開発から始まって多くのステップを要求す る。このようなソフトウェアアーチテクチャ−の開発は、該開発の異なる面でそ れぞれ働き、また、開発段階の途上におけるそれぞれのステ・ノブで複数の活動 をコープイネ−ジョンする必要かあるような多数の異なる開発者の相互作用（ｉ ｎｔｅｒａｃｔｉｏｎ　）をも必要としｊこ。

従って、ユーザの要求による機能と特徴とを実行するｔこめの新しいラフｌ−ウ ェアシステムを車中に導入することは、多額の費用かかかり、また、システムが 設計され、開発され、試験され、市場で商業的に実施されるまで（こは困難か伴 うとともに時間かかかるプロセスで、時としてユーザの要求が代わり、新たな要 求か成されることカベあった。

なんらかのソフトウェアシステムの開発におし）で主として考慮される事項の１ つは、システムを構成するときに採用されるプログラミングの方法の選択である 。プログラミングの際の良く知られている従来技術の方法は、例えば“ＡＤＡ” 或いは”ＰΔ５ＣＡＬ”のような言ａ言でのプロセス向きのプログラミングと、 例えば“Ｃ４４″或いは“Ｓ　Ｍ　Ａ　Ｌ　Ｌ　Ｔ　Ａ　Ｌ　Ｋ”のような言語 ての目０９Ｉ！ｈ向きのプログラミングと、例えば“ＰＲＯＬＯＧ”或し）は° ’ＬＩＳＰ”のような言語ての宣言プログラミングとかある。これら言語のどれ もか、通信スイ・ソチングノフトウエア開発のための所望の特徴の完全なセ・ソ トを含むものではなかった。例えば、プロセス向きプログラミング言語の基本コ ンセプトは、プログラムされる目的ａｈの良好な規定と良好な理解とを提供する ことにある。し力１しこれは、プロセスにおける動作又は述語の構成及び規定の ために、非常に限定された支持しか与えなかった。

プロセスにおいて動作をプログラミングする際に、設計者は、アブリケーション ソフ１−ウェア内に非常に多くの数の独立した明細を提供することか要求された 。同様に、プログラミング言語のＰＡＳＣＡＬ／ＡＤＡ世代はデータを規定し扱 うためにいくつかの支持を与えるが、プログラマは、実際に作りだされるアプリ ケーションにおいては行われることか非常に少ない明細レベルでの多くの仕事を 行うことかやはり要求された。

最新の目的語向きのプログラミング方法でさえもそれ自身の制限を有していた。

このようなプログラミングの目的語向き方法は、目的語を規定し承継する種々の 技術に、そして、目的語を如何にドキメントするかに関心が向けられていた。こ れらの技術は、規定し扱う多くの数の目的語を含む開発プログラムの場合にはか なり寄与するか、明瞭さや構造に関する多くの問題か、プログラムか其自身目的 語として規定されるときに生じた。

しかしなから、通信システムのようなプロセス制御プログラムにおいて、プログ ラムの構成要素は、システム内での活用を指向し動作する目的語で常にある。通 信プロセスプログラムシステムの目的語は、基本的には次の２つのタイプである 。

（１）このような全てのプログラムシステムは、プログラムか動作するデータの タームで規定される内部目的語である。これらの目的語は、ソフトウェアシステ ムの実在性で、そして、該データはプログラムの操作する実世界（ｒｅａｌ　ｗ ｏｒｌｄ）の静止画像である。

（２）しかしなから、全てのリアルタイム及びプロセス制御システムは、プログ ラムシステムの外の動的な目的語で動作する。このような動的目的語の例は、表 示スクリーン或いは電話のイメージ、及び、通信システムのトランクである。こ れらのプログラムシステムは、データの目的として表される動的目的語を含むも のである。

データと共に動作をカプセル化し、そして、目的語としてそれを全て規定する該 目的語向きのプログラミング技術は、プログラムかその目的語に緊密に関連する ルーチンであるとき、明瞭な利点を有する。このようなルーチンの例は、表示ス クリーンを表すシステムや、同様に通信システムのラインインターフェイス部分 において見いたされる。しかしなから、もし、このようなプロセス制御ソフトウ ニアシステムにおける制御プログラムが、目的語として全て規定されるなら、あ る否定的な効果も発生する。第１に、制御プログラムか断片化され、非常に複雑 な相互作用になり、また、関連か目的語の間において必要になる。このような結 果か、全体的な制御構造を必要とし、また、公知の目的語−基準通信システムに おいて、複雑なＣ，Ｃ，］、Ｔ、Ｔ　仕様設計言語（ｓｐｅｃｉｆｉｃａｔｉｏ ｎ　ｄｅｓｉｇｎ　ｌａｎｇｕａｇｅ　５ＤＬ）フローチャートか、このような 制御構造を記述するために必要になる。

更に、例えそのようなフローチャー１−を用いたとしても、該目的語間の動的な 関係を記述し理解することはやはり非常に困難である。第２に、制御ソフトウェ アシステムの構成要素か目的語により規定されないとき、なんらかの説明のモデ ルか本質的に欠陥を有することになる。該プログラム動作、即ちその述部か、［ １的語と共に扱われるようになり、このため、目的語と動作との両方を位置させ ることか非常に困難になる。これが、プロセス制御システムの動作を論理グルー プへの組織化を殆ど不可能にする。更に、設計者は、機構を見る人への高度な理 解性と、そこで働く設計者のための容易性との両方が成立するよう自然な方法で 、アプリケージヨレを構造することが不可能になる。

ＰＲＯＬＯＧやＬＩＳＰのような宣言プログラミング言語の最新の世代は、大変 効率的で、プログラミング及びソフトウェア設計の仕事量を減らす。これは、（ ａ）全プログラミングか記号形状で行える。（ｂ）述部のコンセプ１−と力強い 指示の全く新たなセットとかこれらの言語に含まれる。これらの言語の使用は、 関連する必要なプログラマの明細の数と、プログラムカプセル化の重要性とを劇 的に減らすことかできる。保持されプログラムされた制御通信スイッチングシス テムのようなリアルタイムシステム及びプロセス制御での宣言言語の利用の実際 の不利益は、それらのリアルタイム能力が不十分で、また、それらの並列的な扱 いの能力かないことにある。

多くの新たな宣言的或いは目的語向きにされたプログラミング言語は、プログラ マか機能即ちプログラムの迅速なプロ１へタイプを作成てきるようにするために 用いられてきた。迅速なプロトタイプ作成技術は、アプリケージヨレ即ちシステ ムの開発及び設計能力を増大させることに依る幾つかの顕著な利点を存する。潜 在的に高価となる設計エラーは、開発のプロセスの初期段階に発見され訂正され る。システムの個々の面は、非常に早く実行され、また試験され、長い試験及び ／又は実行の期間か避けられ、迅速なプロトタイプ開発か、アプリケージヨレ即 ち機能に関するオプションの数を広げることを設計者に許容する。プロ１へタイ プ作成における他の利点も同様に存在する。

迅速なプロ１−タイプ作成の技術も、同様に通信システムのコンチクストにおけ る利益を有する。しかしながら、今まて該技術は、通信システム及びこれらの動 作の並列特性で生じるプロセシングの活用のリアルタイム特性によって幾度か後 退した。本発明のシステムは、以前から知られているプロトタイプ作成の方法及 び能力に広げられている一定の面を在し、これにより、迅速なプロトタイプ作成 を、通信システムとの接続において効率的に用いることかできる。通信システム との接続において用いるプロトタイプ作成の技術についての実験か、゛通信シス テムの迅速なプロトタイプ作成のための使用プロローグ、Ｊ、Ｌ、Ａｒｍｓｔｒ ｏｎｇ　及び　Ｍ　ＣｌＷｉｌｌｉａｍｓ、第７回通信スイソチンクシステムの ソフトウェアエンジニアリング国際会議、１９８９年７月３日−６日、ホーマン ス、そして、“プログラミング言語の実験及び通信適用の技術”、Ｂ、Ｄａｃｋ ｅｒ。

Ｎ、ＥＩｓｈｉｅｗｇ、　Ｐ、Ｈｅｄｅｌａｎｄ。

Ｃ−Ｗ　Ｗｅ　Ｉ　ｉ　ｎ、Ｍ、　Ｗｉ　Ｉ　Ｉ　ｉ　ａｍｓ、第６回通信スイ ッチングシステムのソフトウェアエンジニアリング国際会議、１９８６年４月１ ４日−１８日、アイントホベン（Ｅｉｎｄｈｏｖｅｎ）に開示されている。これ らの開示は本願の参照に採り入れられる。

宣言言語ＥＲＬＡＮＧの開発は２つの問題を本質的に解決し、宣言言語の世界へ のプロセス制御コンセブ（・の導入を許容する。ＥＲＬＡＮＧ言語の基本的なコ ンセブトは、”ＥＲＬＡＮＧ　：実験的な電話のプログラミング言語”手続き、 Ｘ１１１　国際スイッチングンンポジュームＩＩＩ版Ｐ４８　（１９９０年）に 記述されており、これが本願の参照に取り入れられる。更に詳細な取扱か、“Ｅ ｒ　］　ａｎｇ　ユーザガイド　＆　参考取扱書“及び“Ｅｒｌａｎｇ　ＢＩＦ 　ガイド”に見いだされ、添付Ａとして取り入れられる。このような言語の利用 か、本発明のシステムに基づくリアルタイムプロセス制御ソフトウェアの構築を 可能にする。

発明の概略 １つの局面において、本発明のシステムは、通信スイノチングシステムのような プロセス制御システムのプログラミングに用いる宣言言語構成を有する。該言語 構造は、動作のプロセスによって表される主語と、プログラミング手続きとして 規定される宣言言語の述語により表される述語と、目的語プロセスに含まれ記号 形状で規定される実世界構成要素及びデータによって表される目的語とを含む自 然言語要素を有する。

池の面において、本発明のシステムは、機能的仕様を用意しその後にユーザへ向 けたこれら機能的仕様のマツピングを行う手続きと、本発明の宣言言語構造を採 用するネットワーク機能的構成要素とを含む通信スイッチングシステムのための プロトタイプソフトウェアの構成のための方法を有している。

更に他の面において、本発明は、通信スイッチングシステムのようなプロセス制 御システムのためのソフトウェアアーチテクチャ−を含む。この面で、該システ ムは、機能性の高められたレベルを提供するために、それぞれか相互に協動する 、アプリケーション層と、アプリヶーノヨン動作システム層と、基本動作システ ム層とを含む階層化されたアーチテクチャ−を含む。

更に池の面で、発明は、通信スイッチングシステムのためのプロ！・タイプノフ トウェアシステムを構成するための方法を在し、そこでは、ソフトウェアシステ ムのサービス面の全体的な記述か、ユーザの視点から最初に規定されている。ユ ーザ中の現実の主語を形成するユーザンーケンスの開始と終了か識別される。次 に、システム内の情報の流れ及び機能的構成要素が特定され、単一で共通の述語 の機能的構成要素及び識別がマツプにされる。

最後に、実世界構成要素が、システム内の目的語として表される。

また更に他の面で、発明は、通信スイッチングシステム内で用いられる多層ソフ トウェアアーチテクチャ−を含み、それは、スイッチングシステム内の通信特徴 を実施するためのアプリケーション層を含み、また、識別される通信アプリケー ションへの直接相当で構成される。

アプリケーション動作システム層は、アプリケーション層へ支持機能と、通信ア プリケーションの配置計画明細を隠し隔離するために提供されている。基本動作 システム層は、時分割コンピュータシステムのための実行時間執行部と、基準原 型と同様な通信機能の配置計画のために必要とされる機能及び原型とを含む。こ の面での１つの実施例か、その中に採用されるシグナリングプロトコルを含み、 実施される通信機能或いはアプリケーション内の特定の作業を規定する作業モジ ュールを有する。なんらかのケースにおいて、もし特徴の設置計画がそれと直接 関連する特定された管理機能を要求しないなら、作業は単に１以上の特徴モジュ ールから構成される。同様に、特徴モジュールを含まない、１以上の管理モジュ ールのみからなる作業の例が存在し得る。最後に、作業モジュールは、１以上の 管理モジュールと一緒の１以上の特徴モジュールの両方からなることができる。

更に池の面において、本発明は基本動作システム層内のデータヘースと、アプリ ケーション層内の少なくとも１つの管理モジュール及び少なくとも１つの特徴モ ジュールとを含む通信スイッチングシステムのアーチテクチャ−内のデータを管 理するためのシステムを有する。特徴−単一データフィールドかデータペース内 で創造され、特徴モジュールの初期部分によってフォーマット、制限、不履行値 か割り当てられる。該管理モジュールの初期部分は、データペース内のデータフ ィールドを参照するパラメータ及び命令を創造し、該データヘースに該パラメー タ及び命令を保持する。それぞれの命令かその受信により解析され、その利用の 典拠のため、及び、そのパラメータか予め選択された制限値内か否がかチェック される。適切な固体か、該命令の受信に応答して管理特徴によりアクセスされ、 命令に応答してフィールドを修正するために、適切な特徴単一データフィールド か動作させら第１る。

既にこの分野の当業者には明らかなように、発明の適用及び原理は、他のソフト ウェアシステム、いろいろな池のコンピュータ、通信スイッチングシステムに加 えてプロセス制ｉ卸アブリケーソヨンで有利に用いることかできる。

図面の簡単な説明 本発明及び本発明の更なる目的及び利点の理解のため、参照か添付の図面ととも に次の記述により成される。こ第１図は、通信スイッチング機械の制御のための プロトタイプソフトウェアの開発への本発明のシステムの適用を示すブロック図 である。

第２図は、プロトタイプソフトウェアの開発に採用されるステップのブロック図 である。

第３図は、本発明のシステムに基づくソフトウェア開発を示すフローチャートで ある。

第４図は、本発明に基づく通信ソフトウェア開発のサービス面を特定したステッ プを示すフローチャートである。

第５図は、本発明に基づく通信ソフトウェアの開発の機能ネットワーク面の仕様 を示すフローチャートである。

第６図は、本発明に基づくソフトウェアシステム構造の機能的仕様からの機能的 構成要素のマツピングを示すブロック図である。

第７図は、本発明に基づく、仕様からソフトウェアシステムへのネットワークの 場合の機能的構成要素のマツピングを示すブロック図である。

第８図は、本発明に基づき構成された通信スイッチングシステムのためのソフト ウェアの全体的なアーチテクチャ−を示すブロック図である。

第９図は、本発明の通信ソフトウェアシステムアーチテクチャ−を示すブロック 図である。

第１０図は、ユーザモジュールのトラフィック部分が本発明により階層的に構築 された手法を示すブロック図である。

第１１図は、本発明のソフトウェアシステムの、別のアーチテクチャ−のデータ 扱い動作を示すプロ・ツク図である。

第１２図は、本システムの発呼側分離面を示すブロック図である。

第１３図は、本発明の発呼側の相互作用を示すブロック図である。

第１４図〜第１６図は、本システムの機能特徴の設置計画の種々の面を示す図で ある。

第１７図は、プロトタイプ用の本システムが機能する全体的な開発環境を表すブ ロック図である。

第１８図は、本発明のシステムと、他の公知のあるシステムとの一定の相違を示 すブロック図である。

詳細な記述 本発明のシステムは、特に、通信システムのようなリアルタイムプロセス制御シ ステムのソフトウェアに用いるため適用されるプログラミング言語構造を含んで いる幾つかの異なる関連する面と：通信スイッチングに用いられるプロトタイブ ソフ１へウェアの用意のために用いられる方法論と：通信スイッチングシステム のためのソフトウェアアーチテクチャ−及びプログラム構成ツールとからなる。

本発明のこれらの異なるそれぞれの面及びこれらの相互関係の両方か、これらの 論理的及び技術的基礎と、また、それに実用的に用いられるラフｌ−ウェアシス テムの動作とに関連し、以下に記述される。

ソフトウェア構成の方法論 ト述したように、それぞれ良く知られているプロセス適合されたプログラミング 、目的語向きにされたプログラミング、及び宣言言語プログラミングは、通信ス イッチングシステムに存在するようなリアルタイムプロセス制御環境に適用され る際には、一定の本来的な欠点を有する。本発明のシステムに用いられるリアル タイムプロセスのようなプログラミング構造方法は、新規な言語構成技術で強固 な宣言言語を採用することにより、リアルタイム処理を扱い、並列動作を同様に 遂行するための能力を取り入れ、明瞭で簡単に理解できるアプリケーション向き のソフトウェアアーチテクチャ−を生み出す。

本発明のシステムの言語構成技術は、主語と述語と目的語との３つの自然言語要 素を用いることより特徴付けられる。主語は動作のプロセスによって表され、一 方述語はプログラム手続きとして規定される宣言言語の述語により表される。目 的語は、通信のトランク及び電話のような実世界構成要素によって表され、これ らは全て記号形状によって規定され、また、目的語プロセスに含まれる。本技術 は、ソフトウェア設計者が、構成されるアプリケーション構造の異なる構成要素 の規定に集中することを可能にするだけでなく、これを強固に力づける。

人間言語の３つの基本要素の使用は、創造されるモデルを強力なだけてなく明瞭 かつ容易に理解できるようにすることを許容する。更に、本言語構成は、活性主 語の規範（ｐａｒａｄｉｇｍ　ｏｆ　ａｃｔｉｖｅ　５ｕｂｊｅｃｔｓ　＋Ｐ　 Ａ　ＣＳ″）であると見ることかできる。

本発明において、主語は、述語の１つのソーケンス或いは述語の幾つかのノーケ ンスとして規定され、行い得る動作によって特徴付けられる。゛ソフトウェアに おいて自然で理解し易い構成要素を形成するため、これか、グループ内への全て の機能を構成するための強力な機構を提供する。プロセスコンセットの利用かリ アルタイムの多数の問題を解決し、更に、“主語“の言語要素をコンビコータプ ログラミング言語の構造への導入を支持する。

本システムにおいて、主語プロセスは、実世界で個人か石工、商人、大工のよう にそれぞれか名付けられ識別されているのと同様な方法で、動作のその内容に関 連して名付けられ特定される。これか動作量の関連の自然な特定を可能にする。

例えば、ＰＢＸソフトウェアシステムにおいて、この面か、ザーピス相互作用と して知られており、本方法論に適用されており、これは、目的語仕様の自然部分 になる。しかしなから、アプリケーション或いはサーヒスのための適切な主語を 規定するために、実際のアプリケーションの完全な知識か要求される。主ａｈコ ンセプ１〜か、ソフトウェア開発の焦点を低−レヘ／Ｌの構成要素の明細から全 体のアプリケーションへ向けて動かす労力を支持し、ユーザー規定の問題を解決 する。

本システムにおいて、開発されるアプリケーション或いはシステムの設計者の概 念化における抽象化のいずれか最も低いレベルを除き、主語を規定することを可 能にする。抽象化の最も高いレベルにおいて、システムの全体の機能を規定し、 或いは破壊する主語か存在する。全体の制御シーケンスと該システムからの流れ とを提供する最高レベルの主語は、伝統的なプログラミング言語で用いられてい る主プログラム或いはルーチンと似ている。

本発明のシステムのこの面で、主語は主語一連語−目的語のプロセスのシーケン ス、或いは、単に述語と目的語のプロセスのシーケンスから成り、この主語の一 部を形成する活用（ａｃｔｉｖｉｔｉｅｓ）の全てのセットを規定する。

本システムで主語として規定されることがある機能或いは活用の例は、（ａ）通 信スイッチングシステムの活用と（ｂ）システム内で如何にサーヒスが利用でき るかに関する通信システムの質問とを含むか、これに限定される訳ではない。述 語の１つのシーケンス或いは述語の幾つかのシーケンスとして規定される主語は 、特徴の特定の面を扱う特徴モジュールのユーザ部分内で、活用或いは制御流と して解釈されることかあることを理解すべきてあろう。この特徴モジュールは、 本発明の“改善されたプロトタイプ作成技術”と“ソフトウェアアーチテクチャ −及び技術”面の関連する欄に以下のように記述されている。ここに続くものは 、主語を規定する本発明のシステムで用いることかてきる゛疑似符号”のサンプ ル七ノ１−である。

＜５ｕｂｊｅｃｔ　Ｄｅｆｉｎｉ【ｉｏｎ＞＜Ｄｅｓｃｒｉｐｔｉｏｎ　ｏｅ　 ｔｈｅ　Ｉｎｔｅｒｆａｃｅ＞（ｃｏｍｍｏｎ　ｐｒｅｄｉｃａｔｅ　ｘ＞（ａ ｃｔｉｖａｔｅ　ｐｒｅｄｉｃＩＩｔｅ　Ｎ）＜ｃｏｎ【１ｎｕｅ　ｉｎ　ｕｓ ｅｒ　１　ｏｐｅｒａｔｉｏｎ＞＜ｕｓｅｒ　Ｉ　ｐｒｅｄｌｃａｔｅ　Ｎ＞主 語により用いられる該述語は、手続きとして参照されたプログラムルーチンを規 定することによる新たな手続きの編成により、或いは、基本指令のいずれかによ り本発明のシステムて規定される。それぞれの手続きは、特定の１つの主語のた めの単一に特定されるか、或いは、それは一般化され多くの異なる主語によって 用いられる。

それぞれの手続きはその動作によって特徴付けられる。

宣言言語の述語として階層化されたアーチテクチャ−での手続きの利用か、抽象 化レベルを高めトップレベル言語のパワーを増大させるため事実上無制限の可能 性を導き出す。このタイプのシステムを設計する上で用いられなければならない １つの基本的な規則は、システムを簡単に理解でき維持てきるように手続きの数 を十分に小さく保たなくてはならないことにある。述語は、例えば数の解析のよ うな、区分された手続きであると見られる。

述語は複雑な仕事を実行できるが、これは常に非常に明瞭でなければならない。

最も低いレベルで、述語は単一の宣言言語記述（ｓｔａｔｅｍｅｎｔ）以外ては ないものからも成る。発明の言語構造面て用いられる述語は、宣言言語の述語と して表され、また、本発明の“ソフトウェアアーチテクチャ−及び技術”面の関 連する欄に以下記述されているように、アプリケーション動作システム（ａｐｐ ｌｉｃａｔｉｏｎ　ｏｐｅｒａｔｉｎｇ　ｓｙｓｔｅｍ　ＡＯＳ）内のプログラ ム手続きとして規定されることを理解すべきである。

本方法は、プログラムの全部又は一部の継承を提供する公知の０〜手法と対比す ることかできる。しかしながら、このケースにおいて、実目的語及び述語の両方 か目的語と呼はれ、動作成いは述語は常に該実目的語に緊密（こりンクされてい る。これは、Ｃ１＋てはカプセル化のために行われている。しかしながら、カプ セル化の重要性は、目的語向き言語を用いるときと、宣言言語を用いるときとて は近似したものではない。Ｃ〜での動作の目的語への弱い連結は、機能的構成を 容易に理解するための構造に対して大きな逆効果となる。他方、本方法は、明瞭 な機能的構成の創造を支持する述語或いは動作のみを継承することを可能にする 。これにより、このような機能的構成は容易に理解され、また、これは、プロセ ス制御ソフトウニアシステムの構造上の大きな重要性を常に有する。

本システムでの目的語は、緊密に関連する動作で束ねられた記号形状での実世界 構成要素及び／又はデータを含むプロセスとして規定される。これか、目的語プ ロセスに、目的語へ密接に結び付けられ、そして、述語の論理構造への不可欠な 重要性のない何らかの動作を含ませることかできる。このようなルーチンは、例 えば、外部の目的語の状態のスキャニングするルーチン、ある目的語のために常 に行われる計算ルーチン、及び、画面に何らかを表示するルーチンを含む。この ように、Ｃ−のような目的語向き方法の主要な利点は、本システムにおいて利用 されている。しかしながら、主語と目的語とかお互いに混ぜ合わされないことは 、これらは共にプロセスにおいて実行されるため非常に重要である。該プロセス は、配置計画の技術であり、また、主語、目的語及び述語は、アプリケーション アーチテクチャ−内での全てのプロセス構成要素である。もしもルーチンがデー タ目的語に強固に結び付けられていないら、述語プロセスにおいて分離されるで あろう。他の目的を含み承継のために適用された方法は、この技術で良く知られ ているように必要とされ導入されることかある。幾つかのトークンで、もし述語 か大きく又は複雑であるなら、目的語の代わりとして構成されるへきてあろう。

発明の言語構成面での実世界構成要素及びデータによって表されるアスペクトか 、発明の“ソフトウェアアーチテクチャ−及び技術”面の欄に関連して以下に記 述されているように、アクセス部分として翻訳できることを理解ずへきである。

この関連で、ユーザ部分か述語或いは手続きを執行し、これは、特定の作業を遂 行するアクセス部分への命令である。この命令は、とのように実際の実世界構成 要素か設計されているかに依存することはない。即ち、この命令は、例えば到来 する発呼、１２３４５等の発呼パーティの電話番号、或いは、オペレータ等の到 来パーティの区分等の実際の状況についてアクセスに知らせることかできる。も しアクセスかアナログの内線であるなら、おそらく、アクセスアスペクト内での 呼び鈴信号を発生することのみか可能であろう。しかしなから、アクセスアスペ クトか表示装置を有する特徴的な電話であるなら、＋２３４５の番号かオペレー タ区分の指示か可能になるよう表示器に表示されることかある。

本発明のソフトウェア構造方法論は、配置計画の明細から離し、そして、アプリ ケーション自身についての集中と知識の増大のために、ソフトウェア設計者即ち プログラマ−の働きを強力に支持する。例えアプリケーションか非常に複雑なプ ロセスとロジックを含んでいても、明瞭で容易に理解できるアプリケーション向 きソフトウェアアーチテクチャ−の創造を可能にする。本発明の技術は、本発明 の別の面の記述と共に以下の更に例示されるように、機能の付加によりソフＩ・ ウェアの維持を容易にし、これを高揚させる。

のための改良されたプロトタイプ作成技術本発明のシステムは、ソフトウェアア ーチテクチャ−技術、即ち、通信スイ・ソチングシステムの状態の評（ｉ及び開 発に用いることかでき、特に、このような゛ソフトウェアの拡大、或いは新たな アプリケーションの開発のｔこめの有用なプロｌ−タイピングｌベースの製造（ こ用し）ることかできる。本システムて用いられる該プロゲラミンク゛規！！（ ｐａｒａｄｉｇｍ）は、上述したように、宣言ブログ゛ラミングのもので、適用 される動作システムは、通信への適用を支援するために特に適用される。例え（ よ、ブ１ノーコール失敗回復を含むように拡大されている。

通信スイッチングソフトウェアの開発は、ｔ！ん１＝ん市場によって操作される ようになってきてる。全１本の開発チェーンにわたっての需要（ｓａｆｅ）の特 徴の取扱を簡１３（ヒするため、回数か多くなるにつれて、アプリケーションの 専門家かソフトウェアアーチテクチャ−設ｉ１＋二組み込まれるようになってき ている。即ち、生産イ士様の特徴（よ、ソフトウェアアーチテクチャ−内の実際 の特徴モジュールにマツプされる。事実、これか市場（こより操（乍さオするア プローチをソフトウェア開発へと導く。

通信スイッチンダシステムアーチテクチャー及びスイノチンクシステムノフトウ エアのプロ１〜タイプ（’ＩＥ　Ｉ戊（よ、早い段階において、実用試験の結果 による立証の必・要性と非常に複雑な問題の解決とを含む。プロトタイプ（乍或 はそれぞれかそれ自身規定された目的語を有する勺−イクルに分割され、そこで 、１つのサイクルが限定された数の完全に実行される特徴を含み、そして、それ ぞれ連続するサイクルか新たな特徴を導入する。そのようなプロトタイプは、そ の機能により制限されても現実的なシステムを表す。プロトタイプは、リアルタ イム特性と実際の生産品に匹敵するソフトウェア品質とを存することかできる。

これらは、動作上のソフトウェアの設置計画と同様に、更なるプロｌ−タイプを 構築するための安定したヘースを作成する。

プロトタイプ作成プロセスは、全体的なワークモデルの用意の非常に重要な段階 で、設計者がユーザに最初に集中させることを可能にする。第１図を参照し、こ こにはプロセスを説明するブロック図か示されており、そこで、提案されている システムの使用可能性２１はユーザの研究と彼らの要求２２とから評価され、こ れはプロトタイプの初期ワーク前提を提供するユーザインターフェイス模擬実験 ／試験２３に続く。次に、プロトタイプ作成プロセス２４自身か実行される。こ のプロセスは、生産品開発２８のための全体に渡り見向された要求仕様を達成し 、同様に標準化機構２７への適正な入力を発生するために、新たなアプリケーシ ョン２６のプロ［・タイプ作成用の新たなラフ１−ウェア技術２５か利用される 。達成される更なる利点は、相対的に少ない努力で、これらプロトタイプから最 終の、動作し得る生産品か開発できることにある。

実際上、新たなアプリケーション或いは特徴のプロトタイプは、設計され、実行 され、そして、共同のユーザ位置で試験される。該プロトタイプを構成するため の実際のワークモデルが第２図に示されている。最終のモデルが、特徴モジュー ルのそれぞれの特徴を取り入れるこによって特徴付けられる。第２図は、仕様及 び設計の段階において作り出さなければならない対応のドキュメントを表してお り、ここて機能的仕様３２と試験仕様３３との両方を含む特徴仕様３１を有する 。特徴仕様３１から特徴設計及び証明期間３４に入れられ、それは構造仕様３５ の一部と、複数の宣言言語モジュール３６と、証明記録３８を発生するために用 いる証明モジュール３７とを有する。最後に、システム試験期間３９に引き継が れて完了する。

次に、第３図を参照し、ここには、本システムに基づくプロトタイプソフトウェ アの開発の複合段階の全体的な図を表すフローチャートが示されている。前に指 摘したように、プロトタイプ制作の開始時の作業は仕様を用意することである。

４１には、Ｃ，Ｃ，１，Ｔ、　Ｔ、の基準手続きによって予め記述されている３ 一段階の方法論の第１段階か採用される。更に詳細には、これらの技術は、Ｃ， Ｃ。

１、Ｔ、Ｔ、仕様１．１３０　Ｃ通信サーヒスを特徴付ける方法）：Ｑ　６５（ 段階２の詳細な記述）：及び、１．３１０（ＩＳＤＮネットワーク機能原理）に 示されており、これらはそれぞれ本願の参照に取り入れられる。この最初の段階 か、ユーザの視点からのアプリケーションの全体的な記述或いは仕様を用意する ために提供する。次に、４２において、それぞれのユーザのための上記の宣言言 語構成に統合される種々の目的語の大まかなレイアウトか用意される。これは、 現実の目的語を形成するユーザシーケンスの開始と終了の両方の識別を含む。こ の後、４３において、システムは別の仕様ステップ、即ち、前に指摘したＣ、　 Ｃ，１，Ｔ、　Ｔ、手続きに置かれている３一段階方法論の、機能的構成要素の 識別を含む段階２を採用する。

次に、４４で、機能的構成要素がマツプにされ、単−及び共通の述語は、上述し た宣言言語アプローチに基づき識別される。このステップにおいて、ユーザシー ケンスか主語により表され、種々の機能は自然で理解し易い方法で構成され及び ／又はグループにされる。最後に、４５て、それぞれの実世界構成要素が目的語 により表される。例えば、アクセスソーケンスは使用する目的語により表される 。しかし、これらは、主語として最初に構成することもてきる。

本発明のプロトタイプ作成技術の更なる例として、第４図か機能的仕様のサービ ス面の第１段階仕様を示す。

これは、ユーザの視点から用意された全体的な記述内の手続きである。第４図に 示すように、サービスが特定状態５Ｉて既に存在しており、ユーザ要求５２に応 答して、それは機能的動作５３を要求する。その機能的動作５３の結果が、５４ てユーザ応答と特定状態５５の選択とをトリガする出力を発生する。しかしなか ら、５３ての機能的動作は、また、機能的コンポーネント５８の結果となるネノ Ｉ〜ワーク／ユーサ応答５７をめるネ’ｙ　＋−ワーク／ユーザ要求５６の形を 取ることかある。コンポーネント５８の出力は、システムを最初の状態６１へ送 るユーザ応答６０と共に機能的動作５９を発生することができる。

同様に、機能的仕様明細を発生ずる段階２手続きか、機能的構成要素の識別、及 びシステム内の情報の流れのような機能的ネットワーク面を扱う。第５図から分 かるように、複数の機能的構成要素（ＦＥ、−ＦＥ、’）６２−６５か、ネ７１ −ワークの機能的コンポーネント６６面と接続される。それぞれのこれら機能的 コンポーネントは、機能的ネットワークへ構成要素をリンクするシステムの種々 のコンポーネント内の完全な情報の流れか存在するように、他の機能的コンポー ネントとメツセージを交換することかできる。例えば、機能的構成要素６２から の６６ａで送られたメツセージ要求か、機能的構成要素６３の６７で受信される 。応答で、それは機能的構成要素６４てメツセージ要求を６８から６９へ向かわ せ、それか次にメソセージを７１から機能的構成要素６５の受容器７２へ向かわ せる。その後、機能的構成要素６５て発生された応答か、７３−７４からと、７ ５−７６からと、７７−７８からのメツセージ応答によって機能的構成要素６４ 及び６３を介し、７９てオリジナル要求への応答を提供する機能的構成要素６２ へ送られる。

次に第６図を参照し、これは、機能的構成要素がローカルの場合、例えば、ネッ トワーク化されていない通信かプログラム構造上にマツプされる手法の解説的な 図を示している。これは、仕様構造からなる機能的構成要素ＦＥ、−ＦＥ、が如 何にして本発明に基づくプログラム構造８２上にマツプされるかを示している。

理解されるように、２つの電話機８３ａ、８３ｂかアクセス８４ａ及びアクセス ８３ｂによってソフトウェア構造へそれぞれ相互接続されている。それぞれのア クセスがソフトウェア構造での目的語として動作する。同様に、アクセス８４ａ 、８４ｂは、ユーザＡ構成要素８５ａ及びユーザＢ構成要素８５ｂによって交互 接続され、これは本発明のプログラム構造内で目的語を形成し、これは、第６図 から分かるようにアクセス／目的語独立である。

次に第７図を参照し、これは、機能的構成要素がネットワーク通信の場合にマツ プされる方法を表す同様な解説的な図を示している。これは、仕様構造８１の機 能的構成要素ＦＥ、−ＦＥ４がプログラム構造８２上でマツプされる手法か表さ れている。再び、２つの電話機８３ａ、８３ｂがアクセスＡ３４ａ及びアクセス Ｂ８４ｂへそれぞれ接続されている。同様に、ユーザＡ構成要素８５ａ及びユー ザＢ構成要素８５ｂが、アクセス／目的語独立であるプログラム構造内で分離し た目的ａｈを再び形成する。加えて、一般的なネットワーク目的語８７と共にネ ットワーク従属目的語８６が存在する。これらのそれぞれが、ネットワークユー ザＡ３６ａ、８７ａとネットワークユーザＢ、８６ｂ、８７ｂとを含む。加えて 、ネットワークプロトコル８８が、ネットワークアクセスＡ構成要素８９とネッ トワークアクセスＢ構成要素９０とを相互接続する。

本発明のプロトタイプ作成システムでは、プロセスコンセットが、互いに併存す るプロセスでアプリケーションの実行時間構造発呼モデルをモデル化するのに用 いられる。プロセスは、外部の刺激／信号により活性化され、実コードの履行後 、プロセスは一定の規定された状態に留まる。そのようなモデルは、併存する発 呼が多く存在し、そして、それぞれの発呼か幾つかの動作のシーケンスをトリガ するアプリケーションの特性にとても良くマツチする。

一般的に、該システムは、仕様の機能的モデルか分割されるのと同様な方法て、 発呼モデルを分割する。次に、第１２図を参照し、機能的特徴モジュール９０は 、それぞれアクセス１６０用と、ユーザ１６１用との異なる構成要素を有し、更 にこれらモジュールに加えて、ライン／端子装置＋６２か更に別にモデル化され ている。したかって、第１２図に示されそいるように、発呼のそれぞれの側のた めに、分離プロセスか、（ａ）それぞれの１１−トウエア装置（ドライバプロセ ス１６３）、（ｂ）ラインのそれぞれのタイプ（アクセスプロセス１６４）、（ Ｃ）発呼のそれぞれのパーティ（ユーザプロセス１６５）用に割り当てられる。

ネットワーク化の特徴、同様に独立して操作可能のＰＢＸの特徴は、これらは既 に仕様ワーク期間中に機能的モデル内に置かれているため良く一致し、分離発呼 側は異なる構成要素により表される。従って、分割ビュー（ｖｉｅｖ）か、それ ぞれプロセスの自己のセットを存する２つの発呼側による発呼制御のため選択さ れる。分割発呼制御は、状態の全体の数を顕著に減少させるという付加的な利点 をも有する。多くの場合に、分割発呼制御は、決定を行う前に、発呼側と発呼側 との間での交渉／通信を要求する。従って、発呼側と発呼側との間での通信は、 処理装置間を通過するときに、メツセージを機密にする高レベルプロトコルによ り支持される。

以下に詳細に記述するように、該システムソフ１へウェアアーチテクチャ−は、 幾つかの層に分割される。これは、次のような事項について明瞭な利点を提供す る。

（１）アプリケーションが選択された動作システムから独立する： （２）アプリケーションか、選択されたＣＰＵハードウェア、同様に通信ハード ウェアから独立する。

（３）処理装置の分配がアプリケーションから隠される。

システムアーチテクチャ−の階層化された構造か第８図に示されており、そこで は、アプリケーション層９１、アプリケーション動作システム層９２及び基本動 作システム層９３がソフトウェアシステムを構成する。アプリケーションソフト ウェア構造を動作上の実行時間環境に可能な限り近似させてモデル化するため、 該アプリケーション層コードの境界が定められる。該アプリケーション層９１は 、仕様ワーク期間において以前に規定された需要（５ａｆｅ）目的語／特徴を映 しだす幾つかの独立した作業モジュール８９を有する。これら作業モジュール８ ９は、更に、ユーザモジュール９４、アクセスモジュール９５、トライバモジュ ール９６に再分割される。それぞれのユーザモジュール９４は、例えば特徴のト ラフィック制御部のような特徴のアクセス独立アスペクトを扱う。それぞれのア クセスモジュール９５は、独立の発呼期間の開始／終了及びタミナル特性を扱う 。それぞれのドライバモジュール９６は、ハードウェアへの論理信号をピノトス トリウムにする符号化と、ハードウェアからの論理信号及びヒットスｌ−リュー ムの復号化とを扱う。

これら作業モジュール８９は、（ａ）信号化プロトコルを含む電話作業、（ｂ） 管理作業；或いは（Ｃ）特徴間の相互作用、のいずれかのための特徴或いは機能 の完全なセントを記述する。本システムの１つの命令の特徴は基本発呼ソーケン スである。

システムのアプリケーション層９１は、アプリケーションライブラリ９７を含む 。コンポーネントの該アプリケーションライブラリ９７は、設計者及び開発者の ための強力なツールを提供し、それはアプリケーション設計のレベルを高める。

それは、特徴を設計する際にたびたび用いられる機能を含む。これら機能のそれ ぞれか、それぞれの新たなアプリケーションのために仕様期間で識別され、機能 性を動作させるのに必要とされる明細を実際にプログラムすることを必要とせず にシステムへ加えられる。

第８図を参照し続け、アプリケーションライブラリ９７は、例えば、特徴を設計 する際にしばしば用いられる幾つかの機能を統合する。機能は、仕様期間に識別 され、そして、単にワーク期間内に再使用される。アプリケーションライブラリ ９７の該機能は、アプリケーション動作システム機能に関する拘束とは対称に、 幾つかの発呼側ての機能性を含むことかできる。以下は、アプリケーションライ ブラリ９７内に含むことかできる機能のリストである。

（ａ）回答発呼 （ｂ）チェック発呼 （ｃ）接続発呼 （ｄ）接続解除発呼 （ｅ）分配発呼 （ｆ）参加発呼 （ｇ）合併発呼 （ｈ）キュー発呼 （１）再リンク （ｊ）再ルート発呼 （ｋ）再開発呼 （１）戻り発呼 （ｍ）パーティ捕獲 （ｎ）設定発呼 （ｏ）分割発呼 （ｐ）懸垂発呼 加えて、アブリケーンヨンライブラリ９７の機能は、管理タイプ特徴により規定 される。

また第８図に示されているように、システムアーチテクチャ−の該アプリケーシ ョン動作システム（ＡＯ３）Ｍ９２は、アプリケーション層９１への支持機能を 提供し、幾つかの異なる特徴において重複コードの開発者による使用の回避を助 ける。これはまた、アプリケーション設計者からの再び実行明細を隠すことによ って、抽象化の可能な限り高いレベルでアブリケーンヨンプログラミングを起こ すことを許容することにおいて援助する。

該ＡＯＳ層９２は、ツールキット９８と一般機能９９のセットとの２つの主要機 能グループを有する。該ツールキット９８は、アプリケーション層９１に一般目 的機能を提供し、これは、例えば次のような機能、（ａ）内部パーティ通信、（ ｂ）スイッチング、（Ｃ）キューイング、（ｄ）タイミング、（ｅ）発呼履歴、 （ｆ）ナンバー解析、及び、（ｇ）配置管理を有する。ＡＯ３層９２の該一般機 能９９は、特徴モジュール９０に内蔵されるユーザ９４とアクセス９５のモジュ ールを実行するのに必要な機構を提供する。

通常、通信システムの動作システムは、ロードコード及び遂行Ｉ１０動作等のシ ステムの一部の間でメツセージを送る能力よりも僅かに大きな機能性を備える実 行時間執行部である。これは、ときとして、通信システムにおいて、特定の特徴 或いはアプリケーションの機能性のコード化よりも、分配、再開、或いは他の動 作的／手続的な機構を管理するのが更に難しいことを意味する。第８図に示され ているように、本発明の動作システムのアプローチは、基準の時分割システムの 利用可能なものに更に近似した基本動作システム９３を代わりに提供する。

しかしこれは特に通信用の付加的な機能とプリミティブ（ｐｒ　ｉｍｉ　ｔ　１ ｖｅ）とを含んでいる。このような機能の幾つかの例は、下記を含む。

（ａ）トライバ１０２の一般機能 （ｂ）初期化機能１０３ （ｃ）データベース保持及び検索機能１０４（ｄ）装置割り当て１０５及び割り 当て解除機能（ｅ）エラー回復機能１０６ （ｆ）スイッチグループアブストラクションに基づくスイッチ扱い （ｇ）分配されたアーチテクチャ−と実際の構成の現実性の隠蔽 プロセス、プロセスのスケジューリング、ハードウェアへのＩ１０接続等の間を 通過するメツセージのための基準のプリミティブは、制御プログラムパネルと共 に勿論存在する。本発明の基本動作システム（ｂａｓｉｃｏｐｅｒａｔｉｎｇ　 ｓｙｓｔｅｍ″ＢＯ３”）９３は、プログラミングのレベルを向上させるだけて なく、システム故障−耐性を作り出すのにも寄与する。該ＢＯ３９３は、アプリ ケーションプロセスへ割り当てられるリソースについて、及び、ランザクジョン と一緒にリンクされるプロセスについての情報を維持する。従って、プログラミ ングエラ、或いは共同ノードの故障のいずれかによる故障が発生したとき、該Ｂ Ｏ３９３は接続されたプロセスを終了し、リソースを回復し得る。これの１つの 効果は、それか予備−発呼エラー回復を可能にすることである。別の利点は、新 たなアプリケーションソフトウェアの開発のための非常に強固な試験環境を提供 することである。従って、更に本システムで、ハードウェア及びソフトウェアの 故障かそれの発生した］・ランサクションにのみ影響し、そして、通常の手法で 効率的にシステムが再編成及び再命令できる。

上述したように、本発明に基づくリアルタイム動作システムとプロトタイプとの 両方のプログラミングは、例えは、以前に論述した活性主語の規範に基づき構成 された言＃１ＥＲＬＡＮＧのような宣言言語を採用する。この目的のためのＥＲ ＬＡＮＧの選択の際に、言語Ｌ■ＳＰ、ＰＲＯＬＯＧ及びＰＡＲＬＯＧについて も調査された。

該調査が、特に通信スイッチングシステムに対して、他の特性とリアルタイム動 作の並列的な処理を扱うための付加的な構成の必要性を指摘した。例えば、ＰＡ ＲＬＯＧ、ＰＡＲＬＯＧと他との協動のような、並列処理を扱うことかできる論 理言語の特定のクラスでさえ、非同期電話処理（プロセス）を該言語の単一の処 理（プロセス）によって表すことができる協動の粒状度（ｇｒａｎｕｌａｒｉｔ ｙ）を含むものではない。ＥＲＬＡＮＧは、ＰＲＯＬＯＧと協動ではないＰＡＲ ＬＯＧとの両方の所望の特徴と、言語自身に構築されるエラー回復構造とを処理 する。ＥＲＬＡＮＧの上記取り入れられた参照の図から明らかなように、ＥＲＬ ＡＮＧは、高−レベル記号の特性と、パタン一致構文と、単純な制御構造と、高 −レベルデータ構造と、エラー検出及び訂正の支持と、ライトウェイトプロセス と、メツセージ通過とを有する。

本発明のプロトタイプ作成システムの設置計画において、プロトタイプ作成環境 は、ＵＮＩＸ動作システム下で動作する基準的なワークステーションから成る。

ワークステーションの開発環境はユーザインターフェイスを存し、これは、Ｘ− ウィンドウと、メニュー−準拠アクセスでのアーカイブと、バーシュン管理と、 ＵＮＩＸ上で動作するテキストエディツタと、フレームマーカーを通るドキュメ ント準備と、電子メールを介しての通信とから成る。加えて、プロトタイプ作成 支持システムは、仕様期間の将来設計のための同様のツールと証明期間とを存す る。これらのワーク期間では共通なツールは、ブロウザ−（ｂｒｏｗｓｅｒｓ） と、選択されたビュー　（ｖｉｅｗ）と、ハイパーテキスト（ｈｙｐｅｒｔｅｘ ｔ）エディツタと、ドキュメント内でと、同じワーク期間のドキュメント間での トレース能力と、仕様と最終コード間でのトレース能力とを有する。

仕様ワーク期間のため、該支持システムはグラフィックツールと、静止及び動的 なモデル化のためのツールとテンプレートとを提供する。設計及び証明ワーク期 間のための最も重要なツールは、次の能力を支持するＥＲＬＡＮＧシステムであ る。

（ａ）特徴モジュールの実行及びハードウェアノードの模擬試験 （ｂ）個々の機能のトレースステップ （Ｃ）特定のプロセスへの全通信上の探査（ｄ）プロセス構造の試験、即ち、と のプロセスを支持し、プロセスをエラー回復目的のためにどの様にリンクさせる か等の決定 （ｅ）プロセスグローバル変数の試験 （ｆ）フライ（ｆｌｙ）上でのコートの再コンパイルと、それの動作上の実行時 間システムへの導入該支持システムは更に、相互作用グラフィックと、データヘ ースと、他のツールとを提供する。

種々の特徴か、プロトタイプ作成技術の環境の試験対象として選択できる。ぞの ような特徴は、エリクノンＭＤＩＩＯのような現代のＰＢＸのための機能的仕様 に基づき設計され、それは、次の特徴を有する。基本発呼、基本ネットワーク発 呼、基本コードレス発呼、発呼ライン識別、３〜パーテイサービス、発呼送り、 オペレータ延長、通話中／返答なしの発呼終了、オペレータ再発呼、侵入。

上述したように、仕様の機能的構成の近接したマツピングと共に、ソフトウェア アーチテクチャ−の階層化を行うアプローチは、−個人が全体の特徴設計と設置 計画とを遂行することを可能にする。この個人は、機能的仕様ワーク期間に責任 を持つことかでき、これにより、ソフトウェア設計者を彼らの顧客及びその要求 に集中できるアプリケーション設計者にすることを可能にする。これは、アーチ テクチャ−の低い層を、この作業に更に適応しているシステム設計者に扱わせる ことをも可能にする。

機能的構成へのソフトウェアアーチテクチャ−の該クロスマツピングは、ワーク モデルを非常に簡単にする。

結果として、本システムにより作り出されるドキュメントの数が非常に少なくな る。更に、プロトタイプの幾つかのドキュメントを自動的に発生することもでき る。また更に、本システムと対比した設計効率の計測は、少なくとも１０倍まで 効率を増大できることを示している。

プロトタイプソフトウェアの特定の特徴の証明及び設計に含まれる人の数の減少 が、１個人にまで減じさせ、それは、長い待ち時間を消滅させり一トタイムを短 縮させることを含む多くの利点を提供する。更なる利点は、より正確なソフトウ ェアプランの作成である。

作業の設計は、即ち、本システムの特徴或いは管理モジュールは比較的簡単で、 また幾つかの異なる機能により知的な刺激性がある。例えば、機能的仕様の口頭 テキストが特徴モノニールのコードに応答し、それにより、コード及び特徴の理 解を改善する。加えて、プログラムのサイズか小さくなり、見渡し得る仕様言語 品質は、マツチング、リストハンドリング及び機能関数の特徴を示す。更に、設 計は、増加的で相互作用的であり、プロセスか構成の成長を許容する。プログラ ムはフライで再コンパイルされ得るため、また、特徴或いは特徴の部分の証明か 、単に試験ファイルの活性化により自動的に繰り返されるため、パッチング（ｐ ａｔｃｈｉｎｇ）が本システムでは不要になる。最後に、データか高い記号レベ ルで表示でき、設計時における容量の問題を考慮する必要がなくなり、用意する ドキュメントをとても少なくてきる。

本発明のプロトタイプ作成技術の上記記述から分かるように、アーチテクチャ− のワークは、ユーザアブリケーノヨンについての真の知識に基づく。これは、階 層化された構造内でのよく規定され制限された数の構成要素の作成を可能にする 。該システムは、構成要素の境界を定め、また、如何に目的をドキュメントにし 引き継ぐかについての付加的な方法の開発を要求するよりも、その機能的内容を 厳格に規定する。比較的理解し易く扱い易いアーチテクチャ−と、上述したリア ルタイム宣言言語との結合か、通信スイッチングシステムの新たなサービス及び 特徴の実行のために必要とされるワークの量を非常に減少させる。また更に、大 規模に市場に導入する前に、進歩したプロトタイプを実行することにより、新た なサービスと特徴の実寿命試験を行うことを可能にする。

本発明の技術が、設置計画の問題からワークの量を除くことを可能にし、また、 新しくまた更に進歩ししたサービスの開発、及び、顧客の要求に集中することを 許容する。

ソフトウェアアーチテクチャ−及び技術第８図に関連して記述したように、本発 明のソフトウェアシステムアーチテクチャ−は階層化され、また、アプリケーシ ョン層９１と、アプリケーション動作システム層９２と、基本動作層９３とを有 する。加えて、設置計画層１０１は、階層化されたソフトウェアアーチテクチャ −を引き受ける。該アプリケーション層９１は、幾つかの作業モジュール８９を 存するアプリケーションライブラリ９７を含む。それぞれの作業モジュール８９ は、ユーザモジュール９４とアクセスモジュール９５とドライバモジュール９６ とを有する。該アプリケーション動作システム層９２は、ツールキット９８と一 般機能９９とを有する。該基本動作システム層９３は、ドライバ１０２用の一般 機能と、システム開始設定と、再開機能的１０３と、データベース保持及び検索 機能的１０４と、装置割り当て／割り当て解除のための一般機能１０５と、エラ ー回復機能＋０６とを有する。ブロック１０１での設置計画は、Ｅｒｌａｎｇの ような宣言プログラミング言語システム１０７と、ハードウェア動作システム（ ｏｐｅｒａｔｉｎｇ　ｓｙｓｔｅｍ　”Ｏ３”）１０８と、中央処理装置（ＣＰ Ｕ）１０９と、通信スイッチングハードウェアｌｌＯとを含む。

次に、第９図を参照し、本発明の階層化されたソフトウェアアーチテクチャ−の 別の図か示されており、そこで、アプリケーションが最高の層、即ち、アプリケ ーション仕様に最も近いものからなる。他の層は、ソフトウェアを実行する物理 的機構により近い設置計画の深い層を表している。示されているように、該アプ リケーションはアプリケーション＠９１からなり、これは、アプリケーションラ イブラリ９７とアプリケーション動作システム層９２とから成る。該アプリケー ション層９１は、アプリケーションが最初に特定された方法に対応するビューを 与える。該アプリケーション層９１は、該アプリケーション動作システム層９２ により、基本動作システムと該システムアーチテクチャ−とから隔離される。該 アプリケーション動作システム層９２は、幾つかの異なる作業或いは特徴でコー ドを再生する事を避けるために、アプリケーション層９１へ支持機能を提供し、 アブリケーノヨンプログラミングの抽象レベルを可能な限り高め、アプリケーシ ョン設計者を設置計画明細から分離する。

内部的に、該アプリケーション層９１は、複数の独立した作業モジュール８９に 再分割され、これは特徴モジュール９０と管理モジュールＩｌｌとの結合として 機能的に見ることかできる。特徴モジュール９０と管理モジュールＩｌｌとの２ つのタイプのそれぞれは、相互に大変似ており、ユーザ（発呼扱い）モジュール １１２ａ−ｂと、アクセス（ライン扱い）モジュール１１３ａ−ｂ。

ドライバモジュール１１４ａ−ｂに完全に再分割される。

該特徴モジュール９０と管理モジュール１１１とは共に、システム内の作業或い は特徴の完全なセットを記述する。

作業は、例えば、電話或いは管理作業自身、即ち、シグナリングプロトコル等の 他の特徴と如何に相互作用させるかから成る。該“基本発呼”は、システム内に 常に含まなければならない命令の特徴と考えられる。作業モジュール８９は、特 定の作業のために特徴モジュール９０のみを含むことかあり、或いは、他の作業 のために管理モジュールＩｌｌのみを含むこともある。しかしながら、他の場合 において、作業モジュール８９は特徴モジュール９０と管理モジュールＩＩＩと の両方を含む。

特徴モジュール９０のユーザモジュール１１２ａは、例えば、いずれかの特徴と 同様に基本発呼を制御する。

それは、ラインプロトコル独立方法て発呼の監視と設定とを制御する。例として 、ユーザモジュールｌ１２ａは以下を含む。

（ａ）単一データフィールドの創造、或いは、そのようなフィールドへの不履行 データの割り当てのような作業を遂行するために、特徴により必要とされる初期 データを規定する初期部分： （ｂ）ユーザ手続き構文及び意味を規定し、不履行値を割り当てるユーザ手続き 部分。

（Ｃ）特徴かとの様に働くかを規定するトラフイ・ツク部分。

管理モノニールＩｌｌは、同様に、ユーザモジュール１１２ｂとアクセスモジュ ール１１３ｂとドライノくモジュール１１４ｂとから構成されている。

他方の発呼側から離れた状態のそのセ・ノドを存するそれぞれのパーティのため に１つの発呼側（ビュー［ｖｉｅｗ］　）か存在するように、特徴のトラフィッ ク部分は分割される。これは、将来割り当てられることかある全部の数を一般的 に減少させる。それぞれのユーザモジュール１１２ａの該ｌ・ラフイック部分は 、最上レベルから階層的に構築されている。第１Ｏ図に示されているように、車 室−及びサブ状態−機能＋７０から成る状態／事象駆動輪埋に達するように、全 ての外部及び内部の刺激はこの最−Ｌレベルに入る。それは最高レベルからて、 そこては、適切なフェイズ１７１か、発呼のノく−テイの付加／移動と同様に、 サブ状態或いは次状態の初期であるフェイズの結果て発呼される。この構成か、 この最高レベルを読みだすことにより、全ての特徴の良好な大要を設計者に提供 する。

該事象−及びサブ状態−機能は、システム内で他のユーザモジュールを一覧でき るユーザモジュールの一部分である。これらは、制御を引き継ぎその後戻す事象 −及びサブ状態−機能を規定することにより、第１発呼扱いモジュールと相互に 作用する可能性を有する。例えば、記録を行う特徴は、常に、該特徴か実行を完 了した後に制御を戻す。状態／事象扱いのための一般支持機能は、アプリケーシ ョン動作システム９２により提供される。

フェイズ１７１は、大きな程度まで、アプリケーション動作システム９２へ、或 いは、アプリケーションライブラリ９７、或いは、そのローカルライブラリ１７ ２へかのいずれかにアドレスされた機能発呼の結合である。

フェイズ１７１の終了後、結果１７３は最上レベルへ戻る。典型的なフェイズの 仕事は、（ａ）アドレス情報の解析、（ｂ）典拠（ａｕ　ｔｈｏｒ　ｉ　ｔ　１ ｅｓ）のチェック、（Ｃ）他のパーティへの質問、（ｄ）他のパーティによる質 問へ回答、（ｅ）スイッチ動作：　（ｆ）ラインを引き継ぐための命令を含む。

アプリケーション層のトラフィック部分内で用いられる階層的な構成が第１Ｏ図 に示されている。トラフィック機能を実行するために、如何にして種種の機能が 種々のライブラリ及び動作システムから発呼されるかが示されている。

本発明のシステムのコンポーネントの構成が、第１１図で別の形で再び表される 。ここに、特徴のライン従属部分を制御するアクセスモジュール１１３ａ、ｂが 示すれている。ライン従属部分を有するこれらの特徴用と、ラインターミナルの それぞれのタイプのための単一アクセスモジュールとが存在する。ラインターミ ナルの例は、基本及び補足サービスのためのアナログ／ディジタル／ｌ５ＤＮＩ −ランクと、アナログ／ディジタル／ｌ５ＤＮ電話ターミナルとを備える。それ ぞれのアクセスモジュール１１３は、ハードウェアのぞれぞれの特定のタイプの ためにプロトコルの意味部分を扱う。該アクセスモジュールは、ユーザモジュー ル１１２の方に向けられた装置独立プロトコルをまた表す。該プロトコルは、純 粋に機能的で、ラインターミナルのタイプから独立である。

それぞれのアクセスモジュールｌｌ３ａ、ｂは次を含む。

（ａ）現実ラインのために不履行データをセットし、ハードウェアを活性化し、 ターミナルを適正な状態にリセットする初期部分。

（ｂ）ｌ−ラフイック事象の扱いと発送（ｄｉｓｐａｔｃｈｉｎｇ）とを提供す るトラフィック部分。

アクセスモジュール１１３の構成は、ユーザモジュール１１２のものど１蓋かに 異なる。アクセスモジュール１１３の該最上レベルは２つの近似した部分、即ち 、発送部分と事象扱い部分とに分割される。発送部分の目的は、ライン或いは他 のパーティから事象の内部セットへ到来するプロセシング／翻訳信号により、事 象扱い部分に供給する前に、到来する事象を純化することにある。この予備−プ ロセシングは、受信されるメツセージ、メツセージデータ及びターミナル状部に 関して行われる。該事象扱い部分は、ユーザモジュールの最上レベルに近似して いる。アクセスモジュール１１３の典型的なフェイズの仕事は次を含む。

（ａ）幾つかの発呼アクセス可能性の扱い（ｂ’）ユーザへの発呼進展メツセー ジの指摘（Ｃ）ラインターミナルプロトコルの意味部分の扱い（ｄ）ナンバー、 手続き、接尾辞（ｓｕｆｆｉｘ）解析の遂行（ｅ）発呼扱いの訂正及び協動化。

トライバモジュール１１４ａＳｂは、ハードウェアへのインターフェイスと見做 すことができる。これらは、ラインプロトコルのハードウェア部分、即ち、特徴 の意味部分を扱う。該トライバモジュール１１４は、ハードウェアライン信号／ ビットストリームを復号化し、シンボル信号のそれらを適切なアクセスモジュー ル１１３に配送する。該ドライブモジュール１１４は、アクセスモジュール１１ ３からのシンボル信号をハードウェア信号に符号化する。モジュールの始動で継 承される動作システムで扱われる事象／信号のための一般ドライバ支持機能も存 在する。これは、ハードウェアとソフトウェアとの間の信号を移送するための実 行機構であると見做すことができる。ターミナル／ハードウェアのそれぞれのタ イプのために１つのドライバモジュールが存在する。

システム内に含まれているものは、管理機能の異なるタイプのアレーを収容する 幾つかの管理モジュール１１１で、これは、（ａ）故障管理：　（ｂ）配置管理 ：　（Ｃ）計数管理、（ｄ）遂行管理：　（ｅ）他のなかでの安全管理とを含む 。

管理特徴は、特徴モジュール９０が電話特徴を規定し実行したのと近似した方法 で、管理モジュールＩｌｌにより扱われる。管理モジュールは、１つのタイプ又 はｌ以」二の管理機能を扱うことかできる。管理モジュール１１１は、それぞれ 第９図及び第１１図に示されているように、管理ユーザモジュールｔｔｚｂと、 管理アクセスモジュール１１３ｂと、管理ドライバモジュール＋１４ｂとにより 構成される。特徴モジュール９０が動作するのと同様な方法で、管理ドライバモ ジュール１Ｉ４ｂは、管理プロトコルの意味部分を扱い、そして、管理アクセス モジュールｌ１３ｂは、管理プロトコルの意味部分のために応答できる。最後に 、管理モジュールＩＩＩは、次のように特徴モジュール９０と相互に作用される 。

（ａ）配置命令のためのデータベースを介して（ｂ）特徴の記録を行うレポート ／メツセージ受信で、（Ｃ）データベースを介して、ライン管理用の／）−ドウ エアで直接に、 再び第１＋図を参照し、ブロック図は、ソフトウェアアーチテクチャ−の種々の コンポーネントの配置を示す−だけでなく、第８図に示されているように、それ ぞれのコンポーネントの間での相互作用を指示している。特徴モジュール９０は 、適切なアプリケーションＢＯＳデータベース１０４の特徴単一データフィール ドを創造し、そして、フォーマットを割り当て、１２２及び１２３で示されてい る初期部分における不履行データ値１２２を制限する。管理モジュール１１１は 、１２５で示されているクラスデータフィールド１２４を参照することによりそ の初期部分命令とパラメータとを創造する。これらは検索クラスデータフィール ド１２４典拠制限及びアクセスと共に配置データベース＋０４に保存される。管 理モジュール１１１のドライバ１１４ｂへの、１２８での命令の受信で、該命令 は命令解析器により１２７で解析され、命令に用いる典拠がチェックされる。更 に、１２７及び１２８て、与えられたパラメータが、クラスデータフィールド１ ２４内に保持された値制限内か否かを決定する。命令か受け取られたなら、適切 な個人が現実のメツセージ特徴によりアクセスすることが許され、そして、適切 な特徴−単一データフィールド１３１がそれで動作し、１３２及び＋３３で示さ れているようにユーザモジュール１１２ｂにより受信される。このような動作は 、挿入、変化、プリント、及び動作除去を含む。

更に詳細に、特徴モジュール９０のユーザモジュール１１２ａ内の初期部分は、 開始されたときにＡＯ３ｉｉ９（１ｎｔｒｕｓｉｏｎ　ｃａｔ　Ａ　）で用いら れるエクステンションクラスデータ１２＋のＢＯＳデータベース＋０４の不履行 データを開始する（即ち、開始したパーティのザービスの発呼、或いは、カテゴ リ、Ａ−パーティ、侵入の開始）。このデータのために割り当てられたフォーマ ット、或いは、制限は、該データベース１０４に保持される。

特徴モジュール９０のユーザモジュール１１２ａ内のツクが発呼される。この手 続きは、最初に、該関連するユーザか、個々のエクステンションデータベース１ ３１にプログラムされた１ｎｔｒｕｓｉｏｎ　ｃａｔ　Ａのための個々のカテゴ リを有するか否かをチェックする。もしもそうなら、このカテゴリか用いられる 。さもなくば、エクステンションクラスデータベース１２１の特定された不履行 データ１２２か用いられる。

管理モジュールＩｌｌのユーザモジュール１１２ｂ内の初期部分は、開始される とき、ＡＯ３層９２手続きの利用で、エクステンションクラス不履行データ１２ ２で規定されたそれぞれのパラメータ或いは属性のために配置クラスデータ１２ ４の参照１２５を創造する。

管理動作か、管理モジュールＩＩＩのアクセスモジュール１１３ｂ内て受信され たとき、実際の動作が、管理ユーザの典拠と共に認証されて動作に使用される。

ひとたび該管理動作か有効とされたなら、それはユーザモジュールｌ１２ｂに渡 される。もしも該管理動作が値“イエス”で、エクステンション“１２３４５″ のための１ｎｔｒｕｓｉｏｎ　ｃａｔ　Ａのためにデータフィールドが作られた なら、次が取られる：ユーザモジュール１１２ｂが、ＡＯ３層９２手続きの利用 により、エクステンションクラス１２１内で不履行データ１２２を発呼し、デー タフィールド“１ｎｔｒｕｓｉｏｎ　Ｃａｔ　Ａ”パラメータの実際のフォーマ ットを得る。もしも該値“イエス”がこのフォマット内て有効とされたなら、Ａ ３０層９２内の手続きか発呼され、値“イエス”でエクステンション”１２３４ ５”のための個々のエクステンションデータ１３１が更新される。該管理動作が 、エクステンション“１２３４５″のためのデータフィールド１ｎｔｒｕｓｉｏ ｎ　ｃａｔＡ”を得たなら、ＡＯ３層手続きが発呼されて、それが個々のエクス テンションデータ！３１の実際の値１３３を連れてくる。

管理特徴は、例えば、特徴記録データがらの出力を受信することもてきる。そこ で、該管理特徴は、一定の事象と選択された電話特徴とに同意し、その事象か発 生したときに、該電話特徴は、適切な管理特徴に基準メツセージをダンプする。

そこで、命令は、以下を順に決定するこの管理モジュールＩＩＩによって扱われ る：（ａ）受信されたデータを見逃すべきか否か。

（ｂ）何時出力を発生ずへきか （Ｃ）何方のデータを出力するか （ｄ）出力データのためのフォーマット（ｅ）出力データを送るべきアドレス 管理モジュールＩＩＩは、ローカルターミナル或いはネジｌ−ワーク管理センタ のいずれかから到達する。

アプリケーションデータは、スタティックデータとダイナミックデータとの２つ のタイプに分割される。全てのデータは、基本動作システム９３により管理され るデータベース内で物理的に保持され、上述されたデータのそれぞれのビューは アプリケーション層９１から見れる。

スタティックデータは、１つの発呼よりも長生きするデータである。スタティッ クデータの寿命は、例えば１日等短くすることかでき、該データの寿命はデータ を所有する特徴に依存し、このようなデータの多くはシステムの終了までは生き 残らず、或いは、システム終了後の／＜ツクアップメディアからの命令即ち回復 によりチェンジされるまで生きるデータの場合は長い。短い寿命のデータの例に は、長い寿命データの例かナンバーシリーズの間のフォローミデータ或いはコー ルバック情報、ユーザのために許容された特徴アクセス（サーヒスのクラス）、 ユーザ活性化特徴、データ関連特徴等が含まれる。

あるタイプのデータは、目的語のクラス、或いは、クラスか一定のユーザタイプ と見做すことかできる上位クラスのいずれかに属する。このデータタイプは、名 前と、不履行値と、特定されたフォーマットと、許容された値の間隔と、システ ム終了後に回復すべきか否かについての情報とを有する。個々は創作されたとき のクラスと関連し、個々の構成要素の具体化によりこれらは適切なりラスデータ を継承する。該不履行データ値はそれぞれの個々のために変更される。典型的な りラスデータは：エクステンションクラスデータ１２１と、配置クラスデータ１ ２４と、オペレータクラスデータと、行き先クラスデータと、ルートクラスデー タとトランククラスデータとを有する。クラスとクラスの個々とを見つけ出すた め、解析テーブルか本システムに含まれている。クラス及び／又はクラスの個々 の創造成いは変化で、分配され或いは変更されるデータかある。

ダイナミックデータは、発呼に関連するデータで、該発呼が終わると消える。典 型的なダイナミックデータは、発呼のパーティ間の参照と、発呼履歴（即ち、特 徴の実行、初期の接続等）と、発呼状態とを含む。ダイナミックデータは、目的 ／プロセス自身によってのみ操作でき、アクセスはデータ名によって成される。

対照的に、スタティクデータは、データ名と結合したオーナ参照によってアクセ スか得られる。

特徴モジュール９０と管理モジュール１１１とを含んでいるアプリケーション層 より低いレベルての、アプリケーション動作システム層９２が第１１図に表され ている。アプリケーション動作システム層９２での意図は、アプリケーション層 からの実行明細の分離にあり、これにより、アプリケーション設計に関する抽象 レベルを高める。動作システムへのインターフェイスは一般的で、アプリケーシ ョン動作システム層９２が、システムハードウェアに含まれる動作上のシステム 機能と内部変化とに関連して影響されないままであることを意味する。第８図に 示されているように、アプリケーション動作システム層９２は、ツールキット９ ８と一般機能９９とからなる２つの主機能グループを有する。該アブリケーンヨ ン動作システムツールキット９８は、アブリケーンヨン層９１へ一般目的語機能 を提供する。該アプリケーション動作システムツールキット９８に含まれること かある典型的な機能としては、（ａ）インタパーティ通信：（ｂ）パーティ扱い 、（Ｃ）スイッチ動作；　（ｄ）キュー扱い、（ｅ）タイミング、（ｆ）履歴扱 い：　（ｇ）データフィールド扱い、（ｈ）ナンバー扱い、（ｉ）手続き扱い： Ｎ）整理扱いとかある。

更に第８図を参照し、該アブリケーンヨン動作システム９２−膜機能９９は、事 象／サブ状態扱いのため、及び、新たな状態に入るための支持機能を提供する。

該−膜機能９９は、アブリケーンヨン層のエンジンであると見做すことかできる 。事象またはサブ状態が発生したなら、−膜機能９９により提供された支持機能 か、固定された順番でシステムのユーザモジュール１１２（或いはアクセスモジ ュール＋１３）に、パラメータを含んでいるこのサブ状態或いは事象を一致させ ることを試みる。

もしも該事象或いはサブ状態かユーザに関連するなら、特徴リストに従いユーザ モジュール１１２で一致化か試みられる。もしも該事象がアクセスに関連するな ら、アクセス特徴リストに従いアクセスモジュール１１３で一致化が試みられる 。ユーザモジュール＋１２或いはアクセスモジュール＋１３との事象の一致か見 いだされたとき、このモジュールは発呼され、対応の機能が実施される。もしも ユーザに関連するサブ状態或いは事象が一致する事象或いはサブ状態を存しない なら、該発呼は失敗するであろう。アクセスに関連する事象が一致する事象を有 しないなら、事象は無視される。

該アプリケーション動作システム９２は、新たな状態に入るための組み込まれた 機能を含み、これは、ユーザモジュールからアクセスモジュールのいずれかに向 かうことかできる。この”新たな状態”としては次が含まれる。

（ａ）新たな状態 （ｂ）与えられた新たな状態に入る前のサブ状態（Ｃ）加えられ或いは取り除か れたパーティとの結合の新たな状態 （ｄ）現在状態 （ｅ）発呼／なし状態の失敗 発呼モジュールの規定において、プロセスコンセットはアプリケーションの実行 時間構造をモジュール化するように選択される。このコンチクストを用いて、該 期限プロセスは、データの関連するセットと陳述のシーケンソヤルな実行を行お うとする。外部の刺激／信号により、プロセスは同時に実施され、プロセスが活 性化する（即ち、実施状態となる）。プロセスは。実施が完了するとき常に一定 の規定された状態になる。該プロセスコンセットのこれら全ての特性は、通信の 特性（即ち、−以上の連続した動作からそれぞれ成る、多くの平行な発呼）にと ても良く一致する。該プロセスコンセットは、上述したように、本発明の特に創 造されたプログラミング言語と拡張された動作システムの両方により支持される 。

本システムにおいて、アプリケーション構造と実行時間構造との間て可能な限り 完全に一致するように、アプリケーションコートが定められるのと同様な方法で プロセスの程度は定められる。第１２図に示されているように、アプリケーショ ンコードは、機能的仕様目的に可能な限り近似するようにモジュール化される。

この構造は、ユーザプロセスのそれぞれのパーティとアクセスプロセスのライン のそれぞれのタイプの、ドライノくプロセスのそれぞれのハードウェア装置のた めの１つのプロセスの仮定へと導く。

特徴のネットワーク化と独立操作可能な通信スイッチング特徴とかよく一致すべ きであるため、本システムは、実行する発呼制御のために分割ビューを用いる。

これは、それぞれ一方かプロセスのセットを有する、２つの発呼側か存在するこ とを意味する。該分割発呼制御の主たる利点としては次か含まれる。

（ａ）状態の全体の数が非常に減少する。該状態コンセットは、アプリケーショ ンコードの複雑さを軽減するのに用いられる。これは特に望まれるコンセットで ある。

集中化された発呼モデルにおいて、状態の数は、幾つかのパーティと結合された 配置へ加えられる状態で大きくなり制御できなくなる傾向がある。

（ｂ）それぞれが自身の状態と履歴とを存する該パーティは、互いによく分離さ れる。発呼がオリジナル発呼配置（通常は２つのパーティ発呼で）に戻ったとき 、それぞれの発呼側のためのデータは未だ有効である。分割発呼制御は、決定が なされる前に、発呼側の間での打合せ及び通信を多くの場合要求する。両側（サ イド）の間での通信は、プロセス間を通過するメツセージを提供する高レベルプ ロトコルにより支持される。少なくとも３つの異なる通信状況か支持される。

（ａ）非承認のメツセージ送り （ｂ）承認のメツセージ送り （Ｃ）承認及び更なる情報の要求のメツセージ送り通信のこれらのタイプのそれ ぞれのため、次の４つのメツセージのタイプかある。

（ａ）非承認メツセージか予期されたとき、メツセージを送るのに用いられる告 知メツセージ（ｂ）承認メツセージが予期されたとき、メツセージを送るのに用 いられる要求メッセージ （Ｃ）返答メソセージを与える前に、更に情報を要求するときに用いる確認メソ セージ （ｄ）先の要求メソセージへの認証メツセージである返答メソセージ 第１２図は、プロトタイプＰＢＸスイッチングシステム用の特定の設置計画のフ ンチクスト内について以前に議論したものを示している。第１２図は、分割発呼 制御パラダイム（ｐａｒａｄｉｇｍ）により必須とされる両発呼側間の通信を施 行するために、利用及び実施されなければならないプロトコルを示している。該 両側（サイド）の間の通信は、最初、ユーザからユーザへ送られるメツセージの ための高レベルプロトコル１８０により支持される。

他の低いレベルのプロトコルは、通信をハートウエアレベルヘダウンするのとチ ェーンへのバックアップとの完了を支持する。該ユーザ／アクセスプロトコル１ ８１は、ユーザプロセス１６５とアクセスプロセス１６４との間の通信を提供す る。該アクセス／ドライバプロトコルＩ８２は、アクセスプロセス１６４とドラ イバプロセスＩ６３との間の通信を提供する。最後に、ノ１−ドウエア／トライ バプロトコル１８３は、ドライ／＜プロセス１６３と個々のハードウェアユニッ ト１８４との間の通信を提供する。

第１３図は、示されている基本発呼の２つの離れた発呼側のそれぞれの−っであ るユーザプロセス１６５ａ、ｂとアクセスプロセス１６４ａ、ｂとドライバプロ セス１６３ａ、ｂとを示す基本発呼のための発呼モデル例を図示している。ハー ドウェアは、何時ハードウェアが開始されるかを検出し、そのドライバプロセス へ信号ピットストリームを送る。そこで、ドライバ１６３は、該信号ピットスト リームを記号形状に変換し、そして、メツセージをそのアクセスプロセス１６４ へ送る、これは、発呼されたパーティのために論理的な個々の参照を与えるため 発呼されたパーティのためのアドレス情報の受信、解析、変換に待機する。この 仕事が完了したとき、該アクセスプロセス１６４はその発呼側のためのユーザプ ロセス１６５を開始し、設定メツセージをそれに送る。該ユーザプロセス１６５ は、論理的な個々の参照を発呼されたパーティに割り当てる。そこで、同じ発呼 されたパーティのためにユーザプロセス１６５ｂを開始し、そして、発呼を設定 するようユーザプロセス１６５ａに依頼する。該発呼されたパーティのための該 ユーザプロセス１６５ｂは、該パーティを捕獲し、そして、其自身をこのユーザ プロセス１６５ｂにリンクさせるように、このパーティのためのアクセスプロセ ス１６４ｂに依頼する。

そこで、承認メツセージが、発生側のユーザプロセス１６５ａに送り返され、そ れにより、基本発呼のだめの完全な発呼モデルか設定される。

次に、第１４図を参照し、ここには、３つのパーティを含む発呼のための発呼モ デルの図が示されている。問い合わせ発呼１８７のため、即ち、オペレータか第 ２発呼側を設定したとき、アクセスプロセス１９１ａか第１発呼１８８を預け、 この新たな発呼１８９のためにプロセス（ユーザ１９２ａ−ユーザ１９２ｃｍア クセス１９１ｃ−トライバ１９０ｃ）の同一のシリーズを設定する。

該アクセスプロセス１９１ａは、それにより、一つがそれぞれの発呼のために、 プロセス１８８．１８９の２つのシリーズへリンクされる。

次に、第１５図を参照し、ここでは複合−パーティ発呼のための発呼モデルの図 が示されている。複合パーティ発呼において、プロセスの通常発呼側チェーンが 、それぞれの参加者のために用いられる。反対の発呼側て、１つの共通通常サー ビスユーザプロセス＋９５が存在する。それはリンクされたアクセスプロセスを 有さす、これにより、この配置は、それぞれの参加者の発呼側からの通常２つの パーティ発呼のセットに似せて作る。

次に、第１６図を参照し、ここでは、オペレータへの再発呼のための発呼モデル の図が示されている。オペレータへの再発呼て、元の発呼のそれぞれのユーザ２ ００ａ、ｂからそれぞれの発呼側の１オペレータユーザ２０Ｉａ−ｂヘリングさ れた新たな発呼側か存在する。特徴を設計する時に、該発呼モデルは、記憶に止 めなければならず、ぞして、第１３図−第１６図に関連して上述した例及び原理 は、将来のシナリオのため発呼モデルを作成するためのガイドラインであると見 做すことかできる。

埋包的に、アブリケーソヨンコンセブ１へによく一致するモデル、そして、アプ リケーション像の可能性ある新たな状態に容易に適合するモデルを得るよう努力 すべきである。

本発明のシステムで用いられるプログラミング言語は、リアルタイム施設で並列 な動作か可能な拡張された宣言言語である。言語ＥＲＬＡＮＧは、これら必要な 特性を存し、その内の幾つかは例えば次である。

（ａ）ダイナミックメモリ管理により支持されるＬＩＳＰやＰＲＯＬＯＧからの リスト及び要素集合（ｔｕｐｌｅ）のような高レベルデータ構造（ｂ）ＬＩＰＳ のような効率的なプログラム開発と同しタイプで与えられる高レベル記号プログ ラミング（Ｃ）プログラミングの短く明瞭なスタイルを与える簡単な制圓構造と バタンマツチングとによる実行（ｄ）大きなプログラムシステムを構成するため の補助として適用されるモジュール （ｅ）プロセス制御及び同時に支持しリアルタイムの動作する通信のプロセス （ｆ）エラー検出、及び、例えば予備−発呼エラー回復を備える堅牢なシステム の設計を可能にするエラー修正 （ｇ’）ＳＤＬ−＼近似へのクロス、Ｃ，Ｃ，１，Ｔ、　Ｔ、推奨仕様言語 図示のように、以下の記述は基本発呼設置計画により取られる幾つかのコートの 例である。以下は、事象／状懸しベルからの例で、そこでは、５つのパラメータ を含む設定メソセージか受信される。事象のマツチングか、特徴リストに基づき 特徴モジュールのために実施される。

他の特徴は、該特徴との相互作用の機会か与えられるか、行われることはない。

最終マツチングが、以下に記述するように基本発呼モジュールで試みられる。

・１９９１　Ｔｅｌｅｆｏｎａｋｔｉｅｂｏｌａｇｅｔ　Ｌ　Ｍ　Ｅｒ１ｅ＋＋ ｍｏｎ最初の基本発呼設定句（ｃｌａｕｓｅ）と同時の全パラメータを含む受信 された設定メツセージとのマツチングの最初の試みてパターンマツチングか生し る。もしも一致（マツチ）するなら、この機能定義か加えられる。もし一致しな いなら、マツチングか次の句て試みれる等である。

パラメータにマツチングかないなら、制御はエンジンに戻される。哉本発呼か、 特徴リストの最終の特徴であるため、該発呼はこのケースでは失敗となる。高レ ベル記号プログラミングの例か、設定句でのパラメータ名及び名前で発呼される 機能により具象化される。なんらかの長さの好適な名前は、ソフトウェア設計者 によって選択できる。

高レベルデータ構造か、設定句のパラメータ（ＣａｌｌＴｙｐｅ、　Ｎｏ　Ｎａ ｍｅｌに含まれ、これは、２つの変数でデータ構造を表すリストである。本シス テムにおいては、ともかく現実に非常に少ない制御構造か存在する簡単な発呼制 御構造となる。上の例で、２つの制御構造のみ、即ち、ケースと継続（ｃｏｎｔ ｉ口ｕｅ）とか存在する。しかし、ケースステーｉ・メント（ｓｔａｔｅｍｅｎ ｔ）は最も重要な構造ステートメントである。下記の記述はフェイズレベルから の例で、ここで我々は、上記の例の最初の設定句が受信されたメソセージと一致 するものとする。この句のｌ　Ｑｃａｌｌ−ｓ【ａｒｔ−ｕｐ（Ｓ＠１４．Ｃａ １ｌＴｙｐｅ　）−））。

＠　１９９１　Ｔｅｌｅｆｏｎａｋｔｉｅｂｏｌａｇｅｃ　Ｌ　Ｍ　Ｅｒ１ｃｓ ｓｏｎその順ての該Ｃａ１ｌ　５ｔａｒｔ　ｕｐが一致したとき、該最初の機能 発呼はＡＳＯｌｉ！能チェック／２エラタれは２つのパラメータを有する。この 機能か評価され、結果か該Ｃａ１ｌ　５ｔａｒｔ　ｕｐ機能に戻され、他のＡＯ Ｓ機能のカップルを発呼し、そして結果を発呼設定機能に戻すことによりその仕 事を行う。

通信システムか属するリアルタイムシステムに組み込まれる開発における１つの 問題の奉賀は、常に２台のコンピュータか含まれることにある。常には、ＶＡＸ 、ＩＢＮｉ或いは池の同等機のホストコンピュータのため、エリクノンＡＸＥ　 ＳＰＣ通信スイッチングシステムで用いられるＡＰＮ或いはＡＰＺ等の特定され たプロセス装置のコンピュータの目標用、即ち、■いるプログラムの開発は行わ れる。これにおいて、プログラムは動作システムを実行する。これは、ホストコ ンピュータ上でプログラムの開発及び編集と、目標機での試験を行うのと間に大 きなターン・アラウンド・タイムが存在することか必然的であることを意味する 。しかじから、本発明のシステムにおいてこれらの活動は結合される。なんらか の操作によって、ラインインターフェイスモジュール（“ＬＩＮｉ”）は、ワー クステーション及びそのコンピュータによって制御され、そして、編集−実行サ イクルタイムかこれにより事実上取り除かれるように、ホスト及び目標コンピュ ータの機能を結合する。第１７図に示すように、このような設計／編集配置は、 多くの利点を有する。

第１８図に、本発明のシステムに比較して実質的に大きな数のステップを含む１ つの公知のワークモデルが示されている。如何に特徴が、本発明の簡単な記号作 業モジュール＋４２と比較して多くの数のブロック＋４１を収容するかが分かる であろう。したがって、仕様のステップの簡略化を大いに進めれ、また、最終動 作ソフトウェアシステムへ導くコーディングが存在する。

高いソフトウェア品質か本システムの軸となる他の利点である。本発明の幾つか の面か実施され、従前の公知通信システムに対する設計効率を決定する試験が行 われた。該設計効率試験の結果は、試験されたいずれの特徴についても、本シス テムが公知のシステムよりも良い動作を行った。更に、本システムを用いて特徴 を設計し、実行し、確認し、ドキュメント化するのに必要な時間は、平均して、 公知のシステムで必要とされる時間よりも非常に短い。

自分自身のコートの証明前に他の設計者のワークを待つことを、設計者か必要と しないという事実と結合した本システムのこれら効率的な機能が、ソフトウェア 開発をプランされ適切な順番のシーケンスでの作り出せるようにすることを意味 する。本システムは、全システムを容易に理解でき簡単に見ることかてきるよう にする、個個の既に証明された構築ブロックからなる明瞭な階層組織のソフトウ ェアを作り出す。更に、本システムは、独立し増加的に証明されるコートを許容 し、そして、エラー回復及びコード解析のためのツールを提供する。以前に簡単 に述へたように、特徴の設計と証明との両方に含まれる人の数を、１個人にまで 減少させることができ、これにより、待ち時間とリード時間とを短縮する。本シ ステムは、機能試験前でもプランニング及び設計証明を行うことを可能にする。

本発明のシステムを適用する設計特徴モジュールを簡単にそして、興味深くする 主たる要素は、機能的仕様の言語テキストか特徴モジュールのコードに対応する という事実に含まれ、これにより、コードと特徴との両方の理解を改善する。更 に、帰納的機能でリスト扱いのマツチングする言語品質を用いることにより、プ ログラムを小さくして見渡し得るようにてきる。設計は増加的、相互作用的に行 われ、大きく構成することが可能となる。

従って、パッチングか必要とされず、可能であっても、プログラムかフライ（ｆ ｌｙ）で再コンパイルすることができる。特徴及び特徴の一部の証明の繰り返し は自動化、即ち、単に試験ファイルの活性化によって自動的に行われる。そして 、データか高記号レベルで表示できる。設計時における容量の問題について考慮 する必要かなくなり、沢山の小量記載のトキュメンＩ・か存在し、設計者は、実 際の使用の開始前に全ての特徴の証明を行うことかできる。ソフ］へウェアの質 か非常に高められ設計者に十分な満足を与える。

上述した効率的な要素の多くは、システムに新たな機能性を付加するときに有効 にされる。機能性の該付加は、システムに新たな特徴モジュールを付加するのに 等しい。

この特徴モジュールは、基本発呼モジュールへ付加された完全に新しい機能性か 、或いは、基本発呼モジュール上の特徴モジュールの既存の機能性の取り替えか のいずれかを含む。

上述した効率的要素の多くは、分配された設計環境で特徴の設計を行うときにも 有効である。これらの最も大切なことは、開発か小さく、そして完全な特徴モジ ュールに分割されるという事実にある。該設計者は、彼の担当する特徴を創造す る際に他の設計者から独立する。加えて、狭いインターフェイスがコープイネ− ジョンの必要性を非常に小さくする。特徴設計者への必要な入力は、単に、機能 の仕様と、システムライブラリの現実のバーシュンと、アプリケージタン動作ツ ールキットとである。

最後に、特徴間の相互作用（即ち、特徴が発呼される順番）は、動作上の手続き により解決され、該相互作用を１つの単一位置で試験することかできる。

本発明のシステムの種々の面での試験から分かるように、ソフトウェアプロトタ イプの設置計画を可能にするソフトウェア言語構造と、同様に、通信スイッチン グシステムを実行するための基本ソフトウェアアーチテクチャ−との両方による 本来的な多くの利点か存在する。更に、該システムか他のプロセス制御システム アプリケーションへ簡単に適用できることが容易に分かるであろう。

本発明の構成及び動作が上記の記述から明瞭であると信しられる。示され記述さ れた方法、装置及びシステムは好適であるとして特徴付けられたもので、発明の 種々の改変と改良とか、以下のクレームで規定された発明の精神及び範囲から逸 脱することなく成し得ることは既に明瞭である。

Ｆｌに、７ Ｆｌに、５ ＦＩＣ；、６ ＦＩＧ、７２ 発呼側１　発呼側２ オペレータ フロントページの続き （７２）発明者　オーケ　ロスベルグ スウェーデン国ニス　−１３５５３ティレソ、ソフィエベルグスベーゲン　１０ （７２）発明者　バーカン　カールソンスウェーデン国ニス　−１１３３８スト ックホルム、トムテボガタン　１８，４トルブ

Claims (34)

【特許請求の範囲】
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. ２５．請求項２４の通信スイッチングシステム内で用いる多層ソフトウエアアー チテクチャーであって、前記アプリケーション動作システム層内の事象及びサブ 状態扱いのための一般支持機能を提供する手段が、事象或いはサブ状態を、特徴 リストに基づくアクセスモジュールか、アプリケーションユーザモジュールかの いずれかに一致させる手段を有することを特徴とする多層ソフトウエアアーチテ クチャー。
26. ２６．請求項７の通信スイッチングシステム内で用いる多層ソフトウエアアーチ テクチャーであって、前記基本動作システム層が、 前記システムによって実施される通信特徴と関連するデータの保持及び検索のた めのデータベースメモリを有することを特徴とする多層ソフトウエアアーチテク チャー。
27. ２７．請求項２６の通信スイッチングシステム内で用いる多層ソフトウエアアー チテクチャーであって、前記基本動作システム層の前記データベースが、データ のエクステンションクラスを保持する手段と、データの配置クラスを保持する手 段とを有することを特徴とする多層ソフトウエアアーチテクチャー。
28. ２８．請求項２７の通信スイッチングシステム内で用いる多層ソフトウエアアー チテクチャーであって、前記基本動作システム層の前記データベース内のデータ のエクステンションクラスを保持する手段が、クラスデータを保持する手段と、 不履行データを保持する手段と、 独立データを保持する手段とを有することを特徴とする多層ソフトウエアアーチ テクチャー。
29. ２９．アプリケーション層内の管理モジュール及び特徴モジュールと、基本動作 システム層内のデータベースとを有する通信スイッチングシステムのアーチテク チャー内のデータを管理する方法であって、前記方法が：前記データベース内の 特徴単一データフィールドを発生し、前記特徴モジュールの初期部分により前記 フィールドヘフォーマット、制限、不履行値を割り当て、前記データベース内の 前記データフィールドを参照するパラメータと前記管理モジュール命令の初期部 分を発生し、前記データベースに前記パラメータ及び命令を保持し、 その受信に応答してそれぞれの命令を解析し、その利用の典拠と、そのパラメー タが予め選択された値制限内か否かとをチェックし、 前記命令の受領に応答して管理特徴により適切な個別データ要素をアクセスし、 前記命令に応答して前記フィールドを改変するために適切な特徴単一データフィ ールドで動作することからなることを特徴とする方法。
30. ３０．請求項２９のアプリケーション層内の管理モジュール及び特徴モジュール と、基本動作システム層内のデータベースとを有する通信スイッチングシステム のアーチテクチャー内のデータを管理する方法であって、前記命令が、どのデー タを出力すべきかの決定と、ある基準に対して、前記受信されたデータを見逃す べきか否かの評価とを含むことを特徴とする方法。
31. ３１．基本動作システム層内のデータベースとアプリケーション層内の管理モジ ュール及び特徴モジュールとを含む通信スイッチングシステムのアーチテクチャ ー内のデータを管理するシステムであって： 前記データベース内で特徴単一データフィールドを発生し、前記特徴モジュール の初期部分により前記フィールドヘフォーマット、制限、不履行値を割り当てる 手段と、 前記データベース内の前記データフィールドを参照するパラメータと前記管理モ ジュール命令の初期部分を発生し、前記データベースに前記パラメータ及び命令 を保持する手段と、 その受信に応答してそれぞれの命令を解析し、その利用の典拠と、そのパラメー タが予め選択された値制限内か否かとをチェックする手段と、 前記命令の受領に応答して管理特徴により適切な固体をアクセスし、前記命令に 応答して前記フィールドを改変するために適切な特徴単一データフィールドで動 作する手段とからなることを特徴とするシステム。
32. ３２．プロセス制御システム内で用いるための多層ソフトウエアアーチテクチャ ーであって：特定されるプロセス制御アプリケーションヘの直接対応で構成され 、そして、前記システム内でのプロセス制御機能を実施するアプリケーション層 と、該アプリケーション層への支持機能を提供し、そこからのプロセス制御アプ リケーションの設置計画明細を隠し分離するアプリケーション動作システム層と ；時分割コンピュータシステムのための実行時間執行部と、基準原型と同様なプ ロセス制御機能の配置計画のために必要とされる機能及び原型を含む基本動作シ ステム層とを有することを特徴とするシステム。
33. ３３．請求項３２のプロセス制御システム内で用いるための多層ソフトウエアア ーチテクチャーであって、前記アプリケーション層が： 実行されるプロセス制御機能内の特定の作業を規定するための作業モジュールを 含むことを特徴とするシステム。
34. ３４．請求項３２のプロセス制御システム内で用いるための多層ソフトウエアア ーチテクチャーであって、前記作業モジュールが少なくとも： それに採用されるシグナリングプロトコルを含み、実施されるプロセス制御機能 内の特定の制御作業を規定する特徴モジュールと、 実施されるプロセス制御機能の提供に関連する管理機能を規定する管理モジュー ルとを有することを特徴とするシステム。