3.1 全体構成
- M-baseの開発環境とアプリケーション・アーキテクチャの関係を図3.1に示す.
図3.1:M-baseの開発環境とアプリケーションアーキテクチャ
開発環境は主に次のような構成要素からなる.
- ・モデリング&シミュレーションツール
- ・スクリプト言語
- ・UIビルダ
- ・コンポーネントビルダ
- ・共通プラットフォーム
これらのツールを用いて開発されるアプリケーションは大まかには次の3つの部分から構成される.
- ・ユーザインタフェース
- ・モデル
- ・コンポーネントウェア
モデルはアプリケーションに固有の処理を行う本体である. 動的モデル(ドメインモデル)に対応するOAMの部分をモデリング&シミュレーションツールを用いて作成する. 静的モデル(設計モデル)に対応するCDMの部分をスクリプト言語を用いて作成する.
ユーザインタフェースはそのアプリケーションのユーザとの対話処理部分であり, モデルと独立させることにより,クライアント/サーバシステムなどのシステム構成,あるいはクライアント端末のマルチプラットフォーム化が容易になる. その構築ツールとしてUIビルダがある.
コンポーネントウェアには分野に共通の基本部品と特定業務分野向きの部品がある. 後者が充実してくるとエンドユーザによるアプリケーション構築が容易になる. このようなコンポーネント化を支援するためにコンポーネントビルダを用意する.
共通プラットフォームはミドルウェアと基本ソフトウェアの部分で,オープンシステムや部品の流通の観点からは特に分散オブジェクト管理機能などが重要である.
3.2 モデリング&シミュレーションツール
- 3.2.1. 基本機能
モデリング&シミュレーションツール[1,2,3]は,主にマウス操作により動的モデルを構築するツールである. 動的モデルは,オブジェクトとメッセージパッシングで構成される. システムの動的モデルをアイコン表示などで視覚的に判りやすく表し,かつ,オブジェクト指向の概念を素直に表現することを目標としている.
図3.2は,モデリング&シミュレーションツールを用いた例である.
既存のビジュアルプログラミングツールでも,オブジェクト間をリンクで結んでアプリケーションを構築していくものがある. しかし,これらのツールではデータベースからデータを検索し,その結果の表を作成したり,さらにそれをグラフ表示するといった典型的な処理には向いているが,非定型の業務をモデル化の段階から支援してアプリケーションを構築するようにはなっていない.
我々が開発したツールでは,オブジェクト指向概念に基づく分散協調型問題解決モデルを用いて業務モデルの動的な振舞いを表現できるようにした. モデル化の各段階でシミュレーションによる動作確認ができるようにすると共に,「メソッドの意味定義」によってその動作を詳細に規定できるようにした.
例題として会議開催システムを取り上げ,実際の開発手順にしたがってモデリング&シミュレーション技法を説明する. 会議開催システムはグループウェアの代表的なアプリケーションパッケージであるスケジューリングシステムの一種であると考えて良い. M-baseはこのようなアプリケーションをエンドユーザ自身が開発,保守できることを狙っている.
例えばオフィス等で,
事務局に会議開催の指示が出されると,事務局はその会議のために会議室の予約とOHPなどの備品の予約を行なうと共に,会議開催通知を出席者に送り,出欠の返事を返してもらう.
以上に挙げた業務を自動化するアプリケーションを想定する.
M-baseにおけるモデリングは次の手順で行なわれる.
- 外部仕様の作成
- - システムの利用者の抽出
- - 機能概要の記述
- - 入出力メッセージの決定
- 動的モデルの作成
- - オブジェクトの抽出
- - メッセージの抽出
- オブジェクト内部の詳細化
- - メンバ(属性)の決定
- - メソッド(操作)の意味定義の記述
- - メソッド内部のスクリプティング
- 3.2.2. 外部仕様の作成
まずはじめにシステムの利用方法を明確にするために,OOSEと同様の一般的な手法をとる. すなわち,システムの利用者(アクタ)を抽出し,各々の外部入力から開始される機能概要(ユースケース)を記述する. そして最後に外部インタフェース,即ち図2.1におけるMin,Moutを決める.
会議開催システムでは,会議開催者,会議参加者が利用者であり,会議の予約,変更,取消の機能が存在し,それぞれの機能概要を記述することになる. また,入出力メッセージについては,会議の予約を例にとると「会議室名と日時を指定する」といったものになる.
- 3.2.3. 動的モデルの作成
このフェーズでは,各シナリオに対するシステムの動的な振舞い,即ち,インスタンスベースのメッセージのやりとりをモデリングしていく. オブジェクトやメッセージの抽出は,以下に挙げる方法によって行なわれる.
- ひとまとまりの日常的業務が割り当てられる一人または複数の人からなるグループを一つのオブジェクトに対応させる.
- 一人又はグループの間で相互の通信手段として用いられている書類,メモ,電話,郵便,口頭連絡などはすべてメッセージとみなす.
- 日常的業務における協調作業はメッセージの送受信によって遂行される.
一つの業務を擬人化したオブジェクトに割り当てることにより,メタファベースのモデル化を行う. 実世界と同じように一つのオブジェクトに複数の業務を割り当てることも可能であるが,柔軟性と保守性を重視して「1オブジェクト1業務」の割り当てを原則とした.
会議開催システムでは以下の4種類のオブジェクトからなる.
- 事務局オブジェクト
会議開催の要求メッセージを受けると,会議室の予約,OHPの予約,その会議のメンバへの会議開催案内などのためのメッセージを各々の担当オブジェクトへ送り,その後,メンバからの出欠通知のメッセージを受け取り,管理する.会議室管理オブジェクト
会議室予約の要求メッセージを受け取り,予約管理する.備品管理オブジェクト
備品予約の要求メッセージを受け取り,予約管理する個人オブジェクト
会議開催案内のメッセージを受け取り,出欠通知のメッセージを送る.
この部分で用いるツールは,ドローツール風の視覚的にわかりやすいインタフェースを備えている. 図3.2に示すようにオブジェクトをアイコンにより表示し,メッセージをアイコン間を結んでいる線により表示している.
また,メッセージに付けられている番号はメッセージパッシングされる順番を示している. この順番はメッセージ変換列を表現するために用いる. これに基づき,直列や並列の処理を表現し,スクリプト言語Hoopのメッセージセットを生成する. スクリプト言語については後述する.
M-baseの対象となるアプリケーションは比較的小規模なものであるため,このような動的モデルに重点を置く. どうしてもモデルが複雑になる場合には,システムエンジニアの支援をあおぐ必要もありうる.
図3.2:会議開催システムの動的モデル
3.2.4. オブジェクト内部の詳細化
基本的には,メンバの決定,メソッドの意味定義の記述,メソッド内部のスクリプティングの3つのステップがある. オブジェクトの詳細を決めていくには図3.3のウィンドウを用いる.
特にメソッドの意味定義は,マクロモデルからミクロモデルへの橋渡しとして重要である. すなわち,メソッド名だけを用いたシミュレーションによる動作確認には限度があり,メソッド名から内部のスクリプティングに移っていくのには大きなギャップがある. そこで,この問題を解決するために,モデリング時にメソッドの意味定義をできるようにした.
会議開催システムにおける事務局オブジェクトの``予約''メソッドの例を以下に示す.
事務局オブジェクト:会議の予約(日時)
- 会議室の予約要求を出す.
- - 会議室の予約がとれなかったら,その旨を会議開催者に通知する.
- 備品の予約要求を出す.
- - 備品の予約がとれなかったら,会議主催者にその旨を通知し,会議の取消を行なうか確認する.
- 会議案内を出席予定者に送る.
メソッドの意味定義は,次の2つの記述からなる.
- [基本系列] 上の例で,1.から3.の各1行目がこれにあたる. 基本系列は,メソッドの処理の概要を示すものであり,最初にこれを記述する.
- [例外処理]上の例では, - 印部分がこれにあたり,業務フローにおける例外処理を示す. 例外処理は,早い段階で発見でき,気づいた時点で記述しておく.
図3.3:オブジェクトの詳細化画面
3.2.5. シミュレーション機能
シミュレーションは,作成した業務フローの基本的な動作の確認のために行なう. このシミュレーション時に,メソッドの意味定義をメソッドが起動されるたびに表示することで,視覚的にわかりやすくなる. この表示方法には,次に挙げる2つの方法が考えられる.
前者の方法は,ふきだし表示などにより,作成したモデル上で動作の確認が行なえるため,直観的に理解しやすい. 図3.4がその例であり,備品管理オブジェクトの``予約''メソッドを実行中であることを示している.
- ドメインモデルをそのまま用いる方法
- 事象トレース図を用いる方法
図3.4:ドメインモデルを用いたシミュレーション
後者の方法は,システムが動作を開始すると,起動されたメソッドの定義内容が事象トレース図上に表示されていくので,オブジェクト間通信の全体のシーケンスを見渡すことが可能である. 図3.5がその例であり,事務局オブジェクトの会議の予約の処理の中で,会議室管理オブジェクトと,備品管理オブジェクトにメッセージを送り,現在,備品の予約処理を行なっているところである. 実行済みの業務フローは,太い線で表示されている.実際の実行画面を図3.6に示す.
これらの表示方法を併用して使うことにより,メソッドの意味定義の利点を充分発揮できると考えている. この他に,オブジェクトの属性の表示,変更を行なえる機能を実現していく予定である.
図3.5:イベントトレース図を用いたシミュレーション
図3.6:シミュレーション画面
3.3 スクリプト言語
- 3.3.1. 設計思想
Hoop言語[5,7]は,分析・設計段階で使用することを目的としており,以下のような特徴を有する.
- オブジェクト間のメッセージの流れを記述するメッセージセット
- ネットワーク上でのオブジェクトの柔軟な割り付けを可能とする オブジェクトのネスト構造
- 3.3.2. 分散協調型モデルの表現方法
- 3.3.2.1 メッセージセット
Hoopのモデルでは,オブジェクトどうしが直接メッセージをやりとりするのではなく,``宛先のオブジェクト''+``メッセージ''をひと組みとし,これをいくつか組み合わせたものをメッセージセットとして,メッセージセットをオブジェクトどうしがやりとりする. すなわちメッセージセットとは,オブジェクト間に伝わるメッセージの流れを記述するためのものである.
メッセージセットを導入することにより,本来メッセージの流れを管理する立場のオブジェクトが,これを指定できるようになる. 例えば,ワークフローシステムにおいて全体のワークフローを管理するメタなシステムあるいはメタなオブジェクトが不要になり,純粋な分散協調型モデルを構築できる.
このメッセージセットは,先に述べたOAMモデルにおけるメッセージ集合Mの各要素を時系列的に複数個まとめたものに対応する.
- 3.3.2.2 メッセージセットの構文
メッセージセットの構文を以下に示すが,言語の詳細は文献[5]に詳しい.
objはオブジェクト,msgはメッセージ,condは条件,α || βはα,βのどちらかを意味する.
- M ::= M' || ( cond ) M'
- M' ::= Ms || Mp || X
- Ms ::= [ M, M, ..., M ]
- Mp ::= [ M | M | ... | M ]
- X ::= obj.msg
- 3.3.2.1 直列のメッセージセット
メッセージの流れを表現するための従来の方法のひとつとして,アクタモデルのメッセージでは
のように表現する. Hoopでは,さらに``結果の送り先に対するメッセージ''も一緒に送る.
- [ 宛先のオブジェクト, メッセージ, 結果の送り先のオブジェクト ]
例えば,以下のような直列にメッセージを送る場合を考える.このような直列のメッセージセットは以下のように記述する.
[例)]
ある書類oを提出する時に,Aさん,Bさん,Cさんにハンコをもらわなければならず,かつAさん,Bさん,Cさんの順番でハンコをもらわなければならない.
- [ M1, M2, ..., Mn ] (n > 0)
図3.7:直列のメッセージセットの例
簡単な例としてはである.
- [ obj1.msg1, obj2.msg2, ..., objn.msgn ]
オブジェクトobjiはメッセージmsgiを受け取ると オブジェクトobji+1に対してを送る.
- [ obji+1.msgi+1, obji+2.msgi+2, ..., objn.msgn ]
- 3.3.2.2 並列のメッセージセット
一方,並列にメッセージを送る場合は以下のように記述する.このような並列のメッセージセットは以下のように記述する.
[例)]
会議を開催する時に, Aさん,Bさん,Cさんに出欠の問い合わせをする. ただし,Aさん,Bさん,Cさんの どの順番で返事がかえってきても良い.
- [ M1 | M2| ... | Mn ] (n > 0)
図3.8:並列のメッセージセットの例
簡単な例としてはである.
- [ obj1.msg1 | obj2.msg2 | ... | objn.msgn ]
あるオブジェクトが上記のメッセージセットを送ると, オブジェクトobj1, obj2, ..., objnにそれぞれメッセージ msg1, msg2, ..., msgnが送られる.
図3.9:3種類のオブジェクト
- 3.3.2.1 ガード
メッセージセットに条件を付加し,メッセージの流れを動的に変化させることができる. Hoopでは,これをガードと呼ぶ.
ガードを使うのは,以下のような場合である.ガードは以下のように与えられる.
[例)]
会議の出欠をとる時に, 出席であれば出席通知, 欠席であれば欠席通知を出す.
条件が真の時のみメッセージセットが送られる.
- ( 条件 ) M'
簡単な例として,直列のメッセージセットにガードを付加した場合は,
のようになる.
- ( 条件 ) [ obj1.msg1, obj2.msg2, ..., objn.msgn ]
- 3.3.4. 分散システムの実行方式
Hoopでは,分散協調すべきオブジェクト群をネットワーク上のノードへ割り当てる問題や個々のオブジェクトの機能が複雑になった場合のオブジェクト分割問題を解決するために以下の3種類のオブジェクトを導入する(図3.9).
- ノードオブジェクト
- ネットワーク上のノードに対応するオブジェクトであり,内部にプロセスオブジェクト を持つことができる. 基本的に,Hoopではノードオブジェクト を使い記述する.
- プロセスオブジェクト
- 解決すべき問題が複雑な場合に使用する. 複数のプロセスの協調により,ノードオブジェクトが果たすべき機能を実現する. 内部にサブオブジェクト を持つことができる.
- サブオブジェクト
- 補助的なオブジェクトである. 内部にサブオブジェクト を持つことができる. ただし,ノードオブジェクトやプロセスオブジェクトと異なり,逐次処理に限られる.
オブジェクト単位に機能を分割していくときの一番大きな分割の単位がノードオブジェクト である. 基本的には,ノードオブジェクト で問題を記述できる. しかし,ノードオブジェクト の機能が複雑な場合は,ノードオブジェクト 内をプロセスオブジェクト で分割することにより複雑さを解消する. サブオブジェクト については,ノードオブジェクト をプロセスオブジェクト で分割しても,まだ複雑である場合に使用する.
3.4 モデリング&シミュレーションツールと言語処理系の連携
- 3.4.1. スクリプトの生成
会議開催システムにおいて,モデリング&シミュレーションツールで作成されたオブジェクトおよびメッセージ変換列から次のようなスクリプトが自動生成される.
class Main {
public main(String args[]){
}
- Class_事務局 事務局;
- Class_会議室管理 会議室管理;
- Class_備品管理 備品管理;
- Class_Staff 安部;
- Class_Staff 馬場;
- Class_Staff 千葉;
- 事務局 = new Class_事務局();
- 会議室管理 = new Class_会議室管理();
- 備品管理 = new Class_備品管理();
- 安部 = new Class_Staff();
- 馬場 = new Class_Staff();
- 千葉 = new Class_Staff();
- ...
- }
class Class_事務局 {
}
- public 予約(Date d){
- [ 会議室管理.予約(d), this.結果( boolean) ];
- [ 備品管理.予約() ];
- [ 安部.通知() | 馬場.通知() |
- 千葉.通知()];
- }
このスクリプトはJava言語をベースとしたHoop言語で記述されている. これを実行する処理系はJavaで記述されたインタプリタである. ステップごとの実行や属性の変更機能についても今後実装していく.
- 3.4.2. スクリプトの実行
メッセージセットの実行方式を会議開催システムの例で説明する. 前節で示したClass_事務局の``予約''メソッドには次のようなメッセージセットがある.
[ 会議室管理.予約(d), this.結果( boolean) ];
このメッセージセットは,会議室管理の``予約''メソッドに渡される. その予約処理の中には next(...)文が記述されており, それを実行した時点で,残りのメッセージセット
[ this.結果(...) ];
が呼ばれる.
分散システムを実現するために3種類のオブジェクトのうち, ノードオブジェクトとサブオブジェクトを実現した. サブオブジェクトを生成するには, プログラム中で次のように宣言する.
new クラス名();
ノードオブジェクトを生成するには, プログラムの起動時に稼働させたいノード側で次のように指定する.
java hoop.Main -n ``ノード名'' ``ファイル名'' ``クラス名'' ``メソッド名'' ``引数''
ノード名は, hostname name とする.nameについては任意の名前でよい. ノードオブジェクトの参照が必要な時は, プログラム中で次のように指定する.
bind クラス名() [``ノード名'']
ネットワーク部分の実装は,ORBの技術を使用し, RMIを用いた.
Software Engineering Lab., Meiji Univ.