Trabalho final completo - Frota de táxis

Prévia do material em texto

UNIVERSIDADE DO OESTE DE SANTA CATARINA 
ÁREA DAS CIÊNCIAS EXATAS E DA TERRA 
CURSO: ENGENHARIA DA COMPUTAÇÃO 
DISCIPLINA: ENGENHARIA DE SOFTWARE II CRÉDITOS: 4 HORAS/AULA: 60 
PROFESSORA: ROGERIA RAMOS [rogeria.monteiro@unoesc.edu.br] 
PERÍODO LETIVO: 2º SEM DE 2013 FASE: 4ª 
Data de solicitação: 25 de setembro de 2013 
Data de entrega: 15 de outubro de 2013 – publicado na Área de Colaboração do Portal de 
Ensino da Unoesc. 
Equipe: Mariana Rodrigues dos Santos, Oriel Antonio Gaida e Welenton Artur Webler 
Nota: ________ 
 
 
AVALIAÇÃO A1P2 
Processo Unificado – Fase de Elaboração/Análise 
 
PROJETO FROTA DE TÁXIS 
ESTRUTURA DO TRABALHO E CRITÉRIOS DE AVALIAÇÃO 
1. FASE DE CONCEPÇÃO 
1.1. LEVANTAMENTO DE REQUISITOS 
1.1.1. Visão Geral 
1.1.2. Índice de Requisitos Funcionais 
1.1.3. Índice de Requisitos Não Funcionais 
1.1.4. Detalhamento dos Requisitos Funcionais 
1.1.5. Glossário 
1.2. ORGANIZAÇÃO DOS REQUISITOS EM CASOS DE USO 
1.3. PLANEJAMENTO DOS CICLOS ITERATIVOS 
 
2. FASE DE ELABORAÇÃO 
2.1. ANÁLISE 
2.1.1. Expansão de Caso de Uso 
2.1.2. Identificação de Operações e Consultas de Sistema 
2.1.3. Modelo Conceitual 
2.1.4. Elaboração de Contratos 
 
CRITÉRIOS DE AVALIAÇÃO 
A NOTA DO TRABALHO VALE PARA TODOS OS INTEGRANTES DO GRUPO. 
 Aplicação do modelo sugerido: todos os itens. 
 Coerência, objetividade e completude: itens 2.1.2 e 2.1.3 e 2.1.4. 
 Coerência com a técnica para elaborar os artefatos. 
 
DISTRIBUIÇÃO DA PONTUAÇÃO (TOTAL 10 PONTOS): 
▪ Aplicação do modelo sugerido equivale a 1 ponto. 
▪ Itens 2.1.2, 2.1.3 e 2.1.4 equivalem a 3 pontos, cada um. 
 
1. FASE DE CONCEPÇÃO 
 
O processo unificado (PU ou UP) foi proposto por Grady Booch, James Rumbaugh e 
Ivar Jacobson (Jacobson, Booch & Rumbaugh, 1999), sendo o resultado de mais de trinta 
anos de experiência acumulada. O trio também foi que propôs a UML, Unified Modeling 
Language, como linguagem de linguagem de modelagem de sistemas unificada e não-
proprietária. 
Segundo Wazlawick (2011, p. 4 e 5), o processo se fundamenta em três valores: 
a) É dirigido por casos de uso: o planejamento do desenvolvimento é feito em função 
dos casos de uso identificados, tratando-se prioritariamente os mais complexos; 
b) É centrado na arquitetura: o processo de desenvolvimento prioriza a construção de 
uma arquitetura de sistema que permita a realização dos requisitos. Essa 
arquitetura baseia-se na identificação de uma estrutura de classes, produzida a 
partir de um modelo conceitual. 
c) É iterativo e incremental: a cada ciclo de trabalho realizado, novas características 
são adicionadas a arquitetura do sistema, deixando-a mais completa e mais 
próxima do sistema final. 
O UP é dividido, basicamente, em quatro grandes fases, que são: concepção, 
elaboração, construção e transição. 
A fase de concepção incorpora o estudo de viabilidade, o levantamento dos requisitos 
e uma parte da sua análise. A fase de elaboração incorpora o detalhamento da analise 
requisitos, a modelagem de domínio e o projeto. A fase de construção corresponde à 
programação e testes, e a fase de transição consiste na instalação do sistema e migração 
de dados. 
Segundo Pressman (2011, p. 74), as fases do processo unificado não ocorrem em 
sequência, mas sim de forma concorrente e escalonada. “É provável que, ao mesmo 
tempo em que as fases de construção, transição e produção estejam sendo conduzidas, 
já se tenha iniciado o incremento de software seguinte.” (PRESMANN, 2011). 
 
O esquema abaixo demonstra o processo unificado, suas fases e iterações. 
 
 
Esquema 1: Processo Unificado com suas fases e iterações. 
 
Segundo Wazlawick (2011, p. 5), apesar de ser um processo prescritivo, o UP pode 
também ser realizado como um processo ágil, com poucos artefatos e burocracia, 
permitindo o desenvolvimento de software de forma eficiente, uma vez que o que 
interessa ao cliente é o software pronto e não uma pilha de documentos justificando por 
que não ficou pronto. 
A seção a seguir trata da fase de concepção, que é a primeira fase do processo 
unificado, na qual se procura levantar os principais requisitos e compreender o sistema de 
forma abrangente. Os principais objetivos dessa fase estão listados a seguir: 
1. Estabelecer o escopo do projeto e condições de fronteira 
2. Identificar os casos de uso críticos do sistema 
3. Descrever pelo menos uma arquitetura candidata para os principais casos de uso 
4. Apresentar estimativas globais de custo e prazo para o projeto global e estimativas 
detalhadas para a fase de elaboração 
5. Levantar os principais riscos que podem comprometer o sucesso do projeto 
 
 
1.1. LEVANTAMENTO DE REQUISITOS 
 
Na prática, requisito é o que o sistema tem que ter para atender plenamente ao 
propósito para o qual foi criado (FERNANDES, 2005). 
De acordo com NUNES, 2007 os requisitos, de modo geral, podem ser classificados 
em dois grandes grupos: os requisitos funcionais e os não funcionais, os quais serão 
vistos a seguir. 
A especificação de requisitos é um grande desafio para projetos de desenvolvimento 
de software. Nesta etapa os analistas de sistemas se relacionam com os usuários para 
entender, documentar, separar informações, conhecer o fluxo de trabalho e detalhar os 
objetivos a serem atingidos com o projeto que venha a responder as ansiedades e 
necessidades dos usuários e da organização. Uma grande quantidade de conhecimento 
dos usuários e técnicos é explicitada nesta etapa e este conhecimento precisa ser 
depositado em repositórios que facilitem a recuperação e agreguem valor ao processo. 
Percebe-se uma enorme dificuldade em listar, analisar, validar e gerenciar corretamente 
os requisitos (COSER, CARVALHO, KOVALESKI, 2006). 
Sobre as técnicas para se obter informações sobre funcionalidades esperadas do 
sistema, existem inúmeras. Entrevistas, questionários e observações são as mais 
comuns. A escolha entre uma ou mais de uma das técnicas fica a critério do analista. 
 
 
1.1.1. Visão Geral 
Manoel Antonio é proprietário de uma frota de táxis na cidade de Joaçaba. Ele deseja 
um programa que apresente o valor de cada deslocamento e também, ao fim do dia, 
gostaria de uma funcionalidade que apresente o valor total recebido, de cada um dos 
veículos individualmente, assim como o valor recebido pela frota como um todo. 
Considerar que: 
 a quantidade de km rodados marcada no taxímetro é a principal informação para 
que o valor do deslocamento seja apresentado; 
 que há um valor mínimo a ser cobrado; 
 que vários deslocamentos podem ser registrados em um único dia; 
 que cada veículo tem um motorista sob responsabilidade; 
 de cada motorista devem ser conhecidas as seguintes informações: nome 
completo, cpf, rg, número da CNH, validade da CNH, categoria da CNH e celular. 
 
 
1.1.2. Índice de Requisitos Funcionais 
 
Os requisitos funcionais são aqueles que descrevem o comportamento do sistema, 
suas ações para cada entrada, ou seja, é aquilo que descreve o que tem que ser feito 
pelo sistema. São o cérebro do projeto, já que descrevem as funcionalidades que o 
sistema deve dispor. 
Para Wazlawick (2011, p. 24 e 25), os requisitos funcionais devem conter basicamente 
os seguintes elementos: 
a) A descrição de uma função a ser executada pelo sistema (usualmente entrada, 
saída ou transformação da informação); 
b) A origem do requisito (quem solicitou) e/ou quem vai executar a função em questão 
(usuário); 
c) Quais as informações que são passadas do sistema para o usuário e vice-versa 
quando a função for executada; 
d) Quais restrições lógicas (regras de negócio) ou tecnológicas se aplicam à função. 
As informaçõesde entrada e saída são importantíssimas para que a análise de 
requisitos ocorra de forma sistemática. Sem essas informações, os requisitos ficam muito 
vagos e pouco é aprendido sobre o sistema nessa fase. 
 
Sendo assim, seguem os requisitos funcionais elencados para este sistema: 
 F01. Manter informações sobre taxímetro 
 F02. Manter informações sobre táxi 
 F03. Gerenciar táxi 
 F04. Manter informações sobre motorista 
 F05. Gerenciar frota de táxis 
 
 
1.1.3. Índice de Requisitos Não Funcionais 
 
Os requisitos não funcionais são aqueles que expressam como deve ser feito. Em 
geral se relacionam com padrões de qualidade como confiabilidade, desempenho, 
robustez, etc. São muito importantes, pois definem se o sistema será eficiente para a 
tarefa que se propõe a fazer ou não. Um sistema ineficiente certamente não será usado. 
Neles também são apresentadas restrições e especificações de uso para os requisitos 
funcionais. 
Segundo Wazlawick (2011, p. 25), os requisitos não funcionais aparecem sempre 
ligados a requisitos funcionais e podem ser basicamente de dois tipos: lógicos ou 
tecnológicos. 
As restrições lógicas são as regras de negócio relacionadas a função em questão. Já 
as restrições tecnológicas dizem respeito à tecnologia para a realização da função, como, 
por exemplo, a interface, o protocolo de comunicação, restrições de segurança ou 
tolerância a falhas. 
 
Desta forma, os requisitos não funcionais destacados para este sistema são: 
 Deve ser desenvolvido para o sistema operacional Windows 
 Plataforma Desktop 
 Níveis de acesso: Administrador, Motorista. 
 
 
1.1.4. Detalhamento dos Requisitos Funcionais 
 
O detalhamento das informações que entram e saem do sistema é fundamental para 
a compreensão mais detalhada das funções. Segundo Wazlawick (2011, p. 29), “Sem 
esse detalhamento, o sistema pode parecer mais simples do que realmente é, o que 
explica por que, em muitos casos, os analistas esperam desenvolver um sistema em 
determinado tempo mas levam muito mais tempo, estourando prazos e orçamentos. 
As seções recomendadas nessa atividade são as seguintes: 
 Descrição: descrição geral da função, do que ela deve fazer; 
 Fontes: pessoas, sistemas ou documentos dos quais foram extraídas as 
informações; 
 Usuários: descreve quais usuários poderão acessar aquela determinada função 
do sistema, auxilia na realização da hierarquia de usuários do sistema; 
 Informações de entrada: informações que serão inseridas no sistema quando 
aquela função estiver sendo chamada; 
 Informações de saída: informações que o sistema deverá apresentar para o 
usuário; 
 Restrições lógicas: descreve as restrições lógicas das informações de entrada; 
 Restrições tecnológicas: descreve as restrições da tecnologia que será utilizada 
para trocar informações com o sistema. 
 
F01. Manter informações sobre taxímetro 
Descrição Registrar as informações de um taxímetro associado a um determinado 
táxi. Os dados podem ser alterados a cada novo deslocamento. 
Fontes Cliente (Manoel Antonio) 
Usuários Administrador 
Informações 
de entrada 
valor mínimo, taxa por km rodado, km rodados por deslocamento 
completo, valor total do deslocamento, total de Km rodados, número de 
deslocamentos, número de referência. 
Informações 
de saída 
valor total do deslocamento 
Restrições  ‘valor mínimo’ indica o valor mínimo a ser cobrado do passageiro 
lógicas independente da quantidade de km rodados. No momento, este valor 
é equivalente a R$ 4,00. 
 ‘taxa por km rodado’ indica o valor a ser cobrado por cada km que o 
táxi se desloca a pedido de um passageiro. 
 ‘km rodados’ indica a quantidade efetiva de deslocamento realizado 
pelo táxi a pedido de um passageiro, considerando o valor marcado 
ao chegar no destino. 
 ‘valor total do deslocamento’ é calculado da seguinte forma: 
 ‘valor mínimo’ + (‘taxa por km rodado’ * ‘km rodados’); 
 a cada novo deslocamento (passageiro) o valor de ‘km rodados’ 
deve ser zerado. 
 a cada registro de deslocamento: 
o o ‘número de deslocamentos’ deve ser acrescentado em uma 
unidade; 
o o ‘total de km rodados’ deve ser acrescentado do valor de ‘km 
rodados’. 
Restrições 
tecnológicas 
não existe 
**** 
F02. Registrar táxi 
Descrição Registrar as informações de táxi, associando um motorista e um 
taxímetro ao mesmo, permitindo a inclusão, alteração, exclusão e 
localização de um determinado táxi em uma lista correspondente à frota 
da empresa. 
Fontes Cliente (Manoel Antonio). 
Usuários Administrador 
Informações 
de entrada 
Taxímetro, Motorista, placa, marca, modelo, anoModelo 
Informações 
de saída 
Motorista, placa, marca, modelo, anoModelo 
Restrições 
lógicas 
 cada táxi tem apenas um taxímetro que já está instalado no mesmo. 
 cada táxi tem apenas um motorista responsável. 
Restrições 
tecnológicas 
não existe 
**** 
F03. Gerenciar táxi 
Descrição A partir da quantidade de km rodados deve ser possível obter o valor a 
ser pago pelo deslocamento. Após o registro de vários deslocamentos, 
deve ser apresentado o valor do faturamento diário do motorista, ou 
seja, qual foi o valor de todos os deslocamentos realizados em um dia 
Fontes Cliente (Manoel Antonio). 
Usuários Administrador, Motorista. 
Informações Táxi, data do dia de trabalho 
de entrada 
Informações 
de saída 
valor total dos deslocamentos, valor do faturamento diário 
Restrições 
lógicas 
 ‘data do dia de trabalho’ refere-se ao dia de trabalho, ou seja, a 
cada dia de trabalho a frota completa pode estar prestando serviços 
ou apenas parte dela. 
Restrições 
tecnológicas 
não existe 
**** 
F04. Manter informações sobre motorista 
Descrição Registrar as informações do motorista de cada táxi permitindo a 
inclusão, alteração, exclusão e localização de um determinado motorista 
em uma lista dos funcionários da empresa. 
Fontes Cliente (Manoel Antonio). 
Usuários Administrador 
Informações 
de entrada 
nome completo, cpf, rg, número da CNH, validade da CNH, categoria da 
CNH e celular 
Informações 
de saída 
nome completo, cpf, rg, número da CNH, validade da CNH, categoria da 
CNH e celular 
Restrições 
lógicas 
 um motorista é responsável por um veículo apenas, enquanto for 
funcionário da empresa. 
 a CNH do motorista não pode estar vencida 
 a CNH do motorista deve ser de categoria B, correspondente ao 
veículo que terá sob sua responsabilidade. 
Restrições 
tecnológicas 
não existe 
**** 
F05. Gerenciar Frota de Táxis 
Descrição Para cada dia da semana, é colocado em serviço um conjunto de táxis, 
correspondendo à frota completa ou parte dela. Ao final do dia, deve ser 
possível conhecer o valor arrecadado por cada um, assim como o 
faturamento total da frota. 
Fontes Cliente (Manoel Antonio). 
Usuários Administrador 
Informações 
de entrada 
Lista de táxis, data do dia de trabalho, número total de táxis, número de 
táxis em serviço. 
Informações 
de saída 
valor do faturamento diário por táxi, valor do faturamento diário da frota, 
data do dia de trabalho. 
Restrições 
lógicas 
 ‘data do dia de trabalho’ refere-se ao dia de trabalho, ou seja, a 
cada dia de trabalho a frota completa pode estar prestando serviços 
ou apenas parte dela. 
Restrições 
tecnológicas 
Não existe. 
Quadro 1: Detalhamento dos requisitos funcionais. 
 
1.2. ORGANIZAÇÃO DE REQUISITOS EM CASOS DE USO 
 
O Caso de Uso (Use Case) descreve uma sequência de ações que representam um 
cenário principal e cenários alternativos, com o objetivo de demonstraro comportamento 
de um sistema através de interações com atores (usuários). Os casos de uso devem 
representar processos de negócio de uma determinada empresa, devem ser 
monossessão, interativos e ter um resultado consistente. Quanto sua classificação, é 
necessário considerar a complexidade do UC, podendo ser feita classificando-o em 
Processo de Negócio, CRUD ou Relatório. 
 
Nome 
Tipo do 
UC 
Atores Descrição 
Referências 
Cruzadas 
UC1 
Gerenciar a 
frota de Táxi 
Processo 
de 
Negócio 
Usuário 
Para cada dia da semana, é 
colocado em serviço um conjunto 
de táxis, correspondendo à frota 
completa ou parte dela. Ao final do 
dia, deve ser possível conhecer o 
valor arrecadado por cada um, 
assim como o faturamento total da 
frota. 
F01, F02, 
F03, F04, 
F05 
UC2 
Gerenciar 
Táxi 
Processo 
de 
Negócio 
Usuário 
A partir do registro do 
deslocamento (em Km) realizado 
por um táxi, deve ser possível 
determinar o valor a ser pago pelo 
cliente e também, ao final do dia, 
o valor total faturado por cada táxi. 
F01, F02, 
F03, F04 
UC3 Registar 
Táxi 
Processo 
de 
Negócio 
Usuário 
Deve-se registrar cada táxi em 
particular com suas informações, 
associar um motorista responsável 
pelo mesmo e associar um 
taxímetro que estará em cada 
veículo. 
F02, F04 
CRUD01 
Manter 
Informações 
sobre 
taxímetro 
CRUD Usuário 
As informações sobre taxímetro 
devem ser registradas, 
observando os dados que deverão 
ter seus valores inicializados. 
F01 
CRUD02 
Manter 
Informações 
CRUD Usuário 
Cada motorista deve ter suas 
informações registradas. 
F04 
sobre 
Motorista 
REL01 – 
Calcular o 
valor por um 
determinado 
deslocamento 
REL Usuário 
Deve-se informar o deslocamento, 
em km, realizado e a partir disso, 
o valor a ser pago pelo 
deslocamento deve ser fornecido. 
F02. 
Informações 
de Saída 
REL02 – 
Obter 
faturamento 
de um táxi 
num 
determinado 
período 
REL Usuário 
A cada deslocamento realizado 
por um determinado táxi, deve ser 
registrado o valor do 
deslocamento e, ao final do dia, o 
valor total faturado deve ser 
fornecido. 
F03. 
Informações 
de Saída 
REL03 – 
Obter 
faturamento 
da frota de 
táxis num 
determinado 
período 
REL Usuário 
Considerando todos os táxis que 
estão em serviço em um 
determinado dia, deve ser 
possível, ao final do dia, obter o 
valor total faturado por todos os 
veículos juntos. 
 
Quadro 2: Identificação e classificação de casos de uso. 
Segundo Wazlawick (2011, p. 37), o diagrama de casos de uso não é um dos 
diagramas mais úteis, mas é bastante popular para mostrar quais funções o sistema 
efetivamente executa. Nesse diagrama, as elipses representam casos de uso, os bonecos 
representam atores (usuários) e o retângulo representa a fronteira do sistema ou 
subsistemas. 
Fowler (2005, p. 106 e 107), descreve que a melhor maneira de pensar um diagrama 
de casos de uso é como um sumário gráfico do conjunto de casos de uso. Ele ainda 
destaca que pouco tempo e esforço deve ser aplicado a esse diagrama, concentrando-se 
mais na descrição textual dos casos de uso. 
O diagrama de casos de uso a seguir demonstra o sistema a ser desenvolvido, 
elaborado com o auxílio da ferramenta Astah Community versão 6.7. 
 
Diagrama 1: Diagrama de Casos de Uso UML do SisTáxi 
 
 
1.3. PLANEJAMENTO DOS CICLOS ITERATIVOS 
 
Uma vez que os casos de uso tenham sido identificados, deve-se verificar se todos os 
requisitos funcionais do sistema tenham sido encaixados em pelo menos um caso de uso. 
Caso contrário, provavelmente ainda faltam casos de uso. Sendo o UP um processo 
interativo e incremental, espera-se que a cada ciclo de desenvolvimento sejam tratados 
um conjunto de casos de uso isoladamente, assim surgem os ciclos iterativos. 
Wazlawick (2010) define ciclos iterativos: “[...] são mini projetos baseados em casos 
de uso, conceitos e consultas. Estes mini projetos devem ser curtos e com tempo pré-
determinado.”. 
No decorrer dessa fase, cada caso de uso relacionado será introduzido ao menos em 
um ciclo iterativo. Os critérios para alocação são tratar prioritariamente os processos de 
negócio, em seguida os CRUDs em por último os relatórios, tratando assim os mais 
complexos primeiro. Nada impede de que casos de uso de tipos diferentes, por exemplo, 
processos de negócio e relatórios, sejam inseridos no mesmo ciclo iterativo, estando eles 
relacionados. 
A partir da análise dos ciclos iterativos do sistema que está sendo tratado, chegamos 
ao Quadro 3, identificação e classificação de casos de uso. 
 
Ciclo Caso de Uso 
1 UC1, REL03 
2 UC2, REL02 
3 UC3, REL01 
4 CRUD1 
5 CRUD2 
Quadro 3: Identificação e classificação de casos de uso. 
 
 
2. FASE DE ELABORAÇÃO 
 
É a segunda fase do UP cujo objetivo, segundo LARMAN (2008), é iniciar as iterações 
durante as quais a arquitetura central e de alto risco do software é programada e testada, 
a maioria dos requisitos é descoberta e estabilizada e os principais riscos são mitigados 
ou retirados. 
Segundo LARMAN (2008), a análise de domínio representa a investigação a fim de se 
identificar classes conceituais relacionadas com os requisitos da iteração corrente, criar 
um modelo de domínio inicial e modelar atributos e associações adequadas. Desta forma, 
um modelo de domínio ilustra importantes conceitos em um domínio. 
 
 
2.1. ANÁLISE 
 
A subfase de análise da fase de elaboração se concentra na análise dos casos de uso 
significantes à arquitetura do sistema. Estes casos de uso, que representam um pouco 
um pouco mais de 10% do total de casos de uso definidos, são analisados visando a 
complementação do trabalho de análise arquitetural feito na fase de concepção. Assim, 
tendo como ponto de partida a arquitetura definida superficialmente durante a fase de 
concepção, este fluxo de análise poderá definir uma base sólida para a arquitetura do 
sistema de forma a se conseguir uma arquitetura executável. (SEABRA, 2001). 
A fase de análise, comporta três subatividades distintas (WAZLAWICK, 2011), as 
quais serão tratadas a seguir: 
a) Expansão dos casos de uso 
b) Construção ou refinamento do modelo conceitual 
c) Elaboração dos contratos das operações e consultas de sistema 
 
 
2.1.1. Expansão de Casos de Uso – UC3 Registrar Táxi 
 
A expansão dos casos de uso representa a atividade de análise de requisitos, cujo 
modelo foi obtido do autor Wazlawick (2010). O objetivo dessa fase corresponde ao 
aprofundamento da análise de requisitos, realizando um exame detalhado dos processos 
envolvidos. Deve-se descrever o caso de uso passo a passo: como ele ocorre e como é a 
interação entre atores e o sistema. Deve-se evitar mencionar interfaces ou tecnologia, 
mas apenas dizer quais informações os atores passam ao sistema e quais informações o 
sistema passa aos atores (WAZLAWICK, 2011). 
 
NOME: UC3 – Registrar Táxi ATOR: Administrador 
FLUXO PRINCIPAL 
PASSO DESCRIÇÃO 
1 O Administrador deseja registrar um novo táxi na frota, com seu 
respectivo motorista. 
2 O Sistema apresenta todos os motoristas registrados. 
3 O Administrador escolhe o motorista de interesse. 
4 O Sistema apresenta todos os taxímetros registrados 
5 O Administrador escolhe um taxímetro. 
6 O Administrador informa os dados do táxi, tais como: placa, marca, 
modelo e anoModelo. 
7 O Sistema registra o táxi. 
FLUXOS ALTERNATIVOS 
3a – Motorista não cadastrado 
3a.1 – O Administrador informa nome completo,cpf, rg, número da CNH, 
validade da CNH, categoria da CNH e celular do motorista. 
3a.2 – O Sistema registra o novo motorista. 
3a.3 – Retornar ao passo 2 do fluxo principal 
5a – Taxímetro não cadastrado 
5a.1 – O Administrador informa o valor mínimo, taxa por km rodado, km 
rodados por deslocamento completo, valor total do deslocamento, total de 
Km rodados, número de deslocamentos, número de referência. 
5a.2 – O Sistema registra o novo taxímetro. 
5a.3 – Retornar ao passo 4 do fluxo principal 
 
 
 
2.1.2. Identificação de Operações e Consultas de Sistema – UC3 Registrar Táxi 
 
Walzlawick (2011, p. 73), define as operações e consultas de sistema: 
 Operações de sistema são métodos que são ativados a partir de um evento de 
sistema, ou seja, como resposta a uma ação de um usuário. As operações de 
sistema, por definição, indicam um fluxo de informações do exterior para o interior 
do sistema e, portanto, de alguma forma, elas alteram as informações gerenciadas 
pelo sistema. 
 Consultas de sistema são métodos que correspondem à simples verificação de 
informações já armazenadas. Essa informação pode ser apresentada exatamente 
como está ou ser modificada pela aplicação de funções. Mas, por definição, uma 
consulta de sistema não deve ser responsável por inserir, remover ou alterar 
informações armazenadas. 
A partir do caso de uso expandido, é possível encontrar as operações e consultas, 
marcando-as com [IN] para as operações e com [OUT] para as consultas, como vemos a 
seguir. 
 
Nome: UC3 – Registrar Táxi Ator: Administrador 
Fluxo Principal 
Passo Descrição 
1 [IN] O Administrador deseja registrar um novo táxi na frota, com seu 
respectivo motorista. 
2 [OUT] O Sistema apresenta todos os motoristas registrados. 
3 [IN] O Administrador escolhe o motorista de interesse. 
4 [OUT] O Sistema apresenta todos os taxímetros registrados 
5 [IN] O Administrador escolhe um taxímetro. 
6 [IN] O Administrador informa os dados do táxi, tais como: placa, marca, 
modelo e anoModelo. 
7 [IN] O Sistema registra o táxi. 
Fluxos Alternativos 
3a – Motorista não cadastrado 
3a.1 – [IN] O Administrador informa nome completo, cpf, rg, número da CNH, 
validade da CNH, categoria da CNH e celular do motorista. 
3a.2 – [IN] O Sistema registra o novo motorista. 
3a.3 – Retornar ao passo 2 do fluxo principal 
5a – Taxímetro não cadastrado 
5a.1 – [IN] O Administrador informa o valor mínimo, taxa por km rodado, km 
rodados por deslocamento completo, valor total do deslocamento, total de Km 
rodados, número de deslocamentos, número de referência. 
5a.2 – [IN] O Sistema registra o novo taxímetro. 
5a.3 – Retornar ao passo 4 do fluxo principal 
 
A UML possui um diagrama que pode ser útil para representar a sequência dos 
eventos de sistema (operações e consultas) em um cenário de caso de uso. As linhas do 
tempo, representadas na vertical, correspondem ao/aos atores, a interface e ao sistema 
(controlador), respectivamente. As operações e consultas, na horizontal, são numeradas 
em ordem crescente, de forma que as linhas contínuas são as operações [IN] e as linhas 
pontilhadas são as consultas [OUT]. 
Tanto para o fluxo principal quanto para os fluxos alternativos, foram elaborados 
diagramas de sequência com o auxílio do Astah Community versão 6.7. 
 
Diagrama 1: Fluxo principal do caso de uso Registrar Táxi. 
 
Diagrama 2: Fluxo alternativo Motorista Não Cadastrado do caso de uso Registrar Táxi. 
 
Diagrama 3: Fluxo alternativo Taxímetro Não Cadastrado do caso de uso Registrar Táxi. 
A partir da análise dos diagramas de sequência dos fluxos de informações, temos o 
seguinte quadro de operações e consultas de sistema: 
Operações de Sistema Consultas de Sistema 
motoristaEscolhido(nomeMotoristasRegistrados) listarMotoristas() 
taximetroEscolhido(nroReferenciaTaximetros) listarTaximetros() 
registrarTaxi(placa, marca, modelo, anoModelo) 
novoMotorista(nome, cpf, rg, numeroCNH, 
validadeCNH, celular) 
 
registrarTaximetro(vlrMinimo, taxaKm, 
nroReferencia) 
 
 
 
2.1.3. Modelagem Conceitual – UC3 Registrar Táxi 
 
O modelo conceitual deve descrever a informação que o sistema vai gerenciar. 
Trata-se de um artefato do domínio do problema e não do domínio da solução 
(WAZLAWICK, 2011). Não deve ser confundido com o diagrama de classes, da 
arquitetura do software, nem com o modelo de dados, do banco de dados. No 
desenvolvimento, apenas são representados aspectos estáticos da informação, 
modelados a partir de uma visão externa do sistema. 
O modelo conceitual dessa etapa do projeto é uma versão refinada do modelo 
conceitual preliminar, desenvolvido na etapa de concepção. Para o desenvolvimento, o 
diagrama de classes da UML é utilizado, com algumas restrições. Informalmente, 
podemos dizer que o modelo conceitual é um diagrama de classes sem métodos. Apenas 
conceitos, atributos e associações são representados. 
Com o auxílio da ferramenta Astah Community versão 6.7, usando o diagrama de 
classes da UML, foi desenvolvido o modelo conceitual a seguir: 
 
Figura 1: Modelo conceitual do sistema. 
 
2.1.4. Elaboração de Contratos – UC3 Registrar Táxi 
 
A este ponto do UP, a análise produziu dois artefatos importantes: 
a) O modelo conceitual, que representa estaticamente a informação a ser gerenciada 
pelo sistema. 
b) Os casos de uso expandidos, que mostram como os usuário trocam informações 
com o sistema, sem mostrar, porém, como a informação é processada 
internamente ao sistema. 
Na elaboração dos diagramas de sequência, foram identificados as operações e 
consultas de sistema. Cada operação ou consulta implica a existência de uma intenção 
por parte do usuário. Essa intenção é capturada pelos contratos de operações e consultas 
de sistema, que correspondem a modelagem funcional do sistema. (WAZLAWICK, 2011). 
Um contrato de operação de sistema pode ter as seguintes seções: 
a) Pré-condições (opcional) 
b) Pós-condições (obrigatória) 
c) Exceções (opcional) 
Já um contrato para uma consulta de sistema pode ter duas seções: 
a) Pré-condições (opcional) 
b) Resultados (obrigatória) 
 
Contratos para o UC3 – Gerenciar Táxi: 
Operações de sistema: 
1. RegistrarTaxiFP::motoristaEscolhido(nomeMotoristasRegistrados) 
a. Pré-condições 
i. Existe um motorista no cadastro com o atributo “nome” igual ao 
parâmetro nomeMotoristasRegistrados. 
b. Pós-condições 
i. Foi criada uma associação entre o Controlador e Motorista, 
denominada motoristaCorrente. 
2. RegistrarTaxiFP::taximetroEscolhido(nroReferenciaTaximetros) 
a. Pré-condições 
i. Existe um taximetro no cadastro com o número de referência igual ao 
parâmetro nroReferenciaTaximetros. 
b. Pós-condições 
i. Foi criada uma associação entre Controlador e Taximetro, 
denominada taximetroCorrente. 
3. RegistrarTaxiFP::registrarTaxi(placa, marca, modelo, anoModelo) 
a. Pré-condições 
i. Existe um motoristaCorrente. 
ii. Existe um taximetroCorrente. 
b. Pós-condições 
i. Foi criada uma instancia de Taxi chamada taxiCorrente. 
ii. Foi criada uma associação entre taxiCorrente e motoristaCorrente, 
denominada motoristaResponsavel. 
iii. Foi criada uma associação entre taxiCorrente e taximetroCorrente, 
denominada taximetroVinculado. 
iv. Os atributos de taxiCorrente foram alterados, tendo seus valores 
substituídos pelos parâmetros placa, marca, modelo, anoModelo. 
4. RegistrarTaxiFAmotoristaNaoCadastrado::novoMotorista(nome, cpf, rg, 
numeroCNH, validadeCNH, celular) 
a. Pré-condições 
i. Não existe motorista cadastrado com o atributo cpf igual ao 
parâmetro cpf. 
b. Pós-condições 
i. Foi criada umainstancia de Motorista chamada de motoristaCorrente. 
ii. Foi criada uma associação entre Motorista e Controlador, 
denominada novoMotorista. 
iii. Os parâmetros nome, cpf, rg, numeroCNH, validadeCNH, celular 
foram atribuídos aos atributos de motoristaCorrente. 
5. RegistrarTaxiFAtaximetroNaoCadastrado::registrarTaximetro(vlrMinimo, taxaKm, 
nroReferencia) 
a. Pré-condições 
i. Não existe taximetro cadastrado com o atributo nroReferencia igual 
ao parâmetro nroReferencia. 
b. Pós-condições 
i. Foi criada uma instancia de Taximetro chamada de 
taximetroCorrente. 
ii. Foi criada uma associação entre Taximetro e Controlador, 
denominada novoTaximetro. 
iii. Os parâmetros vlrMinimo, taxaKm, nroReferencia foram atribuídos 
aos atributos de taximetroCorrente. 
Consultas de sistema: 
1. RegistrarTaxiFP::listarMotoristas() 
a. Pré-condições: 
i. Nenhuma. 
b. Resultados 
i. Retorna o atributo “nome” de todos os motoristas do cadastro. 
2. RegistrarTaxiFP::listarTaximetros() 
a. Pré-condições 
i. Nenhuma. 
b. Resultados 
i. Retorna o atributo “nroReferencia” de todos os taxímetros do 
cadastro. 
Com os contratos feitos, a análise pode ser considerada concluída dentro do ciclo 
iterativo atual e passa-se para a fase de projeto. 
 
2.2. PROJETO DE DOMÍNIO – UC3 Registrar Táxi 
 
No processo unificado um dos tipos de projeto é o projeto de camada de domínio, 
que corresponde ao conjunto de classes do sistema, e nesta camada que é será realizada 
toda a parte lógica do sistema. O projeto de domínio embasa as demais camadas 
(persistência, interface, segurança, etc.). 
Segundo Wazlawick (2004, p. 183 e 184) a camada de domínio é composta por 
duas atividades: 
A) Definir os diagramas de colaboração e definir um diagrama de colaboração para 
cada contrato identificado na análise. 
B) Elaborar o diagrama de classes de projeto, que se baseia no modelo conceitual 
adicionado de algumas informações que não eram identificadas nas fase de análise. 
Com base na afirmação de Wazlawick podemos dizer que para elaborar o projeto de 
camada de domínio é necessário ter em mãos dois artefatos da fase de análise que 
estejam corretos. Os artefatos são o modelo conceitual e os contratos das operações e 
consultas de sistemas. 
 
2.2.1. Elaboração do Diagrama de Comunicação 
 
O diagrama de comunicação, também conhecido como diagrama de colaboração, 
permite realizar a modelagem dinâmica do sistema, diferentemente dos artefatos já 
concluídos, que são estáticos. Nessa fase, veremos como os objetos que fazem parte da 
arquitetura do sistema trocam mensagens para realizar suas responsabilidades. 
O diagrama de sequência tem a ênfase na visão do sistema no decorrer do tempo, 
enquanto o diagrama de comunicação tem a ênfase no contexto do sistema, ou seja nas 
classes participantes e nas interações entre elas (SOMMERVILLE, 2007). Ambos são 
conhecidos como diagramas de interação. 
Basicamente o diagrama de comunicação é composto por: 
1. Objetos: representantes das classes que trocam mensagens entre si. 
2. Interações entre objetos 
3. Mensagens 
A passagem do tempo não é mais representada por linhas verticais (diagrama de 
sequência), mas sim através de uma numeração sequencial, podendo ser simples (1,2,3, 
...) ou composta (1.1, 1.2, 1.2.1, …). 
O diagrama a seguir demonstra a troca de mensagens do caso de uso Registrar 
Taxi, do nosso sistema. 
 
Figura 2: Diagrama de comunicação 
 
2.2.2. Diagrama de Classe de Projeto 
 
O diagrama de classes do projeto é realizado a partir do modelo conceitual e 
dos diagramas de colaboração desenvolvidos no ciclo. Pode-se dizer que o diagrama de 
classes e o modelo conceitual tem objetivos distintos, apesar um ser construído a partir do 
outro. (WAZLAWICK, 2004) 
As mudanças básicas a serem feitas no DCP durante o projeto da camada de 
domínio são: 
a) Adição de métodos. Na atividade de análise, apenas as operações e 
consultas de sistema foram determinadas e adicionadas na classe controladora. Na 
atividade de projeto os métodos delegados encontrados serão adicionados nas das 
demais classes; 
b) Adição da direção das associações. Na atividade de análise, as associações 
do modelo conceitual eram não direcionais. Na atividade de projeto será determinada a 
direção de navegação das associações em função da direção das mensagens nos 
diagramas de comunicação; 
c) Possível detalhamento dos atributos e associações. É possível que, na 
atividade de análise, nem todos os atributos tenham seus tipos definidos. Nesses casos, 
esses elementos poderão ser adicionados na atividade de projeto, na medida do 
necessário. Além disso, os tipos abstratos de dados definidos nos papéis de associações 
poderão ser substituídos por tipos concretos (por exemplo, trocar lista por array ou lista 
encadeada); 
d) Possível alteração na estrutura das classes e associações. Pode ser 
necessário criar novas classes para implementar certas estruturas de projeto, como 
estratégias, por exemplo. Assim, é possível que a estrutura de classes do DCP não 
corresponda exatamente à mesma estrutura do modelo conceitual em alguns casos; 
e) Possível criação de atributos privados ou protegidos. No modelo conceitual, 
todos os atributos devem ser públicos porque ali se está representado a informação 
disponível. Assim, não faz sentido que seja modelada alguma informação que não possa 
ser acessível fora da classe. Porém quando se inicia a descrição dos aspectos dinâmicos 
e de representação interna dos objetos, pode ser necessário trabalhar com atributos 
privados ou protegidos para encapsular estados internos que determinarão o 
funcionamento de alguns métodos. 
O diagrama a seguir demonstra o diagrama de classes do projeto para o sistema 
de controle dos táxis. 
 
Figura 3: Diagrama de classes do projeto. 
 
2.3. PROJETO DE INTERFACE 
 
Segundo Wazlawick (2004, p. 257) o projeto da camada de interface pode ser 
dividido nas seguintes subcamadas: 
A) Apresentação: É uma camada com as classes que representam os objetos 
gráficos de interface onde sua função se resume a receber e enviar dados ao usuário. 
B) Aplicação: É uma camada que controla toda a lógica da interface. 
A interface é baseada em janelas, onde suas tarefas do projeto de interface tem 
como função determinar as janelas do sistema, e quais as possibilidades de navegação 
entre as janelas, fazer o projeto gráfico e associar o mesmo a controles e eventos de 
navegação, e determinar quais são os controles que estarão habilitados ao usuário em 
determinado momento. 
Para fazer o projeto de interface o projetista deverá saber qual o objetivo de cada 
janela, quais os fluxos alternativos cada janela irá atender de cada caso de uso. 
Segundo Sommerville (2007, p.241), o projeto de interface tem como princípios 
básicos a familiaridade de usuário, pois o sistema deve se basear na experiência do 
usuário que fará o uso do sistema. O sistema deve ser consistente, não deve surpreender 
o usuário com comportamentos não esperados, e por fim o sistema deve interagir de 
maneira coerente com cada tipo de usuário. 
 
2.3.1. Elaboração do Diagrama de Estados de Navegação 
 
O diagrama de estados de navegação indica quais são as janelas que compõe o 
sistema e quais eventos permitem ao usuário navegar de uma para outra. Com o 
diagrama de estados de navegação pode-se ter uma clara visão de como se dará a 
navegação dentro da aplicação quando esta estiver finalizada. Cada evento que rotula as 
transições do diagrama será posteriormente associado a um controle (um botão, por 
exemplo) da janela na origem da transição. 
 
Figura 4: Diagrama de estados denavegação para o caso de uso abordado. 
 
2.3.2. Projeto Gráfico da Tela Central 
 
Segundo WAZLAWICK (2004), para fazer o projeto gráfico de cada janela, o 
projetista deverá saber quais são os objetivos da janela e qual caso de uso ela realiza. É 
possível também que algumas janelas realizem apenas alguns fluxos alternativos de um 
caso de uso. 
O projetista deve ficar atento aos seguintes detalhes quando estiver projetando 
a aparência de uma janela: 
a) Quais são os eventos de navegação que saem da janela no diagrama de 
estados de navegação. A cada evento corresponderá a um controle na interface 
(possivelmente um botão). 
b) Quais as operações de sistema realizadas na janela. Para cada operação 
deverá haver um controle de ativação (possivelmente um botão) e um campo de entrada 
para cada um dos parâmetros (possivelmente caixas de texto, menus ou campos auto 
completar). 
c) Quais as consultas de sistema realizadas na janela. Para cada consulta verá 
haver um controle de ativação (possivelmente um botão) e um campo de entrada para 
cada um dos parâmetros (possivelmente caixa de texto, menus ou campos auto 
completar), além de campos para exibição de cada um dos resultados. 
d) Cada transação efetuada em uma janela deve ter um início e um fim com a 
possibilidade de desistência. Assim, o projetista deverá determinar controles associados 
aos eventos de controle de transação. Esses controles poderão ser compartilhados com 
eventos de navegação, operação ou consulta de sistema, ou poderão ser controles 
independentes. 
 
Figura 5: Projeto gráfico da tela central do sistema. 
A primeira interação que o usuário realizará com o sistema é na tela de login onde 
ele estará "entrando" no sistema e a tela que estará disponível para ele é a de registrar 
taxi. Após feito isso o usuário terá as seguintes opções a sua disposição: Cadastrar 
Motorista, Cadastrar Taxímetro ou então escolher um taxímetro e motorista já cadastrado, 
e inserir informações como placa do taxi, marca, modelo e ano modelo do taxi, e também 
salvar as informações ou encerrar o sistema. 
Relação entre os componentes do projeto gráfico e as operações e consultas do sistema: 
Botão "Cadastrar Motorista" 
 Através do evento onClick ativa a navegação para "Cadastrar Motorista". 
Botão "Cadastrar Taxímetro" 
 Através do evento onClick ativa a navegação para "Cadastrar Taxímetro". 
Botão "Salvar" 
 Através do evento onClick ativa a função de salvar todas as informações inseridas 
no sistema. 
Botão "Encerrar" 
 Através do evento onClick ativa a função de finalizar o sistema. 
Campo "Nome Motorista" 
 Possibilita a escolha do nome de algum motorista já cadastrado. 
Campo "Número Taxímetro" 
 Possibilita a escolha do número de algum taxímetro já cadastrado. 
Campos "Placa, Marca, Modelo, Ano Modelo" 
 São campos para a inserção de informações sobre o táxi. 
 
3.0 Glossário 
 
Sem termos desconhecidos para citar. 
 
REFERÊNCIAS 
 
COSER, M. A.; CARVALHO, H. G.; KOVALESKI, J. L. A gestão do conhecimento no 
apoio à gestão de requisitos em software. Disponível em: 
http://www.simpep.feb.unesp.br/anais/anais_13/artigos/125.pdf. Acesso em 26 mar. 2013. 
FERNANDES, DANIEL BATISTA. Análise de Sistemas Orientada ao Sucesso. Rio de 
Janeiro: Ciência Moderna, 2005. 
FOWLER, M. UML Essencial: Um Breve Guia Para a Linguagem-Padrão de Modelagem 
de Objetos. 3. ed. Porto Alegre: Bookman, 2005. 
PRESSMAN, R. S. Engenharia de Software: Uma Abordagem Profissional. 7. ed. Porto 
Alegre: AMGH, 2011. 
SEABRA, R. M. J. Análise e Projeto Orientado a Objetos Usando UML e o Processo 
Unificado. Belém, 2001. 
SOMMERVILLE, I. Engenharia de Software. 8. ed. São Paulo: Pearson Addison-Wesley, 
2007. 
WAZLAWICK, R. S. Análise e Projeto de Sistemas de Informação Orientados a Objetos. 
Rio de Janeiro: Elsevier, 2004. 
WAZLAWICK, R. S. Análise e Projeto de Sistemas de Informação Orientados a Objetos. 
2. ed. Rio de Janeiro: Elsevier, 2011.