Linhas de Processos de Software - Minicurso - SBQS 2011

  • 1,613 views
Uploaded on

 

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,613
On Slideshare
0
From Embeds
0
Number of Embeds
5

Actions

Shares
Downloads
41
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Linhas de Processo de Software:Conceitos, Técnicas e Ferramentas Uirá Kulesza DIMAp / UFRN uira@dimap.ufrn.br Em colaboração com Fellipe Aleixo, Marilia Freire e Daniel Alencar
  • 2. Breve Apresentação•  Acadêmico – Professor do DIMAp, UFRN – Doutor em Informática pela PUC-Rio – Pós-doutorado – Projeto Europeu AMPLE•  Indústria – Engenheiro de Processos e Software do CESAR, Qualiti e Radix – Pesquisador Sênior do CESAR
  • 3. Objetivos do Curso•  Descrever desafios atuais para gerência e customização de variabilidades em processos de software•  Apresentar o estado-da-arte da área de linhas de processos de software –  Co-relacionando com os avanços da área de processos
  • 4. Agenda•  Contexto e Motivação•  Engenharia de Processos de Software•  Linhas de Produto de Software•  Linhas de Processo de Software
  • 5. Motivação•  Demanda crescente pela definição e melhoria contínua de processos para promover o desenvolvimento produtivo de software de qualidade
  • 6. Motivação•  Ao longo dos últimos anos, pode se observar a evolução da área de processos de software: –  Modelos de maturidade –  Frameworks de processos –  Metodologias e práticas agéis –  Processos alinhados com técnicas existentes (orientação a objetos) –  Avanços em técnicas para diferentes disciplinas
  • 7. Motivação•  De forma geral, podemos dizer que estamos bem servidos de informações, técnicas e mecanismos que nos auxiliem na definição e avaliação de processos de software
  • 8. Motivação•  Apesar dos avanços na área, ainda existe uma forte demanda pela rápida e efetiva customização de processos de software atuais para endereçar a variedade de projetos, tecnologias, cultura e escala existentes
  • 9. Desafios•  Como lidar com redundância e inconsistências oriundas de processos definidos para uma organização?
  • 10. Desafios•  Como incorporar mudanças que ocorrem durante a execução de processos em outros processos futuros?•  Como lidar com a evolução simultânea de vários processos?
  • 11. Desafios•  Como garantir que não se gasta tempo relacionado a definição e manutenção de processos em tarefas improdutivas?•  Como promover o reuso de práticas, métricas, técnicas entre processos de uma empresa?
  • 12. Complexidade na Eng. de Processos
  • 13. Desafio Geral•  Como promover o reuso dentro de uma família de processos relacionados ?•  Como gerenciar variabilidades que ocorrem em tal família?
  • 14. Agenda•  Contexto e Motivação•  Engenharia de Processos de Software•  Linhas de Produto de Software•  Linhas de Processo de Software
  • 15. Engenharia de Processo•  Área responsável pela criação, modelagem, adaptação e representação de processos de software
  • 16. Visão do SWEBOK
  • 17. Como vocês definem seus processos de software?
  • 18. Conhecimento na área•  Modelos de Ciclo de Vida•  Frameworks de Processos (RUP)•  Práticas Agéis (XP, SCRUM)•  Modelos de Maturidade
  • 19. Cultura da Equipe e Escala do Projeto (Contexto)•  Experiência da Equipe•  Conhecimento de tecnologias –  Técnicas, métodos, ferramentas•  Escopo/Complexidade do Projeto•  Custo do Projeto
  • 20. Como especificarprocessos de software?
  • 21. Linguagens de Modelagem de Processos de Software•  Na década de 90, diversas linguagens de modelagem de processos de software foram propostas –  Marvel, SPADE, SPELL, APL/A•  Forte ênfase em formalismos complexos e pouca flexibilidade foram uma das principais razões para receber pouca atenção da indústria
  • 22. Linguagens de Modelagem de Processos de Software•  Ao longo dos últimos anos, novas linguagens baseadas em UML foram propostas•  Duas vertentes principais: –  Industrial: •  SPEM 1.1, SPEM 2.0 –  Projetos de Pesquisa: •  Promenade, UML4SPM, Chous, DiNittos
  • 23. Linguagens de Modelagem de Processos de Software•  Estudo comparativo recente avalia tais linguagens sob diferentes perspectivas: –  Riqueza Semântica –  Aderência a UML –  Representação Gráfica –  Executabilidade –  Modularidade –  Formalismo –  Suporte Ferramental
  • 24. Estudo ComparativoR. Bendraou, J. Jézéquel, M. Gervais, X. Blanc: A Comparison of Six UML-Based Languages for Software Process Modeling. IEEE Trans. Software Eng. 36(5): 662-675 (2010)
  • 25. SPEM 1.1•  Linguagem de modelagem de processos de software proposta pela OMG em 2005•  Reutiliza diagramas de UML (classe, atividade, estado, ...) para permitir a especificação de processos de software•  Possibilidade de uso de diferentes modelos para especificação de processos•  Sem suporte para executabilidade
  • 26. SPEM 2.0•  Define abstracões de processos independentes de UML em metamodelo MOF próprio•  Modularidade: –  Separação clara entre conteúdo de processo da sua instanciação para processos específicos•  Suporte Ferramental Industrial•  Não explicita mecanismos para promover a execução de processos
  • 27. UML4SPM•  Permite modelagem e execução de processos em uma única linguagem•  Reusa o diagrama de atividade de UML para especificação de processos•  Execução do processo pode ser realizada através do seu mapeamento para linguagens de workflow (BPEL), ou do uso da semântica operacional oferecida por um modelo próprio de execução
  • 28. Ferramentas de Definição de Processos•  Surgimento de ferramentas para definição de processos, e gerência de seus diferentes elementos (atividades, guias, papéis)•  Ferramentas industriais: –  Eclipse Process Framework –  Rational Method Composer
  • 29. Reuso em Processos de Software
  • 30. Eclipse Process Framework•  Projeto open-source da comunidade Eclipse•  Objetivos: –  Framework extensível e ferramenta para definição, configuração e publicação de processos –  Disponibilização de processos de referência
  • 31. Eclipse Process Framework
  • 32. EPF - Conceitos•  Permite estruturar frameworks de processos em pequenas unidades modulares – method content – para promover o seu reuso•  Cada method content é definido usando o metamodelo Unified Method Architecture (UMA) –  UMA representa um subconjunto do SPEM 2.0
  • 33. EPF - Conceitos•  Cada method content define um papel realizando um conjunto de tarefas usando guias específicos com artefatos de entrada e saída•  Os processos são definidos a partir do reuso de method contents
  • 34. Method Content x Processos
  • 35. Exemplos de Conteúdo de Método•  Transformar documento de requisitos em modelo de análise•  Definir arquitetura que atenda requisitos funcionais e não funcionais•  Criar plano de projeto para iteração
  • 36. Conteúdo de Métodos x Processos
  • 37. OpenUP•  É uma versão leve e ágil do framework de processo RUP•  Adota uma estratégia incremental e iterativa similar•  Estrutura enxuta não cobrindo questões de alocação de equipe, guias específicos, estabelecimento de contratos•  Disponibilizado como um processo open- source no projeto EPF
  • 38. EPF Composer•  Ferramenta que permite a implementação e manutenção de processos de software para empresas ou projetos individuais•  Gerência e customização de módulos específicos de um processo•  Adota metamodelo Unified Method Architecture (UMA) uma evolução do SPEM 1.1 –  Tem ajudado na evolução do SPEM 2.0
  • 39. EPF Composer - Conceitos
  • 40. EPF Composer - Conceitos
  • 41. Customizações Específicas•  Globais (tempo de desenvolvimento) –  Configuração de conteúdo de método ou do processo –  Exemplo: modificação direta em tais elementos•  Específicas de um Processo Existente (tempo de instanciação) –  Adicionar, remover ou modificar elementos existentes –  Exemplo: Ao instanciar o OpenUP desejo remover determinadas atividades ou tarefas
  • 42. Padrões de Capacidade e Variabilidade•  Padrões de capacidade (templates): –  Um conjunto de atividades reusáveis de uma área de processo comum, que são recorrentemente encontrados durante a definição de um dado processo•  Variabilidades –  Permite modificar (contributes, extends e replace) o conteúdo existente de um processo sem modificar sua estrutura original Exemplo: adição de passos a atividades de um processo OpenUP
  • 43. Reuso de conteúdo entre processos
  • 44. Desafios de Customização•  Não torna explícito características opcionais e alternativas de uma família de processos•  Não define dependências e restrições entre características de forma explícita•  Unidades de variações bem localizadas•  Não permite gerência de variabilidades finas e grossas
  • 45. Agenda•  Contexto e Motivação•  Engenharia de Processos de Software•  Linhas de Produto de Software•  Linhas de Processo de Software
  • 46. Motivação•  Engenharia de Software objetiva proposição de métodos, técnicas e ferramentas para a produção de software com qualidade e produtividade•  Desde o início, reutilização tem sido um dos caminhos naturais explorado para garantir mais produtividade e qualidade no processo de desenvolvimento
  • 47. Motivação•  Reutilização no nível de código: – Componentes, Bibliotecas, Frameworks – Servidores, Serviços•  Reutilização no nível de projeto: – Padrões arquiteturais e projeto•  Mas...
  • 48. Motivação•  Reuso de código e projeto tem sido útil e gera impacto para a produção de software, mas ainda de forma localizada•  Carência de métodos e técnicas para promover o reuso em larga escala entre famílias de sistemas do mesmo domínio•  Reuso sistemático em larga escala é, em geral, artesanal (copy/paste, merge de código, patches)
  • 49. Evolução do Reuso•  Funções (década de 70 e 80)•  Bibliotecas de classes (80 e 90)•  Padrões de projeto e arquitetura (90 e 00)•  Frameworks (90 e 00)•  Linhas de Produto de Software !!
  • 50. Linhas de Produto de Software•  LPS é uma família de sistemas que atende um determinado segmento de mercado [Clements and Northrop, 2001]•  Uma família de sistemas é um conjunto de aplicações que compartilham funcionalidades comuns e mantém funcionalidades específicas que variam de acordo com o sistema sendo considerado [Parnas, 1976]
  • 51. Linhas de Produto de Software•  Promovem o reuso de: – Um conjunto de features comuns e variáveis – Uma arquitetura comum – Implementação de classes e componentes do núcleo da arquitetura
  • 52. Exemplos do mundo não software•  Indústria automotiva –  Fiat (Uno, Palio, Siena, ...)•  Indústria aeronáutica –  Família de aviões da Embraer e da Boeing•  Indústria de eletrodomésticos –  Televisão –  Máquinas Fotográficas –  Computadores, Laptops•  Indústria alimentícia –  Fast Food (McDonald’s)
  • 53. Exemplos de LPS•  Fones móveis (Nokia)•  Software para análise de ações (Market Maker)•  Aplicações embarcadas de tempo real que suportam funções operacionais do piloto (Boeing)•  Software para dispositivos de TV (Philips)•  Hall of Fame, SPLC –  http://www.sei.cmu.edu/productlines/plp_hof.html
  • 54. Exemplos de LPS mais acessíveis•  Games ou software para dispositivos portáteis•  IDEs customizáveis•  Sistemas web de segmento específicos –  Comércio eletrônico –  Rede social•  Middlewares•  Sistemas de informação corporativos
  • 55. Conceitos Básicos
  • 56. Feature (Característica)•  Uma LPS é tipicamente especificada, modelada e implementada em termos de seus features•  Definição: –  É uma propriedade ou funcionalidade que é relevante para algum interessado na LPS, e que é usado para identificar similaridades ou variabilidades existentes entre os diferentes produtos/sistemas da LPS. [Czarnecki, et al, 2006]
  • 57. Exemplos de Features•  Rain of Fire (jogo para dispositivo portátil) –  Jogo clássico na qual o usuário tenta proteger uma vila de ataques de dragões usando uma catapulta•  Features –  Ações do jogo (nível, armas bônus, dragões) –  Imagens opcionais –  Tamanho da tela –  Estratégia de carga de imagens (por demanda, no início)
  • 58. Similaridades e Variabilidades•  Em uma LPS pode existir: – Features comuns •  Similaridades (commonalities) entre todos os seus produtos – Features variáveis •  Variabilidades (variabilities) que definem as diferenças entre produtos existentes
  • 59. Exemplos de Features Comuns e Variáveis•  Rain of Fire
  • 60. Conceitos básicos•  Variabilidade (variability) –  Um feature que varia de um produto para outro•  Ponto de variação (variation point) –  Um ponto/lugar onde uma variabilidade ocorre em um artefato de desenvolvimento da LPS (domain asset)•  Variantes (variants) –  As diferentes possibilidades que existem para satisfazer um dado ponto de variação
  • 61. Desenvolver LPSs consisteem gerenciar adequadamente suas variabilidades !
  • 62. Engenharia de LPSs•  Objetivos: – Prover métodos, técnicas e ferramentas para produção em larga escala de família de produtos relacionados – Permitir a gerência de variabilidades dos diferentes produtos pertencentes a LPS •  Busca especificar, modelar, projetar, implementar, customizar diferentes variabilidades existentes na LPS
  • 63. Engenharia de LPSs•  Tipicamente organizada em: – Engenharia de Domínio • Desenvolvimento para Reuso – Engenharia de Aplicação • Desenvolvimento com Reuso
  • 64. Engenharia de LPSs Engenharia de DomínioConhecimento Modelo do Arquitetura da família dedo domínio domínio Análise de Projeto do sistemas Implem. do Domínio Domínio Domínio Linguagem específica Novos requisitos do domínio Componentes Geradores Customização Customização Novos requisitos Projeto Desenvolvimento Necessidades dos clientes Análise de Configuração Integração Requisitos Features do Produto Configuração e Testes Produto do produto Engenharia de Aplicação Czarnecki, K., Eisenecker, U.: “Generative Programming: Methods, Tools, and Applications”, Addison-Wesley, 2000.
  • 65. Engenharia de LPSs
  • 66. Representação de Variabilidades na Engenharia de Domínio•  Requisitos –  Modelagem de features –  Modelos de Requisitos com Variações•  Arquitetura & Projeto –  Definição de uma arquitetura flexível e adaptável capaz de atender seus features comuns e variáveis•  Implementação –  Mecanismos que facilitem a adição/remoção das implementações de features variáveis
  • 67. Benefícios•  Maior produtividade –  Redução no tempo de entrega•  Maior qualidade•  Diminuição do custo total de produção –  Apesar do alto investimento inicial•  Geração de produtos customizados•  Redução na manutenção –  Correção para um, vale para vários•  Pode facilitar a estimativa de custos
  • 68. Problema Instanciar manualmentevariabilidades de uma LPS é uma atividade bastante custosa
  • 69. Engenharia da Aplicação•  Objetivos: – Construção de produtos/aplicações a partir dos artefatos produzidos na Engenharia de Domínio – Pode ocorrer de forma manual ou de forma automatizada (derivação automática)•  Artefatos Produzidos: – Produto final (parcial ou completo)
  • 70. Derivação de Produto•  Automação da Engenharia de Aplicação•  Seleciona, compõe e monta uma aplicação final (produto) a partir dos artefatos produzidos para a arquitetura da LPS•  Uso de ferramentas de mais alto nível para selecionar os features desejados do produto: – Modelo de Feature – Linguagens Específicas de Domínio (domain-specific language)
  • 71. Derivação de Produtos•  Derivação/Instanciação de Produtos diz respeito ao processo de construção do produto a partir de um conjunto de artefatos de implementação (frameworks, componentes, bibliotecas, aspectos, etc) desenvolvidos durante a Engenharia de Domínio•  Promove a automação da Engenharia de Aplicação
  • 72. Ferramentas de Derivação•  São complementares ao conjunto de técnicas, métodos e ferramentas já propostas pela Engenharia de Domínio•  Permite a geração e customização de produtos / sistemas, a partir dos artefatos reusáveis produzidos na engenharia de domínio
  • 73. Ferramentas de Derivação•  Várias ferramentas industriais propostas nos últimos anos: – Pure::Variants • www.pure-systems.com – Gears • www.biglever.com – MetaEdit • www.metacase.com
  • 74. Que tal seguirmos um exemplo paraaprendermos como de fato funciona a engenharia de LPS? 74
  • 75. Rain of Fire•  Jogo para dispositivo portátil desenvolvido pela Meantime/CESAR –  Jogo clássico na qual o usuário tenta proteger uma vila de ataques de dragões usando uma catapulta•  Features –  Ações do jogo (nível, armas bônus, dragões) –  Imagens opcionais –  Tamanho da tela –  Estratégia de carga de imagens (por demanda, no início)
  • 76. Rain of Fire
  • 77. Similaridades e Variabilidades•  Em uma LPS pode existir: – Features comuns •  Similaridades (commonalities) entre todos os seus produtos – Features variáveis •  Variabilidades (variabilities) que definem as diferenças entre produtos existentes
  • 78. Exemplos de Features Comuns e Variáveis•  Rain of Fire
  • 79. Projeto de Domínio•  Objetivos: –  Definição de uma arquitetura comum e componentes que contemple toda a LPS –  Especificação de um plano de produção•  Artefatos Produzidos: –  Representação arquitetural na forma de componentes da arquitetura –  Projeto detalhado de cada variação a ser implementada –  Definição de um plano de produção que indica como produtos podem ser construídos a partir dos artefatos disponíveis.
  • 80. Arquitetura do Rain of Fire
  • 81. Implementação de Domínio•  Objetivos: –  Implementação da arquitetura e componente previamente especificados –  Escolha de tecnologias para implementação das variações –  Estratégias de derivação manual ou automática dos artefatos de código produzidos•  Artefatos Produzidos: –  Componentes, bibliotecas de classes –  Linguagens específicas de domínio (wizards, diagramas, ...) + geradores (derivação automática)
  • 82. ESTRUTURA GERAL FRAMEWORK CORE DO JOGO ARQUITETURA DELINHA DE PRODUTO COMPILAÇÃO CONDICIONAL ARQUIVO DE BUILD CONFIGURAÇÃODIFERENTESPRODUTOS
  • 83. Jogo – Rain of Fire•  Framework Core –  Conjunto de classes que definem máquina de estado com transições ocorrendo em função do tempo decorrido e interações com o usuário•  Exemplos de variações –  Imagens decorativas opcionais (nuvens no fundo da tela) –  Carga de imagens por demanda ou inicialização –  API de manipulação de imagens proprietária (Nokia, Samsung, Motorola) de diferentes dispositivos
  • 84. CÓDIGO DE JOGO COM COMPILAÇÃO CONDICIONALpublic class GameScreen extends Screen { ... public void paint(Graphics g) { Enemy myEnemy; ... if (this.scroll.isScrolling) { ... } else if(!isGameOver){ if (!this.isPaused) { this.drawBk(g); this.drawRain(g); // #ifdef CLOUDS g.drawImage(Resources.clouds01, clouds01_x, 87, g.TOP | g.LEFT); g.drawImage(Resources.clouds02, clouds02_x, 66, g.TOP | g.LEFT); g.drawImage(Resources.clouds03, clouds03_x, 31, g.TOP | g.LEFT); // #endif this.drawCity(g); this.drawCatapults(g); } } ...}
  • 85. ARQUITETURA DE LINHA DE PRODUTO FRAMEWORK CORE DO JOGOASPECTOS ESCOLHA DE FEATURES BUILD (DSLS, XML, ETC)‫‏‬ DIFERENTES PRODUTOS
  • 86. CÓDIGO DE JOGO COM ASPECTOS Exemplo de Aspectopublic aspect Clouds { private static Image clouds01 = null; private static Image clouds02 = null; ... void around (GameScreen gs): call(public void GameScreen.updateClouds(GameScreen))‫‏‬ && this(gs); { updateClouds(gs); } void around (Graphics g): call(public void GameScreen.drawClouds(Graphics))‫‏‬ && args(g); { drawClouds(g); } protected void drawClouds(Graphics g) { // draws the clouds. g.drawImage(clouds01, clouds01_x, 87, g.TOP | g.LEFT); g.drawImage(clouds02, clouds02_x, 66, g.TOP | g.LEFT); g.drawImage(clouds03, clouds03_x, 31, g.TOP | g.LEFT); } ...}
  • 87. Derivação Automática com GenArch E. Cirilo, et al. A Product Derivation Tool Based on Model-Driven Techniques and Annotations. J. UCS, 14(8):1344–1367, 2008.
  • 88. Modelos de Feature e Arquitetura
  • 89. Modelo de Configuração
  • 90. Derivação Automática•  Seleção de quais variabilidades serão endereçadas pelo produto gerado•  Cópia dos elementos, em função das características selecionadas, para um novo projeto Eclipse/Java•  Pode demandar geração de 400 variações de um mesmo jogo em segundos
  • 91. Outro Exemplo Eclipse IDE como umaLinha de Produto de Software 91
  • 92. Eclipse como uma Linha de Produto Another Eclipse Platform Tool Java Workbench Help Development Tools JFace (JDT) SWT Team Your Tool Plug-in Workspace Development Debug Environment (PDE) Their Platform Runtime Tool Eclipse Project
  • 93. Features do Eclipse•  Features Comuns (Similaridades) –  Gerência de Plugins –  Ambiente Desenvolvimento Java e Plugins –  Infra-estrutura (criação de visões, perspectivas, editores, projeto, etc)•  Features Variáveis (Variabilidades) –  Novas visões, editores, perspectivas, projeto –  Novas linguagens, builders –  Look-and-Feel (Visual Gráfico) baseado no SO
  • 94. Arquitetura do Eclipse•  Núcleo da Arquitetura – Framework OO Extensível com Pontos Flexíveis para Instalação de Plugins•  Variabilidades – Plugins que estendem a plataforma base ou pontos extensíveis de outros plugins instalados
  • 95. Pontos Flexíveis do EclipseMenu bar TextTool bar editorPerspectiveandFast Viewbar OutlineResource viewNavigatorview Bookmarks viewPropertiesviewMessage Editorarea Status area Stacked views 200303331 Tasks 95 view
  • 96. Plataforma Eclipse Eclipse Platform Workbench “UI” JFace SWT Team Help Debug“Core” Workspace Ant Platform Runtime
  • 97. Agenda•  Contexto e Motivação•  Engenharia de Processos de Software•  Linhas de Produto de Software•  Linhas de Processo de Software
  • 98. Linhas de Processo de Software•  Estudo de técnicas e mecanismos para gerência de variabilidades em processos de software•  Proposição e adaptação de técnicas existentes da área de engenharia de linhas de produto
  • 99. Linhas de Processo de Software•  Objetivos: –  Gerência de variabilidades em famílias de processos de software –  Composição e Customização de processos de software
  • 100. Linhas de Processo de Software•  Definição: –  Uma família de processos de software com um conjunto gerenciado de características que satisfazem necessidades específicas de uma organização e que são desenvolvidos a partir de um conjunto de processos básicos comuns [Ambrust 2009] O. Armbrust, M. Katahira, Y. Miyamoto, J. Münch, H. Nakao, A. Ocampo: Scoping software process lines. Software Process: Improvement and Practice 14(3): 181-197 (2009).
  • 101. Abordagens Propostas•  Diferentes abordagens propostas sob diferentes perspectivas: –  Processo de engenharia de linha de processo –  Mecanismos, técnicas e ferramentas para gerenciar variabilidades
  • 102. H. Dieter RombachIntegrated Software Process and Product Lines Proceedings of ISPW 2005 102
  • 103. Rombach•  Propõe a combinação do uso de técnicas de linhas de produto de software em processos•  Adota o termo “linhas de processo de software”•  Artefatos e produtos podem ser escolhidos baseados num conjunto de requisitos de produto e processo, e em restrições de projeto
  • 104. Integrando Processos de Software e Linhas de Produto•  Ao iniciar um projeto, caracteriza-se o projeto e então submete-se uma query ao repositório•  Como resultado, um conjunto combinado de artefatos e processos são fornecidos permitindo o planejamento e execução do projeto
  • 105. Considerações•  Uma linha de processo deve criar um conjunto de processos genéricos, capturar as similaridades e controlar as variabilidades sobre um domínio•  Vantagens: –  aumentar a previsibilidade –  diminuir prazo e custo –  minimizar riscos (abordagem de reuso).
  • 106. Ove Armbrust, et alScoping Software Process Lines Journal of Software ProcessImprovement and Practice, 2009 106
  • 107. Ambrust et al•  Adapta processos de LPS para serem aplicados a processos de software•  Foco principal na definição do escopo da linha de processo•  Priorização de técnicas e processos a serem usados na linha de processo em função de projetos e produtos sendo desenvolvidos por uma empresa
  • 108. Scoping Process Lines
  • 109. Definição do Escopo da Linha de Processo de Software•  Atividades a serem realizadas: –  Análise dos Produtos e dos Projetos da Empresa •  Necessidades específicas para seus processos –  Análise do Processo –  Priorização de Atributos –  Determinação do Escopo
  • 110. Análise de Produtos e Projetos•  Levantamento de produtos e/ou projetos atuais e futuros da empresa•  Caracterização dos mesmos em função de atributos específicos de interesse
  • 111. Análise de Produtos•  Probabilidade de desenvolvimento versus caracterização de atributos
  • 112. Análise de Projetos•  Probabilidade de desenvolvimento versus caracterização de atributos
  • 113. Análise de Processos•  Avaliação dos processos, métodos e técnicas utilizados em função dos atributos de produto e projeto
  • 114. Priorização de Atributos•  Avaliação de atributos mais importantes para produtos e projetos através de comparações dois-a-dois
  • 115. Determinação do Escopo•  Definição de métodos, técnicas e processos mais relevantes em função de atributos de produto e projeto
  • 116. Estudos de Caso•  Adoção parcial em alguns projetos no Japan Aerospace Exploration Agency (JAXA) –  Desenvolvimento de software para satélites•  Aplicação para apenas alguns atributos, sem comparação dois-a-dois•  Resultados preliminares mostram viabilidade da proposta, mas não aplicabilidade geral –  Torna explícito aspectos e decisões relacionados a definição do processo
  • 117. Estudo de Caso
  • 118. Estudo de Caso
  • 119. Thomas Ternité Process Lines: A Product LineApproach Designed for Process Model Development Proceedings of EUROMICRO-SEAA 2009 119
  • 120. Ternité et al•  Aplica conceitos de linhas de produto para modelos de processo•  Define tipos de features e tipos de variabilidades –  Semântica de “change operations” Tipo de Variabilidade Significado Positive Novos elementos ou relações Negative Elementos ou relações são removidos Extending Elementos ou relações são estendidos Replacing Elementos ou relações são substituídos.
  • 121. Um metamodelo para descrever Linha de ProcessoClasses core da linha de processo. Classes específicas de uma arquitetura de linha de processo
  • 122. Uma instância do modelo de processo Variante do modelo de processoInstâncias dos elementos do modelo
  • 123. Considerações•  Apresenta uma terminologia e um metamodelo para criar um modelo de processo.•  Fornece uma separação clara entre conteúdo e mudanças. –  Os modelos de referência e extensão podem ser desenvolvidos separadamente e mesclados no final. •  O modelo de referência pode ser alterado através das “change operations” sem alterar seu conteúdo.
  • 124. Simidchieva, et alRepresenting Process Variation with a Process Family Proceedings of ICSP 2007 124
  • 125. Simidchieva et al•  Propõem a aplicação da abordagem de família de produtos como forma de gerenciar a variação em processos•  Utilizam linguagem Little-JIL para a definição da família de processos – modelagem de variações
  • 126. Instâncias da Linha de Processo•  Definem três técnicas de geração de instâncias –  Modificando o comportamento de agentes –  Modificando a forma de execução das tarefas –  Modificando a estrutura dos artefatos
  • 127. Visão Geral
  • 128. Estudo de caso•  Apresenta um estudo de caso em parceria com o National Mediation Board (NMB) –  Aplica e valida as diferentes técnicas para a derivação de instâncias
  • 129. Hironori WashizakiBuilding Software Process Line Architectures from Bottom UpProceedings of PROFES 2006 129
  • 130. Washizaki et al•  Propõe uma nova técnica de customização de processos com uma abordagem baseada em componentes e generativa construindo uma PLA (Process Line Architecture) e derivando processos para projetos específicos.•  A PLA é construída a partir de uma extensão do SPEM.
  • 131. Product Line Architecture
  • 132. Considerações•  A PLA pode ser usado como base para comparar processos similares.•  A comparação das similaridades entre elementos do processo é realizada manualmente•  Utiliza os labels <<variationPoint>>, <<variant>>, <<optional>> e <<requires>>
  • 133. Estudo de Caso: Arquitetura da Linha de Processo Co-Design
  • 134. Barreto, et al Supporting the Definition of SoftwareProcesses at Consulting Organizations via Software Process Lines Proceedings of QUATIC 2010 134
  • 135. Barreto, et al  Propõe uma abordagem para as SPCOs (Software Process Consulting Organizations), com o objetivo de facilitar a definição de processos reusáveis.  Considera a SPL como uma Software Process Architecture, composta por componentes de processos, atividades, ou combinações entre estes.  Apresenta uma ferramenta Web de apoio à definição de processos reusáveis.
  • 136. Visão Geral
  • 137. Ferramenta Web de Apoio
  • 138. Ferramenta Web de Apoio (cont.)
  • 139. Ferramenta Web de Apoio (cont.)
  • 140. Bendraou, et al Combining Aspect and Model-Driven Engineering Approaches for Software Process Modeling and Execution Proceedings of ICSP 2009 140
  • 141. Bendraou et al  Propõe um framework e uma abordagem para a modelagem e execução dos processos de software  Define um modelo de execução que é um diagrama de classe representando o comportamento operacional de cada elemento do UML4SPM
  • 142. Bendraou et al  Implementa o modelo de execução utilizando a linguagem Kermeta e realiza uma composição (weaving) desta implementação no meta-modelo UML4SPM  Possibilita a execução de modelos sem um passo adicional de compilação ou transformação
  • 143. Modelagem UML4SPMpara a fase de Concepção
  • 144. Modelo de Execução
  • 145. Visão Geral da Abordagem
  • 146. Aleixo, et al Automating the Variability Management,Customization and Deployment of Software Processes: A Model-Driven Approach Proceedings of ICEIS 2010, LNBIP 73 Springer Verlag 146
  • 147. Aleixo, et al Uma Abordagem para Gerência eCustomização de Variabilidades em Processos de Software Proceedings of SBES 2010 (nominated to the best paper) 147
  • 148. Limitações de Ferramentas Atuais (1ª) Edição e configuração manual de processos de software
  • 149. Limitações de Ferramentas Atuais (2ª) Reuso de elementos de processos de softwareatravés da cópia destes entre diferentes processos
  • 150. Limitações de Ferramentas Atuais (3ª) Sem suporte para a execução de um processo customizado
  • 151. Nosso Trabalho•  Promover o reuso sistemático de componentes de processo de software, através da organização de uma linha (ou família) de processos•  Aplicar princípios e técnicas de abordagem de linhas de produto de software•  Propor uma abordagem que dê suporte: 1.  ao gerenciamento de variabilidades em processos de software; 2.  à derivação automática de processos, oriundos da customização automática das especificações de famílias de processos de software 3.  à execução de processos de software em sistemas de workflow, através da transformação de suas especificações
  • 152. Visão GeralDefinição e Modelagem da Linha de Processo Usando uma ferramenta de especificação de processos, como o Eclipse Process Framework Composer
  • 153. Visão Geral Gerência automatizada deDefinição e Modelagem variabilidades dosda Linha de Processos elementos da linha de processo, utilizando uma ferramenta de derivação de produtos, como o GenArchGestão de Variabilidades da Linha de Processos
  • 154. Visão GeralDefinição e Modelagemda Linha de Processos Derivação Automática do Processo CustomizadoGestão de Variabilidades da Linha de Processos
  • 155. Atividade 1 – Definição e Modelagem da LPS
  • 156. Estudo de Similaridades e Variabilidades•  Estudo das similaridades e variabilidades da família de processos –  OpenUP usado como exemplo de família de processos –  Foram pesquisados três projetos de pesquisa e desenvolvimento em execução no IFRN –  Identificadas 586 features: •  273 features mandatórias •  239 features opcionais •  74 features alternativas
  • 157. Dependências e Restrições•  Estudo de Modelagem do OpenUP apresentou conjunto de heurísticas que podem ser modeladas em linhas de processo•  Exemplos: –  Atividades que tenham pelo menos uma tarefa obrigatória, também são obrigatórias –  Atividades com todas as tarefas opcionais, são também opcionais –  Seleção da atividade pode determinar a inclusão de um dado artefato, papel ou guia
  • 158. Exemplos de Features Identificadas para o OpenUP
  • 159. Atividade 2 – Gerência das Variabilidades
  • 160. Identificação das Variabilidades•  Anotar o modelo de processo com as variações –  Exemplo (trecho de um arquivo da especificação do OpenUP): /process.openup.base/capabilitypatterns/ initiate_project/model.xmi
  • 161. Importação da Especificação de Processo pelo GenArch Especificação do Processo em EPFModelos do GenArch
  • 162. Modelagem de Variabilidades em Diferentes Granularidades1.  Granularidade grossa – arquivos XMI que representam elementos de processo EPF2.  Granularidade fina – fragmentos de arquivos XMI que contém informações de detalhamento de um dado elemento de processo
  • 163. Exemplo de Variabilidades em Diferentesnos Diferentes Níveis de Granularidades Feature de granularidade grossa: Atividade Features de granularidade fina: Tarefas, Artefatos de entradas e Artefatos de saída
  • 164. Resultado Final do Processo de Importação
  • 165. Extensão do GenArch para Processos EPF
  • 166. Atividade 3 – Derivação de Processos
  • 167. Derivação de Processos Customizados Nova configuração do modelo de features Seleção das features desejadas Geração automática de uma especificação de processo no GenArch
  • 168. Execução de Processos de Software•  Tão importante quanto oferecer suporte para definição e customização de processos, é permitir e monitorar a sua execução•  Nossas pesquisas vêm atualmente explorando a transformação do processo para especificações de workflows que podem ser efetivamente executados
  • 169. Execução de Processos de Software
  • 170. Atividade 4 – Transformação Processo-to-Workflow
  • 171. Atividade 4 – Transformação Processo-to-Workflow •  Transformação da especificação do metamodelo de processo UMA, para uma especificação de metamodelo de workflow JPDL •  Mapeamento entre as propriedades dos metamodelos •  QVT Operational
  • 172. Tabela de Mapeamento: Process-to-Workflow
  • 173. Atividade 5 – Transformação Workflow-para-Texto
  • 174. Atividade 5 – Transformação Workflow-para-Texto •  A transformação de modelo para texto da nossa abordagem utiliza como entrada o modelo jPDL, resultante da transformação de modelo para modelo •  Ela permite a geração automática de código a partir de um meta-modelo que esteja de acordo com o EMF •  Essa transformação ocorre a partir da construção de templates do Acceleo.
  • 175. Atividade 5 – Transformação Workflow-para-Texto •  O resultado da transformação de modelo para texto pode ser importado como um projeto jBPM e seu conteúdo pode ser visualizado de forma gráfica pelo plugin editor de workflow do Eclipse Designer (GPD)
  • 176. Atividade 5 – Transformação Workflow-para-Texto •  O jBPM permite a criação de formulários web implementados no framework Java Server Faces (JSF) •  Esses formulários podem ser usados para acompanhar o fluxo de execução do processo •  Eles podem ser customizados usando uma conjunto de tags específicas do jBPM o que habilita a sua implantação no motor de execução jBPM.
  • 177. Atividade 6 – Implantação e Execução do Workflow
  • 178. Atividade 6 – Implantação e Execução do Workflow
  • 179. Atividade 7 – Gerenciamento do Workflow
  • 180. Ferramenta de Transformação de Modelos•  Ferramenta de transformação de modelos de processos especificados de acordo com o metamodelo UMA, para modelos e arquivos de configuração do motor de workflow jBPM. –  Uma transformação modelo-para-modelo mapeamento do modelo de processo de software definido pelo metamodelo UMA em modelo de workflow definido pelo metamodelo jPDL –  Uma transformação modelo-para-texto – mapeamento as informações contidas no modelo de workflow para um projeto de workflow executável.
  • 181. Ferramenta de Transformação Processo-para-Workflow
  • 182. Novas Perspectivas e Refinamentos•  Integração do código do workflow com ferramentas de engenharia de software –  Repositórios, IDEs, Relatórios de Gerência de Projeto•  Independência de plataforma de workflow –  Criação de transformações de modelos UMA para outras linguagens de workflow (platform specific models)
  • 183. Novas Perspectivas e Refinamentos•  Modelagem e Deployment de Métricas –  Seleção de métricas do processo e quantificação automática M. Freire, F. Aleixo, U. Kulesza, E. Aranha, R. Coelho. Automatic Deployment and Monitoring of Software Processes: A Model-Driven Approach. Proceedings of SEKE 2011 (to appear)•  Modelo de Característica Multi-Nível –  1o Nível: perguntas específicas de características do processo (ex: técnica ou linguagem usada, nível de maturidade/projeto) –  2o Nível: elementos do processo
  • 184. Considerações Finais e Desafios Futuros 184
  • 185. Considerações Finais•  Engenharia de Linhas de Processo de Software –  Reuso sistematizado e planejado dentro de famílias de processos relacionados –  Carência de métodos e ferramentas que adotem práticas e técnicas consolidadas de LPS –  Validação na prática dos ganhos efetivos da abordagem –  Desafios específicos de pesquisa e aplicação industrial na área
  • 186. Considerações Finais•  Execução de Processos de Software –  Promove o monitoramento efetivo das atividades em execução em processos –  Forte sinergia com a área de gerenciamento de processos de negócio e sistemas de workflow –  Quantificação de métricas de produtividade
  • 187. Desafios Futuros•  Avaliação da utilidade e escalabilidade de mecanismos de gerência de variabilidade•  Caracterização de variabilidades em diferentes tempos de instanciação –  Definição, Deployment e Execução•  Criação de repositórios de linhas e componentes de processo•  Exploração de técnicas de BPMN para execução de processos
  • 188. Perguntas, Dúvidas... Uirá Kulesza DIMAp/UFRN uira@dimap.ufrn.br
  • 189. Linhas de Processo de Software:Conceitos, Técnicas e Ferramentas Uirá Kulesza DIMAp / UFRN uira@dimap.ufrn.br Em colaboração com Fellipe Aleixo, Marilia Freire e Daniel Alencar
  • 190. Linhas de Processo de Software:Conceitos, Técnicas e Ferramentas Uirá Kulesza DIMAp/UFRN uira@dimap.ufrn.br
  • 191. GenArch na Prática6/6/11
  • 192. Modelo de Características •  Representa as características (variabilidades) do domínio •  Permite a criação de instancias da LPS (Produtos) baseada na seleção de Configurações características •  Pode apresentar regras globais (Se característica ‘x’ está selecionada então característica ‘y’ não pode ser selecionada)6/6/11
  • 193. Modelo de Implementação da Arquitetura•  Contém uma visão, organizada em containers dos artefatos de código da LPS –  Componentes –  Classes –  Aspectos –  etc•  É a partir do modelo de arquitetura que os artefatos de código são mapeados para expressões booleanas de características6/6/11
  • 194. Modelo de Configuração •  Contém o conhecimento de configuração da LPS. Mapeamento entre elementos de implementação e expressões booleana de features. •  Responde a questão –  Quando cada artefato de código está habilitado para compor uma aplicação?6/6/11
  • 195. Abordagem em Ação•  Ilustrar as funcionalidades da ferramenta através de um exemplo.•  Passos da abordagem: 1.  Anotação de código com Features e Variabilidades 2.  Geração e refinamento dos modelos 3.  Implementando variabilidades com Templates 4.  Geração de uma instância da LPS
  • 196. Passo I – Anotação de Código da LPS•  Inicialmente, são criadas anotações no código de classes.•  Em geral, apenas classes representando variabilidades são anotadas, porque são@Feature(name="Adicao",parent="Operacao", type=FeatureType.optional)public únicas manipuladas no processo de as class OperacaoAdicao extends Operacao { public float resultado() { derivação. return getTermoUm() + getTermoDois(); }}
  • 197. Passo II – Processamento das Anotações•  Em seguidas, as anotações são processadas pelo plugin GenArch, usando a API Eclipse JDT de navegação na AST de programas Java.•  Uma versão inicial dos modelos é gerada baseado nas anotações.•  Além dos modelos, templates são criados para cada variabilidade da LPS anotada com @Variability 197
  • 198. Exemplo: Modelos Gerados
  • 199. Exemplo: Modelos Gerados 199
  • 200. Passo II: Preparação dos Modelos e Templates •  Modificações manual nos modelos: –  Criação de novas características –  Relacionamento das características com elementos de implementação •  Codificação dos templates 200
  • 201. Exemplo: Modelos Completos
  • 202. Exemplo: Janela de Configuração
  • 203. Passo II: Sincronização entre modelos e código•  Os modelos de derivação também podem ser revisitados para incorporar novas modificações ou novos requisitos.
  • 204. Passo III: Implementando Variabilidades com Templates«IMPORT br::pucrio::inf::les::genarch::models::instance»«EXTENSION br::pucrio::inf::les::genarch::models::Model»«DEFINE Main FOR Instance»«FILE "MSTestSuite.java"»«LET feature("Operacao",featureInstance) AS operacaoFeature»package br.pucrio.inf.les.genarch.exemplos.teste;public class MSTestSuite extends TestSuite { public static Test suite() { TestSuite suite = new TestSuite(); «FOREACH operacaoFeature.features AS child» suite.addTestSuite(Operacao«child.name»Teste.class); «ENDFOREACH» return suite; }}«ENDLET»«ENDFILE»«ENDDEFINE»
  • 205. Passo V: Derivação•  A partir de uma configuração (instância) do Modelo de Características, do Modelo de Configuração e do Modelo de Arquitetura (que expressa os elementos de implementação - classes, aspectos, arquivos, etc.) um novo produto (ou instância de um framework) é derivado em um projeto Eclipse/Java.•  Tal projeto contém apenas os elementos de implementação do modelo de arquitetura que são necessários para implementar a instância solicitada via Modelo de Características.
  • 206. Passo IV: Derivação 206
  • 207. Outro Exemplo: Rain of Fire
  • 208. Jogo Rain of Fire
  • 209. Jogo Rain of Fire•  (I) Anotação do código-fonte –  Maior parte das variabilidades implementadas com AspectJ•  (II) Processamento das anotações –  Geração dos modelos –  Não foi necessária a geração de templates –  Similar a um framework Black-Box
  • 210. Rain of Fire: Modelos
  • 211. Rain of Fire: Modelos
  • 212. Jogo Rain of Fire: Derivação•  Seleção de quais variabilidades serão endereças pelo produto gerado•  Cópia dos elementos, em função das características selecionadas, para um novo projeto Eclipse/Java
  • 213. GenArch •  Ferramenta de Derivação Baseada em Modelos –  Mestrado de Elder Cirilo na PUC-Rio, co- orientado com Carlos Lucena •  Deriva produtos automaticamente a partir de informações presentes nos modelos6/6/11
  • 214. GenArch •  Centrada na definição de três modelos: –  Modelo de Características •  Modela as variabilidades da LPS –  Modelo de Arquitetura •  Representação visual dos artefatos de código –  Modelo de Configuração •  Define o mapeamento entre características e artefatos de código. •  Representa o conhecimento de configuração em Programação Generativa6/6/11
  • 215. Modelo de Características •  Representa as características (variabilidades) do domínio •  Permite a criação de instancias da LPS (Produtos) baseada na seleção de Configurações características •  Pode apresentar regras globais (Se característica ‘x’ está selecionada então característica ‘y’ não pode ser selecionada)6/6/11
  • 216. Modelo de Implementação da Arquitetura•  Contém uma visão, organizada em containers dos artefatos de código da LPS –  Componentes –  Classes –  Aspectos –  etc•  É a partir do modelo de arquitetura que os artefatos de código são mapeados para expressões booleanas de características6/6/11
  • 217. Modelo de Configuração •  Contém o conhecimento de configuração da LPS. Mapeamento entre elementos de implementação e expressões booleana de features. •  Responde a questão –  Quando cada artefato de código está habilitado para compor uma aplicação?6/6/11
  • 218. Exemplo: Janela de Configuração
  • 219. Derivação Automática com GenArch 219