Market-Driven Symbolic Execution of Models of ... - Semantic Scholar

UNU/IIST International Institute for Software Technology

Market-Driven Symbolic Execution of Models of Manufacturing Enterprises Tomasz Janowski, Gustavo Gimenez Lugo and Zheng Hongjun April 15, 1998

UNU/IIST Report No. 137

T

UNU/IIST and UNU/IIST Reports UNU/IIST is a Research and Training Center of the United Nations University. It was founded in 1992, and is located in Macau. UNU/IIST is jointly funded by the Governor of Macau and the Governments of

China and Portugal through contribution to the UNU Endowment Fund.

The mission of UNU/IIST is to assist developing countries in the application and development of software technology. UNU/IIST contributes through its programmatic activities:

1. advanced development projects in which software techniques supported by tools are applied, 2. research projects in which new techniques for software development are investigated, 3. curriculum development projects in which courses of software technology for universities in developing countries are developed, 4. courses which typically teach advanced software development techniques, 5. events in which conferences and workshops are organised or supported by UNU/IIST, and 6. dissemination, in which UNU/IIST regularly distributes to developing countries information on international progress of software technology. Fellows, who are young scientists and engineers from developing countries, are invited to actively participate in all these projects. By doing the projects they are trained. At present, the technical focus of UNU/IIST is on formal methods for software development. UNU/IIST is an internationally recognised center in the area of formal methods. However, no software technique is universally applicable. We are prepared to choose complementary techniques for our projects, if necessary. UNU/IIST produces a report series. Reports are either Research R , Technical T , Compendia C or Administrative A . They are records of UNU/IIST activities and research and development achievements.

Many of the reports are also published in conference proceedings and journals.

Please write to UNU/IIST or visit UNU/IIST home page: http://www.iist.unu.edu, if you would like to know more about UNU/IIST and its report series. Zhou Chaochen, Director | 01.8.1997 { 31.7.2001

UNU/IIST International Institute for Software Technology

P.O. Box 3058 Macau

Market-Driven Symbolic Execution of Models of Manufacturing Enterprises Tomasz Janowski, Gustavo Gimenez Lugo and Zheng Hongjun Abstract We apply formal description techniques to model, compose and give operational meaning to the class of reactive systems representing manufacturing enterprises. The enterprise is a discreteparts manufacturer which pursues its business activities to best compete with other such entities, together comprising a market. It does so by means of resources and processes that execute concurrently on such resources, subject to internal (resource) and external (market) constraints. In some cases the enterprise is a consumer, in others a supplier of products. Some modelling techniques are familiar for reactive systems: shared-memory concurrency, resource-bound synchronous executions, priorities and scheduling, external and internal choice. Other are speci c to this domain: undetermined (human) choice, transfer of products during one-to-one (one consumer, one supplier) synchronisation, marketing decisions and how they aect many-to-one (one consumer, many suppliers) synchronisation. It is a relatively new application of FDTs, as well as a contribution to the semantics of the emerging discipline of enterprise engineering.

Tomasz Janowski is a Research Fellow of UNU/IIST. He received an MSc in Mathematics from the University of Gdansk (Poland) and a PhD in Computer Science from the University of Warwick (England). His research interests include logics for provable fault-tolerance, realtime scheduling, formal models for manufacturing and the integration of formal and informal techniques in software development. Gustavo Gimenez Lugo is a Fellow of UNU/IIST, originally from CPGEI/Federal Centre for Technological Education, Curitiba, Brazil where he is a research assistant. His research interests are focused on modelling and analysis of production systems. Zheng Hongjun is a Fellow of UNU/IIST. He received a PhD degree in Computer Science from the Peking University, Department of Informatics, Beijing, China, in 1997. His research interests are focused on the semantics of programming languages.

Copyright c 1998 by UNU/IIST, Tomasz Janowski, Gustavo Gimenez Lugo and Zheng Hongjun

Contents

i

Contents

1 Introduction 2 Modelling an Enterprise 2.1 2.2 2.3 2.4

Products . Resources Processes Enterprise

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

3 Modelling an Enterprise: Example 4 Semantics of an Enterprise: Symbolic Execution 4.1 4.2 4.3 4.4 4.5

Operations . . . . Tests . . . . . . . . Processes . . . . . Enterprise . . . . . Set of Enterprises .

5 Conclusions

Report No. 137, April 15, 1998

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

1 3 3 4 6 7

8 10 10 11 12 14 17

19

UNU/IIST, P.O. Box 3058, Macau

Introduction

1

1 Introduction The scope for application of formal engineering methods is steadily growing. They increasingly enter domains where computing is only a fragment, albeit an important one, of the universe of discourse [19]. Telecommunication, nances, hybrid or work- ow systems, air-trac control, shop- oor manufacturing are only some well-known examples. This paper is about market-driven manufacturing. This is an important area, present in every aspect of the economy. Because of problems of adaptation for every manufacturing enterprise to face increasingly dynamic situations on the market, there is a growing demand for tools, methods, languages and standards to model, analyse, build and re-build such enterprises as engineering artifacts [3]. In fact, some authors predict on this basis the need for a new discipline of enterprise engineering [17, 21]. Not unlike other engineering disciplines, this one requires semantic foundations. This paper applies formal description techniques, in particular RAISE [9], to put forward some issues in the modelling of manufacturing enterprises and their market-driven executions. This is a demanding area because an enterprise can in many aspects be seen as a complex reactive system [15]. This complexity demonstrates itself not only in the \size" the system, but the number of concepts which are needed in order to describe it. Even adopting a unifying abstract perspective on the rm where it consists of a set of resources and processes which execute concurrently on such resources (see Figure 1). The resources include stocks, warehouses, shop oor etc. Activities include buying, selling and manufacturing products (from sub-products), expanding production capacities etc. Every process is like a sequential program which carries out such activities by means of sequential composition, recursion, conditionals, repetitions and alternatives. Conditionals and repetitions represent the internal choice between possible executions

processes resources buy

sell

5

produce

10 2

7

sub-products

Figure 1: Modelling a manufacturing enterprise, a unifying perspective. Report No. 137, April 15, 1998

UNU/IIST, P.O. Box 3058, Macau

Introduction

2

of a process, in terms of properties about the state of resources. Alternatives represent the external choice determined by the market which may or may not oer to buy or sell products. Addressing internal competition between processes for limited resources requires modelling of priorities and scheduling. Then there are issues how to represent concurrency among processes (non-interleaving), their executions separately (linear-time) or together (synchronous), nally interaction between dierent enterprises on the market (many-to-one synchronisation). Indeed, enterprise modelling is a demanding area. This is also an interesting area, stimulating extensions of formal description techniques in order to address adequately the issues speci cally about this domain. First, we cannot pretend that all activities inside the enterprise take place automatically, according to the pre-de ned set of processes. There are management decisions involved. We model such decisions as a choice between dierent executions of a process, which choice is neither resolved based on the resources, nor by the market, but left completely open in the model [5]. Second, a one-to-one synchronisation represents an exchange of products between a supplier and a consumer, total number of which remains the same before and after the synchronisation: a version of value-passing which aects not only the receiver (incrementing the stock) but the sender as well (decrementing the stock by the same value). Suppose E (n) represents an enterprise which holds n items of a product, its behaviour described by labelled or unlabelled (internal) transitions. Let E1 (n1 )jE2 (n2 ) represent two enterprises together, with possibility for exchange of products. Then we can illustrate this situation using structured transition rules below. enough stock? enough space? buy (d) 0 E (n) ) E (n + d) E (n) sell(d)) E 0 (n ? d) E1 (n1 ) buy(d)) E10 (n1 + d); E2 (n2 ) sell(d)) E20 (n2 ? d) E1 (n1 )jE2 (n2 ) ) E10 (n1 + d)jE20 (n2 ? d)

Third, a many-to-one synchronisation between a consumer and a set of suppliers creates the problem how to partition consumer demand, but also an opportunity to address competition and marketing in the model. Among the activities of an enterprise is advertising: levels of attributes for every product produced by a rm. Such attributes may include price, quality, aesthetics etc. There are corresponding weights assigned to the attributes when the rm acts as a consumer. Together, levels and weights of attributes allow consumers to calculate utility of products when purchased from dierent suppliers, and partition the demand proportionally [13]. This aects the execution of many-to-one synchronisation on the market, as well as allowing rms to in uence their share by marketing activities. We represent by utility(E; Ei ) this utility function when enterprise E buys products from the supplier Ei . We also use ni=1 Ei to represent n enterprises Ei, i = 1; : : : ; n, acting together. We illustrate this situation using the following

Report No. 137, April 15, 1998

UNU/IIST, P.O. Box 3058, Macau

Modelling an Enterprise transition rule:

P

3

P E (nbuy ) ( =1)d E) 0 (n + ni=1 di ) Ei (nPi ) sell(d )) Ei0 (ni ? di ); i = 1P; : : : ; n di =( ni=1 di ) = utility(E; Ei )=( ni=1Putility(E; Ei )); i = 1; : : : ; n E (n)jni=1 Ei (ni) ) E 0(n + ni=1 di )jni=1 Ei0 (ni ? di) n i

i

i

The rest of this paper consists of four sections. Section 2 provides a formal de nition the enterprise, in the form of its abstract model. Section 3 provides an example. Section 4 is about operational semantics: market-driven symbolic executions of enterprise models. Section 5 contains some conclusions. The formal notation used in this paper is a small fragment of RSL, the RAISE Speci cation Language [9]. Prior knowledge of RSL is not required.

2 Modelling an Enterprise We are interested in an enterprise which carries out manufacturing as an assembly of products from sub-products (a discrete-parts manufacturer). Modelling adopts a unifying perspective where many aspects of the rm are abstracted away. We consider respectively: products (Section 2.1), resources (Section 2.2), processes which execute sequentially operations on the resources (Section 2.3), sets of processes which execute concurrently (Section 2.4) and the enterprise itself (Section 2.5), where processes are given priorities and together they execute under a scheduler. We explain this \execution" semantics, but leave the formalisation until Section 3.

2.1 Products All products we are interested in are values of the abstract type Product; a type is a collection of values together with operations on them. We are only interested in some attributes of products that will be important for modelling of the enterprise. The rst is about conditions to store products, measured in some way by a function dim from products to numbers (encoding dimensions of the product etc.). The second attribute is the composition of a product from sub-products: how many items we need of each sub-product in order to assemble an item of the nal product. This sub-product relation is a map bill which given a product returns a map from (sub-)products to natural numbers; a map is similar to a partial function.

type

Product

value

dim: Product ! Nat, bill: Product ! m (Product ! m Nat)

Report No. 137, April 15, 1998

UNU/IIST, P.O. Box 3058, Macau

Modelling an Enterprise

4

Right now, bill can represent any value of the type given above. We constrain this value in two ways: no product is a sub-product of itself and every sub-product is itself included in the bill. We state those properties by the axiom below, in terms of the predicate issub(q,p) (q is a sub-product of p); pre precedes a pre-condition and post a post-condition in the de nition of a partial function; dom and rng are operators on maps which return their domain and range respectively.

axiom (8 p, q : Product  p 2 dom bill ) (issub(p,p) ^ (issub(q,p) ) q 2 dom bill)) )

value

 issub: Product  Product ! Bool issub(q,p)  q 2 dom bill(p) _ (9 r:Product  r 2 dom bill ^ issub(r,p) ^ issub(q,r)) pre p 2 dom bill

2.2 Resources Our resources include concrete investment of the enterprise in stocks, space (warehouses) and production capacity (shop oor), all of which are directly related to production. The stock represents how many items of each product are available in the warehouse, a map from products to natural numbers. As dierent products may have dierent storing conditions, \measured" by function dim, we represent the space as the maximum value of this function, summed up for all products and stocks (function dimall). Finally, we represent production capacity as a map from products to natural numbers: which products can be manufactured and how many items we can assemble within an agreed time period.

type

Space = Nat, Stock = Product ! m Nat, Trans = Product ! m Nat

value

dimall: Stock ! Nat dimall(s)  sum(fs(p)dim(p) j p:Product  p 2 dom sg)

On the other hand, resources also include information which is used to determine how the enterprise behaves on the market. Suppose we would like to distinguish between dierent brands of a product: the same product but sold by dierent rms. We do this by means of attributes like reliability, aesthetics, price etc., depending on the product. On the one hand every supplier Report No. 137, April 15, 1998

UNU/IIST, P.O. Box 3058, Macau

Modelling an Enterprise

5

assigns levels of attributes (say real numbers) to all products it wants to sell on the market; those numbers may represent say price in USD, reliability in the number of defects per 1000 items, aesthetics in the number of colours oered etc. On the other, every consumer assigns weights to the attributes (again, real numbers) to represent their importance. Together, weights and levels of attributes allow to make comparisons between dierent brands (function utility) and determine how the rm behaves on the market.

type

Attribute, Consumer = Attribute ! m Real, Supplier = Attribute  Product ! m Real

value

utility: Consumer  Supplier  Product ! Real utility(c,s,p)  sum(fc(a)s(a,p) j a:Attribute  a 2 dom c ^ (a,p) 2 dom sg)

Of course there are other enterprise resource that we can think of, de ning its state of possession and aecting the ways it behaves. Choosing to model only some of them is one way to decide on the level of abstraction, which level is actually sucient for the de nition of the semantics for the enterprise, as we shall see later. In a companion paper we discuss how this semantics can be naturally extended (re ned) by such additional resources. For now, we represent resources as a record which consists of ve elds: stock, space, production, consumer and supplier; a record is like a Cartesian product with functions for each eld to extract and modify the corresponding value. Our records are subject to a number of restrictions: the stock must not exceed the space or include products not in the bill, and production must not apply to products not included, or their sub-products not included, in the stocks. The type is de ned as a sub-type: a type constrained by a predicate.

type

Res :: stock : Stock space : Space trans : Trans con : Consumer sup : Supplier, Resources = fj r:Res  iswf(r)jg

value

iswf: Res ! Bool iswf(r)  dom stock(r)  dom bill ^ dimall(stock(r))  space(r) ^ (8 p,q:Product  p 2 dom trans(r) ) p 2 dom stock(r) ^ q 2 dom bill(p) ) q 2 dom stock(r) )

Report No. 137, April 15, 1998

UNU/IIST, P.O. Box 3058, Macau

Modelling an Enterprise

6

2.3 Processes Operating on the resources are functions which change their values, representing concrete operations in the warehouse, on the shop oor, extending or reducing capacities of both, as well as decisions about the sale and purchase of products. For buying, selling and producing we have corresponding functions which increase, decrease, or both increase (for nal product) and decrease (for sub-products) stocks. They are partial because they depend on the stock and space. For extending or reducing capacities of the warehouse and shop oor we have corresponding functions with an argument which is positive for expansion and negative for reduction. Again, they are partial because the result must not be negative and we cannot reduce the storage below the level of products we currently have on stock. Then there are total functions for changing weights and levels of attributes.

value

 Resources, expand store: Int  Resources !  expand prod: Product  Int  Resources ! Resources,  buy, sell, prod: Product  Nat  Resources ! Resources, change weights: Attribute  Real  Resources ! Resources, change levels: Attribute  Product  Real  Resources ! Resources

All functions act by modifying the corresponding elds of the record of resources but this eect is only formalised in Section 3. Deciding which activities should be carried out and in which order is the task of a process. A process is like a \program" which executes not on the computer but on the enterprise resources. More than just a sequence of activities, the process can test the state of resources, e.g. if the stock is greater than given number, if the space can accommodate given number of items. . . Or involve a human decision, the outcome of which cannot be resolved based on the resources alone (which does not mean that we cannot represent them in the model). Tests can also apply usual propositional constants and connectives. The type of tests is a union type, specifying alternative ways to build tests, starting from the basic ones which are simply predicates on the resources.

type

Pred = Resources ! Bool, Test == basic(Pred) j human j tt j  j not(Test) j and(Test,Test) j or(Test,Test)

A process is one of resource-consuming activities which we de ned before: buying, selling or producing, expanding or reducing space or production capacities, changing weights or levels of attributes. . . We represent all such activities as operations from resources to resources, expanded into sets of operations, one for every allowed value of the arguments. A process can be halted, a sequential or conditional execution of two processes (depending on the outcome of a test), an Report No. 137, April 15, 1998

UNU/IIST, P.O. Box 3058, Macau

Modelling an Enterprise

7

alternative execution which lets the environment decide on the execution of one of the processes, or an execution which repeats a process as long as given test remains true. A process may also behave like some other process, here referred to only by name. This allows de nitions by recursion where a process refers to itself, or by mutual recursion. Function names returns the set of names inside a process. The meaning of all constructors is de ned formally in Section 3.

type

Name, Oper = Resources ! m Resources, Process == halt j basic(Oper) j rec(Name) j seq(Process,Process) j alt(Process,Process) j test(Test,Process,Process) j loop(Test,Process)

value

names: Process ! Name-set names(p)  case p of rec(n) ! fng, basic(op) ! fg, seq(p1,p2) ! names(p1) [ names(p2)

:::

end

2.4 Enterprise Assume we have a set of de nitions for process names, so that every name inside the de nition refers to one of the de nitions in the set, perhaps itself.

type

Defs = Name ! m Process, De nitions = fj d:Defs  iswf(d) jg

value

iswf: Defs ! Bool iswf(d)  (8 p:Process, n:Name  p 2 rng d ^ n 2 names(p) ) n 2 dom d )

An enterprise consists of a set of processes which are running concurrently on the shared resources, sometimes competing for them. Unlike on the market, we can control this competition in order to ensure the best use of the resources. We do so by means of priorities assigned to every running process. Technically, we use a sequence to represent a set of processes running in the Report No. 137, April 15, 1998

UNU/IIST, P.O. Box 3058, Macau

Modelling an Enterprise: Example

8

enterprise together with their priorities: the earlier in sequence the higher the priority. A simple extension to this model could de ne priorities as part of the resources, and designate a process which acts like a scheduler. Priorities are a true management decision about the importance of activities in the enterprise. The resources, the set of de nitions for names and the list of processes (with priorities) together \de ne" the enterprise.

type

Ent:: res: Resources def: De nitions prc: Process , Enterprise = fj e:Ent  iswf(e) jg

value

iswf: Ent ! Bool iswf(e)  (8 p:Process, n:Name  p 2 elems prc(e) ^ n 2 names(p) ) n 2 dom def(e) )

This provides a general \structure" for abstract description of enterprises. Concrete instances can be de ned as values of this type, e.g.

value

ABCompany: Enterprise

3 Modelling an Enterprise: Example Consider a small example. Suppose we have products p(i) where i is a natural number and p(i) is the only sub-product of p(i + 1) with quantity i, for all i.

value p: Nat ! Product axiom forall i:Nat  p(i) 2 dom bill ^ bill(p(0))=[ ] ^ bill(p(i+1))=[ p(i)7!i ] Suppose we have enterprises e(i), each holding stock for two products p(i) and p(i+1), and able to produce p(i+1) only. Enterprise e(i) consists of two processes which compete for the stock of p(i): s1(i) and s2(i); in this order of priority. Report No. 137, April 15, 1998

UNU/IIST, P.O. Box 3058, Macau

Modelling an Enterprise: Example

9

value e: Nat ! Enterprise, s1,s2: Nat ! Process axiom forall i:Nat  prc(e(i))  hs1(i),s2(i)i, dom trans(res(e(i)))  fp(i+1)g, dom stock(res(e(i)))  fp(i),p(i+1)g The aim of s1(i) is to repeatedly sell one item of p(i+1), until the number reaches n(i). If the stock is empty, it tries to produce this item from p(i). If the stock for p(i) is too low, it waits. s1(i) is de ned by recursion, using de nitions for process names a(i,j) where j is the number of items which remain to be sold.

value n: Nat ! Nat, a: Nat  Nat ! Name axiom forall i,j:Nat  s1(i)  rec(a(i,n(i))), dom def(e(i))  fa(i,j) j j:Nat  jn(i)g, j=0 ) (def(e(i))(a(i,j))  halt), j>0 ) (def(e(i))(a(i,j))  test(isempty(p(i+1)),

seq(prod(p(i+1),1),rec(a(i,j))), seq(sell(p(i+1),1),rec(a(i,j?1)))))

s2(i) tries of p(i+1).

to keep the stock for p(i) at all times greater than i, required to produce one item It is also willing to sell p(i), if this is possible. The choice between buying and selling is resolved by the environment.

axiom forall i:Nat  s2(i)  loop(tt,test(ismore(p(i),i),sell(p(i),1),alt(buy(p(i),i),sell(p(i),1)))) If we put together all e(i) then there is a possibility for exchange of products: p(i) between e(i-1) and e(i), and p(i+1) between e(i) and e(i+1). In order to supply one item of p(i), a demand will propagate down the sequence, resulting in the factorial demand i! for p(0) which must be bought on the market.

Report No. 137, April 15, 1998

UNU/IIST, P.O. Box 3058, Macau

Semantics of an Enterprise: Symbolic Execution

10

4 Semantics of an Enterprise: Symbolic Execution The de nition of the enterprise in Section 2 is formal, written down in the language which has both precise syntax and formal semantics. In fact, we can also reason about this de nition using the proof system which underlies RSL. Yet, formality obtained by translation of the enterprise value (say ABCompany) into the semantics of RSL is on the level where its concrete interpretation, as the enterprise, has been lost altogether. In this section we aim to give semantics to enterprise descriptions in a way to \preserve" this interpretation, with respect to our so-far informal explanations. We de ne operational semantics for enterprise models as they execute symbolically among other enterprises, together comprising a market. We follow the steps for: basic operations on the resources (Section 4.1); testing the resources (Section 4.2); a process which puts together tests and operations for sequential execution (Section 4.3); an enterprise which executes its processes concurrently and according to their priorities (Section 4.4); a set of enterprises which proceed with own activities independently or exchange products between themselves. We consider one-to-one (one supplier one consumer) and manyto-one (many supplier one consumer) exchange of products, where suppliers compete with each other to take the best share of the demand by the consumer (Section 4.5).

4.1 Operations In Section 2.3 we listed nine basic operations on the resources, as used in the de nition of a process, for buying, selling and manufacturing products, expanding production and storage capacities and for implementing marketing decisions. We only speci ed those operations by their signatures. Now we de ne their semantics, in particular the semantics of the rst three operations. Selling decrements the stock for the product, provided there is enough items:

axiom forall p:Product, n:Nat, r:Resources  p 2 dom stock(r) ^ stock(r)(p)n ) stock(sell(p,n,r))(p) = stock(r)(p)?n Buying increments the stock for the product, provided there is enough space:

axiom forall p:Product, n:Nat, r:Resources  p 2 dom stock(r) ^ dimall(stock(r))+ ndim(p)space(r) ) stock(buy(p,n,r))(p) = stock(r)(p)+n

Report No. 137, April 15, 1998

UNU/IIST, P.O. Box 3058, Macau

Semantics of an Enterprise: Symbolic Execution

11

Production does both. It increments the stock for the nal product and decrements stocks for all immediate sub-products, according to the bill. There must be enough space in the warehouse for items of the nal product, enough stock to manufacture those number of items, and enough production capacity.

axiom forall p:Product, n:Nat, r:Resources  n  trans(r)(p) ^ p 2 dom trans(r) ^ dimall(stock(r))+ ndim(p)  space(r) ^ (8 q:Product  q 2 dom bill(p) ) stock(r)(q)nbill(p)(q) )

) stock(prod(p,n,r))(p) = stock(r)(p)+n ^ (8 q:Product  q 2 dom bill(p) ) stock(prod(p,n,r))(q) = stock(r)(q)?nbill(p)(q) )

Semantically, we expand every such operation which takes arguments into sets of basic operations one operation per every con guration of the allowed arguments, as used in the de nition of a process. Resources -> Resources,

4.2 Tests A process also applies tests on the state of resources, expanded by management decisions (value human). The latter make it dicult to actually \execute" the test. In order to avoid this problem we represent such management decisions by function man from the type Unit to Bool. Unit is a pre-de ned type with only one value written as (), used to de ne imperative functions which depend upon and aect some variables. On two dierent invocations man can return dierent values.

value

 man: Unit ! Bool

Given this completely under-speci ed function we are able to \execute" tests on given state of resources, the result of which is either true or false. This execution proceeds on the structure of tests, as below.

Report No. 137, April 15, 1998

UNU/IIST, P.O. Box 3058, Macau

Semantics of an Enterprise: Symbolic Execution

12

value

 test: Test  Resources ! Bool test(t,r)  case t of tt ! true,  ! false, human ! man(), basic(p) ! p(r), not(t1) ! test(t1,r), and(t1,t2) ! test(t1,r) ^ test(t2,r), or(t1,t2) ! test(t1,r) _ test(t2,r)

end

4.3 Processes Given semantics of tests and basic operations we are at last prepared to give the meaning to the de nition of a process. Because of recursion, we must take into account de nitions for free names. Because of tests we must also take into account the current state of resources. The semantics takes the form of a labelled transition relation which represents all one-step executions of a process. We represent this relation by function step which returns the set of operations a process can perform initially and for each of them the set of possible continuations (another process).

value

 step: Process  De nitions  Resources ! (Oper ! m Process-set)

We proceed to de ne this function on the structure of the process. There is no transition for a process which is halted. For a basic operation there is one transition labelled by this operation and one continuation: halt.

axiom

step(halt,d,r)  [ ], step(basic(op),d,r)  [ op7!fhaltg ]

A process de ned by sequential composition has all transitions of the second process if the rst has terminated (it has no transitions), otherwise all transitions of the rst process, with continuations combined sequentially with the second.

Report No. 137, April 15, 1998

UNU/IIST, P.O. Box 3058, Macau

Semantics of an Enterprise: Symbolic Execution

13

axiom

step(seq(p1,p2),d,r)  let s=step(p1,d,r) in if s=[ ] then step(p2,d,r) else [ op7!seqset(s(op),p2) j op:Oper  op 2 dom s ] end

value

end

seqset: Process-set  Process ! Process-set seqset(ps,p2)  fseq(p1,p2) j p1:Process  p1 2 psg

An alternative between two processes has transitions of both of them. If an operation is possible for both, we sum up possible sets of continuations, otherwise we take the union of the disjoint maps:

axiom

step(alt(p1,p2),d,r)  let s1=step(p1,d,r), s2=step(p2,d,r) in s1ndom s2 [ s2ndom s1 [ [ op7!s1(op) [ s2(op) j op:Oper  op 2 dom s1 \ dom s2 ]

end

Transitions of a conditional test(t,p1,p2) depend on the satisfaction of a test t. If t holds then we have all transitions of p1, otherwise all transitions of p2.

axiom

step(test(t,p1,p2),d,r)  if test(t,r) then step(p1,d,r) else step(p2,d,r) end

Transitions of a loop loop(t,p) also depend on the satisfaction of a test t. If t holds, these are all transitions of seq(p,loop(t,p)), a sequential composition of p and the loop itself, otherwise the set of transitions is empty.

axiom

step(loop(t,p),d,r)  if test(t,r) then step(seq(p,loop(t,p)),d,r) else [ ] end

A recursive process referring to a name has all transitions of a process which is a de nition for this name. The name must actually exist among the de nitions. Report No. 137, April 15, 1998

UNU/IIST, P.O. Box 3058, Macau

Semantics of an Enterprise: Symbolic Execution

14

axiom

step(rec(n),d,r)  step(d(n),d,r) pre n 2 dom d

4.4 Enterprise Consider an enterprise, with its resources and a set of processes which execute concurrently on those resources. The aim of this section is to de ne one-step executions of an enterprise, in the form of a function exec below. The function represents labelled transitions between enterprises, as carried out concurrently by their processes [12]. One enterprise represents the initial state, another is the nal state, the label represents the set of operations which are responsible for the transition. We present this label as a map from process numbers (as in the sequence) to operations.

value

exec: Enterprise  (Nat ! m Oper)  Enterprise ! Bool

Before we de ne this function we must determine what combinations of initial operations are possible. In principle, we can have any combination of initial operations performed by every or only some of processes of the enterprise; inds and elems apply to a sequence and return the set of indices and the set of elements respectively.

value

oered: Enterprise  (Nat ! m Oper) ! Bool oered(e,os)  dom os  inds prc(e) ^ (8 n:Nat  n 2 dom os ) os(n) 2 dom step(prc(e)(n),def(e),res(e)) )

While there may be many such combination, many will also violate priorities assigned to processes, by including an operation of a lower-priority process but excluding an operation of a higher-priority process. This can only be the case if the higher-priority process has no operations.

value

 scheduled: Enterprise  (Nat ! m Oper) ! Bool scheduled(e,os)  (8 n:Nat  n 62 dom os ^ n 2 inds prc(e)

Report No. 137, April 15, 1998

UNU/IIST, P.O. Box 3058, Macau

Semantics of an Enterprise: Symbolic Execution

15

) step(prc(e)(n),def(e),res(e))=[ ] _ (8 m:Nat  mn ) m 62 dom os) ) pre oered(e,os) A combination can be oered by processes, also allowed by priorities assigned to them, yet there may not be enough resources for it to actually take place. Not only we need resources to perform each operation separately, we need resources to perform them altogether, as a single concurrent operation. Technically, we apply component operations in any order, represented by an implicit let expression which takes any value of given type as long as this value satis es a predicate:

value

 Resources exec con: Oper-set  Resources ! exec con(os,r)  let s:Oper  elems s = os in exec seq(s,r) end pre feasible(os,r), exec seq: Oper  Resources ! Resources exec seq(s,r)  if s=hi then r else exec seq(tl s,(hd s)(r)) end pre de ned(s,r)

Then the result need not depend on the order we choose to perform such operations. It cannot be the case that one operation depends upon and makes use of the resources which are produced by another, which happened to be performed rst. There must be enough resources to execute operations simultaneously. Feasibility for concurrent execution of operations includes a test for de nedness for any sequence of executions, and for equal results for any two execution sequences:

value

feasible: Oper-set  Resources ! Bool feasible(os,r)  (8 s:Oper  elems s=os ) de ned(s,r)) ^ (8 s1,s2: Oper  elems s1=os ^ elems s2=os ) exec seq(s1,r)=exec seq(s2,r) ), de ned: Oper  Resources ! Bool de ned(s,r)  s=hi _ (r 2 dom (hd s) ^ de ned(tl s,(hd s)(r)))

It is now possible to de ne one-step executions of the enterprise, labelled by sets of operations which are: oered by its processes, scheduled according to their priorities and feasible for concurrent execution on given resources. The result is an enterprise which de nitions are unchanged, resources are transformed by concurrent execution of operations, and processes either remain unchanged (if they didn't contribute to the operations) or reach new states. A new state is chosen from possible continuations (as de ned in step) or is a halted state if there are no continuations.

Report No. 137, April 15, 1998

UNU/IIST, P.O. Box 3058, Macau

Semantics of an Enterprise: Symbolic Execution

16

value

exec: Enterprise  (Nat ! m Oper)  Enterprise ! Bool 0 exec(e,os,e )  oered(e,os) ^ scheduled(e,os) ^ feasible(rng os,res(e)) ^ def(e0) = def(e) ^ 0 len prc(e ) = len prc(e) ^ 0 res(e ) = exec con(rng os,res(e)) ^ (8 n:Nat  n 2 inds prc(e) ) let s=step(prc(e)(n),def(e),res(e))(os(n)) in if n 62 dom os then prc(e0)(n) = prc(e)(n) else if s=fg then prc(e0)(n)=halt else prc(e0)(n) 2 s end end )

end

Suppose for every operation we can produce a map from products to non-zero integers, representing external requirement for products which must be bought (positive) or sold (negative number) in order for the operation to take place; the function is extended into sets of operations.

value

req: Oper ! (Product ! m Int), sumreq: Oper-set ! (Product ! m Int)

axiom (8 op:Oper  0 62 rng req(op))

This allows us to describe an abstract version of the execution function, which summs up all external requirements for operations and puts them explicitly at the label. Empty map represents the internal transition which can be performed without participation from the environment. For simplicity, we only consider transitions which operations are either internal or all relate to one and the same product. If two processes require dierent products, they cannot progress simultaneously but must be interleaved according to their priorities.

value

absexec: Enterprise  (Product ! m Int)  Enterprise ! Bool 0 absexec(e,pm,e )  (9 om: Nat ! m Oper  exec(e,om,e0) ^ pm = sumreq(rng om) ^ card(dom pm)