モデル駆動型開発の実践例（代表著者）京都情報大学院大学 准教授 江見 圭司

MDD ロボットチャレンジとは
京都コンピュータ学院と京都情報大学院大学では，高度なモ◆

1. はじめに◆1.1. MDDロボットチャレンジへの参加

デル駆動型開発を身につけるために，株式会社ヒューマンエン
ジニアリングアンドロボティックスと産学連携で，情報処理学

京都コンピュータ学院（KCG）
・京都情報大学院大学（KCGI）
・会の組込みシステム研究会が主催している MDD ロボットチャ

株式会社ヒューマンエンジニアリングアンドロボティックス

レンジという大会に参加した。この大会では，小型飛行船を制（HERO 社）の共同チームは，2007 年，2008 年に続き，MDD

御するソフトウェアをモデル駆動開発に従って開発・実践・研ロボットチャレンジへ参加。チーム名は「京魂英雄（きょうこ究する機会と，組込み技術者育成の場を提供している大会であんひーろー）」とした。

る。MDD（Model Driven Development）に基づいた開発を行い，用いたモデルと飛行競技をコンテスト形式で競うのである。と◆

1.2. プロジェクト運営，参加メンバと役割についてころで MDD とは，明示的な論理にもとづいてソフトウェアモ
デルを変換することの繰り返しで最終ソフトウェアを生成する開発方法である。

2007 年の大会では，短期間での準備・開発が課題となっていた。そこで，日本語プログラミング言語「ドリトル」を使用

審査基準はモデルと競技の２つからなる。

し，プログラミング言語習得に費やす時間と，開発工程の短縮

モデル図は，本プロジェクトでは UML を用いた。この場合，を実現した。

システムに要求する機能はユースケース，構造はクラス図（必2008 年は，2007 年の運営との比較を行うため，プロジェ

要に応じてオブジェクト図），さらにシステムの構造をシーケクトの管理方法や使用するプログラミング言語をＣ＃として，ンス図で表現する必要がある。また，作成したモデルからコー

ドリトルの比較を行った。

ディングに至るまでのコード変換ルールを定めることも審査基準に含まれる。
あともう一点は，飛行競技である。” 自動航法競技 ” であり，これは飛行船を出発地点から規定の通過点（Way Point 1，

2009 年は，2007 年，2008 年の結果をふまえたプロジェ
クト運営を行った。2007 年で使用したドリトルからシリアルポート通信を強化した新バージョンが登場したので，それを採用した。

Way Point 2 といい，風船がそれぞれの地点に浮いている）を2010 年は開発言語には C# を用いた。2008 年でも C# を用

通過しながら目的地点に着陸させる一連の動作を自動制御で行いて開発したが，モデルの改善を行い，それに伴ってソフトウェ

うことを競うものである。離陸，第一通過点（Way Point 1），

アも改善されたと考えている。また，地上局の超音波センサ

第二通過点（Way Point 2），着陸，ゴールへの着陸，制御画面とのやりとりの改善を行って位置測定の精度を上げることや，の表示の６つの部分点の合計で競う。着陸とゴールへの着陸がGUI の改善を行った。

異なるのは，ゴールへの着陸が困難であるため，とりあえず，また，モデリングには前年度までは JUDE
（現 Astah*）を用い

規定時間内に着陸しただけでも部分点が取得できるように配慮たが，モデル→コーディングまでのトレーサビリティを考慮しされているのである。

た結果，
Microsoft Visio 2010 と Visial Studio 2010 を利用した。

我々のチームは 2007 年から 2010 年まで４回出場した。そ表 1 にメンバーの一覧と，それぞれの役割について示す。

れで，2010 年には IBM 大和研究所のチームが総合一位で，我々KCG・KCGI の学生は，プログラミングやモデリング，プロジェ

は総合二位に輝いた。

クトマネジメントなどを実践して学ぶことをこのコンテストの

ところが，この大会は残念ながら，2010 年で使命を終えて参加目的としている。HERO 社は，制御機器やファームウェア

終了した。そこで本稿では，そのときに作成したモデル図をこソフトウェアを担当した。また，2009 年と同様，資料の共有

こに残すことにして，奥田茂人によるレポート「MDD ロボッのために MS 社 Skydrive を採用したため，資料などをそのま

トチャレンジを終えて」を末尾に追加した。

ま引き継ぐことができた。
プロジェクト運営において以前との違いは，開発開始時期や実際の開発スケジュールが変化したこと，プロジェクト開始以降，メンバーの脱退や入れ替わりが多く，途中段階で役割分担などの変更を要した。そのため，プロジェクト運営にあたって
は臨機応変な対応が必要であった。しかし，過去のドキュメン47◆

2.3. シナリオ（規定動作）◆

2.4. シナリオ（飛行競技）

前述のユースケースを元に，ユースケース後のシナリオを明

前述のユースケースを元に，ユースケース後のシナリオを明確にした。基本シナリオは飛行船の基本的な規定動作であり，確にした。以下の記述については「2.3 シナリオ ( 規定動作 )」例外シナリオは，基本シナリオの①～④がそれぞれ失敗した際と同様である。

の「競技のやり直し」の場合に発生する。なお，規定動作に関しては自動航行データファイルに記述してあるものを読み込

基本シナリオ

み，実現するものとする。

①飛行船が離陸する②基地局が目的地を設定する

基本シナリオ③飛行船が目的地に向かう①・飛行船が離陸する。

④飛行船が第１立ち寄り点を通過する②・飛行船が規定通り上昇する。

⑤飛行船が第２立ち寄り点を通過する③・ チャレンジャがホバリングと，高さ，角度測定の申告を⑥飛行船が目的地に着陸するする。

表 1 メンバーと役割・飛行船が規定通りホバリングする。

例外シナリオ１

トの管理を徹底した結果，プロジェクトの引き継ぎは比較的ス

・飛行船が測定結果（高さ・角度）を基地局に送信する。

飛行船がエリア外に離脱した場合，復帰できなければチャレン

ムーズに行われて，プロジェクトは継続された。

・基地局が，測定結果（高さ・角度）を画面に表示する。

ジャがやり直しの申告をし，・チャレンジャが測定結果（高さ・角度）を確認する。

「2.3 シナリオ（規定動作）」の基本シナリオの①から開始する。

◆

2. 機能

◆

2.1. マインドマップとユースケース以前④・飛行船が位置測定可能な場所にいる場合，チャレンジャが，位置測定の申告をする。

ユースケース図を考えるにあたって，まずは MDD ロボット

例外シナリオ２
飛行船が風に流されてエリア外に離脱した場合，復帰できなけ

・地上局が，測定結果（位置）を基地局に送信する。

ればチャレンジャが・基地局が，測定結果（位置）を画面に表示する。

やり直しの申告をし，「2.3 シナリオ（規定動作）」の基本シナ・チャレンジャが測定結果（位置）を確認する。

リオの①から開始する。

チャレンジ 2010 について，図 1 のマインドマップを作成した。

例外シナリオ３

これによって，MDD ロボットチャレンジの 2010 の全体像を例外シナリオ１

飛行船と電波の送受信ができない場合，チャレンジャがやり直

掴むと同時に，ユースケース図の記述の参考になった。

①が失敗した場合，チャレンジャがやり直しの申告をし，しの申告をし，

基本シナリオの①から開始する。

「2.3 シナリオ（規定動作）」の基本シナリオの①から開始する。

図 2 ユースケース図

規定動作・飛行競技のミスユースケースを図 3 に示す。ユー

例外シナリオ２

スケース同様に，「チャレンジャ」アクターを記述し，人間（チャ①は基本シナリオ通りレンジャ）の手によって行われる「停止」と「やり直し」の動②・飛行船が上昇しない場合，チャレンジャがやり直しを申告

作も表現している。

し，基本シナリオの①→②→③→④の順に進める。
例外シナリオ３①，②は基本シナリオ通り③・飛行船がホバリングしない，またはチャレンジャが測定結◆

2.5. 飛行戦略
前述のユースケースを元に，ユースケース後のシナリオを明確にした。
図 4 飛行戦略

果を確認できない場合，チャレンジャがやり直しを申告し，基本シナリオの①→③→④の順に進める。
例外シナリオ 4-a①，②，③は基本シナリオ通り。
④・飛行船が，位置測定不可能な位置にいた場合，飛行可能な
図 1 マインドマップ

位置に移動する。
・チャレンジャが，位置測定の申告をする。

◆

2.2. ユースケース

・地上局が，測定結果（位置）を基地局に送信する。
・基地局が，測定結果（位置）を画面に表示する。
・チャレンジャが測定結果（位置）を確認する。

規定動作と飛行競技についてのユースケースを図 2 に示す。
「競技をやり直す」動作があるため，アクターは飛行船や地上局などのハードウェア以外に，「チャレンジャ」を加えた。チャ
レンジャは競技のやり直しの判断と，データ画面表示の測定結果の確認を行う。

48

図 3 ミスユースケース図

図 5 下降気流の予想

例外シナリオ 4-b①，②，③は基本シナリオ通り。

以上のユースケースやミスユースケースは，飛行船だけでな④・飛行船が位置測定可能な場所にいるが，チャレンジャが測く，ライトレースの走行体である競技でも応用できるように考定結果を確認できない場合，チャレンジャがやり直しを申告し，えている。つまり再利用可能性は高い。

基本シナリオの①→④の順に進める。

49

◆2.3. シナリオ（規定動作）◆

2.4. シナリオ（飛行競技）

前述のユースケースを元に，ユースケース後のシナリオを明

前述のユースケースを元に，ユースケース後のシナリオを明確にした。基本シナリオは飛行船の基本的な規定動作であり，確にした。以下の記述については「2.3 シナリオ ( 規定動作 )」例外シナリオは，基本シナリオの①～④がそれぞれ失敗した際と同様である。

の「競技のやり直し」の場合に発生する。なお，規定動作に関しては自動航行データファイルに記述してあるものを読み込

基本シナリオ

み，実現するものとする。

①飛行船が離陸する②基地局が目的地を設定する

基本シナリオ③飛行船が目的地に向かう①・飛行船が離陸する。

④飛行船が第１立ち寄り点を通過する②・飛行船が規定通り上昇する。

⑤飛行船が第２立ち寄り点を通過する③・ チャレンジャがホバリングと，高さ，角度測定の申告を⑥飛行船が目的地に着陸するする。

表 1 メンバーと役割・飛行船が規定通りホバリングする。

例外シナリオ１

トの管理を徹底した結果，プロジェクトの引き継ぎは比較的ス

・飛行船が測定結果（高さ・角度）を基地局に送信する。

飛行船がエリア外に離脱した場合，復帰できなければチャレン

ムーズに行われて，プロジェクトは継続された。

・基地局が，測定結果（高さ・角度）を画面に表示する。

ジャがやり直しの申告をし，・チャレンジャが測定結果（高さ・角度）を確認する。

「2.3 シナリオ（規定動作）」の基本シナリオの①から開始する。

◆

2. 機能

◆

2.1. マインドマップとユースケース以前④・飛行船が位置測定可能な場所にいる場合，チャレンジャが，位置測定の申告をする。

ユースケース図を考えるにあたって，まずは MDD ロボット

例外シナリオ２
飛行船が風に流されてエリア外に離脱した場合，復帰できなけ

・地上局が，測定結果（位置）を基地局に送信する。

ればチャレンジャが・基地局が，測定結果（位置）を画面に表示する。

やり直しの申告をし，「2.3 シナリオ（規定動作）」の基本シナ・チャレンジャが測定結果（位置）を確認する。

リオの①から開始する。

チャレンジ 2010 について，図 1 のマインドマップを作成した。

例外シナリオ３

これによって，MDD ロボットチャレンジの 2010 の全体像を例外シナリオ１

飛行船と電波の送受信ができない場合，チャレンジャがやり直

掴むと同時に，ユースケース図の記述の参考になった。

①が失敗した場合，チャレンジャがやり直しの申告をし，しの申告をし，

基本シナリオの①から開始する。

「2.3 シナリオ（規定動作）」の基本シナリオの①から開始する。

図 2 ユースケース図

規定動作・飛行競技のミスユースケースを図 3 に示す。ユー

例外シナリオ２

スケース同様に，「チャレンジャ」アクターを記述し，人間（チャ①は基本シナリオ通りレンジャ）の手によって行われる「停止」と「やり直し」の動②・飛行船が上昇しない場合，チャレンジャがやり直しを申告

作も表現している。

し，基本シナリオの①→②→③→④の順に進める。
例外シナリオ３①，②は基本シナリオ通り③・飛行船がホバリングしない，またはチャレンジャが測定結◆

2.5. 飛行戦略
前述のユースケースを元に，ユースケース後のシナリオを明確にした。
図 4 飛行戦略

果を確認できない場合，チャレンジャがやり直しを申告し，基本シナリオの①→③→④の順に進める。
例外シナリオ 4-a①，②，③は基本シナリオ通り。
④・飛行船が，位置測定不可能な位置にいた場合，飛行可能な
図 1 マインドマップ

位置に移動する。
・チャレンジャが，位置測定の申告をする。

◆

2.2. ユースケース

・地上局が，測定結果（位置）を基地局に送信する。
・基地局が，測定結果（位置）を画面に表示する。
・チャレンジャが測定結果（位置）を確認する。

規定動作と飛行競技についてのユースケースを図 2 に示す。
「競技をやり直す」動作があるため，アクターは飛行船や地上局などのハードウェア以外に，「チャレンジャ」を加えた。チャ
レンジャは競技のやり直しの判断と，データ画面表示の測定結果の確認を行う。

48

図 3 ミスユースケース図

図 5 下降気流の予想

例外シナリオ 4-b①，②，③は基本シナリオ通り。

以上のユースケースやミスユースケースは，飛行船だけでな④・飛行船が位置測定可能な場所にいるが，チャレンジャが測く，ライトレースの走行体である競技でも応用できるように考定結果を確認できない場合，チャレンジャがやり直しを申告し，えている。つまり再利用可能性は高い。

基本シナリオの①→④の順に進める。

49

3. 構造◆つぎに，機能要件を満たしているかどうか確かめるための図を添えておく。

3.1. ユースケースからクラス図へ◆

図 8 ユースケースとクラス図の対応

ユースケース図および，ユースケース後のシナリオを作成した後，構造の段階として，クラス図が必要となる。ユースケースを実現するためのクラスを求めるために，ロバストネス図の記述方法を利用した。（図 6 参照）
バウンダリとして識別したユースケース：「データ画面表示」「状態取得」「データ画面表示」は「飛行船データ表示 GUI」クラスとし，「状態取得」のユースケースにおいては，クラスを「飛行船状態」

図 6 ユースケース図からクラス

3.2. クラス図◆と「飛行船平面座標」に分割した。
コントロールとして識別したユースケース：「自動航行」「モーター設定」「自動航行」は「飛行船モーター制御」クラスとし，「モーター設定」は「飛行船モーター状態」クラスとした。
エンティティとして識別したユースケース：「自動航行デー
タファイル」「自動航行データファイル」は，「自動航行データ」クラスとした。

前節の分析から図 7 のようなクラスを分析レベルで設計した。
飛行船に関するクラス（うすい青色）として，「飛行船モーター状態」クラス，「飛行船状態」クラスがつくった。
地上局に関するクラス（うすい橙色）として，「飛行船平面座標」クラスをつくった。
飛行船制御に関するクラス（うすい黄緑色）として，「自動航行データ」クラス，「飛行船モーター制御」クラスをつくった。

◆

3.3. UMLクラス図から C＃への変換
メンバー変数の値の取得 (get)・変更 (set) を行うためのメソッドであるアクセサー (accessor) を必要とする。C++ や Java などの言語ではメンバー変数の数だけアクセサーが存在する場合もある。
クラス内部側ではメンバ変数の可視性はプライベートにしておいて，アクセサーというメソッドを通して取得 (get)・変更(set) を行う方がよい。一方，クラス利用側からすると，メンバー
変数に値を直接代入するほうが見た目がすっきりする。
このような理由から，C# では，クラス内部から見るとメソッドのように振る舞い，クラス利用側から見るとメンバー変数の

図 9 シーケンス図ように振る舞う「プロパティ」という機能がある。本プロジェ
クトでは，「プロパティ」という機能を前提にしているため，取得 (get)・変更 (set) などのアクセサーはクラス図から省いている。
以上のことを前提にして，分析レベルのクラス図から設計レ
図 7 分析レベルのクラス図

表示部分に関しては「飛行船データ表示 GUI」クラスをつくった。

ベルのクラス図へ変換して，C# のコーディングを行った。

地点，第１，２立ち寄り地点，着陸地点など，自動航行デー
タファイルに設定された移動先のことを指す。
・モーター出力値算出では，目標地点情報と飛行船状態情報を元に設定値を算出する。この時，ミスユースケース状態が◆4. 振る舞い◆

4.1. シーケンス図とステートチャート図

クラスにデータを渡す際には C# の event を使用しデータをやり取りする。

シーケンス図に関する補足説明を追加する。
・「loop: 目的地点に向かう」の目的地点とは，規定動作を行う

発生しても，正常状態に復帰する方法はユースケース状態のモーター出力値算出方法と同一である。よって，ミスユース
ケースはシーケンス図に表れない。

・C# ではメンバー変数の値の取得 (get)・変更 (set) を行うため
図 7 において以下の注意点がある。
・「飛行船モータ制御」クラスから「飛行船データ表示 GUI」

50のメソッドはプロパティで表現できるのでそちらを使用する（次節参照）。

シーケンス図について図 9 に示す。

次に，飛行船モーター制御クラスのオブジェクトのステート
チャート図を示す。

51

3. 構造◆つぎに，機能要件を満たしているかどうか確かめるための図を添えておく。

3.1. ユースケースからクラス図へ◆

図 8 ユースケースとクラス図の対応

ユースケース図および，ユースケース後のシナリオを作成した後，構造の段階として，クラス図が必要となる。ユースケースを実現するためのクラスを求めるために，ロバストネス図の記述方法を利用した。（図 6 参照）
バウンダリとして識別したユースケース：「データ画面表示」「状態取得」「データ画面表示」は「飛行船データ表示 GUI」クラスとし，「状態取得」のユースケースにおいては，クラスを「飛行船状態」

図 6 ユースケース図からクラス

3.2. クラス図◆と「飛行船平面座標」に分割した。
コントロールとして識別したユースケース：「自動航行」「モーター設定」「自動航行」は「飛行船モーター制御」クラスとし，「モーター設定」は「飛行船モーター状態」クラスとした。
エンティティとして識別したユースケース：「自動航行デー
タファイル」「自動航行データファイル」は，「自動航行データ」クラスとした。

前節の分析から図 7 のようなクラスを分析レベルで設計した。
飛行船に関するクラス（うすい青色）として，「飛行船モーター状態」クラス，「飛行船状態」クラスがつくった。
地上局に関するクラス（うすい橙色）として，「飛行船平面座標」クラスをつくった。
飛行船制御に関するクラス（うすい黄緑色）として，「自動航行データ」クラス，「飛行船モーター制御」クラスをつくった。

◆

3.3. UMLクラス図から C＃への変換
メンバー変数の値の取得 (get)・変更 (set) を行うためのメソッドであるアクセサー (accessor) を必要とする。C++ や Java などの言語ではメンバー変数の数だけアクセサーが存在する場合もある。
クラス内部側ではメンバ変数の可視性はプライベートにしておいて，アクセサーというメソッドを通して取得 (get)・変更(set) を行う方がよい。一方，クラス利用側からすると，メンバー
変数に値を直接代入するほうが見た目がすっきりする。
このような理由から，C# では，クラス内部から見るとメソッドのように振る舞い，クラス利用側から見るとメンバー変数の

図 9 シーケンス図ように振る舞う「プロパティ」という機能がある。本プロジェ
クトでは，「プロパティ」という機能を前提にしているため，取得 (get)・変更 (set) などのアクセサーはクラス図から省いている。
以上のことを前提にして，分析レベルのクラス図から設計レ
図 7 分析レベルのクラス図

表示部分に関しては「飛行船データ表示 GUI」クラスをつくった。

ベルのクラス図へ変換して，C# のコーディングを行った。

地点，第１，２立ち寄り地点，着陸地点など，自動航行デー
タファイルに設定された移動先のことを指す。
・モーター出力値算出では，目標地点情報と飛行船状態情報を元に設定値を算出する。この時，ミスユースケース状態が◆4. 振る舞い◆

4.1. シーケンス図とステートチャート図

クラスにデータを渡す際には C# の event を使用しデータをやり取りする。

シーケンス図に関する補足説明を追加する。
・「loop: 目的地点に向かう」の目的地点とは，規定動作を行う

発生しても，正常状態に復帰する方法はユースケース状態のモーター出力値算出方法と同一である。よって，ミスユース
ケースはシーケンス図に表れない。

・C# ではメンバー変数の値の取得 (get)・変更 (set) を行うため
図 7 において以下の注意点がある。
・「飛行船モータ制御」クラスから「飛行船データ表示 GUI」

50のメソッドはプロパティで表現できるのでそちらを使用する（次節参照）。

シーケンス図について図 9 に示す。

次に，飛行船モーター制御クラスのオブジェクトのステート
チャート図を示す。

51

ング上では規定動作を行う地点，第１，２立ち寄り地点，着陸データを受信すると受信イベントが発生するので，一旦データいて行う。

地点という概念はない。あくまでも設定された目標地点に向かを格納する。

地上局側が受信したデータはそのままでは使用することができうことを繰り返すのみである。以上から，各チェックポイント

飛行船の状態の更新 ( 制御データの送信 ) は受信してすぐではないので，一旦格納する。

の位置が変更，あるいは増減した場合でもソースコード上の変なく，決まった間隔時間で定期的に実行されるようにしている。

更新処理でデータを正規化し，過去データと比較して有効な現更は一切必要ない。

更新処理では以下のような処理を行っている。

在の座標を決定する。

また，ミスユースケース状態が発生した場合でも，飛行船の図 14 更新処理のフローチャート

航行方法はユースケース状態の場合と同じため，プログラム上◆

6. メトリックスにミスユースケースのパターンは存在しない。これはどのような状態であっても，モーター出力値の計算方法は同一だからで

MDD ロボットチャレンジ 2010 では，2009 年までの資源ある。

を活用してプロジェクトを遂行した。図 16 に今回のプロジェ
クトの開発に関するガントチャートを示す。モデリングの知識◆

5. ハードウェアのシステム構成とソフトウェア

は 4 ～ 7 月の間に KCGI で開講された「オブジェクト指向シス
テム設計」の講義にて修得した。C# プログラミングの知識は，

図 10 飛行船モーター制御クラスのオブジェクトのステートチャート図◆

4.2. UMLシーケンス図から C＃への変換◆

5.1. 基地局

チーム内で勉強会を行い，修得に努めた。
また，ミーティングの日程と活動内容に関して図 17 に示本システムはフロートデイで説明された飛行船ハードウェア

す。2009 年に引き続き，Skype を利用したオンラインでのミー

構成概要を基本としている。
以下，各構成物について，記述する。

ティングも利用した。これまでは活動開始時期が比較的遅く，

シーケンス図から C# のソースコードへの変換方法の例を記載する。競技には直接関連がないが，UML からソースコード

H/W：PC（OS : Windows7 64bit），ゲームパッド

夏期休暇中の 8 月に集中して活動が行われることが多かった。

開 発 環 境：Microsoft Visual Studio 2010，Microsoft

2010 年は活動開始時期が早かったが，実際に開発を手がけ始XNA4.0

めたのは 2009 年と同じ時期の 6 月以降である。また，8 月にへ変換する際の手順の参考とする。
本シーケンス図においては自動航行データファイルに設定さ

主に Visual Studio 2010 及び C# 言語を使用し，飛行船の制れた目標地点に到達することを繰り返すことにより，最終的な御を行う。制御に必要なセンサ情報は，RfMPU-5H および US_

着陸地点に到達するようになっている。そのため，プログラミ

MPU-5H で通信して取得する。

1. 格納したデータを正規化する。

空白の期間が生じている。開始時期が早くある程度の準備が

2. 正規化されたデータから現在の状態を判断し，データ上の整っていたため，プロジェクトの遂行に致命的な支障をきたす

モータを制御する。

ことはなかったが，今後の改善点としたい。

3. データ上のモーターの値を送信用データに変換。
4. 送信用データを RfMPU-5H に送信する。
データの送信漏れを考え，モーターの値の変更が無い場合でも図 11 管制プログラム

データを送信する。
正常にデータを受け取ったかどうかは，受信データから判別す

図 16 ガントチャート（L →勉強会や，講義を受けて知識を修得した）ることができるが，それでは遅いのというのも理由のひとつである。
◆

5.3. 飛行船配布されたセット（Haluna-5H） を 基 本 と して使用。
プロペラの周りにフードを付ける，左右のプロペラの図 17 ミーティング日程（On → Skype を用いたオンラインミーティング）

間の幅を拡げるなど，安全性，安定性などを向上させる改造を行っている。
ゲームパッドは手動制御を行う場◆

5.2. Rf_MPU◆

図 15 改造部の写真

5.4. US_MPU

図 18 モデル図レビュー・修正の回数 (MDD ロボットチャレンジ 2009 と 2010 の比較 )合に使用する。
ゲームパッドを使用する際には飛行船が現在どの辺りにいるのか判断するためのデータを送Microsoft XNA 4.0 の ク ラ ス を 使

H/W は配布されたものを使用し，データの送受信は Visual

信する。

用する。

Studio の Serial Port コントローラクラスを用いて行う。

H/W は配布されたものを使用し，データの送受信は RfMPU-

図 12 ゲームパッド (Xbox360 コントローラ )52

飛行船と基地局間の通信を中継する。

図 13 Serial Port コントローラクラス

モデル図の作成に費やしたレビューおよび修正の回数を図18 に示す。

5H 同様，Visual Studio の Serial Port コントローラクラスを用53

ング上では規定動作を行う地点，第１，２立ち寄り地点，着陸データを受信すると受信イベントが発生するので，一旦データいて行う。

地点という概念はない。あくまでも設定された目標地点に向かを格納する。

地上局側が受信したデータはそのままでは使用することができうことを繰り返すのみである。以上から，各チェックポイント

飛行船の状態の更新 ( 制御データの送信 ) は受信してすぐではないので，一旦格納する。

の位置が変更，あるいは増減した場合でもソースコード上の変なく，決まった間隔時間で定期的に実行されるようにしている。

更新処理でデータを正規化し，過去データと比較して有効な現更は一切必要ない。

更新処理では以下のような処理を行っている。

在の座標を決定する。

また，ミスユースケース状態が発生した場合でも，飛行船の図 14 更新処理のフローチャート

航行方法はユースケース状態の場合と同じため，プログラム上◆

6. メトリックスにミスユースケースのパターンは存在しない。これはどのような状態であっても，モーター出力値の計算方法は同一だからで

MDD ロボットチャレンジ 2010 では，2009 年までの資源ある。

を活用してプロジェクトを遂行した。図 16 に今回のプロジェ
クトの開発に関するガントチャートを示す。モデリングの知識◆

5. ハードウェアのシステム構成とソフトウェア

は 4 ～ 7 月の間に KCGI で開講された「オブジェクト指向シス
テム設計」の講義にて修得した。C# プログラミングの知識は，

図 10 飛行船モーター制御クラスのオブジェクトのステートチャート図◆

4.2. UMLシーケンス図から C＃への変換◆

5.1. 基地局

チーム内で勉強会を行い，修得に努めた。
また，ミーティングの日程と活動内容に関して図 17 に示本システムはフロートデイで説明された飛行船ハードウェア

す。2009 年に引き続き，Skype を利用したオンラインでのミー

構成概要を基本としている。
以下，各構成物について，記述する。

ティングも利用した。これまでは活動開始時期が比較的遅く，

シーケンス図から C# のソースコードへの変換方法の例を記載する。競技には直接関連がないが，UML からソースコード

H/W：PC（OS : Windows7 64bit），ゲームパッド

夏期休暇中の 8 月に集中して活動が行われることが多かった。

開 発 環 境：Microsoft Visual Studio 2010，Microsoft

2010 年は活動開始時期が早かったが，実際に開発を手がけ始XNA4.0

めたのは 2009 年と同じ時期の 6 月以降である。また，8 月にへ変換する際の手順の参考とする。
本シーケンス図においては自動航行データファイルに設定さ

主に Visual Studio 2010 及び C# 言語を使用し，飛行船の制れた目標地点に到達することを繰り返すことにより，最終的な御を行う。制御に必要なセンサ情報は，RfMPU-5H および US_

着陸地点に到達するようになっている。そのため，プログラミ

MPU-5H で通信して取得する。

1. 格納したデータを正規化する。

空白の期間が生じている。開始時期が早くある程度の準備が

2. 正規化されたデータから現在の状態を判断し，データ上の整っていたため，プロジェクトの遂行に致命的な支障をきたす

モータを制御する。

ことはなかったが，今後の改善点としたい。

3. データ上のモーターの値を送信用データに変換。
4. 送信用データを RfMPU-5H に送信する。
データの送信漏れを考え，モーターの値の変更が無い場合でも図 11 管制プログラム

データを送信する。
正常にデータを受け取ったかどうかは，受信データから判別す

図 16 ガントチャート（L →勉強会や，講義を受けて知識を修得した）ることができるが，それでは遅いのというのも理由のひとつである。
◆

5.3. 飛行船配布されたセット（Haluna-5H） を 基 本 と して使用。
プロペラの周りにフードを付ける，左右のプロペラの図 17 ミーティング日程（On → Skype を用いたオンラインミーティング）

間の幅を拡げるなど，安全性，安定性などを向上させる改造を行っている。
ゲームパッドは手動制御を行う場◆

5.2. Rf_MPU◆

図 15 改造部の写真

5.4. US_MPU

図 18 モデル図レビュー・修正の回数 (MDD ロボットチャレンジ 2009 と 2010 の比較 )合に使用する。
ゲームパッドを使用する際には飛行船が現在どの辺りにいるのか判断するためのデータを送Microsoft XNA 4.0 の ク ラ ス を 使

H/W は配布されたものを使用し，データの送受信は Visual

信する。

用する。

Studio の Serial Port コントローラクラスを用いて行う。

H/W は配布されたものを使用し，データの送受信は RfMPU-

図 12 ゲームパッド (Xbox360 コントローラ )52

飛行船と基地局間の通信を中継する。

図 13 Serial Port コントローラクラス

モデル図の作成に費やしたレビューおよび修正の回数を図18 に示す。

5H 同様，Visual Studio の Serial Port コントローラクラスを用

53

参考文献

[18]

林田 幸司 , 國正 聡 ,「失敗事例から学ぶ UML システム

では米山君のみが正規メンバーという驚くべき状態でした。

存在する難所の性質を逆手に取るという戦略でした。

開発の鍵」（ソフトリサーチセンター，2008）

MDDロボットチャレンジ[19]

桐越 信一 , 国正 聡 , 竹政 昭利 , 照井 康真 , 橋本 大輔 ,そして，いよいよ大会当日がやってきます。東京へは先生を[1]「UML モデリング教科書 UML モデリング L2 第 2 版」
（翔泳社，

引率者として，米山君と高瀬さん，それに私の 4 人で赴きまhttp://sdlab.sys.wakayama-u.ac.jp/mdd2009/2008）した。10 月 26 日の昼ごろに到着し，午後から大会前日の調

[2]

[20]

整飛行を行う予定でした。

MDD ロボットチャレンジ
社団法人情報処理学会，「MDD ロボットチャレンジ 2004

竹政 昭利 ,「[ 改訂版 ] UML モデリング技能認定試験 <産学連携による組み込みソフトウェア開発の実践」（社団法人

入門レベル (L1)> 問題集 -UML2.0 対応」（技術評論社，2007）

情報処理学会，2005）

[21]

[3]

社団法人情報処理学会，「MDD ロボットチャレンジ 2005

運営委員会で用意されていたヘリウムを風船に注入してもらってチームに戻ってくると，先生が皆を廊下へ連れ出しまし株式会社チェンジビジョン社 JUDE/Community

た。

http://jude.change-vision.com/jude-web/index.html

産学連携によるモデルベース組み込み開発の実践」（社団法人

C#，言語関連

情報処理学会，2006）

[22]

[4]

Jay Hilyard,Stephen Teilhet, 鈴木 幸敏 ( 翻訳 )，「C# クッ

写真 1 百万遍キャンパスの教室の天井を飛ぶモデル飛行船「もちろん。データの変化率を比べればいいんですよ」

クブック 第 3 版」
（オライリージャパン，2008）「よし，それじゃ教室に運んで飛ばしてみよう」

http://www.ertl.jp/ESS/2008/mdd/file/MDDchallenge2008_[23]

Jesse Liberty, 首藤 一幸 ( 翻訳 ), 鈴木 幸敏 ( 翻訳 ), 情報

風船にヘリウムを詰め込む作業が終了すると，いよいよ飛行

データから計算した変化率にどのくらい差異があるかを比較す

system-requlation_sheet.pdf

技研 ( 翻訳 ) ，「プログラミング C# 言語解説 第 3 版 」（オラ

船を飛ばす準備に取り掛かります。大会当日は自動航法プログ

るわけです。データを採取した環境が異なっていても，飛行船[5]

イリージャパン，2004）

ラムで動かすことになっていますが，開発中はゲーム機のコンが正しく動いた環境で得られた変化率に合うようにパラメータ[24]

トローラで動かすように変更されていました。そして，米山君を調整すれば，本番でも想定通りに動くはずというわけです。

ＭＤＤロボットチャレンジ 競技仕様書

高橋修司，中村州男，江見圭司ほか，「ドリトルを用いたモデル化・シミュレーション・オブジェクト指向開発の自学自習実践」第 94 回コンピュータと教育研究発表会，（2008）

UML モデルをどうやって C 言語に落とし込むか

http://monoist.atmarkit.co.jp/fembedded/robocon/
etrobo06/road03/road03a.html

プロジェクトマネジメントが動作試験のため飛行船を離陸させます。

あらかじめ大学院で収集したデータの変化率と，会場で得た

こうして試験は順調に進めることができたのですが，全く想「おお，ほんまに飛んだ！」像していなかったところで問題が発生してしまいます。

私は，このとき初めて飛んでいる飛行船を目の当たりにしま「先生，えっと，競技に出られないかもしれないです」

その他した。確かに飛ぶということは知っていましたが，実際に目の標準を実践で活かす」（日経 BP 社，2003）[25]

当たりにするとやはり感動します。

この大会の出場枠には，大きく分けてソフトウェア部門と[7]

http://www.atmarkit.co.jp/im/carc/serial/extend/11/11a.html「あ，次俺も動かしてみる！」

ハードウェア部門の 2 つがあります。私はこのとき初めて知っ[6]

岡村正司，「徹底解説 ! プロジェクトマネジメント―国際
金子則彦，「プロジェクトマネージャ完全教本 2009 年版」

キミの設計に「トレーサビリティ」はあるか( 日本経済新聞出版社，2009)[8]

Project Management Institute，「プロジェクトマネジメン

ト知識体系ガイド第 3 版」（Project Management Inst，2005）[9]

Kim Heldman，PMI 東 京 支 部 ( 翻 訳 ) ，「PMP 教 科 書

Project Management Professional 第 3 版」( 翔泳社 ,2006)
[10]

江見
Emi

圭司
Keiji

経歴はジャーナル 28 ページに掲載。

「え？！米山君，なんで？」やはり，こういうものは触りたくなるものです。私も動かしたのですが，私達のチームは機体改造が禁止されているソフトてみましたが，子供の頃に触ったことのあるラジコンカーのノウェア部門でエントリーしていたそうです。にもかかわらず，

リでとても懐かしかったです。思わず時を忘れて遊んでしまい

私たちは前日まで改造された機体を使用して試験をしていましました。過去にハマってひたすら飛行船と戯れていたメンバー

た。

がいたらしいですが，その気持ちを初めて理解できました。

「米山君，それなら予備機を使えばええやろ。あれ，出して」

Craudia Baca , PMI 東京支部 ( 編集 ) ，「PMP 教科書 問

題集 Project Management Professional」（翔泳社，2004）

とりあえず競技規約を満たしているかを確認するために，米設計書の提出期限を数日後に控えた 10 月 3 日の昼下がりに，
私と米山君と高瀬さんの 3 人で集まりました。飛行戦略を決

山君が予備機を運営委員会に持っていきました。結果は合格。
大会最大の危機を乗り越えた瞬間です。

モデリング定するため，この日は前々から必ず集合すると決めていたので

しかし，この後，飛行船の風船から気体が漏れることが発覚[11]

す。先生も含めた 4 人で徹底した議論を繰り広げました。ししました。それでも予備の風船を 3 枚持参していたので，こかし，なかなか良い案は出てきません。

の困難も乗り越えました。

竹 政 昭 利，「 は じ め て 学 ぶ UML 第 2 版 」（ ナ ツ メ 社，

2007）
[12]

青山幹雄，中谷多哉子，「オブジェクト指向に強くなる

最大の問題は，風の流れという外部要因の動向が当日になる―ソフトウェア開発の必須技術」（技術評論社，2003）まで不明だということです。一般的に，どのような大会でも開翌日，この１ヵ月の成果が試されるときがやってきました。

[13]

山口淳一，江見圭司，「オブジェクトモデリング (UML)

催される会場の環境は一定に保たれるものですが，飛行船の特

私はモデル部門担当でしたので競技部門では試験データ採取くを用いた組み込みソフトウェア開発技術者養成プロジェクト」，

性上どうしても風と気温の変化に敏感なので，会場に人が出入

らいしかしていませんでしたが，それでもやはり上位入賞した

IPSJ Symp. vol.2004, pp.171-174 (2004)

りするだけでも影響があるのです。

いという思いはありました。

[14]「意外と飛びませんね」

江見圭司，石井充，矢島彰，「モデリングを中心にしホワイトボードにその図を描き込んでみると，競技エリアをたオブジェクト指向技術者養成カリキュラム」，IPSJ Symp.

ちょうどまっぷたつにするような形になりました（図 5 参照）。

「せやろ，どのチームも会場の環境に苦しむんや」

vol.2002, No.12, pp.127-132 (2002)

出場する飛行船の大半がこの風の壁に行く手を阻まれるそうで先生から飛ばすだけでも難しいということは以前に教えても[15]す。逆に言うと，この風の壁さえ乗り越えてしまえば優勝も充らっていました。しかし，大半のチームは，外部環境が飛行船分にあり得るということです。

に与える影響というものを軽く見ていたのではと推測してい牛尾剛，長瀬嘉秀，「オブジェクト脳のつくり方―Java・

UML・EJB をマスターするための究極の基礎講座」（翔泳社，2003）

議論は次第に煮詰まってきたので，一旦休憩することになります。私達の飛行船はその中ではよく飛んだ方で，2 つ存在す

平澤章，「オブジェクト指向でなぜつくるのか―知ってました。私も話題を切り替えて先生と話をしていましたが，飛るチェックポイントのうち 1 つは通過しました。結局，これおきたいプログラミング，UML，設計の基礎知識―」（日経

行船競技から宇宙の話へと移ります。宇宙といえば天文博士ので競技部門は 3 位となります。ゴールまで到達した飛行船は 1

BP 社，2004）

ある教授が真っ先に思い出されるわけですけども，気象衛星のつもありませんでした。

[17]

話が出てきたときに閃きました。探査衛星が地球の重力を利用[16]

株式会社テクノロジックアート，「UML 辞典」（翔泳社，

2004）

54

「先生，廊下で取ったデータって役に立つんですか？」

して他惑星に航行する方法を真似るわけです。競技コース中にまた，相撲部門では，米山君が相手の裏をかくなど上手に操作したこともあって，4 位という好成績でした。

55