Linhas de Processo de Software: conceitos, técnicas e ferramentas para reuso em processos

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

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?

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

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

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

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

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

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

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
Conhecimento Modelo do Arquitetura da
família de
do 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.

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

Que tal seguirmos um exemplo para
aprendermos como de fato funciona
a engenharia de LPS?

74

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)

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

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

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
–  Componentes, bibliotecas de classes
–  Linguagens específicas de domínio (wizards,
diagramas, ...) + geradores (derivação automática)

ESTRUTURA GERAL
FRAMEWORK
CORE DO JOGO
ARQUITETURA DE
LINHA DE PRODUTO
COMPILAÇÃO
CONDICIONAL

ARQUIVO DE
BUILD CONFIGURAÇÃO
DIFERENTES
PRODUTOS

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);
// #endif
this.drawCity(g);
this.drawCatapults(g);
}
}
...
}

ARQUITETURA DE
LINHA DE PRODUTO FRAMEWORK
CORE DO JOGO
ASPECTOS

ESCOLHA DE FEATURES
BUILD (DSLS, XML, ETC)‫‏‬
DIFERENTES
PRODUTOS

CÓDIGO DE JOGO COM ASPECTOS
Exemplo de Aspecto
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);
}
...
}

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

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

Outro Exemplo

Eclipse IDE como uma
Linha de Produto de Software

91

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

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

Pontos Flexíveis do Eclipse
Menu bar
Text
Tool bar editor

Perspective
and
Fast View
bar

Outline
Resource view
Navigator
view

Bookmarks
view
Properties
view
Message Editor
area Status
area
Stacked
views
200303331 Tasks
95 view

Plataforma Eclipse

Eclipse Platform

Workbench

“UI”
JFace
SWT Team Help Debug

“Core” Workspace Ant

Platform Runtime

Linhas de Processo de Software
•  Estudo de técnicas e mecanismos
para gerência de variabilidades em

•  Proposição e adaptação de técnicas
existentes da área de engenharia de
linhas de produto

•  Objetivos:
–  Gerência de variabilidades em famílias
de processos de software
–  Composição e Customização de

•  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

H. Dieter Rombach

Integrated Software Process and
Product Lines

Proceedings of ISPW 2005

102

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

Ove Armbrust, et al

Scoping Software Process Lines

Journal of Software Process
Improvement and Practice, 2009

106

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

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

Thomas Ternité

Process Lines: A Product Line
Approach Designed for Process
Model Development

Proceedings of
EUROMICRO-SEAA 2009

119

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 core da linha de processo. Classes específicas de uma
arquitetura de linha de processo

Uma instância do modelo de processo

Variante do modelo de processo

Instâncias dos elementos do modelo

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.

Simidchieva, et al

Representing Process Variation
with a Process Family

Proceedings of ICSP 2007

124

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

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

Hironori Washizaki

Building Software Process Line
Architectures from Bottom Up

Proceedings of PROFES 2006

129

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.

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

Barreto, et al

Supporting the Definition of Software
Processes at Consulting Organizations
via Software Process Lines

Proceedings of QUATIC 2010

134

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.

Ferramenta Web de Apoio (cont.)

Bendraou, et al

Combining Aspect and Model-
Driven Engineering Approaches for
Software Process Modeling and
Execution

Proceedings of ICSP 2009
140

Bendraou et al
  Propõe um framework e uma abordagem
para a modelagem e execução dos

  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

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

Aleixo, et al

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

Proceedings of SBES 2010

(nominated to the best paper)

147

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
Gerência automatizada de
Definição e Modelagem variabilidades dos
da Linha de Processos elementos da linha de
processo, utilizando uma
ferramenta de derivação de
produtos, como o GenArch

Gestão de Variabilidades
da Linha de Processos

Visão Geral

Definição e Modelagem
Derivação Automática
do Processo Customizado

Gestão de Variabilidades

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
Seleção das
features
desejadas

Geração
automática
de uma
especificação
de processo no
GenArch

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

Considerações Finais e
Desafios Futuros

184

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

uira@dimap.ufrn.br

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

Uirá Kulesza
DIMAp/UFRN

uira@dimap.ufrn.br

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

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

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

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
@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();
}
}

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

Exemplo: Modelos Gerados

199

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

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

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

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

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

Derivação Automática com GenArch

219

Linhas de Processo de Software: conceitos, técnicas e ferramentas para reuso em processos

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Linhas de Processo de Software: conceitos, técnicas e ferramentas para reuso em processos

Semelhante a Linhas de Processo de Software: conceitos, técnicas e ferramentas para reuso em processos (20)

Último

Último (20)

Linhas de Processo de Software: conceitos, técnicas e ferramentas para reuso em processos