thumb|250px|UML 2.0 のコンポーネント図で、2つのコンポーネントを表現した例。CheckoutコンポーネントはCardProcessingコンポーネントを使用している。

ソフトウェアコンポーネント（）は、ソフトウェアシステムの様々な機能を関心の分離によって分割したものである。システムを独立した結合の弱い再利用可能なコンポーネント（部品）群で構成する設計技法は Component-Based Software Engineering (CBSE) と呼ばれ、ソフトウェア工学の一分野となっている。

コンポーネントの考え方は、サービス指向の起点となっている。例えば、Webサービスやサービス指向アーキテクチャ (SOA) ではソフトウェアコンポーネントの考え方を発展させサービスをコンポーネント化するという考え方をする。

狭義ではEJBなどインタフェースが標準化されたもののみを示し、広義では関数化、クラス化などソースコードレベルで再利用出来る物などを示す。 概要 個々のソフトウェアコンポーネントは、ソフトウェアパッケージだったり、Webサービスだったり、ウェブリソースだったり、相互に関連する機能（とデータ）の集合をカプセル化したモジュールだったりする。

すべてのシステムプロセスを別々のコンポーネントとして配置すると、各コンポーネント内のデータや関数は全て（クラスのコンテンツのように）相互に意味的に関連することになる。この原則のため、コンポーネントはしばしば「モジュラー」であり「統一的」であると言われる。

システム全体として協調動作するため、コンポーネント群は「インタフェース」経由で相互にやりとりする。あるコンポーネントがシステムの他の部分にサービスを提供するとき、他のコンポーネントが利用可能なインタフェースを公開し、どうやって使えばよいかを示す。このインタフェースをコンポーネントの署名とみることができ、それを使う側はコンポーネントの内部（実装）を知る必要はない。この原則によりコンポーネントは「カプセル化」される。本記事にも掲載されているUMLのコンポーネント図ではロリポップ記号（白丸）でこのインタフェースを表現している。

一方コンポーネントは機能するのに他のコンポーネントを必要とすることがあり、サービスの提供に必要となる使用インタフェースも決まっている。UMLのコンポーネント図ではそれをソケット記号（半円）で表し、他のコンポーネントが公開しているインタフェース（ロリポップ）と接続する形で表現している。

thumb|550px|right|UML 2.0 のコンポーネント図でソフトウェアコンポーネント群を表現した例。ホテルの休日予約システムを表現している。

コンポーネントの持つもう1つの重要な特性は「置換可能」だという点で、公開しているインタフェースが同一のコンポーネントを設計時または実行時に相互に置換可能である。インタフェースさえ同一であれば、システムの動作を損なうことなくコンポーネント単位でバージョンアップしたり実装を置換したりできる。

一般に、コンポーネントBがコンポーネントAを即座に置換できる場合、コンポーネントBはコンポーネントAが提供するものを全て提供していなければならず、さらにコンポーネントAが使っていた他の要素以外のものを必要としないようになっていなければならない。

ソフトウェアコンポーネントは、（クラスではなく）オブジェクトまたは複数のオブジェクトの集まりであることが多いが（オブジェクト指向プログラミングの場合）、インタフェース記述言語 (IDL) に従ったバイナリやテキスト形式の場合もある。後者の場合、コンポーネントはコンピュータ内に他のコンポーネントとは独立した形で存在するだろう。

実行コンテキストやネットワークリンクを通してコンポーネントがアクセスされたり共有されたりする場合、コンポーネント自身やそのインタフェースをビットストリームに変換するための何らかのシリアライズ（またはマーシャリング）が行われる。

高品質のソフトウェアコンポーネントではが重要な特徴である。プログラマはソフトウェアコンポーネントを設計・実装する際に、様々なプログラムから利用できるよう心がける必要がある。ソフトウェアコンポーネントを再利用可能なものにするには多大な努力と注意深さを要する。再利用性を備えたコンポーネントは次のような要件を持たなければならない。

文書が完備されている。 完全に評価済みである。 頑健性 - 入力の妥当性を完全にチェックしている。 適切なエラーメッセージやリターンコードを返すことができる。 本来想定していない使われ方をする可能性を考慮している。

歴史 1960年代、科学技術系の様々な計算に使用可能なサブルーチンライブラリが構築された。そうしたサブルーチンライブラリはよく使われる主なアルゴリズムを効率的に実装していたが、用途は科学技術計算に限られていた。商用システムでは、アセンブリ言語、COBOL、PL/Iや他の第二世代や第三世代の言語で書かれた再利用可能なモジュールをシステムやアプリケーションライブラリとして使用するようになっていった。

ソフトウェアをコンポーネント化するという考え方は、1968年、ドイツのガルミッシュ＝パルテンキルヒェンで行われたNATOのソフトウェア工学会議で Douglas McIlroy がMass Produced Software Components と題して発表したのが最初である。この会議はソフトウェア危機と呼ばれた事態への対策を話し合うための会議であった。彼は、その考えをUNIXオペレーティングシステムのパイプとフィルターという形で、世界で初めて実装した。

最近のソフトウェアコンポーネントの概念の多くを定義したのは Stepstone 社の Brad Cox であった。彼はそれを「ソフトウェアIC」と呼び、Objective-Cを開発してその考え方を市場に広めようとした。このあたりの経緯は彼の著書 Object-Oriented Programming - An Evolutionary Approach（1986年）に詳しく記してある。Cox の試みはシリコンのICとソフトウェアICの明らかで基本的な違いのため、失敗に終わった。シリコンのICは物質であるから、需要と供給の関係で売買は成立する。ソフトウェアICはビットの集まりであり、電子部品と同じような売買は成立しなかったのである。

IBM は1990年代初期に System Object Model (SOM) と名づけたソフトウェアコンポーネントのアーキテクチャを提唱した。今日ではいくつかのソフトウェアコンポーネントモデルが成功しているが、それを可能にしたのはマイクロソフトのOLEやCOMが登場したためであると主張する人もいる。

2010年現在、再利用可能なコンポーネントはデータ構造とそのデータ構造に適用されるアルゴリズムをカプセル化したものとなっている。ソフトウェアオブジェクト、ソフトウェアアーキテクチャ、ソフトウェアフレームワーク、デザインパターンなどに基づいて構築されており、オブジェクト指向プログラミングおよび設計の理論を活用している。ソフトウェアコンポーネントとは、ハードウェアの電子部品（electronic component）からの発想でありFoukalas et al "Protocol Reconfiguration Using Component-Based Design"、モジュールの互換性と信頼性を重視していることを意味する。また、フレームワークなしにコンポーネントは存在しないという意味で、個々のコンポーネントよりフレームワークの方が重要だとも言われている。

例

UI UIは機能ごとの小さなUIに分割できる。このUIコンポーネントは状態 (state)・処理 (logic)・見た目 (view) を1箇所に集約しカプセル化している「コンポーネントベース 自分自身の状態を管理するカプセル化されたコンポーネントをまず作成し」 React 2021-03-02閲覧。カプセル化のおかげで外部（例: DOM）に依存せずそれ単体で機能できる（自己完結している）「コンポーネント...は...DOM に状態を持たせないようにすることができます。」React 2021-03-02閲覧「小さく、自己完結的で、（多くの場合）再利用可能なコンポーネント」Vue.js - コンポーネントによる構成。これらの再利用可能なUIコンポーネントを集めそれらの相互作用を定義することで、UI全体を構成することができる「コンポーネントベース ... これらを組み合わせることで複雑なユーザインターフェイスを構築します。」 React 2021-03-02閲覧「ほぼすべてのタイプのアプリケーションインターフェイスは、コンポーネントツリーとして抽象化できます。」Vue.js - コンポーネントによる構成（c.f. マイクロフロントエンド）。

オブジェクト指向プログラミングとの違い オブジェクト指向プログラミング (OOP) の考え方では、ソフトウェアはオブジェクトのモデルに従って書かれる。OOP やオブジェクト指向分析設計は実世界の相互作用のモデル化に注目し、そこからエンドユーザーやプログラマが直感的に利用可能なある種の「動詞」と「名詞」を抽出する。

一方、ソフトウェアコンポーネントでは必ずしもそのような前提はなく、事前に製作されたコンポーネント群を組み合わせて、電気製品や機械製品を作るようにソフトウェアを作れることを強調する。実際、有用なコンポーネントの定義はオブジェクトほど直感的ではない。コンポーネントはオブジェクトのように擬人化されることはなく、エンドユーザーによるプログラミングにも悲観的な立場と言える。ソフトウェアコンポーネントに基づいた新たなプログラミングパラダイム、コンポーネント指向プログラミングを提唱する人もいる。

この両者の区別は初期の計算機科学者らにその起源があるとする人もいる。すなわち、ドナルド・クヌースは文芸的プログラミングとして直観と形式モデルの融合を提唱した。一方、エドガー・ダイクストラは論文 The Cruelty of Really Teaching Computer Science でプログラミングは数学の一分野でしかないと主張した。

両者の考え方は学界での論争を呼び、2つの手法の利点と欠点が議論され、両者の融合を可能にする戦略が話し合われた。彼らの立場が本当に対立するものだったかについては異論もある。

アーキテクチャ 複数のソフトウェアコンポーネントを実行するコンピューターをアプリケーションサーバと呼ぶ。このようなアプリケーションサーバとソフトウェアコンポーネントの組み合わせは典型的な分散コンピューティングの一種であり、金融アプリケーションやビジネスソフトウェアで使われている。

モデル コンポーネントモデルは、コンポーネントの実装・ドキュメンテーション・配備についての標準を定義したものである。例えば、EJBモデル (Java)、COM+モデル (.NET)、CORBAコンポーネントモデルなどがある。コンポーネントモデルは、インタフェースの定義の仕方やインタフェース定義に含まれるべき要素などを指定している。

技術 ビジネスオブジェクト技術 Newi 特定領域向けのコンポーネントベースのソフトウェアフレームワーク Earth System Modeling Framework (ESMF) コンポーネント指向プログラミング OSGi Service Platform で定義されたバンドル Component - js、ccs などのためのウェブプラットフォーム Common Component Architecture (CCA) Eiffel言語 Enterprise JavaBeans: サン・マイクロシステムズ Oberon言語や Component Pascal と BlackBox Component Builder .NET における System.ComponentModel名前空間 Unity3D UNO: OpenOffice.orgオフィススイート Visual Component Library (VCL)、Component Library for Cross Platform (CLX): ボーランド Lazarus Component Library (LCL): VCLをモデルに開発されたLazarus向けのオープンソースライブラリ Visual Basic Extension、OCX/ActiveX/COM、DCOM: マイクロソフト XPCOM: Mozilla Foundation TECS: TOPPERSプロジェクト 複合文書技術 Oberonにおける Active Documents Bonobo （GNOMEの一部） KParts（KDE） Object Linking and Embedding (OLE) OpenDoc Fresco 分散コンピューティングのソフトウェアコンポーネント .NET Remoting: マイクロソフト Windows Communication Foundation (WCF): マイクロソフト 9P: Plan 9で開発された分散プロトコル。Infernoなどで使用されている。 CORBA: Object Management Group D-BUS: freedesktop.org DCOP (KDE) DCOMおよび後期のCOM、COM+: マイクロソフト DSOMとSOM: IBM（既に使われていない） Jakarta EE: Eclipse Foundation Universal Network Objects (UNO): OpenOffice.org Webサービス Representational State Transfer (REST) Zope: Zope Corporation ジェネリックプログラミングでは、アルゴリズムとデータ表現の分離を強調する。 インタフェース記述言語 (IDL) Open Service Interface Definitions (OSIDs) COMやCORBAの一部 SOAP IDL: W3C WDDX XML-RPC、SOAPの前身 制御の反転 (IoC) と Plain Old C++/Java Object (POCO/POJO) コンポーネントのフレームワーク パイプとフィルター UNIX オペレーティングシステム

参考文献 Brad J. Cox, Andrew J. Novobilski (1991). Object-Oriented Programming: An Evolutionary Approach. 2nd ed. Addison-Wesley, Reading ISBN 0-201-54834-8 Bertrand Meyer (1997). Object-Oriented Software Construction. 2nd ed. Prentice Hall. George T. Heineman, William T. Councill (2001). Component-Based Software Engineering: Putting the Pieces Together. Addison-Wesley Professional, Reading 2001 ISBN 0-201-70485-4 Richard Veryard (2001). Component-based business : plug and play. London : Springer. ISBN 1-85233-361-8 Clemens Szyperski (2002). Component Software: Beyond Object-Oriented Programming. 2nd ed. Addison-Wesley Professional, Boston ISBN 0-201-74572-0 David Polberger (2009). Component technology in an embedded system. Master's thesis in computer science, available online. ISSN 1651-6389

脚注

関連項目 ビジネスロジック モジュール ソフトウェアエンジン Webサービス

外部リンク Mass Produced Software Components by M. Douglas McIlroy NATO Science Committee Software Engineering Conference in Garmisch - reports (PDF) Planning the Software Industrial Revolution 製造業とソフトウェアの歴史比較 The independence of notion of component-orientation. Cox's feasibility demonstration Component Systems 包括的リスト "Why Software Reuse has Failed and How to Make It Work for You" by Douglas C. Schmidt VirCA - Virtual Collaboration Arena framework, a component based, Future Internet collaboration platform powered by RT-Middleware