Conceptual Modeling Workshop Desing - 概念モデリングワークショップ 設計編
•Download as PPTX, PDF•
0 likes•6 views
概念モデリングで作成したモデルを使ってシステムを設計・実装する方法を学ぶ資料です。 ”Technique of Transformation (https://note.com/kae_made/m/md806463fb58a)" の基本を学びます。
Recommended
Recommended
More Related Content
Similar to Conceptual Modeling Workshop Desing - 概念モデリングワークショップ 設計編
Similar to Conceptual Modeling Workshop Desing - 概念モデリングワークショップ 設計編 (20)
More from Knowledge & Experience
More from Knowledge & Experience (20)
Recently uploaded
Recently uploaded (14)
Conceptual Modeling Workshop Desing - 概念モデリングワークショップ 設計編
- 1. 概念モデリング ワークショップ 設計編 Knowledge ＆ Experience 代表 太田 寛 https://www.kae-made.jp Twitter： @embedded_george 1 Date: 2023/12/8 Version: 1.2.0
- 2. 本資料について • 使い方 • 本資料は、“Art of Conceptual Modeling”のコンテンツを元に作成した集合教育向けの講師用 プレゼンテーションです • 概念モデリングワークショップ‐基礎編を実施後に開催します • ワークショップ実施の際 • 開催要領は、“基礎編”の“P2. 本資料について”を参照してください • 演習込みで2日間を目安 • 有償にて講師対応しますので、お気軽に 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 にご連絡ください。
- 4. アジェンダ • 振り返り • 設計・実装に関する基本事項 • ドメインの種別 • ドメイン間の対応付け • 変換による実装 • まとめ 4
- 7. 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 ↤ “対応付け” 7
- 8. 現実世界のモデル化 現実世界に散らばる 様々な何か 抽出 1対1対応 • “現実世界に散らばる様々な何か”は、それぞれを区別できる • 現実世界とモデルの世界は双方向で1対1対応をなす • “現実世界の何か”に相当する“もの”が“モデル世界”にただ一つだけある • “モデル世界”の“もの”に相当する“何か”が、“現実世界”にただ一つだけある 現実世界 モデル化された世界 8
- 9. 振り返り ‐概念モデル 現実世界（ドメイン） • 概念インスタンスと特徴値の値 • 事象と状態機械 • 概念インスタンス間のリンク • データ型 それぞれの“モノ” それぞれの“コト” それぞれの“役割” それぞれの“単位” 1対1対応 • 概念クラスと特徴値 • 関係：Relationship • 概念クラスの状態モデル • データ型 モデル化された世界 存在を規定するスキーマ 存在を規定するスキーマ 9
- 10. 概念振舞モデルの例 概念情報モデル PB052:装置の状態機械 PB037:装置の状態機械 PB021:装置の状態機械 F002:工場 インスタンスは、それぞれの“状態機械”を持つ PB021:装置 PB037:装置 PB052:装置 クラスのインスタンスのライフサイクルを規定する状態モデル S1 S2 S3 S4 E1 E2 E2 E3 E4 状態 事象 遷移 状態に紐づいたアクション 状態機械の現在の状態を示す 10
- 12. 基本的な考え方 ビジネスで求められる非機能要件 • 利用ユーザー増加傾向 • 管理機器数増加傾向 • 応答性能 • 運用コスト • 保守のしやすさ • セキュリティ要件 • アクセシビリティ • … 利用する実装技術・サービス 選択 ビジネス機能要件 アプリケーションドメインの概念モデル サービス ドメイン テレメ トリ GU I 3D Model AI 学習 AI 学習済み モデル配置 セキュリティ 認証 基盤 データ ベース メッセージ 配信 選択 対応付け 対応付け 対応付け 複数のドメインを組み合わせてシステムを構築する 概念モデル View Business Logic (Behavior Model) Conceptual Instance Repository 概念振舞モデル 他のシステム 現実の世界 振舞モデル 12
- 15. サービスドメイン サービス ドメイン アプリケーション ドメイン 商品管理 装置管理 自動送配電 テレメトリ GUI 3D Model AI 学習 AI 学習済 みモデル配 置 セキュリティ 認証基盤 データ ベース メッセージ 配信 開発対象のビジネス要件 に関わる対象世界をモデル化 システムとして実装する際に 必要なミドルウエア等 アプリケーションドメインに織り込み 組み立てることによってシステムを構築 アプリケーションドメインをシステム化するために必要な“ソフトウェア部品”群 15 ※ サービスドメインのモデル：一般的には API が概念モデルに相当する ※ 似たようなサービスが複数ベンダーから提供されている場合、概念モデルを作ると違いを明確化可能
- 16. サービス ドメイン インプリメンテーションドメイン アプリケーション ドメイン 商品管理 装置管理 自動送配電 利用する実装技術・サービス インプリメンテーション ドメイン テレメトリ GUI AI 学習 認証基盤 Azure Data Explorer HTML, CSS, Vue.js Tensorflow, Python Active Directory ※ 実装技術は、ITシステムに求められる、非機能要件、デファクト性、継続性などに合致するものを選択 HW、OS、実装言語等も インプリメンテーションドメイン にカテゴライズされる 16
- 17. ドメイン間の対応付け ～ What に How を割り当てる ～ 17
- 18. （参考）ドメインチャート 凡例 Domain A Domain B Domain A Domain B 実装時の 対応付け 矢印は、右の 対応付けと同義 ドメインチャート ドメインチャート（Domain Chart） 装置管理 IoT Device App IoT Hub Data Repository Digital Twins Messaging Behavior Functions SignalR C++ C# Linux システム構築時、使用するドメインと、 ドメイン間の対応を示す図 • ドメイン、及び、ドメイン間の関係 • 依存先ドメインへの非機能要件の記述 18
- 20. 概念情報モデルを元にしたストレージ設計 ～ その２ 概念情報モデル No SQL Database Customers:{ “顧客ID”:”xxxx”,”顧客名”:”yyyy”,”住所”:”zzzzzzz”}, ・・・ ・・・ Documents 操作ロジック 概念情報モデルで定義された制約を実装 利用ロジックに、状態更新、問合せの API を提供 Goods:{ “商品コード”:”abcd”,”商品名”:”xyz”,”在庫”:1028,”単価”:1200}, ・・・ ・・・ Orders:{ “注文ID”:”O365“,”個数”:10,”金額”:12000,顧客ID”:”xxxx”,”商品コード”:”abcd”}, ・・・ ・・・ 20
- 21. 概念情報モデルを元にしたストレージ設計 ～ その３ 概念情報モデル Relational Database customer goods order リレーショナルデータベースのAPI 利用ロジックに、状態更新、問合せの API を提供 制約を元に、テーブル、識別子、 外部参照等を定義 21
- 22. 概念情報モデルを元にしたストレージ設計 ～ その４ 概念情報モデル Azure Digital Twins Azure Digital Twins のAPI 利用ロジックに、状態更新、問合せの API を提供 Customer.json DTDL Order.json DTDL Goods.json DTDL Twin Model Twin Graph 22
- 23. ドメイン間の対応例 ～ 時系列データの扱い ドメイン：テレメトリ ドメイン：装置管理 Time Series Instance *TSI_ID R_TSI_1 1 * Time Series Data Timestamp:DateTime Value:ANY 装置管理.装置.消費電力:Time Series Instance 装置管理.装置.温度:Time Series Instance (2022/2/14 12:34:09,450W):Time Series Data (2022/2/14 12:34:10,350W):Time Series Data (2022/2/14 12:34:09,120℃):Time Series Data (2022/2/14 12:34:10,121℃):Time Series Data アプリケーションドメインの特徴値を “Time Series Instance”のインスタンスと して保持する ドメイン：装置管理 23
- 24. ドメイン間の対応 部屋の温度 24.3℃ といった値は… • 参照する度に確定していると考える • その値はどこから来るかについては、 対象ドメインの範疇ではないと考える “利用者の快適さを管理する”というドメインにおいて サービスドメイン ニッケル・銅 熱電対センサー 計測用マイクロコンピューター 温度計測 計測 一定間隔で“計測”事象発生 “IoT機器” “ネットワーク通信” 精度、分解能等の要件 通信量、対応端末数等の要件 実現手段 実現手段 24
- 25. ドメイン間の対応例 ～ 生産部門 × 営業部門 ドメイン：商品販売 ドメイン：装置管理 クラスの各インスタンスは1：1で対応付けられる？ ※文末に“？”をつけているのは、それぞれ、全く異なる問題領域を主題とした概念情報モデルであるので、 数える単位が異なっているかもしれないから ※実際の開発ではきちんとした精査が必要 25
- 26. ドメイン間の対応例 ～ 生産部門 × 人事部門 ドメイン：人事 ドメイン：装置管理 クラスの各インスタンスは1：1で対応付けられる？ ※ Identity の同一性を基にした対応付け 26
- 27. メタモデル メタモデル 概念情報モデルによる、ドメイン間対応の記述 • メタモデルを使った対応づけモデル 27 ドメイン：装置管理 ドメイン：人事 ※便宜上、メタモデルをそれぞれ二つ描いているが、同一のモデルである ※ Any Class of … は、メタモデルで定義された任意のクラス ※ 対応づけの概念情報モデルは対応の仕方によって変わる ～ are conceptual instances of ～ ～ are conceptual instances of ～ Any Class of Left Any Class of Right Mapping Class 対応づけの概念情報モデル
- 31. メタモデルを使った設計 ビジネスで求められる非機能要件 • 利用ユーザー増加傾向 • 管理機器数増加傾向 • 応答性能 • 運用コスト • 保守のしやすさ • セキュリティ要件 • アクセシビリティ • … 利用する実装技術・サービス 選択 ビジネス機能要件 アプリケーションドメインの概念モデル サービス ドメイン テレメ トリ GU I 3D Model AI 学習 AI 学習済み モデル配置 セキュリティ 認証 基盤 データ ベース メッセージ 配信 選択 対応付け 対応付け 対応付け メタモデル 1. “対応付け”を“ルール化” 2. “ルール化”は“メタモデル”で行う 3. “実装”は 1. “各概念モデル”を“メタモデル”に基いて取得 2. “各要素”に“ルール”を適用し、実装に“変換” 31
- 32. 変換による実装 • メタモデルを使った設計 • 変換ルールは、概念モデルのメタモデルに対して行うので、概念モデルで記述された全て のビジネスアプリケーションドメインに対して適用可能 • 記述された概念モデル、変換ルールをデジタル化し、概念モデルの読み込み、変換の過程 をプログラム化すれば、実装工程は自動化が可能 • 一般的な設計・実装との対応付け • アーキテクチャ ⇔ ドメインチャート • アプリケーションの仕様書⇔アプリケーションドメインの概念モデル • 設計書 ⇔ 変換ルール一式 • コーディング ⇔ モデルからコードへの変換 ※ 生成コードは、選択した実装プラットフォームに特化したソフトウェアフレームワーク の可変部のコードに相当するのが一般的 ※ ソフトウェアフレームワークの設計・実装については、https://note.com/kae_made の “Essence of Software Design”を参照のこと 32
- 33. 例）C# による概念クラスの実装例 interface ICustomer { string CustomerId { get; set; } string CustomerName { get; set; } string Address { get; set; } } class Customer : ICustomer { static public ICustomer Create(…) {…} … static public List<ICustomer> Select() {…} static public List<IOrder> SelectByPreOrder() {…} … public string CustomerId {…} … 設計（変換）ルール： • ドメインのモデルリポジトリから… • 概念クラスを一つ取り出し、interface を宣言 • 概念クラスの特徴値を全て取り出し、interface の property とし て宣言 • 概念クラスを一つ取り出し、生成した interface をリアライズする class を宣言 • instance 生成用 method 定義 • instance 全てを取り出す method 定義 • 関係を元に、つながった先の instance を全て取り出す method 定義 • 特徴値の property を実装 • … メタモデル ドメインの“概念情報モデル” 33
- 34. 参考）BridgePoint で作成した概念モデルの活用 34 DomainMode.xtuml MetaModelGenerator xtumlmc_schema.sql Model Repository Domain Model 入れ物を 作る 中身を作る CIMofCIM 変換による 自動生成 Meta Model Repository Meta Model BridgePointから • 概念情報モデル • 状態モデル • アクション • … C#ライブラリ https://github.com/kae-made/xtuml-ooa-of-ooa-library C# App Generator DTDL Generator BridgePoint が提供するメタモデル定義
- 35. 参考）Excel で記述した概念モデルの活用 35 domain datatypes relationships Class A Class B Class definition A Descriptions… Relationships Properties… 概念情報モデルのメタモデルをスキーマにしたExcelファイルでモデルを定義 変換ルール VSTO＋T4などで実装 所望の コンテンツ 所望の コンテンツ 所望の コンテンツ
- 36. まとめ • 概念モデリングを用いた設計 • 複数のドメインを組み合わせてシス テムの実装を構築 • What と How の分離 Application ＝ What Service・Implementation＝How • メタモデルを使った設計 • アプリケーションの詳細に非依存 • 設計を変換ルールとして記述 • 得られるメリット • 概念モデルにじっくり取り組める • 実装技術の変化に追従可能 • ベンダーロックインの防止 • 実装アーキテクチャの統一 • 仕様決めと設計を同時並行化 • 概念モデルのスキルアップ • 正確な見積 36
- 37. 理解を深めるために • Technique of Transformation • Art of Auto Software Development Deliverables Generation • BridgePoint で作成した概念モデルから DTDL 定義を自動生成する • Bridge Point で作成した概念モデルを In Memory で動作する C# アプリケーションライブラリに変換する https://note.com/kae_made 37
- 38. お問い合わせは、mastar@kae-made.jp にご連絡ください Copyright 2023, all rights reserved by Knowledge & Experience 38
Editor's Notes
- 一般的には多人数でコトに当たるであろうから、関係者という言い方をしているが、一人でやる場合でも、時間が経てば、前に自分がどんな理解をしたか忘れてしまう。未来の自分も含めて関係者と言っている
- リアルタイム系の制御ソフトウェア開発についても、制御ソフトウェアのモデル化をするのではなく、リアルタイムの制御対象そのものをモデル化する事が重要
- 詳細はPart2で ここでは、状態モデルは概念クラスに対して定義する事、概念インスタンスは、状態モデルに従ってそれぞれの状態機械を持って振舞う事、アクションが実行されることが知っていればよい
- 概念モデルをコード化した時、初期状態を設定するコードが必要
- 特に必須の図ではない。 必要に応じて書けば良い
- 変換ルールとは何ですと？ で、メタモデルの話に移る
- 仕様、設計、実装全てがデジタル化されるので、ある意味、ソフトウェア開発のデジタルトランスフォーメーションと言っても良い