An Overview of The Mensurae Language: Specifying Business Processes

We describe a language which can be used to model business processes (both technical and nontechnical). It has a formal semantics, so as to enable formal analysis and prediction on the basis of the models, and i s based on principles of measurement theory, so as to enable the application of engineering and scientific principles to metricate the business processes. The language models products and processes as the constituents of business processes and uses a control construct, gates, to enable product and process composition. The semantics of the language is based on timed transition systems and processes can be specified using a combined temporal and modal logic with real-time operators. The language thus obtained i s also relevant to modelling threads of execution in object oriented systems and may lead to appropriate constructs for defining timed, concurrent, and synchronised computations over object oriented structures.


Introduction
The purpose of this paper is to provide a brief overview of the Mensurae language.(See [17] for a more detailed description.)The language supports the Mensurae method for formal description of processes, understood here as referring to the technical and administrative activities of organisations.As such, it provides abstractions for the two main constructs of the method: products and processes.
The basics of the method are described in [15], as is the relationship of the method to Measurement Theory.(See also [21,5] on measurement.)What we are modelling is some real process and its associated products, technical or administrative (or both).Either this process is in place and we are modelling what we observe or we are intending, via the model, to prescribe what we eventually intend to observe in the organisation.The observed or intended phenomenon is called the empirical referent (and is to our endeavours what specific physical phenomena are to physicists attempting to understand the world by building scientific theories/models).
The language we use for modelling processes has three basic constructs via which the empirical referent must be modelled: products, processes and, an artefact of the method, gates.The first of these, product, is used to model the entities manipulated by processes.A product is an 'instantaneous' entity, in that it represents the measurable attributes of the entity at a specific moment in time.On the other hand, a process is an entity that relates to behaviour and so represents a phenomenon taking place over time.Gates are, to some extent, an artefact of the method.Processes are modelled via 'single input, single output' transformers and so require products to be assembled (input from several preceding processes) and disassembled (to send parts of the output to separate subsequent processes).
Business process modelling is, of course, not a new subject!Many consultants make big money out of it!Our focus here is on the problem of modelling itself, with a particular focus on technical processes and requiring levels of detail in process definition which enable the methods and principles of measurement theory to be applied for the purposes of analysis and prediction.A standard reference to approaches to business process modelling is [12].
The idea of characterising formally the process of software development is not new.The early work of [20, An Overview of The Mensurae Language: Specifying Business Processes ROOM 2000 2 16], etc is notable in this regard and relevant recent material on process modelling in software engineering can be found in [8].The spirit of what we are attempting is very much in the style of [20], i.e., characterising processes as programs.We see the major difference as being the larger domain of processes being modelled, the much more powerful and expressive language being used and the focus on measurement and measurability.Also, software engineering has moved on since the time of this work and concepts such as patterns and software architecture enable a more sophisticated approach.A related, but quite different formalisation appears in [10].
We also see this work as having potentially useful impact on the problem of defining threads of computation in object oriented systems.This will be elaborated further in section 3 on processes and in the conclusion.
The rest of this chapter is organised as follows.Section 2 describes products; section 3 focuses on atomic (unstructured) processes; section 4 explains the role of gates; section 5 introduces the concepts needed to use the constructs already introduced to model organisational processes and section 6 contains some concluding remarks and describes open questions.

Products
We wish to model product entities in terms of their measurable characteristics.So, an iron rod may be characterised in terms of its length, circumference, weight and so on.We say that it has length 2.2 m, circumference 3 cm, and weight 10.75kg.A room may be characterised in terms of its length, width, height, and floor area, as well as the numbers of windows and doors, their sizes and their position relative to some designated point in the room.The width of the room is measured directly (is directly observable) by applying a ruler in a prescribed manner to determine (with some degree of expected accuracy) the required number designating length on the appropriate scale.We may wish not to measure directly the area of the room, but to calculate it instead from the usual law relating length and width to area.Sometimes, unlike area, there is no way of directly measuring the value associated with some characteristic, as for example in the case of the utility of some decision made by management.In the theory of measurement, such utility values are the result of some well-defined function applied to some already available values for relevant characteristics (some of which may be directly measurable or calculated eventually from such directly measured values).These derived characteristics are theoretical constructs that we use in the modelling of product entities.
This distinction between what is (directly) observable and what is described via theoretical relationships is a fundamentally important one in science.See [24] for an explanation of these ideas in relation to science and [11] for an exposition of software engineering from this perspective.These chosen characteristics, the rules relating derived ones to the directly measurable ones and any other relevant relationships and laws incorporated into the model give us the vocabulary and properties characterising this (class of) product entity.If we see this model of a class of product entities as being given by a theory in some appropriate logic, we can view an individual product entity as being an interpretation (often confusingly called a model or mathematical model, as we will refer to it) of this theory.In particular, the characteristics associated with the product entity are given values in the appropriate scales (by means of the correspondence rules/measurement procedures) and obeying the rules and laws prescribed for the class, including the derivation of some characteristics from others.
Then, an atomic product P is defined as a 5-tuple <code_number P , product_name P , time P , attributes P , <Σ P , A P >> where: code_number P is a constant of sort Code, used to distinguish the product from other; • product_name P is a constant of sort Name to allow reference to the product; • time P is a constant of sort Time, called the time stamp of the product P, defining the moment at which the product's attributes have values associated with them; • attributes P is a set of constants which forms a subset of the constants in Σ P , designating the characteristics which we wish to use as the measures characterising our empirical referent; • <Σ P , A P > is a theory presentation, the proto-product (which includes in the language all of the constants above).
The Mensurae method requires that products be marshalled to form single inputs to processes (so process initiation time is well defined) and that outputs be decoupled ('unmarshalled') so as to enable them to be directed to the appropriate subsequent processes.The use of the word composed will be restricted to this kind of method induced notion of structure.(We will reserve the word structured to refer to the normal notion of structure, as for example in OO languages in terms of aggregation, specialisation, etc.For instance, a table is an aggregation of legs, top, screws, etc.) A product is either an atomic product or a composed product.A composed product P is either: • a pair P = <code_number P , ⊗(P c1 , …, P cn )> where ⊗(P c1 , …, P cn ) is an injection of the components P ci into the Cartesian product ('marshalling'); or • a pair < code_number P , ι( )> where is a finite non-empty set of products and ι( ) ∈ (i.e., choice, a kind of 'unmarshalling', the oher kind being projection from a tuple in ⊗(P c1 , …, P cn )).
(Note that composed products do not have names or timestamps of their own.Essentially, the timestamp of the latest atomic constituent can be said to be the timestamp of tupled product, while the timestamp of the chosen product in a choice construct is its timestamp.There is a rationale for this in the method.)When are two products equal?Clearly they have to have the same proto-product, i.e., specification.Further, we require that the codes, names, and time stamps and attributes be the same.Thus P = P', where P = <c, n, t, att, <Σ, A>> and P' = <c', n', t', att', <Σ', A'>>, iff c = c', n = n', t = t', att = att', Σ = Σ', and A = A'.
We have been looking at what OO calls classes.That is we have been building models of classes of empirical referents.We now wish to model individual referents, with specific values (of the appropriate kinds) associated with the attributes, code, name, and timestamp.Logic supplies us with the natural definition of what such 'individualisation' means and measurement theory tells us how to use measurement procedures to determine the appropriate 'individualisation'.We use the word instance for the individual referents in the real world corresponding to our theoretical (class) constructs).It will be instances of products that will be involved in executions of processes.
Simply put, an instance of a product P = <c, n, t, att, T> is an interpretation/model (in the sense used in logic) of T. The reader should note that we are not in fact considering all models of the proto-product/presentation associated with a product.We are only interested in some 'standard' interpretations where: the codes are always interpreted in some organisation's standard code domain; ditto names and name domain; the time stamp is interpreted in the standard time domain (as given by correspondence rules and measurement theory); and certain sorts are interpreted as measurement scales according to the organisation's (and scientific) standards.

Processes
A process models an empirical referent that transforms an input product into an output product.Examples include: the process of assembling a telephone from the component products as part of an assembly line in a factory; developing, testing, and delivering a software application from a given set of requirements; ascertaining and stating the requirements for a software application from the appropriate information sources; performing an experiment in a scientific laboratory; servicing defect reports after products have been delivered to customers; (a thread of computation over a given object system -see the discussion below of the virtual machine); etc.
As for products, processes may be atomic (i.e., no internal structure in terms of 'subprocesses') or structured.We call the latter framework processes or process explosions and treat these in section 5 after introducing gates, which will play the role of control elements (as well as that of 'marshalling' devices) in our process language.
Because processes model input/output transformations, we are immediately put in mind of conventional programs, as conceived in the early days of programming language semantics.Should we think of processes as simply implementing such an input/output transformation?Programs are defined over some virtual machine representing the execution environment for the language.This execution environment provides direct interpretations for the basic commands of the language and is able to sequence instruction execution according to the control flow prescribed by the program.
Our processes differ from conventional programs in a number of ways.One such difference is the fact that there may be more than one virtual machine at work in implementing the process and these virtual machines are coordinated and synchronised in their behaviour in some well-specified way.This reminds us of the world of object oriented (OO) programming and design, where systems of objects play the role of our virtual machines.An application is realised in terms of a number of such machines co-ordinated by one such machine that controls the order in which objects' methods are invoked with appropriate data so as to achieve the application's objectives.
In order to model processes, we will pursue this analogy of the virtual machine executing our process prescriptions.Thus, our virtual machine will be an object (system) with methods, the basic actions of which our machine is capable (analogous to assignments in a conventional language and machine).Its states will be defined in terms of attributes or state variables (analogous to program variables in conventional languages and some of which will be used as attributes of products).This object may be built from a number of other objects via the appropriate structuring mechanisms (e.g., see [6,7]) and will in realistic applications be very large.For example, to model software development, we must have modelled the basic actions of which individuals or groups are capable: design a test, execute a test, build a specification of a small program, implement the specification in a given programming language, integrate a program with an application, retrieve a program from a depository, fix a bug in a program, etc.In practice, we have noted that the most difficult aspect of modelling is deciding on the granularity of the basic actions of our virtual machine.Now, what our virtual machine models is the potential activities that the empirical referent is capable of performing.Using our analogy with the virtual machine executing a program, the former is capable of executing many programs; in fact, it can execute any syntactically correct program in the programming language.Analogously, our virtual machine is capable of exhibiting many behaviours, all consistent with the 'rules' of the machine.What we want is to choose some behaviour(s) that is (are) consistent with our intention of transforming some input product into a corresponding well defined output product.This is where processes come into the picture.Any process will be a specification of what input/output transformation is required so as to model the empirical referent in which we are interested.Some such specifications will be like the programs in our analogy, i.e., an explicit combination of the actions of our virtual machine via some appropriate control structures.Others will be more abstract and describe implicitly the effect required via more abstract actions.Eventually, we will have to refine such an abstract specification into a 'program' using only basic actions so as to be able to execute them on our virtual machine.
As with conventional programs and machines, there are a number of other factors to consider.One such question is the nature of the control structures to be allowed.We will introduce standard combinators for sequencing, and parallel combination of processes and we will need some form(s) of loop structure to deal with iterative processes.See section 5 for the definition of these structures.Our first task is to formalise the concept of virtual machine.We do this by borrowing from [6,7] the concept of object specification.
The formal counterpart to the real-time virtual machine outlined above consists of a logical framework based on timed transition systems, called RETOOL (REal Time Object Oriented Logic).RETOOL [2] is a modal action logic based on an extension of Segerberg's δ operator [22] with time bounds.The semantics of RETOOL is based on the notion of a computation over a timed object frame, which is the formal counterpart to a potential behaviour of some object described, in our methodology, by a timed transition system.By a specification, we mean a theory (presentation) in the proposed action logic, that is a pair consisting of a signature and a collection of sentences describing the behaviour of the system.A signature consists of a declaration of the non-logical symbols that are used to model the specific features of the object/system.In the case of RETOOL, signatures consist of collections of attributes (state variables) and actions.For simplicity, we will present in this paper a propositional version of RETOOL.In the more general setting, attributes can be typed with data sorts and actions can take arguments.
We assume given an ordered field (TIME,≤) with a maximum ∞.An object signature is a pair <Α,Γ> where Α and Γ are sets of attribute and action symbols, respectively.A semantic interpretation structure for an object signature is given based on the notion of timed transition system by Henzinger et al (1992).A timed object frame F for a signature θ is a sextuple (W,→,l,u,I,w 0 ) where: W is the set of states (or possible worlds); →:W×Γ→W is the transition relation; l maps each g∈Γ to a delay l(g)∈TIME\{∞}; u maps each g∈Γ to a delay u(g)∈TIME such that u(g)≥l(g); I: Α→2 W interprets the attributes; and w 0 ∈ W is the initial world/state.We say that g∈Γ is enabled in state w iff → is defined on the pair <w,g>, and define, for every g∈Γ, the set en(g) of all states in which g is enabled.
Attribute symbols are interpreted as defining subsets of worlds: the worlds in which the attributes are true (recall that we are working in a propositional language).Action symbols are interpreted as transition relations over states.As in [14], two time bounds are defined for every action: a lower and an upper time bound.The intuitive semantics of these bounds, formalised below, is that the lower bound defines the minimum delay that must be observed for the action to take place (be committed), whereas the upper bound defines the maximum delay before the action's effects become observable.
Given a signature θ, we define the set SP(θ) of state propositions over θ as follows: p ::= a | ¬p | p→p' where a∈Α.The denotation of a state proposition in a timed object frame F is the set of worlds defined as follows: Given an object signature θ, the set of action terms AT(θ) is defined as follows: t ::= g | q l δ u p where g∈Γ, p,q∈SP(θ), u∈TIME and l∈TIME\{∞}, l≤u.Αction terms are interpreted over 2 Γ as follows: • oeg" F = {g}; • oeq l δ u p" F = {g: l≤l(g)≤u(g)≤u, en(g)=oe¬p∧q" F and w g → w' implies w'∈oep" F }.
By q l δ u p we denote the actions that establish p before u units of time provided that they were enabled for at least l units of time in states satisfying ¬p∧q.This is a generalisation of the δ operator defined by [22] in two ways: the inclusion of the precondition q and the time bounds.Finally, we have the language FOR(θ) of the sentences that can be used to express properties of objects over an object signature θ: φ where a∈Α and t, t 1 and t 2 ∈AT(θ).The satisfaction of a formula by a timed object frame F at a world w is defined as follows: F,w‚a iff w∈I(a); F,w‚(t A formula φ is said to be valid in a timed object frame F iff F,w‚φ for every world w.Given a set Φ of formulae, and a formula φ, φ is a consequence of Φ (Φ‚φ) iff φ is valid in all the timed object frames in which all the formulae in Φ are valid.An object specification is a theory presentation <θ,Φ> where θ is an object signature and Φ is a (finite) set of θ-formulae.We say that a frame F is a model of the specification <θ,Φ> iff φ is valid in F for every φ in Φ. (There is a proof theory for the logic presented in [2,17].) As mentioned before, the behaviour of a system is given by the integration of the behaviour of each of its component objects together with their interactions.The integration will be discussed further below.
In fact, an extension of Timed Transition Systems may be used, Timed Action Transition Diagrams (TATD), which, instead of just assignments as in [14], takes arbitrary actions in the labels of the transitions.The idea is that actions can be understood as a semantic counterpart of methods and messages in OO.For a definition of TATD, see [14,2].A mapping from TATDs to object specifications in RETOOL is also provided.
The integration of the behaviour of the objects of the involved classes is achieved by means of colimits in the appropriate category of object specifications (C RETOOL ).The categorical framework for this integration, which takes into account the possibility of various objects of the same class to be active at the same time, follows the approach presented in [6,7].
Properties of behaviours of objects specified in RETOOL can be formulated and proved using a Metric Temporal Logic in the style of [3].We start by defining the possible behaviours of an object in terms of computations over a timed transition diagram.A timed state sequence for a timed object frame F is a pair ρ=<σ,T> where σ is an infinite sequence of states (σ i ∈W F ) and T is an infinite sequence of corresponding times (T i ∈TIME\{∞}), satisfying: • (monotonicity): for all i≥0, T i+1 =T i or (T i+1 >T i and σ i+1 =σ i ); • (progress): for every t∈TIME\{∞}, there is i≥0 such that T i ≥t.
A computation over a timed object frame F is a timed state sequence <σ,T> such that σ is a computation of the underlying transition system (i.e., for every i≥0, if T i+1 ≠T i , then σ defines a transition σ I σ(i) → σ i+1 with g=σ(i) for some g∈Γ) and • (lower bound): for every i≥0 in the domain of σ there is a j≤i such that T i -T j >l(σ(i)) and σ(i) is enabled in every state σ k for j≤k≤i; • (upper bound): for every g∈Γ and i≥0, there is j≥i with T j -T i ≤u(g) such that either g is not enabled at σ j or g=σ(j).
A computation is said to be complete if it is either infinite or it cannot be extended.Let O = <θ,Φ> be an object specification.The set of computations over O, denoted comp(O), is the set of all computations over any timed object frame F which is a model of O.We also use comp F (O) to denote computations over the fixed model F.
The temporal language over a signature θ=(Α,Γ) is defined as follows: where a∈A, t∈AT(θ), ∼ is a relation on TIME, c∈TIME.The semantics of this language is straightforward, see [3].
In summary, the virtual machine provides basic actions whose behaviour is specified in terms of state variables.There are necessary conditions for the action to be performed.There are preconditions that define the situations in which the execution of the action is to have a particular effect.There are upper and lower bounds on the duration of an action (with the latter indicating the time after which the action will be committed and the former indicating the maximum time until the effect of the action becomes observable).
We now wish to define atomic processes.We will use the diagrammatic notation for processes illustrated in Figure 1:

Figure 1: a basic process
Here p denotes a process code (as we will see, an attribute of a process) and P I , P O denote the codes of the input and the output products, respectively.These kinds of diagrams hide other information about the process and we will have occasion to use various devices to exhibit some of this information, as and when necessary.Our intention is to define a process as a transaction consisting of a segment of a computation of the underlying virtual machine.Hence, we want a process to specify such a segment of a computation by: • defining an initial condition (identifying states of the virtual machine's computations which can serve as an initial state of the transaction); • defining a final condition (identifying states of the virtual machine's computations which can serve as a final state of the transaction); • defining an invariant which must be satisfied throughout the transaction in order for the transaction to complete successfully; and • defining lower and upper bounds on the time to be taken by the transaction where the lower bound gives a minimum time from some point of the computation within which the transaction must start and the upper bound gives a maximum time within which it must complete.
In order to specify transactions, we need a new operator that allows us to describe segments of computations of such a virtual machine.We use ∆ to denote this operator and introduce it into the class of formulae, FOR(θ), as follows: τ where: q is the initial condition, I is the invariant, l is the lower time bound, u is the upper time bound and p is the final condition.The semantics of this new formula is defined as follows1: σ,T,i‚(q,I) l ∆ u p iff for some j, k such that i+l≤j<k≤i+u, we have for each i≤m≤j that σ,T,m‚q, σ,T,k‚p, and for each j≤n≤k we have σ,T,n‚I.In fact, we can reformulate this as: σ,T,i‚(q,I) l ∆ u p iff for some j such that i+l≤j<i+u we have for each i≤m≤j that σ,T,m‚q and σ,T,j‚IU ≤(i+u-j) p where the latter relation holds if at state j the invariant begins to hold, continues to hold until p becomes true and p must become true before i+u-j time units pass (so as to assure termination of the transaction before the maximum time u allowed for the transaction).
The reason we have included the invariant I in the specification of the transaction is because the transaction is not atomic, in the sense that the actions of the virtual machine are.Once committed, the latter actions complete without interruption or interference, 'ignoring' whatever else may be happening during the elapsed time of the execution.In contrast, transactions may be influenced by changes caused by the execution of other actions in the virtual machine.For example, if someone turns off the printer in the middle of its printing transaction, the latter cannot complete properly.We can represent the availability of the printer throughout the printing transaction via an invariant on the states of the virtual machine.In fact, we will use this feature to represent environmental influence on the characteristics of a transaction.Analogously, q may be thought of as a 'set-up invariant', i.e., a property that has to hold while the transaction is made ready.This is analogous to the enabling condition on actions having to hold for long enough for the action to commit, as defined above.
We say that (q,I) l ∆ u p is satisfied by the specification <θ,Φ> iff there is a computation over a timed frame F such that (q,I) l ∆ u p is satisfied in the computation.In other words, the specification has a non-empty set of models satisfying the specification of the transaction.
An atomic process is a pair <proc, VM> where VM = <θ, Φ> is as defined above and proc = <process_code, process_name, process_owner, P I , P O , (q,I) l ∆ u p> where: • process_code is a state variable of the appropriate sort (used for process codes) and which is rigid (i.e., does not change value during computations); • process_name is a state variable of the appropriate sort (used for process names) and which is rigid (i.e., does not change value during computations); • process_owner is a state variable of the appropriate sort (used for process owner names) and which is rigid (i.e., does not change value during computations); • P I , P O are the input and output products, respectively, for the process with the attributes of the products interpreted as state variables of the virtual machine; and • (q,I) l ∆ u p is the specification of the process's various properties, which we call the transfer function of the process.
An Overview of The Mensurae Language: Specifying Business Processes ROOM 2000 8 The semantics of an atomic process p = <proc, VM>, denoted by comp(p), is given by the subset of comp(VM) which satisfies (q,I) l ∆ u p.That is, we take the timed state sequences over frames, which are models of the virtual machine and choose those computations that satisfy the process specification.
We can use TATDs to specify an atomic process by associating the initial condition q with the initial state of a TATD, the final condition p with the final state of a TATD, and the invariant and time bounds with the transition from the former to the latter.The following diagram illustrates this:

Figure 2: a simple transaction diagram defining an atomic process
In fact we can use arbitrary such TATDs as long as a few restrictions are observed.Firstly, we require that there are unique initial and final states in the TATD.We also require that each transition be labelled by a formula of the form (q,I) l ∆ u p.We then obtain 'complex' invariants from the process thus defined.We will not detail here how this works.
An instance p I of an atomic process p = <proc, VM> is a computation <σ,T> over a timed object frame F such that there is an i such that σ i satisfies the transaction specification in proc.We also call such an instance an execution trace for p.So, an execution trace is a sequence of states and transitions in some model of the underlying virtual machine that satisfies the transaction specification.Let us consider an example, which will be completed in section 5.The example shows how the real-time features of the specification language play a decisive role in the selection of the refinements of processes.We concentrate first on the prescription of the required process.Our products will be very simple and their role in the example completely de-emphasised.
A manufacturer of candy vending machines wants to manufacture machines with the following characteristics.If the machine has candy, then, after money has been deposited, at most a time K1 passes before candy is delivered.If the machine is empty, then at most a time K2 can pass before the transaction is finished.If the machine can be fully replenished in time to meet the K2 upper bound, then it should be replenished; otherwise, the money should be given back.
Let us model the process that forms the part of the behavior of the machine after money has been introduced and until candy has been delivered or the money was given back.We do this by defining an appropriate formula (q,I) l ∆ u p; we will actually do this by giving I, u and l and characterising q and p in corresponding 'parts'.

I: true
The invariant is the trivial condition.(But see below!) p1: $_in ∧ x = #candy > 0 ∧ u ≥ K1 ∧ l = 0 q1 #candy = x-1 ∧ delivered This covers the situation where there are candies in the machine and the upper time bound for the required process is greater than that needed to deliver the candy.p2: $_in ∧ #candy = 0 ∧ u ≥ K2 ∧ l = 0 q2: #candy = max_candy -1 ∧ delivered This covers the situation where there are no more candies in the machine, but there is enough time to replenish the machine before the customer gets tired.p3: $_in ∧ #candy = 0 ∧ u < K2 ∧ l = 0 q3: delivered ^ money_back If the manufacturer believes that a consumer can wait 3 minutes for candy without loosing his patience, then K2 can be set to 3 minutes in the specification.Let us assume that as a constraint, this part of the machine must be built using the following (subset of) actions of the assumed general vending machine (i.e., it is the basic actions of An Overview of The Mensurae Language: Specifying Business Processes which a general vending machine is capable; it must be programmed to exhibit the behaviour described by the formulae above): RETURN_PRODUCT (which returns candy provided the machine is not empty; its lower time bound is 0 and the upper time bound is 3 seconds); REPLENISH (which fully replenishes the machine; its lower time bound is 0 and the upper time bound will be discussed later); RETURN_MONEY (which gives the customer his/her money back; its lower time bound is 0 and the upper time bound is 3 seconds).We will complete the example in section 5 when we have defined the concept of refinement and we have conceptual tools to check the correctness of implementations.

Gates
The Mensurae method requires that the processes used to model empirical referents have a single input product (so as to make the start time of the process unique in any execution trace) and a single output product (so as to make the termination time of the process unique in any execution trace).Hence, it becomes problematic to model a process that may have many input sources without finding some way to synchronise the arrival of the inputs (in time), and some way to 'package' the various products into the single input product.
Similarly, the output product needs to be 'unpackaged' so as to enable the sending of various constituent products to the appropriate subsequent processes.There is also the problem of dealing with context conditions defining when a part of a process may proceed.For example, it may be that some product can move to a process only after some condition is met, as in the case of a print job being held in a queue until the printer is ready (e.g., has been turned on).
We use the concept of a gate to model the constructs we need in the language.Gates are simply artefacts of the method, in that they do not appear explicitly in empirical referents and are used only to achieve the 'artificial' conditions set by the method.There are three basic types of gates which we will discuss: the multiplexer, the demultiplexer, and the semaphore.
A multiplexer m c (see Figure 3 for a graphical representation) defined over some virtual machine VM = <θ, Φ> is a four-tuple <multiplexer_code, c , P c ,F c > where: • multiplexer_code is a rigid variable of the underlying virtual machine used as a unique identifier of the gate in some model; • c = {P 1 , …, P n } is the set of input products to the multiplexer; • P c = <P 1 ', …, P m '> is the output product of the multiplexer; and • F c is the multiplexer action function defining each P i ' explicitly in terms of the set of input products c .A demultiplexer d c (see Figure 4) and a semaphore s c (see Figure 5) are defined similarly.
Gates are used to connect processes by means of their input/output products.We now want to define what the result is of such a connection in terms of the properties and semantics of the resulting constructs.These constructions will also be useful when defining abstractions and explosions of processes in section 5. Suppose that we have a muliplexer m c = <c, c , P c ,F c > and that the process p i outputs the corresponding product P i to the gate m c and that the output product P c of the gate is the input to process p c .Diagrammatically, we have the situation of Figure 6a.

F i Figure 6c
We have presumably associated the TATDs T j , i = 1,...,n, and T c with the processes p j and p c , respectively.An obvious question to ask is: What is the TATD associated with the combination?Firstly, we have to define how a transition is made from the final state L jf of T j to the initial state L ci of T c .Clearly, not only must the initial condition p ci of p c be true, but so must the condition q jf associated with the final state of T j .. Hence, we can define a transition from the final state L jf to the initial state L ci as in Figure 6b.Details may be found in [17].

Processes
When defining processes, we will be modelling very complex empirical referents, even after deciding to abstract away unnecessary details of the latter.We can proceed in two ways to overcome this complexity: work bottom up and model small subprocesses and compose them successively until we have modelled the overall process in which we are interested, or work top down and specify the overall effect we want from the process and then refine this abstract specification in terms of process combinations, eventually using the actions of the underlying abstract machine.In either case, we need to relate an 'abstract' atomic process to a refinement of it in terms of more concrete processes, products and gates.We start with the following definition: a P/p framework is either a product or a process.Whereas a product is potentially a stand-alone object, a process is not.The latter requires the existence of two other referents and their models, i.e., the two products constituting the input and the output of the process.A process is either an atomic process or a framework process.
Our empirical referents will, in the end, have to be modelled in terms of the atomic processes supplied as the actions/methods of our underlying abstract machine.Any process we define will eventually have to be realised by a bottom up or top down construction from these atomic constituents.We must now define what we mean by the term framework process.
We need some way of combining constituent processes and products, via the use of gates, to define processlike objects with single input and single output products, a well defined transformation from the former to the latter and well defined minimum and maximum execution times.These combinations will be defined in terms of several basic combinators: sequential combination of two processes, semaphore combination of two processes, and parallel combination of a set of processes via a multiplexer and a demultiplexer.Let p i = < code i , name i , owner i , P iI , P iO , (q i ,I i ) l i ∆ u i p i >, i = 1,2, be two processes defined over the same virtual machine VM.Let τ i = (q i ,I i ) l i ∆ u i p i .Then, the sequential composition of p 1 and p 2 , denoted by p 1 ; p 2 , is the process p = <code, name, owner, P 1I , P 2O , τ> where:code is a new (unique) code for the newly defined process;name is a new (unique) name for the newly defined process;owner is a new (not necessarily unique) entity responsible for the newly defined process; • P 1I , the input product of p 1 , is the input product of the newly defined process; • P 2O , the output product of p 2 , is the output product of the newly defined process; • τ is the transfer function (q,I) l ∆ u p where: • q is q 1 ; • p is p 2 ; )) which requires that: • the initial condition q 1 of p 1 holds for at least time l 1 ; • at which point the invariant I 1 of p 1 holds for time not exceeding u 1 -l 1 ; • at which point the final condition p 1 of p 1 becomes true; • and this means that eventually the initial condition q 2 of p 2 holds for at least time l 2 ; • at which point the invariant I 2 of p 2 holds for time not exceeding u 2 -l 2 ; • at which point the final condition p 2 of p 2 becomes true.
Clearly, we require the resulting process to have the same initial condition as p 1 and the same final condition as p 2 .The combination will take at least as long as p 1 to commit and will take at most the sum of time that each of p 1 and p 2 would individually to produce a result.Also, we want the invariant I 1 to hold while p 1 executes and ditto I 2 and p 2 .Further, when we reach the final state of p 1 satisfying p 1 , we want that eventually the initial state of p 2 satisfying q 2 , is reached, committing p 2 to start execution.The transfer function for p is then defined from these ingredients.
The semaphore composition of p 1 and p 2 , denoted by p 1 ; S p 2 , (enabling p 2 to proceed only when the condition in semaphore s becomes true), and the parallel composition of p 1 and p 2 via demultiplexer d I and multiplexer m O , denoted by [p 1 ; p 2 ](d I , m O ), are defined analogously.
Finally, we are ready to define framework processes in terms of these combinators: a framework process p is a process defined from some set of constituent processes {p 1 , …, p n } in terms of the combinators defined above.We denote such a framework process by the pair <p, f-exp> where p is an atomic process obtained from the combination of processes {p 1 , …, p n } by the combinators in f-exp.For the sake of brevity, we often write p = <code, name, owner, P 1I , P 2O , f-exp> instaed of p = <<code, name, owner, P 1I , P 2O , τ>, f-exp>.
Processes are 'programs'.Like programs, we require some way of describing iterative computations, not simply parallel and sequential combinations of processes.(We may indeed require recursive processes, but we leave this for further work.)The idea behind the construct that we want is the same as that for a while loop in conventional languages: If the semaphore condition S is false, then the loop body, the process p, is not executed and the loop terminates.If the semaphore condition is true, then the loop body, process p, is executed and the execution returns to the semaphore.Note that the input product to the loop, the output product of the loop and the product that is the output of the semaphore and the input of the body process are all the same.This is because a loop would not 'type check' if the products were different.The output product of p has to go either to the process after the loop or back to the semaphore to be (possibly) executed again.Hence it must be the same as the input product to the loop.Note, however, that the instances of the product P that would be input to the semaphore at each iteration would not be the same!(Otherwise, the loop would not be doing anything useful!) What we are attempting to represent is the family of framework processes corresponding to the unfolding of the loop a 'sufficient' number of times, as in the semantics of such constructs in programming languages.
As a special kind of process, a while loop should have a specification like any other process, i.e., there should be an input condition, an output condition, an invariant and lower and upper bounds on the execution time of the loop (as opposed to that of the constituent process).So, if we denote such a loop by while(S, p), with: • s w = <code sw , P, S w > being the semaphore to which the condition S corresponds, • p = < code, name, owner, P, P, (q,I) l ∆ u p> being the process to be used as the body of the while loop, and with • p i = < code i , name i , owner i , P iI , P iO , (q i ,I i ) l i ∆ u i p i >, i = 1,2, the processes to be connected by the loop, then while(S w , p) = < code w , name w , owner w , P, P, (q w ,I w ) l w ∆ u w p w > where: • code w , name w , owner w are new code, name and owner for the family of processes like entities which the loop represents; • P is the input and the output product of the loop 'family'; • q w is the triggering condition for the loop.It must be the case that q w U(S w ∨ ¬S w ) since we want the triggering condition to cause the loop condition S to be evaluated (and it could have the initial value true or false); • p w is the output condition of the loop and we must have that: • p w → ¬S w , because having exited must mean that the loop condition is false, and • p w → I w , because the loop invariant should be true when the loop body terminates; • I w is the loop invariant and it must be true before the loop body executes and after the loop body terminates, but not necessarily during the loop body's execution (as is the case for loops in conventional languages); and • l w and u w are the lower and upper bounds on the time taken to execute the loop.
If the loop condition is false the first time it is met, then the loop connects the processes p1 and p2 as if it were the semaphore with condition q w ∧ ¬S w .Hence, we need the triggering condition of the loop to hold along with the semaphore condition ¬S w (when the process p 2 is available for execution).This is not quite the semaphore we started with, because there is the extra requirement that the triggering condition for the loop is to hold while the semaphore passes on the condition ¬S w .
If the loop body is executed once, then the initial instance of the semaphore becomes q w ∧ S w to indicate that the triggering condition for the loop holds when the positive result S w holds, simultaneously with the initial condition q of the loop body.And then, after one execution of the loop body, the semaphore test fails and the loop is exited, implying that we have a semaphore condition p ∧ ¬S w connecting the loop body p with the succeeding process p 2 .
The only case left is the one when there is more than one execution of the loop body.In this case, the initial and final instances of the semaphore are connected to the first instance of the loop body p and the succeeding process p 2 , respectively, as in the paragraph above.Then there is the general case to be considered of one instance of the loop body connected by a positive result of the semaphore to the succeeding instance of the loop body.The semaphore condition in this case is just S.
Note that what we have defined is a family of framework processes consisting of: the initial process p 1 ; a number (0 or more) of positive occurrences of the semaphore, each followed by the loop body p; and, finally, a negative occurrence of the semaphore connected to the succeeding process p 2 .The semantics of the loop construct is given in terms of this family of framework processes.For each member of the family, the framework defines a set of computations as explained above for frameworks generally.We further require that the end-to-end time from entering the first instance of the loop body to entering the final state of the final instance conforms to the loop specification.
Having mentioned the time limits set in the loop specification, as a default, the former may be 0 and the latter ‹ to reflect the fact that a semaphore takes no time to 'execute' and a loop may be unbounded.However, different limits may be specified, resulting in proof obligations that must be verified so as to demonstrate that the lower and upper bounds are met by any execution of the loop.
So, a refinement is exactly what one would expect -a process with a set of associated computations, which is a subset of the abstract process's computations.This concept of refinement reminds one of the definitions used in algebraic specification: a refinement is correct iff the models of the refined specification are a subset of the models of the abstract specification.However, to obtain such a simple definition in the algebraic specification theory requires a lot of 'contortions': take quotients, forget junk, take a reduct along a signature morphism, etc.It is interesting that here there is a direct version of this idea which may be used and it appears that the target language (that of the virtual machine) being fixed underpins this simplicity.We might call this targeted notion of refinement language constrained refinement and will focus on it in a future paper.Note that this does not actually give us direct methods for proving that one process is a refinement of another.We have at the moment only the indirect method given above -compare the relevant computations.We leave as further work the development of appropriate direct methods.
Of course, if comp(p 2 ) =∅, the empty set of computations, then p 2 is a refinement of p 1 !But, in general, this would be unsatisfactory and should only occur if either we have built the refinement badly or there is a genuine problem and the original process specification already has an empty set of computations.The latter case may be an impetus to retool our factory, so that we do have in place the right constituents to realise our process specification.
Let us return to the example at the end of section 3. We want to refine our requirement for a process to control the vending machine so that the specification is implemented in terms of the three given atomic actions RETURN_PRODUCT, REPLENISH and RETURN_MONEY.If the machine is to be placed inside a convenience store, then as soon as the machine is emptied a clerk will replenish it, and therefore, a reasonable upper time bound for the replenishing action might be 2 minutes.Then, the following (not completely described) framework process shows a feasible implementation: (Note that we have not labelled arrows with products, as we are not focusing on these in this example.The labels we have included are to help interpret the demultiplexers as implementing a conditional.) If the machine is to be placed in an underground station, then it may be expected that it will not be replenished more than twice a day.Then, the upper time bound for the replenishing action might be, for instance, 12 hours.In this case, the previously described process does not satisfy the specification, but the following one does: Of course, we have not given enough details to verify that the framework processes have the right functionality.(We would have to specify the underlying general vending machine.)One further variant is worth discussing.If the vending machine has a button the customer can use to retrieve the coin that he/she has inserted, then we might wish to condition the process we have specified by requiring that the customer has not pressed this button.We can do this by changing the invariant I to ¬return_coin_pressed.This would have the effect of predicating the correct functioning of the framework processes defined above on the non-detection of a button press by the customer during the time that the vending machine is executing the framework process.

Conclusions
We have described briefly a language for modelling industrial processes, developed as part of the Mensurae project being conducted at LMF-DI, PUC-Rio de Janeiro.The language supports a method based on ideas first put forward by Agnes Kaposi (in, e.g., [15]).We have said very little about the method, which has some claim to universality in process modelling.No language, on its own, is really an effective tool.It requires systematic method in the hands of skilful engineers to turn it into that effective tool.
The language we have described is at one level a very simple one.It has only two kinds of constructs, namely products and processes.Products are modelled by first order theories, which describe the (class of) products in terms of their basic measurable characteristics.Because we are modelling industrial processes, some of these characteristics are related to the role that such products play in these processes.So, we have product codes and names, together with time stamps, which establish when the characteristics were determined by means of appropriately defined measurement procedures.Products may be composed (by means of tupling and choice operators) from other products to enable us to marshal inputs to our single input, single output processes.Products may also be complex (i.e., assembled or manufactured), in the sense that they are modelled, via a set of object oriented operations, from constituent products.
Processes are single input, single output transformations which take some non zero amount of time and that model the changes wrought by business processes on products.Like products, they are modelled in terms of appropriate characteristics, which again include codes and names.They also include further characteristics, like responsible entities (owners), timing constraints and input/output transformation.Processes may be composed from (or refined to) framework processes built from constituent processes via sequential and parallel combinators.A gate is an artefact of the method used to enforce the single input, single output regime of processes.It can also be used to define control mechanisms, including loops.The computational model used is analogous to that for programs being executed on an abstract machine.The role of the latter is played by a system of objects modelling the basic capabilities of the organisation.A process is then like a program executing over this abstract machine, 'causing' it to execute the process.As such, a process may be affected by external influences, via conditions dependent on attributes not fully under the control of the executing process.Hence, other processes executing concurrently with the process in question may influence its behaviour.Examples of such external influences may be management procedures, quality procedures, as well as other technical/organisational processes.
There are many avenues of further research to be explored.We need to understand how the interaction between concurrent processes running in the same organisation may be expressed effectively.Clearly, synchronisation between processes and the notion of one process being 'meta' with respect to another are relevant points at issue.There is an obvious connection with the concept of threads of execution over object oriented systems.The process language presented may well be a good starting point for exploring this thorny problem in object oriented programming.