オブジェクト・関数型プログラミングからオブジェクト・関数型分析設計へ
•Download as PPTX, PDF•
2 likes•1,451 views
クラウド時代のモデリングを考える
Recommended
Recommended
More Related Content
What's hot
Viewers also liked
Similar to オブジェクト・関数型プログラミングからオブジェクト・関数型分析設計へ
Similar to オブジェクト・関数型プログラミングからオブジェクト・関数型分析設計へ (20)
オブジェクト・関数型プログラミングからオブジェクト・関数型分析設計へ
- 1. オブジェクト・関数型プログラミング からオブジェクト・関数型分析設計へ クラウド時代のモデリングを考える 2016年10月24日 QCon Tokyo 2016 浅海智晴 (Everforth)
- 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. 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. アジェンダ • Functional Programming • Object-Functional Programming • Object-Functional Analysis and Design
- 5. 背景(seeds) • 関数型プログラミングの技術革新 – 型クラス • 代数的構造 – モノイド、モナド – モナド(monad) • I/O処理、状態遷移を伴う普通のプログラムを純粋関数型で 記述可能になった – Reactive Streams • 大規模データ、イベント駆動、ストリーミング • Observableモナド(RxJava)、Processモナド(scalaz-stream) • 次の技術革新の土台 – 証明プログラミング
- 6. 背景(needs) • 大規模データ処理 – Hadoop/Spark • 高頻度シグナル処理 – IoT • リアクティブ – Reactive Manifesto • http://www.reactivemanifesto.org • 数学/計算機科学の理論が基盤技術に – 大規模データ処理 – 確率・統計 – 人工知能
- 8. 関数型プログラミング技術マップ 数理論理学 直観主義 述語論理 抽象代数学 直感主義命題論理＆ 自然演繹 単純型付ラ ムダ計算 純粋関数型言語 命題 型ク ラ ス 群論 H ask圏 (プロ グラ ム圏) 永続データ 構造 関数型言語 手続き 型言語 代数的データ 型 Curry-H oward -Lam b ek対応 オブジェ ク ト 指向言語 証明 様相論理 圏論 直積 直和 不変 副作用なし 参照透過性 置換モデル カ ルテジアン 閉圏 有限直積 ト ポス(圏) 冪 述語論理 モノ イ ド モナド 型 計算
- 9. 純粋関数型プログラミング • I/Oや状態遷移などの副作用を起こさないプ ログラミング。 • コンパイルが証明になる。 – Curry-Howard対応。 – バグが出にくい。 • モナドの登場によって汎用用途で使用可能に なった。 – ちょっとしたトリックがあるが、その点だけ納得 できれば純粋関数型でI/O、状態遷移が可能にな る。
- 10. FPの基本概念 集合X 集合Y 圏X 圏Y 圏X 圏Z 関手 圏X 圏X 圏X 射 射 圏X 圏X 対象 対象 対象 対象 写像/関数 射 関手 対象 対象 射 モナド 集合Y 写像/関数 対象 対象 対象 対象 射 対象 対象 射モナド
- 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. ソフトウェア部品としての数学 • 群論 – scalaz: Monoid – 将来的には群、環、体なども – 並列・分散では可換(commutative)の性質も重要 • 可換モノイド、可換群 • 圏論 – scalaz: Arrow, Category, Functor, NaturalTransformation • 計算機科学 – scalaz: Monad, Applicative, Traverse, Foldable, State, Reader, Writer, Free/Operational Monad, Lens • 線形代数 – Breeze
- 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. 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. まとめ: FP • コンパイルは証明。 – 品質向上。生産性向上。 – リファクタリングが容易。 • 数学的汎用DSLで数学・計算機科学の理論を プログラミングに直結させる。 – Stream API (基本形) – Reactive Stream • 大規模、高頻度、ストリーミング • 数学・計算機科学の理論をソフトウェア部品 として活用。
- 17. OOPとFPの インピーダンスミスマッチ • 状態の更新 – OOP • イベント発生→状態の更新が基本 – FP • 状態の更新は不可 • 継承 – OOP • クラス • 実行時に動作するオブジェクトを切替え。(ポリモーフィズム) – FP • 型クラス • コンパイル時にすべてが確定している必要がある。 • 大規模開発 – OOP • コンポーネント – インタフェースを使ったAPI/SPI – FP • 状態を持ったオブジェクト的な機能がないので難しそう(私見)
- 18. OOPとFPの関係 • 品質、開発効率 : FP > OOP • 表現力、拡張性 : OOP > FP • FPでは実現できないことがある。 – 状態の更新 – 動的束縛によるポリモーフィズム – 大規模開発(?) • OOPとFPの完全な融合は困難 – ScalaではOOPを主に、紳士協定でFPを可能にす るという選択を行っている。 • OOPとFPの併用が現実解
- 19. OOP vs FP I/O実現方式比較 関数 手続き 手続き 手続き 手続き DB 関数 関数 関数 関数 関数 関数 関数 OOP方式 FP方式 DB イ ンタ ープリ タ ー データ データ データ データ コ ンソ ール コ ンソ ール
- 20. オブジェクトと関数の連携 オブジェ ク ト 指向 関数型 オブジェ ク ト 指向 関数 手続き 状態 オブジェ ク ト 値 関数 手続き 状態 オブジェ ク ト 代数的 データ 型 データ 構造 永続 データ 構造 関数 手続き 状態 オブジェ ク ト 値 関数 手続き 状態 オブジェ ク ト 値 データ 構造 データ 構造
- 21. オブジェクトと関数：適材適所 • システム全体の構成はOOP • FPで実現できるところはFP – 数学・計算機科学の理論の実装 – アルゴリズム的な計算 – I/Oや状態を持つ機能でもStream APIやReactive Streamsで実現できるものはFP • 「モナドのトリック」をOOPで実現 – Operational(Free)モナドのインタープリタ(自然 変換として実装)をOOPで実現 • その他の処理はOOP
- 22. OOPとFPの協業 OOP FP OOP FP FP OOP I/O I/O Reactive Stream s Free M onad Interpreter I/O
- 23. まとめ: OFP • OOPとFPの併用が現実解 • OOPとFPの協業 – システム全体の構成はOOP。 – FPで実現できるところはFP – その他はOOP。
- 24. Object-Functional Analysis and Design (OFAD)
- 26. 外部要因 • Application Cloud Platform (ACP) – アプリケーションの基本機能をクラウドプラット フォームとして提供 • 例: Prefer Cloud Platform (弊社) – ほとんどの機能はACPで提供。開発はカスタマイ ズと拡張機能。 – ビジネス全体を包含したモデリングが重要になる。 • Domain-Specific Language (DSL) – 実行エンジン – プログラムの自動生成
- 28. 現実世界と科学世界 現実世界 オブジェ ク ト ・ モデル 関数モデル 科学世界 モノ ・ コ ト モノ ・ コ ト オブジェ ク ト 集合・ 圏・ 論理など 理論 集合・ 圏・ 論理など 理論オブジェ ク ト モノ ・ コ ト オブジェ ク ト
- 30. 開発運営 Realization Presentation Service Extension Configuration Plan-DrivenAgile Iteration Iteration Iteration Requirement UX Design ImplementationTest Integration Test Analysis/ Design Implementation Test Implementation Test
- 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. Functional的なモデル • オブジェクトモデル – EntityとRelationshipによるドメイン構造 • 集合、圏論 – EntityやObjectのState Machine • オートマトン • 宣言的モデル – Business Workflow • State Machine – Business Rule • 述語、関数、数理論理学 – Dataflow • 集合・写像、圏論 • OMT第1版ではオブジェクトモデルとして使用されていた
- 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. まとめ: OFAD • Functional的なモデルを一級モデルとして 考える。 – 広義の解釈として関数モデルとみなす。 • 関数モデルはできるだけDSL化を目指す – DSLエンジンで実行 – プログラムの自動生成 • 可能なものは関数モデル→FPを目指す。 • Collaborationの所でOOPが残る。
- 35. まとめ • FPの技術革新 – 型クラス、モナド、Reactive Streams • クラウド・アプリケーションがやりたい こと – 大規模、高頻度、ストリーミング • OFP – OOPとFPの協業 • OFAD – 関数モデル→DSL
Editor's Notes
- FPだけだと書けないことがある