Universidade Federal de Pernambuco

Centro de Informatica

CEPCombine: Uma biblioteca para o Processamento de

Eventos Complexos em Swift

Trabalho de Conclusao de Curso de Graduacao

por

Isaac Douglas Rodrigues do Nascimento

Orientador: Prof. Kiev Santos da Gama

Recife, Dezembro / 2019

Isaac Douglas Rodrigues do Nascimento

CEPCombine: Uma biblioteca para o Processamento de Eventos Complexos

em Swift

Trabalho apresentado ao Programa deGraduacao em Ciencia da Computacaodo Centro de Informatica da UniversidadeFederal de Pernambuco como requisitoparcial para obtencao do grau de Bacharelem Ciencia da Computacao.

Orientador: Prof. Kiev Santos da Gama

Recife

2019

Agradecimentos

Agradeco primeiramente a Deus que me deu forcas para lutar e chegar ate aqui,

por todas as oportunidades que Ele me deu, mesmo nao merecendo. A minha famılia que

sempre me deu apoio e nunca deixaram de me incentivar nos estudos, sem eles nao esta-

ria aqui hoje, e tambem a minha namorada Giselli, companheira e amiga que me apoia

desde o inicio em tudo que faco, e aos meu amigos mais proximos Bruno e Wellington que

participaram ativamente da minha vida academica e tambem na pessoal e mostraram que

cada segundo de uma virada de noite e importante, e que posso contar com eles sempre.

Agradeco tambem ao projeto BEPID e aos professores, que juntos mudaram minha forma

de pensar para melhor, e tracou o inicio da minha carreira profissional de desenvolvedor.

Quero mudar o mundo

Cruzar os ceus e nada temer.

“Mudar o Mundo” (Inuyasha)

RESUMO

A cada dia que passa, surgem novos sistemas que possuem a necessidade do tratamento

em tempo real dos dados, geralmente esses dados vem de uma fonte de fluxo continuo.

Os dados gerados podem ser originados de varias fontes, tais como dados oriundos de

conexoes de rede, dados sensores ou ate mesmo de elementos interativos de uma interface

grafica (campos de texto, posicao atual do cursor etc.). Uma forma de trabalhar com esses

dados e usando uma arquitetura orientada a eventos, este trabalho aborda um ramo dessa

arquitetura, o Processamento de Eventos Complexos, pois tratar esses dados isoladamente

nem sempre pode significar algo, mas combinando esses dados o poder de detectar padroes

aumenta. O Processamento de Eventos Complexos surge a partir da ideia de combinar

dados das diversas fontes e criar regras para a deteccao de comportamentos em alto nıvel,

o que nao seria possıvel visualizando os dados isolados. Este trabalho propoe a criacao de

uma biblioteca para o Processamento de Eventos Complexos chamada de CEPCombine,

baseado no framework Combine e escrito em Swift.

Palavras-chave: EDA; Processamento de Eventos Complexos; CEPSwift; CEPCombine;

Combine; RLs

ABSTRACT

New systems that need to process data in real time emerge every day. Usually this

data comes from a continuous stream source. The data generated have its origin from

various sources such as network connections, sensor data or even interactive elements

of a graphical interface (text fields, current cursor position, etc). One way of working

with this data is by using an Event-driven architecture. This paper addresses a branch

of this architecture called Complex Event Processing, because handling data in isolation

may not always mean anything, but combining pieces of data increases the power of

pattern detection. Complex Event Processing comes from the idea of combining pieces

of data from various sources and creating rules for detecting high-level behaviors that

would not be possible by observing data separately. This paper proposes the creation of a

Complex Event Processing library called CEPCombine, based on the Combine framework

and written in Swift.

Keywords: EDA; Complex Event Processing; CEPSwift; CEPCombine; Combine; RLs

LISTA DE FIGURAS

Figura 1 Fluxo do processamento de evento simples e suas camadas [1]. . . . . . . . . . . . . 15

Figura 2 Componentes de um evento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Figura 3 Deteccao de fogo por meio de um sistema CEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figura 4 Classe que representa o evento de localizacao (CEPCombine) . . . . . . . . . . . . . . 33

Figura 5 Classe que representa o evento de pedometro (CEPCombine) . . . . . . . . . . . . . . 34

Figura 6 Criacao dos eventos e lancamento no gerenciador de eventos (CEPCom-

bine) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Figura 7 Definicao das regras utilizadas (CEPCombine) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Figura 8 Classe que representa o evento de localizacao (CEPSwift) [2] . . . . . . . . . . . . . . 35

Figura 9 Classe que representa o evento de pedometro (CEPSwift) [2] . . . . . . . . . . . . . . 36

Figura 10 Criacao dos eventos e lancamento no Gerenciador de eventos (CEPSwift) [2] 36

Figura 11 Definicao das regras (CEPSwift) [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Figura 12 Representa os lados que o aparelho esta inclinado. . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Figura 13 Classe que representa o evento do sentido que o celular esta inclinado

(CEPCombine) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Figura 14 Classe que representa o evento de inclinacao (CEPCombine). . . . . . . . . . . . . . . 38

Figura 15 Classes que representam os eventos de sentido de inclinacao (A) e o

evento de inclinacao (B) (CEPSwift) [3]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Figura 16 Criacao do evento de inclinacao quando o sensor notifica (CEPCombine) . 39

Figura 17 Recebe os dados de inclinacao e cria o evento respectivo (CEPSwift) [3] . . 39

Figura 18 Mostra os dados de inclinacao na tela (CEPSwift) [3]. . . . . . . . . . . . . . . . . . . . . . . 39

Figura 19 Definicao das regras utilizadas no jogo Genius (CEPCombine). . . . . . . . . . . . . 40

Figura 20 Definicao das regras utilizadas no jogo Genius (CEPSwift) . . . . . . . . . . . . . . . . . 41

Figura 21 Criacao dos eventos de localizacao e pedometro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Figura 22 Definicao das regras utilizadas na deteccao de caminhada (A) . . . . . . . . . . . . . 42

Figura 23 Definicao das regras utilizadas na deteccao de caminhada (B) . . . . . . . . . . . . . 43

Figura 24 Criacao do evento de inclinacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Figura 25 Definicao das regras utilizadas no jogo Genius (A) . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Figura 26 Definicao das regras utilizadas no jogo Genius (B) . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Figura 27 Grafico da quantidade de funcoes/metodos chamados por biblioteca . . . . . . 47

LISTA DE TABELAS

Tabela 1 Operadores unarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Tabela 2 Operadores logicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Tabela 3 Operadores de janela. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Tabela 4 Operadores de fluxo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Tabela 5 Operadores de agregacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Tabela 6 Funcoes implementadas (A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Tabela 7 Funcoes implementadas (B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Tabela 8 Comparativo entre CEPSwift, CEPCombine e Combine . . . . . . . . . . . . . . . . . . . . 46

LISTA DE CODIGOS

3.1 Protocolo CBEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Extensao do Protocolo CBEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3 Classe CBEventManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4 Classe CBEventStream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5 Extensao Publisher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

LISTA DE SIGLAS

CEP Complex Event Processing

EDA Event-Driven Architecture

IDE Integrated Development Environment

RL Reactive Languages

SUMARIO

1 INTRODUCAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 CONTEXTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1 Arquitetura orientada a eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Evento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Processamento de Eventos Complexos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 Programacao Reativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4.1 Combine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5 Abordagem Reativa com CEP .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.6 Operadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.7 Usos e aplicacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 PROPOSTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 CEPCombine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Analise das funcoes implementadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.1 Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.2 CBEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.3 CBEventManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.4 CBEventStream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.5 Publisher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 CASO DE USO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1 Deteccao de caminhada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 Jogo Genius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3 Combine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3.1 Deteccao de caminhada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3.2 Jogo Genius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.4 Comparacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5 CONSIDERACOES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

12

1 INTRODUCAO

Atualmente existe um grande crescimento de sistemas que necessitam de um pro-

cessamento contınuo de dados, podendo ser originados em locais ou fontes diferentes [4].

Os dados gerados podem ser tratados em uma arquitetura orientada a eventos ou do ingles

(Event-Driven Architecture, EDA) e, nessa arquitetura, os dados podem ser encapsulados

em eventos que e descrito como um acontecimento notavel disseminado a todas as partes

interessadas imediatamente [1]. As partes interessadas sao notificadas por meio de uma

assinatura realizada a partir do fluxo dos dados de entrada, que sao processados item

por item, de acordo com um conjunto de regras como aplicacao de filtros, combinacoes,

agregacoes, podendo gerar novos fluxos [1].

Atualmente existem diferentes abordagens para o cenario de processamento de

dados contınuos, como a programacao reativa ou do ingles (Reactive Languages, RL),

bibliotecas reativas, Processamento de Eventos Complexos ou do ingles (Complex Event

Processing, CEP) que e um estilo de EDA e tambem abordagens que unem tanto CEP

quanto RLs como mostrado em [5] com o CEP.js.

No CEP o poder de processamento cresce de forma expressiva, pois comeca a

considerar padroes de eventos mais complexos que envolvem a ocorrencia de diversos

eventos relacionados [4]. Um exemplo de abordagem e em sistemas de gerenciamento de

trafego como [6] descreve, onde precisa analisar milhoes de eventos contınuos originados de

sensores e veıculos, para detectar problemas e acionar as solucoes adequadas. [7] identifica

alguns estilos de linguagem para o CEP, um exemplo sao as Data Stream Query Languages

como e o caso do Esper [8] que utiliza regras definidas por consultas no banco de dados,

tambem existe as Logic Languages que podem se beneficiar com conceitos funcionais e

orientacao a objetos para definir as regras, essa ultima costuma ser mais intuitiva para o

desenvolvimento das regras, diferente das Query Languages que pode ser em um primeiro

momento nao intuitivo para quem nao tem experiencia em linguagens no estilo banco de

dados.

1.1 Objetivos

O presente trabalho propoe uma biblioteca baseado no Combine [9], que e um fra-

mework reativo, e por cima dele criar uma camada de extensao aplicando conceitos do

13

CEP. Chamada de CEPCombine a biblioteca vai ser desenvolvida em Swift uma lingua-

gem orientada a objetos de facil compreensao [10], para facilitar a definicao das regras

tambem vai ser adicionado um subconjunto de funcionalidades descritas em [4], assim

possibilitando trabalhar com Processamento de Eventos Complexos. Alem disso sera

implementado casos de uso nas bibliotecas CEPCombine, CEPSwift e Combine, com o

proposito de comparar alguns pontos, como vantagens e desvantagens.

14

2 CONTEXTO

Para a contextualizacao dos temas presente neste trabalho, este capıtulo vai abor-

dar uma breve explicacao sobre eventos, arquitetura orientada a eventos, programacao

reativa e por fim fazer uma pequena analise de como as bibliotecas de processamento de

eventos funcionam, como exemplo citar CEPSwift e Combine. Tambem vai ser necessario

mostrar a contextualizacao do subconjunto das funcoes implementadas em cada uma das

bibliotecas.

2.1 Arquitetura orientada a eventos

Em uma arquitetura orientada a eventos, pequenos acontecimentos pode ocorrer

dentro ou fora do escopo observado, esses acontecimentos sao imediatamente encaminha-

dos aos interessados [1]. Um modelo de aplicacao bastante utilizada e para a leitura

dos dados fornecidos por sensores, pelo fato de tanto a arquitetura quanto os sensores

trabalhar em tempo real, como exemplo podemos ter um sistema que analisa se o smart-

fone esta em modo paisagem ou retrato, para esse sistema funcionar satisfatoriamente ele

precisa dos dados do sensor de acelerometro em tempo real, possibilitando perceber se o

smartfone esta sendo segurado de uma forma ou outra, adaptando o conteudo da tela.

Desde a geracao do evento ate a entrega das notificacoes, a arquitetura orientada a

eventos passa por camadas que sao divididas para poder ter responsabilidades separadas

[1].

• Event generator: Os eventos sao gerados a partir de uma fonte, que pode ser

sensores, banco de dados, aplicativos entre outros, com a variedade dos tipos de

fontes as vezes e necessario processar os dados antes de publicar no canal de eventos.

• Event channel: O canal de eventos e normalmente a camada mais importante,

ela transporta os eventos formatados entre o gerador de evento e os mecanismos de

processamento e notificacao.

• Event processing: Na camada de processamento de eventos, logo apos o rece-

bimento, os eventos sao avaliados de acordo com as regras e acoes definidas pelas

partes interessadas. As acoes podem incluir chamada de servicos, geracoes de novos

15

eventos ou armazenar os eventos para registros. Os eventos podem ser processa-

dos independentemente se for por meio de operadores simples, ou complexo por

considerar ocorrencias de eventos atuais com eventos anteriores e futuros.

• Downstream event-drive activity: Um unico evento, ou eventos relacionados,

podem desencadear varias atividades com a sua ocorrencia, essas atividades pode

ser a notificacao do ocorrido para as partes interessadas.

Figura 1: Fluxo do processamento de evento simples e suas camadas [1].

2.2 Evento

Evento pode ser descrito como um acontecimento que esta em constante observacao

por quem esta interessado nessa informacao. Exemplos dessa informacao sao notificacoes

sobre eventos que ocorrem em um cenario observado, de maneira mais geral, qualquer

tipo de dado que reflete algum conhecimento gerado pela fonte [4]. Entretanto as vezes

um evento isolado pode nao descreve algo relevante, entao e comum avaliar um ou mais

eventos e realizar algum tipo de processamento.

Todo evento possui um cabecalho e um corpo [1], onde o cabecalho descreve de

onde o evento veio, momento que foi gerado, tipo e etc, o corpo e onde fica o dado em

si, a informacao relevante que se deseja analisar, a seguir a figura que representa essa

descricao.

16

Figura 2: Componentes de um evento

2.3 Processamento de Eventos Complexos

Como o nome ja sugere o Processamento de Eventos Complexos tem como proposta

tratar eventos nao somente de uma fonte, mas de diversas, assim aumentando a comple-

xidade dos padroes que podem ser identificados. CEP exige o emprego de sofisticados

interpretadores de eventos, combinacao, definicao de padroes e tecnicas de correlacao.

E comumente usado para detectar e responder anomalias, ameacas e oportunidades de

negocios [1]. O CEP faz parte da arquitetura orientada a eventos, mas tem um escopo

mais restrito, pois agrega eventos em alto nıvel que podem ser consumidos por outros

clientes [11].

Como exemplo, podemos ver o seguinte caso baseado no que [4] descreve e abordado

na Figura 3, temos um sistema para detectar fogo em uma sala que utiliza sensores

de temperaturas e de fumaca para fazer as analises, os sensores de temperaturas estao

representados pelos itens A, B e C, e o de fumaca pelo item D, com esse conjunto de

sensores podemos analisar a seguinte regra, se pelo menos dois sensores de temperatura

passar de um certo limiar e o sensor de fumaca detectar fumaca, podemos acionar o

alarme de incendio. Esse simples caso e possıvel ser analisado com um sistema CEP, pois

se utiliza de duas fontes de dados combinadas para gerar o resultado desejado.

17

Figura 3: Deteccao de fogo por meio de um sistema CEP

2.4 Programacao Reativa

A programacao reativa e um paradigma orientado a mudanca de valores ao longo

do tempo, geralmente esses valores sao referenciados como comportamentos ou sinais [12],

onde essas mudancas sao propagadas aos interessados. Permite tambem a manipulacao de

fluxo de dados, fornecendo uma abstracao ao desenvolvedor focar nas regras de negocio

[13]. Algumas das aplicacoes para a programacao reativa incluem redes de sensores,

robotica e animacoes graficas [12]. Um exemplo e o que [2] descreve, no qual em uma

rede social a quantidade de “curtidas” em uma postagem e atualizada de acordo com o

numero de usuarios que clicam no botao “curtir”, entao essa informacao e propagada e

refletida na interface onde o contador e exibido de forma instantanea.

Uma solucao conhecida para programacao reativa e o ReactiveX, que se descreve

como uma biblioteca para compor programas assıncronos e baseados em eventos usando

sequencias observaveis [14]. O mesmo fornece varios operadores como filter, map, merge

entre outros, permitindo um controle maior do fluxo dos dados. Na linguagem de pro-

gramacao Swift [10], existe uma extensao de codigo aberto para o uso da programacao

reativa o RxSwift [15], que faz parte do ReactiveX.

2.4.1 Combine

O Combine foi recentemente lancado na WWDC 2019 pela Apple, o mesmo e

descrito como uma ferramenta de processamento de eventos assıncronos que podem ser

combinados e aplicado operadores [9]. O combine fornece uma API declarativa para

processar valores ao longo do tempo, que o caracteriza como uma biblioteca reativa.

Esses valores podem representar eventos assıncronos e serem expostos por Publishers e

18

recebidos por Subscribers. Existe dois pontos apontados por [9], estao eles abaixo.

• O protocolo Publisher declara o tipo de valor que pode fornecer em sequencia ao

longo do tempo. Os Publishers possuem Operadores para agir de acordo com os

valores recebidos e republica-los.

• No final da cadeia de Operadores, um Subscriber age sobre os valores a medida que

os recebe. Os Publishers emitem apenas valores quando solicitados explicitamente

pelos Subscribers. Isso coloca o Subscriber no controle de como recebe os eventos

que esta conectado.

Em [9] tambem declara que o Combine pode combinar a saıda de varios Publishers

e coordenar sua interacao, tambem que se adotar o Combine vai facilitar a leitura e a

manutencao do codigo, pois vai centralizar o processamento de eventos e eliminar tecnicas

problematicas como e o caso de aninhamento de callbacks.

2.5 Abordagem Reativa com CEP

Abordagens que utilizam RLs mais CEP se mostram interessantes, pois tanto RLs

quanto CEP possuem caracterısticas semelhantes e sao exemplos para aplicacoes reativas

[16]. Apesar de diferentes, ambas compartilham alguns aspectos [5]. Uma analise realizada

em [12] revela que CEP e RLs oferecem solucoes complementares e dao suporte a aplicacoes

reativas, um exemplo de aplicacao e demonstrada em [5], onde apresentam uma biblioteca

chamada CEP.js.

2.6 Operadores

Operadores sao componentes indispensaveis nas arquiteturas orientadas a eventos,

pois sao utilizados para definir as regras e mapear os padroes desejados para ser alertado.

Alguns desses operadores estao descritos em [4], mas o subconjunto implementado neste

trabalho esta listado na secao 3.2.

Os operadores a seguir pertence ao grupo do CEP, estao definidos em [4] e separados

por categoria, pois existem operadores unarios, que trabalham diretamente com um unico

evento, mas tambem aqueles que podem ser usados em um fluxos de eventos.

19

Single-Item Operators: Esse tipo de operador processa as informacoes dos ele-

mentos um a um.

Tabela 1: Operadores unarios

Logic Operators: E usado para definir regras que combinam a informacao de

varios itens, uma caracterıstica e que nesses operadores nao necessita do relacionamento

de ordem. Esses mesmos operadores se aplicam ao tipo Sequences, mas ja esse ultimo

diferente do primeiro, considera a ordem dos itens.

Tabela 2: Operadores logicos

Window: Muitas vezes e necessario definir uma particao no fluxo dos dados para

a execucao de operadores, por essa razao existe a definicao de windows.

20

Tabela 3: Operadores de janela

Flow Management Operators: As vezes e necessario processar alguns fluxos de

eventos, mas para isso exigem alguns operadores para gerenciar essas informacoes como

por exemplo, merge, split.

21

Tabela 4: Operadores de fluxo

Aggregates: Muitos sistemas precisam agregar o conteudo de varios eventos re-

cebidos para produzir novas informacoes.

Tabela 5: Operadores de agregacao

22

2.7 Usos e aplicacoes

O processamento de eventos pode ter diversas aplicacoes, qualquer sistema que

necessite trabalhar com fluxos de dados contınuos e em tempo real ja pode ser avaliado a

aplicacao de um EDA. Um sistema orientado a eventos pode ser usado para a leitura de

sensores, que mapeia acontecimentos do mundo real em busca de padroes, como tambem

a monitoracao de atividades em sistemas buscando identificar ou prever algum problema

futuro. Algumas de suas aplicacoes pode ser visto abaixo:

• Sensores: Um exemplo e o descrito em [6] onde utiliza a arquitetura orientada

a eventos para suporte de decisoes em sistemas de gerenciamento de trafego, esse

sistema analisa milhoes de eventos de forma contınua gerados a partir de sensores.

Outro exemplo e o uso em cidades inteligentes, com a utilizacao de sensores em

aplicacoes como monitoracao de temperatura, umidade, estresse mecanico e etc [17].

• Predicao: O uso de CEP em conjunto com um sistema de analise preditiva como a

aplicada em [18] mostra que o CEP tambem pode ser usado como uma ferramenta

aliada a outras para resolver algum problema mais especıfico.

• Negocios: No mundo dos negocios EDA tambem aparece como demonstrado em

[19], pode ser usado para analises de oportunidades, alertas de vendas, bem como

tendencias de mercado.

• Corporativo: Em um ambiente corporativo como [20] descreve, EDA e usado para

as empresas monitorar seus negocios, como TI e processos organizacionais em tempo

real.

23

3 PROPOSTA

Este trabalho propoe a criacao de uma biblioteca para o Processamento de Eventos

Complexos chamada de CEPCombine, baseado no framework Combine e escrito em Swift.

Este capıtulo vai abordar um pouco das bibliotecas utilizadas, que e o caso do CEPSwift,

Combine e tambem um pouco da implementacao do CEPCombine1, o CEPSwift foi de-

senvolvido por [2], que aborda a estrategia de programacao reativa usando como base o

RxSwift [15]. Como objetivo principal o CEPSwift vem facilitar a geracao de eventos e

o seu gerenciamento em Swift e tambem fornecer recursos de Processamento de Eventos

Complexos [2]. Ja o CEPCombine foi desenvolvido como uma extensao do framework

Combine [9] durante este trabalho e utiliza o conceito de Publisher, semelhantemente aos

Observables presente no RxSwift, tornando tanto CEPSwift quanto CEPCombine duas

bibliotecas poderosas para o Processamento de Eventos Complexos.

3.1 CEPCombine

Originalmente o Combine nao possui tratamento para combinar eventos de tipos

distintos, mas como ele ja possui a capacidade de trabalhar com eventos, entao existe a

possibilidade de funcionar com Eventos Complexos realizando algumas adicoes ao codigo

original, de acordo com essas questoes a serem resolvidas nasce o CEPCombine.

Tendo a mesma proposta do CEPSwift o CEPCombine e uma biblioteca que aborda

a geracao de eventos bem como seu gerenciamento, processamento e notificacao aos inte-

ressados, com a possibilidade tambem de trabalhar com eventos complexos. Por ser uma

extensao direta do framework Combine o CEPCombine possui algumas restricoes, como

por exemplo exigir no mınimo a versao 13 do iOS, e tambem a versao 11 do Xcode que e

a IDE oficial da Apple para o desenvolvimento para iOS e Mac. Apesar das restricoes o

desenvolvimento nao foi afetado.

Existe algumas vantagens do CEPCombine em relacao ao CEPSwift, abaixo estao

alguns pontos.

• Extensao: Por ser uma extensao o CEPCombine tem por padrao todas as funcoes

do Combine, diferente do CEPSwift que precisa adicionar manualmente na biblio-

teca as funcoes que existem no RxSwift.

1Disponıvel em https://github.com/IsaacDouglas/CEPCombine

24

• Dependencia: Como o CEPCombine so precisa da biblioteca Combine que e do

sistema, dificilmente vai ter algum problema com incompatibilidade de versoes, en-

quanto no CEPSwift pode precisar de ajustes com novas atualizacoes do RxSwift.

• Continuacao do fluxo: Logo apos a utilizacao da funcao merge(withStream:)

do CEPCombine, o usuario ainda consegue prosseguir com aplicacoes de outros

operadores. Entretanto o mesmo nao acontece no CEPSwift, que pelo modo que foi

implementado logo apos realizar o merge, o usuario nao consegue continuar aplicando

operadores, a unica funcao que fica disponıvel e a subscribe(completion:), forcando

a terminar o fluxo ali.

• Gerenciador de eventos centralizado: Por ter um gerenciador de eventos centra-

lizado o CEPCombine permite que Publishers e Subscribers possam estar definidos

em locais diferentes, sem a necessidade de criar uma variavel para a fonte de eventos,

limitando um pouco o escopo, igual ao CEPSwift.

• Intervalo de publicacao para sequencias: Com o uso da funcao addEvent(every:with)

e possıvel passar uma lista e definir um intervalo para que os eventos sejam publi-

cados ate o fim da sequencia no intervalo definido.

3.2 Analise das funcoes implementadas

Como base este trabalho tera como foco o subconjunto das funcoes implementadas

inicialmente por [2] e tambem as que constam na atual versao do CEPCombine.

25

Tabela 6: Funcoes implementadas (A)

26

Tabela 7: Funcoes implementadas (B)

*A funcao ja existe na implementacao de Combine entao por padrao pode ser usado no

CEPCombine.

**Segundo a tabela descrita em [21].

3.3 Implementacao

3.3.1 Componentes

CEPCombine e composto por alguns componentes como protocolos, classes e ex-

tensoes, sao eles: CBEvent, CBEventManager, CBEventStream e Publisher. O prefixo

CB (usado como abreviacao para Combine) foi adotado para nao ter confusao e conflitos

entres componentes com o mesmo nome em outras bibliotecas como e o caso do CEPSwift.

A adocao do prefixo so nao foi utilizado para o Publisher, pois na definicao de uma ex-

tensao em Swift deve usar o nome do componente estendido e como o Publisher e um

componente do sistema, entao nao e permitido alterar o nome.

3.3.2 CBEvent

CBEvent e um protocolo que contem todo o cabecalho do evento, onde mostra o

momento em que o evento foi criado e a qual fluxo de dados ele pertence, foi utilizado

27

um protocolo por ser um modelo mais flexıvel para a criacao dos eventos, pois os eventos

que implementam esse protocolo ja vai possuir o cabecalho adequado. CBEvent segue

a especificacao que [1] apresenta sobre o cabecalho de um evento, que deve conter uma

descricao da ocorrencia do evento como o tipo e o momento em que ocorreu.

1 public protocol CBEvent {

2 var source: String? { get set }

3 var timestamp: Date { get set }

4 }

3.1: Protocolo CBEvent

1 public extension CBEvent {

2 static var identifier: String {

3 return String(describing: self)

4 }

5

6 func addEvent () {

7 CBEventManager.addEvent(event: self)

8 }

9 }

3.2: Extensao do Protocolo CBEvent

Acima temos dois codigos, onde o 3.1 representa o Protocolo CBEvent e o 3.2

a extensao do mesmo protocolo. O cabecalho e representado pelos atributos source e

timestamp definidos pelo usuario no codigo 3.1, pois quando realiza a implementacao do

protocolo e necessario definir a fonte e o momento em que foi criado o evento. Esses dois

atributos juntamente com o atributo identifier formam o cabecalho do evento, esse ultimo

representa o tipo do evento. Entretanto nao e obrigatorio a definicao do atributo source,

so e necessario quando o usuario precisar definir fontes diferentes para o mesmo tipo de

evento.

3.3.3 CBEventManager

CBEventManager e a classe usada para gerenciar os eventos, ela e responsavel por

adicionar os eventos gerados que estao de acordo com o protocolo CBEvent, atraves da

28

funcao addEvent(event:) independente do seu tipo no stream correto, tambem possui uma

variacao da funcao addEvent, a addEvent(every:with) que recebe um intervalo de tempo

e uma lista de eventos, cada evento dessa lista e adicionado no fluxo de eventos toda vez

que esse intervalo e completado, ate a lista esvaziar. CBEventManager tambem captura

o stream pelo tipo do evento passado, resultando em um CBEventStream como retorno

da funcao getEvents(onType:source:). Por se tratar de uma classe com funcoes estaticas

possui a vantagem de capturar eventos gerados em outras partes do codigo sem ter a

necessidade de manter uma variavel para o gerenciamento dos eventos.

Logo abaixo esta o codigo que representa a classe CBEventManager, nela podemos

adicionar ou capturar os eventos. O parametro source do metodo getEvents(onType:source:)

representa a fonte do evento, sendo que nao e obrigatorio a passagem desse parametro,

somente e preciso quando existem mais de uma fonte de evento do mesmo tipo e o usuario

precisa especificar de qual fonte ele quer recuperar o stream, pois se nao definir esse

parametro o metodo vai recuperar um stream contendo os eventos de todas as fontes.

1 import Combine

2

3 public class CBEventManager <T: CBEvent > {

4

5 public static func getEvents(onType type: T.Type , source: String? =

nil) -> CBEventStream <T> {

6 let publisher = NotificationCenter

7 .default

8 .publisher(for: Notification.Name(type.identifier))

9 .map({ $0.object as! T })

10 .filter ({ event in

11 return (source == nil) ? true : (event.source == source)

12 })

13

14 return CBEventStream(publisher)

15 }

16

17 public static func addEvent(event: T) {

18 NotificationCenter

19 .default

20 .post(name: Notification.Name(T.identifier), object: event)

29

21 }

22

23 public static func addEvent(every time: TimeInterval , with events: [

T]) {

24 guard !events.isEmpty else { return }

25

26 var items = events

27 var anyCancellable: AnyCancellable?

28

29 anyCancellable = Timer

30 .publish(every: time , on: .main , in: .default)

31 .autoconnect ()

32 .receive(on: RunLoop.main)

33 .sink(receiveValue: { _ in

34 if items.isEmpty {

35 anyCancellable ?. cancel ()

36 }else{

37 self.addEvent(event: items.first!)

38 items.remove(at: 0)

39 }

40 })

41 }

42 }

3.3: Classe CBEventManager

3.3.4 CBEventStream

CBEventStream foi criado para deixar o codigo um pouco mais legıvel, nele existe

a propriedade stream que indica o inıcio do acesso ao fluxo dos eventos com a possibilidade

de seu processamento. Abaixo o codigo que representa a classe CBEventStream.

1 import Combine

2

3 public class CBEventStream <T> {

4

5 fileprivate let publisher: Filter <Map <NotificationCenter.Publisher ,

T>>

30

6

7 public init(_ publisher: Filter <Map <NotificationCenter.Publisher , T

>>) {

8 self.publisher = publisher

9 }

10

11 public var stream: Filter <Map <NotificationCenter.Publisher , T>> {

12 return publisher

13 }

14 }

3.4: Classe CBEventStream

3.3.5 Publisher

O componente Publisher foi desenvolvido como uma extensao, onde fica locali-

zada a implementacao de todas as funcoes que CEPCombine acrescenta ao framework

Combine, pela caracterıstica de ser uma extensao e pelo modo que essas funcoes foram

implementadas o CEPCombine possui diversas vantagens, por exemplo, a sua utilizacao e

totalmente compatıvel com as funcoes ja definidas no Combine, sem o uso de uma interferir

na outra. Atualmente as funcoes implementadas sao followed(by:), subscribe(completion:),

merge(withStream:), duplicate( :), group(by:) e order(by:), a seguir a implementacao de

cada uma.

1 import Combine

2

3 public typealias Map = Publishers.Map

4 public typealias Filter = Publishers.Filter

5 public typealias CollectByCount = Publishers.CollectByCount

6 public typealias Merge = Publishers.Merge

7

8 @available(OSX 10.15 , iOS 13.0, tvOS 13.0, watchOS 6.0, *)

9 extension Publisher {

10

11 private func pairwise () -> Map <Filter <Self >, (Output , Output)> {

12 var previous: Output? = nil

13 return self

31

14 .filter ({ element in

15 if previous == nil {

16 previous = element

17 return false

18 } else {

19 return true

20 }

21 })

22 .map({ element -> (Output , Output) in

23 defer { previous = element }

24 return (previous!, element)

25 })

26 }

27

28 public func followed(by predicate: @escaping (Self.Output , Self.

Output) -> Bool) -> Filter <Map <Filter <Self >, (Self.Output , Self.

Output)>> {

29 return pairwise ().filter(predicate)

30 }

31

32 public func subscribe(completion: @escaping ((Self.Output) -> Void))

{

33 _ = self

34 .receive(on: RunLoop.main)

35 .sink(receiveCompletion: { _ in }, receiveValue: completion)

36 }

37

38 public func merge <T: Publisher >( withStream: T) -> Map <Filter <Map <

CollectByCount <Merge <Map <Self , (Int , Any)>, Map <T, (Int , Any)>>>, (

Self.Output?, T.Output ?) >>, (Self.Output , T.Output)> {

39

40 let first = self

41 .map({ (1, $0) as (Int , Any) })

42

43 let second = withStream

44 .map({ (2, $0) as (Int , Any) })

45

46 return first

47 .merge(with: second)

32

48 .collect (2)

49 .map({ values -> (Self.Output?, T.Output ?) in

50 guard

51 let f = values.first(where: { $0.0 == 1 }).map({ $0

.1 as! Self.Output }),

52 let s = values.first(where: { $0.0 == 2 }).map({ $0

.1 as! T.Output })

53 else { return (nil , nil) }

54 return (f, s)

55 })

56 .filter ({ $0.0 != nil && $0.1 != nil })

57 .map({ ($0.0!, $0.1!) })

58 }

59

60 public func duplicate(_ count: Int = 2) -> [Self] {

61 return (0 ..< count)

62 .map({ _ in self })

63 }

64

65 public func group <T: Sequence , Key: Hashable >(by keyForValue:

@escaping ((T.Element) throws -> Key)) -> Map <Self , [[T.Element]]>

where T == Self.Output {

66 return self

67 .map({ values -> [[T.Element ]] in

68 let dictionary = try! Dictionary(grouping: values , by:

keyForValue)

69 return dictionary.map({ $0.value })

70 })

71 }

72

73 public func order <T: Sequence >(by: @escaping ((T.Element , T.Element)

-> Bool)) -> Map <Self , [T.Element]> where T == Self.Output {

74 return self

75 .map({ $0.sorted(by: by) })

76 }

77 }

3.5: Extensao Publisher

33

4 CASO DE USO

Este capıtulo aborda dois casos de usos executados no CEPCombine que estao

descritos em [2] e [3].

4.1 Deteccao de caminhada

Este problema e abordado em [2] onde e combinado duas fontes de eventos ori-

ginadas dos sensores pedometro e o GPS do smartfone. Utilizando esses dois sensores e

possıvel ter mais acuracia para detectar se o usuario esta andando, ja que so o pedometro

pode ser enganado se o celular for balancado, ou so o GPS nao identificar se o usuario

esta de carro, entao com a ajuda dos dados de ambos os sensores combinados a precisao

e melhorada.

A seguir uma pequena demonstracao de como pode ser implementado esse sistema,

desde as classes que representam os eventos, funcoes responsaveis por receber o evento

do sensor do celular para gerar o evento e tambem a descricao das regras. Os exemplos

estao em CEPCombine e tambem CEPSwift, como foi demonstrado em [2], a resolucao

desse problema e realizado com apenas 5 linhas de codigo para realizar as regras, e em

CEPCombine tambem nao e diferente.

As figuras 4 e 5 mostram as classes que representam os eventos de localizacao e

pedometro respectivamente, sao responsaveis por guardar as informacoes necessaria de

cada evento.

Figura 4: Classe que representa o evento de localizacao (CEPCombine)

34

Figura 5: Classe que representa o evento de pedometro (CEPCombine)

Na figura 6 existem duas funcoes locationManager( :didUpdateLocations:) e pedo-

meterHandler( : :) elas sao responsaveis por receber do sistema as atualizacoes dos dados

de localizacao e pedometro respectivamente, criando e repassando os eventos para a classe

CBEventManager.

Figura 6: Criacao dos eventos e lancamento no gerenciador de eventos (CEPCombine)

Ja na figura 7 estao definidas as regras utilizadas para a deteccao da caminhada, no

metodo setRulesCEPCombine contem 5 blocos bem definidos, cada um com sua funciona-

lidade na composicao das regras. No primeiro bloco esta a regra que define a velocidade

regular de uma pessoa andando, ou seja, toda vez que o usuario estiver entre 0,2m/s e

1,8m/s essa regra e acionada. O segundo bloco e responsavel por identificar se o numero

de passos esta aumentando, com isso o sistema fica sabendo que o usuario esta avancando

na contagem de passos, caso contrario o usuario esta provavelmente parado. O terceiro

bloco faz a combinacao das duas regras anteriores e executa a acao definida quando os

dois eventos acontecer. No quarto e no quinto bloco de codigo fica a regra que muda

o estado do usuario para parado, correndo ou em algum veıculo, pois a velocidade esta

baixa ou ele esta muito rapido para esta caminhando.

35

Figura 7: Definicao das regras utilizadas (CEPCombine)

A Criterio de comparacao as figuras 8, 9, 10 e 11 que foram retiradas de [2] e estao

usando CEPSwift sao equivalentes as figuras 4, 5, 6 e 7 escritas usando CEPCombine

respectivamente. Ou seja, para esse exemplo tanto CEPCombine quanto CEPSwift re-

solveram o problema da caminhada de uma forma pratica. As figuras 8 e 9 estao escritas

usando CEPSwift e representam os eventos observados tanto de localizacao quanto de

pedometro.

Figura 8: Classe que representa o evento de localizacao (CEPSwift) [2]

36

Figura 9: Classe que representa o evento de pedometro (CEPSwift) [2]

Uma diferenca de implementacao que tem no CEPCombine e que nao precisa definir

variaveis para armazenar os eventos, diferente do CEPSwift, um exemplo esta na figura

10 onde precisa declarar as variaveis pedometerEvents e locationEvents. Essas variaveis no

CEPSwift representam a fonte dos eventos, ou seja, para cada fonte precisa ser definido

uma variavel, mesmo que as fontes sejam de eventos distintos, no CEPCombine a fonte

esta descrita no evento e so precisa definir quando existem mais de uma fonte de evento do

mesmo tipo. Essa decisao foi tomada para facilitar a escrita das regras, sem ficar definindo

variaveis. Quando precisa recuperar um unico stream e somente informar a fonte, mas se

desejar recuperar o stream de todas as fontes de uma vez basta nao fornecer a fonte na

hora de capturar o stream, evitando realizar um merge, como acontece no CEPSwift.

Figura 10: Criacao dos eventos e lancamento no Gerenciador de eventos (CEPSwift) [2]

37

Figura 11: Definicao das regras (CEPSwift) [2]

4.2 Jogo Genius

Este jogo e discutido em [3] e utiliza processamentos de eventos complexos para

sua jogabilidade, na proposta inicial o jogo utiliza um stream da sequencia que o usuario

iria replicar, outro para os dados enviados do sensor de inclinacao e um terceiro stream

que seria gerado a partir dos dados recebidos do sensor [3]. Posteriormente a proposta do

jogo foi alterada, pois o projeto pode ser implementado em RxSwift, mas por limitacoes

nao poderia ser em CEPSwift. Para ser implementado em sua totalidade [3] descreve que

CEPSwift precisa de um operador de tempo, para disparar eventos pre estabelecidos em

um intervalo definido e tambem uma funcao de combinacao que externaliza os eventos

recebidos para dois streams, para disparar um novo evento na ocorrencia desses eventos.

Abaixo a implementacao de como fica a nova proposta do jogo Genius em CEP-

Combine, como as classes que representam os eventos e a definicao das regras.

As figuras 13 e 14 representam as classes que representam os eventos utilizados no

Jogo Genius implementados em CEPCombine, em seguida na figura 15 (A) e (B) esta a

implementacao dessas mesmas classes em CEPSwift que foram apresentadas em [3], as

classes nao mudam muito de uma biblioteca para a outra.

Figura 12: Representa os lados que o aparelho esta inclinado

38

Figura 13: Classe que representa o evento do sentido que o celular esta inclinado (CEP-Combine)

Figura 14: Classe que representa o evento de inclinacao (CEPCombine)

Figura 15: Classes que representam os eventos de sentido de inclinacao (A) e o eventode inclinacao (B) (CEPSwift) [3]

A funcao deviceMotionHandler( : :) na figura 16, e responsavel por receber dos

sensores as atualizacoes de inclinacao do smartfone, e a partir dos dados criar o evento de

39

inclinacao, logo abaixo na figura 19 (bloco 1), e registrado uma acao de quando receber o

evento de inclinacao atualizar os dados exibidos na tela da aplicacao.

Figura 16: Criacao do evento de inclinacao quando o sensor notifica (CEPCombine)

As figuras 17 e 18 esta implementado em CEPSwift o mesmo que as figuras 16 e

19 (bloco 1) respectivamente.

Figura 17: Recebe os dados de inclinacao e cria o evento respectivo (CEPSwift) [3]

Figura 18: Mostra os dados de inclinacao na tela (CEPSwift) [3]

A figura 19 e onde esta definida as regras em CEPCombine para a identificacao

da inclinacao do aparelho no jogo Genius, existem 7 blocos de codigo, cada um tem a

responsabilidade de identificar um lado da inclinacao e gerar um novo evento com essa

identificacao. No bloco 7 mostra a inscricao onde exibe na tela o lado de inclinacao

que foi detectado de acordo com a figura 12, essa inscricao e notificada toda vez que e

gerado eventos a partir dos blocos 2 a 6 da figura 19. O mesmo se aplica a figura 20, que

representam em CEPSwift o mesmo que a figura 19, sendo a figura 12 igual para ambas

as bibliotecas.

40

Figura 19: Definicao das regras utilizadas no jogo Genius (CEPCombine)

41

Figura 20: Definicao das regras utilizadas no jogo Genius (CEPSwift)

42

4.3 Combine

A criterio de comparacao para os dois exemplos abordados em 4.1 e 4.2, abaixo

esta a implementacao dos mesmos casos de uso em Combine puro.

4.3.1 Deteccao de caminhada

A figura 21 e equivalente a figura 6, enquanto as figuras 22 e 23 sao equivalentes a

figura 7 que estao implementadas em CEPCombine.

Figura 21: Criacao dos eventos de localizacao e pedometro

Figura 22: Definicao das regras utilizadas na deteccao de caminhada (A)

43

Figura 23: Definicao das regras utilizadas na deteccao de caminhada (B)

4.3.2 Jogo Genius

A figura 24 e equivalente a figura 16, enquanto as figuras 25 e 26 sao equivalentes

a figura 19.

Figura 24: Criacao do evento de inclinacao

44

Figura 25: Definicao das regras utilizadas no jogo Genius (A)

45

Figura 26: Definicao das regras utilizadas no jogo Genius (B)

4.4 Comparacao

Esta secao aborda em mais detalhes a comparacao com alguns criterios como quan-

tidade de classes, linhas de codigo e metodos chamados. Abaixo esta uma tabela com os

casos de usos demonstrados neste capıtulo.

46

Tabela 8: Comparativo entre CEPSwift, CEPCombine e Combine

*A quantidade de blocos neste trabalho e considerado equivalente a quantidade de linhas

quando a linha esta quebrada por ponto ou tambem por operadores logicos como (&&)

por exemplo, em alguns momentos a utilizacao de blocos e somente por questoes de estilo

e para uma melhor visualizacao. Tambem e considerado somente a quantidade referente

ao que necessita para a implementacao das regras e nao nas classes que representam os

eventos.

**Considerando as variaveis declaradas para poder gerenciar os eventos nas figuras 10 e

20, o CEPSwift precisa de mais duas linhas de codigo para realizar os exemplos.

***Utiliza as classes do proprio sistema.

No geral as diferencas de implementacao para esses casos de uso com o CEPCom-

bine e o CEPSwift sao pequenas, o criterio que mais se destacou foi o da quantidade

de funcoes/metodos chamados quando comparado com o Combine puro, como mostra a

figura 27.

47

Figura 27: Grafico da quantidade de funcoes/metodos chamados por biblioteca

Utilizar o Combine puro como nas figuras 25 e 26 e mais complexo e trabalhoso,

pois algumas abstracoes ja estao implementadas no CEPCombine, enquanto no Combine

algumas regras como followed(by:) e o merge(withStream:) com fontes de eventos dis-

tintas nao e inferida naturalmente, portanto essas abstracoes do CEPCombine tras mais

facilidade na definicao das regras, diferente do Combine puro. Um exemplo e que ao

usar o Combine para criar a regra merge(withStream:), precisaria de aproximadamente 20

linhas de codigo como mostrado no codigo 3.5, enquanto so precisa de 1 linha para definir

no CEPCombine, pois a funcao ja esta pronta, o mesmo vale para a funcao followed(by:)

que precisa de aproximadamente 19 linhas.

48

5 CONSIDERACOES FINAIS

Tanto o Processamento de Eventos Complexos quanto a Programacao Reativa sao

consideradas boas ferramentas para aplicacoes reativas. Tambem a juncao de ambas se

mostrou viavel neste trabalho, pois como o CEPCombine se utiliza do framework reativo

Combine e acrescenta uma camada de CEP, isso permite uma maior facilidade na definicao

das regras para o reconhecimento de padroes de alto nıvel.

O CEP e uma abordagem muito poderosa para fluxos contınuo de eventos, sendo

assim este trabalho propos uma biblioteca chamada CEPCombine, o que se concretizou,

possibilitando realizar as demonstracoes dos casos de uso com a biblioteca. Alem disso,

foi abordada uma comparacao com o Combine e o CEPSwift que e outra biblioteca CEP

escrita em Swift, na pratica o CEPCombine acrescenta mais uma nova forma de trabalhar

com diversos fluxos de eventos, com a vantagem de ser suportado por um framework da

propria Apple, e ser compatıvel com suas funcoes. Realizando as comparacoes propostas,

verificou-se que nao existem muitas diferencas entre CEPSwift e CEPCombine no criterio

da quantidade de funcoes para definir as regras, mas a comparacao de ambas as bibliotecas

CEP com o Combine mostrou-se uma diferenca consideravel, o que apresenta ser mais

favoravel utilizar uma biblioteca CEP para facilitar e agilizar no desenvolvimento.

49

REFERENCIAS

[1] MICHELSON, B. M. Event-driven architecture overview. Patricia Seybold Group, v. 2,

n. 12, p. 10–1571, 2006.

[2] GEORGE, B. Complex event processing framework for swift. tg. 2017.

[3] SILVA, V. E. M. Um comparativo entre tecnicas de processamento de streamings em

swift.

[4] CUGOLA, G.; MARGARA, A. Processing flows of information: From data stream to

complex event processing. ACM Computing Surveys (CSUR), ACM, v. 44, n. 3, p. 15,

2012.

[5] ZIMMERLE, C.; GAMA, K. Reactive cep: Integrating complex event processing into

web reactive languages. In: ACM. Proceedings of the 24th Brazilian Symposium on

Multimedia and the Web. [S.l.], 2018. p. 69–72.

[6] DUNKEL, J. et al. Event-driven architecture for decision support in traffic manage-

ment systems. Expert Systems with Applications, Elsevier, v. 38, n. 6, p. 6530–6539,

2011.

[7] ECKERT, M. et al. A cep babelfish: Languages for complex event processing and

querying surveyed. In: Reasoning in Event-Based Distributed Systems. [S.l.]: Springer,

2011. p. 47–70.

[8] ESPERTECH. Espertech Esper. Accessed: 2019-11-26. Available at:

<http://www.espertech.com>.

[9] APPLE. Combine - Customize handling of asynchronous events by com-

bining event-processing operators. Accessed: 2019-09-12. Available at:

<https://developer.apple.com/documentation/combine>.

[10] APPLE. Swift - The powerful programming language that is also easy to learn. Ac-

cessed: 2019-11-26. Available at: <https://developer.apple.com/swift>.

50

[11] ROBINS, D. Complex event processing. In: CITESEER. Second International

Workshop on Education Technology and Computer Science. Wuhan. [S.l.], 2010. p.

1–10.

[12] MARGARA, A.; SALVANESCHI, G. Ways to react: Comparing reactive languages

and complex event processing. REM, p. 14, 2013.

[13] SANTOS, J. G. dos. Extensao e avaliacao funcional da biblioteca ceplin. 2018.

[14] REACTIVEX. An API for asynchronous programming with observable streams. Ac-

cessed: 2019-12-07. Available at: <http://reactivex.io/>.

[15] RXSWIFT. ReactiveX RxSwift Project. Accessed: 2019-09-12. Available at:

<https://github.com/ReactiveX/RxSwift>.

[16] ZIMMERLE, C. et al. Reactive-based complex event processing: An overview and

energy consumption analysis of cep. js. In: ACM. Proceedings of the XXXIII Brazilian

Symposium on Software Engineering. [S.l.], 2019. p. 84–93.

[17] FILIPPONI, L. et al. Smart city: An event driven architecture for monitoring public

spaces with heterogeneous sensors. In: IEEE. 2010 Fourth International Conference on

Sensor Technologies and Applications. [S.l.], 2010. p. 281–286.

[18] FULOP, L. J. et al. Predictive complex event processing: a conceptual framework for

combining complex event processing and predictive analytics. In: ACM. Proceedings of

the Fifth Balkan Conference in Informatics. [S.l.], 2012. p. 26–31.

[19] ADI, A. et al. Complex event processing for financial services. In: IEEE. 2006 IEEE

Services Computing Workshops. [S.l.], 2006. p. 7–12.

[20] SCHIEFER, J. et al. Event-driven rules for sensing and responding to business situ-

ations. In: ACM. Proceedings of the 2007 inaugural international conference on Distri-

buted event-based systems. [S.l.], 2007. p. 198–205.

[21] DMITRY. RxSwift to Combine Cheatsheet. Accessed: 2019-09-

23. Available at: <https://github.com/freak4pc/rxswift-to-combine-

cheatsheet/blob/master/Data/operators.csv>.