Frameworks
Projeto de Sistemas de Software
Sumário
• Motivação
• Definição
• Classificação
• Características
• Propriedades
• Técnicas de Customização
• Frameworks X Outras Abordagens
• Processos de Desenvolvimento
• Documentação
• Exemplos
• Vantagens e Desvantagens
© LES/PUC-Rio
2
Motivação
• “Reusar” software não é simples
• Maioria dos esforços resultam apenas reutilização de
pequenos componentes
• Principais vantagens do uso de frameworks
– Aumento do reuso
– Diminuição do tempo para produção de família de aplicações
• Framework provê reutilização de
– Design
– Código
• Reuso em larga escala
© LES/PUC-Rio
3
Definição
• Provê solução para uma família de problemas
semelhantes
• Usa conjunto de classes e interfaces que mostra como
decompor a família de problemas
• Como objetos dessas classes colaboram para cumprir suas
responsabilidades
• Conjunto de classes deve ser flexível e extensível
– Permite a construção de várias aplicações com pouco esforço
– Especifica-se apenas as particularidades de cada aplicação
© LES/PUC-Rio
4
Outras Definições
• “Um framework é um conjunto de classes que constituem
um design abstrato para soluções de uma família de
problemas.”
Johnson e Foote (1988)
• “Um framework é um conjunto de objetos que colaboram
com o objetivo de cumprir um conjunto de
responsabilidades para uma aplicação ou um domínio de um
subsistema.”
Johnson (1991)
• “Uma arquitetura desenvolvida com o objetivo de se obter a
máxima reutilização, representada como um conjunto de
classes abstratas e concretas, com grande potencial de
especialização.”
Mattsson (1996)
© LES/PUC-Rio
5
Classificação
• Frameworks da Infra-estrutura de Sistema
– Dão suporte ao desenvolvimento das infra-estruturas de
sistemas como
• Comunicações
• Interfaces com usuário
• Compiladores
• Frameworks de Integração com Middleware
– Padrões e classes que dão suporte à comunicação de
componentes e a troca de informação
• Frameworks de Aplicações Corporativas
– Suportam o desenvolvimento de tipos específicos de aplicação
como telecomunicações ou sistemas financeiros
– Relacionados com Família de Programas
© LES/PUC-Rio
6
Características
• Reusável
– Propósito final
– Para ser reusável, deve primeiro ser usável
• Bem documentado
• Fácil de usar
• Extensível
– Framework contém funcionalidade abstrata (sem
implementação) que deve ser completada
• Seguro
– Desenvolvedor de aplicações não pode destruir o framework
• Eficiente
– Devido a seu uso em muitas situações, algumas das quais
poderão necessitar de eficiência
© LES/PUC-Rio
7
Características
• Completo
– Para endereçar o domínio do problema pretendido
• Inversion-of-Control (IoC)
– Quem é responsável por chamar os objetos de uma instância
do framework?
– Princípio de Hollywood: “Don’t call us, we call you”
• Framework define o controle de fluxo
– Inversão do controle de fluxo, comparativamente às bibliotecas de
classes
• Framework comanda a resposta do sistema aos eventos externos
– Invocando operações definidas pelo programador
© LES/PUC-Rio
8
Características
• Inversion-of-Control (IoC)
© LES/PUC-Rio
9
Características
• Inversion-of-Control (IoC)
Biblioteca de Classes
Snot
Framework
usa
Bar
Foo
Snot
<<abstract>>
Foo
Bar
usa
CienteFoo
Ciente
CienteBar
© LES/PUC-Rio
10
Propriedades
• Núcleo do framework
– Conjunto de classes que juntas colaboram para implementar
uma arquitetura de família de sistemas
• Pontos de extensão
– Na forma de classes abstratas ou interfaces
• Controle de Fluxo da Aplicação
– Fluxo definido pelo comportamento das classes que
representam o seu núcleo
– Classes responsáveis por invocar classes que estendem os
pontos de extensão
© LES/PUC-Rio
11
Propriedades
Núcleo
Pontos de Extensão
© LES/PUC-Rio
12
Propriedades
• Hot Spots
– Pontos de Flexibilização
– Partes passíveis de customização e extensão
– Expressam aspectos do domínio do framework que não podem
ser antecipados
– Descobertos na análise do domínio
• Posteriormente instanciados por especialistas no domínio da
aplicação
• Frozen Spots
– Partes fixas (núcleo)
– Partes de código já implementadas
• Chamam um ou mais hot spots definidos em cada instância
© LES/PUC-Rio
13
Abstração
• Frameworks não são executáveis
• Para produzir uma aplicação completa e executável
– Instanciar o framework implementando código específico à aplicação
para cada hot spot
© LES/PUC-Rio
14
Técnicas de Customização
• Extensão de classes abstratas
• Implementação de interfaces
• Configuração/Composição de classes existentes
• Parametrização
© LES/PUC-Rio
15
Técnicas de Customização - Exemplo
Customização por Herança:
Implementação dos
Métodos Abstratos
© LES/PUC-Rio
16
Tipos
• Tipo varia de acordo com a abordagem utilizada para a
implementação dos Hot Spots
Por Herança
White-Box
Por Composição
Gray-Box
© LES/PUC-Rio
Black-Box
17
Tipos
• White Box
– Fortemente ligado às características das linguagens OO
• Herança e Classes Abstratas
– Instanciação através da criação de novas classes
• Utilização de herança e de implementação de métodos
– Requer bom entendimento do framework para criar uma
instância
– Padrões de projeto tipicamente usados
• Template Method e Abstract Factory
© LES/PUC-Rio
18
Tipos
• Black Box
– Instanciados a partir de scripts ou de algum tipo de
configuração
• XML
• Wizard Gráfico
– Fundamenta-se no mecanismo de composição
– Não requer entendimento de detalhes internos para produzir
uma instância
© LES/PUC-Rio
19
Tipos
• Gray Box
– Mix de customização por herança e por
composição/configuração
– Evita desvantagens presentes nos frameworks white-box e
black-box
– Bastante flexibilidade e extensibilidade
– Habilidade de esconder informações não necessárias para
desenvolvedores da aplicação
© LES/PUC-Rio
20
Tipos
© LES/PUC-Rio
21
Frameworks X Design Patterns
• Aparentemente, ambos consistem de classes, interfaces e
colaborações prontas
• Diferenças
– Design patterns mais abstratos do que frameworks
• Framework inclui código, design pattern não (apenas exemplo do uso de
pattern)
• Devido à presença de código, framework pode ser estudado a nível de
código, executado, e reusado diretamente
– Design patterns elementos arquiteturais menores do que frameworks
• Framework típico contém vários design patterns mas o contrário nunca
ocorre
• Exemplo: Design patterns são frequentemente usados para documentar
frameworks
– Design patterns menos especializados do que frameworks
• Frameworks sempre têm um domínio de aplicação particular enquanto design
patterns não ditam uma arquitetura de aplicação particular
© LES/PUC-Rio
22
Frameworks X Design Patterns
Design
Pattern
Framework B
Framework A
© LES/PUC-Rio
23
Frameworks X Biblioteca de Classes
• Bibliotecas
– Conjunto de classes relacionadas
• Funcionalidades de propósito geral
– Classes não relacionadas a um domínio de aplicação específica
• Em contrapartida às classes de um framework
• Diferença
– Grau de reutilização
– Impacto na arquitetura da aplicação
• Classe de uma biblioteca
– Reutilizada sozinha
• Classe de um framework
– Reutilizada juntamente com as outras em uma instanciação
© LES/PUC-Rio
24
Frameworks X Biblioteca de Classes
Biblioteca
Framework
•
Classes instanciadas pelo cliente
•
Customização com subclasse ou
composição
•
Cliente chama funções
•
Não tem fluxo de controle prédefinido
•
Chama funções da “aplicação”
•
Controla o fluxo de execução
•
Não tem interação pré-definida
•
Define interação entre objetos
•
Não tem comportamento default
•
Provê comportamento default
© LES/PUC-Rio
25
Desenvolvimento de Framework
Análise da
Aplicação
Design
Aplicação
Desenvolvimento tradicional orientado a objetos
Análise do
Domínio
Design do
Framework
Aplicação 1
Aplicação 2
...
Aplicação n
Desenvolvimento de aplicações baseado em frameworks
© LES/PUC-Rio
26
Processo de desenvolvimento
• Baseado na Experiência
Inicio do desenvolvimento
de n aplicações
Desenvolvimento
da Aplicação
1. Elementos em Comum
1. Re-desenvolver as n aplicações
usando o Framework
2. Experiência
2. Desenvolver as aplicações
n+1,n+2, ... usando o Framework
Desenvolvimento
do Framework
Atividade de manutenção
usando a experiência
© LES/PUC-Rio
27
Processo de desenvolvimento
• Baseado na Análise de Domínio
Desenvolvimento
da Aplicação
Análise do
Domínio
3. Experiência 2. Usar
1. Identificar abstrações e
elementos em comum
Desenvolvimento
do Framework
4. Atividade de manutenção
usando a experiência
© LES/PUC-Rio
28
Processo de desenvolvimento
• Caso Geral
Testar o Framework
desenvolvendo Aplicação
2. Erros e
Experiência
Análise do Domínio
do Problema
1. Usar
Desenvolvimento
do Framework
3. Atividade de manutenção
usando a experiência
© LES/PUC-Rio
29
Documentação
• Documentação deve se adaptar a diferentes públicos
– Exemplos
Público
Documentação
ES que decidem qual
framework utilizar
Neste caso uma breve descrição das
capacidades é suficiente
ES que já decidiram usar o
framework
Neste caso deve-se descrever como o
uso de framework foi planejado
ES que desejam realizar
algum tipo de manutenção
no framework
Neste caso, a descrição deve ser mais
elaborada, contendo os algoritmo
abstratos e o modelo de colaboração
© LES/PUC-Rio
30
Documentação
• Para atender a todo o público a documentação deve ter
diferentes níveis de abstração
– Propósito do framework
• Breve descrição do propósito do framework
• Domínio do problema para o qual foi desenvolvido
– Como usar os fundamentos do framework
• Mais importante documentação para garantir a reutilização do
framework
• Descrever como utilizar o framework
– Não entrar em detalhes sobre seu funcionamento
– 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
© LES/PUC-Rio
31
Exemplo 1 - Agenda
• Serviço de agenda eletrônica para a WWW
• Serviço possui 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 comunicação
– Tipos de eventos
© LES/PUC-Rio
32
Exemplo 1 - Agenda
Hot Spots
© LES/PUC-Rio
33
Exemplo 1 - Agenda
© LES/PUC-Rio
34
Exemplo 2 - VMarket
• 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
© LES/PUC-Rio
35
Exemplo 2 - VMarket
Workstation
INTERFACE
Laptop
MARKETPLACE
SERVER
Computer
Negócios são fechados dentro do
marketplace através da intermediação de agentes
Agente
PDA
© LES/PUC-Rio
36
Exemplo 2 - VMarket
• Exemplo em XML de uma descrição do Item
© LES/PUC-Rio
37
Exemplo 2 - VMarket
• Diagrama de Classes
Hotspot
© LES/PUC-Rio
38
Vantagens
• Com o framework pronto, benefícios
– Redução de custos
– Redução de time-to-market
• Motivos
– Maximização de re-uso (análise, design, código, testes)
• Reutilização de design feito por outros pode transferir
conhecimento e experiência para o usuário do framework
– Desenvolvedores adicionam valor em vez de reinventar a roda
– Menos manutenção
• Fatoração de aspectos comuns a várias aplicações
• Uso de herança permite corrigir todas as aplicações com a troca de
uma classe-mãe
– Cuidado com o "Fragile Base Class Problem” onde troca da classe-mãe
quebra as filhas
– Melhora do código (menos defeitos) devido ao uso em várias
aplicações
© LES/PUC-Rio
39
Vantagens
• Outras vantagens
– Diminuição de linhas de código na aplicação
– Melhor consistência e compatibilidade entre aplicações
– Conhecimento sobre o domínio da aplicação é mantido dentro
da organização
– Alavancagem do conhecimento de especialistas
• Framework oferece uma forma de empacotar o conhecimento de
especialistas sobre domínios de problemas
• Assim, não se perde o conhecimento com a saída de especialistas e
o conhecimento pode ser usado/estudado sem a presença do
especialista
• Resultado: criação de patrimônio estratégico da empresa (Strategic
Asset Building)
© LES/PUC-Rio
40
Desvantagens
• Construir um framework é complexo
– Re-uso não vem sozinho: deve ser planejado
– É mais complexo e demora mais fazer uma aplicação tendo que
construir um framework em vez de fazer a aplicação do zero
• Documentação é essencial para o usuário (desenvolvedor)
poder utilizar o framework
• Dificuldade para manter compatibilidade com versões
anteriores
– Frameworks se tornam mais maduros com o passar do tempo e
as aplicações devem evoluir em paralelo
• Flexibilidade e generalização do framework podem trabalhar
contra sua eficiência em algumas aplicações
© LES/PUC-Rio
41
Desvantagens
• Benefícios são realizados em longo prazo
– Quem pode pensar em longo prazo quando se está competindo
"On Internet time"?
• Poucas empresas
• Uma empresa aeroespacial demorou anos para fazer frameworks e
começou a ter retorno na quarta missão
• Precisa-se modificar o processo de desenvolvimento e criar
novos incentivos
• Vencer o "Not Made Here Syndrome"
– "The most profoundly elegant framework will never be reused
unless the cost of understanding it and using its abstractions is
lower than the programmer's perceived cost of writing them
from scratch" (Booch, Dr Dobb's Journal, 1994)
© LES/PUC-Rio
42
Bibliografia
• Jacques S. Projeto de Software Orientado a Objeto.
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/fra
me/oque.htm
• Markiewicz M., Lucena C. Object Oriented Framework
Development. http://www.acm.org/crossroads/xrds74/frameworks.html
• Sommerville, I. Software Engineering. 7th edition,
Chapter 18, 2000.
© LES/PUC-Rio
43