engenharia de software

1

Reuso de Software

SCE 186- Engenharia de SoftwareProfa Rosana T. Vaccare Braga

(parte do material elaborado com base no tutorial sobre reuso da Profa. Claudia Werner)

2

SumárioIntroduçãoBenefícios X DificuldadesGerência de ReutilizaçãoTécnicas para Reuso

Famílias de ProdutosPadrõesFrameworksComponentes (próxima aula)

3

IntroduçãoO Reuso é inerente ao processo de solução de problemas utilizado pelos seres humanosNa medida em que soluções são encontradas, estas são utilizadas em problemas similaresNossa capacidade de abstração garante a adaptação necessária ao novo contextoO 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

4

Definição de ReutilizaçãoReutilização de software é o processo de incorporar em um novo produto: um novo

códigoespecificações de requisitos e projetoplanos de teste, planos de teste,qualquer produto gerado durante desenvolvimentos anteriores, conhecimento em geral

5

Benefícios da reutilizaçãoMelhores índices de produtividadeProdutos de melhor qualidade, mais confiáveis, consistentes e padronizadosRedução dos custos e tempo envolvidos no

desenvolvimento de softwareMaior flexibilidade na estrutura do software produzido, facilitando sua manutenção e evolução

6

Benefícios da reutilização (cont.)

Uso efetivo dos especialistas no desenvolvimento de artefatos reutilizáveisConformidade 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

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çãoDeve ser possível compreender o componente para adaptá-lo à nova situação

documentação interna detalhada

8

Dificuldades

Identificação, recuperação e modificação de artefatos reutilizáveisCompreensão dos artefatos recuperados Qualidade de artefatos reutilizáveisComposição de aplicações a partir de componentes

9

Dificuldades

Aumento nos custos de manutençãoFalta de ferramentas de apoio Barreiras psicológicas: síndrome do não foi inventado aquiBarreiras legais e econômicasNecessidade da criação de incentivos à reutilização

10

Estado atualDiversos 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

11

Gerência de reutilização

Planejamento de Reutilização Criação de ArtefatosGerência de ArtefatosUtilização de Artefatos

12

Gerência de Reutilização

13

Criação de artefatosObjetivo: 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çãoEvolução do processo

14

Reuso ProdutorQuestõ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 componenteSepare as dependência de forma que seções mais propensas a mudanças sejam isoladas das que devem permanecer iguaisMantenha a interface geral e bem-definida

15

Reuso ProdutorQuestões a serem consideradas:

Inclua informações sobre problemas encontrados e resolvidosUse convenções claras para nomeaçãoDocumente as estruturas de dados e algoritmosSepare as seções de comunicação e tratamento de erros, para facilitar sua mudança.

16

Engenharia de DomínioDomí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çãoUma 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

17

Engenharia de Domínio

18

Engenharia de DomínioObjetivos

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é-planejadaTornar 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

19

Engenharia de DomínioEtapas:

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

20

Utilização de ArtefatosObjetivo: 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 artefatosFeedback ao Planejamento, Criação e Gerência de Artefatos

21

Reuso ConsumidorQuestõ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?

22

Técnicas para Reuso

Famílias de ProdutosPadrões de softwareFrameworksComponentesBibliotecas de Classes

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 maneiraO 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.

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 utilizadosEspecializaçã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

25

Padrões de Software

descrevem soluções para problemas que ocorrem com freqüência no desenvolvimento de softwareDiversas categorias:

padrões de processo, padrões arquiteturais, padrões de análise, padrões de projeto, padrões de programação, ...

26

Vantagens de padrões

reuso de soluções encontradas por especialistas experientes --> aumento da produtividade e qualidademelhoria na comunicação entre projetistasuniformidade na estrutura do softwaremenor complexidade (blocos construtivos)

Exemplo: Padrão de análise

STATIC 1namedescriptionsetget

STATIC 2namedescriptionsetget

ASSOCIATIONbegin_Dateend_Datecostallocate_costscreate_current_from_plan

1..1 1..1

0..m0..m

Comportamento

Atributos

(Boyd 98)

ExemploSalanomedescriçãocalcular custos da salasetget

Departamentonomedescriçãocalcular custos deptosetget

Atribuição_Sala_Deptodata_inicialdata_finalpercentagem_alocaçãoalocar_custoscriar_atribuição

1..1 1..1

0..m0..m

29

Padrões de Projeto - GoFCatálogo de Padrões de Projeto [Gamma95]

Dois critérios de classificaçãoPropósito - reflete o que o padrão faz

De Criação: trata da criação de objetosEstrutural: cuida da composição de classes e objetosComportamental: caracteriza o modo como as classes e objetos interagem e distribuem responsabilidades

EscopoClasse: 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

30

Padrões de Projeto - GoFPropósito

De Criação Estrutural ComportamentalClasse Factory Method Adapter Interpreter

Template Method

Esco

po

Objeto Abstract FactoryBuilderPrototypeSingleton

AdapterBridgeCompositeDecoratorFacadeFlyweygthProxy

Chain of ResponsabilityCommandIteratorMediatorMementoObserverStateStrategyVisitor

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.

32

Padrões de ProjetoMotivaçã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 primitivasProblema: Código que usa essas classes deve tratar primitivas e objetos do depósito diferentemente, tornando a aplicação mais complexa

33

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

34

Padrões de ProjetoExemplo de composição recursiva de objetos

35

Padrões de ProjetoAplicabilidade (Applicability)

representar hierarquias de objetos part-wholepermitir aos usuários ignorar a diferença entre composições de objetos e objetos individuais. Todos os objetos na estrutura são tratados uniformemente

36

Padrões de ProjetoEstrutura (Structure)

37

Padrões de ProjetoParticipantes (Participants)

Component (Grafic)declara a interface para os objetos na composiçãoimplementa o comportamento padrão para a interface comum de todas as classes, quando apropriadodeclara uma interface para acessar e gerenciar os componentes filhodefine uma interface para acessar o pai de um componente na estrutura recursiva, implementado-o se for apropriado

38

Padrões de ProjetoLeaf (Rectangle, Line, Text, etc.)

representa objetos “folha” na composição. Uma folha não tem filhosdefine o comportamento para objetos primitivos na composição

Composite (Picture)define o comportamento para componentes que têm filhosarmazena componentes filhoimplementa operações relacionadas aos filhos na interface Component

Clientmanipula objetos na composição pelo através da interface Component

39

Padrões de ProjetoColaboradores (Collaborations)

Clients usam a interface Component para interagir com objetos na estrutura composta.Se o receptor é uma folha então o pedido é manipulado diretamenteSe o receptor é um Composite então os pedidos são enviados para seus componentes filhos

40

Padrões de ProjetoConseqüências (Consequences)

define hierarquias de classes que consistem de objetos primitivos e compostossimplifica o cliente. Clientes podem tratar estruturas compostas e objetos individuais de maneira uniformefacilita a adição de novos componentes

41

Padrões de ProjetoExemplo 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;

};

42

Padrões de Projeto

class FloppyDisk : public Equipment {public:

FloppyDisk(const char*);virtual ~FloppyDisk();

virtual Watt Power();virtual Currency NetPrice();virtual Currency DiscountPrice();

};

43

Padrões de ProjetoUsos Conhecidos (Known Uses)

Presente em quase todos os sistemas OOA classe original View do MVCRTL Smalltalk compiler frameworkEtc.

44

Padrões de ProjetoPadrões Relacionados (Related Patterns)

Chain of ResponsibilityDecoratorFlyweightIteratorVisitor

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)

46

Conceitos BásicosHot-Spots

Representam as partes do framework de aplicação que são específicas de sistemas individuaisSão projetados para serem genéricos - podem ser adaptados às necessidades da aplicação

Frozen-SpotsDefinem a arquitetura geral de um sistema de software - seus componentes básicos e os relacionamentos entre elesPermanecem fixos em todas as instanciações do framework de aplicação

47

Tipos de framework

Framework Caixa Branca:reuso provido por herança

Framework Caixa Pretareuso provido por composição

Framework Caixa Cinzamistura

48

Framework Caixa Branca

HotSpot

RR3

49

Framework Caixa Preta

HotSpot

R R1R2

R3

Ocorrência devariabilidade

50

Framework caixa-branca X caixa-preta

framework caixa branca é mais fácil de projetarframework 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

51

Tipos de framework

Facilidade de desenvolvimento

Caixa Branca

CaixaPreta

CaixaCinza

Facilidade de uso

52

Classificação de Frameworksde aplicação

Frameworks de Infra-estrutura do Sistemasimplificam 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 linguagemem geral são usados internamente em uma organização de software e não são vendidos a clientes diretamente

53

Classificação de Frameworksde aplicação

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

54

Classificação de Frameworksde aplicação

Frameworks de Aplicação Empresarialvoltados 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

55

Desenvolvimento de Software Baseado em Frameworks

Desenvolvimento do frameworkAnálise de domínio, projeto arquitetural, projeto do framework, implementação, teste e documentação

Uso do frameworkEvolução e manutenção do framework

56

Componentes de SoftwareObjetivo: quebra de blocos monolíticos em componentes interoperáveisComponentes 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

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õesapoiar o empacotamento (desenvolvimento para reutilização)apoiar a avaliação (desenvolvimento com reutilização) e permitir anotaçõesusar a tecnologia de hipermídia para apresentar a informação com interatividade

58

Desenvolvimento Baseado em Componentes (DBC)

Metodologias para o DBCUML Components

J. J. Cheesman and J. Daniels

Catalysis (http://www.iconcomp.com/catalysis)

D. D'Souza and A. A. Wills

KobrAC. Atkinson et al.

59

Bibliotecas de Classes

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