設計と難所への挑戦

2011年10月11日(火)
吉田 彩花舟元 拓斗

振る舞いの分析

  1. [吉田] 今回は動的な分析をするんだったね。
  2. [舟元] そう、そう。この前は静的な分析だったから、ベーシックステージ、ボーナスステージ、難所の順番なんかが分からないままだからね。
  3. [吉田] (>.

  1. [舟元] 前回分析した、「感知する」と「切り替える」に注目してみたらどうかな?ステージや難所の前には灰色のライン「マーカー」があって、それを感知したら切り替える。
  2. [吉田] なるほど。マーカー駆動、マーカードリブン、MKDか!
  3. [舟元] 。。。
  4. [吉田] アウトコースの振る舞いをベタで分析するとこんな感じかな?

図1:アウトコースの振る舞いを分析したところ(クリックで拡大)
  1. [舟元] そうだね。インコースも同じようになるだろうね。次はこいつらを基に設計していこう。

いざ設計

  1. [吉田] 設計ってのはソフトウエアとしてどうやって実現するかを検討することだよね。
  2. [舟元] うん。前回の分析結果を基に静的構造から考えると良いと思うんだけど、まず、前回の結果の切り替える部分を全部洗い出すところから始めようか。
  3. [吉田] だね。こんな感じかな。
  4. [舟元] うんうん。

図2:切り替えの部分を細く洗いだしたところ
  1. [吉田] マーカーを感知するごとに切り替えるんだよね。どうしようかな?「感知する」、「切り替える」ってのは動作だし、「ルックアップゲート」とか「ET相撲」は「走り方」が違うだけで「走る」っていう点で同じようなナカマって感じ。仲間ね。
  2. [舟元] うん。うん。「どうやって走行するかが違う」というところが大事だね。「どうやって走行するか」っていう事柄に対して、その特徴(「どうやって」の部分)が何パターンかある。って気付けたら、設計の方針が何パターンか出せるね。
  1. 抽象クラスを設けて、サブクラスで走行方法の差分を実装する。
  2. インターフェース設けて、実装クラスで走行方法を実装する。
  1. [舟元] 抽象クラスにするか、インターフェースにするかは、共通度合いとかで使い分けたりするかな。あとは、実装言語の仕様とかも気にしないといけないね。
  2. [吉田] (さすが経験者。。。)じゃあさ、具体的に「どうやって走行するか(実装であったり制御方法であったり)」は後で考えるとして、「走行の仕方」って捉えられそうなモノをピックアップしてまとめてみよう。まずは、親クラス、、、抽象度の高い表現で「走行状態」とでもしておこっか。で、この「走行状態」クラスのサブクラスになりそうなものは、走り方だから、難所とかだよね、、、っと、こんな感じかな。

図3:走行状態のサブクラスを追加したところ
  1. [吉田] 「平面走行」と「坂道走行」は「ベーシックステージ走行状態」という一つのクラスにまとめたよ。
  2. [舟元] 「感知する」とか「切り替える」はどうする?
  3. [吉田] それって、動作だから「走行体」にさせれば良いんじゃないの?「走行体」がマーカーを感知して、状態を切り替える。どうかな?
株式会社 永和システムマネジメント

永和システムマネジメントに2011年入社。文系出身で右も左もプログラミングも分からない中、ETロボコンへの参加を命じられ四苦八苦中。

株式会社 永和システムマネジメント

永和システムマネジメントに2011年入社。学生時代に二度ETロボコンに参戦。配属されてから役に立ちそうな技術・知識を盗むべく奮闘中。

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています