efficient and consistent transformation of uml …1.1 why uml diagrams? uml is an object-oriented...

EFFICIENT AND CONSISTENT TRANSFORMATION OF UML FUNCTIONAL

REQUIRMENTS INTO BPEL SPECIFICATIONS FOR SOA-BASED SYSTEMS

BY

ANISHA VEMULAPALLI

A RESEARCH PROJECT SUBMITTED IN PARTIAL FULFILLMENT

OF THE REQUIREMENTS FOR THE DEGREE OF

MASTER OF SCIENCE IN THE

DEPARTMENT OF COMPUTER SCIENCE

NARY SUBRAMANIAN, Ph.D., COMMITTEE CHAIR

DEPARTMENT OF COMPUTER SCIENCE

THE UNIVERSITY OF TEXAS AT TYLER

DECEMBER 2009

The University of Texas at Tyler

Tyler, Texas

This is to certify that the Master’s Project of

Anisha Vemulapalli

Has been approved for the research project requirement on 12/10/2009

For the Master of Science Degree

Approvals:

Dr. Narayanan Subramanian, Ph.D: ________________________________________________

(Project Chair)

Dr. George M. Whitson, Ph.D: ____________________________________________________

(Committee Member)

Dr. Kazeem Mahdavi, Ph.D: ______________________________________________________

(Committee Member)

Acknowledgement

Foremost, I would like to express my sincere gratitude to my advisor Dr. Narayanan

Subramanian for the continuous support of my Master’s study and research, for his patience,

motivation, enthusiasm, and immense knowledge. His guidance helped me in all the time of

research and writing of this project.

Besides my advisor, I would like to thank the rest of my project committee: Dr. George M.

Whitson and Dr. Kazeem Mahdavi, for their encouragement and insightful comments.

My sincere thanks also go to the faculty of the Department of Computer Science at the

University of Texas at Tyler for providing me an excellent platform to hone my computer skills

and achieve my Master’s degree.

I thank my fellow classmates in the University of Texas at Tyler, for the sleepless nights we

were working together before deadlines, and for all the fun we had in the last two years. Also, I

thank my best friend in the University of Texas at Tyler: Srividya Koganti, for her continuous

support and encouragement.

Last but not the least, this project could not have been accomplished without Gopala Krishna

Vellanki, my husband who is always with me no matter how dubious my decision was. He

always gives me warm encouragement and love in every situation. And, my parents who have

supported me since I was born. I owe deepest thanks to both of them.

TABLE OF CONTENTS

DESCRIPTION PAGE NO.

Abstract 1

Chapter 1

Introduction 2

1.1 Why UML Diagrams? 3

1.2 BPEL4WS or BPEL 4

Chapter 2

Efficient transformation of functional requirements into BPEL specifications 6

2.1 How does EaCTUML2BPEL approach work? 6

2.1.1 Mapping UML components and BPEL transformations 7

2.1.2 Validation Tools 7

2.2 Functional Requirements 8

2.3 UML Diagrams 8

2.4. XMI Document 8

2.5 BPEL Specification 10

Chapter 3

Consistent transformation of functional requirements into BPEL specifications 12

3.1 What is Consistency? 12

3.2 Importance of consistency 12

3.3 Why consistency can lack? 12

3.4 NFR Approach for Evaluating Consistency 12

3.4.1 Applying NFR Approach 13

Chapter 4

Case Study: Travel Reservation System 15

4.1 Description of Travel Reservation System 15

4.2 Functional Requirements of the TRS 15

4.3 UML models 16

4.3.1 Use case Diagram 16

4.3.2 Activity Diagram 17

4.3.3 Class Diagram 19

4.3.4 Sequence Diagrams 20-30

4.4 XMI Document 30

4.5 BPEL Specification 32

DESCRIPTION PAGE NO.

4.6 Mapping the Functional Requirements to the BPEL Specification 36

4.7 Evaluating Consistency between the above generated BPEL 37

specification and the UML functional requirements

4.7.1 Applying NFR Approach 37

4.7.1.1 Identifying the softgoals 37

4.7.1.2 Contributions of the softgoals 37

4.7.1.3 Applying Propagation Rules 38

Chapter 5

Conclusions and Future Work 40

Chapter 6

References 41

LIST OF FIGURES AND TABLES

FIGURE DESCRIPTION PAGE NO.

Figure 1: Process for developing SOA – based system using BPEL specification 2

derived from UML Functional Requirements

Figure 2: Relation mapping between the BPEL process and the WSDL 4

Figure 3: Transformation process from UML functional requirements 6

into BPEL Specifications

Figure 4: Exporting UML Diagrams into XMI document in VP-UML 9

Figure 5: Exporting XMI from VP-UML to NetBeans 9

Figure 6: Importing the XMI document into NetBeans environment 10

Figure 7: Transformation of XMI document into BPEL executable code 11

Figure 8: Use case Diagram for TRS developed in VP-UML 16

Figure 9: Activity diagram for TRS developed in VP-UML 17

Figure 10: Class Diagram for TRS developed in VP-UML 19

Figure 11: Sequence Diagram for the Login usecase scenario 20

Figure 12: Sequence diagram for register usecase scenario 21

Figure 13: Sequence Diagram for Make Reservation for Airline usecase scenario 22

Figure 14: Sequence Diagram for Make Reservation for Hotel usecase scenario 23

Figure 15: Sequence Diagram for Make Reservation for Vehicle usecase scenario 24

Figure 16: Sequence Diagram for Add Reservation for Airline usecase scenario 25

Figure 17: Sequence Diagram for Add Reservation for Hotel usecase scenario 26

Figure 18: Sequence Diagram for Add Reservation for Vehicle usecase scenario 27

Figure 19: Sequence Diagram for Cancel Reservation for Airline usecase scenario 28

Figure 20: Sequence Diagram for Cancel Reservation for Hotel usecase scenario 29

Figure 21: Sequence Diagram for Cancel Reservation for Vehicle usecase scenario 30

Figure 22: Exporting UML models to XMI Document 31

Figure 23: Percentage of Export Completed 31

Figure 24: Import XMI Document in NetBeans 32

Figure 25: Generate BPEL executable code from the XMI document 33

Figure 26: BPEL specification generated from the UML functional requirements 35

Figure 27: Softgoal Interdependency graph for Evaluating Consistency 38

between the BPEL specifications and the UML functional

requirements for the Travel Reservation System

TABLE DESCRIPTION PAGE NO.

Table 1: Mapping between UML components and BPEL transformations 7

1

Abstract

From the past few years, dependence on the online services has grown steadily which lead the

development of web applications to employ Service-Oriented Architecture (SOA) which is a

collection of services. These services communicate with each other to coordinate some activity.

The development of a SOA-based system begins with analysis of the system domain, capturing

functional requirements and then designing the system. To capture the functional requirements of a

system being developed, several techniques are employed. One of the techniques is to arrange

requirements-gathering meetings with the user to capture user-stories. These requirements, which

describe the intended behavior of the system, are called the functional requirements of the system.

These functional requirements can be captured in diagrams by using a general-purpose modeling

language such as Unified Modeling Language (UML) which models real-world objects. These

diagrams capture the actors, usecases, classes, objects, packages and their relationships. The

functional requirements of an SOA-based system can be expressed using a web services language

such as Business Process Execution Language for Web Services (BPEL4WS or BPEL) to capture

the business goals and objectives. In this project, an approach EaCTUML2BPEL (Efficient and

Consistent Transformation of UML functional requirements into BPEL specifications) to

transform the functional requirements captured in UML into BPEL Specifications is proposed by

providing a subsequent mapping between the captured UML models and the BPEL specifications.

NetBeans provides an environment to simulate the captured BPEL specifications. Initially, UML

models are developed from the identified functional requirements using Visual Paradigm for UML

(a UML modeling tool), and the captured UML models are transformed into an XMI document.

This XMI document is later transformed into BPEL specifications using NetBeans environment. It

is a known fact that functional requirements of any system keeps changing throughout the

development with the change in the client‟s needs. Hence consistency must abide between the

captured BPEL specifications and the functional requirements of the system being developed

satisfying the client‟s needs. The consistency is evaluated in this project using a Non-Functional

Requirements (NFR) approach. This approach is illustrated with an example web application

Travel Reservation System, starting with capturing the functional requirements, developing the

UML models, transforming the UML models into BPEL Specifications, and evaluating

consistency between the transformed BPEL Specifications and the functional requirements of the

system using NFR Approach.

2

CHAPTER 1

Introduction

Developing an SOA-based system comprises of, developing several independent services each

performing a unique well-defined task and making these services interact with each other. At the

first phase of the development of SOA-based system, the business domain must be clearly

analyzed and, user requirements of the system must be captured. The user requirements of the

system constitute both functional requirements and non-functional requirements (NFR‟s). The

functional requirements captures the intended behavior of the system representing what the user

wants the system to perform and, the non-functional requirements capture the overall properties

such as availability, reliability, robustness, security, performance, throughput etc. While

developing an SOA-based system both functional requirements and NFR‟s must be considered.

BPEL (Business process execution language) provides a means for expressing the functional

requirements of SOA-based system and simulate the behavior of the system in an environment

such as NetBeans. BPEL is an XML (Extensible Markup language) – based description language

for web services used to develop SOA – based systems. The initial business requirements are

captured as the functional requirements, and are modeled using UML diagrams. These UML

models are transformed into BPEL specifications with the appropriate mapping. Figure 1 depicts

how the UML models are transformed into BPEL Specifications and, later used for designing

SOA- based systems.

Figure 1. Process for developing SOA – based system using BPEL specification derived from UML Functional

Requirements [10]

However, the transformation from UML models to BPEL specifications is not direct. Initially, the

functional requirements of the system are captured. Then, the UML models are developed for the

system. These UML models are exported into an XMI (XML Metadata Interchange) document

which uses XML using an environment Visual Paradigm for UML, and later, this XMI document

is imported in an environment such as NetBeans and then transformed into a BPEL Specification.

During this transformation, the important requirement of the functional requirement – consistency

must be satisfied for the system. This is important because there are two different representations

of the functional requirements – one in UML models with usecases, user-stories and requirements-

UML Functional

Requirements

Functional Requirements

Model the processes with

BPEL4WS or BPEL

Specification

Design Service-oriented

Architecture (SOA)

Requirements BPEL/WSDL

Obtain processes

3

gathering meetings and the other in BPEL specifications with an executable code. Existence of

consistency between these two representations helps us in efficiently developing the SOA-based

systems, accurately meeting the user needs, identifying the test cases and detecting errors.

Some of the web applications found in the literature include but not limited to:

1. Student Housing System, a common web application where a student applies for the lease

logging into the system, and then the staff member verifies the student background in the

records, then decides whether to give him the house for lease or not.[10]

2. Travel Reservation System which is a web application developed to examine the client

itinerary to find whether any reservations pre-exist for the airline, hotel and/or vehicle or no

reservations pre-exist.[25]

3. Elevator control system modeled as a multiagent system where each elevator is an agent

collaborating with other elevators for reducing waiting time for people to use the elevator.

[28]

4. Air traffic control system which is a web-based system that is responsible for displaying

flight-related information to air traffic controllers[19]

5. Mycology Laboratory Information Management System (MYCO-LIMS), a web-based

complex system capable of providing services such as managing microarray gene

expression data and laboratory supplies, managing patients, physicians, managing and

tracking samples information, and managing orders. [12]

1.1 Why UML Diagrams?

UML is an object-oriented language for specifying, visualizing, constructing, and documenting the

artifacts of the systems and developing business models of the systems. In UML, the design of the

system is expressed in graphical notations suppressing the lower-level details. This gives an easy

communication, exploration of alternate designs, validation of the design, and re-implementation

of the design if necessary with a minimum knowledge. Functional requirements capture the actual

essence of what the system needs to do. Usecases have become a traditional way to capture these

functional requirements by giving a provision of interactions between the actors and the system

being developed.

Practitioners and industries always looks for automating the production of the software improving

the quality and reducing the cost and time to manage the system being developed. UML was

designed to respond to the needs of the industries such as, physical distribution, concurrency,

replication, security, load balancing and fault tolerance. UML is an expressive visual modeling

language providing the users ready-to-use to develop and exchange models, specialization

mechanisms to extend core concepts, and a formal basis for understanding the modeling language.

Independent of the particular programming language and development process, UML supports

higher-level development suppressing the lower level details.

4

UML Diagrams are created commonly using visual modeling tools. These diagrams include

usecase diagrams, class diagrams, sequence diagrams, collaboration diagrams, state diagrams,

activity diagrams, component diagrams, and deployment diagrams. Usecase diagrams give the

overview of the system being developed, displaying the relationships among actors and usecases.

A system can be decomposed into small scenarios describing the sequence of actions it performs.

This sequence of actions can be captured by developing the sequence diagrams of the system. A

systematic way for developing the activity diagrams is provided by the usecase models

(information sources like usecases and actors) to describe the overall flow of control of the system.

1.2 BPEL4WS or BPEL

BPEL (Business process execution language) is a XML-based language which is an important

technology of SOA (service-oriented architecture), as it enables easy and flexible composition of

services into business processes that are dynamic in nature. Every change in the business

requirement must be reflected in applications that provide support for business processes. Making

modifications to the applications is often a difficult task. Hence, instant reactions cannot be found

with the change in the business requirements, rather, they require time to implement, test, and

deploy the modifications. A business process is a collection of coordinated service invocations and

related activities exposing its functionality as a web service. Each BPEL process will be described

with a WSDL (web services Description Language) description. BPEL supports the characteristics

of business process with fault handlers and event handlers providing a means to express complex

parallel flows. BPEL provides a good support for long running transactions and event

management. BPEL is layered on top of WSDL containing the components BPEL Designer,

Process Flow Template, and BPEL Engine. Figure 2 explains the relation mapping between BPEL

process and the WSDL description.

Figure 2. Relation mapping between the BPEL process and the WSDL [10]

BPEL

Process

Action Partner

Link

BPEL/Partner Link Type

Partner Link Type

Role

Port Type

Operation

Input

Output

Fault

Message

Message Type

WSDL

5

The following elements are provided by BPEL to capture the process information:

1. Partner Link Types: The kind of message exchanges the WSDL services intend to carry

out are described by the partner link types. This is done by defining the roles played by

each service and by specifying the port type provided by the service. The partner link type

can include either one role or two roles depending on the service.

2. Process: A BPEL process uses elementary services to implement a potentially long-

running service. It describes the orchestration of other services using the control flow

graphs and variables. Error handling can be done through fault handling in a process

supporting asynchronous events. Two types of processes – executable processes and

abstract processes are supported by the BPEL.

3. Activities: The basic building blocks of BPEL process are the BPEL activities. Two types

of Activities are supported by BPEL. They include Primitive activities (or Basic activities)

and structured activities. Primitive activities (represent basic constructs) are used for

common tasks such as invoking the web services, waiting for the request, manipulating the

data variables, and indicating the faults and exceptions. The primitive activities can be

combined into complex algorithms, and structured activities supports this combination. The

structured activities include sequence, flow, case-switch construct, and while.

6

CHAPTER 2

Efficient Transformation of UML Functional Requirements into BPEL

Specifications

This chapter describes the EaCTUML2BPEL approach which was presented at the On The Move

2009 Conference at Portugal [13], to transform the UML functional requirements into BPEL

specifications.

2.1 How does the EaCTUML2BPEL approach work?

User stories and requirements-gathering meetings help the developer to gather the client‟s

requirements and develop the functional requirements for the system being developed. The

functional requirements are then modeled as the UML diagrams which are used in transformation

to BPEL specifications. Figure 3 describes the methodology for transforming UML functional

requirements into BPEL specifications.

Figure 3. Transformation process from UML functional requirements into BPEL Specifications [10]

Gather Functional Requirements

1.

2.

………………….

n.

UML Diagrams

Use case Diagram: Identify use cases

and actors

BPEL4WS

<process>

<invoke> ……..

</invoke>

<assign> ……..

</assign>

<receive>…….

</receive>

<reply> ……..

</reply>

</process>

Web

service A

Web

service B

XMI Document

Sequence Diagram:

Identify the sequence of actions

Class Diagram:

Identify the classes

Activity Diagram:

Identify sequence of activities

7

The transformation from UML functional requirements into BPEL specifications can be viewed as

a step-wise process.

Step -1: Gather the functional requirements of the system.

Step -2: Develop the UML Diagrams for the functional requirements.

Step -3: Export the UML models into an XMI document.

Step -4: Import the XMI document into NetBeans and generate the BPEL executable code.

2.1.1 Mapping UML components and BPEL Transformations

During the transformation of UML functional requirements into BPEL specifications, WSDL (web

services description language) artifacts, XSD (XML schema definition) artifacts, and a BPEL file

are generated. The final BPEL file includes the executable code with the specification. The

corresponding mappings between the UML components and the generated BPEL transformations

can be found in Table 1. The actor in UML represents the participants in the interaction in BPEL,

the classes and objects in UML represent the business processes in BPEL, the attributes in UML

are the variables with the Variable name, message type and element in BPEL, the basic behavior of

a web service of BPEL can be captured by the activity graph in UML.

UML Component BPEL Transformation

Actor Partners represent the participants in the interaction.

Class and objects Business process

Attribute Variables include variable name, message type and element.

Activity Graph Activity represents the basic behavior of a web service.

Messages Includes partner link type, role, port type and message (receive or

reply or request)

Table 1. Mapping between UML components and BPEL transformations [10]

2.1.2 Validation Tools

UML models can be created using UML modeling tool Visual Paradigm for UML (VP-UML).

These UML models capture the actual essence of the functional requirements in a graphical

notation. These functional requirements can be simulated in an environment such as NetBeans in a

BPEL specification. In out project, we use NetBeans to simulate the functional requirements

captured by the UML models in VP-UML. This can be done by integrating NetBeans with VP-

UML using Visual paradigm for UML SDE (Smart Development Environment) for

NetBeans. Upon synchronization of VP-UML with NetBeans, all the functions that can be carried

out in VP-UML can be performed in NetBeans.

8

2.2 Functional Requirements

The intended behavior of the system can be described by the functional requirements. The

functional requirements are denoted with an „F‟ followed by a „number‟. The number represents

the order of the functional requirements. Any change requested by the client in client‟s needs must

reflect in the functional requirements. Based on the requirement the order of functional

requirements can be changed. These functional requirements form the basis for developing the

usecases in the UML usecase diagrams. These usecases include scenarios which represent the

functional requirements. Each scenario can be captured with the UML sequence diagrams.

2.3 UML Diagrams

UML diagrams are modeled using UML-based modeling tools. Visual paradigm for UML (VP-

UML from here on) is one such UML-based modeling tool used to generate the UML diagrams.

Initially usecases and actors are developed based on the captured functional requirements in a VP-

UML usecase diagram. Each usecase may include several usecases within it. Usecase diagram

represents the overall structure of the system being developed. Based on these usecases and actors,

classes are identified for the system in a VP-UML class diagram. The classes generated and the

actors identified are used to develop the VP-UML sequence diagrams which represent the

scenarios of the usecases. The methods and variables defined in the classes are used to represent

the sequence of steps carried out for a scenario in a sequence diagram. Later, the VP-UML activity

diagram of the system is developed describing the actual activity of the system without including

any technical details.

2.4 XMI Document

XMI (XML Metadata Interchange) supports exchange of metadata between modeling tools based

on UML and repositories based on metadata structures. VP-UML environment provides a means to

export the XMI document to the intended locations once the UML diagrams are generated. Select

file from the menu and then choose Export-> XMI from the dropped file menu. Figure 4 shows

how to export the developed UML diagrams into XMI document.

9

Figure 4. Exporting UML Diagrams into XMI document in VP-UML

Once the above is chosen from the file menu, a popup window as shown in Figure 5 appears on the

screen asking for the location where the XMI needs to be exported. As NetBeans provides a means

to simulate the functional requirements and models the BPEL specifications. NetBeans location is

chosen as the file path to export the XMI document. Once the file path and the XMI version are

selected, VP-UML starts exporting the XMI document into NetBeans. The status of percentage of

completion of export is shown as shown in Figure 5.

Figure 5. Exporting XMI from VP-UML to NetBeans

10

With a successful export of the XMI document, XMI import is done in the NetBeans to transform

it into BPEL file. For this, the NetBeans environment must be synchronized with the VP-UML by

using Visual paradigm for UML SDE (Smart Development Environment) for NetBeans. This

integration can be seen in NetBeans environment through inclusion of VP-UML into NetBeans. To

import the XMI document, select file from the menu and chose SDE EE-NB Import -> XMI.

Then it pops up a window asking from where to import the XMI file. Choose the file that has been

previously exported to NetBeans. And we see the same status of percentage completed for import

of XMI document.

Figure 6. Importing the XMI document into NetBeans environment

2.5 BPEL Specification

Once the XMI document is imported, Visual paradigm for UML SDE for NetBeans provides an

instant generator in modeling tab in the menu, to transform the XMI and generate the executable

code in BPEL.

11

Figure 7. Transformation of XMI document into BPEL executable code

For this, select modeling tab in menu, and chose Instant Generator -> Instant Generator. Then a

window as shown in Figure 7 below pops up and asks to chose the language in which the XMI

document is to be transformed, the output path in which the file should be saved and the template

directory in which the instant generator chooses the language.

12

CHAPTER 3

Consistent Transformation of UML Functional Requirements into BPEL

Specifications

This chapter describes how to ensure the transformation from the UML functional requirements

into BPEL specifications be consistent using NFR Approach evaluation.

3.1 What is consistency?

Inconsistencies between the UML functional requirements and BPEL specifications may lead to

the bad system development in the industry. Hence the BPEL specifications developed must be

consistent with the functional requirements captured by UML. Consistency has a wide range of

meanings in the literature.

1. Nien-Lin Hsueh, Peng-Hua Chu and William Chu proposes a quantitative approach for

evaluating design „quality‟, especially that of consistency. Also, Transcom solutions

presents a “consistency = Quality” through a quality assurance program. Hence we can

consider “quality” as one of the definitions of consistency. [13]

2. Kenneth P. Birman and Bradford B. Glade evaluates reliability through consistency by

presenting evaluation of failure of consistency as failure of reliability. This can bring us to

a conclusion of considering “reliability” as consistency. [14]

3. G. Taguchi and D. Clausing generates a Harvard Business Review which describes

consistency as robustness. Hence “robustness” can be considered as one of the definition of

consistency. [15]

Considering all the above definitions found in the literature, we can define consistency as quality,

reliability and robustness of the system being developed.

3.2 Importance of consistency

Functional requirements of the system keeps on changing during the development of the project, as

there will be a change in the client‟s needs. Consistency between the BPEL specifications and the

functional requirements captured by the BPEL specifications is very important to ensure that the

system developed based on the BPEL specifications satisfies the Client‟s needs.

3.3 Why can consistency lack?

BPEL specifications are developed from the UML models which are created as a part of functional

requirements documentation for the system. However, there can exist inconsistencies between the

BPEL specifications and the UML functional requirements due to several reasons listed below.

13

1. The functional requirements itself may be confused and can get wrong with the whole

system.

2. The UML models developed from the functional requirements may be mistaken.

3. The UML models may be incomplete.

4. UML models may not always be transformed into BPEL specifications in a one-to-one

manner.

5. The changes made in the UML models may not be broadcasted to the BPEL specifications.

6. All UML expressions may not be susceptible to the BPEL specification representation.

3.4 NFR Approach for Evaluating Consistency

Several techniques have been proposed in the literature to evaluate the consistency. One of them is

a theorem-proving technique proposed by L.H. Weiner, E.W. Dijkstra, H.D. Mills and C.A.R.

Hoare in the roots of structured programming to verify a program with its corresponding

specifications. But this approach requires a lot of expertise and large amount of time; also, it does

not propose a direct approach to evaluate consistency between the specifications. Another

approach for checking models automatically for consistency has been proposed by M. Chechik and

J. Gannon. But this approach analyses consistency between requirements and design by

considering the events in state transitions. This is an impractical approach and also does not help in

evaluating the consistency between the specifications.

We employ the NFR approach in our project for evaluating consistency between the BPEL

specifications and the UML functional requirements as NFR approach provides an ability to

capture variety of definitions of consistency as described earlier both qualitatively and

quantitatively. Also, NFR approach provides justifications for the evaluation done between the

BPEL specifications and the UML functional requirements. This approach is a goal-oriented

approach (goal here is to achieve good consistency) which is easy to understand as it uses

graphical artifacts for capturing the evaluation decisions and provides a means for retaining

historical decision-making.

3.4.1 Applying NFR Approach

NFR approach views the goal to be achieved (here consistency) as a non-functional requirement

(NFR). A structure called Softgoal Interdependency Graph (SIG) is developed for evaluating

consistency to apply the NFR approach. SIG can be developed in four steps:

Step 1: The factors affecting the consistency are decomposed into AND-OR-EQUAL graph. The

relation between two factors can be defined to be AND if both the factors are important to satisfy

the parent factor; the relation between two factors can be defined to be OR if one of the factor

among both is important to satisfy the parent factor; the relation between two factors can be

defined to be EQUAL if child factor is equally important to satisfy the parent factor.

14

Step 2: Various features of specifications relationship such as, completeness, comprehension,

acceptability of the system by the users in the relationship between two specifications must be

determined.

Step 3: The extent to which the above mentioned features in step 2 affect the leaf consistency

factors identified in step 1 are determined by calculating the contributions (MAKE, HELP,

HURT, and BREAK) the specifications relationship features make to the consistency factors.

Step 4: Justifications for the contributions in step 3 are captured so that a historical record of

explanation for contribution changes is maintained.

The decomposition of factors in step 1 may assign priorities to some factors, and the contributions

to the consistency factors calculated in step 4 can either satisfce or deny that factor. Once the SIG

is developed and computed, the propagation rules of the NFR Approach are applied to

propagate the contributions in step 3 above to the top of the SIG to evaluate the root of the NFR

softgoal, namely, consistency.

The result of this evaluation will be the consistency score for each set of specifications which are

qualitatively categorized into MAKE, HELP, HURT, or BREAK, with the following order:

MAKE > HELP > HURT > BREAK

Where MAKE is referred to excellent consistency, HELP is referred to good consistency, HURT is

referred to poor consistency, and BREAK is referred to very poor consistency.

From the above four steps the consistency between the BPEL specifications and the UML

functional requirements can be evaluated using the NFR Approach.

15

CHAPTER 4

CASE STUDY: TRAVEL RESERVATION SYSTEM

This chapter includes a case study – travel reservation system to describe efficient transformation

from UML functional requirements into BPEL specifications of SOA-based systems using

EaCTUML2BPEL approach, and consistency evaluation between the developed specifications

using NFR approach.

4.1 Description of Travel Reservation System

The Travel reservation System (TRS from here on) is a web-based system developed to examine

the client itinerary to find whether any reservations pre-exist for airline, hotel and/or vehicle or no

reservations pre-exist. The travel reservation system processes the client itenerary for airline and

adds to the airline reservation. Later, the system processes the itinerary to find out the existing

hotel reservations and/or vehicle reservations, and if there are any reservations, they are added to

the hotel reservation and vehicle reservation respectively. If the Traveler wishes to update or

cancel the reservation, the reservation is updated or canceled respectively. Finally, the completed

itinerary is sent to the client with the changes processed.

4.2 Functional Requirements of the TRS

F1. The Traveler and the administrator must be able to login to the system.

F2. If the Traveler is a new user, he must be able to register with the Travel Reservation System.

F3. The Traveler must be able to check the availability of the airline, hotel and/or vehicle for

reservation.

F4. The Traveler must be able to make a reservation to the airline, hotel and/or vehicle.

F5. The Traveler must be able to add a reservation to the airline, hotel and/or vehicle.

F6. The Traveler must be able to update the details for the reservation.

F7. The Traveler must be able to cancel a reservation.

F8. The System must be able to examine if there are any pre-existing reservations.

F9. The system must be able to validate the requests for creating a reservation, adding a

reservation, updating a reservation and cancelling a reservation.

.

16

4.3 UML models

4.3.1 Use case Diagram

From the above functional requirements of TRS a business model is developed to understand what

the system has to do. From the description of the system, we can identify traveler and admin as the

actors; login, register, make reservation, cancel reservation, add reservation, update reservation

and check availability as the usecases. All these usecases except register includes vehicle, airline

and hotel usecases to which reservation activities are to be performed. Hence we can identify two

actors and seven usecases in the use case model developed in VP-UML as shown in Figure 8.

Figure 8. Use case Diagram for TRS developed in VP-UML

4.3.2 Activity Diagram

Once the use case diagram is captured the activity diagram of the system is developed as illustrated

in Figure 9. The diagram is captured for the sequence of activities performed by the TRS. The

traveler or the admin (here referred as system) enters the TRS to choose the reservation

(airline/vehicle/hotel). Depending on the type of reservation, traveler or admin (system) logs into

the system. Then the system checks if there are any pre-existing reservations from the itinerary

17

verification code. If there are any pre-existing reservations, then the traveler can modify the

reservation which includes cancel the reservation or update reservation or add a reservation.

Figure 9. Activity diagram for TRS developed in VP-UML

If the traveler selects cancel a reservation, then the itinerary is cancelled and updated to the

database; the change in the itinerary is sent back to the traveler. If the traveler wants to update the

itinerary information, the traveler updates the information and changes are applied to the database;

the updated itinerary is sent back to the traveler. To add a reservation, the traveler checks for the

availability of the airline/vehicle/hotel, and enters the user details. Then the system creates a new

reservation for the traveler, updates the database, creates the itinerary, and sends the itinerary to

the traveler.

If there are no pre-existing reservations, the user can make a new reservation. Foremost, the

traveler checks the availability of the airline/vehicle/hotel he wishes to reserve, then enters the new

user details, creates a reservation and the system updates to the database, creates the new itinerary

and sends the itinerary to the user.

18

4.3.3 Class Diagram

The classes can be identified for the scenario from the usecases after the activity diagram has been

captured. A „Reservation’ class is identified as the boundary class which models the control

behavior of the „reservation’ usecase. It includes the methods createReservation,

updateReservation, cancelReservation, addReservation and checkAvaiability. The reservations can

be performed to airline/hotel/vehicle which are identified in the „Airline’, „Hotel‟, and „Vehicle‟

classes. The Airline class has the attributes airline name, airline headquarters location,

headquarters phone number, arrival time and departure time. The Hotel class has the attributes

hotel name, hotel location, hotel phone number, check in and checkout times. The vehicle hast he

attributes vehicle number, vehicle type, vehicle headquarters location, headquarters phone number,

pickup time and drop-off time. „Userinterface‟ is identified as a boundary class which models the

interaction between system‟s surroundings and its inner workings

The „Login‟ class has the attributes username and password with the methods verify username,

verify password, allow access and deny access. The ‘Traveler’ class, „Admin‟ class, „Itinerary’

class and „Database system’ class are identified as the entity classes which exchange information

with the „Reservation’ class. The Traveler class has the attributes customer id, customer first name,

customer last name, customer address and customer phone number with the methods setFeild,

getFeild, makeReservation, cancelReservation and viewReservation. The „Admin‟ class has the

username and password as the attributes. The „Database system’ has the attribute database table

name with the methods getFeild, setFeild, read and write. The „Itinerary’ class has the attributes

code and type with the methods createItinerary, cancelItinerary and addItinerary. The class

diagram can be illustrated in Figure 10.

19

Figure 10. Class Diagram for TRS developed in VP-UML

4.3.4 Sequence Diagrams

The instance of the usecase describes the sequence of actions in a scenario. This sequence of

actions can be captured in a sequence diagram using the identified classes. The following

scenarios can be depicted for the above described usecases.

Usecase: Login

Scenario:

1. The traveler or the administrator will give the credentials (username and password) to the

system.

2. The credentials are verified by the system.

3. If the credentials are correct, the user (traveler/administrator) will be able to login to the

system.

4. If the credentials do not match the user will be denied to access the system.

The sequence diagram in Figure 11 depict the Login scenario.

20

Figure 11. Sequence Diagram for the Login usecase scenario

Usecase: Register

Scenario:

1. The user enters his/her details which includes first name, last name, phone number, email

and address.

2. All the details are asked to enter into the database by the system.

3. Before writing into the database, the system asks user to verify the details once again.

4. As soon as the user verifies the details, and clicks ok, all the details are updated to the TRS

database.

5. The registered message will be sent to the traveler.

The sequence diagram captured is shown in Figure 12.

21

Figure 12. Sequence Diagram for Register usecase scenario

Usecase: Make Reservation for Airline

Scenario:

1. The user (traveler) checks the availability of the flights.

2. The system returns the list of available flights requested by the user.

3. The user selects the required flight and asks the system for „make a reservation‟.

4. The system checks if there are any pre-existing reservations.

5. If there are no pre-existing reservations found, the system creates a new itinerary and sends

it to the user.

6. If there are pre-existing reservations on the system, the system add an itinerary to the

existing reservations, and sends the itinerary to the user.

The sequence diagram is shown in Figure 13.

22

Figure 13. Sequence diagram for Make a Reservation for Airline usecase scenario

Usecase: Make Reservation for Hotel

Scenario:

1. The user (traveler) checks the availability of the rooms.

2. The system returns the number of available rooms requested by the user.

3. The user selects the required room and asks the system for „make a reservation‟.



it to the user.



The sequence diagram for the scenario is illustrated in Figure 14.

23

Figure 14. Sequence Diagram for Make Reservation for Hotel usecase scenario

Usecase: Make Reservation for Vehicle

Scenario:

1. The user (traveler) checks the availability of the vehicles.

2. The system returns the list of available vehicles requested by the user.

3. The user selects the required vehicle and asks the system for „make a reservation‟.



it to the user.




24

Figure 15. Sequence Diagram for Make Reservation for Vehicle usecase scenario

Usecase: Add Reservation for Airline

Scenario:

1. The user (traveler) checks the availability of the flights.

2. The system returns the list of available flights requested by the user.

3. The user selects the required flight and asks the system for „add a reservation‟.

4. The system requests the user for the verification code.

5. The user enters the verification code.

6. The system verifies it with the database, and checks for the pre-existing reservations.

7. If there are pre-existing reservations on the system, the system adds an itinerary to the



25

Figure 16. Sequence Diagram for Add Reservation for airline usecase scenario

Usecase: Add Reservation for Hotel

Scenario:

1. The user (traveler) checks the availability of the rooms.

2. The system returns the number of available rooms requested by the user.







The Sequence diagram is shown in Figure 17.

26

Figure 17. Sequence Diagram for Add Reservation for hotel usecase scenario

Usecase: Add Reservation for Vehicle

Scenario:

1. The user (traveler) checks the availability of the vehicles.

2. The system returns the list of available vehicles requested by the user.








27

Figure 18. Sequence Diagram for Add Reservation for vehicle usecase scenario

Usecase: Cancel Reservation for Vehicle

Scenario:

1. The traveler logs into the system and asks for cancel a reservation for flight.

2. The system checks for the pre-existing reservations and asks the user to enter the

verification code.

3. The traveler enters the verification code.

4. The system updates the details in the database and cancels the reservation.

5. The message of cancellation of itinerary is sent back to the user.


28

Figure 19. Sequence Diagram for Cancel Reservation for airline usecase scenario

Usecase: Cancel Reservation for Hotel

Scenario:

1. The traveler logs into the system and asks for cancel a reservation for hotel.


verification code.





29

Figure 20. Sequence Diagram for Cancel Reservation for hotel usecase scenario

Usecase: Cancel Reservation for Vehicle

Scenario:

1. The traveler logs into the system and asks for cancel a reservation for hotel for vehicle.


verification code.





30

Figure 21. Sequence Diagram for Cancel Reservation for vehicle usecase scenario

4.4 XMI Document

The UML models developed from all the above steps are now exported into an XMI document

from VP-UML into NetBeans as shown in Figure 22. Select the „File menu’ in VP-UML and select

„Export‟. This gives options as shown in Figure 22. Choose „XMI‟ from the listed options, and we

will soon be able to see a pop-up window asking to choose the path in which the XMI file needs to

be exported. The path can be chosen to the NetBeans location with the name of the XMI

document. This window also shows the percentage of export completed. This can be observed in

Figure 23.

31

Figure 22. Exporting UML models to XMI Document.

Figure 23. Percentage of Export Completed

32

4.5 BPEL Specification

Once the XMI document is exported to NetBeans as shown in Figure23, we can import the file and

transform it into a BPEL specification. The NetBeans environment needs to be integrated with

SDE EE-NB by selecting start „SDE EE-NB’ from the file import can be done by selecting „file

menu‟ and select „SDE EE-NB Import’. A list of options is shown as shown in Figure 24 below.

Chose „XMI‟ from the list. Then a pop-up window is going to appear similar to the XMI Export

window, but, this will be XMI Import.

Figure 24. Import XMI Document in NetBeans

Once the XMI import is successful, this XMI document can be converted into BPEL specification

by select the „Modeling‟ tab from the menu, and select the „Instant Generator’. A window opens

giving the options to which language the document needs to be transformed. This is illustrated in

Figure 25. Chose the „BPEL‟ from the options, and select output path and the Template directory

and click „Generate‟.

33

Figure 25. Generate BPEL executable code from the XMI document

The code below describes the BPEL specification generated from the UML diagrams. The

usecases in UML are depicted by the business processes in BPEL. Hence Travel, Airline, Hotel

and Vehicle are identified as partner links in the BPEL specification. The BPEL executable code

transformed from the UML diagrams be explained as follows:

1. The traveler logs into the system and checks the availability if the airline/hotel/vehicle.

2. Once he logs into the system he can make a reservation, cancel a reservation, ass a

reservation or update a reservation to the airline/hotel/vehicle.

3. Add a reservation and update a reservation are included in the make a reservation in the

BPEL specification

4. The partnerLinks are identified as travel, airline, hotel and vehicle

5. The variables and correlation sets are identified from the UML diagrams and are mapped

with the corresponding components in the BPEL specification.

The BPEL executable code explains how the Travel Reservation System works for making a

reservation, canceling a reservation, adding a reservation and updating a reservation.

34

<process name="TravelReservationService"

targetNamespace="http://enterprise.netbeans.org/bpel/TravelReservationService/TravelReservationService"

xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable" xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:bpws="http://docs.oasis-open.org/wsbpel/2.0/process/executable"

xmlns:sxt="http://www.sun.com/wsbpel/2.0/process/executable/SUNExtension/Trace" xmlns:sxed="http://www.sun.com/wsbpel/2.0/process/executable/SUNExtension/Editor"

xmlns:tres="http://enterprise.netbeans.org/bpel/TravelReservationService/TravelReservationService"

xmlns:ares="http://enterprise.netbeans.org/bpel/TravelReservationService/AirlineReservationService" xmlns:vres="http://enterprise.netbeans.org/bpel/TravelReservationService/VehicleReservationService"

xmlns:hres="http://enterprise.netbeans.org/bpel/TravelReservationService/HotelReservationService"

<import namespace="http://j2ee.netbeans.org/wsdl/TravelReservationService" location="TravelReservationService.wsdl" importType="http://schemas.xmlsoap.org/wsdl/"/>

<import namespace="http://j2ee.netbeans.org/wsdl/AirlineReservationService" location="AirlineReservationService.wsdl"

importType="http://schemas.xmlsoap.org/wsdl/"/> <import namespace="http://j2ee.netbeans.org/wsdl/VehicleReservationService" location="VehicleReservationService.wsdl"

importType="http://schemas.xmlsoap.org/wsdl/"/>

<import namespace="http://j2ee.netbeans.org/wsdl/HotelReservationService" location="HotelReservationService.wsdl" importType="http://schemas.xmlsoap.org/wsdl/"/>

<partnerLinks>

<partnerLink name="Travel" partnerLinkType="tres:TravelReservationPartnerLinkType" myRole="TravelReservationServiceRole">

</partnerLink>

<partnerLink name="Airline" partnerLinkType="ares:AirlineReservationPartnerLinkType" partnerRole="AirlineReservationServiceRole"

myRole="AirlineReservationCallbackServiceRole">

</partnerLink> <partnerLink

name="Vehicle" partnerLinkType="vres:VehicleReservationPartnerLinkType" partnerRole="VehicleReservationServiceRole"

myRole="VehicleReservationCallbackServiceRole"> </partnerLink>

<partnerLink

name="Hotel" partnerLinkType="hres:HotelReservationPartnerLinkType" partnerRole="HotelReservationServiceRole" myRole="HotelReservationCallbackServiceRole">

</partnerLink>

</partnerLinks> <variables>

<variable name="CancelVehicleOut" messageType="vres:CancelVehicleOut"/>

<variable name="CancelVehicleIn" messageType="vres:CancelVehicleIn"/> <variable name="CancelAirlineOut" messageType="ares:CancelAirlineOut"/>

<variable name="CancelAirlineIn" messageType="ares:CancelAirlineIn"/>

<variable name="ItineraryIn" messageType="tres:ItineraryIn"/> <variable name="ItineraryOut" messageType="tres:ItineraryOut"/>

<variable name="ReserveAirlineIn" messageType="ares:ReserveAirlineIn"/>

<variable name="AirlineReservedIn" messageType="ares:AirlineReservedIn"/> <variable name="ReserveVehicleIn" messageType="vres:ReserveVehicleIn"/>

<variable name="VehicleReservedIn" messageType="vres:VehicleReservedIn"/>

<variable name="ReserveHotelIn" messageType="hres:ReserveHotelIn"/> <variable name="CancelHotelIn" messageType="hres:CancelHotelIn"/>

<variable name="CancelHotelOut" messageType="hres:CancelHotelOut"/>

<variable name="HotelReservedIn" messageType="hres:HotelReservedIn"/> </variables>

<correlationSets> <correlationSet name="ItineraryCorrelator" properties="tres:ItineraryRefId"/></correlationSets> <sequence name="Main">

<receive name="ReceiveItinerary" partnerLink="Travel" portType="tres:TravelReservationPortType" operation="buildItinerary"

createInstance="yes" variable="ItineraryIn"> <correlations> <correlation set="ItineraryCorrelator" initiate="yes"/></correlations>

</receive>

<assign name="CopyItineraryIn"> <copy> <from variable="ItineraryIn" part="itinerary"/> <to variable="ItineraryOut" part="itinerary"/></copy>

<copy> <from variable="ItineraryIn" part="itinerary"/> <to variable="ReserveAirlineIn" part="itinerary"/> </copy>

<copy><from variable="ItineraryIn" part="itinerary"/><to variable="ReserveVehicleIn" part="itinerary"/> </copy> <copy> <from variable="ItineraryIn" part="itinerary"/> <to variable="ReserveHotelIn" part="itinerary"/> </copy>

</assign>

<if name="HasAirline"> <condition>not($ItineraryIn.itinerary/ItineraryInfo/ReservationItems/Item/Air)</condition>

<sequence>

<invoke name="ReserveAirline" partnerLink="Airline" portType="ares:AirlineReservationPortType" operation="reserveAirline"

inputVariable="ReserveAirlineIn">

35

<correlations> <correlation set="ItineraryCorrelator"> </correlation> </correlations>

</invoke> <pick name="Pick1">

<onMessage partnerLink="Airline" operation="airlineReserved" portType="ares:AirlineReservationCallbackPortType"

variable="AirlineReservedIn"> <correlations> <correlation set="ItineraryCorrelator" initiate="no"> </correlation></correlations>

<assign name="CopyAirlineReservation">

<copy><from variable="AirlineReservedIn" part="itinerary"/> <to variable="ItineraryOut" part="itinerary"/> </copy> <copy><from variable="AirlineReservedIn" part="itinerary"/> <to variable="ReserveVehicleIn" part="itinerary"/> </copy>

</assign></onMessage>

<onAlarm> <sequence name="AirlineCancelSequence">

<assign name="CopyAirlineCancellation">

<copy> <from>$ReserveAirlineIn.itinerary/ota:ItineraryRef</from> <to variable="CancelAirlineIn" part="itinerary"/> </copy> <copy><from variable="CancelAirlineOut"/> <to variable="CancelAirlineOut"/> </copy>

</assign>

<invoke name="CancelAirline" partnerLink="Airline" operation="cancelAirline" portType="ares:AirlineReservationPortType"

inputVariable="CancelAirlineIn" outputVariable="CancelAirlineOut"/>

</sequence></onAlarm> </pick></sequence> </if>

<if name="HasVehicle">

<condition>not($ItineraryIn.itinerary/ItineraryInfo/ReservationItems/Item/Vehicle)</condition> <sequence>

<invoke name="ReserveVehicle" partnerLink="Vehicle" portType="vres:VehicleReservationPortType" operation="reserveVehicle"

inputVariable="ReserveVehicleIn"> <correlations> <correlation set="ItineraryCorrelator"/> </correlations>

</invoke> <pick name="Pick2">

<onMessage partnerLink="Vehicle" operation="vehicleReserved" portType="vres:VehicleReservationCallbackPortType"

variable="VehicleReservedIn"> <correlations><correlation set="ItineraryCorrelator" initiate="no"/> </correlations>

<assign name="CopyVehicleReservation">

<copy> <from variable="VehicleReservedIn" part="itinerary"/> <to variable="ItineraryOut" part="itinerary"/> </copy> <copy><from variable="VehicleReservedIn" part="itinerary"/> <to variable="ReserveHotelIn" part="itinerary"/> </copy>

</assign></onMessage> <onAlarm>

<sequence name="CancelVehicleSequence">

<assign name="CopyVehicleCancellation">

<copy><from>$ReserveVehicleIn.itinerary/ota:ItineraryRef</from> <to variable="CancelVehicleIn" part="itinerary"/>

</copy> <copy><from variable="CancelVehicleOut"/> <to variable="CancelVehicleOut"/> </copy>

</assign>

<invoke name="CancelVehicle" partnerLink="Vehicle" operation="cancelVehicle" portType="vres:VehicleReservationPortType" inputVariable="CancelVehicleIn" outputVariable="CancelVehicleOut"/>

</sequence> </onAlarm> </pick> </sequence>

</if> <if name="HasHotel">

<condition>not($ItineraryIn.itinerary/ItineraryInfo/ReservationItems/Item/Hotel) </condition>

<sequence> <invoke name="ReserveHotel" partnerLink="Hotel" portType="hres:HotelReservationPortType" operation="reserveHotel"

inputVariable="ReserveHotelIn">

<correlations><correlation set="ItineraryCorrelator"/> </correlations> </invoke>

<pick name="Timeout" createInstance="no">

<onMessage partnerLink="Hotel" portType="hres:HotelReservationCallbackPortType" operation="hotelReserved" variable="HotelReservedIn">

<correlations><correlation set="ItineraryCorrelator"/> </correlations>

<sequence name="HotelReserved"> <assign name="CopyHotelReservation">

<copy><from variable="HotelReservedIn" part="itinerary"/> <to variable="ItineraryOut" part="itinerary"/> </copy>

</assign> </sequence> </onMessage> <onAlarm> <sequence name="Timer">

<assign name="CopyHotelCancellation">

<copy><from>$ReserveHotelIn.itinerary/ota:ItineraryRef</from><to variable="CancelHotelIn" part="itinerary"/></copy> <copy><from variable="CancelHotelOut"/><to variable="CancelHotelOut"/></copy>

</assign>

<invoke name="CancelHotel" partnerLink="Hotel" portType="hres:HotelReservationPortType" operation="cancelHotel" inputVariable="CancelHotelIn" outputVariable="CancelHotelOut"/>

</sequence> </onAlarm> </pick> </sequence>

</if>

36

<reply name="ReturnItinerary" partnerLink="Travel" portType="tres:TravelReservationPortType" operation="buildItinerary"

variable="ItineraryOut"> </reply> </sequence>

</process>

Figure 26. BPEL specification generated from the UML functional requirements

4.6 Mapping the Functional Requirements to the BPEL Specification

The functional requirements of the system are mapped with the BPEL specification developed

from the UML diagrams to evaluate the consistency employing the NFR approach. The BPEL

specification is evaluated against the functional requirements captured in the first step of

developing a system. The administrator logs into the system to check whether there are any pre-

existing reservations from the traveler. This is illustrated in the BPEL specification. The traveler

can make a reservation, cancel a reservation, add a reservation and update a reservation. The

operations add a reservation and update a reservation are included in the make a reservation in the

BPEL specification. All these operations invoke the create itinerary, receive itinerary, cancel

itinerary operations in the BPEL specification. The operation add itinerary is inclusive of the

operation create itinerary which adds a new reservation. The BPEL specification can be divided

into three parts, namely, airline reservation, hotel reservation and vehicle reservation for easy

understanding. The operations performed by all the three parts are described in the BPEL

specification.

When an airline is reserved, the system checks if there are any pre-existing airline reservations

using the „HasAir‟ functionality. Later, if there are no pre-existing reservations the itinerary is sent

to the TRS for processing and airline reservation is added to the system invoking the

„ReserveAirline‟ method. If there are pre-existing reservations, the itinerary is sent for TRS for

processing and airline reservation is added to the system invoking „ReserveAirline‟ method.

Later, the system processes the itinerary using „HasHotel‟ and „HasVehicle‟ functionalities to find

out the existing hotel reservations and/or vehicle reservations respectively; and if there are any pre-

existing reservations, they are added to the hotel reservation and vehicle reservation with

„ReserveHotel‟ and „ReserveVehicle‟ methods respectively. If the Traveler wishes to update the

reservation, the reservation is updated with „ReserveAirline‟, „ReserveHotel‟, „ReserveVehicle‟

methods, which update the airline, hotel and vehicle respectively. If the Traveler wishes to cancel

the reservation, the reservation is canceled with „CancelAirline‟, „CancelHotel‟, „CancelVehicle‟

methods to cancel the airline, hotel, vehicle respectively. Finally, the completed itinerary is sent to

the client with the „ItineraryIn‟, „ItineraryOut‟, „ReceiveItinerary‟ methods with the changes

processed.

From observations, the BPEL specification satisfies all the functional requirements the system

needs to perform, beginning from logging into the system, checking the availability of the

reservations, make reservations, cancel reservations, add reservations and update reservations for

airline / hotel / vehicle.

37

4.7 Evaluating Consistency between the above generated BPEL specification and the UML

functional requirements

4.7.1 Applying NFR Approach

4.7.1.1 Identifying the Softgoals

The Softgoal Interdependency Graph (SIG) is developed as discussed earlier to evaluate the

consistency between the BPEL specifications and the UML functional requirements. To develop

SIG, softgoals are needed to be identified. The softgoal is represented with a cloud. As we are

developing the SIG for consistency, it is considered as the parent softgoal of all the other child

softgoals that we are going to decompose. From the definitions of consistency given earlier, we

can decompose consistency into three child softgoals, quality, reliability and robustness. These

softgoals are related to the Consistency softgoal with an „OR‟ relation. As described earlier, from

the literature, we can decompose the softgoal Quality into Maintainability and Performance

softgoals with an „AND‟ relation. Similarly, the Reliability can be decomposed into Failure

Reporting and Design softgoals with „AND‟ relation, and Robustness can be decomposed into

Predictability, Time Consumption and Risk Assessment softgoals with an „AND‟ relation.

4.6.1.2 Contributions of the softgoals

For the functional requirements of the Travel Reservation System listed earlier from F1 through

F9, the BPEL specifications were derived from the corresponding UML models. The mapping

between the diagrams and the specifications for F1 through F9 the following features were

observed for the Specifications relationship:

1. It is easy to maintain the BPEL specifications in synchronous with the UML models. This

satisfices the HELP contribution for Maintainability.

2. This does not consume time or space to perform and store the synchronization. This

satisfices the MAKE contribution for Performance.

3. The errors in the relationship are easily identified. This satisfices the HELP contribution for

Failure Reporting.

4. The mappings between the BPEL specifications and the UML models are straightforward.

This satisfices the HELP contribution for the Predictability.

5. The synchronizations between the BPEL specifications and the UML models are not time-

consuming. Hence it satisfices the HELP contribution for the Time Consumption.

6. Risk Assessment can be disregarded for the relationship between the BPEL specifications

and the UML models. Hence it can be considered as a HELP contribution satisfaction for

Risk Assessment.

38

The above discussed contributions can be observed in the Softgoal Interdependency Graph in

Figure 27.

Figure 27. Softgoal Interdependency graph for Evaluating Consistency between the BPEL specifications and the UML

functional requirements for the Travel Reservation System

4.7.1.3 Applying Propagation Rules

The propagation rules as discussed in section 3.4.1 in applying the NFR approach. The MAKE

contribution of the softgoal can be referred to as excellent consistency with a „++‟ representation

in the Figure 27. Similarly, the HELP contribution of the softgoal can be referred to as good

consistency with a „+‟ representation, HURT contribution can be referred to as poor consistency

with a „-„ representation, and BREAK contribution can be referred to as very poor consistency

with a „- -„ representation in Figure 27.

The propagation can be described as follows:

MAKE (++) > HELP (+) > HURT (-) > BREAK (- -)

Hence by applying the above propagation rules to the SIG, we can conclude that the NFR softgoal

– Consistency [Mapping], is HELP satisficed. This means that the specifications relationship is

consistent for the Travel Reservation System. However, if other systems are considered for

39

evaluation, the specifications relationships for their functional requirements and the impact of NFR

softgoals may differ.

The NFR approach allows us to consider all sets of mappings between the BPEL specifications and

the UML functional requirements to evaluate the consistency for the entire set of mappings with

the above discussed method.

40

CHAPTER 5

Conclusions and Future Work

As the dependence on the complex web applications has grown steadily from the past few years

the web applications are developed employing Service-Oriented Architecture (SOA). In this

project, we propose an approach for transforming the UML functional requirements into BPEL

specifications to develop these SOA-based systems. We have developed UML models from the

functional requirements in VP-UML, and transformed the functional requirements into an XMI

Document. This XMI document is imported into NetBeans environment which provides a means

to simulate the functional requirements. Once the import is successful, the XMI document is then

transformed into a BPEL specification in NetBeans.

BPEL specifications generated from the above proposed approach must be consistent with the

UML functional requirements captured in the first step. If this consistency can be evaluated by any

means, it would help the industry to develop accurate scheduling and personnel estimates, identify

test cases for user acceptance, and ensure that the system developed meets the client‟s needs.

Hence we employ NFR Approach to evaluate the consistency between the BPEL specifications

generated and the UML functional requirements, as it provides a means to capture the evaluation

of consistency by means of NFR softgoal decomposition. We have validated the proposed

approach using the case study „Travel Reservation System’.

In future, the proposed approach can be validated with more systems, and quantitative evaluation

for the consistency can be done so that numbers may be assigned and ensure wider applicability of

the approach. Also, another possible future work could be development of tool for automated

evaluation.

41

CHAPTER 6

References

1. K. Mantell. From UML to BPEL – https://www.ibm.com/developerworks/webservices/library/ws-

uml2bpel/, September 2003.(Accessed on Jun 6, 2009)

2. Assaf Arkin et al. Web services business process execution language version 2.0 – http://docs.oasis-

open.org/wsbpel/2.0/wsbpel-specification-draft.html, December 2004. (Accessed on Aug 29, 2009)

3. Frank Leymann and Dieter Roller. Business processes in a Web services world,

http://www.ibm.com/developerworks/webservices/library/ws-bpelwp/#code1, August 2002. (Accessed on

Jun 5, 2009)

4. http://en.wikipedia.org/wiki/Unified_Modeling_Language (Accessed on June 9, 2009)

5. http://en.wikipedia.org/wiki/Business_Process_Execution_Language (Accessed on June 9, 2009)

6. M. L´opez-Sanz, C. J. Acu˜na, V. de Castro, E. Marcos, and C. E. Cuesta, "Using an Architecture-Centric

Model-Driven Approach for Developing Service-Oriented Solutions: A Case Study", Lecture Notes in

Computer Science No. 5872, November 2009, pp. 350-359, Proceedings of On The Move 2009 Conference,

Editors: R. Meersman, P. Herrero, and T. Dillon.

7. B. Korherr and B. List. Extending the UML 2 Activity Diagram with Business Process Goals and

performance Measures and the Mapping to BPEL, November 2006, pp. 7–18, 2nd

International workshop on

best practices of UML (BP-UML ’06). Spinger Verlag, Lecture Notes in Computer Science.

8. L.Chung, N. Subramanian, “Software Architecture Adaptability: An NFR Approach”, 2001, pp. 55–61,

International Conference on Software Engineering Proceedings of the 4th

International Workshop on

Principle of Software Evolution.

9. H Kurahata, T Fuji, T Miyamoto, S Kumagai. A UML Simulator for Behavioral Validation of Systems

Based on SOA, September 2006, pp. 3–10, IEEE International Conference on Next Generation Web

Services Practices.

10. A. Vemulapalli and N. Subramanian, "Transforming Functional Requirements from UML into BPEL to

Efficiently Develop SOA-Based Systems", Lecture Notes in Computer Science No. 5872, November 2009,

pp. 337-349, IWSSA’09 8th

International Workshop on System/Software Architectures.

11. L. Zhang, W. Jiang, “Transforming Business Requirements into BPEL: a MDA-Based Approach to Web

Application Development”, July 2008, pp. 61–66, IEEE International Workshop on Semantic Computing

and systems.

12. A. Shaban-Nejad, O. Ormandjieva, M. Kassab, and V. Harrslev, “ Managing Requirement Volatility in an

Ontology-Driven Clinical LIMS using Category theory”, Volume 2009, International Journal of

Telemedicine and applications.

13. Nien-Lin Hsueh, Peng-Hua Chu and William Chu, “A Quantitative Approach for evaluating quality of

design patterns”, Volume 81, August 2008, pp.1430–1439, Journal of Systems and Software.

14. Kenneth P. Birman and Bradford B. Glade, “Reliability through Consistency”, Volume 12, May 1995, pp.

29–41, IEEE Software.

15. L. H. Weiner, E. W. Dijkstra, H. D. Mills, and C. A. R. Hoare, “The Roots of Structured Programming”,

Volume 10, February 1978, pp. 243–254, ACM SIGCSE Bulletin.

https://www.ibm.com/developerworks/webservices/library/ws-uml2bpel/

https://www.ibm.com/developerworks/webservices/library/ws-uml2bpel/

http://docs.oasis-open.org/wsbpel/2.0/wsbpel-specification-draft.html

http://docs.oasis-open.org/wsbpel/2.0/wsbpel-specification-draft.html

http://www.ibm.com/developerworks/webservices/library/ws-bpelwp/#code1

http://en.wikipedia.org/wiki/Unified_Modeling_Language

http://en.wikipedia.org/wiki/Business_Process_Execution_Language

42

16. M. Chechik and J. Gannon, “Automatic Analysis of Consistency between Requirements and Designs”,

Volume 27, July 2001, pp. 651–672, IEEE Transactions on Software Engineering.

17. L. Chung and N. Subramanian, “Process-Oriented Metrics for Software Architecture Adaptability”, Aug-

Sep. 2001, pp. 310-311, Proceedings of the International Symposium on Requirements Engineering, IEEE

Computer Press.

18. IEEE Std. 830-1993, IEEE Recommended Practice for Software Requirements Specifications, December

1993.

19. J. Coleman, C. Jones, I. Oliver, A. Romanovsky, and E. Troubitsyna, “RODIN (Rigorous Open

Development Environment for Complex systems)”, unpublished (available at School of Computing Science,

Newcastle University Projects)

20. J. Coleman, C. Jones, I. Oliver, a. Romanovsky, and E. Troubitsyna, “RODIN (Rigorous Open Development

Environment for Complex systems)”, unpublished.

21. M.Emilia Cambronero, Gregorio Diaz, J.J.Pardo, Valentin Valero. Using UML Diagrams to Model Real-

Time Web Services, May 2007, pp.24–24

22. M.B.M.B. Juric and P. Sarang. Business Process Execution Language for Web services. Second Edition.

PACKT Publishing, 2006, pp. 5–14

23. Murali Pattathe. Transformation to SOA: Part 4. How Web service processes transform from UML to BPEL

in IBM Rational Software Architect. March 2008. (Accessed on June 7, 2009)

24. F. Jennings, D. Salter, Building SOA-Based Composite Applications Using NetBeans IDE, 2008, pp. 73–

196

25. G. Jalloul, “UML by Example (SIGS: Advances in Object Technology Paperback)”, 2004, pp. 99–129

26. John R. Clymer, Simulation-Based Engineering of Complex Systems, 2nd

ed., 2009, pp. 376–382

27. G. Taguchi and D. Clausing, “Robust Quality”, Jan-Feb. 1990, pp.65–75, Harvard Business Review.

28. John R. Clymer, Simulation-Based Engineering of Complex Systems, 2nd

ed., 2009, pp. 376–382

efficient and consistent transformation of uml …1.1 why uml diagrams? uml is an object-oriented...

Documents