概念モデリング ワークショップ 基礎編 - Conceptual Modeling for Real World
•
0 likes•33 views
現実世界を理解し記述する為の概念モデリングに関するワークショップ資料の基礎編です。 ”Art of Conceptual Modeling (https://note.com/kae_made/m/m054c9f9f8b61)”を集合教育スタイルで学ぶ為の資料です。 冒頭のライセンスに従ってご利用ください。
Recommended
More Related Content
Similar to 概念モデリング ワークショップ 基礎編 - Conceptual Modeling for Real World
Similar to 概念モデリング ワークショップ 基礎編 - Conceptual Modeling for Real World (20)
More from Knowledge & Experience
More from Knowledge & Experience (20)
概念モデリング ワークショップ 基礎編 - Conceptual Modeling for Real World
- 1. 概念モデリング ワークショップ 基礎編 Knowledge ＆ Experience 代表 太田 寛 https://www.kae-made.jp Twitter： @embedded_george 1 Date: 2023/12/9 Version: 1.2.0
- 2. 本資料について • 使い方 • 本資料は、“Art of Conceptual Modeling”のコンテンツを元に作成した集合教育向けの講師用 プレゼンテーションです • ワークショップ実施の際 • 演習込みで2日間の目安で実施 • 演習は、4～5人のチームで行う • 受講者ごとに、紙と鉛筆を用意 • チームごとにホワイトボードや大判用紙、ペンを用意 • ワークショップの講義で概要を学び、 “Art of Conceptual Modeling” とhttps://note.com/kae_made のドキュメントで詳細を習得 • 有償にて講師対応しますので、お気軽に master@kae-made.jp までご連絡ください • ライセンス • 本ドキュメントは、https://github.com/kae-made/kae-made/blob/main/contents-license.md に従ってご利用ください 2 ライセンスより抜粋： •個人学習、ビジネス用途における組織内での学習用途においてはご自由にお使いください。 •ビジネス用途の場合、学習の結果として得られたスキルにより開発されたシステム、ソリューション、機器がリリースされた場合は、可能な限り、 users.mdへの組織名の追加を Pull & Request で申請してください。 •WEB サイトや CD 等、書籍等紙媒体等を含め再頒布は、改変の有無に関わらず、無料、有料の有無を問わず、禁止します。 •コンテンツ群を使った無許可での有料セミナーの開催や配信は禁止します。実施したい場合は、ライセンス料として料金の 15% をお支払いいただきま す。詳しくは、 master@kae-made.jp にご連絡ください。
- 3. アジェンダ • ワークショップの目的 • 概念モデリングの意義 • 現実世界をモデル化する • 概念情報モデル • ドメイン • 概念振舞モデル概要 • メタモデル 3
- 4. ワークショップの目的 • 概念モデリングが必要な理由を理解する • 概念モデリングの基本を習得する • 概念モデルが読めるようになる • 概念モデルを作成できるスタートラインに立つ 4
- 6. AI、IoT、Digital Twins も全ては現実を理解し記述する事から モデル駆動型開発の基本 Zinovy Diskin et.al の論文 “Category Theory and Model-Driven Engineering: From Formal Semantics to Design Patterns and Beyond” より Digital Twins: 現実世界のモノ・コト等を、データ化して、デジタル空間上に 再現する為のテクノロジーセット IoT : 現実世界のモノ・コトの状態（データ）をデータ空間上に収集する、 あるいは、状態（データ）を変えるためのテクノロジーセット DX（Digital Transformation）: デジタルテクノロジーを使用して、ビジネスプロセス・文化・ 顧客体験を新たに想像して、変わり続けるビジネスや市場の要 求を満たすプロセス ※ Wikipedia より 技術的基盤 技術的基盤 現実世界における“やりたい事”のモデル ↤ “対応付け” Open AI ↤ “対応付け” 6
- 8. 演習１. • 二人でペアを組む • 一人が最近気になっている事を話す 3分ぐらい？ • その間、聞いている人は、その話の中から要点を抜き出し箇条 書きをする • 一通り終わったら、役割を交代 • 終わったら、メモを見せ合って、双方が話した内容を理解した か話し合う 8
- 9. 現実世界のモデル化 現実世界に散らばる 様々な何か 抽出 1対1対応 • “現実世界に散らばる様々な何か”は、それぞれを区別できる • 現実世界とモデルの世界は双方向で1対1対応をなす • “現実世界の何か”に相当する“もの”が“モデル世界”にただ一つだけある • “モデル世界”の“もの”に相当する“何か”が、“現実世界”にただ一つだけある 現実世界 モデル化された世界 9
- 10. “現実世界の何か” ‐“概念インスタンス” 抽出 1対1対応 現実世界 モデル化された世界 家 部屋 電気スタンド トラック ビル 倉庫 店舗売上 太陽光発電パネル EV 契約 収穫 変電所 ソファー • “現実世界に散らばる様々な何か”の一つ目は、それぞれを区別できる“もの” • 実際に触って確認できる出来ないにかかわらず、存在が認識されるもの • この“もの”の事を“概念インスタンス”と呼ぶ 現実世界に散らばる 様々な何か 10
- 11. “現実世界の何か” ‐“値を持った特徴値”と“データ型” 抽出 1対1対応 • “現実世界に散らばる様々な何か”は、それぞれを区別できる“値を持った特徴値” • “値を持った特徴値”は、どれかただ一つだけの“概念インスタンス”に紐づく • “値を持った特徴値”は現実世界において、各時点で確定した値を持っている • “値”は、現実世界の文脈に則った単位や意味に従い、それを“データ型”と呼ぶ 現実世界 モデル化された世界 山形県山形市…:住所 21.7℃：温度 (36.70,140.24)：位置 3人：稼働人数 東京都港区港南…:住所 良:作柄 3.1kw/h:発電量 24.5km/h：速さ 120万円：売上 12000 Lux：明るさ 現実世界に散らばる 様々な何か 11
- 12. “現実世界の何か” ‐“リンク” 抽出 1対1対応 • “現実世界に散らばる様々な何か”は、対象世界の意味に基づいて関係を持っている • “対象世界の関係”を、2つの“概念インスタンス”の間に張られた“リンク”と呼ぶ • 2つの“概念インスタンス”の組の間に、現実世界において意味の異なる複数の “リンク”が存在する場合もある 現実世界 モデル化された世界 家と部屋の位置関係 トラックの目的地 賃貸契約と契約者 トラックの配送ルート 現実世界に散らばる 様々な何か 12
- 13. “現実世界の何か” ‐“事象” 抽出 1対1対応 • “現実世界に散らばる様々な何か”は、任意の時点で発生する“出来事”として識別される • 現実世界の“出来事”は、“きっかけ”と、それを起点として“変化”が生じる • モデルの世界では、“きっかけ”を“事象（Event）”と呼ぶ • 現実世界の変化は、概念インスタンス、値、リンクの変化で表される • 一連の変化の流れを、“アクション”と呼ぶ 現実世界 モデル化された世界 積込み完了 アクシデント発生 コネクタ接続 収穫完了 現実世界に散らばる 様々な何か 13
- 14. まとめ ‐現実世界のモデル 抽出 1対1対応 現実世界 モデル化された世界 現実世界に散らばる 様々な何か • 概念インスタンス • 値を持った特徴値 • データ型 • リンク • 事象 14
- 17. • 店舗ごとに異なる • 時間と共に変化する • 店舗ごとのモデル図作成 • 変化に追従したモデル図変更 商品販売を例に 購入 購入 購入 購入 購入 現実の対象世界 藤間幸三郎：顧客名 tom@xxx.yy：連絡用メールアドレス 東京都…：住所 03-…：電話番号 桐野瞳子：顧客名 toko@xxx.yy：連絡用メールアドレス 東京都…：住所 03-…：電話番号 HB鉛筆：商品名 茜色：色 10円：価格 ・・・ H鉛筆：商品名 鉛丹：色 12円：価格 ・・・ A4ノート：商品名 瓶覗：色 120円：価格 ・・・ B5ノート：商品名 浅葱：色 110円：価格 ・・・ 5ミリ方眼紙ノート：商品名 露草色：色 110円：価格 ・・・ A4バインダー：商品名 浅紫：色 210円：価格 ・・・ （概念インスタンス図の例） 文具ショップABC：店舗名 モデル化された世界 1対1対応 17
- 18. “1対1”のモデルから“分類のモデル”へ 現実世界と1対1対応のモデル 分類のモデル • 概念インスタンス群 • 値を持った特徴値群 • リンク群 • データ型群 • 事象（Event Instance）群 • 概念クラス • 同じ意味でかつ、同じ特徴値の組を持つものに分類 • 関係（Relationship） • 同じ意味でかつ、両端が同じ概念クラスの組を 紐づけるものに分類 • データ型 • 同じ意味を持つものに分類 • 事象（Event） • 同じ意味、同じデータの組を伴うものに分類 存在の在り様を規定 • 現実世界の様々な状況を包含 • 時間経過の変化の影響なし ⇒ 安定したモデル 概念クラス、関係（Relationship）、データ型で記述されたモデル = “概念情報モデル” 18
- 19. 概念情報モデルの例 顧客 • 顧客ID{I} • 顧客名 • 住所 • 連絡用メールアドレス • 店舗ID{R1} 店舗 • 店舗ID{I} • 店舗名 R1 1 * 会員 登録されている 商品 • 商品ID{I} • 商品名 • 商品コード • 色 • 単価 • 店舗ID{R2} R2 1 1..* 売り場 販売対象 0..1 R3 * 購入対象 購入者 購入 • 顧客ID{I,R3} • 商品ID{I,R3} • 購入日時 （概念情報モデル図の例） 世界の在り様を記述 現実の対象世界 モデル化された概念インスタンス・リンクの世界 モデル化された世界を規定するスキーマの世界 19
- 20. 理解を深めるために • Art of Conceptual Modeling • ０. 概念モデリングとは • SaG of Modeling for Real World • 3. モデリングとは ～ 現象学からの考察 • 5. 概念モデリングに関する圏論的考察 ‐ 議論のとっかかりとして https://note.com/kae_made 20
- 22. 概念クラスの書き方 クラス名 特性値名:データ型名 ・・・ 特徴値のリスト 概念クラス名 特徴値名:データ型名 特徴値の名前 特徴値のデータ型名 概念クラス UML表記 クラス名 特性値名:データ型名 ・・・ 属性のパートに特徴値を記載 簡易表記 クラス名 特性値名 ・・・ クラス名 データ型なし クラス名のみ ※ 大規模なクラス図で使用 問題領域名 モデル化対象の問題領域の名前 ※ クラス名は同一の問題領域内で重複しないこと ※ 特徴値名は同一のクラス内で重複しないこと 概念クラスとは • 現実世界に存在する識別可能なモノ達の、その現実世界の文脈において同じ意味を持つ分類 22
- 23. 部屋 部屋 部屋 特徴値：Property 特徴値とは • 現実世界に存在する値を保持 • 同じ概念クラスを雛形とする概念インスタンスは、同じ特徴値の組を持つ • 逆に言えば、同じ特徴値の組を持つかどうかが、概念インスタンス群から概念クラスを分類・抽出する指針になる • 概念インスタンスは、その雛形となっている概念クラスに紐づけられた特徴値、全ての値が確定している • 部屋名 • 温度 • 明るさ • 湿度 • CO2濃度 • 使用電力量 現実世界のそれぞれの部屋に 対応する概念インスタンス 部屋 部屋名:文字列{I} 温度:摂氏 明るさ:ルックス 湿度:百分率 CO2濃度:ppm 使用電力量:ワット 分類としての概念クラス • トラックID • 位置 • 速度 • 積載量 トラック トラックID:文字列{I} 位置:位置情報 速度:速度ベクトル 積載量:kg • 特徴値の値は“データ型”で規定される • 特徴値は以下の二種類に分類できる • 概念インスタンスを区別する • 概念インスタンスの特徴を記述する 23
- 24. データ型 • 基本データ型 • 文字列 • 数値 • 自然数、整数、実数 • 時刻 • 列挙型 • 値の範囲があらかじめ定まった列挙子で規定される • 複合型 • 基本データ型、列挙型、複合型のデータ要素から定義 ※ データ型は上の種別を基本とし、モデル化対象世界の文脈に則った意味づけがなされ、 単位やフォーマット等を付与して定義 24
- 25. データ型の例 温度 － 単位：℃、数値：Real、値域：-273より大きい実数 電波強度 － 単位：dB、数値：Real、値域：-100以上０以下 金額 － 単位：円、数値：整数、値域：０以上 携帯電話番号 － ^0[789]0-d{4}-d{4}$ 商品コード － ^[a-z]4-d{6}$ 装置の状態 ::= 電源OFF | 初期化中 | 稼働中 | 故障中 加速度： 単位：1/(9.8m/s2)、数値：Real、精度：± 0.01% “acceleration”:{“x”:0.01401,”y”:-0.0712,”z”:0.99128} 位置 － 単位：度、数値：Real 緯度 － 値域：-90～90 経度 － 値域：-180～180 “location”:{“latitude”:34.939351,”longitude”:139.823074} モデル化対象のドメインにおいて、特徴値が取りうる値を規定する 25
- 27. 関係：Relationship A B Aの多重度 Bの多重度 Aの意味 Bの意味 概念クラス 関係名 概念クラス 関係は、２つのクラスを つなぐ線で表現する “A”と “B”、二つの概念クラス間の“関係”を表記 Aの多重度 Bの多重度 Aの意味 Bの意味 関係名 問題領域内で重複しない名前 Aのインスタンス から見た多重度 Aのインスタンスから見 た、Bの意味を表す簡潔 なテキスト Bのインスタンスから見 た、Aの意味を表す簡潔 なテキスト Bのインスタンス から見た多重度 ※ 関係名、意味、多重度の線に対する上下の位置は見やすい位置でよい ※ 大規模な図の場合は、関係名、意味は省略してよい 関係とは • 現実世界に存在するモノ（概念インスタンスに対応）の間に意味を持って関連するリンクの分類 • 二つの概念インスタンスの雛形の概念クラスの間に定義 • リンクにおいて、双方から見た意味を、紐づける • 分類後の、概念インスタンス間のリンクの多重度を両端に紐づける • 便宜上、形式的な名前でも構わないので、それぞれの関係を区別するために名前を付ける 27
- 29. 例 ドメイン：人事管理 部署 部署ID{I} 名前 コストセンターコード ミッション 名前{I} ミッションステートメント 社員 社員番号{I} 名前 等級 … ジョブデスクリプション 名前{I} デスクリプション 任用 R_HR_1 0..1 1..* 上位 下位 * 0..1 1 マネージャー 1..* 1 1 1 1..* 遂行に必要なジョブ 1 1..* 規定 所属 R_HR_2 R_HR_3 R_HR_4 R_HR_5 R_HR_6 工場 工場ID{I} 工場名 所在地 消費電力{M} 生産ライン 生産ラインID{I} 消費電力{M} 稼働状態 R_FL1 1 * 製品 製品ID{I} 装置 装置ID{I} 消費電力{M} 稼働状態 温度 危険上限温度 1 1 0..1 1 1..* 1..* * 0..1 0..1 0..1 0..1 前の工程 後の工程 仕掛り品 加工中 生産製品 設置場所 設置場所 開始装置 R_LE1 R_LE2 R_EO1 R_EP1 R_LP1 オーダー仕様 製造ステップ{I} 装置コマンド{I} 1 1..* 1 1 製造指示仕様 製造指示仕様 R_LOS1 R_POS1 インシデント インシデントID{I} 発生日 状態 担当者 担当者ID{I} 名前 状態 0..1 0..1 1 R_EI1 R_IR1 ドメイン：装置管理 29
- 30. 同じ概念クラス間に定義された関係：Relationship Element 前にある 後ろにある 0..1 0..1 E0 S E1 E2 En S1 S2 p s p s p s 上のモデルを雛形にしたインスタンスの例 一つのクラスに定義された関係の例 両端の意味、多重度はモデ ル化対象によって異なる この例では、最初の要素には、その“前にある”インスタンスは 存在しないので、“前にある”側の多重度が“0..1”になっており、 最後の要素には、その“後ろにある”インスタンスは存在しない ので、“後ろにある”側の多重度も”0..1“になっている。 多重度を意図的に“1”や、“*”、“1..*”に変えると、存在可能な インスタンスとインスタンス間の関係が許されるか、また、 その変更によって両端の意味が適切なままか、不適切になる かを、確認してみよう。 30
- 32. 関連クラス A B Aの多重度 Bの多重度 Aの意味 Bの意味 概念クラス 関係名 概念クラス 関係を表す線と 関連クラスを、 点線でつなぐ C 特徴値 ・・・ 関連クラス ※ 関連クラスも概念クラスであり、特徴値がある場合はリスト表記してよい 32
- 33. 関連クラスの例 概念インスタンスの一シーン 顧客A 商品001 注文 A001 顧客B 商品002 商品003 顧客C 顧客Aは、商品001、商品002を注文している 顧客Cは、商品002を注文している 顧客Bは、何も注文していない 商品003は、誰からも注文されていない 概念クラス 顧客 商品 注文 発注者 * * 購入予約 概念クラスと関係で定義した制約に従って… 33
- 35. 概念インスタンスを表形式で表す 注文 *注文ID 個数 金額 顧客ID(R) 商品コード(R) 商品 *商品コード 商品名 在庫 単価 顧客 *顧客ID 顧客名 住所 発注者 * * 購入予約 顧客ID 顧客名 住所 C003 概 念 XXX C172 円 帝一 YYY C026 蔵巣 抽 ZZZ 商品 コード 商品名 在庫 P031 ペンシル 1000 N008 手帳 752 L012 ルーズ リーフ 108 単価 700 3500 1400 ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ 顧客ID C003 C003 C026 ・・・ 商品 コード P031 N008 L012 ・・・ 注文ID 個数 金額 C003P0 31-001 2 1400 C003N0 08-005 1 3500 C026L01 2-052 50 63000 ・・・ ・・・ ・・・ 表で示すとインスタンス間のリンクが見えなく なるので、関係を示す特徴値が必要 概念クラスの名前→表の名前 特徴値→表のカラム名 これらの値がどこから来るのか、どう やって現実世界と同期するのかについて、 考える必要はない 35
- 36. 特徴値（Property）の種別 特徴値は、以下の四種類に分類できる • 識別子特徴値 • それぞれの概念インスタンスを識別する値 • 同じ概念クラスの概念インスタンスは全て異なる値を持たなければならない • ひとつの特徴値、または、複数の特徴値の組で表される • 記述的特徴値 • 他の特徴値と併せて識別子になる場合もある • 関係を保持する特徴値 • 概念インスタンス間のリンクを保持する • 相手の概念クラスの識別子特徴値と同じデータ型を持つ • 関係の多重度によっては、NULL になる場合もある • 計算可能な特徴値 • 他の特徴値やリンクから計算で算出可能な値 36
- 37. 特徴値の記法と例 クラス名 識別子特徴値名{I} ・・・ 関係特徴値名{R} ・・・ 計算可能特徴値名{M} 問題領域において、概念クラスのインス タンスで必ず別の値を持つ場合は、後ろ に“{I}”をつける 識別を意味する特徴値、または、特徴値 の組が複数ある場合、I1、I2 の様に番号 を付与する 関係を持つ他の概念クラスの特徴値と同 じ値を持つ場合は、後ろに“{R}”をつける “R”は関係の名前を入れる 概念モデルの他の要素から計算可能な場 合は、後ろに“{M}”をつける 製造装置 Device Id{I} 担当工程{R1} 仕掛り製品数{M} 工程 工程名{I} 生産中の製品 Product Id{I} 現在の工程{R3} 製造装置{R2} 1 1 0..1 0..1 * * R1:割当て 現在の工程 割当てられ た機器 担当工程 現在の工程 仕掛り製品 ※Device Id は製造装置を特定する一位の値なので重複は不可 ※“製造装置.担当工程”は、“割当て”という名前で関係づけられた“工程”の “工程名”と同じ値でなければならない ※“製造装置.仕掛り製品数”は、 “生産中の製品”クラスのインスタンス群の 中で、関係の“製造中”で関係づけられたインスタンスの数と一致してい なければならない R2:製造中 R3:生産中 記法 例 37
- 38. Super Sub 関係 P C1 C2 P1 p2 c11 c12 c21 c22 拡張される側に△をつけて、 拡張するクラスを線でつなぐ {complete, disjoint} ※拡張した側のクラスの各インスタンスに対応する拡張された側のクラスのインスタンスが必ず一つだけ存在 する、かつ、拡張された側のクラスの各インスタンスに対応する、拡張したクラスのうちのどれかのクラス のインスタンスが必ず一つだけ存在する。 ※拡張するクラスの数は、扱っている問題領域において意味的に正しければ、2つ以上あっても構わない ※{complete, disjoint}は図の表記上、省略しても構わないが、モデリングにおいては、{complete, disjoint}に なるように概念クラスを定義すること Pの集合 C1の集合 C2の集合 概念インスタンスの集合をベン図で描くと 38
- 39. Super Sub 関係による概念の詳細化 Element 前にある 後ろにある 0..1 0..1 E0 S E1 E2 En S1 S2 p s p s p s Element First {complete, disjoint} Middle Last Predecessor Successor 1 1 {complete, disjoint} {complete, disjoint} 一列の並びの詳細なモデル precedes succeeds 一列の並びの単純なモデル 関係の多重度が、“0..1”から“1”に変っている 39
- 40. 参照特徴値の定義場所 0..1 0..1 0..1 1 0..1 * 0..1 1..* 1 0..1 1 1 1 * 1 1..* どちらか一方に定義 どちらでも可 ☆：参照特徴値を定義する側 ☆ ☆ ☆ ☆ どちらか一方に定義 どちらでも可 ☆ ☆ * 0..1 * 1 1..* 0..1 1..* 1 ☆ ☆ ☆ ☆ ☆ ☆ ☆ ☆ ☆ 多重度に関係なく 関係クラスに定義 ☆ ☆ 40
- 41. Super Sub Relationship は継承・拡張ではない 41 Super Sub Relationship は、ある特定の概念における分類を示すことに注意 Relationship の線は、注意深く定義する事 Super Sub Relationship の Super 側のクラスのインスタンスは、単体で存在することはできない A B C P D E R1 R２ R3 BとCは、ある一つの観点（R1） において、A を分類、分割している • A のインスタンスは、必ず B か C、 どちらかのインスタンスと R1 のリ ンクを持つ DとE は、それぞれ別の観点（R2、R3）において、 A を別系統で、分類、分割している • P のインスタンスは、必ず、D のインスタンスが R2 でリンクを持ち、かつ、E のインスタンスと R3 でリンクを持つ ※ Super Sub Relationship は、分類の世界の概念情報モデルを不安定にするので、安易に定義せ ず、よくよく吟味してから定義する事
- 42. 演習３. • お題 • 水力発電所、火力発電所、風力発電所、太陽光発電所を Super Sub Relationship を使って、概念情報モデルを描きなさい • 水力発電所、火力発電所、風力発電所、太陽光発電所を Super Sub Relationship を使わずに、二項関係の概念情報モデルを描きなさい • 二項関係の概念情報モデルで定義した Relationship の多重度を吟味し なさい 42
- 43. 概念情報モデル ‐ まとめ 現実世界 • 概念インスタンスと特徴値の値 • 概念インスタンス間のリンク • データ型 それぞれの“モノ” それぞれの“役割” それぞれの“単位” 1対1対応 概念情報モデル • 概念クラスと特徴値 • 関係：Relationship • データ型 モデル化された世界 存在を規定するスキーマ 存在を規定するスキーマ 43 ※ 安定したモデルであること
- 44. 概念情報モデルのテスト 1. 関連ドキュメントから、3つ程度のシーンを想定する 2. シーンに基づいて概略の図を描く 3. 図に描かれたモノや役割を、概念情報モデルの定義に従って、概念インスタンス、特徴値の値、 リンクに当てはめる 4. 概念クラス、特徴値、関係について、以下の条件が全て満たされれば OK • 該当する概念クラス、特徴値、関係が全てある • 全ての概念インスタンスについて、特徴値が確定する • 関係の多重度が満たされている 5. NG の場合は、想定した全てのシーンに対するテストを行った後、まとめてモデルを修正する 1. 両端の多重度を意図的に変えてみる 2. 変えた結果、意味がどう変わるかを検討する 3. ドメインにおいて、見落とし、新たな解釈等の発見があれば、モデルを修正する 形式テスト 意味論テスト 44
- 45. 演習４. • お題 • ビルの所有、賃貸契約の管理 • 以下の手順で概念情報モデルを作成してみよう • ビル、所有者、契約者等を複数含むシーンを図に描く • 概念情報インスタンス、特徴値、リンクを抽出する • 抽出したものから概念クラス、関係を分類抽出する • 概念クラス、関係を図に描き、関係の両端の意味、多重度を決める • 以下の手順で概念情報モデルをチェックしよう • ひとつ関係を選び、その両端の多重度を変えてみて、意味がどう変わ るかディスカッションを行う • 最初に書いたシーンに登場するものが、全て、概念情報モデルに書か れた、条件を満たすかチェックする 45
- 46. 概念情報モデル作成のコツ • インスタンスレベルではなくクラス（分類）で考える • 関係 : Relationship をおろそかにしない • 意味を双方向から吟味する • 多重度の“0”を消す • モデルパターンの活用 • Art of Conceptual Modeling – 概念モデリング ～ 虎の巻 • 常に図をシンプルに保つ • ドメインを意識する • 問題を分割する 46
- 47. 理解を深めるために • Art of Conceptual Modeling • 1. 概念情報モデル https://note.com/kae_made 47
- 49. ドメイン ドメインとは • モデル化する意図や目的・観点から見た対象世界・領域 • 言葉や図による記述は、ドメインがあって、初めてその文脈における意味を成す • 全く同じ現実世界を対象にしても、設定しているドメインが異なれば、全く異なる概念モデルになる • 現実世界は、複数の意図や目的・観点から切り取られた複数のドメインで構成される • ドメインはそれぞれ独立していて、無関係 ビジネスシステム開発において • 「なぜシステム化したいのか」という目的を同じくする、システム化したいビジネス対象に含まれる 主題や観点などの集まり • ビジネスを支えるコストセンター業務 • ミドルウェア、プログラミング言語、実装プラットフォーム等 • コンピュータプラットフォーム上で動く実システムは、複数のドメインの組合せで構築される 49
- 52. ドメインを定義する • モデル作成開始時点では、ドメインは曖昧模糊としている • だからこそ、モデル作成を通じて、明確にし理解し、共有可能にする • 初期は、簡潔なドメイン名と、概要を説明する数行のステートメントを記述 • 最終的には… • ドメインの厳密な定義 ＝ “概念モデル”による記述 • 概念モデルを構成する要素は、モデル化対象のドメインにおいてのみ、意味が成り立 つ • 意味がなりたつとは、概念モデルをスキーマとして、概念インスタンスとリンクを構成し た場合、それが、ドメインにおいて対応する何かが存在する（命題が有意味でかつ真） • ドメイン分割 • 概念モデルは、ドメイン毎に作成する • 異なるドメインの要素は、作成中の概念モデルから排除し、別のドメインの 概念モデルとして作成する • 判断基準 • ドメインの論理空間において • その概念クラスは意味をなすか • その特徴値は唯一の概念クラスに所属するか • その Relationship は、唯二つだけの概念クラスだけにおいて意味をなすか • そのイベントは、唯一つの概念クラスが受信するか 52
- 53. ドメインの操作（Operation または Function） • 概念インスタンスの操作 • 概念インスタンスの作成 • 概念インスタンスの削除 • リンクの操作 • 概念インスタンス間のリンクの作成 • 概念インスタンス間のリンクの削除 • 特徴値の操作 • 概念インスタンスの特徴値の更新 • 概念インスタンスの特徴値の参照 • 算術計算 • 操作引数、特徴値、一時変数等を元にした算術計算 • 条件判定 • 論理演算による True、False の判定 • データ変換 ※ 概念クラスの操作（Operation） • ドメインのコンテキスト上必要なデータ変換 • 事象の生成 • 概念インスタンスの状態機械に事象を送信する • クエリ • 概念クラスの任意の概念インスタンスを一つ、または 全て取り出す • リンクを辿る • 概念インスタンスを起点に、関係でつながっている概 念インスタンスを取り出す • 多重度が“0..1”または“1”の場合は、唯一つの概念インスタ ンスが取り出される • 多重度が、“*”または“1..*”の場合は、どれか一つ、または、 全て取り出す • 条件付きクエリ • 概念クラスの任意の概念インスタンスのうち、条件に 合致する概念インスタンスを一つ、または全て取り出 す • 条件付きでリンクを辿る • 概念インスタンスを起点に、多重度が、“*”または、 “1..*”の関係でつながっている概念インスタンスの内、 条件に合致する概念インスタンスを一つ、または全て 取り出す • ドメインの外側の仕組みからのデータ取得 53
- 54. 概念情報モデルを使う ITシステム上のストレージやデータベースなど 概念インスタンスの状態を保持 現実の世界 同期 概念情報モデル 存在条件を 規定 ビジネス上の 問いかけ操作 概念を抽出し モデル化 存在条件に 従って検索 概念情報モデルに対する、 ドメインオペレーションを介した操作 ドメインオペレーション： 概念情報モデルの定義に従った • 概念インスタンスの生成・削除 • 概念インスタンスの特徴値参照・更新 • Relationship のリンク・アンリンク • 概念インスタンスへのイベント送信 54
- 56. 概念情報モデルを元にしたストレージ設計 ～ その２ 概念情報モデル No SQL Database Customers:{ “顧客ID”:”xxxx”,”顧客名”:”yyyy”,”住所”:”zzzzzzz”}, ・・・ ・・・ Documents 操作ロジック 概念情報モデルで定義された制約を実装 利用ロジックに、状態更新、問合せの API を提供 Goods:{ “商品コード”:”abcd”,”商品名”:”xyz”,”在庫”:1028,”単価”:1200}, ・・・ ・・・ Orders:{ “注文ID”:”O365“,”個数”:10,”金額”:12000,顧客ID”:”xxxx”,”商品コード”:”abcd”}, ・・・ ・・・ 56
- 57. 概念情報モデルを元にしたストレージ設計 ～ その３ 概念情報モデル Relational Database customer goods order リレーショナルデータベースのAPI 利用ロジックに、状態更新、問合せの API を提供 制約を元に、テーブル、識別子、 外部参照等を定義 57
- 58. 概念情報モデルを元にしたストレージ設計 ～ その４ 概念情報モデル Azure Digital Twins Azure Digital Twins のAPI 利用ロジックに、状態更新、問合せの API を提供 Customer.json DTDL Order.json DTDL Goods.json DTDL Twin Model Twin Graph 58
- 61. 概念振舞モデル 振舞とは • ドメインにおいて、発生した事象（Event）に対し、ドメインの状態が変化する事 • ドメインの状態は、概念インスタンス群とそれぞれの概念インスタンス群の特徴値の値、及び、概念イン スタンス間のリンク群で表される • 状態変化は、概念インスタンスに紐づいた局所的な状態変化を起こすアクションの連なりによって行われ る。 • あるアクション内では、新たに事象（Event）が発生し、別のアクションに伝搬する 概念振舞モデルとは • 概念クラスに対する、状態遷移図で記述された状態モデル • 事象が発生すると、ある状態から別の状態への遷移が発生し、その状態に紐づいたアクションが起動し、 アクションが完了した時点で状態遷移が確定したものと考える • アクションは、データフローモデルで記述する • ある概念クラスの全ての概念インスタンスは、概念クラスの状態モデルに従って振舞う • 状態モデルを雛形にした、各概念インスタンスの振舞の事を、“状態機械（State Machine）”と呼ぶ • 状態機械は現実世界を反映したものなので、複数の状態機械は、同時並行的に、状態遷移を引き起こしア クションを行う、と考える 61
- 62. 概念振舞モデルの例 概念情報モデル PB052:装置の状態機械 PB037:装置の状態機械 PB021:装置の状態機械 F002:工場 インスタンスは、それぞれの“状態機械”を持つ PB021:装置 PB037:装置 PB052:装置 クラスのインスタンスのライフサイクルを規定する状態モデル S1 S2 S3 S4 E1 E2 E2 E3 E4 状態 事象 遷移 状態に紐づいたアクション 状態機械の現在の状態を示す 62
- 63. 概念モデル ‐ まとめ 現実世界（ドメイン） • 概念インスタンスと特徴値の値 • 事象と状態機械 • 概念インスタンス間のリンク • データ型 それぞれの“モノ” それぞれの“コト” それぞれの“役割” それぞれの“単位” 1対1対応 • 概念クラスと特徴値 • 関係：Relationship • 概念クラスの状態モデル • データ型 モデル化された世界 存在を規定するスキーマ 存在を規定するスキーマ 63
- 67. メタモデルから見た概念モデル 商品販売 R_GS_1 関係の凡例 Property Class Domain 商品販売 顧客 商品 注文 顧客ID 顧客名 住所 商品コード 商品名 在庫 単価 注文ID 個数 金額 String Data Type 顧客ID 顧客名 住所 商品コード 商品名 注文ID Numeric Data Type 個数 金額 Binary Relationship R_GS_1 One Side of Relationship R_GS_1顧客側 Other Side of Relationship R_GS_1商品側 “メタモデル”のインスタンスとリンクによる表現 R1 R2 R3 R15 R17 R18 R16 商品販売に限らず、全てのドメインの概念モデルが。 メタモデルの概念インスタンス、特徴値の値、リンク として扱う事が出来る 67
- 68. 概念モデリング用ツール • ホワイトボード • PowerPoint 等の図作成アプリ • 専用ツール：BridgePoint ※ 推奨 • xtUML community が管理する専用ツール • オープンソースで提供 ‐ https://xtuml.org 68 概念情報モデル 状態モデルとアクション記述 アクション記述言語 OAL サポート • 専用エディタ • モデルベリファイア • メタモデルベースのモデルデータ取出し
- 69. 参考）他のモデリング技法との比較 • 表記法 • UML • 概念モデルを図で記述する場合は、UML に従う • ER図 • 概念情報モデル図は、ER図の拡張にあたる • ER図には、概念振舞モデル図に相当するものがない • olog • 概念情報モデル図は、“クラス”と“インスタンス”を明確に区別 • OWL • 概念モデルをテキストで記述する場合は、OWL による記述も可能 • プロセス • Rational Unified Process • ドメイン分割という概念がない • モデル化の対象は、現実世界ではなく、ソフトウェア世界 69
- 70. 理解を深めるために • Art of Conceptual Modeling • 2. 概念情報モデルを使う • 3. 概念情報モデルの操作 • 4. 概念振舞モデル • 5. 概念モデルを IT システムに組み込む • 6. ドメインと IT システム構築 https://note.com/kae_made 70
- 71. 理解を深めるために • 概念モデリングチュートリアル集 • “商品販売”を例にした、概念モデルチュートリアル • 概念モデリングチュートリアル ～ ホテルのコインランドリー • ビジネスをモデル化する ～ BridgePoint を使ってみよう https://note.com/kae_made 71
- 72. お問い合わせは、mastar@kae-made.jp にご連絡ください Copyright 2023, all rights reserved by Knowledge & Experience 72