Union Strategy

delo da UML (OMG 2007c).

5.2

Union Strategy

O relacionamento de composição baseado na union strategy especifica que todos os recei- ving elements e todos os merged elements devem ser adicionados ao resulting profile, o qual passa a ter todo o conteúdo do receiving profile e do merged profile.

As partes que são equivalentes do merged profile em relação ao receiving profile são copiadas para o resulting profile, porém algumas transformações são necessárias de serem realizadas. Por outro lado, as partes que não são equivalentes entre o merged profile e o receiving profile são adicionadas ao resulting profile sem alterações.

Todas as partes que não são equivalentes do merged profile em relação ao receiving profile são apenas copiada para o resulting profile. Porém, ao adicionar as partes equiva- lentes entre o merged profile e o receiving profile ao resulting profile, surgem conflitos de nome, haja vista terão resulting elements com assinaturas iguais em um mesma names- pace, sendo necessário, com isso, realizar alguns transformações.

Estabelecer o relacionamento de composição entre dois profiles de entrada se- guindo a semântica de composição definida para a union strategy implica em uma com- posição conservativa. Haja vista, os profiles são compostos seguindo um princípio de conservação dos conceitos dos domínios que os mesmos representam. Sendo assim, todos os conceitos presentes nos profiles de entrada terão que estar presentes no resulting profile. Para conservar os conceitos é necessário realizar algumas transformações nos elementos dos profiles que serão inseridos no modelo de saída para não originar conflitos. Na Fi- gura 5.2 é mostrado um exemplo de composição seguindo a union strategy, onde se tem na parte (E) da figura Tree.Node, Tree.StateKind, Topology.StateKind e

Topology.Node que mostram a inserção do nome do profiles de origem Topology e Tree.

A semântica de composição baseada na union strategy é descrita nesta seção. Para isto, tem-se as seguintes Subseções contendo:

• possíveis cenários de aplicações do relacionamento de composição baseado na union

strategy;

• a descrição da semântica de composição de union strategy.

5.2.1

Cenário de Aplicação

Quando é estabelecido um relacionamento de composição entre dois profiles aplicando union strategy como a estragégia de composição, isto implica em uma tentativa de conservar o conteúdo dos profiles de entrada. Por exemplo, tendo-se os profiles dos framework JSF

5.2. UNION STRATEGY 83 Topology <<profile>> <<metaclass>> Class <<metaclass>> Association <<stereotype>> LocalEdge <<stereotype>> Edge Tree <<profile>> <<metaclass>> Class <<Metaclass>> Operation <<stereotype>> Search <<stereotype>> Edge name: String value: Integer <<stereotype>> Node <<stereotype>> Root <<streotype>> Leaf <<metaclass>> Association Receiving Profile <<profile>> <<metaclass>> Class <<metaclass>> Operation <<stereotype>> Search <<streotype>> Leaf A ) B ) E ) Topology.Node LocalEdge Location C )

Topology.Herança SearchTree.Edge Tree.Node

Busy Leaf F ) <<enumeration>> StateKind available busy Available Tree.StateKind <<Enumeration>> Tree.StateKind available busy off <<stereotype>> MainNode state: StateKind Topology

Herança MainNode LocalEdge Edge

State

Node

Tree

Herança Root Search Edge

Name Node D ) Value Leaf equivalentes equivalentes Location StateKind StateKind equivalentes Name Value TreeTopology <<enumeration>> StateKind available busy off

Off Busy Available Busy Available

TreeTopology Resulting Profile

Merged Profile <<merge>> name: String state: Topology.StateKind Name <<metaclass>> Association <<stereotype>> LocalEdge <<stereotype>> Topology.Edge name: String Name <<stereotype>> Node location: String <<stereotype>> MainNode state: StateKind name: String value: Integer <<stereotype>> Tree.Node <<stereotype>> Root state: Tree.StateKind <<enumeration>> Topology.StateKind available busy <<Stereotype>> Tree.Edge <<stereotype>> Topology.Node location: String

Off Busy Available Topology.StateKind MainNode State Top.Edge Tree.Herança State Name

5.2. UNION STRATEGY 84 (Java Serve Face) e Struts utilizados para modelar aplicações Web, busca-se ter um pro- file único que possa representar estes dois profiles. Para isto, é necessário apresentar a capacidade de representar todos os conceitos de ambos os frameworks. Sendo assim, é possível fazer uso da union strategy para originar um resulting profile que possua todos os conceitos de ambos os frameworks.

Definir o relacionamento de composição seguindo a union strategy consiste em de- finir que as partes que são equivalentes (overlapping parts) do receiving profile e do merged profile sofram transformações a fim de que todas as partes que são equivalentes estejam presentes no resulting profile, enquanto que as partes não equivalentes são apenas adicio- nadas no resulting profile.

5.2.2

Semântica de Union Strategy

Nesta Subseção é discutida a semântica que o relacionamento de composição assume quando é definido union strategy como a estretégia de composição. Union strategy é apli- cada quando existe a necessidade de obter um profile único contendo todo o conteúdo dos profiles de entrada, como já mencionado.

O relacionamento de composição baseado na union strategy especifica que os elementos de receiving profile deve “reunir” os elementos equivalentes de merged profile originando um resulting profile, o qual possui todos os receiving elements e merged ele- ments equivalentes combinados. A forma de identificar os elementos que são equivalentes, as overlapping parts, é a mesma especificada no Capítulo 4.

A composição seguindo a semântica de composição union strategy deve respeitar as seguintes regras, como segue:

Regra 01: para todo receiving element que possua um merged element equivalente, isto implica que os mesmos deverão ser inseridos no resulting profile sendo necessário aplicar algumas transformações, tais como: atualizar namespace e renomear os ele- mentos equivalentes. A aplicação desta regra é ilustrada na Figura 5.2, onde é considerado a default match strategy como a base para definir as overlapping parts. Desse modo, observa-se três overlapping parts, o surgimento de alguns conflitos e a realizações de algumas transformações, como segue:

1. os stereotypes Tree.Node e Topology.Node são equivalentes e, uma vez que sejam inseridos em TreeTopology surge um conflito de nome, haja vista têm-se dois stereotypes com nomes iguais em uma mesma namespace. Logo, é neces- sário realizar uma transformação que consiste, basicamente, em renomeá-los e verificar o que esta modificação produz. Por exemplo, um vez que um ele- mento teve seu nome alterado é possível que surjam conflitos de referência, ou seja, elementos fazendo referência a um elemento que não existe, devido à

5.2. UNION STRATEGY 85 alteração do nome. Outro exemplo seria, o conflito de referência do relaciona- mento de herança (ver Figura 5.2 na página 83) entre TreeTopology.MainNode e TreeTopology.Topology.Node, a qual faz referência ao Topology.Node e não ao TreeTopology.Topology.Node que é o correto.

2. o enumeration Topology.StateKind e Tree.StateKind são equivalentes e devem ser inseridas no resulting profile TreeTopology. Porém, surgem con- flitos de nome, haja vista têm-se dois stereotypes com nomes iguais em uma mesma namespace. Com isso, é realizado uma transformação que consiste em renomeá-los, obtendo TreeTopology.Topology.StateKind e TreeTopology- .Tree.StateKind. Isto tem um impacto nos elementos que fazem referência a eles, surgindo conflitos de referência, por exemplo TreeTopology.MainNode e

TreeTopology.Rootfazendo referência à Topology.StateKind e Tree.State-

Kind, respectivamente, sendo necessário atualizar estas referências.

3. os stereotypes Tree.Edge e Topology.Edge são equivalentes, sendo necessário renomear estes elementos, a fim de inseri-los no resulting profile TreeTopology. Como resultado tem-se TreeTopology.Tree.Edge e TreeTopology.Topology- .Edge.

Regra 02: para todo merged element que não possua um receiving element equiva- lente, o mesmo deverá ser inserido no resulting profile sem alterações. Na Fi- gura 5.2, é ilustrado o uso desta regra, onde os stereotype Topology.LocalEdge e Topology.MainNode são inseridos no resulting profile sem alterações.

Regra 03: para todo receiving element que não possua um merged element equivalente, o mesmo deve ser inserido no resulting element sem alterações. Na Figura 5.2, é apre- sentado o uso desta regra, onde os stereotype Tree.Leaf, Tree.Root e Tree.Search são inseridos no resulting profile sem alterações.

Regra 04: o resulting profile não deve apresentar conflitos. Caso exista, é necessário aplicar as model transformation rules, anteriormente definidas. Um exemplo de apli- cação destas regras é ilustrada na Figura 5.2, onde stereotype Tree.MainNode possui uma referência à enumeration StateKind. As enumeration Topology.StateKind e Tree.StateKind são equivalentes, o que implica que Tree.StateKind é com- posto com Topology.StateKind. Desse modo, surge um reference conflict, haja vista TreeTopology.MainNode faz referência à enumeration Topology.StateKind que não existe mais. Este conflito é solucionado com a mudança de referência da enumeration Topology.StateKind para TreeTopology.StateKind através da apli- cação da regra de transformação MTR6 definida na Seção 4.4.4 na página 70.

5.3. MERGE STRATEGY 86