現在のソフトウェア開発では,オブジェクト指向技術がソフトウェア工学の有力な方法として広く活用されている.オブジェクト指向ではオブジェクト同士が相互作用によってある目的に向かって動作するという形態をとり,現実の世界の物事を記述するのに向いている.しかし,オブジェクトの状態および動作は最初に定義されたものに固定されるため,それが環境の変化に応じて適応する状況には対応できないという問題点がある.適応的役割モデルは,役割の概念を導入することによって実世界の現象をシミュレートし,オブジェクトの環境適応を実現する新しい計算モデルである.このモデルに基づいてわれわれはすでに一つのフレームワークを提案しているが,そこではモデル要素が既知であるか,システム記述から直接的に識別することができると仮定して,Epsilonと呼ぶ役割モデルに基づくシステムを構築するための方法を提供した.しかし,特に問題領域が複雑な場合には,この構築フレームワークを適用する前にモデルの構成要素を正確に識別することが難しい.本研究はそのような実際的な状況で,いかにモデルを構築しシステム開発につなげるかというプロセスを確立したいという動機から出発している.

本研究の主要な成果は,役割モデルEpsilonに基づいたシステムの設計および構築のためのフレームワークを提案したことである.このフレームワークは,システムの要求仕様から戦略的かつ体系的に対象システムを表すEpsilonモデルを導出する方法論を提供する.モデル変換手法を用いてモデルからシステムへの実装が自然に行えるため,実行可能なプログラムを自動生成するツールも開発している.本フレームワークを用いることにより,開発者は抽象的なレベルでのモデル構築に傾注することができ,さらに変換ツールによって実装レベルにモデルを変換することができる. 図1に示すように,本フレームワークは主に以下の3つの連続した段階で構成されている.第一および第二段階は人間による作業であり,第三段階はツールにより自動化された作業である.

1) モデルの具体化

この段階では,i*フレームワークという目標指向要求分析手法を改良したトップダウンの方法で抽象化レベルを洗練化することにより,システムの要求から段階的にモデル化を行うための手法を提供している.この手法によりシステム要求からEpsilonモデルの構成要素が抽出され,それが段階的に具体化されて対象問題領域のモデルが構成される.この段階のアウトプットは,モデル構成要素の集合で記述されたEpsilonの概念モデルである.

2)モデル表現

この段階ではUML (Unified Modeling Language)の図式表現を用いて,第一段階で得た要素から構成されるEpsilonモデルを表現するための方法を提供する.この方法で各モデル要素が適切なUMLの構成要素に写像され,対象システムを表現するEpsilonモデルのアーキテクチャとしてUML図に組み込まれる.この段階のアウトプットは,UML図として表されたEpsilonのアーキテクチャモデルである.

3)モデル変換

この段階では,既存のUML描画ツールと本研究で開発した変換ツールを用いることにより,第二段階で得たUML図をJavaプログラムのソースコードに変換する.UML図はまず,UMLツールによって中間表現に変換され,さらに開発された変換ツールでJavaプログラムに変換される.この変換過程は,以下の3つの内部プロセスによって構成されている.

・前処理:UML ツールで生成された中間生成物を別の形式に変換する.

・モデル変換:Epsilon モデルを表す前処理された中間生成物を,Java モデルを表す別の形式に変換する.

・後処理:モデル変換された形式を,Java プログラムのソースコードに変換する.

第一と第三のプロセスはJavaで実装した.モデル変換プロセスには、Model-Driven Engineering:モデル駆動工学(MDE)によるモデル変換技術を採用し,モデル変換言語ATLにより実装した.このツールで生成されたJavaプログラムには,これまでのモデルでは明示的に指定できないビジネスロジックを実現するためのコードを追加する必要がある.本フレームワークではそのためのガイドラインも提供する.

本フレームワークの説明には,会社組織の社員と管理者という役割で構成される具体的な状況を例題として用いている.それとは別に,より実際的なシステム開発における本フレームワークの適用可能性と有効性を評価するため,事例研究を行った.人工知能の分野から交通渋滞監視システムを事例として取り上げ,このシステムを設計構築するために本フレームワークを適用した経験を報告している.この適用経験とシステムの実行に関する実験により,本フレームワークが複雑で現実的なシステム開発にも適用できることを示した.

先行研究として提案した既存のフレームワーク,およびマルチエージェントシステムや自己適応システムなどの役割に基づくシステムと類似するシステム開発のための他のアプローチとの比較も議論している.本研究で提案したアプローチは役割モデルの概念を採用し,それに基づいたシステム開発に直接的な手段を提供しているので,役割モデルが適合する問題領域に対しては優位性があることが示された.提案手法の形式化や,フレームワークの全般的な自動化などは,興味深い今後の課題としている.

図1:フレームワークの概要

ソフトウェアを核とする情報システムは,実世界の環境に置かれて機能を発揮する.置かれた環境が変化した場合や,システムが別の環境に移された場合,ソフトウェアが変化した環境に自ら適応してその機能レベルを持続させることが,現代のソフトウェア技術に課された大きな課題の一つである.

そのような環境に適応するソフトウェアのアーキテクチャの一つとして,「役割モデル」が知られている.オブジェクト指向型のソフトウェアは,オブジェクトを単位として構築されるが,そのオブジェクトが動的に役割を獲得し,また不要になった時点で役割を捨てることによって,周囲の変化に柔軟に対応する,というモデルである.論文提出者の所属する研究室では,以前にそのような役割モデルとしてEpsilonと名づけられたものを提案し,またそのモデルを具体化したプログラミング言語としてEpsilonJを公表している.

本論文ではEpsilonモデルに基づく実際的なソフトウェア開発全体の基盤となるフレームワークを提案し,またそれを支援するツールの開発経緯とその特徴,および使用事例を報告している.その中心的な概念は「モデル駆動開発」である.このフレームワークでは,ソフトウェアに対する要求記述からスタートして,その記述に基づいたモデル構築の方法論を提供する.モデルは標準的なモデル記述言語UMLを拡張した図式で記述され,それを本研究で開発したモデル変換ツールで順に変換し,最終的には実行可能なJavaプログラムを生成する.

本論文は8章で構成されている.

第1章では上に述べたような研究背景と目的,およびその目的達成のための研究方法の概要が説明される.続く第2章では,この研究に至るまでの先行研究の内容,とくにEpsilonモデルとその言語についての紹介がなされる.第3章では,改めて本研究で基本的な枠組みとして用いているモデル駆動開発の方法を述べている.そして要求把握からモデル構築というプロセスで,既存のi*というアプローチを採用しながら,それをいかに拡張し,役割モデル構築に適合するものに改良したかを説明している.

第4章から6章で,本研究の成果の中心内容が述べられる.第4章では,第3章で導入したi*の拡張手法を適用して,要求からEpsilonの静的モデルと動的モデルとを構築する具体的な手続きが詳しく述べられる.説明のために会社組織の社員と管理者という役割で構成される具体的な状況を例にとりながら,モデル構築の手順が精緻に組み立てられており,提案手法の有効性が説得力をもって示される.第5章では,モデルをUMLに準拠した記法によりツールを用いて記述する方法が示される.これにより,作られたモデルは厳密性を保ちながらも図式として直観的な理解が得られ易い形式を獲得できる.UMLは実際のソフトウェア開発で広く導入されている標準記法なので,本研究で提案している手法の普及にも役立つことが期待できる.第6章では,構築されたモデルをステップを追って変換し,最終的には実行可能なJavaプログラムを導出するための方法と,それを実現するツールについて説明している.UML形式のEpsilonモデルはまずXMIという中間形式に変換され,次にATLという言語を用いて開発されたモデル変換ツールによって,等価なJavaモデルのXMI形式に変換される.最後にそれからJavaプログラムが生成される.この一貫した変換を支援するツールを開発したことは独自の成果として評価できる.

第7章では,事例研究により提案した方法の有用性が評価されている.事例としてはマルチエージェント・システムの分野から,交通の渋滞監視システムが取り上げられている.4章から6章で使われた例題は説明用の簡単なものだったが,ここでより複雑な事例を扱うことによって,手法がより実際的な事例に適用可能であることが示されている.第8章では先行研究との比較,全体のまとめ,および今後の展望が示される.

このように,本研究は役割モデルに基づく環境適応型システムの開発支援という重要な課題に対して,精緻な手法の提案,実装と評価を成し遂げたものとして,大きな学術的貢献があると認められる.

よって,本論文は博士(学術)の学位論文として相応しいものであると審査委員会は認め,合格と判定する.