Antes de mais nada, vamos citar alguns conceitos importantes de BDD.

Estórias e Cenários

BDD é baseado em estórias e cenários, e para criarmos ambos, vamos seguir alguns padrões pré-definidos por autores de BDD. Uma vez que BDD é focado em comportamento e sequência, as estórias e cenários devem ter um formato rígido para que as ferramentas consigam entendê-los e interpretá-los.

As estórias, possuem o seguinte formato:

As I [X]
I want [Y]
so that [Z]

E os cenários possuem o seguinte formato:

Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.

Ou seja, isso quer dizer que devemos pensar em nossos requisitos de maneira que possam ser escritos baseados nessa convenção.

O JBehave é originalmente escrito para entender estórias em inglês, entretanto como BDD é focado em pessoas (stakeholders) e na descrição de situações reais, faz muito mais sentido semanticamente que as estórias e cenários sejam escritos em português e para resolver isso, usei uma contribuição do Emerson Macedo para que os cenários possam ser escritos e entendidos em português pelo JBehave.

Começando com o JBehave

O primeiro passo para utilização do JBehave, é fazer download do JAR do projeto e incluí-lo no classpath do seu projeto.

O próximo passo é escrever a estória juntamente com o cenário e para tal resolvi criar um exemplo simples para que o entendimento do conceito possa ser casado através do código a ser desenvolvido.

O exemplo escolhido é baseado no requisito: Compra de produtos em promoção com aviso por email. E é isso que nosso cenário BDD deve descrever.

Por questão de organização, resolvi quebrar a estória em 3 cenários diferentes, onde a primeira parte representa a verificação de produtos em promoção, a segunda representa a compra desses produtos e o terceiro é a finalização da compra e o envio de email. Então, a estória e os cenários ficaram assim:

Compra de produtos em promoção com aviso por email
 
Narrativa:
Como um usuário
Eu quero comprar produtos em promoção
E então receber um email de confirmação
 
Cenário: Verificar produtos em promoção
Dado Que uma loja possui 10 produtos
E Que 5 estão em promoção
Quando Eu verifico quais estão em promoção
Então Preencho minha sacola apenas com produtos em promoção
 
Cenário: Comprar produtos em promoção
Dado Que minha sacola de compras está preenchida com 5 produtos em promoção
Quando Eu verifico o somatório de produtos
Então Devo ter somente um total de 500 reais em produtos
 
Cenário: Enviar email
Dado Que minha sacola está preenchida de produtos
Quando Enviar um email de confirmação
Então Devo receber o status do envio "true"

A primeira linha do arquivo texto representa o título da nossa estória, o requisito de fato. A narrativa é um resumo do que essa estória deve cumprir e a seguir vem os três cenários, que no caso são as três etapas da estória.

É importante notar, que as palavras chaves em inglês (Given, When, Then, And) foram substituídas por palavras em português (Dado, Quando, Então, E).

Esse arquivo texto deve ser salvo com a extensão *.cenario e o seu nome está diretamente ligado a classe que irei criar no passo a seguir, que no caso é a classe que representa a estória e a associação com os cenários.

Criando a classe que irá comportar os cenários

Nesse passo irei criar a classe que irá apontar os cenários que compõe a estória e essa classe deve extender a classe Scenario do JBehave. Dessa forma, a classe ficaria assim:

PrecoPromocaoTeste.java

package scenario1;
 
import scenario1.steps.CompraSteps;
import scenario1.steps.EmailSteps;
import scenario1.steps.PromocaoSteps;
import scenario1.util.PtBRScenario;
 
public class PrecoPromocaoTeste extends PtBRScenario {
	public PrecoPromocaoTeste() {
           addSteps(new PromocaoSteps());
           addSteps(new CompraSteps());
           addSteps(new EmailSteps());
	}
}

No exemplo acima, estou extendo a classe PtBRScenario só para que a estória e o cenário sejam escritos em português, mas essa classa herda a classe Scenario como descrito anteriormente.

No construtor da classe, inclui os passos que a estória deve seguir para ser satisfeita e como quebrei a estória em três pedaços, precisei incluir três passos sequenciados.

Criando os passos da estória

Como a estória foi quebrada em três partes, se faz por necessário a criação de 3 classes que irão representar os passos da estória e todas essas classes devem herdar a classe Steps do JBehave.

Pela ordem definida na nossa classe de cenário, vamos aos passos:

PromocaoSteps.java

package scenario1.steps;
 
import java.util.List;
 
import junit.framework.Assert;
 
import org.jbehave.scenario.annotations.Given;
import org.jbehave.scenario.annotations.Then;
import org.jbehave.scenario.annotations.When;
 
import scenario1.entity.Loja;
import scenario1.entity.Produto;
import scenario1.util.PtBRSteps;
import scenario1.vo.Sacola;
 
public class PromocaoSteps extends PtBRSteps {	
	Loja loja 		= new Loja();
	Sacola sacola 	= new Sacola();
	List<Produto> listaProdutoPromocao;
	int quantidadeProdutoPromocao;
 
	@Given("Que uma loja possui $quant produtos")
	public void populaLoja(Integer quantidade) {
		loja.inicializaProdutos(quantidade);
	}	
 
	@Given("Que $quant estão em promoção")
	public void informaProdutosPromocao(Integer quantidade) {
		loja.colocaProdutosPromocao(quantidade);
		quantidadeProdutoPromocao = quantidade;
	}	
 
	@When("Eu verifico quais estão em promoção")
	public void verificaProdutosPromocao() {		
		listaProdutoPromocao = loja.retornaProdutosPromocao();
	}
 
	@Then("Preencho minha sacola apenas com produtos em promoção")
	public void populaSacola() {
		sacola.populaSacola(listaProdutoPromocao);
 
		Assert.assertEquals(listaProdutoPromocao.size(), quantidadeProdutoPromocao);
	}
}

CompraSteps.java

package scenario1.steps;
 
import java.util.ArrayList;
import java.util.List;
 
import junit.framework.Assert;
 
import org.jbehave.scenario.annotations.Given;
import org.jbehave.scenario.annotations.Then;
import org.jbehave.scenario.annotations.When;
 
import scenario1.entity.Produto;
import scenario1.util.PtBRSteps;
import scenario1.vo.Sacola;
 
public class CompraSteps extends PtBRSteps {
	Sacola sacola 				= new Sacola();
	double somatorioProdutos 	= 0d;
 
	@Given("Que minha sacola de compras está preenchida com $quant produtos em promoção")
	public void verificaSacola(Integer quantidade) {
		List<Produto> listaProduto = new ArrayList<Produto>();
 
		for (int i=1; i<=quantidade; i++) {
			Produto produto 	= new Produto();
			produto.preco 		= Math.round(Math.random()*100);
			produto.emPromocao 	= true;
 
			listaProduto.add(produto);
		}
 
		sacola.populaSacola(listaProduto);
	}
 
	@When("Eu verifico o somatório de produtos")
	public void verificaTotalProdutosSacola() {
		for ( Produto produto : sacola.retornaProdutos() ) {
			somatorioProdutos = produto.preco + somatorioProdutos;
		}
	}
 
	@Then("Devo ter somente um total de R$ $total reais em produtos")
	public void validaSacola(double totalProduto) {		
		if ( somatorioProdutos > totalProduto )
			Assert.fail("Total de produtos é acima de R$ 500");
	}
}

EmailSteps.java

package scenario1.steps;
 
import static org.jbehave.Ensure.ensureThat;
 
import org.jbehave.scenario.annotations.Given;
import org.jbehave.scenario.annotations.Then;
import org.jbehave.scenario.annotations.When;
 
import scenario1.util.PtBRSteps;
import scenario1.vo.Sacola;
 
import com.guilhermechapiewski.fluentmail.email.EmailMessage;
import com.guilhermechapiewski.fluentmail.transport.EmailTransportConfiguration;
 
public class EmailSteps extends PtBRSteps {
	Sacola sacola 		= new Sacola();
	Boolean statusEnvio = false;
 
	@Given("Que minha sacola está preenchida de produtos")
	public void verificaSacola() {
		System.out.println("Lista cheia..");
	}
 
	@When("Enviar um email de confirmação")
	public void enviaEmail() {
		EmailTransportConfiguration.configure("localhost", false, false, "", "");
 
		new EmailMessage()
	    	.from("eusou@marcuscavalcanti.net")
	    	.to("eusou@marcuscavalcanti.net")
	    	.withSubject("Testando BDD")
	    	.withBody("Testando terceiro cenário e o final da estória.")
	    	.send();
 
		statusEnvio = true;
	}
 
	@Then("Devo receber o status do envio \"$retorno\"")
	public void recebeStatusEnvio(String retorno) {	
		ensureThat(statusEnvio.toString().equals(retorno));
	}
}

Nos exemplos acima, que representam os passos de um cenário, é importante notar que os métodos seguem a ordem definida no arquivo texto, assim como todos são anotados com as palavras chaves correspondentes, no caso Given, When, And, Then. As anotações recebem como parâmetro as frases descritas no arquivo texto, excluindo apenas as palavras chaves no começo da frase, que estão devidamente representadas pelas anotações.

Os parâmetros são identificados com o formato $variavel, e uma vez que usamos esses parâmetros, devemos também colocá-los na assinatura dos métodos. Esses parâmetros são automaticamente capturados pelo JBehave através do uso de expressões regulares.

Executando o exemplo

Para executar o exemplo deve-se executar a classe que extende a classe Scenario do JBehave, nesse caso seria a classe PrecoPromocaoTeste.java, e para acompanhar os resultados, eu utilizo a integração do Eclipse com o JUnit, através de uma view própria da IDE.

No exemplo, usei ainda algumas classes auxiliares criadas especificamente para o exemplo, mas que não irei mostrar aqui os seus códigos para não tornar o tópico extenso demais. De qualquer forma, ao final desse tópico botarei um link para download do projeto no Eclipse que contém todos os códigos.

Observações finais

Um dos problemas que eu notei no JBehave é em relação a parametrização de alguns valores no arquivo texto para o código Java, em alguns casos isso pode se tornar um trabalho sacal e pouco produtivo, mas acredito que com a evolução do framework esse problema será resolvido.

Algumas pessoas utilizam alternativas variadas para resolver esse problema, como por exemplo criar o valor dos parâmetros diretamente como atributos nas classes que representam os passos. Eu particularmente não gosto dessa abordagem, pois acredito que isso faz com que os arquivos que descrevem os cenários percam seu valor e esses arquivos são essencial para utilização e sentido do BDD.

No exemplo citado, usei ainda algumas bibliotecas como FluentMailApi, Mail e Activation da JavaMail e Hamcrest. Essas bibliotecas servem basicamente para o envio de email e uso mais aperfeiçoado de expressões regulares por parte do JBehave.

Para finalizar, é importante citar que as classes do meu negócio (Sacola, Usuario, Loja, etc) foram construídas baseadas no meu requesito, no meu cenário, que foi a primeira etapa a ser elaborada na construção do exemplo.

Download

Para download do projeto completo no Eclipse, basta clicar aqui.

BDD ajuda você, BDD ajuda seu cliente

Um ponto que pude observar, é que usando BDD a possibilidade de um cliente participar de um projeto é imensa, mesmo que você não use alguma metodologia ágil (falarei sobre isso a seguir). E por que ele pode participar? É simples, pois é ele quem pode escrever os testes. Se ainda assim não for o seu cliente o responsável por escrever os testes, será ele quem irá validá-los, ou seja, você pode escrever os testes e pedir para que ele aprove ou não. Isso é muito importante, pois nesse caso os testes em BDD seriam o contrato entre você o seu cliente, entre o que você está entregando e o que ele está esperando.

BDD favorece o sucesso do uso de metodologias ágeis

Sem dúvida nenhuma um dos pontos fortes do uso de BDD é que suas características se encaixam muito bem em equipes que fazem o uso de metodologia ágil. E são vários pontos que favorecem.

Uma delas é a já citada participação do cliente, pois um dos requisitos para o sucesso do uso de metodologias ágeis é a participação e contribuição efetiva do cliente e no caso do uso de BDD ele pode participar diretamente, uma vez que é ele quem é o responsável (PO) por criar as estórias (ítens do backlog) e criar os testes de aceitação para as mesmas, onde tudo isso é usado no BDD.

Os artefatos que constituem BDD são muito, mais muito semelhantes aos artefatos presentes em ágil.

Em BDD se usa estórias e testes de aceitação, além de BDD favorecer a construção de aplicativos de forma evolutiva (sprints) e tudo isso casa perfeitamente com os requisitos das metodologias ágeis.

Favorece a escrita de testes antes da implementação

Uma boa prática na criação de testes, independente se você usa BDD ou TDD, é que os testes sejam criados antes de tudo. Ok, eu concordo, mas devo dizer que com TDD isso não é muito nítido, pois na maioria dos casos, principalmente no começo, as pessoas tendem a implementar os códigos e depois escreverem os testes para validá-los. Já com BDD, a primeira coisa que você precisa ter em mãos antes de implementar os testes são as estórias e os cenários, não tem como fugir disso, o que torna muito mais nítido que em primeiro lugar vem os testes e depois as implementações.

Torna mais nítido o que sua aplicação deve fazer

Com BDD é muito mais fácil isolar as funcionalidade da sua aplicação, já que o que é testado é exatamente isso, dessa forma fica fácil identificar os componentes que envolvem determinada funcionalidade, torna mais nítido qual é o papel daquela funcionalidade, além do que consegue dar um sentido melhor para a sua aplicação de maneira geral.

Com BDD, você consegue ainda uma visão de workflow da sua aplicação, ou seja, uma visão macro, o que favorece dar manutenção a mesma. Percebo também, que BDD favorece um bom design de código, evitando assim problemas de desenvolvimento como códigos com alto-acoplamento.

Torna os testes mais humanos

A essência do BDD são os cenários e não parte isoladas da aplicação e essa maneira de lidar com testes favorece o entendimento por parte de nós, humanos.

Testes de interface com o Selenium, tornam-se mais compreensíveis num contexto que envolva BDD, como em um teste de login, por exemplo.

Conclusão

Na minha opinião, está mais do que clara a vantagem no uso de BDD, entretanto ele não substitui o uso de TDD, pois a abordagem de ambas são diferentes e complementares.

No próximo tópico, irei mostrar um cenário de testes com o framework JBehave, um framework BDD para Java.

Mais sobre o assunto

The truth about DDD

The difference between TDD and BDD

Linguagens de programação tendem a ser parecidas com religião ou com times de futebol, a pessoa simplesmente escolhe uma e defende aquilo com todas as forças, geralmente de forma cega. Eu particularmente acredito que, para defender ou criticar algo, se faz por necessário conhecer profundamente aquilo que você defende ou critica, pois só assim você terá argumentos para apontar falhas ou reconhecer méritos. Sou, ainda, a favor da filosofia “cabeça aberta”, que em poucas palavras quer dizer: não tenha medo, muito menos preconceito, de conhecer algo novo, conheça para a partir disso você ter uma opinião formada se aquilo te agrada, ou não.

É comum acontecer em fóruns e em listas de discussão debates sobre “qual linguagem é melhor”, na maioria das vezes as pessoas atacam uma linguagem, ou defendem outra, simplesmente baseadas em sua opinião pessoal, ou melhor, baseados na falta de conhecimento. As pessoas não conseguem enxergar que todas têm seus prós e contras, como tudo na vida, e que a partir de uma situação real que é possível avaliar a melhor opção.

Eu comecei a programar através do PHP e hoje em dia trabalho basicamente só com Java. Programadores Java tendem a achar PHP um lixo, na maioria das vezes com embasamentos e teorias totalmente furadas, que demonstram tremenda falta de conhecimento. Eu concordo que o PHP tem uma má fama devido a linguagem ter demorado a amadurecer, como também concordo que o nível dos programadores em PHP no geral é baixo, é duro admitir, mas no geral é assim, provavelmente pela facilidade que a linguagem proporciona e também por sua curva de aprendizado ser bem mais baixa que a do Java, por exemplo. Mas isso quer dizer que o PHP é ruim? Eu poderia enumerar uma série de vantagens que o PHP tem em relação ao Java, da mesma forma que o Java tem uma série de outras vantagens em relação ao PHP, mas esse não é o foco do tópico, o foco é justamente o contrário.

Uma “nova” era

E para acabar, ou pelo menos ajudar bastante, surge o famoso framework Ruby on Rails, o hype do momento tratando-se de linguagem de programação! Ruby on Rails é um framework de desenvolvimento web que prega o conceito de que algo deve ser simples, prático e prazeroso de fazer, dessa forma inúmeros benefícios são alcançados, como: códigos com mais qualidade, tempo de desenvolvimento mais curto e comunidade participativa. Ruby on Rails não é uma linguagem de programação, é um framework, que foi desenvolvido em cima da linguagem Ruby, que é uma linguagem de programação criada por um japonês em 1995 baseada nos pontos fortes de várias linguagens da época. Reparou no trecho “…que havia de melhor em outras linguagens…”? Ou seja, o próprio criador da linguagem era (ou é) totalmente desprovido de preconceitos, e com isso conseguiu identificar os pontos fortes e fracos de várias linguagens com o intuito de criar uma, que no seu modo de ver, seria mais eficiente.

Complexidade não é sinal de qualidade

Uma linguagem de programação, um framework ou uma API, tem como principal objetivo (pelo menos deveria) fornecer uma maior praticidade aos desenvolvedores em solucionar problemas. Essa deveria ser a premissa básica para que uma determinada linguagem ou plataforma fosse adotada em um projeto, entretanto nada impede que N linguagens ou plataformas trabalhem de forma conjunta, desde que proporcionem alternativas para descomplicar o problema.

Só para esclarecer: simplicidade, praticidade, produtividade e facilidade nesse caso são sinônimos!

Outro ponto a ser observado é que a engenharia de software é um assunto relativamente novo, principalmente se formos comparar as outras engenharias, como a civil, e por isso é tão comum observarmos novas metodologias, padrões e linguagens surgindo a todo momento. Mas o que elas tem em comum é que todas tem como objetivo resolver os problemas da maneira “menos complexa” que for possível, é claro que outros fatores são levados em consideração, entretanto se paramos para pensar a simplicidade é sempre a prioridade.

E é por isso que o RoR está na crista da onda, pois talvez nenhum framework descomplique tanto as coisas como ele, e o melhor é que isso é contagioso, pois a todo momento surgem mais e mais frameworks “RoR like“, em PHP existe uma penca deles, como: Akelos, Code Igniter, Cake, Kohana. Até o sempre conservador Java se rendeu ao RoR e lançou o Groovy (JSR 241) e consequentemente o Grails, que é um framework web baseado em quem? No Rails!

Maçãs são maçãs e bananas são bananas!

O título acima parece estranho, mas ele serve para deixar claro o seguinte: comparar linguagens não é algo inteligente, ao invés disso, procure conhecê-las e tirar proveito do melhor de cada uma. PHP é PHP, Java é Java, Python é Python! Assim como maçãs são maçãs e bananas são bananas, portanto não cabem comparações. Parece óbvio, e na verdade é, mas mesmo assim existem pessoas que ainda insistem em levar essa discussão adiante, onde dificilmente é tirado algum proveito.

Só para deixar claro, eu nunca desenvolvi uma aplicação sequer usando o RoR, já usei alguns frameworks “RoR like” e tive ótimas experiências, entretanto não acho que o RoR substitui o Java, o PHP, ou até mesmo o .NET, como eu já disse, cada um tem o seu propósito e por isso deve haver um equilíbrio na tomada de decisões sobre “o que escolher?”, fatores como: experiência com determinada linguagem, documentação, maturidade, infra-estrutura, segurança não podem ser esquecidos de forma alguma, pois no final é a sinergia entre vários fatores que determina as opções a serem escolhidas.

É normal, e de certa forma até compreensível, nos deixarmos levar pela emoção de conhecer um novo mundo e com isso embarcamos no erro de que a partir daquele momento tudo será feito “daquela forma”, com “aquela nova linguagem”, e isso é um erro, dos graves! Nesse ponto, a experiência, o conhecimento e o equilíbrio fazem toda a diferença na tomada de decisão mais acertada.

Só para finalizar, gostaria de ressaltar que nada impede que existam linguagens e frameworks ruins, é claro que eles existem, mas mais uma vez, para termos essa certeza é preciso conhecer. Da mesma forma que, não é só porque devemos abrir a nossa cabeça e olharmos para os lados, ao invés de olharmos só para frente, que devemos deixar de considerar nossas preferências e aquilo com que temos mais facilidade. Preferência e preconceito não são sinônimos.

No final rolou uma rodada de perguntas, onde foram questionados assuntos como BDD, programação defensiva, contract by domain, dentre outras metodologias e padrões. Nesse ponto da apresentação, a maioria das pessoas que estavam presentes ficaram meio perdidas com as milhares de buzzwords associadas com as perguntas que foram feitas. O pessoal mais antigo ficou mais perdido ainda e até brincaram sobre a questão do “estamos ficando velho”.

Paralelamente a isso, começei a ler essa semana um livro do Tadeu Cruz sobre BPM e BPMS, onde no primeiro capítulo ele fala sobre a questão da desorganização informacional, muitas vezes causadas pelo excesso de informação e as novas ondas de TI que surgem a todo momento. Outra coisa que o autor do livro cita e crítica é que existem muitos casos de determinadas organizações, que forçam o uso de determinado software sem obter o real benenfício que esse software deveria oferecer, na maioria dos casos, por questões comerciais ou de interesse próprio dessas organizações. Questões como: para que determinada tecnologia foi criada, como deveria ser corretamente usada, como efetivamente está sendo usada, quais deveriam ser os resultados esperados do seu uso e quais são os resultados que estão sendo obtidos com sua utilização, orientariam de forma efetiva o profissional ou a organização com o intuito de medir se a adoção de determinada tecnologia está realmente sendo benéfica. Esse tipo de situação tem ocorrido muito com BPM, que é o novo hype do momento tratando-se de TI.

O que as duas histórias tem em comum e onde estou querendo chegar?

O que eu quero dizer é o seguinte: até onde vale apena conhecer N conceitos diferentes e até onde não vale a pena? Nos casos citados acima tem um pouco das duas coisas, bem como suas respostas. No caso específico do TDD, deveríamos considerar que o melhor a ser feito seria debater sobre as buzzwords que o assunto levantou, ou o melhor seria não conhecer muitos desses novos padrões e metodologias? Eu fico com a primeira opção, mas a segunda opção pode contradizer a primeira. Explico logo abaixo.

Vale a pena usar TDD e BDD em um projeto sem conhecer seus benefícios, o resultado a ser esperado e os possíveis obstáculos a serem vencidos? Não. Pois nesse caso tudo de positivo que TDD traria sendo usada da forma correta, traria inversamente em dobro no caso do seu mal uso, pois nesse caso o projeto acabaria tendo novos percalços (além dos já conhecidos), como: prazos atrasados, código mal estruturado, equipe perdida e etc. E isso acontece em larga escala em TI, não apenas no caso específico do TDD, já que o mais se vê são empresas gastando milhões em “soluções” de TI (CRM, ERP, BI, etc) – muitas vezes empurradas pelos ótimos vendedores dos grandes players do mercado – sem obter benefício algum sobre aquilo (ou até mesmo desconhecendo o porquê do seu uso). Na verdade muito pelo contrário, pois como muito desses processos são feitos sem estruturação alguma e demoram meses, anos… no final das contas a dor de cabeça e o custo envolvido não atingem nem de perto o custo x benefício esperado sobre aquele investimento.

Outro fênomeno interessante a ser observado e que de certa maneira ligam as duas histórias é a infobia. Infobia é uma palavra que o Tadeu Cruz usa para definir o medo por informação, ou seja, em determinado momento, com a enxurrada de tantas buzzwords, as pessoas acabam ficando reativas em absorver novas tecnologias e entender o seu significado, com isso de certa forma ficam estagnadas, pois deixam de absorver novos conhecimentos. Mas em compensação não adianta em nada conhecer várias palavrinhas mágicas superficialmente só para dizer que “domina” aquela tecnologia do momento. Por isso, acredito que dependendo do contexto, é válido ou não conhecer uma nova tecnologia. Esta aí mais um caso do paradoxo de TI. De certa forma, mas sem generalizar, a infobia consegue explicar a frase “estamos ficando velho”.

Devemos considerar que TI não irá salvar o mundo, TI pode ajudar de forma efetiva qualquer negócio de qualquer natureza, desde que seja aplicada da forma correta, e aplicar de forma correta envolve antes de mais nada: estruturação, disciplina, educação, mudança e planejamento. Ao mesmo tempo que sabemos de diversos casos onde TI trouxe um real benefício as organizações, sabemos de tantos outros onde TI acabou com negócios, projetos e sonhos. A bolha da internet talvez seja o melhor exemplo que ilustra essa situação das ondas de TI.

Muitas vezes as ondas de TI trazem a tona novas tecnologias que surgem apenas com o objetivo de remediar uma tecnologia já existente. O que as vezes é considerado como inovação, nada mais é que uma evolução de algo que tenha tido insucesso no passado, dessa forma uma tecnologia X surge apenas com o intuito de servir como “curativo” da tecnologia Y, que prometeu maravilhas e na verdade devido ao seu mal uso (ou não) só trouxe dores de cabeça.