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