Processo Unificado
Marcio de Carvalho Victorino
[email protected]
Unidade IV: Análise OO
(Aspectos Estáticos)
Modelo de Classes

O Modelo de Classes evolui durante as iterações do
desenvolvimento do sistema. À medida que o
sistema é desenvolvido, o Modelo de Classes é
incrementado com novos detalhes. Há três níveis
de abstração pelos quais o Modelo de Classes
passa:



Modelo de Classes de Domínio.
Modelo de Classes de Especificação.
Modelo de Classes de Implementação.
3
Modelo de Classes

Modelo de Classes de Domínio:



Representa as classes de domínio do negócio em
questão.
É construído durante a atividade de análise das iterações.
Não leva em consideração restrições inerentes à
tecnologia a ser utilizada na solução de um problema.
4
Modelo de Classes

Modelo de Classes de Especificação:




É uma extensão do Modelo de Classes de Domínio.
Possui detalhes específicos inerentes a solução de
software escolhida.
São definidas novas classes necessárias para desenvolver
a solução do problema.
É construído na atividade de projeto das iterações.
5
Modelo de Classes

Modelo de Classes de Implementação:



É uma extensão do Modelo de Classes de Especificação.
Corresponde à implementação das classes em alguma
linguagem de programação, normalmente OO.
É construído na atividade de implementação das
iterações.
6
Diagrama de Classes


Os diagramas de classes também podem conter
pacotes ou subsitemas, utilizados para agrupar
elementos do seu modelo em um conjunto maior.
Elementos de UML presentes nos Diagramas de
Classes:





Classes, suas estruturas internas e comportamento;
Interfaces;
Associações, agregações, dependências, e relações de
herança;
Multiplicidade e indicadores de navegação;
Nomes de papéis (O que uma classe representa para
outra).
7
Classes
Nome da Classe
ContaBancaria
ContaBancaria
numero
saldo
dataAbertura
ContaBancaria
numero
saldo
dataAbertura
creditar()
debitar()
Atributos
Operações
3 formas de representar classes
8
Relacionamentos



Ao construir modelo de classe você irá descobrir
que há um numero muito pequeno de classes que
trabalham sozinhas.
Ao fazer modelagem de um sistema é preciso ver
como os itens relacionam-se entre si.
Três tipos especialmente importantes:



Dependência - que representa relacionamento de
utilização entre as classes.
Generalização - que relacionam classes generalizadas a
suas especializações.
Associações - representam relacionamentos estruturais
entre objeto.
9
Dependência
ContaBancaria
ObjValor
public class ContaBancaria {
private int numero;
private float saldo;
private Date dataAbertura;
public void creditar(ObjValor valor) {
.
.
.
}
}
10
Generalização
public class ContaBancaria {
private int numero;
private float saldo;
private Date dataAbertura;
ContaBancaria
numero
saldo
dataAbertura
public void creditar(ObjValor valor) {
.
.
.
}
creditar()
debitar()
}
Poupanca
variacao
public class Poupanca extends ContaBancaria {
private int variacao;
.
.
.
}
}
11
Associação
nome da associação
Empresta de
Pessoa
Banco
papéis na associação
Pessoa
devedor
credor
Banco
multiplicidade da associação
Pessoa
1..*
*
Banco
12
Associação: Multiplicidade



Não Especificado
Exatamente um
Zero ou mais (vários,
ilimitado)
1
0..*
*


Um ou mais
Zero ou um
1..*
0..1


Intervalo especificado
Intervalos múltiplos
2..4
2, 4..6
13
Associação
Cliente
Movimenta
1
*
ContaBancaria
public class Cliente {
private String nome;
private long cpf;
private ContaBancaria contas[ ];
.
.
.
}
14
Associação: Classe Associativa
Pessoa
nome
telefone
endereco
empregado
empregador
*
*
Empresa
rezaoSocial
endereco
Emprego
salario
dataContratacao
15
Associação: Classe Associativa
Pessoa
nome
telefone
endereco
Emprego
1
salario
*
dataContratacao *
Empresa
rezaoSocial
1
endereco
16
Associação Reflexiva
Supervisao
supervisor
1
Empregado
nome
telefone
endereco
*
supervisionado
17
Agregação
Banco
1..*
*
Cliente
18
Composição
Banco
1
*
Filial
19
Agregação & Composição
Banco
*
1
Filial
1..*
*
Cliente
20
Responsabilidades & Colaborações

Costuma-se categorizar os objetos de um sistema
de acordo com o tipo de responsabilidade a ele
atribuída.




objetos de entidade
objetos de controle
objetos de fronteira
Esta categorização foi proposta por Ivar Jacobson
(Jacobson et al, 1992) em uma técnica denominada
Análise de Robustez.
21
Objetos de Entidade




Um objeto de entidade é um repositório para
alguma informação manipulada pelo sistema.
Esses objetos representam conceitos do domínio do
negócio.
Normalmente esses objetos armazenam
informações persistentes.
Há várias instâncias de uma mesma classe de
entidade coexistindo no sistema.
22
Objetos de Fronteira




Esses objetos traduzem os eventos gerados por um
ator em eventos relevantes ao sistema.
Também são responsáveis por apresentar os
resultados de uma interação dos objetos em algo
inteligível pelo ator.
Um objeto de fronteira existe para que o sistema se
comunique com o mundo exterior.
Por conseqüência, estes objetos são altamente
dependentes do ambiente.
23
Objetos de Controle



São a “ponte de comunicação” entre objetos de
fronteira e objetos de entidade.
Responsáveis por controlar a lógica de execução
correspondente a um caso de uso.
Decidem o que o sistema deve fazer quando um
evento externo relevante ocorre.


Eles realizam o controle do processamento
Agem como gerentes (coordenadores, controladores)
dos outros objetos para a realização de um ou mais caso
de uso.
24
Divisão de responsabilidades

A categorização de responsabilidades implica em
que cada objeto é especialista em realizar um de
três tipos de tarefa:




se comunicar com atores (fronteira)
manter as informações do sistema (entidade)
coordenar a realização de um caso de uso (controle).
A importância dessa categorização está relacionada
à capacidade de adaptação do sistema a eventuais
mudanças
25
Divisão de responsabilidades
«entidade»
«fronteira»
«controle»
«entidade»
«entidade»
26
Classes Avançadas

Visibilidade (UML):

A visibilidade de uma característica indica se ela pode
ser utilizada por outras classes:




Público (+) – membros da classe são acessíveis por todos os
clientes.
Package (~) - membros da classe são acessíveis somente pelas
classes do mesmo pacote (package) e pela própria classe.
Protegido (#) – membros da classe são acessíveis somente por
subclasses e pela própria classe.
Privado (-) - membros da classe são acessíveis somente pela
própria classe.
27
Classes Avançadas

Escopo:

O escopo da propriedade especifica se uma
característica aparece em cada instancia da classe ou se
haverá uma única instancia da característica para todas
as instancias da classe:


Instância – cada instancia da classe mantém seu próprio valor
para a característica.
Static (Classe) – existe apenas um valor da característica para
todas as instancias do classificador.
28
Classes Avançadas

Elementos abstratos, herança e polimorfismo:




É comum especificar classes abstratas, significando que não
poderão apresentar instancias diretas. Na UML são
representadas por nome em itálico.
Generalização (herança) é usada para fazer a modelagem de
estruturas de classes com abstrações mais gerais no topo da
hierarquia e outras mais específicas na parte inferior.
Uma operação é polimórfica, significando que, em uma
hierarquia de classes, você pode especificar operações com
a mesma assinatura em pontos diferentes da hierarquia.
Você pode especificar uma operação abstrata escrevendo o
respectivo nome em itálico.
29
Diagrama de objetos



Além do diagrama de classes, A UML define um
segundo tipo de diagrama estrutural, o diagrama
de objetos.
Pode ser visto com uma instância de diagramas
de classes
Representa uma “fotografia” do sistema em um
certo momento.

exibe as ligações formadas entre objetos conforme
estes interagem e os valores dos seus atributos.
30
Exemplo (Diagrama de objetos)
Supervisao
supervisor
1
Empregado
nome
telefone
endereco
*
supervisionado
Aline
Empregado
: Empregado
João : Empregado
Rafaela : Empregado
Antônio : Empregado
José : Empregado
Lucas : Empregado
Maria : Empregado
31
FIM