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 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. 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.