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

Email

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