Experimento 1 – Transformação Manual

A Figura 45 apresenta o Modelo de Features produzido manualmente a partir da especificação PL-AOVgraph de Smart Home, sem que os participantes tivessem acesso às regras de mapeamento. Podemos observar que os participantes optaram por não excluir nenhum elemento PL-AOVgraph (task, goal, softgoal), exceto os que possuíam a propriedade isFeature configurada como no (“Activate Alarm [Visual]” e “Activate Alarm [Sound]”), nem agrupar requisitos para formar uma feature. Mesmo sem ter acesso as nossas regras, os membros deste grupo decidiram realizar o mapeamento “1 para 1”, ou seja, cada elemento PL-AOVgraph é mapeado para uma feature, assim como no mapeamento implementado por ReqSys-MDD.

Quanto à nomeação das features, na maioria dos casos os participantes preferiram repetir o nome do elemento PL-AOVgraph. As exceções são: (i) Todos os filhos de “Low Response Time” foram nomeados apenas com o tópico do elemento PL-AOVgraph, que são as palavras entre colchetes, por exemplo, a softgoal “Low Response Time [Sprinkle Water]” deu origem a feature “Sprinkle Water”; (ii) Os filhos de “Availability” também foram nomeados com os tópicos (“Sensors” e “Actuators”), porém seus filhos receberam apenas parte do tópico, por exemplo, as softgoals “Availability [Movement Sensor]” e “Availability [Light Actuators]” deram origem as fetaures “Movement” e “Light”, respectivamente; (iii) Os filhos de “Safety” foram nomeados com a primeira e a última palavra do nome do elemento PL-AOVgraph, por exemplo, as softgoals “Safety to control [Doors]” e “Safety to Sprinkle Water” deram origem as features “Safety Doors” e “Safety Water”, respectivamente.

Experimento: ______________________________________________________________ Grupo: ___________________________________________________________________ Duração: ___:___ Dificuldades: ______________________________________________________________ Facilidades: _______________________________________________________________ Observações: ______________________________________________________________

Figura 45. Modelo de Features produzido manualmente a partir de PL-AOVgraph

Devido a renomeação, duas features foram nomeadas como “Fire”. A primeira é filha de “Sensors” e a segunda filha de “Actuators”, porém semanticamente duas ou mais features não podem possuir o mesmo nome. Neste caso uma delas deveria ser uma feature de referência.

Os participantes decidiram mudar a hierarquia dos elementos “Security” e “Accessibility”. Para eles a feature “Security” se adequa melhor como filha de “Safety” e “Accessibility” como filha de “Usability”. Além disso, em vez de utilizarem anotações para representar informações adicionais no Modelo de Features, por exemplo, “correlations” e “crosscuttings”, optaram por utilizar atributos. Porém, como relatado na seção 2.1, os atributos são elementos que permitem que cada feature possua um valor, que pode ser uma string, um booleano, um inteiro, etc, enquanto as anotações definidas pelo usuário permitem adicionar propriedades às features, além das básicas, permitindo uma maior customização do modelo. Dessa forma, quando a intenção é adicionar propriedades ao modelo, as anotações são mais adequadas que os atributos. Em XFeature as anotações são visualizadas apenas através da View Properties, para que o corpo do Modelo de Features não fique

sobrecarregado com tanta informação. O conteúdo dos atributos também só é visualizado através da View Properties, porém cada feature que possui um atributo é marcada com um círculo vermelho.

Os relacionamentos de correlação foram representados através de atributos, de forma que a feature correspondente ao elemento source recebeu o atributo e no conteúdo deste foi registrado o tipo e o destino da correlação. Por exemplo, podemos ver na Figura 45 que a feature “Safety” possui o círculo vermelho que indica um atributo, ao selecionar este símbolo é exibido na View Properties o seguinte conteúdo: hurt {Low Response Time}, que indica que a feature “Safety” afeta “Low Responde Time”. Os participantes deixaram de representar no Modelo de Features três dos relacionamentos de correlação da especificação PL-AOVgraph.

Uma vez que o Modelo de Features não é orientado a aspectos, no mapeamento implementado em ReqSys-MDD optamos por realizar a composição das características transversais, através de features de referência, sem perder as informações do relacionamento transversal, armazenando-as em anotações, para o caso da transformação inversa. A composição consiste em espalhar e entrelaçar os requisitos modelados inicialmente de maneira separada através do crosscutting (Silva, 2006). Porém, os participantes que realizaram esta transformação manual, alegaram que realizar a composição das características transversais no Modelo de Features o torna sobrecarregado com as features de referência desnecessariamente, uma vez que é possível representar todas as informações do crosscutting no conteúdo dos atributos. Dessa forma, eles decidiram adicionar um atributo a feature correspondente ao elemento source e em seu conteúdo registraram as demais informações do crosscutting. Por exemplo, na Figura 45 podemos observar que a feature “Accessibility”, por ser o source de um dos crosscuttings, possui um atributo, ao selecioná-lo obtemos o seguinte conteúdo na View Properties: include task "Reposition Authentication Device" in {Card Reader + Keypad + Eye Recognition + Finger Print} ; substitute atr "Keypad Type" = "Embossed keys" in {Keypad}. A sintaxe elaborada pelos participantes é confusa pelos seguintes motivos: (i) A primitiva (include) vem antes do advice e não dos pointcuts; (ii) O operador and é representado pelo símbolo “+” e o operador or pelo símbolo “-”; (iii) Intertype Declarations do tipo attribute são indicados pela palavra “atr” e do tipo element pela palavra “in”.

Uma vez que os participantes optaram por não realizar a composição das características transversais no Modelo de Features, mas apenas registrar o conteúdo dos crosscuttings nos atributos, ocorreram duas inconsistências. Podemos observar que as features “Presence Simulation” e “Turn Off” possuem um agrupamento do tipo inclusive-or

(cardinalidade 1-n), porém só existe uma feature dentro de cada agrupamento, que são “Regulate Blind” e “Regulate Thermostat”, respectivamente, o que semanticamente é uma inconsistência, uma vez que um grupo deve ser formado por no mínimo duas features. Se fosse realizada a composição isto não aconteceria, pois o elemento declarado no corpo do advice seria espalhado em todos os pointcuts. Dessa forma, o grupo de “Presence Simulation” seria formado pelas features “Regulate Blind” e “Regulate Intensity Light”, e o grupo de “Turn Off” pelas features “Regulate Thermostat” e “Regulate Intensity Light”.

Uma dificuldade citada pelos participantes é que durante a modelagem o Modelo de Features tornava-se cada vez maior, isto dificultou a organização das features e a visualização do modelo como um todo através de XFeture, o que é essencial para a identificação de todos os elementos necessários ao Modelo de Features.