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

More Related Content

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