A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Frameworks Orientados a Objetos. Agenda Crash Course! Um problema Conceitos Classificação Framework vs Outras Abordagens Processo de desenvolvimento Documentação/Instanciação.

Apresentações semelhantes


Apresentação em tema: "Frameworks Orientados a Objetos. Agenda Crash Course! Um problema Conceitos Classificação Framework vs Outras Abordagens Processo de desenvolvimento Documentação/Instanciação."— Transcrição da apresentação:

1 Frameworks Orientados a Objetos

2 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

3 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!

4 Um problema Controle de qualidade AB Trigger Efetuador Sensor 12 Líquido opacidade Frameworks4

5 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

6 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

7 Uma Solução Separar o que é fixo(frozen-spot) do que é variável(hot- spot). Permitir a reutilização da parte fixa. 2010Frameworks7

8 Introdução

9 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

10 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

11 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

12 + 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

13 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

14 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

15 Frameworks Conceito Básico

16 Framework é composto por: 2010Frameworks16

17 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

18 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

19 Exemplo Frameworks19

20 Frameworks Instanciação

21 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

22 Aplicação Instanciação Processo de preenchimento / adaptação dos pontos de flexibilização (hot- spots) de uma framework. 2010Frameworks22

23 Processo de Instanciação 2010Frameworks23

24 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

25 + 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

26 Exemplo 2010Frameworks26

27 Frameworks Documentação

28 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çãoPúblico 2010Frameworks28

29 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

30 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

31 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]

32 Colaboração 2010Frameworks32

33 Frameworks Processo de Desenvolvimento

34 Desenvolvimento de um Framework Análise da aplicação DesignAplicação Análise do domínio Framework design Aplicação 1 Aplicação 2 Aplicação n Desenvolvimento tradicional orientado a objetos Desenvolvimento de aplicações baseado em frameworks 2010Frameworks34

35 Processo de Desenvolvimento Processo baseado na experiência Processo baseado na análise do domínio Processo utilizando design patterns Caso geral 2010Frameworks35

36 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 2010Frameworks36

37 Processo de desenvolvimento baseado na análise de domínio Desenvolvimento da Aplicação Desenvolvimento do Framework Análise do Domínio 1. Identificar abstrações e elementos em comum 2. Usar 3. Experiência 4. Atividade de manutenção usando a experiência 2010Frameworks37

38 Processo de desenvolvimento utilizando design de patterns Desenvolvimento da Aplicação Desenvolvimento do Framework 4. Atividade de manutenção usando a experiência 2. Usar3. Experiência Desenvolver a primeira aplicação Conjunto de Design Patterns 1. Aplicação sistemática 2010Frameworks38

39 Processo de desenvolvimento – Caso Geral Testar o Framework desenvolvendo de Aplicações Desenvolvimento do Framework 3. Atividade de manutenção usando a experiência 1. Usar 2. Erros e Experiência Análise do domínio do problema 2010Frameworks39

40 Cuidado! 2010Frameworks40

41 Frameworks Classificação

42 Quanto ao escopo Infra-estrutura System infrastruture frameworks Integração Middleware integration frameworks Corporativos Enterprise application frameworks [Fayad99] 2010Frameworks42

43 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

44 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

45 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

46 Quanto à técnica de extensão WhiteBox BlackBox GrayBox 2010Frameworks46

47 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

48 Exemplo: herança A B Trigger Efetuador Sensor 1 2 Cerveja opacidade 3 4 Cerveja opacidade Item Frango peso 2010Frameworks48

49 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

50 Componentes Frameworks com estas características (blackbox) são comumente chamados de Componentes [Mattson2000]. 2010Frameworks50

51 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

52 Classificação de Frameworks por técnicas de extensão 2010Frameworks52

53 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

54 Instanciação WhiteBox 2010Frameworks54

55 Instanciação Blackbox 2010Frameworks55

56 Frameworks Frameworks vs Outras Abordagens

57 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

58 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

59 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

60 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

61 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

62 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

63 Frameworks Trade–offs

64 Vantagens Modularidade Reusabilidade Extensibilidade Inversão de Controle Reuso de Design 2010Frameworks64

65 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

66 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

67 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

68 Resumindo 2010Frameworks68

69 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

70 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

71 Inversão de Controle 2010Frameworks71

72 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

73 Desvantagens Esforço de Desenvolvimento Curva de Aprendizado Integrabilidade Manutenibilidade Eficiência 2010Frameworks73

74 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

75 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

76 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

77 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

78 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

79 Exemplos de Framework Agenda VMarket Junit JBOSS – Hibernate, Seam, JPDL Eclipse – Pluggins J2EE/.NET 2010Frameworks79

80 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

81 Agenda - Diag. de Classe do Framework Hotspot 2010Frameworks81

82 Agenda - Diag. Classe da Aplicação 2010Frameworks82

83 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

84 VMarket - Descrição 2010Frameworks84

85 VMarket - Item Exemplo em XML de uma descrição de item 2010Frameworks85

86 VMarket - Diag. de Classe Hotspot 2010Frameworks86

87 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

88 JUnit Design 2010Frameworks88

89 JUnit – Como Utilizar 2010Frameworks89


Carregar ppt "Frameworks Orientados a Objetos. Agenda Crash Course! Um problema Conceitos Classificação Framework vs Outras Abordagens Processo de desenvolvimento Documentação/Instanciação."

Apresentações semelhantes


Anúncios Google