Parte 1 do material sobre UML, contendo: - introdução a Orientação a Objetos - visão geral do processo de software OO - histórico da UML - diagramas de casos de uso - diagramas de classes

1. www.labes.ufpa.br
Abril
de
2015
ESPECIALIZAÇÃO
EM
P
PROJETO
DE
SOFTWARE
COM
UML
(DOCUMENTAÇÃO
DE
ARQUITETURA
DE
SOFTWARE)
PROF.
RODRIGO
QUITES
REIS
easo5ware,
ufpa,
2015
1

2. www.labes.ufpa.br
easo5ware,
ufpa,
2015
2
Obje9vo
da
Disciplina
• Fornecer
ao
aluno
a
capacitação
no
uso
de
UML
para
documentar
Requisitos
e
Arquitetura
de
So5ware
• Engenharia
Avante
– Construção
de
modelos
como
forma
de
se
refinar
o
entendimento
dos
requisitos,
estabelecer
o
comportamento,
e
gerar
código/esquemas
de
banco
de
dados
• Engenharia
Reversa
– Geração
de
documentação
a
par9r
de
so5ware
já
desenvolvido

3. www.labes.ufpa.br
Conteúdo
• Visão
Geral
sobre
o
Processo
de
Engenharia
de
So5ware
• Revisão
de
Orientação
a
Objetos
• UML
– Histórico
– Núcleo
da
UML
– Especificação
de
Requisitos
– Arquitetura
de
so5ware
• Exemplos
e
Exercícios
permeiam
a
disciplina
easo5ware,
ufpa,
2015
3

4. www.labes.ufpa.br
Orientação
a
Objetos
easo5ware,
ufpa,
2015
4

5. www.labes.ufpa.br
Antes
da
Orientação
a
Objetos
• Modelo
predominante:
Programação
Estruturada
– Estrutura
de
Sequência
• Ação1;
Ação2;
Ação3;
Ação4;
Ação5;
– Estrutura
de
Seleção
• Se,
então,
senão
– Estrutura
de
Repe9ção
• Repe9r
…
Até
;
• Enquanto
…;
easo5ware,
ufpa,
2015
5

6. www.labes.ufpa.br
Antes
da
Orientação
a
Objetos
• Programação
Estruturada
– Muito
código
foi
desenvolvido
e
con9nua
operacional
– Dificuldades
em
manter
e
reu9lizar
código
em
grande
escala
– Principais
unidades
de
manutenção/reuso:
• Módulos
funcionais
– Procedures
e
Func9ons
(Pascal)
– Func9ons
(em
C)
easo5ware,
ufpa,
2015
6

7. www.labes.ufpa.br
Antes
da
Orientação
a
Objetos
• Abstrações
Procedimentais
easo5ware,
ufpa,
2015
7
Problema
Proc
proc1;
Begin
...
End;
Proc
proc2(a,b,c);
Begin
...
End;
FuncJon
f1(x,
y);
Begin
...
End;
Begin
//
principal
End;
Programa
em
Pascal
Mapeamento
Mecanismos
de
abstração
da
Programação
Estruturada:
Procedimentos
e
funções

8. www.labes.ufpa.br
Orientação
a
Objetos
• Obje9vos
– Facilitar
o
mapeamento
do
Problema
para
Código
executável
• O
mundo
não
é
composto
por
procedimentos
• Estrutura
é
relacionável
com
Matemá9ca
Discreta
– Facilitar
a
manutenção
e
reu9lização
• Classes
são
cápsulas
que
englobam
(estruturas
de
dados
+
operações)
com
controle
de
acesso
• Modificações
tendem
a
ficar
restritas
a
um
módulo
easo5ware,
ufpa,
2015
8

9. www.labes.ufpa.br
Orientação
a
Objetos
• Conceitos
básicos
– Classe
&
Objeto
– Composição
de
objetos
– Herança
de
Classes
(sub-­‐9pos)
– Método
&
Mensagem
easo5ware,
ufpa,
2015
9

10. www.labes.ufpa.br
Orientação
a
Objetos
• Abstração
Orientada
a
Objetos
easo5ware,
ufpa,
2015
10
Problema
Classe
Pessoa
{
...
}
Classe
Obra
{
...
}
void
main()
{
…
}
Programa
em
C++/Java
Mapeamento
Mecanismos
de
abstração
da
Orientação
a
Objetos:
Classes,
Métodos,
Herança,
Composição,
etc.

11. www.labes.ufpa.br
Orientação
a
Objetos
• Conceito:
Classe
– Definição
de
um
conjunto
de
objetos
que
compar9lham
estrutura
e
comportamento
comuns
– Objetos
são
criados
a
par9r
das
classes
– Na
construção
de
uma
classe,
a
abstração
mais
importante
diz
respeito
aos
dados
– O
principal
modelo
semân9co
adotado
é
a
Teoria
dos
Conjuntos
(para
definição
dos
dados)
easo5ware,
ufpa,
2015
11

12. www.labes.ufpa.br
Orientação
a
Objetos
• Conceito:
Classe
e
Objeto
easo5ware,
ufpa,
2015
12
Funcionário
Nome: João
Cargo: Analista
Grupo: Desenvolvimento
Nome: Maria
Cargo: Gerente
Grupo: Desenvolvimento
Classe
(conjunto)
Objetos
(elementos do
conjunto)

13. www.labes.ufpa.br
Orientação
a
Objetos
• O
uso
de
computador
é
baseado
em
abstrações
– Abstração:
representação
simplificada
da
realidade,
segundo
um
ponto
de
vista
– Exemplos:
• Zeros
e
Uns
para
representar
valores
de
portas
eletrônicas
de
um
computador
• Linguagens
de
Programação
• Interface
gráfica
baseada
em
Mouse
e
Janelas
easo5ware,
ufpa,
2015
13

14. www.labes.ufpa.br
Orientação
a
Objetos
• Abstrações
easo5ware,
ufpa,
2015
14
Booch,
1991

15. www.labes.ufpa.br
Orientação
a
Objetos
• Conceito:
Encapsulamento
easo5ware,
ufpa,
2015
15
Booch,
1991

16. www.labes.ufpa.br
Orientação
a
Objetos
• Encapsulamento
easo5ware,
ufpa,
2015
16
htp://www.dsc.ufcg.edu.br/~jacques/cursos/p2/html/oo/objetoconta.gif

17. www.labes.ufpa.br
Orientação
a
Objetos
• Encapsulamento
– Influência
dos
circuitos
integrados
– Podem
ser
livremente
combinados
– Não
podem
ser
modificados
easo5ware,
ufpa,
2015
17

18. www.labes.ufpa.br
Orientação
a
Objetos
• Encapsulamento
&
Mensagens
– “Muralha”
em
volta
do
objeto
– No
funcionamento
do
sistema,
objetos
respondem
mensagens
de
outros
objetos
– Alteração
no
estado
interno
do
objeto
só
através
dos
métodos
easo5ware,
ufpa,
2015
18
Objeto
Encapsulamento

19. www.labes.ufpa.br
Orientação
a
Objetos
• Encapsulamento
&
Mensagens
easo5ware,
ufpa,
2015
19
Void
violacao
{
ObjetoExterno
o;
o.Nome
=
“Fulano”;
o.Endereco
=
“Av.
Tal”;
....
Void
não_viola
{
ObjetoExterno
o;
o.setNome(“Fulano”);
o.setEndereco(“Av.
Tal”);
....

20. www.labes.ufpa.br
Orientação
a
Objetos
• Encapsulamento
&
Mensagens
– Lei
de
Deméter
easo5ware,
ufpa,
2015
20
X
Y
z
obj
obj.mensagem(parâmetros)
mensagem(p)
begin
...
// qualquer valor manipulado aqui é x, y, z ou p.
end;

21. www.labes.ufpa.br
Orientação
a
Objetos
• Outros
elementos
importantes
– Classificação
• Associar
objetos
às
classes
– Associação
• Conexão
entre
objetos
– Agregação
• Um
objeto
é
composto
por
outro
– Generalização/Especialização
• Herança
easo5ware,
ufpa,
2015
21

22. www.labes.ufpa.br
Orientação
a
Objetos
• Classificação
easo5ware,
ufpa,
2015
22

23. www.labes.ufpa.br
Orientação
a
Objetos
• Associação
(ou
conexão)
entre
objetos
– Objetos
exis9ndo
de
forma
associada
– Poderoso
mecanismo
de
reu9lização
de
objetos
– Exemplo:
Biblioteca
easo5ware,
ufpa,
2015
23
Biblioteca
=
usuário
reserva
obra

24. www.labes.ufpa.br
Orientação
a
Objetos
• Agregação:
componentes
de
so5ware/hardware
easo5ware,
ufpa,
2015
24
System
Subsystem
1
Subsystem
2
Subsystem
3
Assembly
a
Assembly
b
Assembly
c
So5ware
Program
y
Hardware
Device
x
Notação
para
acesso
em
OO:
System.subsystem2.assemblyc.y

25. www.labes.ufpa.br
Orientação
a
Objetos
• Generalização/Especialização
easo5ware,
ufpa,
2015
25
Classes

26. www.labes.ufpa.br
Orientação
a
Objetos
easo5ware,
ufpa,
2015
26
• Generalização/Especialização
Funcionário
Proje9sta
Engenheiro
Gerente

27. www.labes.ufpa.br
Orientação
a
Objetos
• Estado,
Comportamento
e
Iden9dade
de
Objetos
– Estado:
• Conjunto
de
valores
armazenados
em
um
objeto
– Comportamento:
• Ações
que
o
objeto
pode
realizar,
isto
é,
o
conjunto
de
métodos
implementados
na
classe
associada
– Iden9dade:
• Todo
objeto
é
criado
com
uma
chave
primária
implícita
determinada
pelo
sistema
(Object
Iden9fier
-­‐
OID)
• O
OID
é
usado
para
definir
conexões
entre
objetos
easo5ware,
ufpa,
2015
27

28. www.labes.ufpa.br
Orientação
a
Objetos
• Estado,
Comportamento
e
Iden9dade
de
Objetos
easo5ware,
ufpa,
2015
28
Estado
Comportamento
IdenJdade

29. www.labes.ufpa.br
Processo
de
Análise
e
Projeto
Orientado
a
Objetos
easo5ware,
ufpa,
2015
29

30. www.labes.ufpa.br
Orientação
a
Objetos
easo5ware,
ufpa,
2015
30
Problema
Análise
Orientada
a
Objetos
Solução

31. www.labes.ufpa.br
Orientação
a
Objetos
31
Processo
Top-­‐Down
BD
Relacional
Classes
OO
Consulta
SQL
Métodos
(algoritmos)
easo5ware,
ufpa,
2015

32. www.labes.ufpa.br
Orientação
a
Objetos
• Orientação
a
Objetos
e
Modelo
Relacional
32
Banco de
Dados
Relacional
Interface
Gráfica
com
Usuário
Banco de
Dados
Relacional
Interface
Gráfica
com
Usuário
Modelo de
Objetos do
Negócio
Banco de
Dados
Relacional
Modelo de
Objetos do
Negócio
Interface
Gráfica c/
Usuário
Processo Bottom-Up Arquitetura de 3 camadas
easo5ware,
ufpa,
2015

33. www.labes.ufpa.br
O
Modelo
MPS
de
So5ware
e
seu
relacionamento
com
Análise/Projeto
de
Sistemas
easo5ware,
ufpa,
2015
33

34. www.labes.ufpa.br
MPS.BR
• MPS.BR
– Programa
de
Melhoria
do
Processo
de
So5ware
e
Serviços
de
TI
voltado
a
pequenas
e
médias
empresas
brasileiras
• MR-­‐MPS-­‐SW
– Modelo
de
Referência
para
Melhoria
do
Processo
de
So5ware
com
base
no
CMMi-­‐DEV
– 600+
avaliações
realizadas
– Modelo
de
maturidade
brasileiro
Avaliação
da
qualidade
de
so5ware
através
do
seu
processo
de
construção
easo5ware,
ufpa,
2015
34

35. www.labes.ufpa.br
Programa
MPS.BR
easo5ware,
ufpa,
2015
35

36. www.labes.ufpa.br
Níveis
de
Maturidade
easo5ware,
ufpa,
2015
36

37. www.labes.ufpa.br
Níveis
de
Maturidade
MPS-­‐SW
37
easo5ware,
ufpa,
2015

38. www.labes.ufpa.br
Processo
GRE
easo5ware,
ufpa,
2015
38

39. www.labes.ufpa.br
Níveis
de
Maturidade
MPS
39
easo5ware,
ufpa,
2015

40. www.labes.ufpa.br
Processo
PCP
easo5ware,
ufpa,
2015
40

41. www.labes.ufpa.br
Processo
DRE
easo5ware,
ufpa,
2015
41

42. www.labes.ufpa.br
Um
rápido
histórico
da
UML
easo5ware,
ufpa,
2015
42

43. www.labes.ufpa.br
Histórico
da
UML
• Diversas
metodologias
e
métodos
surgiram
para
apoiar
OO
– Evolução
a
par9r
de
linguagens
C++
e
SmallTalk
– Anos
80-­‐90:
diversidade
de
autores
– Anos
98-­‐2000:
unificação
em
torno
de
UML
43
easo5ware,
ufpa,
2015

44. www.labes.ufpa.br
Histórico
da
UML
• Exemplos
de
Notações
– Classes
easo5ware,
ufpa,
2015
44
Booch
Schlaer-Mellor
OMTCoad-Yourdon

45. www.labes.ufpa.br
Histórico
da
UML
• 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
So5ware
– Fabricantes
de
Ferramentas
– Treinamentos
• Cenário
ideal
para
unificação
em
torno
de
uma
única
notação
easo5ware,
ufpa,
2015
45

46. www.labes.ufpa.br
Histórico
da
UML
• Grady
Booch
– Um
dos
pioneiros
da
OO
– 1980:
ênfase
em
técnicas
de
projeto
para
Ada
– 1992-­‐1994:
livros
• Object-­‐Oriented
Design
with
Applica6ons
– projeto
de
programas
em
C++
e
Ada
easo5ware,
ufpa,
2015
46
Bastante
a9vo
no
Twiter
@Grady_Booch

47. www.labes.ufpa.br
Histórico
da
UML
• 1994:
Object-­‐Oriented
Analysis
and
Design
with
Applica6ons
• 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
Ra9onal
easo5ware,
ufpa,
2015
47

48. www.labes.ufpa.br
Histórico
da
UML
• 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
easo5ware,
ufpa,
2015
48

49. www.labes.ufpa.br
Histórico
da
UML
• James
Rumbaugh
– Object
Modeling
Technique
(OMT)
– Desenvolvida
na
GE
– Metodologia
baseada
em
notações
pré-­‐existentes
(ER,
DTE,
DFD)
– Clara
dis9nção
entre
as
três
visões
do
problema
– Base
da
UML
para
Análise
easo5ware,
ufpa,
2015
49

50. www.labes.ufpa.br
Histórico
da
UML
• James
Rumbaugh
(cont.)
easo5ware,
ufpa,
2015
50

51. www.labes.ufpa.br
Histórico
da
UML
easo5ware,
ufpa,
2015
51
Booch
Rumbaugh
OMT
Jacobson
OOSE
UML

52. www.labes.ufpa.br
Histórico
da
UML
easo5ware,
ufpa,
2015
52
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
UML
2.4.1

53. www.labes.ufpa.br
Histórico
da
UML
easo5ware,
ufpa,
2015
53
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

54. www.labes.ufpa.br
Histórico
da
UML
• 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,
...
easo5ware,
ufpa,
2015
54
Pessoa
Comitê
Membro-­‐de
Presidente-­‐de
{subconjunto}
0..*
0..*
0..*
Telefone
Celular
Usuário
Uso
programado

55. www.labes.ufpa.br
Histórico
da
UML
• O
que
é
UML
– De
propósito
geral
• Não
está
presa
a
uma
etapa
do
desenvolvimento
de
so5ware
– 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
easo5ware,
ufpa,
2015
55

56. www.labes.ufpa.br
Histórico
da
UML
• UML
apóia
o
desenvolvimento
incremental
easo5ware,
ufpa,
2015
56
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

57. www.labes.ufpa.br
UML
• O
que
é
UML
– De
propósito
geral
• Não
está
presa
a
uma
linguagem
de
programação
easo5ware,
ufpa,
2015
57
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;
}
Programador
Java
Possível
implementação

58. www.labes.ufpa.br
UML
• O
que
é
UML
– Padrão
OMG
• Em
htp://www.omg.org
estão
disponíveis
documentos
eletrônicos
que
contém
– Sumário
da
UML
– Semân9ca
– Guia
da
Notação
– Extensões
da
Linguagem
easo5ware,
ufpa,
2015
58

59. www.labes.ufpa.br
UML
• O
que
é
UML
– Privilegia
a
descrição
de
um
sistema
segundo
três
perspec9vas:
• Dados
(estrutural)
– Diagrama
de
Classes
• Operações
(funcional)
– Diagrama
de
Caso
de
Uso
• Eventos
(temporal/dinâmica)
– Diagramas
de
Seqüência,
A9vidades,
de
Transição
de
Estados
easo5ware,
ufpa,
2015
59

60. www.labes.ufpa.br
UML
• O
Processo
de
Análise
easo5ware,
ufpa,
2015
60
Funções
Dados
Problema
Análise
Eventos
Sistema
(conceitual)
(entrevistas,
leituras
especializadas,
brainstorming,
etc.)

61. www.labes.ufpa.br
UML
• O
Processo
de
Projeto
easo5ware,
ufpa,
2015
61
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

62. www.labes.ufpa.br
Falando
um
pouco
sobre
ferramentas
para
UML
easo5ware,
ufpa,
2015
62

63. www.labes.ufpa.br
• Astah
Algumas
das
principais
ferramentas
na
atualidade
easo5ware,
ufpa,
2015
63

64. www.labes.ufpa.br
• Astah
– iPad
Algumas
das
principais
ferramentas
na
atualidade
easo5ware,
ufpa,
2015
64

65. www.labes.ufpa.br
• Visual
Paradigm
Algumas
das
principais
ferramentas
na
atualidade
easo5ware,
ufpa,
2015
65

66. www.labes.ufpa.br
• Enterprise
Architect
Algumas
das
principais
ferramentas
na
atualidade
easo5ware,
ufpa,
2015
66

67. www.labes.ufpa.br
• 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
– ...
Como
estas
ferramentas
se
diferenciam
entre
si?
easo5ware,
ufpa,
2015
67

68. www.labes.ufpa.br
Casos
de
Uso
Notação
da
UML
e
especificações
textuais
suplementares
easo5ware,
ufpa,
2015
68

69. www.labes.ufpa.br
Casos
de
Uso
• Resumo
– Um
caso
de
uso
é
uma
forma
específica
de
uso
do
sistema
composta
por
uma
seqüência
de
ações
que
produz
um
resultado
de
valor
para
algum
agente
externo.
– Mostram
apenas
o
que
o
sistema
faz,
não
como.
– Capturam
o
comportamento
pretendido
para
um
sistema,
sem
a
necessidade
de
especificar
como
esse
comportamento
será
implementado.
easo5ware,
ufpa,
2015
69

70. www.labes.ufpa.br
Casos
de
Uso
• Um
caso
de
uso
realiza
um
aspecto
maior
da
funcionalidade
do
produto:
– deve
gerar
um
ou
mais
bene„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
easo5ware,
ufpa,
2015
70
Filho,
W.P.P
em
“Engenharia
de
So5ware:
Fundamentos,
Métodos
e
Padrões”

71. www.labes.ufpa.br
Casos
de
Uso
• Casos
de
Uso
(CDU)
– Técnica
para
documentar
os
requisitos
potenciais
para
um
novo
sistema
ou
para
uma
modificação
em
um
so5ware;
– Cada
CDU
provê
um
ou
mais
cenários
que
descrevem
como
o
sistema
deve
interagir
com
seus
usuários
finais
ou
outros
sistemas
para
a9ngir
um
obje9vo
de
negócio;
– CDUs
devem
evitar
jargão
técnico,
usando
ao
invés
a
linguagem
do
usuário
ou
do
especialista
de
domínio.
easo5ware,
ufpa,
2015
71

72. www.labes.ufpa.br
Casos
de
Uso
• 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
a9ngir
um
obje9vo
de
negócio.
• Atores
são
en9dades
externas
ao
sistema.
Um
ator
pode
ser
uma
classe
de
usuários,
um
papel
que
usuários
podem
desempenhar,
ou
outro
sistema.
easo5ware,
ufpa,
2015
72

73. www.labes.ufpa.br
Casos
de
Uso
• CDUs
são
efe9vos
para
descrever
requisitos
funcionais,
mas
não
para
todos
os
9pos
de
projetos.
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
intera9vidade,
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
ú9l
para
iden9ficar
requisitos
de
performance.
easo5ware,
ufpa,
2015
73

74. www.labes.ufpa.br
Casos
de
Uso
• 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
9me.
– Criação
da
documentação
do
usuário.
easo5ware,
ufpa,
2015
74

75. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Notação
Gráfica
easo5ware,
ufpa,
2015
75
Caixa
eletrônico
Consultar
saldo
Solicitar
extrato
Realizar
SaqueCliente Funcionário
Abastecer
dinheiro
Recolher
envelopes de
depósitos
[Furlan98]
Realizar
depósito

76. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Notação
gráfica
(em
ferramenta
CASE)
easo5ware,
ufpa,
2015
76
Consultar saldo
Emitir extrato
Realizar saque
Cliente
Realizar depósito
Retirar envelopes de depósito
Funcionário
Abastecer com dinheiro

77. www.labes.ufpa.br
Casos
de
Uso
• Oferecem
uma
maneira
intui9va
e
sistemá9ca
para
capturar
os
requisitos
FUNCIONAIS
• Foco
no
conceito
de
“valor
adicionado”
(added
value)
ao
cliente
• Podem
ser
u9lizados
para
guiar
o
processo
de
desenvolvimento
easo5ware,
ufpa,
2015
77
[Unified
So5ware
Development
Process
–
Jacobson,
Booch,
Rumbaugh]

78. www.labes.ufpa.br
“Valor
adicionado”
• Perguntar
aos
clientes/usuários
o
que
eles
gostariam
que
o
sistema
fizesse
não
funciona:
– Lista
de
funcionalidades
que
pode
parecer
ú9l
a
princípio,
mas
na
verdade...
• Ex:
modificar
endereço
da
cobrança
• Estratégia
de
Caso
de
Uso:
– Refrazear
para
“O
que
você
quer
que
o
sistema
faça
PARA
CADA
USUÁRIO?”
easo5ware,
ufpa,
2015
78

79. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Notação
-­‐
Elementos:
easo5ware,
ufpa,
2015
79
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

80. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
–
CDU
– Normalmente
associado
com
uma
tela
de
entrada
e/ou
saída
de
dados,
ou
um
relatório
easo5ware,
ufpa,
2015
80

81. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
-­‐
Cenário
– Exemplo
(Realizar
Saque):
• Saque
com
sucesso
• Tenta9va
de
saque
MAS
senha
incorreta
• Tenta9va
de
saque
MAS
saldo
insuficiente
– Cada
caso
de
uso
encapsula
uma
coleção
de
cenários,
tanto
de
sucesso
como
de
falha.
easo5ware,
ufpa,
2015
81
Cliente
Realizar saque

82. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
-­‐
Ator
– Qualquer
coisa
que
possui
interface
com
o
sistema
a
ser
desenvolvido
– Definem
um
papel
par9cular
exercido
por
uma
coisa
ou
pessoa
– São
sempre
externos
ao
sistema
easo5ware,
ufpa,
2015
82
Cliente
Exemplo
de
Ator:
(Sempre
com
aparência
humanóide)

83. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
–
Ator
– Uma
mesma
pessoa
pode
desempenhar
diferentes
papéis
em
um
sistema
– Cada
papel
é
representado
por
um
ator.
easo5ware,
ufpa,
2015
83
Funcionário Administrador
Beltrano
Papéis
que
pode
exercer

84. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
-­‐
Pacotes
– Servem
para
agrupar
casos
de
uso
relacionados
– Critérios
para
agrupamento:
• Ator
• Funcionalidades
correlatas
• Processos
easo5ware,
ufpa,
2015
84
Consultar saldo
Emitir extrato
Realizar saque
Cliente
Realizar depósito
PacoteCliente

85. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
–
Comunicação
Ator
e
CDU
– Representa
quais
atores
estão
ligados
a
quais
casos
de
uso
easo5ware,
ufpa,
2015
85
Telefone
Celular
A comunicação é representada através
de um arco simples
Usuário
Fazer ligação

86. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Tipos
de
Interação
– Inclusão
• Um
caso
inclui
(precisa
de,
é
composto
de)
outro
• Representada
através
de
um
arco
pon9lhado
com
o
rótulo
<<inclui>>
ou
<<include>>
(UML
1.4+)
ou
<<uses>>
(UML
1.3-­‐)
• Normalmente
um
CDU
componente
é
usado
em
mais
de
um
outro
easo5ware,
ufpa,
2015
86
Telefone
Celular
Usuário
Fazer ligação Identificar destinatário
<<include>>

87. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Tipos
de
Interação
– Extensão
• Um
caso
de
uso
pode
opcionalmente
u9lizar
um
outro
easo5ware,
ufpa,
2015
87
Telefone
Celular
Usuário
Receber ligação
Receber Ligação Adicional
<<extend>>
Opcional

88. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Extensão
easo5ware,
ufpa,
2015
88
Servir entrada Servir sobremesa
Servir refeição
<<extend>>
<<extend>>

89. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
-­‐
Herança
– Generalização
/
Especialização
• Pode
ser
aplicada
para
CDU
e
Ator
easo5ware,
ufpa,
2015
89
Super tipo
Sub tipos
Pagamento a vista Pagamento com cartão
Usuário Efetua pagamento

90. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
–
Herança
– Herança
de
Atores
easo5ware,
ufpa,
2015
90
Administrador
Usuário Visitante
Correto?
Usuário
não
é
um
9po
de
Visitante

91. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
–
Herança
– Herança
de
Atores
easo5ware,
ufpa,
2015
91
Atendente
Realiza venda
Gerente
Cancela venda
<<extend>>
Consulta estoque
Funcionário

92. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Exemplo
easo5ware,
ufpa,
2015
92
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

93. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Exemplo
-­‐
Telefone
Celular
easo5ware,
ufpa,
2015
93
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>>
Iden9ficar
des9natário
<<include>>

94. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Exemplo
easo5ware,
ufpa,
2015
94
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

95. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• 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
par9cipou
(cliente
e
vendedor)
– o
quê
esteve
envolvido
(o
produto
da
venda)
easo5ware,
ufpa,
2015
95

96. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Exemplo
–
Máquina
de
Venda
de
Bebidas
easo5ware,
ufpa,
2015
96
Vender bebida
Consumidor
Abrir máquina
Fechar máquina
Fornecedor
Repor Bebidas
<<include>>
<<include>>
Dono
Retirar dinheiro
<<include>>
<<include>>

97. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Exemplo:
Restaurante
easo5ware,
ufpa,
2015
97
Servir entrada Servir sobremesa
Servir almoço
Servir jantar
Cobrar refeição
Comprar bens
Fornecedor
Cliente
Servir refeição
<<extend>>
<<extend>>
<<include>>

98. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
easo5ware,
ufpa,
2015
98

99. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• 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
corren9sta
easo5ware,
ufpa,
2015
99

100. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Granularidade
de
CDUs
– Devido
a
dúvida
sobre
o
valor
de
CDUs,
o
processo
de
modelagem
é
normalmente
itera9vo
easo5ware,
ufpa,
2015
100

101. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Heurís9cas
(1)
– Evitar
um
número
muito
elevado
de
casos
de
uso
• Fragmentar
o
sistema
em
sub-­‐sistemas
(ou
em
sub-­‐pacotes)
• Usar
casos
de
uso
com
denominação
genéricas
como
Manter
ou
Gerenciar
para
descrever
as
funções
de
Cadastro
de
uma
en9dade
• Evitar
detalhamento
algorítmico
easo5ware,
ufpa,
2015
101

102. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Heurís9cas
(2)
– Diagramas
de
Caso
de
Uso
têm
sido
usados
para
auxiliar
no
diálogo
do
usuário
– Deve-­‐se
ter
atenção
para
o
fato
que
o
diagrama
tem
semân9ca
informal
• Isto
é,
não
é
preciso
• Para
um
mesmo
problema,
múl9plas
soluções
válidas
são
admi9das
• Exige
descrição
textual
para
elucidação
easo5ware,
ufpa,
2015
102

103. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Heurís9cas
(3)
– Evitar
o
uso
de
<<include>>
e
<<extend>>
nas
primeiras
iterações
easo5ware,
ufpa,
2015
103

104. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
–
Modelo
de
Casos
de
Uso
– Modelo
que
descreve
os
casos
de
uso
do
sistema
e
atores
relacionados.
– Diagramas
e
especificações
textuais
Atores Casos de Uso
Especificações de casos de uso
easo5ware,
ufpa,
2015
104

105. www.labes.ufpa.br
Como
encontrar
Atores
e
CDUs?
• Atores
e
CDUs
são
elementos
de
primeira
ordem
– Atores:
papéis
desempenhados
por
usuários
ou
sistemas
externos
– CDUs:
serviços
fornecidos
pelo
sistema
novo
sendo
concebido
easo5ware,
ufpa,
2015
105

106. www.labes.ufpa.br
Como
encontrar
atores?
• 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?
easo5ware,
ufpa,
2015
106

107. www.labes.ufpa.br
Como
encontrar
casos
de
uso?
• 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
no9ficar
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?
easo5ware,
ufpa,
2015
107

108. www.labes.ufpa.br
Escopo
do
sistema
• É
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
easo5ware,
ufpa,
2015
108
Sistema BancárioSistema de
Caixa Automático
Qual é a
fronteira
do sistema?

109. www.labes.ufpa.br
Especificação
detalhada
dos
casos
de
uso
easo5ware,
ufpa,
2015
109

110. www.labes.ufpa.br
Quando
e
por
que
realizá-­‐las?
• 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.
easo5ware,
ufpa,
2015
110

111. www.labes.ufpa.br
Especificando
casos
de
uso
• 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
easo5ware,
ufpa,
2015
111

112. www.labes.ufpa.br
Especificação
de
um
caso
de
uso
• Iden9ficador
• 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:
alterna9vos
e
de
exceção
easo5ware,
ufpa,
2015
112

113. www.labes.ufpa.br
Iden9ficação
do
caso
de
uso
easo5ware,
ufpa,
2015
113
• Deve
ser
única
• Não
deve
mudar
nunca,
pois
casos
de
uso
podem
ser
referenciados
por
seu
iden9ficador.

114. www.labes.ufpa.br
Breve
descrição
do
caso
de
uso
easo5ware,
ufpa,
2015
114
• Dar
uma
idéia
do
propósito
do
caso
de
uso,
do
seu
obje9vo
• Deve
ser
feita
ao
se
iden9ficar
o
caso
de
uso,
para
evitar
mal-­‐entendidos
• 2
ou
3
linhas!

115. www.labes.ufpa.br
Atores
• Descrição
dos
atores
envolvidos
com
o
caso
de
uso
easo5ware,
ufpa,
2015
115
Usuário
Fazer ligação
Atores
Descrição
Usuário
É
o
responsável
por
iniciar
e
o
principal
interessado
na
realização
de
uma
ligação.
Para
tanto,
deve
ser
cliente
de
uma
operadora
de
telefonia
celular.

116. www.labes.ufpa.br
Prioridades
de
casos
de
uso
easo5ware,
ufpa,
2015
116
• 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

117. www.labes.ufpa.br
Pré
e
pós
condições
• 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.
easo5ware,
ufpa,
2015
117

118. www.labes.ufpa.br
Pré
e
pós
condições:
exemplos
• Caso
de
uso
“Entregar
pedido”
– Pré-­‐condição:
Os
itens
do
pedido
devem
exis9r
em
estoque
– Pós-­‐condição:
Os
itens
enviados
devem
ser
aba9dos
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.
easo5ware,
ufpa,
2015
118

119. www.labes.ufpa.br
Fluxo
de
eventos
básico
ou
principal
• 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
obje9vo
é
a9ngido.
• Pense
nos
fluxos
secundários
depois!
easo5ware,
ufpa,
2015
119

120. www.labes.ufpa.br
Exemplo
de
um
fluxo
básico
• 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
debita
da
conta
do
cliente
o
valor
do
saque.
6. O
dinheiro
é
entregue
ao
cliente.
easo5ware,
ufpa,
2015
120

121. www.labes.ufpa.br
Exemplo
de
um
fluxo
básico
• 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!
easo5ware,
ufpa,
2015
121

122. www.labes.ufpa.br
• 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és9mo
• 5.
O
sistema
emite
um
comprovante
do
emprés9mo
(em
duas
vias)
easo5ware,
ufpa,
2015
122

123. www.labes.ufpa.br
Subfluxos
• As
vezes,
o
fluxo
principal
possui
várias
alterna9vas
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
easo5ware,
ufpa,
2015
123

124. www.labes.ufpa.br
Subfluxos
-­‐
Exemplo
• 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.
easo5ware,
ufpa,
2015
124

125. www.labes.ufpa.br
Subfluxos
–
Exemplo
(2)
– 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
iden9ficador
único
para
o
produto
e
o
armazena
as
informações
fornecidas.
– Subfluxo
Alterar
informações
do
produto
1. O
sistema
solicita
o
nome
ou
iden9ficador
do
produto
a
ser
alterado.
2. O
funcionário
fornece
o
iden9ficador
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
...
easo5ware,
ufpa,
2015
125

126. www.labes.ufpa.br
Fluxos
secundários
• 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
alterna9vos
– Situações
especiais
(desconto
para
um
cliente)
• Fluxos
de
erro
– Situações
de
erro
easo5ware,
ufpa,
2015
126

127. www.labes.ufpa.br
Reuso
de
fluxos
secundários
• Fluxos
secundários,
principalmente
de
erros,
podem
ser
referenciados
por
diferentes
casos
de
uso
• Evitar
duplicação
de
informação!
easo5ware,
ufpa,
2015
127

128. www.labes.ufpa.br
Resumo
–
Fluxos
de
eventos
easo5ware,
ufpa,
2015
128
• Fluxo
normal
ou
básico
(“Happy
Path”)
– Pode
conter
subfluxos
• Fluxos
alterna9vos
– Variações
regulares
– Casos
incomuns
• Fluxos
de
exceção
– Tratam
situações
de
erro
do
fluxo
básico.

129. www.labes.ufpa.br
Requisitos
não
funcionais
associados
• Listar
RNFs
associados
ao
CDU
específico
– Exemplos:
• Tempo
de
resposta
(máximo
de
2
seg
para
100
transações
concorrentes)
• Segurança:
Controle
de
acesso
• …
easo5ware,
ufpa,
2015
129

130. www.labes.ufpa.br
easo5ware,
ufpa,
2015
130

131. www.labes.ufpa.br
Exemplo
easo5ware,
ufpa,
2015
131

132. www.labes.ufpa.br
easo5ware,
ufpa,
2015
132
Padrão
do
Ra9onal
Unified
Process

133. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Comentário
Final
– Os
casos
de
uso
são
elementos
muito
importantes
no
Processo
Unificado
– Todas
as
a9vidades
de
desenvolvimento
são
organizadas
em
função
dos
casos
de
uso
easo5ware,
ufpa,
2015
133

134. www.labes.ufpa.br
Papel
do
Modelo
de
CDU
no
Processo
easo5ware,
ufpa,
2015
134
Fonte: Alexandre Vasconcelos - O Fluxo de Requisitos

135. www.labes.ufpa.br
Checklists:
Modelo
de
Casos
de
Uso
• 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?
• A
divisão
em
pacotes
do
modelo
de
caso
de
usos
está
apropriada?
easo5ware,
ufpa,
2015
135

136. www.labes.ufpa.br
Checklists:
Atores
• Todos
os
atores
foram
iden9ficados?
• 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
intui9vos
e
descri9vos?
Tanto
os
usuários
como
os
patrocinadores
do
so5ware
têm
um
entendimento
comum?
easo5ware,
ufpa,
2015
136

137. www.labes.ufpa.br
Checklists:
Casos
de
Uso
• Cada
caso
de
uso
está
envolvido
com
pelo
menos
um
ator?
• Os
caso
de
usos
são
independentes
uns
dos
outros?
• Algum
dos
caso
de
usos
tem
comportamento
ou
fluxo
de
eventos
muito
similares?
• Os
caso
de
usos
têm
nomes
únicos,
intui9vos
e
explica9vos
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?
easo5ware,
ufpa,
2015
137

138. www.labes.ufpa.br
Checklists:
Especificação
de
Caso
de
Uso
• 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?
• A
seqüência
de
comunicação
entre
um
ator
e
um
caso
de
uso
está
de
acordo
com
as
expecta9vas
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
alterna9vos)
estão
modelados
de
forma
clara?
easo5ware,
ufpa,
2015
138

139. www.labes.ufpa.br
Encadeamento
dos
diagramas
da
UML
easo5ware,
ufpa,
2015
139

140. www.labes.ufpa.br
Processo
Simplificado
• Artefatos
easo5ware,
ufpa,
2015
140
Sistema
Usuário
XPTO
Diagrama
de
Casos
de
Uso
Diagrama
de
Classes
: Atendente: Atendente
Tela de Geração
de Conta
Tela de Geração
de Conta
: Sessão: Sessão : Item: Item
conta : Contaconta : Conta
: Promoção: Promoção
1: gerarContaSessão(s)
2: obter(s)
3: s
4: obterItensConsumidos
5: obterItens
6: itens
7: itens
10: obterPreço
11: preçoUnitário
12: obterQuantidade(item)
13: quantidade
8: obterNome
9: nome
repetir enquanto houver itens na sessão de consumo
15: criar(s, itens)
16: conta
17: conta
14:
Diagrama
de
Sequência
e
Colaboração
Planejado
Cancelado
transferência( novaData, novaHora ) /
data := novaData; hora := novaHora
Pago
Realizado
Realizado com
pagamento pendente
Realizado com
pagamento antecipado
Realizado com
pagamento pendente
pagamentoEfetuado Realizado com
pagamento antecipado
solicitaçãoPaciente / criarCancelamento(dataHoraAtual,
motivo=paciente)
solicitaçãoMédico / criarCancelamento(dataHoraAtual,
motivo=médico)
autorização( dataHoraAutorização, códigoAutorização, convênio )[ tipo == convênio
] / criarAutorização(dataHoraAutorização, códigoAutorização, convênio)
pagamentoEfetuado[ tipo == particular ]
Diagrama
de
Estados
Diagrama
de
AJvidades

141. www.labes.ufpa.br
Processo
Simplificado
• Relacionamento
entre
artefatos
(1)
easo5ware,
ufpa,
2015
141
Sistema
Usuário
XPTO
Diagrama
de
Casos
de
Uso
: Atendente: Atendente
Tela de Geração
de Conta
Tela de Geração
de Conta
: Sessão: Sessão : Item: Item
conta : Contaconta : Conta
: Promoção: Promoção
1: gerarContaSessão(s)
2: obter(s)
3: s
4: obterItensConsumidos
5: obterItens
6: itens
7: itens
10: obterPreço
11: preçoUnitário
12: obterQuantidade(item)
13: quantidade
8: obterNome
9: nome
repetir enquanto houver itens na sessão de consumo
15: criar(s, itens)
16: conta
17: conta
14:
Diagrama
de
Sequência
e
Colaboração
Fornece
os
cenários
Valida
as
interações

142. www.labes.ufpa.br
Processo
Simplificado
• Relacionamento
entre
artefatos
(2)
easo5ware,
ufpa,
2015
142
Sistema
Usuário
XPTO
Diagrama
de
Casos
de
Uso
Diagrama
de
Classes
Fornece
os
cenários
Validas
as
interações
(*)
(*)
isto
é,
se
não
forem
achadas
as
classes
envolvidas
em
um
CDU,
há
indícios
que
não
se
trata
de
um
CDU
em
si.

143. www.labes.ufpa.br
Processo
Simplificado
• Relacionamento
entre
Artefatos
(3)
easo5ware,
ufpa,
2015
143
Diagrama
de
Classes
: Atendente: Atendente
Tela de Geração
de Conta
Tela de Geração
de Conta
: Sessão: Sessão : Item: Item
conta : Contaconta : Conta
: Promoção: Promoção
1: gerarContaSessão(s)
2: obter(s)
3: s
4: obterItensConsumidos
5: obterItens
6: itens
7: itens
10: obterPreço
11: preçoUnitário
12: obterQuantidade(item)
13: quantidade
8: obterNome
9: nome
repetir enquanto houver itens na sessão de consumo
15: criar(s, itens)
16: conta
17: conta
14:
Diagrama
de
Sequência
e
Colaboração
Fornece
objetos
e
classes
Valida
o
modelo
e
fornece
detalhes
(atributos
e
operações)

144. www.labes.ufpa.br
Processo
Simplificado
• Relacionamento
entre
Artefatos
(4)
easo5ware,
ufpa,
2015
144
Diagrama
de
Classes
Planejado
Cancelado
transferência( novaData, novaHora ) /
data := novaData; hora := novaHora
Pago
Realizado
Realizado com
pagamento pendente
Realizado com
pagamento antecipado
Realizado com
pagamento pendente
pagamentoEfetuado Realizado com
pagamento antecipado
solicitaçãoPaciente / criarCancelamento(dataHoraAtual,
motivo=paciente)
solicitaçãoMédico / criarCancelamento(dataHoraAtual,
motivo=médico)
autorização( dataHoraAutorização, códigoAutorização, convênio )[ tipo == convênio
] / criarAutorização(dataHoraAutorização, códigoAutorização, convênio)
pagamentoEfetuado[ tipo == particular ]
Diagrama
de
Estados
Fornece
os
objetos
e
classes
Valida
o
modelo
e
fornece
detalhes
(atributos
e
operações)

145. www.labes.ufpa.br
Processo
Simplificado
• Relacionamento
entre
Artefatos
(5)
easo5ware,
ufpa,
2015
145
htp://www.voxxel.com.br/pages/introdiauml.html

146. www.labes.ufpa.br
Diagrama
de
Classes
III.1
Modelagem
de
Dados
III.2
Mapeamento
para
Banco
de
Dados
III.3
Projeto
com
Interfaces
III.4
Diagrama
de
Pacotes
easo5ware,
ufpa,
2015
146

147. www.labes.ufpa.br
Diagrama
de
Classes
• Resumo
– Diagrama
base
para
qualquer
discussão
acerca
da
arquitetura
de
um
sistema
com
UML
easo5ware,
ufpa,
2015
147

148. www.labes.ufpa.br
Diagrama
de
Classes
• Propósito
– Representação
dos
dados
manipulados
e
armazenados
pelos
programas
de
acordo
com
os
conceitos
de
Orientação
a
Objetos
– Notação
fortemente
baseada
no
Diagramas
En9dade-­‐
Relacionamento
de
Peter
Chen
easo5ware,
ufpa,
2015
148

149. www.labes.ufpa.br
Diagrama
de
Classes
• Diagrama
de
Classe
– Notação
easo5ware,
ufpa,
2015
149
Nome
da
classe
atributo:
9po
de
dado
atributo:
9po
de
dado
=
valor
inicial
Operação(lista
de
argumentos):
9po
do
resultado
Opcionais
(fornecidos somente após
um melhor entendimento
do sistema)

150. www.labes.ufpa.br
Diagrama
de
Classes
• Aspectos
tratados
pelos
Diagramas
de
Classe:
Dados
e
Funções
easo5ware,
ufpa,
2015
150
Dados
Funções
Eventos
Sistema
Obs:
a
ordem
da
execução
das
funções
(aspecto
temporal)
não
é
tratada
explicitamente
nos
diagramas
de
classe

151. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Permitem
descrever
as
relações
existentes
entre
os
elementos
(objetos)
dos
conjuntos
(classes)
easo5ware,
ufpa,
2015
151
Livros
Pessoas
Autor
de
Escrito
por

152. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
easo5ware,
ufpa,
2015
152
Livro
Pessoa
escrito
por
0..*
1..*
Multiplicidade da associação
Rótulo da associação

153. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Interpretação:
• Um
objeto
de
Livro
está
associado
com
no
mínimog
um
objeto
de
Pessoa,
e
no
máximo
com
uma
quan9dade
indeterminada
• Um
objeto
de
Pessoa
pode
não
estar
vinculado
com
qualquer
objeto
de
Livro
ou
com
uma
quan9dade
indeterminada
easo5ware,
ufpa,
2015
153
Livro
Pessoa
escrito
por
0..*
1..*

154. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Classes:
• Nome
de
“Coisas”
• Rotuladas
no
Singular
– Associações
• Leitura
no
sen9do
“convencional”
(esquerda
para
direita,
de
cima
para
baixo)
easo5ware,
ufpa,
2015
154

155. www.labes.ufpa.br
Diagrama
de
Classes
easo5ware,
ufpa,
2015
155
Jogador
Gol
0..* +autor0..*
Relação
18..*
0..*
18..*
0..*
Substituição
0..* +substituto0..*
0..*
+substituído
0..*
Expulsão
0..*
+expulso
0..*
Estádio
Arbitro
Torneio
Jogo
0..*0..*
+local
0..*0..*
+principal
2
0..*+auxiliar
2
0..*
1
0..*
+reserva
1
0..*
0..1
1..*
0..1
1..*
HistoriaEquipeJogo
0..*0..*
0..*0..*
0..*0..*
0..*
Equipe
2
0..*
2
0..*
0..*0..*0..*
Exemplo
de
diagrama
conceitual
(9picamente
produzido
nas
primeiras
iterações)
realizado
em

156. www.labes.ufpa.br
Diagrama
de
Classes
• Atributos
easo5ware,
ufpa,
2015
156
Pessoa
Nome:
Str
Endereço:
{
Logradouro:
Str,
Bairro:
Str,
Cidade:
Str.
}
Telefones:
Array
of
Int
Obs: Atributos Compostos e
Multivalorados são
permitidos pelo modelo de
dados OO

157. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Observe:
não
há
chave-­‐primária
easo5ware,
ufpa,
2015
157
Livro
Título:
Str
ISBN:
Int
Editora:
Str
Pessoa
Nome:
Str
Endereço:
{
Logradouro:
Str,
Bairro:
Str,
Cidade:
Str.
}
Telefones:
Array
of
Int
escrito
por
0..*
1..*
Multiplicidade da associação
Rótulo da associação

158. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Papel
de
Classe/Objeto
em
uma
Associação
(em
inglês,
role)
– Pode
ocorrer
simultaneamente
com
o
nome
(rótulo
/
label)
da
associação
– O
papel
é
usado
na
geração
de
código
e
BD
easo5ware,
ufpa,
2015
158
Livro
Título:
Str
ISBN:
Int
Editora:
Str
Pessoa
Nome:
Str
Endereço:
{
Logradouro:
Str,
Bairro:
Str,
Cidade:
Str.
}
Telefones:
Array
of
Int
escrito
por
0..*
1..*
autor
obra
Papéis

159. www.labes.ufpa.br
Diagrama
de
Classes
• Atributos
e
Métodos
easo5ware,
ufpa,
2015
159
Conta
Bancária
número
saldo
dataAbertura
criar()
bloquear()
desbloquear()
creditar()
debitar()
Pessoa
Nome:
Str
Endereço:
{
Logradouro:
Str,
Bairro:
Str,
Cidade:
Str.
}
Telefones:
Array
of
Int
1
0..*
9tular
dependente
0..2
0..*

160. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Exemplo
de
Geração
de
Código
em
Java
easo5ware,
ufpa,
2015
160
ContaBancariaPessoa 0..*
1
0..*
1
+titular possui
0..* 0..*+dependente 0..*0..*
Class
ContaBancaria
{
String
numero;
float
saldo;
Date
dataAbertura;
Pessoa
9tular;
Vector
dependente;
}
Omi9dos
do
diagrama
por
simplificação
Os
atributos
que
Implementam
as
Associações
não
devem
Ser
inseridos
no
diagrama

161. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Exemplos:
Associação
Unária
easo5ware,
ufpa,
2015
161
Funcionário
0..1
*
Supervisiona
Funcionário
João
supervisiona
É
supervisionado
por

162. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Exemplos:
Associação
Unária
easo5ware,
ufpa,
2015
162
Funcionário
0..1
*
Supervisiona
Funcionario
0..*
0..1 supervisiona
0..*
0..1+chefe
+subordinado
Evolução:
acréscimo
dos
papéis
facilita
a
implementação
e
o
entendimento

163. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Exemplos:
Associação
Unária
easo5ware,
ufpa,
2015
163
l Class
Funcionario
{
l Xxx;
l Funcionario
chefe;
l Vector
subordinado;
Funcionario
0..*
0..1 supervisiona
0..*
0..1+chefe
+subordinado

164. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Navegabilidade
das
Associações
• Associação
binária
e
bidirecional
easo5ware,
ufpa,
2015
164
Funcionário Departamento
0..* trabalha 1
Funcionário
trabalha
em
Departamento
Funcionário
João
Departamento
Financeiro

165. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Navegabilidade
das
Associações
• Associação
binária
e
unidirecional
easo5ware,
ufpa,
2015
165
Funcionário Departamento
0..* trabalha
Funcionário
João
Departamento
Financeiro

166. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Navegabilidade
das
Associações
• Associação
Unidirecional
– Razão
da
existência
è
mais
fácil
a
implementação
easo5ware,
ufpa,
2015
166

167. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Navegabilidade
das
Associações
easo5ware,
ufpa,
2015
167

168. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Mul9plicidade:
limiar inferior..limiar superior
easo5ware,
ufpa,
2015
168
Multiplicidade
Significado
0..1
Zero ou um
1
Somente 1 (opcional)
0..*
Maior ou igual a zero
*
Maior ou igual a zero
1..*
Maior ou igual a 1
1..15 (
m..n)
De 1 a 15 (m a n), inclusive

169. www.labes.ufpa.br
Diagrama
de
Classes
• Exercício:
qual
o
mais
correto?
easo5ware,
ufpa,
2015
169
Funcionário Departamento
1 trabalha 0..1
Funcionário Departamento
0..* trabalha
Funcionário Departamento
0..* trabalha 0..*
(adaptado de BEZ02)

170. www.labes.ufpa.br
Diagrama
de
Classes
• Exemplos
– Funcionário
=
{
João,
Maria,
José
}
– Depto
=
{A,
B}
– Trabalha
=
{
(João,
A),
(Maria,
B),
(José,
B)}
– Gerente
=
{
(João,
B),
(Maria,
A)
}
easo5ware,
ufpa,
2015
170
Funcionário Departamento
trabalha
1*
gerente 0..1

171. www.labes.ufpa.br
Diagrama
de
Classes
easo5ware,
ufpa,
2015
171
Funcionário
Departamento
Financeiro
TI
João
Marcela
Amanda
Funcionário Departamento
trabalha
1*
gerente 0..1

172. www.labes.ufpa.br
Diagrama
de
Classes
• Exemplo
easo5ware,
ufpa,
2015
172
Financeira
código
nome
Venda
data
hora
Vendedor
número
nenha
nívelAutorização
financia
0..1 * *
realizada por

173. www.labes.ufpa.br
Diagrama
de
Classes
• Classes
associa9vas
– Informação
que
surge
a
par9r
da
associação
de
duas
outras
classes
– Podem
ser
anônimas
– Um
objeto
de
classe
associa9va
está
associado
com
exatamente
um
objeto
de
cada
extremidade
easo5ware,
ufpa,
2015
173
Fulano,
Cálculo
I,
INS,
75%,
1º
2005
Fulano,
Cálculo
I,
BOM,
100%,
2º
2005
Beltrano,
Mat,
BOM,
90%,
2º
2005

174. www.labes.ufpa.br
Diagrama
de
Classes
• Classes
associa9vas
easo5ware,
ufpa,
2015
174
Pessoa
Nome
Endereço: {
Logradouro;
Bairro;
Cidade. }
Sexo
marido
esposa
0..1
0..1
casamento
Data
Regime
Pessoa
Nome
Endereço: {
Logradouro;
Bairro;
Cidade. }
Sexo
Pessoa
Nome
Endereço: {
Logradouro;
Bairro;
Cidade. }
Sexo
marido
esposa
0..1
0..1
casamento
Data
Regime
Data
Regime
Data
Regime

175. www.labes.ufpa.br
Diagrama
de
Classes
easo5ware,
ufpa,
2015
175
Pessoa
Nome
Endereço: {
Logradouro;
Bairro;
Cidade. }
Sexo
marido
esposa
0..1
0..1
casamento
Data
Regime
Pessoa
Nome
Endereço: {
Logradouro;
Bairro;
Cidade. }
Sexo
Pessoa
Nome
Endereço: {
Logradouro;
Bairro;
Cidade. }
Sexo
marido
esposa
0..1
0..1
casamento
Data
Regime
Data
Regime
Data
Regime
Pessoa
João
Marcela
Amanda
Jorge
Abel
dataX
regimeX
dataY
regimeY

176. www.labes.ufpa.br
Diagrama
de
Classes
• Classes
associa9vas
easo5ware,
ufpa,
2015
176
Financeira
código
nome
Venda
data
hora
Vendedor
número
nenha
nívelAutorização
financia
0..1 * *
realizada por
registroAprovação
dataAprovação
Financiamento

177. www.labes.ufpa.br
Diagrama
de
Classes
• Classes
associa9vas
– Observação
importante:
o
conceito
de
“Classe
Associa9va”
não
é
permi9do
em
todas
as
linguagens
de
programação
e
sistemas
de
banco
de
dados
OO
– Assim,
em
muitos
casos
as
classes
associa9vas
encontradas
em
Análise
são
subs9tuídas
por
classes
regulares
em
Projeto
easo5ware,
ufpa,
2015
177

178. www.labes.ufpa.br
Diagrama
de
Classes
• Classes
associa9vas
– Classe
associa9va
subs9tuída
por
normal
easo5ware,
ufpa,
2015
178
Obs:
sempre
vai
ser
mul9plicidade
1,
neste
caso
Original
(Análise)
Modificado
(Projeto)

179. www.labes.ufpa.br
Diagrama
de
Classes
• Classes
associa9vas
– Classe
associa9va
subs9tuída
por
normal
easo5ware,
ufpa,
2015
179
Observar
que
neste
caso
a
subs9tuição
não
é
trivial
visto
que
o
objeto
de
devolução
só
é
criado
após
a
associação
de
Emprés9mo
e
Item.

180. www.labes.ufpa.br
Diagrama
de
Classes
• Classes
associa9vas
– Classe
associa9va
subs9tuída
por
normal
easo5ware,
ufpa,
2015
180

181. www.labes.ufpa.br
easo5ware,
ufpa,
2015
181

182. www.labes.ufpa.br
easo5ware,
ufpa,
2015
182

183. www.labes.ufpa.br
Diagrama
de
Classes
• Exercício
– Fazer
diagrama
de
classes
para
a
súmula
de
campeonatos
de
futebol
easo5ware,
ufpa,
2015
183

184. www.labes.ufpa.br
easo5ware,
ufpa,
2015
184

185. www.labes.ufpa.br
Diagrama
de
Classes
• Agregação
– Associa
de
todo/parte
– Ação
realizada
sobre
todo
a9nge
as
partes
– Tipo
especial
de
associação
easo5ware,
ufpa,
2015
185
Documento
Parágrafo
Sentença
0..* 0..*
Documento
Parágrafo
Sentença
0..* 0..*
composto-por composto-por

186. www.labes.ufpa.br
Diagrama
de
Classes
• Agregação
– Exemplo
easo5ware,
ufpa,
2015
186
Associação
Espor9va
Equipe
Jogador
0..* 0..*
◀ afiliada

187. www.labes.ufpa.br
Diagrama
de
Classes
• Generalização/Especialização
– Todos
os
exemplos
anteriores
envolviam
a
ligação
entre
instâncias
de
classes
(objetos)
– Com
a
Herança,
o
relacionamento
fornecido
é
o
de
subconjunto
– Ú9l
para
definir
hierarquias
de
classes
(não
de
objetos!)
que
possuem
propriedades
comuns
easo5ware,
ufpa,
2015
187

188. www.labes.ufpa.br
Diagrama
de
Classes
• Generalização/Especialização
– Associação
do
9po
“é
um”
easo5ware,
ufpa,
2015
188
Cliente
nome
PessoaFísica
CPF
RG
Sexo
DataNascimento
PessoaJurídica
CGC
RazãoSocial
Super-classe
Sub-classes
(herdeiras)

189. www.labes.ufpa.br
Diagrama
de
Classes
• Generalização/Especialização
– Em
Ra9onal
Rose
easo5ware,
ufpa,
2015
189
Cliente
PF
PJ

190. www.labes.ufpa.br
Diagrama
de
Classes
• Generalização/Especialização
– Polimorfismo
de
dados:
• Uma
associação
pode
ocorrer
com
objetos
de
diferentes
classes
(deste
que
tenham
suas
classes
relacionadas
por
herança).
easo5ware,
ufpa,
2015
190

191. www.labes.ufpa.br
Diagrama
de
Classes
• Generalização/Especialização
– Polimorfismo
de
dados:
exemplo
• não
há
necessidade
de
se
criar
uma
associação
entre
Compra
e
subclasses
de
Cliente
easo5ware,
ufpa,
2015
191
Cliente
nome
PessoaFísica
CPF
RG
Sexo
DataNascimento
PessoaJurídica
CGC
RazãoSocial
Compra*realiza

192. www.labes.ufpa.br
easo5ware,
ufpa,
2015
192

193. www.labes.ufpa.br
Diagrama
de
Classes
• Generalização/Especialização
– Herança
Múl9pla:
caso
especial
easo5ware,
ufpa,
2015
193
Veículo
an„bio
Veículo
Veículo
terrestre
Veículo
aquá9co
Conceito pouco usado na prática:
• Poucas linguagens de programação
permitem o uso
• Adiciona maior complexidade ao
modelo

194. www.labes.ufpa.br
Diagrama
de
Classes
• Generalização/Especialização
– Classe
Abstrata
• Classe
que
não
instancia
objetos.
• Serve
apenas
para
gerar
novas
sub-­‐classes
a
par9r
da
herança.
• Freqüentemente
é
uma
classe
ar9ficial,
isto
é,
que
não
existe
no
Domínio
do
Problema
e
surge
para
acomodar
propriedades
comuns
de
classes
concretas.
• Representada
com
‘tulo
em
itálico
ou
com
uma
restrição
{abstrata}
(ou
{abstract})
easo5ware,
ufpa,
2015
194

195. www.labes.ufpa.br
Diagrama
de
Classes
• Generalização/Especialização
easo5ware,
ufpa,
2015
195
Cliente
ContaBancária
número
dataAbertura
saldo
debitar(quantia)
creditar(quantia)
Transação
ContaCorrente
limiteSaque
ContaPoupança
dataAniversário
* *
Classe
Abstrata
possui

196. www.labes.ufpa.br
Diagrama
de
Classes
• Generalização/Especialização
– Em
Ra9onal
Rose
easo5ware,
ufpa,
2015
196

197. www.labes.ufpa.br
easo5ware,
ufpa,
2015
197

198. www.labes.ufpa.br
easo5ware,
ufpa,
2015
198

199. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições
– São
regras
especificadas
com
lógica
ou
com
linguagem
específica
(*)
para
impedir
/
condicionar
a
criação
de
objetos
e
associações
– Úteis
para
especificar
regras
de
negócios
no
diagrama
– (*)
Object
Constrain
Language
-­‐
OCL
easo5ware,
ufpa,
2015
199

200. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições
–
Exemplo
{ou}
– Restrição
{ou}
implica
na
seleção
exclusiva
entre
duas
ou
mais
associações
existentes
em
uma
classe
easo5ware,
ufpa,
2015
200
Conta
corrente
Indivíduo
Organização
0..*
0..*
0..1
0..1
{ou}
cliente
cliente

201. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições
easo5ware,
ufpa,
2015
201
Conta
corrente
Cliente
Organização
0..*
0..1
cliente
Indivíduo
Conta
corrente
Indivíduo
Organização
0..*
0..*
0..1
0..1
{ou}
cliente
cliente
Obs:
são
equivalentes
Notar
classe
abstrata

202. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições
easo5ware,
ufpa,
2015
202
Contrato
de
Seguro
Indivíduo
Empresa
0..*
0..*
1..*
1..*
{ou}
Contrato
Cliente
Organização
0..*
1..*
Indivíduo
OBS:
Não
são
equivalentes!
Por
que?

203. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições
easo5ware,
ufpa,
2015
203
Significado:
seja
uma
pessoa
(empregado),
seu
empregador
é
mesmo
do
seu
chefe

204. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições
– Restrição
{subconjunto}
ou
{subset}
• Estabelece
relação
de
subconjunto
entre
duas
associações
easo5ware,
ufpa,
2015
204
Pessoa
Comitê
Membro-­‐de
Presidente-­‐de
{subconjunto}
0..*
0..*
0..*

205. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições
easo5ware,
ufpa,
2015
205
Pessoa
Comitê
Membro-­‐de
Presidente-­‐de
{subconjunto}
0..*
0..*
0..*
Pessoa
=
{joão,
josé,
maria}
Comitê
=
{
é9ca,
licitações
}
Membro-­‐de
=
{
(joão,
é9ca),
(josé,
licitações),
(maria,
licitações),
(maria,
é9ca)
}
Opções
(A)
Presidente-­‐de
=
{(joão,
é9ca),
(maria,
licitações)}
(B)
Presidente-­‐de
=
{(maria,
licitações),
(maria,
é9ca)}
(C)
Presidente-­‐de
=
{(josé,
é9ca)}
(errado,
não
é
subconjunto
de
Membro-­‐de)
(D)
Presidente-­‐de
=
{(maria,
licitações)}
(errado,
pois
cada
comitê
deve
possuir
um
presidente
–
e,
no
caso,
é9ca
não
tem
presidente)

206. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições
easo5ware,
ufpa,
2015
206
Funcionário Departamento
trabalha 1*
gerente 0..1
{subconjunto}
Funcionário
=
{
rodrigo,
carla,
dio
}
Departamento
=
{
informá9ca,
administração
}
(A) Trabalha
=
{
(rodrigo,
informá9ca),
(dio,
administração),
(carla,
informá9ca)
}
Gerente
=
{
(rodrigo,
informá9ca)
}
[errado,
pois
o
departamento
de
administração
não
possui
gerente]
(B)
Trabalha
=
{
(rodrigo,
informá9ca),
(dio,
administração)
,
(carla,
administração)
}
Gerente
=
{
(dio,
informá9ca)
,
(dio,
administração)
}

207. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições:
exemplos
diversos
easo5ware,
ufpa,
2015
207
Empregado
salário
chefe
{Empregado.salário
<
Empregado.chefe.salário}
Janela
comprimento
largura
{0,8<=comprimento/largura<=1,5}
Cargo
prioridade
{prioridade
nunca
cresce}
1..*
1
Janela
Tela
Visível
em
{ordenado}
*

208. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições:
exemplos
diversos
easo5ware,
ufpa,
2015
208
Pessoa
Nome
Endereço:
{
Logradouro;
Bairro;
Cidade.
}
Sexo
marido
esposa
0..1
0..1
casamento
Data
Regime
{pessoa.sexo=Feminino}
{pessoa.sexo=Masculino}

209. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições:
exemplos
diversos
easo5ware,
ufpa,
2015
209
Pessoa
Nome
Endereço:
{
Logradouro;
Bairro;
Cidade.
}
Sexo
cônjuge
0..1
0..1
casamento
Data
Regime
{pessoa.sexo
<>
pessoa.cônjuge.sexo}

210. www.labes.ufpa.br
Diagrama
de
Classes
Restrições:
exemplos
diversos
easo5ware,
ufpa,
2015
210

211. www.labes.ufpa.br
Diagrama
de
Classes
easo5ware,
ufpa,
2015
211
Pessoa
=
{
joão,
maria,
márcio,
fulano,
beltrano}
Condomínio
=
{
Greenville
I,
Greenville
II,
Costa
e
Silva
}
condômino
=
{
(joão,
greenville
I),
(maria,
greenville
II),
(márcio,
greenville
II),
(fulano,
costa
e
silva),
(beltrano,
costa
e
silva)
}
Síndico
=
{
(joão,
greenville
I),
(márcio,
greenville
II),
(fulano,
costa
e
silva)
}
Pessoa Condomínio
condômino
síndico
*
{subconjunto}
0..1

212. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições
easo5ware,
ufpa,
2015
212
Conta
Bancária
número
saldo
dataAbertura
criar()
bloquear()
desbloquear()
creditar()
debitar()
Pessoa
nome:
Str
endereço:
{
logradouro:
Str,
bairro:
Str,
cidade:
Str.
}
telefones:
Array
of
Int
1..*
*
corren9sta
9tular
{subconjunto}
*

213. www.labes.ufpa.br
Diagrama
de
Classes
easo5ware,
ufpa,
2015
213
Conta
Bancária
número
saldo
dataAbertura
Pessoa
nome:
Str
endereço:
{
logradouro:
Str,
bairro:
Str,
cidade:
Str.
}
telefones:
Array
of
Int
1..*
*
corren9sta
9tular
{subconjunto}
*
Conta
Bancária
=
{
001,
002,
003
}
Pessoa
=
{rodrigo,
carla,
fulana
}
Corren9sta
=
{
(001,
carla),
(002,
rodrigo),
(001,
rodrigo)
(001,
fulana)
(003,
fulana)
(003,
rodrigo}
Titular
=
{
(001,
rodrigo),
(002,
rodrigo)
,
(003,
rodrigo),
(001,
carla)
}

214. www.labes.ufpa.br
Diagrama
de
Classes
easo5ware,
ufpa,
2015
214
Conta
Corrente
número
saldo
dataAbertura
PessoaJurídica
nome:
Str
1..*
*
corren9sta
9tular
{subconjunto}
*
1
PessoaFísica
Representante
1..*
*

215. www.labes.ufpa.br
Diagrama
de
Classes
easo5ware,
ufpa,
2015
215
Aluno
Turma
1..*
representante
*
{subconjunto}
Exemplo
válido:
Aluno
=
{
amanda
,
breno
}
Turma
=
{01,
02}
Representante
=
{
(amanda,
01),
(amanda,
02)
}
Membro
=
{
(amandav,
01),
(amanda,
02),
(breno,
01)
}
1..*

216. www.labes.ufpa.br
Diagrama
de
Classes
• Transmutação
ou
Metamorfose
de
Objetos
– Monitor,
Professor,
Aluno:
herança
easo5ware,
ufpa,
2015
216
Pessoa
AlunoProfessor
Monitor

217. www.labes.ufpa.br
Diagrama
de
Classes
• Transmutação
ou
Metamorfose
de
Objetos
– Monitor,
Professor,
Aluno:
herança
• Problemas
– Acomodação
inábil
de
objetos
que
mudam
de
classes
easo5ware,
ufpa,
2015
217
Pessoa
AlunoProfessor
Monitor