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

Transcript

1. 異なるモデリングパラダイムから見る
   モデリングの勘所
   2020/02/16 Object-Oriented Conference
   末並 晃 @a_suenami
   

   View Slide

2. 自己紹介
   ● 末並 晃 @a_suenami
   ● 生息している界隈: DDDとか、TDDとか、RDBとか
   ● お仕事で使ってる技術スタック: Rails, React, Java, PHP
   ● 好きな RDBMS: PostgreSQL
   ● 好きな制約: チェック制約
   ● 好きな焼肉の部位: ハラミ
   ● 好きな（ｒｙ
   

   View Slide

3. インターネット上での立場
   

   View Slide

4. インターネット上での立場
   殺伐としたインターネットの世界へ、
   ただただ焼肉をタカられるという
   エンターテイメントを提供しています。
   

   View Slide

5. 今日話すこと
   ● オブジェクト指向とは何か
   ● クラスベースオブジェクト指向
   ● メッセージベースオブジェクト指向
   ● オブジェクト以外のモデリングとマルチパラダイムでのモデ
   リングについて
   ● 計算モデルとデータモデル
   

   View Slide

6. オブジェクトとは
   

   View Slide

7. 2つのオブジェクト指向
   ● クラスベースのオブジェクト指向
   ○ 抽象データ型のスーパーセット
   ○ モジュール化/データ抽象の手段としてユーザ定義型を利
   用する
   ○ 現在よく知られているのはおそらくこちら
   ● メッセージベースのオブジェクト指向
   ○ オブジェクト同士がメッセージを送る（メッセージパッ
   シング）のをプログラミングの基本とするという考え方
   ○ 徹底的な動的性、遅延結合、メタプログラミングなどを
   特徴とする
   

   View Slide

8. クラスベースオブジェクト指向
   

   View Slide

9. 歴史を振り返る
   構造化プログラミング モジュラープログラミング
   データ抽象
   抽象データ型
   クラス
   

   View Slide

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
    #include
    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章 オブジェクト指向プログラミング
    

    View Slide

11. データ抽象とその手段としての抽象データ型
    ● 抽象データ型とは、データ抽象を実現する手段のひとつとし
    て提案され、その具体的実装としてクラスが多くの機能に導
    入された。
    ● クラスとはモジュール化の手法のひとつと言える。
    ● つまり、クラスベースのオブジェクト指向におけるソフトウ
    ェア構築は、抽象データ型の構造化された集合としてシステ
    ムを構築することである。
    

    View Slide

12. データ構造とアルゴリズムの隠蔽
    モジュール
    モジュール
    モジュール
    モジュール
    モジュール
    モジュール
    抽象の世界 実際のデータ構造/アルゴリズムの世界
    実装
    実装
    実装
    実装
    実装
    実装
    隠蔽・可換
    

    View Slide

13. メッセージベースオブジェクト指向
    

    View Slide

14. Smalltalk
    

    View Slide

15. Smalltalk
    ● メッセージベースのオブジェクト指向を体現するプログラ
    ミング言語として（おそらく）もっとも有名な言語。
    ○ 言語というか処理系というほうが適切かも…？
    ● Smalltalk-72, Smalltalk-76 など複数の処理系がある。
    ● 徹底的な動的性と遅延結合にこだわり、誰もが自分のため
    にプログラミングできることを目指した。
    ○ パーソナルコンピューティング
    

    View Slide

16. メッセージパッシングを支える特徴
    ● メッセージ解釈の動的性と遅延結合
    ○ メッセージの解釈は実行時にレシーバーによって行われ
    る
    ○ Smalltalk 処理系では実行時に解釈できないメッセージ
    があった場合、処理を中断してその実装を書ける
    ■ これは実行 “後” まで結合を遅延していると言えるの
    では…？
    

    View Slide

17. レシーバーによる実行時解釈（Rubyの例）
    

    View Slide

18. 処理の中断とレシーバーの実装
    

    View Slide

19. メッセージパッシングを支える特徴
    ● オブジェクトの独立性
    ○ あるオブジェクトの変更が他のオブジェクトに影響しな
    い
    ○ レシーバーがメッセージを解釈できなくても送信元には
    影響しない
    ● Earlang はオブジェクト指向？
    ○ これらの特徴を兼ね備えている（らしい）
    

    View Slide

20. メッセージ >= オブジェクト >> クラス
    クラスやメソッドという概念は
    実行パフォーマンスのため（だけ）に存在する
    

    View Slide

21. ここまでのまとめ
    ● オブジェクト指向にもいろいろあり、似たような機能（ク
    ラス、メソッドなど）はあるものの、背景にある思想はま
    ったく違う。
    ● 現代ではほとんどのプログラミング言語がクラスベースで
    ある。
    ● クラスベースのオブジェクト指向は型システムによる全体
    構造の早期結合と実装の遅延/可換性、メッセージベースの
    オブジェクト指向は動的型付けとメタプログラミングによ
    る遅延結合を特徴とする。
    

    View Slide

22. メッセージベースOOから何を学ぶべきか
    ● メッセージパッシングと遅延結合というコンセプトはとて
    もよいアイデアである
    ● 現代ではシステムアーキテクチャの文脈でのほうがそのア
    イデアを活かせることが多いのではないか
    ○ Pub/Sub
    ○ キューイング / 非同期処理
    ○ ロギング
    

    View Slide

23. 意思決定の遅延
    ● いずれにしても何らかの意思決定を遅延するためのアイデ
    アである
    ● 具体的な実装を検討する場合にはオブジェクトというアイ
    デアとは別の異なるモデリング手法が必要になる
    ● “オブジェクトパラダイム自身がこれまでに登場してきたパ
    ラダイムの混合物である” （『マルチパラダイムデザイン
    』）
    

    View Slide

24. マルチパラダイム・モデリング
    モジュール
    モジュール
    モジュール
    モジュール
    モジュール
    モジュール
    抽象の世界 実際のデータ構造/アルゴリズムの世界
    関数適用
    関数合成
    関係演算
    （SQL）
    グラフ演算
    手続き処理
    有限オートマトン
    etc…
    

    View Slide

25. よいモデリングとは何か
    

    View Slide

26. モデルとは
    https://speakerdeck.com/a_suenami/moderutohahe-deatute-he-denaifalseka-number-kichijojipm
    

    View Slide

27. モデルとは
    つまり、モデリングとは何を重要な情報と扱い
    何を捨てるかを決めること
    

    View Slide

28. 思考実験: 「手続き」はモデルか
    ● 抽象データ型というモデリングパラダイムから見れば “捨て
    られる” 対象である
    ● しかし、ハードウェアや処理系あるいはコンパイラなどから
    見ると、具体的なメモリ管理やOSへの命令などを抽象化し
    ている
    “捨てた” のではなく
    別のパラダイムに移譲したと捉えられる
    

    View Slide

29. 設計要素とパラダイム
    抽象化によって抽出されるもの 具象となるもの（ “捨て” られるもの）
    抽象データ型 型名、メソッド名と引数リスト 型の実装
    サブルーチン サブルーチン名、引数リスト 処理内容
    関数 関数名、適用対象と結果の型 計算内容
    RDB スキーマ定義 結果セットの構造
    RESTful API
    URI、パラメータ、レスポンス内容 利用するプログラミング言語、ミドルウ
    ェア
    

    View Slide

30. よりよいモデリングとは
    ● 問題を複数の小さな問題に分割する
    ● 早期決定が必要あるいは可能なものと決定遅延したいものに
    分解する
    ● それに適合する最適なモンデリングパラダイムでそれを表現
    する
    

    View Slide

31. 計算モデルとデータモデル
    

    View Slide

32. 計算モデルとは
    『https://ja.wikipedia.org/wiki/計算モデル
    “計算モデル（model of computation）は、計算・推論・証
    明といった行為を論理的・抽象的に考察するための数理モデ
    ルである。”
    

    View Slide

33. 要するに？
    『「計算とは ◯◯ である」という問いに答えること』
    

    View Slide

34. 計算モデル
    ● 抽象機械型計算モデル
    ○ チューリングマシン、レジスタマシン、有限オートマトン
    ○ 計算とは “状態を変更すること” である
    ● 代入・命令型計算モデル
    ○ フローチャート
    ○ 計算とは “順番に代入・命令をすること” である
    ● 関数型計算モデル
    ○ 帰納的関数、ラムダ計算
    ○ 計算とは “関数を適用すること” である
    ● 論理型計算モデル
    ○ 述語論理
    ○ 計算とは “事実集合に問い合わせること” である
    『計算モデルとプログラミング』
    

    View Slide

35. 計算モデルとしてのデータモデル
    ● 一般にデータモデルと呼ばれるものも、それを用いることで
    特定の計算を行いやすくなるという意味で計算モデルと考え
    ることももできる
    ● SQL と Prolog とかとても似てますよね？ね？
    ● チューリング完全であるとは限らないが…
    計算
    

    View Slide

36. ERモデルとリレーショナルモデルの混同
    ≠
    

    View Slide

37. View Slide

38. “The entity-relationship model can be used as a basis for
    unification of different views of data”
    

    View Slide

39. リレーショナルモデルとERモデルの混同
    ● ERモデルは複数のデータモデルの包括的なビューとして提
    案された。
    ● 概念モデル / 分析モデルの類と考えるのが適切である。
    ● それ自体は計算体系を持たない。
    

    View Slide

40. ERモデル → リレーショナルモデル
    社員番号 名字 名前
    所属
    社員
    部署
    社員
    番号
    名字
    名前
    部署
    番号
    部署名
    社員番号 部署番号
    部署番号 部署名
    

    View Slide

41. ERモデル → ネットワークモデル
    所属
    社員
    ・社員番号
    ・名字
    ・名前
    部署
    ・部署番号
    ・部署名
    社員
    部署
    社員
    番号
    名字
    名前
    部署
    番号
    部署名
    所属
    社員
    ・社員番号
    ・名字
    ・名前
    部署
    ・部署番号
    ・部署名
    所属
    

    View Slide

42. ERモデル → エンティティセットモデル
    所属
    社員
    部署
    社員
    番号
    名字
    名前
    部署
    番号
    部署名
    社員番号: X 名字: XXX
    名前: YYY
    部署番号: X 部署名: ZZZ
    名字
    名前
    所属
    名前
    

    View Slide

43. それぞれのデータモデル
    ● リレーショナルモデルの “リレーション” は属性間の関係で
    あり、柔軟な関係をあとから構築できることが強みである。
    ● ネットワークモデルはデータレコードをノードとする有向グ
    ラフと捉えられ、グラフ演算などと相性がよい。
    ● エンティティセットモデルは EAV (Entity Attribute Value,
    『SQLアンチパターン』）というアンチパターンとも考えら
    れるが、構造を固定化させず柔軟な構造を定義するのに適し
    ている。
    

    View Slide

44. 計算モデルとデータモデル まとめ
    ● 現代では多くのプログラミング言語がマルチパラダイムな言
    語であると言え、どのようなパラダイムが最適かを常に考え
    るべきである。
    ● データモデルおよびその実装であるデータストアの選定も、
    それによってどのような計算が可能かを規定するものであり、
    適切な選択が必要になる。
    

    View Slide

45. まとめ
    ● クラスベースオブジェクト指向とメッセージベースオブジェ
    クト指向の違いについて説明した。
    ● オブジェクト指向によって抽象化・意思決定遅延された部分
    を他のモデリングパラダイムへの移譲と捉え、最適なモデリ
    ングパラダイムを選択するとよい。
    ● それぞれのパラダイムの得手・不得手を理解し、最適なモデ
    ルを選択することが設計者には求められる。
    

    View Slide

46. ご清聴ありがとうございました。
    

    View Slide