れごぼく@メガネボーイズ2008 RSSフィード

2008-07-06

[][] 7/5の会合議事録 20:24  7/5の会合議事録 - れごぼく@メガネボーイズ2008 を含むブックマーク はてなブックマーク -  7/5の会合議事録 - れごぼく@メガネボーイズ2008  7/5の会合議事録 - れごぼく@メガネボーイズ2008 のブックマークコメント

今後のスケジュールの確認

f:id:skelton_boy:20080705134233j:image

  • 7/12(土)はオフラインって書いているけど、オンラインの間違い
    • あと、12日は予定があることに気づいた^^; ので、13日に変更希望
  • 13日の段階で、コーディングルールとかが決まってて、完全に実装するだけの段階に入っているとうれしい。
  • 7/19(土)はオフラインとあるけど、実装が滞りなく進んでいたら、なるべくオンラインで進めたいところ
    • 経済的な理由です・・・^^;

アジェンダ

f:id:skelton_boy:20080705134244j:image

  • ふじさんのモデルを見ながら、おかしな点がないかチェックした
  • 主に、走る、走行を切り替えるのところの分析モデルの作成を行った
    • 走る、走行を切り替えるに関しては、応用的な機能については考慮に入れつつも、当面は基本機能を重点的に実装した方がよい

メガネ兄さんの宿題:「コースを走る」のユースケース

f:id:skelton_boy:20080705145708j:image

メガネ兄さんに、走るのユースケースの分析モデルを作成する件を宿題としてやってもらってたけど、まーたいていの場合はうまいモデルを書けるもんではない。

今回のは、コース要素ごとにロジックを切り替えようねとか、どういう手順で切り替わるかはシナリオとして用意してお区といいかもねという話だったので、こういうモデルになっているわけだが。

じゃーそもそも、概念としてはどういうものがあんのさ?とか責務として、何をやんなくちゃいけないのさ?ってとこを整理する必要があると思った。

分析モデルを作成する上での指針

f:id:skelton_boy:20080705135428j:image

ということで、もう一度分析モデルを書く上で整理しようって話をした。

上はそのための指針。分析モデルの考え方に関しては、

オブジェクトデザイン (Object Oriented SELECTION)」とかに詳しく書いてある。

コースをモデリングしてみた

f:id:skelton_boy:20080705155758j:image

分析モデルを考える上でよくあるのは、対象領域の重要な概念を中心にデータ構造に着目して、モデルを書いてみること。

今回は、コースがどうなっているのかをモデリングしてみた。

モデル中ではぬけているけど、それぞれのコース要素に1対応で走行ロジックというものがある。

コース要素ごとに走り方に関する責務や関心事を閉じ込める感じにしたい。

オブジェクト図で表現してみると

f:id:skelton_boy:20080705160629j:image

こんな感じ。

インコースアウトコースがあって、コース要素にリンクがある。コース要素は走行ロジックにリンクしている。これらの関係は静的に用意されていて、走行直前にボタン操作などで、どちらのコースを走るかを選択する形式になる。

実際には、どっちのコースを走るかを記述しておいて、必要なものだけしかインスタンスを生成しないって方がメモリ節約にはなる。

走行に必要なクラス群を付け足してみると

f:id:skelton_boy:20080705181239j:image

走行制御クラスは走り始めるきっかけを与えるだけで、実際走る処理はロジックに委譲している。

んで、右上の方にシナリオってのがいるけど、これは、コース切り替えの知識を担っているクラス。今どこを走っていて、どのようなイベントがあったら、次は何コース要素に遷移をするのかって判断をする。

コース要素としては一通り用意するんだけど、シナリオのロジックを調節することで、本番直前でショートカットはやっぱやめることもできる。

そして、右下の方に状況判断ってやつがいるけど、これは右にステアリング切れとか、マーカー見つけたぞってのを判断する箇所。PID制御する場合とか、マーカー検知アルゴリズムが走行ロジックに散らばると面倒かなと思って、クラスとして分け、かつ平行作業しやすいように、別のドメインに出してみた。

「コースを走る」のコミュニケーション

f:id:skelton_boy:20080705181924j:image

UIからの通知い始まっているが、走れの通知がきたらいったんタスクは切れる。

んで、走るタスクに入って、ぐるぐるやり始める。

走行ロジックが状況判断ドメインに状況を訪ねて、ステアリングをきるなど、走るためのイベントだった場合は自分でメカニズムに、ステアリングを切ったり駆動輪をまわしたりしてもらう。

「走行を切り替える」のコミュニケーション

f:id:skelton_boy:20080705182854j:image

走行きりかえ系の場合は、走行ロジックがコース要素に切り替えを指示して、コース要素がシナリオに遷移先のコース要素を訪ねて、走行制御に切り替えを指示する。

2008-06-22

[][] 6/22(日)の会合議事録 22:25  6/22(日)の会合議事録 - れごぼく@メガネボーイズ2008 を含むブックマーク はてなブックマーク -  6/22(日)の会合議事録 - れごぼく@メガネボーイズ2008  6/22(日)の会合議事録 - れごぼく@メガネボーイズ2008 のブックマークコメント

今日のアジェンダ

f:id:skelton_boy:20080622142847j:image

今日の目標は、「コースを走る」、「キャリブレーションする」の設計モデルを書くことでしたが、結果的に「キャリブレーションする」の分析モデルを書くだけで終わってしまいました^^;

連絡事項(1) 今後優先するユースケース

色々ユースケースを検討する中で、高い優先度のものを先に開発線といかんだろうという話をしました。

星ついてあるやつが、高優先度のやつ。

走行ロジックの切り替えに関しては、最初はロジック切り替えはしないんだけども、切り替えで自体はできるようにしたいよねと。

f:id:skelton_boy:20080622145225j:image

連絡事項(2) 主アクター(人間)へはUIドメインを通して、副アクター(デバイス関係)へはMechanismドメインを通して通知する

アクターだるユーザーには、Application→UI→Mechanism→Deviceと遠回りすんの?って話が持ち上がってましたけど、遠回りなので、ユーザーへの通知に関してはUIからデバイスへ指示するようにしましょう。

f:id:skelton_boy:20080622143340j:image

キャリブレーション(1) 指示待ち受け

ここから今日の本題。

キャリブレーションでは、黒→白→灰色の順にサンプリングしてから閾値を決めるんだけども、各色のサンプリング値取得をボタン操作で指示するまでは、LCDにセンサ値を表示し続けていく。

f:id:skelton_boy:20080622163902j:image

キャリブレーション(2) サンプリングを実施する

んで、ボタンで指示を受けると、実際に色をサンプリングして閾値を決定します。3色について、これを実施し、閾値を内部的に決定したらキャリブレーションは完了です。

f:id:skelton_boy:20080622161904j:image

分析モデル(1) Application::calibrationドメインのクラス図

f:id:skelton_boy:20080622230739p:image

分析モデル(2) 「光センサ値を表示し続ける」のコミュニケーション

f:id:skelton_boy:20080622231009p:image

分析モデル(3) 「センサ値をサンプリングする」のコミュニケーション

f:id:skelton_boy:20080622230848p:image

次回の会合は6/28(土)

次回までの宿題は以下のとおり。なぜか全員関東圏にいますが、みんなでメッセで会議します。

2008-05-31

[][] 今日の会合 00:59  今日の会合 - れごぼく@メガネボーイズ2008 を含むブックマーク はてなブックマーク -  今日の会合 - れごぼく@メガネボーイズ2008  今日の会合 - れごぼく@メガネボーイズ2008 のブックマークコメント

今日の会合は「ドメインの責務」を明確にし、ドメインコラボレーションを書いてみました。今日の作業で各自の担当ドメインの役割分担がおおよそ把握できたんじゃないでしょうか?

今日の写真は、僕のフォトライフ:に上げています。

まずはドメインの責務を定義しよう

f:id:skelton_boy:20080531175014j:image

模造紙半分を四分割して、4つのドメインの責務が書けるスペースを用意しました。

そこに、ドメインの責務を書いていきました。書き方は、「○○を知っている」や「○○をする」など。

逆に、「○○は知らない」「○○はしない」など、否定の文章も書いていくと役割分担が明確になります。

ドメインの責務については後ほどブログにてまとめましょう。

(1) キャリブレーション

f:id:skelton_boy:20080531181139j:image

まずは順番から行って電源入った後すぐにやるキャリブレーションです。

写真ではアクターが直接UIに通知してますが、正確にはDeviceのボタンに通知して、DeviceからMechanismを通じてUIに通知が上がってくる形式になります。

(2) 走行モードの設定

f:id:skelton_boy:20080531181904j:image

僕らのチームでは、本番用と試走用の2種類の走行モードを用意しています。前者は普通に本番コースを走る用ですが、後者は試走して走行ログを取得する用のモードです。

(3) 走行を開始する

f:id:skelton_boy:20080531182620j:image

実際には「走行を開始する」と「走行する」では、別のタスクになっている可能性がありますが、硬いことは抜きで。

ここは一番重要なとこですね。実際には、コース要素用の走行ロジックなどかなり重要な部分が入っています。

(4) 走行を中断する

f:id:skelton_boy:20080531183122j:image

(5) 走行ログを取る

f:id:skelton_boy:20080531183424j:image

(6) メカニズムドメインが提供する機能ユニット

f:id:skelton_boy:20080531183805j:image

メカニズムドメインの役割はデバイスを抽象化し、アプリケーションドメインが利用しやすい機能を提供することですかね。

若干、ユーティリティっぽくなってますが、アプリケーションとのすみわけを要検討です。

個人的には、メカニズムはこんなもんで、アプリケーションをもっとドメイン分割した方がいいと考えています。

(7) 今後の予定

f:id:skelton_boy:20080531184922j:image

とりあえず概略的にはどういうことをすべきなのか把握できてきたと思います。次回は、ユースケースの優先順位を決めて、6・7・8・9月に何をやるとよいかを決めていきましょう。

個人的には、次回の会合から1ヶ月単位で開発する範囲を決めて、それを4回繰り返すという感じにしたいと思っています。

(8) 次回の会合は6/14(土)です

ということで、次回は6月14日です。宿題も出ているので、皆張り切っていきましょう。

f:id:skelton_boy:20080531191800j:image

2008-05-11

[] 昨日描いたユースケース図について 15:02  昨日描いたユースケース図について - れごぼく@メガネボーイズ2008 を含むブックマーク はてなブックマーク -  昨日描いたユースケース図について - れごぼく@メガネボーイズ2008  昨日描いたユースケース図について - れごぼく@メガネボーイズ2008 のブックマークコメント

昨日描いたユースケースモデルを修正して、リポジトリにコミットしてあります。各自、ユースケースの概要、基本フロー(ステップごとの処理手順)、シナリオ(具体的な場面を想定したもの)、などを書いてください。

以下に、ユースケースを示しておきます。

ドメイン構成

f:id:skelton_boy:20080511143523p:image

ライントレーサ側のシステムを4つのドメインに分割しています。

  • Application:
  • UI
    • ボタン操作やLCDなど、UI受付処理を行っています。
    • 内部処理に関しては、ApplicationやMechanismに委譲します。
  • Mechanism:
    • ApplicationやUIの提供する機能を実現するドメインです。
    • ApplicationやUIが直接ハードウェアを制御しなくてもよいようにしています。
  • Device:

Applicationドメインユースケース

f:id:skelton_boy:20080511143524p:image

走行の準備として、キャリブレーション機能や走行シナリオ設定機能などがあります。

走行モードというのを用意しており、本番走行モードの場合、事前に設定された走行シナリオを参照して、シナリオどおりにコース要素を走るようにします。

試走モードでは、走行のログを取ったりします。このログは、走行中に、バッテリがどのような状態にあったのか?光センサーの値はどうなっているかを記録したもので、PC側に転送してから、戦略検討に利用します。

Mechanismドメインユースケース

f:id:skelton_boy:20080511143526p:image

実際に走ったり、ログの転送などをやっているのはこちら側です。

Applicationとの役割分担をはっきりさせておきたいですね。

このドメインユースケースを起動するのは、通常ApplicationドメインUIドメインです。

UIドメインユースケース

f:id:skelton_boy:20080511143527p:image

LEGOの場合、出力できるUIがないので、ボタン操作で何らかの入力を与えることが多いです。ここで入力を受け、通常Applicationドメインへ通知を行います。

Deviceドメインユースケース

f:id:skelton_boy:20080511143525p:image