ustify>
Clique aqui para ler todos os artigos desta edição
UML na Prática
Construindo Diagramas de Classes
Existem diversos pontos críticos causadores de inserção de defeitos durante o desenvolvimento de um software. Podemos citar requisitos, projeto e codificação como alguns exemplos. Somados a estes pontos críticos, tem-se um outro momento do desenvolvimento que merece uma atenção especial: a elaboração da solução para o
problema através do diagrama de classes. Elaborar de forma criteriosa diagramas de classes é um fator de sucesso de projetos de software por que, além do fato de ser um
momento propenso à inserção de defeitos no software, são neles em que são transformados os problemas do usuário em uma solução computacional, servindo como uma ponte entre requisitos e codificação. Se esta ponte for mal projetada, o software também será (ver Figura 1).
A UML (Unified Modeling Language) apresenta uma série de diagramas para a modelagem de sistemas orientados a objetos. Os diagramas mais comuns são o diagrama de casos de uso (representa as funcionalidades de um sistema), o diagrama de classes (ler Nota 1) (descreve as classes do modelo numa visão estática), o diagrama de seqüência, ou seu substituto na UML 2.0, o diagrama de comunicação (descrevem as funcionalidades através de uma visão dinâmica) e o diagrama de estados (apresenta o comportamento dinâmico de um objeto).
O objetivo desta matéria é trazer ao leitor algumas boas práticas para elaboração de diagramas de classes, através de sua aplicação prática em dois estudos de caso.
Nota 1. Diagrama de classes
De forma simplificada, um diagrama de classes descreve os
“tipos” de objetos do software e os vários tipos de relacionamentos
estáticos que existem entre eles. De todos os diagramas da UML,
este é o diagrama mais comumente utilizado pelas empresas.
Modelagem de classes
Existem diferentes caminhos para se chegar ao diagrama de classes. Dois dos mais utilizados são:
• Especificar os casos de uso e, então, partir para o diagrama de classes: neste caso, as classes, seus atributos, relacionamentos e métodos são identificados diretamente a partir dos requisitos de software definidos. Pode-se utilizar, em seguida, o diagrama de
seqüência para verificar se os relacionamentos e métodos definidos fazem sentido.
• Especificar os casos de uso, elaborar o diagrama de seqüência e, então, partir para a construção do diagrama de classes: neste caso, a construção do diagrama de seqüência ajudará na identificação das classes, relacionamentos e métodos a partir da especificação de requisitos. É uma abordagem muito interessante também.
Não existe um caminho mais correto que o outro, devendo o desenvolvedor utilizar aquele que se sentir mais a vontade em seguir. Neste artigo será trabalhada a primeira
opção: caso de uso à diagrama de classes, que é a forma mais natural de ser utilizada. Neste caso, partiremos para a construção do diagrama de classes atentando para a identificação de quatro elementos: entidades (classes) do software, seus atributos, suas operações e o relacionamento entre as classes. Assim, um processo para criação de um modelo de classes pode ser dividido em quatro etapas (ver Figura 2).
Etapa 1: Identificação de entidades (classes)
Classes permitem que sejam representados no mundo computacional elementos do mundo real, ou seja, do problema para o qual o software está sendo desenvolvido. Elas permitem descrever um conjunto de objetos que compartilhem os mesmos atributos, operações, relacionamentos e semântica, e representam o principal bloco de construção de um software orientado a objetos.
Seguindo nossa abordagem para a construção do diagrama de classes (partindo da especificação dos casos de uso), para identificá-las, procura-se na especificação por conceitos que representem objetos do domínio da aplicação a ser desenvolvida. A Figura 3 apresenta a simbologia para uma classe chamada ContaBancaria utilizando a UML.
Etapa 2: Identificação de atributos
...
