　今回は、自作したMDDツールを使ってモデルからコードを生成します。コード生成のみであれば、無償で入手できるものだけで比較的簡単に構築できます。今回は、モデル情報を参照するために「astah* API」、コード生成のためのテンプレートエンジンとして「FreeMaker」を用いてMDDツールを構築しました。

　それでは、前置きはこれくらいにして、前回の続きを進めていきましょう。


	参考（1）：astah* API：
⇒	astah* API

モデリングツール「astah*」を用いて作成したモデル図からモデルの情報を取得するために、「astah* API」が利用できます。astah* APIは、Java言語でモデル情報にアクセスできます。


	参考（2）：FreeMarker：
⇒	FreeMarker

モデルの情報からソースコードを生成するために、テンプレートエンジンとしてオープンソースライブラリである「FreeMarker」が利用できます。ソースコードの固定部分をテンプレートと呼ばれるひな型で定義し、可変部分をモデルから取得した情報で補完して、コンパイル可能なコードとします。

動的モデルの詳細化【1】（振る舞いの論理設計）

　前回、概念クラス図の中で、システムをコントロールする役割を持った自動追従ライントレーサークラスの状態に着目して、ステートマシン図を作成しました。このモデルでは、自動追従ライントレースシステムがどういう状態を持ち、それぞれの状態がどういう遷移をしていくのかが表現されていましたが、それぞれの状態でどのように振る舞うかまでは表現されていませんでした。よって今回は、状態の“内部動作”に着目して、このモデルを詳細化していきます。

図2　自動追従ライントレースシステムのステートマシン図

　図2をご覧ください。各状態について、entry（その状態に遷移した時点で実行される）、do（その状態の間に実行中である）、exit（その状態から出る時点で実行される）アクティビティをそれぞれ必要に応じて書き加えています。

　「スタート待機中」の状態では、まず初期化処理を行い、遷移のためのイベント（タッチセンサが押される）に備えます。走行中のサブ状態である「追従走行中」と「通常走行中」の状態では、それぞれの走行用に必要な初期化を行い、それぞれ要求された機能どおりの走行を行います。「停止中」の状態では、まずスピードをゼロにして、最後に終了処理を行います。

モデルの検証

　さて、先ほど作成したステートマシン図（図2）において、検討漏れはないでしょうか。このような場合、状態遷移表を書いて“ヌケモレ”がないかを確認してみましょう。

　今回は、縦軸にイベント、横軸に状態を並べ、交差する各マスにはそのイベントが発生したときに次に遷移すべき状態名とアクティビティ名を記述する形式で、あり得る遷移を書き加えていきます（図3）。

図3　状態遷移表

　「スタート待機中」からは、タッチセンサ、停止ボタンの各イベントに応じてそれぞれ次の状態へと遷移があります。「追従走行中」「通常走行中」からは、タッチセンサのイベントに応じてそれぞれ次の状態へと遷移がありますが、停止ボタンのイベントではどちらも同じく「停止中」状態に遷移するため、この場合、それぞれのマスを埋めるのではなく親の状態である「走行中」状態のマスの方を埋めます。

　このように状態遷移表で、状態とイベントを対応付けて表を埋めていくことで、遷移の考慮漏れはなさそうだということが分かりました。

動的モデルの詳細化【2】（振る舞いの物理設計）

　ここまでは、プラットフォーム固有の実装（教育用レゴマインドストームNXTなど）に関する制約を受けない抽象的なモデルを扱ってきました。しかし、これからさらに詳細化しようとすると、今回のプラットフォーム固有の実装を考慮する必要が出てきました。よって、ここからは今回のプラットフォーム上で実現することを前提として、モデルをさらに洗練させていきましょう。

図4　「走行中の状態のサブ状態」のステートマシン図

　図4は、先ほど作成したステートマシン図（図2）のうち、走行中の状態のサブ状態に絞って洗練させたものです。今回は、プラットフォームに依存する要素として、C言語で実装を行いますので、各名前もいままでの日本語表記から英語表記に修正しています。

MDDツールを用いたコード生成

　ここまでの作業で、モデルとして十分に洗練させることができました。続いて、作成したモデルからソースコードを生成していきます。今回、コード生成への入力対象とするモデルは、いままで作成したすべてのモデルではなく、最後に作成した「走行中の状態のサブ状態」のステートマシン図（図4）とします。

　なぜこのモデルのみを対象としたかというと、それには2つの理由があります。まず1つ目の理由は、いわゆるシステム開発の上流工程における品質の作り込みにおいては、状態遷移が“キモ”となってくるからです。逆にいうと、状態遷移の分析、設計が最も品質低下を招く要因となりやすいということです。そして、もう1つの理由は、仕様や設計変更の可能性がほかと比べて高い個所であるからです。

　それでは、MDDツールを実行してみましょう。ソフトウェア開発環境である「nxtOSEK」上にMDDツール（注1）を配置して、Cygwinから「make gen」を実行します。

※注1：ツール本体および今回開発したソフトウェアは、こちら「AutoFollower」からダウンロードできます（圧縮されているので任意の解凍ソフトで展開して利用してください）。詳しい使い方についてはREADME.txtをご覧ください。