Artigos Canal Mais Aprenda a interpretar Diagramas de Classes da UML – Parte 2
Demais posts desta série:
Como interpretar Diagramas de Classes da UML – Parte 1
Artigo no estilo: Curso
Por que eu devo ler este artigo:Independentemente da área de atuação no desenvolvimento de software, o diagrama de classes possui muitas informações que podem estar ocultas sob seus elementos para pessoas que não estão treinadas em observá-las. E o problema principal é que muitas vezes essas informações podem passar despercebidas não só por desenvolvedores, mas também por analistas de negócio, que são os responsáveis pela construção desses diagramas e não sabem trabalhar mais profundamente sobre eles. Vale ressaltar que é muito importante a correta interpretação deste para gerar classes e atributos corretos e, principalmente, para a utilização dos construtores das classes na construção das regras de negócio de um software a partir das obrigatoriedades existentes nas associações entre as classes. Com base nisso, este artigo visa explorar a interpretação desses aspectos com um exemplo prático de um sistema de compras de bilhetes aéreos, cujo projeto Java será gerado a partir de um diagrama de classes.

Na primeira parte deste artigo foram apresentados os conceitos relacionados à interpretação de um diagrama de classes UML. Foi visto que uma associação entre classes contém quatro características básicas: Navegabilidade, que define a direção de uma associação, podendo ser unidirecional ou bidirecional; Multiplicidade, que indica quantos objetos de uma classe destino estão presentes em uma classe origem; Conectividade, que é a união dos dois sentidos da Navegabilidade, formando a representação da leitura da associação, que pode ser do tipo OneToOne, OneToMany, ManyToOne e ManyToMany; e Obrigatoriedade, que indica a necessidade básica de uma classe para ser instanciada como, por exemplo, para criar uma instância de uma Casa é necessário que exista um Terreno. Além dos aspectos básicos de uma associação, foram apresentados conceitos sobre as camadas Model, Business, View e DAO, que ajudam a organizar a arquitetura de um software.

Com base nisso, nesta segunda parte do artigo iremos realizar a codificação do diagrama de classes apresentado no próximo tópico. Deste modo, serão assimilados os conceitos abordados na parte um com a implementação de cada classe projetada no diagrama. Antes, porém, vale ressaltar que o mesmo possui várias situações que certamente serão encontradas em outros diagramas, o ajudando a se preparar para os desafios enfrentados diariamente na carreira de um desenvolvedor profissional.

O diagrama de classes do sistema de bilhetes aéreos

Além do texto de requisitos do sistema de Bilhetes Aéreos, a título de melhor visualização dos requisitos, o analista de sistema do projeto deixou um diagrama de classes UML para ser codificado na linguagem Java, conforme a Figura 1. Esse diagrama contém 14 classes e três enums, que serão explicitados com mais detalhes durante a parte prática deste artigo. Antes disso, é interessante que você o observe e tente imaginar como seria a codificação das classes, enums e suas associações. Além disso, também é interessante que você tente antecipar problemas que podem aparecer durante a codificação. Isto certamente lhe ajudará a entender melhor o conteúdo apresentado nos próximos tópicos.

Diagrama de classes representando o sistema de bilhetes aéreos

Figura 1. Diagrama de classes representando o sistema de bilhetes aéreos.

Codificação da camada Model

Além da qualidade em um projeto de software, é válido destacar que a codificação de um diagrama de classes é uma tarefa que exige uma atenção muito grande. Nesta etapa é interessante lembrar de um ditado bastante conhecido na área da computação: Dividir para Conquistar. Esse “lema” sinaliza que quando existe um grande problema, por exemplo, codificar o diagrama de classes desse projeto, a melhor forma de resolvê-lo é através da sua divisão por partes. Sendo assim, vamos dividir o nosso diagrama de classes para tornar mais fácil a sua codificação.

Codificação da classe Endereco

A primeira atividade a ser realizada sobre um diagrama de classes UML é a busca por classes que sejam somente de destino, ou seja, que possuam somente associações unidirecionais com outras classes e que todas essas associações terminem nela (a classe destino). No caso do diagrama do projeto, a classe Endereco, situada no canto inferior direito, satisfaz essa condição. Repare que existem duas associações com a classe Endereco (Pessoa e Aeroporto), mas em ambas, Endereco é a classe destino. Assim, essa classe é uma excelente candidata para iniciar a codificação da camada model, conforme a Listagem 1.

Em Java, a divisão por camadas é auxiliada pelos pacotes (packages). Com o intuito de manter essa padronização/organização, para o nosso projeto de tickets aéreos iremos criar um pacote para a camada model com o nome br.com.devmedia.bilhetesAereos.model.

Listagem 1. Código da classe Endereco.


  01  package br.com.devmedia.bilhetesAereos.model;
  02
  03 public class Endereco {
  04  private Long id;
  05  private String rua, complemento, bairro, cidade, estado, pais;
  06  private Integer numero;
  07 
  08  //não é necessário construtor default
  09 
  10  //Métodos getters e setters para todos os atributos
  11 
  12 }

Como é possível perceber, todos os atributos do diagrama de classes foram representados utilizando a palavra-chave private. Isto se deve ao fato de no diagrama de classes esses atributos estarem representados com um sinal de menos (“-”). Portanto, quando houver esse símbolo na frente de atributos ou métodos em um diagrama, ele sempre será private. Caso o símbolo seja um sinal de adição (“+”) esse atributo ou método deve ser codificado como public. E caso o símbolo seja um sinal de Hash (“#”), esse atributo ou método deve ser codificado como protected.

Essa definição também tem relação com o conceito da orientação a objetos chamado encapsulamento. Tal conceito declara que todos os atributos de uma classe devem estar protegidos de outras classes. Uma forma de acesso a esses atributos seria através dos métodos ge ...

Quer ler esse conteúdo completo? Tenha acesso completo