［レポート］
今年も UML Forum / Tokyo 2004 の季節がやってきました。
そして、今回の UML Forum でも昨年に引き続き UML ロボットコンテストが同時に行われました。
我が社からは 2003 年度入社のフレッシュな 5 人組が出場しました。
チームのメンバーの中には普段組み込みとは関係ない仕事をしている人もいるため、
「組み込みで UML っておいしいの？」というレベルからのスタートでした。
本記事ではエントリーから大会参加までの奮闘ぶりをまとめてみました。
去る 2004 年 4 月 13 日、今年で第 3 回目となる、通称 UML ロボコン、UML ロボットコンテストが開催されました。 UML ロボットコンテストとは、開発した走行ロボットのレースを行い、開発を通じて作成した UML モデルとレースのタイムを競いあうコンテストです。走行ロボットは、レゴマインドストーム（LEGO Mindstorms）とレゴブロックを組み合わせて作成し、参加者は規定のコースをこの走行ロボットでゴールまで走らなくてはなりません。折からの UML 人気も手伝って、参加チーム数は去年（23 チーム）に比べ大幅な増加を見せ、40 チームがタイムを競い合いました。
レゴマインドストームは、LEGO 社の製品で、モータやセンサーなどをプログラムで制御することが出来ます。
レゴマインドストームについては、「オブジェクトの広場」の以下の記事が参考になるかと思います。
組込みトレーニング向け実習教材の開発記録 〜マインドストームはオブジェクト指向の夢を見るか？〜
今年の UML ロボコンは決められた機体で決められたコースを走るというショートトラック部門のみで、より純粋に速さと（UML モデルの）美しさを競いあうコンテストになりました。去年はレスキュー部門という、一種の障害物レースがありました。レスキュー部門は、走行ロボットの形状が自由で、コースの中に完走が難しくなるような工夫が施されている、多彩なレゴロボットと走法を楽しめるものだったようです。今年はショートトラック部門に絞られたため、さながら F1 レース（ちょっと大げさか・・・）のような速さを競い合う熱い大会となりました。
我が社では、UML ロボコンには去年、一昨年と参加していて、去年からは新人が参加しているので、新人の勉強をかねた恒例行事という雰囲気になりつつありました。今年も新人（2003 年度入社）から参加者を募ることになり、2004 年 1 月下旬から 2 月上旬にかけて募集が行われました。募集中、先輩に運悪くつかまった自発的に集まった 5 人（金子、黒田、林、山口、富居）が UML ロボコンに挑むことになりました。勉強したい人、レゴに触りたい人、メンバーに強引に連れてこられた人など、思惑はそれぞれですが、UML ロボコンへの熱い戦いが始まりました。
ちなみに、チーム名は かしゅー☆なっつ といいますが、これはチーム名を決めるときにメンバーの A 氏がたまたま食べていたおつまみの”カシューナッツ”からとりました。（結構適当だな・・・）
UML ロボコンへのエントリーも済ませて、いざ開発作業が始まったのですが、開発の流れを決定することはなかなか難しいことでした。集まったメンバーの現業務を見てみると、ビジネス系、Web アプリ系、組み込み系、パッケージソフト開発系など、多種多様です。（全員、開発もしくは開発に近い業務ではありますが・・・。）それぞれ考え方ややり方が違い、誰もが一度に納得する方法を見つけることは困難に見えました。
メンバーの何人かは組み込み初心者だったので、まずは”お勉強会”から始まりました。メンバー唯一のくみこまー（組み込みエンジニア）である A 氏を講師として、日曜日の夕方新宿の喫茶店に集まり、eUML（参考文献[2]）についてレクチュアを受けました。eUML は組み込み向けの開発プロセス（厳密には開発プロセスも含んだ開発ガイドライン）です。メンバー曰く「eUML と聞いたときに、UML の拡張版か新たな言語かと勘違いしてしまいました。」とのこと。なかなか前途多難です。
もっとも、時間が限られていることもあり、あまり複雑な方法論を取ることは出来ません。eUML はかなりしっかりとした方法論で、これを厳密に適用することは時間的に難しいので、図 2.1 のような軽めのプロセスを組み立てることにしました。
図 2.1 開発の流れ
図 2.1 の流れにあわせて作った UML ダイアグラムの数を走行に関する部分に限って数えると、以下の 7 枚になりました。
走行アルゴリズムは没になったものもあるので、実際にはもう何枚か書きました。この他、機械制御やセンサーの変化（イベント）を処理する部分などに、10 枚程度書きました。どのくらいが多くて、どのくらいが少ないと感じるかは人によって違ってくると思うので、なんとも言えませんが、あれこれ欲張らずに進めていたことは、読み取れるのではないかなと思います。とはいえ、少ないから良いというものでもなく、問題の重要性や大きさに応じて作成できるモデルの数は変わってくると思います。
このプロセスは、レゴマインドストームという小さな問題領域だったせいか、わりと迷うことなく最後まで行き着くことが出来ました。個々の成果物の作成ではメンバー内でバトルが起こったのですが、その辺については、後ほど「勃発！ モデリングバトル！！」にて詳しくふれたいと思います。
毎週土日はレゴとの戦いでした。レゴは様々な形のブロックを組み合わせて作ることができ、自由度の高いロボットを作成できます。しかし、コンテストでは決められたパーツで決められた形のロボットを作成しなければなりません。つまり、参加者全員が同じ走行体を使用しなければなりません。
コンテストで使う走行体は PathFinder （パスファインダー）と呼ばれていて、みの虫みたいな形をしています。フロントにタッチセンサーと光センサーがついていて、後輪が動力になっています。パスファインダーの部品は変更できないので、ハードウェアに関しては、各チームの工夫する点は限られてきます。結局は各チームのモデルとアルゴリズムの勝負となってきます。それでも、組み立てたら終わりとはならないのがレゴの面白さなのかもしれません。
というか弱いです、車体・・・。
組み立てたそばから崩れていくような部分もあったり、組み立て直してもなぜか残ってしまう部品があったり、苦労の連続でした。特に、光センサーと車体の接合面に関しては、あまりに弱く外れやすいため、各チームさまざまな工夫を行ったようです。我々のチームではセロハンテープでぐるぐる巻きにして固定してしのぐことにしました。また、練習走行しているときに、センサー部分がずり上がったり、ずり下がったりしてしまうことも多々あり、機体の弱さは一つのネックになっていたと思われます。
◆ 概念モデリング 〜 動的構造の分析
この部分は、UML モデリングの過程でもあるので、「提出したモデルについて」にて詳しく触れたいと思います。
◆ 実装 〜 テスト
実装するための言語は Java か C++ で行うことが許されていますが、われわれのチームは C++ で実装することにしました。実装はコースの攻略部分以外（基盤となる部分）はくみこまー A 氏が担当し、コースの攻略の部分は、走法にこだわりのあるコンビがメインに進めていきました。くみこまー A 氏の実装が良かったのか、他のメンバーが走法のアルゴリズムを記述する際に、バグなどに惑わされることはあまりなかったと思います。どちらかというよりも、パスファインダーが走法どおりに動いても、走法がよくなければゴールできないんだと実感させられました。
◆ 試走会
試走会は二日間ありましたが、両日ともいっぱい課題を持って帰ってくることができました。特に問題があったのは、スピードが上がってくると、走行体がぶれるようになって、カーブで転んだりコースのラインから大幅に外れてしまうことでした。同様な作戦を取られていたチームをみると、みな同様な悩みを抱えていたようです。特に坂道を下ったあとの急カーブをクリアする部分はかなりの難関となっていました。メンバー内で議論した結果、最適なパラメータ（走行体の速度や曲がる速さ・角度など）を見つけてこの難関を切り抜けようということになりました。それからは微妙なチューニングの繰り返しでした。F1 マシーンをコースに最適化するピットクルーのような気分になりました。しかし、結局必ずゴールできるパラメータを見つけることができず、いよいよ当日を迎えてしまいました。
さて、参戦記も盛り上がってきましたが、ここでちょっと息抜きをして提出したモデルを掲載したいと思います。むしろ息が詰まるとか言わないように。ただモデルを載せるだけではわかりにくいと思うので、説明も付け加えてみました。
まず、図 4.1 のようにわれわれのチームは概念モデルを作成することにしました。どういうシステム（ハードを含めて）であるか、お互いの認識を概念モデルである程度一致させておきたかったのです。
図 4.1 概念モデル
図 4.1 を説明しますと、パスファインダーにはステアリング（車輪の向きを変える機器）の機構がついています。つまり、車体をその場で回転させて方向転換するシステムではなく、通常の車のように車輪（パスファインダーは前輪）の向きを変えることで、車体の進行方向を変えます。また、コースを複数のエリアに区切りました。以下に今回定義したエリアの一覧を載せたいと思います。
概念モデルにコースやエリアを含める必要性があるか難しいところですが、システムと外部世界との関係も意識するために、コースとエリアを概念モデルの中へ含めました。これは、課題となっているコースに分岐が含まれていて、やや複雑であるため外部の環境までモデリングする必要性が、出てくるかもしれなかったからです。
ここで、本来ならばユースケース図を書く必要があると思いましたが、どうせ似たり寄ったりだろうということで、提出物に含めませんでした。実はこれはこれで問題だったようです。というのは、要求分析は”誰”が”何をしたい”か明らかにするための作業です。これが入っていないということは、提出したモデルはやりたいことがないということです。
概念モデルの後は、図 4.2 のように問題領域の分割（ドメイン分割）を行いました。これは、問題領域をわけることによって、何を解決していけばシステムが作れるかを把握するという意図もありましたが、後々またレゴマインドストームと LegOS にふれる機会があった場合、重複する問題領域を再利用できないかと考えたためでもあります。使うかどうかはともかくとして、来年 UML ロボコンがあったとして、それに参加したメンバーの負担が少しでも軽減できれば良いという考えからでした。
図 4.2 ドメイン（問題領域）チャート
図 4.2 で定義したドメインの説明を以下の表にまとめました。
| ドメイン名 | ミッション記述（ドメインの責務） |
| ロボットコンテスト | UML ロボットコンテストの課題をクリアする方法を提供する。 |
| ユーザインターフェース | ユーザとシステムが相互にやり取りをする方法を提供する。 |
| メカニズム | エンジンやセンサーなどの物理デバイスを操作する方法を提供する。 |
| デバイスドライバ | 入出力ポートを制御する方法を提供する。 |
そして、クラスの抽出を行い、クラス図（図 4.3）を作成しました。クラス図を作るにあたっては、一悶着あったのですが、その件については後ほど詳しく触れさせていただくとして、簡単な説明だけしたいと思います。コースは複数のエリアから構成されており、パスファインダーはコースを選択後、エリアを見つつ走法を選択します。エリアは、「前」「後」というロール名で前後関係を規定していますが、多重度を見ていただけばわかりますが、分岐には対応していません。実は近道を取り損ねると、前後関係が破綻してしまうつくりになっています。このようなつくりにしたのは、センサーなどから得られる情報から、現在のエリアを特定することは難しいと思われたためです。あとから聞いた話では、コースとエリアの構造をわかりやすくモデリングしていた点が、評価の高い部分になったようです。
ちなみに、関連名に R1 などの記述がありますが、Executable UML の記述方法に沿っています。ロール名が動詞になっているのも、同書の記述方法です。詳しくは参考文献[1]をご参照ください。
図 4.3 クラス図（分析レベル）
審査員の方からは不適切な関連があるというご指摘をいただきました。おそらく、関連の R3 か R5 が冗長なのだと思われますが、R3 は走っているときに注目すると抜くことが出来ない関連なので、R5 でしょうか。この関連は意味的にはおかしくありません（関連クラスへの関連:参考文献[1]を参照のこと）が、走法を決定する際の流れに特に情報を与えていません。意味的にはエリアと走法の間に多対多の関連があることは間違っていないと思います。あるエリアの攻略法は複数あるし、ある走法は複数のエリアを攻略できます。
次に、今回のレースで使用した 2 つの走法（エッジ走法と安全第一走法）のアルゴリズムを状態遷移図で表現しました。下の図 4.4 のエッジ走法は、黒を検知すると右に首を振り、白を検知すると左に首を振ることで、線のふち（エッジ）をジグザグに走って進みつづける走法です。（線の右側のエッジをたどる”右”エッジ走法。）おそらく、本大会で最も多く選択された走法アルゴリズムではないかと思われます。
図 4.4 ”エッジ走法”の状態遷移図
下の図 4.5 の安全第一走法は、最初に考えた走法であったため、メンバー内ではベーシック走法と呼ばれていました。基本的に前進を続け、白を検知すると（つまりラインから外れたことを検知すると）、左右に首を振ってラインを見つけます。ラインを見つけたら、向きを修正（ステアリングが曲がっていない状態にしてから）してから、「前進中」状態に復帰します。ただ、「停止中」状態時に、首振りでコースを見つけられないときは、後進してコースに復帰しようとします。コースへ復帰しようと努力をするので、"安全第一"と呼ばれることになりました。
図 4.5 ”安全第一走法”の状態遷移図
エリアごとに走法に微妙なアレンジはしたものの、基本的にはエッジ走法・安全第一走法をそれぞれのエリアに割り当てて、コースの攻略を図りました。しかしながら、走法の選択方式が、コースの構成（エリア同士のつながり方）に依存してしまうので、コースが変更になるたびにコードを書き換えなくてはいけない弱点があり、改善の余地が残りました。
これで提出するモデルは全て揃いました。 このモデルで、「どうだ、動いたぞ！」と主張できるかどうかはコンテスト当日次第です。
「モデリングバトル」なんて大げさなタイトルをつけましたが、成果物作成中に起こったちょっとしたエピソードを紹介したいと思います。ことは、分析レベルのクラス図を作成するときに起こりました。問題になったのは、パスファインダーが走法を決定するまでの流れを、クラス図にどこまで起こすべきかというところです。戦いは、くみこまー A 氏とこだわり走法コンビのかたわれ B 氏の間で繰り広げられました。まずは、図 5.1 と図 5.2 をご参照ください。
図 5.1 A 氏のクラス図
図 5.2 B 氏のクラス図
両者の違いはパスファインダーとエリアの間にある関連です。組み込み系エンジニアである A 氏は分析の段階でも、実現性を重視したようです。A 氏のクラス図からは「パスファインダーは選択したコースにあるエリアを走る」ことが読み取れます。パスファインダーはエリアに応じて走り方を変えるので、エリアを走るという意味合いの関連線を欲したのです。（A 氏の図にはエリアとパスファインダーの間に関連クラスとして走法があることが前提となっています。）ビジネス系（Web アプリ系）エンジニアである B 氏は、この関連をやや細かすぎると考えたようです。この線がなくても、コースからエリアを手繰っていけばパスファインダーはエリアを知ることが出来ます。設計もしくは実装の段階になってから、実際のエリアの手繰り方を考えればよいと考えたようです。
この辺は、いろいろな意味で思想の違いが出たようです。A 氏はもともと「Executable UML」（参考文献[1]）を手本としていて、動くモデルを重要視していました。そして、組み込み系では分析レベルのモデルの定義は、パフォーマンスなどはともかく、理論上動くモデルが出来上がっている必要があるのだそうです。B 氏は逆に分析レベルの図、しかもクラス図でやや動的な面まで見えてしまう図の書き方に違和感をもったようです。図の書き方も、目的が違えば変わってくるのが当然なので、両者ともに別々の方向を見ながら、議論をしていたのかもしれません。とにかく、激しいバトルの結果、お互いが書こうとしている図の目的を理解したらしく、両者和解して分析クラス図が完成しました。
教訓。誰が何を目的にしてモデルを書いているか明らかにしよう。
余談になりますが、前述の「Executable UML」（参考文献[1]）では、A 氏のようなクラス図を「関連ループ」というパターン名で紹介しています。似たようなクラス図でも、三つの関連の中に冗長な関連が紛れ込んだり、逆に制約を表現するために必須になったりする例が載せられています。興味のある方は「Executable UML」（参考文献[1]）を参照されると良いかと思われます。これを考えると、上記の図の議論は重要です。
コンテスト当日は非常に熱気があり、どのチームも控え室のそこらじゅうでチューニングに必死になっていました。本番前の試走を見る限りでは、どのチームも非常にレベルが高く、苦戦しそうな感じを受けました。負けじとわれわれのチームも何とか完走したいと最後のチューニングに入りました。
◆ モデル
コンテスト会場に向かったところ、コンテストが始まる前にすでにモデルの審査の結果発表がされていました。そこでなんと私たちのチームのモデルがシルバーモデル（3 位）に入賞しているではありませんか。
図 6.1 モデルの評価結果
とりあえず、みんなで喜んだとともにほっとしました。これだけの賞をもらったからには絶対に完走し、あわよくば優勝しなければと自分たちにプレッシャーをかけて一回目の走行に臨みました。走行のチャンスは 2 回です。一回目は午前に行われ、昼食をはさんで二回目の走行があります。二回の中でタイムの良かったものが、コンテストの記録となります。
◆ 走行
本番前の準備時間も終わり、いよいよ第一回目の走行が始まりました。ところが、なんということか！！最初のチームがかなり速いタイムでフィニッシュ！！ いきなりプレッシャーがかかった状態で競技を行わなければならなくなりました。しかし、完走できずにリタイアするチームが続出しました。他のチームが次々とリタイアしていく中、いよいよ私たちの順番が回ってきました。緊張の面持ちでインタビューを受ける第一回目走行のお立ち台担当の二人。なんとか完走できるといいんですが・・・
図 6.2 走行一回目
よーいドン！！の合図で走行体を走らせるが・・・第一コーナーで転倒。あっけなすぎる。もうちょっとがんばって頂戴。一回目が失敗に終わったため、何とか二回目はせめて完走したいとチューニングして臨みました。
◆ 結果
お昼に微調整をし、完走を目指した二回目の走行。しかし、残念ながら完走できず。おかげで、ここで実況っぽい記事も書けず。結局、一回目の走行の最初のほうでいい記録を残したチームが優勝しました。非常に残念、無念！！
我らが「かしゅー☆なっつ」の走行ロボットは、当日の会場のコンディションに振り回されて完走はできませんでした。走法以外にも、効果的なキャリブレーションやコンディションの変化に強いアルゴリズムなど、留意すべき点がたくさんあります。しかし、「かしゅー☆なっつ」のモデルはそういった面での詰めが甘かったので、その辺に敗因があるかなと感じました。
今回このコンテストに参加してみて、いろいろな人が参加しているなと感じました。会社での参加はもちろん大学生や高校生など、さらには親子で参加しているチームもありました。これだけ多種多様な職種のチームが参加していましたが、ただどの参加チームも非常にレベルが高くコンテストを楽しんでいる様子でした。特に私の中で印象が強かったのは親子で参加されたチームで、親子のコミュニケーションにこういったコンテストを利用するのも素敵だなと感じました。
それはさておき、これだけの人間が参加していると様々な考え方があり、こんな考え方があるんだととても勉強になりました。モデル一つ一つにそれぞれのチームの色が出ていて、モデルを見るだけでもこのコンテストに参加する意義はあったと思います。興味をもたれた方は、ぜひ次回のコンテストに参加してみてはいかがでしょうか。
◆ メンバーのつぶやき
[1] スティーブ・J・メラー、マーク・J・バルサー著 二上 貴夫、長瀬 嘉秀監訳 Executable UML 研究会翻訳 株式会社テクノロジックアート編集「Executable UML」（翔泳社、2003 年）
[2] 渡辺博之、渡辺政彦、堀松和人、渡守武和記著「組み込みUML 〜 eUMLによるオブジェクト指向組み込みシステム開発」（翔泳社、2002 年）
| © 2004 OGIS-RI Co., Ltd. |
|
