|
[2010 年 2 月号] |
［レポート］
去る1月26日にETロボコン*12010の開催、そして近日中に公式サイトをオープンされることがアナウンスされました。毎年ETロボコンに参加されている常連チームの方々は、今か今かと待ち望んでおられると思います。
*1正式名称はETソフトウェアデザインロボットコンテスト、英語名はEmbedded Technology Software Design Robot Contest。
そこで、オブジェクトの広場では、2010年に参加する方々に向けてETロボコンにおけるモデリングのポイントやノウハウを提供するため、「田町レーシング」チーム*2のメンバーを中心に2009年のモデル審査を振り返る座談会を開催しました。
*2ETロボコン2009 東京地区大会のモデル部門・総合部門で優勝したオージス総研有志によるチーム。メンバ構成は、オージス総研の手嶋高明、時岡優のほか、社外から太田浩二、張存孝などを加えた計5名。
本記事は、その座談会で議論した、「モデル審査で評価されるシートの書き方」や「機能分析・構造分析におけるモデリングのポイント」をご紹介します。来月公開される後編の記事では、「振る舞い分析」や「難所の攻略方法」をご紹介する予定です。
なお、本記事では、「田町レーシング」チームが作成した東京地区大会とチャンピオンシップ大会のモデルを度々引用します。ぜひ、実際のモデルを手元に印刷して記事を読み進めてください。
ETロボコンは、組み込み分野におけるソフトウェアデザインの技術を競うロボットコンテストです。組み込み分野の学生および若手エンジニアへ分析・設計モデリングの教育機会を提供することを目的に、2002 年より組み込み総合技術展Embedded Technologyのイベントの1つとして毎年開催されています。
ETロボコンには、LEGO Mindstorms*3で作成したライントレースロボットが競技フィールドの走行タイムを競う競技部門と、ソフトウェア分析・設計の内容を競うモデル部門があり、両部門の総合的な成績で最終的なチャンピオンを決定します*4。競技内容は他のロボットコンテストと大きな違いはなく、モデルの審査があることに大きな特徴があります。
*3LEGO社が提供している教育用ロボット開発キット。
*4ETロボコン参加規約：https://www.etrobo.jp/ETROBO2009/gaiyou/sankakiyaku.html
モデル部門の審査では、ソフトウェア分析・設計の内容をまとめたモデルシート（A3紙 5枚）が「モデルの書き方」と「内容」の2つの観点で評価されます*5。さらに、「内容」の審査の内訳として以下の3点を評価することが定められており、競技者は審査基準に気を払いながらモデルシートを作成することになります。
*5モデル審査基準：https://www.etrobo.jp/ETROBO2009/gaiyou/model.html
そして、今年の目玉は、新しい走行体としてLEGO Mindstormsの新しいキット「LEGO Mindstorms NXT」を使った倒立振子ロボットが採用されたことです。光センサーを使って競技フィールド上の黒いレーンを識別しながらライントレースをすることは従来の走行体と同様ですが、新しい走行体では、左右にある2つの車輪でロボットが倒立した状態で、角速度を検知するジャイロセンサの情報をもとにマイコンで重心を制御しながらライントレースを実現します*6。
*6実際の倒立制御は参加者共通のライブララリで容易に実現でき、複雑な制御理論よりもソフトウェアの分析・設計に集中できるようになっています。
今回の座談会では以下の7名のメンバーで議論しました。
(1) 手嶋 高明 （2009年ETロボコン参加 東京地区大会モデル部門優勝メンバー）
組み込みソリューション部所属。ここ3年は半導体製造装置の開発に携わり、開発者を支援する立場として、開発プロセス改善やドメイン知識共有、支援ツール開発などを行っている。ETロボコン2009では時岡と共に「田町レーシング」チームのメンバーとして参加。東京地区大会のモデル部門でエクセレントモデル（1位）を受賞、総合部門で優勝し、チャンピオンチップ大会への出場を果たした。最近は、中国に興味を持ち、週末に中国語スクールに通いながら業務で関われないか妄想中。
(2) 時岡 優 （2009年ETロボコン参加 東京地区大会モデル部門優勝メンバー）
組み込みソリューション部所属。これまでマイコン制御の小さなシステムの開発から、MFP*7の大規模開発の業務まで幅広く携わる。ETロボコン2009では手嶋と共に「田町レーシングチーム」のメンバーとして参加。東京地区大会のモデル部門でエクセレントモデル（1位）を受賞、総合部門で優勝し、チャンピオンチップ大会への出場を果たした。ETロボコンへの参加を通じて、マイコンのポートを叩く素朴な組み込みソフトウェア開発だけでなく、ロボットを制御するアルゴリズムに関心がわいている。
*7Multifunction Peripheralの略称。複数の機能を搭載した複合的な周辺機器のこと。1台でプリンタとスキャナー、コピー機、FAXなどの機能を兼ねる機器などが該当する。
(3) 平岡 尚（2009年ETロボコン参加 新人チームメンバー）
組み込みソリューション部所属。組み込みソリューション部の新人チームメンバーとしてETロボコン2009に参加し、東京地区大会のモデル部門でシルバーモデル（3位）受賞。ETロボコンを通じてUMLでソフトウェアを表現することの面白さを実感した。
(4) 三村 次朗（2009年ETロボコン参加 新人チームメンバー）
組み込みソリューション部所属。組み込みソリューション部の新人チームメンバーとしてETロボコン2009に参加し、東京地区大会のモデル部門でシルバーモデル（3位）受賞。大学生の時からオブジェクト指向分析設計の興味があり、現在はオブジェクト指向分析設計のスキルを極めようと日夜努力している。
(5) 大西 洋平（モデル座談会のモデレータ）
組み込みソリューション部所属。新卒から3年目の現在まで、車載オーディオ機器の制御ソフトにおけるアーキテクチャ再構築業務に携わる。学生時代を含めてETロボコンに3回の参加経験があり、ETロボコン2008では学生時代の同期と共にチャンピオンシップ大会に出場した。毎回センサーの誤検知に苦しんでおり、本座談会では安定して走るための工夫に関心を寄せている。
(6) 山内 亨和（座談会のつっこみ担当）
ビジネスモデリング部所属。主にシステムの開発プロセスや調達プロセスを標準化、改善したり、実践の支援を行う。オブジェクトの広場等記事を書いているため、読み手に対し分かりやすく情報を見せることへ強い意識を持っている。特に日本語の使い方にはこだわる。
(7) 森原 剛（座談会のつっこみ担当）
ビジネスモデリング部所属。提案とコンサルティングに従事。かつては組み込みソリューション部に所属し、組み込みソフトウェア開発の現場に対する技術コンサルティングを提供していた。美しいモデルとその見せ方に関心を持つ。
座談会では、モデルシートの中身に入る前に、チームの意図を読み手に伝えやすくするための工夫から議論がスタートしました。ETロボコンのモデル審査では短時間でモデルシートの評価が行われるため、モデルシートの意図が容易に理解できることは非常に重要なポイントとなります。
時岡： 今回、チャンピオンシップ大会のモデルシート作成にあたって、どういう方針でモデリングしているかという説明を各シートに書くことにしました（図1）。各シートになぜ方針を書いたかというと、方針を実現できていることと、それがモデルにちゃんと表せていることを訴えたかったからです。
図1 チャンピオンシップ大会に提出したモデルシートの構成(クリックすると拡大します)
手嶋： さらに言うと、方針を初めに示せば、自分たちがどういうスタンスで臨んだのかを読み手に把握してもらえるので、後の説明を誤解なく理解してもらう効果も期待しています。
大西： シートの左上にモデルの方針、右下に「POINT」（モデルの注目点）を書いてありますよね。ここは審査員コメント*8で評価されていました。
*8審査を担当した審査員からモデルの良い点・悪い点をコメントしてもらえる。
三村： それは、いきなりモデルだけをバーンって出しているチームが多いからでしょうね。チャンピオンシップ大会出場チームのモデルシートは、かなり内容は正確でよく読めば分かります。でも、文章での説明がないと、どこに注目して良いか分からなくて読むのが大変です。
大西： おそらくは載せたい情報が山ほどある中で、5枚のモデルシートに納めるために、補足の文章を削ってモデルを多く載せてしまったんじゃないでしょうか？
山内：その場合って、書き手の伝えたいことと読み手が読んで理解したこととが一致していることを保証する材料が何もないんだよね。昔から業務でモデリングをやっている人でも方針や注目点を書かない人は結構多いけど、僕は図しかないモデルはあまり好きじゃないんだ。やっぱりモデルに対する説明が文章になっているのは大切だよ。
森原： 普段の業務の中でモデルの説明を書かないのは現実的な解だと思うよ。みんな普段は、ハイコンテキスト*9の中で、顔を突き合わせて同じ仕事をやっているから。わざわざ確認しないといけないことでもなければ、わざわざ文章で説明を書いたり、それをメンンテナンスしたりするコストが無駄になるんだよ。
*9文脈の共有性が高く、伝える努力やスキルがなくても、お互いに相手の意図を察しあうことで、なんとなく通じてしまう環境。
森原： だけど、こういうコンテストの場合、基本的にローコンテキスト*10だから方針や注目点を補足しないと読み手には伝わらない。
*10ハイコンテキストとは逆に、文脈に頼れず、言語によるコミュニケーションを重要視する環境。
山内： 確かに、ハイコンテキストの中でプロジェクトを回すためにモデルを描くという立場なら分かるね。文脈は日常的なコミュニケーションでずっと共有していて、あとは抽象化したモデルがあれば良いから。
でも、プロジェクトが終わった後に引き継ぐ相手や、お客さんに対して誤解なく伝えることを考えると、モデルだけじゃなくて、こういう文章での補足が必要になってくる。
ただ、モデルを書いている人達全員がお客さんと話すわけではないし、その次の引き継ぎ相手と顔を合わせる機会が少ないから、こういった文章が軽視されてしまう。それに、あまり注目しなくてもプロジェクトは回ってしまう。おそらく、お客さんと接している人は打ち合わせ資料にモデルの補足を書いて説明はしているんだろうけど、結局、成果物として残りづらいっていう現実があるのかも。
森原： そこ、もう1個ポイントがあるんだよね。メーカーの人達だと「直接のお客さん」は企画部門のいつも同じ相手が多いし、成果物に対する説明を口頭で補えるから、文章での説明を書くメリットを体験する機会が少なかったりする。
山内： 残念なことにビジネス系でも書かないプロジェクトが多いんだけれど、今回に関しては組み込み特有の状況っていうのもあるのかな。
大西： 一方、地区大会のモデルには、2枚目のシート以降、左上に方針が書かれていませんね（図2）。地区大会からチャンピオンシップ大会にかけて、シート作成の方針を変えた理由はなんでしょう？
 |
 |
| (1)地区予選のモデル：1枚目だけモデルの方針を書いた | (2)チャンピオンシップ大会： 全シートにモデルの方針を書いた |
図2 モデルの方針の記述（クリックすると拡大します）
時岡： 地区大会のモデルでは、最初の1枚目だけ方針を入れていましたね。これが審査員に結構ウケたから、チャンピオンシップ大会では全てのシートに方針を入れました。
時岡： なぜウケが良かったかというと、モデル審査基準に書かれているとおり、審査員の方々は「資料間のトレーサビリティ」を重要視しているからです。各シートのモデルをなぜ書いたのかを分かりやすく示すと、資料間の繋がりも分かりやすくなって、評価が良くなります。だから、「このシートで何が言いたいのか」を最初に書くことが良かったみたいです。
大西： 確かに、最近のETロボコンのトレンドで、モデルシート間のトレーサビリティを取る工夫をしているチームって結構ありますよね。モデル図の間で矛盾がないようにするのは当然で、さらにユースケースの実現性検証がどのシートに書いてあるか注釈をつけていたりします。
森原： それはぜだろう？一般の会社で「資料間のトレーサビリティ」が重要視され始めて、ETロボコンでも実践するチームが増えたんだろうか？
時岡： 前回のモデル部門の優勝チームがトレーサビリティを工夫していて、それを審査員が褒めたから、皆が真似し始めたんでしょうね。
手嶋： 確かに最近はトレーサビリティのために注釈を多用する傾向があるみたいです。だけど、僕たちのチームは注釈が多いと読みづらいと考えて、注釈がなくても資料の流れで理解できるようにしました。注釈はあくまでも最後の手段だと考えました。
山内： 仕事で提案書やレポートを書く側からすると、機能分析・ドメイン分析のシートのサブタイトルが「機能分析・ドメイン分析の方針」ってのが納得いかないな（図3）。
図3 機能分析・ドメイン分析のシートのサブタイトル
大西： 方針の具体的な内容が書いてある方が分かりやすいですよね。
森原： これってタイトルじゃなくてタイトルの枠なんだよね。言いかえれば、新聞の見出しで要約の代わりに「今日起きた事件」と書いているのと同じだよ。
三村： 例えば、このページだったら「機能分析とドメイン分析の中心はコースだ」と書いて欲しいですよね。
山内： そうなんだよ。最後の一行に「そこで私たちは、コースを起点として分析を進めることにしました」って結論が書いてあるのが残念だよね。 サブタイトルで最初に結論を示した方が、「このモデルはコースを中心に分析しているんだ」ってすぐに分かる。その後の説明を読むときも、「コースをどう解釈して、シートに反映しているんだろう」と心の準備をして読めるんですよ。
大西： 書籍や雑誌の記事を書く時に、目次を読んで内容が分かるようにすることと一緒の話ですよね。読み手からすると絶対その方が読みやすいと思います。
次に、実際のモデルシートの中身の議論に移りました。「田町レーシング」チームのモデルシートの1枚目ではドメイン分析と機能分析を扱っています。このシートでは、最初にソフトウェアのエッセンスをドメインモデルで示すことで、2枚目以降のモデルシートを理解しやすくする工夫がなされていました。
手嶋： ドメイン分析*11も審査員のウケが良かったです。ドメインモデル*12を書いているチームもありましたが、うちのチームみたいに自分達がコースをどう捉えているかを整理して、整理した結果をコースの定義としてシートに載せているチームはあまりいなかったように思います。例えば、「コースは区間の集合である」、「区間によって走行が決まる」のように（図4(a)）。
*11対象のシステムの分野が固有にもつ性質や知識を整理して、システム開発に有効に使おうというアプローチ。ETロボコンの場合、競技フィールド、走行体、競技ルールなどもドメイン分析の対象になりうる。
*12ドメイン分析の結果、対象システム固有の性質や知識を概念構造で現したモデル。
 |
 |
| (a) コースの定義（クリックすると拡大します） | (b) ドメインモデル |
図4 ドメイン分析の結果
山内： こういうのは良いよね。これはとても大事。
大西： 本当にコアな部分をドメインモデル（図4(b)）として出しているから、構造分析に入ってモデルの要素が増えていても、要点はつかみやすいですよね。
森原： これって、言わゆるメタファー*13も同じ効果を狙っているんだよね。「要するに、このシステムっていうのはこういうことなんだよ」っていうメタファーを示せば、複雑なことを書かなくても、それと同じだけの把握ができるんだよ。メタファーを使わない選択をしたとしても、これだけの内容が把握できないと、これ以降の説明が理解できないから、やっぱりメタファーを使いましょうって話になってくる。
*13認知言語学の用語で、ある概念領域を別の概念領域を用いて理解することを指す。アジャイルソフトウェア開発方法論のeXtream Programming(XP)でも採用されるモデリング手法。
時岡： メタファーと言えば、ETロボコンでも4～5年前にメタファーのブームがありました。そのきっかけを作ったチームは、走行体が前輪の首振りをしながら黒いレーンを辿る姿を、地面のフェロモンを辿る蟻に例えるメタファーを使っていましたね。
森原： 有名な逸話ですな。
手嶋： それをモデリングワークショップ*13でも、審査員がコメントしたんですよ。そしたら次の年にメタファーが大流行。それで、当時は新人チームとして参加していた僕らも悪ノリして、マニアックなメタファーを使ったんだよね。チームのメンバ全員が全員、メタファーを勘違いして「何かに例えればいいんでしょ？」みたいな感じになっちゃった（笑）
（一同笑）
*14チャンピオンシップ大会終了後に開催される審査員と参加者がモデリングについて議論を行う対話的な教育の場。審査員によるモデル解説ツアー、技術トピックを扱ったディスカッションなどが行われる。
大西： その年、確か、審査委員長がメタファーの乱用で訳が分からないとコメントしてませんでしたっけ？
森原： 何かに例えれば、深いレベルの内容が一瞬にして読み手に伝わるからメタファーを使うんだよ。やたらニッチな分野のメタファーを見せられても、審査員に前提知識がなかったら理解してもらえないよね。
大西： ドメイン分析では、何に注目しましたか？
時岡： 僕たちは、ETロボコンには「コース」をどう捉えるかがとても重要で、そこがすごく面白いところだと考えました（図5）。ETロボコンでは、競技のルールは1つでも、コースの捉え方次第でドメインモデルが変わる面白みがあるからです。
図5 ドメインモデルの注目点
時岡： 例えば、今回のロボコンのルールには、決められた地点を順番に通りさえすればルートは問わないことになっています。だから、最初はインコースでスタートして、アウトコースに飛び移ったり、逆走したり、柔軟な走り方をやっているチームをよく見ました。
さらに、走行体が新しくなり、去年よりもセンサの性能が向上したことで、走行体の位置を推測できるほど正確に制御できるようになりました。
手嶋： コース上に黒いレーンは書いてありますが、走行体の位置を推測すれば、レーンを辿る必要はないんですよね。難所の1つにショートカットという点線部分がありますが、去年までは一個づつ点を辿りながら走っているチームが多かったのに、今年は、もうレーンを全く無視して直進で走ったりしていた。
山内： 確かに、ルート通りに走る必要がないと捉えると、全然モデルが変わるよね。 本当にどこを通っても良いモデルにするのか？または、結果を出すための戦略を実現するようなドメインモデルにするのか？今回のはどっちに当たるんだろう？
手嶋： そこはかなり議論しましたね・・・。僕たちは最初にモデリングするときの視点を2つ考えました。
1つ目は「コースを最重要な要素と捉えて、コースを決めることで走り方が1つに決まる」という視点です。その場合、コースは区間の分け方とその組み合わせによって複数存在すると捉えます。そして走るコースを決めると走り方も1つに決まります。
2つ目は「走行戦略を最重要な要素と捉えて、走行戦略を決めることで走り方が1つに決まる」という視点です。その場合、コースはインコースとアウトコースの2つのみで、走行戦略を決めると走り方が1つに決まります。
今回採用したのは前者です。
大西： ドメインモデルの「走行体クラス」と「コースクラス」の間に関連が2つありますよね。それぞれ関連端名と多重度が違うようですが、この2つの関連の違いはなんでしょうか？（図6）
図6 チャンピオンシップ大会のドメインモデル
手嶋： POINTに書いている「コースは複数存在する」に関係しています（図5）。複数存在するコースを「登録コース」として持っていて、その中で実際に走るコースが「走行コース」です。例えば、ある「走行体」がコースAとコースBの2つを走ることができる場合、「走行体」は「登録コース」としてコースAとコースBを持っています。一方、「走行体」にコースAを走らせることを決めた場合、「走行体」は「走行コース」としてコースAを持っています。
時岡： この「登録コース」を出した意図は、「別のコースを走る時にプログラムを入れ替えることなく、動的に『走行コース』を選択できますよ」と言いたかったんですね。大会の競技規約でインコースとアウトコースを1回ずつ走ると決められているため、極端な話を言うと、インコース用とアウトコース用のプログラムをそれぞれ用意しなくちゃいけなくなります。「登録コース」を用意しておくと、プログラムを入れ替えることなく、動的に「走行コース」を変更できます。
さらに、選択できる「走行コース」はインコース・アウトコースという物理的なコースに依存しません。柔軟に区間を組み合わせたコースをたくさん用意しておいて、その時の状況に応じてどのコースを走るかその場で決められます。当日、あちこちに障害物が置かれていて通れないこともありますが、そういうケースにも柔軟に対応できます。
森原： 例えば、ショートカットを走るアウトコースと走らないアウトコースを登録して、いざ走る時に好きな方を選択することができるんですね。コースは1周分のことと考えていいんですか？
時岡： 基本的にはそう。ただ、1周するだけじゃなくて、テスト用にある区間だけを走るコースもあります。だから、1周かどうかではなく、走り切る単位がコースになります。例えば、「5周のタイムを測る」とルールが変更された場合、5周分が1コースになります。
モデルシート1枚目の2つ目のコンテンツは機能分析です。「田町レーシング」チームのモデルでは、ETロボコン参加者の多くが軽視しているユースケース記述を明示したことが審査での高評価につながりました。そして、ただユースケース図を見せるだけではなく、高い評価を受けるためにどの情報に焦点を当てるべきかについても議論が行われました。
手嶋： 自分達のモデルでは、ユースケース記述を掲載しました（図7）。でも、他のチームのモデルを見ていると、ユースケース記述を書かずにユースケース図だけを載せている場合が多くありました。審査員の方もおっしゃっていましたが、ユースケースはあくまでもシステムの機能を俯瞰して見る図です。ユースケース記述の方が大事なので、それを載せるべきです。
森原： コバーン*15は「ユースケース図は目次です」と言ってるし、僕も「目次だけ見せられてもね」ってよく言う。ハイコンテキストの中だと目次さえ見せれば十分伝わったりする。だけど、ローコンテキストの中だと「目次だけ見せるより中身くれよ」って話になる。
*15コバーン：アリスター・コバーン氏、『ユースケース実践ガイド』の著者。
山内： チャンピオンシップ大会のモデルで「キャリブレーションをする」というユースケースを増やした意図は何なんですか（図8）？明らかに1個増えてるから、何か意識が大きく変わったのかな？
 |
 |
| (a) 地区大会 | (b) チャンピオンシップ大会 |
図8 ユースケース図
手嶋： 地区大会の時は、コースを選択する際に走行パラメータを設定出来るようにしていました。これは「コースを選択する」のユースケース記述の備考として書きました（図9）。そして、チャンピオンシップの時に「キャリブレーションする」を大きな機能として捉え直したため、ユースケースとして付け加えました。
図9 「コースを選択する」のユースケース記述 （地区大会のモデル）
森原： 結局は、速く走れるかどうかで評価されるわけだから、それって今回の審査と関係があるの？
時岡： ETロボコンでは、走る前にその場の環境に合わせて光センサの設定を動的に調整できることが重要なんです。例えば、準備期間中に脱線してしまうことが度々あって、その原因を分析した結果、光センサの値をちゃんと調節できていなかったことが原因の1つだと分かりました。走行体は光センサを使って白いトラックと黒いレーンを識別しますが*16、会場の明るさや、コースの材質に大きな影響を受けてしまいます。だから、自分達のソフトウェアでは、ちゃんとその場の環境に合わせて調整できることを全面に出したかったんです。
*16光センサは、反射光の明るさで色を識別している。白い色は光が多く反射するため、大きなセンサ値が取れる。逆に黒い色の場合、反射が弱くて小さなセンサ値が取れる。その特性を活かして、競技フィールド上の白いトラック、黒いレーンを識別している。
森原： 「キャリブレーションする」機能が重要というのは、もちろん正しいと思う。このチームが「どんな天候でも確実にバッチリ走りますよ！」っていうのを売りにするのであれば、当然ここはユースケースとしてアピールすべき。でも、「今回は、みんなキャリブレーションやってるよね？」って状況では売りにはならないよね。紙面を割いて大きくフィーチャーする価値はない。
単純に「この機能は絶対必要だ！その機能が盛り込まれているぞ！」って伝えたいんだとすると、地区大会の「コースを選択する」の基本フローのように「(6) アクターが必要に応じて走行パラメータを設定する」って1行を書いてあるだけで十分だと思うよ。「ちゃんとありますよ」っていうのさえ示せば、「作ったソフトウェアとプレゼンテーション資料で内容が違う」と審査員に突っ込まれることはない。
だから、もっと売り込みたい所、目立たせたい所、重要だけど場所を大きく取ってしまう所に譲った方が良い。例えば、このチームのウリはバレリーナ走行*17にあるとするじゃない。そしたら、キャリブレーションよりバレリーナ走行を大々的にフィーチャーした方が良い。
*17田町レーシングチームが編み出したショートカット区間の走行方法。バレリーナのようにくるくる回る走行が会場を大きく盛り上げたことがが評価され、＠IT MONOistから「＠IT MONOist賞」を受賞するきっかけとなった。 https://monoist.atmarkit.co.jp/fembedded/articles/robocon/etrobocon2009/08/etrobocon08b.html
森原： これって言いかえれば、もう1個メタなレベルでのドメイン分析なんだよね。「ETロボコンっていうコンテストで何が評価されるのか？」というドメイン分析なんだよ。これは実際の保守でも重要で、「どこが保守をする上で大変なとこなの？」っていうのが、読み手、つまり引継ぎを受ける側の関心事になるわけね。そこは、ばっちりドキュメンテーションすることになる。ここは作る価値が非常にあるし、伝えるべきところになる。
次にモデルシート2枚目の構造分析について議論が行われました。クラスの責務分担を改善することで再利用性が大きく向上した事例があるものの、一方でドメインモデルと構造分析のトレーサビリティが取れていないことが指摘されました。
大西： 地区大会とチャンピオンシップ大会の構造分析（2枚目のシート）では、大きく構成が変わっているようですね（図10）。クラス図を大きく変えているんでしょうか？
 |
 |
| (1) 地区大会 | (2)チャンピオンシップ大会 |
図10 構造分析のモデル (クリックすると拡大します）
手嶋： 両者の基本構造を見てもらえば分かると思うけど、クラス図自体は大きく変えてはいなくて、構造分析のアピールの仕方を変えました（図11）。地区大会ではシステムを2つのレイヤーに分けて、「変更を局所化」できることをアピールしています。一方で、チャンピオンシップ大会では「クラスの責務分担が明確」になっていることアピールしています。なぜこのように変えたかというと、地区大会での分析方針が実際にはあまり役に立たなかったからなんです。
 |
 |
| (a) 地区大会 | (b) チャンピオンシップ大会 |
図11 構造分析でのアピールの違い
手嶋： 具体的に言うと、当初は走り方を変えるために目的レベルのレイヤーにある区間の分け方や組み合わせを変更しても、実現レベルのレイヤーにある走行・検知のロジックを変更する必要はないと考えていました。しかし、実際に作り始めるとレイヤーの区分けがそんなに役に立たたないことが分かりました。例えば、走る区間を変えると変更した区間に合わせて、新しい走行クラスを追加しなければいけないケースが多々ありました。これはトラック上ならどこを走ってもいいETロボコンの競技の特徴が大きく影響していると思います。どこを走ってもいいが故に、新しいルートを考えると、そのルートに含まれる区間固有の走行も追加しなければならないケースが多かったわけです。
時岡： そこでレイヤーを2つを分けてもメリットがないという結論に至って、2番目に重点を置いていた「クラスの責務」を前面に押し出す形にシートを変更しました。
山内： なるほど。だから、チャンピオンシップ大会のモデルではクラスの責務を表でまとめているんだね。でも、せっかくまとめているのに、表とクラス図が分離されてしまって、各クラスに対する責務の割当てが適当なのか判断しづらくなっているね。クラス図中のクラスのコンパートメント*18に直接責務を書き込んでみてもおもしろいかなと思います。
*18クラスの名前や属性・操作などを記述する区画のこと。
時岡： クラスの責務分担を重要視することで良かったことがあります。それは「走行クラス」の責務を変えて、再利用性を大きく向上できたことです。
地区大会では走行クラスのサブクラスの責務範囲が通常の区間や難所ごとでしたが、チャンピオンシップ大会ではサブクラスの粒度をより細かい単位に変更しました（図12）。これにより「走行クラス」の再利用性が向上しています。
 |
 |
| (a) 地区大会（一部抜粋） | (b) チャンピオンシップ大会 |
図12 走行クラス
時岡： 例えば、地区大会ではインコースのツインループ区間*19を走る「ループスキップ走行クラス」は、完全にツインループ区間専用のクラスになっていました（図13(a)）。一方、チャンピオンシップ大会ではどの区間でも汎用的に使える「PDエッジ走行クラス」と「マニュアル走行クラス」の組み合わせでツインループ区間を走行しています（図13(b)）。
*19インコースの難所の1つ。円を二つ隣接させた形となっている。
 |
 |
| (a) 地区大会 | (b) チャンピオンシップ大会 |
図13 インコースの難所「ツインループ」を走る際のオブジェクト構成例
手嶋： 地区大会のモデルは個々の「走行クラス」のロジックは複雑でインスタンス数が少ない、チャンピオンシップ大会のモデルは個々の「走行クラス」のロジックが簡単でインスタンス数が多い、という違いもあります。構造分析のモデルでは単純にオブジェクト構成例を示していいますが、チャンピオンシップ大会では、4枚目のシートで難所走行を例に「インスタンスの組み合わせを変えることで、走り方を柔軟に変更できる」というメリットを説明しています。
森原： ドメインモデルと構造分析モデルの基本構造が合ってないよね。「走行体クラス」と「コースクラス」の間の関連が、いつのまにか2個から1個に変わっている（図14）。
 |
 |
| (a) ドメインモデル | (b) 分析モデルの基本構造（一部抜粋） |
図14 ドメインモデルと分析モデルの違い
時岡： 元々は関連端に「登録コース」がある方の関連に「コースリストクラス」を抽出したからですね。
なぜこの「コースリストクラス」を抽出したかというと、詳細に分析したときに多重度で「コースクラス」を持つよりも、複数コースをまとめてくれるような「コースリストクラス」を出した方がモデルがよりシンプルになると気づいたからです。具体的に言うと、地区大会の振る舞い分析でユースケースの実現性を検討したところ、「登録コース」のインスタンスが複数個あるせいで「コースを選択する」のコミュニケーション図が非常に複雑になってしまいました（図15）。そこで、チャンピオンシップ大会では、「登録コース」を扱いやすい形でまとめる役割を持ったクラスとして、「コースリストクラス」を抽出したところ、モデルが非常にすっきりしたんです（図16）。
図15「コースを選択する」 のコミュニケーション図（地区大会）
図16「コースを設定する」のコミュニケーション図（チャンピオンシップ大会）
森原： 最初思いついたのはドメインモデルの形だけど、もう少し下流に入ってみたら「コースリストクラス」があった方がモデルがすっきりしたってことか。「コースリストクラス」に関しては、実現方法としてあった方が良いって話ではなくて、モデルが把握しやするためって話だよね？そういうことだと、頭の中ではドメインモデルが変わってるのに、ドキュメント上でフィードバックできてないように思えるな。だとすると、僕はドメインモデルが間違っていると僕は見る。「コースリスト」が大事な概念ならドメインモデルの方にも無きゃおかしいよね。
森原： 審査員がトレーサビリティを非常に重視するんだとすると、ドメインモデルと構造分析の間のトレーサビリティを無視しっちゃってるのは非常にもったいないよね。
平岡： 区間の区切りを見つける方法を抽象化して、「端点検知クラス」を抽出しているのには驚きました（図17）。しかも、「端点検知クラス」のサブクラスも再利用を意識してか、責務の粒度が小さいクラスになっていますね。自分達、新人チームではマーカー*20を検知するための「灰色検知クラス」だけしか抽出していませんでした。
*20これから難所に入る直前にいることの目印として灰色のラインがある。多くのチームはマーカーを見つけることで、通常の走行と難所の走行を切り分けている。
図17 端点検知クラスとそのサブクラス
手嶋： このクラスを出した経緯は逆なんだよね。どちらかというとトップダウン。区間が切り替わっていく際に、区間の中の走行は「走行クラス」で実現しているけど、区間が切り替わるきっかけを検知するクラスが必要になってきて「端点検知クラス」を抽出した。端点を検知する具体的な実現手段として、いろんな情報を収集できるから、その情報ごとにサブクラスを出していった。例えば、明るさ（輝度）だったり、走った距離であったりとか、時間であったり。
－ － － － － －
森原： ん？ところで、ここでこんなに盛り上がっていいんだっけ？
大西： 2枚で2時間以上もしゃべっています！このままだと座談会が5時間以上になりますよ！
(一同笑)
（座談会 後編に続く）
座談会前編の記事はいかがだったでしょうか？今回の記事では、「田町レーシング」チームのモデルが東京地区大会で評価されたポイントを中心に、チームの意図を審査員へ伝えやすくする資料の作り方やドメインモデル作成の工夫を紹介しました。これらのノウハウは、ETロボコン2010でも有用なものであると思いますので、ぜひ活用してください。その際は、自分たちが書きたい事を盛り込んだ情報過多なモデルではなく、審査に評価されるポイントや「チームの売り」を中心にしたシンプルなモデルを心がけると、モデル部門での好成績につながるでしょう。
来月公開予定の後編では、「振る舞い分析」と「難所の攻略方法」を扱います。「振る舞い分析」では構造分析モデルの実現性を検証する方法、「難所の攻略方法」ではモデル審査基準における性能面でアピールする方法などをご紹介します。お楽しみに。
| © 2010 OGIS-RI Co., Ltd. |
|
