概念モデリングによるビジネスの見える化とシステム開発のデジタルトランスフォーメーション.pptx

1. 概念モデリングによる “ビジネスの見える化”と、システム開発の “デジタルトランスフォーメーション” Knowledge ＆ Experience 代表太田寛 https://www.kae-made.jp Twitter： @embedded_george

2. アジェンダ～ 2022/12/6 • あらためて、自己紹介 • 前半 • 概念モデリングによる“ビジネスの見える化” • 後半 • システム開発の“デジタルトランスフォーメーション”

3. 自己紹介と事業紹介

4. 自己紹介 • 1989年3月東北大学大学院物理学専攻修士課程修了 • 実験物理屋さんでした。実験用の装置・計測システム開発。 • ～2006年8月富士ゼロックス • ネットワークプリンター、FAX、複合機の制御ソフトウェア開発 • 次世代製品アーキテクチャ設計 • Shlaer-Mellor法（現 xtUML）によるモデル駆動型開発や CMM を活用した、大規模組込みソフトウェア開発プロセス改善・推進 • 手法提唱者の Steve Mellor 氏（現 IIC Executive CTO）をはじめとする、xtUML.org メンバーと現在も協業中 • 第一回 UMLロボコン（現 ETロボコン）モデル部門最優勝賞受賞 • ～2022年2月マイクロソフト • 技術系エバンジェリストとして • 技術者への、組込み機器、PC・スマホアプリ、Web、クラウドに関する普及啓発活動。講演、セミナー、ハンズオン等多数開催、多数のチュートリアル、サンプル作成・公開 • IoT あるじゃん、Smart Japan Alliance 立ち上げメンバー、その他様々な技術者コミュニティに寄与 • お客様の実プロジェクト導入支援 • 2010年以降、200件以上のIoT、Digital Twins、AI のアーキテクチャ設計・導入支援 • 過去の経緯も含め、Azure 系 IoT 技術・サービスに国内外で最も詳しい技術者の一人 • 支援に当たり、Shlaer-Mellor 法を応用し、概念モデリングを試行 • 2022年3月 Knowledge ＆ Experience始動代表：太田寛 E-Mail: master@kae-made.jp Twitter @embedded_george LinkedIn @hiroshi-ota-009

5. https://www.kae-made.jp

6. https://note.com/kae_made 一部のチュートリアルは信州大学の授業で採用

7. https://note.com/kae_made/m/m5f5f32fee80b Azure IoT ・Digital Twins を使いこなすための、濃く超マニアックな正統派技術解説サンプルコードは Github から公開中 https://github.com/kae-made

8. 概念モデリングによる “ビジネスの見える化” ～ 1992年からの知識と体験を元に～

9. “ビジネスの見える化”とは • リアルなデータに基づいた経営判断が重要 • データを収集・活用してビジネスを継続・発展させるには、そのビジネスに適した IT システムが必要 • データは、ビジネスで扱うモノや人、役割、出来事、事柄から生まれる • ビジネスに関わる人それぞれの脳内で描いているビジネス像はバラバラ • 全員がビジネス像を理解・共有し、適切な IT システムの構築には、数学的な原理に則った、論理的な記法による“ビジネスの記述”が必要 “ビジネスの見える化” ＝ “フォーマルなモデル作成”

10. “概念モデリング（Conceptual Modeling）”とは～私の造語です • 1990年代に提唱され確立された Shlaer-Mellor 法がベース • 現在は、xtUML：eXecutable and Translatable UML と呼びます • https://xtuml.org • オブジェクト指向分析、変換による実装、ドメイン分割 • 30年以上に渡る、明に暗に実践してきた体験を元に整理・統合 • OA機器開発での実践、マイクロソフト在職中の最新技術の理解・習得、実案件支援での暗黙的適用 • 最新のソフトウェア開発技術、IT 技術の活用 • 今時、“オブジェクト指向”とか、“UML”、“開発方法論”とか言う時代か？ • 過去にあった、方法論戦争とか、“こうあるべし”とか嫌だしね • “概念モデリング” ※ 英語で “Conceptual Modeling” • 概念情報モデル（≒オブジェクト情報モデル）⇒ ビジネスのデータ構造 • 概念振舞モデル（≒状態モデル）⇒ビジネスの動的側面・シナリオ

11. 概念情報モデル～現実世界の情報構造～

12. 現実世界の写し、あるいは、データ構造 • データっていうけど • 何の？ • 要するに、同じ特徴値の組で記述できる、指差しできるモノやコト・役割（インスタンス）と、それらの関係 12 2 1 F002:工場 PB021:装置 PB037:装置 PB052:装置注文

13. 概念情報クラスクラス名特性値名:データ型名・・・特徴値のリスト概念クラス名特性値名:データ型名特徴値の名前特徴値のデータ型名概念クラス UML表記クラス名特性値名:データ型名・・・属性のパートに特徴値を記載簡易表記クラス名特性値名・・・クラス名データ型なしクラス名のみ ※ 大規模なクラス図で使用 ※ 図はなるべく見やすく描くこと ※ 特徴値名は同一のクラス内で重複しないことモノ、コト、役割の分類存在する、個々の、モノ、コト、役割は、どれかの概念情報クラス（分類）に属し、概念情報クラスで定義された特徴値の値を全て持つ

14. Relationship A B Aの多重度 Bの多重度 Aの意味 Bの意味概念クラス関係名概念クラス “A”と “B”、二つの概念クラス間の“関係”を表記 Aの多重度 Bの多重度 Aの意味 Bの意味関係名問題領域内で重複しない名前 Aのインスタンスから見た多重度 Aのインスタンスから見た、Bの意味を表す簡潔なテキスト Bのインスタンスから見た、Aの意味を表す簡潔なテキスト Bのインスタンスから見た多重度 ※ 関係名、意味、多重度の線に対する上下の位置は見やすい位置でよい ※ 大規模な図の場合は、関係名、意味は省略してよい関係は、２つのクラスをつなぐ線で表現する B 0..1 Bの意味 B 1 Bの意味 B * Bの意味 B 1..* Bの意味多重度は、“0..1”、“1”、“*”、“1..*” の４種類のみを使用 Aのインスタンスが存在する場合、Aの各インスタンスに対して、R1で定義された意味で関係するBのインスタンスが存在しないか、存在した場合はただ一つだけ存在する R1 R1 R1 R1 Aのインスタンスが存在する場合、Aの各インスタンスに対して、R1で定義された意味で関係するBのインスタンスが、必ず一つだけ存在する Aのインスタンスが存在する場合、Aの各インスタンスに対して、R1で定義された意味で関係するBのインスタンスが、存在しないか、複数存在する Aのインスタンスが存在する場合、Aの各インスタンスに対して、R1で定義された意味で関係するBのインスタンスが、必ず一個以上存在する

15. 概念情報クラス、概念インスタンス、Relationship の関係概念情報モデル顧客商品注文発注者 * * 購入予約概念インスタンスの一シーン顧客A 商品001 注文 A001 顧客B 商品002 商品003 顧客C 顧客Aは、商品001、商品002を注文している顧客Cは、商品002を注文している顧客Bは、何も注文していない商品003は、誰からも注文されていない概念クラスと関係で定義した制約に従って… 現実のシーンが変わっても、概念情報モデルの構造は不変不変の構造に着目するので安定して作業を行える時間の経過とともにドラスティックに変化

16. 関連概念情報クラス A B Aの多重度 Bの多重度 Aの意味 Bの意味概念クラス関係名概念クラス関係を表す線と関連クラスを、点線でつなぐ C 特徴値・・・関連クラス ※ 関連クラスも概念クラスであり、特徴値がある場合はリスト表記してよい “A”と“B”という概念の間に生じる別の概念をモデル化 ※ 左右反転したときに同じ多重度になるものは省略多重度のパターン

17. Super-Sub Relationship P C1 C2 P1 p2 c11 c12 c21 c22 拡張される側に△をつけて、拡張するクラスを線でつなぐ {complete, disjoint} ※拡張した側の(Sub)クラスの各インスタンスに対応する拡張された側の (Super)クラスのインスタンスが必ず一つだけ存在する、かつ、拡張された側のクラスの各インスタンスに対応する、拡張したクラスのうちのどれかのクラスのインスタンスが必ず一つだけ存在する。 ※拡張するクラスの数は、扱っている問題領域において意味的に正しければ、 2つ以上あっても構わない ※{complete, disjoint}は図の表記上、省略しても構わないが、モデリングにおいては、{complete, disjoint}になるように概念クラスを定義すること Pの集合 C1の集合 C2の集合 P を C1、C2 で細分化集合のベン図で描くと… オブジェクト指向プログラミングの、継承や interface の実装、 polymorphism とは、まったく異なる概念なので注意作成した概念情報モデルに現実世界の事象を概念インスタンスとして割り当てていったとき、 • あるケースでは必要な特徴値があるケースでは不必要 • あるケースの時だけ別の概念情報クラスとRelationshipを持つ • 振舞が異なる様な場合は、Super-Sub Relationship で細分化するのがよい Super側 Sub側

18. 概念情報モデル概念情報クラス（集合・分類）と概念インスタンス（実体）注文 *注文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 個数金額 C003P03 1-001 2 1400 C003N00 8-005 1 3500 C026L01 2-052 50 63000 ・・・・・・・・・表で示すとインスタンス間の関係が見えなくなるので関係を示す特徴値が必要存在する“顧客”のリスト存在する“商品”のリスト存在する“注文”のリスト

19. Relationship の特徴値によるフォーマライズなどクラス名非重複特徴値名（I）・・・関係特徴値名(R) ・・・計算可能特徴値名(M) 問題領域において、概念クラスのインスタンスで必ず別の値を持つ場合は、後ろに“I”をつけるか、先頭に“＊”をつける関係を持つ他の概念クラスの特徴値と同じ値を持つ場合は、後ろに“(R)”をつける概念モデルの他の要素から計算可能な場合は、後ろに“(M)”をつける製造装置 Device Id（I）担当工程(R) 仕掛り製品数(M) 工程工程名（I）生産中の製品 Product Id（I) 現在の工程(R) 1 1 0..1 0..1 * * 割当て現在の工程割当てられた機器担当工程現在の工程仕掛り製品 ※Device Id は製造装置を特定する一位の値なので重複は不可 ※“製造装置.担当工程”は、“割当て”という名前で関係づけられた“工程”の “工程名”と同じ値でなければならない ※“製造装置.仕掛り製品数”は、 “生産中の製品”クラスのインスタンス群の中で、関係の“製造中”で関係づけられたインスタンスの数と一致していなければならない製造中

20. データ型温度－単位：℃、数値：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}

21. 概念情報モデルの例概念情報モデル現実の世界

22. 概念情報モデルの例工場 *工場ID 工場名所在地消費電力(M) 生産ライン *生産ラインID 消費電力(M) 稼働状態 R_FL1 1 製品 *製品ID 装置 *装置ID 消費電力(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 オーダー仕様製造ステップ装置コマンド 1 1..* 1 1 製造指示仕様製造指示仕様 R_LOS1 R_POS1 概念インスタンスの例 F001:工場 F002:工場概念情報モデル

23. 概念情報モデルを使う ITシステム上のストレージやデータベースなど概念インスタンスの状態を保持現実の世界同期概念情報モデル存在条件を規定ビジネス上の問いかけ操作概念を抽出しモデル化存在条件に従って検索概念情報モデルに対する、ドメインオペレーションを介した操作ドメインオペレーション：概念情報モデルの定義に従った • 概念インスタンスの生成・削除 • 概念インスタンスの特徴値参照・更新 • Relationship のリンク・アンリンク • 概念インスタンスへのイベント送信

24. 概念振舞モデル～現実世界のダイナミクス～

25. 現実のビジネスのダイナミクス世界は方々で勝手に変化する… 現実の世界 3 12 2 1 商品は担当部署の都合で追加される … 顧客は任意の時点で増えていく… 注文は顧客の都合でバラバラに生じる… 結果として生じる、 • 同一商品に対する注文の競合 • 在庫引当の不整合等を防ぐ、ビジネス的な観点から検討された概念クラスや関係を、概念情報モデルで定義すること

26. ドメインオペレーション＝データフローモデル変化後の状態変化前の状態 C003:顧客 C172:顧客 P031:商品 N008:商品 C003P031-001:注文 12 C003:顧客 C172:顧客 P031:商品 N008:商品 C003P031-001:注文 C172N008-005:注文 12 2 R1 顧客インスタンスを検索商品インスタンスを検索注文インスタンス作成と個数、金額設定商品.単価と個数から金額計算 R1でリンク作成顧客ID 商品コード個数顧客インスタンス顧客インスタンス商品インスタンス注文インスタンス金額商品インスタンス事象: “商品を注文する” (C172:顧客, N008:商品コード,2:個数) 変化後の状態を作り出すための処理概念情報モデルで規定された概念インスタンスを参照・操作

27. 概念情報クラスの振舞の規定＝状態モデルドメインに対する振舞概念情報モデル 0..1 ＊ 1..＊ 1 S1 S2 S3 S4 E1 E2 E2 E3 E4 状態事象遷移状態に紐づいたアクション PB052:装置の状態機械 PB037:装置の状態機械 PB021:装置の状態機械状態遷移図 S1 S2 S3 S4 E1 E2 E2 E3 E4 インスタンスが“S4”の状態にある時に、 “E4”事象が発生した場合、状態“S4”から状態“S1”への状態遷移を引き起こす。 “S1”に紐づいたアクションがまず実行され、アクション完了時点で“S1”への遷移が確定する。状態遷移、アクション実行、遷移の確定 F002:工場概念インスタンスは、それぞれの“状態機械”を持つ PB021:装置 PB037:装置 PB052:装置状態機械の現在の状態を示す概念インスタンスのライフサイクルを規定する振舞モデル＝“状態モデル”

28. ドメイン～問題を主題ごとに分割する～

29. 概念インスタンスは今の状態を表す～じゃあ過去は？履歴管理したいので… ドメイン：テレメトリドメイン：装置管理 Time Series Instance *TSI_ID R_TSI_1 1 * Time Series Data Timestamp:DateTime Value:ANY 装置管理に関する深い知識は一切含まないデータの時系列管理は一切含まない

30. ドメイン分割～異なる主題群を整理する • 商品販売 • お客様から注文を受けて商品を引当て、配送するまでに着目するなら… • 配送手段は… • 郵便小包、宅配、… • トラック、航空便、船便、… • 適正なコスト/期間/品質で届けばどれでもよい • お客様が注文する手段は… • Web、モバイルアプリ、店頭の注文用紙、 … • 装置制御 • 制御対象の物理的制約を満たしたい • 実現手段は… • CPU、OS、… • 適正なコストで満たせればどれでもよいサービスドメインアプリケーションドメイン商品販売装置管理自動送配電テレメトリ GUI 3D Model AI 学習 AI 学習済みモデル配置セキュリティ認証基盤データベースメッセージ配信ビジネスに関わる主題群を領域ごとに分割して、独立した主題領域＝“ドメイン”毎に作業を行う “何をしたいか” と、“どう実現するか”を分割する

31. 複数ドメインの組合せによる現実世界の状態保持ドメイン：テレメトリドメイン：装置管理 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”のインスタンスとして保持する

32. 概念モデルを IT システムに組み込む～対応付け、あるいは、変換による実装～

33. 概念モデルをベースにした設計と実装ビジネスで求められる非機能要件 • 利用ユーザー増加傾向 • 管理機器数増加傾向 • 応答性能 • 運用コスト • 保守のしやすさ • セキュリティ要件 • アクセシビリティ • … 利用する実装技術・サービス選択ビジネス機能要件アプリケーションドメインの概念モデルサービスドメインテレメトリ GU I 3D Model AI 学習 AI 学習済みモデル配置セキュリティ認証基盤データベースメッセージ配信選択対応付け対応付け対応付け変換ルール変換ルール変換ルール稼働可能な実際のITシステムインスタンスの状態該当要素の抽出必要ライブラリ等の実装

34. 概念モデルから定義した情報を取り出す～メタモデル • 概念モデルの概念情報モデル＝メタモデル Domain *Name Description R1 1 1..* Class *Domain Name *Name Description Property *Domain name *Class Name *Name Description concept R2 1 * Data Type *Domain Name *Name Description R3 1 specify * R20 1 1..* String Data Type Pattern Number Data Type Unit Kind Domain Enum Data Type {complete, disjoint} R21 Enum Value *Domain Name *Data Type Name *Name Description 1 1..* values R22 Relationship *Domain Name名 *Name Description Side of Relationship Multiplicity Mean Binary Relationship Super Sub Relationship {complete, disjoint} R10 R11 R12 1 Super class 1..* Sub class * Sub Side * 1 1 R13 1 1 1 1 One Side of Relationship Other Side of Relationship {complete, disjoint} R14 R15 R16 * 0..1 * Relationship class R17 R18 1 linked by Complex Data Type * 1..* parent child R23 概念情報モデルの概念情報モデル（抜粋） Boolean Data Type Reference Data Type * 1 holder R24 例メタモデルの定義に従って構築した概念モデルの内容を系統的に全て取り出せる ↓ メタモデルで設計変換ルールをプログラム化 ↓ 全ての概念モデルから実装コードを自動生成できる

35. 概念情報モデルってそんなに強力なの？ • 本当に現実世界・論理世界をモデル化できるのか？ • 30年来の経験から、多分可能 • IT システムの本質はデジタル化したデータを扱うシステム • デジタル化データ化できるものは確実に、概念情報モデルの定義は可能 • 対偶をとると、「概念情報モデルの定義が不可能なら、デジタル化データ化はできない」⇒ IT システム化できない • つまりは、概念情報モデルは実用上問題ない、はず • 概念モデリングをマスターしていると便利ですよ • 新しい技術・サービスの理解や、競合他社の似たような技術を比較で • Relationship の多重度を敢えて変えてみると見落としや新たな発見が • 慣れると頭の中に回路がり、何見てもモデリングするになりますが（苦笑） • 表現方法はケースバイケースで • 既に確立された記法があるならそれに従ったほうが効率が良いですよ • 言語やプロトコルなら、ASN で • WPF なら XAML で • プログラミング言語なら、UML Full Spec で • Domain Specific Language 最大の弱点は、概念モデル作成が出来ないと、何も始まらないところですかね…

36. 手書きで概念モデルを描く？ • どうです？このやり方？ 1. ビジネス要件を元に概念モデルを紙に描く 2. 紙に書かれたメタモデルと設計ルールを元にコーディングする 3. 要求変更を元に概念モデルを修正する 4. 修正した箇所を特定し、紙に書かれたメタモデルと設計ルールを元に、コードの変更箇所を特定しコードを修正する 5. 以降、3と４の繰り返し • 現実は… • 推進する側は充実間満載かもしれないが、現場はたまったもんじゃない！ • いつの間にか紙に書かれた概念モデルはお蔵入り • コードだけが独り歩き ⇒専用のモデリングツールと自動生成環境は必須 1. 専用ツールで概念モデル作成 2. 概念モデルからコードを自動生成 3. 要求変更を元に概念モデルを修正⇒コードを再生成

37. 概念モデリング専用ツール～ BridgePoint • xtUML community がオープンソースで提供する専用ツール • https://github.com/xtuml/bridgepoint • 昔は有償の結構お高いツールだったなぁ… • 使い方は、「ビジネスをモデル化する～ BridgePoint を使ってみよう」で概念情報モデル状態モデルとデータフローベースのアクション記述動的振舞も含め検証する Model Verifier C/C++コード生成可能な Model Compiler C#、.NET で動くコード生成環境一式を公開中詳しくは、「Technique of Transformation」で出来れば、Excel、PowerPoint 並みに Information Worker に使ってほしい…

38. “概念モデリング”まとめ

39. まとめ • IT システム構築にはビジネスのモデル化が必須 • 概念モデル作成による現実世界のモデル化 • ビジネスが扱う、モノ・コト・役割等のデータ構造 ⇒ 概念情報モデル • ビジネスシナリオやフロー等のダイナミクス ⇒ 概念振舞モデル • ドメイン分割 • 異なる主題領域は分けて考える • 複数の主題領域の統合で IT システムを構築する • メタモデルと変換による実装 • 作成した概念モデル（現実世界の写し）から系統的に実装コードを生み出す • 専用ツールによる開発の自動化 • BridgePoint とコード生成環境

40. お役立ち資料 • https://note.com/kae_made • Art of Conceptual Modeling • 詳細な概念モデリング教本 • 概念モデリングチュートリアル集 • 概念モデリングをマスターするためのチュートリアル • Technique of Transformation • 概念モデリングをベースにした“変換による実装”解説 • Essene of Software Design • アーキテクチャ・設計で知っておいたほうが良い基礎 • Practices of Software Engineering • 大規模開発に役立つソフトウェアエンジニアリング実践要諦

41. システム開発の “デジタルトランスフォーメーション” 概念モデリングをベースにした“変換による実装”

42. そもそも“デジタルトランスフォーメーション”って何さ？ • Wikipedia で調べたら… • 色々出てきた：苦笑 • 私の理解に近しいのが、案外、ガートナーと経産省の定義だった経済産業省「DX推進ガイドライン」より “企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること” “概念モデルをベースにした変換による実装” ≒ DX

43. 概念モデルをベースにした設計と実装～変換による実装ビジネスドメインの概念モデル 0..1 ＊ 1..＊ 1 概念モデルの概念情報モデルと振舞モデルの実行セマンティクスプログラミング言語のシンタックスとセマンティクスコードへの変換方法設計 • 非機能要件 • サービスドメイン • インフラストラクチャドメイン変換ルール • データ構造 • ロジック • モジュール分割プログラムコードビルドスクリプト配置スクリプトプログラムコードビルドスクリプト配置スクリプトプログラムコードビルドスクリプト配置スクリプト build Deploy transform IoT機器 Cloud Digital Transformation Digital Twins

44. BridgePoint による概念モデルを C# コードに変換するドメインの概念モデル 0..1 ＊ 1..＊ 1 概念モデルの概念情報モデルと振舞モデルの実行セマンティクスプログラミング言語のシンタックスとセマンティクスコードへの変換方法設計 • 非機能要件 • サービスドメイン • インフラストラクチャドメイン変換ルール • データ構造 • ロジック • モジュール分割プログラムコードビルドスクリプト配置スクリプトプログラムコードビルドスクリプト配置スクリプトプログラムコードビルドスクリプト配置スクリプト transform .NET Framework C# 言語仕様 Visual Studio T4 Template C# によるフレームワーク設計共通コードのライブラリ化 https://github.com/kae-made/domainmodel-code-generator-csharp 詳しくは、「Technique of Transformation」で

45. デモ BridgePoint のモデルから C# コードを生成して動かす

46. Azure サービスを活用した IoT・Digital Twins ソリューション組込み機器 Azure IoT Hub Azure Stream Analytics Azure Functions Azure Event Hubs Azure Digital Twins Database SQLDB or Cosmos DB Azure Data Explorer Web サービスの名前ラムダアーキテクチャベースの標準構成 • リアルタイムデータ処理ー Hot Path • 過去データの活用ー Cold Path ※ 基本は、ビッグデータ系データストリーム非機能要件の重要ポイント • セキュア • スケーラブル • 拡張性 IoT • モノとサービスの連携 • 機器は現実世界とデジタル空間の窓口 Digital Twins • 現実世界のモノ・コト・役割の写しをデジタル空間に再現する

47. Azure Digital Twins • Azure Digital Twins の使い方 • Twin Model を定義 • モノやコト、役割を複数の Property の値を持つ、Twin を定義 • Twin 間の Relationship を定義 • Twin Model に則った Twin Graph の保持 • Twin Graph の参照・更新 • Twin Graph の状態変化を別サービスへ • Twin への Telemetry 通知 • Azure Digital Twins とは • 現実世界の“今の写し”を保持・共有する • Twin Model は DTDL で記述 • 概念情報モデル • 概念情報モデルを定義 • モノやコト、役割を複数の“特徴値”の値を持つ、“概念情報クラス”として定義 • “概念情報クラス” 間の Relationship を定義 • 現実の世界の状態を、概念インスタンス群で表現用語が違うだけで、同じ話だよね概念情報モデルから DTDL 生成すればいいね概念インスタンス群の状態を Twin Graph で保持すればOK Conceptual Model for business solution constructed by BridgePoint DTDL Generator Twin Model (DTDL) Twin Model (DTDL) Twin Model (DTDL) Twin Model (DTDL) Generated DTDL Files Upload Twin Models https://github.com/kae-made/dtdl-schema-generator

48. IoT Plug & Play を元にした IoT 機器アプリ雛形生成 • DTDL を使って、IoT 機器とクラウドサービス間の双方向通信を定義 • IoT 機器が IoT Hub に接続する際に Model Id を通知することにより、その IoT 機器がどんな双方向通信ができるかわかる仕組み • IoT PnP DTDL 定義から双方向通信のデータ構造、送受信ロジックは自動生成可能 • IoT Hub との接続と双方向通信の基本機能の部分はパターン化可能 • 定型部分をフレームワーク化 • “変換による実装”の技術を活用して、IoT 機器アプリの雛形を自動生成する Conceptual Model for business solution constructed by BridgePoint DTDL Generator IoT PnP Model (DTDL) Generated DTDL Files IoT App Generator IoT Device Application 以下のコードを追加すれば完成 • センサーからのデータ収集 • Direct Method 起動時の処理 • Device Twins 周りの処理 https://github.com/kae-made/dtdl-iot-app-generator

49. IoT 機器からのテレメトリデータを元にした Twin Graph 更新 Send Telemetry & Update Reported Property Telemetry Update Property Publish as telemetry Reported Property Twin Model ReceiveD2CToTwinGraph ReceiveReportedPropertiesToTwinGraph • Telemetry の一部は、 Property 更新へ • それ以外は、Telemetry として Publish • Azure Function は固定コードで実現可能 DTDL 生成時の一工夫 Twin Model 側と IoT 機器側それぞれを生成 ※“ドメイン”という概念の応用

50. デモ BridgePoint のモデルからの Twin Model・IoT PnP 用 DTDL 生成、及び、 IoT 機器アプリの雛形生成 IoT 機器アプリ⇒ IoT Hub ⇒ Azure Function ⇒ Twin Graph 更新

51. 概念インスタンス群の状態保持～ In Memory vs Azure Digital Twins In Memory の場合 Azure Digital Twins の場合振舞ロジックデータ構造実行エンジン概念インスタンス群の状態（メモリ）振舞ロジックデータ構造実行エンジン概念インスタンス群の状態キャッシュ外部ストレージ参照・更新に気を使う必要なし参照・更新で同期処理が必要

52. Azure Digital Twins 利用時の Domain Model 実装の動作 Generated Domain Model Library （Data Structure ＋ Behavior） HTTP Trigger • Invoke Domain Operation • Create/Delete Instance • Update Instance Property • Link/Unlink Relationship Twin Model Telemetry notification Get/Set current twin graph Publish telemetry ※ Executing for current state ※ Scalable Generated Domain Model Library （Data Structure ＋ Behavior） Get/Set current twin graph Publish telemetry ※ Executing for current state ※ Scalable Trigger scenario Update state Data Stream Telemetry Notification Update State Notification Dashboard or Long term Storage Domain Model C# ライブラリ側外部ストレージ側 Instance Instance Instance Instance Instance In Memory Cache Behavior thread Instance Property Property Conceptual Instances State データが必要になった時点で参照・取得変更内容を収集： • 概念インスタンス生成・削除 • Relationship のリンク・アンリンク更新された特徴値取得状態更新データセット更新されたデータを反映実行完了概念モデルが実行セマンティクスに従って正しく現実をモデル化していれば同時並行実行でも問題なく動く⇒ スケーラブル

53. デモ BridgePoint のモデルから生成された Domain Library と Azure Digital Twins のコラボレーション

54. 全体像 Conceptual Model for business solution constructed by BridgePoint C# Generator DTDL Generator Project File C# Code C# Code C# Code C# Code Generated Files Twin Model (DTDL) Twin Model (DTDL) Twin Model (DTDL) Twin Model (DTDL) Generated DTDL Files Upload Twin Models IoT App Generator DLL Build & Publish Add logic & Build as Application Fixed Logic + Fixed Logic + Fixed Logic 詳しくは、以下を参照してください • 「チュートリアル～モデル化したビジネスを Azure Digital Twins を活用したソリューションに変換する」 • 「Azure の最新機能で IoT を改めてやってみる」用途に合わせて View を追加すれば完成 • 管理用ダッシュボード • ユーザー向けの Web ページやモバイルアプリ • 3D Model の View で Metaverse 冒頭のアーキテクチャに則っているので、 • スケーラブル • 拡張可能

55. 開発プロセス振り返り概念モデリング、自動生成等、従来と凄く違うように見えるが… 1. 要件定義 2. 実装技術の選択 3. アーキテクチャの定義 4. アーキテクチャに則ったフレームワーク設計 5. 詳細な実装方法の設計 6. 実装 7. テストという本質的な手順は従来型の開発と全く同じ概念モデリングを使って、きっちり厳密に行うので… ⇒結果として最新の IT 技術、開発技術を駆使した自動化が可能

56. 従来型開発との比較開発工数は N×Mに比例開発工数は N＋Mに比例設計は、概念モデルのメタモデルのみに依存し、個々のアプリケーションとは無関係に作業を進められる

概念モデリングによるビジネスの見える化とシステム開発のデジタルトランスフォーメーション.pptx

Vous êtes en train de lire un aperçu.

Consultez-les par la suite

概念モデリングによるビジネスの見える化とシステム開発のデジタルトランスフォーメーション.pptx

Plus De Contenu Connexe

Similaire à 概念モデリングによるビジネスの見える化とシステム開発のデジタルトランスフォーメーション.pptx (20)

Plus par Microsoft Co., Ltd. (15)

Plus récents (20)