Formal Methods Application in Business Processes Specification Mario Guillén-Rodríguez1, Juan Frausto-Solís2, José Torres-Jimenez3 1
Instituto de Investigaciones Eléctricas Cuernavaca, Morelos, México
[email protected] 2 Instituto Tecnológico y de Estudios Superiores de Monterrey, Campus Morelos Cuernavaca, Morelos, México
[email protected] 3 Centro Nacional de Investigación y Desarrollo Tecnológico Cuernavaca, Morelos, México
[email protected]
Abstract. This article shows a new methodology that applies mathematical techniques, acquaintances as formal methods in the specification and analysis of Business Process Management System (BPMS) using graphic interfaces, and its application in the specification of industrial scale problems. The methodology of formal specification implanted provides a sound foundation for the specification of business processes, and it serves as basis for the design, analysis and installation of BPMS. This specification is expressed by means of a graphic language that generates a specification in language LOTOS. Starting from the specification in LOTOS and using analysis formal tools, the formal specifications obtained are analyzed, explored, filtered and verified.
1 Introduction The Business Process Management (BPM) refers to a work philosophy that places the business process in the center of its universe, and it consists on administering the life cycle of the process, with the support of well-known automation tools as BPMS [29],[30],[31],[32],[33]. The cycle of life of a process covers its conceptualization, representation (graph or textual), automation, simulation and testing, and implementation in the organization. On the other hand, the administration includes planning, following up, monitoring and controlling. At the moment it is considered that BPM is the natural evolution of the workflows. Therefore BPM will be defined based on the terminology of the workflow. At the moment, the process of business is characterized by applications that involve the access and manipulation of the information stored in different database and information systems. These systems are usually located in autonomous and heterogeneous software and in software platforms that are distributed in several nodes of computer network. The distribution of these systems reflects the decentralized nature of the modern com-
panies, while its heterogeneity and autonomy arise as a consequence of the diversity of the requirements of information search. Originally these systems were executed in isolated way to support individual applications, but it has being evident the need of cooperation among these systems. To fulfill these requirements, the concept of workflow has been used [1],[2],[26]. The Workflow Management Coalition (WfMC) defines the workflow as: “The automation of a business process, in part or as a whole, during the one which documents, information or tasks are transferred from one participant to another by action, according to a set of procedural rules”[26]. A Workflow Management System is defined as: “A system that defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with work flows participants and, where it is required, invoke the use of IT tool applications”[26]. There exist many definitions of BPM [29],[30],[31],[32],[33] the most common definition is: “Supporting business process using methods, techniques, and software to design, enact, control, and analyze operational process involving humans, organizations, applications, documents and other sources of information”[26]. A business process is the algorithm step by step to achieve a business objective. A process is the basic algorithm or the behavior of the process. The activities or tasks are defined as a step in a process. The activities or automated tasks are a step in a process and they are executed by engines. The activities or manual tasks are executed by people. The tasks are classified in two types, simple and compound. The simple tasks represent individual indivisible activities and the compound ones represent tasks that can be divided in sub-activities.
2 Problem Definition The administration of the business process in appropriate form should facilitate the coordination among different processes, and to manage the interoperability and the heterogeneity among different systems, likewise it is required to maximize the concurrence level, therefore it should be allowed to model and to specify concurrent systems. A concurrent system is a collection of sequential tasks, been executed in one or more processors that interact between each other and they exchange results between them and with the external environment [3]. Many of the problems in this type of systems arise of the necessity of sharing or of competing for the limited resources of the system (data or processing resources). The correct operation of a system sometimes means that it should prevent that certain operations happen in simultaneous form. Other problems arise as a result of the limitations of time in the execution of certain tasks. For these reasons the concurrent systems are designed considering the concurrent concepts, causation, non determinism, synchronization, communication and restrictions of time, therefore they demand a more careful treatment than in the case of sequential systems. Given the complexity of the systems with the characteristics mentioned it is required the use of a methodology that uses formal methods that allow the specification of distributed systems, the concurrency among processes, data heterogeneity, of communications and of computation platforms. Although formal specifica-
tion languages exist that allows to specify this type of systems (for example, LOTOS, Petri nets, Pi-Calculus), due to their mathematical complexity and their notation, they tend to inhibit their use in widespread form.
2.1 Difficulties of using formal methods in industrial applications The formal methods are a theoretical, very powerful concept that refers to the use of discreet mathematics and of the logic in the specification, design and construction of a system of computers and software. However, in practice the formal methods are seldom used. This contrast between the theoretical and the practical point owes itself mainly to the following causes: − lack of experienced people in formal methods and almost null adoption of the formal methods in the programming process, − the use of inadequate tools in the industrial environment forbids the use of the formal methods, − The application of the formal methods in general is carried out at prototype level, and models and inadequate examples are used. In spite of the above, optimism exists since at the moment the developers of formal methods they are working with these tools in its third or fourth generation. At the moment a variety of languages are used in the different phases of the life cycle of BPM. The main languages have a mathematical foundation based on the theories of Pi-Calculus and Petri nets. The Pi-Calculus [28] it is a language that defines concurrent processes that interact between each other in a dynamic fashion. Each process consists of one or more actions and they can be organized in sequential form, in parallel or in conditional trajectories or recursively. The Petri nets [14], [15], [16] , [17] they were created especially to represent concurrent systems. A Petri net is a graph directed with two types of nodes: places and transitions. The state of a Petri net is represented by a group of tokens distributed throughout the places, defining this way the state of the net. Due to the form of representing the state of the system (distributed on the net), the Petri nets are one of the most popular models to represent and to analyze systems with concurrency and parallelism. The languages based on the Pi-Calculus are [26],[27]: Web Services Choreography Description Language (WS-CDL), Web Services Choreography Interface (WSCI), Business Process Modeling Language (BPML) and XLANG. The languages based on the Petri nets are: Business Process Modeling Notation (BPMN), YAWL, Web Service Flow Language (WSFL) and Business Process Execution Language (BPEL) that is based on the two previous languages. In the next section it is presented a methodology, based on formal methods, for the specification of business processes. The methodology uses the language LOTOS that allows to specify and to verify systems in a rigorous way.
3 Specification Methodology The developed methodology applies formal methods to the specification of business processes. The methodology is formed by the following phases: the characterization of the application, the modeling of the application, the specification of the application, the analysis of the application, the refinement of the application, and the results of the application. The distinction of the phases is in some sense artificial and it cannot be taken literally (see Figure 1). Characterization phase: it has the objective to thoroughly synthesize the knowledge of the problem and the domain of the application; the related topics are also studied. The main components and their interfaces are identified, as well as the basic algorithms and control and flow data, the behavior and applications restrictions are understood.
Fig. 1. Specification phase of the proposed methodology The modeling phase: defines a suitable mathematical representation that constitutes the applications domain in such away as to allow us evaluate and predict the application behavior in such a context. The formal specification phase: it characterizes a planned system or existent one and expresses it in a formal language that verifies the syntactic validity and semantics of the specification. The specification describes a system and its wanted properties. Within the specification formalisms more used at the present time; are VDM, Z and Larch [4], and they focused to the specification of sequential systems. Other languages like processes algebras [5],[6],[7],[8],[9],[10],[11],[12],[13] Petri nets [14],[15],[16],
[17] Pi-Calculus [28], finite state automata and Statecharts [18],[19],[20], temporal logic [7],[8] they are focused to the specification of the behavior of concurrent systems. To carry out the formal specification a specification language was developed that receives inputs in graphic notation and as a result it produces a specification in the language LOTOS. At the bottom of Fig. 1, a rectangle is shown; that it contains the components of the interpreter of the graphic specification language of business processes (LEGPN). In turn, the interpreter is formed by a graphic editor and a translator of the language. The interpreter receives graphic inputs, in notation of Statecharts, and it generates a specification in LOTOS language. The LEGPN allows the definition of control and data flow among tasks. As a result of the edition a translation of the conceptual model captured by the editor to the specification of the system in the language of specification LOTOS takes place. Analysis phase: it predicts and calculates the behavior of the system, interprets or executes the specifications, verifies the main properties of the system and their invariants, establishes the consistency of the axioms and establishes the validity of the hierarchical different layers. Once the model is translated in a formal specification in the language LOTOS, tools of formal analysis are used to analyze and verify the behavior of the modeling system. The formal analysis refers to the techniques based on tools that are used in isolated form or in group form to explore, to debug and to verify formal specification, they are also used to predict, calculate or to refine the behavior of the specified system [7]. A great variety of tools exists to analyze concurrent systems written in LOTOS language [8],[12],[21],[22],[23] of which the following ones can be mentioned: CADP, TRAIN, OLA, OLD, LOLA, TOPO, ELUDO and ARA. According to the availability software requirements and hardware of these tools, in this work the programs ARA were used. The programs ARA are a group of utilities to analyze the behavior of concurrent systems. The programs ARA are used to find deadlocks, synchronization errors, illegal operations and other errors related to the logical behavior of a concurrent system. Refinement phase: this step allows the specification of the model in an incremental way. The model is analyzed from different perspectives to understand its behavior. From the logical point of view, the properties of the model are verified taking into account the semantics of the language, for example, deadlocks and cycles. From the functional point of view, the functional specified behavior is investigated including aspects like: dynamic behavior, input/output relationship, efficiency, design economy, orthogonality and functions independence. The refinement process is taken in the following way: The first stage of the specification produces an abstract description of the system. Each one of the following stages of the refinement derives in a more refined description of the system, which should be consistent with all the specifications taken previously. Each new refinement is a more complete model of the system to specify, with a level of abstraction in more detail. Results phase: Once the user is satisfied with the analyses carried out to the specifications, the results are stored in cases of study. An important part of the methodology is the phase of formal specification, for which they were developed: the graphic specification language of processes, the functions mapping between the graphic lan-
guage of inputs and the output language LOTOS. Likewise an interpreter of the language was developed that shows the feasibility of implementation of the language and of the methodology.
3.1 Processes Graphic Specification Language Virtually all software can be specified by a state machine [24]. To model the current applications that require the representation of distribution, concurrency and heterogeneity in their components, the finite states machines have the following limitations: to) they don't have the concept of depth, b) they do not provide hierarchies, neither modularity, c) they are inherently sequential and they cause a state explosion when parallel control threads are modeled. To alleviate the previous limitations, a new concept denominated Statecharts has been developed [18],[19],[20]. The Statecharts are formalisms of graphic specification that enriches the diagrams of transition of traditional states with a hierarchical structure on the states and with a graphic convention that represent in explicit form the parallelism and the communication among parallel components. The Statecharts are based on the states machine of Mealy-Moore [24] but they contain a number of improvements that enlarge the understanding and scalability of the models of states. The improvements include: to) nested states, b) concurrency, c) orthogonal regions, d) conditional transitions and guards, and) the actions can associate to the input/output of states, or to the occurrence of transitions, f) activities inside states. Also, in a graph of states, the states can break down in sub-states, forming a hierarchy. Three types of states exist: OR states, AND states, and Basic states. The OR states have sub-states that are related between them by means of an exclusive OR, the AND states, also called orthogonal regions, they are related with an AND, and they represent the parallelism among the states involved in the orthogonal component. The events are the means of communication among components of a system. The labels of the transitions in Statecharts have the structure ev[con]acc, where: ev is a combination of Boolean events; con it is a Boolean condition; acc is an action. The three parameters are optional. If the state source of the transition is active and it the event ev occurs and the condition with it is true then the transition is carried out, and the action acc is executed. The formalization of the hierarchical structure of the states is carried out by means of a directed finite marked tree, also well-known as tree of derivation of grammars by means of which is defined the language LGEPN, likewise it is defined the language for the transitions [34].
3.2 Element Mapping Next it is shown a translation of Statecharts to a specification in LOTOS. In this translation each state corresponds to a process and the transitions (arrows) leaving a state correspond to the different actions that can be taken, If the transition has the effects
like in the Statecharts, it is taken as an action and it continues with the process that corresponds to the state destination. Next it is shown the mapping of elements of the Statecharts to processes just as they are defined in LOTOS. If s is a basic state then s=stop If s is an initial state then s=stop If s is a final state then s=exit Semantically a Basic state corresponds to the process inaction stop, except for the final state that corresponds to the process exit, If s is an OR state, and s1, s2., sn is the sub-state of s and T it is the group of transitions among those states, then:
s = si [> ¦{t ; s j | t ∈ T ∧ output (t ) = si ∧ input (t ) = s j }
(1)
If si is a basic state or
s = si >> ¦{t ; s j | t ∈ T ∧ output (t ) = si ∧ input (t ) = s j
(2)
If it is an OR state or an AND state where t is the transition that comes out of si and enters sj. The operator to enable is represented by “>>”; and the operator to prefer action for “;” and “[>” it is the operator to disable and ||| it is the operator of parallelism. An OR state is mapped through the operator to disable, if the precedent state is a basic state. In case the precedent state is an OR state or an AND state the mapping is carried out by means of the operator to enable. If s is an AND state and s1, s2., sn are substates of s and T is the group of transitions that enter to those states, then s1 ||| s2 ||| … ||| sn. The translation of an AND state maps their component states to the parallel composition of the resulting processes of the translation of each one of the processes, In the following section a case of test is shown that it uses the mappings described previously.
4 Test Cases for Specification and Analysis This section uses a representative test case to show the feasibility and the potential of the methodology.
4.1 Practical Test Case The Dispatcher Training Simulator (DTS) is software out of line for electrical power systems. DTS emulates a Energy Management System (EMS), but it is isolated of all the activities in real time [25].
The main objective of DTS is to provide a tool for the training of the operators of the electric system in the centers of energy control on functions of SCADA, of generation and of electric nets. The functions of SCADA include the monitoring of the conditions of the system, alarm acknowledge, supervisory control and field communications with the personnel of the substations. The generation functions include the automatic generation control, transactions assignment, economic office, unit commitment, communication and coordination with the generating plants. DTS uses a model of dynamic system of power to create the operative feigned environment. The model of the power system consists of a detailed description of the topology and of the components of the power system. DTS uses this model to follow the dynamics of the turbines, the operation of the switches, the action of the relays, and the variations of frequency, generation and loads. DTS is formed by a series of subsystems to carry out its function. In the following section one of the subsystems is described; in addition to the of validation subsystems, the initialization and execution subsystems must be specified. The methodology proposed in Section 3 was successfully applied to the specification of DTS. During the analysis stage they were illegal operations, deadlocks and synchronization errors and other logical errors related to the behavior of the system that were corrected in the specification stage.
4.2 Databases Validation of DTS The construction of the databases used by the models of DTS is supported through four out of line applications. The applications are: NETMODEL (data network, stored in the database NETMOM), GENMODEL (data generation, stored in the database GENMOM), SCADAMDL (data SCADA, stored in the database SCADAMOM) and DTSMODEL (data relays and of the dynamics of the prime motors).
Fig. 2. DTS validation sequence
Figure 3 shows the specification in language LOTOS equivalent wing graphic representation of the processes of figure 2. The system begins with a selection of transitions tl, t12 or tl5 just as it is shown in figure 3 and reflects different faithfully the alternatives that can happen when beginning the validation of DTS indicated in the figure 2. Another bifurcation point exists where you can select one of the transitions t6 or t8, indicated by the selector operator “[ ]”. Process Valida [t5,t6,t7,t8,t10,t12,t11,t1,t2,t3,t4]:= ((t5;((t6;(t7;exit))[](t8;(t10;(t7);exit))))) [] (t12;(t11;((t6;(t7;exit))[](t8;(t10;(t7;exit)))))) [] (t1;(t2;(t3;(t4;(t11;((t6;(t7;exit))[](t8;(t10;(t7;exit ))))))))) endproc In this section the advantages of the language of specification of business processes have been shown. Likewise their use has been described in a case study in complex applications of electrical engineering. The obtained results have been proven and they are consistent with the expected results.
5 Conclusions This work has shown an innovative focus in the solution of the problem of specification of business processes. A specification methodology was developed that applies formal methods in the specification and analysis of systems of business processes in applications of industrial scale. An important part of the methodology is the specification phase, for that which a language was developed that receives input in graphic notation and it produces a specification in language LOTOS, as well as an interpreter of the same one that allows to show the feasibility of implementation of the language and of the methodology. From this work the following contributions can be pointed out: − It allows to identify problems in the specification of the business process before it is implemented, reducing the cost for later corrections, − Helps to analyze the system from different points of view with the purpose of improving the process, − It contributes fundamentally to overcome the difficulties of using the formal methods in the specification of applications of industrial use and in a domain of complex nature as are the concurrent systems,
− It provides an innovative methodology for the formal specification of systems of business processes using graphic and friendly interfaces that allow to hide the complexity of the mathematical concepts and of the logic, without losing their formality, allowing also as means of communication among the different participants of the specification, like they are the analysts, developers and users of the system, − Nevertheless in this investigation the methodology is applied to Dispatcher Training Simulator, it can be used to other application domains where processes of business are given, for example, systems of information and electric power control, systems of data acquisition of generating plants and systems of electric power measurement, among other domains.
References 1. Alonso G., and Scheck H.: Database Technology for Workflow Management (Position Paper), Database Research Group, Institute for Information Systems, ETH Zentrum, Zurich CH-8092, Switzerland, December 20, (1995) 2. Georgakopoulus D., Hornick M. F., Sheth A.: An Overview of Workflow Management: From Process Modeling to Workflow Automation infraestructure, in Distributed and Parallel Databases, 3(2), April (1995) 119-153 3. De Nicola R., Smolka S. A.: Concurrency: Theory and Practice, in ACM Computing Surveys 28A(4), December, (1996) 4. Sanella D.: A Survey of Formal Software Development Methods, Department of Artificial Intelligence and Department of Computer Science, University of Edinburgh, July ( 1988) 5. van Eijk P. E. J.: Software Tools for the Specification Language Lotos, Ph.D. Thesis, Twente University, Netherlands, 1988. 6. Harel D., and Gery E.: Executable Object Modeling with Statecharts, in Proceedings 18th Int. Conf. Soft. Eng., IEEE Press, (1996) 246-257 7. NASA 95: Formal Methods Specification and Verification Guidebook for Software and Computer Systems, Volume I: Planning and Technology Insertion, NASA-GB-002-95, Release 1.0. http://eis.jpl.nasa.gov/quality/Formal_methods/ 8. NASA 97: Formal Methods Specification and Analysis Guidebook for the Verification Software and Computer Systems, Volume II: A practitioner's Companion, NASA-GB-OOI-97, Release 1.0. http://eis.jpl.nasa.gov/qualitylFormal_methods/ 9. Cleaveland R., et al,: Strategic Directions in Concurrency Research, in ACM Computing Surveys 28(4), (1996) 607-625 10. Milner R.: Communication and Concurrency. Prentice Hall International Series in Computer Science, (1989) 11. Hoare C.A.R.: Communicating Sequential Process, Prentice Hall, (1985) 12. Turner K. J. : The Formal Specification Language LOTOS a Course for Users, Department of Computing Science, University of Stirling, Stirling FK9 4LA, Scot1and, (1996) 13. Logrippo L., Faci M., Haj-Husscin M.: An Introduction to LOTOS: Learning by Examples, University of Ottawa, Protocols Research Group, Department of Computer Science, Ottawa, Ontario, Canada KIN6N5, (1998) 14. Agerwa1a T.: Putting Petri Nets to Work, in Computer, IEEE, December (1979), 85-94 15. Murata T.: Petri Nets: Properties, Ana1ysis and Applications, in Proceedings of the IEEE, 77(4), (1989) 541-580 16. Peterson J. L.: Petri Nets, in Computing Survey, 9(3), (1977), 223-252
17.Jensen K.: An Introduction to the Theorical Aspects of Coloured Petri Nets, Computer Science Department, Aarhus University, Ny Munkegade, Bldg. 540, DK-8000 Aarhus C, Denmark, (1994) 18. Harel D., Naamad A.: The STATEMATE Semantics of Statecharts, in ACM Transaction Software Engineering Method 5:4, (1996) 19. Harel D., Gery E.: Executable Object Modeling with Statecharts, in Proceedings 18th Int. Conf. Soft. Eng., IEEE Press, (1996), 246-257 20. Douglass B. P.: UML Statecharts, white paper, in http://www.ilogix.com, (1998) 21. CADP: Caesar/Aldebaran Development Package, a Software Engineering Toolbox for Protocols and Distributed Systems. Email: http://www.inria1pes.fr/vasy/cadp.html, (2000). 22. Quemada J., Azcorra A., Pavón S.: Design with LOTOS, Depto. Ingeniería de Sistemas Telemáticos, Universidad Politécnica de Madrid. (1993) 23. ARA: ARA Tools 2.0, User's Manua1 and Reference Manual, Jukka Kemppainen, VTr Electronics, P.O. Box 1100, Fin-90571, Oulu, Finland. Email:
[email protected], August, (1994) 24. Aho A. V., R. Sethi, Ullman J. D.: Compiladores Principios, técnicas y herramientas, Addison-Wesley Iberoamericana, (1990). 25. ESCA: DTS Instructor Guide, Operator Guide, Software and Maintenance Manua1, ESCA Corporation, Washington, (1994) 26. Wil M.P. van der Aalst, Arthur H.M. ter Hofstede, Mathias Weske: Business Process Management: A Survey. BPM, Conference on Bussiness Process Management: On the Application of Formal Methods to Process-Aware Information Systems in Netherlands 2003. Published in BPM 2003, LNCS 2678, 1-12 27. Mike Havey: Essential Business Process Modeling, O'Reilly (2005). 28. R. Milner: Communicating and Mobile Systems: the Pi-Calculus, Cambridge University Press, Cambridge (1999). 29. Margaret May: Business Process Management, Integration in a web-enabled environment. Prentice Hall (2003). 30. Robert B. Walford: Business Process Implementation for IT Professionals. Artech House (1999). 31. Thomas W. Malone, Kevin Crowston and George A. Herman (eds): Organizing Business Knowledge: The MIT Process Handbook, The MIT Press (2003). 32. Howard Smith, Douglas Neal, Lynette Ferrara and Francis Hayden: The Emergence of Business Process Management. A report by CSC’S Research Services 2002, version 1.0. 33. Rick L. Click and Thomas N. Duening: Business Process outsourcing, The Competitive Advantage. John Wiley & Sons (2005). 34 . Mario Guillén-Rodríguez: Metodología para la Especificación de Tareas Concurrentes en Multibase de Datos, Tesis de Doctorado, ITESM, Campus Cuernavaca, Cuernavaca, Mor., México, (2000)
