Ponto de Venda autónomo em
dispositivo móvel (offline e online)
Francisco de Sousa Gomes Ferreira do Couto
Mestrado Integrado em Engenharia Informática e Computação Orientador: António Miguel Pontes Pimenta Monteiro
online)
Francisco de Sousa Gomes Ferreira do Couto
Mestrado Integrado em Engenharia Informática e Computação
Aprovado em provas públicas pelo Júri:
Presidente: Jorge Alves da Silva
Arguente: Fernando Augusto Cruz e Silva Mouta Vogal: António Miguel Pontes Pimenta Monteiro
Um ponto de venda, do inglês Point of Sale, refere-se, de um modo genérico, a um dispositivo no qual é possível registar uma venda. Dado o vasto leque de funcionalidades que visam dispo-nibilizar, os POS podem fazer parte de uma mais ampla valorização do mundo da logística e dos negócios permitindo, entre outras coisas, a gestão, em tempo real, do fluxo de vendas e de stocks. Numa perspetiva mais ágil e de grande disponibilidade, que se pretende para o mundo em-presarial, encara-se, frequentemente, a necessidade de serem obtidas aplicações que se destacam pela sua portabilidade e acessibilidade, de forma a que se consiga ir de encontro ao cliente e não o contrário. No caso concreto desta dissertação, o objetivo passa por transladar algumas das funcio-nalidades do sistema de gestão comercial desenvolvido pela empresa Gestware - Gestware Cloud - em componentes de negócio que respondam às últimas necessidades e tendências do mercado das aplicações móveis.
O fim último passa, então, por elaborar uma aplicação multiplataforma, recorrendo ao desen-volvimento e desenho em Xamarin, que permitirá a sua utilização seja em ambiente Android, iOS ou Windows Universal. A arquitetura a desenvolver basear-se-á, tal como o produto supramenci-onado, no serviço cloud da Microsoft, o Microsoft Azure.
A aplicação de tecnologias de ponta não se afigura, no entanto, como o único aspeto diferenci-ador desta proposta. A principal característica que a torna inovdiferenci-adora é a possibilidade de funcionar desligada da rede (offline), baseando-se, para isso, num sistema de bases de dados distribuídas por cada dispositivo que aloje a aplicação. A implementação de uma arquitetura do género afigura-se como um desafio, uma vez que põe em causa a integridade e consistência dos dados armazenados - as operações de atualização, criação e eliminação dos mesmos numa versão local da base de da-dos, podem levar a conflitos quando a ligação à rede é reestabelecida e é feita uma sincronização com a base de dados no servidor. Ainda neste contexto, além de ter de existir este mecanismo de sincronização que permite lidar com potenciais operações concorrentes na informação armaze-nada, visa-se estudar a possível utilização de um método, que se insira no âmbito do Data Mining preditivo, para controlar o caso especial de gestão de stocks. O objetivo passa por tentar evitar ruturas que ponham em causa o normal funcionamento do negócio, quando são feitas vendas sem qualquer conexão à rede e os valores de stock armazenados localmente poderem já se encontrar desatualizados.
A validação da solução visa entender de que forma as funcionalidades desenvolvidas se en-quadram nas exigências do meio empresarial, nomeadamente na perspetiva da sua portabilidade e usabilidade e do cumprimento dos requisitos definidos à priori. Em termos de performance, é feita uma comparação entre o comportamento da aplicação sem conexão à rede e quando esta é reestabelecida, analisando-se se são mantidos os mesmos padrões de qualidade, seja na veloci-dade de utilização, seja na coerência dos dados armazenados. No que diz respeito à aplicação de mecanismos preditivos, são analisadas as taxas de erro obtidas, permitindo inferir a pertinência da sua utilização como valor acrescentado à arquitetura apresentada no âmbito desta dissertação, bem como no contexto atual da empresa para a qual foi desenvolvida a prova de conceito.
A point of sale (POS) is a device with which is possible to register and conclude a sale. Due to the wide array of functionalities they provide, these devices can be part of a broader valorisation of the business world, allowing things such as real-time management of processed sales and product stock changes.
Due to the latest shift in the business world to treat the business as a service, delivering it direc-tly to the client, there’s the urge to bring in tools that distinguish themselves by their portability and easiness of access to business related data. Taking this into account, Gestware, a portuguese com-pany dedicated to the development and distribution of software for managerial purposes, suggested the creation of a proof of concept that emulated some of their web based product functionalities on a cross platform mobile application.
The goal of this thesis is to present an architecture based on the mobile application built. The solution must be developed resorting to Xamarin’s development environment allowing its usage on either Android, iOS, or Windows Phone. The whole architecture shall be based on Microsoft’s cloud platform, Azure.
The usage of state of the art technology isn’t the sole differentiating aspect of the proposed so-lution. In order to be considered an innovative product in the market, and to offer extra portability to its usage, it must be able to work even when there is no connection to the internet. It shall then be based in a system of distributed databases, which means there would be a main database in the server and a replica in each mobile device. This obviously brings great challenges concerning the consistency and integrity of data since its creation, update, and elimination in a local instance of the database needs to be synchronized in order to be reached a state of consistency between all co-pies. That might lead, as a consequence, to the existence of conflicts, if changes are concurrently made to the same data.
That said, besides this synchronization mechanism that must deal, as mentioned, with conflic-ting changes in the databases, there will also exist a study on Data Mining methods that might be helpful to control the special case of stock ruptures. The goal is to try to avoid that, in the inexis-tence of a network connection, due to non-updated data, sales that are made cause the products’ stock values to go below 0.
As an analysis of the proposed solution it shall be evaluated how it meets the demanding requirements of the business world, namely in terms of its portability and usability. It must also be analysed how the proof of concept performance differs between scenarios with and without connection to the internet and if the quality standards concerned with its velocity and the integrity of the data are maintained or not and why. Finally, there must exist a thorough evaluation of the usage of the data mining algorithms, namely by analysing their error rates, and inferring the true utility of this mechanisms for the architecture proposed in this master thesis as well as the company for which the proof of concept was developed.
Ao professor Miguel Pimenta Monteiro pela disponibilidade e orientação ao longo da realiza-ção desta dissertarealiza-ção.
Aos engenheiros Tiago Nobre e Vítor Pinto, bem como aos restantes trabalhadores da empresa Gestware, que me acolheram durante todo o processo de realização da dissertação e que sempre se disponibilizaram para me auxiliar de qualquer forma possível.
Aos meus amigos, porque sem eles a vida não tem tanta cor.
Por fim, às pessoas a quem devemos tudo e que me acompanham em todos os momentos da minha vida, à minha família, em especial aos meus pais, irmã e avós.
1 Introdução 1 1.1 Enquadramento . . . 1 1.2 Motivação . . . 1 1.3 Projeto e Objetivos . . . 2 1.4 Estrutura da Dissertação . . . 3 2 Revisão Bibliográfica 5 2.1 Soluções Existentes . . . 5 2.2 Aplicações Móveis . . . 6 2.2.1 Desenvolvimento Nativo . . . 6 2.2.2 Desenvolvimento Cross-Platform . . . 8
2.3 A Transição do Online para o Offline . . . 11
2.3.1 Armazenamento Local . . . 12
2.3.2 Armazenamento em Cache . . . 13
2.3.3 Armazenamento em Bases de dados Locais . . . 13
2.3.4 Sistema de Bases de dados distribuídas . . . 14
2.3.5 Protocolos de Replicação . . . 15 2.3.6 Resolução de conflitos . . . 17 2.3.7 Tecnologias . . . 19 2.4 Gestão de Stocks . . . 20 2.4.1 O Data Mining . . . 20 2.5 A emissão de faturas . . . 29
3 Arquitetura, Especificação da Solução e Análise de Requisitos 31 3.1 Desenvolver um ponto de venda autónomo . . . 31
3.2 A Arquitetura . . . 32
3.3 Tecnologias . . . 34
3.3.1 Xamarin . . . 34
3.3.2 Microsoft Azure . . . 36
3.4 Especificação e Análise de Requisitos . . . 46
3.4.1 Análise de Requisitos Não Funcionais . . . 47
3.4.2 Análise de Requisitos Funcionais . . . 47
4 Aspetos da Implementação 51 4.1 Metodologia . . . 51
4.2 Base de Dados . . . 52
4.3 Criação do Backend . . . 59
4.4.1 Padrão de Desenvolvimento MVVM . . . 61
4.4.2 Funcionalidades Implementadas . . . 62
4.4.3 Análise do produto desenvolvido . . . 73
4.5 Experiências Azure Machine Learning . . . 75
4.5.1 Obtenção e processamento de dados . . . 76
4.5.2 Criação de features . . . 78
4.5.3 Teste de algoritmos . . . 78
4.5.4 Avaliação da performance dos algoritmos . . . 79
4.5.5 Criação do Web Service . . . 82
5 Conclusões e Trabalho Futuro 85 5.1 Satisfação dos Objetivos . . . 85
5.2 Trabalho Futuro . . . 87
Referências 89 A Anexos 93 A.1 Exemplo de Resposta - Serviço CTT . . . 93
A.2 Exemplo de documento impresso . . . 95
2.1 Desenvolvimento baseado em silos . . . 8
2.2 Arquitetura de uma aplicação web based [LLNES16] . . . 9
2.3 Abordagem Black Box . . . 10
2.4 Arquétipo da abordagem Gerada [LLNES16] . . . 11
2.5 Comparação de várias técnicas de Fragmentação [CR05] . . . 15
2.6 Replicação Cópia Primária Síncrona [Sta05] . . . 16
2.7 Replicação Cópia Primária Assíncrona [Sta05] . . . 16
2.8 Replicação Multi Master Síncrona [Sta05] . . . 17
2.9 Replicação Multi Master Assíncrona [Sta05] . . . 17
2.10 K-Nearest Neighbours [Car16] . . . 22
2.11 Exemplo de geração de uma árvore de decisão relativa à probabilidade de jogar ou não ténis . . . 22
2.12 Redes Neuronais Artificiais [Kle98] . . . 23
2.13 Support Vector Machines[Mey17] . . . 23
2.14 Exemplo de uma Série Não Estacionária . . . 25
2.15 Exemplo de uma Série Estacionária . . . 25
2.16 Árvore de Decisão que prevê a probabilidade de sobreviver ao naufrágio do Titanic 26 2.17 Support Vector Regression [dS15] . . . 26
2.18 Tipos de Funções de Ativação [JMM96] . . . 27
3.1 Arquitetura proposta para a solução . . . 33
3.2 Serviço Azure Mobile Apps . . . 38
3.3 Esquemática da arquitetura do Sistema - Tecnologias . . . 42
3.4 Interface do Azure Machine Learning Studio . . . 43
3.5 Diagrama de Casos de Uso . . . 50
4.1 Diagrama das tabelas da base de dados . . . 53
4.2 Exemplo de aplicação do trigger de atualização de stocks . . . 58
4.3 Interface de criação do backend . . . 59
4.4 Interface Easy Tables . . . 60
4.5 App Service Editor . . . 60
4.6 Página Inicial . . . 63
4.7 Vistas do Menu Principal da Aplicação . . . 64
4.8 Página de Criação de Cliente . . . 65
4.9 Opções no menu cliente . . . 66
4.10 Página Cliente . . . 66
4.11 Funcionalidade de Navegação . . . 66
4.13 Página de Venda . . . 68
4.14 Página de Criação de Artigo . . . 68
4.15 Página de Artigo . . . 69
4.16 Página de edição de informação de um artigo . . . 70
4.17 Página de Documento . . . 70
4.18 Menu de Impressão . . . 71
4.19 Funcionalidade Connectivity Plugin . . . 72
4.20 Processo de sincronização iniciado . . . 73
4.21 Análise da evolução das vendas do Produto 7 . . . 80
4.22 Model of Goodness para as previsões feitas (Decision Forests) . . . 81
4.23 Distribuição dos erros de cada previsão (Decision Forests) . . . 82
2.1 Sistema operativos em dispositivos móveis e respetivas linguagens de programação 7
2.2 Quota de Mercado por Sistema Operativo . . . 7
2.3 Ferramentas mais Utilizadas . . . 28
2.4 Ferramentas com maior crescimento . . . 28
3.1 Detalhes relativos ao desenvolvimento de aplicações recorrendo a Xamarin . . . 35
3.2 Elementos utilizados para criar vistas em Xamarin.Forms . . . 36
3.3 Mecanismos expostos pela webAPI . . . 39
4.1 Taxas de IVA em território nacional . . . 56
4.2 Estatísticas de Utilização da Aplicação . . . 74
4.3 Análise de performance para os métodos de Machine Learning . . . 80
ACID Atomicidade, Consistência, Isolamento e Durabilidade API Application Programming Interface
BD Base de Dados
CRAN Comprehensive R Archive Network CRUD Create, Read, Update, Delete GPS Global Positioning System GUID Globally Unique Identifier HTML Hyper Text Markup Language IDE Integrated Development Environment IVA Imposto sobre o Valor Acrescentado POS Point of Sale
PVP Preço de Venda ao Público
SAMD Synchronization Algorithms based on Message Digest SDK Software Development Kit
SO Sistema Operativo
SQL Structured Query Language SSMS SQL Server Management Studio SyncML Synchronization Markup Language WEB World Wide Web
XAML Extensible Application Markup Language XML Extensible Markup Language
Introdução
Neste primeiro capítulo, será apresentada uma visão genérica do tema abordado nesta dis-sertação, sendo identificada, de uma forma clara, a motivação para a realização da mesma. Esta análise será acompanhada por uma explicação do projeto a desenvolver e dos objetivos que visa concretizar, bem como da estruturação do restante documento.
1.1
Enquadramento
A Gestware, uma empresa nacional exclusivamente dedicada à produção e distribuição de Soft-warede Gestão, visa oferecer aos seus clientes a melhor experiência possível no que diz respeito à gestão dos seus negócios, almejando, dessa forma, que estes obtenham vantagens competitivas em relação aos demais concorrentes. Não obstante, e apesar de já oferecerem uma larga gama de produtos que permitem, nomeadamente, a gestão de stocks, vendas e contas correntes e que garantem escalabilidade consoante a dimensão do negócio, necessitavam, de modo a acompanhar as tendências recentes do mercado da tecnologia e dos sistemas de informação, de disponibilizar estas funcionalidades no âmbito das aplicações móveis.
A proposta, inserida no contexto supracitado, consiste no desenvolvimento de uma prova de conceito que reúna várias das funcionalidades presentes no Software de Gestão Comercial da empresa, o Gestware Cloud, e que, tal como este, se alicerce na plataforma cloud da Microsoft, o Microsoft Azure. A funcionalidade mais importante que o sistema deve incluir, e que atribui o título a esta dissertação, é a capacidade do utilizador efetuar uma venda através da emissão de um documento legal representativo da mesma: a fatura.
1.2
Motivação
Esta dissertação surge, não só como meio de acompanhar as tendências tecnológicas de um mercado em constante expansão, mas, de igual modo, como resposta à crescente infiltração, no
meio corporativo, de tecnologias que tiveram a sua origem no mercado de consumo. Esta ten-dência, conhecida como Consumerization, começou com a emergência das tecnologias WEB 2.0 como as wikis e as redes sociais, que pretendiam aprimorar a capacidade de colaboração e troca de informação dentro da empresa [WL12].
Numa segunda etapa, surge uma nova vertente que fomenta a utilização de dispositivos móveis e das aplicações, nestes alojadas, no dia-a-dia do trabalhador. O fenómeno da IT Consumeriza-tion, conforme descrito por Enrique Castro-Leon [CL14], também conhecido como o movimento BYOD(Bring your own device), está a ajudar as organizações a adotar uma mudança cultural que permite responder às necessidades de uma nova geração, cujas expectativas passam por poder uti-lizar este tipo de dispositivos num ambiente empresarial da mesma forma que os utiliza na sua rotina privada.
A utilização deste tipo de ferramentas de trabalho vem, por conseguinte, redefinir a forma como as empresas definem as suas fronteiras e forçam a que sejamos integrados numa economia cada vez mais orientada para a disponibilização de serviços e não focada no produto.
A relação cliente-vendedor ganha, por isso, uma importância extraordinária exigindo que seja feita uma aproximação ao consumidor apenas possível através do contacto pessoal. Isto exige, no contexto em questão, que o vendedor consiga transportar consigo todas as funcionalidades de uma aplicação de gestão comercial tradicional para mostras e feiras da área, ou, até mesmo para o domicílio do cliente, mesmo que se situem em zonas remotas e/ou sem conexão à rede. Este último tópico afigura-se como crucial, uma vez que, em condições normais, impede qualquer acesso a dados essenciais para o funcionamento de um sistema do género, inviabilizando que a situação supracitada ocorra.
1.3
Projeto e Objetivos
O projeto consiste, então, na planificação, desenvolvimento de raiz, e validação de uma prova de conceito no âmbito das aplicações móveis multiplataforma, que translade algumas das funcio-nalidades que poderíamos encontrar no Software de Gestão Comercial desenvolvido pela empresa. Entre as funcionalidades presentes destacar-se-iam a gestão de clientes, artigos e respetivos stocks, bem como a emissão de faturas.
Tendo em conta a necessidade constante de providenciar produtos que almejam prover o cli-ente de uma vantagem relativamcli-ente aos demais e de forma a apresentar-se como um produto inovador no mercado interno, uma das características de valor acrescentado que este deve abarcar é a possibilidade de utilizar todas as funcionalidades supracitadas mesmo na ausência de conexão à rede. Para tal ser possível, o sistema baseia-se na criação de uma rede de bases de dados distribuí-das. Esta abordagem levanta, contudo, obstáculos no que diz respeito à consistência e integridade da informação armazenada, uma vez que esta é utilizada e modificada em cada nó deste sistema, de uma forma heterogénea, mas deve atingir um estado de eventual consistência em todos eles.
Desse modo, além da necessidade de existirem mecanismos de sincronização que visem regu-lar e retrair ao máximo os efeitos do problema supracitado, no comércio de retalho é necessária
uma preocupação extra com certas imposições inerentes ao negócio, nomeadamente no que diz respeito à manutenção da integridade dos valores coincidentes com os stocks dos vários produ-tos. Tendo isso em consideração, além do desenvolvimento da arquitetura base já descrita, será estudada a possibilidade de adicionar à solução final um módulo extra que coadune com a mesma e sirva como uma medida preventiva, de modo a tentar impedir a concretização de vendas que implicassem a atribuição de valores negativos aos valores de stock de um produto.
A proposta no contexto da dissertação passa, mais concretamente, pelo estudo exploratório da utilização de algoritmos preditivos que permitam oferecer indicadores de carácter informativo ao vendedor, de modo a que este possa determinar se é possível vender determinada quantidade de um produto, sem causar um rutura de stock quando a aplicação é utilizada sem qualquer conexão à rede e a fidedignidade dos dados é, por isso, posta em causa.
Para que o projeto seja bem sucedido deve ser utilizada uma abordagem incremental que per-mita concretizar os objetivos propostos nas várias áreas técnicas já expostas. É premente que existam várias fases de validação do produto, nomeadamente através da realização de testes de aceitação validados por parte dos elementos da empresa, de forma a comprovar a usabilidade da mesma e o cumprimento de questões importantes como a integridade dos valores de stock após cada venda, ou a correção dos elementos presentes em cada fatura emitida.
Uma vez construído o sistema, será interessante verificar, ao nível da performance, quais as diferenças existentes entre a utilização da aplicação na existência de uma ligação à rede e em modo offline, analisando-se se esta é de alguma forma prejudicada. De igual modo, será importante constatar quais os efeitos, a longo prazo, na consistência e integridade dos dados e os possíveis contratempos que poderão daí advir para o negócio. Por fim, verificar-se-á se a utilização de um algoritmo preditivo tem um impacto importante num sistema deste género, analisando-se a sua premência para o contexto da dissertação, bem como para a realidade atual da empresa.
1.4
Estrutura da Dissertação
Para além da introdução, esta dissertação contém mais quatro capítulos. No capítulo 2, são apresentados trabalhos relacionados e é versado o levantamento feito relativo ao estado da arte, sendo conduzida uma vasta análise a vários conceitos inerentes às áreas em que se enquadra a solução, bem como a tecnologias frequentemente utilizadas para fazer face aos vários desafios propostos. No capítulo3, é detalhada a arquitetura do sistema e são apresentadas e esmiuçadas as tecnologias eleitas para levar a cabo a elaboração do produto final. O enquadramento feito neste capítulo terá um cariz mais técnico e específico, apresentando detalhes essenciais para se perceber o conteúdo do capítulo sucedâneo. A solução desenvolvida é então apresentada e do-cumentada no capítulo4. Neste, é ainda feita uma análise dos resultados obtidos e apresentados os detalhes relativamente a alguns desafios superados. Por fim, no capítulo5, são apresentadas as conclusões, sendo especificado até que ponto foi possível cumprir os requisitos estipulados a priori, bem como as expectativas da empresa que acolheu a realização da prova de conceito. É ainda feito um pequeno overview relativamente ao trabalho futuro que poderá permitir a extensão
das funcionalidades desenvolvidas e o aumento da robustez da solução, tendo em vista uma futura comercialização.
Revisão Bibliográfica
Neste capítulo, é feita uma prospeção das soluções existentes no meio científico e tecnoló-gico no que diz respeito a trabalhos relacionados e técnicas consideradas relevantes para o desen-volvimento desta dissertação. Abordar-se-ão, numa primeira etapa, as tecnologias existentes no contexto das aplicações móveis, passando-se, posteriormente, para o âmbito das aplicações com modo de funcionamento offline. Por fim, é reservada uma secção onde é examinada a área do Data Miningpreditivo e, em particular, o problema da previsão de stocks e vendas.
2.1
Soluções Existentes
A utilização de pontos de vendas afigura-se como essencial para todos os negócios, desde as pequenas lojas de retalho até às grandes superfícies, constituindo também uma questão legal. De forma a se entender até que ponto a proposta enquadrada nesta dissertação se apresentava como singular, foi importante, como ponto de partida, entender que tipo de soluções existiam, seja na literatura, seja no mercado de aplicações, no que ao desenvolvimento de POSs diz respeito.
A aplicação de conceitos de computação móvel no âmbito empresarial tem sido alvo de es-tudo de uma forma alargada não só visando a implementação de pontos de venda móveis, mas promovendo outro tipo de soluções que permitem a interação direta com o cliente[RK07,FL12].
No que diz respeito à criação de pontos de venda, verifica-se uma preocupação quase unânime da literatura em mapear soluções que visam, especialmente, a certificação da segurança destes sistemas no que diz respeito à implementação de diferentes métodos de pagamento[DB11,PHS06, Sad13,YH15], mas poucos visam explorar diferentes potencialidades de implementação [DW15]. No mercado de aplicações, pelo contrário, quem procura usufruir deste tipo de sistemas en-contra um grande leque de soluções disponíveis: aplicações pagas como o POS comercializado pela Vend, pela Bindo, ou o eMobilePOS da e-Nabler aos quais se juntam os produtos da Loyverse, uniCenta, zeroPos ou eHopper que se destacam por serem gratuitos e/ou Open Source.
Revistas estas alternativas, torna-se claro que o que se visa explorar é a incapacidade, na literatura atual, de elaborar uma análise às perspetivas de solução para a criação de um ponto de venda móvel e, sobretudo, a elaboração de uma arquitetura detalhada e uma prova de conceito validada, que contraste com as soluções supracitadas, com o intuito de, no futuro, se apresentar como uma alternativa viável no mercado nacional.
Neste sentido, a proposta a desenvolver deve ainda adaptar-se ao contexto específico da em-presa em questão, nomeadamente ao ambiente cloud no qual os seus restantes produtos já se baseiam, à estrutura da base de dados já existente, e às normas em vigor na legislação portuguesa, nomeadamente no que diz respeito à emissão de documentos da área financeira, restrições que os sistemas acima citados poderão não permitir cumprir. Por outro lado, deve conseguir englobar as mais valias destes mesmos sistemas e combater as suas debilidades numa única proposta de solução.
Pretende-se, por isso, a criação de uma aplicação fiável, que seja passível de ser utilizada num alargado leque de dispositivos e que inclua um modo de funcionamento offline que tenha em conta as limitações e restrições inerentes ao processo de atualização de stocks e a importância desta operação para o sucesso da solução.
Feita esta contextualização do propósito deste projeto, no âmbito da literatura e do meio tec-nológico atual, será apresentada, de seguida, uma prospeção do estado da arte para cada uma das áreas visadas na implementação e dos conceitos e potencialidades que lhes estão inerentes e que serão essenciais para compreender as escolhas feitas posteriormente e, em última análise, o trabalho desenvolvido.
2.2
Aplicações Móveis
Uma aplicação móvel é um software desenvolvido especialmente para ser utilizado em dispo-sitivos móveis, como smartphones, ou tablets. O mercado destes dispodispo-sitivos tem vindo a crescer substancialmente, graças à feroz competição existente entre empresas como a Apple e a Google, mas que implicou a existência de uma grande fragmentação no que diz respeito às plataformas existentes e aos sistemas operativos que as suportam. Recentemente, e de modo a acompanhar esta evolução e dar resposta às exigências inerentes ao desenvolvimento de uma aplicação para várias plataformas distintas, temos vindo a testemunhar o surgimento de várias tecnologias que visam facilitar e promover este desenvolvimento e que se baseiam em abordagens distintas[RD12]. De forma a que pudesse ser obtida uma perspetiva que pudesse influenciar a escolha da plataforma ideal para o desenvolvimento desta dissertação as várias alternativas foram alvo de estudo e de análise.
2.2.1 Desenvolvimento Nativo
Uma aplicação é considerada nativa se for desenvolvida recorrendo ao SDK correspondente a um certo sistema operativo, estando apenas disponível nos dispositivos que apresentem esse ambiente[LLNES16]. A principal distinção, no que ao desenvolvimento diz respeito, é feita entre
quatro empresas: a Apple, a Google, a BlackBerry e a Microsoft, cada uma delas com o seu próprio sistema operativo e inerente linguagem de programação, conforme se mostra na tabela2.1.
Tabela 2.1: Sistema operativos em dispositivos móveis e respetivas linguagens de programação Empresa Sistema
Operativo
Linguagem de Programação
Google Android Java
Apple iOS Objective-C / Swift Microsoft Windows Phone C++ BlackBerry BlackBerry OS Java
De acordo com estatísticas retiradas de um estudo realizado pela empresa de consultoria norte americana Gartner, é possível concluir, no entanto, que as duas primeiras empresas de-têm o quase completo monopólio do mercado com uma quota de 99.6%. Com 81.7%, a Google afigura-se como líder destacado e tem vindo a distanciar-se do rival, conseguindo vender cerca de 352.669.900 dispositivos com sistema operativo Android até aos últimos três meses de 2016, conforme mostram os dados da tabela2.2. Em claro contraste, aparecem os dispositivos com sis-tema operativo BlackBerry que apresentam uma quota de mercado irrisória, considerada nula, com cerca de 200.000 unidades vendidas até ao mesmo período.
Tabela 2.2: Quota de Mercado por Sistema Operativo1 Sistema Operativo Unidades
Vendidas (Milhares) Quota de Mercado (%) Android 352,669.9 81.7 iOS 77,038.9 17.9 Windows 1,092.2 0.3 BlackBerry 207.9 0.0 Other OS 530.4 0.1 Total 431,539.3 100.0
O desenvolvimento nativo, nomeadamente quando visa cobrir mais do que um determinado sistema operativo, baseia-se numa abordagem que é tradicionalmente referida como Silo approach, ou, abordagem em Silo.
A escolha por este tipo de metodologia, atualmente a mais comum no que diz respeito ao desenvolvimento de aplicações móveis, implica construir a aplicação para cada plataforma de uma forma independente entre elas. Cada sistema operativo que queremos visar é considerado um silo e requer que se utilize a linguagem nativa para aquele SO, conforme acima descrito.
O desenvolvimento de aplicações seguindo este tipo de abordagem permite o acesso ao com-pleto arsenal de utilitários disponibilizados pelo dispositivo, como a câmara e o GPS, não apresenta quaisquer limitações ao nível de performance e oferece a possibilidade de criação de interfaces que têm um aspeto natural e estão sujeitas à natural evolução do sistema operativo ao longo do tempo,
proporcionando, por isso, uma melhor experiência, ao nível da utilização, ao utilizador. Todavia, a opção por este tipo de abordagem acarreta um maior esforço ao nível do desenvolvimento, seja ao nível do tempo que é necessário despender, visto requerer a criação de duas ou mais aplica-ções distintas dependendo do número de sistemas operativos que queremos visar, ou, no âmbito técnico, pois requer o domínio de várias linguagens de programação distintas [XX13]. Este úl-timo ponto poderá ainda envolver custos adicionais caso seja necessária a criação de equipas de desenvolvimento multidisciplinares.
As aplicações de cada sistema operativo são igualmente comercializadas em diferentes Appli-cation Storeso que se afigura um desafio em termos comerciais, caso não haja a possibilidade de implementar soluções para cada ambiente de programação.
Figura 2.1: Desenvolvimento baseado em silos2
2.2.2 Desenvolvimento Cross-Platform
A solução proposta para ultrapassar os desafios que o desenvolvimento nativo envolve passa pela criação de aplicações móveis recorrendo a arquiteturas multiplataforma que permitem que seja apenas necessária uma base de código comum, de forma a que a aplicação seja compatível com múltiplos sistemas operativos.
Serão apresentadas, de seguida, algumas das arquiteturas disponíveis no mercado, bem como algumas das frameworks que se afiguram como as melhores soluções para este tipo de abordagem. A sua divisão aproxima-se da sugerida por diversos autores[XX13, Wil,HHM13, LLNES16] e visou, sobretudo, a revisão ao pormenor das capacidades e falhas de cada uma, numa tentativa não só de comparação com a abordagem nativa, mas também entre si.
2.2.2.1 Abordagem WEB
Este tipo de abordagem não se traduz na criação de uma aplicação, na verdadeira aceção da palavra e conforme se subentende nas restantes abordagens. A sua implementação consiste na construção de um website que, tal como os demais, é constituído por um conjunto de páginas HTML interligadas e que pode ser acedido através de um qualquer browser.
Este tipo de aplicações browser-based não requer, por isso, qualquer tipo de instalação nem está sujeito a subsequentes atualizações. Em comparação com os restantes websites, estes podem ser distinguidos por se preocuparem em atingir um standard designado de responsive web design que visa, não só a construção de páginas que se adaptem a um dispositivo móvel, mas a qualquer dispositivo e resolução de ecrã.
Apesar deste tipo de soluções apresentar vantagens ao nível da velocidade e dos custos ineren-tes ao desenvolvimento, existem alguns pontos negativos que não abonam a favor da escolha deste tipo de abordagem caso as exigências ao nível da implementação sejam maiores, quer ao nível da utilização e aspeto da aplicação, por apenas emular o aspeto de uma aplicação nativa, quer em relação ao uso do hardware inerente ao dispositivo móvel, nomeadamente no que diz respeito à utilização de funcionalidades como o GPS[HHM13]. Entre as frameworks utilizadas para este tipo de implementação destacam-se o jQuery Mobile3e o Sencha Touch4.
Figura 2.2: Arquitetura de uma aplicação web based [LLNES16]
2.2.2.2 Abordagem Híbrida
No contexto da utilização de ferramentas web surge um outro tipo de abordagem possível que é conhecida como híbrida, tornando a aplicação parte nativa e parte baseada em web, justificando, por isso, a denominação.
Este tipo de abordagem coincide com a utilização de uma arquitetura denominada de Black Boxou caixa negra. Neste caso, não há, mais uma vez, necessidade de escrever código diferente para as várias plataformas que queremos abranger. As frameworks que suportam este tipo de implementação, baseiam-se na utilização de HTML5 e JavaScript para criar a aplicação que é executada num browser interno e cujo código é embutido num wrapper nativo, também designado por Web View em Android e UIWebView em iOS [XX13].
Em comparação com as web applications, este tipo de soluções apresentam o mesmo aspeto e usabilidade, mas têm a grande vantagem de poderem aceder a algumas funcionalidades nativas
3https://jquerymobile.com/
através de bindings de JavaScript [HHM13]. Duas das frameworks mais utilizadas são o Cordova5 da Apache e o Ionic6.
Figura 2.3: Abordagem Black Box7
2.2.2.3 Abordagem Interpretada
As soluções até então documentadas afiguram-se como alternativas pouco recomendáveis para quem procura a emulação das funcionalidades e usabilidade que as aplicações nativas oferecem. A abordagem interpretada é uma das opções que procuram responder a este dilema e que se ba-seia no pressuposto de mapear o código base em que a aplicação é desenvolvida para o respetivo código nativo. Um dos casos analisados e que faz parte desta classificação é o Titanium App-celerator[appb]. Esta framework faz parte da categoria das abordagens interpretadas na medida em que o código desenvolvido, neste caso utilizando JavaScript, é compilado com a ajuda de um mecanismo embutido (interpretador) de forma a ser traduzido no seu respetivo equivalente na componente nativa de cada plataforma.
Este projeto da autoria da empresa Axway é open-source e conta já com uma extensa documen-tação e comunidade, pelo que, se torna uma solução apelativa para um developer cuja preferência recai na utilização de linguagens web, mas que exija extrair o máximo das funcionalidades nativas.
2.2.2.4 Abordagem Gerada/Cross-Compiled
A utilização de práticas de desenvolvimento de aplicações que se regem pela existência de uma base de código comum para criar aplicações funcionais em todas as plataformas, afigura-se extremamente atraente tendo em conta a incrível capacidade que oferece para que se atinja uma maior quota de mercado, com menores exigências. A abordagem gerada afigura-se como mais uma das alternativas que assentam nesta descrição.
5https://cordova.apache.org/ 6https://ionicframework.com/
Como o nome indica, este tipo de implementação baseia-se na utilização de um compilador para transformar uma base de código fonte, escrito na linguagem da respetiva framework, de alto nível, num executável compatível com um sistema operativo diferente daquele onde é feita a com-pilação (origem do nome em inglês cross-compilation), traduzindo-se, por isso, numa linguagem de baixo nível como assembly ou código máquina [Wil]. Para cada plataforma que queremos implementar é gerado um executável diferente.
Reunindo as mesmas vantagens que as aplicações híbridas, as aplicações desenvolvidas utili-zando software como o Xamarin8, conseguem assemelhar-se às (e até ser consideradas) aplicações nativas, nomeadamente ao nível da performance. Apresentam, no entanto, uma contrariedade que é não serem imediatamente compatíveis com as atualizações mais recentes em cada sistema ope-rativo, uma vez que dependem de terceiros para a implementação dessas mesmas atualizações na frameworkutilizada.
Figura 2.4: Arquétipo da abordagem Gerada [LLNES16]
2.3
A Transição do Online para o Offline
A utilização do telemóvel e das aplicações através dos quais podemos aceder já faz parte do nosso quotidiano, tendo-se tornado um utensílio essencial para o nosso dia-a-dia, seja por motivos pessoais, seja por motivos profissionais, por nos abrirem um leque incrível de funcionalidades, ali-adas à mobilidade e portabilidade que estes aparelhos oferecem, mesmo sem descurar a qualidade do conteúdo.
A capacidade de utilizar tecnologia de uma forma não estática, ou remota, conhecida como mobile computingapresenta algumas limitações no que diz respeito aos recursos limitados e às capacidades de conexão à rede. É, no entanto, cada vez mais importante que todas as funciona-lidades de um aplicação que desejamos utilizar sejam acessíveis mesmo na inexistência de uma ligação à internet, quer por opção (custos adicionais com redes móveis), quer por outros motivos que nos são alheios (locais remotos, redes pouco seguras, instabilidade da conexão, etc.). Este
tópico revela-se importantíssimo, nomeadamente no âmbito desta dissertação, uma vez que res-tringe, por vezes, o acesso a recursos fulcrais para quem deseja, nomeadamente, gerir informação relativa a um negócio.
Existem, no entanto, várias soluções que visam apresentar uma resposta a este problema, po-dendo o programador, que vise a criação de aplicações que suportem a utilização das suas funcio-nalidades sem conexão à rede, ou com uma conexão instável, recorrer a três tipos de técnicas:
• Armazenamento Local. • Armazenamento em Cache. • Bases de Dados Locais
2.3.1 Armazenamento Local
Antes do aparecimento do HTML5 o armazenamento de dados era feito em cookies. Uma cookieé um pequeno arquivo de informação criado para guardar informações sobre a navegação, tendo, no entanto, severas limitações, nomeadamente no que diz respeito ao espaço de armaze-namento que dispõe - 4096 bytes (4kB). Com a introdução desta nova versão da linguagem de representação de conteúdos web, surgiu um novo conceito baseado no supracitado que é o de Lo-cal Storage, ou Armazenamento LoLo-cal. Para permitir a utilização deste tipo de técnica existe uma API que permite o acesso a dois tipos de objetos distintos denominados: Session Storage e Local Storage.
O primeiro diz respeito a um tipo de armazenamento temporário sendo associado à janela web em que foi criado e destruído aquando do seu encerramento. Em contraste com o citado, o objeto de local storage armazena informação de forma permanente, ou até ser destruído[Roc].
1 sessionStorage.setItem("name","XYZ");
2 sessionStorage.removeItem("name");
3 sessionStorage.name="ZXY";
4 sessionStorage.clear();
Listagem 2.1: Objeto Session Storage
1 localStorage.setItem("name","XYZ");
2 localStorage.removeItem("name");
3 localStorage.name="ZXY";
4 localStorage.clear();
Listagem 2.2: Objeto Local Storage Todavia, este conceito não é exclusivo à criação de web applications, tendo, igualmente, uma implementação homónima em ambientes nativos. No caso dos dispositivos com sistema operativo Android é possível utilizar este mecanismo através da criação de objetos da classe SharedPrefe-rences que permite guardar qualquer tipo de dados primitivos: booleanos, inteiros, floats, etc., ou, através da criação de ficheiros guardados diretamente no armazenamento interno do dispo-sitivo, através de métodos que permitem a utilização de objetos do tipo FileOutputStream, seja para escrita, seja para leitura e do método respetivo openFileOutput[And]. Os ficheiros deste tipo são apenas visíveis no âmbito da aplicação e são removidos caso esta seja desinstalada. No sistema operativo iOS, a criação de ficheiros semelhantes aos supracitados é igualmente permi-tida sendo a forma como é feito o seu armazenamento crucial para a correta implementação
desta técnica: documentos e outro tipo de dados devem ser armazenados no diretório <Appli-cation>_Home/Documents[Appa].
2.3.2 Armazenamento em Cache
O armazenamento em cache permite aos programadores definir quais as páginas web que devem estar acessíveis aos utilizadores que não possuam qualquer conexão à rede. Este tipo de armazenamento recorre à criação de um ficheiro, denominado manifest, que permite ao browser, que normalmente obtém as páginas através de um pedido HTTP, saber quais destas, previamente descarregadas, estão disponíveis ao utilizador quando este pedido não é passível de ser executado. A utilização deste mecanismo em ambiente nativo segue uma implementação semelhante à de utilização de técnicas de armazenamento local. No que ao Android diz respeito é utilizado o método getCacheDir, em vez do supramencionado, para garantir que os ficheiros criados são provisórios. No caso do iOS apenas temos de mudar o diretório de leitura e escrita para: <Appli-cation_Home>/Library/Caches, caso se tratem de ficheiros que podem ser transferidos novamente, ou <Application_Home>/tmp, caso sejam ficheiros temporários.
2.3.3 Armazenamento em Bases de dados Locais
A utilização das técnicas acima descritas, apesar de ajudarem a retrair os efeitos da falha ou falta de conexão, não se afiguram como viáveis para o armazenamento de quantidades de informação consideráveis que a implementação de um ponto de venda móvel exige. Dessa forma, uma das vertentes de armazenamento local visa a criação de bases de dados locais no dispositivo. O HTML5 trouxe, igualmente, avanços no que diz respeito à aplicação deste tipo de conceito abrindo espaço para dois tipos de alternativas: WebSQL e bases de dados indexadas (Indexed DB). O primeiro conceito, já descontinuado, procurava trazer o conceito de base de dados para o lado do cliente, mas a sua utilização não teve continuidade com o surgimento do HTML5 e deu lugar à utilização de bases de dados indexadas, que perseguem o mesmo propósito. Consistindo numa API de baixo-nível, a sua utilização visa simular o funcionamento de uma bases de dados relacional comum, permitindo o armazenamento de dados em formato de objetos, sendo estes indexados por uma chave [Moz]. Esta tipologia permite o armazenamento de grandes quantidades de informação estruturada no lado do cliente e, uma vez que utiliza índices, a pesquisa de alta performance nestes mesmos dados.
Contudo, a utilização de tecnologias web para a criação de aplicações móveis nem sempre é conveniente, pelo que os seus mecanismos para possibilitar o acesso a informação em modo offline não se afiguram válidos para as restantes perspetivas de implementação.
De forma a ultrapassar esta questão é possível utilizar este mecanismo de bases de dados locais recorrendo a outro tipo de arquiteturas de construção de aplicações utilizando bases de dados alojadas nos próprios dispositivos móveis.
2.3.4 Sistema de Bases de dados distribuídas
Uma aplicação móvel necessita de dados para funcionar. Tradicionalmente, este dados provêm de uma base de dados na rede e que, por esse motivo, só pode ser acedida caso exista uma conexão constante e suficientemente rápida para garantir a funcionalidade da mesma. Conforme já menci-onado, a existência de condições propícias para esta conexão, nem sempre é garantida no contexto de mobile computing. Este conceito pretende garantir que um utilizador tem a oportunidade de aceder a informação em qualquer lugar, seja quando for [Sta05].
A solução encontrada para garantir que os dados conseguem ser utilizados de uma forma transparente para o utilizador, mesmo na inexistência de uma ligação à rede, é a replicação ou fragmentação das bases de dados originais nos próprios dispositivos. Este tipo de arquitetura poderá ser considerada semelhante à utilizada nos sistemas distribuídos, denominada por cliente-servidor. Este tipo de topologia afigura-se como a mais simples, mas poderão existir, igualmente, múltiplos servidores (multiple-servers/multiple-clients) [Özs].
Foram igualmente propostas algumas variações a este tipo de arquitetura, nomeadamente adi-cionando um agente intermediário na estrutura compondo uma arquitetura servidor-agente-cliente. O papel deste agente varia consoante as implementações de diferentes autores, podendo residir seja no servidor, seja no cliente, mas mantendo a topologia fixa deste tipo de implementação.
Este mesmo conceito de topologia fixa é posta de parte noutro tipo de abordagens que permi-tem que os nós da rede se organizem ao longo do permi-tempo de forma dinâmica. Estes nós podem ter um papel de servidores ou clientes, implicando que não existe apenas uma conexão muitos para um, mas muitos para muitos, originando uma transmissão de dados entre os vários dispositivos móveis. Este modelo assemelha-se à arquitetura peer-to-peer nos sistemas distribuídos.
2.3.4.1 Sumariar os Dados
Um dos problemas a endereçar neste tipo de solução é a forma como é feita a cópia de informa-ção da base de dados primária para a base de dados no dispositivo móvel. Esta última poderá não necessitar de conter o conteúdo original por inteiro, ou tal opção poderá não ser a mais indicada devido a limitações de armazenamento ou de custo de transmissão.
Dada uma base de dados relacional, é então possível aplicar técnicas de fragmentação de forma a dividir cada relação em partições. Este processo, conhecido como Data Summarisation [CR05], pode ser feito de três formas: fragmentação horizontal, vertical e híbrida.
A fragmentação horizontal envolve a redução do número de tuplos presentes na base de dados local, podendo ser feita através da agregação pelo valor de um determinado atributo. A fragmenta-ção vertical, pelo contrário, não limita o número de linhas presentes na tabela, mas as suas colunas, diminuindo o número de atributos. Estas duas técnicas podem ser utilizadas em conjunto dando origem a uma abordagem híbrida que produz vistas materializadas. Consoante a ordem pela qual aplicamos os dois tipos de fragmentação a abordagem híbrida extrapola diferentes resultados.
Figura 2.5: Comparação de várias técnicas de Fragmentação [CR05]
2.3.5 Protocolos de Replicação
Independentemente da forma como é feita a cópia da informação presente na base de dados primária, uma vez que a informação se encontra espalhada por várias localizações distintas, não sendo, de todo, imutável, é necessário estipular métodos para gerir e consolidar as modificações feitas entre os vários nós da rede, propagando a informação de forma a garantir a (eventual) con-sistência dos dados.
As bases de dados replicadas são, de acordo com Alexander Stage[Sta05], um conjunto de bases de dados que armazenam cópias da mesma informação. De forma a existir um fluxo de dados que mantenha a consistência dessa mesma informação, poderão ser utilizadas diferentes arquiteturas que evidenciam características diferentes no que diz respeito, nomeadamente, ao seu sincronismo e à topologia que cada nó presente na rede adota.
A utilização de técnicas síncronas, ou gananciosas (eager) implica a propagação instantânea das atualizações dos dados para todas as réplicas numa só transação mantendo-as sempre atuali-zadas e num estado consistente [GHOS96]. Este tipo de implementação é bastante difícil de ser concretizada de uma forma eficiente, levantando problemas ao nível da performance e dos tempos de resposta para cada transação, não sendo de todo adequado a ambientes móveis. Esta abordagem contrasta com a abordagem ociosa (lazy) que permite que as modificações se propaguem de forma assíncrona para todas as réplicas. Quando é utilizado este tipo de protocolo, uma atualização é reproduzida nos restantes nós apenas depois de ter sido aplicada na réplica que a iniciou [CR05]. É, por vezes, utilizada uma abordagem que coaduna ambas as técnicas de forma a aumentar a performance de interrogação de um sistema que utilize uma topologia síncrona.
No que diz respeito à estruturação da rede, os protocolos de replicação subdividem-se tendo em conta os nós a partir dos quais são efetuadas as atualizações aos dados, ou seja, se estas são feitas apenas num só nó, ou se a atualização pode ser feita em qualquer nó.
2.3.5.1 Abordagem Single Master
A arquitetura mais simples e pragmática é a que implica a existência de uma base de dados que funciona como a source of truth[Sta05]. Nesta base de dados, considerada a réplica principal, a cópia mestre, é que são feitas e propagadas todas as modificações que ocorrem no sistema para as denominadas réplicas secundárias, evitando-se, assim, conflitos no que diz respeito à alteração concorrente de dados por parte de várias cópias.
Esta abordagem, denominada Single Master, ou Primary Copy, poderá ainda ser divida tendo em conta a forma como é feita a propagação da informação ao longo do tempo. Caso seja um
processo síncrono, conhecido por Eager Primary Copy Replication [WPS+00], a operação de modificação dos dados é feita para todas as réplicas de uma só vez, sendo a cópia mestre a respon-sável por se assegurar que as restantes recebem com sucesso os dados e, se necessário, lidar com conflitos. Este tipo de processo não necessita de um mecanismo de coordenação, uma vez que existe apenas um nó responsável pela propagação de informação, tentando, no entanto, assegurar a atomicidade do protocolo, garantindo que este é bem sucedido apenas se todas as transações que o compõem forem concluídas com sucesso (all-or-nothing). De forma a que esta propriedade seja posta em prática é necessária a implementação de protocolos de atomic-commitment, como o Two-Phase Commit Protocol(2PC).
Este protocolo visa coordenar todas as réplicas de acordo com a decisão de aceitar ou reverter a transação. Para que uma réplica possa aceitar uma transação deve ser capaz de a armazenar localmente e, assim que possível, enviar, então, uma mensagem a informar a cópia mestre de que concorda com a mesma. No caso de ocorrer uma falha, este mecanismo não permite que esta seja evitada, mas permite saber a origem da mesma, identificado o nó no qual falhou a aceitação da transação. Tal como Sang Hyuk Son [Son88] documenta, existem ainda outros mecanismos que facilitam esta fase de concordância entre todas as réplicas: o protocolo de votação Quorum Consensus permite que apenas uma maioria das réplicas estejam operacionais para que o voto seja bem sucedido, na medida em que apenas uma maioria dos votos é necessária para dar como terminado o processo, ao contrário do que acontece no 2PC; existem ainda outras variantes deste protocolo que envolvem uma votação com pesos diferentes para cada réplica, ou métodos em que cada conjunto de dados está associado a uma cópia (Primary Copy), para a qual as atualizações que dizem respeito a este conjunto de dados são em primeiro lugar direcionadas.
Este tipo de abordagem síncrona é tradicionalmente usada para garantir a existência de cópias de segurança atualizadas e que podem substituir a base de dados principal caso esta falhe.
Por outro lado, poderá ser seguida uma abordagem que se baseie numa topologia assíncrona, também chamada de Lazy Primary Copy Replication. Neste caso, a atualização de informação feita entre a cópia mestre e as cópias escravas pode ser concluída antes de existir qualquer coorde-nação entre réplicas. Num passo posterior existe uma fase denominada de Agreement Coordina-tion Phase, na qual todas as cópias atingem um estado consistente, sendo da responsabilidade da cópia primária a coordenação da ordem das várias transações provenientes das diferentes réplicas e consequente resolução de possíveis conflitos.
Figura 2.6: Replicação Cópia Primária Síncrona [Sta05]
Figura 2.7: Replicação Cópia Primária Assín-crona [Sta05]
2.3.5.2 Abordagem Multi Master
A exigência de que todas as atualizações dos dados sejam concluídas num só nó da rede é impraticável em algumas situações, nomeadamente no que diz respeito à construção de um sistema como o proposto nesta dissertação. A abordagem Multi Master afigura-se como uma alternativa viável, uma vez que consente a modificação de informação por parte das várias réplicas de uma forma independente entre elas, mas tornando o processo de coordenação mais complexo.
A transmissão de informação pode, de igual forma, ser inserida em dois contextos separados, conforme o sincronismo do processo de troca de informação entre réplicas. Caso a propagação seja feita de forma síncrona, Eager Update Everywhere Replication, existem dois métodos para garantir que esta é bem sucedida: os pedidos de atualização podem ser feitos de forma serializada por todas as réplicas, ou, de forma concorrente.
Ao contrário do seu homónimo em que existe apenas uma fase de coordenação final, neste caso, para lidar com a concorrência do processo, existe a necessidade de coordenar as várias ré-plicas numa fase denominada Server Coordination phase. Nesta, são frequentemente utilizados métodos de locking que apenas permitem que a transação seja levada a cabo, uma vez que a cópia em que estamos a trabalhar envie um pedido de bloqueio, para os dados que pretendemos modi-ficar, que seja aceite pelas restantes. Este tipo de procedimento é chamado Distributed Locking [WPS+00].
No caso da propagação assíncrona, cada nó poderá atualizar a informação sem necessitar de aguardar por uma coordenação entre réplicas. Algum tempo após a transação, as atualizações são propagadas para as restantes cópias, almejando-se atingir um estado de consistência entre a informação presente em cada uma. Este processo, denominado por reconciliação, pode revelar-se bastante complexo caso tenham existido transações concorrentes aos mesmos dados, tornando pre-mente a existência de mecanismos de resolução de conflitos que permitam chegar a um consenso relativamente às modificações feitas.
Figura 2.8: Replicação Multi Master Síncrona [Sta05]
Figura 2.9: Replicação Multi Master Assín-crona [Sta05]
2.3.6 Resolução de conflitos
A criação, modificação e eliminação de dados é uma necessidade premente nos vários nós que compõem uma rede de bases de dados distribuídas no que diz respeito a sistemas que se asse-melham ao descrito nesta dissertação. A utilização de um sistema de gestão comercial implica,
constantemente, a necessidade de serem atualizados dados relativos a clientes, artigos e documen-tos, implicando, de igual modo, a criação e modificação de movimentos de entrada e saída de stock.
A resolução de conflitos assume, por isso, um papel determinante na verificação e manutenção da consistência e integridade dos dados armazenados nos vários dispositivos, impedindo perdas de informação e o surgimento de incongruências que levem a problemas no normal funcionamento do negócio. Serão analisadas, de seguida, algumas técnicas que visam lidar com estes mesmos conflitos, seguindo a categorização proposta por Mohammad Faiz e Udai Shanker [FS16]:
• Sincronização Compreensiva: A sincronização é feita através da cópia integral de toda a informação armazenada num dispositivo, para outro, de forma a que seja feita uma com-paração local. Apesar de ser extremamente ineficiente, tem a vantagem de ser fácil de implementar e de garantir que todas as mudanças são tidas em conta e aplicadas.
• Sincronização baseada em Status Flags: Cada cliente mantém um conjunto de Flags para sinalizar mudanças num certo conjunto de dados, sendo apenas estes transferidos para as restantes réplicas. Esta tipologia serviu de inspiração para a criação do protocolo SyncML [LL12] que se baseia na troca de mensagens em formato XML. O protocolo supramencio-nado encontra-se agora enquadrado no âmbito da iniciativa OMA - Open Mobile Alliance9. • Sincronização baseada em TimeStamps: O método acima mencionado exige a criação de flagspara guardar informação extra que indique quais os clientes com quem já foi efetu-ada a sincronização, revelando-se, por isso, pouco eficiente. A sincronização baseefetu-ada em timestamps, por outro lado, apenas necessita de manter informação sobre a última vez em que os dados foram modificados e a última vez em que foi realizada uma sincronização. Este tipo de implementação é, normalmente, row-based, exigindo a manutenção de um es-tado para cada linha de uma tabela de dados. Esta solução tende, porém, a não se revelar ideal, uma vez que dois utilizadores poderão efetuar mudanças a uma mesma linha da tabela, mas a atributos diferentes. O utilizador que sincronizasse as mudanças primeiro vê-las-ia propagadas pelas restantes réplicas, no entanto o segundo veria as suas descartadas. Tendo em conta esta limitação, Divyashikha Sethia [SMC+14] preconiza a criação de um proto-colo de sincronização baseado em timestamps cell-based, ou seja, para cada tabela de dados é criada uma tabela adicional que segue a mesma estrutura, mantendo a mesma chave pri-mária, mas substituindo os atributos por timestamps. Este método visa, sobretudo, a redução extrema da quantidade de informação transferida entre os nós da rede.
• Sincronização Matemática: Mecanismo que visa a utilização de propriedades/funções ma-temáticas para permitir que os dados sejam sincronizados corretamente.
• Sincronização SAMD: A sincronização baseada no protocolo SAMD [CCP+10] é uma va-riação do método acima descrito e visa ser invariante às tecnologias utilizadas para imple-mentar e manipular as bases de dados, seja no lado do servidor, seja no lado do cliente. A 9http://openmobilealliance.org/
solução passa pela utilização de uma função de hashing10que é aplicada aos valores presen-tes em cada linha de uma tabela de dados. O resultado da aplicação desta função é guardado numa tabela extra denominada digest table. Este processo ocorre em cada nó da rede, de forma a que possam ser detetadas diferenças entre a informação presente em cada um: os dados em duas linhas de uma mesma tabela, em diferentes nós, são diferentes se o seu valor hashedé diferente.
• Sincronização baseada em logs: A utilização de transaction logs permite a gravação de cada modificação feita numa base de dados ao nível da transação visando garantir o cumprimento das propriedades ACID bem como proporcionar a possibilidade de recuperar de falhas de sistema. A sincronização é feita através da troca destes ficheiros, tendo, cada réplica, que replicar cada transação.
2.3.7 Tecnologias
A utilização de técnicas de replicação e sincronização é uma necessidade que já pode ser suprida recorrendo a várias soluções presentes no mercado. Foi, por isso, feito um breve levanta-mento de tecnologias que pretendem apresentar uma resposta neste âmbito, bem como conciliá-lo com as potencialidades das aplicações móveis, tal como é pretendido no âmbito desta dissertação. • Firebase11: Ferramenta da Google que permite implementar uma rede de bases de dados
distribuídas para dispositivos móveis e plataformas web. É cloud-based e não relacional, sendo os dados guardados em formato JSON.
• CouchBase12: Mais concretamente a solução Couchbase Mobile, procura direcionar o seu
foco especialmente para os dispositivos móveis oferecendo a possibilidade de criar aplica-ções móveis e web de uma forma "rápida, segura e poderosa", oferecendo uma base de dados "completamente integrada, sincronização em tempo real, segurança ao nível empresarial e um servidor facilmente escalável".
• CouchDB13: A solução da Apache foca-se em proporcionar um processo de replicação e
sincronização para arquiteturas "Multi-Master, que podem escalar desde contextos Big Data até mobile", através da utilização da sua API. O protocolo que implementa é já estendido por um conjunto de outras soluções nomeadamente o PouchDB e o Cloudant.
• SymmetricDS14: Software open-source baseado na linguagem de programação Java que
pro-cura oferecer um protocolo que suporte múltiplas arquiteturas de replicação, bem como ope-rações entre diferentes plataformas. Visa ser facilmente escalável e oferecer uma solução que permite replicar informação de forma assíncrona.
10Uma função de hash mapeia dados de comprimento variável para dados de comprimento fixo. 11https://firebase.google.com/
12https://www.couchbase.com/ 13http://couchdb.apache.org/ 14https://www.symmetricds.org/
2.4
Gestão de Stocks
A utilização de informação dispersa por vários nós na rede de base de dados distribuídas levanta, conforme descrito na secção anterior, problemas ao nível da consistência e integridade dos dados. A aplicação de mecanismos de sincronização e resolução de conflitos, fruto das várias modificações feitas em cada uma das réplicas, visa responder a estes problemas, tentando que seja atingido um estado de eventual consistência entre todas. Contudo, este tipo de mecanismos não tem em conta algumas regras de negócio fulcrais, nomeadamente no que concerne à gestão e modificação de valores que dizem respeito aos stocks dos vários produtos.
Caso um vendedor opte por utilizar o software de gestão numa situação de inacessibilidade à rede, de modo a processar uma compra, não possui informação em tempo real sobre o atual número de cópias do(s) artigo(s) que deseja vender disponíveis em stock. É possível, no cenário supracitado, que a informação que se encontra no seu dispositivo, obtida após a última sincroniza-ção, já tenha sido alterada numa outra réplica, iludindo o vendedor no que diz respeito ao número de unidades que pode realmente comercializar.
De forma a tentar mitigar as consequências de tais situações, pretende-se efetuar um estudo exploratório, no âmbito do Data Mining, relativo a mecanismos preditivos que permitam, tendo em conta informação histórica de vendas passadas, estimar se uma venda poderá, ou não, ocorrer sem que esta implique violações de stock. O objetivo final será anexar, se possível, um novo módulo à restante solução até então projetada, que complemente o mecanismo de sincronização e dê uma resposta a este problema.
2.4.1 O Data Mining
Data Miningpode ser definido como o processo que envolve a análise de grandes quantidades de dados, com o intuito de encontrar relações entre os mesmos e de os sumariar de diferentes formas que sejam compreensíveis e úteis ao analista [dS15].
Apesar de não se tratar de uma área recente no âmbito da computação, apenas nos últimos anos ganhou uma preponderância especial graças ao aparecimento e crescimento do conceito de Big Data que permitiu o acesso a volumes de informação consideráveis e mais ricos ao nível da variedade do conteúdo. Dependendo do intuito da análise a ser feita, as técnicas de Data Miningvisam a criação de modelos estatísticos que podem ter um carácter puramente descritivo, identificando propriedades que caracterizam os dados analisados e procurando correlações entre os mesmos, ou preditivo, na medida em que são utilizados valores históricos para procurar prever tendências e estimar valores desconhecidos, ou futuros, de uma variável de interesse.
No âmbito da mineração de dados, podem ainda ser aplicadas diversas técnicas de Machine Learning. Este conceito diz respeito ao domínio da ciência que explora a capacidade de uma máquina de compreender informação e aprender com base neste conhecimento sem que seja ex-plicitamente programada para o fazer. Dentro deste contexto de aprendizagem podemos encontrar duas abordagens distintas, distinguindo se esta é feita de uma forma supervisionada ou não.
No caso da aprendizagem não supervisionada (Unsupervised Learning) a máquina tem como objetivo identificar a estrutura dos dados e as relações que entre estes existem partindo de um conjunto de dados de entrada sobre o qual não é dada qualquer informação dos valores de saída esperados. Uma das abordagens mais importantes neste contexto é denominada de Clustering e implica a formação de clusters15 de informação, tendo como base uma característica específica dos dados de entrada. Cada valor novo é depois incorporado ao cluster mais apropriado para as suas características.
Em contrapartida, na aprendizagem supervisionada, o conjunto de dados, que é considerado o input do problema, já se encontra previamente etiquetado como pertencendo a uma certa classe ou com um output respetivo. A máquina tem como objetivo criar uma função que correlacione ambos tanto quanto possível para que seja capaz de generalizar a abordagem para novos dados de entrada cuja saída é desconhecida.
Os métodos de Data Mining de carácter preditivo serão o foco desta dissertação e podem ser enquadrados em dois tipos, consoante o tipo de previsão que desejamos fazer. Por um lado, os problemas de regressão visam a criação de uma função matemática que permita inferir o valor numérico de uma determinada variável a partir de um conjunto de atributos de input. A função obtida deve, posteriormente, ser capaz de emitir novas previsões para outros valores de entrada desconhecidos. Numa outra perspetiva, surgem os problemas de classificação nos quais são uti-lizados dados previamente rotulados como pertencentes a uma determinada classe como um con-junto inicial, para a construção de um modelo preditivo que permitirá inferir a que classe pertence um qualquer novo item que desejemos classificar. O output esperado é meramente categórico, envolvendo respostas como "Azul", "Verde", ou "Doente"e "Não Doente".
2.4.1.1 Métodos de Classificação
Os métodos de classificação podem ser agrupados consoante a abordagem tomada em cinco categorias:
• Classificação baseada em probabilidades: Baseia-se num modelo probabilístico que permite obter a probabilidade de uma instância pertencer a uma determinada classe. A base teórica desta tipologia de classificação é a aplicação do teorema de Bayes que segue a equação:
P(y|X ) = P(X |y) ∗ P(y)) P(X )
Os métodos mais estudados que se baseiam nesta abordagem são as Redes de Bayes e o algoritmo Naïve Bayes [PD11].
• Classificação baseada na distância: Uma outra abordagem para prever a classe a que um objeto poderá pertencer baseia-se em medidas de similaridade que comparam este objeto com os restantes, nomeadamente através do cálculo da distância. Normalmente a fórmula utilizada é a euclidiana, no entanto existem outras alternativas conhecidas:
– Distância de Hamming – Distância de Manhattan – Distância de Minkowski
. O algoritmo K-NN, ou K-Nearest Neighbors é um dos algoritmos de machine learning mais simples que aplica esta técnica. Assumindo que cada instância dos dados pode ser representada como um ponto no espaço, este limita-se a procurar os K exemplos de treino mais próximos, da instância que queremos classificar, neste mesmo espaço. O objeto é então classificado de acordo com a maioria dos votos dos seus vizinhos [Mit97,Phy09].
Figura 2.10: K-Nearest Neighbours [Car16]
• Classificação utilizando árvores de decisão: Uma árvore de decisão segue uma estratégia de dividir e conquistar que consiste na divisão recursiva de um problema complexo em múltiplos sub-problemas. As soluções destes sub-problemas podem depois ser agrupadas para apresentar uma resposta para o problema mais complexo [Car16]. A geração destas árvores de decisão pode ser feita utilizando vários algoritmos, nomeadamente ID3 e a sua extensão, o C4.5 [Kot07].
Figura 2.11: Exemplo de geração de uma árvore de decisão relativa à probabilidade de jogar ou não ténis16
• Redes Neuronais: O elemento mais básico do nosso cérebro é o neurónio. Estas células permitem que tenhamos a capacidade de nos lembrarmos, de pensarmos e de atuarmos e
cada uma está ligada a dezenas de milhar de outras semelhantes. As redes neuronais ar-tificiais,frequentemente associadas ao termo computação neuronal, pretendem emular esta arquitetura biológica. Um conjunto de neurónios artificiais são dispersos em várias camadas que estão ligadas entre si, possivelmente através de ligações pesadas. Estas camadas estão divididas em três tipos. Uma primeira camada que recebe os dados de entrada, uma, ou mais, camadas intermédias escondidas e uma camada de saída. O principal problema na criação de uma rede neuronal é a estipulação do número de camadas a criar e do número de neurónios que deve estar presente em cada uma. Este último tópico é especialmente sensí-vel, uma vez que a definição de um número de neurónios superior ao necessário pode levar a uma adaptação excessiva aos dados de treino, impedindo que o modelo se torne numa fiel representação da realidade, perdendo capacidade de generalização. Este fenómeno é denominado por Overfitting.
Figura 2.12: Redes Neuronais Artificiais [Kle98]
• Support Vector Machines: As SVM (figura2.13) são algoritmos cujo foco principal come-çou por ser solucionar problemas lineares de classificação. A sua evolução permitiu a sua adaptação a problemas não lineares. Este tipo de método baseia-se na criação de uma di-visória (linha, plano, hiperplano) que procure maximizar a margem entre os pontos que lhe estão mais próximos e que pertencem a uma de duas classes. Quando não é possível encon-trar um separador linear os pontos são projetados num espaço dimensional superior, onde é possível ocorrer esta separação, através da utilização de um kernel. Numa variação deste método denominada Soft-Margin SVM, caso os pontos de ambas as classes não consigam ser divididos linearmente, aos pontos que são separados erroneamente é atribuído um peso menor.[Mey17]
