análise orientada a objetos para fluxo de caixa em estúdio de gravação

5/8/2018 Análise Orientada a Objetos para Fluxo de Caixa em Estúdio de Gravação - slidepdf.com

http://slidepdf.com/reader/full/analise-orientada-a-objetos-para-fluxo-de-caixa-em-estudio-de-gravacao 1/120

IVAN LUIS GUNKEL

MAYCON VIANA BORDIN

ANÁLISE ORIENTADA A OBJETOS PARA FLUXO DE

CAIXA EM ESTÚDIO DE GRAVAÇÃO

Três de Maio

2009



IVAN LUIS GUNKEL

MAYCON VIANA BORDIN

ANÁLISE ORIENTADA A OBJETOS PARA FLUXO

DE CAIXA EM ESTÚDIO DE GRAVAÇÃO

Relatório da Prática Profissional Direcionada III

Sociedade Educacional Três de Maio

Faculdade Três de Maio

Curso de Bacharelado em Sistemas de Informação

Professores Orientadores:

Ms. Gelson Reis

Ms. Marcelo Ackermann

Ms. Renato Rockenbach

Ms. Vera Lúcia Lorenset Benedetti

Três de Maio

2009



RESUMO

O presente trabalho tem por objetivo apresentar a análise orientada a objetos

desenvolvida na Prática Profissional Direcionada III, no curso de Bacharelado em

Sistemas de Informação que envolve as disciplinas de Análise e Projetos de Sistemas

II, Banco de Dados I, Matemática Financeira e Teoria Econômica, sendo elaborado na

Faculdade Três de Maio – SETREM no período de julho a novembro de 2009. O

objetivo principal deste estudo foi aplicar os conhecimentos das disciplinas acima

citadas para o desenvolvimento de uma análise orientada a objetos, onde uma empresa

fictícia foi usada como local para estudo e aplicação da análise. Foi identificado um

problema na empresa, onde procurou-se obter informações sobre as necessidades e

carências da mesma no quesito movimento de caixa. A partir de então buscou-seembasamento teórico em bibliografia impressa e artigos publicados na internet, onde

estes serviram de apoio no entendimento do regime de caixa e na construção dos

diagramas UML e ER, que foram construídos a partir do levantamento das

necessidades descritas nos requisitos. Como resultados desta análise, foram obtidos

diagramas que podem servir de base para o desenvolvimento de um software,

atendendo as necessidades da empresa.

Palavras chave: Análise Orientada a Objetos, Regime de Caixa, Diagramas.



ABSTRACT

This paper aims to present the object-oriented analysis developed in the

Professional Practice III, in the course of Graduation of Information Systems involving

the disciplines of Analysis and Design System II, Database I, Financial Mathematics and

Economic Theory being developed at the Faculdade Três de Maio - SETREM from July

to November 2009. The aim of this study was to apply the knowledge of the disciplines

mentioned above to develop an object-oriented analysis, where a fictitious company was

used as a place for study and analysis application. Issue has been identified in the

company, tried to obtain information about the needs and wants of the same in motion

box. Since then we sought in theoretical literature and printed articles on the web, where

they served as support in the understanding of the cash basis and the construction ofUML diagrams and ER, which were built from the needs assessment described in the

requirements. The results of this analysis were obtained diagrams that can serve as a

basis for the development of software, meeting the needs of the company.

Keywords: Object-Oriented Analysis, Cash Basis, Diagrams.



LISTA DE FIGURAS

Figura 1: Esquema de entradas e saídas em um fluxo de caixa. ................................... 32

Figura 2: Ciclo de caixa. ................................................................................................. 36

Figura 3: Modelo de Fluxo de Caixa. .............................................................................. 38

Figura 4: Contribuições a UML. ...................................................................................... 46

Figura 5: Visões de um sistema de software. ................................................................. 49

Figura 6: Exemplo de Diagrama de Casos de Uso. ....................................................... 54

Figura 7: Exemplo de Classe. ........................................................................................ 56

Figura 8: Tipos de relacionamentos entre classes. ........................................................ 58

Figura 9: Exemplo de Diagrama de Classes. ................................................................. 60

Figura 10: Objetos criados antes de a interação começar. ............................................ 62

Figura 11: Tipos de mensagem. ..................................................................................... 62

Figura 12: Exemplo de Diagrama de Sequência. ........................................................... 63

Figura 13: Exemplo de Diagrama de Máquina de Estados. ........................................... 66

Figura 14: Exemplo de Componente com Interfaces e Portas. ...................................... 67

Figura 15: Exemplo de Diagrama de Componentes. ...................................................... 68

Figura 16: Exemplo Diagrama de Implementação. ........................................................ 70

Figura 17: Exemplo de um modelo conceitual. ............................................................... 72

Figura 18: Exemplo de representação de entidades. ..................................................... 73

Figura 19: Representação gráfica de um relacionamento. ............................................. 74

Figura 20: Relacionamento 1:1. ..................................................................................... 75



6

Figura 21: Relacionamento 1:n. ..................................................................................... 76

Figura 22: Relacionamento n:n. ..................................................................................... 76

Figura 23: Relacionamento ternário com cardinalidade. ................................................ 77

Figura 24: Cardinalidade em atributos............................................................................ 78

Figura 25: Atributos em relacionamentos. ...................................................................... 79

Figura 26: Identificador simples. ..................................................................................... 79

Figura 27: Identificador composto. ................................................................................. 80

Figura 28: Exemplo de generalização/especialização. ................................................... 81

Figura 29: Exemplo de generalização/especialização parcial. ....................................... 82

Figura 30: Exemplo de entidade associativa. ................................................................. 83

Figura 31: Diagrama de Casos de Uso. ......................................................................... 88 Figura 32: Diagrama de Classes. ................................................................................... 95

Figura 33: Diagrama de Sequência (Abertura de Caixa). ............................................... 99

Figura 34: Diagrama de Sequência (Cadastro de Categoria)....................................... 100

Figura 35: Diagrama de Sequência (Cadastro de Funcionário). .................................. 101

Figura 36: Diagrama de Sequência (Estornar Lançamento). ....................................... 103

Figura 37: Diagrama de Sequência (Fechamento de Caixa). ....................................... 105

Figura 38: Diagrama de Sequência (Geração de Relatórios). ...................................... 106

Figura 39: Diagrama de Sequência (Incluir Lançamento). ........................................... 107

Figura 40: Diagrama de Máquina de Estados (Caixa). ................................................. 110

Figura 41: Diagrama de Máquina de Estados (Lançamentos). .................................... 111

Figura 42: Diagrama de Entidades-Relacionamentos. ................................................. 112



LISTA DE QUADROS

Quadro 1: Cronograma de Atividades do Projeto. .......................................................... 18

Quadro 2: Orçamento do projeto. ................................................................................... 19

Quadro 3: Comparativo entre juros simples e juros compostos. .................................... 26

Quadro 4: Diagramas da UML. ....................................................................................... 51

Quadro 5: Requisitos Funcionais. .................................................................................. 85

Quadro 6: Requisitos Não-Funcionais ............................................................................ 86

Quadro 7: Requisitos de Domínio. ................................................................................. 86

Quadro 8: Descrição dos Casos de Uso. ....................................................................... 93

Quadro 9: Atributos e Operações das Classes. ............................................................. 97



LISTA DE SIGLAS

CE – Ciclo Econômico

CF – Ciclo Financeiro

CFMe – Custo Fixo Médio

CTMe – Custo Total Médio

CVMe – Custo Variável Médio

DER – Diagrama Entidades-Relacionamentos

ER – Entidades-Relacionamentos

OMG – Object Management Group OMT – Object Modeling Technique

OOSE – Object-Oriented Software Engineering

PMP – Prazo Médio de Pagamentos

PMR – Prazo Médio de Recebimentos

SFC – Saldo Final de Caixa

SGBD – Sistema de Gerenciamento de Banco de Dados

SIC – Saldo Inicial de Caixa

UML – Unified Modeling Language



SUMÁRIO

RESUMO .......................................................................................................................... 3

ABSTRACT ...................................................................................................................... 4

LISTA DE FIGURAS ........................................................................................................ 5

LISTA DE QUADROS ...................................................................................................... 7

LISTA DE SIGLAS ........................................................................................................... 8

SUMÁRIO ........................................................................................................................ 9

INTRODUÇÃO ............................................................................................................... 13

CAPÍTULO 1: ASPECTOS METODOLÓGICO ............................................................. 14

1.1 TEMA ....................................................................................................................... 14

1.2 DELIMITAÇÃO DO TEMA ........................................................................................ 14

1.3 PROBLEMATIZAÇÃO DO TEMA ............................................................................. 14

1.4 HIPÓTESES ............................................................................................................. 15

1.4.1 Variáveis ............................................................................................................... 15

1.5 OBJETIVOS ............................................................................................................. 15

1.5.1 Objetivo Geral ...................................................................................................... 15

1.5.2 Objetivos Específicos ......................................................................................... 15

1.6 JUSTIFICATIVA ....................................................................................................... 16

1.7 METODOLOGIA ....................................................................................................... 17

1.7.1 Métodos de Abordagem ...................................................................................... 17

1.7.2 Métodos de Procedimentos ................................................................................ 17



10

1.7.3 Técnicas ............................................................................................................... 17

1.8 CRONOGRAMA ....................................................................................................... 18

1.9 RECURSOS ............................................................................................................. 19

1.10 ORÇAMENTO ........................................................................................................ 19

CAPÍTULO 2: FUNDAMENTAÇÃO TEÓRICA .............................................................. 20

2.1 PRESTAÇÃO DE SERVIÇOS .................................................................................. 20

2.2 TEORIA ECONÔMICA ............................................................................................. 21

2.2.1 Conceito de Economia ........................................................................................ 21

2.2.2 Sistemas Econômicos ........................................................................................ 21

2.2.3 Moeda ................................................................................................................... 22

2.2.4 Inflação ................................................................................................................. 22

2.2.5 Demanda .............................................................................................................. 23

2.2.6 Orçamento ........................................................................................................... 23

2.3 MATEMÁTICA FINANCEIRA ................................................................................... 24

2.3.1 Juros ..................................................................................................................... 24

2.3.1.1 Juros Simples ..................................................................................................... 25

2.3.1.2 Juros Compostos................................................................................................ 26

2.3.2 Investimento ........................................................................................................ 27

2.3.3 Poupança ............................................................................................................. 27

2.3.4 Custo .................................................................................................................... 27

2.3.5 Contabilidade ....................................................................................................... 28

2.3.6 Despesas .............................................................................................................. 29

2.3.7 Receitas ................................................................................................................ 30

2.4 PLANEJAMENTO FINANCEIRO.............................................................................. 30

2.4.1 Fluxo de Caixa ..................................................................................................... 31

2.4.1.1 Conceituação...................................................................................................... 31

2.4.1.2 Características.................................................................................................... 31

2.4.1.3 Planejamento do Fluxo de Caixa ........................................................................ 33

2.4.1.4 Implantação do Fluxo de Caixa .......................................................................... 34

2.4.1.5 Ciclo de Caixa .................................................................................................... 36

2.4.1.6 Modelo de Fluxo de Caixa .................................................................................. 37



11

2.4.1.7 Controle de Caixa ............................................................................................... 39

2.4.2 Regime de Caixa, Regime de Competência e Livro Caixa ............................... 40

2.5 ANÁLISE ORIENTADA A OBJETOS ....................................................................... 41

2.5.1 Análise de Sistemas ............................................................................................ 41

2.5.2 Análise Orientada a Objetos ............................................................................... 42

2.5.2.1 História ............................................................................................................... 42

2.5.2.2 Classes, Objetos e Mensagens .......................................................................... 43

2.5.2.3 Encapsulamento ................................................................................................. 44

2.5.2.4 Herança .............................................................................................................. 44

2.5.2.5 Polimorfismo ....................................................................................................... 45

2.5.3 UML ....................................................................................................................... 45

2.5.3.1 História ............................................................................................................... 45

2.5.3.2 Conceitos ........................................................................................................... 46

2.5.3.3 Elementos Básicos ............................................................................................. 49

2.5.3.4 Diagramas da UML ............................................................................................. 50

2.5.3.4.1 Diagrama de Casos de Uso ............................................................................ 51

2.5.3.4.2 Diagrama de Classes ...................................................................................... 55

2.5.3.4.3 Diagrama de Sequência .................................................................................. 61

2.5.3.4.4 Diagrama de Máquina de Estados .................................................................. 64

2.5.3.4.5 Diagrama de Implementação........................................................................... 66

A) Diagrama de Componentes ....................................................................................... 67

B) Diagrama de Implantação .......................................................................................... 69

2.6 BANCO DE DADOS ................................................................................................. 70

2.6.1 SGBD .................................................................................................................... 71

2.6.2 Banco de Dados .................................................................................................. 71

2.6.3 Modelo Conceitual ............................................................................................... 72

2.6.3.1 Modelagem ER ................................................................................................... 73

2.6.3.1.1 Entidade .......................................................................................................... 73

2.6.3.1.2 Relacionamento............................................................................................... 74

2.6.3.1.3 Atributo ............................................................................................................ 78

2.6.3.1.4 Generalização/Especialização......................................................................... 80



12

2.6.3.1.5 Entidade Associativa ....................................................................................... 82

2.6.4 Modelo Lógico ..................................................................................................... 83

CAPÍTULO 3: RESULTADOS OBTIDOS ...................................................................... 84

3.1 PROPOSTA DO NOVO SISTEMA ........................................................................... 84

3.1.1 Descrição do Problema ....................................................................................... 84

3.1.2 Descrição das necessidades dos interessados ............................................... 84

3.1.2.1 Requisitos funcionais .......................................................................................... 85

3.1.2.2 Requisitos não-funcionais .................................................................................. 86

3.1.2.3 Requisitos de domínio ........................................................................................ 86

3.1.3 Descrição do sistema proposto ......................................................................... 86

3.1.3.1 Diagramas UML.................................................................................................. 87 3.1.3.1.1 Diagrama de Casos de Uso ............................................................................ 87

3.1.3.1.2 Diagrama de Classes ...................................................................................... 94

3.1.3.1.3 Diagramas de Sequência ................................................................................ 97

A) Abertura de Caixa ...................................................................................................... 98

B) Cadastro de Categorias ............................................................................................. 99

C) Cadastro de Funcionário ......................................................................................... 100

D) Estornar Lançamento .............................................................................................. 102

E) Fechamento de Caixa .............................................................................................. 103

F) Geração de Relatórios ............................................................................................. 105

G) Incluir Lançamento .................................................................................................. 107

3.1.3.1.3 Diagramas de Máquina de Estados ............................................................... 108

A) Classe Caixa ............................................................................................................ 109

B) Classe Lançamentos ............................................................................................... 110

3.1.3.1 Diagrama de Entidades-Relacionamentos ....................................................... 111

3.1.4 Resultados esperados ...................................................................................... 113

3.1.5 Restrições do sistema proposto ...................................................................... 114

CONCLUSÃO .............................................................................................................. 115

REFERÊNCIAS ............................................................................................................ 117



INTRODUÇÃO

O presente trabalho foi elaborado pelos acadêmicos do curso de Sistemas de

Informação da Faculdade Três de Maio – SETREM, juntamente com os professores

orientadores, tendo como escopo a realização de uma análise orientada a objetos para

regime de caixa em uma empresa fictícia, onde foram levantados os requisitos dos

usuários fictícios e em cima destes foi desenvolvida toda a análise e obtidos os

diagramas da UML e o modelo ER.

Através da Análise Orientada a Objetos bem como a modelagem de dados

estruturou-se a documentação do sistema de forma detalhada e consistente. De modo

a ilustrar claramente o funcionamento do sistema de regime de caixa, além de sanarmuitos problemas que surgem na fase de desenvolvimento quando a análise não é feita

corretamente ou inexiste nas fases do projeto.

O relatório é composto da seguinte maneira: O Capítulo 1 apresenta o projeto

realizado, onde constam os aspectos metodológicos empregados na sua realização e o

cronograma respeitado. No Capítulo 2 é apresentado o referencial teórico, onde consta

o embasamento teórico utilizado no desenvolvimento da análise orientada a objetos. O

Capítulo 3 apresenta uma descrição da situação da empresa, os requisitos levantados e

os diagramas resultantes da análise. E em sequência, a conclusão e as referências

utilizadas na formulação do relatório.



CAPÍTULO 1: ASPECTOS METODOLÓGICO

Neste capítulo apresenta-se a forma de como foi realizada a análise orientada a

objetos, os objetivos, sua justificativa de execução, a metodologia empregada, os

prazos determinados e os recursos utilizados no seu desenvolvimento.

1.1 TEMA

Elaboração de uma análise orientada a objetos para fluxo de caixa em empresa

no ramo de serviços.

1.2 DELIMITAÇÃO DO TEMA

Elaborar uma análise orientada a objetos e modelo entidade-relacionamento

para fluxo de caixa para empresa de gravação de áudio, que foi desenvolvida pelos

acadêmicos Ivan Luis Gunkel e Maycon Viana Bordin do 4º semestre do curso

Bacharelado em Sistemas de Informação, na Prática Direcionada III, que envolve as

disciplinas de Banco de Dados, Análise e Projetos de Sistemas II, Matemática

Financeira e Teoria Econômica de agosto a dezembro de 2009 na Sociedade

Educacional Três de Maio - SETREM na cidade de Três de Maio, RS.

1.3 PROBLEMATIZAÇÃO DO TEMA

A análise orientada a objetos bem como o modelo de entidades-

relacionamentos poderiam estruturar de forma consistente uma documentação



15

detalhada de um sistema de fluxo de caixa. Descrevendo este de forma concisa e

ilustrando claramente o funcionamento do sistema através dos diagramas UML?

1.4 HIPÓTESES

A análise orientada a objetos torna mais claro o entendimento sobre o fluxo de

caixa da empresa.

O modelo ER possibilita uma melhor compreensão do fluxo de caixa da empresa.

1.4.1 Variáveis

Fluxo de Caixa

Finanças

Organização

1.5 OBJETIVOS

1.5.1 Objetivo Geral

Realizar uma análise orientada a objetos e um modelo de entidades-

relacionamentos em uma empresa de gravação de áudio.

1.5.2 Objetivos Específicos

Levantar os requisitos e necessidades da empresa com relação ao sistemade regime de caixa intentado.

Estudar o funcionamento do fluxo de caixa.

Realizar uma análise orientada a objetos sobre o fluxo de caixa da empresa

selecionada.



16

Elaborar o modelo ER.

Elaborar os diagramas UML.

Registrar e divulgar os resultados.

Criação e acompanhamento do projeto na ferramenta dotProject, instalado no

servidor da SETREM.

1.6 JUSTIFICATIVA

O desenvolvimento deste projeto tem como intuito salientar os benefícios daanálise orientada a objetos, que vão desde a padronização dos diagramas utilizados

nas fases do projeto, a junção entre a visão das funcionalidades e dos dados, a

compreensão facilitada dos diagramas por parte dos usuários, o que torna a

comunicação com o analista muito melhor, e a possibilidade de se reutilizar códigos

sem grandes esforços. Desta forma, o custo de desenvolvimento é reduzido, a correção

de erros se torna mais fácil e a produtividade aumenta.

Já a modelagem de banco de dados serviu para descrever as entidades

importantes para o sistema e qual a relação que existe entre elas. Uma boa modelagem

deve estar embasada nos requisitos dos usuários e deve ser consistente. Pois, é no

banco de dados onde serão armazenadas todas as informações vitais para a

organização, e futuros problemas no banco de dados poderiam ser eliminados em uma

modelagem bem feita.

Com o desenvolvimento de uma análise consistente e que busque atender asnecessidades dos stakeholders o produto final irá atingir o seu principal objetivo, que é

o de agregar valor a empresa. De modo que os benefícios trazidos pelo sistema

desenvolvido justifiquem os investimentos feitos pela mesma.



17

1.7 METODOLOGIA

“O método substituiu os mitos, as religiões, pela racionalidade, pela lógica, pela

objetividade, a fim de captar e manipular uma realidade a partir de uma baseexperimental.” (PÁDUA, 2004, p.26)

Através do método a ciência pode evoluir com alicerces firmes, utilizando-se de

técnicas que possibilitaram a obtenção de conhecimentos neutros sobre a realidade.

(PÁDUA, 2004)

1.7.1 Métodos de Abordagem

O estudo adota o método qualitativo, pois foi desenvolvido em contato direto e

interativo com o objeto de estudo que é a empresa. Também foi realizado um relato

sobre a situação da mesma, sua história e o seu papel na economia local,

caracterizando a pesquisa como histórico-cultural. (MARCONI, LAKATOS, 2006).

1.7.2 Métodos de Procedimentos

A pesquisa quanto seus procedimentos pode ser classificada como exploratória

explicativa. Exploratória, pois envolve uma entrevista com funcionários da empresa,

buscando obter informações sobre o problema, além de aprimorar conceitos sobre

negócio e administração, e explicativa, pois foi analisada e registrada, interpretando os

fenômenos e procurando identificar seus fatores determinantes. (GÜLLICH, LOVATO,

EVANGELISTA, 2007). Também foi de cunho bibliográfico, pois estará fundamentada

em obras escritas que serão usadas como referências no estudo. (MARCONI,

LAKATOS, 2006).

1.7.3 Técnicas

Foi feita uma entrevista com o responsável pela empresa para adquirir

informações necessárias sobre a sua situação e organização. Segundo Lakatos e



18

Marconi (2006, p.88), trata-se de uma pesquisa observacional, pois os dados serão

identificados e analisados, classificando-os de acordo com seu papel na empresa.

1.8 CRONOGRAMA

O projeto segue o seguinte cronograma, que teve início no mês de março à

julho de 2009 observando-se nele as atividades propostas e realizadas conforme o

Quadro 1.

A primeira linha indica os meses de duração do projeto, de março à julho

de 2009.

A primeira coluna referencia cada uma das fases de desenvolvimento

apresentadas no item 1.6 (metodologia) e reproduzida no Quadro 1. Os

asteriscos indicam os meses em que cada fase será desenvolvida.

Nos quadros que tiverem *, significa o cronograma previsto e os quadros

que forem sombreados representam o cronograma executado.

Fases do ProjetoMeses- 2009

A g o s t o

S e t e m b r o

O u t u b r o

N o v e m b r o

D e z e m b r o

Hipóteses do Projeto * *Elaboração do Projeto * *

Entrega do Projeto *Fundamentação Teórica de Teoria

Econômica* * * *

Fundamentação Teórica de AOO * * * *Fundamentação Teórica de BD * * * *

Entrega do Relatório e Artigo Parcial *Entrega do Relatório e Artigo Final *

Apresentação da Prática *

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Quadro 1: Cronograma de Atividades do Projeto.



19

1.9 RECURSOS

Professores Orientadores.

Laptops Pessoais.

Pen Drive.

Livros.

Impressora.

Folhas de tamanho A4.

Microsoft Office 2007.

CASE Studio.

JUDE/Community.

1.10 ORÇAMENTO

Observaram-se as seguintes despesas relacionadas ao desenvolvimento do

projeto no Quadro 2.

Mês Transporte Alimentação Impressões eencadernações CDs

Julho R$ 60,00 R$ 80,00 R$ 0,00 R$ 0,00Agosto R$ 60,00 R$ 80,00 R$ 0,00 R$ 0,00

Setembro R$ 60,00 R$ 80,00 R$ 4,00 R$ 0,00Outubro R$ 60,00 R$ 80,00 R$ 6,00 R$ 0,00

Novembro R$ 60,00 R$ 80,00 R$ 90,00 R$ 5,00Dezembro R$ 60,00 R$ 80,00 R$ 0,00 R$ 0,00

Total: R$ 945,00

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Quadro 2: Orçamento do projeto.



CAPÍTULO 2: FUNDAMENTAÇÃO TEÓRICA

Neste capítulo apresenta-se todo o embasamento teórico empregado na

realização do trabalho.

2.1 PRESTAÇÃO DE SERVIÇOS

Partindo de um pressuposto geral, a prestação de serviços está diretamente

ligada ao produto oferecido pela empresa ao mercado consumidor. A prestação de um

serviço é reconhecida como uma atividade comercial, e que geralmente não se

apresenta de forma concreta (HARGREAVES; ZUANETTI; LEE et al., 2001).

Serviço pode ser descrito como o resultado de ao menos uma atividade

comercial realizada entre fornecedor e cliente, sendo geralmente intangível

(HARGREAVES; ZUANETTI; LEE et al., 2001).

Os serviços podem ser classificados em bens tangíveis e intangíveis. Toma-se

como exemplo o caso do estúdio de gravação, onde CDs, equipamentos de gravação e

computador, são usados como meio para produzir o produto final, que é o CD master.

Todos esses bens palpáveis são considerados tangíveis. Entretanto, o serviço de

gravação, de mixagem e de masterização são considerados intangíveis pois são

percebidos pelos clientes, mas não são produtos em si (HARGREAVES; ZUANETTI;

LEE et al., 2001).



21

2.2 TEORIA ECONÔMICA

Para Rossetti (1991) a Teoria Econômica é um sistema que possui leis e teorias

comprovadas cientificamente e que vão de acordo com a coerência, consistência eobjetividade. A Teoria Econômica pode ser dividida em Análise Microeconômica e

Análise Macroeconômica.

2.2.1 Conceito de Economia

Para Umbreit, Hunt e Kinter (1957 apud ROSSETTI, 1991, p.57) “A economia é

o estudo da organização social através da qual os homens satisfazem suas

necessidades de bens e serviços escassos.”

A Economia é a ciência que se preocupa com o estudo das leis econômicasindicadoras do caminho que deve ser seguido para que seja mantida em nívelelevada a produtividade, melhorando o padrão de vida das populações eempregados corretamente os recursos escassos (SAMUELSON, 1973 apud ROSSETI, 1991, p.57).

E para Barre (1970 apud ROSSETTI, 1991, p.57) a economia é:

[...] a ciência voltada para a administração dos escasso recursos dassociedades humanas: ela estuda as formas assumidas pelo comportamentohumano na disposição onerosa do mundo exterior em decorrência da tensãoexistentes entre os desejos ilimitados e os meios limitados aos agentes daatividade econômica.

2.2.2 Sistemas Econômicos

Os sistemas econômicos podem estar divididos em microeconomia e

macroeconomia. A Microeconomia, para Vasconcellos e Garcia (1998, p.30), analisa a

economia relacionada as relações entre empresa e consumidor, preços de produtos e

serviços, bem como a demanda destes.

Já a Macroeconomia, de acordo com Vasconcellos; Garcia (1998, p.83), faz

uma análise mais generalizada da economia, buscando entender o comportamento de



22

um conjunto maior, como uma economia nacional, desempenho de um país na

indústria, taxas de juros.

2.2.3 Moeda

Para Vasconcellos e Garcia (1998, p.133), “Moeda é um instrumento ou objeto

que é aceito pela coletividade para intermediar as transações econômicas, para

pagamento dos bens, serviços e fatores de produção .”

Ainda segundo Vasconcellos e Garcia (1998), antes das moedas, as pessoas

faziam troca de produtos, o que causava muitos problemas. Com o tempo, alguns

produtos passaram a ser aceitos por todos nas trocas, por serem mais escassos.

Depois os metais preciosos começaram a ser utilizados nas transações, e as moedas

passaram a ser utilizadas, estas que eram por sua vez cunhadas pelos governos, para

manter o controle.

Vasconcellos e Garcia (1998) afirmam que o papel moeda surgiu de um sistema

muito semelhante ao bancário, onde as pessoas depositavam metais preciosos e

recebiam certificados de depósito. Com o passar do tempo os ourives, que recebiam osdepósitos, passaram a emitir certificados sem lastro. Com a criação dos Estados, cada

um se encarregou de fazer o seu papel-moeda, lastreado por ouro. Com a quantidade

de ouro limitada os Estados passaram a emitir papel-moeda livremente, sendo a moeda

aceita pela força da lei.

2.2.4 Inflação

“A inflação é definida como um aumento persistente e generalizado no índice de

preços, ou seja, os movimentos inflacionários são aumentos contínuos de preços, e não

podem ser confundidos com altas esporádicas de preços [...].” (VASCONCELLOS;

GARCIA, 1998, p.181)



23

De acordo com Rossetti (1982), a inflação pode ser considerada um fenômeno

de abrangência macroeconômica. A principal característica dela é a alta dos preços de

todos os produtos e serviços, sendo que a alta de apenas alguns produtos não

caracteriza inflação.

2.2.5 Demanda

De acordo com Vasconcellos e Garcia (1998, p.37) “A demanda ou procura

pode ser definida como a quantidade de um determinado bem ou serviço que os

consumidores desejam adquirir em determinado período de tempo.”

Para Vasconcellos e Garcia (1998, p.37), a escolha do consumidor vai

depender das seguintes variáveis: “o preço do bem ou serviço, o preço dos outros bens,

a renda do consumidor e o gosto ou preferência do indivíduo.”

Segundo Vasconcellos e Garcia (1998), uma das variáveis que afeta a

demanda de um bem é descrita pela Lei Geral da Demanda, onde quanto maior for a

quantidade demandada menor será o preço e o contrário também é verdadeiro. Isso

significa, por exemplo, que um consumidor ao ver o preço de algum produto se elevarele buscará substituí-lo por outro produto. Além disso, quando o preço de um produto

sobe o poder aquisitivo do consumidor diminui e consequentemente a demanda pelo

produto também.

2.2.6 Orçamento

Para Hoji (2007), uma empresa é um sistema de geração de lucros, aonde

partes como acionistas investem na empresa a fim de conseguirem ter retorno

financeiro. A empresa, para gerar lucro e caixa a longo prazo, deve ser munida de um

forte planejamento financeiro e controle das suas entradas e saídas no presente,

caracterizando assim o orçamento empresarial.

Para Hoji:



24

O orçamento geral retrata a estratégia de um conjunto integrado pororçamentos específicos, subdivididos em quadros auxiliares, onde estãorefletidas quantitativamente as ações e políticas da empresa, relativas adeterminados períodos futuros (2004, p. 384 apud HOJI, 2007, p. 130).

O objetivo dos orçamentos é representar, através de números, as políticas decompras, vendas, recursos humanos, produção, gastos, qualidade e tecnologia. Os

gerentes dos departamentos da empresa devem aplicá-los conforme os planos de

ação, acompanhando resultados e corrigindo falhas nos mesmos (HOJI, 2007).

Segundo Hoji (2007, p.131), o orçamento geral de uma empresa do ramo

industrial é composto dos seguintes orçamentos específicos:

a) orçamento de vendas;

b) orçamento de produção;

c) orçamento de matérias-primas;

d) orçamento de mão-de-obra direta;

e) orçamento de custos indiretos de fabricação;

f) orçamento de custo de produção;

g) orçamento de despesas gerais, administrativas e de vendas;

h) orçamento de capital;

i) orçamento de aplicações financeiras e financiamentos;

j) orçamento de caixa;

k) orçamento de resultado.

2.3 MATEMÁTICA FINANCEIRA

Segue abaixo o referencial sobre matemática financeira, que é ferramenta útil

na avaliação de alternativas de investimentos e financiamentos de bens de consumo.

2.3.1 Juros

Segundo Samanez (2002), dá-se o nome de juro a remuneração do capital

empregado durante um determinado período de tempo. Após o fim do prazo de



25

aplicação, esse capital tornar-se-á um valor denominado montante, que será igual ao

capital aplicado somado ao juro obtido com o período de aplicação.

A diferença entre o valor do montante (S) e a aplicação (P), serão os jurosganhos ou o rendimento do capital no período de tempo (SAMANEZ, 2002). Eis a

fórmula:

De acordo com Samanez (2002), os rendimentos desses juros são o produto de

uma taxa de juros estabelecida, multiplicada pelo valor principal. Segue a fórmula:

( )

()

Conforme a fórmula abaixo, pode-se obter uma relação para o montante,

igualando as duas expressões para o cálculo de juros (SAMANEZ, 2002).

( )

2.3.1.1 Juros Simples

Para Samanez (2002), em um regime de juros simples, os juros sempre incidem

sobre o capital inicial, ou seja, são calculados sobre o mesmo principal. O capital cresce

em sentido linear em relação ao tempo, não existindo capitalização dos juros no

período pois os mesmos não são incorporados ao principal para a base de cálculos dos

juros do período seguinte (SAMANEZ, 2002).

Segue abaixo a fórmula do cálculo do juro simples para o prazo de um período

único, aonde J (juro), P (aplicação) e i (taxa de juros) (SAMANEZ, 2002):



26

Quando o juro for calculado em um período maior de tempo, tem-se o

acréscimo de uma variável n para calcular o juro resultante (SAMANEZ, 2002). Abaixosegue a fórmula:

2.3.1.2 Juros Compostos

O regime de juros compostos é:

[...] o mais comum no dia-a-dia, no sistema financeiro e no cálculo econômico.Nesse regime os juros gerados a cada período são incorporados ao principalpara o cálculo dos juros do período seguinte. Ou seja, o rendimento gerado pelaaplicação será incorporada a ela, passando a participar da geração dorendimento no período seguinte; dizemos, então, que os juros são capitalizados(SAMANEZ, 2002, p. 15).

Portanto, juros compostos agregam valor ao principal a cada período

contabilizado, sendo tomado para o cálculo dos juros do período seguinte, também

popularmente chamado de juro sobre juro (SAMANEZ, 2002). No Quadro 3 há umcomparativo de juros simples e juros compostos:

Juros Simples Juros CompostosMês Rendimento Montante Rendimento Montante1 $ 1.000 X 0,2 = $ 200 $ 1.200 $ 1.000 X 0,2 = $ 200 $ 1.2002 $ 1.000 X 0,2 = $ 200 $ 1.400 $ 1.200 X 0,2 = $ 240 $ 1.4403 $ 1.000 X 0,2 = $ 200 $ 1.600 $ 1.440 X 0,2 = $ 288 $ 1.728

Fonte: SAMANEZ, 2002, p.15Quadro 3: Comparativo entre juros simples e juros compostos.

De acordo com Samanez (2002), em regime de juros compostos, o dinheiro

aumenta exponencialmente em progressão geométrica ao longo do tempo, pois os

rendimentos de cada período são somados ao saldo do período anterior para junto com

este, render novos juros. Ao contrário, juros simples crescem em sentido linear, pois os

juros somente são contabilizados sobre o valor inicial.



27

Segue abaixo a fórmula para o cálculo dos juros compostos, sendo: (S)

montante, (P) principal, (i) taxa e (n) para os períodos de tempo:

( )

2.3.2 Investimento

De acordo com Vasconcellos e Garcia (1998, p.124), “Investimento é o

acréscimo ao estoque de capital que leva ao crescimento da capacidade produtiva

(construções, instalações, máquinas etc.).”

Acrescentando, Rossetti (1982, p.675) diz que o investimento é “[...] o

acréscimo ao capital real da sociedade [...] ele resulta de uma abstenção do consumo

imediato em relação à renda gerada no período.”

2.3.3 Poupança

Segundo Vasconcellos e Garcia (1998, p.124), “A poupança é a parte residual

da renda nacional disponível, ou seja, a parcela da renda nacional que não é gasta em

bens de consumo.”

2.3.4 Custo

Rossetti (1982) afirma que os custos podem ser fixos ou variáveis. De acordo

com Rossetti (1982, p.302):

[...] os custos fixos incluem todas as formas de remuneração ou ônusdecorrentes da manutenção dos correspondentes recursos. E os custosvariáveis decorrem de todos os pagamentos dirigidos aos recursos que variamdiretamente em função do volume de produção da empresa.

“O custo fixo médio (CFMe) resulta da divisão do custo fixo total pelas

quantidades produzidas, para cada um dos diferentes níveis de produção admitidos.”

(ROSSETTI, 1982, p.305) Em outras palavras, quanto maior for a produção menor será



28

o valor de cada unidade de produto. O custo fixo médio pode ser dado pela fórmula

abaixo, onde CFT é o custo fixo total e q é a quantidade.

“O custo variável médio (CVMe) resulta da divisão do custo variável total pelas

quantidades produzidas, para cada um dos diferentes níveis de produção admitidos.”

(ROSSETTI, 1982, p.305) O custo variável médio pode ser descrito pela fórmula abaixo,

onde CVT é o custo variável total q é a quantidade.

“O custo total médio (CTMe) resulta da soma do custo fixo médio com o custo

variável médio.” (ROSSETTI, 1982, p.306) Sua fórmula pode ser visualizada abaixo,

onde CT é o custo total e q é a quantidade.

E o custo marginal, de acordo com Rossetti “É o custo em que a empresa

incorre para produzir uma unidade adicional.” (1982, p.309)

2.3.5 Contabilidade

Para Ribeiro (2002), “A Contabilidade é uma ciência que permite, através de

suas técnicas, manter um controle permanente do Patrimônio da empresa” (p.14).



29

Em outras palavras, a contabilidade vem para controlar tudo que envolve

finanças, patrimônio e movimentação financeira numa empresa, sendo instrumento para

o fornecimento de informações úteis para a tomada de decisões internas e externas da

empresa (MARION, 1998).

O patrimônio pode ser descrito como um conjunto de bens, direitos e

obrigações de uma pessoa, tanto física quanto jurídica, e que podem ser avaliados

monetariamente (RIBEIRO, 2002). Os bens podem ser materiais ou imateriais, e

compreendem tudo que a empresa possui, com finalidade de troca, uso ou consumo.

Direitos são todos os valores a receber de terceiros (clientes), como aluguéis a receber,

promissórias a receber e duplicatas a receber. E as obrigações, ao contrário dos

direitos, são os valores que a empresa deve a terceiros (fornecedores), como salários e

impostos a pagar (MARION, 1998).

2.3.6 Despesas

Para Ribeiro (2002):

As Despesas caracterizam-se pelo consumo de bens e pela utilização deserviços, objetivando a obtenção de Receita. Por exemplo: a energia elétricaconsumida, os materiais de limpeza consumidos (sabões, desinfetantes,vassouras, detergentes), o café consumido, os materiais de expedienteconsumidos (canetas, papéis, lápis, impressos etc.), a utilização de serviçotelefônico etc (RIBEIRO, 2002, p. 62).

As despesas por outro lado podem ser vistos como gastos, mas que tem como

finalidade a obtenção de receita, porém, não se identificam com o processo de

produção e transformação dos bens e dos produtos (RIBEIRO, 2002).

Na contabilidade é importante diferenciar despesa de custo. Custo está

relacionado diretamente com o processo de produtivo de bens e serviços enquanto que

a despesa caracteriza de uma forma genérica os gastos com a manutenção das

atividades da empresa (RIBEIRO, 2002).



30

2.3.7 Receitas

De acordo com Ribeiro (2002), as receitas são provenientes da venda dos bens

e da prestação de serviços. Existem menos receitas do que despesas, sendo maiscomuns as seguintes:

Vendas

Receitas de Serviços

Juros Ativos

Descontos Obtidos

Aluguéis Ativos.

Segundo Ribeiro (2002), para diferenciar as despesas das receitas são usados

adjetivos como Ativo e Passivo. Como exemplo tem-se uma conta de aluguéis, aonde a

conta aluguéis passivos representam despesa e a conta aluguéis ativos são

classificados como receita.

2.4 PLANEJAMENTO FINANCEIRO

A expressão planejamento tem em seu significado o ato de planejar, que

possibilita através do presente avaliar caminhos e construir um referencial para o futuro,

sendo o lado racional da ação. E financeiro é relacionado a finanças, a parte

administrativa, gestão de dinheiro e sua circulação. Em suma, é muito importante para oapoio de decisão e planos futuros da empresa. Um bom planejamento é a certeza de

que se encontrará êxito na operação pretendida, tanto para o planejamento numa

empresa como numa família (LUCION, 2005).



31

2.4.1 Fluxo de Caixa

2.4.1.1 Conceituação

Para Zdanowicz (1986, p.37) o fluxo de caixa “[...] é o instrumento de

programação financeira, que corresponde às estimativas de entradas e saídas de caixa

em certo período de tempo projetado.”

Essa ferramenta, de acordo com Zdanowicz (1986, p.24), visa “prognosticar a

necessidade de captar empréstimos ou aplicar excedentes de caixa nas operações

mais rentáveis para a empresa.”

De acordo com Zdanowicz (1986), estando ciente das entradas e saídas, o

administrador financeiro poderá planejar de forma eficiente quais as melhores formas

de captar recursos, programas os desembolsos, investir excedentes da empresa, evitar

acúmulos de compromissos em épocas com menos entradas de caixa, suprir

necessidades sazonais ou cíclicas da empresa.

Como consequência, segundo Zdanowicz (1986), haverá um equilíbrio entre asentradas e saídas de caixa, os recursos captados de terceiros diminui, boa

rentabilidade do capital aplicado, a rotação de estoque aumenta, há menor necessidade

de capital de giro.

2.4.1.2 Características

O fluxo de caixa tem como objetivo controlar as entradas e saídas da empresa,

e para que esse controle ocorra, de acordo com Zdanowicz (1986), é preciso saber querecursos estão ingressando no caixa e como eles são desembolsados.



32

Fonte: ZDANOWICZ, 1986.Figura 1: Esquema de entradas e saídas em um fluxo de caixa.

Como é possível visualizar na Figura 1, o fluxo de entradas no caixa pode ser

constituído de: vendas à vista e a prazo, que são fontes internas regulares; aumento de

capital social, participações em ativos do open-market , venda de algum ativo

imobilizado, que são fontes internas periódicas; e empréstimos de terceiros que são

fontes externas de recursos.

Já as saídas podem ser provenientes do: custo para a empresa operar (saídas

regulares), amortizações de empréstimos e financiamentos de terceiros (saídasperiódicas), e investimentos em ativos permanentes ou em ativos do open-market

(saídas irregulares).



33

2.4.1.3 Planejamento do Fluxo de Caixa

Zdanowicz (1986) exibe a seguinte fórmula para exprimir o fluxo de caixa

projetado:

Onde, SFC é o saldo final de caixa, SIC é o saldo inicial de caixa, I são os

ingressos e D os desembolsos.

De acordo com Zdanowicz (1986), a finalidade desta fórmula é mostrar se o

saldo final em caixa será positivo ou negativo. Se for positivo, possibilitará ao

administrador financeiro aplicar o excedente da melhor forma. Mas caso seja negativo,

ele terá de encontrar um meio de captação de recursos para suprir essa escassez em

caixa.

Zdanowicz (1986) ainda afirma que para elaboração de um fluxo de caixa são

necessárias as seguintes informações:

Projeção das vendas.

Estimativas das compras e condições de pagamento dadas pelos

fornecedores.

Valores a receber de clientes em compras a prazo.

Saber de quanto em quanto tempo será feito o fluxo do caixa.

Orçamento de outras entradas e saídas no período.

E para que a implantação do fluxo de caixa ocorra, segundo Zdanowicz (1986),

é preciso:

Haver apoio da cúpula da empresa.

Cada área da empresa deve ter suas responsabilidades definidas.



34

A forma como será feito o fluxo de caixa deve estar bem definida e todas

as áreas da empresa devem participar.

Os envolvidos com o fluxo de caixa devem estar comprometidos com as

metas.

O fluxo de caixa de antever os impactos de decisões nas finanças da

empresa.

2.4.1.4 Implantação do Fluxo de Caixa

Para Zdanowicz (1986, p.55), “A implantação do fluxo de caixa consiste em

apropriar os valores fornecidos pelas várias áreas da empresa [...] de acordo com os

períodos que efetivamente deverão ocorrer os ingressos e os desembolsos de caixa.”

Segundo Zdanowicz (1986), a essência do fluxo de caixa está no planejamento

das entradas e saídas que podem ser subdivididas em fluxo operacional e fluxo extra-

operacional.

O fluxo de caixa operacional, como assevera Zdanowicz (1986), corresponde à

atividade fim da empresa. Sendo os ingressos compostos de vendas à vista,recebimentos, desconto, caução. Já os desembolsos correspondem a compras de

matérias primas à vista e a prazo, salários e ordenados, custos indiretos de fabricação,

despesas administrativas, despesas com vendas, despesas financeiras e tributárias.

A depreciação do ativo imobilizado, segundo Zdanowicz (1986), está acoplada

ao custo de fabricação e também será usado para determinar o preço de venda do

produto ao consumidor final. Para Ross, Westerfield e Jordan (2000), a depreciação

não é incluída no cálculo do fluxo de caixa operacional, por esta não ser uma despesa

de caixa. Tampouco os juros, pois são despesas financeiras.

O fluxo de caixa extra-operacional, de acordo com Zdanowicz (1986), são as

entradas e saídas que não tem relação com a atividade fim da empresa, como:



35

imobilizações, aluguéis pagos ou recebidos, amortizações de empréstimos ou de

financiamentos, vendas de itens do ativo permanente, receitas financeiras.

As amortizações, segundo Zdanowicz (1986, p.60), “[...] compreendem ospagamentos de empréstimos ou de financiamentos de longo prazo, geralmente

contratados com garantias reais de bens dos sócios ou da empresa.”

E a projeção de imobilizações, de acordo com Zdanowicz (1986), deve ser feita

pela alta administração da empresa, pois envolve um grande investimento que só trará

retorno em longo prazo. Um mau planejamento pode colocar a empresa em

dificuldades financeiras, como falta de capital de giro. Obrigando o administrador

financeiro a buscar fontes alternativas de capital, como empréstimos, onde as

amortizações deverão ser pagas com capitais próprios em determinado período de

tempo. (ZDANOWICZ, 1986, p.60)

Ross, Westerfield e Jordan (2000, p.64) afirmam que o fluxo de caixa gerado

pelas atividades da empresa (fluxo de caixa dos ativos) deve servir para pagar seus

credores bem como seus acionistas ou donos.

De acordo com Ross, Westerfield e Jordan (2000), o fluxo de caixa dos ativos

se subdivide em fluxo de caixa operacional, gastos de capital e variação do capital de

giro líquido. Os gastos de capital correspondem a diferença entre os ativos

permanentes ao fim de um período somado a depreciação do mesmo. E a variação do

capital de giro líquido é o investimento da empresa em ativos circulantes.

O fluxo de caixa aos credores corresponde, segundo Ross, Westerfield e

Jordan (2000), ao pagamento de juros por empréstimos feitos. Enquanto que o fluxo de

caixa aos acionistas são os dividendos que são distribuídos aos acionistas da empresa.



36

2.4.1.5 Ciclo de Caixa

De acordo com Zdanowicz (1986), o fluxo de caixa pode ser considerado

cíclico, e o autor ainda o classifica em:

Regulares: ingressos e desembolsos regulares. Ex.: vendas à vista e a

prazo.

Razoavelmente regulares: ingressos e desembolsos que acontecem em

períodos iguais. Ex.: amortizações de financiamentos e empréstimos.

Irregulares: ingressos e desembolsos que ocorrem sem planejamento

prévio. Ex.: multas e compra de peças de reposição para máquinas.

Fonte: ZDANOWICZ, 1986, p.61.Figura 2: Ciclo de caixa.

Na Figura 2 está contemplado um exemplo simples do ciclo de caixa em uma

empresa. Através do caixa são efetuadas as compras de matéria-prima que serão

utilizados na produção de produtos. Com o caixa também são pagos todos os encargos

sociais e todos os custos atrelados a fabricação do produto. Depois de pronto, o

produto será vendido à vista ou a prazo, e os valores recebidos retornarão então ao

caixa da empresa.



37

Como Zdanowicz (1986) descreve, a empresa precisa manter um nível de

estoque que esteja de acordo com o fluxo de produção e vendas. As matérias-primas

são adquiridas normalmente a prazo, seus custos mais os custos gerados direta e

indiretamente na produção integram o custo do produto final. Este será vendido aosconsumidores à vista ou a prazo.

O ciclo econômico, de acordo com Zdanowicz (1986, p.63), é o “[...] prazo

decorrido entre as entradas de matérias-primas (compras) e as saídas de produtos

prontos (vendas) [...]” E o ciclo financeiro é o “[...] prazo decorrido entre os desembolsos

de caixa e os ingressos de caixa.” (ZDANOWICZ, 1986, p.63)

O ciclo financeiro pode ser expresso pela seguinte fórmula:

Onde, CF é o ciclo financeiro, CE é o ciclo econômico, PMR é o prazo médio de

recebimentos e PMP é o prazo médio de pagamentos.

2.4.1.6 Modelo de Fluxo de Caixa

Na Figura 3 é possível visualizar um exemplo de fluxo de caixa. A tabela possui

dispostas todas as entradas e saídas que ocorrem em determinado período. “Quanto

mais especificado for o fluxo de caixa, melhor será o controle sobre as entradas e as

saídas de caixa, verificando assim as suas defasagens e determinando as medidas

corretivas ou saneadoras para os períodos subsequentes.” (ZDANOWICZ, 1986, p.64)

Para Zdanowicz (1986), além do fluxo de caixa, o administrador financeirodeverá elaborar mapas auxiliares para: vendas a prazo, compras a prazo, despesas

tributárias, despesas financeiras.

No modelo da Figura 3, é possível notar que cada período possui três colunas.

A primeira coluna corresponde ao projetado, ou seja, aquilo que se esperava ter saído



38

ou entrado. Na segunda coluna está o realizado, que é aquilo que de fato entrou e saiu.

E na terceira coluna está a defasagem, negativas ou positivas, que devem ser

analisadas pelo administrador financeiro para descobrir as causas desse resultado e

como reverter a situação nos próximos períodos.

Fonte: ZDANOWICZ, 1986, p.64

Figura 3: Modelo de Fluxo de Caixa.

Segue abaixo a descrição dos itens do fluxo de caixa, de acordo com

Zdanowicz (1986):



39

1. Ingressos: são as entradas no caixa e podem ser: vendas à vista ou a

prazo (utilizando mapas auxiliares de recebimentos), recebimentos com

atraso, aumento de capital social, venda de itens do ativo permanente.

2. Desembolsos: são as saídas no caixa e podem ser: compras à vista ou aprazo (utilizando mapas auxiliares de pagamentos), despesas

operacionais e compra de algum ativo permanente.

3. Diferença do período: é a diferença entre os ingressos e os desembolsos

do caixa de dado período.

4. Saldo inicial de caixa: saldo final de caixa do período anterior.

5. Disponibilidade acumulada: a soma das entradas e saídas mais o saldo

inicial de caixa.6. Nível desejado de caixa: é o capital de giro que a empresa vai precisar,

levando em conta as projeções das entradas e saídas.

7. Empréstimos ou aplicações de recursos financeiros: quando a

disponibilidade acumulada for baixa, será preciso captar recursos através

de financiamentos e empréstimos de terceiros. E quando houver um

excedente, este poderá ser aplicado no mercado aberto.

8. Amortizações e resgates das aplicações: “amortizações são as

devoluções do principal, tomado emprestado, enquanto os resgates das

aplicações constituem-se no recebimento do principal.” (p.66)

9. Saldo final de caixa: quanto de caixa se deseja ter para o período

seguinte.

2.4.1.7 Controle de Caixa

De acordo com Zdanowicz (1986), existe grande importância em se controlar ocaixa ocorrido e comparar com o projetado diariamente, possibilitando a tomada de

decisões que revertam alguma situação indesejada, além de facilitar a elaboração do

fluxo de caixa do período seguinte.



40

O fluxo de caixa consiste basicamente “[...] em coletar ao final de cada período,

as estimativas de ingressos e de desembolsos de recursos financeiros que comporão o

fluxo de caixa para o período subsequente desejado.” (ZDANOWICZ, 1986, p.91)

Além disso, de acordo com Zdanowicz (1986), é preciso fazer todo o controle

das entradas e saídas da empresa, a fim de verificar se as expectativas estão de

acordo com a realidade da empresa. Cabe ressaltar ainda, que todas as operações

realizadas pela empresa devem ser comprovadas através de documentos.

O controle do fluxo de caixa pode ainda, para Zdanowicz (1986), ter uma

abrangência a curto prazo e longo prazo. A curto prazo busca-se detalhar precisamente

as entradas e saídas de caixa, a fim de minimizar custos. Enquanto que a longo prazo é

a uma projeção menos detalhada, que busca resumir as entradas e saídas da empresa,

pois tem uma finalidade mais administrativa que não necessita de detalhes mínimos

(ZDANOWICZ, 1896)

Para Zdanowicz (1986), o fluxo de caixa deve ser usado com um auxiliar na

tomada de decisões. Através dele é possível apurar as causas de problemas na

empresa e buscar soluções para os mesmos. Também é importante ter o envolvimentode todos os responsáveis pelas áreas da empresa, para que estes concentrem seus

esforços nas metas traçadas para o próximo período.

2.4.2 Regime de Caixa, Regime de Competência e Livro Caixa

No regime de caixa são apenas consideradas as operações que de fato

ocorreram no período, ou seja, quando foi realizado o desembolso. Este regime é

utilizado por pessoas físicas, mas pode também ser usado por pessoas jurídicas em

contratos a longo prazo e contratos governamentais, por exemplo. (YOUNG, 2008)

Enquanto que no regime de competência as operações são registradas nos

períodos em que ocorrem, independente de terem ou não sido feitos os desembolsos.

(YOUNG, 2008)



41

Por fim, “[...] o Livro Caixa tem a função de controlar o fluxo de caixa – a

entrada e a saída de dinheiro – através do registro de todos os débitos e créditos

ocorridos naquela conta.” (AUTRAN; COELHO, 2003, p.65)

2.5 ANÁLISE ORIENTADA A OBJETOS

Nas próximas seções estão dispostos os conceitos básicos da análise de

sistemas, as características e conceitos do paradigma da orientação a objetos e os

métodos de análise orientada a objetos, em especial a UML, que foi amplamente

utilizado neste trabalho.

2.5.1 Análise de Sistemas

De acordo com Yeates e Wakefield (2004), a análise de sistemas consiste em

dividir o sistema da empresa em partes, que são os subsistemas que trabalham juntos

para fazer o funcionamento do negócio, para que se possa estudar e interpretar o

sistema da melhor forma possível.

Yeates e Wakefield (2004, p.132) acrescentam que:

Before designing a computer system that will satisfy the information requirements of a company, it is important that the nature of the business and the way it currently operates are clearly understood. The detailed examination will then provide the design team with the speci fi c data they require in order to ensure that all the client’s requirements are fully met.

Segundo Pressman (2006), os principais objetivos da análise de requisitos são

os de descrever as exigências dos clientes, prover uma base para um projeto de

software e definir requisitos que poderão ser validados na construção do software.

Depois de definidos os requisitos dos usuários, segundo Yeates e Wakefield

(2004), é preciso especificar a plataforma técnica e o caminho a ser seguido na fase do

desenvolvimento. A importância da documentação está na possibilidade de se medir a

performance do projeto bem como ter um controle de modificações realizadas.



42

De acordo com Pressman (2005), a análise de sistemas deve estar focada nos

requisitos visíveis no problema e não deve se apegar aos mínimos detalhes. Além

disso, os modelos criados devem ser úteis para a análise, ou seja, eles devem fornecer

uma visão que facilite o entendimento do sistema. E quanto mais simples forem osmodelos, melhor será a compreensão do sistema, não há motivos para adicionar

diagramas que não acrescem informações ao modelo.

2.5.2 Análise Orientada a Objetos

A orientação a objetos foi criada para suprir as necessidades existentes nas

fases de desenvolvimento de softwares e que não eram completamente supridas pela

análise estruturada. A análise orientada a objetos traz um novo paradigma, que condiz

muito mais com o mundo real.

2.5.2.1 História

Em 1962 foi iniciado o projeto da linguagem de programação Simula, criada por

Ole-Johan Dahl e Kristen Nygaard. Com essa linguagem surgiram os conceitos de

classes (com atributos e métodos), encapsulamento e herança. A partir dessalinguagem surgiu SmallTalk, a primeira linguagem totalmente orientada a objetos.

(MELO, 2004)

Uma década depois do surgimento das primeiras linguagens orientadas a

objetos, segundo Melo (2004), começaram a surgir metodologias para a orientação a

objetos, hoje conhecidas como análise orientada a objetos.

“Análise Orientada a Objetos consiste em definir quais objetos fazem parte de

um sistema e a maneira como se comportam.” (CORREIA, TAFNER, 2006, p.8)

Bezerra (2002, p.5) destaca os princípios da orientação a objetos, estabelecidos

por Alan Kay:



43

1. Qualquer coisa é um objeto.2. Objetos realizam tarefas através da requisição de serviços a outros objetos.3. Cada objeto pertence a uma determinada classe. Uma classe agrupa objetos

similares.4. A classe é um repositório para comportamento associado ao objeto.

5. Classes são organizadas em hierarquias.

A maior vantagem da orientação a objetos está na junção dos dados e

processos em um único conjunto, mostrando como os processos estão lidando com os

dados. (CORREIA, TAFNER, 2006)

Outras vantagens da orientação a objetos, de acordo com Melo (2004), estão

na padronização dos modelos em todas as fases do projeto, além disso, vários modelos

são utilizados para ilustrar o mesmo sistema em diferentes ângulos de visão.

Ainda sobre as idéias de Melo (2004), na orientação a objetos os dados passam

a ser tratados de forma diferenciada, estando estes protegidos pelo encapsulamento. A

compreensão dos modelos orientados a objetos é muito melhor, pois a linguagem

utilizada se aproxima muito da realidade, isso torna a comunicação entre desenvolvedor

e usuário muito mais fácil.

Como consequência dessas mudanças trazidas com a orientação a objetos, aprodutividade aumenta, os gastos em dinheiro e tempo no desenvolvimento são

reduzidos e a manutenção é muito mais fácil. É possível reutilizar códigos, como

classes que, se bem escritas, não precisam ser refeitas do zero em um novo sistema.

(MELO, 2004)

No próximos tópicos estão dispostos os conceitos da orientação a objetos, que

são: classes, objetos, mensagens, encapsulamento, herança e polimorfismo.

2.5.2.2 Classes, Objetos e Mensagens

Um objeto é algo do mundo real, com existência própria, podendo ser concreto

ou abstrato. Os objetos possuem atributos, que são as suas características, que por

sua vez diferenciam um objeto do outro. (MELO, 2004)



44

Melo (2004) afirma ainda que os objetos possuem métodos, que são as

operações que um objeto pode executar. Os métodos de uma classe de objetos só

podem modificar dados de sua classe.

Objetos semelhantes são agrupados em classes. “Uma classe é uma descrição

dos atributos e serviços comuns a um grupo de objetos. Sendo assim, pode-se

entender uma classe como sendo um molde a partir do qual objetos são construídos.

[...] um objeto é uma instância de uma classe.” (BEZERRA, 2002, p.7)

Para que haja interação entre objetos, de acordo com Bezerra (2002), é feita a

troca de mensagens. Objetos trocam mensagens entre si para poderem realizar

determinada tarefa no sistema, requisitando serviços uns aos outros.

2.5.2.3 Encapsulamento

Um objeto não pode acessar as operações de outro objeto, muito menos

modificar seus dados, ele apenas pode requisitar a realização de uma tarefa ao objeto,

isso é encapsulamento. Para que um objeto possa acessar os métodos de outro ele irá

utilizar a interface deste objeto. A interface serve para que o objeto requisitante saiba oque o outro objeto pode fazer e quais dados ele possui. (BEZERRA, 2002)

Além disso, segundo Bezerra (2002), a forma como a interface é implementada

não tem importância para o objeto que requisitou algo. E para este objeto pouco

importa como os métodos foram implementados, pois ele apenas precisa que a tarefa

seja executada.

2.5.2.4 Herança

Na orientação a objetos, para Bezerra (2002), as classes podem estar

agrupadas em hierarquia. Sendo que as classes de um nível irão herdar as

características e operações das classes dos níveis acima. De acordo com Melo (2004),

a classe mais genérica pode ser chamada de superclasse, enquanto que a mais



45

específica é chamada de subclasse. Este é o conceito de generalização e

especialização.

2.5.2.5 Polimorfismo

De acordo com Melo (2004), uma subclasse pode implementar um método de

forma diferente de sua superclasse, sendo que o método da subclasse prevalecerá.

Mas a quantidade e tipo de atributos bem como o tipo de resultado devem ser iguais

aos do método da superclasse.

2.5.3 UML

A UML tem sido padrão industrial nos últimos 10 anos na visualização,

especificação, construção e documentação de sistemas de software dos mais diversos

segmentos.

2.5.3.1 História

Segundo Melo (2004), com a introdução da orientação a objetos, uma grande

quantidade de métodos começaram a surgir. O problema era que boa parte deles

estendiam métodos estruturados. Além disso, com tantas opções de métodos era difícil

escolher um para utilizar.

De acordo com Booch, Rumbaugh e Jacobson (2005), alguns métodos

começaram a ganhar destaque. Entre estes métodos estavam o Booch, OOSE e OMT,

eles possuíam pontos fortes distintos, e fatias diferentes de mercado. Na década de 90,

os principais métodos começaram a seguir rumos semelhantes, o que culminaria naunificação dos métodos.

A unificação começou em 1994, quando Rumbaugh se uniu a Booch na

Rational Software, o que resultou no Método Unificado 0.8. Com o ingresso de

Jacobson o modelo OOSE foi incorporado e a versão 0.9 do Método Unificado foi



46

lançada, chamada agora de UML (Unified Modeling Language ). (MELO, 2004). Na

Figura 4 é possível visualizar os principais contribuintes para a formação da UML.

Segundo Booch, Rumbaugh e Jacobson (2005), em 1997 foi lançada a versão1.0 para submissão a OMG (Object Management Group ) para padronização. No mesmo

ano o grupo ganhou novos participantes e colaboradores. Eles produziram a versão 1.1

da UML e submeteram a OMG, que a adotou como padrão no mesmo ano. Atualmente

a UML está na versão 2.0, que incluí grande quantidade de características além da

versão 1.

Fonte: QUATRANI, 2001, p.4Figura 4: Contribuições a UML.

2.5.3.2 Conceitos

Segundo Melo (2002, p.32), UML “é uma linguagem para especificação,

visualização, construção e documentação de artefatos de sistemas de software.” E



47

segundo Bezerra (2002, p.14), ela “é uma linguagem visua l para modelar sistemas

orientados a objetos.”

Aprofundando o que disse Melo, Booch, Rumbaugh e Jacobson (2005)explicam as características da UML:

Visualização: os modelos são padronizados, o que facilita a comunicação

entre as pessoas, os modelos podem ser tanto gráficos como textuais.

Especificação: construção de modelos precisos, sem ambiguidade e

completos.

Construção: os modelos podem se conectar a linguagens de

programação, bancos de dados relacionais e orientados a objetos. Ainda

é possível gerar códigos através dos modelos e o contrário também é

possível.

Documentação: requisitos, arquitetura, projeto, código fonte, testes,

protótipos, versões. Tudo isso é documentado através da UML, além do

planejamento das atividades do projeto e controle de versões.

Com a UML é possível modelar todas as visões de um sistema através dosdiversos diagramas por ela fornecidos. Cada representação gráfica tem seu significado

e também uma forma de ser utilizada. A utilização de gráficos padronizados facilita a

compreensão dos gráficos bem como a comunicação com os usuários. (BEZERRA,

2002)

Além da comunicação facilitada entre usuários e analistas, de acordo com

Gornik (2005), com a UML a comunicação entre membros de grupos é mais fácil, bem

como a integração a repositórios, o formato de entrada e saída é padronizado além de

haver uma representação unificada para qualquer ciclo de um projeto.

Essas vantagens atribuídas a UML se devem, em parte, a padronização da

linguagem que possui um vocabulário e também regras que definem como as palavras

do vocabulário devem estar organizadas para permitir a comunicação.



48

Segundo Booch, Rumbaugh e Jacobson (2005), o vocabulário e as regras de

uma linguagem de modelagem devem focar a representação conceitual e física de um

sistema. Eles ainda afirmam que apenas um modelo do sistema não é suficiente, pois

são precisos vários modelos com visões diferenciadas do sistema e que se conectemuns aos outros.

Essas visões diferenciadas, segundo Bezerra (2002), podem estar divididas em

cinco perspectivas:

Visão de Casos de Uso: é o ponto de partida para as outras visões do

sistema, mostra as interações entre o sistema e com agentes externos a

ele.

Visão de Projeto: são as características básicas do sistema, estruturais e

comportamentais.

Visão de Implementação: é o controle das versões do sistema.

Visão da Implantação: é onde o sistema estará localizada fisicamente,

quais componentes farão parte do sistema, com quem o sistema irá se

comunicar.

Visão de Processo: em relação ao paralelismo, sincronismo e

desempenho do sistema.



49

Fonte: BEZERRA, 2002, p.16.Figura 5: Visões de um sistema de software.

2.5.3.3 Elementos Básicos

De acordo com Booch, Rumbaugh e Jacobson (2005) existem três tipos de

elementos básicos:

1. Objetos

2. Relacionamentos

3. Diagramas

Os objetos se dividem em quatro tipos, segundo Booch, Rumbaugh e Jacobson

(2005), sendo eles:

1. Objetos Estruturais: partes estáticas de um modelo, que representam

objetos conceituais ou físicos. São eles: classes, interfaces,colaborações, casos de uso, classes ativas, componentes.

2. Objetos Comportamentais: partes dinâmicas de um modelo, que

representam comportamentos no espaço e tempo. São eles: interações,

estado da máquina, ações.



50

3. Objetos de Agrupamento: partes organizacionais de um modelo, que são

caixas onde os modelos podem ser decompostos. Fazem parte deste

grupo pacotes.

4. Objetos de Anotação: partes de um modelo que são responsáveis pelaexplicação de algo, ou seja, são anotações. Deste grupo fazem parte as

notas.

Os relacionamentos também se dividem em quatro tipos para Booch,

Rumbaugh e Jacobson (2005), sendo eles:

1. Dependência

2. Associação

3. Generalização

4. Realização

Os diagramas da UML serão abordados na próxima seção de modo mais

generalizado, e nas seções consequentes estarão apresentadas em maiores detalhes.

2.5.3.4 Diagramas da UML

Segundo Melo (2004), na UML 2.0 existe treze tipos de diagramas, sendo estes

classificados em diagramas estruturais e diagramas dinâmicos. O primeiro tem por

objetivos mostrar características imutáveis do sistema. Enquanto que o segundo mostra

as reações do sistema a requisições e sua evolução no tempo. O Quadro 4 exibe todos

os diagramas da UML agrupados de acordo com sua classificação.



51

Diagramas Estruturais

Diagrama de ClassesDiagrama de ObjetosDiagrama de ComponentesDiagrama de PacotesDiagrama de ImplantaçãoDiagrama de Estrutura Composta

Diagramas Dinâmicos

Diagrama de Casos de UsoDiagramas de Interação:

Diagrama de Visão Geral Diagrama de Sequências Diagrama Temporal Diagrama de Comunicação

Diagrama de AtividadesDiagrama de Máquina de Estados

Fonte: MELO, 2004, p.43.

Quadro 4: Diagramas da UML.

Neste estudo somente seis diagramas foram utilizados, pois as necessidades e

complexidade do problema abordado neste trabalho não necessitaram de todos os

diagramas oferecidos pela UML para representar uma solução viável. Estes diagramas

utilizados estão dispostos nas próximas seções.

2.5.3.4.1 Diagrama de Casos de Uso

Para Bezerra (2002, p.46) “Um caso de uso [...] é a especificação de uma

sequência de interações entre um sistema e os agentes externos que utilizam esse

sistema.” Casos de uso descrevem a ordem perfeita dos acontecimentos dentro de um

caso de uso, bem como comportamentos divergentes. (MELO, 2004)

Os casos de uso podem ser classificados em primários e secundários. Casos

de uso primários são aqueles que envolvem diretamente o que será automatizado na

empresa. Enquanto que casos de uso secundários não trazem benefícios diretos àempresa, mas ainda assim são necessários para que o sistema funcione. (BEZERRA,

2002)

A forma como são representados graficamente os casos de uso, atores e seus

relacionamentos pode ser vista em detalhes na Figura 6. Além da representação



52

gráfica, é preciso ainda elaborar uma descrição detalhada de cada um dos casos de

uso detectados. Isso proporciona uma melhor compreensão dos casos de uso do

sistema e facilita a construção de outros diagramas da UML.

Através de uma descrição detalhada é possível tomar conhecimento dos

envolvidos no caso de uso, quais os passos do fluxo principal, as exceções que podem

ocorrer e outros casos de uso incluídos no fluxo. (HAMILTON; MILES, 2006)

A descrição dos casos de uso não tem um padrão, abaixo estará disposta uma

lista de itens que podem ser documentados, seguindo Bezerra (2002):

1. Nome do caso de uso.

2. Identificador, um código que identifique o caso de uso.

3. Importância do caso de uso.

4. Sumário, pequena descrição do caso de uso.

5. Ator Primário, aquele que inicia o caso de uso.

6. Atores Secundários, outros atores que participem do caso de uso.

7. Pré-condições para que o caso de uso aconteça.

8. Fluxo Principal são os passos que ocorrem em um cenário perfeito.9. Fluxos Alternativos são as tomadas de decisões diferentes das do fluxo

principal, tomadas pelos atores para alcançar o objetivo.

10.Fluxos de Exceção são os acontecimentos inesperados que podem vir

a ocorrer na interação entre caso de uso e atores.

11.Pós-condições, como deve ser o estado do sistema depois de efetuada

a tarefa.

12.Regras de Negócio

13.Histórico

14.Notas de Implementação sobre como o caso de uso pode ser

implementado.

Para interagir com os casos de uso existem os atores, que farão isso através de

mensagens, que serão as relações entre caso de uso e ator. O ator pode ter o papel de



53

uma pessoa, dispositivo de hardware ou outro sistema. (BOOCH; RUMBAUGH;

JACOBSON, 2005)

Os relacionamentos entre casos de uso e atores é dado através da associação.Existem ainda relacionamentos entre casos de uso (generalização, extensão e

inclusão) e entre atores (generalização). (MELO, 2004)

Na associação, de acordo com Melo (2004), existe o relacionamento binário, ou

seja, de um lado um ator e de outro um caso de uso. Esse relacionamento significa que

há comunicação através do envio e recebimento de mensagens.

Na generalização, segundo Bezerra (2002), existe a ligação entre atores ou

entre casos de uso. Casos de uso ou atores semelhantes podem estar ligados

hierarquicamente, sendo que os de níveis mais baixos terão especialidades em relação

ao de nível mais alto.

A extensão entre casos de uso quer dizer que um caso de uso poderá ter uma

exceção que fuja do fluxo principal, e em consequência irá incluir um outro caso de uso

neste caso (MELO, 2004). Para Bezerra (2002), um caso de uso só será estendido sehouverem as condições certas para que ela ocorra, o que vai depender do ator.

A inclusão, de acordo com Bezerra (2002), é a inclusão de um caso de uso

dentro de algum passo do fluxo principal de outro caso de uso. É uma forma se

empacotar uma rotina em outro caso de uso que pode ser chamado por outros casos

de uso. Com isso, se ganha em manutenção, o entendimento é mais claro e evita-se a

redundância.

Na Figura 6 é possível visualizar um exemplo de diagrama de caso de uso de

uma locadora. Os atores são representados por bonecos, os casos de uso por elipses

com o nome do caso de uso dentro. As associações são feitas por ligações simples

entre ator e caso de uso, enquanto que extensões e inclusões são representadas por

setas pontilhadas, alternando somente a direção da seta e o estereótipo identificador.



54

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Figura 6: Exemplo de Diagrama de Casos de Uso.

Ainda na Figura 6, é possível notar a generalização que há de atendente e

gerente para funcionário. Sendo que os dois primeiros irão herdar todas as

características e operações do último. Em uma Devolução de Título, caso haja atraso é

estendido o caso de uso Geração de Multa. Na Locação de Título está incluída a

Validação de Clientes, ou seja, toda vez que um cliente for retirar um título ele precisa

ter seu cadastro validado para pode retirar o título.

Em sistemas maiores é possível utilizar pacotes para agrupar casos de uso, o

que torna o diagrama mais organizado e facilita a visualização. Um pacote podeagrupar não somente casos de uso, mas também classes, estados e outros pacotes.

(MELO, 2004)



55

2.5.3.4.2 Diagrama de Classes

“Um diagrama de classes é um diagrama que mostra um conjunto de classes,

interfaces, e colaborações e seus relacionamentos. Graficamente, um diagrama declasses é uma coleção de vértices e arcos.” (BOOCH; RUMBAUGH; JACOBSON, 2005,

Cap. 8)

Segundo Booch, Rumbaugh e Jacobson (2005), diagramas de classe são

usados para:

1. Modelar o vocabulário do sistema: o diagrama de classes pode servir

para mostrar aquilo que fará parte do sistema, ou seja, aquilo que é de

interesse do sistema.

2. Modelar as colaborações: o diagrama de classes permite a visualização

das classes bem como as suas relações, que juntas formam um

comportamento.

3. Modelar um esquema lógico de banco de dados: a partir do diagrama declasses é possível criar um esquema lógico de um banco de dados

relacional ou orientado a objetos.

Na UML, as classes são representadas graficamente por uma caixa dividida

entre o compartimento onde ficará o nome da classe, o compartimento com os atributos

e o último com as operações da classe, como pode ser visualizado na Figura 7. (MELO,

2002)



56

Fonte: BOOCH; RUMBAUGH; JACOBSON, 2005.Figura 7: Exemplo de Classe.

Dentro do compartimento onde se localiza o nome da classe pode ainda estar

disposto acima do nome um estereótipo, e abaixo uma lista de propriedades (atributos)da classe. Os atributos utilizam a seguinte sintaxe:

visibilidade nome : tipo [multiplicidade ordering] = valor-inicial {string-

propriedade}

A visibilidade, segundo Melo (2002), pode ser de quatro tipos:

+ ou public: a propriedade pode ser vista e utilizada pela própria classe,

suas descendentes e qualquer elemento externo.

# ou protected: a propriedade pode ser vista e utilizada pela própria

classe e por suas descendentes.

- ou private: a propriedade pode ser vista e utilizada apenas pela própria

classe.

~ ou package: a propriedade pode ser vista e utilizada por qualquer

elemento dentro do mesmo pacote.



57

O tipo do atributo pode ser uma classe ou pode ser algum tipo definido em

alguma linguagem de programação. A multiplicidade é a quantidade de valores que um

atributo pode possuir, se for apenas um ela pode ser suprimida. (MELO, 2002)

Ainda de acordo com Melo (2002), a propriedade ordering só é válida se houver

multiplicidade maior que um. Ela pode assumir o valor unordered ou ordered. O valor-

inicial seria o valor default para qualquer objeto instanciado. E a string propriedade que

pode ser: changeable (o valor pode ser modificado), addOnly (em multiplicidade maior

que 1, novas instâncias podem ser adicionadas, mas não alteradas), frozen (após

instanciado, o valor não poderá ser modificado). Existe ainda os atributos derivados,

eles são representados por uma barra antes do nome. O valor desse tipo de atributo é

dado através do cálculo de outros atributos.

Da mesma forma que os atributos possuem uma sintaxe padrão, de acordo com

Melo (2002), as operações também o têm, e esta está representada a seguir:

visibilidade nome (escopo-parâmetro nome : tipo = valor-default, ...) : tipo-de-

retorno {string-propriedade} A visibilidade funciona da mesma maneira como foi descrita para os atributos.

Dentro dos parênteses ficam os parâmetros, o escopo dele pode ser: in (só entrada,

sem modificação), out (só saída, sem leitura) e inout (entrada e saída, leitura e

modificação). O tipo de retorno depende da linguagem de programação. E a string-

propriedade indica os valores das propriedades para a operação. (MELO, 2002)

Para que um objeto possa se comunicar com outro objeto, se faz necessária a

existência de um intermediário, já que uma classe não pode ter acesso direto a outra

classe. Este intermediário é a interface, que conterá os métodos de uma classe.

(BOOCH; RUMBAUGH; JACOBSON, 2005)



58

Uma interface tem a mesma representação gráfica de uma classe, mas possui

um estereótipo identificando-a como interface, além de operações. Essa interface se

relaciona com classes através de uma realização. (MELO, 2004)

Assim como os casos de uso, as classes também se relacionam. É desta forma

que elas requisitam serviços a outras classes. Segundo Booch, Rumbaugh e Jacobson

(2005) as conexões entre classes ocorrem através de relacionamentos e podem ser dos

tipos dispostos na Figura 8.

Fonte: HAMILTON; MILES, 2006.Figura 8: Tipos de relacionamentos entre classes.

Juntamente com o relacionamento entre classes é possível especificar a

cardinalidade, ou seja, quantas instâncias uma classe pode ter, na UML isso é

conhecido como Multiplicidade. (BOOCH; RUMBAUGH; JACOBSON, 2005)

Melo (2004) dá exemplos comuns de multiplicidade, dispostos abaixo:

0..1 (valor opcional)

1 ou 1..1 (exatamente um)

* ou 0..* (qualquer valor inteiro não negativo)

1..* (qualquer valor inteiro positivo)



59

Além da multiplicidade, ainda é possível determinar restrições (constrains ) em

relacionamentos associativos e atributos de classes, bem como em outros elementos

da UML. São condições colocadas em forma de texto ao lado do elemento dentro de

chaves. (MELO, 2004)

Depois de compreendida a forma como as classes estão dispostas dentro do

diagrama de classes da UML é preciso identificá-las. De acordo com Bezerra (2002),

existem dois métodos principais para a identificação de classes: o método dirigido a

dados e o método dirigido a responsabilidades.

“No método dirigido a dados, a ênfase está na identificação da estrutura dos

conceitos relevantes para um domínio de negócio. A aplicação desse método resulta

em um modelo conceitual do sistema.” (BEZERRA, 2002, p.109)

O segundo método, de acordo com Bezerra (2002), dá ênfase as

responsabilidades que cada classe tem para como o sistema em que está inserido, que

é a colaboração com outros objetos a fim de atingir os objetivos do sistema.

Bezerra (2002) ainda afirma que a divisão de responsabilidades entre osobjetos, sendo que cada objeto possui uma especialidade, torna as possíveis

modificações no sistema menos complexas e mais localizadas. A divisão uniforme de

responsabilidades entre classes evita a sobrecarga das mesmas e torna mais fácil a

reutilização das classes.

A identificação de classes pode ainda ser feita através do diagrama de casos de

uso. Dentro das descrições dos casos de usos, substantivos devem ser destacados,

além das ações que estes efetuam. Mas para que essa técnica seja bem efetuada é

preciso ter um diagrama de casos de uso bem elaborado. (BEZERRA, 2002)

Cabe ainda ressaltar que depois de feito o levantamento das possíveis classes

do sistema, é preciso eliminar aquelas que são desnecessárias ou redundantes. Além



60

de agrupar classes semelhantes através de heranças. E os atributos de cada classe

devem estar dentro do escopo do sistema. (BEZERRA, 2002)

Fonte: BOOCH; RUMBAUGH; JACOBSON, 2005.Figura 9: Exemplo de Diagrama de Classes.

Na Figura 9 está representado um diagrama de classes de uma escola. A

classe Estudante tem uma relação de agregação com Escola, onde um estudante pode

fazer parte de uma ou mais escolas e uma escola pode possuir zero ou mais

estudantes. O estudante ainda pode freqüentar nenhum ou mais cursos.

Departamento também faz parte de Escola, através da agregação. Um

departamento pode pertencer a somente uma escola. Enquanto que uma escola pode

ter um ou mais departamentos.

Faz parte do departamento o instrutor, que pode estar em um ou mais

departamentos. E este pode ter também um ou mais instrutores. Instrutor e

Departamento tem ainda uma relação de associação, havendo deste modo colaboração

entre ambas as partes. O instrutor também pode ensinar em nenhum ou mais cursos.



61

A classe Curso tem relação de associação com departamento, e um curso pode

se relacionar a um ou mais departamentos, e um departamento também pode se

relacionar com um ou mais cursos. O curso pode ter ainda nenhum ou mais estudantes.

2.5.3.4.3 Diagrama de Sequência

O Diagrama de sequência é um dos tipos de diagramas de interação da UML.

De acordo com Quatrani (2001, p.61):

Um diagrama de sequência mostra o objeto de interações organizado na horada sequência. Ele apresenta os objetos e classes envolvidas no cenário e asequência de mensagens trocadas entre os objetos, necessária para efetuar a

funcionalidade do cenário.

O diagrama de sequência é representado em duas dimensões, segundo Melo

(2004), sendo elas: vertical (eixo y) e horizontal (eixo x). Hamilton e Miles (2006)

afirmam que a ordem dos acontecimentos é mostrada de acordo com o posicionamento

vertical da interação. A segunda dimensão (horizontal) mostra os objetos que estão

participando das interações.

Cada objeto no diagrama tem uma linha de vida representada por uma linhatracejada na vertical, estando no topo desta linha um retângulo com o nome do objeto.

Quando o objeto se posiciona acima da primeira seta de mensagem, significa que

objeto já existia antes da transação ser iniciada. E se a linha de vida do objeto continuar

após a última seta de mensagem significa que este objeto continuará a existir após a

finalização da transação. (MELO, 2004)

Na Figura 10 é possível ver dois objetos que foram criados antes das interações

iniciarem. A seta simples que parte do primeiro objeto (Participante 1) para o segundo

(Participante 2) é uma transação através de mensagem. A seta é identificada pela

operação a qual ela chama. Quando a mensagem atingir o outro objeto, o método

solicitado é ativado. Um objeto pode ainda mandar uma mensagem de retorno,

representada por uma seta pontilhada, o que não é obrigatório. (MELO, 2004)



62

Fonte: HAMILTON; MILES, 2006.Figura 10: Objetos criados antes de a interação começar.

Na Figura 11 estão dispostos os quatro tipos de mensagens existentes em um

diagrama de sequência e suas notações. Na identificação da mensagem, irá a chamada

de uma operação que está implementada no receptor da mensagem. Pode ainda estar

na mensagem uma condição para que a mensagem seja enviada ou uma iteração.

(MELO, 2004)

Fonte: HAMILTON; MILES, 2006.Figura 11: Tipos de mensagem.

Uma mensagem síncrona significa que o transmissor irá enviar uma mensagemao receptor e aguardará a resposta deste. Já em uma mensagem assíncrona, o

transmissor não irá esperar a resposta do receptor, mas irá continuar com as outras

interações subsequentes. (HAMILTON; MILES, 2006)



63

De acordo com Hamilton e Miles (2006), a mensagem de retorno significa que o

método foi finalizado e retornou o resultado. Mas o retorno não se faz necessário pois já

está implicito no envio de uma mensagem e pode tornar o diagrama muito carregado e

talvez confuso. E as mensagens de criação e destruição servem para iniciar ou terminarum participante do diagrama.

Nos diagramas de sequência ainda é possível criar interações que podem ser

referenciadas por outros diagramas de sequência, evitando assim redundância. Na

UML 2, é preciso colocar a interação dentro de um frame e colocar o operador ref no

cabeçalho. Quando a referência for efetuada é possível ainda enviar parâmetros para a

interação (MELO, 2004)

Melo (2004) ainda cita três principais operadores nos diagramas de sequência,

sendo eles:

opt: trecho opcional.

loop: repetição de trecho.

alt: trechos alternativos.

Fonte: HAMILTON; MILES, 2006.Figura 12: Exemplo de Diagrama de Sequência.



64

A Figura 12 é um exemplo de diagrama de sequência da criação de uma conta

de blog regular. De acordo com Hamilton e Miles (2006), boa parte dos detalhes

utilizados para iniciar a construção do diagrama está no fluxo principal dos casos de

uso.

O Administrator (administrador) inicia a transação requisitando a

AccountCreationUI (interface de usuário de criação de contas) à criação de uma nova

conta de blog. Logo após, ele seleciona o tipo de conta de blog que deseja e entra com

os detalhes do autor. A AccountCreationUI cria o participante AuthorDetails (detalhes

do autor).

O administrador submete os detalhes do autor, que são representados por um

relacionamento assíncrono, pois o administrador poderá realizar outras tarefas no

sistema mesmo antes da nova conta de blog ter sido criada. A AccountCreationUI

submete os dados ao CreateNewAccountController (controlador de criação de novas

contas). Este por sua vez checa os dados do autor no AuthorCredentialsDB (banco de

dados de credenciais do autor).

Após checados os dados do autor, o CreateNewAccountController cria oparticipante RegularBlogAccount (conta de blog regular) com os detalhes do autor e

elimina o participante AuthorDetails . A operação de envio dos detalhes da conta é

chamada pelo próprio CreateNewAccountController , que então envia o email ao

EmailSystem (sistema de email) com os detalhes do novo blog criado.

Por fim, o CreateNewAccountController dá o retorno à AccountCreationUI que

por sua vez chama a operação que notifica o administrador de que a conta foi criada.

2.5.3.4.4 Diagrama de Máquina de Estados

“A state machine is a behavior that specifies the sequences of states an object

goes through during its lifetime in response to events, together with its responses to

those events.” (BOOCH; RUMBAUGH; JACOBSON, 2005, Cap. 22)



65

Para Bezerra (2002), os estados dos objetos são determinados através dos

valores de seus atributos ou ligações com outros objetos.

Um estado é representado em um diagrama por um retângulo com cantosarredondados e se divide em dois compartimentos. O compartimento superior contém o

nome do estado, caso exista um. E o compartimento inferior contém as atividades

internas executadas por um objeto enquanto estiver no estado em questão. (MELO,

2004)

Hamilton e Miles (2006) chamam de comportamento interno as atividades

internas. Além disso, eles adicionam mais um compartimento ao estado, que é onde

ficam as transações internas, que causam reações no estado, mas sem modificar o

estado do objeto.

As atividades internas são identificadas por três tipos de expressões, segundo

Melo (2004), e que estão dispostas a seguir:

entry: ação executada quando o objeto entra no estado.

exit: ação executada quando o objeto sai do estado. do: ação executada enquanto o objeto estiver no estado atual.

As atividades internas possuem ainda um formato padrão, descrito por Melo

(2004), sendo ele o seguinte:

nome-do-evento (parâmetros) [condição-de-guarda] / expressão-ação

A Figura 13 é um exemplo simples de diagrama de máquina de estados. O

círculo preenchido é um estado que indica o início da máquina de estados. Enquanto

que o círculo preenchido e envolvido por outro círculo indica o fim da execução da

máquina de estados.



66

Fonte: HAMILTON; MILES, 2006.Figura 13: Exemplo de Diagrama de Máquina de Estados.

Ainda na Figura 13, a seta que parte de um estado para outro é uma transição.

Uma transição é um relacionamento entre dois estados, onde um objeto irá passar de

um estado para outro quando certas condições forem satisfeitas (BOOCH;

RUMBAUGH; JACOBSON, 2005)

De acordo com Melo (2004), cada transição é identificada por uma string no

seguinte formato:

nome-do-evento (parâmetros) [condição-de-guarda] / expressão-ação

Segundo Melo (2004), a condição de guarda indica quando uma transição

iniciará, através de uma expressão booleana. A expressão ação são operações ou

atributos que serão executados se a transição iniciar.

De acordo com Hamilton e Miles (2006), na UML ainda é possível que estados

sejam concorrentes ou sequênciais. Melo (2004) descreve os subestados concorrentes

como estados que ocorrem ao mesmo tempo e subestado sequêncial como transações

que ocorrem sequencialmente.

2.5.3.4.5 Diagrama de Implementação

“Diagramas de implementação mostram aspectos de implementação física,

incluindo a estrutura de componentes e a estrutura do sistema em tempo de execução

(runtime ).” (MELO, 2004, p.199)



67

Os diagramas de implementação estão divididos em:

Diagrama de Componentes

Diagrama de Implantação

A) Diagrama de Componentes

“A component is a replaceable part of a system that conforms to and provides

the realization of a set of interfaces .” (BOOCH; RUMBAUGH; JACOBSON, 2005,

Cap.15)

“Components are used to organize a system into manageable, reusable, and

swappable pieces of software .” (HAMILTON; MILES, 2006, Cap.12)

De acordo com Hamilton e Miles (2006), componentes, bem como classes,

podem ter generalizações e associações com outras classes e componentes, tem uma

interface e operações. Por outro lado, um componente possui mais responsabilidade do

que uma classe.

Fonte: BOOCH; RUMBAUGH; JACOBSON, 2005.Figura 14: Exemplo de Componente com Interfaces e Portas.

A Figura 14 é um exemplo de diagrama de componentes de Venda de Bilhetes.

O retângulo representa o componente. Os quadrados localizados em cima da borda do



68

componente são as portas. Os círculos fechados são as interfaces fornecidas e os

meios círculos são as interfaces necessárias.

Uma interface fornecida é um serviço que o componente provê para outroscomponentes. Uma interface necessária é a interface usada pelo componente para

requisitar serviços. As portas são janelas por onde as interações de entrada e saída

passam. E, ao contrário das interfaces, as portas possuem identidades. (BOOCH;


Em sistemas maiores, segundo Booch, Rumbaugh e Jacobson (2005), existe

um interesse em poder construir um componente utilizando componentes menores.

Assim, a estrutura interna de um componente será formada por partes que também

possuem portas e interfaces e que ligam entre si.

As relações de comunicação entre partes e portas ocorrem através de

conectores. (BOOCH; RUMBAUGH; JACOBSON, 2005) Existem ainda conectores de

delegação e conectores assembly , que usados para conectar interfaces com partes

internas (HAMILTON; MILES, 2006)

Fonte: HAMILTON; MILES, 2006.Figura 15: Exemplo de Diagrama de Componentes.

A Figura 15 é um exemplo de diagrama de componentes, com seus

relacionamentos e estruturas internas. O componente ConversionManagement

(gerenciador de conversão) fornece as interfaces FeedProvider (fornecedor de feed) e

DisplayConversor (conversor de tela). Essas duas interfaces são fornecidas por

componentes que estão dentro do componente ConversionManagement , no caso o

Controller (controlador).



69

O Controller ainda precisa da interface Parser que é fornecida pelo BlogParser .

Este precisa da interface DataSource (fonte de dados), então se conecta através de

delegação a uma porta que por sua vez se conecta através de dependência a interface

DataSource do componente BlogDataSource .

O componente BlogDataSource é composto por duas partes: Blog e Entry . Elas

se comunicam com as portas através de conexões de delegação e entre si através de

associação.

B) Diagrama de Implantação

“O Diagrama de Implantação mostra a estrutura de nós nos quais os

componentes e artefatos são implantados.” (MELO, 2004, p.201)

De acordo com Booch, Rumbaugh e Jacobson (2005), um nó é um elemento do

mundo real e que representa um recurso computacional. Pode ser um dispositivo ou

sistema operacional ou algum aplicativo necessário para a execução do sistema. É no

nó onde serão implementados os artefatos.

A comunicação entre nós mais utilizada é a associação. Mas qualquer outro tipo

de relacionamento definido na UML pode ser utilizado. A comunicação é definida ainda

por um estereótipo que descreve o tipo de comunicação que é estabelecida. (BOOCH;


“An artifact is a physical part of a system that exists at the level of the

implementation platform. Graphically, an artifact is rendered as a rectangle with the

keyword «artifact».” (BOOCH; RUMBAUGH; JACOBSON, 2005, Cap.26)



70

Fonte: BOOCH; RUMBAUGH; JACOBSON, 2005.Figura 16: Exemplo Diagrama de Implementação.

A Figura 16 mostra um exemplo diagrama de implementação. O cubo

representa o nó e os retângulos dentro dos nós são os artefatos. Existe ainda um

relacionamento de dependência entre o artefato contacts.exe com os componentes

Sale e Contract .

Os artefatos podem ainda ser listados dentro de um nó ao invés de se utilizar a

representação gráfica dos artefatos. Os relacionamentos dos artefatos podem ser

colocados em um diagrama a parte para tornar o diagrama com os nós mais limpo.

(HAMILTON; MILES, 2006)

2.6 BANCO DE DADOS

Atualmente, os bancos de dados têm papel fundamental em diversasaplicações práticas. É possível afirmar que eles fazem parte da vida de muitas pessoas,

mesmo que elas não tenham conhecimento a respeito. A popularização da computação

é, em parte, devida ao banco de dados. (ELMASRI; NEVATHE, 2003)



71

Neste capítulo estão descritos os conceitos de banco de dados, sistemas de

banco de dados, modelagem conceitual (em especial modelagem ER) e modelagem

lógica.

2.6.1 SGBD

De acordo com Date (1990), um sistema de gerenciamento de banco de dados

consiste em um software que manipula todos os acessos ao banco de dados.

Analisando de uma forma conceitual, o que ocorre é:

1. O usuário solicita o acesso ao banco, usando uma sublinguagem própria de

dados, por exemplo, SQL.

2. O SGBD recebe a solicitação e a analisa. O SGBD verifica as ligações externas

para o usuário, o mapeamento externo/ conceitual correspondente, o esquema

conceitual, o mapeamento conceitual/ interno e a definição da estrutura de

armazenamento.

3.

Por fim, o SGBD executa as operações no banco de dados.

O nível externo é caracterizado pela parte do usuário, tanto programador como

usuário final. Mapeamentos internos e externos aplicam os modelos conceituais no

banco de dados e vice versa. E o nível interno é uma pequena representação de todo o

banco de dados, não trabalhando fisicamente com os dados em termos de registros

(DATE, 1990).

2.6.2 Banco de Dados

Segundo Date (2004), um banco de dados é composto por uma coleção de

dados persistentes, que são usados pelas aplicações de um sistema de determinada

empresa. Em outras palavras, pode ser definido como um arquivamento eletrônico dos

dados de uma organização, em que podem ser manipulados por usuários



72

acrescentando, excluindo, buscando e alterando dados ou arquivos existentes na

database .

O sistema de banco de dados é basicamente um sistema de manutenção deregistros por computador – ou seja, um sistema cujo objetivo global é manter asinformações e torná-las disponíveis quando solicitadas. Trata-se de qualquerinformação considerada como significativa ao indivíduo ou à organizaçãoservida pelo sistema – em outras palavras, que seja necessária ao processo detomada de decisão daquele indivíduo/ organização (DATE, 1990, p.5).

2.6.3 Modelo Conceitual

De acordo com Heuser (2001), o modelo conceitual é a primeira etapa do

projeto na construção de um banco de dados, que descreve de uma forma abstrata obanco de dados de sua aplicação em um SGBD registrando os dados, mas não

demonstrando como estes estão armazenados num nível de SGBD.

O modelo conceitual está intimamente relacionado com a abordagem entidade-

relacionamento, popularmente chamado de modelo ER. Nesta técnica, o modelo

conceitual é representado por um diagrama entidade relacionamento (DER) (HEUSER,

2001). A Figura 17 ilustra um exemplo de modelo conceitual.

Fonte: HEUSER, 2001, p. 17. Figura 17: Exemplo de um modelo conceitual.

A Figura 17 descreve que o banco de dados possui dados sobre os produtos e

sobre os tipos de produtos. Em cada produto é armazenado seu código, sua descrição

e seu preço bem como o tipo de produto relacionado. Na entidade Tipo de produto são



73

armazenadas informações de código e descrição, bem como os produtos daquele tipo

(HEUSER, 2001).

2.6.3.1 Modelagem ER

Segundo Heuser (2001), a modelagem ER é considerada como padronizadora

em relação ao modelo conceitual e mesmo na modelagem de orientação a objetos, que

se baseia em fundamentos da abordagem ER.

Criada em 1976 por Peter Chen, divide-se em propriedades constituintes do

modelo ER que são entidade, relacionamento, atributo, generalização/ especialização e

entidade associativa (HEUSER, 2001).

2.6.3.1.1 Entidade

Heuser (2001) explica que o conceito fundamental da abordagem ER é

atribuído ao conceito de entidade, é o ponto de partida inicial compreender seu

significado. Para Heuser:

“entidade = conjunto de objetos da realidade modelada sobre os quais deseja-

se manter informações no banco de dados” (HEUSER, 2001, p. 23).

Através dessa definição podemos descrever que uma entidade é um objeto do

mundo real sobre o qual é possível gravar dados para um determinado sistema

(HEUSER, 2001). A entidade é representada através de um retângulo, contendo o

nome da entidade conforme o exemplo citado na Figura 18.

Fonte: HEUSER, 2001, p. 23. Figura 18: Exemplo de representação de entidades.



74

Cada um dos retângulos da Figura 18 descreve um conjunto de objetos sobre

os quais se deseja guardar informações. O primeiro retângulo referencia todas as

pessoas que se deseja guardar e manter informações no banco de dados. Já no

segundo retângulo, são designados todos os departamentos sobre os quais se desejaguardar informações (HEUSER, 2001).

2.6.3.1.2 Relacionamento

O relacionamento pode ser descrito como o conjunto de associações entre as

entidades, as ligações e relações entre os objetos (HEUSER, 2001).

Em um DER, um relacionamento é representado através de um losango, ligado

por linhas as entidades representativas participantes do relacionamento (HEUSER,

2001). A Figura 19 descreve um exemplo de relacionamento entre as entidades

departamento e pessoa, sendo o relacionamento chamado de lotação:

Fonte: HEUSER, 2001, p. 24. Figura 19: Representação gráfica de um relacionamento.

O exemplo da Figura 19 demonstra um banco de dados contendo as entidades

DEPARTAMENTO e PESSOA, guardando informações peculiares a sua classe e uma

ligação entre essas entidades designada LOTAÇÃO (HEUSER, 2001).

Para Heuser (2001), relacionamentos são caracterizados por sua cardinalidade

(mínima/máxima), que podem ser binários, ternários e auto-relacionamento.

A cardinalidade descreve a quantidade de vezes que uma ocorrência de

determinada entidade se relaciona a uma ocorrência de outra entidade. Cardinalidade

máxima é representada por 1, para uma associação e n, para muitas associações. Ela



75

não pode ser nula, pois expressa sempre o maior numero de possíveis associações

entre entidades. A cardinalidade mínima possui dois valores, que são 0 e 1. O Valor 1,

ou associação obrigatória, registra que determinada entidade x ocorre 1 vez dentro da

entidade y. Já o valor 0, ou associação opcional informa que determinada entidade nãoprecisa estar relacionada com outra entidade em seu valor mínimo (HEUSER, 2001).

Dentro da cardinalidade máxima existe o relacionamento binário. Heuser nos

descreve que:

A cardinalidade máxima pode ser usada para classificar relacionamentosbinários. Um relacionamento binário é aquele cujas ocorrências envolvem duasentidades, como todos vistos até aqui. Podemos classificar os relacionamentos

em n:n (muitos-para-muitos), 1:n (um-para-muitos) e 1:1 (um-para-um) (2001, p.28).

A Figura 20 demonstra a ocorrência de 1 para 1 (1:1), expressando que um

marido pode ter apenas uma esposa e uma esposa apenas uma instância de marido:

Fonte: HEUSER, 2001, p. 28. Figura 20: Relacionamento 1:1.

A Figura 21, descreve um relacionamento 1:n, ou 1 para muitos.



76

Fonte: HEUSER, 2001, p. 29. Figura 21: Relacionamento 1:n.

De acordo com HEUSER (2001), o exemplo acima demonstra um banco de

dados contendo entidades de ALUNO e CURSO e o relacionamento entre eles

designado de INSCRIÇÃO. Um aluno pode se inscrever em apenas um curso. Um

curso pode conter n alunos inscritos.

Há também dentro da cardinalidade máxima o relacionamento n:n, que

representa muitos para muitos (HEUSER, 2001). A Figura 22 exibe um exemplo da

associação n:n.

Fonte: HEUSER, 2001, p. 29.Figura 22: Relacionamento n:n.

Na Figura 22, é descrita a relação CONSULTA entre MÉDICO e PACIENTE.

Um médico pode consultar vários pacientes. Um paciente pode marcar consulta com

vários médicos (HEUSER, 2001)

Relacionamentos podem associar duas ou mais entidades. Relacionamento

ternário ocorre quando três entidades se relacionam.

No caso de relacionamentos de grau maior que dois, o conceito decardinalidade de relacionamento é uma extensão não trivial do conceito decardinalidade em relacionamentos binários. Lembre-se que, em umrelacionamento binário R entre duas entidades A e B, a cardinalidade máxima



77

de A em R indica quantas ocorrências de B podem estar associadas a cadaocorrência de A. No caso de um relacionamento ternário, a cardinalidade refere-se a pares de entidades. Em um relacionamento R entre três entidades A, B eC, a cardinalidade máxima de A e B dentro de R indica quantas ocorrências deC podem estar associadas a um par de ocorrências de A e B (HEUSER, 2001,

p. 30).

Fonte: HEUSER, 2001, p. 31. Figura 23: Relacionamento ternário com cardinalidade.

Na Figura 23 é mostrado um exemplo de associação ternária, tendo como

entidades a CIDADE, DISTRIBUIDOR E PRODUTO. A relação entre eles está expressa

na DISTRIBUIÇÃO, aonde existe um produto a ser distribuído numa determinada

cidade por um distribuidor. A cardinalidade máxima expressada pelo número 1 se refere

a cidade e o produto, podendo haver apenas um distribuidor deste produto por cidade,

não existindo assim concorrência. E o par de “n” expressa que os pares de entidades

podem estar associados a várias instâncias entre eles, como por exemplo, a um par de

(cidade, distribuidor) podem estar associados vários produtos e a um par de (produto,

distribuidor), podem estar associadas muitas cidades (HEUSER, 2001).



78

2.6.3.1.3 Atributo

Para Heuser (2001), um atributo é descrito como um dado que é associado a

cada ocorrência de um relacionamento ou uma entidade. Em outras palavras, umatributo guarda informações sobre a entidade que se deseja armazenar.

Atributos também possuem cardinalidade, definindo o numero de valores deste

atributo que podem estar relacionados a entidade/relacionamento do qual ele faz parte

(HEUSER, 2001).

Na Figura 24 há um exemplo de uma entidade constituída por três atributos.

Fonte: HEUSER, 2001, p. 34.

Figura 24: Cardinalidade em atributos.

No exemplo da Figura 24, são atribuídos a entidade CLIENTE, três atributos:

nome, código e telefone. Quando a cardinalidade for 1, ou obrigatória como visto

anteriormente, não é posta a sua cardinalidade, ficando vazio como nos atributos nome

e código. Já o atributo telefone, indica que um cliente pode ter 0 e n telefones

cadastrados, sendo opcional (HEUSER, 2001).

Atributos também podem estar contidos em relacionamentos, como pode servisualizado na Figura 25.



79

Fonte: HEUSER, 2001, p. 34. Figura 25: Atributos em relacionamentos.

A Figura 25 mostra um DER aonde o relacionamento ATUAÇÂO possui um

atributo, a função que um engenheiro possui em um determinado projeto (HEUSER,

2001).

Esta [função] não pode ser considerada atributo de ENGENHEIRO, já que umengenheiro pode atuar em diversos projetos exercendo diferentes funções.Também, não é atributo de PROJETO, já que, em um projeto, podem atuardiversos engenheiros com funções diferentes (HEUSER, 2001, p. 35).

Segundo Heuser (2001), cada entidade deve possuir no mínimo um atributo

identificador. Atributos identificadores têm a função de diferenciar um atributo do outro,

uma ocorrência das demais concorrências da mesma entidade.

A Figura 26 abaixo demonstra um exemplo de entidade com um atributo

identificador, aonde o código diferencia as informações das pessoas armazenadas:

Fonte: HEUSER, 2001, p. 36.Figura 26: Identificador simples.



80

Uma entidade também pode conter mais de um atributo identificador, como é o

caso da Figura 27.

Fonte: HEUSER, 2001, p. 36. Figura 27: Identificador composto.

A Figura 27:

[...] mostra um exemplo no qual o identificador da entidade é composto pordiversos atributos. Considera-se um almoxarifado de uma empresa de ferragensorganizado como segue. Os produtos ficam armazenados em prateleiras. Estasprateleiras encontram-se em armários organizados em corredores. Oscorredores são numerados seqüencialmente a partir de um e as prateleiras sãonumeradas seqüencialmente a partir de um dentro de um corredor. Assim, paraidentificar uma prateleira é necessário conhecer seu número e o número docorredor em que se encontra. Para cada prateleira deseja-se saber suacapacidade em metros cúbicos (HEUSER, 2001, p. 36).

Atributos também podem ocorrer em relacionamentos, como é o caso de uma

consulta médica, aonde existe um paciente e um médico. O atributo identificador dorelacionamento consulta é sua data/hora (HEUSER, 2001).

2.6.3.1.4 Generalização/Especialização

De acordo com Heuser (2001), podem ser atribuídas propriedades específicas,

particulares a um subconjunto das ocorrências (especializadas) de uma entidade

genérica. São simbolizadas por um triângulo isósceles conforme a Figura 28.

Um exemplo bem prático é o caso de pessoa jurídica e pessoa física. Essas

entidades podem ser associadas a uma entidade generalizada, chamada cliente ou

pessoa (HEUSER, 2001). Na Figura 28 está apresentado um exemplo desta situação.



81

Fonte: HEUSER, 2001, p. 40. Figura 28: Exemplo de generalização/especialização.

Na Figura 28, a entidade genérica CLIENTE assume dois atributos, sendo um

deles identificador. Esses são atribuídos tanto para PESSOA FÍSICA como PESSOA

JURÍDICA. Os atributos de uma entidade específica não se relacionam com os atributos

de outra entidade. A pessoa física possui CIC (atual CPF), e a pessoa jurídica CGC

(atual CNPJ) (HEUSER, 2001).

As generalizações/especificações são divididas em dois tipos: total e parcial.

Caso seja total, é obrigatório que a entidade genérica seja uma ou a outra específica.

No caso do cliente, ou ele será pessoa física ou jurídica. Já no caso de ser parcial, é

facultativo que a entidade genérica se especialize em uma das entidades relacionadas.

Como por exemplo, nem toda entidade funcionário deverá ser motorista ou empregada,pois existe um atributo chamado tipo de funcionário, generalizando as opções (Figura

29) (HEUSER, 2001).



82

Fonte: HEUSER, 2001, p. 41. Figura 29: Exemplo de generalização/especialização parcial.

2.6.3.1.5 Entidade Associativa

Para Heuser (2001, p. 43): “Uma entidade associativa nada mais é que a

redefinição de um relacionamento, que passa a ser tratado como se fosse também uma

entidade”.

Ela ocorre quando surge a necessidade de relacionar uma entidade com um

relacionamento ou um relacionamento com um novo relacionamento (Figura 30)

(HEUSER, 2001).



83

Fonte: HEUSER, 2001, p. 44. Figura 30: Exemplo de entidade associativa.

Na Figura 30, surgiu a necessidade de criar a prescrição de um determinado

medicamento à consulta. Ela não poderia ser relacionada somente ao médico ou ao

paciente, pois sem médico ou sem paciente não existe prescrição de medicamento. No

caso, a prescrição deve relacionar-se com a consulta, criando uma entidade

associativa. Envolve-se o relacionamento com um retângulo, caracterizando-o como

uma entidade (associativa), mas não deixando de ser relacionamento (HEUSER, 2001).

2.6.4 Modelo Lógico

Para Heuser (2001, p.17): “Um modelo lógico é uma descrição de um banco de

dados no nível de abstração visto pelo usuário do SGBD. Assim, o modelo lógico é

dependente do tipo particular de SGBD que está sendo usado.”

Em outras palavras, pode ser descrito como a estrutura de dados de um banco

de dados conforme vista pelo usuário do SGBD, definindo como o banco de dados será

implementado em um SGBD específico. Os detalhes internos de armazenamento de

informações que não tem influência na programação do SGBD, não fazem parte do

modelo lógico (HEUSER, 2001).



CAPÍTULO 3: RESULTADOS OBTIDOS

Neste capítulo apresenta-se a proposta do novo sistema, sua descrição, suas

restrições, requisitos levantados para o desenvolvimento do mesmo e resultado obtidos.

3.1 PROPOSTA DO NOVO SISTEMA

3.1.1 Descrição do Problema

A empresa fictícia do ramo de gravações possui como meio de controle uma

planilha Excel, configurada com campos contendo informações sobre o montante de

valores mensais de entrada. Esse sistema de controle torna-se vago, pois apenasregistra as entradas efetuadas, não compondo assim um regime de caixa consistente.

De acordo com o problema, viu-se a oportunidade de estudar o caso, aliado

com a prática profissional direcionada III, de formular uma análise orientada a objetos

para o regime de caixa da empresa, aonde o material incluído no relatório, como os

requisitos, diagramas ER e UML, poderão servir futuramente para uma possível

implantação em software.

3.1.2 Descrição das necessidades dos interessados

Neste item, são listados os requisitos funcionais, não funcionais e de domínio,

levantados para a criação de um sistema de controle de estoque. O software deve ser

adequado e formulado de acordo com as necessidades descritas nestes requisitos.



85

3.1.2.1 Requisitos funcionais

No Quadro 5, são apresentados os requisitos que estão diretamente ligados asfuncionalidades do software.

RF1 Lançamento de entradasDescrição: Lançamento de entradas no caixa.Prioridade: AltaRF2 Lançamento de saídasDescrição: Lançamento de saídas do caixa.Prioridade: AltaRF3 Cadastro de categoriasDescrição: Cadastrar as categorias de entradas e saídas que podem ocorrer no caixa. Ex.:

vendas à vista, vendas a prazo, amortizações, contas de luz, contas de telefone,etc.

Prioridade: AltaRF4 Cadastro de funcionáriosDescrição: Cadastro dos funcionários da empresa e que terão acesso ao sistema. Dados

para o cadastro: nome, CPF, RG, telefones, logradouro, etc.Prioridade: MédiaRF5 Relatório por períodoDescrição: O sistema deve permitir a geração de um relatório que mostre todas as entradas

e saídas de caixa em determinado período de tempo. Indicando o saldo inicial efinal do caixa.

Prioridade: AltaRF6 Relatório por categoriaDescrição: O sistema deve permitir a geração de um relatório que mostre as entradas ou

saídas de uma categoria em determinado período de tempo.

Prioridade: AltaRF7 Abertura do caixaDescrição: O sistema só irá permitir o lançamento de entradas e saídas após a abertura de

caixa.Prioridade: AltaRF8 Fechamento do caixaDescrição: No final de um período, que pode ser o fim de expediente da empresa ou o fim do

turno de um funcionário, o caixa deve ser fechado para que as entradas e saídascorrespondentes aquele período sejam computadas e conferidas para verificareventuais inconsistências e para que o saldo em caixa seja ajustado (recolhendoou adicionando saldo a ele)

Prioridade: AltaRF9 Consultar lançamentos

Descrição: O sistema deve permitir a consulta aos lançamentos efetuados no sistema.Prioridade: MédiaRF10 Estornar lançamentosDescrição: O sistema deve permitir o estorno de lançamentos efetuados no sistema, para

que eventuais erros sejam sanados.Prioridade: Média

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Quadro 5: Requisitos Funcionais.



86

3.1.2.2 Requisitos não-funcionais

No Quadro 6, são listados todos os requisitos não-funcionais, que expressam

as qualidades específicas ou condições que o software deve atender.

RNF1 Sistema deverá disponibilizar o recurso de backupDescrição: O sistema deverá disponibilizar uma forma de se realizar backup dos

dados armazenados no sistema.Categoria: ConfiabilidadeObrigatoriedade: RecomendávelRNF2 Usuário e senhaDescrição: Somente os funcionários cadastrados poderão ter acesso ao sistema.

Sendo que estes terão um login e uma senha.Categoria: SegurançaObrigatoriedade: Obrigatório

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Quadro 6: Requisitos Não-Funcionais

3.1.2.3 Requisitos de domínio

No Quadro 7, estão listados os requisitos de domínio que são regras de negócio

que a empresa adota e descrevem características do sistema.

RD1 Saldo mínimo de caixa

Descrição: O caixa deve ter um saldo mínimo de caixa para iniciar suas operações.Fonte: Domínio do negócioRD2 Ajuste do caixaDescrição: O caixa deve ser ajustado quando houver inconsistências no mesmo e

deve ser conferido novamente.Fonte: Domínio do negócio

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Quadro 7: Requisitos de Domínio.

3.1.3 Descrição do sistema proposto

O escopo deste projeto se concentrou no regime de caixa, ou seja, as entradas

e saídas que efetivamente ocorreram em caixa. Para descrever o sistema proposto,

foram desenvolvidos quatro diagramas da UML e um diagrama de entidades-

relacionamentos.



87

Nos diagramas da UML é possível notar a ligação entre os mesmos, pois cada

um deles tem como objetivo mostrar uma visão do sistema. Eles tem um papel

fundamental na validação de como o sistema irá funcionar, o que pode evitar muitos

erros nas próximas etapas de um projeto.

A seguir estão dispostos os diagramas desenvolvidos nesta análise bem como

uma detalhada descrição dos mesmos.

3.1.3.1 Diagramas UML

3.1.3.1.1 Diagrama de Casos de Uso

O primeiro diagrama criado (Figura 31) foi o diagrama de casos de uso, com ele

é possível visualizar os acontecimentos dentro do sistema e a interação deste com os

agentes externos a ele.

Os atores deste diagrama, aqueles que irão disparar os casos de uso, são:

Chefe de Caixa, Operador de Caixa e Administrador do Sistema. Estes três atores são

especializações do ator Funcionário, pois aqueles não deixam de ser um funcionário,mas com algumas especialidades.

Os casos de uso estão envolvidos por um retângulo, que é a fronteira do

sistema, ou seja, tudo dentro daquele retângulo faz parte do sistema. Os casos de uso

podem estar divididos em: primários e secundários.

Os casos de uso primários são: Abertura de Caixa, Incluir Lançamento e

Fechamento do Caixa. São as atividades diretamente relacionadas com aquilo que foiproposto para ser automatizado.

A abertura do caixa consiste na autenticação do chefe de caixa que irá fazer a

abertura do caixa e então o operador de caixa fará sua autenticação e poderá realizar

suas tarefas. A autenticação é o ato do usuário de informar seu login e senha, essa



88

operação está representada no diagrama pelo <<include>> do caso de uso Efetuar

Login.

O caso de uso Incluir Lançamento é o foco deste sistema, consiste nolançamento das entradas e saídas que ocorreram no caixa de determinado período.

Esta atividade é desempenhada pelo Operador de Caixa. Dentro deste caso de uso

podem ocorrer fatos que fogem do ambiente perfeito. Estes desvios são representados

pelos <<extend>> que partem do caso de uso que será incluído nesta exceção que

pode ocorrer e apontam para o caso de uso Incluir Lançamento.

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Figura 31: Diagrama de Casos de Uso.

O Fechamento de Caixa representa o fim de um período, que pode ocorrer

devido ao fim do expediente ou do turno de um operador de caixa. Quando o caixa vai

ser fechado uma conferência do mesmo é feita para verificar eventuais inconsistências

que devem ser corrigidas para que o caixa possa então ser fechado.



89

Todos os outros casos de uso são secundários, pois não trazem benefícios

diretos para a empresa, mas ainda assim são necessários para que o sistema funcione.

O Cadastro de Categoria é necessário para que existam categorias que identifiquem os

lançamentos.

Estornar Lançamento é um caso de uso que ocorre quando algum lançamento

foi incluído em caixa com algum erro. Para que esse erro seja corrigido o estorno do

lançamento é efetuado. O estorno consiste em realizar um novo lançamento com o

mesmo valor do lançamento a ser estornado mas com direção diferente. Ou seja, se o

lançamento a ser estornado era uma entrada o lançamento de estorno será uma saída.

Os casos de uso Consultar Lançamentos e Geração de Relatórios são

atividades que tem por objetivo demonstrar as entradas e saídas do caixa por períodos,

ou por uma determinada categoria. Seria ainda possível visualizar apenas as saídas ou

apenas as entradas em caixa.

O Cadastro de Funcionários é um controle de segurança do sistema, onde

todos os funcionários que terão acesso ao sistema devem estar cadastrados e então

poderão ter um login para acessar o sistema. E o Backup também é uma atividade desegurança que deve ser feita periodicamente.

O Quadro 8 mostra as descrições de cada caso de uso. As descrições detalham

o caso de uso, apontado quem são os atores envolvidos, quem são os interessados.

Que condições devem ser atendidas para que o caso ocorra e como irá ficar após o

caso de uso ter ocorrido. Os requisitos correlacionados com o caso de uso são

referenciados aqui e podem ser consultados nos Quadros 7, 6 e 5.

O fluxo principal de cada caso de uso mostra a sequência de passos que

ocorrem dentro do caso de uso em um mundo perfeito. Enquanto que o tratamento de

exceções descreve os desvios que podem ocorrer do fluxo principal.

Caso de Uso: Abertura do Caixa



90

Atores: Chefe de Caixa e Operador de Caixa

Interessados: Chefe de Caixa e Operador de Caixa

Pré-condições: O caixa não deve ter sido aberto ainda e o chefe de caixa deve estarlogado no sistema.

Pós-condições: O caixa deve estar aberto e pronto para receber lançamentos ououtras operações.

RequisitosCorrelacionados: RF7

Fluxo Principal:

1. O chefe de caixa abre o sistema.2. Inclusão do caso de uso "Efetuar Login" para o chefe de caixa.3. O chefe de caixa escolhe no sistema a opção de abertura de caixa.4. O sistema confirma que o caixa foi aberto.5. Inclusão do caso de uso "Efetuar Login" para o operador de caixa.6. O sistema está pronto para ser operado pelo operador de caixa.

Tratamento de Exceções:3a. O caixa já está aberto.3a.1 O sistema informa que o caixa já está aberto.

3a.2 Retorna ao passo 4 do fluxo principal.Caso de Uso: Incluir Lançamento

Atores: Operador de Caixa

Interessados: Operador de Caixa

Pré-condições: O Caixa deve estar aberto e o operado de caixa deve estar logado.

Pós-condições: O lançamento deve ter sido incluído no sistema e atribuído aooperador de caixa que efetuou o lançamento.

RequisitosCorrelacionados: RF1 e RF2

Fluxo Principal:

1. O operador de caixa escolhe no sistema a opção de inclusão delançamentos.

2. O sistema solicita os dados do lançamento.3. O operador de caixa informa os dados solicitados e envia-os para osistema.4. O sistema inclui os dados do lançamento e atualiza os totais docaixa.

Tratamento de Exceções:

1a. O caixa não está aberto ainda.1a.1 O caso de uso "Abertura de Caixa" é estendido.1a.2 Retorna ao fluxo principal do passo 1.

2a. A categoria de lançamento não existe no sistema.2a.1 Estende o caso de uso "Cadastro de Categoria".2a.2 Retorna ao fluxo principal do passo 2.

4a. Existem incorreções no lançamento.4a.1 O caso de uso "Estornar Lançamento é estendido.Caso de Uso: Fechamento do Caixa

Atores: Chefe de Caixa e Operador de Caixa


Pré-condições: O caixa deve estar aberto.

Pós-condições: O caixa deve estar fechado.RequisitosCorrelacionados: RF8, RD1 e RD2



91

Fluxo Principal:

1. O turno de um funcionário ou o expediente da empresa acabou.2. O chefe de caixa pede para o operador de caixa fazer a conferêciadas entradas e saídas para verificar eventuais inconsistências.3. O chefe de caixa confirma a conferência do caixa.4. O chefe de caixa ajusta o saldo mínimo do caixa.

5. O chefe de caixa faz o fechamento do caixa.


3a. Existem inconsistências no caixa do período.3a.1 O chefe de caixa faz o ajuste do caixa de acordo com a políticada empresa.3a.2 Retorna ao passo 3 do fluxo principal.

Caso de Uso: Extornar Lançamento

Atores: Chefe de Caixa


Pré-condições: Os dados de um lançamento devem estar incorretos.

Pós-condições: O lançamento deve ter sido estornado no sistema.Requisitos

Correlacionados:

RF10

Fluxo Principal:

1. O operador de caixa informa ao chefe de caixa que os dados deum lançamento estão incorretos e o estorno deve ser efetuado.2. O chefe de caixa solicita ao operador de caixa o código destelançamento.3. O chefe de caixa entra no sistema e solicita o estorno de umlançamento.4. O sistema solicita o código do lançamento.5. O chefe de caixa informa o código do lançamento.6. O sistema efetua o estorno e atualiza o contador de estornos docaixa e os totais do caixa.


2a. O operador de caixa não sabe o código do lançamento.2a.1 O caso de uso "Consultar Lançamentos" é estendido.

2a.2 O operador de caixa informa algum parâmetro a respeito dolançamento para o chefe de caixa.2a.3 O chefe de caixa utiliza o parâmetro para encontrar olançamento.2a.4 Retorna ao fluxo principal do passo 3.

Caso de Uso: Cadastro de Categoria



Pré-condições: A categoria não deve estar cadastrada no sistema.

Pós-condições: A categoria deve estar cadastrada no sistema.Requisitos

Correlacionados:

RF3

Fluxo Principal:

1. O chefe de caixa escolhe a opção de cadastro de categoria nosistema.2. O sistema solicita ao chefe de caixa os dados da nova categoria.3. O chefe de caixa informa os dados da categoria.4. O sistema adiciona a categoria.


3a. A categoria já está cadastrada.3a.1 O sistema informa que a categoria já existe.3a.2 O chefe de caixa sai do sistema ou corrige os dados dacategoria.



92

Caso de Uso: Consultar Lançamentos


Interessados: Chefe de Caixa

Pré-condições: O chefe de caixa deve estar logado no sistema.

Pós-condições: O chefe de caixa deve estar com as informações que buscou.RequisitosCorrelacionados: RF9

Fluxo Principal:

1. O chefe de caixa escolhe a opção consultar lançamentos nosistema.2. O sistema solicita o preenchimento de algum parâmetro para que aconsulta seja efetuada.3. O chefe de caixa informa os parâmetros que deseja.4. O sistema busca pelos lançamentos relacionados com osparâmetros e retorna os resultados ao chefe de caixa.


Caso de Uso: Geração de Relatórios


Interessados: Chefe de Caixa

Pré-condições: O chefe de caixa deve estar logado no sistema.

Pós-condições: O chefe de caixa deve estar com o relatório desejado.RequisitosCorrelacionados: RF5 e RF6

Fluxo Principal:

1. O chefe de caixa escolhe a opção para geração de relatórios nosistema.2. O sistema solicita que o chefe de caixa escolha o tipo de relatório.3. O chefe de caixa informa o tipo de relatório ao sistema.4. O sistema solicita o período desejado para que o relatório seja

gerado.5. O chefe de caixa informa o período desejado.6. O sistema gera o relatório para o chefe de caixa.


Caso de Uso: Efetuar Login

Atores: Funcionário

Interessados: Funcionário

Pré-condições: O funcionário sistema deve estar cadastrado no mesmo e não deveestar logado.

Pós-condições: O funcionário deve estar logado no sistema.Requisitos

Correlacionados: RNF2

Fluxo Principal:

1. O sistema solicita autenticação por login e senha.2. O funcionário informa ao sistema seu login e senha.3. O sistema verifica se os dados estão corretos e autoriza o acessoao sistema para o funcionário.4. O usuário pode utilizar o sistema de acordo com suas permissões.



93


2a. O funcionário não está cadastrado no sistema.2a.1 Estende o caso de uso "Cadastro de Funcionário".2a.2 Retorna ao passo 1 do fluxo principal.

2b. Os dados informados estão incorretos.

2b.1 O sistema informa que o login e/ou senha estão incorretos.2b.2 Retorna ao passo 1 do fluxo principal.

Caso de Uso: Cadastro de Funcionário

Atores: Administrador do Sistema e Funcionário

Interessados: Administrador do Sistema e Funcionário

Pré-condições: O funcionário não deve estar cadastrado no sistema.

Pós-condições: O funcionário deve estar cadastrado no sistema e possuir um login esenha.

RequisitosCorrelacionados: RF4

Fluxo Principal:

1. O administrador do sistema solicita os dados do funcionário.

2. O funcionário informa os dados ao administrador do sistema.3. O administrador do sistema verifica se o usuário já não estácadastrado.4. O administrador do sistema escolhe a opção de cadastro defuncionários no sistema e informa os dados fornecidos pelofuncionário.5. O sistema cadastra o funcionário no sistema, cadastra um logingerado a partir dos dados fornecidos e cria uma senha aleatória parao funcionário e retorna uma mensagem de status.6. O funcionário está cadastrado no sistema e já pode se logar aomesmo.


4a. O funcionário já está cadastrado no sistema.

4a.1 O sistema informa que o usuário já está cadastrado no sistema.4a.2 A operação de cadastro de funcionário é cancelada.

Caso de Uso: Backup

Atores: Administrador do Sistema

Interessados: Administrador do Sistema

Pré-condições: O administrador do sistema deve estar logado no sistema.

Pós-condições: O administrador deve estar em posse do backup do sistema.RequisitosCorrelacionados: RNF1

Fluxo Principal:

1. O administrador do sistema solicita a opção de backup no sistema.2. O sistema solicita o local para onde deve ser salvo o arquivo de

backup.3. O administrador do sistema informa o local ao sistema.4. O sistema gera o backup dos dados.

Tratamento de Exceções:4a. Não existem dados para salvar.4a.1 O sistema informa que não existem dados salvos.4a.2 O administrador do sistema sai do sistema.

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Quadro 8: Descrição dos Casos de Uso.



94

3.1.3.1.2 Diagrama de Classes

O diagrama de classes serve para visualizar aquilo que fará parte do sistema,

bem como essas partes se comunicam entre si formando um comportamento. Alémdisso, através do diagrama de classes é possível modelar o esquema lógico de um

banco de dados.

A Figura 32 é o diagrama de classes que mostra cada classe envolvida no

sistema e seus relacionamentos. Os atributos e operações das classes estão dispostos

no Quadro 9.

A classe Funcionário é uma superclasse, ou seja, ela possui outras classes

ligadas a ela através da generalização. Em outras palavras, as classes Chefe de Caixa,

Operador de Caixa e Administrador do Sistema são especializações da classe

Funcionário.

O Funcionário possui ainda agregado a ele a classe de Login, essa classe

contém os logins e senhas dos funcionários. Um funcionário pode ter nenhum ou mais

logins. O Funcionário é ainda aquele que utiliza a entidade Sistema. Este, por sua vez,é uma entidade que faz o intermédio entre os funcionários e as outras classes do

sistema.

A classe Caixa representa um período do caixa, nela ficam armazenadas a data

inicial e final de operação do caixa, bem como quem o abriu (Chefe de Caixa) e quem o

operou (Operador de Caixa). Um caixa pode ter nenhum ou mais Lançamentos, que

estão agregados ao caixa. Cada Lançamento tem um valor, a data em que ocorreu e

sua especialização, que pode ser Entrada ou Saída. Um Lançamento ainda é

classificado em uma única categoria, que vai indicar para quem foi desembolsado

dinheiro ou de quem foi embolsado dinheiro.

As classes que possuem o estereótipo <<actor>> são os mesmos atores do

diagrama de casos de uso. As ligações entre os atores e as outras classes mostram os



95

relacionamentos que eles precisam ter para que sejam capazes de desempenhar seus

papéis, ou seja, trocar mensagens entre as classes de modo a realizar alguma tarefa

específica do sistema.

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Figura 32: Diagrama de Classes.

Os atributos e operações de cada classe estão dispostos no Quadro 9.

Classe: Funcionário



96

Atributos:

int CodigoString CPFString EnderecoString NomeString RG

Métodos:void fornecerDadosCadastrais()void receberLoginSenha(String Login, String Senha)void solicitarAutenticacao()

Classe: Chefe de Caixa

Atributos:

Métodos:

void confirmarConferenciaCaixa()void estornarLançamento()void informarCodigoLancamento()void selecionarPeriodoRelatorio()void selecionarTipoRelatorio()void solicitarDadosCategoria()

Classe: Operador de CaixaAtributos:

Métodos:void conferirCaixa()void informarCodigoLancamento()void informarDadosLancamento()

Classe: Administrador do Sistema

Atributos:

Métodos:

void alterarFuncionario()void alterarFuncionario()void consultarFuncionario()void efetuarBackup()

void incluirFuncionario()Classe: Login

Atributos: String LoginString Senha

Métodos:

void alterarLogin()void autenticarLogin(String Login, String Senha)void consultarLogin()void incluirLogin(String Login, String Senha)

Classe: Caixa

Atributos:

Date DataFimDate DataInicio

Currency SaldoFinalCurrency SaldoInicialCurrency SaldoMinimoCurrency TotalEntradasint TotalEstornosCurrency TotalSaidas



97

Métodos:

void abrirCaixa()void ajustarCaixa()void ajustarSaldoMinimo(Currency SaldoMinimo)void atualizarEstornos(int extornos)void atualizarSaldosTotais(String DadosLancamento)void conferirCaixa()void fecharCaixa()void gerarRelatorio(int TipoRelatorio, int PeriodoRelatorio)void gerarRelatorioCaixa(int CaixaID)

Classe: Lançamentos

Atributos: Currency ValorDate Data

Métodos:

void consultarLancamento()void consultarLancamentosCaixa(int CaixaID)void estornarLancamento(int Codigo)void incluirLancamento(String DadosLancamento)

Classe: CategoriasAtributos: String Nome

Métodos:void alterarCategoria()void consultarCategoria(ArrayList DadosCategoria)void incluirCategoria()

Classe: Sistema

Atributos: String NomeString Versao

Métodos:

void abrirCaixa()void abrirSistema()

void alterarFuncionario()void cadastrarCategoria()Funcionário consultarFuncionario(int Codigo)void efetuarBackup()void efetuarLogin(String Login, String Senha)void estornarLancamento()void fecharCaixa()String gerarLogin(String DadosFuncionario)void gerarRelatorio()String gerarSenha()void incluirFuncionario(String DadosFuncionario)void incluirLancamento()

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Quadro 9: Atributos e Operações das Classes.

3.1.3.1.3 Diagramas de Sequência

Um diagrama de sequência mostra a ordem dos acontecimentos em um caso

de uso bem como quem são os envolvidos. A importância de se descrever



98

detalhadamente os casos de uso pode ser justificada com a construção dos diagramas

de sequência, pois estes se baseiam inteiramente nas descrições. E ainda mais, com a

construção dos diagramas de sequência, os fluxos dos casos de uso podem ser

validados ou não.

Neste trabalho foram criados os diagramas de sequência para os principais

casos de uso, eles estão dispostos nas próximas seções.

A) Abertura de Caixa

A Figura 33 ilustra a sequência do caso de uso Abertura de Caixa. Quem inicia

essa sequência é o Chefe de Caixa que abre o Sistema, este por sua vez solicita ao

Chefe de Caixa a autenticação para entrar no sistema. O Chefe de Caixa efetua o login,

enviando ao sistema o Login e a Senha. O Sistema armazena estes parâmetros e envia

a classe Login, que verifica se os parâmetros são válidos e retorna o resultado.

Se a autenticação for bem sucedida, então o Chefe de Caixa vai chamar a

função abrirCaixa() no Sistema. Este irá criar um novo objeto da classe Caixa, através

da função abrirCaixa(). Cada novo objeto da classe Caixa será um período novo decaixa, com um operador realizando os lançamentos.

Se o caixa estiver aberto o Sistema irá solicitar então a autenticação do

Operador de Caixa que irá operar o caixa. O Operador de Caixa envia seu Login e

Senha ao Sistema, e este pede para a classe Login autenticar os parâmetros. Se a

autenticação for bem sucedida o Operador de Caixa estará apto a efetuar lançamentos.



99

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Figura 33: Diagrama de Sequência (Abertura de Caixa).

B) Cadastro de Categorias

Na Figura 34 é possível visualizar o diagrama de sequência para o cadastro de

categoria. O Chefe de Caixa solicita ao sistema o cadastro de categoria através do

método cadastrarCategoria() da classe Sistema. Este solicita ao Chefe de Caixa os

dados da categoria para que a mesma seja cadastrada.



100

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Figura 34: Diagrama de Sequência (Cadastro de Categoria).

O sistema, num primeiro momento faz a consulta na classe Categorias para

saber se a categoria que o Chefe de Caixa deseja cadastrar já não existe. Caso ela

exista o sistema retorna uma mensagem informando que a categoria já existe.

De outro modo, o Sistema invocará o método incluirCategoria() da classe

Categorias, enviando como parâmetro os dados da categoria informados pelo Chefe de

Caixa. Este método criará uma nova instância da classe categorias contendo os dados

que foram recebidos por parâmetro.

Depois de incluída a categoria o Sistema retorna a mensagem de sucesso ao

Chefe de Caixa.

C) Cadastro de Funcionário

O diagrama de sequência do cadastro de funcionário pode ser visto na Figura

35. A sequência é iniciada com o Administrador do Sistema que solicita ao Funcionário

os seus dados para realizar o cadastro e o Funcionário fornece os dados solicitados.



101

O Administrador do Sistema, em posse dos dados do Funcionário, faz uma

consulta no Sistema para verificar se o Funcionário já foi cadastrado. Se o Funcionário

não estiver cadastrado no Sistema, o Administrador do Sistema inclui o usuário através

da operação incluirFuncionario(), enviando como parâmetro os dados do funcionário.

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Figura 35: Diagrama de Sequência (Cadastro de Funcionário).

Durante a inclusão do funcionário, o Sistema gera para este um login e uma

senha e cria uma nova instância da classe Login através do método incluirLogin,

enviando por parâmetros o login e a senha criadas anteriormente.

Após ter sido incluído o funcionário no sistema e seu login ter sido criado, o

Sistema retorna ao Administrador do Sistema o login e a senha do funcionário. Por fim,

o Administrador repassa o login e senha ao funcionário.



102

D) Estornar Lançamento

Na Figura 36 está disposto o diagrama de sequência de estornar lançamento.

Quando um lançamento for incluído com algum erro, este deve ser estornado. OOperador de Caixa solicitará ao Chefe de Caixa o estorno de um lançamento. O Chefe

de Caixa irá pedir ao Operador de Caixa o código do lançamento que será repassado

ao Chefe de Caixa.

Então, o Chefe de Caixa irá solicitar ao Sistema o estorno de um lançamento,

este por sua vez solicita o código do lançamento a ser estornado. Informado o código, o

Sistema realiza o estorno do lançamento desejado invocando o método

estornarLancamento() da classe Lançamentos, informando o código do lançamento

através de parâmetro.

Estornado o lançamento, o Sistema atualiza junto a classe Caixa, o contador de

estornos que foram efetuados durante o período corrente do Caixa. Em sequência, ele

também atualiza os saldos totais do Caixa, enviando por parâmetro o valor que foi

estornado.

Finalizada a tarefa, uma mensagem de status é retornada ao Chefe de Caixa e

ao Operador de Caixa indicando que a tarefa foi ou não executada com êxito.



103

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Figura 36: Diagrama de Sequência (Estornar Lançamento).

E) Fechamento de Caixa

O Fechamento de Caixa (Figura 37) ocorre ao fim do turno de um Operador de

Caixa ou ao fim do expediente da empresa. Ocorrido isto, o Chefe de Caixa pede ao

Operador de Caixa para que este realize a conferência do caixa para verificar se não

existe alguma inconsistência.

Enquanto o Caixa estiver com inconsistências, será feita a conferência do Caixa

e o ajuste do Caixa, que é uma forma utilizada para sanar as inconsistências

encontradas. Para efetuar a conferência o Operador de Caixa chama a operação

conferirCaixa() da classe Sistema que, por sua vez, chama a operação conferirCaixa()da classe Caixa.

O Caixa faz a geração de um relatório do caixa corrente (chamando um método

próprio) e também uma consulta na classe Lançamentos para resgatar todas as

entradas e saídas associadas ao caixa corrente. Todas estas informações são



104

entregues ao Sistema que repassa para o Operador de Caixa que pode então fazer a

verificação destes dados.

Caso haja inconsistência em Caixa, o Operador de Caixa vai então realizar oajuste de caixa através do método ajustarCaixa() do Sistema que chama o método

correspondente na classe Caixa. Efetuado o ajuste, o caixa é conferido novamente, se

não houver mais inconsistências é preciso então haver a confirmação desta conferência

de Caixa. A conferência de caixa e posterior ajuste é repetida até que não existam mais

inconsistências, isso está representado no diagrama pela retângulo com loop.

A confirmação da conferência do Caixa é efetuada pelo Chefe de Caixa que irá

confirmar que o Caixa está consistente, para que este possa então ser fechado. Com o

caixa conferido, é preciso fazer o ajuste do saldo mínimo que permanecerá em Caixa e

será o saldo inicial do próximo Caixa.



105

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Figura 37: Diagrama de Sequência (Fechamento de Caixa).

O saldo mínimo vai depender da empresa, e também do ritmo de vendas. Com

um volume maior de vendas existe uma necessidade maior de dinheiro em caixa, caso

contrário, não existem motivos para deixar grandes quantidades em caixa.

Com o saldo mínimo ajustado, o Chefe de Caixa pode então fechar o caixa, que

será o encerramento das atividades daquele período de caixa.

F) Geração de Relatórios

A geração de relatórios que está ilustrada na Figura 38 consiste no resgate de

lançamentos através do informe de parâmetros de busca, como período e categoria. A



106

geração dos relatórios é de responsabilidade do Chefe de Caixa. Este solicita ao

Sistema a geração de relatório. O Sistema então pede que o Chefe de Caixa informe o

tipo de relatório desejado, que pode ser um relatório por período ou por categoria.

Mesmo que tenha sido escolhida a geração de relatório por categoria, ainda

assim é preciso informar o período desejado, para que seja possível filtrar melhor as

informações desejadas.

Informados ao Sistema o tipo de relatório e o período do mesmo, o Sistema irá

invocar o método gerarRelatorio() da classe Caixa, enviando através do método os

parâmetros de tipo de relatório e período. O Caixa, para resgatar as informações dos

lançamentos precisará ainda se comunicar com os Lançamentos, para resgatar suas

informações de acordo com os parâmetros desejados pelo Chefe de Caixa.

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Figura 38: Diagrama de Sequência (Geração de Relatórios).

Como mostra o diagrama, serão feitas várias buscar (representado por [*]), uma

para cada categoria e o intervalo do período. Resgatados estas informações, o Caixa

as repassa para o Sistema que entrega o relatório ao Chefe de Caixa.



107

G) Incluir Lançamento

A inclusão de lançamentos, como é possível visualizar na Figura 39, é a

principal atividade do sistema por ser responsável pelo registro das entradas e saídasocorridas em caixa. Esses registros são de responsabilidade do Operador de Caixa.

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Figura 39: Diagrama de Sequência (Incluir Lançamento).

O primeiro passo nessa sequência é verificar se o caixa está aberto para

receber lançamentos. Caso ele esteja fechado (exceção representada pelo retângulo

com o operador opt) o diagrama de sequência de Abertura de Caixa é referenciado,



108

indicando que esta sequência deverá ser percorrida para que os lançamentos em caixa

possam ser efetuados.

Com o caixa aberto e o Operador de Caixa logado ao sistema a inclusão delançamentos já pode ocorrer normalmente. Ela é iniciada pelo Operador de Caixa que

solicita ao Sistema a inclusão de lançamento. Em contrapartida, o Sistema solicita ao

Operador de Caixa os dados do lançamento. E quando recebidos os dados, o Sistema

faz a verificação da categoria para se certificar de que ela existe, caso não exista a

sequência de Cadastro de Categoria é referenciada.

Depois de criado o novo lançamento, os saldos totais do caixa são atualizados

pelo Sistema, incluindo o valor do lançamento que foi efetuado. Uma mensagem de

status é retornada ao Operador de Caixa, indicando sucesso ou falha na inclusão do

lançamento. Além disso, caso o Operador de Caixa encontre alguma incorreção no

lançamento incluído, o diagrama de sequência Estornar Lançamento é referenciado, ou

seja, o estorno do lançamento é efetuado.

Depois de feita a verificação da categoria, o lançamento já pode ser incluído.

Isso ocorre quando o Sistema chama a operação incluirLancamento() da classeLançamentos, enviando como parâmetro os dados do lançamento fornecidos pelo

Operador de Caixa. A inclusão de um novo lançamento cria uma nova instância da

classe Lançamentos.

3.1.3.1.3 Diagramas de Máquina de Estados

Através dos diagramas de máquina de estados é possível ver a sequência de

estados pelo qual um objeto passa durante sua linha de vida em resposta a eventos.

Através dos diagramas de sequência é possível montar o diagrama de máquina de

estados, pois aquele mostra a interação entre os objetos e os estímulos que eles

recebem e enviam.



109

Foram construídos neste trabalho dois diagramas de máquina de estados, um

para a classe Caixa e outro para a classe Lançamentos. Outras classes não possuem

tanta importância para que se tornasse necessária a construção de uma diagrama de

estados. Os dois diagramas construídos estão nas seções consequentes.

A) Classe Caixa

A classe Caixa é uma das principais classes do sistema, nela ficam

armazenados os dados do período de operação do caixa e os totais de entradas e

saídas.

O primeiro estado pelo qual esta classe passa é Criado, é quando ele recebe o

saldo inicial e a data inicial. Com a abertura do caixa ele passa ao estado Aberto, nesse

estado ele poderá receber lançamentos vinculados a ele.

Do estado Aberto ele pode passar para o estado Gerando Relatório ou

Consultando. Quando o relatório ou consulta forem finalizados ele irá retornar ao estado

Aberto. Assim ele ficará até o fim do expediente ou turno, quando o Operador de Caixa

irá fazer a conferência do caixa e este passará para o estado Conferindo.

Enquanto ele permanecer nesse estado consultas a lançamentos serão feitas.

Depois de efetuada a conferência é necessária apurar se existem inconsistências em

caixa. Caso haja é necessário ser feito o ajuste do caixa, onde este passa para o

estado Ajustando Caixa. Quando o caixa estiver ajustado, a conferência é novamente

efetuada para garantir que o caixa está correto.

Estando sem nenhum erro, o caixa irá passar para o estado Ajustando Saldo

Mínimo, que é o ajuste do valor que permanecerá em caixa e será o saldo inicial do

próximo período de caixa. Com o saldo ajustado, o caixa pode então ser fechado pelo

Chefe de Caixa, passando o caixa então para o estado Fechado, não podendo mais

este ser aberto.



110

No estado fechado, o caixa pode ainda passar para o estado de Gerando

Relatório e Consultando, mas sempre retornado ao estado Fechado.

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Figura 40: Diagrama de Máquina de Estados (Caixa).

B) Classe Lançamentos

A classe Lançamentos é um agregado da classe Caixa, onde um Caixa é

possui vários Lançamentos. Cada instância da classe Lançamento possui um valor,

uma data e uma categoria agregada.

Todo Lançamento, em primeira instância é criado pelo Operador de Caixa,

neste estado ele pode possuir seus valores, mas ele ainda não é uma instância de



111

Lançamentos. Quando o Operador de Caixa efetua a inclusão deste Lançamento, então

ele passa a fazer parte da classe Lançamentos.

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Figura 41: Diagrama de Máquina de Estados (Lançamentos).

Depois de incluído, o lançamento pode ainda ser consultado, que é

representado no diagrama pelo estado Consultando. Depois de finalizada a consulta, o

lançamento retornará ao estado Incluído.

3.1.3.1 Diagrama de Entidades-Relacionamentos

O diagrama de entidades-relacionamentos (Figura 42) foi construído em cima

do diagrama de classes da UML, com as devidas modificações, mas mantendo a

mesma proposta inicial do projeto.

A entidade Caixa é responsável por armazenar o intervalo de período deoperação do caixa (Caixa_Data_Inicio e Caixa_Data_Fim), pelos saldos inicial, final,

mínimo e pelos saldos totais de entradas e saídas. No caixa haverá um funcionário que

será o operador e outro que será o chefe do caixa, por isso existe uma ligação N:N

entre Caixa e Funcionários. O que diferenciará cada funcionários será o seu cargo, que



112

é uma relação N:1 não identificada, significando que o funcionário pode ter apenas um

cargo e um cargo pode pertencer a vários funcionários.

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.Figura 42: Diagrama de Entidades-Relacionamentos.

Cada funcionário é identificado através de um código, que é a chave primária.

Um funcionário terá ainda seu CPF cadastrado, além de possuir um ou mais telefones,

e estes podem pertencer a apenas um funcionário. Para ter acesso ao sistema, um

funcionário precisa também de um login e uma senha, estes ficam armazenados na

entidade Logins, sendo que um funcionário pode ter mais de um login, e este pertence

a apenas um funcionário.

Retornando ao Caixa, ele é composto por lançamentos (relação 1:N), sendo

que um lançamento deve pertencer a um caixa. Cada lançamento possui ainda um



113

valor e uma data (de ocorrência). Ele é classificado em uma categoria (conta de luz,

vendas, aluguel) e em um tipo de lançamento (entrada ou saída). Em ambas as

situações as ligações entre as entidades são N:1, isso significa que um uma categoria

ou tipo pode ter vários lançamentos, e este só pode se ligar a uma categoria ou tipo.

3.1.4 Resultados esperados

Através dos diagramas da UML buscou-se a ilustração das várias visões do

sistema de uma maneira compreensível e lógica. A realização de uma análise

consistente tem o intuito de criar uma base forte para as próximas etapas de um projeto

de sistemas. Evitando problemas que dentro da análise podem ser resolvidos com uma

facilidade maior.

Quanto à aplicação de um controle de entradas e saídas (regime de caixa) na

empresa, os benefícios podem ser vários. O principal seria o registro de todas as

operações financeiras da empresa. Além disso, com um controle financeiro é possível

visualizar o desempenho da empresa e verificar defasagens em caixa.

Algo que é importante salientar é o controle do caixa, pois não basta apenas osistema estar funcionando. É preciso haver comprometimento por parte dos

responsáveis pelo setor financeiro da empresa, para que todas as entradas e saídas

sejam registradas no sistema, para torná-lo efetivo. Somente com informações reais é

que será possível verificar se a empresa está de fato passando ou não por dificuldades,

ou se realmente está tendo bons lucros.

Tendo um controle organizado do caixa, não omitindo entradas ou saídas, é

possível controlar o desempenho da empresa e se a empresa passar por problemas

financeiros será muito mais fácil identificar a fonte do problema para então tomar as

devidas medidas. Mas é claro que uma empresa deve ser capaz de antever possíveis

problemas, para tomar medidas preventivas.



114

De modo geral, com a captação das reais necessidades dos interessados é

possível desenvolver um sistema que atenda da melhor forma possível a empresa e de

fato agregue valor a esta, melhorando-a de alguma forma e justificando o investimento

no novo sistema.

3.1.5 Restrições do sistema proposto

O escopo deste projeto foi a realização de uma análise orientada a objetos em

uma empresa (real ou fictícia) para um regime de caixa. A análise se iniciou com o

levantamento dos requisitos de sistema juntamente com os usuários envolvidos e foi

até a construção de quatro diagramas da UML, cada um com uma visão do sistema e

de um diagrama de entidades-relacionamentos.

Quanto ao regime de caixa, ele trata de controlar as entradas e saídas que

efetivamente ocorreram em caixa. Contas a pagar e receber foram descartadas deste

projeto, pois não havia nenhum intuito em planejar entradas e saídas futuras. A

identificação de quem pagou e a quem foi pago também não foram incluídas, pois o

projeto não busca controlar vendas.

O planejamento de caixa também foi deixado de lado, pois ele trata de incluir

previsões de caixa, que é aquilo que se espera acontecer. Além da criação de relatórios

e demonstrativos que fizessem a comparação entre aquilo que foi previsto e aquilo que

de fato ocorreu, indicando a defasagem em caixa.

O projeto teve foco no caixa de um modo mais generalizado, sem detalhar em

demasia. O objetivo da implantação de um regime de caixa está no controle daquilo que

ocorreu em determinado período. Classificando os lançamentos como entradas ou

saídas e identificando este lançamento com uma categoria específica.



CONCLUSÃO

A realização deste trabalho esteve apoiada na idéia de se buscar uma empresa

sem um controle de caixa, para que a partir daí fossem levantadas as necessidades da

empresa para então iniciar a busca por material teórico que serviria de base para o

desenvolvimento da análise.

Como resultado, obteve-se toda a documentação da análise orientada a

objetos, sendo composta por diagramas e suas descrições, e o diagrama de entidades-

relacionamentos.

A construção desta documentação só foi possível através do estudo dofuncionamento do regime de caixa que viria a ser implantado na empresa. Com o

conhecimento a respeito do regime de caixa, a análise orientada a objetos foi utilizada

como principal ferramenta para a estruturação de todo o projeto.

Através da análise orientada a objetos foi possível transcrever todas as

necessidades da empresa em forma de diagramas e descrições detalhadas e mais

precisas. Com os diagramas da UML foi possível montar todo o sistema a partir de

visões diferentes, mas que em algum ponto se interligavam. A vantagem de se utilizar

vários diagramas está exatamente nessa conexão entre eles, isso torna a visão do

sistema mais clara, além de possibilitar a validação de vários processos.

Essa validação faz com que o sistema funcione de uma forma lógica, sem

redundâncias ou inconsistências. E com a utilização de diagramas é muito mais fácil



116

sanar estes problemas, que poderiam ser muito mais difíceis de resolver se ocorressem

na fase de desenvolvimento.

Com os diagramas construídos e descritos, foi possível afirmar que a análiseorientada a objetos tornou mais claro o entendimento sobre regime de caixa da

empresa. Pois através dela foi possível entrar detalhadamente em cada tarefa que seria

executada pelo sistema e descrever como essa tarefa seria executada e se realmente

essa era a maneira correta de executar a tarefa.

Os diagramas da UML forçam o analista a validar todo o tempo a lógica do

sistema, o que torna a análise muito mais consistente. Ficou evidente também como os

diagramas tornam a comunicação entre analistas e usuários mais clara, pois eles

retratam de uma forma mais real os problemas da empresa.

Com o desenvolvimento de uma análise consistente e bem elaborada fica claro

como as fases consequentes do projeto poderão ser mais bem executadas, pois estão

embasadas em esquemas que foram comprovados inúmeras vezes. Isso aumenta a

produtividade e diminui o retrabalho, além de permitir a reutilização de códigos.

Através do diagrama de classes da UML foi possível ainda elaborar o modelo

lógico do banco de dados do sistema (modelo de entidades-relacionamentos). Ele é de

grande importância em um sistema, pois todas as informações estarão armazenadas

em um banco de dados com o esquema deste modelo. E bancos de dados mal

modelados podem ter sérios problemas de desempenho a medida que o banco de

dados for crescendo.

Apesar do trabalho não abranger as próximas etapas de um projeto de

sistemas, com os resultados obtidos na análise é possível concluir que as necessidades

da empresa foram atendidas. Através de um embasamento teórico sólido e da

compreensão das reais necessidades dos interessados, bem como pela ilustração do

sistema desejado através de diagramas consistentes.



REFERÊNCIAS

AUTRAN, Margarida; COELHO, Cláudio Ulysses F.. Básico de Contabilidade e

Finanças. Rio de Janeiro: Senac, 2003.

BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. The Unified Modeling

Language User Guide – 2ª Edição. Addison-Wesley, 2005.

CORREIA, Carlos Henrique; TAFNER, Malcon Anderson. Análise Orientada a Objetos

– 2ª Edição. Florianópolis: Visual Books, 2006.

DATE, Christhoper J.. Introdução a Sistemas de Banco de Dados – 8ª Edição. Rio de

Janeiro: Campus, 1990.

DATE, Christopher J.. Introdução a Sistemas de Bancos de Dados – 8ª Edição. Rio

de Janeiro: Campus, 2004.

ELMASRI, Ramez; NAVATHE, Shamkant B.. Fundamentals of Database Systems – 4ª Edição. Addison-Wesley, 2003.

GORNIK, Davor. Entity Relationship Modeling with UML. IBM Technical Library, 23

de Julho de 2005. Disponível em: <http://www.ibm.com/developerworks/

rational/library/content/03July/2500/2785/2785_uml.pdf>. Acesso em: 28 ago. 2009.



118

GÜLLICH, Roque Ismael da Costa; LOVATO, Adalberto; EVANGELISTA, Mário dos

Santos. Metodologia da Pesquisa: normas para apresentação de trabalhos: redação,

formatação e editoração. Três de Maio: Ed. SETREM, 2007.

HAMILTON, Kim; MILES, Russell. Learning UML 2.0. O’Reilly, 2006.

HARGREAVES, Lourdes; ZUANETTI, Rose; LEE, Renato et al. Qualidade em

prestação de serviços – 2ª Edição. São Paulo: Ed. SENAC, 2001.

HEUSER, Carlos Alberto. Projeto de Banco de Dados – 6ª Edição. Porto Alegre:

Sagra&Luzzatto, 2001.

LAKATOS, Eva Maria; MARCONI, Marina de Andrade. Técnicas de Pesquisa – 6ª

Edição. São Paulo: Atlas, 2006.

LUCION, Carlos Eduardo Rosa. Planejamento Financeiro. Revista Eletrônica de

Contabilidade Vol.1, N.3, Mar-Mai/2005 – Curso de Ciências Contábeis UFSM.

Disponível em:

<http://w3.ufsm.br/revistacontabeis/anterior/artigos/vIIn01/a09vIIn01.pdf>. Acesso em:21 out. 2009.

MARION, José Carlos. Contabilidade Básica – 6ª Edição. São Paulo: Atlas, 1998.

MASAKAZU, Hoji. Administração financeira na prática: guia para educação

financeira corporativa e gestão financeira pessoal. São Paulo: Atlas, 2007.

MELO, Ana Cristina. Desenvolvendo Aplicações com UML 2.0 – 2ª Edição. Rio deJaneiro: Brasport, 2004.

MELO, Ana Cristina. Desenvolvendo Aplicações com UML. Rio de Janeiro: Brasport,

2002.



119

PÁDUA, Elisabete Matallo Marchesini de. Metodologia da Pesquisa: Abordagem

teórico-prática – 10ª Edição. Campinas: Papirus: 2004.

PRESSMAN, Roger S.. Engenharia de Software – 6ª Edição. McGraw-Hill, 2006.

QUATRANI, Terry. Modelagem Visual com Rational Rose 2000 e UML. Rio de

Janeiro: Ciência Moderna, 2001.

RIBEIRO, Osni Moura. Contabilidade Básica Fácil – 23ª Edição. São Paulo: Saraiva,

2002.

ROSS, Stephen A.; WESTERFIELD, Randolph W.; JORDAN, Bradford D.. Princípios

de Administração Financeira – 2ª Edição. São Paulo: Atlas, 2000.

ROSSETTI, José Paschoal. Introdução à Economia – 15ª Edição. São Paulo: Atlas,

1991.

ROSSETTI, José Paschoal. Introdução à Economia – 9ª Edição. São Paulo: Atlas,

1982.

SAMANEZ, Carlos Patrício. Matemática Financeira: Aplicações à Análise de

Investimentos – 3ª Edição. São Paulo: Prentice Hall, 2002.

VASCONCELLOS, Marco A. S. de; GARCIA, Manuel E.. Fundamentos de Economia.

São Paulo: Saraiva, 1998.

YEATES, Donald; WAKEFIELD, Tony. Systems Analysis and Design – 2ª Edição.Pearson, 2004.

YOUNG, Lúcia Helena Briski. Imposto de Renda Pessoa Jurídica: Noções

Fundamentais – 7ª Edição. Curitiba: Juruá, 2008.



120

ZDANOWICZ, José Eduardo. Fluxo de Caixa: Uma decisão de planejamento e

controle financeiros. Porto Alegre: D.C. Luzzatto, 1986.

análise orientada a objetos para fluxo de caixa em estúdio de gravação

Documents