Frameworks Orientados a Objetos. Agenda Crash Course! Um problema Conceitos Classificação...
Transcript of Frameworks Orientados a Objetos. Agenda Crash Course! Um problema Conceitos Classificação...
Frameworks Orientados a Objetos
Agenda Crash Course!
Um problema
Conceitos
Classificação
Framework vs Outras Abordagens
Processo de desenvolvimento
Documentação/Instanciação
Trade-offs
Exemplos de Frameworks
Conclusão
2010Frameworks2
Crash Course!! Lápis...
....Ou Lapiseira?
2010Frameworks3
Fácil de Idealizar/Construir
Útil Pouco Flexível Necessita de outras
“ferramentas” Apontador!
Difícil de Idealizar/Construir
Útil, mas precisa de “manual”
Flexível Aceita vários tipos de
grafite Restrição
Diâmetro do Grafite!
Um problema Controle de qualidade
A B
TriggerEfetuador
Sensor
1
2 Líquidoopacidade
3
4
2010 Frameworks 4
Um problema(2) Empresa especializada em software para controle
de qualidade em manufaturas. Diminuir custos com o desenvolvimento de novos
sistemas. Mas muita coisa muda…
Sensores Câmeras, balanças, termômetros, etc…
Efetuadores Braço mecânico, rotulador, etc…
Critérios de qualidade variados Itens diferentes
2010Frameworks5
Um problema(3) Mas tudo muda?
A dinâmica do processo é sempre a mesma: Trigger Sensor Adaptações Algoritmos de
classificação do item Executar ação no efetuador.
2010Frameworks6
Uma Solução
Separar o que é fixo(frozen-spot) do que é variável(hot-spot).
Permitir a reutilização da parte fixa.
2010 Frameworks 7
Frameworks
Introdução
Motivação Reuso:
Reutilizar software não é simples A maioria dos esforços resultam na reutilização de pequenos
componentes.
Framework Orientado a Objeto é uma técnica de reuso
Provê reutilização de projeto e de código.
As principais vantagens do uso de frameworks incluem: diminuição do tempo para produção de uma família de aplicações.
2010Frameworks9
O que é um Framework? É uma aplicação “semi-acabada” que captura
os conceitos mais gerais de um domínio: Uma aplicação gerada a partir de framework
especializa ou estende os conceitos capturados pelo framework podendo ainda adicionar novos conceitos.
2010Frameworks10
Algumas definições
“Um framework é um conjunto de classes que constitui um design abstrato para soluções de uma família de problemas”
[Johnson e Foote – 1988] “Um framework é um conjunto de objetos que
colaboram para cumprir uma série de responsabilidades em uma aplicação ou em um domínio de um subsistema.”
[Johnson -1991]
2010Frameworks11
+ duas “Um framework é uma arquitetura desenvolvida
visando reutilizar ao máximo projeto e código. Este reuso se dá através da representação de um conjunto de classes abstratas e concretas, essas com grande potencial de especialização.”
[Mattsson – 1996] Uma framework é mais que uma hierarquia de
classes. É uma hierarquia de classes mais um modelo de interação entre os objetos instanciados a partir do framework.
[Lewis95]
2010Frameworks12
Por que reutilizar design?
A reutilização de código é um tanto restritiva, pois no processo de implementação de uma determinada abstração em uma linguagem de programação específica, as idéias originais (a abstração) são normalmente intercaladas e escondidas pelo idioma da linguagem utilizada. Isto não permite que todo ou parte do conhecimento adquirido durante o processo de desenvolvimento do artefato reutilizável seja reaproveitado em situações diversas.
2010Frameworks13
Reuso de Design Melhoria no entendimento do sistema em
geral, através do uso de uma representação de alto nível (próximo à abstração), não vinculada a um idioma (próximo à implementação).
Melhoria na captura de erros de projeto, uma vez que a reutilização é decidida em fases iniciais do desenvolvimento.
Induz à reutilização de código, uma vez que este design necessita de uma representação “executável” que comprove sua utilidade.
2010Frameworks14
Frameworks
Conceito Básico
Framework é composto por:
2010Frameworks16
Frozen spot Partes fixas do framework (kernel)
São partes de código já implementadas no framework que chamam um ou mais hot spots definidos em cada instância.
Templates de códido. Ex: Call Trigger Call Sensor Call Adaptações Call Algoritmos de classificação do item Call Executar ação no efetuador
2010Frameworks17
Hot spot Ou pontos de flexibilização
Pedaços do framework que são passíveis de customização e extensão
Os hot spots expressam aspectos do domínio do framework que não podem ser antecipados.
Os hot spots são descobertos na análise do domínio ou providos por um especialista no domínio da aplicação.
2010Frameworks18
Exemplo....
2010Frameworks19
Frameworks
Instanciação
Abstração
Um framework é uma abstração e não é executável. Para produzir uma
aplicação completa e executável deve-se instanciar o framework implementando código específico a aplicação para cada hot spot.
2010Frameworks21
Aplicação
Instanciação
Processo de preenchimento / adaptação dos pontos de flexibilização (hot-spots) de uma framework.
2010 Frameworks 22
Processo de Instanciação
Aplicação
Tempo
Requisitos Análise deDomínio
Intanciação/Design Testes
{Modelos da
Aplicação geramIncrementos da
Aplicação relativosao framework
Modelos DoFramework
Outros Incrementosda Aplicação
Design Final da Aplicação
Composição
Codificação
2010Frameworks23
Abordagens para Instanciação UML-F [Fontoura99]
Decoração para Diagramas de Classe UML
Cookbook [Krasner88] Especificação em Linguagem Natural semi-
estruturada
Hooks [Froelich96] Especificação em Linguagem Natural semi-
estruturada
2010Frameworks24
+ Instanciação RDL[Oliveira01]
Reuse Description Language Linguagem de prósito específico que descreve o
processo de instanciação de frameworks orientados a objetos.
ReuseTool[Oliveira10] (in the making :)) Máquina de Execução para RDL (em breve....)
2010Frameworks25
Exemplo
2010Frameworks26
Frameworks
Documentação
Documentação
• Documentação deve se adaptar a diferentes públicos, três exemplos são dados abaixo:
Neste caso deve-se descrever como o uso de framework foi planejado.
ESs que já decidiram usar o framework
Neste caso, a descrição deve ser mais elaborada, contendo os algoritmos abstratos e o modelo de colaboração.
ESs que desejam realizar algum tipo de manutenção no framework.
Neste caso uma breve descrição das capacidades é suficiente.
ESs que decidem qual framework utilizar.
Documentação Público
2010Frameworks28
Documentação Para atender a todo o tipo de público a
documentação deve ter diferentes níveis de abstração. O propósito do framework Como usar os fundamentos do framework O propósito das aplicações: exemplos O design do framework
2010Frameworks29
Documentação Propósito do framework
Breve descrição do propósito do framework O domínio do problema para o qual foi desenvolvido.
Como usar os fundamentos do framework Está é a mais importante documentação para garantir a reutilização do
framework. Deve-se descrever como utilizar o framework sem entrar em detalhes
sobre como ele funciona.
Propósito das aplicações: exemplos Exemplos concretos ajudam a entender melhor o framework.
Design do framework Deve conter as classes, seus relacionamentos e colaborações.
[Johnson92]
2010Frameworks30
Exemplo
2010Frameworks31
Nome: SimpleFigure Tool
Propósito do framework Apresentar o nome da Figura no console.
Como usar os fundamentos do framework Definir as figuras que serão utilizadas pela aplicação.
Propósito das aplicações: exemplos Slides anteriores.
Design do framework Slides anteriores e próximo slide.
[Johnson92]
Colaboração
2010Frameworks32
Frameworks
Processo de Desenvolvimento
Desenvolvimento de um Framework
Análise daaplicação Design Aplicação
Análise dodomínio
Frameworkdesign Aplicação 1
Aplicação 2
Aplicação n
................
Desenvolvimento tradicional orientado a objetos
Desenvolvimento de aplicações baseado em frameworks
2010Frameworks34
Processo de Desenvolvimento Processo baseado na experiência
Processo baseado na análise do domínio
Processo utilizando design patterns
Caso geral
2010Frameworks35
Processo de desenvolvimento baseado na experiência
Desenvolvimento daAplicação
Desenvolvimento doFramework
1. Elementos em Comum
2. Experiência
Inicio do desenvolvimento de n aplicações
1. Re - desenvolver as n aplicações usando o Framework
2. Desenvolver as aplicações n+1,n+2, ... usando o Framework
Atividade de manutenção usando a experiência
2010Frameworks36
Processo de desenvolvimento baseado na análise de domínio
Desenvolvimento daAplicação
Desenvolvimento doFramework
Análise do Domínio
1. Identificar abstrações eelementos em comum
2. Usar3. Experiência
4. Atividade de manutençãousando a experiência
2010Frameworks37
Processo de desenvolvimento utilizando design de patterns
Desenvolvimento daAplicação
Desenvolvimento doFramework
4. Atividade de manutenção
usando a experiência
2. Usar3. Experiência
Desenvolver a primeiraaplicação
Conjunto de Design Patterns
1. Aplicação sistemática
2010Frameworks38
Processo de desenvolvimento – Caso Geral
Testar o Frameworkdesenvolvendo de Aplicações
Desenvolvimento doFramework
3. Atividade de manutençãousando a experiência
1. Usar2. Erros e Experiência
Análise do domínio doproblema
2010Frameworks39
Cuidado!
Abstração 2
Escopo1
+ fácil utilizar
- abrangente
+ facil desenvolver
- fácil utilizar
+ abrangente
- fácil desenvolver
1 - Quantidade de classes envolvidas2 - Quantidade de pontos de extensão envolvidos
2010Frameworks40
Frameworks
Classificação
Quanto ao escopo
Infra-estrutura System infrastruture frameworks
Integração Middleware integration frameworks
Corporativos Enterprise application frameworks
[Fayad99]
2010Frameworks42
Infra-estrutura
Frameworks de infraestrutura simplificam o desenvolvimento de sistemas portáteis e eficientes como sistemas operacionais, comunicações e interface com o usuário. Em geral, são usados internamente como um
software da organização e não são vendidos para clientes diretamente.
2010Frameworks43
Integração São comumente utilizados para integrar
sistemas distribuídos permitindo a troca de dados entre sistemas heterogêneos. São projetados para aumentar a habilidade de
desenvolvimento de software de infra-estrutura para trabalharem similarmente em um ambiente distribuído.
Ex. Corba,DCOM, DSOM
2010Frameworks44
Corporativos Estes frameworks são direcionados para
amplos domínios de aplicação como telecomunicações, manufatura e finanças. Ex. SAP e seus milhares pontos de flexibilização.
2010Frameworks45
Quanto à técnica de extensão WhiteBox
BlackBox
GrayBox
2010Frameworks46
Whitebox Fortemente ligado às características de
linguagens OO: Herança e classes abstratas.
O reuso e a extensão das funcionalidades existentes são feitos através da criação de novas classes utilizando herança e implementação de métodos.
O usuário do framework deve entendê-lo muito bem para que possa criar uma instância.
2010Frameworks47
Exemplo: herança
A B
TriggerEfetuador
Sensor
1
2Cerveja
opacidade
3
4
Cervejaopacidade
Item
Frangopeso
2010Frameworks48
Blackbox
Instanciados a partir de scripts ou de algum tipo de configuração: XML Wizard Gráfico
Para produzir uma instância o usuário do framework não precisa entender detalhes internos apenas a interface.
Promovem menos flexibilidade que os frameworks do tipo whitebox.
2010Frameworks49
Componentes Frameworks com estas características
(blackbox) são comumente chamados de Componentes [Mattson2000].
2010Frameworks50
Graybox Criado para evitar as desvantagens presentes
nos frameworks whitebox e blackbox.
Permitem um certo grau de extensibilidade sem a necessidade de se expor informações internas. Frameworks visuais como o Borland VCL são exemplos, pois permitem instanciação a partir da ligação de componentes e ainda provêm parametrização via herança.
2010Frameworks51
Classificação de Frameworks por técnicas de extensão
2010 Frameworks 52
Instanciação
blackbox
whitebox
Conectando componentes já existentes:
• Reutiliza a interface do framework.
• Reutiliza regras para a conexão dos componentes.
Criando novas sub-classes concretas:
• Sub-classes são bem acopladas à super-classe
• É necessário ter um maior conhecimento das classes abstratas.
• Adicionando novas operações e variáveis.
2010Frameworks53
Instanciação WhiteBox
2010Frameworks54
Instanciação Blackbox
2010Frameworks55
Frameworks
Frameworks vs Outras Abordagens
Framework vs Outras Abordagens Abordagens de reutilização de software:
Design Pattern Biblioteca de classes Uma aplicação orientada a objeto Linhas de Produto de Software
2010Frameworks57
Design Pattern
Design patterns são mais abstratos do que um framework.
Frameworks estão sempre relacionados a um domínio de aplicação, enquanto patterns são mais genéricos e podem ser aplicados a vários domínios de aplicação.
Design patterns possuem uma arquitetura menor do que um framework. Um framework pode conter vários patterns, no entanto o
oposto não se aplica.2010Frameworks58
Biblioteca de classes
São um conjunto de classes relacionadas que tem funcionalidades de propósito geral. Suas classes não necessariamente estão relacionadas a
um domínio de aplicação específico, como no caso das classes de um framework.
A diferença é o grau de reutilização e o seu impacto na arquitetura da aplicação.
Uma classe em uma biblioteca é reutilizada sozinha, enquanto uma classe de um framework é reutilizada juntamente com as outras em uma instanciação.
2010Frameworks59
Hollywood Principle O fluxo de controle é inverso quando se
utiliza um Framework. “don't call us, we'll call you” call backs ou herança O framework é quem tem a thread principal de
execução Na utilização de bibliotecas, quem
controla as interações com o artefato reutilizável é o artefato reutilizador.
2010Frameworks60
Uma aplicação orientada a objeto
Aplicação: Descreve um programa executável completo
que atende a todos os requisitos de uma especificação.
Framework: Captura as funcionalidades de diversas
aplicações de um domínio. Não é executável:
Não cobre o comportamento de uma aplicação específica
2010Frameworks61
Linha de Produto de Software
LPS: É um conceito de marketing que relaciona
produtos afins com objetivo melhorar as vendas/lucros.
Framework: É um conceito de engenharia (de software) que
pode ser utilizado para apoiar uma LPS. Arquitetura de Referência.
2010Frameworks62
Frameworks
Trade–offs
Vantagens Modularidade
Reusabilidade
Extensibilidade
Inversão de Controle
Reuso de Design
2010Frameworks64
Modularidade
Frameworks melhoram a modularidade de um design através do encapsulamento de detalhes de implementação por trás de interfaces estáveis. Esta modularidade torna possível incrementar a qualidade do software, uma vez que os impactos causados por alterações de design e implementação são localizados, reduzindo o esforço necessário para o entendimento e manutenção do software existente.
2010Frameworks65
Reusabilidade As interfaces estáveis de um framework
incentivam reusabilidade uma vez que definem um componente genérico que pode ser re-aplicado para criar novas aplicações. Esta reusabilidade carrega o conhecimento em um domínio e o esforço prévio de desenvolvedores experientes, para evitar re-criação e re-validação de soluções comuns presentes em requisitos de aplicações recorrentes.
2010Frameworks66
Extensibilidade Frameworks aprimoram extensibilidade
através da definição de pontos de extensão que permitem a uma aplicação estender suas interfaces estáveis. Estes pontos de extensão permitem o desacoplamento sistemático da parte fixa do framework, presente no domínio da aplicação, da parte variável introduzida pelo processo de instanciação.
2010Frameworks67
Resumindo
pontos deflexibilização
Incremento da aplicação
Framework Aplicação
Parte oriunda doframework
Componentesmodulares
Organizaçãodas partes
1) Modilaridade - O usuário doframework só alltera os pontos deflexibilização.
2) Reuso - Grande parte do código/design da aplicação final vem doframework.
3) Extensibilidade - Pontos deflexibilização permitem acustomização do framework
2010Frameworks68
Inversão de Controle (WB) Uma novidade trazida pela reutilização de
frameworks é a possibilidade da inversão do fluxo de controle, isto é, quem comanda o fluxo de execução principal do programa é o artefato reutilizável e não o artefato reutilizador.
Este conceito permite que uma aplicação especifique seu funcionamento como um todo, principalmente no que se refere à coordenação de seus componentes principais. Em abordagens convencionais como as encontradas na reutilização de bibliotecas e componentes o artefato reutilizável é passivo, o que torna seu desenvolvimento muito mais complexo uma vez que o contexto em que este artefato será inserido é totalmente desconhecido pelo seu projetista.
2010Frameworks69
Inversão de Controle A inversão de controle está intimamente ligada
aos mecanismos de extensão presentes em linguagens orientadas a objetos nos quais frameworks se baseiam.
Estes mecanismos, como polimorfismo e late-binding, permitem que objetos “executem” um código a ser definido futuramente pelo desenvolvedor da aplicação, durante o processo de instanciação. Esta execução se dá através de um protocolo bem definido, normalmente especificado pelo mecanismo de herança. É esta inversão de controle que, em última análise, possibilita a criação dos esqueletos de aplicação mencionados por Johnson [Johnson88].
2010Frameworks70
Inversão de Controle
FrameworksArtefatoReutilizável
ArtefatoReutilizador
Bibliotecas
Aplicação Aplicação
ReusoPassivo
ReusoAtivo
2010Frameworks71
Reuso de Design
Frameworks oferecem reutilização de código e design o que facilita a transferência de conhecimento/experiência de alto nível ao reutilizador do framwork.
2010Frameworks72
Desvantagens Esforço de Desenvolvimento
Curva de Aprendizado
Integrabilidade
Manutenibilidade
Eficiência
2010Frameworks73
Esforço de Desenvolvimento Uma vez que o desenvolvimento de
sistemas complexos é difícil, o desenvolvimento destes sistemas de forma abstrata tendo em mente reutilização é ainda mais difícil. É necessário além de tempo, o auxílio de especialistas no domínio para o qual frameworks está sendo desenvolvido bem como uma boa dose de criatividade.
2010Frameworks74
Curva de Aprendizado Um problema comum no processo de reutilização
é o tempo necessário para se tornar capacitado para obter vantagens desta reutilização. Quando tratamos de frameworks isto não é diferente.
Foi constatado em [Fayad99a] que são necessários de 6 a 12 meses para um desenvolvedor se tornar produtivo na utilização de frameworks para interfaces gráficas como MFC [Mfc]. Sendo assim a menos que o custo de aprendizagem seja amortizado por vários projetos ou que o ganho de produtividade e qualidade sejam expressivos, este investimento não se tornará atraente.
2010Frameworks75
Integrabilidade A maioria dos frameworks são
desenvolvidos exclusivamente para o propósito de extensão e não integração com outros artefatos de software. Sendo assim problemas difíceis de serem solucionados, como, por exemplo, quem comanda do fluxo de controle da aplicação final, podem surgir e dificultar este processo de integração. Este tipo de problema é muito comum quando se tenta integrar frameworks[Mattsson00][Garlan96].
2010Frameworks76
Manutenibilidade Como todo artefato de software, seus
requisitos iniciais evoluem no tempo, obrigando a criação de novas versões do framework. Sendo assim, as aplicações instanciadas a partir de um dado framework também devem evoluir com a finalidade de se manterem de acordo com a especificação do framework. Entretanto, uma vez gerada, esta aplicação “perde” o vínculo com o framework.
2010Frameworks77
Eficiência Frameworks promovem extensibilidade
empregando níveis de indireção adicionais através de mecanismos como polimorfismo e late-binding, presentes em linguagens orientadas a objetos. Esta indireção usualmente provoca queda na eficiência do código final, uma vez que chamadas adicionais a tabelas virtuais de métodos serão necessárias para executar uma determinada tarefa.
Sistemas com restrições de tempo, como telecomunicações, precisam de ferramentas adicionais para gerar/transformar o código instanciado a partir do framework, de forma eficiente na plataforma alvo [Carvalho98].
2010Frameworks78
Exemplos de Framework Agenda
VMarket
Junit
JBOSS – Hibernate, Seam, JPDL
Eclipse – Pluggins
J2EE/ .NET2010Frameworks79
Agenda - Descrição Serviço de agenda eletrônica para a WWW
O serviço conta com as seguintes facilidades: cadastro do usuário registro em eventos da agenda
tarefas, compromissos, aniversários e programas de TV (disponibilizados futuramente).
eventos registrados podem possuir alarmes para lembrar ao usuário da sua ocorrência
alarmes meios de comunicação
Hotspots Canais de de comunicação tipos de eventos
2010Frameworks80
Agenda - Diag. de Classe do Framework
NewClass
Sistema
Usuário Evento
0..*1
Alarme
0..*1
Canal1..*
11 0..* 1 0..*
1
1..*
NewClass
Hotspot
2010Frameworks81
Agenda - Diag. Classe da Aplicação
CompromissoTarefa
Canal
Alarme
1
1..*
1
1..*
Evento
1 0..*1 0..*
Usuário
1 0..*1 0..*
Sistema
Aniversario
Celular
2010Frameworks82
VMarket - Descrição Framework para sistemas de comércio eletrônico voltados para
Mercados Virtuais mediados por Agentes de Software
Descrição do item
Agentes de compra
Agentes de venda
Negociação do item entre um agente de compra e um de venda
Hot-spots item estados do agente tipos de agentes estratégia de negociação
2010Frameworks83
VMarket - Descrição
INT
ER
FA
CE
MARKETPLACE SERVER
C om puter
W orksta tion
Laptop
PD A
Agente
Negócios são fechados dentro domarketplace através da intermediação de agentes
2010Frameworks84
VMarket - Item Exemplo em XML de uma descrição de item
2010Frameworks85
VMarket - Diag. de Classe
Hotspot
2010Frameworks86
JUnit JUnit is a testing framework written by Erich
Gamma and Kent Beck. It is used by the developer who implements unit tests in Java.
2010Frameworks87
JUnit Design
2010Frameworks88
JUnit – Como Utilizar http://junit.sourceforge.net/doc/testinfected/
testing.htm
2010Frameworks89