POO::Plena-15-Associações

POO-P-14-Objetos que usam objetos

POO-P-16-Associações:composições

No mundo real, os muitos tipos de objetos que existem aparecem tanto de maneira isolada, como elementos independentes, como associados a outros objetos. As técnicas de construção de sistemas por meio da Programação Orientada a Objetos (POO) contemplam maneiras para representar as diferentes associações que podem existir entre os objetos.

Associações

Uma associação representa um vínculo (ou ligação) possível entre instâncias de classes, ou seja, entre objetos que podem ser tanto de um mesmo tipo, como de tipos diferentes [2].

O vínculo existente entre instâncias representa um relacionamento de natureza específica, como:

• Um aluno de um curso e as disciplinas ou módulos que cursou;
• Um usuário de uma biblioteca e um livro por ele emprestado;
• Uma propriedade imóvel e seu proprietário;
• Um sócio ou um membro de um clube ou agremiação;
• As rodas de um veículo ou partes de uma máquina.

Assim, as associações podem e, de fato, devem ser documentadas em qualquer projeto, pois representam os relacionamentos requeridos entre as entidades do seu modelo (de negócio, de dados, etc).

A Unified Modeling Language (UML) é uma linguagem gráfica que possui vários diagramas para representar as visões diferentes de um projeto de software [2][8]. O diagrama de classes UML, em particular, possibilita a representação gráfica de classes, seus atributos e suas operações; possuindo também todos os elementos necessários para expressar as associações existentes entre elas, como ilustrado na figura que segue.

O diagrama exibido contém duas classes, Pessoa e Veiculo, representados por retângulos com três divisões: uma para a identificação da classe (seu nome e, opcionalmente, seu pacote/namespace); uma para os atributos da classe; e outra para as operações da classes. Os atributos e operações são precedidos por um símbolo que indica sua visibilidade: '+' para elementos públicos, '#' para elementos protegidos e '-' para elementos privados; sendo que a ausência de símbolo denota visibilidade de nível pacote.

Também podem existir ligações entre classes, como mostra a figura abaixo, que destaca a ligação entre a classe Pessoa e a classe Veiculo. 

A associação (ligação) entre as classes Pessoa e Veiculo é denominada propriedade. Cada extremidade também é identificada, o que permite estabelecer como se dá o vínculo de propriedade especificamente para cada tipo (classe) envolvida:

• Pessoa tem frota de 0..* (zero ou mais) veículos; e
• Veículo tem 1 (um) proprietário.

A indicação numérica existente em cada extremo de uma associação é a cardinalidade ou multiplicidade da relação, que pode ser:

• 0..1 -- zero ou um;
• 0..* -- zero ou mais (qualquer número);
• 1 -- (apenas) um;
• 1..* -- um ou mais do que um; e
• * -- qualquer número.

Assim, tal diagrama pode ser lido como:

• Pessoas e veículos têm um vínculo denominado propriedade. Uma pessoa possui uma frota (de veículos), com zero até muitos veículos. Um veículo possui apenas um proprietário.

Importância das associações

Modelar as associações entre classes constitui a espinha dorsal da análise técnica que se denomina modelagem de informações. Assim, os diagramas de classes que contêm associações permitem obter informações sobre várias perspectivas da modelagem:

• Uma associação ou relacionamento é nomeada por uma forma verbal: "propriedade" pode ser também "possuído por".
• A multiplicidade de relações que é possível, incluindo a ausência de relação (0) quando permitida.
• Os nomes das associações e dos papéis não são obrigatórios na UML, mas mostram-se muito úteis na etapa de implementação e na interpretação dos diagramas.

Associação básica ou binária

O diagrama que segue mostra associação básica ou binária entre (classes) Pessoa e Cachorro, a qual é denominada PosseDeCachorro:

• Um Cachorro tem 0..1 (zero ou um) dono (Pessoa).
• Uma Pessoa possui 0..* (qualquer número) de Cachorros. 

Associação representada por Classe

Uma associação entre classes, tal como a básica entre Pessoa e Cachorro, pode também ser representada por uma classe (dita de associação). Desta maneira, a relação PosseDeCachorro, entre Pessoa e Cachorro, poderia ser expressa assim.

Navegabilidade

É um conceito da UML reservado inteiramente para modelos de implementação orientados a objeto.

A navegabilidade é indicada por setas acrescentadas nas linhas que representam as associações. Ela mostra quando um objeto pode se referir ao outro associado, o que permite acessá-lo, ou seja, navegar até tal objeto. Com isso é possível executar operações relacionadas à associação em si.

A navegação pode ser unidirecional e bidirecional, assim entre duas classes existem três possibilidades de navegação, como mostra a figura que segue, onde se vê a navegação unidirecional de Pessoa para Cachorro, a navegação unidirecional de Cachorro para Pessoa, e também bidirecional entre Pessoa e Cachorro.

Associação, Navegabilidade e Código OO

Cada forma de associação e sua possível multiplicidade tem uma expressão própria em termos de código.

Para ilustrarmos como o código OO pode ser construído para representar as associações de navegação uni e bidirecional, com diferentes multiplicidades, considere a existência das classes A e B, como segue:

public class A {

   // atributos, operações e construtores

   :

}

public class B {

   // atributos, operações e construtores

   :

}

Neste momento, não é necessário conhecermos e considerarmos os eventuais atributos, operações e construtores pertencentes a estas classes.

Navegação unidirecional

Se for desejada uma associação denominada papel, unidirecional, de cardinalidade 0..1 (zero ou um), com navegação de A para B, devemos ter:

public class A {

   // associação de A para B, 0..1

   public B papel;

   // atributos, operações e construtores

   :

}

public class B {

   // atributos, operações e construtores

   :

}

Este código possibilita que:

• Quando o atributo papel de uma instância da classe A é nulo, temos a situação de nenhum objeto do tipo B está associado ao primeiro (multiplicidade = 0).
• Quando o atributo papel de uma instância da classe A contém uma referência válida, temos a situação de um objeto do tipo B associado ao primeiro (multiplicidade = 1).
• Quando a instância de A contém um referência válida, é possível navegar do objeto  de tipo A para o objeto de tipo B. O contrário não é possível, assim temos uma navegação unidirecional.

Então, temos que este código permite que cada instância de A possa, livremente, ser associada a zero ou uma instância de B, permitindo a navegação de A para B apenas (é a classe que possui um campo para representar a associação que possibilita suas instâncias de acessar a - navegar para - instância associada).

Para inverter o sentido da navegação, bastaria colocar o atributo de navegação na outra classe, ou seja, para uma associação denominada papel, unidirecional, de cardinalidade 0..1 (zero ou um), com navegação de B para A, devemos ter:

public class A {

   // atributos, operações e construtores

   :

}

public class B {

   // associação de B para A, 0..1

   public A papel;

   // atributos, operações e construtores

   :

}

As características desta associação são as mesmas, apenas com a navegabilidade invertida.

Para navegação bidirecional, o campo de associação deve estar presente nas duas classes, como segue.

public class A {

   // associação de A para B, 0..1

   public B papel;

   // atributos, operações e construtores

   :

}

public class B {

   // associação de B para A, 0..1

   public A papel;

   // atributos, operações e construtores

   :

}

O exemplo acima permite a navegação bidirecional entre A e B, mantendo a multiplicidade 0..1 em cada extremidade da associação.

No entanto, esta estrutura de código não é robusta. Cabe ao programador garantir a consistência entre quaisquer associações construídas!

Considerações finais

Como um sistema OO contém vários objetos interrelacionados, é necessário representar adequadamente as diferentes associações que podem existir entre os objetos, isto é, os vínculos entre instâncias de tipos diferentes, pois tais associações explicitam as relações lógicas ou de negócios que existem entre tais objetos.

Assim é muito importante modelar as associações entre classes, atividade essencial na análise técnica que se denomina modelagem de informações, a qual culmina num projeto orientado a objetos.

As associações, com sua identificação, cardinalidade e possibilidade de navegação expressam o uso típico que os objetos fazem dos demais. Particularmente existem as associações todo/parte, dentre as quais a composição e a agregação merecem estudo mais cuidadoso, a ser visto nos próximos posts!

POO-P-14-Objetos que usam objetos

POO-P-16-Associações:composições

Referências Bibliográficas

[1] JAMSA, K.; KLANDER, L.. Programando em C/C++: a bíblia. São Paulo: Makron Books, 1999.

[2] PAGE_JONES, M.. Fundamentos do Desenho Orientado a Objeto com UML. São Paulo: Makron Books, 2001.

[3] SOMMERVILLE, I.. Software Engineering. 6th. Ed. Harlow: Pearson, 2001.

[4] DEITEL, H.M.; DEITEL, P.J.. Java: como programar. 6a. Ed. São Paulo: Pearson Prentice-Hall, 2005.

[5] SAVITCH, W.. C++ Absoluto. São Paulo: Pearson Addison-Wesley, 2004.

[6] JANDL JR., P. Introdução ao C++. São Paulo: Futura, 2003.

[7] JANDL JR., P.. Java - guia do programador. 3a. ed. São Paulo: Novatec, 2015.

[8] RUMBAUGH, J.; BLAHA, M.; PREMERLANI, W.; EDDY, F.; LORENSEN, W.. Object-oriented modeling and design. Englewoods Cliffs: Prentice-Hall, 1991.

[9] STROUSTRUP, B.. The C++ Programming Language. 3rd Ed. Reading: Addison-Wesley, 1997.

[10] LANGSAM, Y.; AUGENSTEIN, M. J.; TENENBAUM, A. M.. Data structures using C and C++. 2nd Ed. Upper Saddle River: Prentice-Hall, 1996.

[11] WATSON, K.; NAGEL, C.; PEDERSEN, J.H.; REID, J.D.; SKINNER, M.; WHITE, E.. Beginning Microsoft Visual C# 2008. Indianapolis: Wiley Publishing, 2008.