O documento descreve como criar diagramas de classes de projeto (DCPs) utilizando a UML. Explica os tipos de visibilidade entre objetos e como representá-los na UML. Apresenta um estudo de caso sobre a criação de um DCP para um sistema PDV, ilustrando os passos de identificar classes, atributos, métodos, associações e detalhes.
Módulo 9 - Introdução à Programação Orientada a Objectos
Visibilidade e Diagrama de Classe de Projeto na UML
1. João F. M. Figueiredo www.joaomatosf.com [email_address] Departamento de Informática – UFPB
2.
3.
4. 1.1 Visibilidade entre objetos Figura 18.1 – A Visibilidade do Registro para o CatálogoDeProduto é exigida.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15. 2.2 Exemplo de DCPs Figura 19.1 – Amostra de diagrama de classe de projeto
16. 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
17.
18. 2.4 Criação De Um DCP Para o Estudo de Caso (2) Figura 19.3 – Classes de software na aplicação
19.
20.
21.
22.
23.
24.
25.
26.
27. João F. M. Figueiredo www.joaomatosf.com [email_address] Brian Departamento de Informática – UFPB
Notas do Editor
Habilidade de um objeto ver ou fazer referência a outro objeto. Inserir figura 18.1 Ao criar um projeto de objetos interativos, é necessário assegurar que a visibilidade necessária esteja presente para apoiar a interação da mensagem. A UML tem notação especial para ilustrar a visibilidade.
Habilidade de um objeto ver ou fazer referência a outro objeto. Inserir figura 18.1 Ao criar um projeto de objetos interativos, é necessário assegurar que a visibilidade necessária esteja presente para apoiar a interação da mensagem. A UML tem notação especial para ilustrar a visibilidade.
Na figura, temos a motivação para considerar a visibilidade: Para um A enviar uma mensagem para um objeto B, B deve ser visível para A. Há quatro meios comuns pelos quais pode ser alcançada a visibilidade de A para B.
A visibilidade por atributo de A para B, existe quando B é um atributo(variável de instância) de A. Persiste enquanto A e B existem. É uma forma bastante comum em sistemas OOP.
A visibilidade por parâmetro de A para B existe quando B é passado como um parâmetro para um método de A. Persiste somente dentro do corpo do método. É a segunda forma mais comum em OOP. Na figura, Registro já possui visibilidade para CatálogoDeProdutos por atributo, conforme o exemplo anterior, porém Venda não possui essa visibilidade. Então, quando a mensagem criarLinhaDeItem é enviada para Venda, uma instancia de EspecificaçãoDeProduto é passada como parâmetro. Assim, dentro do escopo criarLinhaDeVenda, venda tem visibilidade por parâmetro para CatalogoDeProduto. É comum esse tipo de visibilidade se transformar em visibilidade por atributo, usando o construtor para tal.
A visibilidade por parâmetro de A para B existe quando B é passado como um parâmetro para um método de A. Persiste somente dentro do corpo do método. É a segunda forma mais comum em OOP. Na figura, Registro já possui visibilidade para CatálogoDeProdutos por atributo, conforme o exemplo anterior, porém Venda não possui essa visibilidade. Então, quando a mensagem criarLinhaDeItem é enviada para Venda, uma instancia de EspecificaçãoDeProduto é passada como parâmetro. Assim, dentro do escopo criarLinhaDeVenda, venda tem visibilidade por parâmetro para CatalogoDeProduto. É comum esse tipo de visibilidade se transformar em visibilidade por atributo, usando o construtor para tal.
Visibilidade local de A para B existe quando B é declara como um objeto local dentro de um método de A. Persiste somente dentro do escopo do método; Terceira forma mais comum em sistemas OOP. Dois meios comuns pelos quais a visibilidade se realiza: Criar uma nova instancia e atribuir a uma variável local Atribuir o objeto que retorna de uma invocação de método para uma variável local Ex: //existe visibilidade local implícita para objeto ‘foo’ retornado via chama objterFoo umObjeto.obterFoo().executarBar();
Um objeto global é visível a todos Não uma boa forma de ter visibilidade Se for obrigado a ter objetos globais, é melhor usar o padrão de projeto Singleton (GoF) Existe visibilidade gloca de A para B quando B é global em A. Existe enquanto A e B existirem. Forma menos comum em sistemas OOP; Pode ser alcançada atribuindo-se uma instancia a uma variável global; Possíbel em C++ mas não em java. Normalmente se usa o padrão Objeto Unitário, que será tratado no proximo capitulo.
Objetivos do Capítulo! A UML tem notação para mostrar detalhes de projetos em diagramas de Classes. Ilustrar-se-á isso.
São diagramas mais detalhistas com relação ao software. Exibindo informações como métodos, por exemplos. São geralmente criados em paralelo com os diagramas de interação;
São diagramas mais detalhistas com relação ao software. Exibindo informações como métodos, por exemplos. São geralmente criados em paralelo com os diagramas de interação; Vale apena ressaltar que apartir das DCPs, pode-se gerar código em alguma linguagem de programação.
Conforme pode-se ver, nas dcps tem-se 3 caixas na definição de calsses. Uma delas define informações de tipos, a seguinte define os métodos. A navegabilidade também está disponível nas dcps. OBS: os parâmetros dos métodos não são especificados
Neste ponto, já pode-se perceber a diferença das DCPs para o MD. Para ambos, UML usa o diagrama de classes No modelo conceitual, uma entidade não representa uma classe de software mas um conceito do domínio do problema No diagrama de classes da fase de projeto, as classes são de software
Verificar os diagramas de interação para identificar as classes; Adicioná-las ao diagrama de classes, junto com os atributos; Não incluir classes que não participam da iteração atual. Localizar as mensagens para identificar os métodos das classes.
Verificar os diagramas de interação para identificar as classes; Adicioná-las ao diagrama de classes, junto com os atributos; Não incluir classes que não participam da iteração atual.
Analisar os diagramas de interação para descobrir os métodos de cada classe Alguns detalhes sobre métodos O método create() de UML não aparece em muitas linguagens, pois é uma chamada a um construtor Muitas vezes, não se incluem os métodos acessores (getAtributo() e setAtributo()) Se classes de bibliotecas (ex. Vector em Java) são mostrados no diagrama, não se precisa mencionar seus métodos Pode-se usar a sintaxe da linguagem de programação final, se desejado
Analisar os diagramas de interação para descobrir os métodos de cada classe Alguns detalhes sobre métodos O método create() de UML não aparece em muitas linguagens, pois é uma chamada a um construtor Muitas vezes, não se incluem os métodos acessores (getAtributo() e setAtributo()) Se classes de bibliotecas (ex. Vector em Java) são mostrados no diagrama, não se precisa mencionar seus métodos Pode-se usar a sintaxe da linguagem de programação final, se desejado
Este passo é opcional Se o diagrama de classes está sendo criado numa ferramenta CASE (ex. Rational Rose), e a ferramenta será usada para gerar código, todos os detalhes de tipos devem ser dados Se o diagrama for preparado apenas para leitura por desenvolvedores, o nível de detalhamento pode ser menor O seguinte diagrama contém toda a informação de tipo
A navegabilidade implica visibilidade da fonte para o destino Normalmente navegabilidade de atributo, incluída na implementação As associações devem ser apenas aquelas necessárias para a visibilidade de objetos Isso é diferente das associações no modelo conceitual, as quais podem ser incluídas para melhorar o entendimento Os diagramas de interação são usados para descobrir a visibilidade, associações e navegabilidade Situações comuns que levam a associações: A envia uma mensagem a B A cria uma instância de B A deve manter conhecimento de B Exemplo:
A navegabilidade implica visibilidade da fonte para o destino Normalmente navegabilidade de atributo, incluída na implementação As associações devem ser apenas aquelas necessárias para a visibilidade de objetos Isso é diferente das associações no modelo conceitual, as quais podem ser incluídas para melhorar o entendimento Os diagramas de interação são usados para descobrir a visibilidade, associações e navegabilidade Situações comuns que levam a associações: A envia uma mensagem a B A cria uma instância de B A deve manter conhecimento de B Exemplo:
Quando uma classe conhece outra (tem visibilidade), mas a visibilidade não é de atributo, usa-se uma linha tracejada Exemplo: TPDV recebe um objeto da classe EspecificaçãoDeProduto como retorno do método especificação da classe TPDV Diagrama de classes com dependências:
UML possui sintaxe para especificar: Visibilidade Valores iniciais etc. Exemplo:
UML possui sintaxe para especificar: Visibilidade Valores iniciais etc. Exemplo:
![João F. M. Figueiredo www.joaomatosf.com [email_address] Departamento de Informática – UFPB](https://image.slidesharecdn.com/slides-090929202420-phpapp02/85/Visibilidade-e-Diagrama-de-Classe-de-Projeto-na-UML-1-320.jpg)
![Sumário ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)