UNU/IIST
International Institute for Software Technology
UNU/IIST Report No. 235
A Formal Design of Online Ticketing
Sys-tem in UML
Xiaoshan Li, Zhiming Liu and Zhengshen Guo
July 2001UNU/IIST and UNU/IIST Reports
UNU/IIST(United Nations University International Institute for Software Technology) is a Research and Training Centre of the United Nations University (UNU). It is based in Macau, and was founded in 1991. It started oper-ations in July 1992. UNU/IISTis 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 supplyUNU/IISTwith its office premises and furniture and subsidise fellow accommodation.
The mission ofUNU/IISTis to assist developing countries in the application and development of software tech-nology.
UNU/IISTcontributes 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. Courses, which typically teach advanced software development techniques,
6. Events, in which conferences and workshops are organised or supported byUNU/IIST, and
7. Dissemination, in whichUNU/IISTregularly distributes to developing countries information on interna-tional 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 ofUNU/IISTis onformal methodsfor software development. UNU/IISTis an internationally recognised center in the area of formal methods. However, no software technique is universally applicable. We are prepared to choose complementary techniques for our projects, if necessary.
UNU/IISTproduces a report series. Reports are either Research R, Technical T, Compendia C or Adminis-trative A . They are records ofUNU/IISTactivities and research and development achievements. Many of the reports are also published in conference proceedings and journals.
Please write toUNU/IISTat P.O. Box 3058, Macau or visitUNU/IISThome page: http://www.iist.unu.edu, if you would like to know more aboutUNU/IISTand its report series.
UNU/IIST
International Institute for Software Technology
P.O. Box 3058 Macau
A Formal Design of Online Ticketing
Sys-tem in UML
Xiaoshan Li, Zhiming Liu and Zhengshen Guo
Abstract
E-commerce systems have been changing the traditional business activities through the Internet. An
e-commerce system can be seen as a client-server system in which a server maintains some information and provides a searching function to a client. However, for an e-commerce system, we also need to consider two specific functions for booking products and carrying out payment transactions. Using an online ticketing system as a case study, this paper presents a formal use of the Unified Modelling Language (UML) to the analysis and design of e-commerce systems. We demonstrate how the formalization given in [13,14] can be used in formal specification of the system functional requirements, safety and liveness
constraints, and in verification of the correctness of the design.
Xiaoshan Li is an Assistant Professor at the University of Macau. His research areas are Interval
Tem-poral Logic, formal specification, verification and simulation of computer systems, formal methods in system design and implementation. E-mail: fstxsl@umac.mo
Zhiming Liu is a Visiting Scientist at UNU/IIST, on leave from Department of Mathematics and
Com-puter Science of the University of Leicester, Leicester, England, where he is lecturer in comCom-puter sci-ence. His Research interests include theory of computing systems; formal methods for specification, verification and refinement of fault-tolerant, real-time and concurrent systems; and formal theories and techniques for Object-Oriented and Component-Based development. E-mail: Z.Liu@mcs.le.ac.uk
Zhensheng Guo is a Professor at the University of Macau. Her research areas are network
communica-tion systems, E-commerce system analysis and design. Email: fstzsg@umac.mo
Copyright c
1
2
1
A Formal Design of Online Ticketing System in UML
*Xiaoshan Li♦, Zhiming Liu♣ and Zhensheng Guo♦
Abstract
E-commerce systems have been changing the traditional business activities through the Internet. An e-commerce system can be seen as a client-server system in which a server maintains some information and provides a searching function to a client. However, for an e-commerce system, we also need to consider two specific functions for booking products and carrying out payment transactions. Using an online ticketing system as a case study, this paper presents a formal use of the Unified Modeling Language (UML) to analysis and design of e-commerce systems. We demonstrate how the formalization of UML given in [13,14] can be used in formal specification of system functional requirements, safety and
liveness constraints, and in verification of the correctness of a design.
Keywords: UML, E-commerce, Formal Techniques, Safety, Liveness,
Object-Orientation.
1.
Introduction
With the development of Internet techniques, demand in the study of theories and methods in the development of e-commerce systems is being increased dramatically [11]. Through the Internet, an e-commerce system connects buyers with sellers in different places. Sellers can distribute their commercial product information, and accept orders made from buyers and sell their products 24 hours a day. As with a client-server system, a buyer can get the information from a server (seller) by using a web browser and transfers information such as booking and payment. Thus, e-commerce systems can be viewed as a special kind of client-server systems which provide some electronic business services on the Internet. However, beside searching
*
This work is partly supported by the British EPSRC Grant GR/M89447, Macau Secretary of Social Affairs and Culture e-Ticketing Project, and Research Committee of University of Macau.
♣ On study leave from the University of Leicester and working as a Guest Scientist at the International Institute
for Software Technology of the United Nations University (UNU/IIST), Macau.
♦Faculty of Science and Technology University of Macau
PO Box 3001, Macau, China Email: fstxsl{fstzsg}@umac.mo
♣ Department of Mathematics and Computer Science
University of Leicester, UK Email: z.liu@mcs.le.ac.uk
2
and providing information functions of general client-server systems, two other functions: booking products and payment transactions are specific for e-commerce systems.
UML [4,5,6] is a general-purpose visual modeling language for specifying, constructing, and documenting the artifacts of a software intensive system. It is based on object-oriented methodology, and accepted as an international standard modeling language by Object Management Group (OMG). UML has been applied to describe the different develop stages from high-level requirements to design and implementation [6,9], and is supported by the CASE tools of UML, Rational Rose 2000 [8]. UML is also suggested to be used for business modeling that is one of the first problems to be considered in the development of an e-commerce system [1].
In UML, system functional requirements are specified with a use-case model that contains the use cases and use-case diagrams [4,5,6,15]. As for the non-functional requirements, also called constraints, textual comments are generally used with UML diagrams. OCL (Objectary Constraint Language) [12], in a form of first order logic, is used as an extension mechanism of UML for a kind of formal description of such constraints. However, without a formal semantics for use cases and class diagrams, the use of OCL is very much limited and cannot be fully formalized. In the paper, we use a formalization in [13,14] given for the UML models used in requirement analysis to describe these constraints as well as the functional requirements. After analyzing the system requirements, we can use the unified use-case driven, iterative and incremental software development process to develop the system [6]. That is to say, we can first give the system static and dynamic design step by step according to use-case driven analysis [13]. In UML, the static structure of the system is modelled as class diagrams, and the system dynamic behavior models are described by sequence diagrams or collaboration diagrams, state diagrams and activity diagrams. The deployment and component diagrams of UML are used to describe the system architecture models and management. The correctness of system design is mainly concerned with whether the class diagrams with interaction diagrams (sequence diagrams, collaboration diagrams, state diagrams and activity diagrams) can realize use cases and satisfy constraints.
Research is currently very active in using UML for modeling general software systems [4,5,6,7,8] and e-commerce systems in particular [1,2,3]. However, there is still little work on formal use of UML in the development of e-commerce systems. Wang’s paper [11] briefly discusses assurance model checking in e-process design. However, it does not present the formal semantics of UML and formal specifications of e-commerce system design. Base on our work in [13, 14] about a formal use of UML, this shows how a formal method can be used in the development of an e-commerce system. For this purpose, we shall use a case study of an online ticketing system that is being developed for Macau Secretary of Social Affairs and
3
Culture [10] . We will also show that formal use of UML is necessary for developing e-commerce systems that often require high reliability and performance. For example, the online ticketing system is a real-time system accessed concurrently by clients, and there are some possible faults such as network disconnection and long time idles of clients, safety and liveness properties and fault-tolerance should be considered formally. For the booking function of the ticket system, the following properties should be considered in the design.
Safety: One ticket must be paid and printed by the customer who has booked it. Liveness: Any ticket cannot be reserved or booked infinitely without paying. Fairness: If a ticket is available, the first coming customer could reserve or book it.
The reminder of this paper is arranged as follows. Section 2 introduces the general model of e-commerce system and its main functions as well as the system architecture. The online ticketing system as a case study is first briefly introduced in Section 3, and then we analyze and design the system by using UML. Focusing on the typical booking service of e-commerce system, we demonstrate how to formally use UML to give the system design in detail. Meanwhile the correctness of booking function with fault-tolerance is verified. Section 4 presents formal specification of the system safety and liveness properties in interval temporal logic. Finally, Section 5 summarizes the contributions of this paper.
2.
General Model of E-Commerce System
E-commerce systems are designed to provide some business services through the Internet. Giving a general model of e-commerce is very useful for the practical system analysis and design.
Business process includes three flows which are information flow, money flow, and material flow. Obviously, the information flow can be handled well in an e-commerce system through the Internet that can be seen as a huge distributed system connecting all the information systems all over the world. With the development of new techniques in network communication, the money transactions among buyers, sellers, agents, brokers, and their banks, will become more and more effective and efficient with high security. It is a trend for the global world economy to use electronic money instead of real note money. The e-commerce systems will be widely adopted by the modern business companies. As for the material flow, we have to adopt the traditional ways of transactions but with efficient aids of the Internet information systems. The advantage of e-commerce system is that the communication between buyer and seller through the Internet is faster and more efficient than the traditional ways.
4
Actually, e-commerce systems provide virtual trade markets or shops for the interaction between buyers and sellers, which are two typical kinds of system users, also called actors in UML. Buyers (clients) can search for useful product information from the sellers’ servers using IE or Netscape web browsers through the Internet. A seller is responsible for providing the information of products onto the server. In addition to this search function, a buyer can also make orders with a seller and pay for the orders by credit cards, or other bank money transactions. After receiving an order and the payment from a buyer, the seller (server) provides and delivers the ordered products to buyers via train or airplane. Of course, sometimes, an invoice will be issued to the buyer from the seller before the payment is made. The basic functions of an e-commerce system are described as UML use cases and their relationships with the actors are simply modeled as the use case diagram in Figure 1. The typical actors (system users and environmental systems) of an e-commerce system are buyers (customers), agents, brokers, sellers (companies), system administrator, banks of system users, etc. And the typical use cases are searching information, booking products, paying products, bank transaction, issuing invoice, delivering products, refunding, canceling order, maintaining server database, etc.
A dd-pro duct D eliver-P ro duct S eller S earch B o o k P ay B uyer
Figure 1: The Basic Use Case Diagram of E-Commerce System
The architecture of e-commerce system is a common client and server system. The online ticketing system includes three servers: web server, application server and database server, described in UML deployment diagram shown in Figure 2. Clients access information from the database of the server via the Internet. The seller in the server side is responsible for maintaining system and administrating the database. The main tasks of system software development include two parts; one is the database design and the other is the control software component in the server, which is responsible for data communication between database and
5
clients. The system integrates software, hardware, and network communication techniques such as HTML, XML, JSP, ASP, Java, SQL, HTTP, Oracle Database and so on.
Clie nt-1 Client- n Internet HTT P HTT P A P Se rve r S UN E2 50 DB Se rve r S UN E2 50 W e b S erver Ultra 10 custom er custom er
Figure 2: Deployment Diagram of E-Commerce System Architecture
The most important class of e-commerce systems is the class product, which can be a class such as book, computer, air-ticket, car, and even a service, etc. The product of online ticketing system is the class ticket. The other typical classes are customer, agent, bank account, agent,
order, company, and so on. The general conceptual model [13,14,15] describes classes and
their relationships in the application domain. How to abstract classes and analyze the relationships can be found in lots of textbooks on UML and object-oriented analysis and design [1,4,5,6,7,8,15]. Here we only define ticket and customer classes of online ticketing system in an abstract level and the booking association shown in Figure 3. The basic attributes and operations of classes ticket and customer are listed in the diagram. We will discuss them in detail in later sections.
T icket seatN o-info status ticket-price user timestamp reserve() book() pay() print() release() S tate() C ustomer name pe rsonal-info bo okticketset getname() getin fo() number ticket() 0..n 0..1 0..n 0..1 b o ok in g
Figure 3: The Class Diagram of Ticket and Customer
…
6
3. Analysis and Design of Online Ticketing System
More and more people have been using the Internet where they can easily get the information they are interested in. Obviously, people prefer booking tickets in advance than going to ticket agent to buy in office hours. People can book tickets first, and then decide to buy the tickets later. And people can pay by their credit cards through the Internet and even more they do not need to go to ticket selling agents. The tickets can be sent to people’s home, or customers print their virtual tickets at home, or tickets are recorded in people’s personal IC card. Therefore, now many online ticketing systems have been developed and used on the Internet. We are developing one such system at the University of Macau for the Macau Secretary of Social Affairs and Culture. The project aims to maintain and provide the information of social and cultural activities in Macau, and to provide online services of booking and selling tickets. Although the system is a specific online ticketing system, the insights from this case study are helpful in the understanding, design and analysis of general e-commerce systems.
In this section, we will first analyze the system requirements and draw the use case diagram. Then focusing on one key use case, booking tickets, we demonstrate how to formally specify requirements and constraints in UML. We shall following the technique in [13,14] to define an atomic use case in the form of Pre|--- Post with its pre and post conditions in first-order logic. Composite use case can be defined in the notation of He and Hoare’s Unifying Theory of Programming [18]. Furthermore, we shall employ temporal logic to express the system dynamic behavioral properties of the system. These formal treatments are essential to guarantee the correctness of system design.
3.1 Use case diagram
For simplicity, we draw the use case diagram for the online ticketing system in Figure 4. For customer actor, there are three use cases: Search, Book and Pay. Agent is responsible for issue ticket for paid customers. Meanwhile, agents can also book and sell tickets through the Internet for those customers who can not access the Internet. People can go to agents or telephone agents to book tickets. Therefore, agent actor is a subclass of customer. That means the agent can access all use cases of customer. For the event provider actor, there are three use cases which are Provide-event, Provide-ticket, and Maintainsystem. Here we just briefly describe them as follows.
(1). Search: Users can search for the information of events to be held in Macau, such as movies, sport contests, exhibitions, car racing, etc.
(2). Book: Customers can book the tickets which they select from the seat plan online.
7
(3). Pay: Customers can pay their bookings by credit cards on line, or ATM or cash. (4). Issue: Ticket agents can issue tickets for the customers who have paid tickets. (5). Provide-event: Provider can create new events in the web server.
(6). Provide-ticket: Provider can create new tickets on an event.
(7). Maintainsystem: Provider is responsible for maintaining system, such as deleting tickets.
Book Pay Search Buyer Agent Issue Provide-event Provide-ticket Provider M aintainsytem
Figure 4: The Use Case Diagram of Online Ticketing System
In terms of a formal semantics, each use case can be considered as a process, and it will be realized as one or several sequences of operations by the design class diagram and collaboration (or sequence) diagrams in UML. The entire system is the parallel or non-deterministic composition of those processes. Therefore, the ticket system can be specified as an eTS process.
eTS=def Search⇑⇑Book⇑⇑Pay⇑⇑Issue⇑⇑Provide-Event⇑⇑Provide-Ticket⇑⇑Maintainsystem→→eTS
in which the operator “⇑⇑” denotes for non-deterministic choice or parallel composition, and “→→” for prefixing operator.
In [13, 14], each step of a use case can be defined as a system operation on conceptual model. For the variable X, the notation X’ denotes the value of X at the next state after executing an operation. Here we use the framing assumption, where a variable will keep its value unchanged in an operation if its primed version does not appear explicitly in the post condition of the operation. In addition, we need to introduce a temporal state variable, status for ticket class, that is an attribute class ticket. In conceptual model, the state of any ticket should be in one of Available, Booked, Paid and Printed states. Later in the design state diagram, we should introduce another state, Reserved. The variable status is the function: Ticket →{Available,
8
Reserved, Booked, Paid, Printed}, and we use t.status to denote the status of ticket t in a state. The association between class Ticket and class Customer is booking, a set of pairs like <u,t> which means customer u is booking ticket t. The multiplicity constraints on association booking can be specify formally as follows.
∀
∀ t ∈∈ Ticket. # { u: Customer | <u, t> ∈∈ booking } ∈∈ {0..1} /\
∀
∀ u ∈∈ Customer. # {t ∈∈ Ticket | (<u, t> ∈∈ booking } ∈∈ {0..n}
in which operator ‘#’ calculates the total element number of the set. As for n, we make a constraint on “n” to limit that customer cannot buy more than n tickets.
The use case Book can be defined by pre and post conditions style of [13,14] as follows.
Book (u, t) = def
Pre-Cond: u ∈∈ Customer /\ t ∈∈Ticket
Post-Cond: (t.status=Available ⇒⇒ t.status’ = Booked /\ booking’=booking ∪∪ {<u, t>}) \/ (t.status≠≠ Available ⇒⇒ReturnInfo= “Ticket t is unavailable. Select new one instead” )
It means that the pre-condition of use case Book(u,t) requires input parameters u and t are existing objects of classes Customer and Ticket; if pre-condition holds, then the function Book will be executed and make a transition from the current state to new one where the result should satisfy the post-condition, that is, if t is available, it will be booked to customer u finally. Otherwise, the function will return the information “Ticket t is unavailable. Select new one instead”. Similarly, Pay and Issue can be defined as follows.
Pay(u, t) = def
Pre-Cond: u∈∈ Customer /\ t ∈∈Ticket /\ t.status=Booked /\ <u,t>∈∈booking Post-Cond: t.status’= Paid
Issue(u,t) = def
Pre-Cond: u ∈∈Customer /\ t ∈∈ Ticket /\ t.status=Paid /\ <u,t>∈∈booking Post-Cond: t.status’ = Printed
The use cases Book, Pay and Issue are almost directly implemented by the operations book,
pay and print of class ticket. We just use this simplified case study to demonstrate the
relationship among the different models of UML.
3.2 Class diagram
9
After drawing the use case diagram and describing each function in natural language [10], we present them to the government project investigators and engineers. Obviously, the use cases of customer and agent actors will be realized by calling the sequences of operations of ticket objects which will be defined in collaboration diagram. For the Book use case, it is realized by calling first reserve operation, and then book operation. Since any ticket is unique, it cannot be booked by two customers. Executions of the operations/methods of the same ticket object must be mutual exclusive to avoid multi-booking. In Java programming language, it supplies the synchronized function to control the object operation invocation mutual exclusion. Therefore, at any time, only one customer can be allowed to call one operation of a ticket. Consequently, system data inconsistency can be avoided. The ticket class defines several basic atomic operations in the Figuress 3 and 4, which can combine together and cooperate with other objects to achieve some large system functions, use cases. Similarly, we use the techniques of [13,14] to define the basic operations of class ticket formally as follows, where t.user and
t.timestamp denote that the customer u such that <u,t>∈booking and the value of the attribute timestamp of ticket t respectively, and currenttime denotes the current value of the system
clock:
reserve(u, t) =def
Pre-Cond: u ∈∈ Custormer /\ t ∈∈ Ticket
Post-Cond: (t.status=Available ⇒⇒ t.status’ = Reserved /\ t.user’=u /\ t.timestamp’=currenttime) /\ (t.status ≠≠ Available ⇒⇒
ReturnInfo= “Ticket t is unavailable. Select new one instead” ) book(u, t) = def
Pre-Cond: u ∈∈Customer /\ t ∈∈ Ticket /\ t.status = Reserved /\ t.user=u Post-Cond: t.status’ = Booked /\ t.timestamp’=deadlinetime
pay(u, t) = def
Pre-Cond: u ∈∈Customer /\ t ∈∈ Ticket /\ t.status = Booked /\ t.user=u Post-Cond: t.status’ = Paid
print(u, t)= def
Pre-Cond: u ∈∈Customer /\ t ∈∈Ticket /\ t.status = Paid /\ t.user=u Post-Cond: t.status’=Printed
release(t)=def
Pre-Cond: t ∈∈Ticket
Post-Cond: t.status = Available
10 collect(t) =
Pre-Cond: t ∈∈Ticket /\ ((t.status=Reserved /\ (t.timestamp+10 min) ≥≥currenttime) \/ (t.status= Booked /\ t.timestamp≥≥currenttime))
Post-Cond: t.status’=Available
The formal description of multiplicity constraints of booking in the low-level design can be specified as follows.
∀∀ t ∈∈ Ticket. #{u: Customer | t.status = Reserved /\ t.user=u } ∈∈ {0, 1}
/\ ∀∀ u ∈∈ Customer. #{t ∈∈ Ticket | ( t.status ∈∈ {Reserved, Booked, Paid, Printed}) /\ t.user=u } ∈∈ {0..n}
3.3State diagram
One interesting problem of the system is the concurrent booking conflicts. The system certainly allows many users to access the ticket system at the same time. However, one ticket obviously can only be booked and sold to one customer. Booking race is the case which can not be avoided. For example, when two customers visit the server system at a same period, it is possible that both of them download the seat plan with the same available ticket information. Suppose each of them book ten tickets concurrently, but both of them select one same available ticket and put in their shop carts. Obviously, the ticket will be given to the customer who first delivers his or her booking. When the second customer delivers his or her booking, he or she will be told that the ticket is not available, and be asked to select a new available ticket instead. That is to say, the second customer’s booking action is not successful. If the system does not reserve the rest nine tickets for the second customer, he or she perhaps could not book successfully at next time because one or more of original nine available tickets may be taken by other customer again. Therefore, one customer may not book successfully for several times. To avoid this unfairness and make the booking service fair to customers, we should introduce a reserved state for ticket class in the system design. This is one constraint on the booking use case, i.e., the system should guarantee that the customer could definitely book the ticket if it is available when he or she delivers his or her booking. Hence, when a ticket is reserved, it is locked and cannot be booked by other customer.
On the other hand, we also need to avoid the bad case that tickets are always reserved but not booked. Therefore, the system should have a nonfunctional requirement that is no customer is allowed to reserve or book one ticket infinitely without making a payment. Otherwise, lots of tickets could not be sold out because they are reserved by a few customers but are not available
11
for other customers. Therefore, we make a constraint on the reserved state to be temporary, i.e., the server system will collect those reserved tickets when the tickets are reserved more than 10 minutes without being booked. Similarly, we also give a deadline for the booked tickets. If a booked ticket is not paid by a given deadline, it must be released compulsorily by the server.
According to the analysis of the booking use case, we can draw the state diagram of ticket in Figure 5. A ticket is initially available when a ticket is created. It is reserved when its reserve operation is invoked and executed, and afterward booked when the book operation is called to confirm by a customer within 10 minutes, then paid and printed. When a ticket is in the reserved state more than 10 minutes without being confirmed, it will be collected by the server to make it available again. We can design an active thread in the server that collects the outdate reserved tickets from the database once in every 5 minutes. Therefore, there is a time bound [10,15] for the transition from reserved state to available state. Similarly, there is a transition “timeout collect” from state booked to available. The state diagram of ticket can be modeled
as Figure 5.
Ava ila ble
R e serve d B o o ked P a id P rin te d re serve re le a se b oo k p ay p rin t re le a se [1 0 ,1 5] --> colle ct T imeO ut --> co llect
Figure 5: The State Diagram of Ticket
3.4Collaboration diagram
In UML collaboration diagram is used to model the dynamic behavior of the system. Several objects of system collaborate and interact each other according to a sequence order of operation invocations to provide system service to outside.
12
Figure 6 demonstrates the process how to buy a ticket, that is first to get the information about the ticket corresponding actions 1 and 2, and second to reserve a ticket (action 3). And then there are three possibilities:
(1). The customer disconnects with the server system; or idles long time more than 10 minutes. In this case, the server will collect the reserved ticket to make it available to other customers -- this is corresponding action 4.
(2). The customer changes his or her mind, and release (action 5) the ticket before the timeout.
(3).The customer sends the book request (action 6) on time. After then the ticket is booked for the customer. The system will set a deadline for the customer to pay the ticket. If the customer does not pay the ticket before the deadline, the system will collect the ticket and set it to be available again (action 7).
If the system receives the payment from the customer before the deadline, the ticket will be changed into paid state (action 8). Finally, the customer can ask an agent to issue the ticket and agent will print the ticket for the customer (actions 9 and 10).
:A ge nt
:C us tom er :Tic ket
:S eat Pla n
4: [10 , 15 ]-> c olle c t 7:Ti m eO ut-> c o llet
5: releas e 6: book 8: pay
9: is s ue-tic ket 10 : pr int
1: get -se atpla n
3: re s er ve
2: get-tic ketS tatus
Figure 6: The Collaboration Diagram of Book, Pay and Issue Use Cases
The behavior of above actions can be formally specified as a CSP process. Therefore, a use case is realized as one or more possible sequences of actions (operation invocations) by prefixing operator “ →”. The implementation of use case Book, denoted as Bookimp, can be
modeled as a process of a sequence of operations of objects. Similarly, Searchimp Payimp and
Issueimp are the corresponding to the implementations of Pay and Issue use cases. They can be
modeled as follows:
13
Bookimp =def reserve →→ (([10,15]→→collect) | release | book)
Searchimp =def get-seatplan →→ get-ticketStatus
Payimp =def release | pay | timeout→→ collect
Issueimp =def issue-ticket →→ print
Customerimp = def || Customerimp[u]
Customerimp[u] =def Searchimp[u] | Bookimp [u] | Payimp [u] | Issueimp[u]→→Customerimp [u]
The processes here are defined to specify the behavior of the system with a finite number of registered (i.e. active) customers and tickets.
The correctness of the design Bookimp with respect to the use case Book is concerned with
whether the postcondition of Book is guaranteed by Bookimp. However, this is too strong as the
design here has considered some timing constraints and fault-tolerance such that the effect of
Book will be only realized by Bookimp only when the booking is successful. That is, the pre
and postcondition definition of the trace reserave(u,t)
book(u,t) of the process Bookimp
implies Book:
reserve(u,t)
book (u,t)=
[ u∈∈Customer /\t∈∈Ticket |-- (t.status=Available ⇒⇒ t.status’ = Reserved /\ t.user’=u /\ t.timestamp’=currenttime) /\ (t.status ≠≠ Available ⇒⇒ ReturnInfo=
“Ticket t is unavailable. Select new one instead”)
;
u ∈∈ Customer /\ t ∈∈ Ticket /\ t.status = Reserved /\ t.user=u
t.status’ = Booked /\ t.timestamp’=deadlinetime]
⇓⇓
(implies)u∈∈Customer /\t∈∈Ticket |-- (t.status=Available ⇒⇒ t.status’ = Booked /\ booking’=booking ∪∪ {<u, t>}) \/
(t.status≠≠ Available ⇒⇒ReturnInfo=
“Ticket t is unavailable. Select new one instead” )
14
= Book(u,t)
Please see [18] about details of the calculus of designs of the form Pre |-- Post.
4. System Safety and Liveness Properties
The correctness of a system includes two aspects. One is the system should provide correct services, i.e., function requirements captured as use cases in UML. The other is that the system should also guarantee some non-functional requirements which are constraints and system properties. Because the safety and liveness properties are the assertions on the time interval behavior of systems, the temporal logic must be employed. Here we use interval temporal logic [16,17] to express the constraints and properties on booking function of online ticketing system.
Two useful temporal operators are “always” and “sometime”, denoted as “[]” and “ ◊◊”, respectively. Formula “[]A” holds on a given interval if and only if “A” holds on any subintervals. However, “◊◊A” holds on a given interval means that there exist at list one
subinterval where A holds. Those two operators can be derived by the basic interval temporal logic operator chop “ ; ”. Formula “A; B” holds if and only if the given interval can be chopped into two subintervals where A holds on the first and B holds on the second. The following are the definitions of “[]” and “ ◊◊” by chop.
◊◊ A= true; A ; true and [] A = ¬¬◊◊¬¬A
in which special formula “true” holds on any interval. We assume that for any state variable X, if X holds on current state, then X holds on any intervals from current state.
Now the constraints can formally specified as the following interval temporal formulas.
Safety 1: One ticket can only be paid and printed by one buyer who booked it.
[]∀∀t ∈∈Ticket ∀∀u1,u2,u3 ∈∈Customer.( t.status=Booked /\ t.user=u1) ; (t.status=Paid /\ t.user=u2) ; (t.status=Printed /\ t.user=u3))⇒⇒ u1=u2 /\ u2=u3)
This safety requires that the consecutive operation calls (reserve, book, pay and print) of a same ticket must be from a same customer. The mutual exclusion of these operations and their pre and postconditions guarantee this invariance property.
15 Safety 2: Ticket is not refundable.
[]∀∀ t ∈∈Ticket. (t.status=Paid ∨∨ t.status=Printed) ⇒⇒ [] (t.status= Paid ∨∨t.status=Printed)
This property can also be guaranteed by ticket state diagram if we only consider the meaningful life duration of ticket and ignore the delete operation after the event is cancelled.
Invariant 1. At any time, the total money of system received should always be equal to the
total money of all the sold tickets.
[] ReceivedMoney = ΣΣ { t.ticket-price | ∀∀ t ∈∈Ticket . (t.status=Paid \/ t.status=Printed}
This invariant can be used to design system variable ReceivedMoney.
Liveness 1. No ticket can be reserved infinitely without being booked or releasing available. ∀∀ t ∈∈Ticket . (¬¬◊◊ [] t.status=Reserved)
Server should be responsible for releasing the reserved tickets every 5 minutes. If a ticket has been reserved for more than 10 minutes, when it is checked by the server collecting thread which is executed every 5 minutes. That is to say, the reserved state of ticket is temporary. It must transfer from reserved state into booked or available states for no longer than 15 minutes. According to the system design of state diagram of ticket and server collecting thread, we can guarantee liveness property with 15 minutes up-bound (len is the duration of interval).
∀∀ t ∈∈Ticket. ( [] t.status= Reserved ⇒⇒ len ≤≤ 15 min. )
Liveness 2: Similarly, the booked state will be released if it is not paid. Because we set a time
deadline to the ticket attribute timestamp in the design of ticket operation book, the booked ticket will be collected by the server after the deadline. Thus we can get the following liveness property.
∀∀ t ∈∈ Ticket . (¬¬◊◊ [] t.status=Booked)
Please note that liveness properties here are implemented by timing properties. We can of course design an untimed system which guarantees the above absolute liveness properties under some fairness assumption on the operations. This also implies that the traditional
16
methods in dealing with invariant and liveness properties of computer systems still apply to e-commerce systems in our framework.
5. Conclusion and Discussion
In this paper, we use an online ticketing system as a case study to demonstrate important properties of e-commerce systems, and problems need to be considered in the design of such a system. We have presented some initial ideas about how to combine UML development methodology with formal techniques. Focusing on an interesting concurrent real-time booking function of an e-commerce system, a reliable design is presented according to the system analysis following the UML framework. Since UML cannot express the non-functional requirements, such as safety and liveness properties, which are very important to the system performance and correctness of an e-commerce system, a temporal logic is suggested to be useful to support UML analysis and design. Formal treatment of correctness of the design is discussed. We believe that the ideas presented in the work are fundamental and essential for formal use of UML and for the development of reliable e-commerce systems. The understanding and treatment of safety, liveness, timing properties and fault-tolerance of the online ticketing system can be applied to development of general e-commerce systems.
Future work includes the detailed formalization of the relationship of the interaction models with the use-case models, and properly adding real-time and fault-tolerance [19] into the framework. The former is about the combination of pre and postcondition definition of operations and CSP-like definition of the control flow. The later can follow the approach of Timed CSP that associates time stamps with events and Timed Linear Temporal Logic that adding time bounds to state transitions [19].
Acknowledgements: We wish to thank Prof. Jifeng He for the discussions on formalization of UML. And the first and third authors also thank all the members of e-ticketing project, Addie, Shirley, Tang, Zhiguo Gong, Prof. Yiping Li, Ximei Tan, etc, on the analysis, and design e-Ticketing Project in UML.
References
[1] Hans-Erik Eriksson and Magnus Penker: Business Modeling with UML, John Wiley& Sons, 1999.
[2] David Whiteley: E-Commerce: Strategy, Technologies and Applications, McGraw-Hill, 2000.
17
[3] Matthew Reynolds: Beginning E-Commerce with Visual Basic, ASP, SQL Server 7.0 and
MTS, Wrox Press Ltd., 2000.
[4] Grady Booch, James Rumbaugh and Ivar Jacobson: The Unified Modeling Language User
Guide, Addison-Wesley, 1999.
[5] James Rumbaugh, Ivar Jacobson and Grady Booch: The Unified Modeling Language
Reference Manual, Addison-Wesley, 1999.
[6] Ivar Jacobson , Grady Booch and James Rumbaugh: The Unified Software Development
Process, Addison-Wesley, 2000.
[7] Mark Priestley: Practical Object-Oriented Design with UML, McGraw-Hill, 2000.
[8] Terry Quatrani: Visual Modeling with Rational Rose 2000 and UML, Addison-Wesley, 2000.
[9] Dean Leffingwell and Don Widrig: Management Software Requirements: A Unified
Approach, Addison-Wesley, 2000.
[10] E-ticketing System Design in UML, technical report, University of Macau, June, 2001. [11] Wenli Wang, Zoltan Hidvegi, Andrew D. Bailey Jr., and Andrew B. Whinston: E-Process
Design and Assurance Using Model Checking, IEEE Computer, October 2000.
[12] Jos Warmer and Anneke Kleppe: The Object Constraint Language: Precise Modeling with
UML, Addison-Wesley, 1999.
[13] Xiaoshan Li, Zhiming Liu and Jifeng He: Formal and Use-Case Driven Requirement
Analysis in UML, to be published in COMPSAC2001, Chicago, USA, October 2001.
[14] Zhiming Liu, He Jifeng and Xiaoshan Li: Formalizing the Use of UML in requirement
analysis: Technical Report UNU/IIST report No228, UNU/IIST: International Institute for
Software Technology, The United Nations University, Macau, March 2001. A short version ‘Towards a formal use of UML for software requirement analysis’ is published in the proceedings of PDPTA2001, June 2001,Las Vegas, USA.
[15] Zhiming Liu: Object-Oriented Software Development Using UML, Technical Report UNU/IIST report No229, UNU/IIST: International Institute for Software Technology, The United Nations University, Macau, March 2001.
[16] Zhou Chaochen, C.A.R. Hoare, and A.P. Ravn: A Calculus of Durations, Information Processing Letters, 40(5): 269-276, 1991.
[17] Ben Moszhowshi: Excuting Temporal Logic Programs, Cambridge University Press, Cambridge, UK, 1986.
[18] Jifeng He and Tony Haore: Excuting Unifying Theories of Programmin, Prentice-Hall, 1998.
[19] Zhiming Liu and Mathai Joseph: Specification and Verification of Fault-Tolerance,
Timing and Schedulaing, ACM Transaction on Programming Languages and Systems, Vol. 21,
No. 1, 46-89, 1999.
