HENRIQUE GONÇALVES RODRIGUES MEDINA
VERIFICAÇÃO DE CONTRATOS UTILIZANDO BUSINESS
PROCESS MANAGEMENT
LONDRINA 2018
VERIFICAÇÃO DE CONTRATOS UTILIZANDO BUSINESS
PROCESS MANAGEMENT
Trabalho de Conclusão de Curso apresentado ao curso de Bacharelado em Ciência da Com-putação da Universidade Estadual de Lon-drina para obtenção do título de Bacharel em Ciência da Computação.
Orientador: Prof. Dr. Adilson Luiz Boni-fácio
LONDRINA 2018
Ficha de identificação da obra elaborada pelo autor, através do Programa de Geração Automática do Sistema de Bibliotecas da UEL
Sobrenome, Nome.
Título do Trabalho : Subtitulo do Trabalho / Nome Sobrenome. - Londrina, 2017. 100 f. : il.
Orientador: Nome do Orientador Sobrenome do Orientador. Coorientador: Nome Coorientador Sobrenome Coorientador.
Dissertação (Mestrado em Ciência da Computação) - Universidade Estadual de Londrina, Centro de Ciências Exatas, Programa de Pós-Graduação em Ciência da Computação, 2017.
Inclui bibliografia.
1. Assunto 1 - Tese. 2. Assunto 2 - Tese. 3. Assunto 3 - Tese. 4. Assunto 4 - Tese. I. Sobrenome do Orientador, Nome do Orientador. II. Sobrenome Coorientador, Nome Coorientador. III. Universidade Estadual de Londrina. Centro de Ciências Exatas. Programa de Pós-Graduação em Ciência da Computação. IV. Título.
VERIFICAÇÃO DE CONTRATOS UTILIZANDO BUSINESS
PROCESS MANAGEMENT
Trabalho de Conclusão de Curso apresentado ao curso de Bacharelado em Ciência da Com-putação da Universidade Estadual de Lon-drina para obtenção do título de Bacharel em Ciência da Computação.
BANCA EXAMINADORA
Orientador: Prof. Dr. Adilson Luiz Bonifácio Universidade Estadual de Londrina
Profa. Dra. Cinthyan Renata Sachs C. de Barbosa
Universidade Estadual de Londrina – UEL
Prof. Dr. Jacques Duílio Branche Universidade Estadual de Londrina – UEL
Este trabalho é dedicado à geração que segue em frente com nada a não ser café e três horas de sono.
Agradeço ao meu orientador Prof. Dr. Adilson Luiz Bonifácio por todo auxilio, incentivo e conhecimento compartilhado, que nem mesmo nos momentos em que eu pensei em desistir, desistiu de mim.
Agradeço a todos os professores do Departamento de Computação da UEL, em especial ao professor Daniel Kaster, que em um momento difícil da graduação auxiliou, confortou com palavras e me encorajou a seguir em frente e dar continuidade ao curso e à este trabalho.
Agradeço ao meu pai, por toda força, dedicação e incentivo que foram essenciais para percorrer este caminho, à minha mãe que nos momentos de angústia esteve ao meu lado e me deu suporte, à minha namorada, sempre compreensiva e que me incentivou a ir até o fim, e aos meus irmãos, familiares e amigos que me aturaram nos mais variados humores, sempre me dando base para seguir em frente.
lado em Ciência da Computação) – Universidade Estadual de Londrina, Londrina, 2018.
RESUMO
O BPM (Business Process Managent - Gerenciamento de processo de negócios) é um conjunto de conceitos de gestão de negócios para representação do processo de produção de um produto ou serviço. Este trabalho propõe a integração do BPM com a verificação formal de contratos legais utilizando a linguagem de contratos relativizada (RCL). O objetivo é facilitar e, possivelmente, otimizar estes processos com a representação de BPM, porém com a precisão da verificação formal de contratos.
Palavras-chave: BPM, BPMN, Contratos, Verificação de contratos, Gerenciamento de processos de negócio, linguagem de contratos, RCL, formal
MEDINA, H.. Contract verification using Business Process Management. 2018. 53p. Final Project (Bachelor of Science in Computer Science) – State University of Lon-drina, LonLon-drina, 2018.
ABSTRACT
BPM (Business Process Management) is a set of business management concepts to repre-sent the production process of a product or service. This work aims to integrate BPM and formal verification of contracts using Relativized Contract Language (RCL). We aim to ease and, possibly, optimize these processes based on BPM specifications, but still having the accuracy of the formal verification.
Keywords: BPM, BPMN, Contratos, Contract verification, Business Process Manage-ment, Contract language, RCL, formal
Figura 1 – Eventos. . . 16
Figura 2 – Atividade. . . 16
Figura 3 – Gateway. . . . 17
Figura 4 – Gateway Paralelo . . . . 17
Figura 5 – Gateway Exclusivo . . . . 18
Figura 6 – Gateway Inclusivo . . . 18
Figura 7 – Fluxo de sequência. . . 19
Figura 8 – Fluxo de mensagens. . . 19
Figura 9 – Associação. . . 19
Figura 10 – Piscina. . . 19
Figura 11 – Raias. . . 20
Figura 12 – Exemplo pizzaria[1] . . . 21
Figura 13 – BPMN Deôntico [2] . . . 30
Figura 14 – Remoção de Phi-Path de gateways exclusivos [2]. . . . 31
Figura 15 – Gateways exclusivos sem Phi-Path [2]. . . . 31
Figura 16 – Gateways Aninhados [2]. . . . 32
Figura 17 – Gateways condicionais [2]. . . . 32
Figura 18 – Classificações deônticas múltiplas [2]. . . 33
Figura 19 – Gateway Exclusivo (XOR) . . . . 35
Figura 20 – Gateway Paralelo (AND) . . . . 36
Figura 21 – Gateway Inclusivo (OR) . . . . 36
Figura 22 – Gateway Exclusivo Permissivo P(XOR) . . . . 37
Figura 23 – Gateway Inclusivo Permissivo P(OR) . . . . 37
Figura 24 – Exemplo Derivação . . . 38
Figura 25 – Contrato de compra e venda. . . 41
LISTA DE TABELAS
Tabela 1 – Tabela de indivíduos e tarefas. . . 42 Tabela 2 – Equivalência da fórmula RCL derivada. . . 46 Tabela 3 – Análise da fórmula RCL derivada por Wellington na ferramenta
RE-CALL. . . 46 Tabela 4 – Análise da fórmula RCL derivada neste trabalho pela ferramenta
RE-CALL. . . 47 Tabela 5 – Tabela de derivação das regras do contrato de compra e venda. . . 53
BPM Business Process Management
BPMN Business Process Management Notation
CL Contract Language
SUMÁRIO
1 INTRODUÇÃO . . . . 13
2 FUNDAMENTAÇÃO TEÓRICO-METODOLÓGICA . . . . . 14
2.1 Gerenciamento de Processos de Negócio . . . 14
2.1.1 Business Process . . . . 14
2.1.2 BPMN - Business Process Modeling Notation . . . . 15
2.2 Contratos Legais . . . . 22
2.2.1 Formalização de contratos . . . 22
2.2.2 Lógicas para contratos . . . 22
2.2.3 A Linguagem de contratos (𝐶𝐿 - Contract Language) . . . 26
2.2.4 A Linguagem de contratos relativizada (𝑅𝐶𝐿) . . . . 27
2.3 Verificação de contratos . . . . 28
2.3.1 Verificação formal de contratos . . . 28
2.3.2 BPMN Deôntico . . . 30
3 UM MÉTODO DE VERIFICAÇÃO PARA BPM . . . . 34
3.1 Representação formal BPM . . . 34 3.2 Transformação do BPM em RLC . . . . 38 3.3 Estudo de caso . . . 40 4 CONCLUSÃO . . . . 48 REFERÊNCIAS . . . . 49
APÊNDICES
52
1 INTRODUÇÃO
O Gerenciamento de processo de negócios(Business Process Managent - BPM) é um conjunto de conceitos de gestão de negócios para representação do processo de pro-dução de um produto ou serviço. Apesar das vantagens que o modelo visual proporciona, falhas na especificação, como na comunicação dos processos, podem levar a uma imple-mentação equivocada do BPM. As tarefas de análise e monitoramento são de extrema importância para garantir uma implementação correta de um BPM. No entanto, não há conhecimento de métodos e ferramentas que garantam uma modelagem correta dos pro-cessos usando BPM. Este trabalho propõe um mecanismo de apoio e formalização do BPM usando verificação formal de contratos. Um contrato é um conjunto de cláusulas que definem regras e rege uma negociação entre duas ou mais partes para garantir as von-tades dos envolvidos [4]. Um dos grandes problemas em contratos são ambiguidades nas cláusulas contratuais, que podem levar à rescisão contratual e a desentendimentos entre as partes envolvidas. Esses problemas motivam a formalização dos contratos com emba-samento matemático, para que seja possível a validação formal através de um suporte computacional.
Para a correta compreensão da formalização dos contratos é necessário o enten-dimento das representações formais de sistemas, como as lógicas modais, dinâmica pro-posicional, deôntica e a relativização da lógica deôntica. Neste estudo são abordados a linguagem de contratos (CL - Contract Language) e a linguagem de contratos relativi-zada (RCL)[3] e os conceitos que envolvem a verificação formal de contratos. Também são apresentados os principais conceitos e aspectos relacionados a modelagem usando BPM. Alguns trabalhos abordam o tema de formalização de contratos [3], no entanto, não há conhecimento de trabalhos que façam uma relação de BPM com uma linguagem mais precisa, como a RCL. Este trabalho propõe uma forma mais precisa de verificar contratos especificados em BPM, com uma gramática para a representação formal do BPM e uma transformação para RCL através de regras bem definidas para possibilitar uma verificação mais formal.
No capítulo 2 são descritos os conceitos relacionados a BPM , uma de suas prin-cipais notações, o BPMN, além dos conceitos sobre contratos, formalização, lógicas, a linguagem desses, incluindo a relativizada, e a verificação formal. O capítulo 3 descreve o método de verificação proposto, usando uma gramática para representação formal de mo-delos BPM, a transformação dos momo-delos BPM para RCL e o estudo de caso como prova de conceito do método. Por fim, o capítulo 4 apresenta as conclusões, algumas observações e considerações finais, bem como os trabalhos futuros.
14
2 FUNDAMENTAÇÃO TEÓRICO-METODOLÓGICA
Esta seção apresenta os conceitos relacionados ao BPM, modelagem e notações do BPM e suas características, formalização e lógicas utilizadas na representação de contra-tos.
2.1
Gerenciamento de Processos de Negócio
O Gerenciamento de Processos de Negócio (BPM - Business Process Management) é um conjunto de conceitos de gestão de negócios com foco na otimização dos resultados por meio da melhoria desses processos, que utiliza um conjunto de elementos estruturados e relacionados que representam como um serviço ou produto será produzido para seus clientes. Técnicas para modelagem do processo de negócio como fluxogramas, diagramas de controle de fluxo e PERT, entre outros, emergiram desde o começo do século 20 [5]. O termo “modelagem de processo de negócio” passou a ser utilizado na década de 1960 na área de engenharia de sistemas por S. Williams [6]. No entanto o termo só se tornou popular na década de 1990, quando as primeiras ferramentas visuais para modelagem e implementação do processo de negócio foram apresentadas [7]. Na subseção 2.1.1 são apresentados os conceitos sobre gerenciamento de processos de negócio e na subseção 2.1.2 os componentes do BPM juntamente com uma de suas principais notações, o BPMN. 2.1.1 Business Process
Um processo consiste em um número de tarefas que precisam ser feitas e um grupo de condições que determinam a ordem das tarefas. Uma tarefa é uma unidade lógica de trabalho que é executada atomicamente por um recurso, o qual é um nome genérico para uma pessoa, máquina ou grupo de pessoas ou máquinas que podem realizar tarefas específicas [8]. Isso nem sempre significa dizer que recursos necessariamente executam tarefas de forma independente, mas que são responsáveis por ela, por exemplo, um chefe. Atomicidade de uma tarefa significa que uma vez iniciado seu processo de execução, ele deve ser feito por inteiro e caso algo dê errado durante a realização de uma tarefa, ela deve começar novamente deste o início e todo seu progresso deve ser descartado, em outras palavras, um rollback. No entanto, a indivisibilidade de uma tarefa depende do contexto em que ela é definida, como por exemplo, uma tarefa entre um cliente e um revendedor pode ser atômica para o cliente, no entanto, pode não ser o caso para o revendedor, que pode dividir a tarefa de revenda para o cliente em diferentes tarefas menores[8].
A ordem que as tarefas são executadas podem ser diferentes conforme a pro-priedade dos casos. Condições são usadas para decidir a ordem a ser seguida. Pode-se
identificar quatro mecanismos básicos diferentes nas estruturas de processos: sequência, paralelização, seleção e iteração[8].
∙ Sequencial. A forma mais simples é a execução, onde as tarefas são executadas uma após a outra. Nesse caso a dependência entre as tarefas é clara, o resultado de uma tarefa é entrada para a próxima.
∙ Paralelas. Se duas tarefas são executadas de forma simultânea, ou a ordem de execução delas não importa. Nesse caso, se duas tarefas precisam ser executadas sem que o resultado de uma afete diretamente a outra, elas podem ser executadas de forma paralela, utilizando um 𝐴𝑁 𝐷 − 𝑠𝑝𝑙𝑖𝑡 e depois são re-sincronizadas com um 𝐴𝑁 𝐷 − 𝑗𝑜𝑖𝑛.
∙ Seleção. Quando existe uma escolha entre duas ou mais tarefas, essa escolha pode depender de propriedades especificas de cada caso. A escolha entre alternativas, é conhecida como 𝑂𝑅 − 𝑠𝑝𝑙𝑖𝑡, e depois são reunidas usando um 𝑂𝑅 − 𝑗𝑜𝑖𝑛. Também podem ser conhecidas como condicionais ou alternativas.
∙ Iteração. O ideal é que tarefas sejam executadas somente uma vez por caso, no entanto, em alguns casos é necessário que uma tarefa seja repetida até que um resultado subsequente seja considerado satisfatório.
Algumas tarefas podem ser manuais, quando executadas inteiramente por pes-soas; automáticas, se executadas sem interferência humana alguma; ou semi-automáticas, quando ambos, pessoas e máquinas estiverem envolvidas em sua execução.
Processos além de tarefas e condições, podem ser construídos a partir de sub-processos, que são construídos de tarefas, condições e outros sub-sub-processos, formando assim uma estrutura que pode ser usada repetidamente para formar processos mais com-plexos. Um processo é definido com um ciclo de vida, com um início e um fim definidos claramente[8].
2.1.2 BPMN - Business Process Modeling Notation
A modelagem é uma etapa muito importante, onde os processos são representados e alterados para que sejam otimizados. O BPMN (Business Process Modeling Notation) é uma das notações mais utilizadas para representação de processos de negócios. Trata-se de uma série de símbolos padrões para a representação dos elementos e relações entre eles no processo, como um diagrama ou work-flow. A Business Process Management Initiative (BPMI) desenvolveu o BPMN, que foi mantido pelo Object Management Group desde que as duas organizações se fundiram em 2005[9]. A versão 2.0 do BPMN foi lançada em janeiro de 2011[10], ponto em que o nome foi adaptado para Business Process Model and Notation. O BPMN é uma notação gráfica que descreve em passos o processo de negócios. A notação foi projetada especificamente para coordenar a sequência de processos e as mensagens que fluem entre diferentes participantes do processo em um conjunto relacionado de atividades
16
[10]. Os componentes do BPM são chamados de elementos e na modelagem BPMN estes são divididos em cinco grupos:
1. Objetos de fluxo (𝐹 𝑙𝑜𝑤 𝑂𝑏𝑗𝑒𝑐𝑡𝑠)
Objetos de fluxo representam os conceitos de gestão de negócio sendo modelados e são os principais elementos gráficos que definem o comportamento do processo de ne-gócio [11]. Eles podem ser separados em três áreas: eventos, atividades e 𝑔𝑎𝑡𝑒𝑤𝑎𝑦𝑠. Um evento é uma ocorrência durante o fluxo de um processo e são usados tam-bém para representar o seu início e fim. Esses eventos afetam o fluxo do modelo e geralmente são uma causa (𝑡𝑟𝑖𝑔𝑔𝑒𝑟) ou um efeito (𝑟𝑒𝑠𝑢𝑙𝑡) [11]. Eles podem ser cus-tomizados para representar detalhes específicos do processo, como o envio de uma mensagem por exemplo[12]. Na Figura 1 podemos ver as três categorias de eventos.
Figura 1 – Eventos.
Atividades descrevem o tipo de trabalho que está sendo executado em uma
de-terminada instância[12]. Uma atividade é um termo genérico para tarefas que são executadas no processo[11] e elas são representadas como na Figura 2.
Figura 2 – Atividade.
O fluxo do processo pode sofrer divergências para representar a tarefas simultâneas ou paralelas, e também convergências durante sua execução para representar de-pendência de tarefas anteriores. Gateways controlam a divergência e a convergência de fluxos de sequência no processo[12]. Eles determinam ramificações, separam e recombinam fluxos em um diagrama e são representados como na Figura 3.
Figura 3 – Gateway.
Marcações internas representam o tipo de comportamento de controle do gateway [11], por exemplo:
Gateway Paralelo
Representado pelo sinal interno conforme a Figura 4, o gateway paralelo é, por um lado, usado para sincronizar múltiplas ramificações concorrentes, e por outro para iniciar novas threads concorrentes em ramificações paralelas. O gateway paralelo é ativado se existe pelo menos um token em cada fluxo de sequência de entrada. O
gateway paralelo consome exatamente um token de cada fluxo de entrada e produz
exatamente um token também em cada fluxo de saída. Se existem tokens excedentes em um fluxo de entrada, esses permanecem após a execução do gateway [11].
Figura 4 – Gateway Paralelo
Gateway Exclusivo
No gateway exclusivo cada ativação do gateway leva a ativação de uma única rami-ficação e ele pode ser representado por um vazio ou por um símbolo de ’X’ interno. Cada token que chega em um fluxo de sequência ativa o gateway e sua rota é definida para um único caminho de saída. Para determinar qual fluxo de saída correto, as condições são avaliadas em ordem e a primeira condição a ser verdadeira determina o fluxo de sequencia para o qual o token será enviado e nenhuma outra condição será avaliada. Como mostra a Figura 5, se nenhuma das condições forem avaliadas como verdadeiras o token é passado para o fluxo de sequência padrão (default) e caso esse não exista, uma exceção é enviada [11].
18
Figura 5 – Gateway Exclusivo
Gateway Inclusivo O gateway inclusivo, na Figura 6, sincroniza um determinado
subgrupo de ramificações do grupo de entrada e leva para a criação de threads em um determinado subgrupo de saída. Esse gateway é ativado quando pelo menos um dos fluxos de sequência contém um token. Quando executado, um token é consumido de cada fluxo de sequência que tiver pelo menos um token e um deles será produzido em alguns dos fluxos de sequência de saída. Para determinar esse fluxo que receberá um
token, todas as condições de saída são avaliadas. A avaliação não necessariamente
respeita uma ordem. Para cada condição avaliada como verdadeira, um token deve ser passado para o respectivo fluxo de sequência. Se, e somente se, nenhuma das condições forem avaliadas como verdadeiras, o token é passado para o fluxo de sequência padrão (default), se este existir, caso não exista o gateway envia uma exceção[11].
Figura 6 – Gateway Inclusivo
2. Objetos de conexão (𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑛𝑔 𝑂𝑏𝑗𝑒𝑐𝑡𝑠)
Objetos de conexão [11] representam as conexões no fluxo do diagrama. Existem tipos diferentes de objetos de conexão: fluxos de sequência, fluxos de mensagem, associações e associações de dados. O fluxo de sequência mostra a ordem que as atividades serão realizadas em um processo e são representados graficamente como linhas direcionadas e contínuas, como mostra a Figura 7. Os fluxos de mensagem são representados graficamente como linhas direcionadas e descontínuas, conforme a Figura 8 e associações são usadas para ligar informações e artefatos com outros elementos gráficos do modelo e são representadas graficamente como linhas não direcionadas e descontinuas, assim como demonstra a Figura 9.
Figura 7 – Fluxo de sequência.
Figura 8 – Fluxo de mensagens.
Figura 9 – Associação.
3. Dados (𝐷𝑎𝑡𝑎)
Dados podem ser separados em quatro tipos: Objetos de Dados, Entrada de Dados, Saída de Dados e Banco de Dados. Objetos de Dados são utilizados para informar sobre os requisitos para uma atividade ser realizada e/ou o que elas produzem. Podem representar um único objeto ou uma coleção de objetos. Entrada e saída de Dados providenciam a mesma informação para os processos [11]. O Banco de Dados é um mecanismo que permite as atividades recuperarem ou atualizarem uma informação que irá persistir além do escopo do processo.
4. Piscinas e Raias (𝑃 𝑜𝑜𝑙 e 𝑆𝑤𝑖𝑚𝑙𝑎𝑛𝑒𝑠)
As Piscinas são uma representação gráfica conforme mostra a Figura 10, de um participante do processo, onde geralmente são representados uma empresa ou um processo inteiro. Uma Raia é uma sub-partição em um processo, onde podem ser definidos os responsáveis específicos que realizam um sub-conjunto de tarefas do processo, como na Figura 11. São usadas para organizar e categorizar atividades [11], para organizar um diagrama no BPMN e agrupam objetos facilitando a visualização de cada aspecto do diagrama, além disso, podem mostrar atrasos, ineficiências, bem como, o responsável por cada tarefa do processo[12].
20
Figura 11 – Raias.
5. Artefatos (𝐴𝑟𝑡𝑖𝑓 𝑎𝑐𝑡𝑠)
Artefatos representam informações relevantes para o modelo, mas não para
elemen-tos individuais do processo[12]. Elas são Anotações e Grupos.
Anotações permitem descrever fluxos adicionais do modelo ou notação por quem
está modelando e são anexadas utilizando associações [11].
Grupos são utilizados para agrupar tarefas ou processos que são de uma mesma
categoria. Esse agrupamento não influencia no fluxo de sequência e podem ser usados para propósitos de análise ou documentação [11].
A figura 12 é um exemplo simples que demonstra a interação entre duas partes distintas, que são o cliente e vendedor e estão divididos em duas piscinas ou Pools.
Figura 12 – Exemplo pizzaria[1]
O processo se inicia no cliente, pelo símbolo 𝐻𝑢𝑛𝑔𝑟𝑦 𝑓 𝑜𝑟 𝑝𝑖𝑧𝑧𝑎 que representa o início do evento. Em sequência temos duas atividades, 𝑆𝑒𝑙𝑒𝑐𝑡 𝑎 𝑝𝑖𝑧𝑧𝑎 e 𝑂𝑟𝑑𝑒𝑟 𝑎 𝑝𝑖𝑧𝑧𝑎. A atividade 𝑂𝑟𝑑𝑒𝑟 𝑎 𝑝𝑖𝑧𝑧𝑎 dispara uma mensagem 𝑝𝑖𝑧𝑧𝑎 𝑜𝑟𝑑𝑒𝑟 para a Pool 𝑃 𝑖𝑧𝑧𝑎 𝑣𝑒𝑛𝑑𝑜𝑟, que inicia o seu processo recebendo a mensagem 𝑂𝑟𝑑𝑒𝑟 𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑. A tarefa 𝑂𝑟𝑑𝑒𝑟 𝑎 𝑝𝑖𝑧𝑧𝑎 segue para o símbolo de Gateway baseado em evento, que aguardará até que um dos dois eventos subsequentes ocorram: ou o evento de tempo 60 𝑚𝑖𝑛𝑢𝑡𝑒𝑠, caso 60 minutos se passem, ou 𝑝𝑖𝑧𝑧𝑎 𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑 caso receba a pizza. Enquanto isso, na Pool 𝑃 𝑖𝑧𝑧𝑎 𝑣𝑒𝑛𝑑𝑜𝑟, a
Lane 𝑐𝑙𝑒𝑟𝑘, que representa o atendente, o fluxo segue pelo símbolo de atividade paralela
para a Lane 𝑝𝑖𝑧𝑧𝑎 𝑐ℎ𝑒𝑓 , que inicia a tarefa 𝐵𝑎𝑘𝑒 𝑡ℎ𝑒 𝑝𝑖𝑧𝑧𝑎, paralelamente o atendente fica pronto para receber uma mensagem 𝑤ℎ𝑒𝑟𝑒 𝑖𝑠 𝑚𝑦 𝑝𝑖𝑧𝑧𝑎?. Na Lane do cliente, caso 60 minutos se passem, uma tarefa 𝐴𝑠𝑘 𝑓 𝑜𝑟 𝑡ℎ𝑒 𝑝𝑖𝑧𝑧𝑎 dispara uma mensagem para o atendente, que está pronto para responder com a tarefa 𝐶𝑎𝑙𝑚 𝑐𝑢𝑠𝑡𝑜𝑚𝑒𝑟. Após a tarefa
𝐵𝑎𝑘𝑒 𝑡ℎ𝑒 𝑝𝑖𝑧𝑧𝑎 ser concluída, o processo continua para a Lane 𝐷𝑒𝑙𝑖𝑣𝑒𝑟𝑦 𝑏𝑜𝑦 que executa
a tarefa 𝐷𝑒𝑙𝑖𝑣𝑒𝑟 𝑡ℎ𝑒 𝑝𝑖𝑧𝑧𝑎 enviando uma mensagem 𝑝𝑖𝑧𝑧𝑎 para o cliente. O cliente então libera o evento 𝑝𝑖𝑧𝑧𝑎 𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑 levando à tarefa 𝑃 𝑎𝑦 𝑡ℎ𝑒 𝑝𝑖𝑧𝑧𝑎 que troca mensagens com a tarefa 𝑅𝑒𝑐𝑒𝑖𝑣𝑒 𝑝𝑎𝑦𝑚𝑒𝑛𝑡, a qual após enviar sua mensagem, termina o processo da Pool
𝑃 𝑖𝑧𝑧𝑎 𝑣𝑒𝑛𝑑𝑜𝑟, Na Pool 𝑃 𝑖𝑧𝑧𝑎 𝐶𝑢𝑠𝑡𝑜𝑚𝑒𝑟, segue-se para a tarefa 𝐸𝑎𝑡 𝑡ℎ𝑒 𝑝𝑖𝑧𝑧𝑎 finalizando
22
2.2
Contratos Legais
Um contrato pode ser definido como um conjunto de cláusulas, que rege uma negociação entre duas ou mais partes, para que constituam, modifiquem ou extinguam vínculos jurídicos. Os contratos são uma forma de manifestar e garantir as vontades dessas partes sobre um determinado assunto, geralmente de natureza patrimonial[4].
O contrato eletrônico é uma conversão de contratos convencionais, em que duas ou mais partes possam expressar, ou não, suas declarações de vontade por meios digitais. Para que o contrato eletrônico tenha sua existência e validade jurídica, é necessária a observância de requisitos que cabem aos contratos em geral. Além disso, ainda há abor-dagens que tratam da utilização de contratos eletrônicos para formalizar regras de negócio em workflows [13], verificação de sistemas baseados em multi-agentes [14], verificação de arquiteturas baseadas em serviços e em nuvem [15], entre outras aplicações.
2.2.1 Formalização de contratos
O processo de formalização pode ser entendido como a depuração técnica do vago ao preciso [16], de forma a eliminar ambiguidades e imprecisões que possam ser causadas pela linguagem natural, mediante a representação por símbolos e definindo operações a serem executadas por artefatos formais sobre esses símbolos [17]. Nos contratos, a formali-zação pode ser considerada como essencial, visto que é indesejável que haja ambiguidades nas cláusulas, o que poderia levar à rescisão do contrato ou desistência de negócio por uma das partes. Para que isso não ocorra é necessário um alto grau de precisão. A utiliza-ção de formalismos em contratos também possibilita a verificautiliza-ção sistemática com apoio computacional [3].
2.2.2 Lógicas para contratos
A linguagem para contratos, denominada 𝐶𝐿 [18], foi desenvolvida para a represen-tação formal de contratos legais, serviços web, interfaces e protocolos de comunicação[3]. Essa linguagem é expressiva o suficiente para capturar o comportamento de contratos e permitir sua verificação formal. A 𝐶𝐿 é baseada em ações síncronas (concorrentes), nos princípios da lógica deôntica para definir normas [19], e na lógica dinâmica proposicional para representar as ações num sistema [20]. Para melhor compreensão da linguagem de contratos, é necessário primeiro entender as lógicas que a compõem, portanto os conheci-mentos sobre a 𝐶𝐿 serão aprofundados na subseção 2.2.3. Serão apresentadas 4 das lógicas que fundamentam a linguagem de contratos:
1. Lógica modal
possuem características modais[3]. A lógica modal é, estritamente falando, o es-tudo do comportamento dedutivo das expressões "é necessário que"e "é possível que", ou seja, sua principal característica é a capacidade de expressar necessidade e possibilidade[21]. A lógica modal é baseada nos conectivos da lógica proposicional: negação ¬; conjunção ∧; disjunção ∨; condicional −→; e bicondicional ←→. Além dos operadores proposicionais, são acrescido dos operadores modais[22]:
𝑝, necessariamente 𝑝 ◇ 𝑝, possivelmente 𝑝
Nas lógicas modais clássicas, cada um pode ser expresso em função do outro e da negação:
◇𝑝 ≡ ¬¬𝑝 𝑝 ≡ ¬ ◇ ¬𝑝
2. Lógica dinâmica proposicional
A lógica dinâmica é uma extensão da lógica modal e é composta basicamente pelos operadores de necessidade e possibilidade [] e ⟨⟩, respectivamente[23].
O significado de [𝑎]𝑝 é de que, após executar a ação 𝑎, é necessariamente o caso que 𝑝 se verifique, isto é, todo estado de 𝑎 deve acarretar 𝑝, ou ainda, esse deve ser verdadeiro após 𝑎[23].
O significado de ⟨𝑎⟩𝑝 é de que, após executar a ação 𝑎, existe um estado em que 𝑝 se verifica, ou seja, existe um estado após 𝑎 que deve acarretar 𝑝, ou ainda, é possível que 𝑝 seja verdade após 𝑎[23].
Equivalências[23]: [𝑎]𝑝 ≡ ¬⟨𝑎⟩¬𝑝 ⟨𝑎⟩𝑝 ≡ ¬[𝑎]¬𝑝
Essa lógica permite ações compostas construídas a partir de ações menores. En-quanto os operadores de controle de base de qualquer linguagem de programação pode ser utilizada para esse fim, operadores de expressão regular de Kleene são uma boa combinação para a lógica modal.
Dadas ações 𝑎 e 𝑏, a componente 𝑎 ∪ 𝑏, pode-se escrever também como 𝑎 + 𝑏 ou
𝑎|𝑏, é realizada através de uma delas. O componente 𝑎; 𝑏, representa sequência,
e é realizado efetuando primeiro 𝑎 e depois 𝑏, 𝑎⋆, representa iteração, dado pela execução de 𝑎 zero ou mais vezes, sequencialmente. O componente 𝑎?, representa teste lógico, se 𝑎 se verifica então prossiga, e caso não, aborte. A constante 0 ou
𝐵𝐿𝑂𝐶𝐾 não realiza operação alguma e não finaliza, ao passo que a constante 1,
ou 𝑆𝐾𝐼𝑃 , ou 𝑁 𝑂𝑃 , não faz nada, porém finaliza.
As fórmulas da lógica dinâmica descrevem propriedades que ocorrem após a execução de um programa. A fórmula 𝐴 = [𝑎 ∪ 𝑏]𝑝, por exemplo, indica que sempre que o
24
programa 𝑎 ou o programa 𝑏 são executados a proposição 𝑝 é verdadeira no estado seguinte[3].
3. Lógica deôntica
A lógica deôntica é um tipo especial de lógica modal que aborda os conceitos norma-tivos, sistemas de normas e o raciocínio sobre essas normas. Os conceitos normativos incluem deveres, possibilidades e impossibilidades, representados respectivamente, pela obrigação, permissão e proibição de ações [24].
Operadores: 𝑂:Obrigatório 𝐹 :Proibido 𝑃 :Permitido Tabela de equivalências[24]: 𝑂𝑝 ≡ 𝐹 ¬𝑝 ≡ ¬𝑃 ¬𝑝 𝑂¬𝑝 ≡ 𝐹 𝑝 ≡ ¬𝑃 𝑝 ¬𝑂¬𝑝 ≡ ¬𝐹 𝑝 ≡ 𝑃 𝑝 ¬𝑂𝑝 ≡ ¬𝐹 ¬𝑝 ≡ 𝑃 ¬𝑝
A partir do operador O, é possível qualificar atos ou proposições como obrigató-rios e a partir do operador de obrigação e da negação lógica (¬) é possível definir os operadores de proibição (𝐹 ) e de permissão (𝑃 ):
𝑂𝑝 ≡ 𝐹 ¬𝑝 ≡ ¬𝑃 ¬𝑝
4. Lógica deôntica relativizada
A relativização da lógica deôntica[25] é a principal alteração da lógica deôntica pa-drão, para que os indivíduos envolvidos em uma modalidade deôntica possam ser identificados. Essa modificação permite a especificação de cláusulas na lógica deôn-tica clássica, onde as expressões são escritas sem revelar a identidade dos indivíduos envolvidos. A expressão 𝑂(𝑎) por exemplo, significa que é obrigatório executar a ação 𝑎. Essa obrigação é imposta a algum indivíduo ou é genérica, direcionada a todos os possíveis indivíduos. A falta de personificação das ações torna a aplica-ção da lógica dinâmica clássica limitada tanto na análise do mundo real, quanto na concepção de sistemas multi-agente [26].
Nesse cenário é comum existir sentenças sem a menção do indivíduo responsável pela ação, como por exemplo em "é obrigatório pagar o produto para o vendedor", porém expressar sentenças, tais como "é obrigatório que João pague o produto para o vendedor", também são desejáveis.
Um tipo de relativização de operadores deônticos foi proposto por Herrestad e Krogh [25] para explicitar o indivíduo responsável pela execução de uma determinada ação.
A relativização da lógica deôntica especifica quais indivíduos estão relacionados a um certo operador deôntico. Os operadores deônticos são considerados relativizados, quando apontam o indivíduo responsável por executar uma ação, ou não relativiza-dos, quando não definem esse indivíduo [26].
Vários tipos de modalidades vinculando indivíduos específicos, podem ser obtidos conforme segue:
∙ Modalidade geral (ou genérica): modalidade relativa a todos os indivíduos; ∙ Modalidade impessoal (ou não especificada): quando a modalidade não
menci-ona o indivíduo vinculado;
∙ Modalidades pessoais (ou relativizadas): modalidade relacionada a um único indivíduo; e
∙ Modalidade direcionada: quando a modalidade especifica o indivíduo que deve executar a ação e o indivíduo beneficiado (ou requerente) dessa ação.
A relativização da lógica deôntica é obtida ao adicionar operadores capazes de definir o portador da modalidade relacionada à execução de certa ação. O conjunto de todos os indivíduos é denotado por 𝐼 e cada indivíduo portador da obrigação ou permissão é referido pelo nome ou por um índice 𝑖, 𝑗, 𝑘... ∈ 𝐼. Seja o indivíduo 𝑖 e uma ação 𝑎, a sentença 𝑖𝑂(𝑎) expressa que o indivíduo 𝑖 é obrigado a fazer 𝑎, e 𝑖𝑃 (𝑎) significa que indivíduo 𝑖 tem permissão para executar a ação 𝑎 [25].
Essa relativização possibilita expressar situações mais detalhadas com a lógica deôn-tica, como por exemplo, em um comércio eletrônico, onde o vendedor 𝑖 é obrigado a 𝑒𝑛𝑡𝑟𝑒𝑔𝑎𝑟 um produto e o cliente 𝑗 é obrigado a 𝑝𝑎𝑔𝑎𝑟 por esse produto. Essa sentença pode ser descrita por 𝑖𝑂(𝑒𝑛𝑡𝑟𝑒𝑔𝑎𝑟) ∧ 𝑗𝑂(𝑝𝑎𝑔𝑎𝑟)[3].
Uma característica típica das obrigações presentes em contratos é sua execução por um indivíduo, o portador da obrigação para outro, chamado de contra-parte ou requerente [27].
Para entender essa necessidade, suponha o vendedor 𝑖 e o cliente 𝑗, num contrato em que 𝑖 deve entregar o produto para 𝑗. Dessa cláusula podemos extrair duas sentenças, uma em que 𝑖 deve entregar o produto para 𝑗 e outra que 𝑗 deve receber o produto de 𝑖. Nessa construção fica clara que as sentenças convergem para a mesma situação:
𝑖𝑂(𝑒𝑛𝑡𝑟𝑒𝑔𝑎𝑟) ∧ 𝑗𝑂(𝑟𝑒𝑐𝑒𝑏𝑒𝑟)[3].
Além disso, existe o direcionamento da ação 𝑒𝑛𝑡𝑟𝑒𝑔𝑎𝑟 onde a obrigação de executá-la pertence ao cliente e o direito de recebê-la é do vendedor.
Uma obrigação direcionada é entendida como a união de duas obrigações relativi-zadas, em que a primeira 𝑖𝑂(𝑎) indica que o indivíduo 𝑖 deve executar a ação 𝑎 e
26
a segunda 𝑂𝑗(𝑎) expressa que o indivíduo 𝑗 deve receber a execução da ação 𝑎. A sentença 𝑖𝑂𝑗(𝑎) representa uma obrigação direcionada [25].
Dessa forma, a sentença 𝑖𝑂𝑗(𝑎) ⇐⇒ 𝑖𝑂(𝑎) ∧ 𝑂𝑗(𝑎) indica que o indivíduo 𝑖 é obrigado a executar a ação 𝑎 em favor ao indivíduo 𝑗, se e somente se, 𝑖 é obrigado a executar a ação 𝑎 e 𝑗 é obrigado a ser beneficiado pela ação 𝑎. Do ponto de vista legal, o indivíduo 𝑗 é considerado no operador 𝑂𝑗 como o requerente da ação [3]. 2.2.3 A Linguagem de contratos (𝐶𝐿 - Contract Language)
A parte deôntica da 𝐶𝐿 possui os operadores de permissão, obrigação e proibi-ção, bem como a compensação sobre a violação de obrigações ou proibições. Já a parte dinâmica expressa as cláusulas válidas após a execução de alguma ação. Uma caracterís-tica importante da 𝐶𝐿 é a captura de conceitos e propriedades naturais encontradas em contratos legais e eletrônicos buscando evitar os principais paradoxos deônticos[28].
As cláusulas podem conter os operadores lógicos, como na lógica proposicional, representados pela conjunção ∧ e pelo valor lógico falso, denotado por ⊥. As constantes proposicionais são denotadas por 𝜙. Uma constante proposicional descreve uma situação como por exemplo "o produto foi entregue"ou "o banco repassou o valor do frete"[3].
A sintaxe da 𝐶𝐿 é definida pela gramatica a seguir, onde 𝐶 é um contrato ou uma de suas cláusulas:
𝐶 ::= 𝜑 | 𝑂𝐶(𝛼) | 𝑃 (𝛼) | 𝐹𝐶(𝛼) | 𝐶 ∧ 𝐶 | [𝛽]𝐶 | ⊥ 𝛼 ::= 0 | 1 | 𝛼 × 𝛼 | 𝛼 · 𝛼 | 𝛼 + 𝛼
𝛽 ::= 0 | 1 | 𝛽 × 𝛽 | 𝛽 · 𝛽 | 𝛽 + 𝛽 | 𝛽 | 𝛽* | 𝜙? 𝜙 ::= 0 | 1 | 𝜙 ∨ 𝜙 | 𝜙 ∧ 𝜙 | ¬𝜙
Uma ação é considerada uma tarefa ou programa da lógica dinâmica proposicional, obrigatória, proibida ou permitida, de acordo com a modalidade deôntica associada. As ações executadas dentro dos operadores deônticos são representadas por 𝑎. Já as ações
𝑏 são utilizadas nos operadores dinâmicos juntamente com o teste lógico, denotado por 𝜑. As ações de ônticas consistem num conjunto de ações básicas (ou atômicas) denotado
por 𝐴𝐵. Além disso,existem os tipos especiais de ações que não pertencem ao conjunto
𝐴𝐵, representadas por 0 e 1. A ação 0 representa uma violação num contrato e a ação 1,
chamada ação de salto (skip), representa a execução de qualquer ação do conjunto 𝐴𝐵 e significa que a ação executada, em particular, não é importante [3].
As ações dentro das fórmulas podem ser combinadas pelos operadores: +, quando há uma escolha entre as ações; ·, quando existe uma sequência de ações; e ×, quando ocorrem ações síncronas (ou concorrentes). O conjunto de ações compostas 𝐴𝐷 é composto por ações básicas, ações especiais 0 e 1 e pela combinação de operadores. O conjunto de
ações concorrentes, denotado por 𝐴×𝐵 , é formado por ações compostas que utilizam apenas o operador × e obtidas a partir da combinação das ações básicas. Na 𝐶𝐿, as ações atômicas de 𝐴𝐵 são representadas por símbolos e, intuitivamente, executadas por um indivíduo. Nesta linguagem, os indivíduos são incorporados nas ações, seguindo o conceito da lógica deôntica padrão [15].
As modalidades deônticas 𝑂𝐶(𝑎), 𝐹𝐶(𝑎), 𝑃 (𝑎) representam respectivamente os
operadores de obrigação, proibição e permissão da lógica deôntica padrão, onde 𝑎 é uma ação e𝐶 representa a penalidade ou reparação quando a cláusula é violada após a execução
da ação. Note que não existe nenhum tipo de reparação nas permissões já que estas são facultativas e não implicam numa violação.
Esse conceito de reparação, representa as cláusulas contrárias ao dever (CTD ou
contrary-to-duty) e contrárias à proibição (CTP ou contrary-to-prohibition). As cláusulas
CTD representam situações em que há uma violação de obrigação primária e implica em executar uma obrigação secundária. Essa obrigação secundária é uma reparação ou penalidade da violação gerada pela obrigação primária. O mesmo ocorre para o CTP que trata da violação de uma proibição [29].
Obrigações ou proibições sem reparações, 𝑂⊥(𝑎) e 𝐹⊥(𝑎), também podem ser
representadas, onde o símbolo ⊥ indica a ausência de reparação, ou seja, que o contrato
será violado. Obrigações (ou proibições) sem reparações são chamadas de categóricas, pois não podem ser violadas de forma alguma. Para facilitar a sintaxe, as obrigações categóricas podem ser representadas por 𝑂(𝑎) e, do mesmo modo, as proibições como
𝐹 (𝑎).
Os operadores deônticos da 𝐶𝐿 são aplicados apenas sobre as ações, ao contrário da lógica deôntica clássica que permite a aplicação das modalidades deônticas tanto em ações quanto em situações. Já os operadores dinâmicos são aplicados sobre as ações dinâmicas 𝑏. Na expressão [𝑏]𝑂(𝑎), por exemplo, após 𝑏 ser executada, 𝑎 é obrigatoriamente executada. A lógica dinâmica proposicional na 𝐶𝐿 também proporciona a interação entre as ações e as fórmulas. Obrigações condicionais (ou permissões e proibições) podem ser expressas de duas formas: [𝑏]𝑂(𝑎), onde após 𝑏 ser executada, obrigatoriamente 𝑎 deve ser executada; [𝐶?]𝑂(𝑎), simula a implicação 𝐶 ? 𝑂(𝑎). A sequência 𝜑?.𝑎 indica uma ação de guarda, onde 𝑎 é executada se 𝜑 é verdadeira[3].
2.2.4 A Linguagem de contratos relativizada (𝑅𝐶𝐿)
A sintaxe relativizada da 𝐶𝐿, chamada de 𝑅𝐶𝐿, proposta por Wellington A. Della Mura [3] como um método para detecção de conflitos em contratos multilaterais é baseada na 𝐶𝐿 com características da lógica deôntica relativizada [3].
28
deônticos e dinâmicos da 𝐶𝐿. Seja 𝐶 um contrato, onde 𝐼 é o conjunto de indivíduos do contrato, 𝐷 ={𝑂, 𝑃, 𝐹 } é o conjunto de operadores deônticos, 𝑅 = {𝑔, 𝑖, 𝑖 y 𝑗|𝑖, 𝑗 ∈ 𝐼} define os tipos de relativizações possíveis e 𝑎 uma ação relacionada ao operador 𝑑, com
𝑑 ∈ 𝐷. A fórmula 𝑔𝑑(𝑎) indica que a ação 𝑎 deve ser executada por todos os indivíduos
de 𝐼 sob o operador deôntico 𝑑. Já a fórmula 𝑖𝑑(𝑎) indica que o indivíduo 𝑖 ∈ 𝐼 deve
executar a ação 𝑎 relacionada ao operador 𝑑. Por fim, 𝑖 y𝑗𝑑(𝑎) indica que o indivíduo 𝑖
deve executar a ação 𝑎 associada para o indivíduo 𝑗 conforme 𝑑 [3].
Com o propósito de simplificar a notação, o símbolo 𝑔 que representa um operador global é suprimido na sintaxe. Já para os operadores dinâmicos, 𝑔[𝑎]𝐶 indica que após
a execução da ação 𝑎 por todos os indivíduos, o contrato 𝐶 entra em vigor. O operador dinâmico relativizado 𝑖[𝑎]𝐶 indica que 𝐶 é válido se o indivíduo 𝑖 executar 𝑎. Por último, 𝑖 y𝑗[𝑎]𝐶 indica que 𝐶 entra em vigor se 𝑖 executar 𝑎 para 𝑗 [3].
A sintaxe relativizada da 𝐶𝐿, chamada de 𝑅𝐶𝐿, é descrita conforme a gramática:
𝐶 ::= 𝐶𝑂 | 𝐶𝑃 | 𝐶𝐹 | 𝐶 ∧ 𝐶 | 𝐶𝐷 | ⊤ | ⊥ 𝐶𝑂 ::= 𝑂𝐶′(𝛼) | 𝑖𝑂𝐶′(𝛼) |𝑖y𝑗𝑂𝐶′(𝛼) | 𝐶𝑂⊕ 𝐶𝑂 𝐶𝑃 ::= 𝑃 (𝛼) |𝑖𝑃 (𝛼) | 𝑖y𝑗𝑃 (𝛼) | 𝐶𝑃 ⊕ 𝐶𝑃 𝐶𝐹 ::= 𝐹𝐶′(𝛼) |𝑖𝐹𝐶′(𝛼) |𝑖y𝑗𝐹𝐶′(𝛼) | 𝐶𝐹 ∨ 𝐶𝐷𝐶𝐹 𝐶𝐷 ::= [𝛽]𝐶 | 𝑖[𝛽]𝐶 | 𝑖y𝑗[𝛽]𝐶 𝛼 ::= 0 | 1 | 𝛼 | 𝛼 × 𝛼 | 𝛼 · 𝛼 | 𝛼 + 𝛼 𝛽 ::= 0 | 1 | 𝛼 | 𝛽 × 𝛽 | 𝛽 · 𝛽 | 𝛽 + 𝛽 | 𝛽 | 𝛽*
Um contrato 𝐶 pode ser derivado por obrigações 𝐶𝑂, permissões 𝐶𝑃, proibições 𝐶𝐹
e operadores dinâmicos 𝐶𝐷. Os operadores lógicos de conjunção, ∧ , disjunção exclusiva, ⊕
e disjunção, ∨, são aplicados conforme definição convencional. Além disso, os operadores deônticos de obrigação e proibição são acompanhados do mecanismo de penalidade em caso de violação. Na fórmula 𝑖𝑂𝐶(𝛼), a penalidade 𝐶′ passa a vigorar caso o indivíduo 𝑖
não execute a ação 𝛼. Note que 𝐶′ é uma cláusula em 𝑅𝐶𝐿.
2.3
Verificação de contratos
Diversas pesquisas já foram realizadas sobre a área de contratos eletrônicos, em especial, na verificação formal desses contratos. A automatização da análise de um con-trato, além de acelerar sua escrita, permite que propriedades desejadas sejam formalmente verificadas [30].
2.3.1 Verificação formal de contratos
Negociação: É um cenário em que, pelo menos, dois indivíduos visam alcançar um acordo. Normalmente, cada parte inicia a negociação oferecendo a solução preferida de seu interesse. A outra parte, caso não aceite, deve fazer contrapropostas de forma a convergir para que ambos aceitem a solução proposta.
Detecção de Conflitos: Tem como objetivo detectar e eliminar conflitos em cláu-sulas que se contradizem [30]. Essa situação invalida um contrato, visto que podem gerar uma violação, por exemplo: dado dois indivíduos 𝑖 e 𝑗, onde 𝑖 é obrigado a pagar para 𝑗
𝑂(𝑝) e 𝑗 é proibido de receber de 𝑖 𝐹 (𝑟), onde 𝑝 e 𝑟 são pagar e receber, respectivamente.
A verificação de conflitos deve ocorrer antes da execução do contrato e, se for o caso, após sua negociação.
Com a representação de contratos em 𝐶𝐿 é possível realizar a verificação formal dessas especificações de várias maneiras. Algumas formas de se aplicar a 𝐶𝐿 são apresen-tadas a seguir:
Verificação formal de contratos. Uma abordagem proposta por Pace, Prisa-cariu e Schneider [15] especifica contratos em 𝐶𝐿 e transforma as fórmulas para uma variação do 𝜇-calculus denominada 𝐶𝜇. A técnica se baseia nos seguintes passos:
1. Traduzir o contrato convencional para 𝐶𝐿;
2. Traduzir sintaticamente as especificações em 𝐶𝐿 para 𝐶𝜇; 3. Obter manualmente um modelo de Kripke das fórmulas 𝐶𝜇;
4. Traduzir o modelo para a linguagem de uma ferramenta para model checking; 5. Realizar a verificação do modelo;
6. Interpretar o contra-exemplo, se existir, como uma cláusula 𝐶𝐿 e ajustar o contrato. Por se tratar de uma primeira aplicação da técnica, alguns passos são manuais, principal-mente a construção do modelo e a interpretação do contra-exemplo.
Detecção de conflitos em contratos. Com o objetivo de auxiliar o processo de negociação, essa abordagem proposta por Fenech [30] realiza a análise em um contrato em 𝐶𝐿 buscando conflitos normativos, onde uma cláusula sobrepõe outra, invalidando o contrato. A análise é realizada convertendo o contrato num autômato para procurar cláusulas conflitantes. O autômato obtido além de permitir a análise de conflitos ainda pode ser utilizado para o monitoramento do contrato. Essa abordagem realiza as seguintes tarefas:
1. Traduzir o contrato convencional para 𝐶𝐿;
30
3. Criar um autômato representando as cláusulas a partir das decomposições do con-trato;
4. Buscar nos estados do autômato os conflitos normativos.
5. Além dessas aplicações existem outras pesquisas realizadas com a 𝐶𝐿, como a tra-dução automática de contratos baseada em Processamento de Linguagem Natural [31] e técnicas para a modelagem visual de contratos [32].
2.3.2 BPMN Deôntico
O BPMN Deôntico (Deontic BPMN ) é uma extensão do BPMN com a lógica deôntica [33], destacando obrigações, permissões e alternativas, para melhorar a leitura do fluxo de processo. Dessa forma o Deontic BPMN permite reduzir o número de gateways e fluxos de sequência e identificar o que é obrigatório e o que é permitido mais facilmente. No BPMN Deôntico os operadores obrigação ("O"), permissão ("P") e alternativa ("X "), são destacados pelas cores vermelho, verde e amarelo, respectivamente (veja Fig.13.).
Uma alternativa não é um conceito deôntico independente, mas deriva-se da obri-gação e da permissão e pode ser expressa da seguinte forma:
𝑋(𝐴, 𝐵) = (𝑂(𝐴) ∨ 𝑂(𝐵)) ∧ ¬(𝑃 (𝐴) ∨ 𝑃 (𝐵))
As cores são uma das variáveis mais efetivas cognitivamente segundo Moody [34], porém elas devem ser usadas apenas como redundância para que a compreensão não seja afetada para daltônicos ou por impressões em preto e branco, conforme a Figura 13.
Figura 13 – BPMN Deôntico [2]
A transformação do BPMN para o BPMN Deôntico é definida como um sistema de grafo de atributo tipificado que inclui rótulos [2]. Primeiro é definido um caminho vazio Phi(𝜑). Um caminho é chamado de Phi-path ou caminho vazio, quando o fluxo de sequência conecta diretamente uma divergência em uma convergência oferecendo a possibilidade de não causar efeito nenhum, sendo assim, se um gateway permite essa possibilidade, ela não tem funcionalidade alguma e pode ser removida. Por exemplo:
𝐴 ∨ 𝜑 = 𝐴
𝐴 ∨ 𝐵 ∨ 𝜑 = 𝐴 ∨ 𝐵 𝐴 ∧ 𝐵 ∧ 𝜑 = 𝐴 ∧ 𝐵
Se um gateway paralelo tem apenas um caminho além do caminho vazio, remover esse caminho vazio permite remover os gateways ligados a ele. Todos os caminhos que seguem dele são obrigatórios[2]. Em contraste com o gateway paralelo, gateways exclusivos e inclusivos definem condições nos fluxos de sequência de saída, exceto pro fluxo padrão. A classificação deôntica depende do tipo de decisão. No contexto do BPMN deôntico,
gateways incondicionais denotam todos os gateways que o usuário pode decidir livremente.
Essas decisões são chamadas de User Choice e as tarefas subsequentes são permissões ou alternativas. Já os gateways condicionais são todos aqueles que os fluxos de saída são definidos por uma regra um estado ou um dado. Nesse caso, o usuário não é livre para escolher e as tarefas subsequentes são obrigatórias[2].
No BPMN, uma atividade permitida, bem como uma alternativa, podem ser ex-pressas com gateways incondicionais ou eventos. Se um fluxo de saída é um caminho vazio, então todos os caminhos são permissões. No entanto, se nenhum caminho é um caminho vazio, na maioria dos casos os fluxos de saída serão alternativas[2].
Um gateway exclusivo (XOR) oferece um mecanismo onde apenas um fluxo de saída pode ser escolhido. Se um dos caminhos é um caminho vazio, então todos os outros são permissões[2]:
𝐴 ⊕ 𝜑 = 𝑃 (𝐴)
𝐴 ⊕ 𝐵 ⊕ 𝜑 = 𝑃 (𝐴) ⊕ 𝑃 (𝐵)
Se existir apenas um caminho além do caminho vazio, então os gateways podem ser removidos como na Figura 14.
(a) (b)
Figura 14 – Remoção de Phi-Path de gateways exclusivos [2].
Se um gateway exclusivo não tem um caminho vazio, então todos os caminhos são alternativos, como mostra a Figura 15.
(a) (b)
Figura 15 – Gateways exclusivos sem Phi-Path [2].
Um gateway inclusivo (OR), onde pelo menos um caminho de saída é tomado, pode ser descrito como: 𝐴𝑂𝑅𝐵 ≡ (𝐴 ⊕ 𝐵) ⊕ (𝐴 ∧ 𝐵). Se um dos caminhos de saída é um caminho vazio, entao a estrutura (𝐴 ∨ 𝐵 ∨ 𝜑) pode ser transformada da seguinte forma[2]:
32
𝜑 ⊕ 𝐴 ⊕ 𝐵 ⊕ (𝐴 ∧ 𝐵) ⊕ (𝐴 ∧ 𝜑) ⊕ (𝐵 ∧ 𝜑) ⊕ (𝐴 ∧ 𝐵 ∧ 𝜑)
≡ 𝜑 ⊕ 𝐴 ⊕ 𝐵 ⊕ (𝐴 ∧ 𝐵) ≡ 𝑃 (𝐴 ⊕ 𝐵 ⊕ (𝐴 ∧ 𝐵)) ≡ 𝑃 (𝐴 ∨ 𝐵)
Se "A ou B"é permitido, então certamente pelo menos "A"ou "B"devem ser permi-tidos, então de 𝑃 (𝐴 ∨ 𝐵) segue 𝑃 (𝐴) ∨ 𝑃 (𝐵). Se não há nenhum caminho vazio de saída, então a estrutura 𝐴 ∨ 𝐵 ∨ 𝐶 pode ser transformada da seguinte forma[2]:
(𝑃 (𝐴) ∧ 𝑂(𝐴|¬𝐵 ∧ ¬𝐶)) ∨ (𝑃 (𝐵) ∧ 𝑂(𝐵)|¬𝐴 ∧ ¬𝐶) ∨ (𝑃 (𝐶) ∧ 𝑂(𝐶|¬𝐴 ∧ ¬𝐵) Essa definição requer previamente o conceito de lógica dinâmica (veja 2). A notação
𝐴|𝐵 significa que A só pode ser executado caso B tenha sido executado[2]. Demais
pré-condições podem ser concatenadas como por exemplo: 𝐴|𝐵 ∧ (𝐶 ∨ 𝐷).
Outra grande importância das pré-condições é no caso de gateways aninhados como na Figura 16. Nesse caso a tarefa B é permitida apenas se A foi executada, ou seja, A é uma pré-condição.
(a) (b)
Figura 16 – Gateways Aninhados [2].
Pré-condições são necessárias também para os casos onde a escolha não é livre para o usuário. Esse é o caso de quando condições ou eventos estão envolvidos. Na Figura 17 po-demos ver um gateway exclusivo com a decisão "Contém erros?"e dois caminhos de saída. O primeiro representa "Sim"e leva à tarefa "Corrigir erros", o segundo representa "Não"e nenhuma tarefa é executada (𝜑 caminho vazio). No entanto, a tarefa "Corrigir erros"não é permissiva, mas obrigatória caso a pré-condição "Contém erros"seja satisfeita e proibida caso contrário: [𝑂(𝐶𝑜𝑟𝑟𝑖𝑔𝑖𝑟𝐸𝑟𝑟𝑜𝑠|𝐶𝑜𝑛𝑡𝑒𝑚𝐸𝑟𝑟𝑜𝑠) ∧ 𝐹 (𝐶𝑜𝑟𝑟𝑖𝑔𝑖𝑟𝐸𝑟𝑟𝑜𝑠|¬𝐶𝑜𝑛𝑡𝑒𝑚𝐸𝑟𝑟𝑜𝑠)]. Além disso, especifica-se que tudo que não é explicitamente permitido é proibido. Por-tanto, a parte proibida pode ser omitida, como exibida na Figura 17.
(a) (b)
Figura 17 – Gateways condicionais [2].
Além disso, uma atividade pode ter múltiplas classificações deônticas como na Fi-gura 18. A tarefa A é endereçada por diferentes gateways. Dessa forma, a tarefa A é
mar-cada como alternativa e como permissiva (𝑋(𝐴) ∧ 𝑃 (𝐴)). Os gateways da estrutura per-missiva podem ser removidos se as pré-condições forem utilizadas (𝑋(𝐴|¬𝐵) ∧ 𝑃 (𝐴|𝐵)).
(a) (b)
34
3 UM MÉTODO DE VERIFICAÇÃO PARA BPM
O método proposto consiste em uma transformação de um contrato expresso em BPM, modelado com BPMN, para uma lógica de contratos baseada na CL com caracte-rísticas da lógica deôntica relativizada para especificar contratos multilaterais. O processo necessita que o formalismo adotado seja capaz de representar indivíduos envolvidos e suas relações, bem como as tarefas realizadas por cada um deles e para quem as tarefas são realizadas, além de outros aspectos como as tarefas realizadas, obrigações, permissões e proibições, paralelismo e sequenciamento.
3.1
Representação formal BPM
As regras de execução das ações em um contrato podem ser realizadas por indi-víduos específicos ou serem ações globais. A seguir é apresentada uma gramática formal para derivar contratos em BPMN de maneira precisa, evitando contratos mal-formados. A gramática tem fundamental importância para que as componentes de um contrato, como indivíduos, ações e suas relações, sejam expressas de maneira clara, permitindo uma transformação confiável para uma outra linguagem formal, a RCL.
1. 𝑃 ::= 𝑝𝑘(𝑋) | 𝑝𝑘(𝑋)𝑃 | 𝑝𝑘(𝜖)𝑃 | 𝑝𝑘(𝜖)
2. 𝑋 ::= 𝐺(𝑌 ) | 𝑡𝑎𝑠𝑘𝛽(𝑎) | 𝐺(𝑌 )𝑋 | 𝑡𝑎𝑠𝑘𝛽(𝑎)𝑋 | [𝛼𝛿]𝑋
3. 𝑌 ::= 𝑋, 𝑌 | 𝑋, 𝑋 | 𝑋, 𝜖 4. 𝐺 ::= 𝑔𝑝, 𝑔𝑖, 𝑔𝑥
Na sintaxe descrita, P é o estado inicial, 𝑝𝑘 é uma Pool, onde 𝑘 é o identificador
da Pool e fará parte do conjunto de indivíduos, I, do contrato. A 𝑡𝑎𝑠𝑘𝛽(𝑎) é uma tarefa 𝑎, onde 𝑎 é uma única ação que faz parte do conjunto de ações A; 𝛽 é a indicação de uma
associação entre as Pools, onde 𝛽 ⊆ I, que indica para qual, ou quais, indivíduos de I a ação será realizada; pode ser vazio, quando a ação é realizada para todos os indivíduos e um (𝛽) ou mais (𝛽1, 𝛽2, ...) para indicar para quais indivíduos do conjunto de indivíduos
a ação está sendo realizada. [𝛼] indica de qual, ou quais, tarefas realizadas por outros indivíduos um determinado elemento depende para ser realizado. 𝛼 representa uma ou mais tarefas (𝑎1𝛿, 𝑎2𝛿, ...) do conjunto A; 𝛿, representa o indivíduo responsável por realizar
a respectiva tarefa 𝛼 para o indivíduo 𝑘 em questão.
Na gramática os gateways podem ser de três tipos: 𝑔𝑝 é a representação de um
gateway paralelo; 𝑔𝑥 é a representação de um gateway exclusivo: e 𝑔𝑖 é a representação
O símbolo “,” indica uma ramificação no fluxo de sequência, caso contrário o elemento deve ser sequencial. Note que a gramática respeita os conceitos do BPM para não gerar contratos mal-formados. Por exemplo, pools vazias podem ser geradas, porém nenhum elemento pode ser colocado fora de uma pool, assim como não há possibilidade de gerar uma bifurcação a partir de tarefas, sem que seja através de um gateway, pois a bifurcação só é permitida através do não terminal Y e esse só é possível ser gerado dentro de um gateway, assim como um caminho vazio que também só pode existir dentro de um
gateway, uma vez que não faria sentido entre sequências de tarefas.
Em um contrato é possível gerar sequências de tarefas de tamanho variável, assim como ramificações de tamanhos variáveis, sendo essas, no mínimo duas, mesmo que uma delas vazia, uma vez que não há sentido em uma ramificação de um único caminho, pois seria o mesmo que uma sequência, ainda que com a possibilidade de gerar um aninhamento de gateways, cada um deles terá no mínimo uma bifurcação.
Cada Gateway se comporta de uma maneira equivalente a uma porta lógica. O
Gateway exclusivo se comporta como uma porta lógica XOR, se uma tarefa 𝛼 é
re-alizada nenhuma outra tarefa é rere-alizada. Na Figura 19 temos uma representação de
𝑔𝑥(𝑡𝑎𝑠𝑘(𝐴), 𝑡𝑎𝑠𝑘(𝐵), 𝑡𝑎𝑠𝑘(𝐶)).
Figura 19 – Gateway Exclusivo (XOR)
O Gateway Paralelo se comporta como uma porta lógica AND, onde todas as tarefas de sua ramificação deverão ser realizadas. Na Figura 20 temos uma representação de 𝑔𝑝(𝑡𝑎𝑠𝑘(𝐴), 𝑡𝑎𝑠𝑘(𝐵), 𝑡𝑎𝑠𝑘(𝐶)).
36
Figura 20 – Gateway Paralelo (AND)
O Gateway Inclusivo se comporta como uma porta lógica OR, ou seja, ao me-nos uma tarefa deve ser realizada, podendo ser uma ou mais. Na Figura 21 temos uma representação de 𝑔𝑖(𝑡𝑎𝑠𝑘(𝐴), 𝑡𝑎𝑠𝑘(𝐵), 𝑡𝑎𝑠𝑘(𝐶)).
Figura 21 – Gateway Inclusivo (OR)
Os Gateways permissivos têm um caminho vazio 𝜖, podendo assim não realizar nenhuma tarefa. As demais características deles se mantém as mesmas. Na Figura 22 temos uma representação de 𝑔𝑥(𝑡𝑎𝑠𝑘(𝐴), 𝑡𝑎𝑠𝑘(𝐵), 𝜖).
Figura 22 – Gateway Exclusivo Permissivo P(XOR)
No Gateway Inclusivo Permissivo qualquer execução é permitida, uma vez que ele pode realizar nenhuma, uma, ou mais tarefas. Na Figura 23 temos uma representação de
𝑔𝑖(𝑡𝑎𝑠𝑘(𝐴), 𝑡𝑎𝑠𝑘(𝐵), 𝜖).
Figura 23 – Gateway Inclusivo Permissivo P(OR)
No Gateway Paralelo todas as tarefas serão realizadas. Por isso, o caminho vazio
𝜖 é inútil, e por consequência pode ser ignorado ou retirado.
Um exemplo de derivação de contrato, com o conjunto de indivíduos I = {𝑘, 𝑤, 𝑧}, usando a gramática proposta é apresentada a seguir:
𝑝𝑘(𝑔𝑝(𝑔𝑖(𝑡𝑎𝑠𝑘(𝑏), 𝑡𝑎𝑠𝑘(𝑐)), 𝑡𝑎𝑠𝑘(𝑑), 𝑡𝑎𝑠𝑘(𝑒))𝑔𝑥(𝑡𝑎𝑠𝑘(𝑓 )𝑡𝑎𝑠𝑘(𝑔), 𝜖)𝑡𝑎𝑠𝑘𝑤,𝑧(𝑎))𝑝𝑤(𝑡𝑎𝑠𝑘𝑘(𝑎))𝑝𝑧(𝜖)
38
Figura 24 – Exemplo Derivação
3.2
Transformação do BPM em RLC
Esta subseção apresenta as regras de transformação da gramática BPM proposta, para uma fórmula RCL e discute alguns aspectos que envolvem o mapeamento das regras. O BPM define claramente quais tarefas devem, ou podem, ser executadas, de quem, para quem e quais execuções dependem de outras tarefas. No entanto, como visto na sub-seção 2.3.2, as ações proibitivas ficam implícitas nesse modelo, uma vez que, se a tarefa não está explicitamente especificada, esta então não pode ou não deve ocorrer. Sendo assim, nesta proposta não incluímos a modelagem de proibições em BPM e consequentemente sua transformação para RCL. Para a modelagem dessas restrições foram consideradas as dependências entre tarefas e garantir que ações proibitivas não sejam executadas no contrato.
Para que uma transformação de BPM para RCL seja bem sucedida ela deve seguir determinadas regras e ajustes. Alguns elementos se traduzem explicitamente, no entanto, outros podem surgir de maneira mais implícita, como alguns operadores AND por
exem-plo, que surgem a partir do fluxo de execução de tarefas e a definição dessa ordem que é definido a partir das dependências e da sequência de fluxo.
Uma tarefa deve ser traduzida em uma ação a ser realizada, podendo ser uma Obrigação ou uma Permissão. Se a tarefa em questão for a primeira tarefa de qualquer uma das ramificações de um gateway permissivo, então essa tarefa será uma Permissão, caso contrário, ela será uma Obrigação. A variável 𝛽 determina para qual, ou quais, indivíduos essa tarefa está sendo realizada, e o indivíduo que a realiza é definido pela pool a qual esta pertence.
𝑝𝑖(𝑡𝑎𝑠𝑘𝑗(𝑎)) ≡𝑖y𝑗𝑂(𝑎) 𝑝𝑖(𝑔𝑖(𝑡𝑎𝑠𝑘𝑗(𝑎), 𝜖)) ≡ 𝑖y𝑗𝑃 (𝑎)
Os Gateways influenciam tanto na sequência de execução, quanto no operador lógico entre as tarefas:
1. O gateway inclusivo conecta as tarefas por meio do operador lógico OR:
𝑝𝑖(𝑔𝑖(𝑡𝑎𝑠𝑘𝑗(𝑎), 𝑡𝑎𝑠𝑘𝑗(𝑏))) ≡𝑖y𝑗𝑂(𝑎)∨ 𝑖y𝑗𝑂(𝑏) 𝑝𝑖(𝑔𝑖(𝑡𝑎𝑠𝑘𝑗(𝑎), 𝑡𝑎𝑠𝑘𝑗(𝑏), 𝜖)) ≡𝑖y𝑗𝑃 (𝑎)∨𝑖y𝑗𝑃 (𝑏)
2. O gateway paralelo conecta as tarefas por meio do operador lógico AND:
𝑝𝑖(𝑔𝑝(𝑡𝑎𝑠𝑘𝑗(𝑎), 𝑡𝑎𝑠𝑘𝑗(𝑏))) ≡𝑖y𝑗𝑂(𝑎)∧𝑖y𝑗𝑂(𝑏)
3. O gateway exclusivo conecta as tarefas por meio do operador lógico XOR:
𝑝𝑖(𝑔𝑥(𝑡𝑎𝑠𝑘𝑗(𝑎), 𝑡𝑎𝑠𝑘𝑗(𝑏))) ≡𝑖y𝑗𝑂(𝑎)⊕ 𝑖y𝑗𝑂(𝑏) 𝑝𝑖(𝑔𝑥(𝑡𝑎𝑠𝑘𝑗(𝑎), 𝑡𝑎𝑠𝑘𝑗(𝑏), 𝜖)) ≡𝑖y𝑗𝑃 (𝑎)⊕𝑖y𝑗𝑃 (𝑏)
As demais tarefas realizadas são conectadas pelo operador AND, mesmo que de Pools separadas,
𝑃𝑖(𝑔𝑥(𝑡𝑎𝑠𝑘𝑗(𝑎), 𝑡𝑎𝑠𝑘(𝑏))) 𝑃𝑗(𝑡𝑎𝑠𝑘𝑖(𝑐)) ≡ (𝑖y𝑗𝑂(𝑎)⊕ 𝑖y𝑗𝑂(𝑏)) ∧𝑗y𝑖𝑂(𝑐).
As tarefas dependentes de outras tarefas são representadas pelos operadores di-nâmicos da RCL e são também conectados pelo operador AND. O símbolo 𝛿 representa quem executou a tarefa e a Pool representa para quem foi executada,
𝑃𝑖(𝑡𝑎𝑠𝑘(𝑎)𝑡𝑎𝑠𝑘(𝑏)) ≡ 𝑂(𝑎) ∧ [𝑖𝑎](𝑂(𝑏)),
𝑃𝑖(𝑡𝑎𝑠𝑘(𝑎)𝑡𝑎𝑠𝑘𝑗(𝑏))𝑃𝑗([𝑏𝑖]𝑡𝑎𝑠𝑘𝑖(𝑐)𝑔𝑥(𝑡𝑎𝑠𝑘𝑖(𝑑), 𝑡𝑎𝑠𝑘(𝑒))) ≡ 𝑖𝑂(𝑎)∧ [𝑖𝑎](𝑖y𝑗𝑂(𝑏)∧
[𝑖y𝑗𝑏](𝑗y𝑖𝑂(𝑐) ∧ [𝑗𝑐](𝑗y𝑖𝑂(𝑑)⊕𝑗y𝑖𝑂(𝑒)))).
Para definir a ordem de composição da fórmula, deve primeiro separar as pools e definir um conjunto P da primeira tarefa de cada pool, caso a primeira tarefa de uma pool seja um gateway, todas as tarefas deste gateway devem fazer parte do conjunto. Isso é feito
40
porque as tarefas subsequentes são, ao menos, dependentes das anteriores. Dentro desse conjunto definido, pode-se escolher qualquer uma das tarefas para dar início ao processo de definir a ordem de execução.
Ao escolher uma das tarefas observe se esta depende de alguma outra tarefa, caso dependa, empilha e procura realizar a tarefa da qual ela depende, e assim sucessivamente; caso não dependa, essa tarefa é marcada como realizada e procura por outra tarefa dentro do conjunto, até que todas sejam realizadas. Se após esse processo ainda existirem tarefas não realizadas no conjunto de tarefas A, inicia-se novamente o processo de criação do conjunto P, excluindo as tarefas já realizadas. Após a execução de todas as tarefas, obtém-se a obtém-sequência possível de execução. Seguindo essa obtém-sequência, ao executar uma tarefa, deve executar todas as tarefas que dependem diretamente desta, fazendo as respectivas transformações para RCL.
3.3
Estudo de caso
O estudo de caso apresentado neste trabalho aborda um modelo de negócio para venda de produtos via Internet, baseado no trabalho do Wellington [3]. Os envolvidos no contrato, além do comprador e vendedor, são instituições financeiras que trabalham como mediadoras dos pagamentos entre os indivíduos e transportadoras, responsáveis pelas entregas.
O contrato deste estudo de caso é apresentado na Figura 25, onde são descritas as transições e interações entre as partes. A transação é, basicamente, composta por um comprador que realiza uma compra de um vendedor, um banco que realiza a intermediação dos pagamentos e transações financeiras e uma transportadora que se encarrega da entrega do produto ao comprador e notificações de entrega ao banco. Além disso, existem algumas regras internas tanto do banco, quanto da transportadora.
Esse contrato apresentado é um contrato multilateral, ou seja, que modela relaci-onamentos entre vários indivíduos simultaneamente e não pode ser dividido em contratos bilaterais, que modelam relacionamentos apenas entre dois indivíduos, sem que informa-ções relevantes sobre o modelo de negócio sejam perdidas [3].
A seguir são apresentados o contrato, a geração do contrato em BPM pela gramá-tica proposta neste capitulo, a transformação desta em RCL, conforme os passos descritos, a verificação pela ferramenta proposta no trabalho do Wellington e uma breve comparação com os resultados apresentados pelo mesmo.
Figura 25 – Contrato de compra e venda.
Para facilitar a visualização, organização e evitar poluição visual, identificaremos e renomearemos os indivíduos e as tarefas conforme a Tabela 1.
42 Indivíduos Representação Comprador (buyer ) b Vendedor (seller ) s Banco (bank) k Transportadora (carrier ) c Tarefas Representação
Comprar produto (buyProduct) A
Pagar produto (payProduct) B
Notificar recebimento do produto (notifyProductReceipt) C Notificar pagamento do produto (notifyProductPayment) D
Pagar produto (payProduct) E
Pagar valor do frete (payShippingCosts) F
Enviar produto (sendProduct) G
Pagar valor do frete (payShippingCosts) H
Liberar pagamento do frete (liberateShippingCosts) I
Entregar produto (deliverProduct) J
Notificar entrega do produto (notifyProductDelivery) K Tabela 1 – Tabela de indivíduos e tarefas.
Seguindo os conceitos de formulação de um BPM, os conceitos formais apresenta-dos na gramática proposta na seção 3.1, deriva-se o BPM para o contrato 25 até obter o resultado 𝑃𝑏(𝑡𝑎𝑠𝑘𝑠(𝐴)𝑡𝑎𝑠𝑘𝑘(𝐵)[𝐽𝑐]𝑡𝑎𝑠𝑘𝑘(𝐶))𝑃𝑘([𝐵𝑏]𝑡𝑎𝑠𝑘𝑠(𝐷)𝐺([𝐶𝑏]
𝑡𝑎𝑠𝑘𝑠(𝐸), [𝐻𝑠, 𝐼𝑠]𝑡𝑎𝑠𝑘𝑐(𝐹 )))𝑃𝑠([𝐷𝑘]𝐺(𝑡𝑎𝑠𝑘𝑐(𝐺), 𝑡𝑎𝑠𝑘𝑘(𝐻))[𝐾𝑐]𝑡𝑎𝑠𝑘𝑘(𝐼))𝑃𝑐([𝐺𝑠, 𝐻𝑠]𝑡𝑎𝑠𝑘𝑏
(𝐽 )𝑡𝑎𝑠𝑘𝑠(𝐾))
Pode-se observar que para garantia das cláusulas 11 e 12 foram necessárias as adições das dependências [𝐼𝑠] e [𝐻𝑠]. A gramática permite essa adição na regra de derivação
2 apresentada em 3.1, essas alterações se fazem necessárias para garantir a dependência causada pela proibição e na cláusula 10 não houve alteração, pois a regra já foi satisfeita por outra derivação.
Após obter o resultado 𝑃𝑏(𝑡𝑎𝑠𝑘𝑠(𝐴)𝑡𝑎𝑠𝑘𝑘(𝐵)[𝐽𝑐]𝑡𝑎𝑠𝑘𝑘(𝐶))𝑃𝑘([𝐵𝑏]𝑡𝑎𝑠𝑘𝑠(𝐷)𝐺([𝐶𝑏] 𝑡𝑎𝑠𝑘𝑠(𝐸), [𝐻𝑠, 𝐼𝑠]𝑡𝑎𝑠𝑘𝑐(𝐹 )))𝑃𝑠([𝐷𝑘]𝐺(𝑡𝑎𝑠𝑘𝑐(𝐺), 𝑡𝑎𝑠𝑘𝑘(𝐻))[𝐾𝑐]𝑡𝑎𝑠𝑘𝑘(𝐼))𝑃𝑐([𝐺𝑠, 𝐻𝑠]𝑡𝑎𝑠𝑘𝑏
(𝐽 )𝑡𝑎𝑠𝑘𝑠(𝐾)) separa-se as pools identificando as primeiras tarefas de cada uma, formando
o conjunto de tarefas e então é feita a análise da ordem de composição da fórmula.
𝑃𝑏(𝑡𝑎𝑠𝑘𝑠(𝐴)𝑡𝑎𝑠𝑘𝑘(𝐵)[𝐽𝑐]𝑡𝑎𝑠𝑘𝑘(𝐶))
𝑃𝑘([𝐵𝑏]𝑡𝑎𝑠𝑘𝑠(𝐷)𝐺([𝐶𝑏]𝑡𝑎𝑠𝑘𝑠(𝐸), [𝐻𝑠, 𝐼𝑠]𝑡𝑎𝑠𝑘𝑐(𝐹 ))) 𝑃𝑠([𝐷𝑘]𝐺(𝑡𝑎𝑠𝑘𝑐(𝐺), 𝑡𝑎𝑠𝑘𝑘(𝐻))[𝐾𝑐]𝑡𝑎𝑠𝑘𝑘(𝐼))
𝑃𝑐([𝐺𝑠, 𝐻𝑠]𝑡𝑎𝑠𝑘𝑏(𝐽 )𝑡𝑎𝑠𝑘𝑠(𝐾))
Obtendo como resultado o conjunto de tarefas (A,B,C,D,E,F,G,H,I,J,K).
