ES_I_Aula04

Prévia do material em texto

�1
Bacharelado em
Ciência da 
Computação
2014
Engenharia de Software I
Rogério Eduardo Garcia
(rogerio@fct.unesp.br)
Aula 04
In a calm sea every man is a pilot.
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 2
Engenharia de Software I –
Aula 4
� Revisão
� Introdução ao Método Larman
� Planejar e Elaborar
� Construir
� Analisar
� Revisão de conceitos de Orientação a Objetos
�2
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 6
Padrão IEEE para o
Documento de Requisitos
� 1 Introdução
� 1.1 Propósito do documento de requisitos
� Motivações, público-alvo, ...
� 1.2 Escopo do produto
� Explicitar o que o produto faz (e o que não faz).
� Descrever a aplicação.
� 1.3 Definições, acrônimos e abreviações
� 1.4 Referências
� Listar todos os documentos referenciados.
� Especificar a origem dos documentos.
� 1.5 Visão geral do restante do documento
� Estrutura/organização.
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 7
Padrão IEEE para o
Documento de Requisitos
� 2 Descrição Geral
� 2.1 Perspectiva do Produto
� Relacionamento: sistema, usuário, hardware, software,
comunicação.
� 2.2 Funcionalidades do Produto
� 2.3 Características do Usuário
� 2.4 Restrições Gerais
� Limitações de hardware, considerações sobre segurança,
...
� 2.5 Suposições e Dependências
� Máquina específica, sistema operacional, ...
�3
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 8
Padrão IEEE para o
Documento de Requisitos
� 3 Requisitos Específicos
� Abrangem os requisitos funcionais, não funcionais e de interface.
� Os requisitos podem documentar interfaces externas, descrever
funcionalidade e desempenho do sistema, especificar requisitos
lógicos de banco de dados, restrições de projeto, propriedades
emergentes do sistema e características de qualidade.
� 4 Apêndices
� 5 Índice
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 9
Análise de Requisitos
ANÁLISE DE
REQUISITOS
Engenharia de 
Sistemas de 
Computador
Projeto de 
Software
Como Proceder?
�4
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 10
Princípios da Análise
� O domínio de informação de um problema deve ser
representado e compreendido
� Modelos que descrevam a informação, função e
comportamento do sistema devem ser
desenvolvidos
� Os modelos devem ser divididos em partições, de
maneira que revele os detalhes em forma de
camadas, preferencialmente
� O processo de análise deve ter como foco a
informação essencial do (UdeI) – detalhes de
implementação ficam para a fase de Projeto
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 11
Princípios da Especificação
� Separar funcionalidade de implementação
� Uso de uma linguagem de especificação orientada
ao processo
� A especificação deve abranger o sistema do qual o
software é um componente
� A especificação deve abranger o sistema no qual o
software opera
�5
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 12
Princípios da Especificação 
(Cont.)
� Uma especificação deve ser um modelo cognitivo
� Uma especificação deve ser operacional
� Uma especificação deve ser tolerante com a não-
inteireza e ser expansível
� Uma especificação deve ser localizada e
fracamente acoplada
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 13
Estabelecimento das 
necessidades do sistema
Estudo de 
viabilidade 
Modelagem 
do sistema 
Definição 
dos 
requisitos 
Especif. 
dos 
requisitos 
Especific.
do sistema 
Documento de 
requisitos 
Relatório de 
viabilidade 
Relatório de 
necessidades 
Especificação
do projeto 
Formulação dos requisitos
�6
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 14
Para que tudo isso?
� Obter uma descrição dos requisitos
� Propor uma solução (“software”) que atenda
ao requisitos da melhor maneira possível
� Possibilidade de avaliar não apenas a
proposta, mas também as conseqüências de
decisões tomadas em tempo de projeto
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 15
Problema Solução
Abstrato
Concreto
Problema X Solução
�7
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 16
Portanto...
� É preciso planejar considerando a maneira
com que um projeto será implementado...
Orientado a Objetos
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 18
Mundo x Paradigma OO
� Mundo Real é formado por objetos que se
interagem
� Representar esses objetos em um software é mais
natural e permanente do que representar a sua
funcionalidade (decomposição funcional), pois essa
é mutável
� A representação usando objetos facilita o
mapeamento do mundo real, ou seja, a criação de
um modelo que o represente
�8
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 19
Problema...
ESPAÇO DE
PROBLEMAS
ESPAÇO DE
SOLUÇÕES
Gap Semântico
Mundo Real Mundo Computacional
Todo software representa um Modelo de um problema 
do mundo real, no Espaço de Soluções
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 21
Gap Semântico
� Quanto menor o Gap (diferença entre espaços)
mais fácil será :
� o desenvolvimento da aplicação
� assegurar a compreensão, confiabilidade e manutenção
da aplicação
� Diminuir o Gap implica em tornar o mapeamento do
mundo real (modelo) mais próximo da realidade
� Sendo mais “natural”, o Paradigma de Orientação a
Objetos tem por objetivo diminuir o gap semântico
�9
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 22
Criação de Modelos
Mapeamento
Processo de Identificação de 
“coisas” do mundo real para 
compor o modelo
ABSTRAÇÃO Modelo Conceitual
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 23
Problema Solução
Abstrato
Concreto
Problema X Solução
�10
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 24
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 25
Método Larman: Visão Geral
Tópicos e
Habilidades
Padrões
Desenvolvimento
Iterativo
A/POO
Notação UML
Princípios e
Diretrizes
Engenharia de
Requisitos
�11
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 26
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 27
UML
� História da UML
� início em 1994 – esforço conjunto de Booch e
Rumbaugh para combinar as notações
diagramáticas de seus métodos Booch e OMT
(Object Modeling Technique)
� a eles juntaram-se outros colaboradores
� adotada como padrão em 1997 pela OMG
� continua a ser refinada…
� versão 2.0 em andamento (???)
�12
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 28
UML
� Segundo OMG: “A UML (Unified Modeling
Language - Linguagem de Modelagem Unificada) é
uma linguagem para especificar, visualizar, construir
e documentar os artefatos de sistemas de software,
bem como para modelar negócios e outros sistemas
quenão sejam de software”
� Notação UML - principalmente diagramática, para
modelagem de sistemas usando conceitos
baseados na metáfora de “objetos”
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 31
UML
� A UML é a linguagem padrão para visualizar,
especificar, construir e documentar os
artefatos de um sistema intensamente
baseado em software
� Pode ser usada com todos os processos,
durante todo o ciclo de desenvolvimento, e
com diferentes tecnologias de
implementação;
�13
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 32
Diagramas 
� Use Case
� Diagramas de Estrutura Estática
� Diagrama de Objetos
� Diagramas de Classe
� Diagramas de Interação
� Diagrama de Seqüência
� Diagrama de Colaboração
� Statecharts
� Diagramas de Atividade
� Diagrama de Implementação
� Diagrama de Componentes
� Diagrama de Desdobramentos (Deployment)
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 33
Problema Solução
Abstrato
Concreto
Problema X Solução
Diagrama de
Classes
Diagrama de
Classes
�14
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 34
Método Larman: Visão Geral
� Processo Planejar e Elaborar
� Casos de Uso: Formatos, Tipos e Diagrama
� Modelo Conceitual: Conceitos e Associações
� Processo Construir (Fase Analisar)
� Modelo Conceitual: Agregações, Generalizações e
Tipos Associativos
� Diagramas de Seqüência
� Contratos de Operação
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 35
Método Larman: Visão Geral
� Auxiliar o desenvolvedor a:
� Aplicar princípios, diretrizes e padrões na
construção de software
� Seguir um conjunto de atividades comuns de
análise e projeto, a partir de um ciclo de
desenvolvimento iterativo
� Criar diagramas freqüentemente utilizados na
notação UML
�15
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 36
Desenvolvimento Iterativo
� Um ciclo de vida iterativo (CVI) envolve a repetição
dos ciclos de planejamento, elaboração, construção
e instalação
� O sistema cresce pela adição de novas funções (e
refinamento das existentes) em cada ciclo iterativo
� Cada ciclo ataca um pequeno conjunto de requisitos
planejar
elaborarconstruir
instalar
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 37
Método Larman
Planejar e
Elaborar Construir Instalar
Ciclo de 
Desenvolvimento 1
Ciclo de 
Desenvolvimento 2 …
Refinar
Plano
Sincronizar
Artefatos
Analisar Projetar Construir Testar
�16
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 38
Método Larman
Planejar e
Elaborar Construir Instalar
Ciclo de 
Desenvolvimento 1
Ciclo de 
Desenvolvimento 2 …
Refinar
Plano
Sincronizar
Artefatos
Analisar Projetar Construir Testar
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 39
Método Larman: Planejar e 
Elaborar
Planejar e Elaborar Construir Implantar
1. Definir
Plano Inicial
2. Criar Relatório de
Investigação Preliminar 3. Definir Requisitos
4. Registrar
Termos no Glossário a
5. Implementar
Protótipo bd
6. Definir Casos de Uso
(Alto Nível e Essenciais)
7. Definir Modelo
Conceitual Inicial c
8. Definir Arquitetura
Inicial do Sistema acd
9. Aperfeiçoar (Refinar)
Plano
a 
o
n
go
in
g
b 
o
pc
io
n
al
c 
ad
iá
v
el
d 
o
rd
em
 
v
ar
ia
da
�17
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 40
Método Larman
Planejar e Elaborar Construir Implantar
1. Definir
Plano Inicial
2. Criar Relatório de
Investigação Preliminar 3. Definir Requisitos
4. Registrar
Termos no Glossário
5. Implementar
Protótipo
6. Definir Casos de Uso
(Alto Nível e Essenciais)
7. Definir Modelo
Conceitual Inicial
8. Definir Arquitetura
Inicial do Sistema
9. Aperfeiçoar (Refinar)
Plano
Engenharia de Requisitos
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 41
Entendimento dos Requisitos
� Objetivos:
� Criar os artefatos da fase de engenharia de
requisitos
� Documento de Especificação de Requisitos
� Identificar e categorizar as funções do sistema
� Identificar e categorizar os atributos do sistema
e relacioná-los com as funções
JÁ VISTO!!!
�18
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 42
Funções do Sistema
� O QUE o sistema deve fazer?
� ex: autorizar pagamento por cartão de crédito
� funções do sistema devem ser identificadas e
listadas em agrupamentos lógicos
� Geralmente escritas da forma: “O sistema
deve fazer <X>”
� Cada função pode ser expressa em termos
de um ou mais requisitos que o sistema
deve atender
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 43
Tipos de Funções
� Evidente ou Visível (E): deve ser executada e o
usuário tem conhecimento de ela foi executada
� Oculta (O): deve ser executada, mas não é visível
para o usuário
� vale para muitos serviços técnicos de infra-estrutura, tais
como salvar a informação em um dispositivo permanente
de armazenamento
� são freqüentemente, e incorretamente, esquecidas durante
a fase de especificação de requisitos
�19
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 44
Tipos de Funções
� Enfeite/Decoração/Luxo (D): opcional
� sua adição não afeta significativamente o custo
ou outras funções. ???
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 45
Estudo de caso - TPV
� Descrição Geral:
� O propósito deste projeto é criar um terminal de
ponto de vendas (TPV) para ser usado em lojas
de varejo
� Clientes
� ObjectStore, Inc., uma multinacional que
comercializa objetos
�20
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 46
Estudo de caso - TPV
� Objetivos:
� O objetivo geral é aumentar a automatização
das compras (checkout) para permitir serviços e
processos comerciais mais rápidos, melhores e
mais baratos. Tipicamente, isso inclui:
� checkout (passagem pelo caixa) mais rápido para o
cliente
� análise rápida e precisa do crédito
� controle automático do estoque
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 47
TPV - Funções Básicas
� R1.1 – Registrar a venda em andamento (corrente),
isto é, os itens comprados (E)
� R1.2 – Calcular o total da venda corrente, incluindo
os cálculos de impostos e de cupons de desconto
(E)
� R1.3 – Capturar a informação de um item adquirido,
usando o código, obtido por um leitor de código de
barra, ou pela entrada manual do código do
produto, usando o código universal de produto
(CUP ou UPC) (E)
�21
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 48
Funções Básicas - TPV
� R1.4 – Reduzir a quantidade em estoque
quando a venda for finalizada (O)
� R1.5 – Registrar as vendas completadas (O)
� R1.6 – O funcionário (Caixa) deve abrir o
caixa (log in) com um Identificador (ID) e uma
senha para poder usar o sistema (E)
� R1.7 – Fornecer um mecanismo de
armazenamento permanente (O)
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 49
Funções Básicas - TPV
� R1.8 – Fornecer mecanismos de
comunicaçãointer-processos e inter-
sistemas (O)
� R1.9 – Exibir a descrição e o preço do item
registrado (E)
�22
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 50
Funções de Pagamento - TPV
� R2.1 – Tratar os pagamentos em dinheiro:
capturar a quantia recebida e informar o
troco (E)
� R2.2 – Tratar o pagamento com cartão de
crédito: captar a informação do cartão de
crédito por um leitor de cartões ou uma
entrada manual e autorizar o pagamento com
o serviço de autorização de crédito (externo)
da loja via conexão por modem (E)
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 51
Funções de Pagamento - TPV
� R2.3 – Registrar os pagamentos por crédito
no sistema de contas a receber da loja, uma
vez que o serviço de autorização de crédito
deve à loja a quantia oferecida como
pagamento (O)
� R2.4 – Tratar os pagamentos com cheque:
capturar o CPF por entrada manual e
autorizar o pagamento com o serviço de
autorização de crédito da loja (externo) via
conexão por modem (E)
�23
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 52
Atributos do Sistema – TPV 
� para R1.9 (Exibir a descrição e o preço do
item registrado (E))
� tempo de resposta: Max 5s � Obrigatório
� metáfora da interface:
� saída baseada em formulário � Obrigatório
� saída colorida � Desejável
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 53
Atributos do Sistema – TPV
� para R2.3 (Registrar os pagamentos por
crédito no sistema de contas a receber da
loja (O))
� tolerância a falhas: deve registrar no sistema de
contas a receber em 24h, mesmo em caso de
falhas elétrica ou de hardware � Obrigatório
� tempo de resposta: Max 10s � Obrigatório
�24
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 54
Método Larman
Planejar e Elaborar Construir Implantar
1. Definir
Plano Inicial
2. Criar Relatório de
Investigação Preliminar 3. Definir Requisitos
4. Registrar
Termos no Glossário
5. Implementar
Protótipo
6. Definir Casos de Uso
(Alto Nível e Essenciais)
7. Definir Modelo
Conceitual Inicial
8. Definir Arquitetura
Inicial do Sistema
9. Aperfeiçoar (Refinar)
Plano
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 55
Casos de Uso: descrevendo 
processos
� Objetivos:
� Identificar e Escrever Casos de Uso
� Elaborar Diagramas de Casos de Uso
� Contrastar Casos de Uso de Alto Nível e
Expandidos
� Contrastar Casos de Uso Reais e Essenciais
�25
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 56
Casso de Uso –
Documentação
� Um documento de fluxo de eventos é criado para
cada caso de uso
� Escrito do ponto de vista do ator
� Detalha o que o sistema deve fornecer quando o
caso de uso é executado
� Conteúdos típicos
� Como o caso de uso inicia e termina
� Fluxo normal de eventos
� Fluxos alternativos de eventos
� Fluxos excepcionais de eventos (respostas a erros)
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 57
Casos de Uso
� Um caso de uso é um padrão de
comportamento que o sistema exibe
� Cada caso de uso é uma seqüência de
transações relacionadas executadas por um ator
e o sistema em um diálogo
�26
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 58
Casos de Uso
� Um caso de uso é um documento textual que
descreve a seqüência de eventos realizados por um
ator (um agente externo) para completar um
processo durante o uso do sistema
� Contam “histórias” de utilização do sistema
� Casos de uso não são especificação de requisitos,
mas ilustram e implicam requisitos
� dependem de que se tenha um entendimento ao menos
parcial dos requisitos do sistema
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 59
Atores
� Um ator é uma entidade externa ao sistema que
participa de um caso de uso de alguma forma.
� Atores interagem com o sistema, estimulando-o
com eventos de entrada ou de saída
� Representam o papel que desempenham no caso
de uso. Ex: Cliente, Caixa
� uma pessoa, por exemplo, pode assumir vários papéis
� várias pessoas podem ser instâncias de um ator
�27
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 60
Atores
� Atores podem ser papéis desempenhados
por pessoas, sistemas de computadores,
dispositivos elétricos e mecânicos, …
� Para um caso de uso, geralmente existe um
ator iniciador e possivelmente vários outros
atores participantes
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 61
Método Larman:
Formatos dos Casos de Uso
� de alto nível
� descreve o processo sucintamente, em duas ou
três sentenças
� são vagos a respeito de decisões de projeto e
são úteis para a compreensão dos principais
processos globais
� expandidos
� mostram mais detalhes
� compreensão mais profunda dos processos e
requisitos
�28
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 62
Caso de Uso de Alto Nível
Caso de uso: Comprar Itens
Atores: Cliente, Caixa
Tipo: primário (a ser discutido adiante…)
Descrição: Um Cliente chega ao balcão de saída da 
loja com itens que deseja comprar. O Caixa 
registra os itens de compra e recebe o 
pagamento. Quando termina, o Cliente sai 
com os itens comprados.
Usar verbo para 
nomear caso de 
uso
Nome de atores 
com letra 
maiúscula
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 63
Caso de Uso Expandido 
(Parte 1 - Resumo) 
(restrito a pagamento em dinheiro e sem tratar controle de estoque)
Caso de Uso: Comprar Itens com Dinheiro
Atores: Cliente (iniciador), Caixa
Finalidade: Capturar a venda e seu pagamento em dinheiro
Visão geral: Um Cliente chega ao balcão de saída da loja com itens que 
deseja comprar. O Caixa registra os itens de compra e 
recebe o pagamento. Quando termina, o Cliente sai com os 
itens comprados.
Tipo: primário e essencial (a ser discutido adiante…)
Referências Requisitos: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1
Cruzadas:
Informar ator que 
inicia o processo
�29
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 64
Caso de Uso Expandido
� Rastreabilidade
� A cláusula de referência cruzada permite conferir
se todos os requisitos foram atendidos por casos
de uso.
� Ao final, todos os casos de uso devem poder ser
rastreados para a implementação e o teste.
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 65
Lembrando...
� R1.1 – Registrar a venda em andamento … (E)
� R1.2 – Calcular o total da venda corrente … (E)
� R1.3 – Capturar a informação de um item adquirido,
usando o código… (E)
� R1.7 – Fornecer um mecanismo de armazenamento
permanente (O)
� R1.9 – Exibir a descrição e o preço do item
registrado (E)
� R2.1 – Tratar os pagamentos em dinheiro… (E)
�30
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 66
Caso de Uso Expandido 
Parte 2 - Seqüência típica de eventos
Ação do ator Resposta do Sistema
1. Este caso de uso começa quando o Cliente
chega ao TPV com itens para comprar
2. O Caixa registra o identificador de cada
item
3. Determina o preço do item e adiciona
informação sobre o item à transação de venda
corrente
Se há mais de um do mesmo item, ocaixa
também entra a quantidade
A descrição e o preço do item são
apresentados
4. Quando termina a entrada dos itens, o
Caixa indica ao TPV que as entradas estão
completas
5. Calcula e apresenta o total da venda
6. O Caixa informa o total ao cliente
7. O Cliente entrega o pagamento em dinheiro
– o “pagamento em dinheiro” – possivelmente
maior que o total da venda
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 67
Caso de Uso Expandido 
Parte 2 - Seqüência típica de eventos-Cont.
Ação do ator Resposta do Sistema
8. O Caixa registra a quantidade de dinheiro
recebida
9. Exibe o valor do troco a ser devolvido ao
cliente
10. O Caixa deposita o dinheiro recebido e
retira o troco devido
11. Registra a venda completada (logs)
O Caixa entrega ao cliente o troco e o recibo
impresso
12. O Cliente sai com os itens comprados
�31
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 68
Caso de Uso Expandido 
(Parte 3 – Seqüências Alternativas)
� Descreve alternativas importantes ou
exceções que podem ocorrer numa
seqüência típica
� se forem muito complexas podem se transformar
num caso de uso
� Seqüências alternativas:
� Linha 2: Identificador de item inválido digitado.
Indicar o erro.
� Linha 7: O Cliente não tem dinheiro suficiente.
Cancelar a transação de venda
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 69
Tipos de Casos de Uso (I) 
� Primários : principais processos comuns
Ex: Comprar Itens
� Secundários: processos menos importantes ou
raros
Ex: Requisição de estoque de produto novo
� Opcionais: processos que podem não ser incluídos
na solução
�32
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 70
Tipos de Casos de Uso (II)
� Essencial: caso de uso expandido expresso numa
forma ideal, que é relativamente livre de detalhes
tecnológicos e de implementação
� decisões de projeto são postergadas
� Real: descreve o processo em termos de seu
projeto atual (real)
� considera tecnologia, entrada e saída, interface,…
� definido na fase de projeto
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 71
Tipos de Casos de Uso (II)
� Casos de uso de alto nível são essenciais por
natureza, devido à sua forma resumida e alto nível
de abstração
� O intervalo entre essencial e real deve ser visto
como um contínuo em que o caso de uso pode se
situar em qualquer ponto
Real,
muito 
concreto
Essencial, 
muito 
abstrato
Requisitos/Anális
e
Projeto
�33
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 72
Caso de Uso Comprar Itens: 
Essencial
Ação do ator Resposta do Sistema
1. Este caso de uso começa quando o
Cliente chega ao TPV com itens para
comprar
2. O Caixa registra o identificador de
cada item
3. Determina o preço do item e adiciona
informação sobre o item à transação de
venda corrente
Se há mais de um do mesmo item, o
caixa também entra a quantidade
A descrição e o preço do item são
apresentados
4. … ….
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 73
Caso de Uso Comprar Itens: 
Real
Ação do Ator Resposta do Sistema
1. Este caso de uso começa quando o
Cliente chega ao TPV com itens para
comprar
2. Para cada item o Caixa digita o código
universal do produto no campo de
entrada UPC da janela. Ele então
pressiona o botão “Entrar Item” com o
mouse ou pressiona <Enter>
3. Mostra o preço do item e adiciona a
informação do item à transação de venda
corrente. A descrição e o preço são
mostrados na caixa de texto 2 da Janela1.
…. ...
�34
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 74
Importante
� Em geral, os casos de uso reais não devem
ser produzidos na fase de engenharia de
requisitos (comprometimento prematuro com
uma decisão de projeto e complexidade
desnecessária)
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 75
Resumo
Formato do caso de uso
Alto nível
Expandido
Tipo do caso de uso (I)
Primário
Opcional
Secundário
Tipo do caso de uso (II) Essencial
Real
�35
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 76
Diagrama de Casos de Uso: 
UML Diagram
� Objetivo
� Mostrar como o sistema a ser desenvolvido irá
interagir com o ambiente, delimitando o sistema e
definindo a funcionalidade
� Importantes na organização e modelagem do
comportamento do sistema
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 77
Diagrama de Casos de Uso
� Um diagrama de caso de uso mostra o
relacionamento entre os atores e os casos de uso
dentro de um sistema.
� Um caso de uso representa uma funcionalidade do
sistema.
� Representado por uma elipse contendo o nome do caso de
uso.
� Um ator é um agente externo (um usuário ou um outro
sistema) que interage com o sistema.
� Pode ser representado como um retângulo de classe com o
estereótipo "ator” ou pela figura de um homem estilizado.
�36
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 78
Diagrama de Casos de Uso: 
Notação
Comprar Itens
ícone para caso de uso
Caixa
ícone para ator
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 79
Diagrama de Casos de Uso
TPV
Comprar
Itens
Abrir 
(Log in)
Reembolsar
Itens
Caixa Cliente
�37
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 80
Diagrama de Casos de Uso
TPV
Comprar
Itens
Abrir 
(Log in)
Reembolsar
Itens
Caixa Cliente
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 81
Diagrama de Casos de Uso: 
Notação
� Relacionamentos entre casos de uso e atores:
� communicates: relacionamento entre atores e casos de
uso.
� extends: um relacionamento extends de um caso de uso
A para um caso de uso B indica que uma instância de B
pode incluir o comportamento especificado por A.
� include: um relacionamento include de um caso de uso A
para um caso de uso B indica que uma instância
de B inclui o comportamento especificado por A.
�38
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 82
Relacionamento <<include>> Relacionamento <<extends>>
ValidarCliente
Cliente RealizarPedido
<<include>>
CadastrarCliente
Cliente RealizarPedido
<<extends>>
Diagrama de Casos de Uso:
Notação
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 83
Diagrama de Casos de Uso: 
Exemplo
Leitor
Bibliotecário
Bibliotecário
Sistema de Biblioteca
<<extends>>
<< extends >>
Adicionar título
Manter
Reservar
Cancelar
reserva
Emprestar
Devolver
Remover
/atualizar
título
Adicionar item
Adicionar leitor
<< extends >>
<< extends >>
<< extends >>
�39
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 84
Identificação de casos de uso
� Dois métodos: baseado nos atores ou
baseado nos eventos do sistema
� Baseado em atores
� Identificar os atores relacionados a um sistema
ou organização
� Para cada ator, identificar os processos que eles
iniciam ou dos quais eles participam
� Exemplos:
� Caixa - Iniciar uso, Registrar retirada de dinheiro
� Cliente – Comprar itens, Reembolsar itens
BCC
2014
25/03/2014 Ciênciada Computação - Engenharia de Software I - Rogério Eduardo Garcia 85
Identificação de casos de uso
� Baseado em eventos
� Identificar os eventos externos aos quais um
sistema deve responder
� Relacionar os eventos a atores e a casos de uso
� Exemplos:
� Itens vendidos (ator=cliente, caso de uso=comprar
item)
� Dinheiro retirado (ator=caixa, caso de uso=registrar
retirada de dinheiro)
�40
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 86
Importante
� um caso de uso não representa um passo individual ou uma
operação ou transação de entrada. por exemplo: “imprimir o
recibo” não é um caso de uso no sistema de TPV
� um caso de uso é normalmente a descrição de um processo
relativamente grande, com início e fim próprios, que
normalmente incluem várias transações ou operações de
entrada e saída. Ex:
� retirar dinheiro de um caixa automático
� matricular-se em uma disciplina
� verificar ortográfica em um editor de texto
� …
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 87
Escopo do Sistema
� O sistema pode ser limitado por:
� Hardware ou software
� Departamentos de uma organização
� Toda a organização
� O limite é sempre delimitado arbitrariamente pelo
analista e o cliente, mas geralmente leva em conta
critérios tais como: política organizacional, limites de
menor comunicação entre os subsistemas,
oportunidade e tamanho do sistema
�41
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 88
Exemplo
Ex: considerar toda a loja como sendo 
o sistema. O caixa está dentro do 
sistema e é um de seus recursos.
LOJA
Comprar
Itens
Reembolsar
Itens
Cliente
TPV
Comprar
Itens
Abrir 
(Log in)
Reembolsar
Itens
Caixa Cliente
Limite do 
sistema
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 89
Decisão e Desvio
� Pontos de decisão e desvio podem ocorrer em um caso de
uso
� Ex: no caso de uso Comprar Itens, o cliente pode pagar em
dinheiro, cartão de crédito ou cheque
� Dividir o caso de uso em seções
� Para cada caso de uso:
� Parte 1 – Resumo
� Seção Principal
� parte 2 – seqüência típica de eventos
� parte 3 – seqüências alternativas
� Seção Pagamento com dinheiro
� parte 2 – seqüência típica de eventos
� parte 3 – seqüências alternativas
� Seção Pagamento com cartão de crédito
� …
�42
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 90
Caso de Uso Comprar Itens
Seção Principal 
Seqüência típica de eventos
Ação do ator Resposta do Sistema
1. Este caso de uso começa quando o Cliente chega
ao TPV com itens para comprar
2. O Caixa registra o identificador de cada item … 3. Determina o preço do item…
4. Quando termina a entrada dos itens… 5. Calcula…
6. O Caixa informa o total ao cliente
7. O Cliente escolhe o tipo de pagamento:
i. Se for pagamento em dinheiro, ver seção
Pagamento em Dinheiro
ii. Se for pagamento com cartão de crédito ver
seção Pagamento por Cartão de Crédito
iii. Se for pagamento por cheque, ver seção
Pagamento em Cheque
8. Registra a venda completada
9. O Caixa entrega o recibo para o Cliente
10. O Cliente sai da loja com os itens…
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 91
Caso de Uso Comprar Itens
Seção Pagamento com Dinheiro
Seqüência típica de eventos
Ação do ator Resposta do Sistema
1. O Cliente entrega o pagamento em
dinheiro, possivelmente maior que o total
da venda
2. O Caixa registra a quantidade de
dinheiro recebida
3. Exibe o valor do troco a ser devolvido
ao cliente
4. O Caixa deposita o dinheiro recebido e
retira o troco devido
O Caixa entrega o troco ao Cliente
Seqüência alternativa:
• Linha 4: Dinheiro insuficiente na gaveta para pagar o troco. Solicita 
dinheiro ao supervisor
�43
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 92
Planejar e Elaborar:
Passos do Processo
1. Listar todas as funções (requisitos), definir os limites do sistema e
identificar atores e casos de uso.
2. Escrever todos os casos de uso no formato de alto nível, classificando-
os como principais, secundários e opcionais.
3. Desenhar o diagrama de casos de uso.
4. Escrever o formato expandido dos casos de uso mais importantes,
mais complexos ou mais arriscados. Os demais poderão ser
expandidos quando forem tratados em fases posteriores do processo
de desenvolvimento.
5. Idealmente, postergar os casos de uso reais até a fase de projeto.
Exceções podem ocorrer se:
a) descrições concretas auxiliam grandemente a compreensão, ou
b) os clientes demandam que o processo seja especificado dessa
forma.
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 93
Exemplo – Sistema TPV
Os limites do sistema serão definidos como o sistema de hardware e 
software.
Atores e casos de uso:
Caixa: Abrir (Log In), Retirar dinheiro da caixa, Fechar 
Cliente: Comprar Itens, Reembolsar Itens
Gerente: Iniciar e Encerrar (o sistema)
Administrador do Sistema: Adicionar novo usuário
(Passo 1. Identificar atores, casos de uso e limites do sistema.)
�44
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 94
Exemplo – Sistema TPV
Caso de uso: Comprar Itens
Atores: Cliente (iniciador), Caixa
Tipo: primário 
Descrição: Um cliente chega ao balcão de saída da loja com 
itens para comprar. O caixa registra os itens de 
compra e recebe o pagamento. Quando termina, 
o cliente sai com os itens comprados.
(Passo 2. Escrever casos de uso no formato de alto nível.)
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 95
Caso de uso: Iniciar
Atores: Gerente
Tipo: primário 
Descrição: Um Gerente liga o sistema TPV de modo a 
prepará-lo para o uso pelos Caixas. O Gerente 
confere que as datas e hora estão corretas, após 
o que o sistema está pronto para uso dos Caixas.
Exemplo – Sistema TPV
(Passo 2. Escrever casos de uso no formato de alto nível.)
�45
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 96
TPV
Comprar
Itens
Abrir
Reembolsar
Itens
Caixa Cliente
Administrador 
Do Sistema
Gerente
Adicionar 
novos 
usuários
Iniciar
etc.
(Passo 3. Desenhar um 
diagrama de casos 
de uso.)
Exemplo:
Sistema TPV
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 97
Caso de Uso: Comprar Itens
Atores: Cliente (iniciador), Caixa
’
Propósito: Captura a venda e seu pagamento em dinheiro
Visão geral: Um cliente chega a um ponto de pagamento, com vários itens que 
deseja comprar. O caixa registra os itens de compra e recebe o 
pagamento, o qual pode necessitar autorização. No final, o cliente 
sai com os itens comprados.
Tipo: primário e essencial
Referências
Cruzadas: Funções: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1, R2.2, R2.3, R2.4
Casos de Uso: o caixa deve ter completado o caso de uso Abrir
(Passo 4. Escrever casos de uso essenciais expandidos.)Exemplo – Sistema TPV
�46
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 98
Seção : Principal
Seqüência Típica de Eventos
Ação do ator Resposta do sistema
1. Este caso de uso começa quando um Cli-
ente chega a um ponto de pagamento equi-
pado com um TPV, com vários itens que
deseja comprar.
2. O Caixa registra cada item. 3. Determina o preço do item e 
acrescenta informação sobre o 
Se houver mais de um exemplar do item, o itemà transação de vendas em andamento
Caixa também pode entrar a quantidade. A descrição e o preço do item corrente são 
apresentados 
4. No término da entrada de itens, o Caixa 5. Calcula e apresenta o total
indica para o TPV que a entrada de itens da venda.
está completa.
6. O Caixa informa ao Cliente o total.
(Passo 4. Escrever casos de uso essenciais expandidos.)Exemplo – Sistema TPV
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 99
(continuação…)
Ação do ator Resposta do sistema
7. O Cliente escolhe o tipo de pagamento:
a. Se pagamento em dinheiro, ver seção
Pagar com Dinheiro.
b. Se pagamento com cartão, ver seção
Pagar com Cartão de Crédito.
c. Se pagamento com cheque, ver seção
Pagar com Cheque.
8. Registra a venda completada.
9. Atualiza os níveis de estoque.
10. Gera um recibo.
11. O Caixa dá o recibo ao Cliente.
12. O Cliente sai com os itens comprados.
Seqüências alternativas
Linha 2: Entrada de Identificador de item inválido. Indicas erro.
Linha 7: Cliente não pode pagar. Cancelar a transação de venda.
(Passo 4. Escrever casos de uso essenciais expandidos.)Exemplo – Sistema TPV
�47
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 100
Seção: Pagar com Dinheiro
Seqüência Típica de Eventos
Ação do ator Resposta do sistema
1. O Cliente dá um pagamento em dinheiro.
O valor fornecido é possivelmente maior que o
total da venda.
2. O Caixa registra a quantia fornecida 3. Apresenta o troco devido ao
Cliente
4. O Caixa deposita o dinheiro recebido e retira
o troco devido.
O Caixa dá o troco ao Cliente
Seqüências Alternativas
Linha 1: O Cliente não tem dinheiro suficiente. Pode cancelar a venda ou iniciar outro método de 
pagamento
Linha 4: A gaveta de dinheiro não contém o suficiente para pagar o troco. O Caixa solicita mais dinheiro 
ao supervisor ou pede ao Cliente uma quantia de dinheiro diferente ou a opção por 
um outro método de pagamento
Exemplo – Sistema TPV(Passo 4. Escrever casos de uso essenciais expandidos.)
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 101
Seção: Pagar com Cartão de Crédito
Seqüência Típica de Eventos
Ação do ator Resposta do sistema
1. O Cliente comunica suas 2. Gera uma solicitação de pagamento com 
informações de Crédito para o cartão de crédito e a envia a um Serviço
pagamento com cartão de crédito de Autorização de Crédito (SAC) externo
3. O SAC autoriza o pagamento 4. Recebe uma resposta de aprovação
de crédito do SAC.
5. Lança o pagamento com cartão de crédito
e a informação da resposta de aprovação no
sistema de Contas a Receber (C/R). (O SAC
deve dinheiro à Loja, logo C/R deve fazer o
acompanhamento)
6. Exibe a mensagem de autorização bem 
sucedida
Seqüências Alternativas
Linha 3: Solicitação de crédito negada pelo SAC. Sugerir um método de pagamento diferente
(Passo 4. Escrever casos de uso essenciais expandidos.)Exemplo – Sistema TPV
�48
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 102
Seção: Pagar com Cheque
Seqüência Típica de Eventos
Ação do ator Resposta do sistema
1. O Cliente preenche um cheque
e se identifica.
2. O Caixa registra a informação de 3. Gera uma solicitação de pagamento
identificação e solicita autorização com cheque e a envia a um Serviço de
para pagamento com cheque Autorização de Cheques externo
4. O Serviço de autorização de 5. Recebe uma resposta de aprovação
Cheques autoriza o pagamento do Serviço de Autorização de Cheques.
6. Indica autorização bem-sucedida.
Seqüências Alternativas
Linha 4: Solicitação de cheque negada pelo Serviço de Autorização de Cheques. Sugerir um método de pagamento diferente
Exemplo – Sistema TPV(Passo 4. Escrever casos de uso essenciais expandidos.)
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 103
Planejar e Elaborar: Artefatos
Relatório de 
Investigação 
Preliminar 
Protótipos
Orçamento,
Cronograma
Especificação de 
Requisitos
Casos de Uso
a. Todos os de alto nível
b. Alguns essenciais 
expandidos
Diagramas de Casos de Uso
Esboço do modelo conceitual
Glossário
Depende de
�49
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 104
Planejar e Elaborar Construir Implantar
1. Definir
Plano Inicial
2. Criar Relatório de
Investigação Preliminar 3. Definir Requisitos
4. Registrar
Termos no Glossário
5. Implementar
Protótipo
6. Definir Casos de Uso
(Alto Nível e Essenciais)
7. Definir Modelo
Conceitual Inicial
8. Definir Arquitetura
Inicial do Sistema
9. Aperfeiçoar (Refinar)
Plano
Método Larman
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 105
Planejar e Elaborar Construir Implantar
1. Definir
Plano Inicial
2. Criar Relatório de
Investigação Preliminar 3. Definir Requisitos
4. Registrar
Termos no Glossário
5. Implementar
Protótipo
6. Definir Casos de Uso
(Alto Nível e Essenciais)
7. Definir Modelo
Conceitual Inicial
8. Definir Arquitetura
Inicial do Sistema
9. Aperfeiçoar (Refinar)
Plano
Método Larman
�50
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 106
Modelos Conceituais
� Modelo Conceitual é uma representação dos
conceitos, ou objetos, do mundo real pertencentes a
um domínio de interesse
� É exibido por um conjunto de diagramas de
estrutura estática, no qual não se definem
operações
� Pode ser tratado como um “dicionário visual” das
abstrações significativas do domínio
� ajuda a compreender vocabulário e informação do domínio
� Pode mostrar: conceitos, associações entre
conceitos e atributos de conceitos
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 107
Modelagem Conceitual
� Realiza-se a análise do domínio da aplicação
e a modelagem das entidades e fenômenos
desse domínio considerados importantes,
independentemente da implementação.
� A tarefa de modelagem conceitual envolve
dois mecanismos:
� Abstração e
� Representação.
�51
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 108
Modelagem Conceitual
Entidade
Observada
Entidade 
Representada
Avião
ABSTRAÇÃO REPRESENTAÇÃO
Operação mental
para observar um
domínio e capturar
sua estrutura
Expressão segundo
as convenções:
notação gráfica,
linguagem de
programação, etc.
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 112
Classificação/Instanciação
Estudante
de
Graduação
José Maria CL
A
SS
IF
IC
A
ÇÃ
O
IN
ST
A
N
C
IA
ÇÃ
OCATEGORIA
INDIVÍDUO
(Objeto)
�52
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 113
Modelo Conceitual: Conceito
� Informal: idéia, “coisa”, ou objeto do mundo real no domínio
de interesse.
� Algo digno de nota, de ser documentado, de importância para o
domínio.
� Formal: Um conceito pode ser considerado em termos de
seu:
� Símbolo: palavra ou imagem representando um conceito.
� Ex.: Venda
� Intenção: a definição de um conceito.
� Ex.: Uma venda representa uma transação de compra e possui
data e hora.
� Extensão: o conjunto de exemplos (instâncias) ao qual o
conceito se aplica.
� Ex.: Venda1, Venda2, Venda3 …
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 114
Modelo Conceitual: Conceito
� Símbolo
� Ex.: Aeronave
� Intenção
� Ex.: (o conceito) Aeronave representa uma aeronave, ou
seja, um meio de transporteaéreo que possui categoria,
dimensões, número de lugares, …
� Extensão
� Ex.: AirBus PT999, Boing747 PX111, …
�53
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 115
Conceitos no Sistema TPV
� Como identificar conceitos em um sistema ?
TPV Venda Loja
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 116
Estratégias para
Identificar Conceitos
� É melhor especificar em excesso um modelo conceitual com
muitos conceitos do que subespecificá-lo.
� Menos conceitos não implicam em um modelo melhor.
� Não exclua um conceito só porque sua necessidade não está
óbvia nos requisitos.
� Não exclua um conceito só porque não tem atributos – ele pode
possuir um papel de comportamento e não de informação.
� Usar uma Lista de Categorias de Conceitos.
� Identificar Substantivos.
�54
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 117
Conceito - Definição
� Informal: idéia, “coisa”, ou objeto do mundo real no domínio
de interesse
� algo digno de nota, de ser documentado, de importância para o
domínio
� Formal - Um conceito pode ser considerado em termos de
seu:
� Símbolo: palavra ou imagem representando um conceito. Ex:
Venda
� Intenção: a definição de um conceito. Ex: Uma venda
representa uma transação de compra e possui data e hora
� Extensão: o conjunto de exemplos (instâncias) ao qual o
conceito se aplica: Ex: Venda1, Venda2, Venda3 …
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 118
Exemplo 
� Símbolo - Ex: Aeronave
� Intenção - Ex: (o conceito) Aeronave representa uma
aeronave, ou seja, um meio de transporte aéreo que possui
categoria, dimensões, número de lugares, …
� Extensão - Ex: AirBus PT999, Boing747 PX111,…
�55
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 119
Conceitos no Sistema TPV
� Como identificar conceitos em um sistema ?
TPV Venda Loja
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 120
Exemplos de Categorias de 
Conceitos
� Objetos físicos ou tangíveis: TPV, Carro, Aeronave
� Especificações ou Descrições de “Coisas”:
EspecificaçãoProduto, ListaVerificação
� Lugares: Loja, Aeroporto
� Transações: Venda, Pagamento, Reserva
� Regras e Políticas: PolíticaReembolso
� Itens de linha de transação: ItemLinhaVendas
�56
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 121
Exemplos de Categorias de 
Conceitos (cont.)
� Papéis desempenhados por pessoas: Caixa
� Contêineres: Depósito, Armário, Aeronave
� Coisas em um contêiner: Item, Passageiro
� Catálogos: CatálogoProdutos, CatálogoPeças
� Organizações: DepartamentoVendas
� Sistema externo: SistmAutorizaçãoCartCrédito
� …
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 122
Identificação de Substantivos -
caso de uso Comprar Itens
1. Este caso de uso começa quando um Cliente chega a um
ponto de pagamento equipado com um TPV com vários
itens que deseja comprar.
2. O caixa registra o código universal do produto (UPC) de
cada item.
Se houver mais de um exemplar do item o caixa
também pode entrar a quantidade.
3. Determina o preço do item e acrescenta informação sobre o
item à transação de vendas em andamento.
A descrição e o preço do item corrente são apresentados
�57
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 123
Identificação de Substantivos
Lembre-se: 
1. Nem todos os substantivos são conceitos – linguagem 
natural pode ser ambígua
Ex: substantivos diferentes podem representar o mesmo conceito –
(Consumidor e Cliente)
2. Alguns dos substantivos são candidatos a conceitos e 
outros são candidatos a atributos
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 124
Conceitos candidatos
Domínio TPV – caso de uso Comprar Itens
• TPV
• Item
• Loja
• Venda
• CatálogoProdutos
• EspecificaçãoProduto
• ItemLinhaVenda
• Caixa
• Cliente
• Pagamento
• Gerente
⇒⇒⇒⇒ Ideal: Combinar as estratégias para identificar 
uma lista de candidatos a conceito
�58
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 125
Incluir no modelo objetos do 
tipo relatório?
� Um recibo é um relatório (uma saída do sistema) de uma
venda
� a informação contida num recibo é derivada de outras fontes, e
portanto essa informação é duplicada
� ⇒ razão para excluí-lo
� Um recibo desempenha um papel importante em termos das
regras do negócio
� confere ao portador o direito de retornar o item comprado ⇒
razão para incluí-lo
� Então… o Recibo deve ser incluído somente na fase onde o
retorno de itens for tratado – considerando o ciclo de
desenvolvimento iterativo
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 126
O Conceito de Especificação 
(ou de Descrição)
� O que aconteceria se todas as TVs de 19” (Item)
fossem vendidas ?
� Como fazer para saber o preço desse item de
venda ?
Item
descrição
preço
número série
CUP
ou
?????
EspecificaçãoProduto Item
número sériedescrição
preço
CUP
Descreve
1 *
MELHOR
�59
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 127
Quando utilizar conceitos de 
especificações
� Quando houver necessidade da existência de uma
descrição de um item ou serviço, independente da
existência de uma instância do item ou serviço
� se a exclusão de instâncias do item/serviço resultar em
perda de informação que deveria ser mantida
� Quando reduzir informação redundante ou
duplicada
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 128
Dicas...
� Objetos podem ser:
� Entidades Externas que produzem ou consomem informações
(outros sistemas, pessoas)
� Coisas que fazem parte do domínio (relatórios, displays, cartas)
� Eventos que ocorrem no contexto do sistema (transferência de
propriedade)
� Papéis desempenhados por pessoas (gerente, engenheiro,
vendedor)
� Unidades organizacionais (grupo, equipe)
� Lugares que estabelecem o contexto do problema (piso de
fábrica, área de descarga)
�60
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 129
Dicas...
� Isolar nomes (e locuções nominais), verbos (e locuções
verbais)
� Os nomes e os verbos que são sinônimos ou que não tem
nenhuma relação com o processo de modelagem são
omitidos
� Os nomes são classes ou atributos (itens de dados)
� Os verbos são operações (métodos) - relacionamento entre
classes
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 130
Exemplo para TPV
Venda
data
hora
Pagamento
quantiaPago-por
1 1
� Parte do Modelo Conceitual do TPV
� indica que os conceitos Venda e Pagamento são 
significativos para o domínio
� indica que Venda e Pagamento estão relacionados de uma 
forma digna de nota 
�61
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 131
Modelo Conceitual
� Modelo Conceitual NÃO mostra artefatos de
software
� objetos ou classes de software
� métodos ou responsabilidades
� janelas
� bases de dados
BDdeVendas
Venda
data
hora
imprimir ()
NÃO!!!
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 132
Cardinalidade ou 
Multiplicidade
� Cardinalidade define quantos objetos participam da
relação� É o número de instâncias de objetos da classe que
participam da relação
� Para cada associação e agregação, são definidas duas
multiplicidades: uma para cada participante do
relacionamento.
�62
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 133
Multiplicidade: Exemplo
C
C
C
C
C
*
1..*
1..40
5
3,5,8
zero ou mais - muitos (as)
um ou mais
um a quarenta
exatamente cinco
exatamente três, cinco ou 
oito
• A multiplicidade
define quantas 
instâncias de um 
conceito A podem 
ser associadas a 
cada instância do 
conceito B
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 134
Navegação
� Embora associações e agregações sejam bi-
direcionais por default, por ser desejável restringir a
navegação em uma direção
� Para isso, uma ponta (flecha) é adicionada à linha,
indicando a direção da navegação
�63
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 135
Exemplo do Sistema TPV
TPV Venda
Captura
1 1
associação
nome da associação direção de leitura 
(default: opcional)
OBS: o símbolo SOMENTE indica direção de 
leitura – não tem significado no modelo
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 136
Exemplo
TPV Venda
Captura
1 1
nome da associação
multiplicidade
direção de leitura 
(default: opcional)
associação
Loja Item1 *Estoca
�64
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 137
Associação - definição
� Associação é um relacionamento entre
conceitos
� indica uma conexão com significado e interesse
� Em UML são descritas como
“relacionamentos semânticos entre objetos
diferentes”
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 138
Critérios para incluir 
associações
� Quando o conhecimento associado necessita ser preservado por
algum tempo
� “necessário-ser-conhecida” – requisitos indicam essa necessidade
� Ex: associação entre Venda e Pagamento
� Evite associações cuja necessidade não é sugerida nos requisitos
� Ex: associação entre Venda e Gerente
� É mais importante identificar conceitos do que associações
� Excesso de associações pode tornar o modelo conceitual confuso
� Evite mostrar associações redundantes ou deriváveis
�65
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 139
Associações Comuns
� A é uma parte física de B
� Gaveta – TPV
� Asa - Aeronave
� A é uma parte lógica de B
� ItemLinhaVenda – Venda
� PernaVôo (Flight Leg) - RotaVôo
� A está fisicamente contida em/sobre B
� Item – Prateleira
� Passageiro - Aeronave
� A está logicamente contida em B
� DescriçãoItem - Catálogo
� Vôo – ProgramaçãoVôo
� A é registrada em B
� Venda - TPV
� Reserva - ManifestoVôo
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 140
Associações Comuns
� A é uma descrição para B
� DescriçãoItem – Item
� DescriçãoVôo – Vôo
� A é um item de linha de uma transação ou relatório B
� ItemLinhaVenda – Venda
� ServiçoManutenção - LogManutenção
� A é uma transação relacionada a outra transação B
� Pagamento – Venda
� Reserva – Cancelamento
� …
�66
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 141
Associações com Papéis
� Cada extremo de uma associação é chamado de
papel.
� Os papéis podem ter, opcionalmente, as seguintes
propriedades:
� Nome
� Expressão de multiplicidade
� Navegabilidade
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 142
Associações com Papéis
� Nomes de papéis são necessários,
principalmente, para associação entre dois
objetos de mesma classe.
Companhia Empregado
1
0 .. *
subordinado1 1 .. *
�67
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 143
Associações Múltiplas
entre Conceitos
Vôo Aeroporto
Voa-para
Voa-de
* 1
* 1
Origem
Destino
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 144
Associações e Implementação
� Uma associação indica um relacionamento significativo apenas
sob a perspectiva conceitual.
� Uma associação não implica em um fluxo de dados ou conexão
entre objetos em uma solução de software.
� Algumas associações do modelo conceitual podem não ser
necessárias na implementação.
� Durante a implementação podem ser descobertas associações
entre objetos de software que foram esquecidas durante a
modelagem conceitual.
�68
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 145
Exemplo
Companhia
Aérea
Pessoa
1..*
1
Emprega
1
Vôo
*
Designada-para Aeronave
1*
Designada-para
Supervisiona
1 *
OBS: considere vôos não 
simultâneos na alocação de 
pessoas e aeronaves. Essa 
alocação seria feita, por 
exemplo, o planejamento de 
vôos do dia/semana/mês…
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 146
Exemplo
Pagamento
1..1
1..1
1..1
Gerente
0..*
1..*
1..1
*
1..1
1..1
1..1
1..1
Cliente
1..1
1..1
*
1..1
TPV 1..10..*
Iniciado por
1..1
*1..1
Loja
1..*
1..1
Possui
1..*1..1
Catálogo de Produtos
*
1..1
Usado-por
1..1
1..*
1..1
Item
*1..1
Estoca
0..1
1..1
Especificação de Produto1..*1..1
Contém
*
Descreve
*
ItemLinhaVenda
1..1
0..1
Registra-venda-de
1..1
*
Descritos-por
Venda
1..1
1..1
Paga-por
1..1
1..1
Iniciada-por
1..1
*
Registra-dados-da
v
1..1
1..1
capturada-em
1..1
1..*
Contido-em
Caixa
1..1
1..1
< Registra-Vendas-do
1..1
1..1
Iniciada-por
1..1
1..1
1..1
�69
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 147
Modelo Conceitual
Planejar e Elaborar Construir Implantar
1. Definir
Plano Inicial
2. Criar Relatório de
Investigação Preliminar 3. Definir Requisitos
4. Registrar
Termos no Glossário
5. Implementar
Protótipo
6. Definir Casos de Uso
(Alto Nível e Essenciais)
7. Definir Modelo
Conceitual Inicial
8. Definir Arquitetura
Inicial do Sistema
9. Aperfeiçoar (Refinar)
Plano
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 148
Desenvolvimento Iterativo
Planejar e
elaborar Construir Instalar
Ciclo de 
Desenvolvimento 1
Ciclo de 
Desenvolvimento 2 …
Refinar
Plano
Sincronizar
Artefatos
Analisar Projetar Construir Testar
�70
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 149
Refinar
Plano
Sincronizar
artefatos Analisar Projetar Construir Testar
1. Definir Casos
de Uso Essenciais
2. Refinar Diagramas 
de Casos de Uso
3. Refinar o Modelo 
Conceitual 
4. Refinar Glossário 5. Definir Diagramas deSeqüência do Sistema
6. Definir Contratos
de Operação
7. Definir Diagramas
de Estado
Método Larman
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 150
Modelo Conceitual: Atributo
� Um atributo é um valor de dados lógico de um objeto.
Descreve uma característica do objeto.
� Inclua no modelo conceitual apenas os atributos para os
quais os requisitos sugerem ou implicam uma necessidade
de memorizar a informação.
� Ex: preço de item, valor da compra, …
� Preferivelmente, no modelo conceitual,os tipos de atributos
devem ser simples, como:
� tipos de dados primitivos - booleano, inteiro, real, cadeia de
caracteres,...
� data, hora, cor, endereço, geometria, número de telefone, CEP,
…
�71
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 151
Modelo Conceitual: Atributo
� Os atributos são descritos na segunda seção
da caixa de conceito.
� O tipo do atributo é opcional.
Pessoa
nome: String
idade: Inteiro
Venda
data: Data
hora: Hora
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 152
1..1
1..1
Caixa
1..1
Gerente
1..*
1..*
*
1..1
1..1
Pagamento
quantia
1..1
1..1
Cliente
1..1
1..1
TPV
1..1
Registra-Vendas-do
Iniciado por
*1..1
Loja
endereço
nome
1..1
Possui
1..*1..1
CatálogoProdutos
*
1..1
Usado-por
*
1..1
Venda
data
hora
1..1
1..1
Paga-por
1..1
1..1
Iniciada-por
1..1
*
Registra-Dados-da
1..1
1..1
Capturada-em
1..*
Item
*
Estoca
0..1
1..1
EspecificaçãoProduto
descrição
preço
UPC
1..*1..1
Contém
*
Descreve
*
ItemLinhaVenda
quantidade
1..1
1..*
Contido-em
1..*
0..1
Registra-venda-de
1..1
*
Descritos-por
1..1
Exemplo
�72
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 153
Generalização
� No sistema TPV – caso de uso ComprarItens :
� Os conceitos de PagamentoComDinheiro,
PagamentoComCartãoCrédito e PagamentoComCheque
são muitos semelhantes.
� Podem ser organizados em uma hierarquia de tipos (ou
conceitos).
� Hierarquia “generalização/especialização”.
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 154
Generalização
� Identifica o que há em comum entre conceitos.
� Permite:
� Construir classificações taxonômicas – hierarquias de tipos.
� Compreender os conceitos em termos mais gerais e abstratos, ou mais
refinados.
� Conduz a uma notação mais econômica
� Evita repetição de informação.
� Na implementação, pode ser feita com classes e herança.
�73
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 155
Generalização: Notação UML
ConceitoA
ConceitoA1 ConceitoA2 ConceitoA3
ConceitoA
ConceitoA1 ConceitoA2 ConceitoA3
supertipo –
conceito geral
subtipo -
conceito especializado
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 156
Generalização e Tipo
� A definição de um supertipo é mais geral e mais abrangente que a
definição de um subtipo.
� Pagamento: uma transação de transferência de dinheiro (não
necessariamente em espécie) de um comprador para um vendedor.
� PagamentoComCartãoCrédito: transferência de dinheiro, via uma
instituição de crédito, que necessita ser autorizada.
� Propriedade pertinência ao conjunto: todos os membros de um subtipo
são membros do supertipo.
� ex: PagamentosComCartãoCrédito estão dentro do conjunto
Pagamento.
�74
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 157
Regra É-Um
Todos os membros de um conjunto 
subtipo devem ser membros de seu
conjunto supertipo.
O Subtipo é um Supertipo.
Generalização/Especialização
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 158
Pagamento
PagamentoComDinheiro
PagamentoComCartãoCrédito
PagamentoCheque
supertipo –
conceito geral
subtipo -
conceito especializado
Pagamento
Pagamento Com
Dinheiro
Pagamento Com
Cheque
Pagamento Com
Cartão Crédito
Exemplo
�75
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 159
PagamentoComDinheiro PagamentoComCartãoCrédito PagamentoComCheque
Pagamento
valor: Quantia
VendaPago-a
Regra dos 100%
100% da definição do supertipo dever ser aplicada ao subtipo.
O subtipo deve estar em conformidade com 100% dos seguintes elementos 
do supertipo:
• Atributos
• Associação
Generalização/Especialização
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 160
Quando definir um subtipo ?
� Criar subtipos significa particionar um tipo.
� Dividir um tipo em subtipos disjuntos.
� Quando mostrar a partição de um tipo?
� Depende da relevância da partição para o domínio do problema.
� Ex: No sistema TPV seria útil definir a seguinte hierarquia??
Cliente
ClienteFeminino ClienteMasculino
�76
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 161
Dicas de quando particionar...
1. Um subtipo tem atributos adicionais de interesse.
2. O subtipo tem associações adicionais de interesse.
3. O conceito do subtipo é tratado, operado ou manipulado de
maneira diferente que o supertipo ou outros subtipos,
segundo formas que são de interesse considerar.
4. O conceito do subtipo representa uma coisa ou ser animado
que se comporta de maneira diferente do supertipo ou de
outros subtipos, segundo formas que são de interesse
considerar.
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 162
Exemplo
Estudante
Disciplina
Docente
Pessoa
nome
CPF
nro. UNESP
código
MinistraCursa
*
*
0..3
1..2
titulação
Departamento
nome
Está-vinculada-a
1*
atributos em 
comum
subtipos com 
atributos e 
associações 
adicionais, e 
comportament
o e distintos
�77
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 163
Exemplo – Sistema TPV
PagamentoComDinheiro
Pagamento
valor : Quantia VendaPago-a
PagamentoComCartãoCrédito
CartãodeCrédito
PagamentoComCheque
Cheque
Identifica_crédito_com
1
*
Pago_com
1
1
11
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 164
O que fazer???
Empresa
nome
Pessoa
nome* *
emprega
� Se uma pessoa pode ter mais de um emprego em empresas 
diferentes, onde colocar a informação de salário????
Empresa
nome
Pessoa
nome* *
emprega
Salário
valor
recebepaga * *
**
� Uma opção: 
�78
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 165
Um opção MELHOR: 
Tipos Associativos
� Classe associativa: seus atributos estão relacionados a uma
associação e não a um dos conceitos envolvidos na associação.
� Seu tempo de vida depende do tempo de vida da associação.
Empresa
nome
Pessoa
nome* *
emprega
Emprego
salário: Quantia TIPO ASSOCIATIVO
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 166
Tipos Associativos
� Indícios da existência de tipos associativos:
� Um atributo está relacionado a uma associação.
� As instâncias do tipo associativo têm tempo de vida
dependente do tempo de vida da associação.
� Existe uma associação muitos-para-muitos entre dois
conceitos, bem como informações relacionadas à
associação propriamente dita.
�79
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 167
Agregação
� É um tipo de associação usado para modelar relacionamentos
todo-parte entre coisas.
� O todo é geralmente chamado composto, as partes podem ser
chamadas componentes.
� Notação em UML: losango vazio ou preenchido.
Mão Dedo
0..51
COMPOSTO
COMPONENT
E
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 168
Agregação Composta
(Losango Preenchido)
� Agregação composta ou composição significaque:
� A multiplicidade na extremidade do composto pode ser no
máximo 1.
� Uma instância do componente pode ser parte de apenas
uma instância do composto (simultaneamente).
� Existe uma dependência de existência entre o
componente e o composto.
� A existência de uma instância do composto implica na
existência de instâncias dos componentes.
� A destruição de uma instância do composto implica na
destruição das instâncias dos componentes agregados.
�80
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 169
Exemplos
Mão Dedo0..51
� Um dedo só pode fazer parte de uma mão. 
Venda 1..*1
� Um item de linha de venda só pode fazer parte de uma venda.
ItemLinhaVenda
1..*1
� Uma especificação de produto só pode ser parte de um catálogo.
CatálogoProduto EspecificaçãoProduto
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 170
Agregação Compartilhada
(Losango Vazio)
� Agregação compartilhada significa que:
� A multiplicidade na extremidade do composto pode ser
maior que 1.
� Uma instância do componente pode estar
simultaneamente em muitas instâncias do composto.
� Esse tipo de agregação é raro em agregados
físicos, mas aparece em conceitos não-físicos.
� Exemplo:
Software
OO Classe**
�81
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 171
Modelo Conceitual:
Diretrizes para Construção
� Liste os conceitos candidatos relacionados aos requisitos
considerados.
� Use a Lista de Categorias de Conceitos e a Identificação de
Substantivos.
� Desenhe os conceitos em um modelo conceitual.
� Registre as associações entre conceitos.
� Acrescente os atributos necessários para completar os
requisitos.
� Identifique possíveis agregações, generalizações e tipos
associativos.
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 172
Refinar
Plano
Sincronizar
artefatos Analisar Projetar Construir Testar
1. Definir Casos
de Uso Essenciais
2. Refinar Diagramas 
de Casos de Uso
3. Refinar o Modelo 
Conceitual 
4. Refinar Glossário 5. Definir Diagramas deSeqüência do Sistema
6. Definir Contratos
de Operação
7. Definir Diagramas
de Estado
Método Larman
�82
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 173
Refinar
Plano
Sincronizar
artefatos Analisar Projetar Construir Testar
1. Definir Casos
de Uso Essenciais
2. Refinar Diagramas 
de Casos de Uso
3. Refinar o Modelo 
Conceitual 
4. Refinar Glossário 5. Definir Diagramas deSeqüência do Sistema
6. Definir Contratos
de Operação
7. Definir Diagramas
de Estado
Método Larman
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 174
Diagramas de Seqüência
do Sistema (DSS)
� Para dar prosseguimento à fase de análise, é
desejável ter uma noção mais concreta do
comportamento esperado do sistema diante dos
eventos que fazem parte de cada caso de uso
� Idéia: investigar e definir o comportamento do sistema
como uma “caixa preta”.
� O comportamento é dependente dos casos de uso.
� Interação de atores com o sistema gera eventos que
solicitam operações em resposta.
�83
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 175
Diagramas de Seqüência
do Sistema (DSS)
� Os diagramas de seqüência do sistema são
utilizados para especificar parte de seu
comportamento.
� Mostram um cenário global do funcionamento do
sistema, dividindo o caso de uso em partes bem
definidas, denominadas operações, que são
executadas em resposta aos eventos.
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 176
Diagramas de Seqüência
do Sistema (DSS)
� Um DSS ilustra os eventos de entrada e saída do sistema.
Para uma seqüência específica de eventos (cenário) de um
caso de uso, o DSS mostra:
� Os atores que interagem com o sistema.
� O sistema, como uma “caixa-preta”.
� Eventos do sistema gerados pelos atores.
� Eventos entre sistemas.
� A ordem dos eventos.
� Deve ser feito para uma seqüência típica do caso de uso.
� Possivelmente outros DSS podem ser criados para as
seqüências alternativas mais interessantes.
�84
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 177
Eventos e Operações do 
Sistema
� Um evento de sistema é um evento externo de entrada para o
sistema, gerado por um ator.
� Eventos de sistema podem incluir parâmetros.
� Cada evento inicia uma operação de resposta do sistema.
� Uma operação de sistema é uma operação executada em
resposta a um evento de sistema.
� Um mesmo nome é atribuído a um evento e à operação
correspondente (assim como mensagens e métodos).
� Eventos e operações também podem ser de saída.
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 178
Relembrando...
Caso de Uso Expandido: Comprar Itens
(restrito a pagamento em dinheiro e sem tratar controle de estoque)
Caso de Uso: Comprar Itens com Dinheiro
Atores: Cliente (iniciador), Caixa
Finalidade: Capturar a venda e seu pagamento em dinheiro
Visão geral: Um Cliente chega ao balcão de saída da loja com itens que 
deseja comprar. O Caixa registra os itens de compra e 
recebe o pagamento. Quando termina, o Cliente sai com os 
itens comprados.
Tipo: primário e essencial (a ser discutido adiante…)
Referências Requisitos: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1
Cruzadas:
�85
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 179
Caso de Uso Expandido
Ação do ator Resposta do Sistema
1. Este caso de uso começa quando o Cliente
chega ao TPV com itens para comprar
2. O Caixa registra o identificador de cada
item
3. Determina o preço do item e adiciona
informação sobre o item à transação de venda
corrente
Se há mais de um do mesmo item, o caixa
também entra a quantidade
A descrição e o preço do item são
apresentados
4. Quando termina a entrada dos itens, o
Caixa indica ao TPV que as entradas estão
completas
5. Calcula e apresenta o total da venda
6. O Caixa informa o total ao cliente
7. O Cliente entrega o pagamento em dinheiro
– o “pagamento em dinheiro” – possivelmente
maior que o total da venda
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 180
Ação do ator Resposta do Sistema
8. O Caixa registra a quantidade de
dinheiro recebida
9. Exibe o valor do troco a ser devolvido
ao cliente
10. O Caixa deposita o dinheiro recebido
e retira o troco devido
11. Registra a venda completada (logs)
O Caixa entrega ao cliente o troco e o
recibo impresso
12. O Cliente sai com os itens comprados
Caso de Uso Expandido
Que ator(es) realmente interage(m) com o sistema??
�86
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 181
:Sistema
:Caixa
Comprar Itens
terminarVenda()
fazerPagamento(quantia)
troco, recibo
entrarItem(CUP, quantidade)
descrição item, total
iniciarNovaVenda( )
*[mais itens]
Linha do 
tempo
Operação
Ator
Repetição 
de uma 
operação
“:” indica 
instância
“*[..]” indica iteração e 
a caixa refere-se à 
iteração
Exemplo – Sistema TPV
DSS para o Caso de Uso Comprar Itens
BCC
2014
25/03/2014 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 182
:Sistema
:Caixa
Comprar Itens
terminarVenda()
fazerPagamento(quantia)
troco, recibo
entrarItem(CUP, quantidade)
descrição item, total
iniciarNovaVenda( )
*[mais