Aula 6 - (2012)

Prévia do material em texto

16/03/2012
1
2
16/03/2012
2
3
Estrutural
(dados)
Comportamental
(estados e eventos)
Arquitetural (operações)
[FOWLER96]
Visões para
um problema
(aspectos fundamentais
do software)
4
16/03/2012
3
5
� Projeto Estruturado (de Tom DeMarco):
◦ primeira metodologia a ser amplamente aceita 
pela comunidade de Engenharia de Software
◦ surgiu como evolução natural do sucesso das 
linguagens de programação estruturadas
◦ surgiu a partir da necessidade de notações 
específicas para representar a arquitetura de um 
sistema estruturado
� Cenário anterior: somente fluxogramas
6
� Análise Estruturada
◦ Douglas T. Ross (1978) e Tom DeMarco (1979)
� Criaram a notação básica para facilitar a especificação e 
permitir o diálogo com usuário
◦ Nos anos seguintes, variações surgiram por 
diferentes autores
� Gane e Sarson (1982) e Page-Jones (19980)
◦ Na metade da década de 1980, surgiram 
extensões para tempo real 
16/03/2012
4
7
� Privilegia a observação dos aspectos 
funcionais para a modelagem do software
� Durante muito tempo (auge da Programação 
Estruturada)
◦ Foram as mais conhecidas, utilizadas e criticadas
8
16/03/2012
5
9
Dicionário
de Dados
DiagramaDiagramaDiagramaDiagrama
EntidadeEntidadeEntidadeEntidade----
RelacionamentoRelacionamentoRelacionamentoRelacionamento
Diagrama deDiagrama deDiagrama deDiagrama de
Fluxo deFluxo deFluxo deFluxo de
DadosDadosDadosDados
Diagrama deDiagrama deDiagrama deDiagrama de
Transição deTransição deTransição deTransição de
EstadosEstadosEstadosEstados
Especificação de controleEspecificação de controleEspecificação de controleEspecificação de controle
10
� De maneira simplificada, o processo de 
Análise Estruturada pode ser descrito como 
sendo a aplicação dos modelos abaixo:
◦ Entidade Relacionamento
� Mostra as relações entre os dados
◦ Fluxo de Dados
� Fornece a indicação de como os dados são transformados 
à medida que se movem pelo sistema
� Mostra as funções (e sua decomposição)
◦ Transição de Estados
� Indica como o sistema se comporta em conseqüência de 
eventos externos
16/03/2012
6
11
12
� A definição do escopo pode ser obtida a partir de
◦ Um documento de trabalho que define o sistema
� A definição do escopo deve ser “processada” para 
extrair os: 
◦ domínios de dados
◦ funções 
◦ comportamento esperados
16/03/2012
7
13
� Uma descrição simples do sistema a ser 
construído
◦ Indica quais os dados de entrada e saída e a 
funcionalidade básica esperada
◦ Indica o processamento condicional (em um alto 
nível de abstração)
◦ Indica restrições e limitações do sistema
14
� Análise Gramatical
◦ Definir “objetos” destacando todos os substantivos na 
definição escrita para o escopo do sistema
� Produtores e consumidores de dados
� Locais onde os dados são armazenados
� Itens de dados compostos
◦ Definir “operações” sublinhando todos os verbos ativos
� Processos relevantes para a aplicação
� Transformações de dados
◦ Considere outros “serviços” que podem ser requeridos 
pelos objetos e não estão apresentados explicitamente na 
definição
16/03/2012
8
15
16
� Examina os objetos de dados de maneira 
independente do seu processamento
� Atenção especial ao domínio dos dados
� Indica qual a relação entre objetos de dados
16/03/2012
9
17
18
� Todo sistema baseado em computador é a 
transformação automatizada de informação
SistemaSistema
Baseado emBaseado em
ComputadorComputadorinputinput outputoutput
16/03/2012
10
19
� Yourdon
Entidade Externa
Processo
Fluxo de Dados
Depósito de Dados
20
� Gane-Sarson
Processo
Entidade externa
Fluxo de dados
Depósito de
dados
16/03/2012
11
21
� Produtor ou consumidor de dados
◦ Exemplos: pessoa, sensor
◦ Outro exemplo: sistema de computação existente
� Princípio: Dados surgem em algum lugar e 
devem ser enviados para algum 
processamento
22
� Transformador de dados (de entrada em 
saída)
� Exemplos: 
◦ cálculo de imposto, determinar a área de figura, 
formatar um relatório, exibir um gráfico
� Princípio: Os dados sempre devem ser 
processados de alguma maneira para atender 
uma função do sistema
16/03/2012
12
23
� Os dados fluem pelo sistema, desde a 
entrada até a saída
� Todos os fluxos devem ser descritos, isto é, 
rotulados com a informação transmitida
24
� Dados são armazenados para uso posterior 
(em outro processo)
16/03/2012
13
25
� Todos os ícones devem ser rotulados com significado 
claro
� O DFD deve ser fornecido em múltiplos níveis de 
detalhe
◦ Deve-se começar com o Diagrama de Contexto (nível 0) que 
apresenta o sistema sendo desenvolvido como um único 
processo
◦ Todas as entidades externas devem estar presentes no nível 
zero
◦ O processo deve ser refinado (“explodido”) em novos 
processos que, por sua vez, podem ser refinados novamente
� Sempre inclua rótulos nas setas que indicam fluxo de 
dados
26
� Revise DER para identificar objetos de dados 
que irão atuar como produtores ou 
consumidores de dados
� Identifique a principal “operação” do sistema 
através da Análise Gramatical
� Crie um DFD de nível 0
16/03/2012
14
27
� Escreva uma narrativa que descreva a 
transformação realizada por um processo
� Faça a análise gramatical novamente para 
identificar as sub-funções do sistema
� Faça o “balanceamento” do fluxo de dados para 
garantir 
◦ todas as entradas e saídas presentes no nível superior 
estejam presentes no nível inferior
� Construa um processo de nível 1
� Use aproximadamente a razão 1:5 para a explosão 
de processos
28
mapeamentomapeamento
Modelo de análiseModelo de análise
Modelo de projetoModelo de projeto
16/03/2012
15
29
Processar
pedidos
LIVROS
CLIENTES
Situação
de crédito
CLIENTECLIENTE
Pedidos
Faturas
Distribuidora de livros
(DFD Nível 0)
Livros
Dados dos
livros
30
Verificar
validade do
pedido
CLIENTECLIENTE
PEDIDOS PENDENTES
LIVROS EDITORAS
CLIENTES
Situação
de crédito
Pedidos
Preparar
pedido para
editora
EDITORAEDITORA
Endereço
Pedidos agrupados
Pedidos
válidos
Ordens
de
compra
dados dos
livros
Entregar
livroslivros
fatura
livros
pedidos
Pedidos agrupados
16/03/2012
16
31
32
Mundo
externo
Aplicação
eventos comportamento
16/03/2012
17
33
� Definições
◦ EstadoEstadoEstadoEstado - conjunto de circunstâncias observáveis que
caracterizam o comportamento do sistema em um 
momento específico
◦ Transição Transição Transição Transição de Estadosde Estadosde Estadosde Estados - a movimentação de um estado 
para outro
◦ EventoEventoEventoEvento - ocorrência que faz com que o sistema 
apresente algum comportamento previsível
◦ AçãoAçãoAçãoAção - processo que ocorre como conseqüência do 
disparo de uma transição
34
� Faça uma lista dos diferentes estados de um 
sistema
◦ Responder a pergunta: como o sistema deve se comportar?
� Indique como o sistema realiza uma transição de 
um estado para outro
◦ Pergunta: como ocorre mudanças de estado no sistema?
◦ Indique o evento
◦ Indique a ação (opcional)
� Desenhe um diagrama de transição de estados
16/03/2012
18
35
Estado
Novo
Estado
Evento que causa transição
Ação que ocorre
36
16/03/2012
19
37
� Gramática “quase-formal” para descrição 
dos itens de dados
� É um repositório que também pode conter 
informações sobre “quem-usa” e “como-
usa”
� Pode ser representada manualmente, mas é 
melhor se apoiada por ferramenta CASE
38
Name: 
Aliases: 
Where used: 
How used: 
Description:Format:
the primary name of the data item 
other names for the data item 
data transforms that use the data item 
the role of the data item (input, output, 
temporary storage, etc). 
a notation for representing content (presented 
on next slide) 
specific information about data types, pre-set 
values (if known) 
16/03/2012
20
39
Notation
= 
+ 
[ ] 
{ } 
( ... ) 
* ... text ...* 
n
Meaning
is composed of 
and 
or 
n repetitions of 
optional data 
delimits a comment
40
telephone number
integrated 
office 
phone 
system
Name: 
 
Aliases: 
 
Where/How 
used: 
 
 
Description: 
 
 
 
 
Format:
telephone number 
 
phone number, number 
 
read-phone-number (input) 
display-phone-number (output) 
analyze-long-distance-calls (input) 
 
telephone no. = [ local extension | outside no. | 0 ] 
outside no. = 9 + [ service code | domestic no. ] 
service code = [ 211 | 411 | 611 | 911 ] 
domestic no. = ( ( 0 ) + area code ) + local number 
area code = *three numeral designator*
Build the requirements dictionary:
alphanumeric data
system output
16/03/2012
21
41
� Desenvolvimento de Sistemas Estruturados 
pelos Dados (Warnier/Orr)
� Jackson System Development (Michael 
Jackson)
� Structured Analysis and Design Technique 
(Douglas Ross)
42
[http://www.cs.toronto.edu/~jm/2507S/Notes04/SADT.pdf]
16/03/2012
22
43
� Diversas metodologias e métodos surgiram 
para apoiar OO
◦ Evolução a partir de linguagens C++ e SmallTalk
◦ Anos 80-90: diversidade de autores
◦ Anos 98-2000: unificação em torno de UML
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 44
16/03/2012
23
� Exemplos de Notações
◦ Classes
45
Booch
Schlaer-Mellor
OMTCoad-Yourdon
� A diversidade de notações para representar 
sistemas orientados a objetos nas décadas de 
1980 e 1990 criou o caos para
◦ Desenvolvedores e Empresas de Software
◦ Fabricantes de Ferramentas
◦ Treinamentos
� Cenário ideal para unificação em torno de 
uma única notação
46
16/03/2012
24
� Grady Booch
◦ Um dos pioneiros da OO
◦ 1980: ênfase em técnicas de projeto para Ada
◦ 1992-1994: livros
� Object-Oriented Design with Applications
� projeto de programas em C++ e Ada
47
� 1994: Object-Oriented
Analysis and Design with
Applications
� texto sobre conceitos de OO e 
modelagem de objetos
� projeto de várias aplicações-
exemplo com diferentes 
linguagens da época
� base de UML para o Design
◦ 1998: Fundação da 
Rational
48
16/03/2012
25
� Ivar Jacobson
◦ Modelagem OO baseado em 
Casos de Uso
◦ Objectory
� Processo centrado em casos 
de uso que fornece a base 
teórica usada atualmente no 
Unified Process
49
� James Rumbaugh
◦ Object Modeling Technique (OMT)
◦ Desenvolvida na GE
◦ Metodologia baseada em notações
pré-existentes (ER, DTE, DFD)
◦ Clara distinção entre as três visões do problema
◦ Base da UML para Análise
50
16/03/2012
26
� James Rumbaugh (cont.)
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 51
© Carla A. Lima Reis e Rodrigo Quites Reis 
(LABES-UFPA) / 2009 52
Booch
Rumbaugh
OMT
Jacobson
OOSE
U
M
L
16/03/2012
27
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 53
Metodologia Booch OMT
Unified Method 0.8OOPSLA ´95 Unified Method 0.8OOPSLA ´95
OOSEOutras metodologias
UML 0.9Web - June ´96
OOSEOutras metodologias
UML 0.9Web - June ´96 UML 0.9Web - June ´96 UML 0.9Web - June ´96
Período de
Feedback
público
Período de
Feedback
público
Submissão final ao OMG, Set ‘97
1a submissão ao OMG, Jan ´97
UML 1.1
Aceitação como padrão OMG, Nov 1997
Submissão final ao OMG, Set ‘97
1a submissão ao OMG, Jan ´97
UML 1.1
Aceitação como padrão OMG, Nov 1997
UML 1.4UML 1.4UML 1.4
UML 1.0Parceiros UML UML 1.0UML 1.0Parceiros UML
UML 2.1
OMG: Object Management Group
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 54
Meyer
Before and after 
conditions
Meyer
Before and after 
conditions
Meyer
Before and after 
conditions
Harel
Statecharts
Harel
Statecharts
Harel
Statecharts
Gamma, et al
Frameworks and patterns,
Gamma, et al
Frameworks and patterns,
Gamma, et al
Frameworks and patterns,
HP Fusion
Operation descriptions and 
message numbering
HP Fusion
Operation descriptions and 
message numbering
HP Fusion
Operation descriptions and 
message numbering
Embley
Singleton classes and
high-level view
Embley
Singleton classes and
high-level view
Embley
Singleton classes and
high-level view
Wirfs-Brock
Responsibilities
Wirfs-Brock
Responsibilities
Wirfs-Brock
Responsibilities
Odell
Classification
Odell
Classification
Odell
Classification
Shlaer - Mellor
Object lifecycles
Shlaer - Mellor
Object lifecycles
Shlaer - Mellor
Object lifecycles
Rumbaugh
OMT
Rumbaugh
OMT
Booch
Booch method
Booch
Booch method
Jacobson
OOSE
Jacobson
OOSE
16/03/2012
28
� O que é UML
◦ Linguagem visual para especificação (modelagem) 
de sistemas orientados a objetos
� Fornece representação gráfica para os elementos 
essenciais do paradigma de objetos
� Classes, atributos, objetos, troca de mensagens, ...
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 55
Pessoa Comitê
Membro-de
Presidente-de
{subconjunto}
0..*
0..*
0..*
Telefone Celular
Usuário
Uso
programado
� O que é UML
◦ De propósito geral
� Não está presa a uma etapa do desenvolvimento de 
software
� Análise
� Projeto
� Implementação
� Testes
� Não está presa a um processo
� Ciclo de vida em cascata
� Incremental
� Processo Unificado
� ...
� Não está presa a uma linguagem de programação
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 56
16/03/2012
29
� UML apóia o desenvolvimento incremental
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 57
Usuário Serviço
habilita
data
**
Serviço
habilita
data
**
Serviço
Nome
Preço
Usuário
Nome
CPF
Serviço
habilita
data
**
Serviço
Nome
Preço
Usuário
Nome
CPF
suspende(período)
Modelos podem evoluir com a inclusão
de novos detalhes
Analogia: aula com transparências
sobrepostas
� O que é UML
◦ De propósito geral
� Não está presa a uma linguagem de programação
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 58
Serviço
habilita
data
**
Serviço
Nome
Preço
Usuário
Nome
CPF
suspende(período)
public class Usuario {
private String nome;
private String cpf;
private Vector lnkServico;
}
ProgramadorProgramadorProgramadorProgramador
JavaJavaJavaJava
Possível
implementação
16/03/2012
30
� O que é UML
◦ Padrão OMG
� Em http://www.omg.org estão disponíveis documentos 
eletrônicos que contém
� Sumário da UML
� Semântica
� Guia da Notação
� Extensões da Linguagem
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 59
� O que é UML
◦ Privilegia a descrição de um sistema segundo três 
perspectivas:
� Dados (estrutural)Dados (estrutural)Dados (estrutural)Dados (estrutural)
� Diagrama de Classes
� Operações (funcional)Operações (funcional)Operações (funcional)Operações (funcional)
� Diagrama de Caso de Uso
� Eventos (temporal/dinâmica)Eventos (temporal/dinâmica)Eventos (temporal/dinâmica)Eventos (temporal/dinâmica)
� Diagramas de Seqüência, Atividades, de Transição de 
Estados
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 60
16/03/2012
31
� O Processo de Análise
© Carla A. Lima Reise Rodrigo 
Quites Reis (LABES-UFPA) / 2009 61
Funções
DadosProblema Análise
Eventos
Sistema
(conceitual)
(entrevistas,
leituras especializadas,
brainstorming, etc.)
� O Processo de Projeto
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 62
Funções
Dados Projeto
Eventos
Sistema
(conceitual)
(resultado da análise)
•Mapeamento
•Requisitos Arquiteturais
•Requisitos da plataforma
•Aspectos de deploy
Funções
Dados
Eventos
Outros Aspectos
16/03/2012
32
� Grande variedade de ferramentas com 
diferentes recursos
◦ IBM/Rational
� Rational Rose
� Rational Software Architect / Software Modeler
◦ Gentleware Poseidon
◦ Visual Paradigm
◦ Enterprise Architect
◦ Jude Professional
◦ Software Livre
� Argo UML (Java) - http://argouml.tigris.org
� Fujaba (Java) - http://www.fujaba.de
� JUDE Community - http://jude.change-vision.com
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 63
� Alguns critérios para avaliação
◦ Aspectos comerciais: preço, disponibilidade
◦ Suporte técnico
◦ Performance
◦ Usabilidade
◦ Exigências de Hardware
◦ Suíte (cobre todo o processo) ou Isolada
◦ Plataforma de Execução
◦ Integração com ferramentas de desenvolvimento existentes 
(IDEs, Gerência de Requisitos, etc)
◦ Geração de Código e Esquema de BD (e importação) �
conhecido em inglês como round-trip engineering
◦ ...
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 64
16/03/2012
33
� Observações:
◦ Algumas ferramentas assumem “liberalidades 
artísticas” para representar os diagramas de 
maneira diferente do previsto na linguagem
◦ XMI é o padrão cada vez mais adotado usado para 
intercâmbio de modelos feitos por diferentes 
ferramentas
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 65
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 66
16/03/2012
34
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 67
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 68
16/03/2012
35
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 69
Imifarma S.A. - Programação 
Orientada a Objetos 70
16/03/2012
36
Imifarma S.A. - Programação 
Orientada a Objetos 71
� Ferramenta escolhida para o Curso
� Principais diagramas UML 2.0
◦ Casos de Uso; Classes; Estados; Atividades; 
Sequência; Pacotes; Componentes; e Implantação.
� Exporta HTML
� Geração de Código Java
Imifarma S.A. - Programação 
Orientada a Objetos 72
16/03/2012
37
Imifarma S.A. - Programação 
Orientada a Objetos 73
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 74
16/03/2012
38
� Fáceis de entender (escritos na linguagem 
do problema)
� Ajudam a unificar critérios
� Estimulam o pensamento
� Ajudam no treinamento
� Ajudam no rastreamento
© Carla A. Lima Reis e Rodrigo Quites Reis 
(LABES-UFPA) / 2009 75
Fonte: Karin Breitman, EIN 2004
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 76
16/03/2012
39
� Resumo
◦ Um caso de uso é uma forma específica de uso 
do sistema 
� Composto por uma seqüência de ações que produz um 
resultado de valor resultado de valor resultado de valor resultado de valor para algum agente externo.
◦ Mostram apenas o que o sistema fazo que o sistema fazo que o sistema fazo que o sistema faz, não como.
◦ Capturam o comportamento pretendido para um 
sistema, sem a necessidade de especificar como 
esse comportamento será implementado.
77
� Um caso de uso realiza um aspecto maior 
da funcionalidade do produto:
◦ deve gerar um ou mais benefícios para o cliente 
ou para os usuários
◦ Podem representar:
� roteiros de interação com usuário
� roteiros do manual de usuário
� casos de teste
78
16/03/2012
40
� Casos de Uso (CDU)
◦ Técnica para documentar os requisitos potenciais 
para um novo sistema ou para uma modificação 
em um software;
◦ Cada CDU provê um ou mais cenários que 
descrevem como o sistema deve interagir com 
seus usuários finais ou outros sistemas para 
atingir um objetivo de negócio;
79
� CDUs não descrevem o funcionamento interno de 
um sistema tampouco explicam como o sistema 
deve ser implementado
� Ao invés, mostram os passos que um usuário deve 
seguir para realizar uma tarefa.
� Um CDU define interações entre atores externos e 
o sistema sob consideração para se atingir um 
objetivo de negócio.
� Atores são entidades externas ao sistema. Um ator 
pode ser uma classe de usuários, um papel que 
usuários podem desempenhar, ou outro sistema.
80
16/03/2012
41
� CDUs são efetivos para descrever requisitos funcionais. 
� CDUs focalizam nas interações de um usuário com o 
sistema, ou em interações sistema a sistema.
� Contudo, não são úteis em projetos onde a 
complexidade não está associada com a interatividade, 
e sim com a funcionalidade interna
◦ P.Ex: Processamento batch, Data Wareshousing, cálculos 
complexos
� CDUs também não são adequados para descrever 
requisitos não funcionais. 
� Entretanto, o raciocínio em cima de CDUs pode ser útil 
para identificar requisitos de performance.
81
� Casos de uso servem como guia para:
◦ Criação e validação da arquitetura do 
sistema.
◦ Definição de casos e procedimentos de 
testes.
◦ Planejamento da iterações, elaboração de 
cronograma, organização do time.
◦ Criação da documentação do usuário.
82
16/03/2012
42
� Notação Gráfica
83
Caixa eletrônico
Consultar
saldo
Solicitar
extrato
Realizar
SaqueCliente Funcionário
Abastecer
dinheiro
Recolher
envelopes de
depósitos
[Furlan98]
Realizar
depósito
� Notação gráfica (em ferramenta CASE)
84
Consultar saldo
Emitir extrato
Realizar saque
Cliente
Realizar depósito
Retirar envelopes de depósito
Funcionário
Abastecer com dinheiro
16/03/2012
43
� Oferecem uma maneira intuitiva e 
sistemática para capturar os requisitos 
FUNCIONAIS
� Foco no conceito de “valor adicionado” 
(added value) ao cliente
� Podem ser utilizados para guiar o processo 
de desenvolvimento
85
� Notação - Elementos:
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 86
Ator
Ator. Elemento externo do sistema que sempre
inicia o uso ou recebe um valor do caso de uso
Caso de Uso. Serviço que o sistema fornece aos usuários.
Sistema
Caso de uso 1
Interação. Estímulos recebidos pelo sistema.
Sistema. Contexto aonde o caso de uso é utilizado
16/03/2012
44
� Conceito – CDU
◦ Normalmente associado com uma tela de entrada 
e/ou saída de dados, ou um relatório
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 87
� Conceito – Cenário
◦ Sequência única e completa de eventos
� Ator segue para atingir um objetivo
◦ Exemplo (Realizar Saque):
� Saque com sucesso
� Tentativa de saque senha incorreta
� Tentativa de saque saldo insuficiente
◦ Cada caso de uso encapsula uma coleção de 
cenários, tanto de sucesso como de falha.
88
Cliente
Realizar saque
16/03/2012
45
� Conceito - Ator
◦ Qualquer coisa que possui interface com o sistema 
a ser desenvolvido
◦ Definem um papel particular exercido por uma 
coisa ou pessoa
◦ São sempre externos ao sistema
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 89
Cliente
Exemplo de Ator:
(Sempre com aparência humanóide)
� Conceito – Ator
◦ Uma mesma pessoa pode desempenhar diferentes 
papéis em um sistema
◦ Cada papel é representado por um ator.
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 90
Funcionário Administrador
Pedro
Papéis que
pode exercer
16/03/2012
46
� Conceito – Comunicação Ator e CDU
◦ Representa quais atores estão ligadosa quais casos 
de uso
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 91
Telefone Celular
A comunicação é representada através
de um arco simples
Usuário
Fazer ligação
� Tipos de Interação
◦ Inclusão
� Um caso inclui (precisa de, é composto de) outro 
� Representada através de um arco pontilhado com o rótulo 
<<inclui>> ou <<include>> (UML 1.4+) ou <<uses>> (UML 
1.3-)
� Normalmente um CDU componente é usado em mais de um 
caso de uso
92
Telefone Celular
Usuário
Fazer ligação Identificar destinatário
<<include>>
16/03/2012
47
� Tipos de Interação
◦ Extensão
� Um caso de uso pode opcionalmenteopcionalmenteopcionalmenteopcionalmente utilizar um outro
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 93
Telefone Celular
Usuário
Receber ligação
Receber Ligação Adicional
<<extend>>
Opcional
� Extensão
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 94
Servir entrada Servir sobremesa
Servir refeição
<<extend>>
<<extend>>
16/03/2012
48
� Conceito - Herança
◦ Generalização / Especialização
� Pode ser aplicada para CDU e Ator
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 95
Super tipo
Sub tipos
Pagamento a vista Pagamento com cartão
Usuário Efetua pagamento
� Conceito – Herança
◦ Herança de Atores
96
Atendente
Realiza venda
Gerente
Cancela venda
<<extend>>
Consulta estoque
Funcionário
16/03/2012
49
� Exemplo
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 97
Busca itens
Cliente
Solicita ajuda Sistema de ajuda online
Realiza pedido
Processador de pagamentos
Tempo
Realiza pagamento de impostos
Autoridade de impostos
1o release
2o release
3o release
� Exemplo - Telefone Celular
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 98
Telefone Celular
Usuário
Rede
Celular
Fazer
ligação
Receber
ligação
Fazer uso
programado
Fazer
ligação em
conferência
Receber
ligação
adicional
<<extend>>
<<extend>>
Identificar
destinatário
<<include>>
16/03/2012
50
� Exemplo
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009 99
Cliente
Cliente
Pessoa
Física
Cliente
Pessoa
Jurídica
Sistema de Venda
com Cartão de Crédito
Varejista
Administradora
de
cartão de
crédito
Transação
Venda
Cancelamento
de venda
<<extends>>
Obs: padrão de análise
� Caso de Uso Transação
◦ Abstrato
� É usado como generalização
◦ É usado para representar serviços da organização 
que precisam ter a sua ocorrência registrada
� O registro obrigatoriamente contém
� o momento em que ocorreu a transação (data/hora)
� quem participou (cliente e vendedor)
� o quê esteve envolvido (o produto da venda)
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
10
0
16/03/2012
51
� Exemplo – Máquina de Venda de Bebidas
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
10
1
Vender bebida
Consumidor
Abrir máquina
Fechar máquina
Fornecedor
Repor Bebidas
<<include>>
<<include>>
Dono
Retirar dinheiro
<<include>>
<<include>>
� Granularidade de CDUs
◦ Um CDU deve representar uma unidade de 
funcionalidade menor possível, que uma vez 
implementada, acrescenta valor (do ponto de vista 
dos autores) ao sistema
◦ Exemplo em ATM bancário
� “Introduzir cartão” não é CDU (não tem valor 
isoladamente)
� “Realizar saque” é CDU pois tem valor para o 
correntista
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
10
2
16/03/2012
52
� Quem usa o sistema?
� Quem instala/mantém o sistema?
� Quem inicia/desliga o sistema?
� Que outros sistemas usam o sistema?
� Quem recebe informação do sistema?
� Quem provê informação ao sistema?
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
10
3
� Atores são fundamentais para a descoberta dos 
casos de uso
� Pergunte:
◦ Que funções o ator vai querer do sistema?
◦ O sistema armazena informações? Que informações atores 
irão criar, ler, atualizar ou apagar?
◦ O sistema precisa notificar o ator sobre mudanças no seu 
estado interno?
◦ Existe algum evento externo que o sistema precisa saber? 
Que ator informa o sistema desses eventos?
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
10
4
16/03/2012
53
� É preciso delimitar as fronteiras do 
sistema
◦ Se a fronteira for o círculo interno, então 
Caixa e o Sistema Bancário são atores e não 
precisarão ser implementados.
Cliente
Caixa
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
10
5
Sistema BancárioSistema de 
Caixa Automático
Qual é a 
fronteira
do sistema?
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
10
6
16/03/2012
54
� Quando?
◦ Após fazer levantamento dos principais casos de 
uso do sistema.
� Por que?
◦ Descrever detalhes dos casos de uso
◦ Descrever fluxos de eventos e outras 
propriedades
◦ Uniformizar entendimento entre clientes, 
usuários e equipe de desenvolvimento.
10
7
� Casos de uso não precisam ser 
especificados todos de uma vez
� Casos de uso devem ser 
priorizados por iteração
◦ Prioridade técnica
◦ Prioridade do usuário
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
10
8
16/03/2012
55
� Identificador
� Nome e breve descrição
� Ator(es)
� Prioridade
� Requisitos não funcionais associados
� Pré-condições
� Pós-condições
� Fluxo de eventos principal
� Fluxos secundários: alternativos e de exceção
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
10
9
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
11
0
� Deve ser única
� Não deve mudar nunca, pois 
casos de uso podem ser 
referenciados por seu 
identificador.
16/03/2012
56
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
11
1
� Dar uma idéia do propósito do caso de 
uso, do seu objetivo
� Deve ser feita ao se identificar o caso de 
uso, para evitar mal-entendidos
� 2 ou 3 linhas!
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
11
2
� Essencial para gerenciar requisitos e para 
montar iterações
� Definir prioridade de todos os casos de 
uso
� Exemplo de classificação da prioridade:
◦ Essencial
◦ Importante
◦ Desejável
16/03/2012
57
� O que deve ser verdade antes e depois da 
realização do caso de uso!
◦ Pré-condição: 
� estado em que o sistema deve estar para realizar o 
caso de uso.
◦ Pós-condição: 
� lista de possíveis estados em que o sistema pode 
estar imediatamente após o término da realização 
do caso de uso.
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
11
3
� Caso de uso “Entregar pedido”
◦ Pré-condição: Os itens do pedido devem 
existir em estoque
◦ Pós-condição: Os itens enviados devem ser 
abatidos do estoque.
� Caso de uso “Recadastramento de CPF”
◦ Pré-condição: o usuário deve possuir um CPF
◦ Pós-condição: a situação do contribuinte é 
atualizada.
© Carla A. Lima Reis e Rodrigo Quites Reis 
(LABES-UFPA) / 2009 114
16/03/2012
58
� Funcionalidade básica ou central do caso de 
uso
� Representa o caminho que é seguido na 
maioria das vezes que o caso de uso é 
executado.
� Descreve a situação mais simples do caso 
de uso, na qual o objetivo é atingido.
� Pense nos fluxos secundários depois!
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
11
5
� Caso de uso “Sacar dinheiro”
1.O cliente passa o cartão
2.O sistema solicita senha e valor do saque
3.O cliente digita os valores solicitados
4.O sistema verifica se há saldo suficiente 
5.O sistema debitada conta do cliente o valor 
do saque.
6.O dinheiro é entregue ao cliente.
© Carla A. Lima Reis e Rodrigo Quites Reis 
(LABES-UFPA) / 2009 116
16/03/2012
59
� Caso de uso “Sacar dinheiro”
� MAS...
◦ E se a senha não conferir?
◦ E se não houver saldo?
◦ E se não houver dinheiro suficiente na 
máquina?
Calma, vamos deixar esses detalhes para 
depois!
© Carla A. Lima Reis e Rodrigo Quites Reis 
(LABES-UFPA) / 2009 117
� Pré-condição: usuário não está suspenso
� 1. Usuário solicita um item do acervo
� 2. Funcionário verifica disponibilidade do 
item solicitado
� 3. Sistema informa a localização do item
� 4. Funcionário registra o empréstimo
� 5. O sistema emite um comprovante do 
empréstimo (em duas vias)
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
11
8
16/03/2012
60
� As vezes, o fluxo principal possui várias 
alternativas igualmente prováveis de 
ocorrer
� Nestes casos, pode-se usar o conceito 
de subfluxos
� Cada subfluxo representa um dos 
possíveis caminhos do fluxo principal
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
11
9
� Caso de uso “Cadastrar Produtos”
◦ Fluxo básico
1.O funcionário seleciona a opção de cadastro, 
iniciando o caso de uso.
2.O sistema solicita que o funcionário indique a 
operação que deseja efetuar: inclusão, atualização 
ou remoção de produtos.
3.De acordo com a opção fornecida pelo funcionário, 
um dos subfluxos abaixo é executado.
120
16/03/2012
61
◦ Subfluxo Incluir produto
1. O sistema solicita o nome, descrição e preço do novo produto.
2. O funcionário fornece os dados
3. O sistema gera um identificador único para o produto e o 
armazena as informações fornecidas.
◦ Subfluxo Alterar informações do produto
1. O sistema solicita o nome ou identificador do produto a ser 
alterado.
2. O funcionário fornece o identificador do produto.
3. Os sistema apresenta os dados do produto para alteração (os 
mesmos dados solicitados no subfluxo “Incluir produto”)
4. O funcionário atualiza os dados do produto e o sistema 
armazena os novos dados.
◦ Subfluxo Remover produto
...
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
12
1
� Só devem ser analisados e descritos após a 
descrição dos fluxos básicos.
◦ Para cada CDU, perguntar: “o que pode dar 
errado?”, “o que pode ser diferente?”
� Fluxos alternativos
◦ Situações especiais (desconto para um cliente)
� Fluxos de erro
◦ Situações de erro
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
12
2
16/03/2012
62
� Fluxos secundários, principalmente 
de erros, podem ser referenciados 
por diferentes casos de uso
� Evitar duplicação de informação!
12
3
12
4
� Fluxo normal ou básico (“Happy Path”)
◦ Pode conter subfluxos
� Fluxos alternativos
◦ Variações regulares
◦ Casos incomuns
� Fluxos de exceção
◦ Tratam situações de erro do fluxo básico.
16/03/2012
63
� O modelo de caso de usos está fácil de se 
entender?
� Estudando o modelo de caso de usos, você
pode ter uma idéia clara das funções do 
sistema e como elas estão relacionadas?
� Todos os requisitos foram levantados?
� O modelo de caso de usos contém algum
comportamento supérfluo?
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
12
5
� Cada caso de uso está envolvido com pelo menos
um ator?
� Algum dos caso de usos tem comportamento ou
fluxo de eventos muito similares?
� Os caso de usos têm nomes únicos, intuitivos e 
explicativos de modo que não podem ser 
confundidos em um estágio posterior?
� Os patrocinadores e usuários entendem os nomes
e descrições dos caso de uso?
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
12
6
16/03/2012
64
� Todos os atores foram identificados?
� Cada ator está envolvido com pelo menos um caso de 
uso?
� Cada ator desempenha um papel? Algum deveria ser 
fundido com outro ou ser dividido em dois?
� Existem dois ou mais atores desempenhando o mesmo
papél em relação a um caso de uso?
� Os atores têm nomes intuitivos e descritivos? Tanto os
usuários como os patrocinadores do software têm um 
entendimento comum?
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
12
7
� Está claro quem deseja executar um caso de uso?
� A finalidade de cada caso de uso está clara?
� A descrição breve dá uma idéia clara do significado
do caso de uso?
� Está claro como e quando os fluxos de eventos de 
cada caso de uso começam e terminam?
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
12
8
16/03/2012
65
� A seqüência de comunicação entre um ator e um 
caso de uso está de acordo com as expectativas do 
usuário?
� As interações e trocas de informação entre os
atores e o sistema estão claras?
� Existe algum caso de uso demasiadamente
complexo?
� Os fluxos de eventos (básicos e alternativos) estão
modelados de forma clara?
© Carla A. Lima Reis e Rodrigo 
Quites Reis (LABES-UFPA) / 2009
12
9
� Exercício
◦ Faça o diagrama de casos de uso do sistema 
escolhido
Imifarma S.A. - Programação 
Orientada a Objetos
13
0