2.4　SDPの目指すものに関連した技術、システムの動向

2.4　SDPの目指すものに関連した技術、システムの動向

　SDPの将来の方向性として、前述のように、モデリング、形式的枠組み、オープンな開発環境、既存資産の活用を提言し、キーワードを並べているが、まだ、具体的なイメージがつかめない読者も多いことであろう。SDPに参加したメンバも将来構想であるから、具体的イメージを持っているわけでもなく、各メンバの将来イメージもそれぞれ異なっているので無理からぬ話である。しかし、参加メンバは、予算獲得の思惑があり、各メンバが現在研究していること、あるいは関心があることの延長線上に将来イメージがあるであろう。そこで、SDPが目指す方向に関する、以下に述べる現在の研究動向を把握し、それから、その延長線上の将来イメージがどんなものであるかを把握してもらいたい。

2.4.1　モデリング、特定領域記述言語(DSL: Domain Specific Language)

　IT革命が進行し、ITと他分野との融合が加速していけば、融合分野の専門知識が希薄なITプログラマは対応が難しくなってくる。従って、ITプログラマがプログラミングするのではなく、各特定領域の専門家がプログラムできるものでなくてはならない。特定領域には、多くの場合、建築設計図、電気回路図、損益対照表といった特定領域固有のモデリングドキュメントが既に存在する。このようなモデリングドキュメントをベースにITシステムを記述しようとするアプローチが特定領域記述言語である。
これは、従来、プログラミングとは、インプリメントすることを設計してきたが、モデリングを設計することによって行おうとするアプローチであり、このモデリングが特定領域固有のモデリングドキュメントに他ならないのである。しかし、ただ単にモデリングドキュメントで終わらずに、実行できるものではなくてはならない。従って、モデリングドキュメントを「軽い形式的枠組み」にしたり、「メタモデリング言語」でモデリングドキュメントの意味を規定したりして、あるいは、暗黙的な知識を使ってシステムが自動的に、実行コードの生成をサポートにする。
　特定領域記述言語の代表的なのは、スプレッドシートで表に関する処理はほぼ何でもこなすことができる。表以外で注目されるシステムに、Simulink、Ptolemy、OMGで検討が始まったMDA、Webサービスをベースにビジネスフローを記述するBPEL4WSがある。

2.4.1.1　Simulink

　Simulink[4]は、MathWorks社の製品で、DSPの設計、コミュニケーションシステムの設計、その他シミュレーションシステム向けのダイアグラムブロックの開発ツールである。その特徴は、150以上のブロックを含むライブラリやモデル（出来合いブロックダイアグラム）が準備されており、これらを組み合わせてブロックダイアグラムを作成、編集できる。

図1　Simulink FFTの例

　図1（http://www.mathworks.com/products/simulink/description1.jsp）は、短時間の高速フーリエ変換ブロック（FFT）の例であり、これはDSPブロックを用いて作成されている。FFTブロックに対するパラメタは右のダイアログボックスで入力される。ユーザがサブシステムの詳細を見たければ、右下に示すその詳細ブロックダイアグラムを表示することができる。
　Simulinkでは、ユーザ作成のカスタムブロックをシステムに組み込む、あるいはC言語などのコードをブロックダイアグラムに組み込むことによって、システムを拡張することができる。また、作成したブロックダイアグラムを、インタラクティブに実行することができ、結果を即座に表示したり、グラフィカルデバッガでデバッグしたりすることができる。

2.4.1.2　Ptolemy

　Ptolemy[5]は、カルフォルニア大バークレー校のプロジェクトであり、組み込みシステムのような複雑なシステムのモデリングと設計を支援するシステムの構築を目指している。
　その狙いは、以下の実現にある。

�@ 組み込みシステムの開発におけるモデリング、設計の方法論の確立
�A 適切なコンピュテーションモデルの選択によるシステム設計品質の向上
�B 多数のコンピュテーションモデルを実行するモデルの生成と相互運用
�C コンポーネントベースの設計

　Ptolemyプロジェクトでは、ビジュアルエディタであるVergilを用いてモデリング、設計を行う。このVergilの特徴は、単一のコンピュテーションモデルではなく、複数のコンピュテーションモデルの中から選択できることである。Vergilでは、継承構造、手続きインターフェースを主体とするオブジェクト指向ベースのモデリングではなく、並列性やコミュニケーションモデルを主体としたアクタベースとした、以下に示す９つのコンピュテーションモデルが用意されている。

Communicating Sequential Processes - CSP
Continuous Time - CT
Discrete-Events - DE
Distributed Discrete Events - DDE
Discrete Time - DT
Finite-State Machines - FSM
Process Networks - PN
Synchronous Dataflow ? SDF
Synchronous/Reactive - SR

　２つ目の特徴は、上記のモデルがグラフィカルに表現されることである。図2（http://ptolemy.eecs.berkeley.edu/publications/papers/01/overview/overview.pdf）は、Discrete Eventモデルの例で、バス停に乗客がポアソン過程で到着し、バスが一定間隔で到着したときと、ポアソン過程でランダムに到着したときのシミュレーションの比較を示す。
　図3（http://ptolemy.eecs.berkeley.edu/publications/papers/01/overview/overview.pdf）は、Finite-State Machineの例を示す。
　３つ目の特徴は、上記のグラフィカルなモデルは、コンピュテーションモデルに基づいてため、意味の形式化がなされ、実行可能で、モデルが意図するものであれば、信頼性のおけるプログラムとなる。

図2　Vergilのバス停における待ち行列のシミュレーション例

図3　Vergilの状態遷移図の例

2.4.1.3　UML,MDA

　UML(Unified Modeling Language)は、オブジェクト指向に基づく開発方法論で使われるドキュメント(図)を統一したものであって、以下の９種類の図を規定している。
　ユースケース図………システム要件となる機能を表す図
　クラス図………………クラスの階層構造、振る舞いを表す図
　オブジェクト図………個々のオブジェクトの振る舞いを表す図
　シーケンス図…………オブジェクト間の協調動作（メッセージングの順序）を表す図
　コラボレーション図…オブジェクト間の協調動作（メッセージングとコンテキスト）を表す図
　状態遷移図……………オブジェクトの状態の変化の様子を表す図
　アクティビティ図……操作の中で実行されるアクティビティの流れを表す図
　配置図…………………システムのハードウェアとソフトウェアの物理的なアーキテクチャを表す図
　コンポーネント図……コードのコンポーネントの物理構造を表す図
　しかし、このようなUMLには大きな二つ課題を抱えている。一つ目はUMLの図は、モデリング言語ではあるが、オブジェクト指向言語によるインプリメントを前提としたものであって、ITシステム設計者、プログラマ向けのものである。業務で使うモデリングではなく、業務の専門家が使えるものではない。二つ目は、実行コードの生成までを可能とする情報は含んでいないため、設計からインプリメント、テストへとシームレスな開発が行えず、また、ツールを使えば、或る程度は補えるが、実行コードとUMLとの不一致が生じたりする。
　この課題を解決する動きが、MDA(Model Driven Architecture)[6]、UML2である。
MDAはOMG(Object management Group)が提案しているものであり、業務に視点を置いたモデリング(PIM: Platform Independent Model)とインプリメントに視点を置いたモデリング(PSM: Platform Specific Model)とに分けてモデリングを行い、この二つのモデリングをマッピングルールで関係付けを行おうとするものである。
　PIMの一つとして、企業でのビジネスプロセスを対象としたエンタープライズ分散オブジェクトコンピューティング(EDOC: Enterprise Distributed Object Computing)向けにUMLに対して、ビジネスプロセス、イベントドリブン、コンポーネント、パターンなど様々な拡張が検討されている。PSMも分散オブジュクトをサポートするCORBA、EJB、NET、XMLが検討されている。図4（http://cgi.omg.org/docs/ptc/02-02-05.pdf）にEDOCのCCA(Component Collaboration Architecture)による販売の例を示す。

図4　EDOCのCCA(Component Collaboration Architecture)による販売の例

2.4.1.4　BPEL４WS

　BPEL4WS(Business Process Execution Language for Web Services)[7]は、ウェブサービスをベースとしたワークフローによるビジネスプロセスの振る舞いを記述するXMLベースのドキュメントであり、IBM、Microsoft、BEAが共同で提案しているものである。BPEL4WSは、XLANGとWSFLの概念を融合しており、それらに取って代わるものである。BPEL4WSは、ビジネスプロセスの二つの側面、ビジネス活動における参加者の振る舞いのモデルを進行させる実行プロセスと各業者間のメッセージ交換の振る舞いを記述するビジネスプロトコルとを記述する。
　BPEL4WSでは、ルートのProcess要素の下位要素として、Partners要素、Conntainers要素、CorrelationSets要素、FaltHandlers要素、CompensationHandler要素、及びアクティビティを記述する。
　Partners要素では、ビジネスプロセスの過程で登場する各業者について、Partner要素でサービスリンクタイプと役割を記述する。Containers要素では、ビジネスプロセスで使われる各データ内容について、Container要素で記述する。CorrelationSets要素では、各相互関係について、CorrelationSet要素で記述する。エラー処理については、FaltHandlers要素、CompensationHandler要素で記述する。
　アクティビティは、ビジネスプロセスの活動内容を以下の要素で記述する。

・ Receive要素　メッセージの受け取り
・ Reply要素　メッセージに対する返答
・ Invoke要素　パートナーのPortTypeで提供されるサービスの起動
・ Assign要素　新しいデータでContainerの内容の変更
・ Throw要素　例外処理の生成
・ Terminate要素　ビジネスプロセスの終了
・ Wait要素　或る時間待つ
・ Empty要素　無操作
・ Sequence要素　順次に各操作を行う
・ Switch要素　分岐操作を行う
・ While要素　繰り返し操作を行う
・ Pick要素　メッセージの受け取りまたはタイムアウトでアクティビティを実行
・ Flow要素　並列操作を行う
・ Scope要素　エラー処理の範囲を定義
・ Compensate要素　補償処理の呼び出し

2.4.2　多面的ソフトウェア

2.4.2.1　アスペクト指向

　オブジェクト指向は、システムを「もの」、すなわちオブジェクトという側面から分割し、対象システム中の「もの」をモデル化し、その性質（手続きとデータ）を記述する。しかし、対象モデルの性質は、一つの側面ではなく、いくつかの側面を含んでいる場合が多い。このことに着目し、「もの」という側面からではなく、他の側面からもシステムを分割しようとするのがアスペクト指向[8]である。先ず、オブジェクトの側面からシステムを分割し、分割したオブジェクトを横断するような関心事があれば（複数のクラスに同じ関心事があれば）、その関心事に対する機能を一まとめにして分割の単位とする。このように、アスペクト指向とオブジェクト指向とを組み合わせてシステムを構築する。
　オブジェクトに跨る関心事には、すべてのオブジェクトに共通な関心事の例として、セキュリティチェック、課金、トレース、ロギング等があり、幾つかのクラス間の取り決めの例として、Observer―Subjectのようなデザイン・パターンに見られるクラス、図形描画における図形要素と画面の再描画の関係といった構成要素と全体の管理の処理、クラス間の役割を明確化するメソッド呼び出しにおけるプレコンディション・ポストコンディション等がある。また、システム統合を行う場合にもアスペクト指向は有効である。例えば、販売管理システムと配送システムとを統合する場合には、商品の重量、大きさ、配送スケジュール等といった配送の側面から機能を一まとめとにして、販売管理システムに後付けで（販売管理システムに大きな変更を加えずに）追加することもできる。
　このようなアスペクト指向をサポートするシステムには、Hyper/J、Aspect/J等がある。Aspect/Jを用いた図形描画における図形要素と画面の再描画の例で、具体的にどのようにコーディングするかを図5に示す。

図5　Aspect/Jによる図形要素と画面の再描画の例

　図5の左に示したのが、オブジェクト指向による図形描画のクラスの階層構造である。ここで、図形要素のPoint、Lineが変更されたときには、必ず画面の再描画をしなければならないが、その処理は、各図形要素すべてで記述しなければならなく、モジュラリティがよくない。アスペクト指向では、その部分を別モジュールaspect DisplayUpdatingで記述する。そこでは、pointcut文でPoint、Lineが変更されたという関心事moveを（call(FigureElement.mobeBy||Point.setX||Point.setY||Line.setP1||Line.setP2)）で指定し、そのときのオブジェクトをfeと指定する。そして、関心事moveが呼び出された後処理として行うべき処理（画面の再描画）をafter文で指定している。

2.4.3　科学、工学的な設計

　現在のソフトウェアが抱える低い信頼性、生産性、相互運用性、柔軟性は、技術的な脆弱性に起因している。それを解決するには、ソフトウェアは、科学的原理、方法、経験に基づいて設計すべきであり、このような科学、工学的な設計によって、実行コードを自動生成したり、事前にエラー、矛盾性をチェックしたり、テストを自動化したりしようとする試みである。このような試みに、軽い形式的枠組み、Semantic Webがある。

2.4.3.1　軽い形式的枠組み

　軽い形式的枠組みとは何かを説明する前に、先ず、形式的枠組み、擬似形式的枠組み、及び、非形式的枠組みについて説明しよう。
　形式的枠組みは、Hoareのロジックやリレーショナルデータベースの計算のように、数学的理論で裏づけされた概念で記述しようとする枠組みである。これは、類似、プリ／ポストコンデション、信頼／保証、連続性といった強力な概念の宝庫ではあるが、多くのアプリケーションにおいて、実用的ではない。
　一方、非形式的枠組みは、デザイン・パターン、エクトリーム・プログラミングがその例で、優秀なプログラマ、マネジャーの経験を発掘して、その経験を実践しようとするもので、非常に効果的な方法である。しかし、人の経験的能力に依存しており、経験的能力を身に付けるまでの時間、教育コストが課題である。
　また、擬似形式的枠組みは、UMLがその代表例であり、意外に有効ではあるが、その有効性は、ソフトウェア設計を形式化、標準化することによって得られるものであり、次善の策と言えよう。
　軽い形式的枠組み[9]は、型付けシステム、モデルチェッキング、ランタイムモニタリングといった実用的で強力な概念を採り入れる試みである。これらの概念を拡張してより強力にしたり、新たなこのような概念を見つけていけば、現在のソフトウェアが抱える問題を飛躍的に解決する可能性がある方法である。
　例えば、型付けシステムは、コンポーネントとその動作環境との間の約束事を決めて置き、コンパイル時に、その約束事に従っているかを自動的にチェックするものであるが、実行時に動作環境が動的に変わるような場合においても、この型づけの概念、機構を適用されるようにすれば、証明付きコードを実現できる。また、モデルチェッキングは、ハードウェア設計において、流れを示すのに非常に有効であるが、これをソフトウェアに対しても適用できるようにする。ランタイムモデリングは、不正なふるまいを事前に推測するといった労力のいる仕事をしなくても、実行時に実際に不正な振る舞いをするコンポーネントを容易に検出できるようにする。

2.4.3.2　メタデータ、Semantic Web

　メタデータ、Semantic Web[10]は、W3Cなどの団体が中心となって、その標準化、推進活動を行っている。メタデータは、データについてのデータであり、データを或る目的のために扱いやすくするデータのことである。例えば、以下のようなデータがある。

・データを構造化したデータ
・データリソースについてのデータ
・カタログデータ
・データを共通認識させる意味データ

　Semantic Webは、データについての意味情報であり、W3Cのディレクターであるティム・バーナーズ・リーらによって提唱された。その考え方は、サイエンティフィック・アメリカン誌で、以下のように紹介され、計算機が情報の意味を理解できるようにし、各意味情報を用いて、自動的な処理、知的な推論処理を行うことによって、人々が知識共有をグローバルに効率よく効果的に行うことを目指している。
　「The Semantic Web is an extension of the current web in which information is given well-defined meaning, better enabling computers and people to work in cooperation．」
　Semantic Webは、メタデータの拡張として記述される。
　図6に示すように、Semantic Webは、XML Schema、RDF、RDF Schema、DAML+OILなどのメタデータの記述を階層的に定義することよって記述される。

図6　Semantic Webのアーキテクチャ

　Semantic Webプロジェクトの特徴は、セマンテックスの標準化に向けて、非集中型のアプローチを採用していることである。データに対し意味を付与し、計算機が理解可能とするには、XMLのタグ、プロパティの用語を標準化し、その意味付けを明確化するメタデータの定義が必要となるが、そのメタデータの標準化にあたっては、一つに統一するのではなく、複数の標準が存在することを許容している。それぞれの目的のために、数多くのメタデータが定義され、標準化されてくると、それらの複数のメタデータには、同義語、同音異義語などが生じ、用語の相違が生まれる。このような場合には、同義語辞書（オントロジー）を作ることによって、その用語の相違を解消していこうとしている。この同義語辞書もメタデータで、図6のOntology vocabularyレイヤで定義される。同義語辞書を作成してもセマンティクスギャップ（用語の相違）は完全には解消されないが、現実的なアプローチであると言える。データベースがデータの整合性、一貫性を死守するあまり、分散化、共有化が進まなかったのに対し、Webが、データの整合性、一貫性を放棄して分散化を進め、ボトムアップの草の根型の発展を遂げ、Webをグローバルな巨大なデータベース化するのに成功したように、セマンティクスギャップを許容することによって、ボトムアップの草の根型に意味、知識が蓄積されて、巨大な知識ベースが構築されることを目論んでいる。　次に、図6に示したSemantic Webアーキテクチャの各レイヤの内容を以下に示す。なお、Logic、Proof、Trustレイヤは、構想段階では何も決まっていないので、省略する。

(1)　XML Schema

　XML Schema[11]は、XMLドキュメントの以下に示すクラス情報を記述する。

• 構造情報：どのようなエレメント、属性から構成されているか
• データタイプ：そのエレメント、属性がどのようなデータタイプであるか
  < xsd:element name=“Price” type=xsd:decimal>
• データの基本情報：エレメントの頻出回数の制約などの情報
  < element name=“item” minOccurs=“1” maxOccurs=”unbounded”>

　これには、意味情報はなく、DTDと同様の機能を提供するが、DTDはXMLでないのに対し、XML SchemaはXMLであるので、XMLで使われているツールがXML Schemaに対しても使えるメリットがある。

(2)　RDF(Resource Description Framework)

　RDF[12]は、メタデータを表すための枠組みであり、計算機が理解可能とするための情報記述を与える。RDFでは、リソースとプロパティと値の三つ組で構造を表す極めてシンプルな構造化モデルを採用している。
　例えば、リソース：http:// www.w3.org/Home/Lassila のプロパティ：著者の値：Ora Lassilaは、次のように表される。

< rdf:Description about=”http://www.w3.org/Home/Lassila”>
<Name>Ora Lassila</Name>
< /rdf:Description>

　値は、リソースを指してよいので、ネットワークとして定義していくことができる。
「http:// www.w3.org/Home/Lassila（リソース）の著者（プロパティ）は、個人http://www.w3.org/staffId/85740（リソース）であり、その個人の名前（プロパティ）は Lassila（値）、Emailアドレス（値）はlassila@w3.orgである。」は、次のように記述される。

< rdf:RDF>
　<rdf:Description about="http://www.w3.org/Home/Lassila">
　　<Creator>
　　　<rdf:Description about="http://www.w3.org/staffId/85740">
　　　　<Name>Ora Lassila</Name>
　　　　<Email>lassila@w3.org</Email>
　　　</rdf:Description>
　　</Creator>
　</rdf:Description>
< /rdf:RDF>

　また、構造を表すモデルとしてコンテナモデルを採用し、<Bag>, <Sequence>, <Alternative>が用いられる。

(3)　RDF Schema

　RDF Schema[13]は、RDFの以下のようなデータタイプを記述する。

• クラス、及び他のクラスとの関係を定義
  オブジェクト指向風に<Class>, <subClassOf>が用いられる。
• プロパティ､及び他のプロパティとの関係を定義
  < subPropertyOf>で他のプロパティの定義を継承することを示す。
• プロパティの値の範囲、属するクラスなどプロパティの制約を定義
  < range>でプロパティの値の範囲を、<domain>でプロパティが属するクラスを指定する。
• 意味（ラベルとコメント）を定義
  < label>でラベルを、<comment>でコメントを指定する。

(4)　メタデータの例―Dublin Core

　以上のRDF､RDF Schemaを用いてメタデータが定義され、各業界、団体で標準化作業が行われている。その主なものには、以下のものがある。

・Dublin Core；書誌情報の基本語彙集
・P3P：プライバシに関するメタデータ
・RSS：サイト情報の要約と公開
・WSDL：リモートプロシジャコール（SOAP）のメタ情報

　Dublin Core[14]は、Webや文書の作者、タイトルなどの書誌情報の基本語彙集である。
　次の15の基本エレメントタイプが決められている。

Title　Creator　Subject　Description　Publisher　Contributor　Date　Type　
Format　Identifier　Source　Language　Relation　Coverage　Right

　さらに基本エレメントタイプよりもっと厳密なメタデータ記述を行うために、以下のような修飾子が規定されている。

Title.alternative
Description.tableOfContents　Description.abstract
Date.created　Date.Valid　Date.available　Date.issued　Date.modified
Format.extent Format.medium
Relation.isVersionOf　Relation.hasVersion　Relation.isReplaceBy　Relation.replace
Relation.isRequiredBy　Relation.requires　Relation.isPartOf　Relation.references
Relation.isFormatOf　Relation.hasFormat
Coverage.special　Coverage.temporal

(5)　DAML+OIL　Ontology

　DAML+OIL　Ontology[16][17]は、RDF Schemaに加えて、より詳細なクラス、プロパティの定義、制約、表記を記述する.
これらの記述のために以下のタグが規定されている。

cardinality cardinalityQ Class complementOf Datatype DatatypeProperty
DatatypeRestriction Datatype value differentIndividualFrom disjointUnionOf
disjointWith domain equivalentTo hasClass hasClassQ hasValue imports
intersectionOf inverseOf maxCardinality maxCardinalityQ minCardinality
minCardinalityQ ObjectClass ObjectProperty ObjectRestriction oneOf
onProperty Ontology Property range Restriction sameClassAs
sameIndividualAs samePropertyAs subClassOf subPropertyOf toClass
TransitiveProperty UnambigousProperty unionOf UniqueProperty versionInfo

2.4.4　オープンな協調開発環境

2.4.4.1　オープンソースソフトプロセス

　Linuxは、オープンソースソフトプロセス（OSSP）[18]の成果である。OSSPを採用したが故に、Linuxは、安定性・スケーラビリティ・カスタマイズ性・性能の向上、開発・バグ修正の素早さ、低コストをもたらし、マイクロソフトを脅かす存在となっている。OSSPは、単にソースを公開した方式にとどまらず、インターネットを最大限に活用した開発方式であり、市場原理に基づく開発方式とは異なるハッカー社会の贈与文化に基づく開発方式である。

[OSSPによるソフトウェア開発の特徴]

　OSSPによるソフトウェア開発方法の特徴を以下に示す。
�@　OSSPの開発組織

・ 地域的な広がり
　国際化、標準化に優位性を持つ。
・ 万人が認めるリーダの存在
　LinuxではLinus Torvaldsの存在
・ 巨大な数の貢献者集団
　Linuxではコード提供者200人以上、バグ修正者1000人以上
・ 金銭的動機ではなく、余暇に開発に貢献する個人集団
　（ただし、商業版Linuxが登場して変わりつつある）

�A　SPが成功する開発運営方法

・ インターネットの共働技術を駆使
メーリングリスト、ニュースグループ、Web
・ 共通の目標
　「UNIXを作り直せ」＝＞方向性を明確にし、開発チーム全員の意思決定
　（「すばらしいOSを作ろう」といったあいまいな目標はダメ）
　UNIXの経験＝＞何がうまくいって、何がうまくいかないかが分かる。
・ 共通の経験、スキル
　UNIX/gnu＝＞参入障壁を低くし、参加できる開発者を増やす。
・ 並列競合開発とコンポーネント化の枠組み
　コンポーネントの枠組みを確立し、複数の小チーム、個人が個別に開発。
　競合した場合は、最もいい実装を選択。
・ 並列デバッグ
　誰かが問題を見つけ、たいてい別の人がその問題を理解してそれを直す。
　デバッグは、プロジェクトに参加する人の数に正比例して効率が上がる。
　これが、ブルックスの法則（開発者の人数を増やしても、管理、調整作業が増大して効率が比例して上がらない）から逃れる鍵
・ 紛争解決
　Linuxでは、「やさしい独裁者」モデル
　Linus Torvaldsがプロジェクトのリーダ。
　大きなコンポーネントを信頼できる副官に移譲。
　副官は、サブコンポーネント開発者に移譲。
　Apacheは、共同開発者による議決委員会方式。
・ 動機づけ
　開発者の個人的な悩みを解決
　自分のエゴの満足とハッカー社会での評判
　ハッカーの社会は、贈与文化。
　ものが豊富な社会（ソフトが自由に共有される社会）では、競争的な成功の尺度は仲間内の評判
　ノウアスフィアの開墾
　未開の土地を開拓し、自分のものにすること
　弱者の反発（反マイクロソフト）
・コードの分裂の回避
　万人が認めるリーダの存在：Linus Torvalds
　GPLライセンス（派生したものはフリーにしなければならない）
　ハッカー社会での評判が低下する恐れ

[OSSP開発を効率化する法則]

　Linix上のfetchmailを開発したレイモンドは、そのOSSPを実践した経験から、OSSP開発を効率化する法則を「伽藍とバザール」[19]に書いている。その法則を以下に列挙する。

�@よいソフトはすべて、開発者の個人的な悩み解決から始まる。
�A何を書けばいいかわかっているのがよいプログラマ。なにを書き直せば（そして使い回せば）いいかわかっているのが、すごいプログラマ。
�B捨てることをあらかじめ予定しておけ。どうせいやでも捨てることになるのだから（フレッド・ブルックス『人月の神話』第11章）
�Cまともな行動をとっていれば、おもしろい問題のほうからこっちを見つけだしてくれる。
�Dあるソフトに興味をなくしたら、最後の仕事としてそれを有能な後継者に引き渡すこと。
�Eユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグの一番楽ちんな方法。
�F早目のリリース、頻繁なリリース。そして顧客の話を聞くこと。
�Gベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず。
�H賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
�Iベータテスタをすごく大事な資源であるかのように扱えば、向こうも実際に大事な資源となることで報いてくれる。
�Jいいアイデアを思いつく次善の策は、ユーザからのいいアイデアを認識することである。時にはどっちが次善かわからなかったりする。
�Kもっとも衝撃的で革新的な解決策が、自分の問題のとらえかたがそもそも間違っていたという認識からくるということはよくある。
�L「完成」（デザイン上の）とは、付け加えるものが何もなくなったときではなく、むしろなにも取り去るものがなくなったとき。
�Mツールはすべて期待通りの役にたたなきゃダメだが、すごいツールはまったく予想もしなかったような役にもたってしまう。
�Nゲートウェイソフトを書くときはいかなる場合でも、データストリームへの干渉は最低限におさえるように必死で努力すること。そして受け手がわがどうしてもと言わない限り、絶対に情報を捨てないこと！
�O自分の言語がチューリング的完成からほど遠い場合には、構文上の甘さを許すといろいろ楽になるかもね。
�Pセキュリティシステムのセキュリティは、そこで使われている秘密の安全性にかかっている。見かけだけの秘密は要注意。
�Qおもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう。
�R開発コーディネーターが、最低でもインターネットくらい使えるメディアを持っていて、圧力なしに先導するやりかたを知っている場合には、頭数は一つよりは多いほうが絶対にいい。

[OPPSの強み]

　指数関数的性質

• OSSPはインターネットと共に成長
• OSSPでは「勝者がすべてをかっさらう」
• 開発者は最大のOSSPプラットフォームに貢献したがる。
• 大規模なOSSPプロジェクトのほうがもっとたくさんの「目先の問題」を解決する。

　長期的な信用

• バイナリは死に絶えるがソースコードは永遠なり。
• コード分裂の不在が長期的信用につながる。

　並列デバッグ
　並列開発
　完璧なAPIとドキュメンテーション
　頻繁なリリース

[OSSPの弱み]

　OSSPプロジェクトを始めるのは難しい。

　OSSPを信用させ、開発に貢献するには以下のことが基準を満たさないといけない。
　　大きな将来のノウアスフィア
　　大きな悩みを解決する
　　まずは問題のそこそこの部分を解決せよ
飽和点に達した後の開発
　飽和点に達すると、OSSPが成功する要件である「共通の目標・スキル」、および「大きなノウアスフィア」が薄れてくる。これをどう克服するか。
非専門家からのフィードバック
　OSSPは、「開発者の個人的な悩みを解決」が動機付け
　技術水準の高いユーザ向けシステムになりがち

2.4.4.2　エクストリーム・プログラミング(XP)

　エクストリーム・プログラミング[20]とは、Kent Beckらによって提唱されているソフトウェア開発方法であり、略してXP(eXtreme Programming)と呼ばれている。
　XPは、コミュニケーション、シンプルさ、フィードバック、勇気に価値を置く開発手法である。その特徴は、変化を容認（Embrace Change）するとの思想に立ち、その変化に対応できように、初期設計はシンプルに行い、リファクタリングによる再設計を重視し、また、変更コストが時間とともに増大しないように、テストを自動化するなどプログラミング、テストを重視している。また、チームに責任と権限が与えられ、メンバがプロセスを最適化していくセルフオーガナイズされたチームを目指し、人間であるプログラマに大切にする思想に立っている。

[12のプラクティス]

　XPは、これらの思想に立脚し、次の12のプラクティス（経験に基づいて有用性が立証された実践項目）を示している。

�@　計画ゲーム(The Planning Game)
　ビジネス優先度と技術的見積により次回リリースの範囲を早急に決める。現実が計画と変わったら、計画を更新する。
�A　小規模リリース(Small Releases)
　シンプルなシステムを早急に生産に投入する、それから新バージョンを非常に短いサイクルでリリースしていく。
�B　比喩(Metaphor)
　どの様に全体のシステムが機能するかを示すシンプルな喩え話(メタファー)をメンバが共有することで全ての開発を導く（ガイドする）。
�C　シンプルデザイン(Simple Design)
　いつでもシステムは出来る限りシンプルに設計されるべきだ。余分な複雑さは見つけ次第取り除かれる。
�D　テスティング(Testing)
　プログラマは継続的にユニットテストを書く、それは開発を続けるために完全に動かなければならない。顧客は、機能の開発が終わったことを示す機能テストを書く。
�E　リファクタリング(Refactoring)
　二重コードを取り去り、コミュニケーションを改善し、単純化し、柔軟性を加えるために、プログラマは、システムの動作を変えることなくシステムを再構成する。
�F　ペアプログラミング(Pair Programming)
　全てのコードは２人のプログラマにより一台のマシンで書かれる。
�G　共同所有権(Collective Ownership)
　誰でも、どのコードでも、どこででも、いつでも、プログラマはコードを修正できる。
�H　継続的インテグレーション(Continuous Integration)
　システムを一日に何回もインテグレードしビルドし、テストを 100% パスさせる。
�I　週40時間(40-Hour Week)
　週40時間以上仕事をしてはいけないのがルール。
�J　オンサイト顧客(On-Site Customer)
　現実のユーザをチームに加えて、フルタイムで質問に答えられるようにする。
�K　コーディング標準(Coding Standards)
　プログラマは、コーディング標準に従って全てのコードを書く。

2.4.5　コンポーネントウェア

2.4.5.1　デザイン・パターン

　デザイン・パターン[21]は、ソフトウェアの拡張性・再利用性を高める構成法のカタログである。
　ソフトウェア開発の生産性を高める有効な手段の一つが再利用である。繰り返し使われる機能を集めた関数ライブラリやオブジェクト指向に基づき機能とデータを一つにまとめて内部を隠蔽したクラスライブラリといったコンポーネントは、再利用形態の例である。
この他の再利用の形態として、フレームワークがある。フレームワークは、コンポーネントのように完成品ではなく、半完成品である。繰り返し使われる枠組み（半完成品）だけを提供し、開発者が目的に応じて、その枠組みに拡張を施し、最終的に完成品を効率よく作成することを目指している。通常、互いに関係を持つクラスを集めたクラスライブラリとして提供され、開発者はそれらを継承するなどして独自のクラスを作成し、フレームワークが用意した枠組みに沿ったアプリケーションを作成する。
　しかし、フレームワークは、大きな問題を抱えている。それは、その設計アイデアをよく理解し、クラス間の約束事などの仕掛けを理解しなければ、フレームワークを使いこなすことはできないということである。その問題を解決するのがデザイン・パターンである。設計の中で繰り返し使われる設計アイデアをデザイン・パターンとして取り出して名前を付け、ボキャブラリを多くの人々の間で共有することによって、設計アイデアや、それによる構築法の理解を助け、再利用を可能にするのがデザイン・パターンである。

[GOFのデザイン・パターン]

　ソフトウェアのデザイン・パターンのアイデアは、1991年のOOPSLA（Object-Oriented Programming System, Languages and Applications）で出され、Erich Gamma、Richard Helm、Ralph Johnson、John Vlissidesの4名による『Design Patterns』が出版されて、世の中に広まった。これには、表3に示す23個のデザイン・パターンが記述されおり、4人組になぞらえて、GOF(Gang Of Four)の23パターンと呼ばれている。

　各デザイン・パターンについて、目的、別名、動機、適用可能性、構造、構成要素、強調関係、結果、実装、サンプルコード、使用例、関連するパターンの説明がなされている。例えば、Observerパターンの目的、適用可能性、構造は、以下のように示されている

[目的]

　あるオブジェクトが状態を変えたときに、それに依存するすべてのオブジェクトに自動的にそのことが知らされ、また、それらが更新されるように、オブジェクト間に一対多の依存関係を定義する。

[適用可能性]
　次のような状況で Observer パターンを使う。

• 抽象化により、2つの面が、一方が他方に依存しているという形で現れる場合。これらの面をそれぞれ別々のオブジェクトにカプセル化することにより、それらを独立に変更したり、再利用したりすることが可能になる。
• 1つのオブジェクトを変化させるときに、それに伴いその他のオブジェクトも変化させる必要があり、しかも変化させる必要があるオブジェクトを固定的に決められない場合。
• オブジェクトが、他のオブジェクトに対して、それがどのようなものなのかを仮定せずに通知できるようにする場合。別の言い方をすると、これらのオブジェクトを密に結合したくない場合。

[構造]

2.4.5.2　Webサービス

　Webサービスとは、広義には、インターネットの標準的なプロトコルを使ってアクセスできるサービス全般を意味する。狭義には、インターネットの標準的なプロトコルとして、サービスの通信プロトコルを規定するSOAP(Simple Object Access Protocol)、サービスのインタフェース定義を規定するWSDL(Web Services Description Language)、サービスディレクトリを規定するUDDI(Universal Description, Discovery, and Integration)を使ってアクセスできるサービスを意味する。
　そのコンセプトは、サービス指向アーキテクチャに基づいて、サービスとして表されるソフトウェア・コンポーネントを疎結合でつなぐものである。技術的には、オブジェクト指向、コンポーネントウェア、及び分散処理技術の延長線上にある漸進的な技術であるが、しかし、ソフトウェアアーキテクチャ的には、プラットフォーム独立の実現、クラサバモデルからP2Pへ、ビジネス的には、ソフトウェアからサービスへ、ソフトウェアエコシステムの登場、無料Webから有料Web時代へ、といった革新的な変革をもたらすものである。
　以下に、Webサービスの基本技術であるSOAP、WSDL、UDDIについて説明する。

[SOAP]

　SOAP[22]は、XMLを用いてメッセージ交換するための通信規約であり、サービスを実行するときに用いられる。下位の通信層は通常HTTPを用いるが、これに限定した仕様ではなく、例えばSMTPを用いることもできる。
　SOAPによって送受信されるXMLは、ルートにEnvelope要素があり、その下位要素に、HeaderとBody要素が存在する構造を持つ。Header 部は、主にメッセージの制御のために扱われ、例えば、署名情報などが格納される。Body要素に、通信したい内容が格納される。このBodyの中身は、XML Schemaで定義した任意のXML文書が記述できる。
　特にSOAPには、RPC(Remote Procedure Call)を実現するために用いる表現の規約があり、要求側では、Body要素の中に、メソッド名、引数に関するXML情報が記述され、一方、応答側に、結果を表すXML情報が記述される。このRPCに用いる引数や結果の値に利用できる型は、XML Schemaで定義された基本データ型(byte, short, integer, double など)と、その複合型(構造体と配列)である。構造体は、XML Schemaの文書型定義を用いて表現し、配列は、SOAP encodingによる特別な表現が用意されている。
　この他、SOAPには、SOAP Messages with Attachmentsという仕様があり、MIMEなどでエンコーディングした複数のパートにまたがる文書を転送することができる。

[WSDL]

　WSDL[23]は、Webサービスのサービスインタフェースを XML で定義するための言語であり、サービスがどのようなものであるかを理解するために用いられる。また、このWSDLによって、Javaのinterface定義等のプログラミング言語からWSDLを自動生成したり、SOAPのクライアントプログラム用プロキシクラスを生成したりする支援ツールが可能となり、ソフトウェア開発が容易となる。WSDLのXML文書は、definitions要素の中に次のような要素を記述する。

• types
  引数や返却値に現れる型を宣言する部分。XML Schemaによる文書型の規定を行う。
• message
  交換する一つのメッセージのフォーマットを規定する。message要素の中にpart要素があり、これが引数のひとつずつに対応する。
• portType
  まとまった操作の集合を表す。portTypeの中には、一つの操作を表すoperation要素がある。さらに、operation要素の中には、input要素、output要素が記述され、これが、それぞれmessage要素と結び付けられる。
• binding
  転送プロトコルへのバインディングを行う。例えば、SOAP bindingでは、WSDLで定義したインタフェースとSOAPメッセージの関係を定義する。
• service
  service要素はport要素を持ち、サービスのエンドポイントなどを指定する。

[UDDI]

　UDDI[24]は、Webサービスの公開と検索を行うレジストリの仕様を規定し、主にレジストリのデータ構造とレジストリへのアクセスインタフェースの定義を行っており、どのようなサービスがあるかを検索するために用いられる。
　その内容は、businessEntity, businessService, bindingTemplateの3階層からなるXML文書と、tModelを表現するXML文書からなる。

• BusinessEntity
  サービスを提供する企業に関する情報(企業名、所在地、企業コードなど)を記述する。
• businessService
  サービスの内容や種類に関する情報を記述する。
• bindingTemplate
  サービスに接続するための情報(tModelへのリンク、エンドポイント)を記述する。
• tModel
  サービスにアクセスするためのインタフェース情報(WSDL等)へのリンクを記述する。

　そして、これらの情報を登録、検索するためのAPIとしては、次のものが用意されている。（_XXXは検索対象を示す）

• ? 参照API (Inquiry API)
  • ? find_XXX　キーワードなどを用いた検索のためのAPI。検索の結果は対象となった要素のキーがリスト形式で返される。
  • ? get_XXX: find_XXXで検索されたキーから、その実体（内容）を取り出すときに使用するAPI。
• ? 発行API (Publication API)
  • ? save_XXX: オブジェクトを登録するためのAPI。
  • ? delete_XXX: レジストリのエントリを削除するためのAPI。

2.4.6　既存ソフトウェア資産を生かす技術

2.4.6.1　アプリケーションインテグレーション技術

　現在の社会は、膨大な既存アプリケーションを抱えている。しかも、その多くの既存アプリケーションは、脆弱であり、スパゲティ状態である。SDPが目指すものが実現したとしても、これらの既存アプリケーションを即座に捨てるわけにはいかない。SDPが実現する新しいソフトウェアアーキテクチャを核としたインフラ上に既存アプリケーションを追加・統合し、段階的に消滅させていかねばならない。このために、アプリケーションインテグレーション技術が必要となってくる。
　アプリケーションインテグレーション技術は、図7に示す5つのレベルがある。

　基本ミドルウェアのデータ管理は、リモートのファイル、DBを論理的にローカルにあるかのように扱う。たとえば、JDBC、ODBC、NFS、MicrosoftのWindowsなどである。通信管理は、RPC、メッセージ指向ミドルウェアのように、リモートとの通信を同じシステム上の通信のようにする。プラットフォーム管理は、通信管理のスーパーセットで、サーバとサーバ間、サーバとクライアント間のプログラムローディング、メモリ管理等のリソース管理を同一のシステム上の管理のように行う。
統合ミドルウェアのゲートウェイは、異なったDBシステム、通信システム、プロットホームを共通のインタフェースで扱えるようにする。　スーパーサービスは、異なった複数のOS、サーバにまたがって、ディレクトリ、セキュリティ、トランズアクションマネジャといった共通の機能を提供する。インテグレーションブローカは、二つのアプリケーション間のメッセージの内容を変換したり、コンテンツの内容に応じて宛先を決定したりして、アプリケーションの統合をサポートする。ビジネスプロセスマネジャは、アプリケーション統合をマルチステップまで広げて自動化し、ビジネスプロセスのワークフローをサポートする。
　繋ぎ方として、メッセージバス方式とハブ方式がある。統合のパターンには、システムが物理的も論理的にも独立で一方向のデータ同期の方式と、システムが物理的には独立であるが、論理的にはワークフロー的に複数のプロセスが一方向に繋がるマルチプロセス方式と、システムが物理的にも論理的にも繋がり、双方向のデータの同期を取り遅延なく整合性をとる複合アプリ方式とがある。今後は、複合アプリ方式が重要となっていく。
　繋ぐ時の通信のモデルには、対話型、リクエスト・リプライ型、メッセージ・パッシング型、ストア＆フォワード型、パブリッシュ・サブスクライブ型の5つがある。
　ストア＆フォワード型は、キューを持つことにより、メッセージの完全性、配信保証をし、パブリッシュ・サブスクライブ型は、送信者は宛先を指定しなく、受信者が受信したい情報を論理的に指定する方式で、送受信者の相互作用を最も柔軟にできる。この2つの通信型のサポートによって、イベントベースのビジネスプロセス統合を実現できることに特徴がある。例えば、新しい注文を受けると、販売報告システム、製造システム、請求伝票システムへ即時に通知され、ビジネスプロセスの統合が遅延なくデータの同期を取って実現できる。
　以上のようなアプリケーションインテグレーション技術で既存アプリケーションを統合していくには、脆弱でスパゲティ状態の既存アプリケーションを標準化、部品化、抽象化、再構築するのを自動化、支援するツールとして、コンバータ、アダプタ、ラッパー、リバースエンジニアリング等で構成されるアプロケーションインテグレーション環境が必要となってくる。

2.4.6.2　CBS（COTS−Based Systems Initiative）

　CBS[25]は、カネーギーメロン大のSEI(Software Engineering Institute)で研究開発中のプロジェクトで、商業的ソフトウェア・コンポーネント(COTS：Commercial Off The Shelf)、既存ソフトウェア・コンポーネントを用いて、システムを構築するための開発手法に取り組んでいる。CBSは、従来のシステムコンテンツ（要求、価格、スケジュール、OS・サポート環境等のシステムに求められる性格）の選択、アーキテクチャと設計、実装の工程を順次に行うウォータ・フォールモデルではなく、システムコンテンツ、アーキテクチと設計、市場の於ける製品の能力を同時に検討するアプローチを目指している。

図8　CBSの開発手法のアプローチ

　COTS、既存コンポーネントからシステムを構築するには、以下のような質問に答えて行かねばならない。

• どんな技術、製品が適切か？
• 我々のシステムに製品のミスマッチがどの程度あるか？
• 個々のコンポーネントを制御しづらくなるにも拘らず、信頼性、安全性、性能といったシステム特性をどのように設計するか？
• COTS製品とカスタムコードをどのようにインテグレートしていくか？
• 長いライフタイムに亘ってシステムを出荷する間にCOTSの良さをどのように生かすか？

　このような難しい質問に答えるためにCBSは次の３領域をキーポイントとしている。

(1) 製品と技術の評価の実施
　製品と技術の評価に際しては、直接的なシステム要求に応えると同時に、その技術、ソフトウェアの進化が途切れることがないかを考慮しなければならない。そのため、候補となる製品、技術は、関係する製品、技術との関連のなかで評価されなければならない。したがって、問題領域での実験に着手して、クリティカルな質問に答え、COTSの製品、技術の適用に対するガイドラインを作成していくようにしなければならない。
(2) 入手とマネジメントの実施
　CBSでは、システムの開発者という立場からシステムの消費者、インテグレータという立場へと変化し、コンポーネントのライセンシング、知的財産権の交渉、開発・メンテナンスコストの見積もり、スケジュールの予測、人材の管理、リスクの同定と軽減といったことに対する戦略が必要となる。さらに、システムに柔軟性を持たせるための知識、いろいろな創造的なソルーションを可能とするドキュメントも要求される。このために、CBSは、CBSをうまく活用した組織の実践例の情報、あるいは、CBSにおける入手の失敗を避ける情報を提供し、CBSに対する要求の作成、リスクの同定等、CBSプロセスを支援する。
(3)　設計とソフトウェア・エンジニアリングの実施
　CBSシステムでは、コンポーネントをインテグレートするために「つぎはぎのコード」が使われ、このため、可読性、発展性、信頼性に欠ける傾向がある。これを克服するため、CBSコンポーネントの人工的な見せかけを記述する参照モデルを開発、提供している。
CBSのシステムエンジニアリングでは、図9に示すようなプロセスを経てシステム開発が行われる。最初はコンポーネントの多くのプロパティは未知であり、ブラックボックスとして扱われ、システマティクな調査によって、プロパティが明らかにされる。プロパティが明らかにされると、他のコンポーネントと矛盾したり、対立したりするものが明らかになり、その矛盾、ミスマッチがコンポーネントの改造プロセスで除かれる。ミスマッチが除かれると、コンポーネントはシステムに組み込まれ、そして、他のコンポーネントと共に再構成されて、進化していく。

図9　CBSのエンジニアリング・フレームワーク

　この参照モデルは、順次的な段階で行われるものでなく、コンポーネントのプロパティによってアーキテクチャ・パターンが決められるものである。

【次へ】