JPH11513515A - コンピュータ制御サービスを形成する方法 - Google Patents

Abstract

(57)【要約】 本発明は、アプリケーション指向のコンピュータ制御サービスを形成する方法に係る。アプリケーション指向のプログラムコードが自動的に発生され、そして上記サービスを提供するためのアプリケーション指向のコンピュータプログラムが形成される。従来より容易に変更を行うために、コンピュータプログラムは、３つのグループに分割される。第１のグループ(A)は、アプリケーションに関わりなく同一に保持されるコードのみで形成され、そして第２及び第３のグループには、上記発生により形成されたプログラムコードが与えられ、（ａ）第２のグループ(B)は、上記発生により形成されたプログラムコードのみを含み、そして（ｂ）第３のグループ(C)は、上記発生により形成されたコードであって、発生の後にデザイナーにより変更されるべきコードを含む。発生手段(11)は、発生されるべきコードが第２のグループに対するものか又は第３のグループに対するものかが通知される。

Description

【発明の詳細な説明】 コンピュータ制御サービスを形成する方法発明の分野 本発明は、一般に、ネットワークマネージメントシステムと同様のシステムで あって、エンドユーザがこのシステムを使用し、例えば、ネットワーク内の装置 を制御するようなサービスを伴うソフトウェアで構成されたシステムに係る。よ り詳細には、本発明は、このようなシステムのユーザに対するアプリケーション 指向のコンピュータ制御サービスを形成するための請求項１の前文に記載の方法 に係る。又、本発明は、アプリケーション指向のコンピュータ制御サービスを形 成するための請求項８に記載のシステムにも係る。先行技術の説明 コードを発生するよう意図された多数のシステムが市場に存在する。このよう なジェネレータは、一般に、プログラミングの始めに使用されるもので、完成し たアプリケーションの重要な変更を迅速に且つミステークなしに行うように使用 できない。換言すれば、既知のジェネレータは、繰り返しの変更及び追加を充分 にサポートしない。 又、多数のアプリケーションは、できるだけ迅速に且つ正しく変更を行うこと ができねばならない。このようなアプリケーションは、例えば、マネージされる べきネットワークが異なる形式の多数の装置を備え、そしてオペレータが多数の 異なる製造者から装置を取得するときにネットワークが連続的に変化して既存の 装置及びそのソフトウェアの更新を実行するようなネットワークマネージメント システムである。特に、テレコミュニケーションの分野における新たな自由競争 に伴い、ユーザに新たなサービスを連続的に提供する必要が生じ、柔軟に変更で きるという重要性を更に増加させる。 既知のシステムは、上記の形式のアプリケーションに非常に適しているのでは ない。これは、例えば、システムがデザイナーに多量の詳細な、ひいれは、二次 的な情報を与え、そこから本質的な部分（変更が向けられる）を見出すことが困 難なためである。又、デザイナーは、この情報をコントロール（理解）すること ができねばならない。それ故、変更を行う者は、プログラミングの分野の専門家 でなければならない。 又、このようなシステムにおいては、デザイナーが、変更すべきでないソフト ウェアの部分を変更する危険性も存在する。発明の要旨 本発明の目的は、アプリケーション指向のサービスを形成するための新たな形 式の構成体を提供することにより上記欠点を解消することである。この目的は、 請求項１の特徴部分に記載する本発明の方法により達成される。 本発明の考え方は、変更がデザイナーにとってできるだけ簡単且つ明瞭である 環境を形成することである。これは、発生されるべきコードを、（ａ）デザイナ ーが変更中に無視できる（従ってそれが見えない）部分（デフォールト機能を含 む）と、（ｂ）デザイナーに見えそして変更の各状況においてデザイナーが変更 を行う必要のある部分とに別々に配置することにより可能となる。この分離は、 特殊なテンプレートファイルの使用をベースとし、そしてアプリケーションの記 述ファイルの変更に対応する変更を行い、アプリケーションフレームワークを再 生し、そしてその後、デザイナーが手動で行うべき変更を必要に応じて行うこと により、変更が行われる。発生に関しては、コードジェネレータが、アプリケー ションの記述ファイルに基づいてテンプレートファイルを変更する。 本発明の構成によれば、変更は、迅速に且つできるだけ欠陥なしに行うことが できる。従って、サービスのユーザに供給されるべき製品は、欠陥なしに迅速に 形成できる。本発明により、組織に雇われた個人、例えば、ネットワークオペレ ータがこのサービスを使用することにより変更を行うこともでき、この場合には 変更ができるだけ融通性のあるものとなる。 上記の効果は、システムがデザイナーの作業の抽象レベルを増加し、即ちデザ イナーはアプリケーションの本質的な部分（変更を必要とする部分）を見るだけ でよく、そして二次的な事柄（複雑なプログラムコード）は見えないということ をベースとする。それ故、デザイナーは、変更を行わねばならない部分を容易に 探索できる。又、これは、同時に、編集すべきでない部分をデザイナーが偶発的 に変更する可能性を低減する。図面の簡単な説明 以下、添付図面を参照し、本発明の好ましい実施形態を詳細に説明する。 図１は、本発明によるシステムを示す図である。 図２は、本発明のシステムによる完成アプリケーションの発生を例示する図で ある。 図３ａは、説明のためのアプリケーションにおけるメインウインドウを示す図 である。 図３ｂは、説明のためのアプリケーションのサブウインドウを示す図である。 図４は、説明のためのアプリケーションのオブジェクトモデルの図である。 図５は、コードジェネレータに供給されるアプリケーション記述の図である。 図６は、発生されたアプリケーションフレームワークを示す図である。 図７は、アプリケーションのメインウインドウを変更形態で示す図である。 図８は、オブジェクトモデルに対して行われるべき変更を示す図である。 図９は、アプリケーションに対して行われるべき別の変更を示す図である。好ましい実施形態の詳細な説明 図１は、本発明によるネットワークマネージメントシステムを示す。ＭＶＣ＋ ＋アプリケーションアーキテクチャー（及びＣ＋＋プログラミング言語の使用） をベースとするオブジェクトベースのプログラムが一例として使用される。一般 的に述べると、この方法は、例えば、ＭＶＣ＋＋アーキテクチャーのような簡単 なアプリケーションアーキテクチャーの使用を必要とする。このアーキテクチャ ーを一例として以下に使用するので、以下の説明の理解を容易にする特徴を簡単 に説明する。 ＭＶＣ＋＋アーキテクチャーは、既知のＭＶＣ（モデル・ビュー・コントロー ル）アーキテクチャーから変更されたものであり、従って、アプリケーションは ３つの部分、モデル、ビュー及びコントロールに分割される。モデル部分は、ア プリケーションに関連した現実ワールドのエリアを記述するオブジェクトの集合 である。ビュー部分は、アンドユーザから見えるアプリケーションの最も外側の レイヤである。この部分は、モニタにおいてユーザが何をみるか決定する。ビュ ー部分は、視覚及び機能部分に分割される。視覚部分は、表示のレイアウトをマ ネージし、そして機能部分は、表示に関連した機能を制御する。ビュー部分は、 コントローラ部分によって形成され、そして各ビューオブジェクトごとに、１つ のコントローラオブジェクトがある。コントローラ部分は、モデル及びビュー部 分の協働を制御し、そしてアプリケーション指向のロジックを形成する。１つの コントローラオブジェクトは、多数のモデルオブジェクトへの関連を有し、同じ モデルオブジェクトを多数のコントローラオブジェクトに接続できる。ＭＶＣ＋ ＋アーキテクチャーに基づくアプリケーションにおいて、モデル部分及びビュー 部分のオブジェクトは、互いに直結されないが、ビューオブジェクトは、コント ローラオブジェクトを経てモデルオブジェクトのみと通信することができる。そ れ故、ビュー部分は、ユーザによりワークステーションから与えられたコマンド を解読し、そしてどの機能が問題であるかをコントローラ部分に指示する。コン トローラ部分は、各コマンドをいかに処理すべきかについての知識を含み、従っ て、コントローラ部分は、コマンドに応答して測定を実行するようにモデル部分 に要求する。モデル部分は、測定の結果をコントローラ部分に通知し、コントロ ーラ部分は、次いで、それらをユーザに示すようにビュー部分に求める。ＭＶＣ ＋＋アーキテクチャーに基づく各アプリケーションは、メインコントローラクラ ス、即ちメインコントローラを有し、これは、他のコントローラクラス、ひいて は、全アプリケーションを制御する。又、メインコントローラオブジェクトは、 メインビューオブジェクトを形成し、そしてそれを制御する。メインビューオブ ジェクトは、アプリケーションのメインウインドウを形成する。１つおきのウイ ンドウ（ダイアログ）ごとに、別々のビュー及びコントローラクラスがある。 ＭＶＣ＋＋アーキテクチャーの更に詳細な説明は、例えば、Ａ．ジャークシ著 の「Ｃ＋＋での対話型アプリケーションの実施(Implementing Interactive Appl ications in C++)」（ソフトウェア・プラクティス＆エクスペリエンス、第２５ 巻、第３号、１９９５年３月、第２７１−２８９ページ）に見られる。 本発明によるネットワークマネージメントシステムは、実際には、例えば図１ に示すようなものである。オペレーション及びメンテナンスセンターＭＳに位置 するネットワークオペレータは、例えば、イーサネットネットワークである個別 のワークステーションネットワークＷＳＮに接続されたネットワークマネージメ ントワークステーションＷＳを使用する。マネージメントシステムは、通常は、 ワークステーションネットワークの多数のコンピュータに分割され、あるコンピ ュータは、ネットワークを制御するのに必要なデータを含むデータベースＤＢを 備えている。マネージメントシステムは、例えば、規格に定義されたＱ３インタ ーフェイスを経て、例えば、ＳＤＨデバイス２１及びＰＤＨデバイス２３より成 る送信ネットワークに接続される。ＳＤＨデバイス間の制御チャンネルは、実際 には、ＳＴＭ−Ｎ（Ｎ＝１、４、１６）のヘッダバイトで形成され、従って、Ｓ ＤＨデバイス間の制御信号は、ペイロード信号と一緒に搬送される（即ち、同じ 物理的ネットワーク内で）。従って、従来のＰＤＨデバイス２３は、各製造者ご とに特有の構成を必要とし、それ故、個別の仲介デバイス２２を経てマネージメ ントシステムに接続されねばならない。 本発明によるシステムは、このシステムに使用されるアプリケーション指向の コンピュータプログラム１０（以下、アプリケーションフレームワークとも称す る）の一部分を自動的に発生するコードジェネレータ１１を備えている。このア プリケーションフレームワークは、オペレータが自分のワークステーションから ネットワークマネージメントサービスを使用するときに実行されるプログラムフ レームワークである。完成したアプリケーションは、ワークステーションネット ワークのサーバ又は個々のワークステーション（又はその両方）に記憶される。 アプリケーションの高抽象レベル記述、即ちジェネレータの第１入力グループ を形成する記述が、ジェネレータに対して形成される。この記述は、参照番号１ ２で示されている。この記述は、例えば、ジェネレータが理解するテキスト形態 に直接手書きすることができ、その後、この記述は、システムメモリにファイル として記憶することができる。又、この記述は、アプリケーションがグラフィッ ク記述として表示されるような既知のＣＡＳＥ（コンピュータ助成式のソフトウ ェアエンジニアリング）デバイスで形成することもできる。この場合に、ＣＡＳ Ｅデバイスによりファイルに記憶された記述は、特殊な変換プログラムと共に、 ジェネレータが理解する形態に変換される。 ジェネレータへの別の入力グループは、アプリケーションフレームワークの発 生に対してモデルとして作用するテンプレートファイル１３で構成される。コー ドジェネレータ１１は、デザイナーにより書き込まれた記述１２に基づいてテン プレートファイルに対してコードを再生することによりアプリケーションフレー ムワークを発生する。テンプレートファイルは、２つのグループ１３ａ及び１３ ｂに分割され、アプリケーションフレームワークのある部分が各グループに基づ いて発生される。テンプレートファイルは、アプリケーションが変更されるとき に変更する必要のない固定ファイルである。この点について、テンプレートファ イルは、コードジェネレータ１１の内部実施の一部分であると考えることもでき る。 上記の２つの入力グループから、コードジェネレータは、図１の右側に示され たアプリケーション指向のコンピュータプログラム１０（即ち、アプリケーショ ンフレームワーク）のそれ自身の部分（図１に「発生されたコード」という語で 示された）を形成する。本発明によれば、アプリケーションフレームワークは、 ３つの異なるグループ即ちレイヤＡないしＣに分割され、グループＡの特性は、 グループＢに引き継がれ、そしてグループＢの特性は、グループＣに引き継がれ る。図１において、これらの引き継ぎは、上を向いた三角形で示されている。 第１のグループＡ（最も下位のレイヤ：このレイヤは、図面では最も上に示さ れているが、デザイナーにとっては最も下のレイヤである）は、アプリケーショ ンに関わりなく同一に保持されるプログラムコードのみを含む。それ故、このグ ループは、特に形成する必要がなく、アプリケーションごとに同一に保たれる。 このグループは、アプリケーションごとに同一に保たれる機能を含む。アプリケ ーションに対してある変更を行わねばならないか、又はアプリケーションを完全 に変更すべきであっても、このグループは、常に同一に保たれる。この例では、 第１のグループは、ＭＶＣ＋＋ベースのクラス（全てのアプリケーションに対し て同一の）より成る。 第２のグループＢ（中間レイヤ）及び第３のグループ（最も上のレイヤ）は、 コードジェネレータ１１で発生されたプログラムコードが与えられる。分割は、 第２のグループに、ジェネレータにより発生されたプログラムコードのみが与え られ、次いで、第３のグループに、ジェネレータにより及びデザイナーにより手 動で発生されたコードが与えられるように実行される。それ故、発生中に、第３ のグループには、デザイナーが変更、例えば、追加しようとするコードが与えら れる。発生の後に、デザイナーは、第３のグループに対して必要な変更を行う。 それ故、第３のグループは、その最終的な形態において、２つの部分、即ちジェ ネレータにより発生されたコードのみを含む部分Ｃ１と、デザイナーにより手動 で発生されたコードを含む部分Ｃ２とに分割される。 第２のグループＢは、アプリケーション指向のデフォールト機能を含むクラス より成る。これらクラスは、ジェネレータにより以下に述べるように発生され、 そしてデザイナーは、このグループではいかなる段階においても変更を行う必要 がない。このデフォールト機能は、アプリケーション構造及びそれに接続される サービスに依存し、そしてデザイナーがアプリケーション（即ち、グループＣ） に追加した特性が保持されるように変更することができる。第２のグループは、 対応するテンプレートファイル（１３ａ）及び記述１２に基づいて発生される。 第２のグループのクラスは、システムにおいて、デザイナーにより手書きされた コードを含まないそれら自身のファイルに記憶される。これらクラスは、以下、 デフォールトクラスと称する。 第３のグループ（Ｃ）は、アプリケーションにより必要とされる付加的な機能 をデザイナーが手書きするクラスであるスケルトン（骨格）クラスより成る。プ ログラミング言語の技術的特徴により、アプリケーションフレームワークの再生 中にスケルトンクラスにも変更を行わねばならない。このため、再生されるべき コード（部分Ｃ１）は、スケルトンクラスを含むファイルにおいてコード（部分 Ｃ２）の残りから分離される。この分離は、特にこの目的のために指定されたキ ャラクタストリングを使用し、これに基づいて、ジェネレータは、変更中に再生 されるべきファイルの部分を確認する。 発生されるべきコードがデフォールトクラス（即ち、グループＢ）の一部分で あるか、又はスケルトンクラス（即ち、グループＣ）の一部分であるかに関する 情報は、テンプレートファイルによりジェネレータに与えられる。このため、テ ンプレートファイル区分１３は、特に、グループＢに対応する部分、即ちデフォ ールト機能を含むクラスのテンプレートファイル１３ａと、グループＣに対応す る部分、即ちスケルトンクラスのテンプレートファイル１３ｂとを含む。デフォ ールトクラスのテンプレートファイルは、記述ファイル１２に基づいて自動的に 実施できる機能に対するモデルである。スケルトンクラスのテンプレートファイ ル１３ｂにより発生されるフレームは、自動的に発生できないコードがデザイナ ーにより補足される。添付資料１は、デフォールト及びスケルトンのメインコン トローラクラスのテンプレートファイルを一例として使用するものである。 アプリケーションフレームワークが第１回目に形成されるときには、コードジ ェネレータは、必要なコードをグループＢ及びＣへ書き込む。最終的なアプリケ ーションに対して変更を行うべきときには、ジェネレータは、グループＢ及びＣ を再書き込みする。ジェネレータは、変更された入力データに基づいてグループ Ｂを完全に再書き込みできるが、グループＣ（スケルトンクラス）の内容は、最 初に読み取られ、デザイナーにより手動で追加された部分をジェネレータが確認 して、それをそのまま保持できるようにされねばならない。 発生されるべきコードがジェネレータのコードを含むときには、発生されるべ きコードに識別子が補足され、こにより、発生されるべきコード及び手書きされ たコードが接続される。これについては、以下で詳細に説明する。 ジェネレータは、テンプレートファイルを読み取る。ジェネレータは、テンプ レートファイルからこの目的で指定されたあるキャラクタストリングを見つける と、そのストリングを、それが発生したコード部分と置き換える。ジェネレータ は、これらコード部分をそれ自身の発生ルール及びアプリケーション記述に基づ いて形成する。発生ルールは、使用するアプリケーションアーキテクチャーに依 存するが、個々のアプリケーションとは独立したものである。（それ故、発生ル ールは、使用するパラメータ、即ちアプリケーションの記述１２に依存する結果 を与えるある種の機能を形成する。） 上記から明らかなように、発生されるべきアプリケーションフレームワークは 次の特徴を有する。 １．手書きされたコード及び自動的に発生されたコードは、アプリケーション をデフォールトクラス及びスケルトンクラスに分割することにより互いに分離さ れる。 ２．手書きされたコード及び発生されるべきコードは、この目的のために指定 されたキャラクタストリングによりスケルトンクラス内で分離される。 ３．手書きされたコード及び発生されるべきコードは、発生されるべきコード が直接手書きされたコードを含むときに特殊な識別子と組み合わされる。 図２は、本発明の方法による完成アプリケーションの発生を例示する。デザイ ナーは、先ず、例えば、ＣＡＳＥデバイスでオブジェクトダイヤグラムを作成す る。記述は、これを手で書き込むか又は変換プログラムで書き込むことにより、 コードジェネレータ１１で理解される形態へと変換される。次いで、コードジェ ネレータは、この例ではＣ＋＋言語のファイル（コントローラクラス及び機能ビ ュークラス）と、ユーザインターフェイスツール（例えば、インペリアル・ソフ トウェア・リミテッドの商標であるＸ−Ｄｅｓｉｎｅｒ（登録商標））の形態の ファイル（視覚ビュークラス）とで構成されたアプリケーションフレームワーク １０を発生する。デザイナーは、手動コード及びユーザインターフェイスの（例 えば、上記した）ユーザインターフェイスツールによりアプリケーションの機能 を補足する。次いで、プログラムをコンパイルし、例えば、ネットワークマネー ジメントシステムで実行されるべきプログラムとしてリンクすることができ、こ のシステムにおいては、ネットワーク及びそのネットワークエレメント（物理的 デバイス）が送信ネットワークを経てワークステーションＷＳから制御される。 又、上記の開発ツールは、ネットワークマネージメントシステムの１つのワーク ステーションに配置することができ、従って、オペレータ個人は、ネットワーク マネージメントシステムに要求される変更をそれ自身で行うことができる。 以下、アプリケーションの実施は、ネットワークマネージメントに関連したベ ースステーションの無線ネットワークパラメータである仮想アプリケーションを 一例として使用することにより説明する。このアプリケーションは、ベースステ ーションの無線ネットワークに関連したパラメータを見てセットすることができ るようにする。 図３ａは、図１のネットワークマネージメントシステムＭＳにおいてコントロ ールセンターのワークステーションＷＳのディスプレイにおいて見たアプリケー ションのメインウインドウを示す。アプリケーションは、ネットワークマネージ メントシステムのメインユーザインターフェイスからスタートされ、次いで、ア プリケーションのメインウインドウがディスプレイに現れる。ベースステーショ ンの送信パワーに関連したデータをこのメインウインドウから読み取ってセット することができる。又、アプリケーションは、図３ｂに示された１つのサブウイ ンドウも含む。処理されるべきベースステーションは、このサブウインドウから 選択することができる。 デザイナーは、先ず、ＣＡＳＥデバイスで、アプリケーションを記述するオブ ジェクトモデルを描く。これにより得られたモデルは、例えば、ジェームス・ラ ンボー氏等の「オブジェクト指向のモデリング及びデザイン(Object Oriented M odering and Design)（米国、ニュージャージー州、プレンティス−ホール、１ ９９１年、第３章）に説明された通常使用されるＯＭＴ表示法を用いて図４に示 されている。（図４の左側に示されそしていかなるクラスにも接続されないフレ ーム４ａは、以下に詳細に述べる全アプリケーションに関する付加的な情報を与 えることを述べねばならない。ビュー型の定義４Ｂ及び４Ｃにより、ビュークラ スに引き継がれるユーザインターフェイス要素が選択される。） このグラフィック記述は、変換プログラムによるか又は手書きにより、コード ジェネレータが理解する形態に変換される。このようにして得られたコードが図 ５に示されている。この記述ファイルを理解するために、添付資料２は、使用す る記述言語の構文を示している。（図５は、ＯＭＴ表示法で図４に示されたもの と同様のハイアラーキ構造をかっこ表示で示している。） 次いで、アプリケーションジェネレータ１１を使用することによりアプリケー ションフレームワーク１０が発生される。図５に示すリストは、次いで、図６に 示すアプリケーションフレームワークへと発生される。図６は、上記のグループ 分割を示し、発生されたコードのうち、グループＢに属するクラス（即ちデフォ ールトクラス）は細いフレームで示され、そしてグループＣのクラス（即ちスケ ルトンクラス）は太いフレームで示されている。従って、プログラマーは、アプ リケーションフレームワークから、太いフレームで示された（ビュー、コントロ ーラ及び抽象パートナー）クラスをＣ＋＋ソースコードとして見る。デザイナー は、必要量のコードをこれらスケルトンクラスに追加することによりアプリケー ションの機能を実行する。（抽象パートナーは、オブジェクトが発呼オブジェク トから何を期待するかを記述するクラスである。抽象パートナーの概念は、本発 明の実際の考え方に関連していないので、これについては詳細に説明しない。抽 象パートナーの詳細な説明は、ＭＶＣ＋＋の上記文献に述べられている。） デザイナーは、視覚ビュークラス（破線の太いフレームで図示されたクラス） をユーザインターフェイスツール（例えばＸ−Ｄｅｓｉｇｎｅｒ（登録商標）） で編集することによりユーザインターフェイスのレイアウトを実施する。図６に 示された他のクラスは、デザイナーには見えない。（図示されそして視覚ビュー クラスに引き継がれるユーザインターフェイス要素は、記述ファイル１２に示さ れたビュー形式定義に基づいて選択される。） 図４と６を比較すると、本発明による構成体がプログラミング作業の抽象レベ ルをいかに高められるか明らかとなろう。図４の抽象レベルでの記述は、図６の （若干複雑な）クラスのハイアラーキへと変換することができる。図６のクラス の中で、デザイナーは、太いフレームで示されたクラスしか見ず、従って、デザ イナーは、高い抽象レベルで発生されたコードも見る。 発生されるべきクラスの名前付けは、以下のテーブルに示された名前付けルー ルを使用する。このテーブルにおいて、キャラクタストリング「ａｂｃ」は、記 述ファイル（図５）に与えられたアプリケーションの３文字接頭語である。 以下の項目ＡないしＥは、テンプレートファイル及び記述ファイルのデータに 基づきデフォールトメインコントローラクラス（グループＢの「abcDefaultMain Controller＿c 」クラス）の宣言の発生を一例として示す。フレームは、変更さ れるファイルの部分を示す。フレームは、１つのラインに矢印を有し、矢印より 前の部分は、変更前の状態を記述し、そして矢印より後の部分は、変更後の状態 を記述する。 Ａ．クラスの名前は、テンプレートファイルのクラス名におけるキャラクタス トリング「fft 」（添付資料１を参照）を、記述ファイルに与えられたアプリケ ーション接頭語、この場合は「abc 」、に置き換えることにより得られる。 Ｂ．デフォールトクラスに引き継がれるべきメインビュー抽象パートナークラ スの名前は、キャラクタストリング「fftMainViewAbsVP＿c 」の部分「fft 」を 「abc 」に置き換えることにより得られる。メインコントローラに引き継がれる べきサブコントローラ抽象パートナークラスの名前は、名前付けルールに基づい て形成される。それらは、抽象パートナークラスの名前がコンマとラインフィー ドキャラクタとで分離されたキャラクタストリングへと形成される。このように して得られたキャラクタストリングは、テンプレートファイルのキャラクタスト リングINHERIT ABS に取って代わる。 Ｃ．テンプレートファイルのパブリック部分の方法の宣言において、キャラク タストリング「fft 」は、「abc 」に置き換えられる。 Ｄ．テンプレートファイルの保護された部分の宣言において、キャラクタスト リング「fft 」は、「abc 」に置き換えられ、そしてMAINVIEW＿C は、名前付け ルールに基づいて形成されたメインビュー名に置き換えられる。キャラクタスト リング「SUB ＿CONT＿DECLARATIONS」は、次のように形成されたキャラクタスト リングに置き換えられる。 記述ファイルに定義された各サブコントローラに対し、次のステップが繰り返 される。 １．名前付けルールに基づくキャラクタストリングは、テンプレートファイル のsub ＿controller定義と共に与えられた名前に基づいてサブコントローラクラ スの名前として形成される。 ２．キャラクタストリングは、スペースキャラクタ及びアスタリスクが順次に 補足される。 ３．インスタンス定義によりサブコントローラに対してインスタンス名が定義 された場合には、それがキャラクタストリングに追加され、さもなくば、sub ＿ controller定義と共に与えられた名前がキャラクタストリングに追加される。 ４．キャラクタストリングは、セミコロン及びラインフィードキャラクタが補 足される。 このようにして得られたキャラクタストリングが結合される。 Ｅ．プライベート部分は、キャラクタストリング「fft 」を記述ファイル１２ に与えられた「abc 」に置き換えることにより形成される。 説明のためのアプリケーションから発生されるファイルを以下のテーブルに示 す。 テーブル及び図４に示すように、アプリケーション記述の１つのコントローラ クラスは、２つのクラス、即ちスケルトンクラス（グループＣに属する）及びデ フォールトクラス（グループＢに属する）に変換される。次いで、ビュークラス は、ビュー、デフォールト及びスケルトンクラスの機能部分に対して３つのクラ スに変換され、そしてビューの視覚部分についてはスケルトンクラスのみに変換 される（この部分は、ソースコードより高いレベルにおいてユーザインターフェ イスツールで処理することができる）。 以下、メインコントローラデフォールト及びスケルトンクラスについて例示す る。先ず、デフォールトクラスのヘッダ及び実施ファイルを示し、次に、スケル トンクラスのヘッダ及び実施ファイルを示す。ヘッダファイルは、外部に見える オブジェクトのインターフェイス、即ち別のオブジェクトがコールできる機能を 示す。次いで、実施ファイルは、機能がコールされるときに実行される実際のコ ードを含む。 デフォールトメインコントローラクラスのヘッダファイル（Ｃ＋＋言語の）「 abccontmadfmx.h 」は、次の通りである（添付資料に示すテンプレートファイル が上記のように変更されたとき）。 デフォールトメインコントローラクラスの実施ファイル「abccontmadfmx.cc」 は、次の通りである。 スケルトンメインコントローラクラスを次に説明する。スケルトンクラスのヘ ッダファイル「abccontmainmx.h 」は、次の通りである。（添付資料１に示され た対応するテンプレートファイルを参照）。 次いで、スケルトンメインコントローラクラスの実施ファイル「abccontmainm ax.cc 」は、次の通りである。 デザイナーは、充分な量のコードをスケルトンクラスに追加することにより、 アプリケーションに必要とされる機能を実施する。ユーザインターフェイスは、 例えば、上記Ｘ−Ｄｅｓｉｇｎｅｒ（登録商標）のフォーマットを有する視覚ビ ュークラスの発生された記述を用いることにより、Ｘ−Ｄｅｓｉｇｎｅｒ（登録 商標）ツールで補足される。 モデル部分のクラス、BaseStation ＿c 及びBaseStationGroup＿c （図４を参 照）は、モデル部分のクラスライブラリーにおいて既に実施されて、それ故、現 在のアプリケーションに関連して実施される必要はない。 以上の説明から明らかなように、コードジェネレータは、アプリケーションの 記述ファイルに与えられたデータに基づいて対応するテンプレートファイルを変 更することによりデフォールト及びスケルトンクラスを自動的に形成する。 アプリケーションフレームワークをいかに発生するかについて以上に詳細に述 べた。従って、この例は、アプリケーションが初めて形成される状態を説明して いる。アプリケーションフレームワークに対して変更を行わねばならない状態を 次に説明する。この例は、ネットワークマネージメントシステムを使用するオペ レータが、新たな特性、いわゆる優先順位サービスをベースステーションコント ローラに追加することを要求する状態に関連している。このオペレータのネット ワークにおいて、クライエントは、２つのクラス、即ちゴールドカードを有する クラスと、シルバーカードを有するクラスとに分割される。甚だしいトラフィッ クの間に全てのチャンネルが使用されそしてゴールドカードをもつユーザがコー ルを発する場合には、シルバーカードのユーザの１人がチャンネルから除去され る。このサービスは、優先順位サービスが使用されるかどうかを指示する新たな パラメータを要求する。 図７は、ユーザインターフェイスに必要とされる変更を示す。図３ａ及び７に 示されたように、ウインドウには、２つの値（イエス又はノー）をもつ新たなパ ラメータ「優先順位モード」が与えられる。 図８は、図４に既に示されたオブジェクトダイヤグラムに必要とされる変更を 示す。図８は、変更されたダイヤグラムの部分のみを示す。従って、ダイヤグラ ムには、新たなクラス「BaseStationController ＿c 」が与えられ、その属性は 「priorityMode」であり、そしてその方法は「setPriorityMode 」である。 又、この点については、ベースステーションにおける無線ネットワークパラメ ータの更新に長時間を要することにも注意されたい。それ故、アプリケーション には、オペレーションが依然として進行中であることをユーザに指示するいわゆ るワーキングダイヤログを与えなければならない。図９は、ワーキングダイヤロ グウインドウを示す。 優先順位サービスの追加について先ず説明する。この変更（変更に関わる方法 「ShowParametersFM」及び「AbcUpdateButtonActivated」への新たなパラメータ の追加）を実施するために、アプリケーションの記述ファイル１２における方法 の宣言に新たなboolean ＿t パラメータ「priorityMode」が追加される。以下の フレームは、上記した記述ファイルの一部分を示す。このフレームは、優先順位 サービスが追加されるときに記述ファイルに対して行われる追加をボールド活字 で示す。 識別子#abc1#及び#abc2#は、たとえ宣言が変化しても、論理的に同じ方法が依 然として使用される（即ち方法に対して書かれた実施が同じに保たれる）ことを 指示する。 必要な変更が記述ファイルになされたときには、コードジェネレータによって コードが再生される。コードジェネレータは、次いで、スケルトンメインビュー 及びメインコントローラクラスのヘッダファイルにおいて、再生されるべき部分 を更新する。再生されるべき部分は、キャラクタストリングAF＿TOKEN ＿END 及 びAF＿TOKEN ＿START で指示され、それ故、それらは、ファイルの他の部分を変 更せずに更新することができる（AF＿TOKEN ＿START は、再生されるべき部分の 最初のキャラクタであり、そしてAF＿TOKEN ＿END は、その終了キャラクタであ る）。 変更前に、スケルトンメインビュー及び抽象パートナークラスの共用ヘッダフ ァイルは、次の通りである。 変更後に、状態は、次のようになる（追加部分をボールド活字で示す）。 次いで、スケルトンメインコントローラクラスの上記ヘッダファイルは、変更 後に次のようになる（ファイルの一部分のみが示され、変更された部分は、ボー ルド活字である）。 上記パラメータ (boolean ＿t priorityMode)を、スケルトンメインコントロ ーラクラス及びスケルトンメインビュー抽象パートナークラスの宣言における方 法「void AbcUpdateButtonActivated() 」の宣言に自動的に追加することは、本 発明の構成体によりアプリケーションフレームワークに新たな特性がいかに容易 に追加されるかを示す。上記追加は、記述ファイルへの追加を行いそしてコード ジェネレータによりコードを再生することにより実行された。又、この点に関し てデフォールトクラスも再生されるが、この例では、デフォールトクラスに変更 は生じない（それらに関する変更が記述ファイルになされないので）ことに注意 されたい。 スケルトンメインコントローラクラスの実施ファイルにおいて変更されるべき パートナー方法は、AF＿TOKEN に後続する識別子#abc2#（記述ファイルに与えら れた）で識別される。変更は、次のように行われる。コードジェネレータは、フ ァイルを読み取り、AF＿TOKEN に後続するラインから始まって第１の“｛”符号 までのキャラクタを除去し、そしてその場所に、パートナー方法の新たな宣言を 書き込む（記述ファイルの新たな宣言に基づいて）。コードジェネレータは、次 いで、最初のAF＿TRACE キャラクタストリングを見るまでファイルの走査を続行 する。コードジェネレータは、AF＿TRACE の後のかっこ内のキャラクタを新たな パートナー方法宣言に置き換える。次いで、コードジェネレータは、キャラクタ ストリング〈PUBLIC〉FUNCTION: を見るまでファイルを後方に走査する。コード ジェネレータは、次のラインフィードキャラクタまで〈PUBLIC〉FUNCTION: に続 くキャラクタを除去し、そしてそれらの場所に新たなパートナー方法宣言を書き 込む（注：以下に示すコード例において、抽象パートナー方法の宣言が次のライ ンに続くとしても、方法宣言の終りにはラインフィードキャラクタのみが現れる ）。 方法宣言の上記変更（即ち、宣言へのパラメータの追加）は、コードジェネレ ータにより発生されたコードと、プログラマにより書き込まれたコードとの間に いかに接続が維持されるかの例である。この例では、キャラクタストリング「ab c2」は、方法 (UpdateButtonActivated)に対応する識別子であり、これにより、 接続が維持される。プログラマは、ベースステーションコントローラへのパラメ ータを更新するために、この方法に対して発生されたフレームにコードを手で既 に書き込んでいる。 方法「ShowParametersFM()」は、メインビュークラスの実施ファイル「abcvie wmainmx.cc」において、メインコントローラの実施ファイルの上記抽象パートナ ー方法と同様に変更される。この方法に対応する識別子は、アプリケーションの 記述ファイルが示すように、「abc1」である。記述ファイルに与えられるこれら の識別子により、記述ファイルに対して変更がなされた後、及び各変更がスケル トンクラスの一部分に対応するところのスケルトンクラスが再生された後であっ ても、それが分かる。 以上、アプリケーションへの優先順位サービスの追加について説明した。上記 ワーキングダイヤログの追加について以下に説明する。 この変更を行うために、メインコントローラクラスのヘッダファイルをワーキ ングダイヤログ要素のヘッダファイルで補足しなければならず、ワーキングダイ ヤログの抽象パートナークラスをメインコントローラへ引き継がねばならず、ワ ーキングダイヤログの抽象パートナー方法を宣言せねばならず、そして変数をワ ーキングダイヤログオブジェクトのポインタとして宣言せねばならない。ポイン タは、メインコントローラクラスの実施ファイルにおいてワーキングダイヤログ に初期化されねばならず、新たなワーキングダイヤログオブジェクトインスタン スを形成しなければならず、ワーキングダイヤログオブジェクトダイヤログを削 除しなければならず、そしてワーキングダイヤログの抽象パートナー方法を実施 しなければならない。 変更は、実際には、次のライン をアプリケーションの記述ファイル（図１の参照番号１２）のメインコントロー ラの定義部分に書き込み、そしてアプリケーションフレームワークを再生するこ とにより行われる。記述ファイルへ行われる変更により再生に生じる変更を以下 に示す。 コードジェネレータは、デフォールトクラスのヘッダファイル「abccontmadfm x.h 」を再生し、このヘッダファイルにはワーキングダイヤログ要素のヘッダフ ァイルが追加されており、ワーキングダイヤログの抽象パートナークラスが引き 継がれており、そしてワーキングダイヤログオブジェクトへのリンクがクラスの 保護された部分に追加されている（これらの変更は、ボールド活字で示す）。 又、コードジェネレータは、デフォールトクラスの実施ファイル「abccontmad fmx.cc」を次のように再生する。 １．ワーキングダイヤログポインタが初期化される。 ２．ワーキングダイヤログが削除される。 ３．新たなワーキングダイヤログオブジェクトインスタンスが生成される。 抽象パートナー宣言は、スケルトンメインコントローラクラスのヘッダファイ ル「abccontmainmx.h 」において再生され、ワーキングダイヤログの抽象パート ナー方法がそこに含まれる。 コードジェネレータは、再生されるべき部分をAF＿TOKEN ＿START 及びAF＿TO KEN ＿END により識別し、それ故、ファイルの一部分を変更して、コードの残り 部分が同一に保たれるようにする。 フレームは、抽象パートナー方法の実施に対しスケルトンメインコントローラ クラスの実施ファイル「abccontmainmx.cc」において発生される。 抽象パートナー方法のこのフレームにおいて、デザイナーは、ワーキングダイ ヤログのキャンセルボタンの押圧に続くべき機能を実施する。 デザイナーは、例えば、時間のかかるオペレーションを開始するコードの部分 の前に要求workingDialog → ShowLongDelay(MESSAGE＿TEXT) を書き込むことに よりワーキングダイヤログをアクチベートする（ディスプレイに示す）。 上記例（ワーキングダイヤログの追加）は、アプリケーションフレームワーク に新たな特性をいかに容易に追加するかを示す。変更は、記述ファイルに１ライ ンを追加し、そして変更された記述ラインに基づいてアプリケーションフレーム ワークを再生することにより実施された。又、アプリケーションの抽象レベルも 高く保持される。というのは、ワーキングダイヤログサービスからデザイナーに 見えるアプリケーション部分に方法「KuiCancelWanted() 」及び「ShowLongDela y() 」しか示されないからである。アプリケーションにワーキングダイアログオ ブジェクトを追加するための更に複雑なコードは、デザイナーに見えないデフォ ールトクラスに対して（自動的に）発生される。 添付図面の例を参照して本発明を以上に説明したが、本発明は、これに限定さ れるものではなく、上記した本発明の考え方の範囲内及び請求の範囲内で変更が なされ得ることが明らかである。オブジェクトベースのアプリケーションについ て上記したが、原理的には他の形式の構成においても同様の構成を使用できる。 同様に、この方法は、ネットワークマネージメントシステム以外のシステムにお いてサービスを形成するのにも使用できるが、ネットワークマネージメントシス テムは、最初に述べた理由で、効果的な実施環境を構成する。本発明による手段 は、サービスを提供するシステムの一部分を形成することができ、又はこの方法 は、システムとは個別に実施でき、そして完成したアプリケーションをその後に システムへ転送することができる。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，Ｓ Ｚ，ＵＧ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ， ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，Ｇ Ｅ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ， ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，Ｐ Ｌ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ， ＶＮ (72)発明者 ネルヴェーネン ピア フィンランド エフイーエン−33960 ピ ルッカラ メシンマルヤクーヤ ４

Claims (1)

1. 【特許請求の範囲】 １．ユーザのためのアプリケーション指向のコンピュータ制御サービスを形成 する方法であって、サービスを意図するアプリケーションが、使用されるアプリ ケーションアーキテクチャーに関して記述された記述ファイルを形成し；ソフト ウェア発生手段(11)を使用しそして上記使用されるアプリケーションアーキテク チャーのルールに従うことによりアプリケーション指向のコンピュータプログラ ムを形成するところのアプリケーション指向のプログラムコードを自動的に発生 し；そして上記コンピュータプログラムを実行してユーザに上記サービスを提供 するという段階を含む方法において、上記コンピュータプログラムは、異なるグ ループに分割され、 第１のグループ(A)は、アプリケーションに関わりなく同一に保持されるプロ グラムコードのみで形成され、 第２及び第３のグループには、上記発生により形成されたプログラムコードが 与えられ、（ａ）第２のグループ(B)は、上記発生により形成されたプログラム コードのみを含み、そして（ｂ）第３のグループ(C)は、上記発生により形成さ れたコードであって、デザイナーが発生の後に変更することを意図したコードを 含み、そして 上記発生手段(11)は、発生されるべきコードが第２のグループに対するものか 又は第３のグループに対するものかが通知されることを特徴とする方法。 ２．上記アプリケーションは、オブジェクトベースのものであり、上記第１グ ループの特性は、第２グループへ引き継がれ、そして第２グループの特性は、第 ３グループへ引き継がれる請求項１に記載の方法。 ３．第３グループ内で、デザイナーにより変更されるべき部分は、その目的の ために指定されたキャラクタストリングでそのグループの残り部分から分離され る請求項１に記載の方法。 ４．記述においてデザイナーにより行われる変更を追加すべきところのコード が上記発生により補足される情報には個々の識別子が与えられる請求項１に記載 の方法。 ５．上記発生手段に与えられる入力データは２つの部分に分割され、その一方 は、上記第２グループに対応し、そしてその他方は、上記第３グループに対応す る請求項２に記載の方法。 ６．上記部分は、テンプレートファイルより成り、そして上記発生は、アプリ ケーション記述に基づいてテンプレートファイルを補足することにより実行され る請求項５に記載の方法。 ７．上記方法は、ネットワークマネージメントシステムのユーザがテレコミュ ニケーションネットワークを制御するところのネットワークマネージメントサー ビスを発生する請求項１に記載の方法。 ８．アプリケーション指向のコンピュータ制御サービスを発生するシステムで あって、サービスを意図するアプリケーションに関してメモリに記憶された記述 を備え、この記述は、使用されるアプリケーションアーキテクチャーに関してな されたものであり、更に、使用されるアプリケーションアーキテクチャーのルー ルに基づいてアプリケーション指向のプログラムコードを発生するためのソフト ウェア発生手段(11)を備えたシステムにおいて、上記発生手段は、発生されたコ ードを２つの異なるグループに分離するための分離手段(12,13)に作動的に接続 され、一方のグループ(B)は、上記発生により形成されたプログラムコードのみ を含み、そして（ｂ）他方のグループ(C)は、上記発生により形成されたコード であって、発生の後にデザイナーにより変更されるべきコードを含むことを特徴 とするシステム。 ９．上記分離手段は、各グループごとに上記記述及び個別のテンプレートファ イル(13a,13b)を含む請求項８に記載のシステム。 １０．ネットワークマネージメントシステムの一部分であって、このシステム を使用して、ネットワークマネージメントサービスを形成し、これにより、ネッ トワークマネージメントシステムのユーザがテレコミュニケーションネットワー クを制御するようにした請求項８に記載のシステム。