JPH08507397A - パケット交換ネットワークサイジングのための方法およびシステム - Google Patents

Abstract

(57)【要約】 本発明は、通信ネットワークのようなエンティティのサイジングのための方法とシステムである。実施例では、このシステムは、パケット交換ネットワークのためのpCべースデータ方式対話型計算ツール（図1）である。この方法は、入力スクリーンテキストファイル（図2）、計算処理テキストファイル（図5）、および報告書フォーマットテキストファイル（図7）を定義するステップを含み、それぞれはユーザが変更可能である。また、この方法は、入力スクリーンファイルに含まれるネットワーク必要条件に関連する事前定義された入力問合わせに応えてユーザがネットワークサイジングデータをコンピュータに入力するステップ（図2）、および処理計算ファイルに従って、ネットワークのサイズを判断できるよう入力したネットワークサイジングを用いてネットワーク構成要素数の計算することも含む（図5）。またこの方法は、報告書フオーマットファイルに従ってネットワーク構成要素数のネットワークサイジング報告書（図7）を生成すること、およびそのネットワークサイジング報告書をもとにネットワークを構成することを含む。

Description

【発明の詳細な説明】 発明の名称 パケット交換ネットワークサイジングのための方法およびシステ ム 発明の分野 本発明は概して通信ネットワーク関する。さらに詳しくは、パケット交換型通 信ネットワークのサイジングのための方法とシステムに関する。 発明の背景 ビジネスや科学分野における多くの用途で最も頻繁に行なわれるタスクとして 「サイジング」がある。コンピュータのハードウェア業界では、新しいハードウ ェアを設置するたびに、CPU必要条件、必要周辺機器やワークステーションなど の設置を分析する必要がある。必要なメモリ、およびプログラムとデータベース に必要な記憶場所の量を判断するため、コンピュータソフトウェアのアプリケー ションが検査される。 通信業界、つまりデータ交換業界では、特定のネットワークを構成するために 必要なCPUノード数、インターフェースプロセッサ、およびアクセス集信装置な どの情報を判断する必要性がよく出てくる。一般的にサイジングプロセスは、ま ず必要なエンティティの必要条件、つまり仕様を得ることから始まる。例えば、 通信、つまりデータ交換ネットワークの場合では、一股的に仕様は、トラフィッ ク特性、反応時間期待値、およびサポートすべきプロセスなど、属性とパラメー タのリストからなる。多くの場合、サイジング機能を実施するために必要な情報 は、エンティティのエンドユーザには直感的に分かりにくいため、エンドユーザ が必要とする事前インストールのサポートの量を増加することが必要がある。 これらの重要な必要条件、つまり仕様を得た後、一連の意思決定および計算ア ルゴリズムにおいてその値を使用し、エンティティ構成要素（CPUノード、イン ターフェースプロセッサ、およびアクセス集信装置）の実際の数を引き出す。こ れらの意思決定および計算アルゴリズムは、エンドユーザにはあまり知られてお らず、製造企業が提供しなければならない。各エンティティインストールは、サ イトによって異なり、サイトに特定のアルゴリズムを提供するか（これは事前イ ンストールサポートのコストが増加する）、または一般的なアルゴリズムを提供 する必要がある（これはエンティティのサイジングが正確にできない可能性があ る）。 プロセスの最終ステップは、構成要素の取得・統合を担当するエンティティ技 師のためにエンティティのサイズ（エンティティ構成要素）の報告書を作成する ことである。 上述の機能を扱う既存のエンティティサイジングツールは、一般的に対話型と 言うよりは受動的な方法で利用されてきた。アルゴリズムは通常、数ページの印 刷物にしてユーザに配付された。上述したように、このようなアルゴリズムは非 常にユーザ特定または一般的であり、ユーザがそれを解釈することが困難であっ たり、さらに悪い場合には、非常に不正確なサイジング結果を作りだしてしまう 。新しいツールでは対話型機能を導入しているとはいえ、サイト特定による変化 の問題を取り扱うことにおいてはほとんど何も行なわれていない。 Lotus 1-2-3などのような計算表アプリケーションを使用してエンティティサ イジングツールを開発することが提案されてきた。これには、ユーザが適用可能 なサイジングユーティリティに対していくつかの有用な機能がある。一般的に計 算表は、エンドユーザにとってかなり修得が容易なプログラミング言語を提供す る。但し、これはプログラミング言語であるため、計算表アプリケーションのサ イジングツールに変更を行なうこと（例えばスクリーンを加えるなど）には、プ ログラミング変更および計算表での保存が要求される。また、対話型エンドユー ザセッションのセマンティクフローへの変更もプログラミング変更と計算表での 保存が要求される。最後に、計算表アプリケーションサイジングツールを実行・ 維持するため、エンドユーザは、そのツールをサポートする予定の各機器につき ソフトウェアパッケージのライセンスを受ける必要がでてくる。 またRebohらによる米国特許4,866,634に開示されたような機能エキスパートシ ェルも提案されてきた。このようなシステムは、エキスパートシステム、計算表 システム、および関係型データベースシステムのコンセプトを組み合わせ、特定 の事実一組に対する符号化された知識（因果関係、状況関係など）の応用をもと に結論を導きだす。 従って、真に汎用のエンティティサイジングツールを持つことが望まれている 。このようなサイジングツールは、実行可能なプロセスとテキストファイル一組 を有するが、関係型データベース管理システムの間接費が不要なものである。テ キストファイルを使用することにより、付随の実行可能プロセスに影響を与える ことなく、エンドユーザによるすべての必要な変更をツールに行なうことができ る。 発明の概要 故に本発明の目的は、向上した対話型データ方式のエンティティサイジングの 方法とシステムを提供することにある。 さらに本発明の目的は、対話型データ方式のエンティティサイジングの方法と システムで、「サイジング検査」を実施できるように、特定エンティティのため にユーザが複数組のサイジング属性とパラメータを維持することができるものを 提供することにある。 実施例のツールによると、3つのエンティティサイジング機能の1つを選択でき る高レベルメニュースクリーンがユーザに呈示される。ユーザはエンティティの ために属性およびパラメータの特定の一組を入力、属性およびパラメータの特定 の一組を基礎にした必要なサイジング計算を実施、または属性およびパラメータ の特定の一組を使用して実施した計算の結果報告書を作成することができる。 ユーザが入力機能を選択した場合、一連のデータ入力スクリーンが表示される 。これらのスクリーンは、「はい」や「いいえ」、またはデータ量のような具体 的なデータアイテムの入力を要求するテキスト式質問を含んでいる。シーケンス で呈示されるテキスト、および各スクリーンのフォーマットは、主にユーザ適応 可能スクリーン定義ファイルによって、そして2つ目には以前のスクリーンに入 力したユーザの応答によって決定されることが望ましい。各スクリーンデータア イテムには、スクリーン定義ファイルにおいて固有のデータアイテム番号が割り 当てられる。ユーザは、どの時点でも高レベルメニュースクリーンにエスケープ できるうえ、一連のスクリーンのどこからでも再開でき、また最初のスクリーン から開始することもできる。できれば最後のスクリーンの後は、ユーザは最初の スクリーンに戻ることが望ましい。 ユーザが計算機能を選択した場合、下記のことを実施する間、ユーザは高レベ ルメニュースクリーン上のままになる。事前定義済みユーザ適応可能計算定義フ ィルタが読み出され、処理される。これは作業中変数のリスト、および一連の意 思決定と計算のアルゴリズムを含む。これらのアルゴリズムは入力機能中に入力 されたデータアイテムを数字で参照する。作業中変数は、アルゴリズムによって 定義された計算の中間および最終結果を記憶するために使用される。処理がうま く完了したら、完了メッセージが表示される。そうでない場合は、該当のエラー メッセージが表示される。 ユーザが報告書機能を選択した場合、下記のことを実施する間、ユーザは高レ ベルメニュースクリーン上のままになる。事前定義済みユーザ適応可能報告書定 義フィルタが読み出され、処理される。これは一連のテキストストリング（リテ ラル）、キャリッジコントロール文字、および作業中変数を含む。テキストスト リングは、報告書にあるヘディングおよびキーワードをつくるために使用される 。キャリッジコントロール文字により、ユーザは入力を製表化することができる 。最後に、作業中変数は、計算機能中に作成されたものである。処理がうまく完 了すると、報告書出力はローカルプリンタに送られる。そうでない場合は、該当 のエラーメッセージが表示される。 上記の目的および他の目的および本発明の機能を達成するため、通信ネットワ ークやコンピユータと使用するためのネツトワークのサイジングの方法を提供す る。この方法は、入力スクリーンテキストファイル、計算処理テキストファイル 、および報告書フォーマットテキストファイルからなり、それぞれはユーザが変 更可能である。また、この方法は、ユーザネットワークによって、入力スクリー ンファイルに含まれるネットワーク必要条件に関する事前定義された入力問合わ せに応えてサイジングデータをコンピュータに入力すること、およびコンピュー タによって、ネットワークのサイズ決定するよう、入力されたネットワークサイ ジングデータを使用して処理計算ファイルに従いネットワーク構成要素数を計算 することを含む。また、この方法は、報告書フォーマットファイルに従ってネッ トワーク構成要素数のネットワークサイジング報告書を生成すること、およびネ ットワークサイジング報告書をもとにネットワークを構成することを含む。 また、この方法を実施するためにシステムも提供されている。 本発明には数々の利点がある。例えば、本発明は、柔軟性のあるエンティティ サイジング機能を用い、実用的ユーザプログラミングツールのある複雑なエンジ ニアリングプロセスをサポートする。 本発明の目的および他の目的、機能および利点は、通常の技術を有するもので あれば、添付の図面を参照し、本発明を実施するための下記の詳細な説明で容易 に理解できると思われる。 図面の簡単な説明 図1は、本発明に従ったパケット交換ネットワークの対話型データ方式のエン ティティ サイジングの方法を実施するためのシステムを図示したもの； 図2は、本発明に従ったパケット交換ネットワークの対話型データ方式と関連 する最初のエンティティサイジング機能の方法を図示したフローチャート； 図3は、本発明が使用する入力スクリーンモジュールの機能を表したもの。 図4a-4cは、本発明で使用する論理スクリーンタイブ、定量スクリーンタイプ 、およびプロトコル定量スクリーンタイプをそれぞれ表したもの； 図5は、本発明に従った対話型ユーザ適応可能データ方式のエンティティサイ ジングと関連する2つ目のエンティティサイジング機能の方法を図示したフロー チャート； 図6は、本発明が使用する計算モジュールの機能を表したもの； 図7は、本発明に従った対話型ユーザ適応可能データ方式のエンティティサイ ジングと関連する3つ目のエンティティサイジング機能の方法を図示したフロー チャート；および 図8は、本発明が使用する報告書モジュールの機能を表したもの。 発明の詳細な説明 図1は、本発明のパケット交換ネットワークの対話型データ方式のエンティテ ィサイジングの方法を実施するシステム10を示したものである。示されたように 、システム10は必要な計算を行なうパーソナルコンピュータ12、キーボード14や マウス16などのような入力手段（これによってユーザは情報との対話やコンピュ ータ12への情報の提供を行なう）、ディスプレイ18（これによってコンピュータ はユーザとコミュニケーションを行なう）、およびプリンタ20などのような出力 ／記憶手段を含んでいる。 コンピュータ12は、ハードディスク、またランダムアクセスメモリ（RAM）お よび読み出し専用メモリ（ROM）を含んでいることが最も望ましい。本発明は、C 言語で書かれた実行可能プログラムで、Becchwoodスクリーンジェネレータ・ソ フトウェアパッケージのような適切なソフトウェアパッケージでサポートされる ウィンドウインターフェースを伴っているものに関する。当然のことながら、適 切なウィンドウインターフェース・ソフトウェアパッケージ（例えばX-Windows など）と結合できる適当なプログラミング言語であれば、どんなものでも使用で きる。関係型データベースの代わりに、本発明では「フラットファイル」を使用 するが、これは簡単なテキストエディタで変更でき、関 係型データベース管理システムの間接費の必要なくしてエンドユーザがデータ構 造を容易に調整できるものが望ましい。本発明は、図2、図5、図7のフローチャ ートに図示されるように、エンティティサイジング機能を対話型で、さらに各ユ ーザに固有の形で実施するための方法およびシステム、またはツールを提供する ものである。実施例では、エンティティはパケット通信ネットワークであり、ツ ールは3つの基本モジュール、つまり入力モジュール、計算モジュール、報告書 モジュールを使用し、これらはエンティティサイジングを行なう機能として実施 される。図2のステップ40に示したように、ユーザはパケット交換ネットワーク のサイジングのプロセスを開始するため、3つの機能の1つを選択するよう要請さ れる。下記に詳しく説明するように、ステップ42、44、46でコンピュータはどの 機能が選択されたかを判断し、適当なモジュールを実行する。ステップ48で、ユ ーザがサイジング機能を選択する代わりに「終了」オプションを選択した場合、 エンティティサイジングは停止する。 〔入力モジュール〕 図2に示したように、ユーザが入力機能を選択した場合、コンピュータがステ ップ50で開始する入力モジュールを実行する。図3は入力モジュールの機能を表 したものである。エンティティの属性を収集するには「スクリーン・フォーム」 で行なうのが最も実際的な手段である。故に、ユーザ入力インターフェース全体 は、対話型データ方式の設計で行なわれることが望ましい。 典型的な設計では、ネットワーク必要条件に関する具体的な情報の入力を要求 する一連の入力スクリーンがエンドユーザに呈示される。あるエンティティを構 成するために必要な多量のデータを収集するには、多数の入力スクリーンが必要 になる。場合によっては、必要なスクリーン数は100以上になることもある。こ れらのスクリーンの各々にはスクリーン定義およびスクリーンハンドラコードを 作成する必要があり、各々は入力モジュールとコンパイルされなければならない 。1つのスクリーンにわずかの変更を加えると、入力モジュールを再コンパイル および／または再マップする必要が出てくる結果をまねく。サイトによってエン ティティ構造がかなり異なることがよくあるため、サイト依存型スクリーンソフ トウェアを開発しなければならず、これはツールを供給するたびに各サイトの状 態に合わせなければならないことになる。従って本発明は、柔軟性 のあるスクリーン管理手段を用いて、上述の問題を解決するものである。 〔入力スクリーンファイル〕 実施例では、3つの基本的スクリーンカテゴリーが定義され、入力データの各 組の個別スクリーンを定義する代わりに、6つの一般的スクリーンタイプを設計 するように使用される。最初のカテゴリーは、正誤応答（「はい／いいえ」など ）を必要とする論理スクリーンからなる。2つ目のカテゴリーは具体的な数値が 必要な定量スクリーン、そして3つ目のカテゴリーはプロトコルのグループのた めの具体的数値が必要なプロトコル定量スクリーンである。スクリーンタイブ1 と2はカテゴリー1と2にそれぞれ対応し、スクリーンタイプ3〜6はカテゴリー3に 対応する。スクリーンのテキスト部分は入力保護されたソフトウェアのポピュレ ートされたフィールドであるため、各スクリーンは汎用型であると考えられる。 実施例では、これらのフィールドに表示されたテキストは、ユーザ定義、ポピュ レートされた入力スクリーンファイル（ISF）から柚出される。典型的なISFファ イルは下記のとおりである： 各スクリーンタイプにより、入力値の具体的な最大数が可能になる。スクリー ンタイプ1には、最高4つの「はい／いいえ」入力値が使用できる。図4aは可能な 論理入力を含むスクリーンタイプ1のサンプルを図示したものである。スクリー ンタイプ2では最高6つまでの入力数値が使用できる。図4bは、2つの可能な入力 を含むスクリーンタイプ2のサンプルを図示したものである。スクリーンタイプ3 〜6では、最高2つのプロトコルセクションを使用でき、それぞれは6つまたは7つ の入力数値を受け入れる。図4cは2つのプロトコルセクションを含むプロトコル 定量スクリーンのサンプルを図示したもので、各セクションには4つの入力値が ある。 実施例では、固有のシーケンス番号が各入力に割り当てられる。入力モジュー ル設計において、将来には複合タイプのスクリーンを定義することのできる必要 性も考えられている。新しいスクリーンタイプが定義され（タイプ6＋n）、タイ プは新規スクリーンの各入力フィールドに割り当てられる。その入力タイプは1 から6の値を有し、これは上述したスクリーンタイプに対応する値を表す。スク リーンタイプと入力タイプは、タイプ1から6では同一である。実施例では、スク リーンタイプ、入力番号、入力タイプという各スクリーンに関連する3つの属性 がある。 各スクリーンのテキスト（つまり質問）は、以前述べ、上記に示したIFSに含 まれることが望ましい。各スクリーンは、エンドユーザに呈示する順に定義され る。1つのスクリーンは、各ファイルエントリ（つまり記録）につき定義される 。上に示したように、各エントリのフォーマットは、スクリーンタイプ、その後 にコロンがあり、入力番号を含む少なくとも1つの入力セグメント、入力タイプ 、およびコンマで分けられる入力テキストストリングが記載される。番号、タイ プ、テキストからなるすべての入力セグメントは、セミコロンで終わるが、最後 のセグメントだけは新しい行の文字で終わる。事前設定された文字の最高数（例 えば１６０など）は、各入力セグメントのテキストのために指定することができ る。 スクリーンエントリに加えで、本発明は、条件付き構迫をISPに置くことがで きる。典型的な条件付き構造は下記のようなものである： これらの条件付き構造により、エンドユーザが応答するとスクリーンが呈示さ れる。次に、ユーザはスクリーン環境を定義することができ、条件付き構造の配 置をもとに特定のサイジング行為に関するスクリーンのみが表示される。上に示 したように、条件付き構造のフォーマットは、"IF"（カラム１から開始）に続い て少なくとも1つの空白スペース、オープンブラケット（"["）、入力番号、クロ ーズブラケット（"]"）、空白スペース、スキップ引き数となる。この構造は新 しい行の文字で終了することができる。 条件付き構造は、下記の方法で解釈されることが望ましい。入力番号で識別さ れる入力への応答が肯定（タイプ1に"yes"、その他すべてにはO以外）の場合、 構造にすぐ続くスクリーンが表示される。しかしながら、入力への応答が肯定で ない場合、指定されたスクリーン数がスキップされる。スキップ引き数が除かれ た場合、1つのスクリーンのデフォルトスキップが行なわれる。この設計により 、スクリーンエントリおよび条件付き構造の間に空白行を入れ、読みやすくする ことができる。 〔入力処理〕 図2と図3を再び参照する。ステップ50で、コンピュータは、ハードディスクに 記憶されているエンティティデータファイルが存在するかどうかを判断する。一 般的に、エンティティデータファイルは、エンティティサイジングツールの以前 の呼出しのスクリーンポピュレーションの結果を含んでいる。実施例では、エン ティティデータファイルは、聞く質問、およびユーザが与える答えも含んでいる 。エンティティデータファイルが存在する場合は、ステップ52で、コンピュータ はエンティティファイルの内容をステップ52aでのRAMメモリにロードする。図3 に示したように、これはステップ52bでのスクリーンコントロールテーブルと関 連データ構造の割当て、およびステップ56cでの各入力の集合体データの割当て を含んでいる。 スクリーンコントロールテーブルは、入力スクリーンをユーザに呈示する順の 決定し た情報を含んでいる。スクリーンコントロールテーブルは、ユーザが定義し、IS F自体から作成される。さらに具体的に述べるなら、スクリーンコントロールテ ーブルは、ISFの条件付き構造から作成されると言える。データ構造は「集合体 」と呼ばれ、3つの入力カテゴリー（論理、定量、プロトコル定量）の各々の要 素を含んでいる。またデータ構造は関連する入力番号、入力タイプ、および入力 テキストストリングを含んでいる。 エンティティファイルが存在しない場合、ステップ54とステップ56で、コンピ ュータはエンティティファイルを作成し、ユーザが定義したISFにロードする。 エンティティファイルは、指定されたエンティティのために作成され、入力スク リーンファイルに含まれる情報は、入力モジュールの最初の呼び出し中にデータ 構造にロードされることを理解されたい。図3で最もよく分かるように、ISFのロ ードにはいくつかのステップがある。まず最初に、ステップ56aでISFにおける情 報に一連の編集および妥当性検査が行なわれる。これにはステップ56bと56cのそ れぞれで、入力スクリーンレコードの構造解析および適切な構文のチェックが含 まれる。問題がある場合は、ステップ56dで該当のメッセージがユーザに表示さ れる。また入力モジュールは、ステップ56eで各入力のための集合体データ構造 を割当て、ステップ56fでスクリーンコントロールテーブルのためのデータ構造 の一組を割り当てる。ISFの条件付き構造情報は、スクリーンコントロールテー ブルに使用するデータ構造にロードされる。 図2および図3をさらに続けて参照する。ステップ58で、コンピュータはスクリ ーンコントロールテーブルを検査し、ユーザにどの入力スクリーンを表示するか を決定する。ステツプ60で、コンピュータはスクリーンコントロールテーブルを もとにして次の入力スクリーンを表示すべきか否かを判断する。次のスクリーン を表示するべきでない場合、ステップ62で入力スクリーンはスキップされ、コン トロールはステップ58に戻る。そこでコンピュータはスクリーンコントロールテ ーブルを検査し、次の表示スクリーンを決定する。次のスクリーンが表示される べきである場合、スクリーンはステップ64でユーザに表示される。この設計によ り、エンドユーザは、標準タイプ、オーバータイプ、タブ、および消去の規格を 使用して、スクリーンをポピュレートすること（つまり、サイトに固有の相違の 問題に関する質問に答えること）ができる。 図2に示したように、ステップで、コンピュータはスクリーン入力を処理する 。図3で 最もよく分かるように、これはいくつかのステップを要する。例えば、入力処理 は、例えば「エンター」キーを押すこと（またはその他の確認行為）によって現 在のスクリーン上の入力された情報が適切な入力データ構造に置かれるようなス テップ66aでのキーボードエントリの管理を含む。また入力処理は、ステップ66b でのスクリーンエントリの編集／妥当性検査を含み、品質データを間違えなく入 力できるようにする。これはステップ66cでスクリーンエントリフィールドを構 文解析することにより、またステップ66dで構文をチェックすることによって行 なうことができる。不適切な情報が入力された場合、入力された情報は拒否され 、ステップ66cで該当のメッセージが表示される。 スクリーン入力処理が完了した後、これ以上の追加のスクリーン入力がないこ とをコンピュータに示すために、コンピュータはステップ68で、定義された「エ スケープ」機能キーのエントリまたはその他同様の確認行為を待つ。キーが押さ れない場合、コントロールフローはステップ58に戻り、そこでコンピュータは次 のスクリーンを表示する否かを決定するためスクリーンコントロールテーブルを 検査する。キーが押された場合、現在のスクリーン上の入力は適切な入力データ 構造に記憶されることが望ましく、入力データとスクリーンコントロール構造は エンティティファイルに書き込まれ、入力モジュールが存在して、図2に示した ように、コントロールフローはステップ40に戻る。 〔計算モジュール〕 図2のステップ40でユーザが計算モジュールを選択した場合、ステップ44で、 コンピュータは計算モジュールを実施するが、そのフローチャートを図5で詳し く示す。図6は計算モジュールの機能を表したものである。エンドユーザが実施 したいと考える計算の種類には限りがないように思われ、どの計算を実施すれば よいかを決定することは困難である。前述したように、エンティティの構造はサ イトによって多数のバリエーションがあることが多い。計算の多くにはある程度 の共通点があるとはいえ、多数の計算がサイト依存であることは間違いない。ま たこれは複数のサイト依存ツールを維持することが必要にもなってくる。これら の理由により、本発明は柔軟性のある計算処理設計で、上述の問題を補うもので ある。 〔処理計算ファイル〕 各計算を直接モジュールに符号化する代わりに、実施する計算はユーザが定義 し、ポ ピュレートされた処理計算ファイル（PCF）に置かれる。計算のエントリに加え て、条件付き構造はPCFに置くことができる。これらの構造により、エンドユー ザが応答すると計算が実施される。故に、エンティティ計算の環境は定義され、 PCFにおける条件付き構造の配置をもとに特定のサイジング行為に関する計算の みが実施される。条件付き構造に関するPCFの一例を下記に示す： 上記に示したように、PCFの最初の行に現れるのは、作業中変数定義レコード である。上記に示したように、定義エントリのフォーマットは、VER（カラム1） に空白スペースとイコール記号（=）が続く。イコール記号および間に入る空白 の直後には、作業中変 数名のリストがくるが、これはコンマで分けることが望ましい。各変数名は長さ が最高3文字（英数字が望ましい）で、事前定義された変数の最高数（例えば85 ）を指定することができる。変数リストはドル記号（$）で終わり、エントリは 新しい行の文字で終わる。言うまでもなく、他の区切りや記号を使用することも できる。できれば計算エントリは定義エントリに従い、1行につき1つの計算が望 ましい。 この設計はあらゆる演算（つまり加算、減算、乗算、除算、べき乗）をサポー トする。各計算のオペランドはスクリーン入力および／または上述した作業中変 数である。PCFは多数のオペレータを含む。例えば、'＆'オペレータはプロトコ ル定量エントリおよび変数のためのみに有効である。これは個別プロトコル量の 合計が実施されることを示している。'＞'オペレータはオペランドの最大を示す 。オペランドがプロトコルエントリまたは変数である場合、各隣接プロトコルで 最大動作が個別に実施される。もう一つのオペレータは'＜'だが、これはオペラ ンドの最小を選択すべきであることを示す。オペランドがプロトコルエントリま たは変数の場合、各隣接プロトコルで最大動作が個別に実施される。スクリーン 入力が計算において参照されたときの望ましいフォーマットは：空白スペース、 オープンブラケット（"["）、入力番号、クローズブラケット（"]"）、空白スペ ース（または新しい行の文字）である。各計算の結果は、オペランドおよびオペ レータの前に'variable='を置くことによって、作業中変数に割り当てることが 望ましい。 PCF条件付き構造のフォーマットは上述したISFの条件付き構造と実質上同様で ある。つまり、"IF"（カラム1）に続けて空白スペース、オープンブラケット、 入力番号、クローズブラケット、空白スペース、スキップ引き数となる。この構 造は新しい行の文字で終了することができる。 PCF条件付き構造は、下記の方法で解釈される。入力番号で識別される入力へ の応答が肯定（つまりタイプ1には"yes"、その他すべてにはO以外）の場合、構 造のすぐ後に続く計算が実施される。応答が肯定でない場合は、計算の指定され た番号はスキップされる。スキップ引き数が構造から除かれた場合、一つの計算 のデフォルトスキップが行なわれる。この設計により、スクリーンエントリと条 件付き構造の間に空白行を置くことによって、読みやすくすることができる。 〔計算処理〕 図5および図6を参照する。ステップ78で、コンピュータは処理計算ファイルの 解釈を開始する。示したように、これはステップ80でPCFの作業中変数定義レコ ードの読み出しと解釈を含む。図6でよく分かるように、この処理にはいくつか の手順を要する。作業中変数定義レコードはステップ80aでのレコードエントリ の編集／妥当性検査を含む。これはステップ80bおよび80cでそれぞれレコードを 構文解析し構文をチェックすることによって行なうことができる。エラーがある 場合、入力された情報は拒否され、ステップ89dでユーザに該当のメッセージが 表示される。 また作業中変数定義レコードの処理は、ステップ80eで定義リストにおける各 変数のための変数集合体データ構造の割当てを含む。このデータ構造は、スクリ ーンテキスト要素を含めることを除いては、ISFを参照して上述のデータ構造と 実質的に同様である。上に示したように作業中変数定義レコードはユーザが定義 し、基本的には有効な変数名のストリングで、続けて行なう計算に使用する名前 を定義する。 続けて図5および図6を参照する。ステップ82で、コンピュータは複合計算など と関連する中間計算値を記憶した一時的集合体データ構造を少なくとも一つ割り 当てる。ステップ84で、コンピュータは条件付き構造を処理することによってPC Fの解釈を継続する。図6に示したように、これはステップ84bとステップ84cのそ れぞれで構造を解析し適切な構文を構築することにより、図84aでの条件付き構 造を編集／妥当性検査することを含む。構造内容にエラーが見つかった場合、ス テップ84dで該当するメッセージが表示される。 図5に示したように、ステップ86で、コンピュータは条件付き構造をもとに次 のレコードを処理するか否かを決定する。次のレコードを処理すべきでない場合 、図5に示したようにコントロールフローはステップ84に戻る。しかしながら、 次のレコードを処理すべきの場合は、ステップ90でコンピュータはその計算レコ ードを編集／妥当性検査を行なう。上述した編集／妥当性検査と同様、これはス テップ84bで計算レコードを解析し、ステップ90bで適切な構文のためにレコード を確認し、エラーが見つかった場合、ステップ戟で該当するメッセージが表示さ れる。 続けて図5および図6を参照する。ステップ92で、コンピュータは次に計算レコ ードを処理する。ステップ92で、コンピュータは計算動作を行なう。実施例では 、各動作エン トリは、左から右に評価されて読み出され解釈される。複合計算、つまり複数の 動作からなる計算は、一時的集合体データ構造を使用して中間計算結果を記憶す ることが望ましい。各一時的構造における値は、次の最も右の動作のオペランド になる。 実施例において、単一値のオペランドおよび複数値（つまりプロトコル入力） のオペランドが動作に現れた場合、単一値の動作は各複数値に適用され、その結 果は複数値となる。しかしながら、2つの複数値オペランドが動作に現れた場合 、動作は隣接する複数値ペアを使用して行なわれ、その結果は複数値となる。さ らに、動作に2つの単一値オペランドが現れた場合、動作は単一値を使用して行 なわれ、その結果は単一値となる。この設計は補助合計オペレータも含んでいる ことに留意されたい。これは複数値オペランドの値を合計し、作業中変数に割り 当てたり追加的計算に使用することができる単一値を生成する。できれば各作業 中変数は、計算に使用する前に、それに割り当てる値を持っていることが望まし い。 いくつかの計算は複数の動作からなる。従って、ステップ96で、コンピュータ は実施される計算に複数動作が含まれるか否かを判断する。含まれる場合、ステ ップ98で、中間結果は一時的データ構造に記憶され、コントロールはステップ94 に戻ってさらに計算が行なわれる。実施する動作が残っていない場合は、ステッ プ100で、コンピュータは最終結果を適切な変数集合体データ構造に記憶する。 ステップ102で、コンピュータはPCFの解釈が完了したが否かを判断する。完了し ていない場合、コントロールフローはステップ84にスキップし、上述したように ステップ84〜102が繰り返される。 〔報告書モジュール〕 図2のステップ40でユーザが報告書モジュールを選択した場合、ステップ46で コンピュータは報告書モジュールを実行する。このフローチャートは図7に詳し く示している。図8は報告書モジュールの機能を表したものである。概して、ひ とたび入力データを得て、そのデータでネットワークサイジング計算が行なわれ ると、結果がユーザに報告される。フォーマットと報告書の判定基準をモジュー ルに符号化することは、サイト依存性のため実用的とは思えない。再び柔軟性が 生かされ、ユーザのニーズに最適な方法で計算結果をフォーマットし報告するこ とができる。上述のことを提供するための設計方法を下記に説明する。 〔報告書フォーマットファイル〕 実施例において、各報告書の製作をコントロールするために使用する情報は、 ユーザが定義しポピュレートされた報告書フォーマットファイル（RFF）に置か れる。RFFに現れる報告書フィールドの指定に2つの基本的タイプがある。それず れは、行やページをコントロールするための関連キャリッジコントロール文字（ "!"、タブ、";"など）を1つまたはそれ以上持っている。報告書ファイルエント リに加えて、条件付き構造もRFFに置かれることがある。これらの構造により、 報告書はエンドユーザの応答によって実施される。故に、報告書出力行の環境を 定義することができ、RFF内の条件付き構造の配置をもとに特定のサイジング行 為に関連するそれらの報告書行を出力する。条件付き構造を伴う典型的なRFFは 下記のとおりである： リテラルおよび作業中変数フイールドは、報告書ページのエリアに対応するRF F位置 に置かれることが望ましい。PCFに定義された作業中変数名は予約語となり、従 って、リテラルフィールド内で使用されないことが望ましい。作業中変数がリテ ラルフィールド内に現れない場合は、変数の数値は報告書が生成される時間で代 用される。リテラルフィールドおよび作業中変数は、同一の行に現れることがあ る。 条件付き構造のフォーマットは、ISFおよびPCFに関して前述した条件付き構造 と実質上同じである。従って、望ましいフォーマットは、"IF"（カラム1）に続 いて少なくとも1つの空白スペース、オープンブラケット入力番号、クローズド ブラケット、少なくとも1つの空白スペース、およびスキップ引き数である。こ の構造は新しい行の文字で終了する。条件付き構造を解釈する際、入力番号で識 別される入力に対する応答が肯定である場合（つまりタイプ１には"yes"、その 他すべてにはO以外）、構造のすぐ後に続く報告書行は出力になる。しかしなが ら、応答が肯定でない場合、報告書行の指定された番号はスキップされる。構造 からスキップ引き数が除かれた場合は、1つの報告書行のデフォルトスキップが 行なわれる。この設計により、スクリーンエントリと条件付き構造の間に空白行 を置き、読みやすくすることができる。 〔報告書処理〕 報告書処理中、コンピュータは、RFF 108および報告書出力構造の書き込みと いう2つの基本的機能を実行する。図7と図8に示したように、RFFの解釈中、コン ピュータはまず、ステップ110で報告書出力構造を割り当てる。報告書出力構造 は、報告書行およびその報告書を構成する結果を含むデータ構造である。ステッ プ112で、RFF条件付き構造が処理される。これには、ステップ112bで構造を解析 することによるステップ112aでの条件付き構造の編集／妥当性検査、および112d での適切な構文のチェックが含まれる。エラーが見つかった場合はステップ112d でユーザに該当のメッセージ表示される。 図7および図8を続けて参照する。ステップ114で、入力番号によって識別され る入力への応答をもとに、コンピュータはRFFの次の記録を処理するか否かを決 定する。上述したように、その応答が肯定でない場合は、ステップ116で、報告 書行の指定された番号はスキップされ、コントロールフローはステップ112に戻 って条件付き構造をさらに処理する。しかしながら、応答が肯定の場合（計算が 実施された場合）、コンピュータはステップ118で報告書行フォーマットを処理 する。図8に詳しく示したように、これに は計算レコードの構造解折によるステップ118aでの報告書行フォーマットの編集 ／妥当性検査、レコード構文のチェック、およびステップ118b、118c、118dの適 切なメツセージをそれぞれ発することが含まれる。図7のステップ120および122 のそれぞれで、コンピュータはキャリッジコントロール機能を処理し、プリント アウトされる情報と共に報告書出力構造をポピュレートする。 故に、報告書モジュールがRFFにおける各レコードエントリを読み出し解釈す る際、関連キャリッジコントロール機能が行なわれている間、リテラルフィール ドが報告書出力フィールドに書き込まれる。 各作業中変数では、関連キャリッジコントロール機能が行なわれている間、変 数値は報告書出力フィールドに書き込まれる。実施例では、作業中変数が単-値 を有する場合、その値が書き込まれるが、作業中変数が複数の値をもつ場合は、 各値の前に識別子（プロトコルなど）にを置いて報告書出力ファイルに書き込ま れる。タブキャリッジコントロール文字は、一般的にカラムの出力を作るために 使用される。 図7を続けて参照する。ステップ124でコンピュータは新しい報告書ページを開 始すべきか否かを決定する。一般的には、ページブレークキャリッジコントロー ル文字は、各報告書ページの最初のリテラルフィールド（ヘッダーなど）に関連 する。ページブレーク文字に出会わない場合、ステップ126で、特定ページのリ テラルフィールドがプリントされる。ステップ128で処理する追加のレコードが ある場合、コントロールフローはステップ112に戻る。 ステップ124でページブレーク文字に出会った場合、ステップ130でコンピュー タはRFFに処理する追加レコードがあるか否かを判断する。追加レコードがある 場合、コントロールフローはステップ112にスキップし、上述したようにステッ プ114から128が繰り返される。つまり、レコードが処理され、報告書出力構造が ポピュレートされる。処理するレコードが残っていない場合は、ステップ132で 、報告書処理が完了し、リテラルフィールドがプリントされる。コントロールフ ローは図2のステップ40に戻る。 最近のソフトウェアシステムは複雑であり急速に変化を続けているため、ソフ トウェアが有効でなくなったり、ユーザの手に渡った時点で調整が必要になるこ とがある。また、ユーザコミュニティの中でかなりの多様比が見られるため、サ イト依存のソフトウェ アを開発・維持することが必要なことも多い。これらに代わる方法は、ある程度 までユーザが調整可能・プログラム可能なソフトウェアを設計開発するものであ る。故に、本発明はユーザのニーズに対してカスタム化できるソフトウェアの「 一般化」バージョンを考慮する点にある。 当然のことながら、本書に呈示・説明した発明の形態は、本発明の望ましい実 施例からなり、その可能な形態のすべてを示そうとしたものではないことを理解 されたい。また使用した用語は限定するものではなく、説明するための用語であ り、開示した発明の範囲から逸脱することなくさまざまな変更が可能であること を理解されたい。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 庁内整理番号 ＦＩ Ｈ０４Ｌ 12/26 12/56 9466−5Ｋ Ｈ０４Ｌ 11/20 １０２ Ｚ

Claims (1)

1. 【特許請求の範囲】 請求項1 通信ネットワークをサイジングするコンピュータ化された方法 で、下記のものからなるもの： 入力スクリーンテキストファイル、計算処理テキストファイル、報告書フォー マットテキストファイルを定義し、各テキストファイルがユーザによって変更可 能なもので、入力スクリーンファイルがネットワーク必要条件に関連する事前定 義された入力問合わせを含むもので、計算処理テキストファイルがネットワーク のサイズを判断するための計算エントリを含むもので、報告書フォーマットテキ ストファイルがネットワークのサイズを示すための報告書ファイルエントリを含 むもの； 事前定義された入力問合わせに応えて、ネットワークサイジングデータをユー ザによってコンピュータに入力するもの； ネットワークのサイズを判断するために入力されたネットワークサイジングデ ータを使用して、処理計算ファイルによるネットワーク装置数をコンピュータで 計算するもの；および 報告書フォーマットファイルによるネットワーク装置数のネットワークサイジ ング報告書を生成するもの。 請求項2 請求項1記載の方法で、入力スクリーンファイルを定義するステ ップがスクリーンの複数の種類を定義するステップを含むもので、各スクリーン の種類が関連する入力データの種類を入力するために有用なもの。 請求項3 請求項2記載の方法で、入力スクリーンファイルを定義するステ ップが、少なくとも一つの入力スクリーン条件付き構造を定義するステップを含 むもので、条件付き構造が、入力されたネットワークサイジングデータによって 、ユーザに表示される入力スクリーンの順をけっていするもの。 請求項4 請求項3記載の方法で、入力スクリーンファイルを定義するステ ップが、入力されたネットワークサイジングデータを記憶するために少なくとも 一つのデータ構造を定義するステップを含むもの。 請求項5 請求項1記載の方法で、計算処理ファイルを定義するステップが 、入力されたネットワークサイジングデータによって、ネットワークのサイズを 判断するため の少なくとも一つの計算エントリを定義するステップを含むもの。 請求項6 請求項5記載の方法で、計算処理ファイルを定義するステップが 、少なくとも一つの計算処理条件付き構造を定義するステップを含むもので、計 算処理条件付き構造が、入力されたネットワークサイジングデータによって、い ずれの計算エントリが実施されるかを判断するもの。 請求項7 請求項6記載の方法で、計算処理ファイルを定義するステップが 、少なくとも2つのデータ構造を定義するステップで、その内の一つのデータ構 造が、最終計算結果を記憶するためであり、一方のデータ構造が複合計算に関連 する計算中間結果を記憶するためであるもの。 請求項8 請求項1記載の方法で、報告書フォーマットファイルを定義する ステップが、報告書フォーマットを定義するための少なくとも一つの報告書ファ イルエントリを定義するステップを含むもの。 請求項9 請求項8記載の方法で、報告書フォーマットファイルを定義する ステップが、少なくとも一つの報告書フォーマット条件付き構造を定義するステ ップを含むもので、報告書内容を決定する報告書フォーマット条件付き構造が、 入力されたネットワークサイジングデータによるもの。 請求項10 通信ネットワークをサイジングするコンピュータ化された方法 で、下記のものからなるもの： 入力スクリーンテキストファイル、計算処理テキストファイル、報告書フォー マットテキストファイルを定義し、入力スクリーンファイルがネットワーク必要 条件に関連する事前定義された入力問合わせを含むもので、計算処理テキストフ ァイルがネットワークのサイズを判断するための計算エントリを含むもので、報 告書フォーマットテキストファイルがネットワークのサイズを示すための報告書 ファイルエントリを含むもの； 事前定義された入力問合わせに応えて、ネットワークサイジングデータをコン ピュータに入力することをユーザに要請するもの； 入力スクリーンファイルに関連する少なくとも一つのデータ構造にある入力さ れたネットワークサイジングデータをコンピュータで捕獲するもの； ネットワークのサイズを判断するために入力されたネットワークサイジングデ ータを 使用して、処理計算ファイルによるネットワーク装置数をコンピュータで計算す るもの；および 報告書フォーマットファイルによるネットワーク装置数のネットワークサイジ ング報告書を生成するもの。 請求項11 請求項10記載の方法で、入力スクリーンファイルを定義するス テップが、さらに下記のステップからなるもの： スクリーンの複数の種類を定義するステップを含むもので、各スクリーンの種 類が関連する入力データの種類を入力するために有用なもの； 少なくとも一つの入力スクリーン条件付き構造を定義するステップを含むもの で、条件付き構造が、入力されたネットワークサイジングデータによって、ユー ザに表示される入力スクリーンの順をけっていするもの；および 入力されたネットワークサイジングデータを記憶するために少なくとも一つの データ構造を定義するステップを含むもの。 請求項12 請求項10記載の方法で、計算処理ファイルを定義するステップ が、さらに下記のステップからなるもの： 入力されたネットワークサイジングデータによって、ネットワークのサイズを 判断するための少なくとも一つの計算エントリを定義するステップを含むもの； 少なくとも一つの計算処理条件付き構造を定義するステップを含むもので、計 算処理条件付き構造が、入力されたネットワークサイジングデータによって、い ずれの計算エントリが実施されるかを判断するもの；および 少なくとも2つのデータ構造を定義するステップで、その内の一つのデータ構 造が、最終計算結果を記憶するためであり、一方のデータ構造が複合計算に関連 する計算中間結果を記憶するためであるもの。 請求項13 請求項10記載の方法で、報告書フォーマットファイルを定義す るステップが、さらに下記のステップからなるもの： 報告書フォーマットを定義するための少なくとも一つの報告書ファイルエント リを定義するステップを含むもの；および 少なくとも一つの報告書フォーマット条件付き構造を定義するステップを含む もので、 報告書内容を決定する報告書フォーマット条件付き構造が、入力されたネットワ ークサイジングデータによるもの。 請求項14 通信ネットワークをサイジングするシステムで、下記のものか らなるもの： 入力スクリーンテキストファイル、計算処理テキストファイル、報告書フォー マットテキストファイルを定義する手段で、各テキストファイルがユーザによっ て変更可能なもの； 入力スクリーンファイルに含まれるネットワーク必要条件に関連する事前定義 された入力問合わせに応えて、ユーザネットワークによってコンピュータにサイ ジングデータを入力する手段; ネットワークのサイズを判断するために入力されたネットワークサイジングデ ータを使用して、処理計算ファイルによるネットワーク装置数をコンピュータで 計算する手段;および 報告書フォーマットファイルによるネットワーク装置数のネットワークサイジ ング報告書を生成する手段で、ネットワークサイジング方法に従ってネットワー クが構成されるもの。 請求項15 請求項14記載のシステムで、入力スクリーンファイルを定義す る手段がスクリーンの複数の種類を定義する手段を含むもので、各スクリーンの 種類が関連する入力データの種類を入力するために有用なもの。 請求項16 請求項15記載のシステムで、入力スクリーンファイルを定義す る手段が、少なくとも一つの入力スクリーン条件付き構造を定義する手段を含む もので、条件付き構造が、入力されたネットワークサイジングデータによって、 ユーザに表示される入力スクリーンの順をけっていするもの。 請求項17 請求項16記載のシステムで、入力スクリーンファイルを定義す る手段が、入力されたネットワークサイジングデータを記憶するために少なくと も一つのデータ構造を定義する手段を含むもの。 請求項18 請求項14記載のシステムで、計算処理ファイルを定義する手段 が、入力されたネットワークサイジングデータによって、ネットワークのサイズ を判断するた めの少なくとも一つの計算エントリを定義する手段を含むもの。 請求項19 請求項18記載のシステムで、計算処理ファイルを定義する手段 が、少なくとも一つの計算処理条件付き構造を定義する手段を含むもので、計算 処理条件付き構造が、入力されたネットワークサイジングデータによって、いず れの計算エントリが実施されるかを判断するもの。 請求項20 請求項19記載のシステムで、計算処理ファイルを定義する手段 が、少なくとも2つのデータ構造を定義する手段で、その内の一つのデータ構造 が、最終計算結果を記憶するためであり、一方のデータ構造が複合計算に関連す る計算中間結果を記憶するためであるもの。 請求項21 請求項14記載のシステムで、報告書フォーマットファイルを定 義する手段が、報告書フォーマットを定義するための少なくとも一つの報告書フ ァイルエントリを定義する手段を含むもの。 請求項22 請求項21記載のシステムで、報告書フォーマットファイルを定 義する手段が、少なくとも一つの報告書フォーマット条件付き構造を定義する手 段を含むもので、報告書内容を決定する報告書フォーマット条件付き構造が、入 力されたネットワ−クサイジングデータによるもの。