FACULDADE DE TECNOLOGIA CARLOS DRUMMOND DE ANDRADE Curso Superior de Tecnologia em Sistemas de Informao

Projeto de software orientado a objetos com UML: Estudo de caso em uma locadora de veculos.

Cleber Luis Marrara

So Paulo 2006

CLEBER LUIS MARRARA

Projeto de software orientado a objetos com UML: Estudo de caso em uma locadora de veculos.

Trabalho de concluso de curso apresentado Faculdade de Tecnologia Carlos Drummond de Andrade como exigncia parcial para obteno do grau em Tecnlogo em Sistemas de Informao.

Orientador Prof. Wilson Vendramel.

So Paulo 2006.

CLEBER LUIS MARRARA

Projeto de software orientado a objetos com UML: Estudo de caso em uma locadora de veculos.

Trabalho de concluso de curso apresentado Faculdade de Tecnologia Carlos Drummond de Andrade como exigncia parcial para obteno do grau em Tecnlogo em Sistemas de Informao.

Orientador Prof. Wilson Vendramel.

Data de Aprovao ____/___/_____

Banca Examinadora:

_________________________________ Prof. Wilson Vendramel

_________________________________ Prof.

_________________________________ Prof.

Dedico este meu trabalho a todos os estudantes e profissionais da rea de Sistemas e, que esse estudo, possa servir como base para novos trabalhos e projetos.

Agradecimentos

Agradeo em primeiro lugar a Deus por permitir que eu pudesse chegar at aqui e fazer esse trabalho. minha me e ao meu pai (in memoriam) que me ajudaram muito durante toda a minha vida e se esforaram para me dar o estudo que eles no tiveram. minha filha que, apesar de muito jovem, entendeu a minha ausncia durante esse perodo de estudos. minha namorada, companheira, amiga e futura esposa pela pacincia e incentivo que me deu foras pra continuar at o fim. E aos meus Professores e Mestres que me transmitiram sua experincia e sabedoria.

"Voc tem o seu caminho, eu tenho o meu. Quanto ao caminho certo, o correto, o nico, no existe". Nietzche

Resumo
Esse trabalho um estudo de caso cujo objetivo aplicar os conceitos de anlise e projeto de sistemas orientado a objetos para se desenvolver um software com a finalidade de controlar o aluguel de veculos de uma locadora. Inicialmente, o estudo apresenta conceitos relacionados s etapas de desenvolvimento de sistemas e definies dos elementos que as compem. Entre os itens abordados esto conceitos de sistema de informao, engenharia de software, anlise de sistemas orientada a objetos e Linguagem de Modelagem Unificada (Unified Modeling Language, UML). Por fim, um estudo de caso apresentado onde pode-se aplicar todos os conceitos abordados.

Palavras-Chaves: Engenharia de Software, Orientao a Objetos, Modelagem de Sistemas.

Abstract
This work is a study case whose objective is to apply the systems analysis concepts and systems project objects-oriented to develop software, with purpose to controller the vehicle rental of a company. Initially, the study presents concepts related to the system development stages and definitions of the elements that compose them. Among the items

approached are concepts of system of information, software engineering, oriented systems analysis to objects and Unified Modeling Language (UML). Finally, a study case is presented where it can be applied all of the approached concepts.

Key-word: Software engineering, Objects-driven, Systems modeling.

ndice de Figuras e Tabelas Figuras

Figura 1: Etapas de processos gerenciais ................................................................23 Figura 2: Modelo balbrdia........................................................................................27 Figura 3: Modelo Cascata .........................................................................................28 Figura 4: Modelo incremental ....................................................................................30 Figura 5: Modelo prototipao...................................................................................31 Figura 6: Modelo espiral ............................................................................................32 Figura 7: Subdiviso das ferramentas CASE ............................................................36 Figura 8: Tipos de requisitos no-funcionais .............................................................40 Figura 9: Objeto e classe. .........................................................................................53 Figura 10:Representao de classe..........................................................................55 Figura 11: Encapsulamento.......................................................................................56 Figura 12: Herana mltipla ......................................................................................57 Figura 13: Herana....................................................................................................58 Figura 14: Polimorfismo ............................................................................................59 Figura 15: Cenrio Principal ......................................................................................62 Figura 16: Cenrios alternativos................................................................................63 Figura 17: Representao de fronteira do sistema....................................................64 Figura 18: Representao de uma associao .........................................................64 Figura 19: Representao de um relacionamento de Generalizao........................65 Figura 20: Representao de um relacionamento Extend ........................................65 Figura 21: Representao de um relacionamento Include ........................................66 Figura 22: Multiplicidade numa associao...............................................................68 Figura 23: Representao de associao .................................................................70 Figura 24: Representao de uma associao ternria ............................................71 Figura 25: Representao de generalizao.............................................................71 Figura 26: Definio de operaes Polimrficas .......................................................72 Figura 27: Dependncia ............................................................................................72 Figura 28: Assinatura da Dependncia .....................................................................73 Figura 29: Agregao................................................................................................73 Figura 30: Composio .............................................................................................74 Figura 31: Classe Associativa ...................................................................................75 Figura 32: Classe Associativa ...................................................................................76 Figura 33: Interface usando uma classe com esteretipo ........................................77 Figura 34: Interface usando o circulo ........................................................................77 Figura 35: Diagrama de seqncia com elementos bsicos. ....................................78 Figura 36: Objetos annimos e nomeados................................................................78 Figura 37: Notao de tipos de mensagens em diagrama de seqncia..................79 Figura 38: Elementos do Diagrama de Seqncia ....................................................80 Figura 39: Elementos de Diagrama de Atividades ....................................................81 Figura 40: Aplicao de Raias de Natao (swim lanes) ..........................................82 Figura 41: Disposio das Atividades no grfico de Gantt ........................................88 Figura 42: Diagrama de Caso de Uso Locadora de Veculos.................................92 Figura 43: Diagrama de Classes Locadora de Veculos ........................................97 Figura 44: Diagrama de Seqncia #1/2...................................................................98 Figura 45: Diagrama de Seqncia #2/2...................................................................99 Figura 46: Diagrama de atividade do pacote Controlar Cobrana .........................100 Figura 47: Prottipo da Tela de Abertura de Contrato.............................................153

10 Figura 48: Prottipo da Tela de Fechamento de Contrato de Locao. ..................154 Figura 49: Prottipo da Tela de Cadastro de Veculos............................................155

Tabelas
Tabela 1: Histrico dos mtodos de desenvolvimento de software...........................34 Tabela 2: Classes e instncias..................................................................................54 Tabela 3: Tabela de Atividades x Recursos Humanos..............................................88

11

Sumrio
Agradecimentos ..........................................................................................................5 Resumo .......................................................................................................................7 Abstract .......................................................................................................................8 ndice de Figuras e Tabelas ........................................................................................9 Introduo .................................................................................................................14 Captulo 1. Sistema de Informao ...........................................................................17 1.1 Definio ..................................................................................................................... 17 1.2 Elementos de Sistemas de Informao ........................................................................ 18 1.2.1 Hardware.............................................................................................................. 19 1.2.2 Software ................................................................................................................ 19 1.2.3 Redes .................................................................................................................... 20 1.2.4 Pessoas.................................................................................................................. 21 1.2.5 Dados .................................................................................................................... 22 1.3 O Projeto de Software.................................................................................................. 22 1.3.1 Gerncia de Projeto de Software .......................................................................... 22 1.3.2 Definio do Escopo do Software ........................................................................ 24 1.3.3 Planejamento das Atividades................................................................................ 24 1.4 Aplicao do Software................................................................................................. 25 Captulo 2. Engenharia de Software..........................................................................26 2.1 O que Engenharia de Software .................................................................................. 26 2.2 Processo de desenvolvimento de Software.................................................................. 26 2.2.1 Modelo balbrdia.................................................................................................. 27 2.2.2 Modelo cascata ..................................................................................................... 27 2.2.3 Modelo incremental.............................................................................................. 29 2.2.4 Modelo prototipao............................................................................................. 30 2.2.5 Modelo espiral ...................................................................................................... 31 2.3 Mtodos de desenvolvimento de Software .................................................................. 33 2.3.1 Anlise Estruturada .............................................................................................. 34 2.3.2 Anlise Essencial.................................................................................................. 34 2.3.3 Anlise Orientada a Objetos ................................................................................. 35 2.4 Ferramentas de desenvolvimento de Software ............................................................ 35 2.5 Requisitos de software................................................................................................. 37 2.5.1 Tipos de requisitos................................................................................................ 38 2.5.1.1 Requisitos de usurios ................................................................................... 38 2.5.1.2 Requisitos de sistemas ................................................................................... 39 2.5.1.3 Requisitos funcionais..................................................................................... 39 2.5.1.4 Requisitos no-funcionais ............................................................................. 39 2.5.1.5 Requisitos de domnio ................................................................................... 40 2.5.2 Levantamentos de requisitos ................................................................................ 41 2.5.2.1 Aplicao de questionrios............................................................................ 41 2.5.2.2 Verificao de documentos ........................................................................... 41 2.5.2.3 Cenrios participativos .................................................................................. 42 2.5.2.4 Entrevistas ..................................................................................................... 42 2.5.2.5 Observao in-loco ........................................................................................ 43 2.5.3 Anlise dos requisitos........................................................................................... 43

12 2.5.4 Especificao de requisitos................................................................................... 44 2.6 Projeto do Software ..................................................................................................... 45 2.7 Projeto de Interface Homem-Computador (IHC)........................................................ 45 2.8 Implementao do Software ........................................................................................ 48 2.9 Testes do Software....................................................................................................... 49 2.10 Implantao do Software ........................................................................................... 50 2.11 Evoluo do Software................................................................................................ 51 Captulo 3. Anlise Orientada a Objetos com UML ...................................................52 3.1 Conceitos de Orientao a Objeto .............................................................................. 52 3.1.1 - Objetos .................................................................................................................. 52 3.1.2 - Classes................................................................................................................... 53 3.1.3 Mtodos, operaes, servios ............................................................................... 55 3.1.4 - Mensagens............................................................................................................. 55 3.1.5 - Encapsulamento .................................................................................................... 56 3.1.6 - Herana ................................................................................................................. 57 3.1.7 Polimorfismo ........................................................................................................ 58 3.2 Anlise Orientada a Objetos ........................................................................................ 59 3.3 Linguagem de Modelagem Unificada (Unified Modeling Language, UML) .............61 3.4 - Diagramas .................................................................................................................... 61 3.4.1 Diagrama de Caso de Uso (Use Case).................................................................. 62 3.4.1.1 Associao (Association)............................................................................... 64 3.4.1.2 Generalizao (Generalization)..................................................................... 64 3.4.1.3 Extenso (Extend).......................................................................................... 65 3.4.1.4 Incluso (Include) .......................................................................................... 66 3.4.2 Diagrama de classes.............................................................................................. 66 3.4.2.1 Visibilidade.................................................................................................... 67 3.4.2.2 Multiplicidade................................................................................................ 68 3.4.2.3 Atributos e Operaes ................................................................................... 68 3.4.2.4 Relacionamentos............................................................................................ 70 3.4.2.4.1 Associao .............................................................................................. 70 3.4.2.4.2 Generalizao ......................................................................................... 71 3.4.2.4.3 Dependncia ........................................................................................... 72 3.4.2.4.4 Agregao............................................................................................... 73 3.4.2.4.5 Composio ............................................................................................ 74 3.4.2.4.6 Realizao............................................................................................... 74 3.4.2.5 Classe de associao...................................................................................... 75 3.4.2.6 Classe de Interface......................................................................................... 76 3.4.3 Diagrama de Seqncia ........................................................................................ 77 3.4.4 Diagrama de Atividades ....................................................................................... 80 Captulo 4. Estudo de Caso.......................................................................................84 4.1 Definio do Ambiente e Escopo do Software............................................................ 84 4.1.1 Apresentao do ambiente ............................................................................. 84 4.1.2 Declarao do Objetivo Geral do Sistema ................................................... 85 4.1.3 Estudo de Viabilidade ...................................................................................... 86 4.1.4 Planejamento das Atividades................................................................................ 87 4.2 Levantamento de Requisitos do Software ................................................................... 88 4.2.1 Anlise e especificaes de requisitos. ........................................................ 89 4.3 Regras de negcios................................................................................................. 90

13 4.4 Diagrama de Caso de Uso ..................................................................................... 92 4.4.1 Descrio dos Cenrios .................................................................................. 94 4.5 Diagrama de Classes.................................................................................................... 97 4.6 Diagrama de Seqncia ............................................................................................... 98 4.7 Diagrama de Atividade.............................................................................................. 100 Anexo B Questionrio utilizado no levantamento de requisitos............................102 Anexo C - Tabelas de Grupos de Veculos .............................................................105 Anexo D - Tabelas de Tarifas de Locao de Veculos...........................................112 Anexo E Detalhes do Diagrama de Caso de Uso.................................................119 Anexo F Detalhes do Diagrama de Classes.........................................................128 Anexo G Detalhes do Diagrama de Seqncia Controlar Cobranca ..................145 Anexo H Detalhes do Diagrama de Atividades Controlar Cobranca...................149 Anexo I Prottipos de Interface Grfica................................................................153 Consideraes Finais ..............................................................................................156 Referncias Bibliogrficas .......................................................................................157

14

Introduo
Durante toda a minha trajetria profissional executei trabalhos em diversas reas entre elas: eletro-mecnica, automao industrial, eletrnica, informtica, redes e agora a rea de sistemas. Tenho gosto pela tecnologia desde pequeno e sempre procuro aperfeioar-me, tornou-se um hobby e por isso escolhi o curso de Sistemas de Informao. Sistemas de Informao foi uma maneira de integrar tudo o que j tenho como experincia tecnolgica e tambm acrescentar novos conhecimentos de sistemas computacionais. Para assimilar as tcnicas de desenvolvimento de sistemas de software escolhi um tema onde pudesse englobar itens de projeto e anlise orientada a objeto. Projeto de software orientado a objetos com UML: Estudo de caso em uma locadora de veculos. um trabalho onde proponho mostrar como pode ser feito uma anlise desde o levantamento de requisitos at a modelagem do sistema orientado a objetos. Inicialmente sero passados alguns conceitos bsicos sobre software1, sistemas e aplicaes para que o leitor sem muito conhecimento no assunto possa acompanhar com mais tranqilidade. Nos captulos seguintes sero abordados conceitos de engenharia de software e seus mtodos e processos, Anlise e Modelagem Orientadas a Objeto com UML2 e, por ltimo, um estudo de caso para a implementao de um sistema em uma locadora de veculos, que visa atender apenas as atividades operacionais no qual sero aplicados esses conceitos. Para fazer uma comparao de como eram os sistemas de antigamente podem-se observar os primeiros computadores e seus mtodos de programao e v-se o quo grande foi a evoluo em apenas 60 anos. Na dcada de 1940 o primeiro computador, chamado ENIAC3, tinha sua programao era feita atravs 6000 de chaves e a cada nova programao as chaves precisavam ser re-programadas, por volta da mesma poca, a International
Software uma palavra da lngua inglesa que foi incorporada lngua portuguesa como sendo um termo tcnico de informtica. Software um programa que instrui ao computador o que ele deve executar. O assunto ser abordado no captulo 1. 2 Abreviao do termo em ingls Unified Modeling Language ou Linguagem de Modelagem Unificada. Foi criada em 1996 para padronizar a modelagem de sistema orientada a objetos e utiliza-se de diagramas para representar as diversas partes do sistema. 3 ENIAC a abreviao de Electronic Numerical Integrator Analyzer and Computer. Foi construdo em 1945.
1

15 Business Machines Corporation IBM criou para seu computador o mtodo de programao atravs de cartes perfurados4. Com a evoluo dos computadores, novos mtodos, novas ferramentas e novas linguagens de programao tambm foram aprimorados para acompanhar o desenvolvimento do hardware5. Na dcada de 1980 eram comuns empresas que construam sistemas para computadores sem a utilizao de mtodos, os projetos eram feitos de forma desordenada, e depois de finalizado e apresentado o prottipo ao seu cliente, verificava-se que era necessrio fazer alguns acertos e perdia-se muito tempo no trabalho de manuteno. Esse processo de criao de software chamado de balbrdia 6. Sistemas criados seguindo a prtica da balbrdia caiam em desuso devido no atender as necessidades, ou devido ao custo de retrabalho, ou por no ter sido planejado de forma correta com a realidade do negcio, ou por no surtir o resultado satisfatrio. Com o surgimento da engenharia de software, o processo, seus mtodos e atividades passaram a ser utilizados na construo do software e com isso ganhouse mais qualidade no produto final e os processos ficaram melhor documentado. A criao de ferramentas, mtodos de desenvolvimento, estudos de uso de interface com o operador tambm contriburam para prolongar o ciclo de vida do software. Na dcada de 1990 teve inicio o paradigma7 da anlise orientada a objeto e os programadores comeam a ter uma nova viso de desenvolvimento e o velho paradigma da anlise estruturada foi caindo em desuso. De acordo com Bezerra (2002: 12), no resumo abaixo pode-se ter uma idia da evoluo das tcnicas de desenvolvimento. Dcada de 1950/60: Os sistemas eram muito simples e eram desenvolvidos com base em fluxogramas e diagramas de mdulos.

Os cartes perfurados era a maneira de inserir dados e instrues nos computadores daquela poca. Hardware uma palavra da lngua inglesa que foi incorporada lngua portuguesa como sendo um termo tcnico de informtica. Hardware como so chamados os componentes que compem o computador, a parte fsica. O assunto ser abordado no item 1.2.1. 6 Termo adotado por Tonsig (2003: 57) para retratar a maneira desorganizada com que algumas empresas e desenvolvedores criam seus sistemas. Balbrdia no um mtodo nem um modelo de desenvolvimento, e sim uma prtica de desenvolvimento de software onde os desenvolvedores no se preocupam em documentar e nem seguir as prticas da Engenharia de Software. 7 Paradigma a forma de abordar um problema.
5

16 Dcada de 1970: Nessa poca computadores mais avanados

comearam a surgir e necessitavam de sistemas mais robustos. Novos modelos surgiram e a partir deles a programao estruturada e o projeto estruturado. Dcada de 1980: Computadores tornam-se mais avanados e velozes, com isso h necessidade de interfaces mais sofisticadas e softwares mais complexos. Nesse perodo surge a Anlise Estruturada. Inicio da dcada de 1990: quando o novo paradigma da Anlise Orientada a Objeto surge. Fim da dcada de 1990: O novo paradigma da Anlise Orientada a Objetos comea a ganhar fora e surge a UML. No transcorrer desse trabalho poder ser verificado como deve ser feito a anlise e o projeto orientado a objetos a qual teve inicio na dcada de 1990, mas antes disso alguns conceitos e definies precisam ser estabelecidos. O primeiro captulo ir tratar de algumas definies: sobre o que um sistema, o que uma informao, hardware e software, possibilitando entender melhor os assuntos que sero abordados em seguida. O captulo dois, Engenharia de Software, sero tratados conceitos que abordam a anlise de sistemas, processos, mtodos, ferramentas, entre outros assuntos pertinentes ao captulo. No terceiro captulo, antes de passar os conceitos de anlise orientada a objetos, sero abordados definies de classes, objetos e tipos de modelagem de objetos e diagramas de classes. No capitulo quatro, uma vez definidos todos os conceitos principais, ser apresentado o estudo de caso de uma locadora de veculos colocando em prtica os tpicos abordados anteriormente.

17

Captulo 1. Sistema de Informao

O objetivo desse capitulo dar algumas definies bsicas sobre alguns elementos que compem o Sistema de Informao. Afinal, o que um Sistema? O que software? Hardware? Informao e dado so a mesma coisa? E o que exatamente Sistemas de Informao? Todas essas perguntas sero respondidas nesse captulo as quais sero muito importantes para o entendimento desse assunto como um todo.

1.1 Definio
A palavra sistema muito empregada em diversas reas tais como: sistema poltico, sistema de ensino ou sistema de comunicao. Por exemplo, quando se faz um telefonema para uma empresa onde o atendente necessita consultar alguma informao no computador e por alguma razo isso no possvel, o atendente diz: O sistema est fora do ar. Pode-se observar que o sistema no est somente em um computador ou em um equipamento eletrnico; o ser humano vive em um sistema, o sistema solar tambm um sistema! Na lngua portuguesa, pode-se encontrar muitos significados para a palavra sistema, a seguir seguem alguns significados:

1)Conjunto de elementos, materiais ou ideais, entre os quais se possa encontrar ou definir alguma relao; 2)Disposio das partes ou elementos de um todo, coordenados entre si, e que funcionam com estrutura organizada; 3) Complexo de regras ou normas. (AURLIO, 1988: 603).

Pode-se concluir que um sistema ...um conjunto de entidades relacionadas, interdependentes, que interagem entre si, buscando atingir um objetivo declarado e outros correlatos. (TONSIG, 2003: 8). Para definir o significado do termo Sistema de Informao, necessrio saber primeiro o que Informao. Por exemplo, uma data de nascimento de uma pessoa

18 09/04/1968 um dado ou uma informao? Saber que a idade dessa mesma pessoa hoje 38 anos e que no ano que seguinte ela ter 39 anos, um dado ou uma informao? Os dados podem ser considerados caractersticas ou propriedades bsicas de algo (pessoas, documentos, objetos, situaes e concatenaes dessas coisas) cujo contedo deve ser unvoco. (TONSIG, 2003: 27). Portanto conclui-se que a data de nascimento um dado. Seguindo essa mesma linha de raciocnio, se junto com a data de nascimento tiverem mais dados, por exemplo, nome, endereo, telefone, todos esses dados de forma organizada e tratadas por algum procedimento podem trazer uma informao, tais como: a idade, nome do cliente, endereo do cliente, telefone para contato. Conclui-se que a informao: obtida atravs de dados organizados de forma ordenada; Tem um perodo de validade, pois o dado pode mudar com uma certa freqncia; Tem um custo para ser obtida.

Com base em todos esses conceitos, pode-se definir que Sistemas de Informao no mbito computacional, como sendo um conjunto de mecanismos independentes que tratam os dados para obter informao para um fim especfico. Nas corporaes os sistemas de informao devem auxiliar nas tomadas de decises ou at mesmo faz-las, tem que integrar as informaes que esto isoladas, pois quanto mais informao melhor ser a deciso tomada. Resumindo: sistemas de informao a integrao de diferentes sistemas com diversos tipos de informao para auxiliar nas tomadas de decises ou tomar decises.

1.2 Elementos de Sistemas de Informao

Agora que se tem uma melhor definio do que sistema de informao, observa-se que o S.I.8 a interao de vrios tipos de sistemas diferentes, os quais so compostos por hardware, software, redes, pessoas e dados.

Abreviao de Sistemas de Informao.

19

1.2.1 Hardware
A palavra hardware provm da lngua inglesa e utilizado freqentemente no nosso idioma quando o assunto informtica. Hardware pode ser entendido como sendo a parte fsica composta por circuitos eletrnicos e outros componentes que compe o computador, seus perifricos e outros dispositivos eletrnicos. Exemplificando, o hardware pode ser: mouse9, teclado, placa me, disco rgido, monitor de vdeo, impressora, modem, roteador. O hardware que tem a capacidade de processar informaes possui dois componentes muito importantes: a memria e o processador. Esses dois componentes tm uma funo muito importante: A memria armazena dados e instrues a serem processados e o processador executa essas instrues. Logo, pode-se observar que, com o avano da tecnologia, o hardware tornase mais sofisticado a ponto de fazer tarefas programadas, ou seja, eles armazenam e processam os dados, que de alguma forma, so convertidos em informaes para o usurio. A pea fundamental que atua diretamente com o processador e a memria o programa chamado software.

1.2.2 Software
A palavra software provm da lngua inglesa e muito utilizada na informtica. O software a parte lgica do computador e quem diz ao hardware o que fazer e quando fazer, em outras palavras um conjunto de instrues que sero executadas pelo processador para executar uma determinada tarefa. Existem vrios tipos diferentes de software, Tonsig (2003: 54-56) explica: Software bsico: um programa que visa atender as necessidades bsicas do hardware, sua execuo feita para dar suporte a outros tipos programas. Alguns exemplos de software bsico so: BIOS10 do

10

Dispositivo apontador usado em sistemas baseados em janelas. Por exemplo: Microsoft Windows Abreviao do termo em ingls: Basic Input Output System ou Sistema Bsico de Entrada e Sada. BIOS um componente eletrnico (memria) que armazena uma pequena quantidade de dados, suficiente para fazer a programao bsica do computador antes que o sistema operacional seja carregado.

20 computador, Firmware11 de perifricos, drivers12 e sistema operacional. Especificamente nos casos do BIOS e Firmware, o software bsico um tipo de programa de baixo nvel onde as instrues so compostas por mnemnicos (instrues de mquina), que so compiladas de acordo com a arquitetura do processador. O software bsico executado primeiramente para configurar as funes bsicas do hardware, para que possa ser carregado o software aplicativo. Software aplicativo: Para utiliz-lo necessrio que o software bsico esteja instalado para que d suporte as rotinas e instrues do software aplicativo. So exemplos de software aplicativo: programas editores de texto, planilhas de clculo, programas corporativos para suprir

necessidades administrativas. Mais de um software aplicativo pode estar instalado no mesmo hardware, eles podem trocar informaes entre si e tambm pode fornecer informaes para os usurios, alm de se comunicar com outro software aplicativo instalado em outro hardware, utilizando para isso uma rede de computadores. Software embutido: Tambm conhecido como embedded systems, podem ser utilizados em palms, celulares, computadores automotivos e dispositivos de rede. Pode ser considerado um software bsico e / ou software aplicativo, pois esse tipo de software gerencia todas as funes operacionais desses dispositivos. Os dispositivos equipados com o hardware e o software no tm muita utilidade se eles estiverem isolados uns dos outros, por isso existe a comunicao entre eles que feita atravs de uma rede.

1.2.3 Redes
Pode-se definir rede como sendo uma quantidade de pontos interligados com outros pontos que podem ser de vrios tipos diferentes. As redes de computadores podem ser de vrios tipos, tamanhos e com velocidades e tipos de conexes variadas.
11

Programa em linguagem de baixo nvel que armazenado em uma memria somente de leitura. O firmware tambm um componente eletrnico (memria) que faz a programao em diversos tipos de perifricos do computador e equipamentos eletrnicos, tais como: aparelho celular, impressora, aparelho de DVD. 12 Pequeno programa para dar suporte ao software de alto nvel na comunicao com o hardware.

21

Uma rede de computadores consiste de dois ou mais computadores e outros dispositivos ligados entre si e compartilhando dados, impressoras, trocando mensagens (e-mails), etc. Internet um exemplo de Rede. Existem vrias formas e recursos de vrios equipamentos que podem ser interligados e compartilhados, mediante meios de acesso, protocolos e requisitos de segurana. (WIKIPDIA. In: Redes de computadores, 2006).

Pode-se classificar as redes de acordo com a arquitetura, extenso geogrfica, topologia e o meio de transmisso: Arquitetura de Rede: Ethernet, Token Ring, FDDI (Fiber Distributed Data Interface Interface de Dados Distribudo por Fibra), Giga Ethernet, ATM (Asynchronous Transfer Mode Modo de Transferncia Assncrona); Extenso geogrfica: LAN (Local Area Network), MAN (Metropolitan Area Network), WAN (Wide Area Network); Topologia13: Rede em anel, ponto-a-ponto, barramento, estrela; Meio de transmisso: Rede por cabo coaxial, fibra tica, par tranado, Wireless rede sem fios, infravermelhos, microondas.

1.2.4 Pessoas
Cada ser humano tem comportamentos diferentes, alguns tem um bom relacionamento interpessoal outros so mais reservados, mas para se desenvolver um software, o fator primordial a comunicao entre o projetista e o usurio / cliente. A pea-chave no desenvolvimento de software sem dvida o contato com o usurio, pois ele necessitar da ferramenta que ser desenvolvida, portanto ele precisa passar as diretrizes de funcionamento. Muitos usurios no sabem expressar o que realmente querem, outros mais ocupados no querem perder tempo com reunies onde sero levantados os requisitos e passam essa responsabilidade para algum subalterno. Problemas relacionados com a informao levam ao desenvolvimento de um software que no
13

Topologia de rede a forma por meio da qual ela se apresenta fisicamente, ou seja, como os elementos de rede esto dispostos.

22 atende as necessidades do cliente e por isso que a boa comunicao e um bom relacionamento interpessoal so fundamentais. A boa comunicao e o bom relacionamento interpessoal tambm so importantes entre os membros da equipe de desenvolvedores, pois a equipe deve estar alinhada e em perfeita sintonia com as diretrizes do projeto e do cliente. Outro fator importante so as mudanas que o novo projeto trar ao dia-a-dia do usurio. O ser humano, de uma maneira geral, no aceita e no se adapta facilmente s mudanas, isso devido ao fato de que o ser humano acostuma-se facilmente com o cotidiano (paradigma do comportamento). Quando sugere-se ao usurio a substituio de algum aplicativo comum ouvir ... por que mudar, est funcionando bem assim!. Neste momento deve-se mostrar quais as melhorias que o novo software trar ao seu trabalho.

1.2.5 Dados
Tonsig (2003, 26), citando Pompilho (1995), explica que dado ... a estrutura fundamental sobre a qual um sistema de informao construdo. Smbolo intencionalmente destacado para representar uma caracterstica ou propriedade da realidade a ser tratada. Exemplificando a citao de Tonsig, podemos dizer que dados so caractersticas de algo ou algum tais como nome, endereo, data de nascimento de uma pessoa, nmeros e outros itens de um documento, propriedades de um objeto.

1.3 O Projeto de Software

Quando existe um software para ser construdo, vrios profissionais estaro envolvidos no projeto os quais tero que estar em constante sincronismo, pois a falha ou atraso de alguma etapa poder comprometer todo o projeto. nessa hora que entra em ao a figura do Gerente de Projeto.

1.3.1 Gerncia de Projeto de Software

23 O gerente de projeto no deve ter apenas conhecimentos de gerenciamento de pessoas e operaes, mas tambm deve deter ou buscar o conhecimento tcnico sobre o projeto, pois ele poder ter que gerenciar uma rea na qual no detm o conhecimento, nesse caso estar colocando todo o projeto em risco. Ele

desenvolver trabalhos de coordenao, administrao, superviso da sua equipe, dever levantar os riscos14 e saber como contorn-los, responsvel por manter a equipe alinhada com os objetivos at a fase de implantao do software. Deve, acima de tudo, saber trabalhar sobre presso e conviver com incertezas, e paralelamente a isso, manter um ambiente de trabalho agradvel para seus colaboradores. Em um projeto de software o gerente de projeto deve seguir as prticas de engenharia de software mesmo que sejam burocrticas, e ter sempre em mente que cada projeto diferente um do outro. Pois muitos gerentes, no intuito de agilizar o trabalho devido presso para o cumprimento do cronograma, acabam por deixar de documentar o processo ou utilizar software adaptado e remendado de um projeto antigo. Outro fator muito importante que o gerente tem que se preocupar com o cronograma e os recursos, pois qualquer alterao em um desses itens, tais como contratar mais recursos ou prolongar alguma tarefa, ir influenciar diretamente no prazo de entrega e no custo final do projeto. A primeira ao de um gerente de projeto a definio do escopo do software. Definio do escopo do software Planejamento das atividades necessrias. Criao de cronograma. Organizao e Controle. Locao de recursos para atividade e coordenao. Checagem do Realizado X Previsto. Documentao de desvios
Figura 1: Etapas de processos gerenciais (TONSIG, 2003: 70)
14

Para tomar decises eficientes, necessrio ter conhecimento dos riscos que o projeto enfrenta e claras estratgias para trat-los ou elimin-los. Portanto risco tudo o que pode acontecer desde o incio at o trmino do projeto, e que atualmente incerto ou desconhecido.

24

1.3.2 Definio do Escopo do Software

O escopo do software deve ser bem definido com o cliente, deve-se saber tudo sobre que o software dever fazer, em qual ambiente ele ser instalado, quantos usurios iro acess-lo e de que maneira, detalhes do hardware onde o software ser executado. Tonsig (2003: 110), explica que na fase de definio do escopo que o gerente de projeto dever fazer uma estimativa do custo do software, quantidade de recursos envolvidos no projeto e o prazo de entrega do software. Para isso necessrio saber quais so as viabilidades do projeto: Viabilidade tcnica: So verificadas a existncia de hardware, software e pessoas com conhecimento tcnico disponvel para atender os requisitos de sistema. Viabilidade operacional: Diz respeito s conseqncias na implantao ou modificao de processos da organizao ou sociedade. Viabilidade econmica: Ser verificado se vivel o custo da soluo encontrada. Algumas vezes o projeto do software pode tornar-se invivel devido ao fator custo, tcnico ou operacional, mas nesse caso o cliente quem decide pela viabilidade ou no do projeto. Uma vez definida a viabilidade do projeto a prxima etapa o planejamento das atividades.

1.3.3 Planejamento das Atividades

O planejamento pode ser representado de vrias formas grficas onde se devem alocar os recursos, o tempo gasto para cada atividade, a descrio da atividade, o custo dessa atividade, quando comea e quando termina. Tonsig (2003: 73) explica que, no planejamento, deve-se definir sobre cada atividade: Uma descrio sobre ela (O QUE); As devidas justificativas (POR QUE); Quais recursos sero alocados para cada atividade (QUEM);

25 Definir a ordem que cada atividade deve ser realizada (QUANDO); Qual tcnica deve-se empregar (COMO); O local da sua realizao (ONDE).

Todos os itens citados acima pode-se dispor na forma de um diagrama onde observar-se facilmente quais so as tarefas, quem so os recursos, quando comeam e quando terminam cada tarefa.

1.4 Aplicao do Software

Como visto no item 1.2.1 o hardware tem varias aplicaes, porm sem o software o hardware no tem utilidade. Ao unir as funcionalidades do hardware com as diretrizes do software pode-se criar um produto com vrias aplicaes. A aplicao mais usual so os aplicativos para computadores pessoais. As quantidades e tipos de aplicaes do software so vastos e so limitados apenas pela tecnologia e pela criatividade dos projetistas. Pode-se citar alguns exemplos de tecnologias aplicadas ao uso do software: dispositivos mveis como Assistente Pessoal Digital (Personal Digital Assistants, PDA ou Handhelds), celulares, programas armazenados e executados em cartes (Java Card
15

) e a

interconexo entre equipamentos diversos para troca ou envio de informaes.

15

Carto do tipo Smart Card, com pouca memria, que tem capacidade para armazenar pequenos programas em Java permitindo sua execuo atravs de um dispositivo externo. Ex.: Chip para celular com tecnologia GSM.

26

Captulo 2. Engenharia de Software

A primeira meno engenharia de software ocorreu em 1968 quando ainda no utilizava-se de processos para a criao de software. Foi a poca em que comearam a surgir computadores mais avanados e complexos e observou-se que, se continuasse a utilizar os mtodos de desenvolvimento de software antigos, o avano do software no acompanharia o hardware. O custo do desenvolvimento do software crescia enquanto que o custo do hardware caia, foi ento necessrio uma reviso nos mtodos e processos de desenvolvimento de software.

2.1 O que Engenharia de Software

A engenharia de software similar engenharia voltada a outras reas, tem como objetivo criar processos, normatizaes, novas abordagens e documentos envolvidos no desenvolvimento de software. A engenharia de software ...uma disciplina da engenharia, cuja meta o desenvolvimento de sistemas de software com boa relao custo / beneficio. (SOMMERVILLE, 2003: 3)

2.2 Processo de desenvolvimento de Software

O processo de desenvolvimento composto por etapas que so executadas por engenheiros, analistas e programadores. Em cada etapa so executados diferentes tipos de atividades onde, ao trmino de todo o processo, desenvolvido um produto (software) que implantado. Genericamente, as etapas de desenvolvimento de software, podem ser divididas em fases: anlise de requisitos, projeto, desenvolvimento, implantao e manuteno. Existem vrios modelos padres para o processo de desenvolvimento de software que foram criados baseados em outros processos de engenharia. Os modelos mais comuns so: balbrdia, cascata, incremental, prototipao e espiral. Mas nada impede que, em um processo de desenvolvimento, seja seguido

27 um modelo baseado em dois ou mais modelos, ou ento, seja criado um novo modelo desde que as etapas bsicas sejam seguidas.

2.2.1 Modelo balbrdia

Dos modelos apresentados, o modelo balbrdia16 o nico modelo que nunca deve ser tomado como referncia. Nesse modelo no h planejamentos nem documentao dos processos, e a constante mudana no software para atender novos requisitos torna esse modelo, como o prprio nome diz, uma balbrdia. O processo de desenvolvimento de software um constante retrabalho onde existe a implementao e em seguida a implantao, e volta-se novamente para a implementao por no ter atendido os requisitos e / ou as necessidades funcionais. O diagrama desse processo representado na figura abaixo.

IMPLEMENTAO

IMPLANTAO

Figura 2: Modelo balbrdia (TONSIG, 2003: 58)

2.2.2 Modelo clssico ou cascata

O primeiro modelo publicado do processo de desenvolvimento de software originou-se de outros processos de engenharia (ROYCE, 1970. In: SOMMERVILLE, 2003: 37).

16

Termo adotado por Tonsig (2003: 57) para retratar a maneira desorganizada com que algumas empresas e desenvolvedores criam seus sistemas. Balbrdia no um mtodo nem um modelo de desenvolvimento, e sim uma prtica de desenvolvimento de software onde os desenvolvedores no se preocupam em documentar e nem seguir as prticas da Engenharia de Software.

28 No modelo cascata os processos acontecem seqencialmente, esse processo de desenvolvimento ideal para situaes onde os requisitos so bem definidos e compreendidos. Pelo fato dos processos acontecerem seqencialmente, uma fase comea quando a etapa anterior termina. Conforme a figura abaixo, nesse modelo encontramos as fases de anlise de viabilidades, definio de requisitos, projeto de sistema e de software,

implementao, testes, implantao e manuteno.

Anlise de viabilidades Anlise de requisitos

Projeto

Implementao

Testes

Implantao

Manuteno

Figura 3: Modelo Cascata (TONSIG, 2003: 59)

O processo de anlise de viabilidade onde ser obtida uma idia bsica do que o software vai desempenhar. Na segunda etapa feito o levantamento dos requisitos de forma mais detalhada de modo a fornecer dados suficientes ao projeto. Na fase de projeto ser elaborado todo o sistema (interface com o usurio, meio de armazenamento de dados, interligao entre os sistemas). na implementao que ocorre a programao propriamente dita, seguida pelos testes e implantao do sistema como um todo. na implantao que o sistema entra em produo e os usurios comeam a utiliz-lo, e onde so

29 verificados se todos os requisitos implementados atendem as necessidades que foram inicialmente levantadas. Tambm possvel que apaream novas falhas de projeto nessa fase. Por ser um modelo seqencial, comum encontrar problemas em uma fase que deveriam ter sido solucionados nas fases anteriores, quando isso acontece ocorrem retrabalhos. Esse tipo de modelo aumenta o custo do desenvolvimento do software por ter vrios retrabalhos e comum pular para as etapas seguintes do modelo mesmo com algumas falhas constatadas nas etapas anteriores. Obviamente que, ao ser implantando o software, algumas funes podero no funcionar de acordo com as necessidades do usurio. Todas as falhas, tanto as que foram deixadas durante o processo, quanto as demais falhas encontradas na fase de implantao, sero corrigidas na fase de manuteno.

2.2.3 Modelo incremental

A abordagem do desenvolvimento incremental (...) foi sugerida por Mills. (Mills et al., 1980. In: SOMMERVILLE, 2003: 43). O modelo incremental uma variao do modelo cascata e tem como objetivo diminuir o retrabalho. Nesse modelo os desenvolvedores no tm uma viso detalhada do que ser o software como um todo, pois ele divido em vrias partes de acordo com o grau de prioridade de entrega, as mais prioritrias so entregue primeiro, e depois as menos prioritrias. A prioridades so definidas em reunies com o cliente juntamente com os prazos de entrega para cada parte do sistema. Os primeiros incrementos servem como um prottipo para o usurio se familiarizar com o sistema e ajudam os projetistas coletar de novos requisitos. Com base nesses requisitos, um novo incremento ser criado e disponibilizado na prxima verso. Sempre que novas funcionalidades so adicionadas um novo incremento ao software criado e disponibilizado ao usurio. Dessa forma, o usurio no precisa esperar o trmino de todo o desenvolvimento para comear a utilizar o software, e por outro lado, ele vai sendo testado medida que novos requisitos menos importantes vo sendo incrementados.

30 Uma vantagem desse modelo que, para iniciar o desenvolvimento, no necessrio ter em mos todos os requisitos como no modelo cascata, aos poucos, os requisitos sero adicionados nos incrementos medida que vo surgindo. Outra vantagem , devido aos incrementos mais importantes terem sido entregues primeiro, eles so testadas por um tempo maior pelo usurio o que diminui falhas. Uma das desvantagens desse modelo o fato do software ser dividido em partes, pois no se consegue visualizar quais sero as funcionalidades que o cliente deseja implantar, sendo assim, fica difcil criar incrementos sem saber se a funcionalidade de uma parte poder, ou no, ser usada por outra. Isso poder ocasionar problemas, onde alguma funcionalidade no atenda as necessidades dos usurios.

Definir esboo dos requisitos

Atribuir requisitos aos incrementos

Projetar arquitetura do sistema

Desenvolver incremento do sistema

Validar incremento

Integrar incremento

Validar sistema

Sistema final

Sistema incompleto novo requisito / funcionalidade

Figura 4: Modelo incremental (SOMMERVILLE, 2003: 43)

2.2.4 Modelo prototipao

No modelo de prototipao tem como objetivo diminuir o tempo de produo do software e dar ao usurio uma viso mais realista do que est sendo construdo, fazendo com que ele participe do desenvolvimento opinando sobre os

desenvolvimentos das telas e relatrios. Isso faz com que o usurio / cliente se torne co-responsvel pelo produto final. Seguindo o fluxo abaixo pode-se analisar o que o modelo prototipao prope.

31

Anlise de requisitos

Desenvolvimento de prottipo

Experimentao

Reviso

Detalhamento

Codificao e testes

Manuteno

Implantao

Figura 5: Modelo prototipao (TONSIG, 2003: 61)

Como pode-se observar, nesse modelo, tem como etapa inicial a anlise de requisitos e tambm a definio das telas e relatrios onde o usurio teve participao. Diferente do modelo incremental, o usurio no poder operar o sistema at o final do projeto. Aps passar por vrias experimentaes e revises, o prottipo aperfeioado, passa pela etapa de codificao, testes e s ento implantado. conveniente deixar o usurio ciente de que a codificao do software no to rpida e simples como o projeto da tela e relatrios, pois o software em si necessita ser codificado. Isso pode gerar uma ansiedade por parte do usurio.

2.2.5 Modelo espiral

Sommerville (2003: 44) diz que o modelo de processo de desenvolvimento em espiral foi proposto por Boehm em 1988. O modelo espiral rene as vantagens dos modelos mais antigos. Ele tem um formato espiralado e dividido em quatro quadrantes, cada quadrante representa uma etapa: Determinar objetivos, Avaliao de alternativas e riscos,

Desenvolvimento e verificao de produto, Avaliao e planejamento. O processo inicia-se no centro do espiral e percorre as diversas etapas no sentido horrio.

32 No 1 quadrante, feita a anlise de requisitos e de viabilidades, os objetivos so definidos e os riscos so relacionados. No 2 quadrante, so avaliados os riscos e, dependendo do nvel de abstrao17 dos requisitos levantados na etapa anterior e dos riscos envolvidos, pode-se implementar o modelo prototipao para obter requisitos mais detalhados. Nesse caso um prottipo do software desenvolvido referente a abstrao em questo. No 3 quadrante, o software entra na fase de desenvolvimento. definido o modelo no qual o software ser desenvolvido e, dependendo do grau de risco, podese adotar outros modelos e implement-los no espiral. Por exemplo, se os requisitos forem bem definidos pode-se utilizar o modelo cascata.

Figura 6: Modelo espiral (SOMMERVILLE, 2003: 45)

No 4 quadrante, o trabalho realizado durante esse ciclo apresentado ao cliente para validao e um planejamento para o prximo ciclo definido.

17

Abstrao o processo mental em que as idias esto distanciadas dos objetos, operao intelectual onde existe o mtodo que isola os generalismos tericos dos problemas concretos, trata-se de um mecanismo essencial em disciplinas filosficas e cientficas.

33 Finalizando o ultimo quadrante, h uma iterao do processo para os ciclos seguintes e o desenvolvimento segue um processo evolutivo. A quantidade total de ciclo no especificada e depende de cada projeto de software.

2.3 Mtodos de desenvolvimento de Software

A abordagem desse trabalho est focada na anlise orientada a objetos, portanto, no ser explicado em detalhes todos os mtodos de desenvolvimento citados. Em muitos projetos, as informaes obtidas geram muitos documentos. Ao iniciar a etapa de codificao e desenvolvimento propriamente dita, pode haver algumas modificaes no projeto original e, devido a falta de controle, essas modificaes so implementadas diretamente no software, mas algumas vezes, no so acrescentadas nas documentaes do projeto. Resultado: Ao final do projeto temos a documentao desatualizada. Sommerville (2003: 49) conclui que a utilizao de mtodos estruturados garante a criao de uma documentao padro para o projeto. Antes de fazer uma descrio dos mtodos de desenvolvimento de software, na tabela abaixo pode-se observar um resumo do histrico mostrando os mtodos e tcnicas de desenvolvimento de software.

Modelo
Balburdia (Informal) Desde o inicio dos anos 50 (at hoje em alguns casos), porm, sem outra alternativa at o incio da dcada de 70. Estruturado O mtodo comeou efetivamente a ser empregado a partir de 1975 e dever ainda continuar sendo utilizado por mais alguns anos pelas empresas que possuem estruturas de

Abordagem
Funcionalidade (com maior enfoque) e dados Textos

Ferramentas
Fluxogramas

Inicialmente a funcionalidade e depois os dados. Posteriormente, com a maturidade das ferramentas de SGBD ,
18

Diagrama de Fluxo de Dados (DFD) Especificao dos processos Diagrama de Entidade Relacionamento (DER) Normalizao

18

SGBD a sigla de Sistema Gerenciador de Bando de Dados.

34
sistemas concebidas a partir desse modelo, que ainda se encontra ativos. os dados ganham mais nfase. Diagrama de Estrutura de Dados (DED) Dicionrios de Dados Essencial Trata-se de um aprimoramento do modelo estruturado que teve incio em 1984. Essncia Funcional e Dados Integrao Funcional e Dados DFD de Contexto Lista de Eventos DFD Particionado por Eventos Diagrama Entidade Relacionamentos Diagrama de Estrutura de Dados Normalizao Dicionrios de Dados Orientado a Objetos Decorrente dos conceitos j existentes nas linguagens de programao, especialmente na Simula(67) e Smaltalk(70). A aplicao na anlise de sistemas teve incio na dcada de 90. Funcionalidade Objeto = Encapsulamento de Funes e Dados Contempla o estado de um objeto Viso esttica e dinmica Diagrama de Caso de Uso Diagrama de Classes e Objeto Diagrama de Seqncia Diagrama de Colaborao Diagrama de Componentes Diagrama de Distribuio

Tabela 1: Histrico dos mtodos de desenvolvimento de software (TONSIG, 2003: 105)

2.3.1 Anlise Estruturada

Tonsig (2003: 107) diz que a anlise estruturada prope uma metodologia de construo de sistema que inicia-se com uma viso global e vai aprofundando para nveis de detalhamento mais especficos. Utiliza-se de: Diagramas de Fluxo de

Dados (DFD) dispostos em vrios nveis, o primeiro nvel tem uma viso macro, quanto mais se aprofunda nos nveis subseqentes, maior o de detalhamento; o Diagrama de Entidade Relacional (DER) uma ferramenta que auxilia a fazer o modelo conceitual do Banco de Dados.

2.3.2 Anlise Essencial

A anlise essencial surgiu da analise estruturada e tem como objetivo estudar um sistema ideal sem se prender s restries tecnolgicas, para isso imagina-se um sistema ideal.

35 Tonsig (2003: 126) explica que esse estudo feito para o levantamento das funcionalidades do sistema e, baseado nesse levantamento, um modelo essencial dessas funcionalidades desenvolvido.

2.3.3 Anlise Orientada a Objetos

O mtodo de desenvolvimento orientado a objetos prope um novo paradigma no desenvolvimento de software. Tonsig (2003: 165) explica que enquanto o mtodo estruturado trabalha com as funcionalidades e modelagem de dados separadamente, a anlise orientada a objetos tem uma viso nica e trabalha com as funcionalidade e modelagem de dados ao mesmo tempo. Uma abordagem mais detalhada sobre a anlise orientada a objetos ser visto no capitulo 3.

2.4 Ferramentas de desenvolvimento de Software

A engenharia de software sempre construiu diversos tipos de software para auxiliar muitos tipos de usurios e automatizar vrios tipos de processos, mas at ento os profissionais envolvidos no desenvolvimento de software no tinham ferramentas prprias que os auxiliassem no desenvolvimento dos mesmos. como um dito popular: Na casa de ferreiro o espeto de pau. Foi ento que desenvolveu-se um tipo de ferramenta para ajudar no processo de desenvolvimento de software. Essas ferramentas so chamadas
19

de

Ferramentas C.A.S.E. que so utilizadas por engenheiros de software para auxiliar e automatizar os processos de desenvolvimento de software. Sommerville (2003: 54), citando Fuggetta (1993), comenta sobre os tipos de ferramentas C.A.S.E. existentes, divididas em trs categorias: Ferramentas; Workbenches20; Ambientes.

19

A palavra C.A.S.E. uma abreviao do termo em ingls Computer Aided Software Engineering que significa Engenharia de Software Auxiliada por Computador. 20 Palavra inglesa cujo significado bancada de trabalho. No contexto onde aplicado, pode-se interpretar como teste de mesa onde sero verificadas e validadas as funcionalidades do software.

36 Na figura 7, pode-se observar melhor como essas categorias so subdivididas.

Tecnologia C.A.S.E.

Ferramentas

Workbenches

Ambientes

Editores

Compiladores

Comparadores de arquivos

Ambientes integrados

Ambientes centrados em processo

Anlise e projeto

Testes

Programao

Workbenches com vrios mtodos

Workbenches com mtodo nico

Workbenches de propsito geral

Workbenches de linguagem especfica

Figura 7: Subdiviso das ferramentas CASE. (SOMMERVILLE, 2003: 56)

De acordo com Pressman (2002: 810), as ferramentas C.A.S.E. podem ser classificadas de acordo vrios aspectos. Abaixo tem-se uma relao da sua classificao pela funo: Ferramenta de engenharia de processo de negcio; Ferramenta de modelagem e gesto de processo; Ferramenta de planejamento de projeto; Ferramenta de anlise de risco; Ferramenta de gesto de projeto; Ferramenta de rastreamento de requisitos; Ferramenta de mtricas e gesto; Ferramenta de documentao; Ferramenta de software bsico;

37 Ferramenta de garantia de qualidade; Ferramenta de gesto de base de dados; Ferramenta de gesto de configurao de software; Ferramenta de anlise e projeto; Ferramenta PRO/SIM (Prototipao e Simulao); Ferramenta de projeto e desenvolvimento de interfaces; Ferramenta de prototipao; Ferramenta de programao; Ferramenta de desenvolvimento WEB21; Ferramenta de integrao e teste; Ferramenta de anlise esttica; Ferramenta de anlise dinmica; Ferramenta de gesto e teste; Ferramenta de teste cliente / servidor; Ferramenta de reengenharia.

Os fabricantes de ferramentas C.A.S.E. normalmente incorporam a facilidade de poder exportar documentos de uma ferramenta para outra, essa funo muito til para o processo de produo de software.

2.5 Requisitos de software

Uma vez analisado a viabilidade do projeto, o trabalho de desenvolvimento do software inicia-se com levantamento de diversos tipos informaes as quais auxiliaram todo o trabalho de desenvolvimento. O conjunto de informaes, tais como: as funcionalidades e restries do software, as necessidades do cliente, funcionalidade dos processos e documentos internos da empresa, do-se o nome de requisitos. Os requisitos so as peas fundamentais, auxiliam o analista no entendimento do funcionamento do software que ser projetado. Por isso, se os requisitos forem mal interpretados, omitidos, ou no condizerem com a verdade, o projeto no atender as necessidades do cliente / usurio.
21

Abreviao de World Wide Web. uma rede mundial de computadores que fornece informao em forma de hipertexto, tambm chamada de Internet.

38 Os requisitos so classificados em vrios tipos e existem diversas tcnicas de se obter do cliente o que ele realmente necessita.

2.5.1 Tipos de requisitos

Segundo Sommerville (2003: 82), pode-se dividir e resumir os requisitos da seguinte forma: Requisitos de usurios: So declaraes em linguagem natural sobre as funes do sistema. o Requisitos funcionais: Descreve em linguagem natural as

funcionalidades do sistema. o Requisitos no-funcionais: Descreve em linguagem natural os requisitos que no diz respeito as funcionalidades do sistema. Requisitos de sistemas: Estabelece detalhadamente as funes e restries do sistema. Podem ser subdivididos em: o Requisitos funcionais: Descreve as funcionalidades do sistema. o Requisitos no-funcionais: No diz respeito as funcionalidades do sistema. o Requisitos de domnio: Descreve as caractersticas do domnio. Pode-se ver a seguir uma definio mais detalhada de cada um desses requisitos.

2.5.1.1 Requisitos de usurios

Os requisitos de usurios devem descrever, em uma linguagem

compreensvel pelos usurios, os requisitos funcionais (funcionalidades do sistema) e os requisitos no-funcionais, mas no deve-se evitar entrar em detalhes tcnicos no que diz respeito ao desenvolvimento do software. O fato dos requisitos serem escritos em um tipo de linguagem natural (no tcnica) poder trazer alguns problemas, tais como: a falta de clareza e interpretao do requisito, misturar os requisitos funcionais com os no-funcionais ou at relacionar um ou mais requisitos em um s.

39

2.5.1.2 Requisitos de sistemas

As especificaes dos requisitos de sistemas so mais abrangentes e mais detalhadas do que os requisitos de usurios. Os ...requisitos de sistema deveriam definir o que o sistema deveria fazer, e no como ele teria de ser implementado. (SOMMERVILLE, 2003: 91). A linguagem natural utilizada para descrever esse tipo de requisito e pode servir como base para o contrato de desenvolvimento e implementao do sistema. necessrio incluir o mximo de informaes possveis, pois isso pode ajudar aos analistas a definir uma arquitetura inicial do sistema e a fornecer requisitos adicionais no caso de sistemas coexistentes que necessitem de integrao ao novo sistema.

2.5.1.3 Requisitos funcionais

Os requisitos funcionais devem relacionar de forma consistente e completa todas as funcionalidades, servios e necessidades do cliente / usurio para o sistema que ser desenvolvido. Quando trata-se de requisitos de usurio os requisitos funcionais so escritos em linguagem natural de fcil compreenso pelos usurios, mas quando trata-se de requisitos de sistemas os requisitos funcionais devem especificar as funes, as excees e demais processos em detalhes.

2.5.1.4 Requisitos no-funcionais

Requisitos no-funcionais esto relacionados com aspectos de confiabilidade, tempo de resposta, tamanho ocupado em memria, espao em disco, portabilidade do sistema. Tambm podem especificar restries do sistema. Em geral, os requisitos no-funcionais fornecem informaes do sistema como um todo, j os requisitos funcionais especificam caractersticas individuais ou parciais do sistema. Portanto, isso torna o requisito no-funcional mais importante que o funcional. A conseqncia da falha na implementao de um requisito funcional ser a inoperabilidade de uma funo ou conjunto de funes, se isso acontecer em um requisito no-funcional o sistema pode torn-lo inutilizado.

40 Na figura 8, podem-se observar os vrios tipos de requisitos no-funcionais que podem surgir.
Requisitos no-funcionais

Requisitos do produto

Requisitos organizacionais

Requisitos externos

Requisitos de eficincia

Requisitos de confiabilidade

Requisitos de portabilidade

Requisitos de interoperabilidade

Requisitos ticos

Requisitos de facilidade de uso

Requisitos de entrega

Requisitos de implementao

Requisitos de padres

Requisitos legais

Requisitos de desempenho

Requisitos de espao

Requisitos de privacidade

Requisitos de segurana

Figura 8: Tipos de requisitos no-funcionais (SOMMERVILLE, 2003: 85)

2.5.1.5 Requisitos de domnio

Os requisitos de domnio podem ser funcionais ou no-funcionais e esto relacionados com dados e informaes especficas sobre o ambiente em que o sistema vai operar, o analista deve ter conhecimento e o domnio das informaes do ambiente em questo. Esses tipos de requisitos ... podem ser novos requisitos funcionais em si, podem restringir os requisitos funcionais existentes ou estabelecer como devem ser realizados clculos especficos. (SOMMERVILLE, 2003: 88).

41

2.5.2 Levantamentos de requisitos

O levantamento de requisitos consiste em obter do usurio / cliente as informaes, dados, e processos relativos ao sistema de forma que o analista possa entender o que se pretende desenvolver e saber o que o usurio / cliente quer que o software faa. Conhecer com exatido o ambiente do usurio, sua forma de trabalho, a estrutura da organizao, os problemas e as necessidades a serem supridas pelo novo sistema fundamental para o processo de desenvolvimento de software. (TONSIG, 2003: 94). Pode-se citar algumas maneiras de como coletar esses requisitos: Aplicao de questionrios; Verificao de documentos; Cenrios participativos; Reunies e entrevistas; Observao in-loco 22.

2.5.2.1 Aplicao de questionrios

A tcnica de aplicao de questionrios tem um custo baixo para o desenvolvedor, porm no um bom recurso de levantamento de requisitos por limitar requisitos adicionais que por ventura o usurio possa fornecer. Dependendo da forma que o questionrio for aplicado, suas questes podemse tornar muito cansativas e pouco especificas.

2.5.2.2 Verificao de documentos

A verificao de documentos uma boa tcnica na aquisio de requisitos para o desenvolvimento de software, desde que, seja agregada a alguma outra tcnica de levantamento de requisitos. So muito teis para levantar, dentre os dados utilizados nos processos, quais tem realmente alguma importncia ou se est faltando algum dado adicional que no esteja sendo requisitado nos documentos.

22

Termo em ingls cujo significado quer dizer no lugar. No contexto entende-se no ambiente.

42 Como por exemplo, um formulrio de requisio onde pode haver campos ou lacunas que nunca foram utilizados ou sua inexistncia para alguma informao essencial ao processo que nunca fora solicitado.

2.5.2.3 Cenrios participativos

Em uma empresa, muitas vezes tm-se vrias pessoas envolvidas em processos onde, por sua vez, cada uma detm uma parte da informao. E, algumas vezes, o responsvel pelo departamento pode no dominar todos os processos. Nesses casos fica difcil para o analista unir todas essas informaes desencontradas para ter uma viso detalhada do processo como um todo. Para isso, o analista pode utilizar a tcnica de cenrios participativos tais como: brainstorming23 (tempestade de idias) e JAD (Joint Application Design Reunies de Projeto) que nada mais so do que reunies entre os usurios / cliente e desenvolvedores e demais envolvidos no projeto. Em uma sesso utilizando a tcnica JAD, participam: lder da sesso; especialistas nos assuntos tcnicos e do negcio do cliente; executivo responsvel / patrocinador; representantes dos usurios; gerente de projeto; observadores passivos e ativos (podem opinar); responsvel por documentar os requisitos levantados nas reunies. So realizados vrias sesses onde sero discutidos com todas as pessoas, ou seus representantes, envolvidas nos processos da organizao. Dessa forma fica mais produtivo o trabalho de levantamento de requisitos e pode-se evitar conflito, falta ou equvoco de informaes.

2.5.2.4 Entrevistas
As entrevistas auxiliam no processo de levantamentos de requisitos. Ao entrevistar os envolvidos, deve-se ter objetividade nas perguntas, tratar as

23

O brainstorming (ou "tempestade de idias") mais que uma tcnica de dinmica de grupo uma atividade desenvolvida para explorar a potencialidade criativa do indivduo, colocando-a a servio de seus objetivos. Quando se necessita de respostas rpidas a questes relativamente simples, o brainstorming uma das tcnicas mais populares e eficazes. Disponvel em: <http://pt.wikipedia.org/wiki/Brainstorming>.

43 informaes da forma mais clara possvel e, coletar de documentos utilizados pelo usurio os quais auxiliaro os analistas no desenvolvimento da soluo. Quando o assunto necessitar de requisitos mais detalhados o ideal entrevistar o funcionrio que trata do respectivo assunto, tomando alguns cuidados ao fazer entrevistas, tais como: Conversar com o responsvel de um determinado setor antes de entrevistar o funcionrio, pois deve-se seguir a hierarquia da organizao; Verificar com o funcionrio entrevistado a sua disponibilidade de horrio e, durante a entrevista, no tomar mais tempo do que o combinado; Sempre verificar se o entrevistador entendeu todas as informaes que o funcionrio tentou passar. Lembre-se que ... a pessoa a especialista no que faz e voc apenas busca informaes. (TONSIG, 2003: 100)

2.5.2.5 Observao in-loco

Aliada a entrevista, a observao in-loco auxilia no levantamento de requisitos durante as atividades no dia-a-dia do cliente por um perodo de alguns dias. Isso permite observar detalhes que no seriam possveis de serem abordados em uma entrevista. A observao in-loco tambm pode ser adotada para esclarecer dvidas sobre algum requisito levantado durante uma entrevista. Em questes que envolvem planejamentos estratgicos, no cabe a observao in-loco como mtodo para levantamento de requisitos, pois nesse caso as aes so planejadas independentes dos processos. Nesse caso o analista deve estar ciente desse fato, pois o software dever executar o que se planeja.

2.5.3 Anlise dos requisitos

A anlise de requisitos, tambm conhecida como especificao de requisitos, a fase onde, de posse dos requisitos levantados anteriormente, tenta-se unir todas as necessidades do cliente na construo de um modelo que ir servir de base para desenvolver o sistema.

44 Nessa fase, ao analisar os requisitos e desenvolver um sistema que atenda as necessidades do cliente, no so analisados os ambientes tecnolgicos onde o sistema ir atuar. Primeiro necessrio saber o que o sistema proposto deve fazer para, ento, definir como esse sistema ir faz-lo. (BEZERRA, 2002: 24) Basicamente dois tipos de modelos sero criados durante o processo de analise: a modelagem de sistema e a modelagem de dados24. Depois de criados os modelos, os mesmos precisam ser validados e verificados. A validao garante que as necessidades e funcionalidades que o cliente necessita esto sendo atendidas, e a verificao garante que os requisitos esto sendo atendidos. A anlise pode ser feita atravs de vrios mtodos de desenvolvimento de software, como por exemplo: estruturado, essencial e orientados a objetos. Uma abordagem mais detalhada sobre anlise orientada a objetos pode ser visto no captulo 3, os demais mtodos no sero abordados nesse trabalho.

2.5.4 Especificao de requisitos

A especificao de requisitos realizada quando a tarefa anlise encontra-se no auge de suas atividades. Nesta etapa, as funes de sistema, levantadas anteriormente, so refinadas e documentadas em detalhes, so especificadas metas e objetivos que o software dever tratar. Tudo ser incorporado ao planejamento do desenvolvimento do software juntamente com as especificaes das funcionalidades para cada necessidade levantada ou apresentada pelo cliente. Tambm sero definidos quais sero os critrios de validao (testes). Os tipos de testes so apresentados no item 2.9. O documento criado acompanha: bibliografia contendo documentos

relacionados ao software, documentos de referncia tcnica, informao sobre fornecedores, e apndice com informaes adicionais. Um eventual prottipo executvel do software e uma verso preliminar do manual do usurio tambm podem acompanhar o documento. O planejamento de desenvolvimento do software entregue para anlise e cincia do cliente. A partir desse ponto, qualquer outro requisito ou mudana no software acarretar em mudana de custo e poder afetar o cronograma.
24

Por este se tratar de um trabalho onde o foco principal a modelagem de sistema orientado a objetos no ser abordado a modelagem de dados.

45

2.6 Projeto do Software

Na etapa de desenvolvimento, os aspectos tecnolgicos, que at ento foram deixados de lado, passam a ter sua verdadeira importncia no projeto. no projeto que define-se como o software atender os requisitos levantados, e ao mesmo tempo, respeitando os limites tecnolgicos. Dependendo do tipo de anlise adotada, estruturada ou orientada a objetos, diferentes ferramentas de trabalho no projeto do software sero utilizadas. Pode-se adotar que teremos basicamente: projeto da base de dados, projeto da arquitetura do sistema, projeto de interface.

2.7 Projeto de Interface Homem-Computador (IHC)

De acordo com Pressman (2002: 393), o projeto de interface do homem com o computador visa criar meios para que o usurio interaja e se comunique com o sistema. O objetivo do projeto identificar objetos e suas aes para a criao de uma tela de sistema seguindo um conjunto de princpios de projeto. Cada tipo diferente de sistema apresenta uma interface prpria. Quando tratase de usurios com deficincias fsicas o tipo de interface necessita ser bem elaborada. Projetos de interfaces baseados em comando de voz j uma realidade no Brasil que auxiliam portadores de deficincia na utilizao do computador 25.

O projeto de interface focaliza trs reas de preocupao: (1) o projeto de interface entre componentes do software, (2) o projeto de interfaces entre o software e outros produtores e consumidores de informao no-humanos (i. e., outras entidades externas) e (3) o projeto de interfaces entre um ser humano (i. e., o usurio) e o computador. (PRESSMAN, 2002: 393).

Um projeto de interface homem-computador precisa atender as necessidades do usurio. Pressman (2002: 394), citando Mandel (1997), relaciona trs regras de
25

Mais informao sobre o programa de interface brasileiro baseado em comando de voz, chamado MOTRIX, encontra-se disponvel em: <http://intervox.nce.ufrj.br/motrix/>. Acessado em: 02/Jul/06.

46 ouro que servem de base formando um conjunto de princpios para um projeto de interface com o usurio. 1. Coloque o usurio no controle; 2. Reduza a carga de memria do usurio; 3. Faa interface consistente. O projeto de interface deve partir das necessidades do usurio e deve causar o menor impacto possvel no seu cotidiano. Interfaces grficas cheias de menus e botes acabam confundindo os usurios criando uma resistncia na utilizao do novo sistema. Utilizando a regra n 1, Pressman (2002: 394), citando Mandel (1997),

explana alguns princpios que colocam os usurios no controle de projeto de interfaces: Defina os modos de interao de uma forma que no force o usurio a aes desnecessrias ou indesejadas. O programa deve fornecer ao usurio a possibilidade de ativar e desativar opes do programa sem esforo. Proporcione interao flexvel. O programa deve permitir que o usurio escolha o melhor meio para interagir com o sistema. Como por exemplo: mouse, teclado, caneta tica ou reconhecimento de voz. Permita que a interao com o usurio possa ser interrompida e desfeita. Deve ser permitido ao usurio interromper uma ao, ou desfaz-la, sem que o usurio perca o trabalho que j foi feito. Simplifique a interao medida que os nveis de competncia progridem e permita que a interao seja personalizada. Quando usurios fazem uma operao repetitiva, sugere-se projetar para os usurios mais avanados um mecanismos para automatizar esse processo (macro). Esconda detalhes tcnicos internos do usurio espordico.26 Deve ficar oculto para o usurio a execuo de comandos internos aplicao, como por exemplo, a digitao de comandos do sistema operacional. Projete a interao direta com objetos que aparecem na tela. O usurio tem maior facilidade de interao com objetos ao executar uma ao, como por exemplo clicar no desenho de uma impressora quando quer imprimir um relatrio.

26

Usurio espordico aquele que tem um nvel de conhecimento razovel do sistema.

47 Na regra n 2, prope no sobrecarregar a memria do usurio fazendo-o lembrar de comandos do sistema, isso o induz ao erro. Sempre que for possvel o programa deve sugerir aes ao usurio fornecendo dicas e assistncia. Pressman (2002: 395), citando Mandel (1997), relaciona a teoria de projeto de interface para reduzir a carga de memria do usurio. Reduza a demanda de memria de curto prazo. No projeto da interface, deve-se tentar no forar a memria do usurio para lembrar de aes e resultados anteriores. Estabelece defaults
27

significativos. Deve ser permitido ao usurio alterar

as configuraes do sistema de acordo com a sua preferncia, mas deve estar disponvel uma opo destinada voltar para configurao padro. Defina atalhos que so intuitivos. Ao definir atalhos no sistema, a seqncia de teclas deve ser sugestiva de acordo com a ao proposta, como por exemplo as teclas <CTRL> + P para imprimir. O leiaute visual da interface deve ser baseado numa metfora do mundo real. A interao entre o usurio e uma interface maior quando esta possuir uma visualizao familiar para o usurio, como por exemplo um formato de formulrio de requisio que o usurio esteja habituado a utilizar. Revele informao de um modo progressivo. A interface deve fornecer informaes, em primeira instancia, de uma forma generalizada e com grande nvel de abstrao. Caso o usurio necessite especificar detalhes dessa informao a interface deve fornecer maiores detalhes de como essa informao pode ser exibida. Na regra n 3, para fazer uma interface consistente implica dizer que:

...(1) toda a informao visual seja organizada de acordo com um padro de projeto que mantido ao longo de todos os mostradores de tela, (2) mecanismos de entrada so restritos a um conjunto limitado que usado consistentemente ao longo de toda a aplicao e (3) mecanismos para navegar de tarefa a tarefa so consistentemente definidos e implementados. (PRESSMAN, 2002: 396)

27

Palavra da lngua inglesa. Refere-se a um valor pr-definido que pode ser atribudo a um parmetro do sistema.

48 Pressman (2002: 396), citando Mandel (1997), esclarece um conjunto de teorias que auxilia a fazer a interface consistente: Permita ao usurio situar a tarefa atual num contexto significativo. Muitas interfaces so construdas com diversas telas com vrios sub-nveis cada. A interface para permitir ao usurio se situar, deve fornecer indicadores, tais como: ttulos nas janelas ou cones grficos, dessa forma o usurio consegue associar uma tarefa a uma localizao especifica. Mantenha consistncia ao longo de uma famlia de aplicaes. Na interface deve ser mantido a forma de interao para a mesma famlia de aplicao. Se modelos interativos anteriores criaram expectativas para o usurio, no faa modificaes, a menos que haja forte razo para isso. As seqncias de interao que forem bem assimiladas pelos usurios, eles esperaro que todos as interfaces adotem o mesmo tipo de interao, como por exemplo o atalho <ALT>+S para salvar se for alterado poder induzir o usurio ao erro. A experincia do usurio com o sistema, o nvel de conhecimento dos usurios e a anlise do ambiente onde o usurio encontram-se sempre devem ser levados em conta na hora de se projetar um modelo de interface. Para projetar uma interface, devem-se analisar os objetos e as aes que o usurio utiliza, isso servir de base para a criao das aes da interface. Pde-se observar que o projeto de uma interface muito complexo e no o objetivo desse trabalho entrar em detalhes referente a interfaces.

2.8 Implementao do Software

Na etapa de implementao, onde o software sai do papel para comear a se tornar um produto real. Todas as partes do projeto sero codificadas atravs de vrias ferramentas de programao. A base de dados, dependendo dos requisitos, provavelmente dever ser implementada em um Sistema Gerenciador de Bando de Dados (SGBD), o projeto da arquitetura definir a linguagem de programao. O projeto de interface pode ser implementado de diversas formas, dependendo de qual maneira sero feitas as entradas e sadas de dados no sistema.

49

2.9 Testes do Software

Uma maneira eficaz de constatar se o software que foi projetado atende os requisitos levantados e a necessidade do cliente executar testes de software ou verificao e validao (V & V) do software. Teste de software um elemento crtico da garantia de qualidade de software e representa a reviso final da especificao, projeto e gerao de cdigo. (PRESSMAN, 2002: 429). Existem diversos tipos de testes, um para cada situao e para cada tipo de software. Abaixo segue uma lista de alguns tipos diferentes de testes que podem ser empregados testar um software: Teste caixa-branca ou caixa de vidro; Teste de caminho bsico; Teste de estrutura de controle; Teste caixa-preta ou comportamental; Teste de ambientes, arquiteturas e aplicaes especializadas: o Teste de GUI (Graphical User Interfaces 28); o Teste de arquitetura cliente / servidor29; o Teste da documentao e dispositivos de ajuda; o Teste de sistemas de tempo real30. No basta ter a ferramenta e no saber como us-la, o mesmo acontece com os testes. Os chamados casos de teste devem ser cuidadosamente preparados de acordo com o sistema a ser testado. A elaborao de um conjunto de diferentes mtodos de teste d-se o nome de estratgias de teste. As estratgias de testes so aplicadas desde o nvel mais baixo (cdigo) at o nvel mais alto. Em cada etapa de nvel de teste so aplicadas diferentes estratgias de teste, como segue:
28

Teste de unidade utiliza:

uma palavra da lngua inglesa que significa Interface Grfica com o Usurio. Refere-se as telas grficas de sistemas baseado em janelas, tais como: Microsoft Windows . 29 Tipo de arquitetura onde o sistema do computador do usurio conecta-se a um servidor de aplicao ou sistema de base de dados. 30 Tipo de sistema onde as interaes entre o sistema e os usurios ocorrem simultaneamente ou em um intervalo muito curto de tempo.

50 o Teste caixa-branca Teste de integridade utiliza: o Teste de integrao descendente o Teste de integrao ascendente o Teste de regresso o Teste fumaa Teste de validao utiliza: o Teste caixa-preta o Teste Alfa (Teste com usurio sob a superviso do desenvolvedor) o Teste Beta (Teste somente com o usurio) Teste de sistema. o Teste de recuperao o Teste de segurana o Teste de estresse o Teste de desempenho Relatrios so os resultados da etapa de testes. De acordo com Pressman (2002: 429), nessa etapa gasto de 30% a 40% do esforo total do projeto. No o objetivo desse trabalho se aprofundar no assunto de testes de software. Maiores detalhes sobre esse assunto podem ser encontrados em Pressman (2002: 429-496, 617-636).

2.10 Implantao do Software

Nessa etapa o software embalado, distribudo e instalado no usurio e se for o caso os dados so importados. Em alguns casos ocorrem migraes de sistemas. Os manuais so escritos, e os usurios so treinados. Dependendo do porte do sistema ele poder demorar meses ou at anos para ser implantado completamente. Alguns problemas podem surgir nessa fase: 1. Houve mudana do ambiente onde inicialmente foi feito o levantamento de requisitos; 2. Os usurios podem ter dificuldades de aceitao do novo sistema;

51 3. O novo sistema e o sistema antigo podem ter que funcionar simultaneamente at que o cliente sinta segurana como o novo sistema. Pode ser que o novo sistema cause algum tipo de conflito com o sistema antigo impossibilitando a sua implantao; 4. Problemas fsicos de instalao, tais como: espao fsico, temperatura controlada. Uma vez colocado o sistema em produo, problemas no detectados durante os testes podem aparecer devido alguma falha durante o levantamento de requisitos ou no decorrer do processo de desenvolvimento. Essa ser uma fase de adaptao para os usurios at que eles se acostumem com o novo sistema. Erros de operao podem ocorrer.

2.11 Evoluo do Software

A evoluo do software a fase onde corrige-se os erros do software encontrados aps a sua implantao e tambm faz-se o aperfeioamento implementando novos requisitos e funcionalidades para o sistema. Segue abaixo algumas observaes sobre as evolues de sistemas:

1. As mudanas propostas precisam ser analisadas muito cuidadosamente, tanto sob uma perspectiva de negcios como de acordo com os aspectos tcnicos.(...) 2. Como os subsistemas nunca so inteiramente independentes, as mudanas em um subsistema podem afetar adversamente o desempenho e o comportamento de outros subsistemas.(...) 3. As razes das decises de projeto originais muitas vezes no ficam registradas. Os responsveis pela evoluo de sistemas precisam entender por que foram tomadas determinadas decises de projeto. 4. medida que os sistemas envelhecem, sua estrutura se torna tipicamente corrompida por mudanas, de modo que aumentam os custos referentes a novas mudanas. (SOMMERVILLE, 2003: 30).

52

Captulo 3. Anlise Orientada a Objetos com UML

Antes de fazer qualquer citao sobre a anlise orientada a objeto, vamos abordar os conceitos de orientao a objetos.

3.1 Conceitos de Orientao a Objeto

Na anlise orientada a objetos as funcionalidades do sistema so vistas na forma de objetos31, onde cada objeto tem seus prprios mtodos32 compostos por rotinas independentes que se relacionam com outros objetos.

3.1.1 - Objetos
Melo (2006: 12) define que, na modelagem de sistema orientado a objetos, um objeto qualquer coisa existente no mundo real, seja material ou conceitual. Por exemplo: carro, bola, bicicleta, caneta, livro, escola, professor, aluno, disciplina. Pressman (2002: 534) explica que cada um desses objetos so membros de uma classe mais ampla de objeto. Por exemplo, o objeto carro pode ser um membro da classe (tambm chamado de instncia) automvel que tambm outro objeto. Utilizando o conceito de objeto fica mais fcil fazer a modelagem de sistemas, e tambm permite que os usurios e clientes compreendam e participem da validao dos diagramas ativamente e vejam como o sistema est sendo desenvolvido evitando dvidas nos requisitos. Cada objeto possui caractersticas prprias denominadas atributo33. Seguindo o exemplo do automvel, seriam exemplos de seus atributos: quantidade de passageiros, cor, modelo, ano, chassi, placa, capacidade de combustvel, tipo de combustvel, motor, preo.

31

Na anlise orientada a objetos, os objetos so representados por classes. Fazendo uma analogia com o processo de fritar um ovo, dependendo da abstrao, podemos ter como objetos os substantivos: ovo, fogo e a frigideira. 32 Os mtodos, tambm chamado de operao, definem o comportamento do objeto (classe). So as rotinas que determinam a ao do objeto. Ainda com a analogia de fritar um ovo podemos ter, por exemplo: na classe o ovo pode ter o mtodo quebrar o ovo, o fogo pode ter o mtodo ajustar o nvel do fogo, e a frigideira pode ter o mtodo verificar a temperatura do leo. 33 Os atributos definem um objeto no contexto que est sendo analisado. Por exemplo, os atributos do objeto ovo podem ser: tipo, marca, tamanho.

53 Os objetos, como o automvel, possuem comportamentos tais como: acelerar, brecar, abrir vidro, acender farol, buzinar, abrir porta, ligar motor. implementao desses comportamentos d-se o nome de operaes, tambm chamados de mtodos.

3.1.2 - Classes
Uma classe a representao de um conjunto de objetos que compartilham a mesma estrutura de atributos, operaes e relacionamentos dentro de um mesmo contexto... (MELLO, 2006: 17). Segundo Pressman (2002: 534) a comunicao de uma classe, por exemplo, automvel, com outra classe, por exemplo, motorista, faz-se atravs de uma mensagem. Na modelagem de sistemas orientada a objetos, se uma classe de objeto necessita saber algum dado (atributo) de outra classe enviado uma mensagem de uma classe para outra que ir executar um mtodo (operao) e obter o dado desejado. Melo (2006: 18) explica que num sistema orientado a objetos trabalhamos com os objetos, chamados de instncias, os quais so representados a partir de uma classe. Os dados so carregados nas instncias criadas. Na figura n 9 exemplificado o conceito de instncia de objeto.
Objeto Joo Nome: Joo Souza Sexo: Masculino Data de Nascimento: 01/03/0960 Estado Civil: Casado Atributos Figura 9: Objeto e classe. (MELO, 2004: 18) do tipo Classe Pessoa Nome Sexo Data de Nascimento Estado Civil Atributos

No exemplo acima, a partir da classe pessoa foi criado o objeto Joo, logo o objeto Joo do tipo Pessoa. Quem recebeu os dados foi o objeto Joo. Para entender melhor, pode-se fazer uma analogia com uma fotocpia de um formulrio onde a partir de um original (classe) pode-se criar vrias cpias

54 (instancias de objetos), os campos do formulrio (atributos) a serem preenchidos (dados) ser o da cpia e no o original.

Uma classe pode ter qualquer nmero de atributos ou mesmo nenhum atributo. Da mesma forma, pode ter qualquer nmero de operaes ou mesmo nenhuma operao. (MELLO, 2006: 18). Podemos citar alguns tipos de classes:

Classe Funcionrio

Objetos Funcionrio Ana Cristina Funcionrio Gustavo

Empresa

Empresa Casa de Festas ABC Empresa Softwares Ltda.

Veculo

Veculo Santana Veculo Escort

Tabela 2: Classes e instncias. (MELO, 2006: 18)

Segundo Pressman (2002: 536), por definio, todos os objetos instanciados a partir de uma classe herdam seus atributos e mtodos. D-se o nome de superclasse (ou classe me) classe principal, e d-se o nome de subclasse (ou classe filha) a classe criada (instanciada) a partir da superclasse. Maiores detalhes sobre herana sero vistos no item 3.1.6. Para se identificar as classes e objetos em um determinado contexto, deve-se relacionar todos os substantivos que tem relao com o caso em questo. Segundo Pressman (2002: 543), tambm podem ser tipos de objetos: Entidades externas: outros sistemas, dispositivos ou pessoas; Coisas: relatrios, cartas que faam parte do problema; Ocorrncias: eventos que ocorram dentro do contexto do problema; Papis: pessoas que exercem funes de gerente, vendedor; Unidades Organizacionais: diviso, grupo da organizao; Lugares: que estabelecem contexto do problema; Estruturas: sensores, computadores.

55

3.1.3 Mtodos, operaes, servios

Mtodos definem o comportamento do objeto (classe) e podem modificar de algum modo os atributos do objeto. So as rotinas que determinam a ao do objeto. Segundo Pressman (2002: 538), os mtodos tambm pode ser chamados de operaes ou servios. Por exemplo, na classe Evento temos os atributos nome, horarioInicio, duracao, dataRealizacao e descricao, quando alguma outra classe quiser cadastrar dados para a realizao de um evento ser utilizado um mtodo cadastrarEvento, previamente criado nessa classe. Para acessar esse mtodo, a classe que requisita essa informao envia uma mensagem34 para a classe veculo. nome da classe
Evento nome horarioInicio duracao dataRealizacao descricao cadastrarEvento() remarcarEvento()

atributos

operaes

Classe
Figura 10:Representao de classe. (MELO, 2004: 101)

3.1.4 - Mensagens
As mensagens so o meio pelo qual os objetos interagem (PRESSMAN, 2002: 538). Ao modelar o sistema, ou seja, criando associaes entre as classes estabelecendo-se uma ligao entre elas. atravs dessa associao que h a troca de mensagens contendo: o nome da classe receptora, qual o tipo de operao ser realizado, e quais os parmetros.

34

Mensagem o meio pelo qual os objetos se comunicam uns com os outros.

56

3.1.5 - Encapsulamento
Encapsulamento o conceito que faz referncia ocultao ou empacotamento de dados e procedimentos dentro do objeto. (TONSIG, 2003: 169)

Mtodo A Mtodo H

Mtodo B

Mtodo C

Atributos do Objeto
Mtodo G Mtodo F Mtodo E Mtodo D

Figura 11: Encapsulamento (TONSIG, 2003: 169)

Melo (2004: 19) explica que a finalidade do encapsulamento proteger os atributos e as operaes da classe. Com o auxlio de uma classe de interface35 possvel que outras classes do sistema acessem as operaes da classe encapsulada, pois a interface serve de intermediaria na troca de mensagens. Em uma classe encapsulada os atributos e operaes ficam protegidos impedindo que demais classes tenham acesso a eles. Sendo assim nenhuma classe do sistema poder enviar mensagens a uma classe encapsulada diretamente. Somente a classe de interface poder ter acesso a essas operaes protegidas, ou seja, a classe de interface recebe a mensagem e a encaminha a classe encapsulada, e se for o caso, a classe encapsulada devolve o resultado para a classe de interface e esta devolve ao destinatrio. Segue abaixo alguns benefcios importantes do encapsulamento:
Os detalhes internos de implementao dos dados e procedimentos so ocultados do mundo exterior (..). As estruturas de dados e as operaes que as manipulam so juntadas numa nica entidade denominada a classe.(...)
35

A classe de interface oca, ela no contm atributos e nem operaes prprias. Serve apenas de intermediaria. explicada no tpico 3.4.2.6.

57
As interfaces entre objetos encapsulados so simplificadas. Um objeto que envia uma mensagem no precisa estar preocupado com os detalhes de estruturas internas de dados.(...) PRESSMAN (2002: 540).

3.1.6 - Herana
A herana, como o prprio nome sugere, tem como caracterstica permitir que as classes herdeiras, chamadas de classe-filha ou subclasse, recebam os mesmos atributos e mtodos da classe-me ou superclasse. Quando falamos em herana, temos dois conceitos envolvidos: a

generalizao e especializao. A generalizao quando separamos os atributos mais genricos da classe filha para criar a classe me, por exemplo, seria como passar o atributo nome, da classe funcionrio para a classe pessoa. A especializao ao contrrio, quando separamos os atributos mais especficos da classe me para criar a classe filha, por exemplo, seria como passar o atributo matrcula, da classe pessoa para a classe aluno. Um tipo especial de herana, chamada herana mltipla, quando uma classe filha (subclasse) possui duas ou mais classes me (superclasse) e herdam os atributos e mtodos de todas as superclasses. Nesse tipo de herana, a classe filha tambm conhecida como classe de juno. CarroAnfbio CarroAnfbio

CarroAnfbio
Figura 12: Herana mltipla (BEZERRA, 2002: 195)

58

Figura 13: Herana (MELO, 2004: 21)

3.1.7 Polimorfismo
O principio do polimorfismo quando ...um objeto pode enviar a mesma mensagem para objetos semelhantes, mas que implementam a sua interface de formas diferentes. (BEZERRA, 2002: 10). De acordo com Melo (2004: 22), uma operao polimrfica pode ser implementada nas classes filhas de forma diferente da classe me. Podemos tomar como exemplo uma classe me chamada funcionrio que possui uma operao chamada CalcularSalrio, essa classe possui uma classe filha chamada professor. A classe professor tambm possui uma operao chamada CalcularSalrio que calcula o salrio em horas enquanto a operao CalcularSalrio da classe me calcula o salrio fixo. Esse tipo de operao pode ser feito em diversos pontos da hierarquia desde que a assinatura36 no se altere.
36

So os parmetros que so colocados entre os parnteses da operao. So quantidade e tipos de argumentos e o tipo do valor resultante.

59

CLASSE FUNCIONRIO Operao CalculaSalrio(mesReferencia: integer)

CLASSE PROFESSOR Operao CalculaSalrio(mesReferencia: integer)

Figura 14: Polimorfismo (MELO, 2004: 22)

Segundo Presmann (2002: 542), em uma operao onde a assinatura se mantm inalterada chamada de polimorfismo de incluso. Quando a assinatura modificada temos o conceito de polimorfismo de sobrecarga.

3.2 Anlise Orientada a Objetos

Antes do surgimento da UML, Booch utilizava o mtodo chamado de anlise orientada a objetos (Object-Oriented Analysis, OOA), por sua vez Rumbaugh utilizava a tcnica de modelagem de objetos (Object Modeling Technique, OMT) e Jacobson usava a engenharia de software orientada a objetos (Object-Oriented Software Engineering, OOSE). Durante a ltima dcada, Grady Booch, James Rumbaugh e Ivar Jacobson colaboraram para combinar as melhores caractersticas de seus mtodos individuais de anlise e projeto orientados a objeto num mtodo unificado. (PRESSMAN, 2002: 563). A partir desse mtodo surgiu a Linguagem de Modelagem Unificada (Unified Modeling Language, UML). Pressman (2002: 559) explica que, a anlise orientada a objetos se inicia com as descries de casos-de-uso37, onde cada um dos casos-de-uso poder ser transformado em uma ou mais classes no decorrer da anlise orientada a objetos. Durante a anlise orientada a objetos so definidos as classes (objetos) e a forma como elas interagem entre si e com o mundo externo, suas funes internas (atributos e operaes), seus relacionamentos e a comunicao entre elas (mensagens).
37

uma descrio baseada em cenrios mostrando como atores, que podem ser pessoas, mquinas e sistemas externos, interagem com o sistema que est sendo construdo.

60 Segundo Pressman (2002: 563), a UML permite que o projetista de software modele o sistema com base em um conjunto de regras e smbolos. A representao de um sistema em UML pode ser visto em 5 tipos de vises: Viso do modelo do usurio: Representa a viso do sistema do ponto de vista do usurio; Viso do modelo estrutural: Viso dos dados e funcionalidades dentro do sistema, os quais so modelados e se transformam em classes, objetos e relacionamentos; Viso do modelo comportamental: Descreve os aspectos

comportamentais do sistema, e mostra como ocorre a interao com os modelos do usurio e estrutural; Viso do modelo de implementao: Descreve como devem ocorrer as construes dos aspectos estrutural e comportamental; Viso do modelo do ambiente: Descreve o aspecto estrutural e comportamental do ambiente onde o sistema ser implementado. Pode-se dizer que a anlise vai se transformando em projeto medida que o desenvolvimento evolui. (BEZERRA, 2002: 139). O projeto orientado a objetos (object-oriented design, OOD) transforma o modelo de anlise criado (...) num modelo de projeto que serve como documento para a construo de software (PRESSMAN, 2002: 589). Bezerra (2002: 139) afirma que, as atividades executadas na fase de projeto so: 1. Detalhamento dos aspectos dinmicos do sistema: So construdos os modelos de interaes, modelos de estados e modelos de atividades. 2. Refinamento dos aspectos estticos e estruturais do sistema: So construdos os modelos de classes de domnio, de fronteira, de controle e de entidade. 3. Definio de outros aspectos da soluo: analisado como o sistema pode ser decomposto em diversos subsistemas, onde cada subsistema ser composto por vrias classes.

61

3.3 Linguagem de Modelagem Unificada (Unified Modeling Language, UML)

Conforme foi falado anteriormente Grady Booch, James Rumbaugh e Ivar Jacobson foram os principais precursores da UML. A UML surgiu a partir da unio de vrios modelos com o objetivo de criar uma linguagem nica para a modelagem de sistemas orientados a objetos. A primeira vez que a UML foi reconhecida e aprovada pelo OMG38 foi em 1997. A UML no um mtodo, uma linguagem de modelagem que utiliza um visual grfico para construo e documentao de artefatos39 para sistemas orientados a objetos. composta por diversos componentes grficos e diagramas, e independente de linguagem de programao e processos de desenvolvimentos. O inicio da unificao foi em outubro de 1994 quando James Rumbaugh deixou a General Electric e juntou-se a Grady Booch da Rational Software com o objetivo de unir seus mtodos. Em 1995 Ivar Jacobson tambm se juntou ao grupo e em 1996 e eles passaram a ser conhecidos como os trs amigos. Desde 1995 at 2004 a UML teve muitas verses e publicaes (verso 0.8 em 1995, verso 0.9 e 0.91 em 1996, verso 1.0 e 1.1 em 1997, verso 1.2 e 1.3 em 1998, verso 1.4 em 2001, verso 1.5 em 2003 e finalmente a 2.0 em 2004). A partir do ano de 1997 novos integrantes se juntaram ao grupo que j tinha ganhado a confiana das organizaes. As modelagens com UML so feitas com base em relacionamentos, diagramas e regras de formatao. Neste tpico vamos dar nfase verso 1.4 da UML, no veremos todos os elementos disponveis40 da UML, somente alguns conceitos e exemplos para o perfeito entendimento do estudo de caso apresentado no captulo 4.

3.4 - Diagramas

38

Abreviao da sigla Object Management Group. O OMG um consrcio internacional que define e valida padres na rea de orientao a objetos (http://www.omg.org). 39 Artefato qualquer coisa que pode ser utilizado durante a construo de um sistema. Ex: requisitos, arquitetura, testes, cdigo-fonte, relatrios, croqui, planos de projetos, etc. 40 Mais informaes sobre UML podem ser encontradas na Internet (http://www.uml.org).

62 Segundo Booch (et al.: 2000: 89), o diagrama um meio e representao grfica feita atravs de blocos, smbolos e vrios elementos interligados entre si que so utilizados para auxiliar o desenvolvimento do sistema fazendo com que todos consigam ter a mesma perspectiva. O UML possui diversos diagramas que permitem abordar diferentes aspectos de maneira independentes que servem para validar os requisitos levantados junto ao usurio / cliente e tambm para documentar o projeto que servir de guia para a equipe de desenvolvimento evitando assim problemas de interpretao.

3.4.1 Diagrama de Caso de Uso (Use Case)

Melo (2004: 54) explica que, um caso de uso uma maneira grfica de relatar o funcionamento de um sistema atravs de uma seqncia de aes que mostra um cenrio principal e um cenrio alternativo (caso ocorra na seqncia principal algum imprevisto). Podemos exemplificar a descrio acima com o caso de uso: Emitir saldo em um terminal de caixa eletrnico. Em um cenrio principal, tambm chamado de cenrio perfeito, teramos:
Cenrio Principal 1. O sistema realiza a leitura do carto magntico do correntista. 2. O sistema solicita a digitao da senha. O correntista digita a senha. 3. O sistema valida a senha. 4. O correntista seleciona a opo de saldo. 5. O sistema questiona o tipo de saldo: conta corrente, poupana, aplicaes. 6. O sistema processa e mostra o saldo solicitado pelo cliente. etc.
Figura 15: Cenrio Principal (MELO, 2004: 55)

Por mais bem projetado que seja o sistema impossvel que seja tudo perfeito, cabe ao analista verificar as possibilidades de algo sair errado e tratar esse erro. De posse da relao das probabilidades de algo sair errado criam-se cenrios alternativos. Em um cenrio alternativo usa-se o termo encerar o caso de uso para indicar que a seqncia de aes foi interrompida por um determinado acontecimento.

63 No exemplo da figura 16, Include uma indicao que ser incorporado a esse caso de uso um outro caso de uso atravs de um relacionamento de incluso. Ser visto em maiores detalhes no item 3.4.1.4.
Alternativa: Problema na leitura do carto magntico 1a) Se o sistema no conseguir ler os dados do carto magntico, tentar nova leitura por, no mximo, mais duas vezes. Caso persista o problema, encerrar o caso de uso. Alternativa: Senha Invlida 3a) Se a senha digitada pelo correntista no for igual senha cadastrada no sistema, informar ao mesmo e solicitar nova digitao. Esse processo pode ser repetido por no mximo trs tentativas (incluindo a primeira). Aps a terceira tentativa, a conta do usurio dever ser bloqueada e o caso de uso encerrado. Include Bloquear Conta. Alternativa: Conta Inexistente 6a) Se o correntista no possuir o tipo de conta selecionada, informar ao mesmo e encerrar o caso de uso.
Figura 16: Cenrios alternativos (MELO, 2004: 56)

Faz parte da documentao de caso de uso a descrio das regras do negcio. Regras do negcio so polticas, condies ou restries que devem ser consideradas na execuo dos processos existentes em uma organizao. (GOTTESDIENER, 1999 In: BEZERRA, 2002: 70). Segundo BEZERRA (2002:71), as regras de negcios podem ser

representadas atravs de descrio textual onde cada regra pode conter: Uma identificao, (por exemplo: RN01) dessa forma podem ser referenciadas nas descries de casos de uso; Um nome que seja possvel fazer sua distino; Uma fonte, quem forneceu essa regra de negcio; Um histrico, contendo uma data de referncia ou alguma informao adicional. As regras de negcio so obtidas na fase de levantamentos de requisitos (visto no item 2.5.2), tem influncia na lgica de programao e podem estar relacionadas a um ou vrios casos de uso. Bezerra (2002: 84) sugere um modelo de descrio de caso de uso um pouco diferente do anterior que pode ser visto no anexo A (Modelo de Descrio de Caso de Uso).

64 No diagrama de caso de uso todos os meios externos (ex.: sistemas externos, usurio ou grupo de usurios) que interagem com o sistema so chamados de atores. Na modelagem de caso de uso os atores ficam separados dos casos de uso por uma fronteira do sistema (system boundary), os atores do lado de fora e os casos de uso do lado no seu interior.

Figura 17: Representao de fronteira do sistema (MELO, 2004: 68)

3.4.1.1 Associao (Association)

A associao a forma que um ator interage com um ou mais casos de uso do sistema. Essa interao feita atravs do envio e recebimento de mensagens. A associao s pode ser utilizada entre atores e casos de uso.

Figura 18: Representao de uma associao (MELO, 2004: 65)

3.4.1.2 Generalizao (Generalization)

A generalizao utiliza o mesmo conceito proveniente da herana em orientao a objetos, ou seja, casos de uso podem ser genricos ou especficos. Por exemplo: Podemos ter um caso de uso Cadastrar Funcionrio onde relacionados a

65 este temos Cadastrar Professor. O caso de uso Cadastrar Funcionrio uma generalizao, Cadastrar Professor so especializaes, ou tipo de funcionrio. O mesmo acontece com atores, nesse exemplo o ator Gerente tem suas responsabilidades e tambm herda as responsabilidades do ator Vendedor. Generalizaes s ocorrem entre casos de uso ou entre atores.

Figura 19: Representao de um relacionamento de Generalizao41 (MELO, 2004: 67)

3.4.1.3 Extenso (Extend)

Melo (2004: 61) explica que um ...relacionamento de extenso entre casos de uso indica que um deles ter seu procedimento acrescido, em um ponto de extenso, de outro caso de uso, identificado como base.

Figura 20: Representao de um relacionamento Extend (MELO, 2004: 67)

41

Considere que o Gerente tambm um vendedor e possui as mesmas responsabilidades e algumas a mais.

66 A extenso usada para relacionar casos de uso que possuem aes que tem ocorrncias eventuais, opcionais ou excees, por exemplo, os cenrios alternativos. Pode-se observar que a palavra extend est entre dois smbolos, guillemets (), a essa nomenclatura d-se o nome de esteretipo. Extenso somente utilizada entre casos de uso. Um caso de uso pode ter vrios pontos de extenso.

3.4.1.4 Incluso (Include)

Incluso, como o prprio nome diz, inclui as aes de um caso de uso em outro. Tem como vantagem utilizar as mesmas aes do caso de uso includo em vrios outros casos de uso evitando a cpia de vrias aes repetidas. Normalmente utilizada a incluso quando existe um pr-requisito para que uma ao acontea. O exemplo abaixo mostra a incluso do caso de uso Validar Matricula que includo ao matricular o aluno (caso de uso Matricular Aluno) ou ao emitir o histrico escolar (caso de uso Emitir Histrico Escolar). Incluso somente utilizada entre casos de uso. Um caso de uso pode ter vrios pontos de incluso.

Figura 21: Representao de um relacionamento Include (MELO, 2004: 66)

3.4.2 Diagrama de classes

67 A funo do diagrama de classes criar relacionamentos entre as classes fazendo com que elas troquem mensagens para que suas operaes possam ser acessadas e assim obter a funcionalidade do sistema. Como foi visto na figura 10, uma classe tem a representao grfica de um retngulo dividido em trs compartimentos. Melo (2004: 101) explica que essa ...diviso corresponde notao bsica dos diagramas de classe. Na parte superior fica o nome da classe, centralizado e em negrito. As iniciais do nome deve ser em maisculo, se for nome composto no pode haver espao. Na parte central a lista de atributos deve ser escrita com formatao normal alinhado esquerda. Os nomes dos atributos iniciam-se com letra minscula, e se for nome composto, o segundo nome deve ser escrito em letra maiscula sem espaamento. Na parte inferior a lista de operaes escritas da mesma forma que os atributos. Mas antes de comearmos a criar diagramas, alguns conceitos precisam ser vistos.

3.4.2.1 Visibilidade
Em uma classe temos atributos e operaes que podem ter seu parmetro de visualizao de diversas formas. A visualizao permite que atributos e operaes sejam visualizados totalmente, parcialmente por outras classes ou no visualizados, nesse ltimo caso somente a prpria classe poder visualiz-los. Os parmetros de visualizao so os seguintes: public (publico) ou + protected (protegido) ou # private (privado) ou package (pacote) ou ~ Public (+): visualizado por todos os elementos do sistema, com a ressalva de pacotes externos42. Pacotes externos podero obter acesso aos valores pblicos

42

So utilizados em sistemas de mdio e grande porte. Em um sistema tm-se subsistemas, cada subsistema composto por vrios elementos do modelo UML que so agrupados, a esse agrupamento d-se o nome de pacote.

68 dos atributos e das operaes da classe se o mesmo puder visualizar o pacote onde est a referida classe. Protected (#): visualizado pela prpria classe e pelas classes descendentes (herana). Private (-): visualizado apenas dentro da prpria classe. Outros elementos associados a essa no tero acesso. Package (~): pode ser visualizado por todos os elementos dentro do pacote onde encontra-se a referida classe.

3.4.2.2 Multiplicidade
A multiplicidade ...a quantidade de instncias possveis em um relacionamento. (MELO, 2004: 96). Vamos tomar como exemplo a classe EmissoraTv e a classe Comercial: Uma emissora de TV transmite nenhum ou vrios comerciais, e um comercial pode ser veiculado por nenhuma ou at oito emissoras. A figura 22 possui a representao grfica dessa multiplicidade. Nota-se que existe um limite-inferior e limite-superior.

EmissoraTV

0..8

0..*

Comercial

Figura 22: Multiplicidade numa associao. (MELO, 2004: 111)

Exemplos de multiplicidades mais utilizadas: 0..1 = nenhum ou um; 1 ou 1..1 = apenas um; * ou 0..* = nenhum ou vrios, ou seja, qualquer valor. 1..* = um ou vrios.

3.4.2.3 Atributos e Operaes

69 Ao definir os atributos informa-se seu nome, tipo, valor inicial, visibilidade. Alguns parmetros so opcionais, obrigatoriamente precisam ser informados o nome e tipo. Visibilidade: +, -, # ou ~. Tipo: inteiro (integer), real, texto (string), entre outros. Multiplicidade: se for exatamente 1 poder ser omitida. Valor-default: valor inicial do atributo no momento que o objeto instanciado. Segue alguns exemplos abaixo: private Senha: string

(visibilidade privado, nome do atributo Senha do tipo string texto). + tamanho: integer

(visibilidade publica, nome do atributo tamanho do tipo integer inteiro). angulos: integer [3]

(a classe tem de um a trs angulos) nota1: real = 0

(define o tipo de atributo e atribui o valor inicial) Existe um atributo chamado: atributo derivado. Atributo derivado um atributo cujo valor calculado com base em outros atributos da mesma classe. A identificao visual desse tipo de atributo feito com uma barra ( / ) frente do nome do atributo. As operaes tambm possuem visibilidades similares dos atributos. Operaes podem passar e / ou retornar algum tipo valor, por isso tambm precisase saber seu tipo. Segue abaixo exemplos de sintaxe: private obterSenha: string

(visibilidade privado, nome da operao Senha, recebe valor do tipo string texto). + modificarTamanho (iTamanho: integer)

(visibilidade publica, nome da operao iTamanho envia valor do tipo integer inteiro). + modificarTamanho (iTamanho: integer)

Na operao existe um conceito muito importante, refere-se assinatura da operao. A assinatura da operao como se chamam os parmetros que so

70 passados entre os parnteses de uma operao. No exemplo abaixo, percentual: real a assinatura da operao. reajustarSalario(percentual: real)

3.4.2.4 Relacionamentos
atravs do relacionamento que as classes estabelecem a comunicao, trocam mensagens e colaboram umas com as outras. Os relacionamentos, que veremos a seguir, podem ser de associao, generalizao, dependncia, agregao e composio.

3.4.2.4.1 Associao
A associao pode relacionar duas classes (associao binria), trs classes (associao ternria), mais de trs classes ou apenas uma classe se relacionando com ela mesma (auto-relacionamento). A associao representada por uma linha contnua ligando as classes, o nome da associao pode ser mostrado para indicar a ao. Segundo Melo (2004: 109), o auto-relacionamento tambm uma associao binria.

Aluno

Disciplina

Funcionrio

Figura 23: Representao de associao (MELO, 2004: 109).

Em uma associao ternria, um losango usado para unir as conexes. Melo (2004: 109) explica, que na figura 24 um Jogador joga por uma equipe em uma determinada Temporada (ano) e uma Equipe possui Jogadores diferentes em cada Temporada.

71

Equipe

Jogador

Temporada
Figura 24: Representao de uma associao ternria (MELO, 2004: 109).

3.4.2.4.2 Generalizao
O relacionamento de generalizao mostrado graficamente como uma linha contnua com uma flecha vazada apontando para a classe-me, ou seja, a classe mais genrica. O outro lado da linha liga a classe filha, ou seja, a classe mais especfica. De acordo com Booch (et al.: 2000: 63) os relacionamentos de generalizao tambm so chamados de relacionamentos um tipo de um item. Conforme explanado sobre herana no item 3.1.6, classes mais especficas (classe filha) herdam as propriedades da classe genrica (classe me). A generalizao pode ser representada de duas formas. As duas formas esto sendo apresentadas na figura 25.
Pessoa

Cliente

Fornecedor

Funcionrio

Primeira forma de representao

Pessoa

Cliente

Fornecedor

Funcionrio

Segunda forma de representao

Figura 25: Representao de generalizao (MELO, 2004: 113)

72 A herana permite que as classes filhas herdem tanto os atributos quanto as operaes da classe me. Observemos o exemplo a seguir:

Funcionrio - salarioBase: Moeda + obterPagamento(): Moeda + definirSalarioBase(in umSalario: Moeda) + obterSalarioBase(): Moeda

Vendedor - comissao: Porcentagem + obterPagamento(): Moeda Figura 26: Definio de operaes Polimrficas. (BEZERRA, 2002: 201)

A classe Funcionrio possui uma operao obterPagamento a partir do salario base, a classe Vendedor tem seu salrio calculado de forma diferente da operao herdada ento essa operao redefinida na classe Vendedor, ou seja, seu cdigo re-escrito. D-se o nome de Polimorfismo a essa operao.

3.4.2.4.3 Dependncia
Segundo Booch (2000: 451), dependncia um relacionamento entre dois elementos, em que a alterao de um elemento (o independente) poder afetar o outro elemento (o dependente). A indicao da dependncia feita com uma linha tracejada com uma seta aberta apontando para o item independente, conforme a figura abaixo.

AgendaConsulta

HorarioMedico

Figura 27: Dependncia (MELO, 2004: 116)

73 No exemplo anterior a classe AgendaConsulta depende de HorarioMedico. Qualquer alterao em HorarioMedico afetar a classe AgendaConsulta. Na assinatura de uma operao, uma classe aparece como parmetro. (MELO, 2004: 116). Na figura 28, pode-se observar que na classe abaixo a operao playOn aparece com o nome da classe dependente como parmetro.
FilmClip name playOn(c: Channel) start() stop() reset() Channel

Figura 28: Assinatura da Dependncia (BOOCH, 2000: 63)

3.4.2.4.4 Agregao
uma associao somente entre duas classes independentes onde sua existncia no depende uma da outra. utilizada quando deseja-se fazer um relacionamento todo/parte, ou seja, quando um objeto do todo formado por objeto(s) da(s) parte(s). Esse relacionamento do tipo tem-um, e representado por uma linha contnua com um pequeno losango em uma das extremidades. O losango aponta para a agregao (todo), enquanto a outra extremidade aponta para a classe agregada (parte). No exemplo da figura 29 uma Empresa tem muitos Departamentos.

Empresa
todo 1 agregao parte *

Departamento
Figura 29: Agregao (BOOCH, 2000: 66)

74

3.4.2.4.5 Composio
A composio uma variao da agregao, o relacionamento do tipo composto de algum elemento da mesma forma que na agregao o todo e a parte. A diferena da composio que a classe parte no pode fazer parte de nenhuma outra composio. Outra diferena que a classe composta (todo) responsvel por criar e destruir43 sua(s) parte(s). Caso a classe composta for destruda suas partes tambm sero. A representao do relacionamento de composio feita com uma linha contnua e um losango preenchido, sendo que o losango fica posicionado na classe composta e a outra extremidade da linha nas partes. No exemplo da figura 30, diz-se que a Janela composta de Moldura.

Janela
todo 1 composio parte *

Moldura
Figura 30: Composio (BOOCH, 2000: 148)

3.4.2.4.6 Realizao
Realizao ... um relacionamento entre uma especificao e sua

implementao. (MELO, 2004: 42). Segundo Booch (2000: 150), a realizao na maioria das vezes utilizada para especificar um relacionamento entre uma classe de interface ou componente que fornece uma operao ou servio para a interface.

43

Na programao orientada a objetos, criam-se objetos a partir de uma classe e os objetos criados podem ser destrudos aps sua utilizao.

75 A realizao representada por uma linha tracejada com uma seta fechada e vazia. Poderemos ver uma aplicao do relacionamento de realizao, na figura 33 no item 3.4.2.6, onde falaremos de classes de Interface.

3.4.2.5 Classe de associao

Em uma associao entre duas classes, a prpria associao poder ter propriedades (BOOCH, 2000: 148). A classe de associao surge na modelagem quando existe uma associao de muitos para muitos, por exemplo, conforme a figura 31, uma Pessoa pode trabalhar em muitas Empresas, por sua vez, uma Empresa podem ter muitos empregados (Pessoas). Nesse caso a associao pode ter propriedades como salario e dataContratacao, d-se ento a origem a classe associativa Emprego. A classe associativa representada por uma linha tracejada ligado linha contnua da associao, e a outra extremidade ligada nova classe - classe associativa.

Emprego salario dataContratacao

Pessoa nome telefone endereco

* empregado

* empregador

Empresa razaoSocial endereco

Figura 31: Classe Associativa (BEZERRA, 2002: 105)

Bezerra (2002: 106) explica que, uma classe associativa pode ser modificada substituindo o elemento hbrido por uma classe ordinria, conforme a figura 32.

76

Pessoa nome telefone endereco

Emprego

Empresa

salario dataContratacao

razaoSocial endereco

Figura 32: Classe Associativa (BEZERRA, 2002: 106)

Podemos notar que a multiplicidade que no diagrama da figura 31 era muitos para muitos. Com a substituio do elemento hbrido, a classe Emprego passou a fazer parte da associao e a multiplicidade passou a ser um para muitos e muitos para um respectivamente. Essa modificao no implica em perda ou alterao da informao.

3.4.2.6 Classe de Interface

Uma interface uma coleo de operaes utilizadas para especificar um servio de uma classe ou de um componente. (BOOCH, 2000: 154). De acordo com Booch (2000: 158) a interface no possui atributos nem implementam operaes, uma classe vazia. As operaes que aparecem listadas na classe da interface, mostrada na figura 33, esto implementadas na classe Loja. Quando outra classe solicita uma operao interface, est repassa a operao para a classe na qual est servindo de interface, ao retornar uma resposta segue o caminho inverso. A representao da interface pode ser feita como uma classe colocando o esteretipo interface acima do nome da classe, nesse caso utiliza-se o relacionamento de Realizao para se comunicar com outra classe e coloca-se as operaes da classe. A interface tambm pode ser representada na forma de um circulo vazio com o nome da interface colocado logo abaixo do mesmo, mas as operaes no aparecero e sua ligao feita atravs do relacionamento de realizao representado por uma linha contnua sem seta.

77
Loja idLoja: integer vendedores: List criar() busca(idLoja) obterTotalVendas(vendedor) lanarVendas(vendedor, vendas) realizao interface Loja

obterTotalVendas(vendedor) lanarVendas(vendedor, vendas)

Figura 33: Interface usando uma classe com esteretipo (MELO, 2004: 123)

Loja idLoja: integer vendedores: List criar() busca(idLoja) obterTotalVendas(vendedor) lanarVendas(vendedor, vendas) realizao ILoja

Figura 34: Interface usando o circulo (MELO, 2004: 123)

3.4.3 Diagrama de Seqncia

De acordo com Melo (2004: 163) o diagrama de seqncia tem a finalidade de identificar as operaes das classes com o auxilio de um conjunto de elementos grficos que permita ilustrar todas as interaes do sistema. Os cenrios de caso de uso podem ser representados atravs do diagrama de seqncia, assim podemos visualizar a troca de mensagens entre as classes e visualizar quando os objetos so criados e destrudos. Nas figuras 35, 36 e 37 podem ser visualizados alguns dos elementos do diagrama de seqncia, em seguida uma explicao sobre cada um deles.

78

Figura 35: Diagrama de seqncia com elementos bsicos. (BEZERRA, 2002: 148)

A representao dos atores no diagrama de seqncia opcional, sua forma grfica de um homem de basto (stick man). Os objetos do diagrama de caso de uso devem aparecer no diagrama na mesma seqncia. Os objetos podem ser annimos ou nomeados, so nomeados quando so utilizados em vrios lugares. Objeto nomeado

Objeto annimo

item: ItemPedido

: ItemPedido

Figura 36: Objetos annimos e nomeados. (BEZERRA, 2002: 149)

A nomeao dos objetos feita pelo nome do Objeto: nome da Classe. Bezerra (2002: 149) explica que, na maioria das vezes os diagramas de

seqncia contm objetos, caso alguma mensagem for direcionada a uma classe esta dever ser representada no diagrama sem sublinhar seu nome. A linha de vida do diagrama de seqncia aparece na forma de uma linha tracejada verticalmente. O foco de controle um retngulo em cima da linha de vida do objeto, ele representa o tempo em que o objeto realiza uma ao. A cada nova ao do objeto

79 um novo foco de controle adicionado abaixo da linha da ultima mensagem de retorno recebida. As trocas de mensagens podem ser representadas de acordo com seu tipo, conforme mostra a figura 37.
Simples Sncrona Assncrona Retorno
Figura 37: Notao de tipos de mensagens em diagrama de seqncia. (BEZERRA, 2002: 150)

Mensagem simples: mensagem do tipo no relevante. a mais utilizada; Mensagem sncrona: ao enviar uma mensagem sncrona o remetente fica bloqueado enquanto espera a resposta do receptor; Mensagem assncrona: nesse tipo de mensagem o objeto no espera a resposta para prosseguir com as aes seguintes; Mensagem de retorno: indica o fim do processamento, seu uso opcional; Mensagem reflexiva: quando um objeto envia uma mensagem a si prprio para executar uma operao que est implementada na sua prpria classe. Pode-se ver um exemplo de mensagem reflexiva na figura 38.

A criao de objetos pode ser requisitada por outro objeto a partir da mensagem create (criar). Se o objeto for criado desde o inicio da interao ele fica no topo do diagrama, se for instanciado depois ele fica na mesma altura da mensagem de criar. A destruio de objetos ocorre logo aps a mensagem destroy (destruir) e sua representao atravs do smbolo X logo no final do foco de controle logo abaixo da mensagem de destruio. Na figura 38 podemos observar todas os elementos citados.

80

Figura 38: Elementos do Diagrama de Seqncia. (BEZERRA, 2002: 151)

3.4.4 Diagrama de Atividades

O diagrama de atividade tem por propsito focalizar um fluxo de atividades que ocorrem internamente em um processamento, dentro de um perodo de tempo. (MELO, 2004: 187). O diagrama de atividades foi redesenhado na UML 2.0. Esse tipo de diagrama orientado a fluxo de controle e tem como objetivo representar o estado de uma atividade e tambm pode ser utilizado para auxiliar a modelagem de um cenrio no diagrama de caso de uso. Segundo Booch (2000: 258-265), os diagramas costumam conter os seguintes elementos: Estado de inicio, ou estado inicial; Estado de parada, ou estado final; Estado de Ao e Atividade; Ponto de Transio; Ponto de Ramificao e Intercalao; Bifurcao e Unio;

81 Raias de Natao; Fluxo de Objeto.

Podemos ver esses elementos nos diagramas das figuras 39 e 40, e a explicao de cada um deles em seguida.

Figura 39: Elementos de Diagrama de Atividades. (BEZERRA, 2002: 229)

O estado inicial e o estado final do diagrama so representados por um circulo cheio e um crculo cheio com outro crculo ao redor respectivamente. O estado de ao e estado de atividades tem sua representao por um retngulo com os cantos arredondados. A diferena entre esses dois estados que em um estado de ao executada uma ao por vez, ao essa que no pode ser decomposta. J em um estado de atividade so compostos por vrios estados de aes e podem conter outros estados de atividades. O ponto de transio representado por uma linha contnua com uma seta aberta que aponta para o prximo estado de ao ou estado de atividade que ser executado. Os pontos de Ramificao e Intercalao so representados por um losango vazio com setas entrando e saindo dele. O ponto de Ramificao possui uma seta entrando e vrias saindo, sendo que na sada, somente um caminho ser seguindo de acordo com a condio estabelecida. O ponto de Intercalao possui

82 vrias setas entrando e somente uma saindo, utilizado para marcar o fim de um ponto de Ramificao. Na figura 40 podemos observar os seguintes elementos: Bifurcao e Unio, Raias de Natao e Fluxo de Objeto.

Figura 40: Aplicao de Raias de Natao (swim lanes) . (BOOCH, 2000: 265)

As

Raias de Natao so compostas por um grande retngulo dividido

verticalmente de acordo com as responsabilidades. Na figura 40 podemos observar as raias do Cliente, Vendas e Estoque, cada uma com suas responsabilidades e seus fluxos. Nota-se que as transies podem cruzar as raias, mas as atividades pertencem a uma nica raia. A Bifurcao e Unio, tambm chamada de barra de sincronizao, representada na figura 40 por uma linha grossa na horizontal, mas tambm pode estar na vertical. So utilizadas para modelar atividades concorrentes (que

83 acontecem ao mesmo tempo). A Bifurcao permite a entrada de um fluxo de controle e o divide em dois ou mais fluxos de controle. A Unio permite a entrada de dois ou mais fluxos de controle e os sincronizam em apenas um fluxo de controle na sada, nesse caso o processamento s poder prosseguir at que todos os fluxos de controle cheguem at esse ponto. O Fluxo de Objeto utilizado para relacionar objetos aos fluxos de controle. Booch (2000: 265) explica que, o estado de um objeto pode ser representado colocando o nome do estado que se encontra dentro de colchetes embaixo do nome do objeto.

84

Captulo 4. Estudo de Caso

Nesse captulo ser descrito o estudo de caso de uma locadora de veculos onde sero abordados os conceitos da anlise orientada a objetos apresentados anteriormente.

4.1 Definio do Ambiente e Escopo do Software

Conforme visto no item 1.3 (O projeto de software), necessrio antes de iniciar a construo do software, se faa alguns levantamentos preliminares e um planejamento para que o produto final saia como o esperado.

4.1.1 Apresentao do ambiente

A empresa Freedom Rent a Car44 do ramo de locao de veculos, ela pretende instalar sua primeira loja da rede no aeroporto de Guarulhos dentro de setenta dias que contar com dez funcionrios, sendo cinco agentes de locao, cinco manobristas e o proprietrio que gerenciar o negcio. O horrio de funcionamento da agncia ser vinte e quatro horas por dia, sete dias por semana durante todos os dias do ano (24 x 7 x 365) sendo que somente os agentes e os manobristas trabalharo em regime de escala, o gerente, que o proprietrio da frota45, trabalhar de segunda a sexta no horrio comercial ficando acessvel para sanar eventuais problemas ou dvidas nos finais de semana e feriados. A frota de veculos ser composta inicialmente de 30 veculos sendo divididos em grupos46 de A a P de vrias marcas, modelos e anos de fabricao todos os grupos com preos diferenciados para cada tipo de cliente e para cada poca do ano. O escritrio contar com uma infra-estrutura enxuta, porm eficaz, contendo duas estaes (um microcomputador para o agente e um notebook47 de uso do gerente) ambos com acesso banda larga.

44 45

O nome da empresa fictcia para preservar sua identidade. Frota: So todos os veculos pertencentes a uma agencia de locao de veculos. 46 Grupo: So conjuntos de veculos que tem as mesmas caractersticas tais como: tamanho, potencia, valor, etc. 47 Microcomputador pequeno, leve e porttil.

85 Aps a informatizao, em uma etapa futura, ser elaborada uma pgina na Internet que permitir aos clientes fazerem reservas48 on-line, esse servidor Web ter a criao e manuteno de sua pgina feita por uma empresa terceirizada e a hospedagem do servidor onde estaro armazenados os arquivos da base de dados estar alocado em um data-center49 contratado. A empresa planeja atingir um faturamento de R$ 80.000,00/ms e estima seu custo mensal em R$ 60.000,00. A empresa planeja adquirir um sistema para o controle operacional de locaes de veculos (reservas, locaes, cadastros, cobranas) o qual dever prever comunicao para o sistema administrativo, financeiro e contbil que ser implantado no futuro.

4.1.2 Declarao do Objetivo Geral do Sistema

Controlar as reservas, locaes e cobrana de um sistema de locadora de veculos. No esto inclusos os controles financeiros, contbeis.

Objetivo e Escopo do Projeto

O projeto completo da locadora abrange toda uma infra-estrutura de hardware e software. Apesar de estarem relacionados alguns itens que no fazem parte desse trabalho, por outro lado, eles fazem parte do escopo do projeto. Temos como objetivo a informatizao de todas as rotinas operacionais de uma locadora de veculos, incluindo: Instalao de uma rede local com acesso a Internet; Construo de sistema, utilizando tecnologia Orientada a Objetos, para controlar a rea operacional de locao de veculos50. Deve-se prever que, futuramente,
48

existir

comunicao

desse

sistema

com

as

reas

administrativas, financeiras e contbeis. Construo de interface grfica (front end);

Reserva: Manter o veculo correspondente a um grupo especfico reservado para um cliente para um dia e horrio pr-determinado. 49 Data-Center: Local especializado para hospedagem de equipamentos de informtica de mdio e grande porte, por exemplo: servidores. 50 Esse objetivo o foco do estudo de caso.

86 Instalao de servidor de banco de dados; Prever a implementao de interface Web no sistema para futura implantao.

4.1.3 Estudo de Viabilidade

Estudo de Viabilidade Tcnica Plataforma51 Windows; O servidor

54

utilizar

sistema

de

redundncia52

R.A.I.D.53

com

multiprocessamento a ASP58;

utilizando sistema operacional Windows 2003 Server55,

Sistema Gerenciador de Banco de Dados SQL Server56 e servidor IIS57 com suporte O acesso banda larga deve ter uma taxa real de, no mnimo, 1Mbps59. Devido falta de recurso na equipe de desenvolvimento ser necessria a

contratao de profissionais para auxiliar no desenvolvimento, implantao e demais atividades durante o projeto.

Estudo de Viabilidade Operacional

Partindo-se do princpio de que na locadora de veculos est sendo inaugurada e no existem rotinas operacionais implantadas, pode-se analisar o seguinte impacto operacional:

uma expresso utilizada para denominar a tecnologia empregada em determinada infra-estrutura, garantindo facilidade de integrao dos diversos elementos dessa infra-estrutura. 52 A redundncia de interfaces de rede, de processadores, de servidores, de fontes de alimentao interna mantm o perfeito funcionamento do sistema mesmo em caso de falhas de componentes ou sobrecargas do sistema. 53 Abreviao do termo ingls Redundant Array of Inexpensive Disks que significa Disposio Redundante de Discos Baratos, cuja finalidade manter vrias cpias de dados para contornar possveis falhas de hardware. 54 a capacidade de um computador executar simultaneamente dois ou mais processos. 55 Tipo de software bsico, abordado no item 1.2.2, cujo fabricante a Microsoft. 56 Software aplicativo responsvel pelo gerenciamento de uma base de dados 57 O IIS (Internet Information Services) um servidor de pginas web criado pela Microsoft. 58 Abreviao do termo em ingls Active Server Pages. uma linguagem de programao que, juntamente com o software aplicativo IIS, permite que sejam disponibilizadas pginas para Web. 59 O megabit por segundo (mbps or mbit/s) uma unidade de transmisso de dados.

51

87 Dificuldade dos agentes na utilizao do sistema para atender as rotinas

da locadora; Todos os agentes so da rea de locao de veculos e operavam

diferentes sistemas. Acredita-se que o treinamento de cinco dias proposto para os usurios seja o suficiente para suprir essa dificuldade operacional.

Estudo de Viabilidade Financeira

Esto inclusos no projeto o fornecimento de todos os equipamentos para deixar o ambiente totalmente operacional (micros, servidores multi-processados com sistema de redundncia RAID, micro porttil, equipamentos e infra-estrutura de rede, assim como, todos os custos com sistemas operacionais, sistema de rede, banco de dados). Tambm esto contabilizados os custos com os profissionais envolvidos no desenvolvimento do sistema e do projeto como um todo.

4.1.4 Planejamento das Atividades

A apresentao do planejamento de atividades pode ser feita em uma tabela, em forma de organograma, textual, entre outras. Optou-se pela apresentao do planejamento de atividades na forma do grfico de Gantt60.

Item A B C D E

Atividades Analisar e levantar de requisitos Fazer projeto de T.I61. e S.I. Compras e Entrega de produtos de T.I e S.I. Criar banco de dados Gerar cdigo fonte62 para programa de interface do usurio

Recursos humanos Analista de sistema Projetista Comprador Projetista de banco de dados Projetista de interface do usurio

O Grfico de Gantt uma das formas de se fazer uma apresentao visual grfica dos itens do planejamento O QUE, POR QUE, QUEM, QUANDO, COMO e ONDE abordados no item 1.3.3. 61 Abreviao de Tecnologia da Informao. Serve para designar o conjunto de recursos tecnolgicos e computacionais para gerao e uso da informao. 62 o conjunto de palavras escritas de forma ordenada, contendo instrues em uma das linguagens de programao existentes no mercado, de maneira lgica.

60

88 F G H I Executar teste de funcionabilidade no sistema Integrar equipamentos e sistemas Elaborar treinamento para usurios Auditoria do sistema em produo. Verificador Integrador de sistema Desenvolvedor de curso Auditor de sistema

Tabela 3: Tabela de Atividades x Recursos Humanos

Figura 41: Disposio das Atividades no grfico de Gantt

4.2 Levantamento de Requisitos do Software

Vimos no item 2.5 (Requisitos de software) que necessrio utilizar alguns artifcios para visualizar o sistema que o cliente deseja, pois muitas vezes a comunicao no clara e o projeto pode no atender as necessidades do ambiente. Nesse estudo de caso, para fazer o levantamento de requisitos do software, optou-se por fazer algumas entrevistas primeiramente com o gerente para entender como funciona o negcio e posteriormente elaborou-se um questionrio63 e a tcnica de brainstorming para obter informaes. Participaram das demais entrevistas e da reunio de Brainstorming o gerente e cinco agentes. Foram abordados procedimentos, rotinas, suas responsabilidades e coletados alguns documentos com a finalidade de gerar artefatos para o projeto.

63

O questionrio utilizado para o levantamento de requisitos encontra-se no Anexo B.

89

4.2.1 Anlise e especificao de requisitos.

Com base nas entrevistas realizadas levantaram-se os seguintes requisitos, abaixo enumerados precedidos pela letra R.

Requisitos Funcionais
R1 - O cliente poder fazer a reserva, por telefone ou pessoalmente, tanto o cliente quanto o agente recebero o cdigo da reserva. R2 - A reserva dever ser cancelada automaticamente uma hora aps a hora prevista para retirada do veculo; R3 - O cliente poder solicitar o cancelamento ou alterao da reserva por telefone ou pessoalmente; R4 - O sistema deve permitir que o usurio, de acordo com o tipo de perfil, possa inserir, consultar, alterar e cancelar dados do: cadastro de veculos, cadastro de clientes, cadastro de tarifas de locao, dados da reserva, contrato de locao e informaes da agncia; R5 - O sistema deve permitir a abertura do contrato de locao onde sero inseridos os dados do cliente, dados do veculo a ser locado pelo cliente, data e hora da retirada e sua previso de retorno, dados do seguro; R6 - Para liberar o veculo64 ao cliente, o programa dever fazer uma prautorizao (on-line) junto administradora de carto no valor correspondente ao grupo e o perodo que o veculo ficar locado; R7 - Para fazer o fechamento do contrato de locao o programa deve solicitar o nmero do contrato de locao, cdigo do veculo, quilometragem de chegada, quantidade de combustvel, cdigo do agente e forma de pagamento; R8 - Para fazer o pagamento o sistema far uma transao on-line efetuandoo na forma escolhida pelo cliente (carto de dbito ou crdito), o nmero da autorizao do pagamento ser impresso juntamente com o contrato em quatro vias; R9 - O sistema deve avisar o agente sempre que houver uma nova reserva no sistema atravs do recebimento de um e-mail e tambm permitir a impresso dos dados de reserva em uma impressora;

64

Liberao do veiculo: As chaves so entregues ao cliente juntamente com uma via do contrato de locao e o cliente e o veculo so liberados.

90 R10 - O sistema deve avisar o agente sempre que o veculo atingir a quilometragem de reviso, data do licenciamento e / ou vistoria, data ou quilometragem prevista para venda; R11 - Quando o veculo precisar de manuteno ou qualquer outro tipo de servio, o veculo tem o status alterado saindo de Disponvel para Manuteno;

Requisitos No-Funcionais
A base de dados deve ser protegida permitindo acesso apenas aos usurios autorizados; O tempo de resposta do sistema no deve ultrapassar cinco segundos; O servidor dever ter infra-estrutura para permanecer ligado 24hs/dia; O sistema dever ter uma comunicao on-line com as administradoras de

cartes via Internet.

4.3 Regras de negcios

Conforme visto no item 3.4.1, antes de iniciar a descrio dos casos de uso, precisamos relacionar as regras do negcio. Em nosso estudo de caso foram levantadas as seguintes regras de negcio:

RN01. Pr-requisito para locao. O cliente (motorista) deve ter no mnimo 21 anos de idade, possuir CNH a mais de 2 anos e carto de crdito com limite disponvel para fazer a pr-autorizao ambos vlidos at o final da locao. RN02. Locao de veculo O cliente poder alugar um veculo com ou sem reserva, a diferena que a reserva garante a disponibilidade de um grupo de veculo especfico para um dia e horrio determinado pelo cliente. RN03. Quantidade mxima de locaes por vez. Pessoa fsica poder fazer apenas uma locao por vez, pessoa jurdica poder alugar mais de um. RN04. Perodo de locao.

91 Para pessoa fsica uma locao no pode durar mais do que 30 dias, caso isso acontea o cliente deve retornar a agencia para renovar o contrato. Para pessoa jurdica no existe prazo mximo para devoluo. RN05. Alterao da reserva A reserva poder ser alterada a qualquer momento desde que a mesma ainda esteja vlida no sistema. RN06. Cancelamento automtico da reserva. A reserva feita pelo cliente perder validade caso o mesmo no comparea na agncia para retirar o veculo em at uma hora aps o prazo para retirada estipulada no ato da reserva. RN07. Contrato de locao O contrato de locao poder ser modificado a qualquer momento para a substituio do veculo caso o alugado apresente problemas. RN08. Venda do veculo. A locadora dever vender o veculo quando o mesmo atingir 50.000Km ou 2 anos (o que atingir primeiro).

92

4.4 Diagrama de Caso de Uso

No anexo E (Detalhes do Diagrama de Caso de Uso) pode-se obter uma relao dos itens do diagrama do caso de uso e seus respectivos relacionamentos.

Figura 42: Diagrama de Caso de Uso Locadora de Veculos

Lista de Casos de Uso

De acordo com o diagrama de caso de uso acima, temos a seguinte lista de caso de uso: Controlar Cobrana;

93 o Efetuar Pagamento com Cheque; o Efetuar Pagamento Faturado; o Fazer Pagamento com Carto; o Fazer Pr-Autorizao; o Validar Carto; Controlar Contrato; o Abrir Contrato de Locao; o Alterar Contrato de Locao; o Fechar Contrato de Locao; o Cancelar Contrato de Locao; Controlar Reserva; o Incluir Reserva; o Alterar Reserva; o Consultar Reserva; o Excluir Reserva; Emitir Relatrio; o Emitir Relatrio de Cliente; o Emitir Relatrio de Veculos; o Emitir Relatrio de Contratos; Fazer Cadastro; o Manter Cadastro de Veculo; Incluir Veculo; Alterar Veculo; Excluir Veculo; o Manter Cadastro de Usurio; Incluir Usurio; Alterar Usurio; Excluir Usurio; o Manter Cadastro de Cliente; Incluir Cliente; Alterar Cliente; Excluir Cliente; o Manter Cadastro de Tarifa; Incluir Tarifa;

94 Alterar Tarifa; Excluir Tarifa;

4.4.1 Descrio dos Cenrios

Para este trabalho no se tornar repetitivo, no sero abordados todos os casos de uso apresentados. Sero descritos apenas os casos de uso referente ao pacote: Controlar Cobrana por ser o mais complexo e por conter todos os elementos dos outros casos de uso.

Controlar Cobrana (CSU01) Sumrio: O usurio pode: efetuar diversos tipos de pagamentos e fazer prautorizao atravs da administradora de carto. Ator Primrio: Usurio Ator Secundrio: Adm Cartao (Administradora de Carto) Fluxo Principal: 1) O usurio seleciona opo Fechar Contrato e seleciona a opo Efetuar Pagamento. 2) O usurio entra com o valor e data do pagamento, e escolhe uma das opes de tipo de pagamento. 2.1) Se pagamento com cheque. Verificar o caso de uso CSU02. 2.2) Se pagamento com dinheiro. 2.2.1) Lana o valor pago e a data de pagamento na base de dados. 2.2.2) O sistema emite nota fiscal; 2.2.3) O sistema atualiza o status do contrato de locao e o caso de uso termina. 2.3) Se pagamento faturado. Verificar o caso de uso CSU03. 2.4) Se pagamento com carto. Verificar o caso de uso CSU04.

Efetuar Pagto Cheque (CSU02) Sumrio: Usurio efetua pagamento da locao com cheque. Ator Primrio: Usurio Fluxo Principal:

95 1) O sistema solicita ao usurio os seguintes dados adicionais de cobrana: 1.1) Nome do banco; 1.2) Nmero do banco; 1.3) Nmero da agncia; 1.4) Nome da agncia; 1.5) Nmero do cheque; 1.6) Data de emisso do cheque; 1.7) Prazo para pagamento do Cheque; 2) O sistema armazena os dados de pagamento na base de dados. 3) O sistema emite nota fiscal. Ps-condies: Atualiza o status do contrato de locao e o caso de uso termina.

Efetuar Pagto Faturado (CSU03) Sumrio: Usurio efetua faturamento da locao. Ator Primrio: Usurio Fluxo Principal: 1) O sistema solicita ao usurio os seguintes dados adicionais de cobrana: 1.1) Razo Social; 1.2) CNPJ (Cadastro Nacional de Pessoa Jurdica); 1.3) Endereo completo; 1.4) Telefone; 1.5) Contato; 1.6) Nmero da Autorizao de Pagamento fornecida pela empresa. 2) O sistema armazena os dados de pagamento na base de dados. 3) O sistema emite nota fiscal e boleto para pagamento. Ps-condies: Atualiza o status do contrato de locao e o caso de uso termina.

Fazer Pagto Cartao (CSU04) Sumrio: Cliente faz pagamento atravs de carto. Ator Primrio: Usurio Ator Secundrio: Adm Cartao (Administradora de Carto) Fluxo Principal: 1) O sistema solicita ao usurio os seguintes dados adicionais de cobrana:

96 1.1) Nmero do carto; 1.2) Validade do carto; 1.3) Digito de segurana do carto. 2) O usurio confirma os dados e o sistema envia os dados para validao. Include (Validar Cartao); 3) O sistema envia dados para administradora e recebe o nmero da autorizao. 4) O sistema armazena os dados de pagamento na base de dados. 5) O sistema emite nota fiscal e boleto para pagamento e o caso de uso termina. Fluxo Alternativo (3): Sistema da administradora de carto est congestionado. a) O sistema informa que a administradora de carto est com o sistema congestionado e solicita que tente novamente dentro de alguns instantes. O caso de uso retorna ao passo 2. b) O sistema informa que o limite disponvel no carto de crdito insuficiente. O caso de uso retorna ao passo 1. Ps-condies: O sistema armazena o nmero da autorizao no cadastro de contrato.

Validar Carto (CSU05) Sumrio: O sistema valida o carto de crdito do cliente junto administradora do carto. Ator Primrio: Usurio Ator Secundrio: Adm Cartao (Administradora de Carto) Fluxo Principal: 1) O caso de uso recebe os dados do carto, o valor, e o digito de segurana; 2) O sistema comunica-se com a administradora do carto que faz a validao; 3) O sistema envia para a administradora os dados do carto e valor para pagamento; 4) O sistema recebe da administradora de carto o nmero da transao e o caso de uso termina. Fluxo Alternativo (3): Sistema da administradora de carto est congestionado. a) O status do erro enviado e o caso de uso termina.

97

4.5 Diagrama de Classes

No anexo F (Detalhes do Diagrama de Classes) pode-se obter uma relao com mais detalhes dos itens abordados pelo diagrama de classes e suas respectivas associaes.

Figura 43: Diagrama de Classes Locadora de Veculos

98

4.6 Diagrama de Seqncia

No anexo G (Detalhes do Diagrama de Seqncia Controlar Cobranca) pode-se obter uma relao detalhada dos itens do diagrama de seqncia referente ao caso de uso Controlar Cobranca.

Figura 44: Diagrama de Seqncia - Parte 1/2

99

Continuao do diagrama anterior.

Figura 45: Diagrama de Seqncia - Parte 2/2

100

4.7 Diagrama de Atividade

Figura 46: Diagrama de atividade do pacote Controlar Cobrana

No anexo H (Detalhes do Diagrama de Atividade Controlar Cobranca) podese obter uma relao detalhada dos itens do diagrama de seqncia referente ao caso de uso Controlar Cobranca.

101

Anexo A Modelo de Descrio de Caso de Uso

Modelo de descrio de caso de uso sugerido por Bezerra (2002:84)

102

Anexo B Questionrio utilizado no levantamento de requisitos

1) Quais as opes que o cliente ter para fazer uma reserva? O cliente poder fazer a reserva telefonando ou comparecendo pessoalmente na agncia. 2) Quais os dados necessrios para o cliente fazer uma reserva? Para fazer uma reserva o cliente deve fornecer: data e hora de retirada, data e hora devoluo, nmero do cliente (se houver), tipo de veculo, optar pelo tipo de seguro (opcional), nome completo, telefone, optar pelo tipo de tarifa (corporativa ou pessoal). 3) Como o cliente ir se referenciar a uma reserva? O sistema dever fornecer um cdigo de reserva para que ser solicitado no ato da abertura de contrato65 de locao ou para um eventual cancelamento ou alterao da reserva. 4) Como o cliente dever proceder para cancelar uma reserva? O cliente somente poder cancelar uma reserva telefonando ou

comparecendo na agncia informando o cdigo da reserva. 5) Como o cliente saber quais veculos, marcas e modelos estaro disponveis para locao? Existe uma relao de veculos separada por grupos de A a P onde cada grupo composto por vrios veculos, de marcas e modelos diferentes e devero estar disponveis no sistema e futuramente na web. 6) Quais os pr-requisitos para o cliente alugar um veculo? Ser exigido que o motorista tenha mais de 21 anos, habilitado a mais de 2 anos e com carteira de habilitao vlida at o final do contrato de locao. Para pessoa fsica ser possvel fazer apenas uma locao por vez, pessoa jurdica poder alugar mais de um. 7) Quando o sistema estiver disponvel na web, como o agente ficar sabendo que existe uma reserva de veculo quando esta for feita pela Internet? Aps o cliente preencher todas as informaes na pgina da Internet referente reserva, quero que esses dados sejam inseridos no sistema automaticamente e que o agente receba um e-mail avisando sobre a nova reserva.
65

Abertura do contrato: So inseridos os dados necessrios no contrato (dados do cliente, veculo, seguro, prautorizao, etc) para que o cliente seja liberado com o veculo.

103 8) Quais as formas de pagamento possveis? Sero aceitos pagamento em carto de dbito, crdito, cheque e dinheiro. 9) Como funciona o sistema de tarifas? Existe uma tabela de tarifas para cada: grupo de veculo, perodo de locao (diria, semanal ou mensal), quilometragem66 livre ou controlada, faixa de quilometragem, corporativa ou promocional e de alta ou baixa temporada. 10) Quais os documentos necessrios para locao? CNH, CPF, RG, carto de crdito vlido. 11) Qual garantia ser exigida do cliente para a locao de veculos? Ser efetuada uma pr-autorizao67 no carto de crdito do cliente no valor correspondente ao grupo do veculo escolhido. 12) Quem ir cadastrar e alterar os clientes, veculos, tarifas, reservas, dados da agencia, abrir e fechar contrato? Os agentes sero responsveis apenas por cadastrar clientes, fazer, alterar e cancelar reservas, fazer abertura e fechamento de contrato68. Somente o gerente ter acesso para cadastrar veculos, tarifas, dados da agencia e alterar qualquer informao no sistema. 13) Quais dados sero exigidos para cadastrar usurios? O nome completo, login, senha e determinar os direitos de acesso. 14) Quais relatrios e consultas sero necessrios e quem ter acesso e que tipo de acesso? Relatrio e consulta de cliente, veculos, locao, pagamento. Os agentes podero alterar somente os dados cadastrais dos clientes, os demais tero acesso somente para visualizao. O gerente dever ter acesso completo e poder alterar qualquer informao. 15) Quais dados sero exigidos para efetuar o cadastro de veculos? Para cadastro do veculo quero que o sistema solicite: cdigo do veculo, nome do fabricante, modelo, ano, n do chassi, placa, cor, Km, cdigo da chave (se houve), quantidade de portas, tipo de acessrios (ar, direo, rdio / cd), data da
66

Quilometragem: o limite de quilometragem que o cliente tem o direito de percorrer com o veculo dentro de um prazo determinado pela tarifa sem o pagamento de taxas adicionais por quilometro rodado. 67 Pr-autorizao: No ato da abertura do contrato faz-se uma cobrana no carto de crdito do cliente com um valor pr-determinado para efeito de acionar o seguro do veculo caso seja necessrio. Quando o cliente retornar com o veculo a cobrana ser cancelado. 68 Fechamento do contrato: So inseridos os dados necessrios no contrato (dados do veculo, dados para pagamento, etc) para a devoluo do veiculo e pagamento da locao.

104 compra, data em que deve ser realizados a vistoria69 e licenciamento, data prevista para venda. 16) Como funcionar o sistema de pagamento com cartes? O sistema dever se comunicar com as administradoras de cartes a qual tenho convnio para efetuar as transaes on-line. Os dados dos cartes devem ser digitados no sistema e o comprovante ser impresso em uma impressora acoplada ao computador. Os dados de pr-autorizao, autorizao e / ou pagamento devero constar no contrato.

69

Vistoria: uma verificao do estado funcional e visual do veculo que tem por objetivo comparar qualquer avaria depois do ato de retirada at o ato da devoluo.

GRUPO A - SUBCOMPACT - VECULOS 1.0 SEM AR CONDICIONADO

GRUPO 2/4DR 2/4DR 2/4DR 2/4DR 2/4DR 2/4DR 2/4DR 4DR 2/4DR Liter Liter Liter Liter Liter Liter Liter Liter Liter M M M M M M M M M 1,0 1,0 1,0 1,0 1,0 1,0 1,2 1,0 1,0 Subcompact Subcompact Subcompact Subcompact Subcompact Subcompact Subcompact Subcompact Subcompact 48 50 42 42 46 46 40 50 51 GAS GAS GAS GAS GAS GAS GAS GAS GAS 14,9 16 16,1 16,1 14,9 14,9 14 12 14,8

MAKE

MODEL

DOO RS LITER TRANS.

ENGINE SIZE

BODY TYPE

FUEL CAPACITY

FUEL TYPE

DISTANCE PER UNIT

A A A A A A A A A

Fiat Fiat Ford Ford GM GM Renault Renault Volkswagen

Palio Uno Mille Fiesta Ford Ka Corsa Wind Celta Twingo Clio Gol

Anexo C - Tabelas de Grupos de Veculos

GRUPO B - SUBCOMPACT - VECULOS 1.0 COM AR CONDICIONADO

GRUPO 2/4DR 2/4DR 2/4DR 2/4DR 2/4DR 2/4DR 4DR 2DR 2/4DR 1,0 1,0 1,0 1,0 1,0 1,0 1,0 1,0 1,0 Subcompact Subcompact Subcompact Subcompact Subcompact Subcompact Subcompact Subcompact Subcompact 48 50 42 42 46 46 50 50 51

MAKE

MODEL

DOORS

ENGINE SIZE

BODY TYPE

FUEL CAPACITY

LITER Liter Liter Liter Liter Liter Liter Liter Liter Liter

FUEL TYPE GAS GAS GAS GAS GAS GAS GAS Bi-comb GAS

DISTANCE PER UNIT 14,9 16 16,1 16,1 14,9 14,9 12 11 14,8

TRANS. M M M M M M M M M

B B B B B B B B B

Fiat Fiat Ford Ford GM GM Renault Volkswagen Volkswagen

Palio Uno Mille Fiesta Ford Ka Celta Corsa Wind Clio Fox Gol

105

GRUPO C - COMPACT - VECULOS SEDAN 1.0 COM AR CONDICIONADO

GRUPO 4DR 4DR 4DR 4DR Liter Liter Liter Liter 1,0 1,0 1,0 1,0 Compact Compact Compact Compact 48 42 46 40 GAS GAS GAS GAS 10,6 15 14,9 12 M M M M

MAKE

MODEL

DOO RS LITER TRANS.

ENGINE SIZE

BODY TYPE

FUEL CAPACITY

FUEL TYPE

DISTANCE PER UNIT

C C C C

Fiat Ford GM Renault

Siena Fiesta Sedan Corsa Sedan Clio Sedan

GRUPO D - COMPACT - VECULOS 1.3, 1.4, 1.6, 1.8 COM AR CONDICIONADO

GRUPO 2/4DR 2/4DR 2/4DR 4DR 2/4DR 4DR 4DR 2DR 4DR 4DR 2/4DR 4DR 4DR 1,6 1,3 1,6 1,4 1,6 1,6 1,6 1,6 1,6 1,6 1,8 1,6 1,8 Compact Compact Compact Compact Compact Compact Compact Compact Compact Compact Compact Compact Compact 48 48 42 45 46 50 48 50 51 51 51 45 45

MAKE

MODEL

DOORS

ENGINE SIZE

BODY TYPE

FUEL CAPACITY

LITER Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter

FUEL TYPE GAS GAS GAS Bi-comb GAS GAS GAS Bi-comb GAS GAS GAS GAS GAS

DISTANCE PER UNIT 13,9 12,6 13,6 11 13,9 12 12,7 10 13,8 12 13,8 14,7 13,8

TRANS. M M M M M M M M M M M M M

D D D D D D D D D D D D D

Fiat Fiat Ford GM GM Renault Seat Volkswagen Volkswagen Volkswagen Volkswagen Volkswagen Volkswagen

Palio Palio Fiesta Celta Corsa Clio Seat Ibiza Fox Gol Gol Power Gol Polo Polo

106

GRUPO E - INTERMEDIATE - VECULOS SEDAN 1.3, 1.6 e 1.8 COM AR CONDICIONADO

DOORS 4DR 4DR 4DR 4DR 4DR 4DR 4DR 4DR 1,3 1,6 1,8 1,6 1,8 1,6 1,6 1,6 Liter Liter Liter Liter Liter Liter Liter Liter Intermediate Intermediate Intermediate Intermediate Intermediate Intermediate Intermediate Intermediate 48 48 48 42 45 46 50 48 GAS GAS Bi-comb GAS GAS GAS GAS GAS 12 10,6 12,1 13,6 11,3 13,9 12 12,7 ENGINE SIZE LITER BODY TYPE FUEL CAPACITY FUEL TYPE DISTANCE PER UNIT TRANS. M M M M M M M M

GRUPO

MAKE

MODEL

E E E E E E E E

Fiat Fiat Fiat Ford GM GM Renault Seat

Siena Siena Siena Fiesta Sedan Corsa Sedan Maxx Corsa Sedan Clio Sedan Seat Cordoba

GRUPO F - STATION WAGON - VECULOS 1.3, 1.6, 1.8 COM AR CONDICIONADO

DOORS 4DR 4DR 4DR 4DR 4DR 4DR 4DR 4DR 4DR 1,6 1,3 1,8 1,8 1,8 1,6 1,4 1,6 1,8 Station Wegon Station Wegon Station Wegon Station Wegon Station Wegon Station Wegon Station Wegon Station Wegon Station Wegon ENGINE SIZE BODY TYPE FUEL CAPACITY 51 51 51 51 64 46 42 51 51 LITER Liter Liter Liter Liter Liter Liter Liter Liter Liter FUEL TYPE GAS Bi-comb Bi-comb GAS GAS GAS GAS GAS GAS DISTANCE PER UNIT 11,6 11,1 10,3 10 12,7 13,8 14 13,4 13,4 TRANS. M M M M M M M M M

GRUPO

MAKE

MODEL

F F F F F F F F F

Fiat Fiat Fiat Fiat Ford GM Honda Volkswagen Volkswagen

Palio Weekend Palio Weekend Palio Weekend Palio Weekend Escort Wagon Corsa Wagon FIT Parati Parati

107

GRUPO G - FULL SIZE - VECULOS COM AR CONDICIONADO

GRUPO 4DR 4DR 4DR 4DR 4DR 4DR 4DR 2DR 4DR 4DR 4DR 4DR 4DR 4DR 4DR 4DR 4DR 4DR 4DR 1,6 1,8 1,6 1,6 2,0 1,8 2,0 2,0 2,0 1,6 1,6 2,0 1,8 / 2,0 1,6 2,0 1,8 / 2,0 2,0 1,6 1,6 Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Full Size Full Size Premium Full Size Full Size Full Size Full Size Full Size Full Size Full Size Full Size Full Size Full Size Full Size Full Size Full Size Full Size Full Size Full Size 47 45 55 60 52 52 52 52 60 60 60 60 72 55 55 72 55 55 45 GAS GAS GAS GAS GAS GAS GAS GAS GAS GAS GAS GAS GAS GAS GAS GAS GAS GAS Bi-comb

MAKE

MODEL

DOORS

ENGINE SIZE LITER

BODY TYPE

FUEL CAPACITY

FUEL TYPE

DISTANCE PER UNIT 10 10 11,4 8 8,7 11,7 11,6 11,6 8 9,5 14,5 14,5 13,8 10 10 13,8 12,2 12,2 12,4

TRANS. M M M M M M M M M M M M M M A M M M M

G G G G G G G G G G G G G G G G G G G

Citroen Fiat Ford Fiat GM GM GM GM GM Peugeot Renault Renault Volkswagen Volkswagen Volkswagen Volkswagen Volkswagen Volkswagen Volkswagen

C3 Stilo Focus Ret Brava Astra Sedan Flex Astra Sedan Astra Astra Meriva Peugeot 307 Megane Megane Santana Golf Golf Sant. Quantum Golf Polo Sedan Polo Sedan Flex

108

GRUPO H PREMIUM
MODEL Marea Marea Marea Focus Blazer Omega Vectra Vectra Blazer Civic Civic Peugeot 406 Laguna Corolla Corolla Bora 4DR 4DR 4DR 4DR 4DR 4DR 4DR 4DR 4DR 4DR 4DR 4DR 4DR 4DR 4DR 4DR 2,0 1,8 2,4 2,2 2,2 3,0 2,2 2,0 4,1 2,0 2,0 2,0 1,8 1,6 1,8 2,0 Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Liter Premium Premium Premium Premium Premium Premium Premium Premium Premium Premium Premium Premium Premium Premium Premium Premium 63 63 63 57 72 75 57 57 72 65 65 65 60 55 55 63 GAS GAS GAS GAS GAS GAS GAS GAS GAS GAS GAS GAS GAS GAS GAS GAS 9,5 9 10,5 11,5 9,8 9,6 11,5 9 9,8 9,8 9,8 9,7 15,7 11 10 11,5 DOORS ENGINE SIZE LITER BODY TYPE FUEL CAPACITY FUEL TYPE DISTANCE PER UNIT TRANS. M M M M M M M M M M A M M M A M

GRUPO

MAKE

H H H H H H H H H H H H H H H H

Fiat Fiat Fiat Ford GM GM GM GM GM Honda Honda Peugeot Renault Toyota Toyota Volkswagen

GRUPO I - MINI VAN

GRUPO 4DR 4DR 4DR 4DR 4DR 4DR 4DR 2,0 2,0 2,0 2,0 1,8 1,6 2,0

MAKE

MODEL

DOORS

ENGINE SIZE

BODY TYPE Mini Van Mini Van Mini Van Mini Van Mini Van Mini Van Mini Van

FUEL CAPACITY 55 58 58 58 58 60 60

LITER Liter Liter Liter Liter Liter Liter Liter

FUEL TYPE GAS GAS Bi-comb Bi-comb Bi-comb GAS GAS

DISTANCE PER UNIT 11,9 11,6 9 9,8 11,6 10 10

TRANS. M M A M M M M

I I I I I I I

Citroen GM GM GM GM Renault Renault

Picasso Zafira Zafira Elegance Zafira Elite Meriva Senic Senic

109

GRUPO J - PICKUP PEQUENA

MODEL 2DR 2DR 2DR 2DR 2DR 2DR 2DR 2DR 2DR 1,5 1,5 1,6 1,6 1,8 1,6 1,6 1,8 1,6 Liter Liter Liter Liter Liter Liter Liter Liter Liter Pickup Pickup Pickup Pickup Pickup Pickup Pickup Pickup Pickup 58 64 53 57 55 53 54 54 53 GAS GAS GAS GAS Bi-comb. GAS GAS GAS GAS 12,3 11,6 11,9 13,5 12 11,9 12,7 13 13,9 DOORS ENGINE SIZE LITER BODY TYPE FUEL CAPACITY FUEL TYPE DISTANCE PER UNIT TRANS. M M M M M M M M M

GRUPO

MAKE

J J J J J J J J J

Fiat Fiat Ford GM GM Volkswagen Volkswagen Volkswagen Volkswagen

Strada Fiorino Courier Corsa Corsa-Montana Saveiro Van Carga Saveiro Saveiro Flex

GRUPO K AUTOMATIC

GRUPO Corolla 4DR 1,6 Premium

MAKE

MODEL

DOORS

ENGINE SIZE

BODY TYPE

FUEL CAPACITY 55

LITER Liter

FUEL TYPE GAS

DISTANCE PER UNIT 12

TRANS. A

Toyota

GRUPO M - KOMBI

GRUPO Kombi 2DR

MAKE

MODEL

DOORS

ENGINE SIZE 1,6

BODY TYPE Minivan

FUEL CAPACITY 46

LITER Liter

FUEL TYPE GAS

DISTANCE PER UNIT 8,2

TRANS. M

Volkswagen

110

GRUPO N - VAN

GRUPO 2DR 3DR 2DR 3DR 3DR 2DR 2,0 2,0 2,0 2,6 2,0 2,5 Liter Liter Liter Liter Liter Liter Van Van Van Van Van Van 80 80 80 65 65 80 Diesel Diesel Diesel Diesel Diesel Diesel 12,2 12,2 12,2 12 12,5 12,2

MAKE

MODEL

DOORS

ENGINE SIZE LITER

BODY TYPE

FUEL CAPACITY

FUEL TYPE

DISTANCE PER UNIT

TRANS. M M M M M M

N N N N N N

Asia Fiat Ford Hyundai Kia Mercedes

Towner Ducato Club Wagon H-100 GL Besta Sprinter

GRUPO O MINI VAN (COM AR CONDICIONADO

MODEL Kangoo Doublo 3DR 4DR 1,0 1,3 Mini Van Mini Van 50 50 DOORS ENGINE SIZE BODY TYPE FUEL CAPACITY LITER Liter Liter FUEL TYPE GAS GAS DISTANCE PER UNIT 14,7 11 TRANS. M M

GRUPO

MAKE

O O

Renault Fiat

GRUPO P - PICKUP
MODEL 2DR 4DR 4DR 4DR 2DR 2DR 4DR 4DR 2DR 2,2 1,6 1,6 2,8 2,4 2,8 2,5 2,5 2,8 DOORS ENGINE SIZE BODY TYPE Pickup Pickup Pickup Pickup Pickup Pickup ---Pickup ---FUEL CAPACITY 72 60 45 98 70 70 64 75 72 LITER Liter Liter Liter Liter Liter Liter Liter Liter Liter FUEL TYPE GAS GAS GAS Diesel GAS Diesel GAS Diesel Diesel DISTANCE PER UNIT 9,8 8 12,3 6 7 11 7 9,7 9 TRANS. M M M M M M A M A

GRUPO

MAKE

P P P P P P P P P

Ford Ford Ford Ford GM GM Land Rover Mitsubishi Troller

Ranger EcoSport EcoSport F-250 XLT W20 S10 S10 Freelander L-200 T4 TDI 4X4

111

112

Anexo D - Tabelas de Tarifas de Locao de Veculos

TARIFA STANDARD WKI / WJI

PARA: Todas as localidades DATA EFETIVA: 01 Maro 04
WKI Grupos SIPP Diria Semanal Mensal

PAS: Brasil VALIDADE: Indeterminada

WJI WKI/WJI Dia Adic.72

Km Adic.70 Hr. Adic.71

A
B C D E F G H I J K M N O P

79,00 110,00 118,00 140,00 149,00 158,00 206,00 238,00 265,00 134,00 258,00 163,00 325,00 227,00 269,00

474,00 660,00 708,00 840,00 894,00 948,00 1.236,00 1.428,00 1.590,00 804,00 1.548,00 978,00 1.950,00 1.362,00 1.614,00

1.896,00 2.640,00 2.832,00 3.360,00 3.576,00 3.792,00 4.944,00 5.712,00 6.360,00 3.216,00 6.192,00 3.912,00 7.800,00 5.448,00 6.456,00

0,45 0,60 0,65 0,75 0,80 0,85 1,10 1,30 1,40 0,70 1,36 0,85 1,75 1,20 1,45

22,58 31,44 33,73 40,01 42,58 45,16 58,87 68,01 75,73 38,30 73,71 46,58 92,87 64,87 73,71

67,72 94,30 101,15 120,01 127,72 135,44 176,58 204,01 227,15 114,87 221,14 139,72 278,58 194,58 230,58

MN/ MX DIAS: WKI= 01/28, WJI= 28/31 dias QUILOMETRAGEM: WKI = Livre, WJI = 3.000 km livres/ ms

70

Km adicional: o valor pago pelo cliente a locadora quando a distncia percorrida pelo veculo foi maior que a contratada. 71 Hora adicional: o valor pago pelo cliente a locadora quando h atraso na devoluo do veiculo em at 23 horas. 72 Dia adicional: o valor pago pelo cliente a locadora quando h atraso na devoluo do veiculo entre 1 a 6 dias.

113

TARIFA 2CI DIRIA KM LIVRE

PARA: Todas as localidades DATA EFETIVA: 01 Maro 04 PAS: Brasil VALIDADE: Indeterminada

Grupos

Diria

Semanal

Mensal

Hora adic.

Dia adic.

A B C D E F G H I J M N O P

61,00 85,00 91,00 109,00 115,00 122,00 160,00 184,00 205,00 104,00 126,00 252,00 176,00 208,00

20,34 28,34 30,34 36,34 38,34 40,68 53,34 61,34 68,34 34,68 42,01 84,01 58,68 69,34

MN/ MX DIAS: 1/6 QUILOMETRAGEM: Livre

114

TARIFA 2NI SEMANAL KM LIVRE

PARA: Todas as localidades DATA EFETIVA: 01 Maro 04 PAS: Brasil VALIDADE: Indeterminada

Grupos

Diria

Semanal

Mensal

Hora adic.

Dia adic.

A B C D E F G H I J M N O P

367,00 512,00 549,00 651,00 693,00 735,00 958,00 1.107,00 1.232,00 623,00 758,00 1.511,00 1.056,00 1251,00

17,49 24,39 26,15 31,01 33,01 35,01 45,63 52,72 58,68 29,68 36,11 71,96 50,30 59,58

52,43 73,14 78,43 93,00 99,00 105,00 136,86 158,14 176,00 89,00 108,29 215,86 150,86 178,71

MN/ MX DIAS: 6/30 QUILOMETRAGEM: Livre

115

TARIFA HPI 100 KM LIVRES

PARA: Todas as localidades DATA EFETIVA: 01 Maro 04 PAS: Brasil VALIDADE: Indeterminada

Grupos

Diria

Semanal

Dia adic.

Hora adic.

Km adic.

A B C D E F G H I J M N O P

51,00 72,00 77,00 91,00 97,00 103,00 134,00 155,00 172,00 87,00 106,00 211,00 148,00 175,00

308,00 429,00 460,00 546,00 581,00 616,00 803,00 928,00 1.034,00 523,00 636,00 1.268,00 885,00 1.049,00

44,01 61,29 65,74 78,00 83,01 88,03 114,77 132,60 147,64 74,66 90,81 181,07 126,47 149,87

17,13 23,84 25,58 30,34 32,29 34,24 44,64 51,58 57,43 29,04 35,33 70,43 49,19 58,29

0,45 0,60 0,65 0,75 0,80 0,85 1,10 1,30 1,40 0,70 0,85 1,75 1,20 1,45

MN/ MX DIAS: 1/28 QUILOMETRAGEM: 100 Km livres/dia

116

TARIFA BPI KM CONTROLADA

PARA: Todas as localidades DATA EFETIVA: 20 Jun 03 PAS: Brasil VALIDADE: Indeterminada

Grupos

Diria

Semanal

Dia adic.

Hora adic.

Km rodado

A B C D E F G H I J M N O P

27,75 40,50 43,00 52,50 55,75 59,00 77,50 87,50 100,75 51,50 62,75 121,25 86,25 100,25

9,26 13,51 14,34 17,51 18,59 19,68 25,84 29,18 33,59 17,18 20,93 40,43 28,76 33,43

0,45 0,60 0,65 0,75 0,80 0,85 1,10 1,30 1,40 0,70 0,85 1,75 1,20 1,45

MN/ MX DIAS: 1/ 7 QUILOMETRAGEM: Controlada

117

TARIFA JMI MENSAL 3.000 KM LIVRES

PARA: Todas as localidades DATA EFETIVA: 01 Maro 04 PAS: Brasil VALIDADE: Indeterminada

Grupos

Mensal

Semana adic.73

Dia adic.

Hora adic.

Km adic.

A B C D E F G H I J M N O P

1.109,00 1.544,00 1.657,00 1.966,00 2.092,00 2.218,00 2.892,00 3.342,00 3.721,00 1.881,00 2.289,00 4.563,00 3.187,00 3.777,00

277,00 386,00 414,00 491,00 523,00 555,00 723,00 835,00 930,00 470,00 572,00 1.141,00 797,00 944,00

39,61 55,16 59,17 70,20 74,71 79,23 103,29 119,34 132,88 67,19 81,73 162,96 113,82 134,88

13,21 18,40 19,73 23,41 24,91 26,42 34,44 39,79 44,30 22,41 27,25 54,33 37,95 44,97

0,45 0,60 0,65 0,75 0,80 0,85 1,10 1,30 1,40 0,70 0,85 1,75 1,20 1,45

MN/ MX DIAS: 28/ 30 QUILOMETRAGEM: 3.000 km livres/ms

73

Semana adicional: o valor pago pelo cliente a locadora quando h atraso na devoluo do veiculo entre 1 a 3 semanas.

118

TARIFA 51I CORPORATE NO-DESCONTVEL

PARA: Todas as localidades DATA EFETIVA: Abril 04 PAS: Brasil VALIDADE: Indeterminada

Grupos

Diria

Semanal

Mensal

Hora adic.

Dia adic.

A B C D E F G H I J M N O P

67,00 94,00 100,00 119,00 127,00 134,00 175,00 202,00 225,00 114,00 139,00 276,00 193,00 229,00

402,00 564,00 600,00 714,00 762,00 804,00 1.050,00 1.212,00 1.350,00 684,00 834,00 1.656,00 1.158,00 1.374,00

1.005,00 1.410,00 1.500,00 1.785,00 1.905,00 2.010,00 2.625,00 3.030,00 3.375,00 1.710,00 2.085,00 4.140,00 2.895,00 3.435,00

19,15 26,87 28,58 34,01 36,30 38,30 50,01 57,72 64,30 32,58 39,72 78,87 55,15 65,44

57,43 80,57 85,71 102,00 108,86 114,86 150,00 173,14 192,86 97,71 119,14 236,57 165,43 196,29

MN/ MX DIAS: 1/ no h QUILOMETRAGEM: Livre

119

Anexo E Detalhes do Diagrama de Caso de Uso

Diagram Content Summary
Sistema de Locadora de Veiculos Pacote de Controle de Cobranca Pacote de Controle de Contrato Pacote de Controle de Relatorios Pacote de Controle de Cadastro Pacote de Controle de Reservas Fazer Pagto Cartao Validar Cartao Fazer Pre-Autorizacao Efetuar Pagto Faturado Efetuar Pagto Cheque Controlar Cobranca Abrir Contrato Alterar Cadastro Fechar Contrato Controlar Contrato Cancelar Contrato Relatorio de Contratos Relatorio de Cliente Relatorio de Veiculos Emitir Relatorio Controlar Cadastro Manter Dados de Usuario Manter Dados de Tarifa Manter Dados de Cliente Manter Dados de Veiculo Consultar Reserva Manter Dados de Reversa Manter Dados... Incluir Dados... Alterar Dados... Excluir Dados... Usuario Gerente Adm Cartao Agente

Diagram Content Detail

UseCase Fazer Pagto Cartao Parent : Pacote de Controle de Cobranca Include: Validar Cartao Super Class

120
Controlar Cobranca

UseCase Validar Cartao Parent : Pacote de Controle de Cobranca Include by: Fazer Pagto Cartao, Fazer Pre-Autorizacao Communication Link communicationlink to Adm Cartao

UseCase Fazer Pre-Autorizacao Parent : Pacote de Controle de Cobranca Include: Validar Cartao, Abrir Contrato

UseCase Efetuar Pagto Faturado Parent : Pacote de Controle de Cobranca Super Class Controlar Cobranca

UseCase Efetuar Pagto Cheque Parent : Pacote de Controle de Cobranca Super Class Controlar Cobranca

UseCase Controlar Cobranca Parent : Pacote de Controle de Cobranca Subclasses Efetuar Pagto Cheque, Fazer Pagto Cartao, Efetuar Pagto Faturado Communication Link communicationlink to Adm Cartao Communication Link communicationlink to Usuario

UseCase Abrir Contrato

Use Case Extends Hierarchy Controlar Contrato | +-Abrir Contrato Parent : Pacote de Controle de Contrato Include by: Fazer Pre-Autorizacao Extended by Consultar Reserva Extension Point Name : ExtensionPoint Extend from Controlar Contrato Super Class Controlar Contrato

UseCase Alterar Cadastro Use Case Extends Hierarchy Controlar Contrato | +-Alterar Cadastro Parent : Pacote de Controle de Contrato

121
Extend from Controlar Contrato Super Class Controlar Contrato

UseCase Fechar Contrato Use Case Extends Hierarchy Controlar Contrato | +-Fechar Contrato Parent : Pacote de Controle de Contrato Extend from Controlar Contrato Super Class Controlar Contrato

UseCase Controlar Contrato Parent : Pacote de Controle de Contrato Extended by Abrir Contrato, Fechar Contrato, Alterar Cadastro, Cancelar Contrato Extension Point Name : ExtensionPoint Name : ExtensionPoint Name : ExtensionPoint Name : ExtensionPoint Name : ExtensionPoint Name : ExtensionPoint Subclasses Abrir Contrato, Fechar Contrato, Alterar Cadastro Communication Link communicationlink to Usuario

UseCase Cancelar Contrato Use Case Extends Hierarchy Controlar Contrato | +-Cancelar Contrato Parent : Pacote de Controle de Contrato Extend from Controlar Contrato

UseCase Relatorio de Contratos Use Case Extends Hierarchy Emitir Relatorio | +-Relatorio de Contratos Parent : Pacote de Controle de Relatorios Extend from Emitir Relatorio Super Class Emitir Relatorio

UseCase Relatorio de Cliente Use Case Extends Hierarchy Emitir Relatorio | +-Relatorio de Cliente

122
Parent : Pacote de Controle de Relatorios Extend from Emitir Relatorio Super Class Emitir Relatorio

UseCase Relatorio de Veiculos

Use Case Extends Hierarchy Emitir Relatorio | +-Relatorio de Veiculos Parent : Pacote de Controle de Relatorios Extend from Emitir Relatorio Super Class Emitir Relatorio

UseCase Emitir Relatorio

Parent : Pacote de Controle de Relatorios Extended by Relatorio de Cliente, Relatorio de Contratos, Relatorio de Veiculos Extension Point Name : ExtensionPoint Name : ExtensionPoint Name : ExtensionPoint Name : ExtensionPoint Subclasses Relatorio de Cliente, Relatorio de Contratos, Relatorio de Veiculos Communication Link communicationlink to Gerente

UseCase Controlar Cadastro Parent : Pacote de Controle de Cadastro Extended by Manter Dados de Cliente, Manter Dados de Veiculo, Manter Dados de Usuario, Manter Dados de Tarifa Extension Point Name : ExtensionPoint Name : ExtensionPoint Name : ExtensionPoint Name : ExtensionPoint Subclasses Manter Dados de Cliente, Manter Dados de Tarifa, Manter Dados de Usuario, Manter Dados de Veiculo Communication Link communicationlink to Gerente

UseCase Manter Dados de Usuario Use Case Extends Hierarchy Controlar Cadastro | +-Manter Dados de Cliente | +-Manter Dados de Usuario Parent : Pacote de Controle de Cadastro Extend from Controlar Cadastro Manter Dados de Cliente

123
Super Class Controlar Cadastro

UseCase Manter Dados de Tarifa Use Case Extends Hierarchy Controlar Cadastro | +-Manter Dados de Tarifa Parent : Pacote de Controle de Cadastro Extend from Controlar Cadastro Super Class Controlar Cadastro

UseCase Manter Dados de Cliente Use Case Extends Hierarchy Controlar Cadastro | +-Manter Dados de Cliente Parent : Pacote de Controle de Cadastro Extended by Manter Dados de Usuario Extension Point Name : ExtensionPoint Extend from Controlar Cadastro Super Class Controlar Cadastro Communication Link communicationlink to Usuario

UseCase Manter Dados de Veiculo Use Case Extends Hierarchy Controlar Cadastro | +-Manter Dados de Veiculo Parent : Pacote de Controle de Cadastro Extend from Controlar Cadastro Super Class Controlar Cadastro

UseCase Consultar Reserva Use Case Extends Hierarchy Manter Dados de Reversa | +-Controlar Contrato | +-Abrir Contrato | +-Consultar Reserva Parent : Pacote de Controle de Reservas Extend from Manter Dados de Reversa Abrir Contrato

UseCase Manter Dados de Reversa Parent : Pacote de Controle de Reservas Extended by Consultar Reserva Extension Point Name : ExtensionPoint

124
Subclasses UseCase Communication Link communicationlink to Usuario

UseCase Manter Dados... Parent : Sistema de Locadora de Veiculos Extended by Incluir Dados..., Alterar Dados..., Excluir Dados... Extension Point Name : Incluir Dados Name : Alterar Dados Name : Excluir Dados

UseCase Incluir Dados... Use Case Extends Hierarchy Manter Dados... | +-Incluir Dados... Parent : Sistema de Locadora de Veiculos Extend from Manter Dados...

UseCase Alterar Dados... Use Case Extends Hierarchy Manter Dados... | +-Alterar Dados... Parent : Sistema de Locadora de Veiculos Extend from Manter Dados...

UseCase Excluir Dados...

Use Case Extends Hierarchy Manter Dados... | +-Excluir Dados... Parent : Sistema de Locadora de Veiculos Extend from Manter Dados...

Actor Usuario Subclasses Gerente, Agente Communication Link communicationlink to Manter Dados de Cliente Communication Link communicationlink to Manter Dados de Reversa Communication Link communicationlink to Agente Communication Link communicationlink to Controlar Contrato Communication Link communicationlink to Controlar Cobranca

Actor Gerente Generalization Hierarchy Usuario | +-Gerente Super Class

125
Usuario Communication Link communicationlink to Controlar Cadastro Communication Link communicationlink to Emitir Relatorio

Actor Adm Cartao Communication Link communicationlink to Validar Cartao Communication Link communicationlink to Controlar Cobranca

Actor Agente Generalization Hierarchy Usuario | +-Agente Super Class Usuario Communication Link communicationlink to Usuario

Package Pacote de Controle de Cobranca Parent : Sistema de Locadora de Veiculos Children: Fazer Pagto Cartao, Validar Cartao, Fazer Pre-Autorizacao, Efetuar Pagto Faturado, Efetuar Pagto Cheque, Controlar Cobranca

Package Pacote de Controle de Contrato Parent : Sistema de Locadora de Veiculos Children: Abrir Contrato, Alterar Cadastro, Fechar Contrato, Controlar Contrato, Cancelar Contrato

Package Pacote de Controle de Relatorios Parent : Sistema de Locadora de Veiculos Children: Relatorio de Contratos, Relatorio de Cliente, Relatorio de Veiculos, Emitir Relatorio

Package Pacote de Controle de Cadastro Parent : Sistema de Locadora de Veiculos Children: Controlar Cadastro, Manter Dados de Usuario, Manter Dados de Tarifa, Manter Dados de Cliente, Manter Dados de Veiculo

Package Pacote de Controle de Reservas Parent : Sistema de Locadora de Veiculos Children: Consultar Reserva, Manter Dados de Reversa

System Sistema de Locadora de Veiculos Children: UseCase, Efetuar Pagto Dinheiro, Efetuar Pagto Taxa Servico, UseCase2, , UseCase3, Pacote de Controle de Cobranca, Pacote de Controle de Contrato, Pacote de Controle de Relatorios, Pacote de

126
Controle de Cadastro, Pacote de Controle de Reservas, , Manter Dados..., Incluir Dados..., Alterar Dados..., Excluir Dados...

Communication Link
Communication Link End From Element : Gerente Navigable : True Visibility : Unspecified Communication Link End To Element : Controlar Cadastro Navigable : True Visibility : Unspecified

Communication Link
Communication Link End From Element : Usuario Navigable : True Visibility : Unspecified Communication Link End To Element : Manter Dados de Reversa Navigable : True Visibility : Unspecified

Communication Link
Communication Link End From Element : Gerente Navigable : True Visibility : Unspecified Communication Link End To Element : Emitir Relatorio Navigable : True Visibility : Unspecified

Communication Link
Communication Link End From Element : Usuario Navigable : True Visibility : Unspecified Communication Link End To Element : Controlar Contrato Navigable : True Visibility : Unspecified

Communication Link
Communication Link End From Element : Usuario Navigable : True Visibility : Unspecified Communication Link End To Element : Controlar Cobranca Navigable : True Visibility : Unspecified

127

Communication Link
Communication Link End From Element : Adm Cartao Navigable : True Visibility : Unspecified Communication Link End To Element : Validar Cartao Navigable : True Visibility : Unspecified

128

Anexo F Detalhes do Diagrama de Classes

Diagram Content Summary
Sistema de Locadora de Veiculos IContrato Cliente Reserva TiposDeTarifa GrupoTarifa GruposDeVeiculos Contrato Veiculo Pagamento Cartao Cheque Fatura IPagamentoAdmCartao ICliente IReserva IVeiculo IGrupoVeiculo ITipoDeTarifa IGrupoTarifa

Diagram Content Detail

Class IContrato Stereotype : interface Realizied by: Contrato, Pagamento

Operation Summary public public public public public public public Operation Detail public abrirContrato() Return Type : public alterarContrato() Return Type : public fecharContrato()

abrirContrato() alterarContrato() fecharContrato() cancelarContrato() consultarContrato() efetuarPagamento() enviaDadosCobranca()

129

Return Type : public cancelarContrato() Return Type : public consultarContrato() Return Type : public efetuarPagamento() Return Type : public enviaDadosCobranca() Return Type :

Class Cliente
Parent : Sistema de Locadora de Veiculos Realization: ICliente Association association(0..*) to Contrato Association association(0..*) to Contrato Association association(0..*) to Reserva Attribute Summary private string private string private int private string private string private int private string private int private date private date private int private int private int private string private int

clienteNome endereco cep cidade estado cpf rg cnh validadeCnh dataNascimento telefoneRes telefoneCel telefoneComl empresaNome empresaCnpj

Operation Summary public public public public Attribute Detail private string clienteNome private string endereco private int cep private string cidade private string estado private int cpf

cadastrarCliente() excluirCliente() alterarCliente() consultarCliente()

130
private string rg private int cnh private date validadeCnh private date dataNascimento private int telefoneRes private int telefoneCel private int telefoneComl private string empresaNome private int empresaCnpj Operation Detail public cadastrarCliente() Return Type : public excluirCliente() Return Type : public alterarCliente() Return Type : public consultarCliente() Return Type :

Class Reserva Parent : Sistema de Locadora de Veiculos Realization: IReserva Association association to Reserva Association association(0..1) to Contrato Association association(1) to Cliente Association association(1) to GrupoTarifa Association association(0..1) to Contrato Association association to Reserva
Attribute Summary private tiime private time private date private date private int private string

horaSaida horaDevolucao dataSaida dataDevolucao statusReserva numeroReserva

Operation Summary public public public public Attribute Detail private tiime horaSaida private time horaDevolucao private date dataSaida private date dataDevolucao

cadastrarReserva() cancelarReserva() alterarReserva() consultaReserva()

131
private int statusReserva private string numeroReserva Operation Detail public cadastrarReserva() Return Type : public cancelarReserva() Return Type : public alterarReserva() Return Type : public consultaReserva() Return Type :

Class TiposDeTarifa Parent : Sistema de Locadora de Veiculos Realization: ITipoDeTarifa Association association(1..*) to GruposDeVeiculos
Attribute Summary private string private string private string private date private date private int

tarifaNome tarifaId tarifaComentario tarifaValidade tarifaDataEfetiva tarifaKmFranquia

Operation Summary public public public public

cadastrarTarifa() consultarTarifa() excluirTarifa() alterarTarifa()

Attribute Detail private string tarifaNome private string tarifaId private string tarifaComentario private date tarifaValidade private date tarifaDataEfetiva private int tarifaKmFranquia Operation Detail public cadastrarTarifa() Return Type : public consultarTarifa() Return Type : public excluirTarifa()

132
Return Type : public alterarTarifa() Return Type :

Class GrupoTarifa Parent : Sistema de Locadora de Veiculos Realization: IGrupoTarifa Association association(0..*) to Contrato Association association(0..*) to Contrato Association association(1..*) to Reserva
Attribute Summary private float private float private float private float private float private float

tarifaDiaria tarifaSemanal tarifaMensal tarifaKmAdicional tarifaHoraAdicional tarifaDiaAdicional

Operation Summary public public public public

alterarTarifa() cadastrarTarifa() consultarTarifa() excluirTarifa()

Attribute Detail private float tarifaDiaria private float tarifaSemanal private float tarifaMensal private float tarifaKmAdicional private float tarifaHoraAdicional private float tarifaDiaAdicional Operation Detail public alterarTarifa() Return Type : public cadastrarTarifa() Return Type : public consultarTarifa() Return Type : public excluirTarifa() Return Type :

Class GruposDeVeiculos Parent : Sistema de Locadora de Veiculos Realization: IGrupoVeiculo Subclasses

133
Class11 Association association(0..*) to Veiculo Association association(0..*) to Contrato Association association(1..*) to TiposDeTarifa Association association(0..*) to Veiculo Attribute Summary private string private string

grupoNome grupoComentario

Operation Summary public public public public

cadastrarGrupo() consultarGrupo() excluirGrupo() alterarGrupo()

Attribute Detail private string grupoNome private string grupoComentario Operation Detail public cadastrarGrupo() Return Type : public consultarGrupo() Return Type : public excluirGrupo() Return Type : public alterarGrupo() Return Type :

Class Contrato Parent : Sistema de Locadora de Veiculos Realization: IContrato Realizied by: Sistema de Locadora de Veiculos Association association(1) to Pagamento Association association(1) to Cliente Association association(1) to Veiculo Association association(0..1) to Reserva Association association(1) to GrupoTarifa Association association(1) to GruposDeVeiculos Association association(1) to Cliente Association association(0..1) to Reserva Association association(1) to GrupoTarifa Association association(1) to Veiculo
Attribute Summary private string private date private int

numeroContrato dataContrato codigoAgenteAbertura

134
private int private int private date private time private byte private byte private byte private byte private float private date private time private int private float private int private float private int private float private int private float private int private float private int private float private int private int private int private byte private date private time private string private float private float private float private float private string kmSaida qteCombustivelDeSaida dataSaida horaSaida seguroVeiculo seguroPessoal seguroTerceiros prePagto valorPrePagto dataPrevistaDevolucao horaPrevistaDevolucao qteKmAdicional valorKmAdicional qteHoraAdicional valorHoraAdicional qteDiaria valorDiaria qteSemana valorSemanal qteMensal valorMensal qteDiaAdicional valorDiaAdicional codigoAgenteFechamento kmChegada qteCombustivelChegada cobrarCombustivel dataChegada horaChegada ajusteComentario valorSeguroPessoal valorSeguroVeiculo valorSeguroTerceiros valorAjuste statusContrato

Operation Summary public public public public public public

abrirContrato() alterarContrato() fecharContrato() cancelarContrato() consultaContrato() efetuaPagamento()

Attribute Detail private string numeroContrato private date dataContrato private int codigoAgenteAbertura private int kmSaida private int qteCombustivelDeSaida private date dataSaida private time horaSaida

135
private byte seguroVeiculo private byte seguroPessoal private byte seguroTerceiros private byte prePagto private float valorPrePagto private date dataPrevistaDevolucao private time horaPrevistaDevolucao private int qteKmAdicional private float valorKmAdicional private int qteHoraAdicional private float valorHoraAdicional private int qteDiaria private float valorDiaria private int qteSemana private float valorSemanal private int qteMensal private float valorMensal private int qteDiaAdicional private float valorDiaAdicional private int codigoAgenteFechamento private int kmChegada private int qteCombustivelChegada private byte cobrarCombustivel private date dataChegada private time horaChegada private string ajusteComentario private float valorSeguroPessoal private float valorSeguroVeiculo private float valorSeguroTerceiros private float valorAjuste private string statusContrato Operation Detail public abrirContrato() Return Type : public alterarContrato() Return Type : public fecharContrato() Return Type : public cancelarContrato() Return Type : public consultaContrato() Return Type : public efetuaPagamento() Return Type :

Class Veiculo Parent : Sistema de Locadora de Veiculos

136
Realization: IVeiculo Association association(0..*) to Contrato Association association(0..*) to Contrato Association association(1) to GruposDeVeiculos Association association(1) to GruposDeVeiculos Attribute Summary private string private string private string private string private string private string private int private int private string private byte private byte private byte private date private date private date private int private date private string private int private string private int private string private int

numeroChassi numeroPlaca fabricante marca cor anoModelo qtePorta kmInicial codigoChave arCondicionado direcaoHidraulica radio dataCompra dataVistoria dataPrevVenda statusVeiculo dataLicenciamento otencia capacidadeCombustivel tipoCombustivel rendimentoCombustivel tipoCarroceria tipoTransmissao

Operation Summary public public public public

cadastarVeiculo() consultarVeiculo() alterarVeiculo() excluirVeiculo()

Attribute Detail private string numeroChassi private string numeroPlaca private string fabricante private string marca private string cor private string anoModelo private int qtePorta private int kmInicial private string codigoChave private byte arCondicionado private byte direcaoHidraulica private byte radio private date dataCompra private date dataVistoria

137
private date dataPrevVenda private int statusVeiculo private date dataLicenciamento private string otencia private int capacidadeCombustivel private string tipoCombustivel private int rendimentoCombustivel private string tipoCarroceria private int tipoTransmissao Operation Detail public cadastarVeiculo() Return Type : public consultarVeiculo() Return Type : public alterarVeiculo() Return Type : public excluirVeiculo() Return Type :

Class Pagamento Parent : Sistema de Locadora de Veiculos Realization: IPagamentoAdmCartao, IContrato Subclasses Cartao, Cheque, Fatura Association association(1) to Contrato
Attribute Summary private date private string private float

dataPagamento tipoPagto valorTotal

Operation Summary public public public public public public public Attribute Detail private date dataPagamento private string tipoPagto private float valorTotal

atualizaBaseDeDados() emiteNotaFiscal() atualizaStatusContrato() validaCartao() recebeDadosAdministradora() enviaDadosAdministradora() enviaDadosCobraca()

Operation Detail public atualizaBaseDeDados()

138

Return Type : public emiteNotaFiscal() Return Type : public atualizaStatusContrato() Return Type : public validaCartao() Return Type : public recebeDadosAdministradora() Return Type : public enviaDadosAdministradora() Return Type : public enviaDadosCobraca() Return Type :

Class Cartao Generalization Hierarchy Pagamento | +-Cartao Parent : Sistema de Locadora de Veiculos Super Class Pagamento
Attribute Summary private float private int private date private int private int private int

valorPreAutorizacao cartaoId cartaoValidade cartaoDigitoSeguraca numeroAutorizacao numeroPreAutorizacao

Attribute Detail private float valorPreAutorizacao private int cartaoId private date cartaoValidade private int cartaoDigitoSeguraca private int numeroAutorizacao private int numeroPreAutorizacao

Class Cheque Generalization Hierarchy Pagamento | +-Cheque Parent : Sistema de Locadora de Veiculos Super Class Pagamento

139
Attribute Summary private string private string private string private string private string private date

nomeBanco numeroBanco numeroAgencia nomeAgencia numeroDoCheque dataEmissao

Attribute Detail private string nomeBanco private string numeroBanco private string numeroAgencia private string nomeAgencia private string numeroDoCheque private date dataEmissao

Class Fatura Generalization Hierarchy Pagamento | +-Fatura Parent : Sistema de Locadora de Veiculos Super Class Pagamento
Attribute Summary private string private string private string private int private string private int

razaoSocial cnpj endereco telefone contato numeroAutorizacaoPagto

Attribute Detail private string razaoSocial private string cnpj private string endereco private int telefone private string contato private int numeroAutorizacaoPagto

Class IPagamentoAdmCartao Stereotype : interface Realizied by: Pagamento

Operation Summary public public public

validaCartao() recebeDadosAdministradora() enviaDadosAdministradora()

140
Operation Detail public validaCartao() Return Type : public recebeDadosAdministradora() Return Type : public enviaDadosAdministradora() Return Type :

Class ICliente Stereotype : interface Realizied by: Cliente

Operation Summary public public public public Operation Detail public cadastrarCliente() Return Type : public excluirCliente() Return Type : public alterarCliente() Return Type : public consultarCliente() Return Type :

cadastrarCliente() excluirCliente() alterarCliente() consultarCliente()

Class IReserva Stereotype : interface Realizied by: Reserva

Operation Summary public public public public Operation Detail public cadastrarReserva() Return Type : public cancelarReserva() Return Type : public alterarReserva()

cadastrarReserva() cancelarReserva() alterarReserva() consultarReserva()

141

Return Type : public consultarReserva() Return Type :

Class IVeiculo Stereotype : interface Realizied by: Veiculo

Operation Summary public public public public Operation Detail public cadastrarVeiculo() Return Type : public consultarVeiculo() Return Type : public alterarVeiculo() Return Type : public excluirVeiculo() Return Type :

cadastrarVeiculo() consultarVeiculo() alterarVeiculo() excluirVeiculo()

Class IGrupoVeiculo
Stereotype : interface Realizied by: GruposDeVeiculos Operation Summary public public public public Operation Detail public cadastrarGrupo() Return Type : public consultarGrupo() Return Type : public excluirGrupo() Return Type : public alterarGrupo()

cadastrarGrupo() consultarGrupo() excluirGrupo() alterarGrupo()

142

Return Type :

Class ITipoDeTarifa Stereotype : interface Realizied by: TiposDeTarifa

Operation Summary public public public public Operation Detail public cadastrarTarifa() Return Type : public consultarTarifa() Return Type : public excluirTarifa() Return Type : public alterarTarifa() Return Type :

cadastrarTarifa() consultarTarifa() excluirTarifa() alterarTarifa()

Class IGrupoTarifa Stereotype : interface Realizied by: GrupoTarifa

Operation Summary public public public public Operation Detail public alterarTarifa() Return Type : public cadastrarTarifa() Return Type : public consultarTarifa() Return Type : public excluirTarifa() Return Type :

alterarTarifa() cadastrarTarifa() consultarTarifa() excluirTarifa()

Package Sistema de Locadora de Veiculos

143
Children: Class7, Class8, Class9, Class10, Class11, Package, Cliente, Contrato, Veiculo, Reserva, TiposDeTarifa, GrupoTarifa, GruposDeVeiculos, Pagamento, Cartao, Cheque, Fatura Realization: Contrato

Association
Association End From Element : Cliente Multiplicity : 1 Navigable : True Association End To Element : Contrato Multiplicity : 0..* Navigable : True

Association
Association End From Element : Reserva Multiplicity : 0..* Navigable : True Association End To Element : Cliente Multiplicity : 1 Navigable : True

Association
Association End From Element : Reserva Multiplicity : 1..* Navigable : True Association End To Element : GrupoTarifa Multiplicity : 1 Navigable : True

Association
Association End From Element : Reserva Multiplicity : 0..1 Navigable : True Association End To Element : Contrato Multiplicity : 0..1 Navigable : True

Association
Association End From Element : GruposDeVeiculos Multiplicity : 1..* Navigable : True Association End To

144
Element : TiposDeTarifa Multiplicity : 1..* Navigable : True

Association
Association End From Element : GrupoTarifa Multiplicity : 1 Navigable : True Association End To Element : Contrato Multiplicity : 0..* Navigable : True

Association
Association End From Element : GruposDeVeiculos Multiplicity : 1 Navigable : True Aggregation Kind : Aggregation Association End To Element : Veiculo Multiplicity : 0..* Navigable : True

Association
Association End From Element : Contrato Multiplicity : 1 Navigable : True Association End To Element : Pagamento Multiplicity : 1 Navigable : True

Association
Association End From Element : Veiculo Multiplicity : 1 Navigable : True Association End To Element : Contrato Multiplicity : 0..* Navigable : True

145

Anexo G Detalhes do Diagrama de Seqncia Controlar Cobranca

Detalhes do Diagrama de Seqncia Controlar Cobranca Parte #1/2 Diagram Content Summary
Usuario IContrato c1:Contrato Pagamento Cheque

Diagram Content Detail

Actor Usuario Message Usuario insere dados para pagamento: tipoPagto, valorTotal, dataPagamento to IContrato Message Opcao fechar Contrato to IContrato Message Usuario insere dados adicionais de cobranca: nomeBanco, numeroBanco, nomeAgencia, numeroAgencia, numeroDoCheque, dataEmissao. to IContrato Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte #1/2)

LifeLine IContrato Message efetuarPagamento(tipoPagto, valorTotal, dataPagamento) to c1:Contrato Message fecharContrato() to c1:Contrato Message retorno to Usuario Return (Action) action detail Name : Return Message enviaDadosCobranca(nomeBanco, numeroBanco, nomeAgencia, numeroAgencia, numeroDoCheque, dataEmissao) to Cheque Message retorno to Usuario Return (Action) action detail Name : Return Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte #1/2)

LifeLine c1:Contrato Message atualizaBaseDeDados() to Pagamento Message emiteNotaFiscal(); to Pagamento Message atualizaStatusContrato(); to Pagamento Message <> to Pagamento Message retorno to IContrato Return (Action) action detail Name : Return Message <> to Cheque Message <> to Pagamento Destroy (Action) action detail Name : Destroy Message atualizaBaseDeDados() to Cheque

146
Message emiteNotaFiscal(); to Cheque Message atualizaStatusContrato(); to Cheque Message <> to Cheque Destroy (Action) action detail Name : Destroy Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte #1/2)

LifeLine Pagamento Message retorno to c1:Contrato Return (Action) action detail Name : Return Message retorno to c1:Contrato Return (Action) action detail Name : Return Message retorno to c1:Contrato Return (Action) action detail Name : Return Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte #1/2)

LifeLine Cheque Message retorno to c1:Contrato Return (Action) action detail Name : Return Message retorno to c1:Contrato Return (Action) action detail Name : Return Message retorno to c1:Contrato Return (Action) action detail Name : Return Message retorno to IContrato Return (Action) action detail Name : Return Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte #1/2) Detalhes do Diagrama de Seqncia Controlar Cobranca Parte #2/2 Diagram Content Summary
Usuario Administradora de Cartao IContratoTela c1:Contrato Fatura Cartao IPagamentoAdmCartao

Diagram Content Detail

Actor Usuario

147
Message Usuario insere dados adicionais de cobranca: numeroCartao, cartaoValidade, cartaoDigitoSeguranca. to IContratoTela Message Usuario insere dados adicionais de cobranca: razaoSocial, cnpj, endereco, telefone, contato, numeroAutorizacaoPagto. to IContratoTela Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte # 2/2)

Actor Administradora de Cartao Message retorno to IPagamentoAdmCartao Return (Action) action detail Name : Return Message retorno to IPagamentoAdmCartao Return (Action) action detail Name : Return Message retorno to IPagamentoAdmCartao Return (Action) action detail Name : Return Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte # 2/2)

LifeLine IContratoTela
Message retorno to Usuario Return (Action) action detail Name : Return Message enviaDadosCobranca(numeroCartao, cartaoValidade, cartaoDigitoSeguranca) to Cartao Message enviaDadosCobranca(razaoSocial, cnpj, endereco, telefone, contato, numeroAutorizacaoPagto) to Fatura Message retorno to Usuario Return (Action) action detail Name : Return Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte # 2/2)

LifeLine c1:Contrato Message retorno to IContratoTela Return (Action) action detail Name : Return Message atualizaStatusContrato(); to Fatura Message <> to Fatura Message <> to Cartao Message <> to Fatura Destroy (Action) action detail Name : Destroy Message atualizaBaseDeDados() to Cartao Message emiteNotaFiscal(); to Cartao Message atualizaStatusContrato(); to Cartao Message <> to Cartao Destroy (Action) action detail Name : Destroy Message emiteNotaFiscal(); to Fatura Message atualizaBaseDeDados() to Fatura Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte # 2/2)

148

LifeLine Fatura
Message retorno to c1:Contrato Return (Action) action detail Name : Return Message retorno to IContratoTela Return (Action) action detail Name : Return Message retorno to c1:Contrato Return (Action) action detail Name : Return Message retorno to c1:Contrato Return (Action) action detail Name : Return Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte # 2/2)

LifeLine Cartao Message retorno to c1:Contrato Return (Action) action detail Name : Return Message retorno to c1:Contrato Return (Action) action detail Name : Return Message retorno to c1:Contrato Return (Action) action detail Name : Return Message <> to IPagamentoAdmCartao Message validaCartao(numeroCartao) to IPagamentoAdmCartao Message enviaDadosAdministradora() to IPagamentoAdmCartao Message recebeDadosAdministradora() to IPagamentoAdmCartao Message <> to IPagamentoAdmCartao Destroy (Action) action detail Name : Destroy Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte # 2/2)

LifeLine IPagamentoAdmCartao Message validaCartao(numeroCartao) to Administradora de Cartao Message retorno to Cartao Return (Action) action detail Name : Return Message enviaDadosAdministradora() to Administradora de Cartao Message retorno to Cartao Return (Action) action detail Name : Return Message recebeDadosAdministradora() to Administradora de Cartao Message retorno to Cartao Return (Action) action detail Name : Return Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte # 2/2)

149

Anexo H Detalhes do Diagrama de Atividades Controlar Cobranca

Diagram Content Summary
InitialState Seleciona opcao de fechamento de contrato. Insere o valor e a data Escolhe o tipo de pagamento Sistema atualiza base de dados Sistema emite nota fiscal Sistema atualiza status do contrato Insere dados adicionais do cheque: numero e nome do banco, numero e nome da agencia, numero do cheque, data de emissao, data para pagamento. Insere dados adicionais da empresa: CNPJ, Razao Social, endereco, telefone, contato, numero A.P., data para pagamento, data emissao Insere dados adicionais do cartao: Validade e numero do cartao. Insere digito de seguranca Envia dados para administradora Recebe numero da transacao SynchronizationBar SynchronizationBar2 FinalState Usuario Admin. de Cartao

Diagram Content Detail

Initial State InitialState

Parent : Usuario Transition link to Seleciona opcao de fechamento de contrato.

Action State Seleciona opcao de fechamento de contrato. Parent : Usuario Transition link to Insere o valor e a data Transition link from InitialState

Action State Insere o valor e a data Parent : Usuario Transition link to Escole o tipo de pagamento Transition link from Seleciona opcao de fechamento de contrato.

Action State Escole o tipo de pagamento

Parent : Usuario

150
Transition link to Transition link from Insere o valor e a data

Action State Sistema atualiza base de dados Parent : Usuario Transition link to Sistema emite nota fiscal Transition link from

Action State Sistema emite nota fiscal Parent : Usuario Transition link to Sistema atualiza status do contrato Transition link from Sistema atualiza base de dados

Action State Sistema atualiza status do contrato Parent : Usuario Transition link to FinalState Transition link from Sistema emite nota fiscal

Action State Insere dados adicionais do cheque: numero e nome do banco, numero e nome da agencia, numero do cheque, data de emissao, data para pagamento. Parent : Usuario Transition link to Transition link from Action State Insere dados adicionais da empresa: CNPJ, Razao Social, endereco, telefone, contato, numero A.P., data para pagamento, data emissao Parent : Usuario Transition link to Transition link from

Action State Insere dados adicionais do cartao: Validade e numero do cartao. Parent : Usuario Transition link to SynchronizationBar Transition link from

Action State Insere digito de seguranca Parent : Usuario Transition link to SynchronizationBar2 Transition link from SynchronizationBar

Action State Envia dados para administradora Parent : Admin. de Cartao

151
Transition link to SynchronizationBar2 Transition link from SynchronizationBar

Action State Recebe numero da transacao Parent : Admin. de Cartao Transition link to Transition link from SynchronizationBar2

Decision Point
Parent : Usuario Transition link [dinheiro] to Transition link [faturado] to Insere dados adicionais da empresa: CNPJ, Razao Social, endereco, telefone, contato, numero A.P., data para pagamento, data emissao Transition link [cheque] to Insere dados adicionais do cheque: numero e nome do banco, numero e nome da agencia, numero do cheque, data de emissao, data para pagamento. Transition link [cartao to Insere dados adicionais do cartao: Validade e numero do cartao. Transition link from Escole o tipo de pagamento

Decision Point
Parent : Usuario Transition link to Sistema atualiza base de dados Transition link from , Insere dados adicionais da empresa: CNPJ, Razao Social, endereco, telefone, contato, numero A.P., data para pagamento, data emissao, Insere dados adicionais do cheque: numero e nome do banco, numero e nome da agencia, numero do cheque, data de emissao, data para pagamento., Recebe numero da transacao

Synchronization BarSynchronizationBar Transition link to Insere digito de seguranca Transition link to Envia dados para administradora Transition link from Insere dados adicionais do cartao: Validade e numero do cartao.

Synchronization BarSynchronizationBar2 Transition link to Recebe numero da transacao Transition link from Envia dados para administradora, Insere digito de seguranca

Final State FinalState Parent : Usuario Transition link from Sistema atualiza status do contrato

152

SwimLane Usuario
Children: InitialState, Seleciona opcao de fechamento de contrato., Insere o valor e a data, Escole o tipo de pagamento, Sistema atualiza base de dados, Sistema emite nota fiscal, Sistema atualiza status do contrato, FinalState, Insere dados adicionais do cheque: numero e nome do banco, numero e nome da agencia, numero do cheque, data de emissao, data para pagamento., Insere dados adicionais da empresa: CNPJ, Razao Social, endereco, telefone, contato, numero A.P., data para pagamento, data emissao, Insere dados adicionais do cartao: Validade e numero do cartao., Insere digito de seguranca

SwimLane Admin. de Cartao Children: Envia dados para administradora, Recebe numero da transacao

153

Anexo I Prottipos de Interface Grfica.

Figura 47: Prottipo da Tela de Abertura de Contrato.

154

Figura 48: Prottipo da Tela de Fechamento de Contrato de Locao.

155

Figura 49: Prottipo da Tela de Cadastro de Veculos.

156

Consideraes Finais
Conforme proposto no incio desse trabalho, mostrou-se a teoria atravs dos conceitos e a prtica atravs do estudo de caso, observou-se as etapas para realizar um projeto de software utilizando a orientao a objetos com UML. Pde-se constatar que a documentao do projeto muito importante para que toda a equipe envolvida no processo de desenvolvimento do sistema trabalhe em sincronismo, alcanando assim o mesmo objetivo: um sistema condizente com a necessidade do cliente. Apesar do processo de documentao consumir um tempo aparentemente desnecessrio, o qual poderia ser utilizado para efetuar outras atividades do projeto, conclui-se que a documentao gerada no decorrer desse perodo de grandssima utilidade, tanto para manter a equipe alinhada aos objetivos do projeto quanto para a evoluo do sistema. Com a elaborao desse trabalho, conclui-se que necessrio seguir um mtodo eficaz de desenvolvimento para o sistema evitando a utilizao do modelo balbrdia. necessrio emprenhar-se na anlise de requisitos para que no ocorra retrabalho, evitando assim ultrapassar o oramento do projeto e, na maioria das vezes, a data limite e com isso a perda de dinheiro e tempo, respectivamente. Constatou-se que, com a utilizao da anlise orientada a objetos, o desenvolvimento de software ficou simples, pois os objetos possuem caractersticas e aes retratando o mundo real. Pelo fato do software ser composto por objetos, facilitou a manuteno e evoluo do sistema, ficando transparente para o usurio as alteraes na implementao dos cdigos. Durante o trabalho, de acordo com o tema proposto, foi abordado apenas o projeto do software orientado a objetos com UML, em uma etapa futura ser dado seqncia a esse trabalho onde pretende-se dar nfase na implementao do sistema. Finalizando, a elaborao deste estudo foi muito gratificante principalmente, porque atravs dele, pude reforar os meus conhecimentos e assimilar novas experincias relacionadas ao projeto de software orientado a objetos.

157

Referncias Bibliogrficas
BEZERRA, Eduardo. Princpios de anlise e projeto de sistemas com UML. Rio de Janeiro: Campus, 2002.

BORGES, Jos Antonio. Projeto MOTRIX. Disponvel em: <http://intervox.nce.ufrj.br/motrix/>. Acessado em: 02/Jul/06.

BOOCH, Grady et al. UML, guia do usurio. Rio de Janeiro: Elsevier, 2000.

FERREIRA, Aurlio Buarque de Holanda. Dicionrio Aurlio Bsico da Lngua Portuguesa. Rio de Janeiro: Nova Fronteira, 1988, p. 603.

GOTTESDIENER, E., Business Rules as Requirements. Software Development, 1999. In: BEZERRA, Eduardo. Princpios de anlise e projeto de sistemas com UML. Rio de Janeiro: Campus, 2002: 70.

Guia

do

Hardware.Net.

ENIAC.

Disponvel

em

<http://www.guiadohardware.net/termos/eniac> Acessado em: 13/Jun/2006

MANDEL, T., The Elements of User Interface Design. Wiley, 1997. In: PRESSMAN, Roger S. Engenharia de Software - Ed.5. Rio de Janeiro: McGrawHill, 2002: 394.

MELO, Ana Cristina. Desenvolvendo aplicaes com UML 2.0: do conceitual implementao - 2ed. Rio de Janeiro: Brasport, 2006.

POMPILHO, S. Anlise essencial Guia prtico de anlise de sistemas. Rio de Janeiro: Infobook, 1995. In: TONSIG, Sergio Luiz. Engenharia de Software Anlise e Projetos de Sistemas. So Paulo: Futura, 2003.

158 PRESSMAN, Roger S. Engenharia de Software - Ed.5. Rio de Janeiro: McGrawHill, 2002.

SOMMERVILLE, Ian. Engenharia de Software. So Paulo: Pearson Addison Wesley, 2003.

SUN.

Java

Card.

Disponvel

em

<http://java.sun.com/products/javacard/overview.html> Acessado em: 16/Jun/2006.

TONSIG, Sergio Luiz. Engenharia de Software Anlise e Projetos de Sistemas. So Paulo: Futura, 2003.

WIKIPDIA.

Linguagem

procedural.

Disponvel

em:

<http://pt.wikipedia.org/wiki/Linguagem_Procedural>. Acessado em: 09/Jul/06.

WIKIPDIA.

Orientao

objeto.

Disponvel

em:

<http://pt.wikipedia.org/wiki/Orientao_a_objeto>. Acessado em: 09/Jul/06.

WIKIPDIA. R.A.I.D. Disponvel em: <http://pt.wikipedia.org/wiki/Raid>. Acessado em: 31/Jul/06.

WIKIPDIA.

Multiprocessamento.

Disponvel

em:

<http://pt.wikipedia.org/wiki/Multiprocessamento>. Acessado em: 31/Jul/06.

WIKIPDIA. Sistema de Gerenciamento de Banco de Dados. Disponvel em: <http://pt.wikipedia.org/wiki/SGBD>. Acessado em: 31/Jul/06.

WIKIPDIA.

Active

Server

Pages.

Disponvel

em:

<http://pt.wikipedia.org/wiki/ASP>. Acessado em: 31/Jul/06.

WIKIPDIA. Rede. Disponvel em: <http://pt.wikipedia.org/wiki/Rede> Acessado em 15/Jun/2006.

159 WIKIPDIA. Rede de computadores. Disponvel em:

<http://pt.wikipedia.org/wiki/Rede_de_computadores> Acessado em 15/Jun/2006.

WIKIPDIA. WEB. Disponvel em: <http://pt.wikipedia.org/wiki/Web> Acessado em 27/Jun/2006.

WIKIPDIA.

Brainstorming

Disponvel

em:

<http://pt.wikipedia.org/wiki/Brainstorming > Acessado em: 30/Jul/2006.

WIKIPDIA.

Carto

perfurado.

Disponvel

em:

<http://pt.wikipedia.org/wiki/Carto_perfurado> Acessado em: 13/Jun/2006

WIKIPDIA. Topologia. Disponvel em: <http://pt.wikipedia.org/wiki/Topologia>. Acessado em: 22/Ago/2006.

WIKIPDIA. Gesto de Riscos nos projetos de Software. Disponvel em: <http://pt.wikipedia.org/wiki/Gesto_de_Riscos_nos_projectos_de_Software>. Acessado em: 22/Ago/2006.

WIKIPDIA. PDA. Disponvel em:<http://pt.wikipedia.org/wiki/PDA>. Acessado em: 22/Ago/2006.

WIKIPDIA.

Abstrao.

Disponvel

em:<http://pt.wikipedia.org/wiki/Abstrao>.

Acessado em: 22/Ago/2006.

WIKIPDIA.

Plataforma

(informtica).

Disponvel

em:

<http://pt.wikipedia.org/wiki/Plataforma_(informtica)>. Acessado em: 23/Ago/2006.

WIKIPDIA.

Redundncia

(informtica).

Disponvel Acessado

em: em:

<http://pt.wikipedia.org/wiki/Redundncia_(informtica)>. 23/Ago/2006.