ソフトウェアコンポーネント

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

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

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

狭義ではEJBなどインタフェースが標準化されたもののみを示し、広義では関数化、クラス化などソースコードレベルで再利用出来る物などを示す。

概要

個々のソフトウェアコンポーネントは、ソフトウェアパッケージだったり、Webサービスだったり、ウェブリソースだったり、相互に関連する機能（とデータ）の集合をカプセル化したモジュールだったりする。

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

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

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

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

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

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

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

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

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

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

歴史

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

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

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

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

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

例

UI

UIは機能ごとの小さなUIに分割できる。このUIコンポーネントは状態 (state)・処理 (logic)・見た目 (view) を1箇所に集約しカプセル化している[6]。カプセル化のおかげで外部（例: DOM）に依存せずそれ単体で機能できる（自己完結している）[7][8]。これらの再利用可能なUIコンポーネントを集めそれらの相互作用を定義することで、UI全体を構成することができる[9][10]（c.f. マイクロフロントエンド）。

オブジェクト指向プログラミングとの違い

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

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

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

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

アーキテクチャ

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

モデル

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

技術

参考文献

  • 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

脚注

  1. ^ McIlroy, Malcolm Douglas (January 1969). “Mass produced software components”. Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7-11 Oct. 1968. Scientific Affairs Division, NATO. p. 79. 2013年4月5日閲覧。
  2. ^ Rainer Niekamp. “Software Component Architecture”. Gestión de Congresos - CIMNE/Institute for Scientific Computing, TU Braunschweig. p. 4. 2011年7月29日閲覧。 “The modern concept of a software component largely defined by Brad Cox of Stepstone, => Objective-C programming language”
  3. ^ Raphael Gfeller (December 9, 2008). “Upgrading of component-based application”. HSR - Hochschule für Technik Rapperswill. p. 4. 2011年7月29日閲覧。 “1990, IBM invents their System Object Model. 1990, as a reaction, Microsoft released OLE 1.0 OLE custom controls (OCX)”
  4. ^ Foukalas et al "Protocol Reconfiguration Using Component-Based Design"
  5. ^ Wallace, Bruce (May 19, 2010). “A hole for every component, and every component in its hole”. Existential Programming. 2013年4月5日閲覧。 “There is no such thing as a Component”
  6. ^ 「コンポーネントベース 自分自身の状態を管理するカプセル化されたコンポーネントをまず作成し」 React 2021-03-02閲覧
  7. ^ 「コンポーネント...は...DOM に状態を持たせないようにすることができます。」React 2021-03-02閲覧
  8. ^ 「小さく、自己完結的で、（多くの場合）再利用可能なコンポーネント」Vue.js - コンポーネントによる構成
  9. ^ 「コンポーネントベース ... これらを組み合わせることで複雑なユーザインターフェイスを構築します。」 React 2021-03-02閲覧
  10. ^ 「ほぼすべてのタイプのアプリケーションインターフェイスは、コンポーネントツリーとして抽象化できます。」Vue.js - コンポーネントによる構成
  11. ^ Donald E. Knuth (September 1983). “Literate Programming”. Literate Programming/The Computer Journal. p. 15. 2011年7月29日閲覧。 “Thus, WEB may be only for the subset of computer scientists who like to write and to explain what they are doing. My hope is that the ability to make explanations more natural will cause more programmers to discover the joys of literate programming, because I believe it’s quite a pleasure to combine verbal and mathematical skills; but perhaps I’m hoping for too much. The fact that at least one paper has been written that is a syntactically correct ALGOL 68 program22 encourages me to persevere in my hopes for the future. Perhaps we will even one day find Pulitzer prizes awarded to computer programs.”
  12. ^ “Dijkstra, Wybe Edsger”. Encyclopedia.com (2011年7月29日). 2013年4月5日閲覧。 “In his view, the key to a good computing science program was to consider it as a branch of mathematics.”

関連項目

外部リンク

Strategi Solo vs Squad di Free Fire: Cara Menang Mudah!