linhas de processos de software - minicurso - sbqs 2011

Linhas de Processo de Software: Conceitos, Técnicas e Ferramentas

Uirá Kulesza DIMAp / UFRN

[email protected]

Em colaboração com Fellipe Aleixo, Marilia Freire e Daniel Alencar

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

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

Agenda

•  Contexto e Motivação •  Engenharia de Processos de

Software •  Linhas de Produto de Software •  Linhas de Processo de Software

Motivação •  Demanda crescente pela definição e

melhoria contínua de processos para promover o desenvolvimento produtivo de software de qualidade

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

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

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

Desafios •  Como lidar com redundância e

inconsistências oriundas de processos definidos para uma organização?

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?

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?

Complexidade na Eng. de Processos

Desafio Geral

•  Como promover o reuso dentro de uma família de processos relacionados ?

•  Como gerenciar variabilidades que ocorrem em tal família?

Agenda



Engenharia de Processo

•  Área responsável pela criação, modelagem, adaptação e representação de processos de software

Visão do SWEBOK

Como vocês definem seus processos de software?

Conhecimento na área

•  Modelos de Ciclo de Vida

•  Frameworks de Processos (RUP)

•  Práticas Agéis (XP, SCRUM)

•  Modelos de Maturidade

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

Como especificar processos de software?

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


•  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


•  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

Estudo Comparativo

R. 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)

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

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

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

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

Reuso em Processos de Software

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

Eclipse Process Framework

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

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

Method Content x Processos

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

Conteúdo de Métodos x Processos

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

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

EPF Composer - Conceitos

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

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

Reuso de conteúdo entre processos

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

Agenda



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

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...

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)

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 !!

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]

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

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)

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

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

Conceitos Básicos

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]

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)

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

Exemplos de Features Comuns e Variáveis

•  Rain of Fire

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

Desenvolver LPSs consiste em gerenciar adequadamente

suas variabilidades !

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

Engenharia de LPSs

•  Tipicamente organizada em: – Engenharia de Domínio

• Desenvolvimento para Reuso – Engenharia de Aplicação

• Desenvolvimento com Reuso

Engenharia de LPSs Engenharia de Domínio

Engenharia de Aplicação

Análise de Domínio

Projeto do Domínio

Implem. do Domínio

Análise de Requisitos

Configuração do Produto

Integração e Testes

Conhecimento

do domínio

Modelo do

domínio

Arquitetura da família de sistemas

Necessidades dos

clientes

Features Configuração

do produto Produto

Linguagem específica do domínio

Componentes

Geradores

Novos requisitos

Novos requisitos Customização

Projeto Customização

Desenvolvimento

Czarnecki, K., Eisenecker, U.: “Generative Programming: Methods, Tools, and Applications”, Addison-Wesley, 2000.

Engenharia de LPSs

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

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

Problema

Instanciar manualmente variabilidades de uma LPS é uma

atividade bastante custosa

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)

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)

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

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

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 para aprendermos como de fato funciona

a engenharia de LPS?

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)

Rain of Fire

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

Exemplos de Features Comuns e Variáveis

•  Rain of Fire

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.

Arquitetura do Rain of Fire

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)

ESTRUTURA GERAL

BUILD

ARQUITETURA DE LINHA DE PRODUTO

FRAMEWORK CORE DO JOGO

DIFERENTES PRODUTOS

ARQUIVO DE CONFIGURAÇÃO

COMPILAÇÃO CONDICIONAL

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

CÓDIGO DE JOGO COM COMPILAÇÃO CONDICIONAL public 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); } } ... }

BUILD

ARQUITETURA DE LINHA DE PRODUTO FRAMEWORK

CORE DO JOGO

ASPECTOS

DIFERENTES PRODUTOS

ESCOLHA DE FEATURES (DSLS, XML, ETC)‏

CÓDIGO DE JOGO COM ASPECTOS

public 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); } ... }

Exemplo de Aspecto

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.

Modelos de Feature e Arquitetura

Modelo de Configuração

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 uma Linha de Produto de Software

Eclipse como uma Linha de Produto

Platform Runtime

Workspace

Help

Team

Workbench

JFace

SWT

Eclipse Project

Java Development

Tools (JDT)

Their Tool

Your Tool

Another Tool

Plug-in Development Environment

(PDE)

Eclipse Platform

Debug

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

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

200303331 95

Pontos Flexíveis do Eclipse

Tool bar

Perspective and Fast View bar

Resource Navigator view

Stacked views

Properties view

Tasks view

Outline view

Bookmarks view

Menu bar

Message area

Editor Status area

Text editor

Plataforma Eclipse

Platform Runtime

Eclipse Platform

Workspace

Workbench

SWT JFace

Team Help Debug

Ant “Core”

“UI”

Agenda



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

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

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).

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 Rombach

Integrated Software Process and Product Lines

Proceedings of ISPW 2005

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

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

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 al

Scoping Software Process Lines

Journal of Software Process Improvement and Practice, 2009

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

Scoping Process Lines

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

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

Análise de Produtos

•  Probabilidade de desenvolvimento versus caracterização de atributos

Análise de Projetos

•  Probabilidade de desenvolvimento versus caracterização de atributos

Análise de Processos

•  Avaliação dos processos, métodos e técnicas utilizados em função dos atributos de produto e projeto

Priorização de Atributos

•  Avaliação de atributos mais importantes para produtos e projetos através de comparações dois-a-dois

Determinação do Escopo

•  Definição de métodos, técnicas e processos mais relevantes em função de atributos de produto e projeto

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

Estudo de Caso

119

Thomas Ternité

Process Lines: A Product Line Approach Designed for Process

Model Development

Proceedings of EUROMICRO-SEAA 2009

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.

Um metamodelo para descrever Linha de Processo

Classes específicas de uma arquitetura de linha de processo

Classes core da linha de processo.

Uma instância do modelo de processo

Instâncias dos elementos do modelo

Variante do modelo de processo

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 al

Representing Process Variation with a Process Family

Proceedings of ICSP 2007

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

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

Visão Geral

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 Washizaki

Building Software Process Line Architectures from Bottom Up

Proceedings of PROFES 2006

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.

Product Line Architecture

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>>

Estudo de Caso: Arquitetura da Linha de Processo Co-Design

134

Barreto, et al

Supporting the Definition of Software Processes at Consulting Organizations

via Software Process Lines

Proceedings of QUATIC 2010

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.

Visão Geral

Ferramenta Web de Apoio

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

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

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

Modelagem UML4SPM

para a fase de Concepção

Modelo de Execução

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

147

Aleixo, et al

Uma Abordagem para Gerência e Customização de Variabilidades em

Processos de Software

Proceedings of SBES 2010

(nominated to the best paper)

Limitações de Ferramentas Atuais

(1ª) Edição e

configuração manual de processos de software

(2ª) Reuso de

elementos de processos de

software através da cópia

destes entre diferentes processos


(3ª) Sem

suporte para a

execução de um

processo customizado


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

Visão Geral

Definição e Modelagem da Linha de Processo Usando uma ferramenta

de especificação de processos, como o Eclipse Process Framework Composer

Visão Geral

Definição e Modelagem da Linha de Processos

Gestão de Variabilidades da Linha de Processos

Gerência automatizada de variabilidades dos elementos da linha de processo, utilizando uma ferramenta de derivação de produtos, como o GenArch

Visão Geral

Definição e Modelagem da Linha de Processos

Gestão de Variabilidades da Linha de Processos

Derivação Automática do Processo Customizado

Atividade 1 – Definição e Modelagem da LPS

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

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

Exemplos de Features Identificadas para o OpenUP

Atividade 2 – Gerência das Variabilidades

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

Importação da Especificação de Processo pelo GenArch

Especificação do Processo em EPF

Modelos do GenArch

Modelagem de Variabilidades em Diferentes Granularidades

1. Granularidade grossa – arquivos XMI que representam elementos de processo EPF

2. Granularidade fina – fragmentos de arquivos XMI que contém informações de detalhamento de um dado elemento de processo

Exemplo de Variabilidades em Diferentes nos Diferentes Níveis de Granularidades

Feature de granularidade grossa:

Atividade

Features de granularidade fina: Tarefas, Artefatos de entradas e

Artefatos de saída

Resultado Final do Processo de Importação

Extensão do GenArch para Processos EPF

Atividade 3 – Derivação de Processos

Derivação de Processos Customizados

Nova configuração do modelo de

features

Geração automática

de uma especificação

de processo no GenArch

Seleção das features

desejadas

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

Execução de Processos de Software

Atividade 4 – Transformação Processo-to-Workflow

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

Tabela de Mapeamento: Process-to-Workflow

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.


•  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)


•  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.

Atividade 6 – Implantação e Execução do Workflow

Atividade 7 – Gerenciamento do Workflow

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.

Ferramenta de Transformação Processo-para-Workflow

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)

Novas Perspectivas e Refinamentos •  Modelagem e Deployment de Métricas

– Seleção de métricas do processo e quantificação automática

•  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

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)

184

Considerações Finais e Desafios Futuros

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

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

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

Perguntas, Dúvidas...

Uirá Kulesza DIMAp/UFRN

[email protected]


Uirá Kulesza DIMAp / UFRN

[email protected]

Em colaboração com Fellipe Aleixo, Marilia Freire e Daniel Alencar


Uirá Kulesza DIMAp/UFRN

[email protected]

6/6/11

GenArch na Prática

6/6/11

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 características

•  Pode apresentar regras globais (Se característica ‘x’ está selecionada então característica ‘y’ não pode ser selecionada)

Configurações

6/6/11

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ísticas

6/6/11


•  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?

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

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 as únicas manipuladas no processo de derivação.

@Feature(name="Adicao",parent="Operacao", type=FeatureType.optional)

public class OperacaoAdicao extends Operacao { public float resultado() { 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

Exemplo: Modelos Gerados

199

Exemplo: Modelos Gerados

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

Exemplo: Modelos Completos

Exemplo: Janela de Configuração

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.

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»

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.

Passo IV: Derivação

206

Outro Exemplo: Rain of Fire

Jogo Rain of Fire

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

Rain of Fire: Modelos

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

6/6/11

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 modelos

6/6/11

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 Generativa

6/6/11

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 características

•  Pode apresentar regras globais (Se característica ‘x’ está selecionada então característica ‘y’ não pode ser selecionada)

Configurações

6/6/11

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ísticas

6/6/11


•  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?

Exemplo: Janela de Configuração

Derivação Automática com GenArch

219

linhas de processos de software - minicurso - sbqs 2011

Education