Título do Trabalho: Ei, Seu Sistema é um Workflow! Autor(a): Marlon Silva Carvalho Tema: Engenharia de Software (processo de desenvolvimento de sistemas) Total de páginas: 29
Título: Ei, Seu Sistema é um Workflow! Autor: Marlon Silva Carvalho Tema: Engenharia de Software (processo de desenvolvimento de sistemas) Resumo: O objetivo deste trabalho baseia-se na apresentação dos principais benefícios factíveis de serem alcançados por uma empresa, a partir do momento em que há a disseminação e um entendimento sólido sobre a tecnologia de Workflows. Com a posse deste entendimento, as equipes munem-se de práticas e técnicas que garantem um produto mais confiável e construído em prazos mais curtos. Embora apresente-se como uma tecnologia com amplos estudos e diversas soluções de software livre existentes no mercado, ainda há pouco direcionamento para o seu uso no Serpro. A pouca compreensão que existe internamente na empresa sobre o tema apresenta-se como o maior dificultador para identificar, documentar e implementar sistemas deste tipo. Considerando a grande extensão deste assunto, que abrange conceitos como Services Oriented Architecture (SOA), Business Process Management (BPM) e Enterprise Service Bus (ESB), que possuem como foco uma visão mais ampla, tocando mais incisivamente nas questões que envolvem o negócio macro de uma empresa, o contexto no qual o Serpro atua urge não desprezar as dificuldades encontradas por suas equipes de desenvolvimento para construírem aplicações desta natureza para seus clientes. Observou-se que o pouco conhecimento em Workflows direciona para a perda de qualidade e produtividade das equipes, uma vez que grande parte de código dos sistemas que são inerentes a esta tecnologia pode ser descartada apenas adotando um mecanismo de Workflow. Contudo, este benefício estende-se também às áreas de requisitos, análise e projeto, que tendem a se tornar mais simples, uma vez que sistemas de Workflow são propensos a se comportarem de forma similar. Este trabalho ainda apresenta um estudo de caso, dentro do próprio Serpro, exemplificando como este trabalho extra foi evitado adotando um mecanismo de código livre no desenvolvimento de um projeto para a Receita Federal do Brasil. Com este rápido estudo de caso, é possível observar os benefícios alcançados pela equipe, reduzindo a quantidade de código, aumentando a qualidade do produto e diminuindo o prazo para entrega. Concluindo, apresenta-se como o Demoiselle pode agregar funcionalidades de Workflow, permitindo que as equipes de desenvolvimento do Serpro usufruam das vantagens que esta tecnologia proporciona. Palavras-chave: Workflow. SOA. BPM. ESB. Demoiselle. Engenharia. Total de páginas: 29
Currículo Funcionário do Serpro desde 2006, atua na área de desenvolvimento de software desde 2000. Atuou no Serpro no projeto Sispei, sistema da Receita Federal do Brasil totalmente direcionado para Workflows. Possui a certificação Java 1.4 e está concluíndo a pósgraduação de Sistemas Distribuídos pela Universidade Federal da Bahia. Apoiador e mantenedor de diversos projetos de software livre.
Sumário O Incrível Mundo dos Workflows...7 Ei, Seu Sistema é um Workflow!...9 Então, qual o problema?...10 Qual o Caminho?...12 O Mapa para a Mina...12 Sistema AmoWorkflows S/A...13 Ajudando o Analista de Requisitos...15 Generalizando os Casos de Uso...15 Casos de Uso Modulares...17 Regras de Negócio por Entidade/Ação...17 Análise, Projeto e Codificação...18 Componentes...18 Utilização de Engines...19 Exemplos são Melhores que Mil Palavras...20 Demoiselle e Workflows...23 O Amanhã...24 O Fim...24 Bibliografia...26
O INCRÍVEL MUNDO DOS WORKFLOWS Embora seja considerado um tema de discussão antiga, podem ser encontradas, ainda hoje, diversas correntes divergentes quanto ao que é e quais as atribuições de um Workflow. O objetivo desta seção é esclarecer o que são Fluxos de Trabalho, quais as suas atribuições e como podem ser aplicados, tentando desmistificar este incrível, e fascinante, mundo dos Workflows. Muitos dos conceitos desta área são encontrados em nosso cotidiano. A sequência de tarefas realizadas ao levantar-se da cama até o momento de chegada ao trabalho destaca uma série de atividades executadas todos os dias por muitas pessoas: levantar, escovar os dentes, tomar banho, tomar o café da manhã, dirigir-se ao trabalho, etc. Deste exemplo, observa-se um conjunto de estados que se modificam a partir de ações. Tem-se, então, o estado dormindo, que necessita da ação acordar para que se passe para o estado escovando os dentes. Para chegar ao estado tomando café da manhã será necessário executar algumas atividades, como escovar os dentes e tomar banho. Embora possa ser considerado um exemplo simplório, é importante para clarear as ideias básicas de um Workflow. Em uma visão macro, abordando questões de negócio de uma empresa, tem-se relatórios que estão aguardando validação e que, para chegarem até o chefe do setor, devem ser analisados e, logo após, aprovados. Para aqueles formados na área de engenharia de sistemas, alguns conceitos anteriormente aprendidos em outras áreas podem surgir, como o de Máquinas de Estado. De fato, um fluxo de trabalho contém esta ideia, mas a amplia consideravelmente. Conforme a evolução das tecnologias que circundam os Workflows foram avançando, diversas características foram agregadas, muitas vezes criando termos novos que possivelmente criaram mais dificuldades para entender este tema. Para Eder e Liebhart (1996), fluxos de trabalho são Processos de Negócio que consistem de múltiplas atividades que devem ser executadas em uma sequência válida. Atividades representam qualquer unidade de trabalho, que pode ser, por exemplo, uma simples chamada de telefone. Para o objetivo deste trabalho será considerada a definição construída pela Workflow Management Coalition (WfMC), órgão criado e gerido por um grupo de empresas e outras partes interessadas neste assunto. A WfMC descreve: Workflows preocupam-se com a automação de procedimentos nos quais documentos, informações 7
ou tarefas são trocados entre participantes, conforme um conjunto definido de regras, com o objetivo de alcançar, ou contribuir, para uma meta global de negócios (WFMC, 2010). Considerando a definição proposta pela WfMC, pode-se esclarecer um fluxo de trabalho através de um rápido exemplo real, como um fluxo de pedidos de compra. Nele pode-se perceber a participação de entes que devem executar tarefas como, por exemplo, o técnico que deve verificar o estoque dos produtos que compõem o pedido e a aprovação financeira, realizada pelo analista financeiro. A Ilustração 1 exemplifica esta ideia. Nesta ilustração percebe-se seis estados, ou passos, que um pedido pode passar. Em cada passo deste pode existir uma ou mais tarefas associadas aos usuários do sistema. Uma vez executada uma atividade, ou tarefa, o fluxo migra de estado, utilizando para isto as transições, representadas através das setas direcionadas que interligam os passos. Ilustração 1: Exemplo de Fluxo de Trabalho. Outro termo comum nesta área, e que merece um esclarecimento, é o termo Workflow Engine ou, traduzido para nosso idioma, Mecanismo de Fluxo de Trabalho. Uma vez definido um fluxo de trabalho, cabe operacionalizá-lo e um mecanismo de workflow é o responsável por esta ação. Cabe a ele tratar uma entrada, o fluxo de trabalho descrito em uma linguagem, e gerenciar as transições entre os estados e as tarefas que cada participante possui, além da execução destas pelos seus responsáveis. As linguagens de definição de processos são estruturas formalmente organizadas que permitem aos responsáveis pela idealização de um fluxo descreverem os passos e as 8
tarefas que cada participante terá. Neste contexto, podemos destacar as linguagens extensible Process Definition Language (XPDL, 2010) e a Business Process Management Notation 2 (BPMN2, 2010). A primeira é mantida pela WfMC, enquanto a segunda é mantida pelo grupo BPM.org. A linguagem BPMN2 diferencia-se da XPDL não apenas na sintaxe, mas também na forma de apresentação, uma vez que ela também pode ser usada de maneira visual, permitindo a construção de fluxos de trabalho adotando elementos gráficos pré-estabelecidos. Ambas linguagens não encerram o assunto, pois diversas outras já foram sugeridas, embora muitas não tenham alcançado o êxito pretendido. Atualmente, a linguagem BPMN2 possui maior evidência, sendo adotada como linguagem padrão dos Mecanismos de Workflow mais utilizados do mercado. Finalizando, é importante diferenciar os conceitos de Workflows e BPM, pois percebe-se, nos analistas de sistemas e negócio, confusão quanto aos limites de cada um. Pretendendo não se estender neste assunto, será adotada a ideia de BPM defendida por (COOK, 2007): Worflows são a base para o BPM. Deste ponto de vista, um BPM é um Workflow com alguns enfeites. Do ponto de vista de um analista de negócios, contudo, estes adornos são tão importantes para as pessoas que desejam que seus processos de negócio sejam rodados de forma eficiente, que cabe criar um termo específico para designar isto. EI, SEU SISTEMA É UM WORKFLOW! Com base nos conceitos de Workflows já discutidos, esta seção apresenta como muitos analistas de sistemas não percebem que várias aplicações a serem desenvolvidas são Workflows e acabam perdendo a oportunidade de adotar práticas que agilizariam o desenvolvimento e ajudariam a ter um produto mais confiável. Espera-se que ao final deste seção qualquer analista de sistemas possa imediatamente afirmar, ao ouvir os requisitos ditados por seu cliente, a frase: Ei, seu sistema é um Workflow!. De fato, muitos sistemas possuem características inerentes de Workflow, porém uma quantidade bem razoável de analistas de sistemas não consegue captar este detalhe de fundamental importância. Quando o fazem, infelizmente, não adotam práticas que permitam um maior ganho de produtividade. 9
Então, qual o problema? Desenvolver um sistema não é uma tarefa trivial. Contudo, pode ser ainda mais conturbada quando os responsáveis por sua criação não possuem conhecimentos além daqueles referentes à sua área de atuação. Sistemas de Workflow são um exemplo prático disto. A partir das descrições do negócio de uma empresa, é simples observar que determinada aplicação pode ser modelada facilmente como um fluxo de trabalho, mas não é tão fácil para aqueles que nunca estudaram o assunto. Conscientes ou não, os analistas terminam abdicando de adotar práticas ou reusar soluções existentes que poderiam agilizar e embutir maior qualidade ao produto. Este esforço supérfluo é comum no desenvolvimento de sistemas, principalmente pela falta de cultura nesta tecnologia. Visando a exemplificar, pode-se considerar esta simples descrição inicial de um sistema, dada por um cliente fictício: Gostaria de um sistema para facilitar a publicação de notícias em meu sítio na Internet. Os repórteres enviam as notícias de suas casas e o redator revisa. Depois, eu devo publicá-las, uma a uma, evitando notícias que ferem interesses de patrocinadores. Para um analista de sistemas com bons conhecimentos em Workflows é bastante fácil identificar um fluxo de trabalho no qual notícias passam por, no mínimo, três passos antes de serem acessíveis ao usuário externo, conforme apresenta a Ilustração 2. Contudo, para o analista sem conhecimentos sólidos, este fato passa despercebido, dificultando sobremaneira o reuso e manutenção futura do sistema. Ilustração 2: Exemplo de Workflow para Publicação de Notícias. Cabe destacar, também, que sistemas como o já descrito nos parágrafos anteriores são comuns. Considerando uma empresa com as dimensões do Serpro, no qual centenas de sistemas são mantidos e desenvolvidos anualmente, pode-se compreender o esforço desnecessário aplicado na criação de sistemas de Workflow. Em um rápido levantamento, consultando as equipes de desenvolvimento de uma das regionais, constatou-se a 10
existência de, no mínimo, cinco sistemas que poderiam ser criados com práticas específicas. Sistema (Linguagem) Requisitos Projeto Engine A (Java) Sim Sim OSWorkflow B (ASP) Não Não Não Utilizou C (PHP) Não Não Galáxia D (Java) Não Não Não Utilizou E(ASP) Não Não Não Utilizou Tabela 1: Lista de Sistemas Regional Salvador que poderiam usar práticas de Workflow. A Tabela 1 apresenta estes sistemas, usando nomes ficíticos. Este levantamento foi feito em agosto de 2010 e demonstra como apenas um sistema adotou práticas na área de engenharia de requisitos, análise e projeto, além de uma engine. Três foram totalmente desenvolvidos sem qualquer tipo de prática que visasse alavancar a produtividade da equipe. Um deles adotou apenas um engine. Um fato comum é a construção quase completa de uma engine própria, contendo código específico da aplicação entrelaçado com o gerenciamento do fluxo de trabalho. Adotando os termos comuns na área de desenvolvimento de aplicações, pode-se dizer que o código encontra-se com centenas de comandos if e switch totalmente desnecessários, que visam a apenas controlar em qual direção o fluxo deve prosseguir. Obviamente, uma simples engine eliminaria todo este esforço. A Listagem 1 exemplifica um cenário como este. public class SistemaSemEngineDeWorkflow { public void aprovardocumento(documento documento) throws Exception { if (! documento.getsituacao().equals("situacao_aaprovar") ) { throw new Exception("Situação Incorreta!"); } else { // Checar se o usuário pode executar tal tarefa... if ( usuario.getnome().equals("usuario1") ) { documento.setsitucao("situacao_aprovado"); } else { throw new Exception("Usuário Não Pode executar tal ação!"); } } } } Listagem 1: Código Fictício de um Fluxo de Trablaho sem utilizar Engines. 11
Este código Java (JAVA, 2010) fictício demonstra a utilização dispensável de instruções de controle de fluxo. Todo ele pode, e deve, ser executado por um mecanismo de fluxo de trabalho, que abstraia todas estas informações, permitindo ao programador focar-se apenas nas regras que são específicas para a aplicação em construção. Embora já haja forte ganho adotando apenas uma engine, benefícios ainda maiores podem ser obtidos usando práticas também em algumas disciplinas da engenharia de software. Comumente sistemas de Workflow são complexos e a engenharia tende a ocupar um tempo considerável no desenvolvimento do sistema. Os ganhos são perceptíveis não apenas na questão do tempo economizado, mas também na robustez do produto. As engines disponíveis no mercado já foram validadas por dezenas de outros projetos. Práticas e padrões na área de engenharia também garantem um produto mais confiável, pois estas podem ser constantemente evoluídas e validadas por diversas equipes. As etapas de elicitação de requisitos, análise e projeto são aquelas que mais ganham com a utilização destas práticas. Qual o Caminho? A garantia de um bom produto ao término do desenvolvimento de um sistema de Workflow depende fortemente dos meios adotados para desenvolvê-lo. Esta seção descreve poucas e simples práticas que, em tese, se aplicadas no desenvolvimento de sistemas deste tipo, tendem a dar maiores ganhos para as equipes. Destaca-se que nenhum estudo aprofundado foi realizado. Todo conhecimento aqui descrito foi adquirido através da criação de um sistema real e de estudos teóricos nesta área. Estas práticas ainda devem ser melhoradas e avaliadas no desenvolvimento de sistemas deste tipo, visando a validá-las e estendê-las. Também é importante destacar que se tratam apenas de práticas e não um roteiro completo e fechado de passos a serem seguidos por qualquer equipe. O Mapa para a Mina Cada tipo de sistema possui características específicas que podem ser usadas para facilitar sua classificação. Em Workflows o cenário não é diferente. Dada uma descrição de um cliente, o analista pode verificar a existência de alguns termos que definem facilmente sua classificação como um sistema de fluxo de trabalho. Provavelmente, o cliente do produto não dirá imediatamente estes termos, mas o analista pode induzi-lo a isto. Entretanto, caso o cliente relate diretamente os termos ação, atividade, tarefa, passo, 12
situação e estado, há fortes indícios que o sistema a ser desenvolvido é um Workflow. Também deve-se ter atenção especial a uma possível sequência de ações que o usuário possa relatar, como fulano deve escrever o relatório e enviar para o seu chefe olhar. Há uma possibilidade, neste caso, de que se esteja falando em uma entidade relatório que possui dois estados. Sistemas de Workflow sempre possuem esta característica: pessoas ou sistemas devem executar algo em alguma entidade, normalmente um documento. Para entender como um sistema pode interagir com um fluxo, basta imaginar uma administradora de cartão de crédito fornecendo um retorno para o fluxo, indicando que o cartão do cliente tem crédito. Neste caso, um pedido pode passar do estado Aguardando Pagamento para Pago, sem interferência humana direta. Finalizando, a indicação é estar atento não apenas a termos específicos, mas também a entidades que dependem de pessoas para executar alguma ação, como enviar para o chefe analisar. Sistema AmoWorkflows S/A Para ilustrar estas práticas, consideraremos uma descrição de um sistema fictício. Tratase de uma aplicação que contém apenas dois documentos: um Relatório Diário e um Relatório Especial. O primeiro é um documento que é gerado diariamente por analistas da empresa AmoWorkflows S/A. O segundo é um relatório gerado ao final do mês pelos chefes de setor. O cliente deste sistema descreve-o da seguinte forma para o analista de sistemas: Preciso de um sistema que gerencie dois documentos de minha empresa. Um documento chamado Relatório Diário, que é criado pelos analistas todos os dias e que depois são enviados para revisão da sua chefia imediata. Após revisar, o Relatório Diário deve ser enviado para a Aprovação da chefia do setor. Já o segundo documento é um Relatório Especial, criado pelas chefias imediatas mensalmente e enviado para o Parecer do chefe do setor. Logo após isto, o chefe do setor envia para a aprovação do gerente da empresa. Esta etapa de aprovação é idêntica à aprovação do Relatório Diário. Nenhum relatório pode ser aprovado caso o usuário não tenha informado seu detalhamento. Todo relatório também deve ter preenchida automaticamente a data de aprovação. Finalmente, todos os relatórios são classificados como público ou restrito e ainda há o envio de e-mails para as pessoas responsáveis em executar cada tarefa. Desta descrição, pode-se encontrar facilmente alguns casos de uso, sendo eles: 13
Relatório Diário Manter Relatório Diário; Enviar Relatório Diário para Revisão; Revisar Relatório Diário; Rejeitar Relatório Diário; Enviar Relatório Diário para Aprovação; Aprovar Relatório Diário; Reprovar Relatório Diário. Relatório Especial Manter Relatório Especial; Enviar Relatório Especial para Parecer; Dar Parecer no Relatório Especial; Enviar Relatório Especial para Aprovação; Aprovar Relatório Especial; Reprovar Relatório Especial. Modelando este sistema com os conceitos de Workflow, teremos estados, tarefas e transições entre estes estados. A Ilustração 3 apresenta a forma gráfica que representa o fluxo de trabalho para o documento Relatório Diário. Ilustração 3: Representação Gráfica do Fluxo do Relatório Diário. 14
A Ilustração 4 apresenta, utilizando a mesma notação gráfica do Relatório Diário, a representação do fluxo de trabalho do Relatório Especial. Ilustração 4: Representação Gráfica do Fluxo do Relatório Especial. Ajudando o Analista de Requisitos Deve-se considerar a área de requisitos inicialmente, pois trata-se da primeira etapa da construção de todo sistema. Aqui são apresentadas práticas que visam a construir casos de uso mais genéricos e o principal ganho é na produtividade. Aqui, nenhuma técnica de elicitação nova foi criada, ao contrário, algumas foram apenas mais evidenciadas, pois trazem ganhos para os sistemas de Workflow. Serão apresentadas apenas três práticas consideradas mais importantes. Generalizando os Casos de Uso Generalização é um conceito bastante comum na engenharia de software, principalmente na fase de construção de código. Atribui-se a ela muitos ganhos, pois partes comuns são agrupadas em uma única entidade, evitando a repetição. Em requisitos, no entanto, vê-se pouco o seu uso. Tende-se a construir diversos casos de uso, um para cada situação descrita pelo cliente, sem analisar friamente se existem casos de uso que podem ser generalizados. Isto é importante principalmente em sistemas de Workflows, pois é comum ocorrer a repetição de atividades em diversas instâncias de fluxos diferentes. Conforme o exemplo apresentado nesta seção, pode-se perceber que os dois documentos transitam entre 15
estados diferentes, mas possuem tarefas parecidas, ou até mesmo iguais. Ambos relatórios necessitam de aprovação e geraram dois ECUs chamados, respectivamente, Aprovar Relatório Especial e Aprovar Relatório Diário. Neste contexto, a melhor prática para esta situação consiste em tentar generalizar em um único ECU o comportamento geral da atividade Aprovar. Nome do Caso de Uso Aprovar Relatório Diário e Relatório Especial Objetivo Aprovar os documentos Relatório Diário e Relatório Especial. Atores Analista, Chefe de Setor, Chefia Imediata Pré-condições O documento a ser aprovado deve se encontrar na situação A Aprovar. Fluxo Principal P1. Solicitar Aprovação Na tela de edição do documento, o Ator opta por Aprovar o documento. P2. Solicitar Confirmação O sistema exibe mensagem solicitando confirmação da aprovação. P3. Confirmar Aprovação O Ator confirma a aprovação. P4. Gravar Dados P4.1. Inclusão do Caso de Uso Validar Campos de Formulário P4.2. O sistema grava os dados e altera a situação do documento para Aprovado. P4.3. O sistema numera o documento. P4.4. O sistema grava o histórico conforme LEL. P5. Enviar E-mail Fluxos Alternativos A1. Aprovar Relatório Diário Se no passo P4, o documento for do tipo Relatório Diário: A1.1. O sistema envia e-mail para a Chefia Imediata. A1.2. O fluxo retorna ao passo P4.2. A2. Aprovar Relatório Especial Se no passo P4, o documento for do tipo Relatório Especial: A2.1. O sistema envia e-mail para todos funcionários do setor. A2.2. O fluxo retorna ao passo P4.2. Tabela 2: Definição do ECU de Aprovação. A Tabela 2 demonstra, de forma bastante resumida, como o ECU de aprovação pode ser 16
idealizado com esta ideia. Observa-se que as questões específicas para cada documento podem ser referenciadas na seção de fluxos alternativos, evitando a criação de dois ECUs, uma vez que seus fluxos principais são iguais, mudando apenas questões simples de regra de negócio. Embora possa parecer uma prática bastante simples e seus ganhos contestáveis, considerando sistemas com mais de dez documentos e que possuem semelhanças em suas atividades, esta prática tende a diminuir consideravelmente o número de casos de uso. De fato, para sistemas pequenos, talvez não haja ganhos visíveis. Mas, neste caso, cabe também avaliar se a tecnologia de Workflows é realmente necessária para criá-lo. Casos de Uso Modulares Embora a ideia de modularizar alguns tipos de casos de uso possa parecer idêntica à ideia de generalização, existem diferenças e tratam-se de práticas complementares. Existem outros padrões também comuns em sistema de fluxo de trabalho, como o envio de correios eletrônico ou a atribuição de papeis de forma dinâmica. Neste caso, pode-se criar ECUs específicos para estes padrões comportamentais, apenas referenciado-os quando necessário nos casos de uso mais específicos. Por exemplo, o ECU Aprovar Relatório Especial pode referenciar diretamente estes dois ECUs citados. Regras de Negócio por Entidade/Ação O documento de regras de negócio não possui um padrão para ser criado, contendo os tópicos necessários e o formato do texto. Cabe ao analista definir a melhor forma junto ao seu cliente. Em um sistema de Workflow, entretanto, algumas características levam a considerar a possibilidade de se adotar um padrão comum. Todo fluxo de trabalho possui ações a serem executadas, sejam por humanos ou por uma máquina. Também possuem entidades que sofrem estas ações. Por exemplo, o documento Relatório Diário sofre a ação Aprovar. Em um sistema de notícias, uma Notícia sofre a ação de Revisão, uma passagem sofre a ação de Aprovação em um sistema de reserva de passagens. 17
1. Relatório Diário 1. Enviar para Aprovação Descrever as regras de negócio desta ação. 2. Aprovar Descrevar as regras de negócio desta ação. Tabela 3: Documento de Regras de Negócio. Assim, é indicado que as regras de negócio do sistema venham a ter dois níveis de divisão. A primeira, por entidade que sofre a ação, como o Relatório Diário. A segunda, por ação. A Tabela 3 ilustra simplificadamente esta ideia. Esta ação reforça a qualidade do artefato gerado. Análise, Projeto e Codificação As etapas de análise e projeto beneficiam-se de práticas bastante difundidas na área. A principal delas diz respeito à componentização. Já a etapa de codificação beneficia-se basicamente na utilização de uma engine, além das práticas comuns e bastante difundidas de programação. Os ganhos de uma área beneficiam diretamente a outra, portanto, esta seção discutirá as técnicas independente de área da engenharia. Aqui, observa-se um forte ganho na robustez do produto, adotando soluções consolidadas de mercado e práticas reconhecidas. Componentes A ideia de criar sistemas componentizados é antiga, embora pouco praticada. Os teóricos na área afirmam a necessidade de se modularizar, visando dividir o problema em partes mais compreensíveis e de fácil manutenção. Na área de Workflows a componentização assume papel de fundamental importância tanto na programação, como na definição da arquitetura. No sistema sugerido nesta seção, pode-se verificar alguns requisitos pedidos pelo cliente, como o envio de correios eletrônicos, documentos que são classificados entre público e restrito, validados, complementados com informações extras e, finalmente, tem seus dados persistidos em um banco de dados. Analistas experientes materializam estes requisitos em alguns componentes, como: Componente de Validação, Componente de Complementação, Componente de Classificação, Componente de Persistência e 18
Componente de Envio de Correio Eletrônico. Todos podem agir de forma independente e podem ter seu comportamento definido de diversas formas, como em arquivos no formato extensible Markup Language (XML, 2010) ou em através de código na linguagem no qual o sistema foi concebido. A prática de componentizar comportamentos gerais facilita sobremaneira a realização de casos de uso que adotam diagramas de sequência. Ilustração 5: Diagrama de Sequência Simplificado. A Ilustração 5 apresenta um diagrama de sequência bastante simplificado de uma possível realização de caso de uso, como a aprovação dos Relatórios. Observa-se que todos os documentos poderão ter diagramas de sequência parecidos com este, mudando apenas a ordem de chamada dos componentes. Assim, é possível agrupar diagramas de sequência em comum. Por exemplo, basta apenas a criação de um diagrama de sequencia para todos os documentos que possuem a necessidade de Aprovação, pois a sequência de componentes e a forma como são chamados apresenta-se sempre a mesma. Para a criação dos componentes, é indicado ao analista verificar comportamentos em comum a muitas entidades. Como exemplo, caso dois ou três documentos tenham necessidade de classificação, cabe criar um componente específico para isto. Utilização de Engines Quanto à programação do sistema é fortemente indicado que uma engine de Workflow seja adotada. Isto evitará o problema já destacado, no qual código de negócio apresentase entrelaçado com código para o controle do fluxo de trabalho. Uma engine abstrai todos 19
estes aspectos, controlando o fluxo e a atribuição de tarefas para os usuários. Um estudo deve ser realizado visando a detectar aquela que melhor se encaixa ao projeto em criação. Deve-se considerar as características da engine, as facilidades que ela provê, se segue padrões abertos e amplamente difundidos e, preferencialmente, se é código aberto. Há uma gama enorme de mecanismos deste tipo disponibilizados pelos comunidades de código aberto e este fato deve ser aproveitado. No momento de escolha da engine, a equipe pode usar como guia os seguintes aspectos: 1. Licença Livre; 2. Ampla documentação, contendo JavaDoc; 3. Adota como linguagem de definição de processos a BPMN2; 4. Possuir ferramenta gráfica para criação de processos; 5. Comunidade ativa; 6. Facilitar a criação de componentes para acoplamento à engine; 7. Integração com diretórios de usuário, como LDAP. Esta lista não esgota o assunto e, portanto, a depender do projeto, novos aspectos devem ser levantados e agregados. Usar uma engine de mercado reforça o reuso de soluções abertas e já consolidadas no mercado, agregando maior confiabilidade ao produto final, além de um grande ganho de produtividade. EXEMPLOS SÃO MELHORES QUE MIL PALAVRAS Esta seção tem como objetivo apresentar um estudo de caso interno ao Serpro, no qual a equipe de desenvolvimento responsável pelo sistema adotou as práticas citadas na seção anterior para a modelagem e programação de um aplicativo com características de Workflow. Trata-se de um sistema criado para a Receita Federal do Brasil. Devido ao caráter altamente sigiloso do sistema, o cliente não permitiu que documentos reais do sistema fossem utilizados neste trabalho. Portanto, serão realizadas substituições gráficas e documentais, embora os exemplos apresentados ainda estejam refletindo o sistema real. O objetivo deste sistema, de forma bastante resumida, baseia-se no gerenciamento dos 20
documentos que permeiam o processo de investigação da Receita Federal do Brasil. O sistema foi idealizado para ser executado em um ambiente Java e acessado através de navegadores web. O cerne deste sistema baseia-se nos trâmites de mais de vinte (20) documentos, cada qual com suas ações específicas. Cada documento possui, em média, cinco ações que podem ser executadas por pessoas. Neste cenário, tem-se aproximadamente cerca de cem (100) ações diferentes em todo o sistema. Considerando a própria complexidade do sistema, mas também a necessidade em concluir a sua confecção dentro do prazo, a equipe realizou um estudo inicial, no qual o objetivo foi identificar um Motor de Workflow que fosse capaz de dar suporte à aplicação. A engine escolhida foi a OSWorkflow (OSWORKFLOW, 2010) da empresa OpenSymphony. Uma vez definido o software, necessitou-se identificar a melhor forma possível para elicitar os requisitos, assim como para a realização de casos de uso, conforme determinado pela versão vigente do Processo de Desenvolvimento de Software do Serpro (PSDS, 2010), chegando às práticas já descritas na seção anterior. Esta etapa demonstrou-se de extrema importância, uma vez que o sistema apresentava cerca de cento e noventa (190) casos de uso, além de um documento de Regras de Negócio que alcançava cerca de duzentas (200) páginas. Neste contexto, havia uma necessidade urgente de adotar um padrão, ou prática, que visasse agilizar a etapa de elicitação de requisitos, sem comprometer a qualidade dos documentos gerados por esta área da engenharia de software. Notou-se que era possível generalizar muitas ações realizadas nos documentos e, portanto, foram criados ECUs genéricos e modulares. A Ilustração 6 apresenta a quantidade total de ECUs necessários caso esta prática não fosse adotada, em contrapartida com a adoção desta prática. 21