IVAN LUIS GUNKEL MAYCON VIANA BORDIN

ANLISE ORIENTADA A OBJETOS PARA FLUXO DE CAIXA EM ESTDIO DE GRAVAO

Trs de Maio 2009

IVAN LUIS GUNKEL MAYCON VIANA BORDIN

ANLISE ORIENTADA A OBJETOS PARA FLUXO DE CAIXA EM ESTDIO DE GRAVAO

Relatrio da Prtica Profissional Direcionada III Sociedade Educacional Trs de Maio Faculdade Trs de Maio Curso de Bacharelado em Sistemas de Informao

Professores Orientadores: Ms. Gelson Reis Ms. Marcelo Ackermann Ms. Renato Rockenbach Ms. Vera Lcia Lorenset Benedetti

Trs de Maio 2009

RESUMO O presente trabalho tem por objetivo apresentar a anlise orientada a objetos desenvolvida na Prtica Profissional Direcionada III, no curso de Bacharelado em Sistemas de Informao que envolve as disciplinas de Anlise e Projetos de Sistemas II, Banco de Dados I, Matemtica Financeira e Teoria Econmica, sendo elaborado na Faculdade Trs de Maio SETREM no perodo de julho a novembro de 2009. O objetivo principal deste estudo foi aplicar os conhecimentos das disciplinas acima citadas para o desenvolvimento de uma anlise orientada a objetos, onde uma empresa fictcia foi usada como local para estudo e aplicao da anlise. Foi identificado um problema na empresa, onde procurou-se obter informaes sobre as necessidades e carncias da mesma no quesito movimento de caixa. A partir de ento buscou-se embasamento terico em bibliografia impressa e artigos publicados na internet, onde estes serviram de apoio no entendimento do regime de caixa e na construo dos diagramas UML e ER, que foram construdos a partir do levantamento das necessidades descritas nos requisitos. Como resultados desta anlise, foram obtidos diagramas que podem servir de base para o desenvolvimento de um software, atendendo as necessidades da empresa. Palavras chave: Anlise 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 Trs 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 of UML 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 sadas em um fluxo de caixa. ...................................32 Figura 2: Ciclo de caixa. .................................................................................................36 Figura 3: Modelo de Fluxo de Caixa. ..............................................................................38 Figura 4: Contribuies a UML. ......................................................................................46 Figura 5: Vises 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 interao comear. ............................................62 Figura 11: Tipos de mensagem. .....................................................................................62 Figura 12: Exemplo de Diagrama de Sequncia. ...........................................................63 Figura 13: Exemplo de Diagrama de Mquina 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 Implementao. ........................................................70 Figura 17: Exemplo de um modelo conceitual. ...............................................................72 Figura 18: Exemplo de representao de entidades. .....................................................73 Figura 19: Representao grfica de um relacionamento. .............................................74 Figura 20: Relacionamento 1:1. .....................................................................................75

Figura 21: Relacionamento 1:n. .....................................................................................76 Figura 22: Relacionamento n:n. .....................................................................................76 Figura 23: Relacionamento ternrio 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 generalizao/especializao. ...................................................81 Figura 29: Exemplo de generalizao/especializao 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 Sequncia (Abertura de Caixa). ...............................................99 Figura 34: Diagrama de Sequncia (Cadastro de Categoria)....................................... 100 Figura 35: Diagrama de Sequncia (Cadastro de Funcionrio). .................................. 101 Figura 36: Diagrama de Sequncia (Estornar Lanamento). ....................................... 103 Figura 37: Diagrama de Sequncia (Fechamento de Caixa). ....................................... 105 Figura 38: Diagrama de Sequncia (Gerao de Relatrios). ...................................... 106 Figura 39: Diagrama de Sequncia (Incluir Lanamento). ........................................... 107 Figura 40: Diagrama de Mquina de Estados (Caixa). ................................................. 110 Figura 41: Diagrama de Mquina de Estados (Lanamentos). .................................... 111 Figura 42: Diagrama de Entidades-Relacionamentos. ................................................. 112

LISTA DE QUADROS

Quadro 1: Cronograma de Atividades do Projeto. ..........................................................18 Quadro 2: Oramento 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 No-Funcionais............................................................................86 Quadro 7: Requisitos de Domnio. .................................................................................86 Quadro 8: Descrio dos Casos de Uso. .......................................................................93 Quadro 9: Atributos e Operaes das Classes. .............................................................97

LISTA DE SIGLAS

CE Ciclo Econmico CF Ciclo Financeiro CFMe Custo Fixo Mdio CTMe Custo Total Mdio CVMe Custo Varivel Mdio DER Diagrama Entidades-Relacionamentos ER Entidades-Relacionamentos OMG Object Management Group OMT Object Modeling Technique OOSE Object-Oriented Software Engineering PMP Prazo Mdio de Pagamentos PMR Prazo Mdio de Recebimentos SFC Saldo Final de Caixa SGBD Sistema de Gerenciamento de Banco de Dados SIC Saldo Inicial de Caixa UML Unified Modeling Language

SUMRIO

RESUMO..........................................................................................................................3 ABSTRACT ......................................................................................................................4 LISTA DE FIGURAS ........................................................................................................5 LISTA DE QUADROS ......................................................................................................7 LISTA DE SIGLAS ...........................................................................................................8 SUMRIO ........................................................................................................................9 INTRODUO ...............................................................................................................13 CAPTULO 1: ASPECTOS METODOLGICO .............................................................14 1.1 TEMA .......................................................................................................................14 1.2 DELIMITAO DO TEMA ........................................................................................14 1.3 PROBLEMATIZAO DO TEMA .............................................................................14 1.4 HIPTESES .............................................................................................................15 1.4.1 Variveis ...............................................................................................................15 1.5 OBJETIVOS .............................................................................................................15 1.5.1 Objetivo Geral ......................................................................................................15 1.5.2 Objetivos Especficos .........................................................................................15 1.6 JUSTIFICATIVA .......................................................................................................16 1.7 METODOLOGIA .......................................................................................................17 1.7.1 Mtodos de Abordagem ......................................................................................17 1.7.2 Mtodos de Procedimentos ................................................................................17

10

1.7.3 Tcnicas ...............................................................................................................17 1.8 CRONOGRAMA .......................................................................................................18 1.9 RECURSOS .............................................................................................................19 1.10 ORAMENTO ........................................................................................................19 CAPTULO 2: FUNDAMENTAO TERICA ..............................................................20 2.1 PRESTAO DE SERVIOS ..................................................................................20 2.2 TEORIA ECONMICA .............................................................................................21 2.2.1 Conceito de Economia ........................................................................................21 2.2.2 Sistemas Econmicos ........................................................................................21 2.2.3 Moeda ...................................................................................................................22 2.2.4 Inflao .................................................................................................................22 2.2.5 Demanda ..............................................................................................................23 2.2.6 Oramento ...........................................................................................................23 2.3 MATEMTICA 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 Poupana .............................................................................................................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 Conceituao......................................................................................................31 2.4.1.2 Caractersticas....................................................................................................31 2.4.1.3 Planejamento do Fluxo de Caixa ........................................................................33 2.4.1.4 Implantao 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 Competncia e Livro Caixa ...............................40 2.5 ANLISE ORIENTADA A OBJETOS .......................................................................41 2.5.1 Anlise de Sistemas ............................................................................................41 2.5.2 Anlise Orientada a Objetos ...............................................................................42 2.5.2.1 Histria ...............................................................................................................42 2.5.2.2 Classes, Objetos e Mensagens ..........................................................................43 2.5.2.3 Encapsulamento .................................................................................................44 2.5.2.4 Herana ..............................................................................................................44 2.5.2.5 Polimorfismo .......................................................................................................45 2.5.3 UML.......................................................................................................................45 2.5.3.1 Histria ...............................................................................................................45 2.5.3.2 Conceitos ...........................................................................................................46 2.5.3.3 Elementos Bsicos .............................................................................................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 Sequncia ..................................................................................61 2.5.3.4.4 Diagrama de Mquina de Estados ..................................................................64 2.5.3.4.5 Diagrama de Implementao...........................................................................66 A) Diagrama de Componentes .......................................................................................67 B) Diagrama de Implantao ..........................................................................................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 Generalizao/Especializao.........................................................................80

12

2.6.3.1.5 Entidade Associativa .......................................................................................82 2.6.4 Modelo Lgico .....................................................................................................83 CAPTULO 3: RESULTADOS OBTIDOS ......................................................................84 3.1 PROPOSTA DO NOVO SISTEMA ...........................................................................84 3.1.1 Descrio do Problema .......................................................................................84 3.1.2 Descrio das necessidades dos interessados ...............................................84 3.1.2.1 Requisitos funcionais ..........................................................................................85 3.1.2.2 Requisitos no-funcionais ..................................................................................86 3.1.2.3 Requisitos de domnio ........................................................................................86 3.1.3 Descrio 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 Sequncia ................................................................................97 A) Abertura de Caixa ......................................................................................................98 B) Cadastro de Categorias .............................................................................................99 C) Cadastro de Funcionrio ......................................................................................... 100 D) Estornar Lanamento .............................................................................................. 102 E) Fechamento de Caixa .............................................................................................. 103 F) Gerao de Relatrios ............................................................................................. 105 G) Incluir Lanamento .................................................................................................. 107 3.1.3.1.3 Diagramas de Mquina de Estados............................................................... 108 A) Classe Caixa ............................................................................................................ 109 B) Classe Lanamentos ............................................................................................... 110 3.1.3.1 Diagrama de Entidades-Relacionamentos ....................................................... 111 3.1.4 Resultados esperados ...................................................................................... 113 3.1.5 Restries do sistema proposto ...................................................................... 114 CONCLUSO .............................................................................................................. 115 REFERNCIAS ............................................................................................................ 117

INTRODUO O presente trabalho foi elaborado pelos acadmicos do curso de Sistemas de Informao da Faculdade Trs de Maio SETREM, juntamente com os professores orientadores, tendo como escopo a realizao de uma anlise orientada a objetos para regime de caixa em uma empresa fictcia, onde foram levantados os requisitos dos usurios fictcios e em cima destes foi desenvolvida toda a anlise e obtidos os diagramas da UML e o modelo ER. Atravs da Anlise Orientada a Objetos bem como a modelagem de dados estruturou-se a documentao do sistema de forma detalhada e consistente. De modo a ilustrar claramente o funcionamento do sistema de regime de caixa, alm de sanar muitos problemas que surgem na fase de desenvolvimento quando a anlise no feita corretamente ou inexiste nas fases do projeto. O relatrio composto da seguinte maneira: O Captulo 1 apresenta o projeto realizado, onde constam os aspectos metodolgicos empregados na sua realizao e o cronograma respeitado. No Captulo 2 apresentado o referencial terico, onde consta o embasamento terico utilizado no desenvolvimento da anlise orientada a objetos. O Captulo 3 apresenta uma descrio da situao da empresa, os requisitos levantados e os diagramas resultantes da anlise. E em sequncia, a concluso e as referncias utilizadas na formulao do relatrio.

CAPTULO 1: ASPECTOS METODOLGICO Neste captulo apresenta-se a forma de como foi realizada a anlise orientada a objetos, os objetivos, sua justificativa de execuo, a metodologia empregada, os prazos determinados e os recursos utilizados no seu desenvolvimento. 1.1 TEMA Elaborao de uma anlise orientada a objetos para fluxo de caixa em empresa no ramo de servios. 1.2 DELIMITAO DO TEMA Elaborar uma anlise orientada a objetos e modelo entidade-relacionamento para fluxo de caixa para empresa de gravao de udio, que foi desenvolvida pelos acadmicos Ivan Luis Gunkel e Maycon Viana Bordin do 4 semestre do curso Bacharelado em Sistemas de Informao, na Prtica Direcionada III, que envolve as disciplinas de Banco de Dados, Anlise e Projetos de Sistemas II, Matemtica Financeira e Teoria Econmica de agosto a dezembro de 2009 na Sociedade Educacional Trs de Maio - SETREM na cidade de Trs de Maio, RS. 1.3 PROBLEMATIZAO DO TEMA A anlise orientada a objetos bem como o modelo de entidades-

relacionamentos poderiam estruturar de forma consistente uma documentao

15

detalhada de um sistema de fluxo de caixa. Descrevendo este de forma concisa e ilustrando claramente o funcionamento do sistema atravs dos diagramas UML? 1.4 HIPTESES

A anlise orientada a objetos torna mais claro o entendimento sobre o fluxo de caixa da empresa.

O modelo ER possibilita uma melhor compreenso do fluxo de caixa da empresa.

1.4.1 Variveis Fluxo de Caixa Finanas Organizao 1.5 OBJETIVOS 1.5.1 Objetivo Geral Realizar uma anlise orientada a objetos e um modelo de entidadesrelacionamentos em uma empresa de gravao de udio. 1.5.2 Objetivos Especficos Levantar os requisitos e necessidades da empresa com relao ao sistema de regime de caixa intentado. Estudar o funcionamento do fluxo de caixa. Realizar uma anlise 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. Criao e acompanhamento do projeto na ferramenta dotProject, instalado no servidor da SETREM.

1.6 JUSTIFICATIVA O desenvolvimento deste projeto tem como intuito salientar os benefcios da anlise orientada a objetos, que vo desde a padronizao dos diagramas utilizados nas fases do projeto, a juno entre a viso das funcionalidades e dos dados, a compreenso facilitada dos diagramas por parte dos usurios, o que torna a comunicao com o analista muito melhor, e a possibilidade de se reutilizar cdigos sem grandes esforos. Desta forma, o custo de desenvolvimento reduzido, a correo de erros se torna mais fcil e a produtividade aumenta. J a modelagem de banco de dados serviu para descrever as entidades importantes para o sistema e qual a relao que existe entre elas. Uma boa modelagem deve estar embasada nos requisitos dos usurios e deve ser consistente. Pois, no banco de dados onde sero armazenadas todas as informaes vitais para a organizao, e futuros problemas no banco de dados poderiam ser eliminados em uma modelagem bem feita. Com o desenvolvimento de uma anlise consistente e que busque atender as necessidades dos stakeholders o produto final ir atingir o seu principal objetivo, que o de agregar valor a empresa. De modo que os benefcios trazidos pelo sistema desenvolvido justifiquem os investimentos feitos pela mesma.

17

1.7 METODOLOGIA O mtodo substituiu os mitos, as religies, pela racionalidade, pela lgica, pela objetividade, a fim de captar e manipular uma realidade a partir de uma base experimental. (PDUA, 2004, p.26) Atravs do mtodo a cincia pode evoluir com alicerces firmes, utilizando-se de tcnicas que possibilitaram a obteno de conhecimentos neutros sobre a realidade. (PDUA, 2004) 1.7.1 Mtodos de Abordagem O estudo adota o mtodo qualitativo, pois foi desenvolvido em contato direto e interativo com o objeto de estudo que a empresa. Tambm foi realizado um relato sobre a situao da mesma, sua histria e o seu papel na economia local, caracterizando a pesquisa como histrico-cultural. (MARCONI, LAKATOS, 2006). 1.7.2 Mtodos de Procedimentos A pesquisa quanto seus procedimentos pode ser classificada como exploratria explicativa. Exploratria, pois envolve uma entrevista com funcionrios da empresa, buscando obter informaes sobre o problema, alm de aprimorar conceitos sobre negcio e administrao, e explicativa, pois foi analisada e registrada, interpretando os fenmenos e procurando identificar seus fatores determinantes. (GLLICH, LOVATO, EVANGELISTA, 2007). Tambm foi de cunho bibliogrfico, pois estar fundamentada em obras escritas que sero usadas como referncias no estudo. (MARCONI, LAKATOS, 2006). 1.7.3 Tcnicas Foi feita uma entrevista com o responsvel pela empresa para adquirir informaes necessrias sobre a sua situao e organizao. Segundo Lakatos e

18

Marconi (2006, p.88), trata-se de uma pesquisa observacional, pois os dados sero identificados e analisados, classificando-os de acordo com seu papel na empresa. 1.8 CRONOGRAMA O projeto segue o seguinte cronograma, que teve incio no ms de maro julho de 2009 observando-se nele as atividades propostas e realizadas conforme o Quadro 1. A primeira linha indica os meses de durao do projeto, de maro 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.
Meses- 2009 Fases do Projeto Novembro Dezembro * * * * * Setembro Outubro * * * * * * * * * * Agosto Hipteses do Projeto Elaborao do Projeto Entrega do Projeto Fundamentao Terica de Teoria Econmica Fundamentao Terica de AOO Fundamentao Terica de BD Entrega do Relatrio e Artigo Parcial Entrega do Relatrio e Artigo Final Apresentao da Prtica * * * * *

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 ORAMENTO Observaram-se as seguintes despesas relacionadas ao desenvolvimento do projeto no Quadro 2.
Impresses e encadernaes R$ 0,00 R$ 0,00 R$ 4,00 R$ 6,00 R$ 90,00 R$ 0,00

Ms Julho Agosto Setembro Outubro Novembro Dezembro Total:

Transporte R$ 60,00 R$ 60,00 R$ 60,00 R$ 60,00 R$ 60,00 R$ 60,00 R$ 945,00

Alimentao R$ 80,00 R$ 80,00 R$ 80,00 R$ 80,00 R$ 80,00 R$ 80,00

CDs R$ 0,00 R$ 0,00 R$ 0,00 R$ 0,00 R$ 5,00 R$ 0,00

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.

Quadro 2: Oramento do projeto.

CAPTULO 2: FUNDAMENTAO TERICA Neste captulo apresenta-se todo o embasamento terico empregado na realizao do trabalho. 2.1 PRESTAO DE SERVIOS Partindo de um pressuposto geral, a prestao de servios est diretamente ligada ao produto oferecido pela empresa ao mercado consumidor. A prestao de um servio reconhecida como uma atividade comercial, e que geralmente no se apresenta de forma concreta (HARGREAVES; ZUANETTI; LEE et al., 2001). Servio pode ser descrito como o resultado de ao menos uma atividade comercial realizada entre fornecedor e cliente, sendo geralmente intangvel

(HARGREAVES; ZUANETTI; LEE et al., 2001). Os servios podem ser classificados em bens tangveis e intangveis. Toma-se como exemplo o caso do estdio de gravao, onde CDs, equipamentos de gravao e computador, so usados como meio para produzir o produto final, que o CD master. Todos esses bens palpveis so considerados tangveis. Entretanto, o servio de gravao, de mixagem e de masterizao so considerados intangveis pois so percebidos pelos clientes, mas no so produtos em si (HARGREAVES; ZUANETTI; LEE et al., 2001).

21

2.2 TEORIA ECONMICA Para Rossetti (1991) a Teoria Econmica um sistema que possui leis e teorias comprovadas cientificamente e que vo de acordo com a coerncia, consistncia e objetividade. A Teoria Econmica pode ser dividida em Anlise Microeconmica e Anlise Macroeconmica. 2.2.1 Conceito de Economia Para Umbreit, Hunt e Kinter (1957 apud ROSSETTI, 1991, p.57) A economia o estudo da organizao social atravs da qual os homens satisfazem suas necessidades de bens e servios escassos.
A Economia a cincia que se preocupa com o estudo das leis econmicas indicadoras do caminho que deve ser seguido para que seja mantida em nvel elevada a produtividade, melhorando o padro de vida das populaes e empregados corretamente os recursos escassos (SAMUELSON, 1973 apud ROSSETI, 1991, p.57).

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

[...] a cincia voltada para a administrao dos escasso recursos das sociedades humanas: ela estuda as formas assumidas pelo comportamento humano na disposio onerosa do mundo exterior em decorrncia da tenso existentes entre os desejos ilimitados e os meios limitados aos agentes da atividade econmica.

2.2.2 Sistemas Econmicos Os sistemas econmicos podem estar divididos em microeconomia e macroeconomia. A Microeconomia, para Vasconcellos e Garcia (1998, p.30), analisa a economia relacionada as relaes entre empresa e consumidor, preos de produtos e servios, bem como a demanda destes. J a Macroeconomia, de acordo com Vasconcellos; Garcia (1998, p.83), faz uma anlise mais generalizada da economia, buscando entender o comportamento de

22

um conjunto maior, como uma economia nacional, desempenho de um pas na indstria, 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 transaes econmicas, para pagamento dos bens, servios e fatores de produo. 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 comearam a ser utilizados nas transaes, 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 bancrio, onde as pessoas depositavam metais preciosos e recebiam certificados de depsito. Com o passar do tempo os ourives, que recebiam os depsitos, passaram a emitir certificados sem lastro. Com a criao 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 fora da lei. 2.2.4 Inflao A inflao definida como um aumento persistente e generalizado no ndice de preos, ou seja, os movimentos inflacionrios so aumentos contnuos de preos, e no podem ser confundidos com altas espordicas de preos [...]. (VASCONCELLOS; GARCIA, 1998, p.181)

23

De acordo com Rossetti (1982), a inflao pode ser considerada um fenmeno de abrangncia macroeconmica. A principal caracterstica dela a alta dos preos de todos os produtos e servios, sendo que a alta de apenas alguns produtos no caracteriza inflao. 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 servio que os consumidores desejam adquirir em determinado perodo de tempo. Para Vasconcellos e Garcia (1998, p.37), a escolha do consumidor vai depender das seguintes variveis: o preo do bem ou servio, o preo dos outros bens, a renda do consumidor e o gosto ou preferncia do indivduo. Segundo Vasconcellos e Garcia (1998), uma das variveis que afeta a demanda de um bem descrita pela Lei Geral da Demanda, onde quanto maior for a quantidade demandada menor ser o preo e o contrrio tambm verdadeiro. Isso significa, por exemplo, que um consumidor ao ver o preo de algum produto se elevar ele buscar substitu-lo por outro produto. Alm disso, quando o preo de um produto sobe o poder aquisitivo do consumidor diminui e consequentemente a demanda pelo produto tambm. 2.2.6 Oramento Para Hoji (2007), uma empresa um sistema de gerao 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 sadas no presente, caracterizando assim o oramento empresarial. Para Hoji:

24

O oramento geral retrata a estratgia de um conjunto integrado por oramentos especficos, subdivididos em quadros auxiliares, onde esto refletidas quantitativamente as aes e polticas da empresa, relativas a determinados perodos futuros (2004, p. 384 apud HOJI, 2007, p. 130).

O objetivo dos oramentos representar, atravs de nmeros, as polticas de compras, vendas, recursos humanos, produo, gastos, qualidade e tecnologia. Os gerentes dos departamentos da empresa devem aplic-los conforme os planos de ao, acompanhando resultados e corrigindo falhas nos mesmos (HOJI, 2007). Segundo Hoji (2007, p.131), o oramento geral de uma empresa do ramo industrial composto dos seguintes oramentos especficos: a) oramento de vendas; b) oramento de produo; c) oramento de matrias-primas; d) oramento de mo-de-obra direta; e) oramento de custos indiretos de fabricao; f) oramento de custo de produo; g) oramento de despesas gerais, administrativas e de vendas; h) oramento de capital; i) oramento de aplicaes financeiras e financiamentos; j) oramento de caixa; k) oramento de resultado. 2.3 MATEMTICA FINANCEIRA Segue abaixo o referencial sobre matemtica financeira, que ferramenta til na avaliao de alternativas de investimentos e financiamentos de bens de consumo. 2.3.1 Juros Segundo Samanez (2002), d-se o nome de juro a remunerao do capital empregado durante um determinado perodo de tempo. Aps o fim do prazo de

25

aplicao, esse capital tornar-se- um valor denominado montante, que ser igual ao capital aplicado somado ao juro obtido com o perodo de aplicao. A diferena entre o valor do montante (S) e a aplicao (P), sero os juros ganhos ou o rendimento do capital no perodo de tempo (SAMANEZ, 2002). Eis a frmula:

De acordo com Samanez (2002), os rendimentos desses juros so o produto de uma taxa de juros estabelecida, multiplicada pelo valor principal. Segue a frmula: ( ( ) )

Conforme a frmula abaixo, pode-se obter uma relao para o montante, igualando as duas expresses para o clculo 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, so calculados sobre o mesmo principal. O capital cresce em sentido linear em relao ao tempo, no existindo capitalizao dos juros no perodo pois os mesmos no so incorporados ao principal para a base de clculos dos juros do perodo seguinte (SAMANEZ, 2002). )

Segue abaixo a frmula do clculo do juro simples para o prazo de um perodo nico, aonde J (juro), P (aplicao) e i (taxa de juros) (SAMANEZ, 2002):

26

Quando o juro for calculado em um perodo maior de tempo, tem-se o acrscimo de uma varivel n para calcular o juro resultante (SAMANEZ, 2002). Abaixo segue a frmula:

2.3.1.2 Juros Compostos O regime de juros compostos :

[...] o mais comum no dia-a-dia, no sistema financeiro e no clculo econmico. Nesse regime os juros gerados a cada perodo so incorporados ao principal para o clculo dos juros do perodo seguinte. Ou seja, o rendimento gerado pela aplicao ser incorporada a ela, passando a participar da gerao do rendimento no perodo seguinte; dizemos, ento, que os juros so capitalizados (SAMANEZ, 2002, p. 15).

Portanto, juros compostos agregam valor ao principal a cada perodo contabilizado, sendo tomado para o clculo dos juros do perodo seguinte, tambm popularmente chamado de juro sobre juro (SAMANEZ, 2002). No Quadro 3 h um comparativo de juros simples e juros compostos:
Juros Simples Rendimento $ 1.000 X 0,2 = $ 200 $ 1.000 X 0,2 = $ 200 $ 1.000 X 0,2 = $ 200 Juros Compostos Rendimento $ 1.000 X 0,2 = $ 200 $ 1.200 X 0,2 = $ 240 $ 1.440 X 0,2 = $ 288

Ms 1 2 3

Montante $ 1.200 $ 1.400 $ 1.600

Montante $ 1.200 $ 1.440 $ 1.728

Fonte: SAMANEZ, 2002, p.15

Quadro 3: Comparativo entre juros simples e juros compostos. De acordo com Samanez (2002), em regime de juros compostos, o dinheiro aumenta exponencialmente em progresso geomtrica ao longo do tempo, pois os rendimentos de cada perodo so somados ao saldo do perodo anterior para junto com este, render novos juros. Ao contrrio, juros simples crescem em sentido linear, pois os juros somente so contabilizados sobre o valor inicial.

27

Segue abaixo a frmula para o clculo dos juros compostos, sendo: (S) montante, (P) principal, (i) taxa e (n) para os perodos de tempo: ( 2.3.2 Investimento De acordo com Vasconcellos e Garcia (1998, p.124), Investimento o acrscimo ao estoque de capital que leva ao crescimento da capacidade produtiva (construes, instalaes, mquinas etc.). Acrescentando, Rossetti (1982, p.675) diz que o investimento [...] o acrscimo ao capital real da sociedade [...] ele resulta de uma absteno do consumo imediato em relao renda gerada no perodo. 2.3.3 Poupana Segundo Vasconcellos e Garcia (1998, p.124), A poupana a parte residual da renda nacional disponvel, ou seja, a parcela da renda nacional que no gasta em bens de consumo. 2.3.4 Custo Rossetti (1982) afirma que os custos podem ser fixos ou variveis. De acordo com Rossetti (1982, p.302):
[...] os custos fixos incluem todas as formas de remunerao ou nus decorrentes da manuteno dos correspondentes recursos. E os custos variveis decorrem de todos os pagamentos dirigidos aos recursos que variam diretamente em funo do volume de produo da empresa.

O custo fixo mdio (CFMe) resulta da diviso do custo fixo total pelas quantidades produzidas, para cada um dos diferentes nveis de produo admitidos. (ROSSETTI, 1982, p.305) Em outras palavras, quanto maior for a produo menor ser

28

o valor de cada unidade de produto. O custo fixo mdio pode ser dado pela frmula abaixo, onde CFT o custo fixo total e q a quantidade.

O custo varivel mdio (CVMe) resulta da diviso do custo varivel total pelas quantidades produzidas, para cada um dos diferentes nveis de produo admitidos. (ROSSETTI, 1982, p.305) O custo varivel mdio pode ser descrito pela frmula abaixo, onde CVT o custo varivel total q a quantidade.

O custo total mdio (CTMe) resulta da soma do custo fixo mdio com o custo varivel mdio. (ROSSETTI, 1982, p.306) Sua frmula 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 cincia que permite, atravs de suas tcnicas, manter um controle permanente do Patrimnio da empresa (p.14).

29

Em outras palavras, a contabilidade vem para controlar tudo que envolve finanas, patrimnio e movimentao financeira numa empresa, sendo instrumento para o fornecimento de informaes teis para a tomada de decises internas e externas da empresa (MARION, 1998). O patrimnio pode ser descrito como um conjunto de bens, direitos e obrigaes de uma pessoa, tanto fsica quanto jurdica, 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 so todos os valores a receber de terceiros (clientes), como aluguis a receber, promissrias a receber e duplicatas a receber. E as obrigaes, ao contrrio dos direitos, so os valores que a empresa deve a terceiros (fornecedores), como salrios e impostos a pagar (MARION, 1998). 2.3.6 Despesas Para Ribeiro (2002):
As Despesas caracterizam-se pelo consumo de bens e pela utilizao de servios, objetivando a obteno de Receita. Por exemplo: a energia eltrica consumida, os materiais de limpeza consumidos (sabes, desinfetantes, vassouras, detergentes), o caf consumido, os materiais de expediente consumidos (canetas, papis, lpis, impressos etc.), a utilizao de servio telefnico etc (RIBEIRO, 2002, p. 62).

As despesas por outro lado podem ser vistos como gastos, mas que tem como finalidade a obteno de receita, porm, no se identificam com o processo de produo e transformao 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 servios enquanto que a despesa caracteriza de uma forma genrica os gastos com a manuteno das atividades da empresa (RIBEIRO, 2002).

30

2.3.7 Receitas De acordo com Ribeiro (2002), as receitas so provenientes da venda dos bens e da prestao de servios. Existem menos receitas do que despesas, sendo mais comuns as seguintes: Vendas Receitas de Servios Juros Ativos Descontos Obtidos Aluguis Ativos. Segundo Ribeiro (2002), para diferenciar as despesas das receitas so usados adjetivos como Ativo e Passivo. Como exemplo tem-se uma conta de aluguis, aonde a conta aluguis passivos representam despesa e a conta aluguis ativos so classificados como receita. 2.4 PLANEJAMENTO FINANCEIRO A expresso planejamento tem em seu significado o ato de planejar, que possibilita atravs do presente avaliar caminhos e construir um referencial para o futuro, sendo o lado racional da ao. E financeiro relacionado a finanas, a parte administrativa, gesto de dinheiro e sua circulao. Em suma, muito importante para o apoio de deciso e planos futuros da empresa. Um bom planejamento a certeza de que se encontrar xito na operao pretendida, tanto para o planejamento numa empresa como numa famlia (LUCION, 2005).

31

2.4.1 Fluxo de Caixa 2.4.1.1 Conceituao Para Zdanowicz (1986, p.37) o fluxo de caixa [...] o instrumento de programao financeira, que corresponde s estimativas de entradas e sadas de caixa em certo perodo de tempo projetado. Essa ferramenta, de acordo com Zdanowicz (1986, p.24), visa prognosticar a necessidade de captar emprstimos ou aplicar excedentes de caixa nas operaes mais rentveis para a empresa. De acordo com Zdanowicz (1986), estando ciente das entradas e sadas, o administrador financeiro poder planejar de forma eficiente quais as melhores formas de captar recursos, programas os desembolsos, investir excedentes da empresa, evitar acmulos de compromissos em pocas com menos entradas de caixa, suprir necessidades sazonais ou cclicas da empresa. Como consequncia, segundo Zdanowicz (1986), haver um equilbrio entre as entradas e sadas de caixa, os recursos captados de terceiros diminui, boa rentabilidade do capital aplicado, a rotao de estoque aumenta, h menor necessidade de capital de giro. 2.4.1.2 Caractersticas O fluxo de caixa tem como objetivo controlar as entradas e sadas da empresa, e para que esse controle ocorra, de acordo com Zdanowicz (1986), preciso saber que recursos esto ingressando no caixa e como eles so desembolsados.

32

Fonte: ZDANOWICZ, 1986.

Figura 1: Esquema de entradas e sadas em um fluxo de caixa. Como possvel visualizar na Figura 1, o fluxo de entradas no caixa pode ser constitudo de: vendas vista e a prazo, que so fontes internas regulares; aumento de capital social, participaes em ativos do open-market, venda de algum ativo imobilizado, que so fontes internas peridicas; e emprstimos de terceiros que so fontes externas de recursos. J as sadas podem ser provenientes do: custo para a empresa operar (sadas regulares), amortizaes de emprstimos e financiamentos de terceiros (sadas peridicas), e investimentos em ativos permanentes ou em ativos do open-market (sadas irregulares).

33

2.4.1.3 Planejamento do Fluxo de Caixa Zdanowicz (1986) exibe a seguinte frmula para exprimir o fluxo de caixa projetado:

Onde, SFC o saldo final de caixa, SIC o saldo inicial de caixa, I so os ingressos e D os desembolsos. De acordo com Zdanowicz (1986), a finalidade desta frmula 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 captao de recursos para suprir essa escassez em caixa. Zdanowicz (1986) ainda afirma que para elaborao de um fluxo de caixa so necessrias as seguintes informaes: Projeo das vendas. Estimativas das compras e condies 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. Oramento de outras entradas e sadas no perodo. E para que a implantao do fluxo de caixa ocorra, segundo Zdanowicz (1986), preciso: Haver apoio da cpula 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 decises nas finanas da empresa. 2.4.1.4 Implantao do Fluxo de Caixa Para Zdanowicz (1986, p.55), A implantao do fluxo de caixa consiste em apropriar os valores fornecidos pelas vrias reas da empresa [...] de acordo com os perodos que efetivamente devero ocorrer os ingressos e os desembolsos de caixa. Segundo Zdanowicz (1986), a essncia do fluxo de caixa est no planejamento das entradas e sadas que podem ser subdivididas em fluxo operacional e fluxo extraoperacional. O fluxo de caixa operacional, como assevera Zdanowicz (1986), corresponde atividade fim da empresa. Sendo os ingressos compostos de vendas vista, recebimentos, desconto, cauo. J os desembolsos correspondem a compras de matrias primas vista e a prazo, salrios e ordenados, custos indiretos de fabricao, despesas administrativas, despesas com vendas, despesas financeiras e tributrias. A depreciao do ativo imobilizado, segundo Zdanowicz (1986), est acoplada ao custo de fabricao e tambm ser usado para determinar o preo de venda do produto ao consumidor final. Para Ross, Westerfield e Jordan (2000), a depreciao no includa no clculo do fluxo de caixa operacional, por esta no ser uma despesa de caixa. Tampouco os juros, pois so despesas financeiras. O fluxo de caixa extra-operacional, de acordo com Zdanowicz (1986), so as entradas e sadas que no tem relao com a atividade fim da empresa, como:

35

imobilizaes, aluguis pagos ou recebidos, amortizaes de emprstimos ou de financiamentos, vendas de itens do ativo permanente, receitas financeiras. As amortizaes, segundo Zdanowicz (1986, p.60), [...] compreendem os pagamentos de emprstimos ou de financiamentos de longo prazo, geralmente contratados com garantias reais de bens dos scios ou da empresa. E a projeo de imobilizaes, de acordo com Zdanowicz (1986), deve ser feita pela alta administrao 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 emprstimos, onde as amortizaes devero ser pagas com capitais prprios em determinado perodo 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 variao do capital de giro lquido. Os gastos de capital correspondem a diferena entre os ativos permanentes ao fim de um perodo somado a depreciao do mesmo. E a variao do capital de giro lquido 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 emprstimos feitos. Enquanto que o fluxo de caixa aos acionistas so os dividendos que so distribudos aos acionistas da empresa.

36

2.4.1.5 Ciclo de Caixa De acordo com Zdanowicz (1986), o fluxo de caixa pode ser considerado cclico, 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 perodos iguais. Ex.: amortizaes de financiamentos e emprstimos. Irregulares: ingressos e desembolsos que ocorrem sem planejamento prvio. Ex.: multas e compra de peas de reposio para mquinas.

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. Atravs do caixa so efetuadas as compras de matria-prima que sero utilizados na produo de produtos. Com o caixa tambm so pagos todos os encargos sociais e todos os custos atrelados a fabricao do produto. Depois de pronto, o produto ser vendido vista ou a prazo, e os valores recebidos retornaro ento ao caixa da empresa.

37

Como Zdanowicz (1986) descreve, a empresa precisa manter um nvel de estoque que esteja de acordo com o fluxo de produo e vendas. As matrias-primas so adquiridas normalmente a prazo, seus custos mais os custos gerados direta e indiretamente na produo integram o custo do produto final. Este ser vendido aos consumidores vista ou a prazo. O ciclo econmico, de acordo com Zdanowicz (1986, p.63), o [...] prazo decorrido entre as entradas de matrias-primas (compras) e as sadas 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 frmula:

Onde, CF o ciclo financeiro, CE o ciclo econmico, PMR o prazo mdio de recebimentos e PMP o prazo mdio de pagamentos. 2.4.1.6 Modelo de Fluxo de Caixa Na Figura 3 possvel visualizar um exemplo de fluxo de caixa. A tabela possui dispostas todas as entradas e sadas que ocorrem em determinado perodo. Quanto mais especificado for o fluxo de caixa, melhor ser o controle sobre as entradas e as sadas de caixa, verificando assim as suas defasagens e determinando as medidas corretivas ou saneadoras para os perodos subsequentes. (ZDANOWICZ, 1986, p.64) Para Zdanowicz (1986), alm do fluxo de caixa, o administrador financeiro dever elaborar mapas auxiliares para: vendas a prazo, compras a prazo, despesas tributrias, despesas financeiras. No modelo da Figura 3, possvel notar que cada perodo possui trs colunas. A primeira coluna corresponde ao projetado, ou seja, aquilo que se esperava ter sado

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 situao nos prximos perodos.

Fonte: ZDANOWICZ, 1986, p.64

Figura 3: Modelo de Fluxo de Caixa. Segue abaixo a descrio dos itens do fluxo de caixa, de acordo com Zdanowicz (1986):

39

1. Ingressos: so 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: so as sadas no caixa e podem ser: compras vista ou a prazo (utilizando mapas auxiliares de pagamentos), despesas

operacionais e compra de algum ativo permanente. 3. Diferena do perodo: a diferena entre os ingressos e os desembolsos do caixa de dado perodo. 4. Saldo inicial de caixa: saldo final de caixa do perodo anterior. 5. Disponibilidade acumulada: a soma das entradas e sadas mais o saldo inicial de caixa. 6. Nvel desejado de caixa: o capital de giro que a empresa vai precisar, levando em conta as projees das entradas e sadas. 7. Emprstimos ou aplicaes de recursos financeiros: quando a

disponibilidade acumulada for baixa, ser preciso captar recursos atravs de financiamentos e emprstimos de terceiros. E quando houver um excedente, este poder ser aplicado no mercado aberto. 8. Amortizaes e resgates das aplicaes: amortizaes so as devolues do principal, tomado emprestado, enquanto os resgates das aplicaes constituem-se no recebimento do principal. (p.66) 9. Saldo final de caixa: quanto de caixa se deseja ter para o perodo seguinte. 2.4.1.7 Controle de Caixa De acordo com Zdanowicz (1986), existe grande importncia em se controlar o caixa ocorrido e comparar com o projetado diariamente, possibilitando a tomada de decises que revertam alguma situao indesejada, alm de facilitar a elaborao do fluxo de caixa do perodo seguinte.

40

O fluxo de caixa consiste basicamente [...] em coletar ao final de cada perodo, as estimativas de ingressos e de desembolsos de recursos financeiros que comporo o fluxo de caixa para o perodo subsequente desejado. (ZDANOWICZ, 1986, p.91) Alm disso, de acordo com Zdanowicz (1986), preciso fazer todo o controle das entradas e sadas da empresa, a fim de verificar se as expectativas esto de acordo com a realidade da empresa. Cabe ressaltar ainda, que todas as operaes realizadas pela empresa devem ser comprovadas atravs de documentos. O controle do fluxo de caixa pode ainda, para Zdanowicz (1986), ter uma abrangncia a curto prazo e longo prazo. A curto prazo busca-se detalhar precisamente as entradas e sadas de caixa, a fim de minimizar custos. Enquanto que a longo prazo a uma projeo menos detalhada, que busca resumir as entradas e sadas da empresa, pois tem uma finalidade mais administrativa que no necessita de detalhes mnimos (ZDANOWICZ, 1896) Para Zdanowicz (1986), o fluxo de caixa deve ser usado com um auxiliar na tomada de decises. Atravs dele possvel apurar as causas de problemas na empresa e buscar solues para os mesmos. Tambm importante ter o envolvimento de todos os responsveis pelas reas da empresa, para que estes concentrem seus esforos nas metas traadas para o prximo perodo. 2.4.2 Regime de Caixa, Regime de Competncia e Livro Caixa No regime de caixa so apenas consideradas as operaes que de fato ocorreram no perodo, ou seja, quando foi realizado o desembolso. Este regime utilizado por pessoas fsicas, mas pode tambm ser usado por pessoas jurdicas em contratos a longo prazo e contratos governamentais, por exemplo. (YOUNG, 2008) Enquanto que no regime de competncia as operaes so registradas nos perodos em que ocorrem, independente de terem ou no sido feitos os desembolsos. (YOUNG, 2008)

41

Por fim, [...] o Livro Caixa tem a funo de controlar o fluxo de caixa a entrada e a sada de dinheiro atravs do registro de todos os dbitos e crditos ocorridos naquela conta. (AUTRAN; COELHO, 2003, p.65) 2.5 ANLISE ORIENTADA A OBJETOS Nas prximas sees esto dispostos os conceitos bsicos da anlise de sistemas, as caractersticas e conceitos do paradigma da orientao a objetos e os mtodos de anlise orientada a objetos, em especial a UML, que foi amplamente utilizado neste trabalho. 2.5.1 Anlise de Sistemas De acordo com Yeates e Wakefield (2004), a anlise de sistemas consiste em dividir o sistema da empresa em partes, que so os subsistemas que trabalham juntos para fazer o funcionamento do negcio, para que se possa estudar e interpretar o sistema da melhor forma possvel. 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 specic data they require in order to ensure that all the clients requirements are fully met.

Segundo Pressman (2006), os principais objetivos da anlise de requisitos so os de descrever as exigncias dos clientes, prover uma base para um projeto de software e definir requisitos que podero ser validados na construo do software. Depois de definidos os requisitos dos usurios, segundo Yeates e Wakefield (2004), preciso especificar a plataforma tcnica e o caminho a ser seguido na fase do desenvolvimento. A importncia da documentao est na possibilidade de se medir a performance do projeto bem como ter um controle de modificaes realizadas.

42

De acordo com Pressman (2005), a anlise de sistemas deve estar focada nos requisitos visveis no problema e no deve se apegar aos mnimos detalhes. Alm disso, os modelos criados devem ser teis para a anlise, ou seja, eles devem fornecer uma viso que facilite o entendimento do sistema. E quanto mais simples forem os modelos, melhor ser a compreenso do sistema, no h motivos para adicionar diagramas que no acrescem informaes ao modelo. 2.5.2 Anlise Orientada a Objetos A orientao a objetos foi criada para suprir as necessidades existentes nas fases de desenvolvimento de softwares e que no eram completamente supridas pela anlise estruturada. A anlise orientada a objetos traz um novo paradigma, que condiz muito mais com o mundo real. 2.5.2.1 Histria Em 1962 foi iniciado o projeto da linguagem de programao Simula, criada por Ole-Johan Dahl e Kristen Nygaard. Com essa linguagem surgiram os conceitos de classes (com atributos e mtodos), encapsulamento e herana. A partir dessa linguagem surgiu SmallTalk, a primeira linguagem totalmente orientada a objetos. (MELO, 2004) Uma dcada depois do surgimento das primeiras linguagens orientadas a objetos, segundo Melo (2004), comearam a surgir metodologias para a orientao a objetos, hoje conhecidas como anlise orientada a objetos. Anlise 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 princpios da orientao a objetos, estabelecidos por Alan Kay:

43

1. Qualquer coisa um objeto. 2. Objetos realizam tarefas atravs da requisio de servios a outros objetos. 3. Cada objeto pertence a uma determinada classe. Uma classe agrupa objetos similares. 4. A classe um repositrio para comportamento associado ao objeto. 5. Classes so organizadas em hierarquias.

A maior vantagem da orientao a objetos est na juno dos dados e processos em um nico conjunto, mostrando como os processos esto lidando com os dados. (CORREIA, TAFNER, 2006) Outras vantagens da orientao a objetos, de acordo com Melo (2004), esto na padronizao dos modelos em todas as fases do projeto, alm disso, vrios modelos so utilizados para ilustrar o mesmo sistema em diferentes ngulos de viso. Ainda sobre as idias de Melo (2004), na orientao a objetos os dados passam a ser tratados de forma diferenciada, estando estes protegidos pelo encapsulamento. A compreenso dos modelos orientados a objetos muito melhor, pois a linguagem utilizada se aproxima muito da realidade, isso torna a comunicao entre desenvolvedor e usurio muito mais fcil. Como consequncia dessas mudanas trazidas com a orientao a objetos, a produtividade aumenta, os gastos em dinheiro e tempo no desenvolvimento so reduzidos e a manuteno muito mais fcil. possvel reutilizar cdigos, como classes que, se bem escritas, no precisam ser refeitas do zero em um novo sistema. (MELO, 2004) No prximos tpicos esto dispostos os conceitos da orientao a objetos, que so: classes, objetos, mensagens, encapsulamento, herana e polimorfismo. 2.5.2.2 Classes, Objetos e Mensagens Um objeto algo do mundo real, com existncia prpria, podendo ser concreto ou abstrato. Os objetos possuem atributos, que so as suas caractersticas, que por sua vez diferenciam um objeto do outro. (MELO, 2004)

44

Melo (2004) afirma ainda que os objetos possuem mtodos, que so as operaes que um objeto pode executar. Os mtodos de uma classe de objetos s podem modificar dados de sua classe. Objetos semelhantes so agrupados em classes. Uma classe uma descrio dos atributos e servios comuns a um grupo de objetos. Sendo assim, pode-se entender uma classe como sendo um molde a partir do qual objetos so construdos. [...] um objeto uma instncia de uma classe. (BEZERRA, 2002, p.7) Para que haja interao 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 servios uns aos outros. 2.5.2.3 Encapsulamento Um objeto no pode acessar as operaes de outro objeto, muito menos modificar seus dados, ele apenas pode requisitar a realizao de uma tarefa ao objeto, isso encapsulamento. Para que um objeto possa acessar os mtodos de outro ele ir utilizar a interface deste objeto. A interface serve para que o objeto requisitante saiba o que o outro objeto pode fazer e quais dados ele possui. (BEZERRA, 2002) Alm disso, segundo Bezerra (2002), a forma como a interface implementada no tem importncia para o objeto que requisitou algo. E para este objeto pouco importa como os mtodos foram implementados, pois ele apenas precisa que a tarefa seja executada. 2.5.2.4 Herana Na orientao a objetos, para Bezerra (2002), as classes podem estar agrupadas em hierarquia. Sendo que as classes de um nvel iro herdar as caractersticas e operaes das classes dos nveis acima. De acordo com Melo (2004), a classe mais genrica pode ser chamada de superclasse, enquanto que a mais

45

especfica chamada de subclasse. Este o conceito de generalizao e especializao. 2.5.2.5 Polimorfismo De acordo com Melo (2004), uma subclasse pode implementar um mtodo de forma diferente de sua superclasse, sendo que o mtodo da subclasse prevalecer. Mas a quantidade e tipo de atributos bem como o tipo de resultado devem ser iguais aos do mtodo da superclasse. 2.5.3 UML A UML tem sido padro industrial nos ltimos 10 anos na visualizao, especificao, construo e documentao de sistemas de software dos mais diversos segmentos. 2.5.3.1 Histria Segundo Melo (2004), com a introduo da orientao a objetos, uma grande quantidade de mtodos comearam a surgir. O problema era que boa parte deles estendiam mtodos estruturados. Alm disso, com tantas opes de mtodos era difcil escolher um para utilizar. De acordo com Booch, Rumbaugh e Jacobson (2005), alguns mtodos comearam a ganhar destaque. Entre estes mtodos estavam o Booch, OOSE e OMT, eles possuam pontos fortes distintos, e fatias diferentes de mercado. Na dcada de 90, os principais mtodos comearam a seguir rumos semelhantes, o que culminaria na unificao dos mtodos. A unificao comeou em 1994, quando Rumbaugh se uniu a Booch na Rational Software, o que resultou no Mtodo Unificado 0.8. Com o ingresso de Jacobson o modelo OOSE foi incorporado e a verso 0.9 do Mtodo Unificado foi

46

lanada, chamada agora de UML (Unified Modeling Language). (MELO, 2004). Na Figura 4 possvel visualizar os principais contribuintes para a formao da UML. Segundo Booch, Rumbaugh e Jacobson (2005), em 1997 foi lanada a verso 1.0 para submisso a OMG (Object Management Group) para padronizao. No mesmo ano o grupo ganhou novos participantes e colaboradores. Eles produziram a verso 1.1 da UML e submeteram a OMG, que a adotou como padro no mesmo ano. Atualmente a UML est na verso 2.0, que inclu grande quantidade de caractersticas alm da verso 1.

Fonte: QUATRANI, 2001, p.4

Figura 4: Contribuies a UML. 2.5.3.2 Conceitos Segundo Melo (2002, p.32), UML uma linguagem para especificao, visualizao, construo e documentao de artefatos de sistemas de software. E

47

segundo Bezerra (2002, p.14), ela uma linguagem visual para modelar sistemas orientados a objetos. Aprofundando o que disse Melo, Booch, Rumbaugh e Jacobson (2005) explicam as caractersticas da UML: Visualizao: os modelos so padronizados, o que facilita a comunicao entre as pessoas, os modelos podem ser tanto grficos como textuais. Especificao: construo de modelos precisos, sem ambiguidade e completos. Construo: os modelos podem se conectar a linguagens de

programao, bancos de dados relacionais e orientados a objetos. Ainda possvel gerar cdigos atravs dos modelos e o contrrio tambm possvel. Documentao: requisitos, arquitetura, projeto, cdigo fonte, testes, prottipos, verses. Tudo isso documentado atravs da UML, alm do planejamento das atividades do projeto e controle de verses. Com a UML possvel modelar todas as vises de um sistema atravs dos diversos diagramas por ela fornecidos. Cada representao grfica tem seu significado e tambm uma forma de ser utilizada. A utilizao de grficos padronizados facilita a compreenso dos grficos bem como a comunicao com os usurios. (BEZERRA, 2002) Alm da comunicao facilitada entre usurios e analistas, de acordo com Gornik (2005), com a UML a comunicao entre membros de grupos mais fcil, bem como a integrao a repositrios, o formato de entrada e sada padronizado alm de haver uma representao unificada para qualquer ciclo de um projeto. Essas vantagens atribudas a UML se devem, em parte, a padronizao da linguagem que possui um vocabulrio e tambm regras que definem como as palavras do vocabulrio devem estar organizadas para permitir a comunicao.

48

Segundo Booch, Rumbaugh e Jacobson (2005), o vocabulrio e as regras de uma linguagem de modelagem devem focar a representao conceitual e fsica de um sistema. Eles ainda afirmam que apenas um modelo do sistema no suficiente, pois so precisos vrios modelos com vises diferenciadas do sistema e que se conectem uns aos outros. Essas vises diferenciadas, segundo Bezerra (2002), podem estar divididas em cinco perspectivas: Viso de Casos de Uso: o ponto de partida para as outras vises do sistema, mostra as interaes entre o sistema e com agentes externos a ele. Viso de Projeto: so as caractersticas bsicas do sistema, estruturais e comportamentais. Viso de Implementao: o controle das verses do sistema. Viso da Implantao: onde o sistema estar localizada fisicamente, quais componentes faro parte do sistema, com quem o sistema ir se comunicar.

Viso de Processo: em relao ao paralelismo, sincronismo e desempenho do sistema.

49

Fonte: BEZERRA, 2002, p.16.

Figura 5: Vises de um sistema de software. 2.5.3.3 Elementos Bsicos De acordo com Booch, Rumbaugh e Jacobson (2005) existem trs tipos de elementos bsicos: 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 estticas de um modelo, que representam objetos conceituais ou fsicos. So eles: classes, interfaces,

colaboraes, casos de uso, classes ativas, componentes. 2. Objetos Comportamentais: partes dinmicas de um modelo, que representam comportamentos no espao e tempo. So eles: interaes, estado da mquina, aes.

50

3. Objetos de Agrupamento: partes organizacionais de um modelo, que so caixas onde os modelos podem ser decompostos. Fazem parte deste grupo pacotes. 4. Objetos de Anotao: partes de um modelo que so responsveis pela explicao de algo, ou seja, so anotaes. Deste grupo fazem parte as notas. Os relacionamentos tambm se dividem em quatro tipos para Booch, Rumbaugh e Jacobson (2005), sendo eles: 1. Dependncia 2. Associao 3. Generalizao 4. Realizao Os diagramas da UML sero abordados na prxima seo de modo mais generalizado, e nas sees consequentes estaro 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 dinmicos. O primeiro tem por objetivos mostrar caractersticas imutveis do sistema. Enquanto que o segundo mostra as reaes do sistema a requisies e sua evoluo no tempo. O Quadro 4 exibe todos os diagramas da UML agrupados de acordo com sua classificao.

51

Diagramas Estruturais

Diagramas Dinmicos

Diagrama de Classes Diagrama de Objetos Diagrama de Componentes Diagrama de Pacotes Diagrama de Implantao Diagrama de Estrutura Composta Diagrama de Casos de Uso Diagramas de Interao: Diagrama de Viso Geral Diagrama de Sequncias Diagrama Temporal Diagrama de Comunicao Diagrama de Atividades Diagrama de Mquina 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 no necessitaram de todos os diagramas oferecidos pela UML para representar uma soluo vivel. Estes diagramas utilizados esto dispostos nas prximas sees. 2.5.3.4.1 Diagrama de Casos de Uso Para Bezerra (2002, p.46) Um caso de uso [...] a especificao de uma sequncia de interaes 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 primrios e secundrios. Casos de uso primrios so aqueles que envolvem diretamente o que ser automatizado na empresa. Enquanto que casos de uso secundrios no trazem benefcios diretos empresa, mas ainda assim so necessrios para que o sistema funcione. (BEZERRA, 2002) A forma como so representados graficamente os casos de uso, atores e seus relacionamentos pode ser vista em detalhes na Figura 6. Alm da representao

52

grfica, preciso ainda elaborar uma descrio detalhada de cada um dos casos de uso detectados. Isso proporciona uma melhor compreenso dos casos de uso do sistema e facilita a construo de outros diagramas da UML. Atravs de uma descrio detalhada possvel tomar conhecimento dos envolvidos no caso de uso, quais os passos do fluxo principal, as excees que podem ocorrer e outros casos de uso includos no fluxo. (HAMILTON; MILES, 2006) A descrio dos casos de uso no tem um padro, abaixo estar disposta uma lista de itens que podem ser documentados, seguindo Bezerra (2002): 1. Nome do caso de uso. 2. Identificador, um cdigo que identifique o caso de uso. 3. Importncia do caso de uso. 4. Sumrio, pequena descrio do caso de uso. 5. Ator Primrio, aquele que inicia o caso de uso. 6. Atores Secundrios, outros atores que participem do caso de uso. 7. Pr-condies para que o caso de uso acontea. 8. Fluxo Principal so os passos que ocorrem em um cenrio perfeito. 9. Fluxos Alternativos so as tomadas de decises diferentes das do fluxo principal, tomadas pelos atores para alcanar o objetivo. 10. Fluxos de Exceo so os acontecimentos inesperados que podem vir a ocorrer na interao entre caso de uso e atores. 11. Ps-condies, como deve ser o estado do sistema depois de efetuada a tarefa. 12. Regras de Negcio 13. Histrico 14. Notas de Implementao sobre como o caso de uso pode ser implementado. Para interagir com os casos de uso existem os atores, que faro isso atravs de mensagens, que sero as relaes 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 atravs da associao. Existem ainda relacionamentos entre casos de uso (generalizao, extenso e incluso) e entre atores (generalizao). (MELO, 2004) Na associao, de acordo com Melo (2004), existe o relacionamento binrio, ou seja, de um lado um ator e de outro um caso de uso. Esse relacionamento significa que h comunicao atravs do envio e recebimento de mensagens. Na generalizao, segundo Bezerra (2002), existe a ligao entre atores ou entre casos de uso. Casos de uso ou atores semelhantes podem estar ligados hierarquicamente, sendo que os de nveis mais baixos tero especialidades em relao ao de nvel mais alto. A extenso entre casos de uso quer dizer que um caso de uso poder ter uma exceo que fuja do fluxo principal, e em consequncia ir incluir um outro caso de uso neste caso (MELO, 2004). Para Bezerra (2002), um caso de uso s ser estendido se houverem as condies certas para que ela ocorra, o que vai depender do ator. A incluso, de acordo com Bezerra (2002), a incluso 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 manuteno, o entendimento mais claro e evita-se a redundncia. Na Figura 6 possvel visualizar um exemplo de diagrama de caso de uso de uma locadora. Os atores so representados por bonecos, os casos de uso por elipses com o nome do caso de uso dentro. As associaes so feitas por ligaes simples entre ator e caso de uso, enquanto que extenses e incluses so representadas por setas pontilhadas, alternando somente a direo da seta e o esteretipo identificador.

54

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.

Figura 6: Exemplo de Diagrama de Casos de Uso. Ainda na Figura 6, possvel notar a generalizao que h de atendente e gerente para funcionrio. Sendo que os dois primeiros iro herdar todas as caractersticas e operaes do ltimo. Em uma Devoluo de Ttulo, caso haja atraso estendido o caso de uso Gerao de Multa. Na Locao de Ttulo est includa a Validao de Clientes, ou seja, toda vez que um cliente for retirar um ttulo ele precisa ter seu cadastro validado para pode retirar o ttulo. Em sistemas maiores possvel utilizar pacotes para agrupar casos de uso, o que torna o diagrama mais organizado e facilita a visualizao. Um pacote pode agrupar no somente casos de uso, mas tambm 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 colaboraes e seus relacionamentos. Graficamente, um diagrama de classes uma coleo de vrtices e arcos. (BOOCH; RUMBAUGH; JACOBSON, 2005, Cap. 8) Segundo Booch, Rumbaugh e Jacobson (2005), diagramas de classe so usados para: 1. Modelar o vocabulrio 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 colaboraes: o diagrama de classes permite a visualizao das classes bem como as suas relaes, que juntas formam um comportamento. 3. Modelar um esquema lgico de banco de dados: a partir do diagrama de classes possvel criar um esquema lgico de um banco de dados relacional ou orientado a objetos. Na UML, as classes so 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 operaes 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 esteretipo, e abaixo uma lista de propriedades (atributos) da classe. Os atributos utilizam a seguinte sintaxe: visibilidade nome : tipo [multiplicidade ordering] = valor-inicial {stringpropriedade} A visibilidade, segundo Melo (2002), pode ser de quatro tipos: + ou public: a propriedade pode ser vista e utilizada pela prpria classe, suas descendentes e qualquer elemento externo. # ou protected: a propriedade pode ser vista e utilizada pela prpria classe e por suas descendentes. - ou private: a propriedade pode ser vista e utilizada apenas pela prpria 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 programao. 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 vlida se houver multiplicidade maior que um. Ela pode assumir o valor unordered ou ordered. O valorinicial 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 instncias podem ser adicionadas, mas no alteradas), frozen (aps instanciado, o valor no poder ser modificado). Existe ainda os atributos derivados, eles so representados por uma barra antes do nome. O valor desse tipo de atributo dado atravs do clculo de outros atributos. Da mesma forma que os atributos possuem uma sintaxe padro, de acordo com Melo (2002), as operaes tambm o tm, e esta est representada a seguir: visibilidade nome (escopo-parmetro nome : tipo = valor-default, ...) : tipo-deretorno {string-propriedade} A visibilidade funciona da mesma maneira como foi descrita para os atributos. Dentro dos parnteses ficam os parmetros, o escopo dele pode ser: in (s entrada, sem modificao), out (s sada, sem leitura) e inout (entrada e sada, leitura e modificao). O tipo de retorno depende da linguagem de programao. E a stringpropriedade indica os valores das propriedades para a operao. (MELO, 2002) Para que um objeto possa se comunicar com outro objeto, se faz necessria a existncia de um intermedirio, j que uma classe no pode ter acesso direto a outra classe. Este intermedirio a interface, que conter os mtodos de uma classe. (BOOCH; RUMBAUGH; JACOBSON, 2005)

58

Uma interface tem a mesma representao grfica de uma classe, mas possui um esteretipo identificando-a como interface, alm de operaes. Essa interface se relaciona com classes atravs de uma realizao. (MELO, 2004) Assim como os casos de uso, as classes tambm se relacionam. desta forma que elas requisitam servios a outras classes. Segundo Booch, Rumbaugh e Jacobson (2005) as conexes entre classes ocorrem atravs 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 possvel especificar a cardinalidade, ou seja, quantas instncias 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 no negativo) 1..* (qualquer valor inteiro positivo)

59

Alm da multiplicidade, ainda possvel determinar restries (constrains) em relacionamentos associativos e atributos de classes, bem como em outros elementos da UML. So condies colocadas em forma de texto ao lado do elemento dentro de chaves. (MELO, 2004) Depois de compreendida a forma como as classes esto dispostas dentro do diagrama de classes da UML preciso identific-las. De acordo com Bezerra (2002), existem dois mtodos principais para a identificao de classes: o mtodo dirigido a dados e o mtodo dirigido a responsabilidades. No mtodo dirigido a dados, a nfase est na identificao da estrutura dos conceitos relevantes para um domnio de negcio. A aplicao desse mtodo resulta em um modelo conceitual do sistema. (BEZERRA, 2002, p.109) O segundo mtodo, de acordo com Bezerra (2002), d nfase as responsabilidades que cada classe tem para como o sistema em que est inserido, que a colaborao com outros objetos a fim de atingir os objetivos do sistema. Bezerra (2002) ainda afirma que a diviso de responsabilidades entre os objetos, sendo que cada objeto possui uma especialidade, torna as possveis modificaes no sistema menos complexas e mais localizadas. A diviso uniforme de responsabilidades entre classes evita a sobrecarga das mesmas e torna mais fcil a reutilizao das classes. A identificao de classes pode ainda ser feita atravs do diagrama de casos de uso. Dentro das descries dos casos de usos, substantivos devem ser destacados, alm das aes que estes efetuam. Mas para que essa tcnica 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 possveis classes do sistema, preciso eliminar aquelas que so desnecessrias ou redundantes. Alm

60

de agrupar classes semelhantes atravs de heranas. 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 relao de agregao 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 freqentar nenhum ou mais cursos. Departamento tambm faz parte de Escola, atravs da agregao. 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 tambm um ou mais instrutores. Instrutor e Departamento tem ainda uma relao de associao, havendo deste modo colaborao entre ambas as partes. O instrutor tambm pode ensinar em nenhum ou mais cursos.

61

A classe Curso tem relao de associao com departamento, e um curso pode se relacionar a um ou mais departamentos, e um departamento tambm pode se relacionar com um ou mais cursos. O curso pode ter ainda nenhum ou mais estudantes. 2.5.3.4.3 Diagrama de Sequncia O Diagrama de sequncia um dos tipos de diagramas de interao da UML. De acordo com Quatrani (2001, p.61):
Um diagrama de sequncia mostra o objeto de interaes organizado na hora da sequncia. Ele apresenta os objetos e classes envolvidas no cenrio e a sequncia de mensagens trocadas entre os objetos, necessria para efetuar a funcionalidade do cenrio.

O diagrama de sequncia representado em duas dimenses, 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 interao. A segunda dimenso (horizontal) mostra os objetos que esto participando das interaes. Cada objeto no diagrama tem uma linha de vida representada por uma linha tracejada na vertical, estando no topo desta linha um retngulo com o nome do objeto. Quando o objeto se posiciona acima da primeira seta de mensagem, significa que objeto j existia antes da transao ser iniciada. E se a linha de vida do objeto continuar aps a ltima seta de mensagem significa que este objeto continuar a existir aps a finalizao da transao. (MELO, 2004) Na Figura 10 possvel ver dois objetos que foram criados antes das interaes iniciarem. A seta simples que parte do primeiro objeto (Participante 1) para o segundo (Participante 2) uma transao atravs de mensagem. A seta identificada pela operao a qual ela chama. Quando a mensagem atingir o outro objeto, o mtodo solicitado ativado. Um objeto pode ainda mandar uma mensagem de retorno, representada por uma seta pontilhada, o que no obrigatrio. (MELO, 2004)

62

Fonte: HAMILTON; MILES, 2006.

Figura 10: Objetos criados antes de a interao comear. Na Figura 11 esto dispostos os quatro tipos de mensagens existentes em um diagrama de sequncia e suas notaes. Na identificao da mensagem, ir a chamada de uma operao que est implementada no receptor da mensagem. Pode ainda estar na mensagem uma condio para que a mensagem seja enviada ou uma iterao. (MELO, 2004)

Fonte: HAMILTON; MILES, 2006.

Figura 11: Tipos de mensagem. Uma mensagem sncrona significa que o transmissor ir enviar uma mensagem ao receptor e aguardar a resposta deste. J em uma mensagem assncrona, o transmissor no ir esperar a resposta do receptor, mas ir continuar com as outras interaes subsequentes. (HAMILTON; MILES, 2006)

63

De acordo com Hamilton e Miles (2006), a mensagem de retorno significa que o mtodo foi finalizado e retornou o resultado. Mas o retorno no se faz necessrio pois j est implicito no envio de uma mensagem e pode tornar o diagrama muito carregado e talvez confuso. E as mensagens de criao e destruio servem para iniciar ou terminar um participante do diagrama. Nos diagramas de sequncia ainda possvel criar interaes que podem ser referenciadas por outros diagramas de sequncia, evitando assim redundncia. Na UML 2, preciso colocar a interao dentro de um frame e colocar o operador ref no cabealho. Quando a referncia for efetuada possvel ainda enviar parmetros para a interao (MELO, 2004) Melo (2004) ainda cita trs principais operadores nos diagramas de sequncia, sendo eles: opt: trecho opcional. loop: repetio de trecho. alt: trechos alternativos.

Fonte: HAMILTON; MILES, 2006.

Figura 12: Exemplo de Diagrama de Sequncia.

64

A Figura 12 um exemplo de diagrama de sequncia da criao de uma conta de blog regular. De acordo com Hamilton e Miles (2006), boa parte dos detalhes utilizados para iniciar a construo do diagrama est no fluxo principal dos casos de uso. O Administrator (administrador) inicia a transao requisitando a

AccountCreationUI (interface de usurio de criao de contas) criao de uma nova conta de blog. Logo aps, 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 so representados por um relacionamento assncrono, 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 criao de novas contas). Este por sua vez checa os dados do autor no AuthorCredentialsDB (banco de dados de credenciais do autor). Aps checados os dados do autor, o CreateNewAccountController cria o participante RegularBlogAccount (conta de blog regular) com os detalhes do autor e elimina o participante AuthorDetails. A operao de envio dos detalhes da conta chamada pelo prprio CreateNewAccountController, que ento 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 operao que notifica o administrador de que a conta foi criada. 2.5.3.4.4 Diagrama de Mquina 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 so determinados atravs dos valores de seus atributos ou ligaes com outros objetos. Um estado representado em um diagrama por um retngulo com cantos arredondados e se divide em dois compartimentos. O compartimento superior contm o nome do estado, caso exista um. E o compartimento inferior contm as atividades internas executadas por um objeto enquanto estiver no estado em questo. (MELO, 2004) Hamilton e Miles (2006) chamam de comportamento interno as atividades internas. Alm disso, eles adicionam mais um compartimento ao estado, que onde ficam as transaes internas, que causam reaes no estado, mas sem modificar o estado do objeto. As atividades internas so identificadas por trs tipos de expresses, segundo Melo (2004), e que esto dispostas a seguir: entry: ao executada quando o objeto entra no estado. exit: ao executada quando o objeto sai do estado. do: ao executada enquanto o objeto estiver no estado atual. As atividades internas possuem ainda um formato padro, descrito por Melo (2004), sendo ele o seguinte: nome-do-evento (parmetros) [condio-de-guarda] / expresso-ao A Figura 13 um exemplo simples de diagrama de mquina de estados. O crculo preenchido um estado que indica o incio da mquina de estados. Enquanto que o crculo preenchido e envolvido por outro crculo indica o fim da execuo da mquina de estados.

66

Fonte: HAMILTON; MILES, 2006.

Figura 13: Exemplo de Diagrama de Mquina de Estados. Ainda na Figura 13, a seta que parte de um estado para outro uma transio. Uma transio um relacionamento entre dois estados, onde um objeto ir passar de um estado para outro quando certas condies forem satisfeitas RUMBAUGH; JACOBSON, 2005) De acordo com Melo (2004), cada transio identificada por uma string no seguinte formato: nome-do-evento (parmetros) [condio-de-guarda] / expresso-ao Segundo Melo (2004), a condio de guarda indica quando uma transio iniciar, atravs de uma expresso booleana. A expresso ao so operaes ou atributos que sero executados se a transio iniciar. De acordo com Hamilton e Miles (2006), na UML ainda possvel que estados sejam concorrentes ou sequnciais. Melo (2004) descreve os subestados concorrentes como estados que ocorrem ao mesmo tempo e subestado sequncial como transaes que ocorrem sequencialmente. 2.5.3.4.5 Diagrama de Implementao Diagramas de implementao mostram aspectos de implementao fsica, incluindo a estrutura de componentes e a estrutura do sistema em tempo de execuo (runtime). (MELO, 2004, p.199) (BOOCH;

67

Os diagramas de implementao esto divididos em: Diagrama de Componentes Diagrama de Implantao 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 generalizaes e associaes com outras classes e componentes, tem uma interface e operaes. 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 retngulo representa o componente. Os quadrados localizados em cima da borda do

68

componente so as portas. Os crculos fechados so as interfaces fornecidas e os meios crculos so as interfaces necessrias. Uma interface fornecida um servio que o componente prov para outros componentes. Uma interface necessria a interface usada pelo componente para requisitar servios. As portas so janelas por onde as interaes de entrada e sada passam. E, ao contrrio das interfaces, as portas possuem identidades. (BOOCH; RUMBAUGH; JACOBSON, 2005) 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 tambm possuem portas e interfaces e que ligam entre si. As relaes de comunicao entre partes e portas ocorrem atravs de conectores. (BOOCH; RUMBAUGH; JACOBSON, 2005) Existem ainda conectores de delegao 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 converso) fornece as interfaces FeedProvider (fornecedor de feed) e DisplayConversor (conversor de tela). Essas duas interfaces so fornecidas por componentes que esto 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), ento se conecta atravs de delegao a uma porta que por sua vez se conecta atravs de dependncia a interface DataSource do componente BlogDataSource. O componente BlogDataSource composto por duas partes: Blog e Entry. Elas se comunicam com as portas atravs de conexes de delegao e entre si atravs de associao. B) Diagrama de Implantao O Diagrama de Implantao mostra a estrutura de ns nos quais os componentes e artefatos so 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 necessrio para a execuo do sistema. no n onde sero implementados os artefatos. A comunicao entre ns mais utilizada a associao. Mas qualquer outro tipo de relacionamento definido na UML pode ser utilizado. A comunicao definida ainda por um esteretipo que descreve o tipo de comunicao que estabelecida. (BOOCH; RUMBAUGH; JACOBSON, 2005) 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 Implementao. A Figura 16 mostra um exemplo diagrama de implementao. O cubo representa o n e os retngulos dentro dos ns so os artefatos. Existe ainda um relacionamento de dependncia entre o artefato contacts.exe com os componentes Sale e Contract. Os artefatos podem ainda ser listados dentro de um n ao invs de se utilizar a representao grfica dos artefatos. Os relacionamentos dos artefatos podem ser colocados em um diagrama a parte para tornar o diagrama com os ns mais limpo. (HAMILTON; MILES, 2006) 2.6 BANCO DE DADOS Atualmente, os bancos de dados tm papel fundamental em diversas aplicaes prticas. possvel afirmar que eles fazem parte da vida de muitas pessoas, mesmo que elas no tenham conhecimento a respeito. A popularizao da computao , em parte, devida ao banco de dados. (ELMASRI; NEVATHE, 2003)

71

Neste captulo esto descritos os conceitos de banco de dados, sistemas de banco de dados, modelagem conceitual (em especial modelagem ER) e modelagem lgica. 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 usurio solicita o acesso ao banco, usando uma sublinguagem prpria de dados, por exemplo, SQL. 2. O SGBD recebe a solicitao e a analisa. O SGBD verifica as ligaes externas para o usurio, o mapeamento externo/ conceitual correspondente, o esquema conceitual, o mapeamento conceitual/ interno e a definio da estrutura de armazenamento. 3. Por fim, o SGBD executa as operaes no banco de dados. O nvel externo caracterizado pela parte do usurio, tanto programador como usurio final. Mapeamentos internos e externos aplicam os modelos conceituais no banco de dados e vice versa. E o nvel interno uma pequena representao de todo o banco de dados, no 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 coleo de dados persistentes, que so usados pelas aplicaes de um sistema de determinada empresa. Em outras palavras, pode ser definido como um arquivamento eletrnico dos dados de uma organizao, em que podem ser manipulados por usurios

72

acrescentando, excluindo, buscando e alterando dados ou arquivos existentes na database.

O sistema de banco de dados basicamente um sistema de manuteno de registros por computador ou seja, um sistema cujo objetivo global manter as informaes e torn-las disponveis quando solicitadas. Trata-se de qualquer informao considerada como significativa ao indivduo ou organizao servida pelo sistema em outras palavras, que seja necessria ao processo de tomada de deciso daquele indivduo/ organizao (DATE, 1990, p.5).

2.6.3 Modelo Conceitual De acordo com Heuser (2001), o modelo conceitual a primeira etapa do projeto na construo de um banco de dados, que descreve de uma forma abstrata o banco de dados de sua aplicao em um SGBD registrando os dados, mas no demonstrando como estes esto armazenados num nvel de SGBD. O modelo conceitual est intimamente relacionado com a abordagem entidaderelacionamento, popularmente chamado de modelo ER. Nesta tcnica, 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 cdigo, sua descrio e seu preo bem como o tipo de produto relacionado. Na entidade Tipo de produto so

73

armazenadas informaes de cdigo e descrio, bem como os produtos daquele tipo (HEUSER, 2001). 2.6.3.1 Modelagem ER Segundo Heuser (2001), a modelagem ER considerada como padronizadora em relao ao modelo conceitual e mesmo na modelagem de orientao 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 so entidade, relacionamento, atributo, generalizao/ especializao e entidade associativa (HEUSER, 2001). 2.6.3.1.1 Entidade Heuser (2001) explica que o conceito fundamental da abordagem ER atribudo ao conceito de entidade, o ponto de partida inicial compreender seu significado. Para Heuser: entidade = conjunto de objetos da realidade modelada sobre os quais desejase manter informaes no banco de dados (HEUSER, 2001, p. 23). Atravs dessa definio podemos descrever que uma entidade um objeto do mundo real sobre o qual possvel gravar dados para um determinado sistema (HEUSER, 2001). A entidade representada atravs de um retngulo, contendo o nome da entidade conforme o exemplo citado na Figura 18.

Fonte: HEUSER, 2001, p. 23.

Figura 18: Exemplo de representao de entidades.

74

Cada um dos retngulos da Figura 18 descreve um conjunto de objetos sobre os quais se deseja guardar informaes. O primeiro retngulo referencia todas as pessoas que se deseja guardar e manter informaes no banco de dados. J no segundo retngulo, so designados todos os departamentos sobre os quais se deseja guardar informaes (HEUSER, 2001). 2.6.3.1.2 Relacionamento O relacionamento pode ser descrito como o conjunto de associaes entre as entidades, as ligaes e relaes entre os objetos (HEUSER, 2001). Em um DER, um relacionamento representado atravs 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 lotao:

Fonte: HEUSER, 2001, p. 24.

Figura 19: Representao grfica de um relacionamento. O exemplo da Figura 19 demonstra um banco de dados contendo as entidades DEPARTAMENTO e PESSOA, guardando informaes peculiares a sua classe e uma ligao entre essas entidades designada LOTAO (HEUSER, 2001). Para Heuser (2001), relacionamentos so caracterizados por sua cardinalidade (mnima/mxima), que podem ser binrios, ternrios e auto-relacionamento. A cardinalidade descreve a quantidade de vezes que uma ocorrncia de determinada entidade se relaciona a uma ocorrncia de outra entidade. Cardinalidade mxima representada por 1, para uma associao e n, para muitas associaes. Ela

75

no pode ser nula, pois expressa sempre o maior numero de possveis associaes entre entidades. A cardinalidade mnima possui dois valores, que so 0 e 1. O Valor 1, ou associao obrigatria, registra que determinada entidade x ocorre 1 vez dentro da entidade y. J o valor 0, ou associao opcional informa que determinada entidade no precisa estar relacionada com outra entidade em seu valor mnimo (HEUSER, 2001). Dentro da cardinalidade mxima existe o relacionamento binrio. Heuser nos descreve que:
A cardinalidade mxima pode ser usada para classificar relacionamentos binrios. Um relacionamento binrio aquele cujas ocorrncias envolvem duas entidades, 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 ocorrncia de 1 para 1 (1:1), expressando que um marido pode ter apenas uma esposa e uma esposa apenas uma instncia 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 INSCRIO. Um aluno pode se inscrever em apenas um curso. Um curso pode conter n alunos inscritos. H tambm dentro da cardinalidade mxima o relacionamento n:n, que representa muitos para muitos (HEUSER, 2001). A Figura 22 exibe um exemplo da associao n:n.

Fonte: HEUSER, 2001, p. 29.

Figura 22: Relacionamento n:n. Na Figura 22, descrita a relao CONSULTA entre MDICO e PACIENTE. Um mdico pode consultar vrios pacientes. Um paciente pode marcar consulta com vrios mdicos (HEUSER, 2001) Relacionamentos podem associar duas ou mais entidades. Relacionamento ternrio ocorre quando trs entidades se relacionam.
No caso de relacionamentos de grau maior que dois, o conceito de cardinalidade de relacionamento uma extenso no trivial do conceito de cardinalidade em relacionamentos binrios. Lembre-se que, em um relacionamento binrio R entre duas entidades A e B, a cardinalidade mxima

77

de A em R indica quantas ocorrncias de B podem estar associadas a cada ocorrncia de A. No caso de um relacionamento ternrio, a cardinalidade referese a pares de entidades. Em um relacionamento R entre trs entidades A, B e C, a cardinalidade mxima de A e B dentro de R indica quantas ocorrncias de C podem estar associadas a um par de ocorrncias de A e B (HEUSER, 2001, p. 30).

Fonte: HEUSER, 2001, p. 31.

Figura 23: Relacionamento ternrio com cardinalidade. Na Figura 23 mostrado um exemplo de associao ternria, tendo como entidades a CIDADE, DISTRIBUIDOR E PRODUTO. A relao entre eles est expressa na DISTRIBUIO, aonde existe um produto a ser distribudo numa determinada cidade por um distribuidor. A cardinalidade mxima expressada pelo nmero 1 se refere a cidade e o produto, podendo haver apenas um distribuidor deste produto por cidade, no existindo assim concorrncia. E o par de n expressa que os pares de entidades podem estar associados a vrias instncias entre eles, como por exemplo, a um par de (cidade, distribuidor) podem estar associados vrios 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 ocorrncia de um relacionamento ou uma entidade. Em outras palavras, um atributo guarda informaes sobre a entidade que se deseja armazenar. Atributos tambm 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 constituda por trs atributos.

Fonte: HEUSER, 2001, p. 34.

Figura 24: Cardinalidade em atributos. No exemplo da Figura 24, so atribudos a entidade CLIENTE, trs atributos: nome, cdigo e telefone. Quando a cardinalidade for 1, ou obrigatria como visto anteriormente, no posta a sua cardinalidade, ficando vazio como nos atributos nome e cdigo. J o atributo telefone, indica que um cliente pode ter 0 e n telefones cadastrados, sendo opcional (HEUSER, 2001). Atributos tambm podem estar contidos em relacionamentos, como pode ser visualizado na Figura 25.

79

Fonte: HEUSER, 2001, p. 34.

Figura 25: Atributos em relacionamentos. A Figura 25 mostra um DER aonde o relacionamento ATUAO possui um atributo, a funo que um engenheiro possui em um determinado projeto (HEUSER, 2001).
Esta [funo] no pode ser considerada atributo de ENGENHEIRO, j que um engenheiro pode atuar em diversos projetos exercendo diferentes funes. Tambm, no atributo de PROJETO, j que, em um projeto, podem atuar diversos engenheiros com funes diferentes (HEUSER, 2001, p. 35).

Segundo Heuser (2001), cada entidade deve possuir no mnimo um atributo identificador. Atributos identificadores tm a funo de diferenciar um atributo do outro, uma ocorrncia das demais concorrncias da mesma entidade. A Figura 26 abaixo demonstra um exemplo de entidade com um atributo identificador, aonde o cdigo diferencia as informaes das pessoas armazenadas:

Fonte: HEUSER, 2001, p. 36.

Figura 26: Identificador simples.

80

Uma entidade tambm 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 por diversos atributos. Considera-se um almoxarifado de uma empresa de ferragens organizado como segue. Os produtos ficam armazenados em prateleiras. Estas prateleiras encontram-se em armrios organizados em corredores. Os corredores so numerados seqencialmente a partir de um e as prateleiras so numeradas seqencialmente a partir de um dentro de um corredor. Assim, para identificar uma prateleira necessrio conhecer seu nmero e o nmero do corredor em que se encontra. Para cada prateleira deseja-se saber sua capacidade em metros cbicos (HEUSER, 2001, p. 36).

Atributos tambm podem ocorrer em relacionamentos, como o caso de uma consulta mdica, aonde existe um paciente e um mdico. O atributo identificador do relacionamento consulta sua data/hora (HEUSER, 2001). 2.6.3.1.4 Generalizao/Especializao De acordo com Heuser (2001), podem ser atribudas propriedades especficas, particulares a um subconjunto das ocorrncias (especializadas) de uma entidade genrica. So simbolizadas por um tringulo issceles conforme a Figura 28. Um exemplo bem prtico o caso de pessoa jurdica e pessoa fsica. Essas entidades podem ser associadas a uma entidade generalizada, chamada cliente ou pessoa (HEUSER, 2001). Na Figura 28 est apresentado um exemplo desta situao.

81

Fonte: HEUSER, 2001, p. 40.

Figura 28: Exemplo de generalizao/especializao. Na Figura 28, a entidade genrica CLIENTE assume dois atributos, sendo um deles identificador. Esses so atribudos tanto para PESSOA FSICA como PESSOA JURDICA. Os atributos de uma entidade especfica no se relacionam com os atributos de outra entidade. A pessoa fsica possui CIC (atual CPF), e a pessoa jurdica CGC (atual CNPJ) (HEUSER, 2001). As generalizaes/especificaes so divididas em dois tipos: total e parcial. Caso seja total, obrigatrio que a entidade genrica seja uma ou a outra especfica. No caso do cliente, ou ele ser pessoa fsica ou jurdica. J no caso de ser parcial, facultativo que a entidade genrica se especialize em uma das entidades relacionadas. Como por exemplo, nem toda entidade funcionrio dever ser motorista ou empregada, pois existe um atributo chamado tipo de funcionrio, generalizando as opes (Figura 29) (HEUSER, 2001).

82

Fonte: HEUSER, 2001, p. 41.

Figura 29: Exemplo de generalizao/especializao parcial. 2.6.3.1.5 Entidade Associativa Para Heuser (2001, p. 43): Uma entidade associativa nada mais que a redefinio de um relacionamento, que passa a ser tratado como se fosse tambm 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 prescrio de um determinado medicamento consulta. Ela no poderia ser relacionada somente ao mdico ou ao paciente, pois sem mdico ou sem paciente no existe prescrio de medicamento. No caso, a prescrio deve relacionar-se com a consulta, criando uma entidade associativa. Envolve-se o relacionamento com um retngulo, caracterizando-o como uma entidade (associativa), mas no deixando de ser relacionamento (HEUSER, 2001). 2.6.4 Modelo Lgico Para Heuser (2001, p.17): Um modelo lgico uma descrio de um banco de dados no nvel de abstrao visto pelo usurio do SGBD. Assim, o modelo lgico 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 usurio do SGBD, definindo como o banco de dados ser implementado em um SGBD especfico. Os detalhes internos de armazenamento de informaes que no tem influncia na programao do SGBD, no fazem parte do modelo lgico (HEUSER, 2001).

CAPTULO 3: RESULTADOS OBTIDOS Neste captulo apresenta-se a proposta do novo sistema, sua descrio, suas restries, requisitos levantados para o desenvolvimento do mesmo e resultado obtidos. 3.1 PROPOSTA DO NOVO SISTEMA 3.1.1 Descrio do Problema A empresa fictcia do ramo de gravaes possui como meio de controle uma planilha Excel, configurada com campos contendo informaes sobre o montante de valores mensais de entrada. Esse sistema de controle torna-se vago, pois apenas registra as entradas efetuadas, no compondo assim um regime de caixa consistente. De acordo com o problema, viu-se a oportunidade de estudar o caso, aliado com a prtica profissional direcionada III, de formular uma anlise orientada a objetos para o regime de caixa da empresa, aonde o material includo no relatrio, como os requisitos, diagramas ER e UML, podero servir futuramente para uma possvel implantao em software. 3.1.2 Descrio das necessidades dos interessados Neste item, so listados os requisitos funcionais, no funcionais e de domnio, levantados para a criao 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, so apresentados os requisitos que esto diretamente ligados as funcionalidades do software.
RF1 Descrio: Prioridade: RF2 Descrio: Prioridade: RF3 Descrio: Lanamento de entradas Lanamento de entradas no caixa. Alta Lanamento de sadas Lanamento de sadas do caixa. Alta Cadastro de categorias Cadastrar as categorias de entradas e sadas que podem ocorrer no caixa. Ex.: vendas vista, vendas a prazo, amortizaes, contas de luz, contas de telefone, etc. Alta Cadastro de funcionrios Cadastro dos funcionrios da empresa e que tero acesso ao sistema. Dados para o cadastro: nome, CPF, RG, telefones, logradouro, etc. Mdia Relatrio por perodo O sistema deve permitir a gerao de um relatrio que mostre todas as entradas e sadas de caixa em determinado perodo de tempo. Indicando o saldo inicial e final do caixa. Alta Relatrio por categoria O sistema deve permitir a gerao de um relatrio que mostre as entradas ou sadas de uma categoria em determinado perodo de tempo. Alta Abertura do caixa O sistema s ir permitir o lanamento de entradas e sadas aps a abertura de caixa. Alta Fechamento do caixa No final de um perodo, que pode ser o fim de expediente da empresa ou o fim do turno de um funcionrio, o caixa deve ser fechado para que as entradas e sadas correspondentes aquele perodo sejam computadas e conferidas para verificar eventuais inconsistncias e para que o saldo em caixa seja ajustado (recolhendo ou adicionando saldo a ele) Alta Consultar lanamentos O sistema deve permitir a consulta aos lanamentos efetuados no sistema. Mdia Estornar lanamentos O sistema deve permitir o estorno de lanamentos efetuados no sistema, para que eventuais erros sejam sanados. Mdia

Prioridade: RF4 Descrio: Prioridade: RF5 Descrio:

Prioridade: RF6 Descrio: Prioridade: RF7 Descrio: Prioridade: RF8 Descrio:

Prioridade: RF9 Descrio: Prioridade: RF10 Descrio: Prioridade:

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.

Quadro 5: Requisitos Funcionais.

86

3.1.2.2 Requisitos no-funcionais No Quadro 6, so listados todos os requisitos no-funcionais, que expressam as qualidades especficas ou condies que o software deve atender.
RNF1 Descrio: Categoria: Obrigatoriedade: RNF2 Descrio: Categoria: Obrigatoriedade: Sistema dever disponibilizar o recurso de backup O sistema dever disponibilizar uma forma de se realizar backup dos dados armazenados no sistema. Confiabilidade Recomendvel Usurio e senha Somente os funcionrios cadastrados podero ter acesso ao sistema. Sendo que estes tero um login e uma senha. Segurana Obrigatrio

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.

Quadro 6: Requisitos No-Funcionais 3.1.2.3 Requisitos de domnio No Quadro 7, esto listados os requisitos de domnio que so regras de negcio que a empresa adota e descrevem caractersticas do sistema.
RD1 Descrio: Fonte: RD2 Descrio: Fonte: Saldo mnimo de caixa O caixa deve ter um saldo mnimo de caixa para iniciar suas operaes. Domnio do negcio Ajuste do caixa O caixa deve ser ajustado quando houver inconsistncias no mesmo e deve ser conferido novamente. Domnio do negcio

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.

Quadro 7: Requisitos de Domnio. 3.1.3 Descrio do sistema proposto O escopo deste projeto se concentrou no regime de caixa, ou seja, as entradas e sadas que efetivamente ocorreram em caixa. Para descrever o sistema proposto,

foram desenvolvidos quatro diagramas da UML e um diagrama de entidadesrelacionamentos.

87

Nos diagramas da UML possvel notar a ligao entre os mesmos, pois cada um deles tem como objetivo mostrar uma viso do sistema. Eles tem um papel fundamental na validao de como o sistema ir funcionar, o que pode evitar muitos erros nas prximas etapas de um projeto. A seguir esto dispostos os diagramas desenvolvidos nesta anlise bem como uma detalhada descrio 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 possvel visualizar os acontecimentos dentro do sistema e a interao deste com os agentes externos a ele. Os atores deste diagrama, aqueles que iro disparar os casos de uso, so: Chefe de Caixa, Operador de Caixa e Administrador do Sistema. Estes trs atores so especializaes do ator Funcionrio, pois aqueles no deixam de ser um funcionrio, mas com algumas especialidades. Os casos de uso esto envolvidos por um retngulo, que a fronteira do sistema, ou seja, tudo dentro daquele retngulo faz parte do sistema. Os casos de uso podem estar divididos em: primrios e secundrios. Os casos de uso primrios so: Abertura de Caixa, Incluir Lanamento e Fechamento do Caixa. So as atividades diretamente relacionadas com aquilo que foi proposto para ser automatizado. A abertura do caixa consiste na autenticao do chefe de caixa que ir fazer a abertura do caixa e ento o operador de caixa far sua autenticao e poder realizar suas tarefas. A autenticao o ato do usurio de informar seu login e senha, essa

88

operao est representada no diagrama pelo <<include>> do caso de uso Efetuar Login. O caso de uso Incluir Lanamento o foco deste sistema, consiste no lanamento das entradas e sadas que ocorreram no caixa de determinado perodo. Esta atividade desempenhada pelo Operador de Caixa. Dentro deste caso de uso podem ocorrer fatos que fogem do ambiente perfeito. Estes desvios so representados pelos <<extend>> que partem do caso de uso que ser includo nesta exceo que pode ocorrer e apontam para o caso de uso Incluir Lanamento.

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.

Figura 31: Diagrama de Casos de Uso. O Fechamento de Caixa representa o fim de um perodo, que pode ocorrer devido ao fim do expediente ou do turno de um operador de caixa. Quando o caixa vai ser fechado uma conferncia do mesmo feita para verificar eventuais inconsistncias que devem ser corrigidas para que o caixa possa ento ser fechado.

89

Todos os outros casos de uso so secundrios, pois no trazem benefcios diretos para a empresa, mas ainda assim so necessrios para que o sistema funcione. O Cadastro de Categoria necessrio para que existam categorias que identifiquem os lanamentos. Estornar Lanamento um caso de uso que ocorre quando algum lanamento foi includo em caixa com algum erro. Para que esse erro seja corrigido o estorno do lanamento efetuado. O estorno consiste em realizar um novo lanamento com o mesmo valor do lanamento a ser estornado mas com direo diferente. Ou seja, se o lanamento a ser estornado era uma entrada o lanamento de estorno ser uma sada. Os casos de uso Consultar Lanamentos e Gerao de Relatrios so atividades que tem por objetivo demonstrar as entradas e sadas do caixa por perodos, ou por uma determinada categoria. Seria ainda possvel visualizar apenas as sadas ou apenas as entradas em caixa. O Cadastro de Funcionrios um controle de segurana do sistema, onde todos os funcionrios que tero acesso ao sistema devem estar cadastrados e ento podero ter um login para acessar o sistema. E o Backup tambm uma atividade de segurana que deve ser feita periodicamente. O Quadro 8 mostra as descries de cada caso de uso. As descries detalham o caso de uso, apontado quem so os atores envolvidos, quem so os interessados. Que condies devem ser atendidas para que o caso ocorra e como ir ficar aps o caso de uso ter ocorrido. Os requisitos correlacionados com o caso de uso so referenciados aqui e podem ser consultados nos Quadros 7, 6 e 5. O fluxo principal de cada caso de uso mostra a sequncia de passos que ocorrem dentro do caso de uso em um mundo perfeito. Enquanto que o tratamento de excees descreve os desvios que podem ocorrer do fluxo principal.
Caso de Uso: Abertura do Caixa

90

Atores: Interessados: Pr-condies: Ps-condies: Requisitos Correlacionados:

Chefe de Caixa e Operador de Caixa Chefe de Caixa e Operador de Caixa O caixa no deve ter sido aberto ainda e o chefe de caixa deve estar logado no sistema. O caixa deve estar aberto e pronto para receber lanamentos ou outras operaes. RF7 1. O chefe de caixa abre o sistema. 2. Incluso do caso de uso "Efetuar Login" para o chefe de caixa. 3. O chefe de caixa escolhe no sistema a opo de abertura de caixa. 4. O sistema confirma que o caixa foi aberto. 5. Incluso do caso de uso "Efetuar Login" para o operador de caixa. 6. O sistema est pronto para ser operado pelo operador de caixa. 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. Incluir Lanamento Operador de Caixa Operador de Caixa O Caixa deve estar aberto e o operado de caixa deve estar logado. O lanamento deve ter sido includo no sistema e atribudo ao operador de caixa que efetuou o lanamento. RF1 e RF2 1. O operador de caixa escolhe no sistema a opo de incluso de lanamentos. 2. O sistema solicita os dados do lanamento. 3. O operador de caixa informa os dados solicitados e envia-os para o sistema. 4. O sistema inclui os dados do lanamento e atualiza os totais do caixa. 1a. O caixa no 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 lanamento no existe no sistema. 2a.1 Estende o caso de uso "Cadastro de Categoria". 2a.2 Retorna ao fluxo principal do passo 2. 4a. Existem incorrees no lanamento. 4a.1 O caso de uso "Estornar Lanamento estendido. Fechamento do Caixa Chefe de Caixa e Operador de Caixa Chefe de Caixa e Operador de Caixa O caixa deve estar aberto. O caixa deve estar fechado. RF8, RD1 e RD2

Fluxo Principal:

Tratamento de Excees: Caso de Uso: Atores: Interessados: Pr-condies: Ps-condies: Requisitos Correlacionados:

Fluxo Principal:

Tratamento de Excees:

Caso de Uso: Atores: Interessados: Pr-condies: Ps-condies: Requisitos Correlacionados:

91

Fluxo Principal:

Tratamento de Excees: Caso de Uso: Atores: Interessados: Pr-condies: Ps-condies: Requisitos Correlacionados:

1. O turno de um funcionrio ou o expediente da empresa acabou. 2. O chefe de caixa pede para o operador de caixa fazer a confercia das entradas e sadas para verificar eventuais inconsistncias. 3. O chefe de caixa confirma a conferncia do caixa. 4. O chefe de caixa ajusta o saldo mnimo do caixa. 5. O chefe de caixa faz o fechamento do caixa. 3a. Existem inconsistncias no caixa do perodo. 3a.1 O chefe de caixa faz o ajuste do caixa de acordo com a poltica da empresa. 3a.2 Retorna ao passo 3 do fluxo principal. Extornar Lanamento Chefe de Caixa Chefe de Caixa e Operador de Caixa Os dados de um lanamento devem estar incorretos. O lanamento deve ter sido estornado no sistema. RF10 1. O operador de caixa informa ao chefe de caixa que os dados de um lanamento esto incorretos e o estorno deve ser efetuado. 2. O chefe de caixa solicita ao operador de caixa o cdigo deste lanamento. 3. O chefe de caixa entra no sistema e solicita o estorno de um lanamento. 4. O sistema solicita o cdigo do lanamento. 5. O chefe de caixa informa o cdigo do lanamento. 6. O sistema efetua o estorno e atualiza o contador de estornos do caixa e os totais do caixa. 2a. O operador de caixa no sabe o cdigo do lanamento. 2a.1 O caso de uso "Consultar Lanamentos" estendido. 2a.2 O operador de caixa informa algum parmetro a respeito do lanamento para o chefe de caixa. 2a.3 O chefe de caixa utiliza o parmetro para encontrar o lanamento. 2a.4 Retorna ao fluxo principal do passo 3. Cadastro de Categoria Chefe de Caixa Chefe de Caixa e Operador de Caixa A categoria no deve estar cadastrada no sistema. A categoria deve estar cadastrada no sistema. RF3 1. O chefe de caixa escolhe a opo de cadastro de categoria no sistema. 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 da categoria.

Fluxo Principal:

Tratamento de Excees:

Caso de Uso: Atores: Interessados: Pr-condies: Ps-condies: Requisitos Correlacionados:

Fluxo Principal:

Tratamento de Excees:

92

Caso de Uso: Atores: Interessados: Pr-condies: Ps-condies: Requisitos Correlacionados:

Consultar Lanamentos Chefe de Caixa Chefe de Caixa O chefe de caixa deve estar logado no sistema. O chefe de caixa deve estar com as informaes que buscou. RF9 1. O chefe de caixa escolhe a opo consultar lanamentos no sistema. 2. O sistema solicita o preenchimento de algum parmetro para que a consulta seja efetuada. 3. O chefe de caixa informa os parmetros que deseja. 4. O sistema busca pelos lanamentos relacionados com os parmetros e retorna os resultados ao chefe de caixa. Gerao de Relatrios Chefe de Caixa Chefe de Caixa O chefe de caixa deve estar logado no sistema. O chefe de caixa deve estar com o relatrio desejado. RF5 e RF6 1. O chefe de caixa escolhe a opo para gerao de relatrios no sistema. 2. O sistema solicita que o chefe de caixa escolha o tipo de relatrio. 3. O chefe de caixa informa o tipo de relatrio ao sistema. 4. O sistema solicita o perodo desejado para que o relatrio seja gerado. 5. O chefe de caixa informa o perodo desejado. 6. O sistema gera o relatrio para o chefe de caixa. Efetuar Login Funcionrio Funcionrio O funcionrio sistema deve estar cadastrado no mesmo e no deve estar logado. O funcionrio deve estar logado no sistema. RNF2 1. O sistema solicita autenticao por login e senha. 2. O funcionrio informa ao sistema seu login e senha. 3. O sistema verifica se os dados esto corretos e autoriza o acesso ao sistema para o funcionrio. 4. O usurio pode utilizar o sistema de acordo com suas permisses.

Fluxo Principal:

Tratamento de Excees: Caso de Uso: Atores: Interessados: Pr-condies: Ps-condies: Requisitos Correlacionados:

Fluxo Principal:

Tratamento de Excees: Caso de Uso: Atores: Interessados: Pr-condies: Ps-condies: Requisitos Correlacionados:

Fluxo Principal:

93

2a. O funcionrio no est cadastrado no sistema. 2a.1 Estende o caso de uso "Cadastro de Funcionrio". 2a.2 Retorna ao passo 1 do fluxo principal. Tratamento de Excees: 2b. Os dados informados esto incorretos. 2b.1 O sistema informa que o login e/ou senha esto incorretos. 2b.2 Retorna ao passo 1 do fluxo principal. Caso de Uso: Atores: Interessados: Pr-condies: Ps-condies: Requisitos Correlacionados: Cadastro de Funcionrio Administrador do Sistema e Funcionrio Administrador do Sistema e Funcionrio O funcionrio no deve estar cadastrado no sistema. O funcionrio deve estar cadastrado no sistema e possuir um login e senha. RF4 1. O administrador do sistema solicita os dados do funcionrio. 2. O funcionrio informa os dados ao administrador do sistema. 3. O administrador do sistema verifica se o usurio j no est cadastrado. 4. O administrador do sistema escolhe a opo de cadastro de funcionrios no sistema e informa os dados fornecidos pelo funcionrio. 5. O sistema cadastra o funcionrio no sistema, cadastra um login gerado a partir dos dados fornecidos e cria uma senha aleatria para o funcionrio e retorna uma mensagem de status. 6. O funcionrio est cadastrado no sistema e j pode se logar ao mesmo. 4a. O funcionrio j est cadastrado no sistema. 4a.1 O sistema informa que o usurio j est cadastrado no sistema. 4a.2 A operao de cadastro de funcionrio cancelada. Backup Administrador do Sistema Administrador do Sistema O administrador do sistema deve estar logado no sistema. O administrador deve estar em posse do backup do sistema. RNF1 1. O administrador do sistema solicita a opo 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. 4a. No existem dados para salvar. 4a.1 O sistema informa que no existem dados salvos. 4a.2 O administrador do sistema sai do sistema.

Fluxo Principal:

Tratamento de Excees: Caso de Uso: Atores: Interessados: Pr-condies: Ps-condies: Requisitos Correlacionados:

Fluxo Principal:

Tratamento de Excees:

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.

Quadro 8: Descrio 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. Alm disso, atravs do diagrama de classes possvel modelar o esquema lgico 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 operaes das classes esto dispostos no Quadro 9. A classe Funcionrio uma superclasse, ou seja, ela possui outras classes ligadas a ela atravs da generalizao. Em outras palavras, as classes Chefe de Caixa, Operador de Caixa e Administrador do Sistema so especializaes da classe Funcionrio. O Funcionrio possui ainda agregado a ele a classe de Login, essa classe contm os logins e senhas dos funcionrios. Um funcionrio pode ter nenhum ou mais logins. O Funcionrio ainda aquele que utiliza a entidade Sistema. Este, por sua vez, uma entidade que faz o intermdio entre os funcionrios e as outras classes do sistema. A classe Caixa representa um perodo do caixa, nela ficam armazenadas a data inicial e final de operao do caixa, bem como quem o abriu (Chefe de Caixa) e quem o operou (Operador de Caixa). Um caixa pode ter nenhum ou mais Lanamentos, que esto agregados ao caixa. Cada Lanamento tem um valor, a data em que ocorreu e sua especializao, que pode ser Entrada ou Sada. Um Lanamento 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 esteretipo <<actor>> so os mesmos atores do diagrama de casos de uso. As ligaes entre os atores e as outras classes mostram os

95

relacionamentos que eles precisam ter para que sejam capazes de desempenhar seus papis, ou seja, trocar mensagens entre as classes de modo a realizar alguma tarefa especfica do sistema.

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.

Figura 32: Diagrama de Classes. Os atributos e operaes de cada classe esto dispostos no Quadro 9.
Classe: Funcionrio

96

int Codigo String CPF Atributos: String Endereco String Nome String RG Mtodos: Classe: Atributos: void void void void void void confirmarConferenciaCaixa() estornarLanamento() informarCodigoLancamento() selecionarPeriodoRelatorio() selecionarTipoRelatorio() solicitarDadosCategoria() void fornecerDadosCadastrais() void receberLoginSenha(String Login, String Senha) void solicitarAutenticacao() Chefe de Caixa

Mtodos:

Classe: Atributos: Mtodos: Classe: Atributos:

Operador de Caixa void conferirCaixa() void informarCodigoLancamento() void informarDadosLancamento() Administrador do Sistema void void void void void Login String Login String Senha void alterarLogin() void autenticarLogin(String Login, String Senha) void consultarLogin() void incluirLogin(String Login, String Senha) Caixa alterarFuncionario() alterarFuncionario() consultarFuncionario() efetuarBackup() incluirFuncionario()

Mtodos:

Classe: Atributos:

Mtodos: Classe:

Date DataFim Date DataInicio Currency SaldoFinal Currency SaldoInicial Atributos: Currency SaldoMinimo Currency TotalEntradas int TotalEstornos Currency TotalSaidas

97

Mtodos:

void void void void void void void void void

abrirCaixa() ajustarCaixa() ajustarSaldoMinimo(Currency SaldoMinimo) atualizarEstornos(int extornos) atualizarSaldosTotais(String DadosLancamento) conferirCaixa() fecharCaixa() gerarRelatorio(int TipoRelatorio, int PeriodoRelatorio) gerarRelatorioCaixa(int CaixaID)

Classe:

Lanamentos Currency Valor Atributos: Date Data void consultarLancamento() void consultarLancamentosCaixa(int CaixaID) Mtodos: void estornarLancamento(int Codigo) void incluirLancamento(String DadosLancamento) Classe: Categorias Atributos: String Nome void alterarCategoria() Mtodos: void consultarCategoria(ArrayList DadosCategoria) void incluirCategoria() Classe: Sistema Atributos: String Nome String Versao void abrirCaixa() void abrirSistema() void alterarFuncionario() void cadastrarCategoria() Funcionrio 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()

Mtodos:

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.

Quadro 9: Atributos e Operaes das Classes. 3.1.3.1.3 Diagramas de Sequncia Um diagrama de sequncia mostra a ordem dos acontecimentos em um caso de uso bem como quem so os envolvidos. A importncia de se descrever

98

detalhadamente os casos de uso pode ser justificada com a construo dos diagramas de sequncia, pois estes se baseiam inteiramente nas descries. E ainda mais, com a construo dos diagramas de sequncia, os fluxos dos casos de uso podem ser validados ou no. Neste trabalho foram criados os diagramas de sequncia para os principais casos de uso, eles esto dispostos nas prximas sees. A) Abertura de Caixa A Figura 33 ilustra a sequncia do caso de uso Abertura de Caixa. Quem inicia essa sequncia o Chefe de Caixa que abre o Sistema, este por sua vez solicita ao Chefe de Caixa a autenticao para entrar no sistema. O Chefe de Caixa efetua o login, enviando ao sistema o Login e a Senha. O Sistema armazena estes parmetros e envia a classe Login, que verifica se os parmetros so vlidos e retorna o resultado. Se a autenticao for bem sucedida, ento o Chefe de Caixa vai chamar a funo abrirCaixa() no Sistema. Este ir criar um novo objeto da classe Caixa, atravs da funo abrirCaixa(). Cada novo objeto da classe Caixa ser um perodo novo de caixa, com um operador realizando os lanamentos. Se o caixa estiver aberto o Sistema ir solicitar ento a autenticao 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 parmetros. Se a autenticao for bem sucedida o Operador de Caixa estar apto a efetuar lanamentos.

99

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.

Figura 33: Diagrama de Sequncia (Abertura de Caixa). B) Cadastro de Categorias Na Figura 34 possvel visualizar o diagrama de sequncia para o cadastro de categoria. O Chefe de Caixa solicita ao sistema o cadastro de categoria atravs do mtodo 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 Sequncia (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 no existe. Caso ela exista o sistema retorna uma mensagem informando que a categoria j existe. De outro modo, o Sistema invocar o mtodo incluirCategoria() da classe Categorias, enviando como parmetro os dados da categoria informados pelo Chefe de Caixa. Este mtodo criar uma nova instncia da classe categorias contendo os dados que foram recebidos por parmetro. Depois de includa a categoria o Sistema retorna a mensagem de sucesso ao Chefe de Caixa. C) Cadastro de Funcionrio O diagrama de sequncia do cadastro de funcionrio pode ser visto na Figura 35. A sequncia iniciada com o Administrador do Sistema que solicita ao Funcionrio os seus dados para realizar o cadastro e o Funcionrio fornece os dados solicitados.

101

O Administrador do Sistema, em posse dos dados do Funcionrio, faz uma consulta no Sistema para verificar se o Funcionrio j foi cadastrado. Se o Funcionrio no estiver cadastrado no Sistema, o Administrador do Sistema inclui o usurio atravs da operao incluirFuncionario(), enviando como parmetro os dados do funcionrio.

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.

Figura 35: Diagrama de Sequncia (Cadastro de Funcionrio). Durante a incluso do funcionrio, o Sistema gera para este um login e uma senha e cria uma nova instncia da classe Login atravs do mtodo incluirLogin, enviando por parmetros o login e a senha criadas anteriormente. Aps ter sido includo o funcionrio no sistema e seu login ter sido criado, o Sistema retorna ao Administrador do Sistema o login e a senha do funcionrio. Por fim, o Administrador repassa o login e senha ao funcionrio.

102

D) Estornar Lanamento Na Figura 36 est disposto o diagrama de sequncia de estornar lanamento. Quando um lanamento for includo com algum erro, este deve ser estornado. O Operador de Caixa solicitar ao Chefe de Caixa o estorno de um lanamento. O Chefe de Caixa ir pedir ao Operador de Caixa o cdigo do lanamento que ser repassado ao Chefe de Caixa. Ento, o Chefe de Caixa ir solicitar ao Sistema o estorno de um lanamento, este por sua vez solicita o cdigo do lanamento a ser estornado. Informado o cdigo, o Sistema realiza o estorno do lanamento desejado invocando o mtodo

estornarLancamento() da classe Lanamentos, informando o cdigo do lanamento atravs de parmetro. Estornado o lanamento, o Sistema atualiza junto a classe Caixa, o contador de estornos que foram efetuados durante o perodo corrente do Caixa. Em sequncia, ele tambm atualiza os saldos totais do Caixa, enviando por parmetro 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 no executada com xito.

103

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.

Figura 36: Diagrama de Sequncia (Estornar Lanamento). 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 conferncia do caixa para verificar se no existe alguma inconsistncia. Enquanto o Caixa estiver com inconsistncias, ser feita a conferncia do Caixa e o ajuste do Caixa, que uma forma utilizada para sanar as inconsistncias encontradas. Para efetuar a conferncia o Operador de Caixa chama a operao conferirCaixa() da classe Sistema que, por sua vez, chama a operao conferirCaixa() da classe Caixa. O Caixa faz a gerao de um relatrio do caixa corrente (chamando um mtodo prprio) e tambm uma consulta na classe Lanamentos para resgatar todas as entradas e sadas associadas ao caixa corrente. Todas estas informaes so

104

entregues ao Sistema que repassa para o Operador de Caixa que pode ento fazer a verificao destes dados. Caso haja inconsistncia em Caixa, o Operador de Caixa vai ento realizar o ajuste de caixa atravs do mtodo ajustarCaixa() do Sistema que chama o mtodo correspondente na classe Caixa. Efetuado o ajuste, o caixa conferido novamente, se no houver mais inconsistncias preciso ento haver a confirmao desta conferncia de Caixa. A conferncia de caixa e posterior ajuste repetida at que no existam mais inconsistncias, isso est representado no diagrama pela retngulo com loop. A confirmao da conferncia do Caixa efetuada pelo Chefe de Caixa que ir confirmar que o Caixa est consistente, para que este possa ento ser fechado. Com o caixa conferido, preciso fazer o ajuste do saldo mnimo que permanecer em Caixa e ser o saldo inicial do prximo Caixa.

105

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.

Figura 37: Diagrama de Sequncia (Fechamento de Caixa). O saldo mnimo vai depender da empresa, e tambm do ritmo de vendas. Com um volume maior de vendas existe uma necessidade maior de dinheiro em caixa, caso contrrio, no existem motivos para deixar grandes quantidades em caixa. Com o saldo mnimo ajustado, o Chefe de Caixa pode ento fechar o caixa, que ser o encerramento das atividades daquele perodo de caixa. F) Gerao de Relatrios A gerao de relatrios que est ilustrada na Figura 38 consiste no resgate de lanamentos atravs do informe de parmetros de busca, como perodo e categoria. A

106

gerao dos relatrios de responsabilidade do Chefe de Caixa. Este solicita ao Sistema a gerao de relatrio. O Sistema ento pede que o Chefe de Caixa informe o tipo de relatrio desejado, que pode ser um relatrio por perodo ou por categoria. Mesmo que tenha sido escolhida a gerao de relatrio por categoria, ainda assim preciso informar o perodo desejado, para que seja possvel filtrar melhor as informaes desejadas. Informados ao Sistema o tipo de relatrio e o perodo do mesmo, o Sistema ir invocar o mtodo gerarRelatorio() da classe Caixa, enviando atravs do mtodo os parmetros de tipo de relatrio e perodo. O Caixa, para resgatar as informaes dos lanamentos precisar ainda se comunicar com os Lanamentos, para resgatar suas informaes de acordo com os parmetros desejados pelo Chefe de Caixa.

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.

Figura 38: Diagrama de Sequncia (Gerao de Relatrios). Como mostra o diagrama, sero feitas vrias buscar (representado por [*]), uma para cada categoria e o intervalo do perodo. Resgatados estas informaes, o Caixa as repassa para o Sistema que entrega o relatrio ao Chefe de Caixa.

107

G) Incluir Lanamento A incluso de lanamentos, como possvel visualizar na Figura 39, a principal atividade do sistema por ser responsvel pelo registro das entradas e sadas ocorridas em caixa. Esses registros so de responsabilidade do Operador de Caixa.

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.

Figura 39: Diagrama de Sequncia (Incluir Lanamento). O primeiro passo nessa sequncia verificar se o caixa est aberto para receber lanamentos. Caso ele esteja fechado (exceo representada pelo retngulo com o operador opt) o diagrama de sequncia de Abertura de Caixa referenciado,

108

indicando que esta sequncia dever ser percorrida para que os lanamentos em caixa possam ser efetuados. Com o caixa aberto e o Operador de Caixa logado ao sistema a incluso de lanamentos j pode ocorrer normalmente. Ela iniciada pelo Operador de Caixa que solicita ao Sistema a incluso de lanamento. Em contrapartida, o Sistema solicita ao Operador de Caixa os dados do lanamento. E quando recebidos os dados, o Sistema faz a verificao da categoria para se certificar de que ela existe, caso no exista a sequncia de Cadastro de Categoria referenciada. Depois de criado o novo lanamento, os saldos totais do caixa so atualizados pelo Sistema, incluindo o valor do lanamento que foi efetuado. Uma mensagem de status retornada ao Operador de Caixa, indicando sucesso ou falha na incluso do lanamento. Alm disso, caso o Operador de Caixa encontre alguma incorreo no lanamento includo, o diagrama de sequncia Estornar Lanamento referenciado, ou seja, o estorno do lanamento efetuado. Depois de feita a verificao da categoria, o lanamento j pode ser includo. Isso ocorre quando o Sistema chama a operao incluirLancamento() da classe Lanamentos, enviando como parmetro os dados do lanamento fornecidos pelo Operador de Caixa. A incluso de um novo lanamento cria uma nova instncia da classe Lanamentos. 3.1.3.1.3 Diagramas de Mquina de Estados Atravs dos diagramas de mquina de estados possvel ver a sequncia de estados pelo qual um objeto passa durante sua linha de vida em resposta a eventos. Atravs dos diagramas de sequncia possvel montar o diagrama de mquina de estados, pois aquele mostra a interao entre os objetos e os estmulos que eles recebem e enviam.

109

Foram construdos neste trabalho dois diagramas de mquina de estados, um para a classe Caixa e outro para a classe Lanamentos. Outras classes no possuem tanta importncia para que se tornasse necessria a construo de uma diagrama de estados. Os dois diagramas construdos esto nas sees consequentes. A) Classe Caixa A classe Caixa uma das principais classes do sistema, nela ficam armazenados os dados do perodo de operao do caixa e os totais de entradas e sadas. 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 lanamentos vinculados a ele. Do estado Aberto ele pode passar para o estado Gerando Relatrio ou Consultando. Quando o relatrio 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 conferncia do caixa e este passar para o estado Conferindo. Enquanto ele permanecer nesse estado consultas a lanamentos sero feitas. Depois de efetuada a conferncia necessria apurar se existem inconsistncias em caixa. Caso haja necessrio ser feito o ajuste do caixa, onde este passa para o estado Ajustando Caixa. Quando o caixa estiver ajustado, a conferncia novamente efetuada para garantir que o caixa est correto. Estando sem nenhum erro, o caixa ir passar para o estado Ajustando Saldo Mnimo, que o ajuste do valor que permanecer em caixa e ser o saldo inicial do prximo perodo de caixa. Com o saldo ajustado, o caixa pode ento ser fechado pelo Chefe de Caixa, passando o caixa ento para o estado Fechado, no podendo mais este ser aberto.

110

No estado fechado, o caixa pode ainda passar para o estado de Gerando Relatrio e Consultando, mas sempre retornado ao estado Fechado.

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.

Figura 40: Diagrama de Mquina de Estados (Caixa). B) Classe Lanamentos A classe Lanamentos um agregado da classe Caixa, onde um Caixa possui vrios Lanamentos. Cada instncia da classe Lanamento possui um valor, uma data e uma categoria agregada. Todo Lanamento, em primeira instncia criado pelo Operador de Caixa, neste estado ele pode possuir seus valores, mas ele ainda no uma instncia de

111

Lanamentos. Quando o Operador de Caixa efetua a incluso deste Lanamento, ento ele passa a fazer parte da classe Lanamentos.

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.

Figura 41: Diagrama de Mquina de Estados (Lanamentos). Depois de includo, o lanamento pode ainda ser consultado, que representado no diagrama pelo estado Consultando. Depois de finalizada a consulta, o lanamento retornar ao estado Includo. 3.1.3.1 Diagrama de Entidades-Relacionamentos O diagrama de entidades-relacionamentos (Figura 42) foi construdo em cima do diagrama de classes da UML, com as devidas modificaes, mas mantendo a mesma proposta inicial do projeto. A entidade Caixa responsvel por armazenar o intervalo de perodo de operao do caixa (Caixa_Data_Inicio e Caixa_Data_Fim), pelos saldos inicial, final, mnimo e pelos saldos totais de entradas e sadas. No caixa haver um funcionrio que ser o operador e outro que ser o chefe do caixa, por isso existe uma ligao N:N entre Caixa e Funcionrios. O que diferenciar cada funcionrios ser o seu cargo, que

112

uma relao N:1 no identificada, significando que o funcionrio pode ter apenas um cargo e um cargo pode pertencer a vrios funcionrios.

Fonte: BORDIN; GUNKEL; ACKERMANN; BENEDETTI; REIS; ROCKENBACH, 2009.

Figura 42: Diagrama de Entidades-Relacionamentos. Cada funcionrio identificado atravs de um cdigo, que a chave primria. Um funcionrio ter ainda seu CPF cadastrado, alm de possuir um ou mais telefones, e estes podem pertencer a apenas um funcionrio. Para ter acesso ao sistema, um funcionrio precisa tambm de um login e uma senha, estes ficam armazenados na entidade Logins, sendo que um funcionrio pode ter mais de um login, e este pertence a apenas um funcionrio. Retornando ao Caixa, ele composto por lanamentos (relao 1:N), sendo que um lanamento deve pertencer a um caixa. Cada lanamento possui ainda um

113

valor e uma data (de ocorrncia). Ele classificado em uma categoria (conta de luz, vendas, aluguel) e em um tipo de lanamento (entrada ou sada). Em ambas as situaes as ligaes entre as entidades so N:1, isso significa que um uma categoria ou tipo pode ter vrios lanamentos, e este s pode se ligar a uma categoria ou tipo. 3.1.4 Resultados esperados Atravs dos diagramas da UML buscou-se a ilustrao das vrias vises do sistema de uma maneira compreensvel e lgica. A realizao de uma anlise consistente tem o intuito de criar uma base forte para as prximas etapas de um projeto de sistemas. Evitando problemas que dentro da anlise podem ser resolvidos com uma facilidade maior. Quanto aplicao de um controle de entradas e sadas (regime de caixa) na empresa, os benefcios podem ser vrios. O principal seria o registro de todas as operaes financeiras da empresa. Alm disso, com um controle financeiro possvel visualizar o desempenho da empresa e verificar defasagens em caixa. Algo que importante salientar o controle do caixa, pois no basta apenas o sistema estar funcionando. preciso haver comprometimento por parte dos responsveis pelo setor financeiro da empresa, para que todas as entradas e sadas sejam registradas no sistema, para torn-lo efetivo. Somente com informaes reais que ser possvel verificar se a empresa est de fato passando ou no por dificuldades, ou se realmente est tendo bons lucros. Tendo um controle organizado do caixa, no omitindo entradas ou sadas, possvel controlar o desempenho da empresa e se a empresa passar por problemas financeiros ser muito mais fcil identificar a fonte do problema para ento tomar as devidas medidas. Mas claro que uma empresa deve ser capaz de antever possveis problemas, para tomar medidas preventivas.

114

De modo geral, com a captao das reais necessidades dos interessados possvel desenvolver um sistema que atenda da melhor forma possvel a empresa e de fato agregue valor a esta, melhorando-a de alguma forma e justificando o investimento no novo sistema. 3.1.5 Restries do sistema proposto O escopo deste projeto foi a realizao de uma anlise orientada a objetos em uma empresa (real ou fictcia) para um regime de caixa. A anlise se iniciou com o levantamento dos requisitos de sistema juntamente com os usurios envolvidos e foi at a construo de quatro diagramas da UML, cada um com uma viso do sistema e de um diagrama de entidades-relacionamentos. Quanto ao regime de caixa, ele trata de controlar as entradas e sadas que efetivamente ocorreram em caixa. Contas a pagar e receber foram descartadas deste projeto, pois no havia nenhum intuito em planejar entradas e sadas futuras. A identificao de quem pagou e a quem foi pago tambm no foram includas, pois o projeto no busca controlar vendas. O planejamento de caixa tambm foi deixado de lado, pois ele trata de incluir previses de caixa, que aquilo que se espera acontecer. Alm da criao de relatrios e demonstrativos que fizessem a comparao 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 implantao de um regime de caixa est no controle daquilo que ocorreu em determinado perodo. Classificando os lanamentos como entradas ou sadas e identificando este lanamento com uma categoria especfica.

CONCLUSO A realizao deste trabalho esteve apoiada na idia de se buscar uma empresa sem um controle de caixa, para que a partir da fossem levantadas as necessidades da empresa para ento iniciar a busca por material terico que serviria de base para o desenvolvimento da anlise. Como resultado, obteve-se toda a documentao da anlise orientada a objetos, sendo composta por diagramas e suas descries, e o diagrama de entidadesrelacionamentos. A construo desta documentao s foi possvel atravs do estudo do funcionamento do regime de caixa que viria a ser implantado na empresa. Com o conhecimento a respeito do regime de caixa, a anlise orientada a objetos foi utilizada como principal ferramenta para a estruturao de todo o projeto. Atravs da anlise orientada a objetos foi possvel transcrever todas as necessidades da empresa em forma de diagramas e descries detalhadas e mais precisas. Com os diagramas da UML foi possvel montar todo o sistema a partir de vises diferentes, mas que em algum ponto se interligavam. A vantagem de se utilizar vrios diagramas est exatamente nessa conexo entre eles, isso torna a viso do sistema mais clara, alm de possibilitar a validao de vrios processos. Essa validao faz com que o sistema funcione de uma forma lgica, sem redundncias ou inconsistncias. E com a utilizao de diagramas muito mais fcil

116

sanar estes problemas, que poderiam ser muito mais difceis de resolver se ocorressem na fase de desenvolvimento. Com os diagramas construdos e descritos, foi possvel afirmar que a anlise orientada a objetos tornou mais claro o entendimento sobre regime de caixa da empresa. Pois atravs dela foi possvel 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 foram o analista a validar todo o tempo a lgica do sistema, o que torna a anlise muito mais consistente. Ficou evidente tambm como os diagramas tornam a comunicao entre analistas e usurios mais clara, pois eles retratam de uma forma mais real os problemas da empresa. Com o desenvolvimento de uma anlise consistente e bem elaborada fica claro como as fases consequentes do projeto podero ser mais bem executadas, pois esto embasadas em esquemas que foram comprovados inmeras vezes. Isso aumenta a produtividade e diminui o retrabalho, alm de permitir a reutilizao de cdigos. Atravs do diagrama de classes da UML foi possvel ainda elaborar o modelo lgico do banco de dados do sistema (modelo de entidades-relacionamentos). Ele de grande importncia em um sistema, pois todas as informaes estaro armazenadas em um banco de dados com o esquema deste modelo. E bancos de dados mal modelados podem ter srios problemas de desempenho a medida que o banco de dados for crescendo. Apesar do trabalho no abranger as prximas etapas de um projeto de sistemas, com os resultados obtidos na anlise possvel concluir que as necessidades da empresa foram atendidas. Atravs de um embasamento terico slido e da compreenso das reais necessidades dos interessados, bem como pela ilustrao do sistema desejado atravs de diagramas consistentes.

REFERNCIAS

AUTRAN, Margarida; COELHO, Cludio Ulysses F.. Bsico de Contabilidade e Finanas. Rio de Janeiro: Senac, 2003. BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. The Unified Modeling Language User Guide 2 Edio. Addison-Wesley, 2005. CORREIA, Carlos Henrique; TAFNER, Malcon Anderson. Anlise Orientada a Objetos 2 Edio. Florianpolis: Visual Books, 2006. DATE, Christhoper J.. Introduo a Sistemas de Banco de Dados 8 Edio. Rio de Janeiro: Campus, 1990. DATE, Christopher J.. Introduo a Sistemas de Bancos de Dados 8 Edio. Rio de Janeiro: Campus, 2004. ELMASRI, Ramez; NAVATHE, Shamkant B.. Fundamentals of Database Systems 4 Edio. Addison-Wesley, 2003. GORNIK, Davor. Entity Relationship Modeling with UML. IBM Technical Library, 23 de Julho de 2005. Disponvel em: <http://www.ibm.com/developerworks/

rational/library/content/03July/2500/2785/2785_uml.pdf>. Acesso em: 28 ago. 2009.

118

GLLICH, Roque Ismael da Costa; LOVATO, Adalberto; EVANGELISTA, Mrio dos Santos. Metodologia da Pesquisa: normas para apresentao de trabalhos: redao, formatao e editorao. Trs de Maio: Ed. SETREM, 2007. HAMILTON, Kim; MILES, Russell. Learning UML 2.0. OReilly, 2006. HARGREAVES, Lourdes; ZUANETTI, Rose; LEE, Renato et al. Qualidade em prestao de servios 2 Edio. So Paulo: Ed. SENAC, 2001. HEUSER, Carlos Alberto. Projeto de Banco de Dados 6 Edio. Porto Alegre: Sagra&Luzzatto, 2001. LAKATOS, Eva Maria; MARCONI, Marina de Andrade. Tcnicas de Pesquisa 6 Edio. So Paulo: Atlas, 2006. LUCION, Carlos Eduardo Rosa. Planejamento Financeiro. Revista Eletrnica de Contabilidade Vol.1, N.3, Mar-Mai/2005 Curso de Cincias Contbeis UFSM. Disponvel em:

<http://w3.ufsm.br/revistacontabeis/anterior/artigos/vIIn01/a09vIIn01.pdf>. Acesso em: 21 out. 2009. MARION, Jos Carlos. Contabilidade Bsica 6 Edio. So Paulo: Atlas, 1998. MASAKAZU, Hoji. Administrao financeira na prtica: guia para educao financeira corporativa e gesto financeira pessoal. So Paulo: Atlas, 2007. MELO, Ana Cristina. Desenvolvendo Aplicaes com UML 2.0 2 Edio. Rio de Janeiro: Brasport, 2004. MELO, Ana Cristina. Desenvolvendo Aplicaes com UML. Rio de Janeiro: Brasport, 2002.

119

PDUA, Elisabete Matallo Marchesini de. Metodologia da Pesquisa: Abordagem terico-prtica 10 Edio. Campinas: Papirus: 2004. PRESSMAN, Roger S.. Engenharia de Software 6 Edio. McGraw-Hill, 2006. QUATRANI, Terry. Modelagem Visual com Rational Rose 2000 e UML. Rio de Janeiro: Cincia Moderna, 2001. RIBEIRO, Osni Moura. Contabilidade Bsica Fcil 23 Edio. So Paulo: Saraiva, 2002. ROSS, Stephen A.; WESTERFIELD, Randolph W.; JORDAN, Bradford D.. Princpios de Administrao Financeira 2 Edio. So Paulo: Atlas, 2000. ROSSETTI, Jos Paschoal. Introduo Economia 15 Edio. So Paulo: Atlas, 1991. ROSSETTI, Jos Paschoal. Introduo Economia 9 Edio. So Paulo: Atlas, 1982. SAMANEZ, Carlos Patrcio. Matemtica Financeira: Aplicaes Anlise de Investimentos 3 Edio. So Paulo: Prentice Hall, 2002. VASCONCELLOS, Marco A. S. de; GARCIA, Manuel E.. Fundamentos de Economia. So Paulo: Saraiva, 1998. YEATES, Donald; WAKEFIELD, Tony. Systems Analysis and Design 2 Edio. Pearson, 2004. YOUNG, Lcia Helena Briski. Imposto de Renda Pessoa Jurdica: Noes Fundamentais 7 Edio. Curitiba: Juru, 2008.

120

ZDANOWICZ, Jos Eduardo. Fluxo de Caixa: Uma deciso de planejamento e controle financeiros. Porto Alegre: D.C. Luzzatto, 1986.