(cache) ETロボコン2010 東京地区大会Aブロック　モデルワークショップ

審査方法・総合評価方法について（本部　中嶋審査員）
東京地区大会　モデル審査傾向と所感　（東京　門倉審査委員長）
オブジェクト抽出　－視点からオブジェクトを導くー（本部　幸加木審査委員）
ソースコード品質評価活動の結果報告（東京　田邊審査アシスタント）
アンケートによるQ&A
1. 気になったモデル＆性能（東京　阿左美＆宮田審査委員）
2. チーム間でのQ&A　（参加者全員）
PMレポート共有プロジェクトのお誘い

1．審査方法・総合評価方法について（本部　中嶋審査員）

審査方法
- 昨年との違い
  - モデルの書き方と内容は昨年と同じ。追加課題とオリジナリティが増えている
  - モデルの書き方・内容は減点式で採点する。
  - 新たに追加した追加課題とオリジナリティは加点式で採点する。
  - きっちりモデル書いていれば、平均的な点は出る。その上でオリジナルなことをやると高得点になる。
  - 追加課題をやれば満点を超える可能性があるが、満点を超えた超過分はカットする。
- 総合結果はモデルと競技の調和平均で順位を決めるため、両方良い点じゃないと総合では良い成績にならない。
- モデル審査は予備審査と最終審査で2回行う。
  - 予備審査では、モデル審査チームと性能審査チームで一次審査する。
  - 1次審査の結果は後で調整する。なぜ、このモデルがBなのかなどを話し合って、評価がそろうようにする。
  - 性能審査は東海実行委員がやっている。めちゃめちゃ厳しい。
  - 最終審査では、各審査委員が自分が好きなモデルに投票して、上位3チームを選ぶ。
新しい審査基準：並行性設計
- 組み込みでは、本来、並行性は当たり前でしょ。
- NXTは並行で動作させる可能性があるものはいっぱいある。
- 必要かどうかはチームごとの方針に従って出してもらう。
- その設計指針が妥当であるか、モデルで適切に表現されているかを審査で確認する。
- 並行性は東京地区で23チーム（約4割）くらいが挑戦していた。
新しい審査基準：オリジナリティ
- オリジナリティは新しい試み、斬新な切り口、審査員に面白いねと思わせるものが入っていれば、評価する。
- ※追加課題より、オリジナリティの方が重みが高い？
東京地区がんばれ！
- 東京地区は自然光が入る環境でやる分、不利ではあるが、難所に挑戦しないチームが多い。
- 九州地区は完全制覇をしたチームがいる。
- 東京地区は完走率3割。九州は5割6割。

2．東京地区大会　モデル審査傾向と所感　（東京　門倉審査委員長）

機能面
- レベルは上がりつつある。
- UCを導き出した経緯が分かるチームがある。
- UCがユーザ視点になっていないチームが多い。
- UCの関連が上手く出来ていないチームが多い。
- 昨年よりUC記述を書くチームが増えている。
- ただ書くだけじゃなく、UCを書く目的を分かってほしい。
- 要求図使っているチームあり。

構造面
- 全体的に構造はダメ。
- 多重度や関連端名がないチームアリ。
- 多重度1対1が多い。インスタンスとクラスの違いをわかってない可能性あり。
- 責務ではなく処理で分けているチームあり。
- メタボクラスが多い。
- 似たような構造モデルが多い。

振る舞い
- 振る舞い表現するチームが増えている。
- アクティビティ図を使用していているチームが多い。
- 状態を表現するスコープが適切でない。
- シート上でポイントにしている部分とは、全く違う箇所の振る舞いを書いているチームあり。
- イベントやアクションを書いていないチーム多い。
- 何の状態か分からないチーム多い。

トレーサビリティ
- 構造と振る舞いで矛盾しているチームが減った。
- しかし、機能・構造・振る舞いで矛盾があるチームがある。機能分析が機能分析だけで終わっている。
- 図をとりあえずそろえたという印象。

難所
- 階段・シーソーは複数の要素技術の組み合わせでやっているチームが多い。
ミステリー
- モデルでも挑戦しているチームが多い

並行性
- 取り組んでいるチームは23チーム。効果がある判断されたチームは少ない。
- 位置情報やノイズ除去など時間の関係でタスク分けているチームあり。
モデルの表現
- 構造面での表記が弱い。アクティブクラスが書かれていない。
オリジナリティ
- まいまい式を改良しているチームあり。
- マップツールを分析に利用チームあり。

モデルの見せ方
- 表記ルールに外れていない。
- 色分け、配置とかきれいにできている。

レベルと傾向
- トップクラスはヌケめない。
- 中位以下はある側面が抜けている。

おまけ
- 高校生チームが検討している。

3．オブジェクト抽出　－視点からオブジェクトを導く－（本部　幸加木審査委員）

オブジェクト抽出のポイントは”視点”である。
視点とは、どこから見ているかという対象。立ち位置。
同じ対象なのに、別の呼び名で呼んだりる場合がある。
ここに水の入ったペットボトルがあるとして、ある人は飲み物と答え、ある人はペットボトルであると答える。
視点の違いは何か？
- どんな視点が隠れているか？立脚点が違う。
- 容器の種別を考えている人はペットボトルと答える。
- 飲み物の種類と考える人は水と答える。
物理オブジェクトは1つでも、それを見る視点で、概念オブジェクトが違う。
オブジェクトを抽出する時は、視点を考える。
概念オブジェクトは、見る視点で変わる。
捉える視点が違うと、違うオブジェクトが出てくる。
オブジェクトの抽出課題として「シーソー区間」を考えてみよう。
コースの視点だと？形状の視点だと？ゲートの視点だと？
視点を変えると色々出てくる。
さらに一歩先は、「立てた戦略から、どの視点が一番大事な視点か？」を考えること。それがクラス化へのヒント。
オブジェクトファースト with 視点。基本を大事に。

4．ソースコード品質評価活動の結果報告（東京　田邊審査アシスタント）

今日のテーマ
- ロボコンのソースコード品質ってどのくらい？
- 設計品質とソースコード品質の関係は？
- ソースコード品質評価はソフトウェアの品質改善に結びつくのか？
- ※ここで言う設計品質の「設計」とは要求分析・分析・設計を一まとめにしている。
活動の紹介
- 設計品質と走行性能の差をうめたい。
- 走行体に実際に乗っているのはソースコード。
- ソースコード品質に対する意識向上をするための機会づくりとしたい。
品質評価の方法
- Adqua（あどくあ）というツールを使っている。
- 詳細は以下。
- http://tokyo.etrobo.jp/pdf/20100524_03.pdf
評価結果
- 提出は5チームのみ。
- C：1チーム、C++：4チーム
- C++もCも3000行程度。
- ほとんどのプロジェクトで、実製品開発から収集した結果の平均点を上回る。
- 全体を見通せる規模なので、品質が劣化しにくいのでは？
モデル品質とソースコード品質
- 某チームその1の結果を例に
  - モデルの良さがソースコードの品質につながっていることが分かった。
  - ただし、モデルでは安定性をうたっているが、ソースコード品質では保守性の中の安定性が低い。
  - ※ここで言う安定性とは、一部の設計を変更した時に、他のモジュールなどの設計に影響を与える度合い。
  - 安定性が低くなった原因は、設計で想定していない依存が含まれていたこと。
  - レイヤを飛び越えた依存、相互依存など。
  - この結果から、良いモデルは良いソースコードにつながることが分かった。
  - ただし、設計で想定していない実装をすると、実装段階で品質が崩れるとになる。

某チームその2の結果を例に
- 設計は責務の大きいクラスが多い、特定のクラスに責務が集中していた。
- 実装では、設計の問題がソースコードに影響していた。
- 設計での凝集度や結合度は実装品質に影響する。
- 設計で担保した品質以上を実装で目指すのは難しい。

ソースコードのみで改善できるポイントとしては、暗黙の型変換、メンバの初期化、コピーコンストラクタや代入演算子を定義するなど。
Effective C++などに例は載っている。

某チームの例を改善すると？
- 設計どおりに実装を修正する。そうすると、実際に安定性の品質は上がった。
- 上位レイヤーから直接デバイスレイヤーを呼ばず、中間に抽象化レイヤを用意する。
- 設計で良いものを作り、設計どおりに実装すれば、ソースコードを品質を上げられる

今後のソースコード品質評価活動の展望
- サンプル数が少ないため、もう一度、東京地区で募集する。
- 関西地区でも同様の取り組みをやる。
- 評価結果の分析を続ける。
  - モデルとの相関を分析する。
  - 分析結果をなんらかの形で発表する。
  - 早稲田大学の鷲崎先生と共同研究する。
- 評価の結果は、モデル審査に影響しない。

5．アンケートによるQ&A

1）気になったモデル＆性能（東京　 阿左美＆宮田審査委員）

モデルと性能の相関
- 田町レーシング
  - （問）だいたいのチームは、段差を両輪で乗り越えるが、田町レーシングだけ、段差を片輪で乗り越えると書いている。これは本当に成功するのか？
- （答)練習をやっている限りでは、成功確率は高い。速くない。

モデル審査
- selfD
  - 要求分析で機能を整理し、一覧化している。
  - ユースケース記述を詳細定義している。
  - 全部出さなくても良いが、一部出した方が良い。
  - （問）モデルシート上でユースケースにコースが重なっており、視認性が悪い。重ねた理由は？
  - （答）一目見て、コースとの対応がついて分かりやすいと思ったから。時間の関係でコースの緑を薄く出来なかった。
  - ユースケースのincludeとextendを使っているが、ユースケース記述にその関係が明記されていない。

田町レーシング
- 要求や戦略から、構造を導出するアプローチが良い。
- （問）走行体というクラスに複数の役割が集約させれている。その理由は？
- （答）走行体に関係する情報は走行体にまとめた方が変更に強くなる。分かりやすい
- あまり回答に納得できない。

2）チーム間でのQ&A　（参加者全員）

？？？→特命平社員
- 他のチームジャイロを使って段差を見ていたが、特命平社員だけモータの回転を見ていた。
- （問）他のセンサは見ていたか？
- （答）ジャイロはゆれ続けて安定しないので、使わなかった。段差を超えたときに加速するので、回転速度で判断できる。
- （問）偏差って何？
- （答）偏差は引き算。過去の値から現在の値を引いた結果。

ねっともん→VDM
- （問）VDMとUMLの違いは何か？
- （答）UMLは全体を俯瞰するのに向いている。
- （答）VDMは詳細な仕様を書くのに向いている。どんな制約が必要か？など。しかし、VDMは全体が分かりにくい。
- （答）全体はUML、詳細な仕様はVDMで書くと良い。

飯亭ロボ魂 PART1→裏裏方さん
- （問）マルチタスクにした理由は？導入したメリットを教えてほしい。
- （答）予定では、走行状態を確認するタスク、難所ごとに条件判定を別タスクにしようした。実際は前者のみ。
- （答）実際にはマルチタスクにはできていない。
- （答）4msec以内に情報を取得して、リアルタイム性を高めたかった。

マルチタスクに関する審査コメント
- マルチタスクにするには動機が必要。それがないと、何がうれしいのか分からない。
- 何が何でもマルチタスクにしなくても良い。
- 九州では、マルチタスクにしなくて良い理由をちゃんと説明しているチームがあった。

hrp→Mashi-Mashi
- 非常に正確で、すばやい走行をした。
- （問）なぜ難所を挑戦しなかった？
- （答）単に時間がなかった。

審査員コメント
- （問）他のチームと違い、論文形式で書いている。なんでこんな書き方をした？
- ※ここは質問と回答が食い違う。質問はなぜ論文形式にしたかであるが、UMLモデルではなくSimulinkモデルを書いた理由が述べられる。

（答）UMLを良く知らない。
（答）また、うちのチームは自然現象は振る舞いで表現できないと考えており、すべて微分方程式をたてて、それを解くという方針にした。

審査員コメント
- 全体像が分かりづらい。
- （問）階層のイメージが分からない。NXTをモデル化した？コースをモデル化した？センサをモデル化した？専門家の方しか読めない。気を使ってほしい。
- ※ここでも質問と回答が食い違う。コンポーネント？レイヤーごとの目的・役割が分からないという質問に対して、Simulinkモデルの読み方に対して回答があった。

（答）右から左に計算が流れるので、それを順番に読めば分かる。

審査員コメント
- 読み方は知っている。ここで何をしているのか？が読み取れなかった。
- （問）今回のコース以外でも使えるか？汎用的なものかも読み取れなかった。
- （答）実際に他のコースでも使える汎用的なもの。

うちのチームは、コースの画像データからを座標データを抽出した。ソフトウェアでは座標に沿って走る。単に、点をつたう度に予測するのではなく、ある程度、先を予測しながら走る。

審査員コメント
- モデルでその意図が読み取れなかった。そこを書いてほしい。

宇部レーシング→田町レーシング
- （問）ユースケースの粒度が他のチームより大きいが、ユースケース抽出のポリシーは？
- （答）ユーザ視点で、ユーザに勝ちあるものをユースケースとして抽出した。
- （答）粒度をそろえること、最も重要なもの何か？を意識した。
- （答）詳細は、要求図で掘り下げているので、ユースケース図で詳細を書く必要はないと判断した。