検索
連載

組み込みUMLのリファレンスモデルを学ぶ組み込み開発にUMLを活用しよう(3)(3/3 ページ)

ユースケース分析やドメイン図、概念モデルなど、組み込み開発に特化したUMLモデリングの各工程を詳細に解説する

PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ |       

主要な責務を表す概念モデル(クラス図)

 ここでは、概念モデルを作成してみましょう。概念モデルはクラス図で表現しますが、操作の代わりに責務を記述してみます。名前抽出されたものから、1つの名前につき1つの「クラス」を作成し、責務を記述してみましょう。そして各責務の記述されたクラスの関連を記述します。名前抽出の際は考えられる限りの抽出を行いましたが、ここでは不必要なものを削除します。また足りないものがあった際は追加します。このようにして責務を記した概念モデルを作成します。


責務を記した概念モデル
図6 責務を記した概念モデル

CBC(クラスベース・コミュニケーション図)

 CBCとはクラスをベースにしたコミュニケーション図になります。クラス図とコミュニケーション図を合わせたものをイメージしてください。CBCとは聞き慣れない言葉だと思います。というのもUML表記法ではなく、分科会オリジナルの表現方法になります。シュレイア・メラー法に似ているもので、OCM(Object Communication Model:オブジェクト通信モデル)に相当します。ここでは、役割分担を考えクラスの責務分担とメッセージを考え、シナリオを緩く考えてモデリングを行うといったものです。

 クラス図を作成する際に、クラス、属性、操作を一度に考えてモデリングを行うより、1つ1つ順序立てて考えた方がモデリングは容易に行えます。よってまず静的な構造として「クラス名と属性」のみを記します。ここではあくまで静的な図であることが重要で、操作などの動きは考えません。またクラス間のコミュニケーション関連を記述します。

CBC(クラスベース・コミュニケーション図)
図7 CBC(クラスベース・コミュニケーション図)

IBC(インスタンスベース・コミュニケーション図)

 IBCとはインスタンスをベースにしたコミュニケーション図になります。UMLのコミュニケーション図そのものですが、CBCとの区別のためにIBCと呼称しています。特定のシナリオを表したもので動的検証を目的にしたものです。つまり、今回のシナリオ(ユースケース記述)は5つありますが、それぞれのシナリオを深く考えてモデリングを行います。そうすることによりクラス間のコミュニケーションとして何を行う必要があるか、どのような操作を行うべきかが明確になります。

IBC(インスタンスベース・コミュニケーション図)
図8 IBC(インスタンスベース・コミュニケーション図)

 本稿ではCBCモデル、IBCのモデルは紹介しておりませんが、詳細を知りたい方は、ぜひUMTPにご参加ください。

クラス図

 クラス図はUMLで一番基本となるモデルです。IBCの操作はクラスとクラスのコミュニケーション間に記述されていますが、その「操作」をクラスの内部に割り当てると通常のクラス図が作成されます。またクラス図はモデリング指針を決めて数回にわたり洗練させていきます。また分析モデリングと設計モデリングの明確な境界はありません。徐々に分析モデリングから設計モデリングになっていきます。分科会では3回のリファインを行いました。その過程を以下で参照してください。

分析クラス図(その1)

 以下のモデリング指針に基づき作成。

  1. 物理構成を中心に目的や事象を表現するオブジェクトを見いだして関連付ける
  2. 乗客や待ち客の個々の要求ごとに移動という事業が存在するのではなく、それら複数の要求すべてを満たすための移動インスタンスが1つだけ存在するものとしてモデリングする
  3. 複数の要求を調整して最適な移動順を決定する責務を持つスケジューラを導入する
分析クラス図Vol.1
図9 分析クラス図Vol.1

分析クラス図(その2)

 以下の指針に基づき洗練。

  1. 物理構成を中心に目的や事象を表現するオブジェクトを見いだして関連付ける
  2. 複数の要求が存在する場合、方向ごとにすべての要求を満たしてからほかの方向に対する要求を満たすものとする
  3. 複数の要求を調整して最適な移動順を決定する責務を持つスケジューラを導入する
分析クラス図Vol.2
図10 分析クラス図Vol.2

分析モデル(その3)

 以下の方針に基づき洗練。

  1. 物理構成を中心に目的や事象を表現する。またオブジェクトを見いだして関連付ける
  2. 複数の要求が存在する場合、方向ごとにすべての要求を満たしてからほかの方向に対する要求を満たすものとする
  3. 複数の要求を調整して最適な移動順を決定する責務を持つスケジューラを導入する
分析クラス図Vol.3
図11 分析クラス図Vol.3

最後に(私たちの手で……)

 今回、UMLを組み込み開発に適用するためのリファレンスモデルとして、エレベータのキャビンモデルを紹介しました。分科会では、カテゴリに着目した名詞抽出方法、CBC(クラスベース・コミュニケーション図)、IBC(インスタンスベース・コミュニケーション図)を使用するクラス作成方法など、UMLを組み込み開発に適用するために有効なノウハウを研究しています。今後の取り組みは、設計モデルを完成させ、シミュレーションを行っていく予定です。このリファレンスモデルが完成した際は、またの機会に紹介したいと思います。

 これまで3回の連載で紹介してきた組み込みUMLは、まだその歴史は浅く、今後その取り組みはさらに活発になっていくことでしょう。今回リファレンスモデルの作成に当たり、分科会の参加者メンバーは熱い思いがあります。UMLでの設計(モデルベース設計)が当たり前になる時代を待っているのではなく、「私たちの手で作っていく!」そういった強い意思を持っています。皆さんも一緒に取り組みませんか!(連載完)


Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ |       
ページトップに戻る