SMartyProcess

O SMartyProcess segue as atividades gerais relacionadas às especificadas no processo de desenvolvimento de LPS [1]. Tal relacionamento pode ser observado por meio da Figra 4, em um diagrama de atividades da UML. Nela é possível observar o processo genérico de Desenvolvimento de Linha de Produto, representado pelas atividades alinhadas no lado esquerdo e o SMartyProcess representado pelas atividades do retângulo à direita [2].

SMarty combina o SMartyProfile e o SMartyProcess, gerando uma abordagem guiada por diretrizes para gerenciar sistematicamente variabilidades de LPS.

O SMartyProcess é realizado pelo engenheiro de LPS e é um processo iterativo e incremental. Iterativo, pois ocorre após a execução de cada atividade do desenvolvimento de LPS e incremental, pois o número de variabilidades tende a crescer, à medida que as atividades do SMartyProcess são executadas.

O SMartyProcess utiliza-se de elementos do núcleo de artefatos de uma LPS, bem como o alimenta com outros. Por exemplo, os modelos de casos de uso e de classes alimentam o SMartyProcess e retornam para o núcleo com as variabilidades identificadas e representadas.

A cada ciclo de interação entre o Desenvolvimento de LPS e o SMartyProcess, a atividade de identificação de variabilidades recebe como entrada os modelos de casos de uso, classes, atividades e componentes. Por meio dessa atividade, identificam-se progressivamente as variabilidades associadas a esses modelos.

A identificação de variabilidades é uma atividade que depende do domínio, o que exige habilidade dos gerentes e analistas de LPS. Para que essa atividade possa ser realizada e concretizada com sucesso o SMartyProcess fornece um conjunto de diretrizes [2,3].

Diretrizes para Identificação e Representação de Variabilidade (RV)

Assim, para a identificação e a representação de variabilidades aplicando o SMartyProfile, as seguintes diretrizes do SMartyProcess podem ser sequidas:

• RV.1 Variabilidades com variantes opcionais (optional) possuem multiplicidade minSelection=0 e maxSelection=1;
• RV.2 Variabilidades com variantes exclusivas (alternative_XOR) possuem multiplicidade minSelection=maxSelection=1;
• RV.3 Variabilidades com variantes inclusivas (alternative_OR) possuem multiplicidade minSelection=1 e maxSelection= size(variants) em que size(x) é uma função que retorna a quantidade de elementos da coleção x;
• RV.4 O valor bindingTime deve ser definido escolhendo-se um dos valores da classe de enumeração BindingTime, que são: DESIGN_TIME, LINK_TIME, COMPLE_TIME, RUNTIME;
• RV.5 O valor booleano do atributo allowsAddingVar deve ser analisado de acordo com a possibilidade de manter o ponto de variação aberto (true) ou fechado (false); e
• RV.6 O valor da coleção variantes é o conjunto formado pelas instâncias das variantes associadas ao ponto de variação ou variabilidade.

Diretrizes para Casos de Uso (UC)

• UC.1 Elementos de modelos de casos de uso relacionados aos mecanismos de extensão e de pontos de extensão sugerem pontos de variação com variantes associadas, as quais podem ser inclusivas ou exclusivas;
• UC.2 Modelos de casos de uso com o relacionamento de inclusão (« include ») ou associados a atores sugerem variantes obrigatórias ou opcionais;
• UC.3 Variantes que, ao serem selecionadas para fazer parte de um produto, exigem a presença de outra(s) determinada(s) variante(s) devem ter seus relacionamentos de dependência marcados com o estereótipo « requires »;
• UC.4 Variantes mutuamente exclusivas para um determinado produto devem ter seus relacionamentos de dependência marcados com o estereótipo « mutex ».

Diretrizes para Diagrama de Classes (CL)

• CL.1 Em modelos de classes, pontos de variação e as suas variantes são identificadas nos seguintes relacionamentos:
  • a) generalização, os classificadores mais gerais são os pontos de variação, enquanto os mais específicos são as variantes;
  • b) realização de interface, os suppliers (especificações) são os pontos de variação e as implementações (clientes) são as variantes;
  • c) agregação, as instâncias tipadas com losangos não preenchidos são os pontos de variação e as instâncias associadas são as variantes; e
  • d) composição, as instâncias tipadas com losangos preenchidos são os pontos de variação e as instâncias associadas são as variantes.
• CL.2 Elementos de modelos de classes, relacionados às associações nas quais os seus atributos aggregationKind possuem valor none, ou seja, não representam nem agregação nem composição, sugerem variantes obrigatórias ou opcionais.
• CL.2.1 Elementos de modelos de classes, relacionadas às associações nas quais os seus atributos aggregationKing possuem valor * (zero ou mais) ou 0..n onde n é um número inteiro qualquer, diferente de zero, sugerem que tal classe é opcional.
• CL.3 Variantes em modelos de classes, que ao serem selecionadas para fazer parte de um produto, exigem a presença de outra(s) determinada(s) variante(s) devem ter seus relacionamentos de dependência marcados com o estereótipo « requires »;
• CL.4 Variantes em modelos de classes, mutuamente exclusivas para um determinado produto devem ter seus relacionamentos de dependência marcados com o estereótipo « mutex ».

Diretrizes para Componentes (CP)

• CP.1 Componentes formados por classes com variabilidades são marcados com o estereótipo « variable ».

Diretrizes para Diagrama de Atividades (AT)

• AT.1 Elementos de modelos de diagramas de atividades como DecisionNode sugerem pontos de variação marcados com « variationPoint », pois é um local formado explicitamente por possíveis caminhos para grupos de ações distintas;
• AT.2 Elementos Action dos diagramas de atividades podem ser definidos como variantes obrigatórias ou opcionais;
• AT.3 Elementos Action que representam fluxos alternativos de saída de um DecisionNode sugerem variantes alternativas inclusivas ou exclusivas;
• AT.4 Elementos ActivityPartition que possuem elementos variáveis, DecisionNode como ponto de variação ou Action como variantes, devem ser marcados como « variable », pois são compostos por elementos que sofrem algum tipo de variação.

Diretrizes para Diagrama de Sequência (SQ)

• SQ.1 Elementos de diagramas de sequência como CombinedFragment que possuem do interactionOperator do tipo "alt" (alternative), ou seja, variantes mutuamente exclusivas, sugerem pontos de variação marcados com « variationPoint » e serão relacionados a um comentário da UML especificando a variabilidade (« variability »). As variantes correspondentes às mensagens devem ser estereotipadas como « alterna tive_XOR »;
• SQ.2 Em diagramas de sequência, as duas possíveis ocorrências a seguir, sugerem variantes opcionais:
  • a) Elementos de diagramas de sequência como o CombinedFragment que possuem interactionOperator do tipo "opt" (optional) sugerem variantes opcionais, sendo estereotipados como « optional », e são relacionados a um comentário da UML especificando a variabilidade (« variability »). Os lifelines contidos nesse CombinedFragment e que fazem parte da variabilidade deverão ser estereotipados também como « optional »;
  • b) Troca de mensagens entre dois objetos não obrigatórios, ou entre um objeto obrigatório e outro não, sugerem uma variante opcional, estereotipadas como « optional » e estarão relacionados a um comentário da UML especificando a variabilidade (« variability »). A(s) lifeline(s) correspondente(s) a essa variante será(ão) estereotipada(s) também como « optional ».
• SQ.3 O elemento interactionUse "ref" sugere ponto de variação para variantes alternativas inclusivas, sendo estereotipado como « variationPoint » e relacionado a um comentário da UML, que identifica os elementos da variabilidade (« variability »). Os diagramas de sequência referenciados pelo interactionUse "ref" correspondem às variantes do ponto de variação, são considerados portanto, alternativos inclusivos, podendo um ou mais serem selecionados, sendo estereotipadas como « alternative_OR ».
• SQ.4 As mensagens (messages) que são independentes dos fluxos contidos no CobinedFragment "alt", "opt", interactionUse "ref", ou não estejam relacionadas diretamente a uma variabilidade e seus elementos, são mantidas sem estereótipos e consideradas assim, obrigatórias;
• SQ.5 Variantes em diagramas de sequência que, ao serem selecionadas para fazer parte de um produto específico, exigirem a presença de outra(s) determinada(s) variante(s) devem ter seus relacionamentos de dependência marcados com o estereótipo « requires »;
• SQ.6 Variantes mutuamente exclusivas de um diagrama de sequência, para um determinado produto devem ter seus relacionamentos de dependência marcados com o estereótipo « mutex ».