SCE 186- Engenharia de Software

Transcrição

1 Reuso de Software SCE 186- Engenharia de Software Profa Rosana T. Vaccare Braga (parte do material elaborado com base no tutorial sobre reuso da Profa. Claudia Werner) 1

2 Sumário Introdução Benefícios X Dificuldades Gerência de Reutilização Técnicas para Reuso Famílias de Produtos Padrões Frameworks Componentes (próxima aula) 2

3 Introdução O Reuso é inerente ao processo de solução de problemas utilizado pelos seres humanos Na medida em que soluções são encontradas, estas são utilizadas em problemas similares Nossa capacidade de abstração garante a adaptação necessária ao novo contexto O problema, portanto, não é a falta de reutilização na Engenharia de Software, mas a falta de uma sistemática ampla e formal para realizá-la 3

4 Definição de Reutilização Reutilização de software é o processo de incorporar em um novo produto: um novo código especificações de requisitos e projeto planos de teste, planos de teste, qualquer produto gerado durante desenvolvimentos anteriores, conhecimento em geral 4

5 Benefícios da reutilização Melhores índices de produtividade Produtos de melhor qualidade, mais confiáveis, consistentes e padronizados Redução dos custos e tempo envolvidos no desenvolvimento de software Maior flexibilidade na estrutura do software produzido, facilitando sua manutenção e evolução 5

6 Benefícios da reutilização (cont.) Uso efetivo dos especialistas no desenvolvimento de artefatos reutilizáveis Conformidade aos padrões, por exemplo, fazendo com que os usuários cometam menos erros ao utilizarem uma interface familiar. Desenvolvimento acelerado: economia no tempo de desenvolvimento e validação 6

7 Requisitos para reutilização Deve ser possível encontrar componentes reutilizáveis adequados catalogação e documentação externa efetivas. Deve-se ter certeza de que o componente se comportará conforme especificado e que será confiável certificação Deve ser possível compreender o componente para adaptá-lo à nova situação documentação interna detalhada 7

8 Dificuldades Identificação, recuperação e modificação de artefatos reutilizáveis Compreensão dos artefatos recuperados Qualidade de artefatos reutilizáveis Composição de aplicações a partir de componentes 8

9 Dificuldades Aumento nos custos de manutenção Falta de ferramentas de apoio Barreiras psicológicas: síndrome do não foi inventado aqui Barreiras legais e econômicas Necessidade da criação de incentivos à reutilização 9

10 Estado atual Diversos progressos na área técnica: sistemas de bibliotecas; técnicas de classificação, criação e distribuição de componentes; ambientes de suporte à reutilização de componentes; Trabalhos recentes tratam de aspectos não técnicos: aspectos gerenciais, econômicos, culturais e legais Temas de Pesquisas atuais: engenharia de domínio; reutilização de processos; desenvolvimento baseado em componentes 10

11 Gerência de reutilização Planejamento de Reutilização Criação de Artefatos Gerência de Artefatos Utilização de Artefatos 11

12 Gerência de Reutilização 12

13 Criação de artefatos Objetivo: produzir software e produtos associados para o reuso (Desenvolvimento para Reutilização Reuso Produtor) Atividades: Análise e modelagem do Domínio (Engenharia de Domínio) Desenvolvimento de uma Infraestrutura de Reutilização Evolução do processo 13

14 Reuso Produtor Questões a serem consideradas: Faça seu componente o mais geral possível, utilizando parâmetros e prevendo condições similares àquelas nas quais seu sistema invocará o componente Separe as dependência de forma que seções mais propensas a mudanças sejam isoladas das que devem permanecer iguais Mantenha a interface geral e bem-definida 14

15 Reuso Produtor Questões a serem consideradas: Inclua informações sobre problemas encontrados e resolvidos Use convenções claras para nomeação Documente as estruturas de dados e algoritmos Separe as seções de comunicação e tratamento de erros, para facilitar sua mudança. 15

16 Engenharia de Domínio Domínio: Uma coleção de problemas reais Uma coleção de aplicações que compartilham características comuns Definições p/ ED É o processo de identificar e organizar o conhecimento sobre uma classe de problemas, o domínio do problema, para dar suporte a sua descrição e solução Uma abordagem baseada em reutilização para definição do escopo, especificação da estrutura, e construção de recursos para uma classe de sistemas, subsistemas ou aplicações 16

17 Engenharia de Domínio 17

18 Engenharia de Domínio Objetivos Originar meta Originar meta-sistemas, ou seja, sistemas que são reutilizados na construção de aplicações específicas Descobrir e definir modelos de domínio e arquiteturas comuns às famílias de aplicações para suportar reutilização pré-planejada Tornar explícito e formalizar as teorias específicas ao domínio que permitem aos projetistas e especialistas do domínio a raciocinar sobre problemas e sistemas no domínio da aplicação 18

19 Engenharia de Domínio Etapas: Análise de Domínio: o conhecimento existente sobre o domínio é estudado e formalizado por meio de um modelo de domínio Projeto de Domínio: arquiteturas de software são construídas para atender aos requisitos identificados no modelo de domínio Implementação do Domínio: artefatos reutilizáveis são implementados para compor as arquiteturas 19

20 Utilização de Artefatos Objetivo: compor sistemas a partir de artefatos reutilizáveis (Desenvolvimento com Reutilização Reuso Consumidor) Atividades: Identificação, compreensão, avaliação, seleção, adaptação e integração de artefatos Feedback ao Planejamento, Criação e Gerência de Artefatos 20

21 Reuso Consumidor Questões a serem feitas: O componente executa a função e fornece os dados que você precisa? Se forem necessárias mudanças mínimas, trata-se de menos esforço do que construir o componente do zero? O componente está bem documentado, de forma que possa ser entendido sem ter que entender linha por linha do código? Existe um registro completo do teste do componente e histórico da revisão, para certificar que ele não tem erros? 21

22 Técnicas para Reuso Famílias de Produtos Padrões de software Frameworks Componentes Bibliotecas de Classes 22

23 Famílias de Produtos Uma família de produtos, ou linha de produtos, é um conjunto de aplicações relacionadas, que têm uma arquitetura de domínio específico em comum. Contudo cada aplicação específica é especializada de alguma maneira O núcleo em comum da família é reutilizado cada vez que uma nova aplicação é desejada. O novo desenvolvimento pode exigir que algumas partes de código sejam escritos, ou que sejam modificados alguns componentes já existentes. 23

24 Famílias de Produtos Tipos de especialização: Especialização da plataforma, por exemplo Windows, NT, Solaris e Linux (funcionalidade permanece inalterada) Especialização da configuração, por exemplo periféricos utilizados Especialização funcional (clientes com diferentes requisitos), por exemplo biblioteca pública ou privada têm diferentes tratamentos para multa ou privilégio dado a leitores 24

25 Padrões de Software descrevem soluções para problemas que ocorrem com freqüência no desenvolvimento de software Diversas categorias: padrões de processo, padrões arquiteturais, padrões de análise, padrões de projeto, padrões de programação,... 25

26 Vantagens de padrões reuso de soluções encontradas por especialistas experientes --> aumento da produtividade e qualidade melhoria na comunicação entre projetistas uniformidade na estrutura do software menor complexidade (blocos construtivos) 26

27 Exemplo: Padrão de análise (Boyd 98) STATIC 1 STATIC 2 name name description description set set get get m ASSOCIATION begin_date end_date cost allocate_costs create_current_from_plan 0..m Atributos Comportamento

28 Sala nome descrição calcular custos da sala set get Exemplo Atribuição_Sala_Depto data_inicial data_final percentagem_alocação alocar_custos criar_atribuição Departamento nome descrição calcular custos depto set m get 0..m

29 Padrões de Projeto - GoF Catálogo de Padrões de Projeto [Gamma95] Dois critérios de classificação Propósito - reflete o que o padrão faz De Criação: trata da criação de objetos Estrutural: cuida da composição de classes e objetos Comportamental: caracteriza o modo como as classes e objetos interagem e distribuem responsabilidades Escopo Classe: trata do relacionamento entre classes e subclasses (herança - relacionamento estático) Objetos: lida com a manipulação de objetos (podem ser modificados em tempo de execução) GoF: Gang of Four apelido dado aos quatro autores do livro 29

30 Padrões de Projeto - GoF Propósito De Criação Estrutural Comportamental Classe Factory Method Adapter Interpreter Template Method Escopo Objeto Abstract Factory Builder Prototype Singleton Adapter Bridge Composite Decorator Facade Flyweygth Proxy Chain of Responsability Command Iterator Mediator Memento Observer State Strategy Visitor 30

31 Padrões de Projeto Composite (Objeto Estrutural) Intenção (Intent) compõe objetos em estruturas de árvore para representar hierarquias part-whole. Composite deixa o cliente tratar objetos individuais e composição de objetos uniformemente. 31

32 Padrões de Projeto Motivação (Motivation) Editores gráficos permitem aos usuários construir diagramas complexos, agrupando componentes simples Implementação simples: definir uma classe para primitivas gráficas tais como Texto, Linhas e outras classes que agem como depósitos (containers) para essas primitivas Problema: Código que usa essas classes deve tratar primitivas e objetos do depósito diferentemente, tornando a aplicação mais complexa 32

33 Padrões de Projeto O Composite cria uma classe abstrata que representa primitivas e seus depósitos. 33

34 Padrões de Projeto Exemplo de composição recursiva de objetos 34

35 Padrões de Projeto Aplicabilidade (Applicability) representar hierarquias de objetos part-whole permitir aos usuários ignorar a diferença entre composições de objetos e objetos individuais. Todos os objetos na estrutura são tratados uniformemente 35

36 Padrões de Projeto Estrutura (Structure) 36

37 Padrões de Projeto Participantes (Participants) Component (Grafic) declara a interface para os objetos na composição implementa o comportamento padrão para a interface comum de todas as classes, quando apropriado declara uma interface para acessar e gerenciar os componentes filho define uma interface para acessar o pai de um componente na estrutura recursiva, implementado-o se for apropriado 37

38 Padrões de Projeto Leaf (Rectangle, Line, Text, etc.) representa objetos folha na composição. Uma folha não tem filhos define o comportamento para objetos primitivos na composição Composite (Picture) define o comportamento para componentes que têm filhos armazena componentes filho implementa operações relacionadas aos filhos na interface Component Client manipula objetos na composição pelo através da interface Component 38

39 Padrões de Projeto Colaboradores (Collaborations) Clients usam a interface Component para interagir com objetos na estrutura composta. Se o receptor é uma folha então o pedido é manipulado diretamente Se o receptor é um Composite então os pedidos são enviados para seus componentes filhos 39

40 Padrões de Projeto Conseqüências (Consequences) define hierarquias de classes que consistem de objetos primitivos e compostos simplifica o cliente. Clientes podem tratar estruturas compostas e objetos individuais de maneira uniforme facilita a adição de novos componentes 40

41 Padrões de Projeto Exemplo de Código (Sample Code) class Equipment { public: virtual ~Equipment(); const char* Name() { return _name; } virtual Watt Power(); virtual Currency NetPrice(); virtual Currency DiscountPrice(); virtual void Add(Equipment*); virtual void Remove(Equipment*); virtual Iterator* CreateIterator(); protected: Equipment(const char*); private: const char* _name; }; class CompositeEquipment : public Equipment { public: virtual ~CompositeEquipment(); virtual Watt Power(); virtual Currency NetPrice(); virtual Currency DiscountPrice(); virtual void Add(Equipment*); virtual void Remove(Equipment*); virtual Iterator* CreateIterator(); protected: CompositeEquipment(const char*); private: List _equipment; }; 41

42 Padrões de Projeto class FloppyDisk : public Equipment { public: FloppyDisk(const char*); virtual ~FloppyDisk(); }; virtual Watt Power(); virtual Currency NetPrice(); virtual Currency DiscountPrice(); 42

43 Padrões de Projeto Usos Conhecidos (Known Uses) Presente em quase todos os sistemas OO A classe original View do MVC RTL Smalltalk compiler framework Etc. 43

44 Padrões de Projeto Padrões Relacionados (Related Patterns) Chain of Responsibility Decorator Flyweight Iterator Visitor 44

45 Frameworks Aplicação semi-completa reutilizável que, quando especializada, produz aplicações personalizadas (Johnson & Foote, 1988) Coleção de classes abstratas e concretas e a interface entre elas, representando o projeto de um sub-sistema (Pree, 1995) 45

46 Conceitos Básicos Hot-Spots Representam as partes do framework de aplicação que são específicas de sistemas individuais São projetados para serem genéricos - podem ser adaptados às necessidades da aplicação Frozen-Spots Definem a arquitetura geral de um sistema de software - seus componentes básicos e os relacionamentos entre eles Permanecem fixos em todas as instanciações do framework de aplicação 46

47 Tipos de framework Framework Caixa Branca: reuso provido por herança Framework Caixa Preta reuso provido por composição Framework Caixa Cinza mistura 47

48 Framework Caixa Branca R Hot Spot R3 48

49 Framework Caixa Preta R Hot Spot R1 R2 R3 Ocorrência de variabilidade 49

50 Framework caixa-branca X caixa-preta framework caixa branca é mais fácil de projetar framework caixa preta é mais fácil de usar frameworks caixa-branca evoluem para se tornar mais caixa preta Aumenta o numero de objetos, mas eles ficam menores Complexidade está na interconexão Objetos compostos de objetos menores O Scripting fica mais importante e as linguagens visuais tornam-se possíveis 50

51 Tipos de framework Facilidade de desenvolvimento Caixa Branca Caixa Cinza Caixa Preta Facilidade de uso 51

52 Classificação de Frameworks de aplicação Frameworks de Infra-estrutura do Sistema simplificam o desenvolvimento da infra-estrutura de sistemas portáveis e eficientes, exemplos: sistemas operacionais, comunicação, interfaces com o usuário e ferramentas de processamento de linguagem em geral são usados internamente em uma organização de software e não são vendidos a clientes diretamente 52

53 Classificação de Frameworks de aplicação Frameworks de Integração de Middleware usados em geral para integrar aplicações e componentes distribuídos. projetados para melhorar a habilidade de desenvolvedores em modularizar, reutilizar e estender sua infra-estrutura de software para funcionar sem costuras em um ambiente distribuído exemplos: Object Request Broker (ORB), middleware orientado a mensagens e bases de dados transacionais 53

54 Classificação de Frameworks de aplicação Frameworks de Aplicação Empresarial voltados a domínios de aplicação mais amplos e são a pedra fundamental para atividades de negócios das empresas. exemplos: telecomunicações, aviação, manufatura e engenharia financeira. são mais caros para desenvolver ou comprar, mas podem dar um retorno substancial do investimento, já que permitem o desenvolvimento de aplicações e produtos diretamente 54

55 Desenvolvimento de Software Baseado em Frameworks Desenvolvimento do framework Análise de domínio, projeto arquitetural, projeto do framework, implementação, teste e documentação Uso do framework Evolução e manutenção do framework 55

56 Componentes de Software Objetivo: quebra de blocos monolíticos em componentes interoperáveis Componentes são construídos/empacotados com o objetivo de serem reutilizados em diferentes aplicações Um componente provê um conjunto de serviços acessíveis por meio de uma interface bem definida Motivações: desenvolvimento da Internet/WWW, arquitetura cliente/servidor, computação distribuída, Orientação a Objetos, Componentware, dentre outros 56

57 Documentação de Componentes Objetivos: Objetivos: definir a estrutura de dados e serviços necessários para descrever o formato de empacotamento usando padrões apoiar o empacotamento (desenvolvimento para reutilização) apoiar a avaliação (desenvolvimento com reutilização) e permitir anotações usar a tecnologia de hipermídia para apresentar a informação com interatividade 57

58 Desenvolvimento Baseado em Componentes (DBC) Metodologias para o DBC UML Components J. J. Cheesman and J. Daniels Catalysis ( D. D'Souza and A. A. Wills KobrA C. Atkinson et al. 58

59 Bibliotecas de Classes Classes de uso genérico podem ser disponibilizadas para reuso e importadas em múltiplas aplicações Em geral são incorporadas ao código final da aplicação, ou seja, são compiladas juntamente com o restante do código. 59