シーケンス図を使ったステートチャートの作成(1)

状態遷移図・ステートチャートをシーケンス図から設計する手法があるようです。

モデル検査法
http://apal.naist.jp/~seki/Japanese/ss/2011-2.pdf

例に挙げているのは通信プロトコルのモデル化で、

(1) 正常系のシーケンス図の作成
(2) それぞれのラインに対して、トリガー（入力イベント）を見つける
(3) 状態を見つける
(4) 状態遷移図に起こす
(5) 書きづらい・読みづらいなど、必要に応じて階層化
(6) 上記を、その他の正常系や異常系で繰り返す

といったもの。

今回はサンプルとして、メールソフトからのメール送信について、この手順を追ってみようと思います。

(1) 正常系のシーケンス図の作成

利用者、メールソフト、メールサーバで正常系のシーケンス図を作成。

まずは、メールサーバの入力イベントで区切ってみると、入ってくる矢印、出ていく矢印に注目。

状態は、「idle」「新着確認」「受付中」がみつけられる。さて、メールサーバの状態はこれだけだろうか。

ハレルの状態遷移図 statechart を勉強する

twitter で @Unity1004 さんがファミコンで有名なスーパーマリオの状態遷移図（＝マリオチャート）を描きながら、ハレルの statechart 等の話題が出たりしていたので、僕も勉強してみようと思う。

==

仕様書や設計所が自然言語で記述されている場合、視覚的にわかりやすくするために図や表に整理することが多い。その整理方法のひとつとして状態遷移モデルを状態遷移図に記述する工夫がある。しかし、一般的な状態遷移図では、似たような状態が複数登場したり、オブジェクトがひとつの状態でしかなりえないが、実際のソフトウェアでは複数の状態をもつことも多い。

そこでデビッド・ハレル氏が提唱したハレルチャート（statechart）が登場します。

以下は、astah を使って記述した一般的な「キッチンタイマー」の statechart である。

参考：　http://www.ssi.ist.hokudai.ac.jp/Archives/.../systemdesign2011-5-24-1.pdf　
参考：　http://zone.ni.com/devzone/cda/tut/p/id/12848

参考にした2つの説明ページでは、どちらもズームインしながらチャートを作成していく手順である。また、特定のサブ状態（子要素を持つ状態）を検討しているときは、別のサブ状態を抽象化してわかりやすくしている。ちなみに今回使用した astah では、サブ状態の内部には開始疑似状態は作れなかった。

状態遷移表と論理決定表で機能図式

状態遷移図を工夫してみるの続き。

コメント欄にて教えていただいた「機能図式」を自分なりに少しまとめてみて、そのあとで例題に適用してみようと思います。

機能図式とは、ソフトウェア機能仕様を

「入力データ」と「入力順序」を状態遷移モデル

「入力データ」と「出力データ」と「遷移先状態」を論理モデル

を使って表現することを指しています。
機能図式の記法については、論文を参照してください。基本的には状態遷移図、原因結果グラフ、デシジョンテーブルの記法の組み合わせ。

では、メール一覧のアプリを例にとって実際に機能図式を作ってみる。

仕様を箇条書きでまとめると、以下のようなアプリケーションです。

1. デスクトップのアイコンをダブルクリックして、アプリが起動


2. メールが1通もない場合は、メールがない旨の表示


3. メールがあればメール一覧をリスト表示。5通ずつのページング表示で、必要に応じて「前リンク」「次リンク」が表示


4. 前リンクをクリックすると、前のページの5通を表示。次リンクをクリックすると、次のページの5通を表示


5. （上図にはないが、）右上の[x]をクリックするとアプリ終了

このメール一覧のアプリを機能図式で表現すると、まずは状態遷移部がこのようなグラフとなる。

また、論理関係部はこのようなテーブル（決定表）となる。

決定表の各列にはパス名としてPxxを名付けてみました。
テスト経路作成基準は論文中では「全遷移を少なくとも1回、ループについては0回と1回の2通りを実現する」とある。論文には具体的なテスト経路作成アルゴリズムも紹介されているが、まだ消化不良なので、今日はここまで。

状態遷移図を工夫してみる

簡単な状態遷移図を作ってみるの続き。

メールソフトを起動するときに、メールがある場合とない場合で初期画面が異なります。この部分についての状態遷移図はどうやって作るか。僕の場合は観測できない状態を１つ用意して、内部イベントの違いによって遷移を分ける方法をとっている。

実際には「メールが5通以下」「メールが6通以上（すなわち、次リンクが表示される）」「メールがない」の3パターンが考えられるので、「S1→(S2)→S3」「S1→(S2)→S4」「S1→(S2)→S5」の3パスが表現できる状態遷移図を作成。ここでは観測できない状態S2を終了状態にはできないので、実際のテストケースを作成するときには、少し注意が必要。

ただし、分岐条件が複雑になった場合はこの手法だけでは難しくなってくる。たとえば、「インストール後最初の起動時にはお知らせ画面を表示する」とか、「未読メールがある場合はその旨を通知するダイアログを出す」とか、そういった仕様があったとすると、どうします？

そこで「機能図式」という考え方へ進んでいきます。続く～。

簡単な状態遷移図を作ってみる

状態と遷移とイベントとアクションの続き。

具体的に状態遷移図を作ってみますかね。一つ目は比較的シンプルなもの。

「電源ボタン」と「強さボタン」をもつヒーター

電源ボタンを押すと、電源のON/OFFが切り替わり、強さボタンを押すと、「強」「弱」が切り替わるヒーターです。

状態は「電源OFF」「電源がONで、強さが弱」「電源がONで、強さが強」の3つ。イベントは「電源ボタンを押す」「強さボタンを押す」の2つ。

では、こちらはどうでしょうか。

メールソフトのメール一覧機能

デスクトップにアイコンがあって、ダブルクリックすると起動するメールソフトですが、メールが受信箱にある場合とない場合とで、初期画面がが異なります。

上の図はメールソフトの起動時のみを表現したものです。が、状態遷移図は、状態とイベントが一つ決まれば遷移先の状態とアクションも決まる、はず。でも、この図を単純に状態遷移図にしたら、ちょっとへんですね。左の状態では「次>>」というイベントが可能ですが、左の状態では不可能のようです。みなさんは、どんな状態遷移図を考えますか？

状態の洗い出しへHAYST法かpairwise法の適用

状態遷移モデルを使ったソフトウェアテストを勉強するためのテキストとしてボーリス・バイザーの「ソフトウェアテスト技法」「実戦的プログラムテスト入門」などを読んでみた。手順の最初に出てくるのが、仕様書からの状態とイベントの洗い出し作業。そもそも状態遷移図や状態遷移表を作ることって設計工程のツールなので、上流工程でのこういった作業が作りこみを減らすことにつながる。

で、ソフトウェアテスト技法のほうで状態の数を探るところ（第11章　4.2）があるのだけれど、具体例としてエンジンを題材にして、

ギア　　　（R、N、1速、2速、3速、4速）　＝　6要素
進行方向　（全身、後退、停止）　＝　3要素
エンジン　（動作中、停止）　＝　2要素
トランスミッション　（正常、異常）　＝　2要素
エンジン　（正常、異常）　＝　2要素

合計　＝　144要素

という記述がある。ここでいっている不可能な状態への考察って、禁則の考え方じゃないのかしら？だとすると、HAYST法を使って状態を絞り込むことができるのかな。ただ、本質的には同じことだけどHAYST法（＝直交表）の特徴である、「どの条件も同じ程度出現する」というのはいらないので、pairwise法のほうが状態数が少なくなるのかな。

ソフトウェアテスト技法―自動化、品質保証、そしてバグの未然防止のために

posted with All Consuming at 2008.12.27

by ボーリス バイザー
日経BP出版センター
定価： ￥ 5,607

Amazon.co.jp で詳細を見る
ブックオフオンラインでチェックする
All Consuming でブログの評判を見る
crossreview のレビューを見る

実践的プログラムテスト入門―ソフトウェアのブラックボックステスト

posted with All Consuming at 2008.12.27

by ボーリス バイザー
日経BP社
定価： ￥ 4,095

Amazon.co.jp で詳細を見る
ブックオフオンラインでチェックする
All Consuming でブログの評判を見る
crossreview のレビューを見る

状態と遷移とイベントとアクション

状態遷移図や状態遷移表を使う場合（ここでは状態遷移モデルを扱う、と同義）に、まずは構成要素である「状態」「遷移」「イベント」「アクション」を確認しておこう。

• 状態
• 遷移
• イベント（入力）
• アクション（出力）

状態とは、状態遷移モデルでも通常の言葉と同様の意味で使われ、「システムの当分の間の状況と特性」というとらえ方をする。基本的な考え方としては状態は同時にはただ一つしかありえない。排他型と並列型という状態のとらえ方もあるが、ここでは割愛する。たとえば、「電源がOFFである/ONである」「インターネットが切断状態である/接続状態である」「検索状態である/検索結果表示状態である」など。

遷移とは、ある状態からある状態へ状態が移り変わることを表す。たとえば、「電源が（電源ボタンを押したことで）OFF状態へ遷移する」「インターネットが（認証成功によって）接続状態へ遷移する」「（検索結果が確定して）検索結果を表示する」など。

イベントとは、遷移をもたらす外的刺激や内的変化などを表し、入力とも事象とも表現される。ひとつのイベントは一つの遷移を決定するが、それらはイベント発生時の状態によって変化する。場合によっては、イベントはシステムに関するものではなく、システムのユーザへの刺激で表現される。たとえば、「電源ボタンを押す」「接続の認証が成功する」「検索クエリーのレスポンスが確定する」「○○さんに連絡する用事が発生する」など。

アクションとは、遷移の結果生じる分析が可能な対象物を意味し、入力と対照的に出力とも表現される。混同されやすいが、アクションと遷移後の状態は区別される。ただし、出力も遷移後の状態も同じ名称で表現されることが多いのは確か。たとえば、「（電源がONに遷移して）ディスプレイが点灯する」「（接続の認証が成功して）アイコンが点滅する」「（検索結果が確定して）検索結果が表示される」などである。

さて、これらのうち「状態」「遷移」「イベント」を使って、状態遷移図と呼ばれるグラフを作成してみる。

一般的には、状態はマルで表現して、中に状態名を記述する。ただし、必要なのはモデルであるため便宜上はS1,S2などと記載される。遷移は矢印で表現され、始点は遷移前の状態と、終点は遷移後の状態と接している。イベントは状態同様にE1,E2などで省略され、対応する遷移（矢印）のそばに記述する。

あれ、アクションがでてきません。アクションは状態遷移表で記述しましょう。今日はここまで。

スイッチカバレッジのまとめ

WACATE 2008 冬も無事終了したので、ここらへんで状態遷移テストについてちょこちょこ書いていこうっと。

ということで状態遷移テストで登場するカバレッジ基準をまとめてみる。具体例や図はのちほど。

ノード網羅

システムの仕様書から「状態」を洗い出して、その状態をすべて確認すること。たとえば、バスのボタンを例に取ると「消灯」状態、「点灯」状態が考えられ、それらの状態自体を確認すること。もっともレベルの低いカバレッジ基準。

リンク網羅（0スイッチカバレッジ）

システムの仕様書から「状態」と「イベント」を洗い出して、そのイベントの表す遷移をすべて確認すること。たとえば、バスのボタンを例に取れば、イベントとして「ボタンを押す」、「点灯をリセットする」などが考えられ、状態遷移図の中の→をすべて網羅することになる。このカバレッジ基準を確認するとともに、状態遷移図から状態遷移表への変換を行い、「無効な遷移（=N/A）」の確認をあわせて行うべし。仕様書のままではもちろんのこと、状態遷移図の形でも無効な遷移は網羅しにくい。0スイッチカバレッジともいう。状態遷移図も状態遷移表も視覚的にも仕様が直感的に確認できるので、動的テストではなく設計時の検証方法でも利用される。

1スイッチカバレッジ

0スイッチカバレッジの上位のカバレッジ基準。合計3つの状態を2回のイベントで遷移する経路をすべて網羅するカバレッジ基準の名称。0スイッチカバレッジでは、状態遷移表を作成することで、登場するマス目を網羅すればよいのだが、1スイッチカバレッジは組み合わせを考慮する必要がある。一般的には行列の積（累乗）で計算可能。1スイッチカバレッジまでは最低限確認したいところ。

2スイッチカバレッジ

1スイッチカバレッジの上位のカバレッジ基準。合計4つの状態を3回のイベントで遷移する経路をすべて網羅するカバレッジ基準の名称。こちらも行列計算で全パスを抽出可能だが、対角線上のマス目に注目して、遷移ループを優先的にテストを実施するなどの工夫が考えられる。