モデル検討に専念できる!! 「BridgePoint」によるアプローチ：3つの設計アプローチで見るETロボコン参戦記録（5）（2/3 ページ）

[田村純一／監修：土樋祐希（富士ゼロックス），＠IT MONOist]

モデル作成

　私たちのチームでは、メンバー全員がスキルアップを目的にこの活動に参加していたため、研修やセミナーなどにも積極的に参加するようにしました。特に、南関東大会では参加者向けの独自セミナーが多く、モデル提出までの間に毎週のように開催されていたので、メンバーの1人は必ず参加するようにしました。

　研修やセミナー受講の影響もあり、はじめの1カ月ぐらいは研修やセミナーで習得した手法などを用いて机上でモデルを一生懸命考えていました。しかし、このころはロボットの特性や、どのように走らせるかというようなことを十分に理解していない状態で、クラス図などの分析モデルをいきなり作ろうとしていました。そのため、モデルの議論は収束せず、時間だけが過ぎて行きました。

　そのようなとき、活動の全体リーダーである土樋から、

実際にロボットをどのように走らせたいかというシナリオを考えないと分析クラス図は作れない！

というアドバイスを受け、ボトムアップ的に検討を進めていくようにしたところ、議論が前進するようになりました。走行するコース図を各自がプリントして、付せんにシナリオを書き込むというアナログな手法でしたが、どのような走りを目指しているのかを整理できて非常に効果的でした。

　約2週間のシナリオ検討の結果、私たちのチームではアクション（走行アクション）と変更条件をインスタンス化し、それらを組み替えることでさまざまな走りを実現するという方法で戦略を構築することにしました。実際に構築した戦略（インコースのガレージイン）の例を図6に示します。

図6　ガレージイン（インコース）の戦略例

　図6内にある、赤い四角が「走行アクション」、青い四角が「変更条件」を表しています。このような実際のシナリオを考慮して、それを実現するソフトウェアの構造を考えていきました。私たちのチームでは、モデルを作成するに当たり、いきなり完成品を目指すのではなく、メンバーの誰かにモデルの土台（たたき台）を作成してきてもらい、それを週1回のミーティングで作成者も含めてメンバー全員で議論するという形式で検討を進めていきました。このようにすることで、円滑に情報共有ができるとともに、作成者だけではなく、メンバー全員でモデルを作り上げることができました。

　モデル検討では、システムを3つのドメインに分割し、各ドメインに1人ずつの担当を割り振りました。「戦略ドメイン」ではコース走行戦略の組み立て、「足回りドメイン」ではロボットの走行、「検知ドメイン」では検知条件のマッチングという役割を担っています。

図7　3つのドメインとその関係

　このようなドメイン構成を基本として、分析クラス図やステートマシン図の検討を進めていきました。BridgePointで開発する場合、モデルからソースコードを自動生成するので、この2つの図が非常に重要となります。分析クラス図は、クラス間の関係と属性を重視して作成しました。例えば、あるクラスの機能を実現するために必要な情報が、そのクラス自身の属性、もしくは別のクラスの属性の関連をたどって取得できるかどうかを常に確認するようにしました。私たちのチームが作成した分析クラス図のうち、戦略ドメインのクラス図を図8に示します。

図8　作成した分析クラス図

　ステートマシン図では、3つのドメイン間で情報のやりとりを行うために、どのような状態やイベントが必要なのかを常に考えながら作成しました。

BridgePointでのモデルの作成と検証

　BridgePointを使うに当たり、6月3日、4日の2日間、アフレルの久保秋真氏によるBridgePoint講習会を受講しました。これは今回の参加者にBridgePointを使ったことのあるメンバーがほとんどいないということで、当社のロボコン活動事務局が企画したものです。この研修を通じて、BridgePointがどのようなツールであるかということをきちんと理解することができました。研修内容は、BridgePointで作成したモデルから実際にソースコードを生成し、ETロボコンのロボット（一部荷台が付くなどの変更がされていました）を走行させる演習を交えたものでした。

　この研修では、BridgePointでロボットを走行させる骨組みがあらかじめ用意されていました。そのため、研修で実際にBridgePointを用いてステートマシン図を編集し、ソースコードを生成、ロボットを走らせるという一連の流れを体験することができ、モデルからソースコードが自動生成される仕組みやBridgePoint自体の理解度が高まりました。

　また、この研修はBridgePoint以外の点でも役立ちました。前述した“誰かが土台を作成して、それをメンバー全員で議論する”という形式は、実はこの研修で教えてもらったやり方です。分析モデルの検討と並行し、こうした取り組みを通じて、自分たちのモデルがBridgePointを使ってどのように実現されるかというイメージを固めていきました。

　8月5日にはツールスポンサーのメンター・グラフィックス社から、参加者向けにツールが提供されました。実は、モデル提出期限（8月18日）の2週間前の時点で、モデル検討に多くの時間が取られてしまい、BridgePointを使用した開発に着手できたのはモデル提出後でした。そのため、私たちはモデル提出した翌日からBridgePointによるモデルの作成を急ピッチで進めることになりました。

　BridgePointでの作業は、提出したモデルをほぼそのまま入力するという作業になります。Executable UMLのやり方に沿ってモデルを作っていたので、この作業自体は（ツールへの慣れは別として）難しくはありませんでした。ただ、ソースコードを自動生成する際に、クラス図などに漢字が含まれているとエラーになるといった制限があったため、名前を変えるといった作業が必要でした。図9にBridgePointに入力したクラス図を示します。

図9　BridgePointに入力したクラス図

　作成したモデルは前述したVerifierを使用して動作させ、状態やアクションがうまく定義されているかどうかを確認しました。