9/24（土）に開催されたETロボコン東京地区大会Bブロックのワークショップに参加しました。良い話がいろいろ出たのでブログに書いておきます。
個人的なハイライトは「気になったモデルについてQ&A」でした。審査員と全員で対話的にモデルについて議論する良いセッションでした。時間が足りなさすぎたのが少し残念。
アジェンダ
- 審査内容の説明 - ニューウェイブシステム(株) 斎藤 司氏
- モデル審査結果の傾向 - (株)オージス総研 阿左美 勝氏
- 気になったモデルについてQ&A - (株)オージス総研 田邉 浩之氏
- PMレポート共有について - (株)建設技術研究所 東谷 上氏
審査内容の説明 - ニューウェイブシステム(株) 斎藤 司氏
公式サイトのモデル審査基準の紹介がありました。公式サイトに書いていますので、ここでは省略します。
http://www.etrobo.jp/2011/gaiyou/model.php
モデル審査結果の傾向 - (株)オージス総研 阿左美 勝氏
審査後に審査員同士の振り返りで挙った良いモデルとダメなモデルについて紹介がありました。
ここに紹介されている通り、まだUMLの文法として基本的な間違いをしているチームはまだまだ多いようです。こういうので減点はつまらないので、レビューで取り除くことをオススメします。
書き方
悪い例
- UMLの文法として不備がある。
- （例）多重度のないクラス図、開始状態のないステートマシン図、など。
- 印刷物として読み取れない。審査基準にも図の見やすさは明記しているので、印刷物として読めないと減点対象。
- （例）文字が小さい、背景の画像で関連が見えない、など。
悪い例
- アクターを「NXT」にしている。アクターはシステムの価値提供の相手なので、アクターとしてNXTは不適切。
- ユースケース間の関係に間違いがある。includeにすべきところがextendになっている。
- ユースケース記述が詳細すぎる。ユースケースは要件定義の段階の成果物なので、利用者視点で書くべき。
悪い例
- 継承しているのにメソッドオーバライドしていない。親クラスにない振る舞いを子クラスにさせるため継承するなら、子クラス側でメソッドをオーバーライドさせる方が適切。
- 不適切な継承関係。
- （例）制御クラスの子クラスがデバイスクラスになっている。
- 汎用性の高いクラスが増えて来た。いくつかの部品の組合わせで難所を走るクラスを作る傾向が増えて来た。
悪い例
- ステートマシン図で手順を書いている。ステートマシン図は状態遷移を書くダイアグラムなので、手順を書きたいならアクティビティ図を使うべき。
悪い例
- クラスを導出された理由が分からない。
- やる！と宣言した戦略や要素技術が構造や振る舞いに反映されていない。
- モデル間の対応関係が分からない。
良い例
- 理由を書いている。
- 定量化するようになった。
- 並行性設計について動機や効果が書かれていない。
- 開発支援について効果のエヴィデンスがない。
悪い例
- 読み手に「どうモデルを見てほしいか？」について解説がない。
気になったモデルについてQ&A - (株)オージス総研 田邉 浩之氏
このセッションでは審査員が審査中に気になったモデルを例として挙げ、審査員からモデルの作者に質問したり、インタタラクティブにモデルについて理解を深める内容でした。
機能
例として挙ったのは以下のようなユースケース図です。モデルを書いたチームがワークショップに参加していなかったので、審査員からの質問はできませんでした。
まず、本部審査員の鈴木氏から、includeやextendが使われているユースケース図の読み方について解説がありました。ユースケース図は英語圏で作られているので、ユースケース間の関係であるextendやincludeは英語の文章として読むと理解しやすいそうです。つまり、矢印の根元が主語（Subject）で、矢印の種類は述語（Verb）、矢印の先が目的語（Object）です。
- （英語）「ベーシックステージを走る」 extends「コースをライントレースする」
- （日本語）「ベーシックステージを走る」は「コースをライントレースする」を拡張する。
- （英語）「ボーナスステージを走る」 extends「コースをライントレースする」
- （日本語） 「ボーナスステージを走る」は「コースをライントレースする」を拡張する。
（英語）「PID制御の旋回値を計算する」 includes「コースをライントレースする」- （英語）「コースをライントレースする」 includes 「PIDの旋回値を計算する」
（日本語）「PID制御の旋回値を計算する」は「コースをライントレースする」を含む。- （日本語）「コースをライントレースする」は「PIDの旋回値を計算する」を含む。
まだちょっと堅いので、もっと柔らかい表現で、どういう意味かを解釈します。例えば、includeとextendは以下のような関係になると言えます。
「PID制御の旋回値を計算する」は「コースをライントレースする」を含むので、「PID制御の旋回値を計算する」がないと「コースをライントレースする」が動かない。- 「コースをライントレースする」は「PIDの旋回値を計算する」を含むので、「PIDの旋回値を計算する」がないと「コースをライントレースする」が動かない。
- 「ベーシックステージを走る」は「コースをライントレースする」を拡張したものなので、「ベーシックステージを走る」がなくても「コースをライントレースする」は動く。
このincludeとextendの関係をうまく使って、ユースケースを開発の単位とすれば、ユースケースを見積もりやマネジメントに使えるとのことです。
ちなみに上記の「コースをライントレースする」、「ベーシックステージを走る」、「ボーナスステージを走る」の関係はあくまで例です。チームの捉え方次第なので、上記の例のとおりでなければいけないわけではありません。
なお、extendを書いた場合はどの条件の時に拡張されるのか拡張点を書く必要があります。また、includeについてもどの場合にinclude先のユースケースが実行されるのかユースケース記述に書く必要があります。
構造
悪い例
として挙っていたのが以下のクラス図です。
クラスが継承関係にあるのに子クラスで「走行する」メソッドがオーバライドされず、別のメソッド「走行を開始する」が定義されていました。書いた本人に聞いてみると、結局は書き間違いだったそうですが、これで減点食らうのはちょっと損だと思いました。気をつければ気付くはずなので、作っている時にチェックすべきだと思います。
良い例
良い例として挙っていたのが以下のクラス図です（属性と操作は省略）。
ちょっと複雑なので、このクラスの意図を示しておきます。
- 「走行戦略」が一位に決まる単位をコースの最小単位である「経路」とする。
- 「走行戦略」には複数の「走法」が順序付きで含まれている。
- 「走法」が切り替わるタイミングは「走法切替条件」で決まる。
- 「走法」はもっと細かい制御の単位である「アクセル操作法」と「ハンドル操作法」に還元できる。
このクラス図で良い点はまず特定の難所に依存しないような作りになっていることです。部品の組合わせで、全ての難所は走ることができると示しています。
クラス図の例で言えば、コースは最終的には「アクセル操作法」と「ハンドル操作法」の制御量の違いに還元できると言っています。こうなっていると「アクセル操作法」と「ハンドル操作法」という低いレベルの部品は来年以降も再利用できます。
「経路」、「走行戦略」、「走法」については、その年のコースの特徴に依存して範囲を定義する必要がありますが、「アクセル操作法」と「ハンドル操作法」という部品をどう使うかを考えればいいわけです。ただし、実際にはコースの似た部分はあるので、「経路」、「走行戦略」、「走法」について全く再定義することはなく、部分的な流用は可能でしょう。
振る舞い
振る舞いで悪い例として挙ったのが以下のようなステートマシン図です。
作り手の意図としては、おそらく以下の通りだと思います。
- ベーシックステージには、いくつかの区間があり、区間を順番に走る。
- それぞれの区間を走っている時にコースアウトすると、リカバリ走行に切り替わる。
- コースに復帰できると元の区間走行に戻る。
ただ、このモデルはリカバリ走行中にコース復帰した場合に、どの状態に戻るかは判別できません。
私自身はこのモデルの話があった時にリカバリ走行中を外に出し、履歴疑似状態でコース復帰した時に元の状態に戻ることを示せば良いのかなと思いました。
一方で、会場から「復帰の仕方は区間によって違うと考えられるので、区間ごとに内部状態を作って、そこでリカバリをやる必要があるのではないか？」という意見もありました。確かに、区間ごとにリカバリの振る舞いが異なるなら、リカバリを一緒にしてしまうのは問題ですが、本当にこの要求は正しいのかは結論が出せませんでした。
要求
要求では２種類のモデルが紹介されていました。
- 要求図を使って要求同士の関係を書いている。
- ソフトウェア品質特性(ISO/IEC9126)の分類に対して、ETロボコンならでは品質目標を書いている。
どちらのアプローチでも良いと思います。ただ、要求が満たされる合格判定基準を定量的な指標で書くのは必須です。
全体を通じての所感
ETロボコンも10年続いて、成果物が参加者全体に継承されているため、昨年度の成果物の書きっぷりを見ることで成果物の質の底上げはなされていると感じています。
ただ、初参加組の人は、まだまだUMLの基本的な書き間違いが多いチームが多いようですし、常連組についても構造が貧弱、トレーサビリティが取れない、意図と違うモデルを書いているなどの毎年同じ指摘が挙っているようです。
チームは継続していても、人が入れ替わっている以上、これらの指摘がなくなることは難しいと思いますが、ワークショップでもっと上のレベルの議論ができるようになればいいと思いました。
ちなみに、審査員の方とも話しましたが、モデルシート全体のレベルは上がっても、構造のレベルは上がっていないとのこと。私も同感でした。モデリングの中でも特に構造は難しいと思っています。5〜10年継続してトレーニングが必要で、熟練したメンターに適切にフィードバックをもらわないと構造モデリングのスキルはなかなか上がらないと思いました。ETロボコン参加者の構造モデリングの質を上げることは、最大のチャレンジじゃないかと思います。
ユースケース図のincludeの説明が逆になっていたので修正しました。
返信削除神戸電子の江口です。
返信削除ツイッターでご指名がありましたので、コメントを書かせて頂きます。
いつもブログやオブジェクトの広場等で貴重な情報を発信していただきありがとうございます。
いろいろ参考にさせてもらっています。
さて、コメントですが、「全体の所感」のところで書かれた「モデルの構造のレベル」について思ったことを少し書かせて頂きます。
この点については、ETロボコンの参加者(競技者)が、企業の若手や学生ということから、現時点では少々難しいのではないでしょうか。
ブログの中で「5?10年継続してトレーニングが必要で、熟練したメンターに適切にフィードバックをもらわないと構造モデリングのスキルはなかなか上がらないと思いました。」
と書かれていますように、そのトレーニングの１コマがETロボコンであると思うのです。
特に、神戸電子の場合はUMLやオブジェクト指向を初めて学んだ学生が参加していますので、なかなか新しい構造にまで至らないのが現実です。
（更に個別の事情を言えば、神戸電子の学生は業務系SEを目指して学んでおり、組込みソフトについてはETロボコンで初めて体験しているという状況です。）
いつか、大西さんが昨年の田町レーシングのモデルについてツイートされた内容に対して、私が「守・破・離」でRTしたのですが、学生にとっては前年度の優秀モデルを「守」できれば十分で、「破」でさえなかなか難しいかと思います。
しかしまぁ、そう言っているだけでは進歩しないわけですから、そこをどう乗り越えていくかは今のETロボコンで学んだ方達に将来考えてもらうことにして、私の方はETロボコンに参加する若者を増やす方向で仕事をしていきたいと思います。(^_^;)
ところで、東京地区大会の会場と他地区の会場の環境が違い過ぎるのはなんとかならないのでしょうかねぇ。
東海地区のタイムは確かにすごいですが、違う意味で東京地区のタイムもすごいです。
ベーシックステージがあのタイムだと、観客は見ていて面白くないのではないでしょうか。
私が初めて参加したのがRCXだったので、今のNXTにあのスピード感がないのがとても寂しいです。
ベーシックステージを30秒切ると、少しスピードを感じることが出来ます。
東海地区のおやじプログラマーズさんが出した24.1秒だと相当スピードを感じることが出来たのではないでしょうか。
そして、今年のCS大会は、確か広い会議室のような所で行われると聞いていますので、30秒台を切るチームが続出することでしょう。
ですから、東京地区のチームはベーシックステージの走行を完全に変えなければ勝負にならないと思います。
それもまた大変ですが、頑張ってください。
ということで、まとまりもなく、余計なこともいろいろ書きましたが、ご容赦ください。
それでは、今後ともよろしくお願いいたします。