ここでは、概念モデルを作成してみましょう。概念モデルはクラス図で表現しますが、操作の代わりに責務を記述してみます。名前抽出されたものから、1つの名前につき1つの「クラス」を作成し、責務を記述してみましょう。そして各責務の記述されたクラスの関連を記述します。名前抽出の際は考えられる限りの抽出を行いましたが、ここでは不必要なものを削除します。また足りないものがあった際は追加します。このようにして責務を記した概念モデルを作成します。
CBCとはクラスをベースにしたコミュニケーション図になります。クラス図とコミュニケーション図を合わせたものをイメージしてください。CBCとは聞き慣れない言葉だと思います。というのもUML表記法ではなく、分科会オリジナルの表現方法になります。シュレイア・メラー法に似ているもので、OCM(Object Communication Model:オブジェクト通信モデル)に相当します。ここでは、役割分担を考えクラスの責務分担とメッセージを考え、シナリオを緩く考えてモデリングを行うといったものです。
クラス図を作成する際に、クラス、属性、操作を一度に考えてモデリングを行うより、1つ1つ順序立てて考えた方がモデリングは容易に行えます。よってまず静的な構造として「クラス名と属性」のみを記します。ここではあくまで静的な図であることが重要で、操作などの動きは考えません。またクラス間のコミュニケーション関連を記述します。
IBCとはインスタンスをベースにしたコミュニケーション図になります。UMLのコミュニケーション図そのものですが、CBCとの区別のためにIBCと呼称しています。特定のシナリオを表したもので動的検証を目的にしたものです。つまり、今回のシナリオ(ユースケース記述)は5つありますが、それぞれのシナリオを深く考えてモデリングを行います。そうすることによりクラス間のコミュニケーションとして何を行う必要があるか、どのような操作を行うべきかが明確になります。
本稿ではCBCモデル、IBCのモデルは紹介しておりませんが、詳細を知りたい方は、ぜひUMTPにご参加ください。
クラス図はUMLで一番基本となるモデルです。IBCの操作はクラスとクラスのコミュニケーション間に記述されていますが、その「操作」をクラスの内部に割り当てると通常のクラス図が作成されます。またクラス図はモデリング指針を決めて数回にわたり洗練させていきます。また分析モデリングと設計モデリングの明確な境界はありません。徐々に分析モデリングから設計モデリングになっていきます。分科会では3回のリファインを行いました。その過程を以下で参照してください。
以下のモデリング指針に基づき作成。
以下の指針に基づき洗練。
以下の方針に基づき洗練。
今回、UMLを組み込み開発に適用するためのリファレンスモデルとして、エレベータのキャビンモデルを紹介しました。分科会では、カテゴリに着目した名詞抽出方法、CBC(クラスベース・コミュニケーション図)、IBC(インスタンスベース・コミュニケーション図)を使用するクラス作成方法など、UMLを組み込み開発に適用するために有効なノウハウを研究しています。今後の取り組みは、設計モデルを完成させ、シミュレーションを行っていく予定です。このリファレンスモデルが完成した際は、またの機会に紹介したいと思います。
これまで3回の連載で紹介してきた組み込みUMLは、まだその歴史は浅く、今後その取り組みはさらに活発になっていくことでしょう。今回リファレンスモデルの作成に当たり、分科会の参加者メンバーは熱い思いがあります。UMLでの設計(モデルベース設計)が当たり前になる時代を待っているのではなく、「私たちの手で作っていく!」そういった強い意思を持っています。皆さんも一緒に取り組みませんか!(連載完)
Copyright © ITmedia, Inc. All Rights Reserved.