Professional Documents
Culture Documents
Projeto de software orientado a objetos com UML: Estudo de caso em uma locadora de veculos.
So Paulo 2006
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.
So Paulo 2006.
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.
Banca Examinadora:
_________________________________ 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.
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.
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
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
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.
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.
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
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.
) e a
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
27 um modelo baseado em dois ou mais modelos, ou ento, seja criado um novo modelo desde que as etapas bsicas sejam seguidas.
IMPLEMENTAO
IMPLANTAO
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,
Projeto
Implementao
Testes
Implantao
Manuteno
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.
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.
Validar incremento
Integrar incremento
Validar sistema
Sistema final
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
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.
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.
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.
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
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
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.
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.
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.
Tecnologia C.A.S.E.
Ferramentas
Workbenches
Ambientes
Editores
Compiladores
Comparadores de arquivos
Ambientes integrados
Anlise e projeto
Testes
Programao
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.
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.
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.
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
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 entrega
Requisitos de implementao
Requisitos de padres
Requisitos legais
Requisitos de desempenho
Requisitos de espao
Requisitos de privacidade
Requisitos de segurana
41
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.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)
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.
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
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
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
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.
49
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).
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.
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
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
Empresa
Veculo
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
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
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
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
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
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.
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.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.
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.
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.
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.
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
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.
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]
(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
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
Pessoa
Cliente
Fornecedor
Funcionrio
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
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
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.
* empregado
* empregador
Bezerra (2002: 106) explica que, uma classe associativa pode ser modificada substituindo o elemento hbrido por uma classe ordinria, conforme a figura 32.
76
Emprego
Empresa
salario dataContratacao
razaoSocial endereco
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.
77
Loja idLoja: integer vendedores: List criar() busca(idLoja) obterTotalVendas(vendedor) lanarVendas(vendedor, vendas) realizao interface Loja
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
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
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
Podemos ver esses elementos nos diagramas das figuras 39 e 40, e a explicao de cada um deles em seguida.
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
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
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.
Controlar as reservas, locaes e cobrana de um sistema de locadora de veculos. No esto inclusos os controles financeiros, contbeis.
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
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.
utilizar
sistema
de
redundncia52
R.A.I.D.53
com
multiprocessamento a ASP58;
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.
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
diferentes sistemas. Acredita-se que o treinamento de cinco dias proposto para os usurios seja o suficiente para suprir essa dificuldade operacional.
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.
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
63
89
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
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
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;
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
98
99
100
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
102
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 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
ENGINE SIZE
BODY TYPE
FUEL CAPACITY
FUEL TYPE
A A A A A A A A A
Palio Uno Mille Fiesta Ford Ka Corsa Wind Celta Twingo Clio Gol
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
TRANS. M M M M M M M M M
B B B B B B B B B
Palio Uno Mille Fiesta Ford Ka Celta Corsa Wind Clio Fox Gol
105
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
ENGINE SIZE
BODY TYPE
FUEL CAPACITY
FUEL TYPE
C C C C
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
MAKE
MODEL
E E E E E E E E
Siena Siena Siena Fiesta Sedan Corsa Sedan Maxx Corsa Sedan Clio Sedan Seat Cordoba
GRUPO
MAKE
MODEL
F F F F F F F F F
Palio Weekend Palio Weekend Palio Weekend Palio Weekend Escort Wagon Corsa Wagon FIT Parati Parati
107
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
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 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
TRANS. M M A M M M M
I I I I I I I
109
GRUPO
MAKE
J J J J J J J J J
Strada Fiorino Courier Corsa Corsa-Montana Saveiro Van Carga Saveiro Saveiro Flex
GRUPO K AUTOMATIC
MAKE
MODEL
DOORS
ENGINE SIZE
BODY TYPE
FUEL CAPACITY 55
LITER Liter
TRANS. A
Toyota
GRUPO M - KOMBI
MAKE
MODEL
DOORS
FUEL CAPACITY 46
LITER Liter
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
BODY TYPE
FUEL CAPACITY
FUEL TYPE
TRANS. M M M M M M
N N N N N N
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
Ranger EcoSport EcoSport F-250 XLT W20 S10 S10 Freelander L-200 T4 TDI 4X4
111
112
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
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
114
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
115
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
116
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
117
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
73
Semana adicional: o valor pago pelo cliente a locadora quando h atraso na devoluo do veiculo entre 1 a 3 semanas.
118
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
119
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 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 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...
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
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
Operation Summary public public public public public public public Operation Detail public abrirContrato() Return Type : public alterarContrato() Return Type : public fecharContrato()
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
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
Operation Summary public public public public Attribute Detail private tiime horaSaida private time horaDevolucao private date dataSaida private date dataDevolucao
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
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
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 :
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
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
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
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 :
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
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
Operation Summary public public public public public public public Attribute Detail private date dataPagamento private string tipoPagto private float valorTotal
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
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
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
Attribute Detail private string razaoSocial private string cnpj private string endereco private int telefone private string contato private int numeroAutorizacaoPagto
140
Operation Detail public validaCartao() Return Type : public recebeDadosAdministradora() Return Type : public enviaDadosAdministradora() Return Type :
141
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()
142
Return Type :
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
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
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
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.
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
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
154
155
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
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.
SUN.
Java
Card.
Disponvel
em
TONSIG, Sergio Luiz. Engenharia de Software Anlise e Projetos de Sistemas. So Paulo: Futura, 2003.
WIKIPDIA.
Linguagem
procedural.
Disponvel
em:
WIKIPDIA.
Orientao
objeto.
Disponvel
em:
WIKIPDIA.
Multiprocessamento.
Disponvel
em:
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:
WIKIPDIA.
Brainstorming
Disponvel
em:
WIKIPDIA.
Carto
perfurado.
Disponvel
em:
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.
Abstrao.
Disponvel
em:<http://pt.wikipedia.org/wiki/Abstrao>.
WIKIPDIA.
Plataforma
(informtica).
Disponvel
em:
WIKIPDIA.
Redundncia
(informtica).
Disponvel Acessado
em: em:
<http://pt.wikipedia.org/wiki/Redundncia_(informtica)>. 23/Ago/2006.