JPH10501358A - 通信用交換機のためのソフトウェアを作成する方法 - Google Patents

Abstract

(57)【要約】 本発明は通信用交換機を制御するのに適した共通機能ソフトウェアユニット（５５５）を作成するための方法である。これら共通機能ソフトウェアユニット（５５５）は現在のすべての通信用交換機（５０２）にてドメイン解析（５４２）を実行することにより作成され、この解析の結果、交換機のためのベアラーサービスハンドラー（ＢＳＨ）およびハードウェア（ＨＷ）のタイプのすべての可能な組み合わせに対する共通概念、用語、作用および機能が識別される。ユニバーサル共通ソフトウェアテンプレート（ＵＣＳＴ）（５４８）、関連するパラメータ定義ドキュメント（ＰＤＤ）（５４４）および関連するアブストラクトデータタイプ定義（ＣＡＤＴＤ）（５４６）の群において共通作用および機能が実現される。ＣＡＤＴＤのサブセットと共にＵＣＳＴがコンパイルされ、テストされる。ＵＣＳＴがコンパイルされ、テストされた後にＵＣＳＴおよびＣＡＤＴＤからＢＳＨとＨＷの異なる組み合わせに対する複数の共通ソフトウェア関数ユニット（ＣＳ）を作成できる。

Description

【発明の詳細な説明】 通信用交換機のためのソフトウェアを作成する方法 背景 本発明の分野 本発明は複雑な電子システムを制御するためのソフトウェアを作成する方法に 関し、より詳細には通信用交換機を制御するためのソフトウェアを制御するため の方法に関する。 関連技術の経過 第１図（従来技術）は通信システムで使用される最新の通信用交換機１０２を ほぼ示すブロック図である。交換機１０２は少なくとも１つの交換機用ソフトウ ェアモジュール１１０と、交換機用ハードウェア（ＨＷ）１０８と、交換機１０ ２への複数のデータ入力１０４と、交換機１０２からの複数のデータ出力１０６ とを含む。交換機用ハードウェア１０８によりデータを極めて高いデータレート で転送することが可能となっている。 交換機用ソフトウェアモジュール１１０は交換機ユーザーソフトウェア１００ に交換機１０２の論理的なビューを提供する。１つの論理的ビューは交換機のユ ーザーに対して複数のフォーマットを提供し、これらフォーマットの各々はこれ ら１０２内でデータをどのように送受信すべきか、および接続のタイプ（例えば ポイント対ポイント、ポイント対マルチポイント、マルチポイント対ポイントま たはマルチポイント対マルチポイント）を表示する。以下、交換機の論理的ビュ ーをベアラーサービスハンドラー（Bearer Service Handler−ＢＳＨ）と称す。 ＢＳＨは交換機用ハードウェア１０８の限られた知識しか有していない交換機ユ ーザーでも交換機用ハードウェア１０８を制御できるようにもする。 データ入力１０４で、ある特定のフォーマットで入進データが受信され、デー タ出力１０６で別の特定のフォーマットで送信される。交換機ユーザーソフトウ ェア１００はユーザーインターフェース１１２を介して交換機１０２と通信する 。スイッチユーザーソフトウェア１００は１つ以上のデータ入力１０４で第１の 特 定のフォーマットにて受信されたデータが１つ以上のデータ出力１０６に交換さ れ、第２の特定のフォーマットで送信されることを指定する。特定フォーマット の例としては非同期転送モード- 仮想パス（ＡＴＭ- ＶＰ）、非同期転送モード - 仮想チャンネル（ＡＴＭ- ＶＣ）、同期転送モード- 毎秒６４キロビット（Ｓ ＴＭ- ６４ｋ）、および同期転送モード- 毎秒２メガビット（ＳＴＭ- ２Ｍ）が ある。 ＡＴＭは固定長さの５３バイトセルに基づくセル交換技術である。オーディオ 、データ、画像すなわちビデオなどを含むすべての広バンドの送信信号が一連の セルに分割され、ＡＴＭ交換機により接続されたリンクから成るＡＴＭネットワ ークを通ってルート化される。各ＡＴＭリンクは一定ストリームのＡＴＭセルス ロットから成り、このセルスロット内に送信信号が挿入されるか、または使用し ない場合にはアイドル状態のままである。ＡＴＭの最大の利点は１つのネットワ ークが多数の広バンドサービスの要求を満たすことができるようにサービスを一 様に取り扱うことにある。ＡＴＭ技術は送信および交換の双方に対するフレキシ ビリティと適性を考慮して、広バンドの統合サービスデジタルネットワーク（Ｂ −ＩＳＤＮ）を実現するため、１９８８年における国際電信電話諮問委員会（Ｃ ＣＩＴＴ）の国際規格機構により選択されたものである。ＡＴＭ- ＶＰでは仮想 パス識別子（ＶＰＩ）値を使用することにより交換を行う。これと対照的に、Ａ ＴＭ- ＶＣ交換はＶＰＩ値と仮想チャンネル識別子（ＶＣＩ）値の双方を使用す ることにより行われる。 ＳＴＭはフレームパターンのような１つの基準に対して定期的および固定パタ ーンで生じる情報に従属したトランスポートおよび交換方法である。 通信用フォーマットは交換機用ハードウェアがサポートする交換フォーマット のタイプに従って分類される。例えばＳＴＭフォーマットをサポートする交換機 はＳＴＭ交換機と称され、ＡＴＭフォーマットをサポートする交換機はＡＴＭ交 換機と称される。最新の通信業界では複数の指定フォーマットをサポートするよ うに交換機が製造されている。例えばＡＴＭ交換機はＡＴＭ- ＶＰおよびＡＴＭ - ＶＣ指定フォーマットの双方をサポートでき、ＳＴＭ交換機はＳＴＭ- ６４ｋ およびＳＴＭ- ２Ｍの双方をサポートできる。 第２図（従来技術）は交換機用ソフトウェアおよび交換機用ハードウェアを有 する通信用交換機３０６を示すブロック図である。交換機３０６はタイプＡ（Ｓ Ｈ- Ａ）の交換機用ハードウェア３１４と、交換機用ソフトウェアユニット（Ｓ Ｓ１）３０８、（ＳＳ２）３１０および（ＳＳ- １- ２- Ａ）３１２を含む。交 換機３０６はタイプ１のＢＳＨ（ＢＳＨ１）およびタイプ２のＢＳＨ（ＢＳＨ２ ）（図示せず）もサポートする。ソフトウェアユニットＳＳ１ ３０８およびＳ Ｓ２ ３１０はそれぞれＢＳＨ１およびＢＳＨ２に従属する。ソフトウェアユニ ットＳＳ- １- ２- Ａ ３１２はＢＳＨ１、ＢＳＨ２およびＳＨ- Ａに従属する 。ユーザーインターフェースＵＩ- ＢＳＨ１ ３０２およびＵＩ- ＢＳＨ２ ３ ０４はそれぞれＢＳＨ１およびＢＳＨ２をサポートし、交換機３０６でＢＳＨ１ またはＢＳＨ２を選択できる能力をユーザーに与える。 最新の通信業界ではソフトウェアユニットＳＳ１ ３０８、ＳＳ２ ３１０お よびＳＳ- １- ２- Ａ ３１２は特定タイプのハードウェアを有し、少なくとも １つのＢＳＨを実現する１つのタイプの交換機（ＡＴＭまたはＳＴＭ）でしか運 用しないように製造されている。換言すれば、ソフトウェアユニットＳＳ１ ３ ０８、ＳＳ２ ３１０およびＳＳ- １- ２- Ａ ３１２はユニバーサル共通ソフ トウェアテンプレート（ＵＣＳＴ）から製造されていない。 通信用交換機のためのソフトウェアユニットの現在の設計に関連した欠点はい くつかある。かかる１つの欠点は特定タイプのＢＳＨすなわち交換機用ハードウ ェアに従属するソフトウェアユニットごとに更新または変更を繰り返さなければ ならないことから生じている。例えば交換機用ハードウェアに対して行われる変 更は交換機用ハードウェアに従属するソフトウェアユニットごとの更新時に表示 されなければならず、特定のＢＳＨに関して行われる変更は、ＢＳＨに従属する ソフトウェアユニットごとの更新時に表示されなければならない。ソフトウェア ユニットの現在の設計に関連した別の欠点は、異なるグループの開発者に交換機 のタイプごとにソフトウェアユニットを作成させることから生じている。ソフト ウェアユニットの作成中、異なるグループの開発者は一貫性のない用語、概念お よびアーキテクチャを使用することが多い。ソフトウェアユニットにおける一貫 性のなさにより、ソフトウェアユニットとインターフェースする交換機ユーザー ソフトウェアをデザインする際に多くの困難が生じる。 複数のタイプの交換機用ハードウェアおよびＢＳＨに対し共通なソフトウェア ユニットを作成できるユニバーサル共通ソフトウェアテンプレート（ＵＣＳＴ） をもっことが明らかに有利である。 発明の概要 本発明の目的は、更新または変更の繰り返しを必要としない共通機能ソフトウ ェアユニットを設計し、作成できるユニバーサル共通ソフトウェアテンプレート （ＵＣＳＴ）を提供することにある。本発明の別の目的は、ＵＣＳＴに対して行 われる変更を自動的に表示する共通機能ソフトウェアユニットを作成することに ある。 本発明の別の目的は、共通機能ソフトウェアユニットの設計、作成、維持およ び更新にかかる時間を短縮し、費用を削減することにある。設計者がＵＣＳＴに 精通するだけでよく、種々の共通機能ソフトウェアユニットに精通しなくてもよ いことから、このような時間の短縮および費用の削減が可能となっている。 本発明の別の目的は、すべての共通機能ソフトウェアユニットを実現するため の単一の組のドキュメンテーションとなるように、ソフトウェアのドキュメンテ ーションを少なくすることにある。このように、単一の組のドキュメンテーショ ンとすることにより用語およびフレーズを使用する際の一貫性のなさおよび混乱 を回避できる。 図面の簡単な説明 添付した明細書と関連して次の図面を参照すれば、当業者には本発明について より良好に理解でき、その多数の目的および利点がより明らかになろう。 第１図（従来技術）は、通信システムで使用される最新通信用交換機１０２を ほぼ示すブロック図である。 第２図（従来技術）は、交換機用ソフトウェアおよび交換機用ハードウェアを 有する通信交換機を示すブロック図である。 第３図は、本発明に係わる方法を示す機能ブロック図である。 第４図は、本発明の好ましい実施例において共通機能ソフトウェアユニットを 作成するための作動を一般に示すフローチャートである。 第５図は、第４図のユニバーサル共通ソフトウェアテンプレート（ＵＣＳＴ） 、パラメータ定義ドキュメント（ＰＤＤ）およびアブストラクトデータタイプ定 義（ＣＡＤＴＤ）のコレクションを作成する工程をより詳細に示すフローチャー トである。 第６図は、第４図の共通機能ソフトウェアユニット（ＣＳ）を作成する工程を より詳細に示すフローチャートである。 第７図は、本発明の要旨に従い、ユニバーサル共通ソフトウェアテンプレート （ＵＣＳＴ）およびアブストラクトデータタイプ定義（ＣＡＤＴＤ）のコレクシ ョンから作成された共通機能ソフトウェアユニットを含む通信用交換機を示すブ ロック図である。 詳細な説明 第３図は、本発明の方法を示す機能ブロック図である。ドメイン解析５４２に おいてすべてのタイプの通信用交換機５０２を検討する。このドメイン解析５４ ２の結果、交換機５０２に対するＢＳＨとＨＷのすべての可能な組み合わせに対 する共通の概念、用語、作用および機能(functionality)が得られる。ユニバー サル共通ソフトウェアテンプレート（ＵＣＳＴ）５４８、関連するパラメータ定 義ドキュメント５４４（ＰＤＤ）およびアブストラクトデータタイプ定義５４６ の関連するコレクション（ＣＡＤＴＤ）において、共通な作用および機能が実現 される。ＰＤＤ５４４はＵＣＳＴ５４８で用いられるパラメータに対する節(sec tion)および章(chapter)を有する。ＣＡＤＴＤ５４６はＵＣＳＴ５４８のパラメ ータと関連する複数のアブストラクトデータタイプ定義から成る。ＵＣＳＴ５４ ８およびＣＡＤＴＤ５４６を実現するコンピュータコードは、ＢＳＨ従属性、Ｈ Ｗ従属性またはＢＳＨおよびＨＷの双方の従属性を示すプリフィックス(prefix) を示す。ＵＣＳＴ５４８はＣＡＤＴＤ５４６のサブセットと共にコンパイル(com pile)されテストされる。ＵＣＳＴ５４８がコンパイルされ、テストされた後、 ＵＣＳＴ５４８およびＣＡＤＴＤ５４６からＢＳＨとＨＷとの異なる組み合わせ に対する複数の共通機能ソフトウェアユニット（ＣＳ）が作成される。ＵＣＳＴ ５４８およびＣＡＤＴＤ５４６から関連するコンピュータコードをコピーするこ とにより、共通機能ソフトウェアユニット（ＣＳ）が作成される。コピ ーされたコンピュータコード内に存在するプリフィックスがＣＳを運用すべき交 換機によりサポートされたＢＳＨとＨＷとの組み合わせを識別するプリフィック スと置換される。例えばＵＣＳＴ５４８およびＣＡＤＴＤ５４６から関連するコ ンピュータコードをコピーすることにより共通機能ユニット（ＣＳ）５５５を作 成してもよい。コピーされたコンピュータコード内に存在するプリフィックスは ＣＳ５５５を運用すべき交換機のためのＢＳＨおよびＨＷを識別するプリフィッ クスと置換される。 第４図は、本発明の好ましい実施例における共通機能ソフトウェアユニットを 作成するための作動を一般に示すフローチャートである。まずステップ６０４に て一組の通信用交換機のためのベアラーサービスハンドラーとハードウェアのタ イプのすべての可能な組み合わせが識別される。次にステップ６０５にて、上記 のように識別されたベアラーサービスハンドラーおよびハードウェア上でドメイ ン解析が実行される。ステップ６０６にてドメイン解析からユニバーサル制御ソ フトウェアテンプレート（ＵＣＳＴ）、パラメータ定義ドキュメント（ＰＤＤ） 、およびアブストラクトデータタイプ定義のコレクション（ＣＡＤＴＤ）が作成 される。ステップ６０８にてＵＣＳＴおよびＣＡＤＴＤから共通機能ソフトウェ アユニットが作成される。上記工程の各々についてより詳細に後述する。 ステップ６０４において、一組の交換機に対する異なるタイプのハードウェア とベアラーサービスハンドラーとのすべての組み合わせが識別される。例えば特 定の組みの交換機に対してベアラーサービスハンドラー１、２、３および４とハ ードウェアタイプＡ、Ｂ、ＣおよびＤが存在し得る。次の表ＩＩに示されるよう に、上記ベアラーサービスハンドラーおよびハードウェアタイプに対する可能な 組み合わせが存在し得る。 従って、ベアラーサービスハンドラー１はタイプＡまたはＣのハードウェア上 で作動し、ベアラーサービスハンドラー２はタイプＡのハードウェア上で作動し 、ベアラーサービスハンドラー３はタイプＢまたはＤのハードウェア上で作動し 、ベアラーサービスハンドラー４はタイプＢまたはＤのハードウェア上で作動す る。 ステップ６０５において、ステップ６０４で決定された組み合わせに対する共 通機能および作用を決定するように、ドメイン解析が実行される。使用可能な数 種類のドメイン解析技術が存在する。ドメイン解析は一般に（１）各ベアラーサ ービスハンドラーおよびハードウェアタイプの知識を有するエキスパートを集め 、（２）共通概念および要望を定義することから成る。 第５図は、第４図におけるステップ６０６でＵＣＳＴ、ＰＤＤおよびＣＡＤＴ Ｄを作成するステップをより詳細に示すフローチャートである。まずステップ７ ０６で共通機能および用語を記述するドキュメンテーションを作成する。このド キュメンテーションはＵＣＳＴ、ＰＤＤおよびＣＡＤＴＤを作成する全プロセス にわたって連続的に更新される。本発明に係わる好ましい実施例では、ステップ ７０８でオブジェクト指向のプログラム言語、例えばボーランドインターナショ ナル社により作成されたボーランドＣ＋＋またはマイクロソフト社によって作成 されたビジュアルＣ＋＋を使用し、オブジェクトを定義し、実行する。これらオ ブジェクトの各１つは共通機能のサブセットを実行する。以降、オブジェクト指 向のプログラム言語をＣ＋＋と称す。 ステップ７１２にてオブジェクトの各々に対し共通機能のサブセットを実現す るためのメンバー機能を作成する。１つのメンバー機能は名前およびオプション の引数リストによって示される独立した処理オペレーションである。メンバー機 能はＣ＋＋における１つのクラスに対して定義された機能に類似し、更に従来の ソフトウェアシステムで宣言された手順および機能に類似する。 ステップ７１６では定義されたオブジェクトに対するパラメータを決定し、定 義する。パラメータとは、メンバー機能が呼び出されたとき、供給された変数と 置換されるシンボルである。各パラメータは特定のデータタイプの定義と関連し ている。ドメイン解析および関連する引数リストから作成されるメンバー機能の 各々は共通機能概念を示している。従って、各メンバー機能はＢＳＨと使用され るハードウェアタイプとの組み合わせにかかわらず同じ名前および同じ数の引数 から成る。 引数の各々はパラメータによって決められた関連するデータタイプの定義を有 する。各引数に対するパラメータもＢＳＨとＨＷとの各組み合わせに対し同じ名 前を有する。しかしながら、ＢＳＨとＨＷとの異なる組み合わせは異なるデータ タイプの定義を必要とする。従って、パラメータが決めるデータタイプの定義も 、これを必要とするＢＳＨとＨＷの組み合わせに対して異なっていなければなら ない。例えば特定のＢＳＨを提供するＡＴＭ- ＶＣ交換機はＶＰＩおよびＶＣＩ をそれぞれ表示する（整数、整数）のデータタイプの定義を有するよう、チャン ネル番号(Channel Number)と称されるパラメータを必要とすることがあり、一方 、同じＢＳＨを実行するＡＴＭ- ＶＰ交換機はＶＰＩを表示する（整数）のデー タタイプの定義を有するようにチャンネル番号(Channel Number)を必要とするこ とがある。 ステップ７１８ではＰＤＤが作成される。このＰＤＤはＢＳＨとＨＷとの各組 み合わせに対する関連するデータタイプの定義を有するパラメータの名前のリス トを含む。ステップ７２２にてパラメータの各々にプリフィックスが加えられる 。識別されたＢＳＨ、ＨＷのタイプおよびＢＳＨとＨＷのタイプとの組み合わせ の各々に対し１つのプリフィックスが選択される。選択されるプリフィックスの 各各はＢＳＨ、ＨＷのタイプまたはＢＳＨとＨＷとの組み合わせを適当に識別す る能力を保持したまま、できるだけ短くしなければならない。選択されるプリフ ィックスの各々は同じ長さとなっていなければならない。更にパラメータが（１ ）ＢＳＨだけに従属しているか、（２）ＨＷのみに従属しているか、または（３ ）ＢＳＨおよびＨＷの双方に従属しているかを識別するのに３つのテンプレート からなるプリフィックスの１組が使用される。このテンプレートプリフィックス は選択されたプリフィックスと同じ長さとなっていることも必要である。更に、 テンプレートプリフィックスの各々は排他的であり、メンバー機能の（コメント を含む）コンピュータコード内の他の任意の組み合わせ内で使用することはでき ない。例えば表Ｉに対するテンプレートプリフィックスはそれぞれＢＳＨのみに 従属するか、ＨＷのみに従属するか、ＢＳＨのＨＷに従属するパラメータを表示 す るＢＳＨ、ＨＷＲおよびＢＨＷとなり得る。 ステップ７２２ではＰＤＤ内のパラメータの各々に選択されたプリフィックス が加えられる。しかしながら選択されたプリフィックスを加える前にＰＤＤ内の 個々の部分となるようにパラメータの各々が分類される。これら部分とは次のと おりである。すなわち包括的である(generic)か、ＢＳＨのみに従属する(BHS de pendent)か、ＨＷのみに従属する(HW dependent)か、ＢＳＨとＨＷに従属する(B SH and HW dependent)かのいずれかである。ＢＳＨおよびＨＷのすべてのタイプ に対する同じデータタイプの定義を有するパラメータは「包括的」節に分類され 、この節に入れられる。ＢＳＨのみに従属し、ＢＳＨのすべてに対し同じデータ タイプの定義を有するパラメータは「ＢＳＨ従属」節に分類され、この節に入れ られる。ＨＷのみに従属し、ＨＷのすべてのタイプに対する同じデータタイプの 定義を有するパラメータは「ＨＷ従属」節に分類され、この節に入れられる。Ｂ ＳＨおよびＨＷに従属し、ＢＳＨおよびＨＷのすべてのタイプに対し同じデータ タイプの定義を有するパラメータは、「ＢＳＨおよびＨＷ従属」節に分類され、 この節に入れられる。更に、ＢＳＨ、ＨＷおよびＢＳＨとＨＷとの組み合わせの タイプごとに別個の章が作成される。 包括的パラメータは自らの名前に加えられるプリフィックスを有しない。ＢＳ Ｈ従属パラメータはＢＳＨの従属性を表示する自らの名前に加えられるプリフィ ックスを有する。例えば交換機を通る接続を設定する役割を果たすメンバー機能 はアドレス＝［整数、チャンネル番号、整数、チャンネル番号］として表示でき るアドレスと称されるパラメータを必要とし得る。アドレスパラメータは交換機 への入力に対する数値Ｉｄ、入力チャンネル番号、交換機の出力に対する数値Ｉ ｄおよび出力チャンネル番号から成る。パラメータは包括的であるので交換機の 入力および出力に対する数値Ｉｄを示すパラメータにはプリフィックスは加えら れない。しかしながらチャンネル番号パラメータはＰＳＨの各タイプに対し異な る定義を有するので、パラメータの名前にＢＳＨのプリフィックスが加えられる 。更にアドレスパラメータは定義によりＢＳＨのタイプに従属し、パラメータの 名前に加えられたプリフィックスＢＳＨも有する。加えられたプリフィックスを 備えたアドレスタイプの定義はＢＳＨアドレス［整数、ＢＳＨチャンネル番号、 整 数、ＢＳＨチャンネル番号］として表示できる。従って、タイプの定義であるＢ ＳＨアドレスはＢＳＨに従属し、ＢＳＨおよびＨＷのすべての組み合わせに対し 同じデータタイプの定義を有する。 ＨＷ従属性パラメータはＨＷ従属性を示す名前に加えられたプリフィックスを 有する。ＢＳＨおよびＨＷ従属性パラメータはＢＳＨおよびＨＷ従属性を示す名 前に加えられたプリフィックスを有する。ＢＳＨに従属し、ＢＳＨのタイプごと に異なったデータタイプの定義を有するすべてのパラメータは、ＰＤＤ内のＢＳ Ｈのタイプごとに各タイプに対する別個の節に分類され、その節に入れられる。 例えば表Ｉ内のＢＳＨタイプのＢＳＨ１−ＢＳＨ４の各々は、これらに従属する パラメータに対するＰＤＤ内の別個の節を有することになる。ＨＷに従属し、Ｈ Ｗの各タイプに対し異なったデータタイプの定義を有するすべてのパラメータは 、ＰＤＤ内のＨＷの各タイプに対する別個の節に分類され、この節に入れられる 。例えば表Ｉ内のＨＷ Ａ−Ｄのタイプの各々は、これらに従属するパラメータ に対するＰＤＤ内の別個の節を有することになる。ＢＳＨおよびＨＷに従属し、 ＢＳＨとＨＷとの各組み合わせに対し異なったタイプの定義を有するパラメータ の各々は、組み合わせごとにＰＤＤ内の別個の節に分類され、この節に入れられ る。例えば表Ｉ内のＸをつけて表示されるＢＳＨとＨＷとの組み合わせの各々は 、これらに従属するパラメータに対するＰＤＤ内の別個の節を有するであろう。 ＵＣＳＴをテストするために使用されるテンプレートパラメータはステップ７ ２４で定義される。ＢＳＨとＨＷとの異なる組み合わせに対し異なる定義を有す る各パラメータはテンプレートパラメータとして定義される。テンプレートパラ メータはＢＳＨおよびＨＷに従属するパラメータに関連してこれまで説明したの と同じようにプリフィックスを受ける。ＢＳＨ、ＨＷまたはＢＳＨとＨＷに従属 するテンプレートパラメータはＰＤＤ内の従属性の各々に対応する節に分類され 、この節に入れられる。 ステップ７２８ではＣＡＤＴＤが作成される。本発明の好ましい実施例ではＣ ＋＋でＣＡＤＴＤが作成される。しかしながら、当業者であればオブジェクト指 向のプログラム言語を使用できることは明らかであろう。オブジェクト指向のプ ログラム言語は後にアブストラクトデータタイプ（ＡＤＴ）と以下称する、ユー ザーが定義するデータタイプを作成できる能力をユーザーに与える。ＡＤＴは他 のＡＤＴおよび／またはプログラム言語により既に定義されている基本的データ タイプ（例えば整数(integer)、浮動(float)、長い整数(long integer)および倍 数(double)）から構成できる。ＰＤＤ内の各パラメータはＡＤＴまたは基本デー タタイプによって定義される。 ステップ７５０ではシミュレートされたテンプレートを用いてＵＣＳＴを実現 するかどうかを決定する。プログラム言語がテンプレートをサポートしていない 場合、ステップ７３０にてドキュメンテーション内のオブジェクトすべてにプリ フィックスを加えることにより、シミュレートされたテンプレートを実行する。 そうでない場合、ドキュメンテーション内のオブジェクトすべてに対し言語テン プレートを作成する。Ｃ＋＋によって提供されるようなテンプレートを使ってい ずれのデータタイプの定義にも従属しないパラメータを有する包括的メンバー機 能を作成できる。Ｃ＋＋コンパイラーはＡＤＴの固有の組み合わせのそれぞれを 実行するコンピュータコード（非包括的メンバー機能）を発生するのにこのよう な包括的メンバー機能（テンプレート）を使用する。換言すれば、Ｃ＋＋コンパ イラーはＡＤＴの固有の組み合わせのそれぞれに対し個々のメンバー機能を作成 するのに関連する作業を実行する。 ステップ７３０ではドキュメンテーション内のすべてのオブジェクトの名前に テンプレートのプリフィックスが加えられる（すなわちテンプレートは使用され ていなかった）。このことはパラメータにプリフィックスを加えたプロセスと同 様である。オブジェクトは包括的か、ＢＳＨに従属か、ＨＷに従属か、またはＢ ＳＨとＨＷに従属かのいずれかに分類される。各オブジェクトのカテゴリーを表 示する各オブジェクトの名前にプリフィックスが加えられる。ステップ７３２に てＵＣＳＴのためのテストケースが定義される。設計に従ってオブジェクトが機 能していることを証明するためにＵＣＳＴ内の各々のオブジェクトに対しテスト ケースが定義される。 ステップ７３６にてＵＣＳＴを含むコンピュータコードが作成される。ＵＣＳ Ｔを実行するすべてのオブジェクトが（テンプレートプリフィックスおよびＣＡ ＤＴＤテンプレートプリフィックス）を含むドキュメンテーションに従って作成 される。本発明の好ましい実施例ではオブジェクトはＣ＋＋のクラスとして実現 されるが、当業者であれば任意のオブジェクト指向のコンピュータプログラム構 造を使用できることは明らかであろう。更にステップ７３６にてＵＣＳＴをテス トするのに必要とされるコンピュータコードが作成される。ステップ７３８にて ＵＣＳＴのテストが実行される。先に定義されたテストケースの各々に従いＵＣ ＳＴがテストされる。 第６図は第４図におけるステップ６０８におけるＣＳを作成するステップをよ り詳細に示すフローチャートである。ステップ８０４においてＣＳを作動すべき 交換機のためのＢＳＨとＨＷとの組み合わせを決定することにより、ＣＳの作成 を開始する。ＵＣＳＴからＣＳを実現するためのコンピュータコードがコピーさ れ、ステップ８０６においてＣＡＤＴＤの関連するサブセットもコピーされる。 関連するサブセットは包括的、ＢＳＨ従属性、ＨＷ従属性の関連するＡＤＴのす べておよびＢＳＨとＨＷとの組み合わせに対し特定のＡＤＴを含む。ステップ８ ０８において、コピーされたコード内のテンプレートプリフィックスがＢＳＨと ＨＷとの組み合わせのためのプリフィックスと置換される。コピーされたコード 内でのプリフィックスの置換が完了するとステップ８１０にてコピーされたコー ドがセーブ（記憶）される。ステップ８１２にてコピーされたコードは通信用交 換機で実行可能なフォーマットにコンパイルされる。 ＵＣＳＴ上で実行されるメンテナンスはこれより作成されるＣＳ内に直接反映 される。例えばＵＣＳＴ上でエラーが訂正されるか、または更新が行われると、 その後、ＵＣＳＴから作成されるすべてのＣＳにおいて更新または訂正が自動的 に表示される。 第７図は、本発明の要旨に従いＵＣＳＴおよびＣＡＤＴＤから作成された共通 機能ソフトウェアユニットＣＳ１Ａ ４０８およびＣＳ２Ａ ４１０を含む通信 用交換機４０６を示すブロック図である。通信用交換機４０６は共通機能ソフト ウェアユニットＣＳ１Ａ ４０８およびＣＳ２Ａ ４１０、特定ソフトウェアユ ニットＳＰＳ- １- ２- ＡおよびタイプＡ ４１４（ＳＨ- Ａ）のハードウェア から成る。交換機４０６はタイプ１（ＢＳＨ１）および２（ＢＳＨ２）のベアラ ーサービスハンドラーをサポートする。ＣＳ１Ａ ４０８はＢＳＨ１およびタイ プＡのハードウェアに従属し、ＣＳ２Ａ ４１０はＢＳＨ２およびタイプＡのハ ードウェアに従属する。特定ソフトウェアユニットＳＰＳ- １- ２- Ａ ４１２ はＢＳＨ１、ＢＳＨ２およびタイプＡのハードウェアに従属する。 従って、上記説明から本発明の作動および構造が明らかになったと考える。図 示され、説明された方法は、好ましいことを特徴とするが、添付した請求の範囲 に記載の発明の精神および範囲から逸脱することなく、種々の変更および変形が 可能であることは明らかである。

Claims (1)

1. 【特許請求の範囲】 １．複数の通信用交換機の各１つが特定タイプのハードウェアを有し、特定の ベアラーサービスハンドラーをサポートするようになっており、該複数の通信用 交換機のうちの指定された１つのための共通機能ソフトウェアユニットを作成す る方法であって、 複数の共通機能ソフトウェアユニットを含み、該複数の共通機能ソフトウェア ユニットの各１つが複数のテンプレートプリフィックスおよび少なくとも１つの パラメータを有するようになっているユニバーサル共通ソフトウェアテンプレー トを作成する工程と、 前記パラメータの各１つのためのデータタイプの定義を含む、アブストラクト データタイプ定義群を作成する工程と、 前記ユニバーサルな共通ソフトウェアテンプレートから前記複数の共通機能ソ フトウェアユニットのうちの１つにして前記特定のベアラーサービスハンドラー および前記指定された通信用交換機の前記特定のタイプのハードウェアとコンパ チブルである１つの共通機能ソフトウェアユニットをコピーする工程と、 前記コピーされた共通機能ソフトウェアユニット内の複数のテンプレートプリ フィックスを前記指定された通信用交換機の特定のベアラーサービスハンドラー および前記特定タイプのハードウェアを識別する選択されたプリフィックスに置 換する工程とを備えた、共通機能ソフトウェアユニットを作成する方法。 ２．前記パラメータの各１つのための少なくとも１つの定義を含むパラメータ 定義ドキュメントを作成する工程を更に含む、請求項１記載の方法。 ３．ユニバーサル共通ソフトウェアテンプレートを作成する前記工程が、 各１つが前記複数のベアラーサービスハンドラーのうちの１つおよび前記複数の タイプのハードウェアのうちの１つを含む複数の組み合わせを識別する工程と、 前記複数の組み合わせのうちの各１つに存在する複数の共通機能を識別する工 程と、 前記複数の共通機能のうちの各１つを実行するように複数のクラスを作成する 工程とを含む、請求項１記載の方法。 ４．複数のクラスを作成する前記工程が、 前記複数のクラスのうちの各１つにテンプレートプリフィックスを付ける工程 を含む、請求項３記載の方法。 ５．アブストラクトデータタイプ定義群を作成する前記工程が、前記複数のベ アラーサービスハンドラーおよび前記複数のタイプのハードウェアから独立した テンプレートプリフィックスを前記データタイプの定義の各１つに付ける工程を 含む、請求項４記載の方法。 ６．アブストラクトデータタイプ定義群を作成する前記工程が、前記複数のベ アラーサービスハンドラーのうちの１つに従属し、前記複数のタイプのハードウ ェアから独立した第１従属テンプレートプリフィックスを前記データタイプの定 義の各１つに付ける工程を含む、請求項５記載の方法。 ７．アブストラクトデータタイプ定義群を作成する前記工程が、前記複数のタ イプのハードウェアのうちの１つに従属し、前記複数のベアラーサービスハンド ラーから独立した第２従属テンプレートプリフィックスを前記データタイプの定 義の各１つに付ける工程を含む、請求項６記載の方法。 ８．アブストラクトデータタイプ定義群を作成する前記工程が、前記複数の組 み合わせのうちの１つに従属する第３従属テンプレートプリフィックスを前記デ ータタイプの定義の各１つに付ける工程を含む、請求項７記載の方法。 ９．前記コピーされた共通機能ソフトウェアユニットにおける複数のテンプレ ートプリフィックスを置換する前記工程が、 前記第１の従属テンプレートプリフィックスのうちの各１つを前記指定された 交換機の前記特定のベアラーサービスハンドラーを識別する第Ｉの選択されたプ リフィックスに置換する工程を含む、請求項６記載の方法。 10．前記コピーされた共通機能ソフトウェアユニットにおける複数のテンプレ ートプリフィックスを置換する前記工程が、 前記第２の従属テンプレートプリフィックスのうちの各１つを前記指定された 交換機の前記特定タイプのハードウェアを識別する第２の選択されたプリフィッ クスに置換する工程を含む、請求項７記載の方法。 11．前記コピーされた共通機能ソフトウェアユニットにおける複数のテンプレ ートプリフィックスを置換する前記工程が、 前記第３の従属テンプレートプリフィックスのうちの各１つを前記指定された 交換機の前記特定タイプのハードウェアおよび前記特定のベアラーサービスハン ドラーを識別する第３の選択されたプリフィックスに置換する工程を含む、請求 項８記載の方法。 12．各１つが特定タイプのハードウェアを有し、特定のベアラーサービスハン ドラーをサポートする複数の通信用交換機のためのユニバーサル共通ソフトウェ アテンプレートを作成する方法であって、 各１つが前記複数のベアラーサービスハンドラーのうちの１つおよび前記複数 のタイプのハードウェアのうちの１つを含む複数の組み合わせを識別する工程と 、 前記複数の組み合わせのうちの各１つに存在する複数の共通機能を識別する工 程と、 前記複数の共通機能のうちの各１つを実行するように複数のクラスを作成する 工程とを含む、ユニバーサル共通ソフトウェアテンプレートを作成する方法。 13．複数のクラスを作成する前記工程が、 前記複数のクラスのうちの各１つにテンプレートプリフィックスを付ける工程 を含む、請求項１２記載の方法。 14．前記複数のクラスのうちの各１つが少なくとも１つのパラメータを含む、 請求項１３記載の方法。 15．複数のクラスを作成する前記工程が、 前記パラメータの各１つのためのデータタイプの定義を含むアブストラクトデ ータタイプ定義群を作成する工程を含む、請求項１４記載の方法。 16．アブストラクトデータタイプ定義群を作成する前記工程が、 前記複数のベアラーサービスハンドラーおよび前記複数のタイプのハードウェ アから独立する、独立テンプレートプリフィックスを前記データタイプの定義の 各１つに付ける工程を含む、請求項１５記載の方法。 17．アブストラクトデータタイプ定義群を作成する前記工程が、 前記複数のベアラーサービスハンドラーのうちの１つに従属し、前記複数のタ イプのハードウェアから独立した第１の従属テンプレートプリフィックスを前記 データタイプの定義のうちの各１つに付ける工程を含む、請求項１６記載の方法 。 18．アブストラクトデータタイプ定義群を作成する前記工程が、 前記複数のタイプのハードウェアのうちの１つに従属し、前記複数のベアラー サービスハンドラーから独立した、第２の従属テンプレートプリフィックスを前 記データタイプの定義の各１つに付ける工程を含む、請求項１７記載の方法。 19．アブストラクトデータタイプ定義群を作成する前記工程が、 前記複数の組み合わせのうちの１つに従属する第３の従属テンプレートプリフ ィックスを前記データタイプの定義の各１つに付ける工程を含む、請求項１８記 載の方法。