Criação do Web Service

As experiências realizadas até então serviram para criar, treinar e testar os vários modelos, de modo a avaliar a qualidade das suas previsões e consequente utilidade para fazer face ao problema exposto no âmbito desta dissertação. O objetivo final, passaria, no entanto, por utilizar um destes modelos criados para efetuar novas previsões e expor, de algum modo, esta funcionalidade, para

que fosse passível de ser utilizada, futuramente, nas aplicações da empresa. Estas exigências podiam ser supridas através da criação, no âmbito do Azure Machine Learning Studio, de uma experiência que disponibilizasse as capacidades preditivas de um modelo criado através de um web service.

Deste modo, o primeiro passo passou por guardar o melhor modelo criado, já treinado, e que dizia respeito à aplicação do algoritmo de florestas de decisão. Foi então criada uma outra experiência semelhante à que permitiu testar os vários algoritmos de regressão disponibilizados nos módulos do serviço da Microsoft. No entanto, neste caso, esta nova experiência fazia uso não dos módulos correspondentes aos vários algoritmos, mas do modelo supracitado.

De seguida, procedeu-se à conversão da experiência criada numa experiência preditiva atra- vés da opção Set Up Web Service disponível na interface do Azure. Deste modo, puderam ser adicionados dois módulos que permitiam definir os dados de entrada do web service a ser criado e a sua saída. O parâmetro a passar ao web service foi definido como o ID do produto para o qual se deseja fazer a previsão e o resultado como as previsões para as 4 semanas posteriores à última observação. Uma vez que se mantiveram os scripts correspondentes às restrições impostas à formação das séries temporais, o web service poderia igualmente retornar um erro 500, em vez da previsão, caso estas não fossem cumpridas para o produto cujo ID tinha sido fornecido como parâmetro de entrada. Uma vez concluído este processo, foi possível fazer deployment do serviço - opção Deploy Web Service.

Apesar de não ter sido possível acrescentar a solução apresentada como um módulo, de valor acrescentado, diretamente conectado à prova de conceito desenvolvida, este foi, de qualquer modo, sujeito a variados testes a partir do portal Azure Machine Learning Web Services, que permitiu simular o processo de chamda ao serviço e consequente obtenção de resposta - figura4.24.

Conclusões e Trabalho Futuro

Neste capítulo, é apresentada uma breve apreciação ao trabalho desenvolvido e ao cumpri- mentos dos requisitos pré-estabelecidos. É ainda apresentada uma sugestão para o planeamento de trabalho futuro, tendo em conta a melhoria e evolução do produto desenvolvido, de modo a garantir o cumprimento das normas funcionais e legais que permitam a sua adição ao leque de soluções a comercializar pela empresa Gestware.

5.1

Satisfação dos Objetivos

O desenvolvimento de uma solução que vise coadunar os requisitos inerentes à realização de uma dissertação e as exigências de uma empresa, para a qual esta é desenvolvida, não se afigura como uma tarefa fácil. Contudo, uma vez concluído o processo de desenvolvimento pode-se afirmar que o produto final cumpre com os requisitos estabelecidos a priori e reúne consenso quanto à sua qualidade.

Para que este sentimento de dever cumprido fosse atingido, foi necessário superar várias eta- pas e optar por diversas escolhas. Numa primeira etapa, foi premente fazer um estudo alargado que permitisse compreender o contexto envolvente ao projeto e tomar decisões acertadas relati- vamente às tecnologias a utilizar e tentar coaduná-las com as necessidades da empresa. Esta fase revelou uma importância extra, uma vez que a solução agregava conceitos de várias áreas distin- tas do ramo das tecnologias de informação e da informática em geral, nomeadamente no âmbito das aplicações móveis, bases de dados e Data Mining, pelo que foi útil criar uma base de conhe- cimento estruturada para permitir levar a etapa de desenvolvimento a bom porto, seguindo uma metodologia iterativa e sujeita a várias fases de validação.

No que à etapa de desenvolvimento diz respeito, foram tidas em conta, tal como referido ao longo desta dissertação, as condicionantes inerentes à empresa para a qual foi desenvolvida a aplicação. Manteve-se, por isso, inalterada, tanto quanto possível, a estrutura da base de dados

já existente e respeitaram-se as normas legais que regem o funcionamento de aplicações do foro financeiro, nomeadamente os Pontos de Venda.

Ao nível das tecnologias utilizadas ao longo desta etapa, verificou-se que foram uma boa escolha, integrando-se e funcionando bem em conjunto. No que diz respeito ao Xamarin, nome- adamente à framework Xamarin.Forms, esta afigurou-se como uma boa opção para a criação de uma prova de conceito, graças à agilidade que oferece na criação de aplicações compatíveis com múltiplas plataformas e cujas funcionalidades podem fazer usufruto do completo arsenal de ferra- mentas disponibilizadas pelos dispositivos. As interfaces criadas, apesar de simples, revelaram-se extremamente fáceis de usar e permitiram concentrar tanta informação quanto necessária. Exis- tem, no entanto, alguns aspetos negativos, uma vez que, por vezes seria ideal ter mais alguma margem no que diz respeito à personalização dos elementos numa página. A falta, por exemplo, de bindable pickers, ou de funcionalidades de auto-complete numa entry, ou no próprio picker, não permite acrescentar funcionalidades que melhorariam a experiência de utilização de um utili- zador do sistema. Por outro lado, apesar de terem sido feitos testes exaustivos - a descrição da sua realização pode ser consultada no anexoA.3- recorrendo não só ao dispositivo pessoal, mas aos emuladores disponibilizados no IDE utilizado, a fase de testes não foi passível de ser estendida à plataforma iOS, uma vez que não se teve acesso a um dispositivo com esse sistema operativo, ou a um computador Mac onde fosse possível utilizar os emuladores respetivos. É de realçar, no entanto, que, uma vez que a base de código desenvolvida é toda em C#, o produto será facilmente reaproveitado pela empresa, uma vez que os seus produtos também possuem essa mesma base.

Relativamente à utilização do serviço Azure Mobile Apps, esta foi facilitada, pois este apre- senta uma documentação detalhada, incluindo uma secção exclusivamente dedicada ao aproveita- mento das suas funcionalidades em ambiente Xamarin. Deve ser também mencionado que, além de ter permitido suprir todos os requisitos inerentes ao funcionamento offline da aplicação, faci- litou, consideravelmente, a realização de certas tarefas, nomeadamente a criação do backend que o suporta, através das soluções disponibilizadas no portal dedicado, fazendo jus à premissa de permitir criar aplicações que beneficiem dos serviços do Azure de uma forma ágil e expedita.

Após ser analisada a utilização deste serviço e das potencialidades do mesmo, fica a perceção de que, não obstante as imposições relacionadas com a criação de certos campos nas tabela de base de dados e a incapacidade de gerir relações e chaves primárias de forma nativa, este se afigurou como uma boa opção para permitir a integração com a estrutura de base de dados já em utilização pela empresa. O que se verifica atualmente no mercado, nomeadamente tendo em conta as alternativas apresentadas no capítulo2, é que existe uma grande oferta de soluções que visam responder ao problema de criação de aplicações que encapsulem um modo de funcionamento offline, mas que se baseiam em estruturas de dados não relacionais, ou outras, o que dificultaria ou impossibilitaria esta integração.

É de destacar ainda que, no âmbito deste serviço, poderão ainda ser acrescentadas mais funcio- nalidades de valor acrescentado à aplicação, nomeadamente push notifications, ou acesso a opções de armazenamento de dados não estruturados, o que se afigura como um fator aliciante para dar continuidade à sua utilização.

Dada a importância de perceber de que forma o produto final correspondia às expectativas criadas, as suas funcionalidades foram validadas e testadas com a supervisão dos Engenheiros Tiago Nobre e Vítor Pinto da Gestware, que consideraram que a prova de conceito criada cumpria os requisitos estabelecidos, quer a nível de funcionalidades, quer a nível de qualidade. É ainda de destacar o apoio dado por ambos ao longo de todo o processo de desenvolvimento desta dissertação e o seu auxílio no que ao enquadramento logístico, estrutural e legal, que rodeava a criação da prova de conceito, dizia respeito.

Apesar da criação da prova de conceito poder ser considerada como um sucesso, o desenvol- vimento do módulo preditivo não cumpriu as expectativas definidas a priori, uma vez que, por falta de dados passíveis de serem utilizados e cuja qualidade não colocasse em causa os resultados obtidos, não foi possível integrar o mesmo com a prova de conceito, de forma a criar um sistema uno. Este foi, mesmo assim, desenvolvido recorrendo a fontes de dados externas e apresentou bons resultados, augurando que uma possível adaptação à realidade da empresa, uma vez disponíveis dados suficientes, tivesse tudo para correr bem. No entanto, é de frisar que, conforme demons- trado pela análise dos resultados dos algoritmos, a sua aplicação a um contexto real teria de ser cautelosa, uma vez que os indicadores que podem ser obtidos através destes métodos têm sempre uma margem de erro que, por vezes, pode ser substancial. Deste modo, apesar de se poderem vir a revelar como excelentes ajudas à tomada de decisão sobre a possibilidade de poder ocorrer, ou não, uma venda, poderão por vezes levar ao engano o utilizador do sistema, pelo que não devem, no entender do autor, servir como fontes de verdade/reguladores.

Não obstante os excelentes resultados, uma vez que se trata apenas, como supramencionado, de uma prova de conceito, existe ainda bastante margem para a introdução, não só de melhorias, mas também de novas funcionalidades que tornem o sistema mais robusto e equiparável ao sistema em que se baseou, o Gestware Cloud, para que, em última instância, seja considerado apto para uma possível comercialização.