TCC DRUMMOND - Projeto de software orientado a objetos com UML. Estudo de caso em uma locadora de...
159
FACULDADE DE TECNOLOGIA CARLOS DRUMMOND DE ANDRADE Curso Superior de Tecnologia em Sistemas de Informação Projeto de software orientado a objetos com UML: Estudo de caso em uma locadora de veículos. Cleber Luis Marrara São Paulo 2006
Transcript of TCC DRUMMOND - Projeto de software orientado a objetos com UML. Estudo de caso em uma locadora de...
FACULDADE DE TECNOLOGIA CARLOS DRUMMOND DE ANDRADE
Curso Superior de Tecnologia em Sistemas de Informação
Projeto de software orientado a objetos com UML: Estudo de caso em uma locadora de veículos.
Cleber Luis Marrara
São Paulo 2006
2
CLEBER LUIS MARRARA
Projeto de software orientado a objetos com UML: Estudo de caso em uma locadora de veículos.
Trabalho de conclusão de curso apresentado à Faculdade de
Tecnologia Carlos Drummond de Andrade como exigência
parcial para obtenção do grau em Tecnólogo em Sistemas de
Informação.
Orientador Profº. Wilson Vendramel.
São Paulo 2006.
3
CLEBER LUIS MARRARA
Projeto de software orientado a objetos com UML: Estudo de caso em uma locadora de veículos.
Trabalho de conclusão de curso apresentado à Faculdade de
Tecnologia Carlos Drummond de Andrade como exigência
parcial para obtenção do grau em Tecnólogo em Sistemas de
Informação.
Orientador Profº. Wilson Vendramel.
Data de Aprovação ____/___/_____
Banca Examinadora:
_________________________________
Profº. Wilson Vendramel
_________________________________
Profª.
_________________________________
Profº.
4
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.
5
Agradecimentos
Agradeço em primeiro lugar a Deus por permitir que eu pudesse chegar até
aqui e fazer esse trabalho. À minha mãe e ao meu pai (in memoriam) que me
ajudaram muito durante toda a minha vida e se esforçaram para me dar o estudo
que eles não tiveram. À minha filha que, apesar de muito jovem, entendeu a minha
ausência durante esse período de estudos. À minha namorada, companheira, amiga
e futura esposa pela paciência e incentivo que me deu forças pra continuar até o fim.
E aos meus Professores e Mestres que me transmitiram sua experiência e
sabedoria.
6
"Você tem o seu caminho, eu tenho o meu.
Quanto ao caminho certo, o correto, o único,
não existe".
Nietzche
7
Resumo
Esse trabalho é um estudo de caso cujo objetivo é aplicar os conceitos de
análise e projeto de sistemas orientado a objetos para se desenvolver um software
com a finalidade de controlar o aluguel de veículos de uma locadora.
Inicialmente, o estudo apresenta conceitos relacionados às etapas de
desenvolvimento de sistemas e definições dos elementos que as compõem. Entre os
itens abordados estão conceitos de sistema de informação, engenharia de software,
análise de sistemas orientada a objetos e Linguagem de Modelagem Unificada
(Unified Modeling Language, UML).
Por fim, um estudo de caso é apresentado onde pode-se aplicar todos os
conceitos abordados.
Palavras-Chaves: Engenharia de Software, Orientação a Objetos, Modelagem de
Sistemas.
8
Abstract
This work is a study case whose objective is to apply the systems analysis
concepts and systems project objects-oriented to develop software, with purpose to
controller the vehicle rental of a company.
Initially, the study presents concepts related to the system development
stages and definitions of the elements that compose them. Among the items
approached are concepts of system of information, software engineering, oriented
systems analysis to objects and Unified Modeling Language (UML).
Finally, a study case is presented where it can be applied all of the
approached concepts.
Key-word: Software engineering, Objects-driven, Systems’ modeling.
9
Índice de Figuras e Tabelas Figuras Figura 1: Etapas de processos gerenciais ................................................................23 Figura 2: Modelo balbúrdia........................................................................................27 Figura 3: Modelo Cascata .........................................................................................28 Figura 4: Modelo incremental ....................................................................................30 Figura 5: Modelo prototipação...................................................................................31 Figura 6: Modelo espiral ............................................................................................32 Figura 7: Subdivisão das ferramentas CASE ............................................................36 Figura 8: Tipos de requisitos não-funcionais .............................................................40 Figura 9: Objeto e classe. .........................................................................................53 Figura 10:Representação de classe..........................................................................55 Figura 11: Encapsulamento.......................................................................................56 Figura 12: Herança múltipla ......................................................................................57 Figura 13: Herança....................................................................................................58 Figura 14: Polimorfismo ............................................................................................59 Figura 15: Cenário Principal ......................................................................................62 Figura 16: Cenários alternativos................................................................................63 Figura 17: Representação de fronteira do sistema....................................................64 Figura 18: Representação de uma associação .........................................................64 Figura 19: Representação de um relacionamento de Generalização........................65 Figura 20: Representação de um relacionamento Extend ........................................65 Figura 21: Representação de um relacionamento Include ........................................66 Figura 22: Multiplicidade numa associação...............................................................68 Figura 23: Representação de associação .................................................................70 Figura 24: Representação de uma associação ternária ............................................71 Figura 25: Representação de generalização.............................................................71 Figura 26: Definição de operações Polimórficas .......................................................72 Figura 27: Dependência ............................................................................................72 Figura 28: Assinatura da Dependência .....................................................................73 Figura 29: Agregação................................................................................................73 Figura 30: Composição .............................................................................................74 Figura 31: Classe Associativa ...................................................................................75 Figura 32: Classe Associativa ...................................................................................76 Figura 33: Interface usando uma classe com estereótipo ........................................77 Figura 34: Interface usando o circulo ........................................................................77 Figura 35: Diagrama de seqüência com elementos básicos. ....................................78 Figura 36: Objetos anônimos e nomeados................................................................78 Figura 37: Notação de tipos de mensagens em diagrama de seqüência..................79 Figura 38: Elementos do Diagrama de Seqüência ....................................................80 Figura 39: Elementos de Diagrama de Atividades ....................................................81 Figura 40: Aplicação de Raias de Natação (swim lanes) ..........................................82 Figura 41: Disposição das Atividades no gráfico de Gantt ........................................88 Figura 42: Diagrama de Caso de Uso – Locadora de Veículos.................................92 Figura 43: Diagrama de Classes – Locadora de Veículos ........................................97 Figura 44: Diagrama de Seqüência #1/2...................................................................98 Figura 45: Diagrama de Seqüência #2/2...................................................................99 Figura 46: Diagrama de atividade do pacote ‘Controlar Cobrança’ .........................100 Figura 47: Protótipo da Tela de Abertura de Contrato.............................................153
10
Figura 48: Protótipo da Tela de Fechamento de Contrato de Locação. ..................154 Figura 49: Protótipo da Tela de Cadastro de Veículos............................................155 Tabelas Tabela 1: Histórico dos métodos de desenvolvimento de software...........................34 Tabela 2: Classes e instâncias..................................................................................54 Tabela 3: Tabela de Atividades x Recursos Humanos..............................................88
11
Sumário Agradecimentos ..........................................................................................................5 Resumo.......................................................................................................................7 Abstract .......................................................................................................................8 Índice de Figuras e Tabelas ........................................................................................9 Introdução .................................................................................................................14 Capítulo 1. Sistema de Informação ...........................................................................17
1.1 – Definição .....................................................................................................................17 1.2 – Elementos de Sistemas de Informação ........................................................................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 – Gerência de Projeto de Software ..........................................................................22 1.3.2 – Definição do Escopo do Software ........................................................................24 1.3.3 – Planejamento das Atividades................................................................................24
1.4 – Aplicação do Software.................................................................................................25 Capítulo 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 balbúrdia..................................................................................................27 2.2.2 – Modelo cascata .....................................................................................................27 2.2.3 – Modelo incremental..............................................................................................29 2.2.4 – Modelo prototipação.............................................................................................30 2.2.5 – Modelo espiral ......................................................................................................31
2.3 – Métodos de desenvolvimento de Software ..................................................................33 2.3.1 – Análise Estruturada ..............................................................................................34 2.3.2 – Análise Essencial..................................................................................................34 2.3.3 – Análise 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 usuários ...................................................................................38 2.5.1.2 – Requisitos de sistemas ...................................................................................39 2.5.1.3 – Requisitos funcionais.....................................................................................39 2.5.1.4 – Requisitos não-funcionais .............................................................................39 2.5.1.5 – Requisitos de domínio ...................................................................................40
2.5.2 – Levantamentos de requisitos ................................................................................41 2.5.2.1 – Aplicação de questionários............................................................................41 2.5.2.2 – Verificação de documentos ...........................................................................41 2.5.2.3 – Cenários participativos ..................................................................................42 2.5.2.4 – Entrevistas .....................................................................................................42 2.5.2.5 – Observação in-loco ........................................................................................43
2.5.3 – Análise dos requisitos...........................................................................................43
12
2.5.4 – Especificação de requisitos...................................................................................44 2.6 – Projeto do Software .....................................................................................................45 2.7 – Projeto de Interface Homem-Computador (IHC)........................................................45 2.8 – Implementação do Software ........................................................................................48 2.9 – Testes do Software.......................................................................................................49 2.10 – Implantação do Software ...........................................................................................50 2.11 – Evolução do Software ................................................................................................51
Capítulo 3. Análise Orientada a Objetos com UML...................................................52
3.1 – Conceitos de Orientação a Objeto ..............................................................................52 3.1.1 - Objetos ..................................................................................................................52 3.1.2 - Classes...................................................................................................................53 3.1.3 – Métodos, operações, serviços ...............................................................................55 3.1.4 - Mensagens.............................................................................................................55 3.1.5 - Encapsulamento ....................................................................................................56 3.1.6 - Herança .................................................................................................................57 3.1.7 – Polimorfismo ........................................................................................................58
3.2 – Análise 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 – Associação (Association)...............................................................................64 3.4.1.2 – Generalização (Generalization).....................................................................64 3.4.1.3 – Extensão (Extend)..........................................................................................65 3.4.1.4 – Inclusão (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 Operações ...................................................................................68 3.4.2.4 – Relacionamentos............................................................................................70
3.4.2.4.1 – Associação..............................................................................................70 3.4.2.4.2 – Generalização .........................................................................................71 3.4.2.4.3 – Dependência ...........................................................................................72 3.4.2.4.4 – Agregação...............................................................................................73 3.4.2.4.5 – Composição ............................................................................................74 3.4.2.4.6 – Realização...............................................................................................74
3.4.2.5 – Classe de associação......................................................................................75 3.4.2.6 – Classe de Interface.........................................................................................76
3.4.3 – Diagrama de Seqüência ........................................................................................77 3.4.4 – Diagrama de Atividades .......................................................................................80
Capítulo 4. Estudo de Caso.......................................................................................84
4.1 – Definição do Ambiente e Escopo do Software ............................................................84 4.1.1 – Apresentação do ambiente .............................................................................84 4.1.2 – Declaração 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 – Análise e especificações de requisitos. ........................................................89
4.3 – Regras de negócios.................................................................................................90
13
4.4 – Diagrama de Caso de Uso .....................................................................................92 4.4.1 – Descrição dos Cenários ..................................................................................94
4.5 – Diagrama de Classes....................................................................................................97 4.6 – Diagrama de Seqüência ...............................................................................................98 4.7 – Diagrama de Atividade..............................................................................................100
Anexo B – Questionário utilizado no levantamento de requisitos............................102 Anexo C - Tabelas de Grupos de Veículos .............................................................105 Anexo D - Tabelas de Tarifas de Locação de Veículos...........................................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 Seqüência ‘Controlar Cobranca’ ..................145 Anexo H – Detalhes do Diagrama de Atividades ‘Controlar Cobranca’...................149 Anexo I – Protótipos de Interface Gráfica................................................................153 Considerações Finais..............................................................................................156 Referências Bibliográficas.......................................................................................157
14
Introdução
Durante toda a minha trajetória profissional executei trabalhos em diversas
áreas entre elas: eletro-mecânica, automação industrial, eletrônica, informática,
redes e agora a área de sistemas. Tenho gosto pela tecnologia desde pequeno e
sempre procuro aperfeiçoar-me, tornou-se um hobby e por isso escolhi o curso de
Sistemas de Informação.
Sistemas de Informação foi uma maneira de integrar tudo o que já tenho
como experiência tecnológica e também acrescentar novos conhecimentos de
sistemas computacionais. Para assimilar as técnicas de desenvolvimento de
sistemas de software escolhi um tema onde pudesse englobar itens de projeto e
análise orientada a objeto.
“Projeto de software orientado a objetos com UML: Estudo de caso em uma
locadora de veículos.” é um trabalho onde proponho mostrar como pode ser feito
uma análise desde o levantamento de requisitos até a modelagem do sistema
orientado a objetos.
Inicialmente serão passados alguns conceitos básicos sobre software1,
sistemas e aplicações para que o leitor sem muito conhecimento no assunto possa
acompanhar com mais tranqüilidade. Nos capítulos seguintes serão abordados
conceitos de engenharia de software e seus métodos e processos, Análise e
Modelagem Orientadas a Objeto com UML2 e, por último, um estudo de caso para a
implementação de um sistema em uma locadora de veículos, que visa atender
apenas as atividades operacionais no qual serão aplicados esses conceitos.
Para fazer uma comparação de como eram os sistemas de antigamente
podem-se observar os primeiros computadores e seus métodos de programação e
vê-se o quão grande foi a evolução em apenas 60 anos.
Na década de 1940 o primeiro computador, chamado ENIAC3, tinha sua
programação era feita através 6000 de chaves e a cada nova programação as
chaves precisavam ser re-programadas, por volta da mesma época, a International 1 Software é uma palavra da língua inglesa que foi incorporada à língua portuguesa como sendo um termo técnico de informática. Software é um programa que instrui ao computador o que ele deve executar. O assunto será abordado no capítulo 1. 2 Abreviação do termo em inglês 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 abreviação de Electronic Numerical Integrator Analyzer and Computer. Foi construído em 1945.
15
Business Machines Corporation – IBM criou para seu computador o método de
programação através de cartões perfurados4.
Com a evolução dos computadores, novos métodos, novas ferramentas e
novas linguagens de programação também foram aprimorados para acompanhar o
desenvolvimento do hardware5.
Na década de 1980 eram comuns empresas que construíam sistemas para
computadores sem a utilização de métodos, os projetos eram feitos de forma
desordenada, e depois de finalizado e apresentado o protótipo ao seu cliente,
verificava-se que era necessário fazer alguns acertos e perdia-se muito tempo no
trabalho de manutenção. Esse processo de criação de software é chamado de
balbúrdia 6.
Sistemas criados seguindo a prática da balbúrdia caiam em desuso devido
não atender as necessidades, ou devido ao custo de retrabalho, ou por não ter sido
planejado de forma correta com a realidade do negócio, ou por não surtir o resultado
satisfatório.
Com o surgimento da engenharia de software, o processo, seus métodos e
atividades passaram a ser utilizados na construção do software e com isso ganhou-
se mais qualidade no produto final e os processos ficaram melhor documentado. A
criação de ferramentas, métodos de desenvolvimento, estudos de uso de interface
com o operador também contribuíram para prolongar o ciclo de vida do software.
Na década de 1990 teve inicio o paradigma7 da análise orientada a objeto e
os programadores começam a ter uma nova visão de desenvolvimento e o velho
paradigma da análise estruturada foi caindo em desuso.
De acordo com Bezerra (2002: 12), no resumo abaixo pode-se ter uma idéia
da evolução das técnicas de desenvolvimento.
• Década de 1950/60: Os sistemas eram muito simples e eram
desenvolvidos com base em fluxogramas e diagramas de módulos.
4 Os cartões perfurados era a maneira de inserir dados e instruções nos computadores daquela época. 5 Hardware é uma palavra da língua inglesa que foi incorporada à língua portuguesa como sendo um termo técnico de informática. Hardware é como são chamados os componentes que compõem o computador, é a parte física. 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. “Balbúrdia” não é um método nem um modelo de desenvolvimento, e sim uma prática de desenvolvimento de software onde os desenvolvedores não se preocupam em documentar e nem seguir as práticas da Engenharia de Software. 7 Paradigma é a forma de abordar um problema.
16
• Década de 1970: Nessa época computadores mais avançados
começaram a surgir e necessitavam de sistemas mais robustos. Novos
modelos surgiram e a partir deles a programação estruturada e o projeto
estruturado.
• Década de 1980: Computadores tornam-se mais avançados e velozes,
com isso há necessidade de interfaces mais sofisticadas e softwares mais
complexos. Nesse período surge a Análise Estruturada.
• Inicio da década de 1990: É quando o novo paradigma da Análise
Orientada a Objeto surge.
• Fim da década de 1990: O novo paradigma da Análise Orientada a
Objetos começa a ganhar força e surge a UML.
No transcorrer desse trabalho poderá ser verificado como deve ser feito a
análise e o projeto orientado a objetos a qual teve inicio na década de 1990, mas
antes disso alguns conceitos e definições precisam ser estabelecidos.
O primeiro capítulo irá tratar de algumas definições: sobre o que é um
sistema, o que é uma informação, hardware e software, possibilitando entender
melhor os assuntos que serão abordados em seguida.
O capítulo dois, “Engenharia de Software”, serão tratados conceitos que
abordam a análise de sistemas, processos, métodos, ferramentas, entre outros
assuntos pertinentes ao capítulo.
No terceiro capítulo, antes de passar os conceitos de análise orientada a
objetos, serão abordados definições 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 veículos colocando em prática os
tópicos abordados anteriormente.
17
Capítulo 1. Sistema de Informação
O objetivo desse capitulo é dar algumas definições básicas sobre alguns
elementos que compõem o Sistema de Informação. Afinal, o que é um Sistema? O
que é software? Hardware? Informação e dado são a mesma coisa? E o que é
exatamente Sistemas de Informação?
Todas essas perguntas serão respondidas nesse capítulo as quais serão
muito importantes para o entendimento desse assunto como um todo.
1.1 – Definição
A palavra sistema é muito empregada em diversas áreas tais como: sistema
político, sistema de ensino ou sistema de comunicação. Por exemplo, quando se faz
um telefonema para uma empresa onde o atendente necessita consultar alguma
informação no computador e por alguma razão isso não é possível, o atendente diz:
O sistema está fora do ar.
Pode-se observar que o sistema não está somente em um computador ou em
um equipamento eletrônico; o ser humano vive em um sistema, o sistema solar
também é um sistema!
Na língua 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 relação;
2)Disposição das partes ou elementos de um todo, coordenados entre si, e que
funcionam com estrutura organizada;
3) Complexo de regras ou normas.” (AURÈLIO, 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 Informação, é necessário saber
primeiro o que é Informação. Por exemplo, uma data de nascimento de uma pessoa
18
09/04/1968 é um dado ou uma informação? Saber que a idade dessa mesma
pessoa hoje é 38 anos e que no ano que seguinte ela terá 39 anos, é um dado ou
uma informação?
“Os dados podem ser considerados características ou propriedades básicas
de algo (pessoas, documentos, objetos, situações e concatenações dessas coisas)
cujo conteúdo deve ser unívoco.“ (TONSIG, 2003: 27).
Portanto conclui-se que a data de nascimento é um dado. Seguindo essa
mesma linha de raciocínio, se junto com a data de nascimento tiverem mais dados,
por exemplo, nome, endereço, telefone, todos esses dados de forma organizada e
tratadas por algum procedimento podem trazer uma informação, tais como: a idade,
nome do cliente, endereço do cliente, telefone para contato.
Conclui-se que a informação:
• É obtida através de dados organizados de forma ordenada;
• Tem um período de validade, pois o dado pode mudar com uma certa
freqüência;
• Tem um custo para ser obtida.
Com base em todos esses conceitos, pode-se definir que Sistemas de
Informação no âmbito computacional, como sendo um conjunto de mecanismos
independentes que tratam os dados para obter informação para um fim específico.
Nas corporações os sistemas de informação devem auxiliar nas tomadas de
decisões ou até mesmo fazê-las, tem que integrar as informações que estão
isoladas, pois quanto mais informação melhor será a decisão tomada.
Resumindo: sistemas de informação é a integração de diferentes sistemas
com diversos tipos de informação para auxiliar nas tomadas de decisões ou tomar
decisões.
1.2 – Elementos de Sistemas de Informação
Agora que se tem uma melhor definição do que é sistema de informação,
observa-se que o S.I.8 é a interação de vários tipos de sistemas diferentes, os quais
são compostos por hardware, software, redes, pessoas e dados.
8 Abreviação de Sistemas de Informação.
19
1.2.1 – Hardware
A palavra hardware provém da língua inglesa e é utilizado freqüentemente no
nosso idioma quando o assunto é informática. Hardware pode ser entendido como
sendo a parte física composta por circuitos eletrônicos e outros componentes que
compõe o computador, seus periféricos e outros dispositivos eletrônicos.
Exemplificando, o hardware pode ser: mouse9, teclado, placa mãe, disco rígido,
monitor de vídeo, impressora, modem, roteador.
O hardware que tem a capacidade de processar informações possui dois
componentes muito importantes: a memória e o processador. Esses dois
componentes têm uma função muito importante: A memória armazena dados e
instruções a serem processados e o processador executa essas instruções.
Logo, pode-se observar que, com o avanço da tecnologia, o hardware torna-
se mais sofisticado a ponto de fazer tarefas programadas, ou seja, eles armazenam
e processam os dados, que de alguma forma, são convertidos em informações para
o usuário.
A peça fundamental que atua diretamente com o processador e a memória é
o programa chamado software.
1.2.2 – Software
A palavra software provém da língua inglesa e é muito utilizada na
informática. O software é a parte lógica do computador e é quem diz ao hardware o
que fazer e quando fazer, em outras palavras é um conjunto de instruções que serão
executadas pelo processador para executar uma determinada tarefa.
Existem vários tipos diferentes de software, Tonsig (2003: 54-56) explica:
• Software básico: É um programa que visa atender as necessidades
básicas do hardware, sua execução é feita para dar suporte a outros tipos
programas. Alguns exemplos de software básico são: BIOS10 do
9 Dispositivo apontador usado em sistemas baseados em janelas. Por exemplo: Microsoft Windows ™ 10 Abreviação do termo em inglês: Basic Input Output System ou Sistema Básico de Entrada e Saída. BIOS é um componente eletrônico (memória) que armazena uma pequena quantidade de dados, suficiente para fazer a programação básica do computador antes que o sistema operacional seja carregado.
20
computador, Firmware11 de periféricos, drivers12 e sistema operacional.
Especificamente nos casos do BIOS e Firmware, o software básico é um
tipo de programa de baixo nível onde as instruções são compostas por
mnemônicos (instruções de máquina), que são compiladas de acordo com
a arquitetura do processador.
O software básico é executado primeiramente para configurar as funções
básicas do hardware, para que possa ser carregado o software aplicativo.
• Software aplicativo: Para utilizá-lo é necessário que o software básico
esteja instalado para que dê suporte as rotinas e instruções do software
aplicativo. São exemplos de software aplicativo: programas editores de
texto, planilhas de cálculo, programas corporativos para suprir
necessidades administrativas. Mais de um software aplicativo pode estar
instalado no mesmo hardware, eles podem trocar informações entre si e
também pode fornecer informações para os usuários, além de se
comunicar com outro software aplicativo instalado em outro hardware,
utilizando para isso uma rede de computadores.
• Software embutido: Também conhecido como embedded systems,
podem ser utilizados em palms, celulares, computadores automotivos e
dispositivos de rede. Pode ser considerado um software básico e / ou
software aplicativo, pois esse tipo de software gerencia todas as funções
operacionais desses dispositivos.
Os dispositivos equipados com o hardware e o software não têm muita
utilidade se eles estiverem isolados uns dos outros, por isso existe a comunicação
entre eles que é feita através 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 vários tipos diferentes.
As redes de computadores podem ser de vários tipos, tamanhos e com
velocidades e tipos de conexões variadas. 11 Programa em linguagem de baixo nível que é armazenado em uma memória somente de leitura. O firmware também é um componente eletrônico (memória) que faz a programação em diversos tipos de periféricos do computador e equipamentos eletrônicos, tais como: aparelho celular, impressora, aparelho de DVD. 12 Pequeno programa para dar suporte ao software de alto nível na comunicação 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 várias
formas e recursos de vários equipamentos que podem ser interligados e
compartilhados, mediante meios de acesso, protocolos e requisitos de
segurança.” (WIKIPÉDIA. In: Redes de computadores, 2006).
Pode-se classificar as redes de acordo com a arquitetura, extensão
geográfica, topologia e o meio de transmissão:
• Arquitetura de Rede: Ethernet, Token Ring, FDDI (Fiber Distributed Data
Interface – Interface de Dados Distribuído por Fibra), Giga Ethernet, ATM
(Asynchronous Transfer Mode – Modo de Transferência Assíncrona);
• Extensão geográfica: LAN (Local Area Network), MAN (Metropolitan Area
Network), WAN (Wide Area Network);
• Topologia13: Rede em anel, ponto-a-ponto, barramento, estrela;
• Meio de transmissão: Rede por cabo coaxial, fibra ótica, par trançado,
Wireless – rede sem fios, infravermelhos, microondas.
1.2.4 – Pessoas
Cada ser humano tem comportamentos diferentes, alguns tem um bom
relacionamento interpessoal outros são mais reservados, mas para se desenvolver
um software, o fator primordial é a comunicação entre o projetista e o usuário /
cliente.
A peça-chave no desenvolvimento de software é sem dúvida o contato com o
usuário, pois ele necessitará da ferramenta que será desenvolvida, portanto ele
precisa passar as diretrizes de funcionamento.
Muitos usuários não sabem expressar o que realmente querem, outros mais
ocupados não querem perder tempo com reuniões onde serão levantados os
requisitos e passam essa responsabilidade para algum subalterno. Problemas
relacionados com a informação levam ao desenvolvimento de um software que não
13 Topologia de rede é a forma por meio da qual ela se apresenta fisicamente, ou seja, como os elementos de rede estão dispostos.
22
atende as necessidades do cliente e é por isso que a boa comunicação e um bom
relacionamento interpessoal são fundamentais.
A boa comunicação e o bom relacionamento interpessoal também são
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 são as mudanças que o novo projeto trará ao dia-a-dia
do usuário. O ser humano, de uma maneira geral, não aceita e não se adapta
facilmente às mudanças, isso é devido ao fato de que o ser humano acostuma-se
facilmente com o cotidiano (paradigma do comportamento).
Quando sugere-se ao usuário a substituição 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 informação é construído. Símbolo
intencionalmente destacado para representar uma característica ou propriedade da
realidade a ser tratada.”
Exemplificando a citação de Tonsig, podemos dizer que dados são
características de algo ou alguém tais como nome, endereço, data de nascimento de
uma pessoa, números e outros itens de um documento, propriedades de um objeto.
1.3 – O Projeto de Software
Quando existe um software para ser construído, vários profissionais estarão
envolvidos no projeto os quais terão que estar em constante sincronismo, pois a
falha ou atraso de alguma etapa poderá comprometer todo o projeto. É nessa hora
que entra em ação a figura do Gerente de Projeto.
1.3.1 – Gerência de Projeto de Software
23
O gerente de projeto não deve ter apenas conhecimentos de gerenciamento
de pessoas e operações, mas também deve deter ou buscar o conhecimento técnico
sobre o projeto, pois ele poderá ter que gerenciar uma área na qual não detém o
conhecimento, nesse caso estará colocando todo o projeto em risco. Ele
desenvolverá trabalhos de coordenação, administração, supervisão da sua equipe,
deverá levantar os riscos14 e saber como contorná-los, é responsável por manter a
equipe alinhada com os objetivos até a fase de implantação do software.
Deve, acima de tudo, saber trabalhar sobre pressão e conviver com
incertezas, e paralelamente a isso, manter um ambiente de trabalho agradável para
seus colaboradores.
Em um projeto de software o gerente de projeto deve seguir as práticas de
engenharia de software mesmo que sejam burocráticas, e ter sempre em mente que
cada projeto é diferente um do outro. Pois muitos gerentes, no intuito de agilizar o
trabalho devido à pressão 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 alteração 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 ação de um gerente de projeto é a definição do escopo do
software.
Figura 1: Etapas de processos gerenciais (TONSIG, 2003: 70) 14 Para tomar decisões eficientes, é necessário ter conhecimento dos riscos que o projeto enfrenta e claras estratégias para tratá-los ou eliminá-los. Portanto risco é tudo o que pode acontecer desde o início até o término do projeto, e que é atualmente incerto ou desconhecido.
Definição do escopo do software
Planejamento das atividades necessárias. Criação de cronograma.
Organização e Controle. Locação de recursos para atividade e coordenação.
Checagem do Realizado X Previsto. Documentação de desvios
24
1.3.2 – Definição do Escopo do Software
O escopo do software deve ser bem definido com o cliente, deve-se saber
tudo sobre que o software deverá fazer, em qual ambiente ele será instalado,
quantos usuários irão acessá-lo e de que maneira, detalhes do hardware onde o
software será executado.
Tonsig (2003: 110), explica que é na fase de definição do escopo que o
gerente de projeto deverá fazer uma estimativa do custo do software, quantidade de
recursos envolvidos no projeto e o prazo de entrega do software. Para isso é
necessário saber quais são as viabilidades do projeto:
• Viabilidade técnica: São verificadas a existência de hardware, software e
pessoas com conhecimento técnico disponível para atender os requisitos
de sistema.
• Viabilidade operacional: Diz respeito às conseqüências na implantação ou
modificação de processos da organização ou sociedade.
• Viabilidade econômica: Será verificado se é viável o custo da solução
encontrada.
Algumas vezes o projeto do software pode tornar-se inviável devido ao fator
custo, técnico ou operacional, mas nesse caso é o cliente quem decide pela
viabilidade ou não do projeto. Uma vez definida a viabilidade do projeto a próxima
etapa é o planejamento das atividades.
1.3.3 – Planejamento das Atividades
O planejamento pode ser representado de várias formas gráficas onde se
devem alocar os recursos, o tempo gasto para cada atividade, a descrição da
atividade, o custo dessa atividade, quando começa e quando termina.
Tonsig (2003: 73) explica que, no planejamento, deve-se definir sobre cada
atividade:
• Uma descrição sobre ela (O QUE);
• As devidas justificativas (POR QUE);
• Quais recursos serão alocados para cada atividade (QUEM);
25
• Definir a ordem que cada atividade deve ser realizada (QUANDO);
• Qual técnica deve-se empregar (COMO);
• O local da sua realização (ONDE).
Todos os itens citados acima pode-se dispor na forma de um diagrama onde
observar-se facilmente quais são as tarefas, quem são os recursos, quando
começam e quando terminam cada tarefa.
1.4 – Aplicação do Software
Como visto no item 1.2.1 o hardware tem varias aplicações, porém sem o
software o hardware não tem utilidade. Ao unir as funcionalidades do hardware com
as diretrizes do software pode-se criar um produto com várias aplicações. A
aplicação mais usual são os aplicativos para computadores pessoais.
As quantidades e tipos de aplicações do software são vastos e são limitados
apenas pela tecnologia e pela criatividade dos projetistas. Pode-se citar alguns
exemplos de tecnologias aplicadas ao uso do software: dispositivos móveis como
Assistente Pessoal Digital (Personal Digital Assistants, PDA ou Handhelds),
celulares, programas armazenados e executados em cartões (Java Card 15) e a
interconexão entre equipamentos diversos para troca ou envio de informações.
15 Cartão do tipo Smart Card, com pouca memória, que tem capacidade para armazenar pequenos programas em Java permitindo sua execução através de um dispositivo externo. Ex.: Chip para celular com tecnologia GSM.
26
Capítulo 2. Engenharia de Software
A primeira menção à engenharia de software ocorreu em 1968 quando ainda
não utilizava-se de processos para a criação de software. Foi a época em que
começaram a surgir computadores mais avançados e complexos e observou-se que,
se continuasse a utilizar os métodos de desenvolvimento de software antigos, o
avanço do software não acompanharia o hardware.
O custo do desenvolvimento do software crescia enquanto que o custo do
hardware caia, foi então necessário uma revisão nos métodos e processos de
desenvolvimento de software.
2.1– O que é Engenharia de Software
A engenharia de software é similar à engenharia voltada a outras áreas, tem
como objetivo criar processos, normatizações, novas abordagens e documentos
envolvidos no desenvolvimento de software.
A engenharia de software é “...uma disciplina da engenharia, cuja meta é o
desenvolvimento de sistemas de software com boa relação custo / beneficio.”
(SOMMERVILLE, 2003: 3)
2.2 – Processo de desenvolvimento de Software
O processo de desenvolvimento é composto por etapas que são executadas
por engenheiros, analistas e programadores. Em cada etapa são executados
diferentes tipos de atividades onde, ao término de todo o processo, é desenvolvido
um produto (software) que é implantado.
Genericamente, as etapas de desenvolvimento de software, podem ser
divididas em fases: análise de requisitos, projeto, desenvolvimento, implantação e
manutenção. Existem vários modelos ‘padrões’ para o processo de desenvolvimento
de software que foram criados baseados em outros processos de engenharia.
Os modelos mais comuns são: balbúrdia, cascata, incremental, prototipação e
espiral. Mas nada impede que, em um processo de desenvolvimento, seja seguido
27
um modelo baseado em dois ou mais modelos, ou então, seja criado um novo
modelo desde que as etapas básicas sejam seguidas.
2.2.1 – Modelo balbúrdia
Dos modelos apresentados, o modelo balbúrdia16 é o único modelo que nunca
deve ser tomado como referência. Nesse modelo não há planejamentos nem
documentação dos processos, e a constante mudança no software para atender
novos requisitos torna esse modelo, como o próprio nome diz, uma balbúrdia.
O processo de desenvolvimento de software é um constante retrabalho onde
existe a implementação e em seguida a implantação, e volta-se novamente para a
implementação por não ter atendido os requisitos e / ou as necessidades funcionais.
O diagrama desse processo é representado na figura abaixo.
Figura 2: Modelo balbúrdia (TONSIG, 2003: 58)
2.2.2 – Modelo clássico ou cascata
“O primeiro modelo publicado do processo de desenvolvimento de software
originou-se de outros processos de engenharia” (ROYCE, 1970. In: SOMMERVILLE,
2003: 37).
16 Termo adotado por Tonsig (2003: 57) para retratar a maneira desorganizada com que algumas empresas e desenvolvedores criam seus sistemas. “Balbúrdia” não é um método nem um modelo de desenvolvimento, e sim uma prática de desenvolvimento de software onde os desenvolvedores não se preocupam em documentar e nem seguir as práticas da Engenharia de Software.
IMPLANTAÇÃO
IMPLEMENTAÇÃO
28
No modelo cascata os processos acontecem seqüencialmente, esse processo
de desenvolvimento é ideal para situações onde os requisitos são bem definidos e
compreendidos. Pelo fato dos processos acontecerem seqüencialmente, uma fase
começa quando a etapa anterior termina.
Conforme a figura abaixo, nesse modelo encontramos as fases de análise de
viabilidades, definição de requisitos, projeto de sistema e de software,
implementação, testes, implantação e manutenção.
Figura 3: Modelo Cascata (TONSIG, 2003: 59)
O processo de análise de viabilidade é onde será obtida uma idéia básica 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 usuário, meio de
armazenamento de dados, interligação entre os sistemas).
É na implementação que ocorre a programação propriamente dita, seguida
pelos testes e implantação do sistema como um todo. É na implantação que o
sistema entra em produção e os usuários começam a utilizá-lo, e é onde são
Análise de viabilidades
Análise de requisitos
Projeto
Implementação
Testes
Implantação
Manutenção
29
verificados se todos os requisitos implementados atendem as necessidades que
foram inicialmente levantadas. Também é possível que apareçam novas falhas de
projeto nessa fase.
Por ser um modelo seqüencial, é 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 vários 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 funções poderão não funcionar de
acordo com as necessidades do usuário.
Todas as falhas, tanto as que foram deixadas durante o processo, quanto as
demais falhas encontradas na fase de implantação, serão corrigidas na fase de
manutenção.
2.2.3 – Modelo incremental
“A abordagem do desenvolvimento incremental (...) foi sugerida por Mills”.
(Mills et al., 1980. In: SOMMERVILLE, 2003: 43).
O modelo incremental é uma variação do modelo cascata e tem como objetivo
diminuir o retrabalho. Nesse modelo os desenvolvedores não têm uma visão
detalhada do que será o software como um todo, pois ele é divido em várias partes
de acordo com o grau de prioridade de entrega, as mais prioritárias são entregue
primeiro, e depois as menos prioritárias. A prioridades são definidas em reuniões
com o cliente juntamente com os prazos de entrega para cada parte do sistema.
Os primeiros incrementos servem como um protótipo para o usuário se
familiarizar com o sistema e ajudam os projetistas coletar de novos requisitos. Com
base nesses requisitos, um novo incremento será criado e disponibilizado na
próxima versão.
Sempre que novas funcionalidades são adicionadas um novo incremento ao
software é criado e disponibilizado ao usuário. Dessa forma, o usuário não precisa
esperar o término de todo o desenvolvimento para começar a utilizar o software, e
por outro lado, ele vai sendo testado à medida que novos requisitos menos
importantes vão sendo incrementados.
30
Uma vantagem desse modelo é que, para iniciar o desenvolvimento, não é
necessário ter em mãos todos os requisitos como no modelo cascata, aos poucos,
os requisitos serão adicionados nos incrementos à medida que vão surgindo. Outra
vantagem é, devido aos incrementos mais importantes terem sido entregues
primeiro, eles são testadas por um tempo maior pelo usuário o que diminui falhas.
Uma das desvantagens desse modelo é o fato do software ser dividido em
partes, pois não se consegue visualizar quais serão as funcionalidades que o cliente
deseja implantar, sendo assim, fica difícil criar incrementos sem saber se a
funcionalidade de uma parte poderá, ou não, ser usada por outra. Isso poderá
ocasionar problemas, onde alguma funcionalidade não atenda as necessidades dos
usuários.
Figura 4: Modelo incremental (SOMMERVILLE, 2003: 43)
2.2.4 – Modelo prototipação
No modelo de prototipação tem como objetivo diminuir o tempo de produção
do software e dar ao usuário uma visão mais realista do que está sendo construído,
fazendo com que ele participe do desenvolvimento opinando sobre os
desenvolvimentos das telas e relatórios. Isso faz com que o usuário / cliente se torne
co-responsável pelo produto final.
Seguindo o fluxo abaixo pode-se analisar o que o modelo prototipação
propõe.
Definir esboço dos requisitos
Atribuir requisitos aos incrementos
Projetar arquitetura do sistema
Desenvolver incremento do sistema
Validar incremento
Integrar incremento
Validar sistema
Sistema final
Sistema incompleto – novo requisito / funcionalidade
31
Figura 5: Modelo prototipação (TONSIG, 2003: 61)
Como pode-se observar, nesse modelo, tem como etapa inicial a análise de
requisitos e também a definição das telas e relatórios onde o usuário teve
participação. Diferente do modelo incremental, o usuário não poderá operar o
sistema até o final do projeto.
Após passar por várias experimentações e revisões, o protótipo é
aperfeiçoado, passa pela etapa de codificação, testes e só então é implantado.
É conveniente deixar o usuário ciente de que a codificação do software não é
tão rápida e simples como o projeto da tela e relatórios, pois o software em si
necessita ser codificado. Isso pode gerar uma ansiedade por parte do usuário.
2.2.5 – Modelo espiral
Sommerville (2003: 44) diz que o modelo de processo de desenvolvimento em
espiral foi proposto por Boehm em 1988.
O modelo espiral reúne as vantagens dos modelos mais antigos. Ele tem um
formato espiralado e é dividido em quatro quadrantes, cada quadrante representa
uma etapa: Determinar objetivos, Avaliação de alternativas e riscos,
Desenvolvimento e verificação de produto, Avaliação e planejamento. O processo
inicia-se no centro do espiral e percorre as diversas etapas no sentido horário.
Análise de requisitos
Desenvolvimento de protótipo
Experimentação
Revisão
Detalhamento Codificação e testes
Implantação Manutenção
32
No 1º quadrante, é feita a análise de requisitos e de viabilidades, os objetivos
são definidos e os riscos são relacionados.
No 2º quadrante, são avaliados os riscos e, dependendo do nível de
abstração17 dos requisitos levantados na etapa anterior e dos riscos envolvidos,
pode-se implementar o modelo prototipação para obter requisitos mais detalhados.
Nesse caso um protótipo do software é desenvolvido referente a abstração em
questão.
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, pode-
se adotar outros modelos e implementá-los no espiral. Por exemplo, se os requisitos
forem bem definidos pode-se utilizar o modelo cascata.
Figura 6: Modelo espiral (SOMMERVILLE, 2003: 45)
No 4º quadrante, o trabalho realizado durante esse ciclo é apresentado ao
cliente para validação e um planejamento para o próximo ciclo é definido.
17 Abstração é o processo mental em que as idéias estão distanciadas dos objetos, operação intelectual onde existe o método que isola os generalismos teóricos dos problemas concretos, trata-se de um mecanismo essencial em disciplinas filosóficas e científicas.
33
Finalizando o ultimo quadrante, há uma iteração do processo para os ciclos
seguintes e o desenvolvimento segue um processo evolutivo.
A quantidade total de ciclo não é especificada e depende de cada projeto de
software.
2.3 – Métodos de desenvolvimento de Software
A abordagem desse trabalho está focada na análise orientada a objetos,
portanto, não será explicado em detalhes todos os métodos de desenvolvimento
citados.
Em muitos projetos, as informações obtidas geram muitos documentos. Ao
iniciar a etapa de codificação e desenvolvimento propriamente dita, pode haver
algumas modificações no projeto original e, devido a falta de controle, essas
modificações são implementadas diretamente no software, mas algumas vezes, não
são acrescentadas nas documentações do projeto. Resultado: Ao final do projeto
temos a documentação desatualizada.
Sommerville (2003: 49) conclui que a utilização de métodos estruturados
garante a criação de uma documentação padrão para o projeto.
Antes de fazer uma descrição dos métodos de desenvolvimento de software,
na tabela abaixo pode-se observar um resumo do histórico mostrando os métodos e
técnicas de desenvolvimento de software.
Modelo Abordagem Ferramentas
Balburdia (Informal)
Desde o inicio dos anos 50 (até hoje
em alguns casos), porém, sem outra
alternativa até o início da década de
70.
Funcionalidade (com
maior enfoque) e dados
Textos
Fluxogramas
Estruturado
O método começou efetivamente a
ser empregado a partir de 1975 e
deverá ainda continuar sendo
utilizado por mais alguns anos pelas
empresas que possuem estruturas de
Inicialmente a
funcionalidade e depois
os dados.
Posteriormente, com a
maturidade das
ferramentas de SGBD18,
Diagrama de Fluxo de Dados
(DFD)
Especificação dos processos
Diagrama de Entidade
Relacionamento (DER)
Normalização
18 SGBD é a sigla de Sistema Gerenciador de Bando de Dados.
34
sistemas concebidas a partir desse
modelo, que ainda se encontra ativos.
os dados ganham mais
ênfase.
Diagrama de Estrutura de Dados
(DED)
Dicionários de Dados
Essencial
Trata-se de um aprimoramento do
modelo estruturado que teve início em
1984.
Essência Funcional e
Dados
Integração Funcional e
Dados
DFD de Contexto
Lista de Eventos
DFD Particionado por Eventos
Diagrama Entidade
Relacionamentos
Diagrama de Estrutura de Dados
Normalização
Dicionários de Dados
Orientado a Objetos
Decorrente dos conceitos já
existentes nas linguagens de
programação, especialmente na
‘Simula(67)’ e ‘Smaltalk(70)’.
A aplicação na análise de sistemas
teve início na década de 90.
Funcionalidade Objeto =
Encapsulamento de
Funções e Dados
Contempla o estado de
um objeto
Visão estática e
dinâmica
Diagrama de Caso de Uso
Diagrama de Classes e Objeto
Diagrama de Seqüência
Diagrama de Colaboração
Diagrama de Componentes
Diagrama de Distribuição
Tabela 1: Histórico dos métodos de desenvolvimento de software (TONSIG, 2003: 105)
2.3.1 – Análise Estruturada
Tonsig (2003: 107) diz que a análise estruturada propõe uma metodologia de
construção de sistema que inicia-se com uma visão global e vai aprofundando para
níveis de detalhamento mais específicos. Utiliza-se de: Diagramas de Fluxo de
Dados (DFD) dispostos em vários níveis, o primeiro nível tem uma visão macro,
quanto mais se aprofunda nos níveis subseqüentes, maior é o de detalhamento; o
Diagrama de Entidade Relacional (DER) é uma ferramenta que auxilia a fazer o
modelo conceitual do Banco de Dados.
2.3.2 – Análise Essencial
A análise essencial surgiu da analise estruturada e tem como objetivo estudar
um sistema ideal sem se prender às restrições tecnológicas, para isso imagina-se
um sistema ideal.
35
Tonsig (2003: 126) explica que esse estudo é feito para o levantamento das
funcionalidades do sistema e, baseado nesse levantamento, um modelo essencial
dessas funcionalidades é desenvolvido.
2.3.3 – Análise Orientada a Objetos
O método de desenvolvimento orientado a objetos propõe um novo
paradigma no desenvolvimento de software. Tonsig (2003: 165) explica que
enquanto o método estruturado trabalha com as funcionalidades e modelagem de
dados separadamente, a análise orientada a objetos tem uma visão única e trabalha
com as funcionalidade e modelagem de dados ao mesmo tempo.
Uma abordagem mais detalhada sobre a análise orientada a objetos será
visto no capitulo 3.
2.4 – Ferramentas de desenvolvimento de Software
A engenharia de software sempre construiu diversos tipos de software para
auxiliar muitos tipos de usuários e automatizar vários tipos de processos, mas até
então os profissionais envolvidos no desenvolvimento de software não tinham
ferramentas próprias que os auxiliassem no desenvolvimento dos mesmos. É como
um dito popular: “Na casa de ferreiro o espeto é de pau”.
Foi então que desenvolveu-se um tipo de ferramenta para ajudar no processo
de desenvolvimento de software. Essas ferramentas são chamadas de
“Ferramentas C.A.S.E.19” que são 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 três categorias:
• Ferramentas;
• Workbenches20;
• Ambientes.
19 A palavra C.A.S.E. é uma abreviação do termo em inglês “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 serão verificadas e validadas as funcionalidades do software.
36
Na figura 7, pode-se observar melhor como essas categorias são
subdivididas.
Figura 7: Subdivisão das ferramentas CASE. (SOMMERVILLE, 2003: 56)
De acordo com Pressman (2002: 810), as ferramentas C.A.S.E. podem ser
classificadas de acordo vários aspectos. Abaixo tem-se uma relação da sua
classificação pela função:
• Ferramenta de engenharia de processo de negócio;
• Ferramenta de modelagem e gestão de processo;
• Ferramenta de planejamento de projeto;
• Ferramenta de análise de risco;
• Ferramenta de gestão de projeto;
• Ferramenta de rastreamento de requisitos;
• Ferramenta de métricas e gestão;
• Ferramenta de documentação;
• Ferramenta de software básico;
Tecnologia C.A.S.E.
Editores
Compiladores
Comparadores de arquivos
Ambientesintegrados
Ambientes centrados em
processo
Workbenches
Ambientes
Ferramentas
Análise e projeto
Programação
Testes
Workbenches com vários métodos
Workbenches com método único
Workbenches de propósito geral
Workbenches de linguagem específica
37
• Ferramenta de garantia de qualidade;
• Ferramenta de gestão de base de dados;
• Ferramenta de gestão de configuração de software;
• Ferramenta de análise e projeto;
• Ferramenta PRO/SIM (Prototipação e Simulação);
• Ferramenta de projeto e desenvolvimento de interfaces;
• Ferramenta de prototipação;
• Ferramenta de programação;
• Ferramenta de desenvolvimento WEB21;
• Ferramenta de integração e teste;
• Ferramenta de análise estática;
• Ferramenta de análise dinâmica;
• Ferramenta de gestão 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 função é muito
útil para o processo de produção de software.
2.5 – Requisitos de software
Uma vez analisado a viabilidade do projeto, o trabalho de desenvolvimento do
software inicia-se com levantamento de diversos tipos informações as quais
auxiliaram todo o trabalho de desenvolvimento. O conjunto de informações, tais
como: as funcionalidades e restrições do software, as necessidades do cliente,
funcionalidade dos processos e documentos internos da empresa, dão-se o nome de
requisitos.
Os requisitos são as peças fundamentais, auxiliam o analista no entendimento
do funcionamento do software que será projetado. Por isso, se os requisitos forem
mal interpretados, omitidos, ou não condizerem com a verdade, o projeto não
atenderá as necessidades do cliente / usuário.
21 Abreviação de World Wide Web. É uma rede mundial de computadores que fornece informação em forma de hipertexto, também chamada de Internet.
38
Os requisitos são classificados em vários tipos e existem diversas técnicas de
se obter do cliente o que ele realmente necessita.
2.5.1 – Tipos de requisitos
Segundo Sommerville (2003: 82), pode-se dividir e resumir os requisitos da
seguinte forma:
• Requisitos de usuários: São declarações em linguagem natural sobre as
funções do sistema.
o Requisitos funcionais: Descreve em linguagem natural as
funcionalidades do sistema.
o Requisitos não-funcionais: Descreve em linguagem natural os
requisitos que não diz respeito as funcionalidades do sistema.
• Requisitos de sistemas: Estabelece detalhadamente as funções e
restrições do sistema. Podem ser subdivididos em:
o Requisitos funcionais: Descreve as funcionalidades do sistema.
o Requisitos não-funcionais: Não diz respeito as funcionalidades do
sistema.
o Requisitos de domínio: Descreve as características do domínio.
Pode-se ver a seguir uma definição mais detalhada de cada um desses
requisitos.
2.5.1.1 – Requisitos de usuários
Os requisitos de usuários devem descrever, em uma linguagem
compreensível pelos usuários, os requisitos funcionais (funcionalidades do sistema)
e os requisitos não-funcionais, mas não deve-se evitar entrar em detalhes técnicos
no que diz respeito ao desenvolvimento do software.
O fato dos requisitos serem escritos em um tipo de linguagem natural (não
técnica) poderá trazer alguns problemas, tais como: a falta de clareza e
interpretação do requisito, misturar os requisitos funcionais com os não-funcionais ou
até relacionar um ou mais requisitos em um só.
39
2.5.1.2 – Requisitos de sistemas
As especificações dos requisitos de sistemas são mais abrangentes e mais
detalhadas do que os requisitos de usuários. Os “...requisitos de sistema deveriam
definir o que o sistema deveria fazer, e não como ele teria de ser implementado.”
(SOMMERVILLE, 2003: 91).
A linguagem natural é utilizada para descrever esse tipo de requisito e pode
servir como base para o contrato de desenvolvimento e implementação do sistema.
É necessário incluir o máximo de informações possíveis, pois isso pode ajudar aos
analistas a definir uma arquitetura inicial do sistema e a fornecer requisitos
adicionais no caso de sistemas coexistentes que necessitem de integração ao novo
sistema.
2.5.1.3 – Requisitos funcionais
Os requisitos funcionais devem relacionar de forma consistente e completa
todas as funcionalidades, serviços e necessidades do cliente / usuário para o
sistema que será desenvolvido. Quando trata-se de requisitos de usuário os
requisitos funcionais são escritos em linguagem natural de fácil compreensão pelos
usuários, mas quando trata-se de requisitos de sistemas os requisitos funcionais
devem especificar as funções, as exceções e demais processos em detalhes.
2.5.1.4 – Requisitos não-funcionais
Requisitos não-funcionais estão relacionados com aspectos de confiabilidade,
tempo de resposta, tamanho ocupado em memória, espaço em disco, portabilidade
do sistema. Também podem especificar restrições do sistema.
Em geral, os requisitos não-funcionais fornecem informações do sistema
como um todo, já os requisitos funcionais especificam características individuais ou
parciais do sistema. Portanto, isso torna o requisito não-funcional mais importante
que o funcional. A conseqüência da falha na implementação de um requisito
funcional será a inoperabilidade de uma função ou conjunto de funções, se isso
acontecer em um requisito não-funcional o sistema pode torná-lo inutilizado.
40
Na figura 8, podem-se observar os vários tipos de requisitos não-funcionais
que podem surgir.
Figura 8: Tipos de requisitos não-funcionais (SOMMERVILLE, 2003: 85)
2.5.1.5 – Requisitos de domínio
Os requisitos de domínio podem ser funcionais ou não-funcionais e estão
relacionados com dados e informações específicas sobre o ambiente em que o
sistema vai operar, o analista deve ter conhecimento e o domínio das informações
do ambiente em questão. Esses tipos de requisitos “... podem ser novos requisitos
funcionais em si, podem restringir os requisitos funcionais existentes ou estabelecer
como devem ser realizados cálculos específicos.” (SOMMERVILLE, 2003: 88).
Requisitos não-funcionais
Requisitos organizacionais
Requisitos externos
Requisitos do
produto
Requisitos de
eficiência
Requisitos de confiabilidade
Requisitos de portabilidade
Requisitos de
interoperabilidade
Requisitos éticos
Requisitos de facilidade
de uso
Requisitos de
desempenho
Requisitos de
espaço
Requisitos de entrega
Requisitos de
implementação
Requisitos de
padrões
Requisitos legais
Requisitos de
segurança
Requisitos de
privacidade
41
2.5.2 – Levantamentos de requisitos
O levantamento de requisitos consiste em obter do usuário / cliente as
informações, dados, e processos relativos ao sistema de forma que o analista possa
entender o que se pretende desenvolver e saber o que o usuário / cliente quer que o
software faça. “Conhecer com exatidão o ambiente do usuário, sua forma de
trabalho, a estrutura da organização, os problemas e as necessidades a serem
supridas pelo novo sistema é fundamental para o processo de desenvolvimento de
software.” (TONSIG, 2003: 94).
Pode-se citar algumas maneiras de como coletar esses requisitos:
• Aplicação de questionários;
• Verificação de documentos;
• Cenários participativos;
• Reuniões e entrevistas;
• Observação in-loco 22.
2.5.2.1 – Aplicação de questionários
A técnica de aplicação de questionários tem um custo baixo para o
desenvolvedor, porém não é um bom recurso de levantamento de requisitos por
limitar requisitos adicionais que por ventura o usuário possa fornecer.
Dependendo da forma que o questionário for aplicado, suas questões podem-
se tornar muito cansativas e pouco especificas.
2.5.2.2 – Verificação de documentos
A verificação de documentos é uma boa técnica na aquisição de requisitos
para o desenvolvimento de software, desde que, seja agregada a alguma outra
técnica de levantamento de requisitos. São muito úteis para levantar, dentre os
dados utilizados nos processos, quais tem realmente alguma importância ou se está
faltando algum dado adicional que não esteja sendo requisitado nos documentos.
22 Termo em inglês cujo significado quer dizer “no lugar”. No contexto entende-se “no ambiente”.
42
Como por exemplo, um formulário de requisição onde pode haver campos ou
lacunas que nunca foram utilizados ou sua inexistência para alguma informação
essencial ao processo que nunca fora solicitado.
2.5.2.3 – Cenários participativos
Em uma empresa, muitas vezes têm-se várias pessoas envolvidas em
processos onde, por sua vez, cada uma detém uma parte da informação. E, algumas
vezes, o responsável pelo departamento pode não dominar todos os processos.
Nesses casos fica difícil para o analista unir todas essas informações
desencontradas para ter uma visão detalhada do processo como um todo.
Para isso, o analista pode utilizar a técnica de cenários participativos tais
como: brainstorming23 (“tempestade de idéias”) e JAD (Joint Application Design –
Reuniões de Projeto) que nada mais são do que reuniões entre os usuários / cliente
e desenvolvedores e demais envolvidos no projeto.
Em uma sessão utilizando a técnica JAD, participam: líder da sessão;
especialistas nos assuntos técnicos e do negócio do cliente; executivo responsável /
patrocinador; representantes dos usuários; gerente de projeto; observadores
passivos e ativos (podem opinar); responsável por documentar os requisitos
levantados nas reuniões.
São realizados várias sessões onde serão discutidos com todas as pessoas,
ou seus representantes, envolvidas nos processos da organização. Dessa forma fica
mais produtivo o trabalho de levantamento de requisitos e pode-se evitar conflito,
falta ou equívoco de informações.
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 idéias") mais que uma técnica de dinâmica de grupo é uma atividade desenvolvida para explorar a potencialidade criativa do indivíduo, colocando-a a serviço de seus objetivos. Quando se necessita de respostas rápidas a questões relativamente simples, o brainstorming é uma das técnicas mais populares e eficazes. Disponível em: <http://pt.wikipedia.org/wiki/Brainstorming>.
43
informações da forma mais clara possível e, coletar de documentos utilizados pelo
usuário os quais auxiliarão os analistas no desenvolvimento da solução.
Quando o assunto necessitar de requisitos mais detalhados o ideal é
entrevistar o funcionário que trata do respectivo assunto, tomando alguns cuidados
ao fazer entrevistas, tais como:
• Conversar com o responsável de um determinado setor antes de
entrevistar o funcionário, pois deve-se seguir a hierarquia da organização;
• Verificar com o funcionário entrevistado a sua disponibilidade de horário e,
durante a entrevista, não tomar mais tempo do que o combinado;
• Sempre verificar se o entrevistador entendeu todas as informações que o
funcionário tentou passar.
Lembre-se que “... a pessoa é a especialista no que faz e você apenas busca
informações.” (TONSIG, 2003: 100)
2.5.2.5 – Observação in-loco
Aliada a entrevista, a observação in-loco auxilia no levantamento de requisitos
durante as atividades no dia-a-dia do cliente por um período de alguns dias. Isso
permite observar detalhes que não seriam possíveis de serem abordados em uma
entrevista. A observação in-loco também pode ser adotada para esclarecer dúvidas
sobre algum requisito levantado durante uma entrevista.
Em questões que envolvem planejamentos estratégicos, não cabe a
observação in-loco como método para levantamento de requisitos, pois nesse caso
as ações são planejadas independentes dos processos. Nesse caso o analista deve
estar ciente desse fato, pois o software deverá executar o que se planeja.
2.5.3 – Análise dos requisitos
A análise de requisitos, também conhecida como especificação de requisitos,
é a fase onde, de posse dos requisitos levantados anteriormente, tenta-se unir todas
as necessidades do cliente na construção de um modelo que irá servir de base para
desenvolver o sistema.
44
Nessa fase, ao analisar os requisitos e desenvolver um sistema que atenda
as necessidades do cliente, não são analisados os ambientes tecnológicos onde o
sistema irá atuar. Primeiro “É necessário saber o que o sistema proposto deve fazer
para, então, definir como esse sistema irá fazê-lo.” (BEZERRA, 2002: 24)
Basicamente dois tipos de modelos serão 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 validação garante que
as necessidades e funcionalidades que o cliente necessita estão sendo atendidas, e
a verificação garante que os requisitos estão sendo atendidos.
A análise pode ser feita através de vários métodos de desenvolvimento de
software, como por exemplo: estruturado, essencial e orientados a objetos. Uma
abordagem mais detalhada sobre análise orientada a objetos pode ser visto no
capítulo 3, os demais métodos não serão abordados nesse trabalho.
2.5.4 – Especificação de requisitos
A especificação de requisitos é realizada quando a tarefa análise encontra-se
no auge de suas atividades. Nesta etapa, as funções de sistema, levantadas
anteriormente, são refinadas e documentadas em detalhes, são especificadas metas
e objetivos que o software deverá tratar.
Tudo será incorporado ao planejamento do desenvolvimento do software
juntamente com as especificações das funcionalidades para cada necessidade
levantada ou apresentada pelo cliente. Também serão definidos quais serão os
critérios de validação (testes). Os tipos de testes são apresentados no item 2.9.
O documento criado acompanha: bibliografia contendo documentos
relacionados ao software, documentos de referência técnica, informação sobre
fornecedores, e apêndice com informações adicionais. Um eventual protótipo
executável do software e uma versão preliminar do manual do usuário também
podem acompanhar o documento.
O planejamento de desenvolvimento do software é entregue para análise e
ciência do cliente. A partir desse ponto, qualquer outro requisito ou mudança no
software acarretará em mudança 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 não será abordado a modelagem de dados.
45
2.6 – Projeto do Software
Na etapa de desenvolvimento, os aspectos tecnológicos, que até então foram
deixados de lado, passam a ter sua verdadeira importância no projeto. É no projeto
que define-se como o software atenderá os requisitos levantados, e ao mesmo
tempo, respeitando os limites tecnológicos.
Dependendo do tipo de análise adotada, estruturada ou orientada a objetos,
diferentes ferramentas de trabalho no projeto do software serão utilizadas. Pode-se
adotar que teremos basicamente: projeto da base de dados, projeto da arquitetura
do sistema, projeto de interface.
2.7 – Projeto de Interface Homem-Computador (IHC)
De acordo com Pressman (2002: 393), o projeto de interface do homem com
o computador visa criar meios para que o usuário interaja e se comunique com o
sistema. O objetivo do projeto é identificar objetos e suas ações para a criação de
uma tela de sistema seguindo um conjunto de princípios de projeto.
Cada tipo diferente de sistema apresenta uma interface própria. Quando trata-
se de usuários com deficiências físicas o tipo de interface necessita ser bem
elaborada. Projetos de interfaces baseados em comando de voz já é uma realidade
no Brasil que auxiliam portadores de deficiência na utilização do computador 25.
“O projeto de interface focaliza três áreas de preocupação: (1) o projeto de
interface entre componentes do software, (2) o projeto de interfaces entre o
software e outros produtores e consumidores de informação não-humanos (i.
e., outras entidades externas) e (3) o projeto de interfaces entre um ser
humano (i. e., o usuário) e o computador.” (PRESSMAN, 2002: 393).
Um projeto de interface homem-computador precisa atender as necessidades
do usuário. Pressman (2002: 394), citando Mandel (1997), relaciona três “regras de
25 Mais informação sobre o programa de interface brasileiro baseado em comando de voz, chamado MOTRIX, encontra-se disponível em: <http://intervox.nce.ufrj.br/motrix/>. Acessado em: 02/Jul/06.
46
ouro” que servem de base formando um conjunto de princípios para um projeto de
interface com o usuário.
“1. Coloque o usuário no controle;
2. Reduza a carga de memória do usuário;
3. Faça interface consistente.”
O projeto de interface deve partir das necessidades do usuário e deve causar
o menor impacto possível no seu cotidiano. Interfaces gráficas cheias de menus e
botões acabam confundindo os usuários criando uma resistência na utilização do
novo sistema.
Utilizando a regra nº 1, Pressman (2002: 394), citando Mandel (1997),
explana alguns princípios que colocam os usuários no controle de projeto de
interfaces:
• “Defina os modos de interação de uma forma que não force o usuário a
ações desnecessárias ou indesejadas.” O programa deve fornecer ao usuário a
possibilidade de ativar e desativar opções do programa sem esforço.
• “Proporcione interação flexível.” O programa deve permitir que o usuário
escolha o melhor meio para interagir com o sistema. Como por exemplo: mouse,
teclado, caneta ótica ou reconhecimento de voz.
• “Permita que a interação com o usuário possa ser interrompida e desfeita.”
Deve ser permitido ao usuário interromper uma ação, ou desfazê-la, sem que o
usuário perca o trabalho que já foi feito.
• “Simplifique a interação à medida que os níveis de competência progridem
e permita que a interação seja personalizada.” Quando usuários fazem uma
operação repetitiva, sugere-se projetar para os usuários mais avançados um
mecanismos para automatizar esse processo (macro).
• “Esconda detalhes técnicos internos do usuário esporádico.”26 Deve ficar
oculto para o usuário a execução de comandos internos à aplicação, como por
exemplo, a digitação de comandos do sistema operacional.
• “Projete a interação direta com objetos que aparecem na tela.” O usuário
tem maior facilidade de interação com objetos ao executar uma ação, como por
exemplo clicar no desenho de uma impressora quando quer imprimir um relatório.
26 Usuário esporádico é aquele que tem um nível de conhecimento razoável do sistema.
47
Na regra nº 2, propõe não sobrecarregar a memória do usuário fazendo-o
lembrar de comandos do sistema, isso o induz ao erro. Sempre que for possível o
programa deve sugerir ações ao usuário fornecendo dicas e assistência.
Pressman (2002: 395), citando Mandel (1997), relaciona a teoria de projeto de
interface para reduzir a carga de memória do usuário.
• “Reduza a demanda de memória de curto prazo.” No projeto da interface,
deve-se tentar não forçar a memória do usuário para lembrar de ações e resultados
anteriores.
• “Estabelece defaults 27 significativos.” Deve ser permitido ao usuário alterar
as configurações do sistema de acordo com a sua preferência, mas deve estar
disponível uma opção destinada à voltar para configuração padrão.
• “Defina atalhos que são intuitivos.” Ao definir atalhos no sistema, a
seqüência de teclas deve ser sugestiva de acordo com a ação proposta, como por
exemplo as teclas <CTRL> + P para imprimir.
• “O leiaute visual da interface deve ser baseado numa metáfora do mundo
real.” A interação entre o usuário e uma interface é maior quando esta possuir uma
visualização familiar para o usuário, como por exemplo um formato de formulário de
requisição que o usuário esteja habituado a utilizar.
• “Revele informação de um modo progressivo.” A interface deve fornecer
informações, em primeira instancia, de uma forma generalizada e com grande nível
de abstração. Caso o usuário necessite especificar detalhes dessa informação a
interface deve fornecer maiores detalhes de como essa informação pode ser exibida.
Na regra nº 3, para fazer uma interface consistente implica dizer que:
“...(1) toda a informação visual seja organizada de acordo com um padrão de
projeto que é mantido ao longo de todos os mostradores de tela, (2)
mecanismos de entrada são restritos a um conjunto limitado que é usado
consistentemente ao longo de toda a aplicação e (3) mecanismos para
navegar de tarefa a tarefa são consistentemente definidos e implementados.”
(PRESSMAN, 2002: 396)
27 Palavra da língua inglesa. Refere-se a um valor pré-definido que pode ser atribuído a um parâmetro do sistema.
48
Pressman (2002: 396), citando Mandel (1997), esclarece um conjunto de
teorias que auxilia a fazer a interface consistente:
• “Permita ao usuário situar a tarefa atual num contexto significativo.” Muitas
interfaces são construídas com diversas telas com vários sub-níveis cada. A
interface para permitir ao usuário se situar, deve fornecer indicadores, tais como:
títulos nas janelas ou ícones gráficos, dessa forma o usuário consegue associar uma
tarefa a uma localização especifica.
• “Mantenha consistência ao longo de uma família de aplicações.” Na
interface deve ser mantido a forma de interação para a mesma família de aplicação.
• “Se modelos interativos anteriores criaram expectativas para o usuário, não
faça modificações, a menos que haja forte razão para isso.” As seqüências de
interação que forem bem assimiladas pelos usuários, eles esperarão que todos as
interfaces adotem o mesmo tipo de interação, como por exemplo o atalho <ALT>+S
para salvar se for alterado poderá induzir o usuário ao erro.
A experiência do usuário com o sistema, o nível de conhecimento dos
usuários e a análise do ambiente onde o usuário 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 ações que o usuário utiliza, isso servirá
de base para a criação das ações da interface.
Pôde-se observar que o projeto de uma interface é muito complexo e não é o
objetivo desse trabalho entrar em detalhes referente a interfaces.
2.8 – Implementação do Software
Na etapa de implementação, é onde o software “sai do papel” para começar a
se tornar um produto real. Todas as partes do projeto serão codificadas através de
várias ferramentas de programação.
A base de dados, dependendo dos requisitos, provavelmente deverá ser
implementada em um Sistema Gerenciador de Bando de Dados (SGBD), o projeto
da arquitetura definirá a linguagem de programação.
O projeto de interface pode ser implementado de diversas formas,
dependendo de qual maneira serão feitas as entradas e saídas de dados no
sistema.
49
2.9 – Testes do Software
Uma maneira eficaz de constatar se o software que foi projetado atende os
requisitos levantados e a necessidade do cliente é executar “testes de software “ ou
“verificação e validação” (V & V) do software.
“Teste de software é um elemento crítico da garantia de qualidade de
software e representa a revisão final da especificação, projeto e geração de código.”
(PRESSMAN, 2002: 429).
Existem diversos tipos de testes, um para cada situação e para cada tipo de
software. Abaixo segue uma lista de alguns tipos diferentes de testes que podem ser
empregados testar um software:
• Teste caixa-branca ou caixa de vidro;
• Teste de caminho básico;
• Teste de estrutura de controle;
• Teste caixa-preta ou comportamental;
• Teste de ambientes, arquiteturas e aplicações especializadas:
o Teste de GUI (Graphical User Interfaces 28);
o Teste de arquitetura cliente / servidor29;
o Teste da documentação e dispositivos de ajuda;
o Teste de sistemas de tempo real30.
Não basta ter a ferramenta e não saber como usá-la, o mesmo acontece com
os testes. Os chamados “casos de teste” devem ser cuidadosamente preparados de
acordo com o sistema a ser testado. A elaboração de um conjunto de diferentes
métodos de teste dá-se o nome de estratégias de teste.
As estratégias de testes são aplicadas desde o nível mais baixo (código) até o
nível mais alto. Em cada etapa de nível de teste são aplicadas diferentes estratégias
de teste, como segue:
• Teste de unidade utiliza:
28 É uma palavra da língua inglesa que significa Interface Gráfica com o Usuário. Refere-se as telas gráficas de sistemas baseado em janelas, tais como: Microsoft Windows ™. 29 Tipo de arquitetura onde o sistema do computador do usuário conecta-se a um servidor de aplicação ou sistema de base de dados. 30 Tipo de sistema onde as interações entre o sistema e os usuários ocorrem simultaneamente ou em um intervalo muito curto de tempo.
50
o Teste caixa-branca
• Teste de integridade utiliza:
o Teste de integração descendente
o Teste de integração ascendente
o Teste de regressão
o Teste fumaça
• Teste de validação utiliza:
o Teste caixa-preta
o Teste Alfa (Teste com usuário sob a supervisão do desenvolvedor)
o Teste Beta (Teste somente com o usuário)
• Teste de sistema.
o Teste de recuperação
o Teste de segurança
o Teste de estresse
o Teste de desempenho
Relatórios são os resultados da etapa de testes. De acordo com Pressman
(2002: 429), nessa etapa é gasto de 30% a 40% do esforço total do projeto.
Não é o objetivo desse trabalho se aprofundar no assunto de testes de
software. Maiores detalhes sobre esse assunto podem ser encontrados em
Pressman (2002: 429-496, 617-636).
2.10 – Implantação do Software
Nessa etapa o software é embalado, distribuído e instalado no usuário e se
for o caso os dados são importados. Em alguns casos ocorrem migrações de
sistemas. Os manuais são escritos, e os usuários são treinados.
Dependendo do porte do sistema ele poderá demorar meses ou até anos para
ser implantado completamente.
Alguns problemas podem surgir nessa fase:
1. Houve mudança do ambiente onde inicialmente foi feito o levantamento de
requisitos;
2. Os usuários podem ter dificuldades de aceitação do novo sistema;
51
3. O novo sistema e o sistema antigo podem ter que funcionar
simultaneamente até que o cliente sinta segurança como o novo sistema.
Pode ser que o novo sistema cause algum tipo de conflito com o sistema
antigo impossibilitando a sua implantação;
4. Problemas físicos de instalação, tais como: espaço físico, temperatura
controlada.
Uma vez colocado o sistema em produção, problemas não 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 adaptação para os usuários até que eles se
acostumem com o novo sistema. Erros de operação podem ocorrer.
2.11 – Evolução do Software
A evolução do software é a fase onde corrige-se os erros do software
encontrados após a sua implantação e também faz-se o aperfeiçoamento
implementando novos requisitos e funcionalidades para o sistema.
Segue abaixo algumas observações sobre as evoluções de sistemas:
“1. As mudanças propostas precisam ser analisadas muito cuidadosamente,
tanto sob uma perspectiva de negócios como de acordo com os aspectos
técnicos.(...)
2. Como os subsistemas nunca são inteiramente independentes, as mudanças
em um subsistema podem afetar adversamente o desempenho e o
comportamento de outros subsistemas.(...)
3. As razões das decisões de projeto originais muitas vezes não ficam
registradas. Os responsáveis pela evolução de sistemas precisam entender por
que foram tomadas determinadas decisões de projeto.
4. À medida que os sistemas ‘envelhecem’, sua estrutura se torna tipicamente
corrompida por mudanças, de modo que aumentam os custos referentes a
novas mudanças.” (SOMMERVILLE, 2003: 30).
52
Capítulo 3. Análise Orientada a Objetos com UML
Antes de fazer qualquer citação sobre a análise orientada a objeto, vamos
abordar os conceitos de orientação a objetos.
3.1 – Conceitos de Orientação a Objeto
Na análise orientada a objetos as funcionalidades do sistema são vistas na
forma de objetos31, onde cada objeto tem seus próprios métodos32 compostos por
rotinas independentes que se relacionam com outros objetos.
3.1.1 - Objetos
Melo (2006: 12) define que, na modelagem de sistema orientado a objetos,
um objeto é qualquer coisa existente no mundo real, seja material ou conceitual. Por
exemplo: carro, bola, bicicleta, caneta, livro, escola, professor, aluno, disciplina.
Pressman (2002: 534) explica que cada um desses objetos são membros de
uma classe mais ampla de objeto. Por exemplo, o objeto carro pode ser um membro
da classe (também chamado de instância) automóvel que também é outro objeto.
Utilizando o conceito de objeto fica mais fácil fazer a modelagem de sistemas,
e também permite que os usuários e clientes compreendam e participem da
validação dos diagramas ativamente e vejam como o sistema está sendo
desenvolvido evitando dúvidas nos requisitos.
Cada objeto possui características próprias denominadas atributo33. Seguindo
o exemplo do automóvel, seriam exemplos de seus atributos: quantidade de
passageiros, cor, modelo, ano, chassi, placa, capacidade de combustível, tipo de
combustível, motor, preço.
31 Na análise orientada a objetos, os objetos são representados por classes. Fazendo uma analogia com o processo de fritar um ovo, dependendo da abstração, podemos ter como objetos os substantivos: ovo, fogão e a frigideira. 32 Os métodos, também chamado de operação, definem o comportamento do objeto (classe). São as rotinas que determinam a ação do objeto. Ainda com a analogia de fritar um ovo podemos ter, por exemplo: na classe o ovo pode ter o método “quebrar o ovo”, o fogão pode ter o método “ajustar o nível do fogo”, e a frigideira pode ter o método “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 automóvel, possuem comportamentos tais como:
acelerar, brecar, abrir vidro, acender farol, buzinar, abrir porta, ligar motor. À
implementação desses comportamentos dá-se o nome de operações, também
chamados de métodos.
3.1.2 - Classes
“Uma classe é a representação de um conjunto de objetos que compartilham
a mesma estrutura de atributos, operações e relacionamentos dentro de um mesmo
contexto...” (MELLO, 2006: 17).
Segundo Pressman (2002: 534) a comunicação de uma classe, por exemplo,
automóvel, com outra classe, por exemplo, motorista, faz-se através 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 método (operação) e obter
o dado desejado.
Melo (2006: 18) explica que num sistema orientado a objetos trabalhamos
com os objetos, chamados de instâncias, os quais são representados a partir de
uma classe. Os dados são carregados nas instâncias criadas. Na figura nº 9 é
exemplificado o conceito de instância de objeto.
Figura 9: Objeto e classe. (MELO, 2004: 18)
No exemplo acima, a partir da classe pessoa foi criado o objeto João, logo o
objeto João é do tipo Pessoa. Quem recebeu os dados foi o objeto João.
Para entender melhor, pode-se fazer uma analogia com uma fotocópia de um
formulário onde a partir de um original (classe) pode-se criar várias cópias
Objeto João
Nome Sexo
Data de Nascimento Estado Civil
Nome: João Souza Sexo: Masculino Data de Nascimento: 01/03/0960 Estado Civil: Casado
Atributos
Classe Pessoa
Atributos
é do tipo
54
(instancias de objetos), os campos do formulário (atributos) a serem preenchidos
(dados) será o da cópia e não o original.
“Uma classe pode ter qualquer número de atributos ou mesmo nenhum
atributo. Da mesma forma, pode ter qualquer número de operações ou mesmo
nenhuma operação.” (MELLO, 2006: 18).
Podemos citar alguns tipos de classes:
Classe Objetos
Funcionário Funcionário Ana Cristina
Funcionário Gustavo
Empresa Empresa Casa de Festas ABC
Empresa Softwares Ltda.
Veículo Veículo Santana
Veículo Escort
Tabela 2: Classes e instâncias. (MELO, 2006: 18)
Segundo Pressman (2002: 536), por definição, todos os objetos instanciados
a partir de uma classe herdam seus atributos e métodos. Dá-se o nome de
superclasse (ou classe mãe) à classe principal, e dá-se o nome de subclasse (ou
classe filha) a classe criada (instanciada) a partir da superclasse. Maiores detalhes
sobre herança serão 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 relação com o caso em questão.
Segundo Pressman (2002: 543), também podem ser tipos de objetos:
• Entidades externas: outros sistemas, dispositivos ou pessoas;
• Coisas: relatórios, cartas que façam parte do problema;
• Ocorrências: eventos que ocorram dentro do contexto do problema;
• Papéis: pessoas que exercem funções de gerente, vendedor;
• Unidades Organizacionais: divisão, grupo da organização;
• Lugares: que estabelecem contexto do problema;
• Estruturas: sensores, computadores.
55
3.1.3 – Métodos, operações, serviços
Métodos definem o comportamento do objeto (classe) e podem modificar de
algum modo os atributos do objeto. São as rotinas que determinam a ação do objeto.
Segundo Pressman (2002: 538), os métodos também pode ser chamados de
operações ou serviços.
Por exemplo, na classe ‘Evento’ temos os atributos ‘nome’, ‘horarioInicio’,
‘duracao’, ‘dataRealizacao’ e ‘descricao’, quando alguma outra classe quiser
cadastrar dados para a realização de um evento será utilizado um método
‘‘cadastrarEvento’, previamente criado nessa classe. Para acessar esse método, a
classe que requisita essa informação envia uma mensagem34 para a classe veículo.
Figura 10:Representação de classe. (MELO, 2004: 101)
3.1.4 - Mensagens
“As mensagens são o meio pelo qual os objetos interagem” (PRESSMAN,
2002: 538). Ao modelar o sistema, ou seja, criando associações entre as classes
estabelecendo-se uma ligação entre elas. É através dessa associação que há a
troca de mensagens contendo: o nome da classe receptora, qual o tipo de operação
será realizado, e quais os parâmetros.
34 Mensagem é o meio pelo qual os objetos se comunicam uns com os outros.
Evento
cadastrarEvento() remarcarEvento()
nome horarioInicio duracao dataRealizacao descricao
nome da classe
atributos
operações
Classe
56
3.1.5 - Encapsulamento
“Encapsulamento é o conceito que faz referência à ocultação ou
empacotamento de dados e procedimentos dentro do objeto.” (TONSIG, 2003: 169)
Figura 11: Encapsulamento (TONSIG, 2003: 169)
Melo (2004: 19) explica que a finalidade do encapsulamento é proteger os
atributos e as operações da classe. Com o auxílio de uma classe de interface35 é
possível que outras classes do sistema acessem as operações da classe
encapsulada, pois a interface serve de intermediaria na troca de mensagens.
Em uma classe encapsulada os atributos e operações 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 operações 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 destinatário.
Segue abaixo alguns benefícios importantes do encapsulamento:
• “Os detalhes internos de implementação dos dados e procedimentos são
ocultados do mundo exterior (..).
• As estruturas de dados e as operações que as manipulam são juntadas
numa única entidade denominada – a classe.(...)
35 A classe de interface é “oca”, ela não contém atributos e nem operações próprias. Serve apenas de intermediaria. É explicada no tópico 3.4.2.6.
Atributos do Objeto
Método A Método B
Método C
Método D
Método EMétodo F
Método G
Método H
57
• As interfaces entre objetos encapsulados são simplificadas. Um objeto que
envia uma mensagem não precisa estar preocupado com os detalhes de
estruturas internas de dados.(...)” PRESSMAN (2002: 540).
3.1.6 - Herança
A herança, como o próprio nome sugere, tem como característica permitir que
as classes herdeiras, chamadas de classe-filha ou subclasse, recebam os mesmos
atributos e métodos da classe-mãe ou superclasse.
Quando falamos em herança, temos dois conceitos envolvidos: a
generalização e especialização.
A generalização é quando separamos os atributos mais genéricos da classe
filha para criar a classe mãe, por exemplo, seria como passar o atributo nome, da
classe funcionário para a classe pessoa.
A especialização é ao contrário, é quando separamos os atributos mais
específicos da classe mãe para criar a classe filha, por exemplo, seria como passar
o atributo matrícula, da classe pessoa para a classe aluno.
Um tipo especial de herança, chamada herança múltipla, é quando uma
classe filha (subclasse) possui duas ou mais classes mãe (superclasse) e herdam os
atributos e métodos de todas as superclasses. Nesse tipo de herança, a classe filha
também é conhecida como classe de junção.
Figura 12: Herança múltipla (BEZERRA, 2002: 195)
CarroAnfíbio
CarroAnfíbio CarroAnfíbio
58
Figura 13: Herança (MELO, 2004: 21)
3.1.7 – Polimorfismo
O principio do polimorfismo é quando “...um objeto pode enviar a mesma
mensagem para objetos semelhantes, mas que implementam a sua interface de
formas diferentes.” (BEZERRA, 2002: 10).
De acordo com Melo (2004: 22), uma operação polimórfica pode ser
implementada nas classes filhas de forma diferente da classe mãe. Podemos tomar
como exemplo uma classe mãe chamada funcionário que possui uma operação
chamada CalcularSalário, essa classe possui uma classe filha chamada professor. A
classe professor também possui uma operação chamada CalcularSalário que calcula
o salário em horas enquanto a operação CalcularSalário da classe mãe calcula o
salário fixo.
Esse tipo de operação pode ser feito em diversos pontos da hierarquia desde
que a assinatura36 não se altere.
36 São os parâmetros que são colocados entre os parênteses da operação. São quantidade e tipos de argumentos e o tipo do valor resultante.
59
Figura 14: Polimorfismo (MELO, 2004: 22)
Segundo Presmann (2002: 542), em uma operação onde a assinatura se
mantém inalterada é chamada de polimorfismo de inclusão. Quando a assinatura é
modificada temos o conceito de polimorfismo de sobrecarga.
3.2 – Análise Orientada a Objetos
Antes do surgimento da UML, Booch utilizava o método chamado de ‘análise
orientada a objetos’ (Object-Oriented Analysis, OOA), por sua vez Rumbaugh
utilizava a ‘técnica de modelagem de objetos’ (Object Modeling Technique, OMT) e
Jacobson usava a ‘engenharia de software orientada a objetos’ (Object-Oriented
Software Engineering, OOSE).
“Durante a última década, Grady Booch, James Rumbaugh e Ivar Jacobson
colaboraram para combinar as melhores características de seus métodos individuais
de análise e projeto orientados a objeto num método unificado.” (PRESSMAN, 2002:
563). A partir desse método surgiu a Linguagem de Modelagem Unificada (Unified
Modeling Language, UML).
Pressman (2002: 559) explica que, a análise orientada a objetos se inicia com
as descrições de casos-de-uso37, onde cada um dos casos-de-uso poderá ser
transformado em uma ou mais classes no decorrer da análise orientada a objetos.
Durante a análise orientada a objetos são definidos as classes (objetos) e a
forma como elas interagem entre si e com o mundo externo, suas funções internas
(atributos e operações), seus relacionamentos e a comunicação entre elas
(mensagens). 37 É uma descrição baseada em cenários mostrando como atores, que podem ser pessoas, máquinas e sistemas externos, interagem com o sistema que está sendo construído.
CLASSE FUNCIONÁRIO Operação CalculaSalário(mesReferencia: integer)
CLASSE PROFESSOR Operação CalculaSalário(mesReferencia: integer)
60
Segundo Pressman (2002: 563), a UML permite que o projetista de software
modele o sistema com base em um conjunto de regras e símbolos. A representação
de um sistema em UML pode ser visto em 5 tipos de “visões”:
• Visão do modelo do usuário: Representa a visão do sistema do ponto de
vista do usuário;
• Visão do modelo estrutural: Visão dos dados e funcionalidades dentro do
sistema, os quais são modelados e se transformam em classes, objetos e
relacionamentos;
• Visão do modelo comportamental: Descreve os aspectos
comportamentais do sistema, e mostra como ocorre a interação com os
modelos do usuário e estrutural;
• Visão do modelo de implementação: Descreve como devem ocorrer as
construções dos aspectos estrutural e comportamental;
• Visão do modelo do ambiente: Descreve o aspecto estrutural e
comportamental do ambiente onde o sistema será implementado.
“Pode-se dizer que a análise 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 análise criado (...) num modelo de projeto que serve como documento
para a construção de software” (PRESSMAN, 2002: 589).
Bezerra (2002: 139) afirma que, as atividades executadas na fase de projeto
são:
1. Detalhamento dos aspectos dinâmicos do sistema: São construídos os
modelos de interações, modelos de estados e modelos de atividades.
2. Refinamento dos aspectos estáticos e estruturais do sistema: São
construídos os modelos de classes de domínio, de fronteira, de controle e
de entidade.
3. Definição de outros aspectos da solução: É analisado como o sistema
pode ser decomposto em diversos subsistemas, onde cada subsistema
será composto por várias classes.
61
3.3 – Linguagem de Modelagem Unificada (Unified Modeling
Language, UML)
Conforme foi falado anteriormente Grady Booch, James Rumbaugh e Ivar
Jacobson foram os principais precursores da UML. A UML surgiu a partir da união de
vários modelos com o objetivo de criar uma linguagem única para a modelagem de
sistemas orientados a objetos. A primeira vez que a UML foi reconhecida e aprovada
pelo OMG38 foi em 1997.
A UML não é um método, é uma linguagem de modelagem que utiliza um
visual gráfico para construção e documentação de artefatos39 para sistemas
orientados a objetos. É composta por diversos componentes gráficos e diagramas, e
é independente de linguagem de programação e processos de desenvolvimentos.
O inicio da unificação foi em outubro de 1994 quando James Rumbaugh
deixou a General Electric e juntou-se a Grady Booch da Rational Software com o
objetivo de unir seus métodos. Em 1995 Ivar Jacobson também se juntou ao grupo e
em 1996 e eles passaram a ser conhecidos como ‘os três amigos’. Desde 1995 até
2004 a UML teve muitas versões e publicações (versão 0.8 em 1995, versão 0.9 e
0.91 em 1996, versão 1.0 e 1.1 em 1997, versão 1.2 e 1.3 em 1998, versão 1.4 em
2001, versão 1.5 em 2003 e finalmente a 2.0 em 2004). A partir do ano de 1997
novos integrantes se juntaram ao grupo que já tinha ganhado a confiança das
organizações.
As modelagens com UML são feitas com base em relacionamentos,
diagramas e regras de formatação. Neste tópico vamos dar ênfase à versão 1.4 da
UML, não veremos todos os elementos disponíveis40 da UML, somente alguns
conceitos e exemplos para o perfeito entendimento do estudo de caso apresentado
no capítulo 4.
3.4 - Diagramas
38 Abreviação da sigla Object Management Group. O OMG é um consórcio internacional que define e valida padrões na área de orientação a objetos (http://www.omg.org). 39 Artefato é qualquer coisa que pode ser utilizado durante a construção de um sistema. Ex: requisitos, arquitetura, testes, código-fonte, relatórios, croqui, planos de projetos, etc. 40 Mais informações sobre UML podem ser encontradas na Internet (http://www.uml.org).
62
Segundo Booch (et al.: 2000: 89), o diagrama é um meio e representação
gráfica feita através de blocos, símbolos e vários elementos interligados entre si que
são 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
usuário / cliente e também para documentar o projeto que servirá de guia para a
equipe de desenvolvimento evitando assim problemas de interpretação.
3.4.1 – Diagrama de Caso de Uso (Use Case)
Melo (2004: 54) explica que, um caso de uso é uma maneira gráfica de relatar
o funcionamento de um sistema através de uma seqüência de ações que mostra um
cenário principal e um cenário alternativo (caso ocorra na seqüência principal algum
imprevisto).
Podemos exemplificar a descrição acima com o caso de uso: Emitir saldo em
um terminal de caixa eletrônico. Em um cenário principal, também é chamado de
cenário perfeito, teríamos:
Figura 15: Cenário Principal (MELO, 2004: 55)
Por mais bem projetado que seja o sistema é impossível que seja tudo
perfeito, cabe ao analista verificar as possibilidades de algo sair errado e tratar esse
erro. De posse da relação das probabilidades de algo sair errado criam-se cenários
alternativos.
Em um cenário alternativo usa-se o termo “encerar o caso de uso” para
indicar que a seqüência de ações foi interrompida por um determinado
acontecimento.
Cenário Principal 1. O sistema realiza a leitura do cartão magnético do correntista. 2. O sistema solicita a digitação da senha. O correntista digita a senha. 3. O sistema valida a senha. 4. O correntista seleciona a opção de saldo. 5. O sistema questiona o tipo de saldo: conta corrente, poupança, aplicações. 6. O sistema processa e mostra o saldo solicitado pelo cliente. etc.
63
No exemplo da figura 16, Include é uma indicação que será incorporado a
esse caso de uso um outro caso de uso através de um relacionamento de inclusão.
Será visto em maiores detalhes no item 3.4.1.4.
Figura 16: Cenários alternativos (MELO, 2004: 56)
Faz parte da documentação de caso de uso a descrição das regras do
negócio. “Regras do negócio são políticas, condições ou restrições que devem ser
consideradas na execução dos processos existentes em uma organização.”
(GOTTESDIENER, 1999 In: BEZERRA, 2002: 70).
Segundo BEZERRA (2002:71), as regras de negócios podem ser
representadas através de descrição textual onde cada regra pode conter:
• Uma identificação, (por exemplo: RN01) dessa forma podem ser
referenciadas nas descrições de casos de uso;
• Um nome que seja possível fazer sua distinção;
• Uma fonte, quem forneceu essa regra de negócio;
• Um histórico, contendo uma data de referência ou alguma informação
adicional.
As regras de negócio são obtidas na fase de levantamentos de requisitos
(visto no item 2.5.2), tem influência na lógica de programação e podem estar
relacionadas a um ou vários casos de uso.
Bezerra (2002: 84) sugere um modelo de descrição de caso de uso um pouco
diferente do anterior que pode ser visto no anexo A (Modelo de Descrição de Caso
de Uso).
Alternativa: Problema na leitura do cartão magnético 1a) Se o sistema não conseguir ler os dados do cartão magnético, tentar nova
leitura por, no máximo, mais duas vezes. Caso persista o problema, encerrar o caso de uso.
Alternativa: Senha Inválida 3a) Se a senha digitada pelo correntista não for igual à senha cadastrada no
sistema, informar ao mesmo e solicitar nova digitação. Esse processo pode ser repetido por no máximo três tentativas (incluindo a primeira). Após a terceira tentativa, a conta do usuário deverá ser bloqueada e o caso de uso encerrado. Include Bloquear Conta.
Alternativa: Conta Inexistente 6a) Se o correntista não possuir o tipo de conta selecionada, informar ao
mesmo e encerrar o caso de uso.
64
No diagrama de caso de uso todos os meios externos (ex.: sistemas externos,
usuário ou grupo de usuários) que interagem com o sistema são chamados de
atores. Na modelagem de caso de uso os atores ficam separados dos casos de uso
por uma fronteira do sistema (system boundary), os atores do lado de fora e os
casos de uso do lado no seu interior.
Figura 17: Representação de fronteira do sistema (MELO, 2004: 68)
3.4.1.1 – Associação (Association)
A associação é a forma que um ator interage com um ou mais casos de uso
do sistema. Essa interação é feita através do envio e recebimento de mensagens.
A associação só pode ser utilizada entre atores e casos de uso.
Figura 18: Representação de uma associação (MELO, 2004: 65)
3.4.1.2 – Generalização (Generalization)
A generalização utiliza o mesmo conceito proveniente da herança em
orientação a objetos, ou seja, casos de uso podem ser genéricos ou específicos. Por
exemplo: Podemos ter um caso de uso Cadastrar Funcionário onde relacionados a
65
este temos Cadastrar Professor. O caso de uso Cadastrar Funcionário é uma
generalização, Cadastrar Professor são especializações, ou tipo de funcionário. O
mesmo acontece com atores, nesse exemplo o ator Gerente tem suas
responsabilidades e também herda as responsabilidades do ator Vendedor.
Generalizações só ocorrem entre casos de uso ou entre atores.
Figura 19: Representação de um relacionamento de Generalização41 (MELO, 2004: 67)
3.4.1.3 – Extensão (Extend)
Melo (2004: 61) explica que um “...relacionamento de extensão entre casos
de uso indica que um deles terá seu procedimento acrescido, em um ponto de
extensão, de outro caso de uso, identificado como base.”
Figura 20: Representação de um relacionamento Extend (MELO, 2004: 67)
41 Considere que o Gerente também é um vendedor e possui as mesmas responsabilidades e algumas a mais.
66
A extensão é usada para relacionar casos de uso que possuem ações que
tem ocorrências eventuais, opcionais ou exceções, por exemplo, os cenários
alternativos.
Pode-se observar que a palavra extend está entre dois símbolos, guillemets
(«»), a essa nomenclatura dá-se o nome de estereótipo.
Extensão somente é utilizada entre casos de uso. Um caso de uso pode ter
vários pontos de extensão.
3.4.1.4 – Inclusão (Include)
Inclusão, como o próprio nome diz, inclui as ações de um caso de uso em
outro. Tem como vantagem utilizar as mesmas ações do caso de uso incluído em
vários outros casos de uso evitando a cópia de várias ações repetidas.
Normalmente é utilizada a inclusão quando existe um pré-requisito para que
uma ação aconteça. O exemplo abaixo mostra a inclusão do caso de uso Validar
Matricula que é incluído ao matricular o aluno (caso de uso Matricular Aluno) ou ao
emitir o histórico escolar (caso de uso Emitir Histórico Escolar).
Inclusão somente é utilizada entre casos de uso. Um caso de uso pode ter
vários pontos de inclusão.
Figura 21: Representação de um relacionamento Include (MELO, 2004: 66)
3.4.2 – Diagrama de classes
67
A função do diagrama de classes é criar relacionamentos entre as classes
fazendo com que elas troquem mensagens para que suas operações possam ser
acessadas e assim obter a funcionalidade do sistema.
Como foi visto na figura 10, uma classe tem a representação gráfica de um
retângulo dividido em três compartimentos. Melo (2004: 101) explica que essa
“...divisão corresponde à notação básica dos diagramas de classe”.
• Na parte superior fica o nome da classe, centralizado e em negrito. As
iniciais do nome deve ser em maiúsculo, se for nome composto não pode
haver espaço.
• Na parte central a lista de atributos deve ser escrita com formatação
normal alinhado à esquerda. Os nomes dos atributos iniciam-se com letra
minúscula, e se for nome composto, o segundo nome deve ser escrito em
letra maiúscula sem espaçamento.
• Na parte inferior a lista de operações escritas da mesma forma que os
atributos.
Mas antes de começarmos a criar diagramas, alguns conceitos precisam ser
vistos.
3.4.2.1 – Visibilidade
Em uma classe temos atributos e operações que podem ter seu parâmetro de
visualização de diversas formas. A visualização permite que atributos e operações
sejam visualizados totalmente, parcialmente por outras classes ou não visualizados,
nesse último caso somente a própria classe poderá visualizá-los.
Os parâmetros de visualização são 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 poderão obter acesso aos valores públicos
42 São utilizados em sistemas de médio e grande porte. Em um sistema têm-se subsistemas, cada subsistema é composto por vários elementos do modelo UML que são agrupados, a esse agrupamento dá-se o nome de pacote.
68
dos atributos e das operações da classe se o mesmo puder visualizar o pacote onde
está a referida classe.
Protected (#): é visualizado pela própria classe e pelas classes descendentes
(herança).
Private (-): é visualizado apenas dentro da própria classe. Outros elementos
associados a essa não terão 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 instâncias possíveis em um
relacionamento.” (MELO, 2004: 96).
Vamos tomar como exemplo a classe EmissoraTv e a classe Comercial:
• Uma emissora de TV transmite nenhum ou vários comerciais, e um
comercial pode ser veiculado por nenhuma ou até oito emissoras.
A figura 22 possui a representação gráfica dessa multiplicidade. Nota-se que
existe um limite-inferior e limite-superior.
Figura 22: Multiplicidade numa associação. (MELO, 2004: 111)
Exemplos de multiplicidades mais utilizadas:
• 0..1 = nenhum ou um;
• 1 ou 1..1 = apenas um;
• * ou 0..* = nenhum ou vários, ou seja, qualquer valor.
• 1..* = um ou vários.
3.4.2.3 – Atributos e Operações
EmissoraTV Comercial0..8 0..*
69
Ao definir os atributos informa-se seu nome, tipo, valor inicial, visibilidade.
Alguns parâmetros são opcionais, obrigatoriamente precisam ser informados o nome
e tipo.
Visibilidade: +, -, # ou ~.
Tipo: inteiro (integer), real, texto (string), entre outros.
Multiplicidade: se for exatamente 1 poderá ser omitida.
Valor-default: valor inicial do atributo no momento que o objeto é instanciado.
Segue alguns exemplos abaixo:
• private Senha: string
(visibilidade privado, nome do atributo Senha do tipo string – texto).
• + tamanho: integer
(visibilidade publica, nome do atributo tamanho do tipo integer – inteiro).
• angulos: integer [3]
(a classe tem de um a três angulos)
• nota1: real = 0
(define o tipo de atributo e atribui o valor inicial)
Existe um atributo chamado: atributo derivado. Atributo derivado é um
atributo cujo valor é calculado com base em outros atributos da mesma classe. A
identificação visual desse tipo de atributo é feito com uma barra ( / ) à frente do
nome do atributo.
As operações também possuem visibilidades similares à dos atributos.
Operações podem passar e / ou retornar algum tipo valor, por isso também precisa-
se saber seu tipo. Segue abaixo exemplos de sintaxe:
• private obterSenha: string
(visibilidade privado, nome da operação Senha, recebe valor do tipo string –
texto).
• + modificarTamanho (iTamanho: integer)
(visibilidade publica, nome da operação iTamanho envia valor do tipo integer
– inteiro).
• + modificarTamanho (iTamanho: integer)
Na operação existe um conceito muito importante, refere-se à assinatura da
operação. A assinatura da operação é como se chamam os parâmetros que são
70
passados entre os parênteses de uma operação. No exemplo abaixo, percentual:
real é a assinatura da operação.
• reajustarSalario(percentual: real)
3.4.2.4 – Relacionamentos
É através do relacionamento que as classes estabelecem a comunicação,
trocam mensagens e colaboram umas com as outras. Os relacionamentos, que
veremos a seguir, podem ser de associação, generalização, dependência,
agregação e composição.
3.4.2.4.1 – Associação
A associação pode relacionar duas classes (associação binária), três classes
(associação ternária), mais de três classes ou apenas uma classe se relacionando
com ela mesma (auto-relacionamento).
A associação é representada por uma linha contínua ligando as classes, o
nome da associação pode ser mostrado para indicar a ação. Segundo Melo (2004:
109), o auto-relacionamento também é uma associação binária.
Figura 23: Representação de associação (MELO, 2004: 109).
Em uma associação ternária, um losango é usado para unir as conexões.
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.
Aluno Disciplina Funcionário
71
Figura 24: Representação de uma associação ternária (MELO, 2004: 109).
3.4.2.4.2 – Generalização
O relacionamento de generalização é mostrado graficamente como uma linha
contínua com uma flecha vazada apontando para a classe-mãe, ou seja, a classe
mais genérica. O outro lado da linha liga a classe filha, ou seja, a classe mais
específica.
De acordo com Booch (et al.: 2000: 63) os relacionamentos de generalização
também são chamados de relacionamentos é um tipo de um item. Conforme
explanado sobre herança no item 3.1.6, classes mais específicas (classe filha)
herdam as propriedades da classe genérica (classe mãe).
A generalização pode ser representada de duas formas. As duas formas
estão sendo apresentadas na figura 25.
Figura 25: Representação de generalização (MELO, 2004: 113)
Segunda forma de representação
Pessoa
Cliente Fornecedor Funcionário
Pessoa
Cliente Fornecedor Funcionário
Primeira forma de representação
Equipe Jogador
Temporada
72
A herança permite que as classes filhas herdem tanto os atributos quanto as
operações da classe mãe. Observemos o exemplo a seguir:
Figura 26: Definição de operações Polimórficas. (BEZERRA, 2002: 201)
A classe Funcionário possui uma operação obterPagamento a partir do salario
base, a classe Vendedor tem seu salário calculado de forma diferente da operação
herdada então essa operação é redefinida na classe Vendedor, ou seja, seu código
é re-escrito. Dá-se o nome de Polimorfismo a essa operação.
3.4.2.4.3 – Dependência
Segundo Booch (2000: 451), dependência é um relacionamento entre dois
elementos, em que a alteração de um elemento (o independente) poderá afetar o
outro elemento (o dependente).
A indicação da dependência é feita com uma linha tracejada com uma seta
aberta apontando para o item independente, conforme a figura abaixo.
Figura 27: Dependência (MELO, 2004: 116)
Funcionário
+ obterPagamento(): Moeda + definirSalarioBase(in umSalario: Moeda) + obterSalarioBase(): Moeda
- salarioBase: Moeda
Vendedor
+ obterPagamento(): Moeda
- comissao: Porcentagem
AgendaConsulta HorarioMedico
73
No exemplo anterior a classe AgendaConsulta depende de HorarioMedico.
Qualquer alteração em HorarioMedico afetará a classe AgendaConsulta.
“Na assinatura de uma operação, uma classe aparece como parâmetro.”
(MELO, 2004: 116). Na figura 28, pode-se observar que na classe abaixo a
operação playOn aparece com o nome da classe dependente como parâmetro.
Figura 28: Assinatura da Dependência (BOOCH, 2000: 63)
3.4.2.4.4 – Agregação
É uma associação somente entre duas classes independentes onde sua
existência não 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
contínua com um pequeno losango em uma das extremidades. O losango aponta
para a agregação (todo), enquanto a outra extremidade aponta para a classe
agregada (parte).
No exemplo da figura 29 uma Empresa tem muitos Departamentos.
Figura 29: Agregação (BOOCH, 2000: 66)
FilmClip
playOn(c: Channel) start() stop() reset()
Channel
name
Empresa
Departamento
todo
parte
agregação 1
*
74
3.4.2.4.5 – Composição
A composição é uma variação da agregação, o relacionamento é do tipo
composto de algum elemento da mesma forma que na agregação o todo e a parte.
A diferença da composição é que a classe parte não pode fazer parte de nenhuma
outra composição.
Outra diferença é que a classe composta (todo) é responsável por criar e
destruir43 sua(s) parte(s). Caso a classe composta for destruída suas partes também
serão.
A representação do relacionamento de composição é feita com uma linha
contínua 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.
Figura 30: Composição (BOOCH, 2000: 148)
3.4.2.4.6 – Realização
Realização “... é um relacionamento entre uma especificação e sua
implementação.” (MELO, 2004: 42).
Segundo Booch (2000: 150), a realização é na maioria das vezes utilizada
para especificar um relacionamento entre uma classe de interface ou componente
que fornece uma operação ou serviço para a interface.
43 Na programação orientada a objetos, criam-se objetos a partir de uma classe e os objetos criados podem ser destruídos após sua utilização.
Janela
Moldura
todo
parte
composição 1
*
75
A realização é representada por uma linha tracejada com uma seta fechada e
vazia. Poderemos ver uma aplicação do relacionamento de realização, na figura 33
no item 3.4.2.6, onde falaremos de classes de Interface.
3.4.2.5 – Classe de associação
“Em uma associação entre duas classes, a própria associação poderá ter
propriedades” (BOOCH, 2000: 148).
A classe de associação surge na modelagem quando existe uma associação
de muitos para muitos, por exemplo, conforme a figura 31, uma Pessoa pode
trabalhar em muitas Empresas, por sua vez, uma Empresa podem ter muitos
empregados (Pessoas). Nesse caso a associação pode ter propriedades como
salario e dataContratacao, dá-se então a origem a classe associativa Emprego.
A classe associativa é representada por uma linha tracejada ligado à linha
contínua da associação, e a outra extremidade é ligada à nova classe - classe
associativa.
Figura 31: Classe Associativa (BEZERRA, 2002: 105)
Bezerra (2002: 106) explica que, uma classe associativa pode ser modificada
substituindo o elemento híbrido por uma classe ordinária, conforme a figura 32.
Pessoa Empresa
nome telefone endereco
razaoSocial endereco
*
empregado
*
empregador
salario dataContratacao
Emprego
76
Figura 32: Classe Associativa (BEZERRA, 2002: 106)
Podemos notar que a multiplicidade que no diagrama da figura 31 era muitos
para muitos. Com a substituição do elemento híbrido, a classe Emprego passou a
fazer parte da associação e a multiplicidade passou a ser um para muitos e muitos
para um respectivamente. Essa modificação não implica em perda ou alteração da
informação.
3.4.2.6 – Classe de Interface
“Uma interface é uma coleção de operações utilizadas para especificar um
serviço de uma classe ou de um componente.” (BOOCH, 2000: 154).
De acordo com Booch (2000: 158) a interface não possui atributos nem
implementam operações, é uma classe ‘vazia’. As operações que aparecem listadas
na classe da interface, mostrada na figura 33, estão implementadas na classe Loja.
Quando outra classe solicita uma operação à interface, está repassa a operação
para a classe na qual está servindo de interface, ao retornar uma resposta segue o
caminho inverso.
A representação da interface pode ser feita como uma classe colocando o
estereótipo «interface» acima do nome da classe, nesse caso utiliza-se o
relacionamento de Realização para se comunicar com outra classe e coloca-se as
operações da classe. A interface também pode ser representada na forma de um
circulo vazio com o nome da interface colocado logo abaixo do mesmo, mas as
operações não aparecerão e sua ligação é feita através do relacionamento de
realização representado por uma linha contínua sem seta.
Pessoa Empresa
nome telefone endereco
razaoSocial endereco
* *salario dataContratacao
Emprego
1 1
77
Figura 33: Interface usando uma classe com estereótipo (MELO, 2004: 123)
Figura 34: Interface usando o circulo (MELO, 2004: 123)
3.4.3 – Diagrama de Seqüência
De acordo com Melo (2004: 163) o diagrama de seqüência tem a finalidade
de identificar as operações das classes com o auxilio de um conjunto de elementos
gráficos que permita ilustrar todas as interações do sistema.
Os cenários de caso de uso podem ser representados através do diagrama
de seqüência, assim podemos visualizar a troca de mensagens entre as classes e
visualizar quando os objetos são criados e destruídos.
Nas figuras 35, 36 e 37 podem ser visualizados alguns dos elementos do
diagrama de seqüência, em seguida uma explicação sobre cada um deles.
Loja criar() busca(idLoja) obterTotalVendas(vendedor) lançarVendas(vendedor, vendas)
idLoja: integer vendedores: List
realização
«interface» Loja
obterTotalVendas(vendedor) lançarVendas(vendedor, vendas)
Loja criar() busca(idLoja) obterTotalVendas(vendedor) lançarVendas(vendedor, vendas)
idLoja: integer vendedores: List
ILoja
realização
78
Figura 35: Diagrama de seqüência com elementos básicos. (BEZERRA, 2002: 148)
A representação dos atores no diagrama de seqüência é opcional, sua forma
gráfica é de um ‘homem de bastão’ (stick man).
Os objetos do diagrama de caso de uso devem aparecer no diagrama na
mesma seqüência. Os objetos podem ser anônimos ou nomeados, são nomeados
quando são utilizados em vários lugares.
Figura 36: Objetos anônimos e nomeados. (BEZERRA, 2002: 149)
A nomeação dos objetos é feita pelo nome do Objeto: nome da Classe.
Bezerra (2002: 149) explica que, na maioria das vezes os diagramas de
seqüência contém 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 seqüência aparece na forma de uma linha
tracejada verticalmente.
O foco de controle é um retângulo em cima da linha de vida do objeto, ele
representa o tempo em que o objeto realiza uma ação. A cada nova ação do objeto
item: ItemPedido : ItemPedido
Objeto nomeado Objeto anônimo
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.
Figura 37: Notação de tipos de mensagens em diagrama de seqüência. (BEZERRA, 2002: 150)
• Mensagem simples: mensagem do tipo não relevante. É a mais utilizada;
• Mensagem síncrona: ao enviar uma mensagem síncrona o remetente fica
bloqueado enquanto espera a resposta do receptor;
• Mensagem assíncrona: nesse tipo de mensagem o objeto não espera a
resposta para prosseguir com as ações seguintes;
• Mensagem de retorno: indica o fim do processamento, seu uso é
opcional;
• Mensagem reflexiva: é quando um objeto envia uma mensagem a si
próprio para executar uma operação que está implementada na sua
própria classe. Pode-se ver um exemplo de mensagem reflexiva na figura
38.
A criação de objetos pode ser requisitada por outro objeto a partir da
mensagem «create» (criar). Se o objeto for criado desde o inicio da interação ele
fica no topo do diagrama, se for instanciado depois ele fica na mesma altura da
mensagem de criar.
A destruição de objetos ocorre logo após a mensagem «destroy» (destruir) e sua representação é através do símbolo X logo no final do foco de controle logo
abaixo da mensagem de destruição.
Na figura 38 podemos observar todas os elementos citados.
Simples
Síncrona
Assíncrona
Retorno
80
Figura 38: Elementos do Diagrama de Seqüência. (BEZERRA, 2002: 151)
3.4.4 – Diagrama de Atividades
“O diagrama de atividade tem por propósito focalizar um fluxo de atividades
que ocorrem internamente em um processamento, dentro de um período de tempo.”
(MELO, 2004: 187).
O diagrama de atividades foi redesenhado na UML 2.0. Esse tipo de diagrama
é orientado a fluxo de controle e tem como objetivo representar o estado de uma
atividade e também pode ser utilizado para auxiliar a modelagem de um cenário no
diagrama de caso de uso.
Segundo Booch (2000: 258-265), os diagramas costumam conter os
seguintes elementos:
• Estado de inicio, ou estado inicial;
• Estado de parada, ou estado final;
• Estado de Ação e Atividade;
• Ponto de Transição;
• Ponto de Ramificação e Intercalação;
• Bifurcação e União;
81
• Raias de Natação;
• Fluxo de Objeto.
Podemos ver esses elementos nos diagramas das figuras 39 e 40, e a
explicação de cada um deles em seguida.
Figura 39: Elementos de Diagrama de Atividades. (BEZERRA, 2002: 229)
O estado inicial e o estado final do diagrama são representados por um
circulo cheio e um círculo cheio com outro círculo ao redor respectivamente.
O estado de ação e estado de atividades tem sua representação por um
retângulo com os cantos arredondados. A diferença entre esses dois estados é que
em um estado de ação é executada uma ação por vez, ação essa que não pode ser
decomposta. Já em um estado de atividade são compostos por vários estados de
ações e podem conter outros estados de atividades.
O ponto de transição é representado por uma linha contínua com uma seta
aberta que aponta para o próximo estado de ação ou estado de atividade que será
executado.
Os pontos de Ramificação e Intercalação são representados por um
losango vazio com setas entrando e saindo dele. O ponto de Ramificação possui
uma seta entrando e várias saindo, sendo que na saída, somente um caminho será
seguindo de acordo com a condição estabelecida. O ponto de Intercalação possui
82
várias setas entrando e somente uma saindo, é utilizado para marcar o fim de um
ponto de Ramificação.
Na figura 40 podemos observar os seguintes elementos: Bifurcação e União,
Raias de Natação e Fluxo de Objeto.
Figura 40: Aplicação de Raias de Natação (swim lanes) . (BOOCH, 2000: 265)
As Raias de Natação são compostas por um grande retângulo dividido
verticalmente de acordo com as responsabilidades. Na figura 40 podemos observar
as raias do Cliente, Vendas e Estoque, cada uma com suas responsabilidades e
seus fluxos. Nota-se que as transições podem cruzar as raias, mas as atividades
pertencem a uma única raia.
A Bifurcação e União, também chamada de barra de sincronização, é
representada na figura 40 por uma linha grossa na horizontal, mas também pode
estar na vertical. São utilizadas para modelar atividades concorrentes (que
83
acontecem ao mesmo tempo). A Bifurcação permite a entrada de um fluxo de
controle e o divide em dois ou mais fluxos de controle. A União permite a entrada de
dois ou mais fluxos de controle e os sincronizam em apenas um fluxo de controle na
saída, 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
Capítulo 4. Estudo de Caso
Nesse capítulo será descrito o estudo de caso de uma locadora de veículos
onde serão abordados os conceitos da análise orientada a objetos apresentados
anteriormente.
4.1 – Definição do Ambiente e Escopo do Software
Conforme visto no item 1.3 (O projeto de software), é necessário antes de
iniciar a construção do software, se faça alguns levantamentos preliminares e um
planejamento para que o produto final saia como o esperado.
4.1.1 – Apresentação do ambiente A empresa ‘Freedom Rent a Car’44 é do ramo de locação de veículos, ela
pretende instalar sua primeira loja da rede no aeroporto de Guarulhos dentro de
setenta dias que contará com dez funcionários, sendo cinco agentes de locação,
cinco manobristas e o proprietário que gerenciará o negócio. O horário de
funcionamento da agência será vinte e quatro horas por dia, sete dias por semana
durante todos os dias do ano (24 x 7 x 365) sendo que somente os agentes e os
manobristas trabalharão em regime de escala, o gerente, que é o proprietário da
frota45, trabalhará de segunda a sexta no horário comercial ficando acessível para
sanar eventuais problemas ou dúvidas nos finais de semana e feriados. A frota de
veículos será composta inicialmente de 30 veículos sendo divididos em grupos46 de
“A” a “P” de várias marcas, modelos e anos de fabricação todos os grupos com
preços diferenciados para cada tipo de cliente e para cada época do ano.
O escritório contará com uma infra-estrutura enxuta, porém eficaz, contendo
duas estações (um microcomputador para o agente e um notebook47 de uso do
gerente) ambos com acesso à banda larga.
44 O nome da empresa é fictícia para preservar sua identidade. 45 Frota: São todos os veículos pertencentes a uma agencia de locação de veículos. 46 Grupo: São conjuntos de veículos que tem as mesmas características tais como: tamanho, potencia, valor, etc. 47 Microcomputador pequeno, leve e portátil.
85
Após a informatização, em uma etapa futura, será elaborada uma página na
Internet que permitirá aos clientes fazerem reservas48 on-line, esse servidor Web
terá a criação e manutenção de sua página feita por uma empresa terceirizada e a
hospedagem do servidor onde estarão 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/mês e estima seu
custo mensal em R$ 60.000,00. A empresa planeja adquirir um sistema para o
controle operacional de locações de veículos (reservas, locações, cadastros,
cobranças) o qual deverá prever comunicação para o sistema administrativo,
financeiro e contábil que será implantado no futuro.
4.1.2 – Declaração do Objetivo Geral do Sistema
Controlar as reservas, locações e cobrança de um sistema de locadora de
veículos. Não estão inclusos os controles financeiros, contábeis.
Objetivo e Escopo do Projeto
O projeto completo da locadora abrange toda uma infra-estrutura de hardware
e software. Apesar de estarem relacionados alguns itens que não fazem parte desse
trabalho, por outro lado, eles fazem parte do escopo do projeto.
Temos como objetivo a informatização de todas as rotinas operacionais de
uma locadora de veículos, incluindo:
• Instalação de uma rede local com acesso a Internet;
• Construção de sistema, utilizando tecnologia Orientada a Objetos, para
controlar a área operacional de locação de veículos50. Deve-se prever que,
futuramente, existirá comunicação desse sistema com as áreas
administrativas, financeiras e contábeis.
• Construção de interface gráfica (front end);
48 Reserva: Manter o veículo correspondente a um grupo específico reservado para um cliente para um dia e horário pré-determinado. 49 Data-Center: Local especializado para hospedagem de equipamentos de informática de médio e grande porte, por exemplo: servidores. 50 Esse objetivo é o foco do estudo de caso.
86
• Instalação de servidor de banco de dados;
• Prever a implementação de interface Web no sistema para futura
implantação.
4.1.3 – Estudo de Viabilidade Estudo de Viabilidade Técnica
• Plataforma51 Windows;
• O servidor utilizará sistema de redundância52 R.A.I.D.53 com
multiprocessamento54 utilizando sistema operacional Windows 2003 Server55,
Sistema Gerenciador de Banco de Dados SQL Server56 e servidor IIS57 com suporte
a ASP58;
• O acesso à banda larga deve ter uma taxa real de, no mínimo, 1Mbps59.
• Devido à falta de recurso na equipe de desenvolvimento será necessária a
contratação de profissionais para auxiliar no desenvolvimento, implantação e demais
atividades durante o projeto.
Estudo de Viabilidade Operacional
Partindo-se do princípio de que na locadora de veículos está sendo
inaugurada e não existem rotinas operacionais implantadas, pode-se analisar o
seguinte impacto operacional:
51 É uma expressão utilizada para denominar a tecnologia empregada em determinada infra-estrutura, garantindo facilidade de integração dos diversos elementos dessa infra-estrutura. 52 A redundância de interfaces de rede, de processadores, de servidores, de fontes de alimentação interna mantém o perfeito funcionamento do sistema mesmo em caso de falhas de componentes ou sobrecargas do sistema. 53 Abreviação do termo inglês Redundant Array of Inexpensive Disks que significa Disposição Redundante de Discos Baratos, cuja finalidade é manter várias cópias de dados para contornar possíveis falhas de hardware. 54 É a capacidade de um computador executar simultaneamente dois ou mais processos. 55 Tipo de software básico, abordado no item 1.2.2, cujo fabricante é a Microsoft. 56 Software aplicativo responsável pelo gerenciamento de uma base de dados 57 O IIS (Internet Information Services) é um servidor de páginas web criado pela Microsoft. 58 Abreviação do termo em inglês Active Server Pages. É uma linguagem de programação que, juntamente com o software aplicativo IIS, permite que sejam disponibilizadas páginas para Web. 59 O megabit por segundo (mbps or mbit/s) é uma unidade de transmissão de dados.
87
• Dificuldade dos agentes na utilização do sistema para atender as rotinas
da locadora;
• Todos os agentes são da área de locação de veículos e operavam
diferentes sistemas.
Acredita-se que o treinamento de cinco dias proposto para os usuários seja o
suficiente para suprir essa dificuldade operacional.
Estudo de Viabilidade Financeira
Estão inclusos no projeto o fornecimento de todos os equipamentos para
deixar o ambiente totalmente operacional (micros, servidores multi-processados com
sistema de redundância RAID, micro portátil, equipamentos e infra-estrutura de rede,
assim como, todos os custos com sistemas operacionais, sistema de rede, banco de
dados).
Também estão contabilizados os custos com os profissionais envolvidos no
desenvolvimento do sistema e do projeto como um todo.
4.1.4 – Planejamento das Atividades
A apresentação do planejamento de atividades pode ser feita em uma tabela,
em forma de organograma, textual, entre outras. Optou-se pela apresentação do
planejamento de atividades na forma do gráfico de Gantt60.
Item Atividades Recursos humanos
A Analisar e levantar de requisitos Analista de sistema B Fazer projeto de T.I61. e S.I. Projetista C Compras e Entrega de produtos de T.I e S.I. Comprador D Criar banco de dados Projetista de banco de dados E Gerar código fonte62 para programa de interface
do usuário Projetista de interface do usuário
60 O Gráfico de Gantt é uma das formas de se fazer uma apresentação visual gráfica dos itens do planejamento O QUE, POR QUE, QUEM, QUANDO, COMO e ONDE abordados no item 1.3.3. 61 Abreviação de Tecnologia da Informação. Serve para designar o conjunto de recursos tecnológicos e computacionais para geração e uso da informação. 62 É o conjunto de palavras escritas de forma ordenada, contendo instruções em uma das linguagens de programação existentes no mercado, de maneira lógica.
88
F Executar teste de funcionabilidade no sistema Verificador G Integrar equipamentos e sistemas Integrador de sistema H Elaborar treinamento para usuários Desenvolvedor de curso I Auditoria do sistema em produção. Auditor de sistema
Tabela 3: Tabela de Atividades x Recursos Humanos
Figura 41: Disposição das Atividades no gráfico de Gantt
4.2 – Levantamento de Requisitos do Software
Vimos no item 2.5 (Requisitos de software) que é necessário utilizar alguns
artifícios para visualizar o sistema que o cliente deseja, pois muitas vezes a
comunicação não é clara e o projeto pode não atender as necessidades do
ambiente.
Nesse estudo de caso, para fazer o levantamento de requisitos do software,
optou-se por fazer algumas entrevistas primeiramente com o gerente para ‘entender’
como funciona o negócio e posteriormente elaborou-se um questionário63 e a técnica
de brainstorming para obter informações.
Participaram das demais entrevistas e da reunião de Brainstorming o gerente
e cinco agentes. Foram abordados procedimentos, rotinas, suas responsabilidades e
coletados alguns documentos com a finalidade de gerar artefatos para o projeto.
63 O questionário utilizado para o levantamento de requisitos encontra-se no Anexo B.
89
4.2.1 – Análise e especificação de requisitos.
Com base nas entrevistas realizadas levantaram-se os seguintes requisitos,
abaixo enumerados precedidos pela letra R.
Requisitos Funcionais R1 - O cliente poderá fazer a reserva, por telefone ou pessoalmente, tanto o
cliente quanto o agente receberão o código da reserva.
R2 - A reserva deverá ser cancelada automaticamente uma hora após a hora
prevista para retirada do veículo;
R3 - O cliente poderá solicitar o cancelamento ou alteração da reserva por
telefone ou pessoalmente;
R4 - O sistema deve permitir que o usuário, de acordo com o tipo de perfil,
possa inserir, consultar, alterar e cancelar dados do: cadastro de veículos, cadastro
de clientes, cadastro de tarifas de locação, dados da reserva, contrato de locação e
informações da agência;
R5 - O sistema deve permitir a abertura do contrato de locação onde serão
inseridos os dados do cliente, dados do veículo a ser locado pelo cliente, data e hora
da retirada e sua previsão de retorno, dados do seguro;
R6 - Para liberar o veículo64 ao cliente, o programa deverá fazer uma pré-
autorização (on-line) junto à administradora de cartão no valor correspondente ao
grupo e o período que o veículo ficará locado;
R7 - Para fazer o fechamento do contrato de locação o programa deve
solicitar o número do contrato de locação, código do veículo, quilometragem de
chegada, quantidade de combustível, código do agente e forma de pagamento;
R8 - Para fazer o pagamento o sistema fará uma transação on-line efetuando-
o na forma escolhida pelo cliente (cartão de débito ou crédito), o número da
autorização 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 através do recebimento de um e-mail e também permitir a impressão dos
dados de reserva em uma impressora;
64 Liberação do veiculo: As chaves são entregues ao cliente juntamente com uma via do contrato de locação e o cliente e o veículo são liberados.
90
R10 - O sistema deve avisar o agente sempre que o veículo atingir a
quilometragem de revisão, data do licenciamento e / ou vistoria, data ou
quilometragem prevista para venda;
R11 - Quando o veículo precisar de manutenção ou qualquer outro tipo de
serviço, o veículo tem o status alterado saindo de “Disponível” para “Manutenção”;
Requisitos Não-Funcionais • A base de dados deve ser protegida permitindo acesso apenas aos
usuários autorizados;
• O tempo de resposta do sistema não deve ultrapassar cinco segundos;
• O servidor deverá ter infra-estrutura para permanecer ligado 24hs/dia;
• O sistema deverá ter uma comunicação on-line com as administradoras de
cartões via Internet.
4.3 – Regras de negócios
Conforme visto no item 3.4.1, antes de iniciar a descrição dos casos de uso,
precisamos relacionar as regras do negócio. Em nosso estudo de caso foram
levantadas as seguintes regras de negócio:
RN01. Pré-requisito para locação.
O cliente (motorista) deve ter no mínimo 21 anos de idade, possuir CNH a
mais de 2 anos e cartão de crédito com limite disponível para fazer a pré-autorização
ambos válidos até o final da locação.
RN02. Locação de veículo
O cliente poderá alugar um veículo com ou sem reserva, a diferença é que a
reserva garante a disponibilidade de um grupo de veículo específico para um dia e
horário determinado pelo cliente.
RN03. Quantidade máxima de locações por vez.
Pessoa física poderá fazer apenas uma locação por vez, pessoa jurídica
poderá alugar mais de um.
RN04. Período de locação.
91
Para pessoa física uma locação não pode durar mais do que 30 dias, caso
isso aconteça o cliente deve retornar a agencia para renovar o contrato. Para
pessoa jurídica não existe prazo máximo para devolução.
RN05. Alteração da reserva
A reserva poderá ser alterada a qualquer momento desde que a mesma ainda
esteja válida no sistema.
RN06. Cancelamento automático da reserva.
A reserva feita pelo cliente perderá validade caso o mesmo não compareça
na agência para retirar o veículo em até uma hora após o prazo para retirada
estipulada no ato da reserva.
RN07. Contrato de locação
O contrato de locação poderá ser modificado a qualquer momento para a
substituição do veículo caso o alugado apresente problemas.
RN08. Venda do veículo.
A locadora deverá vender o veículo quando o mesmo atingir 50.000Km ou 2
anos (o que atingir primeiro).
92
4.4 – Diagrama de Caso de Uso
No anexo E (‘Detalhes do Diagrama de Caso de Uso’) pode-se obter uma
relação dos itens do diagrama do caso de uso e seus respectivos relacionamentos.
Figura 42: Diagrama de Caso de Uso – Locadora de Veículos
Lista de Casos de Uso
De acordo com o diagrama de caso de uso acima, temos a seguinte lista de
caso de uso:
• Controlar Cobrança;
93
o Efetuar Pagamento com Cheque;
o Efetuar Pagamento Faturado;
o Fazer Pagamento com Cartão;
o Fazer Pré-Autorização;
o Validar Cartão;
• Controlar Contrato;
o Abrir Contrato de Locação;
o Alterar Contrato de Locação;
o Fechar Contrato de Locação;
o Cancelar Contrato de Locação;
• Controlar Reserva;
o Incluir Reserva;
o Alterar Reserva;
o Consultar Reserva;
o Excluir Reserva;
• Emitir Relatório;
o Emitir Relatório de Cliente;
o Emitir Relatório de Veículos;
o Emitir Relatório de Contratos;
• Fazer Cadastro;
o Manter Cadastro de Veículo;
Incluir Veículo;
Alterar Veículo;
Excluir Veículo;
o Manter Cadastro de Usuário;
Incluir Usuário;
Alterar Usuário;
Excluir Usuário;
o Manter Cadastro de Cliente;
Incluir Cliente;
Alterar Cliente;
Excluir Cliente;
o Manter Cadastro de Tarifa;
Incluir Tarifa;
94
Alterar Tarifa;
Excluir Tarifa;
4.4.1 – Descrição dos Cenários Para este trabalho não se tornar repetitivo, não serão abordados todos os
casos de uso apresentados. Serão descritos apenas os casos de uso referente ao
pacote: ‘Controlar Cobrança’ por ser o mais complexo e por conter todos os
elementos dos outros casos de uso.
Controlar Cobrança (CSU01)
Sumário: O usuário pode: efetuar diversos tipos de pagamentos e fazer pré-
autorização através da administradora de cartão.
Ator Primário: Usuário Ator Secundário: Adm Cartao (Administradora de Cartão)
Fluxo Principal: 1) O usuário seleciona opção ‘Fechar Contrato’ e seleciona a opção ‘Efetuar
Pagamento’.
2) O usuário entra com o valor e data do pagamento, e escolhe uma das opções
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) Lança 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 locação e o caso de uso
termina.
2.3) Se pagamento faturado. Verificar o caso de uso CSU03.
2.4) Se pagamento com cartão. Verificar o caso de uso CSU04.
Efetuar Pagto Cheque (CSU02)
Sumário: Usuário efetua pagamento da locação com cheque.
Ator Primário: Usuário Fluxo Principal:
95
1) O sistema solicita ao usuário os seguintes dados adicionais de cobrança:
1.1) Nome do banco;
1.2) Número do banco;
1.3) Número da agência;
1.4) Nome da agência;
1.5) Número do cheque;
1.6) Data de emissão 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.
Pós-condições: Atualiza o status do contrato de locação e o caso de uso termina.
Efetuar Pagto Faturado (CSU03) Sumário: Usuário efetua faturamento da locação.
Ator Primário: Usuário Fluxo Principal:
1) O sistema solicita ao usuário os seguintes dados adicionais de cobrança:
1.1) Razão Social;
1.2) CNPJ (Cadastro Nacional de Pessoa Jurídica);
1.3) Endereço completo;
1.4) Telefone;
1.5) Contato;
1.6) Número da Autorização 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.
Pós-condições: Atualiza o status do contrato de locação e o caso de uso termina.
Fazer Pagto Cartao (CSU04) Sumário: Cliente faz pagamento através de cartão.
Ator Primário: Usuário Ator Secundário: Adm Cartao (Administradora de Cartão)
Fluxo Principal: 1) O sistema solicita ao usuário os seguintes dados adicionais de cobrança:
96
1.1) Número do cartão;
1.2) Validade do cartão;
1.3) Digito de segurança do cartão.
2) O usuário confirma os dados e o sistema envia os dados para validação.
Include (Validar Cartao);
3) O sistema envia dados para administradora e recebe o número da autorização.
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 cartão está congestionado.
a) O sistema informa que a administradora de cartão 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 disponível no cartão de crédito é insuficiente. O
caso de uso retorna ao passo 1.
Pós-condições: O sistema armazena o número da autorização no cadastro de
contrato.
Validar Cartão (CSU05) Sumário: O sistema valida o cartão de crédito do cliente junto à administradora do
cartão.
Ator Primário: Usuário Ator Secundário: Adm Cartao (Administradora de Cartão)
Fluxo Principal: 1) O caso de uso recebe os dados do cartão, o valor, e o digito de segurança;
2) O sistema comunica-se com a administradora do cartão que faz a validação;
3) O sistema envia para a administradora os dados do cartão e valor para
pagamento;
4) O sistema recebe da administradora de cartão o número da transação e o
caso de uso termina.
Fluxo Alternativo (3): Sistema da administradora de cartão está congestionado.
a) O status do erro é enviado e o caso de uso termina.
97
4.5 – Diagrama de Classes
No anexo F (‘Detalhes do Diagrama de Classes’) pode-se obter uma relação
com mais detalhes dos itens abordados pelo diagrama de classes e suas respectivas
associações.
Figura 43: Diagrama de Classes – Locadora de Veículos
98
4.6 – Diagrama de Seqüência
No anexo G (Detalhes do Diagrama de Seqüência ‘Controlar Cobranca’)
pode-se obter uma relação detalhada dos itens do diagrama de seqüência referente
ao caso de uso ‘Controlar Cobranca’.
Figura 44: Diagrama de Seqüência - Parte 1/2
99
Continuação do diagrama anterior.
Figura 45: Diagrama de Seqüência - Parte 2/2
100
4.7 – Diagrama de Atividade
Figura 46: Diagrama de atividade do pacote ‘Controlar Cobrança’
No anexo H (Detalhes do Diagrama de Atividade ‘Controlar Cobranca’) pode-
se obter uma relação detalhada dos itens do diagrama de seqüência referente ao
caso de uso ‘Controlar Cobranca’.
101
Anexo A – Modelo de Descrição de Caso de Uso Modelo de descrição de caso de uso sugerido por Bezerra (2002:84)
102
Anexo B – Questionário utilizado no levantamento de requisitos
1) Quais as opções que o cliente terá para fazer uma reserva? O cliente poderá fazer a reserva telefonando ou comparecendo pessoalmente
na agência.
2) Quais os dados necessários para o cliente fazer uma reserva? Para fazer uma reserva o cliente deve fornecer: data e hora de retirada, data
e hora devolução, número do cliente (se houver), tipo de veículo, optar pelo tipo de
seguro (opcional), nome completo, telefone, optar pelo tipo de tarifa (corporativa ou
pessoal).
3) Como o cliente irá se referenciar a uma reserva? O sistema deverá fornecer um código de reserva para que será solicitado no
ato da abertura de contrato65 de locação ou para um eventual cancelamento ou
alteração da reserva.
4) Como o cliente deverá proceder para cancelar uma reserva? O cliente somente poderá cancelar uma reserva telefonando ou
comparecendo na agência informando o código da reserva.
5) Como o cliente saberá quais veículos, marcas e modelos estarão disponíveis para locação?
Existe uma relação de veículos separada por grupos de “A” a “P” onde cada
grupo é composto por vários veículos, de marcas e modelos diferentes e deverão
estar disponíveis no sistema e futuramente na web.
6) Quais os pré-requisitos para o cliente alugar um veículo? Será exigido que o motorista tenha mais de 21 anos, habilitado a mais de 2
anos e com carteira de habilitação válida até o final do contrato de locação. Para
pessoa física será possível fazer apenas uma locação por vez, pessoa jurídica
poderá alugar mais de um.
7) Quando o sistema estiver disponível na web, como o agente ficará sabendo que existe uma reserva de veículo quando esta for feita pela Internet?
Após o cliente preencher todas as informações na página 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: São inseridos os dados necessários no contrato (dados do cliente, veículo, seguro, pré-autorização, etc) para que o cliente seja liberado com o veículo.
103
8) Quais as formas de pagamento possíveis? Serão aceitos pagamento em cartão de débito, crédito, cheque e dinheiro.
9) Como funciona o sistema de tarifas? Existe uma tabela de tarifas para cada: grupo de veículo, período de locação
(diária, semanal ou mensal), quilometragem66 livre ou controlada, faixa de
quilometragem, corporativa ou promocional e de alta ou baixa temporada.
10) Quais os documentos necessários para locação? CNH, CPF, RG, cartão de crédito válido.
11) Qual garantia será exigida do cliente para a locação de veículos? Será efetuada uma pré-autorização67 no cartão de crédito do cliente no valor
correspondente ao grupo do veículo escolhido. 12) Quem irá cadastrar e alterar os clientes, veículos, tarifas, reservas,
dados da agencia, abrir e fechar contrato? Os agentes serão responsáveis apenas por cadastrar clientes, fazer, alterar e
cancelar reservas, fazer abertura e fechamento de contrato68. Somente o gerente
terá acesso para cadastrar veículos, tarifas, dados da agencia e alterar qualquer
informação no sistema.
13) Quais dados serão exigidos para cadastrar usuários? O nome completo, login, senha e determinar os direitos de acesso.
14) Quais relatórios e consultas serão necessários e quem terá acesso e que tipo de acesso?
Relatório e consulta de cliente, veículos, locação, pagamento. Os agentes
poderão alterar somente os dados cadastrais dos clientes, os demais terão acesso
somente para visualização. O gerente deverá ter acesso completo e poderá alterar
qualquer informação.
15) Quais dados serão exigidos para efetuar o cadastro de veículos? Para cadastro do veículo quero que o sistema solicite: código do veículo,
nome do fabricante, modelo, ano, nº do chassi, placa, cor, Km, código da chave (se
houve), quantidade de portas, tipo de acessórios (ar, direção, rádio / cd), data da
66 Quilometragem: É o limite de quilometragem que o cliente tem o direito de percorrer com o veículo dentro de um prazo determinado pela tarifa sem o pagamento de taxas adicionais por quilometro rodado. 67 Pré-autorização: No ato da abertura do contrato faz-se uma cobrança no cartão de crédito do cliente com um valor pré-determinado para efeito de acionar o seguro do veículo caso seja necessário. Quando o cliente retornar com o veículo a cobrança será cancelado. 68 Fechamento do contrato: São inseridos os dados necessários no contrato (dados do veículo, dados para pagamento, etc) para a devolução do veiculo e pagamento da locação.
104
compra, data em que deve ser realizados a vistoria69 e licenciamento, data prevista
para venda.
16) Como funcionará o sistema de pagamento com cartões? O sistema deverá se comunicar com as administradoras de cartões a qual
tenho convênio para efetuar as transações on-line. Os dados dos cartões devem ser
digitados no sistema e o comprovante será impresso em uma impressora acoplada
ao computador. Os dados de pré-autorização, autorização e / ou pagamento
deverão constar no contrato.
69 Vistoria: É uma verificação do estado funcional e visual do veículo que tem por objetivo comparar qualquer avaria depois do ato de retirada até o ato da devolução.
105
Anexo C - Tabelas de Grupos de Veículos
TRA
NS.
M
M
M
M
M
M
M
M
M
DIS
TAN
CE
PER
UN
IT
14,9
16
16
,1
16,1
14
,9
14,9
12
11
14
,8
FUEL
TY
PE
GAS
G
AS
GAS
G
AS
GAS
G
AS
GAS
B
i-com
b G
AS
LITE
R
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r
FUEL
C
APA
CIT
Y
48
50
42
42
46
46
50
50
51
BO
DY
TY
PE
Sub
com
pact
S
ubco
mpa
ct
Sub
com
pact
S
ubco
mpa
ct
Sub
com
pact
S
ubco
mpa
ct
Sub
com
pact
S
ubco
mpa
ct
Sub
com
pact
ENG
INE
SIZE
1,0
1,0
1,0
1,0
1,0
1,0
1,0
1,0
1,0
DO
OR
S
2/4D
R
2/4D
R
2/4D
R
2/4D
R
2/4D
R
2/4D
R
4DR
2D
R
2/4D
R
MO
DEL
Pal
io
Uno
Mill
e Fi
esta
Fo
rd K
a C
elta
C
orsa
Win
d C
lio
Fox
Gol
MA
KE
Fiat
Fi
at
Ford
Fo
rd
GM
G
M
Ren
ault
Vol
ksw
agen
V
olks
wa g
en
GR
UPO
B B B B B B B B B
TRA
NS.
M
M
M
M
M
M
M
M
M
DIS
TAN
CE
PER
UN
IT
14,9
16
16
,1
16,1
14
,9
14,9
14
12
14
,8
FUEL
TY
PE
GAS
G
AS
GAS
G
AS
GAS
G
AS
GAS
G
AS
GAS
LITE
R
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r
FUEL
C
APA
CIT
Y
48
50
42
42
46
46
40
50
51
BO
DY
TY
PE
Sub
com
pact
S
ubco
mpa
ct
Sub
com
pact
S
ubco
mpa
ct
Sub
com
pact
S
ubco
mpa
ct
Sub
com
pact
S
ubco
mpa
ct
Sub
com
pact
ENG
INE
SIZE
1,0
1,0
1,0
1,0
1,0
1,0
1,2
1,0
1,0
DO
OR
S
2/4D
R
2/4D
R
2/4D
R
2/4D
R
2/4D
R
2/4D
R
2/4D
R
4DR
2/
4DR
MO
DEL
Pal
io
Uno
Mill
e Fi
esta
Fo
rd K
a C
orsa
Win
d C
elta
Tw
ingo
C
lio
Gol
MA
KE
Fiat
Fi
at
Ford
Fo
rd
GM
G
M
Ren
ault
Ren
ault
Vol
ksw
a gen
GR
UPO
A A A A A A A A A
GR
UP
O A
- S
UB
CO
MP
AC
T - V
EÍC
ULO
S 1
.0 S
EM
AR
CO
ND
ICIO
NA
DO
GR
UP
O B
- S
UB
CO
MP
AC
T - V
EÍC
ULO
S 1
.0 C
OM
AR
CO
ND
ICIO
NA
DO
106
TRA
NS.
M
M
M
M
M
M
M
M
M
M
M
M
M
DIS
TAN
CE
PER
UN
IT
13,9
12
,6
13,6
11
13
,9
12
12,7
10
13
,8
12
13,8
14
,7
13,8
FUEL
TY
PE
GAS
G
AS
GAS
B
i-com
b G
AS
GAS
G
AS
Bi-c
omb
GAS
G
AS
GAS
G
AS
GAS
LITE
R
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r
FUEL
C
APA
CIT
Y
48
48
42
45
46
50
48
50
51
51
51
45
45
BO
DY
TY
PE
Com
pact
C
ompa
ct
Com
pact
C
ompa
ct
Com
pact
C
ompa
ct
Com
pact
C
ompa
ct
Com
pact
C
ompa
ct
Com
pact
C
ompa
ct
Com
pact
ENG
INE
SIZE
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
DO
OR
S
2/4D
R
2/4D
R
2/4D
R
4DR
2/
4DR
4D
R
4DR
2D
R
4DR
4D
R
2/4D
R
4DR
4D
R
MO
DEL
Pal
io
Pal
io
Fies
ta
Cel
ta
Cor
sa
Clio
S
eat I
biza
Fo
x G
ol
Gol
Pow
er
Gol
P
olo
Pol
o
MA
KE
Fiat
Fi
at
Ford
G
M
GM
R
enau
lt S
eat
Vol
ksw
agen
V
olks
wa g
en
Vol
ksw
a gen
V
olks
wag
en
Vol
ksw
agen
V
olks
wa g
en
GR
UPO
D
D
D
D
D
D
D
D
D
D
D
D
D
TRA
NS.
M
M
M
M
DIS
TAN
CE
PER
UN
IT
10,6
15
14
,9
12
FUEL
TY
PE
GAS
G
AS
GAS
G
AS
LITE
R
Lite
r Li
ter
Lite
r Li
ter
FUEL
C
APA
CIT
Y
48
42
46
40
BO
DY
TY
PE
Com
pact
C
ompa
ct
Com
pact
C
ompa
ct
ENG
INE
SIZE
1,0
1,0
1,0
1,0
DO
OR
S
4DR
4D
R
4DR
4D
R
MO
DEL
Sie
na
Fies
ta S
edan
C
orsa
Sed
an
Clio
Sed
an
MA
KE
Fiat
Fo
rd
GM
R
enau
lt
GR
UPO
C
C
C
C
GR
UP
O C
- C
OM
PA
CT
- VE
ÍCU
LOS
SE
DA
N 1
.0 C
OM
AR
CO
ND
ICIO
NA
DO
GR
UP
O D
- C
OM
PA
CT
- VE
ÍCU
LOS
1.3
, 1.4
, 1.6
, 1.8
CO
M A
R C
ON
DIC
ION
AD
O
107
TRA
NS.
M
M
M
M
M
M
M
M
M
DIS
TAN
CE
PER
UN
IT
11,6
11
,1
10,3
10
12
,7
13,8
14
13
,4
13,4
FUEL
TY
PE
GAS
B
i-com
b B
i-com
b G
AS
GAS
G
AS
GAS
G
AS
GAS
LITE
R
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r
FUEL
C
APA
CIT
Y
51
51
51
51
64
46
42
51
51
BO
DY
TY
PE
Sta
tion
Weg
on
Sta
tion
Weg
on
Sta
tion
Weg
on
Sta
tion
Weg
on
Sta
tion
Weg
on
Sta
tion
Weg
on
Sta
tion
Weg
on
Sta
tion
Weg
on
Sta
tion
Weg
on
ENG
INE
SIZE
1,6
1,3
1,8
1,8
1,8
1,6
1,4
1,6
1,8
DO
OR
S
4DR
4D
R
4DR
4D
R
4DR
4D
R
4DR
4D
R
4DR
MO
DEL
Pal
io W
eeke
nd
Pal
io W
eeke
nd
Pal
io W
eeke
nd
Pal
io W
eeke
nd
Esc
ort W
agon
C
orsa
Wa g
on
FIT
Par
ati
Par
ati
MA
KE
Fiat
Fi
at
Fiat
Fi
at
Ford
G
M
Hon
da
Vol
ksw
a gen
V
olks
wa g
en
GR
UPO
F F F F F F F F F
TRA
NS.
M
M
M
M
M
M
M
M
DIS
TAN
CE
PER
UN
IT
12
10,6
12
,1
13,6
11
,3
13,9
12
12
,7
FUEL
TY
PE
GAS
G
AS
Bi-c
omb
GAS
G
AS
GAS
G
AS
GAS
LITE
R
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
FUEL
C
APA
CIT
Y
48
48
48
42
45
46
50
48
BO
DY
TY
PE
Inte
rmed
iate
In
term
edia
te
Inte
rmed
iate
In
term
edia
te
Inte
rmed
iate
In
term
edia
te
Inte
rmed
iate
In
term
edia
te
ENG
INE
SIZE
1,3
1,6
1,8
1,6
1,8
1,6
1,6
1,6
DO
OR
S
4DR
4D
R
4DR
4D
R
4DR
4D
R
4DR
4D
R
MO
DEL
Sie
na
Sie
na
Sie
na
Fies
ta S
edan
C
orsa
Sed
an M
axx
Cor
sa S
edan
C
lio S
edan
S
eat C
ordo
ba
MA
KE
Fiat
Fi
at
Fiat
Fo
rd
GM
G
M
Ren
ault
Sea
t
GR
UPO
E E E E E E E E
GR
UP
O E
- IN
TER
ME
DIA
TE -
VE
ÍCU
LOS
SE
DA
N 1
.3, 1
.6 e
1.8
CO
M A
R C
ON
DIC
ION
AD
O
GR
UP
O F
- S
TATI
ON
WA
GO
N -
VE
ÍCU
LOS
1.3
, 1.6
, 1.8
CO
M A
R C
ON
DIC
ION
AD
O
108
TRA
NS.
M
M
M
M
M
M
M
M
M
M
M
M
M
M
A M
M
M
M
DIS
TAN
CE
PER
UN
IT
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
FUEL
TY
PE
GAS
G
AS
GAS
G
AS
GAS
G
AS
GAS
G
AS
GAS
G
AS
GAS
G
AS
GAS
G
AS
GAS
G
AS
GAS
G
AS
Bi-c
omb
LITE
R
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r
FUEL
C
APA
CIT
Y
47
45
55
60
52
52
52
52
60
60
60
60
72
55
55
72
55
55
45
BO
DY
TY
PE
Full
Siz
e Fu
ll S
ize
Pre
miu
m
Full
Siz
e Fu
ll S
ize
Full
Siz
e Fu
ll S
ize
Full
Siz
e Fu
ll S
ize
Full
Siz
e Fu
ll S
ize
Full
Siz
e Fu
ll S
ize
Full
Siz
e Fu
ll S
ize
Full
Siz
e Fu
ll S
ize
Full
Siz
e Fu
ll S
ize
ENG
INE
SIZE
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
DO
OR
S
4DR
4D
R
4DR
4D
R
4DR
4D
R
4DR
2D
R
4DR
4D
R
4DR
4D
R
4DR
4D
R
4DR
4D
R
4DR
4D
R
4DR
MO
DEL
C 3
S
tilo
Focu
s R
et
Bra
va
Ast
ra S
edan
Fle
x A
stra
Sed
an
Ast
ra
Ast
ra
Mer
iva
Peu
geot
307
M
egan
e M
e gan
e S
anta
na
Gol
f G
olf
San
t. Q
uant
um
Gol
f P
olo
Sed
an
Pol
o S
edan
Fle
x
MA
KE
Citr
oen
Fiat
Fo
rd
Fiat
G
M
GM
G
M
GM
G
M
Peu
geot
R
enau
lt R
enau
lt V
olks
wa g
en
Vol
ksw
agen
V
olks
wag
en
Vol
ksw
agen
V
olks
wag
en
Vol
ksw
agen
V
olks
wag
en
GR
UPO
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
GR
UP
O G
- FU
LL S
IZE
- V
EÍC
ULO
S C
OM
AR
CO
ND
ICIO
NA
DO
109
TRA
NS.
M
M
M
M
M
M
M
M
M
M
A M
M
M
A M
DIS
TAN
CE
PER
UN
IT
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
FUEL
TY
PE
GAS
G
AS
GAS
G
AS
GAS
G
AS
GAS
G
AS
GAS
G
AS
GAS
G
AS
GAS
G
AS
GAS
G
AS
LITE
R
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
FUEL
C
APA
CIT
Y
63
63
63
57
72
75
57
57
72
65
65
65
60
55
55
63
BO
DY
TY
PE
Pre
miu
m
Pre
miu
m
Pre
miu
m
Pre
miu
m
Pre
miu
m
Pre
miu
m
Pre
miu
m
Pre
miu
m
Pre
miu
m
Pre
miu
m
Pre
miu
m
Pre
miu
m
Pre
miu
m
Pre
miu
m
Pre
miu
m
Pre
miu
m
ENG
INE
SIZE
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
DO
OR
S
4DR
4D
R
4DR
4D
R
4DR
4D
R
4DR
4D
R
4DR
4D
R
4DR
4D
R
4DR
4D
R
4DR
4D
R
MO
DEL
Mar
ea
Mar
ea
Mar
ea
Focu
s B
laze
r O
meg
a V
ectra
V
ectra
B
laze
r C
ivic
C
ivic
P
euge
ot 4
06
Lagu
na
Cor
olla
C
orol
la
Bor
a
MA
KE
Fiat
Fi
at
Fiat
Fo
rd
GM
G
M
GM
G
M
GM
H
onda
H
onda
P
euge
ot
Ren
ault
Toyo
ta
Toyo
ta
Vol
ksw
a gen
GR
UPO
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
TRA
NS.
M
M
A M
M
M
M
DIS
TAN
CE
PER
UN
IT
11,9
11
,6
9 9,8
11,6
10
10
FUEL
TY
PE
GAS
G
AS
Bi-c
omb
Bi-c
omb
Bi-c
omb
GAS
G
AS
LITE
R
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r
FUEL
C
APA
CIT
Y
55
58
58
58
58
60
60
BO
DY
TY
PE
Min
i Van
M
ini V
an
Min
i Van
M
ini V
an
Min
i Van
M
ini V
an
Min
i Van
ENG
INE
SIZE
2,0
2,0
2,0
2,0
1,8
1,6
2,0
DO
OR
S
4DR
4D
R
4DR
4D
R
4DR
4D
R
4DR
MO
DEL
Pic
asso
Za
fira
Zafir
a E
lega
nce
Zafir
a E
lite
Mer
iva
Sen
ic
Sen
ic
MA
KE
Citr
oen
GM
G
M
GM
G
M
Ren
ault
Ren
ault
GR
UPO
I I I I I I IG
RU
PO
H –
PR
EM
IUM
GR
UP
O I
- MIN
I VA
N
110
TRA
NS.
M
M
M
M
M
M
M
M
M
DIS
TAN
CE
PER
UN
IT
12,3
11
,6
11,9
13
,5
12
11,9
12
,7
13
13,9
FUEL
TY
PE
GA
S G
AS
GA
S G
AS
Bi-c
omb.
G
AS
GA
S G
AS
GA
S
LITE
R
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r
FUEL
C
APA
CIT
Y
58
64
53
57
55
53
54
54
53
BO
DY
TY
PE
Pick
up
Pick
up
Pick
up
Pick
up
Pick
up
Pick
up
Pick
up
Pick
up
Pick
u p
ENG
INE
SIZE
1,5
1,5
1,6
1,6
1,8
1,6
1,6
1,8
1,6
DO
OR
S
2DR
2D
R
2DR
2D
R
2DR
2D
R
2DR
2D
R
2DR
MO
DEL
Stra
da
Fior
ino
Cou
rier
Cor
sa
Cor
sa-M
onta
na
Sav
eiro
V
an C
arga
S
avei
ro
Save
iro F
lex
MA
KE
Fiat
Fi
at
Ford
G
M
GM
V
olks
wag
en
Vol
ksw
a gen
V
olks
wag
en
Vol
ksw
agen
GR
UPO
J J J J J J J J J
TRA
NS.
A
DIS
TAN
CE
PER
UN
IT
12
FUEL
TY
PE
GAS
LITE
R
Lite
r
FUEL
C
APA
CIT
Y
55
BO
DY
TY
PE
Pre
miu
m
ENG
INE
SIZE
1,6
DO
OR
S
4DR
MO
DEL
Cor
olla
MA
KE
Toyo
ta
GR
UPO
K
TRA
NS.
M
DIS
TAN
CE
PER
UN
IT
8,2
FUEL
TY
PE
GAS
LITE
R
Lite
r
FUEL
C
APA
CIT
Y
46
BO
DY
TY
PE
Min
ivan
ENG
INE
SIZE
1,6
DO
OR
S
2DR
MO
DEL
Kom
bi
MA
KE
Vol
ksw
agen
GR
UPO
M
GR
UP
O J
- P
ICK
UP
PEQ
UE
NA
GR
UP
O K
– A
UTO
MA
TIC
GR
UP
O M
- K
OM
BI
111
TRA
NS.
M
M
M
M
M
M
DIS
TAN
CE
PER
UN
IT
12,2
12
,2
12,2
12
12
,5
12,2
FUEL
TY
PE
Die
sel
Die
sel
Die
sel
Die
sel
Die
sel
Die
sel
LITE
R
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
FUEL
C
APA
CIT
Y
80
80
80
65
65
80
BO
DY
TY
PE
Van
V
an
Van
V
an
Van
V
an
ENG
INE
SIZE
2,0
2,0
2,0
2,6
2,0
2,5
DO
OR
S
2DR
3D
R
2DR
3D
R
3DR
2D
R
MO
DEL
Tow
ner
Duc
ato
Clu
b W
agon
H
-100
GL
Bes
ta
S prin
ter
MA
KE
Asi
a Fi
at
Ford
H
yund
ai
Kia
M
erce
des
GR
UPO
N
N
N
N
N
N
TRA
NS.
M
M
DIS
TAN
CE
PER
UN
IT
14,7
11
FUEL
TY
PE
GA
S G
AS
LITE
R
Lite
r Li
ter
FUEL
C
APA
CIT
Y
50
50
BO
DY
TY
PE
Min
i Van
M
ini V
an
ENG
INE
SIZE
1,0
1,3
DO
OR
S
3DR
4D
R
MO
DEL
Kan
goo
Dou
blo
MA
KE
Ren
ault
Fiat
GR
UPO
O
O
TRA
NS.
M
M
M
M
M
M
A M
A
DIS
TAN
CE
PER
UN
IT
9,8 8
12,3
6 7 11
7 9,7 9
FUEL
TY
PE
GAS
G
AS
GAS
D
iese
l G
AS
Die
sel
GAS
D
iese
l D
iese
l
LITE
R
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r Li
ter
Lite
r
FUEL
C
APA
CIT
Y
72
60
45
98
70
70
64
75
72
BO
DY
TY
PE
Pick
up
Pick
up
Pick
up
Pick
up
Pick
up
Pick
up
----
Pick
up
----
ENG
INE
SIZE
2,2
1,6
1,6
2,8
2,4
2,8
2,5
2,5
2,8
DO
OR
S
2DR
4D
R
4DR
4D
R
2DR
2D
R
4DR
4D
R
2DR
MO
DEL
Ran
ger
Eco
Spo
rt E
coS
port
F-25
0 X
LT W
20
S10
S
10
Free
land
er
L-20
0 T4
TD
I 4X
4
MA
KE
Ford
Fo
rd
Ford
Fo
rd
GM
G
M
Land
Rov
er
Mits
ubis
hi
Trol
ler
GR
UPO
P P P P P P P P P
GR
UP
O N
- V
AN
GR
UP
O O
– M
INI V
AN (C
OM
AR
CO
ND
ICIO
NA
DO
GR
UP
O P
- P
ICK
UP
112
Anexo D - Tabelas de Tarifas de Locação de Veículos
TARIFA STANDARD
WKI / WJI PARA: Todas as localidades PAÍS: Brasil DATA EFETIVA: 01 Março 04 VALIDADE: Indeterminada
WKI WJI WKI/WJI Grupos
SIPP Diária Semanal Mensal Km Adic.70 Hr. Adic.71 Dia Adic.72
A 79,00 474,00 1.896,00 0,45 22,58 67,72B 110,00 660,00 2.640,00 0,60 31,44 94,30C 118,00 708,00 2.832,00 0,65 33,73 101,15D 140,00 840,00 3.360,00 0,75 40,01 120,01E 149,00 894,00 3.576,00 0,80 42,58 127,72F 158,00 948,00 3.792,00 0,85 45,16 135,44G 206,00 1.236,00 4.944,00 1,10 58,87 176,58H 238,00 1.428,00 5.712,00 1,30 68,01 204,01I 265,00 1.590,00 6.360,00 1,40 75,73 227,15J 134,00 804,00 3.216,00 0,70 38,30 114,87K 258,00 1.548,00 6.192,00 1,36 73,71 221,14M 163,00 978,00 3.912,00 0,85 46,58 139,72N 325,00 1.950,00 7.800,00 1,75 92,87 278,58O 227,00 1.362,00 5.448,00 1,20 64,87 194,58P 269,00 1.614,00 6.456,00 1,45 73,71 230,58
MÍN/ MÁX DIAS: WKI= 01/28, WJI= 28/31 dias
QUILOMETRAGEM: WKI = Livre, WJI = 3.000 km livres/ mês
70 Km adicional: É o valor pago pelo cliente a locadora quando a distância percorrida pelo veículo foi maior que a contratada. 71 Hora adicional: É o valor pago pelo cliente a locadora quando há atraso na devolução do veiculo em até 23 horas. 72 Dia adicional: É o valor pago pelo cliente a locadora quando há atraso na devolução do veiculo entre 1 a 6 dias.
113
TARIFA 2CI
DIÁRIA KM LIVRE PARA: Todas as localidades PAÍS: Brasil DATA EFETIVA: 01 Março 04 VALIDADE: Indeterminada
Grupos Diária Semanal Mensal Hora adic. Dia adic. A 61,00 20,34 B 85,00 28,34 C 91,00 30,34 D 109,00 36,34 E 115,00 38,34 F 122,00 40,68 G 160,00 53,34 H 184,00 61,34 I 205,00 68,34 J 104,00 34,68 M 126,00 42,01 N 252,00 84,01 O 176,00 58,68 P 208,00 69,34
MÍN/ MÁX DIAS: 1/6
QUILOMETRAGEM: Livre
114
TARIFA 2NI
SEMANAL – KM LIVRE PARA: Todas as localidades PAÍS: Brasil DATA EFETIVA: 01 Março 04 VALIDADE: Indeterminada
Grupos Diária Semanal Mensal Hora adic. Dia adic. A 367,00 17,49 52,43B 512,00 24,39 73,14C 549,00 26,15 78,43D 651,00 31,01 93,00E 693,00 33,01 99,00F 735,00 35,01 105,00G 958,00 45,63 136,86H 1.107,00 52,72 158,14I 1.232,00 58,68 176,00J 623,00 29,68 89,00M 758,00 36,11 108,29N 1.511,00 71,96 215,86O 1.056,00 50,30 150,86P 1251,00 59,58 178,71
MÍN/ MÁX DIAS: 6/30
QUILOMETRAGEM: Livre
115
TARIFA HPI
100 KM LIVRES PARA: Todas as localidades PAÍS: Brasil DATA EFETIVA: 01 Março 04 VALIDADE: Indeterminada
Grupos Diária Semanal Dia adic. Hora adic. Km adic. A 51,00 308,00 44,01 17,13 0,45B 72,00 429,00 61,29 23,84 0,60C 77,00 460,00 65,74 25,58 0,65D 91,00 546,00 78,00 30,34 0,75E 97,00 581,00 83,01 32,29 0,80F 103,00 616,00 88,03 34,24 0,85G 134,00 803,00 114,77 44,64 1,10H 155,00 928,00 132,60 51,58 1,30I 172,00 1.034,00 147,64 57,43 1,40J 87,00 523,00 74,66 29,04 0,70M 106,00 636,00 90,81 35,33 0,85N 211,00 1.268,00 181,07 70,43 1,75O 148,00 885,00 126,47 49,19 1,20P 175,00 1.049,00 149,87 58,29 1,45
MÍN/ MÁX DIAS: 1/28
QUILOMETRAGEM: 100 Km livres/dia
116
TARIFA BPI
KM CONTROLADA PARA: Todas as localidades PAÍS: Brasil DATA EFETIVA: 20 Jun 03 VALIDADE: Indeterminada
Grupos Diária Semanal Dia adic. Hora adic. Km rodado A 27,75 9,26 0,45B 40,50 13,51 0,60C 43,00 14,34 0,65D 52,50 17,51 0,75E 55,75 18,59 0,80F 59,00 19,68 0,85G 77,50 25,84 1,10H 87,50 29,18 1,30I 100,75 33,59 1,40J 51,50 17,18 0,70M 62,75 20,93 0,85N 121,25 40,43 1,75O 86,25 28,76 1,20P 100,25 33,43 1,45
MÍN/ MÁX DIAS: 1/ 7
QUILOMETRAGEM: Controlada
117
TARIFA JMI
MENSAL – 3.000 KM LIVRES PARA: Todas as localidades PAÍS: Brasil DATA EFETIVA: 01 Março 04 VALIDADE: Indeterminada
Grupos Mensal Semana adic.73
Dia adic. Hora adic. Km adic.
A 1.109,00 277,00 39,61 13,21 0,45B 1.544,00 386,00 55,16 18,40 0,60C 1.657,00 414,00 59,17 19,73 0,65D 1.966,00 491,00 70,20 23,41 0,75E 2.092,00 523,00 74,71 24,91 0,80F 2.218,00 555,00 79,23 26,42 0,85G 2.892,00 723,00 103,29 34,44 1,10H 3.342,00 835,00 119,34 39,79 1,30I 3.721,00 930,00 132,88 44,30 1,40J 1.881,00 470,00 67,19 22,41 0,70M 2.289,00 572,00 81,73 27,25 0,85N 4.563,00 1.141,00 162,96 54,33 1,75O 3.187,00 797,00 113,82 37,95 1,20P 3.777,00 944,00 134,88 44,97 1,45
MÍN/ MÁX DIAS: 28/ 30
QUILOMETRAGEM: 3.000 km livres/mês
73 Semana adicional: É o valor pago pelo cliente a locadora quando há atraso na devolução do veiculo entre 1 a 3 semanas.
118
TARIFA 51I
CORPORATE NÃO-DESCONTÁVEL PARA: Todas as localidades PAÍS: Brasil DATA EFETIVA: Abril 04 VALIDADE: Indeterminada
Grupos Diária Semanal Mensal Hora adic. Dia adic. A 67,00 402,00 1.005,00 19,15 57,43B 94,00 564,00 1.410,00 26,87 80,57C 100,00 600,00 1.500,00 28,58 85,71D 119,00 714,00 1.785,00 34,01 102,00E 127,00 762,00 1.905,00 36,30 108,86F 134,00 804,00 2.010,00 38,30 114,86G 175,00 1.050,00 2.625,00 50,01 150,00H 202,00 1.212,00 3.030,00 57,72 173,14I 225,00 1.350,00 3.375,00 64,30 192,86J 114,00 684,00 1.710,00 32,58 97,71M 139,00 834,00 2.085,00 39,72 119,14N 276,00 1.656,00 4.140,00 78,87 236,57O 193,00 1.158,00 2.895,00 55,15 165,43P 229,00 1.374,00 3.435,00 65,44 196,29
MÍN/ MÁX DIAS: 1/ não há
QUILOMETRAGEM: Livre
119
Anexo E – Detalhes do Diagrama de Caso de Uso
Diagram Content Summary
• Sistema de Locadora de Veiculos • Pacote de Controle de Cobranca • Pacote de Controle de Contrato • Pacote de Controle de Relatorios • Pacote de Controle de Cadastro • Pacote de Controle de Reservas • Fazer Pagto Cartao • Validar Cartao • Fazer Pre-Autorizacao • Efetuar Pagto Faturado • Efetuar Pagto Cheque • Controlar Cobranca • Abrir Contrato • Alterar Cadastro • Fechar Contrato • Controlar Contrato • Cancelar Contrato • Relatorio de Contratos • Relatorio de Cliente • Relatorio de Veiculos • Emitir Relatorio • Controlar Cadastro • Manter Dados de Usuario • Manter Dados de Tarifa • Manter Dados de Cliente • Manter Dados de Veiculo • Consultar Reserva • Manter Dados de Reversa • Manter Dados... • Incluir Dados... • Alterar Dados... • Excluir Dados... • Usuario • Gerente • Adm Cartao • Agente
Diagram Content Detail
UseCase Fazer Pagto Cartao Parent : Pacote de Controle de Cobranca Include: Validar Cartao Super Class
120
Controlar Cobranca
UseCase Validar Cartao Parent : Pacote de Controle de Cobranca Include by: Fazer Pagto Cartao, Fazer Pre-Autorizacao Communication Link communicationlink to Adm Cartao
UseCase Fazer Pre-Autorizacao Parent : Pacote de Controle de Cobranca Include: Validar Cartao, Abrir Contrato
UseCase Efetuar Pagto Faturado Parent : Pacote de Controle de Cobranca Super Class Controlar Cobranca
UseCase Efetuar Pagto Cheque Parent : Pacote de Controle de Cobranca Super Class Controlar Cobranca
UseCase Controlar Cobranca Parent : Pacote de Controle de Cobranca Subclasses Efetuar Pagto Cheque, Fazer Pagto Cartao, Efetuar Pagto Faturado Communication Link communicationlink to Adm Cartao Communication Link communicationlink to Usuario
UseCase Abrir Contrato Use Case Extends Hierarchy Controlar Contrato | +-Abrir Contrato Parent : Pacote de Controle de Contrato Include by: Fazer Pre-Autorizacao Extended by Consultar Reserva Extension Point Name : ExtensionPoint Extend from Controlar Contrato Super Class Controlar Contrato
UseCase Alterar Cadastro Use Case Extends Hierarchy Controlar Contrato | +-Alterar Cadastro Parent : Pacote de Controle de Contrato
121
Extend from Controlar Contrato Super Class Controlar Contrato
UseCase Fechar Contrato Use Case Extends Hierarchy Controlar Contrato | +-Fechar Contrato Parent : Pacote de Controle de Contrato Extend from Controlar Contrato Super Class Controlar Contrato
UseCase Controlar Contrato Parent : Pacote de Controle de Contrato Extended by Abrir Contrato, Fechar Contrato, Alterar Cadastro, Cancelar Contrato Extension Point Name : ExtensionPoint Name : ExtensionPoint Name : ExtensionPoint Name : ExtensionPoint Name : ExtensionPoint Name : ExtensionPoint Subclasses Abrir Contrato, Fechar Contrato, Alterar Cadastro Communication Link communicationlink to Usuario
UseCase Cancelar Contrato Use Case Extends Hierarchy Controlar Contrato | +-Cancelar Contrato Parent : Pacote de Controle de Contrato Extend from Controlar Contrato
UseCase Relatorio de Contratos Use Case Extends Hierarchy Emitir Relatorio | +-Relatorio de Contratos Parent : Pacote de Controle de Relatorios Extend from Emitir Relatorio Super Class Emitir Relatorio
UseCase Relatorio de Cliente Use Case Extends Hierarchy Emitir Relatorio | +-Relatorio de Cliente
122
Parent : Pacote de Controle de Relatorios Extend from Emitir Relatorio Super Class Emitir Relatorio
UseCase Relatorio de Veiculos Use Case Extends Hierarchy Emitir Relatorio | +-Relatorio de Veiculos Parent : Pacote de Controle de Relatorios Extend from Emitir Relatorio Super Class Emitir Relatorio
UseCase Emitir Relatorio Parent : Pacote de Controle de Relatorios Extended by Relatorio de Cliente, Relatorio de Contratos, Relatorio de Veiculos Extension Point Name : ExtensionPoint Name : ExtensionPoint Name : ExtensionPoint Name : ExtensionPoint Subclasses Relatorio de Cliente, Relatorio de Contratos, Relatorio de Veiculos Communication Link communicationlink to Gerente
UseCase Controlar Cadastro Parent : Pacote de Controle de Cadastro Extended by Manter Dados de Cliente, Manter Dados de Veiculo, Manter Dados de Usuario, Manter Dados de Tarifa Extension Point Name : ExtensionPoint Name : ExtensionPoint Name : ExtensionPoint Name : ExtensionPoint Subclasses Manter Dados de Cliente, Manter Dados de Tarifa, Manter Dados de Usuario, Manter Dados de Veiculo Communication Link communicationlink to Gerente
UseCase Manter Dados de Usuario Use Case Extends Hierarchy Controlar Cadastro | +-Manter Dados de Cliente | +-Manter Dados de Usuario Parent : Pacote de Controle de Cadastro Extend from Controlar Cadastro Manter Dados de Cliente
123
Super Class Controlar Cadastro
UseCase Manter Dados de Tarifa Use Case Extends Hierarchy Controlar Cadastro | +-Manter Dados de Tarifa Parent : Pacote de Controle de Cadastro Extend from Controlar Cadastro Super Class Controlar Cadastro
UseCase Manter Dados de Cliente Use Case Extends Hierarchy Controlar Cadastro | +-Manter Dados de Cliente Parent : Pacote de Controle de Cadastro Extended by Manter Dados de Usuario Extension Point Name : ExtensionPoint Extend from Controlar Cadastro Super Class Controlar Cadastro Communication Link communicationlink to Usuario
UseCase Manter Dados de Veiculo Use Case Extends Hierarchy Controlar Cadastro | +-Manter Dados de Veiculo Parent : Pacote de Controle de Cadastro Extend from Controlar Cadastro Super Class Controlar Cadastro
UseCase Consultar Reserva Use Case Extends Hierarchy Manter Dados de Reversa | +-Controlar Contrato | +-Abrir Contrato | +-Consultar Reserva Parent : Pacote de Controle de Reservas Extend from Manter Dados de Reversa Abrir Contrato
UseCase Manter Dados de Reversa Parent : Pacote de Controle de Reservas Extended by Consultar Reserva Extension Point Name : ExtensionPoint
124
Subclasses UseCase Communication Link communicationlink to Usuario
UseCase Manter Dados... Parent : Sistema de Locadora de Veiculos Extended by Incluir Dados..., Alterar Dados..., Excluir Dados... Extension Point Name : Incluir Dados Name : Alterar Dados Name : Excluir Dados
UseCase Incluir Dados... Use Case Extends Hierarchy Manter Dados... | +-Incluir Dados... Parent : Sistema de Locadora de Veiculos Extend from Manter Dados...
UseCase Alterar Dados... Use Case Extends Hierarchy Manter Dados... | +-Alterar Dados... Parent : Sistema de Locadora de Veiculos Extend from Manter Dados...
UseCase Excluir Dados... Use Case Extends Hierarchy Manter Dados... | +-Excluir Dados... Parent : Sistema de Locadora de Veiculos Extend from Manter Dados...
Actor Usuario Subclasses Gerente, Agente Communication Link communicationlink to Manter Dados de Cliente Communication Link communicationlink to Manter Dados de Reversa Communication Link communicationlink to Agente Communication Link communicationlink to Controlar Contrato Communication Link communicationlink to Controlar Cobranca
Actor Gerente Generalization Hierarchy Usuario | +-Gerente Super Class
125
Usuario Communication Link communicationlink to Controlar Cadastro Communication Link communicationlink to Emitir Relatorio
Actor Adm Cartao Communication Link communicationlink to Validar Cartao Communication Link communicationlink to Controlar Cobranca
Actor Agente Generalization Hierarchy Usuario | +-Agente Super Class Usuario Communication Link communicationlink to Usuario
Package Pacote de Controle de Cobranca Parent : Sistema de Locadora de Veiculos Children: Fazer Pagto Cartao, Validar Cartao, Fazer Pre-Autorizacao, Efetuar Pagto Faturado, Efetuar Pagto Cheque, Controlar Cobranca
Package Pacote de Controle de Contrato Parent : Sistema de Locadora de Veiculos Children: Abrir Contrato, Alterar Cadastro, Fechar Contrato, Controlar Contrato, Cancelar Contrato
Package Pacote de Controle de Relatorios Parent : Sistema de Locadora de Veiculos Children: Relatorio de Contratos, Relatorio de Cliente, Relatorio de Veiculos, Emitir Relatorio
Package Pacote de Controle de Cadastro Parent : Sistema de Locadora de Veiculos Children: Controlar Cadastro, Manter Dados de Usuario, Manter Dados de Tarifa, Manter Dados de Cliente, Manter Dados de Veiculo
Package Pacote de Controle de Reservas Parent : Sistema de Locadora de Veiculos Children: Consultar Reserva, Manter Dados de Reversa
System Sistema de Locadora de Veiculos Children: UseCase, Efetuar Pagto Dinheiro, Efetuar Pagto Taxa Servico, UseCase2, , UseCase3, Pacote de Controle de Cobranca, Pacote de Controle de Contrato, Pacote de Controle de Relatorios, Pacote de
126
Controle de Cadastro, Pacote de Controle de Reservas, , Manter Dados..., Incluir Dados..., Alterar Dados..., Excluir Dados...
Communication Link Communication Link End From Element : Gerente Navigable : True Visibility : Unspecified Communication Link End To Element : Controlar Cadastro Navigable : True Visibility : Unspecified
Communication Link Communication Link End From Element : Usuario Navigable : True Visibility : Unspecified Communication Link End To Element : Manter Dados de Reversa Navigable : True Visibility : Unspecified
Communication Link Communication Link End From Element : Gerente Navigable : True Visibility : Unspecified Communication Link End To Element : Emitir Relatorio Navigable : True Visibility : Unspecified
Communication Link Communication Link End From Element : Usuario Navigable : True Visibility : Unspecified Communication Link End To Element : Controlar Contrato Navigable : True Visibility : Unspecified
Communication Link Communication Link End From Element : Usuario Navigable : True Visibility : Unspecified Communication Link End To Element : Controlar Cobranca Navigable : True Visibility : Unspecified
127
Communication Link Communication Link End From Element : Adm Cartao Navigable : True Visibility : Unspecified Communication Link End To Element : Validar Cartao Navigable : True Visibility : Unspecified
128
Anexo F – Detalhes do Diagrama de Classes Diagram Content Summary
• Sistema de Locadora de Veiculos • IContrato • Cliente • Reserva • TiposDeTarifa • GrupoTarifa • GruposDeVeiculos • Contrato • Veiculo • Pagamento • Cartao • Cheque • Fatura • IPagamentoAdmCartao • ICliente • IReserva • IVeiculo • IGrupoVeiculo • ITipoDeTarifa • IGrupoTarifa
Diagram Content Detail
Class IContrato Stereotype : interface Realizied by: Contrato, Pagamento Operation Summary public abrirContrato() public alterarContrato() public fecharContrato() public cancelarContrato() public consultarContrato() public efetuarPagamento() public enviaDadosCobranca() 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 clienteNome private string endereco private int cep private string cidade private string estado private int cpf 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 Summary public cadastrarCliente() public excluirCliente() public alterarCliente() public consultarCliente() 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 horaSaida private time horaDevolucao private date dataSaida private date dataDevolucao private int statusReserva private string numeroReserva
Operation Summary public cadastrarReserva() public cancelarReserva() public alterarReserva() public consultaReserva() 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 tarifaNome private string tarifaId private string tarifaComentario private date tarifaValidade private date tarifaDataEfetiva private int tarifaKmFranquia
Operation Summary public cadastrarTarifa() public consultarTarifa() public excluirTarifa() public alterarTarifa() Attribute Detail private string tarifaNome private string tarifaId private string tarifaComentario private date tarifaValidade private date tarifaDataEfetiva private int tarifaKmFranquia Operation Detail public cadastrarTarifa() Return Type : public consultarTarifa() Return Type : public excluirTarifa()
132
Return Type : public alterarTarifa() Return Type :
Class GrupoTarifa Parent : Sistema de Locadora de Veiculos Realization: IGrupoTarifa Association association(0..*) to Contrato Association association(0..*) to Contrato Association association(1..*) to Reserva Attribute Summary private float tarifaDiaria private float tarifaSemanal private float tarifaMensal private float tarifaKmAdicional private float tarifaHoraAdicional private float tarifaDiaAdicional
Operation Summary public alterarTarifa() public cadastrarTarifa() public consultarTarifa() public excluirTarifa() Attribute Detail private float tarifaDiaria private float tarifaSemanal private float tarifaMensal private float tarifaKmAdicional private float tarifaHoraAdicional private float tarifaDiaAdicional Operation Detail public alterarTarifa() Return Type : public cadastrarTarifa() Return Type : public consultarTarifa() Return Type : public excluirTarifa() Return Type :
Class GruposDeVeiculos Parent : Sistema de Locadora de Veiculos Realization: IGrupoVeiculo Subclasses
133
Class11 Association association(0..*) to Veiculo Association association(0..*) to Contrato Association association(1..*) to TiposDeTarifa Association association(0..*) to Veiculo Attribute Summary private string grupoNome private string grupoComentario
Operation Summary public cadastrarGrupo() public consultarGrupo() public excluirGrupo() public alterarGrupo() Attribute Detail private string grupoNome private string grupoComentario Operation Detail public cadastrarGrupo() Return Type : public consultarGrupo() Return Type : public excluirGrupo() Return Type : public alterarGrupo() Return Type :
Class Contrato Parent : Sistema de Locadora de Veiculos Realization: IContrato Realizied by: Sistema de Locadora de Veiculos Association association(1) to Pagamento Association association(1) to Cliente Association association(1) to Veiculo Association association(0..1) to Reserva Association association(1) to GrupoTarifa Association association(1) to GruposDeVeiculos Association association(1) to Cliente Association association(0..1) to Reserva Association association(1) to GrupoTarifa Association association(1) to Veiculo Attribute Summary private string numeroContrato private date dataContrato private int codigoAgenteAbertura
134
private int kmSaida private int qteCombustivelDeSaida private date dataSaida private time horaSaida 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 Summary public abrirContrato() public alterarContrato() public fecharContrato() public cancelarContrato() public consultaContrato() public efetuaPagamento() Attribute Detail private string numeroContrato private date dataContrato private int codigoAgenteAbertura private int kmSaida private int qteCombustivelDeSaida private date dataSaida private time horaSaida
135
private byte seguroVeiculo private byte seguroPessoal private byte seguroTerceiros private byte prePagto private float valorPrePagto private date dataPrevistaDevolucao private time horaPrevistaDevolucao private int qteKmAdicional private float valorKmAdicional private int qteHoraAdicional private float valorHoraAdicional private int qteDiaria private float valorDiaria private int qteSemana private float valorSemanal private int qteMensal private float valorMensal private int qteDiaAdicional private float valorDiaAdicional private int codigoAgenteFechamento private int kmChegada private int qteCombustivelChegada private byte cobrarCombustivel private date dataChegada private time horaChegada private string ajusteComentario private float valorSeguroPessoal private float valorSeguroVeiculo private float valorSeguroTerceiros private float valorAjuste private string statusContrato Operation Detail public abrirContrato() Return Type : public alterarContrato() Return Type : public fecharContrato() Return Type : public cancelarContrato() Return Type : public consultaContrato() Return Type : public efetuaPagamento() Return Type :
Class Veiculo Parent : Sistema de Locadora de Veiculos
136
Realization: IVeiculo Association association(0..*) to Contrato Association association(0..*) to Contrato Association association(1) to GruposDeVeiculos Association association(1) to GruposDeVeiculos Attribute Summary private string 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 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 Summary public cadastarVeiculo() public consultarVeiculo() public alterarVeiculo() public excluirVeiculo() Attribute Detail private string numeroChassi private string numeroPlaca private string fabricante private string marca private string cor private string anoModelo private int qtePorta private int kmInicial private string codigoChave private byte arCondicionado private byte direcaoHidraulica private byte radio private date dataCompra private date dataVistoria
137
private date dataPrevVenda private int statusVeiculo private date dataLicenciamento private string otencia private int capacidadeCombustivel private string tipoCombustivel private int rendimentoCombustivel private string tipoCarroceria private int tipoTransmissao Operation Detail public cadastarVeiculo() Return Type : public consultarVeiculo() Return Type : public alterarVeiculo() Return Type : public excluirVeiculo() Return Type :
Class Pagamento Parent : Sistema de Locadora de Veiculos Realization: IPagamentoAdmCartao, IContrato Subclasses Cartao, Cheque, Fatura Association association(1) to Contrato Attribute Summary private date dataPagamento private string tipoPagto private float valorTotal
Operation Summary public atualizaBaseDeDados() public emiteNotaFiscal() public atualizaStatusContrato() public validaCartao() public recebeDadosAdministradora() public enviaDadosAdministradora() public enviaDadosCobraca() Attribute Detail private date dataPagamento private string tipoPagto private float valorTotal Operation Detail public atualizaBaseDeDados()
138
Return Type : public emiteNotaFiscal() Return Type : public atualizaStatusContrato() Return Type : public validaCartao() Return Type : public recebeDadosAdministradora() Return Type : public enviaDadosAdministradora() Return Type : public enviaDadosCobraca() Return Type :
Class Cartao Generalization Hierarchy Pagamento | +-Cartao Parent : Sistema de Locadora de Veiculos Super Class Pagamento Attribute Summary private float valorPreAutorizacao private int cartaoId private date cartaoValidade private int cartaoDigitoSeguraca private int numeroAutorizacao private int numeroPreAutorizacao Attribute Detail private float valorPreAutorizacao private int cartaoId private date cartaoValidade private int cartaoDigitoSeguraca private int numeroAutorizacao private int numeroPreAutorizacao
Class Cheque Generalization Hierarchy Pagamento | +-Cheque Parent : Sistema de Locadora de Veiculos Super Class Pagamento
139
Attribute Summary private string nomeBanco private string numeroBanco private string numeroAgencia private string nomeAgencia private string numeroDoCheque private date dataEmissao Attribute Detail private string nomeBanco private string numeroBanco private string numeroAgencia private string nomeAgencia private string numeroDoCheque private date dataEmissao
Class Fatura Generalization Hierarchy Pagamento | +-Fatura Parent : Sistema de Locadora de Veiculos Super Class Pagamento Attribute Summary private string razaoSocial private string cnpj private string endereco private int telefone private string contato private int numeroAutorizacaoPagto Attribute Detail private string razaoSocial private string cnpj private string endereco private int telefone private string contato private int numeroAutorizacaoPagto
Class IPagamentoAdmCartao Stereotype : interface Realizied by: Pagamento Operation Summary public validaCartao() public recebeDadosAdministradora() public enviaDadosAdministradora()
140
Operation Detail public validaCartao() Return Type : public recebeDadosAdministradora() Return Type : public enviaDadosAdministradora() Return Type :
Class ICliente Stereotype : interface Realizied by: Cliente Operation Summary public cadastrarCliente() public excluirCliente() public alterarCliente() public consultarCliente() Operation Detail public cadastrarCliente() Return Type : public excluirCliente() Return Type : public alterarCliente() Return Type : public consultarCliente() Return Type :
Class IReserva Stereotype : interface Realizied by: Reserva Operation Summary public cadastrarReserva() public cancelarReserva() public alterarReserva() public consultarReserva() Operation Detail public cadastrarReserva() Return Type : public cancelarReserva() Return Type : public alterarReserva()
141
Return Type : public consultarReserva() Return Type :
Class IVeiculo Stereotype : interface Realizied by: Veiculo Operation Summary public cadastrarVeiculo() public consultarVeiculo() public alterarVeiculo() public excluirVeiculo() Operation Detail public cadastrarVeiculo() Return Type : public consultarVeiculo() Return Type : public alterarVeiculo() Return Type : public excluirVeiculo() Return Type :
Class IGrupoVeiculo Stereotype : interface Realizied by: GruposDeVeiculos Operation Summary public cadastrarGrupo() public consultarGrupo() public excluirGrupo() public alterarGrupo() Operation Detail public cadastrarGrupo() Return Type : public consultarGrupo() Return Type : public excluirGrupo() Return Type : public alterarGrupo()
142
Return Type :
Class ITipoDeTarifa Stereotype : interface Realizied by: TiposDeTarifa Operation Summary public cadastrarTarifa() public consultarTarifa() public excluirTarifa() public alterarTarifa() Operation Detail public cadastrarTarifa() Return Type : public consultarTarifa() Return Type : public excluirTarifa() Return Type : public alterarTarifa() Return Type :
Class IGrupoTarifa Stereotype : interface Realizied by: GrupoTarifa Operation Summary public alterarTarifa() public cadastrarTarifa() public consultarTarifa() public excluirTarifa() Operation Detail public alterarTarifa() Return Type : public cadastrarTarifa() Return Type : public consultarTarifa() Return Type : public excluirTarifa() Return Type :
Package Sistema de Locadora de Veiculos
143
Children: Class7, Class8, Class9, Class10, Class11, Package, Cliente, Contrato, Veiculo, Reserva, TiposDeTarifa, GrupoTarifa, GruposDeVeiculos, Pagamento, Cartao, Cheque, Fatura Realization: Contrato
Association Association End From Element : Cliente Multiplicity : 1 Navigable : True Association End To Element : Contrato Multiplicity : 0..* Navigable : True
Association Association End From Element : Reserva Multiplicity : 0..* Navigable : True Association End To Element : Cliente Multiplicity : 1 Navigable : True
Association Association End From Element : Reserva Multiplicity : 1..* Navigable : True Association End To Element : GrupoTarifa Multiplicity : 1 Navigable : True
Association Association End From Element : Reserva Multiplicity : 0..1 Navigable : True Association End To Element : Contrato Multiplicity : 0..1 Navigable : True
Association Association End From Element : GruposDeVeiculos Multiplicity : 1..* Navigable : True Association End To
144
Element : TiposDeTarifa Multiplicity : 1..* Navigable : True
Association Association End From Element : GrupoTarifa Multiplicity : 1 Navigable : True Association End To Element : Contrato Multiplicity : 0..* Navigable : True
Association Association End From Element : GruposDeVeiculos Multiplicity : 1 Navigable : True Aggregation Kind : Aggregation Association End To Element : Veiculo Multiplicity : 0..* Navigable : True
Association Association End From Element : Contrato Multiplicity : 1 Navigable : True Association End To Element : Pagamento Multiplicity : 1 Navigable : True
Association Association End From Element : Veiculo Multiplicity : 1 Navigable : True Association End To Element : Contrato Multiplicity : 0..* Navigable : True
145
Anexo G – Detalhes do Diagrama de Seqüência ‘Controlar Cobranca’
Detalhes do Diagrama de Seqüência ‘Controlar Cobranca’ – Parte #1/2
Diagram Content Summary
• Usuario • IContrato • c1:Contrato • Pagamento • Cheque
Diagram Content Detail
Actor Usuario Message Usuario insere dados para pagamento: tipoPagto, valorTotal, dataPagamento to IContrato Message Opcao fechar Contrato to IContrato Message Usuario insere dados adicionais de cobranca: nomeBanco, numeroBanco, nomeAgencia, numeroAgencia, numeroDoCheque, dataEmissao. to IContrato Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte #1/2)
LifeLine IContrato Message efetuarPagamento(tipoPagto, valorTotal, dataPagamento) to c1:Contrato Message fecharContrato() to c1:Contrato Message retorno to Usuario Return (Action) action detail Name : Return Message enviaDadosCobranca(nomeBanco, numeroBanco, nomeAgencia, numeroAgencia, numeroDoCheque, dataEmissao) to Cheque Message retorno to Usuario Return (Action) action detail Name : Return Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte #1/2)
LifeLine c1:Contrato Message atualizaBaseDeDados() to Pagamento Message emiteNotaFiscal(); to Pagamento Message atualizaStatusContrato(); to Pagamento Message <> to Pagamento Message retorno to IContrato Return (Action) action detail Name : Return Message <> to Cheque Message <> to Pagamento Destroy (Action) action detail Name : Destroy Message atualizaBaseDeDados() to Cheque
146
Message emiteNotaFiscal(); to Cheque Message atualizaStatusContrato(); to Cheque Message <> to Cheque Destroy (Action) action detail Name : Destroy Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte #1/2)
LifeLine Pagamento Message retorno to c1:Contrato Return (Action) action detail Name : Return Message retorno to c1:Contrato Return (Action) action detail Name : Return Message retorno to c1:Contrato Return (Action) action detail Name : Return Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte #1/2)
LifeLine Cheque Message retorno to c1:Contrato Return (Action) action detail Name : Return Message retorno to c1:Contrato Return (Action) action detail Name : Return Message retorno to c1:Contrato Return (Action) action detail Name : Return Message retorno to IContrato Return (Action) action detail Name : Return Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte #1/2)
Detalhes do Diagrama de Seqüência ‘Controlar Cobranca’ – Parte #2/2
Diagram Content Summary
• Usuario • Administradora de Cartao • IContratoTela • c1:Contrato • Fatura • Cartao • IPagamentoAdmCartao
Diagram Content Detail
Actor Usuario
147
Message Usuario insere dados adicionais de cobranca: numeroCartao, cartaoValidade, cartaoDigitoSeguranca. to IContratoTela Message Usuario insere dados adicionais de cobranca: razaoSocial, cnpj, endereco, telefone, contato, numeroAutorizacaoPagto. to IContratoTela Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte # 2/2)
Actor Administradora de Cartao Message retorno to IPagamentoAdmCartao Return (Action) action detail Name : Return Message retorno to IPagamentoAdmCartao Return (Action) action detail Name : Return Message retorno to IPagamentoAdmCartao Return (Action) action detail Name : Return Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte # 2/2)
LifeLine IContratoTela Message retorno to Usuario Return (Action) action detail Name : Return Message enviaDadosCobranca(numeroCartao, cartaoValidade, cartaoDigitoSeguranca) to Cartao Message enviaDadosCobranca(razaoSocial, cnpj, endereco, telefone, contato, numeroAutorizacaoPagto) to Fatura Message retorno to Usuario Return (Action) action detail Name : Return Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte # 2/2)
LifeLine c1:Contrato Message retorno to IContratoTela Return (Action) action detail Name : Return Message atualizaStatusContrato(); to Fatura Message <> to Fatura Message <> to Cartao Message <> to Fatura Destroy (Action) action detail Name : Destroy Message atualizaBaseDeDados() to Cartao Message emiteNotaFiscal(); to Cartao Message atualizaStatusContrato(); to Cartao Message <> to Cartao Destroy (Action) action detail Name : Destroy Message emiteNotaFiscal(); to Fatura Message atualizaBaseDeDados() to Fatura Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte # 2/2)
148
LifeLine Fatura Message retorno to c1:Contrato Return (Action) action detail Name : Return Message retorno to IContratoTela Return (Action) action detail Name : Return Message retorno to c1:Contrato Return (Action) action detail Name : Return Message retorno to c1:Contrato Return (Action) action detail Name : Return Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte # 2/2)
LifeLine Cartao Message retorno to c1:Contrato Return (Action) action detail Name : Return Message retorno to c1:Contrato Return (Action) action detail Name : Return Message retorno to c1:Contrato Return (Action) action detail Name : Return Message <> to IPagamentoAdmCartao Message validaCartao(numeroCartao) to IPagamentoAdmCartao Message enviaDadosAdministradora() to IPagamentoAdmCartao Message recebeDadosAdministradora() to IPagamentoAdmCartao Message <> to IPagamentoAdmCartao Destroy (Action) action detail Name : Destroy Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte # 2/2)
LifeLine IPagamentoAdmCartao Message validaCartao(numeroCartao) to Administradora de Cartao Message retorno to Cartao Return (Action) action detail Name : Return Message enviaDadosAdministradora() to Administradora de Cartao Message retorno to Cartao Return (Action) action detail Name : Return Message recebeDadosAdministradora() to Administradora de Cartao Message retorno to Cartao Return (Action) action detail Name : Return Parent : Diagrama de Sequencia do caso de uso 'Controlar Cobranca' (Parte # 2/2)
149
Anexo H – Detalhes do Diagrama de Atividades ‘Controlar Cobranca’
Diagram Content Summary
• InitialState • Seleciona opcao de fechamento de contrato. • Insere o valor e a data • Escolhe o tipo de pagamento • Sistema atualiza base de dados • Sistema emite nota fiscal • Sistema atualiza status do contrato • Insere dados adicionais do cheque: numero e nome do banco, numero e nome da agencia,
numero do cheque, data de emissao, data para pagamento. • Insere dados adicionais da empresa: CNPJ, Razao Social, endereco, telefone, contato,
numero A.P., data para pagamento, data emissao • Insere dados adicionais do cartao: Validade e numero do cartao. • Insere digito de seguranca • Envia dados para administradora • Recebe numero da transacao • SynchronizationBar • SynchronizationBar2 • FinalState • Usuario • Admin. de Cartao
Diagram Content Detail
Initial State InitialState Parent : Usuario Transition link to Seleciona opcao de fechamento de contrato.
Action State Seleciona opcao de fechamento de contrato. Parent : Usuario Transition link to Insere o valor e a data Transition link from InitialState
Action State Insere o valor e a data Parent : Usuario Transition link to Escole o tipo de pagamento Transition link from Seleciona opcao de fechamento de contrato.
Action State Escole o tipo de pagamento Parent : Usuario
150
Transition link to Transition link from Insere o valor e a data
Action State Sistema atualiza base de dados Parent : Usuario Transition link to Sistema emite nota fiscal Transition link from
Action State Sistema emite nota fiscal Parent : Usuario Transition link to Sistema atualiza status do contrato Transition link from Sistema atualiza base de dados
Action State Sistema atualiza status do contrato Parent : Usuario Transition link to FinalState Transition link from Sistema emite nota fiscal
Action State Insere dados adicionais do cheque: numero e nome do banco, numero e nome da agencia, numero do cheque, data de emissao, data para pagamento. Parent : Usuario Transition link to Transition link from
Action State Insere dados adicionais da empresa: CNPJ, Razao Social, endereco, telefone, contato, numero A.P., data para pagamento, data emissaoParent : Usuario Transition link to Transition link from
Action State Insere dados adicionais do cartao: Validade e numero do cartao. Parent : Usuario Transition link to SynchronizationBar Transition link from
Action State Insere digito de seguranca Parent : Usuario Transition link to SynchronizationBar2 Transition link from SynchronizationBar
Action State Envia dados para administradora Parent : Admin. de Cartao
151
Transition link to SynchronizationBar2 Transition link from SynchronizationBar
Action State Recebe numero da transacao Parent : Admin. de Cartao Transition link to Transition link from SynchronizationBar2
Decision Point Parent : Usuario Transition link [dinheiro] to Transition link [faturado] to Insere dados adicionais da empresa: CNPJ, Razao Social, endereco, telefone, contato, numero A.P., data para pagamento, data emissao Transition link [cheque] to Insere dados adicionais do cheque: numero e nome do banco, numero e nome da agencia, numero do cheque, data de emissao, data para pagamento. Transition link [cartao to Insere dados adicionais do cartao: Validade e numero do cartao. Transition link from Escole o tipo de pagamento
Decision Point Parent : Usuario Transition link to Sistema atualiza base de dados Transition link from , Insere dados adicionais da empresa: CNPJ, Razao Social, endereco, telefone, contato, numero A.P., data para pagamento, data emissao, Insere dados adicionais do cheque: numero e nome do banco, numero e nome da agencia, numero do cheque, data de emissao, data para pagamento., Recebe numero da transacao
Synchronization BarSynchronizationBar Transition link to Insere digito de seguranca Transition link to Envia dados para administradora Transition link from Insere dados adicionais do cartao: Validade e numero do cartao.
Synchronization BarSynchronizationBar2 Transition link to Recebe numero da transacao Transition link from Envia dados para administradora, Insere digito de seguranca
Final State FinalState Parent : Usuario Transition link from Sistema atualiza status do contrato
152
SwimLane Usuario Children: InitialState, Seleciona opcao de fechamento de contrato., Insere o valor e a data, Escole o tipo de pagamento, Sistema atualiza base de dados, Sistema emite nota fiscal, Sistema atualiza status do contrato, FinalState, Insere dados adicionais do cheque: numero e nome do banco, numero e nome da agencia, numero do cheque, data de emissao, data para pagamento., Insere dados adicionais da empresa: CNPJ, Razao Social, endereco, telefone, contato, numero A.P., data para pagamento, data emissao, Insere dados adicionais do cartao: Validade e numero do cartao., Insere digito de seguranca
SwimLane Admin. de Cartao Children: Envia dados para administradora, Recebe numero da transacao
153
Anexo I – Protótipos de Interface Gráfica.
Figura 47: Protótipo da Tela de Abertura de Contrato.
154
Figura 48: Protótipo da Tela de Fechamento de Contrato de Locação.
155
Figura 49: Protótipo da Tela de Cadastro de Veículos.
156
Considerações Finais
Conforme proposto no início desse trabalho, mostrou-se a teoria através dos
conceitos e a prática através do estudo de caso, observou-se as etapas para realizar
um projeto de software utilizando a orientação a objetos com UML.
Pôde-se constatar que a documentação do projeto é muito importante para
que toda a equipe envolvida no processo de desenvolvimento do sistema trabalhe
em sincronismo, alcançando assim o mesmo objetivo: um sistema condizente com a
necessidade do cliente.
Apesar do processo de documentação consumir um tempo aparentemente
desnecessário, o qual poderia ser utilizado para efetuar outras atividades do projeto,
conclui-se que a documentação gerada no decorrer desse período é de grandíssima
utilidade, tanto para manter a equipe alinhada aos objetivos do projeto quanto para a
evolução do sistema.
Com a elaboração desse trabalho, conclui-se que é necessário seguir um
método eficaz de desenvolvimento para o sistema evitando a utilização do modelo
‘balbúrdia’. É necessário emprenhar-se na análise de requisitos para que não ocorra
retrabalho, evitando assim ultrapassar o orçamento 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 utilização da análise orientada a objetos, o
desenvolvimento de software ficou simples, pois os objetos possuem características
e ações retratando o mundo real. Pelo fato do software ser composto por objetos,
facilitou a manutenção e evolução do sistema, ficando transparente para o usuário
as alterações na implementação dos códigos.
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
seqüência a esse trabalho onde pretende-se dar ênfase na implementação do
sistema.
Finalizando, a elaboração deste estudo foi muito gratificante principalmente,
porque através dele, pude reforçar os meus conhecimentos e assimilar novas
experiências relacionadas ao projeto de software orientado a objetos.
157
Referências Bibliográficas BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. Rio
de Janeiro: Campus, 2002.
BORGES, José Antonio. Projeto MOTRIX. Disponível em:
<http://intervox.nce.ufrj.br/motrix/>. Acessado em: 02/Jul/06.
BOOCH, Grady et al. UML, guia do usuário. Rio de Janeiro: Elsevier, 2000.
FERREIRA, Aurélio Buarque de Holanda. Dicionário Aurélio Básico da Língua Portuguesa. Rio de Janeiro: Nova Fronteira, 1988, p. 603.
GOTTESDIENER, E., Business Rules as Requirements. Software Development,
1999. In: BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro: Campus, 2002: 70.
Guia do Hardware.Net. ENIAC. Disponível em :
<http://www.guiadohardware.net/termos/eniac> Acessado em: 13/Jun/2006
MANDEL, T., The Elements of User Interface Design. Wiley, 1997. In:
PRESSMAN, Roger S. Engenharia de Software - Ed.5. Rio de Janeiro: McGraw-
Hill, 2002: 394.
MELO, Ana Cristina. Desenvolvendo aplicações com UML 2.0: do conceitual à implementação - 2ºed. Rio de Janeiro: Brasport, 2006.
POMPILHO, S. Análise essencial – Guia prático de análise de sistemas. Rio de
Janeiro: Infobook, 1995. In: TONSIG, Sergio Luiz. Engenharia de Software Análise e Projetos de Sistemas. São Paulo: Futura, 2003.
158
PRESSMAN, Roger S. Engenharia de Software - Ed.5. Rio de Janeiro: McGraw-
Hill, 2002.
SOMMERVILLE, Ian. Engenharia de Software. São Paulo: Pearson Addison
Wesley, 2003.
SUN. Java Card. Disponível em
<http://java.sun.com/products/javacard/overview.html> Acessado em: 16/Jun/2006.
TONSIG, Sergio Luiz. Engenharia de Software Análise e Projetos de Sistemas. São Paulo: Futura, 2003.
WIKIPÉDIA. Linguagem procedural. Disponível em:
<http://pt.wikipedia.org/wiki/Linguagem_Procedural>. Acessado em: 09/Jul/06.
WIKIPÉDIA. Orientação a objeto. Disponível em:
<http://pt.wikipedia.org/wiki/Orientação_a_objeto>. Acessado em: 09/Jul/06.
WIKIPÉDIA. R.A.I.D. Disponível em: <http://pt.wikipedia.org/wiki/Raid>. Acessado
em: 31/Jul/06.
WIKIPÉDIA. Multiprocessamento. Disponível em:
<http://pt.wikipedia.org/wiki/Multiprocessamento>. Acessado em: 31/Jul/06.
WIKIPÉDIA. Sistema de Gerenciamento de Banco de Dados. Disponível em:
<http://pt.wikipedia.org/wiki/SGBD>. Acessado em: 31/Jul/06.
WIKIPÉDIA. Active Server Pages. Disponível em:
<http://pt.wikipedia.org/wiki/ASP>. Acessado em: 31/Jul/06.
WIKIPÉDIA. Rede. Disponível em: <http://pt.wikipedia.org/wiki/Rede> Acessado em
15/Jun/2006.
159
WIKIPÉDIA. Rede de computadores. Disponível em:
<http://pt.wikipedia.org/wiki/Rede_de_computadores> Acessado em 15/Jun/2006.
WIKIPÉDIA. WEB. Disponível em: <http://pt.wikipedia.org/wiki/Web> Acessado em
27/Jun/2006.
WIKIPÉDIA. Brainstorming Disponível em:
<http://pt.wikipedia.org/wiki/Brainstorming > Acessado em: 30/Jul/2006.
WIKIPÉDIA. Cartão perfurado. Disponível em:
<http://pt.wikipedia.org/wiki/Cartão_perfurado> Acessado em: 13/Jun/2006
WIKIPÉDIA. Topologia. Disponível em: <http://pt.wikipedia.org/wiki/Topologia>.
Acessado em: 22/Ago/2006.
WIKIPÉDIA. Gestão de Riscos nos projetos de Software. Disponível em:
<http://pt.wikipedia.org/wiki/Gestão_de_Riscos_nos_projectos_de_Software>.
Acessado em: 22/Ago/2006.
WIKIPÉDIA. PDA. Disponível em:<http://pt.wikipedia.org/wiki/PDA>. Acessado em:
22/Ago/2006.
WIKIPÉDIA. Abstração. Disponível em:<http://pt.wikipedia.org/wiki/Abstração>.
Acessado em: 22/Ago/2006.
WIKIPÉDIA. Plataforma (informática). Disponível em:
<http://pt.wikipedia.org/wiki/Plataforma_(informática)>. Acessado em: 23/Ago/2006.
WIKIPÉDIA. Redundância (informática). Disponível em:
<http://pt.wikipedia.org/wiki/Redundância_(informática)>. Acessado em:
23/Ago/2006.
