2011年06月19日
[報告] Enterprise Architectを使ったETロボコンMDD実践
昨日(6/18)、ETロボコンの九州地区において、「Enterprise Architectを使ったETロボコンMDD実践」セミナーを開催しましたので、その概要をご紹介します。
このセミナーでは、MDD(モデル駆動設計開発) の基本的な知識を学び、その後実際にMDDを体験してみることを目的としています。具体的には、Enterprise Architectでモデルを作成し、そこからnxtOSEKのコードを自動生成し、実際にロボットを動かしてみよう、という流れまでを体験します。
このセミナーでは、MDD(モデル駆動設計開発) の基本的な知識を学び、その後実際にMDDを体験してみることを目的としています。具体的には、Enterprise Architectでモデルを作成し、そこからnxtOSEKのコードを自動生成し、実際にロボットを動かしてみよう、という流れまでを体験します。
ただし、時間的な都合もあり、1から全てのモデルを作成してコード生成するのは不可能です。ですので、今回は以下のようなステートマシン図に、状態を追加することにしました。
お題は、タッチセンサを押すとライントレースを実行するというものです。
まず、どのような状態が存在するのかを考えて、状態を配置します。そして、状態間に遷移を追加します。
それぞれの遷移には、トリガ(イベント)を割り当てます。今回は、トリガは4種類(タッチセンサON・タッチセンサOFF・光センサ白検知・光センサ黒検知)を事前に用意しておいて、遷移に割り当てる方式にしました。
そして、アクションは状態のentryアクションのみ、ということにしました。つまり、遷移はイベント発生時のみ(or無条件遷移)、状態にはentryアクションを関連づけるという制約の上での演習です。
例えば、以下のような図になったとします。
(この例での、press_touch_sensorなどが事前に用意されていた、ということです。)
ここで、例えば「右に曲がる」のentryアクションの中身はどうするのでしょうか？
これは、下の画像のように、entryアクションと、操作(C言語での関数)を結びつけることで、その処理の詳細を定義します。
ここで、turnRightなどの操作(関数)の中身は、手作業で記述することになります。ですので、
・どのような状態や遷移があるのかを考え、ステートマシン図などのモデルを記述する「モデル設計チーム」
・nxtOSEKのAPIを利用し、個々のアクションの具体的な実装を考える「実装チーム」
のようにチーム制を取る場合、分業の境目がこの部分になるということです。つまり、モデル設計チームでは、「右に曲がる」「左に曲がる」などの必要な機能要素をモデル作成を通じて洗いだし、実装チームはそれぞれの機能に対応するコードを作成するという分担です。
この、コードの部分は、手作業での作成になります。つまり、Enterprise Architectを利用したMDDの場合には、モデルからの100%のコード生成を想定していません。ロボットの制御など、デバイスに近い部分などは、手作業での実装です。ただ、一般的には、こうした部分は手作業の方が効率的です。
例えば、startingの関数の中身は、以下のように定義されています。Enterprise Architectには、それぞれの操作(関数)のプロパティ画面の中にコードエディタがあり、コード(の断片)を記載できるようになっています。
このコード(の断片)が、モデルから自動生成される部分と合成され、最終的に1つのソースになるということです。今回の例では、ステートマシン図の遷移ルールや、関数を呼び出す部分などはモデルから自動的に生成されます。
今回のセミナーの演習では、この関数についても、事前に用意しました。上記のチーム分業制で言えば、「モデル設計チーム」の疑似体験をした、というイメージです。
とりあえずモデルを作成してみたら、実際にロボットを動かしてみましょう。今回の演習では、Enterprise Architectのメニューから「動作解析」→「ビルド」を実行すると、自動的にビルドするように構成しました。cygwinのウインドウからコマンドで実行しなくても、Enterprise Architect内でビルドできます。
というわけで、コード生成を実行後、ビルドを実行します。ビルドの内容は、下の画面例のように、Enterprise Architectの出力サブウィンドウに表示されます。
そして、NXTをUSBで接続して、Enterprise Architectのメニューから「動作解析」→「配置」を実行することで、ビルドした内容をNXTにダウンロードできます。
上のステートマシン図の内容で実際に動かしてみると、タッチセンサを押すと動作しますが、すぐに倒れてしまいます。つまり、ステートマシン図の内容が間違っているということです。
その場合にはステートマシン図を見ながら考えることも良いのですが、状態遷移表の形式で表示して考えるのも一つの方法です。
すると、上記の表の赤枠の領域、例えば、線上にいるときに、線上(on_the_line)のイベントが発生するとどうなるのか？などの「漏れ」が見つかります。そこで、状態遷移図でもステートマシン図でもどちらでも良いので、不足している内容を埋めていきます。(どちらかで修正すれば、もう片方には自動的に反映されます。)
というわけで、このようなステートマシン図を作成し、コード生成・ビルド・ダウンロードすることで、ライントレースするようになります。(ただ、今回の内容の場合、実際にはライントレースの精度はかなり低いです。)
めでたしめでたし。
なお、セミナーの中では詳しく説明しませんでしたが、クラス図で、タスクとクラス(=ステートマシンを持つもの)の関連づけを行っています。以下の内容は、そのクラス図です。ステレオタイプ<<TASK>>を持つクラスとステートマシン図を持つクラスを依存の関係で結びつけることで、ステートマシンを呼び出すようになっています。
ですので、上の例ではタッチセンサと光センサをまとめて1つのステートマシンにしましたが、以下のように1つのタスクに2つのステートマシンを関連づけ、タッチセンサ側の制御(=動作のON/OFF)を別のステートマシンとして表現することも可能です。場合によっては、複数の<<TASK>>要素と複数のステートマシン図について、依存関係を変えながら、動作を見てみるという検証も可能です。
(依存はドラッグ&ドロップでつなぎ替えができますので、効率的に検証できます。)
なお、上記のように依存で結ぶと4msec間隔でステートマシンを呼び出すところまでは作成したのですが、oilファイルは自動生成しないので、<<TASK>>要素を追加した場合、手作業でoilファイルを修正しなければなりません。
ということを、演習でやりました。実際には、ツールの画面説明・プロジェクトブラウザの内容・操作方法なども説明する必要があるので、持ち時間の3時間では不足気味、という感じでした。また、entryアクションのみに制限したのですが、実際にはdoアクションも利用できるようにする方が簡単だったかも、などの反省点も多く見つかりました。
(今回は、なるべくシンプルになるように、また、自動生成したコードができる限り読みやすくしてMDDの効果が見えるようにするために、独断でさまざまな制約を決めました。)
実際の演習では、人により状態の数や図の内容が異なりました。モデリングに唯一の正解はなく、今回はロボットがライントレースすれば「正解」ということになります。このような場で、「レビュー」ということで何チームかのモデルをプロジェクタで出して、みんなで「共通点」「差異」を共有するようにすると、モデリング力が上がるのではないかと思います。
今回、このような貴重な機会を頂くことができ、個人的にもとても楽しかったです。九州地区の実行委員のみなさまには大変お世話になりました。この場ではありますが、お礼申し上げます。
(特に、窓口的に対応してくださった、Hさん・Uさんには、かなりご迷惑をおかけしました。申し訳ないです。)
補足: 今回のセミナーを実際に受けた方は体感しているかと思いますが、 このMDDを実践するためには、今回の演習前に行った座学での知識・背景の理解が必要です。そのため、上記のnxtOSEK用MDD環境のデータだけで実践することは困難なため、一般公開・配布は行いません。
(Enterprise Architectの評価版・期間限定版にも含まれていません。)
お題は、タッチセンサを押すとライントレースを実行するというものです。
まず、どのような状態が存在するのかを考えて、状態を配置します。そして、状態間に遷移を追加します。
それぞれの遷移には、トリガ(イベント)を割り当てます。今回は、トリガは4種類(タッチセンサON・タッチセンサOFF・光センサ白検知・光センサ黒検知)を事前に用意しておいて、遷移に割り当てる方式にしました。
そして、アクションは状態のentryアクションのみ、ということにしました。つまり、遷移はイベント発生時のみ(or無条件遷移)、状態にはentryアクションを関連づけるという制約の上での演習です。
例えば、以下のような図になったとします。
(この例での、press_touch_sensorなどが事前に用意されていた、ということです。)
ここで、例えば「右に曲がる」のentryアクションの中身はどうするのでしょうか？
これは、下の画像のように、entryアクションと、操作(C言語での関数)を結びつけることで、その処理の詳細を定義します。
ここで、turnRightなどの操作(関数)の中身は、手作業で記述することになります。ですので、
・どのような状態や遷移があるのかを考え、ステートマシン図などのモデルを記述する「モデル設計チーム」
・nxtOSEKのAPIを利用し、個々のアクションの具体的な実装を考える「実装チーム」
のようにチーム制を取る場合、分業の境目がこの部分になるということです。つまり、モデル設計チームでは、「右に曲がる」「左に曲がる」などの必要な機能要素をモデル作成を通じて洗いだし、実装チームはそれぞれの機能に対応するコードを作成するという分担です。
この、コードの部分は、手作業での作成になります。つまり、Enterprise Architectを利用したMDDの場合には、モデルからの100%のコード生成を想定していません。ロボットの制御など、デバイスに近い部分などは、手作業での実装です。ただ、一般的には、こうした部分は手作業の方が効率的です。
例えば、startingの関数の中身は、以下のように定義されています。Enterprise Architectには、それぞれの操作(関数)のプロパティ画面の中にコードエディタがあり、コード(の断片)を記載できるようになっています。
このコード(の断片)が、モデルから自動生成される部分と合成され、最終的に1つのソースになるということです。今回の例では、ステートマシン図の遷移ルールや、関数を呼び出す部分などはモデルから自動的に生成されます。
今回のセミナーの演習では、この関数についても、事前に用意しました。上記のチーム分業制で言えば、「モデル設計チーム」の疑似体験をした、というイメージです。
とりあえずモデルを作成してみたら、実際にロボットを動かしてみましょう。今回の演習では、Enterprise Architectのメニューから「動作解析」→「ビルド」を実行すると、自動的にビルドするように構成しました。cygwinのウインドウからコマンドで実行しなくても、Enterprise Architect内でビルドできます。
というわけで、コード生成を実行後、ビルドを実行します。ビルドの内容は、下の画面例のように、Enterprise Architectの出力サブウィンドウに表示されます。
そして、NXTをUSBで接続して、Enterprise Architectのメニューから「動作解析」→「配置」を実行することで、ビルドした内容をNXTにダウンロードできます。
上のステートマシン図の内容で実際に動かしてみると、タッチセンサを押すと動作しますが、すぐに倒れてしまいます。つまり、ステートマシン図の内容が間違っているということです。
その場合にはステートマシン図を見ながら考えることも良いのですが、状態遷移表の形式で表示して考えるのも一つの方法です。
すると、上記の表の赤枠の領域、例えば、線上にいるときに、線上(on_the_line)のイベントが発生するとどうなるのか？などの「漏れ」が見つかります。そこで、状態遷移図でもステートマシン図でもどちらでも良いので、不足している内容を埋めていきます。(どちらかで修正すれば、もう片方には自動的に反映されます。)
というわけで、このようなステートマシン図を作成し、コード生成・ビルド・ダウンロードすることで、ライントレースするようになります。(ただ、今回の内容の場合、実際にはライントレースの精度はかなり低いです。)
めでたしめでたし。
なお、セミナーの中では詳しく説明しませんでしたが、クラス図で、タスクとクラス(=ステートマシンを持つもの)の関連づけを行っています。以下の内容は、そのクラス図です。ステレオタイプ<<TASK>>を持つクラスとステートマシン図を持つクラスを依存の関係で結びつけることで、ステートマシンを呼び出すようになっています。
ですので、上の例ではタッチセンサと光センサをまとめて1つのステートマシンにしましたが、以下のように1つのタスクに2つのステートマシンを関連づけ、タッチセンサ側の制御(=動作のON/OFF)を別のステートマシンとして表現することも可能です。場合によっては、複数の<<TASK>>要素と複数のステートマシン図について、依存関係を変えながら、動作を見てみるという検証も可能です。
(依存はドラッグ&ドロップでつなぎ替えができますので、効率的に検証できます。)
なお、上記のように依存で結ぶと4msec間隔でステートマシンを呼び出すところまでは作成したのですが、oilファイルは自動生成しないので、<<TASK>>要素を追加した場合、手作業でoilファイルを修正しなければなりません。
ということを、演習でやりました。実際には、ツールの画面説明・プロジェクトブラウザの内容・操作方法なども説明する必要があるので、持ち時間の3時間では不足気味、という感じでした。また、entryアクションのみに制限したのですが、実際にはdoアクションも利用できるようにする方が簡単だったかも、などの反省点も多く見つかりました。
(今回は、なるべくシンプルになるように、また、自動生成したコードができる限り読みやすくしてMDDの効果が見えるようにするために、独断でさまざまな制約を決めました。)
実際の演習では、人により状態の数や図の内容が異なりました。モデリングに唯一の正解はなく、今回はロボットがライントレースすれば「正解」ということになります。このような場で、「レビュー」ということで何チームかのモデルをプロジェクタで出して、みんなで「共通点」「差異」を共有するようにすると、モデリング力が上がるのではないかと思います。
今回、このような貴重な機会を頂くことができ、個人的にもとても楽しかったです。九州地区の実行委員のみなさまには大変お世話になりました。この場ではありますが、お礼申し上げます。
(特に、窓口的に対応してくださった、Hさん・Uさんには、かなりご迷惑をおかけしました。申し訳ないです。)
補足: 今回のセミナーを実際に受けた方は体感しているかと思いますが、 このMDDを実践するためには、今回の演習前に行った座学での知識・背景の理解が必要です。そのため、上記のnxtOSEK用MDD環境のデータだけで実践することは困難なため、一般公開・配布は行いません。
(Enterprise Architectの評価版・期間限定版にも含まれていません。)