desenvolvimento baseado em componentes (dbc) · celulares silenciosos ... regras e serviços para...
TRANSCRIPT
Slide 1 de 81
Desenvolvimento Baseadoem Componentes (DBC)
28 de fevereiro de 2011
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B
Slide 2 de 81
Apresentação do Instrutor
Dúvidas? Interrompam à vontade...
Celulares silenciosos
Uma atividade prática será apresentada ao final da aula
Slide 3 de 81
Como assim reuso? O que é reuso?
Quem faz reuso?
Você fez/faz/pensa em fazer?
Como? Quando? Onde? Por que?
Slide 4 de 81
O que são componentes para você? Tipos/Categorias Quando Positivos Negativos
Slide 5 de 81
Motivação Contexto Definições Características básicas Taxonomia Componentes e objetos Elementos envolvidos com DBC Métodos para DBC
Slide 6 de 81
Reuso e Componentes de
Software
Slide 7 de 81
Slide 8 de 81
Visão clássica◦ Software = blocos monolíticos◦ Partes inter-relacionadas◦ Mundo integral
DBC◦ Pedaços de blocos◦ Redução
Complexidade Tempo de desenvolvimento
◦ Mundo distribuído
Slide 9 de 81
Componentes são unidades de ◦ Abstração “Não consegue resolver um problema? Abstraia
um nível acima”◦ Análise Divisão em partes menores facilita o
entedimento/análise.◦ Disputa Diferentes fornecedores de componentes VS
falha no sistema◦ Gerenciamento de Configuração◦ Deployment◦ Manutenção
Slide 10 de 81
Desenvolvimento de Componentes◦ Não é simples Visão de domínio Uso de abstrações Informações Documentação Informações de teste Help…
Retorno de Investimento◦ Desenvolvimento em “casa” Tempo de entrega Manutenabilidade Flexibilidade
“…imperfect technology in a working market is sustainable;Perfect technology without any market will vanish…”
Szyperski, 2002, pp. 18
Slide 11 de 81
Componentes de Software
Slide 12 de 81
Sametinger (1997)◦ Reusable software components are self-contained,
clearly identifiable artifacts that describe and/or perform specific functions and have clear interfaces, appropriate documentation and a defined reuse status
Heineman (2001)◦ A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a component standard
Szyperski (2002)◦ A software component is a unit of composition with
contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties
Slide 13 de 81
• É uma unidade de implantação independente•Com dependências explícitas de contexto
• É uma unidade de composição•Interfaces especificadas contratualmente •Documentação
• Não possui estado externo observável•Não se distingue de cópias de si mesmo•Não pode ser instanciado como objeto
Slide 14 de 81
Aplicabilidade◦ É a probabilidade que um componente possui para ser
reutilizado em outros sistemas
Generalização◦ Quanto mais genérico é um componente, maior é a sua
aplicabilidade. Entretanto, deve-se existir uma balança pela generalização devido a utilização de recursos (ex. Generalização x Desempenho)
Completude◦ Um componente é completo quando ele oferece a
funcionalidade esperada pelos reutilizadores em outros cenários, diferentes do originalmente desenvolvido
Concorrência◦ Execução de instruções em paralelo
ATRIBUTOS DE COMPONENTES - FUNCIONALIDADE
Slide 15 de 81
Interação de Componentes◦ Alta coesão◦ Baixo acoplamento (métricas – módulo avançado)
Distribuição◦ Componentes são distribuídos logicamente e
algumas vezes separados fisicamente◦ Aumento do poder computacional, flexibilidade
[diferentes equipes, diferentes fornecedores]
ATRIBUTOS DE COMPONENTES – INTERAÇÃO E DISTRIBUIÇÃO
Slide 16 de 81
Adaptação◦ Customização◦ Modificação
Qualidade◦ Tolerância a falhas◦ Componentes distribuídos◦ Testes e certificação de componentes (módulo
avançado)
ATRIBUTOS DE COMPONENTES – ADAPTAÇÃO E QUALIDADE
Slide 17 de 81
Slide 18 de 81
Slide 19 de 81
Componentes◦ Unidade de implantação independente◦ Composição por terceiros◦ Não possui estado externo (observável)
Objetos◦ Unidade de instanciação e tem um identificador
único◦ Possui estado externo◦ Encapsula seu estado e comportamento
COMPONENTES x OBJETOS
Slide 20 de 81
Componentes◦ Black-box JAVA API Uso baseado nas interfaces
◦ White-box Acesso ao código fonte Adaptações e Modificações
Objetos◦ Entidades que encapsulam estado e comportamento e
possuem um identificador único◦ Comportamento e estruturas definidos por classes que:
- Implementam Tipos Abstratos de Dados- Provêem abstrações do comportamento dos objetos- Provêem implementações concretas do comportamento dos
objetos- Permite a criação de objetos – instâncias de classes
COMPONENTES X OBJETOS
Slide 21 de 81
Os modelos de componentes são baseados no paradigma orientado a objetos
Os componentes definem o comportamento e a criação dos objetos
Ambos disponibilizam suas funcionalidades através de descrições de comportamento abstratas - interfaces
COMPONENTES E OBJETOS - SIMILARIDADES
Slide 22 de 81
Implementação de componentes é geralmente oculta e algumas vezes disponível
Componentes podem ser implementados emdiferentes modos: classes únicas, diversasclasses ou procedimentos não orientado a objetos
Componentes são desenvolvidos segundo um modelo de componentes bem definido
COMPONENTES E OBJETOS - DIFERENÇAS
Slide 23 de 81
Slide 24 de 81
GUI Mais comum, baixa complexidade. Reuso deste tipo de
componente pode aumentar a produtividade em até 40%.
Serviços Média complexidade. Reuso deste tipo de componente pode
aumentar a produtividade em até 150%.
Domínio Alta complexidade por pertencer a todo o domínio em questão.
Reuso deste tipo de componente pode aumentar a produtividadeem até 1000%.
Slide 25 de 81
Slide 26 de 81
Componentes precisam ser visíveis
externamente
Slide 27 de 81
Ponto de Acesso◦ Especifica um conjunto de operações que podem ser
invocadas por clientes
Funciona como contrato entre os componentes e os seus“clientes”
◦ Providas Os componentes possuem os detalhes de implementação
de todas as operações definidas pela interface
◦ Requeridas Os componentes solicitam uma interação definida pela
interface e esperam que outros componentesimplementem as operações
INTERFACES
Slide 28 de 81
Contratos definem:◦ O que o cliente precisa saber para
utilizar as interfaces
◦ O que o provedor tem que implementar de modo a atender os serviços definidos pela interface
◦ Definição de Pré x Pós condições
CONTRATOS
Slide 29 de 81
Representa o uso do contratoProvê uma lista de operaçõesDefine um modelo específico informação lógica subjacente à interfaceEspecifica a forma como as operações afetam, ou "confiam" no modelo de informaçõesDescreve apenas os efeitos locais
Representa a realização dos contratosFornece uma lista de interfaces suportadasDefine a unidade de tempo de execuçãoDefine as relações entre os modelos de informação de diferentes interfacesEspecifica como as operações devem ser implementadas em termos de utilização de outras interfaces
Interface Componente
Slide 30 de 81
Como padronizarcomponentes de
software
Slide 31 de 81
Modelos de Componentes definem um conjunto de padrões para implementação de componentes, interoperabilidade, customização, composição, evolução e implantação◦ Enterprise JavaBeans (EJB)◦ CORBA Component Model (CCM)◦ Microsoft .NET◦ OSGi
Implementação de um modelo de componentes -dedicado conjunto de elementos de software executáveis, necessários para suportar a execução dos componentes segundo um modelo de compoentes bem definido◦ Servidores de Aplicação Exemplos: JBoss, Web4J, Frameworks (Struts & Hibernate)
MODELOS DE COMPONENTES
Slide 32 de 81
Padrões para DescriçãoInterfaces Especificação de comportamento dos
componentes e de suas propriedades
Nomeação Nomes globais únicos para interfaces e componentes
Meta dados Informações sobre os componentes, as interfaces e seus relacionamentos
Interoperabilidade Comunicação e intercâmbio de dados entre componentes de diferentes fornecedores, implementados em diferentes linguagens
Customização Interfaces e ferramentas para customizar componentes
MODELOS DE COMPONENTES - ELEMENTOSHeterogeneidade de componentes demanda padrões
Slide 33 de 81
MODELOS DE COMPONENTES - ELEMENTOSHeterogeneidade de componentes demanda padrões – cont.
Padrões para Descrição
Composição Interfaces e regras para combinar componentes a fim de criar grandes estruturas
Suporte a Evolução Regras e serviços para substituir componentes ou interfaces por novas versões
Empacotamento e Implantação Empacotamento da Implementação e recursos necessários para instalar e configurar um componente
Slide 34 de 81
Execution Environment◦ Ambiente padronizado para aplicações
chamadas de bundles◦ J2SE, CDC (JSR 232: Mobile Operational
Management), CLDC, MIDP◦ http://www.osgi.org
Modules◦ Políticas de carregamento de classes◦ Classes privadas para módulos, bem como
links controlados entre módulos
Life Cycle Estados para os bundles - installed, started, stopped, updated and
uninstalled
Service Registry Provê cooperação entre os bundles Compartilhamento de objetos entre bundles
Slide 35 de 81
Equinox◦ Implementação de referência para o OSGi R4. Previamente
instalada no coração do Eclipse. Tutorial: http://aneeshkumarkb.blogspot.com/
Apache Felix◦ Implementação open source da Apache Software Foundation.
Ainda não está completamente compatível com OSGi R4
knopflerfish◦ Implementação open source para OSGi R3 and OSGi R4
Informações interessantes - Hello, OSGi, Part 1: Bundles for beginners◦ http://www.javaworld.com/javaworld/jw-03-2008/jw-03-
osgi1.html?page=1
Slide 36 de 81
Como desenvolverum componente de
software
Slide 37 de 81
Catalysis◦ Desenvolvido na Universidade de Brighton, Inglaterra, por
D’Souza e Wills ◦ Busca solucionar problemas Rastreamento de requisitos Semântica para verificar consistência Níveis de granularidade e refinamento Distinção entre modelos do domínio, modelos do
sistema e arquitetura
Características◦ Processo: também abrange áreas que não dizem respeito
ao código. Daí poder ser considerado também um processode eng. de domínio.
◦ Rastreabilidade◦ Reuso
Slide 38 de 81
Baseado em um conjunto de princípios: ◦ Abstração◦ Precisão ◦ Refinamento◦ Componentes “plug-in” ◦ Leis de reutilização: não reutilizar código sem
reutilizar modelos de especificações desses códigos
Slide 39 de 81
Existem diversos caminhos possíveis
Cada um com uma sequência diferente de atividades e artefatos
Um caminho pode omitir atividades / artefatosque outro inclua
Diferentes caminhos podem ser utilizados para qualquer projeto ou subprojeto
Uma rota mais “leve” pode ser um bom caminho
Slide 40 de 81
Esforço de países europeus em conjunto de 2000 a 2002 para realização do projeto.
Objetivo:◦ Prover um ambiente que suporte a especificação, composição,
checagem de configuração e implantação de sistemas embarcados construídos a partir de componentes de software.
Pontos-chave (similar a outros métodos com o foco em sistemas embarcados)◦ Modelo de componente◦ Linguagem de composição◦ Ambiente de Composição ◦ Ambiente de Componentes Leve
Ambiente de composição disponível no site do projeto.◦ http://www.iam.unibe.ch/~scg/Archive/pecos/index.html
Slide 41 de 81
UML Components Bem focado na especificação de componentes Simples (baseado em estereótipos) Uso de UML e estrutura RUP Workflow
• Definição de requisitos• Especificação de componentes
– Identificação– Interação– Especificação
• Adequação• Codificação• Testes
Slide 42 de 81
Estereótipos◦ <<type>>. Usado para representar uma classe no modelo
de negócios de um componente em nível de especificação.
◦ <<datatype>>. Possui a mesma representação de Type, mas é usado para classes que utilizam persistência.
◦ <<interface type>>. Representa uma interface em nível de especificação.
◦ <<comp spec>>. Usado para indicar uma especificação de um componente.
◦ <<offers>>. Liga uma especificação de um componente à sua interface.
◦ <<core>>. O “core” subentende um “type” sem ocorrência de dependências.
Slide 43 de 81
Slide 44 de 81
Entradas: • Modelo de casos de uso• Modelo conceitual do
negócio
Saídas • Arquitetura• Especificação de componentes
Slide 45 de 81
“Um sistema de reserva para hotéis que permita que areserva seja feita para qualquer hotel da cadeia. Osistema deve oferecer quartos alternativos se o hoteldesejado estiver lotado. Cada hotel tem umadministrador de reservas responsável por controlar asreservas. O tempo para conseguir realizar uma reservapor telefone ou mesmo pessoalmente é, em média, trêsminutos. Para acelerar o processo, detalhes sobreclientes antigos serão armazenados e estarãodisponíveis.”
Exemplo para estudo de caso
Slide 46 de 81
Workflow de Requisitos
Slide 47 de 81
Fase 1 – Indetificação de componentes1. Identificar interfaces e operações do sistema
Modelos de casos de uso utilizado para descoberta de operações Formalizaçao do modelo conceitual do negócio
Slide 48 de 81
Identificar Casos de Uso
Slide 49 de 81
Slide 50 de 81
Slide 51 de 81
Identificação de componentes
Slide 52 de 81
Identificar as interfaces e operações do sistema
Slide 53 de 81
Fase 1 – Indentificação de componentes2. Identificar interfaces de negócio
Abstrações da informação manipulada pelo sistema Refinamento do modelo conceitual gerando o modelo
de tipos de negócioNão há
cadeia de hotéis
Não dá suporte a operações de pagamentos e contas
Simplificação
Slide 54 de 81
Fase 1 – Indentificação de componentes2. Identificar interfaces de negócio
Diagrama inicial de tipos de negócio
Slide 55 de 81
Fase 1 – Indetificação de componentes2. Identificar interfaces de negócio
A partir do Diagrama inicial de tipos de negócio, fazemos a identificação dos tipos <<core>>
Slide 56 de 81
Fase 1 – Indetificação de componentes2. Identificar interfaces de negócio Identificados os tipos <<core>>, criamos a
especificação inicial de interfaces
Slide 57 de 81
Fase 1 – Indetificação de componentes3. Especificar arquitetura de componentes
Uma vez que as interfaces foram identificadas e inicialmente especificadas, montamos a arquitetura de componentes.
Slide 58 de 81
Fase 2 – Interação de componentes◦ Objetivo: refinar especificação inicial de interfaces para obter
assinaturas das operações◦ Passos
Desenvolver modelos de interação para cada operação do sistema Diagramas de sequência
Descobrir operações das interfaces do sistema e suas assinaturas Assinaturas dos métodos
Refinar responsabilidades Atores atuantes nos diagramas de sequência
Definir restrições necessárias Regras de negócio que impõem restrições
Slide 59 de 81
Fase 3 – Especificação de componentes◦ Objetivo: obter a especificação completa dos componentes
e suas interfaces bem como os contratos de uso e realização.
◦ Passos Especificar o modelo de informação da interface
A partir das assinaturas das operações da fase 2 Definir pré e pós-condições
Restrições aplicadas às operações Montar especificação do componente
Visão geral do diagrama de componentes
Slide 60 de 81
Fase 3 – Especificação de componentes◦ Modelo de informação da interfaces
Slide 61 de 81
Fase 3 – Especificação de componentes◦ Diagrama de especificação de componentes (refinamentos
poderiam ter sido aplicados de acordo com a descoberta de operações durante a fase de interação de componentes)
Slide 62 de 81
Detalhes da Especificação dos Componentes
Slide 63 de 81
Slide 64 de 81
Será é viável a existênciade um mercado de
componentes de software
Slide 65 de 81
Será que dá certo?◦ www.componentsource.com Criado em 1995, maior repositório de componentes de software
do mundo. 880.000+ desenvolvedores 290.000+ visitantes por mês 100.000+ clientes 110 países Suporte 7x24 Pagamento em 20 diferentes moedas
◦ http://www.odesk.com/ (força de trabalho – mercado de desenvolvedores) 19.000 desenvolvedores Últimos três meses movimentou uma soma de 3 milhões de
dólares.
Slide 66 de 81
Classificação dos sites (Traas & Hillegersberg, 2000)
◦ Produtor: vende componentes◦ Catalogador: somente cataloga e aponta pra links mas não
vende◦ Intermediário: vende componentes contruídos por terceiros
Pontos a serem considerados para melhorar o mercado de componentes◦ Focar em componentes pouco granularizados (pequenos)◦ Fornecedores devem disponibilizar formas de avaliar os
componentes bem como vasta documentação sobre o mesmo (certificação de componentes)
◦ Devem ser oferecidos com preço aberto◦ Focar em reuso black-box Direitos autorais Príncipios de DBC (menos customização)
◦ Deve existir um engenho de busca específico pra componentes(www.krugle.com, http://code.google.com, www.codase.com)
Slide 67 de 81
O que temos pelafrente
Slide 68 de 81
Processos de reuso (linhas de produto ou eng. de domínio levam em consideração várias outras questões além de implementarem princípios de DBC:
•Features
•Model Driven Development
•Variability
•Métricas
•Repositórios
•Busca de componentes
•Ambientes de reuso
Slide 69 de 81
Linha do tempo de processos de reuso (Almeida et al., 2005)
Slide 70 de 81
Resumindo tudo quevimos e qual o nosso
contexto até então
Slide 71 de 81
Slide 72 de 81
Perceber a HORA e POSSIBILIDADE de criar um componente.◦ Quantas aplicações produzidas no mesmo domínio?◦ Quanto de código vem sendo reusado entre essas aplicações?◦ Qual o nível de customização do código de uma aplicação para
outra?◦ Código apresenta estabilidade suficiente?
“Ok, isso pode ser um componente.”◦ Que funcionalidades devem ser providas?◦ Documentação adequada ou somente os próprios
desenvolvedores conseguem usar?◦ Qual o benefício deste componente? ◦ Reutilizar o componente é mais difícil do que codificar a
funcionalidade novamente?◦ Qual o esforço gasto para criação/manutenção do componente
em relação ao tempo economizado com o reuso do mesmo?
Slide 73 de 81
1) Standard adaptable screen. 2) Standard adaptable screen with active context menu. 3) Standard form with CustomTextField and CustomCheckBox components appended. 4) Popup with a visual effect applied to the background screen. 5) Message screen with a scroll bar. 6, 7 and 8) Examples of standard MIDP screens.
Slide 74 de 81
Alguns pesquisadores acreditam numa evolução natural dos paradigmas, como representado:
Serviços?
Aspectos?
Linhas de Produto?
Serviços?
Aspectos?
Linhas de Produto?
Linguagens Baixo Nível
Orientação a Objetos
Desenv. Baseado em
Componentes
Linguagens Imperativas
Para ser entregue no dia 10/03/2011 até o meio-dia. Por e-mail para
Slide 76 de 81
Especificar de acordo com a UML Components:◦ Sites de compra coletiva tornaram-se muito populares no Brasil, a exemplo
do pioneiro Peixe Urbano. Estima-se que o número de sites que seguiram omesmo caminho já passa de mil [Fonte: Info Exame - http://goo.gl/gfbG5].Partindo do princípio que muitos desses sites funcionam com base nasmesmas regras de negócio, apresente a especificação (em termos decomponentes) de um framework fundamentando-se nos princípios de DBCapresentados em nesta aula para servir de apoio na criação de sites decompra coletiva. Ao final da atividade espera-se o seguinte conjunto deartefatos: Definição dos requisitos: Modelo conceitual do negócio;
Identificação dos casos de uso Especificação dos componentes Identificação: Diagrama de tipos de negócio com identificação dos
tipos <<core>>; Especificação dos componentes Iteração: Diagramas de Sequencia; Assinatura das operações Especificação: Modelo de informação da interfaces; Especificação
completa dos componentes; Contratos de uso e realização
Slide 77 de 81
Principaisreferências desta
aula
Slide 78 de 81
[Sametinger, 1997] Sametinger, J. "Software Engineering with Reusable Components", Springer- Verlag, 1997, pp.275.
[D’Souza and Wills, 1998] D’Souza, D. F. and Wills, A. C. "Objects, Components and Frameworks with UML: The Catalysis Approach", Addison-Wesley, 1998, pp. 816.
[Bachmann et al., 2000] Bachmann, F., Bass, L., Buhman, C., Buhman, C., Comella-Dorda, S., Long, F., Robert, J., Seacord, R. and Wallnau, K. "Volume II: Technical Concepts of Component-Based Software Engineering", Software Engineering Institute (SEI), Technical Report, May, 2000, pp. 65.
[Cheesman and Daniels, 2000] Cheesman, J. and Daniels, J. "UML Component A Simple Process for Specifying Component-Based Software, Addison-Wesley, 2000, pp. 208.
[Council and Heineman, 2001] Councill, B. and Heineman, G. T. "Definition of a Software Component and its Elements", in G. T. Heineman, W. T. Councill, Component-Based Software Engineering, Addison-Wesley, 2001, pp. 818.
[Heineman and Councill, 2001] Heineman, G. T. and Councill, B. "Component-Based Software Engineering", Addison-Wesley, 2001, pp. 818.
[Williams, 2001] Williams, J. "The Business Case for Components" in G. T. Heineman, W. T. Councill, Component-Based Software Engineering, Addison-Wesley, 2001, pp. 818.
[Weinreich, 2001] Weinreich, R. and Sametinger, J. "Component Models and Component Services: Concepts and Principles" in G. T. Heineman, W. T. Councill, Component-Based Software Engineering, Addison-Wesley, 2001, pp. 818.
[Szyperski, 2002] Szyperski, C. "Component Software: Beyond Object-Oriented Programming", Addison-Wesley, 2002, pp. 588.
Slide 79 de 81
[PECOS, 2005] Pervasive Component Systems - PECOS Project. Disponível em http://www.pecos-project.org/, Junho 2005.
[Almeida et al., 2005] E. S. Almeida, A. Alvaro, D. Lucredio, V. C. Garcia, S. R. L. Meira, A Survey on Software Reuse Processes, IEEE International Conference on Information Reuse and Integration (IRI), Las Vegas, Nevada, USA, 2005.
[Traas & Hillegersberg, 2000] Traas, V.; Hillegersberg, J. V. The software component market on the internet current status and conditions for growth. In: ACM SIGSOFT Software Engineering Notes, Vol. 25 No. 1, January, 2000.
[Neighbors, 1980] J. M. Neighbors, Software Construction Using Components, PhD Thesis, University of California, Irvine, Department of Information and Computer Science, USA, April, 1980, pp.217.
[Simos et al., 1996] M. Simos, D. Creps, C. Klingler, L. Levine, D. Allemang, Organization Domain Modeling (ODM) Guidebook, Version 2.0, Technical Report, June, 1996, pp. 509.
[Jacobson et al., 1997] I. Jacobson, M. L. Griss, P. Jonsson, Making the Reuse Business Work, IEEE Computer, Vol. 30, No. 10, October, 1997, pp. 36-42.
[Kang et al., 1998] K. C. Kang, S. Kim, J. Lee, K. Kim, E. Shin, M. Huh, FORM: A Feature-Oriented Reuse Method with domain-specific reference architectures, Annals of Software Engineering Notes, Vol. 05, No. 00, Janeiro, 1998, pp. 143-168.
[Villela, 2000] R. M. M. B. Villela, Search and Recovery of Components in Software Reuse Environments (in portuguese), Ph.D. Thesis, Federal University of Rio de Janeiro, December, 2000, pp. 264.
Slide 80 de 81
[Kang et al., 1990] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, A. S. Peterson, Feature-Oriented Domain Analysis (FODA) Feasibility Study, Software Engineering Institute (SEI), Technical Report, November, 1990, pp. 161.
[Clements & Northrop, 2001] P. Clements, L. Northrop, Software Product Lines: Practices and Patterns, Addison-Wesley, 2001, pp. 608.
[Pasetti & Pree, 2000] A. Pasetti, W. Pree, Two Novel Concepts for Systematic Product Line Development, Software Product Line Conference (SPLC), Denver, Colorado, USA, August, 2000, pp. 249-270.
[Rombach, 2000] D. Rombach, Fraunhofer: The German Model for Applied Research and Technology Transfer, 22nd International Conference on Software Engineering [ICSE], Limerick, Ireland, May, 2000, pp. 25-34.
[Batory & O’Malley, 1992] D. Batory, S. O’Malley, The Design and Implementation of Hierarchical Software Systems with Reusable Components, ACM TOSEM, October, 1992.
[Batory et al., 2000] D. S. Batory, R. Cardone, Y. Smaragdakis, Object-oriented frameworks and product lines, Software Product Line Conference (SPLC), Denver, Colorado, USA, August, 2000, pp. 227-248.
[Bayer et al., 1999] J. Bayer, O. Flege, P. Knauber, R. Laqua, D. Muthig, K. Schmid, T. Widen, J. DeBaud, PuLSE: A Methodology to Develop Software Product Lines, Symposium on Software Reusability (SSR), Los Angeles, USA, May, 1999, pp. 122-131.
[Weiss & Lai, 1999] D. M. Weiss, C. T. R. Lai, Software Product-Line Engineering: A Family-Based Software Development Process, Addison-Wesley, 1999, pp. 426.
[Atkinson et al., 2000] C. Atkinson, J. Bayer, D. Muthig, Component-Based Product Line Development: The KobrA Approach, First Software Product Line Conference [SPLC], Kluwer International Series in Software Engineering and Computer Science, Denver, Colorado, USA, August, 2000, pp.19.
Slide 81 de 81
[America et al., 2000] P. America, H. Obbink, R. V. Ommering, F. V. D. Linden, CoPAM: A Component-Oriented Platform Architecting Method Family for ProductFamily Engineering, First Software Product Line Conference (SPLC), KluwerInternational Series in Software Engineering and Computer Science, Denver, Colorado, USA, August, 2000, pp. 15.
[Kang et al., 2002] K. C. Kang, J. Lee, P. Donohoe, Feature-Oriented Product LineEngineering, IEEE Software, Vol. 19, No. 04, July/August, 2002, pp.58-65.
[Gomaa, 2005] H. Gomaa, Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures, Addison-Wesley, 2005, pp. 701.