JPH11161483A - 動的拡張性を備えたソフトウェア構築システムおよび方法 - Google Patents

Abstract

(57)【要約】 【課題】 既存のコンポーネントをできるだけ再利用し
ながら、新規のコンポーネントと協調させて、ソフトウ
ェアを動的に拡張することが課題である。 【解決手段】 特定のコンポーネントの機能を呼び出す
処理コードをすべて、それを管理する管理コンポーネン
トに集中させる。動的拡張を行う際には、特定のコンポ
ーネントとともに管理コンポーネントを交換すること
で、コンポーネント協調のための情報も自動的に更新さ
れる。そのほかのコンポーネントについては、再利用す
ることが可能になる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、既存のコンピュー
タソフトウェアを再利用しながら、ソフトウェアを動的
に拡張することができるソフトウェア構築システムおよ
びその方法に関する。

【０００２】

【従来の技術】コンピュータのハードウェア上に構築さ
れるソフトウェアシステムは、年々多機能化、大規模化
している。その中でも、最近、例えば、次のような動的
拡張性を持ったシステムの開発要求が高い。・旧システ
ムの運用を継続しながら、その機能を融合するデータベ
ースシステム金融機関のオンラインシステムのような大
規模なデータベースシステムは、データの整合性を保つ
ために様々な配慮がなされており、機能拡張のためのシ
ステム停止に時間がかる。そのような時間を費やすこと
なしに機能拡張を可能にするために、動的拡張システム
が望まれている。・ネットワークを通して得た最新の機
能モジュール（プラグイン等）を即座に利用可能にする
個人用情報表示・編集システムネットワークのエンドユ
ーザが利用する情報表示・編集システムは、常にその時
点で最高の技術を駆使した機能が望まれるために、多機
能となり、起動・終了に時間がかかる。さらなる機能拡
張のために要する起動・終了の時間は、ユーザの自由な
操作意志を阻害し、能率の低下を招く。また、機能拡張
を行う際にシステム全体を更新することは、ネットワー
クトラフィックの増大につながり、コストが増大する。
このような問題を回避するために、動的拡張システムが
望まれている。

【０００３】ここで、動的拡張とは、システム拡張に要
する時間が短く、拡張の前後において、稼働中のシステ
ム資源のうち拡張に関わらない部分が継承されるような
機能を意味する。

【０００４】上述の例では、動的拡張機能は、運用時の
時間コストを節約する点で有利であるが、それ以外に
も、ソフトウェアの開発効率の改善や、ソフトウェア部
品の再利用が促進されることによる信頼性の向上等のメ
リットがある。このため、既存のアプリケーションシス
テム等の中にも、独自にこれらの動的拡張機能を実装し
ているものがある。このように、動的拡張性を備えたシ
ステムのニーズは現在でも存在し、ハードウェアの高性
能化に応じたソフトウェアの高機能化に対応して、将
来、そのニーズはより高まると思われる。

【０００５】動的拡張機能は優れた機能であるが、それ
を備えたシステムを実現することは難しい。その実現の
ための開発コストを下げ、システムの信頼性を増すため
に、次のような既存技術が利用可能である。 ・ソフトウェア再利用技術 ・分散オブジェクト・コンポーネント技術 一般に、コンピュータのソフトウェアを開発するには多
大なコストがかかる。ライブラリ、オブジェクト指向、
フレームワーク、コンポーネントウェア、デザインパタ
ーン等の技術は、ソフトウェアを再利用することにより
開発コストを削減する目的を持って、研究されてきた。
これらは、一般的なソフトウェア開発過程で適用されて
いる。

【０００６】また、ＣＯＭ（component object mode
l）、ＣＯＲＢＡ（common object request broker arch
itecture ）、Java Beans（商標）等の分散オブジェク
ト・コンポーネント技術は、動的拡張システムを構築す
るための基礎的な機構として利用できる。ここで、オブ
ジェクトとは、データと処理をカプセル化したソフトウ
ェアの構成要素に対応し、コンポーネントとは、アプリ
ケーションを構成する機能単位（ソフトウェア部品）に
対応する。分散オブジェクト・コンポーネント技術と
は、複数のコンピュータ上に分散したオブジェクトやコ
ンポーネントを利用する技術である。

【０００７】

【発明が解決しようとする課題】しかしながら、従来の
動的拡張システムには、次のような問題がある。ソフト
ウェア再利用技術は、動的拡張性のような、一部のアプ
リケーション特有の性質を実現するための具体的な解決
方法は与えていない。また、分散オブジェクト・コンポ
ーネント技術は、その基礎的な解決のための道具は提供
するが、実際に動的拡張アプリケーションを開発するに
は不十分である。動的拡張を行うためには、次の課題が
解決される必要がある。

【０００８】Ａ．コンポーネントの型をチェックする。 Ｂ．動的にコンポーネントを読み込む。 Ｃ．読み込んだコンポーネントの提供する機能を実行す
る。

【０００９】Ｄ．読み込んだコンポーネントを協調させ
て活用する。 このうち、Ａ．は、コンポーネントがアプリケーション
の中でどのような役割を果たすかを特定する課題であ
る。分散オブジェクト・コンポーネント技術では、その
役割を型として分類し、それによりコンポーネントを識
別する。２つのコンポーネントの型が一致すれば、それ
らは同じ役割を果たすものとみなされる。Smalltalk-80
やObjective-C 等の一部のプログラミング言語では、言
語レベルでその機能を提供しているが、通常は、ライブ
ラリの関数呼び出しによりチェックを行う。

【００１０】Ｂ．とＣ．は、動作中のプログラムがコン
ポーネントの実体であるプログラムモジュールをいかに
ファイルシステム等から読み込み、実行させるかという
課題である。分散オブジェクト・コンポーネント技術が
そのための機構を提供する。また、Ｄ．は、読み込んだ
コンポーネントをアプリケーションの他の部分といかに
協調させて、機能拡張を行うかという課題である。

【００１１】以上の課題のうち、Ａ．、Ｂ．、Ｃ．は、
既存の分散オブジェクト、コンポーネント技術により解
決できるが、動的拡張にとって最も重要なＤ．を解決す
ることはできない。読み込まれた新規コンポーネント
が、元からアプリケーションに存在する部分の性能を改
善した代替品であれば、Ｄ．の課題は発生しない。しか
し、当初のアプリケーション設計時に予想されていない
新たな機能を備えている場合は、それをどう活用するか
は非常に重要な問題となる。従来の技術は、この問題に
対して明確な回答を与えていない。

【００１２】コンポーネント協調の具体的な問題として
は、次のようなものがある。例えば計算機のファイルシ
ステムの階層構造を２次元的に表示するアプリケーショ
ンがあり、表示のためのウィンドウを実現する部分がコ
ンポーネントとして交換可能になっていると想定する。
そのコンポーネントを、２次元表示との互換性を保ちな
がら、３次元のウィンドウを実現するコンポーネントに
交換することを考えてみる。

【００１３】この場合、コンポーネントの交換後も、ア
プリケーションの他の部分は、ウィンドウ用コンポーネ
ントに対して、２次元平面上の制御情報しか与えること
ができない。したがって、新規に組み込まれた３次元表
示コンポーネントは、アプリケーション内の他の部分と
協調して性能を発揮しているとは言えない。これでは、
アプリケーションの拡張ではなく、単なる交換である。

【００１４】３次元表示コンポーネントの性能を活用し
たアプリケーション拡張を行うには、その表示コンポー
ネントを制御している部分を修正してまわる必要があ
る。コード設計が適切になされていない場合、そのよう
な制御部分は多数のコンポーネントに分散されているこ
とが多い。

【００１５】この場合、開発者は、それらのコンポーネ
ントのソースコードを部分的に再利用することができる
かも知れないが、コンパイルされたバイナリコードの再
利用性は少ない。したがって、アプリケーションをバイ
ナリコードで受け取ったエンドユーザは、関連するコン
ポーネントをすべて新規なものに置き換えなければなら
ず、必要な個所のみ変更すればよいという動的拡張の利
点が失われる。

【００１６】一般に、アプリケーションの拡張の度合い
が大きいほど、その前後で継続して利用できるソフトウ
ェア資源の量は少なくなる。現状の技術は、動的拡張に
関する重要な問題の一つであるコンポーネント協調への
解答を、既存のコンポーネントを再利用できる形で提供
していない。このため、動的拡張性を持つアプリケーシ
ョンの開発効率は悪く、その信頼性も低くなっている。

【００１７】本発明の課題は、既存のコンポーネントを
できるだけ再利用しながら、新規のコンポーネントと協
調させて、ソフトウェアを動的に拡張することができる
ソフトウェア構築システムおよびその方法を提供するこ
とである。

【００１８】

【課題を解決するための手段】図１は、本発明のソフト
ウェア構築システムの原理図である。図１のソフトウェ
ア構築システムは、構成手段１と変更手段２を備え、複
数の機能単位３、４を組み合わせてソフトウェア５を構
築する。

【００１９】構成手段１は、複数の機能単位３のうち特
定の機能単位３を使用する処理を、少数の管理用機能単
位４に集中して実装する。変更手段２は、ソフトウェア
５を変更する際に、特定の機能単位３を含む１つ以上の
機能単位の交換または追加を行う。

【００２０】構成手段１は、特定の機能単位３を使用す
る処理とは、その機能単位３が持っている機能の実行結
果を利用する必要のある処理であり、例えば、他の機能
単位のメソッドを呼び出す処理コードに対応する。この
ような処理を、少数の管理用機能単位４に集中して実装
することで、特定の機能単位３を使用するコードの分散
が回避される。

【００２１】変更手段２は、特定の機能単位３の機能を
変更する際に、少なくともその機能単位３を交換し、必
要であれば、それを管理する管理用機能単位４も交換す
る。また、特定の機能単位３を新たに追加する際に、必
要であれば、管理用機能単位４も追加する。

【００２２】このように、特定の機能単位３に関する変
更を行う際には、それを使用する処理コードを集中して
実装している管理用機能単位４を交換／追加すれば十分
であり、他の機能単位３を交換／追加する必要はなくな
る。したがって、既存の機能単位３をできるだけ再利用
しながら、交換／追加された新規の機能単位と協調させ
て、ソフトウェア５を拡張することが可能になる。

【００２３】例えば、図１の機能単位３、４は、それぞ
れ、後述する図２におけるコンポーネント、管理コンポ
ーネントに対応し、構成手段１と変更手段２は、後述す
る図３におけるカーネル１１、実装マネジャ１２、コン
ポーネントマネジャ１３、およびメッセージディストリ
ビュータ１４に対応する。

【００２４】また、図１のソフトウェア構築システムと
は別に、要求処理手段、機能単位管理手段、実装手段、
および制御手段を備えたソフトウェア構築システムを構
成することもできる。

【００２５】このシステムにおいて、要求処理手段は、
複数の機能単位の間の処理要求を処理する。機能単位管
理手段は、上記複数の機能単位のうち特定の機能単位
と、その特定の機能単位を使用する処理を集中して実装
した少数の管理用機能単位との関係を管理する。

【００２６】実装手段は、ソフトウェアを変更する際
に、上記特定の機能単位を含む１つ以上の機能単位の交
換または追加を行う。制御手段は、上記要求処理手段、
機能単位管理手段、および実装手段のうち少なくとも１
つ以上を制御する。

【００２７】要求処理手段は、複数の機能単位の間でや
り取りされるメッセージ呼び出し等の処理要求の配送を
行い、機能単位管理手段は、機能単位間における管理／
被管理関係を管理する。管理用機能単位が特定の機能単
位を使用する処理を実行する際には、通常、要求処理手
段を介して、管理用機能単位から特定の機能単位に処理
要求が送られる。

【００２８】実装手段は、特定の機能単位の機能を変更
する際に、少なくともその機能単位交換し、必要であれ
ば、機能単位管理手段の管理情報に基づいて、それを管
理する管理用機能単位も交換する。また、特定の機能単
位を新たに追加する際に、必要であれば、管理用機能単
位も追加する。これらの要求処理手段、機能単位管理手
段、および実装手段は、制御手段により制御される。

【００２９】この構成においても、図１のソフトウェア
構築システムと同様に、既存の機能単位をできるだけ再
利用しながら、交換／追加された新規の機能単位と協調
させて、ソフトウェアを拡張することが可能になる。

【００３０】例えば、要求処理手段は、後述する図３に
おけるメッセージディストリビュータ１４に対応し、機
能単位管理手段はコンポーネントマネジャ１３に対応
し、実装手段は実装マネジャ１２に対応し、制御手段は
カーネル１１に対応する。

【００３１】

【発明の実施の形態】以下、図面を参照しながら、本発
明の実施の形態を詳細に説明する。まず、以下で用いる
用語を、前述のものを含めて定義しておく。アプリケー
ションとは、実際に稼働するコンピュータソフトウェア
であり、コンポーネントとは、アプリケーションを構成
する個々の機能単位であり、コンポーネント実装とは、
コンポーネントの機能を実現するソフトウェアの実体で
ある。また、メソッドとは、コンポーネントが提供する
個々の機能であり、通常、１つのコンポーネントには１
つ以上のメソッドが含まれる。

【００３２】したがって、ここで扱うコンポーネント
は、ＣＯＲＢＡ等の特定のコンポーネントや特定のオブ
ジェクトの枠組みに限られることなく、任意の形式のソ
フトウェアにおける機能単位を指す。

【００３３】ここで、動的拡張に関する従来技術の問題
点を改めて整理すると、次のようになる。 （Ｐ−１）特定コンポーネントを制御する制御コード
が、複数のコンポーネントに分散している。これらの制
御コードには、制御対象のコンポーネント名、そのコン
ポーネントに実行を依頼するメソッド名、およびそのメ
ソッドの実行に必要な引数が含まれる。 （Ｐ−２）制御コードを集中させるための機構も、アプ
リケーション開発者の責任において開発しなければなら
ない。

【００３４】これらの問題点を解決し、動的拡張の利点
（必要な個所のみ変更することによる時間の節約、作業
中のデータの活用）を確保したシステムを効率よく開発
するために、本実施形態では、次の手順に従って開発を
行う。 １．開発するコンポーネントの構成を決定する。この構
成は、後述する「動的拡張のためのコンポーネント構成
決定手法」に基づいて決定する。 ２．既存の分散オブジェクト・コンポーネント技術を反
映したプログラミング環境を用いて、各コンポーネント
を実装する。このとき、後述する「動的拡張のためのコ
ンポーネント実装指針」に従って、後述する「動的拡張
を行うコンポーネント統合機構」の提供する適切な機能
を用いる。 ３．各コンポーネントを統合して、アプリケーションと
して完成させる。このとき、「動的拡張を行うコンポー
ネント統合機構」を用いる。

【００３５】次に、図２および図３を参照しながら、
「動的拡張のためのコンポーネント構成決定手法」、
「動的拡張のためのコンポーネント実装指針」、および
「動的拡張を行うコンポーネント統合機構」について説
明する。

【００３６】まず、「動的拡張のためのコンポーネント
構成決定手法」は、次のようになる。拡張性を実現する
ために、いくつかのコンポーネントを組み合わせたもの
として、アプリケーションを設計する。これは、既存の
ソフトウェア再利用技術で、一般的に行われていること
である。そのコンポーネント構成は、アプリケーション
のアーキテクチャに応じて自由に決定してよいが、次の
４つの条件（ＡＣ−１）−（ＡＣ−４）を満たすものと
する。ここで、ＡＣは、Architecture Conditionを表
す。 （ＡＣ−１）それぞれのコンポーネントに名前を付け
る。 （ＡＣ−２）それぞれのコンポーネントの役割を（概念
上）定める。 （ＡＣ−３）あるコンポーネント群（コンポーネントグ
ループ）の間に強い関連がある場合は、それらを管理す
る管理コンポーネントを設ける。 （ＡＣ−４）すべてのコンポーネントが、一つの管理コ
ンポーネント（ルート管理コンポーネント）からたどれ
るようにする。

【００３７】管理コンポーネントは、必要であれば、階
層的に複数設けることができ、コンポーネントグループ
がないときは、１つの管理コンポーネントのみを設け
る。図２は、管理コンポーネントを階層的に設けた様子
を示している。図２において、管理コンポーネントから
の矢印が指すコンポーネントは管理対象を表し、最上部
の管理コンポーネントがルート管理コンポーネントに対
応する。

【００３８】次に、「動的拡張のためのコンポーネント
実装指針」は、次のようになる。実際に動作するアプリ
ケーションを得るために、上述のコンポーネント構成決
定手法で設計したそれぞれのコンポーネントを実装す
る。各コンポーネントは、例えば、前述した動的拡張の
課題Ａ．−Ｃ．を解決できる任意のプログラミング言語
を用いて実装する。そのとき、以下の６つの条件（ＩＣ
−１）−（ＩＣ−６）を満たすものとする。ここで、Ｉ
Ｃは、Implement Condition を表す。 （ＩＣ−１）それぞれのコンポーネント実装に名前をつ
ける。 （ＩＣ−２）１つのコンポーネント内で処理が完結する
機能は、原則としてそのコンポーネント内で実装し、ひ
とまとまりの機能にメソッド名をつける（関連：（ＩＣ
−６）） （ＩＣ−３）他のコンポーネントを扱う処理は、原則と
してそれを管理する管理コンポーネント内で実装する
（関連：（ＩＣ−６）） （ＩＣ−４）管理コンポーネントは、被管理コンポーネ
ントの名前と、そのコンポーネントのメソッド名を指定
し、「動的拡張を行うコンポーネント統合機構」を呼び
出すことで、被管理コンポーネントの機能を用いる。 （ＩＣ−５）コンポーネント実装を一時的に交換された
くないときは、それより上位に位置する管理コンポーネ
ントがコンポーネントの名前を指定し、「動的拡張を行
うコンポーネント統合機構」を呼び出すことで、そのコ
ンポーネント実装をロックする。そして、必要がなくな
れば、ロックを外す。 （ＩＣ−６）あるコンポーネントが、その被管理コンポ
ーネントではない他のコンポーネントが担当する機能を
どうしても呼び出したいときは、例外的に、直接、ルー
ト管理コンポーネントに処理を依頼する（関連：（ＩＣ
−２），（ＩＣ−３））。

【００３９】上述したコンポーネント構成決定手法とコ
ンポーネント実装指針を経て作成されたアプリケーショ
ンにおいては、特定のコンポーネントに関するコンポー
ネント協調のための制御コードをすべて分離して、それ
を管理する管理コンポーネントに集中させることができ
る。これにより、上述の問題点（Ｐ−１）が解決され
る。動的拡張を行う際には、この管理コンポーネントを
交換することで、コンポーネント協調のための情報も自
動的に更新されるため、大幅な機能拡張が可能となる。

【００４０】次に、「動的拡張を行うコンポーネント統
合機構」について説明する。各コンポーネントは、この
コンポーネント統合機構（Mechanism for Dynamic Modi
fication of Component Configuration, ＭＤＭＣＣ）
により統合されて、アプリケーションとなる。また、Ｍ
ＤＭＣＣは、アプリケーション開発の際にも機能提供を
行う。ＭＤＭＣＣは、本実施形態の中心的なソフトウェ
アであり、以下のサービスを提供する。 （Ｓ−１）アプリケーションの起動 （Ｓ−２）被管理コンポーネントのメソッド呼び出し （Ｓ−３）コンポーネント実装のロック、アンロック （Ｓ−４）コンポーネント実装の交換 （Ｓ−５）アプリケーションの拡張 （Ｓ−６）ルート管理コンポーネントへの直接処理要求 このＭＤＭＣＣは、例えば、図３に示すように構成され
る。図３において、カーネル１１は、ＭＤＭＣＣの他の
要素１２、１３、１４を用いて、サービス（Ｓ−１）、
（Ｓ−５）を提供する。実装マネジャ１２とコンポーネ
ントマネジャ１３は連携して動作し、サービス（Ｓ−
３）、（Ｓ−４）を提供する。実装マネジャ１２は、コ
ンポーネント実装を読み込む機能を、コンポーネントマ
ネジャ１３は、システム稼働時のコンポーネントの状態
を管理する機能をそれぞれ受け持つ。このため、コンポ
ーネントマネジャ１３は、各コンポーネントの状態に関
する管理データを保持している。

【００４１】メッセージディストリビュータ１４は、実
装マネジャ１２とコンポーネントマネジャ１３を用いて
サービス（Ｓ−２）を提供し、さらに、それらとルート
管理コンポーネントを用いてサービス（Ｓ−６）を提供
する。サービス（Ｓ−５）の提供時には、メッセージデ
ィストリビュータ１４がカーネル１１に指示を送る。

【００４２】このＭＤＭＣＣは、開発対象のアプリケー
ションに依らないソフトウェアであり、必要に応じて、
各アプリケーションに組み込んでおくことができる。ア
プリケーション開発の際に、あらかじめ用意されたＭＤ
ＭＣＣを用いることで、同様の機構を新たに開発する手
間が省け、開発効率が改善される。したがって、上述の
問題点（Ｐ−２）が回避される。

【００４３】次に、本実施形態の方法により作成された
アプリケーションの具体例として、グラフ構造のデータ
を扱うグラフ構造エディタについて説明する。ここでい
うグラフ構造とは、ノード（節点）とエッジ（枝）から
なるグラフのことである。ここで説明するエディタは、
有向グラフという、グラフ構造の中でも単純な構造を持
つものを対象としている。有向グラフの具体例について
は、後で処理例を述べるときに示すことにする。

【００４４】今回作成したグラフ構造エディタは、以下
の機能を持つ。 ・ノードの作成、ラベルの付与、表示、位置の移動、前
後の移動 ・エッジの作成、ラベルの付与、表示、位置の移動、前
後の移動 ・エッジの有無を考慮したノードの自動配置（スプリン
グ・レイアウト） ・接続ノードに追従するようなエッジの自動配置 ・コンポーネントの交換 ・アプリケーションの動的拡張 スプリング・レイアウトは、表示画面上で、エッジ接続
されたノード同士はなるべく近く、そうでないノード同
士は遠くなるように、ノードの配置を調整する自動描画
手法であり、既存の配置をあまり変えないという性質を
持つ。スプリング・レイアウトは、例えば、簡単なアイ
ディア整理ツールとして用いられる。

【００４５】ユーザは、このエディタの機能を利用し
て、各ノードにラフなアイディア（個別情報）を設定
し、関連があると思うノード同士をエッジで接続する。
すると、関連があると思ったアイディア同士が、スプリ
ング・レイアウトにより、自動的に近寄って表示され、
関連性の低いアイディア同士は離れて表示される。

【００４６】このようなノードの自動配置機能は、一般
的に捕らえると、図４に示すように、グラフを可視化す
るパイプライン処理になっている。図４において、各直
方体はデータを表し、直方体同士を結ぶ円柱は処理を表
す。応用表現データ２１は、計算機内にあり、ユーザに
対して可視化されるべき情報を含んでいる。

【００４７】応用表現データ２１をグラフ抽象化処理す
ると、抽象的なグラフ構造を表す抽象表現データ２２に
なる。抽象表現データ２２をレイアウト生成処理する
と、実際の平面上の位置等が加わった視覚表現データ２
３になる。視覚表現データ２３を装飾処理すると、ノー
ドの色や重複関係等が加わった図表現データ２４にな
る。そして、図表現データ２４を、計算機のディスプレ
イ画面に収まるように、表示処理すると、ユーザが認知
できる図データ２５になる。

【００４８】このように、グラフデータの可視化は、図
４において右方向への流れに沿って行われる。ユーザが
右端の図データ２５を変更した場合は、このパイプライ
ンを左に向かって逆に処理し、グラフデータを更新しな
くてはならない。このパイプライン構造は、後述するア
ーキテクチャに強い影響を与える。

【００４９】図５は、グラフ構造エディタによるグラフ
データの表示例を示している。図５の画面の上部には、
メニューバー３１があり、下部にはメッセージ表示領域
３２があり、中央部にはグラフ領域３３がある。

【００５０】グラフ領域３３では、グラフの図データが
表示され、マウス等のポインティングデバイスによる編
集操作が可能である。この例では、グラフのノードは長
方形で表示され、エッジは矢印で表示されている。スプ
リング・レイアウトは毎秒数十回実行されており、ユー
ザがノードを追加すると、そのノードに重ならないよう
に周辺のノードが徐々に拡散する様子がアニメーション
表示される。

【００５１】このエディタは、ＪＤＫ１．１（Java Dev
eloper's Kit，商標）ベースのＪａｖａアプリケーショ
ンとして書かれており、そのソースコードの規模は、コ
メント空行込みで８，５３６行、２０９，０９１バイト
である。なお、このソースコードには、上述のＭＤＭＣ
Ｃも含まれている。

【００５２】グラフ構造エディタのアーキテクチャは、
図６に示すようになる。図６において、各長方形４１−
５０はコンポーネントを表し、その名前は（ＡＣ−１）
に基づいて付けられている。矢印は、（ＡＣ−３）に基
づいて設けられた管理コンポーネントと被管理コンポー
ネントの関係を表し、管理コンポーネントから被管理コ
ンポーネントに向かっている。コンポーネント粒度（ア
プリケーションの分割の度合い）を、このアーキテクチ
ャのように決定することは、アプリケーションのデザイ
ン作業の中でも重要な過程の一つである。

【００５３】これらのコンポーネントのうち、TaskMana
ger ４１は、間接的にすべてのコンポーネントの管理コ
ンポーネントであり、ルート管理コンポーネントに該当
し、（ＡＣ−４）を満たしている。以下、（ＡＣ−２）
に基づいて、それぞれのコンポーネントの名前、役割、
およびそれが独立したコンポーネントである理由を述べ
る。

【００５４】TaskManager ４１は、EventManager４２を
管理し、EventManager４２と共にアプリケーション全体
を制御する。被管理コンポーネントからの実行要求の収
集・解析と必要な情報の準備をEventManager４２が担当
し、それに基づく実際の制御の執行をTaskManager ４１
が担当する。

【００５５】これらのコンポーネントはルート管理コン
ポーネントの役割を担うため、現状のアプリケーション
の被管理コンポーネント群以外のコンポーネントが新た
に追加された場合、それらのコンポーネント実装を交換
する必要がある。したがって、このような場合に動的拡
張を行うためには、これらはコンポーネントとして独立
していなくてはならない。

【００５６】TaskManager ４１とEventManager４２が別
のコンポーネントであるのは、次の２つの場合が考えら
れるからである。 （１）TaskManager ４１の１つのコンポーネント実装に
対して、異なった情報収集方法が存在し、EventManager
４２のコンポーネント実装を独立して交換する場合 （２）EventManager４２のコンポーネント実装が発する
要求に対して、異なった実行方法が可能であり、TaskMa
nager ４１のコンポーネント実装を独立して交換する場
合 次に、DiagramManager４３は、TaskManager ４１により
管理され、図４に示した応用表現データ２１、抽象表現
データ２２、視覚表現データ２３を管理し、それらに関
する処理を行う。このコンポーネントは、この処理に関
連するコンポーネント群を管理する管理コンポーネント
である。したがって、その処理に関する動的拡張を可能
にするためには、その実装は交換可能でなくてはならな
い。

【００５７】LayoutGeneration４４は、DiagramManager
４３により管理され、抽象表現データ２２を視覚表現デ
ータ２３に変換するレイアウト生成処理を行う。その実
装としては、抽象表現データ２２や表示機構から独立し
て、様々なものが考えられる。したがって、動的交換可
能なコンポーネントでなくてはならない。

【００５８】GraphicalEntity ４５は、DiagramManager
４３により管理され、応用表現データ２１、抽象表現デ
ータ２２、視覚表現データ２３の一部を格納する。抽象
的なグラフ構造としては、レイアウト生成、表示機構、
図表現データ２４から独立して、複数考えることができ
るため、その実装は動的交換可能なコンポーネントでな
くてはならない。

【００５９】DisplayManager４６は、TaskManager ４１
により管理され、視覚表現データ２３、図表現データ２
４、図データ２５を管理し、それらに関する処理を行
う。このコンポーネントは、この処理に関連するコンポ
ーネント群を管理する管理コンポーネントである。した
がって、その処理に関する動的拡張を可能にするために
は、その実装は交換可能でなくてはならない。

【００６０】ViewType４７は、DisplayManager４６によ
り管理され、グラフデータを最終的にユーザに認知させ
る表示処理を行う。表示処理は、グラフの抽象表現デー
タ２２やその処理機構等とは独立に、２次元（２Ｄ）表
示、３次元（３Ｄ）表示等の異なった処理を行うことが
想定される。このため、その実装は動的交換可能なコン
ポーネントでなくてはならない。

【００６１】VisualEntity４８は、DisplayManager４６
により管理され、視覚表現データ２３、図表現データ２
４の一部を格納する。抽象的なデータを図として表現す
る方法はいくつも考えることができる。例えば、エッジ
に関しては、ノード間の矢印で表現することもできる
し、ノードに対応する長方形領域の包含関係で表現する
こともできる。このため、その実装は動的交換可能なコ
ンポーネントでなくてはならない。

【００６２】ShapeChoiceSet４９は、VisualEntity４８
により管理され、図表現データ２４の一部を格納する。
例えば、ノードを表現するのに長方形を使い、エッジを
表現するのに実直線矢印を使うことも可能であり、ノー
ドを表現するのに楕円を使い、エッジを表現するのに矢
印付きスパイラル曲線を使うことも可能である。このよ
うに、具体的な図表現データ２４のセット（この場合は
ノードとエッジだが、他に表現する要素があればそれら
も含める）を格納する。具体的なセットは、抽象表現デ
ータ２２、視覚表現データ２３やそれらの処理から独立
して、いくつも考えることができるため、その実装は動
的交換可能なコンポーネントでなくてはならない。

【００６３】UserInteraction ５０は、TaskManager ４
１により管理され、ユーザがエディタの各種機能をメニ
ューやキーボード・ショートカットにより使えるように
するためのいわゆるＧＵＩ（Graphical User Interfac
e）である。エディタの基本的な機能は変わらなくて
も、言語（英語、日本語等）や操作体系の違いにより、
様々な実現方法が考えられる。このため、その実装は動
的交換可能なコンポーネントでなくてはならない。

【００６４】前述の実装指針（ＩＣ−１）−（ＩＣ−
６）に基づき、これらのコンポーネントのそれぞれに対
して、Ｊａｖａ言語による一つまたは複数の実装を行っ
た。ここでは、それぞれのコンポーネントについて、
（ＩＣ−１）に基づく実装名を列挙し、その機能、特
徴、依存する他のコンポーネント実装を述べる。

【００６５】ここで、「コンポーネント実装Ａがコンポ
ーネント実装Ｂに依存する」とは、ＡがＢの存在を前提
にしており、Ａを読み込んで働かせるためには、Ｂも読
み込まれていなくてはならないことを意味する。コンポ
ーネント間の管理／被管理関係とは別に、実装同士の間
にそうした依存関係が存在し、依存関係の整合性を保つ
ことは管理コンポーネントの責任である。また、管理／
被管理関係と依存関係とが重複する場合もある。こうし
たコンポーネント実装間の関係は、コンポーネントマネ
ジャ１３により管理されている。

【００６６】まず、TaskManager ４１のコンポーネント
実装としては、次のようなものが用いられる。 ・MixedPizza TaskManager（ＭＰＴＭ） UserInteraction ５０と協調して働き、動的拡張機能の
みを持つアプリケーションを構成する。後述するMixedP
izza EventManager コンポーネント実装に依存する。 ・DirectedGraph TaskManager（ＤＧＴＭ） EventManager４２、DiagramManager４３、LayoutGenera
tion４４、GraphicalEntity ４５、DisplayManager４
６、ViewType４７、VisualEntity４８、ShapeChoiceSet
４９、UserInteraction ５０と協調して働き、グラフ構
造エディタを構成する。後述するDirectedGraph EventM
anagerコンポーネント実装に依存する。MixedPizza Tas
kManagerコンポーネント実装の機能はすべて含む。

【００６７】EventManager４２のコンポーネント実装と
しては、次のようなものが用いられる。 ・MixedPizza EventManager（ＭＰＥＭ） UserInteraction ５０と協調して働き、動的拡張機能の
みを持つアプリケーションを構成する。MixedPizza Tas
kManagerコンポーネント実装に依存する。 ・DirectedGraph EventManager（ＤＧＥＭ） EventManager４２、DiagramManager４３、LayoutGenera
tion４４、GraphicalEntity ４５、DisplayManager４
６、ViewType４７、VisualEntity４８、ShapeChoiceSet
４９、UserInteraction ５０と協調して働き、グラフ構
造エディタを構成する。DirectedGraph TaskManager コ
ンポーネント実装に依存する。MixedPizzaEventManager
コンポーネント実装の機能はすべて含む。

【００６８】DiagramManager４３のコンポーネント実装
としては、次のようなものが用いられる。 ・DirectedGraph DiagramManager（ＤＧＤｇＭ） LayoutGeneration４４、GraphicalEntity ４５と協調し
て働き、抽象的な有向グラフデータの管理と処理を行
う。DirectedGraph TaskManager コンポーネント実装、
DirectedGraph EventManagerコンポーネント実装に依存
する。

【００６９】LayoutGeneration４４のコンポーネント実
装としては、次のようなものが用いられる。 ・Arrange LayoutGeneration（ＡＬＧ） ノードをウィンドウ内に整列配置する。DirectedGraph
DiagramManagerコンポーネント実装に依存する。 ・ConnectEdge LayoutGeneration（ＣＥＬＧ） グラフ的に接続しているノード同士が接続しているよう
に見えるように、エッジ配置を行う。DirectedGraph Di
agramManagerコンポーネント実装に依存する。 ・Scramble LayoutGeneration （ＳｃＬＧ） ノードをかきまぜてウィンドウ内にランダムに配置す
る。DirectedGraph DiagramManagerコンポーネント実装
に依存する。 ・Spring LayoutGeneration （ＳｐＬＧ） スプリング・レイアウト手法により、ノード同士があた
かもエッジで表されるバネによってつながれているかの
ような配置を行い、表示する。DirectedGraphDiagramMa
nagerコンポーネント実装に依存する。

【００７０】GraphicalEntity ４５のコンポーネント実
装としては、次のようなものが用いられる。 ・DirectedGaph GraphicalEntity（ＤＧＧＥ） 抽象的な有向グラフデータの保持・管理を行う。Direct
edGraph DiagramManagerコンポーネント実装と、後述す
るTwoD VisualEntity コンポーネント実装に依存する。

【００７１】DisplayManager４６のコンポーネント実装
としては、次のようなものが用いられる。 ・DirectedGraph DisplayManager（ＤＧＤｐＭ） ViewType４７、VisualEntity４８、ShapeChoiceSet４９
と協調して働き、表示のためのグラフデータ管理・処理
を行う。DirectedGraph TaskManager コンポーネント実
装、DirectedGraph EventManagerコンポーネント実装に
依存する。

【００７２】ViewType４７のコンポーネント実装として
は、次のようなものが用いられる。 ・TwoDPlain ViewType（ＴＰＶＴ） グラフの図データを表示するための２次元領域を提供す
る。DirectedGraph DisplayManagerコンポーネント実装
と、後述するDirectedGraph UserInteractionコンポー
ネント実装に依存する。

【００７３】VisualEntity４８のコンポーネント実装と
しては、次のようなものが用いられる。 ・TwoD VisualEntity （ＴＤＶＥ） グラフを２次元図形として表示するためのデータ構造の
保持・管理を行う。DirectedGraph DisplayManagerコン
ポーネント実装と、DirectedGraph GraphicalEntity コ
ンポーネント実装に依存する。

【００７４】ShapeChoiceSet４９のコンポーネント実装
としては、次のようなものが用いられる。 ・TwoD ShapeChoiceSet （ＴＤＳＣＳ） グラフを２次元図形として表示するための図形描画情報
セットを提供する。TwoD VisualEntity コンポーネント
実装に依存する。

【００７５】UserInteraction ５０のコンポーネント実
装としては、次のようなものが用いられる。 ・DirectedGraph UserInteraction （ＤＧＵＩ） グラフ構造エディタを、ウィンドウシステム内のひとつ
のウィンドウとして実現する。ウィンドウ枠やメニュー
を英語表記で提供する。MixedPizza TaskManagerコンポ
ーネント実装と、MixedPizza EventManager コンポーネ
ント実装に依存する。 ・DGj UserInteraction （ＤＧｊＵＩ） DirectedGraph UserInteraction コンポーネント実装と
同等の機能を持つが、ウィンドウ枠やメニューを日本語
表記で提供する。MixedPizza TaskManagerコンポーネン
ト実装と、MixedPizza EventManager コンポーネント実
装に依存する。図７は、これらのコンポーネント実装の
間の管理／被管理関係と依存関係を示している。ここで
は、TaskManager ４１のコンポーネント実装としてＤＧ
ＴＭを用い、EventManager４２のコンポーネント実装と
してＤＧＥＭを用いている。そして、これらがルート管
理コンポーネントに対応する。また、UserInteraction
５０のコンポーネント実装としてＤＧＵＩを用いてい
る。

【００７６】図７において、太い実線の矢印は、管理コ
ンポーネントのコンポーネント実装から被管理コンポー
ネントのコンポーネント実装に対するメソッドの呼び出
し（Ｓ−２）を表し、破線の矢印は、被管理コンポーネ
ントのコンポーネント実装からルート管理コンポーネン
トのコンポーネント実装に対するメソッドの直接呼び出
し依頼（Ｓ−６）を表す。また、細い実線の矢印（双方
向）は、（Ｓ−３）により実現される特定のコンポーネ
ント実装間の依存関係を表す。

【００７７】次に、図８から図２０までを参照しなが
ら、図３のコンポーネント統合機構ＭＤＭＣＣがアプリ
ケーションに対して提供する各種サービスについて、詳
細に説明する。

【００７８】グラフ構造エディタの各コンポーネント実
装は、ＭＤＭＣＣによって統合されて、動的拡張可能な
アプリケーションとして機能する。ＭＤＭＣＣは、前述
した（Ｓ−１）−（Ｓ−６）のサービスを提供する。

【００７９】図８は、サービス（Ｓ−１）のアプリケー
ション起動処理のフローチャートである。アプリケーシ
ョン起動時には、最初にカーネル１１が処理を開始し、
ＭＤＭＣＣの諸機能を用いて、アプリケーションを構成
する各コンポーネント実装を読み込み、起動していく。
また、図９は、図７のグラフ構造エディタの起動の様子
を示している。図９において、実線の矢印は、メソッド
の呼び出しを表し、破線の矢印は、コンポーネント実装
の読み込みを表す。

【００８０】まず、カーネル１１は、実装マネジャ１２
に指示して、ルート管理コンポーネントのコンポーネン
ト実装を読み込ませ（ステップＳ１１）、メッセージデ
ィストリビュータ１４を通して、それを起動する（ステ
ップＳ１２）。図９の例では、ルート管理コンポーネン
トとしてＤＧＴＭが読み込まれ、起動される。

【００８１】次に、ルート管理コンポーネントのコンポ
ーネント実装が、メッセージディストリビュータ１４を
通して、実装マネジャ１２に指示し、アプリケーション
を構成する残りすべてのコンポーネントについて、デフ
ォルトのコンポーネント実装を読み込ませる（ステップ
Ｓ１３）。

【００８２】ここでは、実装マネジャ１２により、Ｓｐ
ＬＧ、ＣＥＬＧ、ＡＬＧ、ＳｃＬＧのいずれかと、ＤＧ
ＥＭ、ＤＧＤｇＭ、ＤＧＧＥ、ＤＧＤｐＭ、ＤＧＵＩ、
ＴＤＶＥ、ＴＰＶＴ、およびＴＤＳＣＳが読み込まれ
る。

【００８３】次に、実装マネジャ１２が、読み込んだ各
コンポーネント実装をコンポーネントマネジャ１３に通
知する（ステップＳ１４）。そして、ルート管理コンポ
ーネントのコンポーネント実装が他のコンポーネント実
装を起動することで、アプリケーションが起動される
（ステップＳ１５）。ここでは、ステップＳ１３で読み
込まれた各コンポーネント実装が、ＤＧＴＭにより起動
される。

【００８４】次に、図１０は、サービス（Ｓ−２）の被
管理コンポーネントのメソッド呼び出し処理のフローチ
ャートである。この処理は、アプリケーション実装時
に、（ＩＣ−４）に基づいてコーディングされている。
指定されたコンポーネント名に対応するコンポーネント
実装が既に読み込まれていれば、メッセージディストリ
ビュータ１４は、指定されたメソッドをそのコンポーネ
ント実装に実行させる。

【００８５】また、図１１は、図７のグラフ構造エディ
タにおける被管理コンポーネントのメソッド呼び出しの
様子を示している。図１１において、実線の矢印は、メ
ソッドの呼び出しを表し、破線の矢印は、コンポーネン
ト実装の状態調査を表す。コンポーネント実装の状態調
査は、コンポーネントマネジャ１３の管理データに基づ
いて行われる。

【００８６】まず、ある管理コンポーネントのコンポー
ネント実装が、被管理コンポーネントの名前、実行させ
たいメソッド名、およびその引数を指定し、メッセージ
ディストリビュータ１４を通して、コンポーネントマネ
ジャ１３にメソッド呼び出し要求を通知する（ステップ
Ｓ２１）。

【００８７】図１１の例では、管理コンポーネントであ
るＤＧＤｐＭが、被管理コンポーネント名としてViewTy
peを指定し、それに対するメソッド呼び出し要求を、コ
ンポーネントマネジャ１３に通知している。

【００８８】次に、コンポーネントマネジャ１３は、通
知された名前に対応する被管理コンポーネントとして読
み込まれているコンポーネント実装の状態を調査し（ス
テップＳ２２）、そのようなコンポーネント実装へのポ
インタの有無を判定する（ステップＳ２３）。

【００８９】コンポーネント実装へのポインタが取得で
きれば、メッセージディストリビュータ１４を通してそ
のコンポーネント実装を呼び出し、与えられた引数を渡
して、指定されたメソッドを実行させる（ステップＳ２
４）。コンポーネント実装へのポインタが取得できなけ
れば、処理を終了する。

【００９０】ここでは、コンポーネントマネジャ１３
は、ViewTypeに対応するコンポーネント実装であるＴＰ
ＶＴへのポインタを取得し、ＴＰＶＴにメソッド実行が
依頼される。

【００９１】このようなサービス（Ｓ−２）によれば、
コンポーネントへの処理要求は、必ずその管理コンポー
ネントから発行されるため、コンポーネントとその管理
コンポーネントを組にして交換することで、容易に機能
を拡張することができる。ただし、コンポーネントへの
処理要求が発行される毎に、対応するコンポーネント実
装の有無を確認しなければならず、実行効率が多少悪く
なる。

【００９２】そこで、管理コンポーネントが、必要に応
じて、被管理コンポーネントの交換、取り外しを禁止で
きるようなロック機構を設ければ、コンポーネント実装
の有無の確認が不要になり、実行効率が改善される。そ
のために、次に説明する（Ｓ−３）のサービスが提供さ
れる。

【００９３】図１２は、サービス（Ｓ−３）のコンポー
ネント実装のロック処理のフローチャートであり、図１
３は、そのアンロック処理のフローチャートである。こ
れらの処理は、アプリケーション実装時に、（ＩＣ−
５）に基づいてコーディングされている。

【００９４】コンポーネントマネジャ１３は、ロック要
求を受け取ると、対象となる被管理コンポーネントのコ
ンポーネント実装へのポインタと、アプリケーション実
行中に重複なく生成されるロックＩＤとを返す。アンロ
ックは、そのロックＩＤに基づいて行われる。ロック中
は、（Ｓ−４）、（Ｓ−５）のサービス要求があって
も、ロック対象となったコンポーネントの交換、取り外
しは行われない。コンポーネントマネジャ１３は、ロッ
クＩＤを管理するために、各コンポーネント実装のロッ
クキューを保持している。

【００９５】また、図１４は、図７のグラフ構造エディ
タにおけるコンポーネント実装のロック／アンロックの
様子を示している。図１４において、実線の矢印は、メ
ソッドの呼び出しを表し、破線の矢印は、コンポーネン
ト実装の状態調査を表す。

【００９６】図１２のロック処理においては、まず、あ
る管理コンポーネントのコンポーネント実装が、それよ
り下位の階層に属する被管理コンポーネントの名前を指
定して、コンポーネントマネジャ１３にロックを要求す
る（ステップＳ３１）。図１４の例では、管理コンポー
ネントであるＤＧＤｇＭが、被管理コンポーネント名と
してGraphicalEntity を指定し、それをロックする要求
をコンポーネントマネジャ１３に通知している。

【００９７】次に、コンポーネントマネジャ１３は、通
知された名前に対応する被管理コンポーネントとして読
み込まれているコンポーネント実装の状態を調査し（ス
テップＳ３２）、そのようなコンポーネント実装へのポ
インタの有無を判定する（ステップＳ３３）。

【００９８】コンポーネント実装へのポインタが取得で
きれば、対応するロックＩＤを生成し、それをそのコン
ポーネント実装のロックキューに追加しておく（ステッ
プＳ３４）。そして、そのコンポーネント実装へのポイ
ンタとロックＩＤを、要求元の管理コンポーネントに返
す（ステップＳ３５）。コンポーネント実装へのポイン
タが取得できなければ、エラーコードを管理コンポーネ
ントに返して（ステップＳ３６）、処理を終了する。

【００９９】ここでは、コンポーネントマネジャ１３
は、GraphicalEntity に対応するコンポーネント実装で
あるＤＧＧＥへのポインタを取得し、ＤＧＧＥのロック
キューにロックＩＤを格納する。そして、ＤＧＧＥへの
ポインタとロックＩＤを、ＤＧＤｇＭに通知する。こう
して、ＤＧＧＥがロックされる。

【０１００】これ以後、ＤＧＧＥがアンロックされるま
での間、一時的に、ＤＧＧＥが交換されたり、取り外さ
れたりすることは禁止される。したがって、ＤＧＤｇＭ
は、通知されたポインタを用いて、直接、ＤＧＧＥに対
して、１つ以上の処理要求を発行することができる。こ
の場合、サービス（Ｓ−２）のようにメッセージディス
トリビュータ１４やコンポーネントマネジャ１３を通す
必要がなくなるので、実行効率の悪化が防止される。

【０１０１】図１３のアンロック処理においては、ま
ず、管理コンポーネントのコンポーネント実装が、ロッ
クされている被管理コンポーネントの名前とそのロック
ＩＤを指定して、コンポーネントマネジャ１３にアンロ
ックを要求する（ステップＳ４１）。図１４の例では、
管理コンポーネントであるＤＧＤｇＭが、被管理コンポ
ーネント名としてGraphicalEntity を指定し、それをア
ンロックする要求をコンポーネントマネジャ１３に通知
している。

【０１０２】次に、コンポーネントマネジャ１３は、通
知された名前に対応する被管理コンポーネントのコンポ
ーネント実装のロックキューを参照して（ステップＳ４
２）、指定されたロックＩＤがあるかどうかを調査する
（ステップＳ４３）。

【０１０３】指定されたロックＩＤがあれば、それをそ
のロックキューから削除する（ステップＳ４４）。指定
されたロックＩＤがなければ、エラーコードを要求元の
管理コンポーネントに返して（ステップＳ４５）、処理
を終了する。

【０１０４】ここでは、コンポーネントマネジャ１３
は、GraphicalEntity に対応するコンポーネント実装で
あるＤＧＧＥのロックキューを調査し、そのロックキュ
ーから指定されたロックＩＤを削除する。こうして、Ｄ
ＧＧＥがアンロックされる。

【０１０５】次に、図１５は、サービス（Ｓ−４）のコ
ンポーネント実装の交換処理のフローチャートである。
例えば、ユーザが新旧のコンポーネント実装を指定し
て、それらの交換を指示すると、コンポーネントマネジ
ャ１３と実装マネジャ１２が各種チェックを行って、条
件が整えば交換を行う。旧コンポーネント実装が存在し
ない場合は、新コンポーネント実装の読み込みのみを行
う。

【０１０６】新コンポーネント実装が既存の管理コンポ
ーネントで制御できず、新たな管理コンポーネントが必
要な場合は、自動的にサービス（Ｓ−５）を呼び出し
て、管理コンポーネントのコンポーネント実装を交換す
る。こうして、ソフトウェアの不整合状態に陥る危険性
が、自動的に回避される。

【０１０７】また、図１６は、図７のグラフ構造エディ
タにおけるコンポーネント実装の交換の様子を示してい
る。図１６において、実線の矢印は、メソッドの呼び出
しを表し、破線の矢印は、コンポーネント実装の状態調
査と脱着を表す。

【０１０８】まず、ユーザ等の指示にしたがって、交換
を指定されたコンポーネントの管理コンポーネントに対
応するコンポーネント実装が、新旧のコンポーネント実
装を指定して、それらの交換要求を発行する。そして、
メッセージディストリビュータ１４は、その要求をコン
ポーネントマネジャ１３に伝える（ステップＳ５１）。
図１６の例では、管理コンポーネントであるＤＧＤｇＭ
が、被管理コンポーネントであるＳｐＬＧをＡＬＧに交
換する要求を出している。

【０１０９】次に、コンポーネントマネジャ１３は、指
定された旧コンポーネント実装が存在するかどうかを調
査し（ステップＳ５２）、それが既に読み込み済かどう
かを判定する（ステップＳ５３）。ここでは、指定され
た旧コンポーネント実装と互換性のあるものは、旧コン
ポーネント実装と同じものとみなされる。指定された旧
コンポーネント実装が読み込み済であれば、次に、新旧
のコンポーネント実装が所属するコンポーネントを調査
し（ステップＳ５４）、それらの名前を比較する（ステ
ップＳ５５）。

【０１１０】新旧のコンポーネント実装のコンポーネン
ト名が一致すれば、次に、新旧のコンポーネント実装の
名前を比較し、それらが異なっているかどうかを判定す
る（ステップＳ５６）。それらが異なっていれば、実装
マネジャ１２に、旧コンポーネント実装の取り外しを指
示する（ステップＳ５７）。

【０１１１】ここでは、旧コンポーネント実装であるＳ
ｐＬＧと新コンポーネント実装であるＡＬＧの所属する
コンポーネントは、ともにLayoutGenerationであり、Ｓ
ｐＬＧとＡＬＧは異なるコンポーネント実装であるの
で、ＳｐＬＧをＡＬＧに交換する指示が実装マネジャ１
２に送られる。

【０１１２】次に、実装マネジャ１２は、旧コンポーネ
ント実装の状態の調査をコンポーネントマネジャ１３に
依頼して（ステップＳ５８）、それがロックされている
かどうかを判定し（ステップＳ５９）、ロックされてい
なければ、それをアプリケーションから取り外す（ステ
ップＳ６０）。ここでは、ＳｐＬＧはロックされておら
ず、アプリケーションから取り外される。

【０１１３】次に、コンポーネントマネジャ１３は、実
装マネジャ１２に、新コンポーネント実装の読み込みを
指示すると（ステップＳ６１）、実装マネジャ１２は、
新コンポーネント実装の状態の調査をコンポーネントマ
ネジャ１３に依頼し（ステップＳ６２）、新コンポーネ
ント実装が既存の管理コンポーネントのコンポーネント
実装で扱うことができるかどうかを判定する（ステップ
Ｓ６３）。ただし、ルート管理コンポーネントの交換要
求の場合は、この判定において「はい」として処理する
ものとする。

【０１１４】既存の管理コンポーネントのコンポーネン
ト実装で扱うことができれば、新コンポーネント実装を
読み込む（ステップＳ６５）。新コンポーネント実装が
他の管理コンポーネントのコンポーネント実装に依存
し、既存のコンポーネント実装で扱うことができなけれ
ば、（Ｓ−５）の動的拡張サービスの処理を行った後に
（ステップＳ６４）、新コンポーネント実装を読み込む
（ステップＳ６５）。ここでは、ＤＧＤｇＭはＡＬＧを
扱うことができるので、ステップＳ６４の処理を行わず
に、ＡＬＧがアプリケーションに読み込まれる。

【０１１５】ステップＳ５３において、指定された旧コ
ンポーネント実装が読み込み済でなければ、ステップＳ
６１以降の処理が行われ、ステップＳ５５において、両
者のコンポーネント名が一致しなければ、ステップＳ６
４以降の処理が行われる。また、ステップＳ５６におい
て新旧のコンポーネント実装が同一の場合、および、ス
テップＳ５９において旧コンポーネント実装がロックさ
れている場合は、処理を終了する。

【０１１６】次に、図１７は、サービス（Ｓ−５）のア
プリケーションの拡張処理のフローチャートである。ア
プリケーションの拡張においては、新しい種類のコンポ
ーネントを動的にアプリケーションに読み込み、他のコ
ンポーネントと結合して、機能拡張を行う。このとき、
既存の管理コンポーネントを、その新コンポーネントを
扱うことができるコンポーネント実装に交換する。実際
の交換においては、サービス（Ｓ−４）を利用する。

【０１１７】また、図１８は、図７のグラフ構造エディ
タにおけるアプリケーションの拡張の様子を示してい
る。図１８において、実線の矢印は、メソッドの呼び出
しを表し、破線の矢印は、コンポーネント実装の状態調
査と脱着を表す。

【０１１８】まず、ユーザが新たなコンポーネント実装
を指定して、アプリケーションの拡張を要求すると、メ
ッセージディストリビュータ１４は、その要求をカーネ
ル１１に伝える。カーネル１１は、新たなコンポーネン
ト実装に関する調査をコンポーネントマネジャ１３に指
示する。これを受けて、コンポーネントマネジャ１３
は、指定されたコンポーネント実装が存在するかどうか
を調査し（ステップＳ７１）、それが既に読み込み済か
どうかを判定する（ステップＳ７２）。

【０１１９】そのコンポーネント実装が読み込み済でな
ければ、カーネル１１の指示により、ルート管理コンポ
ーネントのコンポーネント実装が、他のコンポーネント
実装の動作を停止する（ステップＳ７３）。図１８の例
では、新たなコンポーネント実装として、ＴＰＶＴの組
み込みが要求され、既存のルート管理コンポーネント
が、被管理コンポーネントのコンポーネント実装を停止
する。

【０１２０】次に、コンポーネントマネジャ１３は、指
定されたコンポーネント実装が所属するコンポーネント
が既存のものかどうかを判定し（ステップＳ７４）、既
存のものでなければ、それを扱うことのできる管理コン
ポーネントのコンポーネント実装を入手する（ステップ
Ｓ７５）。このとき、必要であれば、ルート管理コンポ
ーネントまで遡って、複数の管理コンポーネントのコン
ポーネント実装を入手する。そして、カーネル１１が、
既存の管理コンポーネントを、入手したコンポーネント
実装に交換する（ステップＳ７６）。

【０１２１】ここでは、コンポーネントマネジャ１３
は、ＴＰＶＴが所属するコンポーネントであるViewType
を新たなコンポーネントとみなし、ViewTypeの管理コン
ポーネントであるDisplayManagerのコンポーネント実装
ＤＧＤｐＭを入手する。また、DisplayManagerの管理コ
ンポーネントであるTaskManager のコンポーネント実装
ＤＧＴＭを入手する。そして、これらの管理コンポーネ
ントの既存のコンポーネント実装は、それぞれ、ＤＧＤ
ｐＭとＤＧＴＭに置き換えられる。

【０１２２】次に、管理コンポーネントは、指定された
コンポーネント実装を新コンポーネント実装とし、旧コ
ンポーネント実装は指定せずに、サービス（Ｓ−４）の
処理要求を発行する（ステップＳ７７）。これにより、
図１５の処理が起動され、ステップＳ５３からステップ
Ｓ６１に分岐して、ステップＳ６５で新コンポーネント
実装が読み込まれる。そして、カーネル１１の指示によ
り、ルート管理コンポーネントのコンポーネント実装
が、新コンポーネント実装を含む他のコンポーネント実
装を起動する（ステップＳ７８）。

【０１２３】ここでは、ＤＧＤｐＭからの処理要求によ
り、実装マネジャ１２がＴＰＶＴを読み込む。そして、
ＴＰＶＴは、他のコンポーネント実装と共に、ＤＧＴＭ
により起動される。こうして、アプリケーションにＴＰ
ＶＴの新たな機能が追加される。

【０１２４】ステップＳ７２において、指定されたコン
ポーネント実装が読み込み済であれば処理を終了し、ス
テップＳ７４において、指定されたコンポーネント実装
が所属するコンポーネントが既存のものあれば、ステッ
プＳ７７以降の処理が行われる。

【０１２５】次に、図１９は、サービス（Ｓ−６）のル
ート管理コンポーネントへの直接処理要求のフローチャ
ートである。あるコンポーネントが、被管理コンポーネ
ント以外のコンポーネントの機能を用いる場合、メッセ
ージディストリビュータ１４は、ルート管理コンポーネ
ントに実際の処理を任せる。ルート管理コンポーネント
は、サービス（Ｓ−２）を利用してその処理を遂行す
る。

【０１２６】また、図２０は、図７のグラフ構造エディ
タにおけるルート管理コンポーネントへの直接処理要求
の様子を示している。図２０において、実線の矢印は、
メソッドの呼び出しを表し、破線の矢印は、サービス
（Ｓ−２）の実行を表す。

【０１２７】まず、処理の依頼元のコンポーネント実装
が、他のコンポーネントを必要とする処理の要求を発行
すると（ステップＳ８１）、メッセージディストリビュ
ータ１４がその要求を受け取り、ルート管理コンポーネ
ントに通知する（ステップＳ８２）。図２０の例では、
ＴＤＶＥが、その被管理コンポーネントではないＤＧＧ
Ｅのメソッドを呼び出す要求を発行し、メッセージディ
ストリビュータ１４は、それをルート管理コンポーネン
トであるＤＧＴＭに通知する。このとき、ＴＤＶＥへの
ポインタもＤＧＴＭに通知される。

【０１２８】ルート管理コンポーネントは、要求された
処理を実行するために必要な他の情報があるかどうかを
判定し（ステップＳ８３）、必要な情報があれば、それ
を収集し（ステップＳ８４）、要求された処理を実行す
るための命令列を生成する（ステップＳ８５）。ステッ
プＳ８３において、必要な情報がなければ、ステップＳ
８５以降の処理を行う。ここでは、ＤＧＴＭが、ＤＧＧ
Ｅのメソッド呼び出しのための命令列を生成する。

【０１２９】次に、生成された命令列に、他のコンポー
ネントに実行を依頼すべき処理が含まれているかどうか
を判定する（ステップＳ８６）。そのような処理があれ
ば、ルート管理コンポーネントは、メッセージディスト
リビュータ１４を介して、対応するコンポーネント実装
に処理を依頼し（ステップＳ８７）、ステップＳ８６以
降の処理を繰り返す。ステップＳ８７では、実際の処理
は、図１０のフローチャートにしたがって行われる。そ
して、ステップＳ８６において、他のコンポーネントに
依頼すべき処理がなくなれば、処理を終了する。

【０１３０】ここでは、まず、ＤＧＴＭが、メッセージ
ディストリビュータ１４とコンポーネントマネジャ１３
を介して、ＤＧＧＥのメソッド呼び出しをＤＧＤｇＭに
依頼する。次に、ＤＧＤｇＭが、メッセージディストリ
ビュータ１４とコンポーネントマネジャ１３を介して、
ＤＧＧＥにメソッド実行を要求する。このとき、要求元
であるＴＤＶＥへのポインタもＤＧＧＥに通知される。
これにより、ＤＧＧＥが呼び出されて、要求されたメソ
ッドを実行し、その実行結果がＴＤＶＥに通知される。

【０１３１】このように、サービス（Ｓ−６）を利用す
れば、管理／被管理関係を持たないコンポーネント間に
おいても、メソッド呼び出しを行うことができる。本実
施形態のソフトウェア構築システムは、例えば、図２１
に示すような情報処理装置（コンピュータ）を用いて構
成することができる。図２１の情報処理装置は、ＣＰＵ
（中央処理装置）６１、メモリ６２、入力装置６３、出
力装置６４、外部記憶装置６５、媒体駆動装置６６、お
よびネットワーク接続装置６７を備え、それらはバス６
８により互いに接続されている。

【０１３２】メモリ６２には、処理に用いられるプログ
ラムとデータが格納される。メモリ６２としては、例え
ばＲＯＭ（read only memory）、ＲＡＭ（random acces
s memory）等が用いられる。ＣＰＵ６１は、メモリ６２
を利用してプログラムを実行することにより、必要な処
理を行う。

【０１３３】入力装置６３は、例えば、キーボード、ポ
インティングデバイス、タッチパネル等であり、ユーザ
からの指示や情報の入力に用いられる。出力装置６４
は、例えば、ディスプレイやプリンタ等であり、ユーザ
への問い合わせや処理結果等の出力に用いられる。

【０１３４】外部記憶装置６５は、例えば、磁気ディス
ク装置、光ディスク装置、光磁気ディスク（magneto-op
tical disk）装置等である。この外部記憶装置６５に、
プログラムとデータを保存しておき、必要に応じて、そ
れらをメモリ６２にロードして使用することもできる。

【０１３５】媒体駆動装置６６は、可搬記録媒体６９を
駆動し、その記録内容にアクセスする。可搬記録媒体６
９としては、メモリカード、フロッピーディスク、ＣＤ
−ＲＯＭ（compact disk read only memory ）、光ディ
スク、光磁気ディスク等、任意のコンピュータ読み取り
可能な記録媒体が用いられる。この可搬記録媒体６９に
プログラムとデータを格納しておき、必要に応じて、そ
れらをメモリ６２にロードして使用することもできる。

【０１３６】ネットワーク接続装置６７は、ＬＡＮ（lo
cal area network）等の任意のネットワーク（回線）を
介して他の装置と通信し、通信に伴うデータ変換を行
う。これにより、必要に応じて、プログラムとデータを
外部の装置から受け取り、それらをメモリ６２にロード
して使用することもできる。

【０１３７】図２２は、図２１の情報処理装置にプログ
ラムとデータを供給することのできるコンピュータ読み
取り可能な記録媒体を示している。可搬記録媒体６９や
外部のデータベース７０に保存されたプログラムとデー
タは、メモリ６２にロードされる。そして、ＣＰＵ６１
は、そのデータを用いてそのプログラムを実行し、必要
な処理を行う。

【０１３８】

【発明の効果】本発明によれば、アプリケーションに含
まれる特定の機能単位に関する制御コードがすべて、そ
れを管理する管理用機能単位に集中することになる。し
たがって、動的なソフトウェアの拡張を行う際には、特
定の機能単位と、対応する管理用機能単位とを交換・追
加するだけでよい。

【０１３９】このように、必要最小限の機能単位のみを
交換・追加すれば、拡張に伴う停止時間が短縮され、拡
張に関わらない他の機能単位が処理中のデータを継続し
て利用できる機会が増える。

【０１４０】また、アプリケーション開発の際に、汎用
性の高い統合機構（ＭＤＭＣＣ）を用いることで、新た
に同様の機構を開発する手間が省け、開発効率が改善さ
れる。

【図面の簡単な説明】

【図１】本発明のソフトウェア構築システムの原理図で
ある。

【図２】管理コンポーネントを示す図である。

【図３】コンポーネント統合機構の構成図である。

【図４】グラフデータのパイプライン処理を示す図であ
る。

【図５】グラフデータの表示例を示す図である。

【図６】グラフ構造エディタのアーキテクチャを示す図
である。

【図７】コンポーネント実装間の関係を示す図である。

【図８】アプリケーションの起動のフローチャートであ
る。

【図９】アプリケーションの起動を示す図である。

【図１０】被管理コンポーネントのメソッド呼び出しの
フローチャートである。

【図１１】被管理コンポーネントのメソッド呼び出しを
示す図である。

【図１２】コンポーネント実装のロックのフローチャー
トである。

【図１３】コンポーネント実装のアンロックのフローチ
ャートである。

【図１４】コンポーネント実装のロック・アンロックを
示す図である。

【図１５】コンポーネント実装の交換のフローチャート
である。

【図１６】コンポーネント実装の交換を示す図である。

【図１７】アプリケーションの拡張のフローチャートで
ある。

【図１８】アプリケーションの拡張を示す図である。

【図１９】ルート管理コンポーネントへの直接処理要求
のフローチャートである。

【図２０】ルート管理コンポーネントへの直接処理要求
を示す図である。

【図２１】情報処理装置の構成図である。

【図２２】記録媒体を示す図である。

【符号の説明】

１ 構成手段 ２ 変更手段 ３ 機能単位 ４ 管理用機能単位 ５ ソフトウェア １１ カーネル １２ 実装マネジャ １３ コンポーネントマネジャ １４ メッセージディストリビュータ ２１ 応用表現データ ２２ 抽象表現データ ２３ 視覚表現データ ２４ 図表現データ ２５ 図データ ３１ メニューバー ３２ メッセージ表示領域 ３３ グラフ領域 ４１、４２、４３、４４、４５、４６、４７、４８、４
９、５０ コンポーネント ６１ ＣＰＵ ６２ メモリ ６３ 入力装置 ６４ 出力装置 ６５ 外部記憶装置 ６６ 媒体駆動装置 ６７ ネットワーク接続装置 ６８ バス ６９ 可搬記録媒体 ７０ データベース

Claims (10)

【特許請求の範囲】
1. 【請求項１】 複数の機能単位を組み合わせてソフトウ
   ェアを構築するソフトウェア構築システムであって、 前記複数の機能単位のうち特定の機能単位を使用する処
   理を、少数の管理用機能単位に集中して実装する構成手
   段と、 前記ソフトウェアを変更する際に、前記特定の機能単位
   を含む１つ以上の機能単位の交換または追加を行う変更
   手段とを備えることを特徴とするソフトウェア構築シス
   テム。
2. 【請求項２】 前記ソフトウェアを動的に変更する際
   に、前記複数の機能単位のうち交換されない機能単位が
   処理中のデータを継続して使用する手段をさらに備える
   ことを特徴とする請求項１記載のソフトウェア構築シス
   テム。
3. 【請求項３】 前記変更手段は、前記少数の管理用機能
   単位のうち少なくとも１つと前記特定の機能単位の交換
   または追加を行うことを特徴とする請求項１記載のソフ
   トウェア構築システム。
4. 【請求項４】 前記構成手段は、前記特定の機能単位が
   依存する他の機能単位の情報を管理する機能単位管理手
   段を含み、前記変更手段は、前記ソフトウェアを変更す
   る際に、該特定の機能単位とともに、該特定の機能単位
   が依存する他の機能単位の交換または追加を行うことを
   特徴とする請求項１記載のソフトウェア構築システム。
5. 【請求項５】 前記特定の機能単位の交換または取り外
   しを一時的に禁止する手段をさらに備えることを特徴と
   する請求項１記載のソフトウェア構築システム。
6. 【請求項６】 前記複数の機能単位のうち任意の機能単
   位を下位の機能単位として管理するルート管理機能単位
   を介して、互いに管理関係を持たない２つの機能単位の
   間の処理要求を処理する手段をさらに備えることを特徴
   とする請求項１記載のソフトウェア構築システム。
7. 【請求項７】 前記少数の管理用機能単位は、他の機能
   単位からの処理要求の解析を行う第１の管理用機能単位
   と、該処理要求の解析結果に基づいて、要求された処理
   を実行する第２の管理用機能単位とを含み、前記変更手
   段は、前記ソフトウェアを変更する際に、該第１および
   第２の管理用機能単位のいずれかの交換または追加を行
   うことを特徴とする請求項１記載のソフトウェア構築シ
   ステム。
8. 【請求項８】 複数の機能単位を組み合わせてソフトウ
   ェアを構築するソフトウェア構築システムであって、 前記複数の機能単位の間の処理要求を処理する要求処理
   手段と、 前記複数の機能単位のうち特定の機能単位と、該特定の
   機能単位を使用する処理を集中して実装した少数の管理
   用機能単位との関係を管理する機能単位管理手段と、 前記ソフトウェアを変更する際に、前記特定の機能単位
   を含む１つ以上の機能単位の交換または追加を行う実装
   手段と、 前記要求処理手段、機能単位管理手段、および実装手段
   のうち少なくとも１つ以上を制御する制御手段とを備え
   ることを特徴とするソフトウェア構築システム。
9. 【請求項９】 複数の機能単位を組み合わせてソフトウ
   ェアを構築するコンピュータのためのプログラムを記録
   した記録媒体であって、 前記複数の機能単位のうち特定の機能単位を使用する処
   理を、少数の管理用機能単位に集中して実装する機能
   と、 前記ソフトウェアを変更する際に、前記特定の機能単位
   を含む１つ以上の機能単位の交換または追加を行う機能
   とを前記コンピュータに実現させるためのプログラムを
   記録したコンピュータ読み取り可能な記録媒体。
10. 【請求項１０】 特定の機能単位を使用する処理を、少
    数の管理用機能単位に集中して実装し、 前記特定の機能単位と管理用機能単位を含む複数の機能
    単位を組み合わせて、ソフトウェアを構築し、 前記ソフトウェアを変更する際に、前記特定の機能単位
    を含む１つ以上の機能単位の交換または追加を行うこと
    を特徴とするソフトウェア構築方法。