Enzyme assays

O relacionamento de composição baseado na override strategy especifica que os elementos do receiving profile devem sobrescrever os elementos equivalentes do merged profile origi- nando um resulting profile, o qual possui todos elementos de receiving profile e todos os elementos de merged profile, exceto aqueles equivalentes aos do receiving profile. Todas as partes que não são equivalentes do merged profile em relação ao receiving profile são apenas copiadas para o composed profile.

Nesta seção será detalhada a semântica de composição baseado na composição baseado na Override Strategy, para isto tem-se as seguintes Subseções contendo:

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

ride strategy;

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

5.1. OVERRIDE STRATEGY 79

5.1.1

Cenários de Aplicação

Override Strategy é aplicada quando um profile precisa ter alguns dos elementos modifi- cados, ou quando é necessário adicionar novos elementos. Por exemplo, a construção de um profile é realizada tendo como base um metamodelo, o qual define os conceitos especí- ficos do domínio que devem ser especificados no profile. Dentro do cenário de evolução de software, os domínios das aplicações estão constantemente evoluindo, sendo esta evolução caracterizada, ou pelo incremento de novos requisitos, ou pela alteração dos já existentes. Com isso, o metamodelo é alterado a fim de refletir as alterações do domínio. Da mesma forma, o profile específico do domínio deve ser alterado para refletir as alterações ou a in- cremento de novos conceitos no metamodelo. Esta alteração no profile pode ser realizada através da composição baseada na Override Strategy.

Outro cenário de aplicação para Override Strategy é no contexto de GSD (Glo- bal Software Development) . Onde equipes distribuídas trabalham na especificação de uma profile. Estando este profile em um repositório, é possível que alguma parte da espe- cificação do profile desenvolvida por uma equipe venha a ser sobrescrita ou tenha novos elementos desenvolvidos por outra equipe. Isto pode ser implementado usando composi- ção de profile baseada na Override Strategy. Por exemplo, qualquer alteração do Business Metamodel (ver Figura 1.1) implica em realizar alteração do Java Profile e realizar a composição dos Web, Java e Oracle Profiles, novamente.

Definir a estratégia de composição a qual relacionamento de composição deve seguir, implica em especificar a forma como os modelos devem ser compostos. Compor seguindo a override strategy consiste em definir que as overlapping parts do receiving profile deve sobrescrever as overlapping parts do merged profile.

Quando o relacionamento de composição tem override strategy como estratégia de composição, esta composição passa a ter a mesma semântica do relacionamento de herança. Um exemplo de composição seguindo esta estratégia de composição é mostrado na Figura 5.1. A superclasse (merged profile) terá o seu conteúdo (merged elements) que é equivalente ao da subclasse (receiving elements) sobrescritos. Ou seja, todo o receiving element que tiver algum merged element equivalente, sobrescreverá o merged element, dessa forma, sendo inserido no resulting profile.

5.1.2

Semântica de Override Strategy

Nesta Subseção é discutida a semântica que o relacionamento de composição assume quando é definido override strategy como a estretégia de composição.

Conforme anteriormente mencionado, override strategy é aplicada quando o pro- file precisa ter alguns dos elementos modificados, ou quando é necessário adicionar novos elementos, ou seja, especializá-lo. O relacionamento de composição baseado na override strategy especifica que os elementos de receiving profile deve sobrescrever os elementos

5.1. OVERRIDE STRATEGY 80 Topology <<profile>> <<metaclass>> Class <<metaclass>> Association <<stereotype>> LocalEdge <<stereotype>> Edge <<stereotype>> Node 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 <<stereotype>> LocalEdge name: String value: Integer <<stereotype>> Node <<stereotype>> Root <<streotype>> Leaf <<metaclass>> Association <<stereotype>> Edge A ) B ) E ) MainNode LocalEdge State C )

Herança Root Search Edge

Off Node Busy Leaf F ) location: String <<stereotype>> MainNode state: StateKind <<enumeration>> StateKind available busy Available StateKind <<enumeration>> StateKind available busy off <<stereotype>> MainNode state: StateKind Topology

Herança MainNode Edge LocalEdge

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: StateKind

Name

5.1. OVERRIDE STRATEGY 81 equivalentes do merged profile originando um resulting profile que possui todos elementos de receiving profile e todos os elementos de merged profile, exceto aqueles equivalentes aos do receiving profile, como mencionado anteriormente.

A maneira de identificar os elementos equivalentes, as overlapping parts, é especi- ficada no Capítulo 4. A composição seguindo a semântica de composição override strategy deve respeitar as seguintes regras, como segue:

Regra 01: para todo receiving element que possua um merged element equivalente im- plica que receiving element deve sobrescrevê-lo. A aplicação desta regra é ilustrada na Figura 5.1, onde é considerado a default match strategy como a base para a realização da definição da equivalência. Desse modo, observa-se três casos, como segue:

1. o stereotype Tree.Node sobrescreve o stereotype Topology.Node tendo TopologyTree.Node como resultado.

2. o enumeration Tree.StateKind sobrescreve o enumeration Topology.State-

Kind tendo TopologyTree.StateKind como resultado.

3. o stereotype Tree.Edge sobrescreve o stereotype Topology.Edge tendo TopologyTree.Edge como resultado.

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.1, é apresentado 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 profile sem alterações. Na Figura 5.1, é 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 problemas, como por exemplo confli- tos de nomes ou referência elementos que não existem. Caso exista, é necessário realizar algumas transformações. A aplicação desta regra é ilustrada na Figura 5.1, onde stereotype Tree.MainNode possui uma referência à enumeration StateKind. As enumeration Topology.StateKind e Tree.StateKind são equivalentes, o que implica em Tree.StateKind sobrescrever Topology.StateKind. Desse modo, surge um conference conflict, haja vista TreeTopology.MainNode faz referência à enume- ration Topology.StateKind que não existe. Este conflito é solucionado com a mudança de referência da enumeration Topology.StateKind para TreeTopology .StateKind.

5.2. UNION STRATEGY 82