ユースケース図は第2回でも紹介していますが、ここではエレベータ・モデルに沿って解説します。まずアクタとして、フロアからキャビンを呼び出す「フロアの乗客」とキャビンに乗ってエレベータの移動をする「キャビンの乗客」の2種類が考えられます。
フロアの乗客は「キャビンを呼び出す」というユースケースが考えられ、キャビンの乗客は「目的のフロアへ移動する」というユースケースが考えられます。そして、それぞれ「ドアを閉じる」「移動する」「ドアを開ける」という動作のユースケースが考えられます。
そして動作のユースケースは、ドライバとしてのアクタである「ドア制御」「移動制御」に関連しています。組み込み開発は、ユーザー要求とドライバの両方に関連する表現を行うことがポイントとなります。
ユースケース記述は、各ユースケースについての詳細を記述します。つまり「キャビンを呼び出す」「目的のフロアへ移動する」「ドアを閉じる」「移動する」「ドアを開ける」という5つのユースケースについて記述します。ここでは「キャビンを呼び出す」というユースケースについて考えてみましょう。
ユースケース名は「キャビンを呼び出す」になります。そして概要として「キャビンがフロアの乗客の所へ移動するユースケース」となります。アクタは「フロアの乗客」で、処理が終了した後の事後条件として「キャビンがフロアの乗客の所に移動してドアが開いている」とします。
次にシナリオを記述しますが、通常のケースとして「基本系列」、また違う状態の場合の「代替系列」の2つについて考えてみます。基本系列としては、アクタは「キャビンを呼び出す」から始まり、「ドアを閉じる」「移動する」「ドアを開ける」の各ユースケースを起動するという処理を行います。次に代替系列としてドアがすでに閉まっている場合は、ドアを閉めるという作業を行う必要がなく、そのまま移動するという処理を行います。
ドメイン図はUMLの「パッケージ図」を用いて各ドメインと関連を記述します。まず、ユースケースよりキャビン(ユースケース図の左側)とデバイス(ユースケース図の右側:ドア制御、移動制御)の2つのドメインに分割します。そのほか、エレベータ利用の経験からボタンに代表される入力手段や停止階などの表示手段としてのユーザーインターフェイスドメインを抽出しました。さらに、フロアにいる乗客の要求を調整してキャビンへの要求へと変換するコントローラドメインを抽出しました。
結果としてドメインは「キャビン」「コントローラ」「ユーザーインターフェイス」「デバイス」の4つに分割されました。各ドメインの関連を考えると、キャビンはコントローラから操作され、ユーザーインターフェイスを操作し、デバイスを操作するというような関連になります。よって図4のようなドメイン図が作成されます。
ここではキャビンに関して、関係のある名前を抽出してみましょう。UML表現をする際、ここからがポイントになります。
これまでは、ある程度エレベータについて順序立てて考えていけば理解できますが、この名前抽出に関しては、各ドメインに固有の専門知識が重要であり、またテクニックが必要となります。さまざまなテクニックがありますが、今回はカテゴリに着目して抽出するという方法を使用しました。
カテゴリとは、大きく分けると「目的」と「物理」に着目して考えます。目的に着目して考えると「目的フロア」などが考えられ、物理に着目して考えると「ドア」など物理的なものが考えられます。そのほかに、「サービス」に着目して考える、「ルール」に着目して考える、「マテリアル(材料)」に着目して考える、また「抽象部品」「ハードウェア」など各種カテゴリに着目して考えます。特に組み込み開発としては、材料、部品、ハードウェアというカテゴリに関して考えて名前抽出を行うことが重要となってきます。
名前抽出の工程では、思い付く限りの名前を抽出してみましょう。不必要であれば後々削除すればよいので、とにかく思い付く限りの名前抽出を行うのがポイントです。
Copyright © ITmedia, Inc. All Rights Reserved.