Verification of ArchiMate Behavioral Elements by Model Checking

. In this paper we investigate the problem of veriﬁcation of business processes speciﬁed with ArchiMate language. The proposed so-lution employs model checking techniques. As a veriﬁcation platform the state of the art symbolic model checker NuSMV is used. We describe a method of fully automated translation of behavioral elements embedded in ArchiMate models into a representation in NuSMV language, which is then submitted to veriﬁcation with respect to requirements expressed in CTL. The requirements speciﬁcation can be entered by user, but we also propose to derive some of them automatically, based on analysis of control ﬂows within business processes. The solution was implemented as a plugin to Archi, a popular ArchiMate modeling tool. Application of the method is presented on an example of a small business process.


Introduction
In this paper we investigate an application of model checking techniques to automated verification of behavioral description embedded within ArchiMate models. ArchiMate is a lightweight language providing a uniform representation of enterprise architecture [?]. The language comprises elements of various types, however, constructs allowing to model behavior can be found only in the Business layer. They include events, processes (also understood as activities), interactions, collaborations and several types of junctions. Therefore, the verification of ArchiMate behavioral elements falls into a wide domain of business process verification [?].
Business models can comprise a large number of processes. For clarity reasons they are often depicted in form of several views, that cover only selected parts of the model. In consequence, behaviors embedded in the model are distributed among the views, what often makes them difficult to track. Although modeling tools offer support for local syntax checking, e.g. correct use of links between elements of the graphical language, some structural errors remain undetected, especially those resulting from incorrect use of synchronization mechanisms [?]. Partial analysis of model behavior can be performed by simulation techniques, however, only application of formal methods can give unequivocal answer that the verified model exhibits desired properties.
Formal system verification can by done either by deductive reasoning or model checking [?]. Deductive reasoning consists in formulating theorems specifying desired system properties and proving or falsifying them using manual or automated techniques. The advantage of deductive reasoning methods is their ability to verify systems with infinite domains (number of states). However, they give very little information on causes, if the verified property does not hold.
Model checking allows to verify a concurrent system modeled as a finite state transition graph against a set of specifications expressed in a propositional temporal logic. It employs efficient internal representations and quick search procedures to determine automatically, whether the specifications are satisfied along the computational paths. Moreover, if a specification is not met, the procedure delivers a counterexample that can be used to analyze the source of the error. Although formal tools reached state of the art, they are not commonly used in engineering practice. According to Huuck [?] three factors decide on successful application of formal tools: they should be simple to use, the time spent on model preparation and verification should be comparable with other user activities, and, finally, a tool should provide a real value, i.e. deliver information that was previously not available.
The goal of our work was to develop a software tool that fully automatically translates behavioral elements of a business model expressed in ArchiMate language to a corresponding finite-state graph required by a model checker. We were also attracted by an idea of deriving automatically requirements specifications based on control flows within business processes.
As a verification platform the state of the art symbolic model checker NuSMV [?] is used. NuSMV allows to enter a model being a set of communicating finite state machines (FSM) and automatically check its properties specified as Computational Tree Logic (CTL) or Linear Temporal Logic (LTL) formulas. For a given temporal logic formula F, NuSMV provides the answer that F is satisfied by the model or it delivers a counterexample falsifying it.
The concept of verification system is presented in Fig. 1. The business model is defined within Archi [?], a well known ArchiMate modeling tool. We have developed an Archi plugin that extracts a subgraph of ArchiMate behavioral elements and transforms it into NuSMV model descriptions.
As a specification language CTL is used. Basically, a specification of system properties is entered by a user. This is a manual task, that requires a certain insight into the business process, as well a knowledge of mapping of its elements onto NuSMV model. However, a part of the specification is generated automatically by an analysis of the process structure. The paper is organized as follows: next Section 2 discusses various approaches to data verification of business models. It is followed by Section 3, which presents ArchiMate language. In Section 4 the translation procedure is described. Application of the presented approach to a business process verification is presented in Section 5. Section 6 provides concluding remarks.

Related works
Application of formal methods to verification of business processes was surveyed by Morimoto [?]. Author distinguished three prevalent approaches: based on automata, Petri nets and process algebras. The first approach consists in translating the process description into a set of communicating automata (state machines) and performing model checking with such tools, as SPIN or UPPAAL In analysis of Petri net models basically simulation techniques are used, especially in case of more expressive colored Petri nets.
Model checking has an established position in verification of business processes. I was applied in [?] to BPMN models extended with temporal and resource constraints. In [?] verification of of e-business processes was achieved by translation to CSP language and checking refinement between two specifications. In [?] authors implemented a system that translates BPEL specification into NuSMV language and then allows to check properties defined as CTL formulas. Three types of correctness properties were analyzed: invariants, properties of final states and temporal relations between activities. The first two can be classified as safeness, the last as the liveness property. Similarly, in work by Fu et al. [?] CTL was applied to the verification of e-services and workflows with both bounded and unbounded number of process instances. Work [?] discusses verification of data-centric business processes. The correctness problem was expressed in the LTL-FO, an extension to the Linear Temporal Logic, in which propositions were replaced by First Order statements about data objects.
In our previous works [?,?] we proposed a method for verification of Archi-Mate behavioral specifications based on deductive reasoning. The described approach consisted in transforming ArchiMate model into a set of LTL formulas, then extending it with formulas defining desired system properties and formally proving them using semantic tableaux method.
NuSMV [?] is a state of the art model checker that has been succesfully used for various verification tasks including formal protocol analysis [?], verification of requirements specification [?] or planning tasks [?]. The package uses a special language (named also NuSMV) to define the verified model as a set of linked finite state machines, as well as its specification in form of temporal logic formulas. The model submitted to the verification tool must be manually coded in NuSMV language or generated from another language amenable to state transition system, e.g a state charts [?] or reachability graphs of Petri nets [?].

Archimate
ArchiMate [?] is a contemporary, open and independent language intended for description of enterprise architectures. It comprises five main modeling layers shortly characterized below. The Business layer includes business processes and objects, functions, events, roles and services. The Application layer contains components, interfaces, application services and data objects. The Technology layer gathers such elements as artifacts, nodes, software, devices, communication channels and networks. Elements of the Motivation layer allow to express business drivers, goals, requirements and principles. Finally, Implementation&Migration layer contains such elements, as work package, deliverable and gap.
ArchiMate allows to present an architecture in the form of views which, depending on the needs, can include only items in one layer or can show vertical relations between layers, e.g.: a relationship between a business process and a function of the component software.
ArchiMate was built in opposition to UML [?], which can be seen as a collection of unrelated diagrams, and Business Process Modeling Notation BPMN [?] which covers mainly behavioral aspect of enterprise architecture. The definition of a language has been accompanied by an assumption, that in order to build an expressive business model, it is necessary to use the relationships between completely different areas, starting from business motivation to business processes, services and infrastructure.
Archimate provides a small set of constructs that can be used to model behavior. It includes Business Processes, Functions, Interactions, Events and various connectors (Junctions), which can be attributed with a logical operator specifying, how inputs should be combined or output produced. According to language specification casual or temporal relationships between behavioral elements are expressed with use of triggering relation. On the other hand, Archimate models frequently use composition and aggregation relations, e.g. to show that a process is built from smaller behavioral elements (subprocesses or functions).
Although the set of behavioral elements seems to be very limited when compared with BPMN [?], after adopting a certain modeling convention its expressiveness can be similar [?]. An advantage of the language is that in allows to comprise in a single model a broad context of business processes including roles, services, processed business objects and elements of lower layers responsible for implementation and deployment.

Model generation
This section discusses language patterns that can be used to model ArchiMate elements in NuSMV, as well as details of the translation procedure.

ArchiMate model
The internal structure of an Archimate model constitutes a graph of nodes linked by directed edges. Both nodes and edges are attributed with information indicating a type of element or relation. Generating NuSMV code describing behavioral aspects of Archimate model we focus on components of the Business layer : processes (interactions, functions), events and various junctions.
It should be noted that Archimate behavioral constructs have no precisely defined semantics. In fact, translation from Archimate specification to NuSMV assigns a semantics, which, although arbitrarily selected, follows a certain intuition, e.g. how to interpret an activity or an event.
Definition 1 (Archimate model). ArchiMate model AM is a tuple V, E, C, R, v, e , where V is a set of vertices, E ⊂ V × V is a set of edges, C is a set of ArchiMate element types, R is a set of relations, vt : V → C is a function that assigns element types to graph vertices et : E → R assigns relation types to edges.
As we focus on business layer elements that are used to specify behavior, it is assumed that C ={Process, Function, Interaction, Event,Junction, AndJunction, OrJunction, Other } and R ={triggering,association,composition, other }.

NuSMV model
The basic structural unit in NuSMV language is module understood as a set of variables and statements that assign to them initial values and define a transition relation. Depending on the module definition, we may distinguish input variables corresponding to stimuli, internal state variables and output variables (actions).
Definition of a module introduces a new type that can be instantiated. Hence, it is possible to declare a variable of a module type and bind it during declaration resembling a constructor call to a number of input variables.Subsequent variables definitions may reference outputs of other modules instances as their inputs. This allows to define a system of communicating state machines of desired complexity, which propagates input stimuli to its components causing subsequent state changes and generation of output signals. Typically, the model integration is achieved within the special main module, however, it can be distributed among lower level modules, which are referenced from main.
After an analysis of components used to describe ArchiMate processes the following basic modules were identified and implemented: -atomicP rocess n : n-ary atomic process has exactly one input, one primary output and n additional outputs, which can be activated if one of n exceptions occurs. The exception should be modeled in ArchiMate as an event linked with the process by an association relation. event: has only one input and one output (a boolean flag). Multiple recipients may use this flag as trigger. -andF ork: used to model AndJunction in Archmate. The module construction is analogous to event. -andJoin n : n-ary andJoin produces output signal, if all n inputs are set to TRUE. -xorF ork n : n-ary xor-fork have one input and n outputs. Upon module activation, only one from outputs will be triggered. -xorJoin n : n-ary xor-join has n inputs and sets the output flag if any of them is set. Moreover it tracks the number of inputs, e.g. if two from n inputs are activated, the output flag will be set twice. Fig. 2 shows the state diagram of the module atomicProcess1. The number 1 indicates the number of additional outputs activated as a result of exception occurrence. The process is activated by the input signal trigger. Upon signal arrival it makes the state transition from idle to started. Then a choice can be made between the states finished and interrrupted1. Synchronously, the corresponding output variable is set: either outflag or exccptflag1 to TRUE. The output variable, whichever is set, will be cleared during the transition to idle state. The NuSMV code for the module is given in Fig. 3. It should be mentioned, that n exceptional outputs, we generate module atomicProcess n with states interrupted1,. . . , interrruptedn and n output flags exceptflag1,. . . , exceptflagn.

Generation procedure
The generation procedure consists of the following stages:  outputs) or n : 1 (m inputs and one output). Hence elements with the arity n : m are replaced by two two elements: the first is an appropriate xorJoin or andJoin of arity n : 1. The second is an atomic process, event or fork of arity 1 : n. 2. Assigning representation. For each element, based on its type and numbers of inputs/outputs, an appropriate NuSMV module type is selected and configured. Only required modules are generated. E.g. if the specification uses only processes with one and three exceptional outputs, only modules defining atomicProcess1() and atomicProcess3() will be generated. 3. Main module generation. This step comprises declaration of variables and linking them. For roots (modules without inputs) appropriate initial variables and transitions are added as well. 4. Specification generation. The implemented procedure analyses the graph of elements and generates CTL specifications. See Section 4.5.

Small example
We will discuss the effects of the generation procedure on a small process example presented in Fig. 4. The whole process is activated upon occurrence of the event Start. Then the subprocess P1 is launched. If P1 terminates correctly, the event Stop is produced. However, P1 execution can be interrupted by the event Excpt, which triggers the subprocess P2. After finishing P2 a decision is made, whether the whole process should terminate (abort) or P1 should be launched once again (retry). The generated NuSMV code for the main module is presented in Fig. 4 below the ArchiMate diagram. It can be noticed, that variables definition are unordered and the code contains forward references, e.g. the output variable P1.excptflag1 is referenced before P1 definition. The event Stop has two inputs.
As the result of model refactoring an OrJunction (variable Junction Before Stop) was introduced into the model. For the event Start constituting a root element, the boolean variable Start trigger with corresponding transition was added.

Generation of specification
As a specification language we use CTL, which allows to formulate properties applying to a tree of computations (paths) starting from a given state. As the tree defines a set imaginable futures, CTL is called the branching time logic. CTL formulas are combinations of two types of operators path quantifiers and linear-time operators. The path quantifiers are: A (for every path in a tree) and E (there exists a path in a tree). Temporal operators include: G (G p means that p holds true globally in the future) and F (F p means that p holds true sometime in the future).
Typically a specification formally describing requirements is entered by a user. However, we tried to derive some liveness requirements based on control flows within ArchiMate model (see Definition 1). The implemented procedure generating a set of specifications comprises the following steps: 1. Build a set of paths Π = {π i } within the Archimate model, 2. Restrict elements in π i to events only (elements from the set Evt) 3. Build a partial mapping R : Evt → 2 Evt 4. Generate the specification for each pair (e i , R(e i )) in R In the first step (1) a depth-first search starting from roots (ArchiMate elements having no predecessors) is performed. It returns a set of paths Π = {π i } comprising ArchiMate elements linked by control flow relation. For a path π i = (e ib , . . . , e ie ), its last element e ie is either a final element in the model (without successors) or a branching element (already present in π i ). The set of obtained paths reflects only topological relations within the process model. The procedure does not attempt to interpret the model according to any behavioral semantics. This is left to the verification tool.
In the step (2) the paths from Π are restricted to ArchiMate elements being events. We decided to focus in requirements specification on elements of Event type, because in business process definitions they are typically used to mark important process states (e.g. initial, final and intermediate events).
In the next step (3) a partial mapping R : Evt → 2 Evt is built. The mapping R assigns all (potentially) reachable events to first events appearing in paths from Π Finally, in the step (4) for each event e ∈ dom R, a pair (e, R(e)) is converted into a set of specifications taking the form of (1) For the process presented in Fig. 4 an example of generated CTL specification is: AG (Start.outflag -> EF (Stop.outflag | Excpt.outflag)). It is equivalent to the statement: for every path, starting with Start event, it is possible to reach a state, where Stop or Excpt events occur. This requirement is obviously true. Another generated specification: AG( Start.outflag -> AF( Stop.outflag & Excpt.outflag )) is false, as justified by a counterexample path comprising 14 elements produced by NuSMV.

Business process example
In this section we present a more realistic example of ArchiMate specification describing a process of selling a product (a service) to a client. The process is divided into two stages: preparation presented in Fig. 5 and finalization (Fig. 6) separated by the event Contract Prepared. The finalization phase is far more complex. During execution of the Acceptance subprocess two events: Timeout and Rejection may occur and in consequence loop back the whole process to a previous stage. Contract signing by both parties, as well as Implementation and Signed contract scanning are placed between ArchiMate AndJunctions (forks and synchronization joins.) Based on this specification the NuSMV model was generated. During refactoring phase second AndJoin in Fig. 6 was split into two (serving as join and fork). Another join was added before the interaction Terms negotiation. The main module of NuSMV comprised 22 finite state machines, whereas the flattened model consisted of 47 state variables. Considering their ranges, the whole state space comprised 3 9 · 2 37 · 5 = 1.35 · 10 16 states, whereas the number of The first was checked to be true, whereas the second, as expected, occurred false. The path constituting a counterexample for the second specification comprised 42 states.
An example of a user-defined CTL specification equivalent to the statement that all contracts signed by a client are finally scanned is: AG (Signing by Client.outflag ->(AF Scan Signed Contract.outflag )). NuSMV reported is as true.
For the presented example verification of one CTL specification took about 43 seconds. However, after applying dynamic variable ordering this time decreased to 6.64 sec. We may conclude that although the state explosion is alleviated in NuSMV by employing internal OBDD representation, it seems that it still remains a problem. Hence, dedicated model generation techniques focusing on keeping models compact, e.g. generating partial models, should be employed.

Conclusions
This paper investigates the problem of automatic verification of behavioral specification embedded within ArchiMate models. We were motivated by an idea of developing a solution tightly integrated with Archi modeling tool that would allow to extract behavioral elements from an ArchiMate specification, then fully automatically translate it into a model in NuSMV language and finally verify it with the NuSMV model checker. Requirements specification in form of CTL formulas can be entered by user, but the implemented tool is capable of generating specifications based on analysis of control flows. We discuss methods of model transformation applied in the implemented software: language patterns used to model atomic processes and other elements, as well as rules for translating them into NuSMV modules. Finally, application of the method is presented on an example of a business process.
An issue that requires closer investigation is the time efficiency of the verification process. Surprisingly, papers discussed in Section 2, which claim to use the NuSMV model checker, do not provide evaluation data on complexity of verified processes and verification times. On the other hand, sample specifications distributed with NuSMV are built manually and optimized. The main factor influencing memory usage is the ordering of OBDD variables used in internal representation. Many NuSMV models are distributed with files defining ordering, which was determined by performing a separate optimization task.
ArchiMate is primarily a modeling language. It does not define semantics of behavioral elements. Application of certain modeling patterns and methods of translating them to a NuSMV language is an arbitrary decision related to assumed semantics. Probably, several options and alternatives controlled by program parameters should be considered.