【連載】概念モデリングを習得しよう：ドメインファンクションを構成する基本プロセスとアクション記述の要点（第18回）

連載第16回でご紹介した参照の時と同様に、更新の例として挙げたアクション記述例も全て、記述順に実行されていくようなものではありません。理解促進のため、幾つかの例をデータフローのモデル図として紹介しておきます。（図表1、図表2）

※ CREATE INSTANCE ～ は、生成した概念インスタンスを“All instances of XXX”に出力するデータフローが本来あるが、割愛

※ DELETE INSTANCE ～ は、削除した概念インスタンスを“All instances of XXX”に出力するデータフローが本来あるが、割愛

以上、挙げてきたアクションの記述例は、概念ドメインに対して行う、ある目的ごとのひとまとまりの操作です。“果樹園”という概念ドメインにおいては、他にも無数の参照・更新操作が考えられます。
概念情報モデルを基にしたひとまとまりの操作を、ドメインファンクション（Domain Function）と呼ぶことにします。

これまで紹介してきたアクション記述例の中で使われた操作を分類し、基本的なプロセスとして列記します。

• 概念クラスのインスタンスの選択
  　▶　SELECT ～ FROM INSTANCES OF class [ WHERE ～ ] ;
• リレーションシップをたどってリンクされた概念インスタンスの選択
  　▶　SELECT ～ RELATED BY ～ [ WHERE ～ ] ;
• 概念インスタンスの特徴値への参照
  　▶　instance.property
• 概念インスタンスの特徴値の更新
  　▶　 instance.property = value ;
• 概念クラスを指定した、概念インスタンスの作成
  　▶　CREATE OBJECT INSTANCE instance of class ;
• 概念インスタンスの削除
  　▶　DELETE OBJECT INSTNACE instance ;
• リレーションシップを指定した、概念インスタンス間のリンクを作成
  　▶　RELATE a TO b ACROSS Rn [ USING c ] ;
• リレーションシップを指定した、概念インスタンス間のリンクの削除
  　▶　UNRELATE a FROM b ACROSS Rn [ USING c ] ;
• 算術計算
  　▶　v0 [+|-|*|/|%] v1
• 論理計算
  　▶　l0 [AND|OR|==|!=|>|>=|<|<=] l1
  　▶　NOT l
• 概念インスタンス集合の要素数
  　▶　CARDINALITY instanceSet
• 概念クラスにひも付いたオペレーション
  　▶　instance.operation()
• 外部実体のオペレーション
  　▶　EE::operation()

他に、データフローモデルをテキスト形式で記述するための形式的な記述方法があります。

• 条件分岐
  　▶　IF ～ [ ELSE IF  ～ ] [ ELSE ～ ] END IF ;
• インスタンス集合に対する各要素へのアクション
  　▶　FOR EACH instance IN instanceSet ～ END FOR ;

ドメインファンクションのほとんど全ては、これら基本プロセスの組み合わせで構成することができます。

ここまで紹介してきた、OAL によるテキスト形式のアクション記述と、データフローモデル図を比較してみてください。ホワイトボードを使って、複数人でディスカッションを行う場合は後者の方が便利なのですが、手書きしたモデル図の清書、その後のデジタル・IT的な管理・運用を考えると、テキスト形式で記述した方が、圧倒的に実用的であり実践的です。

では、なぜShlaer-Mellor 法をベースにした概念モデリングは、便利なテキストスタイルのアクション記述言語だけを紹介せず、データフローモデルに言及するのでしょうか。

それは、概念モデルが、現実世界を忠実に写し取るためのモデリング技法だからです。繰り返しになってしまいますが、あくまでもアクションの基本は“データフローモデル”であり、テキスト形式は実用性を考えた便宜的な記述方法であるからです。

現実の世界を想像してみてください。樹木にリンゴが生ったり、複数の人がリンゴの収穫数を検討したり、同時並行的に複数の樹木でリンゴを収穫したりと、圏Iの状態の更新・参照は、世界のさまざまな場所で同時多発的に発生するものです。参照・更新に含まれる基本プロセスは、各所で、それが必要とするデータがそろえば、勝手に出力が生成されるのが現実の世界です。

とはいっても、現実世界に合わせて、何らかの仕組みなしに圏Iのモデルが出来上がったり更新されたりすることはあり得ません。圏Iのモデルは、あくまでも意味の場（概念ドメイン）を通じて現実世界に対峙している、人間の思考の中に存在します。圏Iのモデルの参照・更新に関するアクションは、人間の思考を形作る認識の仕組みと同じなのかもしれません。
それを忠実に反映し、記述しようとしているのが概念モデリングのアクションというわけです。

ただ、本来的には二次元的なモデルであるデータフローモデルを、上から順番に書いていくテキスト形式で記述するには、どうしても原義的なテクニックが必要になってしまいます。また、概念モデリングになじみのない人にとっては、どうしても上から下に実行されると思ってしまいがちです。
類似のプログラミング言語として強いて挙げるのであれば、LISP*1 や F# などの関数型プログラミング言語や C# の LINQ*2 が近いと言えるでしょうか。

＊1： 1950年代に開発された歴史あるプログラミング言語で、データとプログラムを同じ形式で扱う「コード＝データ（Homoiconicity）」という特徴を持つ。リスト構造を基盤とした表現力の高さから、人工知能研究やシンボリック処理の分野で長年活用されている。

＊2：LINQ（Language Integrated Query）は、.NET 言語（C# など）に組み込まれた問い合わせ（クエリ）構文で、配列、コレクション、XML、データベースなど多様なデータ源を同じ記法で検索・変換できる。SQL に似た可読性の高い構文で、データ操作の記述を簡潔にする。

概念モデリングの実践においては、常に、脳内ではデータフロー的な描像を思い描きながら、アクションの記述を行いましょう。

これまで、現実世界の写しである圏Iのモデルに対する参照・更新を、概念情報モデルをもとにアクションとして記述する方法について解説してきました。

しかし、ドメインファンクションを複数同時に実行した場合、破滅的な結果が発生してしまうのは、マルチスレッドプログラミング*3の経験者なら容易に想像が付くことと思います。一般的なプログラミングにおける排他処理や、リレーショナルデータベースのトランザクションに当たるような仕掛けが、概念モデリングにも必要なのは言うまでもありません。

＊3： 一つのプログラムの中で複数の処理（スレッド）を同時並行で実行する仕組み。処理を細かく分け、同時に進めることで応答性や処理効率を高められる。

顕在的、時には潜在的な破滅の回避も含め、現実世界の動的な振る舞いを、意味の場を通じて忠実に描写するには、ドメインファンクションだけでは不十分です。

次回は、動的振る舞いを記述する、状態モデルについて解説します。