003 - classesdeespecificação

41
1 Modelagem de Classes de Especificação

Upload: michellynson-anderson-bryant

Post on 11-Jan-2016

18 views

Category:

Documents


0 download

DESCRIPTION

modelo de diagrama de classes

TRANSCRIPT

Page 1: 003 - ClassesDeEspecificação

1

Modelagem de Classes de Especificação

Page 2: 003 - ClassesDeEspecificação

2

Especificação de atributos

Análise e Projeto Orientado a Objeto

Page 3: 003 - ClassesDeEspecificação

3

Especificação de atributos

No modelo de classes de domínio, os atributos, quando são representados, o são somente pelo nome.

No entanto, a especificação completa de um atributo deve seguir a sintaxe:

[/] [visibilidade] nome [: tipo] [= valor-inicial]

Page 4: 003 - ClassesDeEspecificação

4

Sintaxe da UML para atributos

Visibilidade

Diz respeito ao nível de acesso do atributo. Isto é, quais atributos são acessíveis por outros objetos.

A propriedade de visibilidade serve para implementar o encapsulamento

Esta pode ser: Pública: qualquer objeto relacionado pode obter acesso ao atributo (é a

visibilidade default). Não use! Pois acaba com o encapsulamento. Representação: +

Protegida: só o próprio objeto e seus descendestes podem ter acesso ao atributo.

Representação: # Privada: só o próprio objeto tem acesso ao atributo.

Representação: -

Page 5: 003 - ClassesDeEspecificação

5

Sintaxe da UML para atributos

Nome Diz respeito ao nome do atributo

Este deve seguir um padrão e as regras de nomes de identificadores.

EX: certidaoCasamento, sexo, estadoCivil, dataNascimento, RG,...

Tipo Especifica o tipo do atributo.

Este é dependente da LPOO a ser usada.

Pode ser um tipo primitivo ou um tipo criado pelo usuário

EX: String, Cliente, Float, Endereco,...

Page 6: 003 - ClassesDeEspecificação

6

Sintaxe da UML para atributos

Valor Inicial Diz respeito a um valor inicial para o atributo.

Este é automaticamente definido quando o objeto é instanciado.

EX: saldo = 0, debitado = true,...

Atributo Derivado Especifica se o atributo pode ser obtido a partir do valor de outro(s)

atributo(s) (são definidos por questões de desempenho).

Representação : /

EX: /idade, /salarioLiquido,...

Page 7: 003 - ClassesDeEspecificação

7

Sintaxe da UML para atributos

Escopo de um atributo Diz se o atributo é do objeto ou da classe (estático).

Representação: Sublinha-se o atributo, quando este for da classe

EX: quantidadeClientes idadeMedia,...

Exemplo completo:

#nome : String-dataNascimento : Data-telefone : String#/idade : int#limiteCr…dito : Moeda = 500.0-quantidadeClientes : int-idadeM…dia : float

Cliente

Page 8: 003 - ClassesDeEspecificação

8

Especificação de operações

Análise e Projeto Orientado a Objeto

Page 9: 003 - ClassesDeEspecificação

9

Especificação de operações

Operação: um processamento realizado por (um objeto de) uma classe. Em termos de implementação: é uma rotina associada a uma classe.

Na construção do modelo de interações, operações identificadas na análise são validadas, e várias outras operações são identificadas. Essas operações devem ser adicionadas ao diagrama de classes e

documentadas através da definição de sua assinatura.

A especificação UML de uma operação tem pontos em comum com a de um atributo. Sua sintaxe básica é a seguinte:

[visibilidade] nome([parâmetros]): [tipo-retorno]

Page 10: 003 - ClassesDeEspecificação

10

Sintaxe da UML para operações Visibilidade

Aplica os mesmos conceitos usados em atributo (+,# e -) Definir os seletores (obter/get) e os modificadores (definir/set)

Nome Semelhante ao atributo, mas deve expressar uma ação

EX:obterNome(), definirTelefone(),... Parâmetros

São as informações recebidas e depois executadas pela operação Cada parâmetro tem a seguinte sintaxe:

nome_parâmetro: tipo_parâmetro

Page 11: 003 - ClassesDeEspecificação

11

Sintaxe da UML para operações

Tipo-retorno Semelhante a tipo de atributo. Pode ser primitivo ou criado pelo usuário. Nem todas as operações retornam um valor.

Escopo de uma operação Semelhante ao escopo de um atributo (objeto ou classe)

+obterNome() : String+definirNome(in umNome : String)+obterDataNascimento() : Data+definirDataNascimento(in umaData : Data)+obterTelefone() : String+definirTelefone(in umTelefone : String)+obterLimiteCr…dito() : Moeda+definirLimiteCr…dito(in umLimiteCr…dito : float)+obterIdade() : int+obterQuantidadeClientes() : int+obterIdadeM…dia() : float

Cliente

Page 12: 003 - ClassesDeEspecificação

12

Especificação de Relacionamentos

Análise e Projeto Orientado a Objeto

Page 13: 003 - ClassesDeEspecificação

13

Especificação de Relacionamentos

Na UML, há três tipos de relacionamentos entre objetos: Associações Dependências Generalizações

No modelo de classes de domínio, os relacionamentos entre objetos foram identificados como associações.

Observação: A consideração desses detalhes é mais adequada no modelo de

especificação, mas nada impede usá-los no modelo de domínio.

Page 14: 003 - ClassesDeEspecificação

14

De associações a agregações ou composições

Uma associação pode ser de dois tipos especiais: Agregação: um tipo de associação fraca entre um todo e suas partes Composição: Idem anterior, entretanto, existe uma forte associação.

Uma agregação pode ser definida já no modelo de domínio ou apenas no modelo de especificação. Todavia a definição de composições é mais adequada no modelo de especificação.

Agregação X Composição Agregação

Os obj. Partes são criados/destruídos independentemente do obj. Todo Um obj. Parte pode ser utilizado para compor diversos objs. Todos A destruição de um obj. Todo não implica na destruição dos objs. Parte

Composição Os objs. Parte pertencem a um único obj. Todo

Por isso, é também conhecida como agregação não-compartilhada Objs. Parte são sempre criados e destruídos pelo obj. Todo A destruição de um obj. Todo implica na destruição de um obj. Parte

Page 15: 003 - ClassesDeEspecificação

15

De associações a agregações ou composições

Mais exemplos de uma composição:

Composições (ou agregações) podem se estender por diversos níveis, formando hierarquias de composição (agregação).

Autom‘vel

Roda

Motor

1

4

1

1

CapŒtulo Se«√o Par¡grafo1 * 1 *

Page 16: 003 - ClassesDeEspecificação

16

Restrições sobre associações

Restrições podem ser adicionadas sobre uma associação para condicionar a forma pela qual a associação deve ser implementada.

Duas das restrições sobre associações predefinidas pela UML são: subset (subconjunto)

xor (ou exclusivo).

Page 17: 003 - ClassesDeEspecificação

17

Restrições sobre associações

EdifŒcioPessoa

1*

Reside

0..11

{subset}

Administra

Exemplo de restrições sobre associações :

Uma pessoa para administrar um edifício tem que residir neste

Page 18: 003 - ClassesDeEspecificação

18

Restrições sobre associações

{xor}ContaBanc¡ria

Pessoa

Institui«√o

* 1..*

*

1..*

Exemplo de restrições sobre associações :

Uma conta bancária é apenas de Pessoa ou de uma Instituição

Page 19: 003 - ClassesDeEspecificação

19

Navegabilidade de associações

Serve para indicar que um objeto “visualiza” (conhece) outro objeto associado a ele.

Associações, agregações e composições podem ser bidirecionais e unidirecionais. Uma associação bidirecional indica que há um conhecimento mútuo

entre os objetos associados. Por sua vez, Em uma associação unidirecional, apenas um objeto conhece o outro

Na UML, associações são, por omissão, navegáveis em ambos os sentidos.

Uma associação unidirecional é representada adicionando-se um sentido à seta da associação.

Page 20: 003 - ClassesDeEspecificação

20

Navegabilidade de associações

Exemplo de navegabilidade de associação

Esse diagrama indica que objs. de Pedido possuem, cada um, uma referência para um objeto Cliente.

Por outro lado, um obj. de Cliente não possui referências para objs. associados em Pedido

-nome : String-dataNascimento : Data-telefone : String-/idade : int-limiteCr…dito : Moeda = 500.0-quantidadeClientes : int-idadeM…dia : float

Cliente

+obterTotal() : Moeda

-data : Data-hora : Hor¡rio-situa«√o : ESitua«√o

Pedido

1 0..*

Realiza

Page 21: 003 - ClassesDeEspecificação

21

Navegabilidade de associações

No modelo de domínio, a navegabilidade da associação não é definida.

Entretanto, no modelo de classes de especificação, a navegabilidade de todas as associações deve ser definida. Isto facilita a implementação e manutenção do SW

Page 22: 003 - ClassesDeEspecificação

22

Implementando as associações

Para associações 1:1, a implementação é trivial: Defini-se apenas um atributo do tipo B na classe A.Se a navegabilidade for bidirecional: aplica-se o procedimento acima para as duas classes.

Portanto, em associações 1:1, não há necessidade de um refinamento adicional do diagrama de classes.

Todavia, em associações 1:N ou N:N, detalhes adicionais podem ser representados para esclarecer como implementar tais associações.

O detalhamento de associações se baseia em classes que representam coleções de elementos Ex. Classes Parametrizadas

Page 23: 003 - ClassesDeEspecificação

23

Classe Parametrizada

Uma coleção pode ser representada em um diagrama de classes através uma classe parametrizada (template) . Esta é uma classe genérica que é instanciada para obter outras classes

normais. Possui operações ou atributos cuja definição é feita em função dos

parâmetros.

Uma coleção pode ser definida a partir de uma classe parame-trizada, onde o parâmetro é o tipo do elemento da coleção.

Notações UML para uma classe parametrizada. Exemplo: classe parametrizada Lista:

Lista

Tipo

Lista<Tipo>

Page 24: 003 - ClassesDeEspecificação

24

Refinando associações 1:N

Classes parametrizadas são normalmente utilizadas para detalhar associações 1:N. Idéia básica: definir uma classe parametrizada cujo parâmetro é a

classe correspondente ao lado muitos da associação. A utilização da classe parametrizada resulta na transformação

de uma associação 1:N em uma associação 1:1. Formas alternativas para representar uma associação 1:N.

ListaT

ListaEmpregados

Empregado

Departamento

*

1

Departamento

1

1

Empregado

Lista<Empregado> Empregado

Departamento

1

1

Page 25: 003 - ClassesDeEspecificação

25

Herança

Relação de especialização entre DUAS classesUma delas corresponde a um conceito mais genéricoA outra, a um conceito mais específico

Page 26: 003 - ClassesDeEspecificação

26

Herança

Page 27: 003 - ClassesDeEspecificação

27

Herança É Unidirecional

Estudante de graduação é uma espécie de estudante, masestudante NÃO é uma espécie de estudante de graduação

Page 28: 003 - ClassesDeEspecificação

28

Níveis Hierárquicos de Herança

Page 29: 003 - ClassesDeEspecificação

29

Níveis Hierárquicos de Herança

Page 30: 003 - ClassesDeEspecificação

30

Restrições sobre Generalização/Especialização

Page 31: 003 - ClassesDeEspecificação

31

Restrições sobre Generalização/Especialização

Page 32: 003 - ClassesDeEspecificação

32

Restrições sobre Generalização/Especialização

Page 33: 003 - ClassesDeEspecificação

33

Restrições sobre Generalização/Especialização

Page 34: 003 - ClassesDeEspecificação

34

Restrições sobre Generalização/Especialização

Page 35: 003 - ClassesDeEspecificação

35

Papel e Herança

Evitar

Page 36: 003 - ClassesDeEspecificação

36

Herança de Operações e Polimorfismo

•Pode ser que um comportamento de alguma operação herdada seja diferente para a subclasse.

•Nesse caso, a subclasse deve redefinir o comportamento da operação.

•Entretanto, a assinatura da operação pode ser reutilizada pela subclasse.

•A subclasse deverá implementar o novo comportamento desejado e manter a assinatura original.

Page 37: 003 - ClassesDeEspecificação

37

Operações Polimórficas

•São operações de mesma assinatura definidas em diversos níveis de uma hierarquia de generalização e que possuem comportamento diferente.

•Essas operações devem ter a assinatura repetida na(s) subclasse(s) para indicar que elas estão sendo redefinidas.

Page 38: 003 - ClassesDeEspecificação

38

Operações Polimórficas

Page 39: 003 - ClassesDeEspecificação

39

Operações Abstratas

Page 40: 003 - ClassesDeEspecificação

40

Operações Abstratas

Page 41: 003 - ClassesDeEspecificação

41

Classificação Dinâmica