3. 概念情報モデルの操作
本ドキュメントの利用は、https://github.com/kae-made/kae-made/blob/main/contents-license.md に記載のライセンスに従ってご利用ください。
Date: 2023/11/26 - Version 1.1.1
はじめに
前節では、概念情報モデルがどのように使われるかについて解説を行いました。この節では、より具体的に、概念情報モデルに対する様々な操作を、コンピュータが理解できる程度の簡便な文法を交えて解説していきます。
この節では、長ったらしい用語を使うのはやめて、以下の様に省略した用語で解説していきます。
主題領域 → ドメイン
概念クラス → クラス
概念インスタンス → インスタンス
概念インスタンス間の関係 → リンク
ドメインの状態更新
その時々の、存在するインスタンス群と各インスタンスの特性値の値、および、リンク群のスナップショットを、「ドメインの“状態”」と呼びます。これは、ビジネスに関わる情報の現況をデジタル化したものと一致します。
ビジネスに関わる状況保持と状態の取得を行うための、概念情報モデルに対する操作は、大きく、 “状態の更新”と“問合せ（クエリー）”の二つに分類できます。
“状態の更新”には、
インスタンスの生成
リンクを張る
リンクを切る
特徴値を更新する
インスタンスの削除
の５種類の操作があり、“問合せ（クエリー）”は、
インスタンスをすべて取り出す
条件に合致したインスタンスを取り出す
あるインスタンスを起点にリンクでつながっているインスタンスを取り出す
の３種類です。
状態の更新
状態の更新を行う５種類の操作を順に解説します。
インスタンスの生成
概念情報モデルで定義されたクラスのインスタンスを生成します。インスタンスの生成とともに、設定可能な特徴値の値は確定します。インスタンスの表形式においては、クラスの表に一行追加して、全てのカラムに値を入力すること、が、この操作によって行われます。
リンクを張る
生成済みの２つのインスタンスの間で、概念情報モデルで、そのインスタンスのクラスの間で定義された Relationship（関係）に従ってリンクを張ります。
この操作により、該当するインスタンスの関係を表す特徴値の値が更新されます。
装置管理ドメインの装置の前後関係を使って、例を示します。
Relationship（関係）クラスが定義されている関係の場合には、リンクを張るために、Relationship（関係）で定義されているRelationship（関係）クラスのインスタンスを一つ作成し、作成したインスタンスを絡めてリンクを張ります。
リンクを切る
既に存在しているインスタンス間の関係を削除します。該当するインスタンスの関係を表す特徴値の更新や、Relationship（関係）クラスのインスタンスが存在する場合には、そのインスタンスの削除が伴います。
特徴値を更新する
既に存在しているインスタンスの特徴値を更新します。
インスタンスの削除
既に存在しているインスタンスを削除します。インスタンスの表形式においては、クラスの表から該当するインスタンスの行を削除すること、が、この操作によって行われます。
その際、関連している関係がある場合は、その関係を表す参照特徴値の値を更新します。
インスタンスの特徴値の更新
存在しているインスタンスの特徴値の値を更新します。更新できるのは、
識別子を表す特徴値
関係（Relationship） を表す特徴値
計算可能な特徴値
以外の、特徴値だけです。2番目の”関係（Relationship）を表す特徴値”は、前述の”リンクを張る”、”リンクを切る”アクションを実行した際に、そのリンクの概念情報モデル上の関係（Relationship）の定義に従って、関連する特徴値の値が更新されるものとします。
3番目の”計算可能な特徴値”は、概念情報モデル上の定義に従って、その特徴値を参照した時に値が確定しているものとし、この特徴値の値そのものを直接更新することはできません。
状態の更新に関する注意
リンク群は、状態更新前、状態更新後で、概念情報モデルで定義された制約を満たしていなければなりません。
例えば、クラス“A”とクラス“B”で１対１の“R１”という関係が定義されている場合は、これは、クラス“A”のインスタンスが一つ存在したら必ず“R1”という宣言であり、クラス“B”のインスタンスがただ一つつながっているという事を意味します。
つまり、クラス“A”のインスタンスを一つ新たに生成したら、対応するクラス“B”のインスタンスを新たに一つ生成（既に存在している“B”のインスタンスは別の“A”のインスタンスとつながっているので）して、新しく作成した２つのインスタンスの間で“R1”という関係でつながなければならない、ということを強制します。
この時、既に存在している”B”のインスタンスと、新しく生成されたクラス”A”のインスタンスの間にリンクを張る事はできません。何故なら、その”B”のインスタンスは、既に存在している別のクラス”A”のインスタンスとR1 でリンクが張られているからです。
逆に、クラス“A”のインスタンスを一つ削除する場合は、“R1”の関係でつながっているクラス“B”の削除とつながりの削除を行わなければなりません。
更に、クラス”B” が R1（図6‐2. の例では”R_LE1”） 以外の Relationship（関係）を持っている場合も、その Relationship（関係）の制約も満たす様に、インスタンスの生成・削除、リンクの切張（それに伴うインスタンスの特徴値の更新）を行わなければなりません。
概念情報モデル上で、相手方の多重度が“１”、もしくは“1..*”の場合は、必ず生じる事態なので留意しておきましょう。
インスタンスの生成・削除、リンクの切張、特徴値の更新は、単なる空虚な数学的な演算ではありません。
図に示したように、概念情報モデルで定義された制約を満たすのに必要な操作は、現実の世界やビジネスシナリオのコンテキストにおいて必ず意味を持ちます。
よって、概念情報モデルを元にしたドメインの状態更新を考える場合は、それぞれの操作が、現実世界の何に対応するかを常に意識しなければなりません。
インスタンスの削除に伴って生じる概念情報モデル上のつじつま合わせを精査することにより、見落としていたビジネス要件を発見する場合もあります。
ドメインへの問合せ（クエリー）
概念情報モデルで定義された制約に従って存在する概念インスタンス群が保持する情報（データ）は、現実世界の様々なシーンの要請に基づいて参照が行われます。参照には、概念インスタンスの取り出しや、あるインスタンスを起点にしてリンクされたインスタンスを取り出す様な操作が必要です。
問合せ（クエリー）を行う３種類の操作を順に解説します。
インスタンスをすべて取り出す
概念情報モデルで定義されたクラスのインスタンスをすべて取り出します。取り出したインスタンスに対して、その特徴値の参照・更新が可能です。
この場合、取り出した結果は、同一の概念クラスのインスタンス（への参照）の集合です。
条件に合致したインスタンスを取り出す
概念情報モデルで定義されたクラスのインスタンスのうち、指定した条件に合致したもののみ取り出します。例えば、温度が30℃以上のインスタンス、金額が5000円以下のインスタンスといったような条件付きの検索です。
取り出したインスタンスは、その特徴値の参照・更新が可能です。
検索の際、条件に合致するインスタンスを複数取り出す場合は、”インスタンスをすべて取り出す”と同様、結果は、同一の概念クラスのインスタンスの集合です。条件に合致するインスタンスを一つだけ取り出す場合の結果は、インスタンスの集合ではなく、唯一つのインスタンスです。
あるインスタンスを起点に関係しているインスタンスを取り出す
概念情報モデルで定義されたクラスの一つ、あるいは複数インスタンスへの参照を既に取り出している場合、そのクラスに定義された関係を指定して、インスタンスがその関係のもとにつながっているインスタンス群を取り出します。
この場合は、取り出した結果は、一つ前の”条件に合致したインスタンスを取り出す”と場合と同様です。
問合せに関する注意
問合せでは常にインスタンスの集合が結果として得られます。ある時点のインスタンスや関係の状況によって、結果がただ一つのインスタンスだったとしても、それはたまたまそうであっただけであり、要素が唯一つの集合であると考えてください。
その時々の個々のインスタンスの状態に依存した操作を考えるのではなく、そのインスタンスの分類として定義されたクラスのレベルで操作を考えることは非常に重要です。
ドメインのインスタンス（群）の状態は、時間の経過に伴ってどんどん変化する非恒常的な存在です。
一方で、どんなにインスタンス（群）の状態が変化しても、インスタンスの存在基盤となっている、概念を抽出したクラスと Relationship（関係）で定義された概念情報モデルは変わることは無く安定しています。
容易には変わらない概念情報モデルを対象にすれば、安定したレベルでのITシステムの設計が可能になり、変化に強い IT システムが構築できます。
その他の操作
これまで、ドメインの状態更新と問合せ（クエリー）に関する解説を行ってきました。利用可能な（より正確に言えば、モデル化対象の現実世界の振舞を記述するのに必要十分な）操作群は、
インスタンスの特徴値の参照
算術演算によるデータ変換
論理演算によるデータ変換
条件分岐
インスタンスへの事象発生
などが利用可能です。これらについては、「概念振舞モデル」の巻で詳しく解説します。
ドメイン ファンクション
概念情報モデルは、複数の概念クラスと、様々な多重度が定義された複数の Relationship から構成されるものです。現実の世界の要件を元にしたシナリオによる、概念インスタンスの生成・削除や 関係（Relationship） のリンクの切張等、ドメインの状態を更新する様な操作が含まれる一連のアクションの流れは、その一連のアクションの完了時点で、概念情報モデルで定義された関係（Relationship）の多重度が満たされていなければなりません。
この、対象ドメインのビジネスシナリオに基づいた、ドメイン状態を更新する一連の操作群のまとまりを、”ドメイン ファンクション”と呼ぶことにします。
概念情報モデルで定義された概念クラスを雛形に存在する概念インスタンス群は、現実の世界においては、それぞれが独立に存在する実体に対応します。一連の操作群をテキストで記述すると、あたかも、記述された順番に操作が行われるような幻影を見がちですが、例えば、あるドメイン ファンクション内で、複数の概念インスタンスの生成や削除を行う場合、関係（Relationship） の制約がなければ、それぞれの概念インスタンスに対応する実体の生成や削除は同時に行う事も可能である事に注意が必要です。
ドメイン ファンクションは、モデル化対象の現実世界を反映させるため、「概念振舞モデル」で紹介している”データフローモデル”の観点で定義・記述しなければなりません。
概念情報モデルをユースケースの基盤として活用する
システム開発における要求仕様記述において、ユースケースを使う人が多いように見受けられます。しかし、名前付きのスティックフィギュア（アクター）、楕円（ユースケース）、アクターとユースケースをつなぐ線から構成されたユースケース図と、ユースケースごとの自然文で記述されたシナリオだけでは、曖昧さを排除することは難しく、ユース定義を記述した当人と、記述されたユースケースの読者の間で共通認識が得られず誤解を生む可能性を排除できません。
ユースケースで使用する語彙の厳密な定義
また、モデル化対象の現実世界の何かと1対1対応にある、概念インスタンス、概念インスタンスに紐づいた値が確定した特徴値、概念インスタンスを意味的に結ぶリンクの世界を記述した 圏I のモデルと、それらを分類したスキーマとしての 圏C の概念情報モデルを厳密に区別する概念モデリングの技法の観点からすると、記述されたユースケースが、圏I のモデルなのか 圏C のモデルなのかも曖昧です。現実世界の変化に影響を受けにくい安定性の観点から言えば、記述するユースケースもまた、圏C のモデルであるべきでしょう。それはそれとして、ユースケースを定義する前に、ユースケースを記述する対象世界に対して、予め概念情報モデルを作成しておけば、データ型、概念クラス、特徴値、関係（Relationship）を使って厳密に定義された語を、アクターやユースケースの名前、シナリオの文において使うことができ、読者の誤解を生じさせる可能性を減らせるとともに、シナリオで記述した命題文が有意味でかつ真であることも常に確認できます。
ユースケースの事前条件・事後条件
それぞれのユースケースは、起動の時に満たすべき事前条件とユースケース完了時点に満たすべき事後条件を持ちます。ここまで読み進んできた読者であれば、もうお判りですね。この事前条件、事後条件もまた、概念情報モデルを使って厳密な定義が可能です。今時はありえない非常にシンプルな CRUDソリューション（インスタンスの Create、Read、Update、Delete だけで機能を網羅可能）なら何とかなるのかもしれませんが、モデル化対象の現実世界を構成するものやことが複雑に絡み合うような場合は、自然文の記述の羅列だけで、見落としや錯誤を防ぐのは基本的に無理でしょう。概念情報モデルの、特に関係（Relationship）で定義された、モデル化対象の現実世界に潜む意味的なつながりを満たすように記述していけば、システム全体の整合性と一貫性を保った事前条件、事後条件の記述が可能です。
ユースケースの並行起動
概念情報モデルの定義をベースに、語を使ってアクターとユースケースの名づけて、シナリオと事前条件・事後条件を記述したとしても、ユースケースが同時並行的にバラバラに起動された時にどうなるかを、ユースケースだけで記述するのは至難の業です。この観点については、次の”同時並行性を考慮する”での解説を考慮しなければなりません。この観点についての詳細は、”概念振舞モデル”で詳しく解説しているので、そちらを参照してください。
実装要件の混在
システム要件を記述する場合、どんな内容を記述するべきかは、諸説あります。システムを動かすのに使う実装プラットフォーム（プログラミング言語や、ミドルウェア、ハードウェア、OS等）が選択済みで、かつ、未来永劫選択した実装プラットフォームを変えない場合は、使用する実装プラットフォームを前提としたユースケース記述は特に問題は生じないですが、次々と更新され、高性能になっていくサードパーティ製の実装プラットフォームを複数組み合わせて使用する場合のユースケースは、実装プラットフォームに依存しない、”そもそもビジネスとして何をやりたいのか”に関するユースケース記述であるのが望ましいでしょう。この様なユースケースを記述するには、概念モデリングのドメインという概念が非常に有効です。詳しくは、”ドメインと IT システム構築”を参照してください。
同時並行性を考慮する
現実の世界を思い浮かべてください。商品販売の世界では、複数の顧客が何の関係もなく任意の時点で商品を注文するでしょうし、商品の補給や新規商品の追加なども同時並行的に行われます。この様に現実の世界では物事が同時多発的にドラスティックに起こって移り変わっていきます。その現実の世界の写しとしてモデル化した概念情報モデルの世界もまた同じ特性を持っていると考えます。誰かが問合せ（クエリー）の操作を行っていると同時に、別の誰かが、その問合せ対象である、インスタンス群の構成と関係群を更新し続けています。
誰かが状態の更新を行っている最中に、別の誰かが同時に状態の更新を行っている可能性があります。例えば、ある顧客の注文を行うために商品の検索をして、検索した時点では在庫があったにもかかわらず、注文のインスタンスを作成して商品に紐づけようとした時点で既に在庫切れを起こしているかもしれません。
現実のビジネスでは、当然このような事態が発生しないような仕組み、例えば、事前引き当てや割当て、競合する要求の調停が仕組みとして入っていなければ、ビジネスの流れは破綻してしまいます。
概念情報モデルにおいても、このような、リソース割当てや競合する要求の調停等に必要な概念群を抽出し、それらを表現するクラスや Relationship（関係）として定義しておかなければなりません。
一見しただけではシンプルなビジネスシナリオに見えたとしても、概念モデリングの過程で、従来は曖昧だった要件が明確に概念群として定義されたことにより、これまで発見されなかった競合や割当ての必要性が発見されるかもしれません。
なお、現実世界で生ずる、同時並行的に発生する、リソース割当や競合する要求の解決に必要な操作・振舞は、概念情報モデルを基盤にしたデータの操作に関する記述だけでは不可能であり、事象駆動の状態モデルによる記述が必要です。その様な動的な側面を記述する為のモデルを、”概念振舞モデル”と呼びます。
概念情報モデルは、その操作・振舞を行うのに必要なデータを保持するための、（役割的には重要だとしても）単なるスキーマの定義にすぎません。
概念振舞モデルの詳細は、この概念モデリングに関する一連のドキュメントの「概念振舞モデル」で解説しているのでそちらをご覧ください。
概念モデリング上の留意点
現実の世界は様々な側面から観察することができ、その世界を記述するためには必要十分な側面からの観察の結果を基にした記述が必要です。モデル図はその為の記述の文法（Syntax）を提供します。
現実世界を観察するための各側面ごとに、その特性に応じた適切なモデル図が存在します。その選択を間違えて、別の側面の情報を無理やり追加しようとすると、そのモデル図は破綻し、オンボロ煙突以下の使えない単なる絵と化してしまうでしょう。
複数のモデル図の記法を習得するのが面倒だからと言って、一つの図だけで、複雑な現実世界を記述しようというような無謀な試みは慎むことをお勧めします。
まとめ
以上、概念情報モデルの操作の種類とそれぞれの操作に関する説明と注意点を説明してきました。これらは全て、概念情報モデルを使って、現実のビジネスの状態を保持・参照する場合の、論理的に導かれる必要な操作と注意点です。
実際のITシステムに概念情報モデルを組み込んで利用する場合に、ここで説明した操作群は、ファイルストレージやデータベース等、具体的なサービスやアプリケーションを使って実現することになります。利用するITのサービスやアプリケーションが５種類の更新操作と、３種類の問合せ操作に該当する機能を持っている場合はそれを利用し、機能が不足している場合は、自力で必要な操作を実装することになります。
概念情報モデルの操作に関する解説は以上です。
次は、ドメインの動的な側面を記述する為の「概念振舞モデル」を解説し、その後、「概念情報モデルをITシステムに組み込む」で、定義した概念情報モデルをITシステムに組み込む方法を解説します。
この記事が気に入ったらサポートをしてみませんか？