UML - parte 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

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
reﬁnar
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

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

–  Especiﬁcação
de
Requisitos

–  Arquitetura
de
so5ware

•  Exemplos
e
Exercícios
permeiam
a
disciplina

easo5ware,
ufpa,
2015
3

www.labes.ufpa.br

Orientação
a
Objetos

easo5ware,
ufpa,
2015
4

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

www.labes.ufpa.br

Antes
da
Orientação
a
Objetos

•  Programação
Estruturada

–  Muito
código
foi
desenvolvido
e
con9nua
operacional

–  Diﬁculdades
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

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

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

•  Modiﬁcações
tendem
a
ﬁcar
restritas
a
um
módulo

easo5ware,
ufpa,
2015
8

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

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.

www.labes.ufpa.br

Orientação
a
Objetos

•  Conceito:
Classe

–  Deﬁniçã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
deﬁnição
dos
dados)

easo5ware,
ufpa,
2015
11

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)

www.labes.ufpa.br

Orientação
a
Objetos

•  O
uso
de
computador
é
baseado
em
abstrações

–  Abstração:
representação
simpliﬁcada
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áﬁca
baseada
em
Mouse
e
Janelas

easo5ware,
ufpa,
2015
13

www.labes.ufpa.br

Orientação
a
Objetos

•  Abstrações

easo5ware,
ufpa,
2015
14

Booch,
1991

www.labes.ufpa.br

Orientação
a
Objetos

•  Conceito:
Encapsulamento

easo5ware,
ufpa,
2015
15

Booch,
1991

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

www.labes.ufpa.br

Orientação
a
Objetos


–  Inﬂuência
dos
circuitos

integrados

–  Podem
ser
livremente

combinados

–  Não
podem
ser

modiﬁcados

easo5ware,
ufpa,
2015
17

www.labes.ufpa.br

Orientação
a
Objetos

&
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

www.labes.ufpa.br

Orientação
a
Objetos

&
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”);

....

www.labes.ufpa.br

Orientação
a
Objetos

&
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;

www.labes.ufpa.br

Orientação
a
Objetos

•  Outros
elementos
importantes

–  Classiﬁcaçã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

www.labes.ufpa.br

Orientação
a
Objetos

•  Classiﬁcação

easo5ware,
ufpa,
2015
22

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

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

www.labes.ufpa.br

Orientação
a
Objetos

•  Generalização/Especialização

easo5ware,
ufpa,
2015
25

Classes

www.labes.ufpa.br

Orientação
a
Objetos

easo5ware,
ufpa,
2015
26


Funcionário

Proje9sta

Engenheiro

Gerente

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
Iden9ﬁer
-‐
OID)

•  O
OID
é
usado
para
deﬁnir
conexões
entre
objetos

easo5ware,
ufpa,
2015
27

www.labes.ufpa.br

Orientação
a
Objetos

•  Estado,
Comportamento
e
Iden9dade
de
Objetos

easo5ware,
ufpa,
2015
28
Estado
Comportamento
IdenJdade

www.labes.ufpa.br

Processo
de
Análise
e
Projeto

Orientado
a
Objetos

easo5ware,
ufpa,
2015
29

www.labes.ufpa.br

Orientação
a
Objetos

easo5ware,
ufpa,
2015
30

Problema

Análise
Orientada
a
Objetos

Solução

www.labes.ufpa.br

Orientação
a
Objetos

31

Processo
Top-‐Down

BD
Relacional

Classes
OO

Consulta
SQL

Métodos
(algoritmos)

easo5ware,
ufpa,
2015

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

www.labes.ufpa.br

O
Modelo
MPS
de
So5ware
e

seu
relacionamento
com

Análise/Projeto
de
Sistemas

easo5ware,
ufpa,
2015
33

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

www.labes.ufpa.br

Programa
MPS.BR

easo5ware,
ufpa,
2015
35

www.labes.ufpa.br

Níveis
de
Maturidade

easo5ware,
ufpa,
2015
36

www.labes.ufpa.br

Níveis
de
Maturidade
MPS-‐SW

37
easo5ware,
ufpa,
2015

www.labes.ufpa.br

Processo
GRE

easo5ware,
ufpa,
2015
38

www.labes.ufpa.br

Níveis
de
Maturidade
MPS

39
easo5ware,
ufpa,
2015

www.labes.ufpa.br

Processo
PCP

easo5ware,
ufpa,
2015
40

www.labes.ufpa.br

Processo
DRE

easo5ware,
ufpa,
2015
41

www.labes.ufpa.br

Um
rápido
histórico
da
UML

easo5ware,
ufpa,
2015
42

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:
uniﬁcação
em
torno
de
UML

43
easo5ware,
ufpa,
2015

www.labes.ufpa.br

Histórico
da
UML

•  Exemplos
de
Notações

–  Classes

easo5ware,
ufpa,
2015
44

Booch
Schlaer-Mellor
OMTCoad-Yourdon

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
uniﬁcação
em
torno
de
uma
única

notação

easo5ware,
ufpa,
2015
45

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

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

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
Uniﬁed

Process

easo5ware,
ufpa,
2015

48

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

www.labes.ufpa.br

Histórico
da
UML

•  James
Rumbaugh
(cont.)

easo5ware,
ufpa,
2015
50

www.labes.ufpa.br

Histórico
da
UML

easo5ware,
ufpa,
2015
51

Booch

Rumbaugh

OMT

Jacobson

OOSE

UML

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

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
Gamma, et al
HP Fusion
Operation descriptions and
message numbering
HP Fusion
message numbering
HP Fusion
message numbering
Embley
Singleton classes and
high-level view
Embley
high-level view
Embley
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

www.labes.ufpa.br

Histórico
da
UML

•  O
que
é
UML

–  Linguagem
visual
para
especiﬁcação
(modelagem)
de

sistemas
orientados
a
objetos

•  Fornece
representação
gráﬁca
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

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
Uniﬁcado

–  ...

•  Não
está
presa
a
uma
linguagem
de
programação

easo5ware,
ufpa,
2015
55

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

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

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

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

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.)

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

www.labes.ufpa.br

Falando
um
pouco
sobre

ferramentas
para
UML

easo5ware,
ufpa,
2015
62

www.labes.ufpa.br

•  Astah

Algumas
das
principais

ferramentas
na
atualidade

easo5ware,
ufpa,
2015
63

www.labes.ufpa.br

•  Astah

–  iPad

Algumas
das
principais

ferramentas
na
atualidade

easo5ware,
ufpa,
2015
64

www.labes.ufpa.br

•  Visual
Paradigm

Algumas
das
principais

ferramentas
na
atualidade

easo5ware,
ufpa,
2015
65

www.labes.ufpa.br

•  Enterprise
Architect

Algumas
das
principais

ferramentas
na
atualidade

easo5ware,
ufpa,
2015
66

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

www.labes.ufpa.br

Casos
de
Uso

Notação
da
UML
e
especiﬁcações
textuais

suplementares

easo5ware,
ufpa,
2015
68

www.labes.ufpa.br

Casos
de
Uso

•  Resumo

–  Um
caso
de
uso
é
uma
forma
especíﬁca
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
especiﬁcar
como
esse

comportamento
será
implementado.

easo5ware,
ufpa,
2015
69

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”

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
modiﬁcação
em
um
so5ware;

–  Cada
CDU
provê
um
ou
mais
cenários
que
descrevem

como
o
sistema
deve
interagir
com
seus
usuários
ﬁnais
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

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
deﬁne
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

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
iden9ﬁcar
requisitos
de
performance.

easo5ware,
ufpa,
2015
73

www.labes.ufpa.br

Casos
de
Uso

•  Casos
de
uso
servem
como
guia
para:

– Criação
e
validação
da
arquitetura
do
sistema.

– Deﬁniçã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

www.labes.ufpa.br

Modelagem
de
Casos
de
Uso

•  Notação
Gráﬁca

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

www.labes.ufpa.br

Modelagem
de
Casos
de
Uso

•  Notação
gráﬁca
(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

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

[Uniﬁed
So5ware
Development
Process
–
Jacobson,
Booch,
Rumbaugh]

www.labes.ufpa.br

“Valor
adicionado”

•  Perguntar
aos
clientes/usuários
o
que
eles
gostariam

que
o
sistema
ﬁzesse
não
funciona:

–  Lista
de
funcionalidades
que
pode
parecer
ú9l
a
princípio,

mas
na
verdade...

•  Ex:
modiﬁcar
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

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

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

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
insuﬁciente

–  Cada
caso
de
uso
encapsula
uma
coleção
de
cenários,

tanto
de
sucesso
como
de
falha.

easo5ware,
ufpa,
2015
81

Cliente
Realizar saque

www.labes.ufpa.br

Modelagem
de
Casos
de
Uso

•  Conceito
-‐
Ator

–  Qualquer
coisa
que
possui
interface
com
o
sistema
a
ser

desenvolvido

–  Deﬁnem
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)

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

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

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

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>>

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

www.labes.ufpa.br

Modelagem
de
Casos
de
Uso

•  Extensão

easo5ware,
ufpa,
2015
88

Servir entrada Servir sobremesa
Servir refeição
<<extend>>
<<extend>>

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

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

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

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

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>>
Iden9ﬁcar

des9natário

<<include>>

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

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

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>>

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>>

www.labes.ufpa.br

Modelagem
de
Casos
de
Uso

easo5ware,
ufpa,
2015
98

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

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

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

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

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

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

especiﬁcações
textuais

Atores Casos de Uso
Especificações de casos de uso
easo5ware,
ufpa,
2015
104

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

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

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
no9ﬁcar
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

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?

www.labes.ufpa.br

Especiﬁcação
detalhada
dos

casos
de
uso

easo5ware,
ufpa,
2015
109

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
ﬂuxos
de
eventos
e
outras
propriedades

–  Uniformizar
entendimento
entre
clientes,
usuários
e

equipe
de
desenvolvimento.

easo5ware,
ufpa,
2015
110

www.labes.ufpa.br

Especiﬁcando
casos
de
uso

•  Casos
de
uso
não
precisam
ser

especiﬁcados
todos
de
uma
vez

•  Casos
de
uso
devem
ser
priorizados
por

iteração

– Prioridade
técnica

– Prioridade
do
usuário

easo5ware,
ufpa,
2015
111

www.labes.ufpa.br

Especiﬁcação
de
um
caso
de
uso

•  Iden9ﬁcador

•  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

www.labes.ufpa.br

Iden9ﬁcaçã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

iden9ﬁcador.

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
iden9ﬁcar
o
caso
de
uso,
para

evitar
mal-‐entendidos

•  2
ou
3
linhas!

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.

www.labes.ufpa.br

Prioridades
de
casos
de
uso

easo5ware,
ufpa,
2015
116

•  Essencial
para
gerenciar
requisitos
e
para
montar

iterações

•  Deﬁnir
prioridade
de
todos
os
casos
de
uso

•  Exemplo
de
classiﬁcação
da
prioridade:

–  Essencial

–  Importante

–  Desejável

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

www.labes.ufpa.br

Pré
e
pós
condições:
exemplos

•  Caso
de
uso
“Entregar
pedido”

Os
itens
do
pedido
devem
exis9r

em
estoque

Os
itens
enviados
devem
ser

aba9dos
do
estoque.

•  Caso
de
uso
“Recadastramento
de
CPF”

o
usuário
deve
possuir
um
CPF

a
situação
do
contribuinte
é

atualizada.

easo5ware,
ufpa,
2015
118

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
ﬂuxos
secundários
depois!

easo5ware,
ufpa,
2015
119

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

www.labes.ufpa.br

Exemplo
de
um
ﬂuxo
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
suﬁciente
na
máquina?

Calma,
vamos
deixar
esses
detalhes
para
depois!

easo5ware,
ufpa,
2015
121

www.labes.ufpa.br

•  Pré-‐condição:
usuário
não
está
suspenso

•  1.
Usuário
solicita
um
item
do
acervo

•  2.
Funcionário
veriﬁca
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

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

www.labes.ufpa.br

Subﬂuxos
-‐
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

subﬂuxos
abaixo
é
executado.

easo5ware,
ufpa,
2015
124

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

www.labes.ufpa.br

Fluxos
secundários

•  Só
devem
ser
analisados
e
descritos
após
a

descrição
dos
ﬂuxos
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

www.labes.ufpa.br

Reuso
de
ﬂuxos
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

www.labes.ufpa.br

Resumo
–
Fluxos
de
eventos

easo5ware,
ufpa,
2015
128

•  Fluxo
normal
ou
básico
(“Happy
Path”)

–  Pode
conter
subﬂuxos

•  Fluxos
alterna9vos

–  Variações
regulares

–  Casos
incomuns

•  Fluxos
de
exceção

–  Tratam
situações
de
erro
do
ﬂuxo
básico.

www.labes.ufpa.br

Requisitos
não
funcionais

associados

•  Listar
RNFs
associados
ao
CDU
especíﬁco

–  Exemplos:

•  Tempo
de
resposta
(máximo
de
2
seg
para
100
transações

concorrentes)

•  Segurança:
Controle
de
acesso

•  …

easo5ware,
ufpa,
2015
129

www.labes.ufpa.br

easo5ware,
ufpa,
2015
130

www.labes.ufpa.br

Exemplo

easo5ware,
ufpa,
2015
131

www.labes.ufpa.br

easo5ware,
ufpa,
2015
132

Padrão
do
Ra9onal
Uniﬁed
Process

www.labes.ufpa.br

Modelagem
de
Casos
de
Uso

•  Comentário
Final

–  Os
casos
de
uso
são
elementos
muito
importantes
no

Processo
Uniﬁcado

–  Todas
as
a9vidades
de
desenvolvimento
são
organizadas

em
função
dos
casos
de
uso

easo5ware,
ufpa,
2015
133

www.labes.ufpa.br

Papel
do
Modelo
de
CDU
no

Processo

easo5ware,
ufpa,
2015
134
Fonte: Alexandre Vasconcelos - O Fluxo de Requisitos

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érﬂuo?

•  A
divisão
em
pacotes
do
modelo
de
caso
de
usos

está
apropriada?

easo5ware,
ufpa,
2015
135

www.labes.ufpa.br

Checklists:
Atores

•  Todos
os
atores
foram
iden9ﬁcados?

•  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

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
ﬂuxo
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

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

www.labes.ufpa.br

Encadeamento
dos
diagramas

da
UML

easo5ware,
ufpa,
2015
139

www.labes.ufpa.br

Processo
Simpliﬁcado

•  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
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

www.labes.ufpa.br

Processo
Simpliﬁcado

•  Relacionamento
entre
artefatos
(1)

easo5ware,
ufpa,
2015
141

Sistema
Usuário
XPTO
Diagrama
de
Casos

de
Uso

Tela de Geração
de Conta
Tela de Geração
de Conta
2: obter(s)
3: s
5: obterItens
6: itens
7: itens
10: obterPreço
11: preçoUnitário
13: quantidade
8: obterNome
9: nome
15: criar(s, itens)
16: conta
17: conta
14:
Diagrama
de
Sequência

e
Colaboração

Fornece
os

cenários

Valida
as
interações

www.labes.ufpa.br

Processo
Simpliﬁcado

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.

www.labes.ufpa.br

Processo
Simpliﬁcado

entre

Artefatos
(3)

easo5ware,
ufpa,
2015
143

Diagrama
de
Classes

Tela de Geração
de Conta
Tela de Geração
de Conta
2: obter(s)
3: s
5: obterItens
6: itens
7: itens
10: obterPreço
11: preçoUnitário
13: quantidade
8: obterNome
9: nome
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)

www.labes.ufpa.br

Processo
Simpliﬁcado

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
Realizado com
pagamento pendente
pagamentoEfetuado Realizado com
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)

www.labes.ufpa.br

Processo
Simpliﬁcado

entre
Artefatos
(5)

easo5ware,
ufpa,
2015
145

htp://www.voxxel.com.br/pages/introdiauml.html

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

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

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

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)

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

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

www.labes.ufpa.br

Diagrama
de
Classes


easo5ware,
ufpa,
2015
152

Livro
Pessoa

escrito
por

0..*
1..*

Multiplicidade da associação
Rótulo da associação

www.labes.ufpa.br

Diagrama
de
Classes


–  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..*

www.labes.ufpa.br

Diagrama

de
Classes


–  Classes:

•  Nome
de
“Coisas”

•  Rotuladas
no
Singular

–  Associações

•  Leitura
no
sen9do
“convencional”
(esquerda
para
direita,
de
cima

para
baixo)

easo5ware,
ufpa,
2015
154

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

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

www.labes.ufpa.br

Diagrama
de
Classes


–  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

www.labes.ufpa.br

Diagrama
de
Classes


–  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

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..*

www.labes.ufpa.br

Diagrama
de
Classes


–  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;

ﬂoat
saldo;

Date
dataAbertura;

Pessoa
9tular;

Vector
dependente;

}

Omi9dos
do
diagrama

por
simpliﬁcação

Os
atributos
que

Implementam
as

Associações
não
devem

Ser
inseridos
no
diagrama

www.labes.ufpa.br

Diagrama
de
Classes


–  Exemplos:
Associação
Unária

easo5ware,
ufpa,
2015
161

Funcionário
0..1
*
Supervisiona
Funcionário

João

supervisiona

É
supervisionado
por

www.labes.ufpa.br

Diagrama
de
Classes


–  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

www.labes.ufpa.br

Diagrama
de
Classes


–  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

www.labes.ufpa.br

Diagrama
de
Classes


–  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

www.labes.ufpa.br

Diagrama
de
Classes


das
Associações

•  Associação
binária
e
unidirecional

easo5ware,
ufpa,
2015
165

0..* trabalha
Funcionário

João

Departamento

Financeiro

www.labes.ufpa.br

Diagrama
de
Classes


das
Associações

•  Associação
Unidirecional

–  Razão
da
existência
è
mais
fácil
a
implementação

easo5ware,
ufpa,
2015
166

www.labes.ufpa.br

Diagrama
de
Classes


das
Associações

easo5ware,
ufpa,
2015
167

www.labes.ufpa.br

Diagrama
de
Classes


–  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

www.labes.ufpa.br

Diagrama
de
Classes

•  Exercício:
qual
o
mais
correto?

easo5ware,
ufpa,
2015
169

1 trabalha 0..1
0..* trabalha
0..* trabalha 0..*
(adaptado de BEZ02)

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

trabalha
1*
gerente 0..1

www.labes.ufpa.br

Diagrama
de
Classes

easo5ware,
ufpa,
2015
171

Funcionário
Departamento

Financeiro

TI

João

Marcela

Amanda

trabalha
1*
gerente 0..1

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

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

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

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

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

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

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)

Modiﬁcado

(Projeto)

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.

www.labes.ufpa.br

Diagrama
de
Classes

•  Classes
associa9vas

–  Classe
associa9va
subs9tuída
por
normal

easo5ware,
ufpa,
2015
180

www.labes.ufpa.br

easo5ware,
ufpa,
2015
181

www.labes.ufpa.br

easo5ware,
ufpa,
2015
182

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

www.labes.ufpa.br

easo5ware,
ufpa,
2015
184

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

www.labes.ufpa.br

Diagrama
de
Classes

•  Agregação

–  Exemplo

easo5ware,
ufpa,
2015
186

Associação

Espor9va

Equipe
Jogador

0..* 0..*
◀ afiliada

www.labes.ufpa.br

Diagrama
de
Classes


–  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
deﬁnir
hierarquias
de
classes
(não
de
objetos!)

que
possuem
propriedades
comuns

easo5ware,
ufpa,
2015
187

www.labes.ufpa.br

Diagrama
de
Classes


–  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)

www.labes.ufpa.br

Diagrama
de
Classes


–  Em
Ra9onal
Rose

easo5ware,
ufpa,
2015
189

Cliente

PF
PJ

www.labes.ufpa.br

Diagrama
de
Classes


–  Polimorﬁsmo
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

www.labes.ufpa.br

Diagrama
de
Classes


–  Polimorﬁsmo
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

www.labes.ufpa.br

easo5ware,
ufpa,
2015
192

www.labes.ufpa.br

Diagrama
de
Classes


–  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

www.labes.ufpa.br

Diagrama
de
Classes


–  Classe
Abstrata

•  Classe
que
não
instancia
objetos.

•  Serve
apenas
para
gerar
novas
sub-‐classes
a
par9r
da
herança.

•  Freqüentemente
é
uma
classe
ar9ﬁcial,
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

www.labes.ufpa.br

Diagrama
de
Classes


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

www.labes.ufpa.br

Diagrama
de
Classes


–  Em
Ra9onal
Rose

easo5ware,
ufpa,
2015
196

www.labes.ufpa.br

easo5ware,
ufpa,
2015
197

www.labes.ufpa.br

easo5ware,
ufpa,
2015
198

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

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

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

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?

www.labes.ufpa.br

Diagrama
de
Classes

•  Restrições

easo5ware,
ufpa,
2015
203

Signiﬁcado:
seja
uma
pessoa
(empregado),
seu
empregador
é
mesmo

do
seu
chefe

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..*

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)

www.labes.ufpa.br

Diagrama
de
Classes

•  Restrições

easo5ware,
ufpa,
2015
206

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)
}

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}

*

www.labes.ufpa.br

Diagrama
de
Classes

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}

www.labes.ufpa.br

Diagrama
de
Classes

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}

www.labes.ufpa.br

Diagrama
de
Classes

Restrições:
exemplos
diversos

easo5ware,
ufpa,
2015
210

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

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}

*

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)
}

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..*

*

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..*

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

www.labes.ufpa.br

Diagrama
de
Classes

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

www.labes.ufpa.br

Diagrama
de
Classes

ou
Metamorfose
de
Objetos

–  Solução
Geral:
Combinar
herança
e
associação

easo5ware,
ufpa,
2015
218

PapelPessoa
AlunoProfessor Monitor
Pessoa *
nome
cpf
dataNascimento
exerce
matrícula matrícula
1. Início: 01/02
2. Início: 01/11
Fim: 31/12
3. Fim: 31/12
4. Início: 01/01/próximo ano
0. criação
dataInicio

dataFim

www.labes.ufpa.br

Diagrama
de
Classes

•  Erros
Comuns

–  Usar
classes
ou
associações
para
representar
consultas
ou

operações
do
sistema
que
não
devem
ser
registradas

•  Exemplo
1

easo5ware,
ufpa,
2015
219

Usuário Acervo
consulta

www.labes.ufpa.br

Diagrama
de
Classes

•  Erros
Comuns

–  Usar
classes
ou
associações
para
representar
consultas
ou

operações
do
sistema
que
não
devem
ser
registradas

–  Exemplo
2

easo5ware,
ufpa,
2015
220

Usuário Consulta
faz *

www.labes.ufpa.br

Diagrama
de
Classes

•  Erros
Comuns

–  Iden9ﬁcar
métodos
nas
classes
sem
ter
feito
a
modelagem

temporal

easo5ware,
ufpa,
2015
221

O que é sintonizar?
- Quem usa?
- Quais os parâmetros?

www.labes.ufpa.br

Diagrama
de
Classes

•  Erros
Comuns

–  Inserir
atributos
quando
o
ideal
é
criar
uma
classe

easo5ware,
ufpa,
2015
222

Canal
EstiloMusical
Refere-se a
*

www.labes.ufpa.br

Diagrama
de
Classes

•  Erros
Comuns

–  Usar
herança
quando
a
quan9dade
de
9pos
é
grande
ou

dinâmica

easo5ware,
ufpa,
2015
223

EstiloMusical
Pagode Rock Axé
EstiloMusical
Nome: string

www.labes.ufpa.br

Diagrama
de
Classes

•  Erros
Comuns

–  Inserir
chaves-‐estrangeiras
no
diagrama
de
classes

•  As
associações
são
suﬁcientes

easo5ware,
ufpa,
2015
224

Funcionário
codFunc
codDepto
Depto
codDepto
...
trabalha
*
Chave primária? Usar OID!
Chave estrangeira? Redundante!

UML - parte 1

Mais conteúdo relacionado

Mais procurados (20)

Destaque (20)

Semelhante a UML - parte 1 (20)

Último (7)

UML - parte 1