Universidade Federal de Pernambuco CENTRO DE INFORMTICA PS-GRADUAO EM CINCIA DA COMPUTAO

BRUNO LOUREIRO DE ABREU

UMA LINGUAGEM PARA MODELAGEM DE PROCESSOS BASEADA EM SEMNTICA DE AES

ORIENTADOR: Hermano Perrelli de Moura CO-ORIENTADOR: Luiz Carlos Menezes

RECIFE, DEZEMBRO / 2005.

BRUNO LOUREIRO DE ABREU

UMA LINGUAGEM PARA MODELAGEM DE PROCESSOS BASEADA EM SEMNTICA DE AES

DISSERTAO APRESENTADA PSGRADUAO EM CINCIA DA COMPUTAO DO CENTRO DE INFORMTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENO DO GRAU DE MESTRE EM CINCIA DA COMPUTAO.

ORIENTADOR: Hermano Perrelli de Moura CO-ORIENTADOR: Luiz Carlos Menezes

RECIFE, DEZEMBRO / 2005.

ii

BRUNO LOUREIRO DE ABREU

UMA LINGUAGEM PARA MODELAGEM DE PROCESSOS BASEADA EM SEMNTICA DE AES

DISSERTAO APRESENTADA PSGRADUAO EM CINCIA DA COMPUTAO DO CENTRO DE INFORMTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENO DO GRAU DE MESTRE EM CINCIA DA COMPUTAO.

Aprovada em ____de_____________de ___________.

Banca examinadora: ____________________________________________________ Prof. Dr. Hermano Perrelli Moura Orientador Universidade Federal de Pernambuco ____________________________________________________ Prof. Dr. Andr Santos Universidade Federal de Pernambuco ____________________________________________________ Prof. Dr. Ricardo Massa Universidade de Pernambuco

iii

Dedico esta dissertao a minha famlia, bela e incansvel companheira na principal misso humana: amar a vida e v-la sempre com esperanas...

iv

AGRADECIMENTOS
Agora, com nossos melhores sentimentos, dedicamos nosso tempo para agradecimentos, sem dvidas to merecedores.

A Deus pela graa da vida e pelas condies de realizaes to valiosas. A minha famlia, em especial a minha tia, Iolanda Abreu, meu tio Odlio Xavier (em memria), por tornarem possvel esta realizao, sempre acreditando em mim, e a minha me, Giovana Abreu (em memria), que mesmo fora deste ambiente material sempre me deu fora e inspirao para atingir meus objetivos. A Alexsandra Santos, minha esposa e companheira, pela intensa felicidade que me proporciona. Ao doutor, amigo e orientador, Hermano Perrelli de Moura, pelo enorme estmulo e apoio para que mais este passo fosse vitorioso em minha vida profissional. A Luiz Carlos Menezes, meu co-orientador, que sempre se mostrou disposto a tirar as dvidas que surgiram no decorrer da realizao deste trabalho. A UFPE que desde a formao da graduao em Cincia da Computao, tenho enorme respeito e admirao, aproveito para externar os inesquecveis agradecimentos. A amiga Anglica, pela ajuda na reviso do abstract. A todos aqueles que com palavras ou aes contriburam para realizao deste trabalho.

RESUMO
Modelos de processos de negcio so criados para descrever, em uma linguagem de fcil acesso, como os processos de uma organizao so realizados. objetivo final do processo. Para facilitar o entendimento e a anlise de processos deste tipo, a modelagem visual a mais adequada. Nesta modelagem, as atividades so representadas por unidades de execuo e o fluxo de execuo do processo descrito atravs de um fluxograma, que define a seqncia de execuo destas atividades. Os modelos de processos so utilizados como fonte de informao para o diagnstico de pontos de gargalo que levem perda de eficincia da organizao na realizao de suas tarefas. A anlise de processos um procedimento que tem como objetivo realizar ajustes no processo ou at mesmo refaz-lo por completo, visando sempre o aumento de produtividade da organizao. A utilizao de modelos visuais como ponto de entrada para a anlise torna a realizao desta tarefa muito subjetiva, uma vez que o impacto de mudanas no processo apenas sentido quando o mesmo colocado em prtica. Dessa forma, torna-se necessria utilizao de um mecanismo mais formal para a representao do processo que venha possibilitar a anlise e a simulao mecanizada destes processos. Neste contexto, este trabalho define a ANBPL (Action Notation Business Process Language), que viabiliza a especificao de processos formalmente. Na definio da semntica desta linguagem foi utilizado o framework de Semntica de Aes, utilizado para a especificao de linguagens de programao. Apesar do carter textual utilizado para descrever processos, a ANBPL possui uma representao simples, o que a torna de fcil entendimento. Na ANBPL, um processo de negcio representado como uma coleo de conexes entre atividades, onde operadores so especificados para descrever os diferentes tipos de conexes. Cada operador define uma regra particular para o controle do fluxo de execuo das atividades interligadas pelo mesmo. Para isso, o processo visto como uma coleo de atividades que interagem para a realizao do

Palavras-chave: Linguagem para Execuo de Processos, Modelagem de Processos de Negcio, Semntica de Aes.

vi

ABSTRACT
Business process models are created in order to describe, in a common language, how the organization processes are accomplished. The process is perceived as a compilation of activities that interact among them to accomplish the main goal of the process. In order to ease both understanding and process analysis of this kind, visual modeling is the best choice. On this modeling, the activities are represented by execution units and the process execution flows are described through a flowchart, which defines the order of execution of these activities. The process models are used as an information source to the diagnosis of points that impliys the loss of organization efficiency in the tasks accomplishment. The process analysis is a procedure that point out how to make adjustments to the process or even refector it as a whole, always aiming towards productiveness increase. The use of visual models a gateways to the analysis make the task accomplishment too subjective, because the change impact on the process is only perceived when it comes to execution. This way, its necessary the use of a formal mechanism into the process representation that might enable analysis and mechanized simulation of those processes. In this context, this work defines the ANBPL (Action Notation Business Process Language), which enables formal process specifications. At the semantic definition of this language it was used Action Semantic, a common framework to specify programming languages. Besides the textual aspect used to describe process, an ANBPL have a very simple representation that made it easy to understand. In the ANBPL environment, a business process is represented as a collection of links between tasks that have operators to describe different kinds of connections. Each operator defines a particular rule to the execution flow control of the interlinked activities owned by it.

Key-words: Business Process Modeling, Business Process Execution Language, Action Semantics.

vii

SUMRIO
1 Introduo _______________________________________________________ 1
1.1 1.2
1.2.1 1.2.2

Motivao _________________________________________________________ 1 Objetivos __________________________________________________________ 2

Objetivo Geral ___________________________________________________________2 Objetivos Especficos _____________________________________________________2

1.3 1.4

Metodologia ________________________________________________________ 3 Estrutura do Trabalho _______________________________________________ 3 Benefcios da Modelagem de Processos de Negcio ________________________ 6 Tcnicas de Modelagem de Processos de Negcios ________________________ 7
ASME American Society of Mechanical Engineers_____________________________8 EPC Event Process Chain_________________________________________________8 IDEF3 Integration Definition For Function Modeling 3 ________________________11 IDEF Integration Definition For Function Modeling _______________________13 UML Unified Modeling Language _________________________________________16 QPL Quality Process Language ___________________________________________22

Modelagem de Processos de Negcio __________________________________ 5

2.1 2.2
2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6

2.3

Linguagens de Execuo de Processos _________________________________ 24 Sub modelos_______________________________________________________ 27

Processos Privados ______________________________________________________27 Processos Abstratos ______________________________________________________28 Processos de Colaborao _________________________________________________28

BPMN Business Process Modeling Notation _________________________ 26

3.1
3.1.1 3.1.2 3.1.3

3.2
3.2.1 3.2.2

Diagrama de Processos de Negcio ____________________________________ 29

Categorias de Objetos do Diagrama de Processos de Negcio _____________________29 Objetos do Diagrama de Processos de Negcio ________________________________30

Semntica de Aes _______________________________________________ 39

4.1 4.2
4.2.1 4.2.2 4.2.3

Sintaxe Abstrata ___________________________________________________ 40 Entidades Semnticas _______________________________________________ 42

Aes _________________________________________________________________42 Dados_________________________________________________________________43 Yielders _______________________________________________________________44

4.3 4.4
4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.4.6

Funes Semnticas ________________________________________________ 44 Facetas ___________________________________________________________ 46

Bsica ________________________________________________________________47 Funcional ______________________________________________________________49 Declarativa_____________________________________________________________51 Imperativa _____________________________________________________________52 Reflexiva ______________________________________________________________53 Comunicativa___________________________________________________________54

4.5
4.5.1 4.5.2 4.5.3 4.5.4 4.5.5

Ferramentas ______________________________________________________ 56
ASD Tools _____________________________________________________________56 Cantor ________________________________________________________________57 Actress ________________________________________________________________57 OASIS ________________________________________________________________57 Abaco (Algebraic Based Action COmpiler) ___________________________________58

viii 5 Action Notation Business Process Language___________________________ 59

5.1 5.2
5.2.1 5.2.2 5.2.3

Sintaxe da Linguagem ______________________________________________ 61 Entidades Semnticas _______________________________________________ 65

Unidades de execuo do processo __________________________________________68 Tipos de Conexes_______________________________________________________73 Manipulao dos Agentes _________________________________________________78

5.3 5.4
5.4.1 5.4.2

Definio da Semntica _____________________________________________ 79 Processos de Negcios na ANBPL _____________________________________ 81

Pintura de Peas_________________________________________________________83 Confirmao de Viagem __________________________________________________86

Concluso e Trabalhos Futuros _____________________________________ 94

6.1 6.2 6.3 Trabalhos Relacionados _____________________________________________ 94 Contribuies _____________________________________________________ 95 Trabalhos Futuros _________________________________________________ 95

REFERNCIAS _____________________________________________________ 97

ix

LISTA DE FIGURAS
Figura 2.1 Modelo de Processo utilizando tcnica EPC. ........................................... 10 Figura 2.2 Processo de Pintura Modelado em IDEF3 ............................................... 12 Figura 2.3 Notao IDEF ........................................................................................ 14 Figura 2.4 Processo de Pintura modelado em IDEF............................................... 15 Figura 2.5 Diagrama de caso de uso Realizar Venda ................................................ 18 Figura 2.6 Diagrama de caso de uso Realizar Venda Detalhado .............................. 19 Figura 2.7 Processo de Venda modelado em diagrama de atividades UML.............. 20 Figura 2.8 Notao usada pela QPL. ......................................................................... 23 Figura 3.1 Processo de Venda Privado. ..................................................................... 28 Figura 3.2 Processo de Atendimento Abstrato............................................................ 28 Figura 4.1 Gramtica de Linguagem Fictcia............................................................. 41 Figura 5.1 Gramtica da ANBPL ............................................................................... 61 Figura 5.2 - Representao de uma atividade da ANBPL. ............................................ 66 Figura 5.3 Ambiente de Execuo com IdActivity e Action. ......................... 67 Figura 5.4 Converso da Sintaxe nas Entidades Semnticas. .................................... 68 Figura 5.5 Modelo de associaes realizadas por idActivity no ambiente de execuo da ANBPL ....................................................................................................................... 69 Figura 5.6 Traduo de um processo da BPMN para a notao de aes. ............... 81 Figura 5.7 Processo Pintura de Peas Descrito na BPMN. ....................................... 83 Figura 5.9 Processo de Confirmao de Viagem na BPMN. Com Destaque Nos Pontos de Conexo Entre as Atividades......................................................................... 92

LISTA DE TABELAS
Tabela 2.1 Motivaes para a criao de um modelo de processo de negcio. ........... 5 Tabela 2.2 Notao Grfica Utilizada em EPC ............................................................ 9 Tabela 2.3 Notao Utilizada pela tcnica IDEF3. .................................................... 13 Tabela 2.4 Notao Utilizada Por UML ..................................................................... 17 Tabela 2.5 Processo de Venda descrito por narrativa................................................ 21 Tabela 2.6 Elementos de diagrama QPL..................................................................... 23 Tabela 3.1 Elementos grficos BPMN do tipo Evento. ............................................... 30 Tabela 3.2 Elementos grficos BPMN do tipo Gatilho e Resultado. .......................... 31 Tabela 3.3 Elementos grficos BPMN do tipo Atividade............................................ 34 Tabela 3.4 Elementos grficos BPMN do tipo Processo. ........................................... 34 Tabela 3.5 Elementos grficos BPMN do tipo Fluxo.................................................. 35 Tabela 3.6 Elementos grficos BPMN do tipo Loop. .................................................. 36 Tabela 3.7 Elementos grficos BPMN do tipo Geteways de Deciso......................... 36 Tabela 3.8 Elementos grficos BPMN do tipo Artefato. ............................................. 37 Tabela 3.9 Elementos grficos BPMN do tipo Swimlanes. ......................................... 38 Tabela 5.1 Mapeamento dos elementos pertencentes a notao grfica de BPMN para elementos da gramtica da ANBPL. .............................................................................. 63

Captulo 1
1 Introduo
A modelagem de processos de negcio consiste em uma rea de contnuo desenvolvimento e amadurecimento, onde diversas metodologias foram e continuam sendo desenvolvidas com o objetivo de oferecer mecanismos simples e prticos para a representao de processos de negcio. Como a audincia dos envolvidos na anlise destes tipos de processos dentro de uma organizao bem ampla, faz-se necessrio adoo de modelos de processos de negcios que sejam de fcil entendimento por todos os envolvidos, facilitando a comunicao entre as partes interessadas na anlise e entendimento dos processos. Com base neste princpio, as metodologias para modelagem de processos existentes procuram se basear em notaes que utilizam componentes visuais para a criao de modelos de processos de negcio. Um crescente nmero de ferramentas para gerenciamento de processos est oferecendo a funcionalidade de simulao para estender as funes de modelagem. Simulao colocada como um facilitador para avaliar o impacto de mudanas em processos existentes ou na utilizao de novos processos em uma organizao. A simulao viabiliza a avaliao do impacto, em um ambiente real, decorrente de mudanas nos processos de uma organizao, possibilitando tomadas de decises mais seguras na adoo de novos processos ou mudanas nos processos de uma organizao. Outro ponto de destaque no uso da simulao de processos corresponde na identificao de pontos falhos ou de gargalo em processos de negcio [3].

1.1

Motivao

Apesar da existncia de inmeras tcnicas de modelagem de processos [6] [9] [14] [16] [20] [34] e do amadurecimento deste mercado, existe uma lacuna que vem demandando muito estudo e pesquisa. Esta lacuna est na falta de linguagens onde processos de negcio possam ser escritos de acordo com uma sintaxe e semntica bem definidas, para

2 que possam ser executados, permitindo a simulao de situaes organizacionais em um ambiente de execuo computacional.

1.2

Objetivos

1.2.1 Objetivo Geral O objetivo deste trabalho de definir uma linguagem textual e formal, onde processos de negcio possam ser escritos da forma mais natural possvel. Esta linguagem deve possuir operadores que representem as diversas maneiras possveis de controle de fluxo entre as atividades pertencentes a um processo de negcio. A linguagem deve ter sua semntica definida de maneira formal, onde deve ser utilizado um framework formal, para especificao de linguagens, capaz de dar significado aos operadores presentes na linguagem. 1.2.2 Objetivos Especficos As atividades necessrias para a realizao do objetivo geral so: entender o significado e todos os conceitos que norteiam a modelagem de processos de negcio; pesquisar as diversas tcnicas ou notaes para modelagem de processos existentes no mercado, possibilitando o entendimento dos requisitos mnimos que uma linguagem de modelagem de processos deve ser dotada; eleger a tcnica ou a notao grfica utilizada para modelagem de processos de negcio, que sirva como ponto de inspirao para o projeto da linguagem de processos; estudos sobre o framework formal utilizado para projeto de linguagens de programao, denominado de Semntica de Aes [26]; projetar uma linguagem formal para representao de processos de negcios, definindo sua sintaxe e sua semntica utilizando Semntica de Aes; validar a completude da linguagem, utilizando-a para representar processos de negcios definidos graficamente; sugerir novas linhas de pesquisas que possam ser derivadas deste trabalho.

1.3

Metodologia

O desenvolvimento deste trabalho foi direcionado por etapas bem definidas, com o objetivo de adquirir o conhecimento necessrio para a definio de uma linguagem capaz de representar processos de negcios. Em um primeiro momento ocorreu a realizao de estudos sobre a rea de modelagem de processos de negcio, onde boa parte da bibliografia foi levantada e os conceitos que norteiam este tema foram estudados. Em seguida, a pesquisa foi direcionada ao estudo das tcnicas e notaes existentes para modelagem de processos de negcio, este estudo contribuiu para o entendimento de aspectos importantes a respeito da modelagem de processos. Nessa etapa foi eleita uma notao que servisse como alicerce para a definio da linguagem proposta. Como resultado, a notao de maior destaque na literatura para a modelagem de processos de negcio, BPMN [8], foi a selecionada. A prxima etapa deste trabalho correspondeu ao entendimento de um framework formal para descrio de uma linguagem de programao. Com base nos conhecimentos adquiridos nas etapas anteriores, foi realizado o projeto de uma linguagem para representao de processos de negcios.

1.4

Estrutura do Trabalho

O Captulo 2 deste trabalho d uma viso geral sobre a modelagem de processos de negcio, onde so tratados aspectos importantes como: benefcios trazidos pela adoo da modelagem de processos de negcios, tcnicas de modelagem e a atual situao que se encontram os projetos existentes de linguagens para execuo de processos de negcio. No Captulo 3 ser apresentada uma notao para modelagem de processo de negcio, conhecida como BPMN. Em um mundo marcado pela heterogeneidade de notaes e tcnicas para modelagem de processos, levando a conseguinte carncia de uma notao padro para este fim, a BPMN surge com muita importncia e vem sendo considerada uma notao padro para modelem de processos.

4 O Captulo 4 apresenta o framework de Semntica de Aes utilizado no projeto linguagens de programao, sendo de extrema importncia para o entendimento do projeto da linguagem, objetivo deste trabalho de pesquisa. No Captulo 5, onde o produto final deste trabalho de pesquisa apresentado, detalhada uma linguagem para representao de processos de negcio, denominada de ANBPL (Action Notation Business Process Language). Onde sua sintaxe definida, inspirando-se nos operadores existentes na BPMN, apresentada no Captulo 3, e sua semntica descrita com a utilizao do framework de Semntica de Aes. Ainda neste captulo, so apresentados exemplos de processos de negcio escritos na BPMN e sua transformao para os elementos existentes na ANBPL. As concluses e sugestes para trabalhos futuros so detalhadas no Captulo 6.

Captulo 2 2 Modelagem de Processos de Negcio

A modelagem de processos de negcio tem como objetivo principal descrever as atividades que fazem parte de um processo de negcio e como elas se relacionam para atingir seu objetivo final. As atividades so tarefas que tanto podem ser realizadas manualmente como mecanicamente. importante no confundir a modelagem com a engenharia de processos de negcio, uma vez que a modelagem no tem o objetivo de indicar como um processo de negcio deve funcionar, sendo apenas uma tcnica utilizada para visualizar e documentar o funcionamento de um processo de negcio. O modelo de um Processo de Negcio desenvolvido atravs da aplicao de tcnicas especializadas. Ele pode ser construdo com diferentes objetivos, dependendo das necessidades da organizao. Na Tabela 2.1 so apresentados quatro propsitos que motivam a criao de um modelo de processo de negcios, sendo estes: funcional, informativo, organizacional ou comportamental [20]. Tabela 2.1 Motivaes para a criao de um modelo de processo de negcio. Tipo Funcional Objetivo Definir que atividades so realizadas e quais os dados que fluem entre elas. Esclarecendo o papel de cada atividade, de acordo com as transformaes que so realizadas sobre os dados manipulados. Informativo Levantar as entidades (documentos, dados, artefatos, produtos) produzidas ou manipuladas no decorrer de um processo, includo seus relacionamentos e sua estrutura. Organizacional Esclarecer o motivo pelo qual as atividades so realizadas e onde elas acontecem. Definir os mecanismos de comunicao fsica e armazenagem das informaes pertencentes ao processo. Comportamental Representar o momento e a seqncia que as atividades so realizadas, como elas interagem e suas condies de execuo.

Uma atividade que faz parte de um processo de negcio tida como um componente que realiza uma funo especfica. Atividades complexas so compostas por outras atividades, que direcionam sua execuo. Um processo tido como uma composio de atividades, podendo tambm ser visto como uma atividade dentro de um processo de maior magnitude [4]. Existem trs tipos de processos: core, suporte e processo de gerncia [18] [24]. Os processos classificados como core so aqueles que geram produtos para clientes externos da organizao, sendo considerados processos comercialmente importantes, podendo se tomar como exemplo: processos de venda e processos de atendimento ao cliente. Processos de suporte so aqueles que geram resultados para a prpria organizao, sendo fundamentais para o funcionamento do negcio. Enquanto que os processos de gerenciamento descrevem como os outros processos devem ser gerenciados. Nos prximos sub-tpicos sero tratados aspectos relevantes aos benefcios conquistados quando organizaes adotam a modelagem de processos, tcnicas utilizadas para modelagem e linguagens para execuo de processos.

2.1

Benefcios da Modelagem de Processos de Negcio

Como as complexidades de uma organizao so oriundas do seu comportamento, a modelagem dos processos de negcios existentes em uma organizao surge como a melhor estratgia para entender a organizao. So grandes as vantagens existentes ao se modelar um processo de negcio, uma vez que viabiliza um melhor entendimento do funcionamento do mesmo, permitindo sua documentao e facilitando uma anlise mais detalhada, a partir do levantamento de informaes a respeito de como o processo realizado, que recursos so necessrios para seu funcionamento e quais os seus responsveis. A modelagem de processo de negcios utilizada em uma organizao para o entendimento, a representao, e, quando necessrio, serve como meio para re-projetar um processo [20]. A especificao correta dos processos essencial para qualquer empresa, uma vez que processos de negcios bem projetados so necessrios para que, nos momentos corretos, sejam tomadas as decises corretas dentro de uma organizao.

7 Com o aumento da competitividade, empresas dos mais diversos setores buscam cada vez mais aprimorar seus processos, para que possam atender da melhor forma possvel seus clientes, reduzir custos e aumentar sua produtividade. Neste contexto, a modelagem de processo tem um papel primordial no entendimento do funcionamento dos processos existentes nas empresas e na deteco de pontos crtico ao funcionamento do mesmo. Na contnua procura por obter processos de negcio mais eficiente, muitas empresas concentram seus esforos no aperfeioamento de seus processos ou tomam medidas mais radicais, conhecidas como reengenharia de processos, fazendo com que o processo sofra reestruturaes mais profundas [34]. A opo pela reengenharia de processos, em algumas situaes, traz ganhos de maior magnitude com relao primeira, porm consiste em um caminho mais demorado, custoso e de maior risco organizao.

2.2

Tcnicas de Modelagem de Processos de Negcios

Esta Seo tem o propsito de descrever algumas tcnicas utilizadas para modelagem de processos de negcios. Como a complexidade das organizaes torna-se cada vez mais crescente, de extrema importncia o uso de boas tcnicas de modelagem de processos. Os modelos de processos permitem diferentes pessoas envolvidas com os processos organizacionais observarem estes de uma forma padronizada, possibilitando uma melhor comunicao entre elas. O entendimento de como um processo funciona o ponto de partida para a criao do modelo deste processo. Porm, a identificao um processo nem sempre uma tarefa fcil de ser realizada. Como pode ser observado em [30], aps contatos com pessoas responsveis por definir o funcionamento dos processo de negcios em suas empresas, geralmente com a misso de dar mais produtividade a organizao, elas acabam concordando sobre a grande dificuldade da realizao desta tarefa. A primeira etapa que uma organizao deve realizar para criar modelos de seus processos de negcios eleger qual a tcnica de modelagem de processos melhor se adequa as suas necessidades. Esta definio no uma tarefa fcil de ser realizada, visto que, com a crescente popularidade da modelagem de processos de negcios,

8 muitas tcnicas surgiram com o passar do tempo, tornado essa escolha uma tarefa dispendiosa. Nas seguintes subsees sero descritas algumas tcnicas que podem ser adotadas para a realizao da modelagem de processos. 2.2.1 ASME American Society of Mechanical Engineers A ASME, fundada em 1880, desenvolveu um padro para mapeamento de processos que amplamente utilizado em fbricas e cada vez mais popular em escritrios e ambientes que disponibilizam servios [34]. Este mtodo tem a grande vantagem de produzir um modelo de processo onde so identificadas claramente quais atividades trazem benefcios ao objetivo final do processo. Durante a elaborao do modelo deve ser especificado para cada etapa ou atividade pertencente ao processo, se a mesma acrescenta benefcios ao objetivo final do processo. A construo de um modelo de processo baseado nesta tcnica facilita a realizao de uma anlise mais direta sobre o funcionamento do processo, facilitando a identificao de quais atividades, pertencentes ao processo, no acrescentam benefcios direto ao objetivo final do processo, tornando atividades deste gnero sujeitas a serem excludas do processo em uma tomada de deciso da equipe de anlise dos processos da organizao. 2.2.2 EPC Event Process Chain A EPC consiste em uma tcnica de modelagem de processos que, apesar de sua simplicidade, possui uma boa expressividade na modelagem de processos de negcios [20]. Esta tcnica tem foco no cliente beneficiado pelo processo, em vez de ser orientada aos servios da organizao [21], tornando-a uma ferramenta atraente para a realizao de reengenharia de processos de negcios. O modelo adotado por EPC facilita a identificao de gargalos no funcionamento do processo, que podem torn-lo lento e ineficiente, levando subseqentemente insatisfao dos clientes da organizao. A notao utilizada por EPC, descrita pela

9 Tabela 2.2, formada por cinco elementos: Evento; Processo; Desvio; Fluxo e; Espera.

10 Tabela 2.2 Notao Grfica Utilizada em EPC Elemento Descrio Evento Uma mudana de estado em algum determinado momento que tenha alguma relevncia ao cliente (qualquer pessoa ou organizao, interna ou externa organizao). Um evento deve ser representado atravs de um crculo com um nome em seu interior, que o identifica. Processo Atividade ou uma srie de atividades que ocorrem durante um intervalo de tempo. Para a notao EPC apenas as atividades que possuem envolvimento dos clientes so consideradas. Os elementos do diagrama que so processos so representados em forma de retngulos, possuindo no seu interior o nome que o identifica. Desvio O Desvio representa um ponto de bifurcao condicional no fluxo de um evento ou processo, podendo levar o fluxo corrente de execuo a um outro sub-fluxo, dependendo do estado no qual o fluxo corrente se encontre. Fluxo Representa o movimento de objetos do cliente entre eventos e processos. Os objetos do cliente representam entidades de interesse a organizao, que fluem atravs de processos ou eventos internos a organizao. Espera Tempo mdio de atraso para o incio de um evento ou processo. Sendo representado por uma seta abaixo de um crculo com a letra W (Waiting Time), no seu interior.
W

Notao

11

Na Figura 2.1 exibido o exemplo de um processo de consulta mdica modelado com a notao existente na EPC. Este cenrio retrata todos os passos a serem realizados por um paciente (cliente da organizao), ao realizar uma consulta em um hospital (a organizao em questo), desde sua chegada at o momento de sua sada [21].

Interior do Consultrio Mdico

E2 Chegada Paciente

W [60 min.]

P2 Consulta [30 min.]

Precisa Remdio Sim

No

Sala de Espera
E1 Chegada Paciente P1 Registro [30 min.] P3 Pagar Prescrio [15 min.] E3 Deixar Hospital

Farmcia

E3 W Requisitar Remdio [30 min.]

E4 Receber Remdio

Figura 2.1 Modelo de Processo utilizando tcnica EPC. Como pode ser observado no processo modelado acima, das 2:45 (duas horas e quarenta e cinco minutos) gastos em todo o processo apenas 30 minutos foram gastos no processo de consulta, que era o real objetivo do paciente, ficando clara a necessidade de uma melhoria nesse processo, para que tempo gasto em outras atividades e eventos caia o mximo possvel, tornando o tempo de todo o processo o mais prximo possvel do tempo gasto no processo consulta.

12

2.2.3 IDEF3 Integration Definition For Function Modeling 3 IDEF3 um mecanismo criado com o objetivo principal de coletar e documentar um processo de negcio. Esta tcnica possui mecanismos capazes de expressar claramente relacionamentos de precedncia e casualidades entre os eventos pertencentes a um processo de forma natural, devido ao seu mtodo estruturado para expressar conhecimentos a respeito de um sistema, processo ou organizao [1]. IDEF3 possui o poder de descrever aspectos comportamentais do funcionamento de um processo, servindo tambm como uma tima ferramenta para descrever um sistema existente ou um sistema proposto. O fato de IDEF3 descrever o processo dentro do contexto de um cenrio o torna um timo dispositivo para aquisio de conhecimento do funcionamento do processo. Uma descrio de processo IDEF3 desenvolvida usando-se dois tipos de estratgias para a aquisio de conhecimento. Uma direcionada descrio do processo e outra direcionada aos objetos que fazem parte do processo. A estratgia direcionada a processos organiza o conhecimento do processo focalizando no processo e seus relacionamentos temporal, casual e lgico dentro de um cenrio. Enquanto que na estratgia focalizada em objetos so observados os estados de transao dos objetos que fazem parte do processo. Esta observao pode ser realizada atravs de um ou mais cenrios. Nesta seo ser apenas apresentada a estratgia de modelagem baseada em processos. O modelo IDEF3 baseado na modelagem de processos captura o conhecimento de quais so os processo existentes em uma organizao, para que determinado produto seja desenvolvido ou servio seja realizado. Esta descrio de processo tambm leva em considerao toda rede de relacionamentos entre os processos existentes dentro do contexto peculiar ao cenrio no qual os processos ocorrem. O principal objetivo deste tipo descrio de processo consiste em mostrar como as atividades acontecem em uma organizao, responsvel pela realizao de uma determinada atividade ou soluo de um problema. O desenvolvimento deste tipo de modelo consiste em expressar como as aes so realizadas, cujas informaes so extradas de especialistas ligados rea em questo [17].

13 O seguinte exemplo ilustra como os elementos pertencentes ao mtodo IDEF3 podem ser utilizados para descrever um cenrio comum a um ambiente de produo. O cenrio a ser modelado corresponde ao processo de pintura de peas e inspeo que ocorrem durante a realizao da pintura de peas, que iro fazer parte de uma mquina de maior porte. Tal processo ocorre de acordo com o texto relatado, logo abaixo, pelo supervisor da loja de pintura quando pedido para que o mesmo descreva o que ocorre durante tal processo: As peas, prontas para receberem a primeira camada de tinta, entram na loja onde o processo de pintura ser realizado. Ns aplicamos uma primeira camada de tinta a uma temperatura elevada. A tinta colocada para secar em um forno. Aps um certo perodo de tempo a pea pintada parte para o processo de inspeo da pintura. Caso a pea no passe pelo processo de inspeo, verificando que a mesma no recebeu tinta suficiente, fazendo com que a pea receba uma nova camada de tinta. Caso contrrio, o processo de pintura considerado como finalizado. O cenrio descrito acima mapeado para um modelo descritivo de processo IDEF3 de acordo com a Figura 2.2. Podemos observar que as caixas rotuladas descrevem claramente as atividades existentes no cenrio apresentado. Erro! Indicador no definido.
Direciona para mais pintura

Pintar Pea
1

Secar Pea
2

Testar Pintura
3

Segue Prxima etapa

5

Figura 2.2 Processo de Pintura Modelado em IDEF3

O grfico acima composto por vrios tipos de elementos, os quais, so apresentados a seguir, na Tabela 2.3.

14 Tabela 2.3 Notao Utilizada pela tcnica IDEF3. Elemento Unidades Comportamentais (UC) Descrio Representam tipos de acontecimentos como eventos, aes ou processos. Na figura alm de ser destacado o nome do acontecimento, tambm exibido um nmero, servindo como um identificador nico que tambm indica sua seqncia no fluxo da execuo do processo. As setas que ligam as UCs, definem o fluxo de Fluxo execuo. Ou seja, uma UC, cuja seta esteja apontando, s dar incio a sua execuo at que a UC, de onde a seta partiu, termine sua execuo. As caixas menores definem pontos de juno no Ponto de Juno fluxo do processo, onde vrios caminhos podem convergir para um nico, ou um caminho pode divergir para outros possveis [36]. No modelo IDEF3, cada UC pode ser decomposta em outro grfico IDEF3, com o objetivo de aumentar o grau de detalhamento da UC, alm da possibilidade de existir vrias decomposies diferentes para uma mesma UC, cada qual expressando um ponto de vista do funcionamento do processo. 2.2.4 IDEF Integration Definition For Function Modeling IDEF um mtodo projetado para modelar decises, aes e atividades de uma organizao ou sistema. Esse mtodo foi oriundo de uma linguagem grfica bem estabelecida, a SADT (Structured Analysis e Design Technique), a qual foi projetada partir da necessidade da fora area americana de possuir um mecanismo para realizao de anlise de sistemas sobre uma viso funcional. A criao de modelos, utilizando IDEF, alm de possibilitar a anlise do sistema, facilita o entendimento de suas funcionalidades, tanto por parte do analista quanto pelo cliente. IDEF tem grande utilidade no estabelecimento do escopo de uma anlise. X
n

Notao

Nome

15 Como uma ferramenta de comunicao, IDEF amplia o domnio do sistema, proporcionando maior consenso nas tomadas de deciso, devido simplicidade de seus dispositivos grficos. Como ferramenta de anlise, IDEF auxilia o modelador do sistema a identificar que funes so realizadas, quais os recursos alocados execuo destas funes, e o que um determinado sistema faz de correto e de errado [14]. Controles

Entrada

FUNO

Sadas

Mecanismos Figura 2.3 Notao IDEF O modelo IDEF representado graficamente atravs de caixas e setas como pode ser observado na Figura 2.3, acima. As caixas representam funes, que so identificadas pelo nome existente em seu interior. As setas identificam os seguintes tipos de elementos: interfaces de entrada e sada, elementos de controle e mecanismos das atividades. As setas que representam as interfaces de entrada e sada so orientadas da esquerda para direita, onde as que entram representam as entradas, enquanto que as que saem representam as sadas. Os elementos de controle e mecanismos so modelados por meio de setas orientadas verticalmente, cruzando a atividade [25]. Os mecanismos representam os meios ou ferramentas utilizadas para a realizao de uma atividade e os controles ditam as condies necessrias para a produo correta da sada. Atividades podem se comunicar e operarem em seqncia, bastando estarem interligadas via as interfaces de entrada e sada, onde a interface de sada de uma atividade serve como interface de entrada para a outra. Essas interfaces so munidas de regras que fazem com que uma funo ative ou no outra. A composio de funes auxilia a captura e o entendimento das funcionalidades existentes em um processo modelado.

16 Para exemplificar a utilizao de IDEF, o exemplo do processo de pintura, usado para demonstrar a tcnica de modelagem IDEF3, apresentada na seo anterior, ser reutilizado na criao do modelo de processo presente na Figura 2.4, porm, fazendo uso da notao definida por IDEF.

Figura 2.4 Processo de Pintura modelado em IDEF

Primeiramente o processo de pintura, apresentado acima, mostrado em uma viso macro, onde apenas a atividade Pintar Pea apresentada, com suas entradas; sadas; controles e; mecanismos. Em seguida, abaixo da primeira verso, o mesmo processo apresentado de forma mais detalhada, onde a atividade Pintar Pea representada pelas atividades Pintar, Secar e Testar. Nesse segundo cenrio as atividades se interligam atravs das entradas e sadas e os controles e mecanismos so distribudos entre elas.

17 2.2.5 UML Unified Modeling Language A linguagem UML vem cada vez mais se consolidando na modelagem de sistemas dentro do paradigma Orientado a Objetos [23]. Tambm tida como uma linguagem de propsito geral para a modelagem de software, possuindo habilidades para especificar, visualizar, construir, e documentar os artefatos de um sistema de software, podendo tambm ser aproveitada para modelagem de negcios e outras modalidades de sistemas. Esta definio baseada em princpios e conceitos que a enquadram em qualquer tipo de sistema, seja software ou no [31]. UML se originou a partir da unio da Rational Software Corporation [16] com trs grandes metodologistas em sistemas de informao e indstria tecnolgica, Grady Booch, James Rumbaugh, e Ivar Jacobson. Passando a ser utilizada nos mais diversos tipos de organizaes, para posteriormente, em 17 de novembro de 1997, ser adotada pela OMG como um padro [37]. UML possui um vasto conjunto de diagramas, sendo til tanto na especificao estrutural quanto comportamental de um sistema. Cada um desses diagramas utilizado em diferentes fases do ciclo de vida de desenvolvimento de uma aplicao, que vo desde a fase de especificao at a fase de implementao. Com um total de nove diagramas definidos, UML capaz de representar vrias perspectivas, inclusive a representao comportamental. Durante muitos anos UML vem sendo usada na modelagem de uma variedade de tipos de sistemas, que vo de sistemas de software, sistemas de hardware, bancos de dados, sistemas de tempo real e organizaes. O suporte ferramental oferecido pela Rational para modelagem de negcio com UML possibilita a modelagem dos negcios das organizaes e seus processos. O uso compartilhado de uma ferramenta simples para modelagem de sistemas e negcio, facilita o entendimento das necessidades organizacionais. A seguir, na Tabela 2.4, apresentamos os elementos que fazem parte da notao utilizada por UML para modelagem de negcio. Os cones especficos nesse tipo de modelagem foram criados graas ao poder de extensibilidade de UML. Tal notao

18 traduz os elementos de negcio existentes no ambiente de organizacional em modelos visuais [9]. Tabela 2.4 Notao Utilizada Por UML cone que interage com a mesma. Ator de Negcio O Trabalhador de Negcio representa um Papel ou conjunto de papis dentro da organizao. Ele interage com outros Trabalhadores de Negcio, manipulando Entidades de Negcio. Trabalhador de Negcio As Entidades de Negcio so elementos manipulados ou utilizados por Trabalhadores Entidades de Negcio de Negcio. Esses elementos podem sofrer transformaes no decorrer do processo. Uma seqncia de aes organizacionais (processo de negcio) que Casos de Uso de Negcio produza como resultado algum valor para um Ator de Negcio. A Realizao de Casos de Uso de Negcio representada por uma coleo de diagramas para demonstrar como os elementos Realizao de Casos organizacionais so organizados para dar suporte aos processos de de Uso de Negcio negcio. Uma Unidade Organizacional composta por uma coleo de: trabalhadores de negcio, entidades de negcio, relacionamentos, Unidade Organizacional realizaes de casos de uso, diagramas, e outras unidades organizacionais. Usada para estruturar o modelo de negcio pela diviso em partes menores. Nas subsees seguintes sero descritos os diagramas de UML que do suporte a modelagem de negcio. Cada qual provendo um diferente ponto de vista do negcio na organizao. Definio O Ator de Negcio considerado algum ou algo fora da organizao

19 2.2.5.1 Diagramas de Casos de Uso

Do ponto de vista do uso de UML no desenvolvimento de sistemas, um caso de uso consiste em uma seqncia de aes que um ator (sendo um usurio do sistema, ou outro sistema externo) realiza sobre um sistema, para atingir um determinado objetivo. Tendo o papel de descrever um aspecto de utilizao do sistema [10]. Do ponto de vista de modelagem de negcio, o diagrama de caso de uso possui o papel de representar as interaes entre as entidades externas organizao (fornecedores, clientes, etc.), e os processos de negcio existentes na organizao. Um diagrama de casos de uso de negcio deve representar visualmente as interaes existentes entre os servios oferecidos pela organizao e aqueles que fazem uso destes servios [9]. Atores e metas de processos negcios so elementos definidos no profile de UML para modelagem de processos de negcios, que so tratados pelo diagrama de casos de uso. Os Atores so claramente explicitados; as metas definem o objetivo de um processo de negcio. Para demonstrar a meta de um processo de negcio, pode-se utilizar um ou mais casos de uso. Por exemplo, na Figura 2.5 utilizado apenas o caso de uso Realizar Venda, enquanto que na Figura 2.6 a meta do mesmo processo alcanada pela realizao dos casos de uso: Realizar Venda, Checar Estoque e Checar Perfil Cliente, aumentando o detalhamento das aes que precisam acontecer para atingir os objetivos do processo de negcio.

Figura 2.5 Diagrama de caso de uso Realizar Venda

20

Checar Perfil Cliente

Figura 2.6 Diagrama de caso de uso Realizar Venda Detalhado Associar casos de uso a processos de negcio um mecanismo til para identificar os casos de usos que so realizados na perspectivas dos usurios com a realizao de processo de negcio. Porm, casos de uso apenas refletem funcionalidades de alto nvel, na perspectiva de um ou mais atores, no sendo capazes de representar o fluxo das atividades que ocorrem dentro de uma organizao para atingir tais objetivos [10]. 2.2.5.2 Diagramas de atividades

Na modelagem de um sistema, um diagrama de atividades de UML definido como forma de expressar o dinamismo do sistema, atravs do seu fluxo de execuo. O diagrama de atividades utilizado na modelagem de negcio prov uma forma grfica de documentar o fluxo das atividades existentes em uma organizao. Possibilitando o entendimento de como ocorre o fluxo de execuo das atividades pertencentes a um processo, quais atividades podem ser executadas em paralelo e a verificao de fluxos alternativos de execuo do processo [9]. Alm de modelar o fluxo de atividades, estes diagramas possuem a capacidade de modelar a realizao de tarefas por mltiplos atores em paralelo. Para expressar isto graficamente, o diagrama dividido em colunas, denominadas de swimlanes. Os swimlanes so bastante teis para mostrar como os atores de negcio participam da realizao do fluxo de execuo das atividades. Alm dos swimlanes, o diagrama de atividades possui elementos importantes como barra de sincronizao, indicando pontos de execuo onde o fluxo de execuo pode ser bifurcado para execuo paralela de atividades ou servindo como um ponto de convergncia de vrias atividades. Outro elemento que faz parte dos diagramas de atividades so os pontos de deciso,

21 representados por losangos, indicando caminhos condicionais atravs do processo de negcio. Para modelagem de negcios os Diagramas de Atividades sofrem uma configurao especial, fazendo uso de objetos denominados de Entidades de Negcio, que podem ser criados, atualizados ou utilizados no decorrer do processamento das atividades. Se a modelagem de processos de negcio feita com o objetivo de esclarecer os requisitos de um sistema, algumas entidades de negcios podero vir a se tornar classes de anlise durante projeto de um sistema orientado a objetos para dar suporte a tal processo.Na Figura 2.7 podemos observar o exemplo de um processo de negcio modelado em um diagrama de atividades. Erro! Indicador no definido. :Cliente :Vendedor :Setor de Estoque

Requisitar Produto

Lanar ordem de venda

Verifica Nvel

ok

no ok
Pagar Emitir Alarme de Estoque baixo

Separar Itens da Venda

Receber Objeto de compra

Dar baixa na ordem de venda

Figura 2.7 Processo de Venda modelado em diagrama de atividades UML Uma maneira complementar para documentar as atividades utiliza a narrativa como um instrumento importante para melhor esclarecer o modelo. A Tabela 2.5 apresenta um exemplo de como documentar os passos do processo referente ao exemplo citado acima, utilizando a tcnica de narrativa. [37]

22 Tabela 2.5 Processo de Venda descrito por narrativa Passo Cliente 1 Requisitar produto 2 Pagar pelo produto 3 4 5 6 Tomar posse de produto comprado. 2.2.5.3 Diagrama de Classes Dar baixa em ordem de venda, liberando mercadoria mediante verificao de pagamento integral. Vendedor Lanar ordem de venda. Verificar estoque do objeto da compra. Separar Itens da venda. Setor de Estoque

O diagrama de classes de negcio tem o objetivo de modelar a estrutura interna do negcio. Neste diagrama os elementos trabalhador de negcio e entidade de negcio so modelados como sendo classes, possibilitando a documentao dos seus relacionamentos, provendo uma forma fcil de visualizar como se d interao entre esses elementos. Com o diagrama de classes de negcio, possvel esclarecer como as entidades e trabalhadores de negcio interagem para a realizao de um determinado processo de negcio. Esse tipo de diagrama um dispositivo de bastante utilidade na modelagem da estrutura esttica e relacionamentos das entidades de negcio [9]. 2.2.5.4 Diagramas de Interao

Os diagramas de interao podem assumir dois formatos: colaborao ou; seqncia. Os diagramas de interao usados na modelagem de sistemas orientados a objetos modelam os tipos de interaes que ocorrem entre os objetos que fazem parte do ambiente de execuo do sistema, mais precisamente, quando objetos se comunicam com outros, atravs do envio de mensagens, onde os objetos emissores das mensagens realizam chamadas as operaes que so executadas pelos objetos receptores das mensagens. A realizao de um caso de uso corresponde a um conjunto de interaes que so representadas dentro de um diagrama de interaes. Com foco na modelagem de negcios, os diagramas de interao, no formato de colaborao, documentam a realizao das interaes entre os trabalhadores de negcio e as entidades de negcio, necessrias para a execuo das funes referentes aos negcios da organizao. As interaes entre as entidades de negcio e trabalhadores de

23 negcio so representadas via de trocas de mensagens. Anlises podem ser realizadas sobre o diagrama de colaborao no sentido de identificar trabalhadores de negcio sobrecarregados com um grande nmero de tarefas, possibilitando tomadas de decises que visem um aumento de produtividade na realizao das funes de negcio organizacionais [9]. Apesar das informaes colocadas nos diagramas de seqncia serem as mesmas informaes tratadas pelo diagrama colaborao, elas so colocadas em um formato diferente, dando maior nfase seqncia das interaes entre os elementos de negcio, provendo uma melhor visualizao da execuo de um caso de uso de negcio [37]. Uma limitao destacada no uso de diagrama de seqncia para modelagem de processos de negcio, consiste na falta de um padro que possibilite a referncia entre o diagrama de atividades em questo com outros diagramas de atividades, sendo esta uma caracterstica fundamental para modelagem de complexos processos de negcios, onde vrios nveis de refinamentos so necessrios a fim de gerenciar a complexidade existente [10]. 2.2.6 QPL Quality Process Language A QPL definida como sendo uma notao para descrever os processos existentes em uma organizao, juntamente com um framework para gerenciamento de qualidade [6]. O mtodo da QPL considera alguns elementos bsicos para a modelagem de processos como: as informaes manuseadas pelos processos; proprietrios de processos; autoridade; controle e; links entre as atividades que fazem parte do processo. Tais elementos so descritos na Tabela 2.6.

24

Tabela 2.6 Elementos de diagrama QPL. Informaes As informaes descrevem os dados manipulados pelo processo e como eles esto organizados. Como por exemplo: documentos impressos; comunicao verbal; bancos de dados de computadores e; descries de objetos materiais. Na QPL, os recursos consumidos pelo processo em execuo so identificados atravs da verificao de que informaes so alteradas ou modificadas durante a realizao de um processo [6]. Processos Opera sobre as informaes e realiza transformaes sobre a mesma. Processos incluem todas as regras de negcio existentes dentro da organizao. Proprietrio Responsvel pela execuo do processo, podendo ser uma pessoa, um do processo Autoridade Controle Links grupo de pessoas (como um departamento) ou uma mquina. A especificao, descrio ou justificativa de um processo. As condies ou restries para a execuo de um processo Descreve como as informaes fluem entre os processos.

Na Figura 2.8 podemos observar como os elementos pertencentes notao de QPL so representados.

Controle Autoridade

Entrada

Processo __________ Proprietrio do processo

Sada no alterada

Sada Alterada

Figura 2.8 Notao usada pela QPL.

25

2.3

Linguagens de Execuo de Processos

As linguagens de execuo de processos de negcio possuem o papel de representar processos em uma notao que possibilite sua execuo. Elas no possuem utilidade na fase de anlise e modelagem de processos. As linguagens de processos definidas at ento possuem sua sintaxe expressa em XML, cada qual possuindo o seu formato nativo para representao de processos. Por isso, nenhuma dessas linguagens possui uma notao grfica padro para modelagem de processos. Essas linguagens podem ser utilizadas por ferramentas de modelagem de processos de negcio, para dar suporte simulao da execuo de processos. Foi com este objetivo que a WFMC (Workflow Management Coalition) desenvolveu a primeira linguagem com este fim. Uma nova verso XML da linguagem da WFMC foi lanada em 2002, com o nome de XPDL [42]. Outra iniciativa para concepo de uma linguagem para execuo de processos partiu da BPMI (Business Process Manager Initiative group), lanada em 2001, denominada de BPL (Business Process Language) [2][7]. Tal acontecimento aqueceu os estudos voltados para esta rea e deu muitas contribuies a sua sucessora, BPEL. A BPEL (Business Process Execution Language) [7][4] foi uma iniciativa da Microssoft e IBM em resposta a tentativa da BPMI em colocar a BPML como a linguagem padro para execuo de processos de negcio. Porm, desta vez, a linguagem recebeu um foco de ateno bem maior, a ponto de ser suportada pelas maiores empresas do mercado na rea, incluindo a (antes concorrente) BPMI, que no deu mais continuidade a BPML. BPEL, de fato, tornou-se o padro adotado para execuo de processos, sendo adotado por inmeras ferramentas de modelagem. Desde 2003 a organizao OASIS vem trabalhando na evoluo continua da linguagem BPEL, por um grupo de engenheiros especialistas na rea. A BPMI, apesar de ter deixado de lado suas ambies com relao a BPML, deu continuidade ao seu projeto de uma notao visual para modelagem de processos, denominada BPMN (Business Process Modeling Notation). Tal notao ser

26 apresentada em maior detalhe no prximo captulo, visto que a mesma serviu como base para a definio da linguagem proposta neste trabalho. Apesar da existncia de poucos projetos voltados construo de linguagens de execuo de processos, esses projetos so de grande magnitude e importncia, visto que envolvem uma quantidade grande de organizaes renomadas, como por exemplo, o projeto da BPEL, do qual faz parte a IBM e Microssoft, entre outras organizaes.

27

Captulo 3
3 BPMN Business Process Modeling Notation
A BPMN (Business Process Modeling Notation), desenvolvida pela BPMI [7], prov um diagrama para representao de processos de negcio, o qual foi projetado para ser utilizada tanto pelas pessoas que especificam como as que gerenciam processos dessa natureza. A corporao sem fins lucrativos, BPMI, tem o papel de capacitar empresas de todos os tamanhos a desenvolver e operar processos de negcios. Sua misso principal prover o desenvolvimento e uso da gerncia de processos de negcio atravs do estabelecimento de padres que possam ser utilizados, nas fases de projeto, execuo, acompanhamento e otimizao processos. Ela desenvolve especificaes abertas, que venham facilitar o gerenciamento de processos de negcio. Pessoas que lidam com os negcios da organizao esto habituadas a visualizar os processos em representaes visuais, baseando-se em simples fluxogramas. Neste contexto, com o passar do tempo diversas tcnicas e vrios tipos de diagramas apareceram, cada qual com suas vantagens e desvantagens. Com a carncia de uma notao padronizada para modelagem processos de negcio, surge a BPMI, intencionada em criar uma notao universal para fechar esta lacuna. Para alcanar tal objetivo, essa notao deve ser simples e de fcil alcance a todas as pessoas que fazem parte ou possuem algum tipo de interesse nos processos da organizao. A notao grfica de BPMN surgiu com o objetivo de oferecer a organizaes a possibilidade de comunicar seus processos entre seus indivduos de uma forma uniforme. Atualmente existem diversas ferramentas e metodologias para modelagem de processos de negcio. Dado que estes indivduos possam migrar entre organizaes e o fato das organizaes normalmente lidarem com diferentes notaes para a representao de seus processos, necessrio que os analistas estejam sempre aptos a utilizarem as diversas notaes. Essa heterogeneidade de notaes tambm pode ocorrer

28 quando se trabalha com o mesmo processo de negcio na mesma organizao, a partir do momento que so utilizadas diferentes notaes para representao de um processo em diferentes etapas do seu ciclo de vida, como: desenvolvimento; implementao; execuo; monitoramento e; anlise. Uma notao padronizada facilita o entendimento da realizao das colaboraes e transaes de negcio dentro e entre as organizaes. Assegurando o entendimento interno da realizao do processo bem como a comunicao entre diversas entidades que cooperam para a realizao do mesmo, dando maior agilidade s organizaes para se ajustarem s novas circunstncias e cenrios, tanto internamente quanto entre as organizaes com quem se relaciona. BPMN foi projetada no intudo de ser uma notao extensvel por modeladores e ferramentas de modelagem. Possibilitando a adio de elementos ou artefatos, que no fazem parte da notao padro, para satisfazer alguma necessidade de modelagem no suportada pela notao padro. Apesar desta facilidade, deve-se ter sempre em mente o requisito da facilidade de compreenso, uma vez que, qualquer diagrama projetado, utilizando-se algum elemento adicionado a notao da BPMN deva ser facilmente entendido.

3.1

Sub modelos

Os elementos estruturais da BPMN permitem que o leitor do processo tenha a capacidade de facilmente identificar as diferentes sees de um diagrama BPMN. Existem trs tipos bsicos de sub modelos dentro de um modelo completo especificado em BPMN. Sendo estes, descritos nas prximas sub-sees. 3.1.1 Processos Privados Os processos de negcio privados, ou internos, so aqueles que ocorrem dentro da organizao, correspondendo representao das atividades realizadas internamente e como elas interagem entre si. A Figura 3.1 ilustra um processo privado de venda, onde apenas as atividades que esto no mbito interno da organizao so retratadas no processo.

29

Registro de Itens

Totaliza Venda

Realiza Pagamento

Emite Cupom Fiscal

Figura 3.1 Processo de Venda Privado.

3.1.2 Processos Abstratos Os processos de negcio abstratos, conhecido tambm como processos pblicos, retratam as interaes das atividades pertencentes a um processo privado com outra entidade de negcio (outro processo ou um participante) externa ao processo privado. Nesses tipos de processos devem aparecer apenas as atividades que realizam algum tipo de comunicao com a entidade de negcio externa ao processo privado, alm das conexes entre as atividades, que ditam o fluxo de execuo do processo. As demais atividades, que no interagem diretamente com a entidade externa, no devem ser retratadas no modelo do processo. O processo abstrato de atendimento mdico, ilustrado pela Figura 3.2, por exemplo, retrata apenas as atividades que tm interao direta com o paciente. Erro! Indicador no definido. PACIENTE

Requisita Mdico

Atende Paciente

Recebe Sintomas

Prescreve Medicao

Solicita Medicamento

Envia Medicamento

Figura 3.2 Processo de Atendimento Abstrato. 3.1.3 Processos de Colaborao Os processo de negcio do tipo colaborao modelam as interaes entre dois ou mais processos de negcio. Nesta representao so apenas destacadas as atividades que se comunicam via troca de mensagens, entre processos distintos.

30

3.2

Diagrama de Processos de Negcio

O principal objetivo da BPMN de ser uma notao simples, a fim de ser facilmente adotada por analistas de negcio. Alm deste interesse, existe o requisito da BPMN ser suficientemente poderosa para representar processos de negcios de alta complexidade, o qual entra conflito com o primeiro. No intuito de compatibilizar estes desejos antagnicos, os elementos grficos da BPMN so divididos em categorias, que sero vistas na prxima sub-seo. 3.2.1 Categorias de Objetos do Diagrama de Processos de Negcio Para ser dotada de um mecanismo simples para prover modelos de processos de negcio e, ao mesmo momento, ser hbil na representao de processos cada vez mais complexos, a BPMN adotou a abordagem de categorizar os elementos existentes na notao. A notao define um pequeno grupo de categorias, facilitando o entendimento dos diagramas. possvel a adio de outros elementos a fim de tornar a notao mais poderosa e completa. As quatro categorias bsicas de elementos so as seguintes: Objetos de fluxo: So os objetos principais que definem o comportamento de processos de negcios. Esta categoria composta por trs tipos de objetos: Evento; Atividade e; Gatway. Objetos de Conexo: So os objetos, que conectam os objetos de fluxo. Existem trs tipos: Fluxo Seqencial; Fluxo de Mensagem e; Associao. Swimlanes: So entidades, pelas quais, so realizados os agrupamentos dos elementos Pools e Lanes, utilizados para particionar um diagrama BPMN de acordo com os responsveis pela execuo das atividades. Artefatos: So objetos utilizados para prover informaes adicionais sobre o processo. Apesar de modeladores e ferramentas de modelagem estarem livres para adicionarem tantos artefatos quanto forem necessrios, BPMN tem por objetivo padronizar classes de artefatos dividindo-os nos seguintes grupos: Dados; Grupo e; Anotao.

31

3.2.2 Objetos do Diagrama de Processos de Negcio As prximas tabelas exibem a lista completa dos objetos que podem ser utilizados em um diagrama BPMN. Devido quantidade grande de elementos existentes na notao, os elementos sero mostrados em grupos, de acordo com seu significado na notao. O Primeiro tipo de elemento apresentado o evento, que algo que ocorre dentro de um processo, afetando seu fluxo, normalmente tendo uma causa ou impacto. So representados por crculos e divididos em trs tipos: inicial; intermedirio e; final. Tabela 3.1 Elementos grficos BPMN do tipo Evento. Elemento Descrio Como o nome sugere, o evento inicial indica onde um determinado processo comea. Este tipo de evento inicia o fluxo Inicial do processo, desta forma no deve haver nenhum fluxo atingindo um evento inicial, apenas fluxo saindo do mesmo. Ocorre entre um evento inicial e final e afeta o fluxo de um processo, porm no possui os poderes para iniciar nem terminar Intermedirio um processo. Como o nome sugere, o evento final indica onde um determinado processo termina. Este tipo de evento finaliza o fluxo do Final processo, desta forma, no deve haver nenhum fluxo saindo de um evento final, apenas fluxo atingindo do mesmo. Existem tipos especializados de eventos finais, que sero vistos nas prximas tabelas.

32

Os prximos elementos a serem mostrados, so do tipo Gatilho e Resultado. Eles so agrupados em nove categorias: Mensagem; Relgio (Timer); Erro; Cancelamento; Compensao; Regra; Link; Mltiplo e; Trmino. Todos os Gatilhos e Resultados sero expostos pela tabela abaixo. Tabela 3.2 Elementos grficos BPMN do tipo Gatilho e Resultado. Elemento Descrio Este tipo de evento disparado com a chegada de uma Inicial Mensagem mensagem, dando inicio a execuo do processo. Indica que a chegada de uma mensagem dispara um evento no meio de um processo. Fazendo com que o processo continue, Intermediria caso ele esteja em pausa, ou mude o fluxo para o tratamento de uma exceo. Em um fluxo normal, ele utilizado para enviar mensagem a outro participante. O evento final estabelece que uma mensagem deve ser enviada a Final Inicial um participante ao trmino do fluxo de um processo de negcio. Este tipo de evento utilizado para iniciar um processo em determinado momento. Este momento pode ser um determinado dia e hora, ou em um intervalo de tempo. O Timer Intermedirio utilizado no decorrer de um processo de Intermedirio negcio, podendo representar uma data especfica ou um intervalo de tempo. Quando utilizado no fluxo principal, serve como um mecanismo de atraso no processo. utilizado em sub-processos contidos em uma transao Intermedirio
Cancelamento Relgio (Timer)

atmica. Ele deve aparecer anexado fronteira do sub-processo, ficando associado a outra atividade, que dar continuidade a outro fluxo de execuo no processo de negcio principal. O evento ser ativado caso algum evento final de cancelamento seja atingido pelo fluxo do sub-processo em execuo. Indica que a transao corrente deve ser cancelada, levando ocorrncia da ativao do evento intermedirio de cancelamento,

Final

que por sua vez deve estar anexado fronteira do sub-processo.

33 utilizado para associar um sub-processo transacional a uma atividade de compensao, fazendo com que a atividade de Intermediria compensao seja executada, caso o evento seja disparado. Esse evento, que deve aparecer anexado a fronteira do sub-processo, ser ativado quando algum evento final de compensao atingido pelo fluxo do sub-processo em execuo.
Compensao

P C
Compensao Anexada a um Processo

Uma atividade de compensao corresponde a uma atividade capaz de desfazer os efeitos causados pelo sub-processo. A representao desta configurao pode ser exemplificada de acordo com a segunda figura a esquerda, onde P corresponde ao sub-processo e C corresponde atividade de compensao. Este tipo de evento final utilizado dentro de um sub-processo transacional, para indicar a existncia de um rollback no subprocesso. Caso este evento seja disparado pelo fluxo de execuo, o evento intermedirio de compensao anexado a fronteira do sub-processo ser automaticamente disparado. Este tipo de evento disparado quando uma determinada condio a respeito do ambiente de execuo do processo torna-

Final

Inicial
Regra

se verdadeira. Fazendo com que o processo se inicie. Este tipo de evento apenas utilizado para tratamento de exceo. A regra corresponde a uma expresso que avalia algum

Intermediria

dado em processamento, caso a avaliao produza o valor verdade, o evento ser disparado. O Link Inicial utilizado para ligar algum ponto em um processo ao incio de outro. Processos ligados atravs de um link so vistos

Inicial
Link

como sub-processos dentro de um processo maior. Este tipo de evento utilizado para ligar algum ponto no interior do processo a outro processo de negcio. Este tipo de evento utilizado no final de um processo, ligando-o ao incio ou meio de outro processo, via a utilizao de eventos

Intermedirio

Final

iniciais e intermedirios, do tipo link, respectivamente.

34 Este tipo de evento indica que existem mltiplas formas para iniciar um processo, porm apenas uma delas ser necessria. Inicial
Mltiplo

Bastando que um dos possveis eventos ocorra. Semelhante ao evento inicial do tipo mltiplo, porm aplicado ao interior de um processo.

Intermedirio Este tipo de evento indica que mltiplas conseqncias iro ocorrer ao trmino de um processo. Como por exemplo, o envio Final simultneo de vrias mensagens. Este tipo de evento indica o ponto final da execuo de um processo. Trmino O Conector de pginas, representado por um evento intermedirio Link, apenas utilizado em modelos de processos Conector Pgina impressos, quando o processo ocupa nais de uma pgina. O Conector indica onde o fluxo seqencial deixa uma pgina e onde da continuidade na pgina seguinte. Este tipo de evento utilizado no tratamento de erro, seja para
Intermedirio

Conector

Trmino

gerao do erro quanto para captura. Um erro levantado, caso o evento deste tipo faa parte do fluxo normal e seja atingido. O tratamento de um erro ocorre quando o evento est anexo fronteira de uma atividade que gerou o erro. A forma de

Erro

representar esta configurao semelhante ao exemplo visto para o evento de compensao. Este tipo de evento representa a gerao de um erro. O erro
Final

gerado por este evento pode ser tratado caso haja um evento intermedirio de erro anexado a fronteira da atividade ou subprocesso causador do erro.

35

Tabela 3.3 Elementos grficos BPMN do tipo Atividade. Uma Atividade o termo genrico para a realizao de alguma tarefa dentro de uma organizao. Elas podem ser atmicas ou Atividade no. Existem trs tipos de atividades: Processo; Sub-Processo e; Tarefa. Os dois ltimos so representados por retngulos de bordas arredondadas, enquanto que processos no possuem fronteiras ou so representados pelo contedo dentro de um Pool. A tarefa corresponde a uma atividade atmica que faz parte de um processo. A Tarefa utilizada na situao em que a atividade dentro do processo no pode ser decomposta. Tarefa Um Processo encapsula uma coleo de atividades para a realizao de uma tarefa. J um Sub-Processo, que pode ser encapsulado ou expandido, pode ser utilizado dentro de um processo de maior magnitude, nesse contexto ele visto como uma atividade do processo. O Processo pode ser modelado como tendo vrias instncias e ainda um subprocesso pode ter sua atomicidade garantida pela definio de uma transao sobre o mesmo. Todos estes aspectos so tratados na notao BPMN e vistos na Tabela 3.4. Tabela 3.4 Elementos grficos BPMN do tipo Processo. Os detalhes de um sub-processo neste formato no so visveis no diagrama. O sinal de mais, visto no inferior da figura, indica que Sub-Processo Encapsulado a atividade um sub-processo, que possui um nvel mais profundo de detalhamento. Na forma expandida, o sub-processo apresentado em detalhes. As atividades que fazem parte do sub processo tornam-se visveis dentro da fronteira do processo. Sub-Processo Expandido Esta representao, que utilizada em objetos do tipo atividade ou sub-processos, indica a execuo paralela de mltiplas Mltiplas Instncias instncias do mesmo. Uma transao representada por uma regio que envolve um sub processo, dando o significado que tal sub-processo pertence a Transao uma transao.

36 O Fluxo Seqencial utilizado para indicar a ordem em que as atividades so executadas dentro de um processo de negcio. Existindo seis tipos, detalhados em seqncia. Tabela 3.5 Elementos grficos BPMN do tipo Fluxo. Fluxo normal aquele que se inicia em um evento inicial e continua atravs das atividades de um processo, por muitas vezes Fluxo Normal seguindo caminhos alternativos e paralelos, se encerrando ao atingir um evento final. Este fluxo pode ocorrer de forma condicional ou no. Um Fluxo No Condicional corresponde ao fluxo que no Fluxo no condicional afetado por qualquer condio nem passa por um Gateway. A conexo entre duas atividades corresponde a um simples exemplo deste tipo de fluxo. O fluxo condicional possui uma expresso condicional associada, Fluxo Condicional devendo ser testada para que o fluxo prossiga. Este tipo de fluxo identificado por um losngulo pequeno no incio da seta. Para os Gateways de deciso XOR e OR pode haver um fluxo de Fluxo Default sada do tipo Default que ser escolhido caso nenhum dos demais sejam. Possibilita o desvio do fluxo normal de um processo. Ele baseado em um evento intermedirio, que representa uma exceo, que pode ocorrer durante a realizao do processo, do Fluxo de Exceo qual ele faz parte. O fluxo de mensagens utilizado para mostrar a comunicao Fluxo Mensagem entre dois participantes via troca de mensagens. Uma associao de compensao possibilita o desvio do fluxo normal do processo e baseado em um evento intermedirio de Fluxo Compensao compensao.

37 A notao de BPMN possui dois mecanismos para representar loop em um processo, sendo estes descritos na Tabela 3.6. Tabela 3.6 Elementos grficos BPMN do tipo Loop. Este tipo de loop indica a ocorrncia de multiplas execues de uma atividade ou um sub-processo de forma sequencial. Loop Atividade Este tipo de loop utilizado para conectar um dos possveis fluxos de sada de uma atividade ao incio da outra atividade. Loop Fluxo Seqencial

Representados graficamente por losngulos, o Gateway usado para realizar convergncia ou divergncia sobre um fluxo seqencial. Dependendo do tipo, ele pode receber um ou mais fluxos de entrada e gerar um ou mais fluxos de sada. Ele pode representar os seguintes tipos de comportamento no fluxo de um processo: desvio (branching), bifurcao (forking), fuso (merging) e juno (joining). Marcadores colocados no interior do Gateway iro indicar seu tipo. Esses tipos so mostrados a baixo. Tabela 3.7 Elementos grficos BPMN do tipo Geteways de Deciso. Um Gateway Exclusivo (XOR) seleciona apenas um dos possveis fluxos de sada em tempo de execuo. A deciso pode acontecer baseado na avaliao dos dados processados pelas Geteway Exclusivo atividades ou pela ocorrncia de algum evento. Gateway Inclusivo define um ponto de deciso, onde um ou mais possveis fluxos podem ser escolhidos ao mesmo tempo. Uma condio default pode ser usada para assegurar que haver pelo menos um fluxo de sada. Existem duas verses para este tipo de Gateway, a primeira usa vrios Fluxos Condicionais saindo de uma atividade e a segunda Geteway Inclusivo utiliza um Gateway OR, normalmente utilizado quando h combinao com outro Gateway em um fluxo de sada.

38 BPMN utiliza o termo Merge para referenciar a combinao exclusiva de dois ou mais fluxos em um nico fluxo. Merge O Gateway AND pode ser utilizado em operaes de fork e join. And No fork, ele realiza o papel de transformar um fluxo seqencial de execuo em diversos fluxos paralelos, possibilitando a execuo paralela de atividades. Fork Utilizado para representar o join, o gateway AND recebe mais de um fluxo de entrada e alinha todos em apenas um fluxo de sada. A atividade conectada pelo fluxo de sada s inicia sua execuo quando todas as atividades que se conectam ao AND terminam suas execues. Join

Os elementos grficos apresentados em seqncia, so mais voltados a auxiliar a documentao e prover um nvel maior de informaes referentes ao processo de negcio modelado. Tabela 3.8 Elementos grficos BPMN do tipo Artefato. Os dados so artefatos, pois no afetam diretamente o fluxo de execuo ou o fluxo de mensagens, apenas oferece informaes Dados sobre o que as atividades necessitam para serem processadas e o que elas produzem aps seu processamento. Um grupo de atividades no deve afetar o fluxo das mesmas. Apenas sendo usado com propsito de documentao e anlise. Grupo As anotaes so utilizadas apenas para prover informacoes adicionais sobre o funcionamento do processo. Anotao

39 Tabela 3.9 Elementos grficos BPMN do tipo Swimlanes. Um Pool representa um participante em um processo. Dentro do Pool existem vrias atividades que pertencem ao contexto do Pool participante em questo. Um Lane consistem em uma partio dentro de um Pool, estendendo todo comprimento do Pool, seja de forma vertical ou Lane horizontal. utilizado para organizar e categorizar as atividades dentro de um Pool.

Os elementos existentes na notao grfica de BPMN, apresentados nas tabelas acima, do uma boa viso do poder da notao. A sua completude, o projeto bem feito e a credibilidade da BPMI, sua mantenedora, nesta rea foram alguns dos fatores que despertaram o interesse de inmeras ferramentas de modelagem de processo de negcio a adotarem esta notao como uma notao padro. No Capitulo 5, onde uma linguagem para processos de negcio apresentada, a BPMN utilizada como fonte de inspirao na definio dos operadores da mesma. Ela tambm utilizada em alguns exemplos de modelos de processos para que seja demonstrada a equivalncia de modelos de processos definidos na BPMN com os processos escritos na linguagem. O prximo captulo dedicado apresentao do framework de Semntica de Aes utilizado como ferramenta para a definio da semntica da linguagem proposta.

40

Captulo 4
4 Semntica de Aes
Desenvolvida originalmente por Peter Mosses [27] [26], juntamente com a colaborao de David Watt [39], Semntica de Aes consiste em um framework com grande potencial para representao de processamento de informaes. Ela foi concebida com o objetivo de ser utilizada na especificao de linguagens de programao, servindo para realizar sua documentao e auxiliar na definio de padres de implementao. Apesar de ser baseada em uma notao formal, facilmente compreendida, fazendo com que as especificaes baseadas em sua notao tornem-se bastante acessveis a programadores [26]. Possibilitando, inclusive, tais especificaes serem agregadas a descries informais, na especificao de uma linguagem de programao. Uma descrio em semntica de aes extremamente modular, possuindo propriedades como: extensibilidade; modificabilidade e; reusabilidade. Esta ltima, bastante requerida por projetistas de linguagens de programao. A notao de aes composta por primitivas e combinadores de aes. Cada primitiva representa um tipo especial de processamento de informaes enquanto que cada combinador representa uma particular mistura de controle de fluxo e vrios tipos de fluxo de informaes. A notao de aes foi projetada com primitivas e combinadores suficientes para expressar as formas mais padronizadas de controle de fluxo de dados. Tambm inerente em Semntica de Aes a utilizao de uma notao bsica para dados. Dentre os tipos, encontram-se valores booleanos, nmeros racionais, listas, tuplas e Maps. Semntica de Aes possui uma estrutura composicional, onde a semntica de cada frase da linguagem determinada pela semntica de suas sub-frases. Aes so entidades que representam potencialmente o processamento de informaes, ou seja, o significado de programas e as frases que o compem.

41 Semntica de Aes possui todas as propriedades desejveis a um mtodo para descrever linguagens de programao [41]: Legibilidade: Sua notao baseada em palavras bem sugestivas, deixando de lado o uso de simbologias complexas e obscuras, aumentando a legibilidade de suas descries semnticas. Outro ponto que contribui bastante para suas clareza consiste na utilizao de conceitos bem conhecidos computacionalmente. Modularidade: Especificaes baseadas em sua notao so construdas sobre um conjunto padronizado e pequeno de aes primitivas e combinadores de aes, que correspondem a um notvel recurso utilizado pela notao de aes e ditam o fluxo de processamento de informaes [27]. Tais propriedades possibilitam o uso de partes de uma especificao, baseada neste framework, na construo de novas especificaes. Abstrao: Sua notao baseada em conceitos genricos de processamento de informao e controle de fluxo, no se baseando em detalhes de implementao. Comparabilidade: A utilizao de primitivas e combinadores de aes padronizados facilitam a comparao semntica entre linguagens descritas na notao de aes. Uma descrio baseada em Semntica de Aes composta por trs mdulos principais, sendo estes: Sintaxe Abstrata; Entidades Semnticas e; Funes Semnticas [27].

4.1

Sintaxe Abstrata

A sintaxe de linguagens de programao determina a legalidade de um programa e o relacionamento entre os smbolos e as frases encontrados nele. A sintaxe definida sobre dois aspectos, sintaxe concreta e sintaxe abstrata. A sintaxe concreta se concentra na anlise de seqncias de caracteres para a validao de um programa. Ela normalmente obtida pela anlise lxica e sinttica das frases, onde o primeiro tipo de anlise se concentra em validar seqncias de caracteres como palavras legalmente vlidas em um programa, conhecidas tambm como lexemis; j a

42 anlise sinttica valida a estrutural das frases, analisa a combinao dos lexemes para a formao de frases que sejam vlidas em um texto que represente programa. A sintaxe abstrata oferece uma interface apropriada entre a sintaxe concreta e a semntica de uma linguagem. Para atingir este objetivo a sintaxe abstrata ignora todos os detalhes que no sejam semanticamente significantes para representar essencialmente a estrutura composicional de um programa. A notao adotada para representao da sintaxe abstrata de linguagens, no framework de semntica de aes, utiliza gramtica livre de contexto, a qual faz uso de expresses regulares para sua representao. Para melhor demonstrar tal notao na representao de Sintaxes Abstratas, ser apresentado um pequeno exemplo da Sintaxe Abstrata de uma linguagem de programao simplificada. Gramtica:
::= [Identificador := Expressao] | [if Expressao then Comandoelse Comando?]| [while Expressao do Comando] | [begin Comando end]. (2) Comando ::= Comando ; Comando* . (3) Expresso ::= Numeral | Identificador | [( Expressao )]| [Expressao Operador Expressao]. (4) Operador ::= + | - | * | | and | or. (5) Numeral ::= [digito+]. (6) Identificador ::= [letra (letra | digito)*]. (7) Digito ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9. (8) Letra ::= a | ... | z | A | ... | Z. Closed (1) Comando

Figura 4.1 Gramtica de Linguagem Fictcia Tal especificao composta por um conjunto de equaes. Onde cada equao similar a um grupo de produes em uma gramtica, usando-se para separar as alternativas possveis para cada elemento da gramtica. Smbolos terminais so escritos entre aspas duplas, como while e +. Enquanto que os no terminais so escritos livremente sem as aspas duplas e comeando com letra maiscula, como por exemplo: Expressao, Comando e Operador. As equaes (2), (5) e (6) fazem uso das expresses regulares, por exemplo.

43 Na segunda alternativa da equao (1) (if Expressao then Comando

Comando?) Comando? , else else

da gramtica exemplificada, utilizada a parte opcional que equivaleria utilizao da seguinte alternativa:
else Comando]

[if Expressao then Comando ] [if Expressao then Comando

Porm a utilizao da alternativa que possui parte opcional, torna a gramtica mais concisa. Sempre escrita, no final da gramtica, a palavra closed, indicando que todas as equaes da gramtica j foram especificadas e a mesma no estaria aberta a incluso de novas equaes.

4.2

Entidades Semnticas

As entidades semnticas servem para representar o comportamento de programas, com independncia de implementao. Em semntica de aes, so utilizados trs tipos de entidades semnticas: Aes; Dados e; Yielders. O principal tipo entre os tipos de entidades consiste nas Aes, ficando em segundo plano os Dados e Yielders. 4.2.1 Aes As aes so, essencialmente, entidades computacionais e dinmicas. A execuo de uma ao representa o processamento de informaes e reflete o natural passo-a-passo computacional. A notao utilizada para representar aes denominada de Notao de Aes. O processamento de uma ao, que pode fazer parte de outra ao (ao pai), pode levar a uma das possveis situaes: completes: Representa o trmino normal de uma ao; escapes: Representa uma terminao com ocorrncia de uma exceo, fazendo com que a ao pai seja desviada, caso o escape tenha sido capturado. fails: Representa o abandono da execuo de uma ao, caso a ao pai possua alternativas a ser executada, uma destas ser escolhida, caso contrrio ao pai tambm ser levada situao de fail;

44 diverges: Leva a uma execuo infinita da ao, levando inclusive a ao pai entrar nessa situao. A semntica de programas pode ser descrita utilizando aes, pois a sua execuo corresponde ao comportamento de programas. As aes processam alguns tipos diferentes de informaes, que podem ser classificados de acordo com a intensidade de propagao da informao, sendo estes tipos classificados de acordo com a seguinte relao: transient: Corresponde a tuplas de dados que alimentam aes para a realizao de processamento, tambm sendo utilizadas para representar informaes oriundas da execuo de aes. Este tipo de informao encontra-se disponvel apenas para uso imediato em uma ao. Informaes transient representam informaes computadas durante a execuo de um programa. Uma Coleo deste tipo de informao representada em tuplas, facilitando, desta forma, o acesso a cada item de dado. scoped: Mapeamento de identificadores (tokens) para dados. Os dados representados pelos tokens podem ser referenciados a qualquer momento durante a ao. stable: Dados armazenados em clulas. As informaes do tipo stable, podem ser criadas e alteradas por diversas aes, isto realizado apenas fazendo referncia clula que guarda o dado. Este tipo de informao persistido at o momento que explicitamente destrudo. permanent: Dados comunicados entre aes distribudas atravs do envio de mensagens. 4.2.2 Dados Dados, em semntica de aes, consiste nas informaes que so processadas pelas aes. Vrios elementos bem conhecidos so utilizados na representao de dados, como: valores booleanos, nmeros, caracteres, strings, listas, Sets e Maps. Para cada um dos tipos de dados relatados existe, na notao de aes, um conjunto de operadores

45 associados a esses tipos de dados. Novos tipos de dados podem ser especificados livremente para representao de informaes especiais. Na notao de aes a palavra data utilizada para representar qualquer entidade abstrata que represente algum tipo de dado. J a palavra individual representa um nico elemento pertencente a um dos possveis tipos de dados. Uma ao quando encapsulada em uma estrutura chamada abstraction tambm pode ser utilizada como um dado, permitindo ser manipulada por outras aes. 4.2.3 Yielders Yielders so elementos que podem ser avaliados para produzir dados durante o processamento de uma ao. Os dados produzidos preciso acessar as informaes correntes. Existem primitivas de Yielders previamente definidas na notao de aes. Como exemplo podemos apresentar o seguinte Yielder: the given number#2. Que, quando utilizado em uma ao, produz como resultado o valor numrico existente na posio 2 de uma tupla recebida pela ao corrente.

4.3

Funes Semnticas

As funes semnticas so utilizadas para mapear a sintaxe abstrata em entidades semnticas que representem o seu comportamento. As especificaes de funes semnticas so realizadas utilizando-se equaes semnticas. Onde, cada funo semntica deve possuir apenas um argumento. Para exemplificar, ser ilustrada todas as funes semnticas necessrias para dar um significado semntica sintaxe apresentada na Seo 4.1. As funes semnticas utilizadas so: execute_, avalie_, the operation result_, the value of_. A utilizao de mais de uma equao semntica para representar uma funo semntica comum na definio de funes semnticas. A funo semntica execute_, por exemplo, que opera sobre o elemento Comando, composta de seis equaes semnticas, com cada uma sendo aplicada a uma das possveis formaes do elemento no terminal Comando.

46
execute _ :: Comando action[completing | diverging | storing]. (1) execute [I: Identificador := E: Expressao] = give the cel bound to I and avalie E then store the given number#2 in the given cell#1. (2) execute [if E: Expressao then C: Comando] = evaluate E then check the given truth-value and then execute C or check not the given truth-value and then complete. (3) execute [if E:Expressao then C1:Comando else C2:Comando]= evaluate E then check the given truth-value and then execute C1 or check not the given truth-value and then execute C2. (4) execute [while E:Expressao do C:Comando] = unfolding evaluate E then check the given truth-value and then execute C and then unfold or check not the given truth-value and then complete. (5) execute [begin C:Comando end] = execute C. (6) execute(C1:Comando; C2:Comandos)=execute C1 and then execute C2. avalie_ :: Expressao ao [giving a value]. (7) avalie N:Numeral = give the value of N. (8) avalie I:Identificador = give the value bound to I. (9) avalie [ ( E:Expressao ) ] = avalie E. (10) avalie [E1:Expressao O:Operador E2:Expressao] = (avalie E1 and avalie E2) then give the operation-result of O. the operation-result_:: Operador yielder[of a value][using the given value#2]. (11) the operation-result + = the number yelded by the sum of (the given number#1, the given number#2) . (12) the operation-result - = the number yelded by the diference of (the given number#1, the given number#2) . (13) the operation-result * = the number yelded by the product of (the given number#1, the given number#2) . (14) the operation-result = not (the given valuer#1 is the given valuer#2) . (15) the operation-result and = both of (the given truth-value#1, the given truth-value#2) . (16) the operation-result or = either of (the given number#1, the given number#2) . the value of_ :: Numeral number (17) the value of N:Natural = number & decimal N .

Os nomes utilizados para representar as funes semnticas consistem de frases, que podem ser definidas livremente. Normalmente, so utilizadas frases bem sugestivas que venham a facilitar o entendimento da funo.

47 O lado direito das equaes semnticas utiliza a notao padro, para aes e dados, provida por semntica de aes. Cada funo semntica deve ter sua funcionalidade especificada, como por exemplo, a especificao da funo semntica: avalie_::Expressao ao[giving a value] assegura que todas as equaes semnticas utilizadas na sua especificao (equaes 7, 8, 9 e 10) s podem receber como parmetro um elemento do tipo Expresso, obedecendo a sintaxe abstrata definida previamente, e seu significado corresponde a uma ao que, quando executada, retorna um valor. A utilizao de [...] como parmetro de uma equao semntica corresponde a aplicao da equao a um dos possveis ns que a rvore sinttica abstrata pode assumir de acordo com a especificao da gramtica da linguagem. J no exemplo apresentado pela equao 6, utilizado (...), como parmetro para a equao semntica, denotando desta forma a aplicao da equao semntica a uma tupla, onde cada elemento da tupla corresponde a um possvel n da arvore de sintaxe abstrata que o tipo do elemento da tupla pode assumir. uma prtica bastante comum a representao de equaes semnticas em termos de outras equaes semnticas. Como pode ser observado na Equao 7
N:Numeral = give the value of N), (avalie

a qual faz referncia a funo semntica definida

pela Equao 17 (the

value of

N:Natural = number & decimal N).

As funes semnticas devem ser definidas de forma completa e consistente sobre as rvores de sinttica que define a linguagem. Deste modo, para cada elemento principal da sintaxe da linguagem necessrio especificao de uma funo semntica. Caso o elemento da sintaxe assuma mais de uma formao possvel deve existir uma equao semntica para cada uma das possveis formas deste elemento da sintaxe.

4.4

Facetas

A notao de aes apresentada em uma diviso de grupos de aes e Yielders, onde cada um desses grupos um tipo de Faceta. Excluindo a Faceta Bsica, todas as demais (Funcional, Declarativa, Imperativa e Comunicativa) esto intimamente relacionadas s categorias de informaes apresentadas anteriormente (transient, scoped, stable, permanent).

48 4.4.1 Bsica A faceta bsica lida com aes bsicas, que esto fortemente relacionadas a conceitos bsicos de controle de fluxo. As aes apresentadas aqui servem como alicerce para a representao das demais aes existentes nas outras facetas. O processamento de uma ao corresponde a um passo atmico, realizado por um ou mais agentes. Neste momento ser considerada apenas a existncia de um nico agente realizador da execuo de aes, onde passos de execuo ocorrem em uma ordem bem definida, no sendo permitida a execuo paralela. Neste cenrio assegurado que, em determinado passo de execuo, a informao corrente disponvel bem definida. Desta maneira, a execuo de uma ao tida como a realizao de passos seqenciais de execuo. A execuo de uma ao pode ser finita e terminar ou infinita e divergir. Nestas situaes a execuo das aes so consideradas como sendo dos tipos complete e diverge, respectivamente. Porm, em certa situaes, possvel que a execuo de uma ao escape da terminao normal, deixando de dar continuidade ao fluxo de execuo natural. Neste caso, a terminao da execuo da ao tida como anormal e o tipo de terminao associada a esta situao denominada de failure. 4.4.1.1 Aes e Combinadores

Adiante, ser mostrada toda a simbologia que compe a notao bsica de aes. O smbolo action, elemento primordial da notao de aes, denota o conjunto de todas as aes que fazem parte da notao de aes, no restringindo apenas as aes bsicas, mostradas nesta seo. As funcionalidades associadas a cada uma das aes (complete, escape, fail, commit, diverge e unfold) e aos combinadores de aes (unfolding_, indivisibly_, _or_, _and_, _ and then _ e _trap_), especificados abaixo, sero discutidos em seqncia.
complete escape fail commit diverge unfold unfolding_ indivisibly_ _ or _ _ and _ : action : action : action : action : action : action :: action action :: action action :: action, action :: action, action

action action

49
_ and then _ _ trap _ :: action, action :: action, action action action

A execuo da ao primitiva complete consome um nico passo de execuo em uma ao composta e termina normalmente, dando seqncia ao fluxo normal de execuo. A ao escape indica uma terminao anormal, no permitindo a continuidade do fluxo normal de execuo da ao composta, que atingiu o escape. Tal fluxo ser apenas redirecionado caso a ao composta seja o parmetro esquerda de um trap, que direcionar a execuo para a ao existente direita do trap. A execuo da ao fail aborta a execuo corrente, fazendo com que a alternativa em execuo seja abandonada e, caso haja outras alternativas possveis, uma destas ser executada. A ao A1 or A2 representa a escolha independente de implementao de uma das alternativas a ser executada. Caso uma das aes, existentes entre um combinador de ao _or_, atinja uma ao fail, a outra alternativa possvel ser escolhida para execuo. Quando h a ocorrncia de uma ao primitiva commit em uma alternativa em execuo, todas as demais alternativas so descartadas por completo. A execuo de A1 and A2 escalona passos de execuo entre A1 e A2 at que ambas completem, ou at que uma delas atinja um escape ou fail. Caso se queira forar a execuo de uma ao em um passo atmico, deve-se fazer uso do indivisibly, onde execuo da ao indivisibly A faz com que a ao A seja executada em um nico passo, impedindo que passos de execuo sejam intercalados entre esta ao e qualquer outra. Diferente de A1 and A2, a ao A1 and then A2, assegura que as aes A1 e A2, sero executadas em uma ordem bem estabelecida, na qual A2 s comeara a ser executada aps o trmino da execuo de A1. A execuo da ao diverge nunca termina a execuo. O combinador de ao
unfolding_

quando aplicada ao A (ou seja, unfolding A) faz com que a ao A

seja executada at a ao unfold, sub-ao da ao A, seja atingida, fazendo com que a ao A seja novamente executada.

50 4.4.1.2 Outcomes

Os outcomes so entidades auxiliares, utilizadas na especificao de aes, indicando os possveis resultados da execuo de uma ao. Na faceta bsica os seguintes outcomes so introduzidos:
outcome = completing| escaping| committing| diverging| failing| . failing = nothing.

Os possveis outcomes de uma ao so especificados da seguinte forma: A[O], onde A corresponde ao e O corresponde aos possveis outcomes da ao, sendo estes separados por |. Os outcomes completing, escaping, diverging e failing representam trmino normal, trmino anormal, no trmino e falha, respectivamente. Como failing um outcome de ocorrncia possvel na execuo da maioria das aes, caso em que a ao referencia uma informao indisponvel, ele considerado um outcome implcito, por isso, o mesmo igualado a nothing, que representa ausncia de outcome. O outcome
commit

permite a ocorrncia de uma sub-ao commit durante a execuo da ao.

4.4.2 Funcional A faceta funcional da notao de aes voltada para a especificao de fluxo de dados, onde informaes do tipo transient, representadas em tuplas de dados, so produzidas e consumidas por aes. As aes primitivas existentes na faceta funcional apenas so capazes de produzir informaes do tipo transientes, nas situaes em que o outcome resultante de sua execuo forem completing ou escaping. Porm, quando o outcome resultante for
diverging

ou failing, a ao no produzir, como resultado de sua execuo,

qualquer informao transient. Os dados transient resultantes de uma ao correspondem aos dados oriundos de sua execuo, que podem ser produzidos durante computaes realizadas na execuo desta, ou podem meramente corresponder a informaes de entrada de uma ao que foram repassadas. Quando uma ao representada por duas sub-aes, o resultado gerado pela sua execuo pode corresponder concatenao dos valores produzidos por ambas

51 sub-aes ou apenas pelos transientes resultantes da ao que realizou o ltimo passo de execuo, dependendo do tipo de combinador de aes utilizado. A notao de aes funcional corresponde a uma extenso da notao bsica de aes e de dados, com a incluso de novas aes primitivas, um novo combinador, e alguns novos Yielders. 4.4.2.1

Aes e Combinadores
. . . . action .

give _ :: yielder action escape whith _ :: yielder action regive :: action . choose _ :: yielder action check _ :: yielder action _ then _ :: action, action

A execuo de give Y, onde Y um yielder, retorna os dados transientes produzidos pela avaliao de Y. Caso Y gere algum resultado, give Y leva ao outcome
completing,

caso contrrio, o outcome resultante ser failing. Como uma tupla vazia

gerada por Y consiste em um resultado produzido pelo yielder, give() faz com que o outcome resultante seja completing, sendo que, neste caso, retornando uma tupla vazia. A ao primitiva regive apenas repassa todos os transientes recebidos sem realizar qualquer tipo de processamento sobre os dados. A ao escape whith Y realiza a execuo da ao escape e, em seguida, retorna os dados produzidos por Y. A ao choose Y consiste em uma generalizao de give Y, realizando uma escolha entre um dos transientes produzidos por give Y para ser o retorno resultante de sua execuo. Da mesma forma de give Y a ao choose Y, falha quando Y no gera nenhum resultado. A ao check Y necessita que Y seja avaliado para um valor boolean. Caso o valor seja true, a ao completa, outcome igual a completing. Caso contrrio, ela falha, outcome igual a failing. comum a utilizao da ao check Y em testes para a execuo de uma ao ou outra. Por exemplo, (check Y and then A1) or (check not Y and
then A2),

onde, quando Y avaliado para true, a ao A1 executada, caso contrrio, a

ao a ser executada ser A2. O combinador de aes A1 then A2

A2

representa a composio das aes A1 e A2, onde

s ser executada aps a execuo de A1. Os dados recebidos pela ao A1 then A2

52 so apenas passados ao A1, a qual pode realizar algum tipo de processamento sobre esses dados e gerar novos dados de sada, que sero apenas repassados a A2. Os transientes resultantes da execuo de A1 then A2 so os resultantes da execuo de
A2.

4.4.2.2

Yielders

Na faceta funcional novos yielders so introduzidos notao de aes. Sendo estes:

given_ given _#_ it then the _ yelded by _ :: data yielder :: datim, positive-integer : yielder : yielder :: data, yielder yielder yielder

O Yielder given Y produz os dados resultantes da avaliao de Y, contanto que os dados recebidos para avaliao sejam do tipo Y, desta forma, the given truth-value (onde o the opcional, tendo apenas a funo de facilitar a legibilidade) deve resultar
true

ou false, por exemplo. Caso o valor recebido no seja um truth-value, a ao

ir falhar. J o yielder given Y#n acessa o n-simo elemento pertencente a tupla recebida pelo yielder Y. Sendo assim, a construo the given truth-value#2, interpretada como um yielder que espera receber como parmetro uma tupla, na qual o segundo elemento da tupla seja do tipo truth-value. Os yielders it e then capturam transientes recebidos por uma ao, onde o it considera que apenas um item foi recebido pela ao. O yielder the _ yelded by _ enfatiza que o valor produzido pelo yielder no segundo parmetro do tipo de dado identificado pelo primeiro parmetro. Como por exemplo,
the natual yelded by it,

enfatiza que o dado capturado por it do tipo natural.

4.4.3 Declarativa As aes pertencentes faceta declarativa manipulam informaes do tipo scoped, que tm uma propagao maior que as informaes do tipo transient. Este tipo de informao permanece acessvel durante o processamento da ao que a gerou, a menos que seja propagada explicitamente. Informaes do tipo scoped so representadas pelo mapeamento de identificadores com entidades, que representam um subconjunto de todos os tipos de dados existentes na

53 notao de aes, sendo este subconjunto denominado de bindable. O mapeamento de identificadores em bindable denominado de binding. 4.4.3.1 Aes e Combinadores

A notao de aes declarativa estende a notao de aes bsica com a introduo de novas aes a combinadores. Abaixo so encontradas algumas das mais utilizadas nesta faceta:
bind _ to _ rebind _ hence_ :: yielder, yielder action :: action :: action, action action

A ao bind T to Y cria um binding do token T para o bindable produzido pelo yielder Y. A ao rebind utilizada apenas para repassar todos os binds recebidos na ao corrente para a prxima ao a ser processada. O combinador de ao _hence_, quando aplicado da seguinte forma: A1 hence A2, possibilita os bindings produzidos em A1 serem utilizados em A2. 4.4.3.2 Yielders

Nesta faceta, novos Yielders so adicionados. Abaixo so mostrados dois desses:

current bindings the_ bound to_ : yielder :: bindable, yielder yielders

O primeiro, current bindings, produz um map, contendo todos os bindings recebidos. O yielder the d bound to T produz um valor do tipo d, aps a avaliao do bindable associado ao token T, no map de todos os bindings existentes. Por exemplo, o yielder: the truth-value bound to b, produz um valor do tipo truth-value (true ou false) que esteja associado ao token b. 4.4.4 Imperativa Esta faceta especializada no tratamento de informaes do tipo stable, as quais possuem um tempo de vida maior que as informaes do tipo transiente e scoped. Informaes desse tipo representam valores atribudos a variveis em programas. As linguagens de programao representam informaes desse tipo atravs de acesso randmico de memria. Na notao de aes, informaes do tipo stable so representadas atravs do mapeamento de cells para dados do tipo storeable. As cells so elementos que representam o endereo ou localizao em uma rea de memria de acesso randmico.

54 4.4.4.1 Aes e Combinadores

A notao de aes imperativa enriquece a notao de aes, com novas aes para manipulao das informaes do tipo stable. Em seqncia, uma dessas aes apresentada.
store _ in _ :: yielder, yielder action

A ao imperativa store Y1 in Y2, altera o dado armazenado em uma cell reservada, produzida por Y2, com o valor do dado de tipo storable produzido por Y1. 4.4.4.2 Yielders

Nesta faceta apenas dois novos yielders so introduzidos.

current storage the _ stored in _ : yielder.

Onde, o current storage, d uma viso do estado atual de todos os dados armazenados. Enquanto que yielder the d stored in Y produz o dado do tipo d armazenado na celular produzida por Y. 4.4.5 Reflexiva A faceta reflexiva volta para a manipulao de informaes do tipo abstraction. Uma abstraction utilizada para encapsular uma ao, permitindo sua manipulao como se fosse um dado. Tal tipo de dado utilizado para representar as procedures das linguagens de programao. O tipo abstraction definido da seguinte forma: abstraction datum, indicando que uma abstraction um subconjunto dos datum. A forma de se criar uma abstraction sobre uma ao realizada atravs do seguinte operador:
abstraction of _ :: action abstraction

Onde, a ao recebida como parmetro corresponde a ao encapsulada na abstraction. 4.4.5.1 Aes e Combinadores

Nessa faceta apenas uma ao especificada.

enact_ :: yielder action

Essa ao deve receber como parmetro um Yielder, que deve produzir uma abstraction e ativar a execuo da ao encapsulada na abstraction. 4.4.5.2

Yielders
:: yielders, yielders yielders :: yielder yelder

aplication _ to _ clousure _

55 Assumindo que Y1 produz abstraction of A, e Y2 seja avaliado para um dado d, o uso de aplication Y1 to Y2, equivalente a abstraction of (give d then A). De forma similar, quando current bindings so avaliados para b, clousure Y1 equivale a abastraction of (produce b hence A). 4.4.6 Comunicativa A faceta comunicativa incrementa a notao de aes bsica e reflexiva com o processamento de informaes por um sistema distribudo de agentes. As informaes manipuladas nesta faceta so do tipo permanent. A comunicao entre os agentes ocorre de forma assncrona, ou seja, aps um agente enviar uma mensagem para outro agente, ele fica livre para seguir com seu processamento, no ficando na espera do momento em que a mensagem tratada pelo agente receptor. Mensagens transmitidas a um agente ficam armazenadas em um buffer ilimitado assim que ela chega no agente receptor. O fato de um agente receber uma mensagem durante o processamento de uma ao, no interrompe o processamento da mesma. O agente receptor s informado da chegada da mensagem quando a ao em execuo no agente checa o buffer. Cada mensagem carrega a identificao do agente que a envia e do agente que deve receb-la. Alm dessas informaes, uma mensagem pode possuir um contedo, que pode se um dado qualquer, inclusive uma abstraction (dado que encapsula uma ao). Na notao de aes comunicativa tudo que pode ser comunicado entre agentes, do tipo communication. Pertencente ao tipo communication existe dois tipos: message e contract.

56

4.4.6.1

Aes e Combinadores

Na notao de aes comunicativa, algumas novas aes so definidas:

send_ remove _ offer_ patiently_ :: :: :: :: yielder yielder yielder yielder primitive-action primitive-action primitive-action primitive-action

A ao send Y, onde Y do tipo message, inicia a transmisso de uma mensagem. A forma natural de se representar Y da seguinte maneira: a message [to Y1]
[containing Y2],

onde Y1 identifica para que agente a mensagem deve seguir e Y2

representa o contedo da mensagem. A ao remove Y, com Y produzindo uma

message,

realiza a retirada da mensagem do buffer de entrada do agente.

A ao offer Y, onde Y do tipo contract, especificada da seguinte forma: a

contract [to an agent] [containing abstraction of A],

onde A a ao a ser

executada na chegada do contract no agente receptor. A ao patiently A representa um estado de espera at que A falhe, para que a ao termine sua execuo. Com base nas aes primitivas, definidas acima, outras aes, denominadas de hbridas, so definidas na faceta comunicativa, como: receive
subordinate-action. Y, subordinate Y,

Abaixo, segue o exemplo de como a ao hbrida receive Y

definida.
receive Y = patiently choose a Y [in set or items of the current buffer] then remove the given message and give it

A ao receive Y representa a espera por tempo indeterminado chegada da mensagem Y. O uso da ao subordinate an agent, cria um agent apto a receber uma message contendo uma abstraction para executar a ao encapsulada na
abstraction.

Este artifcio exemplificado abaixo, onde um agent, identificado por subordinado e, em seguida, enviada ao mesmo uma encapsulando a ao. Isso faz com que a action A seja executada pelo

agent-exemplo, abstraction agent

identificado por agent-exemplo no momento da chegada da message.

give agent-exemplo and subordinate an agente and then bind the given string#1 to then given agent#2 and then hence send a message [containing clousure of abstraction of [to the agent bound to agent-exemplo]

A]

57

4.4.6.2

Yielders

Em seguida, segue os yielders existentes na notao comunicativa de semntica de aes, que so utilizados nas aes mostradas anteriormente.
current buffer performing-agent : yelder. : yelder.

O Yielder current buffer produz a lista de mensagens existente no buffer do agente, na ordem de chegada das mensagens. Durante a execuo de uma ao, o yielder performing-agent gera a identificao do agente em execuo.

4.5

Ferramentas

Com o amadurecimento de estudos e pesquisas na rea de Semntica de Aes, muitas ferramentas baseadas em sua notao vem sendo desenvolvidas e evoludas, dando um maior suporte a este framework. Nesta seo sero listadas algumas aplicaes baseadas em semntica de aes. 4.5.1 ASD Tools ASD Tools vem sendo desenvolvida desde 1993 por Van Deursen e Petter Mosses [13]. Eles provm um ambiente de suporte para uso de semntica de aes, incluindo facilidades para a utilizao de parsers, editor de sintaxe textual, realizao de checagem, e interpretador de descries em semntica de aes. Tais funcionalidades aumentam a produtividade na escrita e manuteno de longas especificaes em Semntica de Aes, alm de serem bastante teis no aprendizado da escrita na notao de aes. As especificaes suportadas por ASD Tools devem so escritas ASCII, obedecendo notao padro para especificao de semntica de aes. ASD Tools foi implementada usando-se os sistemas ASF e SDF [22].

58

4.5.2 Cantor O Cantor consiste em uma ferramenta para compilao de programas escritos em linguagens de programao, projetadas com o framework de Semntica de Aes [33]. O componente responsvel pela compilao escrito em Perl [38] e recebe como entradas a especificao da sintaxe e semntica da linguagem, ambas escritas em LATEX, utilizando a notao de aes. O compilador emite cdigo para a linguagem de mquina abstrata RISC, o qual compilado em cdigo para o processador RISC. O compilador do Cantor possui mdulo responsvel por realizar checagem sinttica, transformar programas em aes, compilar as aes geradas e um pseudo SPARC assembler. 4.5.3 Actress O sistema Actress [29] um gerador de compilador baseado em semntica de aes, recebe como entrada a descrio, em notao de aes, da linguagem fonte e, a partir desta descrio, gera um compilador. O compilador gerado traduz programas escritos na linguagem fonte para uma ao. Posteriormente realizada a checagem da boa formao da ao e, finalmente, realizada uma traduo desta ao em um programa C. 4.5.4 OASIS O gerador de compiladores OASIS [32] capaz de produzir compiladores eficientes e otimizados para linguagens procedurais e funcionais com funes de alta ordem e recursividade. O compilador, gerado automaticamente, produz cdigos que comparado em termos de eficincia a cdigos gerados por compiladores escritos manualmente. O OASIS formado basicamente por: um pr-processador escrito em PERL [38] que recebe as funes semnticas de uma linguagem e produz o gerador de aes para a linguagem especificada; um analizador e otimizador de aes, que recebe a ao programa e gera um cdigo diretamente para linguagem assembly, realizando anlises e otimizaes sobre a ao programa recebida, a fim de garantir eficincia no cdigo gerado;

59 Este sistema a evidncia mais convincente da aplicabilidade prtica de geradores de compiladores baseados em semntica de aes. 4.5.5 Abaco (Algebraic Based Action COmpiler) O sistema Abaco [28], consiste em uma ferramenta direcionada a dar suporte a escrita de especificaes de linguagens de programao em semntica de aes. O Abaco combina orientao a objetos e semntica de aes para produzir implementaes de linguagens de programao a partir da sua descrio semntica (especificada sobre a notao de aes). Todas as ferramentas apresentadas demonstram o amadurecimento deste framework de Semntica de Aes, e todos os benefcios trazidos pelos trabalhos realizados nesta rea de pesquisa se mostram bastante teis na utilizao deste framework para a definio de uma linguagem para modelagem de processos de negcios.

60

Captulo 5
5 Action Notation Business Process Language
A Action Notation Business Process Language (ANBPL), foi concebida tomando-se como base o fundamento que um processo de negcio consiste em um conjunto de unidades de execuo de tarefa, denominadas de atividades, conectadas entre si e que operam em harmonia para que o objetivo final do processo de negcio seja alcanado. Da mesma forma que as tcnicas para modelagem de processos de negcio se destinam a dar significado aos diferentes tipos de conexes e dependncias entre as atividades pertencentes a um processo de negcio, a ANBPL tem como escopo representar, baseando-se em uma notao formal, usando o framework de Semntica de Aes, os possveis tipos de conexes entre atividades. Neste contexto, as atividades so tidas como caixas pretas, que realizam algum tipo de processamento. Sendo assim, no parte do escopo da ANBPL a modelagem do significado de cada atividade, apenas ficando restrita representao das conexes entre elas, que do o significado global do fluxo de processamento do processo. A sintaxe da ANBPL baseada em um conjunto de operadores que expressam diferentes tipos de conexes entre atividades, definindo os possveis controles de fluxo de processamento que ocorrem em um processo de negcio. Os operadores existentes na linguagem foram criados com inspirao em um subconjunto dos operadores grficos existentes na BPMN [8], apresentada no Captulo 3 deste documento. A BPMN foi adotada como base para a definio dos operadores de fluxo da ANBPL, por se tratar de uma notao que conquistou grande espao no mercado, e, em meio a inmeras notaes para modelagem de processos, ela vem se consolidando como a notao universal para este fim, uma vez que a mesma adotada por uma gama grande de ferramentas de modelagem de processos de negcio.

61

O significado semntico desta linguagem foi concebido utilizando o framework de Semntica de Aes [26], normalmente utilizado na especificao de linguagens de programao, apresentado no Captulo 4. Devido grande quantidade de trabalhos e desenvolvimentos na rea de Semntica de Aes, como a construo de editores, interpretadores e geradores de compilador automticos, baseados em sua notao, tal framework se mostrou bastante atrativo para a especificao desta linguagem. Abrindo espao para a futura utilizao da ANBPL em conjunto com interpretadores, que operam sobre a notao de Semntica de Aes, na construo de simuladores de processos de negcio. A seguir listamos os passos que foram realizados na especificao da ANBPL: 1. Definio da sintaxe da linguagem: Neste primeiro momento a sintaxe da linguagem definida tomando-se como ponto de partida um grupo de operadores de fluxo, tendo os elementos necessrios para garantir uma boa representatividade para os processos de negcio que venham a serem escritos nesta linguagem. 2. Definio de entidades semnticas intermedirias: Nesta etapa algumas entidades semnticas so definidas com o objetivo de auxiliar o mapeamento da sintaxe da linguagem em elementos semnticos da notao aes. 3. Definio das Funes Semnticas: Nesta terceira e ltima etapa, a especificao da semntica da linguagem, baseada em sua sintaxe, realizada com a utilizao das Funes Semnticas do framework de semntica de aes. Nas prximas trs subsees deste Captulo as etapas destacadas acima, que consistem nos passos que foram realizados na especificao da linguagem, sero apresentadas em maiores detalhes.

62

5.1

Sintaxe da Linguagem

A sintaxe de uma linguagem tem como objetivo definir as regras para formao das frases que compem os programas. Cada linguagem possui sua prpria regra de formao, que define como as frases so compostas por smbolos e outras frases. na gramtica que essas regras de formao so especificadas. Na gramtica da linguagem todos os operadores e elementos que fazem parte de sua sintaxe so definidos. A gramtica da ANBPL, definida na Figura 5.1, apresentada em sua completude. Vrios smbolos no terminais so definidos, como: Connection; Connections; ConditionalActivity; ConditionalActivities; IdActivity; IdsActivities e; Process. Alm destes, os smbolos terminais: seq; seq-if; fork; join e; choice. Eles foram criados para servir como operadores que definem os diferentes tipos de conexes entre atividades pertencentes a um processo negcio. Gramtica:
(1)

Connection

::=

[IdActivity

seq

IdActivity]|

[IdActivity seq-if ConditionalActivity]| [IdActivity fork IdsActivities]| [IdsActivities join IdActivity]| [IdActivity choice ConditionalActivities]
(2) (3) (4) (5) (6) (7)

IdActivity IdProcess IdsActivities ConditionalActivity ConditionalActivities String

::= ::= ::= ::= ::= ::=

String String IdActivity

+

(String , IdActivity) ConditionalActivity

+

String String | String Dig | a | ... | z | A | ... | Z |

(8) (9) (10)

Dig Connections Process

::= ::= ::=

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 Connection+ Process IdProcess is Connections

Closed.

Figura 5.1 Gramtica da ANBPL

63 O smbolo no terminal Connection representa uma conexo entre atividades. Para cada tipo de conexo foi definida uma regra de formao na gramtica. O smbolo
IdActivity

representa o identificador de uma atividade, podendo assumir qualquer

valor, que atenda regra de formao do elemento no terminal String. O elemento ConditionalActivity tem o papel de representar a execuo condicional de uma atividade. A atividade identificada pelo segundo elemento da tupla, que define este tipo de elemento. O primeiro elemento da tupla corresponde a um valor que deve ser utilizado em um teste para indicar se a atividade deve ou no ser executada. Utilizando a mesma notao para representar uma tupla de um ou mais elementos, os smbolos IdsActivities, ConditionalActivities e Connections, foram definidos para representar respectivamente tuplas de elementos do tipo IdActivity,
ConditionalActivity

e Connection.

Na definio de um processo de negcio, que segue a regra de formao do elemento

Process,

deve ser especificado o nome do processo e uma tupla de elementos do tipo O nome deve ser especificado de acordo com a regra definida pelo

Connection.

elemento String. A tupla de Connection representada pelo elemento Connections. Pode fazer parte da Connections, qualquer que seja o tipo de Connection definido na gramtica da linguagem. Como os operadores presentes na sintaxe da ANBPL foram definidos com inspirao na BPMN, na Tabela 5.1 ser demonstrado o relacionamento dos elementos da notao BPMN com as diversas formaes que o elemento do tipo Connection pode assumir. Para cada um dos tipos de conexo ser dada uma descrio de como ocorreu o mapeamento dos smbolos da BPMN para as construes existentes na linguagem.

64 Tabela 5.1 Mapeamento dos elementos pertencentes a notao grfica de BPMN para elementos da gramtica da ANBPL. Fluxo No Condicional: representado pela ocorrncia de dois smbolos no terminais
IdActivity,

intercalados pelo smbolo terminal seq. Dando uma idia de execuo

em seqncia. Onde a atividade identificada pelo IdActivity, direita de seq, iniciar sua execuo apenas quando a atividade identificada pelo IdActivity, esquerda de seq, termine de processar e os dados gerados ao trmino de sua execuo ficaro prontos para serem consumidos pela outra atividade.

Connection ::= [IdActivity seq

IdActivity]

Fluxo Condicional: representado pelo smbolo terminal seq-if entre dois smbolos no terminais, onde o anterior ao seq-if um IdActivity, representando o identificador da primeira atividade na seqncia de execuo, e o posterior ao seq-if um ConditionalActivity, o qual composto por uma String e um IdActivity, onde este IdActivity define a segunda atividade a ser executada. O operador seqif

representa que a execuo em seqncia, dependente de uma condio.

Este operador define que aps a execuo da primeira atividade, a condio para a execuo da segunda depender do valor gerado pela primeira atividade coincidir com o valor existente na primeira parte da tupla, do ConditionalActivity. Apenas na situao em que os valores sejam os mesmos, a atividade identificada pelo IdActivity pertencente a ConditionalActivity, ser executada.

Connection ::= [IdActivity seq-if ConditionalActivity]

65

Fork: definido pelo smbolo terminal fork ligando um IdActivity a uma tupla de
IdActivity,

representada pelo smbolo IdsActivities. Tal tipo de conexo representa

a partio do fluxo de execuo de um processo de negcio em vrios fluxos de execuo paralela. Ao trmino da execuo da primeira atividade, identificada pela
IdActivity

esquerda do fork, todas as atividades que so identificadas pela tupla

de IdActivity, direita do fork, iniciaro uma execuo de forma simultnea, onde todos os dados produzidos pela atividade esquerda do fork tornar-se-o aptos a serem consumidos por estas atividades.

Connection = [IdActivity fork IdsActivities]

Join: Esse tipo de conexo identificada pelo smbolo terminal join, ligando uma tupla de IdActivity, identificado pelo elemento IdsActivities a um IdActivity. Representando desta forma a sincronizao de vrios fluxos de execuo paralela em um nico fluxo de execuo. Nesta construo a atividade, identificada pelo IdActivity direita de join apenas iniciar sua execuo aps todas as atividades identificadas pelo smbolo
IdsActivities,

esquerda do join, terminem sua execuo.

Connection = [IdsActivities join IdActivity]

66

Geteway Inclusivo Baseado em Dados: Ser representado pela utilizao do smbolo no terminal choice, ligando um identificador de atividade, IdActivity, a um elemento do tipo ConditionalActivities. Nesse tipo de conexo o operador choice representa a realizao da escolha de quais atividades iro entrar em execuo aps o trmino da execuo da atividade identificada pelo IdActivity, esquerda de choice. Cada ConditionalActivity pertencente ao ConditionalActivities, ter o valor presente no primeiro elemento da tupla, que o representa, comparado com o valor produzido pela atividade, identificada por
IdActivity.

Todas as ConditionalActivity, cujos testes no falhem, tero a que define o executada.

atividade indicada pelo IdActivity, segundo elemento da tupla

ConditionalActivity,

Connection = [IdActivity choice ConditionalActivities]

Aps apresentar a sintaxe da ANBPL, as prximas sees deste captulo tero o papel de definir a semntica da linguagem.

5.2

Entidades Semnticas

Na definio da sintaxe da linguagem, vrios elementos do tipo Connection foram definidos e tiveram seu comportamento descrito textualmente, porm, uma descrio informal no suficiente para que a linguagem seja passvel de execuo. Por isso, necessrio definir a semntica da linguagem, utilizando um mecanismo formal para sua especificao. com esta tarefa que o framework de Semntica de Aes ser utilizado no projeto da linguagem. Nesta linguagem as atividades, que fazem parte do processo de negcio, so vistas como unidades de processamento distribudas que se comunicam atravs de diferentes tipos de conexes, que ditam o fluxo de execuo do processo. Para expressar este

67 cenrio ser utilizada a faceta comunicativa de Semntica de Aes, a qual lida com entidades denominadas de agent, que se comunicam via a troca de mensagens. Para expressar a semntica dos diversos tipos de conexo a ANBPL representa cada atividade como sendo uma unidade de execuo, que se encontra hospedada em um
agent.

As conexes entre essas atividades so expressas atravs de troca de mensagens

entre agents. A Figura 5.2 expressa esse significado. Onde agent representa um agent, que possui em seu interior uma executionUnit, da qual faz parte duas colees de elementos do tipo Actions, uma denominada de Receivers e outra de Senders. A executionUnit significa a unidade de execuo que define as condies necessrias para o processamento de uma atividade e o que deve ser realizado aps seu processamento. Receivers e Senders definem respectivamente, a lista de mensagens que precisam ser recebidas, para que a atividade seja executada, e a lista de mensagens que sero enviadas aps a sua execuo. Erro! Indicador no definido.

Figura 5.2 - Representao de uma atividade da ANBPL.

Os identificadores de atividades, representados por elementos do tipo IdActivity, existentes na sintaxe da ANBPL, encontram-se associados a elementos do tipo action, entidades semnticas da notao de aes, que representam unidades de processamento e no contexto da ANBPL definem o comportamento de uma atividade quando processada. A associao entre identificador de atividade (IdActivity) e uma action,

68 representado pela ilustrao presente na Figura 5.3. Tal associao considerada como j provida pelo ambiente de execuo do processo, uma vez que no o objetivo desta linguagem a especificao do significado do processamento das atividades de um processo de negcio. Ambiente de Execuo do Processo de Negcio IdActivity
Action

...
IdActivity
Action

Figura 5.3 Ambiente de Execuo com IdActivity e Action. Para expressar a semntica da linguagem, deve-se realizar o mapeamento da sintaxe da linguagem para entidades existentes na faceta comunicativa da notao de aes. Porm, a realizao de tal mapeamento de forma direta mostrou-se complexo devido forma com que os elementos da faceta comunicativa devem ser manipulados. Com o objetivo de facilitar esta traduo, foram criadas algumas entidades semnticas intermedirias, com o objetivo de servir como uma ponte entre a sintaxe da linguagem e a faceta comunicativa da notao de aes. A ilustrao apresentada pela Figura 5.4 mostra o fluxo natural do mapeamento da sintaxe da linguagem para a faceta comunicativa da notao de aes. Sintaxe ANBPL

Entidades Semnticas Intermedirias

Entidades Semnticas Faceta Comunicativa

69 Figura 5.4 Converso da Sintaxe nas Entidades Semnticas. As entidades semnticas intermedirias so definidas de acordo com a notao de dados utilizada por Semntica de Aes e na prpria notao de aes. Entidades semnticas como listas, tuplas e action so as mais utilizadas na especificao das entidades intermedirias. Nas prximas subsees tais entidades sero apresentadas em grupos, juntamente com as operaes que agem sobre elas. 5.2.1 Unidades de execuo do processo 5.2.1.1

Tipos

executionUnit = (list of action, list of action) empty-executionUnit = (empty-list, empty-list) token = string. pollAgent = map [token to executionUnit]

A entidade executionUnit define as pr-condies (mensagens que precisam ser recebidas) para execuo de uma action e o que ser realizado aps sua execuo (mensagens que sero enviadas). Tal action representa o processamento de uma atividade pertencente a um processo de negcio. Cada action desse tipo identificada no ambiente de execuo do processo por cada um dos tokens, que so chaves na entidade pollAgent. Enquanto que no contexto interno do pollAgent cada token representa a chave de uma executionUnit. Alm de servir de identificador para duas entidades distintas, dependendo do contexto no qual so referenciados, os tokens quando concatenados no final da string agent-, serve como identificador de um
agent

no contexto de execuo do processo de negcio. Durante a traduo da sintaxe dever ser traduzido para elementos do tipo token, presentes na definio

da ANBPL para as entidades semnticas intermedirias, o elemento de sintaxe

IdActivity

do pollAgent. Dessa forma, no modelo de memria de um processo de negcio na ANBPL, ilustrado pela Figura 5.5, cada IdActivity representa: uma associao a uma action, que representa o processamento de uma atividade no contexto do processo de negcio; uma associao a uma executionUnit no contexto do pollAgent;

70 uma associao entre o identificador gerado pela concatenao da string

agent-

ao IdActivity com um agent.

Ambiente de Execuo do Processo de Negcio idActivity Action

Agent- idActivity

Agent

pollAgent
idActivity MAP executionUnit
Receives Senders

Figura 5.5 Modelo de associaes realizadas por idActivity no ambiente de execuo da ANBPL A executionUnit, como pode ser observada em sua definio, composta por duas listas de entidades do tipo action. A primeira lista formada por actions, onde cada uma representa grupos de mensagens que precisam ser recebidas para que o processamento da action, que representa uma atividade, ocorra. A segunda lista possui as mensagens que sero enviadas aps cada execuo dessa action. A entidade emptyexecutionUnit

representa uma unidade de execuo, cujas duas listas se encontram

vazias. A entidade token, definida pela entidade string, corresponde a uma seqncia de caracteres juntamente com dgitos, utilizada na definio da entidade pollAgent, para representar chaves de unidades de execuo. Cada token corresponde a um identificador de atividade, porm, no contexto de execuo do processo, ligam-se a
actions,

que representam o comportamento de atividades, e no contexto do pollAgent

ligam-se a executionUnit.

71 5.2.1.2 Operadores

A seguir, so apresentadas as entidades semnticas que representam operadores, que operam sobre as entidades semnticas definidas na seo anterior. Essas entidades so definidas por diversos operadores e a especificao do seu comportamento realizada pelas equaes apresentadas em seguida.

72
getAnToken _ _ removeTheTokenMap_ addSenders( _ , _ ) addReceivers( _ , _ ) transToExecAction(_ , _) tansPartSend(_ , _ ) transPartRec(_ , _) separateByAnds _ :: :: :: :: :: :: :: :: poolAgent -> token pollAgent, token -> pollAgent action, executionUnit -> executionUnit action, executionUnit -> executionUnit token, executionUnit -> action token, executionUnit -> action executionUnit, action -> action list ot action -> action

(1) getAnToken pa: poolAgent = first elements mapped-set pa. (2) pa: pollAgent removeTheTokenMap t: token = pa omitting set of t. (3) addSenders (send, (receivers: list of action, senders: list of action)) = (receivers, concatenation (senders, list of (send))). (4) addReceivers(recs: action, (receivers: list of action, senders: list of action) ) = (concatenation (receivers, list of (recs)), senders). (5) transToExecAction (t: token , e: executionUnit)= transPartRec (e, tansPartSend (t, e)). (6) tansPartSend (t:token, ( recs: list of action , sends: list of action)) = the action bound to t and then separateByAnds sends. (7) transPartRec( (empty-list, sends:list of action), execThenSend: action) = commit. (8) transPartRec((recs: list of action, sends: list of action), execThenSend: action) = head recs and then execThenSend and transPartRec ((tail recs, sends) , execThenSend). (9) separateByAnds empty-list = complete. (10)separateByAnds(acts: list ot action) = head acts and separateByAnds(tail acts).

A operao getAnToken_ definida pela equao (1) tem o papel de retornar qualquer
token

da entidade pollAgent e, para atingir esse objetivo, primeiramente, o que representado por um map, transformado em um set atravs da que recebe como parmetro um set e o transforma em uma tupla, para

pollAgent,

aplicao da operao mapped-set_ para, em seguida, ser executada a operao

elements_

ento o primeiro elemento da tupla ser retornado com a aplicao do operador de tuplas first_. Os tipos set, tupla, as operaes mapped-set_, elements_ e
first_,

so exemplos de entidades que fazem parte de notao de dados presente no

framework de semntica de aes. A operao binria _removeTheTokenMap_ toma como argumento esquerda um
pollAgent,

mapeamento de token para executionUnit, e direita um token,

73 realizando a remoo do mapeamento existente no pollAgent que tem o token, parmetro a direita, como chave. A equao (2) define como a remoo realizada, onde, primeiramente, o token transformado em um set via a aplicao da operao
set of_.

Aps a criao do set contendo um elemento, o token, esse set passado esquerda. O operador _omitting_ realiza a excluso de mapeamentos

como parmetro, direita, para o operador binrio _omitting_, juntamente com o

pollAgent,

existente no map, esquerda do operador, onde a chave dos mapeamentos que devem ser excludos aparecem no set passado direita do operador. Como o set passado contm apenas um elemento, o token, ento o operador _removeTheTokenMap_ garantir a remoo do pollAgent, apenas o mapeamento que tem como chave o
token

passado como parmetro direita deste operador.

As operaes addSenders(_,_) e addReceivers(_,_) que tomam como argumento uma action e uma executionUnit, transformam a executionUnit acrescentando uma action na lista de actions que representam o envio de mensagens e na lista de
actions

que representam o recebimento de mensagens, respectivamente. Como pode

ser observado nas equaes (3) e (4) a action que passada como parmetro para qualquer uma das duas operaes primeiramente transformada em uma lista contendo um nico elemento para, depois, ser invocada a operao de concatenao de listas
_concat_.

A operao transToExecAction_, definida pela equao (5), corresponde a um dos principais operadores apresentados aqui, uma vez que ele transforma uma
executionUnit

em uma action, que define o comportamento da executionUnit

como uma unidade de execuo que para ter sua execuo ativada precisa receber determinadas mensagens e depois de completada sua execuo mensagens so enviadas a outras
executionUnit.

Para

representar operaes

esta

situao

a sendo

operao essas:

transToExecAction_

utiliza

outras

auxiliares,

transPartSend(_,_), transPartRec(_,_)

e separateByAnds_, definidas pelas

equaes (6), (7), (8), (9) e (10). A operao transPartSend(_,_),que opera sobre um token e uma executionUnit, gera uma action que corresponde a action referenciada pelo token e em seguida actions separadas pelo operador and, que representam envio de mensagens em paralelo,

74 por isso a utilizao do operador separateByAnds_ na definio do operador

transPartSend(_,_).

O operador tansPartRec(_,_) define que a execuo de cada action da lista de

receivers

uma precondio independente para que a action, segundo parmetro do

operador, seja executada. Cada action da lista de receivers do pollAgent, define o recebimento de uma ou mais mensagens. Esse operador amarra a execuo da action, ao acontecimento de eventos de recebimento de mensagens. Para que o recebimento dessas mensagens ocorram outras executionUnit tiveram que ser executadas para em seguida enviaram mensagens, garantindo o sincronismo de execuo do processo. 5.2.2 Tipos de Conexes Esta seo descreve as entidades semnticas responsveis por representar os trs tipos de conexes entre unidades de execuo, onde cada entidade consiste num tipo particular da connection. Tambm so apresentadas as operaes que manipulam um
pollAgent,

atualizando as executionUnit contidas nele, a partir do momento em que

entidades do tipo connection so adicionadas ao pollAgent. 5.2.2.1

Tipos
connection(token, token ) | connection(token, token) when(string) | connection(list of token, token)

connection =

connections = conection*

A entidade connection representada por trs diferentes tipos. Porm, antes de entrar nos detalhes sobre cada tipo, preciso deixar claro que cada token existente na definio dos tipos de connection representam identificadores para entidades que, dependentemente do contexto em que so referenciados, possuem um significado diferente. A conexo connection(token,token) identifica o tipo de conexo incondicional entre unidades de execuo, onde os dois elementos do tipo token, presentes neste tipo de conexo, correspondem a identificadores de atividades. Neste contexto, a atividade identificada pelo segundo token s ser executada aps o trmino de execuo da atividade identificada pelo primeiro token, incondicionalmente.

75 A conexo
connection(token,token)when(string)

indica

uma

conexo

condicional, onde a string, existente na parte when(string) representa o valor a ser comparado com o valor produzido, na primeira posio da tupla de dados, pela atividade identificada pelo primeiro token da connection e, apenas quando os valores comparados forem iguais, a atividade, identificada pelo segundo token desta
connection

ser executada. A entidade connection(list of token, token) indica

que a atividade representada pelo segundo parmetro ser executada apenas quando todas as atividades identificadas pela lista de tokens terminarem sua execuo. Finalmente, a entidade connections aparece representando uma tupla de elementos do tipo connection. 5.2.2.2 Operaes

_append_ :: pollAgent , connections -> pollAgent _connect_ :: pollAgent , connection -> pollAgent createReceivers_ :: (list of token) -> action _updateSenders_ :: PollAgent, (list of token, token) (1) pa: pollAgent append cs: connections = if not (cs is ( )) then (pa connect first cs) append rest cs else pa. (2) pa: pollAgent connect connection (s: token, r: token ):connection= if (pa at s is nothing) then pa [s to addSenders(empty-executionUnit, send a message [to the agent bound to agent- ^ r])] else pa [s to addSenders(pa at s, send a message [to the agent bound to agent-^r])] if (pa at r is nothing) then pa [r to addReceivers(empty-executionUnit, receive a message [from the agent bound to agent-^s])] else pa [r to addReceivers(pa at r, receive a message [from the agent bound to agent-^s])].

76
(3) pa: pollAgent connect connection (s:token, r:token)when(c:string): connection = if (pa at s is nothing) then pa [s to addSenders(empty-executionUnit, check string#1 is c and then send a message [to the agent bound to agent-^r] or check not string#1 is c and then complete ) ] else pa [s to addSenders(pa at s, check string#1 is c and then send a message [to the agent bound to agent-^r] or check not string#1 is c and then complete ) ] if(pa at r is nothing) then pa [r to addReceivers( empty-executionUnit, receive a message [from the agent bound to agent-^s]) ] else pa [r to addReceivers( pa at r, receive a message [from the agent bound to agent-^s]) ]. (4) pa: pollAgent connect connection(senders: list of token, r: token): connection = pa updateSenders (senders, r) if (pa at r is nothing) then pa[r to addReceivers(empty-executionUnit, createReceivers (senders)] else pa [r to addReceivers(pa at r, createReceivers (senders)]. (5) createReceivers (senders: list of token) = if (senders is empty-lsit) then complete else receive a message [ from the agent bound to agent-^(head senders)] and createReceiver(tail senders).

77
(6) pa: PollAgent updateSenders (senders: list of token, r: token) if (senders is empt-list) then pa else if (pa at head senders is nothing) then pa[head senders to addSenders( empty-executionUnit, send a message [to the agent bound to agent-^r])] else pa[head senders to addSenders( pa at head senders, send a message [to the agent bound to agent-^r])] pa updateSenders (tail senders, r).

A primeira operao apresentada, _append_, recebe como parmetros um pollAgent e um connections, tupla de entidades do tipo connection. Esta operao tem o papel de atualizar ou incluir, caso no exista, executionUnit no pollAgent de acordo com os identificadores de executionUnit presentes em cada item de connections, passado como segundo parmetro. Como pode ser observada na equao (1), a definio da operao _append_ feita de forma recursiva, utilizando a operao _connect_ para cada um dos itens da connections. A operao _connect_ tem o papel de atualizar o pollAgent, primeiro parmetro da operao, de acordo com o connection passado como segundo parmetro. Como existem trs diferentes tipos de connection, sua definio baseada em trs equaes: (2), (3) e (4), responsveis respectivamente, por definir o que deve ser alterado no
pollAgent

quando os tipos de connection forem connection(s:token,r:token),

r:token)when(string)

connection(s:token, token, r:token).

e connection(senders:list of

Quando

tipo

de

connection

utilizado

pelo

operador

_connect_

for

connection(s:token, r:token) executionUnit

o pollAgent ser atualizado de forma que as

identificadas por s e r, no contexto do pollAgent, caso existam, sejam

atualizadas e caso contrrio, sejam criadas e associadas ao respectivo token e includas no pollAgent. De forma que a executionUnit, identificada pelo token s, tenha sua lista de action, que representa as mensagens a serem enviadas, atualizada com a incluso de um action que define o envio de uma mensagem para o agent responsvel por executar a executionUnit identificada pelo r. Enquanto que a executionUnit, identificado pelo token r, deve ter sua lista de action, que representa as mensagens que

78 precisam ser recebidas, atualizada com a incluso de uma action que representa o recebimento de uma mensagem do agent que executa a executionUnit identificada pelo token s. Como o objetivo de cada executionUnit, presente no pollAgent, de representar o comportamento de uma atividade em um processo de negcio, ento uma
connection

desse tipo representa a situao em que uma atividade ficar em estado de

espera para ser executada at que a outra termine sua execuo e a partir do momento que uma conexo deste tipo atualizada no pollAgent via a operao _connect_, isto faz com que o processo de negcio seja atualizado com um requisito a respeito da ordem de execuo dessas atividades. A operao
_connect_,

quando

aplicada

uma

connection

do

tipo

connection(s:token,

r:token)when(string),

definida na equao (3), bem

semelhante definida pela equao (2), com a diferena peculiar que a action a ser includa na lista de action, que representa os envios de mensagens, possua um teste para verificar se deve ou no enviar tal mensagem. Esse teste realizado pela verificao de igualdade do parmetro passado na clausula when() com o valor existente na primeira posio de uma tupla de dados gerada aps a execuo da action identificada por s, no ambiente de execuo do processo. Para o tipo connection(senders:list
_connect_, of token, r:token),

o operador

definido pela equao (4), primeiramente atualiza todas as executionUnit,

identificadas por senders. Nessa atualizao, para cada executionUnit, adicionando um action na lista de actions de envio de mensagens. Essa tarefa realizada com a utilizao da operao auxiliar _updateSenders(_,_), na equao (5). A action adicionada representa o envio de uma mensagem para o agent identificado por
agent-r.

Em seguida, o operador _connect_ altera a executionUnit identificado

pelo token r, adicionando em sua lista de actions de recebimento de mensagens uma action que representa a necessidade de recebimento de mensagens de cada um dos
agents

que encapsulam as executionUnit, definidas em senders. Para indicar a

necessidade de recebimento de todas as mensagens, as actions, que definem recebimento de mensagens, foram combinadas pelo combinador de aes and. Tal combinao realizada pela operao createReceivers(_), equao (6).

79 5.2.3 Manipulao dos Agentes Este tpico apresenta as operaes responsveis por criar e ativar os agents. Em um processo cada agent possui uma executionUnit associada, onde cada composio deste tipo representa uma atividade de um processo de negcio. A seguir sero apresentadas as operaes responsveis pela manipulao dos agents.
createAgents __:: pollAgent -> action initializateAgents __ :: pollAgent -> action activateAgents __:: pollAgent -> action (1) createAgents pa: pollAgent = check pa is empty-map and then complete or check not pa is empty-map and then give agent- ^ getAnToken pa and subordinate an agent and then bind the given token#1 to the given agent#2 and then createAgents pa removeTheTokenMap the given token#1 (2) initializateAgents pa: pollAgent = check pa is empty-map and then complete or check not pa is empty-map and then give getAnToken pa and then send a message [containing clousure of abstraction of transToExecAction (it, pa at it) to the agent bound to agent-^it] and initializateAgents pa removeTheTokenMap it

(3) activateAgents pa: pollAgent = bind endProcess to complete and then createAgents pa hence initializateAgents pa

A operao createAgents_, recebe um pollAgent como parmetro e para cada uma das chaves dos mapeamento existentes no pollAgent, um agent criado. Depois de criado, cada agent ligado a um identificador, cuja regra de formao consiste na concatencao da string agent- com uma chave do mapeamento do pollAgent. A concatenao realizada na formao do identificador do agent necessaria devido s chaves pertencentes ao pollAgent j serem utilizadas como identificador para actions no ambiente de execuo do processo. Portanto no podem ser tambm utilizadas como identificador dos agents.

80 A operao initializateAgents_ tem o papel de ativar a execuo dos agents. Para isso, tal operao age sobre cada um dos agents existentes, encapsulando em uma
abstraction

a action gerada pela aplicao da operao transToExecAction(_,_),

e em seguida enviando essa abstraction para o agent. O fato de um agent receber uma mensagem contendo uma abstrao faz com que esse agent seja ativado e a
action

encapsulada na abstraction, recebida no interior da mensagem, seja

executada. Com o papel de juntar as funes de criao e inicializao dos agents, definida a operao activateAgents_, a qual, alm de realizar as funes mencionadas sobre os
agents

ela cria uma associao do identificador de atividade endProcess a action representando o trmino da execuo de um processo de negcio. Tornando um identificador chave que representa o trmino de um processo.

complete,

endProcess

5.3

Definio da Semntica

Aps definida a sintaxe da linguagem, a qual especificada pela gramtica apresentada na Seo 5.1, necessrio dar significado s possveis construes existentes nesta gramtica. Como o ponto de partida para a escrita de um processo de negcio nesta linguagem consiste na utilizao da regra de formao especificada pelo smbolo no terminal Process, da qual faz parte outro smbolo no terminal, denominado de
Connections,

representado por uma tupla de elementos do tipo Connection,

necessrio dar o significado semntico desses elementos. As funes semnticas, como so utilizadas na especificao de linguagem utilizando o framework de Semntica de Aes, possuem o papel de realizar o mapeamento da sintaxe da linguagem em entidades semnticas da notao de aes, que definam o seu comportamento. Tal mapeamento pode ser realizado diretamente para a notao de aes. Porm, na definio desta linguagem foram criadas outras entidades, apresentadas na Seo 5.2, que devem servir como uma notao intermediria para as entidades semnticas requeridas, facilitando a realizao deste mapeamento. Em seguida, so apresentadas as funes semnticas adotadas para expressar a semntica da linguagem, juntamente com as equaes que as definem.

81
run_:: Process -> action (1) run [Process p is cs] = activateAgents(empty-map append createAllConnections cs). createAllConnections_::Connections -> action (1) createAllConnections cs: Connections = check cs is ( ) and then complete or check not cs is ( ) and then (createConnections first cs, createAllConnections rest cs). createConnections_ :: Connection -> connection* (1) createConnections [id1: IdActivity seq id2: IdActivity] = connection (id1, id2). (2) createConnections [id1: IdActivity seq-if (cond: string, id2: IdActivity):ConditionalActivity] = connection (id1, id2) when (cond). (3) createConnections [id1:IdActivity fork ids:IdsActivities] = if (ids is ()) then () else (connection(id1, first ids), createConnections(id1 fork rest ids)). (4) createConnections [ids: IdsActivities join id2: IdActivity] = connection(list of ids, id2) (5)createConnections[id1:IdActivity choice acs: ConditionalActivities] = if (acs is ( )) then () else (createConnections (id1 seq-if firs acs), createConnections (id1 choice rest acs)).

A primeira funo semntica apresentada, funo semntica run(), recebe como parmetro um Process, que representa um processo de negcio, e define como realizado o mapeamento desse elemento da sintaxe da linguagem para a notao de aes, utilizando as entidades semnticas, definidas na Seo 5.2. Na realizao deste mapeamento utiliza a operao activateAgents(), a qual mapeia um pollAgent em uma action. O pollAgent, passado para a operao activateAgents_, produzido via a utilizao da operao append_ aplicada a um empty-map e uma tupla de
Connection.

O empty-map, passado como parmetro, esquerda do append_,

representa um pollAgent vazio, enquanto o parmetro direita do append_ gerado atravs da funo semntica createAllConnections( ) quando aplicada a uma
Connections.

A funo semntica createAllConnections( ) opera de forma recursiva, chamando a funo semntica createConnections( ) sobre cada um dos elementos da tupla de

82
Connection

recebida como parmetro. A funo semntica createConnections( ) mapeando a Connection em uma tupla de uma ou mais entidades

especificada por cinco equaes, onde cada equao trata um tipo particular de
Connection,

semnticas do tipo connection.

5.4

Processos de Negcios na ANBPL

Com o objetivo de esclarecer a utilizao e funcionamento da ANBPL, nas duas prximas subsees sero mostrados dois processos de negcios. Onde cada processo primeiramente modelado em BPMN, para, em seguida, ter sua codificao demonstrada utilizando a ANBPL. Posteriormente apresentado como seria o processo na notao de aes, aps o cdigo escrito em ANBPL sofrer todas as transformaes, de acordo com a especificao da linguagem. Como a ANBPL foi idealizada tomando como base a notao de modelagem de processos BPMN, os processos exemplificados so apresentados nesta notao para, em seqncia, serem apresentados em ANBPL. Na Figura 5.6, pode-se observar as etapas de transformaes que ocorrem na traduo do modelo de um processo na BPMN para entidades semnticas. Tal traduo comea com sua representao em diagrama BPMN. Em seguida o processo traduzido em cdigo escrito em ANBPL, aps a transformao T1, para, posteriormente, ser demonstrado o equivalente na notao de aes, aps a transformao T2.

PROCESSO MODELADO NA BPMN T1

PROCESSO NA ANBPL

PROCESSO NA NOTAO DE AES T2

Figura 5.6 Traduo de um processo da BPMN para a notao de aes.

83 A seguir so descritos os passos que devem ser realizados em cada uma das etapas de traduo. T1: Traduo de um processo de negcio modelado na BPMN para cdigo fonte em ANBPL: o para cada atividade existente no processo, criar um IdActivity que a represente; o caso uma atividade aparea conectada a um evento de final de processo, este deve ser considerado como uma atividade e o IdActivity utilizado para represent-lo deve se chamar: endProcess; o com base na Tabela 5.1, traduzir os componentes grficos, existentes no processo modelado em BPMN, para elementos do tipo Connection, existentes na sintaxe ANBPL; o escrever o processo de acordo com a sintaxe do elemento Process
(Process String is Connections),

onde no elemento String um

nome deve ser dado ao processo e aps o smbolo terminal is deve ser colocado uma tupla de Connection, contendo todas as Connection criadas pelo passo anterior. T2: Passos para traduzir um processo codificado em ANBPL para a Notao de Aes: o aplica-se a funo semntica run_, apresentada na seo 5.3, sobre o processo descrito em ANBPL, que com o auxlio das demais funes e entidades semnticas definidas, realizar a traduo do processo em ANBPL para a notao de aes. Nas prximas sub-seoes sero apresentados dois processos de negcio modelados em BPMN, juntamente com a demonstrao das etapas de transformao destes processos desde sua definio em BPMN para o equivalente na notao de aes, passando pela sua representacao em ANBPL. As etapas de transformao correspondem exatamente s etapas T1 e T2 descritas acima.

84

5.4.1 Pintura de Peas O processo de pintura de peas, j apresentado na Seo 2.2.3, utilizando a tcnica de modelagem de processos IDEF3, agora ser descrito utilizando BPMN. Como pode ser observado abaixo, este pequeno processo composto por trs atividades: Pintar Pea; Secar Pea e; Testar Pintura. O processo inicia com um evento inicial, ativando a atividade Pintar Pea, que seguida pelas atividades Secar Pea e Testar Pintura. Aps a atividade Testar Pintura realizado um teste para averiguar a qualidade da pintura, caso esta seja aprovada, o processo finaliza com a chegada do fluxo de execuo do processo em um evento final, caso contrrio, o fluxo de execuo do processo redirecionado para a atividade Pintar Pea. Processo na BPMN
no ok

Pintar Peca

Secar Peca

Testar Pintura

ok

Figura 5.7 Processo Pintura de Peas Descrito na BPMN.

T1

Processo na ANBPL
Process pinturaPecas is ((pintarPeca seq secarPeca), (secarPeca seq testarPintura), (testarPintura choice ((ok, endProcess), (naoOk, pintarPeca))))

T2

85 Processo na Notao de Aes

bind endProcess to complete and then give agent-pintarPeca and subordinate an agent and then bind the given token#1 to the given agent#2 and then give agent-secarPeca and subordinate an agent and then bind the given token#1 to the given agent#2 and then give agent-testarPintura and subordinate an agent and then bind the given token#1 to the given agent#2 and then give agent-endProcess and subordinate an agent and then bind the given token#1 to the given agent#2 and then complete hence send a message [containing clousure of abstraction of the action bound to pintarPeca and then send a message [to the agent bound to agent-secarPeca] ] [to the agent bound to agent-pintarPeca] and send a message [containing clousure of abstraction of receive a message [from the agent bound to agent-pintarPeca] and then the action bound to secarPeca and then send a message[to the agent bound to agent-testarPintura]] [to the agent bound to agent-secarPeca] and send a message [containing clousure of abstraction of receive a message [from the agent bound to agent-secarPeca] and then the action bound to testarPintura and then check string#1 is ok and then send a message to the agent bound to agent-endProcess or check not string#1 is ok and then complete and check string#1 is naoOk and then send a message to the agent bound to agent-pintarPeca or check not string#1 is naoOk and then complete ] [to the agent bound to agent-testarPintura] and send a message[containing clousure of abstraction of receive a message [from the agent bound to agent-testarPintura] and then the action bound to endProcess ] [to the agent bound to agent-endProcess].

De acordo com os passos que ditam como deve acontecer as etapas de traduo T1 e T2, o processo de pintura de peas sofreu todas as transformaes necessrias para chegar ao estgio de representao na notao de aes, mostrado acima. Na etapa T1

86 as trs atividades e o evento de final de processo, presentes no diagrama que representa o processo em BPMN geraram os identificadores de atividades: pintaPeca,
secarPeca, testarPintura e endProcess.

Aps observar as conexes entre atividades no modelo deste processo em BPMN, Figura 5.7, foi identificada a existncia de trs conexes entre atividades, sendo representados por trs elementos do tipo Connection. Onde duas utilizam o operador
seq,

indicando processamento seqencial das atividades e a outra utiliza o operador representando dois caminhos condicionais e excludentes de fluxo de

choice,

processamento. Na definio da ltima Connection foi considerado que a atividade TestarPintura tem como resultado de sua execuo um valor que pode ser ok ou naoOk, dependendo respectivamente da avaliao positiva ou negativa do teste da qualidade da pintura realizada. Dependendo dessa avaliao, dever ser enviada mensagem para o agent, identificado por agent-pintarPeca ou o para o agent, identificado por agent-endProcess. A transformao T2 ocorre apenas com a aplicao da funo semntica run( ) sobre o cdigo fonte do processo descrito em ANBPL, gerado aps a transformao T1. De acordo com o resultado observado, para cada idActivity existente na definio do processo definido um identificador de agent atravs da concatenao de agent- ao
idActivity.

Em seguida, vrias mensagens so criadas e enviadas a cada agent. As mensagens possuem em seu contedo uma abstraction, encapsulando a action que define o processamento de uma atividade. Cada action deste tipo composta por trs partes: 1. recebimento de mensagens de outros agents ; 2. a action associada ao identificador de atividade; 3. envio de mensagens para outros agents; A primeira e a terceira parte podem no ocorrer. A primeira omitida no caso que a atividade a primeira a ser executada em um processo, portanto no dependendo do recebimento de mensagens de outro agent, para que sua execuo ocorra. A terceira parte fica de fora no caso da abstraction que enviada ao agent identificado por
agent-endProcess,

que define o trmino de um processo, portanto no necessitando

enviar mensagem para que qualquer outro agent dentro do processo seja ativado.

87 O processo apresentado na seguinte seo de uma magnitude maior que o de pintura. Porm todas as etapas de traduo apresentadas no processo de pintura so seguidas no processo de confirmao de viagem. 5.4.2 Confirmao de Viagem Este processo, descrito em BPMN pela Figura 5.8, responsvel por descrever as atividades inerentes a um processo de confirmao de viagens, realizadas por uma agncia de turismo. Seu papel garantir que todas as solicitaes de reservas necessrias a uma viagem sejam realizadas, alm de confirmar que tais reservas foram processadas com sucesso, para que a viagem possa ser confirmada. O processo composto por doze atividades, comeando com a atividade Acessa Informaes Viagem, onde as informaes pertinentes viagem, a ser realizada, so levantada. Aps o processamento desta atividade, as trs atividades seguintes podem ser realizadas em paralelo: Solicita Reserva Carro; Solicita Reserva Hotel e; Solicita Reserva Vo. Para cada atividade de solicitao existe uma atividade de verificao da reserva, sendo essas: Verifica Reserva Carro; Verifica Reserva Hotel e; Verifica Reserva Vo. As atividades de verificao das solicitaes das reservas podem seguir dois fluxos possveis. Caso a verificao de reserva seja confirmada, uma atividade de confirmao daquela reserva processada, caso contrrio, a solicitao da reserva realizada novamente. Apenas aps a confirmao de todas as reservas (carro, hotel e vo), a viagem ser confirmada, servio que realizado pela atividade Confirma Viagem, finalizando o processo em seqncia.

88 Processo na BPMN no ok
Solicita Reserva Carro Verifica Reserva Carro

ok no ok

Confirma Reserva Carro

Solicita Reserva Hotel

Verifica Reserva Hotel

ok no ok

Confirma Reserva Hotel

Solicita Reserva Vo Acessa Informaes Viagem

Verifica Reserva Vo

ok

Confirma Reserva Vo Confirma Viagem

Figura 5.8 Processo de Confirmao de Viagem na BPMN.

T1

Processo na ANBPL
Process confirmacaoViagens is ((acessaInfViag fork (solResCarro, solResHotel, solResVoo)), (solResCarro seq verifResCarro), (verifResCarro choice ((ok, confResCarro), (naoOk, solResCarro)), (solResHotel seq verifResHotel), (verifResHotel choice ((ok, confResHotel), (naoOk, solResHotel)), (solResVoo seq verifResVoo), (verifResVoo choice ((ok, confResVoo), (naoOk, solResVoo)), ((confResCarro, confResHotel, confResVoo) join confViagem), (confViagem seq endProcess) )

T2

89 Processo na Notao de Aes

bind endProcess to complete and then give agent- acessaInfViag and subordinate an agente and then bind the given token#1 to then given agent#2 and then give agent-solResCarro and subordinate an agente and then bind the given token#1 to then given agent#2 and then give agent-verifResCarro and subordinate an agente and then bind the given token#1 to then given agent#2 and then give agent-confResCarro and subordinate an agente and then bind the given token#1 to then given agent#2 and then give agent-solResHotel and subordinate an agente and then bind the given token#1 to then given agent#2 and then give agent-verifResHotel and subordinate an agente and then bind the given token#1 to then given agent#2 and then give agent-confResHotel and subordinate an agente and then bind the given token#1 to then given agent#2 and then give agent-solResVoo and subordinate an agente and then bind the given token#1 to then given agent#2 and then give agent-verifResVoo and subordinate an agente and then bind the given token#1 to then given agent#2 and then give agent-confResVoo and subordinate an agente and then bind the given token#1 to then given agent#2 and then give agent-confViagem and subordinate an agente and then bind the given token#1 to then given agent#2 and then give agent-endProcess and subordinate an agente and then bind the given token#1 to then given agent#2 and then hence send a message [containing clousure of abstraction of the action boundo to acessaInfViag and then send a message [to the agent bound to agent-solResCarro] and send a message [to the agent bound to agent-solResHotel] and send a message [to the agent bound to agent-solResVoo] ] [to the agent bound to agent-acessaInfViag] and send a message[containing clousure of abstraction of receive a message [from the agent bound to agent-acessaInfViag] and then the action boundo to solResCarro and then send a message [to the agent bound to agent-verifResCarro] and receive a message [from the agent bound to agent-verifResCarro] and then the action boundo to solResCarro and then send a message [to the agent bound to agent-verifResCarro] ] [to the agent bound to agent-solResCarro] and

90
send a message[containing clousure of abstraction of receive a message [from the agent bound to agent-acessaInfViag] and then the action boundo to solResHotel and then send a message [to the agent bound to agent-verifResHotel] and receive a message [from the agent bound to agent-verifResHotel] and then the action boundo to solResHotel and then send a message [to the agent bound to agent-verifResHotel] [to the agent bound to agent-solResHotel] and send a message[containing clousure of abstraction of receive a message [from the agent bound to agent-acessaInfViag] and then the action boundo to solResVoo and then send a message [to the agent bound to agent-verifResVoo] and receive a message [from the agent bound to agent-verifResVoo] and then the action boundo to solResVoo and then send a message [to the agent bound to agent-verifResVoo] ] [to the agent bound to agent-solResVoo] and send a message[containing clousure of abstraction of receive a message [from the agent bound to agent-solResCarro] and then the action boundo to verifResCarro and then check string#1 is ok and then send a message [to the agent bound to agent-confResCarro] or check not string#1 is ok and then complete and check string#1 is naoOk and then send a message [to the agent bound to agent-solResCarro] or check not string#1 is naoOk and then complete ] [to the agent bound to agent-verifResCarro] and

91
send a message[containing clousure of abstraction of receive a message [from the agent bound to agent-solResHotel] and then the action boundo to verifResHotel and then check string#1 is ok and then send a message [to the agent bound to agent-confResHotel] or check not string#1 is ok and then complete and check string#1 is naoOk and then send a message [to the agent bound to agent-solResHotel] or check not string#1 is naoOk and then complete ] [to the agent bound to agent-verifResHotel] and send a message[containing clousure of abstraction of receive a message [from the agent bound to agent-solResVoo] and then the action boundo to verifResVoo and then check string#1 is ok and then send a message [to the agent bound to agent-confResVoo] or check not string#1 is ok and then complete and check string#1 is naoOk and then send a message [to the agent bound to agent-solResVoo] or check not string#1 is naoOk and then complete ] [to the agent bound to agent-verifResVoo] and send a message[containing clousure of abstraction of receive a message[from the agent bound to agent-verifResCarro] and then the action boundo to confResCarro and then send a message [to the agent bound to agent-confResViagem] ] [to the agent bound to agent-confResCarro] and send a message[containing clousure of abstraction of receive a message[from the agent bound to agent-verifResHotel] and then the action boundo to confResHotel and then send a message [to the agent bound to agent-confResViagem] ] [to the agent bound to agent-confResHotel] and send a message[containing clousure of abstraction of receive a message[from the agent bound to agent-verifResVoo] and then the action boundo to confResVoo and then send a message [to the agent bound to agent-confResViagem] ] [to the agent bound to agent-confResVoo] and

92

send a message[containing clousure of abstraction of receive a message [from the agent bound to agent-confResCarro] and receive a message [from the agent bound to agent-confResHotel] and receive a message [from the agent bound to agent-confResVoo] and then the action boundo to confResViagem and then send a message [to the agent bound to agent-endProcess] ] [to the agent bound to agent-confResViagem] and send a message[containing clousure of abstraction of receive a message [from the agent bound to agent-confViagem] and then the action boundo to endProcess ] [to the agent bound to agent-endProcess]

Como resultado da traduo T1, o processo de negcio descrito em BPMN convertido de acordo com a sintaxe de ANBPL. Nessa nova representao o processo escrito com um total de nove elementos do tipo Connection. Cada conexo entre atividades representada por um elemento do tipo Connection. A tupla composta por todos esses elementos Connection utilizada para representar o processo de negcio em ANBPL. A Figura 5.9, corresponde Figura 5.8 transformada com o destaque dos pontos de conexo entre atividades. Na fase de traduo T1, para cada ponto de conexo destacado, um elemento do tipo Connection definido. O processo de negcio, de acordo com a notao da ANBPL, definido pela tupla de todas as Connection criadas. Em seguida ser mostrada a equivalncia entre cada um dos pontos de conexo de atividades e o elemento Connection criado para o representar.

93

no ok
Solicita Reserva Carro

Verifica Reserva Carro

3 no ok

ok

Confirma Reserva Carro

Solicita Reserva Hotel

Verifica Reserva Hotel

5 no ok

ok

Confirma Reserva Hotel

Solicita Reserva Vo Acessa Informaes Viagem

Verifica Reserva Vo

ok

Confirma Reserva Vo Confirma Viagem

Figura 5.9 Processo de Confirmao de Viagem na BPMN. Com Destaque Nos Pontos de Conexo Entre as Atividades. A Conexo 1 interliga uma atividade a outras trs, garantindo o processamento independente e paralelo das atividades onde as setas apontam. Para representar essa situao foi criada a Connection: (acessaInfViag
solResHotel, solResVoo). fork (solResCarro,

As conexes 2, 4 e 6, so as mais simples, garantindo

apenas o processamento seqencial das atividades envolvidas. A conexo 2, por exemplo, representada por (solResCarro seq verifResCarro). As conexes 3, 5 e 7, definem um fluxo condicional, podendo direcionar para a atividade de confirmao da solicitao correspondente ou para uma nova tentativa de solicitao, dependendo se o valor gerado pela atividade de verificao for ok ou noOk, respectivamente. Para expressar esse comportamento utilizado a
Connection,

que utiliza o operador choice, como pode ser observado, por exemplo,
choice ((ok, confResCarro), (naoOk,

em:

(verifResCarro

solResCarro)).

Para que a atividade confirma viajem seja realizada necessrio que as atividades de confirmao de reserva de hotel, de carro e de vo sejam finalizadas. Para expressar esse comportamento, a seguinte Connection foi adicionada a descrio do processo

94
((confResCarro, confResHotel, confResVoo) join confViagem).

Para indicar

que a atividade identificada por confViagem a ltima do processo, foi definido um conexo de seqncia, ligando a atividade confViagem a atividade identificada por endPeocess, representando o trmino do processo de negcio . Aps a transformao T1, tem-se o processo descrito em ANBPL. Aplicando a transformao T2, sobre essa representao, o processo traduzido para a notao de aes. Na notao de aes definido um agent para cada atividade do processo, e as regras que ditam o fluxo do processo so representas por actions, que definem mensagens que precisam ser recebidas para o processamento de uma atividade e mensagens que so enviadas aps seu processamento. Na notao de aes, o processamento de cada atividade realizado por um agent dedicado a esta atividade. O que deve ser executado por cada agent fica em uma
action,

encapsulada em uma abstraction, que apenas ser executada aps o envio

dessa abstraction para o agent em questo. A action, encapsulada na abstraction, construda conforme as Connection definidas na descrio do processo na ANBPL.

95

Captulo 6
6 Concluso e Trabalhos Futuros
Simplicidade e praticidade foram os principais conceitos em mente para o projeto da ANBPL. Considerar um processo de negcio como uma coleo de conexes entre atividades foi um fator primordial para que a representao de processos escrito nessa linguagem fosse o mais simples possvel. A escrita de um processo de negcio na ANBPL, a partir do modelo de um processo especificado em BPMN, torna-se fcil devido linguagem manter um relacionamento claro entre tipos de conexes de atividades e os operadores da linguagem. Tal relacionamento demonstrado na descrio da linguagem, que acompanhado de diretrizes que ditam como especificar processos em ANBPL a partir de um modelo de processo em BPMN, torna a tarefa da escrita de um processo na linguagem uma tarefa mecnica.

6.1

Trabalhos Relacionados

Essa linguagem foi pensada de forma completamente diferente das demais linguagens ou projetos de linguagens para execuo de processos de negcio, visto que, as definidas at ento, como: XPDL [42], BPML (Business Process Languagem) [2] e BPEL (Business Process Execution Language) [7][4], tm como foco a utilizao de XML para representao dos processos de negcio, diferentemente da ANBPL, que tem uma representao completamente textual e baseado em uma sintaxe, de forma semelhante a uma linguagem de programao. No projeto desta linguagem se buscou a todo o momento a definio de uma sintaxe, que possibilitasse a descrio de processos de forma textual, procurando reduzir o esforo ao se escrever um processo de negcio. O uso de Semntica de Aes na especificao de uma linguagem com este propsito contribuiu bastante para a consolidao do carter inovador empregado neste trabalho. Visto que, na literatura so

96 encontrados trabalhos referentes utilizao de Semntica de Aes para a especificao de linguagens de programao.

6.2

Contribuies

Com uma maneira para representar processos de negcio, bem diferenciada das linguagens para execuo de processos, propostas at ento, a ANBPL surge como uma alternativa diferenciada para, no futuro, ser utilizada como ferramenta para realizar a execuo de processos de negcio. O uso do framework de Semntica de Aes [27] na especificao da semntica da linguagem foi de extrema importncia, devido rica representatividade do processamento distribudo de tarefas, oferecido pela Faceta Comunicativa deste framework. A equivalncia entre as atividades de um processo de negcio e os agentes da Faceta Comunicativa, do ponto de vista de processamento de tarefas, que interagem, foi um ponto de inspirao de extrema importncia na definio da ANBPL. O projeto da ANBPL pode ser utilizado como fonte de estudo para interessados no aprendizado no framework de Semntica de Aes. Principalmente no que se refere a forte utilizao da faceta comunicativa da notao de aes. Uma vez que a utilizao prtica de tal faceta no to detalhada na literatura que trata o framework de Semntica de Aes.

6.3

Trabalhos Futuros

Na definio da ANBPL, os principais elementos da BPMN, que ditam o fluxo do processo de negcio, foram levados em considerao para a definio da sintaxe da linguagem. Porm, devido dimenso e a completude da BPMN, muitos elementos pertencentes notao de BPMN no foram contemplados nesta primeira verso da linguagem, ficando a sugesto para trabalhos futuros evoluo da ANBPL com a extenso da sintaxe para contemplar outros elementos grficos existentes na BPMN, tornando a linguagem cada vez mais rica e completa. Alm da extenso da sintaxe da ANBPL existe a possibilidade de definir a forma de representar o processamento particular das atividades de um processo, visto que, nesta primeira verso apenas as associaes entre as atividades e o controle do fluxo de

97 execuo do processo tratado. Definindo como ocorrer especificao do processamento das atividades de um processo ser possvel utilizao da linguagem em conjunto com ferramentas de modelagem de processos para a execuo de processos. Essa realizao contribui para que ferramentas de modelagem possam ter na ANBPL um mecanismo til para a execuo mecanizada de processos de negcio. Dado que os operadores presentes na ANBPL, que representam os tipos de conexes entre atividades, foram definidos a partir dos elementos do diagrama BPMN, o mapeamento automtico de modelos de processos de negcio, definidos na BPMN, para descrio do processo, na ANBPL, torna-se uma tarefa completamente vivel a ser realizada. Para que tal mapeamento seja realmente de utilidade, dando grandes contribuies a rea de modelagem e simulao de processos, seria desejvel a criao ou evoluo de uma ferramenta visual para modelagem de processos, baseada na BPMN. A partir desta ferramenta seria possvel criar o modelo de um processo utilizando BPMN e a transformao do modelo grfico para a descrio do processo em ANBPL ocorreria de forma automtica quando se desejasse executar o processo. Como definio da semntica da ANBPL realizada sobre o framework de Semntica de Aes, tal ferramenta poderia utilizar interpretadores e compiladores, j existentes e baseados na notao de aes, para a execuo de processos de negcio, como por exemplo o Abaco [28]. A descrio semntica da linguagem foi realizada de acordo com a notao utilizada pelo framework de Semntica de Aes, denominada de notao de aes. Porm, no foi utilizada nenhuma ferramenta para validao de tal descrio. Ficando como sugesto para trabalhos futuros a utilizao de uma ferramenta, como o Abaco, capaz de interpretar a notao de aes e validar a corretude da utilizao dessa notao na descrio da ANBPL.

98

REFERNCIAS
[1] AITKEN S., KINGSTON J., Representing Process Models in Cyc: An Application to Crisis Management. Edinburgh. University of Edinburgh. 1998. [2] ANDREWS T., et all. Business Process Execution Language for Web Services. version 1.1, 136 pp. 2003. [3] APRIL J., et al. Enhancing Business Process Management With Simulation Optimization. In: BPTRENDS, 2005. [4] ARKIN, A. Business Process Modeling Language. 2002. Disponvel em http://xml.coverpages.org/ni2002-06-26-b.html. Acesso em: 1 Maro 2004. [5] ARQUIN A., INTALIO, BPMI.org, Business Process Modeling Language, Disponvel em: http://www.bpmi.org/bpml-spec.htm. Acesso em: 15 nov. 2005. [6] BORN, G. The Way to Design, Document and Re-engineer Business Systems. In: Process Management to Quality Improvement. 1994. [7] BPMI.org, Business Process Manager Iniciative. Disponvel em:

http://www.bpmi.org. Acesso em: 12 nov. 2005. [8] BPMI.org, Business Process Modeling Notation (BPMN). v. 1.0, 2004. Disponvel em: http://www.bpmi.org. Acesso em: 12 nov. 2005. [9] Business Modeling with the UML and Rational Suite Analyst Studio. Rational Software White Paper. 2002. [10] CESARE, S.; LYCETT, M.; PATEL, D. Business Modeling with UML: distilling directions for future research, Enterprise information systems IV, Kluwer Academic Publishers, Hingham, MA, 2003. [11] DATTA, A. Automating the Discovery of AS-IS Business Process Models: Probabilistic and Algorithmic Approaches, Information Systems Research, vol. 9, no. 3, pp 275-301. 1998.

99

[12] DAVENPORT, T. H. Process Innovation: Reengineering Work Through Information Technology, Harvard Business School Press, 1993. [13] DEURSEN, A.V.; MOSSES, P. D. ASD: The action semantic description tools. In: Conf. on Algebraic Methodology and Software Technology, 1996, Munich, v. 1101, p. 579-582. [14] FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION. Integration Definition For Function Modeling (IDEF0), n. 183, 1993. Disponvel em http://www.idef.com/Downloads/pdf/idef0.pdf. Acesso em: 15 nov. 05. [15] HOMMES, B. J.; REIJSWOUD, V. V. Assessing the Quality of Business Process Modeling Techniques. In: 33rd Annual Hawaii International Conference, 2002. Hawaii, v.1, p. 1007. [16] IBM RATIONAL SOFTWARE. Disponvel em: http://www-306.ibm.com/

software/rational. Acesso em 14 fev. 2004. [17] Integrated Definition Methods. IDEF3 Process Flow and Object State Description. Disponvel em: http://www.idef.com/idef3.html. Acesso em: 14 fev. 2004. [18] JACKOWSKI, Z. Business Modeling with UML: A Business Process Centred Architecture. Disponvel em: http://www.agilealliance.com/articles/ jackowskizygmuntbusin/file. Acesso em: 15 nov. 2005. [19] JANG, M.; KIM, Y. Process Modeling for Customer Service Process Redesign: A Conceptual Framework. In: Integrating Technology & Human Decisions: Global Bridges into the 21st Century, v. 2, p. 1582-1584. 1999. [20] KIM, H.; KIM, Y. Dynamic Process Modeling for BPR: A Computerised Simulation Approach. In: Information & Management, v. 32, no. 1, p. 1-13. 1997. [21] KIM, Y. G. Process Modeling for BPR: Event - Process Chain Approach. Proceedings of the 16th International Conference on Information Systems, 1995, Amsterdam.

100

[22] KLINT, P. A. Meta-environment for Generating Programming Environments. In: ACM Transactions on Software Engineering Methodology, p. 176-201, 1993. [23] KOBRYN, C.; WEIGERT T. OMG UML 2.0 RFPs. 2000, Disponvel em: ftp://ftp.omg.org/pub/docs/ad/00-09-05.pdf. Acesso em: 14 fev. 2005. [24] KOCK, N., MCQUEEN, R., Knowledge and Information Communication in Organisations: An Analysis of Core, Support and Improvement Processes, Knowledge and Process Management, vol. 5, no. 1, p 29-40. 1998. [25] MAYER R. J., WITTE P. S. Delivering Results: Evolving BPR From Art To Engineerin. Disponvel em http://www.idef.com/Downloads/pdf/bpr.pdf. Acesso em 14 fev. 2004. [26] MOSSES, P. D. A Tutorial on Action Semantics. In: Tutorial notes for Formal Methods Europe, Barcelona, 1994. [27] MOSSES, P. D. Action Semantics. Cambridge University Press. 1992. 329 pp. [28] MOURA H. P, MENEZES L. C. S. The ABACO system - an Algebraic Based Action COmpiler. In: Algebraic Methodology and SoftwareTechnology, v. 1548, p. 527529, 1999. [29] MOURA, H. P. Action Notation Transformations. Glasgow, 1993. Tese de Doutorado, Dept. of Computing Science, Univ. of Glasgow. [30] NICKOLS, F. The Difficult Process of Identifying Processes, Why It Isn't as Easy as Everyone Makes It Sound, 1999. Disponvel em: http://home.att.net/~nickols/diffcult.htm. Acesso em 14 fev. 2004. [31] OMG. OMG Unified Modeling Language Specification. 2000 UML. Disponvel em: http://www.rational.com/media/uml/post.pdf. Acesso em 14 fev. 2005. [32] RBAEK P. OASIS: An optimizing action-based compiler generator. In: CC'94, Proc. 5th Intl. Conf. on Compiler Construction, Edinburgh, v. 786, pp. 1-15. Springer-Verlag, 1994.

101

[33] PALSBERG J. An automatically generated and provably correct compiler for a subset of Ada. In: Fourth IEEE International Conference on Computer Language, San Francisco, California, 1992. [34] PEPPARD, J., ROWLAND, P. The Essence of Business Process Reengineering, Prentice Hall, USA, p. 169-175. 1995. [35] RAINER, F. Aligning Strategies Processes and IT: Case Study. IEEE Engineering Management Review, v. 28, n. 3, p. 81-91, 2000. [36] RICHARD J. M., et. al. Information Integration For Concurrent Engineering (Iice) Idef3 Process Description Capture Method. Report Wright-Patterson Air Force Base, Ohio 45433-7604. 1995. [37] UML Business Modelling Primer. Disponvel em: http://gmckinney.info/resources/ UMLBusinessModelling100.pdf. Acesso em: 14 fev. 2004. [38] WALL, L.; SHWARTZ R. L. Programming Perl. OReily & Associates. 2 ed., 1996. [39] WATT D. A. Executable semantics descriptions. In: Software Practice and Experience, 16(1):13 43, 1986. [40] WATT, D. A. Programming Language Syntax and Semantics. Prentice Hall International (UK) Ltd, 1991. [41] WATT, D. A., MOSSES P. D. Action semantics in action. No Publicado 1987. [42] WfMC, The Workflow Manager Colition. Disponvel em: http://www.wfmc.org/. Acesso em: 15 nov. 2005. [43] YU, E.S.K., et. al. New Concepts and Tools for Re-Engineering, IEEE Expert, p. 1623, 1996.