2023/7/22 xtUML 研究会でのショートセッション Shlaer-Mellor法（現xtUML）を基にした概念モデリングの妥当性を哲学（現象学）的な観点から考察。加えて、概念モデルの基本構成、概念モデリングのコツを解説

1. 概念モデリング再考
2023/7/22
～ xtUML を学ぶ会
Knowledge ＆ Experience
代表 太田 寛
https://www.kae-made.jp
Twitter： @embedded_george

2. 自己紹介と事業紹介

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

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

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
↤ “対応付け”

8. ソフトウェア・システム開発の必須事項
• 開発対象の現実世界を理解する事
• 理解した内容を記述し、関係者の間で共有する事
現実世界を記述する為の記法が必要
その手段としての“概念モデリング”

9. “現実世界” ⇔ “概念モデル”？
現実世界をモデル化する
現実世界の対象を
“概念モデリング”で正しくモデル化
（記述）できるのか？
1. 現実という“客観”の世界と人間の“主観”を通じて認識した世界は
一致するか
2. 一致するとして、その記述方法として“概念モデリング”は適切か

10. “現象学”による回答 ⇒ そもそも“認識”とは
https://note.com/kae_made/n/n7ba632d9555e?magazine_key=m12bb08458a18
「現象学的還元」
我々が「身体」を動かすという体験、あるいはまた「身体」で様々な事物を感じるという体験を、「意識」に
生じている事柄として適切に記述できれば、それが、「身体」体験の「現象学的還元」となる
身体を動かすというような体験を適切に記述する
ことはそもそも不可能
概念的な事態ではなく、感性的な事態だから。
表象様式は無限だから
1. コギタチオ（意識体験）
• コギターツム（意識を向けている対象そのもの）という構造がある
• 現に知覚しているのはつねに一部、だがそれを通して全体対象を志向的に体験しているという事
2. 「中心対象」と「背景野」という構造がある
• メルロー＝ポンティ的には、「地と図」
3. 注意、配置という主体的な中心点がある

11. どういう事？
”今目の前にリンゴが存在しているので、赤くて、丸くて、
つやつやした様子が私に見える”
”いま私に赤くて、丸くて、つやつやした様子が見えてい
る、だから私は目の前にリンゴが実在しているという確
信を持つのだ”
現象学前
現象学
人間の世界を事実としての世界としてではなく、「関係の世界」、すなわちたえず「意味」と
「価値」の連環として編み変えられている「関係の世界」として捉える事、これが「世界」を
「本質」として捉える視点の核心

12. 概念モデリングで現実世界の本質をとらえる
• 概念モデリングの道具立て
• 背景野としての主題領域 ⇒ ドメイン
• 個別の特性を表す値のフォルダー ⇒ 特徴値（Property、Attribute）
• 特徴値の値の意味の定義 ⇒ データ型
• 特徴値を束ねた対象の分類 ⇒ 概念クラス
• 対象間の意味と多重度の定義 ⇒ Relationship
対象世界を記述する為の必要最低限を満たす

13. モデルのみの正しさを問う事は、本来無意味
「知覚」という体験の共通項を取り出す作業が、知覚の現象学的還元であ
り、「意識体験の本質」あるいは「意識のア・プリオリ」を把握するとは、
すなわちそういうこと
正しい世界像が存在するという想定を一旦破棄する ‐ エポケー（括弧入
れ）
• モデル化する事＝現実世界を記述する事であり、他者の主観的世界観との共通項
を括りだすための手段になりうる⇒むしろ何らかのモデル化技法は必須
• 出来上がったモデルが正しいかどうかを問う事は無意味であり、そのモデルに関
わる人（モデル化対象の世界に参加している人達）が同意するか否かが重要
• モデルは、モデル作成者がモデル化対象の世界に対して抱いている確信が何故成
立するのかを説明する為の、条件と構造の記述である

14. 言葉とは？
• 概念モデル:＝{概念クラス、特徴値、データ型、Relationship}
• 図と言葉で定義する
• ポストモダンの言語哲学での言葉遊び的な矛盾の数々
“すべてのクレタ人は嘘つきだ”とクレタ人が言った
そんなあやふやな“言葉”という道具を使って大丈夫なのか？
どれほど単純に見える言語行為でも、必ず「一般意
味」を利用して、その都度の各自的な「意」の投げ
かけあい（関係企投）を行っているといえる。
この様に語の「一般意味」と、言語の「企投的意
味」は違った本質を持っている
この実存的企投に発する他者との世界了解の共有（分
有）ということが、発語する事の基本的「動機」であり、
またそれが、「現実言語」の「企投的意味」の本質です。
更にこの様な関係行為としての言語による「企投的意
味」の集合的な痕跡（積み重なり）として、言語の「一
般意味」（辞書的意味）が成り立っている
あれ？これ LLM の基本じゃん！

15. 再び、概念モデル
• 概念モデル ＝「一般意味」の単語を組織化
• 特徴値を束ねて、概念クラスを定義
• Relationship で、概念クラス間の関係を意味付ける
⇒ これらにより、「企投的意味」が補強される
⇒ ドメインは、データ型、特徴値、概念クラス、Relationship の集まり
で詳細化されたもの ＝ 背景野
一致するとして、その記述方法として”概念モデリング”は適切なのか
第二の問への解
Yes と言ってもいいでしょう

16. データは単体で存在しない
• 温度
• 何の？
• 部屋の
• その部屋を記述するほかのデータは？
• 部屋の名前とか？湿度とか？
• ⇒部屋というクラス:={部屋の名前、温度、湿度}
• 部屋に関係するほかのモノとかは？
• そこにいる人とか？その部屋の建物とか？
• ⇒ほかのクラス群とクラス間の Relationshipがあるよね

17. 概念モデリング ～ 概念情報モデル
現実世界の商品販売
アイデンティティのあるもの、
直接目で見えないもの、
触れられないものも含めて…
• 名前
• 住所
• 値段
• 数量
• 商品コード
• 商品番号
• …
この段階で既にそれぞれの値ではなく、
分類の名前であることに注意
概念情報モデル
普遍化している事と、
分類を扱っていることに注意
企投的意味を担っているのは
関係性であることに留意

18. ドメイン
古典力学
果樹園栽培
果物販売サービス
画像認識 AI
ドメイン（背景野）が変われば、
全く異なる概念モデルが出来上がり、例え同じ
言葉でも企投的意味が変わる。
概念情報モデルにおいて、企投的意味を規定す
るのは、概念クラスよりむしろ Relationship
であると言える。
CG表示アルゴリズム

19. 更に… Dynamics のモデル化
• 概念情報モデル:＝{データ型,概念クラス,特徴値,Relationship｝
• 今の状態を表現
• 特徴値の値の変化や、概念インスタンスの生成削除、Relationship の
リンクの切張等の、履歴情報をモデルに入れない事
• 時間経過に伴う、事象の発生や、値の変化は状態モデルで記述
する
• 状態モデル
• 概念クラスを雛形にして存在する、“概念インスタンス”毎に
• 採りうる状態群、事象に対する状態遷移を、状態モデルとして記述
• 状態遷移が起こった時に、行われる振舞いを、遷移先の状態のアクションとして、
データフローモデルに従って記述する
• それぞれの概念インスタンスは、雛形にしている概念クラスで定義さ
れた状態モデルで規定される、状態機械を持ち、同時並行的に振舞う
• 相対性理論によれば、観測は、各観測者の視点から為されるので、これも妥当

20. 概念モデルの妥当性 ～ 再び
• 数学的妥当性
• 一見正しそうに見えても、論理的破綻・矛盾がある表記を使うと、ど
こかで破綻するに違いない
• 概念モデルの妥当性は、数学的に証明されるのが望ましいだろう
• 圏論：Category Theory が使えそう ～ 勉強中
• 圏 = 合成可能な矢印のシステム
• モノ、モノ間の射
• 関手 = 圏の圏における射 ：アナロジー
• 自然変換 = アナロジーのアナロジー
• プログラミング言語の意味論等で現に活用されている
※ 基本は、“モノそのもので扱うのではなく、分類と分類上の対応付け”
で考える事…らしい

21. 圏論による 概念モデルのフォーマライズ ～ 見込み
• 多分…
• 現実世界のモノと、概念情報モデル、状態モデルの対応付け := 圏
• 特徴値⇔概念クラス :＝ 圏・関手
• Relationship ⇉ 概念クラス :＝ 圏・関手
• 概念クラス⇔ 状態モデル :＝ 圏・関手
• 状態モデル :＝ 圏
• 状態⇔状態アクション:＝圏
• データフローモデル :＝圏
• 実行セマンティクス :＝圏
• モデルのコードへの変換 := 複数ドメインの対応付け :＝関手・自然変換
• …
• 教科書の例題がシンプル過ぎるので、考察必要
• プログラミング言語の意味論への適用とは、毛色が異なる印象

22. 参考）概念モデルからのコードへの変換
• 概念モデリング（xtUML）を実開発で使うなら、自動生成は Must！
ドメインのモデル
OOA of OOA 変換ルール
コード
実装技術

23. 概念モデルをクラウドサービスに実装する 自動生成

24. まとめ
• 概念モデルは使い物になるのか？
• 現象学的には、モデルが正しいかどうかを問う事は無意味
• 現実世界を記述する為には、何某かの記法が必要
• どの記法が一番良いかを問う事も無意味
• 色々ある中で、概念モデルは現実世界を記述する手段として、その構
成要件から、必要最低限の要件を満たすものと思われる
• モデルが正しいかどうかは、関係者の合意で決まる
• 概念モデルは数学的に適切に意味付けられるか？
• 多分、出来るだろう
• 私の過去30年以上の体験を通じて…
• xtUML ベースの概念モデリングはお勧めですよ

25. @2023 Knowledge & Experience