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

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

Eliane Martins - Instituto de Computação - UNICAMP Reutilização de software Nov/2005.

Apresentações semelhantes


Apresentação em tema: "Eliane Martins - Instituto de Computação - UNICAMP Reutilização de software Nov/2005."— Transcrição da apresentação:

1 Eliane Martins - Instituto de Computação - UNICAMP Reutilização de software Nov/2005

2 Eliane Martins - Instituto de Computação - UNICAMP 2 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

3 Eliane Martins - Instituto de Computação - UNICAMP 3 Referências E. Bezerra. Princípios de Análise e Projeto de Sistemas com UML. Editora Campus, 2a. Edição, 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, JANDL, P. Jr. Uma Introdução aos Padrões de Projeto com Java Obtido na Internet em ago/2005. PRESSMAN, R.S. Sw Engineering: a Practitioners Approach. McGraw- Hill, 4ª ed, 1997, c.26. SOMMERVILLE, I.. Sw Engineering, 6ª ed, 2001, cap14.

4 Eliane Martins - Instituto de Computação - UNICAMP 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

5 Eliane Martins - Instituto de Computação - UNICAMP 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

6 Eliane Martins - Instituto de Computação - UNICAMP 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

7 Eliane Martins - Instituto de Computação - UNICAMP Histórico 1960Reutilização de linhas de código de um programa em outro 1970 Reutilização de código comum (subrotinas) Reutilização de funções genéricas (bibliotecas de funções) 1980OO: 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 1990Padrõ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. 2004(?)Serviço: reutilização de unidade autônoma de execução (função de negócio). ??? [Jacques Sauvé 2002:

8 Eliane Martins - Instituto de Computação - UNICAMP 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 Reutilizar: sim ou não?

9 Eliane Martins - Instituto de Computação - UNICAMP 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? Reutilizar: sim ou não?

10 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

11 Eliane Martins - Instituto de Computação - UNICAMP Reutilizar: sim ou não Um caso de fracasso Kublai Khan, neto de Genghis Khan, decide invadir o Japão após ter conquistado China e Coréia 1ª invasão: 800 barcos, 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 Invasões mongóis no Japão (1274 – 1281) Fonte:http://wapedia.mobi/pt/Invasão_mongol_do_Japão, maio/2009

12 Eliane Martins - Instituto de Computação - UNICAMP Reutilizar: sim ou não Um caso de fracasso 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 Invasões mongóis no Japão (1274 – 1281)

13 Eliane Martins - Instituto de Computação - UNICAMP 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

14 Eliane Martins - Instituto de Computação - UNICAMP 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

15 Eliane Martins - Instituto de Computação - UNICAMP 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)

16 Eliane Martins - Instituto de Computação - UNICAMP 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]

17 Eliane Martins - Instituto de Computação - UNICAMP Notação Componente Interface fornecida Interface requerida UML 1.4 UML 2.0 Interface fornecida Interface requerida 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

18 Eliane Martins - Instituto de Computação - UNICAMP Exemplo Sistema de reserva de hotel... IFazReserva ICancelaReserva... ICobrança IGerencia

19 Eliane Martins - Instituto de Computação - UNICAMP Exemplo Sistema de reserva de hotel... IFazReserva ICancelaReserva... ICobrança IGerencia «interface» IGerencia getDetalhesHotel ( ) getInfoQuartos ( ) «interface» IFazReserva getDetalhesHotel ( ) getInfoQuartos ( ) FazReserva ( ) usa

20 Eliane Martins - Instituto de Computação - UNICAMP 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

21 Eliane Martins - Instituto de Computação - UNICAMP 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]

22 Eliane Martins - Instituto de Computação - UNICAMP 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]

23 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)http://www.iconcomp.com/catalysis D. D'Souza e A. A. Wills –KobrA C.Atkinson et al.

24 Eliane Martins - Instituto de Computação - UNICAMP 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?

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

26 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

27 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

28 Eliane Martins - Instituto de Computação - UNICAMP 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

29 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

30 Eliane Martins - Instituto de Computação - UNICAMP 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 opcional Ou exclusivo Ou inclusivo W.M.Assis 2009, Dissertação de Mestrado, IC-Unicamp]

31 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

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

33 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)

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

35 Eliane Martins - Instituto de Computação - UNICAMP Conceitos SOASOA Serviço Aplicação Repositório de Serviços Barramento de Serviços Contrato Implementação Interface Lógica do negócio Dados [Krafzig et al.2005]

36 Eliane Martins - Instituto de Computação - UNICAMP Paradigma find-bind-execute Repositório de Serviços Consumidor de Serviços Provedor de Serviços ClienteServiço Busca (find) Publica barramento Conecta (bind-execute)

37 Eliane Martins - Instituto de Computação - UNICAMP 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

38 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

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

40 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.]

41 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

42 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, > 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].

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

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

45 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)...

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

47 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

48 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)

49 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 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

50 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

51 Eliane Martins - Instituto de Computação - UNICAMP Party endereço: String LocalizaçãoParty dataInício: Date dataTérmino: Date Pessoa Cargo NomeaçãoCargo - dataInício: Date - dataTérmino: Date Party nome: String Organização subordinado a * * ** empregado empregador * 1 1..* Emprego dataInício: Date dataTérmino: Date tipo 1 1..* 1 * nomeações [Bezerra 2007]

52 Eliane Martins - Instituto de Computação - UNICAMP 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]

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

54 Eliane Martins - Instituto de Computação - UNICAMP Padrões de software: utilizar ou não? –Para melhorar a estrutura de algo já implementado, quando o domínio do problema está bem compreendido –Podem melhorar a compreensão do código melhorando a modularidade, separação de conceitos e simplicidade de descrição ex.: é mais fácil dizer: utiliza-se uma instância do padrão Visitor do que " este é um código que varre a estrutura e realiza chamadas a alguns métodos em uma ordem particular e de uma determinada forma ". –Utilize padrões somente para resolver problemas já identificados no projeto/código pois... –... podem diminuir a capacidade de compreensão ao introduzir acesso indireto e aumentar a quantidade de código

55 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 Padrões de projeto, Idiomas e Frameworks –ttp://www.cs.wustl.edu/~schmidt/patterns.html Apresentação geral sobre padrões –http://www.mindspring.com/~mgrand/pattern_synopses.htm

56 Eliane Martins - Instituto de Computação - UNICAMP Sumário dos principais pontos aprendidos

57 Eliane Martins - Instituto de Computação - UNICAMP Exemplo – padrão de teste de regressão Nome: –Teste de caso de uso de maior risco Problema –Útil quando não se dispõe de tempo, recursos ou pessoal suficiente para reaplicar todos os testes Solução –Usar critérios de risco para avaliar os casos de uso a serem testados –Aplicar os critérios para obter o subconjunto de testes a ser reaplicado –Usar como oráculo os resultados do conjunto de testes aplicado anteriormente –Critérios de entrada: Delta já foram testados Conjunto de testes previamente aplicados já existe Matriz associando casos de uso aos casos de teste foi criada O ambiente de testes já foi configurado igual aos dos testes prévios –Critérios de saída Todos os testes selecionados foram aplicados e os bugs devidamente registrados Conseqüências –Risco moderado de não revelar uma falha de regressão –Baixo custo de análise para seleção de casos de teste... [Binder 2000, c.15]


Carregar ppt "Eliane Martins - Instituto de Computação - UNICAMP Reutilização de software Nov/2005."

Apresentações semelhantes


Anúncios Google