d3.2 visual environment for service description · 2017. 4. 12. · file:...

Visual Environment for Service Description

Project acronym: COMPAS

Project name: Compliance-driven Models, Languages, and Architectures for Services

Call and Contract: FP7-ICT-2007-1

Grant agreement no.: 215175

Project Duration: 01.02.2008 – 28.02.2011 (36 months)

Co-ordinator: TUV Technische Universitaet Wien (AT)

Partners: CWI Stichting Centrum voor Wiskunde en Informatica (NL)

UCBL Université Claude Bernard Lyon 1 (FR)

USTUTT Universitaet Stuttgart (DE)

TILBURG UNIVERSITY Stichting Katholieke Universiteit Brabant (NL)

UNITN Universita degli Studi di Trento (IT)

TARC-PL Telcordia Poland (PL)

THALES Thales Services SAS (FR)

PWC Pricewaterhousecoopers Accountants N.V. (NL)

This project is supported by funding from the Information Society Technologies Programme under the 7th

Research Framework Programme of the European Union.

D3.2

Version: 1.4 Date: 2009-07-31

Dissemination status: PU Document reference: D3.2

FP7-215175 COMPAS D3.2v1.0

File: D3.2_Visual-environment-for-service-description of 47

Project no. 215175

COMPAS

Compliance-driven Models, Languages, and Architectures for Services

Specific Targeted Research Project

Information Society Technologies

Start date of project: 2008-02-01 Duration: 36 months

D3.2 Visual Environment for Service Description Revision 1.0

Due date of deliverable: 2009-07-31

Actual submission date: 2009-07-31

Organisation name of lead partner for this deliverable:

CWI Stichting Centrum voor Wiskunde en Informatica, NL

Contributing partner(s):

UCBL Université Claude Bernard Lyon 1, FR

Project funded by the European Commission within the Seventh Framework Programme Dissemination Level

PU Public X PP Restricted to other program participants (including the Commission Services) RE Restricted to a group specified by the consortium (including the Commission Services) CO Confidential, only for members of the consortium (including the Commission Services)

FP7-215175 COMPAS D3.2v1.0


History chart Issue Date Changed page(s) Cause of change Implemented by 0.1 2009-06-18 All sections New document CWI 0.2 2009-06-22 Section 3 Description of converting tools has

been added CWI

0.3 2009-06-25 Section 3 Description of the Reo editor and model checking tools has been added

CWI

0.4 2009-06-26 Introduction, Section 3

Introduction and description of the constraint automata editor has been added.

CWI

0.5 2009-06-29 Section 4 Models of compliant process fragments have been added

CWI

0.6 2009-06-30 Section 3 Description of the model checking tools refined

CWI

0.7 2009-07-02 Section 2, Section 3.6

Tool integration and evaluation of tool prototypes has been added.

CWI

0.8 2009-07-03 All sections, Section 8, Appendix A

References to figures and conclusions have been added

CWI

0.9 2009-07-09 Introduction, Section 7

Abbreviation index and related work have been added

CWI

1.0 2009-07-13 All sections Minor editing CWI 1.1 2009-07-16 All sections Internal revision and proofreading CWI 1.2 2009-07-23 Section 3,

Section 5 Review comments from TUV (RV-TUV-D3.2rev984) have been addressed

CWI

1.3 2009-07-24 All sections Review comments from TILBURG (RV_USTUTT_D3.2rev914.doc) and USTUTT (RV_USTUTT_D3.2rev914.doc) have been addressed

CWI

1.4 2009-07-27 All sections Review comments from UNITN (RV_UNITN_D3.2rev999.doc) and UCBL (UCBL_D3.2rev-01.doc) have been addressed

CWI

Authorisation No. Action Company/Name Date 1 Prepared CWI 2009-07-27 2 Approved TUV 2009-07-31 3 Released TUV 2009-07-31

Disclaimer: The information in this document is subject to change without notice. Company or product names mentioned in this document may be trademarks or registered trademarks of their respective companies.

All rights reserved.

FP7-215175 COMPAS D3.2v1.0


The document is proprietary of the COMPAS consortium members. No copying or distributing, in any form or by any means, is allowed without the prior written agreement of the owner of the property rights.

This document reflects only the authors’ view. The European Community is not liable for any use that may be made of the information contained herein.

FP7-215175 COMPAS D3.2v1.0


Contents 1. Introduction ................................................................................................................................. 8

1.1. Purpose and scope................................................................................................................ 9

1.2. Document overview ............................................................................................................. 9

1.3. Definitions and glossary ...................................................................................................... 9

1.4. Abbreviations and acronyms............................................................................................. 10

2. Tool integration ......................................................................................................................... 11

2.1. Integration with Compliance Language Runtime Environment ..................................... 13

3. Visual Environment for Service Description .......................................................................... 14

3.1. Converters .......................................................................................................................... 14

3.1.1. UML Sequence Diagrams to Reo Converter ............................................................ 14

3.1.2. BPEL to Reo Converter ............................................................................................. 15

3.1.3. BPMN to Reo Converter............................................................................................ 17

3.2. Graphical editors ................................................................................................................ 18

3.2.1. Reo editor .................................................................................................................... 18

3.2.2. Constraint Automata editor........................................................................................ 20

3.3. Verification tools ............................................................................................................... 21

3.3.1. Reo animation (simulation) plug-in .......................................................................... 21

3.3.2. Vereofy model checker .............................................................................................. 23

3.3.3. mCRL2 tool set........................................................................................................... 25

3.3.4. PRISM model checker ............................................................................................... 27

4. Using ECT for process analysis: control flow requirements.................................................. 28

5. Compliance-aware process modeling ...................................................................................... 32

5.1. Thales case study ............................................................................................................... 33

5.2. SoD in sequential processes .............................................................................................. 34

5.3. SoD in parallel processes .................................................................................................. 35

5.4. Privacy requirements ......................................................................................................... 36

5.5. Time-aware business processes ........................................................................................ 37

5.6. Encryption/Decryption ...................................................................................................... 38

6. Evaluation of Tool Prototypes ................................................................................................. 38

7. Related work ............................................................................................................................. 40

8. Conclusions and Future Work .................................................................................................. 43

9. Reference documents ................................................................................................................ 44

9.1. Internal documents ............................................................................................................ 44

9.2. External documents ........................................................................................................... 44

FP7-215175 COMPAS D3.2v1.0


Appendices .................................................................................................................................. 47 A. Appendix A .............................................................................................................................. 47

A.1. BPMN model for the THALES Case Study (preliminary version) ............................... 47

List of figures Figure 1 Overall COMPAS architecture ................................................................................ 12

Figure 2 UMLSDs2Reo converter: UML SD designed in Bouml ....................................... 14

Figure 3 UMLSDs2Reo converter: exporting UML SDs ..................................................... 15

Figure 4 BPEL2Reo converter: input file .............................................................................. 16

Figure 5 BPEL2Reo converter: output file ............................................................................ 17

Figure 6 BPMN2Reo converter: input file ............................................................................ 18

Figure 7 Reo editor.................................................................................................................. 18

Figure 8 Converting Reo diagram to a component ............................................................... 20

Figure 9 Constraint automata editor ....................................................................................... 21

Figure 10 Reo animation (simulation) view ............................................................................ 22

Figure 11 Reo animation (simulation) view: user preferences ............................................... 23

Figure 12 Vereofy model checker: user preferences............................................................... 24

Figure 13 Vereofy model checker: selected connector and formula editor ........................... 24

Figure 14 Vereofy model checker: verification results ........................................................... 25

Figure 15 mCRL2 model generation........................................................................................ 27

Figure 16 LTS generated for a sample mCRL2 script ............................................................ 27

Figure 17 BPMN diagram for the loan request process. ......................................................... 29

Figure 18 Reo circuit for the loan request process. ................................................................. 30

Figure 19 CA for the loan request process: Internal view ...................................................... 31

Figure 20 CA for the loan request process with a deadlock: External view.......................... 31

Figure 21 Refined BPMN for the loan request scenario ......................................................... 32

Figure 22 Reo process model for the refined loan request scenario ...................................... 32

Figure 23 CA for the refined loan request process: External view ........................................ 32

Figure 24 Check fragment: UML activity diagram ................................................................. 33

Figure 25 Check fragment: Reo model .................................................................................... 34

Figure 26 Modeling a sequential process with SoD constraints in Reo ............................... 34

Figure 27 Modeling a parallel process with segregation of duties in Reo ............................. 36

Figure 28 Modeling time-aware business processes: Reo model........................................... 38

Figure 29 Modeling time-aware business processes: TCA model ......................................... 38

FP7-215175 COMPAS D3.2v1.0


List of tables Table 1 Input, output and the main functionalities of the Compliance Language Request Tools 13

Table 2 Input, output and the main functionalities of Process Verification tools ............. 13

List of listings Listing 1 mCRL2 model for basic Reo channels and nodes ................................................. 26

FP7-215175 COMPAS D3.2v1.0


Abstract This deliverable presents visual tool prototypes for service specification and verification based on the formal behavioral model discussed in the deliverable D3.1 [D3.1]. The presented toolset includes graphical editors for the domain-level process modeling (BPMN, UML SDs and BPEL), a set of model transformation tools that enable automated conversion of these diagrams to their formal representation (Reo process models), a visual environment for editing and analyzing formalized processes (Reo editor and Reo animation engine) and their underlying semantic models (Constraint Automata (CA) editor), as well as a number of model checking tools for automated process verification. We outline the main functionalities of these tools, and illustrate their application for the analysis of process fragments developed for the THALES case study [D6.1].

1. Introduction Every time the essential regulations, laws, safety recommendations, agreements, contracts or policies change, an organization encounters the problem of inspecting its processes and supporting software in order to make them compliant to the new versions of these documents or novel regulations that are relevant for this business area. Similar needs emerge when business processes, sub-processes or services provided or consumed by an organization have been modified, substituted or disappeared from the market. In such cases, businesses that adopt Service-Oriented Architecture (SOA) may avoid technical difficulties to rebuild their systems by using new services with standard interfaces, but still risk to affect the behavior of the underlying processes, their trustworthiness and interoperability, violate important agreements and contract conditions or overlook relevant legislative requirements.

According to the COMPAS approach [DoW], the majority of compliance challenges can be addressed by a proper composition of compliant services and process fragments. For example, if a medical organization needs to comply to access control policies prescribed by HIPAA, or an insurance company meets the need to integrate disparate data sources to provide the customer information profile as required by the PATRIOT Act [Gra04], they may adopt a set of core services supplied by IT vendors such as IBM, BEA, Sun, etc. with the required functionality, thus, avoiding the need to develop their own solutions. However, the integration of these services into existing infrastructure may be troublesome by itself. Conceptual errors or flaws in designed processes or service compositions may as well result in failure to comply with necessary regulations and, consequently, unimaginable profit loss or failure of the entire enterprise.

Therefore, it is essential to detect possible conflicts in business process models. Verification of process model conformance to a set of functional and non-functional requirements, including compliance concerns, can help to alleviate these problems. The research community offers numerous models, languages, techniques and tools for safe and verifiable process design. However, the application of these techniques to the development of real–world systems remains very limited due to their high implementation costs. In this deliverable, we aim at providing a solution for formal design and analysis of business processes and web service compositions that is both powerful and relatively easy to apply in practice. We present an integrated toolset that supports process design and verification with the help of the Reo coordination language, and its semantic model, Constraint Automata (CA), extended to incorporate various kinds of data for compliance analysis, as discussed in Deliverable 3.1. This toolset includes graphical editors for the domain-level process modeling (BPMN, UML SDs and BPEL), a set of model transformation tools that enable automated conversion of

FP7-215175 COMPAS D3.2v1.0


these diagrams to their formal representation (Reo process models), a visual environment for editing and analyzing formalized processes (Reo editor and Reo animation engine) and the corresponding behavioral models (Constraint Automata (CA) editor), as well as a number of reasoning tools for automated process verification (essentially, Vereofy model checker, PRISM model checker and mCRL2 model checking toolset). We outline the main functionalities of these tools, provide brief instructions on how to use them and illustrate by examples their application to the design of dependable and compliant service-based applications.

1.1. Purpose and scope According to the Description of Work of the COMPAS project [DoW], the purpose of the deliverable D3.2 is to present a prototype of the visual environment for service description. By service we mean an abstract entity consisting of a set of capabilities offered by providers to consumers. The capabilities of the service and information about how to use these capabilities are described in a service description. A service can be realized by human beings, information systems, machines or processes. A business process is a composition of activities into a structured order that implements the procedure to be followed in order to achieve a business goal. In this deliverable, we consider business processes adopted by an organization or a consortium to realize their services. Thus, business processes define behavior of services provided to customers, while services represent parts of business processes observable by customers. We often use these two terms interchangeably, meaning that we model business processes that realize services.

This deliverable presents visual tools for supporting formal business process/service design and verification using the Reo/CA-based model introduced in the Deliverable D3.1. Furthermore, we provide a detailed description of the proposed framework and illustrate the intended use of the involved tools through a number of didactic examples extracted from the COMPAS case studies [D6.1].

1.2. Document overview The rest of this report is structured as follows. Section 2 places the presented tools in the context of the COMPAS architecture and explains their integration with other (most notably, WP2) tools. Section 3 overviews WP3 tool functionality and gives basic instructions on their installation and usage. Section 4 explains by example how the presented framework can be applied for business process verification, in particular, to reason about process soundness. In Section 5, we give examples of more advanced process analysis that require reasoning about compliance rules identified for the THALES case study. Section 6 overviews related work and compares our approach to existing solutions. Section 7 draws conclusions and outlines our future work.

1.3. Definitions and glossary The most important terminology concerning the COMPAS project is listed on the public COMPAS Web-Site [D7.1] available at http://www.compas-ict.eu section terminology. This helps to make the overall COMPAS approach more comprehensive for the general public.

In the following the definitions of terms valid only in the scope of this deliverable and therefore not listed on the public COMPAS Web-Site [D7.1] are specified:

http://www.compas-ict.eu/�

FP7-215175 COMPAS D3.2v1.0


Service: an abstract entity consisting of a set of capabilities offered by one or more providers to consumers.

Reo process model: a business process model represented as a Reo circuit (also called network or connector).

1.4. Abbreviations and acronyms Abbreviation Complete Term ACP Algebra of Communicating Processes

ASL Alternating-time Stream Logic

BPEL Business Process Execution Language

BPML Business Process Modeling Language

BPMN Business Process Modeling Notation

CA Constraint Automata

CSL Continuous Stochastic Logic

CTL Computation Tree Logic

CTMC Continuous-Time Markov Chains

DTMC Discrete-Time Markov Chains

ECT Eclipse Coordination Tools

EPC Event-driven Process Chains

FSM Finite State Machine

LTL Liner Temporal Logic

LTS Labelled Transition System

mCRL2 micro Common Representation Language 2

MDP Markov Decision Processes

MRMC Markov Reward Model Checker

OCL Object Constraint Language

PBES Parameterised Boolean Equation System

PCTL Probabilistic Computation Tree Logic

QIA Quantitative Intentional Automata

RBAC Role-Based Access Control

SLA Service Level Agreement

SD Sequence Diagram

SMV Symbolic Model Verifier

SOX Sarbanes-Oxley Act

UML Unified Modeling Language

FP7-215175 COMPAS D3.2v1.0


WP Work Package

WSDL Web Service Description Language

XMI XML Metadata Interchange

2. Tool integration Our goal in the current report is to provide a sufficient description of the tool prototypes developed in WP3. These tools aim at visual process/service specification and their formal analysis. The framework presented here covers Converters, Reo editor and Process verification tools which constitute the Process verification environment of the overall COMPAS architecture (see Figure 1). The integration of process verification tools with other parts of the COMPAS architecture is performed via a set of links representing data exchanges between involved logical elements, namely, Process Fragments, Selected Process Fragments and Specification of Compliance that provide us with necessary information about business processes that have to be verified against formalized compliance requirements. The graphical Reo editor can be exploited as an environment for composing process fragments after their conversion to Reo circuits.

Verification results are then used by other partners to improve the process fragments and models stored in the Process Fragment and Model Repositories, managed by WP4 and WP1, respectively, and recompose services and process fragments to make an underdevelopment process compliant to the specification. The special role in the integration of verification tools belongs to the WP2 Compliance Language Request Tools which ensure the back-tracking of transformation chains from compliance sources to requirements, policies and, finally, rules expressed as logical formulas. Verification results produced by the WP3 tools are sent back to the WP2 tools in order to establish what compliance policies have been violated, reconfigure the process by selecting new process fragments, and/or update the information in the Process Fragment and/or Model Repositories.

At the same time, WP2 tools define the functional requirements for the process verification; in particular, property specification formats that need to be supported by the involved model checking tools to address a certain compliance issue. In particular, current implementation of the verification tools supports the linear-time temporal logic with data parameters required by the initial specification of compliance language constructs and operators introduced in the deliverable D2.2 [D2.2].

In the following subsections, we briefly describe the main functionalities of the Compliance Language Runtime Environment according to the information provided by the WP2 partners and relate them to the WP3 tools.

FP7-215175 COMPAS D3.2v1.0


Figure 1 Overall COMPAS architecture

FP7-215175 COMPAS D3.2v1.0


2.1. Integration with Compliance Language Runtime Environment

Table 1 shows input, output and the main functionalities of the Compliance Language Runtime Environment. For more details about this environment please refer to the deliverable D2.3 [D2.3]. The Process Verification tools are dependent on the output of these tools. As can be seen from Table 2, selected compliance targets (e.g., process fragments) and formalized compliance rules constitute the necessary information used as input for the Process Verification tools.

Main functionalities Input Output The matching of the set of rules against the Model and/or Process Fragment Repository to return the sets of compliance targets that can be composed into an end-to-end business process model.

A link to the Model and/or Process Fragment Repository.

A set of candidate compliance targets (e.g., annotated BPMN diagrams and/or BPEL specifications).

The automatic mapping between the rules specified in a form of (graphical) patterns to LTL formulas

A set of applicable compliance constraints (e.g., a section in a legislation act, regulatory body, etc.)

A set of LTL rules representing compliance requirements in a human-understandable format

Table 1 Input, output and the main functionalities of the Compliance Language Request Tools

Main functionalities Input Output Conversion of candidate process fragments and sub-processes to their formal representation, disambiguation, refinement, composition and preliminary analysis using graphical editors and simulation/animation views.

A set of candidate compliance targets (e.g., annotated BPMN diagrams and/or BPEL specifications).

A set of formal models for the candidate compliance targets (Reo circuits and automata-based models).

Conversion (manual) of LTL rules to machine understandable format (suitable for formal verification).

A set of LTL rules representing compliance requirements

A set of LTL rules in a machine understandable form bound to the formal process models.

Verification of candidate compliance targets (e.g., process fragments) against LTL rules.

A set of formal models for given compliance targets (Reo and automata-based models). A set of LTL rules in a machine understandable form bound to the formal process models.

Verification results: whether a certain formula holds for a given compliance target, and if not, the justification (counterexample).

Table 2 Input, output and the main functionalities of Process Verification tools

At the technical level, the integration between WP2 and WP3 is performed using a web service that accepts a file with verification request (compliance target and its specification format (UML/BPMN/BPEL), a file with compliance rules and annotations, if needed) as input and provides a file with the verification results as output. Since the process analysis includes some manual activities (essentially, translation of compliance rules to the appropriate format), this web service notifies a technical expert about a new verification request and stores it in an internal repository for further processing.

FP7-215175 COMPAS D3.2v1.0


3. Visual Environment for Service Description This section introduces the Eclipse Coordination Tools (ECT), a framework for verifiable design of service-based software using the coordination language Reo. The framework consists of a set of integrated tools that are implemented as plug-ins for the Eclipse platform. Currently, ECT provides functionality for converting high-level business process models to Reo, editing and animating Reo process models, generating and editing extended CA from Reo, annotating Reo/CA with QoS constraints and verifying these models using three model checking tools.

The following software is required to run the tools:

• Java 5 or higher,

• Eclipse 3.4 (Ganymede) or higher,

• Adobe Flash or Gnash Browser Plug-in.

The ECT plug-ins can be installed using the Eclipse update manager. To install the coordination tools, add a remote update website http://reo.project.cwi.nl/update in the update manager. More detailed instructions about installing ECT can be found in the Reo project home page at http://reo.project.cwi.nl/cgi-bin/trac.cgi/reo/wiki/Tools.

3.1. Converters The ECT provides three converting tools to translate BPMN, UML diagrams and BPEL specifications to Reo process models. In this section, we describe the high-level process modelling tools for developing BPMN/UML models that can be imported to our framework and explain how the conversion is performed.

3.1.1. UML Sequence Diagrams to Reo Converter UMLSDs2Reo converter accepts as input UML SDs designed in Bouml http://bouml.free.fr, a free UML2 tool box running under all major operating systems. Figure 2 shows a screenshot with a sample sequence diagram model\led in this tool.

Figure 2 UMLSDs2Reo converter: UML SD designed in Bouml

http://reo.project.cwi.nl/update�

http://reo.project.cwi.nl/cgi-bin/trac.cgi/reo/wiki/Tools�

http://bouml.free.fr/�

FP7-215175 COMPAS D3.2v1.0


Most of the UML2 tools, including Bouml, provide facilities to export their models in the XMI format. The UML SDs designed in Bouml can be exported using the menu command Tools → Generate XMI 2.1. Figure 3 shows the screenshot of the export dialogue.

Figure 3 UMLSDs2Reo converter: exporting UML SDs

For importing the generated XMI to the ECT, right-click on the appropriate project folder in the Eclipse Package Explorer, choose Import → File System and input the file name with the XMI model. In order to convert the imported model to Reo, right-click on the opened file and choose Convert Sequence Diagram → To Reo. After that, a Reo process model corresponding to the UML SD can be visualized in the Reo editor. More details about the Reo editor will be given in Section 3.2.1.

3.1.2. BPEL to Reo Converter BPEL2Reo converter is a tool provided by the University of Tehran for converting BPEL process specifications to Reo. Since this tool is still under development, it has not been included in the ECT release. It can be downloaded using the following URL http://ece.ut.ac.ir/msirjani/B2ReoTool/B2R.jar and run in the Eclipse environment as a Java application via menu Run → Run As → Java Application. In the window with a list of executable Java applications, choose Application – ir.ac.ut.B2R. After that, a BPEL to Reo converter window will be opened. In order to import a BPEL process, click File → Open and input a process file name. The selected BPEL process will be shown in the editor along with its logical structure on the left side of the window as shown in Figure 4.

http://ece.ut.ac.ir/msirjani/B2ReoTool/B2R.jar�

FP7-215175 COMPAS D3.2v1.0


Figure 4 BPEL2Reo converter: input file

In order to convert the selected BPEL process to Reo, click Map → Go . The status of the conversion (successful translation or exception) will be displayed in the bottom line of the window (see Figure 5). In the case of successful translation, the resulting Reo process model appears in the same window. Two output formats are supported. An XML representation of the generated model can be seen under the XML Reo tab. It includes only the information about the Reo circuit and can be used, e.g., for obtaining statistical data about the model such as the number of buffer channels, variables or input/output ports. The second representation under the tab CWI Reo contains the graphical information for the model visualization in the ECT environment. Save this model by clicking File → Save → [file path] and open it in the Reo editor.

FP7-215175 COMPAS D3.2v1.0


Figure 5 BPEL2Reo converter: output file

3.1.3. BPMN to Reo Converter BPMN2Reo converter accepts as input file a BPMN diagram developed with the Eclipse BPMN Modeler plug-in available at http://www.eclipse.org/bpmn/ or with the Intalio BPMN Designer available at http://www.intalio.com/products/downloads/. For creating a new BPMN diagram using the BPMN Modeler, click File → New → Other → BPMN diagram, and choose a path and a file name for saving the model. In order to convert the BPMN diagram to Reo, right-click on the imported file in the Package Explorer section of the Eclipse environment, choose Convert to Reo as shown in Figure 6, and specify a path file for the output. This file then can be opened in the Reo editor (see Figure 7). Use the toolbar or the pop-up menu command Arrange All and drag and drop features to rearrange the elements of the generated Reo model.

http://www.eclipse.org/bpmn/�

http://www.intalio.com/products/downloads/�

FP7-215175 COMPAS D3.2v1.0


Figure 6 BPMN2Reo converter: input file

3.2. Graphical editors This section presents graphical editors for creating and analyzing formal process models, namely, the Reo editor, which is a core tool of the ECT and the CA editor, which allows designers to see and modify CA models generated from Reo.

3.2.1. Reo editor For graphical specification of formalized process models, ECT includes a graphical Reo editor. This editor also serves as a bridge to other tools, including the conversion, animation and verification tools. A screenshot of the Reo graphical editor is given in Figure 8. The network shown in this screenshot is equivalent to the one generated from the BPMN in Figure 6 and will be later used as our running example (see Section 4 for a description and detailed analysis of this process).

Figure 7 Reo editor

FP7-215175 COMPAS D3.2v1.0


The palette on the right-hand side of the editor contains a number of tools for adding elements to a Reo diagram.

Connectors and components are the root elements in a Reo diagram. Connectors serve as containers for nodes and channels. On the other hand, components have no internal structure. They have a name and public interface, which consists of a set of input ports and output ports. Components may be further initialized using properties, which are basically key-value pairs.

For verification purposes, the editor includes readers and writers as special primitive components with predefined interfaces and a fixed behavior. Defining a network is done by connecting the boundary nodes of connectors with ports of components. These connections are called links. However, note that links are not Reo channels – they just indicate that a port of a component is attached to a boundary node of a connector. This is done for a better graphical representation as it allows one to separate connectors from components.

Channels are user-defined primitives in Reo. Nevertheless, the Reo editor includes a number of standard channel types that are useful in a number of scenarios. The detailed description of these channels is given in Section 3.4 of Deliverable D3.1 [D3.1].

Reo distinguishes several types of nodes. Nodes where only source ends of channels coincide are called source nodes, nodes where only sink ends coincide are called sink nodes. Collectively, they form the boundary nodes of a connector, which interact with its environment. Nodes where both source ends and sink ends meet are called mixed nodes. Mixed nodes are internal and not accessible from the outside. In the editor and the animation tool, mixed nodes are represented as black circles and boundary nodes as white circles.

In contrast to channels, the behavior of nodes is predefined by Reo. Source nodes replicate available data items to all of their coinciding source ends, which is why they are sometimes also referred to as replicators. On the other hand, sink nodes merge the input from their sink ends. A sink node accepts data from one of its sink ends and prohibit data flow at all other sink ends at the same time. Sink nodes are also referred to as (nondeterministic) mergers. A mixed node is a combination of a merger and a replicator. Mixed nodes merge data on the sink ends and replicate them on their source ends. It is important to note here that nodes never buffer data.

Once a Reo diagram has been created, it can be converted to a component for further reuse. This can be accomplished by right clicking on the selected diagram and choosing Convert to Component. A new component primitive will be created (see Figure 8). The observable behavior of this component is specified in terms of incoming/outgoing message flows and can be seen in its Property view under Animations tab. The editor also provides utilities for validating, formatting or minimizing behavioral descriptions of the generated components.

FP7-215175 COMPAS D3.2v1.0


Figure 8 Converting Reo diagram to a component

ECT has built-in support for defining and executing rule-based reconfigurations of Reo models which can be useful for guided process adaptation (e.g., for transforming a non-compliant business process to a compliant one by adding special process fragments such as data encryption/decryption to necessary places of the process). The user manual on how to use the reconfiguration plug-in can be found in http://reo.project.cwi.nl/cgi-bin/trac.cgi/reo/wiki/ReconfigurationSupport.

3.2.2. Constraint Automata editor A CA model of a Reo diagram can be obtained by right clicking on the selected connector and choosing Convert to Extensible Automaton. A user dialog will be opened to ask for a path to store the automaton, as well as to user preferences about the type of the automaton to be generated. Choose CA transformer (.ea) and in the next window check port names to be hidden (by default, all internal ports will be selected for hiding). After that, a CA model will be created (see Figure 9). By right clicking on the selected model, one can modify the generated automata, e.g., add or remove nodes, hide or show constraint labels, remove or add silent transitions, compute the product of several automata, and so on.

http://reo.project.cwi.nl/cgi-bin/trac.cgi/reo/wiki/ReconfigurationSupport�

http://reo.project.cwi.nl/cgi-bin/trac.cgi/reo/wiki/ReconfigurationSupport�

FP7-215175 COMPAS D3.2v1.0


Figure 9 Constraint automata editor

This model represents an input for the verification and code generation tools supported by the ECT.

3.3. Verification tools Automated verification is a powerful means for detecting behavioral errors and inconsistencies in business processes and web service compositions that otherwise maybe difficult to find and reproduce. Currently, ECT provides an animation tool which can be used to simulate Reo process execution, and supports three model checking tools able to test whether a Reo process model meets some specification. One of these tools, the Vereofy model checker, has been specifically developed to reason about extended CA. The other two model checkers, mCRL2 and PRISM, are external tools adopted to verify Reo process models via model transformation. Given a Reo circuit (if needed, annotated with QoS data such as cost or transmission delay), ECT automatically generates inputs files for the mCRL2 and PRISM toolsets. In this section, we describe the basic functionality of the aforementioned tools focusing on their integration in our environment.

3.3.1. Reo animation (simulation) plug-in To verify the behavior of Reo process models, ECT includes an animation tool which generates Flash animations from Reo connectors. The animation view window can be opened using the menu Window →Show View →Other → Reo → Animation. To see the animated execution of a selected connector, press Synchronize Animation button on a tool bar in the right corner of this window. The plug-in will depict the connector shown in the editor in the animation view and generate a list of possible execution scenarios. The parts of the connector highlighted blue represent synchronous data flow. Tokens move along these synchronous regions. One can switch between plain mode demonstrating all possible execution alternatives for the whole process and a guided mode illustrating each execution step separately using the

FP7-215175 COMPAS D3.2v1.0


Enable Guided Animations button on the toolbar. Figure 10 shows a list of animations for a connector shown in Figure 7.

Figure 10 Reo animation (simulation) view

Animations are generated from the so-called coloring semantics of Reo. The idea of the coloring semantics is to assign data flow colors to nodes in a connector. In the basic case, two colors are used to indicate the presence or absence of data flow. Every channel provides a list of valid colorings, which is called its coloring table. To compute the coloring table of a connector, the coloring tables of all channels of the connector are composed using a join operation. This join operation basically merges colorings that are compatible with each other, i.e., which assign the same color to common nodes. The resulting coloring table describes the data flow in the connector, or – if the components (services) are included – of the component (service)-based system model. The coloring scheme with two data flow colors is a model that captures synchronization and mutual exclusion constraints on the data flow. By adding a third color, one can further express context-dependent behavior that is required for a correct modeling of some primitives, such as the LossySync channel. Recall, that the intuitive behavior of this channel is as follows: it always accepts a data item at its source node and either loses it or transmits it to its sink end depending on whether a channel or a component connected to the sink end is ready to accept the item.

One can switch between 2-colour and 3-colour semantics using Window → Preferences → Reo → Animation menu. Other settings can be modified using this window as well (see Figure 11). For example, traversal option defines a type of Reo graph traversal (depth first, breadth first or mixed) which can be used to optimize the generation of animated executions for large process models.

FP7-215175 COMPAS D3.2v1.0


Figure 11 Reo animation (simulation) view: user preferences

3.3.2. Vereofy model checker With the help of the Reo animation plug-in, designers can observe whether certain requirements hold for a given process or not. However, in many situations, especially for the middle and large-size industrial projects, such user-guided verification is not sufficient. Instead a developer has to specify a set of properties in a formal way and test automatically whether a Reo process model meets this specification.

The native model checker for verifying Reo process models using their CA-based semantics is Vereofy. It can be installed from the Eclipse update web site http://vereofy.de/eclipse/update. For model checking, CA are associated with an arbitrary finite data domain, which collects all possible data items exchanged through the corresponding Reo circuit or stored within the local variables of the components. The default data domain used for the control flow analysis is int(0,1). Data is a global data type, which in the current version of the tool can be Bool, int, or enum, depending on the user settings. These settings can be changed in the preferences view shown in Figure 12 by defining Extra Arguments for Vereofy. The complete list of all arguments can be found in the Vereofy manual [BKK+08].

http://vereofy.de/eclipse/update�

FP7-215175 COMPAS D3.2v1.0


Figure 12 Vereofy model checker: user preferences

Vereofy supports linear and branching-time model checking. Properties of the Reo circuits are specified either in Linear Temporal Logic (LTL) or Alternating-time Stream Logic (ASL), a CTL-like branching-time logic which allows one to express conditions on data flow in channel nodes using regular expressions and supports reasoning about existence or absence of a coalition's strategy to achieve or avoid a specific temporal goal given the behavioral specification of each component. For switching between these two formats, use the check box in the Vereofy window. Syntax, available operators and their mapping from the rich text format to the reduced text format for both specification languages are explained in the Vereofy manual [BKK+08].

Figure 13 Vereofy model checker: selected connector and formula editor

A formally specified process property can be verified by clicking Check button in the Vereofy view. A window with the resulting explanation (see Figure 14) will be opened. This

FP7-215175 COMPAS D3.2v1.0


window shows the result of model checking, i.e., whether the given formula passed or was violated, and in the later case, shows a counterexample. This counterexample represents an execution path, i.e., a set of transitions in a CA with data assignment that violates the property. It can be stored in a .dot file and visualized using an appropriate external tool such as Graphviz http://www.graphviz.org/. The model checker also generates a connector interface and a script that can be used as input format for further verification steps. In principle, one can specify Reo process models in this format without using the Reo editor and run the Vereofy from the command line. This can be convenient for large processes when visual analysis of process models is no longer possible.

Figure 14 Vereofy model checker: verification results

3.3.3. mCRL2 tool set The Vereofy model checker is a relatively new tool which is still under development. For being able to deal with a larger number of compliance requirements, we integrated in the ECT the mCRL2 toolset which supports data- and time-aware model checking.

mCRL2 (micro Common Representation Language 2) http://www.mcrl2.org/ is a specification language based on the Algebra of Communicating Processes (ACP) extended with data and time. A fundamental concept in mCRL2 is the process. Processes perform actions and can be composed using algebraic operators. A system usually consists of several processes (or components) running in parallel. A process can carry data as its parameters. The state of a process is a specific combination of parameter values. This state may influence the possible actions that the process can perform. In turn, the execution of an action may result in a state change. Every process has a corresponding state space or Labeled Transition System (LTS) which contains all states that the process can reach, along with the possible transitions between those states.

A central notion in mCRL2 is the linear process. This is a process from which all parallelism has been removed to produce a series of condition - action - effect rules. Complex concurrent systems, including those with infinite state space, can be translated to a single linear process. Therefore, most tools in the mCRL2 toolset operate on linear processes rather than on state spaces. Model checking is provided using Parameterized Boolean Equation Systems (PBES). Given a linear process and a formula that expresses some desired behavior of the process, a PBES can be generated. The solution to this PBES indicates whether the formula holds on the process or not.

We integrate the mCRL2 model checking facilities in the ECT by mapping Reo connectors into mCRL2 processes. The mapping is straightforward and compositional: each Reo channel

http://www.graphviz.org/�

http://www.mcrl2.org/�

FP7-215175 COMPAS D3.2v1.0


and each Reo node corresponds to a simple process. Channels are connected through nodes by synchronizing process actions corresponding to channel/node ends.

Listing 1 shows an encoding of the basic Reo channels and nodes in mCRL2, as well as an example of their composition to form a Reo connector. Such a mCRL2 script can be obtained automatically for any Reo circuit by selecting mCRL2 tab in the channel/connector property view shown in Figure 15. act

% Channel ends

A1, B1, A2, B2, A3, B3, A4, B4, A5, B5;

% Node ends

X1, Y1, Z1, X2, Y2, Z2, X3, Y3, Z3;

proc

%%%Channels%%%

% FIFO1 with a sink end A1 and a source end B1

FIFO1(b:Bool) = !b -> A1.FIFO1(!b) + b -> B1.FIFO1(!b);

% Synchronous channel with a sink end A2 and a source end B2

Sync = A2|B2.Sync;

% Synchronous drain channel with a sink end A3 and a source end B3

SyncDrain = A3|B3.SyncDrain;

% Asynchronous drain channel with a sink end A4 and a source end B4

AsyncDrain = A4.AsyncDrain + B4.AsyncDrain;

% Synchronous lossy channel with a sink end A5 and a source end B5

LossySync = A5|B5.LossySync + A5.LossySync;

%%%Nodes%%%

% Replicate node with a source end X1 and sink ends Y1 and Z1

Replicate = X1|Y1|Z1.Replicate;

% XOR node with a source end X2 and sink ends Y2 and Z2

XOR = X2|Y2.X1 + X2|Z2.XOR;

% Merge node with source ends X3 and Y3 and a sink end Z3

Merge = X3|Z3.Merge + Y3|Z3.Merge;

%%%Composition%%%

% a circuit consisting of a FIFO1, Replicate node, Sync and SyncDrain

P1 = block({B1, A2, A3, X1, Y1, Z1},

comm({B1|X1 -> tau, A2|Y1 -> tau, A3|Z1 -> tau},

FIFO1(false) || Replicate || Sync || SyncDrain ));

init

P1;

Listing 1 mCRL2 model for basic Reo channels and nodes

FP7-215175 COMPAS D3.2v1.0


Figure 15 mCRL2 model generation

An LTS corresponding to the mCRL2 specification can be opened using a button Open in ltsgraph. For example, Figure 16 shows an LTS generated for the script in Listing 1. Intuitively, this transition system corresponds to a CA model without data constraints. Data constraints can be added through parameterized actions. There is ongoing work on defining the formal relation between this model and CA.

Figure 16 LTS generated for a sample mCRL2 script

mCRL2 is capable of verifying properties specified in μ-calculus, which subsumes LTS, CTL and CTL*. One of the useful properties which currently cannot be checked by Vereofy is the livelock detection specified as follows: [true*]mu X.[tau]X. More details about the use of mCRL2 model checker can be found in [GMR+07].

3.3.4. PRISM model checker PRISM, a probabilistic symbolic model checker, is a tool for formal modelling and analysis of systems that exhibit random or probabilistic behavior. It supports three types of probabilistic models: Discrete-Time Markov Chains (DTMCs), Continuous-Time Markov Chains (CTMCs) and Markov Decision Processes (MDPs), as well as extensions of these models with costs and rewards.

FP7-215175 COMPAS D3.2v1.0


PRISM accepts models specified using a simple state-based language called the PRISM language. It provides support for automated analysis of a wide range of quantitative properties of these models, e.g. "what is the probability of a failure causing the system to shut down within a certain period of time?", "what is the worst-case probability of the business process to terminate in error?" The property specification language adopted in PRISM incorporates LTL, PCTL (Probabilistic Computation Tree Logic), CSL (Continuous Stochastic Logic) [BHH+00], PCTL* (a superset of probabilistic CTL and LTL), as well as their extensions for quantitative specifications and costs/rewards. More information about the use of PRISM can be found on the PRISM official web site http://www.prismmodelchecker.org.

Arbab et al. [ACM+09] proposed stochastic Reo and Quantitative Intentional Automata (QIA) to account for the influence of the environment on the performance of a Reo model. Formally, QIA can be defined as follows:

Definition (Quantitative Intentional Automaton (QIA). QIA is a tuple A = (S, S0, N, E) such that S denotes a finite subset of L ⊆ 2N, where

• L is a set of states in the corresponding CA,

• 2N represent a set of nodes that describe the pending status in the current state,

• the transition relation E is a finite subset of ∪M, N ∈N S×{M}×{N}×DC(N) ×2DI×S, where DI ⊆ 2N×2N×R+.

The Reo and CA editors in the ECT have been extended to support stochastic Reo and QIA, as well as to automatically derive QIA semantics of stochastic Reo circuits. Furthermore, ECT supports the automated translation of QIA to CTMC for performance analysis when the performance properties are distributed exponentially in QIA. Afterwards, input files for PRISM can be generated allowing designers to verify quantitative properties of Reo process models. Additionally, Reo circuits can be converted to mCRL2 according to their QIA semantics and verified using the mCRL2 model checking suit.

4. Using ECT for process analysis: control flow requirements

In this section, we illustrate the application of the ECT toolset to control flow analysis. This type of analysis is required to ensure process soundness which can be understood as structural correctness of process models, e.g., their proper termination, absence of unreachable states or dead tasks, as well as to address control flow compliance concerns [D2.1] imposed by legislative documents. Some examples of such compliance concerns can be found in Section 4.2 of COMPAS Deliverables D1.1 [D1.1].

Due to the fact that control flow compliance concerns essentially regulate the structure of the process flow, the aforementioned two issues can be addressed in the same manner. The basic approach taken by the presented verification tools is to disambiguate a given high-level process model by converting it to Reo, generate a state-based representation of this model (if necessary, enriched with data and time constraints) and use one of the available model checking tools to verify whether certain system properties hold for this model.

There exist a number of studies on how system properties can be expressed using logical formalisms. COMPAS deliverable D2.2 [19] examines the suitability of Deontic logic, LTL, and several XML-based approaches for formal specification of regulatory compliance

http://www.prismmodelchecker.org/manual/PropertySpecification/Introduction�

FP7-215175 COMPAS D3.2v1.0


requirements. It demonstrates that basic compliance requirements can be successfully expressed in all these languages, but advocates the use of LTL as the most comprehensible notation by end users. The ECT environment supports a wide range of property specification formats, including LTL and CTL-like logics for the Vereofy model checker, μ-calculus for mCRL2 model checker and LTL, CSL, PCTL and PCTL* for the PRISM model checker. We believe that the combination of these temporal logics represents a sufficient means for expressing control flow compliance requirements.

Typical examples of process structure analysis include detection of deadlocks, livelocks and problems with synchronization:

• Deadlock is a situation when a service or a process stays idle waiting for resources permanently blocked by another party or messages that will never arrive.

• Livelock (starvation of progress) is a situation when a process or a service is not blocked but doesn't make any progress nevertheless. A livelock may appear, for example, in a process with a loop structure without an appropriate end condition.

• Problems with synchronization conflicts can be introduced by joining fork concurrent paths with a merge structure which in some workflow specification languages (e.g., BPMN) results into unintentional multiple activation of states that follow the merge node.

In the rest of this section, we demonstrate by example the application of the ECT framework for the verification of a BPMN process model.

Figure 17 shows a BPMN diagram for a sample loan request scenario inspired by the THALES case study. The preliminary version of the BPMN diagram for the whole loan request process developed by THALES in collaboration with other COMPAS partners is given in Appendix A. Note that in our example, we use a part of this diagram representing the behavior of a credit broker, modified to contain parallel flows, with the goal to illustrate the ability of our tools to verify concurrent processes.

In this scenario, a credit broker receives a loan request from a customer and evaluates her banking profile. If some necessary condition is not satisfied (e.g., the customer’s salary is not sufficient), the credit broker sends a reject message to the customer. Otherwise, he creates a customer loan profile and prepares all legal documents. However, if the requested loan amount is higher than 10 millions, according to the bank policy, the broker is obliged to ask his supervisor for an authorization. After that, he sends the prepared official form to the customer.

Figure 17 BPMN diagram for the loan request process.

A Reo connector for this process fragment is shown in Figure 18. According to the BPMN to Reo mapping rules specified in deliverable D3.1, we represent BPMN activities as simple

FP7-215175 COMPAS D3.2v1.0


FIFO1 channels meaning that data flow in the source end of each channel corresponds to the start of the activity, data flow in the sink end of the channel corresponds to the end of the activity, while the data token residing in the channel buffer implies that the activity is being executed. Special components, Writer and Reader, are used to introduce and consume data flow at the beginning and the end of the process. Nodes obtained by joining both source and sink ends of Reo channels are called mixed and considered to be internal for the connector. In contrast, nodes where only source or only sink channel ends are merged are considered to be at the boundary and can be attached to writers or readers, respectively. The Reo editor in the ECT environment automatically highlights the internal nodes with grey color. Two parallel flows are initiated by joining a sink end of a Reo channel with the start ends of two other channels (see, e.g., node conditionsOk), and synchronized using a synchronous drain (see, e.g., SYNC_DRAIN(checkAmount, less10M) which requires tokens on both sides to fire). Data-driven conditional choice can be realized using Reo filter channels. However, in this model for simplicity we abstract from data issues and use non-deterministic exclusive router connectors instead. For example, such a connector directs a token from the node checkConditions either to the node conditionsOk or to the node conditionsNotOk, thus, introducing two alternative execution paths.

Figure 18 Reo circuit for the loan request process.

A CA model for one instance of the loan request process is shown in Figure 19. We show only states that are reachable from the initial state after a single request. Such CA are automatically obtained from Reo process models. Intuitively, each state of a CA without hiding corresponds to a unique combination of empty/full buffers of the corresponding Reo circuit. We reflect this dependency in state names by writing 1 for a full FIFO1 channel and 0 for an empty FIFO1 channel assuming their top-down left-to-right order in Figure 18. CA transition labels correspond to the names of Reo nodes where data flow is simultaneously observed during the transition. After hiding internal ports, CA control states represent process states observable by an external user (see Figure 20). In this example, three logical states have been identified: the initial state s1, state s2 corresponding to the started process execution and state s3 that implies the presence of the deadlock in the process model.

FP7-215175 COMPAS D3.2v1.0


Figure 19 CA for the loan request process: Internal view

Figure 20 CA for the loan request process with a deadlock: External view

In our case study, the following LTL formula

G(prepareFormOut → F sendFormIn)

states that whenever the data flow is observed in prepareFormOut port meaning that the activity prepare official form is finished, a data flow must be eventually observed in sendFormIn port corresponding to the execution of the send official form activity. The ASL formula

AG[EX[true]]

which literally means that for all paths, it is globally true that there exists a next state can be used for deadlock detection. Both these formulae fail for the Reo process model presented in Figures 17-20. Indeed, in this scenario, if the supervisor denies authorizing the large credit, the official documents will remain prepared, but will never be sent.

Another conceptual problem with this process model is that in the case of a large credit, the customer may never get a notification about her request being denied. This flaw may be automatically detected using the LTL property

G(request → F (reject ∪ sendFormOut),

which requires any loan request to be followed either by a reject message or by an official form sent to the customer.

A proper BPMN model for our sample scenario is shown in Figure 21. Figures 22 and 23 represent its formal semantics using Reo and CA.

FP7-215175 COMPAS D3.2v1.0


Figure 21 Refined BPMN for the loan request scenario

Figure 22 Reo process model for the refined loan request scenario

Figure 23 CA for the refined loan request process: External view

Figure 23 shows an external behavior of a credit broker service corresponding to the loan request process. This automaton is a typical example of CA for a stateless web service operation which can be obtained from any standard WSDL specification.

5. Compliance-aware process modeling In this section, we provide several examples of compliance-aware process design with the ECT tools. All examples have been extracted from the THALES case study. However, for the sake of clarity, we slightly modified real sub-processes to keep them small and abstract from irrelevant details. For instance, the THALES case study implies Segregation of Duties (SoD) constraints on sub-processes, while for didactic purposes in this document we model SoD for processes with atomic tasks only (see Appendix A).

FP7-215175 COMPAS D3.2v1.0


5.1. Thales case study For the THALES case study, several compliance requirements have been identified. We are interested in those that can be imposed at the design time. In particular,

In order to comply with ISO 27002 and SOX, pre- and postprocessing clerks involved in the loan request process must be separated. The scenario also requires supervisor involvement for unusual or large credits, and final approval of each credit by a manager.

According to Basel II, ISO 27002, and European Directive 95/46/EC, the process must comply with security and privacy requirements, which in particular presumes encryption/decryption of data to be transmitted and strong authentication of clerks accessing data storages.

According to the approach adopted in COMPAS, these and other compliance concerns can be implemented by compositing business processes from compliant services and process fragments. For the THALES case study, several such fragments have been created in WP4. In particular, a check fragment requires an additional check to be performed if a special condition holds (e.g., a loan request amount is larger than 10M), while a security fragment requires strong authentication of users before granting them access to data storages. The goal of the WP3 tools in this scenario is to verify, e.g., that the check is actually performed whenever it is needed or that unauthorized users can never access the secure information. These and other requirements can be formalized as reachability problems on Reo/CA models obtained from BPMN/UML diagrams or BPEL process specifications.

For example, Figure 24 shows a business process fragment modeled using an UML activity diagram. In this process fragment, an activation condition is used to indicate whether a check is required. If so, the perform check activity (service) is executed, and depending on its output, accept or reject exit points are taken.

Annotation:

• Single entry

• Multiple exits

o Accept – check is OK

o Reject – check is not OK

• Parameters

o Activation condition

o Service for checking

o Input data for check (e.g., credit amount)

Figure 24 Check fragment: UML activity diagram

Figure 25 shows Reo model of the check fragment. When plugged-in in a larger process, e.g., loan request process, the compliance rule formalized in LTL or CTL-like logics will require

FP7-215175 COMPAS D3.2v1.0


the reachability of the state corresponding to the perform check task in any execution of the process.

Figure 25 Check fragment: Reo model

5.2. SoD in sequential processes In Deliverable D3.1 we proposed a circuit that automatically assigns two users to two tasks ensuring SoD constraints. In this section, we go further and consider SoD constraints in relation to the business process structure. In particular, we build circuits that enforce SoD in sequential and parallel processes.

Figure 26 Modeling a sequential process with SoD constraints in Reo

Figure 26 shows a Reo process model that consists of sequential invocations of two activities, T1 (process request) and T2 (authorize loan), simulated using FIFO1 channels in separate Reo connectors. In this model, the activity T1 can be executed by three authorized clerks, Alice, Bob and Clara, while the activity T2 can be executed by Alice, Bob and Frank. These access control rights are modeled by means of filter channels FILTER(T1in’, T1start) and FILTER(T2in’, T2start) with conditions

#T1in’.clerkName ∈ D1 = {Alice, Bob, Clara}

and

#T2in’.clerkName ∈ D2 = {Alice, Bob, Frank},

respectively. Here, we use #X to refer to data observed at port X. Parts of the Coordinator circuit emphasized with dashed rectangles impose the dual control constraint in this scenario.

FP7-215175 COMPAS D3.2v1.0


The two Writer components connected to ports U1 and U2 correspond to two roles, credit broker and postprocessing clerk, who login to the system and process the credit request and authorize the loan, respectively. The synchronous drain channel with filter FILTER_SYNC DRAIN(U2, A5) uses a condition #U2 ≠ #A5. to ensure that the postprocessing clerk differs from the credit broker who processed the credit request in this process instance. This circuit uses two special join nodes A2 and A6 as graphical shorthand for components that construct tuples out of the data items from their incoming channels. Transformer channels TRANSFORMER(A2, T1in) and TRANSFORMER(A6, T2in) are employed to transform data objects from the coordinator circuit to the format used in circuits representing operations T1 and T2: The compliance of this process model to the dual control principle can be checked using the ASL formula

A[#T1start.clerkName ≠ #T2start.clerkName]true;

which requires clerk names executing the involved operations to be different.

5.3. SoD in parallel processes There may be cases where SoD constraints are needed in a process with parallel activities. For example, in the loan request scenario, an authorization by two different clerks may be needed for extra large or unusual credits. Figure 27 shows a Reo circuit that imposes an SoD constraint in the parallel process with two activities. In this process, tasks T1 and T2 can be performed simultaneously or in any order by any of the authorized clerks. The only requirement is to ensure that two different clerks are involved in the execution of each process instance. This constraint is imposed by the part of the circuit in the red rectangle. In this circuit, two execution tokens (data items with request data details) wait in the buffers FIFO1(start, A1) and FIFO1(start, B1) until two clerks login to the system and perform their respective tasks. When the first user enters, the circuit keeps his/her name in the buffer FIFO1(C1, C2). When the second user enters, filter channels FILTER_SYNCDRAIN(C2, A4) and FILTER_SYNCDRAIN(C2, B4) with conditions C2≠A4 and C2≠B4 ensure that the same user cannot enter the system to execute another task. Analogously to the sequential processes, transformer channels are used to modify data items before invoking services T1 and T2, and filter channels ensure access control to these tasks.

Although the circuit may initially seem rather intricate, it simply reflects the idea that for each process instance we have to store the name (id) of a cleark executing one of the tasks and ensure that the same person will not be able to execute the second task.

FP7-215175 COMPAS D3.2v1.0


Figure 27 Modeling a parallel process with segregation of duties in Reo

5.4. Privacy requirements In the THALES case study, Alice permits the credit broker to access her banking profile. However, she may not want other parties to use her private data. In general, suppose an organization providing a composite service needs to ensure compliance to a privacy policy stating that user personal data can be transferred to a third party only if the user explicitly authorized such a transfer. In the above loan request process, the credit broker may request for a loan on behalf of a bank client who entrusts his/her personal data (name, passport number, organization, address, etc.) to the bank, but does not want them to be shared with other partners/services (e.g., risk assessment organization). On the other hand, some of these data can be vital for involved services, and to complete the process the bank needs to get the client's permission to transfer particular data to particular services. Such permissions can be formalized by means of privacy rules and stored in the following format:

ri = (ruleID, clientID, dataItem, recipientID, action, permission);

where ruleID is a rule identifier, clientID is a client identifier, dataItem is a data item that requires authorization, recipientID is a partner (service) to whom the data item will be transferred, action is an action on data item performed by the recipient (e.g., use, retain, share, etc.) permission is a boolean value that permits or prohibits the transfer of the specified data item to the specified partner for the particular purpose defined by the action. For example, Alice can authorize the transfer of her passport number to the T1 service if it is needed for processing her request (use), but prohibit retaining this data after her request has been processed.

FP7-215175 COMPAS D3.2v1.0


Although the majority of the publicly available service policies are published in plain natural languages, they usually provide sufficient information about the intended use of personal data. XML-based specifications such as WP-Policy and XACML (eXtensible Access Control Markup Language) allow designers to express privacy policies in a more structured manner. Recent approaches to privacy management suggest the transfer from static policies to customizable solutions which allow parties to negotiate the use of personalized data. This assumes a formalization of possible actions performed by each partner on these data. In our case, providers of composite services may store privacy policies of individual services in the form

pj = (ruleID, serviceID, dataItem, action, purpose, necessity, disclosure);

where ruleID is a rule identifier, serviceID is a service used in the composition, dataItem is a private information concern, action is an action on data item performed by the service, purpose explains the intended use of this data item, necessity indicates whether this data item is vital for a service or optional, while disclosure specifies whether it can be shared with other partners. The selection of permitted actions on protected data items regarding the invocation of a particular service by a particular client can be modeled using Reo transformer channels. Assuming that R : ri, 1 ≤ i ≤n is a table of client permissions, an SQL request

SELECT action FROM R

WHERE clientID = %currentClientName

AND dataItem = `passport number' AND recipientID = `T1' AND permission = `true'

can be realized by a channel TRANSFORMER(A2, T1in) to select a set P of actions permitted for the service T1 over a client's passport number. Here the variable %currentClientName refers to a client name from the current loan request (Alice).

Similarly, assuming that P: pj, 1 ≤ j ≤m is a table of rules formalizing service privacy policies, a set R of requested actions can be obtained using the following SQL request

SELECT action FROM P

WHERE serviceID = `T1' AND dataItem = `passport number' AND necessity = `vital'.

A constraint R ⊆ P for the FILTER(T1in, T1start) channel will ensure that the data transition through this channel is possible only if the set of requested actions is included in the set of permitted actions. Checking an appropriate formula over the domain

Act = enum {`use', `retain', `share',...}

we can automatically establish whether privacy policies match (state T1start is reachable) or mismatch (state T1start is unreachable). Potentially, more complex matching functions, e.g., ones that take into account action implication (e.g., `retain' implies `use', etc.) can be implemented.

5.5. Time-aware business processes In the above model of the loan request process the system waits until a credit broker and a postprocessing clerk perform their activities. Using timer channels, we can model a system that notifies the trader about pending requests and the auditor about the need to authorize the credit request processes if they do not execute their activities within a set time period. Figure 28 shows an example of a Reo circuit that uses a t-timer with off- and reset-option TIMER(B2,B3) to achieve this goal. A Timed Constraint Automaton (TCA) (discussed in the Deliverable D3.1 [D3.1]) for this channel is shown in Figure 29. A t-timer channel accepts

FP7-215175 COMPAS D3.2v1.0


any input data and returns on its sink end a timeout signal after a delay of t time units. In our case, we use a t-timer to measure how long the credit request waits for authorization. The off-option allows the timer to be stopped before the expiration of its delay when a special “off” value is consumed through its source end. This option is used to switch off the timer when the authorization message is received from the auditor. The reset-option allows the timer to be reset to 0 after it has been activated, when a special “reset” value is consumed through its source end. We reset the timer after sending a notification message to the auditor.

Figure 28 Modeling time-aware business processes: Reo model

Figure 29 Modeling time-aware business processes: TCA model

5.6. Encryption/Decryption Brandt et al. [BHE09] applied Reo for exogenous coordination of components in a Credit Suisse scenario. In this work, Reo channels are labeled as private and public. For each public channel encryption/decryption operations are required on its ends. The compliance to the Credit Suisse security policy can be ensured by checking that it is always the case that an encryption operation is invoked before data flow is observed on a source end of a public channel. This example is analogous to a check fragment introduced for the THALES case study in COMPAS.

6. Evaluation of Tool Prototypes In this section, we provide some preliminary evaluation of the presented tool prototypes with respect to the metrics identified in DA.1 for measuring progress in WP3.

Level of automation is defined as the amount of automated vs. manual model transformations required to enable formally verified business process development.

In the presented framework, process models are converted automatically to Reo, and only in the case of ambiguous models some manual interference may be needed. After that, all

FP7-215175 COMPAS D3.2v1.0


technical operations related to the process verification, e.g., mapping to CA or mCRL2 scripts, are fully automated.

However, compliance specifications provided by WP2 in the form of LTL rules are not in a machine understandable form and must be related to Reo process models (e.g., use the same element names) and rewritten in a format acceptable by the ECT model checking tools. Given the specification of compliance language constructs and operators presented in D2.2, this step cannot be fully automated at present, but we may think about some tool for simplifying the translation. In general, the formalization of compliance requirements is partially automated by the WP2 compliance language specification framework which aims at automatic mapping between the rules specified in the form of some (graphical) patterns to LTL formulas. Therefore, we would evaluate the whole level of automation as rather high.

Level of coverage is defined as a fraction of compliance requirements against all compliance requirements relevant to each case study verified automatically using behavioral models and model checking tools developed in WP3.

At the moment, the development of business process models for COMPAS case studies and the formalization of relevant compliance requirements is still work in progress. Therefore, we cannot precisely evaluate this metric. Conformance to the design-time requirements identified for the THALES case study so far (SoD, security and privacy constraints) can be formally verified in our framework.

Model expressiveness is a fraction of business process aspects (control flow, data flow, time properties, performance, resources, etc.) and compliance requirements that can be expressed using behavioral models developed in WP3.

Being more expressive than Petri-nets, Reo allows us to specify rather complex behavioral protocols. As has been shown in this deliverable, control flow and data flow analysis with finite data domains are supported by the ECT framework. Model checking of process models with infinite data domains can be supported by the mCRL2, but it still requires some investigation. Timed, resource-aware and probabilistic behavior of Reo has been addressed in research papers, but not yet supported by the tools (although, some initial work in this direction has been done, in particular, processes with discrete time can be verified by the mCRL2 model checker, while Reo circuits with stochastic delays can be analyzed by the PRISM model checker). Property specification formats cover linear and branching time model checking with data and time constraints, which at the moment is more expressive that required by the WP2 compliance request language.

Extensibility. A binary metric that reflects the ability to extend models and tools developed in WP3 with new functionalities.

Reo/CA based models have been designed with the extensibility in mind. Model expressivity for process behavior specification can be extended by introducing new Reo channels, while new categories of compliance requirements can be dealt with by means of new data constraints. For example, to enable process compliance to locative constraints, components and sub-processes must be annotated with deployment information. However, some behavioral aspects may require an extension of existing semantic models for Reo as this was the case for the timed and probabilistic behavior. The ECT allows researchers to implement their extensions of CA, and there is an ongoing work on defining a user interface for specifying new channels.

FP7-215175 COMPAS D3.2v1.0


Interoperability. A binary metric that reflects the ability to integrate the models and tools developed in WP3 into various software (re-)engineering scenarios and work with other business process and service composition development tools.

As we demonstrated in this deliverable, external business process and service composition specification tools as well as external model checkers can be related to Reo/CA via model transformation and integrated with the ECT. Therefore, we evaluate the WP3 tools as interoperable.

Usability is a compound metric that reflects suitability of the tools developed in WP3 to the needs of industrial partners.

Usability will be evaluated with the help of the industrial partners after the implementation of their case studies.

Scalability in this context can be understood as an ability of WP3 verification tools to handle a larger number of inputs.

In the environments with many concurrent processes, a state explosion problem is the main issue that degrades the usability of the model checking tools. There are several measures we took to alleviate this problem. In particular, Reo avoids the introduction of unnecessary states in process execution by introducing a more elaborate mechanism for synchrony propagation than Petri nets. Furthermore, symbolic techniques used by the Vereofy and mCRL2 model checkers make them quite efficient. For example, mCRL2 toolset was successfully applied to several industrial case studies with millions of states and transitions. However, this tool cannot always provide counterexamples violating a certain property.

Still, the current implementation of Reo animation engine does not allow for the analysis of large process models. This limitation is due to the poor scalability of the coloring semantics for Reo, especially when 3-colours needed to model context-sensitivity are used. In the next versions of the ECT, we plan to optimize process animation by using automata-based semantics. Due to the compositional nature of CA, the generation of CA models is very efficient for small and middle size projects (with the number of atomic process activities between 0 and 50).

7. Related work In this section, we compare the proposed framework with other visual tools for verifiable process design.

A detailed survey of all existing tools for graphical modeling of workflows and service compositions is out of the scope of this work. An overview of some existing business process design tools can be found in [SYS+08]. In particular, this work compares a set of academic and commercial products for service-based process modeling, namely, Bind Studio, BPEL Orchestration Server, ebDesigner, eFlow, SWORD, DAML-S, WCPT, SODA, and WebDG. Most of these tools do not provide means for formal process verification, while others (SWORD and DAML-S) rely on Petri-net based models [Aal98].

The ECT tools provide a graphical environment for service specification by integrating BPMN, BPEL and UML-based tools. Other process modeling formats such as Event-driven Process Chains (EPC) can be supported in a similar way. However, the absence of formal semantics in many business process modelling standards poses the need of their transformations into models with a more formal semantical basis such as Petri nets, process

FP7-215175 COMPAS D3.2v1.0


algebras or finite-state machines. We proposed a novel framework which relies on the Reo coordination language and CA to fulfill this task.

Petri-nets are a powerful model for concurrent process specification (applied also to verify service compositions [NM02]) supported by multiple industrial tools. However, to express certain behavioral aspects, e.g., process cancellation and/or compensation, Petri-nets are usually extended with additional elements such as e.g., inhibitor and reset arcs, which as has been pointed out by Raedts et al. [RPU+07], significantly reduces the number of software tools able to analyze such models. The aforementioned work translates BPMN diagrams to such extended Petri-nets and uses mCRL2 toolset for their verification. Our plug-in for generating mCRL2 scripts has been mainly inspired by this paper. However, we do not limit our approach to structural verification of workflow models, but target at time- and data-aware analysis, while Raedts et al.’s translation represents only the number of data tokens in Petri-nets, but not their content.

Foster et al. [FUM+03] deals with the structural verification of processes modeled using UML message sequence charts. Eshuis and Wieringa [EW02] describe verification of processes modeled as UML activity diagrams with events, data, real-time and loops using SPIN and NuSMV model checkers. This work extends NuSMV to deal with a strong fairness constraint introduced to reason about loop termination. Our experiments show that mCRL2 toolset deals correctly with Reo process models with eventually terminating loops (no livelocks are detected for such loops).

Web Service Analysis Tool (WSAT) http://www.cs.ucsb.edu/~su/WSAT/ is a web service composition verification tool which formalizes BPML (a business process modelling language that has been deprecated) and BPEL/WSDL models using Guarded Automata (GA), and exploits SPIN and NuSMV model checkers to analyse these models. Kazhamiakin and Pistore [KP04] discuss verification of stateful service compositions under various communication models (synchronous vs. asynchronous). Service behavior represented in BPEL is formalized by means of LTS and analyzed using NuSMV. This work illustrates the importance of proper service coordination (e.g., for correct process cancellation), which can be easily realized using synchronous Reo channels. Some examples of complex service coordination scenarios that correctly deal with process cancelation can be found in [KA09].

While structural verification of process models is well examined (although, many of the available tools encounter scalability problems or fail to deal with the state explosion problem), there are not so many tools that support advanced process analysis required to guarantee process model compliance to various organizational controls.

Designers can easily decompose Reo process models into sub-processes, verify compliance properties for each independent (with respect to a given property) sub-process, and compose them again. This is useful when tools are not powerful enough to deal with a whole process at once. Hiding is another technique to abstract from unnecessary details that helps to deal with scalability problems. The ability to define new channels in Reo allows designers to address certain compliance issues locally, without changing the whole model. For example, we can pass from time-agnostic process models to time-aware models by placing timer channels when necessary. This defines another advantage of using Reo for modelling compliance-aware processes.

Schaad and Sohr [SS06] examine SoD in a banking scenario which is somewhat similar to the THALES case study [D6.1] we deal with in COMPAS. This work distinguishes two types of SoD policies, namely, Static vs. Dynamic SoD. The latter category includes Object-based SoD when a single person cannot act on the same object using two exclusive roles,

http://www.cs.ucsb.edu/~su/WSAT/�

FP7-215175 COMPAS D3.2v1.0


Operational SoD when a single person with sufficient authorizations cannot cover the whole workflow, and History-based SoD when a principal cannot act on the same object throughout the whole workflow even if his/her set of authorizations covers it. Adherence of a process model to SoD policies is verified by the NuSMV model checker. Process behavior is formalized by means of the SMV (Symbolic Model Verifier) specification language while SoD requirements are expressed as LTL formulae. While this approach enables automated verification of SoD constraints in an existing process, it does not provide means for modeling processes that are compliant to SoD by design. Moreover, the SoD information derived from BPEL processes and business object repositories is manually encoded in the NuSMV’s input language. This encoding is not intuitive and makes it difficult to apply the approach in practice.

Dury et al. [DBP+07] combine Role-Based Access Control (RBAC) policies with business workflow modelling and apply SPIN and NuSMV model checkers to detect their possible violation. Process behavior is formalized using FSM extended with transition guards that represent optional variables and parameters. In this sense, our extended CA model is more complete as it allows us to incorporate the same information as in FSM, along with other possible constraints (e.g., synchronization, time, QoS) which are not considered in this work. Another disadvantage of the aforementioned approach is that it does not provide the integrated environment for generating and annotating FSM models, assuming that they can be generated by some existing tools.

Park and Kwon [PK05] verify whether security policies hold for processes specified as UML sequence and class diagrams. Process behavior and policies are formalized using the Alloy specification language, a structural modeling language based on first-order relational logic capable of expressing complex behavioral and data constraints. UML2Alloy toolset http://www.cs.bham.ac.uk/~bxb/UML2Alloy/index.php can be used to verify the correctness of UML/OCL models. Hassan and Logrippo [HL08] use the Alloy analyzer http://alloy.mit.edu/community/ tool to verify legal compliance by checking the consistency of legal and enterprise requirements. Wolter and Schaad [WS07] intend to use Alloy for verifying compliance of BPMN processes to authorization constraints. This suggests that Alloy is a rather popular software analysis tool when composite data structures such as objects, trees and lists are involved. Khosravi et al. [KSA+08] establishes a mapping of Reo to Alloy. This work is still incomplete as it currently ignores the actual values of data passed through the channels and points out several performance issues. We are going to extend, optimize and integrate the Reo to Alloy mapping library (called Relloy) with the ECT, thus enabling kind of compliance analysis discussed in the aforementioned works.

The presented ECT incorporates the most advanced techniques for process verification, including detection of structural errors and performance. We have integrated three state-of-the-art model checkers. Moreover, our toolset supports more a expressive property specification format than any of the aforementioned verification frameworks. Nevertheless, as the presented analysis of related work shows, NuSMV and SPIN appear to be the most popular verification tools in the area of SOA. Their comparison [Cho07] suggests that SPIN can be more flexible than NuSMV in handling large scale systems, but can also be more difficult to use by non-experts. In our future work, we may consider generating input files for SPIN and NuSMV from Reo process models similarly to the mCRL2, PRISM and Alloy scripts. However, the process coordination in SPIN is implemented via shared variables, which conceptually differs from the channel-based coordination in Reo.

http://www.cs.bham.ac.uk/~bxb/UML2Alloy/index.php�

http://alloy.mit.edu/community/�

FP7-215175 COMPAS D3.2v1.0


8. Conclusions and Future Work In this deliverable, we described a prototype framework for visual specification of service behavioral interfaces. The presented framework includes tools for converting process specifications in graphical modelling notations such as BPMN and UML SDs, and XML-based process description language BPEL to Reo. We provided the necessary information about Reo-based tools, namely, Reo and Constraint Automata editors, reconfiguration and animation plug-ins, and several model checking tools. Moreover, we exemplified their application to the development of business processes that have to comply with certain functional and non-functional requirements by design. The presented toolset relies on the formal behavioral model introduced in the deliverable D3.1.

The development of ECT has been started to provide tool support for the Reo coordination language. Its application in the COMPAS project poses interesting questions and introduces the need for multiple extensions and integration with well-established products in the area of business process modelling and web service composition on the one hand, and with formal verification techniques and tools able to deal with requirements coming from compliance specifications, on the other hand. Therefore, much effort in WP3 so far has been put on the development of the converting tools from high-level process specification formats to Reo and adaptation of the existing model checking tools such as mCRL2 to verify Reo circuits. In our future work, we plan to investigate several other research lines:

• ECT provides a rich front-end for the verifiable design of business process models. These models have several semantic models that may reflect different aspects of the process flow (e.g., context sensitivity, probabilistic behavior). By integrating new model checking tools able to deal with these models, we may extend the capabilities of our framework. In particular, we consider a more extensive use of the probabilistic model checking tools such as the Markov Reward Model Checker (MRMC) http://www.mrmc-tool.org/trac/ to address compliance issues such as process adherence to Service Level Agreements (SLA) and guaranteed provisioning of end-to-end QoS.

• Other semantic models can be defined for Reo. For example, recently we started to work on Continuous Reo with unreliable channels specifying channel behavior with the help of hybrid automata, a class of automata able to model systems exhibiting both continuous and discrete behavior. Such systems can be useful in the context of the TARC-PL case study to model processes with audio/video data transmission, synchronization and transformation.

• Additional efforts must be put into optimizing the presented tools, improve their usability and scalability. Moreover, several plug-ins such as one for extracting behavioral service specifications from Java code or reverse-engineering of BPEL/WSDL processes may be useful. Currently, we provide a BPEL2Reo conversion tool able to automatically obtain a formal model of some BPEL coordination code. However, for the analysis of the overall service composition, an integrated engine is needed which would bind Reo models obtained from BPEL with behavioral specifications of services/components extracted from WSDL or generated directly from Java code.

http://www.mrmc-tool.org/trac/�

FP7-215175 COMPAS D3.2v1.0


9. Reference documents

9.1. Internal documents [D7.1] “Public Web-Site”, http://www.compas-ict.eu.

[DA.1] “COMPAS Architecture, Architectural Walkthroughs, and Evaluation Met-rics”, 2009-01-31.

[DoW] “Description of Work” for COMPAS, 2008-02-01.

[D1.1] “Model-driven Integration Architecture for Compliance”, 2008-07-31.

[D2.1] “State-of-the-Art in the Field of Compliance Languages”, 2008-07-31.

[D2.2] “Initial specification of compliance language constructs and operators”, 2009-01-31.

[D2.3] “Design of compliance language run-time environment and architecture”, 2009-07-31.

[D3.1] “Specification of a Behavioral Model for Services”, 2009-01-31.

[D6.1] “Use case, metrics and case study”, 2008-07-31.

9.2. External documents [Aal98] W.M.P. van der Aalst: “The application of Petri Nets to workflow

management”, Journal of Circuits, Systems and Computers 8 (1) (1998) 21–66.

[ACM+09] Arbab, F., Chothia, T., van der Mei, R., Sun, M., Moon, Y., Verhoef, C.: “From coordination to stochastic models of QoS”. In: Proceedings of the International Conference on Coordination Models and Languages (COORDINATION). Volume 5521 of LNCS, Springer (2009) 268-287.

[BHE09] C. Brandt and F. Hermann and T. Engel, “Security and Consistency of IT and Business Models at Credit Suisse Realized by Graph Constraints, Transformation and Integration Using Algebraic Graph Theory”. In: Proceedings of the International Workshop on Enterprise, Business-Process and Information Systems Modeling (BPMDS'09), Vol. 29 of LNBIP, Springer, 2009, pp. 339-352.

[BHH+00] C. Baier, B. Haverkort, H. Hermanns, and J.-P. Katoen, “Model checking continuous-time Markov chains by transient analysis”. In: Annual Symposium on Computer Aided Verification (CAV), 2000.

[BKK+08] T. Blechmann, J. Klein, S. Kluppelholz, Vereofy manual, 2008, http://www.vereofy.de/download/vereofy_manual.pdf

[BSM+09] M. De Backer, M. Snoeck, G. Monsieur, W. Lemahieu, G. Dedene: “A scenario-based verification technique to assess the compatibilityof collaborative business processes”, Data & Knowledge Engineering 68 (2009) 531–551.

[Cho07] Choi, Y.: “From NuSMV to SPIN: Experiences with model checking flight guidance systems.” Formal Methods in System Design, 2007, 30(3): 199-216.

http://www.compas-ict.eu/�

http://www.springerlink.com/content/j37772h45n2p/?p=188050f3100641fcb2ead59b92e9bbcc&pi=0�

http://www.vereofy.de/download/vereofy_manual.pdf�

FP7-215175 COMPAS D3.2v1.0


[DBP+07] A. Dury, S. Boroday, A. Petrenko, V. Lotz, “ Formal Verification of Business Workflows and Role Based Access Control Systems”, In: International Conference on Emerging Security Information, Systems and Technologies, 2007, pp. 201-210.

[EW02] R. Eshuis, R. Wieringa: “Verification Support for Workflow Design with UML Activity Graphs”, In: Proc. f the Int. Conf. on Software Engineering (ICSE), 2002, pp.166- 176.

[FUM+03] H. Foster, S. Uchitel, J. Magee, and J. Kramer: “Model-based verification of web service compositions”. In: Proc. of the 18th IEEE Int. Conf. on Automated Software Engineering (ASE), 2003.

[GMR+07] J. F. Groote, A. Mathijssen, M. Reniers, Y. Usenko and M. van Weerdenburg, “The Formal Specification Language mCRL2”, In: Methods for Modelling Software Systems (MMOSS), 2007, http://moodle.risc.uni-linz.ac.at/file.php/31/ccs/06351.GrooteJanFriso.Paper.862.pdf

[Gra04] S. O’Grady: SOA Meets Compliance: Compliance Oriented Architecture, EMC Corporation, White paper, 2005.

[HL08] W. Hassan, L. Logrippo, "Requirements and compliance in legal systems: a logic approach", In: Proceedings of the International Workshop on Requirements Engineering and Law (RELAW), 2008, pp.40-44.

[KA09] Kokash, N., Arbab, F.: "Applying Reo to Service Coordination in Long-Running Business Transactions", Proceedings of the ACM Symposium on Applied Computing, 2009, pp. 318-319.

[KP05] R. Kazhamiakin, M. Pistore: “A parametric communication model for the verification of BPEL4WS compositions”. In: Proceedings of the international Workshop on Formal Methods (WS-FM), 2005.

[KSA+08] R. Khosravi, M. Sirjani, N. Asoudeh, S. Sahebi and H. Iravanchi, “Modeling and Analysis of Reo Connectors Using Alloy”, In: Proceedings of the International Conference on Coordination Models and Languages (COORDINATION), Vol. 5052 of LNCS, 2008, pp.169-183.

[MPT06] A. Marconi, M. Pistore and P. Traverso, “Specifying Data-Flow Requirements for the Automated Composition of Web Services” In: Proceedings of the Software Engineering and Formal Methods, 2006, pp. 147 - 156

[NM02] S. Narayanan, S. McIlraith: “Simulation, verification and automated composition of web services”, In: Proceedings of the International World Wide Web Conference (WWW2002), pages 77–88, 2002.

[PK05] S. Park, G. Kwon: “Verification of UML-Based Security Policy Model”, In: International Conference on Computational Science and Its Applications (ICCSA), 2005, Vol. 3482 of LNCS, Springer pp. 973-982.

[RPU+07] Raedts, I., Petkovic, M., Usenko, Y.S., van der Werf, J.M., Groote, J.F., Somers, L.: Transformation of BPMN models for behavior analysis. In: Proceedings of the International Workshop on Modelling, Simulation, Verification and Validation of Enterprise Information Systems (MSVVEIS), 2007, pp. 126-137.

http://www.springerlink.com/content/j37772h45n2p/?p=188050f3100641fcb2ead59b92e9bbcc&pi=0�

FP7-215175 COMPAS D3.2v1.0


[SO00] W. Sadiq and M.E. Orlowska: “Analyzing process models using graph reduction techniques”, Information Systems 25 (2) (2000), pp 117–134.

[SS06] A. Schaad, K. Sohr, “A Workflow Instance-based Model checking Approach to Analyzing Organizational Controls in a Loan Origination Process”, In: Proceedings of the International Multiconference on Computer Science and Information Technology, 2006, pp. 499 – 517.

[SYS+08] Shi-Ming Huang, Yuang-Te Chu, Shing-Han Li, David C. Yen: “Enhancing conflict detecting mechanism for Web Services composition: A business process flow model transformation approach”, Information and Software Technology, 2008, pp. 1069-1087.

[WS07] C. Wolter, A. Schaad: “Modeling of Task-Based Authorization Constraints in BPMN”, In: Proceedings of the International Conference on Business Process Modeling (BPM’07), vol. 4714 of LNCS, Springer, pp. 64–79.

Appendices

A. Appendix A

A.1. BPMN model for the THALES Case Study (preliminary version)

d3.2 visual environment for service description · 2017. 4. 12. · file:...

Documents