2014/12/19

[uml]ユースケース図がうまく描けない

以前から、ユースケース図がうまく描けないという自覚がある。
普段作るような自分用ツールだと、自分で仕様を決めて作るだけなので必要性はないのだけど、お仕事だと曖昧なところがあると困るので、使えるものは何でも使いたい。

自分で書いていて思うのは、油断すると変に細かく書きすぎてしまう、ということだ。
例えば、いま作ろうとしているBLEとFeliCa Plugをつなげたようなシステムは、こんな感じだ。

image

これは、かなりがんばって削ってみた結果だ。
その少し前は、「搬送波を・・・」とか「割込が・・・」とか、要求仕様と機能仕様と実装観点がごちゃまぜになっていたのだよ。

 

なんでそうなるかというと、何を作りたいのか私もよくわかっていない、というところがあるか。
ハードのところや、ミドルのところまで、アプリも少しは考えているんだけど、全体として「何をやりたいか」が決めきれていないのだ。
今回で言うと、使うのはBLEとFeliCa Plugなんだけど、そこから出た最初の企画が「BLEとFeliCa Plugをつなげてみたい」で、それ以上のものが何もないのだ。
「FeliCa Plugだから、相手はNFC R/Wしかない」とか「とりあえずスマートフォンにはつながないとな」とか、そういうぼんやりとした考えしかないのが、ユースケース図にも現れているような気がしてならない。

よくある例だと、自動販売機。
使う人は「商品を買う」が目的なので、それをユースケースにする、という紹介があった。
うーん、これは自動販売機というものの仕様がかなり確定してからじゃないと出てこない気がする。
それまでは、要求したい仕様自体の洗い出しを先にやるのかね。

2014/12/17

[ble]Serviceの位置

気になることがあると、そっちをある程度調べるまで気が済まないので、なかなか進まない。。
ともかく、WireSharkの件も私の中では落ち着いたので、BLEを普通に使ってみよう。

「普通に」というのは、今までが「BLEのサービスを使ってみる」をやっていた状況に対してのものだ。
何かをするためにBLEを使う、というのをやりたい。
まずは以前動かしたことのある、FeliCa Plugをつないでみようと思う。

何をするか考えてはいないが、軽く設計をしておこう。

image

ま、まずはここからだ。
ほら、山の上から麓を見下ろすような気分で設計しないと、ね。

FeliCa Plugと接続するのが目的なので、ServiceはFeliCa Plugのミドルから使える階層にした方がよいのかとも思ったが、ミドルに引っ付け過ぎすぎるのもどうかな、と思い、アプリ経由でしか通信できないイメージにした。


そういう設計のことを考えると、凝集とか結合とか、そういう話が出てくる。
が・・・苦手なのよね、その手のものが。

とりあえず、直接関係ないものは分けておこう、くらいでよいと思う。
あと、関係あるものはまとめておきましょう、かな。
マイコンの性能が上がってきたおかげで、ずいぶんと余裕あるコーディングができるようになってきたものだ。
まあ、苦手なことには変わりが無いんだけどね。


さらに関係ない話になるが、こういうレイヤーを図にするときの、私の中の配色ルールが決まっていないのが気になっている。
今のところ、アプリが暖色系で、ハードに近くなるほど寒色系、みたいなイメージでやってる。

あとは、濃淡とか。
背景が濃い方がよいか、前景が濃い方がよいか、とか。

image

今回はExcelで作っていて、Excelの標準で持ってる効果を使っている。
補色にするようなシーンでもないと思うので、同じレイヤーは同系色がよかろうと思う。

他の人はどうかな、と、Androidのアーキテクチャ図を見てみた。

http://developer.android.com/images/system-architecture.jpg

私とは逆で、アプリが寒色、ハードが暖色みたい。
背景と前景はグラデーションの方向が逆で、前景はそこまで暗くならないようにされてるみたいだ。

こういうのも参考にしながら、自分の配色を決めたいものだな。

2014/12/16

[ble]CC2540 USB Dongleから直接WireSharkで見る

WireSharkでリアルタイムの流れが見えてもしょうが無かろう、などと言っていたが、だんだん気になってきた。
もしかして、私は技術的に難しそうだから逃げただけじゃないだろうか。。。
えぇい、作ってしまえ!

というわけで、luaを作った。
https://sites.google.com/site/hiro99ma/ble/files/ble_cc2540dongle.lua?attredirects=0&d=1

USB CC2540 Dongleのポートを見て、WireSharkのBT LE LLプロトコルに流しているだけだ。
あんまり動かしてないけど、Advertisingくらいは取れていそうだ。
フィールドとかは気にしないでおくれ(練習の消し忘れ)。

短いluaファイルなので大したことないのかもしれないが、ここまで至るまでが大変だったのだ。
特に、BLEのDissectorをどうやって指定するのかがわからなくてね。。。
UDPとかTCPはやり方がよく出てくるけど、DissectorTable.get()の引数がわからんかったのだ。
メニューの「Internals > Dissector tables」で一覧は出てくるけど、BLEっぽいのがないし、検索もできない。
やむなく、1つ1つツリーを開いて探し、ようやく見つけた次第だ。

最後は、Dissectorに渡すサイズがどこから計算してよいかわからず、いくつかパケットを見て、-10すればよさそうだ、という手抜きで済ませてしまった。

 

まあ、一番の問題は、単にUSBのバルク転送を見ているだけなので、何でもかんでもBLEのデータだと思ってしまうところだろうな。

2014/12/14

[ble]NotificationはATT_MTU-3まで

勘違いしていた、というお話。

データ量を多くしたかったので、256byteのAttributeを作った。
読み出しの方では256byte読めたのだが、Notificationだと20byteまでしかできていない。

image

sd_ble_gatts_hvx()に渡している値も確認したが、256byteになっている。
なぜだ・・・。

そこでようやくCore_V4.1を確認した。
Vol.3 Part F "ATT"の"3.4.7.1 Handle Value Notification"。
読むと、先頭からATT_MTU-3までが上限とのこと。
nRF51822というかS110というか、とにかく今はATT_MTUは23byteなので、20byteまでというのは仕様通りだ。
なるほどねぇ。

それ以上のデータが読みたいならRead Brob Requestを使えとのこと。
つまりまあ、Notificationだから通知だけが目的ってことですな。

[nrf51]GNU ARM Eclipse Plug-ins

nRF51822をJ-Link LITEでデバッグしている。
うちはEclipseでやっているのだが、私がGDBに詳しくないので、なんとなくで使っている。
まあ、BLE通信しているときはステップ実行してもすぐに死んでしまうので、ブレークポイントとウォッチが使えれば問題ないのだが。

ただ、止めて、死んだあとの対処がよくわかっていなかった。
FLASHに焼かずにリセットしたいだけなのだけど、手順がわからない。。
しばらくは、Loadしないデバッグ設定を別に用意してたんだけど、本当に焼いてないのか不安が残った。

調べると、GDBコマンドでリセットできそうだった。
monitor reset
monitor halt
こんな感じでコンソールに打つと、リセットしているようだ。

そして、慣れてくると手で打つのも面倒になってきた。
なんか方法はないだろうかと見てみると、J-Link plug-inなるものがあることがわかった。
http://gnuarmeclipse.livius.net/blog/jlink-debugging/

インストール方法はこちら。
http://gnuarmeclipse.livius.net/blog/plugins-install/

これを使うと、右クリックに「Restart」が出てきて、コマンドを打たずに済むようだ。
また、今まであれこれしないとmainに止まってくれなかったりする件が解決されていそうな気がする。
よかったよかった。

 

J-Linkのプラグインだけじゃなく、OpenOCDのもあるようだ。
他にもコンパイラやテンプレートなんかも提供されているので、気にしておきましょうかね。