ちょっと話す機会があって、
こんなかんじかしら・・・
って、説明したのをシェアシェア！
（１）いちばん、やりたいことの中心のシナリオをまとめる
・人感センサーで、店内の通行量をはかり、３０秒おきに、本部に送って結果が見れるようにする
（２）なんについて、何で、何をするか、決める
→「なんについて」をユースケース、「何で」アクターにすると、ユースケース図が書ける
・例「なんについて」：人気スポット集計（いいのか？この名前で）
「何で」人感センサー、本部、
（３）上記（２）で決めたことを実現する為に、必要なものや事前にやっておくことを
考えて、ストーリー（シナリオ）を作る
・例：人が通ったら、人感センサーがON
ONになったら、端末で、人数１UP
端末は、３０秒ごとに本部にデータ送信、送信後、カウントを０に
本部は、端末からデータを受け取り、DB登録
本部は３０秒ごとに店舗交通量表示画面をリフレッシュ
→ストーリー（上記の例のようなもの）を、ユースケース記述とする
（４）上記（３）で出てきた「もの」を、１レーンとして、ユースケースごとに、業務流れ図を作成する
このとき、入出力を明確にして書く。
入力は、通信・DB以外として、センサーと画面がありえる
出力も、通信・DB以外として、アクチュエーターや画面・帳票・Excel等ファイルがありえる
・例：
人、センサー、端末、本部を各レーンとして、
業務流れ図を書く
※レーンはアクター以外もありえる
（上記だと、アクターにイベントを起こす「人」や、
内部の資源である「端末」も入る）
→業務流れ図がアクティビティ図になる
（５）業務流れ図をもとに、シーケンス図を作成し、
メッセージ交換内容を明確にする
・例：アクティビティ図から、メッセージが発生するのは
人感センサーと端末：GPIO？ならON/OFF
端末と本部：時間＋場所＋人数、これ以外のメッセージ居る？
→シーケンス図を描きましょう
（６）データ入出力部分の画面や、DBなど、決まっていないものの項目を決める
画面は、画面定義書（＝画面遷移図＋画面レイアウト・画面項目定義・アクション定義）
DBは、DB定義書（＝ER図＋DBテーブル（項目）定義）
というかんじで・・
→画面遷移図は、書く気になれば、状態遷移図で表現できる
DB定義書は、クラス図で表現できる
（７）上記（４）で作成した、業務流れ図を、レーンごとにみる。そうすると、
どっかから、「イベントが起こり、一連の処理をして、どっかに飛んでいく」
という流れの繰り返しになる。
このとき、「イベントが起こり、一連の処理をして、どっかに飛んでいく」
を１つの状態とする。
そうすると、１レーンごとに業務流れ図をみると、
・何かの処理をしている状態と、
何もしていない状態の繰り返しになる。
各状態の遷移を、状態遷移図であらわす。
・例：端末のレーンに着目する
「センサーからONが入ってきたら、カウンターを１上げる」という状態と
「３０秒ごとに、本部データ送信、カウンターを０に」という状態がある。
上記状態を「センサーON」、下記状態を「本部転送」とする。
ただし、ここで、何もしないという状態が問題になる。
「センサーON」と「本部転送」が独立して起こるなら、何もしない状態は、
「センサーOFF]と「転送まち」状態になるが、
「本部転送」中は「センサーON」処理をしないのであれば、何もしない状態は
「センサーOFF＆転送まち」状態の１つとなる。
これは、仕様により判断する。
→状態遷移図は、ステートマシン図です。
（８）上記（７）の業務流れ図には、（４）で入出力を書いた。
なので、（７）で振った、どの状態のときに、どの入出力を行うかわかる。
また、（５）のシーケンス図は、（７）の業務流れ図の状態に対応できるはずなので、
（どちらも同じ（４）の業務流れ図を基に作っているから）
その状態のときに、どのメッセージを投げるかがわかる。
そこで、各状態において、どのような入出力と、メッセージが必要かを、
（４）の業務流れ図と、（５）のシーケンス図をもとに、状態ごとにまとめる。
例：端末
case センサーONのときは、
GPIOから、どこかへ保存
break;
case 端末のときは
保存データを読み込み、（５）で考えたメッセージを作り、本部へ送信
break;
→これは、もう言葉で書くかんじなので、UMLつかわない。
（９）実装する
Arduinoのプログラムで、状態がどのときは。。。とか、コーディングしていく
（１０）テストする
がんばれ！
いじょう・・・
こんなかんじかしら・・・
って、説明したのをシェアシェア！
（１）いちばん、やりたいことの中心のシナリオをまとめる
・人感センサーで、店内の通行量をはかり、３０秒おきに、本部に送って結果が見れるようにする
（２）なんについて、何で、何をするか、決める
→「なんについて」をユースケース、「何で」アクターにすると、ユースケース図が書ける
・例「なんについて」：人気スポット集計（いいのか？この名前で）
「何で」人感センサー、本部、
（３）上記（２）で決めたことを実現する為に、必要なものや事前にやっておくことを
考えて、ストーリー（シナリオ）を作る
・例：人が通ったら、人感センサーがON
ONになったら、端末で、人数１UP
端末は、３０秒ごとに本部にデータ送信、送信後、カウントを０に
本部は、端末からデータを受け取り、DB登録
本部は３０秒ごとに店舗交通量表示画面をリフレッシュ
→ストーリー（上記の例のようなもの）を、ユースケース記述とする
（４）上記（３）で出てきた「もの」を、１レーンとして、ユースケースごとに、業務流れ図を作成する
このとき、入出力を明確にして書く。
入力は、通信・DB以外として、センサーと画面がありえる
出力も、通信・DB以外として、アクチュエーターや画面・帳票・Excel等ファイルがありえる
・例：
人、センサー、端末、本部を各レーンとして、
業務流れ図を書く
※レーンはアクター以外もありえる
（上記だと、アクターにイベントを起こす「人」や、
内部の資源である「端末」も入る）
→業務流れ図がアクティビティ図になる
（５）業務流れ図をもとに、シーケンス図を作成し、
メッセージ交換内容を明確にする
・例：アクティビティ図から、メッセージが発生するのは
人感センサーと端末：GPIO？ならON/OFF
端末と本部：時間＋場所＋人数、これ以外のメッセージ居る？
→シーケンス図を描きましょう
（６）データ入出力部分の画面や、DBなど、決まっていないものの項目を決める
画面は、画面定義書（＝画面遷移図＋画面レイアウト・画面項目定義・アクション定義）
DBは、DB定義書（＝ER図＋DBテーブル（項目）定義）
というかんじで・・
→画面遷移図は、書く気になれば、状態遷移図で表現できる
DB定義書は、クラス図で表現できる
（７）上記（４）で作成した、業務流れ図を、レーンごとにみる。そうすると、
どっかから、「イベントが起こり、一連の処理をして、どっかに飛んでいく」
という流れの繰り返しになる。
このとき、「イベントが起こり、一連の処理をして、どっかに飛んでいく」
を１つの状態とする。
そうすると、１レーンごとに業務流れ図をみると、
・何かの処理をしている状態と、
何もしていない状態の繰り返しになる。
各状態の遷移を、状態遷移図であらわす。
・例：端末のレーンに着目する
「センサーからONが入ってきたら、カウンターを１上げる」という状態と
「３０秒ごとに、本部データ送信、カウンターを０に」という状態がある。
上記状態を「センサーON」、下記状態を「本部転送」とする。
ただし、ここで、何もしないという状態が問題になる。
「センサーON」と「本部転送」が独立して起こるなら、何もしない状態は、
「センサーOFF]と「転送まち」状態になるが、
「本部転送」中は「センサーON」処理をしないのであれば、何もしない状態は
「センサーOFF＆転送まち」状態の１つとなる。
これは、仕様により判断する。
→状態遷移図は、ステートマシン図です。
（８）上記（７）の業務流れ図には、（４）で入出力を書いた。
なので、（７）で振った、どの状態のときに、どの入出力を行うかわかる。
また、（５）のシーケンス図は、（７）の業務流れ図の状態に対応できるはずなので、
（どちらも同じ（４）の業務流れ図を基に作っているから）
その状態のときに、どのメッセージを投げるかがわかる。
そこで、各状態において、どのような入出力と、メッセージが必要かを、
（４）の業務流れ図と、（５）のシーケンス図をもとに、状態ごとにまとめる。
例：端末
case センサーONのときは、
GPIOから、どこかへ保存
break;
case 端末のときは
保存データを読み込み、（５）で考えたメッセージを作り、本部へ送信
break;
→これは、もう言葉で書くかんじなので、UMLつかわない。
（９）実装する
Arduinoのプログラムで、状態がどのときは。。。とか、コーディングしていく
（１０）テストする
がんばれ！
いじょう・・・
アクセス
トータル
ランキング
