異なるモデリングパラダイムから見るモデリングの勘所 #ooc_2020

Transcript

1. 異なるモデリングパラダイムから見る モデリングの勘所 2020/02/16 Object-Oriented Conference 末並 晃 @a_suenami
2. 自己紹介 • 末並 晃 @a_suenami • 生息している界隈: DDDとか、TDDとか、RDBとか • お仕事で使ってる技術スタック: Rails, React, Java, PHP • 好きな RDBMS: PostgreSQL • 好きな制約: チェック制約 • 好きな焼肉の部位: ハラミ • 好きな（ｒｙ
3. インターネット上での立場
4. インターネット上での立場 殺伐としたインターネットの世界へ、 ただただ焼肉をタカられるという エンターテイメントを提供しています。
5. 今日話すこと • オブジェクト指向とは何か • クラスベースオブジェクト指向 • メッセージベースオブジェクト指向 • オブジェクト以外のモデリングとマルチパラダイムでのモデ リングについて • 計算モデルとデータモデル
6. オブジェクトとは
7. 2つのオブジェクト指向 • クラスベースのオブジェクト指向 ◦ 抽象データ型のスーパーセット ◦ モジュール化/データ抽象の手段としてユーザ定義型を利 用する ◦ 現在よく知られているのはおそらくこちら • メッセージベースのオブジェクト指向 ◦ オブジェクト同士がメッセージを送る（メッセージパッ シング）のをプログラミングの基本とするという考え方 ◦ 徹底的な動的性、遅延結合、メタプログラミングなどを 特徴とする
8. クラスベースオブジェクト指向
9. 歴史を振り返る 構造化プログラミング モジュラープログラミング データ抽象 抽象データ型 クラス
10. データ抽象とその手段としての抽象データ型 // point.h struct Point; struct Point* makePoint(double x, double y); double distance(struct Point *p1, struct Point *p2); // point.c #include “point.h” #include <stdlib.h> #include <math.h> struct Point { double x, y; }; struct Point* makePoint(double x, double y) { struct Point* p = malloc(sizeof(struct Point)); p->x = x; p->y = y; return p; } double distance(struct Point* p1, struct Point* p2) { double dx = p1->x - p2->x; double dy = p1->y - p2->y; return sqrt(dx*dx+dy*dy); } 『Clean Architecture』第5章 オブジェクト指向プログラミング
11. データ抽象とその手段としての抽象データ型 • 抽象データ型とは、データ抽象を実現する手段のひとつとし て提案され、その具体的実装としてクラスが多くの機能に導 入された。 • クラスとはモジュール化の手法のひとつと言える。 • つまり、クラスベースのオブジェクト指向におけるソフトウ ェア構築は、抽象データ型の構造化された集合としてシステ ムを構築することである。
12. データ構造とアルゴリズムの隠蔽 モジュール モジュール モジュール モジュール モジュール モジュール 抽象の世界 実際のデータ構造/アルゴリズムの世界 実装 実装 実装 実装 実装 実装 隠蔽・可換
13. メッセージベースオブジェクト指向
14. Smalltalk
15. Smalltalk • メッセージベースのオブジェクト指向を体現するプログラ ミング言語として（おそらく）もっとも有名な言語。 ◦ 言語というか処理系というほうが適切かも…？ • Smalltalk-72, Smalltalk-76 など複数の処理系がある。 • 徹底的な動的性と遅延結合にこだわり、誰もが自分のため にプログラミングできることを目指した。 ◦ パーソナルコンピューティング
16. メッセージパッシングを支える特徴 • メッセージ解釈の動的性と遅延結合 ◦ メッセージの解釈は実行時にレシーバーによって行われ る ◦ Smalltalk 処理系では実行時に解釈できないメッセージ があった場合、処理を中断してその実装を書ける ▪ これは実行 “後” まで結合を遅延していると言えるの では…？
17. レシーバーによる実行時解釈（Rubyの例）
18. 処理の中断とレシーバーの実装
19. メッセージパッシングを支える特徴 • オブジェクトの独立性 ◦ あるオブジェクトの変更が他のオブジェクトに影響しな い ◦ レシーバーがメッセージを解釈できなくても送信元には 影響しない • Earlang はオブジェクト指向？ ◦ これらの特徴を兼ね備えている（らしい）
20. メッセージ >= オブジェクト >> クラス クラスやメソッドという概念は 実行パフォーマンスのため（だけ）に存在する
21. ここまでのまとめ • オブジェクト指向にもいろいろあり、似たような機能（ク ラス、メソッドなど）はあるものの、背景にある思想はま ったく違う。 • 現代ではほとんどのプログラミング言語がクラスベースで ある。 • クラスベースのオブジェクト指向は型システムによる全体 構造の早期結合と実装の遅延/可換性、メッセージベースの オブジェクト指向は動的型付けとメタプログラミングによ る遅延結合を特徴とする。
22. メッセージベースOOから何を学ぶべきか • メッセージパッシングと遅延結合というコンセプトはとて もよいアイデアである • 現代ではシステムアーキテクチャの文脈でのほうがそのア イデアを活かせることが多いのではないか ◦ Pub/Sub ◦ キューイング / 非同期処理 ◦ ロギング
23. 意思決定の遅延 • いずれにしても何らかの意思決定を遅延するためのアイデ アである • 具体的な実装を検討する場合にはオブジェクトというアイ デアとは別の異なるモデリング手法が必要になる • “オブジェクトパラダイム自身がこれまでに登場してきたパ ラダイムの混合物である” （『マルチパラダイムデザイン 』）
24. マルチパラダイム・モデリング モジュール モジュール モジュール モジュール モジュール モジュール 抽象の世界 実際のデータ構造/アルゴリズムの世界 関数適用 関数合成 関係演算 （SQL） グラフ演算 手続き処理 有限オートマトン etc…
25. よいモデリングとは何か
26. モデルとは https://speakerdeck.com/a_suenami/moderutohahe-deatute-he-denaifalseka-number-kichijojipm
27. モデルとは つまり、モデリングとは何を重要な情報と扱い 何を捨てるかを決めること
28. 思考実験: 「手続き」はモデルか • 抽象データ型というモデリングパラダイムから見れば “捨て られる” 対象である • しかし、ハードウェアや処理系あるいはコンパイラなどから 見ると、具体的なメモリ管理やOSへの命令などを抽象化し ている “捨てた” のではなく 別のパラダイムに移譲したと捉えられる
29. 設計要素とパラダイム 抽象化によって抽出されるもの 具象となるもの（ “捨て” られるもの） 抽象データ型 型名、メソッド名と引数リスト 型の実装 サブルーチン サブルーチン名、引数リスト 処理内容 関数 関数名、適用対象と結果の型 計算内容 RDB スキーマ定義 結果セットの構造 RESTful API URI、パラメータ、レスポンス内容 利用するプログラミング言語、ミドルウ ェア
30. よりよいモデリングとは • 問題を複数の小さな問題に分割する • 早期決定が必要あるいは可能なものと決定遅延したいものに 分解する • それに適合する最適なモンデリングパラダイムでそれを表現 する
31. 計算モデルとデータモデル
32. 計算モデルとは 『https://ja.wikipedia.org/wiki/計算モデル “計算モデル（model of computation）は、計算・推論・証 明といった行為を論理的・抽象的に考察するための数理モデ ルである。”
33. 要するに？ 『「計算とは ◯◯ である」という問いに答えること』
34. 計算モデル • 抽象機械型計算モデル ◦ チューリングマシン、レジスタマシン、有限オートマトン ◦ 計算とは “状態を変更すること” である • 代入・命令型計算モデル ◦ フローチャート ◦ 計算とは “順番に代入・命令をすること” である • 関数型計算モデル ◦ 帰納的関数、ラムダ計算 ◦ 計算とは “関数を適用すること” である • 論理型計算モデル ◦ 述語論理 ◦ 計算とは “事実集合に問い合わせること” である 『計算モデルとプログラミング』
35. 計算モデルとしてのデータモデル • 一般にデータモデルと呼ばれるものも、それを用いることで 特定の計算を行いやすくなるという意味で計算モデルと考え ることももできる • SQL と Prolog とかとても似てますよね？ね？ • チューリング完全であるとは限らないが… 計算
36. ERモデルとリレーショナルモデルの混同 ≠
38. “The entity-relationship model can be used as a basis for unification of different views of data”
39. リレーショナルモデルとERモデルの混同 • ERモデルは複数のデータモデルの包括的なビューとして提 案された。 • 概念モデル / 分析モデルの類と考えるのが適切である。 • それ自体は計算体系を持たない。
40. ERモデル → リレーショナルモデル 社員番号 名字 名前 所属 社員 部署 社員 番号 名字 名前 部署 番号 部署名 社員番号 部署番号 部署番号 部署名
41. ERモデル → ネットワークモデル 所属 社員 ・社員番号 ・名字 ・名前 部署 ・部署番号 ・部署名 社員 部署 社員 番号 名字 名前 部署 番号 部署名 所属 社員 ・社員番号 ・名字 ・名前 部署 ・部署番号 ・部署名 所属
42. ERモデル → エンティティセットモデル 所属 社員 部署 社員 番号 名字 名前 部署 番号 部署名 社員番号: X 名字: XXX 名前: YYY 部署番号: X 部署名: ZZZ 名字 名前 所属 名前
43. それぞれのデータモデル • リレーショナルモデルの “リレーション” は属性間の関係で あり、柔軟な関係をあとから構築できることが強みである。 • ネットワークモデルはデータレコードをノードとする有向グ ラフと捉えられ、グラフ演算などと相性がよい。 • エンティティセットモデルは EAV (Entity Attribute Value, 『SQLアンチパターン』）というアンチパターンとも考えら れるが、構造を固定化させず柔軟な構造を定義するのに適し ている。
44. 計算モデルとデータモデル まとめ • 現代では多くのプログラミング言語がマルチパラダイムな言 語であると言え、どのようなパラダイムが最適かを常に考え るべきである。 • データモデルおよびその実装であるデータストアの選定も、 それによってどのような計算が可能かを規定するものであり、 適切な選択が必要になる。
45. まとめ • クラスベースオブジェクト指向とメッセージベースオブジェ クト指向の違いについて説明した。 • オブジェクト指向によって抽象化・意思決定遅延された部分 を他のモデリングパラダイムへの移譲と捉え、最適なモデリ ングパラダイムを選択するとよい。 • それぞれのパラダイムの得手・不得手を理解し、最適なモデ ルを選択することが設計者には求められる。
46. ご清聴ありがとうございました。