UNIVERSIDADE DO SUL DE SANTA CATARINA
JONATHAN CLEITON ALVES
APLICAÇÃO DE GERENCIAMENTO FINANCEIRO FAMILIAR WEB COM
INTERFACE MOBILE
Unisul
2014
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
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 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.
Universidade do Sul de Santa Catarina
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.
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.
“É 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
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.
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.
LISTA DE ILUSTRAÇÕES
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
Figura 43 - Diagrama de Sequência UC004 ............................................................................. 99
Figura 44 - Diagrama de Sequência UC005 ........................................................................... 100
Figura 45 - Diagrama de Sequência UC002 ........................................................................... 101
Figura 46 - Diagrama de Sequência UC007 ........................................................................... 102
Figura 47 - Diagrama de Sequência UC008 ........................................................................... 103
Figura 48 - Diagrama de Sequência UC009 ........................................................................... 104
LISTA DE TABELAS E QUADROS
Quadro 1 - Quadro de Requisitos ............................................................................................. 48
Quadro 2 - Detalhamento de Caso de Uso 001 ........................................................................ 51
Quadro 3- Resumo dos Casos de Teste .................................................................................... 81
Quadro 4 - Detalhamento de Caso de Uso 002 ........................................................................ 94
Quadro 5 - Detalhamento de Caso de Uso 003 ........................................................................ 94
Quadro 6 - Detalhamento de Caso de Uso 004 ........................................................................ 95
Quadro 7 - Detalhamento de Caso de Uso 005 ........................................................................ 95
Quadro 8 - Detalhamento de Caso de Uso 006 ........................................................................ 96
Quadro 9 - Detalhamento de Caso de Uso 007 ........................................................................ 96
Quadro 10 - Detalhamento de Caso de Uso 008 ...................................................................... 97
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
SUMÁRIO
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
4.3.3 Casos de Uso .............................................................................................................................49
4.3.3.1
4.3.3.2
4.3.4
4.3.5
Detalhamento dos Casos de Uso ............................................................................................ 50
Telas e Interfaces.................................................................................................................... 52
Robustez....................................................................................................................................52
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
APÊNDICE E – CASOS DE TESTE............................................................................................... 106
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
Os objetivos específicos são:
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;
1.3
•
Desenvolver um Cliente web que fará uso do webservice;
•
Desenvolver um Cliente Android que fará uso do webservice;
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, 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.
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
Fonte: CURBERA et al, 2002
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
Fonte: IMASTERS, 2012
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
Fonte: MACORATTI, 2014
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
Fonte: Silva & Videira, 2001, p.375
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
Fonte: Silva & Videira, 2001, p.123
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.
Fonte: Silva & Videira, 2001, p.123
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.
Url: https://www.contasonline.com.br
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.
Url: http://www.minhaseconomias.com.br/
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
Requisito
ódigo
O sistema deve permitir o cadastro de contas
1
O sistema deve permitir a transferência de valroes entre contas
2
O sistema deve permitir a emissão de um extrato bancário, baseado nos lançamentos
3
cadastrados no sistema
O sistema deve permitir o cadastro de Centros de Custo
4
O sistema deve permitir o cadastro de Categorias
5
O sistema deve permitir o cadastro de entidades (Fornecedores/Clientes)
6
O sistema deve permitir o cadastro de Lançamentos
7
Um lançamento pode conter relação com uma entidade
8
Um lançamento pode ser pago a vista ou parcelado
9
Um Lançamento pode conter mais de um item, composto de uma categoria e um centro de
10
custo
Um lançamento pode ser uma receita ou uma despesa
11
As parcelas de um Lançamento devem possuir o status de PENDENTE ou PAGO
12
Parcelas pagas não podem ser alteradas
13
14
O sistema deve permitir a emissão de um relatório analitico de categorias, respeitando a
hierarquia das mesmas
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
Fonte: Elaborada pelos autores, 2013
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.
2.
3.
4.
5.
6.
Fluxos Alternativos e
exceções
O usuário clicou no item referente à taxonomia que deseja gerenciar
O sistema abre a janela da nova taxonomia (TEL011);
O sistema lista os itens da taxonomia;
O usuário realiza uma das ações:
O usuário clica em “Fechar”;
O sistema fecha a janela;
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)
Fonte: Elaborada pelos autores, 2013
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
Fonte: Elaborada pelos autores, 2013
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
Fonte: Elaborada pelos autores, 2013
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.
55
Figura 25 - UC001 - Diagrama de Sequência de Listagem de Taxonomia
Fonte: Elaborada pelos autores, 2013
Como visto no diagrama de robustez, o usuário efetua a requisição para o
fornecedor REST, que trata o que será realizado dentro do RestMiddleware. Este mediador
dirige a requisição para o controller correto, que irá fazer o devido tratamento junto ao model.
O model, por sua vez, é gerido diretamente pelo ORM RedBean, que se encarrega
de todas as interações com o banco de dados e a geração dos beans, retirando da mão do
desenvolvedor esta preocupação. O model gera também uma lista de beans automaticamente,
não sendo necessário gerar uma instância de nenhum deles.
56
O próximo diagrama representa de forma mais clara este benefício do ORM,
demonstrando os passos realizados pela aplicação para inserir ou atualizar um bean de
taxonomia na aplicação.
Figura 19 - UC001 - Diagrama de Sequência de Inserir e Editar Taxonomia
57
Fonte: Elaborada pelos autores, 2013
O cadastro de taxonomias é uma operação simples, não possuindo outros beans
agregados à eles próprios. Mas, imaginando o cenário de um cadastro de um bean que possui
outros beans agregados, como um lançamento, que possui uma lista de itens e uma lista de
parcelas, o ORM trata automaticamente destas relações na hora de inserir (ou atualizar o
item), como demonstrado no diagrama a seguir, do caso de uso 003.
58
Figura 20 - Diagrama de Sequência UC003
Fonte: Elaborada pelos autores, 2013
Do mesmo modo, na operação de exclusão de um bean, o ORM também se
encarrega de verificar os relacionamentos entre eles, mantendo a integridade da base de
dados. Imaginando o cenário onde o usuário irá excluir uma conta, o RedBean se encarrega de
verificar se esta conta não está utilizada por transferências ou se não foram realizados
pagamento nela.
59
Figura 28 - UC001 - Diagrama de Sequência de Exclusão de Taxonomia
Fonte: Elaborada pelos autores, 2013
O diagrama de classes completo e os demais diagramas de sequência podem ser
encontrados nos apêndices deste trabalho.
60
5
DESENVOLVIMENTO DA SOLUÇÃO
Neste capítulo é descrito o processo de desenvolvimento da solução proposta,
justificando as ferramentas e tecnologias escolhidas e mostrando quais soluções foram
descartadas após a experimentação.
Ao final, o resultado alcançado é apresentado e validado com base na tabela de
requisitos.
5.1
ESCOLHA DAS TECNOLOGIAS
Várias tecnologias foram estudas no processo de escolha das mesmas, de modo a
buscar o caminho mais estável e de fácil manutenção para o desenvolvimento da solução. A
própria escolha de se utilizar REST na camada de aplicação teve a mesma motivação.
As tecnologias e ferramentas escolhidas estão disponíveis no capítulo 4, com suas
descrições. Entretanto, até chegar a esta escolha, outras tecnologias foram estudadas e
descartadas para esta aplicação, por não se enquadrarem em algum aspecto. A sessão está
dividida em 3 pontos de divisão da aplicação: Camada de Aplicação (REST), Camada de
Visualização (Cliente) e Aplicação Mobile. Em diversos artigos lidos durante a busca pelas
tecnologias ideais, a camada cliente era chamada de APP, enquanto a camada REST era
chamada de API. Daqui pra frente, de forma a facilitar o desenvolvimento da narrativa, essa
será a conotação utilizada.
5.1.1
API (Camada de Aplicação)
A camada de aplicação é onde estão todas as regras do sistema (o REST), assim
como o banco de dados. Aqui, o primeiro impedimento encontrado foi o financeiro, pois a
61
princípio pretendia-se utilizar NodeJs com MariaDB no servidor, duas tecnologias em grande
ascensão.
Em 2013 o Google iniciou a migração de suas bases de dados, antes em MySql
para MariaDB, dos mesmos criados do MySql (MEIOBIT, 2013). Ele é OpenSource e com o
apoio da Google em seu desenvolvimento, a tendência é que se torne um banco de dados cada
vez mais robusto.
Já o NodeJS é um interpretador de JavaScript que trabalha no servidor, voltado
para aplicações de tempo real. Extremamente simples de ser utilizado, esse interpretador,
diferente de outras plataformas como apache, mantém a conexão com o cliente a ponto de
poder lhe avisar de eventuais modificações para que o mesmo possa atualizar seus dados, não
trabalhando apenas em modo passivo.
Entretanto, a utilização de qualquer uma das tecnologias iria precisar de um
servidor dedicado ou de conhecimento mais avançados na parte de configuração de
servidores. Assim, foi preferível a segunda opção, na qual o autor já possuía grande
conhecimento: PHP e MySQL. O fato de ser a segunda opção não é um desmerecimento para
as tecnologias, pelo contrário. A escolha inicial pelo NodeJS e MariaDB foi a forma
encontrada de se aproveitar o desenvolvimento deste trabalho para aprender novas
tecnologias, mas como (à exceção do PHP e MySQL) basicamente todos os demais conteúdos
eram inéditos aos autores, essas camadas extras de complexidade poderiam vir a atrapalhar o
andamento do trabalho, ficando aqui como uma sugestão de migração para futuros trabalhos.
Uma vez definido este aspecto inicial da aplicação com a utilização LAMP
(Linux, Apache, MySQL e PHP), a escolha se estendeu à qual ferramenta poderia ser utilizada
para o auxílio no desenvolvimento.
A princípio pensou-se em utilizar CakePHP (http://cakephp.org/), mas com o
andamento da modelagem, foi perceptível que uma ferramenta mais simples e mais leve seria
suficiente para todas as demandas da aplicação. Assim, foi escolhido o microframework
SlimPHP para esta tarefa.
O mesmo possui o básico necessário para a administração de rotas de url em uma
aplicação REST, além de trabalhar com interceptadores de requisição, que facilitam as tarefas
de autenticação, validação, entre outras. Além disso, por ser um framework extremamente
enxuto, o mesmo possui um dos melhores desempenhos em relação à outros
(SYSTEMSARCHITECT, 2013).
Junto ao framework, foi escolhido um ORM para facilitar as interações com a
base de dados. Aqui, o primeiro escolhido foi o Doctrine (http://www.doctrine-project.org/),
62
mas sua complexidade não era necessária para o projeto, pois o ORM aqui serviria apenas
como um auxiliar à aplicação.
Logo
em
seguida
foram
realizados
testes
com
o
NotORM
(http://www.notorm.com/), mas constantes bugs nos relacionamentos entre as tabelas e a
documentação falha fizeram com que o mesmo fosse deixado de lado. Por fim, o escolhido foi
o RedBeanORM em sua versão 3.5.8, por sua simplicidade e perfeito funcionamento junto ao
SlimPHP.
A modelagem do banco de dados se encaixou perfeitamente nos requisitos do
ORM, e com sua utilização, tarefas básicas como listagens e CRUDs foram basicamente que
finalizadas, com exceção dos casos mais complexos que precisaram de testes mais
aprofundados buscando o melhor desempenho.
5.1.2
APP (Camada de Visualização)
A camada de visualização, utilizada pelo cliente (navegador do usuário), foi criada
como forma de acesso aos dados da API. Aqui, nenhuma regra essencial ao sistema foi
aplicada, pois por tratar-se de uma aplicação que roda no navegador do usuário, o mesmo
possui acesso ao código, podendo interferir nos dados encaminhados para a API.
Dessa forma, buscou-se deixar a camada o mais leve e simples possível,
trabalhando-se apenas na forma como os dados são apresentados e realizando validações
básicas, que serão replicadas no servidor caso o usuário interfira no funcionamento normal
das mesmas.
Nesta camada, de início, seria utilizado Bootstrap (http://getbootstrap.com/) junto
ao AngularJS. O Bootstrap seria responsável pelo desenvolvimento da interface, e o
AngularJS pela interação entre a API e os dados resultantes. Entretanto, a versão do Bootstrap
disponível na época não se comportava bem junto ao AngularJS, além de não atender algumas
necessidades da interface que seria desenvolvida.
Assim, foi descartado o Bootstrap e o CSS e Javascript da aplicação foi
desenvolvimento junto ao AngularJS, fazendo uso de algumas libs disponíveis para o JQuery
(http://jquery.com/), como o HighCharts (http://www.highcharts.com/) para os gráficos, entre
outros.
63
A ideia inicial era manter o suporte a navegadores antigos, entretanto, com o
desenvolver da aplicação se percebeu que alguns recursos teriam que ser deixados de lado ao
se tentar manter suporte a navegadores desatualizados e, por tratar-se de uma aplicação
fechada, essa camada de complexidade poderia ser evitada. Dessa forma, a aplicação passou a
seguir os padrões de suporte da google (https://support.google.com/a/answer/33864?hl=en),
que funcionam corretamente nas versões atualizadas do Firefox, Chrome, Safaria e IE
(sempre nas últimas 2 versões disponíveis).
Com essa escolha, foi possível remover uma série de implementações que
existiam apenas para suporte de versões antigas do IE, e o APP passou a funcionar com
HTML5 e CSS3, simplificando o desenvolvimento e o transformando em uma aplicação mais
leve e dinâmica.
Além disso, esta aplicação foi desenvolvida apenas para desktops, visto que existe
a versão mobile que ficará responsável por trabalhar em tablets e smartphones.
5.1.3
Mobile
Este foi um dos maiores desafios percorridos na execução do trabalho, pois era
um campo totalmente novo para o autor.
O primeiro requisito para a escolha das ferramentas foi a portabilidade. Pensou-se
em desenvolver nativamente para Android, mas a aplicação iria precisar, futuramente, ser
migrada para outras plataformas, como Ios. Assim, desenvolver nativamente iria dificultar
essa migração.
Assim, foram realizados vários testes com ferramentas de desenvolvimento para
mobile que possibilitassem a portabilidade entre plataformas de forma mais fácil. JQuery
Mobile (http://jquerymobile.com/) e Sensha Touch (http://www.sencha.com/products/touch/)
foram descartados pois não seguiam as especificações do projeto. Após isso, o escolhido foi o
PhoneGap (http://phonegap.com/) que, depois de algumas semanas de pesquisas e testes foi
trocado pelo seu sucessor, o Cordova (https://cordova.apache.org/), que é o mesmo
PhoneGap, porém mais atualizado e agora pertencente ao Apache, o que resultou em
constantes atualizações com melhorias e uma documentação mais completa.
64
Escolhida a parte estrutural do sistema, foram realizados testes com o bootstrap
para a parte visual, mas o mesmo parecia ficar muito pesado em dispositivos com pouca
memória, então foi alterado para o IOnic (http://ionicframework.com/), que permitiu a
utilização de AngularJS no dispositivo, além do HTML5 e CSS3, o que facilitou ainda mais o
desenvolvimento da aplicação e permitiu a reutilização de alguns scripts básicos já
desenvolvidos.
5.2
RESULTADOS OBTIDOS
A parte mais complexa do desenvolvimento da solução, com certeza, foi a
modelagem. Embora a ideia inicial da aplicação estive bem presente na mente dos autores,
colocar tudo isso no papel e realizar o devido planejamento foi uma tarefa difícil, mas muito
interessante.
Nesta etapa foi possível remover os pontos de complexidade que poderiam
atrapalhar o desenvolvimento da aplicação no tempo disponível da mesma, como o controle
de agendamentos e cartão de crédito, e dessa forma o desenvolvimento da solução se tornou
mais compatível com o calendário apresentado e o tempo disponível para a realização das
tarefas.
Também foi nesta etapa que diversos pontos que antes estavam difíceis de
entender como seriam realizados, foram organizados e então se tornaram possíveis de realizar,
como a própria sincronização entre os dispositivos.
E tudo teve seu primeiro passo com simples rascunhos, onde todas as
necessidades foram sendo estudadas e anotadas. Pouco a pouco os itens foram se relacionando
e os primeiros esboços da modelagem foram desenvolvidos ainda no papel, permitindo o
descarte de itens desnecessários, a validação de relacionamento entre objetos, e estudar quais
os itens seriam fundamentais para a criação deste trabalho, resultando na escolha da
arquitetura e tecnologias demonstradas na figura 21.
65
Figura 21- Arquitetura e Tecnologias
Fonte: Elaborada pelos autores, 2013
5.2.1
API
Uma vez realizado o filtro dos casos de uso que realmente seriam implementados,
e a modelagem básica ter sido realizada, o cronograma da aplicação foi divido em três partes,
do mesmo modo que a sessão anterior: API, APP e Mobile.
A API seria necessária para todas as demais atividades do trabalho, pois é o ponto
fundamental para aplicação. Sem ela, nenhuma das aplicações clientes possui utilidade.
Assim, a API foi desenvolvida tendo em mente todas as necessidades que as aplicações
poderiam vir a ter.
Dessa forma, foi criado um quadro de rotas (urls de requisição do REST) para que
pudesse ser realizado o desenvolvimento e os retornos de cada rota foram testados através de
uma
extensão
do
navegador
Chrome,
chamada
“Advanced
REST
cliente”
(http://goo.gl/NZBWva), que trabalha de forma simples, emulando um cliente consumidor de
REST.
Com essa extensão, foi possível testar os envios e recebimentos de cada rota da
API, manipulando os cabeçalhos da requisição e os dados enviados dependendo da
66
necessidade. A extensão trabalha muito bem com json, padrão utilizado na comunicação com
a API, o que possibilitou o estudo e correção de todos os envios e retornos. A Figura 22
representa um exemplo de requisição de login.
Figura 22 - Exemplo de Requisição de Login
Fonte: Elaborada pelos autores, 2014
Após a requisição ser enviada, a extensão exibe os detalhes da resposta do
servidor, conforme a figura 23:
Figura 23 - Exemplo de Resposta
Fonte: Elaborada pelos autores, 2014
67
Com essa extensão foi possível identificar as requisições que demoravam mais
tempo para trazer seu retorno (ou por terem um gasto maior no processamento ou por terem o
retorno muito pesado), assim como testar exceções e erros que poderiam a vir a ocorrer. Esses
testes possibilitaram que fosse realizado o tratamento destes problemas antes de iniciar o
desenvolvimento de qualquer um dos clientes.
5.2.2
Cliente WEB (APP)
Uma vez realizado o desenvolvimento da API, e a mesma já possuindo as rotas
bem definidas, iniciou-se o desenvolvimento do cliente web.
Nesta etapa do projeto, como já relatado, a primeira dificuldade encontrada foi o
Bootstrap. Uma das ideias iniciais seria criar um APP responsivo (que se ajusta a diversas
telas) para ganhar tempo no desenvolvimento mobile. Mas com o andamento dos testes, se
percebeu que as duas aplicações deveriam ser distintas, pois possuiriam uma arquitetura
completamente diferente uma da outra. Assim, junto à escolha de compatibilidade apenas com
os navegadores modernos e com a retirada do bootstrap, o desenvolvimento das telas pode ser
iniciado.
O primeiro passo foi criar o layout a partir dos protótipos, que tiveram que ser
modificados diversas vezes para atender a necessidades que vieram a surgir, tanto visuais
quanto de usabilidade.
O melhor exemplo é a tela de cadastro de lançamento, que era composta por abas
e passou a não mais possuir as mesmas e a gestão de categorias, que antes ficava dentro de um
modal e agora possui uma página para sua própria gestão.
Apenas após ter a interface funcionando nos navegadores desejados, é que a classe
de javascript que ficaria responsável pela conexão com a API foi criada. Ali, todos os
métodos de contato com a API foram registrados, junto as validações de dados e de
mensagens de erro. Com estes detalhes realizados, o AngularJS foi implantado e a cada
término de implantação do AngularJS houve uma bateria de testes em cada um dos
navegadores, para certificar-se de que o sistema estava dentro do esperado.
Neste desenvolvimento a API também foi novamente testada, sendo enviados
dados aleatórios com alguns erros propositais para testar a interação entre a API e o cliente
68
web. Alguns erros foram encontrados, como esperava-se naquele momento, sendo corrigidos
sempre que detectados.
5.2.2.1 Telas
As interfaces foram criadas utilizando-se da filosofia “Less Is More” (Menos é
Mais) do minimalismo, junto aos conceitos atuais de design da web e de aplicativos mobiles.
Dessa forma, o objetivo foi criar uma interface limpa e de fácil entendimento, de modo a
deixar o sistema rápido e auto didático. A interface de login é o exemplo mais claro disso:
Figura 24 - Interface de Login
Fonte: Elaborada pelos autores, 2014
Uma vez o usuário logado no sistema, ele terá acesso à um painel inicial (Figura
25) com informações básicas como saldos das contas, últimos lançamentos e um gráfico de
resultado mensal, comparando as receitas com despesas dos últimos seis meses.
A ideia dessa tela veio da necessidade de uma visualização rápida e de fácil
entendimento da situação financeira para o gestor familiar. Aqui, além de poder ficar por
dentro das últimas atualizações e cadastramentos de atualizações realizadas por outros
membros da família, o resumo do saldo das contas e o resumo financeiro poderá alertá-lo de
possíveis faltas de dinheiro em uma rápida análise.
69
Figura 25 – Visão Geral
Fonte: Elaborada pelos autores, 2014
Nesta tela estão os acessos rápidos aos itens de sistema, como a adição de um
novo lançamento, os relatórios e também o menu de configurações (Figura 26), onde
encontram-se os acessos a cadastros de Categorias, Centros de Custo, entre outros. As
interfaces voltadas para a configuração do sistema estão disponíveis no apêndice D.
Figura 26 – Configurações
Fonte: Elaborada pelos autores, 2014
A partir dessas configurações é que se torna possível realizar o cadastro de novos
lançamentos e transferências. Ambas as interfaces foram construídas para que o usuário não
70
tenha dificuldade em realizar as devidas ações, chegando em um resultado simples, como
demonstrado na figura 27, na interface de transferência:
Figura 27 – Nova Transferência
Fonte: Elaborada pelos autores, 2014
Até mesmo a interface de cadastro de lançamento, que possui diversos campos,
pois podem possuir mais de um item ou serem parcelados, foi otimizada de modo a ter uma
interface limpa e organizada. Dessa forma, a interface foi dividida em áreas especificas:
Informações, itens e parcelas.
71
Figura 28 – Tela de Movimentação
Fonte: Elaborada pelos autores, 2014
Essa divisão possibilita que o usuário consiga visualizar as áreas separadamente,
gerando conforto no momento de realizar a gestão de algum lançamento. Esta foi a tela que
necessitou do maior estudo para ser disponibilizada, passando desde a utilização de abas até a
atual tela.
Com o cadastro desses lançamentos e transferências, o usuário poderá visualizar
essas informações na forma de um relatório analítico ou de um extrato.
No primeiro caso, o usuário conseguirá visualizar um detalhamento por categoria
e grupo de categoria, dividido por situação (pendente e pago). O relatório sempre corresponde
à um mês, que o usuário informa, junto ao regime de período que deseja visualizar,
competência (data do lançamento) ou vencimento (vencimento das parcelas). Ao fim do
relatório, o usuário pode visualizar o resultado financeiro daquele período.
Na figura 26 (recortada para poder exemplificar o relatório), é possível ver a
divisão dos itens e a apresentação dos totais.
72
Figura 29 – Relatório Analítico
Fonte: Elaborada pelos autores, 2014
Já no segundo caso, o extrato, tem como funcionalidade mostrar o histórico de
transações realizadas em uma determinada conta em um determinado período, conforme
exemplificado abaixo, na figura 27:
Figura 30 – Extrato
Fonte: Elaborada pelos autores, 2014
Além desses relatórios, o usuário tem a possibilidade de gerar uma listagem de
lançamentos utilizando os critérios que desejar, como descrição, centro de custo, etc. Todos os
itens disponíveis dentro de um lançamento são possíveis de se utilizar neste filtro.
73
Figura 31 – Filtros
Fonte: Elaborada pelos autores, 2014
Na listagem gerada o usuário poderá editar/excluir os lançamentos ou até mesmo
efetuar o pagamento das parcelas.
Maiores detalhes do funcionamento do sistema podem ser conferidos no endereço:
http://tcc.finnancer.com.br, com o usuário de teste “tcc” e senha “tcc”.
5.2.2.2 Funcionamento WEB
Partindo para a parte técnica da solução, toda a aplicação web funciona a partir de
requisições para o servidor REST, a API, e com o json resultante de cada uma das
solicitações, ela vai se moldando. Isso é importante de ser ressaltado, pois aqui é onde está um
dos objetivos da realização deste trabalho.
A utilização do servidor com a aplicação REST, juntamente ao AngularJS na
interface, permite que a aplicação se molde facilmente, dependendo da necessidade. Como
exemplo, pode ser analisado o retorno do servidor ao pesquisar lançamentos realizados a
partir de determinados critérios.
74
Figura 32 – Retorno Json
Fonte: Elaborada pelos autores, 2014
Este retorno é utilizado em diversos lugares da aplicação, tanto no relatório de
lançamentos quanto para a geração dos lançamentos recentes utilizados na tela inicial da
aplicação web. E, caso venha a ser necessário alguma outra interface que faça uso da listagem
de lançamentos (últimos lançamentos atualizados, por exemplo), não haverá necessidade de se
criar um método especifico, pois os métodos genéricos disponíveis no REST possibilitam
todas as interações necessárias no sistema.
Por ser um único servidor REST centralizando as regras do sistema, qualquer
outra aplicação consumidora dessa API poderá utilizar os dados da forma necessária para a
aplicação cliente em questão.
Este é o ponto mais importante do cliente web, pois permite que grande parte da
carga de processamento seja mantida no servidor, e não no cliente, dando maior versatilidade
para a manipulação das interfaces.
5.2.3
Aplicação Mobile
O grande desafio dessa etapa estava concentrado na configuração do ambiente de
trabalho. Configurar o phonegap no Windows foi muito problemático, mesmo com os
inúmeros tutoriais encontrados na web.
Por alguma razão, sempre parecia faltar alguma dependência para o projeto
conseguir rodar sem problemas. Dessa forma, o phonegap foi trocado pelo cordova, que
75
funcionou na primeira tentativa, sem erros. Apenas após ter o ambiente funcionando
corretamente é que se iniciou o desenvolvimento das interfaces sem funcionalidades, apenas
no esqueleto, seguindo os protótipos.
O desenvolvimento das interfaces foi facilitado pela utilização do framework
Ionic, que possibilitou a utilização do AngularJS nas interfaces. Com o Cordova foi criada
uma versão simplificada da base de dados no dispositivo móvel, que possuía um hardware
extremamente fraco, contando com pouco menos de 300mb de memória e uma tela de apenas
3,5 polegadas.
A proposta de se utilizar as configurações bem abaixo das necessárias para
utilização surgiu como forma de validar o desempenho do software durante o
desenvolvimento. Como ele rodava fluentemente em configurações mínimas, em aparelhos
com características mais fortes o aplicativo ficava ainda mais rápido.
5.2.3.1 Funcionamento
Um dos requisitos básicos da aplicação mobile é a necessidade de se poder utilizar
o mesmo sem acesso à internet, para que a tarefa de gestão fique mais prática e possa ser
realizada sem essa dependência constante. A internet ficou como requisito apenas para a
tarefa de login inicial (após a instalação do aplicativo) e para efetuar a sincronização.
Assim, de forma a comportar os dados no próprio aparelho, foi necessário criar
uma estrutura de dados diferenciada, conforme exemplificado na figura 33:
76
Figura 33 – Base de Dados do Cliente Mobile
Fonte: Elaborada pelos autores, 2014
Com essa estrutura de dados, a aplicação permite que o usuário consulte o saldo
de suas contas e seus resultados mensais. Também está liberada uma versão simplificada do
cadastro de lançamentos, que ficam armazenados no aparelho até que seja conectado à
internet para poder ser realizada a sincronização.
Figura 34 – Tela inicial do Mobile e de Saldos Bancários
Fonte: Elaborada pelos autores, 2014
77
5.2.3.2 Sincronização
Mesmo embora no momento o sistema possua um único usuário, este usuário
pode conectar-se de múltiplos dispositivos diferentes simultâneamente. Além disso, toda a
aplicação foi construída prevendo a utilização de múltiplos usuários em múltiplos
dispositivos. Dessa forma, cada registro do banco de dados da API guarda a data e hora de sua
última alteração, de modo a prevenir que alguma alteração seja sobrescrita.
Além disso, todas os processos da API que se referem a manipular dados do
banco de dados são encapsulados em Transações do banco de dados e, caso algum problema
ocorra no decorrer do processo, seja do sistema ou de validação, tudo é restaurado ao ponto
inicial, para que não haja perda de dados.
Com esta estrutura é possível criar o mecanismo de sincronização entre as
plataformas. O cliente web por si só está sempre atualizado, pois ele não armazena dados,
apenas consome da API. Entretanto, como a aplicação mobile foi desenvolvida para trabalhar
com alguns recursos de modo off-line, este controle é vital para o funcionamento da
arquitetura.
Assim, um processo simplificado foi criado para realizar essa tarefa, divido em
duas etapas. A primeira etapa, ocorrida no primeiro acesso do usuário após a instalação da
aplicação no dispositivo, é a responsável pela carga inicial do sistema. Aqui, o usuário precisa
estar conectado à internet e deve inserir seus dados de login e senha. Uma vez inserido os
dados, a aplicação irá armazenar o login na base de dados do aparelho, e irá iniciar o processo
de sincronização com a API, onde os dados essenciais são baixados pela primeira vez, como
contas, categorias, centros de custos e os resultados de cada mês até o momento. A partir
deste ponto o usuário pode cadastrar novos lançamentos ou consultar seus saldos e resultados.
A segunda etapa ocorre quando o usuário solicitar que a aplicação sincronize com
o servidor. Aqui, a senha de sua conta é novamente solicitada para que possa ser efetuado o
login na API, para se iniciar a sincronização. Neste processo, toda a prioridade está voltada
para os lançamentos cadastrados no sistema, que são disparados para o servidor um a um, e
excluídos da base temporariamente após a confirmação do cadastro. Finalizado esse processo,
o aplicativo irá solicitar para o servidor a listagem atualizada de contas, categorias e centros
de custo. Após isso, atualizará os resultados mensais, finalizando a sincronização. Este
processo é exemplificado pela figura 32:
78
Figura 35 – Processo de Sincronização
Fonte: Elaborada pelos autores, 2014
Com essa dinâmica, o usuário pode trabalhar com a aplicação sem necessitar estar
conectado na internet, dando maior flexibilidade para os momentos em que for efetuar novos
lançamentos sempre que houver a necessidade.
79
5.2.3.3 Segurança
Embora não estivesse no foco do trabalho, uma camada básica de segurança foi
adicionada ao sistema, de modo a tratar a autenticação de usuários e evitar o uso indevido dos
dados.
Para isso, foi utilizado um recurso do Slim Framework chamado de Middleware,
que trabalha como um “filtro” da aplicação, verificando todas as requisições e respostas,
permitindo que sejam efetuadas diversas verificações, como autenticação e cache. Toda
requisição passa por essa camada, que faz o roteamento da aplicação e, principalmente, as
validações de segurança.
Figura 36 – RestMiddleware
Fonte: SITEPOINT, 2013
Toda requisição para o servidor REST deve conter em seu cabeçalho uma chave
de autenticação. Ou, no cliente web, um cookie com essa chave. A rota de login é a única rota
que não necessita de uma chave de autenticação para se poder acessar, pois, quando um
usuário efetua login no servidor REST (no cliente android o usuário e senha estão no código
temporariamente), o mesmo ainda não possui essa chave.
Assim, ao receber a requisição o servidor verifica as credenciais e monta uma
chave válida por apenas 15 minutos. Essa chave deve ser fornecida ao servidor REST em
todas as demais requisições, caso contrário o mesmo irá negar a requisição. Nos casos de
verificação bem sucedida da chave, a mesma é revalidada por mais 15 minutos.
80
Essas chaves não ficam armazenadas no servidor, mas possuem uma lógica para
que a aplicação consiga identificar quem e da onde está partindo a solicitação, para saber se
pode ou não responder à ela.
Os dados armazenados nessa chave são o ip e host de origem do usuário, id e hash
de senha do, microssegundos da requisição, e uma frase chave da aplicação, que é alterada de
tempos em tempos desvalidando qualquer requisição permanente.
Tanto o id do usuário quanto os microssegundos da requisição possuem suas bases
numéricas alteradas. Por fim, desses dados é gerada uma hash com SHA1, e enviado ao
requisitante junto ao id e tempo da requisição, conforme exemplificado abaixo, na figura 34:
Figura 37 – Criação da hash de autenticação
Fonte: Elaborada pelos autores, 2014
Dessa forma, ao receber a hash do cliente, o sistema verifica o tempo da
requisição (se ultrapassou o limite permitido) e verifica se a hash é válida, capturando a
origem do cliente, o hash de sua senha (a partir de seu id) e as demais informações. Se a hash
resultante estiver correta, a aplicação aceita a requisição.
Embora esse tipo de autenticação obrigue o usuário a usar sempre a mesma
origem para validar a hash, caso o mesmo deixe sua máquina efetuando uma requisição de
tempos em tempo, ele ficará autenticado perpetuamente, apenas tendo seu login bloqueado
quando a frase segredo da aplicação for alterada.
Esta não é a forma mais segura de se autenticar, entretanto, obedece o conceito de
RESTfull, que não mantém internamente as informações do usuário autenticado, deixando
que o cliente da API tome conta desta tarefa.
Como sugestão para trabalhos futuros, além da implantação de um certificado
HTTPS para fortalecer a segurança da comunicação, seria interessante um trabalho tratando
sobre segurança e autenticação em aplicações REST.
81
5.3
AVALIAÇÃO
A avaliação da solução final foi realizada com base na tabela de requisitos
apresentada na modelagem da aplicação. Além disso, foram realizados alguns testes de
funcionamento após o término do desenvolvimento.
5.3.1
Testes
Alinhado a norma IEEE 830 (MATH, 2014), foram desenvolvidos alguns casos
de testes para verificar o funcionamento da ferramenta. Os casos de testes usaram como base
inicial os casos de usos, detalhando cada um dos itens para manter-se a segurança da
funcionalidade. O detalhamento dos casos de testes está no Apêndice E, e um resumo do
resultado dos casos de teste pode ser verificado na tabela abaixo:
Quadro 3- Resumo dos Casos de Teste
Código
CT001
CT002
CT003
CT004
CT005
CT006
CT007
CT008
CT009
CT010
Nome
Cadastrar Taxonomia
Editar Taxonomia
Remover Taxonomia
Inserir Lançamento
Efetuar Transferência
Pagar parcela de lançamento
Gerar Extrato
Gerar Relatório Analítico
Inserir Lançamento (Mobile)
Sincronizar com o Servidor
Bugs Encontrados
10
5
2
36
3
5
8
4
15
5
Bugs Corrigidos
8
4
0
33
3
5
8
4
10
3
Fonte: Elaborada pelos autores, 2014
Grande parte dos problemas encontrados durante a realização dos testes puderam
ser corrigidos, com exceção de alguns problemas relacionados a sincronização, que ainda
necessitam de um tratamento mais aprimorado. No bug, caso um lançamento seja realizado
com algum relacionamento em alguma taxonomia (conta, centro de custo ou categoria) e no
momento da sincronização o sistema verificar que aquela taxonomia não existe mais, a
82
mesma não é gravada no banco de dados do servidor, permanecendo no dispositivo do
usuário. Para solucionar esse problema é necessária a criação de uma interface onde o usuário
pudesse efetuar as devidas alterações em seus cadastros de lançamentos dentro do dispositivo,
para então poder novamente efetuar a sincronização.
83
6
CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS
Desde o início a motivação para a escolha dessa aplicação, tanto o tema quanto as
tecnologias, foram derivadas da necessidade do autor de possuir uma ferramenta que lhe
auxiliasse na gestão financeira pessoal, pois os diversos aplicativos hoje existentes não
possuíam todas as ferramentas necessárias. Além desta motivação, existia um grande interesse
em seu estudar tecnologias que até então não haviam sido utilizadas pelos autores, como
AngularJs, desenvolvimento mobile e a própria arquitetura REST.
Desenvolver
usando
essas
tecnologias
se
mostrou
extremamente
útil,
principalmente no quesito manutenção, que foi muito facilitada pelo ORM e pelo AngularJS.
A própria arquitetura do framework utilizado para o desenvolvimento, por sua simplicidade e
independência de outras libs, fizeram com que o trabalho de desenvolvimento corresse sem
muitas complicações e necessidade de aprender a utilizar diversas outras ferramentas.
Para realizar este trabalho, tentou-se abstrair toda a complexidade que poderia vir
a ser criada sem necessidade, de forma a se tornar um ótimo projeto para o estudo das
tecnologias e métodos. Tentou-se aplicar uma modelagem simplificada, que foi revista a cada
novo ciclo de desenvolvimento do modelo incremental, para que se chegasse no resultado
obtido.
Dessa forma, os objetivos deste trabalho foram atingidos. No entanto, o resultado
obtido está apto a receber novas funcionalidades para se tornar uma ferramenta mais completa
para o objetivo para o qual foi projetado. Por enquanto, essas funcionalidades ficam aqui
como sugestões para trabalhos futuros:
•
Implementação de Gestão de Cartão de Crédito e Agendamentos;
•
Gestão de orçamento e metas;
•
Maior poder de controle na aplicação Mobile;
•
Portar a aplicação para IOS e demais sistemas operacionais mobile;
•
Implantação de teste unitários;
•
Validações de segurança na aplicação;
•
Cadastro e gestão de usuários;
84
Com a adição destas funcionalidades seria possível iniciar a comercialização da
aplicação, que possui todos os requisitos necessários para uma ótima entrada no mercado
comparado às soluções pesquisadas durante o processo de análise das ferramentas disponíveis
atualmente no mercado.
85
REFERÊNCIAS
ALVES, Alessandra Batista de Melo Nóbrega. Planejamento Financeiro Familiar E
Orçamento Doméstico. Disponível em:
<http://www.sudamerica.edu.br/arquivos_internos/publicacoes/PLANEJAMENTO_FINANC
EIRO_FAMILIAR_E_O_ORCAMENTO_DOMESTICO.pdf>. Acesso em: 27 ago. 2013.
ANDROID. Meet Android. 2014. Disponível em: < http://www.android.com/>. Acesso em:
29 mar. 2014.
APACHE. HTTP server project. 2013. Disponível em: <http://httpd.apache.org/>. Acesso
em: 12 nov. 2013.
ANGULARJS. Superheroic Javascript MVC Framework. 2013. Disponível em:
<http://angularjs.org/>. Acesso em: 09 nov. 2013.
CHEROBIM, Ana Paula Mussi Szabo; ESPEJO, Márcia Maria dos Santos Bortolocci.
Finanças pessoais: conhecer para enriquecer! São Paulo: Atlas, 2010.
CONTE, Tayana; MENDES, Emília; TRAVASSOS, Guilherme Horta. Processos de
desenvolvimento para aplicações web: Uma revisão sistemática. In: Proceedings of the 11th
Brazilian Symposium on Multimedia and Web (WebMedia 2005). 2005. p. 107-116.
Disponível em:
<http://lens.cos.ufrj.br:8080/ESEWEB/materials/RSProcessoWeb/2005_10_31_Conte_Web
Media_2005_pubform.pdf>. Acesso em: 06 out. 2013.
CURBERA, Francisco, et al. "Unraveling the Web services web: an introduction to SOAP,
WSDL, and UDDI." Internet Computing, IEEE 6.2 (2002): 86-93. Disponível em: <
http://tele1.dee.fct.unl.pt/rit2_2009_2010/teo/soap.tutorial.pdf>. Acesso em: 25 set. 2013.
FIELDING, Roy Thomas. Architectural Styles and the Design of Network-based Software
Architectures. 2000. Disponível em:
<http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm>. Acesso em: 24 ago.
2013.
FROST & SULLIVAN. MEGA TRENDS. 2011. Disponível em: <http://frostapac.com/download/megatrends.pdf>. Acesso em: 14 set. 2013.
G1. Economista Mauro Halfeld dá dicas sobre orçamento familiar. 2013. Disponível em:
<http://g1.globo.com/pr/parana/noticia/2013/06/economista-mauro-halfeld-da-dicassobreorcamento-familiar.html>. Acesso em: 20 ago. 2013.
GIL, Antônio Carlos. Como elaborar projetos de pesquisa. 4. ed. São Paulo: Atlas, 2002.
GITMAN, Lawrence J. Princípios da administração financeira: Essencial. Porto Alegre:
Bookman, 2001.
GNU. Filosofia do Projeto GNU. 2011. Disponível em:
<http://www.gnu.org/philosophy/philosophy.html>. Acesso em: 06 out. 2013.
86
HOJI, Masakazu. Administração financeira na prática: Guia para educação financeira
corporativa e gestão financeira pessoal. São Paulo. Atlas, 2009.
IBGE. Pesquisa de Orçamentos Familiares 2008-2009. 2009. Disponível em:
<http://www.ibge.gov.br/home/estatistica/populacao/condicaodevida/pof/2008_2009_perfil_d
espesas/default.shtm>. Acesso em: 20 ago. 2013.
ICONIXPROCESS. Iconix Process, 2013. Disponível em: <http://iconixprocess.com/ >. Acesso
em: 08 nov. 2013.
IMASTERS. Exemplo de integração REST entre servidor e cliente. 2012. Disponível em:
< http://imasters.com.br/desenvolvimento/exemplo-de-integracao-rest-entre-servidor-ecliente/>. Acesso em: 20 ago. 2013.
IDC. Android and iOS Combine for 91.1% of the Worldwide Smartphone OS Market in
4Q12 and 87.6% for the Year, According to IDC. 2013. Disponível em:
<http://www.idc.com/getdoc.jsp?containerId=prUS23946013>. Acesso em: 24 ago. 2013.
JSON. Introdução ao JSON. 2013. Disponível em: < http://json.org/json-pt.html >. Acesso
em: 21 set. 2013.
LECHETA, Ricardo R. Google Android - Aprenda a Criar Aplicações Para Dispositivos
Móveis Com o Android Sdk – NOVATEC, 3ª Ed 2013.
LUBLINSKY, B. Defining SOA as an Architectural Style. Estados Unidos: IBM
Developers, 2007. Disponível em: <
http://www.ibm.com/developerworks/architecture/library/ar-soastyle/>. Acesso em: 21 set.
2013.
MACORATTI. Modelando Sistemas em UML - Casos de Uso. 2014. Disponível em: <
http://www.macoratti.net/net_uml2.htm/>. Acesso em: 29 mar. 2014.
MATH. IEEE Recommended Practice for Software Requirements Specifications. 2014.
Disponível em: < http://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf >. Acesso em:
22 mai. 2014.
MEIOBIT. Google troca base de dados MySQL por MariaDB. 2013. Disponível em: <
http://meiobit.com/267380/google-troca-base-dados-mysql-mariadb//>. Acesso em: 03 mai.
2014.
MCCARTHY, John. Oral history interview with John McCarthy. 1989. Disponível em: <
http://conservancy.umn.edu/handle/107476>. Acesso em: 14 set. 2013.
MySQL. The world's most popular open source database. 2013. Disponível em:
<http://www.mysql.com/>. Acesso em: 12 nov. 2013.
NASCIMENTO, Bárbara. Endividamento das famílias é o maior desde julho de 2011,
aponta CNC. 2013. Disponível em:
<http://www.correiobraziliense.com.br/app/noticia/economia/2013/04/18/internas_economia,
361149/endividamento-das-familias-e-o-maior-desde-julho-de-2011-aponta-cnc.shtml>.
Acesso em: 20 ago. 2013.
87
NASCIMENTO, Tatiana. Crédito fácil atiça desejo de comprar. Diário de Pernambuco.
2010. Disponível em: <http://blogs.diariodepernambuco.com.br/economia/?p=4932>. Acesso
em: 21 set. 2013.
PEREIRA, Lucio Camilo Oliva, SILVA, Michel Lourenço Da. Android para
Desenvolvedores. Rio de Janeiro. Brasport, 2009.
PHP. Manual do PHP. 2013. Disponível em:
<http://www.php.net/manual/pt_BR/preface.php>. Acesso em: 09 nov. 2013.
PRESSMAN, Roger S. Engenharia de software. São Paulo. McGraw-Hill, 2006.
RÁDIO APARECIDA. Endividamento das famílias é o maior desde julho de 2011,
aponta CNC. 2013. Disponível em:
<http://www.a12.com/noticias/noticia.asp?ntc=nivel_de_endividamento_do_brasileiro_cresce
u_em_abril.html>. Acesso em: 20 ago. 2013.
REDBEAN. RedBeanPHP. 2013. Disponível em: <http://www.redbeanphp.com/>. Acesso
em: 09 nov. 2013.
SAMPAIO, Cleuton. SOA e Web Services em Java. Rio de Janeiro. Brasport, 2006.
SILVA, Edna Lúcia da; MENEZES, Estera Muszkat. Metodologia da pesquisa e elaboração
de dissertação. 4 ed. Florianópolis: UFSC, 2005.
SILVA, Alberto M. R.; VIDEIRA, Carlos A. E. UML, Metodologias e Ferramentas Case.
Lisboa: Centro Atlântico, 2001. Disponível em: <
http://www.romeumenezes.com.br/livros/Livro%20%20UML%20Metodologias%20e%20Ferramentas%20CASE.pdf>. Acesso em: 08 nov.
2013.
SITEPOINT. Working with Slim Middleware. 2013. Disponível em:
<http://www.sitepoint.com/working-with-slim-middleware/> Acesso em: 10 nov. 2013.
SLIM. Slim Framework. 2013. Disponível em: < http://www.slimframework.com/>. Acesso
em: 09 nov. 2013.
SOMMERVILLE, Ian. Engenharia de software. São Paulo. Addison-Wesley, 2003.
SYSTEMSARCHITECT. Performance benchmark of popular PHP frameworks. 2013.
Disponível em: <http://systemsarchitect.net/performance-benchmark-of-popular-phpframeworks/>. Acesso em: 03 mai. 2013.
TAURION, César. Cloud Computing - Computação em Nuvem: transformando o mundo
da tecnologia da informação. Rio de Janeiro. Brasport, 2009.
TOMÉ, Marcio Sandoval. Integração de sistemas desktop com dispositivos móveis
utilizando web services. Trabalho De Diplomação. UNIVERSIDADE TECNOLÓGICA
FEDERAL DO PARANÁ, 2011. Disponível em: <
http://repositorio.roca.utfpr.edu.br/jspui/bitstream/1/603/1/MD_COADS_2011_2_08.pdf>.
Acesso em: 21 set. 2013.
88
W3C. SOAP. 2007. Disponível em: <http://www.w3.org/TR/soap/>. Acesso em: 29 out.
2013.
W3C. Extensible Markup Language (XML) 1.0 (Fifth Edition). 2008. Disponível em: <
http://www.w3.org/TR/ws-arch/ >. Acesso em: 24 out. 2013.
W3C. Web Services Activity. 2013. Disponível em: < http://www.w3.org/2002/ws/>. Acesso
em: 24 out. 2013.
W3C. Web Services Architecture. 2004. Disponível em: http://www.w3.org/TR/RECxml/>. Acesso em: 29 out. 2013.
W3SCHOOL. XML. 2013. Disponível em: http://www.w3schools.com/xml/xml_tree.asp/>.
Acesso em: 05 out. 2013.
WANG, Lizhe, et al. "Scientific cloud computing: Early definition and experience." High
Performance Computing and Communications, 2008. HPCC'08. 10th IEEE International
Conference on. Ieee, 2008. Disponível em:
<http://cyberaide.googlecode.com/svn/trunk/papers/08-cloud/vonLaszewski-08-cloud.pdf >.
Acesso em: 21 set. 2013.
WMCCANNBR. Consumidor Móvel 2011. 2011. Disponível em: <http://goo.gl/nc7xao>.
Acesso em: 24 ago. 2013.
89
APÊNDICES
90
APÊNDICE A – Diagramas de Classe
Figura 38 – Diagrama de Classe de Beans
Fonte: Elaborada pelos autores, 2014
91
Figura 39 – Diagrama de Classe de Models
Fonte: Elaborada pelos autores, 2014
92
Figura 40 – Diagrama de Classe de Controllers
Fonte: Elaborada pelos autores, 2014
93
Figura 41 – Diagrama de Classe de Aplicação
Fonte: Elaborada pelos autores, 2014
94
APÊNDICE B – Casos de Uso
Quadro 4 - Detalhamento de Caso de Uso 002
CASO DE USO 002: Login
Descrição
Efetua login na API rest
Ator(es)
Usuário
Pré-condições
O ator está no formulário de login (TEL001) de algum cliente
Fluxo Principal
1.
2.
3.
4.
Fluxos Alternativos e
exceções
No item 2, caso algumas informação esteja incorreta:
2.1 – O sistema exibe uma mensagem informando que o usuário ou senha estão
incorretos;
O usuário informa seus dados de login e senha;
O sistema verifica no banco pelo usuário com login igual ao solicitado;
O sistema gera a hash com a senha informa e compara com o hash salvo no banco.
O sistema retorna o hash de autenticação temporário;
Fonte: Elaborada pelos autores, 2013
Quadro 5 - Detalhamento de Caso de Uso 003
CASO DE USO 003: Insere Lançamento
Descrição
Cadastra um lançamento no sistema
Ator(es)
Usuário
Pré-condições
O ator está autenticado no cliente WEB
Fluxo Principal
1.
2.
3.
4.
5.
6.
7.
8.
Fluxos Alternativos e
exceções
No item 6, caso algumas informação esteja incorreta:
6.1 – O sistema exibe uma mensagem mostrando qual informação está incorreta;
O usuário clica em “Novo Lançamento”;
O usuário escolhe a natureza do lançamento;
O sistema abre a janela “Modal” de “Novo Lançamento” (TEL002);
O usuário informa os dados do lançamento;
O usuário clica em “Salvar”;
O sistema efetua validação dos dados cadastrados
O sistema cadastra os dados no banco
O sistema informa que o Lançamento foi salvo e fecha a janela;
A qualquer momento o usuário pode abortar a operação ao clicar no botão “cancelar”.
Fonte: Elaborada pelos autores, 2013
95
Quadro 6 - Detalhamento de Caso de Uso 004
CASO DE USO 004: Efetua transferência entre contas
Descrição
Cadastra uma transferência bancária no sistema
Ator(es)
Usuário
Pré-condições
O ator está autenticado no cliente WEB
Fluxo Principal
1.
2.
3.
4.
5.
6.
Fluxos Alternativos e
exceções
No item 5, caso algumas informação esteja incorreta:
5.1 – O sistema exibe uma mensagem mostrando qual informação está incorreta;
O usuário clica em “Novo Lançamento”;
O usuário clica em “Transferência”;
O sistema abre a janela “Modal” de “Nova Transferência” (TEL003);
O usuário informa os dados da transferência;
O usuário clica em “Salvar”;
O sistema informa que a transferência foi salva e fecha a janela;
A qualquer momento o usuário pode abortar a operação ao clicar no botão “cancelar”.
Fonte: Elaborada pelos autores, 2013
Quadro 7 - Detalhamento de Caso de Uso 005
CASO DE USO 005: Gera extrato da conta
Descrição
Lista as movimentações cadastradas em uma conta bancaria dentro do período
selecionado
Ator(es)
Usuário
Pré-condições
Fluxo Principal
O ator está autenticado no cliente WEB e está na tela de solicitação de extrato
(TEL004)
1. O usuário escolhe a conta e informa o período no qual desejar ver o extrato;
2. O sistema captura os pagamentos realizados dentro do período, naquela conta;
3. O sistema captura as transferências realizadas dentro do período, naquela conta;
4. O sistema mescla as duas listas, e ordena por data;
5. O sistema exibe a listagem de movimentações;
Fonte: Elaborada pelos autores, 2013
96
Quadro 8 - Detalhamento de Caso de Uso 006
CASO DE USO 006: Pagar parcela de lançamento
Descrição
Efetuar o pagamento de uma parcela de um lançamento em uma conta
Ator(es)
Usuário
Pré-condições
Fluxo Principal
Fluxos Alternativos e
exceções
O ator está autenticado no cliente WEB e encontra-se na listagem de lançamentos
(TEL005)
1. O usuário seleciona uma parcela;
2. O usuário clica em “Pagar”;
3. O sistema abre a janela “Modal” de “Pagar Parcela” (TEL006);
4. O usuário informa os dados do pagamento;
5. O usuário clica em “Salvar”;
6. O sistema informa que o pagamento foi salvo e fecha a janela;
No item 5, caso algumas informação esteja incorreta:
5.1 – O sistema exibe uma mensagem mostrando qual informação está incorreta;
A qualquer momento o usuário pode abortar a operação ao clicar no botão “cancelar”.
Fonte: Elaborada pelos autores, 2013
Quadro 9 - Detalhamento de Caso de Uso 007
CASO DE USO 007: Gerar Relatório Analítico
Descrição
Demonstra os valores lançados dentro de cada categoria em determinado mês;
Ator(es)
Usuário
Pré-condições
Fluxo Principal
Fluxos Alternativos e
exceções
O ator está autenticado no cliente WEB e está na tela de solicitação de relatório
(TEL007)
1. O usuário informa o mês e o tipo de período do qual desejar ver o relatório;
2. O sistema captura os lançamentos realizados dentro do período;
3. O sistema divide os lançamentos em categorias;
4. O sistema agrupa as categorias por grupo e natureza;
5. O sistema soma os valores de cada agrupamento;
6. O sistema exibe o relatório de movimentações;
No item 2 e 5, caso o período escolhido pelo usuário seja “Vencimento”, os
lançamentos são capturados com base no vencimento de suas parcelas, não na
competência, e a soma é realizada com base no percentual do total das parcelas com
vencimento para aquele mês.
Fonte: Elaborada pelos autores, 2013
97
Quadro 10 - Detalhamento de Caso de Uso 008
CASO DE USO 009: Sincronização
Descrição
Ação que dispara os eventos de sincronização do dispositivo mobile
Ator(es)
Usuário
Pré-condições
O ator está no cliente mobile, na tela de sincronização (TEL008)
Fluxo Principal
1.
2.
3.
4.
5.
O usuário clica em “Sincronizar”;
O usuário fornece os dados de login;
O sistema efetua o login na API;
O sistema envia os lançamentos para registro na API, um a um.
O sistema solicita a listagem das contas, com saldos, para a API, e as grava no
banco.
6. O sistema solicita a listagem das contas, com saldos, para a API, e as grava no
banco.
7. O sistema solicita a listagem dos centros de custo para a API, e a grava no banco.
8. O sistema solicita a listagem das categorias para a API, e as grava no banco.
9. O sistema solicita os saldos mensais para a API, e grava no banco.
10. O sistema desconecta da API.
11. O sistema informa que a sincronização foi realizada e fecha a janela;
Fluxos Alternativos e
exceções
No item 4, quando a API informa que o cadastro foi realizado:
4.1 – O sistema apaga o lançamento do banco de dados;
No item 11, caso ocorra algum problema de sincronização:
11.1 – O sistema informa que não foi possível realizar a sincronização por completo e
informa o erro;
Fonte: Elaborada pelos autores, 2013
Quadro 11 - Detalhamento de Caso de Uso 010
CASO DE USO 010: Insere Lançamento (Mobile)
Descrição
Cadastra um lançamento no aplicativo mobile
Ator(es)
Usuário
Pré-condições
O ator está no cliente mobile, na tela de saldos (TEL009)
Fluxo Principal
12.
13.
14.
15.
16.
17.
18.
Fluxos Alternativos e
exceções
No item 5, caso algumas informação esteja incorreta:
5.1 – O sistema exibe uma mensagem mostrando qual informação está incorreta;
O usuário clica em “Novo Lançamento”;
O usuário escolhe a natureza do lançamento;
O sistema abre a janela “Modal” de “Novo Lançamento”;
O usuário informa os dados do lançamento;
O usuário clica em “Salvar”;
O sistema “serializa” as informações e salva no banco;
O sistema informa que o Lançamento foi salvo e fecha a janela;
A qualquer momento o usuário pode abortar a operação ao clicar no botão “cancelar”.
Fonte: Elaborada pelos autores, 2013
98
APÊNDICE C – Diagramas de Sequência
Figura 42 - Diagrama de Sequencia UC002
Fonte: Elaborada pelos autores, 2014
99
Figura 43 - Diagrama de Sequência UC004
Fonte: Elaborada pelos autores, 2014
100
Figura 44 - Diagrama de Sequência UC005
Fonte: Elaborada pelos autores, 2014
101
Figura 45 - Diagrama de Sequência UC002
Fonte: Elaborada pelos autores, 2014
102
Figura 46 - Diagrama de Sequência UC007
Fonte: Elaborada pelos autores, 2014
103
Figura 47 - Diagrama de Sequência UC008
Fonte: Elaborada pelos autores, 2014
104
Figura 48 - Diagrama de Sequência UC009
Fonte: Elaborada pelos autores, 2014
105
APÊNDICE D – Telas
Tabela 12 - Detalhamento de Telas
TELAS
Código
TEL001
TEL002
TEL003
TEL004
TEL005
TEL006
TEL007
TEL008
TEL009
TEL010
TEL011
Nome
Login
Gerenciar Lançamento
Nova Transferência
Extrato
Listagem de Lançamento
Pagar Parcela
Relatório Analítico
Sincronização
Relação de Saldos (Mobile)
Visão Geral
Gerenciar Taxonomia
Fonte: Elaborada pelos autores, 2013
106
APÊNDICE E – Casos de Teste
Quadro 13 - CT001
CASO DE TESTE 001: Cadastrar Taxonomia
Descrição
Efetuar o cadastro de uma taxonomia (O processo se repete para Centro de Custo, Conta e Categoria)
#
Ação
Resultado Esperado
01
Clicar sobre o botão “Configuração”
02
Clicar sobre a taxonomia desejada
03
Preencher o formulário com dados
válidos
04
Clicar no botão “Adicionar”
O sistema deve abrir a janela com as opções de
configuração do sistema
Será aberta a janela modal da taxonomia, onde todos os
itens serão listados
Caso o usuário não preencha um dado válido, o sistema
sinalizará pintando o campo de vermelho e desabilitando o
botão cadastrar
O sistema irá cadastrar a taxonomia no banco, apagar os
dados do formulário e atualizar a listagem de itens.
Fonte: Elaborada pelos autores, 2013
Quadro 14 - CT002
CASO DE TESTE 002: Editar Taxonomia
Descrição
Editar o cadastro de uma taxonomia (O processo se repete para Centro de Custo, Conta e Categoria)
#
Ação
Resultado Esperado
01
Clicar sobre o botão “Configuração”
02
Clicar sobre a taxonomia desejada
03
Clicar no botão editar sobre o item que
se deseja atualizar
Atualizar o formulário com dados
válidos
O sistema deve abrir a janela com as opções de
configuração do sistema
Será aberta a janela modal da taxonomia, onde todos os
itens serão listados
O sistema irá atualizar o formulário com os dados de
edição
Caso o usuário não preencha um dado válido, o sistema
sinalizará pintando o campo de vermelho e desabilitando o
botão atualizar
O sistema irá atualizar a taxonomia no banco, apagar os
dados do formulário e atualizar a listagem de itens.
04
05
Clicar no botão “Adicionar”
Fonte: Elaborada pelos autores, 2013
107
Quadro 15 - CT003
CASO DE TESTE 003: Remover Taxonomia
#
Remover o cadastro de uma taxonomia desde que a mesma não possua registros associados a ela. (O
processo se repete para Centro de Custo, Conta e Categoria)
Ação
Resultado Esperado
01
Clicar sobre o botão “Configuração”
02
Clicar sobre a taxonomia desejada
03
Clicar no botão “Excluir” sobre o item
que se deseja remover
Confirmar exclusão
Descrição
04
O sistema deve abrir a janela com as opções de
configuração do sistema
Será aberta a janela modal da taxonomia, onde todos os
itens serão listados
O sistema irá solicitar a confirmação para a exclusão
O sistema irá validar se o item possui algum
relacionamento. Caso possua, alertará o usuário que não
foi possível efetuar a exclusão. Caso não possua, irá avisar
o usuário que o item foi removido e irá atualizar a
listagem.
Fonte: Elaborada pelos autores, 2013
Quadro 16 - CT004
CASO DE TESTE 004: Inserir Lançamento
Descrição
Efetuar o cadastro de um lançamento
#
Ação
Resultado Esperado
01
Clicar sobre o botão “Novo”
02
Escolher uma natureza
03
Preencher o formulário com dados
válidos
04
Clicar no botão “Adicionar”
O sistema deve abrir a janela com as opções de natureza de
lançamento
O sistema irá abrir a janela modal de cadastro de
lançamento
Caso o usuário não preencha um dado válido, o sistema
sinalizará pintando o campo de vermelho e desabilitando o
botão cadastrar
O sistema irá cadastrar o lançamento no sistema e irá
fechar a tela de cadastro.
Fonte: Elaborada pelos autores, 2013
Quadro 17 - CT005
CASO DE TESTE 005: Efetuar Transferência
Descrição
Efetuar o cadastro de uma transferência
#
Ação
Resultado Esperado
01
Clicar sobre o botão “Novo”
02
Clicar em “Transferência”
03
Preencher o formulário com dados
válidos
04
Clicar no botão “Adicionar”
O sistema deve abrir a janela com as opções de cadastro de
movimentação
O sistema irá abrir a janela modal de cadastro de
transferência
Caso o usuário não preencha um dado válido, o sistema
sinalizará pintando o campo de vermelho e desabilitando o
botão cadastrar
O sistema irá cadastrar a transferência no sistema e irá
fechar a tela de cadastro.
Fonte: Elaborada pelos autores, 2013
108
Quadro 18 - CT006
CASO DE TESTE 006: Pagar parcela de lançamento
Descrição
Efetuar o pagamento de uma parcela de lançamento.
#
Ação
Resultado Esperado
01
Clicar sobre o botão “Relatórios”
O sistema deve abrir a janela com as opções de relatórios
02
Clicar em “Lançamentos”
O sistema irá abrir a janela com os lançamentos
03
Clicar sobre o botão “Pagar” da parcela
desejada
Preencher o formulário com dados
válidos
O sistema irá abrir a tela de pagamento
04
05
Clicar no botão “Pagar”
Caso o usuário não preencha um dado válido, o sistema
sinalizará pintando o campo de vermelho e desabilitando o
botão cadastrar
O sistema irá cadastrar o pagamento no sistema, fechará a
tela de cadastro e atualizará a listagem de lançamentos.
Fonte: Elaborada pelos autores, 2013
Quadro 19 - CT007
CASO DE TESTE 007: Gerar Extrato
Descrição
Gerar o Extrato de uma conta cadastrada no sistema
#
Ação
Resultado Esperado
01
Clicar sobre o botão “Relatórios”
O sistema deve abrir a janela com as opções de relatórios
02
Clicar em “Extrato”
O sistema irá abrir a janela de extrato
03
Preencher o formulário com dados
válidos
04
Clicar no botão “Gerar”
Caso o usuário não preencha um dado válido, o sistema
sinalizará pintando o campo de vermelho e desabilitando o
botão “Gerar”
O sistema irá buscar os lançamentos e transferência dentro
do período escolhido e irá listar na tela.
Fonte: Elaborada pelos autores, 2013
Quadro 20 - CT008
CASO DE TESTE 008: Gerar Relatório Analítico
Descrição
Gerar o Relatório Analítico do Mês escolhido
#
Ação
Resultado Esperado
01
Clicar sobre o botão “Relatórios”
O sistema deve abrir a janela com as opções de relatórios
02
Clicar em “Analítico”
O sistema irá abrir a janela de relatório
03
Preencher o formulário com dados
válidos
04
Clicar no botão “Gerar”
Caso o usuário não preencha um dado válido, o sistema
sinalizará pintando o campo de vermelho e desabilitando o
botão “Gerar”
O sistema irá buscar os lançamentos dentro do período
escolhido e irá listar na tela, de forma analítica, agrupado
por categoria
Fonte: Elaborada pelos autores, 2013
109
Quadro 21 - CT009
CASO DE TESTE 009: Inserir Lançamento (Mobile)
Descrição
Inserir um lançamento no dispositivo Mobile
#
Ação
Resultado Esperado
01
Clicar sobre o botão “Novo”
02
Escolher uma natureza
O sistema deve abrir a janela com as opções de natureza de
lançamento
O sistema irá abrir a janela de cadastro de lançamento
03
Preencher o formulário com dados
válidos
04
Clicar no botão “Adicionar”
Caso o usuário não preencha um dado válido, o sistema
sinalizará pintando o campo de vermelho e desabilitando o
botão cadastrar
O sistema irá cadastrar o lançamento no sistema e irá
fechar a tela de cadastro.
Fonte: Elaborada pelos autores, 2013
Quadro 22 - CT010
CASO DE TESTE 010: Sincronizar
Descrição
Sincronizar cadastros do dispositivo com o servidor REST
#
Ação
Resultado Esperado
01
Clicar sobre o botão “Configuração”
02
Clicar em “Sincronizar”
O sistema deve abrir a janela com as opções de
configuração
O sistema irá abrir a janela de log de sincronização,
efetuando os cadastros no servidor REST e recolhendo as
listagens de taxonomia. Após isso, deverá informar o
resultado da operação para o usuário.
Fonte: Elaborada pelos autores, 2013