キッチンから学ぶUMLの勘所

早速クラス図を書こう

UML 2.1において、ソフトウェアの構造を表す図としては、クラス図、オブジェクト図、パッケージ図、コンポーネント図、配置図などがあります。

ここでは食器洗い機の振る舞いについて、フォーカスして考えたいので、クラス図には「Dishwasher」というクラスを1つ描きます。開発対象をオブジェクト指向システムとすると、システムはオブジェクトと呼ばれる部品の集まりです。オブジェクトは、クラス（型）が実体化（インスタンス化）されたものです。少し乱暴な言い方になるかもしれませんが、クラスがそのものの設計図となり、その設計図から作成されたものがオブジェクトです。クラスには、属性、操作などを持つことができます。ここでは、最初の段階として、Dishwasherという型を定義しました。

次に、Dishwasherの振る舞いについて考えたいと思います。UMLで振る舞いを表す図としては、状態マシン図、アクティビティ図がありますが、ここでは状態マシン図を用いて、Dishwasherの振る舞いを表現したいと思います。

（画像をクリックすると別ウィンドウに拡大図を表示します）

振る舞いも階層構造で表現する

図2をもとに状態マシン図の解説をすると、Dishwasherとしての状態は「active」という状態が1つあります。しかしながら「running」「service」「mode」の並列状態を持ち、理論的には同時にその3つの状態が処理されます。

running状態は「off」「on」「open」状態があり、on状態はさらに「washing（洗浄中）」「rinsing（すすぎ）」「drying（乾燥）」状態があります。running状態での振る舞いを説明すると最初はoff状態にあり、evStartというイベントが発生すると、操作setup（）を行いon状態に遷移します。

on状態になると、洗浄、すすぎ、乾燥の各処理を決められた回数分だけこなすように表現されています。on状態中にユーザによって食器洗い機のドアを開けられた場合は、evOpenというイベントが発生し、open状態になります。ユーザがドアを閉じた場合は、evCloseイベントが発生し、開けた直後の処理から再開します。その再開処理は、図2中の真ん中のHで表すことができます。

service状態では、食器洗い機が正常に動作しているかを監視します。状態としては「normal（正常）」「faulty（故障）」があります。今回の場合あるガード条件「isInNeedOfService()」を満たした時に故障することにします。UMLでは遷移のフォーマットは「トリガー[ガード]/アクション」として表現します。

mode状態では洗浄を行うモードを管理します。モードには「quick（迅速モード）」と「intense（食器の汚れがひどい場合のモード）」があります。evModeというイベントで、モードを変更することができます。洗浄などの回数は、このモードによって変更できることとします。処理は操作「setup()」で切り替えできるようにします。