capítulo 5: diagrama de classes: conceitos avançados responsabilidade agregação e composição...

Post on 18-Apr-2015

105 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Capítulo 5: diagrama de classes: conceitos avançados

Responsabilidade Agregação e composição Interfaces e classes abstratas Objeto de referencia e objeto de valor Classificação e generalização Classes de associação Enumerações Visibilidade

Responsabilidade

Uma responsabilidade é um contrato ou obrigação de uma

Um bom ponto de partida para a definição de uma classe é definição de suas responsabilidades.

Responsabilidades representam os conhecimentos e as ações que possibilitam a uma classe cumprir seu papel.

Os atributos e operações podem ser vistos como aspectos ou características através das quais as responsabilidades são cumpridas

Freqüentemente, é útil mostra as responsabilidades (página 75) de uma classe em um diagrama de classe. A melhor maneira de mostra-lás é como frases de comentário em seu próprio compartimento na classe (figura 5.1). Se quiser , você pode dar um nome ao compartimento, mas eu normalmente não faço isso pois raramente exigira alguma confusão. Livro texto: UML Essencial 3ª edição, página 78

Cartões CRC

FIGURA 5.1 Mostrando responsabilidades em um diagrama de classes

Responsabilidades são descritas como frases ou parágrafos curtos em formato textual livre.

Podem ser documentadas em um compartimento específico, como parte da descrição da classe ou como uma nota estereotipada como <<responsabilidade>> ligada a classe.

Exemplo:

BRUNO

OPERAÇÕES E ATRIBUTOS ESTÁTICOS

Agregação e Composição

Ambos descrevem relações entre objetos...

...porém com uma diferença simples:Agregação Um objeto contém uma lista

de outros objetos. Os objetos contidos podem

existir sem serem parte do objeto que os contém.

Exemplo: Carro -> Rodas. Você pode tirar as rodas do carro antes de destruí-lo e elas podem ser colocadas em outro carro.

Composição Um objeto contém uma lista

de outros objetos. Os objetos contidos não

fazem sentido fora do contexto do objeto que os contém.

Exemplo: Pedido -> Itens. Se você destruir o pedido, os itens são destruidos junto, eles não tem sentido fora do pedido.

Uma das fontes de confusão mais freqüentes na UML á a agregação e a composição. É fácil explica-las superficialmente: agregação é o relacionamento “parte de” . É como dizer que um carro tem um motor e rodas como suas partes.Isso soa bem, mas o difícil é considerar qual é a diferença entre agregação e associação

Livro texto: UML Essencial 3ª edição, página 78

•Se as duas classes interagem na forma”todo-parte”, temos uma agregação

•Muitas vezes depende do domínio do problema

•Que tipo de relacionamento modela um carro e seus pneus ? na aplicação de uma oficina, onde os serviços

podem se estender aos pneus Agregação

na loja de vendas de pneus, onde o importante é saber que carro usa qual pneu associação

Associação ou Agregação ?

a agregação é estritamente sem significado; como resultado, recomendo que vocês a ignorem em seus diagramas. Se você a encontrar nos diagramas de outras pessoas, precisará ir mais a fundo para descobrir o que elas querem dizer com isso.Diferentes autores e equipes a utilizam para propósitos muito distintos

Livro texto: UML Essencial 3ª edição, página 80

Composição

Composição é uma forma de agregação com posse forte e tempo de vida idêntico.

Um objeto só pode participar de uma composição.

Cada parte só pode fazer parte de um todo( a regra do “não compartilhamento” é a chave da composição)

A regra geral é que, embora uma classe possa ser um componente de muitas outras classes, toda instancia deve ser um componente de apenas um proprietário. O diagrama de classe pode mostrar varias classes de proprietários em potencial, mas toda entrância tem apenas um único objeto como seu proprietário.

Livro texto: UML Essencial 3ª edição, página 79

BRUNO

Propriedades Derivadas

EU

Interfaces e Classes Abstratas

BRUNO

Read-onlye Frozen

Objetos de referencia e objetos de valor

“Uma coisa comumente ditas a respeito dos objetos é que eles tem identidade...”

...”na pratica,você verifica que a identidade é importante para objetos de referência,mais nem tanto para objetos de valos.”

TIPOS Por Valor (Value Types)

Armazenado na memória Stack. Trabalha com dados diretamente. Não pode ser nulo. Exemplo: Inteiros Decimais Booleanos Estruturas Enumerações

Se você tem duas datas e quer ver se elas são as mesmas não examina as suas identidades, mais sim os valores que elas representam.

Por Referência (reference types)

Contém uma referência a um ponteiro na memória Heap.

Pode ser nulo Exemplo: Vetores Textos Instâncias de Classes Classes

Os objetos por referencia são coisas como um cliente. Aqui, a identidade é muito importante, pois você normalmente só quer um objeto se software para designar um cliente no mundo real. Qualquer objeto que faça referencia a um objeto cliente fará isso por intermédio de uma referencia ou ponteiro.

Livro texto: UML Essencial 3ª edição, página 84

A UML utiliza a noção de tipo de dados, que é mostrada como uma palavra chave no símbolo de classe. Rigorosamente falando o tipo de dado não é o mesmo que objeto de valor, pois os tipos de dados não podem ter identidades . Os objetos de valor podem ter uma identidade, mais não a utilizam para a comparação de igualdade. Em java as primitivas seriam tipos de dados, mais as datas não seriam, embora elas sejam objetos de valor.

se é importante destaca-las, eu uso composição ao associar com objeto de valor, você também pode utilizar as palavras-chaves em um tipo de valor; as convencionais comuns que vejo são << value>> e << struct>>

Livro texto: UML Essencial 3ª edição, página 84

BRUNO

Associações Qualificadas

Classificação e Generalização

Relação semântica “is a” (“é um” / “é uma”): um aluno é uma pessoa.

A expressão é um pode significar coisas diferentes

1. Shep é um Border Collie.

1. Um Border Collie é um cachorro

1. Cachorro são animais

1. Borde Collie é uma Raça

1. Cachorro é uma Espécie

Combinando as frases

1 e 2 ) Shep é um cahorro

2 e 3) Border Collies são animais

1 , 2 e 3) Shep é um animal

Estas não estão corretas

1. Shep é um Border Collie.

1. Um Border Collie é um cachorro

1. Cachorro são animais

1. Borde Collie é uma Raça

1. Cachorro é uma Espécie

1 e 4) Shep é uma raça

2 e 5) Um Border Collie é uma Espécie

Classes de Associação

classe de associação possui as propriedades de classes e de associações:

A classe de associação permitem que você acrescente atributos, operações e outras característica a associações como mostra na figura 5.12.

Livro texto: UML Essencial 3ª edição, página 87

A implementação de classes de associação não é terrivelmente obvia. Meu conselho é implementar uma classe de associação como se ele fosse uma classe completa, fornece métodos que obtenham informações para as classes vinculadas pela classe associação.

Class Pessoa List obterComparecimento()

List obterReunião()

Tornar comparecimento uma classe concreta

Enumerações

São usadas para mostrar um conjunto fixo de valores que não possuem quaisquer propriedade além do seu valor simbólico.

Elas são mostradas como a classe com a palavra <<enumeration>>

BRUNO

Classes Ativas

Visibilidade

A visibilidade é um assunto que é simples em princípios mais tem sutilezas complexas

A UML tenta abordar o tema sem entrar em uma terrível confusão. Basicamente dentro da UML, você pode rotular qualquer atributo ou operação com um indicador de visibilidade. Você pode usar o marcador que quiser, e seu significado é dependente da linguagem. Entretanto, a UML fornece quatro abreviações para visibilidade; + (público), - (privado), ~(pacote), # (protegido).esses quatro níveis são usados dentro da UML e são definidos dentro dele, mas suas definições variam sutilmente daquelas das outras linguagens.

Livro texto: UML Essencial 3ª edição, página 92

Escopo Private ( - ): dentro de uma classe;

Escopo Package ( ~ ): dentro do mesmo pacote;

Escopo Public ( + ): dentro de um sistema;

Escopo Protected ( # ): dentro de uma árvore de herança.

Visibilidade Privada: um elemento privado é visível apenas dentro do namespace que o possui. Ex.: Os atributos privados da Classe B só podem ser acessados por operações realizadas por objetos da Classe B. Eles não seriam acessíveis a Classe A, a outras classes no mesmo pacote ou a quaisquer classes no Pacote 2, ou em qualquer outro lugar do sistema;

Visibilidade de pacote: um elemento do pacote (package) é possuído por um namespace que não é um pacote, e é visível aos elementos que estão no mesmo pacote do namespace que o possui. Ex.: A Classe B define uma operação com visibilidade de pacote. A visibilidade de pacote permite que uma operação na Classe A e os objetos de qualquer outra classe do Pacote 1 invoquem a operação em nível de pacote na Classe B;

Visibilidade pública: um elemento público é visível a todos os elementos que podem acessar o conteúdo do namespace que o possui;

Visibilidade protegida: um elemento protegido é visível aos elementos que possuem um relacionamento de generalização com o namespace que o possui. Ou seja, a visibilidade protegida permite o acesso pelas subclasses.

top related