• Nenhum resultado encontrado

para as features que não foram capturadas na subdiretriz

GOALS, SCENARIOS and CONTEXTS to SOFTWARE PRODUCT LINE - GSC2SPL

Subdiretriz 11.2: para as features que não foram capturadas na subdiretriz

11.1, será anotado no campo Elemento, o nome do elemento intencional do modelo i*-ortogonal que originou a feature.

Exemplo: o elemento que gerou a feature Medi@ é o nome da LPS (Medi@)

(subdiretriz 11.1). O elemento que gerou a feature Carrinho Compra é o elemento Carrinho Compra (subdiretriz 11.2).

Tabela 11. Tabela Goal2Feature da LPS Media Shop

Elemento Cardinalidade Elemento Pai Feature

Tipo Valor

Media@ Root [1..1] - Medi@

Gerenciar Loja Online Elemento [1..1] Medi@ Gerenciar Loja Online Pesquisar Item Elemento [1..1] Gerenciar Loja Online Pesquisar Item

Palavra Chave Elemento [1..1] Pesquisar Item Palavra Chave

Palavra Chave Elemento [1..1] Palavra Chave Palavra Chave

Gerar Estatística Elemento [1..1] Gerenciar Loja Online Gerar Estatística Carrinho de Compra Elemento [1..1] Gerenciar Loja Online Carrinho de Compra

Estatística Loja Elemento [1..1] Gerar Estatística Estatística Loja Estatística Por Cliente Elemento [1..1] Gerar Estatística Estatística Por Cliente

Estatística por Categoria Produto

Grupo <0..2> Gerar Estatística Estatística por Categoria Produto Estatísticas por Produto Grupo <0..2> Gerar Estatística Estatísticas por Produto Consultar Base de Dados Elemento [1..1] Pesquisar Item Consultar Base de Dados

Consultar Catalogo Elemento [1..1] Pesquisar Item Consultar Catalogo

Obter Detalhes Identificação Elemento [1..1] Carrinho de Compra Obter Detalhes Identificação

Adicionar Item Elemento [1..1] Carrinho de Compra Adicionar Item Finalizar Compra Elemento [1..1] Carrinho de Compra Finalizar Compra Exibir Alerta Web Elemento [1..1] Finalizar Compra Exibir Alerta Web

Via Email Grupo <1..1> Finalizar Compra Via Email

Via SMS Grupo <1..1> Finalizar Compra Via SMS

Tratar Online Elemento [1..1] Obter Detalhes Identificação Tratar Online Telefone Elemento [0..1] Obter Detalhes Identificação Telefone Formulário Seguro Grupo <1..1> Tratar Online Formulário Seguro Formulário Padrão Grupo <1..1> Tratar Online Formulário Padrão

Figura 22. Modelo de Features da LPS Medi@

Fonte: AUTOR (2015)

Atividade 5 - Refinamento do modelo de features

Nessa atividade é realizado o refinamento do modelo de features obtido na atividade 4. O refinamento é necessário caso o modelo de features possua alguma inconsistência ou não represente as features desejadas para a LPS. Essa atividade é realizada até que o engenheiro de domínio esteja satisfeito com o modelo de features.

Para BORBA (2009), as situações em que uma reorganização do modelo de features é necessária são: subfeature com mais de um pai, features repetidas, features colocadas em lugar inapropriado, features com nomes diferentes, mas com mesma semântica, feature com nomes que não representa operacionalização, entre outras.

Segundo GUEDES (2012), após refinar o modelo de feature, aconselha-se que o engenheiro de domínio compare o modelo anterior com o modelo refinado para verificar se há produtos que poderiam ser configurados anteriormente, mas não são possíveis com o modelo refinado. Caso isto aconteça, cabe ao engenheiro avaliar se

esses produtos devem fazer parte do escopo da LPS. Se sim, deve-se refatorar o modelo para que seja possível configurar todos os produtos pretendidos.

Exemplo: para o modelo de features obtido é necessário realizar o

refinamento no nome de algumas features, pois as mesmas não possuem nomes representativos. A feature Telefone é renomada para Obter Detalhes através do Telefone. A feature Tratar Online é renomeada para Obter Detalhe Online. Já a feature Via Email é renomeada para feature Alerta Via Email e a feature Via SMS é renomeada para Alerta Via SMS. As duas feature com o nome Palavra Chave são unificadas, tendo em vista que possuem a mesma semântica, e a feature unificada será renomeada para Obter Palavra Chave. A tabela Goa2Feature refinada é apresentada na Tabela 12 e o novo modelo de feature é apresentado na Figura 23.

Tabela 12. Tabela Goal2Feature refinada

Elemento Cardinalidade Elemento Pai Feature

Tipo Valor

Media@ Root [1..1] - Medi@

Gerenciar Loja Online Elemento [1..1] Medi@ Gerenciar Loja Online Pesquisar Item Elemento [1..1] Gerenciar Loja Online Pesquisar Item Obter Palavra Chave Elemento [1..1] Consultar Base de

Dados

Palavra Chave Gerar Estatística Elemento [1..1] Gerenciar Loja Online Gerar Estatística Carrinho de Compra Elemento [1..1] Gerenciar Loja Online Carrinho de Compra

Estatística Loja Elemento [1..1] Gerar Estatística Estatística Loja Estatística Por Cliente Elemento [1..1] Gerar Estatística Estatística Por Cliente

Estatística por Categoria Produto

Grupo <0..2> Gerar Estatística Estatística por Categoria Produto Estatísticas por Produto Grupo <0..2> Gerar Estatística Estatísticas por Produto Consultar Base de Dados Elemento [1..1] Pesquisar Item Consultar Base de Dados

Consultar Catalogo Elemento [1..1] Pesquisar Item Consultar Catalogo Obter Detalhes

Identificação

Elemento [1..1] Carrinho de Compra Obter Detalhes Identificação Adicionar Item Elemento [1..1] Carrinho de Compra Adicionar Item Finalizar Compra Elemento [1..1] Carrinho de Compra Finalizar Compra Exibir Alerta Web Elemento [1..1] Finalizar Compra Exibir Alerta Web

Alerta Via Email Grupo <1..1> Finalizar Compra Via Email Alerta Via SMS Grupo <1..1> Finalizar Compra Via SMS Obter Detalhe Online Elemento [1..1] Obter Detalhes

Identificação

Tratar Online Obter Detalhes através do

Telefone

Elemento [1..1] Obter Detalhes Identificação

Telefone Formulário Seguro Grupo <1..1> Obter Detalhe Online Formulário Seguro Formulário Padrão Grupo <1..1> Obter Detalhe Online Formulário Padrão

Figura 23. Modelo de features refinado

Fonte: AUTOR (2015)

Atividade 6: Elaboração dos Cenários de Caso de Uso

Com o modelo i*-ortogonal construído, também é possível gerar os cenários de caso de uso da LPS. Isso é feito seguindo diretrizes de mapeamento dos elementos dos modelos i* para cenários de casos de uso com variabilidade.

Em GUEDES (2012) foi realizado uma adaptação nas diretrizes propostas por SANTANDER (2002) para mapear diagramas i* em casos de uso. Essa adaptação foi motivada, pois as diretrizes originais não contemplavam o mapeamento de elementos com cardinalidade. As diretrizes adaptadas em GUEDES (2012) possibilitaram a obtenção de cenários de caso de uso com variabilidade a partir do modelo i*. Os cenários obtidos são descritos utilizando a técnica PLUSS.

A organização do mapeamento foi mantida de acordo com GUEDES (2012). O mapeamento é dividido em três passos: Descoberta de Atores, Descoberta de Casos de Uso para os Atores, Descoberta e Descrição dos Cenários de Casos de Uso. O passo Descoberta de Atores tem como objetivos realizar a descoberta dos atores de caso de uso a partir de atores do modelo de objetivos. O passo Descoberta de Caso de Uso para os Atores tem como objetivo realizar a descoberta de casos de uso a partir das dependências atribuídas ao ator que representa a LPS.

Já o passo Descrição dos Cenários de Casos de Uso tem como intuito descobrir os passos do cenário principal. Para realizar o mapeamento, as seguintes diretrizes devem ser seguidas.

Passo 1 - Descoberta de Atores