Contenu connexe Similaire à 概念モデリング再考 (20) Plus de Knowledge & Experience (20) 概念モデリング再考3. 自己紹介
• 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. マイクロソフトを卒業してから、早1年と3か月…
• 過去の体験を元に…
• 世界最大の IT 企業の最新技術情報を
16年にわたって普及啓発
• 数百の実プロジェクト支援
• 30年来のモデル駆動型開発への取り組み
• 物理学的アプローチなのかな…
• 習得した知識を整理整頓しながら公開中
https://note.com/kae_made
• Art of Conceptual Modeling
• Technique of Transformation
• Essence of Software Design
• Practice of Software Engineering
• Azure の最新機能で IoT を改めてやってみる
• Stones and Gold of Modeling for Real World
今一番気になっている事は、“現実世界のモデル化”
6. 概念モデルとは
• 概念モデリング
• Shlaer-Mellor 法(xtUML)のモデリング体系をベースに
• 富士ゼロックス、マイクロソフト時代の技術体験を踏まえ
• リアルタイム制御システム開発から、ビジネス一般のモデリングへ拡張
• BridgePoint でビジネスシナリオをモデル化すると…
• 組込み機器+Cloud サービス(Microsoft Azure)で動くコード一式生成
https://note.com/magazines/all
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 より
技術的基盤
技術的基盤
現実世界における“やりたい事”のモデル
たった一個のモノ(Identity)とたった一個の特徴値しかないなら簡単だけど…
現実は複雑怪奇で果てしない。視点ごとに複数の見方(ドメイン)があるし…
モデルは圏?で、ドメインは圏の圏?で変換によるコード生成は関手圏か?
多分、視点(ドメイン)毎のモデルはモノイドで、
対応付けは関手の圏で表す自然変換なんだろうな…
↤ “対応付け”
Open AI
↤ “対応付け”
14. 言葉とは?
• 概念モデル:={概念クラス、特徴値、データ型、Relationship}
• 図と言葉で定義する
• ポストモダンの言語哲学での言葉遊び的な矛盾の数々
“すべてのクレタ人は嘘つきだ”とクレタ人が言った
そんなあやふやな“言葉”という道具を使って大丈夫なのか?
どれほど単純に見える言語行為でも、必ず「一般意
味」を利用して、その都度の各自的な「意」の投げ
かけあい(関係企投)を行っているといえる。
この様に語の「一般意味」と、言語の「企投的意
味」は違った本質を持っている
この実存的企投に発する他者との世界了解の共有(分
有)ということが、発語する事の基本的「動機」であり、
またそれが、「現実言語」の「企投的意味」の本質です。
更にこの様な関係行為としての言語による「企投的意
味」の集合的な痕跡(積み重なり)として、言語の「一
般意味」(辞書的意味)が成り立っている
あれ?これ LLM の基本じゃん!
15. 再び、概念モデル
• 概念モデル =「一般意味」の単語を組織化
• 特徴値を束ねて、概念クラスを定義
• Relationship で、概念クラス間の関係を意味付ける
⇒ これらにより、「企投的意味」が補強される
⇒ ドメインは、データ型、特徴値、概念クラス、Relationship の集まり
で詳細化されたもの = 背景野
一致するとして、その記述方法として”概念モデリング”は適切なのか
第二の問への解
Yes と言ってもいいでしょう
16. データは単体で存在しない
• 温度
• 何の?
• 部屋の
• その部屋を記述するほかのデータは?
• 部屋の名前とか?湿度とか?
• ⇒部屋というクラス:={部屋の名前、温度、湿度}
• 部屋に関係するほかのモノとかは?
• そこにいる人とか?その部屋の建物とか?
• ⇒ほかのクラス群とクラス間の Relationshipがあるよね
19. 更に… Dynamics のモデル化
• 概念情報モデル:={データ型,概念クラス,特徴値,Relationship}
• 今の状態を表現
• 特徴値の値の変化や、概念インスタンスの生成削除、Relationship の
リンクの切張等の、履歴情報をモデルに入れない事
• 時間経過に伴う、事象の発生や、値の変化は状態モデルで記述
する
• 状態モデル
• 概念クラスを雛形にして存在する、“概念インスタンス”毎に
• 採りうる状態群、事象に対する状態遷移を、状態モデルとして記述
• 状態遷移が起こった時に、行われる振舞いを、遷移先の状態のアクションとして、
データフローモデルに従って記述する
• それぞれの概念インスタンスは、雛形にしている概念クラスで定義さ
れた状態モデルで規定される、状態機械を持ち、同時並行的に振舞う
• 相対性理論によれば、観測は、各観測者の視点から為されるので、これも妥当
20. 概念モデルの妥当性 ~ 再び
• 数学的妥当性
• 一見正しそうに見えても、論理的破綻・矛盾がある表記を使うと、ど
こかで破綻するに違いない
• 概念モデルの妥当性は、数学的に証明されるのが望ましいだろう
• 圏論:Category Theory が使えそう ~ 勉強中
• 圏 = 合成可能な矢印のシステム
• モノ、モノ間の射
• 関手 = 圏の圏における射 :アナロジー
• 自然変換 = アナロジーのアナロジー
• プログラミング言語の意味論等で現に活用されている
※ 基本は、“モノそのもので扱うのではなく、分類と分類上の対応付け”
で考える事…らしい
21. 圏論による 概念モデルのフォーマライズ ~ 見込み
• 多分…
• 現実世界のモノと、概念情報モデル、状態モデルの対応付け := 圏
• 特徴値⇔概念クラス := 圏・関手
• Relationship ⇉ 概念クラス := 圏・関手
• 概念クラス⇔ 状態モデル := 圏・関手
• 状態モデル := 圏
• 状態⇔状態アクション:=圏
• データフローモデル :=圏
• 実行セマンティクス :=圏
• モデルのコードへの変換 := 複数ドメインの対応付け :=関手・自然変換
• …
• 教科書の例題がシンプル過ぎるので、考察必要
• プログラミング言語の意味論への適用とは、毛色が異なる印象
24. まとめ
• 概念モデルは使い物になるのか?
• 現象学的には、モデルが正しいかどうかを問う事は無意味
• 現実世界を記述する為には、何某かの記法が必要
• どの記法が一番良いかを問う事も無意味
• 色々ある中で、概念モデルは現実世界を記述する手段として、その構
成要件から、必要最低限の要件を満たすものと思われる
• モデルが正しいかどうかは、関係者の合意で決まる
• 概念モデルは数学的に適切に意味付けられるか?
• 多分、出来るだろう
• 私の過去30年以上の体験を通じて…
• xtUML ベースの概念モデリングはお勧めですよ
Notes de l'éditeur リアルタイム系の制御ソフトウェア開発についても、制御ソフトウェアのモデル化をするのではなく、リアルタイムの制御対象そのものをモデル化する事が重要 そんな曖昧な言葉という道具を使って大丈夫なの?
関係性が重要なんだから単体で語っても意味がない。機器だけとか、サービスだけとか
分類で考える事