Generating a Prototype from a UML Model of System Requirements Xiaoshan Li, Zhiming Liu, He Jifeng and Quan Long

UNU/IIST International Institute for Software Technology

Generating a Prototype From a UML Model of System Requirements Xiaoshan Li, Zhiming Liu, He Jifeng and Quan Long

September 2004

UNU-IIST Report No. 307 R UNU-IIST and UNU-IIST Reports

UNU-IIST (United Nations University International Institute for Software Technology) is a Research and Training Cen- tre of the United Nations University (UNU). It is based in Macau, and was founded in 1991. It started operations in July 1992. UNU-IIST is jointly funded by the Governor of Macau and the governments of the People’s Republic of China and Portugal through a contribution to the UNU Endownment Fund. As well as providing two-thirds of the endownment fund, the Macau authorities also supply UNU-IIST with its ofﬁce premises and furniture and subsidise fellow accommodation. 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. University development projects, which complement the curriculum development projects by aiming to strengthen all aspects of computer science teaching in universities in developing countries, 5. Schools and Courses, which typically teach advanced software development techniques, 6. Events, in which conferences and workshops are organised or supported by UNU-IIST, and 7. 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 interna- tionally 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 at P.O. Box 3058, Macau or visit UNU-IIST’s home page: http://www.iist.unu.edu, if you would like to know more about UNU-IIST and its report series.

Chris George, Acting Director UNU/IIST International Institute for Software Technology

P.O. Box 3058 Macau

Generating a Prototype From a UML Model of System Requirements Xiaoshan Li, Zhiming Liu, He Jifeng and Quan Long

Abstract

We present a method for automatically generating a prototype from a UML model of system requirements that consists of a use-case model and a conceptual class model. The method is based on a formalization of UML in which a use case is formally speciﬁed by a pair of pre and post conditions in the context of a conceptual class model. To generate a prototype, we translate the pre and post conditions of a use case into a sequence of executable atomic actions. These actions are to create or delete an object, update an object, establish or remove a link between two objects with respect to an association. Such a prototype can be used to validate requirements and check system invariants. An automated prototype generator is developed in Java, and a simple library system is used as an example to illustrate the feasibility of the method. Keywords: Prototype, UML, Requirements analysis, Formal Speciﬁcation, Automated Java Code Generation

This paper is to occur in the proceedings of 1st International Conference on Distributed Computing Internet Technology(ICDCIT 2004) Decemeber 22-24, 2004, Bhubaneswar, India. Xiaoshan Li is an Associate Professor at the University of Macau. His research areas are interval temporal logic, formal speciﬁcation and simulation of computer systems, formal methods in system design and implementation. E-mail: [email protected].

Zhiming Liu is a Research Fellow at UNU/IIST, on leave from Department of Computer Science at the University of Leicester, Leicester, England where he is lecturer in computer science. His research interests include theory of computing systems, emphasising sound methods for specification, verification and refinement of fault-tolerant, real-time and concurrent systems, and formal techniques for OO development. His teaching interests are Communication and Concurrency, Concurrent and Distributed Programming, Internet Security, Software Engineering, Formal specification and Design of Computer Systems. E-mail: [email protected].

He Jifeng is a Senior Research Fellow of UNU/IIST. He is also a professor of computer science at East China Normal University and Shanghai Jiao Tong University. His research interests include the Mathematical theory of programming and reﬁnement methods, design techniques for the mixed software and hardware systems. E-mail: [email protected].

Quan Long is a Fellow at UNU/IIST. He is a Ph.D candidate at Department of Informatics, School of Mathe- matical Sciences, Peking University, Beijing, China. His research interests are formal method, object-oriented analysis and design, and component-based software development. Email: [email protected].

Contents

1 Introduction 1

2 Formalizing UML Models of Requirements 3 2.1 A library system ...... 3 2.2 Formalizing UML models of requirements ...... 4

3 Generate an Executable Prototype 10

4 Prototyping Library System 15

5 Discussion and Conclusion 15

Report No. 307, September 2004 UNU-IIST, P.O. Box 3058, Macau

Introduction 1

1 Introduction

Early acquired requirements are difﬁcult to validate without testing. Prototyping is efﬁcient and effective to expose errors in the early stages of requirements analysis and design. The general purposes of building a prototype include [Smi91, LSHZ94, Cop95, Som00]

• to ensure that the designers and implementors understand requirements directly,

• to help to demonstrate to the customers for validating the requirements,

• to cope with changing requirements better,

• to be used for test planning.

Ideally, prototypes cover two aspects of the system being developed: the semantics of the application and the architecture of the software. The architecture of prototypes has to match the fundamental architecture of the envisaged application system independently of the purpose of the prototype.

This paper presents a method for automatic generation of a prototype from a model of system requirements. A model of requirements consists of a use-case model (UCM) and a conceptual class model (CCM). They are speciﬁed in the notation of UML. When prototyping a system from its model of requirements, we should make clear two key problems. One is which parts of the model we want to prototype; and the other is whether we can prototype the parts in the current context of the model, i.e. the parts are executable or not.

UML models of requirements A UCM consists of a use case diagram and textual descriptions of use cases. However, a use case diagram provides only static information about use cases. The dynamic semantic aspects are described in the textual descriptions of use cases as sequences of interactions between actors and the system. Therefore, formalizing and prototyping the requirements of a system should focus on the textual description of the use cases.

A CCM for an application is a class diagram consisting of classes (also called concepts), and associations between classes. A class represents a set of conceptual objects and an association determines how the objects in the associated classes are related (or linked). For example, we have two concepts User and Copy of a publication in a library system. They are associated so that a customer borrows a number of copies. In addition to associations between concepts, a concept may have some properties represented by attributes. For example, User has an attribute uid.

The reason why we call a class model conceptual at this level is that we are not concerned with what an object does, how it behaves, or how an attribute is represented. The decision on these issues will be made during design phase when the responsibilities of a use case are decomposed and assigned to appropriate objects. Therefore, a CCM is a static model of the structure of the application domain.

The background The correctness of a requirements model is validated in general by simulations with a prototype of the system. However, a prototype is usually a simpliﬁed version of the system with a smaller set of functionalities, but with design and implementation details [Lee01, Som00]. The framework presented in this paper supports the generation of prototypes for requirements validation without the need of going into the

Report No. 307, September 2004 UNU-IIST, P.O. Box 3058, Macau Introduction 2

design. It also supports a fuller scale of prototyping. We believe this is more cost effective as it is only added as part of the requirements analysis, and its automation can even reduce the cost by making the requirements analysis more efﬁcient and effective.

The method is fully based on a sound formal method [HH98] of modelling and refinement of requirements integrated with the Rational Unified Process(RUP)[LLH01, LLH]. RUP [JBR99, Kru00] has emerged as a popular software development process. The modelling notation used in RUP is UML [RJB99], that is the de-facto standard modelling language for the development of software with broad application ranges. UML covers the early development stages of requirements analysis and specification and has strong support for design and implementation [JBR99]. RUP promotes several best practice, but one that stands above the other is the ideas of iterative development. In the iterative approach of RUP, development is organized as a series of short and fixed-length of mini-projects called iterations. The iterations are organized and planned according to the system use cases. In [LLH01, LLH], we present a formal model that relate a UCM to a CCM in the framework of Hoare and He’s Unifying Theory of Programming [HH98]. The formalization supports reasoning about the consistency between a CCM and a UCM that is concerned with whether the CCM is adequate to support the UCM [LLH].

Outline of the method Syntactic correspondence between a CCM and its formalization exists and a translation from one into another is easy. We have to type in the formal speciﬁcation of the use cases as there is no UML syntax for use-case descriptions. In this paper, we use a canonical form of use case speciﬁcations and show how we can generate executable prototype from a CCM and a UCM without the need of knowing more design details.

Based on the formal semantics of a UCM and a CCM, a prototype is generated as follows: first generate a system entity object database (SEOD) from the semantics of the CCM, and then a system prototype interface which displays the buttons for the names of the use cases in the UCM (this can be generated from the use- case diagrams), and finally a use-case handler for each use case in the UCM that handles the execution of specification of the use case. A use case handler maps the executable parts of each use case in the UCM into a sequence of atomic actions on the SEOD. The framework architecture of generating prototype is shown in Figure 1.

In addition to the purposes of a prototype described earlier, we can also use a prototype generated in our framework for

• a better assessment of requirements to supplement use cases,

• checking the consistency between a UCM and a CCM,

• checking system invariants by evaluating the corresponding boolean expressions on the current state (i.e. system object diagram) of SEOD, and

• comparing the prototypes of two models to check whether one reﬁnes another.

Therefore, this is also part of our work on automating the formalization of UML for OO software development.

The rest of this paper is organized as follows. Section 2 describes the formalization of UML models of requirements by using a simple library system as a case study. Section 3 focuses on the method to generate

Report No. 307, September 2004 UNU-IIST, P.O. Box 3058, Macau Formalizing UML Models of Requirements 3

prototype from a UCM and a CCM. An automated prototype generator is designed to achieve this transforma- tion. Consequently, the library prototype is generated automatically from the tool in Java in section 4. Finally, Section 5 discusses some problems and future work.

Prototype Prototype Interface

Use Case Handlers Object Database

Automated Prototyping Generator

Use Case Model Conceptual Model UML Model

Figure 1: Architecture of generating prototype

2 Formalizing UML Models of Requirements

We use a library system to describe how we can formally specify CCM and UCM in the formal theory of Hoare and He in [HH98]. For more detail about the formal semantics of UML and formal speciﬁcation of the library case study, can be referred to [LLH01, LLH].

2.1 A library system

The system provides the services for the librarians of a university library. Librarians maintain a catalogue of publications which are available for lending to users. There may be many copies of the same publication. Publications and copies may be added to and removed from the library. Registered users can borrow the available copies in the library. When a copy has been borrowed by a user, it is on loan and is not available for lending to other users. When a copy is returned, it should be available to all users again after deleting the corresponding lending loan.

From above informal description of the system requirements, the following use cases can be identiﬁed in the system. Librarian maintains the library, such as adds and removes publications, copies, and users. Library lends a copy to a user. User returns a copy.

1. Librarian maintains the library, such as adds and removes publications, copies, and users.

2. Library lends a copy to a user.

3. User returns a copy.

Report No. 307, September 2004 UNU-IIST, P.O. Box 3058, Macau Formalizing UML Models of Requirements 4

After analyzing the system, a CCM of this simple library can be created and it is shown in Figure 2 should contain four classes: User, Publication, Copy and Loan and ﬁve associations: Takes, Borrows, IsCopyof, IsLendableto and IsAvailable shown in Figure 2 as follows, for realizing the system use cases AddUser, Ad- dCopy, AddPublication, RemoveUser, RemoveCopy, RemovePublication, LendCopy, and ReturnCopy.

Takes User Loan 1 * * * 1 IsAvailable Borrows IsLendableTo

* 1

Publication * Copy 1 IsCopyof *

Figure 2: Conceptual Model of Library

2.2 Formalizing UML models of requirements

The requirement analysis is mainly to create a use case model and a conceptual model. We use the notation similar to a transition or action system [MP81] to combine the two models together to form the requirement speciﬁcation.

An action system is a tuple (α, I, Θ,P ), where

• α is the set of variables known to the program.

• P is a set of atomic actions. Each action is a predicate which relates the initial values of program variables at the start of the action to their ﬁnal values at the termination of the action, and takes the form of p(x) ` R(x, x0) called design in [HH98], where x and x0 represent the initial and ﬁnal values of x respectively:

def p(x) ` R(x, x0) = p(x) ⇒ R(x, x0)

where

– the pre-condition p(x) must be true before the program starts. – the post-condition R(x, x0) holds when the program terminates.

• Θ is a predicate over α that deﬁnes that initial state(s) of the system.

• I is a predicate over α, called the invariant. It has to be true at the initial state and preserved by each action in P .

This simpliﬁed model makes the assumption that there is a universal data type, and ignores the issues of dynamic typing and data accessibility. This is obviously not enough to cope with many features of object- oriented program development.

To formalize the conceptual model and use case model, our semantic model takes into account the following features:

Report No. 307, September 2004 UNU-IIST, P.O. Box 3058, Macau Formalizing UML Models of Requirements 5

1. A use case operates at the conceptual level on variables, called class variables, which take values of sets of objects; variables for values of objects’ attributes; and variables, called association variables, which take values of sets of links (i.e. pairs) between objects. 2. Due to the inheritance mechanism, the effect of a use case will depend on its current type at the execution of the use case, rather than its originally declared type. 3. As in the imperative languages, the state of a variable is simply the value it takes at the moment. An object is represented by a ﬁnite tuple which records its identity, current type, and the values of its attributes. As an object has no attributes of object types in the conceptual model, there is no recursive nesting needed here. Association variables are used to represent links between objects, which may be realized as object attributes in the later design and implementation.

In our model, an OO requirement speciﬁcation is written as an action system Σ = (α, I, Θ,P ) where

• each action in P represents a system operation in one step of using the system in a use case; • α models a conceptual class diagram that identiﬁes the environment in which the operations in P execute; • the invariant I formally models the constraints enforced by the class diagram. The tuple (α, I) thus gives the formalization of the conceptual model; • the initial condition Θ is to be established by the startup operation of the system.

A conceptual model is a tuple CCM = (D,I), where D is a class diagram at the conceptual level and I is the state constraints on the classes and associations enforced on D.

A conceptual class diagram D of an application identiﬁes the environment in which the use cases operate. It consists of four categories:

1. The first category provides the static information on classes and their inheritance relationships: • CName: the finite set of classes identified in the diagram. We use bold capital letters to represent arbitrary classes and types. • super: the partial function which maps a class to its direct superclass, i.e. super(C) = D if D is the direct superclass of C. Note that this definition indicates that we do not deal with multiple inheritance in this paper to keep the theory simple. This information is static because they will not be changed during the operation of the system. 2. The second category describes the structure of each class in terms of their attributes: attr(C): the set of declared attributes of C

{< a1 : T1, c1 >, . . . , < am : Tm, cm >}

where Ti and ci stand for the type and initial value of attribute ai of class C, and will be referred by type(C.ai) and initial(C.ai) in later discussion. Note that the initial value can be null and omitted. The type of an attribute is assumed to be a built-in simple data type, such as those of natural numbers Nat, integers Int, Booleans B, characters Char, and strings String, etc. We call these types data types.

Report No. 307, September 2004 UNU-IIST, P.O. Box 3058, Macau Formalizing UML Models of Requirements 6

3. The third category identiﬁes the dynamic relationships among the classes: AVar: the ﬁnite set of associations captured in the diagram and declared as association variables

{A1 : P(C11 × C12),...,Am : P(Cm1 × Cm2)}

The type of each Ai, referred by type(Ai), is the powerset P(Ci1 × Ci2). The multiplicities of the roles of an association will be speciﬁed in the invariant of the conceptual model. Aggregation associations are treated generally as associations and their special properties are more relevant in the design and implementation.

4. The last category declares the set CVar of class variables that are to be changed by use cases of the system:

{C : P(C)|C ∈ CName}

There is an one-one correspondence mapping between CVar and CName. The type of C, denoted by type(C), is P(C).

We deﬁne the alphabet of a class diagrams as the union of AVar and CVar:

def alphabet = CVar ∪ AVar

In the above deﬁnition, we assume that each class C deﬁnes a type, also denoted by C, of elements similar to records1, and allow the construction of a type from the direct product of two types, and the power set P(T) of a type T.

For simpliﬁcation, we omit the many-to-many association IsLendableto by assuming any user is allowed to borrow any publication. And association IsAvailable in CCM is implemented by introducing an attribute available into the class Copy, i.e. availabe = false means the copy is not available; otherwise it is available to any user.

The model of D of library system in Figure 2 is formulated as follows:

CName = {User, Loan, Copy, Publication} super(C) = Object, for all C ∈ CName attr(User) = {< uid : String >} attr(Loan) = {< lid : String >} attr(Publication) = {< pid : String >, < author : String >} attr(Copy) = {< cid : String >, < available : B >}

1An object of a class without attributes still has its identity that is not speciﬁed in this model.

Report No. 307, September 2004 UNU-IIST, P.O. Box 3058, Macau Formalizing UML Models of Requirements 7

AVar = {T akes : P(User × Loan), Borrows : P(Loan × Copy), IsAvailable : P(Copy × User), IsLendableto : P(Publication × User), IsCopyof : P(Copy × Publication)} CVar = {User : P(User), Copy : P(Copy), Loan : P(Loan), P ublication : P(Publication)}

Therefore, variables in CV ar and AV ar should be deﬁned as global variables in the prototype system. We also assume initial conditions for these variables before the system carries out any use cases. For the above declared CCM of library system, we have

PUser User = ∅; PCopy Copy = ∅; PLoan Loan = ∅; PPublication P ublication = ∅; PIsCopyof IsCopyof = ∅; PTakes T akes = ∅; PBorrows Borrows = ∅

Use cases The informal identification and description of a use case is important for the creation of the CCM to support it [Lar01]. However, the formal specification of the use cases depends on the specification of the CCM. We propose a canonical form for the specification of a UCM by introducing a use-case handler (UCH) for each use case2. This class encapsulates the classes and associations of the CCM, and it declares each system operation [Lar01, Liu01] of the use case as a method in the form

def op = pvar x : T1; rvar y : T2 Pre : p Post : R where pvar and rvar declare the value parameter(s) and the result parameter(s). This method was also used by B. Meyer [Mey97, MM02], called design by contract.

At any time during the execution, this class will only have a single instance. Some methods in the UCH class of the library system are speciﬁed as follows.

Use case AddPublication A library may add a new publication into the system and this service is provided by a use case called AddP ublication. The use case AddP ublication can be formally speciﬁed as:

def AddP ublication = pvar p : Publication Pre : p 6∈ P ublication Post : P ublication0 = P ublication ∪ {p}

2This is suggested by the facade controller pattern.

Report No. 307, September 2004 UNU-IIST, P.O. Box 3058, Macau Formalizing UML Models of Requirements 8

The precondition requires that p is not currently in the library; and the postcondition asserts that the publication p has been created and added to P ublication.

Similarly, we can deﬁne use case AddUser as follows.

def AddUser = pvar u : User Pre : u 6∈ User Post : User0 = User ∪ {u}

Use case AddCopy Use case AddCopy adds a new copy of a publication to the library after its corresponding publication has already been created. If there is not the corresponding publication of the new copy, we should ﬁrst call use case AddP ublication to create the publication, and then carry out AddCopy. The use case AddCopy is therefore deﬁned as follows:

def AddCopy = pvar c : Copy, p : Publication; Pre : c 6∈ Copy ∧ p ∈ P ublication Post : Copy0 = Copy ∪ {c} ∧ c.available0 = true ∧ IsCopyof 0 = IsCopyof ∪ {< c, p >}

Use case LendCopy This use case is about how the library lends a copy of a publication to a user. Obviously, a user u and a copy c are participants in this action, and a loan ` should be created for user u and copy c. The three preconditions say that c and u are known by the system, and c is available ; and the post conditions assert that a new loan is created to record the loan of c and u, and that c becomes unavailable shown in ﬁgure 2. This use case can be formally speciﬁed as

u : User u : User (u, l)

=> l : Loan (c , l) c : Copy c : Copy

pre state post state

Figure 3: Pre and Post Object Diagrams of LendCopy Use Case

def LendCopy = pvar c : Copy, u : User; Pre : c ∈ Copy ∧ u ∈ User ∧ c.available = true Post : ∃` : Loan • ` 6∈ Loan ∧ Loan0 = Loan ∪ {`} ∧ Borrows0 = Borrows ∪ {< `, c >} ∧ T akes0 = T akes ∪ {< u, ` >} ∧ c.available0 = false

Report No. 307, September 2004 UNU-IIST, P.O. Box 3058, Macau Formalizing UML Models of Requirements 9

Use case ReturnCopy This use case is the reverse operation of use case LendCopy. A user returns a copy to the library. A copy c, a user u and a loan ` are participants in this action. This use case can be formally speciﬁed as

def ReturnCopy = pvar c : Copy, u : User; Pre : c ∈ Copy ∧ u ∈ User ∧ ∃` ∈ Loan• < u, ` >∈ T akes∧ < `, c >∈ Borrows Post : Loan0 = Loan − {`} ∧ Borrows0 = Borrows − {< `, c >} ∧ T akes0 = T akes − {< u, ` >} ∧ c.available0 = true

The three preconditions say that c, u and ` are known by the system, and link < u, ` > and link < `, c > exist in T akes and Borrows sets respectively; and the post conditions assert that loan ` and two above links are deleted, and the c becomes available.

Use case RemoveCopy This use case is to remove a copy c from the library. Before accessing this service, the copy should be in available state. The formal deﬁnition of RemoveCopy can be deﬁned as follows.

def RemoveCopy = pvar c : Copy Pre : c ∈ Copy ∧ c.available = true ∧ ∃p ∈ P ublication• < c, p >∈ IsCopyof Post : Copy0 = Copy − { c} ∧ IsCopyof 0 = IsCopyof − {< c, p >}

Use case RemovePublication This use case should first call RemoveCopy to remove all the copies belong to the publication p. The formal specification of use case RemoveP ublication can be defined as follows.

def RemoveP ublication = pvar p : Publication Pre : p ∈ P ublication ∧ ¬∃c ∈ Copy• < c, p >∈ IsCopyof Post : P ublication0 = P ublication − { p}

Use case RemoveUser This use case is to remove a user u from the library. Similarly to use cases RemoveCopy and RemoveP ublicatio, the precondition of RemoveUser requires that the user should return all the copies he or she borrowed from the library, i.e. delete all links in association T akes. Therefore, the user should ﬁrst call use case ReturnCopy for returning all the copies before accessing use case RemoveUser. The deﬁnition is given as follows.

def RemoveUser = pvar u : User Pre : u ∈ User ∧ ¬∃` ∈ Loan• < u, ` >∈ T akes Post : User0 = User − { u}

Report No. 307, September 2004 UNU-IIST, P.O. Box 3058, Macau Generate an Executable Prototype 10

3 Generate an Executable Prototype

Prototyping of requirements analysis should demonstrate the important functional effects of the use cases in terms of atomic state changes rather than the detailed algorithms for internal object interactions. State changes are mainly about creating new objects or links, removing old objects or links, or modifying object attributes. Therefore, the prototype concentrates on the atomic actions on the SEOD which are about creating an object or a link, removing an object or a link, and getting and setting an attribute of an object. A complex functional algorithm on attributes which makes a complex equation satisfaction in the post conditions may not be executable and will be left for further reﬁnement. However, the prototyping can give the corresponding warning information on the non-executable parts.

As shown by the architecture in Figure 1, the prototype can be generated by a prototype generator. The prototype interface can be generated easily from the names of the use cases in a given UCM. The main problem is to generate the SEOD from a given CCM, and to generate the UCH (i.e. its methods) for each use case the given UCM.

Generating the entity object database The conceptual model identiﬁes the object entities as well as the associations among them. It corresponds to the declaration part in the program of the prototype. It is used for the construction of the SEOD of the system prototype.

For each class C in the CCM, a corresponding class C can be deﬁned in the Java program of the prototype. We introduce a special attribute id for each class so that each object can have a unique name for reference since the object name is implicitly as a reference in an Java program. When creating an new object, the object is given a unique identity name id. As already discussed in Section 2 about the alphabet CVar ∪ AVar, we use a global variable C for each class C to record the set of current existing objects of class C, and it is initialized in the prototype declaration part. For simpliﬁcation, we only record an object’s identity name in such a set variable.

The attributes of classes in the CCM can be directly coded into the Java notation by syntax translation. An association can be coded as an array of a pair of object names. For example, suppose c and ` are objects of corresponding Copy and Loan, we can use the corresponding object identity names cid and lid for the objects. We use identity attribute names instead of the object and link identities (references) which are unique. Similarly, < cid, lid > can be considered as the link identity name for Borrows.

Deﬁning the atomic actions of object database In the context of the CCM that derives the SEOD, the use cases correspond to the operations on the database which transfer the database from one stable state to another. The database state is a UML object diagram.

In the implementation of the prototype, we deﬁne for each class C the auxiliary system methods C.find(), C.add(), C.delete() and C.get() on the SEOD, where C is variable with type P(C) deﬁned in the previous paragraph. For example, suppose c is an object of class Copy, Copy.find(c) will return a boolean value to check whether c exists in current system state or not, i.e. to return the truth value of the condition c ∈ Copy; Copy.add(c) will add c to the set Copy; Copy.delete(c) will remove c from Copy; and Copy.get(cid) will get the object reference with name cid. Another useful auxiliary atomic action: Get element(C) is arbitrarily get an element from a given set C.

Report No. 307, September 2004 UNU-IIST, P.O. Box 3058, Macau Generate an Executable Prototype 11

A use case can be realized by a sequences of atomic actions on the SEOD of two categories: object level actions and attribute level actions. Object level actions are creating an object AddObject, deleting an object RemoveObject, creating a link AddLink, and deleting a link RemoveLink. In Java programming, AddObject(c : C) can be implemented by creating a new object c of class C, and then adding it into the class variable C, i.e. new C(c); C.add(c). Similarly, RemoveObject(c) is to delete an existing object c from C, i.e. destroy(c); C.delete(c)). Meanwhile sometimes ﬁnding actions are needed, which are FindObject and FindLink by calling methods C.find() and A.find(), where C ∈ CVar and A ∈ AVar.

The attribute level atomic actions are basic reading and writing an object attribute in the database, i.e. class methods: aget and aset for each attribute a of a class. For example, for the attribute availble of Copy, there are two corresponding methods availableget() and availableset(v).

Checking a precondition The precondition of a use case describes execution constraints, i.e. before executing the use case to modify the SEOD, the constraints are checked on current system state. This checking is static operation on the database. It does not change system state, i.e. without side effects like evaluating expressions of Object Constraint Language (OCL) [WK99].

The task of checking a precondition is to read the relevant information from the SEOD and then evaluate the condition. If the value is false, the prototype will stop the use case and output a corresponding warning information. Otherwise, the prototype will continue executing the use case.

The precondition of a use case can be interpreted as a boolean expression in a Java program. The corresponding actions are ﬁnding objects and links, F indObject() and F indLink(), as well as reading the object attributes in the database attribute get().

Concretely, if c ∈ C appears in precondition, it means to check whether object c exists in the current database by calling method C.find(c). An attribute reading can be directly coded as Java method get method.

Checking a postcondition Each use case describes a sequence of interactions between the actors of the use case and the system, and will be realized as sequences of interactions among objects which described in sequence diagrams in the design stage. The pre and post conditions of a use case describes the result of the execution of the uses in terms of its pre and post states without any details of the interactions among system objects in the design interaction diagrams. Prototyping is to ﬁnd the executable parts of a use case speciﬁcation and translate them into atomic actions of the SEOD. These atomic actions include attribute set, AddObject, AddLink, RemoveObject, and RemoveLink.

Obviously, each use case generally involves only a few objects. It is not difficult to find out the participating objects and links from the pre and post conditions of the use case. From the precondition, the participating objects and links in the pre state can be identified and put into the sets preobject and prelink of objects. Similarly, two set variables postobject and postlink of objects are used for the postcondition. Of course, a tool can also be designed to generate the sets of objects and links automatically by parsing the pre and post conditions. Another informal way is that we can directly get the four sets from the use case state transition diagram like figure 3.

The four sets contain the information about the change of the SEOD from the pre state to the post state. From the four sets, we know that if the use case is successfully executed to, as required, create all the new objects in createobject and all the new links in createlink in the post state, and delete all the old objects

Report No. 307, September 2004 UNU-IIST, P.O. Box 3058, Macau Generate an Executable Prototype 12

from deleteobject and all the old links from deletelink in the pre state. The four sets objects and links to be created and deleted can be calculated by following formulas.

createobject = postobject − preobject; deleteobject = preobject − postobject; createlink = postlink − prelink; deletelink = prelink − postlink;

For example, according to the speciﬁcation of use case LendCopy, its precondition relates two existing objects, a user u and a copy c, and its postcondition requires to create a new object, loan `, and two links, < u, ` > and < `, c > (see Figure 3). We thus get the following four sets:

preobject = {u, c}; postobject = {u, c, `}; prelink = ∅; postlink = {< u, ` >, < `, c >}

And the set of objects and the set of links to be created:

createobject = {`}; deleteobject = ∅; createlink = {< u, ` >, < `, c >}; deletelink = ∅

So the corresponding Java source code of use case LendCopy method can be generated as follows.

public void LendCopy(String cid, String uid){ if (User.find(uid) == false) {System.out.println(”Cannot ﬁnd object” + uid)}; else u = User.get(uid); if (Copy.find(cid) == false) System.out.println(”Cannot ﬁnd object” + cid); else {c = Copy.get(cid); if (c.available get() == false) System.out.println( cid + ”is not available”); else {` = new Loan(lid); Loan.add(lid); T akes.add(< uid, lid >); Borrows.add(< lid, cid >); c.availableset(false); } }}

To summarize, a prototype of a use case demonstrates the sequences of atomic actions on the SEOD. The first step is to check the precondition on preobject and prelink, i.e. any object and link in the two sets should exist in the SEOD; otherwise, the use case will preform alternative exception scenarios. Also, the precondition should be checked to ensure that the objects and links to be created in createobject and createlink should not exist in the database in the pre state. And if the precondition on preobject and prelink holds, prototype should first create the objects in createobject, second create the links in createlink, and then delete the links from deletelink, and finally delete the objects from deleteobject. For example, in the use case LendCopy, a loan ` should be created, i.e. ` ∈ createobject. There is a corresponding predicate in the post condition:

Report No. 307, September 2004 UNU-IIST, P.O. Box 3058, Macau Generate an Executable Prototype 13

Loan0 = Loan ∪ {`}. Similarly, for deleting a copy c in use case RemoveCopy, i.e. c ∈ deleteobject, there is a predicate like Copy0 = Copy − {c} in the post condition. Supposing that the four sets has already deﬁned, the algorithm in pseudo code about atomic actions on database is shown as follows.

Exception = false;

** check whether all objects of preobject set exisit in pre-state **

preob = preobject; while preob 6= ∅ do { object = getelement(preob); if CV ar.find(object) == false then {print(object + ” is not in system”); Exception = true; } preob.delete(object); }

** check whether all links of prelink set exist in pre-state **

prelk = prelink; while prelk 6= ∅ do { link = getelement(prelk); if AV ar.find(link) == false then {print(link + ”is not in system”); Exception = true; } prelk.delete(link); }

** check whether all objects of createobject set do not exist in pre-state **

createob = postobject − preobject; while createob 6= ∅ do { object = getelement(createob); if CV ar.find(object) == true then {print(object + ”has existed in system”); Exception = true; } createob.delete(object); }

** check whether all links of createlink set do not exist in pre-state **

createlk = postlink − prelink; while createlk 6= ∅ do { link = getelement(createlk); if AV ar.find(link) == true then {print(link + ”has existed in system”); Exception = true; } createlk.delete(link); }

if Exception == false then {

Report No. 307, September 2004 UNU-IIST, P.O. Box 3058, Macau Generate an Executable Prototype 14

** create all objects of postobject set in post-state **

while createobject 6= ∅ do { object = getelement(createobject); createobject.delete(object); AddObject(object); print(”Create object” + object); }

** create all links of postlink set in post-state**

while createlink 6= ∅ do { link = getelement(createlink); createlink.delete(link); AddLink(link); print(”Create link” + link); }

** delete all links of deletelink set in post-state. **

while deletelink 6= ∅ do { link = getelement(deleteLink); deletelink.delete(link); RemoveLink(link); print(”Delete link” + link); }

** delete all objects in deleteobject set in post-state **

while deleteobject 6= ∅ do { object = getelement(deleteobject); deleteobject.delete(object); RemoveObject(object); print(”Delete object” + object); } }

Some complex predicates in the postcondition describe the complex algorithm of use case on several attributes from different objects. They may not be not executable in the early requirements analysis stage, and need to be reﬁned to be executable in the later. It is acceptable for a prototype to ignore the non-executable parts. However, prototype can print out the corresponding information to explain the post state should make the predicates hold.

0 General predicates in a postcondition on setting values to attributes are in the form of ob.x = f(ob1.a, ob2.b) where a, b and x are attributes of objects ob1, ob2 and ob. It can be easily coded in Java programming as ob.xset(f(ob1.aget(), ob2.bget())) by calling the corresponding attribute get and set methods.

Generating system prototype After constructing the SEOD from CCM and mapping each use case to a method of the UCH from UCM, we can get the prototype as follows.

package library;

Report No. 307, September 2004 UNU-IIST, P.O. Box 3058, Macau Prototyping Library System 15

public class Library{

public static void main(String arg[ ]){ read(s); while s 6= stop do { if s =0 AddCopy0 AddCopy(cid, pid); ··· ; if s =0 ReturnCopy0 ReturnCopy(cid, uid); read(s); } } public void AddCopy(String cid, String pid){· · ·}; ··· ; public voidReturnCopy(String cid, String uid){· · ·}; }

4 Prototyping Library System

Based on the method described in the previous section, a tool is developed to generate prototype automatically in Java programming language shown in Figure 4. The tool is developed by using Java and XML by input information of use case diagram and conceptual class diagram in XML ﬁles generated from MagicDraw or Rational Rose CASE tools, as well as pre and post object and link sets information for each use case.

A prototype has three parts as deﬁned by the architecture shown in Figure 1: the SEOD generated after inputting the CCM, the system prototype interface that shows the buttons for execute all the system use cases, and a UCH which deﬁnes system methods for each use case.

The SEOD stores the current state of the requirements, i.e. a object diagram of the CCM. We need for each class, such as Copy, a class name“Copy”, and its attribute names cid and available as well as their types ’String’ and ’Boolean’. The tool will deﬁne a class Copy in SEOD, and generate class CopyDB (realize the global variable Copy) to store all the objects of class Copy in the system, and provide the general methods find(), add() and delete() for the class Copy().

The system prototype interface is generated by inputting use case names. The generated prototype interface of library system is shown in Figure 5.

If the name of a use case on the prototype interface is clicked, the corresponding UCH of the use case is invoked. A method of a UCH is generated by inputting the use case information deﬁned in the pre and post conditions deﬁned in early sections, such as preobject, postobject, prelink and postlink. For example, if the use case LendCopy is clicked on the interface in Figure 5, the corresponding UCH method LendCopy will be invoked, and its function is prototyped as shown in Figure 6.

5 Discussion and Conclusion

Based on the formalization of a UML model requirements [LLH01, LLH], a method of prototyping is proposed. A prototype contains three main parts as shown in Figure 1: SEOD generated from the UML concep-

Report No. 307, September 2004 UNU-IIST, P.O. Box 3058, Macau Discussion and Conclusion 16

Figure 4: Interface of prototype generator tool

Figure 5: Prototype interface of library system tual class model, a system prototype interface generated from names of the use cases in the use-cased model, and a UCH generated from each use case in the UCM. The key idea is to map the formal specification of a use case defined on the CCM in pre and post conditions to a set of executable atomic actions on the SEOD. The source code of prototype can be generated automatically by tool support. An automated generator has been developed and will be improved for adapting the complex composed use case with an interaction event flow, including and extension cases [Coc01]. We can introduce a sub-interface with some buttons for system interactions in the complex use case which can be decomposed into basic use cases by << include >> and << extend >> relationships [Plo04]..

The method can be used to generate an evolutionary system prototype [Som00] step by step following the iterative and incremental RUP. And at same time it can also be used to generate rapid throw-away prototypes. The framework nicely complements the ideas about engage customers and that scenarios deﬁne problem [Cop95]. Meanwhile, the prototype system can also be modiﬁed to generate different styles corresponding to customers, system analysts, system designers. For example, customers are generally interested in system level interaction and explorative dialog prototypes; and system designers usually pay more attention on system internal interactions among application domain objects.

The prototype generation is fully supported by the formal method developed in [LLH01, LLH]. That model is based on the simple set theory and predicate logic, rather than a particular formal language, such as Z or VDM. The semantics of a use case is deﬁned in the context of a CCM as a design in Hoare and He’s UTP [HH98]. Of course, we can use OCL in [WK99] for the proposed method. The pre and post conditions, and

Report No. 307, September 2004 UNU-IIST, P.O. Box 3058, Macau References 17

Figure 6: Prototyping LendCopy use case invariants in OCL are generally used to deﬁne methods in a class. However, generally several objects consists of the context of a use case. It is not easy to specify a use case in OCL by association navigation way by starting from one object context. Therefore, we chose the simple predicate logic from Hoare and He’s theory in [HH98] that is easier to understand than other formalisms such as the description declarative language in OCL and the one used in other work on formalizing UML (see the webpage of the precise UML consortium at www.pum.org).

A prototype generated from a formal model of requirements can support the practical use of the underlying formal theory. For example, we can use such a prototype to check system invariants, such as multiplicity constraints, that describe the static conditions that should always hold on any stable state of the system database. This is done in a similarly way by coding the invariants into the pre and post conditions. Prototyping this way can also be used for checking the consistency between a CCM and a UCM as the precondition will be eval- uated to false if the CCM is not consistent with a use case in the UCM. Prototypes of two UML models of requirements can be compared to check whether one model is a reﬁnement of another and this allows software engineers to use the formal method without the need to worry about the “formalities”.

Future work will focus on improving the method and its automated prototype generator tool with some AI techniques to handle non-deterministic and algorithmic non-executable speciﬁcations into executable ones, as well as combining design models (class diagrams, sequence diagrams, state diagrams, and activity diagrams) by referring to work and tools of D. Harel’s Play-Engine [HM03] and I-Logic’s Rhapsody as well as the executable UML for model-driven architecture [MB02].

Acknowledgement: The ﬁrst author would like to thank his master student, Percy Loi for implementing the prototype generator tool.

References

[Coc01] A. Cockburn. Writing Effective Use Cases. Pearson Education, 2001.

[Cop95] J. Coplien. A development process Generative Pattern Language. AT & T, 1995.

[HH98] C.A.R. Hoare and J. He. Unifying theories of programming. Prentice-Hall, 1998.

[HM03] D. Harel and R. Marelly. Come, Let’s Play, Scenario-Based Programming Using LSCs and the Play-Engine. Springer-Verlag, 2003.

[JBR99] I. Jacobson, G. Booch, and J. Rumbaugh. The Uniﬁed Software Development Process. Addison- Wesley, 1999.

Report No. 307, September 2004 UNU-IIST, P.O. Box 3058, Macau References 18

[Kru00] P. Kruchten. The Rational Uniﬁed Process – An Introduction (2nd Edition). Addison-Wesly, 2000.

[Lar01] C. Larman. Applying UML and Patterns. Prentice-Hall International, 2001.

[Lee01] R.C. Lee. UML and C++: a practical guide to object-oriented development, 2nd. Prentice Hall, 2001.

[Liu01] Z. Liu. Object-oriented software development in UML. Technical Report UNU/IIST Report No. 228, UNU/IIST, P.O. Box 3058, Macau, SAR, P.R. China, March 2001.

[LLH] Z. Liu, X. Li, and J. He. Using transition systems to unify uml models. In ICFEM2002, in LNCS 2495, Shanghai, China. Springer-Verlag.

[LLH01] X. Li, Z. Liu, and J. He. Formal and use-case driven requirement analysis in UML. In COMP- SAC01, pages 215–224, Illinois, USA, October 2001. IEEE Computer Society.

[LSHZ94] H. Lichter, M. Schneider-Hufschmidt, and H. Zullighoven. Prototyping in industrial software projects–bridging the gap between theory and practice. IEEE Transactions on Software Engineer- ing, 20:825–832, 1994.

[MB02] S.J. Mellor and M. J. Blacer. Executable UML: A Foundation for Model-Driven Architecture. Addison-Wesley, 2002.

[Mey97] B. Meyer. Object-oriented Software Construction (2nd Edition). Prentice Hall PTR, 1997.

[MM02] R. Mitchell and J. McKim. Design by Conctract by Example. Addison-Wesley, 2002.

[MP81] Z. Mana and A. Pnueli. The temporal framework for concurrent programs. In R.S. Boyer and J.S. Moore, editors, The Correctness Problem in Computer Science, pages 215–274. Academic Press, 1981.

[Plo04] Reinhold Plosch. Contracts, Scenarios and Prototypes: An Integrated Approach to High Quality Software. Springer-verlag, 2004.

[RJB99] J. Rumbaugh, I. Jacobson, and G. Booch. The Uniﬁed Modelling Language Reference Manual. Addison-Wesley, 1999.

[Smi91] M.F. Smith. Software Prototyping: Adoption, Pratice and Management. McGraw-Hill, 1991.

[Som00] I. Sommerville. Software Engineering (6th Edition). Addison-Wesley, 2000.

[WK99] J. Warmer and A. Kleppe. The Object Constraint Language: precise modeling with UML. Addison-Wesley, 1999.

Report No. 307, September 2004 UNU-IIST, P.O. Box 3058, Macau