Relatório Final PI

INSTITUTO FEDERAL DE SANTA CATARINA
Priscila Graziele Busnello de Araújo
DESENVOLVIMENTO DE UM SISTEMA DE ADMINISTRAÇÃO FINANCEIRA

PARA MICRO E PEQUENAS EMPRESAS
Gaspar
2017
Priscila Graziele Busnello de Araújo
DESENVOLVIMENTO DE UM SISTEMA DE ADMINISTRAÇÃO FINANCEIRA

PARA MICRO E PEQUENAS EMPRESAS
Relatório apresentado a disciplina de Projeto Integrador do Curso Técnico

em Informática Integrado ao Ensino Médio como requisito para avaliação da
disciplina.
Orientador: Alexandre Altair de Melo.
Gaspar
2017
RESUMO
As micro e pequenas empresas vem crescendo no cenário econômico nacional,

mas muitas delas não são tecnologicamente equipadas, por diversos motivos,
dificultando algumas de suas atividades. Isso acontece com uma empresa localizada
na área próxima ao Instituto Federal de Santa Catarina – Câmpus Gaspar, a JMS
Tornotécnica, que tem um controle financeiro manual, por isso criou-se um mecanismo
que atenda as necessidades da empresa para fazer um controle financeiro melhor e
computadorizado, com melhor armazenamento de dados e maior eficácia. Para atingir
esse objetivo foram realizadas pesquisas sobre softwares da área financeira para
entender quais são as funcionalidades mais recorrentes nesses softwares, como eles
funcionam e se existem similares. Também foram feitas pesquisas sobre como
programar um software da melhor e mais eficaz maneira que venha a atender o
planejado. Em adição, a isso foram realizadas entrevistas com os administradores da
empresa para compreender quais são as suas necessidades e implementá-las no
software. Este foi implementado com as funcionalidades definidas pela empresa,
entretanto ainda há melhorias que podem ser feitas nele para que haja um melhor
controle financeiro.
Palavras-Chave: Controle financeiro. Micro e pequenas empresas. Administração.

Administração financeira. Desenvolvimento de software.
LISTA DE FIGURAS
Figura 1: Fases do RUP ............................................................................................ 19

Figura 2: Diagrama de casos de uso ......................................................................... 33
Figura 3: Diagrama de classes (Parte 1) ................................................................... 44
Figura 4: Diagrama de classes (Parte 2) ................................................................... 45
Figura 5: Diagrama de sequência do CSU01 ............................................................ 46
Figura 10: Diagrama de sequência do CSU07 .......................................................... 51
Figura 11: Diagrama ER ............................................................................................ 52
Figura 12: Cronograma da primeira fase do projeto .................................................. 53
Figura 13: Cronograma da segunda fase do projeto ................................................. 54
Figura 14: Telas de cadastro, alteração e acesso do usuário .................................... 55
Figura 15: Tela inicial do sistema .............................................................................. 56
Figura 16: Tela de cadastro e busca de clientes ....................................................... 57
Figura 17: Tela de detalhes de clientes ..................................................................... 58
Figura 18: Tela de cadastro de contas a pagar ......................................................... 58
Figura 19: Telas de busca e de detalhes de contas a pagar ..................................... 59
Figura 20: Tela de cadastro de pagamento de contas ............................................... 60
Figura 21: Relatório de contas a pagar ..................................................................... 61
Figura 22: Código do teste de cadastro de usuários ................................................. 62
Figura 23: Resultado do teste de cadastro de usuário com JUnit ............................. 62
LISTA DE QUADROS
Quadro 1: Softwares de gestão disponíveis no mercado .......................................... 10

Quadro 2: Funções da administração financeira ....................................................... 13
Quadro 3: Requisitos funcionais do sistema ............................................................. 31
Quadro 4: Requisitos não funcionais do sistema ...................................................... 32
Quadro 5: Cadastrar clientes (CSU01) ...................................................................... 34
Quadro 6: Cadastrar fornecedor (CSU02) ................................................................. 35
Quadro 7: Cadastrar contas a pagar (CSU03) .......................................................... 36
Quadro 8: Cadastrar contas a receber (CSU04) ....................................................... 38
Quadro 9: Cadastro de usuário (CSU05) .................................................................. 40
Quadro 10: Cadastro de pagamento de contas (CSU06) .......................................... 40
Quadro 11: Relatório financeiro (CSU07) .................................................................. 42
Quadro 12: Relatório financeiro (CSU08) .................................................................. 42
LISTA DE ABREVIATURAS E SIGLAS
API – Interface de programação de aplicações (do inglês, Application Programming

Interfaces).
ERP – Sistema de Gestão Empresarial (do inglês, Enterprise Resource Planning).
IFSC – Instituto Federal de Santa Catarina.
JVM – Máquina Virtual Java (do inglês, Java Virtual Machine).
MCU – Modelos de Casos de Uso.
SEBRAE – Serviço Brasileiro de Apoio às Micro e Pequenas Empresas.
SGBD – Sistema Gerenciador de Banco de Dados (do inglês, DataBase
Management System (DBMS)).
SQL – Linguagem Estrutural de Consulta (do inglês, Structure Query Language).
UML – Linguagem Unificada de Modelagem (do inglês, Unified Modeling Language).
RUP – Processo Racional Unificado (do inglês, Rational Unified Process).
SUMÁRIO
1 INTRODUÇÃO ......................................................................................................... 8
1.1 OBJETIVOS .................................................................................................... 10
1.1.2 Objetivos específicos ............................................................................... 10
1.2 JUSTIFICATIVA............................................................................................... 11
2 FUNDAMENTAÇÃO TEÓRICA .............................................................................. 12
2.1 ADMINISTRAÇÃO EMPRESARIAL ................................................................ 12
2.2 ADMINISTRAÇÃO FINANCEIRA .................................................................... 13
2.3 SISTEMA DE INFORMAÇÃO ......................................................................... 14
2.3.1 Sistemas para empresas ......................................................................... 15
2.3.1.1 Os benefícios de sistemas ERP ....................................................... 15
2.3.2 Sistemas financeiros para empresas ....................................................... 16
2.4 DESENVOLVIMENTO DE SOFTWARE.......................................................... 16
2.4.1 Metodologias de desenvolvimento ........................................................... 16
2.4.1.1 RUP .................................................................................................. 17
2.5 DIAGRAMAS DE MODELAGEM .................................................................... 19
2.5.1 UML ......................................................................................................... 19
2.5.1.1 Diagramas da UML ........................................................................... 20
2.5.1.1.1 Diagrama de casos de uso ........................................................ 21
2.5.1.1.2 Diagrama de classes ................................................................. 22
2.5.1.1.3 Diagrama de sequência ............................................................. 23
2.6 ORIENTAÇÃO A OBJETOS ............................................................................ 24
2.6.1 Programação Orientada a Objetos (POO) ............................................... 24
2.6.1.1 Java ...................................................................................................... 25
2.7 BANCO DE DADOS ........................................................................................ 26
2.7.1 Sistema Gerenciador de Banco de Dados (SGBD) ................................. 27
2.7.2 MySQL ..................................................................................................... 28
2.7.3 SQL .......................................................................................................... 28
2.7.4 Modelagem de dados (DER).................................................................... 29
2.7.4.1 Identificando uma entidade ............................................................... 29
2.8 Testes .............................................................................................................. 30
3 METODOLOGIA DA PESQUISA ............................................................................ 31
3.1 DESCRIÇÃO DA SOLUÇÃO PROPOSTA ...................................................... 31
22
3.2 REQUISITOS DO SISTEMAS ......................................................................... 31

3.2.1 Requisitos funcionais ............................................................................... 31
3.2.2 Requisitos não funcionais ........................................................................ 32
3.3 DIAGRAMA DE CASOS DE USO ................................................................... 33
3.4 DIAGRAMA DE CLASSES .............................................................................. 43
3.5 DIAGRAMA DE SEQUÊNCIA ......................................................................... 45
3.6 MODELO DO BANCO DE DADOS ................................................................. 51
4 RESULTADOS ESPERADOS ................................................................................ 53
4.1 ANDAMENTO DO PROJETO E PRÓXIMAS ETAPAS.................................... 53
4.2 Detalhamento das etapas realizadas .............................................................. 54
4.2.1 Etapa I: Implementação do banco de dados ............................................ 54
4.2.2 Etapa II: Implementação da classe usuário ............................................. 54
4.2.3 Etapas III e IV: Implementação das classes do cliente e do fornecedor .. 56
4.2.4 Etapas V e VI: Implementação das classes das contas ........................... 58
4.2.5 Etapa VII: Implementação da classe de pagamento de contas ............... 59
4.2.6 Etapa VIII: Relatórios ............................................................................... 60
4.2.7 Etapa VIII: Realização de testes .............................................................. 61
4.2.7 Etapa IX: Validação com o usuário .......................................................... 62
REFERÊNCIAS ......................................................................................................... 65
8
1 INTRODUÇÃO
Segundo Bio e Cornachione Júnior (2008, p. 22), um sistema de informações

(SI) é “[...] uma rede de subsistemas, em que cada qual se decompõe em
procedimentos que coletam dados, os processam, e produzem e distribuem as
informações resultantes. [...]”. Para exemplificar melhor esse conceito, pense em uma
transação bancária de uma empresa em um software de controle financeiro. Será
necessário retirar ou adicionar dinheiro a conta bancária da empresa, gerando ao final
dessa transação, uma nova informação, que é o saldo final dessa.
As informações são de extrema importância para a devida administração de
uma empresa e com os sistemas de informações a obtenção ou formação dessas
tornou-se algo mais prático e rápido (BIO; CORNACHIONE JÚNIOR, 2008).
O processo de administração de uma empresa é crucial para seu
funcionamento, pois esse processo é o responsável pelo planejamento e execução
das atividades do negócio. Cabe a esse processo e os envolvidos neste, a forma de
como lidar com situações que acontecem no dia a dia da empresa visando a resolução
de problemas, sua expansão e lucro.
Sendo a administração tão importante para as empresas, criaram-se
ferramentas para aprimorar, facilitar e acelerar essa administração, ferramentas como
o sistema ERP (Enterprise Resource Planning, em português, Planejamento dos
Recursos da Empresa), um sistema de informações integrado (SOUZA; ZWICKER,
2000).
A partir de análises desses sistemas criou-se um software de administração
financeira acessível a microempresas, levando em conta que a maioria dos softwares
do mercado tem um elevado custo e dificultam a utilização por micro e pequenas
empresas que estão no mercado.
Segundo Brasil ([2014]), há diversos conceitos para definição do que seria uma
micro ou pequena empresa, um deles é o da legislação nacional, onde afirma que o
porte da empresa é definido a partir do faturamento anual dessa. Já o Instituto
Brasileiro de Geografia e Estatística (IBGE) e o Serviço Brasileiro de Apoio às Micro e
Pequenas Empresas (SEBRAE) utilizam o faturamento anual da empresa e a
quantidade de empregos que ela gera como critérios para definir o seu porte (BRASIL,
[2014]).
9
As micro e pequenas empresas estão crescendo cada vez mais no cenário

econômico brasileiro. Segundo dados do SEBRAE (2014), a produção dessas
empresas geraram, em 2011, cerca de 27% do Produto Interno Bruto (PIB), são cerca
de 599 milhões de reais, mostrando um crescimento significativo, em relação a 2001
que gerou 144 milhões de reais.
Outros dados apontados pelo SEBRAE sobre essas 8,9 milhões empresas
brasileiras foi que elas são responsáveis por:
• 52% dos empregos com carteira assinada;

• 40% dos salários pagos.
Dado esse cenário aonde no Brasil existem muitas micro e pequenas empresas,
essas demandam formas que permitam manter sua operação em funcionamento. E
uma maneira de contribuir para isso é através da automação de seus processos.
Dessa forma neste projeto desenvolveu-se um sistema financeiro (contas a pagar e
receber) que auxiliará a empresa JMS Tornotécnica na sua gestão financeira, visando
automatizar este processo que hoje ocorre por meio manual e com a utilização de
planilhas.
Para entender a aplicabilidade de um software de gestão no controle financeiro
de uma micro e pequena empresa que visa substituir seus processos manuais e
entender os possíveis benefícios que esse tipo de sistema pode trazer a administração
de tal organização, buscou-se fazer uma pesquisa no mercado para listar possíveis
soluções para essa demanda. O Quadro 1 a seguir apresenta alguns exemplos
disponíveis no mercado e que foi resultado dessa pesquisa. A escolha destes
softwares baseou-se no critério de gratuidade ou preço abaixo da faixa de R$ 100,00
(cem reais) por licença mensal.
Quadro 1: Softwares de gestão disponíveis no mercado
Nome do software Pago ou grátis Site

10
eGestor Pago https://www.egestor.com.br/
CashPreview Grátis http://www.cashpreview.com.br/cashprev

iew.htm
ContaAzul Pago https://contaazul.com/
QuickBooks ZeroPaper Grátis https://www.quickbooks.com.br/
Controlle Grátis https://controlle.com/
Fonte: produção da autora, 2017
Ao concluir-se as pesquisas dos softwares acima mostrados, percebeu-se que

os pagos têm todas as funcionalidades que seriam necessárias para o sistema e
outras como emissão de notas fiscais, controle de estoque e emissão de boletos.
Enquanto isso, alguns softwares também tem suas funcionalidades básicas grátis,
mas outras, que também são necessárias, devem ser adquiridas através de licenças.
1.1 OBJETIVOS
Desenvolver um software de administração financeira para uma microempresa,

para automatizar o processo financeiro (contas a pagar e receber) dessa.
1.1.2 Objetivos específicos
• Criar o cadastro de clientes para controlar o público atendido pela empresa;

• Criar o cadastro de fornecedores para controlar quem são os fornecedores da
empresa;
• Criar relatórios das transações financeiras da empresa.
1.2 JUSTIFICATIVA
O projeto se justifica pois apesar de existirem vários sistemas para

administração financeira no mercado muitos deles são pagos ou tem algumas
funcionalidades necessárias que são pagas também. Devido a isso as micro e
11
pequenas empresas, muitas vezes, optam por não adquirir esses serviços para evitar
mais gastos, já que não tem um lucro tão abrangente.
A solução encontrada foi criar um sistema de gestão financeira que abrangesse
as maiores necessidades de uma micro e pequena empresa para que possa ser
redistribuído posteriormente sem nenhum custo possibilitando que essas empresas
consigam automatizar e melhorar esse processo ao utilizá-lo.
12
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo é abordada toda a teoria dos assuntos e tecnologias que foram
utilizados para desenvolver este projeto.
2.1 ADMINISTRAÇÃO EMPRESARIAL
Segundo Chiavenato (2014, p. 2) a administração é:
A condução racional e estratégica das atividades de uma organização, seja

ela lucrativa ou não lucrativa. A Administração trata do planejamento, da
organização (estruturação), da direção e do controle de todas as atividades
diferenciadas pela divisão de trabalho que ocorrem dentro de uma
organização.
O autor comenta também que vivemos em uma sociedade de organizações,

que a vida das pessoas dependem das organizações assim como as organizações
dependem das pessoas. Já que dependemos dessas organizações, elas precisam ser
administradas para que possam continuar com seus serviços. Para que elas possam
fazer isso é necessário que elas sejam bem administradas.
2.1.1 O administrador
Segundo Chiavenato (2014, p.2) o administrador é “um gerador de riqueza, seja

material, financeira ou intelectual.”. Adiciona que o administrador tem como funções
dentro da organização o desenvolvimento de estratégias, definição de missões,
estabelecimento de objetivos e metas, dimensionamento de recursos, planejamento
de sua aplicação, efetuação de diagnósticos, solucionamento de problemas,
impulsionamento de inovações, aplicação e gerenciamento do conhecimento, criação
de valor.
Chiavenato (2014) complementa dizendo que mesmo que um administrador
seja bem-sucedido em uma empresa, ele não será necessariamente bem-sucedido
em outra. Por isso que as organizações têm um cuidado extremo na seleção de um
administrador apropriado, pois ele não será selecionado apenas a partir do seu
currículo, mas sim por suas atitudes, modo de agira, espírito empreendedor, liderança
e filosofia de trabalho.
Chiavenato (2014) mostra que não há apenas uma maneira correta de um
administrador agir ou de conduzir diante das situações pela qual passa, mas sim
13
várias, sendo possível fazer coisas totalmente diferentes e chegar ao mesmo

resultado ao final.
2.2 ADMINISTRAÇÃO FINANCEIRA
Focando na parte financeira da administração de uma empresa, pesquisou-se

sobre e de acordo com Lemes Júnior, Rigo e Cherobim (2010, p. 5) o objetivo da
administração financeira é “maximizar a riqueza da empresa”. A função do
administrador financeiro, responsável por essa parte da administração da empresa,
está dividida em duas áreas: a gerência financeira e a controladoria.
Quadro 2: Funções da administração financeira
GERÊNCIA FINANCEIRA CONTROLADORIA
• Administração de caixa • Administração de custos e preços

• Administração de crédito e • Auditoria interna
cobrança • Avaliação de desempenho
• Administração do risco • Contabilidade
• Administração de câmbio • Orçamento
• Decisão de financiamento • Patrimônio
• Decisão de investimentos • Planejamento tributário
• Planejamento e controle • Relatórios gerenciais
financeiros • Sistemas de informação financeira
• Relações com acionistas e
investidores
• Relações com bancos
Fonte: LEMES JÚNIOR; RIGO; CHEROBIM, 2010, p.6.
Segundo Lemes Júnior, Rigo e Cherobim (2010), além disso o administrador

tem que tomar três decisões fundamentais, que são: a decisão de investimento,
decisão de financiamento e decisão de resultados e procurar responder três questões
fundamentais, que são:
• Quais investimentos de longo prazo deve fazer?

14
• Onde conseguirá os financiamentos necessários para viabilizar esses

investimentos?
• Como obterá resultados que atendam às exigências dos acionistas?
Os autores complementam dizendo que o administrador financeiro contribuirá

para o sucesso da organização ao dar respostas adequadas para essas questões,
sempre buscando a maximização dos lucros gerados pela empresa.
2.3 SISTEMA DE INFORMAÇÃO
As informações são de grande importância no mundo administrativo pois são

como elas que mostram como a empresa deve ser administrada gerando a maior
quantidade de lucro possível, no caso de empresas privadas. Já as empresas
governamentais ou sem fins lucrativos tendem a utilizar informações para reduzir seus
custos e aumentar a eficiência.
É importante também entender a diferença entre dado e informação, que é
definida por Rosini e Palmisano (2012, p.8):
Dados são as representações originais e detalhadas de eventos no mundo

físico. Para que os dados se tornem úteis na tomada de decisão eles
precisam ser tratados, isto é, transformados em informações. Informações
são, portanto, dados trabalhados de modo que sejam úteis. O administrador,
o gerente, o empresário usam informações, e não dados.
Segundo Bio e Cornachione Júnior (2008), o sistema de informação é um

subsistema do “sistema empresa” e pode conter vários subsistemas interdependentes
que trocam informações entre si. Citando o exemplo da introdução, na transação
bancária de uma empresa contém informações do subsistema de faturamento, mas
essas informações precisam constar no subsistema de contabilidade, assim como o
subsistema de contas a receber. Pode-se perceber então a necessidade de troca de
informações entre esses subsistemas.
Ainda segundo Bio e Cornachione Júnior (2008), esse nível de integração entre
os sistemas só é possível graças ao computador e atualmente é possível encontrar
os pacotes de sistemas ERPs que atendem as necessidades gerais da empresa
(marketing/vendas, produção, logística, controladoria e finanças etc.).
15
2.3.1 Sistemas para empresas
Os sistemas de informações evoluem cada vez mais e tem como tendência

natural a integração dos processos organizacionais, de maneira que atendam a
empresa como um todo (ROSINI, PALMISANO, 2012).
Os sistemas Enterprise Resourse Planning (ERP) tem como objetivo a
integração do escritório e fábrica, ou seja, uma integração de toda a empresa. Para
isso usa a abordagem best practices, as melhores práticas de administração de
negócios existentes. É importante ressaltar que o sistema ERP também tem suas
restrições e que ele funciona melhor em atividades padronizadas e rotineiras do que
nas que são exigidas mais competências humanas e processos de tomadas de
decisões estratégicas (ROSINI, PALMISANO, 2012).
O sistema ERP começou a ser desenvolvido como um software de
padronização e controle de estoques, gestão financeira, planejamento de recursos e
necessidades de materiais, mas foi expandido e incluiu outros processos como
vendas e distribuição, marketing, compras, controle de custos, entre outros (SCHEER,
2000 apud ROSINI; PALMISANO, 2012).
2.3.1.1 Os benefícios de sistemas ERP
Os benefícios dos sistemas ERP podem ser classificados em quatro categorias:
• Primeira: geração de informações que apoiam a gestão, o que inclui:
◦ O aumento de fluxo de informações entre os subsistemas da empresa;

◦ A padronização, facilidade de integração e melhoria de coordenação;
◦ A consolidação de resultados e resolução de inconsistências de
informações entre as unidades da empresa;
◦ A redução de custos administrativos no compartilhamento das informações;
e
◦ A disponibilização da informação mais rapidamente.
• Segunda: a padronização e integração das unidades da empresa.

16
• Terceira: redução de custos na manutenção dos sistemas de informações e

aumento de disponibilidade para a criação de funcionalidades.
• Quarta: como instrumental de posicionamento da empresa na adoção de
melhores práticas de negócio da área em que a empresa está inserida.
Os sistemas ERP possuem diversas vantagens para uma empresa, já que

melhora a organização, reduz gastos, entre outros, o que faz com que essas empresas
estejam a frente de seus competidores que não utilizam esse sistema.
2.3.2 Sistemas financeiros para empresas
Anteriormente foram citados alguns sistemas financeiros para empresas que

foram encontrados durante pesquisas. Eles têm, basicamente, as mesmas
funcionalidades, mas alguns disponibilizam ferramentas adicionais pagas. De maneira
geral, suas funcionalidades são similares pois são programas da mesma área, porém
é perceptível a diferença de interface, por exemplo, dos programas pagos e dos grátis.
2.4 DESENVOLVIMENTO DE SOFTWARE
Projetos de software podem adotar metodologias de desenvolvimento para sua

construção e a literatura cita vários modelos para tal finalidade. Nas seções a seguir
é explicado o conceito de metodologia de desenvolvimento de software e a
metodologia adotada neste trabalho.
2.4.1 Metodologias de desenvolvimento
De acordo com Soares ([201?]) a metodologia de desenvolvimento de software
é um conjunto de atividades e resultados associados que auxiliam na

produção de software. Dentre as várias atividades associadas, existem por
exemplo a análise de requisitos e a codificação. O resultado do processo é
um produto que reflete a forma como o processo foi conduzido (SOARES,
([201?], não paginado)
17
Para o desenvolvimento do software será utilizado o Processo Racional

Unificado (do inglês, Rational Unified Process) ou RUP, que será abordado nesta
seção.
2.4.1.1 RUP
De acordo com Booch, Rumbaugh e Jacobson (2012, p. 487) na engenharia de

software, a meta é “entregar, de maneira efieciente e previsível, um produto de
software capaz de atender às necessidades de seu negócio” e para isso acontecer é
necessário seguir um processo constituído de diversos passos.
O Processo Racional Unificado (RUP) aborda esse processo de maneira
adequada à UML e sua meta é permitir o desenvolvimento de softwares da mais alta
qualidade que cumpra com os requisitos do usuário e mantenha-se de acordo com o
planejamento e orçamentos previsíveis (BOOCH; RUMBAUGH; JACOBSON, 2012).
O RUP é um processo iterativo que “requer uma compreensão crescente do
problema por meio de aperfeiçoamentos sucessivos e do desenvolvimento
incremental de uma solução efetiva em vários ciclos” (BOOCH; RUMBAUGH;
JACOBSON, 2012, p.487). Além disso, também é um processo flexível pois permite a
adição de novos requisitos ou de mudanças de alguns objetivos. Em adição permite
que o projeto encontre e erradique riscos no início dele, o que é um grande benefício
desse processo.
Segundo Booch, Rumbaugh e Jacobson (2012), o RUP tem quatro fases,
sendo essas:
• Concepção: é estabelecida a visão para o sistema e a delimitação do escopo

do projeto. Essa fase inclui o caso de negócio, requisitos de alto nível e o plano
de projeto inicial e é comum a criação de um protótipo executável como teste.
Ao final da concepção são examinados os objetivos do ciclo de vida do projeto
e se ele deve ser continuado ou não.
• Elaboração: é feita a análise do domínio do problema, o estabelecimento da
fundação de uma arquitetura sólida, o desenvolvimento do plano do projeto e a
eliminação dos elementos de mais alto risco do projeto.
18
No final desta fase, é examinado o escopo e os objetivos detalhados do sistema,

a escolha de arquitetura e a solução para os principais riscos encontrados durante ela.
Em adição a isso, deve ser decidido se o projeto terá continuidade.
• Construção: esta fase consiste no desenvolvimento, de forma iterativa e
incremental, do produto completo. E ao final dela é decidido se o software,
ambientes e usuários estão prontos para se tornarem operacionais.
• Transição: nesta fase o software é disponibilizado aos usuários, lembrando que
houve uma interação prévia com a comunidade de usuários por meios de
demonstrações, workshops e versões alfa e beta. Geralmente, após o
lançamento para os usuários existem alguns ajustes adicionais que devem ser
feitos.
Ao final desta fase é decidido se os objetivos do ciclo de vida do projeto foram
atingidos e determinar se haverá outro ciclo de desenvolvimento. Em adição a isso,
esse é um momento em que as lições aprendidas durante o desenvolvimento do
projeto devem ser assimiladas para aprimorar o desenvolvimento do próximo projeto.
Para melhor compreensão, mostra-se na figura 1 o ciclo de vida do

desenvolvimento de um software.
19
Fonte: UERJ, 2015
2.5 DIAGRAMAS DE MODELAGEM
Nesta seção são mostrados os diagramas de modelagem que foram

necessários para o desenvolvimento do software, além da teoria acerca desse tópico.
2.5.1 UML
Booch, Rumbaugh e Jacobson (2012) dizem que você pode construir uma casa
para sua família simplesmente pegando algumas tábuas, pregos e outras ferramentas.
Entretanto, a probabilidade de que essa casa será do tamanho desejado, que não terá
nenhuma goteira ou qualquer outro problema de construção, será maior do que se
fosse ela fosse construída a partir de um projeto. O mesmo acontece com os softwares
que são construídos sem um modelo prévio, principalmente os mais complexos, pois
como eles abrangem diversos recursos dificultam uma visão geral e compreensão
deles.
20
Booch, Rumbaugh e Jacobson (2012) explicam que o modelo é uma

simplificação da realidade e é usado para alcançar quatro objetivos, sendo esses:
• A visualização do sistema como ele é ou como é desejado que seja;

• A especificação da estrutura ou o comportamento do sistema;
• A criação de um guia para a construção do sistema; e
• A documentação das decisões tomadas.
A partir disso, percebe-se que a modelagem de sistemas é essencial para a

criação de um sistema eficaz e efetivo que atenda os requisitos e necessidades do
cliente ou usuário e por isso criaram-se linguagens de modelagem.
Segundo Booch, Rumbaugh e Jacobson (2012, p.7) a Linguagem Unificada de
Modelagem (UML) é “uma linguagem gráfica para visualização, especificação,
construção e documentação de artefatos de sistemas complexos de software”. A UML
é essencial pois ela padroniza os projetos de sistema e dá uma preparação melhor
para a implementação do software como citado anteriormente.
A UML é usada para modelar sistemas orientados a objetos e para isso define
elementos gráficos que podem ser utilizados na modelagem de sistemas. Por meio
desses elementos pode-se construir diagramas que representam diversas
perspectivas de um sistema. Além disso, a UML não depende de linguagens de
programação nem de processos de desenvolvimento, ou seja, ela pode ser utilizada
para a modelagem de sistemas, não importando qual linguagem será utilizada, ou a
forma de desenvolvimento adotada (BEZERRA, 2015).
2.5.1.1 Diagramas da UML
Segundo Booch, Rumbaugh e Jacobson (2012) os diagramas são

apresentações gráficas de um conjunto de elementos e são feitos para permitir a
visualização de um sistema sob diversas perspectivas. A UML inclui 13 diagramas,
sendo eles:
• Diagrama de classes;
• Diagrama de objetos;
21
• Diagrama de componentes;
• Diagrama de estruturas compostas;
• Diagrama de casos de uso;
• Diagrama de sequências;
• Diagrama de comunicações;
• Diagrama de estados;
• Diagrama de atividades;
• Diagrama de implantação;
• Diagrama de pacote;
• Diagrama de temporização;
• Diagrama de visão geral da interação.
Para o desenvolvimento do presente projeto, foram utilizados apenas os

diagramas de caso de uso, classe e de sequência.
2.5.1.1.1 Diagrama de casos de uso
Segundo Bezerra (2015, p.53) o modelo de casos de uso (MCU) “é uma

representação das funcionalidades externamente observáveis do sistema e dos
elementos externos ao sistema que interagem com ele.” e o diagrama da UML
utilizado para essa modelagem é o diagrama de casos de uso.
Bezerra (2015) complementa dizendo que o MCU mostra as possibilidades de
uso de um sistema da forma como é percebido por um observador externo a este
sistema, sendo que cada um desses usos está associado a um ou mais requisitos
funcionais do sistema. Bezerra (2015) aponta que para a construção desse diagrama
são necessários componentes como:
• Casos de uso: o caso de uso é a especificação de uma sequência de interações

entre um sistema e um ou mais agentes externos a ele e representa um relato
do uso de certa funcionalidade do sistema sem revelar sua estrutura e seu
comportamento interno.
• Atores: para a UML, qualquer elemento externo ao sistema que tenha alguma
interação com ele, é denominado ator. Com “externo” quer dizer-se que o ator
22
não faz parte do sistema, mas interage com ele, ou seja, troca informações com
o sistema.
• Relacionamentos: serve para relacionar os casos de uso e os atores, ou eles
entre si. A UML ainda define quatro tipos de relacionamentos, sendo eles:
relacionamento de comunicação, inclusão, extensão e generalização.
2.5.1.1.2 Diagrama de classes
Segundo Booch, Rumbaugh e Jacobson (2012) os diagramas de classe são

destinados, principalmente, a modelagem de sistemas orientados a objetos. Ele
mostra um conjunto de classes, interfaces e colaborações e seus relacionamentos.
Complementa dizendo que os diagramas também são importantes para a construção
de sistemas executáveis por intermédio de engenharia direta e reversa e não apenas
para a visualização, a especificação e a documentação de modelos estruturais.
O diagrama de classes geralmente tem os seguintes itens:
• Classes;
• Interfaces; e
• Relacionamentos de dependência, generalização e associação.
Booch, Rumbaugh e Jacobson (2012) dizem que os diagramas de classes tem

alguns usos básicos como:
• Modelagem do vocabulário do sistema: usado para decidir quais abstrações

fazem parte do sistema e quais estão fora dos limites dele. Esse diagrama
especificará quais são essas abstrações e suas responsabilidades.
• Modelagem de colaborações simples: a colaboração é uma sociedade de
classes, interfaces e outros componentes que funcionam em conjunto para
proporcionar algum comportamento cooperativo. Esse diagrama deverá ser
usado para visualizar e especificar esse conjunto de classes e seus
relacionamentos.
23
• Modelagem do esquema lógico de um banco de dados: os bancos de dados

são essenciais para o armazenamento de dados e esse diagrama permite fazer
a modelagem de esquemas para esses bancos de dados.
2.5.1.1.3 Diagrama de sequência
Booch, Rumbaugh e Jacobson (2012) considera o diagrama de sequência

como um diagrama de interação e é utilizado para a modelagem dos aspectos
dinâmicos de sistemas.
Eles podem aparecer sozinhos para visualizar, especificar, construir e

documentar a dinâmica de uma determinada sociedade de objetos ou podem
ser utilizados para fazer a modelagem de um determinado fluxo de controle
de um caso de uso (BOOCH; RUMBAUGH; JACOBSON, 2012, p. 273).
Contudo, esses diagramas não são importantes somente para a modelagem

de aspectos dinâmicos do sistema, mas, assim como os diagramas de classes, para
a construção de sistemas executáveis por meio de engenharia direta e reversa.
Booch, Rumbaugh e Jacobson (2012, p. 273) adicionam que um diagrama de
interação mostra “uma interação, formada por um conjunto de objetos e seus
relacionamentos, incluindo as mensagens que poderão ser enviadas entre eles.” e o
diagrama de sequências é um diagrama de interação que dá maior ênfase à
ordenação temporal das mensagens.
Esse diagrama é formado posicionando-se primeiro os objetos que participam
da interação no nível superior do diagrama, ao longo do eixo X e, tipicamente, o objeto
que inicia a interação é colocado à esquerda e os que vem após ele vão descendo à
direita. Após isso são inseridas as mensagens, que esses objetos recebem e enviam,
ao longo do eixo Y, em ordem crescente de tempo, de cima para baixo. Essa estrutura
proporciona ao leitor uma indicação visual do fluxo de controle ao longo do tempo
(BOOCH; RUMBAUGH; JACOBSON, 2012).
2.6 ORIENTAÇÃO A OBJETOS
Nessa seção é explicado o conceito de orientação a objetos e os conceitos

envolvidos nesse paradigma da programação.
24
2.6.1 Programação Orientada a Objetos (POO)
De acordo com Mendes (2009) a programação orientada a objetos só obteve

mais popularidade com o uso da linguagem Java, em adição a isso o autor explica
que:
o paradigma de orientação a objetos traz um enfoque diferente da

programação estruturada, no sentido de adotar formas mais próximas do
mecanismo humano para gerenciar a complexidade de um sistema. Nesse
paradigma, o mundo real é visto como sendo construído de objetos
autônomos, concorrentes, que interagem entre si, e cada objeto tem seu
próprio estado (atributos) e comportamento (métodos), semelhante a seu
correspondente no mundo real (MENDES, 2009, p.18).
O autor mostra que há grandes diferenças na programação orientada a objetos

e na programação estruturada e também critica a má prática de programadores que
utilizam a linguagem Java, uma linguagem orientada a objetos, tendo em mente a
programação estruturada.
Para uma melhor comparação o autor também mostra como seria montado um
programa utilizando a linguagem estrutural e como seria montá-lo com a linguagem
orientada a objetos.
Na linguagem estrutural seriam criados diversos subprogramas, cada um para
uma função do programa como um todo, que seriam conectados e executados por um
programa principal. Mendes (2009) ainda conclui que a reutilização desses programas
é pequena e a redundância é grande, e em adição a isso, no paradigma procedural,
quando há modificações em algum dos programas é necessário alterar vários outros
para verificar se o programa funcionará da maneira esperada (MENDES, 2009).
Já na linguagem orientada a objetos seriam identificadas as classes com seus
atributos e métodos, por meio de diagramas como os citados na seção 2.5 e não é
necessário definir quantos programas seriam usados, mas sim quais classes, sendo
que essas representam um objeto no mundo real. Outra vantagem da utilização desse
tipo de linguagem é a possibilidade de utilizar uma ferramenta de modelagem para
geração de código (MENDES, 2009).
2.6.1.1 Java
De acordo com Deitel e Deitel (2010) Java é uma linguagem de alto nível de
programação que foi baseada na linguagem C++. Desenvolvida inicialmente pela Sun
25
Microsystems, mais especificamente por James Gosling, foi planejada para ser uma
linguagem para dispositivos eletrônicos inteligentes, mas como esse mercado não se
desenvolveu tão rapidamente como o esperado pela empresa, eles mudaram o foco
da linguagem, principalmente após a explosão da internet. O Java então focou-se na
linguagem para web, contudo, atualmente, é utilizado para desenvolver aplicativos
corporativos de grande porte, aprimorar funcionalidade de servidores web, fornecer
aplicativos para dispositivos voltados para o consumo popular, entre outros.
A linguagem Java tem uma grande biblioteca de classes, que constituem a
linguagem, também conhecidas como Java APIs (Application Programming
Interfaces). É possível ainda criar suas próprias classes utilizando Java e utilizar os
recursos de suas APIs para facilitar (DEITEL; DEITEL, 2010).
Deitel e Deitel (2010) dão aos leitores diversas dicas de engenharia de software
para explicar conceitos que afetam e aprimoram a qualidade e arquitetura do sistema,
além de dicas como:
• Utilizar boas práticas de programação;

• Evitar erros de programação comuns;
• Utilizar dicas de desempenho (técnicas que permitem a criação de programas
que executam mais rapidamente e usam menos memória);
• Utilizar dicas de portabilidade (técnicas que permitem o desenvolvimento de
programas que podem ser executados em diferentes computadores, sem
pouca ou nenhuma modificação);
• Utilizar dicas de prevenção de erros (técnicas para remoção de bugs dos
programas desenvolvidos, além de técnicas para criação de programas sem
bugs);
• Fazer observações sobre a interface (técnicas para ajudar na montagem das
interfaces que serão utilizadas pelos usuários do programa).
2.7 BANCO DE DADOS
Com os avanços tecnológicos, bancos de dados e sistemas de bancos de

dados tornaram-se cruciais para a vida na sociedade moderna e mesmo que o
indivíduo não esteja diretamente ligado a informática profissionalmente, ainda assim
está, indiretamente, usando diversos bancos de dados. Os bancos de dados estão
26
presentes em mercados, empresas, consultórios médicos, bancos e diversos outros

locais, tornando-se vitais para o funcionamento de diversos desses.
Segundo Elmasri e Navathe (2011, p. 3) um banco de dados, de maneira
genérica, é “uma coleção de dados relacionados. Com dados, queremos dizer fatos
conhecidos que podem ser registrados e possuem significado implícito.”.
Os bancos de dados podem ser classificados em diversas categorias de acordo
com Milani (2006), sendo as principais delas:
• Bancos manuais e automatizados:

◦ Os bancos manuais são como ficheiros de empresas que guardam dados
dela. Sua principal desvantagem é o tempo gasto para computar as
informações. Essa é situação atual da empresa JMS Tornotécnica, para a
qual será desenvolvido o software. Todo o processamento e
armazenamento de dados é feito manualmente, gerando um gasto de
tempo desnecessário que seria amenizado com a implementação do
sistema aqui proposto.
◦ Os bancos automatizados são construídos por sistemas de computador e
tem diversas vantagens em relação aos manuais, como a menor ocupação
de espaço físico e a velocidade de processamento para obtenção de
qualquer informação. A única desvantagem desse banco de dados é que
ele necessita de um maior invertimento para ser implementado.
• Bancos relacionais: um banco relacional é aquele que possui relacionamentos
entre seus dados. Esse recurso gera como consequência um melhor controle
na consistência das informações do banco de dados, impedindo que sejam
cadastrados dados não coerentes no sistema. Outra vantagem é que as
consultas aos dados do banco podem unir diversas tabelas para a geração do
resultado, tornando muito mais amplo o seu uso.
2.7.1 Sistema Gerenciador de Banco de Dados (SGBD)
O Sistema Gerenciador de Banco de Dados (SGBD) é, segundo Milani (2006,

p.322) “um sistema responsável pela segurança e proteção dos dados de um banco”.
Milani (2006) lista algumas características do SGBD como:
27
• Gerenciamento de acesso: o SGBD garante que apenas os usuários

autorizados tenham acesso à leitura ou alteração/gravação de determinadas
tabelas ou objetos do banco de dados, evitando que usuários que tem acesso
a partes do banco de dados não consigam acessar o banco todo.
• Integridade de dados: antes da criação dos SGBDs, qualquer um que tivesse
acesso de alteração/gravação de um arquivo poderia preencher um espaço
numérico com caracteres alfas (letras), resultando no mau funcionamento das
aplicações que dependessem desse arquivo. O SGBD garante que os dados
alterados ou adicionados no banco estejam de acordo com as regras que foram
criadas para eles.
• Integridade de entidade referencial: baseia-se na existência de chaves
estrangeiras no preenchimento de um campo, gerenciando e validando os
relacionamentos existentes entre as tabelas, evitando erros nos
relacionamentos entre as tabelas.
• Concorrência de acesso: antes da existência dos SGBDs o acesso para
gravação/alteração dos bancos de dados eram exclusivos. Cada indivíduo tinha
o direito o direito de gravação para si, e apenas quando terminasse seria
possível o acesso à gravação para outros. Em adição a isso, por serem
arquivos, o controle e gerenciamento de acesso eram feitos pelos sistemas
operacionais, impedindo que os bancos crescessem muito, pois uma grande
quantidade de acessos simultâneos a um sistema poderia torná-lo lento demais.
Já com o uso dos SGBDs, os controles de acessos foram diretamente
vinculados aos registros de uma tabela de um banco de dados, tornando
possível o acesso simultâneo de diversos usuários, sem o ocasionamento de
problemas de lentidão, entre outros.
• Linguagens de dados: com a implementação dos SGBDs foi necessária uma
padronização da linguagem utilizada nos bancos de dados. A maioria dos
bancos de dados utilizam a Structured Query Language (SQL), ou Linguagem
de Consulta Estruturada, para a interação do SGBD com o banco de dados.
Além dessas características Milani (2006) também cita algumas funcionalidade

gerais dos SGBDs mais utilizados no mercado e faz também uma comparação dos
SGBDs com os bancos de dados do tipo arquivo.
28
2.7.2 MySQL
Segundo Milani (2006, p.22) MySQL é:
um servidor e gerenciador de banco de dados (SGBD) relacional, de licença

dupla (sendo uma delas de software livre), projetado inicialmente para
trabalhar com aplicações de pequeno e médio portes, mas hoje atendendo
aplicações de grande porte e com mais vantagens do que seus concorrentes.
O MySQL é open-source1, além disso contém as características de um SGBD,

no caso o MySQL Server, já que provê todas as características de acesso aos dados,
faz o gerenciamento do acesso, a integridade dos dados, entre outros.
2.7.3 SQL
O SQL é o nome dados à linguagem responsável pela interação com os dados

armazenados na maioria dos bancos relacionais e as ferramentas de manipulação
gráfica de dados (MySQL Query Browser, PhpMyAdmin) utilizam SQL para interagir
com o banco de dados (MILANI, 2006).
É um conjunto de linguagens específicas para cada característica de um banco
de dados. Basicamente são divididas em três grupos, sendo um destes responsável
pela estrutura dos dados (Linguagem de Definição de Dados ou DDL), outro pela
manipulação dos dados (Linguagem de Manipulação de Dados ou DML) e o último,
pelo controle de acesso ao banco (Linguagem de Controle de Acesso ou DCL)
(MILANI, 2006).
De acordo com Milani (2006) o SQL também disponibiliza alguns recursos como:
• Consultas: possibilidade de pegar informações armazenadas no banco de

dados para a utilização em aplicativos.
• Atualizações: torna possível atualização das informações de um banco de
dados utilizando sistemas que tenham conexão com ele. A atualização é
considerada a inclusão, manutenção ou exclusão de dados de um banco.
1Open-source é “um termo em inglês que significa código aberto. Isso diz respeito ao código-fonte de
um software, que pode ser adaptado para diferentes fins.” (O que é open source?,[200?]).
29
• Filtros e ordenações: o SQL permite a formatação de dados retornados em uma

consulta, para que esses estejam ordenados de acordo com algum critério. Ele
também disponibiliza comandos que possibilitam a formatação de resultados.
2.7.4 Modelagem de dados (DER)
Elmasri e Navathe (2011) considera a modelagem conceitual uma fase

essencial para a construção de um projeto de banco de dados bem-sucedida. Para a
construção desse modelo é utilizado o modelo Entidade-Relacionamento (ER), que é
um modelo de dados conceitual popular de alto nível e utiliza o diagrama de Entidade-
Relacionamento (DER).
De acordo com Elmasri e Navathe (2011, p.134) o modelo ER “descreve os
dados como entidade, relacionamentos e atributos.”.
2.7.4.1 Identificando uma entidade
A entidade é considerada um objeto básico, com existência independente, que

o modelo ER representa. Pode ser um objeto com existência física (como um carro,
ou uma pessoa, entre outros) ou um objeto de existência conceitual (por exemplo,
uma empresa ou um cargo) (ELMASRI; NAVATHE, 2011).
As entidades possuem atributos, que são características ou propriedades que
as descrevem, por exemplo, uma entidade ALUNO pode ser descrita pelo nome, CPF,
idade, endereço, e-mail, turma e curso. Existem ainda vários tipos de atributos, sendo
eles atributos simples, compostos, de valor único, multivalorado, armazenado ou
derivado.
Alguns atributos de entidades fazem referências a outras entidades, como na
entidade ALUNO, em que temos o atributo TURMA e CURSO, que podem ser outras
entidades, em vez de atributos da entidade ALUNO. No modelo ER, essas referências
são consideradas relacionamentos, não atributos. Esses relacionamentos precisam
ter graus definidos e também podem ser de diferentes tipos.
2.8 TESTES
Para criar um sistema com a menor quantidade possível de erros, ou sejam

com uma boa qualidade é necessário testá-lo. No projeto foram feitos testes com o
30
JUnit, um framework opensource desenvolvido por Kent Beck e Martin Fowler, que
permite a criação de testes automatizados para Java (SOARES, [201?]).
O JUnit funciona de uma maneira bem simples, mostrando uma barra vermelha
quando houver erro no teste e os detalhes do erro, ou mostrando uma barra verde o
que significa que não há erros no teste.
31
3 METODOLOGIA DA PESQUISA
Neste capítulo é apresentada toda a parte de análise e desenvolvimento do

sistema que foram necessárias para a construção efetiva dele, abordando as
pesquisas acerca de metodologias de desenvolvimento, análises de sistema e
documentos importantes para a criação de um software.
3.1 DESCRIÇÃO DA SOLUÇÃO PROPOSTA
A metodologia adotada para a construção do sistema foi a RUP e a partir disso

criou-se as documentações vistas nas seções seguintes. Os diagramas utilizados na
construção do sistema fizeram uso também da UML.
3.2 REQUISITOS DO SISTEMAS
Nesta seção são abordadas documentações para o levantamento de requisitos

do sistema, ou seja, o que é necessário que o sistema faça. É a documentação inicial
criada e serviu de base para os diagramas que foram criados posteriormente.
3.2.1 Requisitos funcionais
Os requisitos funcionais são baseados nas necessidades do cliente e no que a

equipe de desenvolvimento acredita que seja necessário nas funcionalidades do
software. Verificou-se e analisou-se então as necessidades da administração
financeira da empresa JMS Tornotécnica e criou-se o quadro 3 com os requisitos
funcionais do sistema.
Quadro 3: Requisitos funcionais do sistema
Requisitos Funcionais
RF1 – O sistema deve permitir o cadastro de clientes (inclusão e modificação).

RF2 – O sistema deve permitir o cadastro de fornecedores (inclusão e modificação).
RF3 – O sistema deve permitir o cadastro de contas a pagar (inclusão, modificação
e exclusão2).
2A conta só poderá ser excluída se não estiver paga ou vencida.

32
RF4 – O sistema deve permitir o cadastro de pagamento de contas a receber

(inclusão, modificação e exclusão2).
RF5 – O sistema deve permitir o cadastro de um usuário e seu login e senha.
RF6 – O sistema deve permitir o cadastro do pagamento de contas (inclusão e
modificação).
RF7 – O sistema deve permitir a geração de um relatório de transações financeiras
das contas já pagas.
RF8 – O sistema deve permitir a geração de um relatório de transações financeiras
das contas não pagas.
Data Levantamento: 03/05/2017
3.2.2 Requisitos não funcionais
Nos requisitos não funcionais são descritos especificações mais técnicas do

sistema, como em que ambiente o sistema deve funcionar, qual banco de dados será
utilizado entre outras características não funcionais. Após encontrá-los montou-se o
quadro 4.
Quadro 4: Requisitos não funcionais do sistema
Requisitos Não Funcionais
RNF1 – Deverá utilizar o sistema gerenciador de banco de dados MySQL.

RNF2 – Deverá ser utilizado Java como linguagem de programação, por ser
orientada a objeto, estável e multiplataforma, caso aja a necessidade de ampliação
do sistema e eventual mudança.
RNF3 – Deverá ser executado no sistema operacional Windows, ou seja, não será
web.
Data Levantamento: 03/05/2017
3.3 DIAGRAMA DE CASOS DE USO

33
Outro passo importante para o planejamento e desenvolvimento do software é

a representação dele no diagrama de casos de uso (seção 2.5.1.1.1) que serviu de
base para os diagramas seguintes. Como mencionado anteriormente, é “uma
representação das funcionalidades externamente observáveis do sistema e dos
elementos externos ao sistema que interagem com ele.” (BEZERRA, 2015, p.53).
Com isso fez-se o diagrama de casos de uso abaixo para representar o sistema
desenvolvido:
Figura 2: Diagrama de casos de uso

34
Para melhor compreensão dos dados mostrados na Figura 2, fez-se os casos

de uso expandidos que mostram os casos de uso com maior aprofundamento.
Quadro 5: Cadastrar clientes (CSU01)
Cadastrar clientes (CSU01)
Sumário: O usuário cadastra clientes no sistema, com as informações necessárias.

Ator primário: Usuário.
Ator secundário: Não há.
Pré-condições: Usuário logado no sistema.
Fluxo principal:
1. O usuário solicita o cadastro de um novo cliente.
2. O sistema apresenta as operações que podem ser realizadas: inclusão, alteração
e consulta do cliente.
35
3. O usuário indica a opção a ser utilizada ou opta por finalizar o caso.

4. O usuário seleciona a opção desejada: inclusão, alteração ou consulta do cliente.
5. Se o usuário deseja continuar com a manutenção, o caso de uso retorna ao passo
2; caso contrário, o caso de uso termina.
Fluxo Alternativo (4): Inclusão
a) O usuário requisita a inclusão de um cliente.
b) O sistema apresenta um formulário em branco para que os detalhes do cliente
(nome, endereço, CNPJ ou CPF, telefone, e-mail, tipo de cliente (pessoa física ou
jurídica)) sejam incluídos.
c) O usuário fornece os detalhes do novo cliente.
d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o novo
cliente; caso contrário, o sistema reporta o fato, solicita novos dados e repete a
verificação.
Fluxo Alternativo (4): Alteração
a) O usuário requisita a alteração dos dados de um cliente.
b) O sistema apresenta os dados existentes que podem ser alterados (nome,
endereço, telefone e e-mail).
c) O usuário insere as informações.
d) O sistema verifica a validade dos dados inseridos. Se forem válidos, serão
alterados; caso contrário o sistema reporta o fato, solicita novos dados dos dados e
repete a verificação.
Fluxo Alternativo (4): Consulta
a) O usuário requisita a consulta dos dados do cliente.
b) O sistema mostra os dados dos clientes e as contas relacionadas com ele.
Pós-condições: O cliente foi cadastrado com sucesso.
Requisitos Funcionais Relacionais: RF1.
Prioridade: [ X ] Alta [ ] Média [ ] Baixa
Quadro 6: Cadastrar fornecedor (CSU02)
Cadastrar fornecedor (CSU02)
Sumário: O usuário cadastra fornecedores no sistema.

36

Fluxo principal:
1. O usuário solicita o cadastro de um novo fornecedor.
2. O sistema apresenta as operações que podem ser realizadas: inclusão, alteração
e consulta do fornecedor.
4. O usuário seleciona a opção desejada: inclusão, alteração ou consulta do cliente.
a) O usuário requisita a inclusão de um fornecedor.
b) O sistema apresenta um formulário em branco para que os detalhes do fornecedor
(nome, endereço, CNPJ ou CPF, telefone, e-mail e tipo de fornecedor (pessoa física
ou jurídica)) sejam incluídos.
c) O usuário fornece os detalhes do novo fornecedor.
d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o novo
fornecedor; caso contrário, o sistema reporta o fato, solicita novos dados e repete a
verificação.
a) O usuário requisita a alteração dos dados de um fornecedor.
b) O sistema apresenta os dados existentes que podem ser alterados (nome,
endereço, telefone e e-mail).
a) O usuário requisita a consulta dos dados do fornecedor.
b) O sistema mostra os dados do fornecedor e as contas relacionadas com ele.
Pós-condições: O fornecedor está cadastrado no sistema.
37
Quadro 7: Cadastrar contas a pagar (CSU03)
Cadastrar contas a pagar (CSU03)
Sumário: O usuário cadastra contas a pagar no sistema.

Fluxo principal:
1. O usuário solicita o cadastro de uma nova conta a pagar.
2. O sistema apresenta as operações que podem ser realizadas: inclusão, alteração,
exclusão e consulta da conta.
4. O usuário seleciona a opção desejada: inclusão, alteração, exclusão ou consulta
da conta a pagar.
a) O usuário requisita a inclusão de uma conta a pagar.
b) O sistema apresenta um formulário em branco para que os detalhes da conta
(valor, data de validade, fornecedor) sejam incluídos.
c) O usuário fornece os detalhes da nova conta a pagar.
d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui a nova
conta; caso contrário, o sistema reporta o fato, solicita novos dados e repete a
verificação.
a) O usuário requisita a alteração dos dados de uma conta a pagar.
b) O sistema apresenta os dados existentes que podem ser alterados (valor, data de
validade, fornecedor).
38
Fluxo Alternativo (4): Exclusão
a) O usuário requisita a exclusão da conta a pagar.
b) Para a conta ser excluída, o sistema precisa verificar se ela está vencida ou se
está paga. Se estiver, a conta não poderá ser excluída.
c) Se a conta puder ser excluída, o sistema pede a reinserção da senha do usuário
para confirmar a ação. Se a senha estiver correta, a conta é excluída, caso contrário
pede a inserção da senha novamente e faz a verificação.
a) O usuário requisita a consulta dos dados da conta a pagar.
b) O sistema mostra os dados da conta a pagar.
Pós-condições: A conta é cadastrada no sistema.
Quadro 8: Cadastrar contas a receber (CSU04)
Cadastrar contas a receber (CSU04)
Sumário: O usuário cadastra contas a receber no sistema.

Fluxo principal:
1. O usuário solicita o cadastro de uma nova conta a receber.
2. O sistema apresenta as operações que podem ser realizadas: inclusão, alteração,
exclusão e consulta da conta.
4. O usuário seleciona a opção desejada: inclusão, alteração, exclusão ou consulta
da conta a receber.
39
a) O usuário requisita a inclusão de uma conta a receber.

b) O sistema apresenta um formulário em branco para que os detalhes da conta
(código, valor, data de validade, cliente, data do lançamento no sistema, status do
pagamento e data de pagamento) sejam incluídos.
c) O usuário fornece os detalhes da nova conta a receber.
d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui a nova
conta; caso contrário, o sistema reporta o fato, solicita novos dados e repete a
verificação.
a) O usuário requisita a alteração dos dados de uma conta a receber.
b) O sistema apresenta os dados existentes que podem ser alterados (valor, data de
validade, cliente, status do pagamento e data de pagamento).
Fluxo Alternativo (4): Exclusão
a) O usuário requisita a exclusão da conta a receber.
b) O sistema pede a reinserção da senha do usuário para confirmar a ação. Se a
senha estiver correta, a conta é excluída, caso contrário pede a inserção da senha
novamente e faz a verificação.
a) O usuário requisita a consulta dos dados da conta a receber.
b) O sistema mostra os dados da conta a receber.
Pós-condições: A conta é cadastrada no sistema.
Quadro 9: Cadastro de usuário (CSU05)
Cadastro de usuário (CSU05)
Sumário: Cadastrar usuário com senha para proteção dos dados.

40
Ator primário: Usuário

Pré-condições: Não ter usuário cadastrado, em caso de primeiro acesso ao sistema,
este contará com um usuário administrador previamente cadastrado na base.
Fluxo principal:
1. Criar usuário e senha para o usuário e submeter o cadastro.
2. O sistema cadastrará o usuário e pedirá seus dados todas as vezes que for
acessado.
3. O usuário poderá ver suas informações e alterar seu login e senha.
a) O usuário requisita a alteração dos dados do usuário.
b) O sistema apresenta os dados existentes que podem ser alterados (login e senha).
a) O usuário requisita a consulta dos seus dados.
b) O sistema mostra o login do usuário e a senha em “ * “.
Pós-condições: Melhor proteção do sistema com criação de usuário.
Quadro 10: Cadastro de pagamento de contas (CSU06)
Cadastrar pagamento de contas (CSU06)
Sumário: O usuário cadastra o pagamento das contas a receber ou a pagar no

sistema.
Fluxo principal:
41
1. O usuário solicita o cadastro do pagamento de conta.

2. O sistema apresenta as operações que podem ser realizadas: inclusão e alteração
do pagamento.
4. O usuário seleciona a opção desejada: inclusão ou alteração.
a) O usuário requisita a inclusão de um pagamento.
b) O sistema apresenta um formulário em branco para que os detalhes do pagamento
(conta (a pagar ou receber), juros (se tiver) e data de pagamento) sejam incluídos.
c) O usuário fornece os detalhes do pagamento.
d) O sistema verifica a validade dos dados. Se os dados forem válidos, cadastra o
pagamento da conta; caso contrário, o sistema reporta o fato, solicita novos dados e
a) O usuário requisita a alteração dos dados de um pagamento.
b) O sistema apresenta os dados existentes que podem ser alterados (juros e data
de pagamento).
Pós-condições: O status é cadastrado no sistema.
Quadro 11: Relatório financeiro (CSU07)
Relatório financeiro pagos (CSU07)
Sumário: O sistema gerará um relatório financeiro com todas as contas cadastradas

que já tiveram pagamento registrado.
Ator primário: Sistema
42

Fluxo principal:
1. O usuário solicitará ao sistema a geração de um relatório financeiro das contas
pagas, podendo selecionar o período que ele deseja que seja gerado o relatório.
2. O sistema buscará todas as transações dentro dos parâmetros exigidos pelo
usuário e gerará o relatório.
Pós-condições: O sistema terá gerado o relatório das transações do usuário.
Quadro 12: Relatório financeiro (CSU08)
Relatório financeiro não pagos (CSU08)
Sumário: O sistema gerará um relatório financeiro com todas as contas cadastradas

que não tiveram pagamento registrado.
Ator primário: Sistema
Fluxo principal:
1. O usuário solicitará ao sistema a geração de um relatório financeiro das contas
que não tiveram pagamento registrado, podendo selecionar o período que ele deseja
que seja gerado o relatório.
2. O sistema buscará todas as transações dentro dos parâmetros exigidos pelo
usuário e gerará o relatório.
Pós-condições: O sistema terá gerado o relatório das transações do usuário.
3.4 DIAGRAMA DE CLASSES
A partir do diagrama de casos de uso (Figura 3), criou-se o diagrama de classes:

43
Figura 3: Diagrama de classes (Parte 1)

44
Figura 4: Diagrama de classes (Parte 2)
3.5 DIAGRAMA DE SEQUÊNCIA
Com base nas pesquisas sobre os diagramas de sequência (seção 2.5.1.1.3) e

nos diagramas criados anteriormente, criou-se também os diagramas de sequência
dos casos de uso anteriormente mostrados.
45
Figura 5: Diagrama de sequência do CSU01

46

47

48

49

50
3.6 MODELO DO BANCO DE DADOS
Para a criação do banco de dados, deve-se construir um modelo dele, como

mostrado na seção 2.8.1. Por isso montou-se o diagrama ER abaixo:
51

52
4 RESULTADOS ESPERADOS
Espera-se atender ao objetivo geral anteriormente descrito na seção 1.1.1, e

os objetivos específicos descritos na seção 1.1.2 deste projeto. Pretende-se também
atender a todas as necessidades especificadas pelo cliente, JMS Tornotécnica, para
que este projeto torne-se válido.
4.1 ANDAMENTO DO PROJETO E PRÓXIMAS ETAPAS
Tendo em vista os objetivos travados na seção 1.1, o projeto, no primeiro

semestre de 2017 (2017/1), teve andamento conforme mostrado na Figura 12.
No segundo semestre (2017/2) visando complementar o projeto, a Figura 13,

apresenta as etapas feitas.
53
Figura 13: Cronograma da segunda fase do projeto
4.2 DETALHAMENTO DAS ETAPAS REALIZADAS
Conforme mostrado na Figura 13 durante o segundo semestre tinham-se 9

etapas para serem cumpridas. Nesta seção é detalhado o que foi feito em cada etapa.
4.2.1 Etapa I: Implementação do banco de dados
Implementou-se o banco de dados de acordo com o definido na modelagem de

dados na seção 3.6.
4.2.2 Etapa II: Implementação da classe usuário
Implementou-se a classe do usuário com seus métodos e atributos conforme o

diagrama de classes. Além disso criou-se as seguintes telas:
54
Figura 14: Telas de cadastro, alteração e acesso do usuário
Além dessas telas, criou-se também uma tela inicial para que o usuário possa
navegar com maior facilidade pelo sistema.
55
Figura 15: Tela inicial do sistema
Essa tela mostra também as contas vencidas e/ou próximas da data de

vencimento, para que o usuário esteja atento ao pagamento dessas.
4.2.3 Etapas III e IV: Implementação das classes do cliente e do fornecedor
Implementou-se as classes do cliente e do fornecedor com seus métodos e

atributos conforme o diagrama de classes. Além disso criou-se as seguintes telas, que
são similares para o cliente e o fornecedor:
56
Figura 16: Tela de cadastro e busca de clientes

57
Figura 17: Tela de detalhes de clientes
4.2.4 Etapas V e VI: Implementação das classes das contas
Implementou-se as classes das contas a pagar e contas a receber com seus

métodos e atributos conforme o diagrama de classes. Criou-se também as seguintes
telas, sendo elas similares para a conta a pagar e para a conta a receber:
58
Figura 18: Tela de cadastro de contas a pagar

59
Figura 19: Telas de busca e de detalhes de contas a pagar
4.2.5 Etapa VII: Implementação da classe de pagamento de contas

60
Implementou-se a classe de pagamento de contas com seus métodos e

atributos conforme o diagrama de classes. Criou-se também uma tela para cadastro
de pagamentos:
Figura 20: Tela de cadastro de pagamento de contas
4.2.6 Etapa VIII: Relatórios
Criou-se o relatório de contas a pagar e a receber conforme mostrado na Figura

abaixo:
61
Figura 21: Relatório de contas a pagar
4.2.7 Etapa VIII: Realização de testes
Fez-se um teste de cadastro do usuário para verificar se a conexão com o

banco de dados estava funcionando da maneira correta. Na Figura 22 mostra-se o
código do teste criado e na Figura 23 mostra-se o resultado do teste.
62
Figura 22: Código do teste de cadastro de usuários
Figura 23: Resultado do teste de cadastro de usuário com JUnit
4.2.7 Etapa IX: Validação com o usuário

63
Para validar o sistema e verificar se ele cumpriu as necessidades dos

administradores a JMS Tornotécnica, aplicou-se um questionário com uma funcionária
da empresa após essa ter testado o sistema.
1. O que você achou da interface do sistema?
Resposta: Boa e fácil para mexer.
2. Você achou que o sistema cumpriu com os objetivos iniciais propostos?

Resposta: Cumpre com minhas necessidades
3. O sistema apresenta travamentos ou erros?

Resposta: Não testei o sistema por muito tempo, mas durante o teste não apresentou
travamentos, somente um erro.
4. Quão satisfeito ou insatisfeito você ficou com o sistema?

Resposta: Muito satisfeita.
5. Você recomendaria o sistema para outras pessoas e/ou empresas?

Resposta: Sim, mas gostaria de mais tempo para testar o sistema.
6. O que você acha que pode ser melhorado no sistema?

Resposta: Puxar os dados do meu sistema de notas fiscais para o sistema financeira,
assim não terei que cadastrar nos dois. Ter aletas sobre notas quando estão próximas
da data de vencimento, em vez de só mostrá-las na tela inicial do sistema.
Pode-se perceber que o resultado foi satisfatório já que cumpriu com os

objetivos criados e com as necessidades do cliente.
64
5 CONCLUSÃO
Através da análise prévia das necessidades do cliente em conjunto com a

revisão bibliográfica realizada foi possível a implementação do sistema. A utilização
da metodologia de desenvolvimento RUP para a construção do sistema mostrou-se
eficaz, uma vez que ela se utiliza dos diagramas disponíveis na UML, o que auxiliou
no entendimento das partes que vieram a constituir o sistema.
Com isso e com a validação realizada com o cliente pode-se perceber que os
objetivos do projeto, que eram desenvolver um software de administração financeira
que pudesse automatizar o processo financeiro de uma micro ou pequena empresa a
partir da criação de cadastros de clientes, fornecedores e relatórios de transações,
foram alcançados.
Entretanto como implementações futuras ainda há possíveis melhorias para o
projeto como a criação de orçamentos, cadastro de serviços ou produtos, cadastro de
funcionários, ou seja, a implementação de funcionalidades que cubram todos ou a
maioria dos fatores que influenciam na renda da empresa, criando assim um controle
financeiro aperfeiçoado e mais preciso. Outra possível mudança para o sistema seria
criar uma versão para a web, pois dessa maneira a facilidade de acesso do usuário
seria maior.
Pretende-se também compartilhar o software postando-o em algum fórum após
a realização de algumas melhorias, podendo até liberar o código-fonte para que, se
alguém achar necessário, possam ser feitas alterações.
Percebe-se portanto que apesar de finalizar esta fase do projeto ainda há muito
o que pode ser trabalhado e implementado no sistema, visando atender demandas
futuras do usuário para esse.
65
REFERÊNCIAS
BIO, Sérgio Rodrigues; CORNACHIONE JÚNIOR, Edgard Bruno. Sistemas de

Informação: Um Enfoque Gerencial. 2. ed. São Paulo: Editora Atlas S.a., 2008. 240
p.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usuário. 2.

ed. Rio de Janeiro: Elsevier Editora Ltda., 2012. 512 p. Tradução de: Fábio Freitas da
Silva e Cristina de Amorim Machado.
BRASIL. Secretaria da Micro e Pequena Empresa da Presidência da República.

Departamento de Racionalização das Exigências Estatais. Tratamento diferenciado
às micro e pequenas empresas: legislação para estados e municípios. Brasília, DF:
Secretaria da Micro e Pequena Empresa da Presidência da República, [2014].
Disponível em
<http://www.smpe.gov.br/assuntos/cartilha_tratamentodiferenciado_mpe.pdf>.
Acessado em: 12 fev. 2017.
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 3. ed.

Rio de Janeiro: Elsevier, 2015. 398 p.
CHIAVENATO, Idalberto. Teoria Geral da Administração: abordagens prescritivas e

normativas. 7 ed. São Paulo: Manole, 2014. 436 p.
DEITEL, Paul; DEITEL, Harvey. Java: Como programas. 8. ed. São Paulo: Pearson,
2010. 1145 p. Tradução de: Edson Furmankiewicz.
ELMASRI, Ramez; NAVATHE, Shamkant B.. Sistemas de banco de dados. 6. ed. 3.

reimpressão, 2014. São Paulo: Pearson, 2011. Tradução de: Daniel Vieira.
LEMES JÚNIOR, Antônio Barbosa; RIGO, Cláudio Miessa; CHEROBIM, Ana Paula
Mussi Szabo. Administração Financeira: Princípios, Fundamentos e Práticas
Brasileiras. 3. ed. Rio de Janeiro: Elsevier, 2010.
MENDES, Douglas Rocha. Programação Java com Ênfase em Orientação a

Objetos. São Paulo: Novatec, 2009. 456 p.
MILANI, André. MySQL: Guia do programador. 1. ed. São Paulo: Novatec, 2006. 397
p.
CANALTECH. O que é open source? Disponível em: <https://canaltech.com.br/o-

que-e/o-que-e/O-que-e-open-source/>. Acesso em: 25 maio 2017.
ROSINI, Alessandro Marco; PALMISANO, Angelo. Administração de Sistemas de

Informação e a Gestão do Conhecimento. 2. ed. São Paulo: Cencage Learning,
2012. 212 p.
SEBRAE. Micro e pequenas empresas geram 27% do PIB do Brasil. 2014.

Disponível em: <https://www.sebrae.com.br/sites/PortalSebrae/ufs/mt/noticias/micro-
66
e-pequenas-empresas-geram-27-do-pib-do-
brasil,ad0fc70646467410VgnVCM2000003c74010aRCRD>. Acesso em: 16 fev. 2017.
SOARES, Diogo Castro Veloso. Testes de unidade com o JUnit. [201?]. Disponível
em: <https://www.devmedia.com.br/testes-de-unidade-com-junit/4637>. Acesso em:
06 nov. 2017.
SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e

Tradicionais para o Desenvolvimento de Software. [201?].
SOUZA, Cesar Alexandre de; ZWICKER, Ronaldo. CICLO DE VIDA DE SISTEMAS

ERP. Caderno de Pesquisas em Administração. São Paulo, 2000. Disponível em:
<https://www.mendeley.com/viewer/?fileId=17a5bd70-745f-0b47-4de5-
964d77f0b7ef&documentId=fb10f6ff-5a78-3f08-82e7-041acc928e6a>. Acesso em: 20
fev. 2017.
UERJ. Metodologia RUP. Disponível em: <http://www.sgp-

ti.uerj.br/site/metodologia/>. Acesso em: 25 maio 2017.

Relatório Final PI

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Relatório Final PI

Enviado por

Direitos autorais:

Formatos disponíveis

INSTITUTO FEDERAL DE SANTA CATARINA

Priscila Graziele Busnello de Araújo

DESENVOLVIMENTO DE UM SISTEMA DE ADMINISTRAÇÃO FINANCEIRA

DESENVOLVIMENTO DE UM SISTEMA DE ADMINISTRAÇÃO FINANCEIRA

Relatório apresentado a disciplina de Projeto Integrador do Curso Técnico

As micro e pequenas empresas vem crescendo no cenário econômico nacional,

Palavras-Chave: Controle financeiro. Micro e pequenas empresas. Administração.

Figura 1: Fases do RUP ............................................................................................ 19

Quadro 1: Softwares de gestão disponíveis no mercado .......................................... 10

API – Interface de programação de aplicações (do inglês, Application Programming

3.2 REQUISITOS DO SISTEMAS ......................................................................... 31

Segundo Bio e Cornachione Júnior (2008, p. 22), um sistema de informações

As micro e pequenas empresas estão crescendo cada vez mais no cenário

• 52% dos empregos com carteira assinada;

Quadro 1: Softwares de gestão disponíveis no mercado

Nome do software Pago ou grátis Site

eGestor Pago https://www.egestor.com.br/

CashPreview Grátis http://www.cashpreview.com.br/cashprev

ContaAzul Pago https://contaazul.com/

QuickBooks ZeroPaper Grátis https://www.quickbooks.com.br/

Controlle Grátis https://controlle.com/

Fonte: produção da autora, 2017

Ao concluir-se as pesquisas dos softwares acima mostrados, percebeu-se que

Desenvolver um software de administração financeira para uma microempresa,

1.1.2 Objetivos específicos

• Criar o cadastro de clientes para controlar o público atendido pela empresa;

O projeto se justifica pois apesar de existirem vários sistemas para

2.1 ADMINISTRAÇÃO EMPRESARIAL

Segundo Chiavenato (2014, p. 2) a administração é:

A condução racional e estratégica das atividades de uma organização, seja

O autor comenta também que vivemos em uma sociedade de organizações,

Segundo Chiavenato (2014, p.2) o administrador é “um gerador de riqueza, seja

várias, sendo possível fazer coisas totalmente diferentes e chegar ao mesmo

2.2 ADMINISTRAÇÃO FINANCEIRA

Focando na parte financeira da administração de uma empresa, pesquisou-se

Quadro 2: Funções da administração financeira

GERÊNCIA FINANCEIRA CONTROLADORIA

• Administração de caixa • Administração de custos e preços

Fonte: LEMES JÚNIOR; RIGO; CHEROBIM, 2010, p.6.

Segundo Lemes Júnior, Rigo e Cherobim (2010), além disso o administrador

• Quais investimentos de longo prazo deve fazer?

• Onde conseguirá os financiamentos necessários para viabilizar esses

Os autores complementam dizendo que o administrador financeiro contribuirá

2.3 SISTEMA DE INFORMAÇÃO

As informações são de grande importância no mundo administrativo pois são

Dados são as representações originais e detalhadas de eventos no mundo

Segundo Bio e Cornachione Júnior (2008), o sistema de informação é um

2.3.1 Sistemas para empresas

Os sistemas de informações evoluem cada vez mais e tem como tendência

2.3.1.1 Os benefícios de sistemas ERP

Os benefícios dos sistemas ERP podem ser classificados em quatro categorias:

• Primeira: geração de informações que apoiam a gestão, o que inclui:

◦ O aumento de fluxo de informações entre os subsistemas da empresa;

• Segunda: a padronização e integração das unidades da empresa.

• Terceira: redução de custos na manutenção dos sistemas de informações e

Os sistemas ERP possuem diversas vantagens para uma empresa, já que

2.3.2 Sistemas financeiros para empresas

Anteriormente foram citados alguns sistemas financeiros para empresas que

2.4 DESENVOLVIMENTO DE SOFTWARE

Projetos de software podem adotar metodologias de desenvolvimento para sua

2.4.1 Metodologias de desenvolvimento

De acordo com Soares ([201?]) a metodologia de desenvolvimento de software

é um conjunto de atividades e resultados associados que auxiliam na

Para o desenvolvimento do software será utilizado o Processo Racional