　しかし、分科会にはエレベータの開発経験者はおりません。またエレベータについて豊富な知識があるわけでもありません。そこでまず、エレベータに関する知識を高めるため、エレベータ関連の情報を集めることにしました。例えば通常ボタンと車椅子ボタンが押された場合の違い、災害など緊急停止した際などの処理などさまざまな情報です。

　そして、いよいよモデリングの開始です。エレベータの知識を集めたメンバーは、自信を持ってモデリングに臨みました。一定のところまでスムーズに進んだのですが、ある個所でモデリングに行き詰まってしまいました。それもそのはずです。エレベータの開発経験のないメンバーが多くの知識を詰め込んだだけで、いきなりモデリングを開始したため、細かい仕様を一度に考え過ぎていたのです。モデルは複雑になってしまい、どの処理部分でどの機能を実現すればよいか、明確ではなくなってしまいました。

図1　エレベータモデル失敗例

　UMLのモデリング経験のあるエンジニアたちでさえ、このような事態に直面します。また今回のように、仕様段階においてモデルの複雑さが明確になったのは、UMLを使用するメリットであるともいえるでしょう。そこでエレベータの知識の少ないメンバーは、単純な仕様からモデリングをし直すことにしました。

ポイント1

初めてモデリングする際は、まず概念モデルから

概念モデルに立ち返って再挑戦！

　それでは概念モデルを紹介いたします。いきなりモデルが出てきましたが、深く考えずに気軽に読んでみてください（UMLの用語をなるべく使わず、一般的な用語を使って説明します）。まずモデリングの流れを説明します。

最初に、キャビンはどのような「要求」があるかを考える
その要求からはどのような「処理」があるかを考える
その処理を実現するのはどのような「動作」をしなくてはいけないかを考える
最後に、物理的にどのような「デバイス」が必要になるかを考える

　初めに要求する人（アクタ）は何になるのかを考えてみましょう。要求する人は乗客ですが、まだエレベータに乗っていないフロアにいる乗客とエレベータに乗っている乗客の2種類が考えられます。フロアの乗客はエレベータに乗るために「キャビンを呼び出す」という処理が考えられ、すでにエレベータに乗っているキャビンの乗客は「目的のフロアに移動する」という処理が考えられます。よって処理としては2つ考えられます。