Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

オブジェクト・関数型プログラミングからオブジェクト・関数型分析設計へ

576 views

Published on

クラウド時代のモデリングを考える

Published in: Engineering
  • Be the first to comment

オブジェクト・関数型プログラミングからオブジェクト・関数型分析設計へ

  1. 1. オブジェクト・関数型プログラミング からオブジェクト・関数型分析設計へ クラウド時代のモデリングを考える 2016年10月24日 QCon Tokyo 2016 浅海智晴 (Everforth)
  2. 2. 自己紹介 • 1985年富士通(株)入社 – UNIXワークステーション/サーバーのOS、分散基盤、Web基盤の開発に従事 • 2001年9月に独立 – Java, XML, UMLを中心に活動 • 2005年4月より2008年3月まで – 稚内北星学園大学東京サテライト校教授 • 現在 – (株) 匠BusinessPlace 取締役チーフコンサルタント – (株) Everforth 取締役CTO • OSS – SmartDoc – Relaxer • 著作 – 上流工程UMLモデリング(日経BP) – マインドマップではじめるモデリング講座(翔泳社) – Relaxer Java/XMLによるWeb開発(ピアソン) – ぼくらのScala(Softbank Creative) http://www.takumi-businessplace.co.jp/ https://prefer.cl/ http://modegramming.blogspot.jp/
  3. 3. App / Web 最適なUXを実現するアプリ/Webサイトを高速開発 Prefer Cloud Platformならオムニチャネル、パーソナライズといったCRO施策を実践するアプリ、Webサイトを高速に開発できます。 また、APIを自由に利用したカスタマイズも際限なくできるので、自社の顧客が求めるニーズを捉えたオリジナルかつ最高のUXを提供することができます。 Communication メール/PUSHを統合配信 チャットにも対応 Prefer Cloud Platformのメッセージ ング機能では、メール/PUSH/独自 メッセージを統合配信できます。 ターゲティング機能を利用して、セ グメントした顧客に最適な情報を最 適な方法で提供することができ、 LTVの向上が図れます。 配信は、メール/PUSHともに100万 通/時間で高速配信が可能です。 また、チャット機能を利用すれば、 ロイヤルカスタマーに対してより丁 寧で密な対応が可能です。 Analytics APIログを正規化して格納 統合的な分析を手軽に実現 Prefer Cloud Platformでは、APIレ ベルのログをすべて正規化し保管 しています。これにより、アプリ、 Webサイト、店舗、メールなど顧 客体験のあらゆるタッチポイント を統合的に分析ができます。 LTVにおけるKPIをレポート表示す るだけでなく、BIを用いた分析も 手軽に実現できるようBI向けの専 用DBも用意しています。 アプリ/Webサイトで利用するため のLike数、Follow数などの集計も汎 用的な基盤で用意されています。 Data Coordination オムニチャネルに不可欠なデータ連携を手軽に実現 Prefer Cloud Platformでは、オムニチャネル施策を進めるときに常に課題となるデータ連携 を容易にすべく、会員、商品、在庫など主立ったデータの連携フォーマットを揃えていま す。定義されたフォーマットでファイルを送るだけでオムニチャネルが実現します。 Optimization MA LTV向上に直結する最適化をテクノロジーで自動化 PUSHをアクセス頻度に合わせてフィルタリングする、顧客をセグメントし最適なコンテン ツ一覧を表示する、最適なタイミングでメッセージを配信する、などLTV向上に不可欠な施 策をPrefer Cloud Platformの独自テクノロジーが自動化して実施します。 Customer Relationship Optimization Application Cloud Platform CROACP
  4. 4. アジェンダ • Functional Programming • Object-Functional Programming • Object-Functional Analysis and Design
  5. 5. 背景(seeds) • 関数型プログラミングの技術革新 – 型クラス • 代数的構造 – モノイド、モナド – モナド(monad) • I/O処理、状態遷移を伴う普通のプログラムを純粋関数型で 記述可能になった – Reactive Streams • 大規模データ、イベント駆動、ストリーミング • Observableモナド(RxJava)、Processモナド(scalaz-stream) • 次の技術革新の土台 – 証明プログラミング
  6. 6. 背景(needs) • 大規模データ処理 – Hadoop/Spark • 高頻度シグナル処理 – IoT • リアクティブ – Reactive Manifesto • http://www.reactivemanifesto.org • 数学/計算機科学の理論が基盤技術に – 大規模データ処理 – 確率・統計 – 人工知能
  7. 7. Functional Programming
  8. 8. 関数型プログラミング技術マップ 数理論理学 直観主義 述語論理 抽象代数学 直感主義命題論理& 自然演繹 単純型付ラ ムダ計算 純粋関数型言語 命題 型ク ラ ス 群論 H ask圏 (プロ グラ ム圏) 永続データ 構造 関数型言語 手続き 型言語 代数的データ 型 Curry-H oward -Lam b ek対応 オブジェ ク ト 指向言語 証明 様相論理 圏論 直積 直和 不変 副作用なし 参照透過性 置換モデル カ ルテジアン 閉圏 有限直積 ト ポス(圏) 冪 述語論理 モノ イ ド モナド 型 計算
  9. 9. 純粋関数型プログラミング • I/Oや状態遷移などの副作用を起こさないプ ログラミング。 • コンパイルが証明になる。 – Curry-Howard対応。 – バグが出にくい。 • モナドの登場によって汎用用途で使用可能に なった。 – ちょっとしたトリックがあるが、その点だけ納得 できれば純粋関数型でI/O、状態遷移が可能にな る。
  10. 10. FPの基本概念 集合X 集合Y 圏X 圏Y 圏X 圏Z 関手 圏X 圏X 圏X 射 射 圏X 圏X 対象 対象 対象 対象 写像/関数 射 関手 対象 対象 射 モナド 集合Y 写像/関数 対象 対象 対象 対象 射 対象 対象 射モナド
  11. 11. 数学的汎用DSL • Stream API – 関手/モナドを使用したパイプラインプログラミ ング (Monadic Programming) – 圏論概念に直接対応した数学的汎用DSL • 一種のマイクロフレームワーク – 数学的計算(写像)を汎用的記述できる(はず) – JavaでもJava 8から導入 • 関手(Functor) • モナド(Monad) val result = source.map(funcA).map(funcB) val result = source.flatMap(funcX).flatMap(funcB)
  12. 12. ソフトウェア部品としての数学 • 群論 – scalaz: Monoid – 将来的には群、環、体なども – 並列・分散では可換(commutative)の性質も重要 • 可換モノイド、可換群 • 圏論 – scalaz: Arrow, Category, Functor, NaturalTransformation • 計算機科学 – scalaz: Monad, Applicative, Traverse, Foldable, State, Reader, Writer, Free/Operational Monad, Lens • 線形代数 – Breeze
  13. 13. The Reactive Manifest • http://www.reactivemanifesto.org/ • 日本語訳 – http://okapies.hateblo.jp/entry/2014/12/03/025921 • Responsive – 応答性:すぐ応答する • Resilient – 耐故障性:回復力に富む、立ち直りが早い • Elastic – 弾力性:伸縮自在の • Message Driven – メッセージ駆動 • 関連: Reactive Streams – http://www.reactive-streams.org/
  14. 14. Reactive Streams • Reactive Streams – http://www.reactive-streams.org/ – 「ノンブロッキング、バックプレッシャー付きの非 同期ストリーム処理」 • FPのメリットを享受しながらI/O処理を記述 – 単なるI/Oだけではなく大規模、高頻度、ストリーミ ングに対応できる • QCon Tokyo 2015 – ScalaによるMonadic Programmingのススメ - Functional Reactive Programmingへのアプローチ • http://qcontokyo.com/tokyo- 2015/ASAMITomoharu_2015.html
  15. 15. まとめ: FP • コンパイルは証明。 – 品質向上。生産性向上。 – リファクタリングが容易。 • 数学的汎用DSLで数学・計算機科学の理論を プログラミングに直結させる。 – Stream API (基本形) – Reactive Stream • 大規模、高頻度、ストリーミング • 数学・計算機科学の理論をソフトウェア部品 として活用。
  16. 16. Object-Functional Programming (OFP)
  17. 17. OOPとFPの インピーダンスミスマッチ • 状態の更新 – OOP • イベント発生→状態の更新が基本 – FP • 状態の更新は不可 • 継承 – OOP • クラス • 実行時に動作するオブジェクトを切替え。(ポリモーフィズム) – FP • 型クラス • コンパイル時にすべてが確定している必要がある。 • 大規模開発 – OOP • コンポーネント – インタフェースを使ったAPI/SPI – FP • 状態を持ったオブジェクト的な機能がないので難しそう(私見)
  18. 18. OOPとFPの関係 • 品質、開発効率 : FP > OOP • 表現力、拡張性 : OOP > FP • FPでは実現できないことがある。 – 状態の更新 – 動的束縛によるポリモーフィズム – 大規模開発(?) • OOPとFPの完全な融合は困難 – ScalaではOOPを主に、紳士協定でFPを可能にす るという選択を行っている。 • OOPとFPの併用が現実解
  19. 19. OOP vs FP I/O実現方式比較 関数 手続き 手続き 手続き 手続き DB 関数 関数 関数 関数 関数 関数 関数 OOP方式 FP方式 DB イ ンタ ープリ タ ー データ データ データ データ コ ンソ ール コ ンソ ール
  20. 20. オブジェクトと関数の連携 オブジェ ク ト 指向 関数型 オブジェ ク ト 指向 関数 手続き 状態 オブジェ ク ト 値 関数 手続き 状態 オブジェ ク ト 代数的 データ 型 データ 構造 永続 データ 構造 関数 手続き 状態 オブジェ ク ト 値 関数 手続き 状態 オブジェ ク ト 値 データ 構造 データ 構造
  21. 21. オブジェクトと関数:適材適所 • システム全体の構成はOOP • FPで実現できるところはFP – 数学・計算機科学の理論の実装 – アルゴリズム的な計算 – I/Oや状態を持つ機能でもStream APIやReactive Streamsで実現できるものはFP • 「モナドのトリック」をOOPで実現 – Operational(Free)モナドのインタープリタ(自然 変換として実装)をOOPで実現 • その他の処理はOOP
  22. 22. OOPとFPの協業 OOP FP OOP FP FP OOP I/O I/O Reactive Stream s Free M onad Interpreter I/O
  23. 23. まとめ: OFP • OOPとFPの併用が現実解 • OOPとFPの協業 – システム全体の構成はOOP。 – FPで実現できるところはFP – その他はOOP。
  24. 24. Object-Functional Analysis and Design (OFAD)
  25. 25. 関数でやりたいこと • 数学・計算機科学の理論・概念を直接モ デルとして使用したい。 • OFPとの連続性を担保したい。
  26. 26. 外部要因 • Application Cloud Platform (ACP) – アプリケーションの基本機能をクラウドプラット フォームとして提供 • 例: Prefer Cloud Platform (弊社) – ほとんどの機能はACPで提供。開発はカスタマイ ズと拡張機能。 – ビジネス全体を包含したモデリングが重要になる。 • Domain-Specific Language (DSL) – 実行エンジン – プログラムの自動生成
  27. 27. オブジェクトモデリング 静的 構造 協調 状態 機械 ドメイン・モデル アプリケーション モデル 協調の実装技術 がボトルネック になっている
  28. 28. 現実世界と科学世界 現実世界 オブジェ ク ト ・ モデル 関数モデル 科学世界 モノ ・ コ ト モノ ・ コ ト オブジェ ク ト 集合・ 圏・ 論理など 理論 集合・ 圏・ 論理など 理論オブジェ ク ト モノ ・ コ ト オブジェ ク ト
  29. 29. BDOEサイクル Development Phase Phase Phase Realization Realization Realization Business Modeling Development Operation Evaluation Requirement Analysis/Design Implementation Test Integration Test
  30. 30. 開発運営 Realization Presentation Service Extension Configuration Plan-DrivenAgile Iteration Iteration Iteration Requirement UX Design ImplementationTest Integration Test Analysis/ Design Implementation Test Implementation Test
  31. 31. モデル体系 Business Process Model IT System Model Domain Model Vision/Value/Goal Business UseCase/UX UseCase/UX Business Flow Collaboration Responsibility Entity State Machine Relationship Context Map Bounded Context Business Rule Class/Object State Machine System/SubSystem State Machine Module/Component State Machine Dataflow Business Workflow
  32. 32. Functional的なモデル • オブジェクトモデル – EntityとRelationshipによるドメイン構造 • 集合、圏論 – EntityやObjectのState Machine • オートマトン • 宣言的モデル – Business Workflow • State Machine – Business Rule • 述語、関数、数理論理学 – Dataflow • 集合・写像、圏論 • OMT第1版ではオブジェクトモデルとして使用されていた
  33. 33. モデル変換戦略 Analysis Model Design Model Implementation/Operatio Object Model Functional Model Static Structure State Machine Collaboration Business Rule Dataflow Program Generator Business Workflow Object Model Functional Programming Object-Oriented Programming DSL DSL Engine Functional Model
  34. 34. まとめ: OFAD • Functional的なモデルを一級モデルとして 考える。 – 広義の解釈として関数モデルとみなす。 • 関数モデルはできるだけDSL化を目指す – DSLエンジンで実行 – プログラムの自動生成 • 可能なものは関数モデル→FPを目指す。 • Collaborationの所でOOPが残る。
  35. 35. まとめ • FPの技術革新 – 型クラス、モナド、Reactive Streams • クラウド・アプリケーションがやりたい こと – 大規模、高頻度、ストリーミング • OFP – OOPとFPの協業 • OFAD – 関数モデル→DSL

×