From first-order logic to automated word ... - Semantic Scholar

3 downloads 4794 Views 629KB Size Report
airline booking systems, or technical systems with complex computations with little data, ...... domain word Name of Type Char belonging to the defined. Fig. 9.
Knowledge-Based Systems 16 (2003) 413–429 www.elsevier.com/locate/knosys

From first-order logic to automated word generation for Lyee Benedict Amon, Love Ekenberg*, Paul Johannesson, Marcelo Munguanaze, Upendo Njabili, Rika Manka Tesha Department of Computer and Systems Sciences, Stockholm University and KTH, Forum 100, SE-164 40 Kista, Sweden

Abstract A conceptual schema can be viewed as a language to describe the phenomena in a system to be modelled, i.e. a set of derivation rules and integrity constraints as well as a set of event-rules describing the behaviour of an object system. In this paper, we investigate the relationship between the Lyee software requirements concepts with various constructs in conceptual modelling. Within our work we choose the Unified Modelling Language (UML) as a modelling notation for explaining conceptual models. The result obtained models a fully expressive set of UML and First Order Logic constructs mapped into Lyee concepts. q 2003 Elsevier B.V. All rights reserved. Keywords: Lyee; Unified modelling language; Logic; Conceptual modelling

1. Introduction Traditionally, software systems were classified as either administrative, data intensive information systems, e.g. airline booking systems, or technical systems with complex computations with little data, e.g. process control systems. However, software systems are increasing rapidly, both in number and in complexity. Application areas, having been a vision yesterday, are today the reality, e.g. electronic commerce, education via World Wide Web, and global distribution of objects to mention a few. Embedded systems are another kind of software applications, rapidly increasing in number, e.g. components in a car or in hi-fi equipment. This implies, among other things, that the demands of software engineering are ever increasing. Quality software is supposed to satisfy the stated and implied intention of a customer. When discussing the quality of the software, three items are of vital concern: the customer intention, the requirements and the code. The requirements must capture the stated and implied user intention, and the software must meet the requirements, i.e. to function according to the requirements. It should also obey any non-functional requirements concerning, e.g. usability, availability, cost for development and operation. The activity of assuring that the requirements capture the customer intention is usually referred to as validation. The activity of assuring that the software meets its requirements * Corresponding author. E-mail address: [email protected] (L. Ekenberg). 0950-7051/$ - see front matter q 2003 Elsevier B.V. All rights reserved. doi:10.1016/j.knosys.2003.08.009

is usually referred to as verification. In other words, the validation is the activity linking the requirements to the intention, while verification links the requirements to the implementation. Formal methods have mainly been advocated for technical types of systems, and safety critical applications. The tradition has been reflected in industrial development, research, and education. However, the rapid technological development, and the increasing number and complexity of software systems are gradually padding the borders—the systems become more complex, even the data intensive systems. Furthermore, technical systems need more data, but above all, customers require that also systems, not labelled as safety critical in the original meaning of the term, should function well and without interruption. The costs of interruption are considered too high even if not measured in human lives, but in money. However, formal methods in software engineering are merely a partial solution to the quality problem. Formal methods at the current level of development are said to be at the stage that programming languages were in the early 1960’s: cryptic, requiring much manual tinkering, with little tool support. Programmers are an elite group who used to talk in cryptic mathematical notations. The Lyee methodology has been described by Fumio Negoro in a series of articles, e.g. [10], and is a way of handling verification problems. The similarities and differences between Lyee and conventional requirements and software engineering can be found in Ref. [2]. Given that

414

B. Amon et al. / Knowledge-Based Systems 16 (2003) 413–429

a user is able to state a set of requirements, the program can be generated in an interactive way until the requirements are satisfied. This makes the verification process a component embedded in the program development process. One crucial issue, however, is the validation process, i.e. to what extent do the stated requirements reflect the actual user intentions and the goals of the customer organisation. At present the Lyee methodology provides no conclusive support for determining this. Several models and representation forms need to co-exist in order to enable users to get a good understanding of a system. Conceptual Models may be expressed in different notations, such as ER, UML, ORM, and other formalisms. These notations are typically graphic based and make use of intuitive and visual modelling constructs as the main components of the notations, which facilitates their adoption among large user groups. However, the constructs of many conceptual modelling approaches are typically informally defined, which leaves room for ambiguities, loose interpretations and misunderstandings. An important task is, therefore, to formalise the basic notions and constructs of conceptual modelling. An attractive way to do this is to translate them into a First Order Logic representation. A logic representation allows for different kinds of analysers that can be used to verify and validate the models. Conceptual modelling and logic representations can be used as means for capturing, verifying, and validating user requirements. However, they are not sufficient for generating executable systems. There is a need for a framework that is able to transform user requirements to executable

software, which is exactly the strength of Lyee. Thus, we get a relationship between conceptual models, first order logic, and Lyee constructs. Against this background, our objective of the work is to design techniques and methods for bridging the gap between customer intention and stated requirements within the framework of Lyee. For this purpose, we are working with the development of the following components: (a) (b) (c) (d)

A formal requirement language Verification techniques and supporting technology Validation techniques and supporting technology Translation algorithms between different formalisms and Lyee constructs

The overall architecture of the work is depicted in Fig. 1. Consequently, our main goal is to develop a tool for bridging the gap between the user intention and the actual program generation. To achieve this goal, there is a need for an interface for generating the input of words to the LyeeAll environment. Instead of reinventing such an interface, we have decided to use a subset of the UML [11] constructs for this purpose. This is not because we believe that UML is the only choice for representing conceptual models, but rather because there are adequate tools, such as Rational Rose [12] or Microsoft Visio [9] for stating UML models. Furthermore, UML has gained increased popularity in recent years and is now regularly used not only for systems analysis and design, for which it was originally conceived, but also for other phases in the systems life cycle such as requirements engineering and business analysis. The success of UML can

Fig. 1. An overview of the work.

B. Amon et al. / Knowledge-Based Systems 16 (2003) 413–429

to a large extent be attributed to two factors. First, UML has received extensive industry support from IT suppliers as well as users and has been effectively standardised. Secondly, UML makes use of intuitive and visual modelling constructs as the main components of the language, which facilitates its adoption among large user groups. The purpose of the paper is to investigate the relationships between Lyee and conceptual modelling using UML and first order logic. The paper is organised as follows. Section 2 gives an overview of Lyee, UML, and Logic for Conceptual Modelling. In Section 3, we introduce the mapping of Conceptual Models concepts into first order logic. Section 4 demonstrates how first order logic notions can be mapped on Lyee constructs. Section 5 concludes the paper.

Fig. 2. A scenario function with its three Pallets in their order of execution.

A PRD specifies the navigation between the various components of the application. A PRD can be considered as a graph with a unique start node, intermediate nodes and one or several ending nodes. The nodes are called Scenario functions, where each scenario function has Pallets. Fig. 2 below shows the three pallets, their functions and the execution order, i.e. how control is routed among the pallets. W04—controls the display of information to screens or databases, including data manipulation and output generation W02—controls the recovery of input from the screens or databases, including data-validity checking W03—controls the conditions for displaying information, including pre conditions checking and routing to another pallet.

2. Lyee, UML, and logic for conceptual modelling In this section, we will give an introduction to the basic concepts in the frameworks that are studied and compared. First, we describe Lyee and and LyeeAll, then UML as an example of a modelling language, and finally how logic can be tailored for conceptual modeling. These descriptions will form a basis for the translations presented in the two final sections of the paper. 2.1. An overview of requirements for Lyee Lyee is a methodology to develop software by simply defining the software requirements [8]. These requirements are defined by words, the formulae that should regulate the words, conditions to form each of these formulae, and the layout of screens and printouts. Once the requirements are defined, Lyee then leaves all subsequent processing to algorithms based on the definitions [14,15,16]. In a sense, the LyeeAll tool can be considered to implement a subset of the methodology, and the data can either be entered directly through the GUI or imported from text files on the required LyeeAll format. In the following, we will only cover those parts of Lyee and LyeeAll that are relevant for explaining the relationships between Lyee and conceptual modelling. 2.1.1. Defined and items data When creating a system, the LyeeAll user needs to enter the Defined and the corresponding Items. A defined corresponds to a window or a database access definition. Defineds are composed of items (where one item belongs to at most one defined), e.g. a database field or a button on a screen. An item in LyeeAll tool can be of various types, e.g. numeric values, text format, buttons and images. 2.1.2. Process route diagram After identifying and entering Defineds and Items data, the next step is the creation of the Process Route Diagram (PRD), which is the graphical representation of a Process Route Vector.

415

The concept of a Routing word is used to distribute the control over the various scenario functions of a PRD. In particular, these words are handling over the control from one pallet to another according to the structure of Fig. 2. 2.1.3. Pallets and logical units Pallets are composed of Words grouped into Logical Units, i.e. they are specified or implemented using Logical Units. Thus, a Pallet can be viewed as a module where the components are Words. 2.1.4. Specification of words in logical units The relationship between words and logical units is similar to the one between items and Defineds. While logical units implement the behaviours of Defineds, Words implement the behaviour of items, where one item belongs to at most one defined), e.g. a database field or a button on a screen. An item in LyeeAll tool can be of various types i.e. 9 for a numeric value, X for text, B for command button and F for image. 2.1.5. Specification of vectors Vectors can also be regarded as Words. There are two main classes of vectors.1 1. 2.

Signification Vectors are composed of domain words already discussed above. Action Vectors are partitioned into four categories: (a) Input Vectors—implement input actions, e.g. reading the screen (b) Output Vectors—implement output actions, e.g. displaying information to a screen

1 Note that a vector in Lyee does not have any relationship to a vector in the mathematical sense.

416

B. Amon et al. / Knowledge-Based Systems 16 (2003) 413–429

Fig. 3. Data elements in LyeeAll requirements.

(c) Structural Vectors—implement the initialization of screen elements such as fields or buttons (d) Routing Vectors—Implement the navigation between the application component Fig. 3 below shows the data elements for the LyeeAll input requirements and the steps to be followed in entering data into the LyeeAll tool. In the figure, the numbering of the data elements suggests the order to be followed in entering data. For instance, a defined needs to be entered before entering its corresponding items. Similarly, a PRD must be defined before its scenario functions are entered, followed by logical units and domain words. 2.2. Unified modelling language In this section, we introduce the basic constructs of UML, the Unified Modelling Language. We discuss here the constructs of UML, i.e. classes, attributes, associations, aggregation, generalisation, and cardinality. The dynamic constructs will be discussed in the next section when the translation between UML and logic is described. 2.2.1. Classes A class is a set of objects that share a common structure and common behaviour (the same attributes, operations, relationships and semantics). A class is an abstraction of real-world items. When these items exist in the real world, they are instances of the class and are referred to as objects. 2.2.2. Attributes Attributes define the characteristics of a class. Each object in a class has the same attributes, but the values of the attributes may be different. 2.2.3. Associations UML defines associations as structural relationships between classes. An instance of an association is a link, that is, a tuple of object references.

2.2.4. Aggregation In UML, aggregation is a special type of association that indicates a lifetime dependency among the related parts. One end of the association is considered the ‘whole’ part of the aggregate structure and the other ends are considered ‘parts’ of the class at the ‘whole’ end. The class at the whole end is referred to as the aggregate class, and the classes at the parts end are part classes. Aggregate classes can be thought of as structures in which part classes are components. 2.2.5. Generalization A generalization relationship between classes shows that the subclass shares the structure or behaviour defined in one or more super classes. We use a generalization relationship to show an ISA relationship between classes. 2.2.6. Cardinality The Cardinality field specifies the number of expected instances of the class. You can set a specific cardinality value for the client class, supplier class, or both. In the case of relationships, this field indicates the number of links between each instance of the client class and the instances of the supplier class. Example 1. In Fig. 4, Saving_Account, Checking_Account, Account, Person and Portfolio, are UML classes. An association represents the relation Saving_Client, from Saving_Account to Person, meaning that a Saving_Client is a person with a Saving Account. There is also another association representing the relation Checking_Client, from Checking_Account to Person, meaning that a Checking_Client is a person with a Checking Account. The attribute amount on both Saving_Account and Checking_Account represents the current balance. An account (Saving_Account or Checking_Account) must be owned by a person, and a person must have one Saving_Account or Checking_Account. Furthermore, at maximum two clients can share an Account. The classes Saving_Account

B. Amon et al. / Knowledge-Based Systems 16 (2003) 413–429

417

Fig. 4. A sample UML diagram.

and Checking_Account are subclasses to Account. Furthermore, Account is a component of the portfolio of the bank. This is represented by the aggregation from Account to portfolio. There are also methods deposit, withdraw, open and close in the Account class, which will be treated when we discuss the dynamic aspects of UML models. 2.3. First order logic for conceptual modelling In this section, we introduce a few definitions showing how First Order Logic can be used for capturing conceptual modelling constructs. 2.3.1. Schemas A schema S is a structure kR; ERl consisting of a static part R and a dynamic part ER. R is a finite set of closed firstorder formulae in a language L: ER is a set of event rules. Event rules describe possible transitions between different states of a schema and will be described below. LðRÞ is the restriction of L to R, i.e. LðRÞ is the set {plp [ L; but p does not contain any predicate symbol, that is not in a formula in R}. The elements in R are called static rules in LðRÞ: A static assertion in S, FðxÞ; is a closed first order formula in LðSÞ: 2.3.2. Event rules An event rule in L is a structure kPðzÞ; CðzÞl: PðzÞ and CðzÞ are first-order formulae in L; and z is a vector of variables in the alphabet of L:2 In terms of conceptual modelling, PðzÞ denotes the precondition of the event rule, and CðzÞ the post condition. 2

The notation AðxÞ means that x is free in A(x).

3. Translating conceptual models into first order logic In this section, we demonstrate how a relevant subset of static and dynamic concepts modelled in UML straightforwardly can be expressed in terms of first order logic formulae for the UML constructs. We also demonstrate the implementation of a translation tool for specifications in UML language into logic based formalism; so as to prepare a unifying view of a general class of conflict detection [4]. Already there is a general recognition that the UML is not yet a precise modelling technique. For instance, Kim and Carrington [7], provide a translation and mapping of UML to Object-Z. The translation is restricted to UML class constructs and class diagrams. These also provide for a formal definition for the languages used. France et al. [6] present a translation of UML class diagrams to Z specifications. Dupuy et al. [3] also develop an Object-Z specification from object models in OMT. None of these provides for a formal basis of the language used and the translation rules are described informally at the model-level. The pUML group [5] has focused on defining the semantics of core UML modelling concepts. At the abstract level they use OCL to specify the semantics of model elements in much the same way as the UML semantics are specified. One main problem with these approaches is that they do not transform the specifications into a format where logic verification techniques can be applied in a computationally meaningful way. Herein, we have followed the general philophy in Ref. [1], arguing that first order logic is the most suitable choice for modelling static and dynamic features of specifications, in contrast to such, e.g. based on traditional temporal logic or varieties thereof. In this, we have

418

B. Amon et al. / Knowledge-Based Systems 16 (2003) 413–429

Fig. 5. Meta-Model showing the relationship between first order logic and UML.

attempted to fulfil two basic requirements: that the target language should be executable; and that it have clear semantics. As for this work we demonstrate the actual implementation on both static part and dynamic part of UML into a common framework—first order logic without introducing peculiar formalisms. In this work different parts of UML, i.e. class diagrams, state diagrams, and collaboration diagrams, are translated independently. For the actual implementation we use we use a scripting language within Rational Rose [12], which is a tool to visually create UML constructs. Fig. 5 illustrates the mapping of UML constructs to first order logic formulae. From Fig. 5, there are two layers (Logic and UML), which are divided with a dotted line. The lines that cross the dotted line show the relationships between UML constructs and Logic formulae. In the figure, Class, Association, and Attribute UML constructs are all related to predicate symbols in first order logic. Transitions in UML are linked to event rules while Typing constraints for attributes, Aggregations as well as ISA relationships are all related to static rules. Definition 1. Translation language In the automatic translation of UML to first order logic, in the translation script, we use the following first order

logic primitives: 1. 2. 3.

Variable Symbols: x, y Connectives: Not ( , ), And (&), Or (#), Implies ( ) ), if and only if ( , ) Quantifiers: (a) Universal (A)—(Ax) C(x) means that C holds for all values of x in the domain associated with that variable. (b) Existential (E)—(Ex) C(x) means that C holds for some value of x in the domain associated with that variable.3

3.1. Translation of static UML constructs In this section we describe a translation of static UML concepts into first order logic formulae as well as its implementation. The mapping rules used in the translation are defined formally below. 3

The alphabet above is different from the one used in the actual algorithm that explains the translation. In this algorithm we make use of the standard first order logic symbols. The reason for this difference is that the implementation language for the script in Rational Rose cannot accommodate the standard first order logic symbols.

B. Amon et al. / Knowledge-Based Systems 16 (2003) 413–429

Definition 2. Translating class diagrams Given a set C of class diagrams in a UML specification, where the strings agg or lex do not occur. RC is the least set of first order formulae defined by the following clauses. A. Alphabet (a) If r is a name of a class definition in C; then r is a predicate symbol of arity one in LðRC Þ: (b) If t is a name of an association in C; then t is a predicate symbol of arity two in LðRC ) (for simplicity, we assume uniqueness of association and attribute names). (c) If t is a name of an attribute in C, then t is a predicate symbol of arity two in LðRC Þ: (d) agg is a predicate symbol of arity two in LðRC Þ: (e) lex is a predicate symbol of arity one in LðRC Þ: B. Constraint generation B.1. Typing constraints for associations If r and sare names of class definitions in C; and t is a name of an association from r to s in C; then ;x;yðtðx; yÞ ! ðrðxÞ ^ sðyÞÞÞ is in RC : Example 2 Translating a sample UML diagram above yields the following first order logic formulae relating to UML associations. %Typing constraints for associations %-----------------------------------(Ax) (Ay) (Saving_Client(x,y) ! (Saving_Account (x) & Person(y)). (Ax)(Ay)(Checking_Client(x,y) ! (Checking_Account (x) & Person(y)). B.2. Typing constraints for attributes If r is a name of a class definition in C and t is a name of an attribute of r in C; then ;x;yðtðx; yÞ ! ðrðxÞ ^ lexðyÞÞÞ is in RC : Example 3 Running a script file on the sample UML diagram above yields the following first order logic formulae relating to UML attributes. %Typing constraints for attributes %-----------------------------------(Ax)(Ay)(Branch(x,y) ! (Account(x) & lex(y))). (Ax)(Ay)(Account Number(x,y) ! (Account(x) & lex(y))). (Ax)(Ay)(Amount(x,y) ! (Saving_Account (x) & Currency(y))). (Ax)(Ay)(Name(x,y) ! (Person(x) & lex(y))). (Ax)(Ay)(Address(x,y) ! (Person(x) & lex(y))).

419

(Ax)(Ay)(Amount(x,y) ! (Checking_ Account (x) & Currency(y))). B.3. Aggregation constraints If r and s are names of class definitions in C; and t is a name of an aggregation from r to s in C; then ;x;yðtðx; yÞ ! ðrðxÞ ^ sðyÞ ^ aggðx; yÞÞÞ is in RC : Example 4 Translating asample UML diagram above yields the following first order logic formulae relating to UML aggregates. %Aggregation constraints %----------------------------------------------------------------(Ax)(Ay)(part_of(x,y) ! (Portfolio (x) & Account(y) & agg(x,y))). B.4. ISA constraints If r and s are names of class definitions in C; and the statement r ISA s belongs to C; then ;xðrðxÞ ! sðxÞÞ is in RC : Example 5 Translating a sample UML diagram above yields the following first order logic formulae relating to UML ISA relationships. %ISA constraints %-----------------------------------(Ax)(Saving_Account (x) ! Account(x)). (Ax)(Checking_Account (x) ! Account (x)). B.5. Subclass constraints Assume that p, r and s are names of class definitions in C; and that p ISA s and r ISA s belong to C: If p and r are disjoint in C; then ;x : ðpðxÞ ^ rðxÞÞ is in RC : If p and r are exhaustive wrt s in C; then ;xðsðxÞ ! ðpðxÞ _ rðyÞÞÞ is in RC : B.6. Cardinality constraints If r and s are names of class definitions in C; and t is a name of an association from r to s in C; with cardinality ððminr · · · maxr Þ; ðmins · · ·maxs ÞÞ; then the formulae below are in RC : Minimum number of associations for the domain ;y’x1 · · ·’xminr ððsðyÞÞ ! ðtðx1 ; yÞ ^ · · · ^ tðxminr ; yÞÞÞ^ : ðx1 ¼ x2 Þ ^ · · ·^ : ðx1 ¼ xminr Þ^ : ðx2 ¼ x3 Þ ^ · · ·^ : ðx2 ¼ xminr Þ ^ · · ·^ : ðxminr21 ¼ xminr Þ Maximum number of associations for the domain ;y;x1 · · ·;xmaxr ;xmaxr þ1 ½ððtðx1 ; yÞ ^ · · · ^ tðxmaxr ; yÞ ^ tðxmaxr þ1 ; yÞÞ ! ððx1 ¼ x2 Þ _ · · · _ ðx1 ¼ xmaxr Þ _ ðx1 ¼ xmaxr þ1 Þ _

ðx2 ¼ x3 Þ _ · · · _ ðx2 ¼ xmaxr Þ _ ðx2 ¼ xmaxr þ1 Þ

_ ··· _

ðxmaxr ¼ xmaxr þ1 ÞÞ

420

B. Amon et al. / Knowledge-Based Systems 16 (2003) 413–429

Minimum number of associations for the range ;y’x1 · · ·’xmins ððrðyÞÞ ! ðtðy; x1 Þ ^ · · · ^ tðy; xmins ÞÞÞ^ : ðx1 ¼ x2 Þ ^ · · ·^ : ðx1 ¼ xmins Þ^ : ðx2 ¼ x3 Þ ^ · · ·^ : ðx2 ¼ xmins Þ ^ · · ·^ : ðxmins21 ¼ xmins Þ Maximum number of associations for the range ;y;x1 · · ·;xmaxs ;xmaxs þ1 ½ððtðy; x1 Þ ^ · · · ^ tðy; xmaxs Þ ^ tðy; xmaxs þ1 ÞÞ ! ððx1 ¼ x2 Þ _ · · · _ ðx1 ¼ xmaxs Þ _ ðx1 ¼ xmaxs þ1 Þ_ ðx2 ¼ x3 Þ _ · · · _ ðx2 ¼ xmaxs Þ _ ðx2 ¼ xmaxs þ1 Þ _ · · ·_ ðxmaxs ¼ xmaxs þ1 ÞÞ Example 6 For example if we consider the maximum number of associations for the domain we get the following results after running a script file on our sample UML diagram. %Maximum number of associations for the domain %-----------------------------------(Ay),(Ax1),(Ax2),(Ax3) [((Saving_Client(X1,Y) & Saving_Client(X2,Y) & Saving_Client(X3,Y))) ! ((X1 ¼ X2) # (X1 ¼ X3) # (X2 ¼ X3))] 3.2. Modelling dynamics In UML, dynamics can be modelled in three different ways: by methods in classes, by state diagrams, and by interaction diagrams. In this section, we consider the translation of

methods, state diagrams and a particular kind of interaction diagrams called collaboration diagrams into logic. In order to illustrate how the translation algorithm works for dynamic constructs in UML, we use the class diagram shown in Fig. 4, and the state and collaboration diagrams shown in Fig. 6. The class diagrams show the set of classes, class names, associations, and methods for the class account. Although not shown on the diagram, it is possible to specify the pre and post condition if necessary for each method. These pre and post conditions are expressed as strings in natural language. The state diagram shows the different possible states for the class Account, together with the events and conditions that trigger a state change. The events are actual methods that have been declared in the class construct. The event names and parameters are written close to the transition arrow on the diagram. State names are written inside the state. An event may have a parameter, and a guard condition expressed in natural language. In the occasion that the guard condition evaluates to true, the transition takes place. The collaboration diagram shows the objects and the messages that link the objects together. Each object has been declared as an instance of a particular class that exists in a static specification of the class diagram. The numbering indicates the sequence of messages. 3.3. Methods Methods in UML describe operations within specifications. These are declared and belong to a specific class. A signature with a vector of variables labels a method. Thus the signature describes the pieces of information needed to invoke an operation. These include the operation name and any parameters that the operation works on. The translation of methods into a first order logic is then a formula made up of these entities. In the sequel, we assume that the semantics of a method gðyÞ can be formulated by a pair ,preðxÞ; postðxÞ .; where preðxÞ is a first order formula expressing the precondition of the method and postðxÞ is a

Fig. 6. UML state diagram and collaboration diagram.

B. Amon et al. / Knowledge-Based Systems 16 (2003) 413–429

421

first order formula expressing the post condition of the method.4 The pre-condition holds when the operation is invoked, while the post condition evaluates to true after the operation has been invoked. Definition 3. Translating methods Given a set of methods M in a UML specification, where the string inv does not occur. ERM is the least set of expressions defined by the following clauses.5

Definition 4. State diagram for a class. A state diagram for a class k is a triple , N; A; G .; where

A. Alphabet (a) If gðyÞ ¼ , preðxÞ; postðxÞ . is a method in M, then the corresponding predicate symbols with the same arities are in LðERM Þ: (b) inv is a predicate symbol of arity one in LðERM Þ:

In G; a is an arc, ueðx; yÞ is a UML event, where x is an object (reference) of class k and y is a vector of objects and values. guardðx; yÞ is an open first order formula. pðx; yÞ is a set of formulas, where each formula has one of the following forms insertðaðx; yi ÞÞ; deleteðaðx; yi ÞÞ; or invokeðumlevðzÞÞ. Here, x is an object (reference) of class C; yi is a member of y and z is a vector of objects and values. In this definition, N represents a set of states and A a set of transitions between these states. G specifies the pre- and post-conditions of these transitions. When a UML event ueðx; yÞ occurs, it is captured by the state machine of the object x: If the guard guardðx; yÞ is true, the state machine will make a transition according to the arc a. Thereafter, the procedure pðx; yÞ will be executed, which inserts and deletes a number of links between x and other objects and values. Finally, a number of other UML events will occur, which other state machines will handle. Definition 5. Translating state diagrams Given a set S of state diagrams , N; A; G .k in a UML specification, where the string state does not occur. A schema for S is constructed as follows.

B. Methods Let k be a class and gðyÞ ¼, preðxÞ; postðxÞ . a method in k. If gðyÞ is a method in M, then , invðgðyÞÞ ^ preðxÞ; postðxÞ^ : invðgðyÞÞ .k is in ERM ; where preðxÞ and postðxÞ are as above. ðinvðgðyÞÞ means that the method gðyÞ has been invoked.) Example 7 Using Fig. 6, the operations that have been declared for the class account, will be translated as follows in our translation script. {, inv(withdraw( )) & amount , Balance, Balance ¼ Balance 2 amount & , inv (withdraw( )) . , , inv(deposit( )) & amount . 0, Balance ¼ Balance þ Amount & , inv(deposit( )) . , , inv(Open( )) & true,true & , inv (Open( )) . , , inv(Close( )) & Balance ¼ 0, true & , inv (Close( )) . } 3.4. State diagrams In a UML specification, each class can be associated with state diagrams. Each state diagram can then be described by the set of nodes, events and conditions that constitute the state diagram. Thus for a corresponding class diagram, consisting of one or more classes, this implies that the state diagrams constitute a collection of such descriptions. In the corresponding translation, we denote such descriptions as a schema. This schema provides a complete image of what the objects in the model are, and how these objects behave according to certain event rules. This is expressed in Definitions 4 and 5. 4 The expressiveness of the translation could be extended by the addition of recursive techniques for handling more general types of methods, but this is beyond the scope of this article. 5 The expressiveness of the translation could be extended by the addition of recursive techniques for handling more general types of methods, but this is beyond the scope of this article.

(a) N is a set of nodes (b) A is a set of directed arcs, i.e. pairs over N (c) G is a set of quadruples , a; ueðx; yÞ; guardðx; yÞ; pðx; yÞ .

A. Alphabet (a) If pti ; tj .; ueðx; yÞ; guardðx; yÞ; pðx; yÞ .[ G; then the corresponding predicate symbols and constants in ti ; tj ; ueðx; yÞ; guardðx; yÞ; and pðx; yÞ with the same arities are in LðERS Þ and LðRS Þ: (b) State is a predicate symbol of arity two in LðERS Þ and LðRS Þ: B. Rules for an object in a state ! : stateðx; tj ÞÞlti ; tj [ N ^ i – RS ¼ {;xðstateðx; ti Þ j} < {;x’tðstateðx; tÞ}