Olá, aluno(a), estamos iniciando mais uma lição, seja muito bem-vindo(a). Nesta lição, aprofundaremos os nossos conhecimentos na criação de Diagramas de Classe da UML, este que, em conjunto com o Diagrama de Caso de Uso, compõe os dois principais diagramas da UML. Enquanto o Diagrama de Caso de Uso permite uma visão das funcionalidades do sistema, o Diagrama de Classe permite saber quais dados modelar e como esses dados estão relacionados no sistema que está sendo modelado.

Para esta lição, sugiro que você se lembre de alguns conceitos básicos acerca do Diagrama de Classe os quais discutimos, anteriormente. Faça uma revisão sobre os conceitos de objeto e classe. As nossas discussões partem do princípio de que você já os compreende e, agora, compreenderemos os tipos de associações existentes nos Diagramas de Classe e como podemos definir as multiplicidades entre as classes.

A modelagem de um sistema computacional envolve dois elementos centrais. Primeiro, é fundamental que saibamos “o que” o sistema deverá fazer e com “quem” ele se relaciona. Para isso usamos o Diagrama de Caso de Uso. 

Outro elemento fundamental a qualquer tipo de sistema computacional é a modelagem dos dados que o sistema armazenará. Hoje em dia, o ativo mais valioso das organizações são os dados gerados pelos sistemas de informação delas, assim, para que possamos desenvolver sistemas robustos e que acomode os dados, realmente, necessários à organização, precisamos modelar o armazenamento desses dados antes que o sistema seja desenvolvido (projeto).

Imagine a seguinte situação: o que aconteceria se você colocasse um sistema em funcionamento e, após alguns minutos, centenas de usuários começassem a usá-lo? Como um(a) excelente técnico(a) em desenvolvimento de sistemas, você decide observar de que modo os dados estão sendo armazenados na base e percebe que está faltando algo ou que eles não deveriam ser armazenados daquela forma. O que você faria? Tiraria o sistema do ar, imediatamente? Pediria a todos os usuários do sistema que parassem de inserir dados? 

Independentemente do que você faça, o caos já está instaurado e qualquer ação terá sérias consequências, seja para o futuro do próprio sistema, seja em termos de custos para a organização. Este tipo de situação não é incomum e pode ocorrer se a forma como os dados são armazenados no sistema não foi projetada, adequadamente.

Para modelar o armazenamento dos dados de um sistema, fazemos uso do Diagrama de Classe da UML. Por meio do Diagrama de Classe, podemos observar, simular e analisar, com antecedência, quais dados serão armazenados, qual o tipo de cada um deles e como os diferentes dados se relacionam.

Imagine que você desenvolverá um software para determinada empresa e foi solicitado, com certa urgência, que, pelo menos, a parte de cadastro de vendedores, clientes, fornecedores e produtos seja feita primeiro, a fim de agilizar a inserção dos dados.

Sabemos que, para criar um cadastro de algo, precisamos saber quais serão, exatamente, os dados necessários em cada um desses cadastros. Por exemplo, no cadastro de um vendedor, talvez eu precise do código dele como um funcionário da empresa, do endereço de residência, do celular, da data de nascimento, entre outros dados. Cada empresa pode trabalhar com determinado grupo de dados para o cadastro de um vendedor. Em relação aos clientes, fornecedores e produtos é a mesma coisa: necessitamos de informações para desenvolver os formulários com base na real necessidade do solicitante. Então, como já vimos, podemos conversar com as pessoas que fazem esse processo ou procurar em documentos existentes. De qualquer forma, quando trabalhamos com uma grande quantidade de dados que precisam ser informatizados, devemos organizá-los e saber qual se relaciona com qual, não podemos, simplesmente, criar um monte de formulários que não conversam entre si. 

Bem, esse exemplo de caso é para você compreender por que utilizamos diferentes tipos de diagramas! Para organizar os muitos tipos de dados que podem envolver um software, faremos uso do Diagrama de Classe e, por meio dele, criaremos estruturas (classes) que são compostas por tipos diferentes de dados (atributos). Se soubermos quais classes existem e quais atributos uma classe possui, conseguimos, facilmente, criar os formulários de entrada de dados ao usuário. 

O Diagrama de Classes está muito próximo do Projeto de Banco de Dados, inclusive algumas ferramentas (pesquise sobre mapeamento objeto/relacional) transformam o Diagrama de Classe em entidades e relacionamentos no Sistema Gerenciador de Banco de Dados (SGBD). 

Desenvolver o Diagrama de Classe durante o projeto de um software não é somente criar o modelo dos dados que o sistema terá, vai muito além disso. O Diagrama de Classe servirá como base para vários outros diagramas da UML e como uma documentação para o programador criar a estrutura de banco de dados e as interfaces com o usuário. Por isso, você, como técnico(a) em desenvolvimento de sistemas, deve se dedicar à criação desse diagrama.

Iniciarei as nossas discussões apresentando a você os tipos de relacionamentos ou associações que existem no Diagrama de Classe da UML.

Relacionamento ou Associações em Diagramas de Classe 

Observamos em lições anteriores que uma classe possui três elementos: o nome da classe (ex.: Funcionário), os seus atributos (ex.: NomeFuncionário, DataNascimentoFuncionário etc.) e seus métodos (ex.: InserirFuncionário, DeletarFuncionário, GerarListaFuncionários etc.). As classes referem-se a “coisas” do mundo real que colocaremos no mundo computacional (RUMBAUGH; JACOBSON; BOOCH, 1999). Vou explicar! Tudo que está no mundo real pode ser colocado no mundo computacional por meio das suas características, logo, uma classe é a estrutura de algo do mundo real, por exemplo, a classe Funcionário que tem as suas características no mundo real, como o nome do funcionário, o seu CPF, data de nascimento, nome da mãe, nome do pai etc. As características de uma classe são chamadas de atributos, e as funcionalidades (a parte de programação) são chamadas de método (GUEDES, 2011).

Da mesma forma que existem diferentes elementos no mundo que possuem associações, precisamos representar essas associações no mundo computacional. Por exemplo, posso dizer que um cliente fez uma compra com determinado funcionário da empresa, neste caso, tenho três elementos se relacionando: Cliente, Funcionário e Venda. A questão é: como posso modelar a associação desses elementos no mundo computacional? A resposta para esta pergunta é Diagrama de Classe. Mas, antes, precisamos compreender algumas nomenclaturas as quais usaremos no diagrama.

Multiplicidade

A multiplicidade, também chamada de cardinalidade em livros da área de Banco de Dados, representa o número máximo e mínimo de objetos que estão envolvidos em cada extremidade da associação em um diagrama de classe. Explicarei, em detalhes, para você, como isso acontece. Veja o Quadro 1, a seguir:

Para explicar a você o exato significado de cada tipo de multiplicidade, observaremos os tipos de associações possíveis no Diagrama de Classe. O tipo de associação mais comum é chamada de associação binária, uma vez que envolve duas classes. Veja a Figura 1, a seguir.

O Diagrama de Classe da Figura 1 apresenta duas classes. A classe da esquerda é intitulada “Professor”, enquanto a classe da direita é intitulada “Disciplinas”. A classe Professor possui quatro atributos, e a classe Disciplinas possui três atributos, não foram modelados métodos em ambas as classes. As classes são ligadas por uma associação do tipo binária e, em cada uma das extremidades da associação, estão as suas multiplicidades. Eu te pergunto: o que significam essas multiplicidades? Como isso afetaria a modelagem de um sistema? Te explicarei!

Na Figura 1, por exemplo, fazemos a seguinte leitura com relação às multiplicidades: de Professor para Disciplinas (multiplicidade 0..*) significa que um professor pode não estar vinculado a nenhuma disciplina (mínima 0) ou a muitas (máximo muitos - *). De Disciplinas para Professor (multiplicidade 1..2) significa que uma disciplina, obrigatoriamente, deverá estar vinculada a, no mínimo, (multiplicidade 1) 1 professor e, no máximo, a 2 (multiplicidade máxima 2). 

A pergunta que devemos fazer é: no que isso implica o desenvolvimento do meu sistema? A resposta é tudo implica, diretamente, a forma como você implementará a interface do usuário (ex.: formulários que o usuário usará para inserir os dados). Se você define uma multiplicidade mínima opcional (0), não há a necessidade de, no formulário de cadastro dos professores, ter uma lista das disciplinas que força o vínculo do professor à disciplina. De outra forma, se você definir uma multiplicidade mínima de 1, força que, no formulário de cadastro do professor, já exista, por exemplo, uma lista suspensa a qual apresenta todas as disciplinas e que, obrigatoriamente, o professor deverá ser vinculado a, no mínimo, uma dessas disciplinas.

Analisaremos, agora, outro tipo de associação possível no Diagrama de Classe. A agregação é considerada um tipo especial de associação, por representar, graficamente, uma relação todo/parte, ou seja, um objeto todo precisa ser complementado por outro objeto, chamado de parte. 

A principal diferença da agregação para a associação é a sua representação gráfica, enquanto a associação utiliza uma linha, a agregação utiliza um losango ou diamante, como alguns autores a chamam. Veremos um exemplo:

A Figura 2 está modelando a agregação entre Pedido e Itens de um Pedido, o fato de utilizarmos a agregação indica que um pedido é composto por itens dele mesmo, ou seja, é semelhante a um carrinho de compras em uma loja virtual: ao clicar em “Comprar”, aquele item que você selecionou passa a fazer parte de um pedido (todo), e os itens são as partes daquele pedido. Usamos esse tipo de representação gráfica para modelar que um pedido sempre será composto por itens, afinal, não faz sentido existir um pedido sem itens associado a ele. 

As multiplicidades apresentadas na Figura 2 indicam o seguinte: de Pedido para ItensPedido (multiplicidade (1..*), indica que, obrigatoriamente, um pedido deve possuir, no mínimo, um item ou muitos (multiplicidade *). De Itens de Pedido para Pedido (multiplicidade 1..1) indica que um Item de Pedido, obrigatoriamente, deve fazer parte de um Pedido (mínima 1) e, no máximo, um pedido (máxima 1). Isso faz sentido porque não podemos deixar que o sistema coloque, exatamente, o mesmo item em vários pedidos, digo isso em termos de quantidade em estoque. Se temos 100 produtos em estoque e alguém já colocou um deles no carrinho, aquele produto deve ser garantido àquele pedido até que ele seja finalizado, mas se o comprador desistir da compra, o produto volta ao estoque. Isso evita que muitas pessoas comprando ao mesmo tempo realizem compras de produtos que não existem.

Veremos, agora, outro tipo de agregação: a agregação por composição, ou, simplesmente, composição (GUEDES, 2011). Ela é representada por meio de um losango ou diamante preenchido e visa demonstrar que as partes dependem, em termos de existência, do todo, ou seja, as partes representadas por composição só existirão a partir do momento que existir, pelo menos, um todo. A mesma ideia vale para a destruição das partes, elas só podem ser destruídas pelo todo. Vamos a um exemplo:

Por fim, como último tipo de associação possível em um Diagrama de Classe, temos a generalização/especialização. Assim como no Diagrama de Caso de Uso, podemos modelar uma estrutura de herança no nosso diagrama. Vamos a um exemplo.

A Figura 4 modela o conceito de generalização/especialização. A classe Pessoas representa a generalização, enquanto as classes PessoaFisica e PessoaJuridica representam as especializações. Mas o que isso significa? Esse conceito diz que as classes especializadas (PessoaFisica e PessoaJuridica) herdam tudo o que a classe generalizada (Pessoas) possui, ou seja, os atributos nomePessoa: string, endereçoPessoa: string, telefoneContato: string também fazem parte das classes PessoaFisica e PessoaJuridica, mas as classes especialização não compartilham os seus atributos ou métodos, se existirem. Por exemplo, o atributo CPF é exclusivo da classe PessoaFisica e o atributo CNPJ é exclusivo da classe PessoJuridica.

Usamos este tipo de modelagem quando estamos trabalhando com classes que compartilham muitos atributos ou métodos em comum, por exemplo, a classe Conta Bancária generalizada com as classes Conta Poupança e Conta Investimento especializadas. São poucos os elementos que diferenciam uma Conta Bancária dos demais tipos de conta, assim, colocamos o que é mais geral como generalização e o que é mais específico como especialização.

O Diagrama de Classe é utilizado para modelar os dados que farão parte de um sistema computacional. O diagrama permite tanto modelar as estruturas (classes) quanto os seus conteúdos (atributos). Ademais, ele permite que o técnico em desenvolvimento de sistemas apresente quais funcionalidades cada classe terá associada a ela (métodos). Estes são os três elementos centrais do diagrama de classe, mas ainda temos mais, o que nos permite criar um diagrama bastante rico em termos de projeto de dados de um sistema computacional.

As associações entre as classes e as suas multiplicidades permitem que o técnico em desenvolvimento de sistemas modele, exatamente, qual classe é associada a qual (associações) e qual a quantidade de instâncias (objetos) que uma classe terá na outra. Esses dados são muito ricos para auxiliar o programador no momento quando ele estiver desenvolvendo o código do sistema. O programador terá em suas mãos informações preciosas que poderão evitar dúvidas ou implementações incorretas, porque o projeto foi construído, adequadamente.

Após aprofundar os seus estudos, o Diagrama de Classe pode ser uma excelente ferramenta para que você automatize o desenvolvimento de sistemas, isso porque, por meio das classes, é possível estruturar o banco de dados do seu projeto e, até mesmo, construir formulários de forma automatizada. Contudo esse não é o momento para abordarmos nada relacionado à automatização do desenvolvimento de sistemas, mas de você obter sólidos conhecimentos na modelagem do seu diagrama.

Lembre-se que a qualidade de um software passa pelo projeto que auxiliou o desenvolvimento dele. Já sabemos que os dois principais diagramas que fundamentam um projeto de software são o Diagrama de Caso de Uso e o Diagrama de Classe. Posso te garantir: se você desenvolver esses dois diagramas, com excelência, há altas chances de o software ter boa qualidade e de ser desenvolvido em menos tempo.