(57)【特許請求の範囲】
【請求項１】
データベース群と、対象毎に制御および／または管理の異なるタスクモジュールである多重タスクモジュール群と、前記データベース群と前記タスクモジュール群を用いて一連の仕事を行うアプリケーションプログラム群と、これらデータベース群、多重タスクモジュール群、アプリケーションプログラム群の結合部であるプラットフォームを含むプラットフォームシステムにおいて、
前記多重タスクモジュール群の多重タスクモジュールの中から該当するタスクモジュールを検索し、該タスクモジュールへの接続を制御するタスクモジュールマネージャと、前記タスクモジュールマネージャが該当するタスクモジュールを検索する時に利用される各タスクモジュールの特性を示す情報を蓄積する専用データベースと、緊急性の高いアプリケーションプログラムを優先的にタスクモジュールへ接続切替する優先度管理制御を実行するタスクモジュールアクセッサを前記プラットフォームが有することを特徴とするプラットフォームシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、通信分野、事務分野などで使用される情報通信ネットワークの管理、運用などにおいてデータベース群やアプリケーションプログラム群、タスクモジュール群とのデータ流通や、各種複数のシステム間のデータ流通に使用されるプラットフォームに関する。
【０００２】
【従来の技術】
図９はアプリケーションプログラムＡＰ１  ，ＡＰ２  がそれぞれデータ群Ｄ１，Ｄ２を蓄積しているデータベースＤＢＡ  ，ＤＢＢ  をそれぞれ使用して一連の仕事を行うことを示しているが、同図に示すように、データベースＤＢＡ，ＤＢＢと、該データベースＤＢＡ，ＤＢＢを用いて一連の仕事を行うアプリケーションプログラムＡＰ１，ＡＰ２とはデータ転送の形式や制御に関して、そのシステム内でしか利用できない形式であった。
【０００３】
このため、データベースのデータの流通が困難であったり、データベースを変更すると、アプリケーションプログラムも変更する必要があった。すなわち、アプリケーションプログラムＡＰ１  でデータベースＤＢＡ  のデータ群Ｄ１とデータベースＤＢＢ  のデータ群Ｄ２の両方を使用して一連の仕事を行うことができず、アプリケーションプログラムまたはシステムを新規に作成する必要があった。
【０００４】
また、図１０に示すように、線路業務における特定の作業や測定を実行する装置と、これを動作させるプログラムによって構成されるタスクモジュールと呼ばれる個別システムにおいても、データ転送の形式や制御に関して、そのシステム内でしか利用できない形式であった。このため、タスクモジュールをＭ２，Ｍ３と変更すると、アプリケーションプログラムもＡＰ２，ＡＰ３と変更する必要があった。さらに、複数のタスクモジュールと複数のデータベースを使用するアプリケーションプログラムの場合の変更は非常に複雑である。
【０００５】
このような問題を解消する手段として、図１１に示すように、アプリケーションプログラムＡＰ１〜ＡＰ４とデータベースＤＢ１，ＤＢ２、アプリケーションプログラムＡＰ１〜ＡＰ４とタスクモジュールＭ１，Ｍ２をデータ転送の形式や制御に関して分離し、アプリケーションプログラムＡＰ１〜ＡＰ４やデータベースＤＢ１，ＤＢ２、タスクモジュールＭ１，Ｍ２毎に共通のインタフェ−ス機能（アプリケーションプログラムＡＰ１〜ＡＰ４に対してはＡＰインタフェーサ１、データベースＤＢ１，ＤＢ２に対してはＤＢインタフェーサ２、タスクモジュールＭ１，Ｍ２に対してはＭインタフェーサ５）を有するプラットフォームＰＦを構成することで、データの流通を図るとともに、データベースＤＢ１，ＤＢ２やタスクモジュールＭ１，Ｍ２の変更がアプリケーションプログラムＡＰ１〜ＡＰ４へ及ぼす影響を軽減することが可能である。ただし、インタフェース機能のみを有する構成では、複数のアプリケーションプログラムからの業務処理依頼に対して、緊急性の高い業務が有限なリソースであるタスクモジュールを占有したり、逆に緊急性の低い業務がタスクモジュールを占有したりする。緊急性の低い業務がタスクモジュールを占有すると、この業務に対する処理が終了するまで、緊急性の高い業務が待ち状態となり不都合が生じる。このような状態を避けるため、アクセッサ６は業務間の優先度を管理制御する。オペレータはあらかじめ業務毎に優先度を設定する。そして、優先度の低い業務がタスクモジュールを占有しているときに、優先度の高い業務が発生したら、優先度の低い業務を一時中断して、優先度の高い業務がタスクモジュールを利用できるように接続の制御を実行する。最後に、優先度の高い業務が処理を終えたら、一時中断していた優先度の低い業務を再開させる操作を実行する。このような業務別の優先度管理制御をアクセッサ６と呼ぶ優先度管理制御機能が実行する。
【０００６】
このように、プラットフォームは複数のデータベースやタスクモジュールとアプリケーションプログラムを接続するためのソフトウエアであり、例えば、電子情報通信学会誌Ｖｏｌ．  Ｅ７６−Ｂ，  Ｎｏ．４，  Ａｐｒｉｌ  １９９３，  ｐｐ．３９１−４０１のＮ．  Ｋａｓｈｉｍａ  ｅｔ．  ａｌ．“Ｏｐｔｉｃａｌ  ｃａｂｌｅ  ｎｅｔｗｏｒｋ  ｏｐｅｒａｔａｉｏｎ  ｉｎ  ｓｕｂｓｃｒｉｂｅｒ  ｌｏｏｐｓ”で議論されている。
【０００７】
加入者系オペレーションシステムのアプリケーションプログラム構築技術では、故障復旧業務のような線路業務フローを、運用するタスクモジュールを単位として、素業務と呼ぶ業務をさらに細分化した、タスクモジュールを指定するためのひとまとまりの仕事に分解する。そして、この様々な素業務の組み替えによって、図１２に示す故障復旧業務のようなアプリケーションプログラムを自由に構築できる。図１２に示す故障復旧業務は、前述した素業務に細分化される。そして、この素業務１つ１つがタスクモジュールの実行する仕事に相当する。例えば、判定やパルス試験の素業務はＡモジュールというタスクモジュールを用いて実行され、最適ルート／切替の素業務はＢモジュールというタスクモジュールによって実行される。このような素業務を自由に組み合わせることによって、図１２に示すような故障復旧業務のような業務フローが構築できる。
【０００８】
【発明が解決しようとする課題】
しかしながら図１３に示すように、例えば、試験監視モジュール（この試験監視モジュールとは、光通信分野における回線である光ファイバを数万本単位で収容し、この光ファイバの故障点を探索する破断点検出作業や、その破断点における損失測定作業を行う装置と、この装置を動作させるプログラムを具備した測定システムを表す）の場合、１台の試験監視モジュールＭ１１，Ｍ１２，Ｍ１３内に収容可能な心線の数が数万本に限られるため、大規模加入者地域ではこのような試験監視モジュールが数台必要となる。同様に、加入者系における他のタスクモジュールや今後構築されるタスクモジュールについても、１つのタスクモジュールに収容可能な心線の数には限界があるので、同一の処理を実行するタスクモジュールでありながら、異なる心線番号を収容するタスクモジュールが多数存在することになる（以降ではこのようなタスクモジュールを多重したタスクモジュールと呼ぶ）。図１４では、図１２に示した故障復旧業務の一部を上方に示し、それに対応するタスクモジュールを下方に示している。例えば、判定／故障距離測定という素業務は試験監視モジュールというタスクモジュールによって実行されることを示している。ただし、電話番号入力という素業務に対しては、オペレータが計算機に投入する作業のみであるから対応するタスクモジュールが存在しない。そして、故障復旧業務は左方より開始され矢印の向きに処理が実行される。従来のプラットフォームシステムでは、同一の処理を実行するタスクモジュールでありながら、図１４に示す試験監視モジュールＭ１１，Ｍ１２，Ｍ１３のように、多重したタスクモジュールが存在する場合、適切なタスクモジュールを選択する配慮がなされておらず、単一のタスクモジュールに対してのみ業務処理依頼の接続が行われる構成であった。このため、不良心線を図１４に示す共通データベースＤＢＯによって特定できても、その心線がどの試験監視モジュールに収容されているかということと、収容先の試験監視モジュールへの処理依頼が実現不可能な構成である。アプリケーションプログラム構築技術では、例えば故障復旧業務を行う場合には、図１３に示す素業務のフローが構築できる。ユーザから故障苦情を受けたオペレータは故障復旧のアプリケーションプログラムを起動させる。まず、対象となる電話番号を入力して、その電話番号情報を元に共通データベースＤＢＯから心線情報を検索する。次に、試験監視モジュールで該当する光ファイバの破断点検出を行う。大規模加入者地域では、収容する加入者数が非常に多いので、加入者数に比例して試験監視モジュールなどのタスクモジュールが多重して必要となる。このような試験監視モジュールが複数存在すると、検索した心線がどの試験監視モジュールに収容されているのかを特定できない。つまり、アプリケーションプログラム構築技術においても、多重タスクモジュールが存在すると、素業務に対するタスクモジュールを特定できないので不都合が生じる。
【０００９】
また、緊急性の低い定期試験業務のような業務が、使用頻度が比較的に高い試験監視モジュールを占有しているときに、故障復旧業務のような緊急性の高い業務が発生した場合には、緊急性の低い業務の処理が終了するまで、緊急を有する業務を待ち状態にさせてしまう可能性がある。従来のプラットフォームでは、このような状況を回避するために業務毎に優先度を決定して、プラットフォーム内の優先度制御機能であるアクセッサによって緊急性の高い業務を該当するタスクモジュールへ優先的に接続して、この問題に対処していた。しかし、上記のように多重したタスクモジュールが存在する場合では、従来のプラットフォームの優先度管理制御機能部であるアクセッサでは、アプリケーションプログラムの業務フローにおいて、どのタスクモジュールを使用するのかについては特定できるが、どの多重タスクモジュールを使用するのかまでをあらかじめ特定できないので、優先度制御機能が効果的に実行できない。
【００１０】
また、このような従来のプラットフォームはオブジェクト指向言語の一つであるＣ＋＋を用いて構成され、その設計においては  Ｊ．  Ｒｕｍｂａｕｇｈ  ｅｔ  ａｌ．，“Ｏｂｊｅｃｔ−Ｏｒｉｅｎｔｅｄ  Ｍｏｄｅｌｉｎｇ  ａｎｄ  Ｄｅｓｉｇｎ  ”，Ｐｒｅｎｔｉｃｅ  Ｈａｌｌ，  Ｉｎｃ．，  １９９１  のオブジェクト指向モデリング手法（以下ＯＭＴ法と略称）を用いている。この手法によって、各インタフェース機能や優先度管理制御機能はオブジェクトとして設計され、これらオブジェクトの結合体としてプラットフォームが動作する構成である。しかしながら、例えば、線路業務を実行する際に、アプリケーションプログラムがタスクモジュールのみ利用してデータベースを用いない業務であれば、構成としてＤＢインタフェーサが不要である。同様に、従来のプラットフォームでは、複数業務の優先管理制御機能としてアクセッサを具備しているが、業務が複数存在せず、単一の業務のみ発生する場合には、優先度管理制御を実行する必要がなく、接続に関与するインタフェーサのみ具備すれば、プラットフォームの構成として十分である。このように従来のプラットフォームの構成は、固定された情報処理システムとして構築され、必ずしも使用環境に適さないことがある。
【００１１】
また、加入者系における光化の展開は、現時点の初期の段階から成長期、成熟期を経て進展するものと思われる。したがって、加入者系オペレーションシステムの導入期においては、タスクモジュールの種類が豊富でないことや、光ファイバとメタリックケーブルの混在する時期でもあり、複雑な機能を有するよりも単純な機能のみを有し、基本的な動作を実行するオペレーションシステムの方が適している。そして、将来的には、線路網形態が変化したり、光技術の進歩によって多種多様なタスクモジュールの出現が予想される。また、社会の要求に適合するためにオペレーションシステム自体も徐々に進化して、新たな機能が必要となる。このような時期において初めて、拡張性と機能性に富んだオペレーションシステムが要求される。
【００１２】
本発明の目的は、同一処理を実行するタスクモジュールが多重して存在する場合でも、多重タスクモジュール群から適切なタスクモジュールを選定して、該当する多重タスクモジュールへのアプリケーションプログラムの接続を実行し、さらに、発生した業務毎の優先度から判断して、効率的な接続を行う優先度管理制御を実行するプラットフォーム（これを多重タスクモジュール接続プラットフォームと呼ぶ）を有するプラットフォームシステムを提供することにある。
【００１４】
【課題を解決するための手段】
本発明のプラットフォームシステムは、データベース群と、対象毎に制御および／または管理の異なるタスクモジュールである多重タスクモジュール群と、前記データベース群と前記多重タスクモジュール群を用いて一連の仕事を行うアプリケーションプログラム群と、これらデータベース群、多重タスクモジュール群、アプリケーションプログラム群の結合部であるプラットフォームを含むプラットフォームシステムにおいて、多重タスクモジュール群の多重タスクモジュールの中から該当するタスクモジュールを検索し、該タスクモジュールの接続を制御するタスクモジュールマネージャと、タスクモジュールマネージャが該当するタスクモジュールを検索する時に利用される、各タスクモジュールの特性を示す情報を蓄積する専用データベースと、緊急性の高いアプリケーションプログラムを優先的にタスクモジュールへ接続切替する優先度管理制御を実行するタスクモジュールアクセッサを前記プラットフォームが有する。
【００１５】
本発明は、試験監視モジュールなどの個別のタスクモジュール毎にタスクモジュールマネージャとタスクモジュールアクセッサを構築し、さらに専用データベースを設ける。このタスクモジュールマネージャは、処理を実行するのに適切な多重タスクモジュールを選定し、その多重タスクモジュールへの接続を管理する。タスクモジュールマネージャが多重タスクモジュールを選定するときの情報は専用データベースから入手する。専用データーベースは、タスクモジュールマネージャが適切な多重タスクモジュールを選定するときに必要とする情報を蓄積している。例えば、試験監視モジュールの場合、対象とする光ファイバの心線番号から、これを収容している試験監視モジュールが、どの試験監視モジュールであるかという情報を蓄積している。そして、タスクモジュールアクセッサによって、従来のプラットフォームにおけるアクセッサが実行するのと同様に多重タスクモジュールに関する優先度管理制御を実行する。例えば、優先度の低い業務が多重タスクモジュールを占有しているときに優先度の高い業務が発生した場合に、優先度の低い業務を一時中断させて、優先度の高い業務を先に実行させる。そして、優先度の高い業務の処理が終了したら、一時中断していた優先度の低い業務を再開させるという一連の操作をタスクモジュールアクセッサは実行する。タスクモジュールが多重した場合には適切なタスクモジュールを選定することと、タスクモジュールにおいて緊急の業務が発生した場合に優先度の高い業務を優先的に実行させるための優先度制御機能を併せもつことを目的とした多重タスクモジュール群への接続を行う。
【００１８】
また、例えば、光ファイバの破断点検出や損失測定を行う試験監視モジュールの場合、１台の試験監視モジュール内に収容可能な心線の数が数万本に限られるため、大規模加入者地域ではこのような試験監視モジュールが数台必要となる。このような多重タスクモジュールが存在するときに、多重タスクモジュールの接続管理制御を実行するタスクモジュールマネージャと優先度管理制御を実行するタスクモジュールアクセッサが必要となるが、これらは多重タスクモジュールが新規に登録される度にタスクモジュールマネージャとタスクモジュールアクセッサの上位クラスから自動的に発生して、多重タスクモジュールに対して固有のタスクモジュールマネージャとタスクモジュールアクセッサとなる。
【００１９】
【発明の実施の形態】
次に、本発明の実施の形態について図面を参照して説明する。
【００２０】
図１は、本発明の一実施形態のプラットフォームシステムの構成図である。
【００２１】
本実施形態のプラットフォームシステムはアプリケーションプログラムＡＰ１〜ＡＰ４とタスクモジュールＭ１，Ｍ１２，Ｍ１３とデータベースＤＢＯ  ，ＤＢ１とプラットフォームＰＦで構成されている。プラットフォームＰＦは、アプリケーションプログラムＡＰ１  ，ＡＰ２  ，ＡＰ３  ，ＡＰ４  とのインタフェ−スであるＡＰインタフェーサ１と、専用データベースＤＢ０  ，データベースＤＢ１  とのインタフェ−スであるＤＢインタフェーサ２と、多重したタスクモジュールである試験監視モジュールや切替運用モジュールであるタスクモジュールＭ１１，Ｍ１２，Ｍ１３とのインタフェースであるＭインタフェーサ５と、タスクモジュールＭ１１，Ｍ１２，Ｍ１３に対してアプリケーションプログラムＡＰ１  〜ＡＰ４  との接続管理を実行するＭ１  マネージャ４と、緊急性の高いアプリケーションプログラムを優先的にタスクモジュールへ接続切替する優先度切替制御を実行するＭ１  アクセッサ３と、アクセッサ６で構成されている。
【００２２】
専用データベースＤＢ０  は、検索した心線番号を収容している多重タスクモジュールの情報を蓄積している。そして、Ｍ１  マネージャ４はこの専用データベースＤＢ０  を用いて、多重タスクモジュールＭ１１，Ｍ１２，Ｍ１３の中から該当するタスクモジュールを検索し、そのタスクモジュールへの接続を制御する。Ｍ１  アクセッサ３は、多重タスクモジュールに関する使用権の優先度管理制御を実行する。タスクマネージャ２およびタスクアクセッサ１は、多重タスクモジュールＭ１１，Ｍ１２，Ｍ１３で処理する業務の優先度や個々の多重タスクモジュールＭ１１，Ｍ１２，Ｍ１３での最大同時処理可能数などの情報を把握している。アクセッサ６はＭ１  アクセッサ３と同様に線路業務の優先度制御を行う。ただし、このアクセッサ６は単一で存在するタスクモジュールに対して動作し、特定のタスクモジュールが多重して存在する場合には、その多重タスクモジュールに対して動作しない。もし、すべてのタスクモジュールが多重して存在する場合には、オブジェクトツールプラットフォームのエディタ機能によって、このアクセッサ６を除去することが可能である。データベースＤＢ１は線路業務を実行するためのデータベースである。具体例としては、図１２における電話番号／心線番号検索という作業を実行する。ここでは、１つのデータベースしか図示されていないが、実際には図１２におけるデータ更新や心線不良履歴追加などのための種々のデータベースが存在する。
【００２３】
図２は試験監視モジュールと切替運用モジュールがそれぞれ多重して存在し、情報収集モジュールが単一で存在する場合のＭマネージャＡ１  ，Ａ２とＭアクセッサＢ１，Ｂ２、多重した各タスクモジュールＭ１１，Ｍ１２，Ｍ２１，Ｍ２および情報収集モジュールＭ３の接続に関する構成図を示す。
【００２４】
図３は、上記の動作を行うアクセス手順の例を示す。ここでは、図１２に示した故障復旧業務を例として、簡単のため業務開始から試験監視モジュールの測定が終了するまでの部分のみを示す。（１）アプリケーションプログラムＡＰは故障苦情のあった電話番号を元に、データベースＤＢ１から心線番号を検索する。（２）データベースＤＢ１  は依頼のあった電話番号の心線番号を検索し、検索結果を送信する。（３）アプリケーションプログラムＡＰは多重試験監視モジュールへ故障の判定と故障距離の測定を依頼するが、ここで試験監視モジュールは多重タスクモジュールであるから、アプリケーションプログラムＡＰは実際に多重タスクモジュールが処理をする前に適切な多重タスクモジュールにアプリケーションプログラムＡＰが接続できるように試験監視ＭマネージャＡ１  へ依頼する。（４）試験監視ＭマネージャＡ１  は専用データベースＤＢ０  にアクセスして、心線番号を収容する多重タスクモジュールの情報の検索を依頼する。（５）専用データベースＤＢ０  は依頼された検索結果を試験監視ＭマネージャＡ１へ送信する。（６）試験監視ＭマネージャＡ１  は得られた情報から適切な多重タスクモジュールへ処理を依頼するが、その前に優先度管理制御を実行する試験監視ＭアクセッサＢ１  へアプリケーションプログラムＡＰを接続する。（７）試験監視ＭアクセッサＢ１  では優先度制御を実行して、適切な優先度制御を実行後に多重タスクモジュール（ここでは例として多重試験監視モジュールＭ１１とする）に処理を依頼する。（８）多重試験監視モジュールＭ１１は故障の判定と故障距離の測定を終了したら、その結果を試験監視ＭアクセッサＢ１へ送信する。（９）試験監視ＭアクセッサＢ１は、処理結果をアプリケーションプログラムＡＰへ送信する。
【００２５】
図４は多重タスクモジュールが存在し、ある多重タスクモジュールにおいて優先度制御が要求される場合のＭアクセッサの動作に関するアクセス手順の例を示す図である。ある多重タスクモジュールへのアプリケーションプログラムからの処理依頼数が、その多重タスクモジュールの最大同時処理可能数を越えてしまった場合、多重タスクモジュールでのいずれかの処理が終了するまで、最大同時処理可能数を越えて接続してきたアプリケーションプログラムからの処理依頼は実行されず、待ち状態に陥ってしまう。例えば、多重タスクモジュールの最大同時処理可能数が１として、この多重タスクモジュールを定期試験業務のような重要度の低い業務が占有しているときに、故障復旧業務のような緊急を要する業務が発生して、この多重タスクモジュールを使用するときには、現在実行されている定期試験業務が終了するまで、故障復旧業務に関する処理は開始されない。このような事態を回避するために、あらかじめ業務毎に優先度をつけて、優先度が低く中断可能な業務が多重タスクモジュールを占有しているときに、優先度の高い業務が接続してきた場合に、優先度の低い業務を一時中断させて、優先度の高い業務が先に多重タスクモジュールを使用できる優先度制御をＭアクセッサが行う。優先度の高い業務が多重タスクモジュールの使用を終了したら、Ｍアクセッサは一時中断している優先度の低い業務を再開させる。優先度制御時の、一時中断した業務のデータはＭアクセッサで管理する。
【００２６】
図４において、アプリケーションプログラムＡＰ１  とアプリケーションプログラムＡＰ２  の優先度においてはアプリケーションプログラムＡＰ２  の方が優先度が高いものとする。
【００２７】
（１）多重タスクモジュールＭ１１を用いるアプリケーションプログラムＡＰ１  が発生して、試験監視ＭマネージャＡ１へアプリケーションプログラムＡＰ１を接続する。図３において、適切な多重タスクモジュールを選択する一連の処理を明記したので、ここではその処理の説明を省略する。（２）試験監視ＭマネージャＡ１は試験監視ＭアクセッサＢ１に優先度制御のためにアプリケーションプログラムＡＰ１を接続する。（３）試験監視ＭアクセッサＢ１は優先度を考慮して多重試験監視モジュールＭ１１へアプリケーションプログラムＡＰ１  を接続する。ただし、ここでは、アプリケーションプログラムＡＰ１  よりも前に処理依頼されているアプリケーションプログラムがないので、優先度制御は実行されずに多重試験監視モジュールＭ１１にアプリケーションプログラムＡＰ１を接続する。（４）アプリケーションプログラムＡＰ１  が多重試験監視モジュールＭ１１に接続された後にアプリケーションプログラムＡＰ１  より優先度の高いアプリケーションプログラムＡＰ２  が発生して、試験監視マネージャＡ１にアプリケーションプログラムＡＰ２を接続する。図３において、適切な多重タスクモジュールを選択する一連の処理を明記したので、ここでもその処理の説明を省略する。（５）試験監視ＭマネージャＡ１は試験監視ＭアクセッサＢ１に優先度制御のためにアプリケーションプログラムＡＰ１を接続する。（６）試験監視ＭアクッセサＢ１はアプリケーションプログラムＡＰ１  とアプリケーションプログラムＡＰ２  の優先度を比較するが、この場合アプリケーションプログラムＡＰ２  の方が優先度が高いので、アプリケーションプログラムＡＰ１  の処理実行を中断するように命令する。（７）多重試験監視モジュールＭ１１はアプリケーションプログラムＡＰ１  を中断したことを示す信号と一時中断データを試験監視ＭアクセッサＢ１へ送信する。（８）試験監視ＭアクセッサＢ１はアプリケーションプログラムＡＰ２  の処理を多重試験監視モジュールＭ１１へ依頼する。（９）多重試験監視モジュールＭ１１はアプリケーションプログラムＡＰ２  の処理が終了したら、その結果を試験監視ＭアクセッサＢ１へ送信する。（１０）試験監視ＭアクセッサＢ１は処理結果をアプリケーションプログラムＡＰ２  へ送信する。（１１）試験監視ＭアクセッサＢ１は一時中断していたアプリケーションプログラムＡＰ１を再開する信号とその中断データを多重試験監視ジュールＭ１１へ送信する。（１２）多重試験監視ジュールＭ１１はアプリケーションプログラムＡＰ１  の処理が終了したら、その結果を試験監視ＭアクセッサＢ１へ送信する。（１３）試験監視ＭアクセッサＢ１は処理結果をアプリケーションプログラムＡＰ１  へ送信する。
【００２８】
図５は本発明におけるオペレーションシステムの設計例を示している。この設計には前記ＯＭＴ法を用いている。
【００２９】
この設計には、実世界の抽象概念をオブジェクトとして捉え、これらオブジェクトのモデル化とオブジェクト間の関連を記述するのに有効な、前記ＯＭＴ記法をによる３つのモデルのうちのオブジェクトモデルを用いて記述している。このオブジェクトモデルは、システム内のオブジェクトとそれらの関係を記述するのに有効な手法である。図４における線路オペレーションスシテムは、各地域の保守センターから一般ユーザまでの設備や装置に対する管理や保守、制御を実行するシステムであり、交換系や伝送系などのような他のオペレーションシステムと統合された統合オペレーションシステムの一要素である。ＯＭＴ記法では、この統合オペレーションシステムをスーパークラスとし、線路オペレーションシステムや他オペレーションシステムをサブクラスとする。サブクラスはスーパークラスの特性を継承するという特徴をもつ。このような継承の関係を示す記法がスーパークラスとサブクラスをつなぐ三角形である。また、線路業務における特定の作業や測定を実行する装置とこれを動作させるプログラムによって構成されるタスクモジュールやデータベース、そしてこれらタスクモジュールやデータベースを用いて一連の仕事を行うアプリケーションプログラム、共通のインタフェ−ス機能を具備して、これらのアプリケーションプログラムやタスクモジュール、データベースの制御を実行するプラットフォームが、線路オペレーションシステムの要素となる。このように線路オペレーションシステムの構成要素を階層レベルに分けて関連づけることをＯＭＴ記法では集約と呼び、菱形で記述する。図５における黒丸は、該当するオブジェクトが複数存在することを記述する。各オブジェクト間の関係をＯＭＴ記法では関連と呼び、線分によって結合される。
【００３０】
保守オペレータはエディタを操作してＰＦ（プラットフォーム）を編集する。また、オペレータはアプリケーションプログラムＡＰを操作することによって、線路業務を実行する。ＰＦは他オペレーションシステムとの接続を管理するシステムマネージャと、線路業務の優先度制御を実行するアクセッサ、アプリケーションプログラムＡＰやタスクモジュールＭに対してデータ転送や制御命令のインタフェースを司るインタフェーサを保持する。これらシステムマネージャやアクセッサ、インタフェーサはＰＦの構成要素であり、ＰＦと集約の関係にある。インタフェーサはさらにＡＰインタフェーサ、Ｍインタフェーサ、ＤＢインタフェーサ、システムインタフェーサに分類される。これら各インタフェーサは、その上位クラスであるインタフェーサの特性を継承する。アプリケーションプログラムＡＰ、タスクモジュールＭ、データベースＤＢはそれぞれＡＰインタフェーサ、Ｍインタフェーサ、ＤＢインタフェーサへ接続される。特にＭインタフェーサには、多重したタスクモジュールが存在するような場合に、適切なタスクモジュールに接続し、かつ優先度制御を実行するためにＭマネージャとＭアクセッサが必要である。そのために、Ｍインタフェーサはタスクモジュールとのインタフェースを実行する作業の他に、上記の作業を実行するためのＭマネージャとＭアクセッサを保持する。Ｍマネージャは多重するタスクモジュールの中から適切なタスクモジュールを選択するために、専用データベースへアクセスし、情報を検索する。アクセッサはＡＰインタフェーサを通じてアプリケーションプログラムＡＰの優先度を管理し、この優先度に応じてタスクモジュールとデータベースを優先度制御する。
【００３１】
図６は本発明におけるプラットフォーム作成エディタの構成例を示す。プラットフォームの各機能（アクセッサ、ＡＰインタフェーサ、Ｍインタフェーサ、ＤＢインタフェーサ、システムマネージャ、他システムインタフェーサなど）をあらかじめオブジェクト化して、これれらをリポジトリに保管する。ここまでの操作はプラットフォームシステムの提供者である、ソフトウェアの開発者が行う。ユーザはリポジトリの中から必要な機能のみを選択して、最後に決定ボタンを押下することによって使用環境に応じたプラットフォームを作成することができる。
【００３２】
図７は本発明におけるプラットフォーム編集機能での新規タスクモジュールの登録例を示す。多重タスクモジュールが存在する場合は、適切なタスクモジュールを選択して接続を実行するＭマネージャと多重タスクモジュールにおける優先度管理制御を実行するＭアクセッサが必要である。多重タスクモジュールが存在する場合、画面の操作を実行することによって、プラットフォーム編集機能は当該の機能を自動的に生成する。
【００３３】
図８は、最も基本的なプラットフォームの構成図である。このプラットフォームの保持する機能はＡＰインタフェーサとＭ（タスクモジュール）（あるいはデータベース）インタフェーサのみである。線路業務であるアプリケーションプログラムＡＰは単一のタスクモジュールＭ（あるいはデータベース）による処理のみを要求する。発生する業務が一つだけなので、優先度制御を実行する必要がなく、したがって、アクセッサは不要である。このようなプラットフォームの構成は動作するタスクモジュールがただ一つしか存在せず、発生する線路業務もただ一つしか存在しない場合に有効である。この基本的なプラットフォームもユーザが編集機能を操作することによって作成することができる。
【００３４】
もちろん、図１に示したようなプラットフォームも上記のような編集機能をユーザが操作することによって作成することができる。
【００３５】
【発明の効果】
以上説明したように、本発明は、以下に示すような効果がある。
多重するタスクモジュール群への業務処理に関して、Ｍマネージャが適切な多重タスクモジュールを専用データベースから検索することによって、多重タスクモジュール群の中から該当するタスクモジュールを特定して、そのタスクモジュールへ接続することができ、多重するタスクモジュールに対してＭアクセッサが優先制御を実行することによって、緊急度に応じた多重タスクモジュールへの接続が可能である。
【００３６】
この特徴により、従来は単一のタスクモジュールに対してのみ、アプリケーションプログラムから業務処理依頼のための接続が可能であったが、多重タスクモジュールのシステム構成においても、多重するタスクモジュールの中から適切なタスクモジュールを選定して、さらに業務別の優先度制御までを実行できるので、多重タスクモジュールが多数存在することが予想される大規模加入者地域においても加入者系オペレーションシステムが効率的に利用できる。
【図面の簡単な説明】
【図１】本発明の一実施形態のプラットフォームシステムの構成図である。
【図２】Ｍ１  マネージャ４とＭ１  アクセッサ３とタスクモジュールの具体例を示す図である。
【図３】図１のプラットフォームシステムの動作例を示すシーケンス図である。
【図４】図１のプラットフォームシステムの他の動作例を示すシーケンス図である。
【図５】本発明におけるオペレーションシステムの設計例を示す図である。
【図６】本発明におけるプラットフォーム作成エディタの構成例を示す図である。
【図７】本発明におけるプラットフォーム編集機能での新規タスクモジュールの登録例を示す図である。
【図８】最も基本的なプラットフォームの構成図である。
【図９】アプリケーションプログラムがデータベースを使用して一連の仕事を行う従来例を示す図である。
【図１０】アプリケーションプログラムがデータベースを使用して一連の仕事を行う他の従来例を示す図である。
【図１１】プラットフォームシステムの従来例の構成図である。
【図１２】故障復旧業務の流れを示す図である。
【図１３】試験監視モジュールが収容する光ファイバの心線番号を示す図である。
【図１４】故障復旧業務と対応するタスクモジュールを示す図である。
【符号の説明】
ＡＰ１  ，ＡＰ２  ，ＡＰ３  ，ＡＰ４        アプリケーションプログラム
Ｍ１，Ｍ２，Ｍ３，Ｍ１１，Ｍ１２，Ｍ２１，Ｍ２２，Ｍ２３    タスクモジュール
ＤＢ０      専用データベース
ＤＢ１      データベース
ＰＦ    プラットフォーム
Ａ１      試験監視Ｍマネージャ
Ａ２      切替運用Ｍマネージャ
Ｂ１      試験監視Ｍアクセッサ
Ｂ２          切替運用Ｍアクセッサ
１    ＡＰインタフェーサ
２    ＤＢインタフェーサ
３    Ｍ１  アクセッサ
３１      試験監視Ｍアクセッサ
３２      切替運用Ｍアクセッサ
４    Ｍ１  マネージャ
４１      試験監視Ｍマネージャ
４２      切替用Ｍマネージャ
５    Ｍインタフェーサ
６    アクセッサ
【図１】
0003596975.tif 000002
【図２】
0003596975.tif 000003
【図３】
0003596975.tif 000004
【図４】
0003596975.tif 000005
【図５】
0003596975.tif 000006
【図６】
0003596975.tif 000007
【図７】
0003596975.tif 000008
【図８】
0003596975.tif 000009
【図９】
0003596975.tif 000010
【図１０】
0003596975.tif 000011
【図１１】
0003596975.tif 000012
【図１２】
0003596975.tif 000013
【図１３】
0003596975.tif 000014
【図１４】
0003596975.tif 000015