Descobrindo a Modelagem de Sistemas: Diagrama de Classes

Foto de fauxels no Pexels

Olá pessoal tudo bem? Dando sequência a nossa série, vamos conversar sobre um assunto clássico na modelagem de sistemas e também clássico para aqueles que já tiveram contato com a programação orientada a objetos alguma vez na vida. Vamos falar hoje do Diagrama de Classes.

A modelagem utilizando-se do diagrama de classes é feita para que, após discutida e definida, sejam gerados automaticamente os códigos fontes da lógica de negócios do sistema a ser desenvolvido.

Classes e Objetos:

As classes são a estrutura mais importante na construção de sistemas orientados a objetos — Booch, Rumbaugh e Jacobson (2005)

Uma classe é representada na UML através de um retângulo e é dividida em três partes:

• Nome da Classe;
• Atributos;
• Métodos

Veja uma representação gráfica tirada do livro Modelagem de Sistemas de João Paulo Casati da Universidade Estácio de Sá.

*Exemplo de classe com atributos e métodos tipados **

O nome da classe deve ser algo que represente uma entidade no sistema a ser modelado. Em um sistema bem simples de cadastro de clientes, pode-se destacar, por exemplo, a entidade “Cliente”.

Os atributos são as qualidades que um objeto possuirá quando instanciado seguindo o modelo de uma classe.

Já os métodos são as ações que um objeto instanciado pode executar, recebendo ou não parâmetros, retornando ou não valores.

Tenha atenção que o tipo declarado no método, significa o tipo de valor que será retornado, e quando não terá um retorno definimos esse método como do tipo void, por fim quando o método possui um valor dentro dos parênteses, significa que recebe um parâmetro para realizar uma execução.

Relacionamentos:

Os relacionamentos é a representação das interações entre as classes e eles podem ser de diversos tipos, que vamos apresentá-los abaixo:

• Herança;

• Associação;

• Agregação;

• Composição;

• Dependência.

Herança:

Uma herança também poderá ser chamado de generalização ou especialização, ela representa o relacionamento entre duas ou mais classes. Aqui o conceito de herança é bem semelhante ao que temos na vida real, ou seja, se definirmos que as classes A,B e C estão relacionadas entre si através de uma herança com o conceito de cascata, de forma automática saberemos que:

• A classe B herdará tudo da classe A;
• A classe C herdará tudo da classe B, inclusive as heranças ocorridas de A para B;

Veja mais um exemplo tirado do livro Modelagem de dados:

*Classes da herança de animais **

Aqui temos uma classe animal e seus filhos, onde cada filho possui seus próprios atributos e métodos, e todos eles herdam os atributos e métodos da classe pai que é Animal.

Aqui algo muito importante precisa ser mencionado e jamais esquecido. Apesar de os filhos herdarem os atributos e métodos da classe pai, nada impede que os métodos da classe pai seja sobrescrito na classe filho, para entender melhor veja mais uma ilustração:

*Herança entre animais com as classes completas **

Repare que agora que esse diagrama possui as classes com seus atributos e métodos definidos. Agora tenha uma atenção especial para a classe peixe. Note que em peixe foi declarado novamente o método respirar, mesmo que esse método seja herdado da classe pai. Aqui houve uma necessidade da classe peixe sobrescrever o método respirar da classe pai, pois a forma de respirar de peixe é completamente diferente dos demais animais terrestres. Então, tenha em mente que é plenamente possível termos situações onde os métodos podem e devem ser sobrescritos.

Associação:

O relacionamento de associação é a base da interação entre as classes de um projeto de sistema. A associação entre classes pode ser:

• Simples;

• De agregação;

• De composição;

• De dependência.

As associações são relações entre classes que possuem um rótulo e uma cardinalidade (também conhecida como multiplicidade).

O rótulo é um nome descrito dado ao relacionamento com o objetivo de tornar o entendimento da relação entre as classes mais objetiva.

A cardinalidade é o modo com que as classes são relacionadas no sistema.

Veja a imagem abaixo

*Exemplo de associação simples entre classes **

Em nosso exemplo podemos destacar as seguintes informações:

• Compra é o rótulo da relação entre as classes;
• 1 e * representam a cardinalidade da associação
• O rótulo também indica o porquê das classes estarem relacionadas;
• A senta indica a direção desse relacionamento

Tipos de Cardinalidade:

• 1;
• *;
• 0..*;
• 1..*;
• 1..1

A cardinalidade em nosso diagrama é muito semelhante a cardinalidade que estudamos em uma banco de dados relacional. Em nossa figura temos que um cliente pode comprar n produtos, mais um produto só pode ser comprado por um único cliente.

Explicando os demais tipos de cardinalidades:

*: Significa muitos;

0..*: Significa que podemos ter 0 ou muitos;

1..*: Significa que podemos ter 1 ou muitos;

1.1: Significa que podemos ter 1 em ambos os lados da relação;

Quando apenas um elemento é especificado significa que estamos representando apenas a cardinalidade máxima, quando temos duas representações como 0..*, significa que o mínimo é 0 e o máximo, muitos.

Agregação:

A agregação considera as classes relacionadas como sendo uma o “todo” e a outra a “parte”. Por tal motivo também é conhecida, juntamente com a composição, como relacionamento todo-parte.

Vamos aos exemplos:

*Exemplo básico de agregação **

Um losango vazado é utilizado para identificar qual é a classe todo, e qual é a classe parte. Podemos ler o exemplo da seguinte forma:

Um objeto da classe todo possui um conjunto de objetos da classe parte. Aqui também poderemos incluir a cardinalidade e o rótulo do relacionamento.

Vamos a um exemplo real:

*Exemplo real de agregação **

Em nosso exemplo, a lógica é a mesma que já foi apresentada, um objeto da classe pedido, possui um conjunto de objetos da classe item. Em outras palavras, sabemos que um pedido precisa do código para sua identificação, a data do pedido, e apresenta também o nome e o preço do item.

Composição:

A utilização da composição é muito similar à agregação, porém, com uma diferença principal: A existência da “parte” não faz sentido se o “todo” não existir. Repare que aqui temos um losango preenchido para identificar uma composição.

Veja como fica a representação gráfica:

*Exemplo de composição **

Na agregação, o objeto parte pode pertencer a mais de um todo, enquanto na composição, o objeto parte pode pertencer somente a um todo. Na composição, as partes são destruídas como consequência na destruição do seu respectivo todo (PODESWA, 2005).

Vamos a um exemplo real:

*Exemplo real do uso de composição **

Do exemplo acima podemos tirar as seguintes conclusões:

• A existência da foto não faz sentido se não for para compor uma galeria;

• Uma galeria, quando destruída no sistema, as fotos também são.

Dependência:

Utilizamos a dependência quando precisamos executar um objeto que para qual operação possa ocorrer, será necessário a existência de um outro objeto de uma outra classe.

Vamos a um exemplo prático:

*Exemplo de relacionamento de dependência entre classes **

Ao realizar uma operação de depósito na boca de um caixa de banco sabemos que o operador precisará saber a quantia que ele irá receber, a quantia propriamente dita que será entregue e por fim a conta de destino desse depósito.

A figura acima ilustra em parte esse processo, ao ler a classe caixa e o seu método depositar, é possível ver que o método depositar recebe dois parâmetros, entre eles note que o parâmetro conta na verdade é uma classe. Repare que Conta começa com a letra “C” em maiúsculo, o que denota ser uma classe.

Aqui em outras palavras está ocorrendo uma dependência, basicamente para que caixa possa operar, ele necessariamente precisa da existência da classe Conta, ou seja, é nítido a dependência que Caixa tem perante Conta.

Lendo novamente o gráfico também notamos a existência de uma seta em sentido a Caixa, ela está literalmente indicando que Caixa depende de Conta.

Bom pessoal, por hoje é isso!

Como sempre terei a honra de poder ajudá-lo, qualquer dúvida encaminhe a sua pergunta para rfcosta85@gmail.com ou deixe nos comentários.

Obrigado pela paciência e até a próxima!

Abraços!

Rodrigo Costa.

Referências:

[1] Casati, João Paulo — Modelagem de Sistemas — Estácio

* Fonte: Modelagem de Sistemas — Estácio de Sá — Casati, João Paulo