|
2.1 対象
- 1. エンドユーザ
一般に,エンドユーザの範囲は広いが,本研究では, ユーザ企業のエンドユーザ部門に所属する基幹業務担当者および 一般にオフィスワーカーといわれるような人達を対象とする. 特に,後者の人達は,業務の専門家として, DB検索や表計算などに市販のアプリケーションパッケージを利用しており, 今後急速に増加すると思われる.
- 2. 対象ソフトウェア
本研究では,「すべての日常的な業務をコンピュータ化する」,即ち, 「日常的業務はマニュアル化でき,マニュアル化できればコンピュータ化できる」 という観点から,オフィスでの業務用アプリケーションを中心に グループウェアやワークフローシステムなども対象とする. 規模的には,中,小規模のアプリケーションソフトウエアを想定することになるが, ネットワーク接続するによりシステムとしては大規模化することもある.
- 3. 開発・保守形態
本研究では,基本的コンセプトとして,をかかげた. これは,問題領域を分析してドメインモデルを構築した時点で ソフトウエアの開発を完了させようというものである.即ち,
- 「ドメインモデル≡計算モデル」
- 「分析≡設計≡プログラミング」
「ソフト開発=モデリング+シミュレーション」
という図式で表現されるように,問題領域のモデルを作成し, そのモデル上でシミュレーションしてモデルの妥当性を検証した後, 実用に際しては,そのモデルをインタプリタにより実行するか, あるいは必要に応じて実際のプログラムを自動生成するという方法である. この時,特定分野向きのコンポーネントウェアを導入して, プログラミングの複雑さを回避することも重要である.
このように最終的にはエンドユーザが 自らの業務のアプリケーションソフトウエアを自ら開発し, 自ら利用することを 目標とするが,その実現に向けての技術課題は多い. そこで,研究のマイルストーンとして,エンドユーザが主体で システムエンジニアの助けを借りて開発するが, 保守はエンドユーザだけで行うレベルを設定する.
2.2 モデリングプロセス
- 1. 2階層モデル
今後増加していくと思われる エンドユーザコンピュ−ティングの分野に分散オブジェクト指向設計技法を 適用するためには, モデリングの初期の段階で,従来の技法であまり明確に示されていない オブジェクト群の動的な振舞いを記述することが重要である. 我々は,次に示すようなマクロモデルとミクロモデルの 2階層モデルを導入して, 基本的コンセプトを実現した.
- マクロモデル
- 「ドメインモデル≡計算モデル」を実現するレベルであり, オブジェクト指向の分散協調型モデルとして位置づけられる.
- ミクロモデル
- 「分析≡設計≡プログラミング」を実現するレベルであり, オブジェクト指向のクラス定義として位置づけられる.
- 2. ドメインモデルの構築手順
オブジェクト指向の概念の発生学的定義に基づいて モデリングプロセスの形式化を行う.概要を図 2.1に示す. 詳細は文献[8] に詳しい.
分析フェーズで構築されるインスタンスベースのドメインモデルを 以下のようにOAM(Object-based Analysis Model)として表現する.
ドメインモデルOAMは,オブジェクトの集合O,メッセージの集合M, メッセージ変換の集合Tの3つ組で規定する. o[i]は,ドメインモデルに含まれるi番目のオブジェクトである. m[i,j,n] は,i番目のオブジェクトo[i]からj番目のオブジェクトo[j]へ 送信されるn番目の種類のメッセージである. メッセージ変換の集合Tは, あるオブジェクトo[j]があるメッセージを受信した後, メッセージの列を送信するという関係を
OAM = { O, M, T } O = {o[i]} M = {m[i,j,n]} T = {t[r]}
t[r] : m[i,j,n] → {m[j,k1,n1], m[j,k2,n2], ...}
また,ドメインモデルOAMの外界を仮想的にオブジェクトとみなして, 外界からドメインモデルへのメッセージ集合Min,ドメインモデルから 外界へのメッセージ集合Moutを決定する.
- 3. 設計モデルの構築手順
ドメインモデルは,2階層モデルの下位の層に対応する設計モデルに詳細化される.設計 モデルはクラスに基づいて構築されるので,以下のようにCDM(Class-based Design Model)として表現する.
CDM = {MD, C, H}設計モデルCDMは,メソッドの集合MD,クラスの集合C,クラスの階層関係の集合Hの3つ 組で規定する.
Software Engineering Lab., Meiji Univ.