Search

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

ソフトウェアシステムの様々な機能を関心の分離によって分割したもの

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

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

コンポーネントの考え方は、サービス指向の起点となっている。例えば、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

脚注

関連項目

外部リンク

「https:https://www.search.com.vn/wiki/index.php?lang=ja&q=ソフトウェアコンポーネント&oldid=92570681」から取得
🔥 Top keywords: メインページ宮崎麗果特別:検索豊後水道松本忠久土居志央梨若葉竜也能登半島地震 (2024年)田中雄士長谷部誠井上道義The GazettE若林志穂服部百音黒木啓司REITA虎に翼平井理央出口夏希サーブ (盲導犬)三鷹事件セウォル号沈没事故白眞勲三淵嘉子高橋克也 (オウム真理教)ME:Iルーシー・ブラックマン事件佐藤ありさ杉咲花蜜谷浩弥水野真紀亀井亜紀子 (政治家)熊本地震 (2016年)水原一平井川意高中川安奈 (アナウンサー)内藤剛志いなば食品YOSHIKI