Transcript reuso - Instituto de Computação

Reutilização de software
Nov/2005
Eliane Martins - Instituto de Computação - UNICAMP
Tó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
2
Referê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”. McGrawHill, 4ª ed, 1997, c.26.
SOMMERVILLE, I.. “Sw Engineering”, 6ª ed, 2001, cap14.
Eliane Martins - Instituto de Computação - UNICAMP
3
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
Eliane Martins - Instituto de Computação - UNICAMP
Reutilização em outras áreas da engenharia
• 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)
Eliane Martins - Instituto de Computação - UNICAMP
Reutilização em Engenharia de Software
• “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
Eliane Martins - Instituto de Computação - UNICAMP
Histórico
1960
1970
1980
1990
2004(?)
???
Reutilização de linhas de código de um programa em outro
Reutilização de código comum (subrotinas)
Reutilização de funções genéricas (bibliotecas de funções)
OO: herança, composição / delegação
uso de interfaces (implementadas, em algumas linguagens,
por classes abstratas
Polimorfismo e ligação dinâmica (late binding): qqr implementação
da interface pode ser usada em tempo de execução
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 de
domínios de aplicações.
Componentes: reutilização de código executável, configurável, adaptável.
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]
Eliane Martins - Instituto de Computação - UNICAMP
Reutilizar: sim ou não?
• Vantagens:
Desenvolvimento acelerado pois custos com
desenvolvimento e validação são reduzidos
Conformidade com padrões
Maior confiabilidade, pois utilizam-se soluções já
experimentadas
Eliane Martins - Instituto de Computação - UNICAMP
Reutilizar: sim ou não?
• Dificuldades:
Seleção, recuperação e modificação de artefatos
reutilizáveis
Compreensão dos artefatos recuperados
Qualidade dos artefatos recuperados
Composição de aplicações a partir dos artefatos
recuperados
Sí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?
Eliane Martins - Instituto de Computação - UNICAMP
Reutilizar: sim ou não
Um caso de fracasso
Invasões mongóis no Japão (1274 – 1281)
Samurais atacam barco da tropa mongol
Eliane Martins - Instituto de Computação - UNICAMP
Reutilizar: sim ou não
Um caso de fracasso
Invasões mongóis no Japão (1274 – 1281)
• 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 chineses
fizeram-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
Eliane Martins - Instituto de Computação - UNICAMP
Reutilizar: sim ou não
Um caso de fracasso
Invasões mongóis no Japão (1274 – 1281)
• 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
Eliane Martins - Instituto de Computação - UNICAMP
Requisitos para reutilização
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
Eliane Martins - Instituto de Computação - UNICAMP
Níveis de Abstraçã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
Eliane Martins - Instituto de Computação - UNICAMP
Desenvolvimento baseado em componentes
(DBC)
• 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
Eliane Martins - Instituto de Computação - UNICAMP
Componente
• 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.
[Sommerville 2001, 14.1]
Eliane Martins - Instituto de Computação - UNICAMP
Notação
Forma expandida
Forma abreviada
UML 1.4
Componente
Interface
requerida
Interface
fornecida
«interface»
Interface_A
tipo Operação_A1 (tipo args)
tipo Operação_A2 (tipo args)
realiza
Componente
UML 2.0
Interface
fornecida
Interface
requerida
depende de
Componente
Eliane Martins -
«interface»
Interface_B
tipo Operação_C1 (tipo args)
Instituto de Computação - UNICAMPtipo Operação_C2 (tipo args)
Exemplo
ICancelaReserva
...
IFazReserva
Sistema de
reserva de hotel
ICobrança
...
IGerencia
Eliane Martins - Instituto de Computação - UNICAMP
Exemplo
ICancelaReserva
...
IFazReserva
Sistema de
reserva de hotel
ICobrança
«interface»
IFazReserva
getDetalhesHotel ( )
getInfoQuartos ( )
FazReserva ( )
...
IGerencia
«interface»
IGerencia
getDetalhesHotel ( )
getInfoQuartos ( )
Eliane Martins - Instituto de Computação - UNICAMP
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
Eliane Martins - Instituto de Computação - UNICAMP
Reutilização de componentes prontos – um processo
Identificar
componentes candidatos
Revisar as especificações
Avaliar o impacto
na arquitetura
Avaliar arquitetura
Negociar requisitos
[aceito]
Atualizar arquitetura
[inspirado em CompGov]
Eliane Martins - Instituto de Computação - UNICAMP
Reutilização de componentes prontos – um processo
Identificar
componentes candidatos
Avaliar o impacto
na arquitetura
Listar
componentes candidatos
Revisar as especificações
Selecionar componente
Levar em conta:
-Requisitos funcionais
- Atributos de qualidade
- Restrições de projeto
Avaliar arquitetura
Validar componente
Negociar requisitos
[aceito]
Atualizar arquitetura
[inspirado em CompGov]
Eliane Martins - Instituto de Computação - UNICAMP
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.
Eliane Martins - Instituto de Computação - UNICAMP
Reutilizar componentes: sim ou não?
• 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
Eliane Martins - Instituto de Computação - UNICAMP
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.
Eliane Martins - Instituto de Computação - UNICAMP
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
Eliane Martins - Instituto de Computação - UNICAMP
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
Eliane Martins - Instituto de Computação - UNICAMP
Frameworks  bibliotecas de classes
Aplicação
Framework
Bibliotecas
Aplicação
O controle da execução está
na aplicação que está sendo
construída
Inversão de controle: a aplicação
que utiliza o framework pode ser
invocada por ele
Eliane Martins - Instituto de Computação - UNICAMP
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
Eliane Martins - Instituto de Computação - UNICAMP
Exemplo de LPS
Caixa Eletrônico
Diagrama de características
Características obrigatórias
Identificação
do usuário
Emissão de
extrato
Ou exclusivo
Ou inclusivo
Toque
na tela
Leitura
de cartão
Tela
Característica opcional
Impressão
Características alternativas
W.M.Assis 2009, Dissertação de Mestrado, IC-Unicamp]
Eliane Martins - Instituto de Computação - 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
Eliane Martins - Instituto de Computação - UNICAMP
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]
Eliane Martins - Instituto de Computação - UNICAMP
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)
Eliane Martins - Instituto de Computação - UNICAMP
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]
Eliane Martins - Instituto de Computação - UNICAMP
Conceitos
Aplicação
Contrato
S
O
A
Serviço
Lógica do
negócio
Implementação
Dados
Repositório
de Serviços
Interface
Barramento
de Serviços
Eliane Martins - Instituto de Computação - UNICAMP
[Krafzig et al.2005]
Paradigma find-bind-execute
Repositório
de Serviços
Busca
(find)
Consumidor
de Serviços
Cliente
Publica
Conecta
(bind-execute)
barramento
Eliane Martins - Instituto de Computação - UNICAMP
Provedor
de Serviços
Serviço
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
Eliane Martins - Instituto de Computação - UNICAMP
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
Eliane Martins - Instituto de Computação - UNICAMP
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]
Eliane Martins - Instituto de Computação - UNICAMP
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.]
Eliane Martins - Instituto de Computação - UNICAMP
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
Eliane Martins - Instituto de Computação - UNICAMP
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].
Eliane Martins - Instituto de Computação - UNICAMP
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]
Eliane Martins - Instituto de Computação - UNICAMP
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.
Eliane Martins - Instituto de Computação - UNICAMP
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)
...
Eliane Martins - Instituto de Computação - UNICAMP
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.
Eliane Martins - Instituto de Computação - UNICAMP
Categorias de padrões
• 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
Eliane Martins - Instituto de Computação - UNICAMP
Categorias de padrões
• 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)
Eliane Martins - Instituto de Computação - UNICAMP
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
• Conseqüências
– Custos e benefícios da aplicação
do padrão
• Exemplos:
– Exemplos de aplicação
• Solução
– Descreve os elementos envolvidos,
suas responsabilidades e
colaborações
Eliane Martins - Instituto de Computação - UNICAMP
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
Eliane Martins - Instituto de Computação - UNICAMP
LocalizaçãoParty
dataInício: Date
dataTérmino: Date
*
*
subordinado a
Pessoa
Party
nome: String
*
empregado
*
Party
endereço: String
*
*
empregador
Organização
1
1..*
Cargo
1
*
Emprego
dataInício: Date
dataTérmino: Date
tipo
nomeações
1
Eliane Martins - Instituto de Computação - UNICAMP
1..*
NomeaçãoCargo
- dataInício: Date
- dataTérmino: Date
[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]
Eliane Martins - Instituto de Computação - UNICAMP
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]
Eliane Martins - Instituto de Computação - UNICAMP
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
Eliane Martins - Instituto de Computação - UNICAMP
Sumário dos principais pontos aprendidos
Eliane Martins - Instituto de Computação - UNICAMP