Daniel Tamiosso

Muitos são os casos de softwares mal-sucedidos e prontos para o insucesso em sistemas desenvolvidos sem um estudo e planejamento inicial. Até mesmo a forma como ele é desenvolvido durante a duração desse ciclo determina seu fracasso. O que realmente acontece quando estamos frente-a-frente com essa situação todos sabemos. A sensação de insegurança é predominante. Não temos nenhuma confiança em utilizar muitos objetos do projeto. Não temos confiança por não termos um contrato definido. Isso acontece, primeiramente, porque temos um sequência de códigos legados mal-escritos. Onde o profissional que projetou determinado objeto do software não se preocupou em como iremos usar determinado resultado de um método por exemplo. Afinal, em muitos casos, pela falta de conhecimento no domínio do negócio não saberemos lidar com uma informação nula. E como não sabemos se isso realmente poderá acontecer, estabelecemos aquela sequência de testes verificando a nulabilidade de determinada ação. Sem nem realmente sabermos onde queremos chegar com aquilo. Querendo apenas evitar uma exceção de sistema.

Podemos evitar essa situação, criando um projeto de software realmente confiável em termos de codificação, que cá pra nós é a parte mais importante do projeto. Faremos isso programando defensivamente, buscando utilizar práticas de codificação defensiva, já que não temos contratos pré-estabelicidos. Evitando assim, o mal uso deles pelos demais desenvolvedores. Afinal, se alguma coisa pode dar errado, ela indiscutivelmente dará errado. É a lei.

Como não temos um contrato pré-estabelicido em nosso projeto em andamento, utilizamos a programação defensiva para evitarmos mais dor de cabeça. Com ela garantimos que quem utilizará nossos objetos obtenham um resposta segura, não importando o que realmente ele quer que aconteça. Ou seja, sempre procuraremos por todas as coisas que podem dar errado e executaremos uma quantidade excessiva de testes para evitarmos situações embaraçosas no nosso software.

A prática mais utilizada na programação defensiva é a utilização de exceções para casos que precisamos evitar a continuidade do fluxo para determinado valor do objeto. Normalmente utiliza-se exceções checadas. Lembrando que existem casos e casos, e a verdade absoluta é algo que realmente não existe. Então se você pensa que uma exeção não checada é a melhor saída: vá em frente, pois uma exeção checada trará sempre mais código para quem reaproveitará o código. Dependendo do caso, o retorno de um objeto vazio pode significar muito mais que o retorno de um objeto nulo.

Outro prática que podemos adotar em uma programação defensiva é dar a devida importância aos dados de entrada em nossos sistema. Sabemos que apartir de um dado errado, muitos outros se perpetuarão no nosso sistema. Então, seja qual for a fronteira: sistema externo, cadastro básico, rotina de movimentação, não interessa. Todos os dados devem ser válidados. Jamais pense na camada de visão para isso. Toda e qualquer validação de dados nunca deverá ser garantida aí. Afinal cada objeto com sua responsabilidade.

Acredito que a melhor forma de garantirmos segurança e confiabiliade no desenvolvimento de um software são os testes. Use e abuse deles. Crie scripts de testes que testem todos os seus componentes e a saída experada por eles. Qualquer modificação errada no código de seu software devem ser inválidadas nos seus scripts de testes. A grande sacada para isso chama-se desenvolvimento dirigido por testes, o famoso TDD. Vale a pena aprofundarmos nesse assunto.

Um sistema de logs bem construído também nos ajuda a encontrar os principais pontos de falhas do nosso sistema. Nunca ignore esse item na elaboração da arquitetura do seu projeto. Você realmente precisará dele para não perder algumas noites de sono.

Uma coisa que vejo periódicamente é o uso dos famosos “domains”, algo que se originou da programação estrutural. Então vemos aqueles testes absurdos com atributos do tipo String. E os erros são inevitáveis. Por favor, conheça a linguagem de programação que você está utilizando no seu projeto. Para esses casos use e brigue pelo uso de enumeradores. Outra pedida é: documente seu código. É importante. Mas nada de desenhar balões e aquelas coisas bizarras, ok? Seja simples e direto.

Reduzir a complexidade do nosso código e atacarmos o menor ponto de funcionalidade de cada caso de uso  separando qualquer algoritmo no menor tamanho possível é outra prática a ser adotada no desenvolvimento. E cada vez que você divide a sua aplicação, você começa a se repetir. Isso gera mais análise e mais projeto pra cada tomada de decisão, aumentando as chances de termos um código coeso e levemente ligado.

Lembre-se que o cliente não liga pra diagramas bem desenhados, uma lista de requisitos em um documento bem elaborado. O que realmente interessa para o cliente é software fazendo alguma coisa concreta. De preferência com a maior qualidade e confiabilidade possível. O desenvolvimento de um software consiste em repetição. Nada de etapas separadas. Na verdade nada de etapas. Quanto mais específico for nosso caso de uso melhor. Iterações curtas até o resultado esperado pelo cliente. E não tenha medo de ser chamado de retranqueiro.

Popularity: 14% [?]

O paradigma orientado a objetos, como o próprio nome deixa claro, parte do principio que o foco de quem irá analisar/projetar/desenvolver… deve ser totalmente direcionado para os objetos. Parece ser muito simples e na verdade eu acredito que seja, pelo menos até que me provem o contrário. Sim, pois acredito – e muito – na idéia básica de que um projeto de um sistema de informação deve sempre buscar a simplicidade. Penso nisso com base em um pensamento de Da Vince: “A simplicidade é o último grau de sofisticação”, que meu amigo Wagner Andrade gosta, e muito, de citar.

Mas a bem da verdade, a maioria dos projetos que encontramos e participamos no nosso dia-a-dia não seguem essa premissa básica. Desde a escolha das tecnologias até aos processos (ou a escolha pela falta deles) que serão empregados no gerenciamento do mesmo.

Quando utilizamos orientação a objetos, não podemos ficar presos apenas a conceitos acadêmicos, como: os objetos normalmente são definidos com métodos e assim por diante. Tudo bem, até pode ser uma afirmativa verdadeira. Mas essa é uma visão um tanto quanto limitada para definirmos uma visão concreta para um objeto.

Podemos dizer que um objeto é algo - qualquer coisa, envolvida no nosso domínio de negócios – e que tem apenas uma responsabilidade: a sua. E é essa responsabilidade que determinará comportamentos ao objeto. Essa é uma definição que nos ajuda em pensar o que os objetos provavelmente irão fazer e não apenas em como o implementar.

No desenvolvimento orientado a objetos podemos usufruir de alguns princípios para nos auxiliar no projeto de um sistema de informação. Um dos mais conhecidos deles, por incrível que pareça não é o POG, mas sim o SRP – que traduzido para o português, significa: princípio da responsabilidade única. Ou seja toda e qualquer classe deve possuir apenas uma razão de ser, estar e existir. Vale lembrar que todos os seus serviços devem estar preparados para externalizar somente essa única responsabilidade. Nada além do que se vê.

Como exemplo, podemos utilizar uma classe Automóvel para entendermos a aplicabilidade do princípio. Um automóvel tem a responsabilidade básica de locomoção. Então o mesmo poderá realizar ações como: andar, parar e receber gasolina. Mas jamais poderá ele mesmo trocar os pneus, dirigir, trocar o óleo e assim por diante. Essas são tarefas, respectivamente, do mecânico, do motoristo e do frentista. E não do carro. Tudo bem que até poderia ser uma boa idéia, mas infelizmente não é o que acontece.

Com esse princípio aplicado de maneira correta, estaremos dando um grande passo pra evitarmos o acoplamento de classes, aumentando, também, as chances de termos um domínio de modelos com alta coesão. Essa idéia nos permite desenvolver o software em dois passos: fazer um projeto preliminar sem se preocupar com todos os detalhes envolvidos; e implementar o projeto alcançado anteriormente.

Uma observação: desculpa pela demora pelos posts, estou na Indonésia, trabalhando na implantação de um importante projeto a dois meses e completamente sem tempo. Prometo ser mais assíduo no meu blog de agora em diante.

Abraço a todos.

Popularity: 24% [?]

Introdução

Seguindo com a série de posts sobre EJB, vamos explanar e entender o suporte que ele proporciona no gerenciamento de transações. Primeiramente, precisamos entender o conceito de transação.

Na vida real realizamos diversas transações diariamente: desde bancárias até mesmo amorosas. Por exemplo, você só leva pra casa a camisa do maior time do Brasil (para os menos informados, falo do glorioso Internacional), se a operadora do seu cartão de crédito autorizar a compra. Caso contrário, a camisa fica lá iluminando a vitrina da loja. Assim, também, podemos relacionar os casos amorosos. Neles precisamos seguir uma cartilha de regras (para os homens: lêia-se o complicado mundo das mulheres) a nós impostas, para podermos levar a um final feliz (ou pelo menos uma tentativa disso) a relação. Caso contrário…

Então uma transação é tudo aquilo que envolve uma série de ações onde o seu desfecho final depende do sucesso dessas ações para poder acontecer (committed). Caso contrário todas essas ações são desfeitas imediatamente (rolled back).

No nosso incrível mundo de desenvolvimento de sistemas, as transações funcionam seguindo
essa mesma linha de raciocínio. Nele as transações são contempladas por quatro características, denominadas pelo acronômo ACID (Atomicidade, Consistência, Isolação e Durabilidade).

Propriedades ACID

• Atomicidade: transações são atômicas desde sempre. Isso quer dizer que: ou tudo é executado com sucesso, ou seu estado original é retomado.
• Consistência: somos os responsáveis diretos por cuidarmos dessa propriedade. Por isso é a mais delicada desse grupo. Está diretamente ligada a forma como escrevemos o código. O sistema de informação deverá estar consistente com seus dados e regras de negócios ao término da transação se o mesmo a iniciou assim. Embora durante uma transação o sistema não necessita estar consistente com essas informações.
  
• Isolação: todas as mudanças que são realizadas durante uma transação podem ser isoladas, isto é, tornadas imperceptiveis para outras transações até que a a mesma seja finalizada. Isso ocorre em sincronização de threads e “locking” em um banco de dados. Essa característica é muito importante para ambientes onde existem muitos processos concorrentes.
• Durabilidade: uma vez uma transação finalizada com sucesso (commited), seus dados devem estar devidamente armazenadas e não podendo ser desfeitas. Ou seja, uma vez confirmada a transação, temos que garantir que seu resultado é “durável”.

Gerenciamento de transações

As transações quando são responsáveis por gerenciar somente um recurso, é uma transação local. Entretanto, na experiência do dia-a-dia sabemos que isso não é algo tão comum. O momento é todo das aplicações distribuídas. E apenas um recurso de armazenamento de dados, muitas vezes, não é o suficiente. Por isso existe o transaction manager, que é o responsável por abstrair toda essa complexidade para nós. É ele que coloca todos esses recursos dentro de uma única transação.

Para que isso possa ocorrer com sucesso ele usufrui do chamado Two-Phase-Commit, que consiste basicamente em dividir a fase de commit de uma transação em dois passos. Primeiramente verifica se existe a possibilidade de commit em todos os recursos envolvidos. Caso sim, deixa todos eles em estado commitment (compromisso). E só após todos estarem “compromissados” com a transação é que realmente ela será commited.

O protocolo mais utilizado e recomendado para coordenar o Two-Phase-Commit é o Protocolo XA. Ele é o responsável por fazer com que os recursos envolvidos e o transactional manager falem a mesma língua tornando assim viável essa comunicação.

Todo o suporte que EJB dá a transações é fornecido através da JTA (Java Transaction API). É ela que expõe as funcionalidades que são distribuidas na camada de gerenciamento de transações pelo servidor de aplicação. Com isso temos duas saídas básicas para gerenciarmos nossas transações:

• Container-Managed Transactions (CMT): pode ser configurada com anotações ou com um descriptor. Elas iniciam antes da chamada de um método de negócio de um EJB e dependendo dos acontecimentos na execução desse método a transação é rollback ou commited. Elas podem ser classificadas em:

1. Requerid (requerida): onde o container cria uma transação ou, se houver uma transação no método que chamante, cria uma junção (continuação), dessa transação.
2. Requires new (requer nova): onde o container cria uma transação ou, se houver uma transação no método que chamante, suspende esta transação e cria uma nova transação.
3. Supports (apoia): onde o container não cria uma transação se não houver no método chamante, ou se houver realiza uma junção (continuação), dessa transação.
4. Mandatory (obrigatória): sempre precisará de uma transação anterior para poder realizar uma junção com ela. Caso contrário lançara uma exceção.
5. Not suported (não suportada) : Se não houver transação anterior, aqui continua sem também. Se houver, ela é suspensa e o método continua sem controle de transação.
6. Never (nunca): Se não houver transação anterior, aqui continua sem também. Se houver, é lançada uma exceção.

• Bean-Managed Transactions (BMT): requer uma configuração programática onde devemos mostrar onde teremos uma transação e onde ela poderá realizar um roll back através da chamada da interface javax.transaction.UserTransaction.

Bom, isso foi só algumas referências básicas sobre o funcionamento das transações com o uso de EJB. Com o tempo quero aprofundar o artigo aqui no blog.

Muito obrigado pela leitura.

Abraços a todos.

Popularity: 46% [?]

Session Beans

Basicamente, de acordo com a especificação de EJB, os Session Beans representam objetos transientes. Disponibilizados em um servidor de aplicações, eles podem ser acessados remotamente por diversos clientes. São os responsáveis por modelar processos de negócios de um determinado caso de uso e de tarefas referentes a um cliente.

Bom, conhecendo os princípios básicos dos Session Beans, podemos começar a entender as diferenças e o motivo do uso entre os dois tipos em que são classificados: Stateless e Stateful.

Stateless

Normalmente destinam-se a executar automaticamente operações individuais não mantendo o seu estado para cada invocação de um método. Cada cliente pode usar em qualquer momento uma instância de um Stateless Session Bean. São leves, pois o servidor de aplicação mantem um certo número de instâncias preparadas para receber requisições de seus clientes. Ao término de cada requisição suas instâncias retornam para o pool para serem reutilizadas. Por isso um pequeno número de Stateless Session Beans garante um número relativamente grande de requisições de clientes.

Stateful

Sua principal característica é a manutenção de estado entre as suas operações. Por isso é associado a um cliente específico. Para manter os estados das operações o Stateful Session Bean implementa a interface SessionSynchronization. Sendo assim o cliente pode facilmente configurar os valores dos atributos do bean, para serem utilizados nos métodos de negócios. Mas a manutenção de estados tem seu preço, uma instância não pode ser facilmente devolvida ao seu pool enquanto uma sessão entre o bean e o cliente ainda está ativa. Vale lembrar que os dados de uma sessão são transientes e não foram projetados para serem persistentes.

Diferenças e afins

Quando usamos Stateful mantemos o estado da conversação com o cliente. Esse estado é mantido somente enquanto durar essa conversação. Ou seja, quando o cliente termina a sessão o estado do bean é destruído. Para isso temos que garantir que quando a conversação é encerrada nem o estado nem o bean deveriam ter utilidade para o cliente.

Totalmente o oposto disso o tipo Stateless mantém estado de conversação apenas durante a vigência da invocação de um método. Após isso, os estados de todas as variáveis do bean são perdidos. Portanto os beans Stateless nos dão alguns benefícios como: escalabilidade, pois são capazes de atender de forma escalável um grande número de requisições comparadas aos beans Stateful; e desempenho, pois container EJB nunca irá mover um bean Stateless da memória RAM para um armazenamento secundário, o que poderá fazê-lo com um bean Stateful.

Boas práticas

A escolha do tipo de um session bean tem que ser realizada cuidadosamente. Sabemos que os Stateful Session Beans têm um preço caro no mercado. As interfaces de acesso devem ser analisadas cautelosamente. Interfaces remotas envolvem acesso a rede podendo ser crucial para um baixo desempenho e a escalabilidade das nossas aplicações. Se utilizarmos somente uma máquina virtual então uma interface local será o suficiente.

Caso utilizarmos Injeção de Dependência devemos certificar que não estamos injetando um Stateful Session Bean em um Stateless Session Bean. Pois informações de estados serão armazenadas em uma instância variável e estarão disponíveis para todos os clientes, contendo assim informações imprecisas. Agora injetarmos um Stateful Session Bean em outro pode ser uma boa solução para alguns casos.

Uma boa prática é separar em interceptadores as rotinas de logging e de auditoria, tento assim as regras de negócios limpas de outras funções que não condizem com o processo em si. Devemos ter cuidado também nos tipos de dados que estaremos armazenando em nossos Stateful Beans, principalmente com aqueles grandes objetos compostos. Existem algumas formas de melhorar o uso de um Stateful Bean, que estarei comentando nos próximos posts como: passivation e configuração de timeout ideal.

Popularity: 63% [?]

Qual mortal desenvolvedor de sistemas que trabalha, principalmente, com Java nunca entrou em contato com o Apache Tomcat. Bom, mas para aqueles menos informados, saibam que ele é conteiner web, cuja função é servir aplicações web escritas em Java. Foi desenvolvido pela Apache Software Foundation

Vale lembrar, que o seu código é aberto e que a SUN considera o projeto como a Implementação de Referência para JSP e Java Servlet.

Em muitos casos, no nosso dia-a-dia, não temos acesso a JVM e ao SO no qual implantamos nossos sistemas. O que resta a nós, nesses casos, para incrementarmos a performance do Tomcat é configurará-lo internamente. A seguir, cito duas dicas básicas, de configuração interna do Apache Tomcat.

Ajustando o número de Threads:

Uma forma de controlar a performance de suas aplicações é ajustando o número de requisições das threads em uso. O Tomcat define por padrão um pool de threads para prover uma resposta rápida aos pedidos recebidos. Normalmente essa configuração padrão normalmente é suficiente para a maioria dos aplicações. Mas você pode ajustar esse pool de acordo com a real necessidade de sua aplicação. Para isso definimos as propriedades “minThreads” e “maxThreads”.

Um exemplo para a configuração da propriedade minThread é a seguinte: em um pequeno momento do dia seu site recebe dez requisições por segundo e cada requisição demora 1 segundo para ser processada, um minímo dez threads, alocadas inicialmente, deve ser o suficiente para garantir uma boa performance do seu servidor.

Agora precisamos configurar o máximo de threads que o servidor irá disponibilizar. Pois, provavelmente, teremos picos de acessos em determinados momentos do dia. Caso isso ocorra, o valor que definirmos na propriedade maxThreads, será o máximo de threads que serão realocadas aquelas iniciais para garantirmos que o servidor não fique ocupado, e garanta as requisições solicitadas. Só não podemos esquecer de termos um limite de thread que condiz realmente com a nossa real necessidade. Visto que, um número alto nessa configuração, poderá estourar a memória da JVM em um ataque malicioso que realizará um ataque em massa no servidor.

Podemos utilizar para testar as nossas configurações, ferramentas que realizam uma carga no servidor configurada por nós. E com a análise dos resultados obtidos podemos chegar a um ponto adequado para as nossas aplicações.

Essa configuração é feita no conector de sua aplicação no arquivo server.xml.

Desabilitando pesquisas de DNS

O servidor, onde está localicazada a nossa aplicação, precisará para gerar um log sobre cada requisição de um cliente, algumas informações com o número do IP ou o resultado de uma pesquisa na busca do seu nome no DNS. Porém, pesquisa de DNS utilizam banda de rede, envolvendo troca de informações de vários servidores.

O que pode acontecer é que um desses servidores poderá ficar inoperante, resultando em tempos de espera pelo nosso servidor. Para evitarmos isso podemos desabilitar as pesquisas de DNS. Após estar desabilitado, toda a requisição pelo servidor remoto (getRemoteHost() emHttpRequest), somente retornará o IP numérico, sem tentar resolver o seu nome.

Essa configuração também é feita no conector de sua aplicação no arquivo server.xml. Em um conector comum o atributo responsável por essa propriedade é o enableLookups.

Popularity: 66% [?]

Diagrama de implantação (deploy):

“Um diagrama que mostra a configuração dos nós de processamento em tempo de execução e os componentes, processos e objetos que neles vivem.” (tradução livre de UML v1.4, página B-7)

Um dos diagramas que acredito ser um dos mais importantes é também um dos menos vistos nos projetos de sistemas de informação. O diagrama de implantação representa como é realizada a distribuição do sistema através de nós de hardware, componentes e dependências de software e as suas devidas relações de comunicação.

O diagrama de implantação pode ser representado de duas formas: como descritor, onde mostra o configuração básica do hardware; ou como uma instância, onde mostra as reais características de configuração de hardware.

Como exemplo podemos ver em seguida um simples diagrama. Ele mostra como uma máquina de um vendedor de uma loja se comunica com um servidor, utilizando HTTP sobre TCP/IP. E como a mesma máquina se comunica com um nó de hardware, no caso uma impressora qualquer, através de uma porta serial. O servidor de aplicações, identificado como sendo o Glassfish, através de um protocolo SSL, troca informações com o banco de dados. Também podemos notar as relações de dependência do servidor de aplicações para com o banco de dados, e dos clientes para com o servidor de aplicaçoes.

Os diagramas de implantação são empregados para modelagem da visão estática de implantação de um sistema. Com essa visão podemos analisar qual a real necessidade do projeto para a aquisição, por exemplo, de máquinas e pacotes de softwares adicionais. Ou seja, a importância do diagrama de implantação não está somente na possibilidade de visualizar e especificar fisicamente os sistemas, mas sim como um auxilílo no gerenciamento de projetos sistemas de informação.

Abraços.

Popularity: 100% [?]

Ainda falando sobre a BPMN, veremos logo em seguida os principais elementos que definem essa notação gráfica para a modelagem de processos. Espero que seja uma boa leitura e possível referência a todos interessados ou não.

A BPMN define quatro categorias principais de notações gráficas: objetos de fluxo, objetos de conexão, partições e artefatos. Analisando esses elementos chegaremos a conclusão que a BPMN disponibiliza um mecanismo simples e de rápida aprendizagem, mas que ao mesmo tempo oferece toda a possibilidade para o desenho de complexos processos inerentes as mais variadas organizações.

Partições (swinlanes):

• Participante (pool): representa um participante do processo. Dentro de um pool podemos ter um ou vários processos, dentro de um diagrama podemos ter vários pools. Um pool pode ser abstrato quando representamos, por exemplo, um sub-processo de um fornecedor, no qual não temos o seu total conhecimento;
• Raia (lane): As lanes são utilizadas para organizar e categorizar os objetos do fluxo.

Elementos de eventos:

Identificam algum evento realizado/esperado durante o fluxo do processo desenhado. Como por exemplo um evento de serviço, o recebimento de uma mensagem de outro sistema, uma rotina a ser executada pelo sistema…

Elementos de eventos de início:

Iniciam um processo, podendo ser representado por uma causa. Não recebe nenhum tipo de conexão e deve gerar uma ou mais conexões.

Podem ser divididos em:

• Mensagem: por exemplo, a chamada de um WebService ou um envio de um e-mail;
• Timer: regra de tempo ou um “clico” de tempo;
• Regra: algoritmo/rotina qualquer do sistema inerente ao processo;
• Link: usado para conectar o final de um processo com o início de outro processo. Por exemplo, dois sub-processos de um mesmo processo pai;
• Múltiplos: se uma das condições descritas nele for verdadeira, o processo inicia.

Elementos intermediários:

Utilizado para mostrar onde mensagens são enviadas ou esperadas. Utilizado, também, para mostrar tempo de espera ou mudar o curso normal do fluxo através do tratamento de exceções.

São dividas em:

• Padrão: indica alguma mudança no status do processo, não pode ser anexado a uma atividade;
• Mensagem: em uma atividade, representa uma exceção que é lançada ao recebimento de uma mensagem, dentro do fluxo normal, pode significar o “aguarde” pelo recebimento de uma mensagem;
• Timer: dentro do fluxo normal, é utilizado como um mecanismo de espera do fluxo, anexado representa uma exceção;
• Erro: no fluxo normal, significa o lançamento de uma exceção (throw exception), anexado a um nó, representa o tratamento de uma exceção (catch);
• Cancelamento: utilizado somente em sub-processos transacionais, para quando ser executado, todas as tarefas referentes serão canceladas automáticamente;
• Compensação: identifica uma operação-extra que será executada para compensar a ação realizada em um determinado nó.

Elementos de fim:

Um processo pode ter nenhum, um ou mais eventos de fim. Se possuir um início, então pelo menos um fim é obrigatório. O processo só é finalizado quando todas as atividades pendentes alcançam algum evento de fim. Seu objeto é simples: finalizar um processo, podendo ser representado pelo seu motivo:

• Mensagem: envio de mensagem ao fim do processo;
• Erro: um erro que foi gerado e deve ser tratado;
• Cancelamento: utilizado em transações, espécie de roolback;
• Compensação: identifica uma operação-extra que será executada para compensar o processo executado.
• Link: indica o fim desse processo com o início de outro;
• Término: todos os processos devem ser terminados imediatamente, mesmo que estejam em execução;
• Múltiplos: representa que o processo que poderá gerar mais de uma conseqüência. As mesmas devem ser descritas com a documentação de atributos do elemento;
• Conexão: pode receber uma ou mais seqüências, não pode receber conexões de mensagens, mas pode dar origem a uma seqüência de mensagem.

Transação

Determina que todas as atividades dentro deles sejam completadas com sucesso ou canceladas;

Compensação

Conjunto de atividades necessárias para cancelar o que foi realizada em determinado nó;

Loop padrão:

Atividade realizada até a condição ser falsa;

Multi-instância:

Utilizado no caso de atividade ter uma condição aonde exista a quantidade de vezes que a tarefa será executada;

Gateways

Controlam (convergem e divergem) o fluxo.

Gateway de decisão exclusiva (XOR);
Dá origem a duas ou mais conexões (cada uma com uma condição associada). As condição são avaliadas em uma determinada ordem, ao achar uma verdadeira as demais são ignoradas e o processo segue o fluxo normal. Ele parte do princípio que pelo menos uma condição é verdadeira (senão o fluxo foi modelado errado).
Podemos ter uma condição padrão (default - sempre verdadeira);

Gateway de decisão inclusiva:

Mais de uma condição pode ser verdadeira, originando fluxos paralelos;

Gateway complexo:

Para o analista de processo determinar uma regra de negócio customizada;

Gateway paralelo:

Criam fluxos paralelos e/ou sincronizam totalmente fluxos que estão em paralelo;

Artefatos:

Oferecem maiores informações sobre o processo;

Artefatos padrões:

• Dados: documento eletrônico ou não;
• Anotações: são textos e informações genéricas sobre o processo ou um elemento do processo;
• Grupos: modo informal de agrupar atividades, para melhorar o entendimento geral do fluxograma.

Conexões:

• Seqüência: determina a ordem do fluxo. Pode ser default (onde sempre é verdadeira a condição) e condicional (existe uma condição lógica intrinsecamente relacionada à conexão);
• Mensagem: troca de mensagens entre diferentes pools;
• Associação: conectar artefatos a objetos do fluxo e conectar atividades a outras atividades de compensação.

Um abraço a todos.

Popularity: 81% [?]

Introdução

Cada vez mais as organizações precisam de processos de negócios bem definidos e, ao mesmo tempo, totalmente flexíveis. E os sistemas de informação precisam acompanhar o seu progresso.

Através da BPMN podemos alcançar esses objetivos, através de uma notação gráfica padronizada para modelagem de processos de negócios que funciona como o meio-campo entre as áreas interessadas no planejamento estratégico da organização.

Um diagrama desenhado com base na BPMN é de fácil entendimento geral. Claro que todos os envolvidos precisam ter uma breve idéia do que se trata a BPMN e suas várias notações gráficas. Uma boa documentação da forma como ela será utilizada e modelos de documentação são requisitos básicos para o bom andamento dos desenhos dos processos.

Enfim, a BPMN tende a se tornar o tradutor oficial de diferentes perfis nessa conhecida jornada que coloca de um lado os famosos (e temidos por muitos) usuários e do outro lado, nós, os desenvolvedores de sistemas.

Observação

Muitas pessoas comentam sobre uma possível concorrência entre a UML e a BPMN, o que não é verdade. Pois, muito pelo contrário, a tendência é uma fusão entre as duas. Até porque, eu pelo menos, não consigo encontrar um ponto de comparação entre as duas, cada uma tem os seus fundamentos e objetivos.

Dicas de ferramentas

Para os desenvolvedores JAVA, a dica fica por conta do Jboss Tools, que traz consigo por padrão, ferramentas para edição e implantação de diagramas. Há também o ILOG JViews BPMN Modeler, de fácil utilização para a realização de desenhos de diagramas BPMN. Existem também boas indicações da ferramenta DIA.

Resumo dos principais conceitos da BPMN

Processo

É um conjunto de atividades, tarefas, práticas realizadas por uma organização e composta por uma série de etapas, definições e controles. Eles são divididos em:

• Processos internos: processos realizados unicamente dentro de uma organização;

• Processos abstratos: processos que são realizados fora do âmbito de uma organização, na qual não possuímos controle;

• Processos de colaboração: dois ou mais processos independentes e reutilizáveis se comunicam dentro do nosso escopo de visão;

Sub-processo

É composto por uma série de atividades e tarefas que formam um novo fluxo. Esse fluxo pode ser aberto (apresentado no mesmo diagrama do processo pai) ou fechado (podendo ser desvendado em um processo mapeado em outro diagrama). Ou seja, podem ser dependentes e desenhados dentro do mesmo diagrama ou independentes (reutilizáveis) e possuem um diagrama próprio. Normalmente utilizados para:

• Para representar processos reutilizáveis;

• Para controle e tratamento de erros em processos;

• Para ações de compensação em processos;

• Para controle de transações de processos.

Eventos:

Algo que acontece durante o andamento de um processo de negócio. Geralmente possuem uma causa e um resultado. São opcionais, mas altamente recomendáveis. Se não existir um início no diagrama, todas as tarefas que não possuem conectores que chegam nelas são iniciadas. Se existe um elemento de fim, o de início é obrigatório.

Atividades:

Trabalho realizado dentro de um processo de negócio. Pode ser atômica (isolada), ou não-atômica (composta). Podem ser um sub-processo ou uma tarefa.

Tarefas:

É o objeto que não pode ser quebrado em mais objetos. Geralmente executada por uma pessoa ou sistema. Ela pode ser bloqueante (a execução da instância do processo continua somente após a tarefa ser executada) ou não.

Bom, em breve estarei colocando aqui uma descrição dos diversos objetos definidos pela BPMN e mais informações que acho válidas para todos que querem conhececer um pouco mais sobre a BPMN. Abraços a todos.

Popularity: 76% [?]

Realmente o primeiro post não é algo muito fácil. Começar ou recomeçar é sempre algo desafiador. Porém, extremamente motivador. Essa é a vida real. Espero poder compartilhar com todos vocês experiências e conhecimentos que sejam válidos para pelo menos uma pessoa.

Também pretendo utilizar esse “canal” para me manter informado sobre alguma coisa bacana (ou nem tanto) pela qual eu já passei ou talvez vi alguem passar. E que normalmente, com o decorrer do tempo, acaba se perdendo por aí.

Ah! E aproveitando “a deixa”, na hora de escolher a hospedagem normalmente perdemos muito tempo até escolher a empresa e o serviço certo. Gostaria de indicar (não estou ganhando nenhum trocado com isso) a eapps. Que além de disponibilizar uma conta root pra você usar da maneira que bem entende, oferecem um excelente suporte (em inglês), e muitos serviços pré-instalados e atualizados.

Bom, por enquanto é isso.

Abraços!

Popularity: 59% [?]