【連載】概念モデリングを習得しよう：状態モデルの作り方とUML図法の使い分け、概念モデリング実践のポイント（第21回）

次は、状態です。

概念クラスの“状態”と聞くと、特にオブジェクト指向プログラミングに慣れた読者は、class の内部状態と捉えがちだと思われます。しかし、概念モデリングにおいて、その先入観は一切捨てしまわなければなりません。

以前にも解説したように、意味の場を通じて見た世界の状態は、圏Iのモデル全体で記述するのが基本です（図表1）。概念クラスの状態モデルの“状態”は、その一部を扱いやすいように、便宜的に切り出したものに過ぎません。
状態にひも付いたエントリアクションでは、その状態機械のひも付く概念インスタンスの特徴値や意味的なリンクだけでなく、その概念インスタンスが存在する、圏Ｉのモデル全体の参照・更新が可能です。

状態は、以下の二点をもとにしたイベントとアクションの整理分類によって導出され、概念クラスとして定義されている概念ドメインの分類の意味付けとしてふさわしい名前が付与される、と考えます。

• 圏Iの状態を参照・更新するアクションが、状態のエントリアクションである
• ある状態への遷移にひも付くイベントの引数のシグネチャは同じである

筆者はこれまで、概念ドメインや概念情報モデル、アクション記述について、哲学や数学を駆使して小難しい理屈を解説してきました。それに比べると、この説明は、随分とお手盛りなものに感じるかもしれません。しかし、これが30年来概念モデリングの実践を続けてきて到達した、筆者の境地です。上の二点を意識することが、状態モデル作成のコツといっても過言ではありませんし、事実、対象世界の状態変化を、シンプルな状態モデル群で記述できます。

念のため補足しておきますが、現実の世界において同種の出来事が発生したとき、その出来事に起因する状態の変化は、時々の状態の違いによって異なります。これは、状態モデルにおいて、一つのイベントが、状態遷移図上の複数の遷移のトリガーとしてひも付けられることを意味します（図表2）。

概念モデリングにおいて、状態モデルを記述する道具立ては非常にシンプルです。シンプルな道具立てで十分なのは、意味の場（概念ドメイン）ごとに概念情報モデルを作成し、概念クラスの状態をモデル化するからです。
皆さんのモデリングにおいて、シンプルな道具立てだけでは足りないと感じたら、今一度、何を対象（意味の場）にモデル化しているのか、対象としている意味の場の概念情報モデルが妥当かどうか、見直してみましょう。

念のため補足しておきます。図中の“1. 準備完了”という状態にはエントリアクションが記述されていません。なぜならこの状態への遷移は記述されておらず、実行されるエントリアクションは存在しないからです。このケースに限らず、全ての状態がエントリアクションを伴うとは限りません。モデル化対象の意味の場において、記述する必要があれば記述し、必要なければ記述しない、が基本です。使っているモデル図記法が豊富であると、それらを全て使わなければならないという強迫観念に陥りがちですが、記述するべきものだけ記述する、これがモデリングの要諦です。

ここまで、概念モデリングにおける、意味の場を通じて観た、現実世界の状態変化の記述方法の基本について解説してきました。
これまで述べてきた通り、状態変化の記述は状態モデルと状態のエントリアクションで記述します。本稿では、状態モデルは UML の表記に準じた状態遷移図で図表記を用いることとし、アクションは、BridgePoint の OAL（Object Action Language）での記述を用いました。

UML 2.0 では、状態遷移図のことを、正式には“状態マシン図（State Machine Diagram）”と呼ばれています。
UML では、システムの動的振舞いを記述する図として、アクティビティ図（Activity Diagram）もあります。

ところで、皆さん、システム開発の実践の場で、状態機械図やアクティビティ図をうまく使い分けられていますか？
UML のアクティビティ図で使用する図要素は、状態マシン図とほぼ同じで、混乱を生じる要因に思えます。

UML の標準化が進められた時代、同じような様相を図示化する、似て非なるモデル記法が多数存在していました。UML の表記は、当時の多くのモデル記法がサポートする図要素を網羅するような形で標準化されたこともあり、図の基本要素も豊富です。このこともうまく使いこなせない要因なのかもしれません。

本稿では、ドメインファンクションやエントリアクションの記述において、本来はデータフロー図で記述するべきものを実用上の観点から、BridgePoint の OAL（Object Action Language）を使ったテキスト形式で記述すると紹介してきました。

概念モデリングにおけるこれらの記述を UML に準拠したモデル図で描きたい場合は、アクティビティ図が妥当でしょう。
状態モデルの図と同様、UML 表記で決められている道具立てのごく一部を使えば、データフローモデルを満たす記述は可能です。ただし、図表3で示す図を描くだけでも、筆者はテキスト形式の OAL で書くのに対して何十倍もの時間を使っています。処理の流れの図による表記は、実用の観点から、図ではなくテキスト形式による表記がお勧めです。

余談ですが、筆者は、状態図とアクティビティ図をうまく使いこなせないUML 初心者が少なからずいるように感じています。どちらの図も現実世界の動的振舞いを記述するための図ですが、状態、イベント、処理、フローとは何か、を明確に理解していないと使い分けは難しいでしょう。

“何の状態？”とか、さらには、“何の動的振舞い？”といった事項を明確に意識していないと、描いたは良いが、混沌とした図が出来上がってしまうでしょう。作った本人は、難しい図を作り上げたという、なんだかよく分からない達成感と高揚感は感じるにしても、実用の観点から見れば、むしろ、無駄な作業をしただけ、といった結果になってしまうのが落ちです。

UML では多くの種類の図法が標準として定義されています。複雑な現実世界をたった一つの記法で図示化することはできないので、複数の図法が用意されています。
これらの図法を実用レベルで組み合わせて使いこなすには、何を対象にしてどのように組み合わせて使うか、言ってみれば、モデル図に関するアーキテクチャが必要です。
これまで説明してきたように、概念モデリングのアーキテクチャは、以下の通りです。

• 意味の場ごとにモデルを作成する
• 概念情報モデルで意味の構造を記述する → クラス図
• 概念クラスごとに、状態モデルを記述する → 状態マシン図
• 状態のエントリアクションで状態変化に関わる処理を記述する → アクティビティ図

これらは、図法を使いこなす有力な指針になるでしょう。

本稿では皆さんの開発プロセスにおける表記法が UML を使わなければならない場合に、利用可能な図法を付与してみました。これらの図を使わなければならないという筆者の推奨ではないので、ご留意ください。

ほかに、作成した概念モデルを検証したり、利用したりするフェーズで、UML の表記法を使うと便利な局面が幾つかあります。それらについては、今後のテーマごとに紹介していく予定です。

概念モデリングで作成に注力する全ての図は、現実世界を構成する事柄と一対一で対応する圏Iの世界のモデルではではなく、分類（概念）に関する圏C（スキーマ圏）のモデルに関するものです。
概念モデリングに限らず、モデル図を描くときには、その対象が、圏Iの世界なのか、圏Cの世界なのかを常に意識することも、適切なモデルを描くコツの一つです。

次回は、状態モデルの基本パターンである「生成・消滅型」と「巡回型」について解説します。あわせて、状態モデルの構造や振舞いをどのように捉えるべきか、実践的な観点から考えます。