• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
MDA-gerenciamento
 

MDA-gerenciamento

on

  • 1,864 views

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

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

Statistics

Views

Total Views
1,864
Views on SlideShare
1,857
Embed Views
7

Actions

Likes
0
Downloads
38
Comments
0

1 Embed 7

http://www.slideshare.net 7

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    MDA-gerenciamento MDA-gerenciamento Presentation Transcript

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