UMLモデルからテストケースを作ろう

1. はじめに

本連載では、UMLの導入に敷居の高さを感じている方を対象に、手軽で有効的なUMLモデルの利用方法をご紹介することが目的です。

第1回では、モデルが円滑なコミュニケーションをサポートすることを解説しました。第2回では、誤解の少ないコミュニケーションを行うために、要素間の関係を正しく表すUMLモデルの作成手順を解説しました。

今回は、ステートマシン図から簡単なテストケースを作成する方法を解説します。UMLモデルが、コミュニケーションのサポート以外にも利用できるとなると、UMLモデルを作成する価値がさらに高まります。

2. ステートマシン図を作成する

UMLのステートマシン図では、外部のイベントに対するオブジェクトの振る舞いを、オブジェクトの状態遷移として表すことができます^*1。

ここでは「タスク管理」を例に挙げて、オブジェクトの状態遷移を考えてみましょう。今回とりあげるタスク管理は、「タスク」（作業）の状態を

• やるべきこと（TODO）
• 現在とりかかっていること（DOING）
• 完了したこと（DONE）

に分類し、タスクを付箋（ふせん）で表して管理する方法です（「付箋によるタスク管理」とよぶことにします）（図1）。

• [*1] UMLのステートマシン図には、振る舞いステートマシンとプロトコルステートマシンの2種類があります。振る舞いステートマシンは、イベントに対するオブジェクトの振る舞いを表します。一方、プロトコルステートマシンは、ある状態および条件のもとで、1つのクラス(またはコンポーネント)の呼び出し可能な操作と、操作を呼び出す順番を表します。

「タスク」とは、「○○さんに打ち合わせの時間を連絡する」や「不具合番号9001の不具合を修正する」というような、実際に手を動かす作業のことです。「付箋によるタスク管理」の「タスク」をオブジェクトとしてとらえ、ステートマシン図を使ってタスク・オブジェクトの状態遷移を表してみましょう。

図2は、タスク・オブジェクトの状態遷移をシンプルに表したステートマシン図です。なお、本記事では、必要最低限のUMLの表記法についてのみ解説します。UMLの詳細な表記法や厳密なモデリングの手法については言及しませんので、ご了承ください。

図2のステートマシン図は、左端の黒丸（開始状態）から始まります。開始状態から「TODO」状態へ矢印が伸びていますが、これは、「タスク・オブジェクトがタスク管理に登録されると、最初にTODO状態になる」ことを表しています。この矢印は「イベントによる状態の遷移」を表しており、イベントが明記されていない場合は、自動的に遷移することを表します。

TODO状態からDOING状態への矢印には「とりかかる」という記述があります。これは「とりかかる」というイベントが起こると、タスク・オブジェクトの状態が、TODO状態からDOING状態に遷移することを表しています。

同じく、「放棄する」というイベントによって、DOING状態からTODO状態へ遷移します。これは、タスクにとりかかろうと思い、タスクをDOING状態にしたものの、急ぎでやらなければならない割り込みタスクが起こったため、タスクを放棄し、タスクの状態をTODO状態に戻す、といったケースを想定しています。

DOING状態からDONE状態への遷移も同じように考えます。「やりおえた」というイベントによって、状態が遷移することを表しています。さらに「やりおえた」イベントが起こった際は、タスク・オブジェクト（付箋）に「“済”シールを貼る」というアクションが実行されることも、明示しています。

逆に、DONE状態になったタスク・オブジェクトが、実は完了していなかった場合、DOING状態に遷移します。これを「やりのこしを見つけた」イベントで表しています。この際、タスク・オブジェクトから「“済”シールをはがす」というアクションが実行されます。

DONE状態は、「破棄する」というイベントによって、二重丸（終了状態）へ遷移します。終了状態への遷移は、タスク・オブジェクトが消滅したことを表します。なお今回は、タスク・オブジェクトがTODO状態やDOING状態の時に、タスク・オブジェクトを破棄することはできないことにします。

このようにステートマシン図を用いて、イベントに対するオブジェクトの振る舞いを、オブジェクトの状態遷移として表現できます。ソフトウエア開発にかかわる関係者の間で振る舞いに対する認識が異なると、期待通りのソフトウエアを作成することができません。図2のように非常にシンプルなUMLモデルであっても、誤解の少ないコミュニケーションをサポートするツールとして活用できます。