目のつけどころが"ソフト"でしょ　開発プロセス考14　――統合モデル化言語のステート・チャート

　統合モデル化言語という名まえを持つUML（Unified Modeling Language）のステート・チャート図（状態遷移図）^注というのは，なかなか興味深い特徴を持ちます．

　図1に示すのは，ガソリン・スタンドのセルフ式ポンプにおける簡単なステート・チャート図です．最初に「アイドル」状態に入ります．ここがちょうどお客さんを待っている状態です．お客さんが来て給油ガンを［取り上げる］と「レディ」状態になります．ここで，自動車の給油口に給油ガンを持っていき［レバーを引く］と，ガソリンが出る「ポンピング」状態になります．レバーを［リリースする］，給油ガンを［元に戻す］という過程を経て，元の「アイドル」状態に戻ります．

　そんなことはあらためて説明するまでもなく明白なことです．しかし，これがクラス図とどのようなつながりを持つのかを少し考えてみます．

［図1］　セルフ式ポンプのステート・チャート

●クラス図における状態，イベント，アクションの関係

　上記の［ ］で示される部分は，外界（対象としているオブジェクトの外側）からのイベントになります．このイベントを受けて状態遷移するわけですが，オブジェクト側の反応（アクション）を考えると次のようになるでしょう（実際とは違うかもしれないが，あくまでも例である）．

取り上げる ：ガソリン・メータのカウンタをゼロにする
レバーを引く ：ポンプを作動し，カウンタをインクリメントする
リリースする ：ポンプを停止し，カウンタを停止する
元に戻す ：入金を求める表示を出す

　これらの状態，イベント，アクションは，対応するクラス図では図2のように表現されます．ポンプの状態（アイドル，レディ，ポンピング）は，ポンプ状態という属性で表示されます．状態を属性として持つのがオブジェクト指向の大きな特徴です．状態を持つことは，状態遷移の制約（「アイドル」から「ポンピング」には直接遷移しないということ）を保証するために必要です．

［図2］　セルフ式ポンプのクラス図

●まず状態遷移（操作）を考えてみよう

　さて，この場合，クラスは状態遷移を考えることによってその構造が明らかにされます．一般にオブジェクト指向と言うとき，実体とその属性というとらえかたで説明されることが多いのですが，場合によっては，今回のように状態遷移からその構造を定義するということが主になる場合もあります．ソフトウェアであっても，リアルタイムで動作する組み込みシステムの場合にはイベント駆動になりますから，まず状態遷移を考えて，それからオブジェクトの構造を考えるということが自然になります．

　「オブジェクトはモノである」的な説明をする場合，オブジェクトと属性だけを考え，操作はとりあえず置いておく場合が多いのですが，適用する場面によっては，まずイベントに対するアクションとしての操作のほうから考える（状態遷移図を先にイメージする）ことが必要です．この場合，属性は単にどの状態にいるかということを記述するためにのみ存在することになり，一般の見かたとは逆になります．図式で書くと次のようになります．

1）［よくある説明］実体→属性→（必要に応じて）操作
2）［反応系における説明］実体→（イベントに対するアクションとしての）操作→（状態情報としての）属性

　実はリアルタイム系に限らず，2）で考えたほうがモデル化として自然であると筆者は考えていますが，その点についてはまた機会があれば説明したいと思います．

 注；状態遷移図に対して，ステート・チャート図は次の2点で異なる．（a）（アンドラインによって）並行で動作する遷移の記述が可能．（b）状態の入れ子表現を可能としている．ただし，今回の例では同等になっている．

(本コラムはDESIGN WAVE MAGAZINE 2002年8月号に掲載されました)

◆筆者プロフィール◆
伊藤昌夫（いとう・まさお）．自動車会社，航空機関連会社のソフトウェア・エンジニアを経て，ニルソフトウェアを設立．ソフトウェア・プロセスおよび開発環境が専門で，そのためのコンサルテーションおよびツールの提供を行っている．設計における人間の認知活動に興味を持っている．