1. オブジェクト指向分析／設計とは？10 1....
TRANSCRIPT
9
1. オブジェクト指向分析／設計とは？
この章では、オブジェクト指向分析／設計の特徴と、それが生まれてきた背景を考
えます。「オブジェクト指向分析／設計」というアイデアは、ソフトウェアエンジニ
アリングの実践的経験と研究から生まれてきました。「構造化分析／設計」の成功を
受けて、それをさらに発展させたのが、このソフトウェア開発アプローチです。けれ
どもそれまでの開発経験とは大きく異なる点も数多くあり、実際の開発にその技術を
生かすために多くの時間とコストがかかりました。それでも現在のシステム開発はオ
ブジェクト指向アプローチが主流です。どうして成功している構造化アプローチから
オブジェクト指向への転換が期待され、実践されてきたのでしょうか。この章では、
オブジェクト指向分析／設計の特徴を考えます。
1.1. オブジェクト指向への期待
ソフトウェア開発は複雑な作業・仕事の１つです。扱う情報の種類も量も多く、そ
の情報を使って実現すべき機能も多岐にわたります。また利用できる“材料”（ハー
ドウェア、基盤となるようなソフトウェア）も多種に及んで日々進化しており、さら
にやっかいなことには、ソフトウェアへの要件 (requirement specification) は確定す
ることがなく、たえず変更と拡張の要求が発生します。また、ソフトウェアは社会
を支える基盤ですから、そのソフトウェアを必要とする組織内部の変化、法律などの
社会変化に迅速に対応することが求められます。そのようなさまざまな要因をうまく
制御しながら顧客に求められるシステムを構築するために、ソフトウェア開発手法
(software development method) が考えられました。これまでにさまざまな手法が提
案されてきたのですが、大別すると構造化アプローチとオブジェクト指向アプローチ
があります。
オブジェクト指向が登場する前にソフトウェア開発の主流を占めていた手法が、構
造化アプローチです。構造化プログラミング (structured programming) のアイデア
（表 1-1）をシステムの分析、設計に活かして、ソフトウェア機能を組織的に分割し、
1. オブジェクト指向分析／設計とは？
kanazawa.indb 9 08.11.17 0:15:49 PM
10
1. オブジェクト指向分析／設計とは？
データを構造化するというこのアプローチの実践によって、良いソフトウェアのため
の条件は何かが徐々にわかってきました。開発のプロセスにおいて、顧客と契約を結
んだり技術者間で対話をしたりするために開発ドキュメントが必要であり、そこにダ
イアグラム（diagram ＝図）を用いると効果的であること、構造化の単位をモジュー
ル（module）とし、モジュールに結合度・凝集度といったメジャーをいれて設計す
ればテストしやすく拡張性にも富んだソフトウェアが開発できることなどが示されま
した。データベースの正規化を設計するための優れた道具である ER 図、構造化され
た処理の流れを表現するためには HIPO やナッシー - シュナイダーマン・チャートが
使われるようになり、その視覚的な設計図により実装前のレビューの質も向上させる
ことができるようになりました。このようにして、良いソフトウェアとは何かという
問題は、ソフトウェアの品質とは何か、それをどのようにしたら実現できるのかとい
う具体的な技術提案へと成熟しました。そのような中で、オブジェクト指向への志向
が強まってきたのです。その理由について考えていきましょう。
表 1-1 構造化プログラミング
GOTO 文を使わないでも、以下の要素を組み合わせるとどのようなアルゴリズムも実現できる（E. W. Dijkstra）
○ 順接：プログラムコードに記された順に逐次処理する。
○ 反復：一定の条件が満たされている間処理を繰り返す。
○ 分岐：条件により処理を振り分ける。
1.1.1. ソフトウェアの品質を向上させる工夫
他の工業製品と同様に、ソフトウェアにとっても品質は重要です。Bertrand
Meyer はソフトウェアの品質には外的品質要因（ユーザーから認識できる品質）と
内的品質要因 1
（ソフトウェアの専門家には認識できる品質）があると説明しています
[Meyer88] [Meyer97] 。外的品質要因については、ソフトウェアの機能は顧客と取
り決めた要件を正確かつ確実に実現する（＝正確さ）だけでなく、ソフトウェアの
1 Meyer は、内的品質要因の例として、モジュール性と読みやすさを挙げています [Meyer97]。
kanazawa.indb 10 08.11.17 0:15:50 PM
11
1.1. オブジェクト指向への期待
利用者がうっかりと間違って使ってもハングアウトすることなく動作する（＝頑丈
さ）のが望ましく、また利用者が使っていてイライラするほどレスポンスが遅くない
こと（＝効率性）が求められます。またソフトウェアは社会や技術の進化に合わせ
てバージョンを改訂していくのが一般的であるので、そのための対処が考慮されて
いる必要があります（＝拡張性、再利用性など）。そして、それらのことが予算をた
てその計画の中で実現されることが求められます（＝経済性）。このようなことを満
たしてこそソフトウェアは高品質であるといえるのだというのが Meyer の主張です
[Meyer88][Meyer97] 2
。
「品質とは何か」についての考察はさらに整理され、たとえば ISO/IEC9126 などに
規定されています。品質の実現は、一筋縄に解決するといった問題ではなく、ソフト
ウェアエンジニアリング（software engineering、ソフトウェア工学）という学問分
野が日々研究をすすめています。
オブジェクト指向技術は、拡張性や再利用性といった品質の実現を容易にするため
に生まれてきました。ソフトウェアシステムは現実世界を支援するものであるのに「現
実世界が日々発展するのに応じてソフトウェアを変更するのがとても困難である」と
いう問題点を解決する役割を担って、オブジェクト指向のアイデアが進化してきたの
です。業務で使われるソフトウェアの拡張性＝ソフトウェアの改変のしやすさは、ビ
ジネスニーズに直結します。また、ソフトウェア企業の問題としても、求められる機
能は複雑化する一方、納期はますます短期間にと求められる中で、再利用性の向上な
しには対処できなくなったという（やはりビジネス的な）要因があります �
。
拡張性と再利用性の中核となるアイデアは「モジュール」（module）という概念で
す [Meyer88]。ソフトウェアを一枚岩の塊ではなく構成要素（＝モジュール）に分解
して、それらの間の関係を明確にすることが、拡張箇所が明らかになるための条件で
す。単純な責務を担うモジュールを用意し、個々のモジュールには単純な責務を担わ
せて、それらをまとめあげるための一貫した仕組みを導入することが、拡張しやすい
ソフトウェア構築に役立ちます。ソフトウェアの再利用性は「すでに解決されている
問題への対処を他の箇所にも適用する」ことで実現されるわけですが、モジュールに
分解されていれば、モジュール単位で再利用の可能性を検討することができます。
ロゴブロック（あるいは、積木）は、その単純な部品を組み合わせて、建物や動物2 ここで挙げたのは、Meyer の外的品質要因の一部です。詳しくは [Meyer97] を参照して下さい。� 開発組織の要請からオブジェクト指向、さらにソフトウェアパターンの導入の必然性については [ 井上 05] に
まとめられています。
kanazawa.indb 11 08.11.17 0:15:50 PM
12
1. オブジェクト指向分析／設計とは？
などの異なる形状を作り上げることができます。そのような単純な形に部品が分割さ
れて、かつ、組み合わせやすい場合、モジュールを組み合わせることが容易になります。
ソフトウェアにはさまざまな機能が期待されています。それをモジュールの組み立て
で作り上げる場合、モジュールの凝集度が高く結合度が低いと、それはよいモジュー
ルであると判断します。凝集度（cohesion、もしくは強度 (strength) 4
）とは、１つの
モジュール内に関連する「知識」がどれくらいまとめられているかの尺度で、結合度(coupling) は１つのモジュールが他のモジュールとどれくらい依存関係があるかを示
す尺度です [Myers78][Yourdon9�]。つまり１つのモジュールが何らかのまとまった
意味をもってソフトウェアの中で責任を果たし（高い凝集度）、かつ、その責任を果
たすために、他のモジュールへの影響は極力少なくする（低い結合度）、このように
すれば、ソフトウェアを構成する“部品”を望ましいものにできると考えられてきま
した。
このような特徴に加えて、B. Meyer は「連続性」と「保護性」という概念をモジュー
ルの測定基準に追加しました [Meyer88] [Meyer97]。連続性（continuity）とは、経
済やエンジニアリングの一般的なことばでいえば追跡可能性（traceability、トレー
サビリティ、追跡性）を実現するモジュールの性質です。ある製品がどのように作成
され、配布されるのかといった製造過程を追っていくことができ、かつ、その前のど
の決定がいまのどの個所に反映されているのかを前にも後にもに辿ることができる能
力が追跡可能性です。ソフトウェアのモジュールを評価する基準に追跡可能性を導入
することができるとは、それが（単なるロゴブロックの１つのブロックを見るという
軸だけでなく）製造・配布の時間軸の中で測定されるものであるべきだという意味を
もっています。ソフトウェアモジュールが追跡可能性をもっていれば、ソフトウェア
に対する１つの要件によってどのモジュールが作成されたのか、１つの要件の変更が
どのモジュールに影響を与えるのかを明確にでき、また逆にモジュールの変更がどの
ように要件に影響を与えるのか、実装上問題が発生すればどこの要求に仕様上の問題
があったのかを指摘できます。
Meyer のいうところのモジュールの保護性（protection）は、何らかの異常がおこっ
たときに、特定のモジュール内でどれくらいその波及を食い止めることができるかを
示す尺度です [Meyer88] [Meyer97]。たとえば本に紙魚がついたというような例を考
えれば、その本だけに抑えたいと考えるのではないでしょうか。モジュールの保護性
4 Myers の使ったことばは strength。cohesion（とその訳「凝集度」）は [Yourdon9�] で使われています。
kanazawa.indb 12 08.11.17 0:15:50 PM
1�
1.1. オブジェクト指向への期待
はそれによく似ていて、そのようにモジュールごとの保護性を前提にすると、ソフト
ウェア全体としての頑丈さ（robustness、ロバストネス、頑健性）の確保が容易にな
ると考えられます 5
。ロバストネスはおおよその工業製品がもつ性質で、あらかじめ予
期されていない使い方をしたとしても、その製造品にこのようなキャパシティがある
ために、現実世界の思わぬ事故を多く防ぐことができているのです。B. Meyer が導
入した連続性（＝追跡可能性）と保護性は、ソフトウェアをその他の工業製品と同レ
ベルに置くために必須の評価といえるかもしれません。モジュールの連続性は要求変
更のコストを見積もるためにも重要です。
（１）構造化アプローチのモジュール分割を考える
構造化アプローチでは、モジュールの分割を「機能」中心で行います。顧客から要
求されるのは新規システムの「機能」ですから、機能を単位にしてさらに処理単位を
分割していくというのはわかりやすく、段階的に詳細化してプリミティブな機能を受
け持つ単位を抽出し、それを再利用単位にするというのも論理的です。
構造化アプローチで大きな問題だとされたのが、要求と（ソフトウェアの）設計
の間に論理的には解析しきれない間隙があることでした。機能に対する要求は「アル
ゴリズム＋データ構造＝プログラム 6
」に分割されて実現されます。その分割に人為的
なファクターがかかって、ある人がやった設計と別の組織がやった設計で大きな差が
出てしまう、同一プロジェクトメンバがやっても要求に微細な違いがあれば必ずしも
同一の分割モジュールが生成できるとは限らない、その結果、ソフトウェアは変更拡
張され続けるものなのに、a) どのモジュールに変更を加えたらよいのか、b) 新しい
モジュールをつくって既存モジュールのどこにそれを接続させればよいのか、の決定
が開発者やチームごとに異なってしまい、それを繰り返すと、別チームにはメンテナ
ンスできないソフトウェアになる危険をはらんでいました。せっかく再利用部品をつ
くってもプロジェクトが異なればまったく役立たない、つまり Meyer のことばでい
えば、構造化アプローチのモジュールには（仕様から実装への）連続性（一般的な用
語では、追跡可能性）がなく、そのためモジュールの組合せがいつも容易とは限りま
せんでした。
5 B. Meyer は、このようなモジュールをはかる尺度をまとめて、モジュールの「５つの基準」と呼んでいます[Meyer88] [Meyer97]。
6 Pascal で有名な Niklaus Wirth が 1975 年に著した著書のタイトルが " Algorithms + Data Structures = Programs"（Prentice-Hall）です。
kanazawa.indb 13 08.11.17 0:15:50 PM