|
[2011 年 5 月号] |
［レポート］
本連載記事では、田町レーシングチームのメンバを中心に開催したETロボコンモデル座談会の中で挙がったETロボコンにおけるモデリングのポイントやノウハウを3回に分けて紹介しています。
中編にあたる本記事では、構造分析と振る舞い分析を扱います。まだ、前編の記事を読んでいない方は前編の記事を参照してください。
なお、本記事では、田町レーシングが作成したチャンピオンシップ大会のモデルを度々引用します。ぜひ、実際のモデルを手元に印刷して記事を読み進めてください。
構造分析のシートでは、構造分析のモデルを作るときに意識した点や注力した点を中心に議論しました。モデルの理解しやすさに配慮したことや、将来起こる変更にも耐えうる基本構造を構築したことで、モデル審査での高評価につながっただけでなく、実際に実機での動作検証がしやすくなりました。しかし残念ながら、今回のモデルでは考慮できていなかった、競技規約の変更例も指摘されました。
国正：構造分析のモデルを作るときに意識した点や注力したところを大きく3つ紹介します（図2-1）。こちらのモデルは分析レベルです。実装環境を意識した設計レベルの情報は含まれていません。
図2-1 構造分析のモデルシート
（クリックすると拡大した画像が見られます）
国正：1つ目は、ドメインモデルと構造モデル間のトレーサビリティを重視し、ドメインモデルと構造モデルの対応が理解しやすくなるように工夫をしています。
国正：具体的に言うと、まず、ドメインモデルで検討したコースやエリアという走行体外部の物理的なものと、走破戦略という人間の頭の中で考えることを分け、構造モデルではそれぞれを別々のパッケージで詳細化しました（前編記事 表2-1 #3）（図2-2）。また、パッケージ図とクラス図は、ドメインモデルで使用した名前を使っています。ドメインモデルに出てこなかった言葉については、極力、文章や図解で説明を入れています（図2-3）。
 |
 |
| (a)ドメインモデル | (b)構造モデルの基本構造 |
図2-3 基本構造の概念図
構造分析で登場した概念は概念図で説明している。
辻：概念図を補足すると、エリアは2次元で区間と経路は1次元を意識した概念です（図2-3）。エリアが競技規約の難所と同じ粒度で、人が理解しやすい単位の概念であり、経路がエリア内の全部の道筋を表す線のような概念です。そして、区間は経路を走破戦略ごとに区切った、より細かい単位で、区間ごとに適切な走法が決まるような概念です。
辻：次に、要求図の分析の切り口に合わせてクラス図のクラス階層を整理しています（前編記事 表2-1の#5）（図2-4）。要求図では、「コースを走破するためには、エリアの境界を認識するための『認識系』とエリアを走るための『駆動系』という2種類の機能を抽出すれば良い」という考え方に基づき整理しています。それらの機能は、構造分析でもきちんと表現しています。認識系は終了条件のクラス階層として、駆動系は走法のクラス階層として整理しています。
国正：クラス図では、技術要素をどのクラスで実現しているのかを緑色の吹き出しで明示することで、構造の中にも性能面の情報を盛り込んでいます（前編記事 表2-1の#6）。
 |
|
| (a)要求図では機能を認識系と駆動系に分類した | |
 |
 |
| (b) 認識系はクラス図の終了条件クラスのクラス階層で実現した | (c) 駆動系はクラス図の終了条件クラスのクラス階層で実現した |
| 図2-4 要求図の分析の切り口に合わせて構造分析のクラス階層を整理した （クリックすると拡大した画像が見られます） |
|
手嶋：ドメインモデルと構造分析のクラス図で多重度が食い違っていませんか？ドメインモデルでは、エリアと走破戦略間の関連の多重度が1対多です（図2-5(a)）。これがそのまま、構造分析のクラス図のエリアと走破戦略の関連の多重度に来るのかなと見ると1対1になっています（図2-5(b)）。あれ？って疑問に思いました。
 |
 |
| (a)ドメインモデル（一部）： エリアと走破戦略の間の多重度は1対多 |
(b)構造分析モデル（一部）： エリアと走破戦略パッケージにある経路クラスの間の多重度は1対1 |
| 図2-5 ドメインモデルと構造分析モデルの多重度の対応関係 | |
辻：2つの関連は意味が違います。ドメイン分析では「エリアの走破戦略って単純に複数あるよね」という意味を表しているだけです。一方、構造分析だと「複数あるエリアの走破戦略の中から最適なものを1個選んだ」という意味です。
手嶋：なるほど。例えば、1本別の関連で「選択可能」を追加すれば、1つのエリアで走破戦略をいろいろ選べますという意味合いも表現できますよね。
大西：去年の田町レーシングのモデルだと、選択可能な経路と今走っている経路は別の関連に分けていましたよね*2-1。
*2-12009年のモデル座談会の「3. ドメイン分析」の「多様なコースを走れる柔軟なドメインモデルを定義する」を参照。
辻：経路と標識の関連を候補と進路に分けて、候補の多重度を多にしてあるので、選択可能な経路は複数あります。最終的に標識が1つの経路を選択します。経路選択エリアの視点で捉えると選択可能な経路は複数あると言えますね。
林田：ちょっとそこ分かりにくかったかな。でも、すっきりと書きたい気持ちがあったんですよね。
国正：工夫した点の2つ目は、将来のコース変更が発生しても使えるような安定した基本構造を固めたことです。特定の難所に対する走らせ方はどのチームでも考えてくるので、田町レーシングは、その一歩上を目指しました。モデルシート中でも、構造を考えるときのストーリーとして「将来的な拡張性を高めるため、特定のエリア攻略に特化しない基本構造を検討しました。」とアピールしています（図2-6）。
図2-6 基本構造のコンセプト
国正：地区大会のモデルは、エニグマデコーディングやミステリーサークルといった動的に経路を選択する新しい難所は例外的な扱いでしたが、チャンピオンシップのモデルでは、これらの難所を攻略することも基本的な構造で実現すべきと考えて、構造に盛り込んでいます。この部分は地区大会から大きく変わったところです。
手嶋：個人的には基本構造に、難所の固有名詞（エニグマデコーディング、ミステリーサークル）が出てないところで、汎用性は高そうだなとは感じました。後は、基本構造を示している点も審査員は理解しやすいと褒めていましたね。
辻：クラス間の関係は意味的なつながりを意識して引いているので、なぜこのクラス間に関係があるの？と疑問に思われないようにしています。その点で理解しやすいモデルになっていると思います。他のチームだと動きを意識した関係が多いので、モデル上で関連が引かれている理由が分からないところもあります。
山内：確かに、クラス名やメソッド名を見ても何の概念を表すのか疑問に思うようなところがないですよね。概念ごとの責務が分かりやすいです。
林田：モデル審査委員長の渡辺さんが素敵な構造のモデルを書いたねって良い評価をしてくれはりました。データにも振る舞いのどちらにも片寄っていなくて、2つのハイブリッドでバランスが良い構造をしているよねと。
手嶋：今年、振る舞いにちょっと特化しすぎているモデルが多いので、そこが良かったんでしょうね。
青木：確かにシンプルだと思うんですよね。主要な構造だけで何をやるかが分かります。要求分析で出てくる基本機能の部分は、サブクラスに集約して、基本構造はほとんど変わらないで動いているというのがぱっと見て分かりやすいと思いました。
国正：工夫した点の3つ目は、振る舞い分析と合わせての話になりますが、ユースケースを実現できる構造になっていることを振る舞い分析で検証しています（図2-7）。今までのロボコンでも、分析モデルで考えた構造が本当に動くのか？というところは審査の対象になっていたと聞いています。なので、この構造でちゃんと動く、ユースケースを実現できるということを検証しています。
図2-7 コミュニケーション図によるユースケースの実現性検証
（クリックすると拡大した画像が見られます）
辻：補足すると、機能の検証のしやすさに配慮した構造モデルにしています。要求図で検討した基本機能とクラス階層を合わせることで、基本機能が変わっても大きく構造に影響しないようにしています（図2-4）。実際に走行しているときに、この基本機能は良くないから違う機能に置き換えたいとなっても、構造には影響を与えずに開発ができるようにしました。
山内：モデルと実際のソースコードにギャップはありますか？
平岡：ちょっと時間の都合上、整合性が取れていないところがあります。具体的に言うと、分析モデルには区間クラスのサブクラスは探索区間しかありませんが、区間ごとに欲しい情報ってかなり違っているので、実際のソースコードではもっと区間のサブクラスがあります。
平岡：地区大会のときも、区間はモデルとソースコードが乖離していましたが、そのまま出しました。
山内：それはなぜ？時間がなかったから？
国正：実際の話をすると、地区大会で出したときは時間がなかったからです。とりあえず地区大会が終わった後、分析モデルの構造に合わせてソースコードを作り直したんですよね。でも、その後、元のソースコードのまま本番まで来てしまいました。
辻：基本的にソースコードは、初版の分析モデルをベースに作りましたが、そこから改訂したモデルに対して対応しきれていないんですよね。技術的に検証してうまくいったソースコードをいじるのはリスクがあります。分析モデルの新しい構造をソースコードに適用して、また新しいパラメータ調整をやろうとすると、もう本番に間に合わないっていうことで諦めました。
手嶋：結構どのチームも同じ状態に陥るんですよね。モデルの構造が変わったときに検証の終わった実装に手を入れるのは躊躇しますからね。ロボコンは、モデル部門と競技部門を両方並行してやらないといけないから、どこも苦労してます。モデルを変更するか、動作実績を取るか、期限を考えた上で決めるしかないですね。規約上、モデルと実装は一致している必要があるので、モデルを変更する場合は実装の修正も必要ですね。
林田：平岡君が「この分析の構造の通りに実装したら、ものすごく実装を変更しやすくなる」って言うてたよね？
平岡：実装をやっていて一番価値があるなと思ったのは、エニグマデコーディングで活躍する「探索区間」ですね（図2-8）。この分析モデルの構造で実装すると、超音波センサで衝立を探す処理はそのままに、探索区間に渡す走法のオブジェクトを置き換えるだけで走法を自由に組み替えられます。例えば、止まって衝立を探したり、ライントレースしながら探したり、直進しながら探したりできます。これで実機テストしながらの試行錯誤がやりやすくなりました。
図2-8 走破戦略パッケージのクラス群
探索区間に渡す走法のオブジェクトを置き換えるだけで走法を自由に組み替えられるようにした
平岡：探索区間がない頃は、走法のサブクラス側で超音波センサを使った衝立の探索をやるのかやらないのか判断していました。このやり方だと、衝立の探索をするときの走法を変えたいときに、その走法クラスに超音波センサを使った衝立の探索処理を実装する必要があって、かなりチューニングが大変でした。
手嶋：区間を継承して探索区間を作るやり方もありますが、別のやり方もありますよね。例えば、走法と同じレベルで探索クラスを出して区間から探索の責務を移すのはどうでしょう？
林田：認識系と駆動系とでせっかくきれいに分けているところで、駆動系にあたる走法に認識系のクラスを結合するのってあまりいい形ではないかなという気がします。そういう意味では、区間に衝立を検知させる責務を持たせているのはいいのかなぁと、僕は思います。
大西：そうですね。田町レーシングのモデルの作り方としては、認識系と駆動系のクラスは細かい粒度にして、区間側でそれらを組み合わせてうまく走るというポリシーでしたね。
青木：この構造だと探索区間と区間が独立していないと対応しきれない場合がありますよね。
辻：どういう場合ですか？
青木：探索しながらエリアの独特の走法もやっていて単純に探索しているとは言えないとか、探索結果をもとに走行が徐々に変わっていくとか、そういうような複雑な競技規約が出てきたときに、この構成だと実装が複雑になるかもしれないかなと思いました。
辻：探索区間と言っても、結局、超音波センサを使う処理を入れるか入れないかを表しているだけなんですよ。探索区間には超音波センサを使う処理を入れますが、単純な区間は入れません。
青木：実際に来年どういうギミックが出てくるか分からないけど、Bluetoothで情報を受信するとか、立体難所とエニグマデコーディング以外の何か違う要素が入る場合も考えられますよね。
手嶋：例えば、衝立（ペットボトル）を探しながら、同時に光センサを使ってコース上に描かれたマークを探すとか、2つ以上の探索を同時に求められる区間が出てくると探索区間内のロジックが煩雑になっていきそうです。
辻：それは、そうですね。そういう競技規約の変更に対する将来的な影響はあまり考慮していません。
山内：今は、現状のドメインがある程度片寄ったところにあるから、ここは探索区間という概念として表れています。もうちょっと広いドメインで捉えたときに、この名前が探索区間ではなくて、別の名前になって責務が変わったり、新しい責務が足されたりするかもしれないですね。
林田：来年は競技規約をいろいろ変えるという噂*2-2やから、このモデルがどこまで対応できるか考えるのもちょっと面白いかもしれないですね。
*2-2ETロボコン2011 競技規約 1.0.4を参照。2011年の競技では1コースに対して2ステージの走行を行う。「ベーシック・ステージ」では走行タイムだけを競い、「ボーナス・ステージ」では難所のボーナスタイムを競う。また、難所についてはインコース・アウトコース共通の「ガレージイン」、インコースの「シーソー」と「階段」は残り、アウトコースの難所が新しく「ルックアップゲート」と「ETタックル」に変わった。
振る舞い分析のシートは、構造分析で示した構造ですべてのエリアと経路を走破できることと、タスク分割について記述しています。議論の中では、シンプルな振る舞いのパターンですべてのエリアを走破できるように構造も含めて入念に整理したことを話しました。また、並行性設計を振る舞いモデルで表現するときの注意点についても議論しました。
林田：振る舞い分析について私から3点説明させてもらいます（図3-1）。こちらも構造分析と同じく、分析レベルのモデルです。実装環境を意識した設計レベルの情報は含まれていません。
図3-1 振る舞い分析のシート
（クリックすると拡大した画像が見られます）
林田：1つ目の大きなポイントは、毎回繰り返される走行のパターンを基本形として整理して、その基本的なパターンの組み合わせですべてのエリアと経路を同じように走れるということを示している点です（図3-2）。
林田：基本的な振る舞いの中で青い枠で示した個所はエリアが切り替わるときの振る舞い、緑色の枠がエリア内の振る舞い、オレンジ色の枠が経路内の振る舞いを表現しています。これらのパターンで、すべてのエリアや経路を走破します。
図3-2 基本的な振る舞い
（クリックすると拡大した画像が見られます）
林田：2点目は、複雑な難所でも基本的な振る舞いパターンは変えずにエリアもしくは区間を特化することで走破できることを示している点です（図3-3、図3-4）。
図3-3 エニグマエリアの振る舞い
（クリックすると拡大した画像が見られます）
図3-4 ミステリーエリアの振る舞い
（クリックすると拡大した画像が見られます）
林田：「②エニグマエリアの振る舞い」は探索区間がエニグマデコーディグの衝立を探している流れ、「③ミステリーエリアの振る舞い」は標識がミステリーサークルの経路を動的に選択するという流れを表現しています。「②エニグマエリアの振る舞い」では、探索区間が衝立を読み取る個所だけが特化されているだけで、他は基本的な振る舞いパターンと同じであることが分かると思います。
三村：「基本的な振る舞いの組み合わせで複雑な難所を走破する」という考え方は、モデリングワークショップでも評価されていましたね。
三村：単に難所ごとの振る舞いを描いているチームが多いと思いますが、田町レーシングのモデルは基本的な振る舞いを先に見せて、その次に難所の振る舞いを見せるという構成になっています。これは狙ってやっていたということでしょうか？
国正：そこは狙って描いていますね。
辻：このシンプルな振る舞いを目指すために構造にもかなり手を入れました。シンプルな振る舞いができないと、構造としては何か問題があると考えて取り組みました。
青木：確かに、これは分かりやすいと思いました。「①基本的な振る舞い」が一番シンプルに書かれているというところが良いと思います。
林田：3つ目は並行性設計です。並行性設計ではタスクを分割した理由、タスクの優先度、共有資源の排他制御について、その根拠を示しました。田町レーシングのモデルでは共有資源の排他制御をやる必要はありませんが、検討した結果、必要ないことを明示的に示しています。
図3-5 並行性設計
（クリックすると拡大した画像が見られます）
手嶋：並行性設計はシーケンス図を使って時系列を見せるモデルが多かったです。例えば、HELIOSさん*3-1の振る舞い分析の左半分にシーケンス図があり、その中にタスク分割についての解説がありました。一方、田町レーシングはコミュニケーション図を使った理由は何ですか？
*3-12009年と2010年のチャンピオンシップ大会でエクセレントモデル（モデル部門1位）を受賞した東海地区の強豪チーム。
辻：構造モデルでオブジェクト図を描かなかったので、コミュニケーション図でインスタンスの構造的な関係も読み取ってもらいたいという狙いがあります。
手嶋：ちなみに私も2009年のモデルでコミュニケーション図を使いました。コミュニケーション図を使うと、オブジェクトの構造も描けるので、構造面と振る舞い面の対応関係が分かりやすくなります。
青木：オブジェクトがどのタスクに所属しているか示したい場合でもコミュニケーション図が有効ですね。一方、時系列に見せたい場合はシーケンス図が有効です。
青木：タスク間で共有する資源がある場合は、共有資源にアクセスするタイミングが重要になるからシーケンス図で排他制御を示すと有効ですね。今回は資源の共有がないのでコミュニケーション図でも十分です。
辻：悩んだ点としては、メッセージを同期で書くか非同期で書くかです。最終的には非同期で書くことになりましたが、本当は同期で書くべきところも非同期で書いています。だからリターンメッセージは一切ありません。
青木：同期と非同期は、実装によって変わるところなので分析レベルではどちらでも良いと思いますよ。分析レベルは基本的に実装に依存しないレベルで、意味的にどういうメッセージにすれば良いかを考えます。ここでは非同期でも良いのではないかなと思います。
国正：一番もめたのは「②エニグマエリアの振る舞い」の方位条件の表現を「時計回り180度」にするか「180度時計回り」にするかです。辻君と戦いましたね。今考えると、どちらでも良かったですけどね。
（一同笑い）
辻：特に林田さんと私の間で細かいバトルが頻繁にありました。
林田：大体、僕が折れました（笑）
青木：背景が違う人ほど、そのような衝突があるから面白いですね。逆に、そういう方が検討の余地が広がるのでお互いに納得する解が出てきます。議論がもう1段高い次元に行くので楽しいですね。
辻：感情的な対立になると悲惨になるので、好意的に思っている状態を維持しないといけませんね。
青木：お互いに目的が一緒だということで、抑えないといけないですね。
林田：その点は国正君が抑えに入ってくれたんよね。ほんまに助かったわ。結局のところ、チームメンバで言いあっても最後には気持ちよく合意できる信頼関係があったから、良い成果を出せたんやろうね。
中編の記事では、モデル審査でも評価の高かった構造分析や振る舞い分析を扱いました。いかがだったでしょうか？
今大会のモデリングで私が強く実感したことは以下です。
UMLは、元々図をまたがったトレーサビリティが確保できるように作られているモデリング言語ではあります。しかし、汎用的な言語であるため、特定のドメインに応用する時には十分なトレーサビリティを確保する能力はありません。UMLで描いたからと言って、モデル全てがトレーサビリティがあり、シンプルなモデルにはならないのです。このギャップを埋めるために、分析し、モデルを描き、モデル間の矛盾をチェックするという地道な作業を繰り返すのがモデリングという活動です。
今回は、田町レーシングがドメイン分析と構造分析の対応関係を分かりやすくしたり、構造分析と振る舞い分析のモデルがお互いにシンプルになるように洗練していったという工夫を紹介しました。チームによってモデルで表現したいことが違うでしょうから、ETロボコン2011の参加者は、田町レーシングとは違った方法が必要になるかもしれません。自分のチームが表現したいことに照らし合わせて、何をすべきか？は本記事を参考にして検討してみてください。
来月公開する後編で本連載記事も最終回です。後編では、難所の攻略方法とETロボコン2011に参加する人へのアドバイスを紹介します。お楽しみに。
| © 2011 OGIS-RI Co., Ltd. |
|
