1 / 30

Thelma Elita Colanzi

Validação experimental de uma abordagem baseada em busca para projeto de arquitetura de linha de produto de software. Thelma Elita Colanzi. Adaptação do material gentilmente cedido por : Mestrando: Anderson da Silva Marcolino Orientador: Prof. Dr. Edson A. Oliveira Junior

zelia
Download Presentation

Thelma Elita Colanzi

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Validação experimental de uma abordagem baseada em busca para projeto de arquitetura de linha de produto de software Thelma ElitaColanzi Adaptação do material gentilmente cedido por : Mestrando: Anderson da Silva Marcolino Orientador: Prof. Dr. Edson A. Oliveira Junior UEM – Universidade Estadual de Maringá

  2. Agenda • Linha de Produto de Software • SMarty – Abordagem para Gerenciamento de Variabilidades • Organização dos documentos do experimento

  3. Linha de Produto de Software • Abordagem que objetiva promover a geração de produtos específicos com base na reutilização de uma infraestrutura central - núcleo de artefatos - formada por uma arquitetura de software e seus componentes.

  4. Linha de Produto de Software Quais seriam as possíveis diferenças entre os produtos dessa linha de produção?

  5. Linha de Produto de Software • Por meio desta abordagem, é possível explorar as semelhanças dos seus produtos para aumentar o reúso de artefatos. • A abordagem de LPS tem sido adotada na indústria de software. • Vantagens: • Maior reutilização de artefatos; • Maximização de lucros; • Diminuição do time tomarket; • Diminuição de riscos; • Produtos com maior qualidade; • Contribuição para o aprimoramento; • ROI; etc.

  6. Linha de Produto de Software • Atividades Essenciais de LPS Arquitetura da LPS Arquitetura de cadaproduto da LPS

  7. Linha de Produto de Software • A base de uma LPS é seu núcleo de artefatos. • arquitetura da LPS, os componentes reusáveis, modelos de domínio, requisitos da LPS, modelos de características e planos de teste. • Uma característica(feature) é uma capacidade do sistema que é relevante e visível para o usuário final. • O modelo de características inclui todas as características de uma LPS e os seus inter-relacionamentos. • A definição explícita de variabilidades em LPS é a diferença chave entre o desenvolvimento de sistemas únicos e o desenvolvimento de LPS.

  8. Linha de Produto de Software • Exemplo de Modelo de Características Legenda: CaracterísticaObrigatória CaracterísticaOpcional MutualmenteInclusivas MutualmenteExclusivas

  9. Linha de Produto de Software • Variabilidade é a forma comoosmembros de umafamília de produtospodem se diferenciar entre si. • O gerenciamento de variabilidades é uma das atividades mais importantes no gerenciamento de uma LPS. • A variabilidade é descrita por pontos de variação e variantes.

  10. Linha de Produto de Software • Ponto de variação: Um local específicode um artefato em que uma decisão de projeto ainda não foi tomada; • Variante: Corresponde a uma alternativa de projeto para resolver uma determinada variabilidade. • Restrições entre variantes: define os relacionamentos entre duas ou mais variantes para que seja possível resolver um ponto de variação ou uma variabilidade.

  11. Gerenciamento de Variabilidade Artefato de uma Linha de Produto Variabilidade Similaridades Pontos de Variação

  12. Gerenciamento de Variabilidade Artefato de uma Linha de Produto Variabilidade Variantes Pontos de Variação

  13. Gerenciamento de Variabilidade Artefato de uma Linha de Produto Variabilidade Pontos de Variação

  14. Gerenciamento de Variabilidade Restrições entre variantes Artefato de uma Linha de Produto Variabilidade Restrições entre variantes Pontos de Variação

  15. Gerenciamento de Variabilidade Restrições entre variantes Opcionais – podem ser selecionadas ou não. Ou – uma ou mais podem ser selecionadas. Restrições entre variantes Mutualmente exclusivas (alternativa - XOR) – apenas uma delas deve ser selecionada.

  16. Gerenciamento de Variabilidade Possíveis produtos da LPS

  17. Gerenciamento de Variabilidade Ou – uma ou mais podem ser selecionadas. Possíveis produtos da LPS (alternativa - XOR) – apenas uma delas deve ser selecionada. Opcionais – podem ser selecionadas ou não.

  18. Abordagem SMarty para Gerenciamento de Variabilidades

  19. Abordagem SMarty

  20. Abordagem SMarty Legenda: CaracterísticaObrigatória CaracterísticaOpcional MutuamenteInclusiva MutuamenteExclusiva <<optional>> <<mandatory>> <<alternative_XOR>> <<alternative_OR>>

  21. Abordagem SMarty • As variabilidades são identificadas por meio do comentário UML, estereotipada com <<variability>> contendo os seguintes meta atributos: • Name: nome da variabilidade; • minSelection: a quantidade mínima de variantes a serem selecionadas; • maxSelection: a quantidade máxima de variantes a serem selecionadas; • bindingTime: em qual momento a variabilidade será resolvida; • allowsAddingVar: se permite incluir novas variantes para resolver o ponto de variação; e • variants: quais as variantes para resolver o ponto de variação (casos de uso ligados ao ponto de variação). • Estas notas são inseridas em todas as variabilidades.

  22. Abordagem SMarty Diretrizes • D.2.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 exclusiva; • D.2.3 Em modelos de caso de uso relacionadas com a associação de inclusão (<<include>>) ou associados a atores sugerem variantes obrigatórias ou opcionais; • D.2.5 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>>; • D.2.6 Variantes mutuamente exclusivas para um determinado produto devem ter seus relacionamentos de dependência marcados com o estereótipo <<mutex>>;

  23. Abordagem SMarty Exemplo de Diagrama de Casos de Uso com Representação de Variabilidades

  24. Abordagem SMarty Exemplo de Identificação de Variabilidade em Casos de Uso

  25. Abordagem SMarty Diretrizes • D.2.2 Em modelos de classes, pontos de variação e suas variantes são identificadas nos seguintes relacionamentos: • Generalização, os classificadores mais gerais são os pontos de variação, enquanto os mais específicos são as variantes; • Realização de interface, os “suppliers” (especificações) são os pontos de variação e as implementações (clientes) são as variantes; • 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 • 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. • D.2.4 Elementos de modelos de classes, relacionados à associações nas quais os seus atributos aggregationKind possuem valor none, ou seja, não representam agregação nem composição, sugerem variantes obrigatórias ou opcionais. • D.2.7 Componentes formados por classes com variabilidades são marcados com o estereótipo <<variable>>.

  26. Abordagem SMarty Exemplo Parcial de Diagrama de Classes com Representação de Variabilidades

  27. Mapeamento de Características na arquitetura da LPS • Uma das formas de se implementarcaracterísticas de LPS é tratandocadaumadelascomo um interessepresentenafamília. • Interesses correspondem a requisitos, funcionais ou não, que devem estar presentes no sistema. • Alguns são naturalmente transversais e, por isso, se espalham em vários pontos dentro do software. • Quanto mais modularizado um interesse estiver dentro do projeto do software mais reusável será o seu projeto. • Osinteressespodemsermapeadosemartefatos da LPS usandoestereótipos UML.

  28. Mapeamento de Características na arquitetura da LPS Exemplo de Interface com Interesses associados usando estereótipos UML

  29. Experimento • Doc. 1 – Termo de Adesão * • Doc. 2 – Questionário de Caracterização • Doc. 3 – Conceitos de LPS e SMarty • Doc. 4 – Descrição Geral da LPS * • Doc. 5 – Formulário Experimento * * Doc. 1, Doc. 4 e Doc. 5 variamparacadauma das LPS.

  30. Perguntas?

More Related