Comments
Description
Transcript
ÍÅÄ モデリングのためのテスト駆動開発
¾¼¼¿ 年度 修士論文 ÍÅÄ モデリングのためのテスト駆動開発 神戸大学大学院自然科学研究科 情報知能工学専攻 潘沂冰 指導教官 林 晋 審査教官 主査 林 晋 審査教官 副査 田村直之 年 月 日 ! " #$ $ $ ! $ % &! $ $ ! $ $ ! " $ $ "$$ ' $ " #$ ! "$$ ! "$$ $ () $ * $ ! $ $ "$$ +*%, - . " $ ! !, "$$ - * ' $ - - - "$$ , " " #$ $ $ , ., " "$$ /0 ! " ! 1 $ ! "$$ " #$ % , 2 ! Æ ! 2 ' ! $ " $! $ "$$ "$$ " #$ 2! / モデリングのためのテスト駆動開発 潘沂冰 要旨 モデルからコードへの自動生成を目標する （ ） は、最新の開発アプローチとして注目を集めている。この目標を達成する上では、 モデルの正当性がますます重要となり、モデル検証の機能がモデリングツールの 必須な機能となる。 現在林研究室では、以前より開発中の モデリングツール にモデ ル検証機能（ ＆ ）を追加する作業を行っている。 その一環として、本研究では現在プログラムの品質を高める有力な方法の つ として注目されているテストファーストの （ を、 モデリングに応用する モデル のテスト駆動開発 技法を提案した。そして、その を システムに おいて実現する （ ） の実装を行った。 では、 の 実行を通じて、モデルの検証を行いながら、モデリングすることができる。 はエラーの修正をガイドする機能を持ち、特に意味論上のエラーにたいするガイダ ンスの仕組みを持つことが特徴である。 は共同研究者の佐藤が作成した 対応のモデリングツール と連携して、まったくモデル要素がな い段階から、テストケースを書くことから始めて、モデルを構築していくという 新たな開発プロセスの可能性を開く。 さらに本研究では、要素間の関連を掴むために、 （ ） というツールを作製し、テストケースを含むモデル要素の作成目的や、 制約条件、要素間の関連などを文書として作成・管理できるようにした。 /0 " #$ 1 $ $ $ $ 3 $ " #$ " $ $ "$$ "$$ "$$ "$$ " $! $ "$$ 4 目次 章 序論 第章 背景 第章 第章 第章 他方法論・ツールとの比較 と コード、モデル、テストケースの重複 第 /1 /0 // $ //1 $ のサイクル /// - /4 " #$ システム 5 6 6 10 14 41 " #$ $ 7 4/ " $ $ の実装 4/1 ., " .," 4// $ 4/4 $ 4/; $ の実行と結果 4/8 とその応用 4/9 エラーの詳細表示とガイダンス 44 $ 技法による開発プロセスのシナリオ 441 $ の手順 44/ 開発シナリオ ;1 論理的構造 ;/ < の構造 ;/1 ;// = 81 $ 811 $ > ; 18 19 1: 16 /0 /1 // /9 4/ 4/ 4/ ;4 ;8 ;8 ;: ;6 ;6 81/ "$$ ガイドと +*%, 8/ ツールのテスト機能 84 要求管理ツールと "$$ 8; 第章 91 9/ 80 80 81 81 結論と今後の展開 結論 今後の展開 機能の拡張 ガイダンス機能の高機能化とインテリジェント化 非同期メッセージのテスト モデルの充実 手順の詳細化 9/1 "$$ 9// 9/4 9/; "$7 9/8 $ 8/ 8/ 8/ 84 84 84 8; 謝辞 参考文献 8 第 章 序論 伝統的なソフトウェア開発プロセスでは開発の初期段階で完全な仕様を作成する のに対して、小中規模のチームで、曖昧で変化しやすい要求仕様と向き合いなが らソフトウェアを開発するための （ ）という方法論が 提唱されている。 の核となっている （ ：テスト 駆動開発）では、非常に細かいサイクルで、 「テスト→コンパイル→動作→リファ クタリング」を繰り返しながら開発作業を進める。この方法では、テスト対象の クラスが存在すると想定して、テストをコードを記述する前に記述する。こうす ることで、目標を最初に決め、そこに向かってコーディングするため、無駄なコー ドが無くなり、テストしやすい設計になるのは当然である。 また、マッピングによる開発手法は「 （ ：モデ ル駆動型アーキテクチャ）」と呼ばれ、最新の開発アプローチとして注目を集めて いる。 は、 （ ）が に続く最新の開発 技術として標準化を推進している技術で、 モデルからコードへの自動生成が 第一目標となっている。この目標を達成する上で、モデルの正当性がますます重 要になるだろう。ただし、厳密で、正しい モデルを作るのが簡単ではない。 したがって、単にモデルを作れるモデリングツールでは十分でなくなり、モデル を検証できる機能も必須となっている。 一方、林研究室で開発したオブジェクト指向組み込みソフトウェア開発用の モデリングツールである システムは、 年度に分散システムに対応す るようになった。この結果、残っているモデル検証の課題、そして のメジャー バージョンアップのインパクトを解決することが今年度 システムの新し いバージョンのターゲットとなった。 本研究はこの目標を達成するための共同研究の一環であり、モデル検証の課題 を解決するようとしている。共同研究者の佐藤は システムを に 対応するように、 というツールの実装を行った。 本研究では、 方法論を でのモデリングに応用する モデルのテスト駆動開発 の提案をし、その を システムにおいて実現する の実装を行った。 は エラーの修正をガイドする機能を持ち、特に意味論上のエラーにたいするガイダ ンスの仕組みを持つことが特徴である。 は と連携して、まっ ?7 ., 7 $ $ ?7 @A = @ = " #$ ?7 $ 3 " #$ /00/ " #$ " #$ " $ $ "$$ 9 /0 $ $ "$$ たくモデル要素がない段階から、テストケースを書くことから始めて、モデルを 構築していくという新たな開発プロセスの可能性を開く。 しかし、 と から成るシステムは構成要素の種類が非常に多 く、要素間の関連を掴みにくくなってきた。この問題を解決するために、 システムの要素の作成目的や、制約条件、要素間の関連などを文書として作成・管 理できる を作製した。 、 、 から構成された新しいシステムは の新 しいバージョン となり、より柔軟性のあるモデリングツールとなった。 本論文は本章を含めて 章から構成される。第 章では本研究の背景となる 技法、 ツール及び システムについて説明する。第 章では を どのように実装していたかについて述べ、そして 技法でのモデリング手順 を実例を用いて解説する。第 章では の論理的構造、 の構造を説明 をどのように実装していたかを述べる。第 章では本研究と類似した し、 目的を持ついくつかのツール、方法論を比較し、それぞれの との違う着 手点を述べる。第 章では本研究の成果および問題点、今後の方針について述べ ることによって本論文の結びとする。 "$$ " #$ " $! $ "$$ "$$ 04 9 - " #$ ; "$$ " #$ / "$$ 9 : 4 $ 8 < " #$ $ "$$ 第章 背景 /0、$ 技法及び 本章では、本研究の背景となる システムについて説明する。 " #$ （ ）とはオブジェクト指向に基づくシステム開 発のためのモデリング言語である。 /0 は 初のメジャーアップリリー スであり、現在、まだ標準化作業を行っている段階で、正式な仕様のリリースは 年中から後半にかけて発表される予定である。 は からの変更は利用者にとっては、それほど大きくないが、 ダイアグラムの書きやすさもモデルの厳密さも向上するので、大規模システムの 分析や設計が容易になることが期待されている。 ただし、利用者からは見えない変更点が数多く存在するため、 対応ツー ルを開発する際の影響は大きい。以下、本研究に関連の深い の変更点を 説明する。 /00; /0 1? /0 /0 1 と の内部構造の整理・強化 > や > をグループ化し、階層構造が作れるようになった。その ために > " を導入され、本研究でもケーススタディに使っ たエアコン・リモコンモデルはこの機能を用いて記述されている。 / 記述法の整理・強化 /0 では、@> が > 記述言語として正式採用され、> 記述法も飛躍的に整理・強化された。たとえば、@操作 と 2振る舞い に対して 7B7 > が貼り付くようになった。 > とは、この @ または 2 が始まるときに満たさ れていなければならない条件のことで、> とは @ また は 2 が終了したときに満たされていなければならない条件のことで ある。この の追加によって、@ や 2 が正しく動作 しているかどうかを検証する道筋ができた。 5 本研究の "$$ は、これらの膨大な > を管理するツールである。 $ （$ とは、C 2* により提唱されたテストを 作りながら、設計を考えるプログラミング方法である。$ は、現在、プログラ ムの品質を高める有力な方法の 1 つとして注目されている。$ 以前に、テスト ファーストと呼ばれる作業の進め方があったが、$ はそれをより体系立て、プ ラクティスに昇格させた方法ともいえる。 テストファーストの方法を使わずに開発したプログラムをテストする場合、実 装したコードの正当性を確認するテストを行う工程が、ソースの作成とは別に必 要となる。この二つの工程が分離されていることで、ソースなどがテストしにく い設計になってしまったり、無駄に書いたコードのテストまでしたりしやすい。 これに対して、テストファーストの では、最初にテストを書くことにな るため、仕様を知らなければテストやソースを組めず、仕様把握をしているのと 同じ効果が得られる。また、目標を最初に決め、そこに向かってコーディングす るため、無駄なコードが無くなり、テストしやすい設計になるのは当然である。 $ のサイクル $ - 次節で紹介する に必要なツール では、テストが成功する場合に、 進捗状況を示すインディケータが緑色になるが、テストが つでも失敗すると、イ ンディケータが緑色から赤色に変わる。そして、 と が ではテストの失敗と成功の代用語になっている。 を利用する際に、 #. 1 =#..D $ #. のときのみ新しいコードを書く #. の時に新しいテストを追加しない という二つのルールを守りながら、次のサイクルを繰り返す。 1 まずテストを書く。 / テストを失敗させる #. 4 仮の実装でテストを成功させる。 =#..D つまり、%* を入れてでも =#..D になるようにする。 6 $ ; =#..D を保ったまま仮実装を本物に置き換える。目標はデータやコード の重複（%* を取り除くことである。 ?7 テストファスト方法論の代表である から単体テスト用のテスティングフレー ムワークという考えが生まれた。このテスティングフレームワークは開発対象言 語と同じ言語でテストコードを記述ことであり、各言語に対応するテスティング フレームワークを作成された。 は、 年に と に より作成されたこのテスティングフレームワークの 版であり、オープンソー スソフトウェアとしてリリースされている。本研究は を使って実装を行っ ている。 - 166: C 2* . = - - の構造 - では、テストコードを本体のコードより先に書き、かつテストコードと 本体のコードは分離される。 1 クラスがテスティングフレームワークの基礎となる。 $> は準備、実行、後処理というテストの実行手順のインタフェース を提供する。$" は複数のテストを統一的に扱うためのクラスであり、 $" により、いくつかのテストケースをひとまとまりのテストとして実 行することが可能になる。図 /1 で示すように、テストメソッドを作成するに は、$> クラスを継承して、必要な場合は メソッドと メソッドをオーバーライドすればよい。 はテストで使うリソースを割 り当てるメソッドで、 はそのリソースを解放するものである。 % /13 $ 10 / メソッドを使って、テストメソッドを作る。 テストコード中では メソッドを呼び出してテストの実行結果の判断 を行う。代表的な メソッド .&（., ）の場合、 テスト対象のプログラムが正常に稼動しているときは , オブジェク トと オブジェクトは同じ値を持っている、ということを意味してい る。すなわち、テストを実行すると、, と の値を評価し、両 者がイコールであればプログラムに問題はないと見なされる。イコールでな かった場合は、テストが失敗となる。 テストの実行結果 では、一つ一つのテストのエラーで実行がとまらず、すべてのテストを 実行させて結果を収集する。テストの実行結果を集めるのが クラスで ある。 には、実行したテストや発生したエラーの数、最終的に失敗し たテストのリストなどの情報が記録される。 では、失敗の場合、 と を区別する。 は、 メ ソッドの実行で期待した値とチェックした結果が一致しなかった場合、 は、 予期されない問題が発生した場合に発生する。 - $# $# - % . % . によるテストの自動実行と結果表示 - は、作成したテストを自動的に実行する機能を提供している。 テスト対象メソッドの名前を ??? というように、() の４文字を先頭 につけて、 で宣言しておく。そして、 に ??? を含んだクラス を渡すだけで、対象のメソッドを自動実行される。 は の機能として、テキスト版とグラフィックス版の両方を提 供する。本研究では図 で示している ベースのグラフィックス版 を 利用して実装を行った。図 は、失敗したテスト結果を表示した画面例である。 - $# // /4 " 11 - % //3 - （" % /43 - 1/ システム 近年のハードウェアの進歩によって、組み込み機器の分野では規模の大きなソフ トウェアに対応した新たな開発技法が求められている。 システムは、この 問題を解決するため林研究室で開発したオブジェクト指向組み込みソフトウェア 開発用のツールである。 に基づいて昨年度開発された では、 図を用いた複数機器のシステムの設計、構築したモデルを動作さ せたり、複数のモデル同士の通信を行うことができた。 しかし、 年 月に、 は初のメジャーバージョンアップを行い、 となった。これを受けて、同研究室の佐藤真紗美は の構造図 の拡張として新たに「モデル図」を提案し、 システムを に対応するように というツールの実装を行った。 そして本研究では、 モデリング上のテスト駆動開発の研究のための 、及び 、 の要素間の関係を掴むための （ の実装を行った。この つのツールから構成され た新しいシステムを と呼ぶ。 本研究で実装した 、 は 、 章で詳しく述べる。ここでは、 システムの他の部分について紹介する。 " #$ 18 " /004 9 " #$0/ /0 " #$ $ $ "$$ "$$ $! $ "$$ " #$04 "$$ "$$ ; 8 4 /0 " /0 " " " #$ （ " は " に基づいた 言語で、 の " と外見モデル間の通信、 ! の記述に使用されている独自実装のミニ言 語である。また、第 ; 章で述べている " を拡張したテスト専用言語の ., " を 記述に使う。 同研究室の清水により、/00/ 年度同研究室の花山健二が開発した並列処理ので きる " 実行系を利用して並列版のオブジェクト指向 言語が作製されつつあるが、今回の研究は旧バージョンの逐次同期型言語の上で 行った。 は主に以下の機能を持つ。 " 言語の制御 文による繰り返し、関数の定 四則演算、代入、 文による条件判断、 義と呼び出しなど（文法は 言語に類似）。 属性値の参照と代入 文法： 7 A 名 属性名 イベントの発信 文法： . オブジェクト名 イベント名 14 ! の呼び出し 文法： ! ! 名 ! !" /0 の各種 で多種の側面からモデリングするためのツールである。 各モデルに対応する各種の 、そして外見モデルのフレームを「モ デル図」（E" 0;F）という にまとめて表示する方法によって、モデル の全体像がわかりやすくなる。モデル図で表現できるものを図 /; で示している。 % /;3 1; 第章 " $ $ は で作られたモデルを検証できるために作製さ れ、さらに と連携して、テスト駆動開発を実現できるツールであ る。"$$ ではテスト対象となるのは モデルであり、$ 7 の 本来の $ に対して、このテスト駆動開発法を ## $ !" と呼ぶ。つ まり、$ は $ 技法を モデリングに適用した モデリ ングのためのテスト駆動開発法である。その目的は正当性が高く、要求に合うモ デルを作ることである。これを略して 技法と呼ぶ。 この章では、この 技法をサポートする について解説する。 節 では の を記述するためのプロファイルを説明する。 節では はどのように実装していったかについて述べる。そして、 節では、具体 的な例を用いて、 システムにおいてどのように 技法でモデリン グするかを示す。 "$$ $ $ " #$ $ $ $ "$$ $ $ 44 4/ 41 技法は と同様に を先に書き、 の実行結果を分析 しながら、モデリングをしていく方法である。本来の が検証する対象はプ ログラム言語なので、 も同じ言語で記述すればよいが、 モデルを検 証対象とする では、 %&（ %）というプロファイルを 定義して、 モデルによって モデルの を記述する。 は、 を次の三つのメタクラスで拡張する。 $ "$7 "$7 1 "> メタクラス " の 、! などの情報を保持する " を持つメタクラス / >" メタクラス " > を するメタクラス 4 ., メタクラス を拡張するメタクラス。以下の ., を作る。 18 " > " > の値を変更する #" > " > の値を読み込む > 実行する時点の > * などの の全体と、すべての " の が、" > として す る 。モデルの の機能としても使える。 #> された と、すべての " の を する モデルの属性、" の状態などが期待する値であるかをチェッ クする % モデルによる 記述 "$7 は、普通の を拡張する 7 なので、"$7 モデルは拡張した モデルとなる。この拡張した モデル（"$7 モデル）で、 モデルをテスト する。., を の代わりにして、 ! " なども すべて、! , して、., ! .," にする。拡張した " 、 ! などで、ループがあるような複雑な でも記述することが可能である。ただし、今度の研究では ., により を記述することにし、.," による記述は今後の 課題とする。 の実装 "$$ は の作成、実行、及び結果表示をでき、テストの結果が正しくな るようにモデリングをガイドする機能をもっている。"$$ は - 版のテスティン グフレームワークである - のオープンソースを使って、実装を行って、主に、 テスト結果の収集、エラーの詳細の表示などの機能を利用した。図 41 で "$$ の = を示し、- を利用した部分を明示している。 この節で、"$$ はどのように構成しているかを説明する。 19 % 413 " $ $ - " #$ の独自実装ミニ言語 " を拡張した言語であり、従来の " と一緒 に使って、テストケースを記述する。.," は > 記述専用のもの であり、テストするためのアクションのほか、勝手に " の 状 態を変化させるアクションもあるので、従来の " で記述する モデルの ! に .," の拡張したアクションを使うとエラーになる。 .," で、拡張した機能は以下の通りである。 !' の ( のセット > オブジェクト名G 状態名 説明 のセットにはスコープの制限がない。つまり、 は全て の " の全ての " に対してセットの操作ができる。ただし、 勝手に をセットできるといっても、 意味論を無視するこ とではない。セットした時点の " が 意味論に反すること はないことを保証をしている。図 4/ では、３つの異なる状況で > の動作を説明する。 文法 1: % 4/3 > モデル全体の " と 説明 "$$ でテストする際に、 がモデルの属性や、" の状態 などを操作することができる。このために、モデル全体を 、 す るアクションを導入する。 を実行する直前に してシステムを 保存し、実行終了の際に して、システムをテストする直前の状態に 文法 戻す。 15 テスト用の .& 期待値 実際の値） $ 値のもつ @A > オブジェクト名G 状態名 説明 .& がもつ第２引数には、変数、モデルの属性などを指定する。テ 文法 スト対象のモデルが正常に動作しているときは指定したモデルの属性値、変 数値と期待値は同じ値を持つべきであるということを意味している。すなわ ち、テストを実行すると、モデルの属性値か変数値と期待値を評価し、両者 が等しければモデルに問題はないと見なされ。等しくなかった場合は、モデ ルが不正であることとみなされ、 期待値 実際値 とい う が発生する。 ( ) % $ はモデルが正常に動作しているときに、指定した @A の値は $ であるべきという意味を持つ。.& 期待値，実際の値 とい う は常に $ 実際の値HH期待値 という と等価 であるが、.& の場合、より明確なエラーメッセージを出すため、 .& を使ったほうがよい。 > は指定した状態が であるかをチェックするもので、モデル が正常に動作しているときには指定した状態が であるべきというこ とを意味している。 はテストの最小単位である。"$$ では規則的な が設定部、実行 部、検証部という３つの部分に分けられる。設定部では、属性値の代入や、 状態のセットなどのテストの事前条件の設定を行う。実行部では、テスト対象を 実行させる。本研究では、 の をテスト対象として位置づけしてい る。検証部では を使って、テスト結果の検証を行う。 ただし、規則的ではない もありえる。可能性としては、３つの部分の １つか２つが存在しない、たとえば、設定部が存在しない場合、その時のシステ ムの状態からテストが始まると考えられる。検証部がない場合、エラーにならな いが、 がないので、テストの機能を持たない になってしま う。そういう意味で、検証部は意味のある に必須な部分ともいえる。ま た、３つの部分を１つのサイクルとすると、１つの には２つ以上のサイ クルが存在するシナリオテストの場合もある。図 で、シナリオテストの例を 示す。 2 44 16 は基本的に "$7 のモデルで記述する。., のス クリプトや、., ! の ! などを使える。 % 443 は の集まりであり、サブ を持つこともできる。 は .," のアクション言語で書いたプログラムであるが、 は パッケージのようにサブ か を持つだけで、プログラムではない。 を実行すると、その が含む全ての 、及びサブ を実行される。 の対象となるものはユーザが自由に決められ、 を 管理するのに便利で、役に立つ。 では、誰でも容易に を記述できるように、テーブルによる 記述の方法を用意している。テーブルは の文法にあまり依存しない記入法を 使用し、 にある各 を対照でき、 の異なる役割を掴みや すい。 テーブルから への変換の様子が図 で示している。テーブルは の が設定部、実行部、検証部に分けられる特性を利用して作られており、 設定部、実行部、検証部にあたる 、 、 を テーブルの該当する欄に入力して、 ボタンを押すと、自動的に各 の のスクリプトに展開される。 の名前が記入されてない行は、 直前で記入した名前の の続きと見なされるので、シナリオテストの場合、 複数の行にわたって記入すればよい。 また、スクリプトとして保存されている を持つ はテーブルに も変換でき、 の修正、追加などの操作が簡単にできる。 "$$ " .," 4; "$$ > $ "A > @C /0 % 4;3 $> " の実行と結果 $ 技法では の実行結果を分析してモデリングするので、 の実行結果は重要な役割となることは当然である。従来、テストの失敗はだれに とってもうれしくないことであるが、 では、失敗は当然なことであること だけではなく、なくてはならない存在でもあるだろう。失敗があるからこそ、モ デリングが進めていくことができる。 の の実行には、 スクリプトがアクションを生成す るための と、コンパイルで生成したアクションを実行する がある。 は文法エラーや、存在しないオブジェクト、属性などに対する操作のエ ラー、 は意味論的エラーや、 が見つかる。 では、右上部のインディケータと で実行結果を明示する。 テストが成功した場合、インディケータが緑であるが、 が一つでも失敗す れば、インディケータが赤色に変わる。失敗の場合、さらに、種類によって、失敗 $ "$$ > > # "$$ .," % /1 >7 # >7 で表示する。"$$ では %、 .. と を分類し、その数を が区別している。 . % で発生するエラー。% が発生する場合、テスト対象のモ デルが正常に動作していない意味をしている。灰色で表示する。 ..（ . . ! " 存在しない要素（オブジェクト、属性、 、 の状態、 など）に対する操作をした際に発生するエラー。一つの に一つ以上 の存在しない要素がある場合、全部収集してからエラーを出す。コンパイル の時に検出し、オレンジ色で表示する。 . .," スクリプトの文法エラーや "$$ の予想外の失敗を含む。赤 色で表示する。 - を使って $ を行うと、テストが失敗した場合、エラーメッセージを収 集して表示されるが、どうやってエラーを取り除くかをユーザが判断しなければ ならない。実は、エラーメッセージ（特にコンパイラエラーと の場合）は そのエラーに基づいて次に何をすべきかというガイドの役になっており、 で は、それを単なるエラーメッセージで終わらせず、ガイドとしてシステムがモデ ルの構築や変更をサポートする。 一部の失敗に対して、その失敗を解決する方法を提供する。解決法を提供でき ない場合でも、大部分に対しては失敗の原因や、解決法につなぐ有力な情報など がガイドされる。これについては、次の節で詳しく述べる。 % とその応用 "$$ " #$04 " 実行の様子を再現できるようにするために、 では、 で記述した 、及び （ を含む）で記述した の実行中に常に を採っている。 は実行の様子を詳しく記録しており、それを利用して、実行 の様子を 図として表示することができる。また、 の場合、実行の 再現だけではなく、 の分析により、テスト対象の 、 をまとめた ' というものを抽出することも可能になる。この は 節に述べるガイダンスの一種として役に立つ。 も同様なので、以下、 の場合の の生成及び応用について説 明する。 ! .," " "& > "! 4/9 ! > > // の形式 4// 節で述べていたように、"$$ の は設定部、実行部、検証部に分 けられる。この三つの部分で、それぞれ次のような形式の をとっておく。 設定部 )* 属性の値を書き換える際に生成する。属性の名前、代入文 " 値、起動源などの情報を記録する。 * " の状態をセットする際に生成する。状態の の左、右両辺の値及び 名前、オブジェクトの名前、起動源を記録する。 実行部 *"* +*( を発生する際に生成する。 のパラメータなどの情報を記録する。 +*( ! を起動する際に生成する。 の名前、起動先、起動源、 *"* ! の名前、起動源を記録する。 検証部 .& という を起動する際に生成する。実 際の値と期待値の値、及び対応の " 値、 の結果（成功か *, 失敗）などの情報を記録する。 > という を起動する際に生成する。状態 の名前、オブジェクトの名前、 の結果（成功か失敗）などの * 情報を記録する。 $"** テストの実行中で、 .. が発生する際に生成する。 . の名前を記録する。 また、 を切り出すための がこのようになる： +"* テストケースの開始・終了する際に生成する。 の名前のほか、実行の開始時間、終了時間を記録する。 48 で、 の例を示す。図 48 の を実行すると、採った を図 48 のようになる。 図 の応用 - . , 図の出力 48 の を & 図として出力したものは図 49 で示す。& 図は 実行の様子を視覚的な表現を与える。 /4 図 % 483 % 493 "& /; の応用 -. テスト対象に対する ' の生成 のテスト対象は実行部で呼ばれる と ! にあたる。"$$ で は、 の設定部はテスト対象に対する事前条件の設定、検証部は事後条件に 対するチェックとみなして、 を解析する。そして、このテスト対象を実行する 前後の属性、" の状態などの変化を整理して、このテスト対象のガイ ドとして保存しておく。 同じ属性か状態は設定部と検証部でともに現れる場合には、その変化が明瞭に 表示できる。この場合は、次のようなガイドを作成する。 属性の場合 設定部に： オブジェクト 属性 1 3H IIIJ 実行部に： . ! テスト対象J 検証部に： .& 期待値，オブジェクト 属性 1J が指定されている場合、次のように属性の変化を表すものを出力する： 期待値 オブジェクト 属性 ： の結果 状態の場合 設定部に： > オブジェクト 状態 1J 実行部に： . ! テスト対象J 検証部に： > オブジェクト 状態 /J が指定されている場合、次のように状態の変化を表すものを出力する： 状態 オブジェクト： 状態 の結果 また、設定部と検証部のどちらの一方にしか現れていない属性か状態の場合、 の片方だけ明示していることになる。たとえば、 (H ) 期待値 オブジェクト 属性 ： や、 の結果 オブジェクト： 状態 などのように情報を作成する。 このようなメカニズムを用いて、例えば図 ような が作成される： > "! /8 48 で示した の場合、次の "$$ は の失敗と成功にはかかわらず、 をとっている。つまり、こ のテスト対象に対する > "! は該当の が失敗の場合も成功 の場合も作成される。また、一つの要素をテスト対象とする が複数存在 する場合、この要素に対する > "! も複数となり、リストの形で要素 が持っている。 を変更した場合、既に生成されている > "! が更新される。 > "! は % が発生する際に、ガイダンスとして提供されるほ か、"$$ を通じていつでも表示することができる。この "$$ による表示に ついては ;/1 で述べる。 エラーの詳細表示とガイダンス "$$ エラーが発生した際、 は にあるエラーの位置を、エラーの種類に より色を変えて表示し、さらにエラーの詳細を表示する。 図 はコンパイラ が発生した場合の詳細を表示する様子を示してい る。同様に、図 は、 が発生した場合の表示を示している。 また、 は を実行して、エラーを検知すると、エラーが発生した原 4: . 4: % "$$ /9 % 4:3 . 因の分析を行う。そして、最大限に解決法を提供しようとする。これは、 の として有名な と同様な機能であるが、 では、その提供 された解決法、あるいは解決法につなぐための情報をガイドと呼ぶ。 詳細はエラーに対する静的な説明に対して、ガイドは常にエラーを解決ための つの動作をサジェストする。エラーが発生した の詳細とガイドは分け て表示し、エラーの種類が異なると、ガイドの生成方法も異なる。 のエラーは、文法 の区別されるが、これら三 つに対するガイドの対処方をまとめると次のようになる。 7 +* %, "$$ 1 . .. % 文法 / の場合 この場合はプログラム言語の構文が膨大であり、可能性な修 正の候補が多すぎるため、自動的な修正は容易ではない。また、自動的に修正す ると、ユーザーにとってはかえって迷惑な場合が多い。そのため、この場合はガ イドは実質的にはできない。これは一般のコンパイラーのエラーから自動修正が 行えないのと同じことである。この場合は、エラーの位置と詳細を明示している ので、それを参照して をユーザーが編集・修正することになる。 !// の場合 これは +* %, と同じように、名前や種類などが分かってい るものが「無い」という状況である。そこで、エラーの原因となったものを作ると いうことが、修正の候補としては、正しい可能性が非常に高い。そこで、 「 を作ってください」というガイドがされ、ユーザがアクセプトすると、 . /: を起動し、. を作成するための を表示する。そして、 で要素を作る時と同じように . を作成できる。図 45 と、図 46 で、そのガイドの様子を示す。図 45 は、ガイドが表示され、それ を選択して を起動したところを、図 46 は、それにより要素が作成され、 再度の の実行で .. が取り除かれた様子を示している。 % 453 = .. 1 /5 % 463 = .. / 0 の場合 この場合も発生の原因が .. のように単純ではないので、 確実なガイドはできない。この場合は文法エラーの時と同様に、修正の候補が多す ぎるのである。しかし、 の場合におきているのは、文法エラーではないこ とに注意しよう。 は、ユーザーが作成した で記述した期待値に、 実際の値が一致してないことである。つまり、 は意味論上のエラーなので ある。 意味論上のエラーの修復方法は、文法のエラー以上に多様であり、それを自動修 % % % /6 復することは、プログラムを自動的に作ることと大きくは変わらず実際的には不 可能なことである。しかし、どのように が失敗したかという情報は、正し い修復方法を発見するための重要な手がかりとなることが多い。このため、 は、 が発生した場合のガイドとして、どのような が発生したかを 整理してデバッグための情報としてユーザーに提供する。その方法は、次のとお りである： % "$$ % 1 "$$ は、 を実行した場合、まず、 の検証部にある でシステムのなるべき状態を指定し、直前の実行部を実行した後のテスト対 象のモデルがその状態になっているかをチェックする。 / もし、期待する状態になっていなければ、% が発生しているわけだが、 この % が発生した の直前で実行されたテスト対象が不正で ある可能性が非常に大きい。 4 4/8 で述べたように、"$$ は失敗と成功にはかかわらず、 の実行 中に常に をとっており、 実行の様子が詳しく記憶されている。 そして、実行が終わった時点で、この を解析し、各テスト対象に対する > "! を作っておく。そこで、% が発生した場合には、該 当するテスト対象に対する > "! の情報をまとめておく。これ が % の場合のガイドであり、' 1" という。 ; このガイドを受けることをユーザが承認すると、その情報を "$$ を通じ て表示する。 % "$$ 410 のガイド機能により が示する情報の様子を図 に示す。 この ユーザーは、この情報を分析しモデルを修正すればよい。この表示はテキストな ので、編集して、テスト対象を修正すればよい。 40 % 4103 = % 41 技法による開発プロセスのシナリオ " #$ の は /0 を基づいた ツールであり、 だけで通常の ツールと同じようにモデルを構築できる。ただし、 " #$ システムは $ 技法を利用してモデルを作製できるという大きな特 徴を持つ。そのために導入した " $ $ は と連携するこ とにより、新たなモデル開発プロセスの可能性を開く。 この節では、 による 開発の実際例を使って説明する。 " #$ $ の手順 $ でのモデリング手順はこのようになる： 1 システムの を作成する / に基づいて、"$7 モデルでいくつかの を作る 4 のコンパイルが成功するまでモデリングする ; を実行して、 % . を観察する 8 を成功させるようにモデリングをしていく 9 を実行して、失敗なら へ : システムの全ての を網羅するまで、 から までを繰り返す 開発シナリオ $ この節では、 でのモデル開発プロセスは次のモコン付きのエアコンシス テムの例によって説明する。 3 エアコン付きリモコンシステムの概要 リモコン付きエアコンシス テムは、エアコン本体とリモコンで構成され、２つの装置は赤外線で メッセージを送受信することより通信する。 リモコンは、電源ボタン、温度上昇ボタン、温度下降ボタン及び表 示機を持つ。電源ボタンを押すと、エアコンに電源状態を切り替える ためのメッセージを送信する。表示機は常にリモコンの設定温度を指 し、温度上昇（下降）ボタンを押すと、エアコンに温度一度ずつ上下 するメッセージを送信する。ただし、最高温度 、最低温度 の /9 4/ 19 制限があり、この範囲を超えると、リモコンの設定温度も変化しない し、エアコンにもメッセージを送らない。 今回の記述はメッセージが必ず届くという前提で行い、エアコンが 届いたメッセージより、対応する動作を行う。 $ これより、上に示した モデリング手順に従い、モデルを開発する。開発 は７つのステップからなっている。ただし、各ステップが のモデリング手 順の上記の７つの項目に対応しているのではなく、一つのステップはいくつかの 項目ができている。 $ ステップ システムの を作成する 図 のように、エアコン付きリモコンシステムのモデル図で、システムの を作成する。 411 % 4113 > # > "! 同じようにリモコン単体、エアコン単体の を以下のように作成する3 リモコン単体 1 電源状態の切替ができる。 / リモコンの設定温度が 19 から /9 まで上下できる。 4 エアコンに送信できる。 2 電源を切り替えするメッセージ 2 温度設定のメッセージ エアコン単体 44 1 リモコンからのメッセージを受信できる。 / メッセージより、動作できる。 2 電源を切り替えするメッセージ 2 温度設定のメッセージ ステップ リモコン単体に対して を作る リモコン単体の に基づいて、 の 二つの を作る。 "$$ 入力テーブルで図 41/ の % 41/3 $ # > 電源と温度設定に生成した はこのようになる： 4; ステップ 「リモコン単体」をコンパイルできるまでモデリングする。 「リモコン単体」をコンパイルすると、 「温度」と「電源」に ある をすべて実行され、全ての において となる。他の も同様だが、 「温度上昇 」の場合は、失敗の詳細が図 、ガイ ドが図 のようになる。 41; 1 % 4143 > . 48 .. 414 % 41;3 = .. . 「リモコン 側の そして、ガイドに従って を作っていくと、 単体」がコンパイルを通ることができるようになり、 のモデル の様子が図 のようになる。 > 418 % 4183 " > ステップ 「リモコン単体」を実行する。 「リモコン単体」を実行すると、 になるが、 の詳細を見る と、 の を作成していないからだと分かる。図 で 「温 度上昇 」の場合の詳細を示している。同様に、他も「リモコン温度下降」、「リ K 1 . 49 . 419 モコン電源 かる。 」、「リモコン電源 K」などの が存在しないことが分 % 4193 . そこで、存在しない を実装する。たとえば次のように実装する： エアコン温度上昇 エアコン温度下降 設定温度 E0F 3H 設定温度 E0F L 1 設定温度 E0F 3H 設定温度 E0F 1 もう一度実行してみると、「温度上昇 1」、「温度下降」は成功になった が、最高温度、最低温度に対する では % が発生した。その様子を 図 41: で示す。 % の場合のガイダンスより、"$$ で図 415 の情報、すなわち > "! をみることにする。 > "! は の実行により、自動的に生成されたテスト対象に 対するガイダンスなので、そのテスト対象に対して、何ができて欲しいのか、既 に何ができていたか、そしてまだ何をできていないかが一目で分かる。 図 の場合、 「 」が発生することより、設定温度が一度下がって 欲しいのだが、 度の場合には下がらない、つまり、設定温度の制限があるとい 415 /9 4: % 41:3 % % 4153 > "! = % % うことが分かる。そして、この制限が、実装できていないので、 が発生し てしまうこともわかる。 この問題は 「温度下降」（「温度上昇」は同様）にガード条件をつけるこ とにより、解決できる。この時点で最初作った が全部成功となり、そして モデルの は図 のようになる。 > " 416 45 % 4163 " > $ 注： ここまでは 技法でモデリングする場合の手順の一つのサイクルと なった。このようにサイクルを繰り返して、全ての を網羅するまで すればよい。 ステップ エアコン単体をモデリングする。 リモコン単体と同じように、エアコン単体に対して をつくり、実行が成 功するまで、モデリングする。その結果、 のモデルである の は図 のようになる。 " 4/0 % 4/03 " > 46 > ステップ リモコンとエアコンの通信に対して を作成する。 エアコン付きリモコンシステムの に基づいて、図 次の二つの を作る。 4/1 % 4/13 $ > ステップ 3 「通信」を実行する。 「通信」をコンパイルすると成功したが、実行すると、図 となった： % ;0 4// のような % 4//3 % % の場合のガイダンスより、"$$ で図 4/4 で示している 「 」、「」の > "! をみることにする。 % 4/43 > "! = 図 4/4 の場合、「」が発生することにより、リモコンの設 定温度だけではなく、エアコンの温度も一度上がって欲しいということが分かる。 しかし、エアコンの温度が変化しなかったため、 が発生した。この場合、 「 」の である「リモコン温度上昇」で、エアコンの温 度を 度上げることを追加すればよいと容易に判断できる。修正した後の 「リモコン温度上昇」はこのようになる： 1 % ! ! ;1 ! 同じように、 「リモコン温度下降」、 「リモコン温度上昇」、 「リモコン温 度下降」にそれぞれ必要なメッセージをエアコンに送信することにする。すると、 「通信」が成功になる。 ;/ 第章 /0 に対応し、さらに $ $ を導入した " #$ システムは、ますます 複雑なシステムになりつつある。複雑というのは、構成要素の種類が非常に多く、 構築システムが大きくなるにつれて、要素間の関連を掴みにくくなるという意味 である。たとえば、ある目的で を作成したが、最初は が発生せ ず、モデリングがかなり進んだ段階で初めて が失敗した時には、既にそ の を書いた目的を忘れてしまっているという状況は現実のシステム開発 の場面では珍しくない。たとえば、前述したリモコン付きエアコンの例の場合、も し図 のようにその目的などを記憶しておけば、この問題を解決できる。そこ で、 システムには、 を導入した。 はシステムの要素の間に関連をつけたり、さらにその関連にコメントを つけたりすることにより、要素の作成目的や、要素間の関係などをメモとして保 存する。そうすれば、最初の考えを時間の経つに連れて、忘れることはなく、よ り精確で、高速で、容易にシステムを修正・拡張できるようになる。 ;1 " #$ "$$ % $! $ "$$ 論理的構造 "$$ の論理的な構成要素には以下のものがある。 1 * 関連をつけられるものであり、以下で と呼ぶ。" #$ システ ムにおいては、基本的に全てのモデル要素が の対象となるが、主 に以下のものがある： 側の各要素3 典型的なのは、>、 !、" などテストの作成目的や、テストの対象となれるもの。 "$$ 側の $"、$> は "$$ 固有の概念であり、モデル要素はそのままでは ではない。要素が "$$ で関連をつけられて、あるいはテスト対象になり ;4 % ;13 > "! が作られて、初めて "$$ のリポジトリに、この要素 に対応する が登録される。他の要素と何の関連も作られてない、 かつテスト対象としての > "! が一つも作成されてない要素は の形では存在しない。また、一つの要素に対する は唯 一である。 / > 間の * であり、その たちの間に何かの関連がある ことを意味する。 は 1 個以上の に付くことができる。 同じ たちの間に が唯一である。 / つの に付く の場合、その / つの をそれぞ れ か、 かを指定することができる。単一の の場合、 は同一ものとし、4 個以上の場合、 を / つのグルー プに分け、それぞれを とすると、全ての にたいし て、、 の対を持ち、方向を指定することができる 図 ;/。 4 .,! ;; % ;/3 につく注釈。 に付く 間の関係についての 説明であり、作成時間の情報を持つ。 の構造 "$$ では、 の表現に と の / つの形式がある。これを という。 ! "# 単一の対象に対する表現であり、ある要素が他の要素との関連の詳細をみたい 時に使う。 は表現対象に注目する目的であり、この対象に付く全ての要 素の詳細が明示される。 を対象とする場合 指定された に * されている 及び ,! を表示する。 の要素は ,（$、、 !）の場合、 名だけではなく、要素の内容を表示する。図 ;4 でこの様子を示し た。三つの領域はそれぞれ の と 、及び ,! にあたる。 を対象とする場合 指定された と直接 を持つ をリスト形式で 表示する。 に付く ,! は、リスト内に常に表示す る。この様子は図 ;; で示た。左の領域にはその が表示され、右 上の領域にはその関連のリストが表示される。 ;8 % ;43 % ;;3 を対象とする では、ユーザにより作成された の情報を表示するだけではなく、4/8 で述べた の実行 により、作成された > "! を表示する役割もしている。> また、 ;9 "! は % の場合のガイダンスとして使われているが、"$$ を 通じて、% が発生したときを限らず、常に見ることができる。% の 場合のガイダンスと区別して、これを > "! ガイダンスを呼ぶ。 > "! ガイダンスはテスト対象の >、> を抽出するのに有力な情報を提供する。図 ;; の の右下の領域で > "! ガイダンスを表示する。また、その > "! ガイダンス の様子は第 4 章の図 410 で示している。 $!! "# 複数の要素を対象とするものであり、システム全体かシステムの一部のすべての 要素間の関連を示す。 は指定要素に直接に関連がある要素のみ示すが、 は直接の関連に限らず、システムの要素間のつながりに注目し、すべ ての要素と要素間の関連を表示する。ユーザは を通じて、要素のシス テム中での位置づけを掴むことができる。 では、それぞれの にレベルを持たせて、レベルによって、各 ドキュメントが仮想的に階層化されるという表現法を取っている。ただし、視点 が異なると、レベル名も階層数も異なる可能性がある。レベルを定義するときに、 どの視点の下で、このようなレベルの階層を定義しているかを示さなければなら ない。その視点を と呼ぶ。 では、最初から 種類の を用意しているが、ユーザが独自の視点から を構築することもできる。 "$$ < $! "$$ < $! / < $! >* 雲B凧B波B魚B貝の 8 つのレベルで構成される $ &B B の 4 つのレベルで構成される < $! が多数存在することにより、それぞれの は複数のレベル （基本的に、< $! の種類と同じ個数）を持つ。< $! を指定すると、表 示パネルを仮想的にいくつかの区域に分け、 がもつ対応のレベルを参照 して、対応する表示範囲に配置する 図 ;8。ユーザがレベルを選んで、見たいレ ベルの だけを表示することもできる。 全ての < $! に対し、レベルの未指定区域を用意する。 にレベ ルが設定されていない場合には、この区域に配置される。ユーザがドキュメントを 移動すると、新しい位置のレベルが自動的にそのドキュメントに設定される。レ ベルの持つドキュメントも移動した場合には、レベルが書き換えられる。 をクリックすると、 の内容を表示される。 の は、 間の をクリックするときに表示される。 ,! > ;: > % ;83 ;5 第章 他方法論・ツールとの比較 本研究は、テストを利用してより正確で迅速なモデリングを行うというアイデア に基づいている。その中心となるテストはソフトウェア工学において広く使われ ているので、本研究に関連する方法論やツールは多い。この章では、これらと本 研究の目的や成果を比較する。その結果、本研究とまったく同じ目的や機能を持 つ方法論やツールは存在しないことがわかる。 ! と " $ は、コードのテスト駆動開発であり、$> $ > と呼ぶべきものである。以下、$ と区別するために、この 本来の $ を $> と呼ぶ。$ は、$> の考え方をモデル構築に適用 従来の したものであるが、コードがモデルに変わったために、従来にはない新しい事態 が生じている。 コード、モデル、テストケースの重複 ?7 技法を支持する人たちが、モデリングや仕様記述の欠点としてあげること に、コードとモデルの重複がある。モデルを先に作り、それからコードを作成する と、コードかモデルに変更が生じた場合に、もう一方を変更する必要が生じ、そ れの手間がオーバーヘッドになるという意見である。これはテストケースとコー ドについても生じることであるが、テストケースとコードの場合は、実行可能で あるために、変更が生じた場合に常にその整合性を自動的にテストできるという 利点がある。 はモデル開発の技法であり、コードの生産を同時には行わない。 はモデルの開発を迅速に行うことを目指しており、実装を始める前段階での迅速な 設計の検証、ビジネスモデリングのように、実装がともなわなくても良い応用例、 あるいは、モデルから実装への変換の自動化を目指すモデル駆動開発 の利 用を前提としている。このため重複の問題はない。また、モデルのほとんどは実 行可能であり、モデルに対するテストケースの実行により、 と同じく、変 $ $ E F $> ;6 更が生じた際には必ずテストケースを実行することにより、モデルとテストケー スの整合性を常に保つことができる。 しかし、 のモデルはすべてが実行可能であるわけではなく、 が 管理する でいう などにあたる文書には実行可能でないものも多 く含まれる。これらが などによる形式的文書であればある程度の自動実行は 可能だが、常に実行可能なのではなく、これらに関しては「重複」の批判が当て はまる。この実行不可能なモデル部品の変更による の問題は、将来 にバージョン管理機構などを含めることにより解決する必要がある。 ただし、 が指摘しているように、 はモデリングを必要以 上に無視しており、実際にはモデリングや設計の重要性は薄れておらず、作りやす く変更しやすいという意味での迅速で軽いモデリング技法が必要性となっている。 は、これを目指しており、テストによる迅速な整合性管理という の アイデアを、モデリングに最大限生かしたものといえる。 " #$ > @> "$$ ! "$$ % E% 00F ?7 $ $ ガイドと %&' "$$ の .. のガイドは、. の機能である +*%, の機能のモデリ ング版である。"$$ では図 45 46 で示したように、状態作成や遷移作成のガイ ドも行う点が +*%, と異なるが、" をプログラムとみれば、状態 や遷移の追加はメソッドの追加に対応しており、これも +* %, と同種のアイ デアと言うことができる。 しかし、 で説明したように、 では、これらの他に、テストケースの の実行の記録 を利用して、 を作成している。この ガイドは、 に該当する機能が無いだけでなく、成功した情報も利用する という点において、 が失敗だけを収集するのに対して、テストケースがシス テムが通った場合の「正」の情報の も作成するという点、そして、 と異なり、 による意味論的情報も含むという点が、本来の と 大きく異なる。 4/8 +* %, $ %, "$$ ! ! +* $> ! ツールのテスト機能 ツールは、テストの機能をもっている。たとえば、$ 社の $ / $ の $$>D4 言語によりテストを記述できる。また、# 社の # $ #$ は モデルツール用のテストツールである。 多くの は、 しかし、これらのテストツールは、あくまで事後テスト、つまり、テストファース トでなく、テストアフター開発用のツールであり、テストファーストモデル開発の 80 $ とは異なった考え方にもとづいている。この論文で示したように、" #$ の $ では、まったくモデル要素がない段階から、最初にテストケースを書く ことから始めて、モデルを構築していくというモデル開発スタイルが可能であり、 これらのテストアフターのツールとは異なっている。 ! 要求管理ツールと # #& 要求管理工学 は、システムの要求を定義し、その変更 を管理するための技術である。トレーサビリティーは、そのための重要な基礎概念 だが、このトレーサビリティーを管理するツールとして、 社の が 良く使われている。また、 用の の として、 がある。 の は、テストケースとユースケースやコンストレイン トを関連付けるために導入された点で、要求管理工学ツールの とは開発 の動機が少し異なるが、結果として、 や に似た機能と なっている。 現在、これらはテストとは関連づけられておらず、また、 モデルの実行と も関係がない。日本 社によると、現在、 を と連 動させる作業が進んでおり 、 年 月以降に出荷される予定である。 これが と良く似た機能を持つことが予想されるが、 のようなテ スト駆動開発法のサポートは計画されてないらしい。 要求管理工学では、要求を定義したとき、システムがその要求に合致するかど うかを検証できるテストを作ることが推奨されているが 、 これらはテストアフターであり、本研究の は、テストファースト要求定 義を行うためのツールとみなすこともできる。 " #$ "$$ " #$ $ @@#" @@#" 7 @@#"B ! @@#" @@#" @@#"B ! $ E= 04F /00; ; $ @@#"B ! $ / $ 5: E" 6:F ! $ は ?7 の中心的技術であり、?7 は という名前でも知 られる。この とモデリングを融合する技術としては、" の が有名なので、当然、これと $ との関連を 考える必要がある。しかし、 が「 はモデリングに対するアジャイル（機 敏）なアプローチであり、その中核部分は経験豊かな多くのソフトウェア開発者 が共有する原則や価値を集めただけのものだということです」と書いているよう に 、この方法は や のようなはっきりした方法論を定義し たものではなく、 と比較できるようなものではない。 E 04F $ $ $ 81 第章 $ 結論と今後の展開 結論 $ " #$ $$ " $ $ "$$ 本研究において、 を モデリングに応用する を提案 し、その を において実現する （ ）の実装 を行った。 では、 の実行を通じて、モデルの検証を行いながら、モ デリングすることができ、さらに、ガイダンスの機能が提供される。これにより、 システムのモデル検証の課題を解決しつつある。 また、 を導入したことにより、システムの要素間の関連を掴みやすくな り、要素の作成目的などをシステムで作成・管理できるようになった。 そして、リモコン・エアコンシステムという実例をもって、この新しいシステ ム の実用性を検証した。その結果、 技法が十分有効であり、 もより柔軟性のあるシステムになっていることが分かった。 $ "$$ " #$ "$$ " #$04 " #$ $ $ 今後の展開 ( 機能の拡張 4 # の 間の "$$ 現在の では、あるモデル要素を変更した際に、どれだけのモデル要素に 影響があるかを調べることができる。さらに、変更が必要な要素のどの部分を変 更すればいいのかも示せるように、モデル要素の 間の関連が必要となる。 たとえば、図 で赤色で示したのはこの の関連である。 " " ;1 " のグループ化の実装 "$$ では、 に付く の数にかかわらず、この ら を に分けて、 を作るという考えで実装を行った。しかし、 現在 をグループ化する機能を実装してないので、4 つ以上の 間の関連を作成できない。 この問題は のグループ化により解決できる。具体的にいうと、まず らを つのグループに分けて、この つのグループをそれぞれ新しい / / 8/ として作成し、そして、/ つの の と同じようにク ループ間の を生成すればよい。つまり、 のグループを一つ の として扱うのである。 ガイダンス機能の高機能化とインテリジェント化 現在、ガイダンスは予め定義されている。これをユーザーが自由に指定できる ようにすることが考えられる。ガイダンスはログを分析して行っているが、ログ を で構造化し、それを分析するツールを提供すれば、ユーザーが自分の目 的にあった分析やガイダンスを に実施させることができる。また、ガイ ダンスの起動時も、現在のような特定の時に限らず、メモリーリークを監視する 常駐型デバッガーのように常時バックグラウンドで実行することもできるだろう。 ユーザーがログの分析方法を指定できるようになれば、これは検証ツールとして 有効に機能するはずである。 さらに 化されたログと は、一種の となり、その分析の方法に は、データマイニングの方法が使えるかもしれない。これに人工知能の方法など 取り入れて、ガイダンス機能をインテリジェント化することも考えられる。 ? " #$ ? "$$ 非同期メッセージのテスト " 既に開発済みの に基づいた並列動作可能なエンジンを使って、 現在並列動作可能なアクション言語が作成されつつある。この言語を に 移植する上では、テストの仕組みの変更が必要となる。特に、本研究では、モデ ル間の通信に同期メッセージを想定して、実験を行ったが、実用的システムのテ ストには非同期メッセージをサポートしなければならない。 " #$ ) モデルの充実 "$$ では、"$7 プロファイルを定義し、"$7 モデルで を記述している。 ただし、現段階では、拡張したアクション言語 .," でしか を 書けない。しかし、.," 、., ! などで複雑な を簡単にかけるかもしれない。また、.," で記述した と、 ., !、.," との相互変換も考えられる。 84 手順の詳細化 / 現段階の「 を基づいて を書く」というステップを つのステッ プに分けて、ストーリーの概念を導入することが考えられる。ストーリーはシナリ オのようなものであり、 から を書くときに役に立つ。あるストー リーに基づいた が全て成功した場合、該当するストーリーによる のテストケース化が完了する。そのとき、ストーリーは役目を終わるので、たと えばクロスアウトすればよい。一つでも失敗した場合も、該当するストーリーに 明示する。これにより、どれだけの機能がモデルの不正で達成していないか、どれ だけの機能がまだチェックしていないを分かりやすくなるだろう。そのストーリー も を通じて管理すればよい。 "$$ 8; 謝辞 筆者がこの研究を進めるにあたり、理論的基礎から実装に至るまでの全課程にお いて熱心な御指導、御教授をいただきました神戸大学工学部情報知能工学科林晋 教授に心から感謝いたします。 また平素より様々な場面でお世話になりました同じ のメンバー方々に深 く感謝いたします。 >"44 88 参考文献 E / 04F @A = ( /0 " ") 3BB /004 E2* 0/F C 2* ($ ! .,) /00/ E- 04F C 2* . = 3BBA E? 0/F " - -2 (., ) ! 7 >" /00/ E 04F 森健司 ( を用いた分散システム・モデリングツール) 卒業論文， 神戸大学 /004 E" 0;F 佐藤真沙美，( /0 に基づく構造的モデリング) 卒業論文 神戸大学 /00; E F @A = (@ = ) 3BBB /00/ E% 00F % ( M) 3BBB /000 和訳「設計の終焉M」 3BBAAB?7B E" 6:F " 7 "! (#& .) 166: E= 04F ! = $ (., % $! >! #& /0) /004 E 04F " (アジャイルモデリング 公式サイ ト) 3BB ABB BB, /001 /004 89