eliane martins - instituto de computação - unicamp reutilização de software nov/2005

Eliane Martins - Instituto de Computação - UNICAMP

Reutilização de softwareReutilização de software

Nov/2005

Eliane Martins - Instituto de Computação - UNICAMP 2

TópicosTópicos

• Reutilização: conceito

• Benefícios e dificuldades

• Desenvolvimento baseado em componentes– Desenvolvimento com reutilização

– Desenvolvimento para reutilização

• Padrões de software

Eliane Martins - Instituto de Computação - UNICAMP 3

ReferênciasReferências

E. Bezerra. Princípios de Análise e Projeto de Sistemas com UML. Editora Campus, 2a. Edição, 2007.

DESCHAMPS, F. “Padrões de Projeto. Uma Introdução”. Notas de Aula. Departamento de Automação e Sistemas (DAS). Universidade Federal de Santa Catarina.

GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J. "Design Patterns: Elements of Reusable Object-Oriented Software". Reading, MA: Addison Wesley, 1995.

JANDL, P. Jr. “Uma Introdução aos Padrões de Projeto com Java”. 2003. Obtido na Internet em ago/2005.

PRESSMAN, R.S. “Sw Engineering: a Practitioner’s Approach”. McGraw-Hill, 4ª ed, 1997, c.26.

SOMMERVILLE, I.. “Sw Engineering”, 6ª ed, 2001, cap14.


Reutilização

● Reutilizar, v.t.d.

1. Tornar a utilizar. 2. Dar novo uso a.

• Reutilização, s.f.

1. Ato ou efeito de reutilizar. 2. Procedimento em que, material que já for a anteriormente processado, após tratamento conveniente, se insere numa corrente ou processo

[FERREIRA, Aurélio B. H. “Novo Dicionário da Língua Portuguesa”. Rio de Janeiro, RJ: Nova Fronteira, 2ª edição, 1986.]

• Também designada em alguns textos técnicos como reutilização


• Atividade comum– Engenheiros mecânicos ou elétricos dificilmente especificam um

projeto no qual os componentes tenham que ser fabricados especialmente

– São reutilizados desde componentes pequenos (válvulas, trnasístores) até componentes mais complexos (motores, turbinas)

Reutilização em outras áreas da engenharia


• “Qualquer procedimento que produza (ou ajude a produzir) um sistema tornando a utilizar algo desenvolvido previamente”

[Peter Freeman 1987, citado em Pressman95, cap.26]]

• Reutilização é algo praticado há muito tempo em Engenharia de Software, só que de maneira ad hoc

• Dada a pressão por produzir sw de boa qualidade em pouco tempo necessidade de reutilizar de forma sistemática

Reutilização em Engenharia de Software


Histórico1960 Reutilização de linhas de código de um programa em outro1970 Reutilização de código comum (subrotinas)

Reutilização de funções genéricas (bibliotecas de funções)1980 OO: herança, composição / delegação

uso de interfaces (implementadas, em algumas linguagens,por classes abstratasPolimorfismo e ligação dinâmica (late binding): qqr implementaçãoda interface pode ser usada em tempo de execução

1990 Padrões de software: reutilização de várias classes e de suas colaborações. reutilização não mais restrita ao código.Frameworks: reutilização de análise, projeto, implementação e testes

dedomínios de aplicações.Componentes: reutilização de código executável, configurável,

adaptável.2004(?) Serviço: reutilização de unidade autônoma de execução (função de

negócio).

???

[Jacques Sauvé 2002: http://jacques.dsc.ufcg.edu.br/cursos/map/html/intro/intro.htm]


• Vantagens:Desenvolvimento acelerado pois custos com

desenvolvimento e validação são reduzidosConformidade com padrõesMaior confiabilidade, pois utilizam-se soluções já

experimentadas

Reutilizar: sim ou não?


• Dificuldades:Seleção, recuperação e modificação de artefatos

reutilizáveisCompreensão dos artefatos recuperadosQualidade dos artefatos recuperadosComposição de aplicações a partir dos artefatos

recuperadosSíndrome do “não foi inventado aqui”Falta de ferramentas de apoio pois atualmente os CASE

não apoiam desenvolvimento com reutilização será válido ainda hoje?

Reutilizar: sim ou não?


Reutilizar: sim ou nãoUm caso de fracasso

Invasões mongóis no Japão (1274 – 1281)

Samurais atacam barco da tropa mongol



• Kublai Khan, neto de Genghis Khan, decide invadir o Japão após ter conquistado China e Coréia

• 1ª invasão: 800 barcos, 15 000 soldados mongóis e chineses, 8000 coreanos, conquistam duas ilhas mas ...– Pesadas baixas

– Rebelião entre soldados coreanos e chinesesfizeram-nos recuar até o litoral mas ...

– Tempestades destruíram uma boa parte dos barcos


Fonte:http://wapedia.mobi/pt/Invasão_mongol_do_Japão, maio/2009



• 2ª invasão (inicia-se em 1275 e termina em 1281): – Nova tentativa, com mais contingente, mais navios (4000)– Novamente o exército é obrigado a se retirar e retomar os navios,

mas ...– Um tufão, kamikaze (vento divino),

destruiu 1/3 da frota mongol. Porquê?• A frota se constitui de botes fluviais

chineses e navios leves• Em parte por sabotagem: engenheiros

chineses introduziram falhas nos navios novos

• Em parte por falta de tempo: os botes fluviais não puderam ser adaptados para reutilização no oceano



1. Existência de uma biblioteca (ou repositório de componentes)ex.: component source, jars

2. Garantia de que o componente se comportará conforme foi especificado e que serão confiáveis

3. Existência de documentação que ajude a compreendê-los e adotá-los

Requisitos para reutilização


• Reutilização pode ser considerada em todas as fases do desenvolvimento

• Pode-se reutilizar:– Artefatos intermediários padrões de software

– Sistemas de aplicação

– Componentes

– Funções

Níveis de Abstração


• Final da década de 90:– frustração com o reutilização de classes de OO

• Reutilização em OO é limitado pois:– Classes não são unidades executáveis por si só, isto é, precisam ser

compiladas ou conectadas a uma aplicação para serem utilizadas

– É difícl reutilizá-las sem ter o código fonte

– Têm granularidade muito baixa

Desenvolvimento baseado em componentes(DBC)


• Entidade executável independente.

• O código fonte pode não estar disponível.

• Sua interface é pública e conhecida, e todas as interações são feitas por meio desta interface:– Interface fornecida (provided): define os serviços formecidos pelo

componente

– Interface requerida (required): especifica os serviços que devem estar disponíveis no contexto de uso do componente.

• Sua interface é descrita em termos de operações parametrizadas, ou seja, seu estado interno não é exposto.

Componente

[Sommerville 2001, 14.1]


Notação

Componente

Interface fornecida

Interface requerida

UML 1.4

UML 2.0

Interface fornecida

Interface requerida

Componente

Componente

Forma abreviada Forma expandida

«interface»Interface_B

tipo Operação_C1 (tipo args)tipo Operação_C2 (tipo args)

«interface»Interface_A

tipo Operação_A1 (tipo args)tipo Operação_A2 (tipo args)

depende de

realiza


Exemplo

Sistema de reserva de hotel

...IFazReservaICancelaReserva

...ICobrança

IGerencia


Exemplo

Sistema de reserva de hotel

...IFazReservaICancelaReserva

...ICobrança

IGerencia

«interface»IGerencia

getDetalhesHotel ( )getInfoQuartos ( )

«interface»IFazReserva

getDetalhesHotel ( )getInfoQuartos ( )

FazReserva ( )

usa


Reutilização de componentes prontos

• A materialização de componentes prontos pode se dar de duas formas:– Reutilização de componente já utilizado pela organização

• Geralmente os componentes associados ao domínio de negócio são os mais propícios a serem reutilizados

– Aquisição de componentes a partir de catálogos de terceiros• Compra ou uso de sw livre (open source ou freeware)

• Componentes reutilizados nem sempre atendem exatamente aos requisitos:– Necessidade de adaptar os requisitos– Necessidade de adaptar a arquitetura para permitir a integração de

componentes prontos


Reutilização de componentes prontos – um processo

Identificar componentes candidatos

Avaliar o impacto na arquitetura

Negociar requisitos

Atualizar arquitetura

Avaliar arquitetura

Revisar as especificações

[aceito]

[inspirado em CompGov]


Reutilização de componentes prontos – um processo

Identificar componentes candidatos

Avaliar o impacto na arquitetura

Negociar requisitos

Atualizar arquitetura

Avaliar arquitetura

Revisar as especificações

[aceito]

Listar componentes candidatos

Selecionar componente

Validar componente

Levar em conta:-Requisitos funcionais

- Atributos de qualidade- Restrições de projeto

[inspirado em CompGov]


Metodologias de DBC

• Existem várias, dentre as quais as mais conhecidas são:– UML Components

• J. J.Cheesman e J.Daniels

– Catalysis (http://www.iconcomp.com/catalysis)• D. D'Souza e A. A. Wills

– KobrA• C.Atkinson et al.


• Custos: Vantagens do reutilização em geral + Redução dos riscos do processo pois o uso de componentes prontos

reduz as incertezas quanto aos custos de desenvolvimento de novos componentes

Aumento nos custos de manutenção pois componentes de terceiro podem ser difíceis de entender e podem se tornar incompatíveis com mudanças do sistema

Síndrome do “não foi criado aqui”: é mais desafiador desenvolver um componente original; acredita-se mais na qualidade do que é desenvolvido “em casa”

Necessidade de manutenção de uma biblioteca de componentes Dificuldade em encontrar, compreender e adaptar componentes

reutilizáveis

Reutilizar componentes: sim ou não?


Frameworks de aplicações

• Framework: projeto de um subsistema (ou arquitetura de sw semi-definida) constituído de um conjunto de componentes individuais e das interconexões entre eles.

• Frameworks criam uma infra-estrutura pré-fabricada para o desenvolvimento de aplicações de um domínio específico.

• Uma aplicação pode ser construída a partir da integração de vários frameworks.


Conceitos básicos

• Hot spots– Partes do framework que são projetados para serem genéricos

– Podem ser adaptados às necessidades da aplicação

• Frozen spots– Definem a arquitetura geral da aplicação, seus componentes e os

relacionamentos entre eles

– Permanecem fixos em todas as instanciações do framework


Frameworks OO

• A maioria dos frameworks são descritos em termos de OO.

• São constituídos de classes abstratas e concretas e das relações entre elas.

• Conforme o modo de estender um framework tem-se:– Framework caixa branca: usuários desenvolvem implementações

para as classes abstratas fornecidas, que funcionam como pontos adaptáveis, bem como o código específico para a aplicação.

– Framework caixa preta: contém todas as possíveis alternativas para todos os seus pontos adaptáveis. O usuário escolhe uma das alternativas disponíveis para criar sua aplicação. Permitem ao usuário

adequar o framework às características específicas

da aplicação


Frameworks bibliotecas de classes

Aplicação

Bibliotecas

O controle da execução está na aplicação que está sendo construída

Framework

Aplicação

Inversão de controle: a aplicação que utiliza o framework pode ser invocada por ele


Linhas de Produto de Software

• Linhas de produto de software (LPS), ou família de aplicações: – Consiste no desenvolvimento de um conjunto de produtos de software,

com alto grau de similaridade entre si e que atendem às necessidades específicas de um segmento de mercado ou missão, de forma prescritiva, a partir de um conjunto de ativos centrais.

[Clements & Northrop. Software Product Lines: Practices and Patterns. Addison Wesely, 2002]

• Atividades essenciais para implantação e manutenção de LPS:– Desenvolvimento de ativos centrais:

• Ativos centrais: partes a serem reutilizadas entre os produtos da família

– Desenvolvimento de produtos:• Construção de produtos utilizando os ativos centrais

– Gerência• Atividades que gerenciam a implantação e manutenção de LPS


Exemplo de LPS

Caixa Eletrônico

Identificação do usuário

Emissão de extrato

Toque na tela

Leitura de cartão

Tela Impressão

Diagrama de características

Características obrigatórias

Características alternativas

Característica opcionalOu exclusivoOu inclusivo

W.M.Assis 2009, Dissertação de Mestrado, IC-Unicamp]


Reutilização de serviços

• Existem várias definições para serviços. Aqui usamos a de Ribarov et al. (2007)

Serviço: bloco de construção de SOA que - realiza uma funcionalidade de negócio - combina dados e comportamento- encapsula lógica de negócio e dados- deixa visível somente uma interface para o resto do sistema- é autônomo com relação aos demais serviços do sistema

de componentes


Mais características de serviços

• Serviços:– Têm interfaces bem definidas, independentes da implementação

– São auto-contidos (autônomos) e fracamente acoplados

– Podem ser descobertos dinamicamente

– Podem ser compostos de outros serviços

[Mahmoud 2005]


Serviço e processo

• Serviços (de negócio) são autônomos – como fazer com que cooperem?

• Processos (de negócio):– Outro bloco de construção de desenvolvimento orientado a serviços

– Fazem a ligação e o seqüenciamento entre os serviços

– Representam a execução do negócio como um todo segundo um workflow e gestão de processos de negócio (BPM)


Demais conceitos

• Aplicação (frontend application)– Materializa o processo de negócio

• Repositório de serviços (service registry)– Registra informações sobre os serviços e sobre o que fazem

• Barramento de serviços (service bus)– Faz a conexão entre os serviços

– Serve de mediador entre o consumidor e provedor do serviço, permitindo introduzir qualidade de serviço (QoS) ou transformação de dados [Ribarov et la. 2007]


Conceitos

SOA

Serviço

Aplicação

Repositóriode Serviços

Barramentode Serviços

Contrato

Implementação

Interface

Lógica donegócio

Dados

[Krafzig et al.2005]


Paradigma find-bind-execute

Repositóriode Serviços

Consumidorde Serviços

Provedorde Serviços

ClienteCliente ServiçoServiço

Busca(find)

Publica

barramento

Conecta(bind-execute)


Acordo de nível de serviço

• SLA (Service Level Agreement)– Contrato entre fornecedor e consumidor de um serviço, que visa garantir

as características de qualidade do serviço oferecido

– O nível de qualidade do serviço (QoS) pode variar de acordo com o quanto o consumidor quer pagar

– QoS, especificada em termos mensuráveis, serve para medir e monitorar o desempenho do fornecedor

– Não cumprimento do SLA multa para o fornecedor


Contrato de SLA

• Pode conter especificações sobre:– Disponibilidade

• Ex.: o serviço deve estar disponível 99,9% do tempo ao longo do ano, ou seja, pode parar no máximo 8,7 horas em um ano

– Confiabilidade• Ex.: durante 1 ano o serviço não deve registrar mais de 1 defeito a cada 1

milhão de operações realizadas

– Desempenho• Ex.: o serviço deve ser realizado em até 2 segundos

– Prioridade e desempenho• Ex.: solicitações indicadas como “urgentes” devem ser realizadas em até 8h,

as marcadas como “importantes”, em até 24h e as “rotineiras”, em até 72h


Modelos de serviços

• Jini– Proposta da Sun de 1990

– Serviços são descobertos e usados dinamicamente (em rede)

• Serviços de grades (GS)

• Serviços Web (WS)– Noção de serviços de Jini + Web + diversos padrões

[Mahmoud 2005; Sommerv.2007, c.12.4]


Padrões

• Padrão, s.m.[do latim patronu, protetor]1. Modelo oficial de pesos e medidas. 2. Aquilo que serve de base ou

norma para a avaliação de qualidade ou quantidade. 3. Qualquer objeto que serve de modelo à feitura de outro. ...

[FERREIRA, Aurélio B. H. “Novo Dicionário da Língua Portuguesa”. Rio de Janeiro, RJ: Nova Fronteira, 2ª edição, 1986.]


Padrões de software

• Porquê– Aumentar a possibilidade de reutilização de boas soluções para

problemas freqüentes, garantindo, com isso, melhor qualidade para o software

– Especialistas têm tendência a reutilizar soluções para problemas surgidos em trabalho anterior

Os padrões surgem com a experiência prática

Experiência de especialistas pode ser compartilhada com novatos


Uma definição

• “Um padrão descreve um problema que ocorre repetidamente no nosso ambiente, descrevendo a essência de uma solução para este problema, de forma que pode-se usar esta solução milhares de vezes, sem faê-lo da mesma forma duas vezes.”

[ALEXANDER, Christopher, 1977 --> propôs padrões a serem usados em Arquitetura, de onde surgiu a idéia de utilizar do mesmo recurso em software]

[ALEXANDER, C., ISHIKAWA, S., SILVERSTEIN, M., JACOBSON, M., FIKSDAHL-KING,

I., ANGEL, S. "A Pattern Language". New York, NY (USA): Oxford University Press, 1977].


Outra definição

• “Um padrão de software nomeia, motiva e explica uma solução genérica a um problema recorrente que surge em uma situção específica. Ele descreve o problema, a solução, quando é aplicável e quais as conseqüências de seu uso.” [Gamma et al]


Características [Jandl 2003]

• Descrevem e justificam soluções para problemas concretos

e bem definidos.

• Documentam a experiência existente e comprovada.

• Fornecem um vocabulário comum aos desenvolvedores de

software.

• Descrevem relações entre conceitos, estruturas e mecanismos existentes nos sistemas.

• Podem ser utilizados em conjunto com outros padrões.


Uso de padrões

• Padrões podem ser utilizados nas diversas etapas de desenvolvimento de software:– Análise (M.Fowler 1997)

– Arquitetura, Projeto e Codificação (Gamma e al; Buschmann 1996.)

– Testes (R.Binder 1999)

– Manutenção (Barry 2003; Hammouda 2004)

– Reengenharia (Demeyer 2003)

...


Categorias de padrões

• Padrões de análise– Fazem parte da Especificação de Requisitos ou da Modelagem

Conceitual

– Definem conjunto de objetos do mundo real, seus relacionamentos e as regras que definem seu comportamento

– São dependentes da aplicação pois descrevem aspectos específicos do domínio do problema

• Padrões de arquitetura– Representam esquemas para estruturar o software. Definem conjunto

de subsistemas pré-definidos, especificam suas responsabilidade e as regras para organizar os relacionamentos entre eles.



• Padrões de projeto– Permitem refinar os subsistemas da arquitetura, ou os

relacionamentos entre eles– Focam em aspectos típicos de projeto, tias como: interface-usuário,

criação de objetos, entre outros– São os mais comuns na literatura

• Idiomas– São padrões de baixo nível, específicos para linguagens de

programação– Descrevem como implementar aspectos dos subsistemas ou dos

relacionamentos entre eles, usando características de uma determinada linguagem de programação



• Padrões de manutenção– Regras e restrições que devem ser satisfeitas por entidades de um

programa (classes, métodos e atributos) para facilitar a manutenção, mais especificamente, a documentação (HAMMOUDA 2004)


Elementos de um padrão

• Existem diversas formas de descrever um padrão. Para os padrões de projeto a forma mais comum é aquela descrita no livro de Gamma et al, denominado Gang of Four (GoF):

• Nome– Deve ser curo e intuitivo

(mnemônico)

• Problema:– Descreve em que situação o padrão

pode ser aplicado

• Solução– Descreve os elementos envolvidos,

suas responsabilidades e colaborações

• Conseqüências– Custos e benefícios da aplicação

do padrão

• Exemplos:– Exemplos de aplicação


Exemplo: um padrão de Análise

• Padrão Party:– Representa componentes de uma organização e os relacionamentos

entre eles

– Conceitos usados:• Party: pessoa ou organização de interesse para a aplicação

• Relação de subordinação: entre pessoas, entre pessoas e organizações


Partyendereço: String

LocalizaçãoPartydataInício: Date

dataTérmino: Date

Pessoa Cargo

NomeaçãoCargo- dataInício: Date- dataTérmino: Date

Partynome: String

Organização

subordinado a

*

*

* *

empregado empregador* *

1 1..*

EmpregodataInício: DatedataTérmino: Datetipo

1 1..*

1

*

nomeações

[Bezerra 2007]


Como selecionar um padrão

• Considere como os padrões de projeto solucionam os seus problemas de projeto.

• Examine as seções de descrição do problema de cada padrão.

• Estude como os padrões se interrelacionam. • Estude padrões de finalidades semelhantes. • Examine uma causa de reformulação de projeto.• Considere o que deveria ser variável no seu

projeto.[Deschamps2005]


Como usar um padrão

• Leia o padrão por inteiro, uma vez, para obter uma visão geral.

• Estude as seções de descrição do problema e do padrão.• Olhe exemplos de código do padrão. • Escolha nomes para os participantes do padrão que

tenham sentido no contexto da sua aplicação. • Defina as classes. • Defina nomes específicos da aplicação para as

operações no padrão. • Implemente as operações para apoiar as

responsabilidades e colaborações presentes.[Deschamps2005]


Onde obter mais informações

• Catálogo sobre padrões– http://www.dofactory.com/Patterns/Patterns.aspx#list

• Tutorial sobre padrões:– www.csc.calpoly.edu/~dbutler/tutorials/winter96/patterns/

objectives.html http://

• Padrões de projeto, Idiomas e Frameworks– ttp://www.cs.wustl.edu/~schmidt/patterns.html http://

• Apresentação geral sobre padrões– http://www.mindspring.com/~mgrand/pattern_synopses.htm


Sumário dos principais pontos aprendidos

eliane martins - instituto de computação - unicamp reutilização de software nov/2005

Documents