ソフトウェアの品質要因 その４「再利用性」

再利用性(reusability)

■定義：再利用性(reusability)
「再利用性」とは、多種多様なアプリケーションの構築に使うことのできる、ソフトウェア要素の能力である。

再利用は、他の品質要因を高めることに繋がる

なぜ「再利用性」が要求されるようになったのか。それは、ソフトウェアシステムを構築するとき、
似たようなパターンを経て開発されるケースが非常に多いためです。
そのようなソフトウェア開発における共通性をうまく利用することができれば、
過去に遭遇した問題の解決策を、再び考え直さずに済みます。
共通するパターンを把握することで、再利用可能なソフトウェア要素を多くの異なる開発に応用することができます。

また、「再利用性」は、「再利用性」以外のソフトウェア品質要因にも影響を与えます。
再利用性を活かすことで、実質的にパターンやモデル、設計や実装などのソフトウェア要素の再発明が減り、
同じコストで、より多くの労力を「正確さ」や「頑丈さ」などのその他の品質要因の向上に割くことが期待できます。

再利用は手段であり、目的ではない

再利用をすることは良いことですが、無闇に再利用をしようとしてはならない。
なぜなら、再利用は手段であり目的ではないからです。
本来、再利用とは正しい分析や設計を心がけていれば、自然とできてしまうものです。
再利用は目的ではなく、あくまで手段であり、そして結果なのです。

「再利用」とは、過去に書いたプログラムを流用して、楽をしようというだけのものではありません。
それこそ、ただプログラムコード至上主義で、無意味です。どうせコードなんてすぐに書けてしまうのです。
最も大変なのは、モデリングやオブジェクトの抽出であったり、設計であって、コードを書くことではありません。
コードの再利用を目的とした再利用は、あまり意味がないのです。

再利用はホワイトボックス化するのが基本

ソフトウェア開発において、「再利用可能な設計」というものを考える場合、
一体どこにどういう場面で再利用されるのかという、具体的なターゲットが決まっていない局面に出会うことが非常に多い。
これが実は問題なのです。つまり、「いつかどこで使われるかわからないけど、どんな風に使われても大丈夫なように考えてソフトを作ってね」
という、汎用化の行き過ぎた考え方は、ソフトウェア開発においては、いささか無理があるという話です。

「再利用可能な設計」というものを考える場合、
いつどこでどんなときに再利用できるように設計する必要があるのか、よく考えてみましょう。
もし再利用するにあたっての具体的な場所が思い当たるのであれば、その再利用の努力は報われるだろう。
しかし、ターゲットが特に決まらないまま「再利用性」と「汎用性」だけを追求していくと、
どんどん中身が薄くなり、再利用のブラックボックス化が進んでしまい、
一体なんのための再利用なのか、全くわからない代物ができあがってしまうことがあります。
何をターゲットに再利用できるように設計しているのか意識し、ホワイトボックス化に努めることが大切です。
再利用の意味や主張が抜けてしまった再利用のためだけの設計は、再利用にあらずです。
つまるところ、よく分析しましょうということです。

再利用できるソフトウェアシステムの要素

再利用できるソフトウェアシステムの要素には、以下のものが考えられます。

ドメイン
ドメインとは、ある立場から見た場合のシステムの見え方のことです。
あるシステムをWebベースで作成した後、画面や操作はまったく同じにして
Windowsアプリケーションで作り直して欲しいと言われた場合、
データベースや画面の設計をそのまま流用することで、新たにコーディングだけやり直せばいい。
例えばそういうことです。ドメインはシステムごとに独立した単位なので再利用することができます。

デザインパターン
ソフトウェア開発における「デザインパターン」とは、
過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、
名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したものです。
なかでも有名なものにＧｏＦデザインパターンがあります。
そのようなデザインパターンをそのまま、時には応用して「設計パターン」そのものを再利用しましょうというお話。

メタモデル
「メタモデル」とは、モデルをモデル化したものです。
より厳密に言えば、「モデルの記述要素（モデル要素）の意味と構文を記述したモデル」を指します。
ここで言うモデルとは、情報システムを構成するソフトウェア、あるいは
実世界における概念や情報などを記述したもののことです。一般的に、その記述にはオブジェクト概念が用いられます。

このとき「記述するものと、記述されるもの」との関係は無限に繰り返されることもあります。
つまり、メタモデルを記述するモデル（メタ-メタモデル）も存在し、
メタ-メタ-メタモデルも、メタ-メタ-メタ-メタモデル存在し得るということです。
これらをメタ階層（M0〜Mn）と呼びます。開発スタイルや開発ツールを作成するような場合、
このようなメタモデルの概念が必要です。また、これは抽象的概念であるためシステムごとに再利用することができます。

コンベンション(規約)
「コンベンション」とは、システム設計に関する規約全般のことです。
コーディングコンベンション(コーディング規約)という単語が一番馴染みがあるでしょうか。
コーディングコンベンションとはコードを書く時の規則のことです。
例えばコメントの書き方や、変数やメソッド名の付け方などを決めたのがそれです。
システム開発をすすめるときは、それに則った上でコーディングしていきます。

当然のことながら、こうした取り決めは一度決めてしまえば様々なシステムに適用することができます。
もちろん、コンベンションはコーディングに限った話ではありません。
仕様書や設計書の書き方、そしてそもそもどんな仕様書を用意すべきかなど、
システム開発の手法を規定する様々な規約がコンベンションであり、これが再利用可能となります。
システム開発手法のモデル化という意味では、これも一種のメタモデルと言うことができます。

アプリケーションフレームワーク
アプリケーションフレームワーク（Application Framework）とは、プログラミングにおいて、
特定のオペレーティングシステムのためのアプリケーションの標準構造を実装するのに使われるクラスやライブラリの集まりです。
多くの再利用可能なコードをフレームワークとして構築してまとめることによって、
新たなアプリケーションのために標準的なコードを改めて書かなくて済み、開発者の作業効率を高めます。
通常、フレームワークの実装にはオブジェクト指向プログラミング技術によって構築され、
その性質の恩恵を受けながら、柔軟にアプリケーションの標準構造を再利用することができます。