1.
Introdução / Motivação
2.
Definição de Linha de Produto de Software
3.Experiências com Linhas de Produto
4.Implantando uma Linha de Produto
5.Análise de Domínio
6.
Projeto de Domínio
7.Exercício
4
§
Henry Ford
•
“The father of assembly-line automation”
§
Produção do Modelo T (1908)
§
Principal conceito:
“
Interchangeable
parts
”
§ Baseado nas idéias de Honoré Blanc e Eli Whitney
§
Processo de produção mais eficiente
•
Linha de automóveis
•
Acessível, construídos mais rapidamente, alta
qualidade
“
Any customer can have a
car painted any colour that
he wants so long as it is
black” -
Henry Ford
•
Line of motor cars
•
affordable, built quickly, high quality
“
Any customer can have a
car painted any colour that
he wants so long as it is
black” -
Henry Ford
Certain choices where
extremely limited!
•
Economia de Escopo
•
Customização em massa
:produção de bens e serviços que atendam as
necessidades
individuais dos clientes
• Cria umaarquitetura base
para servir de
platforma do
produto
da organização•
Core assets
podem ser reusados para construção de novos produtos a partir dafamília base
Economia de
escala Economia de escopo Múltiplas instâncias idênticas de um único design Múltiplos design similares gerando instâncias distintas
•
Baseado nas idéias de PLE
• Princípios fundamentais:
•
Identificação de
comunalidades
•
Gerenciamento de variabilidades
• Adaptação em massa de acordo com as
necessidades dos clientes
• Adaptação é tipicamente realizada durante o
desenvolvimento da SPL
On the Design and Development of Program Families Parnas, D.L.;
IEEE Transactions on Software Engineering, Vol. 02, Issue 01, March 1976, pp. 1 – 9
Desenvolveu o conceito de
desenvolvimento modular
e os
fundamentos da POO
"Software product line engineering is a paradigm to
develop software applications (software-intensive
systems and software products) using platforms and
mass customization."
[Pohl et al., 2005]
“
A software product line is a set of software-intensive systems
sharing a common, managed set of features that
satisfy the specific needs of a
particular market
segment
or mission and that are developed from a
common set of core assets in a prescribed way
.
Paul Clements and Linda Northrop, 2002}
Alcançar
ganhos de produtividade em larga-escala
}Melhorar
time-to-market
}
Manter presença de mercado
}
Melhorar a
qualidade dos produtos desenvolvidos
}Aumentar a satisfação do cliente
◦
customização em massa
}
Alcançar os objetivos de reuso
Management Core Asset
Development Product Development
Domain Engineering Application Engineering
Management Core Asset Development
}
Core assets formam a base para a produção
de produtos em uma SPL
}
Core assets
◦ Architecture {scope, styles, patterns, and frameworks}
◦ Componentes
◦ Plano e casos de teste
◦ Modelos do domínio
◦ Requisitos
◦ Casos de uso
◦ Mapa de produtos
◦ Etc ….
}
Um plano de produção descreve como os produtos
são produzidos a partir dos core assets
◦
{reuser’s guide}
}
Um conjunto de processos
}
Um plano de produção deve descrever:
◦
Ferramentas
◦
Métricas, plano de métricas
Product Development
}
Papel crítico
no
sucesso
da linha de produtos
}Aspectos técnicos
◦ Core asset development
◦ Product development
}
Aspectos organizacionais
◦ treinamento◦ Investimento
◦ Riscos
}
Muitos casos de sucesso citados pela literatura
envolvendo grandes empresas que obtiveram
excelentes resultados com a aplicação de Linhas de
Produto de Software
(Product Line Hall of Fame
)
◦ Asia Brown Boveri (ABB) “The reference architecture of the turbine control system for
the ABB Gas Turbine Family led to shorter development
time, higher code quality, and eased the exchange of modules.”
◦ Boeing Company
“The success of the Bold Stroke software product line is based
on the reduction of dependencies between components
◦
Hewlett-Packard
Tempo de desenvolvimento reduzido em
67%
96%
menos defeitos◦
Philips
Lidera o mercado de pesquisadores europeus no campo de linhas de produto de software.
Philips Consumer Electronics provê linhasdeprodutode
softwarepara equipamentos de áudio e vídeo, tais como
aparelhos de TV, apresentando uma arquitetura de referência
estável.
}
Nokia
◦ Líder mundial no ramo de aparelhos celulares (40% do mercado)
◦ 25~30 novos produtos por ano em mais de 130 países
◦ Suporte:
58 línguas
Variável número de teclas Diferentes tamanhos de tela Diferentes conjuntos de features
Variações de protocolos, operadoras, hardware e estilo (série XX) Features configuráveis (Liga / Desliga -- > Conectar e usar)
◦ Diferentes Linhas de Software espalhadas pelo mundo. Releases são feitos para outros grupos.
Arquitetura Interface com o usuário Etc.
§
Linhas de produtos da Nokia
§
Exemplos de componentes – Idioma
§ Suporte a 58 idiomas
§ Várias línguas não-latinas (Chinês, Árabe, Hebraico, Thai)
§ Recurso opcional de T9
§ Ao alterar a língua ativa, todos os textos devem ser
alterados automaticamente
§
Solução
§ Separar a base de conhecimento da língua do código § Separaraparência de comportamento
§ Independente da língua escolhida, o código não muda
§
Exemplos de componentes – Idioma
§
Sugestões: think ahead
§
Sempre pense na frente
§
Faça sempre brainstroms
sobre todos os
possíveis
usos futuros de features
§
Considere o
impacto
de
novas tecnologias
§
Considere todas as variáveis que podem ser
configuráveis
§
Enquanto não é necessário prever todo o futuro,
leve-o em consideração no seu projeto
(arquitetura). Isso vai salvar muito tempo no
futuro.
}
Tecnologias de Linhas de Produto são também encontradas
no nosso
dia-a-dia
}
Exemplos:
◦
Meantime
adaptações de jogos/software para diferentes dispositivos/
celulares;
◦
Geradores de CRUD
Geradores de código fonte para operações básica de cadastro
(inserir, remover, consultar e atualizar) de sistemas web de informação baseado numa arquitetura genérica
◦
Plataforma Eclipse
Arquitetura extensível baseada em plugins que permite a customização do seu ambiente para diferentes usuários
◦
Diferentes versões do Eclipse podem ser customizadas, e
elas podem até mesmo “sobreviver” juntas em tempo de
execução
Diferentes perspectivas: Modelagem, Implementação, Testes, Gerência de Configuração, Depuração
◦
A
arquitetura extensível baseada em plugins
do Eclipse
pode também ser considerada uma
arquitetura de linha de
produto
que permite a criação/geração de vários produtos
◦
A arquitetura do Eclipse oferece uma estrutura flexível
que :
Oferece pontos de extensão específicos que podem ser estendidos pelo usuário final
A instalação/desinstalação de plugins que estendem os pontos de extensão oferecidos pela plataforma do Eclipse, possivelmente, oferecendo novas plataformas para isso
São componentes de código e/ou dados que contribuem para a extensão da plataforma com alguma funcionalidade, tais como:
novas bibliotecas/APIs
novas visões/perspectivas/editores/depuradores documentação (help)
Em geral, estendem pontos de extensão oferecidos pela plataforma (outros plugins), assim como podem oferecer seus próprios pontos de extensão
◦
Exemplos:
JDT (Java Development Tooling), PDE (Plugin Development Environment)
JUnit Extensions, Ferramenta de Modelagem UML, etc
•
Redução dos
custos de desenvolvimento
[Pohl et al. 2005]
}
Engenharia de linha de produto de software baseia-se
em dois processos:
◦
Estabelecimento da plataforma (Engenharia de
Domínio)
Gerenciamento de pontos variáveis e pontos em comum.
Plataforma consiste em: requisitos, projeto do domínio,
implementação de componentes, testes.
◦
Derivando aplicações (Engenharia de Aplicação)
Explora variabilidade de acordo com as necessidades
específicas de cada aplicação.
}
Artefatos do domínio
◦ Mapa de produtos◦ Modelo de variabilidade do domínio
◦ Requisitos do domínio
◦ Arquitetura do domínio
◦ Implementação de artefatos do domínio
◦ Testes de artefatos do domínio
}
Artefatos da aplicação
◦ Modelo de variabilidade da aplicação◦ Requisitos da aplicação
◦ Arquitetura da aplicação
◦ Implementação de artefatos da aplicação
ANÁLISE DE DOMÍNIO
Análise de Domínio
§ Elicitar e documentar os requisitos (características) que são comuns e variáveis para aplicações de um domínio específico (linha de produtos)
§ Entrada: product roadmap (resultado da definição do escopo)
§ Saídas
§ Modelo de features
§ Documentação [reusável] dos requisitos (texto + modelos)
◦ O domínio (comunalidades e variabilidades) é representado em termos de features
} Feature
◦ Característica de um sistema que é relevante e visível para o usuário final ◦ Uma característica distinguível de um um conceito que é relevante para algum
stakeholder [Kang et al., 1990]
} Elementos
◦ Modelo de features ◦ Definição das features ◦ Regras de composição ◦ Justificativa para as features
} Tipos de features
◦ Mandatórias: devem estar presentes ◦ Opcionais: podeounãoestar presente
◦ Alternativas:exatamente 1 feature deve ser selecionada de um grupo de features alternativas
◦ OR: pelo menos 1 deve ser selecionada de um grupo de features OR
Complete Mandatory Features Optional Feature
Submission
Review
Notification
Partial Alternative Features News Assigment Result Accept/Reject Indication Automatic Manual OR Features • Dependências • Implicação • ExclusãoFEATURE MODELS
}
Variabilidade:
Forma como os membros de uma
família de produtos podem se diferenciar entre si
}
Informações a considerar
◦
O que varia?
Documentação dos locais onde a variabilidade está presente (variation points)
◦
Por que varia?
Documentação textual das razõesque justificam a existência da variabilidade
◦
Como varia?
Documentação das alternativas possíveis (variantes) para resolver uma determinada variabilidade
◦
Variabilidade em requisitos do domínio:
}
Planejar o domínio
◦
Atividades iniciais para o analista de domínio
Analisar stakeholders
Definir objetivos
Definir restrições
Analisar mercado, se possível Coletar dados
◦
Tarefas
Mapear aplicações candidatas
Caracterizar aplicações
Analisar benefícios
O GERENCIAMENTO DE VARIABILIDADES PODE CONTAR COM O APOIO AUTOMATIZADO!
}
Modelar o domínio
◦
Seguindo guidelines para organizar features
Não usar features para representar dependências funcionais,
como por exemplo chamadas de funções. Features são usadas para capturar pontos em comum e pontos variáveis. As simple as possible
}
Validar o domínio
◦
Documentar features
◦
Documentar o domínio
◦
Validar consistência do domínio
PROJETO DE DOMÍNIO
PROJETO DO DOMÍNIO
Objetivos
§ Produzir a arquitetura de referência
• Como os requisitos [variabilidades] são refletidos na arquitetura § Definir a estrutura do software
Relacionamentos § Requisitos do domínio § Implementação do domínio § Projeto da Aplicação Principais Saidas • Arquitetura de referência • Modelo de variabilidades refinado
DIFERENÇAS COM RELAÇÃO AO PROJETO DE
SISTEMAS SIMPLES
§ Incorpora mecanismos de configuração na arquitetura de referência para suportar a variabilidade da linha de produtos § Considera flexibilidade como um dos principais atributos de
qualidade
§ Arquitetura de referência pode ser adaptada para requisitos de aplicações futuras
§ Define regras comuns para o desenvolvimento de aplicações específicas que são baseadas na arquitetura de referência § Partes reusáveis: desenvolvidas e testadas na engenharia de
Requisitos de qualidade guiam a arquitetura
Alguns requisitos de qualidade só surgem a partir da Engenharia
de Linha de Produtos
§ Variabilidade (Configuração, Interna e Externa)
§ Flexibilidade (Mudanças não intrusivas pelos sistemas)
§ “Evolubilidade” (Evoluir a arquitetura de acordo com as mudanças dos requisitos)
§ Manutenibilidade (Facilidade em encontrar e corrigir erros)
REQUISITOS DE QUALIDADE
[Pohl et al., 2005]
}
Artefatos
◦ Domain specific software architecture document; diagramas
(componentes, classes, modulos)
[Pohl et al., 2005]
Construção de:
• Feature Model
• Product map (Mapa do produto) • Requisitos
• Casos de uso • Diagramas UML
}
