知らないと損するアプリ開発におけるStateMachineの活用法(full版)

10,161 views

Published on

StateMachine for client apps.

Published in: Technology
0 Comments
78 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
10,161
On SlideShare
0
From Embeds
0
Number of Embeds
435
Actions
Shares
0
Downloads
104
Comments
0
Likes
78
Embeds 0
No embeds

No notes for slide

知らないと損するアプリ開発におけるStateMachineの活用法(full版)

  1. 1. 知らないと損する アプリ開発における StateMachineの活用法 2014年10月 ゆめみ 森下 健 1
  2. 2. 2 あるあるじゃない? あるよね? • 通信やダイアログやアニメーションが多い ViewControllerがカオス状態 • アプリの初期化・起動処理が 複雑でダ・ヴィンチ・コード級の謎 こんな困ったことありませんか?
  3. 3. 3 今回はそんな悩みを解決するState Machineの話だよ。 「Finite State Machine(有限状態機械、略してFSM)」と 呼ぶこともあるね。 そこで
  4. 4. 4 こんな流れで説明するよ • StateMachine? • StateMachine Generator • 実際の例 • StateMachineの設計Tips • 考察
  5. 5. 5 まずは、StateMachineについて説明するね
  6. 6. 6 StateMachineは組み込み系だと常識的に設計や実装 で使われる技法だよ。例として有名なのは、自動販売 機があるよ(実際どうなのかは知らないけど)。 http://www.riko-rh.expressweb.jp/visio_uml/visio_uml05-03-30.htm
  7. 7. 7 例えば、TVはリモコンの同じ電源ボタンを押しても振る 舞いが違うよね。これはTVが状態を持っている、からと 言える。 これを状態図で表すとこんな感じになるよ。 OFF ON 電源ボタン / 電源ON 電源ボタン / 電源OFF
  8. 8. 8 「状態」「イベント」「アクション」「遷移」は大事な言葉だ から覚えてね。「状態OFF」のときに「電源ボタンイベン ト」で「電源ONアクション」が実行されて「状態ON」に遷 移する、という意味になるよ。 OFF ON 状態 イベント 遷移 アクション 電源ボタン / 電源ON 電源ボタン / 電源OFF
  9. 9. 9 え、自分は組み込み系技術者じゃないからそんなの関 係ないって?
  10. 10. 10 使われているのは組み込み系だけじゃないよ。 例えばTCPの通信状態も状態図で書くとわかりやすい ね。 http://www.atmarkit.co.jp/ait/articles/0402/13/news096_3.html 状態 イベント アクション TCPの通信状態
  11. 11. 11 AndroidのActivityも状態図だと説明しやすいよ。 http://www.tutorialspoint.com/android/android_acitivities.htm 状態 アクション
  12. 12. 12 そして、StateMachineは簡単に言うと 状態図を実装したもの になります。 状態図 実装 StateMachine
  13. 13. 13 こんな風に状態図やStateMachineは色々なところで使 われているんだよ。
  14. 14. 14 状態図の分析・設計から実装まで繋がるのが嬉しいね。 「いつ」「どんなイベント」が来ても 不具合を起こさないようになる ■ なぜStateMachineなのか? 分析・設計手法でもあるので 自然に抜け・漏れを潰しやすい
  15. 15. 15 つまり、StateMachineが解決する問題は、アプリ開発で 起こる問題と近いんだよ。使えそうでしょ? ■ スマホアプリの性質・問題 多様な非同期イベント(UI, 通信, センサー) 頻繁に発生する仕様変更(特にUI) 分散されて見通しが悪い非同期ロジック(初期化処理等)
  16. 16. 16
  17. 17. 17 簡易実装ならまだ簡単なんだけどね StateMachineを実際に自分で実装すると結 構たいへん。 例えばJavaだと、ちょっとしたものでも数百行 になってしまう。
  18. 18. 18 そこでState Machine Compilerを使うよ。 これを使うと、DSLで書いたコードから、「各言語の StateMachineコード」と「状態図(画像)」ができるのだ。 ※DSL: Domain Specific Language (=ドメイン固有言語 ≈ オレオレ言語) SMC The State Machine Compiler http://smc.sourceforge.net/ ロゴには Map って書いてあるw そこで
  19. 19. 19 つまりSMCを使うと、状態図とコードが対応していること が保証されるので、StateMachine部分のコードを読む 必要が無くなる。 DSL 状態図 StateMachine コード 入力 出力 意味的に同じもの こっちを見れば こっちは見なくても良い 自動Documentation
  20. 20. 20 このメリットは非常に大きいと思うの。 なので、これからはこのSMCを使うという前提で話を進 めるよ! ■ SMCより提供 • Java • Objective-C • Python • Ruby • JavaScript ■ゆめみオリジナル • JavaScript(β) • Swift(β) 対応言語
  21. 21. 21 まずは、簡単にSMCで使うDSLの説明をするね
  22. 22. 22 さっきの ON/OFF のStateMachineをSMCのDSLで書くと こうなるよ。だいたい見たら対応がわかるんじゃないか な。 […略…] OFF Entry { offAction(); } { power ON {} } ON Entry { onAction(); } { power OFF {} } 状態 イベント 遷移先状態 アクション OFF ON 電源ボタン / 電源ON 電源ボタン / 電源OFF
  23. 23. 23 「Entry」「Exit」というイベントにもアクションを登録できる よ。これらは「その状態に入った・出たというイベント」を 表すよ。どの遷移(矢印)で来ても発火する共通処理に なるよ。 […略…] OFF Entry { offAction(); } { power ON {} } ON Entry { onAction(); } { power OFF {} } Entry OFF ON 電源ボタン / 電源ON 電源ボタン / 電源OFF Entry Exit
  24. 24. 24 さっきも言ったけど、このDSLをSMCで変換すると、状態 図とソースコード(FSM)が出力されるよ。今後この生成 されたStateMachineをFSMと呼ぶことにするよ(よくそう いう名前が付いているし)。 https://gist.github.com/mokemokechicken/9eb89e3c69d7e97800ea (Javaの場合)300行強のソースコード 状態図 StateMachine コード (FSM) ※FSM: Finite State Machine(有限状態機械)
  25. 25. 25 FSMはアクションを呼び出すけど、そのアクションの中 身は自分で書くことになる 状態 イベント 遷移 アクション DSL […略…] OFF Entry { offAction(); } { power ON {} } ON Entry { onAction(); } { power OFF {} } func offAction() { ・・・ } func onAction() { ・・・ } FSM
  26. 26. 26 つまり、開発者が行うのは、DSLとアクションを書くとい う部分になるね。 アクション DSL ←これ書いて これを書く→ […略…] OFF Entry { offAction(); } { power ON {} } ON Entry { onAction(); } { power OFF {} } func offAction() { ・・・ } func onAction() { ・・・ }
  27. 27. 27 コンポーネント間の連携はこんな感じになるよ。 Controller/ModelがFSMにイベント送って、適切なアク ションを呼んでもらう、という感じかな。 ViewController Activity Model FSM Action イベント 遷移 アクション 電源ボタン 押された! 電源ON処理! ??
  28. 28. 28 実際の例
  29. 29. 29 では、実際のアプリケーションを考えます。 「ぺたんぷ」っていう「子供用ご褒美シールアプリ」を題 材にしてみるよ。
  30. 30. ③スタンプを選択 30 例えば、こんな仕様の画面制御を行うとします。 ①押せるスタンプを選べる ②アニメーション ④押したい場所でタップ
  31. 31. 31 こんな手順で進めていくよ 1.状態図を作る 2.DSLを書いてコンパイル 3.アクションを実装する SMCを使うときの3つのStep
  32. 32. 32 まず、ざっくりと状態名を考える。 初期 伸長中 シート表示中 スタンプ選択済み スタンプ押下済み 状態 ①押せるスタンプを選べる ②アニメーション ③スタンプを選択 ④押したい場所でタップ
  33. 33. 33 遷移とイベント名を考えます 初期 伸長中 シート表示中 スタンプ選択済み スタンプ押下済み 状態 tap button finish animation select stamp tap card
  34. 34. 34 他にもあり得るイベント・遷移を追加する。 初期 伸長中 シート表示中 スタンプ選択済み スタンプ押下済み 状態 tap button select stamp tap card 縮小中 finish animation tap else finish stamp finish animation cancel
  35. 35. 35 とりあえずこんな感じで進めましょう! 足りないものは後で追加できるから、それほど気にしな くてもOKだよ! 押せるスタンプを選べる アニメーション ①スタンプを選択 ②押したい場所でタップ 初期 伸長中 シート表示中 スタンプ選択済み スタンプ押下済み 状態遷移 tap button select stamp tap card 縮小中 finish animation tap else finish stamp finish animation cancel
  36. 36. 36 DSLを書いていくよ。Action名は機械的に名前を付ける 方が良いと思う。アプリケーションに特化した名前を付 けると、アプリの仕様や意味合いが変わった時に違和 感が出てしまうことがあるよ。 初期 INIT 伸長中 EXPANDING シート表示中 SHOWING_SHEET 状態遷移 tap 縮小中 tap else finish INIT { tap EXPANDING {} } EXPANDING Entry { onEntryExpading(); } { finish SHOWING_SHEET {} } SHOWING_SHEET ・・・ DSL 名前考えるのむずい onEntryExpading
  37. 37. 37 DSLをSMCで変換 するよ。画像とFSM が生成されます。 INIT { tap EXPANDING {} } EXPANDING Entry { onEntryExpading(); } { finish SHOWING_SHEET {} } SHOWING_SHEET ・・・ DSL http://goodparts.d.yumemi.jp/generator#StateMachineGenerator-- 8774598a35e825c6da9a9275f50cb373b5685e06
  38. 38. 38 必要なアクションを書いていくよ。 アクションの内容は、「Viewの操作」「通信開始」などに なるから、基本的にSDKや自分のコード依存だね。 public protocol Petamp_Action { func onEntryExpading() func onEntryShrinking() func onEntryStampFinished() func onEntryStampSelected() } 生成されたコード (Action Protocol) Action class PetampAction : Petamp_Action { func onEntryExpanding() { UIView.animateWithDuration(0.5) { // アニメーションコード } } ・・・ 自作Swift版はprotocolも生成してくれる。 (他の言語はしてくれない…)
  39. 39. 39 こんな感じで状態遷移などの仕様を表現している部分 は自動生成したり可読性を高めて、アクションなどの実 装依存の部分だけ自分でコードを書くということができ るよ。 INIT { tap EXPANDING {} } EXPANDING Entry { onEntryExpading(); } { finish SHOWING_SHEET {} } SHOWING_SHEET ・・・ DSL Action class PetampAction : Petamp_Action { func onEntryExpanding() { UIView.animateWithDuration(0.5) { // アニメーションコード } } ・・・ ←これ書いて これを書く→ 大事なことなので 2度言います
  40. 40. 40 この手法の良い点としてFSMや状態図はほぼ仕様書と 対応するということがあるよ。つまり、iOSやAndroidとい う別なプラットフォームでも同じものが使えます(普通は)。 押せるスタンプを選べる アニメーション ①スタンプを選択 ②押したい場所でタップ 初期 伸長中 シート表示中 スタンプ選択済み スタンプ押下済み 状態遷移 tap button select stamp tap card 縮小中 finish animation tap else finish stamp finish animation cancel 仕様書 状態図
  41. 41. 41 状態図と仕様書を見比べると仕様を満たせそうか判断 しやすいので、レビューがものすごく捗ります。状態図 が適切なら「設計上の大枠はOKだね」となります。 レビューも捗る! https://twitter.com/Hackadoll
  42. 42. 42 カメラやセンサーなどのハードウェアの制御にも使えて 「ハードウェアの特性・地雷を制御できているか」という 専門知識を状態図で表せる。これもレビューが捗るし、 再利用も容易です。 Androidのカメラを制御するFSM オートフォーカスの制御をするFSM
  43. 43. 43 どう便利でしょ? とってもお役立ちじゃない?
  44. 44. 44 まあ、確かにね。 よろしい。ならば仕様追加だ。 ん〜、この程度UIだったら 別に要らないんじゃない? む、来たな
  45. 45. またひとつスタンプ をおせたね!! つぎもがんばって ね! 45 スタンプを押した時にアニメーションが追加されたよ。 スタンプが押されると キャラクターが登場し メッセージを表示 3秒で消える
  46. 46. 46 状態を1個追加して、遷移も変更するよ。 この追加した状態のEntryで表示を行い、Exitで表示を 消す、と良さそうだね。 初期 伸長中 シート表示中 スタンプ選択済み スタンプ押下済み 状態遷移 tap button select stamp tap card 縮小中 finish animation tap else finish stamp finish animation cancel メッセージ表示中 SHOWING_MESSAGE finish animation
  47. 47. 47 アクションを2つ追加するよ。 この時、他には何も手を入れなくて良いのがまた良い 所なんだよね。 Action class PetampAction : Petamp_Action { ・・・ func onEntryShowingMessage () { // メッセージ表示処理 // 3秒後にfsm.finish_animation() する } func onExitShowingMessage() { // メッセージ非表示処理 } ・・・ 単体テストも 書きやすい
  48. 48. 48 どう? 簡単でしょ?
  49. 49. 49 よろしい。 ならば仕様追加だ。 ん〜、この程度UIだったら いつも普通に書いてるよ? 仕様追加は 世の常人の常
  50. 50. 50 「スタンプを追加する機能」とその前に「親認証」を行う とするよ。 押せるスタンプを親が追加 下の数字を入力してください nine two seven 親認証スタンプ追加ボタン 「親認証ダイアログ」で認証を行う
  51. 51. 51 状態を2つ追加するよ。 それぞれの状態のEntry/Exitでダイアログを表示/非表 示するよ。親認証は「成功」「失敗」で遷移が変わるね。 初期 伸長中 シート表示中 スタンプ選択済み スタンプ押下済み 状態遷移 tap button select stamp tap card 縮小中 finish animation tap else finish stamp finish animation cancel メッセージ表示中 finish animation 親認証中 スタンプ追加中 tap_add ok ng finish
  52. 52. 52 Actionを4つ追加するよ。 この時、他には何も手を入れなくて良いのがまた良い 所なんだよね。 認証ダイアログ表示 認証ダイアログ非表示 スタンプ追加ダイアログ表示 スタンプ追加ダイアログ非表示 onEntryAuthParent() onExitAuthParent() onEntryAddingStamp() onExitAddingStamp() 親認証中 スタンプ追加中 大事なことなので2度 (ry
  53. 53. 53 少し複雑になったね。でも、この図のおかげで仕様書と 見比べれば何をやっているか想像つくし、変更するとき にどこを触れば良いかもわかりやすいでしょ? http://goodparts.d.yumemi.jp/generator#StateMachineGenerator--078e39c669ee45f55a2bf6b92523d32f0924aad8
  54. 54. 54 よろしい。 ならば仕様追加だ。 ま、まだまだ・・・ やれる・・・ 実際普通に 増えるんだよね・・・
  55. 55. 55 この2つの仕様が追加されたよ。 もう説明は省くけど、似たような感じで対応できるよ。 2012/12/ 21 スタンプをタップするとスタンプを 押した日付が見える 長押しでXボタン出現→削除
  56. 56. 56 コンポーネント間の連携はこんな感じになるよ。電源ボ タンの時と同じだね。 ViewController Activity FSM Action ユーザ Model Event ① onBtnTouch ② tap 初期 伸長中 ③ tap ④ onEnterExpanding() ⑤ Animation処理開始
  57. 57. 57 続きはWebで! http://qiita.com/mokemokechicken/items/9f59bbb11eec2f30b524 SMCの実行環境 % docker run -d -p 8000:8000 -p 9000:9000 -p 10022:22 -v /var/lib/smc:/application/GoodParts/mnt mokemokechicken/smc_service Dockerがあれば1行!
  58. 58. 58 StateMachineの 設計Tips
  59. 59. 59 最初みんな動詞にしてしまいます。 私もそうでした。 その1: 状態名は「名詞」にする 例えば、「ダイアログ表示中」というような状態名にします。 「ダイアログを表示する」「ダイアログ表示」とかだと 「動作」を表す印象になるので少しよろしくないです。 「〜中」「〜済み」のような感じにすると良いです。 英語でかくなら「 〜ing」「〜ed」になります。 状態名を動詞にしてしまうと、色々変な感じになるので注意してください。
  60. 60. 60 関連がある程度あって2x2くらいなら1つにしてしまう けど、それ以上だと分けるほうが良いように思うな。 その2: 複合状態名はなるべく作らない 例えば、2つの独立したView部品が1画面にあったとします。 例えば複数の「独立したアニメーション状態」などです。 それを一つの状態図に書くとどうしても複合した状態が出現しますが、 それらは個々の状態数の掛け算で状態数を増やしてしまいます。 複合状態を作ることはありますが、 基本的に独立している場合は複数の状態図・StateMachineに分けて 考えたほうがスッキリします。 StateMachine間の連携は「Action時に通知」などで疎結合させると良いです。
  61. 61. 61 スレッド間のMessage通信なので、ちゃんとお作法を守 らないと深遠なる不具合が発生するので注意してね。 その3: 1つのStateMachineは複数スレッドをまたがない StateMachineは「ある時刻」では必ず「1つの状態」になります。 複数スレッドの状態を1つのStateMachineで制御すると、 「スレッド毎の状態数の掛け算」の複合状態を考えることになってしまいます。 これはたぶん、上手くいかないので、各スレッド毎に1つStateMachineを作って、 それを統括するStateMachineをMainスレッドなどに保持するような親子関係と する方が上手くいくと思います。
  62. 62. 62 考察
  63. 63. 63 一連の通信処理とかは状態図で書いても良いけど、 シーケンス図の方がわかりやすい、という時もあるね。 状態図って、シーケンス図で書けな いの? シーケンス図は「決まった順序」のメッセー ジのやりとりを書くのに適しているけど、順 序が不定である場合は不向きだね。
  64. 64. 64 シーケンス図でかける処理は、Deferred/Promiseみた いなので十分書けると思う。 Yield/Return とか Deferred/Promiseと かでも非同期ロジックかけるよね? それらは「一直線な非同期ロジック」を書く のに向いているね。複数の分岐や繰り返し があったりするとちょっと辛いと思う。
  65. 65. 65 状態フラグが3つ目になったらそろそろやばい いつもStateMachineを使うべき? 状態が2〜3個くらいなら使わなくても良い かもね。ただ今後増えていく予感があれば 早目に切り替えたほうが吉だったりするよ。
  66. 66. 66 技術的負債を減らす努力は大事だね StateMachine導入するのめんどい! がんばれ。慣れだから。単体テストと同じ。
  67. 67. 67 あと、少し例にも出したけど、 「デバイス・センサー制御」でも役に立つことがあるよ。 カメラとかiBeaconとか。 UI制御以外に使い途があるのか? 例えば「アプリの起動・初期化処理」とかに はよく使うね。「データDL/展開」「ID作成・取 得」「更新チェック」とか色々あるからね。
  68. 68. 68 まとめ
  69. 69. StateMachineのメリット • 複雑な非同期ロジックがある場合 – 状態図による抜け漏れが(少)ない分析・設計 – 可読性が高く・変更に強い実装 – レビューが容易、再利用性も高い 69 夢のような感じだ
  70. 70. StateMachineのデメリット • 新しい概念を覚えないといけない(人が多い) – 覚えよう • StateMachineを実装するのが大変 – SMC使う • 導入前後ではリファクタリングが必要 – これはしょうがない 70 まあ、手間が増えるのは確かだね
  71. 71. 71

×