UML & Padrões Aula 2 1

(1)

UML & Padrões

(2)

UML – Diagrama de Classe

Ainda a tratar:

• Multiplicidade de Associações Binárias

• Navegabilidade de Associações

• Restrições

• Classes Concretas e Abstratas

• Atributos e Métodos Estáticos

• Classes Parametrizadas

• Interfaces

(continuação...)

(3)



muitos-para-muitos



muitos-para-um



um-para-um



Notação:



* - zero ou mais



1 - exatamente um



0..1 - zero ou um



1..* - um ou mais



1, 3..5 - um ou três a 5

UML – Diagrama de Classe

x

Partic. 1

*

Partic. 2

x

Partic. 1

*

1 Partic. 2

x

Partic. 1

1

1 Partic. 2

(4)

UML – Diagrama de Classe

Navegabilidade de Associações

As associações são classificadas quanto à navegabilidade em:

- bidirecionais

(normal)

-

unidirecionais

Pode-se indicar o sentido em que se lê o nome de uma associação

Class-1 Class-2 Class-1 Class-2 Empresa Pessoa Trabalha-para Emprega empregador empregado

(5)

UML – Diagrama de Classe

Restrições

Uma restrição especifica uma condição que tem de se verificar.

Uma restrição é indicada por uma expressão ou texto entre chaves ou por uma

nota posicionada junto aos elementos a que diz respeito, ou a eles ligada por

linhas tracejadas

(sem setas, para não confundir com relação de dependência).

OCL - "Object Constraint Language" - pode ser usada para especificar

restrições mais formalmente.

Pessoa nome dataNascimento localNascimento dataFalecimento dataFalecimento > dataNascimento

(6)

UML – Diagrama de Classe

Restrições em Associações

Fatura LinhaFatura * {ordered} 1

uma fatura é constituída por um conjunto ordenado de 0 ou mais linhas

Pessoa

Comité

Membro-de Diretor-de * * * 1 {subset}

(7)

UML – Diagrama de Classe

Restrições em Associações

Pessoa Empresa chefe _* ₁ empregado empregador trabalhador 0..1 *

Chefe possui nenhum

Conta Pessoa {or} Empresa associações mutuamente exclusivas

(8)

UML – Diagrama de Classe



Em geral, pode-se ter uma hierarquia de classes

relacionadas por herança / generalização



em cada classe da hierarquia colocam-se as propriedades que são

comuns a todas as suas subclasses



evita-se redundância, promove-se reutilização!

(9)

Hierarquias de classes

UML – Diagrama de Classe

CONSTRUTOR

(10)

Notações Alternativas para Hierarquias de classes

Pessoa

Aluno

Professor

Aluno

Professor

Pessoa

(11)

Classes e operações abstratas (



concretas)

Classes concretas são as que estamos acostumados a construir e gerar

objetos a partir delas. Uma classes abstrata ocorre quando a mesma

possui no mínimo um método abstrato.



Classe abstrata: classe que não pode ter instâncias diretas

 pode ter instâncias indirectas pelas subclasses concretas



Método abstrato: método com implementação a definir nas subclasses

 uma classe com métodos abstratos tem de ser abstrata



Notação : nome em

itálico

ou propriedade

{abstract}

(12)

Classes e operações abstratas

Fonte: The UML User Guide, Booch et al

UML – Diagrama de Classe

Circulo Retangulo Figura x: int y: int display() display() display()

Classe abstrata

(13)

Atributos e operações de classe (



instância)



Atributo de classe: tem um único valor para todas as instâncias (objetos) da

classe, o qual está definido mesmo que não exista nenhuma instância.

private static float taxa;



Método de classe: não tem como argumento implícito um objeto da classe

public static void atualizaTaxa(novaTaxa: float)



Notação: nome

sublinhado



Correspondem a membros estáticos (

static

) em C++ e Java

(14)

Conta número: int saldo: double taxa: float dataAniv : Date atualizaTaxa(novaTaxa: float) fazRender()

A taxa se aplica a todas as instâncias de Conta geradas

Altera o valor do atributo taxa da classe.

Todos os objetos da classe podem enxergar essa mudança.

Conta.atualizaTaxa(0.45);

Atributos e operações

de classe (



instância)

(15)

UML – Diagrama de Classe

Em uma empresa existem diversos funcionários, que são representados pelo seu nome,

endereço, cpf, cargo e salário. Entretanto, existem funcionários pagos via CLT, funcionários

que são PJ e funcionários que são comissionados. Esses tipos de funcionários têm caracterís-

ticas próprias como o desconto do FGTS do CLT, as horas e o valor das horas para os PJ e a

comissão para os comissionados.

Os funcionários têm maneiras diferentes de gerar seu salário, ou seja, apesar de todos

poderem calcular o salário, eles o fazem de maneiras diferentes.

 Defina o diagrama de classe para essa situação.

Imagine agora que cada funcionário tem seu salário ajustado através do comportamento

ajustarSalario() que varia de acordo com a taxa de reajuste, que vale para todos os objetos da

classe. Essa taxa entretanto varia para cada tipo de funcionário.

(16)

UML – Diagrama de Classe

Funcionario - nome : String - endereco: String - cpf : int - cargo : String - salário : double + calcularSalário() : double

Classe em itálico: classe abstrata

Método sem implementação:

método abstrato. FuncionarioCLT - desconto : double + calcularSalário() : double FuncionarioPJ - numHoras: double - valorHora: double + calcularSalário() : double FuncionarioCom - comissao: double + calcularSalário() : double

Exercício

Parte 1

(17)

UML – Diagrama de Classe

Funcionario - nome : String - endereco: String - cpf : int - cargo : String - salário : double + calcularSalário() : double

Classe em itálico: classe abstrata

Método sem implementação:

método abstrato. FuncionarioCLT - desconto : double - taxa : double + calcularSalário() : double + ajustarTaxa() : void FuncionarioPJ - numHoras: double - valorHora: double - taxa : double + calcularSalário() : double FuncionarioCom - comissao: double - taxa : double + calcularSalário() : double + ajustarTaxa() : void

Exercício

Parte 2

Atributo de classe: estático

(18)

UML – Diagrama de Classe

Classes Parametrizadas

Muitas linguagens – especialmente as fortemente tipadas – têm a noção de

Classes Parametrizadas ou Templates.

Também chamadas de classes Parametrizada, Genérica ou Gabarito.

Desse jeito pode-se definir comportamentos para conjuntos em geral definindo

uma classe gabarito Conjunto (Set).

(19)

UML – Diagrama de Classe

Classes Parametrizadas

Parâmetro Template (marcador) ClasseTemplate Conjunto + inserir(T) + remover(T)

T

<Empregado> Conjunto << bind >> < Empregado > Amarração de Parâmetro Elemento de Amarração

Este relacionamento indica que Conjunto de Empregados estará de acordo com a interface de Conjunto.

em termos de especificação, Conjunto de Empregados é um subtipo de Conjunto (mas sem a possibilidades de acrescentar propriedades ao elemento de amarração).

As classes parametrizadas são utilizadas, na maioria das vezes, para coleções.

(20)

Interfaces

UML – Diagrama de Classe

Def. Dicionário: dispositivo ou sistemas que entidades não relacionadas

utilizam para se comunicar.

Def. Desenvolvimento de Sistemas: quando estamos desenvolvendo uma

comunidade de entidades (classes) que interagem entre si, uma interface

representa a “cara” que uma dessas entidades pode mostrar a outra, ou seja,

que serviços ela fornece.

(21)

Interfaces



Um interface especifica um conjunto de operações externamente

visíveis de uma classe (ou componente, subsistema, etc.)



Todo atributo será público, estático e constante

.

UML – Diagrama de Classe

«

interface

»

InterfaceExemplo

+ operaçao1(): int

Um estereótipo UML é usado para indicar uma interface.

(22)

Notações alternativas para interfaces

«interface» InterfaceClass ImplementationClass ImplementationClass InterfaceClass operações ClientClass atributos operações atributos operações

ou

ClientClass

Interfaces

(23)



Uma classe de implementação pode ter várias interfaces



Vantagem em separar interface de implementação:

os clientes de uma

classe podem ficar a depender apenas da classe de interface em vez da classe

de implementação

Interfaces

UML – Diagrama de Classe

«interface»

SabeCantar

Classe1

«interface»

(24)

Interfaces

UML – Diagrama de Classe

Exemplo 1

Considere a classe abaixo:

Pessoa

A classe Pessoa é descrita em termos de características e comportamentos.

E se quiséssemos que ela se comportasse como um ser alado em um Mundo Alado ??

Se a classe é pensada isoladamente e simplisticamente, provavelmente,

pensaríamos na seguinte implementação:

Pessoa - nome - sexo - idade + fazAniversario (): void + casar(Pessoa p): boolean

(25)

Sistema A

Interfaces

UML – Diagrama de Classe

1. Poderíamos criar outra classe Pessoa com os comportamentos que o

sistema requeresse.

Mundo Alado Pessoa + voar() + pousar() Pessoa - nome - sexo - idade + fazAniversario (): void + casar(Pessoa p): boolean Passaros Aviao

(26)

Sistema A

Interfaces

UML – Diagrama de Classe

2. Posso manter classe atual e acrescentar os itens faltantes:

Mundo Alado Pessoa - nome - sexo - idade + fazAniversario (): void + casar(Pessoa p): boolean + voar() + pousar() Passaros Aviao

(27)

Sistema A

Interfaces

UML – Diagrama de Classe

3. Posso fazer com que minha classe se comporte como o outro sistema espera:

Mundo Alado <<interface>> serAlado + voar() + pousar() Pessoa - nome - sexo - idade + fazAniversario (): void + casar(Pessoa p): boolean Passaros Aviao

(28)

Interfaces

UML – Diagrama de Classe

Pessoa

Esse sistema não precisa do comportamento de Pessoa como uma classe descrita no sistema

A, apenas que objetos dessa classe se comportem como

seres alados

que possam voar e

pousar no Mundo Alado.

Objetos pessoa então deve estar em concordância com um protocolo de comportamento.

Não há necessidade do Sistema Mundo Alado conhecer a verdadeira classe Pessoa com

quem interage.

Qualquer classe que forneça implementação para as operações definidas na interface que o

sistema do Mundo Alado espera pode representar o papel de ser alado.

Mundo Alado

<<interface>> serAlado

Aviao

(29)

Interfaces

UML – Diagrama de Classe

Exemplo 2:

Agora imagine uma classe ContaBancaria, que possui o comportamento de criarConta,

bloquear, desbloquear, creditar, debitar,...

Existem, claramente, comportamentos que só podem ser executados pelo cliente

(dono da conta) e comportamentos que são restritos do gerente da conta.

O Cliente manipula apenas o que ele consegue ver através da interface

ContaManipulável.

 Mas ele não pode criar uma conta no banco sozinho, ou bloqueá-la ou mesmo

<<interface>> ContaManipulável +creditar() +debitar() ContaBancária

cliente

(30)

Interfaces

UML – Diagrama de Classe

Cliente Gerente <<interface>> Administrável +criar() +bloquear() +desbloquear() ContaBancária -numero -saldo +criar() +bloquear() +desbloquear() +creditar() +debitar() <<interface>> Manipulável +creditar() +debitar()

(31)

UML – Diagrama de Classes

Exercícios:

E uma empresa, um cliente é conhecido pelo seu nome, endereço, data da primeira e ultima compra e o total comprado. Há clientes específicos, que alem das características comuns

possuem ainda, no caso do Cliente PJ o nome do contato, uma lista de até 10 telefones, seu CNPJ e uma lista de até 3 números de fax.

Outro tipo de cliente é o Cliente PF que possui ainda o numero do CPF e o numero do cartão de credito.

O cliente PJ interage com um ou vários empregados da empresa no momento de sua compra. Esses empregados são os representantes de vendas da empresa.

Tanto os clientes PJ e PF quanto o empregado devem implementar uma Interface conhecida como IPessoa.

(32)

UML – Diagrama de Classes

#creditoPermitido: Currency #nivelCredibilidade() -nome: String -endereco: String -dataPrimeiraCompra: Date -dataUltimaCompra: Date -totalComprado: Currency Cliente nomeContato: String telefones[1..10]: String CNPJ: String FAX[1..3]: String Cliente pessoa-jurídica colocarListaNegra() nome: String CPF: String numCartaoCredito Cliente pessoa-física Empregado representante de vendas _* IPessoa

Exercícios

1)

Empresa *

(33)

UML – Diagrama de Classes

Exercícios

Um avião possui um controlador de Vôo, que por si só, é uma classe bem complexa, tendo suas próprias características e comportamentos.

Avião pode ser representado por uma reunião de passageiros. E também como uma composição de no mínimo 1 até muitos motores.

Se o objeto avião deixar de existir, os objetos motores também não mais existirão. Já os passageiros, mesmo que o objeto avião seja destruído, continuarão a existir.

(34)

UML – Diagrama de Classes

Exercícios

* Avião 1..* Motor Passageiro ControladorVoo possui controla 1 *

(35)

UML – Diagrama de Classes

Observe um código em Java: public class Aviao {

ControladorVoo controller; ....

// isto é composição

Motor motor = new Motor();

// isto é agregação

public void add(Passageiro p){ p.embarc(this);

}

public void remove(Passageiro p){ p.desembarc(this)

}

// isto é uma associação

public void setControladorVoo (ControladorVoo controller); public ControladorVoo getControladorVoo ();

}

Composição é responsabilidade do próprio objeto. Por

isso Motor é inicializado dentro do Avião. E NUNCA poderá ser substituído por outro enquanto o Avião existir.

O controlador Voo controla vários aviões ao mesmo tempo. Ele funciona como um observador do avião, e os dois se comunicam. Assim, apenas um controlador é setado para cada avião, mas vários aviões podem

estar associados ao mesmo controlador.

O passageiro está dentro do avião, mas depois ele sai. O passageiro não pertence ao avião e não pode estar em dois aviões ao mesmo tempo. Portanto é uma

(36)

(37)

UML – Diagrama de Objetos



É uma variação do diagrama de classes e utiliza quase a mesma notação, com

duas exceções: os objetos são escritos com seus nomes sublinhados e todas as

instâncias num relacionamento são mostradas.



A diferença é que o diagrama de objetos apresenta os atributos com valores e

mostra os objetos que foram instanciados das classes. É como se fosse o perfil do

sistema em um certo momento de sua execução.

Considere o diagrama de classes abaixo:

-matrícula: String -nome: String Professor -codDisciplina: String -descrição: String -codTurma: String Curso -matrícula: String -nome: String -período: Integer Aluno 0..10 ministra 1..5 * 1..3

(38)

UML – Diagrama de Objetos

p2: Professor matricula: "205-6712-09"

nome: "Jaelson Castro" p1: Professor codCurso: "IF291" descrição: "MPS" codTurma: I7 : Curso codCurso: "IF185" descrição: "AER" codTurma: I6 : Curso matricula: "219846534" nome: "Nelson Mandella"

:Aluno

matricula: "562746134" nome: "John Major"

:Aluno : Aluno : Aluno : Aluno : Aluno c1: Curso c2: Curso c3: Curso Bill: : Aluno : Aluno Lewinsky:

Nos diagramas de objetos, o objeto é representado por um retângulo com o nome sublinhado

objeto anónimo

classe não especificada

(39)

UML – Diagrama de Objetos



Os diagramas de objetos não são tão importantes como os diagramas de

classes, mas eles são muito úteis para exemplificar diagramas complexos

de classes ajudando muito em sua compreensão.



Também são usados como parte dos diagramas de colaboração, onde a

colaboração dinâmica entre os objetos do sistema é mostrada.

(40)

UML – Diagrama de Objetos

Exemplo: O professor Claudio que ministra a disciplina 0034 Lógica e

Programação na turma M45 possui três alunos. Marta e Celina são irmãs

e João entrou na faculdade recentemente sob matricula 201134, e

frequentam o terceiro período .

prof1: Professor matricula: nome: Claudio : Aluno matricula: nome: Celina período: 3 c1 : Curso codDisciplina: 0034

descrição: Lógica e Programação codTurma: M45 : Aluno matricula: 201134 nome: João período: 3 : Aluno matricula: nome: Marta período: 3 objeto anónimo