HENRIQUE GONÇALVES RODRIGUES MEDINA

MODELAGEM, FORMALIZAÇÃO E VERIFICAÇÃO DECONTRATOS UTILIZANDO O CONCEITO DE BPM

(BUSINESS PROCESS MANAGEMENT)

LONDRINA–PR

2017

HENRIQUE GONÇALVES RODRIGUES MEDINA

MODELAGEM, FORMALIZAÇÃO E VERIFICAÇÃO DECONTRATOS UTILIZANDO O CONCEITO DE BPM

(BUSINESS PROCESS MANAGEMENT)

Trabalho de Conclusão de Curso apresentadoao curso de Bacharelado em Ciência da Com-putação da Universidade Estadual de Lon-drina para obtenção do título de Bacharel emCiência da Computação.

Orientador: Prof. Dr. Adilson Luiz Bonifacio

LONDRINA–PR

2017

Henrique Gonçalves Rodrigues MedinaMODELAGEM, FORMALIZAÇÃO E VERIFICAÇÃO DE CONTRATOS

UTILIZANDO O CONCEITO DE BPM (BUSINESS PROCESS MANAGE-MENT)/ Henrique Gonçalves Rodrigues Medina. – Londrina–PR, 2017-

51 p. : il. ; 30 cm.

Orientador: Prof. Dr. Adilson Luiz Bonifacio

– Universidade Estadual de Londrina, 2017.

CDU 02:141:005.7

HENRIQUE GONÇALVES RODRIGUES MEDINA

MODELAGEM, FORMALIZAÇÃO E VERIFICAÇÃO DECONTRATOS UTILIZANDO O CONCEITO DE BPM

(BUSINESS PROCESS MANAGEMENT)

Trabalho de Conclusão de Curso apresentadoao curso de Bacharelado em Ciência da Com-putação da Universidade Estadual de Lon-drina para obtenção do título de Bacharel emCiência da Computação.

BANCA EXAMINADORA

Prof. Dr. Adilson Luiz BonifacioUniversidade Estadual de Londrina

Orientador

Prof. Dr. Segundo Membro da BancaUniversidade/Instituição do Segundo

Membro da Banca

Prof. Dr. Terceiro Membro da BancaUniversidade/Instituição do Terceiro

Membro da Banca

Prof. Ms. Quarto Membro da BancaUniversidade/Instituição do Quarto

Membro da Banca

Londrina–PR, 25 de setembro de 2017

Este trabalho é dedicado as crianças adultas quequando pequenas, sonharam em se tornar cientistas.

AGRADECIMENTOS

“O homem erudito é um descobridor de fatos que já existem,mas o homem sábio é um criador de valores que não existem

e que ele faz existir.”(Albert Einstein)

MEDINA, H.. MODELAGEM, FORMALIZAÇÃO E VERIFICAÇÃO DE CON-TRATOS UTILIZANDO O CONCEITO DE BPM (BUSINESS PROCESSMANAGEMENT). 51 p. Trabalho de Conclusão de Curso (Bacharelado em Ciênciada Computação) – Universidade Estadual de Londrina, Londrina–PR, 2017.

RESUMO

Esta pesquisa propõe a integração entre o conceito de gestão de negócios e a formalizaçãoe verificação de contratos legais, para facilitar e, possivelmente, otimizar estes processos.Para isso, serão estudados modelos e notações já existentes para os processos de negócios,representação formal de contratos e a possibilidade de customizar estes modelos e notaçõespara o problema de contratos legais.

Palavras-chave: BPM. Processo de negťocio. Modelagem. Formalização. Verificação decontratos. Lťogicas formais. Linguagem de contratos. Contratos

MEDINA, H.. Modeling, Formalization and Verification of contracts using theBusiness Process Management (BPM) concept. 51 p. Final Project (Bachelor ofScience in Computer Science) – State University of Londrina, Londrina–PR, 2017.

ABSTRACT

This research proposes the integration between the concept of business process manage-ment and the formalization and verification of legal contracts to simplify and, possibly,optimize these processes. Existent models and notations used on business processes man-agement, formal representation for contracts and the possibility of customizing thesemodels for legal contracts problems, will be explored in this study.

Keywords: BUSINESS PROCESS MANAGEMENT. Modeling. Formalization. Verifica-tion of contracts. Contracts. Formal logics. Contract Language.

LISTA DE ILUSTRAÇÕES

Figura 1 – Pizza Example[8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

LISTA DE TABELAS

LISTA DE ABREVIATURAS E SIGLAS

BPM Gerenciamento de processo de Negócio - Business Process Management

BPMN Notação para Gerenciamento de processo de Negócio - Business ProcessManagement Notation

CL Linguagem de contratos - Contract Language

RCL Linguagem de contratos relativizada - Relativized Contract Language

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2 FUNDAMENTAÇÃO TEÓRICO-METODOLÓGICA . . . . . 252.1 Gerenciamento de Processos de Negócio (BPM - Business

Process Management) . . . . . . . . . . . . . . . . . . . . . . . . . 252.1.1 Representação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.1.2 Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2 Contratos Legais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.1 Formalização de contratos . . . . . . . . . . . . . . . . . . . . . . 292.2.2 Lógicas para contratos . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.3 Lógica modal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.4 Lógica dinâmica proposicional . . . . . . . . . . . . . . . . . . . . 302.2.5 Lógica deôntica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.2.6 Lógica deôntica relativizada . . . . . . . . . . . . . . . . . . . . . 312.2.7 A Linguagem de contratos (𝐶𝐿 - Contract Language) . . . . . 332.3 Verificação de contratos . . . . . . . . . . . . . . . . . . . . . . . . 342.3.1 Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.3.2 Violação e conflito . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . 393.1 Linguagem de contratos relativizada (RCL) . . . . . . . . . . . 393.2 Relacionando Modelos Formais com o Processo de Negócio . 39

4 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

APÊNDICES 45

APÊNDICE A – . . . . . . . . . . . . . . . . . . . . . . . . . . 47

ANEXOS 49

ANEXO A – . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

23

1 INTRODUÇÃO

Este trabalho visa estudar a possibilidade de utilizar um conceito de gestão denegócios, com foco na formalização de contratos para a eliminação de ambiguidades nascláusulas, o que poderia levar à rescisão de contrato e desentendimentos entre as par-tes envolvidas. Estes problemas motivam a formalização dos contratos com embasamentomatemático, para que seja possível a validação matemática e computacional. Veremos osprincipais conceitos para modelagem do BPM (Business Process Managent - Gerencia-mento de processo de negócios), a sintaxe e o significado de seus principais componentes,como objetos de fluxo, objetos de conexão, raias (swim lanes) e as piscinas (pools). Es-tudaremos algumas representações formais de sistemas, como as lógicas modais, lógicadinâmica proposicional, lógica deôntica e a relativização da lógica deôntica. Em cadauma delas abordaremos as suas principais características, comportamentos, operadores,sintaxe e equivalências, dando foco na base necessária para compreender o funcionamentoda linguagem de contratos e a relativização da mesma. Concluiremos com a compreensãoda linguagem de contratos (CL - Contract Language), a linguagem de contratos relativi-zada (RLC) e a verificação formal de contratos.

Já existem trabalhos que abordam o tema de formalização de contratos, no en-tanto, não há trabalhos conhecidos que façam uma relação do BPM para a linguagem decontratos relativizada. Este estudo pode trazer uma via mais simples que leva de contratosformais em alto nível à linguagem de contratos relativizada, que permite sua validaçãomatemática.

25

2 FUNDAMENTAÇÃO TEÓRICO-METODOLÓGICA

Esta seção apresenta os conceitos relacionados a contratos, BPM, modelagem enotações do BPM e algumas de suas características, formalização e lógicas utilizadasnas representação de contratos, fornecendo um conjunto de conceitos necessários paradesenvolver a pesquisa proposta neste trabalho.

2.1 Gerenciamento de Processos de Negócio (BPM - BusinessProcess Management)

O Gerenciamento de Processos de Negócio é um conjunto de conceitos de gestãode negócios com foco na otimização dos resultados por meio da melhoria dos processos denegócios, utiliza um conjunto de elementos estruturados e relacionados que representamcomo um serviço ou produto será produzido para seus clientes.

Na modelagem BPMN existem quatro grupos de elementos[7]:

1. Objetos de fluxo (𝐹𝑙𝑜𝑤 𝑂𝑏𝑗𝑒𝑐𝑡𝑠)

Objetos de fluxo representam os conceitos sendo modelados. Eles podem ser se-parados em três áreas: 𝑒𝑣𝑒𝑛𝑡𝑜𝑠, 𝑎𝑡𝑖𝑣𝑖𝑑𝑎𝑑𝑒𝑠 e 𝑔𝑎𝑡𝑒𝑤𝑎𝑦𝑠.

Eventos podem ser customizados para representar detalhes específicos do processo,como mensagens ou tempo.

Atividades descrevem o tipo de trabalho que está sendo executado em uma deter-minada instância. No BPMN existem 4 tipos de atividades: tarefas, sub-processos,transações e chamadas.

Gateways são símbolos que controlam o fluxo de sequência, separam e recombi-nam fluxos em um diagrama.

2. Objetos de conexão (𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑛𝑔 𝑂𝑏𝑗𝑒𝑐𝑡𝑠)

Objetos de conexão são linhas que representam as conexões no fluxo do diagrama.Existem três tipos diferentes de objetos de conexão: fluxos de sequência, fluxos de

26

mensagem e associações.

3. Raias (𝑆𝑤𝑖𝑚𝑙𝑎𝑛𝑒𝑠)

As raias são usadas para organizar um diagrama no BPMN. Elas agrupam obje-tos facilitando a visualização de cada aspecto do diagrama e, além disso, podemmostrar atrasos, ineficiências, bem como, o responsável por cada tarefa do processo.

4. Artefatos (𝐴𝑟𝑡𝑖𝑓𝑎𝑐𝑡𝑠)

Artefatos representam informações relevantes para o modelo, mas não para ele-mentos individuais do processo. Existem três tipos: anotações, grupos e objetos dedados.

Anotações permitem descrever fluxos adicionais do modelo ou notação por quemestá modelando.

Grupos organizam tarefas ou processos que são significantes.

Objetos de dados representam dados atribuídos ao processo, resultantes do pro-cesso, que precisam ser coletados ou que devem ser armazenados.

2.1.1 Representação

Assim como o UML (Unified Modeling Language), temos o BPMN (BUSINESSPROCESS MODELING NOTATION) como uma das notações mais utilizadas para re-presentação de processos de negócios. Trata-se de uma série de símbolos padrões paraa representação dos elementos e relações entre eles no processo, como um diagrama ouwork-flow. A modelagem é uma etapa muito importante pois é nela que os processos sãorepresentados e podem ser feitas alterações para otimização.

A BPMN possui muitos símbolos, cada forma tem um significado específico. Aseguir estão alguns dos símbolos[6] que serão utilizados no exemplo da Figura 1 [8] nasubseção de diagrama e modelagem.

Símbolos de eventos:

- Início do processo.

27

- Fim do processo.

- Fim de um passo do processo.

- Símbolo de mensagem.

- Símbolo de tempo ou data.

Símbolos de Gateways:

- Gateway baseado em evento.

- Gateway que permite eventos em paralelo.

Objetos de Conexão:

- Representa a sequência de fluxo entre os objetos.

- Representa o fluxo de mensagens no processo.

Símbolos de atividades:

- Representa uma tarefa que deve ser realizada.

Piscina e Raias (Pool e SwimLanes)

-Piscinas e Raias separam as diferentes partes do processo em seus respectivos responsá-veis.

2.1.2 Exemplo

Esta seção apresenta um exemplo de uma modelagem simples para um pedido eentrega de pizza. Este é um exemplo simples que demonstra a interação entre duas partes

28

distintas, cliente e vendedor, que estão divididos em duas piscinas ou Pool.

Figura 1 – Pizza Example[8]

O processo se inicia no cliente, pelo símbolo 𝐻𝑢𝑛𝑔𝑟𝑦 𝑓𝑜𝑟 𝑝𝑖𝑧𝑧𝑎 que representa oinício do evento. Em sequência temos duas atividades, 𝑆𝑒𝑙𝑒𝑐𝑡 𝑎 𝑝𝑖𝑧𝑧𝑎 e 𝑂𝑟𝑑𝑒𝑟 𝑎 𝑝𝑖𝑧𝑧𝑎. Aatividade 𝑂𝑟𝑑𝑒𝑟 𝑎 𝑝𝑖𝑧𝑧𝑎 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 doiseventos subsequentes ocorram: ou o evento de tempo 60 𝑚𝑖𝑛𝑢𝑡𝑒𝑠, caso 60 minutos sepassem, ou 𝑝𝑖𝑧𝑧𝑎 𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑 caso receba a pizza. Enquanto isso, na Pool 𝑃𝑖𝑧𝑧𝑎 𝑣𝑒𝑛𝑑𝑜𝑟, aLane 𝑐𝑙𝑒𝑟𝑘, que representa o atendente, segue o processo pelo símbolo de atividade paralelapara a lane 𝑝𝑖𝑧𝑧𝑎 𝑐ℎ𝑒𝑓 , que inicia a tarefa 𝐵𝑎𝑘𝑒 𝑡ℎ𝑒 𝑝𝑖𝑧𝑧𝑎, paralelamente o atendentefica pronto para receber uma mensagem 𝑤ℎ𝑒𝑟𝑒 𝑖𝑠 𝑚𝑦 𝑝𝑖𝑧𝑧𝑎?. Na lane do cliente, caso60 minutos se passem, uma tarefa 𝐴𝑠𝑘 𝑓𝑜𝑟 𝑡ℎ𝑒 𝑝𝑖𝑧𝑧𝑎 dispara uma mensagem para oatendente, que está pronto para responder com a tarefa 𝐶𝑎𝑙𝑚 𝑐𝑢𝑠𝑡𝑜𝑚𝑒𝑟. Após a tarefa𝐵𝑎𝑘𝑒 𝑡ℎ𝑒 𝑝𝑖𝑧𝑧𝑎 ser concluída, o processo segue para a Lane 𝐷𝑒𝑙𝑖𝑣𝑒𝑟𝑦 𝑏𝑜𝑦 que executa atarefa 𝐷𝑒𝑙𝑖𝑣𝑒𝑟 𝑡ℎ𝑒 𝑝𝑖𝑧𝑧𝑎 enviando uma mensagem 𝑝𝑖𝑧𝑧𝑎 para o cliente. O cliente entãolibera o evento 𝑝𝑖𝑧𝑧𝑎 𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑 levando à tarefa 𝑃𝑎𝑦 𝑡ℎ𝑒 𝑝𝑖𝑧𝑧𝑎 que troca mensagens coma tarefa 𝑅𝑒𝑐𝑒𝑖𝑣𝑒 𝑝𝑎𝑦𝑚𝑒𝑛𝑡, a qual após enviar sua mensagem, termina o processo da Pool𝑃𝑖𝑧𝑧𝑎 𝑣𝑒𝑛𝑑𝑜𝑟, Na pool 𝑃𝑖𝑧𝑧𝑎 𝐶𝑢𝑠𝑡𝑜𝑚𝑒𝑟, segue-se para a tarefa 𝐸𝑎𝑡 𝑡ℎ𝑒 𝑝𝑖𝑧𝑧𝑎 finalizandoo processo.

29

2.2 Contratos Legais

Um contrato pode ser definido como um conjunto de cláusulas, que rege umanegociação entre duas ou mais partes, para que constituam, modifiquem ou extinguamvínculos jurídicos. Os contratos são uma forma de manifestar e garantir as vontades destaspartes sobre um determinado assunto, geralmente de natureza patrimonial[2].O contrato eletrônico é uma conversão de contratos convencionais, em que duas ou maispartes possam expressar, ou não, suas declarações de vontade por meios digitais.Para queo contrato eletrônico tenha sua existência e validade jurídica, é necessária a observância derequisitos que cabem aos contratos em geral. Além disso, ainda há abordagens que tratamda utilização de contratos eletrônicos para formalizar regras de negócio em workflows[12], verificação de sistemas baseados em multi-agentes [14], verificação de arquiteturasbaseadas 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 vagoao preciso [1], de forma a eliminar ambiguidades e imprecisões que possam ser causadaspela linguagem natural, mediante a representação por símbolos e definindo operações aserem 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 ambiguidadesnas cláusulas, o que poderia levar à rescisão do contrato ou desistência de negócio poruma 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 verificação sistemática com apoiocomputacional [4].

2.2.2 Lógicas para contratos

A linguagem para contratos, denominada 𝐶𝐿 [20], 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 epermitir sua verificação formal. A 𝐶𝐿 é baseada em ações síncronas (concorrentes), nosprincípios da lógica deôntica para definir normas [13], e na lógica dinâmica proposicionalpara representar as ações num sistema [19]. Para compreendermos melhor a linguagem decontratos, precisaremos primeiro entender as lógicas por trás dela, portanto voltaremos afalar sobre a 𝐶𝐿 na subseção 2.2.7.

2.2.3 Lógica modal

O termo lógica modal descreve um grande número de lógicas na literatura quepossuem características modais[4]. A lógica modal é, estritamente falando, o estudo do

30

comportamento dedutivo das expressões "é necessário que"e "é possível que", ou seja, suaprincipal característica é a capacidade de expressar necessidade e possibilidade[17].

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[18]:

�𝑝, necessariamente 𝑝

◇𝑝, possivelmente 𝑝

Nas lógicas modais clássicas, cada um pode ser expresso em função do outro e da negação:

◇𝑝 ≡ ¬�¬𝑝

�𝑝 ≡ ¬ ◇ ¬𝑝

2.2.4 Lógica dinâmica proposicional

A lógica dinâmica é uma extensão da lógica modal. Composta basicamente pelosoperadores de necessidade e possibilidade [] e ⟨⟩, respectivamente[10].

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 verdadeiroapós 𝑎[10].

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ívelque 𝑝 seja verdade após 𝑎[10].

Equivalências[10]:

[𝑎]𝑝 ≡ ¬⟨𝑎⟩¬𝑝

⟨𝑎⟩𝑝 ≡ ¬[𝑎]¬𝑝

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 podeser utilizada para este fim, operadores de expressão regular de Kleene são uma boa com-binaçã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 execuçãode 𝑎 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çãoalguma e não finaliza, ao passo que a constante 1, ou 𝑆𝐾𝐼𝑃 , ou 𝑁𝑂𝑃 , não faz nadaporém finaliza.

31

As fórmulas da lógica dinâmica descrevem propriedades que ocorrem após a exe-cução de um programa. A fórmula 𝐴 = [𝑎 ∪ 𝑏]𝑝, por exemplo, indica que sempre queo programa 𝑎 ou o programa 𝑏 são executados a proposição 𝑝 é verdadeira no estadoseguinte[4].

2.2.5 Lógica deôntica

A lógica deôntica é um tipo especial de lógica modal que aborda os conceitosnormativos, sistemas de normas e o raciocínio sobre estas normas. Os conceitos normativosincluem deveres, possibilidades e impossibilidades, representados respectivamente, pelaobrigaçã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óriose a partir do operador de obrigação e da negação lógica (¬) é possível definir os operadoresde proibição (𝐹 ) e de permissão (𝑃 ):

𝑂𝑝 ≡ 𝐹¬𝑝 ≡ ¬𝑃¬𝑝

2.2.6 Lógica deôntica relativizada

A relativização da lógica deôntica[11] é a principal alteração da lógica deônticapadrão, para que os indivíduos envolvidos em uma modalidade deôntica possam ser iden-tificados. Essa modificação permite a especificação de cláusulas na lógica deôntica clássica,onde as expressões são escritas sem revelar a identidade dos indivíduos envolvidos. A ex-pressã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. Afalta de personificação das ações torna a aplicação da lógica dinâmica clássica limitadatanto na análise do mundo real, quanto na concepção de sistemas multi-agente [26].

32

Neste cenário é comum existir sentenças sem a menção do indivíduo responsávelpela ação, como por exemplo em "é obrigatório pagar o produto para o vendedor", porémexpressar 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 eKrogh [11] para explicitar o indivíduo responsável pela execução de uma determinadaação.

A relativização da lógica deôntica especifica quais indivíduos estão relacionadosa 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 relativizados,quando não definem esse indivíduo [26].

Vários tipos de modalidades vinculando indivíduos específicos, podem ser obtidosconforme segue:

Modalidade geral (ou genérica): modalidade relativa a todos os indivíduos;

Modalidade impessoal (ou não especificada): quando a modalidade não mencionao 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 deveexecutar 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 dedefinir o portador da modalidade relacionada à execução de certa ação. O conjunto detodos 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 𝑎, asentença 𝑖𝑂(𝑎) expressa que o indivíduo 𝑖 é obrigado a fazer 𝑎, e 𝑖𝑃 (𝑎) significa queindivíduo 𝑖 tem permissão para executar a ação 𝑎 [11].

Esta relativização possibilita expressar situações mais detalhadas com a lógicadeôntica, como por exemplo, num comércio eletrônico, onde o vendedor 𝑖 é obrigado a𝑒𝑛𝑡𝑟𝑒𝑔𝑎𝑟 um produto e o cliente 𝑗 é obrigado a 𝑝𝑎𝑔𝑎𝑟 por esse produto. Essa sentençapode ser descrita por 𝑖𝑂(𝑒𝑛𝑡𝑟𝑒𝑔𝑎𝑟) ∧ 𝑗𝑂(𝑝𝑎𝑔𝑎𝑟)[4].

Uma característica típica das obrigações presentes em contratos é sua execução porum indivíduo, o portador da obrigação, para outro indivíduo, chamado de contra-parteou requerente [27].

Para entender essa necessidade, suponha o vendedor 𝑖 e o cliente 𝑗, num contratoem 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

33

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 relati-vizadas, em que a primeira 𝑖𝑂(𝑎) indica que o indivíduo 𝑖 deve executar a ação 𝑎 e asegunda 𝑂𝑗(𝑎) expressa que o indivíduo 𝑗 deve receber a execução da ação 𝑎. A sentença𝑖𝑂𝑗(𝑎) representa uma obrigação direcionada [11].

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 aexecutar a ação 𝑎 e 𝑗 é obrigado a ser beneficiado pela ação 𝑎. Do ponto de vista legal, oindivíduo 𝑗 é considerado no operador 𝑂𝑗 como o requerente da ação [4].

2.2.7 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 partedinâ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 emcontratos legais e eletrônicos buscando evitar os principais paradoxos deônticos[21].

As cláusulas podem conter os operadores lógicos, como na lógica proposicional,representadospela conjunção ∧ e pelo valor lógico falso, denotado por ⊥. As constantes proposicionaissã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].

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. Asaçõ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) denotadopor 𝐴𝐵. 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 𝐴𝐵 esignifica que a ação executada, em particular, não é importante [4].

As ações dentro das fórmulas podem ser combinadas pelos operadores: +, quandohá uma escolha entre as ações; ·, quando existe uma sequência de ações; e ×, quandoocorrem ações síncronas (ou concorrentes). O conjunto de ações compostas 𝐴𝐷 é compostopor ações básicas, ações especiais 0 e 1, e pela combinação de operadores. O conjunto deações concorrentes, denotado por 𝐴×𝐵 , é formado por ações compostas que utilizam

34

apenas o operador × e obtidas a partir da combinação das ações básicas. Na 𝐶𝐿, asações atômicas de 𝐴𝐵 são representadas por símbolos e, intuitivamente, executadas porum indivíduo. Nesta linguagem, os indivíduos são incorporados nas ações, seguindo oconceito da lógica deôntica padrão [15].

As modalidades deônticas 𝑂𝐶(𝑎), 𝐹𝐶(𝑎), 𝑃 (𝑎) representam respectivamente osoperadores de obrigação, proibição e permissão da lógica deôntica padrão, onde 𝑎 é umaação e 𝐶 representa a penalidade ou reparação quando a cláusula é violada após a execuçãoda ação. Note que não existe nenhum tipo de reparação nas permissões já que estas sãofacultativas e não implicam numa violação.

Esse conceito de reparação, representa as cláusulas contrárias ao dever (CTD oucontrary-to-duty) e contrárias à proibição (CTP ou contrary-to-prohibition). As cláusulasCTD representam situações em que há uma violação de obrigação primária e implicaem executar uma obrigação secundária. Essa obrigação secundária é uma reparação oupenalidade da violação gerada pela obrigação primária. O mesmo ocorre para o CTP quetrata da violação de uma proibição [22].

Obrigações ou proibições sem reparações, 𝑂⊥(𝑎) e 𝐹⊥(𝑎), também podem serrepresentadas, onde o símbolo ⊥ indica a ausência de reparação, ou seja, que o contratoserá 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çõescategó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 dalógica deôntica clássica que permite a aplicação das modalidades deônticas tanto em açõesquanto 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 eas fórmulas. Obrigações condicionais (ou permissões e proibições) podem ser expressas deduas 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.3 Verificação 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 umacordo. Normalmente, cada parte inicia a negociação oferecendo a solução preferida de seuinteresse. A outra parte, caso não aceite, deve fazer contrapropostas de forma a convergirpara que ambos aceitem a solução proposta.

35

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 geraruma 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óssua negociação.

Com a representação de contratos em 𝐶𝐿 é possível realizar a verificação formaldestas 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 eSchneider [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 denegociaçã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ômatopara procurar cláusulas conflitantes. O autômato obtido além de permitir a análise deconflitos ainda pode ser utilizado para o monitoramento do contrato. Essa abordagemrealiza 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.

36

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 [24] etécnicas para a modelagem visual de contratos [25].

2.3.1 Traces

A semântica da 𝐶𝐿 captura o comportamento da execução de uma sequência deações de forma que a cláusula do contrato seja respeitada. Esta semântica é utilizadana técnica de monitoramento proposta por Kyas, Prisacariu e Schneider [16], onde assequências de ações, chamadas de traces, que violam um contrato são identificadas. Umtrace 𝜎 é definido por uma sequência ordenada de ações concorrentes e a ação especial1 (skip), como 𝑎0, 𝑎1, ... , onde 𝑎𝑖 ∈ 𝐴×𝐵 , 𝑖 ≥ 0. O conjunto de ações concorrentes éobtido a partir da combinação das ações básicas usando o conector de concorrência ×.Sejam as ações básicas 𝑎, 𝑏, 𝑐 ∈ 𝐴𝐵, as ações concorrentes são dadas por 𝐴×𝐵 = 𝑎, 𝑏, 𝑐,𝑎×𝑏, 𝑏×𝑐, 𝑎×𝑐, 𝑎×𝑏×𝑐.

Um trace é, formalmente, definido por um mapeamento 𝜎 : 𝑁 → 𝐴×𝐵 ∪1, tal quedado 𝑖 ∈ 𝑁 , 𝜎 retorna as ações concorrentes de 𝐴×𝐵 da posição 𝑖 do trace. O tamanho dotrace é denotado por |𝜎|. Um trace infinito que possui apenas ações de salto 1 a partir deuma determinada posição 𝑖 é considerado finito de tamanho 𝑖. Um trace vazio é denotadopor 𝜖. Os elementos do trace são representados por 𝜎(𝑖), onde 𝑖 é uma posição. Paraexpressar um subtrace finito utiliza-se 𝜎(𝑖...𝑗), onde 𝑖 é o início e 𝑗 é o fim, e para umtrace infinito basta informar o seu início, onde 𝜎(𝑖...) representa um subtrace iniciado em𝑖. A operação de concatenação de dois traces 𝜎’ e 𝜎” é denotada por 𝜎’𝜎” e só é possível see somente se 𝜎’ é finito. O conteúdo de uma posição 𝑖 de um trace concatenado é definidopor 𝜎’𝜎”(𝑖) = 𝜎’(𝑖) se 𝑖 < |𝜎’ | e 𝜎’𝜎”(𝑖) = 𝜎”(𝑖− |𝜎’|) para 𝑖 ≥ |𝜎’| [4].

A relação de satisfação |= é aplicada sobre o par ordenado (𝜎, 𝐶), onde 𝜎 é umtrace e 𝐶 é um contrato, e 𝜎 |= 𝐶 significa que 𝜎 é satisfeito em 𝐶. Caso contrário, otrace viola o contrato, denotado por 𝜎|/= 𝐶 [4].

A seguir um exemplo simples de contrato que ilustra a semântica da 𝐶𝐿:

"Se o cliente exceder o limite de banda da internet então ele deve pagar uma multa,ou ele deve atrasar o pagamento mas notificar o provedor via e-mail. Em caso de quebradas duas cláusulas de penalidade, o cliente deve pagar em dobro"[23].

Este exemplo pode ser representado em 𝐶𝐿 como:

[𝑒]𝑂𝑂⊥(𝑝·𝑝)(𝑝 + 𝑎 ×𝑛), onde 𝑒 significa exceder o limite da banda, 𝑝 é pagar o valorproposto, 𝑎 é atrasar o pagamento e 𝑛 representa a notificação ao provedor [4].

Alguns traces que respeitam e violam este contrato são descritos a seguir[4]:

∙ 𝜎 = 𝑒, 𝑝; representa exceder o limite de banda e pagar por isso", respeitando o

37

contrato, pois respeita a obrigação principal.

∙ 𝜎 = 𝑒, 𝑎, 𝑝, 𝑝; representa exceder o limite de banda então atrasar o pagamento epagar o dobro". Também respeita o contrato, pois ao exceder o limite de banda,atrasa o pagamento mas não notifica provedor e paga em dobro.

∙ 𝜎 = 𝑝, 𝑝, 𝑝; representa pagar três vezes"e respeita o contrato, pois, desde que o tracenão inicie com a ação 𝑒, não existe obrigação.

∙ Os traces 𝜎 = 𝑒, 𝑒, 𝑒 (constantemente excedendo o limite) e 𝜎 = 𝑒, 𝑎, 𝑎 (excedendoo limite e constantemente atrasando o pagamento) são exemplos de violação docontrato.

2.3.2 Violação e conflito

Análise de conflitos normativos em contratos bilaterais estão presentes tanto emcontratos convencionais quanto em contratos eletrônicos. A condição de conflito em con-tratos caracteriza-se quando suas cláusulas não podem ser satisfeitas. Se uma cláusula𝐶1, por exemplo, proíbe uma ação 𝛼 e uma cláusula 𝐶2 obriga a execução dessa mesmaação 𝛼, torna-se impossível a satisfação do contrato, pois ao atender uma cláusula, a outraé violada. Diante deste cenário, foi proposto por Fenech [5] um método de detecção deconflitos em contratos eletrônicos especificados na linguagem de contratos 𝐶𝐿.

Um contrato possui conflitos quando ocorre uma contradição entre normas. Essasituação pode ser representada pela incompatibilidade entre as normas de proibição comnormas de permissão ou obrigação [5].

Os conflitos podem ser verificados tanto entre operadores deônticos conflitantessobre uma mesma ação quanto entre ações distintas, situação na qual estas ações seguemo princípio da exclusão mútua, podendo ser executadas ao mesmo tempo. Essa relação deconflito é representada em 𝐶𝐿 pelo símbolo #. Desta maneira, a exclusão entre as ações𝛼 e 𝛽 pode ser representada por 𝛼#𝛽. As situações de conflito e ações conflitantes quepodem ocorrer em um contrato são definidas da seguinte forma:

∙ Obrigar e proibir a mesma ação: 𝑂(𝛼) ∧ 𝐹 (𝛼)

∙ Permitir e proibir a mesma ação: 𝑃 (𝛼) ∧ 𝐹 (𝛼)

∙ Obrigar ações conflitantes: 𝑂(𝛼) ∧ 𝑂(𝛽), com 𝛼#𝛽

∙ Obrigar e permitir ações conflitantes: 𝑂(𝛼) ∧ 𝑃 (𝛽), com 𝛼#𝛽.

Existe também um outro tipo de conflito, chamado conflito fraco, em que a violação podeser evitada. Na fórmula 𝑂(𝛼 + 𝛽) ∧ 𝐹 (𝛼), por exemplo, existe uma escolha na obrigaçãoem executar a ação 𝛼 ou a ação 𝛽. Caso seja escolhida a ação 𝛼, um conflito vai ocorrer

38

com a proibição de 𝛼, mas se a ação 𝛽 é executada, o conflito não se caracteriza. A de-tecção de conflitos em 𝐶𝐿 tem como base as técnicas de verificação de modelos (modelchecking) [??], onde propriedades desejadas podem ser verificadas no modelo que especi-fica o contrato. A propriedade que define um contrato livre de conflitos pode ser descritacomo: dada qualquer sequência de ações que não viola o contrato, a execução do contratonão termina num estado que ocorre um conflito". Para todas os caminhos de computa-ção válidos no modelo, nenhum destes caminhos pode chegar a um estado conflitante.A semântica de traces da 𝐶𝐿 é então adaptada por Fenech [??] para possibilitar essaverificação.

Relação de conflito: é uma relação simétrica e irreflexiva sobre as ações básicas de𝐴𝐵 denotada por # ⊆𝐴𝐵 × 𝐴𝐵. Essa relação é comumente usada em contratos legais ondeduas ações não podem ocorrer ao mesmo tempo. Num exemplo simples, uma ação 𝑑𝑖𝑟𝑖𝑔𝑖𝑟

conflita, segundo as leis de trânsito, com as ações 𝑏𝑒𝑏𝑒𝑟 e 𝑓𝑎𝑙𝑎𝑟 𝑎𝑜 𝑐𝑒𝑙𝑢𝑙𝑎𝑟. A equaçãodessa relação é então dada por 𝑎#𝑏 → 𝑎×𝑏 = 0 |∀ 𝑎, 𝑏 ∈ 𝐴𝐵, onde 𝑎 representa a ação𝑑𝑖𝑟𝑖𝑔𝑖𝑟 e 𝑏 representa 𝑏𝑒𝑏𝑒𝑟. Da mesma forma, a equação 𝑐#𝑎 determina que a ação 𝑓𝑎𝑙𝑎𝑟

𝑎𝑜 𝑐𝑒𝑙𝑢𝑙𝑎𝑟, representada por 𝑐, conflita com 𝑑𝑖𝑟𝑖𝑔𝑖𝑟. Note que não há transitividade narelação de conflito, não ocorrendo um conflito com 𝑓𝑎𝑙𝑎𝑟 𝑎𝑜 𝑐𝑒𝑙𝑢𝑙𝑎𝑟 e 𝑏𝑒𝑏𝑒𝑟, por exemplo[4].

Violação de contrato: só ocorre com operadores de Obrigação (𝑂) ou de Proibição(𝐹 ). Como no operador de Permissão (𝑃 ) a ação é facultativa, não há garantia de suaexecução. Quando uma ação obrigatória não é executada ou quando uma ação proibidaé executada, ocorre uma violação. No entanto, de acordo com os conceitos de penalidadee reparação, descritos anteriormente, uma compensação pode ser imposta para evitaruma violação em todo contrato. A 𝐶𝐿 define um conceito de complemento de ação querepresenta a violação sobre uma obrigação. O complemento de uma ação é a execução dequalquer outra ação ou sequência de ações do conjunto de ações básicas 𝐴𝐵, denotadopor 𝛼, e obtido pela função 𝑓 : 𝐴𝐷 → 𝐴𝐷. Seja um conjunto de ações básicas 𝐴𝐵 = 𝑎, 𝑏,alguns exemplos de complementos são: 𝑎 = 𝑏 é qualquer ação diferente de 𝑎, portanto, aúnica alternativa é 𝑏. Já no caso de 𝑎 · 𝑏 = 𝑏 + 𝑎 · 𝑎, o complemento das ações 𝑎 e 𝑏 emsequência pode ser a ação 𝑏 ou a ação 𝑎 duas vezes seguidas [4].

39

3 TRABALHOS RELACIONADOS

3.1 Linguagem de contratos relativizada (RCL)

3.2 Relacionando Modelos Formais com o Processo de Negócio

Guido Governatori trás um tutorial, "Business Process Compliance", apresentadono JURIX de 2009, mostrando brevemente como relacionar as especificações formais doprocesso de negócio com especificações formais para documentos legais, como a lógicadeôntica.

41

4 CONCLUSÃO

43

REFERÊNCIAS

[1] P.E. AGRE. Formalization as a Social Project. Quarterly Newsletter of theLaboratory 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 sistemasinformatizados: 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 ofComputer 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. Logica deontica, março.

[10] FISCHER, M. J.; LADNER, R. E. Propositional dynamic logic of regular programs.Journal of Computer and System Sciences. 1979.

[11] HERRESTAD, H.; KROGH, C. Deontic logic relativised to bearers andcounterparties. In: Proceedings of the Anniversary of Anthology in Computers andLaw. Tano A.S., 1995.

[12] P.; VONK J. KOETSIER, M.; GREFEN. Contracts for cross-organizationalworkflow management. Springer Berlin Heidelberg, 2000.

[13] von Wright, G. H. Deontic logic. Oxford University Press, 1951.

[14] M. P. UDUPI, Y. B.; SINGH. Contract enactment in virtual organizations: Acommitment-based approach. AAAI Press, 2006.

[15] C.; SCHNEIDER G. PACE, G.; PRISACARIU. Model checking contracts a casestudy. Springer Berlin Heidelberg, 2007.

[16] KYAS, M.; PRISACARIU, C.; SCHNEIDER, G. Runtime monitoring of electroniccontracts. Springer-Verlag, 2008.

[17] CHELLAS, B. F. Modal Logic: an introduction. Cambridge University Press, 1980.

[18] BLACKBURN, P.; BENTHEM, J. van; WOLTER, F. Handbook of Modal Logic.Elsevier Science, 2006.

[19] HAREL, D.; KOZEN, D.; TIURYN, J. Dynamic logic. MIT Press, 1984.

44

[20] C.; SCHNEIDER G. PACE, G.; PRISACARIU. A formal language for electroniccontracts. Springer, 2007.

[21] MCNAMARA, P. Deontic logic: Challenges to standard deontic logics. Disponívelem: http://plato.stanford.edu/entries/logic-deontic/.

[22] PRAKKEN, H.; SERGOT, M. Contrary-to-duty obligations. Studia Logica, 1996.

[23] KYAS, M.; PRISACARIU, C.; SCHNEIDER, G. Run-time Monitoring of ElectronicContracts-theoretical results. S.l., 2008.

[24] MONTAZERI, S. M.; ROY, N.; SCHNEIDER, G. From Contracts in StructuredEnglish to CL Specifications. 5th International Workshop on Formal Languagesand Analysis of Contract-Oriented Software Málaga, Spain: [s.n.], 2011.

[25] MARTINEZ, E. A Model for Visual Specification of e-Contracts. The 7th IEEEInternational Conference on Services Computing (IEEE SCC’10) IEEE ComputerSociety, 2010

[26] KROGH, C.; HERRESTAD, H. Individuals Obligations. 1994.

[27] TAN, Y.-h.; THOEN, W. A logical model of directed obligations and permissionsto support electronic contracting in electronic commerce. International Journal ofElectronic Commerce. Formal aspects of digital commerce, 1998.

Apêndices

47

APÊNDICE A –

Anexos

51

ANEXO A –