Você está na página 1de 7

Modelagem de processos, Use Cases e ferramentas BPM

Glauco Reis (gsrt@terra.com.br) Consultor em Java e metodologias OO, e especializado em plataforma IBM. Tm o ttulo 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 informtica h mais de 20 anos, participando tambm como palestrante COMDEX e FENASOFT. especialista em WebServices e est envolvido com a tecnologia BPMS, como arquiteto principal na criao de uma soluo BPMS nacional.

www.portalbpm.com.br

Use cases, assim como modelagem de processos, normalmente so recursos utilizados para representar formalmente (escrita ou grficamente) um sistema. Normalmente se tm utilizado a modelagem de processos para obteno uma viso de mais alto nvel da empresa e dos processos, enquanto que os use cases j esto 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 anlise e design orientado para objetos, para cada um dos sistemas. Vamos explorar neste artigo como estes elementos se relacionam, e o que vm fazendo com que estes relacionamentos se alterem nos ltimos tempos. Nos ltimos anos, a modelagem de processos vm evoluindo de forma a se contrapor ou mesmo suplantar em termos de capacidade de recursos a modelagem focada em Use Cases. A evoluo das representaes como a BPMN e os processos BPEL esto se tornando padres poderosos, e provavelmente iro criar nos prximos anos novas metodologias de desenvolvimento. Esta a proposta de algumas ferramentas BPM, e estamos muito prximos desta realidade (algumas esto 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 vrios livros, alm de ser simples e suficientemente pequeno para explorarmos neste artigo. A idia do problema simples : Uma universidade tm grades de cursos formadas por mdulos, professores dispostos a ministrar estes mdulos e alunos dispostos a curs-los. O mesmo exemplo foi utilizado por vrios 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 idias do sistema para cada pedao 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 apurao de mtricas. Enquanto que para efeitos de desenvolvimento conveniente se tratar atividades de forma isolada, para efeitos de gerenciamento de processos eles tm interdepndencia, e precisam ser reajustados a todo momento. No sentido de integrar as duas necessidades, vm 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 idia prega que os sistemas atuais se preocupam com as funcionalidades isoladas do sistema, mas h pouca preocupao em permitir medidas que permitam melhorar o processo aps implementado. Uma analogia poderia ser aplicada na rea aeronutica. Todos os procedimentos para vos foram estabelecidos, e os pilotos conseguem atingir um outro ponto com preciso (seria o sistema construido). Alguns procedimentos dentro do avio so modularizados a ponto de poderem ser aplicados ou substituidos em certos tipos de aeroplano ( a componentizao e reaproveitamento de cdigos). Mas, nos sistemas atuais nas empresas, raramente se coleta dados durante o vo, ajustando rotas para atingimento do objetivo final (esta a necessidade final). Isto o que os empresrios esto comeando a cobrar da rea de TI. Alm de um sistema adequado para a empresa, que possa se moldar s mudanas de negcio que acontecem com frequncia. Atualmente, o nico artefato disponvel so as ferramentas de

www.portalbpm.com.br BI, que permitem anlise aps o processo ter acontecido, mas no tm 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 tm um use case onde o professor se registra para ministrar alguns mdulos, e um use case onde o aluno se oferece para assistir alguns mdulos. O primeiro aspecto que um Use case no leva em considerao o fator tempo, como decisrio para execuo. Por exemplo, os alunos somente deveriam se oferecer para um mdulo quando os professores no tivessem mais mdulos a oferecer. Ou seja, deveria existir uma temporada onde os professores se ofereceriam para ministrar um ou mais mdulos, e somente aps expirada esta fase os alunos deveriam ser capazes de iniciar seus registros para os mdulos. Uma das razes que o aluno pode estar visualizando uma lista de mdulos oferecidos que ainda no englobe o registro de todos os professores. Alguns professores podem ainda no ter se oferecido para ministrar aulas, e o aluno pode no ter a oportunidade de escolher um mdulo que vir a ser escolhido no futuro. Ou o aluno entra todos os dias no sistema, verificando quais novos professores se ofereceram para os mdulos, ou o sistema poderia enviar para todos os alunos cadastrados emails informando de mudanas 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 mdulos. Nunca sabemos quando este processo chega ao final. Por exemplo, o fluxo bsico 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 no 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 mdulos aos quais ele est alocado Fluxo bsico para escolha dos mdulos a ministrar No caso dos alunos, o fluxo do Use Case para Registrar para cursos definido : 1. 2. 3. 4. O aluno seleciona iniciar agenda O sistema obtm a lista de cursos disponveis para o semestre O aluno seleciona 4 mdulos desejados e 2 mdulos opcionais, para montagem de sua grade O sistema armazena os mdulos que o aluno est interessado em participar Fluxo bsico para escolha dos mdulos a participar

Ainda h um use case chamado Fechar Registros onde o gerente do sistema encerra o perodo de inscries, e sumariza todo o processo, selecionando os alunos para cada mdulo, eliminando os mdulos onde os alunos no demonstrem interesse e criando mais turmas caso a busca por um mdulo seja grande. Ele ainda avisa a cada aluno quais foram os mdulos alocados para ele, com base nesta sumarizao. Ainda h uma outra forma de se construir o sistema, tendo um gerenciador de temporadas. Algum entraria no sistema e habilitaria o processo de registro dos professores. Aps um prazo estipulado, o perodo de inscries de professores estaria encerrado, e se iniciaria o processo de registro dos alunos, ficando novamente por mais um perodo, at que o processo fosse encerrado novamente. Isto tambm no conveniente, pois dependeria de interveno humana para um processo que poderia ser normalmente automatizado. Se voc observar a forma como so escritos os Use Cases, perceber que eles representam atividades discretas e atemporais, a serem executadas no sistema. Eles tm uma srie de fluxos alternativos como Adiciona ofertas, Remove Ofertas e por a vai. Raramente se leva em considerao o tempo, ou a ordem

www.portalbpm.com.br em que as atividades acontecem. Quando acontecem interdependncias, elas ficam por conta dos esteritipos <<extends>> ou <<includes>> . Voc pode colocar pr-condies, mas na realidade no h ligao entre dois use cases distintos, ou interdepncias como um use case somente se inicia quando outro tiver sido executado. Isto faz sentido, pois a idia de Use case uma funo discreta efetuada no sistema, que traz algum valor mensurvel para o usurio. Normalmente no uma preocupao dos use cases a interao entre os usurios. J este o foco dos Workflows. Permitir colaborao entre os usurios. 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 representao utilizada foi o BPMN, mas vamos entender como a sequncia 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 vrias instncias 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 sequncia de telas para faz-lo. Isto conseguido facilmente em uma ferramenta de colaborao atravs de uma rea de leitura pertencente a cada usurio chamada de Inbox. O Inbox funciona como um leitor de emails, 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 mdulos. Quando ele clica em algum lugar no Inbox, uma sequncia de telas apresentada para que ele faa esta atividade. O sistema somente passa ao losango Sumariza professores quando todos os professores j tiverem se oferecido (ou um determinado prazo tiver expirado). Aps sairmos desta etapa, os professores executaram sua atividade, e entra a fase em que os alunos se registram para os cursos disponveis. Quando os alunos esto se oferendo para os cursos, os professores no podem mais se oferecer para ministrar alguma disciplina. Quando todos os alunos j se ofereceram para assistir aos mdulos, o sistema sumariza e pode avisar aos alunos os mdulos aos quais eles esto 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 no controlado, nem mesmo a sequncia em que as atividades acontecem so controladas. Se quizermos controlar estes aspectos, teremos que colocar uma srie de interligaes entre os Use Cases que acabaro

www.portalbpm.com.br por tirar a unidade do mesmo. Isto acontece naturalmente em uma ferramenta de colaborao e expresso por um artefato conhecido como workflow. Mas, este tipo de representao serve a qualquer tipo de sistema a ser construido ? Na maioria dos processos que acontecem dentro das corporaes, existe colaborao. O produto pedido ao fornecedor pelo departamento de compras, recebido pela logstica, vendido ao cliente por vendas, cobrado por cobrana, e por a vai. O problema que para utilizarmos este novo pardigma, precisamos fatiar os sistemas de formas diferentes da que vnhamos fazendo at hoje.

subdiviso dos sistemas dentro da empresa

Como subdividir os sistemas


Se observarmos a figura anterior, at hoje vnhamos fatiando os sistemas por funcionalidades. Quais as responsabilidades do sistema de RH, por exemplo ? Permitir pagamento aos professores, consultar e marcar frias, 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 invs de dividir o sistema em torres verticais, os chamados sistemas, como foi feito acima, o ideal dividir o sistema em fatias horizontais, levando em considerao uma atividade, desde seu incio at seu trmino, mesmo que isto passe por vrios departamentos da empresa. Desta forma estaremos permitindo a colaborao entre as diversas reas. Ou seja, a proposta que os sistemas, ao invs 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 funcionrio ainda pertence a um departamento, e o ideal seria que ele respondesse por atividades, e no 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, aps os cursos terem sido escolhidos ? Quanto tempo leva um professor para oferecer cursos ? Como as ligaes entre os sistemas acontecem agora na horizontal, os tempos de execuo de cada tarefa pode ser medido com mais preciso. Quando uma seta sai de um perfil

www.portalbpm.com.br e entra em outro, neste momento a responsabilidade passa para o outro participante. Na implementao original por Use Cases, no h como mensurar o tempo que um aluno demorou para escolher um curso, aps o professor ter se oferecido. Na verdade, no h ligao no sistema entre o professor ter se oferecido para um mdulo e o aluno t-lo escolhido. Quando o professor registrou os cursos de seu interesse, automticamente a bola passou para o aluno, sem a interveno manual de ningum. Estes tempos podem ser medidos, e se imaginarmos um sistema corporativo mais complexo, teremos informaes importantes como : quanto tempo se leva em mdia para emisso de um boleto bancrio ? Quanto tempo um caixa demora para atender um cliente ? Com o tempo em mos, poderemos obter outro nmero mais interessante que , se para um determinado processo eu tenho o tempo gasto por cada participante, uma empresa pode mensurar quanto est gastando com mo de obra para obter o produto na sada. Isto permite que o preo do produto final pode ser medido com uma preciso 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 nmero de funcionrios para atingir o resultado esperado. Isto faz sentido na cabea de um gerente ou diretor de TI ! isto que estava comentando anteriormente, sobre ajustar o plano de vo do avio antes do destino final. Neste caso, o sistema deixa de apenas executar alguma funcionalidade, mas passa tambm a fornecer subsdios para tomada de deciso pela empresa. A informtica pode deixar de ser um mal necessrio 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 referncias), cada atividade de mais baixo nvel de um workflow representa um Use Case. A grande diferena em modelagem por use cases e modelagem por processos a forma como cada use case ligado. Os workflows agregam mais informao do que os Use Cases de forma isolada. Eu tenho a opinio de que, no nvel mais baixo do workflow, que para uma ferramenta BPM chega a definir cada atividade que um usurio efetua para completar uma etapa, teremos algo muito prximo de um diagrama de atividades da UML. Seria algo como:

Subdiviso em niveis do workflow

www.portalbpm.com.br No exemplo anterior, o use case associado como atividade do Workflow Registra para assistir. Se abrirmos um nvel a mais nesta atividade do workflow, teremos um sub-workflow com as etapas que o usurio deve fazer para se registrar. Mas se voc observar os passos dentro deste sub-workflow ir perceber que exatamente a descrio do fluxo principal deste Use Case. Ele tm a aparncia de um diagrama de atividades. Isto no novidade pois um diagrama de atividades pode ser utilizado para representar graficamente uma descrio de um Use Case. No nvel mais baixo, temos atividades que podem ser interativas ou automticas. Por exemplo, seleciona mdulos uma atividade onde os professores interagem com uma tela (ou sequncia de telas). Armazena mdulos selecionados um tipo de atividade executado independente da interao do usurio. Cada uma destas atividades pode ser presa a um processamento. Por exemplo, podemos prender armazena mdulos 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 disponveis 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 atrs, fabricantes de ferramenta EAI, bem como fabricantes de ferramentas de modelagem de processos e alguns de BI comearam a posicionar seus produtos no mercado como ferramentas BPMS (Business Process Management System). A idia de uma ferramenta BPMS permitir que um desenho dos processos seja feito de forma visual, e ainda que este desenho permita a execuo de um workflow, sendo que cada atividade esteja atachada a um pedao de cdigo, 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 necessrio suporte a algum servidor de aplicaes. Isto foi convencionado, de acordo com vrias empresas, e temos hoje o que chamamos de pure players, que so ferramentas puramente BPM, ou as ferramentas que no esto nesta categoria, que so ferramentas que tm algumas das caractersticas anteriores, mas no todas. Um desenho muito visto pela internet, quando se fala de ferramentas BPM, o seguinte :

Ferramentas BPM

www.portalbpm.com.br Os modeladores de processo, alm de ferramentas que permitam desenhar um processo (pelo menos os diagramas de workflow), devem tambm 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 teramos se alterssemos o fluxo para este ou aquele desenho. Deve existir uma ferramenta de EAI, que de preferncia integre com vrias 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 orquestrao o processo de gerenciar quem o usurio que est responsvel 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 mdulos oferecidos. O termo orquestrar como em uma orquestra musical, onde o maestro vai a cada momento gerenciando quem est em execuo a cada momento. Ainda deve ser possvel executar estes cdigos em algum engine, chamado de servidor de aplicaes. Todos os grandes players esto saindo de servidores de aplicao customizados, para servidores de mercado, como os J2EE (websphere, jboss, BEA, etc.) Em que estgio estamos atualmente ? Existem alguns players que j esto bastante avanados neste processo, j com todas as caractersticas de uma ferramenta BPM, e alguns esto prximos deste estgio, com boas ferramentas visuais e engines de execuo. Nos prximos anos, esta ser a nova onda, e isto est para mudar to profundamente o mercado que at mesmo os fabricantes de ERP esto se mobilizando para tornar seus ERPs compatveis com ferramentas BPM. Mas o que eu preciso para aprender isto hoje em dia ? Uma imensa quantidade de novos padres esto surgindo nesta esteira, como BPMN, BPML, BPEL, e mesmo a evoluo da modelagem por processos em si. Conhecer estes novos padres, e como eles esto integrando ser garantia de domnio do que ser a prxima onda no mercado de informtica. Referncias http://www.proformacorp.com/Downloads/whitepapers.asp http://www.bpmn.org Livros Visual modeling with Rational Rose and UML Terry Quatrani

Você também pode gostar