MDA-gerenciamento

1.258 visualizações

Publicada em

Uso do MDA com uma abordagem de gerenciamento de variabilidade em SPL

Publicada em: Tecnologia, Turismo, Negócios
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
1.258
No SlideShare
0
A partir de incorporações
0
Número de incorporações
9
Ações
Compartilhamentos
0
Downloads
44
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

MDA-gerenciamento

  1. 1. Uso do MDA com uma abordagem de gerenciamento de variabilidade em SPL Alexandre Cavalcanti Milene Fiorio Agosto/2005
  2. 2. Roteiro <ul><li>MDA </li></ul><ul><li>SPL </li></ul><ul><li>SPL e Variabilidade </li></ul><ul><li>MDA e Variabilidade </li></ul><ul><li>MDA e SPL </li></ul><ul><li>MDA, SPL e Variabilidade </li></ul><ul><li>Exemplo </li></ul><ul><li>Conclusão </li></ul>
  3. 3. MDA <ul><li>MDA é uma abordagem de desenvolvimento de sistemas que se baseia na idéia da separação da especificação das funcionalidades do sistema dos detalhes de implementação [OMG] </li></ul><ul><li>Principais Objetivos </li></ul><ul><ul><li>Portabilidade </li></ul></ul><ul><ul><li>Interoperabilidade </li></ul></ul><ul><ul><li>Reutilização </li></ul></ul>
  4. 4. MDA <ul><li>MDA define mecanismos para: </li></ul><ul><ul><li>Especificar o sistema independente da plataforma que o suporta </li></ul></ul><ul><ul><li>Especificar plataformas </li></ul></ul><ul><ul><li>Escolher uma plataforma para um sistema </li></ul></ul><ul><ul><li>Transformar a especificação do sistema em uma plataforma específica </li></ul></ul><ul><li>Esta abordagem ajuda a focar nos aspectos de negócio da solução ao invés dos aspectos técnicos </li></ul>
  5. 5. MDA <ul><li>MDA sugere um desenvolvimento baseado na utilização de modelos para direcionar o entendimento, projeto, construção, instalação e manutenção dos sistemas </li></ul><ul><li>Esta abordagem recomenda a criação de modelos em três níveis de abstração: </li></ul><ul><ul><li>Modelo Independente de Computação </li></ul></ul><ul><ul><li>Modelo Independente de Plataforma </li></ul></ul><ul><ul><li>Modelo Específico de Plataforma </li></ul></ul>
  6. 6. MDA Viewpoints Modelos Independente de Computação Independente de plataforma Específico de Plataforma CIM PIM PSM
  7. 7. MDA
  8. 8. MDA e outras abordagens <ul><li>Linha de Produtos de Software </li></ul><ul><li>Variabilidade </li></ul><ul><li>Desenvolvimento Baseado em Componentes </li></ul><ul><li>Programação Orientada a Aspectos </li></ul><ul><li>Fábricas de Software </li></ul><ul><li>Linguagem Específica de Domínio </li></ul><ul><li>Programa Generativo </li></ul><ul><li>Web Semântica </li></ul><ul><li>Ontologias </li></ul><ul><li>etc </li></ul>
  9. 9. MDA <ul><li>Benefícios: </li></ul><ul><ul><li>Reutilização </li></ul></ul><ul><ul><li>Portabilidade a outras plataformas </li></ul></ul><ul><ul><li>Produtividade </li></ul></ul><ul><ul><li>Manutenibilidade </li></ul></ul><ul><ul><li>Alto nível de abstração (Revolução MDA) </li></ul></ul>
  10. 10. Reuso <ul><li>Reuso é um dos maiores objetivos da engenharia de software </li></ul><ul><ul><li>Ganho em produtividade e qualidade </li></ul></ul><ul><li>Uma aplicação deveria ser desenvolvida pela composição de componentes </li></ul><ul><ul><li>Aplicação fácil de ser montada e robusta </li></ul></ul><ul><li>Reuso visa acelerar a construção de uma aplicação e diminuir os custos de manutenção </li></ul><ul><ul><li>O desenvolvimento de um componente que seja realmente reutilizado tem um custo significante </li></ul></ul><ul><ul><li>Este componente deve ser muito utilizado! </li></ul></ul>
  11. 11. Reuso <ul><li>O sucesso do reuso pode ser medido por: </li></ul><ul><ul><li>Escopo do reuso para um componente reusável </li></ul></ul><ul><ul><ul><li>Atingido pelas bibliotecas </li></ul></ul></ul><ul><ul><ul><ul><li>Componentes genéricos e pequenos </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Não dependem do domínio da aplicação </li></ul></ul></ul></ul><ul><ul><ul><ul><li>O nível de funcionalidade é relativamente baixo </li></ul></ul></ul></ul><ul><ul><ul><li>Atingido por componentes largos </li></ul></ul></ul><ul><ul><ul><ul><li>Sistema de gerenciamento de banco de dados </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Não dependem do domínio da aplicação </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Suportam variabilidade interna (schemas, arquivos de configuração, etc) </li></ul></ul></ul></ul>
  12. 12. Reuso <ul><ul><li>Taxa de reuso na aplicação (quantidade de código / novo código) </li></ul></ul><ul><ul><ul><li>Arquiteturas de linha de produtos </li></ul></ul></ul><ul><ul><ul><li>Reuso ocorre no escopo limitado de uma linha de produtos </li></ul></ul></ul><ul><ul><ul><li>Escopo de reuso relativamente baixo </li></ul></ul></ul>
  13. 13. SPL <ul><li>Linha de produtos de software (SPL) consiste em uma família de sistemas de software que possuem algumas funcionalidades comuns e algumas funcionalidades variáveis </li></ul><ul><li>Para obter vantagens das funcionalidades comuns, recursos reusáveis são desenvolvidos para que possam ser reusados por diferentes membros da família </li></ul>
  14. 14. SPL <ul><li>O interesse em SPL aumentou quando desenvolvedores descobriram, que eles poderiam obter muito mais benefícios reutilizando arquiteturas de software ao invés de reutilizar componentes de software </li></ul><ul><li>A idéia de SPL não é nova </li></ul><ul><ul><li>As pirâmides do Egito devem ter sido as primeiras linhas de produto </li></ul></ul><ul><ul><li>Um exemplo moderno são os aviões da AirBus que compartilham características comuns como equipamento de navegação e de comunicação </li></ul></ul>
  15. 15. SPL <ul><li>O desenvolvimento é feito considerando uma família de sistemas de software </li></ul><ul><li>Envolve análise de características (requisitos funcionais) comuns, características opcionais e características alternativas </li></ul><ul><ul><li>Após análise das características, o objetivo é fazer o design da arquitetura de software para a linha de produtos </li></ul></ul><ul><ul><li>Esta arquitetura possui </li></ul></ul><ul><ul><ul><li>Componentes comuns  Requeridos por todos os membros </li></ul></ul></ul><ul><ul><ul><li>Componentes opcionais  Requeridos por alguns membros </li></ul></ul></ul><ul><ul><ul><li>Componentes variáveis  Diferentes versões são requeridas por diferentes membros </li></ul></ul></ul>
  16. 16. SPL <ul><li>A arquitetura de um SPL é a arquitetura para uma família de produtos </li></ul><ul><li>A maioria dos desenvolvimentos de linha de produtos provê uma arquitetura genérica para a linha de produtos que descreve as igualdades entre os membros mas ignora toda a variabilidade </li></ul><ul><li>Cada aplicação começa com uma arquitetura genérica e adapta manualmente as requisições </li></ul><ul><li>Esta abordagem provê um melhor ponto de começo em comparação a um desenvolvimento de um sistema sem nenhum reuso </li></ul><ul><ul><li>Mas falha ao capturar qualquer conhecimento sobre a variabilidade da família de produtos </li></ul></ul>
  17. 17. SPL <ul><li>Uma abordagem desejável é modelar o que é comum e o que é diferente na família de produtos </li></ul><ul><ul><li>Uma arquitetura de SPL deve descrever as igualdades e a variabilidade na família </li></ul></ul>
  18. 18. Modelando variabilidade em SPL <ul><li>Modelar igualdades e variabilidade é uma atividade muito importante no desenvolvimento de SPL </li></ul><ul><li>Variabilidade em SPL pode ser modelada no nível de requisitos de software e no nível de design de software </li></ul>
  19. 19. Modelando variabilidade em SPL: Nível de requisitos <ul><li>Funcionalidades são um importante conceito em SPL porque elas representam requisitos reusáveis ou características de uma linha de produto </li></ul><ul><li>Conceito de Funcionalidades é intuitivo e se aplica em todas as linhas de produto </li></ul><ul><ul><li>Por exemplo, linha de produtos de veículo </li></ul></ul><ul><li>Funcionalidades podem ser obrigatórias, opcionais ou mutuamente exclusivas </li></ul><ul><li>A árvore de Funcionalidades é uma composição hierárquica de Funcionalidades onde alguns ramos são obrigatórios, alguns opcionais e outros mutuamente exclusivos </li></ul>
  20. 20. Modelando variabilidade em SPL: Nível de design <ul><li>Técnicas para modelar variabilidade em nível de design incluem modelagem de variabilidade utilizando: </li></ul><ul><ul><li>Parametrização </li></ul></ul><ul><ul><li>Informação escondida </li></ul></ul><ul><ul><li>Herança </li></ul></ul>
  21. 21. Utilizando parametrização <ul><li>Parâmetros podem ser usados para introduzir variabilidade em uma SPL </li></ul><ul><li>Os valores dos parâmetros definidos nos componentes da linha de produtos estão onde as variações entram </li></ul><ul><li>Diferentes membros da linha de produtos devem ter diferentes valores atribuídos aos parâmetros </li></ul>
  22. 22. Utilizando parametrização <ul><li>Parametrização utiliza diferentes tipos de parâmetros </li></ul><ul><ul><li>Compilação </li></ul></ul><ul><ul><ul><li>Valores são setados em tempo de execução </li></ul></ul></ul><ul><ul><li>Configuração </li></ul></ul><ul><ul><ul><li>Valores são setados em tempo de configuração </li></ul></ul></ul><ul><ul><ul><li>Geração ou instalação do sistema </li></ul></ul></ul><ul><ul><li>Inicialização </li></ul></ul><ul><ul><ul><li>Valores são setados na inicialização do sistema </li></ul></ul></ul><ul><ul><li>Tabela </li></ul></ul><ul><ul><ul><li>Parâmetros guardados em tabelas </li></ul></ul></ul>
  23. 23. Utilizando informação escondida <ul><li>Diferentes versões de um componente possui a mesma interface mas diferentes implementações para diferentes membros da linha de produtos </li></ul><ul><li>A variabilidade está escondida em cada versão </li></ul><ul><li>Neste caso, os variantes são as diferentes versões do mesmo componente </li></ul>
  24. 24. Utilizando herança <ul><li>Diferentes versões de uma classe utiliza herança para herdar operações de uma superclasse e depois operações especificadas na superclasse interface são redefinidas e/ou a interface é estendida pela adição de novas operações </li></ul><ul><li>Para uma dado membro da linha de produtos, a aplicação seleciona a versão do componente </li></ul>
  25. 25. Comparação entre os métodos <ul><li>Utilizar parametrização permite que a aplicação defina os valores dos atributos da linha de produtos que são mantidos pelos vários componentes da linha de produtos </li></ul><ul><li>Se toda a variabilidade em uma linha de produtos pode ser definida em termos de parâmetros, este pode ser uma forma simples de prover variabilidade </li></ul><ul><li>Porém, a variabilidade fica limitada pois nenhuma funcionalidade pode ser mudada </li></ul>
  26. 26. Comparação entre os métodos <ul><li>Utilizar informação escondida permite a aplicação escolher variantes de um limitado conjunto de escolhas onde a interface é comum mas as implementações variam </li></ul><ul><li>Informação escondida permite um grau mais elevado de variabilidade pois funcionalidade e parâmetros podem variar </li></ul>
  27. 27. Comparação entre os métodos <ul><li>Utilizar herança permite a aplicação escolher variantes cuja funcionalidade pode variar </li></ul><ul><li>Esta abordagem permite um maior número de variantes estendendo a super classe em subclasses variantes </li></ul><ul><li>Na maioria das linhas de produtos, uma combinação das três abordagens são necessárias </li></ul>
  28. 28. Modelando Variabilidade em SPL: Estendendo UML <ul><li>FSB </li></ul><ul><ul><li>Criação de um símbolo especial, <<V>>, que representa a variabilidade </li></ul></ul><ul><ul><li>Elementos que não estão marcados com <<V>> são interpretados como comuns, caso contrário são variáveis </li></ul></ul><ul><ul><ul><li>Se uma classe está marcada com um <<V>> ela pode estar presente em algumas aplicações mas não em outras </li></ul></ul></ul><ul><ul><li><<V>> pode ser usado em operações, atributos e argumentos de operações </li></ul></ul>
  29. 29. Modelando Variabilidade em SPL: Estendendo UML <ul><li>KobrA </li></ul><ul><ul><li>Cada Komponent (Componente KobrA) na estrutura é descrito por um conjunto de diagramas UML como se cada um fosse um sistema independente </li></ul></ul><ul><ul><li>A especificação de cada Komponent é constituída de quatro modelos </li></ul></ul><ul><ul><li>O modelo estrutural, comportamental e funcional constitue a especificação do modelo de um Komponent </li></ul></ul><ul><ul><li>O modelo de decisão contém informações sobre como os modelos mudam para diferentes aplicações e também descreve as diferentes variações do Komponent </li></ul></ul>
  30. 30. Modelando Variabilidade em SPL: Estendendo UML <ul><li>PRAISE </li></ul><ul><ul><li>Uso do estereótipo <<hot spot>> para modelar componentes comuns </li></ul></ul><ul><ul><li>Uso da tagged value “variation point” para modelar pontos de variação </li></ul></ul>
  31. 31. Modelando Variabilidade em SPL: Estendendo UML <ul><li>SPLIT </li></ul><ul><ul><li>Uso de uma classe UML para descrever um ponto de variação </li></ul></ul><ul><ul><li>Esta técnica é muito atrativa no sentido que a variabilidade é imediatamente visível nos modelos UML </li></ul></ul><ul><ul><li>O uso desta técnica sistematicamente requer o desenvolvimento de scripts específicos e programas para gerenciá-los </li></ul></ul><ul><ul><li>O uso de uma classe para representar um ponto de variação dá apenas atributos, mas não comportamentos </li></ul></ul><ul><ul><li>Os atributos fornecem informação sobre uma variação para o reuso </li></ul></ul>
  32. 32. Modelando Variabilidade em SPL: Estendendo UML <ul><li>VPM </li></ul><ul><ul><li>Mostra como construir uma variação em um modelo de ponto de variação </li></ul></ul><ul><ul><li>Esta abordagem fornece um excesso de informação a ser gerenciada pelo designer em uma especificação de baixo nível </li></ul></ul>
  33. 33. Modelando Variabilidade em SPL: Estendendo UML <ul><li>Gomaa </li></ul><ul><ul><li>Este método permite a modelagem explícita das similaridades e variações entre membros de uma linha de produtos ou combinações de linhas de produtos </li></ul></ul><ul><ul><li>Várias vistas da UML são estendidas e usadas para modelar linhas de produtos e domínio de linha de produtos usando uma abordagem de integração da vista </li></ul></ul><ul><ul><li>Introdução de novos estereótipos </li></ul></ul><ul><ul><li>Classes e diagramas de classes são usadas para a modelagem de domínios de linhas de produtos </li></ul></ul><ul><ul><li>Agregação hierárquica e generalização/especialização hierárquica são usadas para representar a visão do modelo de domínio </li></ul></ul>
  34. 34. Modelando Variabilidade em SPL: Estendendo UML <ul><li>UMLAUT com OCL2 </li></ul><ul><ul><li>UMLAUT é uma estrutura para construção de ferramentas, dedicada a manipulação de modelos UML </li></ul></ul><ul><ul><ul><li>Usado para aplicar um modelo de transformação a um modelo UML, automatizando o processo de derivação que consiste em escrever a transformação de modelo relevante </li></ul></ul></ul><ul><ul><ul><li>Esta transfromação guarda os elemenotos do modelo usáveis graças a fábrica concreta selecionada e constrói um modelo UML especializado correspondente ao produto selecionado </li></ul></ul></ul><ul><ul><li>Tem como desafio a manutenção da integridade do modelo, através da preservação de suas constraints </li></ul></ul><ul><ul><ul><li>OCL2 permite a interpretação e preservação das constraints </li></ul></ul></ul>
  35. 35. Modelando Variabilidade em SPL: Estendendo UML Utiliza expressões OCL UMLAUT com OCL2 Introduz novos estereótipos para casos de uso e classes Gomaa Introduz novas visões e símbolos UML e extensões para descrever pontos de variação VPM Um ponto de variação é representado por uma classe UML. Define atributos para pontos de variação. SPLIT Pacote UML representa um ponto de variação que recebe o estereótipo <<hot spot>>. Qualquer colaboração recebe a tagged value “variation point” PRAISE Componente utiliza diagramas UML para especificar seu modelo estrutural, comportamental, funcional e de decisão KobrA Simbolo <<V>> para representar variabilidade FSB Extensão UML Método
  36. 36. Lições SPL <ul><li>Tenha uma abstrata e estável descrição do problema a ser resolvido </li></ul><ul><ul><li>O objetivo da arquitetura é identificar as funcionalidades comuns, seus relacionametos e onde as diferenças (variações) são esperadas </li></ul></ul><ul><ul><li>Esta arquitetura descreve o produto, em termos do ponto de vista funcional </li></ul></ul><ul><ul><li>Esta arquitetura é independente de tecnologia </li></ul></ul>
  37. 37. Lições SPL <ul><li>Identifique explicitamente as variações em termos de funcionalidades , não em termos de solução </li></ul><ul><ul><li>Pontos de variação são indicados na arquitetura abstrata em termos de funcionalidades abstratas </li></ul></ul><ul><li>Componentes com alta funcionalidade </li></ul><ul><ul><li>Arquitetura identifica conjuntos de funcionalidades comuns que se tornam os componentes </li></ul></ul>
  38. 38. Requisitos de família de linha de produtos <ul><li>Permitir evolução da arquitetura abstrata </li></ul><ul><ul><li>Escopo do reuso está relacionado com a capacidade do mecanismo de variação em descrever uma família </li></ul></ul><ul><li>Mecanismos de variação devem ser melhorados </li></ul><ul><ul><li>Geralmente, não há relação entre a descrição abstrata de uma funcionalidade com a sua implementação </li></ul></ul><ul><li>Um mapeamento mais alto nível entre a arquitetura abstrata e os componentes </li></ul><ul><li>Reutilizar componentes desenvolvidos em qualquer lugar </li></ul>
  39. 39. MDA e Variabilidade <ul><li>Variabilidade é um fator de qualidade que expressa a facilidade com que sistemas existentes podem ser adaptados e reutilizados. </li></ul><ul><li>Existe um conjunto de técnicas para tratar variabilidade </li></ul><ul><ul><li>geradores de aplicação </li></ul></ul><ul><ul><li>orientação a aspectos </li></ul></ul><ul><ul><li>extensões da UML </li></ul></ul><ul><ul><li>entre outros. </li></ul></ul><ul><li>A gerência de variabilidade é um fator importante no desenvolvimento de software. </li></ul><ul><ul><li>Ao invés de desenvolver e instalar um único sistema, é comum desenvolver uma família de sistemas cujos membros diferem nas funcionalidades oferecidas. </li></ul></ul>
  40. 40. MDA e Variabilidade <ul><li>Uma razão importante para introduzir variabilidade em um sistema é obter reutilização de software. </li></ul><ul><ul><li>Construir um sistema para cada variação implica em um aumento de esforço e tempo de desenvolvimento. </li></ul></ul><ul><ul><li>Construir estes múltiplos sistemas afeta o esforço necessário na fase de manutenção. </li></ul></ul><ul><li>O tipo principal de variabilidade é a funcional </li></ul><ul><ul><li>A variabilidade nas características fornecidas pelo software. </li></ul></ul><ul><ul><li>Este tipo de variabilidade é diretamente aparente aos usuários. </li></ul></ul>
  41. 41. MDA e Variabilidade <ul><li>O segundo tipo de variabilidade é a técnica </li></ul><ul><ul><li>A variabilidade nas técnicas de implementação utilizadas na construção do sistema. </li></ul></ul><ul><ul><li>Por exemplo, um determinado conjunto de funcionalidade necessita executar em diferentes plataformas. </li></ul></ul><ul><li>Em geral, os pontos de variação dos sistemas não são documentados. </li></ul><ul><ul><li>A existência de modelos de variabilidade torna estes pontos de variação explícitos. </li></ul></ul><ul><li>Diferentes técnicas para capturar variabilidade </li></ul><ul><ul><li>Engenharia de domínio </li></ul></ul><ul><ul><li>desenvolvimento baseado em componentes </li></ul></ul><ul><ul><li>abordagens orientadas a modelo </li></ul></ul><ul><ul><li>linguagens específicas de domínio </li></ul></ul><ul><ul><li>entre outros. </li></ul></ul>
  42. 42. MDA e Variabilidade <ul><li>A implementação ideal de variabilidade é criar componentes por funcionalidades e compor o sistema a partir destes componentes. </li></ul><ul><li>Recentemente, a variabilidade tem mostrado um aumento considerável e a gerência disto está se tornando um desafio no desenvolvimento e evolução dos artefatos de software. </li></ul><ul><ul><li>Um exemplo de abordagem onde esta gerência é considerada um desafio é o desenvolvimento baseado em componentes. </li></ul></ul>
  43. 43. MDA e SPL <ul><li>O SPL envolve várias atividades: </li></ul><ul><ul><li>Especificação do modelo de domínio que contém as funcionalidades do domínio </li></ul></ul><ul><ul><li>Um modelo de aplicação deve ser derivado do modelo de domínio através da seleção de funcionalidades alternativas </li></ul></ul><ul><ul><li>MDA é a possibilidade de automação das transformações que especificam como as instâncias do modelo de domínio são convertidas em uma aplicação </li></ul></ul><ul><ul><li>A definição de transformação pode ser vista com um compilador para uma DSL </li></ul></ul><ul><ul><li>A combinação dos modelos será compilada em aplicação utilizando definição de transformação, recursos e requisitos do cliente </li></ul></ul>
  44. 44. MDA e SPL <ul><li>Um sistema de software que é especificado de acordo com MDA é um caso particular de linha de produtos onde a maioria dos pontos de variação consiste de produtos que implementam a mesma funcionalidade em diferentes plataformas </li></ul><ul><ul><li>A escolha de plataformas alternativas é um ponto de variação em uma linha de produtos </li></ul></ul><ul><ul><li>Este ponto pode ser separado da especificação dos modelos e gerenciados na própria transformação </li></ul></ul><ul><ul><li>O gerenciamento dos pontos de variação é feito automaticamente pela transformação </li></ul></ul>
  45. 45. MDA e SPL <ul><li>Em uma linha de produtos, além dos pontos de variação, é necessário gerenciar os requisitos funcionais e não funcionais que diferem os membros de uma família </li></ul><ul><ul><li>A questão é se MDA pode facilmente acomodar estes requisitos variáveis adicionando a informação que especifica lugares onde conceitos alternativos podem ser selecionados </li></ul></ul><ul><ul><li>Seleção de diferentes conceitos de um modelo de domínio resulta em diferentes PIMs </li></ul></ul>
  46. 46. Gerenciamento de Variabilidade com MDA em SPL <ul><li>Engenharia de domínio identifica igualdades e diferenças entre os membros de uma família de produtos e implementa um conjunto de artefatos para serem compartilhados (componentes ou classes) </li></ul><ul><ul><li>Desta forma as igualdades podem ser compartilhadas </li></ul></ul><ul><ul><li>Habilidade de variar os produtos é preservada </li></ul></ul><ul><ul><li>Produtos são derivados da família de produtos utilizando subconjunto de artefatos compartilhados </li></ul></ul><ul><ul><li>Se necessário, novos recursos são criados </li></ul></ul>
  47. 47. Gerenciamento de Variabilidade com MDA em SPL <ul><li>A habilidade de derivar vários produtos a partir de uma família de produtos é chamada de variabilidade </li></ul><ul><ul><li>Gerenciar a habilidade de tratar as diferenças entre produtos nos vários estágios de desenvolvimento é considerado a chave do sucesso em SPL </li></ul></ul><ul><ul><li>Variabilidade é feita através de pontos de variação </li></ul></ul><ul><ul><ul><li>Partes no design ou implementação onde a funcionalidade deve variar </li></ul></ul></ul>
  48. 48. Gerenciamento de Variabilidade com MDA em SPL <ul><li>Aspectos importantes da variabilidade: </li></ul><ul><ul><li>Binding Time </li></ul></ul><ul><ul><ul><li>Se refere ao ponto no ciclo de vida de um produto onde uma alternativa particular para um ponto de variação é um limite do sistema </li></ul></ul></ul><ul><ul><li>Mecanismo de realização </li></ul></ul><ul><ul><ul><li>Técnica utilizada para realizar o ponto de variação (de uma implementação de ponto de vista) </li></ul></ul></ul><ul><ul><ul><li>Várias técnicas de realização têm sido identificadas </li></ul></ul></ul><ul><ul><ul><ul><li>Agregação </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Herança </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Parametrização </li></ul></ul></ul></ul>
  49. 49. Classificação de família de produtos e MDA <ul><li>Infra-estrutura padronizada </li></ul><ul><ul><li>Começa com desenvolvimento independente de cada produto </li></ul></ul><ul><ul><li>O primeiro passo para explorar as igualdades entre os produtos é reutilizar a forma com que os produtos são construídos </li></ul></ul><ul><ul><li>Reuso de metodologias de desenvolvimento são obtidas através da padronização com que aplicações individuais foram construídas </li></ul></ul><ul><ul><li>A infra-estrutura consiste em aspectos típicos como sistema operacional, gerenciador de banco de dados, uso de uma ferramenta específica, etc </li></ul></ul>
  50. 50. Classificação de família de produtos e MDA <ul><li>Plataforma </li></ul><ul><ul><li>Organização mantém uma plataforma no topo dos produtos que são construídos </li></ul></ul><ul><ul><li>Plataforma consiste na infra-estrutura, assim como os artefatos que capturam a funcionalidade específica de domínio que é comum a todos os produtos </li></ul></ul><ul><ul><li>Estes artefatos são construídos durante a engenharia de domínio </li></ul></ul><ul><ul><li>Uma plataforma é tratada como se fosse uma infra-estrutura externa </li></ul></ul>
  51. 51. Classificação de família de produtos e MDA <ul><li>Linha de produtos de software </li></ul><ul><ul><li>Toda a funcionalidade compartilhada por um subconjunto de membros de uma família de produtos é reutilizada, não somente a comum </li></ul></ul><ul><ul><li>Funcionalidade específica a um ou a alguns produtos é desenvolvida em artefatos específicos </li></ul></ul><ul><ul><li>As outras funcionalidades são projetadas e implementadas de forma que possam ser utilizadas em mais de um produto </li></ul></ul><ul><ul><li>Pontos de variação são adicionados para acomodar as diferentes necessidades dos vários produtos </li></ul></ul>
  52. 52. Classificação de família de produtos e MDA <ul><li>Família de produtos configuráveis </li></ul><ul><ul><li>A organização possui uma coleção de artefatos compartilhados que capturam quase todas as características comuns e diferentes dos membros da família de produtos </li></ul></ul><ul><ul><li>Geralmente, novos produtos são construídos a partir de um subconjunto dos artefatos </li></ul></ul><ul><ul><li>Quando este nível é alcançado, derivação de produtos é automática </li></ul></ul>
  53. 53. Gerenciamento de Variabilidade com MDA em SPL <ul><li>Um sistema que é especificado de acordo com MDA especifica um modelo para uma família consistindo de produtos que implementam a mesma funcionalidade em diferentes plataformas </li></ul>
  54. 54. Gerenciamento de Variabilidade com MDA em SPL <ul><li>A escolha para plataformas alternativas é um ponto de variação </li></ul><ul><li>Este ponto é separado do modelo da aplicação pois não é visível na especificação </li></ul>
  55. 55. Gerenciamento de Variabilidade com MDA em SPL <ul><li>O maior benefício do uso de MDA comparado ao desenvolvimento tradicional de SPF é que o gerenciamento do ponto de variação da plataforma é feita automaticamente pela transformação </li></ul><ul><li>A variação de plataforma não é o único ponto de variação que deve ser gerenciado em uma família de produtos </li></ul>
  56. 56. Gerenciamento de Variabilidade com MDA em SPL <ul><li>MDA pode ser estendido para suportar esta necessidade </li></ul><ul><ul><li>Adicionando modelo de domínio que especifica lugares onde conceitos alternativos podem ser selecionados </li></ul></ul><ul><ul><li>Seleção de conceitos diferentes deste modelo de domínio resulta em diferentes modelos de aplicação </li></ul></ul>
  57. 57. Gerenciamento de Variabilidade com MDA em SPL <ul><li>Transformações em MDA são poderosas o suficiente para se relacionarem não somente com variabilidade de plataforma, mas também com outros tipos de variabilidade </li></ul><ul><ul><li>Todas as variações nos modelos de domínio podem ser implementadas ou fornecidas pela infra-estrutura </li></ul></ul><ul><ul><li>MDA só fornece real benefício para uma família de produtos configuráveis </li></ul></ul>
  58. 58. Gerenciamento de Variabilidade com MDA em SPL
  59. 59. Derivação de produtos no mundo MDA <ul><li>Assumindo que há uma família de produtos de software configuráveis, os dois principais processos são: </li></ul><ul><ul><li>Engenharia de domínio </li></ul></ul><ul><ul><li>Engenharia de aplicação </li></ul></ul>
  60. 60. Engenharia de domínio <ul><li>Envolve a criação e manutenção da base de recursos </li></ul><ul><ul><li>Consiste de recursos reutilizáveis e/ou variáveis </li></ul></ul><ul><li>Envolve a especificação do modelo de domínio </li></ul><ul><ul><li>Consiste nos conceitos do domínio </li></ul></ul><ul><li>Envolve a definição de como será feita a transformação </li></ul><ul><ul><li>Especifica como as instâncias do modelo de domínio são convertidas em uma aplicação utilizando a base de recursos </li></ul></ul><ul><ul><li>Esta definição de transformação poderia ser um compilador para uma DSL </li></ul></ul>
  61. 61. Engenharia de aplicação <ul><li>Cria um modelo de aplicação selecionando conceitos de domínio alternativos a partir do modelo de domínio </li></ul><ul><li>Os conceitos alternativos são selecionados baseados nos requisitos do cliente </li></ul><ul><li>O modelo de aplicação é compilado para uma aplicação usando a definição de transformação, a base de recursos e os requisitos do cliente </li></ul><ul><li>O processo de transformação junta variabilidade em nível de infra-estrutura que não é visível no modelo de domínio </li></ul><ul><li>Pontos de variação que são selecionados em nível conceitual, para realização dos pontos de variação na infra-estrutura, também são juntados </li></ul>
  62. 62. Derivação de produtos no mundo MDA
  63. 63. Benefícios do gerenciamento da variabilidade <ul><li>Ao invés de poluir o modelo da aplicação com detalhes de implementação dos pontos variáveis no nível conceitual, isto é feito na transformação </li></ul><ul><li>A principal vantagem desta separação é que a escolha de um binding time particular e um mecanismo de realização podem ser adiados para o estágio onde o modelo da aplicação é compilado </li></ul><ul><li>Em outras palavras, quando as transformações são definidas, é possível selecionar um binding time e um mecanismo para o ponto de variação que seja mais adaptado aos requisitos durante a engenharia da aplicação </li></ul>
  64. 64. Benefícios do gerenciamento da variabilidade <ul><li>A separação da especificação da implementação permite a evolução independente: </li></ul><ul><ul><li>pontos de variação e variantes especificados nos conceitos de domínio </li></ul></ul><ul><ul><li>Variabilidade realizada na base de recursos </li></ul></ul><ul><li>Gerenciamento da evolução da variabilidade nos conceitos de domínio e infra-estrutura é movido para a definição de transformação </li></ul><ul><li>A definição de transformação é responsável pelo mapeamento entre os conceitos de domínio e infra-estrutura </li></ul><ul><li>Aplicações podem se beneficiar da infra-estrutura ou evolução da transformação com uma simples recompilação </li></ul>
  65. 65. Benefícios do gerenciamento da variabilidade <ul><li>Em casos onde as transformações não são tão boas, s ão necess árias adaptações no nível do PSM </li></ul><ul><ul><li>Quando há mudanças, não é possível muar o PIM e recompilá-lo pois as mudanças feitas no PSM serão perdidas </li></ul></ul><ul><li>MDA identifica a necessidade de round-trip </li></ul><ul><ul><li>Transformação reversível entre PIM e PSM </li></ul></ul><ul><li>Esta necessidae pode ser removida especificando as variações específicas de plataforma com pontos de variação no PIM </li></ul><ul><ul><li>Estes pontos de variação especificam onde as variações são permitidas </li></ul></ul><ul><ul><li>Durante a transformação, estas variações específicas de plataforma não inseridos ao PIM </li></ul></ul>
  66. 66. Dos requisitos ao PIM <ul><li>É possível automatizar o processo de derivação dos requisitos do cliente ao código, mas isto só é possível utilizando SPL </li></ul><ul><ul><li>É necessário a existência de um domínio estável onde uma arquitetura genérica do PIM tenha sido definida e desenvolvida </li></ul></ul><ul><li>O PIM contém as partes comuns e variáveis do sistema </li></ul><ul><ul><li>Isto deve ser levado em consideração quando um PIM específico para um cliente específico esteja sendo definido </li></ul></ul><ul><ul><li>Além disso, é necessário identificar que partes do PIM são comuns a todos os possíveis sistemas finais e que partes são dependentes dos requsitos dos usuários </li></ul></ul><ul><li>Esta atividade tem sido definida como análise do domínio onde as partes comuns e variáveis da linha de produtos são identificadas e especificadas conforme o modele de domínio da linha de produtos </li></ul>
  67. 67. Dos requisitos ao PIM <ul><li>As igualdades identificadas na análise do domínio formar ão a arquitetura base do PIM genérico </li></ul><ul><ul><li>As variabilidades determinarão pontos de variabilidade dentro do PIM genérico </li></ul></ul><ul><ul><li>Estes pontos de variação será resolvido com valores específicos que determinarão um PIM específico para requisitos específicos do usuário </li></ul></ul><ul><li>A idéia é capturar o conceito de PIM flexível </li></ul><ul><ul><li>Um PIM flexível é um PIM que contém igualdades e variabilidades na lógica de negócio do sistema </li></ul></ul><ul><li>Outro conceito importante é o modelo de decisão que irá conter todas as decisões dos clientes e que são implementadas no PIM flexível com o intuito de obter requisitos do usuário </li></ul>
  68. 68. PIM flexível
  69. 69. Criação de modelo de decisão <ul><li>O resultado da análise de domínio consiste em igualdades e variabilidades que terão que ser implementadas dentro do PIM flexível </li></ul><ul><ul><li>As igualdades estão de acordo com a parte comum da arquitetura do PIM flexível enquanto que as variabilidades são definidas no modelo de decisão que representa todos os possíveis requisitos do usuário definidos durante a análise de domínio e o conjunto de regras associadas a eles </li></ul></ul>
  70. 70. Criação de modelo de decisão <ul><li>Foi definido um meta-modelo para o modelo de decisão </li></ul><ul><ul><li>É utilizado para especificar modelos de decisão de linhas de produtos e validar todas os modelos de decisão </li></ul></ul><ul><li>Esta meta-modelo especifica: </li></ul><ul><ul><li>Estrutura do modelo de decisão </li></ul></ul><ul><ul><ul><li>Determina como as decisões devem ser estruturadas </li></ul></ul></ul><ul><ul><li>A decisão </li></ul></ul><ul><ul><ul><li>Determina como uma decisão é definida de uma forma completa </li></ul></ul></ul><ul><ul><ul><li>Este é o resultado do estudo de características e tipos de decisões que aparecem no modelo de decisão </li></ul></ul></ul><ul><ul><li>Dependências entre as decisões </li></ul></ul><ul><ul><ul><li>Determina relacionamentos entre as decisões </li></ul></ul></ul><ul><ul><ul><li>Dependências condicionam a forma de resolver decisões de um modelo de decisão e o impacto da implementação de pontos de variação </li></ul></ul></ul>
  71. 71. Modelo de Decisão
  72. 72. Tecnologia para representar modelo de decisão <ul><li>Se a forma de especificar a estrutura de decisões, as decisões propriamente ditas e a dependência entre as decisões estão bem definidas no meta-modelo, algumas ferramentas podem ser usadas para suportar a construção do modelo de decisão </li></ul><ul><li>Um protótipo desta ferramenta foi desenvolvido </li></ul>
  73. 73. Tecnologia para representar modelo de decisão <ul><li>Tanto o meta modelo quanto o modelo de decisão são representados com XML, mas precisamente XML Schema </li></ul><ul><li>Um modelo de decisão representa todos os possíveis requisitos definidos durante a análise de domínio e o conjunto de regras associadas a eles </li></ul><ul><li>O modelo de decisão pode ser mostrado em uma estrutura de árvore onde decisões podem ser agrupadas em um conjunto de decisões </li></ul><ul><li>Uma decisão é definida por um conjunto de elementos que identificam a decisão e a decisão é sempre representada como folhas da árvore </li></ul>
  74. 74. Tecnologia para representar modelo de decisão
  75. 75. Tecnologia para representar modelo de decisão <ul><li>O exemplo mostra a implementação de uma decisão onde esta pode adotar um valor específico dentro de um intervalo de valores </li></ul>
  76. 76. Tecnologia para representar modelo de decisão <ul><li>A escolha do XML se deu pelas seguintes razões: </li></ul><ul><ul><li>XML permite a definição de todos os tipos de decisão </li></ul></ul><ul><ul><li>Permite estruturar decisões em um modelo de decisão e prover funcionalidades para implementar dependências </li></ul></ul><ul><ul><li>Os pontos de variação associados a cada decisão devem ser implementados no PIM (PIM Flexível) </li></ul></ul><ul><ul><li>A publicação do XMI implica que cada modelo UML pode ser representado como arquivo XML </li></ul></ul><ul><ul><li>A abordagem de projetar o PIM flexível visa implementar os pontos de variação no XMI do PIM </li></ul></ul><ul><ul><li>A mesma tecnologia é utilizada tanto para representar o modelo de decisão quando para implementar os pontos de variações </li></ul></ul><ul><ul><li>Isto provê um poderoso mecanismo para automatizar a geração do PIM através dos requisitos (decisões específicas) </li></ul></ul>
  77. 77. Criação de PIM flexível <ul><li>PIMs flexíveis implementam funcionalidades da aplicação que dependem da variabilidade e igualdade dentro do domínio </li></ul><ul><li>PIMs flexíveis implementam a variabilidade e a igualdade do domínio, provendo interfaces para capturar os valores dos pontos de variação (requisitos dos usuários) </li></ul>
  78. 78. Criação de PIM flexível <ul><li>Processo de derivação do PIM </li></ul>
  79. 79. Criação de PIM flexível <ul><li>Relaçao entre engenharia de linha de produtos e PIMs flexíveis </li></ul>
  80. 80. Tecnologia utilizada na construção de PIMs flexíveis <ul><li>A interface de derivação de PIMs flexíveis é representada utilizando XML que captura requisitos do usuário </li></ul><ul><li>PIMs flexíveis são definidos e especificados com XML Stylesheet documents (XSLT) </li></ul><ul><li>XSLT provê a funcionalidade necessária para implementar os pontos de variação </li></ul><ul><li>O PIM é implementado por um conjunto de arquivos XSL que gera diferentes arquivos XMI dependendo nas decisões (requisitos do cliente) </li></ul><ul><li>Este arquivo XMI corresponde a uma definição de UML PIM que corresponde às necessidades dos requisitos do usuário e definição </li></ul>
  81. 81. Tecnoliga utilizada na construção de PIMs flexíveis <ul><li>PIMs flexíveis são construídos utilizando XML </li></ul>
  82. 82. Tipos de pontos de variação e XML <ul><li>Informação escondida ou inserção </li></ul>
  83. 83. Tipos de pontos de variação e XML <ul><li>Informação inserida </li></ul>
  84. 84. Tipos de pontos de variação e XML <ul><li>Ciclos </li></ul>
  85. 85. Implementação dos pontos de variação associada às decisões
  86. 86. Implementação dos pontos de variação associada às decisões
  87. 87. Transformação de modelos UML <ul><li>Exemplo de meta-modelo proposto por Massen </li></ul>
  88. 88. Transformação de modelos UML
  89. 89. Transformação de modelos UML <ul><li>Transformar cada funcionalidade em classe </li></ul><ul><li>Transformar relacionamentos obrigatórios em agregação/composição </li></ul><ul><li>Transformar relacionamentos opcionais em associações 0..1 </li></ul><ul><li>Transformar relacionamentos alternativos em generalização única </li></ul><ul><li>Transformar relacionamentos require e mutual-exclusive em expressões OCL </li></ul>
  90. 90. Transformação de modelos UML <ul><li>Meta-modelo simplificado proposto por Czanercki </li></ul>
  91. 91. Transformação de modelos UML <ul><li>Transformar o modelo de funcionalidades em um pacote </li></ul><ul><li>Transformar cada funcionalidade em uma classe e, adicionalmente, associar casa SolitaryFeature com a classe gerada com multiplicidade igual à featureCardinality </li></ul><ul><li>Transformar cada FetureGroup em uma super-classe do conjunto de classes geradas através das instâncias do GroupedFeature e gerar uma associação com o classe gerada através do Feature com multiplicidade igual à groupCardinality </li></ul>
  92. 92. Exemplo <ul><li>Família de relógios </li></ul>
  93. 93. Exemplo <ul><li>Visão arquitetural </li></ul>
  94. 94. Exemplo <ul><li>Classes </li></ul>
  95. 95. Exemplo <ul><li>Transformações </li></ul>
  96. 96. Questões <ul><li>Por que MDA poderia ser uma boa abordagem junto com engenharia de linha de produtos? </li></ul><ul><li>Quais são as características de MDA interessantes para uma abordagem de linha de produtos? </li></ul><ul><li>Como MDA pode trazer uma resposta para a linha de produtos em relação a: variabilidade, configuração de plataformas, etc? </li></ul><ul><li>Que mecanismos de MDA poderia ser usado para tratar Engenharia de linha de produtos? </li></ul><ul><li>Que soluções podem ser padronizadas através do MDA para a engenharia de linha de produtos? </li></ul><ul><li>Que extensões poderiam ser propostas por uma ferramenta de MDA para suportar engenharia de linha de produtos? </li></ul><ul><ul><li>PIM!!! </li></ul></ul>
  97. 97. Considerações Finais <ul><li>Certas categorias de sistemas são altamente configuráveis para se adaptarem em diferentes ambientes e processos </li></ul><ul><ul><li>Trazem desafios adicionais para caracterizar a variabilidade do domínio, escolhendo um conjunto flexível de componentes e composições especificando requisitos para uma dada configuração e mapeando para uma configuração particular de componentes que irão realizar o requisito </li></ul></ul><ul><li>Modelos e sistemas de larga escala sempre evoluem </li></ul><ul><ul><li>A arquitetura para os modelos deverá suportar uma refatoração transparente de algumas partes sem afetar as outras </li></ul></ul><ul><li>Com MDA, o tratamento de variabilidade é feito de forma automática através das transformações </li></ul><ul><li>Reais benefícios de MDA só podem ser atingidos em uma família de produtos de software </li></ul><ul><ul><li>É necessário que haja um domínio estável onde uma arquitetuera genérica do PIM tenha sido definida e desenvolvida </li></ul></ul><ul><li>Atualmente, há muitas iniciativas e idéias, porém falta a prática </li></ul><ul><li>Muito tem se falado sobre transformações entre PIMs e pouco sobre transformações de PIM para PSM e de PSM para código </li></ul><ul><li>Uso de variabilidade com MDA elimia a necessidade de reound trip </li></ul>
  98. 98. Bibliografia <ul><li>J. Estublier, G. Vega, Model Driven Architecture as Approach to Manage Variability in Software Product Families </li></ul><ul><li>A. Garcia, J. Mansell, Formalism to describe a domain model based on user specifications using VSL , 2002 </li></ul><ul><li>A. Garcia, J. Mansell, Form Customer Requirements to PIM: necessity and reality </li></ul><ul><li>M. Laguna, B. González-Baixauli, Goals and MDA in Product Line Requirements Engineering , 2005 </li></ul><ul><li>J. Estublier, G. Vega, Reuse and Variability in Large Software Applications </li></ul><ul><li>H. Gomaa, Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures </li></ul><ul><li>L. Monestel, T. Ziadi, J. Jézéquel, Product Line Engineering: Product Derivation , 2003 </li></ul><ul><li>L. Dobrica, E. Niemelä, UML Notation Extensions for Product Line Architectures Modeling </li></ul><ul><li>D. DSouza, Kinetium, Model-Driven Architecture and Integration , 2001 </li></ul><ul><li>Haugen, Birger, An MDA based framework for model-driven product derivation </li></ul><ul><li>M. Fiorio, Experiencia pratica na construcao de aplicacoes utilizando Model Driven Architecture , 2005 </li></ul><ul><li>L. Leal, M. Trannin, M. Fiorio, P. Pires, M. Campos, Uma experiencia de aplicacao de abordagem MDA em desenvolvimento baseado em componentes , 2005 </li></ul><ul><li>http :// modeldrivenarchitecture . esi .es/ mda _ publicDocuments . html </li></ul>

×