第3章 米国政府支援SDP（Software Design and Productivity）研究開発の動向
SDPの将来の方向性として、前述のように、モデリング、形式的枠組み、オープンな開発環境、既存資産の活用を提言し、キーワードを並べているが、まだ、具体的なイメージがつかめない読者も多いことであろう。SDPに参加したメンバも将来構想であるから、具体的イメージを持っているわけでもなく、各メンバの将来イメージもそれぞれ異なっているので無理からぬ話である。しかし、参加メンバは、予算獲得の思惑があり、各メンバが現在研究していること、あるいは関心があることの延長線上に将来イメージがあるであろう。そこで、SDPが目指す方向に関する、以下に述べる現在の研究動向を把握し、それから、その延長線上の将来イメージがどんなものであるかを把握してもらいたい。
これは、従来、プログラミングとは、インプリメントすることを設計してきたが、モデリングを設計することによって行おうとするアプローチであり、このモデリングが特定領域固有のモデリングドキュメントに他ならないのである。しかし、ただ単にモデリングドキュメントで終わらずに、実行できるものではなくてはならない。従って、モデリングドキュメントを「軽い形式的枠組み」にしたり、「メタモデリング言語」でモデリングドキュメントの意味を規定したりして、あるいは、暗黙的な知識を使ってシステムが自動的に、実行コードの生成をサポートにする。
特定領域記述言語の代表的なのは、スプレッドシートで表に関する処理はほぼ何でもこなすことができる。表以外で注目されるシステムに、Simulink、 Ptolemy、OMGで検討が始まったMDA、Webサービスをベースにビジネスフローを記述するBPEL4WSがある。
（1）Simulink
Simulink[4]は、MathWorks社の製品で、DSPの設計、コミュニケーションシステムの設計、その他シミュレーションシステム向けのダイアグラムブロックの開発ツールである。その特徴は、150以上のブロックを含むライブラリやモデル（出来合いブロックダイアグラム）が準備されており、これらを組み合わせてブロックダイアグラムを作成、編集できる。
図3.1 .Simulink FFTの例
図3.1（http://www.mathworks.com/products/simulink/description1.jsp）は、短時間の高速フーリエ変換ブロック（FFT）の例であり、これはDSPブロックを用いて作成されている。FFTブロックに対するパラメタは右のダイアログボックスで入力される。ユーザがサブシステムの詳細を見たければ、右下に示すその詳細ブロックダイアグラムを表示することができる。
Simulinkでは、ユーザ作成のカスタムブロックをシステムに組み込む、あるいはC言語などのコードをブロックダイアグラムに組み込むことによって、システムを拡張することができる。また、作成したブロックダイアグラムを、インタラクティブに実行することができ、結果を即座に表示したり、グラフィカルデバッガでデバックしたりすることができる。
（2）Ptolemy
Ptolemy[5]は、カルフォルニア大バークレー校のプロジェクトであり、組み込みシステムのような複雑なシステムのモデリングと設計を支援するシステムの構築を目指している。その狙いは、以下の実現にある。
① 組み込みシステムの開発におけるモデリング、設計の方法論の確立
② 適切なコンピュテーションモデルの選択によるシステム設計品質の向上
③ 多数のコンピュテーションモデルを実行するモデルの生成と相互運用
④ コンポーネントベースの設計
Ptolemyプロジェクトでは、ビジュアルエディタであるVergilを用いてモデリング、設計を行う。このVergilの特徴は、単一のコンピュテーションモデルではなく、複数のコンピュテーションモデルの中から選択できることである。Vergilでは、継承構造、手続きインターフェースを主体とするオブジェクト指向ベースのモデリングではなく、並列性やコミュニケーションモデルを主体としたアクタベースとした、以下に示す9つのコンピュテーションモデルが用意されている。
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つ目の特徴は、上記のモデルがグラフィカルに表現されることである。
図3.2（http://ptolemy.eecs.berkeley.edu/publications/papers/01/overview/overview.pdf）は、Discrete Eventモデルの例で、バス停に乗客がポアソン過程で到着し、バスが一定間隔で到着したときと、ポアソン過程でランダムに到着したときのシミュレーションの比較を示す。
図3.3（http://ptolemy.eecs.berkeley.edu/publications/papers/01/overview/overview.pdf）は、Finite-State Machineの例を示す。
3つ目の特徴は、上記のグラフィカルなモデルは、コンピュテーションモデルに基づいてため、意味の形式化がなされ、実行可能で、モデルが意図するものであれば、信頼性のおけるプログラムとなる。
図3.2 Vergilのバス停における待ち行列のシミュレーション例
図3.3 Vergilの状態遷移図の例
（3）UML,MDA
UML（Unified Modeling Language）は、オブジェクト指向に基づく開発方法論で使われるドキュメント（図）を統一したものであって、以下の9種類の図を規定している。
ユースケース図………システム要件となる機能を表す図
クラス図………………クラスの階層構造、振る舞いを表す図
オブジェクト図………個々のオブジェクトの振る舞いを表す図
シ－ケンス図…………オブジェクト間の協調動作（メッセージングの順序）を表す図
コラボレーション図…オブジェクト間の協調動作（メッセージングとコンテキスト）を表す図
状態遷移図……………オブジェクトの状態の変化の様子を表す図
アクティビティ図……操作の中で実行されるアクティビティの流れを表す図
配置図…………………システムのハードウェアとソフトウェアの物理的なアーキテクチャを表す図
コンポーネント図……コードのコンポーネントの物理構造を表す図
しかし、このような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が検討されている。図3.4（http://cgi.omg.org/docs/ptc/02-02-05.pdf）にEDOCのCCA（Component Collaboration Architecture）による販売の例を示す。
図3.4 EDOCのCCA（Component Collaboration Architecture）による販売の例
（4）BPEL4WS
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要素 補償処理の呼び出し