UNIVERSIDADE DO SUL DE SANTA CATARINA JONATHAN CLEITON ALVES APLICAÇÃO DE GERENCIAMENTO FINANCEIRO FAMILIAR WEB COM INTERFACE MOBILE

Transcrição

1 UNIVERSIDADE DO SUL DE SANTA CATARINA JONATHAN CLEITON ALVES APLICAÇÃO DE GERENCIAMENTO FINANCEIRO FAMILIAR WEB COM INTERFACE MOBILE Unisul 2014

2 JONATHAN CLEITON ALVES APLICAÇÃO DE GERENCIAMENTO FINANCEIRO FAMILIAR WEB COM INTERFACE MOBILE Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Ciência da Computação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Ciência da Computação. Orientador: Prof. Jean Carlo Rossa Hauck, Dr. Palhoça 2014

3

4 JONATHAN CLEITON ALVES APLICAÇÃO DE GERENCIAMENTO FINANCEIRO FAMILIAR WEB COM INTERFACE MOBILE Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Ciência da Computação e aprovado em sua forma final pelo Curso de Graduação em Ciência da Computação da Universidade do Sul de Santa Catarina. Palhoça, 11 de Junho de Professor e orientador Jean Carlo Rossa Hauck, Dr. Universidade do Sul de Santa Catarina Prof. Flavio Ceci, Me. Eng. Universidade do Sul de Santa Catarina Prof. Richard Henrique de Souza, Me. Universidade do Sul de Santa Catarina

5 A Deus, que me guiou até aqui. Aos meus pais, que me ensinaram a importância da educação. Aos professores, que me incentivaram e forneceram oportunidades. E a minha esposa, pelo carinho, compreensão e companheirismo.

6 AGRADECIMENTOS A Deus, por não ter me deixado faltar saúde e força nesse momento. Agradeço também aos professores, que me apoiaram e acreditaram em minhas capacidades, as vezes até mais do que eu mesmo acreditei. A minha esposa Diana e meus pais, Anésio e Mara, que me apoiaram e respeitaram o tempo empenhado na realização desta tarefa. Ao meu orientador Jean e a coordenadora Inês, que me acompanharam e não me deixaram prometer mais do que o tempo me permitiria realizar. Às eventualidades, que me permitiram me tornar o que sou hoje. E a todos que, diretamente ou indiretamente, fizeram parte de minha formação, o meu muito obrigado.

7 É muito melhor lançar-se em busca de conquistas grandiosas, mesmo expondo-se ao fracasso, do que alinhar-se com os pobres de espírito, que nem gozam muito nem sofrem muito, porque vivem numa penumbra cinzenta, onde não conhecem nem vitória, nem derrota. THEODORE ROOSEVELT

8 RESUMO No contexto computacional atual, a necessidade de se manter as informações online e sempre disponíveis é algo inevitável. Entretanto, nem sempre o usuário possui acesso constante à internet, sendo um grande empecilho para este tipo de arquitetura. Dessa forma, muitas aplicações necessitam disponibilizar uma versão off-line dos dados, para que os usuários não percam o acesso aos seus dados nesses momentos. Com isso, através de um problema real, a gestão financeira familiar, este trabalho apresenta uma solução baseada em REST, com acesso tanto web via um cliente online, quanto off-line, em um cliente Android. Palavras-chave: REST, Android, Webservice.

9 ABSTRACT In current computing context, the need to keep online and always available information is inevitable. However, not always the user has constant access to the internet, being a major impediment to this type of architecture. Thus, many applications need to provide an offline version of the data so that users do not lose access to your data in these moments. With that, through a real problem, family financial management, this paper presents a REST-based solution, with online access via an web client and offline access in an Android client. Keywords: REST, Android, ebservice.

10 LISTA DE ILUSTRAÇÕES Figura 1 Exemplo de orquestração de serviços em SOA Figura 2 Exemplo de XML Figura 3 Exemplo de WSDL Figura 4 Exemplo de requisição SOAP Figura 5 Exemplo de Comunicação Clientes-Aplicação em REST Figura 6 Exemplo de Modelo Incremental Figura 7 - Arquitetura da Aplicação Figura 8 - Exemplo de Código AngularJS Figura 9 - Uma visão geral do ICONIX Figura 10 - Exemplo de Diagrama de Domínio Detalhado Figura 11 - Exemplo de um diagrama de casos de utilização Figura 12 - Objectos usados os diagramas de robustez Figura 13 - Exemplo de um diagrama de sequência Figura 14 - Exemplo de um diagrama de classes Figura 15 - Modelo de Domínio Figura 16 - Diagrama de caso de uso Figura 17 - Tela de Taxonomia (Centros de Custo) (TEL011) Figura 18 - Diagrama de Robustez do UC Figura 19 - UC001 - Diagrama de Sequência de Inserir e Editar Taxonomia Figura 20 - Diagrama de Sequência UC Figura 21- Arquitetura e Tecnologias Figura 22 - Exemplo de Requisição de Login Figura 23 - Exemplo de Resposta Figura 24 - Interface de Login Figura 25 Visão Geral Figura 26 Configurações Figura 27 Nova Transferência Figura 28 Tela de Movimentação Figura 29 Relatório Analítico Figura 30 Extrato Figura 31 Filtros Figura 32 Retorno Json Figura 33 Base de Dados do Cliente Mobile Figura 34 Tela inicial do Mobile e de Saldos Bancários Figura 35 Processo de Sincronização Figura 36 RestMiddleware Figura 37 Criação da hash de autenticação Figura 38 Diagrama de Classe de Beans Figura 39 Diagrama de Classe de Models Figura 40 Diagrama de Classe de Controllers Figura 41 Diagrama de Classe de Aplicação Figura 42 - Diagrama de Sequencia UC Figura 43 - Diagrama de Sequência UC Figura 44 - Diagrama de Sequência UC Figura 45 - Diagrama de Sequência UC

11 Figura 46 - Diagrama de Sequência UC Figura 47 - Diagrama de Sequência UC Figura 48 - Diagrama de Sequência UC

12 LISTA DE TABELAS E QUADROS Quadro 1 - Quadro de Requisitos Quadro 2 - Detalhamento de Caso de Uso Quadro 3- Resumo dos Casos de Teste Quadro 4 - Detalhamento de Caso de Uso Quadro 5 - Detalhamento de Caso de Uso Quadro 6 - Detalhamento de Caso de Uso Quadro 7 - Detalhamento de Caso de Uso Quadro 8 - Detalhamento de Caso de Uso Quadro 9 - Detalhamento de Caso de Uso Quadro 10 - Detalhamento de Caso de Uso Tabela 11 - Detalhamento de Caso de Uso Tabela 12 - Detalhamento de Telas Quadro 13 - CT Quadro 14 - CT Quadro 15 - CT Quadro 16 - CT Quadro 17 - CT Quadro 18 - CT Quadro 19 - CT Quadro 20 - CT Quadro 21 - CT Quadro 22 - CT

13 SUMÁRIO 1 INTRODUÇÃO PROBLEMÁTICA OBJETIVOS Objetivo Geral Objetivos Específicos JUSTIFICATIVA FUNDAMENTAÇÃO TEÓRICA ADMINISTRAÇÃO FINANCEIRA Administração Financeira Familiar CLOUD COMPUTING Classificações Service Oriented Architecture (SOA) Webservices Web Services Definition Language (WSDL) Simple Object Access Protocol (SOAP) REST DESENVOLVIMENTO MOBILE Arquitetura METODOLOGIAS DE DESENVOLVIMENTO Ciclo de Vida do Desenvolvimento de Software Modelo Incremental Fases do Projeto MÉTODO CARACTERIZAÇÃO DO TIPO DE PESQUISA ETAPAS DELIMITAÇÕES PLANEJAMENTO VISÃO GERAL DA SOLUÇÃO Tecnologias e Ferramentas PHP: Slim Framework & RedBean ORM MySQL Apache AngularJS Android & Apache Cordova NetBeans ICONIX: ABORDAGEM PARA MODELAGEM MODELAGEM Requisitos Ferramentas já existentes Contas Online Meu Dinheiro Organizze Minhas Economias Descrição do funcionamento do sistema Quadro de Requisitos Funcionais Domínio Casos de Uso...49

14 Detalhamento dos Casos de Uso Telas e Interfaces Robustez Sequência e Classe DESENVOLVIMENTO DA SOLUÇÃO ESCOLHA DAS TECNOLOGIAS API (Camada de Aplicação) APP (Camada de Visualização) Mobile RESULTADOS OBTIDOS API Cliente WEB (APP) Telas Funcionamento WEB Aplicação Mobile Funcionamento Sincronização Segurança AVALIAÇÃO Testes CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS REFERÊNCIAS APÊNDICES APÊNDICE A DIAGRAMAS DE CLASSE APÊNDICE B CASOS DE USO APÊNDICE C DIAGRAMAS DE SEQUÊNCIA APÊNDICE D TELAS APÊNDICE E CASOS DE TESTE

15 15 1 INTRODUÇÃO O mercado mobile brasileiro se intensificou nos últimos anos. Segundo um estudo realizado pela WMcCann e Grupo.Mobi (WMCCANNBR, 2011), que teve como base uma pesquisa realizada pelo Instituto Ipsos MediaCT, foi verificado que em 2011, 33% dos brasileiros já possuíam smartphones e 41% dos brasileiros já os utilizavam para acessar a internet. Já em 2013 (IDC, 2013), se constatou que aproximadamente 70% dos smartphones vendidos no mundo utilizam o sistema operacional da Google, o Android, fazendo com que o mesmo torne-se uma ótima opção para desenvolvedores de aplicativos. O novo comportamento do usuário, aliado ao avanço tecnológico e a disponibilização cada vez maior de banda larga móvel, proporcionou um novo cenário para o desenvolvimento de aplicações web, criando uma nova necessidade no modo de se armazenar e processar os dados, sendo quase que fundamental que a informação esteja disponível à mão sempre que for requisitada. Nesse sentido, como meio de resolver os problemas de armazenamento e processamento de dados, surgiu o termo Cloud Computing ( em português, computação em nuvem). O conceito da computação na nuvem baseia-se na utilização de computadores e servidores compartilhados, acessados à partir da internet, que fornecem o hardware ou algum tipo de serviço para uma ou mais aplicações, sem a necessidade de instalação de algum programa. Ou, segundo Taurion (2009, p. 2): Computação em Nuvem é um termo para descrever um ambiente de computação baseado em uma imensa rede de servidores, sejam estes virtuais ou físicos. Uma definição simples pode então ser um conjunto de recursos como capacidade de processamento, armazenamento, conectividade, plataformas, aplicações e serviços disponibilizados na internet. O resultado é que a nuvem pode ser vista como o estágio mais evoluído do conceito de virtualização, a virtualização do próprio data center. Esse tipo de arquitetura provê uma diminuição nos custos de desenvolvimento e manutenção de aplicações. Mas, para poder usufruir dos benefícios da computação em nuvem, é necessário se repensar a forma de como é realizado o desenvolvimento de uma aplicação. Assim, aplicações construídas com base em webservices tornam-se cada vez mais promissoras para este mercado. Conforme Sampaio (2006, p. 38) um webservice é um aplicativo Servidor que disponibiliza um ou mais serviços para seus clientes, de maneira fracamente acoplada.

16 16 O interesse na utilização de um webservice está na criação de um fornecedor de serviços paralelo, que poderá ser utilizado por qualquer plataforma, seja desktop ou mobile, de modo a diminuir os custos com a produção da aplicação, criando recursos reutilizáveis. Dessa forma, um mesmo fornecedor de serviço pode ser utilizado por diferentes interfaces, que podem ter funções voltadas para diferentes focos ou plataformas. Este trabalho pretende mostrar os benefícios da utilização de uma aplicação neste modelo, através da utilização do padrão REST, uma técnica de engenharia de software surgida em uma tese de doutorado. Essa técnica se baseia em algumas regras para o desenvolvimento de uma aplicação que fornecerá informações e processamento sob demanda para outras aplicações, baseando em requisições (FIELDING, 2000). Para facilitar a exemplificação destes benefícios, a presente monografia apresenta a criação de uma aplicação web para gerenciamento financeiro familiar. Esta escolha utiliza como base o fato de que gastos como a alimentação fora de casa chegam a ocupar mais de 40% das despesas diárias de uma família, como informa o economista Mauro Halfed (G1, 2013). Ainda segundo ele, esse montante é originado de pequenos gastos, que aliado à falta de controle, passam despercebidos e, no fim, geram um montante que prejudica o orçamento. Da mesma forma, pesquisas realizadas pela Fecomercio SP e pela CNC (2013) mostram que o endividamento dos brasileiros subiu este ano com relação ao ano passado, sendo um dos maiores desde 2011 (NASCIMENTO, 2013). Assim, com a disponibilização de uma ferramenta financeira que esteja ao alcance do usuário no momento em que o mesmo for realizar o gasto, será mais fácil a decisão de gastar ou não. 1.1 PROBLEMÁTICA É no contexto de computação em nuvem e mobilidade que surgem muitos temas para desenvolvimento de aplicações que devem estar sempre disponíveis para o usuário, indiferente do local onde ele esteja. Um destes temas é o gerenciamento financeiro familiar. O gerenciamento financeiro familiar toma como base o controle dos ganhos e dos gastos de uma família. Segundo Cherobim e Espejo (2010), esse controle ainda deve ser categorizado (saúde, vestuário, alimentação, etc), para que através deste controle se torne

17 17 possível identificar os pontos nos quais o dinheiro está sendo gasto desnecessariamente e efetuar o planejamento econômico da família, além de facilitar a tomada de decisões importantes, como investimentos e empréstimos. A falta deste controle resulta no tão conhecido cenário de se gastar mais do que se recebe, ressaltando o aumento do endividamento divulgado pela CNC (2013). Muitas vezes isto ocorre não por irresponsabilidade do gestor da família, mas simplesmente pela falta de um conhecimento real sobre o quanto se ganha, aliado à falsa sensação de segurança gerada pelos parcelamentos, que se tornam cumulativos. Diante destas informações, é feito o seguinte questionamento: utilizando a computação em nuvem, será possível a criação de uma aplicação de fácil acesso que auxilie no gerenciamento financeiro de uma família? 1.2 OBJETIVOS monografia. Aqui são apresentados o objetivo geral e os objetivos específicos desta Objetivo Geral Implementar um sistema com requisitos básicos de gerenciamento financeiro familiar utilizando a arquitetura REST, apoiado por um cliente web e um cliente Android Objetivos Específicos Os objetivos específicos são:

18 18 Realizar o levantamento de experiências relatadas na literatura sobre desenvolvimento REST e Android; Revisar os aplicativos existentes; Avaliar quais os principais requisitos básicos necessários para o desenvolvimento de uma aplicação de gerenciamento financeiro familiar; Desenvolver um webservice, através do padrão REST, que servirá como fornecedor de recursos para as interfaces web e Android; Desenvolver um Cliente web que fará uso do webservice; Desenvolver um Cliente Android que fará uso do webservice; 1.3 JUSTIFICATIVA A presente monografia tem como objetivo desenvolver um sistema com requisitos básicos de gerenciamento financeiro familiar utilizando a arquitetura REST, apoiado por um cliente web e um cliente Android. Dessa forma, esta pesquisa torna-se importante para a sociedade, pois, como forma de exemplificar o estudo, o trabalho tem como resultado uma aplicação que será utilizada para a gestão financeira familiar, pois, segundo Alves (2013) é através do um planejamento financeiro que se é possível estabelecer metas de consumo que se adequem a realidade e planejar novas aquisições, tanto de médio quanto de longo prazo, como veículos, imóveis ou investimento em educação. Dessa forma, essa aplicação tenta auxiliar na gestão financeira familiar, fornecendo uma ferramenta que permitirá a análise de suas movimentações financeiras, de forma simplificada.

19 19 2 FUNDAMENTAÇÃO TEÓRICA Nesta fundamentação teórica são apresentadas as conceituações referentes à administração financeira familiar, utilizadas como introdução para a elaboração dos requisitos da aplicação em questão. Também é abordado o Cloud Computing e o desenvolvimento mobile, termos que ganharam destaque nos últimos cinco anos, e se mostra uma forte tendência brasileira. Afirmação essa, baseada em uma pesquisa da IDC, divulgada em março deste ano (2013), que mostra o aumento exponencial da utilização de smartphones e tablets. 2.1 ADMINISTRAÇÃO FINANCEIRA Para Gitman (2001) é responsabilidade do administrador financeiro a obtenção de recursos para financiar a operação da empresa e verificar a concessão de crédito para clientes, assim como é de sua responsabilidade o planejamento das atividades financeiras e a tomada de decisão das questões financeiras. Gitman (2001) também explica que o orçamento é a chave para o sucesso financeiro, sendo necessário para se saber onde investir e o que realmente dá para se fazer com o dinheiro que se tem Administração Financeira Familiar Hoji (2009) afirma que as famílias são como empresas, e a importância da gestão financeira também deve ser refletida no dia a dia das mesmas. É necessária a existência do orçamento familiar, assim como a definição dos objetivos a curto e a longo prazo. Dessa forma, pode-se considerar equilibrada financeiramente a família que consegue administrar suas finanças a ponto de que as receitas (o dinheiro que entra) sejam superiores as despesas (o dinheiro que sai), restando algum saldo positivo que possa ser convertido em investimentos, visto que, assim como nas empresas, o objetivo financeiro

20 20 familiar também é o de crescimento e lucro, seja ele utilizado depois para a obtenção de algum bem ou a reserva para eventuais emergências e imprevistos. Entretanto, nos últimos anos o governo brasileiro tem incentivado o consumo com base no crédito (NASCIMENTO, 2010), o que para as famílias que não possuem um gerenciamento financeiro organizado pode ser uma grande armadilha. Este crédito e parcelamento de contas escondem o grande vilão de qualquer economia, os juros. O resultado disso é um aumento constante no índice de endividamento brasileiro, como aponta o CNC (2013), visto que os consumidores compram no impulso, deixando de perceber que estarão pagando um valor consideravelmente maior do que se estivessem pagando à vista (NASCIMENTO, 2010). Hoji (2009) menciona a importância de se eleger as reais necessidades de gastos da família, assim como a análise sobre a forma mais vantajosa de se realizar as compras, sempre de olho no orçamento para que não se corra o risco de ter um resultado financeiro negativo. A maneira simples de se manter um controle orçamentário da família é anotar tudo que se recebe e se gasta (HOJI, 2009), simplificadamente. É importante categorizar os gastos e receitas, de modo a distinguir onde estão os furos orçamentários, que poderiam ser convertidos em economias. 2.2 CLOUD COMPUTING Quando os primeiros computadores pessoais surgiram, os usuários foram apresentados a um modelo de armazenamento local. Neste modelo, os dados e programas do usuário ficavam somente na máquina em que foram instalados, e o usuário dependia exclusivamente dela para manipular seus arquivos. O compartilhamento de dados era feito de forma manual, ou através de disquetes, cds, pendrives, etc, gerando duplicatas e arquivos dessincronizados. Tendo em vista essa dificuldade, nos ambientes corporativos o cenário se portou diferente, e comumente as aplicações eram instaladas em servidores para serem acessadas pelos computadores ou aparelhos autorizados. Por tratar-se de redes internas, as aplicações

21 21 não dependiam da utilização da internet para estarem disponíveis. Entretanto, não fossem os backups das máquinas, todos os dados e aplicações estavam restritos àqueles aparelhos. Com o surgimento do mercado mobile, esse panorama teve de ser rediscutido, e o conceito de cloud computing passou a ser bastante comentado, por parecer a solução mais plausível para a disponibilização de aplicações e documentos nos aparelhos portáteis, como tablets e smartphones. De forma geral, descreve-se Cloud Computing como uma grande rede de servidores interligados, virtuais ou físicos, que dividem seus recursos de processamento e armazenamento, para o fornecimento de aplicações ou dados (TAURION, 2009). Com a utilização do Cloud Computing, surgiu também a possibilidade da utilização sob demanda dos recursos, não sendo necessário reservar recursos computacionais que não estão efetivamente sendo utilizados. No início da década de 1960, McCarthy (1989), considerado um dos precursores do Cloud Computing, iniciou uma pesquisa sobre a utilização de um computador por mais de um usuário simultaneamente, fazendo com que um computador não desperdiçasse recursos ociosos, visto que era um equipamento caro na época. Assim, a máquina passou a ser vista apenas como um fornecedor de recursos, e não o objeto principal para o funcionamento da aplicação, permitindo sua reposição sempre que necessária, assim como o aumento ou a diminuição da alocação de recursos dependendo da necessidade de utilização. Como Taurion (2009) exemplifica, pode-se imaginar uma loja virtual que, em épocas como o Natal, atinge os picos das vendas do ano. Neste período, muitas vezes é necessário se triplicar a capacidade de processamento dos servidores. Dessa forma, apoiandose na elasticidade do Cloud Computing, a loja pode alocar mais recursos para esta temporada, e logo após o término dela, voltar a utilizar os recursos anteriores. Isto elimina gastos desnecessários com compra de hardware que depois não seria mais utilizado, assim como facilita o planejamento referente às estruturas de hardware da empresa Classificações três modelos: Segundo Wang et al (2008), a utilização do Cloud Computing é classificada em

22 22 HaaS (Hardware as a Service): A utilização de recursos de hardware, como processamento e armazenamento, de forma elástica; Ex.: Amazon WS; SaaS (Software as a Service): É a utilização de softwares dentro da nuvem, onde o fornecedor do software fica responsável por manter o software online, enquanto o cliente tem apenas a necessidade de usá-lo; Ex.: Office 360; DaaS (Data as a Service): Semelhante ao SaaS, é a informação sobre demanda. Ex: Webservice dos correios, onde retorna os dados dos CEP s; Wang et al (2008) também comentam sobre o fato de que os serviços feitos na nuvem são quase sempre vinculados à webservices, organizados em uma estrutura conhecida como SOA (Service Oriented Architecture), que pode ser brevemente explicada como um conjunto de serviços de nuvem (WANG et al, 2008, p. 5, tradução nossa) Service Oriented Architecture (SOA) Uma das definições dadas por Lublinsky (2007) para SOA refere-se a um conjunto de princípios e padrões de arquitetura que buscam a modularidade, o encapsulamento, fraco acoplamento, separação de conceitos e reutilização de software, possibilitando um desenvolvimento paralelo de aplicações. Também se apoia na ideia de que este modelo utiliza de webservices, definidos como aplicativos Servidores que disponibilizam um ou mais serviços para seus clientes (Sampaio, 2006), para facilitar sua reutilização. Não diferente para Wang et al (2008), que enxerga a utilização de webservices no Cloud Computing como uma ferramenta de facilitar a integração entre os mais diversos serviços. Em seu artigo é possível identificar como os webservices ganharam uma maior importância com a valorização da nuvem, visto que várias empresas estão perdidas em meio a tantas aplicações que utilizam no seu dia a dia. Muitas vezes, é necessário existir a integração entre esses aplicativos, de modo a automatizar tarefas ou resolver problemas que apenas uma aplicação não foi capaz de resolver. Por isso, Wang et al (2008) a define como um conjunto de webservices que podem ser utilizados num ambiente, tornando assim disponível em várias plataformas distribuídas,

23 23 além de poder acessá-los através da Internet. Estes webservices são tratados como os músicos de uma orquestra e, assim como em uma orquestra, são organizados por um maestro, que controla todo o fluxo das requisições realizadas pelo cliente. A Figura 1 exemplifica este fluxo. Na figura, é possível ver que o cliente realiza uma solicitação para o fornecedor de serviços. No fornecedor, há uma camada que é utilizada para coordenar as solicitações e resposta, verificando qual o fluxo que cada chamada deve percorrer. Figura 1 Exemplo de orquestração de serviços em SOA Fonte: TAURION, 2009 (Com modificações) Webservices Sampaio (2006) define Webservices como sendo aplicativos Servidores que disponibilizam um ou mais serviços para seus clientes. Kopack (2003, apud Tomé, 2011) completa informando que estes serviços são acessados via web, semelhante um site, que responde ao cliente dependendo da URL acessada e parâmetros enviados. Diferente de qualquer outro serviço web, os webservices respondem ao cliente através de um documento XML, conhecido como Web Services Description Language ou WSDL (SAMPAIO, p. 38, 2006). Segundo a W3C (2013), este padrão baseado em XML

24 24 serve pra descrever o serviço e deve trazer os métodos que o webservice suporta, além de ser também utilizado para validar os métodos de entrada e saída do webservice. Mas qual é a razão de se utilizar webservices? Não é mais possível manter uma Inteface DPL-DPC (disquete pra lá - disquete pra cá) com seus parceiros, fornecedores e clientes. As empresas precisam estar sempre prontas para oferecer novos serviços ou trocar novos tipos de informações, aprender e desaprender novas coisas. (SAMPAIO, 2006, p.1) A comunicação entre sistemas já existentes é sempre uma questão problemática para muitas empresas. Ao se imaginar um cenário onde se tem dois ou mais softwares que precisam passar a se comunicar, alguns pontos devem ser levados em consideração, como linguagem utilizada, banco de dados, infraestrutura, etc. Sampaio (2006) menciona que uma empresa deve possuir uma carteira básica de aplicações imutáveis na empresa. Mas, pode ser que em algum momento, a solução de um software tenha a necessidade de se juntar a solução de outro, de forma a integrar, juntar pedaços de vários aplicativos (de plataformas diferentes) para oferecer um novo produto ou serviço. E isto tem que ser feito de maneira rápida e prática, sem esperar meses (ou anos) até que um novo sistema seja criado (SAMPAIO, 2006, p.2). Os webservices possuem três camadas básicas (CURBERA et al, 2002): um protocolo de comunicação, a descrição dos serviços e um método de publicação. Este último, servindo para o cadastro do webservice em repositórios de busca, funcionando de modo semelhante a um catálogo telefônico, conhecido como UDDI (Universal Description, Discovery and Integration) Web Services Definition Language (WSDL) Ao se utilizar um webservice, o serviço que estiver fazendo a requisição necessita saber quais os métodos e serviços que aquele webservice poderá lhe fornecer, além de saber como chamar determinados serviços e o que esperar deles. A W3C (2004) orienta a utilização do padrão WSDL para descrever um webservice. Esse padrão possui uma sintaxe em XML (extensible Markup Language), uma linguagem de marcação desenvolvida também pela W3C (2008), que serve como um meio de

25 25 troca de informações entre aplicações e serviços na web. É extremamente flexível, o que ajudou sua popularização. Um exemplo pode ser visto na figura 2. Figura 2 Exemplo de XML Fonte: W3SCHOOLS, 2013 Dentro de um WSDL (figura 3) é informado o protocolo de comunicação que deve ser usado e o conjunto de operações que aquele webservice realiza, com suas chamadas e os atributos necessários para se fazer a chamada e um endereço de rede. Com essas informações, é possível saber onde encontrar o webservice, o que ele faz e como utilizar o mesmo. Figura 3 Exemplo de WSDL Fonte: CURBERA et al, 2002

26 Simple Object Access Protocol (SOAP) SOAP (figura 4) é o protocolo de comunicação mais utilizado por webservices, o qual a W3C (2007) recomenda a utilização por tratar-se de um modelo de desenvolvimento das mensagens cliente-servidor. Possui uma estrutura leve baseada em XML, chamado de envelope, que é dividido em duas partes: cabeçalho (opcional) e corpo (obrigatório). Tanto o cliente quanto o webservice utilizam SOAP em sua comunicação. O cliente gera o SOAP e envia a request (requisição) para o webservice, que irá receber e gerar um SOAP de response (resposta), que enviará novamente ao cliente (W3C, 2007). Figura 4 Exemplo de requisição SOAP Fonte: W3C, 2007 A comunicação é realizada via uma requisição POST do HTTP, e não é obrigatoriamente necessário o webservice efetuar uma resposta, pois tudo irá depender da requisição efetuada pelo cliente e da estrutura do webservice (W3C, 2007) REST A W3C (2004) caracteriza o modelo REST (Representational State Transfer) como também sendo um tipo de webservice, embora mais restrito, por não fornecer o WSDL. Resumidamente, o REST é caracterizado como um padrão de desenvolvimento semelhante

27 27 aos webservices, no qual um serviço é fornecido de forma independente de quem irá chamálo. Diferente dos webservices, os métodos internos desta aplicação são mais genéricos, preocupando-se mais com a manipulação dos dados, enquanto nos webservices os métodos são específicos para a aplicação (FIELDING, 2000). Também diferente dos webservices comuns, no padrão REST todas as requisições devem conter todas as informações necessárias para se compreender o pedido no servidor, pois, por se tratar de uma comunicação estática, o servidor não guarda nenhuma informação do cliente, devendo este manter guardada a sessão do usuário, por exemplo (FIELDING, 2000). Dessa forma, múltiplos clientes podem fazer uso do serviço tendo seu próprio tratamento de sessão e dados. Para exemplificar basta imaginar o cenário de uma aplicação REST que é requisitado tanto por uma página web, uma aplicação mobile e uma aplicação desktop. Figura 5 Exemplo de Comunicação Clientes-Aplicação em REST Fonte: IMASTERS, 2012

28 28 No exemplo da Figura 5, os clientes fazem a requisição para o servidor, que responde através do padrão JSON (JavaScript Object Notation), um formato mais leve para a comunicação de dados na web e amplamente utilizado por webservices mais modernos (JSON, 2013). Utilizando dessa tecnologia, a integração entre os sistemas se torna mais fácil, pois sua estrutura baseia-se em dois modelos que podem ser escolhidos no momento da leitura dos dados: Uma coleção de pares nome/valor. Em várias linguagens, isto é caracterizado como um object, record, struct, dicionário, hash table, keyed list, ou arrays associativas. Uma lista ordenada de valores. Na maioria das linguagens, isto é caracterizado como uma array, vetor, lista ou sequência. Voltando ao exemplo, é visto que os clientes fazem a requisição utilizando os métodos de requisição GET, POST ou DELETE. Estes são alguns dos métodos aceitos por uma requisição HTTP, utilizada na comunicação com o servidor. Dependendo do método da chamada, uma mesma url pode retornar diferentes dados. No exemplo, o método GET seria utilizado para busca. O método POST (algumas vezes utilizado o método PUT no local), para inserção de dados. Já o método DELETE se encarrega de fazer a exclusão do dado. Além disso, cada cliente trata a visualização e apresentação destes dados de modo distinto, visto que a aplicação REST lhe permite manipular os dados da forma que lhe for mais conveniente (FIELDING, 2000). Dessa forma, uma aplicação mobile não precisará exibir todos os dados que uma aplicação desktop exibiria, por exemplo. 2.3 DESENVOLVIMENTO MOBILE Como relatado, a pesquisa realizada pela IDC (2013) relevou o aumento significativo na utilização de smartphones, tablets e notebooks, um mercado antes dominado pelos desktops. Segundo a empresa de consultoria Frost & Sullivan (2011), a média de aparelhos conectados à internet será de cinco por pessoa até 2020.

29 29 Dentro deste novo cenário, o sistema operacional Android vem ganhando grande destaque por estar sempre presente em aparelhos de baixo e alto custo, dominando uma grande fatia do mercado IDC (2013). O Android é a plataforma open-source criada pelo Google para o desenvolvimento de aplicações para dispositivos móveis. Inclui um sistema operacional baseado no Linux e diversas aplicações, com uma rica interface gráfica, um browser para navegar na internet, integração com o Google Maps, suporte a multimídia, GPS, banco de dados integrado, jogos em 3D e muito mais. A plataforma de desenvolvimento do Android permite desenvolver e integrar aplicações de forma simplificada utilizando a linguagem de programação Java e um ambiente de desenvolvimento de alto nível e produtividade como o Eclipse. (LECHETA, 2013, Sinopse) Baseado em Linux e Open Source 1, o Sistema Operacional Android vem sendo considerado o mais utilizado no mundo (IDC, 2013). Foi o primeiro projeto de uma plataforma Open Source Mobile (PEREIRA, 2009), e disponibiliza um kit de desenvolvimento para quem quiser criar aplicações para o sistema, chamado de Android SDK. Este SDK contém todas as bibliotecas necessárias para se desenvolver aplicações para o Android. As aplicações são baseadas em Java, e a própria Google fornece uma IDE especializada para o desenvolvimento de aplicações, através de uma versão do eclipse que vem integrada ao Android SDK. Ao iniciar um projeto com a IDE, a estrutura base da aplicação já é montada. Esta IDE também permite que o aplicativo seja compatível em diversos aparelhos e versões do sistema operacional, diretamente do computador Arquitetura De acordo com Pereira (2009), o sistema operacional Android é divido em cinco camadas, cada qual com uma funcionalidade própria. 1 Especificamente, software livre significa que os usuários têm as quatro liberdades essenciais: (0) para executar o programa, (1) para estudar e mudar o código-fonte do programa, (2) para redistribuir cópias exatas e (3) para distribuir versões modificadas (GNU, 2011). O sistema operacional Linux é o maior exemplo de software de código livre, e possui diversas distribuições personalizadas pela sua comunidade de desenvolvedores.

30 30 A camada mais externa é a de aplicativos, onde são encontradas as aplicações, todas desenvolvidas em JAVA, como agenda, calendário, calculadora, jogos, entre outros. Após esta camada, encontra-se a camada de Framework, onde estão os recursos que as aplicações irão utilizar, como as classes de Views, GPS, WI-FI, Bluetooth, entre outros. Esta camada existe para facilitar a incorporação e reutilização destes componentes primitivos do sistema nas aplicações desenvolvidas por terceiros, para que não seja necessário interagir com as camadas mais internas do sistema. Em seguida, existe a camada de Biblioteca (Libraries), que contém as bibliotecas de linguagem, como C e C++, que são utilizadas pelo sistema. Aqui também ficam as camadas multimídia e banco de dados. Para se ter acesso à essas bibliotecas, é necessário utilizar os recursos da camada de Framework. A camada de Runtime é a camada conhecida como ambiente de execução. É aqui que cada aplicação fica enquanto estiver em execução, como uma instância da máquina virtual do Android (Dalvik). Esta máquina virtual fica responsável pelo controle da utilização dos recursos do hardware por cada aplicativo, de modo a manter o sistema sempre estável e controlado. Cada aplicação roda paralelamente e, caso necessitem se comunicar, a camada de Framework possui recursos para possibilitar isto. Por último encontra-se o Kernel do sistema Linux, base de todo o Android. Esta camada é responsável pelas operações de mais baixo nível, como gerenciamento de memória, gestão da rede, entre outros. 2.4 METODOLOGIAS DE DESENVOLVIMENTO Segundo Conte (2005), o desenvolvimento de software para web segue os mesmos princípios que a engenharia de software convencional. Seu foco está em como desenvolver uma aplicação correta e completa, de acordo com os requisitos do usuário. O diferencial está no fato de que esta deve ser desenvolvida no contexto de um projeto que deve considerar a infra-estrutura Web para sua execução e disponibilização (CONTE, 2005, p.107). Além disso, para Fraternalli e Paolini (1998, apud Conte, 2005), o desenvolvimento de um software para web deve considerar algumas particularidades.

31 31 Estrutural (conceitual): define a organização das informações a serem tratadas pela aplicação e os seus relacionamentos; [...] Navegacional: representa como as informações serão acessadas através da aplicação, e; [...] Apresentação: descreve como as informações e o acesso a essas serão apresentados ao usuário da aplicação (CONTE, 2005, p.107). Seguindo estes preceitos, é cabível de se utilizar o ciclo de vida comum para o desenvolvimento de um software web, descrito a seguir Ciclo de Vida do Desenvolvimento de Software O desenvolvimento de um software, seja ele desktop, web ou mobile, consiste de algumas pequenas etapas, também conhecidas como Ciclo de Vida. Para Pressman (2006), a utilização deste ciclo visa a criação de aplicações com qualidade, além de tentar diminuir os custos com a produção, eliminando erros causados pela falta de validações reais do produto final. Ele ainda afirma que os modelos de ciclo de vida colocam ordem no desenvolvimento de software, eliminando o caos e organizando uma estrutura para o desenvolvimento. A escolha de um ciclo de vida irá depender de alguns fatores como tempo disponível, custo, equipe, dentre outros. Assim, não existe um modelo ideal, sendo necessário um estudo para verificar qual o mais compatível com o projeto. A seguir é apresentado o Modelo Incremental, baseado no estudo de Pressman (2006) e Sommerville (2003) Modelo Incremental Este baseia-se na divisão do projeto em pequenos ciclos, todos possuindo um resultado executável. Cada ciclo é chamado de iteração, e possui quatro tarefas: Análise (Refinamento dos requisitos), Projeto (refinamento do projeto arquitetural, projeto de baixo nível), Implementação (codificação e testes) e Transição para produto (documentação, instalação,...).

32 32 Figura 6 Exemplo de Modelo Incremental Fonte: PRESSMAN, 2006 Neste modelo as alterações de escopo são suportadas, pois o término de cada iteração gera uma versão do produto, e não o produto inteiro, a chamada Entrega Incremental Fases do Projeto Indiferente do modelo adotado para o desenvolvimento, tanto Pressman (2006) quanto Sommerville (2003) citam 3 fases do processo de desenvolvimento de software. Definição: É nesta fase inicial que é definido o que será feito. É o início do planejamento do projeto e da Análise dos requisitos. Pode ser considerada a fase mais importante do projeto, pois a má concepção do projeto pode culminar na falha das duas fases seguintes. Sommerville (2003) descreve alguns passos para essa definição dos requisitos do software. Resumidamente, é o estudo da viabilidade, seguido das especificações de requisitos, a validação de requisitos, e a documentação dos requisitos. São estes quatro passos que permitem a procedência do planejamento das atividades e dos ciclos de desenvolvimento, como cronograma, estimativa de custos e a própria organização do projeto.

33 33 Desenvolvimento: Este é o momento em que, com os requisitos definidos e o projeto planejado, é possível iniciar a geração do código e a realização dos testes, até chegar ao resultado final, o produto. Neste momento, se a primeira fase não foi bem realizada, irão começar a surgir as primeiras falhas e incoerências no projeto, resultando em retrabalho posterior. Manutenção: Com o produto finalizado, é comum o surgimento de modificações póstumas conforme novas necessidades venham a surgir.

34 34 3 MÉTODO Neste capítulo são revisados os métodos e procedimentos utilizados para a elaboração do presente trabalho. Gil (2002) define a pesquisa como um procedimento racional e sistemático e que seu objetivo é proporcionar respostas aos problemas expostos. Dessa forma, a pesquisa deve ser realizada quando se é necessário obter informações para resolver um problema, seja esta informação inexistente ou desordenada. 3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA A pesquisa realizada neste trabalho, segundo sua natureza, é considerada por Silva e Menezes (2005) como sendo uma Pesquisa Aplicada, pois tem um direcionamento à uma solução de um problema especifico. Ainda segundo Silva e Menezes (2005), quanto à abordagem do problema, a pesquisa realizada neste trabalho é caracterizada como pesquisa qualitativa, pois não requer o uso de métodos e estatísticas, e possui na interpretação dos fenômenos a base para a pesquisa. Por seus objetivos, Silva e Menezes (2005) caracteriza a pesquisa deste trabalho como exploratória, pois visa ganhar uma maior familiaridade com o problema, tendo o intuito de torná-lo claro ou a buscar soluções. E, do ponto de vista de procedimentos técnicos, é caracterizada como pesquisa bibliográfica, pois usa como base material já publicado, como livros, arquivos e outros materiais disponibilizados na internet. 3.2 ETAPAS cinco etapas: Para facilitar o alcance do objetivo proposto neste trabalho, ele está dividido em

35 35 1. Fundamentação Teórica: nesta etapa a pesquisa bibliográfica é realizada de modo a criar a base para um melhor entendimento do problema; 2. Planejamento: Nesta etapa é realizado o levantamento de requisitos necessários para a aplicação, assim como o estudo das ferramentas que serão utilizados na implementação da aplicação; 3. Modelagem: nessa etapa são apresentados os casos de uso, assim como os diagramas da UML de sequência dos principais casos de uso; 4. Implementação: Nesta etapa é realizado o desenvolvimento da aplicação, com base nas etapas anteriores; 5. Verificação e Validação: nesta etapa é verificado se a solução alcançada atende às expectativas e requerimentos propostos. 3.3 DELIMITAÇÕES O foco deste trabalho é o desenvolvimento de uma aplicação de gerenciamento financeiro familiar, não possuindo em seu escopo funcionalidade de gestão financeira para empresas, tais como notas fiscais entre outros. Da mesma forma, a versão mobile é compatível apenas com o sistema operacional Android. Também não faz parte do escopo deste trabalho questões ligadas à segurança da aplicação, como implantação de certificados HTTPS, ou gestão de usuários.

36 36 4 PLANEJAMENTO Neste capítulo é dada uma visão geral da solução, com sua arquitetura básica e uma abordagem de quais ferramentas e processos são utilizados para o desenvolvimento da solução. As fases do desenvolvimento do projeto foram feitas seguindo o processo de desenvolvimento de software ICONIX. Neste capitulo são mostrados os principais artefatos gerados pela implementação do ICONIX. Os demais artefatos podem ser encontrados nos Apêndices do trabalho. 4.1 VISÃO GERAL DA SOLUÇÃO A solução proposta neste trabalho tem como objetivo principal facilitar o gerenciamento financeiro de uma família. Dessa forma, é fundamental uma arquitetura que permita que múltiplos usuários façam alterações e cadastros simultâneos à aplicação, estando ou não conectados à internet. Os módulos da aplicação são abordados com maior detalhamento no item 4.3. Entretanto, de modo a exemplificar a arquitetura básica da solução, que servirá como base para o entendimento do funcionamento da mesma, a solução é dividida em três módulos bem definidos, que são representados na Figura 7. No servidor de Aplicação fica toda a lógica da solução, assim como toda a base de dados. Através da autenticação por um usuário e senha, os clientes Android e Web poderão se comunicar com o Servidor de Aplicação para efetuar operações de cadastros, atualizações, remoções e captura de relatórios. A aplicação Android possui apenas a visualização do saldo das contas e cadastro de lançamentos, que poderão ser realizados mesmo com a ausência da internet. A aplicação conterá um banco de dados próprio, que fica responsável por, sempre que requisitado, iniciar uma rotina de sincronização com o servidor. Desta forma, o usuário que estiver em algum local sem internet pode fazer o registro de seus gastos ou ganhos, agilizando o processo do seu gerenciamento.

37 37 O cliente web consiste de uma interface com pleno acesso aos dados da aplicação. Aqui, é possível cadastrar novos lançamentos, assim como outros itens da aplicação, que são abordados na modelagem. Figura 7 - Arquitetura da Aplicação Fonte: Elaborada pelos autores, 2013 Através desta arquitetura é possível a utilização da solução em qualquer momento, desde que se possua acesso à internet ou se instale a aplicação Android em seu dispositivo mobile. É importante ressaltar que a figura 7 não possui embasamento em nenhuma diagramação, servindo apenas como forma de exemplificar a arquitetura básica do sistema, para uma melhor compreensão Tecnologias e Ferramentas Nesta seção abordaremos a linguagem de programação e as tecnologias escolhidas para o desenvolvimento deste trabalho.

38 PHP: Slim Framework & RedBean ORM Na criação do Servidor de Aplicação é utilizada a linguagem PHP que, segundo seu site, é definido como: PHP, que significa "PHP: Hypertext Preprocessor", é uma linguagem de programação de ampla utilização, interpretada, que é especialmente interessante para desenvolvimento para a Web e pode ser mesclada dentro do código HTML. A sintaxe da linguagem lembra C, Java e Perl, e é fácil de aprender. O objetivo principal da linguagem é permitir a desenvolvedores escreverem páginas que serão geradas dinamicamente rapidamente, mas você pode fazer muito mais do que isso com PHP. (PHP, 2013) Foi criado por Rasmus Lerdorf em 1995 (PHP, 2013) e é mantido pela organização The PHP Group. Amplamente utilizado e difundido pelos programados, existem diversos frameworks que facilitam sua utilização. Entre eles, o Slim Framework. Segundo o site do autor, o Slim Framework é um micro framework, que auxilia na criação rápida de leves e poderosas aplicações REST e APIs (SLIM, 2013). O framework já possui os módulos necessários para tratamentos de requisições HTTP e seu roteamento, além de facilitar a criação de camadas, como cache e segurança. Junto ao Slim Framework recomenda-se a utilização do ORM RedBean. ORM são ferramentas que auxiliam as operações realizadas com o banco de dados (REDBEAN, 2013). O RedBean é um ORM leve, de fácil configuração, que fornece ao desenvolvedor as operações básicas de CRUD (Create, Read, Update e Delete, ou seja, inserção, leitura, atualização e remoção) dos cadastros do banco de dados, retornando os Beans representações dos objetos tratados dentro da aplicação (REDBEAN, 2013) MySQL MySQL é um SGBD (Sistema de Gerenciamento de Banco de Dados), que utiliza a linguagem SQL, sendo um dos bancos de dados mais populares da atualidade (MySQL, 2013).

39 39 O PHP é compatível com o SGBD, e comporta todas as funcionalidades necessárias para a aplicação, sendo as principais o gerenciamento de transações, que permitem efetuar alterações nos dados gravados do banco e reverter as mesmas caso algo inesperado ocorra Apache um: Segundo o site do Projeto Apache HTTP Server (APACHE, 2013), este projeto é (...) esforço para desenvolver e manter um servidor HTTP de código aberto para sistemas operacionais modernos, incluindo UNIX e Windows NT. O objetivo deste projeto é fornecer um servidor seguro, eficiente e extensível que fornece serviços HTTP em sincronia com os padrões HTTP atual. (APACHE, 2013, tradução nossa) Ainda segundo o site, este projeto tem sido muito popular desde abril de 1996, quando surgiu. Ele é estruturado em módulos, o que permite uma maior personalização por parte dos usuários. Sua utilização é muito comum quando trata-se de PHP e MySQL, motivo pelo qual foi escolhido. Além disso, ele trabalha com todos os principais métodos de requisição que serão utilizadas pela aplicação REST AngularJS Para a criação do cliente WEB, é utilizado AngularJS. Esta é uma tecnologia desenvolvida pela Google, que serve como um framework para a criação de aplicações web. Todo seu funcionamento baseia-se em javascript, e roda no lado do cliente, em seu navegador (ANGULARJS, 2013). Sua arquitetura é baseada em MVC, o que facilita a organização e criação dos códigos e sua estrutura é ideal para a criação de aplicações consumidoras de REST.

40 40 Figura 8 - Exemplo de Código AngularJS Fonte: AngularJS, 2013 Embora possua uma documentação em estágio muito inicial, tornando difícil encontrar as respostas lá, é muito fácil encontrar os desenvolvedores e evangelistas do framework em grupos de discussão, sempre dispostos a sanar dúvidas e mostrar exemplos funcionais de resolução de problemas. Além disso, a principal vantagem na utilização deste framework está na facilidade de se manipular o HTML da página, sem se criar dezenas de linhas de javascript Android & Apache Cordova Segundo o site do android ( este é o sistema operacional móvel mais popular do mundo (ANDROID, 2014). Ele é mantido pela google, e seus aplicativos são desenvolvidos utilizando JAVA. De forma a facilitar o desenvolvimento e compatibilidade em diversos dispositivos, a aplicação mobile irá utilizar o pacote de desenvolvimento Apache Cordova, que pode ser encontrado no link Este pacote de desenvolvimento permite que se programe para android utilizando html e javascript, inclusive utilizando angularjs.

41 NetBeans O NetBeans é uma IDE gratuita, que trabalha com diversas linguagens de programação e marcação, inclusive o PHP, JavaScript e HTML, utilizadas neste trabalho, e pode ser baixado no site A aplicação auxilia no desenvolvimento e organização do código, sendo um grande facilitador para os desenvolvedores. 4.2 ICONIX: ABORDAGEM PARA MODELAGEM ICONIX é considerado uma das metodologias de desenvolvimento de software mais práticas e simples da atualidade e, ainda assim, uma ferramenta poderosa. Além disso, é também iterativo e incremental, adequado ao padrão UML (SILVA; VIDEIRA, 2001). É mantido pela empresa ICONIX Software Engineering e seu principal idealizador é Doug Rosemberg. (ICONIXPROCESS, 2013). Os artefatos gerados pelo ICONIX estão representados na figura 9. Figura 9 - Uma visão geral do ICONIX. Fonte: ICONIXPROCESS, 2013