ソフトウェア再利用の概念

ソフトウェア再利用の概念について整理してみた。

【参考】
ソフトウェア工学 第13回 保守と再利用

再利用の罠

SOAのための再利用エンジニアリング

【0】ソフトウェア再利用の動機

ソフトウェア開発では、過去のソフト資産や新しいフレームワークなどを流用することで、開発コストをどれだけ削減できるか、再利用することでどの程度までの品質を担保できるか、の見極めが設計工程で重要になる。

再利用できるライブラリ、部品、アーキテクチャがあれば、それらを流用することで、開発工数をカットできる。
しかも、既に本番運用されていれば、稼働実績もあるから、品質も担保されている。
開発中に発生するリスクも、稼働実績から得られたノウハウを流用して対処することもできる。

だが、そのままソフトウェア再利用できるとは限らない。
むしろ、再利用したい新しい技術を取り入れた開発案件では、技術にメンバーが慣れるリスク、技術そのものの適用範囲や実現可能性のリスクがとても大きい。
やってみないと分からないのだ。

だから、アーキテクチャ設計、方式設計では、ソフトウェア再利用のために、事前にプロトタイプを作って機能の実現可能性や性能について事前検証する時が多い。

ソフトウェア開発の案件は、今までと同じような技術を使う時はあまりない。
毎年のようにハードウェアの性能が上がって、以前とは違う環境になるし、次から次へと新しいバズワードと共に新しい技術が現れる。
それらをどこまで自分のものとして取り入れられるか？

【1】ホワイトボックス再利用、ブラックボックス再利用

ブラックボックス再利用とは、再利用資産を変更なしでその まま利用する。
よくある例は、GUIコンポーネントや数値演算ライブラリなど。
利点は、変更の必要がないので、公開されたインターフェイス(API)をうまく使えば、開発の効率化に大きく貢献できる。
.NET FrameworkやEJBもその事例に入るだろう。
.NETライブラリは、C#だけでなく、VBでもそのAPIを参照することができる。
つまり、特定の言語に依存しない場合もある。

ホワイトボックス再利用とは、再利用資産を要求に合わせて部分的に変更して使用する。
よくある例は、オブジェクト指向設計によるフレームワークなど。
フレームワークは、コンポーネントやライブラリと同様に、はっきり定義されたAPIを持ち、実装の詳細は隠蔽している特徴を持つ。
しかし、コンポーネントやライブラリでは、呼び出し側のプログラムがライブラリの制御構造を修正できないのに対し、フレームワークは、呼び出し側のプログラム側で機能を継承して追加したり変更できたりする。
つまり、フレームワークは制御の反転構造を持つ。
古くはStruts、今ならRailsがその事例に当たるだろう。

但し、フレームワークは特定の言語に依存するのが普通。
新しい言語ほど、便利な機能が多いのが普通。

【2】再利用する対象の概念はおおまかに3つある。
コンポーネント、フレームワーク、プロダクトラインの3つ。

コンポーネント指向開発では、ソフトウェアを機能単位にコンポーネントとして分解し、それらを組み合わせてソフトウェアを構築する。
プロダクトライン開発では、ドメイン単位に再利用する部品(コア資産)を作る開発とそれら部品を組み合わせた開発から成る。
イメージ的には、コンポーネントの方がドメインよりも粒度は小さい。
ドメインは、ビジネスオブジェクトないし組込みシステムの機能単位の部品に近い。

コンポーネント指向開発やプロダクトライン開発は、再利用する部品を作るのが大変だ。
コンポーネントのように、汎用的なライブラリを作るレベルならば、仕様の詳細を決めれば作るだけ。
でも、プロダクトライン開発のように、再利用できるビジネスオブジェクトないし機能の部品を作るには、かなりの手間がかかる。
コア資産を開発している間に、ビジネス状況が急変したり、開発の基盤を支えるプログラミング言語やライブラリがVerUpして追いつけなくなったりする。

フレームワーク開発は、アプリケーションの土台となる機能(DBアクセス、画面遷移、Webセッション管理など)はフレームワークが担当し、機能は一から実装するスタイル。
多分、普通の開発案件はこのパターンが多い。

フレームワークを使う場合は、技術リスクの把握が一番大事。
プロトタイプを作ってアーキテクチャや性能を事前検証したり、開発者のためにコーディングルールを決めたり、フレームワークを使うための開発環境を整備したり、色々手間がかかる。

SI独自のフレームワークを使っているなら、開発ノウハウは新規加入した開発者に展開できないから、習得コストもかかる。
最初のうちは、コードレビューして、開発者の習熟度をチェックすることも必要だ。

【3】開発コストの観点は2つある。

一つは、再利用するための開発コストの観点。
再利用できるような部品を作るには、開発者が理解しやすく、使用する状況で便利だと思えるAPIを用意しなければならない。
部品の粒度が大きいほど、実装するソースも大きくなるから、開発コストも大きくなる。

プロダクトライン＞フレームワーク＞コンポーネント＞ソースコードの順に開発コストが小さくなる。

2つ目は、再利用ライブラリを流用して開発するコストの観点。
再利用できるライブラリや部品があれば、それらを組み合わせるだけですぐに製品が作れる。
一から作らなくていいから、プロダクトライン＜フレームワーク＜コンポーネント＜ソースコードの順に開発コストが大きくなる。

この2つの開発コストのバランスから、再利用できる部品を作るべきか、計画するのが重要になってくる。

【4】でも、ソフトウェア再利用は元が取れるのか？

SI独自のフレームワークで開発する案件はどこも大変だった記憶がある。
時代の流れに沿っていけないのだ。

SIerの俺様フレームワークは最悪に激しく同意: プログラマの思索

プロダクトライン開発は、その理想が実際の現場と合っていない時が多い。
再利用できる移植性という品質を重視しながら、運用後の機能追加や修正のしやすさも保証するという保守性の品質を両立するのはとても難しい。

ソフトウェア部品化の幻想: プログラマの思索

他にもSOAのようなサービス単位に流用できる部品を作るという開発スタイルも提唱されていたが、結局の所、うまくいっていないのが実情だろう。
部品の粒度が大きくなるほど、保守の工数は増大する。
粒度の大きい部品、例えば、ビジネスオブジェクトやドメインごとの部品は、成功例があまりないと言えるだろう。

むしろ、粒度の小さい部品、例えば、コンポーネントやフレームワークのレベルでは、再利用できる部品作りにさほど工数がかからないし、品質もそこそこ保証しやすい。
初めて使う開発者も、APIの使い方さえ覚えるだけなので、習得コストも小さい。
フレームワークでは、CoCのようにプログラミングの書き方そのものを開発者に強制して、その設計思想に染めることもできる。

しかし、その再利用できるコンポーネントやフレームワークさえも、その寿命は短い。
業務システムがユーザ企業が生きている限り使われるスパンに比べて、再利用できるアーキテクチャそのものが不安定なのだ。
再利用の幻想には囚われ過ぎない方がいいと思う。