João F. M. Figueiredowww.joaomatosf.com

j-joao@hotmail.comDepartamento de Informática – UFPB

Sumário1. Como Determinar a Visibilidade

1. A visibilidade entre objetos

2. Tipos de Visibilidade

3. Visibilidade na UML

2. Como Criar Diagramas de Classe de Projeto

1. Quando criar DCPs

2. Exemplo de DCP

3. Modelo de Domínio Versus Classes do Modelo de Projeto

4. Criação de um DCP para o PDV ProxGear(estudo de caso)

1.1 Visibilidade entre objetos

Definições: Possibilidade de Ver. (TheFreeDictionary) Medida da facilidade com que o objeto é encontrado.

(Enciclopédia Livre) Habilidade de um objeto ver ou fazer referência a outro objeto.

(Craig Larman, 2004)

mensagem

1.1 Visibilidade entre objetos

Figura 18.1 – A Visibilidade do Registro para o CatálogoDeProduto é exigida.

1.2 Tipos de Visibilidade

1.Visibilidade por atributo: B é atributo de A.

2.Visibilidade por parâmetro: B é um parâmetro de um método de A.

3.Visibilidade local: B é um objeto local(não-parâmetro) em um método de A.

4.Visibilidade global: B é, de certo modo, globalmente visível.

mensagem

1.2 Tipos de Visibilidade (2)

Visibilidade por Atributo

Figura 18.2 – Visibilidade por atributo

Visibilidade Por Parâmetro

1.2 Tipos de Visibilidade (3)

Figura 18.3 – Visibilidade por parâmetro

Visibilidade Por Parâmetro

1.2 Tipos de Visibilidade (4)

Figura 18.1 – A Visibilidade de parâmetro para atributo.

Visibilidade Local

1.2 Tipos de Visibilidade (5)

Figura 18.1 – Visibilidade local

Visibilidade Global

Um objeto global é visível a todos

Não uma boa forma de ter visibilidade

1.2 Tipos de Visibilidade (6)

Como Ilustrar Visibilidade na UML

1.3 Visibilidade na UML

Figura 18.6 – Implementação de estereótipos para visibilidade

2. Como Criar Diagramas de Classe de Projeto

Objetivos:

Criar Diagramas de Classes de Projeto (DCPs)

Identificar as classes, os métodos e as associações para mostrar em um DCP.

2.1 O que é e Quando Criar DCPs

Especifica as classes de software e as interfaces da aplicação; Não somente das entidades conceituais.

Normalmente criado em paralelo com os diagramas de interação.

2.1 O que é e Quando criar DCPs (2)

Informação tipicamente incluída: Classes, associações e atributosInterfaces, incluindo métodos e constantesMétodosInformação de tipo de atributosNavegabilidadeDependências

2.2 Exemplo de DCPs

Figura 19.1 – Amostra de diagrama de classe de projeto

2.3 Modelo de Domínio Versus Classes de Modelo de Projeto

Figura 19.2 – Modelo do domínio vs classes do modelo de projeto

2.4 Criação De Um DCP Para o Estudo de Caso

Identificar as classes que participam da solução de software.Verificar os diagramas de interação para identificar as

classes.

Desenhar um diagrama de classe para estas classes e incluir os atributos identificados.

2.4 Criação De Um DCP Para o Estudo de Caso (2)

Figura 19.3 – Classes de software na aplicação

2.4 Criação De Um DCP Para o Estudo de Caso (3)Acrescentar nomes de métodos

Figura 19.4 – Nomes de métodos a partir dos diagramas de interação

2.4 Criação De Um DCP Para o Estudo de Caso (3)Acrescentar nomes de métodos

Figura 19.5 – Métodos na aplicação

2.4 Criação De Um DCP Para o Estudo de Caso (4)Acrescentar informação de tipo

Figura 19.7 – Informação de tipo

2.4 Criação De Um DCP Para o Estudo de Caso (5)Acrescentar associações e navegabilidade

Figura 19.8 – Mostrar navegabilidade ou visibilidade do atributo

2.4 Criação De Um DCP Para o Estudo de Caso (5)Acrescentar associações e navegabilidade

Figura 19.10 – Associações com adorno de navegabilidade

2.4 Criação De Um DCP Para o Estudo de Caso (6)Acrescentar relações de dependência

Figura 19.10 – Relacionamentos de dependência que indicam visibilidade que não é implementada por atributo

2.4 Criação De Um DCP Para o Estudo de Caso (7)Incluir detalhes de membro de classes

Exemplo:

Figura 19.12 – Detalhes da notação de membro do diagrama de classes UML

3. Referências BibliográficasCraig Larman: Utilizando UML e padrões: uma introdução

à análise e ao projeto orientados a objetos e ao Processo Unificado. 2ed – Porto Alegre: Bookman, 2004.

João F. M. Figueiredowww.joaomatosf.com

j-joao@hotmail.comBrian

Departamento de Informática – UFPB