オブジェクト指向入門 第2版 原則・コンセプト 第1章 ソフトウェアの品質

某社のクマとキツネとMBP ※ 記事の内容に一切関係ありません

# はじめに

先日,ひょんなことから「オブジェクト指向入門 第2版 原則・コンセプト」(バートランド・メイヤー著,酒匂 寛 訳, 翔泳社, 2007)および,同「方法論・実践」(2008)を図書館で借り,オブジェクト指向に入門した.

確実に内容を理解し,定着を図るため,読んだ内容をプレゼンテーション形式でまとめ,インターネット上での公開を始めた.

らりょす Advent Calendar 2017」では,この「1人オブジェクト指向勉強会」の進捗を報告していくことにする.

※内容に誤りなどがあればやんわりと指摘していただければと思います.


# スライド

第1章では,主に「ソフトウェアの品質」を左右する要因について述べている.
以下では,簡単な内容(私の理解した内容)の説明を行う.

## ソフトウェアの品質

ソフトウェアの品質は外的品質要因内的品質要因の2つに分けることができる.ユーザの興味の対象は当然ながら操作性などの外的品質要因であり,内的品質要因は興味の対象ではない.しかし,外的品質要因を一定以上に保つために,内的品質要因を設計者や,我々エンジニアが保証する必要がある.

しかし,ここで注意しなければならないのは,内的品質要因はあくまで「外的品質要因を保証する手段」であり,そこにこだわりすぎる必要はないということである.そのソフトウェアの全体を見失ってしまわないよう,注意する必要がある.

### 外的品質要因

#### 1. 正確さ

プログラムが仕様どおりに動作することである.この要件を満たすことができないソフトウェアはまずあってはならないだろう.

#### 2. 頑丈さ

異常な状態に対して適応する能力のことである.要するに,仕様に定められていない状況において,破壊的なイベントを引き起こすことなく,適切なエラーメッセージの出力によりきれいにソフトウェアを終了させる必要がある.これを graceful degradation (気配りのグレードダウン) と呼んでいる.

ここで「通常の状態」「異常な状態」の定義について考える.これらの基準はあくまで設計の中で考慮されているかどうかであり,「こうであるべきであろう」などの主観的なものではないことに注意が必要である.

#### 3. 拡張性

仕様の変更に対する適応しやすさのことである.仕様の変更は全体に,そして曖昧に発生する.したがって,「設計を単純に」し「非集中化」を行うことで,拡張性をもたせることが必要である.

オブジェクト指向は,単純で非集中的なシステムの設計を助けるシステムアーキテクチャ手法である.

#### 4.再利用性

多様なアプリケーションの構築に使用できる能力の要素である.ソフトウェアシステムの共通パターンをくくりだし,他の開発に応用することで,開発コストを削減し,他の品質要因の向上に割くことができるようになるのである.

#### 5. 互換性

他のソフトウェア要素との組み合わせやすさである.ソフトウェアは他のソフトウェアと相互に成り立つ必要がある.そのため,設計が同質で,コミュニケーションの標準規約が一致していることが互換性の鍵になる.

この考え方は,抽象データ型・オブジェクト指向の基本的な考え方になる.

#### 6. 効率性

ソフトウェア資源を出来る限り必要としないことである.「性能」とほぼ同じ意味である.

効率性を考える上で,拡張性や再利用性など,他の目標とのバランスを取ることを忘れてはならない.ソフトウェアの正確さがもっとも重要であり,効率性に時間を割きすぎる必要はない.

とはいえ,効率を求めるユーザは居るだろうし,効率が正確さに影響をあたえる場合もある.したがって,効率性を蔑ろにしてもならない.

#### 7. 可搬性

様々な環境への移植しやすさのことである.多様なプラットフォームが存在しているが,それらは互換性が低いことが多い.そういった環境で適切に動作するようにソフトウェアを開発する必要がある.

#### 8. 使いやすさ

どのような人でも利用できることである.ユーザ層を限定し,勝手な前提を置いてソフトウェアの開発を行うのではなく,ユーザのことを何も知らないという前提でUIの開発を行う必要がある.

#### 9. 機能性

そのシステムが提供できるサービスの範囲のことである.

機能主義 (featurism) と呼ばれる,高機能を求める圧力は常に存在し,プロジェクトリーダを悩ませる.この機能主義は2つの問題から構成されている.1つは,使いやすさや一貫性を損なってしまうという簡単な問題,もう1つは他の品質要因の向上に労力を避けなくなってしまいがちな困難な問題である.

簡単な問題は,ソフトウェアの全体図を目に見える形でつくり,一貫性を保つための作業を何度も繰り返し,ソフトウェアが1つの塊になるようにすることで解決することができる.

困難な問題は,オブジェクト指向による品質を向上する技法を用い,品質レベルを一定に保つことで解決できる.信頼性や拡張性について妥協することはできないため,機能に満足できない間は,新しい機能の開発に進まない,などの手法がある.

#### 10. 適時性

ユーザが必要とするときにリリースすることである.どれだけ偉大なソフトウェアも世に出すのがおそすぎれば,ユーザを失いかねない.この業界は特に進歩が早いため,適時性の重要性はより一層高まっている.

#### その他の品質要因

・実証性: 不具合の検出等が容易なこと

・統合性: 認証されていないアクセスや修正からデータやプログラムを守ること

・修復性: 欠陥の修復を助ける能力

・経済性: 限られた予算でシステムを完成させることがデキること

### ドキュメントについて

#### 外部向けドキュメント

ユーザがシステムの能力を理解し,快適に利用できる事ができるようにするためのものであり,使いやすさを向上させるためのものである.
⇒ソフトウェアに組み込むのが望ましい.

#### 内部向けドキュメント

開発者向けのドキュメントである.システムの構造と実装方法を理解するのを助け,拡張性を保つ.
⇒良い実装を行うことで,別でドキュメントを書く必要がなくなる(明確さと構造を重視しているため).

#### モジュールインタフェースドキュメント

開発者が,実装方法を理解しなくてもモジュールの機能を理解できるのを助けるドキュメント.
⇒ ツールを用いることで,ドキュメントを自動生成できるような常谷することが望ましい(オブジェクト思考的表現記法を用いることで可能になる).

### トレードオフ

外的品質要因の説明を行う上で,どうしても対立する条件が生まれることがある.

しかし,「正確さ」のトレードオフはまずありえない(正確に動作しないソフトウェアはあってはならない).
それ以外の場合は,対立品質要因を調和させたり,他の要因を諦めることになる.そのときには基準を明確に述べ,意識的に選択を行う努力をする必要がある.

### 特に重要な事柄

・信頼性(正確さと頑丈さ)

・モジュール性(拡張性と再利用性)

・互換性

・可搬性

・使いやすさ

・効率性

・適時性,経済性,機能性

## ソフトウェアの保守について

保守というのは,間違った表現である.なぜならば,ソフトウェアはいくら使ったからといって疲弊しないからである.したがって,ソフトウェアを本来保守する必要はない.

保守のまっとうな作業は「修正」である.まっとうでない保守は「期限を過ぎてからのデバッグ」である.

現状では,後者にも相当のコストが割かれているが,それは変更の実装が困難であることや,操作するデータの物理的構造にプログラムが依存しすぎていることの罰である.