Representação dos Elementos do Diagrama de classes

Após os levantamentos feitos na fase inicial, quando conhecemos os requisitos e domínio do sistema, escrevemos o diagrama de classes. Ele apresenta o sistema de forma estática e detalha quais classes e seus relacionamentos foram identificados no sistema a partir da aprovação do cliente.

Representação dos elementos do diagrama de classes

As classes na UML são representadas por um retângulo dividido em três partes (Figura 7.1):

a) na primeira temos o nome da classe;

b) na segunda temos os atributos da classe;

c) na terceira temos os métodos da classe.

Os atributos podem ser mostrados como:

Formato:

[visibilidade] nome do atributo: tipo

ou

b) uma associação (Figura 7.3):

Nesse exemplo Registradora possui uma associação com Venda chamada vendaAtual.

🔔 Normalmente usamos o elemento textual para representarmos tipos de dados simples (ou primitivos) disponíveis na linguagem de programação, por exemplo: inteiro, string, etc. Para representarmos estruturas como arrays, vetores, etc., usamos a associação.

Os métodos (ou operações) são mostrados na parte de baixo do símbolo de classe (Figura 7.4):

Formato:

[visibilidade] nome da operação (lista de parâmetros): tipo de retorno

Operações especiais que geralmente não aparecem nos diagramas:

a) criação de objetos (create): geralmente associada ao operador new. 

b) operadores de acesso: são os métodos get/set para acesso aos atributos.

Utilizamos a seguinte notação para a visibilidade de atributos e métodos:

+: public

-: private

#: protected

Podemos utilizar palavras-chave para caracterizar nossas classes.

<ator>

<<interface>> 

[abstract]

[ordered]

Utilizamos palavras-chave quando desenhamos as classes a mão, ou seja, sem o apoio de um software.

Para mostrar objetos do tipo Interface podemos utilizar o símbolo (Figura 7.5)

Ou então o símbolo tradicional de classe com a palavra-chave <> antes do nome da interface (Figura 7.6).

As coleções de objetos (arrays, vetores, etc.) podem ser mostradas como: 

a) um elemento textual (Figura 7.7)

Formato:

[visibilidade] nome do atributo: tipo [ocorrências]

b) uma associação (Figura 7.8)

Na Figura 7.8, Venda2 possui uma associação com LinhasDeItensdeVenda chamada linhaDeItens.

Usamos a representação gráfica da Figura 7.9 para inserir comentários em um diagrama de classes.

Uma generalização é mostrada com o símbolo,como mostrado na Figura 7.10.

Uma dependência é mostrada com uma linha (tracejada com uma seta partindo do cliente para o fornecedor) entre dois elementos, como mostrado na Figura 7.11.

Uma dependência indica qualquer tipo de visibilidade entre duas classes.

Veja o exemplo da Figura 7.12:

A composição e a agregação são usadas para representar as relações de “todo” e “parte” existentes entre alguns objetos.

Denominamos composição a relação na qual o objeto “todo” é constituído pelo objeto “parte”, de maneira que sem o objeto “todo” o objeto “parte” não tem sentido.

A Figura 7.13 apresenta uma composição:

A instância Endereço só faz sentido se houver uma instância correspondente de Cliente. Ou podemos perguntar: para que guardar um endereço se não sei a que cliente ele pertence?

Graficamente falando, a representação da composição contém um pequeno losango preenchido em um dos lados da linha horizontal que liga os dois retângulos.

Quando excluímos o objeto “pai”, destruímos também o objeto “filho”. No nosso exemplo, quando destruímos o objeto Cliente destruímos também o objeto Endereço.

A Agregação acontece quando usamos também um objeto “todo” e outro objeto “parte”; porém, a “vida” dos objetos é independente.

Veja o exemplo na Figura 7.14:

Observe que, nesse caso, a representação gráfica possui o losango NÃO preenchido. No exemplo da Figura 7.14, se eliminarmos o objeto LinhaPedido, não devemos eliminar a DescriçãoProduto. Faz sentido não eliminarmos a DescriçãoProduto pois esse objeto provavelmente deverá ser utilizado por outros objetos. Em termos de programação Java, a diferença entre composição e agregação é sutil e pode ser ignorada. 

Não se preocupe em utilizar agregação em seus projetos, utilize composição sempre que for apropriado.

Mapeamento objeto-relacional

Um dos problemas de se projetarem sistemas usando o paradigma de Orientação a Objetos é como implementar os objetos (que possuem informações a serem guardadas) em bancos de dados que não foram criados para este paradigma. Ou seja, os bancos de dados mais comumente encontrados no mercado são relacionais, e, portanto, trabalham com implementação de entidades e relacionamentos (modelo relacional), enquanto o produto gerado pelo desenvolvimento baseado em Orientação a Objetos produz objetos. Assim, precisamos converter os objetos, gerados nos diagramas de classes, em entidades e relacionamentos que poderão ser gerados dentro de um banco de dados relacional.

Os bancos de dados adequados para o desenvolvimento de aplicações OO são os SGBDOO (Sistemas Gerenciadores de Bancos de Dados Orientados a Objetos); porém, a indisponibilidade desses bancos de dados no mercado, seja devido ao custo, diversidade ou oferta, faz com que seja necessária a busca de técnicas específicas para a solução desse problema, para a criação de objetos em bancos de dados que usa entidades. 

Vamos conhecer essa técnica

Considere o diagrama de classe da Figura 7.12. Nele temos duas classes: Alunos e Curso. A associação entre eles informa que alunos fazem cursos. Esse diagrama pode ter sido gerado a partir de um diagrama de entidades e relacionamentos, onde: a entidade ALUNO equivale à classe Aluno e a entidade CURSO equivale à classe Curso. Para detalharmos melhor o diagrama de classes da Figura 7.12 podemos mostrar os atributos e métodos associados às classes Aluno e Curso.

Assim, cada tabela do banco de dados foi mapeada para uma classe, mantendo-se o mesmo nome da entidade (tabela) na classe.

No diagrama de classes, os atributos dessas classes possuirão visibilidade private, ou seja, somente os métodos internos à classe é que poderão acessá- -los diretamente. Para objetos externos acessarem esses atributos, é necessário utiliza get e set. Caso o atributo seja apenas de leitura não será preciso usar a propriedade set.

Até aqui transformamos as entidades em classes; porém, os relacionamentos ainda não foram tratados.

No nosso exemplo (Figura 7.12) temos o relacionamento do tipo 1:n (um para n). Assim, podemos ler o relacionamento da seguinte maneira: um aluno pode fazer um curso, porém um curso pode ser feito por vários alunos.

Para construir o relacionamento inserimos a chave estrangeira Curso.Codigo_ Curso na tabela Aluno associando-a à chave primária Codigo_Curso da tabela Curso. No diagrama de classes também temos os atributos Curso.Codigo_Curso e Código_Curso. Através de métodos específicos, preenchemos essas chaves e informamos a quais cursos estão ligados cada aluno registrado na tabela Aluno.

Resumo

Aprendemos nesta aula a representação gráfica do diagrama de classes. Apesar dos novos conhecimentos sobre cada elemento e conceito, é importante lembrarmos sempre da forma correta de representá-los, porque somente assim nossos diagramas poderão ser lidos e entendidos por todos que trabalham no desenvolvimento de um sistema.

Vimos que os conceitos estudados são todos provenientes da Orientação a Objetos e representam a relação existente entre as classes, objetos e suas especificações.

Nosso próximo passo é aprendermos como usar os padrões de projetos de acordo com os estudos e diagramas produzidos até esta aula. 

Jogo da Memória