オブジェクト指向によるソフトウェア開発の研究

〜再利用のための開発プロセスに関する課題とその解決策〜

• 第１章　序論
• 第１節　研究背景
• 第２章　既存のオブジェクト指向方法論の問題点
• 第１節　方法論としての問題
• 第２節　構造化ベースの問題
• 第３節　再利用プロセスの欠如
• 第３章　再利用のための開発プロセス
• 第１節　再利用と変更可能性
• 第２節　要件変更という問題
• 第３節　従来の開発サイクルとその特徴
• 第１項　ウォーターフォール
• 第２項　カスケード・ウォーターフォール
• 第３項　プロトタイプ開発
• 第４項　積み上げ反復
• 第４節　並列の開発チームと開発サイクル
• 第１項　コンポーネント開発とシステム開発
• 第５節　変更への対処
• 第４章　結論
• 第１節　コンポーネント中心のプロセスへ
• 参考文献

第１章 序論

第１節 研究背景

　近年,コンピュータのハードウェア技術の発展により,大規模で複雑な構造をもつシステムの開発が行なわれるようになった.しかし,ソフトウェアに対する需要の拡大に反してソフトウェアの生産性の低いことが問題になってきている.こういったソフトウェアやシステムの生産性の向上に対する要求やその複雑さの増大などに対処するためにソフトウェア工学は誕生し,複雑性を扱うための技術としてソフトウェアの分析設計法が考えられるようになった.
　その中で,ソフトウェアの生産性を向上させた一つの大きな概念として,オブジェクト指向の概念がある.オブジェクト指向の考え方は実世界での作業の仕方に非常に似ており,プログラムのモデリングを行うための概念として非常に有効な方法であることが認められてきている.オブジェクト指向は従来の構造化設計よりも高いレベルでの抽象化を行うことや,近年のイベント駆動型アプリケーション開発にもうまく適合することから,今後オブジェクト指向によるシステム開発が一般的な開発手法になる可能性は非常に高いといえる.
　オブジェクト指向においてはその再利用可能性が非常に重要な要素とされており,オブジェクト指向の出現により,ソフトウェアは「作る」時代から「利用する」時代に大きく遷移した.しかし,OMT法やBooch法,OOSEなど既存のオブジェクト指向方法論の開発サイクルでは再利用のためのプロセスが含まれておらず,実際の開発現場において混乱を生じさせる原因となっている[4].
　オブジェクト指向ソフトウェア開発においては,再利用を最大限に行うために「新しい要求や既存の要求に対する変更を前もって知ること,また変更に対して強固に対応できるようなシステムを設計すること」が重要な要素となると考えられている[1].効果的な再利用のためには,変更に対して適切に考慮された開発プロセスに対するアプローチが欠かせないのではないだろうか.この論文では,オブジェクト指向による開発において変更を前提とした再利用のための開発プロセスに関する考察を行う.

第２章 既存のオブジェクト指向方法論の問題点

第１節 方法論としての問題

　オブジェクト指向方法論は,オブジェクト指向による開発を効率的に進めるための考え方であり,オブジェクト指向言語の普及により,1990年の半ばまでにはBooch, OMT, OOSE, Fusionなどといういくつかの主要な手法にまとめあげられた.しかし,これらの方法論はそれぞれ独立しており,また個々に特徴を持っていたことから開発者の間で方法論の使用に際して混乱が生じていた.
　そこで1994年以降, Rumbaugh, Booch, Jacobsonにより共同で開発され,Booch法とOMT法,OOSE法を統合化したオブジェクト指向統一モデリング言語 (UML: Unified Modeling Language) が開発され、1997年にはOMG (Object Management Group) に標準規格として承認されるに至った.UMLは既に広まっていた方法論を統合化したため業界に受け入れられ,事実上の業界標準であると考えられている.しかし,UMLはモデリングのための言語であって,開発者がオブジェクト指向分析・設計を行う方法を定義しているものでもなければ,開発プロセスを示すものでもない.UMLは単に,オブジェクト指向概念を用いてシステムをモデル化するための統合化された表記方法のことであり,オブジェクト指向方法論を論議する中での「共通の言語」を定義したものに過ぎない.
　UMLという標準の表記法を用いた開発プロセスを規定した業界標準と言えるような方法論は今だ開発されていない.オブジェクト指向技術を用いてソフトウェア開発を行う技術者は,ひきつづきUML以前の方法論を用いるしかなくなったわけである.

第２節 構造化ベースの問題

　従来のオブジェクト指向方法論は構造化モデルを基本にし,その上にオブジェクト指向モデルを適応させるという考え方をベースとしており,実際の開発サイクルにおいて自然なオブジェクト抽出ができない,もしくはオブジェクト抽出において曖昧な点が多いという問題が指摘されている[4].このような方法論では,設計段階で既存の資産としてのクラスライブラリなどの再利用コンポーネントをモデルに適応させる場合の具体的なプロセスについての指針が曖昧になったり,オブジェクト指向開発サイクルの各開発段階において変化するオブジェクトの性質についての意識が曖昧になり,分析的視点で抽出された概念的な実世界モデルを,クラスライブラリをベースとして作成されるある特定の制約されたシステム要求に移し替える際のモデル変換プロセスに不具合が生ずる場合があるなど,オブジェクト指向による現実の開発プロセスに自然に適応させにくい.

　ソフトウェア開発におけるモデルとは,「対象問題の深い理解を得るために,その対象をある目的または観点から眺め,重要でない部分を取り去り重要な部分だけにしたもの」のことをいう[4].上の図に示されるように,オブジェクト指向による開発では各モデル化過程のそれぞれの目的によってオブジェクト抽出の視点が変わるので,このモデリングプロセスにおいて,「オブジェクト」を中心においた明確な視点と目的が必要となってくるのである. 　

第３節 再利用プロセスの欠如

　オブジェクト指向技術を導入する動機が再利用可能性の向上であることが多いにもかかわらず,多くの方法論には再利用のための開発プロセスについての具体的な指針がないため,実際の開発現場においてそれらの方法論を採用したとしても混乱が生ずることが多いということも問題となっている[4].また,現在のソフトウェア開発では一般的になった「コンポーネント中心」の開発プロセスにおいて,多くの方法論ではコンポーネントの再利用プロセスとソフトウェア分析プロセスの境界についての意識が欠けているため,再利用コンポーネントが適切に作成されないことも問題の一つである.
　再利用コンポーネントを充実させ開発のコストダウンをはかるという視点と,対外的な契約行為によりシステムを完成させるという視点は必然的に異なるものであり,その相反するそれぞれの視点を同じ開発プロセスの中で用いるとそれぞれの特徴が相殺され阻害し合うという結果になり,結果として再利用性が低下するという危険性がある. 再利用のプロセスは,オブジェクト指向の重要な要素の一つである「保守・拡張性」にも影響を与える.再利用性と拡張性は密接に関連しており,適切に考慮された再利用プロセスなくしては円滑な保守を行うことはできないのである.

　このように,既存のオブジェクト指向方法論を実際のソフトウェア開発プロセスに適用させる過程においては,さまざまな問題が存在していることがわかる.それに対する解決策を考える上では,実際のソフトウェア開発現場において自然に適用できるような,再利用を向上させるためのオブジェクト指向ベースの開発プロセスについてのアプローチが欠かせないのではないだろうか. 　

第３章 再利用のための開発プロセス

第１節 再利用と変更可能性

　オブジェクト指向によるソフトウェア開発では,ソフトウェアを一から作るのではなく,オブジェクト指向の枠組みを利用して積極的な再利用をはかる.再利用を適切に進めれば結果として開発工数の短縮や信頼性の確保の実現が可能になるため,オブジェクト指向開発プロセスではソフトウェアの再利用性が特に重要視されている.再利用性の確保は,将来起こり得るソフトウェアに対する要求変更において既存の資産をいかに活かせるかというところに重点があるため,その再利用性においては,「新しい要求や既存の要求に対する変更を前もって知ること,また変更に対して強固に対応できるようなシステムを設計すること」が重要であると考えられている[1].
　ソフトウェアに将来起こり得る変更という問題を考慮しない設計は,その将来の変更過程において根本的な再設計が必要になる危険性がある.再設計にはクラスの再定義,再実装,クライアントの修正,再テストなどが含まれるため,ソフトウェアシステムの多くの部分に影響を及ぼす.変更を構築プロセスや保守段階で行う場合,プロジェクトの初期段階での修正に比べて５０倍から２００倍も工数がかかるという調査結果もある[3].ソフトウェアの再利用を円滑に進めるためには,要件変更という問題を避けては通れないものといえよう. 　

第２節 要件変更という問題

　そもそも,要件を明確にしておくことはソフトウェアが処理すべき問題を明確にすることであり,ソフトウェア開発においては要件定義が根本的に必要なプロセスとなる.要件が確定していれば,プログラミング前にシステムの及ぶ範囲を決定でき,プログラムが処理すべき問題について不具合や意見の食い違いがあれば書面となっている要求仕様を見て解決を図ることができる.大規模プロジェクトにおいて要求仕様にあるエラーをコーディング段階で発見した場合,要求仕様を解析する段階でエラーを検出した場合に比べて１０倍の費用がかかるという報告さえある[3].理想的には,開発プロセスの途中での要件変更は行われるべきではない.
　しかし実際には,要求仕様がプロジェクトの途中で変更されることが一般的な慣行となっている[2].IBMの調査によると,１００万行程度のプロジェクトでは,開発期間中に２５％もの要件変更が行われるということである[3].これは,プロジェクトの規模が大きくなるにつれ,ユーザ自身がソフトウェアに何をさせたいか,何が必要なのかという根本的な視点についての意識が曖昧になりがちになり,ユーザはプロジェクトが進みその概要が明らかになるにつれて自分がしたかったことを理解するからである.開発作業そのものがユーザに要求仕様を変更させる要因となっているといえる.
　オブジェクト指向による開発では「要求仕様は永久に定まらない」ということを前提とする.オブジェクト指向による開発プロセスについて考える上では,再利用を向上させ,かつ要件変更に対しても強固に対処できるような開発プロセスについて考える必要があるのである. 　

第３節 従来の開発サイクルとその特徴

　ソフトウェア開発をどのように進めていくかという戦略を示すモデルのことを「開発サイクル」という.これまで数多くの開発サイクルモデルが提案されてきたが,それらにはそれぞれ長所があり,短所がある.ソフトウェアの生産性をあげ再利用性を高め,なおかつ変更という問題にも対処できるような開発サイクルについて考えるためには,こうした各開発サイクルモデルの長所短所をしっかりと見極める必要がある. 　

第１項 ウォーターフォール

　オブジェクト指向以前のシステム開発は,「ウォーターフォール」に代表される,分析,設計,構築が一回しか行われない開発サイクルに特徴をもっていたとされている.この開発サイクルは,早い段階から複雑な問題に取り組まなければいけないうえに,基本的に要求仕様の変更や設計上の制約条件の変化などに対応できないところに欠点がある.たとえば,設計フェーズから分析フェーズへといった逆方向へのフィードバックが不可能である.また,早い段階から完全な要求仕様や設計仕様を作ろうとするために全体の複雑性に対処できないという問題もある.

　一方,この開発サイクルには利点もある.まず第一に,基本的に分析フェーズや設計フェーズなど各開発段階が明確に区別されるため,工程管理が容易なことである.第二に,段階的なトップダウンアプローチにより,計画的なシステム開発を行えることである.それぞれの開発段階が明確に区別されるため,開発の金銭に関する契約を簡単に行えることも利点の一つである. 　

第２項 カスケード・ウォーターフォール

　カスケード・ウォーターフォールとは,従来のウォーターフォールモデルの欠点を補うために,それぞれのフェーズが重なり合うことができるように改良したものである.このモデルは,「前フェーズが完了しなくとも後フェーズを並行して行うことができる」と定義することで,適度な柔軟性を導入するものである.段階的なトップダウンアプローチによる計画的なプロセスや工程管理の容易性といったウォーターフォールの長所を継承しつつ,前フェーズの遅れによる作業の停滞を解消できフェーズ間を行き来しやすい構造をもたらすなどの利点がある

　このようにカスケード・ウォーターフォールは,ウォーターフォールモデルに対してフェーズ同士が重なり合うことができるという改良を行ったものである.しかし,このモデルは,再利用可能なコンポーネントの開発サイクルといった,パッケージを基本的な単位として,序々に積み上げ拡張するようなモデルにうまく適用できないところに問題があるといえるだろう.

第３項 プロトタイプ開発

　プロトタイプ開発は,システムの中心となる機能の実際的なモデルを開発し評価することである.開発者はユーザインターフェースのプロトタイプを作ることで操作性を確認でき,ソフトウェアの全体像を把握することができる.分析や設計フェーズにおいては,すべての問題を初めから理解し,最善の策を得られるわけではないので,プロトタイプ開発をうまく利用することで,分析・設計フェーズの質を高め,作業速度を早くすることができる.このように,プロトタイプ開発の利用は非常に有効な手段である.
　しかし,プロトタイプ開発だけでは非常に問題である.なぜなら,プロトタイプとして作成したつもりのソースがそのまま開発に使われた場合,明らかな製品の品質の低下を招くこととなるからである.また,早い段階からの実演が可能なためクライアントや経営陣からの期待が高まり,ソフトウェアに対する必要以上の改善要求,つまり要求仕様の変更要望が噴出する可能性が高いという問題もあるといえる. 　

第４項 積み上げ反復

　積み上げ反復とは,ソフトウェアを小さな増分(increment)の積み重ねにより組み立てる方法である.新たに増分されるものは,それだけでも十分利用可能な機能を有するものであり,それを積み木のように積み上げていくアプローチである. UMLでは,このような反復的かつ段階的な開発サイクルが推奨されている[6].
　オブジェクト指向ソフトウェア開発では,大まかな分析・設計・作成というフェーズがあるが,開発は必要に応じて，どの段階にも移行でき,それぞれに積極的にフィードバックをかけて,求められている変更や変化を少しずつ受け入れるところに特徴がある.すでに考察したものを修正し改変していくことが保守でもあり新たな開発でもありソフトウェアの発展となる.この開発サイクルは,パッケージを基本的な単位として序々に積み上げ拡張するようなコンポーネント開発サイクルのモデルにうまく適用できるといえる.

　こういったモデルには分析・設計・作成というフェーズに共通した枠組みが必要になるが,オブジェクト指向では「オブジェクト」を共通の枠組みとする.分析・設計・作成のそれぞれのフェーズにおいて別のものに置き換えていくわけではないので,理解が比較的容易になるというところにオブジェクト指向の真髄がある.オブジェクトはカプセル化されており強力な抽象性を発揮するので,変更や追加に対して強度があり,その強度ゆえに柔軟に対応できる.オブジェクトという枠組みが登場して，初めて可能になったモデルといえるだろう.
　この開発モデルにも問題がないわけではない.システム開発では,システム範囲の決定,それに対する開発コストの見積もり,エンドユーザの承認獲得というプロセスに関して段階的でかつトップダウンの決定,それに対する作業を必要とされることが多いのであるが,こういった開発モデルではそうした作業に関する金銭に関する契約が難しくなったり,それぞれのフェーズにおける責任の所在が不明確になるという危険性があるからである. 　

第４節 並列の開発チームと開発サイクル

　オブジェクト指向開発における開発サイクルは,従来の主流であった「ウォータフォール型」から「反復開発」「プロトタイプ開発」といった開発サイクルに移り変わろうとしている.しかし,既存の多くの方法論では,具体的な開発プロセスに関する指針が欠けているため,実際の開発サイクルを構成するフェーズで何をすればよいかが明確でないものが多い.そのため,開発システムの工程管理が困難になりやすいという問題がある.特に,再利用を促進するための開発プロセスに関する具体的な指針がないので,再利用コンポーネントの作成や既存資産としてのクラスライブラリの有効利用が効率的に行えない.
　そもそも,再利用コンポーネントを充実させて再利用の促進を目指すという視点とシステムを完成させるという契約行為による視点が異なるため,このプロセスを同時に行うには無理があるといえる.この問題を解決するためには,システム開発と再利用の促進という問題を区別し,それぞれの視点ごとに並行に進行する明確な開発サイクルを開発プロセスの一環として定義する必要があるのではないだろうか.

第１項 コンポーネント開発とシステム開発

　今日のような複雑化した大規模システムを開発する場合においては,システム要求や仕様の把握,決定のために大きな労力が必要となる.さらに,実装技術についても,開発環境が複雑化することで,非常に専門的な知識が必要とされている.このような仕様の複雑さと実装の複雑さという２つの困難を克服しながらプロジェクトを円滑に進めるためには,「システム境界を定める」ことと「オブジェクト境界を定める」という２つの異なる観点を持つことが重要となる.オブジェクト指向の特徴を十分に活かすためには,再利用性の向上をシステム開発とは別の観点として進め,再利用性を高める「コンポーネント提供者」としての視点と再利用コンポーネント使用者としての「システム提供者」との視点を明確に分けることが必要であるのではないだろうか.

　これにより,コンポーネント提供側は,再利用性や保守性を高めるという,コンポーネントに最も必要とされる要素により力を注げるようになり,「使える」コンポーネントを作成することができる.一方,再利用資産を構築できる専門家集団の存在によって,システム開発者は問題領域の要求分析や仕様の把握に集中できることになり,短期間で高度なシステムを構築する専門家になることができるという利点がある.

　前節で述べたように,コンポーネント開発に適した開発サイクルとシステム開発に適した開発サイクルには違いがある.コンポーネント開発サイクルには積み上げ反復型の開発サイクルを採用すべきであるし,システム開発サイクルにはカスケード・ウォーターフォールによる開発サイクルによるサイクルがうまく適用できるものと思われる.従って,コンポーネント開発とシステム開発にそれぞれ別々の開発サイクルを採用するべきであるといえよう.また,次の図に示すように,この２つの開発サイクルは同時並行的に行われる.

　

　コンポーネント開発サイクルには,積み上げ反復方式がとられる.クラスライブラリに新規のコンポーネントを追加するための分析と,クラスライブラリを計画的に発展させるためのソフトウェア構造基盤の分析を,連続させて行う必要があるため,コンポーネント分析フェーズが連続的に切れ目なく,繰り返される.こういった方法を取ることによって,オブジェクト指向の大きな目的の一つである再利用性を高め,かつ実際の開発作業で使えるコンポーネントを作成することができるのである.
　一方,システム開発サイクルにおいては,コンポーネントの再利用性の向上という問題について考えずにすむだけでなく,再利用性に関して適切に考慮されたコンポーネントの利用者としての視点で作業を進めることができるので,コンポーネントの再利用性を意識しすぎて開発システムの境界を見失ってしまうといった問題を避けることができる. 　

　これら２つの問題を区別しない開発プロセスでは,開発プロセスが比較的理解しやすくなるという利点はあるが,この２つの視点を同じ開発プロセスの中で用いると,それぞれの相反する特徴が相殺され,そして阻害しあうという結末になる危険性がある.それぞれに適した開発サイクルを採用し,それを並行して運用することにより,再利用コンポーネントを充実させることができるだけでなくシステム開発を円滑に進めることが可能になるといえる.

第５節 変更への対処

　前節のように,システム開発と再利用の促進という問題を区別しそれぞれの視点ごとに並行に進行する開発サイクルを用いることによって再利用性を高めるという目的は達せられたが,この論文の主題である,オブジェクト指向の特徴を最大限に生かして再利用性を高め,かつ要件変更にも柔軟に対処できる開発サイクルについて考えなければならない. 　

第1項 単一の開発サイクルの場合

コンポーネント開発においては積み上げ反復方式が最も適していることはすでに述べた．この方法は変更要求に対しても柔軟に対処できるが，システム開発には適していないという問題がある．一方，カスケード・ウォーターフォールなどの，システム開発に適した方法を単体で用いた場合には，変更要求に対処するためのコンポーネントの作成自体が適切に行われないうえに，実装段階以降の変更要求に対処するためのフェーズが存在しないのである．

3章第2節で述べたように，変更要求というものはソフトウェアシステムが形になってくるにつれて増えてくるものである．つまり，実装段階や評価段階での要求仕様の変更への対処について考えることこそが重要であろう．ウォーターフォールなどの一方向的に続いていくような開発サイクルでは，変更が求められた場合にでもそれに対処するためには次回の開発まで待たなくてはならないか，もしくは対処療法的な変更を一部に行うという方法を取らざるを得なくなる，というところに問題があるのである．

第2項 並列の開発サイクルの場合

前節で述べたような，コンポーネント開発とシステム開発が同時並行的に行われるサイクルでは，再利用コンポーネントの開発サイクルに積み上げ反復を採用していることから，コンポーネント単位での再利用性向上と変更への対処を適切に行うことができる．なぜなら，分析・設計・実装といった一連のサイクルを反復的かつ段階的に行っているからである．要求仕様の変更は，このサイクルの中で適切に受け入れられ，処理される．

例えば，コンポーネント開発サイクルにおいてコンポーネント評価フェーズで問題が発生する，もしくは変更要求があった場合でも，積み上げ反復の場合では次のフェーズ，すなわちコンポーネント分析フェーズでその要求を受け入れることができる．コンポーネントリリース後に変更要求があった場合でも，リリース後に再びコンポーネント分析フェーズが繰り返されるため，そうした問題にも柔軟に対処できるのである．
一方，契約行為を主体にしたシステム開発サイクルの場合はカスケード・ウォーターフォールを採用しているので，コンポーネント開発サイクルの場合と比べれば開発サイクルという枠組みから見ると柔軟性がより低いと考えられるが，再利用性の向上という観点からすれば，変更という問題への対処はコンポーネント単位で行われるべきであり，同時並行的にコンポーネント開発とシステム開発を行う前述のような方法では再利用性と柔軟性について考える上でも問題はないといえるだろう．

以上のように，変更という問題に対してコンポーネント単位で対処することは妥当な方法であると考えられる．しかし，変更に対処すべきコンポーネントが変更不可能なものでは意味がない．コンポーネントという枠組みを用いて変更に対処するためには，そのための適切なコンポーネント設計が欠かせないものとなるだろう．

第４章 結論

第１節 コンポーネント中心のプロセスへ

　これまで見てきたように,再利用を向上させるためのオブジェクトベースの開発プロセスにおいては,再利用を向上させる一つの単位としての「コンポーネント」という存在が欠かせないということができる.コンポーネントとは,一個以上のクラスで構成される再利用可能な集合のことであり,コンポーネントという論理的な単位を用いることによる情報隠蔽により,オブジェクトを「再利用」という視点からだけでなく「利用する」という単位で考えることを可能にするものである.コンポーネントの利用者側にとっては,コンポーネントの物理的な構造や内部構造などよりも必要なサービスを利用するためのオブジェクトとインターフェースの利用法だけが分かっていればよい. 一方，コンポーネントを提供する側では,コンポーネント利用の視点とコンポーネント提供の視点とを明確に分けることでコンポーネントの再利用性や保守性を向上させることができるという利点があるのである.
　こういった考え方はオブジェクト指向技術を基本にしていることはいうまでもないが,コンポーネントを中心として考えることでコンポーネントを利用する側はオブジェクトを利用するという視点により力を注ぐことができ,またコンポーネントを提供する側はコンポーネントそのものの専門家になれるという点から，コンポーネント中心のプロセスはオブジェクト指向そのものよりも抽象度が高いといえる.
　再利用可能なコンポーネントという「部品」を組み合わせてソフトウェアシステムを作成することは,オブジェクト指向開発にとってのひとつの理想である。しかし現実には,コンポーネントをつなぎ合わせただけではユーザが満足できるようなソフトウェアを作成することが困難であることが指摘されている[4].ユーザの要求を具体的なソフトウェアシステムとして実現するためには,その要求に特化したコンポーネントを作成しなければいけないため必然的にクラス間の結合度が高くなることや,ユーザ要求を適切に組み込みつつ,かつ柔軟性の高いコンポーネントを作成することが難しいなどという理由からである。
　しかし,前述のような並列の開発サイクルを採用することによって,システムからコンポーネントとして実現可能な部分を抽出することができるので,そのシステムに特化されたアーキテクチャ部分をできるだけ少なくすることができる.その結果,再利用可能なコンポーネント部品を増やすことにもつながるのではないだろうか.

　コンポーネントを中心においたソフトウェアの開発には再利用可能なコンポーネントの充実が欠かせない.今後，このコンポーネントが充実することによって「コンポーネント提供者」と「コンポーネント利用者」の役割が明確に分かれていき，ますますコンポーネント中心の考え方がオブジェクト指向によるソフトウェア開発の世界に浸透していくであろう. 　

参考文献