Especialização de Associações e Classes de Associação

A especialização/generalização de associações e classes de associação não está claramente definida de forma explícita na UML 2. Porém, sua semântica está implícita na estruturação do meta-modelo, presente na especificação da Object Management Group (2010).

Conforme ilustrado pela Figura 4, as meta-classes Association e Class especializam Classifier. Sendo assim, a semântica de generalização de associações e classes, representada pelas associações

desta com a meta-classe Generalization, é a mesma, diferenciando-se apenas por constraints definidas em ambos.

A meta-classe Generalization faz a ligação entre o Classifier especializado (nome de papel specific) e o Classifier generalizado (nome de papel general).

A semântica de generalização entre duas instâncias de Classifier é descrita da seguinte forma:

Where a generalization relates a specific classifier to a general classifier, each instance of the specific classifier is also an instance of the general classifier. Therefore, features specified for instances of the general classifier are implicitly specified for instances of the specific classifier. Any constraint applying to instances of the general classifier also applies to instances of the specific classifier (OBJECT MANAGEMENT GROUP, 2010, p. 73).

Assim como na generalização de classes, a generalização de associações especifica que instâncias (links) das associações especialistas são também instâncias das associações generalistas. Isto significa que associações especialistas também podem ser vistas como subconjuntos de links de suas associações generalistas, apesar de que os links da associação especialista podem possuir características mais específicas do que os links da associação generalista (RUMBAUGH; JACOBSON; BOOCH, 2004).

Analisando associações como conjuntos, a instanciação de um link de associação pode ser considerada como a inserção do mesmo como elemento do conjunto (a associação) e dos superconjunto (a associação generalista da primeira). A destruição de um link, de forma análoga, é a remoção do mesmo como elemento do conjunto e dos superconjuntos.

A especialização de associações possui algumas particularidades (OBJECT MANAGEMENT GROUP, 2010):

a) A associação especialista possui o mesmo número de association ends da associação generalista;

b) Cada association end da associação especialista conecta um tipo (Classifier) igual ou especialista do tipo conectado pelo respectivo association end da associação generalista.

Pelas particularidades mencionadas e pela semântica de generalização, infere-se que os association ends de uma associação especialista podem ser vistos como subconjuntos dos respectivos association ends da associação generalista, embora os elementos do

subconjunto possam conter características mais específicas que os elementos do superconjunto. A inclusão automática de um link, referente a uma associação especialista, no superconjunto de links da associação generalista obriga que a inclusão dos elementos participante em cada association end da associação especialista também inclua automaticamente os mesmos elementos nos association ends correspondente da associação generalista.

A especialização de classes de associação segue as mesmas regras da especialização de associações e da especialização de classes. Isto é expresso no meta-modelo pela generalização da meta-classe AssociationClass pelas meta-classes Association e Class.

A Figura 9 apresenta um exemplo de

generalização/especialização de associações. Neste, todos os association ends são propriedades das associações e ambas as associações são navegáveis nos dois sentidos. A associação is_activate_by especializa a associação is_controlled_by por intermédio do relacionamento de generalização. Cada link adicionado/removido na associação is_activate_by é também adicionado/removido na associação is_controlled_by. Porém, o inverso nem sempre é verdade.

Figura 9. Exemplo de generalização/especialização de associações.

Cada instância de AlarmController em que sua referência é adicionada/removida pelo association end de nome controllers, possuído pela associação is_activate_by, é obrigatoriamente adicionada/removida no association end de mesmo nome possuído pela associação is_controlled_by. O inverso nem sempre é verdade. O mesmo ocorre na outra extremidade da associação, com os association ends de nome device. Cada instância de Alarm adicionada/removida no association end de nome device pertencente à associação is_activate_by,

é adicionada/removida automaticamente no association end de mesmo nome da associação is_controlled_by.

2.1.9 Interfaces

Segundo o Object Management Group (2010, p. 88), uma interface é um tipo de classifier que representa a declaração de um conjunto de características públicas coerentes e obrigações. Uma interface especifica um contrato, sendo que qualquer instância de um classifier que realiza a interface deve cumprir esse contrato.

Interfaces são representadas no meta-modelo pela meta-classe Interface. Esta, de acordo com a Figura 4, é especialista da meta-classe Classifier, assim como Class e Association. Sendo assim, uma interface pode ter, entre outras coisas, características (atributos e operações). Porém, uma restrição obriga que todas as características tenham visibilidade pública (public) (OBJECT MANAGEMENT GROUP, 2010).

Interfaces, diferente de classes, não geram instâncias. Para que uma instância implemente uma interface, é necessário que a classe que gerou a instância realize a interface por meio do relacionamento de realização. Este relacionamento obriga que a classe cumpra com todas as definições da interface, isto é, obriga que a classe implemente todas as características declaradas na interface (OBJECT MANAGEMENT GROUP, 2010).

A participação de uma interface em uma associação acontece da mesma maneira que a participação de uma classe. O association end que conecta a interface na associação é do tipo da própria interface, significando que qualquer instância que implemente a interface pode ser referenciada. Quando um association end é uma propriedade de uma interface, sua visibilidade é sempre pública devido à restrição mencionada anteriormente (OBJECT MANAGEMENT GROUP, 2010). A Figura 10 apresenta um exemplo similar ao apresentado pela Figura 9 em que as classes Device e DeviceController foram substituídas por interfaces de mesmo nome. Sendo assim, os relacionamentos de generalização que existiam entre as classes Alarm e Device, e entre as classes AlarmController e DeviceController, foram substituídos por relacionamentos de realização. Isto é, a classe Alarm realiza a interface Device e a classe AlarmController realiza a interface DeviceController.

Figura 10. Exemplo de associação entre interfaces com generalização de associação.

2.2 ASSOCIAÇÕES EM PROGRAMAÇÃO ORIENTADA A

OBJETOS

Linguagens de programação orientadas a objetos como Java, C#, C++, Object Pascal e outras, não possuem suporte nativo a construção de associações. Os programadores destas linguagens, frequentemente, utilizam padrões de escrita de código para construir associações, combinando atributos, métodos e classes (NOBLE, 1997).

Esta seção apresenta alguns padrões básicos para implementação de associações em linguagens de programação sem suporte nativo a este tipo de estrutura.