Modelling Reactive Objects in Conceptual Graphs

Modelling Reactive Objects in Conceptual Graphs Gerard Ellis, Steve Callaghan and James Ricketts*

Computer Science Department Royal Melbourne University of Technology GPO Box 2476V, Melbourne, Victoria, 3001, AUSTRALIA * Baker Medical Research Institute, Prahran, Victoria, 3181, AUSTRALIA Email:

fged, s932073, [email protected]

Abstract Conceptual graphs are a general purpose knowledge representation language which can be used for program speci cation. Conceptual graphs are a uni ed diagramming tool which subsume most conventional special-purpose diagrams such as entity-relationship models, nitestate machines, petri-nets, data ow diagrams, parse trees, type hierarchies, ow charts and state-transition diagrams. We illustrate some object-oriented concepts such as inheritance, polymorphism and encapsulation in a case study of a vending machine. Some reasons for using conceptual graphs for program speci cation include the possibility of execution, formal semantics, simple and intuitive modelling.

1 Introduction In this paper, we show that the conceptual graph knowledge representation [13] can be used as a formal program speci cation tool which allows concise and intuitive speci cations to be written which can be executed in a graphical object oriented logic programming language. Conceptual graphs are a graphic system of logic that is as general as predicate calculus, but also as readable as special purpose diagrams [15].

In 1896, Charles Sanders Peirce developed existential graphs [12] as an alternative to the linear notation for predicate calculus. John Sowa [13] combined existential graphs with modern research in semantic networks to develop conceptual graphs. An annual conference on conceptual structures is dedicated to discussing research issues and applications of conceptual graphs [9, 16]1. Conceptual graphs have been used for natural language processing, data modelling, machine learning, information retrieval, temporal reasoning, reasoning, and programming. Sowa [15] showed that many of the existing popular diagram notations can be viewed as special cases of conceptual graphs: type hierarchies, entity-relationships diagrams, parse trees, data ow diagrams, ow charts, state-transition diagrams, and Petri nets. The ability of conceptual graphs to subsume almost all conventional special-purpose diagram notations makes it a uni ed diagramming tool for research in many areas of computer science. The ANSI X3H4 committee on Information Resource Dictionary Services (IRDS) has proposed conceptual graphs as a standard normative schema language for integrating heterogeneous modelling languages, modelling paradigms, and database languages [10]. The ANSI X3T2 Data Interchange and Repositories committee is using the Knowledge Interchange Format (KIF) report [7] as a base document. Developers of KIF, and conceptual graphs have agreed to adopt There is also a conceptual graph mailing list with over 300 subscribers [email protected], subscription to [email protected]. 1

(a)

(b)

VendingMachine

Vending Machine: #45221

(c) Number: 3

GT

Number: 4

(d) 5 2

1

(e) Minus

3 p

2

q

(f) Can

Cans

Thing: Brand

Set: Thing: @forall

Can

(g) Coin

Coins

Thing: Value

Set: Thing: @forall

Coin

Figure 1: Basic conceptual graph building blocks and declarations the KIF model-theoretic foundations as common semantics. The ANSI X3J21 Formal Description committee will examine the common logical foundations for Vienna De nition Methodology (VDM) and the Z speci cation language in order to establish a common basis to be shared with KIF and conceptual graphs. Section 2 brie y introduces the conceptual graph notation. In section 3, the vending machine object and methods are described at a high level, then each of its subobjects and their methods are described in sections 4, 5, 6 and 7. Section 8 gives an example of reasoning with the vending machine speci cation, and section 9 brie y describes a graphic object-oriented logic programming language which can be used to make conceptual graph speci cations executable.

2 Conceptual Graph Tutorial A conceptual graph is a connected bipartite graph consisting of concept and relation nodes. A concept is represented as a box. For example, Figure 1(a) is a generic concept meaning \some vending machine". Figure 1(b)) represents an individual concept meaning \the vending machine". Relations are denoted by ellipses. Figure 1(c) shows the binary relation

"greater than" and represents "the number 3 has a greater than which is the number 4". Figure 1(d) shows a ternary relation minus which means 5 minus 2 is 3. The arcs are numbered indicating the argument position. The nth argument is not numbered as it always points away from the relation. In this example, the type Number has been omitted for brevity. Figure 1(e) represents \p implies q" where p and q are meta-variables representing some conceptual graph. The notation is similar to Peirce's Existential Graph notation [12] using negation boxes meaning \not (p and not(q))". Concepts and relations may be de ned in terms of other concepts and relations. Figure 1(f) shows the de nition of concepts Can and Cans. The double-box notation means that the proposition in the top box is equivalent to the proposition in the lower box. A Can is a Thing with a part Brand. Here PartOf is shown by including the part in the concept context. Here the dotted line indicates concepts are coreferent, that is, the same. The de nition could be translated to a lambda expression C an(x) = T hing (x) ^ P artOf (x; y ) ^ Brand(y ). Cans is a set where every Thing which is a member is a Can. Here membership of a set is shown as containment in the set context. The macro @forall can be translated into a conceptual graph similar to Figure 1(e) where p is Thing and q is Can and there is a line of identity between Thing and Can. Similarly, Coin and Coins can be de ned as in Figure 1(g).

3 Vending Machine In this paper a vending machine case study will be used to illustrate the modelling techniques of conceptual graphs. The VendingMachine [1] has been studied in some detail in languages such as Object-Z [2]. Figure 2 gives an informal picture of a vending machine. Figure 3 formally de nes a VendingMachine as a Thing consisting of objects PriceList, TempCoinBuer, CanStore and CoinStore; and methods InsertCoin, ReturnCoins and ReturnCan. Figure 4 contains de nitions of InsertCoin and ReturnCoins methods on a VendingMachine. The notation used outlined in Figure 5(a) is

Coin

(a) Price List

Coin Buffer

Insert

Selection Panel

Return

Input Object:

Can Store

Method

Output

Coin

Coins

Brand

Return Can

Store

Object:

(b) Input

Coin

Event:

Method

Output

Object

Object

(c) Coin Outlet

Object

Can Outlet Coins

Can

Succ

Event

Succ

Object

Figure 5: Method schema notation

Figure 2: A informal diagram of a vending machine VendingMachine

Coin

ReturnCoins

Coins

Coins

Coins

TempCoinBuffer :

Can

DumpCoins

VendingMachine:

ReturnCan

TempCoinBuffer

Event:

CoinStore

VendingMachine:

Coins

Vending Machine:

ReturnCoins

TempCoinBuffer

Event:

AddCoin

Vending Machine:

TempCoinBuffer

VendingMachine:

DispenseChange

Event:

CanStore

VendingMachine:

Coin

CoinStore

InsertCoin

TempCoinBuffer

Figure 3: A conceptual graph speci cation of a vending machine

Brand

Coins

Dispense

Can

AddCoins

DumpCoins

ReturnCan

Event:

CoinStore

Coins

Brand

CanStore

InsertCoin

CoinStore

CanStore

Vending Machine:

TempCoinBuffer

ValidChange

PriceList

Number

TempCoinBuffer

Thing:

EmptySet

Figure 4: Vending Machine method de nitions for ReturnCoins and InsertCoin

Figure 6: A Vending Machine ReturnCan method de nition

Brand

ValidChange

Number

Vending Machine: PriceList

Can Store Event:

GetPrice

TempCoinBuffer CoinStore

Number Value

2

Minus 1

Vending Machine:

Number

Thing: Cans Brand

Dispense

Can

CanMakeChange

Figure 7: A ValidChange Method of a VendingMachine

Brand

Can Store: Event: Cans

shorthand for a method applying some inputs to an object to get some output and change of object state by some event (Figure 5(b). That is, the method is describing the sequence of Object state, Event, (new) Object state as shown in Figure 5(c). The leftmost object state contains preconditions for the method. The event contains the methods or relationships between the old object state and new. When a Coin is inserted into a VendingMachine, this is a InsertCoin message which the VendingMachine relays to the TempCoinBuer to add the Coin to the TempCoinBuer to get the new TempCoinBuer in the new VendingMachine state. When a VendingMachine receives a ReturnCoins message, it sends a DumpCoins message to the TempCoinBuer which results in dumping all of the Coins in the temporary storage to the external CoinOutlet and resulting in a VendingMachine with an empty TempCoinBuer. Figure 6 is a de nition of the ReturnCan method which returns a Can of a given Brand and some Coins which is the change from the coins inserted. When a VendingMachine receives a ReturnCan message, it checks preconditions that there is appropriate change for the transaction, that the Brand is available from the CanStore. The VendingMachine then sends messages to the CanStore to Dispense a Can of the given Brand and a message to the TempCoinBuer to DumpCoins which are added to the CoinStore using AddCoins. The VendingMachine then sends a message to the CoinStore to DispenseChange for the given Number resulting in Coins. This de nition shows how objects can manage subobjects in conceptual graphs. Figure 7 shows the VendingMachine method ValidChange which checks that there are sucient Coins in the TempCoinBuer to pay for

Can: Brand

Dispense

Can Store:

Delete

Cans

Figure 8: A de nition of a CanStore and Dispense Method CoinBuffer Thing:

Value

0..Limit

Size

Number

Coins CoinBuffer:

Value

Number

EmptySet

Value

OneOrMoreCoins 1 Delete

Coins

Coins

Value

0 Value

Number

2 Coin: Value Value

Plus

Number

Figure 9: A general CoinBuer and Value method the Price (Number is a natural, that is an nonnegative integer) of the given Brand and that the CoinStore CanMakeChange of the amount Number.

4 CanStore Figure 8 de nes a CanStore as some Cans and a Dispense method. A Dispense message tells the CanStore to Delete a Can of a given Brand.

5 TempCoinBuer The two objects within the VendingMachine which deal with coins are the TempCoinBuer and the CoinStore. Both these concepts are derived from a superconcept CoinBuer (Figure 9). A CoinBuer consists of some Coins and a Limit on the number of Coins that can be

TempCoinBuffer CoinBuffer: AddCoin

Coin

DumpCoins

Coins

AddCoin

Coin

TempCoinBuffer: Event: Coins

TempCoinBuffer: Coins

Add

DumpCoins TempCoinBuffer: Event: Coins

Coins TempCoinBuffer: Coins

EmptySet

Figure 10: A TempCoinBuer with AddCoin and DumpCoins methods stored. A CoinBuer supports Value message which outputs the value of the Coins. Value of Coins is de ned recursively: the base case returning zero for the EmptySet of coins; the recursive case being the Value of one Coin Plus the Value of the rest of the Coins (resulting from Deleting the Coin). A TempCoinBuer is the receiver of coins within the VendingMachine. The TempCoinBuer is usually not visible externally. Figure 10 de nes a TempCoinBuer as a CoinBuer which can AddCoin and DumpCoins. The AddCoin method adds a Coin given to the Coins in the TempCoinBuer (which by deduction must not already be full). When a TempCoinBuer receives a DumpCoins message, it outputs all of its Coins, resulting in a TempCoinBuer with no Coins.

6 CoinStore Figure 11 de nes a CoinStore as a kind of CoinBuer which has methods AddCoins, CanMakeChange and DispenseChange. The AddCoins method is used to take the Coins dumped from the TempCoinBuer, it adds all of the input Coins to its set of Coins. The CanMakeChange method checks there are a subset of Coins in the CoinStore whose value is Number. The DispenseChange method returns a set of Coins which have a Value Number.

CoinStore CoinBuffer:

AddCoins

CanMakeChange Number

Union

CanMakeChange CoinStore:

Subset

Number CoinStore: Coins

Coins

Coins

CoinStore: Event:

Coins

Number

DispenseChange

AddCoins

Coins

Coins

CoinStore: Coins

Number Event: CoinStore:

Value Coins

Coins

DispenseChange

Value Union

Event:

CoinStore: Coins

Figure 11: A de nition of a CoinStore and its DispenseChange method

Brand: Fanta Coin: #213567

7 PriceList

PriceList: #79188 TempCoinBuffer:

Brand: Coke Brand: Coke

Can: #789928

ReturnCan

Coins:

Value: 50

Coin: #312067

Value: 20

Coin: #539882

Value: 20

Coin: #664243

PriceList: #79188

VendingMachine: #1234567

Price: 105

Brand: Fanta

Brands:

Price: 110

TempCoinBuffer:

EmptySet

CoinStore: #37799

Brand: Coke

CanStore: #86029

Coin: #213567

Value: 200

Cans:

Brand: Coke

Can: #789912

Brand: Fanta

Can: #789888

Figure 13 shows a sample execution of the speci cation for a vending machine that goes through the sequence of messages of inserting a $2 Coin and then selecting a Can of Coke. Initially, the VendingMachine has three Cans of drink in its CanStore: two Cans of Coke and one of Fanta. There are three Coins in the CoinStore: two 20 cent pieces and a 50 cent piece. The Price of Coke is $1.10 and Fanta is $1.05. The TempCoinBuer is empty. Then a user inserts a $2 Coin into the machine, which gets added to the TempCoinBuer in the change of state. The user then selects a Can of Coke. The VendingMachine checks that the $2 Coin is sucient to purchase a Can of Coke, which is $1.10 leaving 90 cents change. There is 90 cents change in the CoinStore, so the Coke can be Dispensed. The $2 Coin in the TempCoinBuer is dumped into the CoinStore. Figures 14 and 15 show the execution of the ReturnCan message in more detail. The preconditions for this are that the CoinStore has the

Coins:

8 Reasoning with Conceptual Graph Speci cations

Brands:

The PriceList (Figure 16) is a set of tuples Brand and Price in cents, Brand being the determinant. It includes also the GetPrice method. The GetPrice method simply returns the Price for the speci ed Brand.

EmptySet

InsertCoin

Figure 12: A de nition of PriceList and its GetPrice method

VendingMachine: #1234567

Brand: Coke

Brand: Price

TempCoinBuffer:

Coin: #213567

Value: 200

Event: PriceList:

PriceList: #79188

Brand: Fanta

Price: 105

Price

Brands:

Brand: Coke

Price: 110

CoinStore: #37799

Value: 200

CanStore: #86029

Price: 105

CoinStore: #37799

Price: 110

CanStore: #86029

Coin: #312067

Coins:

Value: 50

Can: #789928

Brand: Coke

Coin: #539882

Brands:

Cans:

Value: 50

Can: #789912

Value: 20

PriceList:

Coin: #312067

Brand: Coke

Coin: #539882

Brand: Coke

Coin: #664243

GetPrice

Coins:

Can: #789912

Value: 20

Can: #789888

Brand

Can: #789928

Brand: Coke

Coin: #664243

Price

Cans:

Can: #789888

Price

Value: 20

GetPrice

Brand: Fanta

Brand

Value: 20

Brands: Brand:

Brand: Fanta

Thing:

VendingMachine: #1234567

PriceList:

Figure 13: A conceptual graph movie of a VendingMachine

CoinStore: #37799

Coin: #312067

Value: 50

Value: 20

Coin: #664243

Value: 20

Coins: Number : 90

Coin: #213567

Value: 200 Value: 20

CanStore: #86029 CoinStore: #37799

Cans:

Can: #789928

Brand: Coke Value: 50

Can: #789912

Brand: Coke

Can: #789888

Brand: Fanta

PriceList: #79188

Brands:

Brand: Coke Brand: Fanta

Price: 110 Price: 105

Coins: GetPrice

Number: 110 Number: 200

1 2 Minus

Coin: #539882

CanMakeChange

DumpCoins

Coin: #539882

Value: 20

Coin: #664243 Value: 200

Value: 20

VendingMachine:

TempCoinBuffer:

Coins:

Coin: #213567

Value: 200

Value

Brand: Coke

ValidChange

Number : 90

VendingMachine:

Coin: #664243 Value: 20

Coins:

Coin: #312067

AddCoins

Coins:

Coin: #213567

TempCoinBuffer: EmptySet

CanStore: #86029 Cans: Can: #789912 Brand: Coke

Can: #789888 Brand: Fanta

Value: 50

Coin: #539882 Value: 20

Coin: #664243

Dispense Value: 20

Conceptual Graphs is an executable speci cation language. The upper graph in Figure 16 illustrates the well-known recursive program for factorial. The concept N1 stands for numbers in f1, 2, 3, ...g. The concept N2 stands for numbers in f2, 3, ...g. The factorial program (Fact) is de ned for numbers greater than 0 in this case. The base case is Fact(1) = 1. The recursive case is Fact(n) = n*Fact(n-1). The second graph in Figure 16 shows a sample execution of Fact(3). The trace involves unfolding the relationships between the tuples in the Fact function. This example illustrates how conceptual graphs can be implemented using traditional logic program techniques. In the Peirce project [3, 5, 8, 4], work is ongoing in developing a graphic logic programming language based on conceptual graphs which is further detailed in [6].

TempCoinBuffer:

9 Programming in Conceptual Graphs

ValidChange

Coins required to give the change ie the dierence between the Value of TempCoinBuer and the Price of the selected Brand. These are in this case satis ed. The TempCoinBuer dumps its only Coin which is then added to the CoinStore. The CanStore Dispenses a Can of the selected Brand deleting it from its store of Cans. The CoinStore then Dispenses Change for 90 cents deleting the 50 cent and the two 20 cent Coins from its store.

VendingMachine:

Figure 14: Preconditions for the ReturnCan message

Brand: Coke Brand: Coke

ReturnCan

Coins: Coin: #312067 Value: 50

VendingMachine: PriceList: #79188 Brands:

Coin: #539882 CoinStore: #37799 Coins:

Value: 200 CanStore: #86029

Coin: #312067 Cans:

DispenseChange Can: #789912 Brand: Coke

Can: #789888 Brand: Fanta

TempCoinBuffer:

Brand: Coke Brand: Fanta

EmptySet

Price: 110 Price: 105

Coin: #213567 CoinStore: #37799 Coin: #213567 Value: 200

Figure 15: A conceptual graph movie of a ReturnCan message

Can: #789928

N1 1

Fact Fact

N1 1

N2

Fact

-1 N1

3

Fact

-1

N2

* Fact

N1

6

* 2

Fact

-1

2

* 1

Fact

1

Figure 16: A conceptual graph program

10 Summary Conceptual graphs are a general purpose knowledge representation language which can be used for program speci cation. We have illustrated some object-oriented concepts such as inheritance, polymorphism and encapsulation in a case study of a vending machine. Some reasons for using conceptual graphs for program speci cation include the possibility of execution, formal semantics, simple and intuitive modelling.

References [1] Roger Duke, Cecily Bailes, and Graeme Smith. Modelling reactive objects. Technical Report 93-1, Software Veri cation Research Centre, The University of Queensland, 1993. [2] Roger Duke, Paul King, Gordon Rose, and Graeme Smith. The Object-Z speci cation language. In Technology of Object-Oriented Languages and Systems: TOOLS 5, pages 465{483. Prentice-Hall, 1991. [3] Gerard Ellis and Robert Levinson. The birth of Peirce: A conceptual graphs workbench. In Heather D. Pfeier and Timothy E. Nagle, editors, Conceptual Struc-

tures: Theory and Implementation, number 754 in Lecture Notes in Arti cial Intelligence, pages 219{228. Springer-Verlag, 1992. Proceedings of the Seventh Annual Workshop on Conceptual Graphs, Las Cruces, New Mexico, July 8-10, 1992.

[4] Gerard Ellis and Robert Levinson, editors. Proceedings of the 3rd International Workshop on Peirce: A Conceptual Graphs Workbench, University of Maryland, August 19 1994. available by anonymous ftp ftp.cs.uq.oz.au, /pub/peirce/peirce94.ps.Z. [5] Gerard Ellis and Robert A. Levinson, editors. Proceedings of the First International Workshop on Peirce: A Conceptual Graphs Workbench, Las Cruces, New Mexico, July 10 1992. available by anonymous ftp ftp.cs.uq.oz.au, /pub/peirce/peirce92.ps.Z. [6] Gerard Ellis, Robert A. Levinson, and Peter J. Robinson. Managing complex objects in Peirce. International Journal on Man-Machine Studies, 1994. Special Issue on Object-Oriented Approaches in Arti cial Intelligence and Human-Computer Interaction. [7] Michael R. Genesereth, Richard E. Fikes, Daniel Bobrow, Robert MacGregor, Ronald Brachman, John McCarthy, Thomas Gruber, Peter Norvig, Patrick Hayes, Ramesh Patil, Reed Letsinger, Len Shubert, and Vladimir Lifschitz. Knowledge interchange format version 3.0 reference manual. Technical Report Technical Report Logic-92-1, Computer Science Department, Stanford University, Stanford, CA, USA, 1992. [8] Robert Levinson and Gerard Ellis, editors. Proceedings of the 2nd International Workshop on Peirce: A Conceptual Graphs Workbench, Quebec City, Canada, August 7 1993. available by anonymous ftp ftp.cs.uq.oz.au, /pub/peirce/peirce93.ps.Z. [9] Guy W. Mineau, Bernard Moulin, and John F. Sowa, editors. Conceptual Graphs for Knowledge Representation. Number 699 in Lecture Notes in Arti cial Intelligence.

[10]

[11]

[12] [13]

[14]

[15]

[16]

Springer-Verlag, Berlin, 1993. Proceedings of the 1st International Conference on Conceptual Structures, Quebec City, Canada, August 4-7. Sandra Perez and Anthony Sarris (eds). IRDS conceptual schema. Technical Report X3H4/93-196, American National Standards Institute, New York, 1993. Ben Potter, Jane Sinclair, and David Till. An Introduction to Formal Speci cation and Z. International Series in Computer Science. Prentice Hall, 1991. Don D. Roberts. The Existential Graphs of Charles S. Peirce. Mouton, The Hague, 1973. John F. Sowa. Conceptual Structures: Information Processing in Mind and Machine. Addison-Wesley, Reading, MA, 1984. John F. Sowa. Logical foundations for representing object-oriented systems. Journal of Experimental & Theoretical Arti cial Intelligence, 5, 1993. John F. Sowa. Relating diagrams to logic. In Guy W. Mineau, Bernard Moulin, and John F. Sowa, editors, Conceptual Graphs for Knowledge Representation, number 699 in Lecture Notes in Arti cial Intelligence, Berlin, 1993. Springer-Verlag. Proceedings of the 1st International Conference on Conceptual Structures, Quebec City, Canada, August 4-7. William M. Tepfenhart, Judith P. Dick, and John F. Sowa, editors. Conceptual Structures: Current Practices, number 835 in Lecture Notes in Arti cal Intelligence, Berlin, August 1994. Springer-Verlag. Second International Conference on Conceptual Structures, ICCS'94, College Park, Maryland, USA.