sexta-feira, 28 de março de 2008

Codificação zero

Versus escrever código atrás das caixas

 

BPMN e BPEL fazem para uma combinação extremamente poderosa porque apresentam um caminho do diagrama ao código sem ter que realmente escrever o código. Vamos enfrentar isto, muito trabalho no desenvolvimento destas duas especificações, foi beneficiado pela quantidade de experiência coletiva sem precedentes que nenhum fornecedor poderia combinar com seus próprios recursos. O que esse significa é que a maioria de produtos de BPM, que são baseados em notações proprietárias e em linguagens da execução realmente requerem a escrita de bastante código a fim fazer processos executáveis. Duplo clique sobre as caixas e as setas, e códigos escritos em Java ou as linguagens proprietárias mostrarão sua face. Nada contra o código, mas apenas que manter é mais difícil e mais caro do que a escrever. A BPM 2.0 possibilitou executar os processos mais complexos sem ter que escrever o código. O governo holandês fez apenas aquele para um processo que tivesse um quarto de milhão atividades, assim que se trabalhar para elas em tal escala, deve trabalhar para muitas outras organizações.

Mas por que codificação zero importa? Esta é a oitava edição da nossa publicação semanal do BPM 2.0. Hoje, eu tentarei explicar porque o código zero importa. A maioria das soluções de BPM necessitam que os usuários escrevam manualmente o código atrás das caixas e das setas usadas descrever um processo. Não há nada de errado sobre código do software, mas o código é uma das coisas para que menos é mais, e há mais de uma razão para que seja verdadeiro.

Primeiramente, BPM necessita a participação de analistas do negócio, mas os analistas do negócio não podem ler nem escrever código. O pessoal técnico habilitado poderia escrever o código atrás das caixas e das setas que os analistas do negócio extrairiam, mas das eles não ajudariam realmente a construir uma ponte entre o negócio e o TI, dividindo-se? BPM 2.0 advoga um modelo onde os processos executáveis sejam executados por analistas de processos, e estes poderiam escrever o código se tivessem que realmente, mas tendem a preferir usar ferramentas gráficas preferivelmente.

Há 8 milhões de programadores Visual Basic hoje . é a maior comunidade programadores hoje . e deve haver uma razão porque Microsoft chamou de BASIC sua ferramenta de desenvolvimento Visual. Se nenhuma lógica do negócio puder se esconder atrás das caixas, os analistas do negócio será mais provável, que os analistas de processos compreendam o que fizeram, e esta é uma maneira certa construir uma ponte entre o negócio e o TI divididos, para não se destruir inteiramente.

Em segundo, os seres humanos fazem erros, e o exercício do código da escrita é um erro - propenso. Na média, uma forma do processo em BPMN leva a 10 linhas do código de BPEL, e uma linha do código de BPEL substitui aproximadamente 10 linhas do código de J2EE. Significa que 100 linhas do código J2EE desagradáveis teriam que ser escritas se as ferramentas da geração de BPEL não existirem. Se seu processo tiver centenas ou milhares das etapas (ou de 250.000 como o um Intalio construiu para o governo holandês), aquele é dezenas dos milhares ou de centenas de milhares das linhas do código. O código comercial tem tipicamente em qualquer lugar de um a sete erros por 1000 linhas do código de acordo com um relatório do National Cyber Security Partnership.s Working Group on the Software Lifecycle (Source: ZDNet).

Isto significa que em média o projeto de BPM terá centenas, se não milhares de erros nele, que terá que ser reparado manualmente, um por um. Se você deixar uma ferramenta zero do código BPM gerar o código para você, você não tem que preocupar-se mais sobre estes erros. Concedido, o gerador de código da ferramenta de BPM poderia ter alguns erros, mas será provavelmente serão reparados pelo fornecedor antes que você obtenha os erros que você mesmo criará escrevendo o código manualmente. Além disso, uma vez que os erros da ferramenta são fixos, produzem o código válido qualquer um que usa.

Finalmente, o código do software for geralmente imperativo, quando o código zero projeto-dirigido o desenvolvimento tende a ser muito mais declarativo na natureza. O que estes os meios são que a informação contida dentro dos diagramas de BPMN é muito mais explícita, essa informação equivalente encaixada no código de J2EE ou de C#. Uma informação mais explícita, mais fácil começa com a plataforma de BPM forneça a simulação, eliminando erros, relatando e potencialidade de otimização. Para encurtar a história, o código é melhor escrito pelo fornecedor e os clientes devem focar seus esforços em melhorar seus processos do negócio melhor que o código usado para suportá-los.

http://www.projeler.com.br/artigos_bpm20h.jsp

 

Nenhum comentário: