Loading article…
コンピュータ プログラミングにおいて、ソフトウェア フレームワークとは、汎用的な機能を提供するソフトウェアを、ユーザーが記述した追加のコードによって選択的に変更し、アプリケーション固有のソフトウェアを提供する抽象化です。ソフトウェア フレームワークは、アプリケーションを構築および展開するための標準的な方法を提供し、ソフトウェア アプリケーション、製品、およびソリューションの開発を容易にするために、より大きなソフトウェア プラットフォームの一部として特定の機能を提供する、汎用的で再利用可能なソフトウェア環境です。
ソフトウェア フレームワークには、さまざまなコンポーネントをまとめてプロジェクトまたはシステムの開発を可能にするサポート プログラム、コンパイラ、コード ライブラリ、ツールセット、アプリケーション プログラミング インターフェイス (API)が含まれる場合があります。
フレームワークには、通常のライブラリとは異なる重要な特徴があります。
- 制御の反転: フレームワークでは、ライブラリや標準のユーザーアプリケーションとは異なり、プログラム全体の制御フローは呼び出し元ではなくフレームワークによって決定されます。 [1]これは通常、テンプレートメソッドパターンを使用して実現されます。
- デフォルトの動作: これは、フレームワークによって提供される抽象クラスのテンプレート メソッド パターンの不変メソッドを使用して提供できます。
- 拡張性: ユーザーはフレームワークを拡張できます (通常は選択的なオーバーライドによって)。また、プログラマーは特殊なユーザー コードを追加して特定の機能を提供することもできます。これは通常、スーパークラスのテンプレート メソッドをオーバーライドするサブクラスのフック メソッドによって実現されます。
- 変更不可能なフレームワーク コード: フレームワーク コードは一般に、ユーザーが実装した拡張機能を受け入れながら、変更されることは想定されていません。つまり、ユーザーはフレームワークを拡張できますが、コードを変更することはできません。
根拠
ソフトウェアフレームワークの設計者は、設計者とプログラマーが、実用的なシステムを提供するためのより標準的な低レベルの詳細に対処するのではなく、ソフトウェア要件を満たすことに時間を費やせるようにすることで、ソフトウェア開発を容易にし、全体的な開発時間を短縮することを目指しています。[2]たとえば、Webフレームワークを使用して銀行のWebサイトを開発するチームは、リクエスト処理や状態管理の仕組みではなく、銀行業務に特有のコードを書くことに集中できます。
フレームワークはプログラムのサイズを大きくすることが多く、この現象は「コード膨張」と呼ばれます。顧客の需要主導のアプリケーション ニーズにより、競合するフレームワークと補完的なフレームワークの両方が製品に組み込まれることがあります。さらに、API が複雑なため、フレームワークの使用方法を学習するために追加の時間を費やす必要があり、全体的な開発時間の意図した短縮が達成されない場合があります。この批判は、開発スタッフが特別なフレームワークや新しいフレームワークに初めて遭遇したときには、明らかに当てはまります。[要出典]このようなフレームワークがその後のジョブ タスクで使用されない場合、フレームワークの学習に費やされた時間は、プロジェクトのスタッフが使い慣れている目的に応じて記述されたコードよりもコストがかかる可能性があります。多くのプログラマーは、一般的なニーズのために便利な定型コードのコピーを保持しています。
ただし、フレームワークを習得すると、将来のプロジェクトをより迅速かつ簡単に完了できます。フレームワークの概念は、万能のソリューション セットを作成することであり、慣れれば、コード生成は論理的に増加するはずです。出力製品に最終的にバンドルされるコードのサイズや、その相対的な効率性と簡潔性については、そのような主張はありません。ソフトウェアがタイトな (小さく、完全に制御され、指定された) 実行可能モジュールを作成するコンパイラ オブジェクト リンカーでない限り、ライブラリ ソリューションを使用すると、必然的に余分なものや未使用の無関係なアセットが取り込まれます。
この問題は依然として残っていますが、10 年以上にわたる業界の経験[要出典]から、最も効果的なフレームワークは、サード パーティが汎用目的で開発した汎用的な「万能」フレームワークを使用するのではなく、企業の共通コードをリファクタリングして進化したフレームワークであることがわかっています。その一例は、オフィス スイートなどのアプリケーション パッケージのユーザー インターフェイスが、以前はバラバラだったバンドル アプリケーションが統合されて、より緊密で小さなスイートに成長するにつれて、共通の外観、操作性、データ共有の属性とメソッドを持つようになることです。新しい/進化したスイートは、不可欠なユーティリティ ライブラリとユーザー インターフェイスを共有する製品になることがあります。
この論争の傾向は、フレームワークに関する重要な問題を提起しています。単に問題を解決するフレームワークではなく、エレガントなフレームワークを作成することは、科学というよりはむしろ技術です。「ソフトウェアのエレガンス」とは、明快さ、簡潔さ、無駄の少なさ (余分な機能や無関係な機能、その多くはユーザー定義) を意味します。たとえば、コードを生成するフレームワークの場合、「エレガンス」とは、単に正しいコードを生成するのではなく、ある程度知識のあるプログラマーにとってクリーンで理解しやすいコード (したがって、簡単に変更できるコード) を作成することを意味します。エレガンスの問題は、比較的少数のソフトウェア フレームワークが時の試練に耐えてきた理由です。最高のフレームワークは、その基盤となる技術の進歩に合わせて、優雅に進化してきました。進化したとしても、多くのパッケージは、新しい方法と並行して、本来は置き換えられるはずだった方法が保持されるため、最終的なソフトウェアを肥大化させるレガシー機能を保持します。
例
ソフトウェア フレームワークには通常、ユーザー アプリケーションのブートストラップを支援するために、かなりのハウスキーピング コードとユーティリティ コードが含まれていますが、一般的には次のような特定の問題領域に重点を置いています。
- 美術描画、音楽作曲、機械CAD [3] [4]
- 財務モデリングアプリケーション[5]
- 地球システムモデリングアプリケーション[6]
- 意思決定支援システム[7]
- メディアの再生とオーサリング
- ウェブフレームワーク
- ミドルウェア
- Cactus Framework – 高性能科学計算。
- アプリケーション フレームワーク- 一般的な GUI アプリケーション。
- エンタープライズアーキテクチャフレームワーク
- Oracle アプリケーション開発フレームワーク
- Laravel (PHP フレームワーク)
- マルウェア、例えばPipedream
- PHP4デルファイ
建築
Preeによると、[8]ソフトウェアフレームワークは、凍結スポットとホットスポットで構成されています。凍結スポットは、ソフトウェアシステムの全体的なアーキテクチャ、つまりその基本コンポーネントとそれらの関係を定義します。これらは、アプリケーションフレームワークのインスタンス化では変更されません（凍結）。ホットスポットは、フレームワークを使用するプログラマーが独自のコードを追加して、独自のプロジェクトに固有の機能を追加する部分を表します。
オブジェクト指向環境では、フレームワークは抽象クラスと具象 クラスから構成されます。このようなフレームワークのインスタンス化は、既存のクラスを合成してサブクラス化することで行われます。 [9]
必要な機能は、テンプレート メソッド パターンを使用して実装できます。テンプレート メソッド パターンでは、凍結されたスポットは不変メソッドと呼ばれ、ホット スポットはバリアント メソッドまたはフック メソッドと呼ばれます。スーパークラスの不変メソッドはデフォルトの動作を提供し、各サブクラスのフック メソッドはカスタム動作を提供します。
ソフトウェアフレームワークを使用して具体的なソフトウェアシステムを開発する場合、開発者はシステムの特定のニーズと要件に応じてホットスポットを利用します。ソフトウェアフレームワークは、ハリウッド原則「私たちに電話しないでください。私たちから電話します。」[10] [11]に依存しています。つまり、ユーザー定義のクラス（新しいサブクラスなど）は、定義済みのフレームワーククラスからメッセージを受け取ります。開発者は通常、スーパークラスの 抽象メソッドを実装することでこれを処理します。
参照
参考文献
- ^ Riehle, Dirk (2000)、「フレームワーク設計：ロールモデリングアプローチ」（PDF）、スイス連邦工科大学
- ^ 「Framework」。DocForge。2018年10月7日時点のオリジナルよりアーカイブ。 2008年12月15日閲覧。
- ^ Vlissides, JM; Linton, MA (1990)、「Unidraw: ドメイン固有のグラフィカルエディターを構築するためのフレームワーク」、ACM Transactions on Information Systems、8 (3): 237–268、doi : 10.1145/98188.98197、S2CID 11248368
- ^ Johnson, RE (1992)、「パターンを使用したフレームワークの文書化」、オブジェクト指向プログラミングシステム、言語、およびアプリケーションに関する会議議事録 - OOPSLA '92、ACM Press、pp. 63–76、doi : 10.1145/141936.141943、ISBN 0201533723、S2CID 604969
{{citation}}: CS1 メンテナンス: 日付と年 (リンク) - ^ Birrer, A; Eggenschwiler, T (1993)、「オブジェクト指向プログラミングに関するヨーロッパ会議の議事録」、金融工学分野のフレームワーク：経験レポート、Springer-Verlag、pp. 21–35
- ^ Hill, C; DeLuca, C; Balaji, V; Suarez, M; da Silva, A (2004)、「地球システムモデリングフレームワーク (ESMF) のアーキテクチャ」、科学と工学におけるコンピューティング、6 : 18–28、doi :10.1109/MCISE.2004.1255817、S2CID 9311752
- ^ Gachet, A (2003)、「意思決定支援システム開発のためのソフトウェアフレームワーク - DSS 開発ツールの分類における新しいコンポーネント」、Journal of Decision Systems、12 (3): 271–281、doi :10.3166/jds.12.271-280、S2CID 29690836
- ^ Pree, W (1994)、「メタパターン: 再利用可能なオブジェクト指向設計の本質を捉える手段」、第 8 回ヨーロッパオブジェクト指向プログラミング会議の議事録、コンピュータサイエンスの講義ノート、821、Springer-Verlag : 150–162、CiteSeerX 10.1.1.74.7935、doi :10.1007/BFb0052181、ISBN 978-3-540-58202-1
- ^ Buschmann, F (1996)、パターン指向ソフトウェアアーキテクチャ第1巻：パターンのシステム。Chichester、Wiley、ISBN 978-0-471-95869-7
- ^ Larman, C (2001)、「UML とパターンの適用: オブジェクト指向分析と設計および統合プロセス入門(第 2 版)」、Prentice Hall、ISBN 978-0-13-092569-5
- ^ ガンマ、エリック、ヘルム、リチャード、ジョンソン、ラルフ、ブリシデス、ジョン(1994)。デザインパターン。アディソン・ウェズリー。ISBN 0-201-63361-2。
外部リンク
Wiktionary のソフトウェア フレームワークの辞書定義
ウィキメディア・コモンズのソフトウェアフレームワークに関連するメディア