UNIVERSIDADE ESTADUAL DE GOIS UNIDADE UNIVERSITRIA RIO DAS PEDRAS CURSO DE GRADUAO EM SISTEMAS DE INFORMAO

Ado Aparecido de Oliveira Adenilton Nias Carvalho Jnior Alex Parreira Denis Denon da Silva Marcos Suel Mendes Soares

SISTEMA GERENCIADOR DE GARAGEM (SGG)

Projeto de pesquisa apresentado em cumprimento parcial da 2 nota da disciplina Projeto de Graduao I do Curso de Graduao em Sistemas de Informao da Universidade Estadual de Gois UnU Rio das Pedras, Itabera-GO. Orientadora: Prof. Liliane Balduno

Novembro/2010

SUMRIO
1 - TEMA.............................................................................................................3 2 - APRESENTAO DO TEMA.......................................................................3 3 - OBJETIVOS..................................................................................................3 3.1 - OBJETIVO GERAL....................................................................................3 3.2 - OBJETIVO ESPECIFICOS........................................................................3 4 JUSTIFICATIVA............................................................................................4 5 - REFERENCIAL TERICO............................................................................4 5.1 Orientao a Objetos (OO)...........................................................................4 5.2 UML e seus diagramas.................................................................................6 6 Concluso.....................................................................................................11 7 - REFERNCIAS BIBLIOGRFICAS..............................................................12 8 BIBLIOGRAFIA.............................................................................................13 9 - APNDICES..................................................................................................14 9.1 Relatrio de Entrevista..............................................................................14 9.2 Lista de requisitos......................................................................................15 9.3 Diagrama de caso de uso de negcio - Viso geral.................................17 9.4 Diagrama de caso de uso de negcio.......................................................18 9.5 Diagrama de caso de uso de Software.....................................................19 9.6 Diagramas de atividades...........................................................................20 9.7 Especificao de caso de uso de software...............................................23 9.8 Modelo de domnio....................................................................................29 9.9 REGRAS DE NEGCIO...........................................................................30 9.10 DOCUMENTO VISO.............................................................................31 9.11 - GLOSSRIO DE ATRIBUTOS................................................................36 9.12 PROTTIPOS.........................................................................................38 9.13 Modelo de Entidade e Relacionamento MER......................................41 9.14 Modelo Relacional Normalizado MRN.................................................42 10 - ANEXOS......................................................................................................43

1 TEMA
SISTEMA GERENCIADOR DE GARAGEM - SGG AOO UML UEG Anlise Orientada a Objeto; Unified Modeling Language (Linguagem de Modelagem Unificado); Universidade Estadual de Gois;

2 APRESENTAO DO TEMA
O mercado competitivo exige informaes corretas e geis para a tomada das melhores decises. O Sistema Gerenciador de Garagem uma ferramenta que possibilita ao empresrio usufruir dos padres mais modernos de gerenciamento de negcio, propondo agilidade nas tarefas rotineiras e domnio total sobre as informaes, de forma simples e eficaz. Este um projeto criado por acadmicos do curso de Sistemas de Informao da UEG, buscando entender o domnio do negcio e aplicar uma soluo adequada e alternativa ao processo atual da empresa. O projeto tem significativa importncia para a disciplina PROJETO DE GRADUAO I, onde se aplicam conhecimentos de Analise Orientados a Objetos (AOO).

3 OBJETIVOS
3.1 OBJETIVO GERAL Avaliar as necessidades de automatizao na empresa Melo Veculos e a partir da, atravs da anlise, projetar um software que atende realidade da empresa. Utilizar tcnicas de engenharia de sistemas para definir todos os elementos existentes, obtendo assim uma viso detalhada para uma integrao satisfatria do software ao negocio como um todo e desenvolver o projeto do software utilizando conceitos e ferramentas de anlise de sistemas.

3.2 OBJETIVOS ESPECFICOS Conhecer o negcio; Determinar os elementos que integram o negocio; Avaliar a integrao do software ao negcio; Analisar custo/benefcio do SGG; Levantar os requisitos necessrios Construir o Projeto do sistema SGG

4 JUSTIFICATIVA
No mundo dos negcios, comum a necessidade de organizao. No ramo de comrcio de veculos, no diferente. notria a necessidade de se gerir, gerenciar ou simplesmente manter um controle com maior eficcia e praticidade nesse meio (que neste projeto tem foco em garagens) que hoje se mostra em constante crescimento. Pensando nisso, a equipe de projeto, tem buscado ampliar o domnio de anlise de sistemas para projetar um software que atenda todas as necessidades de automatizao deste setor.

5 REFERENCIAL TERICO
Observao importante: todos os conceitos que seguem sobre Orientao a Objetos (OO) e tambm sobre a UML e seus diagramas (do subitem 5.1 ao subitem 5.2.13) foram absorvidos do livro de Gilleanes T. A. Guedes: UML - uma abordagem Prtica. 5.1 Orientao a Objetos (OO) Segundo Guedes, o Mundo OO totalmente semelhante ao mundo a nossa volta, onde tudo tratado como objetos, diferentemente do enfoque procedural.

O paradigma (modelo para orientar pesquisas posteriores) de orientao a objetos essencial ao desenvolvimento de sistemas de softwares modernos. Teve em Alan Kay, um dos seus criadores, e se caracteriza por visualizar um sistema de software como uma coleo de agentes interconectados chamados objetos. Cada objeto responsvel por realizar tarefas especficas. atravs da interao entre objetos que uma tarefa computacional realizada. Utilizando-se orientao a objetos como tcnica de modelagem de sistemas, diminui a diferena semntica entre a realidade sendo modelada e os modelos construdos. 5.1.1 Objetos e Classes de Objetos Definio de Objeto. Representa uma entidade que pode ser fsica, conceitual ou de software. uma abstrao de algo que possui fronteira definida e significado para a aplicao. Componentes de um objeto: Identidade: o que identifica unicamente um objeto, mesmo que ele possua estados ou comportamento comuns a outros objetos. Estado de um objeto: cada condio na qual o objeto pode existir. mutvel ao longo do tempo. implementado por um conjunto de atributos, os valores desses atributos e ligaes que o objeto pode ter com outros objetos. Comportamento de um objeto: Determina como um objeto age e reage a estmulos de outros objetos. modelado atravs de um conjunto de mensagens que representam resultados visveis das operaes executadas internamente pelo objeto. Definio de Classe uma descrio de um grupo de objetos com atributos, comportamentos, relacionamentos com outros objetos e semntica comuns. Uma classe uma abstrao que enfatiza caractersticas relevantes dos objetos, suprimindo outras caractersticas. Portanto um objeto sempre uma instncia de uma classe. Imagine um apartamento. A planta que deu origem a este uma classe e o apartamento pronto, que voc poder habitar e colocar os mveis, o objeto. Ou seja,

uma classe a implementao lgica, a idia original, enquanto que o objeto a implementao fsica. Outros conceitos fundamentais de Orientao a Objetos. Abstrao: Princpio de ignorar os aspectos de um assunto no relevantes para o propsito em questo, tornando possvel uma concentrao maior nos assuntos. Encapsulamento consiste na separao de aspectos internos e externos de um objeto. Este mecanismo utilizado amplamente para impedir o acesso direto ao estado de um objeto (seus atributos), disponibilizando externamente apenas os mtodos que alteram estes estados. Herana: (ou generalizao) o mecanismo pelo qual uma classe (sub-classe) pode estender outra classe (super-classe), aproveitando seus comportamentos (mtodos) e variveis possveis (atributos). H Herana mltipla quando uma sub-classe possui mais de uma super-classe. Polimorfismo: o princpio pelo qual duas ou mais classes derivadas de uma mesma superclasse podem invocar mtodos que tm a mesma assinatura (lista de parmetros e retorno), mas comportamentos distintos, especializados para cada classe derivada, usando para tanto uma referncia a um objeto do tipo da superclasse. (GUEDES; Gilianes T. A., 2008, UML: uma abordagem Prtica) 5.2 UML e seus diagramas 5.2.1 Diagrama de Caso de Uso Um diagrama de Caso de Uso descreve um cenrio que mostra as funcionalidades do sistema do ponto de vista do usurio. O Diagrama de Casos de Uso tem o objetivo de auxiliar a comunicao entre o analista e o cliente, de forma que a abstrao deste se torne o mais simples possvel. O cliente deve ver no diagrama de Casos de Uso as principais funcionalidades de seu sistema, representadas atravs de atores e dos casos de uso que em algumas

circunstncias se relacionam. Estes relacionamentos podem ocorrer das seguintes formas: Associao -> o relacionamento entre um ator e um caso de uso. Tem a finalidade de definir uma funcionalidade do sistema do ponto de vista do usurio. Generalizao -> o relacionamento entre atores. Tem por finalidade atribuir casos de uso de determinado ator a outro. Include -> a indicao de que um caso de uso A se apontado para um B essencial para o comportamento de B. Pode ser dito tambm que B parte de A. Extend -> a indicao de que um caso de uso A se apontado para um B, no o torna parte de A, uma vez que B uma adio opcional. A delimitao de um sistema em um caso de uso feita por um retngulo envolvendo os casos de uso que compem este sistema. O nome do sistema localizado dentro do retngulo. 5.2.2 Diagrama de Atividades O objetivo do diagrama de atividades mostrar o fluxo de atividades em um nico processo. O diagrama mostra como uma atividade depende da outra. As atividades so conectadas atravs de arcos (transies), que mostram as dependncias entre elas. essencialmente um grfico de fluxo, mostrando o fluxo de controle de uma atividade para outra. Comumente isso envolve a modelagem das etapas seqenciais em um processo computacional. Os diagramas de atividade no so importantes somente para a modelagem de aspectos dinmicos de um sistema ou um fluxograma, mas tambm para a construo de sistemas executveis por meio de engenharia de produo reversa. 5.2.3 Diagrama de Componentes Ilustra como as classes devero se encontrar organizadas atravs da noo de componentes de trabalho. Por exemplo, pode-se explicitar, para cada componente, qual das classes que ele representa. utilizado para: Modelar os componentes do cdigo fonte, do cdigo executvel do software.

Destacar a funo de cada mdulo para facilitar a sua reutilizao. Auxiliar no processo de engenharia reversa, por meio da organizao dos mdulos do sistema e seus relacionamentos. 5.2.4 Diagrama de Implantao O Diagrama de implantao determina as necessidades de hardware do sistema, as caractersticas fsicas como servidores, estaes, topologias e protocolos de comunicao, ou seja, todo o aparato fsico sobre o qual o sistema dever ser executado. O Diagrama de Componentes e de Implantao so bastante associados, podendo ser representados separadamente ou em conjunto. 5.2.5 Diagrama de Pacotes O Diagrama de Pacotes j existia nas verses anteriores da UML, mas foi considerado independente a partir da UML 2. Seu Objetivo representar os subsistemas englobados por um sistema de forma a determinar as partes que o compem. Pode ser utilizado de maneira independente ou associado com outros diagramas. 5.2.6 Diagrama de Interao Geral O Diagrama de Interao Geral uma Variao diagrama de Atividade que fornece uma viso geral dentro de um sistema ou processo de negcio. Este diagrama passou a existir apenas a partir da UML 2. 5.2.7 Diagrama de Estrutura Composta utilizado para mostrar o trabalho interno especifico das classes, atravs das colaboraes que so a viso do conjunto de entidades que cooperam entre si para realizar uma funo especifica. A colaborao refere se s entidades e seus atributos que juntos comunicam se para que haja cooperao e assim atingir a funo desejada. As interconexes desses elementos o que chamado de estrutura.

10

5.2.8 Diagrama de Comunicao Esse diagrama muito parecido com o diagrama de seqncia, na verdade um complementa o outro. Com a diferena de que o de seqncia preocupa se com o tempo em que os objetos trocam as mensagens, j o de comunicao est interessado em como os objetos esto ligados, como trocam mensagens durante o processo e qual o contexto do sistema, ou seja, quais as classes existentes. 5.2.9 Diagrama de Mquina de Estados Todo objeto tem um ciclo de vida, ele nasce, vive durante o processo, e deixa de existir. Esse diagrama ir mostrar as mudanas que esse objeto sofrer dentro de um processo. Em certos momentos toma como base os casos de uso do diagrama de caso de uso, ou at mesmo apia se no diagrama de classes. Normalmente tambm pode acompanhar os estados de uma instancia de uma classe, de um subsistema ou de um sistema completo. 5.2.10 Diagrama de Tempo Descreve a mudana no estado ou condio de uma instancia de uma classe no tempo. Mostrar como um objeto mudar seu comportamento em determinado tempo em resposta h eventos externos. 5.2.11 Diagrama de classe O diagrama de classe o mais utilizado e importante diagrama da UML e da documentao, servem como base de apoio a demais diagramas, onde podemos encontrar as informaes sobre mtodos, atributos, nome das funes e como sero integradas. Define a estrutura das classes utilizadas pelo sistema, alem de estabelecer relaes entre si. Um diagrama de classes bem modelado fundamental para auxiliar o desenvolvedor.

11

5.2.12 Diagrama de objeto O diagrama de objeto esta amplamente associada ao diagrama de classes. O diagrama de objetos uma variao do diagrama de classes e utiliza quase mesma notao. O diagrama de objetos como se fosse o perfil do sistema em certo momento de sua execuo, fornece uma viso dos valores armazenados pelos objetos de um diagrama de classes em um determinado momento da execuo de um processo do software. Existem apenas duas diferenas entre o diagrama de classes, os objetos so escritos com seus nomes sublinhados e todas as instncias num relacionamento so mostradas. Este diagrama importante para se ter uma viso do sistema em determinado tempo e para se conferir se os dados esto atribudos corretamente no tempo e se so consistentes. 5.2.13 Diagrama de seqncia O diagrama de seqncia preocupa-se com a ordem temporal em que as mensagens so trocadas entre os objetos envolvidos em um determinado processo. Mostra como as mensagens so trocadas no decorrer do tempo para a realizao de uma operao. Costuma identificar os eventos geradores do processo modelado, bem como o ator responsvel por esse evento, e determina como o processo deve se desenrolar e ser concludo por meio da chamada de mtodos disparados por mensagens enviadas entre os objetos. (GUEDES; Gilianes T. A., 2008, UML: uma abordagem Prtica).

12

6 - Concluso

A realizao deste serviu para conhecermos o que Anlise de Sistemas, atravs da prtica. Desenvolvemos tcnicas fundamentais para a criao de sistemas de informao, alm de nos familiarizarmos com seus diversos diagramas. Aprendemos a importncia da UML para a Engenharia de Software, alm de noes importantes de orientao a objetos. Ainda estamos na verso beta deste projeto, mas com certeza, at o final do curso, vamos ter aprimorado bastante a nossa viso de analista.

13

7 - REFERNCIAS BIBLIOGRFICAS
Guedes, Gilleanes T. A. - UML: uma abordagem Prtica 3. Edio, So Paulo: Novatec Editora, 2008.

14

8 - BIBLIOGRAFIA
Guedes, Gilleanes T. A. - UML: uma abordagem Prtica 3. Edio, So Paulo: Novatec Editora, 2008. PRESSMAN, Roger S. Engenharia de Software 1. Edio, So Paulo, Pearson Education do Brasil, 1995.

15

9 APNDICE Estudo de Caso

9.1 Relatrio Entrevista 18/03/2010

No dia 18/03/2010, a equipe formada pelos alunos: Ado, Adenilton, Alex, Denis e Marcos Suel, teve o primeiro contato direto com o cliente para coleta de requisitos e o conhecimento do negcio, na forma de entrevista. Esta que foi feita com o senhor Jabes Melo, proprietrio da Melo Veculos - Garagem bastante conhecida em Itapuranga e regio. Os materiais utilizados para a entrevista foram: papel, caneta, lpis, borracha. A entrevista contou com as seguintes perguntas: 1 - Qual o maior problema enfrentado pela empresa, quando diz respeito organizao? 2 - Como feito o armazenamento de dados ? 3 - A empresa j faz uso de algum software para controle ou gerenciamento ? 4 - Quais os tipos de servios e produtos que a empresa fornece ? 5 - Explique como funciona cada um dos servios oferecidos. 6 - No caso de consignao, quanto tempo o veculo fica na garagem ? 7 - H a interao com bancos ? 8 - Se a resposta pergunta anterior foi positiva, como feita essa interao ? 9 - Quais os tipos de documentos/relatrios emitidos ?

16

9.2 Lista de Requisitos

ID R1

Interesse Cadastrar Veculo

Motivo Controlar o estoque de veculos disponveis para venda ou consignao, incluindo tambm os dados ref. aos documentos dos mesmos. Ter os dados para contato de todos os clientes que hora podem ser compradores, em outra, vendedores Manter histrico de todas as vendas efetuadas pela empresa. A comisso por meio de percentagem. O prazo para realizar uma venda consignada indeterminada. (Onde o proprietrio deixe a veculo p/ ser vendido, mediante o pagamento de uma comisso) Controlar vendas efetuadas com financiamento prprio carn pago via banco Relatrio emitido com base na emisso ou vencimento, dentro de um certo perodo

Quem solicita? Jabes

Data 18/03/2010

Ator responsvel Gerente geral

R2

Cadastrar Cliente

Jabes

18/03/2010

Gerente geral

R3

Lanar venda de veculos Lanar consignao de veculos

Jabes

18/03/2010

Gerente geral

R4

Jabes

18/03/2010

Gerente geral

R5

Cadastrar contas a receber Gerar relatrios de contas a receber

Jabes

18/03/2010

Gerente geral

R6

Jabes

18/03/2010

Gerente geral

17

ID R7

Interesse Gerar contrato de compra e venda de veculo

Motivo Com base nos lanamentos de vendas / consignaes, emitir o relatrio do Contrato de compra e venda de veculos, que deve ser arquivado. Baseado no cadastro de contas a receber, emitir carns. Controlar a quantidade de vendas Visualizar os clientes e os seus dados Visualizar os veculos e os seus dados Visualizar os consignaes e os seus dados Caso a garagem no possua um veculo que atenda a um cliente, registrar nome, telefone e modelo do veculo desejado para um futuro contato caso aparea o modelo desejado. Controlar compras de veculos efetuadas a prazo. Registrar compras de veculos

Quem solicita? Jabes

Data 18/03/2010

Ator responsvel Gerente geral

R8 R9 R10 R11 R12 R13

Gerar carns de contas a receber Gerar relatrio de vendas de Veculos Gerar Relatrio de Clientes Gerar Relatrio de Veculos Gerar Relatrio de Consignaes Registrar interesse de um cliente em um veculo

Jabes Jabes Jabes Jabes Jabes Jabes

18/03/2010 18/03/2010 13/05/2010 13/05/2010 13/05/2010 28/10/2010

Gerente geral Gerente geral Gerente geral Gerente geral Gerente geral Gerente geral

R14 R15

Cadastrar contas a pagar Manter compras de veculos

Jabes Jabes

28/10/2010 28/10/2010

Gerente geral Gerente geral

18

9.3 Diagrama de caso de uso de negcio - Viso geral

19

9.4 Diagrama de caso de uso de negcio

20

9.5 Diagrama de caso de uso de Software

21

9.6 Diagramas de atividades

9.6.1 Diagrama de atividades - Vendas de veculos

22

9.6.2 Diagrama de Atividades Compra de veculos

23

9.6.3 Diagrama de Atividades Consignao de Veculos

24

9.7 Especificao de caso de uso de software

Tabela 1.1 Documentao do Caso de Uso<Cadastro de Clientes>

Nome do Caso de Uso

Caso de Uso Geral Ator Principal Atores Secundrios Resumo Pr-Condies Ps-Condies Fluxo Principal Gerente Cliente

<Cadastrar cliente>
Cadastrar cliente

Cria um cadastro para um cliente.

Usurio solicita o cadastro de clientes. Sistema disponibiliza a interface de interao e solicita preenchimento dos campos obrigatrios ou no. Usurio informa dados requeridos. O Usurio requer o salvamento. O Sistema salva e registra emitindo uma mensagem [MSG.] e o caso de uso termina. O sistema exibe uma tela com vrios campos para preenchimento O sistema confere a validade dos dados O sistema salva os dados O sistema exibe uma tela com os dados do cliente em questo, j disponibilizada em modo de alterao O usurio optou pela alterao dos dados de um cliente j informou qual. O sistema disponibiliza os dados do cliente para alterao, com exceo do cdigo identificador nico e continua no passo 2 do curso bsico. O Sistema identificou que

Aes do Ator O gerente pressiona a tecla F2 O gerente insere todos os dados exigidos O gerente requer o salvamento dos dados O gerente pressiona a tecla F3

Aes do Sistema

Restries / Validaes Fluxo Alternativo I

Fluxo de Exceo

25

informaes obrigatrias no foram informadas, informa o usurio [MSG] quais so e no permite o salvamento. Tabela 1.2 Documentao do Caso de Uso<Cadastrar veculo>

Nome do Caso de Uso

Caso de Uso Geral Ator Principal Atores Secundrios Resumo

<Cadastrar veculo>
Cadastrar veculo Gerente Cliente Cria um cadastro para um veculo. Usurio solicita o cadastro de veculos. Sistema disponibiliza a interface de interao e solicita preenchimento dos campos obrigatrios ou no. Usurio informa dados requeridos. O Usurio requer o salvamento. O Sistema salva e registra emitindo uma mensagem e o caso de uso termina. O sistema exibe uma tela com vrios campos para preenchimento O sistema confere a validade dos dados O sistema salva os dados O sistema exibe uma tela com os dados do veculo em questo, j disponibilizada em modo de alterao O usurio optou pela alterao dos dados de uma veculo. O sistema disponibiliza os dados do veculo para alterao, com exceo do cdigo identificador nico e continua no passo 2 do curso bsico. O Usurio est tentando alterar os dados do veculo que tem restries

Fluxo Principal

Aes do Ator O gerente pressiona a tecla F2 O gerente insere todos os dados exigidos, inclusive se o veculo para consignao ou no O gerente requer o salvamento dos dados O gerente pressiona a tecla F3

Aes do Sistema

Fluxo Alternativo I

26

de alterao conforme regras de negcio. O Sistema no permite a alterao e informa o fato ao usurio. O Sistema identificou que informaes obrigatrias no foram informadas, informa o usurio quais so e no permite o salvamento. O Sistema identificou que algumas informaes obrigatrias no foram informadas, informa o usurio quais so e no permite o salvamento.

Fluxo de Exceo

Tabela 1.3 Documentao do Caso de Uso <Cadastrar contas a receber>

Nome do Caso de Uso

Caso de Uso Geral Ator Principal Atores Secundrios Resumo

<Cadastrar contas a receber>

Cadastrar contas a receber Gerente Cliente Cria um cadastro para uma Conta a Receber. O Sistema salva, registra e emite o carn atravs do include Gerar Carn de Contas a receber emitindo uma mensagem e o caso de uso termina. Usurio solicita o cadastro de Contas a Receber. Sistema disponibiliza a interface de interao e solicita preenchimento dos campos obrigatrios ou no. Usurio informa dados requeridos. O Usurio requer o salvamento. O sistema exibe uma tela com vrios campos para preenchimento O sistema confere a validade dos dados O sistema salva os dados

Ps-condio Fluxo Principal Aes do Ator O gerente pressiona a tecla F2 O gerente insere todos os dados exigidos O gerente requer o salvamento dos dados

Aes do Sistema

27

O gerente pressiona a tecla F3

O sistema exibe uma tela com os dados do cliente em questo, j disponibilizada em modo de alterao O usurio optou pela alterao dos dados de uma conta a receber. O sistema disponibiliza os dados da conta a receber para alterao, com exceo do cdigo identificador nico e continua no passo 2 do curso bsico. O usurio pode optar por gerar o carn de contas a receber atravs do include Gerar Carn de Contas a receber. O Sistema identificou que informaes obrigatrias no foram informadas, informa o usurio quais so e no permite o salvamento.

Fluxo Alternativo I

Fluxo de Exceo

Tabela 1.4 Documentao do Caso de Uso<Lanar venda de veculos>

Nome do Caso de Uso

Caso de Uso Geral Ator Principal Atores Secundrios Resumo

<Lanar venda de veculos>

Lanar venda de veculos Gerente Cliente Cria um cadastro para uma venda de veculos. Usurio solicita o cadastro de venda de veculo. Usurio verifica se j existe o cadastro do cliente. Sistema disponibiliza a interface de interao e solicita preenchimento dos campos obrigatrios ou no. Usurio informa dados requeridos. O Usurio requer o salvamento. O Sistema salva e registra emitindo uma mensagem e o caso de uso termina.

Fluxo Principal

Aes do Ator

Aes do Sistema

28

O gerente pressiona a tecla F2 O gerente insere todos os dados exigidos O gerente requer o salvamento dos dados O gerente pressiona a tecla F3

O sistema exibe uma tela com vrios campos para preenchimento O sistema confere a validade dos dados O sistema salva os dados O sistema exibe uma tela com os dados do venda em questo, j disponibilizada em modo de alterao Caso cliente no cadastrado, realizar primeiro caso de uso cadastrar cliente. O usurio optou pela alterao dos dados de uma venda de veculo. O sistema disponibiliza os dados da venda para alterao, com exceo do cdigo identificador nico e continua no passo 2 do curso bsico. O Sistema identificou que informaes obrigatrias no foram informadas, informa o usurio quais so e no permite o salvamento.

Fluxo Alternativo I

Fluxo de Exceo

Tabela 1.5 Documentao do Caso de Uso <Gerar Carn de Contas a Receber>

Nome do Caso de Uso

Caso de Uso Geral Ator Principal Atores Secundrios Resumo Pr-condio Fluxo Principal

<Gerar Carn de Contas a Receber>

Gerar Carn de Contas a Receber Gerente Cliente Gera um Carn de Contas a Receber Salvamento do caso de uso Contas a Receber. Usurio solicita Gerar Carn de Contas a Receber. Sistema disponibiliza a interface de interao e apresenta o Carn gerado.

29

Pr-Requisitos Aes do Ator O gerente pressiona a tecla F11 O gerente seleciona a opo imprimir

O Usurio requer o impresso, ou no.

Ter cadastrado uma conta a receber. Aes do Sistema O sistema exibe uma tela com um formulrio em forma de carn O sistema comanda a impresso O usurio optou por no imprimir, escolhendo a opo cancelar. O Sistema identificou que informaes obrigatrias no foram informadas, informa o usurio quais so e no permite o salvamento.

Fluxo Alternativo I

Fluxo de Exceo

30

9.8 Modelo de domnio

31

9.9 REGRAS DE NEGCIO

RN1. Todo veculo negocivel deve estar cadastrado. RN2. Verificar pendncias judiciais de veculos antes do seu cadastramento, aceitando apenas veculos que no as possuem. RN3. Validar CPF no cadastro de clientes. RN4. Verificar pendncias financeiras dos clientes antes de realizar uma venda no credirio. Clientes com pendncias s compraro vista. RN5. Toda venda no credirio prprio deve gerar carns para o cliente. RN6. Toda venda no credirio ou no gera um contrato de compra e venda. RN7. Aps 30 dias, no caso de consignao, o cliente dever ser avisado para que seu contrato seja renovado, ou para que busque o veculo.

32

9.10 DOCUMENTO VISO Introduo

Uma garagem de veiculo necessita de vrios cadastros e a armazenagem de vrios dados importantes, sendo estes primordiais para o funcionamento da empresa, para obter um controle de sua administrao e a qualidade no atendimento no que diz respeito agilidade em cadastrar seus interesses. A fim de facilitar tal controle, o presente projeto visa desenvolver um sistema de informao que atenda as necessidades dos envolvidos e permita a garagem gerenciar os cadastros de clientes e veculos e oferecer segurana na armazenagem das informaes e recursos para que a empresa tenha um total controle de todas as atividades.

Objetivo
O presente documento define uma parte da informatizao de uma garagem de veculos e uma proposta de soluo para sistemas desktop.

Sistemas similares
No foram avaliados sistemas no mercado.

Situao atual
A garagem de veculos j possui um sistema de informao, porem no atende toda a necessidade da empresa, ao estudarmos o caso em questo constatamos que havia a necessidade re-projetar o sistema.

33

Problema
O problema Falta de funcionalidades no sistema, redundncia de informaes entre outras. Afeta A qualidade no atendimento direto ao cliente. Armazenamento de informaes de clientes e veculos. A satisfao dos clientes no que diz respeito agilidade no atendimento. Organizao e controle de dados importantes para a empresa. O impacto Lentido no acesso a informaes. Oneroso processo de rastreamento de informaes gerenciais. Uma soluo Um sistema de informao capaz de: Cadastrar cliente e veculos. Fornecer informaes rpidas a respeito da disponibilidade de produtos para o seu fornecimento.

satisfatria seria

Armazenamento e recuperao rpida de informaes. Manter os dados dos clientes e fornecedores atualizados. Gerar relatrios de todas as operaes.

34

Produto
Sistema de gerenciamento de garagem de veiculo. Para Quem Que Empresa: Melo Veculos. Garagem de veculos. Auxilie a garagem de veculo a gerenciar efetivamente os cadastros. Alm de gerar relatrios a cerca de informaes sobre suas operaes. Difere Difere do processo existente, pois fornecer mecanismos que permitam um dinamismo em recuperar rapidamente informaes, bem como proporcionar uma agilidade no processo, mantendo a segurana das informaes cadastradas e obtendo-as de forma rpida sempre que necessrio. Produto proposto Dever facilitar a localizao de informaes nos cadastro de clientes. Manter os cadastros atualizados. Gerar relatrios sempre que necessrio Manter o cadastro de veculos atualizado e com minuciosas informaes possveis para que sempre que for requisitado, facilite a busca de informaes a serem passadas para o Oportunidade de melhoria cliente. O atendimento ter condies de ser infinitamente mais veloz, uma vez que todo o processo ser informatizado, e a possibilidade de consultar clientes e veculos de grande eficcia para o gerenciamento da empresa.

35

Clientes e usurios Clientes Descrever os clientes

Nome Gerente: Jabes Melo Representa Administrao da empresa: Melo veculos. Papel Responsvel por toda movimentao e validao do sistema.

Usurios
Os usurios so as clientes que, de fato, interagem com o sistema. Eles esto classificados nas categorias abaixo. Categoria Atores Humanos Gerente Papel
1: Validar

decises de interao;

cadastrar cliente e veculos.

Ambiente do usurio

Computador IBM-PC compatvel, 3 GB de RAM HD 360 GB. Processador Core 2 Duo, 2.2 GHz Impressora HP C3180 All-in-On. Sistema Operacional Windows XP Profissional.

Necessidades dos usurios

N1: Melhorar o processo de armazenamento e recuperao de informaes em uma garagem de veculos;

36

N1.1: Facilitar o controle de informaes de clientes e de veculos, facilitar a consulta destes cadastros C1: Informatizar as informaes de clientes e veculos. C2: Registrar entrada e sada de veculos na garagem. N1.2: Ter disponvel a relao atualizada dos veculos. C3: Manter o cadastro atualizado de clientes e veculos. N2: Ter acesso rpido s informaes.

Caractersticas
C1: Informatizar os cadastros de clientes e veculos mantendo-os atualizados. Esta caracterstica permitira colocar no sistema eletrnico os cadastros de clientes e veculos de forma a auxiliar o seu controle e tambm oferecer consultas dos mesmos de forma rpida, melhorando assim a qualidade do atendimento da empresa ao cliente. Permitir tambm cadastrar os veculos recebidos de forma minuciosa, o que facilitar na busca do mesmo. C2: A escolha dos veculos ficar organizada em uma lista de compras, que poder ser alterada sempre que o cliente queira, at que ele esteja certo da qualidade e valor do produto escolhido para que seja efetuada a venda.

37

9.11 - GLOSSRIO DE ATRIBUTOS

Anexo 1.1 Cliente

Nome
cdigo nome rg cpf cnpj iestadual tipopessoa logradouro numero complemento cidade uf cep telefone Setor

Descrio
Cdigo do cliente Nome do cliente Registro geral do cliente CPF do cliente, se fsica CNPJ do cliente, se jurdica Inscrio Estadual, se jurdica Tipo: Fsica ou Jurdica Ex.: Rua, Avenida Nmero do logradouro Complemento do endereo Cidade em que reside Uf respectiva Cep respectivo Telefone para contato Setor onde reside

Regras do Atributo
99999 999.999.999-99 99.999.999/9999-99 Nmero(5) Varchar(50) Varchar(15) Varchar(11) Varchar(14) Varchar(14) Char(1) Varchar(40) Varchar(5) Varchar(30) Varchar(25) Varchar(2) Varchar(8) Varchar(10) Varchar(30)

99999-999 99-9999-9999

Anexo 1.2 Veculo

Nome
cdigo chassi marca modelo placa potncia anofabric anomodelo cor proprietrio combustvel portas preocompra preovenda vidroelet travaelet arcondicionado dirhidraulica alarme renavan cilindrada

Descrio
Cdigo do veculo Chassi do veculo Marca do veculo Modelo do veculo Placa do veculo Potncia Ano de fabricao Ano do modelo Cor predominante do veculo Proprietrio do veculo Combustvel do veculo Numero de portas do veculo Valor da compra Valor da venda Possui vidro eltrico Possui trava eltrica Possui ar condicionado Possui direo hidrulica Possui alarme Nmero renavam Quantidade de cilindradas

Regras do Atributo
99999 Nmero(5) Varchar(17) Varchar(25) Varchar(25) Varchar(7) Varchar(7) Varchar(4) Varchar(4) Varchar(15) Varchar(50) Varchar(15) Char(1) Real(14,2) Real(14,2) Booleano Booleano Booleano Booleano Booleano Varchar(9) Nmero(10)

38

Anexo 1.3 Contas a pagar

Nome
nmero credor parcela dataemi datavenc datapagto valor

Descrio
Cdigo da conta Nome do credor Nmero da parcela Data da emisso Data de vencimento Data de pagamento Valor da conta

Regras do Atributo
varchar(12) varchar(50) varchar(6) date date date real(14,2)

dd/mm/yyyy dd/mm/yyyy dd/mm/yyyy R$ ###,###,##0.00

Anexo 1.4 - Contas a receber

Nome
nmero devedor parcela dataemi datavenc datarecto valor Anexo 1.5 - Venda

Descrio
Cdigo da conta Nome do devedor Nmero da parcela Data da emisso Data de vencimento Data de recebimento Valor da conta

Regras do Atributo
varchar(12) varchar(50) varchar(6) date date date real(14,2)

dd/mm/yyyy dd/mm/yyyy dd/mm/yyyy R$ ###,###,##0.00

Nome
cdigo cdigo_cli data valortotal

Descrio
Cdigo da venda Cdigo do cliente Data da venda Valor total da venda

Regras do Atributo
varchar(12) varchar(5) date real(14,2)

Anexo 1.6 - Interesse

Nome
cdigo cdigo_cli marca modelo

Descrio
Cdigo do interesse Cdigo do cliente Descrio marca Descrio modelo

Regras do Atributo
varchar(12) varchar(5) varchar(20) varchar(30)

39

Anexo 1.7 - Compra

Nome
cdigo cdigo_cli cdigo_veic dataemissao dataentrada

Descrio
Cdigo da compra Cdigo do cliente Cdigo do veculo Data de emisso Data de entrada

Regras do Atributo
varchar(12) varchar(5) varchar(5) date date

9.12 PROTTIPOS 9.12.1 Tela de Cadastro de Veculos

40

9.12.2.1 Tela de Cadastro de Cliente Pessoa Fsica

9.12.2.2 Tela de Cadastro de Clientes Pessoa Jurdica

41

9.12.3 Tela de Contas a Pagar

9.12.3 Tela de Contas a Receber

42

9.13 Modelo de Entidade e Relacionamento MER

43

9.14 Modelo Relacional Normalizado MRN

OBS: Aps aplicar as formas normais ao MER criando o MRN, surgiram novas entidades, novos relacionament os e atributos. essas modificaes ainda no esto completament e documentada s no projeto e sero inseridas nas prximas revises do mesmo.

44

10 ANEXOS