QCon Tokyo 2016の資料です。 http://www.qcontokyo.com/program.html SlideShare向けにスライドのフォントを変更しました。 画像のフォントは変更できなかったので、空白表示になっています。(対処方法が分かりしだい対応したいと思います。) PDFをDownloadすると文字化けしていないものを読むことができます。

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 "
• 数学/計算機科学の理論が基盤技術に"
– 大規模データ処理"
– 確率・統計"
– 人工知能

7. Functional Programming

8. 関数型プログラミング技術マップ
数理論理学
直観主義
述語論理
抽象代数学
直感主義命題論理＆
自然演繹
単純型付ラムダ計算
純粋関数型言語
命題
型クラス
群論
Hask圏
(プログラム圏)
永続データ構造
関数型言語
手続き型言語
代数的データ型
Curry-Howard-Lambek対応
オブジェクト
指向言語
証明
様相論理
圏論
直積 直和
不変
副作用なし
参照透過性
置換モデル
カルテジアン閉圏
有限直積
トポス(圏)
冪
述語論理
モノイド モナド
型
計算

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 "
• 大規模、高頻度、ストリーミング"
• 数学・計算機科学の理論をソフトウェア部品とし
て活用。

16. Object-Functional
Programming (OFP)

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 Streams
Free Monad Interpreter
I/O

23. まとめ: OFP
• OOPとFPの併用が現実解"
• OOPとFPの協業"
– システム全体の構成はOOP。"
– FPで実現できるところはFP"
– その他はOOP。"

24. Object-Functional Analysis
and Design (OFAD)

25. 関数でやりたいこと
• 数学・計算機科学の理論・概念を直接モデル
として使用したい。"
• OFPとの連続性を担保したい。"
"

26. 外部要因
• Application Cloud Platform (ACP)"
– アプリケーションの基本機能をクラウドプラットフォー
ムとして提供"
• 例: Prefer Cloud Platform (弊社)"
– ほとんどの機能はACPで提供。開発はカスタマイズ
と拡張機能。"
– ビジネス全体を包含したモデリングが重要になる。"
• Domain-Specific Language (DSL)"
– 実行エンジン"
– プログラムの自動生成"

27. オブジェクトモデリング
静的
構造
協調
状態
機械
ドメイン・モデル
アプリケーション
モデル
協調の実装技術
がボトルネックに
なっている

28. 現実世界と科学世界
現実世界 オブジェクト・モデル 関数モデル 科学世界
モノ・コト
モノ・コト
オブジェクト
集合・圏・論理など 理論
集合・圏・論理など 理論オブジェクト
モノ・コト オブジェクト

29. BDOEサイクル
Development
Phase
Phase
Phase
Realization
Realization
Realization
Business Modeling
Development
Operation
Evaluation
Requirement
Analysis/Design
Implementation
Test
Integration Test

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"