ソフトウエアライフサイクル管理方法およびソフトウエアライフサイクル管理装置
【課題】 ソフトウエアライフサイクルの管理の効率化が望まれている。
【解決手段】 位相空間レベル処理ブロック１３０は、オブジェクト集合記憶部１９０に格納されたプログラムを位相空間として設計する。接着空間レベル処理ブロック１４０は、複数のプログラムの上に同値関係を設定し、同値関係で対応づけられたプログラムモジュールを接着した接着空間を設計する。セル空間レベル処理ブロック１５０は、モジュールの属性をセルで表現し、セルの次元を設計し、表現レベル処理ブロック１６０は、セルの表現を設計する。ビューレベル処理ブロック１７０は、ソフトウエア開発者もしくは保守者に対するビューを設計する。ホモトピーレベル処理ブロック１１０は、ソフトウエアの開発、試験、および保守に伴う操作によって生じるプログラムの変化をホモトピーとして設計する。
【解決手段】 位相空間レベル処理ブロック１３０は、オブジェクト集合記憶部１９０に格納されたプログラムを位相空間として設計する。接着空間レベル処理ブロック１４０は、複数のプログラムの上に同値関係を設定し、同値関係で対応づけられたプログラムモジュールを接着した接着空間を設計する。セル空間レベル処理ブロック１５０は、モジュールの属性をセルで表現し、セルの次元を設計し、表現レベル処理ブロック１６０は、セルの表現を設計する。ビューレベル処理ブロック１７０は、ソフトウエア開発者もしくは保守者に対するビューを設計する。ホモトピーレベル処理ブロック１１０は、ソフトウエアの開発、試験、および保守に伴う操作によって生じるプログラムの変化をホモトピーとして設計する。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はソフトウエアライフサイクル管理技術、とくに、複数の異なるオブジェクト集合間でデータの一貫性維持、インタフェイスの確定その他の処理をなすことのできるソフトウエアライフサイクル管理装置およびソフトウエアライフサイクル管理方法に関する。
【背景技術】
【０００２】
「ソフトウエア工学」（Software Engineering）という用語は、１９６８年のＮＡＴＯ会議で最初に使われたといわれる。この会議において討議されたソフトウエア設計法、プロジェクト管理、技術者教育、ソフトウエアの価格および流通の４つの項目は、今なお、ソフトウエア工学の中心課題である（非特許文献１参照）。
【０００３】
ソフトウエアライフサイクル管理は、要求分析・仕様、設計、実装、テスト、運用、および保守の各段階からなる。最初の要求分析が甘く、顧客の要求を取りこぼしたり、取り違えたりすると、それ以降のシステム設計、実装に顧客の要求が正しく反映されない。そのため、テストや運用段階で発見された不具合を修正するために、プログラムを改良したり、大規模な変更の場合はシステム設計をやり直すなど、ソフトウエアの保守に大変な時間と労力がかかる。最悪の場合、保守に耐えられないソフトウエアは廃棄されることもあり、最初から開発をやり直すことになる。このように、ソフトウエアの開発プロセスの初期段階において、要求分析に時間と労力を惜しむと、保守段階においてコストがかかり、開発プロセスをトータルでみた場合に、全体のコストが肥大する。
【０００４】
ソフトウエアの伝統的なライフサイクルモデルの一つに、１９７０年に提案されたウォーターフォールモデルがある。ウォーターフォールモデルでは、ソフトウエア製品は、要求分析から始まり、システム設計、プログラム設計、プログラム実装、単体・結合テスト、システムテスト、運用、保守に至るまでシーケンシャルに開発されるものと考え、ソフトウエアの開発のアクティビティをモデル化している。
【０００５】
ウォーターフォールモデルは、直線的な開発モデルであり、ある段階は次の段階を開始する前に完了する必要があり、複数の段階にまたがった繰り返しは想定されない。ウォーターフォールモデルは、最初の段階ですべての要求仕様を明確に定めることを要求し、不確実性に対応することはできない。顧客の要求が仕様の決定後やプログラムの設計段階で変更されても、ウォーターフォールモデルでは新しい要求に柔軟に対応することができない。通常、ソフトウエアは試行錯誤しながら多くの繰り返しを経て開発されるため、繰り返しを前提としない直線的な開発モデルはおよそ現実的ではない。そのため、ウォーターフォールモデルは今日、非常に大規模なソフトウエアの開発モデルとして用いられることはあっても、一般的には利用されていない。これらのよく知られたウォーターフォールモデルの限界は、最近米国で行われたソフトウエアエンジニアリングに関するサーベイにおいても指摘されている（非特許文献２参照）。
【０００６】
情報システム構築は、たとえば大手銀行の統合に伴う統合システムに典型的にみられるように、単一大規模サイト向けから、複数分散大規模サイト向けに加速度的に移行しつつある。ところが、その基盤技術となっている現在のソフトウエア工学、リエンジニアリング技術において、これに対応するための基本的枠組みとしてのエンジニアリングモデルが欠落している。その理由は、統合方法がモデルレベルで欠如しているために、各サイト構築担当のエンジニアが個々にモジュール群を工夫して設計・構築している点にある。このために、モジュール群仕様がサイト毎に自ずと異なる。モジュール群の仕様が相互に開示されれば、再構築も可能であるが、モジュールの数の組み合わせにより指数関数的に再構築システム数が増え、いわゆる「開発工数爆発」が生じる。しかも、実際には、企業機密保持上モジュール群の仕様が開示されない場合のほうが多い。この場合、モジュール間のインタフェイス作成情報が開示されるものの、インタフェイス数も組み合わせにより指数関数的に増加するので、一層「開発工数爆発」の様相が顕著となる。
【非特許文献１】シャリ・ローレンス・プリーガー著，堀内泰輔訳，「ソフトウエア工学 理論と実践」，初版，株式会社ピアソン・エデュケーション，２００１年１１月
【非特許文献２】Philip A. Laplante and Colin J. Neill, "The Demise of the Waterfall Model Is Imminent" and Other Urban Myths, ACM QUEUE (Feb. 2004), Vol.1, No.10, pp.10-15.
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ソフトウエアの効率的な開発と保守を支援するための理論的基礎となるエンジニアリングモデルが欠如しているために、要求分析からシステム設計、実装、テスト、保守に至るまでのソフトウエアライフサイクルのスムーズな流れが滞り、ソフトウエア開発が遅延し、また、運用段階で不測の事態が発生しやすいためリスク管理が難しく、ソフトウエアの保守にかかるコストが増大している。
【０００８】
国内外には、リレーショナル・データベ−ス（ＲＤＢ）モデル、ＥＲモデル、タグによるＸＭＬ、グラフによるＵＭＬなどが研究され応用されているが、大規模分散情報システムを構築する理論的基礎としてはモデル的に完全とはいえず、例えばモジュール間のインタフェイス仕様が、異なるサイト間で統一的に取り扱える理論体系になっていない。したがって、前述の「開発工数爆発」は解決できない。
【０００９】
また、各国において昨今の厳しい経済状況もあり、会社統合が増加の一途をたどっているが、異なる情報システム間で整合性をもって情報処理を自在に行えること、すなわち、情報システムのインターオペラビリティが確保されないため、情報システムの運用と保守の費用が増大している。
【００１０】
大規模システムのコストの半分から２／３は保守費用であると言われており、保守はシステムを導入した企業にとって大きなコスト要因となっている。特に稼働中のシステムに不具合が生じた場合、保守は企業の存続に関わる問題となることもあり、大変なリスクを伴う。ソフトウエアに変更を加えるコストは、その変更が要求仕様の決定段階あるいはシステムやプログラムの設計段階で行われるのであれば、比較的低いが、ソフトウエアが出荷され、運用されてからの変更の場合、コストはとてつもなく大きくなる。したがって、できるだけ早い段階で要求仕様や設計の不具合を見つけ、運用後の変更を少なくする必要がある。また、運用・保守段階での変更は、たとえ一部の変更であっても、他のソフトウエアの部分に影響を与えることもあり、変更は複雑で慎重を要する作業となる。ソフトウエアの保守を効率的に行うことが、ソフトウエアの全体コストを削減する上できわめて重要である。
【００１１】
本発明はこうした背景からなされたものであり、その目的は、ソフトウエア部品のインターオペラビリティを線形モデルとして保証して、ソフトウエアの開発、試験、および保守の自動化を支援することのできるソフトウエアライフサイクル管理技術を提供することにある。
【課題を解決するための手段】
【００１２】
本発明のある態様はソフトウエアライフサイクル管理方法に関する。この方法は、ソフトウエア部品集合間の線形インターオペラビリティを保証するインクリメンタリモジュラな抽象階層モデルを利用して、ソフトウエアの開発工程から試験工程を経て、保守工程に至るまでのライフサイクルを一貫して管理する。
【００１３】
「ソフトウエア部品」は、本装置により自動生成されるソフトウエアを構成する部品であり、ソフトウエアで利用されるデータ、ソフトウエアを構成するプログラムなどを含む。
【００１４】
本発明の別の態様はソフトウエアライフサイクル管理装置に関する。この装置は、ソフトウエア部品集合間の線形インターオペラビリティを保証するインクリメンタリモジュラな抽象階層モデルを利用した、ソフトウエアの開発機能ブロック、試験機能ブロック、および保守機能ブロックを備え、ソフトウエアのライフサイクルを前記抽象階層モデルにもとづいて一貫して管理する。
【００１５】
この装置によれば、複数のソフトウエア部品集合の間で同値関係を規定し、その同値関係を不変量として抽象階層間で継承しながら、各抽象階層において段階的にソフトウエア部品集合の満たすべき仕様を設計することができる。集合レベル、位相空間レベル、接着空間レベル、セル空間レベル、表現レベル、およびビューレベルを通して、同値関係が保証され、最終的にソフトウエアが数学的に整合性のある形で生成される。また、各抽象階層はモジュール化されており、ソフトウエア部品の追加、削除、および修正などを行っても、抽象階層を上下に行き来しながら、インクリメンタルに設計変更することができる。さらに、ソフトウエア部品集合に対してなされる操作をホモトピーとして扱うことにより、ソフトウエア部品集合を変化前の状態と変化後の状態の間で相互に移行させることができ、数学的な整合性を維持しながら、ソフトウエアの部品化、再利用、デバッグなどの開発工程を支援することができる。
【００１６】
この装置によれば、ソフトウエアの試験に関して、開発工程により生成されたソフトウエアが各抽象階層において詳細化された仕様に合致するか否かをテストし、発見された問題に応じていずれかの抽象階層もどって開発工程を繰り返すことができ、抽象階層を利用して効率的な試験工程を支援することができる。さらに、ソフトウエアの保守に関して、運用中のソフトウエアに修正もしくは機能拡張の必要があった場合に、その修正もしくは機能拡張を行うべき抽象階層にもどって開発工程を繰り返すことにより、抽象階層を利用して効率的な保守工程を支援することができる。
【００１７】
なお、以上の構成要素の任意の組み合わせ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラム、データ構造などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１８】
本発明によれば、情報システムのインターオペラビリティを保証し、ソフトウエア開発、試験、および保守を含むソフトウエアライフサイクルの管理の効率化を図ることができる。
【発明を実施するための最良の形態】
【００１９】
以下本発明を好適な実施の形態をもとに説明する。まず、本発明者が提唱するインクリメンタリモジュラな抽象階層（incrementally modular abstraction hierarchy）を説明し、その後、インクリメンタリモジュラな抽象階層を実装した情報処理装置を説明する。
【００２０】
［１］集合論的設計
まず、サイバースペースに構築すべきオブジェクトの集まりを定義することからサイバーワールドの設計を始める。そのような集まりに対してインテリジェントマシンとしてコンピュータを使った自動操作の実行が可能であるためには、各集まりは「集合（set）」でなければならない。なぜなら、コンピュータは集合論的機械として構築されているからである。直観的に、集合Ｘは、同一のプロパティＰ（ｘ）をもったすべてのオブジェクトｘの集まりである。これを記号で表すなら、Ｘ＝｛ｘ｜Ｐ（ｘ）｝である。集合に含まれる任意のオブジェクトを元または要素（element）という。要素をもたない集合を空集合φという。すべての要素が内部（interior）であるならば、その集合は開集合であるという。集合ＸとＹが与えられたとき、コンピュータは、和（union）Ｘ∪Ｙ、積または共通部分（intersection）Ｘ∩Ｙ、差（difference）Ｘ−Ｙ（ｘ＼ｙとも書く）、否定(negation)¬Ｘのような集合論的演算を施す。
【００２１】
最初のサイバースペースとして集合Ｘからサイバースペースアーキテクチャの設計を始めるとしよう。未知のサイバースペースＵのすべての要素ｕが与えられたとき、もしそれらの要素がすべてサイバースペースＸの要素であることが確かめられたならば、その未知のサイバースペースをＸの部分集合、すなわちＸの部分サイバースペースと呼び、Ｕ⊆Ｘと表記する。部分集合であるかどうかは、（∀ｕ）（ｕ∈Ｕ→ｕ∈Ｘ）を処理することで自動的に調べることができる。Ｕの閉包（closure）
【数１】
は、Ｕを含むＸのすべての閉部分集合の積である。言い換えれば、Ｕの閉包は、Ｕの外部（exterior）要素でないＸの要素である。Ｘの部分集合｛Ｕ｜Ｕ⊆Ｘ｝のすべてからなる集合をＸの巾（べき）集合といい、２Ｘと表記する。これはまたＸの離散位相（discrete topology）とも呼ばれる。離散位相はサイバースペースを部分サイバースペースからなるものとして設計する上でたいへん有用である。なお、集合を要素とする集合（いわゆる「集合の集合」）を「集合族」（family of sets）ということがある。Ｘの巾集合は、集合Ｘのすべての部分集合を要素とする集合族である。
【００２２】
［２］位相幾何学的設計
これから、サイバースペースをＸの（複数の）部分サイバースペースとその重複（overlap）の和として設計する作業に入る。このように設計されるサイバースペースは一般に位相（トポロジー）空間（Ｘ，Ｔ）と呼ばれる。ここでＴ⊆２Ｘである。位相空間の設計は次の仕様により自動化される。
１）Ｘ∈Ｔかつφ∈Ｔ；
２）任意の添え字の集合Ｊに対して、
∀ｊ∈Ｊ（Ｕｊ∈Ｔ）→∪ｊ∈ＪＵｊ∈Ｔ；
３）Ｕ，Ｖ∈Ｔ→Ｕ∩Ｖ∈Ｔ．
【００２３】
上記の設計仕様の１）は、空集合と全体集合がＴの要素であること、２）は、Ｔの要素をいくつもってきて和をとってもＴの要素であること、３）は、Ｔの２つの要素の積（共通部分）もＴの要素であることを示している。コンピュータは、Ｘの巾集合２Ｘからこの設計仕様を満たすようにＴを設計する。
【００２４】
Ｔを位相空間（Ｘ，Ｔ）の位相（トポロジー）という。Ｔ１⊂Ｔ２である２つの位相Ｔ１とＴ２が与えられたとき、Ｔ１はＴ２よりも弱いまたは小さいという。逆に、Ｔ２はＴ１よりも強いまたは大きいという。またＴ２はＴ１よりも細かい、あるいはＴ１はＴ２よりも粗いということもある。明らかなように最も強い位相は離散位相すなわち巾集合であり、最も弱い位相は空集合φである。簡単のため、あいまいさが生じないならば、位相空間を表すために（Ｘ，Ｔ）の代わりにＸをしばしば用いる。
【００２５】
２つの位相空間（Ｘ，Ｔ）と（Ｙ，Ｔ'）が与えられたとき、いかにして（Ｘ，Ｔ）と（Ｙ，Ｔ'）が同値であるということができるだろうか。コンピュータを使って、それらの空間が位相幾何学的に同値であることを自動的に検証（validate）するための基準をここに与える。２つの位相空間（Ｘ，Ｔ）と（Ｙ，Ｔ'）は、連続な関数ｆ：（Ｘ，Ｔ）→（Ｙ，Ｔ'）が存在し、かつその逆関数も存在して連続であるならば、トポロジー同値（topologically equivalent）、すなわち同相、同位相または位相同形（homeomorphic）であるという。（Ｘ，Ｔ）が（Ｙ，Ｔ'）と同相であることを
【数２】
と書く。
【００２６】
それでは、関数ｆの連続性はどのように立証することができるか。最初に、∀Ｂ∈Ｔ'，ｆ−１（Ｂ）∈Ｔであることを調べる。ここでｆ−１（Ｂ）はｆによるＢの逆像を意味する。次に、以下が成り立つことを調べる。
Ｂが開である⇔ｆ−１（Ｂ）もまたＸにおいて開である。
【００２７】
［３］関数
関数ｆ：Ｘ→Ｙが与えられたとき、全域関数（total function）と部分関数（partial function）が存在する。関数ｆ：Ｘ→Ｙに対して、∀ｘ∈Ｘ、∃ｆ（ｘ）であるとき、そしてそのときに限り、関数ｆは全域関数であるという。関数ｆ：Ｘ'→Ｙ｜Ｘ'⊇Ｘを部分関数といい、このときｆ（ｘ）は必ずしもあらゆるｘ∈Ｘに対して存在しているとは限らない。
【００２８】
全域関数に対して、３つの基本的なタイプの関係あるいは写像が存在する。
１．単射（injectiveまたはinto）
∀ｘ，ｙ∈Ｘ，ｘ≠ｙ⇒ｆ（ｘ）≠ｆ（ｙ）
言い換えれば、
∀ｘ，ｙ∈Ｘ，ｆ（ｘ）＝ｆ（ｙ）⇒ｘ＝ｙ
２．全射（surjectiveまたはonto）
（∀ｙ∈Ｙ）（∃ｘ∈Ｘ）［ｆ（ｘ）＝ｙ］
３．全単射（bijective）
単射かつ全射であること
【００２９】
［４］同値関係
集合Ｘ上の任意の２項関係Ｒ⊆Ｘ×Ｘに対して、Ｒは、
１）（∀ｘ∈Ｘ）［ｘＲｘ］ならば、反射性があり、
２）（∀ｘ，ｙ∈Ｘ）［ｘＲｙ⇒ｙＲｘ］ならば、対称性があり、
３）（∀ｘ，ｙ，ｚ∈Ｘ）［［ｘＲｙ⇒ｙＲｘ］⇒ｘＲｚ］ならば、推移性があるという。１）〜３）の条件は、それぞれ反射律、対称律、推移律と呼ばれる。
【００３０】
Ｒが反射性、対称性、推移性をもつとき、Ｒを同値関係（equivalence relation）と呼び、〜で表記する。
【００３１】
ｘ∈Ｘが与えられたとき、ｘ／〜＝｛ｙ∈Ｘ：ｘ〜ｙ｝で定義されるＸの部分集合をｘの同値類（equivalent class）と呼ぶ。ここで類（class）は実際には集合を意味するが、伝統的に類（クラス）と呼ばれており、今となっては変更するのは難しい。すべての同値類の集合Ｘ／〜をＸの商空間（quotient space）もしくは等化空間（identification space）という。
Ｘ／〜＝｛ｘ／〜∈２Ｘ｜ｘ∈Ｘ｝⊆２Ｘ
推移律より、各ｘ∈Ｘ、ｘ／〜≠φについて、以下が成り立つ。
【数３】
これは集合Ｘが空でない互いに素の（すなわち共通要素をもたない）同値類に分割される（分解されるともいう）ことを意味する。
【００３２】
一般に、集合Ｘの上に同値関係〜が定義されたとき、あるＸの要素ａに対してａに同値である要素をすべて集めた集合を考えることができる。このＸの部分集合は、ａを代表要素とする同値類であり、［ａ］と表記される。ここで、同値類に含まれる要素のうちどれを取っても、それを代表要素とする同値類は同じ集合になる。すなわち、同値類は代表要素の取り方によらない。同値類が反射律、対称律、および推移律を満たすことより、各同値類は空ではなく、ａの同値類にはａが属し、相異なる同値類には共通の要素がない。したがって、同値類をすべて集めると、それらは互いに交わらず、また全体の和集合はＸに等しくなる。つまり、集合Ｘは同値類の直和（disjoint union）に分割される。この直和分割を集合Ｘの同値関係Ｒに関する類別（classification）といい、同値類全体の集合を集合Ｘの同値関係〜による商集合と呼ぶ。商集合に位相が定義されたものを上記のように商空間という。
【００３３】
簡単な例で説明する。Ｘを有理整数の集合とし、Ｘの要素ｘ、ｙの関係Ｒとして、「ｘ−ｙが偶数である」を考えると、これは同値関係である。集合Ｘをこの同値関係Ｒで類別すれば、集合Ｘは、奇数の同値類と偶数の同値類の直和に分割される。
【００３４】
ユークリッド幾何学において、図形の集合が与えられたとき、合同関係は同値関係であり、図形の集合全体を、商空間として、合同な図形からなる部分集合の直和に分割する。また、相似関係も同値関係であり、図形の集合全体を、商空間として、相似な図形からなる部分集合の直和に分割する。合同関係と相似関係はアフィン変換の例である。群論における対称関係は、図形の集合全体を、商空間として、対称な図形からなる部分集合の直和に分割する。
【００３５】
電子商取引では、「電子商品であること」は同値関係であるが、「電子取引」は半順序（partially ordered）関係であることに留意する。集合Ｘ上の２項関係Ｓは、次の３つの条件を満たすとき、半順序関係である。
１）（∀ｘ∈Ｘ）［ｘＳｘ］（反射律）
２）（∀ｘ，ｙ∈Ｘ）［ｘＳｙ，ｙＳｘ⇒ｘ＝ｙ］（反対称律）
３）（∀ｘ，ｙ，ｚ∈Ｘ）［［ｘＳｙ⇒ｙＳｚ］⇒ｘＳｚ］（推移律）
【００３６】
半順序関係をもつ集合を半順序集合（partially ordered set）と呼び、頭文字を取って、しばしばポセット（poset）ともいう。集合の２つの要素ｘ、ｙがｘＳｙか、ｙＳｘのいずれかであるとき、比較可能であるという。どの２つの要素も比較可能な半順序集合を全順序集合（totally ordered set）という。
【００３７】
電子取引の関係は、売り手と買い手の関係が非対称であり、対称律を満たさず、反対称律を満たすため、半順序関係となる。一方、電子商品であるという関係は、売り手にとっての電子商品は買い手にとっての電子商品でもあるから、対称であり、同値関係となる。
【００３８】
同値関係について強弱を定義することができる。１つの集合Ｘにおける２つの同値関係Ｒ、Ｓについて、ｘＲｙ⇒ｘＳｙであるとき、ＲはＳより強い、ＳはＲより弱いという。また、Ｒによる類別はＳによる類別より細かい、Ｓによる類別はＲによる類別より粗いという。最も強い同値関係は、「同じものである」という同値関係であり、最も弱い同値関係は、Ｘの任意の２つの要素が同値であるとする同値関係である。
【００３９】
［５］商空間（等化空間）
Ｘを位相空間とする。ｆを全射かつ連続な写像であって、各点ｘ∈Ｘを、ｘを含む部分集合である同値類ｘ／〜∈Ｘ／〜に写像する商写像（quotient map）（しばしば等化写像（identification map）とも呼ばれる）であるとする。
ｆ：Ｘ→Ｘ／〜
ここで、既に説明したように、「写像ｆ：Ｘ→Ｙが全射である」とは、
（∀ｙ∈Ｙ）（∃ｘ∈Ｘ）［ｆ（ｘ）＝ｙ］
を意味する。
【００４０】
Ｘの部分集合Ｘ０⊆Ｘに対して、
Ｘ０が開である⇔ｆ−１（Ｘ０）｜ｙ∈ＡがＸにおいて開である（これはｆが連続であることを意味する）
が成り立つような全射写像ｆを考えた場合、Ｘ／〜を商写像（または等化写像）ｆによる商空間（または等化空間）と呼ぶ。商空間が等化空間とも呼ばれる理由がある。それは、既に述べたように、商空間は、各要素である同値類ｘ／〜∈Ｘ／〜を、ｘ／〜に含まれる点ｘ∈Ｘと同一視することにより得られるからである。
【００４１】
［６］接着空間
一般に、集合Ａと集合Ｂに共通の要素がない、すなわちＡ∩Ｂ＝φのとき、ＡとＢは互いに素（mutually disjoint）であるという。互いに素である集合Ａと集合Ｂの和集合Ｃを特に直和（disjoint union）（別名、「排他的論理和」）といい、
【数４】
と表す。逆に集合Ｃは互いに素である２つの集合Ａと集合Ｂに直和分解されるということができる。
【００４２】
さて、位相空間Ｘから始めて、これに別の位相空間Ｙを接着する。図１は、２つの互いに素である位相空間Ｘ、Ｙから接着空間が生成される様子を説明する図である。
【数５】
は、接着写像（attaching map）ｆによってＹをＸに接着（attach）することによって得られる接着空間（attaching space）である。この接着写像ｆは、各点ｙ∈Ｙ０｜Ｙ０⊂Ｙをその像ｆ（ｙ）∈Ｘと同一視することにより同値関係を規定するものである。
【００４３】
接着写像ｆは、ｆ：Ｙ０→Ｘである連続写像である。ただしＹ０⊂Ｙである。このように、接着空間
【数６】
は商空間の一例であり、
【数７】
である。この場合における等化写像（identification map）ｇは、
【数８】
である。すなわち、等化写像ｇは、互いに素である２つの位相空間Ｘ、Ｙの直和
【数９】
を、接着写像ｆによって規定される同値関係による同値類の直和
【数１０】
に写像する。
【００４４】
［７］制限と包含
任意の関数ｇ：Ｙ→Ｚに対して、ｇのＸ（Ｘ⊆Ｙ）への制限（restriction）とは、
【数１１】
である。ここで
ｉ：Ｘ→Ｙは、包含（inclusion）である。すなわち
∀ｘ∈Ｘ，ｉ（ｘ）＝ｘ
である。
【００４５】
［８］連続写像のエクステンションとレトラクション
位相空間Ｘ、Ｙと、部分空間Ａ⊂Ｘに対して、ｆ｜Ａ：Ａ→Ｙを満たす連続写像ｆ：Ｘ→ＹをＡからＸへの写像ｆ｜Ａの連続エクステンション（または単にエクステンション）という。エクステンションは部分関数である。
【００４６】
制限（restriction）ｒは、ｒ：Ｘ→Ａを満たす恒等写像１Ａ：Ａ→Ａの連続エクステンションである。したがって、ｒ｜Ａ＝１Ａである。
【００４７】
Ａ⊂Ｘに対して、
【数１２】
を満たすレトラクション（retraction）ｒ：Ｘ→Ａがあるならば、ＡをＸの変形レトラクト（deformation retract）と呼び、
【数１３】
で表す。
もし、Ａがただ一つの点Ａ＝｛ａ｝⊂Ｘであるならば、Ａはレトラクト可能(retractable)といい、
【数１４】
で表す。
【００４８】
［９］ホモトピー
ホモトピーはエクステンションの一例である。Ｘ、Ｙを位相空間、ｆ，ｇ：Ｘ→Ｙを連続写像、Ｉ＝［０，１］とする。ホモトピーは、次のように設計される。
Ｈ：Ｘ×Ｉ→Ｙ
ただし、ｔ∈Ｉに対して、
ｔ＝０のとき、Ｈ＝ｆ
ｔ＝１のとき、Ｈ＝ｇ
が成り立つ。このとき、ｆはｇにホモトピックであるという。
【００４９】
ホモトピーは連続写像のエクステンションであり、
Ｈ｜Ｘ×｛０｝＝ｆｉ０
Ｈ｜Ｘ×｛１｝＝ｇｉ１
ここで
ｉ０＝Ｘ×｛０｝→Ｘ
ｉ１＝Ｘ×｛１｝→Ｘ
【００５０】
さて、ホモトピーレベルにおける位相空間の設計について述べる。２つの位相空間ＸとＹがホモトピー同値（homotopically equivalent）
【数１５】
である、すなわち同じホモトピー型をもつように設計する。それは、次の条件が満たされるように設計することでなされる。
【００５１】
２つの連続写像ｆ：Ｘ→Ｙおよびｈ：Ｙ→Ｘに対して、
【数１６】
である。ここで１Ｘおよび１Ｙは恒等写像、すなわち１Ｘ：Ｘ→Ｘ、１Ｙ：Ｙ→Ｙである。
【００５２】
ホモトピー同値も同値関係の一例であるが、ホモトピー同値はトポロジー同値よりも広い概念である。ホモトピー同値は、変化の後、位相幾何学的にはもはや同値ではなくなる情報の変化を同定することができる。情報はいろいろな操作や処理により変化するが、その操作および処理はホモトピーによって指定され、情報の変化はホモトピー同値によって検証される。事実、不変性（invariance）という抽象の観点からは、ホモトピー同値は集合論的同値よりも抽象性が高い。なぜなら、与えられた集合を要素の追加や削除によって変化させるとき、追加や削除の操作手順と追加もしくは削除された要素を保存することにより、集合をホモトピー同値にすることができるからである。また、後述のセル分解もホモトピー同値になるように行うことにより、セル分解を逆にたどって分解前の状態に戻すことが可能になる。
【００５３】
［１０］セル構造空間（セル空間）設計
セル（cell）は任意の次元（たとえばｎ次元、ただしｎは自然数）の閉球（閉のｎセルと呼ぶ）とトポロジー同値（すなわち同相）である位相空間Ｘである。
【００５４】
閉のｎセル（closed n-cell）を
【数１７】
と表記する。
【００５５】
開のｎセル（open n-cell）を
【数１８】
と表記する（しばしばｅｎとも書かれる）。
【００５６】
閉のｎセル
【数１９】
は、ｎ次元閉球体（closed n-dimensional ball）である。ここで
【数２０】
はｎ次元の実数である。
【００５７】
開のｎセル
【数２１】
は、ｎ次元開球体（open n-dimensional ball）であり、ｎ次元閉球体
【数２２】
の内部である。
【数２３】
は、閉のｎセルの境界であり、これは（ｎ−１）次元球面（sphere）Ｓｎ−１である。
【００５８】
位相空間Ｘに対して、特性写像（characteristic map）
【数２４】
は、連続関数
【数２５】
であり、次を満たす。
【数２６】
【００５９】
【数２７】
は、開のｎセルであり、
【数２８】
は、閉のｎセルである。
【００６０】
位相空間Ｘから、整数集合Ｚによってインデックスが与えられた、Ｘの部分空間であるセルＸｐの有限または無限の系列｛Ｘｐ｜Ｘｐ⊆Ｘ，ｐ∈Ｚ｝を構成することができる。これは、フィルトレーション（filtration）と呼ばれ、次の条件を満たす。ＸｐはＸの被覆（covering）、すなわちＸ＝∪ｐ∈ＺＸｐであり、かつ、Ｘｐ−１はＸｐの部分空間、すなわちＸ０⊆Ｘ１⊆Ｘ２⊆…⊆Ｘｐ−１⊆Ｘｐ⊆…⊆Ｘ（これはスケルトン（skeleton）と呼ばれる）である。最大ｐ次元のスケルトンはｐ−スケルトンと呼ばれる。
【００６１】
Ｃ＝｛Ｘｐ｜ＸＰ⊂Ｘ，ｐ∈Ｚ｝を位相空間Ｘのセル分解（cell decomposition）、あるいは、位相空間Ｘの、閉セルである部分空間Ｘｐへの分割（partition）という。（Ｘ，Ｃ）はＣＷ複体（CW-complex）と呼ばれる。
【００６２】
セル接着写像を保存しながらセル分解を行うとき、セル空間を再利用可能な資源に変えることができる。そのような保存され、共有された情報をセルデータベース（cellular database）と名付け、セルデータベースを管理するシステムをセルデータベース管理システム（cellular database management system または cellular DBMS）と名付ける。
【００６３】
より正確には、J. H. C. Whitehead, "Algebraic Homotopy Theory", Proceedings of International Congress of Mathematics, II, Harvard University Press, pp. 354-357, 1950によれば、位相空間Ｘが与えられたとき、スケルトンＸ０⊆Ｘ１⊆Ｘ２⊆…⊆Ｘｐ−１⊆Ｘｐ⊆…⊆ＸをもったフィルトレーションＸｐを以下の条件を満たす位相空間として帰納的に構成することができる。
（１）Ｘ０⊂Ｘは、その要素がＸの０次元セルである部分空間であり、かつ
（２）ＸｐはＸｐ−１から次のようにして作られる。すなわち、Ｘｐは、接着写像と呼ばれる全射かつ連続な写像
【数２９】
によって、Ｘｐ−１にｐ次元閉球体の直和（disjoint union）
【数３０】
を接着することによって作られる。
【００６４】
言い換えれば、Ｘｐは、直和
【数３１】
を求め、
【数３２】
における各点ｘ、すなわち
【数３３】
を、連続写像
【数３４】
（ただし、各インデックスｉに対してｘ〜ｆｉ（ｘ）である）
によって、その像
【数３５】
と同一視（identify）することによって、Ｘｐ−１から構成される。
【００６５】
このように、Ｘｐは商空間（quotient space）あるいは等化空間（identification space）であり、
【数３６】
と書くことができ、これは、接着空間の一例である。写像Ｆｉはセル
【数３７】
の接着写像の一例である。
【００６６】
フィルトレーション空間（filtration space）は、フィルトレーションとホモトピー同値な（homotopically equivalent）空間である。位相空間ＸとスケルトンＸ０⊆Ｘ１⊆Ｘ２⊆…⊆Ｘｐ−１⊆Ｘｐ⊆…⊆Ｘを合わせてＣＷ空間（CW-space）と呼ぶ。セル複体としては、先に説明したように、これはＣＷ複体（CW-complex）と呼ばれる。
【００６７】
このようにして、写像
【数３８】
を等化写像（identification map）の一例として得る。
【数３９】
【００６８】
各ｎセル
【数４０】
に対する特性写像（characteristic map）
【数４１】
は、
【数４２】
と書ける。
【００６９】
Ｘｐ−１をＸｐの閉の部分空間として埋め込むことは
【数４３】
と書ける。
【００７０】
ＣＷ空間が微分同相（diffeomorphic）であるなら、これは多様体（manifold）空間と等価である。
【００７１】
サイバースペースに構築されるオブジェクトの属性をこのようなセルで表現した空間をセル構造空間（cellular structured space）もしくは単にセル空間（cellular space）という。セルモデリングでは、セルの次元を維持しながら、セル構築（composition）とセル分解（decomposition）が可能である。
【００７２】
セルの次元の例を述べる。たとえばサイバーワールドにおいて、ひとつの属性をもつオブジェクトは、ひとつの属性から他の属性へ移行することができないため、その自由度は０であり、したがってセルの次元は０である。このオブジェクトは、表現レベル（representation level）では点として表される。ここで、属性（attribute）とは、オブジェクトが本来有する特質や特徴を指定するための互いに独立な集合をいう。
【００７３】
属性をふたつ有するオブジェクトでは、一方の属性から他方の属性への移行が可能なため、その自由度は１であり、セルの次元も１である。このオブジェクトは、表現レベルにおいて直線として表すことができる。同様に、属性を３個または４個もつオブジェクトは、それぞれ自由度すなわち次元が２または３であり、それぞれ曲面または球として表現できる。一般に、ｎ個の属性を有するオブジェクトはｎ−１の自由度を有し、次元はｎ−１である。これは、（ｎ−１）次元の球として表現できる。リレーショナルモデルは、ｎ個の属性をもつオブジェクトをリレーショナルスキーマとして表現し、そのインスタンスとしてｎ列のテーブルを生成する。リレーショナルモデルは集合の直積にもとづくものであり、したがってそれは集合論レベルにおける表現といえる。
【００７４】
セル空間は、接着空間に次元の概念を加えたものであり、セル空間設計では、接着空間におけるオブジェクトの属性の次元が規定される。同値類の直和である接着空間において、各同値類に含まれるオブジェクトの属性の次元に不整合がある場合、オブジェクトの属性の次元を調整する処理が行われる。
【００７５】
［１１］表現設計
セル空間レベルでセルの次元が設計された後、表現レベルにおいてセルの表現（presentation）が設計される。表現設計では、オブジェクトの属性のデータ型や桁数などの表現形式が詳細化される。オブジェクトの属性の表現形式に不整合がある場合、表現形式を受容表現（Admissible Representation）に合わせる処理が行われる。オブジェクトの属性の表現形式の不整合には、たとえば、データ型または桁数の違いがあり、データ型変換や桁数変換により、その違いを解消することができる。
【００７６】
［１２］ビュー設計
表現レベルでセルの属性の表現形式が詳細化された後、ビュー（view）、すなわちユーザが見ることのできる範囲が決められる。ユーザは、オブジェクトの集合のうち、関心のある部分だけを適当な形式で見たいという要求がある。また、セキュリティ上の理由などによりユーザが参照することのできる範囲を制限しなければならない。そのため、ビュー設計では、ユーザ向けに参照可能なオブジェクトの部分集合や、閲覧可能なオブジェクトの属性を制限したビューが決められる。
【００７７】
［１３］インクリメンタリモジュラな抽象階層
これまで述べてきたホモトピー、集合、位相空間、接着空間、セル空間、表現、ビューの各抽象レベルは、インクリメンタリモジュラな抽象階層（incrementally modular abstraction hierarchy）を形成する。
１．ホモトピーレベル
２．集合論レベル
３．位相空間レベル
４．接着空間レベル
５．セル空間レベル
６．表現レベル
７．ビューレベル
【００７８】
これらの階層は、モジュール化されており、各階層においてインクリメンタルに情報を操作していくことが可能であり、サイバーワールドの不変量（invariant）を示す同値関係を階層的に継承する上できわめて有用である。
【００７９】
まず、複数のオブジェクト集合の特定の要素について同値にする対象が選ばれる。次に、オブジェクト集合に位相が規定され、位相空間において同値関係が規定されることにより、複数のオブジェクト集合は、同値類の直和である接着空間として設計される。さらに、セル空間において同値セルとそれ以外のセルにセル分解されることにより、セル空間レベルまで同値関係が継承される。
【００８０】
さらには、受容表現にもとづいてセルの表現形式を規定することにより表現レベルまで同値関係が継承され、最後にユーザのビューが規定されることによりビューレベルまで同値関係が継承される。表現レベルの１つのインスタンスとして、受容表現を規定するための受容表現レベルを設けておけば、オブジェクトを表現レベルで同値にすることができる。
【００８１】
このようにインクリメンタリモジュラな抽象階層モデルでは、同値関係を抽象階層間で継承しながら、オブジェクトの満たすべき仕様を各階層において設計するため、情報の追加、削除、修正をインクリメンタルに行いながら、抽象階層間を行き来してオブジェクトの仕様を詳細化できる。また、こうして設計されたオブジェクトは再利用可能な形で部品化することができる。
【００８２】
集合Ｘの部分集合からなる集合Ｓにおいて、Ｓに属するすべての集合の和集合がＸに等しいとき、Ｓを集合Ｘの被覆（covering）という。ｎ個の情報システムの統合を行うとき、「経営上の業務統合決定」は、インクリメンタリモジュラな抽象階層の上で、ｎ個の集合の被覆を作ることの決定がなされたことに相当する。ここで、業務は別々の機関のものであってもかまわない。ｎ個の集合は一般には重なりがある。たとえば、複数の業務に同じ社員が参加することなどがあるからである。このｎ個の集合の被覆が、インクリメンタリモジュラな抽象階層間で継承されることにより、業務統合が実装される。言い換えれば、ホモトピーレベル、位相空間レベル、接着空間レベル、セル空間レベル、表現レベル、およびビューレベルのそれぞれで業務の被覆が生成されることが、業務統合になる。いったん被覆が生成されると、ｎ個の情報システムの間の統合および操作は、インクリメンタリモジュラな抽象階層の上ですべて被覆を通して行われる。その結果、ｎ個の情報システムの間の統合および操作は、いずれも線形になる。このように、インクリメンタリモジュラな抽象階層によれば、ｎ個の情報システムの間で被覆という線形インタフェイスを構成して線形インターオペラビリティを実現することができる。
【００８３】
また、インクリメンタリモジュラな抽象階層モデルにおける位相空間は、ハウスドルフ空間（Hausdorff space）すなわちＴ２位相空間に限られない。Ｔ２位相空間では、分離公理により、異なる２点が開集合で分離できるが、異なる２点を開集合で分離することのできないＴ０位相空間やＴ１位相空間であっても、同様に接着空間が設計できることに留意する。したがって、抽象階層モデルは、非常に汎用性が高いものである。
【００８４】
接着空間は、主要な企業や公的機関で用いられている有力な商用の情報システムに共通した特性を接着空間という形で異なる情報システム間で同値になるように抽象化し、モデル構築する。このように、接着空間は、異種情報システムを線形統合することのできる斬新な情報モデルであり、統合作業量の組み合わせ爆発を避けることに大いに貢献する。接着空間レベルにおける線形統合後の線形インタフェイス生成の自動化のために、上記のインクリメンタリモジュラな抽象階層が用いられる。この抽象階層によれば、同値関係が下位の階層まで継承されるため、既存の情報システムに対するインタフェイスを与えて、統合システム規模のタスクを実行するための線形インターオペラビリティを実現することができる。
【００８５】
比較のために、リレーショナルデータベースシステムを例に挙げて説明する。リレーショナルデータベースシステムにおいて、リレーションはタップルの集合である。リレーションに新たなタップルが挿入されたり、既にあるタップルが削除されたり、タップルの属性値が修正されることにより、リレーションは時間とともに変化していく。たとえば、リレーションとして「社員（社員番号，氏名，所属，入社年度）」を考える。新しい社員が入社した場合、リレーション「社員」にその社員を表すタップルを挿入しなければならない。一方、ある社員が退職すると、リレーション「社員」にその社員を表しているタップルを削除しなければならない。また、配置換えにより、ある社員の配属先が変わった場合、その社員のタップルにおいて属性「所属」の値を修正しなければならない。
【００８６】
このように、リレーショナルデータバースでは、タップルの挿入、削除、修正により、リレーションが時間とともに変化していく。しかしながら、リレーションには、社員の社員番号、氏名、所属、入社年度のデータを表しているという固有の性質があり、これは時間に対して不変である。リレーションにはこのように時間に対して不変な構造があり、これをリレーションスキーマと呼んでいる。
【００８７】
リレーショナルデータベースモデルは、集合論にもとづくものであるから、位相空間のレベルで同値関係を定義することができない。したがって、複数の異なるデータベースを統合しようとすると、ＩＤのつけなおしなど、データベースの再設計を行う必要があり、工数爆発の問題が起こる。それに対して、インクリメンタリモジュラな抽象階層モデルでは、上位概念で規定された同値関係を表現レベルまで落とし込むことができるため、複数の異なる情報システムの統合が線形操作で可能となる。すなわち情報システムの各要素のインタフェイスは、接着空間に一回変換するだけでとることができ、ｎ要素でｎ回の変換でインターオペラビリティが保証され、インタフェイスの数は線形である。
【００８８】
このように、本発明の抽象階層モデルに対して、従来のリレーショナルモデルは、同値関係をモデル化していないため、情報の統一的な扱いができない。せいぜい、テーブル間の関係を示す別テーブルを、パッチを当てる要領で設けてインタフェイスをとろうとしているが、これではインタフェイスの数が指数関数的に増える。一方、ＥＲ（Entity Relation）モデルを基本とするＳＡＰ、ＵＭＬ(Unified Modeling Language)なども、これらはすべて直観的なグラフ理論モデルであり、そのモデル自身が同値関係を扱うことができないため、同様の問題が起こる。これが社会基盤情報システムの現状であり、システムが明確なインターオペラビリティをもたないことが大きな問題となっている。
【００８９】
［１４］応用例
［１４．１］Ｗｅｂ情報モデリング
通常、Ｗｅｂ情報マネージメントシステムのやるべき仕事は、Ｗｅｂグラフィックスを用いて情報を可視化することを通して、人間の認識との間で非常に近い相互作用をもちながら、Ｗｅｂ上の情報を管理することである。Ｗｅｂグラフィックスの仕事は、人間の理解のためにグラフィックススクリーンにいろいろなイメージを投影することである。人間は、ディスプレイ空間に表示されたイメージを人間の認識空間における認識対象物にリンクすることによって、表示されたイメージを理解している。しばしば、幾何学的に正確な表示であっても、サイバーワールドでは通常は本質的な情報ではない、優先度の低い幾何学的形状によって、人間の認識を誤りに導くことがある。Ｗｅｂ情報マネージメントに対してＷｅｂグラフィックスは、サイバーワールドの変化に合った速度で、人間が即座に認識できるようにスクリーン上に重要なメッセージを伝えることができなければならない。以下、簡単な例を挙げて説明する。
【００９０】
［１４．２］エレクトロニックファイナンスのＷｅｂ情報モデリング
エレクトロニックファイナンスにおいて、顧客Ｘが、Ｗｅｂサーフィンしているときに、金融取引会社ＹのホームページのＷｅｂページに投稿されている収益の期待できるファンドＹ０を見つけたとする。この時点では、顧客ＸはＷｅｂで「ウインドウショッピング」をしている段階であるから、顧客Ｘと取引会社Ｙはファンドをまだ共有していない。したがって、ＸとＹは互いに素であり、共通要素を持たない。すなわち、
【数４４】
と表記することができる。一般化のために、ＸとＹを位相空間とする。ファンドＹ０は金融取引会社Ｙの属性の一部であるから、Ｙ０⊂Ｙが成り立つ。図２は、Ｗｅｂ上のエレクトロニックファイナンスのプロセスをＷｅｂグラフィックスにおいて図示したものである。次に、ファンドが取引のために特定された後、顧客Ｘは取引会社Ｙとどのようにして関係づけられるかを述べる。ここで提案するＷｅｂ情報モデルは、顧客Ｘと取引会社Ｙの関係を接着写像ｆによって正確に表現し、また、「ファンドＹ０が取引のために特定されている」という状況を２つの互いに素である位相空間Ｘ（顧客）と位相空間Ｙ（金融取引会社）の接着空間として表現する。この接着空間は、顧客Ｘから始めて、金融取引会社Ｙを顧客Ｘに接着することにより得られる。ここで、ＹのＸへの接着は、連続写像ｆを介して、各点ｙ∈Ｙ０｜Ｙ０⊆Ｙをその像ｆ（ｙ）∈Ｘと同一視することによって行われ、その結果、ｘ〜ｆ（ｙ）｜∀ｙ∈Ｙ０である。このように、〜で表記される同値は、Ｗｅｂ情報の接着空間モデルとして接着空間を作成するために、Ｗｅｂ情報モデリングにおいて中心的な役割を果たす。
【００９１】
上記の接着空間モデルは、エレクトロニックマニュファクチャリングにおいてもまったく本質的に等しく適用することができる。エレクトロニックマニュファクチャリングプロセスを管理し、表示するために正確に同一の技術が要求される。エレクトロニックマニュファクチャリングが市場の需要に効果的に即応するためには、いかにしていろいろなサイズのコンポーネントを統一したデザインで組み立てるかを指定しなければならない。先に提示したエレクトロニックファイナンスは、顧客と取引会社をエレクトロニックマニュファクチャリングのコンポーネントとして組み立てることであると考えることにより、エレクトロニックファイナンスのためのＷｅｂ情報マネージメントシステムとＷｅｂグラフィックスは、実際にエレクトロニックマニュファクチャリングに適用可能となる。もし、異なるアプリケーションに異なる技術を使うとなると、急成長しているサイバーワールドは、タイムリーにＷｅｂ情報マネージメントシステムで管理することも、Ｗｅｂグラフィックスで表示することもできなくなる。
【００９２】
［１４．３］エレクトロニックマニュファクチャリングのＷｅｂ情報モデリング
接着空間モデルによるエレクトロニックマニュファクチャリングのＷｅｂ情報モデリングはまったく簡単である。基本的には、エレクトロニックマニュファクチャリングと呼ばれるＷｅｂ上のマニュファクチャリングは、エレクトロニックマニュファクチャリングの工程に関する次の情報からなるＷｅｂ情報としてモデル化される。
１）製品仕様
２）組み立て仕様
３）Ｗｅｂ上での部品購入
４）Ｗｅｂ上の組み立てサイトでの購入
【００９３】
各ステップは、必要に応じてより細かいサブステップに分解される。たとえば、ステップ１は次のサブステップに分解できる。
１．１）電子市場での製品のマーケット調査
１．２）マーケット調査から導き出される製品の要求
１．３）要求を満たすための製品の仕様
【００９４】
エレクトロニックマニュファクチャリングのためのＷｅｂ技術全体の中で核となる部分は、Ｗｅｂ情報モデリングとしてのＷｅｂ上での製品と組み立てのモデリングである。図３は、座席と支持部という２つのコンポーネントをもつ椅子の単純な組み立て例を用いて、最も初歩的な組み立てのモデリングを明確に図示したものである。発展したマニュファクチャリングとしてのエレクトロニックマニュファクチャリングにおいて、製品のコンポーネントは、モジュール化されており、より品質の高いコンポーネントを買うため、最も有効なアップグレードを行うため、あるいは修理するために置き換え可能に構成されている。
【００９５】
エレクトロニックファイナンスとエレクトロニックマニュファクチャリングが接着空間と同値にもとづいて同一の情報モデリングを共有することは明らかである。
【００９６】
［１５］実施例
図４は、実施の形態に係るソフトウエア開発支援装置１００の構成を示す。オブジェクト集合記憶部１９０は、ソフトウエア開発に利用されるオブジェクトの集まりを保持する。ソフトウエア開発に利用されるオブジェクトすなわちソフトウエア部品は、データ構造体やプログラムモジュールである。ソフトウエア開発支援装置１００は、オブジェクト集合記憶部１９０に格納されたオブジェクトの集まりを参照する。ソフトウエア開発支援装置１００は、オブジェクト集合記憶部１９０を介さずに、ウェブ上の情報システムからオブジェクト集合を取得して参照してもよい。以下、実施の形態では、説明の便宜上、２つのオブジェクト集合の間に所定の対応関係またはインタフェイスを定義する場合を説明するが、これはより一般的に複数のオブジェクト集合を参照してそれらの間にインタフェイスを定義する場合の一例に過ぎない。
【００９７】
ソフトウエア開発支援装置１００は、ホモトピーレベル処理ブロック１１０、集合レベル処理ブロック１２０、位相空間レベル処理ブロック１３０、接着空間レベル処理ブロック１４０、セル空間レベル処理ブロック１５０、表現レベル処理ブロック１６０、およびビューレベル処理ブロック１７０を含み、それぞれ既に述べたインクリメンタリモジュラな抽象階層モデルにおける各階層レベルの処理を行う。
【００９８】
集合レベル処理ブロック１２０は、オブジェクト集合記憶部１９０に格納されたオブジェクトの集まりに集合演算を適宜施して、設計対象となる２つのオブジェクト集合を特定する。位相空間レベル処理ブロック１３０は、集合レベル処理ブロック１２０が特定した２つのオブジェクト集合に対して位相を規定することで、２つのオブジェクト集合はそれぞれ位相空間Ｘ、Ｙとして設計する。この時点で２つの位相空間Ｘ、Ｙは互いに素であり、これらの位相空間Ｘ、Ｙの直和あるいは排他的論理和である
【数４５】
が確定する。
【００９９】
接着空間レベル処理ブロック１４０は、図５にその詳細な構成を示すように、同値関係設定部４４、同値関係保持部５２、対応要素抽出部２０、接着写像取得部２２、等化写像取得部２４、手順取得部２６、および手順記録部２８を含む。
【０１００】
同値関係設定部４４は、２つのオブジェクト集合に適用したい同値関係の入力をユーザから受け付ける他、ユーザの入力をもとにして自動的に同値関係を生成する。ユーザが同値関係を設定しやすいように、同値関係保持部５２は同値関係の候補があらかじめ格納されている。また、ユーザがオブジェクト集合の要素を指定して同値関係を記述することのできるインタフェイスを設けてもよい。
【０１０１】
同値関係設定部４４により設定された同値関係（以下、目的同値関係ともいう）は、対応要素抽出部２０へ伝えられる。対応要素抽出部２０は、２つのオブジェクト集合において対応関係を定義すべき構成要素（以下、「対象要素」ともいう）を、目的同値関係をもとに抽出する。その際、ユーザが１つのオブジェクト集合において対象要素の一方を指定し、対応要素抽出部２０が目的同値関係をもとに他方のオブジェクト集合から対応する対象要素を抽出するようにしてもよい。
【０１０２】
対応要素抽出部２０により対応しあうことが判明した対象要素は、ひとつの部分位相空間、すなわち同値類を形成し、接着空間モデルの理論的保証により、同値類の排他的論理和として接着空間が形成される。同値類は同値関係で規定される不変量をもとに分類されるため、オブジェクト集合を客観的に分類することができ、分類の結果にはシステム設計者による個人差が含まれない。また、一方の対象要素を決めると、他方の対象要素が決まるため、前述のごとく、対応関係またはインタフェイスの数が線形になり、インターオペラビリティが保証されることになる。
【０１０３】
目的同値関係が決まると、対象要素間がどのような意味において対応するか、その関係も一意に決まる。そのため、接着写像取得部２２は対象要素間の対応を示す接着写像ｆを特定することができる。接着写像ｆが決まると、接着空間も、
【数４６】
と定まる。接着空間は、もとは共通部分をもたない位相空間ＸとＹの間に、接着写像ｆを媒介として対応関係を持たせた位相空間である。
【０１０４】
等化写像取得部２４は、位相空間ＸとＹの単なる排他的論理和の空間から、接着写像ｆによって定まる接着空間への写像である等化写像ｇを取得する。等化写像ｇは、現実には、その定義から位相空間Ｘ、Ｙおよび接着写像ｆによって記述することができる。
【０１０５】
手順取得部２６は、同値関係設定部４４から目的同値関係、対応要素抽出部２０から対象要素、接着写像取得部２２から接着写像ｆ、等化写像取得部２４から等化写像ｇの入力を受け、ユーザにより指定された対象要素および目的同値関係（以下、これらを「注目手順」ともいう）をホモトピーとして、一連の処理の結果で特定される、
・位相空間Ｘ、Ｙ
・目的同値関係
・接着写像ｆ
・等化写像ｇ
と関連づけて手順記録部２８へ記録する。
【０１０６】
セル空間レベル処理ブロック１５０は、図６にその詳細な構成を示すように、セル接合部６２、セル次元調整部６４、および対応テーブル保持部６６を含む。セル空間レベル処理ブロック１５０は、接着空間レベル処理ブロック１４０において目的同値関係をもとに接着空間として設計された複数のオブジェクト集合の仕様を継承して、セル空間レベルでオブジェクト集合の仕様を詳細化する。セル構造空間モデルは、接着空間モデルに次元を導入したものであり、オブジェクトの属性のＩＤや属性の個数に関する仕様がセル空間レベルで詳細化されることになる。
【０１０７】
セル接合部６２は、２つのオブジェクト集合間で目的同値関係により対応関係にある２つの対象要素を接合し、各オブジェクト集合に属するオブジェクトの属性をセルで表現する。セル次元調整部６４は、対応する２つの対象要素間に属性の次元に関する不整合がある場合、その不整合を解消するための処理を行う。セルの次元に関する不整合として、対象要素の属性のＩＤや個数の違いなどがある。セル次元調整部６４は、必要に応じて、２つの対象要素間で属性のＩＤや属性の個数の不揃いを調整し、２つの対象要素間の属性の対応関係を示すテーブルを対応テーブル保持部６６に格納する。
【０１０８】
表現レベル処理ブロック１６０は、図７にその詳細な構成を示すように、表現生成部７２、表現形式調整部７４、および変換テーブル保持部７６を含む。表現レベル処理ブロック１６０は、セル空間レベル処理ブロック１５０においてセル空間レベルで詳細化されたオブジェクト集合の仕様を継承して、表現レベルでオブジェクト集合の仕様をさらに詳細化する。表現レベルでは、セルの具体的な表現形式を決めるため、オブジェクトの属性のデータ型や桁数などに関する仕様が詳細化されることになる。
【０１０９】
表現生成部７２は、２つのオブジェクト集合のそれぞれに属するオブジェクトの属性の表現を生成する。表現形式調整部７４は、目的同値関係により対応関係にある２つの対象要素間に表現レベルの不整合がある場合に、その不整合を調整するための処理を行う。表現レベルの不整合として、対象要素の属性のデータ型や桁数の違いなどがある。データ型には、ブール値、符号付き整数、正の整数、実数、倍精度実数、文字型などがあり、表現形式調整部７４はこれらのデータ型を変換して対象要素のデータ型を揃えてもよい。また、データ型が同じでも文字列の桁数や数値の有効桁数などの桁数が異なる場合には、表現形式調整部７４は２つの対象要素間で属性の桁数を調整して揃えてもよい。その他の不整合の例として、計量や貨幣などの単位の違いがあり、変換式を用いて、一方の単位系が他方の単位系に変換される。
【０１１０】
表現形式調整部７４は、位相空間Ｙを位相空間Ｘに接着する場合、表現レベルにおいて、位相空間Ｘのオブジェクト集合の対象要素と位相空間Ｙのオブジェクト集合の対象要素の属性のデータ型や桁数を比較して、相対的に精度が高い方の属性に揃えて、データ型や桁数を変換する。３つ以上のオブジェクト集合の対象要素間で属性の表現レベルの不整合を調整する場合も同じであり、表現形式調整部７４は、複数のオブジェクト集合の対応する対象要素の属性表現の内、最も精度の高い属性表現を選んで、他の精度の低い対象要素の属性表現をその精度の高い対象要素の属性表現に合わせるように調整する。これにより、精度の異なる対象要素の接着後に、データ型変換や桁落ちなどにより元のデータが失われるのを防ぐことができる。
【０１１１】
表現形式調整部７４は、最大の文字数や桁数をもった受容表現をもった表現フィルタとして作用し、当該表現フィルタを通過した表現は、表現レベルで同値になる。表現形式調整部７４は、表現の不整合の調整をした場合の変換規則を記述したテーブルを変換テーブル保持部７６に格納する。
【０１１２】
ビューレベル処理ブロック１７０は、ユーザに合わせたビューを設定し、ビューにしたがってオブジェクト集合をディスプレイなどに表示する。
【０１１３】
ホモトピーレベル処理ブロック１１０は、ソフトウエア開発支援装置１００の各処理ブロックがオブジェクト集合に対して操作を行った際、その操作によって生じるオブジェクト集合の変化がホモトピー同値になるように保証する。ホモトピーレベル処理ブロック１１０は、手順記録部２８に記録された接着空間生成に係る注目手順、対応テーブル保持部６６に格納されたセルの次元の不整合の対応関係を示すテーブル、変換テーブル保持部７６に格納されたセルの表現の変換規則を示すテーブルを利用し、各操作によってオブジェクト集合にもたらされた変化を逆にたどることにより、オブジェクト集合を変化前の状態に戻すことができる。
【０１１４】
このようにして、集合レベル処理ブロック１２０から始めて、位相空間レベル処理ブロック１３０、接着空間レベル処理ブロック１４０、セル空間レベル処理ブロック１５０、表現レベル処理ブロック１６０、およびビューレベル処理ブロック１７０へと、同値関係を継承しつつ、２つのオブジェクト集合の仕様を段階的に詳細化していくことで、２つのオブジェクト集合が表現レベルまで同値となって出力される。このようにインクリメンタリモジュラな抽象階層モデルにもとづくソフトウエア開発支援装置１００は、同値関係を、集合レベルから位相空間レベル、接着空間レベル、セル空間レベル、表現レベル、およびビューレベルまで保証する一貫性のあるフィルタとして機能し、フィルタを通過したオブジェクト集合は同値関係が数学的に保証されたインスタンスとなって出力される。
【０１１５】
対応づけたい構成要素が複数あれば、それぞれの構成要素について目的同値関係を設定することによって、同様に接着写像が規定され、最終的に複数のオブジェクト集合間で対応する要素が接着された結果が出力される。一方のオブジェクト集合が注目する構成要素をｎ個もてば、そのｎ個のそれぞれについて、他方のオブジェクト集合のいずれかの構成要素との対応関係が特定されるため、インタフェイス数は線形であり、工数爆発の問題が解決する。
【０１１６】
本実施の形態によれば、同値関係を設定すれば、複数のオブジェクト集合の構成要素間で対応づけができ、対応していない構成要素はそのまま残しつつ、同値関係にある構成要素については常に同じ情報をもつことができ、不変量を切り口に分類や対応づけができるので、データ利用性が向上し、ソフトウエア開発の効率を各段に高めることができる。
【０１１７】
［１６］具体例
以上の構成のソフトウエア開発支援装置１００によるソフトウエア開発支援手順の具体例を説明する。ソフトウエア開発支援装置１００が各種プログラムモジュールをもとにソフトウエアを開発する際、プログラムモジュール間のインタフェイスを確定し、各プログラムモジュールで利用されるデータの仕様を詳細化する。［１６．１］でデータの設計手順を述べ、［１６．２］でプログラムモジュールの設計手順を述べる。
【０１１８】
［１６．１］データ設計
ソフトウエアにおいて利用される複数のオブジェクト集合の一例として、シューズショップＸのオブジェクト集合３００と、シューズメーカーＹのオブジェクト集合２００を考える。これらのオブジェクト集合は、集合レベル処理ブロック１２０によって設計され、オブジェクト集合記憶部１９０に格納されている。これらのオブジェクト集合はデータベースとして管理されているものであってもよい。位相空間レベル処理ブロック１３０は、シューズショップＸのオブジェクト集合３００を位相空間Ｘとして、シューズメーカーＹのオブジェクト集合２００を位相空間Ｙとして設計する。この時点で、２つの位相空間Ｘ、Ｙは互いに素である。
【０１１９】
接着空間レベル処理ブロック１４０は、オブジェクト集合記憶部１９０に格納されたシューズショップＸのオブジェクト集合３００を位相空間Ｘとして、シューズメーカーＹのオブジェクト集合２００を位相空間Ｙとして参照し、同値関係をもとに２つの位相空間Ｘ、Ｙから接着空間を生成する。図８に、接着空間レベル処理ブロック１４０により２つの位相空間が接着される様子を示す。
【０１２０】
いま、シューズメーカーＹの製造する特定の運動靴Ｙ０をシューズショップＸが仕入れて、販売しているとする。このとき、ソフトウエアの開発者は、シューズショップＸのオブジェクト集合、シューズメーカーＹのオブジェクト集合との間でこの運動靴Ｙ０をプログラム上では同一のオブジェクトとして扱いたい。同値関係設定部４４は、シューズメーカーＹとシューズショップＸの位相空間の間で、注目すべき対象要素である運動靴Ｙ０を同値関係にあるものとして設定する。
【０１２１】
対応要素抽出部２０は、シューズメーカーＹの運動靴Ｙ０（符号２０２）に対応するシューズショップＸの運動靴ｆ（Ｙ０）（符号３０２）を抽出する。接着写像取得部２２は、この対応関係をもとに、接着写像ｆ：Ｙ０→Ｘ｜Ｙ０⊆Ｙを取得する。
【０１２２】
等化写像取得部２４は、接着写像取得部２２が取得した接着写像ｆによって、シューズショップＸとシューズメーカーＹの２つの位相空間の排他的論理和を接着空間
【数４７】
に写像する等化写像ｇを取得する。すなわち、等化写像取得部２４は、等化写像
【数４８】
を取得する。ここで、
【数４９】
であり、同図に示すように、運動靴ｆ（Ｙ０）（符号４０２）において２つの位相空間Ｘ、Ｙが接着する。
【０１２３】
図９は、シューズメーカーＹの位相空間における運動靴２０２のセル構造を説明する図である。運動靴２０２は、セルの属性として、靴のブランド名２１０、会社名２１２、種類２１４、サイズ２１６、色２１８、素材２２０、希望小売価格２２２、製造原価２２４、および原産国２２６を含む。
【０１２４】
図１０は、シューズショップＸの位相空間における運動靴３０２のセル構造を説明する図である。運動靴３０２は、セルの属性として、靴のブランド名３１０、メーカー名３１２、種類３１４、サイズ３１６、色３１８、素材３２０、売価３２２、および販売店３２４を含む。
【０１２５】
セル空間レベル処理ブロック１５０のセル接合部６２は、図９に示すシューズメーカーＹの位相空間における運動靴２０２と、図１０に示すシューズショップＸの位相空間における運動靴３０２をセルレベルで接合するため、共通する属性を互いに対応づける。靴のブランド名２１０、３１０、種類２１４、３１４、サイズ２１６、３１６、色２１８、３１８、素材２２０、３２０は属性名が一致するため、共通する属性として対応づけられる。
【０１２６】
シューズメーカーＹの運動靴２０２の会社名２１２と、シューズショップＸの運動靴３０２のメーカー名３１２は、属性名は異なるが同一の要素である。そこで、セル空間レベル処理ブロック１５０のセル次元調整部６４は、シューズメーカーＹ側の属性名をシューズショップＸ側の属性名に対応づけ、接合セルにおける属性名を「メーカー名」に統一することで不整合を調整し、シューズメーカーＹ側の「会社名」をシューズショップＸ側の「メーカー名」に対応づける関係を記述したテーブルを対応テーブル保持部６６に保持する。
【０１２７】
シューズメーカーＹの運動靴２０２とシューズショップＸの運動靴３０２をセルレベルで接合する際、一方の位相空間に属性が存在し、他方の位相空間にはそれに対応する属性が存在しないことがある。たとえば、シューズメーカーＹの運動靴２０２には、原産国２２６という属性があるが、シューズショップＸの運動靴３０２には、それに対応するものがない。逆に、シューズショップＸの運動靴３０２には、販売店３２４という属性があるが、シューズメーカーＹの運動靴２０２には、それに対応するものがない。このように、２つの対象要素間で属性の対応付けをする際、第１の位相空間に属性ａが存在し、第２の位相空間にはそれに対応する属性が存在しない場合、第１の位相空間の属性ａには対応づけられる属性がないとものして処理するか、もしくは第２の位相空間において空の属性ｂを追加して第１の位相空間の属性ａと対応づける処理を行う。たとえば、セル次元調整部６４は、シューズメーカーＹの運動靴２０２の原産国２２６については対応づけられる属性がないとして処理し、一方、シューズショップＸの運動靴３０２の販売店３２４については、空の属性をシューズメーカーＹの運動靴２０２に追加し、シューズショップＸの運動靴３０２の販売店３２４と対応づける処理を行い、属性の個数に関する不整合を調整する。
【０１２８】
属性の個数の調整の他の例として、一方の位相空間に「名前」という１つの属性があり、他方の位相空間には、「姓」と「名」という２つの属性がある場合、実質的には両者は同一の属性であるから、セル次元調整部６４は、「名前」という１つの属性と、「姓」と「名」という２つの属性を対応づけることで、属性の個数の不整合を調整することができる。
【０１２９】
図１１（ａ）〜（ｃ）は表現レベルでの不整合の調整を説明する図である。シューズメーカーＹ側の会社名２１２は、図１１（ａ）に示すように、Ｍ桁の文字列で表現されている。一方、シューズショップＸ側のメーカー名３１２は、図１１（ｂ）に示すように、Ｌ桁の文字列で表現されている。ここで、Ｌ＜Ｍである。表現レベル処理ブロック７０の表現形式調整部７４は、桁数の大きいＭ桁に合わせて、図１１（ｃ）に示すように、接合セルの属性であるメーカー名４１２の表現形式を決めてもよい。
【０１３０】
対象要素の属性の表現形式において桁数の違いがあるときに、桁数の大きい方に合わせて表現することは、「受容表現レベル」の一例である。表現形式調整部７４は、所定の受容表現レベルをフィルタとして用いることにより、対象要素の属性の表現形式の不整合を調整する。
【０１３１】
図１２（ａ）〜（ｄ）も表現レベルでの不整合の調整を説明する図である。シューズメーカーＹ側のサイズ２１６は、図１２（ａ）に示すように、ｉｎｃｈを単位とした実数値で表現されている。一方、シューズショップＸ側のサイズ３１６は、図１２（ｂ）に示すように、ｃｍを単位とした実数値で表現されている。
【０１３２】
ソフトウエアの設計仕様として、ｃｍの単位を採用する場合、表現レベル処理ブロック１６０の表現形式調整部７４は、図１２（ｃ）に示すように、接合セルの属性であるサイズ４１６の表現形式はｃｍを単位とすることにし、シューズショップＸ側のサイズ３１６の属性値を用いる。このとき、表現形式調整部７４は、図１２（ｄ）に示す変換式５１６を変換テーブル保持部７６に格納しておき、属性値の互換性を保つ。このようにいずれかの単位系に合わせることも受容表現レベルの一例である。
【０１３３】
図１３（ａ）〜（ｄ）も表現レベルでの不整合の調整を説明する図である。シューズメーカーＹ側の色２１８は、図１３（ａ）に示すように整数値で表現されている。一方、シューズショップＸ側の色３１８は、図１３（ｂ）に示すように文字列で表現されている。これは、シューズメーカーＹでは靴の色を細かく識別するための番号体系を利用するのに対して、シューズショップＸでは靴の色を顧客が理解しやすい「紺」「紫」などの名称で記述するからである。この違いは、シューズメーカーＹ、シューズショップＸのそれぞれのシステムにおける設計者の設計意図や顧客のニーズにより生じたものである。
【０１３４】
ソフトウエアの設計仕様として、色の表現形式を文字列とする場合、表現レベル処理ブロック１６０の表現形式調整部７４は、図１３（ｃ）に示すように、接合セルの属性である色４１８の表現形式を文字列として、シューズショップＸ側の色３１８の属性値を用いる。このとき、表現形式調整部７４は、図１３（ｄ）に示すように、シューズメーカーＹ側の色を識別する整数値とシューズショップＸ側の色を識別する文字列との間の変換規則を示した変換テーブルを作成して、変換テーブル保持部７６に格納し、属性値の互換性を保つ。このように文字列の表現形式に変換することも受容表現レベルの一例である。
【０１３５】
上記の例では、ソフトウエアの開発者がシューズショップＸとシューズメーカーＹの間で同値関係にある運動靴を指定したが、シューズショップＸと複数のシューズメーカーＹとの間で同値関係を指定してもよい。たとえば、「素材が革である靴」という同値関係をもとに、シューズショップＸの位相空間と、複数のシューズメーカーＹ１，Ｙ２，…，Ｙｎのそれぞれの位相空間との間で対応する構成要素を抽出し、接着空間を生成し、オブジェクトのデータ設計を行ってもよい。
【０１３６】
［１６．２］プログラムモジュールの設計
オブジェクト集合の一例として、プログラムを考え、本実施の形態に係るソフトウエア開発支援装置１００により、複数のプログラムをもとにソフトウエアを開発する手順を説明する。
【０１３７】
図１４（ａ）、（ｂ）は２つのプログラムＸとプログラムＹが統合される様子を説明する図である。これらのプログラムは、いずれも画像処理を行うものであるが、プログラムの開発者が異なるなどの理由で、プログラム構成が異なっているとする。これらのプログラムは、いずれも画像の符号化および復号の機能をもっており、たとえば、電子商取引で売買される商品の画像の符号化および復号を行うことができる。
【０１３８】
集合レベル処理ブロック１２０は、複数のモジュールからなるプログラムＸ、Ｙを集合として設計し、位相空間レベル処理ブロック１３０は、プログラムＸ、Ｙを位相空間として設計する。
【０１３９】
接着空間レベル処理ブロック１４０の同値関係設定部４４は、プログラムＸ、Ｙを構成するモジュールに対して、「符号化処理機能をもつ」および「復号処理機能をもつ」という２つの同値関係を設定する。対応要素抽出部２０は、同値関係設定部４４により設定された２つの同値関係をもとにプログラムＸ、Ｙ間の対応するモジュールを特定し、接着写像取得部２２は、各同値関係による対応関係を与える接着写像ｆ１、ｆ２を取得する。
【０１４０】
これにより、プログラムＹの位相空間は、符号化処理機能をもつモジュールＹ０と、圧縮処理機能をもつモジュールＹ１と、それ以外の機能をもつモジュールの直和
【数５０】
に分割され、一方、プログラムＸの位相空間は、符号化処理機能をもつモジュールでＹ０に対応するｆ（Ｙ０）と、圧縮処理機能をもつモジュールでＹ１に対応するｆ（Ｙ１）と、それ以外の機能をもつモジュールの直和
【数５１】
に分割される。
【０１４１】
等化写像取得部２４は、図１４（ａ）に示すプログラムＸ、Ｙの２つの位相空間の直和を図１４（ｂ）に示す接着空間
【数５２】
に写像する等化写像ｇを取得する。
【０１４２】
図１５（ａ）、（ｂ）は、接着写像により対応づけられた２つのモジュールＡ、Ｂの入出力インタフェイスを説明する図である。モジュールＡの入力に使われている変数は整数型のａ、ｂの２つであり、出力に使われている変数は実数型のｃである。一方、モジュールＢの入力に使われている変数は実数型のｓ、ｔの２つであり、出力に使われている変数は実数型のｕである。接着空間レベル処理ブロック１４０において対応づけられた２つのモジュールＡ、Ｂ間で入力変数、出力変数の名前に違いがあるが、セル空間レベル処理ブロック１５０のセル次元調整部６４は、２つのモジュールＡ、Ｂの入力変数、出力変数の名前を対応が取れるように調整する。また、２つのモジュールＡ、Ｂ間で入力変数、出力変数の個数に違いがあれば、セル次元調整部６４は、２つのモジュールＡ、Ｂの入力変数、出力変数の個数を対応が取れるように調整する。
【０１４３】
表現レベル処理ブロック１６０の表現形式調整部７４は、２つのモジュールＡ、Ｂの入力変数、出力変数のデータ型に違いがあれば、データ型を調整する。モジュールＡの入力変数は整数型であり、モジュールＢの入力変数は実数型であるから、たとえば、モジュールＡの入力変数を実数型に変換する。また、変数が文字型の場合は、表現形式調整部７４は、文字列の桁数の調整を行う。
【０１４４】
図１６〜図１９において、ソフトウエア開発支援装置１００によって、同値関係をもとにモジュールもしくはデータが対応づけられてソフトウエアが開発される手順を説明する。
【０１４５】
図１６（ａ）、（ｂ）は、プログラムモジュールが新しいバージョンに更新される様子を説明する図である。図１６（ａ）のように、新バージョンのモジュールＡｎｅｗと旧バージョンのモジュールＡｏｌｄがあるとする。それぞれ別の開発者が設計したものであってもよい。同値関係によって新バージョンのモジュールＡｎｅｗが旧バージョンのモジュールＡｏｌｄに対応づけられる。また、それに伴い、新バージョンのモジュールＡｎｅｗの入力変数ｓ、ｔが、旧バージョンのモジュールＡｏｌｄの入力変数ａ、ｂにそれぞれ対応づけられ、新バージョンのモジュールＡｎｅｗの出力変数ｕが旧バージョンのモジュールＡｏｌｄの出力変数ｃに対応づけられる。
【０１４６】
このように同値関係で新旧バージョンのモジュールを対応づけることにより、ソフトウエア開発支援装置１００は、図１６（ｂ）のように、旧バージョンのモジュールＡｏｌｄを新バージョンのモジュールＡｎｅｗに置き換えて、更新することができる。ソフトウエア開発支援装置１００は、モジュールの置き換えをホモトピー同値になるように行うため、必要に応じて新バージョンのモジュールＡｎｅｗを旧バージョンのモジュールＡｏｌｄに戻すこともでき、ソフトウエアのデバッグを効率良く行うことができる。
【０１４７】
図１７（ａ）、（ｂ）は、２つのプログラムモジュールが合成される様子を説明する図である。図１７（ａ）のように、モジュールＡは２つのサブモジュールＡ１、Ａ２をもち、モジュールＢは２つのサブモジュールＢ１、Ｂ２をもつ。同値関係によってモジュールＢのサブモジュールＢ１がモジュールＡのサブモジュールＡ１に対応づけられる。また、それに伴い、サブモジュールＢ１の入力変数ｓとサブモジュールＡ１の入力変数ａが対応づけられる。
【０１４８】
図１７（ｂ）のように、同値関係により定まる接着写像によって、モジュールＢのサブモジュールＢ１がモジュールＡのサブモジュールＡ１と同一視されることにより、２つのモジュールＡ、Ｂが合成され、１つのプログラムが生成される。このとき、接着写像で対応づけられたサブモジュールＢ１とサブモジュールＡ１の入出力変数のデータ型や桁数などが調整される。ソフトウエア開発支援装置１００は、モジュールの合成をホモトピー同値になるように行うため、必要に応じて合成されたプログラムから元のモジュールＡ、Ｂを分離して取り出すこともできる。
【０１４９】
このように、ソフトウエア開発支援装置１００は、同値関係をもとにして複数のモジュールを合成したり、合成されたプログラムからモジュールを取り出したりすることができ、ソフトウエアの部品化を進め、再利用性を高めることができる。
【０１５０】
図１８（ａ）、（ｂ）は、２つのプログラムモジュール間でデータが共有される様子を説明する図である。図１８（ａ）のように、２つの変数ａ、ｂを入力して変数ｃを出力するモジュールＡと、２つの変数ｓ、ｔを入力して変数ｕを出力するモジュールＢとがあり、モジュールＢの入力変数ｓとモジュールＡの入力変数ａが同値関係によって対応づけられ、それ以外の変数の間には対応関係がないとする。
【０１５１】
図１８（ｂ）のように、同値関係により定まる接着写像によって、モジュールＢの入力変数ｓがモジュールＡの入力変数ａと同一視されることにより、２つのモジュールＡ、Ｂ間で入力変数の１つが共有される。このように、ソフトウエア開発支援装置１００は、プログラムモジュール間で同値類として対応づけられるデータを共有し、データの利用性を高めることができる。
【０１５２】
図１９（ａ）、（ｂ）は、２つのプログラムモジュールが結合される様子を説明する図である。図１９（ａ）のように、２つの変数ａ、ｂを入力して変数ｃを出力するモジュールＡと、２つの変数ｓ、ｔを入力して変数ｕを出力するモジュールＢとがあり、モジュールＢの出力変数ｕとモジュールＡの入力変数ａが同値関係によって対応づけられ、それ以外の変数の間には対応関係がないとする。
【０１５３】
図１９（ｂ）のように、同値関係により定まる接着写像によって、モジュールＢの出力変数ｓがモジュールＡの入力変数ａと同一視されることにより、モジュールＢとモジュールＡがこの順で結合され、１つのプログラムが生成される。このとき、モジュールＢの出力変数とモジュールＡの入力変数の間でデータ型や桁数などが調整される。このプログラムの結合は、ホモトピー同値になるように行われるため、必要に応じて結合を解除して、モジュールＡとモジュールＢを分離することもできる。このように、ソフトウエア開発支援装置１００は、同値関係をもとにして複数のプログラムモジュールを結合したり、分離したりすることができ、プログラムモジュールの利用性を高めることができる。
【０１５４】
このように、ソフトウエア開発支援装置１００によれば、同値関係にもとづいてソフトウエア部品の合成、置換、連結などの開発工程を線形操作で行うことができるため、ソフトウエア部品の個数が増えても、開発工数爆発が起きることなく、ソフトウエアを効率良く開発することができる。
【０１５５】
上記の具体例では、プログラムモジュールの仕様を特徴づける属性として、入出力インタフェイスを例に挙げ、対応するプログラムモジュール間で入出力インタフェイスの次元や表現形式の不整合を調整することを説明したが、これは属性の一例に過ぎない。プログラムモジュールの仕様を特徴づける他の属性の例として、そのプログラムモジュールが参照する変数を考えてもよい。その場合、対応するプログラムモジュール間で参照変数の次元や表現形式の不整合が調整される。また、プログラムモジュールが利用する関数を属性として考えてもよい。その場合、対応するプログラムモジュール間で関数の次元、すなわち関数名や関数の個数などの不整合が調整される。さらに、その関数の引数や戻り値の次元や表現形式の不整合が調整されてもよい。
【０１５６】
ソフトウエア開発支援装置１００のビューレベル処理ブロック１７０は、ソフトウエア開発者毎に異なるビューを設計してもよい。たとえば、上級のソフトウエア開発者にはプログラムモジュールの内部変数の設計変更ができるように、プログラムモジュール内部のデータ操作が可能なビューを設定する。一方、初級のソフトウエア開発者にはプログラムモジュールの外部インタフェイスの設計変更だけを許すように、プログラムモジュールの内部のデータ操作が不可能なビューを設定する。このように、開発者のプログラミングの経験や技術などのレベルに応じてビューを異ならせてもよい。また、ソフトウエアを複数の開発者が共同開発する場合、各開発者が担当するプログラムエリアに限って設計変更ができるように、開発者毎にビューを異ならせてもよい。後述のようにソフトウエア開発支援装置１００を保守工程で利用する場合は、ビューレベル処理ブロック１７０は、ソフトウエアの保守者毎に異なるビューを設計してもよい。
【０１５７】
［１７］ソフトウエアのライフサイクル管理
ソフトウエア開発のアクティビティには、要求分析、システム設計、プログラム設計、プログラム実装、単体・結合テスト、システムテスト、受け入れテスト、および運用・保守があり、これらの一連のアクティビティがライフサイクルとして管理される。要求分析、システム設計、プログラム設計、およびプログラム実装は、ソフトウエアの開発工程である。開発工程において生成されたソフトウエアのプログラムモジュールについて単体・結合テストが行われ、次にシステム全体の機能面についてシステムテストが行われ、最終的にシステム出荷時の受け入れテストが行われる。これが試験工程である。受け入れテストに合格したシステムは運用され、稼働中にシステムが保守される。これが保守工程である。
【０１５８】
図２０に示すソフトウエアライフサイクル管理装置６００は、開発工程から試験工程を経て、保守工程に至るまでのソフトウエアのライフサイクルを管理する。開発機能ブロック６１０は、既に述べたソフトウエア開発支援装置１００の各機能を有し、抽象階層間でソフトウエア部品集合の同値関係を不変量として継承しながら、ソフトウエア部品集合が満たすべき仕様を抽象階層毎にインクリメンタルに詳細化することにより、与えられた要求仕様に合致するソフトウエアをソフトウエア部品集合から自動生成する。開発機能ブロック６１０により、ソフトウエアの要求分析からシステム設計、プログラム設計、プログラム実装までが実行され、開発されたソフトウエアはソフトウエア記憶部６４０に記憶される。ソフトウエア記憶部６４０は、要求仕様、開発、試験、および保守工程におけるすべてのプログラムを保持する。
【０１５９】
試験機能ブロック６２０は、開発機能ブロック６１０により生成されたソフトウエアが各抽象階層において詳細化された仕様に合致するか否かをテストし、問題が発見された場合に、いずれかの抽象階層において要求条件を修正し、開発機能ブロック６１０は、要求条件が修正された抽象階層から始めて、ソフトウエア部品集合が満たすべき仕様を抽象階層毎にインクリメンタルに詳細化する。
【０１６０】
開発されたソフトウエアの試験は、要求分析、システム設計、プログラム設計、およびプログラム実装のいずれの段階でも行う必要がある。たとえば、試験機能ブロック６２０が、要求仕様に不具合を発見して修正をしたときは、開発機能ブロック６１０は、抽象階層モデルの位相空間レベルや接着空間レベルなどの上位階層にもどって、その階層から設計の詳細化をやり直して不具合を解消する。また、試験機能ブロック６２０が、プログラム実装において、関数の引数の数や変数のデータ型などに不具合を発見した場合は、開発機能ブロック６１０は、抽象階層モデルのセル空間レベルや表現レベルなどの下位階層から設計の詳細化をやり直して不具合を解消する。いずれの階層から作業をやり直すときでも、インクリメンタリモジュラな抽象階層にもとづくソフトウエア開発支援装置１００によれば、新しい要求条件のもと、線形操作でソフトウエアを再構成することができる。
【０１６１】
保守機能ブロック６３０は、運用中のソフトウエアに修正もしくは機能拡張の必要があった場合に、その修正もしくは機能拡張を反映すべき抽象階層において要求条件を変更し、開発機能ブロック６１０は、要求条件が変更された抽象階層から始めて、ソフトウエア部品集合が満たすべき仕様を抽象階層毎に再度インクリメンタルに詳細化する。
【０１６２】
ソフトウエアの保守には、システムの障害への対処もしくは予防のために修正を行うものとして、修正保守（corrective maintenance）と予防保守（preventive maintenance）があり、システムの機能拡張を行うものとして、改善保守（perfective maintenance）と適応保守（adaptive maintenance）がある。
【０１６３】
修正保守は、現行のシステムに障害が起きた場合に、障害の原因を発見して、ソフトウエアの必要な修正を行うものである。修正保守は、ソフトウエアの残存不良を修正する作業であり、一般には仕様の変更はしない。抽象階層モデルを利用した修正保守は、たとえば、セル空間レベルや表現レベルなど比較的下位の階層で要求条件を調整して行われる。
【０１６４】
予防保守は、現実には障害が起きてないが、潜在的な障害の可能性を発見し、システムの故障を未然に防ぐために、システムのある側面を修正、変更することであり、修正保守と同様に抽象階層モデルを利用して行うことができる。
【０１６５】
改善保守は、障害を回避するためにソフトウエアを変更するのではなく、システムのある機能や性能を向上させるためにソフトウエアの変更を行うことである。改善保守は、ソフトウエアの仕様の変更を伴うものである。抽象階層モデルを利用した改善保守は、たとえば位相空間レベルや接着空間レベルなど比較的上位の階層で要求条件を調整した上で、下位の階層に向けて抽象階層を辿りながら、ソフトウエアを再設計することによって行われる。
【０１６６】
適応保守は、ハードウエアやソフトウエアの技術進歩などの変化に応じてソフトウエアの変更を行うものである。適応保守は、障害に対処するものではなく、進化していくシステムに適応させるために変更を行うものである。適応保守も他の保守と同様に抽象階層モデルを利用して行うことができる。
【０１６７】
ソフトウエアの保守工程は、新たな要求を分析し、システムとプログラムの設計を評価し、コードをレビューし、必要に応じて修正を加える点で、ソフトウエアの開発工程およびソフトウエアの試験工程と共通するアクティビティを含んでいる。開発工程および試験工程が抽象階層モデルを利用して行われるように、保守工程も抽象階層モデルを有効に利用して、効率良く行うことができ、保守の負担を軽減することができる。
【０１６８】
一般に、欠陥修正は別の欠陥修正を引き起こす波及効果がある。保守による手直しがシステムの別の部分に影響を与えて、新たな障害を生み出すことがあるからである。一般的にソフトウエア開発は開発者依存であるため、開発者の作成した仕様書を丹念にレビューしても保守による影響を正確に予測することは困難である。しかしながら、本実施の形態のソフトウエアライフサイクル管理装置６００によれば、抽象階層モデルを利用してソフトウエアの開発が行われ、開発者依存の設計要素が排除されるため、保守においても同じ抽象階層モデルを参照することで、何と何が同値関係にあるかを把握した上で、ある箇所の修正が他の箇所にどのような影響を与えるかを的確に予測して正しい修正を効率良く行うことができる。
【０１６９】
修正保守において、ソフトウエアのある部分について同値関係を新たに定義する必要が生じた場合や、最初から定義しておくべきであった同値関係が保守段階で発見された場合でも、抽象階層モデルを参照し、接着空間レベルで同値関係を定義し直し、その同値関係を下位のセル空間レベルや表現レベルにまで落として実装することにより、整合性を保証することができる。また、拡張保守や適応保守において、ソフトウエアに新たな機能を追加する場合や、新たなパラメータを設定する場合でも、抽象階層モデルにおいて適宜新たな同値関係を設定してインクリメンタルにソフトウエアの再設計を行うことができる。また、予防保守において、対応する変数の間でデータ型やデータ長の相違があり、不都合が生じることが予見される場合でも、抽象階層モデルを利用して、これらの変数に同値関係を定義してその部分について不整合を調整することができる。
【０１７０】
このように、本実施の形態のソフトウエアライフサイクル管理装置６００によれば、抽象階層モデルを利用することにより、保守段階で要求の変化が生じても、要求仕様にもとづいて同値関係を定め、設計および実装レベルまでその同値関係を不変量として継承して仕様の詳細化と具体化を図ることができ、変化に対して柔軟かつ効率良く対応することができる。抽象階層モデルを利用することにより、保守工程におけるソフトウエアに対する操作も、開発工程における操作と同じように、線形インターオペラビリティが保証されるため、線形操作で新たな機能の追加や不要な機能の削除を行うことができる。
【０１７１】
ソフトウエアのライフサイクルモデルとして、ウォーターフォールモデル、ラピッドプロトタイピングモデル、スパイラルモデルなどいろいろなモデルが提案されているが、本実施の形態のソフトウエアライフサイクル管理装置６００は、いずれかのライフサイクルモデルに依存するものでもなく、また、いずれかのライフサイクルモデルを前提として適用されるものでもない。もっとも、本実施の形態のソフトウエアライフサイクル管理装置６００をいずれかのライフサイクルモデルに適合させる形で用いることを妨げない。本実施の形態のソフトウエアライフサイクル管理装置６００の主要な利点は、インクリメンタリモジュラな抽象階層モデルを用いることにより、抽象階層間でソフトウエア部品集合間の同値関係を不変量として継承して整合性を保証するとともに、ソフトウエア部品集合の線形統合と線形操作を保証し、ソフトウエアの開発から試験、保守に至るまでのライフサイクルの管理に一貫性をもたせたことにある。
【０１７２】
以上、実施の形態を説明した。実施の形態は例示であり、さまざまな変形例が可能であり、そうした変形例も本発明に含まれることは当業者に理解されるところである。
【図面の簡単な説明】
【０１７３】
【図１】２つの互いに素である位相空間から接着空間が生成される様子を説明する図である。
【図２】顧客と取引会社の位相空間が接着される様子を説明する図である。
【図３】座席と支持部の位相空間が接着される様子を説明する図である。
【図４】実施の形態に係るソフトウエア開発支援装置の構成図である。
【図５】図４の接着空間レベル処理ブロックの構成図である。
【図６】図４のセル空間レベル処理ブロックの構成図である。
【図７】図４の表現レベル処理ブロックの構成図である。
【図８】図５の接着空間レベル処理ブロックにより、２つの位相空間が接着されて接着空間が生成される様子を説明する図である。
【図９】オブジェクトのセル構造を説明する図である。
【図１０】オブジェクトのセル構造を説明する図である。
【図１１】図７の表現レベル処理ブロックにより、表現レベルでの不整合が調整される様子を説明する図である。
【図１２】図７の表現レベル処理ブロックにより、表現レベルでの不整合が調整される様子を説明する図である。
【図１３】図７の表現レベル処理ブロックにより、表現レベルでの不整合が調整される様子を説明する図である。
【図１４】２つのプログラムが統合される様子を説明する図である。
【図１５】接着写像により対応づけられた２つのモジュールの入出力インタフェイスを説明する図である。
【図１６】プログラムモジュールが新しいバージョンに更新される様子を説明する図である。
【図１７】２つのプログラムモジュールが合成される様子を説明する図である。
【図１８】２つのプログラムモジュール間でデータが共有される様子を説明する図である。
【図１９】２つのプログラムモジュールが結合される様子を説明する図である。
【図２０】実施の形態に係るソフトウエアライフサイクル管理装置の構成図である。
【符号の説明】
【０１７４】
２０ 対応要素抽出部、 ２２ 接着写像取得部、 ２４ 等化写像取得部、 ２６ 手順取得部、 ２８ 手順記録部、 ４４ 同値関係設定部、 ５２ 同値関係保持部、 ６２ セル接合部、 ６４ セル次元調整部、 ６６ 対応テーブル保持部、 ７２ 表現生成部、 ７４ 表現形式調整部、 ７６ 変換テーブル保持部、 １００ ソフトウエア開発支援装置、 １１０ ホモトピーレベル処理ブロック、 １２０ 集合レベル処理ブロック、 １３０ 位相空間レベル処理ブロック、 １４０ 接着空間レベル処理ブロック、 １５０ セル空間レベル処理ブロック、 １６０ 表現レベル処理ブロック、 １７０ ビューレベル処理ブロック、 １９０ オブジェクト集合記憶部、 ６００ ソフトウエアライフサイクル管理装置、 ６１０ 開発機能ブロック、 ６２０ 試験機能ブロック、 ６３０ 保守機能ブロック、 ６４０ ソフトウエア記憶部。
【技術分野】
【０００１】
この発明はソフトウエアライフサイクル管理技術、とくに、複数の異なるオブジェクト集合間でデータの一貫性維持、インタフェイスの確定その他の処理をなすことのできるソフトウエアライフサイクル管理装置およびソフトウエアライフサイクル管理方法に関する。
【背景技術】
【０００２】
「ソフトウエア工学」（Software Engineering）という用語は、１９６８年のＮＡＴＯ会議で最初に使われたといわれる。この会議において討議されたソフトウエア設計法、プロジェクト管理、技術者教育、ソフトウエアの価格および流通の４つの項目は、今なお、ソフトウエア工学の中心課題である（非特許文献１参照）。
【０００３】
ソフトウエアライフサイクル管理は、要求分析・仕様、設計、実装、テスト、運用、および保守の各段階からなる。最初の要求分析が甘く、顧客の要求を取りこぼしたり、取り違えたりすると、それ以降のシステム設計、実装に顧客の要求が正しく反映されない。そのため、テストや運用段階で発見された不具合を修正するために、プログラムを改良したり、大規模な変更の場合はシステム設計をやり直すなど、ソフトウエアの保守に大変な時間と労力がかかる。最悪の場合、保守に耐えられないソフトウエアは廃棄されることもあり、最初から開発をやり直すことになる。このように、ソフトウエアの開発プロセスの初期段階において、要求分析に時間と労力を惜しむと、保守段階においてコストがかかり、開発プロセスをトータルでみた場合に、全体のコストが肥大する。
【０００４】
ソフトウエアの伝統的なライフサイクルモデルの一つに、１９７０年に提案されたウォーターフォールモデルがある。ウォーターフォールモデルでは、ソフトウエア製品は、要求分析から始まり、システム設計、プログラム設計、プログラム実装、単体・結合テスト、システムテスト、運用、保守に至るまでシーケンシャルに開発されるものと考え、ソフトウエアの開発のアクティビティをモデル化している。
【０００５】
ウォーターフォールモデルは、直線的な開発モデルであり、ある段階は次の段階を開始する前に完了する必要があり、複数の段階にまたがった繰り返しは想定されない。ウォーターフォールモデルは、最初の段階ですべての要求仕様を明確に定めることを要求し、不確実性に対応することはできない。顧客の要求が仕様の決定後やプログラムの設計段階で変更されても、ウォーターフォールモデルでは新しい要求に柔軟に対応することができない。通常、ソフトウエアは試行錯誤しながら多くの繰り返しを経て開発されるため、繰り返しを前提としない直線的な開発モデルはおよそ現実的ではない。そのため、ウォーターフォールモデルは今日、非常に大規模なソフトウエアの開発モデルとして用いられることはあっても、一般的には利用されていない。これらのよく知られたウォーターフォールモデルの限界は、最近米国で行われたソフトウエアエンジニアリングに関するサーベイにおいても指摘されている（非特許文献２参照）。
【０００６】
情報システム構築は、たとえば大手銀行の統合に伴う統合システムに典型的にみられるように、単一大規模サイト向けから、複数分散大規模サイト向けに加速度的に移行しつつある。ところが、その基盤技術となっている現在のソフトウエア工学、リエンジニアリング技術において、これに対応するための基本的枠組みとしてのエンジニアリングモデルが欠落している。その理由は、統合方法がモデルレベルで欠如しているために、各サイト構築担当のエンジニアが個々にモジュール群を工夫して設計・構築している点にある。このために、モジュール群仕様がサイト毎に自ずと異なる。モジュール群の仕様が相互に開示されれば、再構築も可能であるが、モジュールの数の組み合わせにより指数関数的に再構築システム数が増え、いわゆる「開発工数爆発」が生じる。しかも、実際には、企業機密保持上モジュール群の仕様が開示されない場合のほうが多い。この場合、モジュール間のインタフェイス作成情報が開示されるものの、インタフェイス数も組み合わせにより指数関数的に増加するので、一層「開発工数爆発」の様相が顕著となる。
【非特許文献１】シャリ・ローレンス・プリーガー著，堀内泰輔訳，「ソフトウエア工学 理論と実践」，初版，株式会社ピアソン・エデュケーション，２００１年１１月
【非特許文献２】Philip A. Laplante and Colin J. Neill, "The Demise of the Waterfall Model Is Imminent" and Other Urban Myths, ACM QUEUE (Feb. 2004), Vol.1, No.10, pp.10-15.
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ソフトウエアの効率的な開発と保守を支援するための理論的基礎となるエンジニアリングモデルが欠如しているために、要求分析からシステム設計、実装、テスト、保守に至るまでのソフトウエアライフサイクルのスムーズな流れが滞り、ソフトウエア開発が遅延し、また、運用段階で不測の事態が発生しやすいためリスク管理が難しく、ソフトウエアの保守にかかるコストが増大している。
【０００８】
国内外には、リレーショナル・データベ−ス（ＲＤＢ）モデル、ＥＲモデル、タグによるＸＭＬ、グラフによるＵＭＬなどが研究され応用されているが、大規模分散情報システムを構築する理論的基礎としてはモデル的に完全とはいえず、例えばモジュール間のインタフェイス仕様が、異なるサイト間で統一的に取り扱える理論体系になっていない。したがって、前述の「開発工数爆発」は解決できない。
【０００９】
また、各国において昨今の厳しい経済状況もあり、会社統合が増加の一途をたどっているが、異なる情報システム間で整合性をもって情報処理を自在に行えること、すなわち、情報システムのインターオペラビリティが確保されないため、情報システムの運用と保守の費用が増大している。
【００１０】
大規模システムのコストの半分から２／３は保守費用であると言われており、保守はシステムを導入した企業にとって大きなコスト要因となっている。特に稼働中のシステムに不具合が生じた場合、保守は企業の存続に関わる問題となることもあり、大変なリスクを伴う。ソフトウエアに変更を加えるコストは、その変更が要求仕様の決定段階あるいはシステムやプログラムの設計段階で行われるのであれば、比較的低いが、ソフトウエアが出荷され、運用されてからの変更の場合、コストはとてつもなく大きくなる。したがって、できるだけ早い段階で要求仕様や設計の不具合を見つけ、運用後の変更を少なくする必要がある。また、運用・保守段階での変更は、たとえ一部の変更であっても、他のソフトウエアの部分に影響を与えることもあり、変更は複雑で慎重を要する作業となる。ソフトウエアの保守を効率的に行うことが、ソフトウエアの全体コストを削減する上できわめて重要である。
【００１１】
本発明はこうした背景からなされたものであり、その目的は、ソフトウエア部品のインターオペラビリティを線形モデルとして保証して、ソフトウエアの開発、試験、および保守の自動化を支援することのできるソフトウエアライフサイクル管理技術を提供することにある。
【課題を解決するための手段】
【００１２】
本発明のある態様はソフトウエアライフサイクル管理方法に関する。この方法は、ソフトウエア部品集合間の線形インターオペラビリティを保証するインクリメンタリモジュラな抽象階層モデルを利用して、ソフトウエアの開発工程から試験工程を経て、保守工程に至るまでのライフサイクルを一貫して管理する。
【００１３】
「ソフトウエア部品」は、本装置により自動生成されるソフトウエアを構成する部品であり、ソフトウエアで利用されるデータ、ソフトウエアを構成するプログラムなどを含む。
【００１４】
本発明の別の態様はソフトウエアライフサイクル管理装置に関する。この装置は、ソフトウエア部品集合間の線形インターオペラビリティを保証するインクリメンタリモジュラな抽象階層モデルを利用した、ソフトウエアの開発機能ブロック、試験機能ブロック、および保守機能ブロックを備え、ソフトウエアのライフサイクルを前記抽象階層モデルにもとづいて一貫して管理する。
【００１５】
この装置によれば、複数のソフトウエア部品集合の間で同値関係を規定し、その同値関係を不変量として抽象階層間で継承しながら、各抽象階層において段階的にソフトウエア部品集合の満たすべき仕様を設計することができる。集合レベル、位相空間レベル、接着空間レベル、セル空間レベル、表現レベル、およびビューレベルを通して、同値関係が保証され、最終的にソフトウエアが数学的に整合性のある形で生成される。また、各抽象階層はモジュール化されており、ソフトウエア部品の追加、削除、および修正などを行っても、抽象階層を上下に行き来しながら、インクリメンタルに設計変更することができる。さらに、ソフトウエア部品集合に対してなされる操作をホモトピーとして扱うことにより、ソフトウエア部品集合を変化前の状態と変化後の状態の間で相互に移行させることができ、数学的な整合性を維持しながら、ソフトウエアの部品化、再利用、デバッグなどの開発工程を支援することができる。
【００１６】
この装置によれば、ソフトウエアの試験に関して、開発工程により生成されたソフトウエアが各抽象階層において詳細化された仕様に合致するか否かをテストし、発見された問題に応じていずれかの抽象階層もどって開発工程を繰り返すことができ、抽象階層を利用して効率的な試験工程を支援することができる。さらに、ソフトウエアの保守に関して、運用中のソフトウエアに修正もしくは機能拡張の必要があった場合に、その修正もしくは機能拡張を行うべき抽象階層にもどって開発工程を繰り返すことにより、抽象階層を利用して効率的な保守工程を支援することができる。
【００１７】
なお、以上の構成要素の任意の組み合わせ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラム、データ構造などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１８】
本発明によれば、情報システムのインターオペラビリティを保証し、ソフトウエア開発、試験、および保守を含むソフトウエアライフサイクルの管理の効率化を図ることができる。
【発明を実施するための最良の形態】
【００１９】
以下本発明を好適な実施の形態をもとに説明する。まず、本発明者が提唱するインクリメンタリモジュラな抽象階層（incrementally modular abstraction hierarchy）を説明し、その後、インクリメンタリモジュラな抽象階層を実装した情報処理装置を説明する。
【００２０】
［１］集合論的設計
まず、サイバースペースに構築すべきオブジェクトの集まりを定義することからサイバーワールドの設計を始める。そのような集まりに対してインテリジェントマシンとしてコンピュータを使った自動操作の実行が可能であるためには、各集まりは「集合（set）」でなければならない。なぜなら、コンピュータは集合論的機械として構築されているからである。直観的に、集合Ｘは、同一のプロパティＰ（ｘ）をもったすべてのオブジェクトｘの集まりである。これを記号で表すなら、Ｘ＝｛ｘ｜Ｐ（ｘ）｝である。集合に含まれる任意のオブジェクトを元または要素（element）という。要素をもたない集合を空集合φという。すべての要素が内部（interior）であるならば、その集合は開集合であるという。集合ＸとＹが与えられたとき、コンピュータは、和（union）Ｘ∪Ｙ、積または共通部分（intersection）Ｘ∩Ｙ、差（difference）Ｘ−Ｙ（ｘ＼ｙとも書く）、否定(negation)¬Ｘのような集合論的演算を施す。
【００２１】
最初のサイバースペースとして集合Ｘからサイバースペースアーキテクチャの設計を始めるとしよう。未知のサイバースペースＵのすべての要素ｕが与えられたとき、もしそれらの要素がすべてサイバースペースＸの要素であることが確かめられたならば、その未知のサイバースペースをＸの部分集合、すなわちＸの部分サイバースペースと呼び、Ｕ⊆Ｘと表記する。部分集合であるかどうかは、（∀ｕ）（ｕ∈Ｕ→ｕ∈Ｘ）を処理することで自動的に調べることができる。Ｕの閉包（closure）
【数１】
は、Ｕを含むＸのすべての閉部分集合の積である。言い換えれば、Ｕの閉包は、Ｕの外部（exterior）要素でないＸの要素である。Ｘの部分集合｛Ｕ｜Ｕ⊆Ｘ｝のすべてからなる集合をＸの巾（べき）集合といい、２Ｘと表記する。これはまたＸの離散位相（discrete topology）とも呼ばれる。離散位相はサイバースペースを部分サイバースペースからなるものとして設計する上でたいへん有用である。なお、集合を要素とする集合（いわゆる「集合の集合」）を「集合族」（family of sets）ということがある。Ｘの巾集合は、集合Ｘのすべての部分集合を要素とする集合族である。
【００２２】
［２］位相幾何学的設計
これから、サイバースペースをＸの（複数の）部分サイバースペースとその重複（overlap）の和として設計する作業に入る。このように設計されるサイバースペースは一般に位相（トポロジー）空間（Ｘ，Ｔ）と呼ばれる。ここでＴ⊆２Ｘである。位相空間の設計は次の仕様により自動化される。
１）Ｘ∈Ｔかつφ∈Ｔ；
２）任意の添え字の集合Ｊに対して、
∀ｊ∈Ｊ（Ｕｊ∈Ｔ）→∪ｊ∈ＪＵｊ∈Ｔ；
３）Ｕ，Ｖ∈Ｔ→Ｕ∩Ｖ∈Ｔ．
【００２３】
上記の設計仕様の１）は、空集合と全体集合がＴの要素であること、２）は、Ｔの要素をいくつもってきて和をとってもＴの要素であること、３）は、Ｔの２つの要素の積（共通部分）もＴの要素であることを示している。コンピュータは、Ｘの巾集合２Ｘからこの設計仕様を満たすようにＴを設計する。
【００２４】
Ｔを位相空間（Ｘ，Ｔ）の位相（トポロジー）という。Ｔ１⊂Ｔ２である２つの位相Ｔ１とＴ２が与えられたとき、Ｔ１はＴ２よりも弱いまたは小さいという。逆に、Ｔ２はＴ１よりも強いまたは大きいという。またＴ２はＴ１よりも細かい、あるいはＴ１はＴ２よりも粗いということもある。明らかなように最も強い位相は離散位相すなわち巾集合であり、最も弱い位相は空集合φである。簡単のため、あいまいさが生じないならば、位相空間を表すために（Ｘ，Ｔ）の代わりにＸをしばしば用いる。
【００２５】
２つの位相空間（Ｘ，Ｔ）と（Ｙ，Ｔ'）が与えられたとき、いかにして（Ｘ，Ｔ）と（Ｙ，Ｔ'）が同値であるということができるだろうか。コンピュータを使って、それらの空間が位相幾何学的に同値であることを自動的に検証（validate）するための基準をここに与える。２つの位相空間（Ｘ，Ｔ）と（Ｙ，Ｔ'）は、連続な関数ｆ：（Ｘ，Ｔ）→（Ｙ，Ｔ'）が存在し、かつその逆関数も存在して連続であるならば、トポロジー同値（topologically equivalent）、すなわち同相、同位相または位相同形（homeomorphic）であるという。（Ｘ，Ｔ）が（Ｙ，Ｔ'）と同相であることを
【数２】
と書く。
【００２６】
それでは、関数ｆの連続性はどのように立証することができるか。最初に、∀Ｂ∈Ｔ'，ｆ−１（Ｂ）∈Ｔであることを調べる。ここでｆ−１（Ｂ）はｆによるＢの逆像を意味する。次に、以下が成り立つことを調べる。
Ｂが開である⇔ｆ−１（Ｂ）もまたＸにおいて開である。
【００２７】
［３］関数
関数ｆ：Ｘ→Ｙが与えられたとき、全域関数（total function）と部分関数（partial function）が存在する。関数ｆ：Ｘ→Ｙに対して、∀ｘ∈Ｘ、∃ｆ（ｘ）であるとき、そしてそのときに限り、関数ｆは全域関数であるという。関数ｆ：Ｘ'→Ｙ｜Ｘ'⊇Ｘを部分関数といい、このときｆ（ｘ）は必ずしもあらゆるｘ∈Ｘに対して存在しているとは限らない。
【００２８】
全域関数に対して、３つの基本的なタイプの関係あるいは写像が存在する。
１．単射（injectiveまたはinto）
∀ｘ，ｙ∈Ｘ，ｘ≠ｙ⇒ｆ（ｘ）≠ｆ（ｙ）
言い換えれば、
∀ｘ，ｙ∈Ｘ，ｆ（ｘ）＝ｆ（ｙ）⇒ｘ＝ｙ
２．全射（surjectiveまたはonto）
（∀ｙ∈Ｙ）（∃ｘ∈Ｘ）［ｆ（ｘ）＝ｙ］
３．全単射（bijective）
単射かつ全射であること
【００２９】
［４］同値関係
集合Ｘ上の任意の２項関係Ｒ⊆Ｘ×Ｘに対して、Ｒは、
１）（∀ｘ∈Ｘ）［ｘＲｘ］ならば、反射性があり、
２）（∀ｘ，ｙ∈Ｘ）［ｘＲｙ⇒ｙＲｘ］ならば、対称性があり、
３）（∀ｘ，ｙ，ｚ∈Ｘ）［［ｘＲｙ⇒ｙＲｘ］⇒ｘＲｚ］ならば、推移性があるという。１）〜３）の条件は、それぞれ反射律、対称律、推移律と呼ばれる。
【００３０】
Ｒが反射性、対称性、推移性をもつとき、Ｒを同値関係（equivalence relation）と呼び、〜で表記する。
【００３１】
ｘ∈Ｘが与えられたとき、ｘ／〜＝｛ｙ∈Ｘ：ｘ〜ｙ｝で定義されるＸの部分集合をｘの同値類（equivalent class）と呼ぶ。ここで類（class）は実際には集合を意味するが、伝統的に類（クラス）と呼ばれており、今となっては変更するのは難しい。すべての同値類の集合Ｘ／〜をＸの商空間（quotient space）もしくは等化空間（identification space）という。
Ｘ／〜＝｛ｘ／〜∈２Ｘ｜ｘ∈Ｘ｝⊆２Ｘ
推移律より、各ｘ∈Ｘ、ｘ／〜≠φについて、以下が成り立つ。
【数３】
これは集合Ｘが空でない互いに素の（すなわち共通要素をもたない）同値類に分割される（分解されるともいう）ことを意味する。
【００３２】
一般に、集合Ｘの上に同値関係〜が定義されたとき、あるＸの要素ａに対してａに同値である要素をすべて集めた集合を考えることができる。このＸの部分集合は、ａを代表要素とする同値類であり、［ａ］と表記される。ここで、同値類に含まれる要素のうちどれを取っても、それを代表要素とする同値類は同じ集合になる。すなわち、同値類は代表要素の取り方によらない。同値類が反射律、対称律、および推移律を満たすことより、各同値類は空ではなく、ａの同値類にはａが属し、相異なる同値類には共通の要素がない。したがって、同値類をすべて集めると、それらは互いに交わらず、また全体の和集合はＸに等しくなる。つまり、集合Ｘは同値類の直和（disjoint union）に分割される。この直和分割を集合Ｘの同値関係Ｒに関する類別（classification）といい、同値類全体の集合を集合Ｘの同値関係〜による商集合と呼ぶ。商集合に位相が定義されたものを上記のように商空間という。
【００３３】
簡単な例で説明する。Ｘを有理整数の集合とし、Ｘの要素ｘ、ｙの関係Ｒとして、「ｘ−ｙが偶数である」を考えると、これは同値関係である。集合Ｘをこの同値関係Ｒで類別すれば、集合Ｘは、奇数の同値類と偶数の同値類の直和に分割される。
【００３４】
ユークリッド幾何学において、図形の集合が与えられたとき、合同関係は同値関係であり、図形の集合全体を、商空間として、合同な図形からなる部分集合の直和に分割する。また、相似関係も同値関係であり、図形の集合全体を、商空間として、相似な図形からなる部分集合の直和に分割する。合同関係と相似関係はアフィン変換の例である。群論における対称関係は、図形の集合全体を、商空間として、対称な図形からなる部分集合の直和に分割する。
【００３５】
電子商取引では、「電子商品であること」は同値関係であるが、「電子取引」は半順序（partially ordered）関係であることに留意する。集合Ｘ上の２項関係Ｓは、次の３つの条件を満たすとき、半順序関係である。
１）（∀ｘ∈Ｘ）［ｘＳｘ］（反射律）
２）（∀ｘ，ｙ∈Ｘ）［ｘＳｙ，ｙＳｘ⇒ｘ＝ｙ］（反対称律）
３）（∀ｘ，ｙ，ｚ∈Ｘ）［［ｘＳｙ⇒ｙＳｚ］⇒ｘＳｚ］（推移律）
【００３６】
半順序関係をもつ集合を半順序集合（partially ordered set）と呼び、頭文字を取って、しばしばポセット（poset）ともいう。集合の２つの要素ｘ、ｙがｘＳｙか、ｙＳｘのいずれかであるとき、比較可能であるという。どの２つの要素も比較可能な半順序集合を全順序集合（totally ordered set）という。
【００３７】
電子取引の関係は、売り手と買い手の関係が非対称であり、対称律を満たさず、反対称律を満たすため、半順序関係となる。一方、電子商品であるという関係は、売り手にとっての電子商品は買い手にとっての電子商品でもあるから、対称であり、同値関係となる。
【００３８】
同値関係について強弱を定義することができる。１つの集合Ｘにおける２つの同値関係Ｒ、Ｓについて、ｘＲｙ⇒ｘＳｙであるとき、ＲはＳより強い、ＳはＲより弱いという。また、Ｒによる類別はＳによる類別より細かい、Ｓによる類別はＲによる類別より粗いという。最も強い同値関係は、「同じものである」という同値関係であり、最も弱い同値関係は、Ｘの任意の２つの要素が同値であるとする同値関係である。
【００３９】
［５］商空間（等化空間）
Ｘを位相空間とする。ｆを全射かつ連続な写像であって、各点ｘ∈Ｘを、ｘを含む部分集合である同値類ｘ／〜∈Ｘ／〜に写像する商写像（quotient map）（しばしば等化写像（identification map）とも呼ばれる）であるとする。
ｆ：Ｘ→Ｘ／〜
ここで、既に説明したように、「写像ｆ：Ｘ→Ｙが全射である」とは、
（∀ｙ∈Ｙ）（∃ｘ∈Ｘ）［ｆ（ｘ）＝ｙ］
を意味する。
【００４０】
Ｘの部分集合Ｘ０⊆Ｘに対して、
Ｘ０が開である⇔ｆ−１（Ｘ０）｜ｙ∈ＡがＸにおいて開である（これはｆが連続であることを意味する）
が成り立つような全射写像ｆを考えた場合、Ｘ／〜を商写像（または等化写像）ｆによる商空間（または等化空間）と呼ぶ。商空間が等化空間とも呼ばれる理由がある。それは、既に述べたように、商空間は、各要素である同値類ｘ／〜∈Ｘ／〜を、ｘ／〜に含まれる点ｘ∈Ｘと同一視することにより得られるからである。
【００４１】
［６］接着空間
一般に、集合Ａと集合Ｂに共通の要素がない、すなわちＡ∩Ｂ＝φのとき、ＡとＢは互いに素（mutually disjoint）であるという。互いに素である集合Ａと集合Ｂの和集合Ｃを特に直和（disjoint union）（別名、「排他的論理和」）といい、
【数４】
と表す。逆に集合Ｃは互いに素である２つの集合Ａと集合Ｂに直和分解されるということができる。
【００４２】
さて、位相空間Ｘから始めて、これに別の位相空間Ｙを接着する。図１は、２つの互いに素である位相空間Ｘ、Ｙから接着空間が生成される様子を説明する図である。
【数５】
は、接着写像（attaching map）ｆによってＹをＸに接着（attach）することによって得られる接着空間（attaching space）である。この接着写像ｆは、各点ｙ∈Ｙ０｜Ｙ０⊂Ｙをその像ｆ（ｙ）∈Ｘと同一視することにより同値関係を規定するものである。
【００４３】
接着写像ｆは、ｆ：Ｙ０→Ｘである連続写像である。ただしＹ０⊂Ｙである。このように、接着空間
【数６】
は商空間の一例であり、
【数７】
である。この場合における等化写像（identification map）ｇは、
【数８】
である。すなわち、等化写像ｇは、互いに素である２つの位相空間Ｘ、Ｙの直和
【数９】
を、接着写像ｆによって規定される同値関係による同値類の直和
【数１０】
に写像する。
【００４４】
［７］制限と包含
任意の関数ｇ：Ｙ→Ｚに対して、ｇのＸ（Ｘ⊆Ｙ）への制限（restriction）とは、
【数１１】
である。ここで
ｉ：Ｘ→Ｙは、包含（inclusion）である。すなわち
∀ｘ∈Ｘ，ｉ（ｘ）＝ｘ
である。
【００４５】
［８］連続写像のエクステンションとレトラクション
位相空間Ｘ、Ｙと、部分空間Ａ⊂Ｘに対して、ｆ｜Ａ：Ａ→Ｙを満たす連続写像ｆ：Ｘ→ＹをＡからＸへの写像ｆ｜Ａの連続エクステンション（または単にエクステンション）という。エクステンションは部分関数である。
【００４６】
制限（restriction）ｒは、ｒ：Ｘ→Ａを満たす恒等写像１Ａ：Ａ→Ａの連続エクステンションである。したがって、ｒ｜Ａ＝１Ａである。
【００４７】
Ａ⊂Ｘに対して、
【数１２】
を満たすレトラクション（retraction）ｒ：Ｘ→Ａがあるならば、ＡをＸの変形レトラクト（deformation retract）と呼び、
【数１３】
で表す。
もし、Ａがただ一つの点Ａ＝｛ａ｝⊂Ｘであるならば、Ａはレトラクト可能(retractable)といい、
【数１４】
で表す。
【００４８】
［９］ホモトピー
ホモトピーはエクステンションの一例である。Ｘ、Ｙを位相空間、ｆ，ｇ：Ｘ→Ｙを連続写像、Ｉ＝［０，１］とする。ホモトピーは、次のように設計される。
Ｈ：Ｘ×Ｉ→Ｙ
ただし、ｔ∈Ｉに対して、
ｔ＝０のとき、Ｈ＝ｆ
ｔ＝１のとき、Ｈ＝ｇ
が成り立つ。このとき、ｆはｇにホモトピックであるという。
【００４９】
ホモトピーは連続写像のエクステンションであり、
Ｈ｜Ｘ×｛０｝＝ｆｉ０
Ｈ｜Ｘ×｛１｝＝ｇｉ１
ここで
ｉ０＝Ｘ×｛０｝→Ｘ
ｉ１＝Ｘ×｛１｝→Ｘ
【００５０】
さて、ホモトピーレベルにおける位相空間の設計について述べる。２つの位相空間ＸとＹがホモトピー同値（homotopically equivalent）
【数１５】
である、すなわち同じホモトピー型をもつように設計する。それは、次の条件が満たされるように設計することでなされる。
【００５１】
２つの連続写像ｆ：Ｘ→Ｙおよびｈ：Ｙ→Ｘに対して、
【数１６】
である。ここで１Ｘおよび１Ｙは恒等写像、すなわち１Ｘ：Ｘ→Ｘ、１Ｙ：Ｙ→Ｙである。
【００５２】
ホモトピー同値も同値関係の一例であるが、ホモトピー同値はトポロジー同値よりも広い概念である。ホモトピー同値は、変化の後、位相幾何学的にはもはや同値ではなくなる情報の変化を同定することができる。情報はいろいろな操作や処理により変化するが、その操作および処理はホモトピーによって指定され、情報の変化はホモトピー同値によって検証される。事実、不変性（invariance）という抽象の観点からは、ホモトピー同値は集合論的同値よりも抽象性が高い。なぜなら、与えられた集合を要素の追加や削除によって変化させるとき、追加や削除の操作手順と追加もしくは削除された要素を保存することにより、集合をホモトピー同値にすることができるからである。また、後述のセル分解もホモトピー同値になるように行うことにより、セル分解を逆にたどって分解前の状態に戻すことが可能になる。
【００５３】
［１０］セル構造空間（セル空間）設計
セル（cell）は任意の次元（たとえばｎ次元、ただしｎは自然数）の閉球（閉のｎセルと呼ぶ）とトポロジー同値（すなわち同相）である位相空間Ｘである。
【００５４】
閉のｎセル（closed n-cell）を
【数１７】
と表記する。
【００５５】
開のｎセル（open n-cell）を
【数１８】
と表記する（しばしばｅｎとも書かれる）。
【００５６】
閉のｎセル
【数１９】
は、ｎ次元閉球体（closed n-dimensional ball）である。ここで
【数２０】
はｎ次元の実数である。
【００５７】
開のｎセル
【数２１】
は、ｎ次元開球体（open n-dimensional ball）であり、ｎ次元閉球体
【数２２】
の内部である。
【数２３】
は、閉のｎセルの境界であり、これは（ｎ−１）次元球面（sphere）Ｓｎ−１である。
【００５８】
位相空間Ｘに対して、特性写像（characteristic map）
【数２４】
は、連続関数
【数２５】
であり、次を満たす。
【数２６】
【００５９】
【数２７】
は、開のｎセルであり、
【数２８】
は、閉のｎセルである。
【００６０】
位相空間Ｘから、整数集合Ｚによってインデックスが与えられた、Ｘの部分空間であるセルＸｐの有限または無限の系列｛Ｘｐ｜Ｘｐ⊆Ｘ，ｐ∈Ｚ｝を構成することができる。これは、フィルトレーション（filtration）と呼ばれ、次の条件を満たす。ＸｐはＸの被覆（covering）、すなわちＸ＝∪ｐ∈ＺＸｐであり、かつ、Ｘｐ−１はＸｐの部分空間、すなわちＸ０⊆Ｘ１⊆Ｘ２⊆…⊆Ｘｐ−１⊆Ｘｐ⊆…⊆Ｘ（これはスケルトン（skeleton）と呼ばれる）である。最大ｐ次元のスケルトンはｐ−スケルトンと呼ばれる。
【００６１】
Ｃ＝｛Ｘｐ｜ＸＰ⊂Ｘ，ｐ∈Ｚ｝を位相空間Ｘのセル分解（cell decomposition）、あるいは、位相空間Ｘの、閉セルである部分空間Ｘｐへの分割（partition）という。（Ｘ，Ｃ）はＣＷ複体（CW-complex）と呼ばれる。
【００６２】
セル接着写像を保存しながらセル分解を行うとき、セル空間を再利用可能な資源に変えることができる。そのような保存され、共有された情報をセルデータベース（cellular database）と名付け、セルデータベースを管理するシステムをセルデータベース管理システム（cellular database management system または cellular DBMS）と名付ける。
【００６３】
より正確には、J. H. C. Whitehead, "Algebraic Homotopy Theory", Proceedings of International Congress of Mathematics, II, Harvard University Press, pp. 354-357, 1950によれば、位相空間Ｘが与えられたとき、スケルトンＸ０⊆Ｘ１⊆Ｘ２⊆…⊆Ｘｐ−１⊆Ｘｐ⊆…⊆ＸをもったフィルトレーションＸｐを以下の条件を満たす位相空間として帰納的に構成することができる。
（１）Ｘ０⊂Ｘは、その要素がＸの０次元セルである部分空間であり、かつ
（２）ＸｐはＸｐ−１から次のようにして作られる。すなわち、Ｘｐは、接着写像と呼ばれる全射かつ連続な写像
【数２９】
によって、Ｘｐ−１にｐ次元閉球体の直和（disjoint union）
【数３０】
を接着することによって作られる。
【００６４】
言い換えれば、Ｘｐは、直和
【数３１】
を求め、
【数３２】
における各点ｘ、すなわち
【数３３】
を、連続写像
【数３４】
（ただし、各インデックスｉに対してｘ〜ｆｉ（ｘ）である）
によって、その像
【数３５】
と同一視（identify）することによって、Ｘｐ−１から構成される。
【００６５】
このように、Ｘｐは商空間（quotient space）あるいは等化空間（identification space）であり、
【数３６】
と書くことができ、これは、接着空間の一例である。写像Ｆｉはセル
【数３７】
の接着写像の一例である。
【００６６】
フィルトレーション空間（filtration space）は、フィルトレーションとホモトピー同値な（homotopically equivalent）空間である。位相空間ＸとスケルトンＸ０⊆Ｘ１⊆Ｘ２⊆…⊆Ｘｐ−１⊆Ｘｐ⊆…⊆Ｘを合わせてＣＷ空間（CW-space）と呼ぶ。セル複体としては、先に説明したように、これはＣＷ複体（CW-complex）と呼ばれる。
【００６７】
このようにして、写像
【数３８】
を等化写像（identification map）の一例として得る。
【数３９】
【００６８】
各ｎセル
【数４０】
に対する特性写像（characteristic map）
【数４１】
は、
【数４２】
と書ける。
【００６９】
Ｘｐ−１をＸｐの閉の部分空間として埋め込むことは
【数４３】
と書ける。
【００７０】
ＣＷ空間が微分同相（diffeomorphic）であるなら、これは多様体（manifold）空間と等価である。
【００７１】
サイバースペースに構築されるオブジェクトの属性をこのようなセルで表現した空間をセル構造空間（cellular structured space）もしくは単にセル空間（cellular space）という。セルモデリングでは、セルの次元を維持しながら、セル構築（composition）とセル分解（decomposition）が可能である。
【００７２】
セルの次元の例を述べる。たとえばサイバーワールドにおいて、ひとつの属性をもつオブジェクトは、ひとつの属性から他の属性へ移行することができないため、その自由度は０であり、したがってセルの次元は０である。このオブジェクトは、表現レベル（representation level）では点として表される。ここで、属性（attribute）とは、オブジェクトが本来有する特質や特徴を指定するための互いに独立な集合をいう。
【００７３】
属性をふたつ有するオブジェクトでは、一方の属性から他方の属性への移行が可能なため、その自由度は１であり、セルの次元も１である。このオブジェクトは、表現レベルにおいて直線として表すことができる。同様に、属性を３個または４個もつオブジェクトは、それぞれ自由度すなわち次元が２または３であり、それぞれ曲面または球として表現できる。一般に、ｎ個の属性を有するオブジェクトはｎ−１の自由度を有し、次元はｎ−１である。これは、（ｎ−１）次元の球として表現できる。リレーショナルモデルは、ｎ個の属性をもつオブジェクトをリレーショナルスキーマとして表現し、そのインスタンスとしてｎ列のテーブルを生成する。リレーショナルモデルは集合の直積にもとづくものであり、したがってそれは集合論レベルにおける表現といえる。
【００７４】
セル空間は、接着空間に次元の概念を加えたものであり、セル空間設計では、接着空間におけるオブジェクトの属性の次元が規定される。同値類の直和である接着空間において、各同値類に含まれるオブジェクトの属性の次元に不整合がある場合、オブジェクトの属性の次元を調整する処理が行われる。
【００７５】
［１１］表現設計
セル空間レベルでセルの次元が設計された後、表現レベルにおいてセルの表現（presentation）が設計される。表現設計では、オブジェクトの属性のデータ型や桁数などの表現形式が詳細化される。オブジェクトの属性の表現形式に不整合がある場合、表現形式を受容表現（Admissible Representation）に合わせる処理が行われる。オブジェクトの属性の表現形式の不整合には、たとえば、データ型または桁数の違いがあり、データ型変換や桁数変換により、その違いを解消することができる。
【００７６】
［１２］ビュー設計
表現レベルでセルの属性の表現形式が詳細化された後、ビュー（view）、すなわちユーザが見ることのできる範囲が決められる。ユーザは、オブジェクトの集合のうち、関心のある部分だけを適当な形式で見たいという要求がある。また、セキュリティ上の理由などによりユーザが参照することのできる範囲を制限しなければならない。そのため、ビュー設計では、ユーザ向けに参照可能なオブジェクトの部分集合や、閲覧可能なオブジェクトの属性を制限したビューが決められる。
【００７７】
［１３］インクリメンタリモジュラな抽象階層
これまで述べてきたホモトピー、集合、位相空間、接着空間、セル空間、表現、ビューの各抽象レベルは、インクリメンタリモジュラな抽象階層（incrementally modular abstraction hierarchy）を形成する。
１．ホモトピーレベル
２．集合論レベル
３．位相空間レベル
４．接着空間レベル
５．セル空間レベル
６．表現レベル
７．ビューレベル
【００７８】
これらの階層は、モジュール化されており、各階層においてインクリメンタルに情報を操作していくことが可能であり、サイバーワールドの不変量（invariant）を示す同値関係を階層的に継承する上できわめて有用である。
【００７９】
まず、複数のオブジェクト集合の特定の要素について同値にする対象が選ばれる。次に、オブジェクト集合に位相が規定され、位相空間において同値関係が規定されることにより、複数のオブジェクト集合は、同値類の直和である接着空間として設計される。さらに、セル空間において同値セルとそれ以外のセルにセル分解されることにより、セル空間レベルまで同値関係が継承される。
【００８０】
さらには、受容表現にもとづいてセルの表現形式を規定することにより表現レベルまで同値関係が継承され、最後にユーザのビューが規定されることによりビューレベルまで同値関係が継承される。表現レベルの１つのインスタンスとして、受容表現を規定するための受容表現レベルを設けておけば、オブジェクトを表現レベルで同値にすることができる。
【００８１】
このようにインクリメンタリモジュラな抽象階層モデルでは、同値関係を抽象階層間で継承しながら、オブジェクトの満たすべき仕様を各階層において設計するため、情報の追加、削除、修正をインクリメンタルに行いながら、抽象階層間を行き来してオブジェクトの仕様を詳細化できる。また、こうして設計されたオブジェクトは再利用可能な形で部品化することができる。
【００８２】
集合Ｘの部分集合からなる集合Ｓにおいて、Ｓに属するすべての集合の和集合がＸに等しいとき、Ｓを集合Ｘの被覆（covering）という。ｎ個の情報システムの統合を行うとき、「経営上の業務統合決定」は、インクリメンタリモジュラな抽象階層の上で、ｎ個の集合の被覆を作ることの決定がなされたことに相当する。ここで、業務は別々の機関のものであってもかまわない。ｎ個の集合は一般には重なりがある。たとえば、複数の業務に同じ社員が参加することなどがあるからである。このｎ個の集合の被覆が、インクリメンタリモジュラな抽象階層間で継承されることにより、業務統合が実装される。言い換えれば、ホモトピーレベル、位相空間レベル、接着空間レベル、セル空間レベル、表現レベル、およびビューレベルのそれぞれで業務の被覆が生成されることが、業務統合になる。いったん被覆が生成されると、ｎ個の情報システムの間の統合および操作は、インクリメンタリモジュラな抽象階層の上ですべて被覆を通して行われる。その結果、ｎ個の情報システムの間の統合および操作は、いずれも線形になる。このように、インクリメンタリモジュラな抽象階層によれば、ｎ個の情報システムの間で被覆という線形インタフェイスを構成して線形インターオペラビリティを実現することができる。
【００８３】
また、インクリメンタリモジュラな抽象階層モデルにおける位相空間は、ハウスドルフ空間（Hausdorff space）すなわちＴ２位相空間に限られない。Ｔ２位相空間では、分離公理により、異なる２点が開集合で分離できるが、異なる２点を開集合で分離することのできないＴ０位相空間やＴ１位相空間であっても、同様に接着空間が設計できることに留意する。したがって、抽象階層モデルは、非常に汎用性が高いものである。
【００８４】
接着空間は、主要な企業や公的機関で用いられている有力な商用の情報システムに共通した特性を接着空間という形で異なる情報システム間で同値になるように抽象化し、モデル構築する。このように、接着空間は、異種情報システムを線形統合することのできる斬新な情報モデルであり、統合作業量の組み合わせ爆発を避けることに大いに貢献する。接着空間レベルにおける線形統合後の線形インタフェイス生成の自動化のために、上記のインクリメンタリモジュラな抽象階層が用いられる。この抽象階層によれば、同値関係が下位の階層まで継承されるため、既存の情報システムに対するインタフェイスを与えて、統合システム規模のタスクを実行するための線形インターオペラビリティを実現することができる。
【００８５】
比較のために、リレーショナルデータベースシステムを例に挙げて説明する。リレーショナルデータベースシステムにおいて、リレーションはタップルの集合である。リレーションに新たなタップルが挿入されたり、既にあるタップルが削除されたり、タップルの属性値が修正されることにより、リレーションは時間とともに変化していく。たとえば、リレーションとして「社員（社員番号，氏名，所属，入社年度）」を考える。新しい社員が入社した場合、リレーション「社員」にその社員を表すタップルを挿入しなければならない。一方、ある社員が退職すると、リレーション「社員」にその社員を表しているタップルを削除しなければならない。また、配置換えにより、ある社員の配属先が変わった場合、その社員のタップルにおいて属性「所属」の値を修正しなければならない。
【００８６】
このように、リレーショナルデータバースでは、タップルの挿入、削除、修正により、リレーションが時間とともに変化していく。しかしながら、リレーションには、社員の社員番号、氏名、所属、入社年度のデータを表しているという固有の性質があり、これは時間に対して不変である。リレーションにはこのように時間に対して不変な構造があり、これをリレーションスキーマと呼んでいる。
【００８７】
リレーショナルデータベースモデルは、集合論にもとづくものであるから、位相空間のレベルで同値関係を定義することができない。したがって、複数の異なるデータベースを統合しようとすると、ＩＤのつけなおしなど、データベースの再設計を行う必要があり、工数爆発の問題が起こる。それに対して、インクリメンタリモジュラな抽象階層モデルでは、上位概念で規定された同値関係を表現レベルまで落とし込むことができるため、複数の異なる情報システムの統合が線形操作で可能となる。すなわち情報システムの各要素のインタフェイスは、接着空間に一回変換するだけでとることができ、ｎ要素でｎ回の変換でインターオペラビリティが保証され、インタフェイスの数は線形である。
【００８８】
このように、本発明の抽象階層モデルに対して、従来のリレーショナルモデルは、同値関係をモデル化していないため、情報の統一的な扱いができない。せいぜい、テーブル間の関係を示す別テーブルを、パッチを当てる要領で設けてインタフェイスをとろうとしているが、これではインタフェイスの数が指数関数的に増える。一方、ＥＲ（Entity Relation）モデルを基本とするＳＡＰ、ＵＭＬ(Unified Modeling Language)なども、これらはすべて直観的なグラフ理論モデルであり、そのモデル自身が同値関係を扱うことができないため、同様の問題が起こる。これが社会基盤情報システムの現状であり、システムが明確なインターオペラビリティをもたないことが大きな問題となっている。
【００８９】
［１４］応用例
［１４．１］Ｗｅｂ情報モデリング
通常、Ｗｅｂ情報マネージメントシステムのやるべき仕事は、Ｗｅｂグラフィックスを用いて情報を可視化することを通して、人間の認識との間で非常に近い相互作用をもちながら、Ｗｅｂ上の情報を管理することである。Ｗｅｂグラフィックスの仕事は、人間の理解のためにグラフィックススクリーンにいろいろなイメージを投影することである。人間は、ディスプレイ空間に表示されたイメージを人間の認識空間における認識対象物にリンクすることによって、表示されたイメージを理解している。しばしば、幾何学的に正確な表示であっても、サイバーワールドでは通常は本質的な情報ではない、優先度の低い幾何学的形状によって、人間の認識を誤りに導くことがある。Ｗｅｂ情報マネージメントに対してＷｅｂグラフィックスは、サイバーワールドの変化に合った速度で、人間が即座に認識できるようにスクリーン上に重要なメッセージを伝えることができなければならない。以下、簡単な例を挙げて説明する。
【００９０】
［１４．２］エレクトロニックファイナンスのＷｅｂ情報モデリング
エレクトロニックファイナンスにおいて、顧客Ｘが、Ｗｅｂサーフィンしているときに、金融取引会社ＹのホームページのＷｅｂページに投稿されている収益の期待できるファンドＹ０を見つけたとする。この時点では、顧客ＸはＷｅｂで「ウインドウショッピング」をしている段階であるから、顧客Ｘと取引会社Ｙはファンドをまだ共有していない。したがって、ＸとＹは互いに素であり、共通要素を持たない。すなわち、
【数４４】
と表記することができる。一般化のために、ＸとＹを位相空間とする。ファンドＹ０は金融取引会社Ｙの属性の一部であるから、Ｙ０⊂Ｙが成り立つ。図２は、Ｗｅｂ上のエレクトロニックファイナンスのプロセスをＷｅｂグラフィックスにおいて図示したものである。次に、ファンドが取引のために特定された後、顧客Ｘは取引会社Ｙとどのようにして関係づけられるかを述べる。ここで提案するＷｅｂ情報モデルは、顧客Ｘと取引会社Ｙの関係を接着写像ｆによって正確に表現し、また、「ファンドＹ０が取引のために特定されている」という状況を２つの互いに素である位相空間Ｘ（顧客）と位相空間Ｙ（金融取引会社）の接着空間として表現する。この接着空間は、顧客Ｘから始めて、金融取引会社Ｙを顧客Ｘに接着することにより得られる。ここで、ＹのＸへの接着は、連続写像ｆを介して、各点ｙ∈Ｙ０｜Ｙ０⊆Ｙをその像ｆ（ｙ）∈Ｘと同一視することによって行われ、その結果、ｘ〜ｆ（ｙ）｜∀ｙ∈Ｙ０である。このように、〜で表記される同値は、Ｗｅｂ情報の接着空間モデルとして接着空間を作成するために、Ｗｅｂ情報モデリングにおいて中心的な役割を果たす。
【００９１】
上記の接着空間モデルは、エレクトロニックマニュファクチャリングにおいてもまったく本質的に等しく適用することができる。エレクトロニックマニュファクチャリングプロセスを管理し、表示するために正確に同一の技術が要求される。エレクトロニックマニュファクチャリングが市場の需要に効果的に即応するためには、いかにしていろいろなサイズのコンポーネントを統一したデザインで組み立てるかを指定しなければならない。先に提示したエレクトロニックファイナンスは、顧客と取引会社をエレクトロニックマニュファクチャリングのコンポーネントとして組み立てることであると考えることにより、エレクトロニックファイナンスのためのＷｅｂ情報マネージメントシステムとＷｅｂグラフィックスは、実際にエレクトロニックマニュファクチャリングに適用可能となる。もし、異なるアプリケーションに異なる技術を使うとなると、急成長しているサイバーワールドは、タイムリーにＷｅｂ情報マネージメントシステムで管理することも、Ｗｅｂグラフィックスで表示することもできなくなる。
【００９２】
［１４．３］エレクトロニックマニュファクチャリングのＷｅｂ情報モデリング
接着空間モデルによるエレクトロニックマニュファクチャリングのＷｅｂ情報モデリングはまったく簡単である。基本的には、エレクトロニックマニュファクチャリングと呼ばれるＷｅｂ上のマニュファクチャリングは、エレクトロニックマニュファクチャリングの工程に関する次の情報からなるＷｅｂ情報としてモデル化される。
１）製品仕様
２）組み立て仕様
３）Ｗｅｂ上での部品購入
４）Ｗｅｂ上の組み立てサイトでの購入
【００９３】
各ステップは、必要に応じてより細かいサブステップに分解される。たとえば、ステップ１は次のサブステップに分解できる。
１．１）電子市場での製品のマーケット調査
１．２）マーケット調査から導き出される製品の要求
１．３）要求を満たすための製品の仕様
【００９４】
エレクトロニックマニュファクチャリングのためのＷｅｂ技術全体の中で核となる部分は、Ｗｅｂ情報モデリングとしてのＷｅｂ上での製品と組み立てのモデリングである。図３は、座席と支持部という２つのコンポーネントをもつ椅子の単純な組み立て例を用いて、最も初歩的な組み立てのモデリングを明確に図示したものである。発展したマニュファクチャリングとしてのエレクトロニックマニュファクチャリングにおいて、製品のコンポーネントは、モジュール化されており、より品質の高いコンポーネントを買うため、最も有効なアップグレードを行うため、あるいは修理するために置き換え可能に構成されている。
【００９５】
エレクトロニックファイナンスとエレクトロニックマニュファクチャリングが接着空間と同値にもとづいて同一の情報モデリングを共有することは明らかである。
【００９６】
［１５］実施例
図４は、実施の形態に係るソフトウエア開発支援装置１００の構成を示す。オブジェクト集合記憶部１９０は、ソフトウエア開発に利用されるオブジェクトの集まりを保持する。ソフトウエア開発に利用されるオブジェクトすなわちソフトウエア部品は、データ構造体やプログラムモジュールである。ソフトウエア開発支援装置１００は、オブジェクト集合記憶部１９０に格納されたオブジェクトの集まりを参照する。ソフトウエア開発支援装置１００は、オブジェクト集合記憶部１９０を介さずに、ウェブ上の情報システムからオブジェクト集合を取得して参照してもよい。以下、実施の形態では、説明の便宜上、２つのオブジェクト集合の間に所定の対応関係またはインタフェイスを定義する場合を説明するが、これはより一般的に複数のオブジェクト集合を参照してそれらの間にインタフェイスを定義する場合の一例に過ぎない。
【００９７】
ソフトウエア開発支援装置１００は、ホモトピーレベル処理ブロック１１０、集合レベル処理ブロック１２０、位相空間レベル処理ブロック１３０、接着空間レベル処理ブロック１４０、セル空間レベル処理ブロック１５０、表現レベル処理ブロック１６０、およびビューレベル処理ブロック１７０を含み、それぞれ既に述べたインクリメンタリモジュラな抽象階層モデルにおける各階層レベルの処理を行う。
【００９８】
集合レベル処理ブロック１２０は、オブジェクト集合記憶部１９０に格納されたオブジェクトの集まりに集合演算を適宜施して、設計対象となる２つのオブジェクト集合を特定する。位相空間レベル処理ブロック１３０は、集合レベル処理ブロック１２０が特定した２つのオブジェクト集合に対して位相を規定することで、２つのオブジェクト集合はそれぞれ位相空間Ｘ、Ｙとして設計する。この時点で２つの位相空間Ｘ、Ｙは互いに素であり、これらの位相空間Ｘ、Ｙの直和あるいは排他的論理和である
【数４５】
が確定する。
【００９９】
接着空間レベル処理ブロック１４０は、図５にその詳細な構成を示すように、同値関係設定部４４、同値関係保持部５２、対応要素抽出部２０、接着写像取得部２２、等化写像取得部２４、手順取得部２６、および手順記録部２８を含む。
【０１００】
同値関係設定部４４は、２つのオブジェクト集合に適用したい同値関係の入力をユーザから受け付ける他、ユーザの入力をもとにして自動的に同値関係を生成する。ユーザが同値関係を設定しやすいように、同値関係保持部５２は同値関係の候補があらかじめ格納されている。また、ユーザがオブジェクト集合の要素を指定して同値関係を記述することのできるインタフェイスを設けてもよい。
【０１０１】
同値関係設定部４４により設定された同値関係（以下、目的同値関係ともいう）は、対応要素抽出部２０へ伝えられる。対応要素抽出部２０は、２つのオブジェクト集合において対応関係を定義すべき構成要素（以下、「対象要素」ともいう）を、目的同値関係をもとに抽出する。その際、ユーザが１つのオブジェクト集合において対象要素の一方を指定し、対応要素抽出部２０が目的同値関係をもとに他方のオブジェクト集合から対応する対象要素を抽出するようにしてもよい。
【０１０２】
対応要素抽出部２０により対応しあうことが判明した対象要素は、ひとつの部分位相空間、すなわち同値類を形成し、接着空間モデルの理論的保証により、同値類の排他的論理和として接着空間が形成される。同値類は同値関係で規定される不変量をもとに分類されるため、オブジェクト集合を客観的に分類することができ、分類の結果にはシステム設計者による個人差が含まれない。また、一方の対象要素を決めると、他方の対象要素が決まるため、前述のごとく、対応関係またはインタフェイスの数が線形になり、インターオペラビリティが保証されることになる。
【０１０３】
目的同値関係が決まると、対象要素間がどのような意味において対応するか、その関係も一意に決まる。そのため、接着写像取得部２２は対象要素間の対応を示す接着写像ｆを特定することができる。接着写像ｆが決まると、接着空間も、
【数４６】
と定まる。接着空間は、もとは共通部分をもたない位相空間ＸとＹの間に、接着写像ｆを媒介として対応関係を持たせた位相空間である。
【０１０４】
等化写像取得部２４は、位相空間ＸとＹの単なる排他的論理和の空間から、接着写像ｆによって定まる接着空間への写像である等化写像ｇを取得する。等化写像ｇは、現実には、その定義から位相空間Ｘ、Ｙおよび接着写像ｆによって記述することができる。
【０１０５】
手順取得部２６は、同値関係設定部４４から目的同値関係、対応要素抽出部２０から対象要素、接着写像取得部２２から接着写像ｆ、等化写像取得部２４から等化写像ｇの入力を受け、ユーザにより指定された対象要素および目的同値関係（以下、これらを「注目手順」ともいう）をホモトピーとして、一連の処理の結果で特定される、
・位相空間Ｘ、Ｙ
・目的同値関係
・接着写像ｆ
・等化写像ｇ
と関連づけて手順記録部２８へ記録する。
【０１０６】
セル空間レベル処理ブロック１５０は、図６にその詳細な構成を示すように、セル接合部６２、セル次元調整部６４、および対応テーブル保持部６６を含む。セル空間レベル処理ブロック１５０は、接着空間レベル処理ブロック１４０において目的同値関係をもとに接着空間として設計された複数のオブジェクト集合の仕様を継承して、セル空間レベルでオブジェクト集合の仕様を詳細化する。セル構造空間モデルは、接着空間モデルに次元を導入したものであり、オブジェクトの属性のＩＤや属性の個数に関する仕様がセル空間レベルで詳細化されることになる。
【０１０７】
セル接合部６２は、２つのオブジェクト集合間で目的同値関係により対応関係にある２つの対象要素を接合し、各オブジェクト集合に属するオブジェクトの属性をセルで表現する。セル次元調整部６４は、対応する２つの対象要素間に属性の次元に関する不整合がある場合、その不整合を解消するための処理を行う。セルの次元に関する不整合として、対象要素の属性のＩＤや個数の違いなどがある。セル次元調整部６４は、必要に応じて、２つの対象要素間で属性のＩＤや属性の個数の不揃いを調整し、２つの対象要素間の属性の対応関係を示すテーブルを対応テーブル保持部６６に格納する。
【０１０８】
表現レベル処理ブロック１６０は、図７にその詳細な構成を示すように、表現生成部７２、表現形式調整部７４、および変換テーブル保持部７６を含む。表現レベル処理ブロック１６０は、セル空間レベル処理ブロック１５０においてセル空間レベルで詳細化されたオブジェクト集合の仕様を継承して、表現レベルでオブジェクト集合の仕様をさらに詳細化する。表現レベルでは、セルの具体的な表現形式を決めるため、オブジェクトの属性のデータ型や桁数などに関する仕様が詳細化されることになる。
【０１０９】
表現生成部７２は、２つのオブジェクト集合のそれぞれに属するオブジェクトの属性の表現を生成する。表現形式調整部７４は、目的同値関係により対応関係にある２つの対象要素間に表現レベルの不整合がある場合に、その不整合を調整するための処理を行う。表現レベルの不整合として、対象要素の属性のデータ型や桁数の違いなどがある。データ型には、ブール値、符号付き整数、正の整数、実数、倍精度実数、文字型などがあり、表現形式調整部７４はこれらのデータ型を変換して対象要素のデータ型を揃えてもよい。また、データ型が同じでも文字列の桁数や数値の有効桁数などの桁数が異なる場合には、表現形式調整部７４は２つの対象要素間で属性の桁数を調整して揃えてもよい。その他の不整合の例として、計量や貨幣などの単位の違いがあり、変換式を用いて、一方の単位系が他方の単位系に変換される。
【０１１０】
表現形式調整部７４は、位相空間Ｙを位相空間Ｘに接着する場合、表現レベルにおいて、位相空間Ｘのオブジェクト集合の対象要素と位相空間Ｙのオブジェクト集合の対象要素の属性のデータ型や桁数を比較して、相対的に精度が高い方の属性に揃えて、データ型や桁数を変換する。３つ以上のオブジェクト集合の対象要素間で属性の表現レベルの不整合を調整する場合も同じであり、表現形式調整部７４は、複数のオブジェクト集合の対応する対象要素の属性表現の内、最も精度の高い属性表現を選んで、他の精度の低い対象要素の属性表現をその精度の高い対象要素の属性表現に合わせるように調整する。これにより、精度の異なる対象要素の接着後に、データ型変換や桁落ちなどにより元のデータが失われるのを防ぐことができる。
【０１１１】
表現形式調整部７４は、最大の文字数や桁数をもった受容表現をもった表現フィルタとして作用し、当該表現フィルタを通過した表現は、表現レベルで同値になる。表現形式調整部７４は、表現の不整合の調整をした場合の変換規則を記述したテーブルを変換テーブル保持部７６に格納する。
【０１１２】
ビューレベル処理ブロック１７０は、ユーザに合わせたビューを設定し、ビューにしたがってオブジェクト集合をディスプレイなどに表示する。
【０１１３】
ホモトピーレベル処理ブロック１１０は、ソフトウエア開発支援装置１００の各処理ブロックがオブジェクト集合に対して操作を行った際、その操作によって生じるオブジェクト集合の変化がホモトピー同値になるように保証する。ホモトピーレベル処理ブロック１１０は、手順記録部２８に記録された接着空間生成に係る注目手順、対応テーブル保持部６６に格納されたセルの次元の不整合の対応関係を示すテーブル、変換テーブル保持部７６に格納されたセルの表現の変換規則を示すテーブルを利用し、各操作によってオブジェクト集合にもたらされた変化を逆にたどることにより、オブジェクト集合を変化前の状態に戻すことができる。
【０１１４】
このようにして、集合レベル処理ブロック１２０から始めて、位相空間レベル処理ブロック１３０、接着空間レベル処理ブロック１４０、セル空間レベル処理ブロック１５０、表現レベル処理ブロック１６０、およびビューレベル処理ブロック１７０へと、同値関係を継承しつつ、２つのオブジェクト集合の仕様を段階的に詳細化していくことで、２つのオブジェクト集合が表現レベルまで同値となって出力される。このようにインクリメンタリモジュラな抽象階層モデルにもとづくソフトウエア開発支援装置１００は、同値関係を、集合レベルから位相空間レベル、接着空間レベル、セル空間レベル、表現レベル、およびビューレベルまで保証する一貫性のあるフィルタとして機能し、フィルタを通過したオブジェクト集合は同値関係が数学的に保証されたインスタンスとなって出力される。
【０１１５】
対応づけたい構成要素が複数あれば、それぞれの構成要素について目的同値関係を設定することによって、同様に接着写像が規定され、最終的に複数のオブジェクト集合間で対応する要素が接着された結果が出力される。一方のオブジェクト集合が注目する構成要素をｎ個もてば、そのｎ個のそれぞれについて、他方のオブジェクト集合のいずれかの構成要素との対応関係が特定されるため、インタフェイス数は線形であり、工数爆発の問題が解決する。
【０１１６】
本実施の形態によれば、同値関係を設定すれば、複数のオブジェクト集合の構成要素間で対応づけができ、対応していない構成要素はそのまま残しつつ、同値関係にある構成要素については常に同じ情報をもつことができ、不変量を切り口に分類や対応づけができるので、データ利用性が向上し、ソフトウエア開発の効率を各段に高めることができる。
【０１１７】
［１６］具体例
以上の構成のソフトウエア開発支援装置１００によるソフトウエア開発支援手順の具体例を説明する。ソフトウエア開発支援装置１００が各種プログラムモジュールをもとにソフトウエアを開発する際、プログラムモジュール間のインタフェイスを確定し、各プログラムモジュールで利用されるデータの仕様を詳細化する。［１６．１］でデータの設計手順を述べ、［１６．２］でプログラムモジュールの設計手順を述べる。
【０１１８】
［１６．１］データ設計
ソフトウエアにおいて利用される複数のオブジェクト集合の一例として、シューズショップＸのオブジェクト集合３００と、シューズメーカーＹのオブジェクト集合２００を考える。これらのオブジェクト集合は、集合レベル処理ブロック１２０によって設計され、オブジェクト集合記憶部１９０に格納されている。これらのオブジェクト集合はデータベースとして管理されているものであってもよい。位相空間レベル処理ブロック１３０は、シューズショップＸのオブジェクト集合３００を位相空間Ｘとして、シューズメーカーＹのオブジェクト集合２００を位相空間Ｙとして設計する。この時点で、２つの位相空間Ｘ、Ｙは互いに素である。
【０１１９】
接着空間レベル処理ブロック１４０は、オブジェクト集合記憶部１９０に格納されたシューズショップＸのオブジェクト集合３００を位相空間Ｘとして、シューズメーカーＹのオブジェクト集合２００を位相空間Ｙとして参照し、同値関係をもとに２つの位相空間Ｘ、Ｙから接着空間を生成する。図８に、接着空間レベル処理ブロック１４０により２つの位相空間が接着される様子を示す。
【０１２０】
いま、シューズメーカーＹの製造する特定の運動靴Ｙ０をシューズショップＸが仕入れて、販売しているとする。このとき、ソフトウエアの開発者は、シューズショップＸのオブジェクト集合、シューズメーカーＹのオブジェクト集合との間でこの運動靴Ｙ０をプログラム上では同一のオブジェクトとして扱いたい。同値関係設定部４４は、シューズメーカーＹとシューズショップＸの位相空間の間で、注目すべき対象要素である運動靴Ｙ０を同値関係にあるものとして設定する。
【０１２１】
対応要素抽出部２０は、シューズメーカーＹの運動靴Ｙ０（符号２０２）に対応するシューズショップＸの運動靴ｆ（Ｙ０）（符号３０２）を抽出する。接着写像取得部２２は、この対応関係をもとに、接着写像ｆ：Ｙ０→Ｘ｜Ｙ０⊆Ｙを取得する。
【０１２２】
等化写像取得部２４は、接着写像取得部２２が取得した接着写像ｆによって、シューズショップＸとシューズメーカーＹの２つの位相空間の排他的論理和を接着空間
【数４７】
に写像する等化写像ｇを取得する。すなわち、等化写像取得部２４は、等化写像
【数４８】
を取得する。ここで、
【数４９】
であり、同図に示すように、運動靴ｆ（Ｙ０）（符号４０２）において２つの位相空間Ｘ、Ｙが接着する。
【０１２３】
図９は、シューズメーカーＹの位相空間における運動靴２０２のセル構造を説明する図である。運動靴２０２は、セルの属性として、靴のブランド名２１０、会社名２１２、種類２１４、サイズ２１６、色２１８、素材２２０、希望小売価格２２２、製造原価２２４、および原産国２２６を含む。
【０１２４】
図１０は、シューズショップＸの位相空間における運動靴３０２のセル構造を説明する図である。運動靴３０２は、セルの属性として、靴のブランド名３１０、メーカー名３１２、種類３１４、サイズ３１６、色３１８、素材３２０、売価３２２、および販売店３２４を含む。
【０１２５】
セル空間レベル処理ブロック１５０のセル接合部６２は、図９に示すシューズメーカーＹの位相空間における運動靴２０２と、図１０に示すシューズショップＸの位相空間における運動靴３０２をセルレベルで接合するため、共通する属性を互いに対応づける。靴のブランド名２１０、３１０、種類２１４、３１４、サイズ２１６、３１６、色２１８、３１８、素材２２０、３２０は属性名が一致するため、共通する属性として対応づけられる。
【０１２６】
シューズメーカーＹの運動靴２０２の会社名２１２と、シューズショップＸの運動靴３０２のメーカー名３１２は、属性名は異なるが同一の要素である。そこで、セル空間レベル処理ブロック１５０のセル次元調整部６４は、シューズメーカーＹ側の属性名をシューズショップＸ側の属性名に対応づけ、接合セルにおける属性名を「メーカー名」に統一することで不整合を調整し、シューズメーカーＹ側の「会社名」をシューズショップＸ側の「メーカー名」に対応づける関係を記述したテーブルを対応テーブル保持部６６に保持する。
【０１２７】
シューズメーカーＹの運動靴２０２とシューズショップＸの運動靴３０２をセルレベルで接合する際、一方の位相空間に属性が存在し、他方の位相空間にはそれに対応する属性が存在しないことがある。たとえば、シューズメーカーＹの運動靴２０２には、原産国２２６という属性があるが、シューズショップＸの運動靴３０２には、それに対応するものがない。逆に、シューズショップＸの運動靴３０２には、販売店３２４という属性があるが、シューズメーカーＹの運動靴２０２には、それに対応するものがない。このように、２つの対象要素間で属性の対応付けをする際、第１の位相空間に属性ａが存在し、第２の位相空間にはそれに対応する属性が存在しない場合、第１の位相空間の属性ａには対応づけられる属性がないとものして処理するか、もしくは第２の位相空間において空の属性ｂを追加して第１の位相空間の属性ａと対応づける処理を行う。たとえば、セル次元調整部６４は、シューズメーカーＹの運動靴２０２の原産国２２６については対応づけられる属性がないとして処理し、一方、シューズショップＸの運動靴３０２の販売店３２４については、空の属性をシューズメーカーＹの運動靴２０２に追加し、シューズショップＸの運動靴３０２の販売店３２４と対応づける処理を行い、属性の個数に関する不整合を調整する。
【０１２８】
属性の個数の調整の他の例として、一方の位相空間に「名前」という１つの属性があり、他方の位相空間には、「姓」と「名」という２つの属性がある場合、実質的には両者は同一の属性であるから、セル次元調整部６４は、「名前」という１つの属性と、「姓」と「名」という２つの属性を対応づけることで、属性の個数の不整合を調整することができる。
【０１２９】
図１１（ａ）〜（ｃ）は表現レベルでの不整合の調整を説明する図である。シューズメーカーＹ側の会社名２１２は、図１１（ａ）に示すように、Ｍ桁の文字列で表現されている。一方、シューズショップＸ側のメーカー名３１２は、図１１（ｂ）に示すように、Ｌ桁の文字列で表現されている。ここで、Ｌ＜Ｍである。表現レベル処理ブロック７０の表現形式調整部７４は、桁数の大きいＭ桁に合わせて、図１１（ｃ）に示すように、接合セルの属性であるメーカー名４１２の表現形式を決めてもよい。
【０１３０】
対象要素の属性の表現形式において桁数の違いがあるときに、桁数の大きい方に合わせて表現することは、「受容表現レベル」の一例である。表現形式調整部７４は、所定の受容表現レベルをフィルタとして用いることにより、対象要素の属性の表現形式の不整合を調整する。
【０１３１】
図１２（ａ）〜（ｄ）も表現レベルでの不整合の調整を説明する図である。シューズメーカーＹ側のサイズ２１６は、図１２（ａ）に示すように、ｉｎｃｈを単位とした実数値で表現されている。一方、シューズショップＸ側のサイズ３１６は、図１２（ｂ）に示すように、ｃｍを単位とした実数値で表現されている。
【０１３２】
ソフトウエアの設計仕様として、ｃｍの単位を採用する場合、表現レベル処理ブロック１６０の表現形式調整部７４は、図１２（ｃ）に示すように、接合セルの属性であるサイズ４１６の表現形式はｃｍを単位とすることにし、シューズショップＸ側のサイズ３１６の属性値を用いる。このとき、表現形式調整部７４は、図１２（ｄ）に示す変換式５１６を変換テーブル保持部７６に格納しておき、属性値の互換性を保つ。このようにいずれかの単位系に合わせることも受容表現レベルの一例である。
【０１３３】
図１３（ａ）〜（ｄ）も表現レベルでの不整合の調整を説明する図である。シューズメーカーＹ側の色２１８は、図１３（ａ）に示すように整数値で表現されている。一方、シューズショップＸ側の色３１８は、図１３（ｂ）に示すように文字列で表現されている。これは、シューズメーカーＹでは靴の色を細かく識別するための番号体系を利用するのに対して、シューズショップＸでは靴の色を顧客が理解しやすい「紺」「紫」などの名称で記述するからである。この違いは、シューズメーカーＹ、シューズショップＸのそれぞれのシステムにおける設計者の設計意図や顧客のニーズにより生じたものである。
【０１３４】
ソフトウエアの設計仕様として、色の表現形式を文字列とする場合、表現レベル処理ブロック１６０の表現形式調整部７４は、図１３（ｃ）に示すように、接合セルの属性である色４１８の表現形式を文字列として、シューズショップＸ側の色３１８の属性値を用いる。このとき、表現形式調整部７４は、図１３（ｄ）に示すように、シューズメーカーＹ側の色を識別する整数値とシューズショップＸ側の色を識別する文字列との間の変換規則を示した変換テーブルを作成して、変換テーブル保持部７６に格納し、属性値の互換性を保つ。このように文字列の表現形式に変換することも受容表現レベルの一例である。
【０１３５】
上記の例では、ソフトウエアの開発者がシューズショップＸとシューズメーカーＹの間で同値関係にある運動靴を指定したが、シューズショップＸと複数のシューズメーカーＹとの間で同値関係を指定してもよい。たとえば、「素材が革である靴」という同値関係をもとに、シューズショップＸの位相空間と、複数のシューズメーカーＹ１，Ｙ２，…，Ｙｎのそれぞれの位相空間との間で対応する構成要素を抽出し、接着空間を生成し、オブジェクトのデータ設計を行ってもよい。
【０１３６】
［１６．２］プログラムモジュールの設計
オブジェクト集合の一例として、プログラムを考え、本実施の形態に係るソフトウエア開発支援装置１００により、複数のプログラムをもとにソフトウエアを開発する手順を説明する。
【０１３７】
図１４（ａ）、（ｂ）は２つのプログラムＸとプログラムＹが統合される様子を説明する図である。これらのプログラムは、いずれも画像処理を行うものであるが、プログラムの開発者が異なるなどの理由で、プログラム構成が異なっているとする。これらのプログラムは、いずれも画像の符号化および復号の機能をもっており、たとえば、電子商取引で売買される商品の画像の符号化および復号を行うことができる。
【０１３８】
集合レベル処理ブロック１２０は、複数のモジュールからなるプログラムＸ、Ｙを集合として設計し、位相空間レベル処理ブロック１３０は、プログラムＸ、Ｙを位相空間として設計する。
【０１３９】
接着空間レベル処理ブロック１４０の同値関係設定部４４は、プログラムＸ、Ｙを構成するモジュールに対して、「符号化処理機能をもつ」および「復号処理機能をもつ」という２つの同値関係を設定する。対応要素抽出部２０は、同値関係設定部４４により設定された２つの同値関係をもとにプログラムＸ、Ｙ間の対応するモジュールを特定し、接着写像取得部２２は、各同値関係による対応関係を与える接着写像ｆ１、ｆ２を取得する。
【０１４０】
これにより、プログラムＹの位相空間は、符号化処理機能をもつモジュールＹ０と、圧縮処理機能をもつモジュールＹ１と、それ以外の機能をもつモジュールの直和
【数５０】
に分割され、一方、プログラムＸの位相空間は、符号化処理機能をもつモジュールでＹ０に対応するｆ（Ｙ０）と、圧縮処理機能をもつモジュールでＹ１に対応するｆ（Ｙ１）と、それ以外の機能をもつモジュールの直和
【数５１】
に分割される。
【０１４１】
等化写像取得部２４は、図１４（ａ）に示すプログラムＸ、Ｙの２つの位相空間の直和を図１４（ｂ）に示す接着空間
【数５２】
に写像する等化写像ｇを取得する。
【０１４２】
図１５（ａ）、（ｂ）は、接着写像により対応づけられた２つのモジュールＡ、Ｂの入出力インタフェイスを説明する図である。モジュールＡの入力に使われている変数は整数型のａ、ｂの２つであり、出力に使われている変数は実数型のｃである。一方、モジュールＢの入力に使われている変数は実数型のｓ、ｔの２つであり、出力に使われている変数は実数型のｕである。接着空間レベル処理ブロック１４０において対応づけられた２つのモジュールＡ、Ｂ間で入力変数、出力変数の名前に違いがあるが、セル空間レベル処理ブロック１５０のセル次元調整部６４は、２つのモジュールＡ、Ｂの入力変数、出力変数の名前を対応が取れるように調整する。また、２つのモジュールＡ、Ｂ間で入力変数、出力変数の個数に違いがあれば、セル次元調整部６４は、２つのモジュールＡ、Ｂの入力変数、出力変数の個数を対応が取れるように調整する。
【０１４３】
表現レベル処理ブロック１６０の表現形式調整部７４は、２つのモジュールＡ、Ｂの入力変数、出力変数のデータ型に違いがあれば、データ型を調整する。モジュールＡの入力変数は整数型であり、モジュールＢの入力変数は実数型であるから、たとえば、モジュールＡの入力変数を実数型に変換する。また、変数が文字型の場合は、表現形式調整部７４は、文字列の桁数の調整を行う。
【０１４４】
図１６〜図１９において、ソフトウエア開発支援装置１００によって、同値関係をもとにモジュールもしくはデータが対応づけられてソフトウエアが開発される手順を説明する。
【０１４５】
図１６（ａ）、（ｂ）は、プログラムモジュールが新しいバージョンに更新される様子を説明する図である。図１６（ａ）のように、新バージョンのモジュールＡｎｅｗと旧バージョンのモジュールＡｏｌｄがあるとする。それぞれ別の開発者が設計したものであってもよい。同値関係によって新バージョンのモジュールＡｎｅｗが旧バージョンのモジュールＡｏｌｄに対応づけられる。また、それに伴い、新バージョンのモジュールＡｎｅｗの入力変数ｓ、ｔが、旧バージョンのモジュールＡｏｌｄの入力変数ａ、ｂにそれぞれ対応づけられ、新バージョンのモジュールＡｎｅｗの出力変数ｕが旧バージョンのモジュールＡｏｌｄの出力変数ｃに対応づけられる。
【０１４６】
このように同値関係で新旧バージョンのモジュールを対応づけることにより、ソフトウエア開発支援装置１００は、図１６（ｂ）のように、旧バージョンのモジュールＡｏｌｄを新バージョンのモジュールＡｎｅｗに置き換えて、更新することができる。ソフトウエア開発支援装置１００は、モジュールの置き換えをホモトピー同値になるように行うため、必要に応じて新バージョンのモジュールＡｎｅｗを旧バージョンのモジュールＡｏｌｄに戻すこともでき、ソフトウエアのデバッグを効率良く行うことができる。
【０１４７】
図１７（ａ）、（ｂ）は、２つのプログラムモジュールが合成される様子を説明する図である。図１７（ａ）のように、モジュールＡは２つのサブモジュールＡ１、Ａ２をもち、モジュールＢは２つのサブモジュールＢ１、Ｂ２をもつ。同値関係によってモジュールＢのサブモジュールＢ１がモジュールＡのサブモジュールＡ１に対応づけられる。また、それに伴い、サブモジュールＢ１の入力変数ｓとサブモジュールＡ１の入力変数ａが対応づけられる。
【０１４８】
図１７（ｂ）のように、同値関係により定まる接着写像によって、モジュールＢのサブモジュールＢ１がモジュールＡのサブモジュールＡ１と同一視されることにより、２つのモジュールＡ、Ｂが合成され、１つのプログラムが生成される。このとき、接着写像で対応づけられたサブモジュールＢ１とサブモジュールＡ１の入出力変数のデータ型や桁数などが調整される。ソフトウエア開発支援装置１００は、モジュールの合成をホモトピー同値になるように行うため、必要に応じて合成されたプログラムから元のモジュールＡ、Ｂを分離して取り出すこともできる。
【０１４９】
このように、ソフトウエア開発支援装置１００は、同値関係をもとにして複数のモジュールを合成したり、合成されたプログラムからモジュールを取り出したりすることができ、ソフトウエアの部品化を進め、再利用性を高めることができる。
【０１５０】
図１８（ａ）、（ｂ）は、２つのプログラムモジュール間でデータが共有される様子を説明する図である。図１８（ａ）のように、２つの変数ａ、ｂを入力して変数ｃを出力するモジュールＡと、２つの変数ｓ、ｔを入力して変数ｕを出力するモジュールＢとがあり、モジュールＢの入力変数ｓとモジュールＡの入力変数ａが同値関係によって対応づけられ、それ以外の変数の間には対応関係がないとする。
【０１５１】
図１８（ｂ）のように、同値関係により定まる接着写像によって、モジュールＢの入力変数ｓがモジュールＡの入力変数ａと同一視されることにより、２つのモジュールＡ、Ｂ間で入力変数の１つが共有される。このように、ソフトウエア開発支援装置１００は、プログラムモジュール間で同値類として対応づけられるデータを共有し、データの利用性を高めることができる。
【０１５２】
図１９（ａ）、（ｂ）は、２つのプログラムモジュールが結合される様子を説明する図である。図１９（ａ）のように、２つの変数ａ、ｂを入力して変数ｃを出力するモジュールＡと、２つの変数ｓ、ｔを入力して変数ｕを出力するモジュールＢとがあり、モジュールＢの出力変数ｕとモジュールＡの入力変数ａが同値関係によって対応づけられ、それ以外の変数の間には対応関係がないとする。
【０１５３】
図１９（ｂ）のように、同値関係により定まる接着写像によって、モジュールＢの出力変数ｓがモジュールＡの入力変数ａと同一視されることにより、モジュールＢとモジュールＡがこの順で結合され、１つのプログラムが生成される。このとき、モジュールＢの出力変数とモジュールＡの入力変数の間でデータ型や桁数などが調整される。このプログラムの結合は、ホモトピー同値になるように行われるため、必要に応じて結合を解除して、モジュールＡとモジュールＢを分離することもできる。このように、ソフトウエア開発支援装置１００は、同値関係をもとにして複数のプログラムモジュールを結合したり、分離したりすることができ、プログラムモジュールの利用性を高めることができる。
【０１５４】
このように、ソフトウエア開発支援装置１００によれば、同値関係にもとづいてソフトウエア部品の合成、置換、連結などの開発工程を線形操作で行うことができるため、ソフトウエア部品の個数が増えても、開発工数爆発が起きることなく、ソフトウエアを効率良く開発することができる。
【０１５５】
上記の具体例では、プログラムモジュールの仕様を特徴づける属性として、入出力インタフェイスを例に挙げ、対応するプログラムモジュール間で入出力インタフェイスの次元や表現形式の不整合を調整することを説明したが、これは属性の一例に過ぎない。プログラムモジュールの仕様を特徴づける他の属性の例として、そのプログラムモジュールが参照する変数を考えてもよい。その場合、対応するプログラムモジュール間で参照変数の次元や表現形式の不整合が調整される。また、プログラムモジュールが利用する関数を属性として考えてもよい。その場合、対応するプログラムモジュール間で関数の次元、すなわち関数名や関数の個数などの不整合が調整される。さらに、その関数の引数や戻り値の次元や表現形式の不整合が調整されてもよい。
【０１５６】
ソフトウエア開発支援装置１００のビューレベル処理ブロック１７０は、ソフトウエア開発者毎に異なるビューを設計してもよい。たとえば、上級のソフトウエア開発者にはプログラムモジュールの内部変数の設計変更ができるように、プログラムモジュール内部のデータ操作が可能なビューを設定する。一方、初級のソフトウエア開発者にはプログラムモジュールの外部インタフェイスの設計変更だけを許すように、プログラムモジュールの内部のデータ操作が不可能なビューを設定する。このように、開発者のプログラミングの経験や技術などのレベルに応じてビューを異ならせてもよい。また、ソフトウエアを複数の開発者が共同開発する場合、各開発者が担当するプログラムエリアに限って設計変更ができるように、開発者毎にビューを異ならせてもよい。後述のようにソフトウエア開発支援装置１００を保守工程で利用する場合は、ビューレベル処理ブロック１７０は、ソフトウエアの保守者毎に異なるビューを設計してもよい。
【０１５７】
［１７］ソフトウエアのライフサイクル管理
ソフトウエア開発のアクティビティには、要求分析、システム設計、プログラム設計、プログラム実装、単体・結合テスト、システムテスト、受け入れテスト、および運用・保守があり、これらの一連のアクティビティがライフサイクルとして管理される。要求分析、システム設計、プログラム設計、およびプログラム実装は、ソフトウエアの開発工程である。開発工程において生成されたソフトウエアのプログラムモジュールについて単体・結合テストが行われ、次にシステム全体の機能面についてシステムテストが行われ、最終的にシステム出荷時の受け入れテストが行われる。これが試験工程である。受け入れテストに合格したシステムは運用され、稼働中にシステムが保守される。これが保守工程である。
【０１５８】
図２０に示すソフトウエアライフサイクル管理装置６００は、開発工程から試験工程を経て、保守工程に至るまでのソフトウエアのライフサイクルを管理する。開発機能ブロック６１０は、既に述べたソフトウエア開発支援装置１００の各機能を有し、抽象階層間でソフトウエア部品集合の同値関係を不変量として継承しながら、ソフトウエア部品集合が満たすべき仕様を抽象階層毎にインクリメンタルに詳細化することにより、与えられた要求仕様に合致するソフトウエアをソフトウエア部品集合から自動生成する。開発機能ブロック６１０により、ソフトウエアの要求分析からシステム設計、プログラム設計、プログラム実装までが実行され、開発されたソフトウエアはソフトウエア記憶部６４０に記憶される。ソフトウエア記憶部６４０は、要求仕様、開発、試験、および保守工程におけるすべてのプログラムを保持する。
【０１５９】
試験機能ブロック６２０は、開発機能ブロック６１０により生成されたソフトウエアが各抽象階層において詳細化された仕様に合致するか否かをテストし、問題が発見された場合に、いずれかの抽象階層において要求条件を修正し、開発機能ブロック６１０は、要求条件が修正された抽象階層から始めて、ソフトウエア部品集合が満たすべき仕様を抽象階層毎にインクリメンタルに詳細化する。
【０１６０】
開発されたソフトウエアの試験は、要求分析、システム設計、プログラム設計、およびプログラム実装のいずれの段階でも行う必要がある。たとえば、試験機能ブロック６２０が、要求仕様に不具合を発見して修正をしたときは、開発機能ブロック６１０は、抽象階層モデルの位相空間レベルや接着空間レベルなどの上位階層にもどって、その階層から設計の詳細化をやり直して不具合を解消する。また、試験機能ブロック６２０が、プログラム実装において、関数の引数の数や変数のデータ型などに不具合を発見した場合は、開発機能ブロック６１０は、抽象階層モデルのセル空間レベルや表現レベルなどの下位階層から設計の詳細化をやり直して不具合を解消する。いずれの階層から作業をやり直すときでも、インクリメンタリモジュラな抽象階層にもとづくソフトウエア開発支援装置１００によれば、新しい要求条件のもと、線形操作でソフトウエアを再構成することができる。
【０１６１】
保守機能ブロック６３０は、運用中のソフトウエアに修正もしくは機能拡張の必要があった場合に、その修正もしくは機能拡張を反映すべき抽象階層において要求条件を変更し、開発機能ブロック６１０は、要求条件が変更された抽象階層から始めて、ソフトウエア部品集合が満たすべき仕様を抽象階層毎に再度インクリメンタルに詳細化する。
【０１６２】
ソフトウエアの保守には、システムの障害への対処もしくは予防のために修正を行うものとして、修正保守（corrective maintenance）と予防保守（preventive maintenance）があり、システムの機能拡張を行うものとして、改善保守（perfective maintenance）と適応保守（adaptive maintenance）がある。
【０１６３】
修正保守は、現行のシステムに障害が起きた場合に、障害の原因を発見して、ソフトウエアの必要な修正を行うものである。修正保守は、ソフトウエアの残存不良を修正する作業であり、一般には仕様の変更はしない。抽象階層モデルを利用した修正保守は、たとえば、セル空間レベルや表現レベルなど比較的下位の階層で要求条件を調整して行われる。
【０１６４】
予防保守は、現実には障害が起きてないが、潜在的な障害の可能性を発見し、システムの故障を未然に防ぐために、システムのある側面を修正、変更することであり、修正保守と同様に抽象階層モデルを利用して行うことができる。
【０１６５】
改善保守は、障害を回避するためにソフトウエアを変更するのではなく、システムのある機能や性能を向上させるためにソフトウエアの変更を行うことである。改善保守は、ソフトウエアの仕様の変更を伴うものである。抽象階層モデルを利用した改善保守は、たとえば位相空間レベルや接着空間レベルなど比較的上位の階層で要求条件を調整した上で、下位の階層に向けて抽象階層を辿りながら、ソフトウエアを再設計することによって行われる。
【０１６６】
適応保守は、ハードウエアやソフトウエアの技術進歩などの変化に応じてソフトウエアの変更を行うものである。適応保守は、障害に対処するものではなく、進化していくシステムに適応させるために変更を行うものである。適応保守も他の保守と同様に抽象階層モデルを利用して行うことができる。
【０１６７】
ソフトウエアの保守工程は、新たな要求を分析し、システムとプログラムの設計を評価し、コードをレビューし、必要に応じて修正を加える点で、ソフトウエアの開発工程およびソフトウエアの試験工程と共通するアクティビティを含んでいる。開発工程および試験工程が抽象階層モデルを利用して行われるように、保守工程も抽象階層モデルを有効に利用して、効率良く行うことができ、保守の負担を軽減することができる。
【０１６８】
一般に、欠陥修正は別の欠陥修正を引き起こす波及効果がある。保守による手直しがシステムの別の部分に影響を与えて、新たな障害を生み出すことがあるからである。一般的にソフトウエア開発は開発者依存であるため、開発者の作成した仕様書を丹念にレビューしても保守による影響を正確に予測することは困難である。しかしながら、本実施の形態のソフトウエアライフサイクル管理装置６００によれば、抽象階層モデルを利用してソフトウエアの開発が行われ、開発者依存の設計要素が排除されるため、保守においても同じ抽象階層モデルを参照することで、何と何が同値関係にあるかを把握した上で、ある箇所の修正が他の箇所にどのような影響を与えるかを的確に予測して正しい修正を効率良く行うことができる。
【０１６９】
修正保守において、ソフトウエアのある部分について同値関係を新たに定義する必要が生じた場合や、最初から定義しておくべきであった同値関係が保守段階で発見された場合でも、抽象階層モデルを参照し、接着空間レベルで同値関係を定義し直し、その同値関係を下位のセル空間レベルや表現レベルにまで落として実装することにより、整合性を保証することができる。また、拡張保守や適応保守において、ソフトウエアに新たな機能を追加する場合や、新たなパラメータを設定する場合でも、抽象階層モデルにおいて適宜新たな同値関係を設定してインクリメンタルにソフトウエアの再設計を行うことができる。また、予防保守において、対応する変数の間でデータ型やデータ長の相違があり、不都合が生じることが予見される場合でも、抽象階層モデルを利用して、これらの変数に同値関係を定義してその部分について不整合を調整することができる。
【０１７０】
このように、本実施の形態のソフトウエアライフサイクル管理装置６００によれば、抽象階層モデルを利用することにより、保守段階で要求の変化が生じても、要求仕様にもとづいて同値関係を定め、設計および実装レベルまでその同値関係を不変量として継承して仕様の詳細化と具体化を図ることができ、変化に対して柔軟かつ効率良く対応することができる。抽象階層モデルを利用することにより、保守工程におけるソフトウエアに対する操作も、開発工程における操作と同じように、線形インターオペラビリティが保証されるため、線形操作で新たな機能の追加や不要な機能の削除を行うことができる。
【０１７１】
ソフトウエアのライフサイクルモデルとして、ウォーターフォールモデル、ラピッドプロトタイピングモデル、スパイラルモデルなどいろいろなモデルが提案されているが、本実施の形態のソフトウエアライフサイクル管理装置６００は、いずれかのライフサイクルモデルに依存するものでもなく、また、いずれかのライフサイクルモデルを前提として適用されるものでもない。もっとも、本実施の形態のソフトウエアライフサイクル管理装置６００をいずれかのライフサイクルモデルに適合させる形で用いることを妨げない。本実施の形態のソフトウエアライフサイクル管理装置６００の主要な利点は、インクリメンタリモジュラな抽象階層モデルを用いることにより、抽象階層間でソフトウエア部品集合間の同値関係を不変量として継承して整合性を保証するとともに、ソフトウエア部品集合の線形統合と線形操作を保証し、ソフトウエアの開発から試験、保守に至るまでのライフサイクルの管理に一貫性をもたせたことにある。
【０１７２】
以上、実施の形態を説明した。実施の形態は例示であり、さまざまな変形例が可能であり、そうした変形例も本発明に含まれることは当業者に理解されるところである。
【図面の簡単な説明】
【０１７３】
【図１】２つの互いに素である位相空間から接着空間が生成される様子を説明する図である。
【図２】顧客と取引会社の位相空間が接着される様子を説明する図である。
【図３】座席と支持部の位相空間が接着される様子を説明する図である。
【図４】実施の形態に係るソフトウエア開発支援装置の構成図である。
【図５】図４の接着空間レベル処理ブロックの構成図である。
【図６】図４のセル空間レベル処理ブロックの構成図である。
【図７】図４の表現レベル処理ブロックの構成図である。
【図８】図５の接着空間レベル処理ブロックにより、２つの位相空間が接着されて接着空間が生成される様子を説明する図である。
【図９】オブジェクトのセル構造を説明する図である。
【図１０】オブジェクトのセル構造を説明する図である。
【図１１】図７の表現レベル処理ブロックにより、表現レベルでの不整合が調整される様子を説明する図である。
【図１２】図７の表現レベル処理ブロックにより、表現レベルでの不整合が調整される様子を説明する図である。
【図１３】図７の表現レベル処理ブロックにより、表現レベルでの不整合が調整される様子を説明する図である。
【図１４】２つのプログラムが統合される様子を説明する図である。
【図１５】接着写像により対応づけられた２つのモジュールの入出力インタフェイスを説明する図である。
【図１６】プログラムモジュールが新しいバージョンに更新される様子を説明する図である。
【図１７】２つのプログラムモジュールが合成される様子を説明する図である。
【図１８】２つのプログラムモジュール間でデータが共有される様子を説明する図である。
【図１９】２つのプログラムモジュールが結合される様子を説明する図である。
【図２０】実施の形態に係るソフトウエアライフサイクル管理装置の構成図である。
【符号の説明】
【０１７４】
２０ 対応要素抽出部、 ２２ 接着写像取得部、 ２４ 等化写像取得部、 ２６ 手順取得部、 ２８ 手順記録部、 ４４ 同値関係設定部、 ５２ 同値関係保持部、 ６２ セル接合部、 ６４ セル次元調整部、 ６６ 対応テーブル保持部、 ７２ 表現生成部、 ７４ 表現形式調整部、 ７６ 変換テーブル保持部、 １００ ソフトウエア開発支援装置、 １１０ ホモトピーレベル処理ブロック、 １２０ 集合レベル処理ブロック、 １３０ 位相空間レベル処理ブロック、 １４０ 接着空間レベル処理ブロック、 １５０ セル空間レベル処理ブロック、 １６０ 表現レベル処理ブロック、 １７０ ビューレベル処理ブロック、 １９０ オブジェクト集合記憶部、 ６００ ソフトウエアライフサイクル管理装置、 ６１０ 開発機能ブロック、 ６２０ 試験機能ブロック、 ６３０ 保守機能ブロック、 ６４０ ソフトウエア記憶部。
【特許請求の範囲】
【請求項１】
ソフトウエア部品集合間の線形インターオペラビリティを保証するインクリメンタリモジュラな抽象階層モデルを利用して、ソフトウエアの開発工程から試験工程を経て、保守工程に至るまでのライフサイクルを一貫して管理することを特徴とするソフトウエアライフサイクル管理方法。
【請求項２】
前記開発工程は、抽象階層間で前記ソフトウエア部品集合の同値関係を不変量として継承しながら、前記ソフトウエア部品集合が満たすべき仕様を前記抽象階層毎にインクリメンタルに詳細化することにより、与えられた要求仕様に合致するソフトウエアを前記ソフトウエア部品集合から自動生成することを特徴とする請求項１に記載のソフトウエアライフサイクル管理方法。
【請求項３】
前記試験工程は、前記開発工程により生成された前記ソフトウエアが各抽象階層において詳細化された仕様に合致するか否かをテストし、発見された問題に応じていずれかの抽象階層において要求条件を修正した上で、その抽象階層から前記開発工程を繰り返すことにより、前記問題を除去することを特徴とする請求項２に記載のソフトウエアライフサイクル管理方法。
【請求項４】
前記保守工程は、運用中の前記ソフトウエアに修正もしくは機能拡張の必要があった場合に、その修正もしくは機能拡張を反映すべき抽象階層において要求条件を変更した上で、その抽象階層から前記開発工程を繰り返すことにより、前記ソフトウエアの保守を行うことを特徴とする請求項２または３に記載のソフトウエアライフサイクル管理方法。
【請求項５】
ソフトウエア部品集合間の線形インターオペラビリティを保証するインクリメンタリモジュラな抽象階層モデルを利用した、ソフトウエアの開発機能ブロック、試験機能ブロック、および保守機能ブロックを備え、ソフトウエアのライフサイクルを前記抽象階層モデルにもとづいて一貫して管理することを特徴とするソフトウエアライフサイクル管理装置。
【請求項６】
前記開発機能ブロックは、抽象階層間で前記ソフトウエア部品集合の同値関係を不変量として継承しながら、前記ソフトウエア部品集合が満たすべき仕様を前記抽象階層毎にインクリメンタルに詳細化することにより、与えられた要求仕様に合致するソフトウエアを前記ソフトウエア部品集合から自動生成することを特徴とする請求項５に記載のソフトウエアライフサイクル管理装置。
【請求項７】
前記試験機能ブロックは、前記開発機能ブロックにより生成された前記ソフトウエアが各抽象階層において詳細化された仕様に合致するか否かをテストし、問題が発見された場合に、いずれかの抽象階層において要求条件を修正し、前記開発機能ブロックは、前記要求条件が修正された抽象階層から前記詳細化を繰り返すことを特徴とする請求項６に記載のソフトウエアライフサイクル管理装置。
【請求項８】
前記保守機能ブロックは、運用中の前記ソフトウエアに修正もしくは機能拡張の必要があった場合に、その修正もしくは機能拡張を反映すべき抽象階層において要求条件を変更し、前記開発機能ブロックは、前記要求条件が変更された抽象階層から前記詳細化を再度行うことを特徴とする請求項６または７に記載のソフトウエアライフサイクル管理装置。
【請求項９】
前記抽象階層モデルは、各階層においてソフトウエア部品集合に対する操作が可能にモジュラ化されて構成されており、
前記ソフトウエア部品集合に集合演算を施して、所望の複数のソフトウエア部品集合を設計する集合設計部と、
前記ソフトウエア部品集合の部分集合を要素とする集合に位相を規定することにより、前記ソフトウエア部品集合を位相空間として設計する位相空間設計部と、
それぞれが位相空間として設計された前記複数のソフトウエア部品集合の上に同値関係を規定し、前記同値関係で対応づけられた部分空間を接着した接着空間を設計する接着空間設計部と、
前記接着空間において前記複数のソフトウエア部品集合に属するソフトウエア部品の仕様に係る属性をセルで表現し、前記セルの次元を設計するセル空間設計部と、
前記セルの表現形式を設計する表現設計部とを含むことを特徴とする請求項５から８のいずれかに記載のソフトウエアライフサイクル管理装置。
【請求項１０】
前記モジュラ化された抽象階層モデルは、前記複数のソフトウエア部品集合に関して、前記ソフトウエアの開発者または保守者に対するビューを設計し、前記開発者または保守者毎に前記複数のソフトウエア部品集合の操作可能範囲を異ならせるビュー設計部をさらに含むことを特徴とする請求項９に記載のソフトウエアライフサイクル管理装置。
【請求項１１】
前記モジュラ化された抽象階層モデルは、前記ソフトウエアの開発、試験、および保守のいずれかの工程において各設計部による前記ソフトウエア部品集合に対する操作によって生じた前記ソフトウエア部品集合の変化がホモトピー同値になるように設計し、前記ソフトウエア部品集合を変化前の状態に戻せるように、その操作手順を記録するホモトピー設計部をさらに含むことを特徴とする請求項９または１０に記載のソフトウエアライフサイクル管理装置。
【請求項１２】
前記接着空間設計部は、
互いに素である第１の位相空間Ｘと第２の位相空間Ｙに対して、前記第２の位相空間のＹの部分空間Ｙ０から前記第１の位相空間Ｘへの連続写像を、前記同値関係を表す接着写像ｆとして取得する接着写像取得部と、
前記第２の位相空間Ｙの前記部分空間Ｙ０における各点ｙを、前記接着写像ｆによる前記第１の位相空間Ｘにおける像ｆ（ｙ）と同一視することによって、前記第２の位相空間Ｙを前記第１の位相空間に接着し、前記接着空間を同値類の排他的論理和として取得する等化写像取得部とを含むことを特徴とする請求項９に記載のソフトウエアライフサイクル管理装置。
【請求項１３】
前記セル空間設計部は、
前記接着写像ｆによって同一視された前記第１の位相空間Ｘのソフトウエア部品と前記第２の位相空間Ｙのソフトウエア部品をセル空間において対応づけて接合するセル接合部と、
前記セル空間において対応づけられた前記ソフトウエア部品の仕様に係る属性の次元に関する不整合を調整するセル次元調整部を含むことを特徴とする請求項１２に記載のソフトウエアライフサイクル管理装置。
【請求項１４】
前記表現設計部は、前記セル空間において対応づけられた前記ソフトウエア部品の仕様に係る属性の表現形式に関する不整合を受容表現にしたがって調整する表現形式調整部を含むことを特徴とする請求項１３に記載のソフトウエアライフサイクル管理装置。
【請求項１】
ソフトウエア部品集合間の線形インターオペラビリティを保証するインクリメンタリモジュラな抽象階層モデルを利用して、ソフトウエアの開発工程から試験工程を経て、保守工程に至るまでのライフサイクルを一貫して管理することを特徴とするソフトウエアライフサイクル管理方法。
【請求項２】
前記開発工程は、抽象階層間で前記ソフトウエア部品集合の同値関係を不変量として継承しながら、前記ソフトウエア部品集合が満たすべき仕様を前記抽象階層毎にインクリメンタルに詳細化することにより、与えられた要求仕様に合致するソフトウエアを前記ソフトウエア部品集合から自動生成することを特徴とする請求項１に記載のソフトウエアライフサイクル管理方法。
【請求項３】
前記試験工程は、前記開発工程により生成された前記ソフトウエアが各抽象階層において詳細化された仕様に合致するか否かをテストし、発見された問題に応じていずれかの抽象階層において要求条件を修正した上で、その抽象階層から前記開発工程を繰り返すことにより、前記問題を除去することを特徴とする請求項２に記載のソフトウエアライフサイクル管理方法。
【請求項４】
前記保守工程は、運用中の前記ソフトウエアに修正もしくは機能拡張の必要があった場合に、その修正もしくは機能拡張を反映すべき抽象階層において要求条件を変更した上で、その抽象階層から前記開発工程を繰り返すことにより、前記ソフトウエアの保守を行うことを特徴とする請求項２または３に記載のソフトウエアライフサイクル管理方法。
【請求項５】
ソフトウエア部品集合間の線形インターオペラビリティを保証するインクリメンタリモジュラな抽象階層モデルを利用した、ソフトウエアの開発機能ブロック、試験機能ブロック、および保守機能ブロックを備え、ソフトウエアのライフサイクルを前記抽象階層モデルにもとづいて一貫して管理することを特徴とするソフトウエアライフサイクル管理装置。
【請求項６】
前記開発機能ブロックは、抽象階層間で前記ソフトウエア部品集合の同値関係を不変量として継承しながら、前記ソフトウエア部品集合が満たすべき仕様を前記抽象階層毎にインクリメンタルに詳細化することにより、与えられた要求仕様に合致するソフトウエアを前記ソフトウエア部品集合から自動生成することを特徴とする請求項５に記載のソフトウエアライフサイクル管理装置。
【請求項７】
前記試験機能ブロックは、前記開発機能ブロックにより生成された前記ソフトウエアが各抽象階層において詳細化された仕様に合致するか否かをテストし、問題が発見された場合に、いずれかの抽象階層において要求条件を修正し、前記開発機能ブロックは、前記要求条件が修正された抽象階層から前記詳細化を繰り返すことを特徴とする請求項６に記載のソフトウエアライフサイクル管理装置。
【請求項８】
前記保守機能ブロックは、運用中の前記ソフトウエアに修正もしくは機能拡張の必要があった場合に、その修正もしくは機能拡張を反映すべき抽象階層において要求条件を変更し、前記開発機能ブロックは、前記要求条件が変更された抽象階層から前記詳細化を再度行うことを特徴とする請求項６または７に記載のソフトウエアライフサイクル管理装置。
【請求項９】
前記抽象階層モデルは、各階層においてソフトウエア部品集合に対する操作が可能にモジュラ化されて構成されており、
前記ソフトウエア部品集合に集合演算を施して、所望の複数のソフトウエア部品集合を設計する集合設計部と、
前記ソフトウエア部品集合の部分集合を要素とする集合に位相を規定することにより、前記ソフトウエア部品集合を位相空間として設計する位相空間設計部と、
それぞれが位相空間として設計された前記複数のソフトウエア部品集合の上に同値関係を規定し、前記同値関係で対応づけられた部分空間を接着した接着空間を設計する接着空間設計部と、
前記接着空間において前記複数のソフトウエア部品集合に属するソフトウエア部品の仕様に係る属性をセルで表現し、前記セルの次元を設計するセル空間設計部と、
前記セルの表現形式を設計する表現設計部とを含むことを特徴とする請求項５から８のいずれかに記載のソフトウエアライフサイクル管理装置。
【請求項１０】
前記モジュラ化された抽象階層モデルは、前記複数のソフトウエア部品集合に関して、前記ソフトウエアの開発者または保守者に対するビューを設計し、前記開発者または保守者毎に前記複数のソフトウエア部品集合の操作可能範囲を異ならせるビュー設計部をさらに含むことを特徴とする請求項９に記載のソフトウエアライフサイクル管理装置。
【請求項１１】
前記モジュラ化された抽象階層モデルは、前記ソフトウエアの開発、試験、および保守のいずれかの工程において各設計部による前記ソフトウエア部品集合に対する操作によって生じた前記ソフトウエア部品集合の変化がホモトピー同値になるように設計し、前記ソフトウエア部品集合を変化前の状態に戻せるように、その操作手順を記録するホモトピー設計部をさらに含むことを特徴とする請求項９または１０に記載のソフトウエアライフサイクル管理装置。
【請求項１２】
前記接着空間設計部は、
互いに素である第１の位相空間Ｘと第２の位相空間Ｙに対して、前記第２の位相空間のＹの部分空間Ｙ０から前記第１の位相空間Ｘへの連続写像を、前記同値関係を表す接着写像ｆとして取得する接着写像取得部と、
前記第２の位相空間Ｙの前記部分空間Ｙ０における各点ｙを、前記接着写像ｆによる前記第１の位相空間Ｘにおける像ｆ（ｙ）と同一視することによって、前記第２の位相空間Ｙを前記第１の位相空間に接着し、前記接着空間を同値類の排他的論理和として取得する等化写像取得部とを含むことを特徴とする請求項９に記載のソフトウエアライフサイクル管理装置。
【請求項１３】
前記セル空間設計部は、
前記接着写像ｆによって同一視された前記第１の位相空間Ｘのソフトウエア部品と前記第２の位相空間Ｙのソフトウエア部品をセル空間において対応づけて接合するセル接合部と、
前記セル空間において対応づけられた前記ソフトウエア部品の仕様に係る属性の次元に関する不整合を調整するセル次元調整部を含むことを特徴とする請求項１２に記載のソフトウエアライフサイクル管理装置。
【請求項１４】
前記表現設計部は、前記セル空間において対応づけられた前記ソフトウエア部品の仕様に係る属性の表現形式に関する不整合を受容表現にしたがって調整する表現形式調整部を含むことを特徴とする請求項１３に記載のソフトウエアライフサイクル管理装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【公開番号】特開２００６−３９３９（Ｐ２００６−３９３９Ａ）
【公開日】平成１８年１月５日（２００６．１．５）
【国際特許分類】
【出願番号】特願２００４−１７６４４４（Ｐ２００４−１７６４４４）
【出願日】平成１６年６月１５日（２００４．６．１５）
【出願人】（５９３１６５４８７）学校法人金沢工業大学 (202)
【Ｆターム（参考）】
【公開日】平成１８年１月５日（２００６．１．５）
【国際特許分類】
【出願日】平成１６年６月１５日（２００４．６．１５）
【出願人】（５９３１６５４８７）学校法人金沢工業大学 (202)
【Ｆターム（参考）】
[ Back to top ]