Carregar apresentação
A apresentação está carregando. Por favor, espere
1
Projeto de Sistemas de Software
Frameworks Projeto de Sistemas de Software
2
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
3
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
4
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
5
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
6
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
7
Características Reusável Extensível Seguro Eficiente 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
8
Características Completo Inversion-of-Control (IoC)
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
9
Características Inversion-of-Control (IoC) © LES/PUC-Rio
10
<<abstract>>
Características Inversion-of-Control (IoC) Biblioteca de Classes Snot Foo Bar Framework <<abstract>> Ciente usa CienteBar CienteFoo © LES/PUC-Rio
11
Propriedades Núcleo do framework Pontos de extensão
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
12
Propriedades Núcleo Pontos de Extensão © LES/PUC-Rio
13
Propriedades Hot Spots Frozen 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
14
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
15
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
16
Técnicas de Customização - Exemplo
Customização por Herança: Implementação dos Métodos Abstratos © LES/PUC-Rio
17
Tipos Por Herança Por Composição White-Box Gray-Box Black-Box
Tipo varia de acordo com a abordagem utilizada para a implementação dos Hot Spots Por Herança Por Composição White-Box Gray-Box Black-Box © LES/PUC-Rio
18
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
19
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
20
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
21
Tipos © LES/PUC-Rio
22
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
23
Frameworks X Design Patterns
Framework B Framework A © LES/PUC-Rio
24
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
25
Frameworks X Biblioteca de Classes
Classes instanciadas pelo cliente Cliente chama funções Não tem fluxo de controle pré-definido Não tem interação pré-definida Não tem comportamento default Customização com subclasse ou composição Chama funções da “aplicação” Controla o fluxo de execução Define interação entre objetos Provê comportamento default © LES/PUC-Rio
26
Desenvolvimento de Framework
Desenvolvimento tradicional orientado a objetos Análise da Aplicação Design Aplicação Desenvolvimento de aplicações baseado em frameworks Análise do Domínio Design do Framework Aplicação 1 Aplicação 2 Aplicação n ... © LES/PUC-Rio
27
Processo de desenvolvimento
Baseado na Experiência Desenvolvimento da Aplicação Desenvolvimento do Framework 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 © LES/PUC-Rio
28
Processo de desenvolvimento
Baseado na Análise de Domínio Análise do Domínio Desenvolvimento da Aplicação Desenvolvimento do Framework 1. Identificar abstrações e elementos em comum 2. Usar 3. Experiência 4. Atividade de manutenção usando a experiência © LES/PUC-Rio
29
Processo de desenvolvimento
Caso Geral Análise do Domínio do Problema Testar o Framework desenvolvendo Aplicação Desenvolvimento do Framework 1. Usar 2. Erros e Experiência 3. Atividade de manutenção usando a experiência © LES/PUC-Rio
30
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
31
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
32
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
33
Exemplo 1 - Agenda Hot Spots © LES/PUC-Rio
34
Exemplo 1 - Agenda © LES/PUC-Rio
35
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
36
Exemplo 2 - VMarket © LES/PUC-Rio
37
Exemplo 2 - VMarket Exemplo em XML de uma descrição do Item
© LES/PUC-Rio
38
Exemplo 2 - VMarket Diagrama de Classes Hotspot © LES/PUC-Rio
39
Vantagens Com o framework pronto, benefícios Motivos 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
40
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
41
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
42
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
43
Bibliografia Jacques S. Projeto de Software Orientado a Objeto. Markiewicz M., Lucena C. Object Oriented Framework Development. Sommerville, I. Software Engineering. 7th edition, Chapter 18, 2000. © LES/PUC-Rio
Apresentações semelhantes
© 2024 SlidePlayer.com.br Inc.
All rights reserved.