Aprenda a interpretar Diagramas de Classes da UML – Parte 2
Esse artigo mostra como desenvolver a camada Model de um software para tickets aéreos a partir da interpretação de um diagrama de classes da UML.
Como interpretar Diagramas de Classes da UML – Parte 1
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.
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á "
[...] continue lendo...Artigos relacionados
-
Artigo
-
Artigo
-
Artigo
-
Artigo
-
Vídeo