Hoje existem algumas poucas tentativas para isto. A mais conhecida é o uso de REST. A ideia é ter um web server/container que provê respostas as URL. Então, um aplicativo independente pode ser criado para utilizar essas interações HTTP para produzir funcionalidade agregada e “bonita” naquilo que se está chamando de rich cliente (“cliente rico”). Ok. Só tem um detalhe. Se a aplicação quiser otimizar ou prover uma funcionalidade nova não é possível sem modificação da contraparte REST. Podemos argumentar que a otimização é um problema que pode ser deixado para ultimo e/ou não levado em consideração numa primeira analise. Afinal os browsers são otimizados paras as mesmas respostas HTTP sem saber bem o que vem do outro lado. Coisas como zipar o conteúdo ou controlar o cache de respostas dadas pelo servidor podem ser controlados pelo servidor e desabilitadas pelo browser. Funciona. Mas sempre tem aquele cookie que vc precisa aceitar. Ou seja, estado. O browser precisa armazenar estado para otimizar a comunicação.

Mas REST vai contra isto de estado. Ok. Neste cenário poderíamos implementar um UI em javascript e uma em Swing e tudo estaria correto do ponto de vista da independência parcial. O servidor é livre de prover mais funcionalidades a qualquer momento e o cliente de as usar. O cliente é livre de deixar o usuário brincar com o dados e janelas como quiser. Claro que o cliente não pode criar funcionalidade do zero, mas pode- por exemplo – fazer o mashup de vários servidores para chegar em um cliente interessante. Por exemplo, integrar o google maps com o REST de cadastro de lojas. O detalhe é que nestes mashups o cliente vira a aplicação, o servidor de dados REST é apenas um Banco de Dados virtualizado num URL. Esta é exatamente a arquitetura que o Android usa, com a diferença que os dados podem ficar no próprio aparelho. Mas vc é livre de usar os dados de um aplicativo em outro (dadas as permissões, etc…) Ou seja, as camadas do “DAO para baixo” são expostas como REST e as camadas para cima como uma aplicação diferente. O Business fica em algum lugar no meio. Podemos ter REST que salvam, validam, dão update, etc.. mas podemos deixar todas as regras de validação na aplicação e usar o REST como um dao burro. “Podemos” – não quer dizer que é a melhor forma ou a mais usada. Depende muito se os dados são read-only ou write-almost-never ou se é um serviço transacional pesado como são telas de cadastro.

Bom, isto é uma solução possível nos nosso dias. Passa por alguns pontos interessantes, mas não é bem o que eu estava pensando quando falei do padrão Bridge (Mediator). O padrão Mediator seria mais no nível do código/ bibliotecas/ camadas, à semelhança do JDBC por exemplo.  Pense assim, o JDBC está para o banco de dados como este mediador de UI está para  a ui. O “driver” seria a implementação da API do mediador para a tecnologia de view em causa. O “driver” deveria permitir três coisas básicas : dirigir o fluxo ,  coletar/apresentar dados, responder a eventos. Note-se que estes eventos, dados e diretor de fluxo são levantados pela UI verdadeira ( struts, jsf, etc… ) mas tudo é canalizado para este “driver” invertido” de forma que o mediator possa entender os dados e comunicar com o outro lado dos business.

Se você entendeu o que falei , vc deve estar pensando “mas isso é o que a action do struts faz”. Sim. É o que ela faz. Assim como o managed bean do jsf e outros objetos que cumpre este papel em outro frameworks. Estes objetos são um pouco business delegate ( porque contêm algumas regras de negocio) e um pouco view controler porque dirigem o fluxo.

As peças são mais ou menos obvias e se virmos com atenção estão presentes em todos estes frameworks “compativeis”. Para começar temos o Dispatcher. Este é o cara que trata a navegação. Começa com o próprio dispatecher da Servlet API pura até ao próprio struts em si mesmo. E todos os frameworks web usam isto, afinal tem que ser possível pular de um URL para outro dentro do servidor (forward) ou instruir o browser a pular para outro URL (redirect). Basta termos um objeto POJO -like que não use construtos muitocomplexos (apenas, por exemplo, simples strings ou enums de algum tipo ) para pular para outro “cena”. Este conceito de “cena” em vez de janela ou página ajuda a pensar que o usuário irá ver outra coisa, sem sabermos onde a irá ver.  Para pegar dados o velho padrão View Object é simples de usar e com os recursos de atuais é  o que já usamos. Se bem que adoramos usar as entidades de banco de dados para este fim, mas nada mais se trata do que capturar todos os parâmetros em um POJO e deixar o framework implementar os detalhes da copia, conversão, etc.. Para responder a eventos temos aquilo que definimos como “actions” que podemos entender como métodos em que o nome do método corresponde com a ação. Obviamente este mapeamento acontece na real implementação da view, mas os métodos do mediador são sempre os mesmos.

Quase todos os objetos que identificamos como “actions” se comportam assim e têm estes acessos a API semelhantes. Se enxergarmos do ponto de vista do mediador para fora em direção ao browser iremos enxergar que um conjunto de padrões de uso se repetem, da mesma forma que enxergamos do business em direção do DB que muitos padrões de uso se repetem. Quando estamos na camada de business e olhamos o banco de dados que fica na camada de recursos e nada mais é que o um arquivo glorificado, pensamos na camada de integração onde ficam coisas como o JDBC, JPA e companhia. Quando olhamos da  camada de business em direção ao usuário que está usando a camada cliente pensamos na camada de apresentação no meio.  Normalmente pensamos no cliente como o browser e na camada de apresentação como o struts/spring MVC/ JSF. Contudo sabemos bem que devido a coisas como Ajax, REST, javascript estas partes ( browser – framework web) não são separáveis. Não com um corte limpo.  Mas se pensarmos que na realidade “browser+framework web” são o cliente ficamos com um camada inteira para desacoplar e manter desacoplada. O que significa muito espaço de manobra. Afinal a camada de apresentação não deve depender do cliente (camadas são independentes e se B sucede a A , B não pode depender de A.)

Dito de outra forma. Ou todo o mundo está violando a separação de camadas por fazer a camada de apresentação conhecer o cliente ( o que é sacrilégio já que ninguém aceitaria fazer depender o DAO do business) ou ninguém está usando a camada de apresentação de fato.  Claro que sabemos que a primeira é verdade já que todos assumimos usar duas camadas e todos assumimos que a nossa implementação web depende do browser, mas podemos pensar que afinal não estamos violando nada e usando a segunda.

Para os mais atentos deve ficar o gosto de que estamos repetindo as mesmas “ações” nesta camada de apresentação que repetimos nos frameworks web. Bom, no estado que é hoje sim. Afinal as responsabilidades são semelhantes. Mas se pensarmos na implementação da camada de apresentação como a verdadeira implementação destes padrões ( view object, dispatecher, observer) e as tecnologias web como meras canalizações – meros “drivers”- , então tanto faz à camada de apresentação se o usuário apertou um botão no browser ou uma imagem no swing (ou vice-versa) : o que interessa é a intenção chamada “salvar”  ou “calcular” etc…Afinal são estas intenções que o sistema entende (como no caso do REST ele só entender update, post, get, put, delete) e tanto faz , quem, como ou quanto foram chamadas.

Este design ainda não responde a todas as questões como “como populo um table a partir de uma tabela” e como mudar o struts pelo ZK, por exemplo, mas acho que abre uma porta sem realmente inventar nada e apenas vendo o que temos com outros olhos. E com essa porta começar a pensar como seria a implementação de algo assim.

Aguardo as vossas opiniões sobre o conceito e comentários.

Portanto pese embora o esforço da Sun e depois da Oracle em empurrar o  JavaFX como alternativa visual para o java substituindo em cada plataforma a forma nativa de UI e UX (user experience) o tempo e a concorrencia parecem ter ganho a batalha inicial. O JavaFX perdeu no campo dos celulares e tabblets  para o Android  e foi proibido no iPhone e iPad. Na Web perdeu para o HTML 5 e no desktop … bom, quem usar desktop em java , afinal ?

O JavaFX foi criado para competir com o Flash e o Silverlight. Mas a Revolta dos Plugins iniciada pela Apple e seguida pela Mozilla e agora pela Microsoft em proibir o uso de plugins em browsers e suportar HTML 5 em vez, matou o Flash e o Silverlight antes sequer do FX vingar como competidor nesse campo. É como se o campo de batalha tivesse sido removido e o Fx chega todo armado até aos dentes para encontrar um vácuo onde nada existe mais. A alternativa é ainda vender o FX para celulares e o JME 3 com equiparação JSE 7 (uau!) e com isso criar aplicativos iguais ou melhores que os dos android ou iphone. No andoid a gerra esta perdida, quanto a mim, mas no mundo do iphone ainda ha esperança de vermos um compilador nativo que  compila um jar junto com a JVM e joga tudo em formato binário indistinguível daquele que o  SDK da Apple gera. No desktop poderíamos ver o uso do JWS para difundir novos aplicativos RIA. Com o projeto jigsaw do java 8 isto é ainda é uma possibilidade real para aplicativos, sobretudo se o JWS poder ser instalado via os  Markets da vida seria uma forma, quase viral, de trazer o java de volta tanto no mercado corporativo como no mercado publico.  O JWS é de fato o avô do conceito de Market, e hoje que todo mundo entende o conceito seria muitos mais simples vender o conceito de aplicações instaláveis remotamente. Os novos applets seriam servidos por Markets e não por simples Browsers.

A promessa de um cross-compiler de javaFX para HTML 5 seria a opção matadora e a arquitetura do Fx 2 parece levar isto em consideração. Mas quando poderemos ver isso em produção e será mesmo que vai acontecer ? Estas duvidas tolham o processo de escolha.

Pessoalmente adoro trabalhar com Swing e acho  cem vezes mais produtivo do que qualquer coisa baseada em request-response. Portanto o Fx vem mesmo em boa hora. Mas é o futuro ?

Por outro lado, temos coisas com o Play Framework  que já prometer um novo mundo de programa em Java (ou scala) e corra onde quiser. Baseado em GWT e no compilador java-javascript a magia está pronta para acontecer. Mas e o vendor lock-in ?

O mesmo acontece com frameworks como o Wicket e o Vaadin que embora não prometam a integração HTML5 conseguem-se aproveitar dessa tecnologia e o programador apenas programa em Java (bom o Wicket ainda exige criar as páginas em HTML o que eu acho desproposital). As UI são swing-like e a UX é a de um aplicativo desktop. Não são tecnologia para usar em uma loja virtual, mas para sistema corporativos parecem bem decentes. Mais um vez, o problema do Vendor Lock -in aparece como um contra. Nem sempre as decisões arquiteturais dos criadores vão de encontro às necessidades e podemos assistir a um Struts novamente (sendo abandonado pelo seu primo Struts 2).

Se o Struts no ensinou algo é que não podemos abraçar a tecnologia emergente sem pensar nas consequências.  ninguém previu o abandono do Struts, cegos com a novidade as pessoas escolheram não ver os problemas arquiteturais que o Struts tinha. Relegado ao esquecimento e proibido de usar pelos seus próprios criadores na Apache que decidiram correr para o Struts 2. O mesmo aconteceu com o JSF 1.0 que foi modificado em tantas coisas para se transformar no JSF 2 ( quase tanto como o Fx 1 foi modificado para o Fx2). Nos dá a impressão que ainda não chegamos em um nível de maturidade  em frameworks web, mas está claro que frameworks request-response não dão conta do recado em ambiente corporativo onde ha necessidade forte de lidar com inputs e os writes são quase tantos quantos os reads.

Então, espelho meu, qual é a melhor view que eu ?

O Struts está acabado e qualquer um é melhor que ele. Os frameworks request-response são quase iguais em todos os aspetos, com o Spring MVC correndo na frente apenas porque integra o spring nativamente ( para os outros os spring é uma biblioteca de apoio e nao o core).  Estes frameworks nos dão o controle, mas não a view. Ai vem o JSP ou frameworks de formatação com o Freemarker e o Velocity. Bah! é tudo igual. Não ha componentes poderosos. Temos que os criar. Provavelmente em JQuery e usando alguma integração jquery-java muito louca.

Tiles, Sitemesh  e semelhantes não são frameworks de componentes e sim de template web. Utils para reorganizar o layout, mas inúteis para criar componentes ( não que não seja possível, mas ninguém faz isso)

Bom, parece que a cada uma que coloquemos diante do espelho, sempre existirá alguma melhor. O que fazer ?

A resposta é realmente simples, mas normalmente descartada facilmente pelos desenvolvedores.  A resposta é isolar a view. Afinal é um andar diferente na arquitetura e deve ser tratado como tal. Acontece que não é assim que as aplicações são desenvolvidas. Quantas aplicações você conhece ou fez em que pode mudar de struts para JSF e não perder as logicas de negocio ? Afinal, os programadores insistem em programar lógicas nas actions do struts ou nos managed beans do JSF, certo ? Como migrar isso. Impossível.

Este problema advém do mau entendimento e uso do padrão Bridge (também chamado Mediator). Este padrão é muito útil e a prova dele está na JDBC que é implementada com esse padrão. A ideia é que você tem duas partes do sistema A e B em que ambas podem evoluir independentemente uma da outra e sem causar alterações ou recompilações na outra. O design disto não é trivial e por isso mesmo seria ideal que um framework existisse que provesse esta arquitetura, e é deste santo graal que estamos à espera.

À priori todos concordam que não faz sentido mudar ou cria mais código em business para suportar uma tela que migrou para ajax. Se ela mudar para HTML 5 temos que mudar de novo ? e para JSF ? ou para FX ? Afinal o business depende da view ? Em tese não. Não prática sim, na avassaladora maioria dos casos. E é aqui está o custo de migração. E porque o custo de migração é alto a escolha prévia da tecnologia implica num alto risco.

A solução então é seguir a máxima da arquitetura moderna : deixe suas opções abertas. E a forma de testar se isso é verdade é implementar pelo menos 3 clientes diferentes para o seu andar de apresentação e usar o mesmo business para cada um.  Isto é o futuro. Porque assim, não importa qual a view que usar nem como os browsers vão evoluir, a sua aplicação ainda fará o mesmo.

Por outro lado, mudar de view é o que diferencia as versão de um software. Portanto, comercialmente é interessante evoluir a view a gosto da moda, mas financeiramente não é interessante reescrever as regras de negócio cada vez que fazemos isso. A única forma é portanto utilizar o padrão Bridge, isolar a view do resto e escolher a view do momento.

Fácil ? Não é fácil. Mas se fosse, qual seria o desafio ?

Curiosamente, todo sabem que esta é a resposta certa, mas rapidamente ela é descreditada com frases feitas como “Não temos tempo agora” , “Não está no escopo” , “Não temos orçamento” … tá. Mas temos orçamento para bancar os custos de manutenção em tecnologia obsoletas, e refazer a mesma coisa N vezes …

Esta dúvida sobre qual view é melhor não advém apenas da necessidade de escolhas para novos sistemas, mas também como dúvida sobre qual tipo de framework de view prover no MiddleHeaven. Por enquanto temos o feijão-com-arroz do JSP ou Freemarker, mas como disse isto não provê componentes nem manutenção fácil no futuro. A ideia de um padrão Bridge parece ser a única que faz sentido aqui , mas é muito fácil. O padrão de programação visual é Event Driven como o Swing, não importa como mascaremos isto, isto é o que queremos realmente usar.

Seria interessante ter o vosso feedback do que estão usando, prós e contras e se concordam que isolar a view é a forma segura de prosseguir.

Precorrendo a blogosfera me deparei com um excelente e engraçado artigo que aborda exatamente este problema. O artigo se utiliza da classificação de Alistair Cockburn baseada nos estágios do Aikido : Shu, Ha , Ri que se traduzem – segundo o texto – em algo como: Aprender, Desprender e Transcender.

O curioso aqui é que se enxergam 3 estágios. E poderíamos associá-los a : júnior, pleno e sênior respetivamente. Contudo estaríamos cometendo o mesmo erro que todos cometem que é tentar usar as palavras costumeiras para transmitir ideias diferentes. Para o pessoal de RH pleno não é uma capacidade é um cara que trabalha na área ha 2 ou 3 anos. Este erro grasso de vincular tempo com experiencia é o mesmo erro de vincular tempo com esforço. Tempo é tempo. Nada mais. O fato da pessoa passar 3 anos na área não diz nada sobre o seu nível.

Então, pensando em estágios, em níveis de evolução podemos utilizar os estágios do Aikido como base para definir 3 estágios: Aprendiz (Aprentice), Companheiro (Fellow) e Mestre (Master). Estes nomes – ou algo como eles – deveriam ser usados em vez de júnior/pleno/sênior.

O artigo ilustra bem o que significa cada um destes estágios. O Aprendiz quer aprender tudo e ainda é muito ingênuo no uso do que aprende e não ousa fugir das regras que lhe apresentaram. O Companheiro conhece as regras e sabe como utilizá-las para resolver os problemas. O problema aqui é que estando livre do arcabouço das regras que lhe foram passadas, pode facilmente cometer erros. Podemos dizer que o Aprendiz peca por falta enquanto o Companheiro peca por excesso.  Mestre não apenas utiliza as regras, ele cria novas regras. Novas ferramentas, novas ideias que serão o futuro da profissão. Entenda-se que Mestre aqui significa “aquele que domina a arte” e não “aquele que ensina”. Um Companheiro pode ser melhor professor que um Mestre. Não ha relação.

Por outro lado, o mundo da tecnologia é cheio de domínios para trabalhar. Alguém pode ser mestre em Orientação a Objetos mas ser um Aprendiz numa certa linguagem ou plataforma.  Então este adjetivos por si só não significam muito se não forem acompanhados dos domínios.

Um anuncio de emprego como “Procura-se Analista Desenvolvedor Sênior com domínio da linguagem java e conhecimento das tecnologias EE, HTML, XML, Spring, Hibernate (…) Desejável conhecimento em linux. ” significa” Procura-se profissional que atue à mais de 5 anos e tenha mestria no uso da tecnologia java. O profissional deve saber resolver problemas com as tecnologias EE , HTML (…) . Necessário aprendizado de linux”.

A segunda forma deixa claro o nível de evolução necessário. Pois “desejável linux” significa que se você sabe linux, você tem pontos a mais, mas se não sabe, se aceita que você aprenda.

O artigo vai mais longe que uma mera classificação explorando a psique de cada nível,  mas eu queria foca a classificação antes para deixar claro o que significa. A analise do comportamento e da psique (como a pessoa pensa sobre um problema/solução) é muito interessante também. A ingenuidade do aprendiz pode levar a um excesso de zelo o que leva à sobre-engenharia como querer usar todos os padrões de projeto em uma única classe ou caso de uso enquanto o “desprendimento” do Companheiro pode levar à displicência e ao uso de gambiarras sem respeito pelas diretivas e as regras do desenvolvimento. Por outro lado a mestria não é algo que se “auto-proclama” é necessários dar provas uma e outra vez e de certa forma está também relacionado a não deixar que ninguém se desvie do caminho criando formas mais simples e/ou mais fáceis de alcançar os mesmos objetivos de forma que os aprendizes e companheiros, ou mesmos outros mestres, não se sintam tentados pelo “lado negro”.

Não é fácil criar um personalidade profissional. Conduzir o seu trabalho conforme as regras e diretivas da profissão. Nem ajudar os outros a seguir o mesmo trilho. Contudo a valorização profissional passar por aqui: um caminho de aprendizado e de renuncia a más práticas. Seguir o trilho pode demorar anos ou décadas e por isso o tempo de “exposição”  não é relevante.

Por fim, gostaria de deixar claro que estes adjetivos não devem ofender ninguém. Se alguém é considerado aprendiz isso não o deve ofender, deve o informar de quais são seus próximos passos.

Um conceito complexo, e ao que parece, embora felizmente tem ainda quem entende lógica para saber a diferença , ainda ha muitos que não sabem.

Então decidi esclarecer um pouco melhor a diferença, em certa medida a causa, de porque tanta confusão. O porquê de tanta confusão é que existe um padrão muito parecido com o MVC mas que realmente têm que ver com camadas: O Entity-Control-Boundary. Em muitos lugares você vai ver as pessoas dizendo que o ECB é relacionado ao MVC de alguma forma [1] [2] o que não é verdade. Obviamente. Este é um caso de falsos gémeos.

O conceito do ECB é diferente do MVC no que tange à arquitetura, mas muito semelhante no que tange às responsabilidades. “Entity” representa a entidade. A “entidade” é um elemento prevalente, ou seja, ele existe mesmo quando o sistema está desligado. A entidade é normalmente persistente ou de alguma forma serializada em algum arquivo em algum lugar. A entidade representa estado, memória, conhecimento, e por isso é fácil entender porque ela deve ser/é persistente. “Control” representa o elemento que faz algo. Algoritmos, decisões e lógicas de diferentes tipos são feitas no âmbito do control. Não se trata de delegar e depois redirecional como no control do MVC, mas sim fazer algo. Decidir. “Boundary” representa a “fronteira”. O conceito de fronteira não tem que ver com apresentação, como a view, tem que ver com adaptação de impedância. Ou seja,
estabelecer uma comunicação entre o “mundo” e o control.

O padrão ECB é estabelecido na UML como uma forma genérica de representação destas três partes que se relacional ao básico de todos os programas
Input, Output, Processamento, Estados. Repare que os dados não fazem parte deste processo e são sempre transientes. Ou seja, apenas as entidades são persistidas e não
todo e qualquer objeto de dados que decidirmos criar. O control representa o processamento, a entidade o estado e o Input/Output a Fronteira.

O padrão Entidade-Controle-Fronteira é mais geral, genérico e de propósito e aplicação mais gerais que o MVC. O ECB é um padrão de arquitetura e o MVC de design. São de famílias diferentes.Lembrando que o MVC se restringe apenas a um andar que normalmente é o andar de apresentação. O ECB é usado para desenhar as funcionalidades como um todo e é especialmente util na tradução de casos de usos
e fluxo de interação.

A Fronteira (“Boundary”) é normalmente construída por um conjunto de classes, não apenas uma e representa uma responsabilidade macro e não uma responsabilidade
individual. É por isso que em UML não usado o simbolo de classe, mas um simbolo especial próprio.
Em sistemas web a fronteira seria o web contêiner inteiro. Em sistemas desktop seria todo o maquinário Swing com respetivos listeners e actions. Dito de outra forma
O MVC está dentro da Fronteira e é normalmente usado para realizá-la quando o usuário é um humano. Quando o usuário é outro sistema, a Fronteira se transforma
num mecanismo  semelhante a um serviço e menos MVC. Web services (SOAP ou REST) caem nesta categoria. Adaptadores como conectores a ESB também podem estar na fronteira.
Se pegarmos, por exemplo, a implementação de um driver JDBC a fronteira é toda a API JDBC com que o usuário pode interagir.

Da mesma forma, o Controle também é um conjunto de classes e não necessariamente uma classe apenas. Não é o mesmo que o Controlador do MVC. As classes de Controle
têm a responsabilidade de definir regras. Normalmente de negocio. Padrões uteis para implementar o Controle são Service, Validator, Specification, Strategy, Template Method e outros na linha de padrões relacionados
a algoritmos e controle. O Controle não realizações ações de direcionamento, isso é papel da Fronteira (“Bondary”), o que o Controle faz é decidir e realizar, normalmente isso significa manipular as entidades para criar ou modificar o estado.

As entidades são elementos passivos que são manipulados pelo Controle. Estes elementos são objetos que de alguma forma são persistidos. As classes de persistencia
como DAO , DomainStore e afins não fazem parte da entity. Podem fazer parte do controle ou serem consideradas classes auxiliares, mas não são conceitos do padrão ECB.

ECB e EJB

É interessante comparar o padrão ECB com o padrão tecnologico Enterprise Java Beans. O conceito do EJB é alicerçado em três tipos principais de objetos
Entity Beans, Session Beans e Message Beans. Onde os Session Beans podem se dividir em Statefull e Stateless. O padrão dos Session Beans e Message Beans é dividido em
contrato (interface java) e implementação (classe java). O padrão EJB com certeza não é a implementação do padrão MVC mas pode ser considerado uma implementação inspirada pelo ECB.
A Fronteira são as interfaces dos session e as filas associadas aos Message Beans. Esta é a parte “publica” que pode ser chamada por outros sistemas.
Todas a infraestrutura que realiza estas interfacess de forma a prover mecanismos remotos/ serialização que está contida no EJB container e é realizada pelo provedor do container que canaliza as chamadas para a implementação.
As implementações dos objetos Session e Message Beans correspondem com a implementação do Controle. Os objetos Entity Beans no padrão antes do EJB 3.0 tinham duas funções: a de representar o estado,
e a de representar as pesquisas sobre o estado. Atualmente esta responsabilidade é separa entre os POJO que são o estado e os métodos de pesquisa do DomainStore que permite consultar
este estado. O padrão EJB é um uso direto do padrão ECB.

ECB e Camadas

Como falei, cada parte do ECB representa um conjunto de objetos que trabalham junto para um fim. O nome de que se dá a este conjunto de objetos é : Camada.
Camada é também usado como sinónimo de Andar que além de representar um conjunto de camadas representa um elemento de uma estrutura de pilha. Quando falamos de “Uma camada em cima da outra” fazendo alusão Às camadas de um bolo estamos abusando da linguagem e da metáfora.
A metáfora correta é a de andares uns em cima de outros e “camada” é apenas o nome de um conjunto de classes que colabora para um fim.
As classes do ECB além de formarem camadas podem também formar andares já que a comunicação só se dá em uma direção entre as partes: B->C->E.  Esta é a comunicação
que esperamos entre camadas.

ECB e MVC

O padrão MVC pode ser escrito usando o padrão ECB?  O ECB é um padrão arquitetural de responsabilidade e o MVC é um padrão de design também baseado em responsabilidade. A diferença parece minima.

A diferença é muito grande e muito maior do que parece. Além dos dois padrões não se referirem às mesmas responsabilidade e sim a responsabilidades diferentes que infelizmente têm nomes muito parecidos

No padrão ECB a dependencia dos elementos é sequencial. O Controle não invoca a Fronteira nem a entidade invoca o Controle. No padrão não apenas o Model pode invocar o Controlador, como deve, assim o como o controlador deve invocar a View. A dependência dos elementos do MVC é um triangulo o ECB não. A analogia seria que o MVC é como os 3 poderes da politica em que cada um comunica com o outro e os 3 alcançam um objetivo, enquanto que o ECB é um padrão mais hierárquico em que, quem está em baixo é comandado por quem está em cima. Isto faz o ECB um mecanismo muito próximo do conceito de camada em pilha que o MVC nunca poderá ser devido às sua simetria triangular.

O MVC não pode ser escrito como sendo um caso do ECB. Sim, muitos sites e autores tentarão vender isso para você do mesmo jeito que tentam vender que MVC é arquitetura por camadas. Espero que este post deixe claro que isso simplesmente não faz sentido nenhum. É como dizer que uma cebola é uma maçã apenas porque ambas são redondas.

O que sim acontece é que cada elemento do ECB é a coordenação de város objetos e  o MVC é um ótimo padrão para criar essa coordenação, especialmente na camada de Fronteira.

ECB e os 5 Andares

Em um sistema básico você vê claramente estas três camadas do ECB, mas em sistema mais completos você verá camadas adicionais. No modelo de 5 andares, por exemplo (Cliente, Apresentação, Domínio, Integração, Recursos” ), não existe uma única aplicação do padrão ECB mas três.

A primeira aplicação do ECB serve para controlar o motor de interação com o usuário. A segunda para controlar as regras do sistema/ negócio e a terceira para controlar as regras de dados e integração com outros sistemas fornecedores. No padrão de 5 andares , cada andar tem mais do que uma responsabilidade sob perspectivas diferentes. Os andares das pontas são os mais simples, sendo o andar de domínio o mais recheado de responsabilidade. Claro que é ai onde o “coração” do sistema existe.

O andar cliente – por exemplo um browser ou um applet – representa apenas uma Fronteira, normalmente implementada em MVC quando o usuário é um Humano.
A apresentação – o mecanismo de fluxo no web contêiner, por exemplo, normalmente em algo como Spring MVC ou JSF também tem responsabilidades de
fronteira e por isso o padrão MVC é comun ser usado. Contudo este andar também toma decisões que não são apenas de fluxo e apresentação. Algumas validações especiais e outras interações que deixam a interatividade maior, têm que corresponder com as regras do sistema/negocio e precisam ser controladas.É por isso que o objeto de control do MVC – o Controlador – assume também o papel de implementação do Controle, embora o padrão BusinessDelegate possa ser usado para diferenciar as duas responsabilidades. Por exemplo, no struts, uma action (controlador do MVC) pode chamar um outro objeto BusinessDelegate que contém apenas regras de negocio e portanto cumpre o papel do Controle do ECB.
Do outro lado temos o andar de Recursos. Recursos são dados persistidos em muito formatos (normalmente arquivo e banco de dados) e não ha mais nada aqui do isto: dados burros gravados em algum lugar em algum formato.
O andar de Integração detêm o papel de controle para “dados” o que significa toda a estrutura de JDBC, comunicação , DAO/DomainStore e inclusive triggers.
O papel entidade é representado pelos objetos que são enviados para persistência. A Entidade que representa o estado é a entidade do andar de Resources, a entidade do andar de integração é um (D)TO.
Hoje em dias os frameworks como o hibernate escondem a diferença de você, mas quem trabalhou com EJB pré 2.0 sabe que o uso de DTOs era comum e que o DTO não era a Entidade ( normalmente o DTO navegava entre os andares e o Entidade apenas existia no EJB Container)
E sobra o andar de domínio, também chamado de andar de negócio. Repare que este andar o padrão ECB está representado por completo, mas de diferentes fases.
A Entidade vida da fase de apresentação é normalmente um objeto no padrão DTO que foi tratado pela apresentação e agora é lançado para o dominio tratar. Aqui também ,as tecnologias modernas
deixam que você utilize o mesmo objeto que você usa para persistencia de estado. Isto é bom para reduzir o numero de classes, mas conceptualmente
o mesmo objeto cumpre responsabilidades diferentes em cada andar. A Fronteira do Domínio nada mais é que a interface do DomainStore ou do DAO que permite comunicar com “a parte de baixo” do sistema.
O controle do andar de domínio é controle de fato onde estão as regras. Isto normalmente é feito construindo objetos no padrão service que se comunicam com outros services e com objetos no padrão Repository para encontrar entidades num certo estado.

Repare como o andar de Domínio é onde tudo se funde e onde a decisão realmente irá provocar efeitos no estado do sistema.

Resumo

O padrão ECB é um padrão de Arquitetura com mais usos que o MVC e não limitado a uma camada. Aliás ele é o padrão por detrás do conceito antigo de servidores em 3 camadas.
Mas também é o padrão por detrás de qualquer outro numero de camadas. A arquitetura em 5 camadas deriva também do padrão ECB e até podemos usar o padrão ECB para provar que todas as arquiteturas terão um numero de andares impar (1 – quando tudo está num andar só. É uma confusão, mas era assim no passado , 3 – quando temos UI e dados um pouco separados do resto , 5 – quando temos a UI e os recursos completamente desacoplados …)
Porque o padrão ECB se assemelha muito ao MVC e as pessoas estão habituadas a arquitetura em 3 camadas (andares) tudo parece se misturar. Mas se pensarmos em arquitetura de 5 camadas é fácil ver onde cada padrão é usado e porque e como eles são diferentes.

Espero com isto ter ajudado a remover qualquer dúvida sobre o assunto de MVC e camadas provendo ao mesmo tempo um novo padrão para que você possa desenhar sua arquitetura.

Em  posts anteriores falei de como se sabe se um processo é tradicional ou não e como se define o processo clássico.  Hoje falarei do processo ágil.

O processo ágil é muito semelhante ao processo clásico, mas se apoia em algumas permissas diferentes que injetam muita simplicidade no processo e os desburocratizam.

O primeiro passo é não confundir o “Processo ágil” com o “Movimento Ágil”. O movimento ágil é um conjunto de pessoas que partilham de um conjunto de conceitos e valores que querem ver ser usados na prática. O Manifesto Ágil é o simbolo deste movimento. Contudo o movimento ágil não foi inicado com o manifesto ágil. No final dos anos 90 algumas pessoas começaram a adotar metaforas diferentes para o processo de software. Até aqui a metáfora favorita é a da construção de uma casa, ou um avião. A metáfora passou então a ser a de uma linha de montagem, e não uma linha qualquer, uma linha japonesa de montagem que podemos identificar como a guerra ao desperdicio. Desperdicio de tempo, dinheiro, planejamento,  documentação, preocupações, etc.. Com isto nasceu o processo Lean. Mais tarde o processo Scrum.

O processo ágil é então o resultado de uma mudança de paradigma em que as pessoas queriam ver mais produto e menos “planejamento”.  Isto não significa que não ha planejamento, mas ha o minimo necessário. Esta diretiva de “o minimo necessário” é o amago do processo ágil. Ao contrario nem o processo clássico ou o tradiiconal parte de um conjunto de diretivas/axiomas e essa é a principal diferença para o processo ágil.

As leis do desenvolvimento de software são levadas em consideração para criar um processo que não lute contra o inevitável, mas se aproveite do inevitável. Ou seja, use a correte, não reme contra ela.

O primeiro destes inevitáveis é a mudança. A mudança é inevitável. O que significa que a mudança de escopo é inevitável. Devido a isto o processo ágil pega o processo clássico e define que todos os projeto serão plan-driven e que não existem projeto time-driven ou feature-drive. Ou, dito de outra forma, as mecanênicas de um plan-drive permitem controlar qualquer tipo de projeto, inclusive o time-drive e o feature-drive. Isto significa que num processo ágil sempre consideramos que o cliente quer algumas features em algum tempo. Isto força o cliente a priorizar muito bem o que quer e quando quer. Por isso as verificações que no processo clássico são feitas em certos gates, no processo ágil são feitos continuamente.

O processo ágil começa da mesma forma que o tradicional ou o clássico: transformar prospects (clientes em potencial) em clientes. Para isso o departamento comercial faz o seguinte. Começa por se aproximar do cliente para saber o que ele quer. Normalmente a resposta é vaga. Algo como “precisamos de um sistema de XPTO porque o nosso tem alguns problemas”. O departamento comercial vê isto como uma oportunidade e propõe que o cliente aceite conversar com alguém da área de projetos.  A area de projeto envia 2 ou mais pessoas com capacidades de Levantamento.  Normalmente um analista e um domain expert.  Não envia apenas uma pessoa. Isso seria um erro. E não envia  mais que 3 pessoas, porque isso seria desperdicio. A equipe é focada em levantar os requisitos macro. Até seguimos o processo clássico. A diferença está em que todos os requisitos são gravados como historias. As historias têm uma forma padrão de serem escritas. Isto faz com que os requisitos sejam mais padronizados na sua forma o que permitirá depois indentificar requisitos iguais ou que estão contidos em outros requisitos. Historias não se comparam apenas  acasos de uso podendo conter informações não funcionais.  A estas historias pode ser atribuido um risco como no processo clássico e um tramanho. A diferença é que o tamanho não é atribuido pela equipe de levantamento ou de projeto.

Em um processo ágil a equipe de execução não é escolhida à posteriori. A equipe é envolvida desde um principio. Aqui ha uma diferença grande para o processo clássico e o tradicional.

O processo de levantamento leva de 5 a 10 dias de entrevistas com vários stakeholders. O objetivo não é criar codigo, mas saber o que o cliente precisa e não precisa.Tudo é escrito em forma de historias para posterior análise.

Não é relevante neste ponto saber o que o cliente quer antes do quê e para quando. Esse aspeto será tratado depois.

De posse das historias, elas foram uma lista. Esta lista é reorganizada. Vários stakeholders podem ter dito a mesma coisa com palavras diferentes. Alguns detalharam mais, outros menos. O objetivo é ter uma lista de historias limpa de repetições e ambiguidadas. Questionamentos são enderaçados ao cliente.

Depois da lista limpa, ela é repassada com a equipe de execução. Neste ponto o erro ainda é grande e o cone de incerteza é levado em consideração. A equipe usa um processo interativo de pontuação do tamanho das historias. Este é um processo semelhante ao Wideban Delphi do processo clássico, mas mais simples e rápido. Este processo é conhecido como Planning Poker. Nesta fase cada pessoa da equipe de execução atribui uma pontuação minima e máxima à historia.  Esta margem, junto com o cone de inserteza irá nos dar um tamanho máximo e minimo para a lista de historias.  Estes pontos são chamados pontos de historia e obdecem a um conjunto de regras.

O processo de Planning Poker junto com a escala de pontos  provê uma forma mais imparcial de contabilizar o tamanho da lista de historias.

A grande diferença para o processo tradicional é que a estimativa é em tamanho não em tempo. Para o processo clássico a diferença é que se escolhe uma unidade nova para estimar o tamanho. Estamos aqui efetivamente dimencionando os requisitos e não a implementação. Esta mudança de paradigma é obvia para alguns e alienigena para outros, mas é necessária no processo ágil.

Sabemos então que a lista de historias do cliente tem um tamanho entre A e B, já com os devidos erros e desvios. A posta feita ao cliente é a seguinte : Você terá direito a gastar B pontos de historia. O nosso preço é P por ponto de historia o que significa que o preço do projeto é BxP.

Este mecanismo é extremamente transparente e muito semelhante à proposta tradicional de “Você tem direito a gastar H horas de projeto. O nosso preço é P por hora o que significa que o preço do projeto é H*P”. Isto diz ao cliente porque o preço é aquele e diz como o preço irá variar se ele decidir modificar alguma coisa. Como a mudança é inevitável é importante que o cliente saiba as regras do jogo. Isto , ao contrario do processo classico de gerenciamento de mudanças, deixa o cliente mais livre e mais à vontade.

Contudo para evitar desperdicios, a proposta não termina ai.  A proposta inclui dividir o projeto em pelo menos 3 partes. A prática de repartir o projeto em releases (publicações) já é padrão no processo clássico. Aqui estamos apenas forçando que o projeto seja dividido em 3 releases. Desta forma o cliente é obrigado a priorizar para o primeiro release o que realmente é o coração do sistema, o resto são upgrades ou extensões. As historias são então destribuidas pelos releases, não pelo tamanho, mas pela prioridade que o cliente lhe dá. A Prioridade, assim como o Risco e o Tamanho é uma propriedade das Historias. Veja que no modelo clássico já era assim, já falavamos em prioridades. A diferença é que não atribuimaos um numero para isso. Era sempre subjetivo. Em um processo ágil a prioridade é um numero que pode identificar em qualquer momento qual a historia que é para realizar primeiro.

O processo ágil funciona bem perto do cliente. Nem todos os clientes aguentam esta forma de trabalho, mas o modelo é o mais simples possivel. Uma lista de historias subdividida em 3 ou mais releases. Um conjunto máximo de pontos que têm um preço e a possibilidade de remover, adicionar ou reoganizar as historias a qualquer momento. Qualquer alterção que tenha que ser feita no software para corriger, reverter ou emendar é considerada uma historia e vai consumir pontos. Mas o cliente é livre de comprar mais pontos quando quiser.

O andamento do projeto será medido com comparando as balizas que sãos os releases. O release em si mesmo é dividido em sprints e as tarefas são realidas e aprovadas em um sprint. Isto permite saber claramente o que está pronto para entrega e o que não. A razão entre o numero de pontos realizados por sprint é a velocidade. Estrapolando a velocidade é possivel saber o quanto vai ficar de fora do sprint e já ir replanejando continuamente sem ter que esperar que todas as features estejam implementadas para poder testar ou redirecionar o projeto.

O processo ágil é, portanto, marcado pelos seguintes aspetos:

• Aceitar que a mudança do escopo é inevitável
• Aceiter que o custo advém do desperdício
• Não se  faz nada sem estimar antes e as estimativas não são viciadas. Para não viciar as estimativas processos que colocam a equipe de execução à cabeça como o Planning Poker, são usados.
• Não existe fases de projeto. Existem releases. Com datas e listas de features a serem realizadas.
• Não são feitas promessas. É estabelecido um contrato, com regras, prazos, coisas a esperar e principalmente coisas a não esperar. Tudo é feito de comum acordo e sem mecanismos de submissão.
• O cliente é respeitado. É informado de todos os problemas e todos os riscos. O cliente tem controle absoluto sob o rumo do projeto. Ele decido o que realizar e quando. A priorização constante leva à diminuição de desperdicios e a alcançar os objetivos do cliente mais cedo.
• Conhecimento das capacidades e funções dos membros da equipe não são necessários porque a equipe, ela mesma, vai acabar provendo a estimativa original os dados de andamento através da velocidade. O que ha a fazer é simplesmente guiar o cliente e permitir que ele faça correções.
• Sempre que ha um problema qualquer pessoa pode levantá-lo e alertar.

O processo ágil ainda é estricto em certo aspetos como o processo clássico e demanda, como o clássico um certo grau de comprometimento e não sair mudando as regras sem as conhecer. Não é   um processo Stage-Gate com o clássico. Avaliações e mudanças de planos são feitas constantemente. Contudo, como no processo clássico, tudo isto e feito com base em numeros e dados e não em chutes ou promessas.

Dentro do processo ágil existem várias variantes cada um delas dando mais importância a um aspecto ou outro. Algumas como o XP (Extreme Programming) aliam as práticas do processo ágil com boas práticas de engenharia de software para tentar obter o melhor de dois mundos. Outras, como Lean, ainda focam no fluxo do processo e ainda tem um resticio do processo Stage-Gate ( afinal o modelo Lean é baseado em linhas de produção que são stage-gates por definição), outras adotam Stage-Gates conceptuais como Kanban ao mesmo tempo que permitem um controle ágil.

Ágil não representa o abandono dos valores clássicos, nem de suas práticas. Bem pelo contrário. O processo ágil é genéticamente artilhado para cumprir com uma série de leis e permissas resultado da analise classica e ainda sendo simples de usar. Muita gente acha que ágil é o abandono da documentação e do levantamento de requisitos. Nada mais longe da verdade. O ponto é que ágil se preocupa em não desperdiçar, e isso significa que não podemos documentar tudo a toda a hora nem ficar levantando requisitos o resto da vida. Ha um conceito de “bom o suficiente” ou “minimo suficiente” que basta para o trabalho em mãos.

Com o fim da triologia de processo, espero que fique mais claro para todos as diferenças, para que da proxima vez que ouvir falar em processo tradicional ou ágil saiba do que está falando.

Se você entendeu o que escrevi, você deve ter entendido que dizer que você usa um processo tradicional é na realidade uma forma de insulto profissional pois, a realidade não é nada bom usar um processo tradicional. É que as pessoas que usam tradicional e acreditam nele ouvem “tradicional” mas entendem “clássico” e é não exergar a diferença, que os torna tradicionalistas.

O processo clássico se destingue do processo tradicional principalmente pelo compromisso dos intervenientes com aquilo que estão tentando produzir e com a comunidade que produz a mesma coisa. Aprender com as lições dos outros é importante num oficio que tem apenas 50 anos. Ainda ha muito a ser descoberto em termos de saber qual a forma mais eficiente, eficaz e barata de criar um software. Repare que “barato” tem que ver como o custo e não com o preço.

O software tem que ser barato para quem o cria e livre de risco para quem o cria. Não necessáriamente o preço tem que ser pequeno ( Quanto custa o seu preço ?).

Veja que existem muitos pontos em comum entre o processo tradiciona e o clássico. Isto acontece porque quem usa o processo tradicional normalmente acha que está usando o processo clássico. Ou pelo menos essa é a sua intenção.

O processo clássico começa da mesma forma que o tradicional.: transformar prospects (clientes em potencial) em clientes. Para isso o departamento comercial faz o seguinte. Começa por se aproximar do cliente para saber o que ele quer. Normalmente a resposta é vaga. Algo como “precisamos de um sistema de XPTO porque o nosso tem alguns problemas”. O departamento comercial vê isto como uma oportunidade e propõe que o cliente aceite conversar com alguém da área de projetos.  A area de projeto envia 2 ou mais pessoas com capacidades de Levantamento.  Normalmente um analista e um domain expert.  Não envia apenas uma pessoa. Isso seria um erro. E não envia  mais que 3 pessoas, porque isso seria desperdicio. A equipe é focada em levantar os requisitos macro de forma a que seja possivel estimar o risco do projeto e o tamanho do escopo.

Repare que no tradicional o risco é ignorado e o tamanho do escopo é irrelevanta pois será fixo.

O processo de levantamento leva de 5 a 10 dias de entrevistas com vários stakeholders. O objetivo não é criar codigo, mas saber o que o cliente precisa e não precisa. O que ele quer agora, o que ele não quer agora e o que ele nunca irá querer. Quanto mais as palavras “sempre” e “nunca” são usadas em um requisito maior o risco do requisito.

O risco do requisito é importante para saber o quão estável é aquele requisito.

Daqui a equipe de projeto determina o prazo minimo,  máximo e expectável do projeto ( o mais provável). Determina também quais áreas/requisitos irão precisar de mais detalhamento e em que grau. Por exemplo, um requisito padrão como login, normalmente é estável e precisa de poucas entrevistas. Um requisito como integração com legado é um requisito complexo, de alto risco que precisa de mais entrevistas.

A equipe de projeto detremina também as capacidades que a equipe de execução terá que ter. A tencologia, a estrutrua, a infra-estrutura, o processo usado, a necessidade de comunicação, o nivel de qualidade, o tempo disponivel (baseado no time-to-market) , etc… são constrangimentos ao tipo de equipe necessária. 4 séniors são uma equipe pequena , facil de gerenciar, que produzem boa qualidade e baixo numero de erros, mas mais cara. Uma equipe de 8 juniors é mais barata, mas produz mais erros e é mais dificil de gerenciar face à falta de maturidade.

É vital que o levatamento direcione as perguntas. A conclusão mais importante de todas é saber se o projeto será time-driven, feature-driven ou plan-driven. Em um projeto time-driven existe um requisito temporal que limita o projeto. O chamado time-to-market. Se o cliente precisa do software para uma certa data especifica, como o natal, uma feira , etc.. e se a falha em ter o o software nessa data aborta o projeto. Os projetos tradicionais são todos time-driven, mesmo quando não existe de fato um time-to-market, mas um desejo do cliente em uma data alvo.

Feature -driven acontece quando o tempo não é relevante mais sim as funcionalidades. Aqui se estabelece que o software só está pronto quando tiver as features A, B e C e todos funcionarem sem problemas. Basicamente o que interessa é cumprir o escopo e não nenhum prazo em especifico.

Plan-driven acontece quando o cliente está interessado em determinar um sub-conjunto de features em um certo prazo. O projeto é dividido em releases e cada uma tem um objetivo util e comercial para o cliente. Basicamente o software é feito em forma de upgrades, mas com uma versão 1 que se pode utilizar em produção.

A somar a todas as estimativas ha a consideração do cone de incerteza. Numa fase preliminar como esta e com um cliente com quem nunca se trabalhou, a incerteza é bem grande e deve ser considerada.

Depois de pesar todos estes fatores, determinar o perfil da equipe de execução, o risco e tamanho dos requisitos e o plano de entrega a área de projetos produz um documento de visão acompanhados da proposta de prazo e custo.

O comercial então terá que avaliar a viabilidade deste projeto. Talves não seja rentável executar este projeto. Se não for, uma discussão com o cliente e o departamento de projetos pode levar a uma simplificação do projeto, dos requisitos, uma extenção dos prazos, etc.. de forma a tornar o projeto comercialmente viável.

Feito isto o departamento comercial  propõe ao cliente algo como “Podemos fazer um sistema de XPTO para si entre N e M meses por P reais”. Veja que um prazo máximo e expetável são apresentados e não uma data fixa.

Existem várias formas de escrever um contrato e não necessáriamente os dois limites do prazo vão aparecer explicitamente. Isto porque os clientes ficam confundidos quando veêm duas datas e assumem a menor. Um forma de por isto de uma forma mais digerivel é usar um contrato assim :

“Podemos fazer um sistema de XPTO para si em N meses por P reais. Com um prémio Z que decai até M meses.”

P é o custo do projeto com um lucro embutido. Z é um valor calculado tal que seja igual a P ou maior até um percentual do periodo entre N e M. Este percentual depende do risco e da confiança em N. Ou seja, quanto mais confiante menor este percentual.

Existem muitas formas. O ponto é considerar que a data expectável tem uma probabilidade menor que a data máxima. A empresa e o cliente são recompensados se a data expectável for correta, caso contrário a empresa é penalizada. Este conceito de penalizar a empresa e não o cliente é completamente desconhecido no processo tradicional.
Supondo que o cliente concordou com os termos temos agora um projeto com prazo, preço e escopo definido.

A mudança de escopo é feita segundo um processo de mudança de escopo normalmente recorrendo a um comité e todas as alterações para cima são cobradas pela empresa provedora. As alterações para baixo são colocadas em um “banco” para serem descontadas na seguinte mudança para cima. Isto só acontece porque todo o requisito tem um risco e um tamanho associados.

O próximo passo é detalhar o levantamento já iniciado e em paralelo começar a desenhar uma arquitetura e infra-estrutura.  Nesta fase (analise) o levantamento mais detalhado pode levar a alterações no escopo que podem levar a alterações no resto do projeto.  Todos os requisitos são detalhados e partidos em requisitos menores até que seja possivel transformar o requisito em tarefas de execução.

Durante esta fase de analise os requisitos são também analisados e sentitizados de forma a chegar num numero minimo de requisitos que atendem os requisitos iniciais.Com a arquitetura testada e aprovada e os requisitos detalhados um documento de especificação é produzido.

Em paralelo a equipe de execução é montada e os requisitos são partidos em tarefas, por ela. As tarefas são cotadas com um tamanho por um processo como o Wideband Delphi, por exemplo. A gerencia de projeto usa estes numeros para corrigir a sua estimativa inicial. Se menor, o plano original é mantido. Se maior, o cliente é acionado para modificar a prioridades dos requisitos de foram que se o tempo explodir, apenas as features menos relevantes ficarão de fora.

Passa-se então à execução. Durante a execução, novos requisitos são introduzidos, alterações são necessárias, o comité de mudança é acionado e os requisitos são constantemente analisados e sintetizados. Em paralelo os planos de teste começam a ser construidos.

Passa-se então à execução dos testes. A equipe de QA tem o documento de requisitos e os planos de teste para se guiar e não precisa inventar casos ou cenários que não estejam ali. Contudo, falhas, hiatos funcionais ou de implementação levarão a equipe a recomeçar por analizar os requisitos, modificá-los , modificar o codigo e a documentação.

A taxa de testes com sucesso versus a taxa de bugs são computadas pela gerencia e considerando o cone de incerteza obtemos uma nova estimativa de sucesso ou não do projeto. Novas priorizações são feitas pelo cliente.

Emquanto os testes estão sendo feitos,o cliente revisa os requisitos finais com a equipe de requisitos. Modificações, disparidades, hiatos levarão a equipe a recomeçar por analizar os requisitos, modificá-los , modificar o codigo e a documentação.

No fim deste processo, os testes terão garantido a qualidade tecnica do produto e a revisão dos requisitos terão garantido que o software faz o que o cliente quer. Finalmente temos a fase de homologação em que o cliente usa de fato o software. Quaisquer pedidos de modificação são comparados com os requisitos. Quando o pedido não base com o requisito ele não é realizado. Esta não é uma fase onde o cliente pode inventar coisas novas. Alterações que não sejam devido a bugs serão simplesmente deixadas para outro projeto no futuro.

O processo classico não começa com promessas irrealistas. As coisas são medidas e estimadas by the book ( seguindo os livros). O andar do projeto é medido em certo pontos o cliente faz os ajustes. A empresa nunca prometeu realizar tudo, mas sim cumprir o objetivo inicial ( time-driven, feature-driven ou plan-drive).  Ou seja, a empresa está comprometida em cumprir um plano e não em cumprir o desejo do cliente. O cliente é livre de mudar o plano, basta que pague a diferença.

A equipe é contratada depois que se sabe o que o sistema irá fazer. Os requisitos já estarão detalhados o suficiente para quando a equipe existir ela poder realizar a quebra em tarefas. O risco de escolher uma equipe junior uma sênior, ou um misto é imputado nas estimativas e não é deixado ao acaso. Nada é deixado ao acaso excepto o real andamento do projeto. O projeto é devidamente documentado para que nem o cliente nem a empresa tenham duvidas sobre o que é para fazer e o que não é. O resto é superfluo, não necessário, e relegado para um próximo projeto.

A equipe sabe exactamente o que tem que fazer e pode ser organizada da melhor forma para cumprir esses objetivos no minimo tempo possivel já que o objetivo interno da empresa é alcançar a data expectável (e não a data máxima, que está no contrato). Internamente o projeto é guiado de uma forma e com um objetivo, enquanto que externamente ele é guiado de outra forma com objetivos iguais mas tempos mais dialatados

O processo classico é, portanto, marcado pelos seguintes aspetos:

• Não se  faz nada sem estimar antes e as estimativas não são viciadas. Para não viciar as estimativas processos padrão explicitos na literatura são usado.
• As fazes do projeto são respeitadas e executadas à risca: Negociação, Levantamento, Analise, Desenvolvimento, Teste  e Homologação.
• Não são feitas promessas. É estabelecido um contrato, com regras, prazos, coisas a esperar e principalmente coisas a não esperar. Tudo é feito de comum acordo e sem mecanismos de submissão.
• O cliente é respeitado. É informado de todos os problemas e todos os riscos. Todas as suas decisões são guardadas para futuro uso ou confrontamento. Se o cliente se enganar, ele se enganou. Se nós nos enganarmos, nós nos enganámos. Sem problemas.
• O escopo é controlado rigidamente e qualquer desvio afeta o resto do projeto. O plano é modificado e o contrato com ele.
• Conhecimento das capacidades e funções dos membros da equipe. Responsabilização pela equipe que montou.
• Sempre que ha um problema qualquer pessoa pode levantá-lo e alertar.

O processo clássico é bem estricto. É um processo Stage-Gate com a possibilidade de em cada gate haver uma avaliação do projeto e novos planos serem feitos e novas direções sendo tomadas. Contudo tudo isto e feito com base em numeros e dados e não em chutes ou promessas.

Este processo é extremamente rígido e para funcionar a contento as pessoas que o usam tem que ter uma certa experiencia. É por isso que é importante seguir o processo by the book. O que acontece na prática é que as pessoas leêm os livros mas logo interpretam ou subjugam o que o livro diz para o seu caso sem nunca ter dado uma chance ao processo canónico. É isto que gera a inventividade dos processos tradicionais. A intenção das pessoas é boa, mas sua arrogância é maior e se acham capazes de desafiar o que os autores levaram anos para descobrir e documentar. O exemplo clássico é desconsiderar o cone de incerteza, ou sequer saber o que ele é. Outro é não forçar um processo de mudança de escopo como deve ser com medo que o cliente se assuste quando a empresa disser que não irá fazer tal coisa e o cliente vá embora.  Os medos e inseguranças das empresas de software levam a que rapidamente alterem o que está escrito e começem o processo tradicional. É um mecanismo semelhante ao que acontece com a biblia. um escrito, mil interpretações.

Por outro lado, seguir as regras by the book não significa que as tenha que seguir mesmo quando estão erradas ou não correspondem com o seu caso. Contudo é preciso ser humilde e disciplinado para apenas mudar a regra quando so dados demonstram que ela não é eficaz no seu caso, e que, por algum motivo, o seu universo amostral é estatisticamente  diferente daquele usado pelo autor do livro.

O processo clássico deixa margem de manobra para alterações, só que ele exige provas de a mudança é necessária. Como a maioria dos gerentes faz um pessimo trabalho coletando dados do projeto nunca ha como provar nada e é aí que entra o chute, a artimanha e a politica. E mais uma vez a porta está aberta para o processo tradicional.

Sendo um processo rigido e dificil de seguir, embora muito simples de entender, o processo classico fácilmente se trasnforma no processo tradicional porque os intervenientes não têm a indole moral ou a retidão necessária para executar o processo como deve ser.  Contudo, se você perguntar, muitos irão dizer que estão usando a tecnica A ou B do autor X ou Y, mas se olhar de perto não estão. Simplesmente porque subverterem o que a tecnica significa e deturparam o seu significado

Se seguir o processo como deve ser, verá que ele é muito lento e burucrático. A burocracia advém do fato de constantemente ter que saber se o requisito A ou B está ou não no escopo e algumas vezes isso é subjetivo. Isto levou algumas pessoas a considerar que se dá muita importancia ao processo e pouca ao interesse do cliente ou da execução do software. Ou seja, o cliente é honorado pelo seu próprio desconhecimento do software que ele quer. mas se o cliente soubesse o que ele quer, ele mesmo teria feito o software sem contratar a empresa.

Daqui nasceram tentativas de melhorar o processo classico deixando o seu core de boas práticas, medições, auferições, mudança de planos mas modificando as regras de forma a que o processo fosse mais simples, menos burucrático, mais ágil.

Da próxima falarei do processo ágil. Até lá.

O processo tradicional normalmente começa com transformas prospects (clientes em potencial) em clientes. Para isso o departamento comercial faz o seguinte. Começa por se aproximar do cliente para saber o que ele quer. Normalmente a resposta é vaga. Algo como “precisamos de um sistema de XPTO porque o nosso tem alguns problemas”. O departamento comercial vê isto como uma oportunidade e faz uma oferta direta de negócio se oferecendo para fazer o software. Por meio de licitação ou por conversação direta o departamento comercial só precisa estabelecer dois parâmetros de forma a convencer. O prazo e o preço. O departamento comercial, sem nenhuma noção do que o software será, como será, qual a equipe, qual a tecnologia, qual a complexidade, etc… simplesmente prometa ao cliente algo como “Podemos fazer um sistema de XPTO para si em N meses por P reais”. Normalmente estas variáveis são tunadas para agradar ao cliente. Por exemplo, se o cliente diz que quer o software para o natal e falta 3 meses para o natal, o prazo será  – você adivinhou – 3 meses. Independentemente se é possível ou não. O departamento comercial é sempre otimista porque depois de fechar o contrato não é da sua responsabilidade que ele se cumpra. Se algo der para o torto, o problema é do departamento de projetos e desenvolvimento. Nunca do comercial. O comercial também gosta de jogar com o  dinheiro. Se a empresa cliente é grande, inchamos o preço – a chamada gordura – ( que é diferente do conceito de lucro)  , se o cliente é modesto o preço é mais baixo. Mais uma vez o custo do projeto é irrelevante. Nem sequer se toma em consideração quantas pessoas estarão na equipe, por quanto tempo e quanto cada uma ganhará.

Algumas empresas tentam fugir deste modelo. Elas acham que se tiverem uma estimativa isso torna as coisas mais cientificas. Assim, o departamento comercial fala com o departamento de projetos. Normalmente um dos gerentes de projetos , e pede para que ele faça a estimativa. Mas já lhe fala que o prazo é N meses e o custo é C. Perante isto o gerente simplesmente criar um grant chart no projet que mostra como as pseudo-fases do projeto encaixam nesses meses. Normalmente as fases são : Levantamento, Analise ,  Desenvolvimento, Teste , Homologação. O gerente então adoça o caldo prometendo que no fim de cada faze um conjunto de artefactos será entregue ao cliente em troca de pagamento. Isto basicamente significa que – sem nenhuma noção se vai dar certo ou não  – o gerente compromete uma equipe que ainda não existe em entregar artefatos ( documentos,  diagramas, codigo, entregáveis de qualquer especie) que ele desconhece num prazo que ele não sabe se é suficiente. A desculpa é : depois arranjamos um cara que possa fazer isso no tempo que nós queremos. E se ele não for capaz, pressionamos.

O departamento comercial fica maravilhado com isto porque suas estimativas de preço e prazo estavam certas (uau!). Afinal o gerente não falou nada que estamos enganados, nem que prometemos mundos e fundos. Aliás ele ainda prometeu mais coisas e se ele fez isso é porque está confiante com o preço e prazo que inventamos. Confiante sim. Certo não.

Sendo assim o departamento comercial fica ousado e jura de pés juntos que o prazo e o preço serão cumpridos e por isso propõe o desafio de um prémio. Se o software for entregue na data prevista ou antes, o prêmio será X. Com um decaimento progressivo se entregue depois. É obvio que esta estrutura de pensamento em que ninguém se dá ao trabalho de saber o que afinal irá ser feito e como, está voltada ao fracasso.

Sabendo disto as chamadas fábricas de software apelam para o que chamam de “Definição de escopo”. Afinal isso é a única variável no processo já que o prazo e o custo são chutes do comercial e não baseados no custo e esforço. “Sistema de XPTO” não é suficiente para estas empresas. Eles querem saber, o que compõe um sistema de XPTO. O cliente responde que é o conjunto do modulo A com o B e o C. A empresa pergunta o que é o A , o B e o C. O ciente responde que dará mais detalhes durante a fase de levantamento.Isto é um  artificio do cliente. Na cabeça do cliente está se passando um filme diferente. Na cabeça dele a empresa que constroi o software é de um de dois tipos. Ou é uma empresa que contrata adivinhos e portanto sabe o que ele quer, ou tem gente experiente trabalhando nela e portanto essas pessoas sabem o que o cliente quer. Ter que responder o que elas já sabem é inutil e aliás demonstra que a empesa não é tão boa como diz. A empresa também acha que perguntar de mais é sinal de fraqueza e que pode levá-lo a perder a paciência e a cancelar o projeto. Então, “vamos fazer a estimativa com o que sabemos e por alguma margem de erro em cima” – diz alguém no departamento comercial , de projetos ou até mesmo da diretoria quando algum gerente mais preocupado está tentando avisar que o barco está afundando antes de ir para o mar.

Assim se faz. uma micro-levantamento que foi possivel executar com 5 ou 6 bullet points é apresentado em um power -point ao cliente, com o gráfico do project o preço e o custo que o comercial havia decidido.

Se a sorte quiser, o cliente aceitará a proposta. Entenda que tudo está nas mãos da sorte, não da capacidade ou da competência dos envolvidos, já que ninguém sequer ousou olhar para o software que irão produzir. Aqui começa o problema do processo tradicional. Promete-se tudo de olho no dinheiro e num conceito chamado “por o pé na porta” que significa que tudo é menos importante que tornar um prospect em um cliente e isso deve ser conseguido custe o que custar. Não importa se dentro de N meses quando o software explodir o prazo e o orçamento a imagem da empresa vai para o buraco. Porque nesse ponto o departamento comercial irá chantagear o departamento de projetos para fazer algum milagre para por as coisas nos eixos. Normalmente estamos falando de horas extra. Afinal é a única coisas que estas sabem que existe num projeto: tempo.

Veja que isto poderia ser um projeto de qualquer tipo de área. A estas pessoas tanto faz se é um software ou uma horticultura que estão construindo. Porque na cabeça delas basta arranjar um profissional que saiba fazer o que eles prometeram. E a arrogância nãos lhes permite enxergar que o que prometeram era completamente irrealista.

O processo tradicional começa com promessas irrealistas, mas o descalabro não acaba aqui. O próximo passo é montar a equipe.

Aqui começar contas interessantes. O gerente do projeto chuta que com R recursos ( não pessoas, recursos) sendo 98% juniors 1% plenos e 1% séniors dará para realizar o projeto no prazo e no custo. em outras palavras : contratamentos um bando de mão de obra barata e alguns sêniors para serem o culpados de tudo e alguns plenos para realmente fazerem alguma coisa funcionar. Isto porque um sênior que é sênior não vai tolerar certas coisas e acabará saindo do projeto quando poder. O pleno foi instigado pelo gerente que tem potencial para ser sênior e se ele o demonstrar será aumentado. Veja, um pleno é um cara que tem capacidade tecnica quase como um sênior para ainda pensa como um junior. Por isso é facilmente seduzido pelas artimanhas da gerencia.  Lembrar que no processo tradicional todas as promessas são irrealistas. Inclusive as que dizem respeito aos “recursos”. Tudo não passa de um tecnica de manipulação. A velha cenoura que você nunca comerá. Isto faz dos “recursos” burros.

Obviamente com uma equipe meia boca o projeto só tem um fim possivel : desastre. A fase de levantamento é engolida pela fase de negociação ( que todo o mundo no processo tradicional esquece) , a fase de analise é regida por um cronograma em vez de um risco do desconhecido e chegamos no desenvolvimento. AH! afinal o que interessa é programar o software. Esta atividade também é regida pelo cronograma em vez do estado de conclusão das tarefas e passamos aos testes. Aqui uma equipe chamada de QA (Quality Assurance – Assertividade de Qualidade)  é chamada para verificar que o software funciona. Aqui as coisas mais engraçadas acontecem. Por exemplo, a equipe de QA não sabe como o sistema deveria funcionar e testa no feeling. Não ha documentação que diga o que o sistema tinha que fazer ou como reagir em certos casos. Todas as mensagens em tela são considerados erros e impedivos para continuar testando embora a mensagem apenas informa que o usuário fez merda ao imputar certo dado … etc… Enfim, o QA sempre é uma piada. O que deixa os desenvolvedores putos da vida porque do ponto de vista deles, eles é que sabem como o sistema funciona, mas a gerencia só observa a palavra dos testers. E claro, além disso tudo ha a correção de bugs.

Afinal uma equipe medíocre, cujo objetivo nisto tudo é apenas o dinheiro no fim do mês e uma promessa de promoção, mas que sofre para caramba e trabalha 3 vezes mais que todo o resto da empresa sofre muita pressão e por consequência, se engana muito. Dai os bugs. É certo responsabilizar o júnior pela sua falta de competência ? Não. É certo culpar o Sênior por não ter treinado o junior ? Não. Primeiro porque ha juniors que se acham os donos do pedaço e  segundo porque ninguem paga ao sênior para treinar ninguem. Treinar é coisa de Coach, e isso é outra função e outro salário.

Mas assim é tudo uma zona. Como será possível uma empresa trabalhando assim chegar a algum resultado ? Não é. Só que todos se enganam mutuamente de uma forma tão bem orquestrada que tudo continua na mesma. O rei vai nu. Todo o mundo sabe, mas ninguém tem coragem para fazer nada. Isto significa que as pessoas acabam vivendo descontentes e acabam abandonando a empresa por outra, na esperança que a próxima será diferente. Não nunca é.

Porque você acha que em software todo o mundo é PJ ? Porque a rotatividade é enorme, e a empresa sabe disso. Logo ela diminui os custos de rotatividade ( contratação/ despedimento) usando o mecanismo de PJ. O que isto diz sobre as empresas ? Elas são ruins e sabem disso.  Uma empresa que acha que vai manter seus funcionários (nao “recursos”) aposta neles. Treina. Cumpre o que promete. Ouve. Muda. E com isso mantém o nivel de descontentamento baixo e a moral alta.  Como disse o fundador da Honda :”As pessoas não vêm para o trabalho para trabalhar, elas vêm para se satisfazerem”. Isto é especialmente verdade em trabalhos intelectuais como é a construção de um software. É bem diferente do trabalhador que trabalha para comer.

O processo tradicional é, portanto, marcado pelos seguintes aspetos:

• Falta e estimativas com base em dados relativos ao sistema que será realizado
• Incorreto conhecimento sobre as fases do projeto de software. Ignorância de processos, regras, resultados, estudos , etc … publicados em livros ou outros meios da comunidade de software (os gerentes leêm revistas de negócios, não de software)
• Promessas irrealistas a todos. Sejam clientes, funcionários, chefes ou subordinados
• Falta de compromisso com as necessidades do cliente.  Não importa o que ele quer. Importa quanto queremos receber dele e quando.
• Conhecimento que o escopo irá aumentar, mas insistência teimosa em adotar um modelo de escopo fixo.
• Falta de conhecimento de como funciona uma equipe de software e achar que qualquer bando de pessoas é uma equipe
• Falta de controle ao longo do processo para saber se realmente chegaremos na meta e preferencia por enganar todo o mundo a pensar que vai dar certo. Parecem desconhecer o ditado que “se pode enganar a todos a algum tempo, e a alguns todo o tempo, mas não a todos todo o tempo”. Os gerentes são mestres a enganar poucos todo o tempo porque apenas se reportam a 1 ou 2 pessoas acima deles e quando chega a hora da verdade a culpa é da equipe que era ruim. Mas lembrar que a qualidade da equipe nunca foi medida, nunca foi um fator.
• Falta de respeito pelos profissionais de desenvolvimento que são tratados como gado e não como pessoas inteligentes com capacidades intelectuais especificas como abstração espacial e matemática .
• Total descaso se alguém tentar provar que o rei vai nu. Isso é já sabido e incômodo de ser comentado.

Com certeza você já participou de um algum projeto em alguma empresa que trabalha assim. Aliás , quando é que você trabalhou em uma empresa que não trabalha assim. No Brasil este modelo é tão comum que é um vírus. O único antidoto seriam empresas novas, adotando outros processos que pudessem levam estas à extinção.  O problema é que: 1) sempre existirão desenvolvedores de péssima qualidade posando como sêniors, sempre existirão plenos mercenários que só estão ali pelo dinheiro e juniores crédulos e ingênuos. Isto que a comunidade de desenvolvedores não tem uma sólida e firme base moral  e ética de valores que lhes permita distinguir o certo do errado, o abuso da necessidade; 2) as empresas não querem treinar ninguém. Querem mão de obra que faça o que eles pedem, nas condições que eles pedem, por muito absurdas e imbecis que sejam; 3) clientes que não enxergam que estão sendo enganados.

Em processo tradicional a empresa acha que está tirando vantagem tanto do cliente como dos fornecedores ( desenvolvedores). Mas na realidade, os desenvolvedores juniros estão de passagem, fazendo curriculum para a próxima entrevistas. Os sêniors estão de saco cheio de tanta imbecilidade e falta de profissionalismo de todos os envolvidos que fazem orelhas moucas e os plenos ainda se enganam a si mesmos com um ideal e uma promoção. No dia que cai a fixa, eles vazam. O cliente por outro lado está tirando vantajem da empresa pagando muito menos do que deveria como conseguiu colocar uma corda no pescoço da empresa e é só apertar um pouquinho que a empresa faz qualquer coisa, de graça. Quem está parasitando quem neste modelo ? É na realidade uma simbiose de parasitas num ciclo de vida complexo em que todos acham que ganham, mas todos realmente perdem.

Agora imagine quanto perder o usuário do software que sai de um processo destes. E se num hospital o paciente é a prioridade, em software é o usuário.

Da próxima falarei do processo clássico. Até lá.

Estas leis são muito importantes e são para o mundo da criação do software o que as leis de Newton são para a física ou as leis de Asimov para  a robótica.  As leis de regem o desenvolvimento devem ser a base para novos trabalhos, inovações e progresso da forma como fazemos software. É preciso entender que estas leis não dependem da tecnologia utilizada e por isso são válidas em qualquer tempo.

1. Lei Fundamental Do Desenvolvimento de Software

“O tempo necessário para criar um software completo é infinito“

Esta lei é simples, mas tem consequências muito complexas. Significa que nunca você poderá alcançar o software completo. Isto pode parecer castrador, mas significa realmente que temos que aproveitar melhor o tempo e tentar não criar o software completo, mas o software “completo o suficiente”. O conceito de “suficiente” leva a considerações de necessidade, disponibilidade de recursos e outros constrangimentos. Por outro lado, deixar o tempo ser uma variável em vez de uma constante levará um resultado absurdo. Ou seja, se você tem um software suficiente você deve estipular um período para o seu desenvolvimento.Concluímos , portanto, que o prazo do desenvolvimento nunca é uma variável. É a condição de “suficiente” que é a variável. Dito de outra forma, o prazo sempre é fixo e o conjunto de funcionalidades sempre é variável.

2.Leis de Parkinson’s

“O trabalho se expande pelo tempo disponível”

Isto significa que em qualquer tarefa, projeto, atividade aquilo que houver para fazer será diluído no tempo que for estabelecido para a realização desse trabalho. Ou seja, em outras palavras dado um certo trabalho e um certo periodo de tempo, nunca a atividade será realizada no inicio do perido, deixando o final do periodo sem nada para fazer. Isto é outra forma de dizer que : o trabalho nunca estará pronto antes da data final do prazo.

Sindrome do Estudante

“O inicio do trabalho acontece no ultimo momento possível antes do final do prazo”

Isto significa que você designar alguém para uma tarefa e lhe der um prazo, a pessoa irá protelar o inicio da atividade até o ultimo momento possível. Este limite é imposto pela própria pessoa que irá realizar a tarefa. A pessoas faz isto para poder aproveitar o principio do prazo que lhe deram para fazer outras coisas. Se chama “do estudante’ por é exatamente assim que um estudantes se comporta com o estudo ou deve de casa. Sempre é feito na ultima hora. Mas sabemos que nem todos os estudantes fazem isto. Logo, o síndrome do estudante, como outros síndrome pode ser controlar através de treinamento. O síndrome do Estudantes aliado à lei de Parkinson torna um problema em um risco e um potencial desastre. A Lei de Parkinson não pode ser alterada, mas outros fatores devem ser minimizados.

3.Lei de Pareto

“80% das consequências se devem a 20% das causas”

Este principio tem várias aplicações práticas. A primeira é que 80% dos bugs resultaram de 20% do código. A segunda é que 80% do trabalho será feito por 20% da equipe.  O problema do principio é que você não sabe à partida quais 20% causarão quais 80%.  É por isto que sempre ha que vigiar por um bom design e uma boa codificação porque você sabe que irá alterar pelo menos 20% do software porque irá causar 80% dos problemas. É também por isto que é tão importante a disseminação de informação e cultura na equipe , pois se acontece alguma fatalidade com os 20% que realizaram 80% do trabalho, a empresa terá um problema muito grave, sendo possível até que não consiga acabar o software.

4. Navalha de Occam

 ”A explicação de um fenômeno deve ser baseada no minimo possível de premissas, eliminando aqueles que não fazem diferença para as predições observáveis”

A Navalha de Occam ( também conhecido como Principio de Parcimônia)  é uma ferramenta de raciocínio muito aplicada em ciências naturais. Ela pode ser aplicada no mundo do software de várias formas. Duas são realmente importantes. Durante o levantamento de requisitos aprenda o máximo possível sobre as regras de negocio. Esta fase é chamada Coleta.  Depois analise como essas regras de relacionam. Esta fase se chama Analise. Por fim, simplifique e remova as regras que não são necessárias e/ou que derivam de outras regras. Esta terceira parte é chamada Síntese.  Hoje em dia as pessoas falam muito em analise. Temos até os Analistas. Mas o que realmente é importante é a sintese. É a sintese que cria um software mais simples porque em vez de implementar 100 regras você implementa 10 que produzem o mesmo resultado. Por outro lado, ao escrever código, o código deve envolver o menor numero possível de parâmetros. Sempre que um parâmetro poder ser inferido de um conjunto de outros, esse parâmetro é desnecessário

A redação desta lei pode ser escrita então em temos mais adequados ao desenvolvimento de software :

 ”A especificação de uma regra do sistema deve ser baseada no minimo possível de premissas e parametros, eliminando aqueles que podem ser derivadas das outras.”

Esta lei é conhecida na cena de desenvolvimento pelo acrónimo KISS (Keep it simple, stupid. Particularmente eu acho acrônimo ofensivo. Realizar a síntese não é trivial e a pessoas não conseguir fazê-lo não a torna estupida. O principio KISS realmente utiliza a palavra estupido no sentido contrário. O principio KISS parte do principio que a pessoa irá se esquecer de detalhes e do por quê de certas decisões. Ou seja, assuma que você é estupido, e por isso mantenha as coisas simples. Eu acho que a Navalha de Occam é muito mais elegante, e aplicando a Navalha de Occam ao principio KISS podemo facilmente concluir que a premissa que a pessoa é estupida é irrelevante.

5. Lei de Brook

“Adicionar pessoas a um projeto não diminui o seu tempo de execução, só o aumenta”

Esta lei é bem conhecida e tem várias outras redações possíveis. A redação mais simples e conhecida de todos nós é :

“A tarefa de gestação de uma criança  demorará 9 meses. Não importa quantas mães forem designadas à tarefa”

Basicamente esta lei representa que as tarefas têm um tempo que lhes é inerente e que mesmo com todas as ferramentas do mundo e a melhor inteligencia não dá para realizá-las mais cedo que um certo limite. Por outro lado, adicionar pessoas a um projeto multiplica a rede de canais de comunicação. Se você tem 2 pessoas em uma sala, A e B,  você tem 1 canal de comunicação (A-B). Com 3 pessoas você tem 3 canais (A-B, B-C, C-A). Com 4 pessoas você tem12 canais … em geral com N pessoas você tem N*(N-1)  canais de comunicação. A cada pessoas adicionada você gera 2(N-1) canais. Para resolver estre problema as empresas tendem a usar um modelo de hirarquia como no exercito. Isto funciona se um dado grande grupo de pessoas faz a mesma atividade. No exercito quando a cavalaria ou a infantaria são mandadas “atacar” cada individuo sabe o que tem que fazer, e o que ele tem que fazer é igual ao que o outro está fazendo. Não ha instruções especiais para cada individuo. Contudo, mesmo no exercito, o grupos de operações especiais não funcionam neste modelo. O modelo usado em comandos especias é um modelo em estrela. O grupo é pequeno, e cada pessoa tem comunicação apenas com um individuo que lhe passa instruções com pormenor. Ou seja, quanto mais especifico são as instruções ao individuo, menos um modelo hierárquico é adequado. No modelo em estrela adicionar uma pessoa cria apenas 1 canal, e não 2(n-1) canais.

6. Revelação de Sturgeon

“90% de tudo é CRUD”

Esta revelação é chocante. Se você não se sentiu chocado por ela, você não entendeu direito.Lei de novo. Ah! claro, CRUD significa “Create, Retrive, Update, Delete” as 4 operações básicas em um sistema de dados. Várias implicações saem desta revelação. A primeira é que se você não tem um mecanismo de persistência robusto, fácil de usar, você está indo para um buraco negro e profundo. A outra é que, mesmo mecanismos que não parecem CRUD são de fato CRUD. Repare que a revelação não diz que 90% é cadastros  e sim que 90% é crud. Cadastros são uma parte do problema, e cadastros em si mesmos são 90% CRUD, mas a revelação é o sistema, como um todo é 90% crud.

A revelação é chamada assim porque dá base interpretativa à  Lei dos 90%, que diz :

“Os primeiro 90% do código são responsáveis pelos primeiros 90% do tempo de desenvolvimento. Os outros 10% do código, são responsáveis pelos outros 90% do tempo de desenvolvimento.”

Confuso ? Sim. Por isso que a Revelação de Sturgeon é tão importante e tão profunda. Podemos entender da seguinte forma. Se 90% de tudo é crud, então CRUD é sempre parte de 90% de tudo.Portanto, 90% do projeto é criar o CRUD em sim. Os outros10% é usar o CRUD. Mas os outros 10% são a razão de porque você precisou criar o crud em primeiro lugar, logo 10% são responsáveis pelos 90% do tempo de desenvolvimento.

A leis dos 90% lida na sua forma pura, leva a considerar que o projeto demora 180% do tempo. Claro que é uma provocação, mas a Revelação de Sturgeon torna explica realmente muitas coisas, sem provocação.

7.Lei da Ação-Reação

“Para cada ação de engenharia acontece uma ação social igual e oposta”

Esta lei é uma paráfrase da segunda lei de Newton também chamada Segunda Lei de Augustine. Esta lei explica várias coisas, mas entre elas a dificuldade que o corpo técnico tem em fazer seja o que for sem a interferência do resto das pessoas do projeto. Quem é técnico se preocupa com mecanismos, variáveis,  razões, e emoções que são irrelevantes ao software ou a criação do software. E por simples desconhecimento, qualquer ação que parte dos técnicos é vista com preocupação e descrédito o que leva a uma pressão social de a contrariar. “social” aqui não significa “da sociedade” mas “por meios sociais” em oposição a “por meios técnicos”.  É por isto que soluções brilhantes podem ser destruídas por gostos e desgostos do cliente, gerentes, diretores ,  com base em … Bom, com base em nada , realmente. Não existe nenhuma razão racional, apenas um desconforto em aceitar a ação técnica. O curioso é que nas poucas vezes que uma ação técnica consegue vencer o obstáculo da reação social, as pessoas quase sempre se surpreendem com os resultados.

 8. Lei dos Falsos Alertas

“À medida que a frequência de falsos alertas de problemas aumenta, a credibilidade de alertas subsequentes diminui”

Quando tudo o que o usuário não espera ver na tela é um bug, mesmo quando é um aviso do sistema dizendo que o usário fez algo errado (ou seja, mesmo quando é um erro previsto). Quanto todos os bugs são críticos e impeditivos, menos críticos impeditivos eles são de fato.  Esta lei representa o desconhecimento que os usuários e clientes têm do software que eles mesmos encomendaram e a tentativa estupida de manipular o fornecedor dizendo que tudo é erro e tudo é impeditivo para. Esta lei é fortemente presente em contratos de risco em que o cliente consegui colocar o fornecedor em uma posição de dívida e recompensa futura. Ou seja, tudo o que o cliente quer mudar, ele considera um erro. Isto porque o contrato considera que apenas quanto todos os erros estão resolvidos é que o software está pronto e o fornecedor irá receber seu dinheiro. Ora, isto é uma falácia (Lei fundamental do software – nunca todos os erros estarão resolvidos) . Assim o fornecedor se colocou em um situação em que perde sempre que o cliente encontra um erro. Então, tudo o que o cliente encontra é um erro para forçar o fornecedor e fazer o que se pede. O mesmo principio é usado com a prioridade. Tudo é impeditivo para que o fornecedor sinta que não irá receber o seu dinheiro se não resolver aquele problema.

Sabendo desta lei os fornecedores devem realizar bons contratos, com estipulação especifica do que significa “impeditivo”  e “erro”. Os fornecedores deve aconselhar e treinar o cliente a entender a escala. O fornecedor deve medir a razão “falsos alertas” / “todos os alertas”  e a sua frequência. Sempre conversar e mostrar estes números ao cliente explicando que isto está atrazando o projeto e causando esforço desnecessário. Claro, que medidas de minimização do problema devem ser propostas e aplicadas tais como o treinamento, a redação de manuais e o teste acompanhado.

 9. Lei de Hoare

“Dentro de cada grande problema, existe um pequeno problema lutando para aparecer”

Considerado a Lei de Pareto é sabido da probabilidade  de um grande problema pode ser originado um pequeno problema. O que a lei de Hoare no diz não isso. O que ela no diz é que depois de resolver um grande problema ou enquanto um grande problema é resolvido, pequenos problemas aparecem.  Isto leva à multiplicação dos problemas e por consequência a um aumento no esforço de corrigir o problema original.  Por outro lado, podemos interpretar que todo o grande problema é constituído de pequenos problemas.

Esta lei está diretamente relacionada com o problema da manutenção e como o design do sistema têm que ser simples de forma a que cada pequeno problema seja o mais facilmente solucionável, já que é bem provável os encontremos quando resolvemos problemas grandes.

10. Lei de Hofstadter

“Uma atividade sempre consome mais tempo do que esperado, mesmo quando você leva em consideração a Lei de Hofstadter”

Está é uma lei recursiva. A recursividade dá-lhe um ar nerd, mas realmente é necessária. Esta lei significa que você sempre irá estimar errado a duração de uma atividade e/ou ela sempre demorará mais do que esperado por si, mesmo quando você conhece esta lei, ou seja, mesmo quando você estima a mais do que a sua intuição. Aconteceu comigo quando escrevi este post. Afinal quão dificil é elencar o top 10 das leis do software. Bem, é mais dificil do que parece…

Existem muitas outras leis e corolários relacionados ao software [1][2]. Tomeis as 10 que são mais genéricas e com as quais me deparo todos os dias. Existem muitas outras especificas de tecnologias, situações, tipos de software , algumas ligadas a harware como a famosa Lei de Moore ou algumas demasiado genéricas para serem elencadas como leis de desenvolvimento como a Lei de Murphy ( “Se algo errado poder acontecer, irá”)

Em próximos posts irei discorrer sobre como estas leis se relacionam ao Scrum tentando demonstrar que porque o Scrum se aproveita destas leis, ele funciona. Também tentarei falar sobre leis mais próxima ao código e ao design que deriva destas leis mais genéricas.

O Java 7 traz algumas alterações na linguagem Java,  algumas alterações na JVM e algumas API novas. Além disso temos a primeira alteração no bytecode desde sempre. Podemos dizer que o tema do Java 7 é “Criar caminho para o Futuro” (leia-se Java 8 e 9). Como alterações na Linguagem temos : Swicth com Strings ,melhor inferência de tipos com operador diamante e alterações para invocação de var-args , melhores literais para números,  base binária e melhor suporte a tratamento de exceções (multi-catch , re-throw e try-with-resources) e suporte a unicode 6.0.  Para as API temos a nova API de processamento paralelo Fork-Join  e a nova , muito aguardada , FileSystem API (parte do novo pacote de IO:  NIO.2) .Existem também alguns melhoramentos na API java.util.Locale para  internacionalização como a nova enum Locale.Category que permite distinguir objetos Locale para display e para formatação. A NIO.2 traz também suporte a mais protocolos de cominicação como SCTP , SDP entre outros. A alteração no bytecode é a nova instrução invoke dinamic que traz consigo a nova API de manipulação de métodos. Além disso muitas melhorias na renderização. A lista completa de mudanças na pagina de release da Oracle

Não vou exemplificar cada alteração existem muitos sites sobre isso. Quero, em vez, me debruçar sobre  as causas e consequencias das alterações.

Switch com Strings. Esta funcionalidade é a mais perigosa de todas. Não vai ajudar a escrever programas melhores já que vivemos escrevendo programas sem ela ha 15 anos. Adicionar esta capacidade só vai ajudar a cria Programas Orientados as Strings (POS) ou pior, programas orientados a gambiarra (POG). Uma discussão interessante sobre switch e sua historia aqui. Mas o objetivo desta funcionalidade não é melhorar o Java. Esta era uma requisição de melhoria desde o java 1 que não viu a luz do dia devido ao problema associado à função de hash usada na classe String que foi modificada e melhorada ao longo do anos. É que, para isto funcionar, é necessário usar a função de hash para transformaro switch de string em switch de int que é o que realmente funciona eficientemente, mas para isso o resultado do hash tem que ficar hardcoded no .class. O Java 7 deu este passo estabelecendo que a implementação de hashCode do String não irá mudar mais. Mas será que não ? Eu por mim vou continuar não usando Strings para este tipo de coisa. Aliás uma regra bem válida do Efective Java.

Melhorias na inferência de tipos. O operador diamante é bem vindo já que nos livra de repetir um monte de assinaturas de tipo. Para quem já escreveu mapas de coleções sabe do que estou falando. Além disso usar tipos genéricos em var-args não causa mais um aviso do compilador.  Nada do outro mundo para o programador, mas o trabalho que o compilador faz para inferir os tipos e , no seu melhor, evitar erros, é extraordinário. Uma alteração direcionada a nos fazer escrever menos respondendo às criticas que o java é muito verborraico.

A possibilidade de escrever numeros em base binária é relativamente interessante. Útil se você mexe com protocolos/arquivos binários. A nova possibilidade de separação de algoritmos com underline ajuda bastante a formar os bytes ou as palavras. Uma mudança à primeira vista estética, mas que é direcionada a usar java como uma linguagem de “baixo nível” para ler e escrever binário.

A grande alteração da linguagem são as novas funcionalidades relacionadas ao bloco try-catch. A primeira é a possibilidade de capturar multiplas exceções de um catch só. Isto ajuda a escrever menos blocos de codigo e ajuda a seguir o principio DRY (Don’t repeat yourself – Não se Repita). Contudo criaria um problema caso você pense em relançar a exceção.  A inferencia de tipos entre em jogo aqui também. Ao relançar a exceção o compilador sabe fazer o traking de quais exceções são possiveis dentro do try e portanto quais são possiveis para relançamento.

A outra mecanica que se aproveita do relançamento é o novo try-com-recursos que é uma forma de trabalhar com recursos “fechaveis”. A nova instrução toma conta de chamar o .close no momento certo e tratar as exceções que são lançadas no close.   É um problema quando você acessa o banco, dá erro no resultset você captura e fecha a conexão, mas ai dá erro no fechar da conexão. A exceção que você recebia era a que aconteceu no close e não a que aconteceu no resultset. Isto era realmente um problema e se você quisesse controlar isto. Agora, o java 7 modificou essa regra – desde que use o try-com-recursos  – em que a exceção lançada é a exceção original, e a excação secundária (chamada de exceção suprimida) é adicionada ao stackstrace de forma “paralela” usando os novos métodos na class Throwable addSupressed e getSupressed. O controle de exceção ficou ainda mais robusto.

isto é importante porque é usado no URLClassloader. Este é o classloader mais utilizado que não tinha uma semantica de fechamento, e agora que tem, sem um mecanismo robusto como o try-com-recursos , continuaria dando memory-leaks. A sintaxe não é a mais intuitiva (estão planejadas melhorias para o java 8), mas é uma instrução de controle muito importante e que faltava no arcenal.

O tema do Java 8 será “Multicore” e o do Java 9 “Cloud”.

Para multicore dar certo o fork-join é um framework necessário. Existiu muita polemica se seria util lançar este framework sem lançar closures (lambdas), mas acabou saindo. Lembrar que esta versão do java é mais para desenvolvedores do que usuários e em particular para desenvolvedores que desenvolvem mecanismo em cimado java (como quem desenvolver as ‘vm’ de jruby, scala , etc…) . Com a liberação “adiantada” estas equipes têm mais tempo para se preparar para o mundo com lambdas do java 8.

Para o cloud dar certo, além do multicore, é preciso abstrair o sistema de arquivos. Servidores de aplicação poderão tirar partido disto. A nova API de Filesystem permite trabalhar não apenas com discos da máquina, mas criar sistema virtuais de arquivos , por exemplo, acessar um zip como se fosse uma pasta. Isto é uma tendencia e era aguardado ha muito tempo ( aliás eu já tinha abordado este assunto de arquivos virtuais no MiddleHeaven). Mas API que fará ainda mais diferença – expecialmente para criadores de ferramentas e servidores -  é a API WatchService que permite registrar listeners para escutar quando arquivos são modificados, incluidos ou excluidos. Hoje isto é feito com threads e timers, mas com a nova API estaremos ligados diretamente ao sistema operacional que avisará a API quando algo mudar e a API nos avisará a nós. Espero que as proximas versões de servidores de aplicação se baseiem nestas features.

Resta falar sobre o invoke dynamic. Esta instrução do bytecode permite que se invoque um método sem que se saiba qual a sua implementação. A implementação do método será pesquisada em runtime. É um mecanismo bem complexo que permite criar links dinamicos com métodos em runtime. Isto é ideal para linguagens como groovy e ruby que permitem chamar métodos em classes como se eles lhes pertencessem mas na realidade não estão definidos na classe (  e sim em alguma outra classe ). Esta instrução é orientada a simplificar a vida de quem tem que implementar as vm das linguagens dinamicas e com isto tornar a JVM realmente poliglota.

A API Java foi incrementada para poder manipular métodos de forma programática. Isto é interessante porque é agora possivel criar operações de currying e outras coisas interessantes da programação orientada a funções mesmo ainda sem lambdas.

À parte da swicth de strings que navega contra a maré o resto das alterações é bastante poderosa. O ponto é que toda esta capacidade é em potencial e não muito “pártica” ainda. É mais ou menos como o generic do java 5, demorou um tempo até que as pessoas se abituassem e começassem a fazer coisas interessantes com a ferramenta. O Java 8 promete uma mega alteração da forma de programar em java, e o 9 uma mega alteração na forma como entendemos JEE  , mas o Java 7 lança as bases e traça algumas direções dando ferramentas para aumentar a eficácia dos códigos e o alargamento da base de linguagens que rodam na JVM.

Se começasse um projeto novo hoje, muito provavelmente usaria java 7, não pelo que ele traz de novo, mas como preparação para o java 8 que, se tudo correr bem, irá ver a luz do dia em 2013.

O modelo que iremos usar como base é este (clique para aumentar):

Bom a primeira coisa é o conceito de banco e  agencia. A agencia não é um banco. E um banco não é uma agencia. O banco é uma entidade jurídica, a agencia é uma representação ( uma filial) dessa entidade jurídica. Um banco tem muitas agencias e uma agencia pertence a um banco. Portanto, não é uma relação de herança que queremos usar e sim uma composição.  Um banco tem contas, e as contas estão relacionadas a uma agencia. Portanto, a conta corrente pertence a uma agencia e não ao banco. Como a agencia pertence ao banco é possível encontrar todas as contas do banco iterando todas as agencias que o banco tem. A relação de composição da conta seria no nivel da agencia e não no do banco.

As operações de CRUD não devem estar na entidade, a menos que isto se trate de um modelo conceptual de negocio ( por oposição a um modelo de implementação). Vou partir da premissa que é esse o caso ou explicitar as operação não faria sentido algum.

Endereço é uma coisa complexa por si mesma, mas não me parece que haja um problema na sua modelagem.

O NIF não é um inteiro, é um código. Códigos devem ser representandos com String. O titulo se relaciona a vários clientes no papel de sacado, cedente, etc.. cada um destes campos é um cliente. Não ha necessidade alguma de criar entidades no meio para qualificar a relação. A relação já é qualificada pelo nome do campo no titulo. Acho que esse é o ponto mais estranho do modelo que além de inútil cria bastante confusão.

Nilson, espero seus comentários.

[Editado]
O Nilson enviou outro modelo

Vi que deu uma limpada. Ficou melhor. Mas ainda existe o problema entre o Banco e a Agencia. O Banco não têm uma campo agencia. Ele tem múltiplas agências. E cada agência tem um Banco.