Softw Syst Model (2004) / Digital Object Identifier (DOI) 10.1007/s10270-004-0066-x PSL: A semantic domain for flow models Conrad Bock 1 , Michael Gruninger 2 1 U.S. National Institute of Standards and Technology, 100 Bureau Drive, Stop 8263, Gaithersburg, MD 20899-8263, USA e-mail: conrad.bock@nist.gov 2 Institute for Systems Research, University of Maryland, College Park, MD 20742, USA e-mail: michael.gruninger@nist.gov Received: 25 June 2003 / Accepted: 22 November 2003 Published online: 10 November 2004 – Springer-Verlag 2004 Abstract. Flow models underlie popular programming Runtime effects are represented in the most concrete way, languages and many graphical behavior specification to cover all possible execution traces. Desired behavior is tools. However, their semantics is typically ambiguous, specified by constraining which of the possible executions causing miscommunication between modelers and unex- are allowed. Reducing ambiguity enables more powerful pected implementation results. This article introduces abstractions, such as partial specifications that incremen- a way to disambiguate common flow modeling constructs, tally add constraints in behavior taxonomies. The runtime by expressing their semantics as constraints on runtime representation considered in this paper is the Process Spe- sequences of behavior execution. It also shows that re- cification Language (PSL) [12,23], which is defined in first- duced ambiguity enables more powerful modeling ab- order logic. Constraints on runtime effects are also stated stractions, such as partial behavior specifications. The this way, making behavior specifications in PSL amenable runtime representation considered in this paper uses the to automated reasoning with widely available inference Process Specification Language (PSL), which is defined engines. in first-order logic, making it amenable to automated rea- The article begins with a short discussion relating am- soning. The activity diagrams of the Unified Modeling biguity, abstraction, and expressiveness in languages. It Language are used for example flow models. identifies several unclear aspects of a typical flow model that will be addressed in the paper. Section 2 gives some Keywords: Flow model – Flow semantics – PSL – Pro- background on PSL, the approach it takes to semantics, cess specification – Control flow – Data flow – Concur- and how it is presented in this article. Section 3 intro- rency – UML – Activity model duces the basic PSL concepts for representing runtime execution, how these are composed, and how constraints Communicated by Steve Cook are written on them. Section 4 covers the ordering of steps in an execution. Section 5 covers specifications where the steps are unordered. Section 6 applies the techniques of Sect. 4 to create behavior taxonomies using partial flow Abbreviations: specifications. Section 7 addresses the issue of control- ling what an inference engine can add to a specification CL = Common Logic (closure). Section 8 briefly examines other approaches to KIF = Knowledge Interchange Format process semantics. OCL = Object Constraint Language Examples are given in activity diagrams of the Uni- PSL = Process Specification Language fied Modeling Language, version 2 (UML 2) [2, 27], but UML = Unified Modeling Language could be other flow diagrams, or even programming lan- Flow models are the most common form of behavior guages, most of which are textual forms of flow models. specification. They underlie popular programming lan- Some of the examples happen to require hardware or hu- guages and many graphical behavior specification tools. mans, but implementations would often include software However, their semantics is typically given in natural lan- to coordinate the other two, and in any case no restric- guage or in varied implementations, leading to unexpected tion is implied by UML. For lack of more general terms, effects in the final system. This article gives a way to dis- we use “execution” and “runtime” from software to mean ambiguate common flow modeling constructs in terms of the actual playing out of a specified activity, whether it is constraints on runtime sequences of behavior execution. in a computer, robot, or human organization.
C. Bock, M. Gruninger: PSL: A semantic domain for flow models 1 Ambiguity, abstraction, and expressiveness dressed by a construct that clarifies whether additional behavior occurrences can be introduced between Paint and Dry. The new construct increases expressiveness by Ambiguity and abstraction have the common character- supporting partial specification of processes, which in istic of omitting information. However, in abstraction the turn enables behavior classification (see Sect. 6). In gen- omission is intentional, clearly identified, and only con- eral, abstraction not only reduces ambiguity, but also in- tains information that users do not need. In ambiguity the creases the power of languages. omission is inadvertent, unidentified, and contains use- ful information. For example, readers of in Fig. 1 often take the arrow to mean message passing, so the diagram 2 PSL and semantics would be incorrectly interpreted as saying that the behav- ior Paint sends a message to the behavior Dry. Or those The approach taken in this paper is to use language elem- familiar with rule-based techniques might take it to mean ents referring directly to runtime execution, for example that drying must always happen after painting whenever the executions of Paint and Dry, sometimes called a se- the behavior Paint is performed. It is actually intended to mantic domain. In particular, the idea is to define a simple say the runtime effect of an execution of the ChangeColor set of concepts that cover all possible runtime execution behavior is that an execution of the behavior Paint will traces, then use these concepts to specify which execution occur, and after that is completed, an execution of the be- traces are allowed. For example, if the arrow between Paint havior Dry will occur. However, the specification does not and Dry under ChangeColor rules out any other behaviors say that it means this and only this. occurring in between, then a statement can be written to Figure 1 is ambiguous not because it is graphical, tex- only accept execution traces where that is the case.At run- tual languages have the same problem, but because it is time, exactly one of the allowed traces will actually happen specifying execution with constructs that only implicitly for each execution of ChangeColor, and it will conform to refer to runtime, rather than explicitly. For example, the the ChangeColor specified in this way. nodes labeled ChangeColor, Paint, and Dry will be exe- The runtime representation in this paper is PSL, which cuted many times in many situations, and the diagram is designed to facilitate correct and complete exchange of does not clarify which executions are referred to, or how process information. It is based on a long period of research the graphical nesting and arcs constrain them. The exact stemming from the situation calculus [21, 28] and enter- runtime effect is only given in documentation, examples, prise modeling [5, 6]. It has been applied in scheduling, or other human communication, and in implementations, process modeling, process planning, production planning, which may or may not conform to the original specifica- simulation, project management, workflow, and business tion. The one-to-many mapping between language elem- process reengineering. PSL is project 18629 at the Inter- ents and runtime effects makes the specification more national Organisation of Standardization, and part of the concise, but also more imprecise. work is a Draft International Standard. Other open questions about Fig. 1 include: PSL has a rigorously-developed semantics using first- 1. Are other behaviors allowed to be introduced in order logic, and is based on a three-step methodology: ChangeColor? For example, can an inspection of the identifying intuitions, refining them in mathematical paint occur after painting and before drying? structures, and then defining a logical language for the in- 2. Is there any constraint on how long after painting that tuitions [9, 12]. Specifically, we first chose intuitions about drying must occur? executing processes arising from applications and exist- 3. Is it possible under exceptional conditions to not do ing languages [29]. These restricted the scope of the effort, any drying at all, for example, if the paint job is acci- and served as informal requirements. Next, we mapped dentally ruined for some reason? each intuition to an element of some mathematical struc- 4. Is there any constraint on what behaviors may happen ture. These are defined either by specifying some class concurrently with painting, for example operating leaf of algebraic or combinatorial structures, or by extending blowers nearby? classes of structures defined for other parts of PSL. Ex- Resolving ambiguities results in abstractions that add amples include graphs, linear orderings, partial orderings, expressiveness. For example, ambiguity 1 above is ad- groups, and vector spaces [9, 11]. Once we were satisfied that the class of structures reflected our intuitions, we wrote axioms and definitions in first order logic to formal- ize the original intuitions, guided by the mathematical representation [10]. Finally, we proved that the struc- tures were isomorphic to the extensions of the predicates in the logical language [11]. This process of using well- understood mathematical structures in the translation of intuitions to logic validates that the language does what we expect. Fig. 1. Example UML 2 flow model
Recommend
More recommend
