Controle sobre o processo

Transcrição

1 Modelagem de processos, Use Cases e ferramentas BPM Glauco Reis ([email protected]) é Consultor em Java e metodologias OO, e especializado em plataforma IBM. Têm o título de SCJP 1.1 e 1.4, SCJWCD 1.4, e IBM CSE e IBM Websphere Application Server Certified. Escreve há mais de 8 anos sobre o tema Java e trabalha na área de informática há mais de 20 anos, participando também como palestrante COMDEX e FENASOFT. É especialista em WebServices e está envolvido com a tecnologia BPMS, como arquiteto principal na criação de uma solução BPMS nacional. Use cases, assim como modelagem de processos, normalmente são recursos utilizados para representar formalmente (escrita ou gráficamente) um sistema. Normalmente se têm utilizado a modelagem de processos para obtenção uma visão de mais alto nível da empresa e dos processos, enquanto que os use cases já estão focados em como cada funcionalidade discreta de um sistema será implementada. Como que um acordo entre cavalheiros, a modelagem de processos entraria como um primeiro passo no entendimento da empresa e sua estrutura, enquanto que os Use Cases já estariam focados no processo de análise e design orientado para objetos, para cada um dos sistemas. Vamos explorar neste artigo como estes elementos se relacionam, e o que vêm fazendo com que estes relacionamentos se alterem nos últimos tempos. Nos últimos anos, a modelagem de processos vêm evoluindo de forma a se contrapor ou mesmo suplantar em termos de capacidade de recursos a modelagem focada em Use Cases. A evolução das representações como a BPMN e os processos BPEL estão se tornando padrões poderosos, e provavelmente irão criar nos próximos anos novas metodologias de desenvolvimento. Esta é a proposta de algumas ferramentas BPM, e estamos muito próximos desta realidade (algumas estão presentes por aí). Neste artigo iremos analisar os desenhos de processos e de que forma eles se relacionam com os Use Cases. Para tornar claro o que será explorado aqui, estaremos utilizando como exemplo o sistema de gerenciamento de cursos em uma universidade. Ele é um case bem explorado pela Rational, em vários livros, além de ser simples e suficientemente pequeno para explorarmos neste artigo. A idéia do problema é simples : Uma universidade têm grades de cursos formadas por módulos, professores dispostos a ministrar estes módulos e alunos dispostos a cursá-los. O mesmo exemplo foi utilizado por vários cursos da Rational e está no livro Visual modeling with Rational Rose and UML, de Terry Quatrani. Estaremos explorando pequenas partes deste exemplo, tentando explicar as idéias do sistema para cada pedaço sendo explorado. Controle sobre o processo As modernas metodologias de desenvolvimento, como a RUP, se preocuparam em quebrar os sistemas em pequenas partes, e tratá-las de forma isolada, o que pode ser uma vantagem mas traz alguns impecilhos. Sob o ponto de vista empresarial, cada atividade isolada é parte de um processo maior, que precisa ser medido para apuração de métricas. Enquanto que para efeitos de desenvolvimento é conveniente se tratar atividades de forma isolada, para efeitos de gerenciamento de processos eles têm interdepêndencia, e precisam ser reajustados a todo momento. No sentido de integrar as duas necessidades, vêm se popularizando um novo tipo de ferramental chamado de BPMS (Business Process Management System), onde o apelo é um maior controle sobre o processo. O que esta nova idéia prega é que os sistemas atuais se preocupam com as funcionalidades isoladas do sistema, mas há pouca preocupação em permitir medidas que permitam melhorar o processo após implementado. Uma analogia poderia ser aplicada na área aeronáutica. Todos os procedimentos para vôos foram estabelecidos, e os pilotos conseguem atingir um outro ponto com precisão (seria o sistema construido). Alguns procedimentos dentro do avião são modularizados a ponto de poderem ser aplicados ou substituidos em certos tipos de aeroplano (é a componentização e reaproveitamento de códigos). Mas, nos sistemas atuais nas empresas, raramente se coleta dados durante o vôo, ajustando rotas para atingimento do objetivo final (esta é a necessidade final). Isto é o que os empresários estão começando a cobrar da área de TI. Além de um sistema adequado para a empresa, que possa se moldar às mudanças de negócio que acontecem com frequência. Atualmente, o único artefato disponível são as ferramentas de

2 BI, que permitem análise após o processo ter acontecido, mas não têm poder de antecipar ou corrigir rotas para uma empresa antes de o fator ter acontecido. Como isto se processa na abordagem tradicional? Por exemplo, no caso do programa de cursos, você têm um use case onde o professor se registra para ministrar alguns módulos, e um use case onde o aluno se oferece para assistir alguns módulos. O primeiro aspecto é que um Use case não leva em consideração o fator tempo, como decisório para execução. Por exemplo, os alunos somente deveriam se oferecer para um módulo quando os professores não tivessem mais módulos a oferecer. Ou seja, deveria existir uma temporada onde os professores se ofereceriam para ministrar um ou mais módulos, e somente após expirada esta fase os alunos deveriam ser capazes de iniciar seus registros para os módulos. Uma das razões é que o aluno pode estar visualizando uma lista de módulos oferecidos que ainda não englobe o registro de todos os professores. Alguns professores podem ainda não ter se oferecido para ministrar aulas, e o aluno pode não ter a oportunidade de escolher um módulo que virá a ser escolhido no futuro. Ou o aluno entra todos os dias no sistema, verificando quais novos professores se ofereceram para os módulos, ou o sistema poderia enviar para todos os alunos cadastrados s informando de mudanças na grade. Isto pode fazer o sistema funcionar como um caos, onde o aluno entra diariamente e modificaria sua grade conforme novos professores fossem se oferecendo para ministrar novos módulos. Nunca sabemos quando este processo chega ao final. Por exemplo, o fluxo básico do Use Case Selecionar cursos a ministrar definido no exemplo do livro é : 1. O sistema obtem e mostra uma lista de cursos oferecidos, e que o professor está qualificado a ministrar. 2. O professor seleciona os cursos em que está interessado a ministrar 3. O sistema verifica se não há conflito entre datas, e caso haja avisa ao professor para que ele resolva estes conflitos. 4. A lista de cursos que o professor irá ministrar é atualizada 5. O sistema apresenta ao professor um grupo de módulos aos quais ele está alocado Fluxo básico para escolha dos módulos a ministrar No caso dos alunos, o fluxo do Use Case para Registrar para cursos definido é : 1. O aluno seleciona iniciar agenda 2. O sistema obtém a lista de cursos disponíveis para o semestre 3. O aluno seleciona 4 módulos desejados e 2 módulos opcionais, para montagem de sua grade 4. O sistema armazena os módulos que o aluno está interessado em participar Fluxo básico para escolha dos módulos a participar Ainda há um use case chamado Fechar Registros onde o gerente do sistema encerra o período de inscrições, e sumariza todo o processo, selecionando os alunos para cada módulo, eliminando os módulos onde os alunos não demonstrem interesse e criando mais turmas caso a busca por um módulo seja grande. Ele ainda avisa a cada aluno quais foram os módulos alocados para ele, com base nesta sumarização. Ainda há uma outra forma de se construir o sistema, tendo um gerenciador de temporadas. Alguém entraria no sistema e habilitaria o processo de registro dos professores. Após um prazo estipulado, o período de inscrições de professores estaria encerrado, e se iniciaria o processo de registro dos alunos, ficando novamente por mais um período, até que o processo fosse encerrado novamente. Isto também não é conveniente, pois dependeria de intervenção humana para um processo que poderia ser normalmente automatizado. Se você observar a forma como são escritos os Use Cases, perceberá que eles representam atividades discretas e atemporais, a serem executadas no sistema. Eles têm uma série de fluxos alternativos como Adiciona ofertas, Remove Ofertas e por aí vai. Raramente se leva em consideração o tempo, ou a ordem

3 em que as atividades acontecem. Quando acontecem interdependências, elas ficam por conta dos esteriótipos <<extends>> ou <<includes>>. Você pode colocar pré-condições, mas na realidade não há ligação entre dois use cases distintos, ou interdepências como um use case somente se inicia quando outro tiver sido executado. Isto faz sentido, pois a idéia de Use case é uma função discreta efetuada no sistema, que traz algum valor mensurável para o usuário. Normalmente não é uma preocupação dos use cases a interação entre os usuários. Já este é o foco dos Workflows. Permitir colaboração entre os usuários. Normalmente workflows podem ser expressos por diagramas de fluxo, um artefato comum da modelagem de processos e utilizado para obter um entendimento melhor de como o sistema opera. Um fluxo (simplificado) que poderia representar o mesmo sistema discutido seria : Fluxo representando o sistema de cursos A representação utilizada foi o BPMN, mas vamos entender como a sequência se processa. A primeira etapa é a atividade Cria cursos, onde se poderia cadastrar alunos, professores e inicializar o processo de alguma forma. Quando este processo for executado, se passaria para uma atividade (chamado de Dispara professores ) onde várias instâncias seriam criadas para cada um dos professores. Ou seja, cada professor, ao se logar no sistema, reberá um aviso de que deverá registrar seus cursos, e uma sequência de telas para fazê-lo. Isto é conseguido facilmente em uma ferramenta de colaboração através de uma área de leitura pertencente a cada usuário chamada de Inbox. O Inbox funciona como um leitor de s, onde cada participante vai sendo avisado de alguma atividade (o termo seria orquestrado). Quando o professor entra no Inbox, ele verifica que há uma atividade a ser executada, que consiste em se oferecer para os módulos. Quando ele clica em algum lugar no Inbox, uma sequência de telas é apresentada para que ele faça esta atividade. O sistema somente passa ao losango Sumariza professores quando todos os professores já tiverem se oferecido (ou um determinado prazo tiver expirado). Após sairmos desta etapa, os professores executaram sua atividade, e entra a fase em que os alunos se registram para os cursos disponíveis. Quando os alunos estão se oferendo para os cursos, os professores não podem mais se oferecer para ministrar alguma disciplina. Quando todos os alunos já se ofereceram para assistir aos módulos, o sistema sumariza e pode avisar aos alunos os módulos aos quais eles estão alocados, e os professores as disciplinas a serem ministradas. Este aviso podem igualmente ser enviado ao Inbox. Com este tipo de fluxo, se administra melhor o tempo, pois nunca um professor irá se oferecer para um curso quando os alunos estiverem escolhendo as disciplinas. Em um Use case, como o fator tempo não é controlado, nem mesmo a sequência em que as atividades acontecem são controladas. Se quizermos controlar estes aspectos, teremos que colocar uma série de interligações entre os Use Cases que acabarão

4 por tirar a unidade do mesmo. Isto acontece naturalmente em uma ferramenta de colaboração e é expresso por um artefato conhecido como workflow. Mas, este tipo de representação serve a qualquer tipo de sistema a ser construido? Na maioria dos processos que acontecem dentro das corporações, existe colaboração. O produto é pedido ao fornecedor pelo departamento de compras, é recebido pela logística, vendido ao cliente por vendas, cobrado por cobrança, e por aí vai. O problema é que para utilizarmos este novo pardigma, precisamos fatiar os sistemas de formas diferentes da que vínhamos fazendo até hoje. subdivisão dos sistemas dentro da empresa Como subdividir os sistemas Se observarmos a figura anterior, até hoje vínhamos fatiando os sistemas por funcionalidades. Quais as responsabilidades do sistema de RH, por exemplo? Permitir pagamento aos professores, consultar e marcar férias, emitir holerits, etc. O problema é que estas atividades descritas dependem de atividades que aconteceram anteriormente, e irá causar outros efeitos em atividades seguintes. Ou seja, ao invés de dividir o sistema em torres verticais, os chamados sistemas, como foi feito acima, o ideal é dividir o sistema em fatias horizontais, levando em consideração uma atividade, desde seu início até seu término, mesmo que isto passe por vários departamentos da empresa. Desta forma estaremos permitindo a colaboração entre as diversas áreas. Ou seja, a proposta é que os sistemas, ao invés de serem construidos na vertical, passariam a ser construidos na horizontal. Isto no mundo real ainda é uma coisa meio complicada de gerenciar, pois na verdade um funcionário ainda pertence a um departamento, e o ideal seria que ele respondesse por atividades, e não por departamentos. Quando se divide e constroe o sistema desta forma, ganhamos mais do que apenas isto. Quanto tempo se levou para enviar o boleto a cada aluno, após os cursos terem sido escolhidos? Quanto tempo leva um professor para oferecer cursos? Como as ligações entre os sistemas acontecem agora na horizontal, os tempos de execução de cada tarefa pode ser medido com mais precisão. Quando uma seta sai de um perfil

5 e entra em outro, neste momento a responsabilidade passa para o outro participante. Na implementação original por Use Cases, não há como mensurar o tempo que um aluno demorou para escolher um curso, após o professor ter se oferecido. Na verdade, não há ligação no sistema entre o professor ter se oferecido para um módulo e o aluno tê-lo escolhido. Quando o professor registrou os cursos de seu interesse, automáticamente a bola passou para o aluno, sem a intervenção manual de ninguém. Estes tempos podem ser medidos, e se imaginarmos um sistema corporativo mais complexo, teremos informações importantes como : quanto tempo se leva em média para emissão de um boleto bancário? Quanto tempo um caixa demora para atender um cliente? Com o tempo em mãos, poderemos obter outro número mais interessante que é, se para um determinado processo eu tenho o tempo gasto por cada participante, uma empresa pode mensurar quanto está gastando com mão de obra para obter o produto na saída. Isto permite que o preço do produto final pode ser medido com uma precisão muito boa. Se desejarmos otimizar um processo, reduzindo o tempo de uma atividade, e sabemos quanto tempo se leva para executar uma atividade, podemos aumentar ou diminuir o número de funcionários para atingir o resultado esperado. Isto faz sentido na cabeça de um gerente ou diretor de TI! É isto que estava comentando anteriormente, sobre ajustar o plano de vôo do avião antes do destino final. Neste caso, o sistema deixa de apenas executar alguma funcionalidade, mas passa também a fornecer subsídios para tomada de decisão pela empresa. A informática pode deixar de ser um mal necessário e passa a ser uma ferramenta de melhoria da empresa. Use cases X Workflows Será que há algum relacionamento entre os use cases e os Workflows? Vejamos, segundo um documento criado por uma empresa tradicional de modelagem por processos, encontrado na internet (ver referências), cada atividade de mais baixo nível de um workflow representa um Use Case. A grande diferença em modelagem por use cases e modelagem por processos é a forma como cada use case é ligado. Os workflows agregam mais informação do que os Use Cases de forma isolada. Eu tenho a opinião de que, no nível mais baixo do workflow, que para uma ferramenta BPM chega a definir cada atividade que um usuário efetua para completar uma etapa, teremos algo muito próximo de um diagrama de atividades da UML. Seria algo como: Subdivisão em niveis do workflow

6 No exemplo anterior, o use case associado como atividade do Workflow é Registra para assistir. Se abrirmos um nível a mais nesta atividade do workflow, teremos um sub-workflow com as etapas que o usuário deve fazer para se registrar. Mas se você observar os passos dentro deste sub-workflow irá perceber que é exatamente a descrição do fluxo principal deste Use Case. Ele têm a aparência de um diagrama de atividades. Isto não é novidade pois um diagrama de atividades pode ser utilizado para representar graficamente uma descrição de um Use Case. No nível mais baixo, temos atividades que podem ser interativas ou automáticas. Por exemplo, seleciona módulos é uma atividade onde os professores interagem com uma tela (ou sequência de telas). Armazena módulos selecionados é um tipo de atividade executado independente da interação do usuário. Cada uma destas atividades pode ser presa a um processamento. Por exemplo, podemos prender armazena módulos selecionados a uma storedprocedure ou um WebService. Dentro de uma empresa, ter sistemas criados em diversas tecnologias é muito normal. Quanto mais formas distintas de conectar tivermos disponíveis em uma ferramenta deste tipo, mais facilmente integramos os processos dentro de uma empresa. Existem ferramentas que fazem este tipo de atividade, normalmente chamadas de EAI (Enterprise Application Integration). Mas afinal, do que consiste uma ferramenta BPM? Até algum tempo atrás, fabricantes de ferramenta EAI, bem como fabricantes de ferramentas de modelagem de processos e alguns de BI começaram a posicionar seus produtos no mercado como ferramentas BPMS (Business Process Management System). A idéia de uma ferramenta BPMS é permitir que um desenho dos processos seja feito de forma visual, e ainda que este desenho permita a execução de um workflow, sendo que cada atividade esteja atachada a um pedaço de código, que pode ser um WebService, Stored procedure, acesso a banco, objeto COM, EJB, ou qualquer tecnologia que a empresa pretenda integrar. E por final, para ser uma ferramenta BPM é necessário suporte a algum servidor de aplicações. Isto foi convencionado, de acordo com várias empresas, e temos hoje o que chamamos de pure players, que são ferramentas puramente BPM, ou as ferramentas que não estão nesta categoria, que são ferramentas que têm algumas das características anteriores, mas não todas. Um desenho muito visto pela internet, quando se fala de ferramentas BPM, é o seguinte : Ferramentas BPM

7 Os modeladores de processo, além de ferramentas que permitam desenhar um processo (pelo menos os diagramas de workflow), devem também permitir simular os fluxos dos processos. Para que possamos estudar o fluxo de uma empresa, e otimizá-lo, devemos poder simular, fornecendo entradas ao sistema e simulando quanto de melhoria teríamos se alterássemos o fluxo para este ou aquele desenho. Deve existir uma ferramenta de EAI, que de preferência integre com várias formas de acesso aos dados, mas pelo menos utilizando SOAP e WebServices. O engine do Workflow irá utilizar o desenho criado pela ferramenta visual e orquestrá-lo. A orquestração é o processo de gerenciar quem é o usuário que está responsável por executar cada atividade. No nosso caso, seria responsabilidade do Workflow encerrar os registros das disciplinas pelos professores e passar a responsabilidade aos alunos, para que se registrem nos módulos oferecidos. O termo orquestrar é como em uma orquestra musical, onde o maestro vai a cada momento gerenciando quem está em execução a cada momento. Ainda deve ser possível executar estes códigos em algum engine, chamado de servidor de aplicações. Todos os grandes players estão saindo de servidores de aplicação customizados, para servidores de mercado, como os J2EE (websphere, jboss, BEA, etc.) Em que estágio estamos atualmente? Existem alguns players que já estão bastante avançados neste processo, já com todas as características de uma ferramenta BPM, e alguns estão próximos deste estágio, com boas ferramentas visuais e engines de execução. Nos próximos anos, esta será a nova onda, e isto está para mudar tão profundamente o mercado que até mesmo os fabricantes de ERP estão se mobilizando para tornar seus ERPs compatíveis com ferramentas BPM. Mas o que eu preciso para aprender isto hoje em dia? Uma imensa quantidade de novos padrões estão surgindo nesta esteira, como BPMN, BPML, BPEL, e mesmo a evolução da modelagem por processos em si. Conhecer estes novos padrões, e como eles estão integrando será garantia de domínio do que será a próxima onda no mercado de informática. Referências Livros Visual modeling with Rational Rose and UML Terry Quatrani