legoboku.jp: 9月 2011

2011/09/25

#etrobo ETロボコン東京地区大会モデリングワークショップに行って来た

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ロボコン参加者の構造モデリングの質を上げることは、最大のチャレンジじゃないかと思います。

#etrobo ETロボコン東京地区大会Bブロックの結果

今年はエントリーしてませんが、後輩の応援に行って来ました。

まずは、東京地区大会Bブロックの結果から。ワークショップの模様などは別途書きます。

東京地区大会Bブロックの結果

総合部門

1位チームSUPRAパンダ
2位リターンオブタムラ
3位芝浦雑技団
4位 eRush
5位松浦La
特別枠※ ARASHI50

※今年は東京地区大会の10周年でその記念の特別枠として１チームがチャンピオンシップ大会に参加できるようです。

モデル部門

1位田町レーシング
2位チームSUPRAパンダ
3位リターンオブタムラ

競技部門

1位芝浦雑技団

合計リザルトタイム：31.8秒
インコースリザルトタイム：6.1秒（ベーシックステージ36.1秒、シーソーシングル・階段・ガレージイン成功）
アウトコースリザルトタイム：25.7秒（ベーシックステージ35.7秒、ルックアップゲート成功）

2位チームSUPRAパンダ

合計リザルトタイム：78.8秒
インコースリザルトタイム：44.6秒（ベーシックステージ44.6秒）
アウトコースリザルトタイム：34.2秒（ベーシックステージ44.2秒、ルックアップゲート成功）

3位松浦Lab

合計リザルトタイム：81.2秒
インコースリザルトタイム：45.4秒（ベーシックステージ45.4秒）
アウトコースリザルトタイム：35.8秒（ベーシックステージ45.8秒、ルックアップゲート成功）

所感

後輩チームがモデルと競技で1位を取ったので満足でした。田町はアウトコースが完走できなくて残念だった。また頑張ってほしい。

モデルの感想ですが、個々のチームのモデルの底上げはなされているように思いますが、やはり基本的なUMLモデルの書き方に間違いがあったり、クラス図の構造がいまいちなチームは散見されました。まだまだ東京地区は良くなって行く余地はあると思います。

また、競技面では全国の猛者と比べると、ちょっと弱い感がありますね。全国ではベーシックステージ25秒で、全難所クリアとかがいるそうなので、今のままでは競技で上位に行けません。東京連合でてこ入れしましょう。

#cook4geeks Cooking for Geeks by オライリージャパン×クックパッドに参加してきた

オライリージャパンとクックパッドの共同で開催された「Cooking for Geeks」というイベントに参加してきました。なかなか楽しいイベントだったのでブログにも感想を書いておきます。このような場を開催してくれたオライリー／クックパッドの両者に感謝！

Cooking for Geeks？

このイベントは9月にオライリーから出版された「Cooking for Geeks」という料理本を記念してのイベントです。

書籍の紹介や目次を見ていただければ分かりますが、料理の科学的な仕組みを紹介しており、内容は普通の料理本とは少し違ってます。

そして翻訳者の方もおっしゃってましたが、オライリーから出てる本だからかコンピュータ書に通じるところが随所にあります（笑）。「ハロー、キッチン！」「キッチンの初期化」、「O(1)（定数時間）での検索」とか。なかなか変わってます。

Cooking for Geeks ―料理の科学と実践レシピ (Make: Japan Books)

Jeff Potter

オライリージャパン

発売日：2011-09-22

ブクログでレビューを見る»

イベント概要

日時：2011年9月22日（木）：19：30～20：30（開場19：00、閉会後懇親会）
会場：クックパッド株式会社
主催：クックパッド株式会社、株式会社オライリー・ジャパン
内容：

発表

「食品の効果的な加熱方法」水原文（『Cooking for Geeks』翻訳者） - @bmizuhara
「情報科学からの食文化への挑戦」福地健太郎（明治大学特任准教授） - http://fukuchi.org/, @kentarofukuchi

ライトニングトーク

奥一穂（株式会社ディー・エヌ・エー） - @kazuho
佐々木達也（クックパッド株式会社） - @sasata299
佐々木抄子（株式会社ドワンゴ） - @shokos
塩谷啓（株式会社ドワンゴ） - @kwappa
高木誠（フリーランスプログラマ） - @2celeb
舘野祐一（クックパッド株式会社） - @hotchpotch
中村裕美（明治大学） - YouTaste | 電気で食事をもっと楽しく．
松野徳大 - tokuhirom's Profile - GitHub

参考：http://www.oreilly.co.jp/editors/archives/2011/09/ann-cooking-for-geeks.html

発表への感想
「食品の効果的な加熱方法」水原文（『Cooking for Geeks』翻訳者） - @bmizuhara

トップバッターは翻訳者の方。
このイベントの趣旨をあまり理解せずに参加してしまった僕は、Webとかプログラミングがらみの話をするのだとてっきり思っていたので、いきなり加熱方法とか化学的な話でぶっ飛びました。

話の内容は加熱の目的（おししくするため、食品衛生のため）、肉のコラーゲン量に応じた適切な加熱温度、ごはんを加熱する時に起こる科学変化、ごはんをおいしく保温する方法などなど。料理をする人がI型コラーゲンの変成とかメイラード反応を知っておく必要あるがというと疑問だけど、肉の加熱については皆知っておくべきじゃないかなと。肉を調理したい時って火加減大事だし。

ちなみに水原さんの発表内容は「Cooking for Geeks」の第4章「時間と温度: 料理の主要変数」に書いているようです。

（発表）「情報科学からの食文化への挑戦」福地健太郎（明治大学特任准教授） - http://fukuchi.org/, @kentarofukuchi

料理の発展に科学は大きく寄与してることは、まー周知の事実ですが、発表者は情報科学分野から食文化に貢献したいのだそう。
情報科学分野からの貢献って身近な例では、クックパッドとか食べログとか。もっと大掛かりなやつはホームオートメーションの特にキッチン周りとかもそうだとか。キッチンにディスプレイがあって、レシピが検索できるとかね。

で、発表者が提唱しているのはLaser Cookingというものだ。まな板の上にカメラを置いて、画像処理技術を使って、ベーコンの脂身だけに正確にレーザー光を照射して焼くのだそうだ。
他にもクッキーにちょっとした画像を焼き込んだり、立体造型のお菓子を作ったり。最初ばかばかしいと思ったけどw 、食品メーカーは全然興味しめすんじゃないかと思った。

いちおうベーコンを焼くネタは論文も書いているよう。
Laser-Cooking:レーザーカッターを用いた自動調理法の開発
http://ci.nii.ac.jp/naid/110008583670

(LT) 奥一穂（株式会社ディー・エヌ・エー） - @kazuho

楽しみとしての自炊を提案してました。外食は原価の3倍くらいするので、外食で高いものを食べるのは損とのこと。自炊だからこそ外食で食べると高くなるような良い食材を使うといいとのこと。ポイントは良い食器を使うこと。

僕は生活のための自炊派なので、考え方が違うなーと思いましたが、良い食材を選んで少し贅沢感を味わうのもいいかなと思った。

(LT) 佐々木達也（クックパッド株式会社） - @sasata299

唐揚げの話をしてました。唐揚げを好きと言ったのに、実は立田揚げの方が好きで、唐揚げはそれほどじゃないとか。どっちだよ！と数回突っ込んでしまいました。

(LT) 佐々木抄子（株式会社ドワンゴ） - @shokos

スピリチュアル自炊の話をしてましたが、展開が早くてよく分かりませんでした。でも爆笑しました。Haskellでスピリチュアルプログラミングをされているそうです。
あの「お前が言うんならそうなんだろう　お前の中ではな」って画像はちょくちょく見かけるけど、ネタは何？

(LT) 塩谷啓（株式会社ドワンゴ） - @kwappa

鶏ハムとか簡単でお得なレシピ紹介してました。あれはそのうちやってみたい。
ちなみに料理できると結婚できると断言してました。そうなのか。

(LT) 高木誠（フリーランスプログラマ） - @2celeb

自炊を効率的にやるための工夫を紹介してました。
一度に調理して、冷凍しておいて、日々の弁当作りを素早くやるとか。あとは、1つの調理方法のテンプレートで、具材や調味料を変えてみて楽しむとか。
僕の感覚は少しこの人近いかなと思いました。ちょっと弁当は試してみたい。

(LT) 舘野祐一（クックパッド株式会社） - @hotchpotch

残念ながらお休み。代々の型が「Ruby on Railsは炊き込みご飯のパクリ」という納得感のある主張をされていました。会場爆笑。

(LT) 中村裕美（明治大学） - YouTaste | 電気で食事をもっと楽しく．

食材や飲料を飲食する際に電気を流すことで、「電気味覚」と呼ばれる新しい味覚体験を与えるという提案でした。
ドリンクに電極を指して、飲みながら電気刺激で味にアクセントをつけるとか。かなりぶっ飛んでるw
なかなか誰特な印象はありましたが、興味はわきました（笑）少し試してみたい。
あと、電気との食べ合わせとかも調べているそう。

ちなみにググってみると「2010年度未踏IT人材発掘・育成事業未踏ユース」のに採択されているそうです。
http://www.ipa.go.jp/jinzai/mitou/2010/2010_1/youth/gaiyou/gm-6.html

(LT) 松野徳大 - tokuhirom's Profile - GitHub

とにかく高い食材を食い、高い酒を飲めとのこと。

日常的にはどうかと思うけど、高い日本酒とかは同感。たまに飲みたい。

懇親会の様子

冒頭の写真の通り、書籍に載っている変わった調理法の料理を食べつつ、ビールを飲んでいろいろな方とお話しました。なかなか楽しい会でした。

2011/09/21

Eclipseでgoogletestを使う方法（Mac OS X SnowLeopard編）

Emacs + gccで開発もいいですが、IDEも使ってみたいのでEclipseでgoogletestのテストを実行する方法を調べてみました。

なお、前回のエントリでgoogletestのライブラリを作成したり、テストを行うサンプルコードを作成する手順を紹介しています。そちらの手順を実施していない場合は、前回のエントリを参照してください。

環境

Mac OS X: 10.6.8（Snow Leopard）
gcc: 4.5.4
Eclipse: 3.7.0
Eclipse C/C++ Development Tools: 8.0.0

手順

C++のプロジェクトを作成し、ソースファイルを追加する
プロジェクトにライブラリを追加する
プロジェクトにインクルードパスを設定する
ビルドし、テストを実行する

(1)C++のプロジェクトを作成し、ソースファイルを追加する

メニューの File -> Project -> C/C++ Project でプロジェクトで作成します。プロジェクトの種類は「Executable -> 空のプロジェクト」で良いと思います。これは、実行ファイルを作るプロジェクトで、プロジェクト内にはファイルを追加しないという意味です。

ここにmain関数があるソースファイルおよびテストコードを追加します。昨日のエントリにサンプルを紹介しているので、そちらを参照ください。

(2)プロジェクトにライブラリを追加する

プロジェクトを右クリックして、Propertiesを開きます。

開いた画面の中から「C/C++ Build -> Settings -> Mac OS X C++ Linker -> Libraries」を選んでライブラリの設定画面を開き、以下を設定します。

Libraries(-l)

gtest
gtest_main

Library search path(-L)

gtestのライブラリがあるディレクトリパス

ライブラリの名前は "libgtest.a" と "libgtest_main.a" ですが、頭の "lib" とお尻の ".a" はつけません。これはgccの慣習です。

(3)プロジェクトにインクルードパスを設定する

Propertiesの画面の「C/C++ Build -> Settings -> GCC C++ Compiler -> Includes」を選んでインクルードパス設定画面を開き、googletestのヘッダファイルのあるパスを設定します。

場所は <googletest>/include です。<googletest> はgoogletestの配置場所です。自分の環境のものと置き換えてください。

(4)ビルドし、テストを実行する

これで設定は完了です。

メニューの「Project -> Build All or Build Project」をクリックし、ビルドします。エラーが出なければ成功です。

さらにメニューの「Run -> Run As -> Local C/C++ Application」をクリックすると、実行ファイルが実行され、テスト結果が表示されます。テストが通っていれば成功です。

2011/09/20

gccとCMakeでgoogletestをビルドする方法（Mac OS X編）

Webを調べていると、googletestをビルドする際にVC++かXCodeを使う例が多かったので、IDEを使わないでできる方法を調べてみました。なお、googletest自体の説明は割愛します。

環境
私の環境は以下の通りです。

Max OS X 10.6.8（Snow Leopard）
gcc 4.5.4
cmake 2.8.5

公式のREADMEには cmake 2.6.4 以上が必要とありますが、gccのバージョンは明記されていませんでした。

手順

svnリポジトリからgoogletestを取得する
cmakeでgoogletestをビルドする
main関数を持つソースファイルを作成する
テストコードを作成する
g++でテストコードでビルドする
テストを実行する

(1) svnリポジトリからgoogletestを取得する

適当な場所に配置します。

svn checkout http://googletest.googlecode.com/svn/trunk/ gtest-svn

(2) cmakeでgoogle testをビルドする

cmakeを実行するディレクトリも適当な場所で良いです。 {GTEST_DIR}はgoogletestのあるパスに置き換えてください。 libgtest.a と libgtest_main.a ができれば成功です。

mkdir mybuild
cd mybuild
cmake ${GTEST_DIR}
make

なお、ビルド関係はREADMEが参考になります。

(3) main関数を持つソースファイルを作成する

以下のソースファイルを参考に、main関数のあるソースファイルを作成します。

http://code.google.com/p/googletest/source/browse/trunk/src/gtest_main.cc

ファイル名はtestmain.ccとしました。ちなみに必ず以下の順に呼ばないといけないようです。

testing::InitGoogleTest(&argc, argv);
RUN_ALL_TESTS();

#include <iostream>

#include "gtest/gtest.h"

GTEST_API_ int main(int argc, char **argv) {
  std::cout << "Running main() from testmain.cc\n";

  testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

(4) テストコードを作成する

テストコードを作成します。ファイル名はmytest.ccとしました。

#include "gtest/gtest.h"

TEST(firstTest, abs)
{
  EXPECT_EQ(1, abs( -1 ));
  EXPECT_EQ(1, abs( 1 ));
}

(5) g++でテストコードをコンパイルする

コンパイルする時はgoogle testのヘッダファイルがあるディレクトリをインクルードパスに入れる必要があります。また、cmakeでビルドした時にできたライブラリも含めてビルドします。

なお、以下のコマンド中の testmain.cc はmain関数が入っているファイル、mytest.cc がテストコードが入っているファイルです。また、{GTEST_DIR}はgoogletestが入っているディレクトリのパスに置き換えてください。

g++ -I{GTEST_DIR}/include testmain.cc mytest.cc libgtest.a libgtest_main.a -o mytest

(6) テストを実行する

できあがったバイナリを実行すると、テスト結果が表示されます。テスト結果がOKなら成功です。

登録: 投稿 (Atom)