Linhas de Processo de Software: Conceitos, Técnicas e Ferramentas
Uirá Kulesza DIMAp / UFRN
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
• Contexto e Motivação • Engenharia de Processos de
Software • Linhas de Produto de Software • Linhas de Processo de Software
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
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
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
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
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
• Contexto e Motivação • Engenharia de Processos de
Software • Linhas de Produto de Software • Linhas de Processo de Software
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
• Contexto e Motivação • Engenharia de Processos de
Software • Linhas de Produto de Software • Linhas de Processo de Software
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
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.)
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
Limitações de Ferramentas Atuais
(3ª) Sem
suporte para a
execução de um
processo customizado
Limitações de Ferramentas Atuais
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
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.
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)
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.
Atividade 6 – Implantação e Execução do Workflow
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
Linhas de Processo de Software: Conceitos, Técnicas e Ferramentas
Uirá Kulesza DIMAp / UFRN
Em colaboração com Fellipe Aleixo, Marilia Freire e Daniel Alencar
Linhas de Processo de Software: Conceitos, Técnicas e Ferramentas
Uirá Kulesza DIMAp/UFRN
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
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?
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
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
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?
Exemplo: Janela de Configuração
Derivação Automática com GenArch
219
Top Related