O diagrama de classes é o mais importante diagrama
da UML, ele está no centro da sua
arquitetura e a partir desse diagrama outros diagramas são elaborados. O
diagrama de classes é uma importante ferramenta para a documentação de um
sistema ou produto de software, nesse sentido Melo (2002, p. 85) ressalta:
“Se o protagonista de um sistema desenvolvido sob a análise orientada a
objetos é um objeto, nada mais justo do que termos onde documentar os objetos
encontrados nos requisitos do sistema.”
Segundo Fowler (2000, p. 57), “Um diagrama de
classes descreve os tipos de objetos no sistema e os vários tipos de
relacionamentos estáticos que existem entre eles”. As classes representam as
propriedades e o comportamento de um conjunto de objetos em um sistema e conseqüentemente,
como essas classes não existem sozinhas, é importante também representar os
seus relacionamentos.
O diagrama de classes é similar ao diagrama de
Entidades-Relacionamentos da área de banco de dados, porém, ele se encontra em
um nível de abstração de mais alto nível e contém uma importante diferença que
é a de representar o comportamento da classe, ou seja, através de suas
operações ou métodos. Portanto a persistência é uma importante característica
no conceito desse diagrama, uma vez que, algumas classes podem representar,
futuramente, em um projeto de sistema, entidades físicas implementadas no
banco de dados do sistema. Guedes (2008, p. 75) fornece um bom relato dessa
característica do diagrama de classes:
Em muitos casos pode ser necessário preservar de
maneira permanente os objetos de uma Classe, ou seja, esta deve ser
persistente. Uma classe persistente apresenta muitas semelhanças com uma
entidade como aquelas definidas no antigo Modelo Entidade-Relacionamento
utilizado para definir as estruturas de tabelas em bancos de dados relacionais.
[...] Na verdade o diagrama de classes foi intencionalmente projetado para ser
uma evolução do Modelo Entidade-Relacionamento e pode ser utilizado para
modelar a estrutura lógica das tabelas que irão compor um banco de dados.
A seguir serão apresentados os principais
componentes do diagrama de classe, juntamente com um exemplo ilustrativo. Os
exemplos fazem parte de um pequeno estudo de caso que será apresentado de forma
completa no final deste artigo e também em vídeo aula, não deixe de conferir.
CLASSES
As
classes, no diagrama de classes, são representadas por um retângulo com,
normalmente, três divisões, a saber: o nome da classe, os atributos e as
operações, esses dois últimos, com os seus tipos e respectivos escopos. É
importante que o nome da classe seja uma palavra única, preferencialmente sem
caracteres especiais e acentuados, isso evitará problemas na geração do código
fonte do diagrama.
Em uma
classe os ATRIBUTOS representam as propriedades da classe e as OPERAÇÕES,
representam os métodos desta classe.
ASSOCIAÇÃO
As
associações representam as relações entre as ocorrências das classes. É um tipo
de relacionamento estrutural e estático entre as classes. As associações em um
diagrama de classe definem os tipos de ligações que os objetos participam.
BOOCH (2005, p. 452) usa o termo “associação binária” para se referir a uma
associação entre duas classes.
AGREGAÇÃO
Descreve
uma relação de dependência entre duas classes, é a descrição de um
relacionamento
todo-parte ou “parte de”, também conhecido como um relacionamento do tipo
HAS-A. É um caso particular de associação. Esse tipo de relacionamento traz os
conceitos de responsabilidades entre classes. A agregação é um tipo de
relacionamento que não força a destruição do conjunto, ou seja, uma vez
destruído o objeto todo, não há obrigatoriedade da destruição do objeto
parte, assim, no exemplo abaixo, mesmo se uma equipe “X” acabar, o
jogador poderá fazer parte de outra equipe.
COMPOSIÇÃO
Segundo
BEZERRA (2007, p. 123), “nas agregações/composições, as partes são normalmente
criadas e destruídas pelo todo. Na classe do objeto todo, são definidas as
operações para adicionar e remover as partes”.
MULTIPLICIDADE
É a
indicação de quantos objetos podem participar de um relacionamento.
NOME DO
PAPEL
É uma
descrição (rótulo explicativo) inserido na ponta de uma associação.
GENERALIZAÇÃO
É um
relacionamento onde temos uma classe ancestral (supertipo) e outras classes
herdadas (subtipos). o subtipo deve incluir todos os elementos (atributos
e operações) do supertipo. Na implementação física corresponde a um processo de
herança. Este é o relacionamento IS-A (é um). Este tipo de relacionamento na
linguagem JAVA pode ser identificado com o operador “instanceOff”.
Esse tipo
de generalização podem ser restringidos de várias maneiras. Segundo BEZERRA
(2007, P. 134), as restrições podem ser: Sobrepostas, para representar herança
múltipla; Disjunta para subclasses que só poderão herdar de uma única classe;
Completa, quando todas as classes herdadas possíveis foram definidas;
Incompleta quando nem todas as subclasses foram definidas.
INTERFACE
A
interface define apenas a assinatura dos métodos da classe sem apresentar sua
implementação. Normalmente, nas linguagens de programação orientadas a objetos,
as interfaces não apresentam atributos. A interface implementa a programação
por contrato. A figura a seguir apresenta duas representações de interface e o
seu relacionamento com uma classe. No segundo exemplo note o uso do estereótipo
para evidenciar a interface.
ESTEREÓTIPOS
Segundo
BOOCH (2005, p. 455) trata-se de “Uma extensão do vocabulário da UML, que
permite a criação de novos tipos de blocos de construção derivados dos já existentes,
mas que são específicos ao seu problema.” Os estereótipos são representados por
aspas francesas ( <>). Os estereótipos são
normalmente predefinidos na própria linguagem UML, por outro lado, a equipe de
desenvolvimento pode definir os seus próprios estereótipos, assim esclarece
BEZERRA (2007, P. 47):
[...] A
UML também permite que o usuário defina os estereótipos a serem utilizados em
determinada situação de modelagem. Ou seja, a própria equipe de desenvolvimento
pode definir os estereótipos que serão utilizados em situações específicas.
Dessa forma, podemos ter estereótipos de dois tipos: predefinidos ou definidos
pela equipe de desenvolvimento.
REFERÊNCIAS
BIBLIOGRÁFICAS PRINCIPAIS
BOOCH, Grady; RUMBAUGH,
James; JACOBSON, Ivar. UML Guia do Usuário. – Rio de Janeiro : Elsevier, 2005.
BEZERRA,
Eduardo. Princípios de Análise e Projeto de Sistemas com UML. – Rio de
Janeiro : Elsevier, 2003.
BEZERRA,
Eduardo. Princípios de Análise e Projeto de Sistemas com UML. 2o. Ed. –
Rio de Janeiro : Elsevier, 2007.
PÁDUA,
Wilson de Paula Filho. Engenharia de Software. Fundamentos, Métodos e
Padrões. 2o. Ed. – Rio de Janeiro. LTC – Livros Técnicos e Científicos,
2003.
FOWLER,
Martin.; SCOTT Kendal. UML essencial: um breve guia para a linguagem –
padrão de modelagem de objetos. 169 p. 2. ed. – Porto Alegre: Bookman,
2000.
MELO, Ana
Cristina. Desenvolvendo aplicações com UML. 255 p. – Rio de
Janeiro: Brasport, 2002.
MARTIN,
James.; ODELL, James. Análise e Projeto Orientados a Objeto.
639 p. – São Paulo: Makron
Books, 1995.
GUEDES,
Gilleanes. UML – Uma abordagem Prática. 336 p. 3, ed. – São Paulo:
Novatec Editora, 2008.
Nenhum comentário:
Postar um comentário
O que achou dessa postagem?