HENRIQUE GONÇALVES RODRIGUES MEDINA
VERIFICAÇÃO DE CONTRATOS UTILIZANDO BUSINESS
PROCESS MANAGEMENT
LONDRINA 2018
HENRIQUE GONÇALVES RODRIGUES MEDINA
VERIFICAÇÃO DE CONTRATOS UTILIZANDO BUSINESS
PROCESS MANAGEMENT
Versão Preliminar de Trabalho de Conclusão de Curso apresentado ao curso de Bachare-lado em Ciência da Computação da Univer-sidade Estadual de Londrina para obtenção do título de Bacharel em Ciência da Compu-tação.
Orientador: Prof(a). Dr(a). Adilson Luiz Bonifacio
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.
HENRIQUE GONÇALVES RODRIGUES MEDINA
VERIFICAÇÃO DE CONTRATOS UTILIZANDO BUSINESS
PROCESS MANAGEMENT
Versão Preliminar de Trabalho de Conclusão de Curso apresentado ao curso de Bachare-lado em Ciência da Computação da Univer-sidade Estadual de Londrina para obtenção do título de Bacharel em Ciência da Compu-tação.
BANCA EXAMINADORA
Orientador: Prof(a). Dr(a). Adilson Luiz Bonifacio
Universidade Estadual de Londrina
Prof. Dr. Segundo Membro da Banca Universidade/Instituição do Segundo Membro da Banca – Sigla instituição
Prof. Dr. Terceiro Membro da Banca Universidade/Instituição do Terceiro Membro da Banca – Sigla instituição
Prof. Ms. Quarto Membro da Banca Universidade/Instituição do Quarto Membro da Banca – Sigla instituição
Este trabalho é dedicado à geração que segue em frente com nada a não ser café e três horas de sono.
“Não olhe para trás, você não vai naquela direção.
MEDINA, H.. VERIFICAÇÃO DE CONTRATOS UTILIZANDO BUSINESS PROCESS MANAGEMENT . 2018. 42f. Trabalho de Conclusão de Curso – Versão Preliminar (Bacharelado em Ciência da Computação) – Universidade Estadual de Lon-drina, LonLon-drina, 2018.
RESUMO
Esta pesquisa propõe a integração entre o conceito de gestão de negócios do Business
Pro-cess Management (BPM) e a formalização e verificação de contratos legais utilizando a
linguagem de contratos relativizada (RCL), para facilitar e, possivelmente, otimizar estes processos. Serão estudados modelos e notações para os processos de negócios, representa-ção formal de contratos e a possibilidade de customizar estes modelos e notações para o problema de contratos legais, propondo uma transformação do BPM para a RCL.
Palavras-chave: BPM, BPMN, Contratos, Verificação de contratos, Gerenciamento de
MEDINA, H.. Contract verification using Business Process Management. 2018. 42p. Final Project – Draft Version (Bachelor of Science in Computer Science) – State University of Londrina, Londrina, 2018.
ABSTRACT
This research proposes the integration between the concept of business process manage-ment (BPM) and the formalization and verification of legal contracts using relativized contract language (RCL) to simplify and, possibly, optimize these processes. Models and notations used on business processes management, formal representation for contracts and the possibility of customizing these models for legal contracts problems, will be explored in this study, to propose a transformation from BPM to RCL.
Keywords: BPM, BPMN, Contratos, Contract verification, Business Process
LISTA DE ILUSTRAÇÕES
Figura 1 – Eventos. . . 15
Figura 2 – Atividade. . . 15
Figura 3 – Gateway. . . 16
Figura 4 – Gateway Paralelo . . . 16
Figura 5 – Gateway Exclusivo . . . 17
Figura 6 – Gateway Inclusivo . . . 17
Figura 7 – Fluxo de sequência. . . 18
Figura 8 – Fluxo de mensagens. . . 18
Figura 9 – Associação. . . 18
Figura 10 – Piscina. . . 19
Figura 11 – Raias. . . 19
Figura 12 – Pizza Example[8] . . . 20
Figura 13 – BPMN Deôntico [32] . . . 30
Figura 14 – Remoção de Phi-Path de gateways exclusivos [32]. . . . 31
Figura 15 – Gateways exclusivos sem Phi-Path [32]. . . . 31
Figura 16 – Gateways Aninhados [32]. . . . 31
Figura 17 – Gateways condicionais [32]. . . . 32
Figura 18 – Classificações deônticas multiplas [32]. . . 32
Figura 19 – Exemplo Derivação . . . 34
Figura 20 – Gateway Exclusivo (XOR) . . . 35
Figura 21 – Gateway Paralelo (AND) . . . 35
Figura 22 – Gateway Inclusivo (OR) . . . 36
Figura 23 – Gateway Exclusivo Permissive P(XOR) . . . 36
Figura 24 – Gateway Paralelo Permissive P(AND) . . . 37
LISTA DE ABREVIATURAS E SIGLAS
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 BPMN - Business Process Modeling Notation . . . . 14
2.1.2 Exemplo . . . 19
2.2 Contratos Legais . . . . 21
2.2.1 Formalização de contratos . . . 21
2.2.2 Lógicas para contratos . . . 21
2.2.3 A Linguagem de contratos (𝐶𝐿 - Contract Language) . . . . 25
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 . . . 29
3 UM MÉTODO DE VERIFICAÇÃO PARA BPM . . . . 33
4 CONCLUSÃO . . . . 38
REFERÊNCIAS . . . . 39
APÊNDICES
41
13
1 INTRODUÇÃO
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 [10]. Este trabalho visa estudar a possibilidade de utilizar o conceito do BPM na formalização e verificação 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 vontades dos envolvidos[2]. Um dos grandes problemas em contratos são ambiguidades nas cláusulas contratuais, que podem levar à rescisão contratual e à desentendimentos entre as partes envolvidas. Estes problemas motivam a formalização dos contratos com embasamento matemático, para que seja possível a validação matemática e computacional[4].
Para compreendermos a formalização dos contratos é necessário o entendimento das representações formais de sistemas, como as lógicas modais, lógica dinâmica proposici-onal, lógica deôntica e a relativização da lógica deôntica. Neste estudo abordaremos, para cada uma delas, as suas principais características, comportamentos, operadores, sintaxe e equivalências, e também a linguagem de contratos (CL - Contract Language) e a lingua-gem de contratos relativizada (RCL) [4] e a verificação formal de contratos. Veremos os principais conceitos para modelagem do BPM, a sintaxe e o significado de seus principais componentes, como objetos de fluxo, objetos de conexão, raias (swim lanes) e as piscinas (pools). Já existem trabalhos que abordam o tema de formalização de contratos [4], no entanto, não temos conhecimento de trabalhos que façam uma relação do BPM para a linguagem de contratos relativizada. Este estudo pode trazer uma via mais simples que leva de contratos formais em alto nível à linguagem de contratos relativizada, que permite sua validação matemática.
Na seção seguinte veremos os conceitos do BPM e de sua principal notação, o BPMN. Em seguida, veremos os conceitos de contratos, formalização, as lógicas que fun-damentam a linguagem de contratos e a sua relativização e a violação de contratos. Por fim, será apresentado os objetivos do trabalho, os métodos utilizados, o cronograma da sua execução e as possíveis contribuições e resultados esperados.
14
2 FUNDAMENTAÇÃO TEÓRICO-METODOLÓGICA
Esta seção apresenta os conceitos relacionados a contratos, BPM, modelagem e notações do BPM e suas características, formalização e lógicas utilizadas nas representação de contratos.
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 dos processos de negócios, utiliza um conjunto de elementos estru-turados 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, dia-gramas de controle de fluxo, diagrama PERT, entre outros, emergiram desde o começo do século 20 [30]. 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 em seu artigo ’Business
Process Modelling Improves Administrative Control’. —-Williams, S. (1967) "Business Process Modeling Improves Administrative Control,"In: Automation. December, 1967, pp. 44 - 50.—- No entanto o termo só se tornou popular na década de 1990 [29], quando as
primeiras ferramentas visuais para modelagem e implementação do processo de negócio foram apresentadas. Na sub-seção seguinte serão apresentados os componentes do BPM juntamente com sua principal notação gráfica.
2.1.1 BPMN - Business Process Modeling Notation
A modelagem é uma etapa muito importante pois é nela que os processos são re-presentados e podem ser feitas alterações para otimização. Assim como o UML (Unified
Modeling Language), temos o BPMN (Business Process Modeling Notation) como 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[35]. A versão 2.0 do BPMN foi lançada em janeiro de 2011[34], ponto em que o nome foi adaptado para Business Process Mo-del e 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 proces-sos e as mensagens que fluem entre diferentes participantes do processo em um conjunto relacionado de atividades [34]. Os componentes do BPM são chamados de elementos, na
15
modelagem BPMN estes elementos 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 [10]. Eles podem ser separados em três áreas: 𝑒𝑣𝑒𝑛𝑡𝑜𝑠, 𝑎𝑡𝑖𝑣𝑖𝑑𝑎𝑑𝑒𝑠 e 𝑔𝑎𝑡𝑒𝑤𝑎𝑦𝑠.
Um evento é uma ocorrência durante o fluxo de um processo, são usados também para representar o início e o fim do processo. Esses eventos afetam o fluxo do modelo e geralmente são uma causa (𝑡𝑟𝑖𝑔𝑔𝑒𝑟) ou um efeito (𝑟𝑒𝑠𝑢𝑙𝑡) [10]. Eventos podem ser customizados para representar detalhes específicos do processo, como o envio de uma mensagem por exemplo[7].
Figura 1 – Eventos.
Atividades descrevem o tipo de trabalho que está sendo executado em uma de-terminada instância[7]. Uma atividade é um termo genérico para tarefas que são executadas no processo[10].
Figura 2 – Atividade.
O fluxo do processo pode sofrer divergências, para representar a tarefas simultâneas ou paralelas, e convergências durante sua execução para representar dependência de tarefas anteriores. Gateways controlam a divergência e a convergência de fluxos de sequência no processo[7]. Eles determinam ramificações, separam e recombinam fluxos em um diagrama.
16
Figura 3 – Gateway.
Marcações internas representam o tipo de comportamento de controle do gateway [10], 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 em cada fluxo de saída. Se existem tokens excedentes em um fluxo de entrada, esses tokens permanecem após a execução do gateway [10].
Figura 4 – Gateway Paralelo
Gateway Exclusivo
No gateway exclusivo cada ativação do gateway leva a ativação de uma única rami-ficação, 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, 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. Se nenhuma das condições forem avaliadas como verdadeiras o token é passado para o fluxo de sequência padrão (default), caso este não exista, uma exceção é enviada [10].
Gateway Inclusivo
O gateway inclusivo 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.
17
Figura 5 – Gateway Exclusivo
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 token será produzido em alguns dos fluxos de sequência de saída. Para determinar o fluxo de sequência de saída 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[10].
Figura 6 – Gateway Inclusivo
2. Objetos de conexão (𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑛𝑔 𝑂𝑏𝑗𝑒𝑐𝑡𝑠)
Objetos de conexão [10] 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, são representados graficamente como linhas direcionadas e contínuas. Os fluxos de mensagens mostram as mensagens entre dois participantes que estão preparados para enviar e recebê-las, são representados graficamente como linhas direcionadas e descontínuas. Associações são usadas para ligar informações e artefatos com outros elementos gráficos do modelo, são repre-sentados graficamente como linhas não direcionadas e descontinuas.
18
Figura 7 – Fluxo de sequência.
Figura 8 – Fluxo de mensagens.
Figura 9 – Associação.
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 so-bre 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 [10]. 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 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 es-pecíficos que realizam um sub-conjunto de tarefas do processo. São usadas para organizar e categorizar atividades [10]. São usadas para organizar um diagrama no BPMN. Elas agrupam objetos facilitando a visualização de cada aspecto do dia-grama e, além disso, podem mostrar atrasos, ineficiências, bem como, o responsável por cada tarefa do processo[7].
19
Figura 10 – Piscina.
Figura 11 – Raias.
5. Artefatos (𝐴𝑟𝑡𝑖𝑓 𝑎𝑐𝑡𝑠)
Artefatos representam informações relevantes para o modelo, mas não para ele-mentos individuais do processo[7]. Elas são Anotações e Grupos.
Anotações permitem descrever fluxos adicionais do modelo ou notação por quem está modelando, são anexadas utilizando associações [10].
Grupos são utilizados para agrupar tarefas ou processos que são de uma mesma categoria. Este agrupamento não influencia no fluxo de sequência e podem ser usa-dos para propósitos de análise ou documentação [10].
2.1.2 Exemplo
Esta seção apresenta um exemplo de uma modelagem simples para um pedido e entrega de pizza. Este é um exemplo simples que demonstra a interação entre duas partes distintas, cliente e vendedor, que estão divididos em duas piscinas ou Pool.
20
Figura 12 – Pizza Example[8]
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, segue o processo 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 segue 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
21
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 destas partes sobre um determinado assunto, geralmente de natureza patrimonial[2].
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á abordagens 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 [15], verificação de arquiteturas baseadas em serviços e em nuvem [16], 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 [1], 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 [3]. 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 [4].
2.2.2 Lógicas para contratos
A linguagem para contratos, denominada 𝐶𝐿 [21], foi desenvolvida para a represen-tação formal de contratos legais, serviços web, interfaces e protocolos de comunicação[4]. 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 [14], e na lógica dinâmica proposicional para representar as ações num sistema [20]. Para compreendermos melhor a linguagem de contratos, precisaremos primeiro entender as lógicas por trás dela, portanto voltaremos a falar sobre a 𝐶𝐿 na subseção 2.2.3. Veremos 4 das lógicas que fundamentam a linguagem de contratos:
22
O termo lógica modal descreve um grande número de lógicas na literatura que possuem características modais[4]. 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[18].
A lógica modal é baseada nos conectivos da lógica proposicional: negação ¬; con-junção ∧; discon-junção ∨; condicional −→; e bicondicional ←→. Além dos operadores proposicionais, são acrescido dos operadores modais[19]:
𝑝, 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. Composta basicamente pelos operadores de necessidade e possibilidade [] e ⟨⟩, respectivamente[11].
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, 𝑝 deve ser verdadeiro após 𝑎[11].
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 𝑎[11].
Equivalências[11]: [𝑎]𝑝 ≡ ¬⟨𝑎⟩¬𝑝 ⟨𝑎⟩𝑝 ≡ ¬[𝑎]¬𝑝
Esta 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 este 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 das, seja 𝑎 ou 𝑏. O componente 𝑎; 𝑏, representa sequência, e é realizado efetuando primeiro 𝑎 e depois 𝑏, 𝑎⋆, representa iteração, dado pela
23
execução de 𝑎 zero ou mais vezes, sequencialmente. O componente 𝑎?, representa teste lógico, se 𝑎 se verifica então prossiga, se 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 programa 𝑎 ou o programa 𝑏 são executados a proposição 𝑝 é verdadeira no estado seguinte[4].
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 estas normas. Os conceitos normativos incluem deveres, possibilidades e impossibilidades, representados respectivamente, pela obrigação, permissão e proibição de ações [9].
Operadores: 𝑂:Obrigatório 𝐹 :Proibido 𝑃 :Permitido Tabela de equivalências[9]: 𝑂𝑝 ≡ 𝐹 ¬𝑝 ≡ ¬𝑃 ¬𝑝 𝑂¬𝑝 ≡ 𝐹 𝑝 ≡ ¬𝑃 𝑝 ¬𝑂¬𝑝 ≡ ¬𝐹 𝑝 ≡ 𝑃 𝑝 ¬𝑂𝑝 ≡ ¬𝐹 ¬𝑝 ≡ 𝑃 ¬𝑝
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 (𝑃 ):
𝑂𝑝 ≡ 𝐹 ¬𝑝 ≡ ¬𝑃 ¬𝑝
24
A relativização da lógica deôntica[12] é 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 𝑎, esta 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 [27].
Neste 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 [12] 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 [27].
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 menciona o indivíduo vinculado;
Modalidades pessoais (ou relativizadas): modalidade relacionada a um único indi-víduo; e
Modalidade direcionada: quando a modalidade especifica o indivíduo que deve exe-cutar a ação e o indivíduo beneficiado (ou requerente) desta 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 𝑎 [12].
Esta relativização possibilita expressar situações mais detalhadas com a lógica deôn-tica, como por exemplo, num comércio eletrônico, onde o vendedor 𝑖 é obrigado a
25
𝑒𝑛𝑡𝑟𝑒𝑔𝑎𝑟 um produto e o cliente 𝑗 é obrigado a 𝑝𝑎𝑔𝑎𝑟 por esse produto. Essa
sen-tença pode ser descrita por 𝑖𝑂(𝑒𝑛𝑡𝑟𝑒𝑔𝑎𝑟) ∧ 𝑗𝑂(𝑝𝑎𝑔𝑎𝑟)[4].
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 indivíduo, chamado de contra-parte ou requerente [28].
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 𝑖. Nesta construção fica clara que as sentenças convergem para a mesma situação:
𝑖𝑂(𝑒𝑛𝑡𝑟𝑒𝑔𝑎𝑟) ∧ 𝑗𝑂(𝑟𝑒𝑐𝑒𝑏𝑒𝑟)[4].
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 a segunda 𝑂𝑗(𝑎) expressa que o indivíduo 𝑗 deve receber a execução da ação 𝑎. A sentença 𝑖𝑂𝑗(𝑎) representa uma obrigação direcionada [12].
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 [4].
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[22].
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 exem-plo "o produto foi entregue"ou "o banco repassou o valor do frete"[4].
A sintaxe da 𝐶𝐿 é definida pela gramatica a seguir, onde 𝐶 é um contrato ou uma de suas cláusulas:
𝐶 ::= 𝜑 | 𝑂𝐶(𝛼) | 𝑃 (𝛼) | 𝐹𝐶(𝛼) | 𝐶 ∧ 𝐶 | [𝛽]𝐶 | ⊥
𝛼 ::= 0 | 1 | 𝛼 × 𝛼 | 𝛼 · 𝛼 | 𝛼 + 𝛼
26
𝜙 ::= 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 [4].
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 [16].
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 [23].
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
27
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[4].
2.2.4 A Linguagem de contratos relativizada (𝑅𝐶𝐿)
A sintaxe relativizada da 𝐶𝐿, chamada de 𝑅𝐶𝐿, proposta por Wellington A. Della Mura [4] como um método para detecção de conflitos em contratos multilaterais é baseada na 𝐶𝐿 com características da lógica deôntica relativizada [4].
A relativização proposta por Herrestad e Krogh [12] é estendida para os operadores 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 𝑑 [4].
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 𝑗 [4].
A sintaxe relativizada da 𝐶𝐿, chamada de 𝑅𝐶𝐿, é descrita conforme a gramática:
𝐶 ::= 𝐶𝑂 | 𝐶𝑃 | 𝐶𝐹 | 𝐶 ∧ 𝐶 | 𝐶𝐷 | ⊤ | ⊥ 𝐶𝑂 ::= 𝑂𝐶′(𝛼) | 𝑖𝑂𝐶′(𝛼) |𝑖y𝑗𝑂𝐶′(𝛼) | 𝐶𝑂⊕ 𝐶𝑂 𝐶𝑃 ::= 𝑃 (𝛼) |𝑖𝑃 (𝛼) | 𝑖y𝑗𝑃 (𝛼) | 𝐶𝑃 ⊕ 𝐶𝑃 𝐶𝐹 ::= 𝐹𝐶′(𝛼) |𝑖𝐹𝐶′(𝛼) |𝑖y𝑗𝐹𝐶′(𝛼) | 𝐶𝐹 ∨ 𝐶𝐷𝐶𝐹 𝐶𝐷 ::= [𝛽]𝐶 | 𝑖[𝛽]𝐶 | 𝑖y𝑗[𝛽]𝐶 𝛼 ::= 0 | 1 | 𝛼 | 𝛼 × 𝛼 | 𝛼 · 𝛼 | 𝛼 + 𝛼 𝛽 ::= 0 | 1 | 𝛼 | 𝛽 × 𝛽 | 𝛽 · 𝛽 | 𝛽 + 𝛽 | 𝛽 | 𝛽*
28
𝐶𝐹, e operadores dinâmicos 𝐶𝐷. Os operadores lógicos de conjunção, ∧ , disjunção
ex-clusiva, ⊕ 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 pe-nalidade 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 [5].
2.3.1 Verificação formal de contratos
Algumas das técnicas mais comuns na verificação de contratos eletrônicos são[4]: 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 [5]. Esta 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 destas 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, Prisacariu e Schneider [16] 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 𝐶𝜇;
29
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, esta abordagem proposta por Fenech [5] realiza a análise num contrato em 𝐶𝐿 buscando conflitos normativos, onde uma cláusula sobrepõe outra, invalidando o contrato. A análise é realizada com a semântica de traces, 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 𝐶𝐿;
2. Obter as decomposições das cláusulas do contrato;
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 baseado processamento de linguagem natural [25] e técnicas para a modelagem visual de contratos [26].
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 expressado da seguinte forma:
𝑋(𝐴, 𝐵) = (𝑂(𝐴) ∨ 𝑂(𝐵)) ∧ ¬(𝑃 (𝐴) ∨ 𝑃 (𝐵))
As cores são uma das variáveis mais efetivas cognitivamente segundo Moody [31], 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.
30
Figura 13 – BPMN Deôntico [32]
A transformação do BPMN para o BPMN Deôntico é definida como um sistema de grafo de atributo tipificado que inclui rótulos [32]. 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 este caminho vazio permite remover os gateways ligados a ele. Todos os caminhos que se-guem dele são obrigatórios[32]. 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,
ga-teways incondicionais denotam todos os gaga-teways 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. Neste caso, o usuário não é livre para escolher e as tarefas subsequentes são obrigatórias[32].
No BPMN, uma atividade permitida, bem como uma alternativa, podem ser ex-pressadas 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[32].
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[32]:
𝐴 ⊕ 𝜑 = 𝑃 (𝐴)
𝐴 ⊕ 𝐵 ⊕ 𝜑 = 𝑃 (𝐴) ⊕ 𝑃 (𝐵)
Se existir apenas um caminho além do caminho vazio, então os gateways podem ser removidos. Como na figura 14.
31
(a) (b)
Figura 14 – Remoção de Phi-Path de gateways exclusivos [32].
Se um gateway exclusivo não tem um caminho vazio, então todos os caminhos são alternativos.
(a) (b)
Figura 15 – Gateways exclusivos sem Phi-Path [32].
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[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[32]:
(𝑃 (𝐴) ∧ 𝑂(𝐴|¬𝐵 ∧ ¬𝐶)) ∨ (𝑃 (𝐵) ∧ 𝑂(𝐵)|¬𝐴 ∧ ¬𝐶) ∨ (𝑃 (𝐶) ∧ 𝑂(𝐶|¬𝐴 ∧ ¬𝐵) Esta 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[32]. 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. Neste caso a tarefa B é permitida apenas se A foi executada, ou seja, A é uma pré-condição.
(a) (b)
Figura 16 – Gateways Aninhados [32].
Pré-condições são necessárias também para os casos onde a escolha não é livre para o usuário. Este é 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
32
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, especificamos que tudo que não é explicitamente permitido é proibido. Por-tanto, a parte proibida pode ser omitida, veja figura 17.
(a) (b)
Figura 17 – Gateways condicionais [32].
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. Desta 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)
33
3 UM MÉTODO DE VERIFICAÇÃO PARA BPM
O método proposto consiste numa transformação do modelo de BPM utilizando a BPMN para uma lógica de contratos baseada na CL com caracterí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 e as demais características de um contrato, como as tarefas realizadas, obrigações, permissões e proibições, paralelismo e sequenciamento. As regras de execução das ações num contratos podem ser realizadas por indivíduos específicos e nem sempre são globais. Tendo em mente as características de um contrato simples, uma possível gramática para um BPMN que atenda essas características é proposta abaixo:
𝑃 ::= 𝑝𝑘(𝑖𝑋𝑓 ) | 𝑝𝑘(𝑖𝑋𝑓 )𝑃
𝑋 ::= 𝑔(𝑌 ) | 𝑡𝑎𝑠𝑘𝛽(𝑎) | 𝑔(𝑌 )𝑋 | 𝑡𝑎𝑠𝑘𝛽(𝑎)𝑋 | 𝜖
𝑌 ::= 𝑋, 𝑌 | 𝑋
Na sintaxe descrita, 𝑝𝑘 é uma Pool, onde 𝑘 é o identificador da Pool e fará parte
do conjunto de indivíduos, I, do contrato; 𝑖 é um evento de início e 𝑓 um evento de fim. A 𝑡𝑎𝑠𝑘𝛽(𝑎) é uma tarefa 𝑎, onde 𝑎 é uma única ação que faz parte do conjunto de ações e
𝛽 é uma associação entre Pools, onde 𝛽 ⊆ U, que indica para qual indivíduo 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. Na gramática os gateways são representados por 𝑔 e pode ser um dos 3 tipos de gateways (𝑔𝑝, 𝑔𝑥, ou 𝑔𝑖); 𝑔𝑝 é a representação de um gateway paralelo, 𝑔𝑥 é a representação de um gateway exclusivo e 𝑔𝑖 é a representação de um gateway inclusivo.
Um elemento separado por ","indica uma ramificação no fluxo de sequência, caso contrário o elemento é sequencial.
Utilizando as regras da gramatica acima, temos a seguir um exemplo de derivação:
𝑃 𝑝𝑘(𝑖𝑋𝑓 )𝑃 𝑝𝑘(𝑖𝑋𝑓 )𝑝𝑤(𝑖𝑋𝑓 )𝑃 𝑝𝑘(𝑖𝑋𝑓 )𝑝𝑤(𝑖𝑋𝑓 )𝑝𝑧(𝑖𝑋𝑓 ) 𝑝𝑘(𝑖𝑔(𝑌 )𝑋𝑓 )𝑝𝑤(𝑖𝑋𝑓 )𝑝𝑧(𝑖𝑋𝑓 ) 𝑝𝑘(𝑖𝑔(𝑌 )𝑔(𝑌 )𝑋𝑓 )𝑝𝑤(𝑖𝑋𝑓 )𝑝𝑧(𝑖𝜖𝑓 ) 𝑝𝑘(𝑖𝑔(𝑌 )𝑔(𝑌 )𝑋𝑓 )𝑝𝑤(𝑖𝑡𝑎𝑠𝑘𝑘(𝑎)𝑓 )𝑝𝑧(𝑖𝜖𝑓 ) 𝑝𝑘(𝑖𝑔(𝑌 )𝑔(𝑌 )𝑡𝑎𝑠𝑘𝑤,𝑧(𝑎)𝑓 )𝑝𝑤(𝑖𝑡𝑎𝑠𝑘𝑘(𝑎)𝑓 )𝑝𝑧(𝑖𝜖𝑓 )
34 𝑝𝑘(𝑖𝑔(𝑋, 𝑌 )𝑔(𝑌 )𝑡𝑎𝑠𝑘𝑤,𝑧(𝑎)𝑓 )𝑝𝑤(𝑖𝑡𝑎𝑠𝑘𝑘(𝑎)𝑓 )𝑝𝑧(𝑖𝜖𝑓 ) 𝑝𝑘(𝑖𝑔(𝑋, 𝑌 )𝑔(𝑋, 𝑌 )𝑡𝑎𝑠𝑘𝑤,𝑧(𝑎)𝑓 )𝑝𝑤(𝑖𝑡𝑎𝑠𝑘𝑘(𝑎)𝑓 )𝑝𝑧(𝑖𝜖𝑓 ) 𝑝𝑘(𝑖𝑔(𝑋, 𝑋, 𝑌 )𝑔(𝑋, 𝑌 )𝑡𝑎𝑠𝑘𝑤,𝑧(𝑎)𝑓 )𝑝𝑤(𝑖𝑡𝑎𝑠𝑘𝑘(𝑎)𝑓 )𝑝𝑧(𝑖𝜖𝑓 ) 𝑝𝑘(𝑖𝑔(𝑋, 𝑋, 𝑌 )𝑔(𝑋, 𝑋)𝑡𝑎𝑠𝑘𝑤,𝑧(𝑎)𝑓 )𝑝𝑤(𝑖𝑡𝑎𝑠𝑘𝑘(𝑎)𝑓 )𝑝𝑧(𝑖𝜖𝑓 ) 𝑝𝑘(𝑖𝑔(𝑋, 𝑋, 𝑌 )𝑔(𝑋, 𝜖)𝑡𝑎𝑠𝑘𝑤,𝑧(𝑎)𝑓 )𝑝𝑤(𝑖𝑡𝑎𝑠𝑘𝑘(𝑎)𝑓 )𝑝𝑧(𝑖𝜖𝑓 ) 𝑝𝑘(𝑖𝑔(𝑋, 𝑋, 𝑌 )𝑔(𝑡𝑎𝑠𝑘(𝑓 )𝑋, 𝜖)𝑡𝑎𝑠𝑘𝑤,𝑧(𝑎)𝑓 )𝑝𝑤(𝑖𝑡𝑎𝑠𝑘𝑘(𝑎)𝑓 )𝑝𝑧(𝑖𝜖𝑓 ) 𝑝𝑘(𝑖𝑔(𝑔(𝑌 ), 𝑋, 𝑋)𝑔(𝑡𝑎𝑠𝑘(𝑓 )𝑋, 𝜖)𝑡𝑎𝑠𝑘𝑤,𝑧(𝑎)𝑓 )𝑝𝑤(𝑖𝑡𝑎𝑠𝑘𝑘(𝑎)𝑓 )𝑝𝑧(𝑖𝜖𝑓 ) 𝑝𝑘(𝑖𝑔(𝑔(𝑋, 𝑌 ), 𝑋, 𝑋)𝑔(𝑡𝑎𝑠𝑘(𝑓 )𝑋, 𝜖)𝑡𝑎𝑠𝑘𝑤,𝑧(𝑎)𝑓 )𝑝𝑤(𝑖𝑡𝑎𝑠𝑘𝑘(𝑎)𝑓 )𝑝𝑧(𝑖𝜖𝑓 ) 𝑝𝑘(𝑖𝑔(𝑔(𝑋, 𝑋), 𝑋, 𝑋)𝑔(𝑡𝑎𝑠𝑘(𝑓 )𝑋, 𝜖)𝑡𝑎𝑠𝑘𝑤,𝑧(𝑎)𝑓 )𝑝𝑤(𝑖𝑡𝑎𝑠𝑘𝑘(𝑎)𝑓 )𝑝𝑧(𝑖𝜖𝑓 ) 𝑝𝑘(𝑖𝑔(𝑔(𝑡𝑎𝑠𝑘(𝑏), 𝑡𝑎𝑠𝑘(𝑐)), 𝑡𝑎𝑠𝑘(𝑑), 𝑡𝑎𝑠𝑘(𝑒))𝑔(𝑡𝑎𝑠𝑘(𝑓 )𝑡𝑎𝑠𝑘(𝑔), 𝜖)𝑡𝑎𝑠𝑘𝑤,𝑧(𝑎)𝑓 ) 𝑝𝑤(𝑖𝑡𝑎𝑠𝑘𝑘(𝑎)𝑓 )𝑝𝑧(𝑖𝜖𝑓 ) 𝑝𝑘(𝑖𝑔𝑝(𝑔𝑖(𝑡𝑎𝑠𝑘(𝑏), 𝑡𝑎𝑠𝑘(𝑐)), 𝑡𝑎𝑠𝑘(𝑑), 𝑡𝑎𝑠𝑘(𝑒))𝑔𝑥(𝑡𝑎𝑠𝑘(𝑓 )𝑡𝑎𝑠𝑘(𝑔), 𝜖)𝑡𝑎𝑠𝑘𝑤,𝑧(𝑎)𝑓 ) 𝑝𝑤(𝑖𝑡𝑎𝑠𝑘𝑘(𝑎)𝑓 )𝑝𝑧(𝑖𝜖𝑓 )
tal que, o conjunto de indivíduos I é {𝑘, 𝑤, 𝑧} e graficamente temos o diagrama como mostra a figura 19.
Figura 19 – Exemplo Derivaçã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 𝛼 é realizada nenhuma outra tarefa é realizada.
35
Figura 20 – Gateway Exclusivo (XOR)
O Gateway Paralelo se comporta como uma porta lógica AND, todas as tarefas de sua ramificação deverão ser realizadas.
Figura 21 – Gateway Paralelo (AND)
O Gateway Inclusivo se comporta como uma porta lógica OR, ou seja, ao menos uma tarefa deve ser realizada, podendo ser uma ou mais.
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.
Pelas características do Gateway Paralelo, todas as tarefas serão realizadas, sendo assim, se torna inútil o caminho vazio 𝜖 neste Gateway, podendo este caminho ser ignorado ou retirado.
36
Figura 22 – Gateway Inclusivo (OR)
Figura 23 – Gateway Exclusivo Permissive P(XOR)
37
Figura 24 – Gateway Paralelo Permissive P(AND)
38
39
REFERÊNCIAS
[1] P.E. AGRE. Formalization as a Social Project. Quarterly Newsletter of the Laboratory of Comaprative Human Cognition, 1992.
[2] Natalia Simoes Araujo. Peculiaridades dos contratos eletronicos, outubro.
[3] João Porto de Albuquerque. Repensando processos de formalização em sistemas informatizados: analisando a co-evolução entre software e práticas organizacionais. jun., 2009.
[4] Wellington Aparecido. Della Mura. Deteccao de conflitos em contratos multilaterais. Master’s thesis, Universidade Estadual de Londrina, Londrina, 2016.
[5] FENECH. S. Conflict Analysis of Deontic Contracts. mestrado | Department of
Computer Science and Artificial Intelligence. University of Malta, 2008.
[6] Lucid Software Inc. Bpmn diagram symbols and notation.
[7] Rhaissa Nogueira. Introducao ao business process modeling notation (bpmn). [8] Inc. (OMG) Object Management Group. Bpmn 2.0 by example. jun., 2010. [9] Enciclopedia livre Wikipedia. https://pt.wikipedia.org/wiki/L
[10] Inc. (OMG) Business Process Model and Notation (BPMN). http://www.omg.org/spec/BPMN/2.0. January 2011.
[11] FISCHER, M. J.; LADNER, R. E. Propositional dynamic logic of regular programs. Journal of Computer and System Sciences. 1979.
[12] HERRESTAD, H.; KROGH, C. Deontic logic relativised to bearers and
counterparties. In: Proceedings of the Anniversary of Anthology in Computers and
Law. Tano A.S., 1995.
[13] P.; VONK J. KOETSIER, M.; GREFEN. Contracts for cross-organizational
workflow management. Springer Berlin Heidelberg, 2000.
[14] von Wright, G. H. Deontic logic. Oxford University Press, 1951.
[15] M. P. UDUPI, Y. B.; SINGH. Contract enactment in virtual organizations: A
commitment-based approach. AAAI Press, 2006.
[16] C.; SCHNEIDER G. PACE, G.; PRISACARIU. Model checking contracts a case
study. Springer Berlin Heidelberg, 2007.
[17] KYAS, M.; PRISACARIU, C.; SCHNEIDER, G. Runtime monitoring of electronic
contracts. Springer-Verlag, 2008.
[18] CHELLAS, B. F. Modal Logic: an introduction. Cambridge University Press, 1980. [19] BLACKBURN, P.; BENTHEM, J. van; WOLTER, F. Handbook of Modal Logic.
40
[20] HAREL, D.; KOZEN, D.; TIURYN, J. Dynamic logic. MIT Press, 1984.
[21] C.; SCHNEIDER G. PACE, G.; PRISACARIU. A formal language for electronic
contracts. Springer, 2007.
[22] MCNAMARA, P. Deontic logic: Challenges to standard deontic logics. Disponível em: http://plato.stanford.edu/entries/logic-deontic/.
[23] PRAKKEN, H.; SERGOT, M. Contrary-to-duty obligations. Studia Logica, 1996. [24] KYAS, M.; PRISACARIU, C.; SCHNEIDER, G. Run-time Monitoring of Electronic
Contracts-theoretical results. S.l., 2008.
[25] MONTAZERI, S. M.; ROY, N.; SCHNEIDER, G. From Contracts in Structured English to CL Specifications. 5th International Workshop on Formal Languages and Analysis of Contract-Oriented Software Málaga, Spain: [s.n.], 2011.
[26] MARTINEZ, E. A Model for Visual Specification of e-Contracts. The 7th IEEE International Conference on Services Computing (IEEE SCC’10) IEEE Computer Society, 2010
[27] KROGH, C.; HERRESTAD, H. Individuals Obligations. 1994.
[28] TAN, Y.-h.; THOEN, W. A logical model of directed obligations and permissions to support electronic contracting in electronic commerce. International Journal of Electronic Commerce. Formal aspects of digital commerce, 1998.
[29] Asbjorn Rolstadas Business process modelling and re-engineering. Performance Management: A Business Process Benchmarking Approach. p. 148-150.
[30] Thomas Dufresne and James Martin Process Modeling for E-Business. INFS 770 Methods for Information Systems Engineering: Knowledge Management and E-Business. Spring 2003.
[31] Moody,D.L. The "physics" of notations: Towards a scientific basis for constructing visual notations in software engineering. IEEE Trans. Softw. Eng. 35(5), 756-778 2009.
[32] Christine Natschlager - Felix Kossak - Klaus-Dieter Schewe Deontic BPMN: a powerful extension of BPMN with a trusted model transformation. Springer-Verlag Berlin Heidelberg 2013.
[33] Christine Natschlage Deontic BPMN: In: Hameurlain, A., Liddle, S., Schewe,K.D., Zhou, X. (eds.) Database and Expert SystemsApplications Springer, Berlin, pp 264-278 2011.
[34] Object Management Group Business Process Model and Notation http://www.bpmn.org/ May 2018.
[35] Business Process Model and Notation Wiki. https://en.wikipedia.org/wiki/Business Process Model and Notation maio, 2018.
