Recomendação sobre o JBehave

{ September 14th, 2009 }

Autor: cmilfont

Minha recomendação sobre JBehave: use Cucumber!

Depois de quebrar cabeça para conseguir escrever histórias em Java eu resolvi trocar o Jbehave [java] pelo cucumber [ruby] em quase todos os projetos Java [falta só um projeto agora] e o resultado é uma pessoa mais feliz e menos trabalho para resolver coisas simples.

Não façam juízo de valores sobre uma linguagem ser superior a outra, isso não existe. A questão é que escrever os passos das histórias no Ruby é muito mais fácil pela natureza da linguagem, como os blocos. Até coisas simples como parsear listas de valores é algo muito complexo e leva tempo, aliás, parsear os parâmetros é sem dúvida o mais trabalhoso do JBehave.

Com JRuby e Cucumber você consegue utilizar o Storyrunner com facilidade, acessando sua API Java normalmente e tem também a integração natural com o Selenium.

Pretendo abordar esses assuntos no 3º encontro da XPCE no dia 24/10, até lá.

Posted in Behaviour Driven Development, DSL, Engenharia de Software, Metodologia, Métodos Ágeis, Ruby, teste ~ 4 Comments

CCT Março 2008 – DSL com Rhino

{ March 16th, 2008 }

Autor: cmilfont

Confirmamos mais um evento de alto nível do CEJUG no CCT de Março. Destaque para a excelente palestra ministrada pelo Dr. Vasco Furtado (blog aqui) sobre o Wikicrimes. A última palestra foi do coordenador Hildeberto que voltou da Bélgica para uns dias no Brasil.

Leonardo Ayres, Rafael Carneiro, Christiano Milfont, Vasco Furtado e Hildeberto Mendonça. Mais fotos do evento.

Posted in DSL, Fluent Interface, JSR223, Linguagens, Scripting, cejug, palestras ~ 1 Comment

Regras dinâmicas no Domain Model com linguagens de script

{ January 22nd, 2008 }

Autor: cmilfont

Trabalhar com Orientação a Objetos em aplicações comerciais é trabalhoso porque envolve necessariamente outros paradigmas (como bancos de dados relacionais), além de requisitos não funcionais da sua arquitetura (como segurança, concorrência, etc) impedindo uma modelagem pura. Em aplicações que realmente existem lógica de negócios e não apenas um conjunto de cadastros e relatórios, a utilização de uma abordagem com “Domain Driven Design” se faz necessária para a redução da complexidade no coração do software, ou seja, na camada responsável pelo modelo do negócio.

A abordagem de Domain Model proposta por Eric Evans, consegue isolar o núcleo do sistema (responsável pela lógica de manipulação das informações e processos de negócios) abstraindo das particularidades da arquitetura por meio de suas técnicas modernas e maduras. Mesmo assim o esforço de isolamento não é tão claro mesmo para coisas triviais como segurança, onde existe uma linha tênue entre o que é requisito funcional ou não.

Na construção do seu modelo, a profusão de abordagens como Fluent Interfaces e DSL ajudam a maximizar o entendimento do negócio, mas ainda assim restam dúvidas de como e onde aplicar adequadamente.

Confusão

Tenho visto muitos bons desenvolvedores caírem na onda do Hype e se tornarem fanboys “*-tards” e saírem por aí alegando que a linguagem X ou outra coisa qualquer é evolução do Java/C# ou coisas desse tipo, comparando linguagens de abordagens tão distintas entre si e até de paradigmas diferentes. Esse pessoal esquece “o porquê” de existirem tipos estáticos e dinâmicos, fortes e fracos. Uma linguagem funcional não é evolução de uma linguagem orientada a objetos, se bem que o vice-versa é contraditório porque alguns autores alegam que o object calculi seria evolução do lambda-calculi. Linguagens de tipos dinâmicos não são evolução de tipos estáticos, já existiam e servem para propósitos diferentes. Da mesma forma existem JAVAtards que esquecem que existem outras funcionalidades que Java não implementa (lembre-se que você não cria um MapReduce sem conhecimentos profundos de programação funcional).

O ponto principal é que os tipos estáticos são importantes em linguagens imperativas e são importantes na definição da camada de negócio, mas linguagens dinâmicas também o são, pela agilidade nas mudanças e na complexidade da arquitetura. Imagine o custo de um deploy para cada refactoring e mudança em uma arquitetura JEE e compare com o mesmo nível de complexidade de mudança em PHP ou Ruby.

O mais comum ultimamente é a divisão da camada de negócios em duas zonas distintas: uma estática, implementada com uma linguagem estática e fortemente tipada como Java; e uma dinâmica, implementada com o sabor de script que você goste, como ruby, javascript ou python.

Camada estática

Existem princípios em qualquer negócio que por mais ágil que esse negócio seja e mude constantemente, esses princípios nunca mudam, são aquelas funcionalidades facilmente detectadas na modelagem tradicional, onde se detecta o caminho principal de um ator pelo caso de uso e podemos prever os caminhos alternativos.

Alguns pseudoanalistas imaginam que todas as funcionalidades se revelam na modelagem tradicional e se não cobriu todas as possibilidades é porque falhou o processo de desenvolvimento. Essas funcionalidades facilmente detectáveis e controláveis fazem parte da camada estática do seu modelo, não devem mudar nunca ou muito pouco em relação à vida útil do software.

Imagine um sistema contábil, os princípios de crédito e débito, plano de contas, livros contábeis, a própria operação de contabilização a partir de documentos entre outros aspectos são os mesmos há uns 200 anos e mudaram muito pouco nesse tempo todo. Falo sobretudo da contabilidade fiscal. Uma modelagem desses princípios vai sofrer pouca alteração durante toda a vida útil do software.

Imagine o sistema jurídico, é praticamente o mesmo dos romanos. Imagine um sistema de vendas, desde a troca de sal por um carneiro, surgimento da moeda ao cartão de crédito, os princípios são os mesmos.

Para implementar essa camada, uma linguagem de tipos fortes e estáticos é o mais indicado.

Camada dinâmica

Agora imagine toda a contabilidade gerencial que é realizada com base na contabilidade fiscal. Imagine todas as operações possíveis e combinações imaginárias de vendas. Todos os cálculos de impostos que os governos mudam todo ano. A análise e modelagem total dos casos de usos é praticamente impossível e se mostrou inviável ao longo do tempo.

Alguém pode sugerir a utilização de métodos ágeis para solucionar esse problema em linguagens estáticas mas não é o bastante. Os métodos ágeis surgiram para prepararem as equipes para as mudanças, suavizar o impacto que refactoring causam no código. Observem que estamos falando apenas de negócio, puro negócio. Os métodos ágeis não dizem como fazer o seu código, eles te auxiliam.

A abordagem de utilizar uma linguagem dinâmica para esses requisitos mutáveis e tardiamente diagnosticáveis se mostrou eficientíssima. Isolamos parte do Domain Model para ser provido de uma linguagem dinâmica (de script de preferência), e concentramos na facilidade de montar um idioma comum para a equipe sem o custo de build ou deploy de linguagens estáticas.

Segmentação

Dividimos então essa camada dinâmica em duas camadas interiores: uma da própria linguagem dinâmica que facilita as modificações ágeis (aconselhavelmente com Fluent Interfaces); e outra mais rebuscada, criada para a criação de regras (DSL com ou sem Fluent Interfaces) e uma linguagem comum entre a equipe e os operadores do sistema que são geralmente não técnicos mas treinados para isso.

Implementação

Trabalhemos com esse pequeno exemplo, tenho uma operação fecharVenda de uma hipotetica classe Venda que entre suas responsabilidades, existe a geração de comissão do vendedor.

1
2
3
4
5
6
7

public void fecharVenda() {
 ...
	//pre-execução
 	this.vendedor.setComissao(this.valorTotal * (5/100) );
	//pos-execução
...
}

Agora imagine que surgiu uma modificação no sistema, existem dois percentuais diferentes. Isso é moleza, você refatora a operação com a modificação:

1
2
3
4
5
6
7
8
9
10
11
12
13

public void fecharVenda() {
 ...
 
	//pre-execução
	if(this.tipo.equals("VendaTipo1"))
		this.vendedor.setComissao(this.valorTotal * (5/100) );
	}
	if(this.tipo.equals("VendaTipo2"))
		this.vendedor.setComissao(this.valorTotal * (8/100) );
	}
	//pos-execução
...
}

Ah! Mas eu sou esperto, criei uma propriedade lá que amarro o tipo de documento com o percentual apropriado:

1
2
3
4
5
6
7
8

public void fecharVenda() {
 ...
	//pre-execução
	this.vendedor.setComissao(this.valorTotal 
                   * this.vendedor.getPercentualApropriado() );
	//pos-execução
...
}

Daí chega o seu cliente todo fogoso e diz que a regra mudou, agora não é mais no total da nota e sim nos ítens, cada item pode ter um percentual diferente. O caminho mais usual é você refatorar o item e copiar a propriedade para lá, percorrer todos os produtos no método fecharVenda e calcular a comissão, claro, deixando a abordagem atual comentada caso o cliente deseje voltar como era antes.

Usando uma linguagem de Script

Observe no comentário //pre e //pos execução, que acha de injetar uma chamada a um script no método?

Você faria essa última modificação assim em javascript (com Rhino):

Chamada ao Script que será injetado no modelo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

ScriptEngineManager factory = new ScriptEngineManager();
ScriptEngine engine = factory.getEngineByName("JavaScript");
try {
	engine.put("lista", this.itens);
	engine.put("vendedor", this.vendedor);
	engine.put("nf", this);
	engine.put("total", this.total);
	engine.put("totalDescontos", this.totalDescontos);
	String path = NotaFiscal.class.getResource("script.js").getPath();
	engine.eval(new FileReader(path));
	this.total = (Double) engine.get("total");
	this.totalDescontos = (Double) engine.get("totalDescontos");
} catch (ScriptException e) {
	e.printStackTrace();
} catch (FileNotFoundException e) {
	e.printStackTrace();
}

Código no script.js:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

(function() {
	var _$ = function(els) {
		this.elements = [];
		var iterator = els.iterator();
		while(iterator.hasNext()) {
			this.elements.push(iterator.next());
		}
		return this;
	};
	_$.prototype = {
		each: function(fn) {
			for ( var i = 0, len = this.elements.length; i < len; ++i ) {
				fn.call(this, this.elements[i]);
			};
			return this;
		},
		comissionar:function(vendedor) {
			var comissao = function(e) {
				vendedor.comissao += (e.total * e.percentual);
			}
			this.each(comissao);
		}
	};
	$ = function() {
		return new _$(arguments[0]);
	};
}());
$('lista').comissionar();

Fortemente inspirado no código do prototype resolvi o problema temporariamente sem precisar refatorar o código da aplicação e deixei aberto para quantas modificações forem necessárias nessa parte que é variável.

Posted in DSL, Engenharia de Software, Fluent Interface, Java, Linguagens, Melhores práticas, Orientação a Objetos ~ 16 Comments