O que são Classes? Na lista de uma das várias definições que o Google nos dá achei uma interessante: “grupo ou coleção de coisas que se distinguem das outras pela natureza, uso etc.”.
Considerando a realidade onde o conceito de Classes surgiu, no contexto de produção software, podemos entender que é uma Classe é uma abstração de um objeto da vida real (vida real que será tratada via software), que agrupa dados (atributos) e procedimentos (operações) relacionados ao seu contexto.
/* Acho que “objeto da vida real” é uma boa definição, pois o propósito maior da Orientação a Objetos (OOP) é refletir na estrutura do software a “vida real”. Isso visa diminuir o Gap Semântico (distância de entendimento) entre o problema que o software deve resolver, e sua estrutura. Uma classe que está “viva”, ou seja, quando é instanciada (vai para a memória do sistema operacional quando o software roda) torna-se um objeto (por isso, Orientação a Objetos). */
Classes x Objetos
Uma classe num Diagrama de Classes (ou até mesmo no código fonte) é apenas um conceito. Um conceito em forma de desenho (se num diagrama) ou texto (se em código fonte).
Quando a Classe é materializada através de um software, (quando o software está “rodando”) torna-se um objeto (isso se dá quando é alocado um ponteiro de memória para esta classe).
O diagrama de classes ilustra graficamente como será a estrutura do software (em nível micro ou macro – veremos adiante sobre as possibilidades de uso do diagrama), e como cada um dos componentes da sua estrutura estarão interligados.
Lembramos que na UML também temos o Digrama de Objetos. Este diagrama serve para ilustrar as classes do software instanciadas, ou seja, materializadas em objetos na memória do sistema operacional.
UML e Agilidade
Agilidade não é produzir software com pressa, é produzir software com velocidade, entregando valor no menor espaço de tempo possível, e melhorando isso continuamente.
Para ser ágil, é fundamental ser eficiente.
Não é plausível falar em agilidade sem eficiência, com desperdício.
Em projetos de software, um dos maiores desafios é a boa comunicação.
Deixar claro o que se quer, o que será entregue, como será produzido etc. Isso não é simples quando produzimos software, devido à complexidade inerente a esta atividade.
Quando se entende um requisito do jeito errado, sempre há o custo de fazer errado, desfazer, e fazer certo. Obviamente, este tipo de desperdício custa 3 vezes mais que se tivéssemos feito certo da primeira vez.
E neste contexto, fica claro que o uso racional de diagramas UML com o objetivo de transmitir ideias entre membros de um mesmo time, é uma ferramenta que favorece muito uma cultura ágil.
Objetivos de utilização
O diagrama de classes, como citado, tem como objetivo principal a especificação dos componentes do software e como estes se interligam, do ponto de vista estrutural, ou seja, da sua estrutura.
Possui semelhança com diversos diagramas existentes por aí, aplicáveis às mais diversas áreas, pois (como vários diagramas) é algo como “caixas ligadas com setas”.
Lembrando que sem entender para que servem as caixas, os compartimentos de cada caixa, e as ligações entre as caixas, não é possível entender um modelo de classes.
Quando usar?
O diagrama é bem versátil quanto às possibilidades de aplicação prática.
De modelos estruturais mais simples, a modelos mais complexos, com arquiteturas envolvendo padrões de projeto diversos, modelos objeto-relacional, APIs de micro-serviços e mil e uma outras coisas.
O importante é entender o contexto no qual o diagrama será aplicado, para então usá-lo da melhor forma.
Considerando as possibilidades de aplicação do diagrama, este pode ser utilizado para diferentes finalidades no contexto de produção de software, destacando:
- Design (projeto de software): definir um modelo a ser seguido para um software que ainda não existe, especificando um modelo antes de efetivamente construir software executável (diminuindo o desperdício).
- Engenharia Reversa: refletir a estrutura já existente de um software onde, a partir do código fonte realiza-se a leitura automática (ou não) das classes e suas relações e se produz o diagrama (para compreensão da estrutura do software executável).
- Esboço de ideias: desenhar modelos estruturais para troca de ideias e alinhamento entre analistas de sistemas, por exemplo. Neste caso utiliza-se muito as paredes “rabiscáveis” das empresas mais jovens ou papel e caneta mesmo. Não necessariamente deve-se usar uma ferramenta Case, por exemplo.
Como usar?
Na UML temos três conceitos necessários de entender: diagramas, elementos e relacionamentos.
As formas gráficas que compõe cada diagrama são chamadas “elementos“. Estes elementos são “o grande lance” da UML, é o que sustenta a ideia de “notação”, é a sintaxe contida nos diagramas.
Cada elemento possui um objetivo específico, e a combinação destes elementos torna-se o diagrama, que gera a semântica do respectivo modelo.
Como tudo na vida, na UML também aplica-se o Princípio de Pareto. Com 20% dos elementos fazemos 80% dos diagramas. Então, vou focar nos elementos mais utilizados do diagrama de classes.
Class (Classe) – É a classe propriamente dita. Usamos este elemento quando queremos demostrar visualmente a classe no diagrama (exemplos mais à frente).
Association (Associação – conector sem pontas) – É um tipo de relacionamento usado entre classes. Aplicável a classes que são independentes (vivem sem dependência umas das outras), mas que em algum momento no ciclo de vida do software (enquanto ele está em execução) podem ter alguma relação conceitual.
Generalization (Herança – conector com seta em uma das pontas) – É um tipo de relacionamento onde a classe generalizada (onde a “ponta da seta” do conector fica) fornece recursos para a classe especializada (herdeira). Excetuando conceitos mais avançados (como padrões de projeto, interfaces, visibilidades específicas etc.), tudo que a classe mãe (generalizada) tem, a filha (especializada) terá.
Compose (Composição – conector com um “diamante” hachurado na ponta) – É um tipo de relacionamento onde a classe composta depende de outras classes para “existir”. Por exemplo, a classe “CorpoHumano” possui um composição com a classe “Coracao”. Sem a classe “Coracao”, a classe “CorpoHumano” não pode existir. Mais detalhes neste post completo sobre Composição.
Aggregate (Agregação – conector com um “diamante” vazado na ponta) – É um tipo de relacionamento onde a classe agregada usa outra classes para “existir”, mas pode viver sem ela. Por exemplo, a classe “CorpoHumano” possui uma agregação com a classe “Mao”. Sem a “Mao” a classe “CorpoHumano” pode existir. Mais detalhe neste post completo sobre Agregação.
Exemplo de Uso
Uma classe, na UML (e na Orientação a Objetos também) possui três compartimentos, sendo para: Nome (primeiro), Atributos (segundo) e Operações (terceiro).
Quando fazemos o uso de um diagrama de classes no dia a dia da produção de software, nem sempre é necessário/relevante representar cada classe no menor nível de detalhe , ou seja, com os três compartimentos, e com todo rigor nas especificações dos atributos e operações.
Abaixo temos três exemplos de um mesmo diagrama, em níveis de detalhes diferentes. No último exemplo vamos ver detalhes de cada classe e seus relacionamentos.
No diagrama cima temos relacionamentos de Associação, Agregação, Composição e Generalização (Herança). A explicação a seguir aplica-se a todos os três exemplos, pois foca apenas nos relacionamentos:
- Cozinha pode ter ou não uma PortaCozinha, podendo existir se não tiver. (Agregação)
- PortaCozinha generaliza Porta, possuindo todas as características que Porta têm, além das suas específicas. (Generalização)
- Quarto deve ter PortaQuarto, não podendo existir se não tiver. (Composição)
- PortaQuarto generaliza Porta, que tem todas as características que Porta têm, além das suas específicas. (Generalização)
- Sala deve ter PortaSala, não podendo existir se não tiver. (Composição)
- PortaSala generaliza Porta, que tem todas as características que Porta têm, além das suas específicas. (Generalização)
- Sala pode ter ou não uma Porta que não seja uma PortaSala, mas se tiver ou não isso não fará diferença, pois Porta pode existir sem Sala, e Sala pode existir sem Porta. (Associação).
(no contexto do diagrama anterior) este tipo de representação acima é muito usado/recomendado quando:
- Uma equipe está discutindo um problema e algum profissional quer esboçar (esboço = rascunho, “rabisco”) como pensa na solução, em termos de arquitetura.
- Um profissional quer mostrar apenas as dependências entre as classes do sistema, para uma análise de impacto ou contextualização da arquitetura.
- Não há necessidade de entrar em maiores detalhes sobre as classes, apenas identificá-las e ilustrar suas relações.
O diagrama acima já é um pouco diferente do primeiro, pois além dos compartimentos com os nomes das classes, possui também um outro compartimento contendo os atributos da classe (as classes sem atributos são classes “filhas” de outras [generalização], que portanto, implicitamente possuem todos os atributos que a classe “mãe” possui).
Este tipo de representação acima é muito usado/recomendado quando:
- O objetivo é demonstrar as classes, seus relacionamentos, seus atributos e não há necessidade de detalhar as operações da classe.
- O profissional precisa (ou entende ser necessário) dar mais contexto às classes, detalhando seus atributos, para que se compreenda melhor o escopo de cada classe do modelo e como isso compõe o entendimento sobre as relações entre as classes.
O diagrama acima já é bem diferente do primeiro e do segundo, pois além dos compartimentos com os nomes das classes e atributos, possui também um outro compartimento contendo as operações da classe.
Este tipo de representação acima é muito usado/recomendado quando:
- O objetivo é demonstrar as classes, seus relacionamentos, e cada classe com seu escopo completo.
- Quando a empresa realiza projeto formal do software, utilizando ferramentas case, modelos de classes que serão utilizados para outra empresa (ou a mesma até) para entendimento sobre o software a ser construído.
- Muito cobrado em empresas que prestam serviço para órgãos públicos através de licitação.
- O profissional precisa (ou entende ser necessário) dar 100% de contexto às classes, detalhando seus atributos e suas operações, para que se compreenda melhor o escopo de cada classe do modelo e como isso compõe o entendimento sobre as relações entre as classes.
/* A melhor forma de uso sempre será a mais aderente à necessidade, gerando o melhor entendimento e comunicação entre os profissionais do projeto, e sem gerar desperdício com divagações desnecessárias.*/
Concluindo
O diagrama de classes da UML é sem dúvida uma ferramenta espetacular para auxiliar os profissionais de produção de software no entendimento acerca do que deve ser feito, e como deve ser feito.
Saber utilizá-lo da maneira correta e com bom senso auxilia demais qualquer equipe, mas abusar de seu uso, documentando o desnecessário e gastando tempo detalhando o que não é relevante, subtrai muito da produtividade de qualquer profissional/empresa.
Participe nos comentários, vamos falar mais! 🙂