はじめに

これまでは静的な構造(クラス図で表現する構造)を中心に取り上げてきましたが、今回は動的な構造、そのなかでも状態遷移について取り上げていきたいと思います。

動的構造とは時間の流れに沿って変化するものの構造のことで、状態の変化や処理の順序などが相当します。組込系のソフトウエアを扱う上で、この状態の概念は避けて通れないところです。
今回はまず、その基本である状態とは何なのかを取り上げていこうと思います。

トレースによる対応関係の明示

説明から入ると、状態とは対象(システム、コンポーネント、オブジェクト等)のライフサイクル(生成から消滅まで)から、ある区間を取り出し、それに他と区別するための名前を付けたものです。端的に言えば、ライフサイクルの「ある区間」なら何でも良いので、取出す人の考えに応じて何でも状態にすることができます。例えば、モーターの状態であれば、回っている、止まっている、壊れている、取り付けられている、誰かが触っている、雨が降っている、保管されている等々思いつくことならなんでも状態になります。

図1:モーターの取りうる状態

ただ、そうやって無秩序に思いついたものを状態として取り出してしまうと、それらの状態をモデルとして表現した時にいったい何を表したいのかが分からなくなってしまいます。ですので、状態を抽出する時には、それを状態とすることにモデルとして意味があるのか、システムとして意味があるのかが重要なポイントとなります。

何を状態にするのか

では、何を状態とすれば良いのでしょうか。先ほど、モデルとして意味がある、システムとして意味があるものが状態になると書きましたが、これを掘り下げてみましょう。

状態として意味があるとは、まずは対象が置かれているコンテキストにおいて、その状態を他の状態と区別する必要があるかどうかで考えます。例えば先ほどのモータで考えれば、モータを制御するというコンテキストから見ればモータが正常か故障しているかは重要な違いになるので、状態として意味があります。しかし、モータが在庫なのか出庫なのかは、制御する時点でもう手元にあるので意味を成しません。ここでコンテキストを在庫管理システムを作るときとしてみると、モータが在庫なのか出庫なのかは重要になりますが、正常か故障かはあまり関係ありません(在庫品は故障していないという前提が必要かもしれませんが)。

次に状態として意味があるかどうかを考えるポイントは、他の状態と比べた時に、その状態だけでできること、若しくは、その状態ではできないことがあるかです。例えば、「その状態の時だけ、行う処理がある」、「その状態の時だけ、この操作を無視する」といったものがあれば、それは意味のある状態になります。しかし、状態Aと状態Bを比べた時にできること・できないことの差がないのであれば、この2つの状態を区別する必要はない(2つの状態がある意味がない)ということになります。

非常に大雑把になりますが、状態を識別する基準はこの2点になります。

この基準から考えると、冒頭に挙げたモータの状態の中に怪しいものが混ざっているのが分かると思います。特に「雨が降っている」については、モータのライフサイクルの中で天候が変わることもあるかと思いますが、雨が降っていようと晴れていようとモーターには関係がありません。そのため、「雨が降っている」はモーターのライフサイクルから抽出される状態としては正しくありません(天候によって動作が変わるモータが存在するなら状態になるかもしれませんが)。また、「取り付けられている」、「誰かが触っている」、といったところもそれを区別する必要があるコンテキストは、そうそうないと思いますので、大抵のソフトウエアでは状態にならないでしょう。

ステートマシン図のモデリングでは、状態が正しく捉えられているかは悩みやすいポイントです。状態がうまく抽出できているか迷ったら、今回取り上げた観点から確認してみてください。

次回も引き続いてステートマシン図の話を取り上げていきたいと思います。