徒然なるままに書きつくれば

この記事はMice Advent Calendarの2日目の記事です。

昨日は kana_____s さんの2019年に買ってよかったものベスト5でした。

他の人の購入記事とかって、自分じゃ考えつかないようなものが乗っていたりして良いですよね。チェキ買うとかいう発想は私の人生にはなかったので非常に面白かったです。

また、kana_____s さんは今回のAdvent Calendarの主催者でもあります。

主催していただきありがとうございます。

---

さて、皆さんお久しぶりです。

前回記事が去年のAdvent Calendarで震えている鯉住です。

今年はマウスの大会にも出ていなかったので存在感かなり薄くなっている気がします。

何をしていたかというとETソフトウェアデザインロボットコンテスト（ETロボコン）という競技に取り組んでいました。

ETロボコンは、組込みシステム技術協会が主催している「組み込み技術者の教育」を目的としたロボコンです。

このロボコンでシステム設計的な内容を教えてもらったので、それを使って少しマウスのシステムを考えてみるみたいなことを書こうと思います。

まずETロボコンに参加してみて他のロボコンと比べて特徴的だと思ったことこんな感じです。

　①ロボット（ハード）は全員共通で改造なし（LEGOマインドストーム）

　②走行成績だけでなく、ソフトの品質も評価される

　③運営が技術教育をかなりしっかり行ってくれる

②はソフトのコードを提出するというわけではなく、自身の設計（モデル）をUMLで記述しポスターにまとめて提出します。

コレがなかなか面白くて、モデルが評価される都合上、"ロボットが速く動けばいい"ではなくて"目的に沿った設計をし第三者がわかるように記述する"ことができなければよい成績が取れないようになっています。

当然そんなうまくできるわけないので③でサポートという形をとっており、教育という目的を競技に落とし込んでいると感じました。

参加した感想は、いろいろ勉強になってとても楽しかったというのが一番です。

技術教育として月2回くらいのペースで勉強会開いてくれ、非常に勉強になりました。独学と違って有識者にその場で質問できる大きいです。（その分参加費も割高ですが。。。）

また、企業スポンサーが多くついており、企業の研修としても利用されているみたいです。

私の地区で約20チーム出場した中で所属が個人だったのは私たちのチームは1つだけでした。大半は企業の新人＋少数の大学生といった構成です。この辺は結構マイクロマウスとは違いますね。
ただ、月２の勉強会で運営の審査員とかにモデルの相談とかはバンバンできるので個人勢が滅茶苦茶ハンデ背負ってるわけではなかったです。（それなりにはありますが。時間とか場所とか） 

自分のモデルを評価してもらう機会はなかなかないと思うのでぜひ皆さんも参加してみてはいかがでしょうか？

マイクロマウスのシステムを考える

ここからが本題です。ETロボコンで教わったことをマウスに適用してみます。
（私の理解で書いていくので間違っている可能性があります。マサカリ募集中です。）

※書きなぐってたら思ったより長くなってしまったので注意です。

モデルベース開発

ETロボコンではモデルベース開発を行うこと強く勧められました。
モデルベース開発とは、いきなりコーディングを始めるのではなくモデル※を用いてソフトウェアの設計・開発を行い、目的の機能を果たすモデルが完成したうえでそれをコーディングするという開発手法です。

※ここでいうモデルとは制御的な意味のモデルではなく、ソフトウェアの機能や構造・振る舞いを表現するものことを指します。UML(Unified Modeling Language)のモデルです。

モデルを使うことでソフトウェアの全体像が俯瞰でき複雑な構造・振る舞いを理解しやすくなります。
また、あとから機能を追加する際にも他部分への影響等を考慮しやすいという利点もあります。

モデルの3視点　機能・構造・振る舞い

モデルはソフトウェアを記述するものですが、記述の観点として「機能」「構造」「振る舞い」の3つがあります。
それぞれ異なる視点である上記によって同じものを記述することで誤解なく伝えることができます。製図における3面図と同じような考え方だと思います。

「機能」
　　システムがユーザに提供する働きやサービス。ユースケース図で記述。
　　マウスであれば、”探索”、”最短経路導出”、”最短走行”など。

「構造」
　　システムの構成。クラス図やオブジェクト図で記述。
　　マウスであれば、”壁情報は迷路モジュールが管理"、”探索モジュールは迷路モジュールを経由しないと直接壁情報にアクセスはできない”など。

「振る舞い」
　　システムの動きや処理の順番。シーケンス図やアクティビティ図で記述。
　　マウスであれば、"まずLEDの反射値から壁を判断し、それをもとに次行く方向を決める"、”目標速度を決めた後にPWM指令値を決定する”など。

モデル設計フロー

ETロボコンで学んだ設計フローは下記の順です。
　①要求分析（システムの目的）※
　②機能決定（①のために必要な機能）
　③シナリオ整理（②の機能がどのような流れで実現されるか）
　④オブジェクト抽出（③に出てくる"部品"を整理し必要なオブジェクトを洗い出す）
　⑤構造決定（④の類似品をまとめたり役割を整理しクラスとしてまとめる）
　⑥部品のつながり整理（③を果たすために④がどうつながっているかを整理）
　⑦振る舞い決定（時間軸に沿って⑥の動作を整理）

※システムの要求分析についてはあまり教わってなく正直よくわかっていません。有識者の方いらっしゃれば教えてください。

このフローの中で、②が機能、④⑤が構造、⑥⑦が振る舞いのモデルを設計することに対応します。
また、④～⑦はまず自然言語レベルで概念を明確にする基本設計を行い、そのうえでもう一度コーディングできるレベルで詳細を詰めていく詳細設計を行います。
基本/詳細 設計のイメージ）
　基本設計：迷路モジュールが壁情報を管理
　詳細設計：Maze クラスがprivateメンバ変数 wall[x][y] を保持

よって、正確なフローは
　① ⇒ ② ⇒ ③ ⇒ ④~⑦（基本設計）⇒ ④~⑦（詳細設計）⇒ コーディング
となります。長いですね。

実際にやってみる

私が自身の整理がてら、マイクロマウスを対象に先のフローの⑤くらいまでやってみたので一つの例として紹介します。


①②③ 要求分析＆機能抽出＆シナリオ整理

まずはマウスに必要な機能を考えます。私は「最短走行」と「探索走行」だと考えました。
ただし、これではまだ粒度が大きすぎるので細かく分類します。
例えば、「探索走行」のシナリオを考えると、下記のような感じになりそうです。（）内はそれぞれの処理に関連しそうな部品です。

これを見ると1～4はまだまだ粒度が大きいのでもう少し分類します。
（正直、どのレベルまで分解するべきかはよくわかっていません。私の目安としては、設計フローの部品抽出や振る舞いを考えるときに苦労しないで済む（脳死でできる）くらいをイメージしています）

1をさらに分解すると
となり、ここまで細かくなればその後の部品抽出や振る舞い記述ができそうです。

他も同様に細かくした結果が下記のユースケース図です。




④ 部品抽出

続いて部品の抽出を行っていきます。
これは先ほど洗い出した機能を果たすうえで必要なモノを拾っていく作業です。
例えば、先ほどの「壁情報を取得する」機能ですと"発光LED"と"受光素子"が部品にあたります。
また、部品同士はどれが関連しているかわかるように線を結んでおきましょう。


これをひたすら行っていくわけですが、ここで注意することとしては抽象的な概念を部品として扱わないようにしましょう。

この作業を行っている　走行体を制御するモノ＝制御部　みたいなことをしたくなるのですが、制御部なんてモノは現実には存在しません。抽象的な概念をいれてしまうとオブジェクト指向からブレてしまう、、、とのことです。
私の実体験としては、あいまいな概念が出てくるとその役割が大きくなりすぎて、あらゆる役割を押し付けるようになって大変なことになりました。
頑張ってセンサからデータを取得しモータに電圧をかけるみたいに分類した方がいいです。難しいところではありますが。。。

部品をまとめたものが下のオブジェクト図になります。


（Logが空なのは設計がまだできていないためです）

四角がそれぞれ部品です。部品だけ列挙すると何をするのかわからなくなるので、赤い付箋みたいなので部品の役割をメモしています。
例として出しといてあれなのですが、この後の構造整理をちょっと見越してクラスっぽく整理してあります。
発光素子と発光LEDが光学センサにまとめられていたり、モータが一つしかなかったりするのはそのせいです。（本来この段階では左モータ/右モータみたいに実体の部品に対応している）

⑤ 構造決定

続いて先ほどのオブジェクト図から重複する概念などをまとめて整理しクラス図にまとめていきます。
すでにある程度まとめてしまっていますが、本来は左モータ/右モータを1つのモータクラスとしてまとめたり、N個の発光LEDを1つのクラスにまとめたりします。

迷路回りを書いたクラス図が下記になります。



ところどころ、コーディングっぽくなってるのは私がさぼって詳細設計に一部突入しているからです。
本来はこの時点で具体的な型などまで決める必要はありません。


⑥⑦ 振る舞い

振る舞いでは、④で洗い出した部品が具体的にどのような流れで関連するかを記述します。
まず部品Aから部品Bにデータを渡し、それに応じて部品Bが部品Cに送るデータを決めて…みたいなイメージです。

例としてモデル図を出せればよかったのですが⑤までで力尽きてしまいました。。。申し訳ありません。
いつか書いた暁にはしれっと続きの記事とか書くかもしれません。こうご期待！！

まとめ

というわけで非常にざっくりしたモデルベース開発紹介でした。
説明というより、とりあえず書きなぐった感じになってしまって申し訳ないです。あんまり整理できなかった。。。
わからない点などはぜひお気軽に質問してください。
また、間違っている点とかあったらご指摘いただけると嬉しいです。


途中でも書きましたが、マイクロマウス界隈ではこの辺の話を全然聞かないです。
ハードウェアの工夫やノウハウもいいですが、ソフトウェア設計もいいぞ！！！！ ということで今回の記事を書いてみました。何らかの助けになれば幸いです！

これを読んでくれている誰かに刺さってくれないかなぁ。もっとソフト設計の記事ふえないかなぁ。

---

明日はううさんの粘菌かポーランドの話です！　（ううってなんだ・・・？）
研究内容的なことか旅行記なのかな？
ひと味違う感性を持つ彼の記事、楽しみですね！