Logical specification of processes

Martina Číhalová, Marie Duží, Marek Menšík

VSB-Technical University Ostrava, 17. listopadu 15, 708 33 Ostrava, Czech Republic m.tina.cihal@gmail.com, marie.duzi@vsb.cz, mensikm@gmail.com

Abstract. In the last decades we got used to software applications (or computers, if you like) being everywhere and working for us. Yet sometimes they fail to work as desired. The current situation is often characterized as the second software crisis. There are many alleged causes of this state. They include, inter alia, web net overload, loss of data, inconsistency of data, intrusions by hackers, etc. etc. Yet in our opinion, the main problem is an old one. It consists in an insufficient specification of the procedures to be executed. We have been dealing with this problem since the beginning of computer era. Though there are many specification methods and languages, the problem remains very much a live issue and so far no satisfactory solution has been found. Our stance is that a declarative logical specification is needed. A serious candidate for such a high-quality declarative specification is a higher-order logic equipped with a procedural semantics. The goal of our contribution is to describe a specification method using Transparent Intensional Logic (TIL). TIL is a hyperintensional, typed, partial lambda-calculus. Hyperintensional, because the meaning of TIL-terms are not the functions/mappings themselves; rather, they are procedures producing functions as their products. Proper typing makes it possible to define inputs and outputs of a procedure. Finally, we must take into account partiality and the possibility of a failure to produce a product. A procedure may fail to produce a correct product for one of two reasons. Either the mapping the procedure produces is undefined at the argument(s) serving as point(s) of evaluation, or the procedure is ill- or under-specified, in which case the empirical execution process has undesirable results. This paper investigates, in a logically rigorous manner, how a detailed specification can prevent these problems.

Keywords: program specification, procedural semantics, types, partiality, TIL

"Whenever you see a ratio of 25:75 analysts:programmers you will find systems analysis being performed at

the wrong time and by the wrong person." (Bryce's Law: [2])

1 Introduction

Current situation in computer applications is often characterized as the second software crisis. There is much evidence of this state. To adduce just two examples, in the Czech Republic a new system of ‘automatic register of vehicles’ was introduced last year, and it completely failed. Many new car owners had to queue for hours to register their cars, and many times they failed to do so. The second example is this. The Grant Agency of the Czech Republic developed a new project proposal application, due to which the deadline for project applications had to be postponed for three months. The application is still partly malfunctioning.

There are many alleged causes of this state. They include, inter alia, web net overload, loss of data, inconsistency of data, intrusions by hackers, etc. etc. Yet in our opinion, the main problem is an old one. It consists in an insufficient specification of the procedures to be executed. We have been dealing with this problem since the beginning of the computer era. Though there are many specification methods and languages, the problem remains very much a live issue and so far no satisfactory solution has been found. The problem stems from misunderstandings in mutual communication of the sides involved in the development of a software application. The three sides are: end-users, analysts and programmers. Analysts are the crucial part of this communication. They must present to the end-users the solutions to their problems in a manner comprehensible to them. This is, no doubt, in the form of natural-language specification. However, natural language has proven to be too vague, verbose and ambiguous to rely on for the necessary precision, and thus the programmers often do not know precisely what to do. Either the analysts present an application specification in natural language, or they almost write a program. Both are no good.

Says Tim Bryce ([2]): “It is not uncommon for programmers to receive specs in obscure ways, such as a memo from an end-user (the back of a cocktail napkin is my personal favorite). Rarely are specifications given in a consistent manner that can be evaluated for completeness.”

The purpose of a specification requires that all parties have complete confidence in the properties of the results it warrants. The focus of a specification should be on what is achieved, not how it is achieved. Precise and formally defined conventions for writing specifications are a much more recent invention than programming languages. The need to be fully precise about results before beginning the programming process has led to reliance on logically based specifications.

Hence declarative specifications should be used. In our opinion, a serious candidate for such a high-quality declarative specification is a higher-order logic equipped with a procedural semantics. The goal of our contribution is to describe a specification method using Transparent Intensional Logic (TIL). TIL is a hyperintensional, typed, partial lambda-calculus. Hyperintensional, because the meanings of TIL terms are not the functions/mappings themselves; rather, they are procedures producing functions or functional values as their products. Proper typing makes it possible to define the input and output of a procedure. Finally, we must take into account the fact that some procedures can fail to produce a product. A procedure may fail to produce a correct product for one of two reasons. Either the mapping the procedure produces is undefined at the argument(s) serving as point(s) of evaluation,

or the procedure is ill- or under-specified, in which case the empirical execution process has undesirable results. This paper investigates, in a logically rigorous manner, how a procedural semantics can classify malfunctioning procedures, and how a detailed specification can prevent these problems.

The paper is organized as follows. Section 2 provides a brief overview of existing process specification tools and languages. Section 3 is a summary of the core of Transparent Intensional Logic (TIL) that we need in this paper. Finally, in Section 4 we introduce TIL specification that is accompanied by a practical example.

2 A brief overview of process specification tools and languages

Here we overview five standard specification methods and languages, namely WMC (Workflow Management Coalition), BPM (Business Process Model), VPML (Visual Processing Modelling Language), PSL (Process Specification Language) and RUP (Rational Unified Process).

2.1 Workflow Management Coalition

Here we draw on material from the document Workflow management coalition terminology and glossary, see [12]. The basic concepts defined by WMC are Workflow, Process and Activity.

Figure 1 summarizes basic relationships between important ontological entities.

Figure 1: Basic concepts of process ontology.

Workflow is the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules.

Business Process is a set of one or more linked procedures or activities, which collectively realize a business objective or policy goal, normally within the context of an organizational structure defining functional roles and relationships.

The process definition consists of a network of activities and their relationships, criteria to indicate the start and termination of the process, and information about the individual activities, such as participants, associated IT applications and data, etc. The process definition may contain references to sub-processes, separately defined, which make up part of the overall process definition. The process definition may make reference to a separate Organisation or Resource Model to enable participants to be indirectly defined, for example by reference to attributes such as role or organisational position.

Activity is a description of a piece of work that forms one logical step within a process. An activity may be a manual activity, which does not support computer automation, or a workflow (automated) activity. A workflow activity requires human and/or machine resources(s) to support process execution; where human resource is required an activity is allocated to workflow participants.

Each of the process ontology has to distinguish between the process and its concrete execution, i.e. process instance. Process instance covers activity instances.

Each process instance represents one individual enactment of the process, using its own process instance data, and which is (normally) capable of independent control and audit as it progresses towards completion or termination.

Activity instance is the representation of an activity within a (single) enactment of a process, i.e. within a process instance. Each activity instance represents a single invocation of an activity, relates to exactly one process instance and uses the process instance data associated with the process instance. Several activity instances may be associated with one process instance, where parallel activities exist within the process, but one activity instance cannot be associated with more than one process instance.

Activity instances may be executed in parallel or in sequence so that - one activity instance can split into two or more threads, which are

executed in parallel within the workflow (AND-Split), - two or more parallel executing activities can converge into a single

common thread of control (AND-Join), - a single thread of control can make a decision upon which branch to take

when encountered with multiple alternative workflow branches (OR-Split),

- two or more alternative activity workflow branches re-converge to a single common activity as the next step within the workflow (OR-Join),

- and finally, a workflow activity can cycle involving the repetitive execution of one (or more) workflow activity until a condition is met.

Many process specification languages refer to workflow participants. Workflow participant is a resource which performs the work represented by a

workflow activity instance. This work is normally manifested as one or more work items assigned to the workflow participant via the work-list. Synonyms are, e.g., actor, user, role player, work performer. The term workflow participant is normally

applied to a human resource, but it could conceptually include machine based resources such as an intelligent agent. A workflow participant may be identified directly within the business process definition, or (more normally) is identified by reference within the process definition to a role or organisational entity, which can be filled by one or more of the resources available to the workflow system to operate in that role during process enactment. Participants can be of four types: human, (machine) resource, role, or organisational_unit.

Below are important definitions concerning a process structure. Pre-condition is a logical expression which may be evaluated by a workflow

engine to decide whether a process instance or activity within a process instance may be started.

Post-condition is a logical expression which may be evaluated by a workflow engine to decide whether a process instance or activity within a process instance is completed.

A lot of process models associate the concept of process with the concept of activity. For instance Activity diagrams are pattern on the concept of activity. They are the specialization of Unified Modeling Language (UML) state diagrams and are based on the Petri net semantics (see [11]). Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency. In UML, activity diagrams can be used to describe the business and operational step-by-step workflows of components in a system. Activity diagrams elements are for instance: Activity, Structured activity, Action, Object, Datastore, Decision etc.

An Activity organizes and specifies the participation of subordinate behaviors, such as sub-Activities or Actions, to reflect the control and data flow of a process. An Action element describes a basic process or transformation that occurs within a system. It is the basic functional unit within an Activity diagram. Actions can be thought of as children of Activities. Both represent processes, but Activities can contain multiple steps or decomposable processes, each of which can be embodied in an Action. An Action cannot be further broken down or decomposed. An Action can be further defined with pre-condition and post-condition notes, and certain properties can be graphically depicted on the Action.

Activity diagrams are constructed from a limited number of shapes, connected with arrows. The most important shape types: activities, decisions, start (split) or end (join) of concurrent activities, start (initial state) of the workflow, end (final state). Arrows run from the start towards the end and represent the order in which activities run.1

2.2 Business Process Model

Business Process Model and Notation (BPMN, see [1]) is the graphical tool for the process specification. It is based on the similar principles as activity diagrams.

Activity describes the kind of work which must be done. Task represents a single unit of work that is not or cannot be broken down to a

further level of business process detail without diagramming the steps in a procedure

1 For details see

http://www.sparxsystems.com/enterprise_architect_user_guide/modeling_languages/activitydiagram.html

(which is not the purpose of BPMN). Compare with Activity diagrams, where a single unit of work represents the concept of Action.

Modelling in BPMN is by simple diagrams with a small set of graphical elements. It should be easy for business users as well as developers to understand the flow and the process. The four basic categories of elements are as follows: Flow Objects, Connecting Objects, Swimlanes and Artifact.

Flow Objects are Events, Activities and Gateways. Events denote something that happens (compared with an activity, which is

something that is done). Events are also classified as Catching (for example, if catching an incoming message starts a process) or Throwing (such as throwing a completion message when a process ends).

Activities describe the kind of work that must be done. Gateways determine forking and merging of paths, depending on the conditions

expressed, for instance Exclusive, Inclusive, Parallel etc. Flow objects are connected to each other using Connecting objects, which are of

three types: sequences, messages, and associations. Sequence Flow shows in which order the activities are performed. Message Flow tells us what messages flow across organizational boundaries (i.e.,

between pools). A message flow can never be used to connect activities or events within the same pool.

Association is used to associate an Artifact or text to a Flow Object, and can indicate some directionality using an open arrowhead (toward the artifact to represent a result, from the artifact to represent an input, and both to indicate it is read and updated).

Swimlanes are a visual mechanism for organizing and categorising activities, based on cross functional flowcharting, and in BPMN it consists of two types:

Pool represents major participants in a process, typically separating different organisations. A pool contains one or more lanes (like a real swimming pool). A pool can be open (i.e., showing internal detail) when it is depicted as a large rectangle showing one or more lanes, or collapsed (i.e., hiding internal detail) when it is depicted as an empty rectangle stretching the width or height of the diagram

Lane is used to organise and categorise activities within a pool according to function or role, and depicted as a rectangle stretching the width or height of the pool. A lane contains the flow objects, connecting objects and artifacts.

Artifacts allow developers to bring some more information into the model/diagram. In this way the model/diagram becomes more readable. There are three pre-defined Artifacts and they are data objects, group, annotation.

Data Objects show the reader which data is required or produced in an activity. Group is used to group different activities but does not affect the flow in the

diagram. Annotation is used to give the reader of the model/diagram an understandable

impression.

2.3 Visual Process Modelling Language

Visual Process Modeling Language (VPML) is another graphic language that supports a special process definition. Within VPML, a process is defined as a set of partially ordered steps towards meeting a goal. The components of a process diagram are activities, products, resources, and the connections between them. Connections are used to establish relationships between constructs, pass product information between activities, and coordinate scheduling of activities. Activities represent work that is performed in a process and is the central focus of VPML.

The process model built in VPML can be simulated. It is theoretically proved that VPML is equivalent Petri-Net ([11]).

Now we introduce the semantics of VPML (see [9]). VPML is a 7-tuple {P, A, R, Control, Support, Input, Output} where

P = {Product1, Product2, …, Productj} is a set of products; A = {a1, a2, …, am} is a set of Activities; R = {r1, r2, …, rk} is a set of resources; Control is a set of relations of controlling; Support is a set of resources supporting activities; Support A R; Input is a set of relations between activities and input products; Input A P; Output the relations of activities and output products; Output A P.

Based on the above definition, some more objects are defined. State(i): i (P R), represents the states of an element i. It is an enumeration type: enum={able,disabled} which means that states can be either able or disabled. Status(a): where a A, represents the status of an activity a. In VPML activity has two statuses, START and END. Source(c): where c Input Output, is a set of source objects related by c. Target(c): where c Input Output, is a set of target object related by c. Prod_Source(a): where a A, represents the set of input products related with activity a. Prod_Target(a): where a A, is the set of all output products related to activity a Resource(a): where a A, is the set of all resources related to activity a. Role(a): where a A, is the set of all roles related to activity a. O(a) is the set of constraints.

2.4 Process Specification Language

The Process Specification Language (PSL) has been designed to facilitate correct and complete exchange of process information among manufacturing systems. These applications support process scheduling, modelling, planning, production planning, simulation, management, workflow and reengineering. PSL ontology is a formal set of axioms and theories as in FOL. There are 17 axioms defining this theory. Axiom 1 through 8 define relations and functions concerning temporal execution of actions. The remaining axioms specify objects and activities.

For instance, the first two temporal axioms are as follows:

Axiom 1 The ‘before relation’ is defined only on the set of times. (forall (?t1 ?t2) (if (before ?t1 ?t2) (and (timepoint ?t1) (timepoint ?t2))))

Axiom 2 The before relation is a total ordering. (forall (?t1 ?t2) (if (and (timepoint ?t1) (timepoint ?t2)) (or (= ?t1 ?t2) (before ?t1 ?t2) (before ?t2 ?t1)))) The object specification axioms are, for instance these: Axiom 9 Everything is either an activity, activity occurrence, timepoint, or object. (forall (?x) (or (activity ?x) (activity_occurrence ?x) (timepoint ?x) (object ?x))) Axiom 13 An activity occurrence is associated with a unique activity.

(forall (?occ ?a1 ?a2) (if (and (occurrence_of ?occ ?a1) (occurrence_of ?occ ?a2)) (= ?a1 ?a2))) More details and the complete set of axioms can be found at

http://www.mel.nist.gov/psl/psl-ontology/psl_core.html

2.5 Rational Unified Process

The Rational Unified Process (RUP) provides a disciplined approach to assigning tasks and responsibilities within a process development. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget. RUP is a guide how to effectively use the Unified Modeling Language (UML). The Rational Unified Process is supported by tools which automate large parts of the process. They are used to create and maintain the various artifacts—models in particular—of the software engineering process: visual modeling, programming, testing, etc.

The RUP ontology describes following process elements: roles, artifacts and activities. The backbone of any software engineering process is the description who (roles) does what (artifacts) and how (activities) to do it.

A role is a grouping mechanism that defines a set of responsibilities in terms of activities that this role can perform. A role may be performed by an individual or a set of individuals working together as a team. An individual may also assume multiple roles. Sometimes a role may relate directly to an individual’s job title, but it does not have to.

An activity is a unit of work a role may be asked to perform. An activity is described by its steps and input and output artifacts. The goal of an activity is to create or update one or more artifacts.

Artifacts are the products of a software project. A given artifact can serve as both input to and output from a set of activities. To be able better describe an artifact using a well-defined process language, the RUP meta-model defines a set of artifact types, each identified by a specific stereotype. These types are e.g.: document, data store, plan document, etc. The products can be in various states, e.g. submitted, verified, etc.

2.6 Summary

In the previous paragraphs we briefly introduced some of the existing tools and methods for process specification. They are no doubt useful. However, they mostly cover only the upper levels of process development. A detailed specification of the algorithms that particular activity steps should realize is missing here. For instance, in RUP methodology the software process ontology design is specified in three levels of abstraction. They are process itself, activities (or tasks) of the process and steps of activities. Table 1 is the summary of basic ontological terms used in RUP.

Table 1. Mapping process elements

Term Description Level Process Designed Process itself 0 Activities/Tasks Simplest activities of a process 1 Artefacts One of many kinds of tangible by products

produced during the development of software 1

Roles A definition of the behaviour and responsibilities of an individual

1

Steps Steps are simplest items of Activities. 2

All other terms used in RUP Software Process documentation are specializations of

the base terms introduced in Table 1. However, whereas the elements of level 0 and 1 are usually well-defined, the specification of particular steps is missing.

Moreover, the terminology and methodology is not unified. For instance, the concept of state in RUP concerns a product. On the other hand, in “Workflow management coalition terminology and glossary” it concerns a process or activity according to the following definitions:

Process state is a representation of the internal condition defining the status of a process instance at a particular point in time. Most workflow management systems maintain such status information as part of their workflow data.

Activity state is a representation of the internal conditions defining the status of an activity instance at a particular point in time. Most workflow management systems maintain such status information as part of their workflow data.

For these reasons we are going to propose a detailed declarative logical specification of an algorithm. Our specification is based on Transparent Intensional Logic (TIL) with its procedural semantics that is our overarching background theory.

3 Foundations of TIL

In this section we introduce the fundamental notions of TIL. Since this theory has been presented in the EJC conference many times,2 we just provide a brief summary here.

Tichý’s TIL was developed simultaneously with Montague’s Intensional Logic.3 The technical tools of TIL will be familiar from Montague’s intensional logic, with two important exceptions.

One exception is that we -bind separate variables w1,…,wn ranging over possible worlds and t1,…,tn ranging over times. This dual binding is tantamount to explicit intensionalization and temporalization. The other exception is that functional application is the logic both of extensionalization of intensions (functions from possible worlds) and of predication. Application is symbolized by square brackets, ‘…’. Intensions are extensionalized by applying them to worlds and times, as in [[Intension w] t], abbreviated by subscripted terms for world and time variables: Intensionwt is the extension of the generic intension Intension at w, t. Thus, for instance, the extensionalization of a property yields a set, and the extensionalization of a proposition yields a truth-value (or no value at all). The predication of the property F of John is, logically, a matter of applying the extensionalized property F (i.e. the characteristic function of a set) to John in order to obtain a truth-value, according as John is a member of the set of Fs at w, t.4

Formally, a property of individuals is a function from worlds to a function from times to a partial function from individuals to truth-values (characteristic functions of sets). A proposition is a function from worlds to a partial function from times to truth-values. An attribute like the wife_of is a function from worlds to a function from times to a partial function from an individual to an individual: relative to w, t, given one individual x/John, the attribute yields either the individual that is the wife of x/John or no individual, in case x/John is single or polygamous. An individual role or office like John’s wife (assuming a cultural background of monogamy) is a function from worlds to a partial function from times to individuals: relative to w, t, the role yields either the individual that is John’s wife at w, t or no individual, in case John is single or polygamous. Finally, an n-place relation-in-intension is a function from worlds to a function from times to a partial function from n-tuples to truth-values.

A main feature of the -calculus is its ability to systematically distinguish between functions and functional values. An additional feature of TIL is its ability to systematically distinguish between functions and modes of presentation of functions and modes of presentation of functional values. The TIL operation known as Closure is the very procedure of presenting or forming or obtaining or constructing a function; the TIL operation known as Composition is the very procedure of constructing the value (if any) of a function at an argument. Compositions and Closures are both multiple-step procedures, or constructions, that operate on input

2 See, for instance, [3], [6]. 3 For a critique of Montague’s intensional logic, see [5], §2.4.3. 4 For details, see [5], §2.4.2 and [8].

provided by two one-step constructions, which figure as sub-procedures of Compositions and Closures, namely variables and so-called Trivializations. Variables construct the respective values that an assignment function has accorded to them. The linguistic counterpart of a Trivialization is a constant term always picking out the same object. An analogy from programming languages might be helpful. The Trivialization of an object X (whatever X may be) and its use are comparable to a fixed pointer to X and the dereference of the pointer. In order to operate on X, X needs to be grabbed, or ‘called’, first. Trivialization is one such one-step grabbing mechanism. Similarly, in order to talk about China (in non-demonstrative and non-indexical English discourse), we need to name China, most simply by using the constant ‘China’. Trivialization is important in what follows, because in order to substitute one sub-construction for another inside a construction it is crucial to be able to grab those three individual constructions.

The logical core of TIL is its notion of construction and its type hierarchy, which divides into a ramified type theory and a simple type theory. The ramified type hierarchy organizes all higher-order objects, which are all constructions, as well as all functions with domain or range in constructions. The simple type hierarchy organizes first-order objects, which are non-constructions like extensions (individuals, numbers, sets, etc.), possible-world intensions (functions from possible worlds) and their arguments and values, including those values whose values are themselves intensions (like China’s most adorable property). The relevant definitions are as follows.

Definition 1 (types of order 1) Let B be a base, where a base is a collection of pair-wise disjoint, non-empty sets. Then: (i) Every member of B is an elementary type of order 1 over B. (ii) Let α, β1, ..., βm (m > 0) be types of order 1 over B. Then the collection

(α β1 ... βm) of all m-ary partial mappings from β1 ... βm into α is a functional type of order 1 over B.

(iii) Nothing is a type of order 1 over B unless it so follows from (i) and (ii).

Definition 2 (construction) (i) The variable x is a construction that constructs an object O of the respective

type dependently on a valuation v: x v-constructs O. (ii) Trivialization: Where X is an object whatsoever (an extension, an intension or a

construction), 0X is the construction Trivialization. It constructs X without any change.

(iii) The Composition [X Y1…Ym] is the following construction. If X v-constructs a function f of type (α β1…βm), and Y1, …, Ym v-construct entities B1, …, Bm of types β1, …, βm, respectively, then the Composition [X Y1…Ym] v-constructs the value (an entity, if any, of type α) of f on the tuple argument B1, …, Bm. Otherwise the Composition [X Y1…Ym] does not v-construct anything and so is v-improper.

(iv) The Closure [λx1…xm Y] is the following construction. Let x1, …, xm be pair-wise distinct variables v-constructing entities of types β1, …, βm and Y a construction v-constructing an α-entity. Then [λx1 … xm Y] is the construction λ-Closure (or Closure). It v-constructs the following function f of the type (αβ1…βm). Let v(B1/x1,…,Bm/xm) be a valuation identical with v at least up to assigning objects B1/β1, …, Bm/βm to variables x1, …, xm. If Y is

v(B1/x1,…,Bm/xm)-improper (see iii), then f is undefined on B1, …, Bm. Otherwise the value of f on B1, …, Bm is the α-entity v(B1/x1,…,Bm/xm)-constructed by Y.

(v) The Single Execution 1X is the construction that either v-constructs the entity v-constructed by X or, if X is not itself a construction or X is v-improper, 1X is v-improper.

(vi) The Double Execution 2X is the following construction. Where X is any entity, the Double Execution 2X is v-improper (yielding nothing relative to v) if X is not itself a construction, or if X does not v-construct a construction, or if X v-constructs a v-improper construction. Otherwise, let X v-construct a construction Y and Y v-construct an entity Z: then 2X v-constructs Z.

(vii) Nothing is a construction, unless it so follows from (i) through (vi). Remark. For the purposes of natural-language analysis, we are currently assuming

the following base of ground types, which are parts of the ontological commitments of TIL:

ο: the set of truth-values {T, F}; ι: the set of individuals (constant universe of discourse); τ: the set of real numbers (doubling as temporal continuum); ω: the set of logically possible worlds (logical space).

However, TIL is an open system and the choice of a base depends on the area of interest. In this paper we need another basic type, namely the type of natural numbers.

The definition of the ramified hierarchy of types decomposes into three parts. Firstly, simple types of order 1, which were already defined by Definition 1. Secondly, constructions of order n, and thirdly, types of order n + 1.

Definition 3 (ramified hierarchy of types) T1 (types of order 1). See Definition 1. Cn (constructions of order n) i) Let x be a variable ranging over a type of order n. Then x is a construction of

order n over B. ii) Let X be a member of a type of order n. Then 0X, 1X, 2X are constructions of

order n over B. iii) Let X, X1,..., Xm (m > 0) be constructions of order n over B. Then [X X1... Xm]

is a construction of order n over B. iv) Let x1,...xm, X (m > 0) be constructions of order n over B. Then [x1...xm X] is a

construction of order n over B. v) Nothing is a construction of order n over B unless it so follows from Cn (i)-

(iv). Tn+1 (types of order n + 1) Let n be the collection of all constructions of order n

over B. Then i) n and every type of order n are types of order n + 1. ii) If m > 0 and , 1,...,m are types of order n + 1 over B, then ( 1 ... m)

(see T1 ii)) is a type of order n + 1 over B. iii) Nothing is a type of order n + 1 over B unless it so follows from (i) and (ii).

Empirical languages incorporate an element of contingency that non-empirical ones lack. Empirical expressions denote empirical conditions that may, or may not, be satisfied at some empirical index of evaluation. Non-empirical languages have no need for an additional category of expressions for empirical conditions. We model these empirical conditions as possible-world intensions. Intensions are entities of type (): mappings from possible worlds to an arbitrary type . The type is frequently the type of a chronology of -objects, i.e. a mapping of type (). Thus -intensions are frequently functions of type (()), abbreviated as ‘’. We shall typically say that an index of evaluation is a world/time pair w, t. Extensional entities are entities of a type where () for any type .

For instance, let 0Happy construct the property of being happy of type (), and let 0Pope construct the office of Pope of type . Then wt [0Happywt

0Popewt] is a Closure constructing the possible-world proposition that returns T at all and only those w, t-pairs whose incumbent of the office of Pope and whose set of happy individuals are such that the former is an element of the latter. That is, the Closure wt [0Happywt

0Popewt] constructs this empirical truth-condition P: w, t P =df Popewt Happywt. Whether the pair consisting of the actual world and the present moment is a member of P is beyond logic and semantics, and must be established empirically.

In this paper we do not need PWS-intensions, because we are going to deal only with the specification of algorithms realising analytical functions, i.e. extensions. However, when specifying system ontology, we view such an ontology as the logic of intensions. For details, see [6].

Logical objects like truth-functions and quantifiers are extensional: (conjunction), (disjunction) and (implication) are of type (), and (negation) of type (). Quantifiers , are type-theoretically polymorphous total functions of type (()), for an arbitrary type , defined as follows. The universal quantifier is a function that associates a class A of -elements with T if A contains all elements of the type , otherwise with F. The existential quantifier is a function that associates a class A of -elements with T if A is a non-empty class, otherwise with F. Below all type indications will be provided outside the formulae in order not to clutter the notation. Furthermore, ‘X/’ means that an object X is (a member) of type . ‘X v ’ means that the type of the object v-constructed by X is .

We invariably furnish expressions with their procedural structural meanings, which are explicated as TIL constructions. The analysis of an expression thus consists in discovering the logical construction encoded by the expression. TIL method of analysis consists of three steps:5

1) Type-theoretical analysis, i.e., assigning types to the objects that receive mention in the analysed sentence.

2) Synthesis, i.e., combining the constructions of the objects ad (1) in order to construct the proposition of type denoted by the whole sentence.

3) Type-Theoretical checking.

5 For details see, e.g., [5].

To illustrate the method let us define the set of prime numbers. When defining particular objects, we apply the method of a construction refinement. First, we can start with the primitive concept of primes, that is the Trivialization 0Prime, where Prime/(). This Trivialization does construct the set of primes, but does so in a non-informatic and non-executable manner. Hence we need an ontological definition of this set. One of such definitions is this: ‘the set of natural numbers with exactly two factors’. Our task is to assign TIL construction to this definition. To this end we apply our method of analysis.

Ad (1) Number_of/(ν(ον)): the number of elements of a finite set of natural numbers; Divides/(ονν): the relation of being divisible without a remainder.

Ad (2) The set of factors of a given number x is constructed by the Closure

y [0Divides y x]; x, y

In order that a number x be a prime, the cardinality of this set must be two:

[[0Number_of y [0Divides y x]] = 02]

Finally, we want to construct the whole set of such numbers. Hence we use the -Closure:

x [[0Number_of y [0Divides y x]] = 02].

This construction is the literal analysis of the term ‘the set of numbers such that the number of their factors is 2’.

Ad (3) Type-Theoretical checking:

x [0= [0Number_of y [0Divides y x]] 02]

(ονν) ν ν

(ν(ον)) (ν)

(ονν) ν ν

(ν)

So much for the semantic schema of TIL logic. Now we are going to apply this formal apparatus to specify processes.

4 TIL Specification of processes

In order to specify processes we first define the frequently used If-then-else function. Here is how. The instruction encoded by “If P ( ) then C ( α), else D ( α)” behaves as follows:

a) If P v-constructs T then execute C (and return the result of type , provided C is not v-improper).

b) If P v-constructs F then execute D (and return the result of type , provided D is not v-improper).

c) If P is v-improper then fail to produce the result.

Hence, if-then-else is seen to be a function of type (*n*n) that operates on constructions, and its definition decomposes into two phases.

First, select a construction to be executed on the basis of a specific condition P. The choice between C and D comes down to this Composition:

[0The_only c [[P [c = 0C]] [P [c = 0D]]]]

Types: P v v-constructs the condition of the choice between the execution of C or D, C/n, D/n; c v n; The_only/(n(n)): the singularizer function that associates a singleton set of constructions with the only construction that is an element of this singleton, and is otherwise (i.e., if the set is empty or many-valued) undefined. If P v-constructs T then the variable c v-constructs the construction C, and if P v-constructs F then the variable c v-constructs the construction D. In either case, the set constructed by

c [[P [c = 0C]] [P [c = 0D]]]

is a singleton and the singularizer The_only returns as its value either the construction C or the construction D. Note that in this phase constructions C and D are not constituents to be executed; rather they are mere objects to be supplied by the variable c. This is to say that without hyperintensional approach we would not be able to define the function If-then-else in the strictly compositional way.

Second, the selected construction is executed; therefore, Double Execution must be applied:

2[0The_only c [[P [c = 0C]] [P [c = 0D]]]] Hence the refinement definition of this function is this:

0If-then-else = 2[0The_only c [[P [c = 0C]] [P [c = 0D]]]]

Yet in the interest of comprehensibility instead of [0If-then-else P C D] we will use the common notation If P then C else D.

Since we aim at a declarative logical specification, we do not need imperative constructs like while, do, etc. Now we are going to illustrate the application of TIL to a process specification by way of an example.

4.1 Case study

As an example we now specify the process of ball-bearing production. First, the ontology of the process. In the interest of better readability, in particular rules we use the notation ‘Input Output’.

Ontology rules are of a uniform form:

ProcessElement/(who (role), Input (artefacts) output (artefact))

This rule specifies who is responsible for a given Process element (process, activity or steps) and what input or output artefacts flow in and out. We can say that the set of these rules represents a formal functional view of a process.

As mentioned above, process ontology design defines three levels of abstraction: level 0 – the specification of a process level 1 – activities for individual process are specified level 2 – steps for elementary activities are described Example of the defined rules follows:

Level 0 (Process: Ball-bearing) Ball-bearing / (Production-manager, ((IR, OR, b), N) Ball-bearings)

Types: IR/(): the set of diameters of inner rings; OR/(): diameters of outer rings; b/: calibre; N/: the number of suitable ball bearings; Ball-bearing/.

Level 1 (Process: Ball-bearing, Activities: Assembling) Find triples / (_, b Triples) Select N triples / (_, Triples Triples)

Types: Triples/(()): a set of triples (x,y,b) for the given calibre b, where x IR: the inner ring diameter; y OR: the outer ring diameter.

Level 2 (Process: Ball-bearing, Activities: Assembling, Steps)

In the level 2 we now wish to specify the algorithm consisting of particular steps, because this specification is usually missing in standard methods.

First we describe the algorithm in prose. The task is this. Assemble N ball bearings with the parameters IR (the set of diameters of inner rings), OR (the set of diameters of outer rings) and a given calibre b. Each ball bearing must meet the inequality

42 x + y + 2b + Rp 44

where x IR, y OR, b is the prescribed calibre and Rp/ is the prescribed radial clearance. Since there are more solutions satisfying the above inequality, the goal is to find an optimal solution. Hence we deal with a combinatorial optimisation task. The optimal solution is the one that contains the least number of triple multi-classes with the same values of x and y.

The proposed algorithm can be described like this. 1) find the list L of all triples (x, y, b) such that 42 x + y + 2b + Rp 44 2) classify triples to the multi-classes C L such that each class contains triples

with the same values of x and y 3) find the multi-class D with the greatest number M of elements 4) add D to the Result_Set 5) If N – M is greater than zero then construct new sets IR1 and OR1: IR1 = IR /

{x} and OR1 = OR / {y}, where x and y are the representatives of the class D, and repeat the steps (1) through (4), else the Result_Set is the optimal result.

Remarks. We use the term multi-class or multi-classing for classifying instances of triples (x, y, b) into more than one class. Thus the list L can contain, for instance, these triples:

(12,19,2)1; (12,9,2)2; (13,17,2)3; (13,17,2)4; (13,17,2)5; (13,17,2)6; (13,17,2)7; (16,14,2)8; (16,14,2)9; (16,14,2)10. In the first round of the algorithm the multi-class D is the second one and it

contains five instances indexed from 3 to 7.

Though it is a well-known fact that recursive definitions and lambda definitions are equivalent, for the sake of simplicity and in the interest of better comprehensibility we now use a recursive specification of the whole algorithm. It also complies with a common way of specification as it is applied for instance in HOL or Isabelle which are the proof systems for higher-order logics.6

Laying out the recursive specification is easy while lambda specification requires a fair amount of footwork. Once this is in place, however, all that remains is filling in the nitty-gritty details of lambda specification. The devil is in the detail, as ever, and rewriting recursive specification into a pure lambda form is far from being technically trivial. But it is feasible. Thus we do not want to flood this paper with too many technical details.

Other notational variations from TIL notation are these. We put particular variables bound by one and the same lambda Closure into parentheses in order to make constructions easier to read. Thus, for instance, instead of

‘ ir or n x y b […]’ we write ‘(ir or) n (x y b) […]’. When writing mathematical constructions we use a common mathematical

notation. Thus instead of ‘[[0 042 [0+ [0+ [0+ x y] [0 02 0b]] 0Rp] [0 [0+ [0+ [0+ x y] [0 02 0b]] 0Rp] 044]]’ we write simply ‘[42 x + y + 2b + Rp 44]’.

Here is the TIL specification of our algorithm: As always, first types; Inputs: IR, OR/(): the sets of diameters of inner and outer rings; b/: the prescribed calibre; N/: the number of ball bearings to be assembled ( is the type of natural numbers). Output: Result_Set/((())): the optimal list of indexed triples (x, y, b). The data structure List can be introduced into the TIL-language specification, of course. Here it suffices to say that List results as a mapping from the type of natural numbers to the set of triples of type (). In other words, List is a set of indexed triples.

Now we first refine the primitive steps as described above. 0Find_List = (ir or) [list xy [[ir x] [or y] [42 x + y + 2b + Rp 44] [list = [0Map (x, y, b)]]]]

Types: ir, or (): the sets of inner and outer rings; x, y ; list (()); Map/((())()): the function that maps triples of natural numbers to indexed triples (i.e. index function);

6 See [7] and [10].

0Classes = c [c = n (x y b) [[[0Find_List ir or] n] [x1 y1 [x=x1 y=y1]]] Types: c ((())): the set of indexed triples with the same proportions; n : the index of a given triple.

0Greatest = [0Sing d [[0Classes d] c [[Classes c] [[0Card d] [0Card c]]]]] Types: Sing/((()))(((()))): the singulariser, the only class (from Classes) with the greatest number of elements; Card(((()))): the function that assigns to a given finite set of indexed triples the number of its elements; d ((())).

0Remove = xr x xr1 [[xr xr1] xr1 ≠ x]] – this function assigns to a given set xr of inner/outer rings and a given diameter x as a result value the new set xr1 of diameters that does not contain the given x. This function is used in every algorithm cycle in order to remove the used diameters from the input sets IR and OR.

0Result_Set = rs [greatest rs] – this function realizes including the current greatest class to the resulting set of classes. The set-theoretical operation union of two -sets is of a type (()()()), and it is defined as follows: s1s2 x [[s1 x] [s2 x]]; s1, s2 (); x .

0Test = [(ir or) res_set d [d = [0Greatest [0Classes [0Find_List 0IR 0OR]]] (x y b) n [d ((x y b) n)] If [[N – [0Card d]] > 00]

then [ [ir1 = [0Remove ir x]] [or1 = [0Remove or y]] [res_set1 = [0Result_Set d res_set]] [0Test (ir1 or1) res_set1] % recursive cycling

] else res_set = [0Result_Set d res_set1]

]

res_set = 0 % is an empty set of indexed triples [0Test (0IR 0OR) res_set]

4.2 Concluding remarks.

By way of a practical example we illustrated our logical specification of an algorithm in TIL. The upside of our method is its preciseness and compositionality. We gradually refine particular specification in the top-down way. The degree of refinement can go down as much as needed.

Hence such a fine-grained declarative specification can serve not only as an informative work assignment for a programmer, but also as an input for the verification of an algorithm. Further research will focus on an automatic generation of a program code from such a specification. Though this is still a work in progress, we have implemented in particular the fundamental computational rule of -reduction. To

this end we specified and implemented the substitution method of -reduction ‘by value’ that preserves equivalency even in the logic of partial functions such as TIL, and does not yield a lost of analytic information.7

References.

1. Allweyer, T. (2010): BPMN 2.0 – Introduction to the Standard for Business Process Modeling. BoD. ISBN 978-3-8391-4985-0.

2. Bryce, T. (2005): ‘What is a good program specification?’. M. Bryce & Associates, Palm Harbor, Florida: MBA Press.

3. Duží M., Číhalová M., Ciprich N., Menšík M. (2010): Agents’ reasoning using TIL-Script and Prolog. In Information Modelling and Knowledge Bases XXI, T. Weltzer Družovec, H. Jaakkola, Y. Kiyoki, T. Tokuda, N. Yoshida (eds.), Amsterdam: IOS Press, 135-154.

4. Duží, M., Jespersen, B. (2013): Procedural isomorphism, analytic information, and -conversion by value. Logic Journal of the IGPL, Oxford, vol. 21, pp. 291-308, doi: 10.1093/jigpal/jzs044.

5. Duží, M., Jespersen, B. and P. Materna (2010): Procedural Semantics for Hyperintensional Logic: Foundations and Applications of Transparent Intensional Logic. Logic, Epistemology, and the Unity of Science, vol. 17, Dordrecht et al.: Springer.

6. Duží, M., Číhalová, M., Menšík, M. (2011): Ontology as a logic of intensions. In: Information modelling and Knowledge Base XXII, Heimbürger A., Kiyoki Y., Tokuda T., Jaakkola H., Yoshida N. (eds.), Amsterdam: IOS Press, 1-20.

7. Gordon, M.J.C., Mellan, T.F. (1993): Introduction to HOL; a theorem proving environment for higher-order logic. Canbridge University Press.

8. Jespersen, B. (2005), ‘Explicit intensionalization, anti-actualism, and how Smith’s murderer might not have murdered Smith’, Dialectica, vol. 59, pp. 285-314.

9. Liu, P., Zhou, B. (2008): Workflow Mining of More Perspectives of Workflow, In J. Software Engineering & Applications, 2008, 1: 83-87.

10. Nipkow, T., Paulson, L.C., Wenzel, M. (2012): Isabelle HOL; a proof assistant for higher-order logic. Springer.

11. Ren, A. H. (2001): Research on the Concurrent Software Developing Method Based on Object Oriented Petri Nets, BHU, The school of computer science, pp. 116–128.

12. Workflow management coalition terminology and glossary, Technical Report, WfMCTC–1011, Brussels: Workflow Management Coalition, 1996.

Acknowledgements. This research has been supported by the internal grant agency of VSB-TU Ostrava, project No. SP2013/207 „An utilization of artificial intelligence in knowledge mining from processes and process modeling and mining“, and co-financed by the European Social Fund and the state budget of the Czech Republic, projects No. CZ.1.07/2.2.00/28.0216 “Logic: the Development of the Discipline and Basic Logic Courses” and No. CZ.1.07/2.3.00/30.0004 “The enhancement of creation of excellent research teams and intersectoral mobility at Palacky University in Olomouc (POST-UP)”.

7 For details see [4].