ソフトウェアフレームワーク
ソフトウェアフレームワーク（英: software framework）とは、プログラミングにおいて、アプリケーションプログラム等に必要な一般的な機能が、あらかじめ別に実装されたものである。使い方としては、クラスライブラリとして実装されている場合は、継承したクラスを作ってユーザーが選択的に上書きしたり特化させたりする（一例であって、他にもさまざまな形態がある）。文脈から明確な場合は単に「フレームワーク」としたり、「アプリケーションフレームワーク」など前や後に別の語をつなげた複合語も多い。
ソフトウェアフレームワークは、はっきり定義されたAPIを持ち、具体的な実装を再利用可能な形で隠蔽しているという点でライブラリとよく似ており、両者の間に明確な境界は無いし、分類のための明確な基準も無い。観点のひとつとしては、いわゆる「メインループ」あるいは「イベントループ」をアプリケーション側が持つか否か、という分類がある。メインループをアプリケーション側が持っていてそこから呼び出される形態のものがライブラリであり、一方フレームワークではメインループはフレームワーク側にあり、アプリケーションはそちら側から呼ばれるイベントハンドラによって駆動される（これについて「制御の反転」という語で説明されることがある[1]）。
しかしこの分類は、両者を特徴づけるはっきりした分類というわけではない。アプリケーションの main関数はランタイムライブラリ中のスタートアップルーチンから呼び出される。また、広く使われているようなフレームワークでは、たいていはメインループをアプリケーション側が持つことができるようなメカニズムが用意されている。
背景と批判
ソフトウェアフレームワークは、システム構築に必須な標準的かつ低レベルの詳細を設計者やプログラマが検討する時間を省き、要求仕様の実現に多くの時間を割けるようにし、ソフトウェア開発を容易にすることを目指している[2]。例えば、銀行のWebサイト構築にWebアプリケーションフレームワークを使っている開発チームは、要求処理や状態管理の機構を検討する時間を削減して、口座からの引き落としといった操作に注力できる。
批判としては、フレームワークはコードを肥大化させるという主張もある。これは複数のフレームワークで競合する部分や補い合う部分があり、APIも複雑に絡み合っているためでもある。
フレームワークの使い方を学ぶ時間がかかるという主張もある。ただし一度フレームワークを学べば、同じフレームワークであれば、次のプロジェクトからはより素早く完璧な応用が可能となる。
フレームワークは他のプラットフォーム製品（オペレーティングシステム、DBMSなど）と同様に、特定のフレームワーク・ベンダーや、特定のバージョンに依存（ロックイン）されるリスクがあるとの主張もある。このため機能内容や代替製品などの確認も必要である。
いずれにしても、適切なフレームワークの選定は特に重要である。開発途中で、選択したフレームワークが開発要件を満たさないと判明した場合や、そのフレームワークの開発・提供が打ち切られた場合などは、開発途中で別のフレームワークに移行して（場合によっては基本設計から）再開発する必要が発生するためである。
例
ユーザーアプリケーションを立ち上げるのを助けるため、ソフトウェアフレームワークには一般にかなりの雑多なコードやユーティリティコードが含まれているが、全体としては特定の問題領域に注目した機能を提供している。以下に例を挙げる。
- 絵の描画、音楽作成、機械CAD[3][4]
- 様々なプログラミング言語とターゲットマシン向けのコンパイラ[5]
- 金融モデリングアプリケーション[6]
- 地球システムモデリングアプリケーション[7]
- 意思決定支援システム[8]
- マルチメディアフレームワーク（メディアの再生と制作）
- Webアプリケーションフレームワーク
- ミドルウェア
アーキテクチャ
Preeによれば[9]、ソフトウェアフレームワークには「凍った部分 (frozen spot)」と「熱い部分 (hot spot)」がある。「凍った部分」はソフトウェアシステム全体のアーキテクチャ（基本コンポーネント群とそれらの相互関係）を定義する。それらはそのフレームワークを使って何を実装した場合でも常に変化しない。一方、「熱い部分」はプログラマがプロジェクト固有の機能に対応したコードを追加できる部分である。
ソフトウェアフレームワークには、ソフトウェアアーキテクチャ内でアプリケーションプログラマが特定の機能に対応したコードを置ける場所（すなわち「熱い部分」）が定義してある。
オブジェクト指向言語で、かつそれがクラスベースで具象クラスと抽象クラスがある場合には、前述の「凍った部分」を具象クラスで実装し、「熱い部分」のAPIを抽象クラスで宣言する、というスタイルでフレームワークを作る、という定型的手法がある。利用者（開発者）は、「熱い部分」の抽象クラスを継承した[10]具象クラスを作り、メソッドなどに必要な機能を作り込む[11]。
冒頭部で言及した制御の反転について、「ハリウッドの原則」と言われることがある（詳細は制御の反転#ハリウッドの原則を参照）。つまり「制御の反転」を前提として設計されているフレームワークを使う場合、開発者が書くコードが必要な時にフレームワークのコードを呼ぶスタイルではなく、フレームワークのコードから、ユーザーのクリックなどのイベントなどに応じて開発者が書くコードが呼ばれるというスタイルになる、ということを、（買い手市場の）ハリウッドでは、仕事が得られる見込みがあるのならば電話が掛かってくるし、自分から電話を掛けても見込みは薄い、と例えたジョークである。
汎用フレームワークの一覧
- BFC (en) - .NET環境におけるデータベース中心型分散コンピューティングアプリケーション開発のためのRADフレームワーク
- CNI (Compiled Native Interface) - JavaコードとC++で書かれたアプリケーションやライブラリで相互に呼び出せるようにするGNU GCJ コンパイラ用のソフトウェアフレームワーク
- Component-based Scalable Logical Architecture (en) (CSLA) - .NETでビジネスオブジェクトを使った堅牢なオブジェクト指向プログラムを作成する標準的方法
- Habanero.NET (en) (Habanero) - .NETでドメイン駆動設計の原則を用いてエンタープライズアプリケーションを作成するためのオープンソースのフレームワーク
- Java Native Interface (JNI) - Java仮想マシン (VM) 上で動作しているJavaコードとVM外で動作するネイティブアプリケーション（そのハードウェアやOS上で直接動作するプログラム）や他の言語（C言語、C++、アセンブリ言語など）で書かれたライブラリの相互呼び出しを可能にする。
- Leonardi (en) - GUIアプリケーション向けのオープンソースのアプリケーションフレームワーク
- ActionScript Foundry (en) - ActionScript 3 とJavaで書かれたオープンソースのFlexフレームワーク
- Spring - Javaプラットフォーム向けのオープンソースのアプリケーションフレームワーク
- JSF - Javaプラットフォーム向けのオープンソースのWebアプリケーションフレームワーク。コンポーネントベースのイベント駆動型アプローチによる素早い開発。
- Symfony - PHPプラットフォーム向けのオープンソースのアプリケーションフレームワーク
- CodeIgniter - PHPプラットフォーム向けのオープンソースのアプリケーションフレームワーク
- Rails - Rubyプラットフォーム向けのフリーソフトウェアのアプリケーションフレームワーク
- Zend Framework - PHPプラットフォームと緩やかに結合したコンポーネントライブラリを持つ、強力で拡張性のあるアプリケーションフレームワーク
- Twisted - インターネットアプリケーション用にPythonで書かれたオープンソースのイベント駆動型アプリケーションフレームワーク
- Google Web Toolkit (GWT) - オープンソースのJavaソフトウェア開発フレームワーク
- liferay - オープンソースのWebアプリケーションシステム用のポートレットフレームワーク
関連項目
- アプリケーションフレームワーク
- クラス (コンピュータ)
- デザインパターン (ソフトウェア)
- Don't repeat yourself
- Jini | Upnp
- プログラミングパラダイム
- Webアプリケーションフレームワーク
脚注・出典
- ^ Riehle, Dirk (2000), Framework Design: A Role Modeling Approach, Swiss Federal Institute of Technology
- ^ “Framework”. DocForge. 2008年12月15日閲覧。
- ^ Vlissides, J M; Linton, M A (1990), “Unidraw: a framework for building domain-specific graphical editors”, ACM Transactions of Information Systems 8 (3): 237-268
- ^ Johnson, R E (1992), “Documenting frameworks using patterns”, Proceedings of The Conference on Object Oriented Programming Systems Languages and Applications (ACM Press): 63-76
- ^ Johnson, R E; McConnell, C; Lake, M J (1992), Giegerich, R; Graham, S L, eds., “The RTL system: a framework for code optimization”, Proceedings of the International workshop on code generation (Springer-Verlag): 255-274
- ^ Birrer, A; Eggenschwiler, T (1993), “Proceedings of the European conference on object-oriented programming”, Frameworks in the financial engineering domain: an experience report (Springer-Verlag): pp. 21-35
- ^ Hill, C; DeLuca, C; Balaji, V; Suarez, M; da Silva, A (2004), “Architecture of the Earth System Modeling Framework (ESMF)”, Computing in Science and Engineering: 18-28
- ^ Gachet, A (2003), “Software Frameworks for Developing Decision Support Systems - A New Component in the Classification of DSS Development Tools”, Journal of Decision Systems 12 (3): 271-281
- ^ Pree, W (1994), “Meta Patterns-A Means For Capturing the Essentials of Reusable Object-Oriented Design”, Proceedings of the 8th European Conference on Object-Oriented Programming (Springer-Verlag): 150-162
- ^ Javaなどではインタフェースの場合もあり、その場合は「インタフェースを実装した」となる
- ^ Buschmann, F (1996), Pattern-Oriented Software Architecture Volume 1: A System of Patterns. Chichester, Wiley, ISBN 0471958697