Aplicação de gerenciamento financeiro familiar web com interface mobile

(1)

JONATHAN CLEITON ALVES

APLICAÇÃO DE GERENCIAMENTO FINANCEIRO FAMILIAR WEB COM INTERFACE MOBILE

Unisul 2014

(2)

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)

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 2014.

______________________________________________________ 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.

(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)

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.”

(8)

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.

(9)

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.

(10)

Figura 1 – Exemplo de orquestração de serviços em SOA ... 23

Figura 2 – Exemplo de XML ... 25

Figura 3 – Exemplo de WSDL ... 25

Figura 4 – Exemplo de requisição SOAP ... 26

Figura 5 – Exemplo de Comunicação Clientes-Aplicação em REST ... 27

Figura 6 – Exemplo de Modelo Incremental ... 32

Figura 7 - Arquitetura da Aplicação ... 37

Figura 8 - Exemplo de Código AngularJS ... 40

Figura 9 - Uma visão geral do ICONIX. ... 41

Figura 10 - Exemplo de Diagrama de Domínio Detalhado ... 42

Figura 11 - Exemplo de um diagrama de casos de utilização ... 42

Figura 12 - Objectos usados os diagramas de robustez ... 43

Figura 13 - Exemplo de um diagrama de sequência ... 43

Figura 14 - Exemplo de um diagrama de classes. ... 44

Figura 15 - Modelo de Domínio ... 49

Figura 16 - Diagrama de caso de uso ... 50

Figura 17 - Tela de Taxonomia (Centros de Custo) (TEL011) ... 52

Figura 18 - Diagrama de Robustez do UC003 ... 53

Figura 19 - UC001 - Diagrama de Sequência de Inserir e Editar Taxonomia... 56

Figura 20 - Diagrama de Sequência UC003 ... 58

Figura 21- Arquitetura e Tecnologias ... 65

Figura 22 - Exemplo de Requisição de Login ... 66

Figura 23 - Exemplo de Resposta ... 66

Figura 24 - Interface de Login ... 68

Figura 25 – Visão Geral ... 69

Figura 26 – Configurações ... 69

Figura 27 – Nova Transferência ... 70

Figura 28 – Tela de Movimentação ... 71

Figura 29 – Relatório Analítico ... 72

Figura 30 – Extrato ... 72

Figura 31 – Filtros ... 73

Figura 32 – Retorno Json ... 74

Figura 33 – Base de Dados do Cliente Mobile ... 76

Figura 34 – Tela inicial do Mobile e de Saldos Bancários ... 76

Figura 35 – Processo de Sincronização ... 78

Figura 36 – RestMiddleware ... 79

Figura 37 – Criação da hash de autenticação ... 80

Figura 38 – Diagrama de Classe de Beans ... 90

Figura 39 – Diagrama de Classe de Models ... 91

Figura 40 – Diagrama de Classe de Controllers ... 92

Figura 41 – Diagrama de Classe de Aplicação ... 93

Figura 42 - Diagrama de Sequencia UC002 ... 98

(11)

(12)

Quadro 1 - Quadro de Requisitos ... 48

Quadro 2 - Detalhamento de Caso de Uso 001 ... 51

Quadro 3- Resumo dos Casos de Teste ... 81

Tabela 11 - Detalhamento de Caso de Uso 010... 97

Tabela 12 - Detalhamento de Telas ... 105

Quadro 13 - CT001 ... 106 Quadro 14 - CT002 ... 106 Quadro 15 - CT003 ... 107 Quadro 16 - CT004 ... 107 Quadro 17 - CT005 ... 107 Quadro 18 - CT006 ... 108 Quadro 19 - CT007 ... 108 Quadro 20 - CT008 ... 108 Quadro 21 - CT009 ... 109 Quadro 22 - CT010 ... 109

(13)

1 INTRODUÇÃO ... 15 1.1 PROBLEMÁTICA ...16 1.2 OBJETIVOS ...17 1.2.1 Objetivo Geral ...17 1.2.2 Objetivos Específicos ...17 1.3 JUSTIFICATIVA ...18 2 FUNDAMENTAÇÃO TEÓRICA ... 19 2.1 ADMINISTRAÇÃO FINANCEIRA ...19

2.1.1 Administração Financeira Familiar ...19

2.2 CLOUD COMPUTING ...20

2.2.1 Classificações ...21

2.2.2 Service Oriented Architecture (SOA) ...22

2.2.3 Webservices ...23

2.2.3.1 Web Services Definition Language (WSDL) ... 24

2.2.3.2 Simple Object Access Protocol (SOAP) ... 26

2.2.4 REST ...26

2.3 DESENVOLVIMENTO MOBILE ...28

2.3.1 Arquitetura ...29

2.4 METODOLOGIAS DE DESENVOLVIMENTO ...30

2.4.1 Ciclo de Vida do Desenvolvimento de Software ...31

2.4.1.1 Modelo Incremental ... 31

2.4.2 Fases do Projeto ...32

3 MÉTODO... 34

3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA ...34

3.2 ETAPAS ...34

3.3 DELIMITAÇÕES ...35

4 PLANEJAMENTO ... 36

4.1 VISÃO GERAL DA SOLUÇÃO ...36

4.1.1 Tecnologias e Ferramentas ...37

4.1.1.1 PHP: Slim Framework & RedBean ORM ... 38

4.1.1.2 MySQL ... 38

4.1.1.3 Apache ... 39

4.1.1.4 AngularJS ... 39

4.1.1.5 Android & Apache Cordova ... 40

4.1.1.6 NetBeans ... 41

4.2 ICONIX: ABORDAGEM PARA MODELAGEM ...41

4.3 MODELAGEM ...44 4.3.1 Requisitos ...44 4.3.1.1 Ferramentas já existentes ... 45 4.3.1.1.1 Contas Online ...45 4.3.1.1.2 Meu Dinheiro ...46 4.3.1.1.3 Organizze ...46 4.3.1.1.4 Minhas Economias ...46

4.3.1.2 Descrição do funcionamento do sistema ... 47

4.3.1.3 Quadro de Requisitos Funcionais ... 48

4.3.2 Domínio ...49

(14)

4.3.5 Sequência e Classe...53

5 DESENVOLVIMENTO DA SOLUÇÃO ... 60

5.1 ESCOLHA DAS TECNOLOGIAS ...60

5.1.1 API (Camada de Aplicação) ...60

5.1.2 APP (Camada de Visualização) ...62

5.1.3 Mobile ...63

5.2 RESULTADOS OBTIDOS ...64

5.2.1 API...65

5.2.2 Cliente WEB (APP)...67

5.2.2.1 Telas ...68 5.2.2.2 Funcionamento WEB...73 5.2.3 Aplicação Mobile ...74 5.2.3.1 Funcionamento ... 75 5.2.3.2 Sincronização ... 77 5.2.3.3 Segurança ... 79 5.3 AVALIAÇÃO ...81 5.3.1 Testes ...81

6 CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS ... 83

REFERÊNCIAS ... 85

APÊNDICES ... 89

APÊNDICE A – DIAGRAMAS DE CLASSE ... 90

APÊNDICE B – CASOS DE USO ... 94

APÊNDICE C – DIAGRAMAS DE SEQUÊNCIA ... 98

APÊNDICE D – TELAS ... 105

(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)

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)

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

Aqui são apresentados o objetivo geral e os objetivos específicos desta monografia.

1.2.1 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.

1.2.2 Objetivos Específicos

(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)

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.

2.1.1 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)

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)

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, apoiando-se 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.

2.2.1 Classificações

Segundo Wang et al (2008), a utilização do Cloud Computing é classificada em três modelos:

(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).

2.2.2 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)

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)

2.2.3 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)

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).

2.2.3.1 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)

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

(26)

2.2.3.2 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).

2.2.4 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)

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

(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)

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 Source1_{, 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.

2.3.1 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)

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)

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.

2.4.1 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).

2.4.1.1 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)

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”.

2.4.2 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)

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)

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

Para facilitar o alcance do objetivo proposto neste trabalho, ele está dividido em cinco etapas:

(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)

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)

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.

4.1.1 Tecnologias e Ferramentas

Nesta seção abordaremos a linguagem de programação e as tecnologias escolhidas para o desenvolvimento deste trabalho.

(38)

4.1.1.1 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).

4.1.1.2 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)

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.

4.1.1.3 Apache

Segundo o site do Projeto Apache HTTP Server (APACHE, 2013), este projeto é um:

(...) 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.

4.1.1.4 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)

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.

4.1.1.5 Android & Apache Cordova

Segundo o site do android (http://www.android.com/), 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 https://cordova.apache.org/. Este pacote de desenvolvimento permite que se programe para android utilizando html e javascript, inclusive utilizando angularjs.

(41)

4.1.1.6 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 https://netbeans.org/. 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

(42)

O processo toma como base casos de uso, que norteiam as fases da metodologia. O ICONIX é composto pelas seguintes fases:

Modelo de Domínio: Silva & Videira (2001), descrevem o Modelo de Domínio (Figura 10) como um “diagrama de classes de alto nível”, que serve para identificar os objetos do mundo real e todas as suas relações, sejam de generalização, associação ou agregação.

Figura 10 - Exemplo de Diagrama de Domínio Detalhado

Fonte: Silva & Videira, 2001, p.379

Modelo de Caso de Uso: “representam a visão do sistema na perspectiva do seu

utilizador” (Silva & Videira, 2001, p.123). Uma exemplificação de seu funcionamento pode ser vista na figura 11.

Figura 11 - Exemplo de um diagrama de casos de utilização

(43)

Análise de Robustez: Inicialmente proposto por Ivar Jacobson, a Análise de Robustez é uma forma de permitir ilustrar graficamente as interações entre os objetos participantes num caso de uso, conforme a figura 12. (Silva & Videira, 2001).

Figura 12 - Objectos usados os diagramas de robustez

Diagrama de Sequência: “permitem especificar a dinâmica ou o comportamento

de um sistema segundo a abordagem orientada por objectos” (Silva & Videira, 2001, p.123). Uma exemplificação de seu funcionamento pode ser vista na figura 13.

Figura 13 - Exemplo de um diagrama de sequência

(44)

Diagrama de Classe: “permitem especificar a estrutura estática de um sistema segundo a abordagem orientada por objectos” (Silva & Videira, 2001, p.123). ). Uma exemplificação de seu funcionamento pode ser vista na figura 14.

Figura 14 - Exemplo de um diagrama de classes.

4.3 MODELAGEM

Esta seção contém a modelagem da solução, e sua divisão foi criada tomando como base o ICONIX, descritos na seção anterior.

4.3.1 Requisitos

Esta seção aborda os requisitos da solução, assim como os meios pelos quais estes requisitos foram levantados.

(45)

4.3.1.1 Ferramentas já existentes

A análise dos requisitos foi realizada a partir de um estudo das principais ferramentas já existentes no mercado, levantadas a partir de buscas na internet e uma breve pesquisa com pessoas dos círculos sociais dos autores em conversas informais.

A partir das características encontradas na utilização de cada ferramenta, assim como na avaliação pessoal dos autores, foram escolhidas as 4 principais aplicações. Essa avaliação se baseou na existência de requisitos mínimos de uma gestão financeira pessoal, tais como cadastro de contas bancárias ou caixas, cadastro de categorias e controle de pagamentos. Também se favoreceu as aplicações que possuíam acesso via web, não sendo necessária a instalação de uma aplicação na máquina cliente, e que possuíssem ao menos uma versão gratuita.

4.3.1.1.1 Contas Online

Contas Online é uma aplicação que funciona via web. Seus principais diferencias entre as outras ferramentas é o controle de cartão de crédito e cadastro de marcas, uma forma de agrupar os lançamentos para futuros relatórios. Esta característica é útil, pois é possível visualizar, por exemplo, os custos provenientes de uma reforma realizada na casa ou uma festa de aniversário.

Uma outra característica importante é o cadastro de metas, que, de forma facilitada, auxilia o usuário em gerenciar o alcance de suas metas, tais como a compra de algum item ou uma viagem, por exemplo.

A aplicação conta também com uma versão mobile, mas que necessita do acesso à internet para seu funcionamento. Nas pesquisas não foi encontrada nenhuma versão mobile off-line.

(46)

4.3.1.1.2 Meu Dinheiro

Esta é uma aplicação que possui os módulos comuns às demais, mas mantem seu diferencial na versão mobile, que funciona de forma off-line. Possui também um controle de pagamentos fixos (como luz, água, aluguel) ou com parcelamento estático, sem variação entre as parcelas.

Url: https://www.meudinheiroweb.com.br/

4.3.1.1.3 Organizze

Possui uma interface simples, voltada aos lançamentos rápidos. Seus relatórios são baseados em gráficos, de modo a facilitar a compreensão dos usuários. A aplicação é voltada para quem precisa de uma ferramenta simples, sem muitos recursos, tais como grupos de lançamentos ou maiores detalhamentos.

A aplicação não conta com uma versão mobile para Android.

Url: https://www.organizze.com.br/pessoal

4.3.1.1.4 Minhas Economias

Esta aplicação possui um foco diferente das demais. Aqui, a missão principal do gerenciamento financeiro é o alcance de objetivos, como férias planejadas ou a compra de um carro novo e possui uma interface simples e didática.

A versão mobile apresentou uma série de problemas nos testes, principalmente na sincronização dos lançamentos realizados off-line.

(47)

4.3.1.2 Descrição do funcionamento do sistema

Esta descrição foi criada com base na análise dos softwares da seção anterior, capturando os itens comuns à todas elas:

O projeto permite que um usuário autenticado no cliente WEB, efetue o cadastro de lançamentos, assim como efetuar o cadastro de contas, categorias e centros de custo. Contas são representações de contas bancárias ou caixas, onde são feitas retiradas e entradas de valores. Os saldos das contas poderão vir a se tornar negativos, devido a pagamentos agendados. O usuário poderá realizar transferências de valores entre as contas.

Categorias possuem dois níveis: grupo e categoria. O grupo une as categorias por semelhança, tal como “Habitação” poderá agrupar categorias como “Aluguel”, “Luz” e “Água”. Dentro de um lançamento, poderão haver mais de uma categoria, cada qual com seu próprio valor, de modo à poder “diversificar” os itens dispostos dentro de um lançamento (Ex.: Supondo-se uma compra em um supermercado, um mesmo lançamento pode conter itens de alimentação, higiene e limpeza). Assim, na retirada de relatórios, poderá ser realizada uma análise hierárquica das entradas e saídas.

Centros de Custo são agrupamentos de lançamentos, que permitem uma análise mais aprofundada dos mesmos, servindo para separar os lançamentos em projetos distintos, como gastos de uma viagem ou com uma festa.

Os lançamentos são representações das entradas e saídas do usuário. Seu valor pode ser pago integralmente ou parcelado, em valores distintos sem padrão. Dessa forma, caso um usuário efetue uma compra de R$1.000,00, e tenha dado uma entrada de R$300,00, mais um pagamento de R$150,00 em 15 dias e o restante para 60 dias, o sistema deverá permitir esse controle.

O cliente WEB disponibiliza um painel principal, no qual o usuário visualiza um resumo do andamento de suas finanças, através de gráficos simplificados dos totais acumulados das contas, valores das categorias, e um comparativo Receitas X Despesas. Também irá disponibilizar a possibilidade de emissão de um extrato das contas bancárias do sistema e um relatório analítico com o detalhamento das categorias e seus valores.

Ao usuário que se autenticar no cliente Android, é possível efetuar lançamentos, assim como realizar consultas nos saldos atuais das contas. Aqui, não é possível efetuar o

(48)

cadastro de contas, categorias ou centros de custo, visando diminuir a complexidade para a rotina de sincronização entre os sistemas.

4.3.1.3 Quadro de Requisitos Funcionais

Abaixo, são encontrados os requisitos que serão utilizados na validação do sistema.

Quadro 1 - Quadro de Requisitos

ódigo

Requisito

1 O sistema deve permitir o cadastro de contas

2 O sistema deve permitir a transferência de valroes entre contas

3 _{cadastrados no sistema}O sistema deve permitir a emissão de um extrato bancário, baseado nos lançamentos

4 O sistema deve permitir o cadastro de Centros de Custo

5 O sistema deve permitir o cadastro de Categorias

6 O sistema deve permitir o cadastro de entidades (Fornecedores/Clientes)

7 O sistema deve permitir o cadastro de Lançamentos

8 Um lançamento pode conter relação com uma entidade

9 Um lançamento pode ser pago a vista ou parcelado

10 _custoUm Lançamento pode conter mais de um item, composto de uma categoria e um centro de

11 Um lançamento pode ser uma receita ou uma despesa

12 As parcelas de um Lançamento devem possuir o status de PENDENTE ou PAGO

13 Parcelas pagas não podem ser alteradas

14 hierarquia das mesmas O sistema deve permitir a emissão de um relatório analitico de categorias, respeitando a Fonte: dos autores, 2014

(49)

4.3.2 Domínio

Nesta tarefa foi realizado um levantamento superficial e não detalhado dos objetos do problema.

Figura 15 - Modelo de Domínio

Fonte: Elaboração dos autores, 2013

4.3.3 Casos de Uso

A solução propõe a utilização de um único ator, chamado de usuário. A figura a seguir permite uma visão mais precisa das ações que o mesmo poderá efetuar, tanto no ambiente web quando no ambiente Android.

(50)

Figura 16 - Diagrama de caso de uso

4.3.3.1 Detalhamento dos Casos de Uso

Detalhar um caso de uso é mostrar todas as ações executadas pelo usuário em determinado caso de uso. Com o intuito de explicar o funcionamento da arquitetura da aplicação, será detalhado o caso de uso 001, que representa a gestão das taxonomias. Para fins didáticos, compreende-se como taxonomia (neste trabalho), os artefatos que tem como objetivo categorizar e agrupar determinados registros. Enquadram-se neste sentido, os

(51)

artefatos Contas, Centros de Custo e Categorias, seguindo todos eles o mesmo fluxo para as operações básicas de Cadastro, Edição, Visualização e Remoção.

Quadro 2 - Detalhamento de Caso de Uso 001 CASO DE USO 001: Gerenciar Taxonomias

Descrição Gestão dos artefatos de Contas, Centros de Custo e Categorias

Ator(es) Usuário

Pré-condições O ator está autenticado no cliente WEB e Abriu o menu “Configurações”

Fluxo Principal 1. O usuário clicou no item referente à taxonomia que deseja gerenciar 2. O sistema abre a janela da nova taxonomia (TEL011);

3. O sistema lista os itens da taxonomia; 4. O usuário realiza uma das ações: 5. O usuário clica em “Fechar”; 6. O sistema fecha a janela;

Fluxos Alternativos e

exceções 4.1. O usuário preenche os dados de um novo item e clica em salvar; 4.1.1. O sistema informa que o item foi salvo e recarrega a listagem; 4.2. O usuário escolhe a opção editar de algum item da lista.

4.2.1. O sistema carrega as informações do item no formulário de edição; 4.2.2. O usuário altera os dados e clica em salvar;

4.2.3. O sistema informa que o item foi salvo e recarrega a listagem; 4.3. O usuário escolhe a opção excluir de algum item da lista;

4.3.1. O sistema remove o item;

4.3.2. O sistema informa que o item foi removido e recarrega a listagem; No item 4.1.1 e 4.2.2, caso alguma informação esteja incorreta, o sistema exibe uma mensagem mostrando qual informação está incorreta;

No item 4.3.2, caso não seja possível excluir o item, o sistema exibe uma mensagem informando;

A qualquer momento o usuário pode abortar a operação ao clicar no botão “cancelar”. Fonte: Elaborada pelos autores, 2013

Os demais detalhamentos dos casos de uso podem ser encontrados nos apêndices B.

(52)

4.3.3.2 Telas e Interfaces

As interfaces de taxonomias seguem um padrão, tanto estético quanto de mecânica, salvo à exceção da tela de Categorias, devido a forma como sua informação é apresentada ao usuário.

Como exemplificação, o protótipo de tela do cadastro de centros de custo pode ser considerado o mais genérico, conforme a figura 17.

Figura 17 - Tela de Taxonomia (Centros de Custo) (TEL011)

Uma tabela com as informações de tela pode ser encontrada no apêndice D.

4.3.4 Robustez

O fluxo base das requisições realizadas para a aplicação REST pode ser exemplificado pelo diagrama de robustez abaixo, utilizando o caso de uso 003.

(53)

O fornecedor REST recebe a requisição do usuário através da View da aplicação, e a mesma é tratada dentro do RestMiddleware, uma espécie de camada intermediadora que filtra e trata todas as requisições do usuário, sendo responsável por efetuar a validação da autenticação do usuário e da requisição efetuada, e direcionar para o controlador correto.

Figura 18 - Diagrama de Robustez do UC003

Na figura 18, após as devidas validações do mediador, a requisição é disparada para o controlador dos Lançamentos, o qual efetua a operação designada.

4.3.5 Sequência e Classe

Através do diagrama de sequência é possível verificar quais os métodos são necessários para se realizar a operação. Retornando ao caso de uso 001, onde é visualizada a mecânica básica por trás do sistema, pode ser vista também a interação (como também as facilidades e benefícios) com os frameworks utilizados no desenvolvimento. Entretanto, para

(54)

se compreender os próximos exemplos, é necessário conhecer a estrutura das classes de beans do sistema, representados no próximo diagrama.

Figura 24 - Diagrama de Classe de Beans da Aplicação

Tendo em mente os relacionamentos, agregações e composição das classes, é possível analisar os diagramas de sequência. Para facilitar a visualização e explicação, o diagrama do UC001 foi dividido em partes. A primeira parte representa a operação básica de listagem das taxonomias.