Post on 20-Nov-2018
RiSE – Reuse in Software Engineering Labs http://riselabs.dcc.ufba.br
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 2
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 3
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 and Eisenecker, 2000]
Análise de Domínio ◦ Identificação das características que são comuns e das que são variáveis
para aplicações de um domínio específico. ◦ É representado por feature, que é definida como uma característica de um
sistema que é relevante e visível para o usuário final [Kang et al., 1990] ◦ Fases da análise de domínio – RiDE Process (Almeida, 2007)
Planejar domínio Modelar domínio Validar domínio
Tipos de features ◦ Mandatórias ◦ Opcionais ◦ Alternativas ◦ Or
Dependências ◦ Implicação ◦ Exclusão
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 4
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 5
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
Atividades ◦ Abstrair ◦ Modelar ◦ Prototipar ◦ Validar
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 6
Relacionamento entre o sub-processo Projetar Domínio e os demais sub-processos
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 7
[Pohl et al., 2005]
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 8
A atividade mais importante no desenvolvimento de um sistema é construir a arquitetura ◦ Determina a estrutura do software e as regras a serem aplicadas
Atividades do arquiteto ◦ Abstração
Reduzir a complexidade ◦ Modelagem
Reasoning ◦ Simulação
Execução de “modelos” para medir aspectos específicos do sistema ◦ Prototipação
Parcial [fast] implementação ◦ Validação
Aplicação das regras arquiteturais
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 9
Requisitos de qualidade guiam a arquitetura Qualidade do desenvolvimento Avaliação da arquitetura ◦ Meio de avaliar a arquitetura de acordo com atributos de
qualidade pré-selecionados Alguns requisitos de qualidade só surgem a
partir da SPLE ◦ 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)
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 10
Priorização dos Requisitos Mapeamento entre Requisitos e Projeto Interação dos requisitos Requisitos de linhas de produtos como flexibilidade e adaptabilidade Preparação para o futuro
Frameworks de componentes
Padrões Programação
Orientada a Aspectos
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 11
[Pohl et al., 2005]
Adicionando variabilidade no projeto ◦ Variabilidade interna
Pontos de variação ◦ Tecnologias futuras ◦ Requisitos instáveis ◦ Independência de provedores
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 12
[Pohl et al., 2005]
Features Alternativas ◦ Abstract Factory e Singleton ◦ Factory Method ◦ Strategy ◦ Template Method
OR features ◦ Builder ◦ Decorator ◦ Observer
Sugestão de leitura ◦ [Almeida et al. 2007] Designing Domain-Specific Software Architecture
WICSA ◦ [Keepence and Mannion, 1999] Using Patterns to Model Variability in
Product Families ◦ [Coplien et al., 1998] Commonality and Variability in Software Engineering
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 13
OR Features ◦ Builder ◦ Decorator ◦ Observer
Exemplos
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 14
Or features Builder
Chain of responsability
Or features
EXEMPLOS
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 15
Optional Strategy
A arquitetura de referência é um grande número de componentes interconectados por meio das interfaces
Uso de Framework de componentes restringe o número de configurações de componentes ◦ Configurações ◦ Componentes e interfaces
Conectam-se a uma estrutura comum Componentes plug-in ◦ Frameworks externos
Infra-estrutura, funcionalidades básicas
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 16
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 17
[Pohl et al., 2005]
Uso de componentes [plug-in] específicos da aplicação ◦ A arquitetura de referência determina quais assets reutilizáveis existem na
linha de produtos
Uso de aspectos ◦ Cross-cutting concerns ◦ Manutenibilidade
Regras da estrutura arquitetural ◦ Regras de codificação ◦ Estilos ◦ Design patterns ◦ Frameworks
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 18
Validação da arquitetura da aplicação ◦ Consistência com a arquitetura de referência [estrutura]
Validação dos assets do domínio [Pohl et al., 2005] ◦ Do interfaces carry the right functionality to the right level
of abstraction? ◦ Are components and interfaces produced according to
context? ◦ Does each component carry all its interfaces, and no more? ◦ Do components call only the required interfaces, and all of
them?
Testes de integração
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 19
Um software é composto por múltiplas estruturas
Unidades de código, sua decomposição e dependências
Processos e como eles se relacionam Como o software é implantado ...
Visões são representações de estruturas
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 20
A view is a representation of a set of system elements and the relations associated with them
Não de todos os elementos, mas de parte deles
Uma visão restringe os tipos de elementos e os tipos de relações a serem representadas naquela visão
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 21
Um arquiteto deve considerar pelo menos 4
Como as unidades de código estão estruturadas? ◦ Visão dos módulos
Como os elementos de tempo de execução estão estrturados? ◦ Visão de runtime
Como os artefatos estão organizados no arquivo de instalação do sistema e como o sistema é implantado? ◦ Visão de Implantação
Qual a estrutura do repositório de dados? ◦ Modelo de Dados
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 22
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 23
http://www.rise.com.br/eventos/wire2008/arquivos/08.DSA-Tutorial_-_Paulo_Merson_WIRE-2008.pdf
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 24
http://www.rise.com.br/eventos/wire2008/arquivos/08.DSA-Tutorial_-_Paulo_Merson_WIRE-2008.pdf
Arquitetura de referência Customização em massa Partes reutilizáveis Em especificação ◦ Arquitetura de referência pode estar em
especificação [variantes] Variabilidade Estrutura ◦ Aspectos comuns presentes em todas as aplicações
Qualidade ◦ Evolução, flexibilidade e manutenibilidade
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 25
PLUS PROCESS [Gomaa, 2005]
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 26
Inputs ◦ Casos de uso ◦ Modelo de features (do domínio) ◦ Padrões arquiteturais (estrutura, comunicação, etc)
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 27
GOMAA, Hassan. Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures, Addison Wesley, pp. 736, 2004.
Separation of Concerns in Component Design ◦ Tornar os componentes auto-contidos, de forma que os conceitos sejam
suportados por componentes diferentes
Aggregate and Composite Subsystems ◦ Agrupar os componentes com funcionalidades similares ◦ Encapsular componentes internos, não adicionando novas funcionalidades
Component Structuring Criteria ◦ Guidelines de como estruturar uma aplicação em componentes
configuráveis
Design of Component Interfaces ◦ Definir as interfaces providas e requeridas
Design of Components ◦ Identificar tipo do componente: composite, plug-in e variáveis.
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 28
RiDE PROCESS [Almeida, 2007]
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 29
ALMEIDA, Eduardo Santana de et al. A Systematic Approach to Design Domain-Specific Software Architectures, Journal of Software, 2(2):38-51, Academy Publisher, August 2007.
Almeida , E. S. RiDE: The RiSE Process for Domain Engineering, Ph.D. Thesis, Federal University of Pernambuco, Recife, Pernambuco, Brazil, May, 2007.
DP1. Separation of Concerns and information hiding
DP2. Paramerization DP3. Components isolated rom the conncetion
mechanism DP4. Consistency DP5. Metrics DP6. Commonality and Variability DP7. Traceability DP8. Systematic sequence of activities
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 30
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 31
Escolher o módulo a ser decomposto ◦ Inicialmente, todas as aplicações...
Refinar o(s) módulo(s) de acordo com: ◦ Escolher os guias arquiteturais
Requisitos, features, cenários (se aplicável) ◦ Escolher o padrão arquitetural (se aplicável) ◦ Alocar as funcionalidades usando visões
GRASP Casos de Uso Features
Representar as variabilidades
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 32
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 33
Agrupar Componentes ◦ Aferir dependência funcional ◦ “Clusterizar” Casos de Uso ◦ Selecionar Componentes Candidatos ◦ Alocar Classes a Componentes
Identificar Componente
Especificar Componente ◦ Identificar Interfaces ◦ Identificar “Core Classes” ◦ Refinar a Especificação
Representar a Arquitetura do Domínio
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 34
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 35
[Gacek e Anastasopoules, 2001] e [Jacobson et al., 1997] ◦ linguagem de programação ◦ Documentação bem definida dos artefatos
Técnicas de implementação [Gacek e Anastasopoules, 2001] ◦ Agregação/Delegação
Objetos deleguem funcionalidades Funcionalidade obrigatória no objeto que delega e variante no
objeto delegado Adequada para Features opcionais mas não recomendadas para
features alternativas Alto número de variantes -> alto número de objetos
Delegações combinadas
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 36
Técnicas de implementação [Gacek e Anastasopoules, 2001] ◦ Herança Funções básicas e especializadas as classes
◦ Parametrização Biblioteca de componentes parametrizados Comportamento determinado pelos parâmetros Replicação do código
Centralização de decisões de projeto Melhora a reutilização e rastreamento de decisões de
projeto
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 37
Técnicas de implementação [Gacek e Anastasopoules, 2001] ◦ Sobrecarga (Overloading) O mesmo nome de um elemento pode operar de
maneiras diferentes Em tempo de execução ◦ Carga dinâmica de Classe Classes carregadas na memória Interessante para SPL
Produto pode pesquisar seu contexto e decidir em tempo de execução qual classe carregar
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 38
Técnicas de implementação [Gacek e Anastasopoules, 2001] ◦ Compilação condicional
Controle sobre os segmentos de código Diretivas marcam locais de variação Encapsulamento de múltiplas implementações
Selecionada pela definição dos símbolos condicionais Compilação condicional conseguida antes do tempo de compilação
◦ Reflexão Manipular, na forma de dados, logo que representa o estado do
programa Meta-programação
Objetos em alto nível de abstração representam entidades Sistemas Operacionais e Linguagens de programação
◦ Padrões de Projeto Podem variar e fornecer soluções para o gerenciamento de
variabilidades
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 39
Técnicas de implementação [Gacek e Anastasopoules, 2001] ◦ Orientação a aspectos
Técnica desenvolvida na XEROX PARC e permite a modularização de crosscutting concerns, bem como a integração de pontos de junção
O processo de integrar pontos de junção envolve descrever como os crosscutting concerns afetam o código em um ou mais pontos de junção
Resolução de variabilidade em tempo de compilação (weaving)
AspectJ é uma extensão orientada a aspectos de Java que permite que aspetos sejam reutilizados de forma hierárquica em termos de aspectos abstratos
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 40
Frameworks OO ◦ Representam uma técnica comum para implementar
arquiteturas de família de sistemas e linha de produtos
◦ Cada framework OO define um conjunto de classes (concretas e abstratas) que colaboram entre si para implementar uma arquitetura para um dado domínio
◦ Cada framework possui: Uma parte fixa (frozen-spots) – conjunto de classes que
definem como as classes colaboram Uma parte variável (hot-spots): conjunto de classes/
interfaces abstratas que precisam ser estendidas para implementar o comportamento específico do framework
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 41
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 42
Framework OO
Hot Spots
Hot Spot Instances
Frozen Spots
Legenda:
Classe
Classe Abstrata ou Interface
Escopo ◦ FWs de infra-estrutura Simplificam o desenvolvimento de aplicações
Hibernate, Struts, Java Communication and Threads APIs...
◦ FWs de Integração/Middleware Usados para integrar aplicações distribuídas
CORBA, RMI, EJB
◦ FWs e aplicação Usados para construir aplicações de um domínio/
negócio específico
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 43
Técnica de Extensão ◦ Caixa-branca Usuário deve estender classes/interfaces abstratas
para criar uma instância do mesmo (ex. JUnit) ◦ Caixa-preta Instâncias dos pontos flexíveis (hot-spots) já estão
dispoíveis e o usuário deve apenas usar um script de configuração ou uma DSL para escolher as instências desejadas
◦ Caixa-cinza Mistura as duas técnicas anteriores (ex. Eclipse)
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 44
Frameworks e Padrões de projeto ◦ Padrões de projeto são mais abstratos que um
framework ◦ Padrões de projeto podem ser, em geral, adaptados a
diferentes domínios de aplicação. Enquanto que frameworks definem uma arquitetura específica para um dado domínio ◦ Padrões de projeto representam micro-arquiteturas para
resolução de um dado problema de projeto de software O projeto e implementação de frameworks contém, em
geral, vários padrões de projetos Sobretudo os pontos flexíveis do framework contém vários
padrões de projeto (Strategy, Abstract Factory, Adapter, Decorator, Oberver, Proxy, State, etc)
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 45
Exemplos ◦ Junit ◦ Java Swing, Threads, Applets ◦ Struts, Hibernate, JPA ◦ Eclipse Workbench ◦ Enterprise Java Beans
◦ Outros exemplos?
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 46
Geradores de código são utilizados para melhorar a produtividade e qualidade de linhas de desenvolvimento de empresas
O quê gerar? ◦ Código repetitivo que recorrentemente é reusado,
“reaproveitado” (copy/paste) pelos desenvolvedores ◦ Componentes que precisam ser customizados de
acordo com as especificidades de cada aplicação
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 47
Geração de código sempre parte de uma especificação de mais alto nível
Dados específicos da aplicação são capturados/recolhidos por meio de: ◦ Modelos/Diagramas ◦ Wizards ◦ Diálogos ◦ Linguagens textuais (SQL)
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 48
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 49
Templates
DSLs (Wizards, Feature Models,
etc)
Arquitetura de referência (classes,
arquivos de configuração, etc)
Templates descrevem a estrutura e comportamento do código (ou arquivo) a ser gerado
Várias tecnologias disponíveis ◦ Velocity ◦ XSLT ◦ JET/EMF; ◦ xPand/oAW;
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 50
Geradores de CRUD ◦ Geradores de código-fonte completo para operações de
cadastro CRUD ◦ Geração é feita a partir de uma arquitetura de referência
implementada com classes/componentes comuns + templates ◦ Cada template contém:
Código comum na linguagem de programação usada Código variável a ser customizado a partir de informações
do usuário (nomes e atributos de entidades) Vários geradores disponíveis na internet ◦ Appfuse, AndroMDA, Grails, Groovy ◦ www.codegeneration.net
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 51
JSF + Spring + Hibernate Struts 2 + Spring + Hibernate Spring MVC + Spring + Hibernate Tapestry + Spring + Hibernate
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 52
Model Driven Architecture (MDA) Models from UML tools will be transformed into deployable components for your
favorite platform ◦ Spring ◦ EJB 2 / 3 ◦ Webservices ◦ Hibernate ◦ Struts ◦ JSF ◦ Java ◦ XSD
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 53
Definição de uma Arquitetura de Referência ◦ A partir da experiência de vários projetos, uma arquitetura
de referência é definida ◦ São identificados
Elementos comuns Classes existentes em cada camada (actions, services, daos,
entidades, etc) Classes de serviço de apoio a cada camada (gerência de transações,
gerência de sessões, pacote util) Elementos variáveis
Componentes, classes ou parte específica deles cuja a implementação varia de uma aplicação para outra
Em seguida, a arquitetura de referência deve usar alguma tecnologia para geração dos elementos variáveis ◦ Tecnologia de templates, em geral, é utilizada
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 54
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 55
GUI
Negócio
[Entidade]StrutsAction
[Entidade]ServiceImpl
IFachada[Sistema]
[Entidade]
Dados [Entidade]DAOHibernate
I[Entidade]DAO
FrontEndServlet [Entidade].jsp
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 56
GUI
Negócio
AlunoStrutsAction ProfessorStrutsAction
AlunoServiceImpl ProfessorServiceImpl
IAlunoService
Aluno Professor
Dados AlunoDAOHibernate ProfessorDAOHibernate
IAlunoDAO IProfessorDAO
FrontEndServlet Aluno.jsp Professor.jsp
IProfessorService
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 57
GUI
Negócio
ContribuinteStrutsAction ImpostoStrutsAction
Contribuinte ServiceImpl
Imposto ServiceImpl
IContribuinteService
Contribuinte Imposto
Dados ContribuinteDAOHibernate ImpostoDAOHibernate
IContribuinteDAO IImpostoDAO
FrontEndServlet Contribuinte.jsp Imposto.jsp
IImpostoService
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 58
<%@ jet package="translated" imports="java.util.* org.cesar.sistemaacademico.util.*“ class="EntityClass" %> <% Hashtable model = (Hashtable) argument;%> <% Entity entity = (Entity) model.get("Entity");%> package business;
/** * Classe: <%=entity.getName()%> * */ public class <%=entity.getName()%> {
<% Attribute attributes[] = entity.getAttribute(); for (int i=0;i < attributes.length; ++i){ Attribute attribute = attributes[i]; %> <%=attribute.getType()%> <%=attribute.getName().toLowerCase()%>;
<% } %> }
Compilação condicional ◦ Controle sobre os segmentos de código ◦ Diretivas marcam locais de variação ◦ Encapsulamento de múltiplas implementações Selecionada pela definição dos símbolos condicionais Compilação condicional conseguida antes do tempo de
compilação
Bastante usado na implementação de jogos para celulares ◦ Exemplo: Meantime
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 59
Cada jogo é representado por um arquivo de propriedades que contém as features/funcionalidades que devem ser incluídas naquele aparelho.
A partir de um arquivo de propriedade específico, um pré-processador inclui aqueles comandos que possuem diretivas #ifdef# relacionados as features/ funcionalidades presentes no jogo sendo gerado
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 60
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 61
BUILD
ARQUITETURA DE LINHA DE PRODUTO
FRAMEWORK CORE DO JOGO
VARIAÇÕES (COMPILAÇÃ
O CONDICIONAL)
DIFERENTES PRODUTOS
ESCOLHA DE FEATURES
(DSLS, XML, ETC)
Jogo Rain of Fire / Meantime Framework Core ◦ Conjunto de classes que definem a 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 implementadas (dependem de recursos disponíveis – memória, poder de processamento ou do dispositivo em questão) ◦ Imagens decorativas opcionais ◦ Carga de imagens por demanda ou na inicialização ◦ API de Manipulação de Imagens proprietária de
diferentes dispositivos
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 62
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 63
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); } } ... }
Limitações da Orientação a Objetos ◦ Incapacidade de modularizar certos interesses
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 64
• linhas de código relevantes para a implementação do interesse Gerenciamento de Threads
• linhas de código relevantes para a implementação do interesse Logging
(c) Copyright 1998-2002 Xerox Corporation
Separação avançada de interesses ◦ Modularização dos Interesses Transversais ◦ Nova abstração: aspecto ◦ Novas formas de composição e decomposição
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 65
Classes
Interesse Transversal
Classes
Aspecto
Linguagem de programação orientada a aspectos de propósito geral
Extensão de Java Faz parte do projeto oficial do Eclipse ◦ AJDT – AspectJ para Eclipse www.eclipse.org/ajdt www.eclipse.org/aspectj www.aosd.net
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 66
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 67
Pointcut
Advice
Pontos de Junção
Método
Aspectos estão sendo explorados como tecnologia de implementação de arquiteturas de SPL para implementar variabilidades opcionais de integração existentes em: ◦ Software para celulares: tecnologia alternativa à
compilação condicional (menos invasiva, mais fácil de gerenciar o código) ◦ Middleware: permitindo a customização das
funcionalidades do middleware para diferentes usuários
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 68
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 69
BUILD
ARQUITETURA DE LINHA DE PRODUTO FRAMEWORK
CORE DO JOGO
ASPECTOS
DIFERENTES PRODUTOS
ESCOLHA DE FEATURES
(DSLS, XML, ETC)
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 70
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); } ... }
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 71
Objetivo ◦ Produzir a arquitetura da aplicação Especialização da arquitetura de referência
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 72
[Pohl et al., 2005]
Especialização da arquitetura de referência Abstrações específicas da abstração ◦ Requisitos de qualidade da aplicação ◦ Features não providas pela SPL
Modelos específicos da aplicação ◦ Comportamento específico ◦ Requisitos de qualidade específicos
Simulação e prototipação
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 73
Binding das variações ◦ A forma como a customização em massa é incorporada; ◦ Abstrações utilizadas; ◦ Rastreabilidade entre as variabilidades e a arquitetura de
referência Reuso dos artefatos do domínio Projetar artefatos para as novas variações Avaliar o esforço adicional Determinar a configuração propícia ◦ A configuração dos componentes é o resultado do binding
dos pontos de variação com as variabilidades selecionadas Seleção consistente de variantes de componentes ◦ Impacto global das variantes ◦ Configuração específica de hardware
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 74
Aplicação como base de teste para o domínio ◦ Possibilidade de integração de artefatos da
aplicação ◦ O gerente do produto decide sobre a integração de
novos artefatos Substituição de artefatos não-reutilizáveis
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 75
Custo da realização Fatores de custo ◦ Número de novos componentes a serem realizados ◦ Número de interfaces a serem realizadas ◦ Números de pequenas adaptações de componentes e interfaces ◦ Realização de simulações ◦ Adaptações para aspectos entre-cortantes [cross-cutting aspects] ◦ Testes a serem realizados em componentes e configurações
reutilizáveis ◦ Testes a serem realizados em novos componentes
Estimativa de custos ◦ Padrões para se aplicar ◦ Novos projetos -> alto custo
Amortização de custos para features reutilizáveis
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 76
Reuso da arquitetura de referência Rastreabilidade dos requisitos Regras comuns da estrutura Esforço reduzido
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 77
Considerando o modelo de features, requisitos e casos de uso, projete a arquitetura para o domínio de jogos arcade de atirador fixo que apresente os pontos de variação especificados anteriormente.
Utilize os recursos apresentados em sala, especificando e justificando a sua escolha. ◦ Arquitetura de referência do Domínio (Sugestão: usar a proposta de Paulo Merson -
link para os slides anteiormente- para documentação)
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 78
SPL ◦ [Almeida et al., 2007] Almeida, E. S., Alvaro, A.,
Garcia, V. C., Burégio, V. A. A., Mascena, J. C. C. P., Marques, L. N., Lucrédio, D., Meira, S. R. L. “C.R.U.I.S.E: Component Reuse in Software Engineering", C.E.S.A.R book, 2007, pp. 219. ◦ [Clements and Northrop, 2001] Clements, P. and
Northrop, L. “Software Product Lines : Practices and Patterns”, Addison-Wesley, 2001, pp. 608. ◦ [Pohl et al., 2005] Pohl, K. Bockle, G., Van Der
Linden, F. “Software Product Line Engineering”, Springer-Verlag New York Inc, 2005, pp. 467.
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 79
MODEL-DRIVEN DEVELOPMENT, CODE GENERATORS ◦ [Czarnecki and Eisenecker, 2000] Czarnecki, K., Eisenecker, U.: “Generative
Programming: Methods, Tools, and Applications”, Addison-Wesley, 2000. ◦ [Greenfield and Short, 2005] Greenfield, J., Short, K.: “Software Factories:
Assembling Applications with Patterns, Frameworks, Models and Tools”, John Wiley and Sons, 2005.
◦ [Stahl and Voelter, 2006] Stahl, T., Voelter, M.: “Model-Driven Software Development: Technology, Engineering, Management”, Wiley, 2006.
FRAMEWORKS ◦ [Fayad, et al 1999] FAYAD, M.; SCHMIDT, D.; and JOHNSON, R. Building
Application Frameworks: Object-Oriented Foundations of Framework Design. 1999: John Wiley & Sons.
◦ [Roberts et al., 1998] Roberts, D., Johnson, R.: “Evolving Frameworks: A Pattern Language for Developing Object-Oriented Frameworks” In Martin, R., Riehle, D., Buschmann, F.: “Pattern Languages of Program Design", Addison-Wesley, 3, 471-486, 1998.
◦ [Shavor 2003, et al] Shavor, S., D’Anjou, J., Fairbrother, S., Kehn D., Kellerman, K., McCarthy, P.: “The Java Developer’s Guide to Eclipse” Addison-Wesley, 2003.
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 80
ECLIPSE ◦ [Shavor 2003, et al] Shavor, S., D’Anjou, J., Fairbrother, S.,
Kehn D., Kellerman, K., McCarthy, P.: “The Java Developer’s Guide to Eclipse” Addison-Wesley, 2003.
ASPECT-ORIENTED SOFTWARE DEVELOPMENT ◦ [Filman 2003, et al] Filman, R., Elrad, T., Clarke, S., Aksit,
M. Aspect-Oriented Software Development. Addison-Wesley, 2005. ◦ [Laddad, R. 2003] “Aspectj in Action: Practical Aspect-
Oriented Programming”. Manning Publications. ◦ [Colyer 2004] Colyer, A., Clement, A. Eclipse Aspectj:
Aspect-Oriented Programming with Aspectj and the Eclipse Aspectj Development Tools. Addison-Wesley. ◦ [Johnson 2005, et al] Johnson, R., Hoeller, J., Arendsen, A.,
Risberg, T., Sampaleanu, C.: “Professional Java Development with the Spring Framework”, Wrox, 2005.
Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 81