Artigo da SQL Magazine 34 - UML na Prática

Clique aqui para ler todos os artigos desta edição

UML na Prática

Construindo Diagramas de Classes

     Existem ersos 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).

Figura 1. Inserindo defeitos no projeto 

     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 idido em quatro etapas (ver Figura 2).

Figura 2. Elaborando uma solução computacional