CHAPTER 4: SYSTEM DESIGN

4.1 Design of Travel Management System

Functionalities of the components in the system are determined by a good systems

design. The selection of a better modeling technique is important at this stage.

There are several models including behavioral model, data model and object-oriented
model. Since the project is a real-time system, the O-O (Object-Oriented) modeling is the
most effective way to represent its behavior. This model expresses the system
requirements using an object model, designs using objects and develops the system in an
O-O programming language. O-O programming language, like Java is a better language
to develop a real-time system. The O-O modeling can be used to break down this
complex system into more simple and manageable components. This approach also
improves reusability of the system.

The UML was chosen to design the system, as the purpose of the UML is visualizing,
specifying, constructing, and documenting O-O systems.

Initially the existing manual requirements were gathered from the Marakanda Staff using
the requirement gathering methods such as Interviewing, manual documents etc. Then the
UML system requirements model was created with no implementation constraints for the
Travel Management system. Designed the UML system requirements model consisting of
the system requirements statement (text), system collaboration diagram showing inputs
and outputs, use case diagram, sequence diagram for each use case scenario, and finally
the Class Diagram.

There was a great deal of feedback between stages of the design process. Also, iteration
from one stage to another was carried out at the design process.

4.2 UML visualization

Unified Modeling Language version 2.0 is the designing mechanism used for the initial
designing of dynamic and logical views of the system. Rational Rose 2000 is the tools
used in order to design the necessary diagrams relate to each view of the system.

20
4.2.1 Use Case Diagrams

The main use case diagram shown in Figure 4.1 provides a picture of the system
boundary and the general functionality. Main users of this diagram are identified as the
traveler, secretary, reviewer and approver.

The other use cases were documented with flow of events. The flows of events
documents and the use cases are given in Appendix A.

Figure 4-1 Create Travel Expense

21
4.2.1.1 Claim Travel Expenses

Brief Description
This use case allows a traveler to create travel bill based on trip.

Flow of Events
Basic Flow
When the traveler is logged in and can create travel bill based on travel information.
Alternative Flows
When the secretary is logged in and can create travel bill based on travel information.
Special Requirements
None
Pre-Conditions
Subscriber has to have a valid login session.
Post-Conditions
None
Extension Points
None

22
4.2.2 Activity Diagram

4.2.2.1 Activity Diagram – Create Travel Bill

Figure 4-2

23
Scenario Summary
The following flows are included in this use case.
Basic Flow: User Creates Domestic Travel Bill
Sub Flow A: Connect unbalanced travel advances to the bill
Sub Flow B: Connect the newly created travel bill to another old travel bill.
Sub Flow C: Enter deductions for free meals and night allowances
Sub Flow D: Enter journey information
Sub Flow E: Enter interruptions
Sub Flow F: Enter Car Expenses
Sub flow G: Enter other expenses information
Sub flow H: Enter other expenses’ accounting information
Sub flow I: Car accounting information updating/entering

Activity diagram shows use case realization and given in Appendix A.

4.2.3 Sequence Diagram Designing

4.2.3.1 Create Travel Bill

Figure 4-3

: CreateTravelAction : TravelBillHelper : TravelDelegate : TravelDAO

: Traveler

1: process(request,'Create',TravelForm)

2: validate(TravelForm)

3: Infor

4: Invalide Infor or more infor request

5: populateDTO(TravelForm)

6: storeTravelBill(TravelDTO)

7: validateAccounting(TravelDTO)

8: Infor

9: storeTravelBill(TravelDTO)
10: Invalide account Infor

11: success

12: success

13: success

24
Sequence diagram shows object interactions arranged in time sequence. The sequence
diagrams of the system are given in Appendix B.

4.2.4 Designing of Classes

The Travel Management System is developed under the J2EE technology using main
components of J2EE framework. Following J2EE components, which are defined J2EE
specification, are used in the system

• Java Servlets and Java Server Pages (JSP) technology components, which
describes as web components run on the server.

• Enterprise JavaBeans (EJB) components define business components run on

the server.

J2EE components are written in the Java programming language and are compiled in the
same way as any program in the language. The difference between J2EE components and
“standard” Java classes is that J2EE components are assembled into a J2EE application,
are verified to be well formed and in compliance with the J2EE specification, and are
deployed to production, where they are run and managed by the J2EE server.

Since the total system is designed according to the concepts of Object Oriented Design
and Analysis methodology, it functions under the concept of classes in various layers of
the system, using the instances created at those stages. Those main layers can be listed as
the Presentation layer, Business layer and the Persistence layer.

Most impotently the business layer of the system is designed using the EJB classes as
described above. Due to this reason the final representation of the main classes of the
system are consisting of Session Beans classes and Entity Beans classes.

System is only accessible using a web browser through web interfaces, which are
identified as boundary classes. These presentation layer components can be identified as
the JSP pages those are defined as web pages.

The middle layer server process is broken down into several layers, which consist of
several java classes. Business logic and the database handling part are done using those

25
middle layer classes. J2EE application server is running in order to process this middle
layer functionality and database server is running for the storage purpose.

Business logic part is handled by the functionalities provided by the Session bean classes
where as the database handling functionalities are handled using the DAO classes. All
these business layer classes are designed as container managed persistence mechanism.
So it uses the facilities provided by the EJB and J2EE server in manipulating business
logic functionalities as well as database access processors.

Following figure shows the classes designed according to the EJB specification and some
of the main classes are shown in this diagram. Example of some Session bean classes and
Entity bean classes are shown in this diagram together with the other classes of the
system.

26
Figure 4-4 Class diagram

27
4.3 Database Design

4.3.1 Obtaining the ER diagram

Procedures and steps followed during the physical design of the Travel Management
System can be listed as follows.

• Gathering requirements and write the requirements document.

• Extracting appropriate use cases and creates use case diagrams.

• Create business use case diagram and complete the description of all use cases
in the document.

• Finding business entities and their relationships.

• Identifying the classes required according to the requirements gathered and

draws the initial view of the class diagram.

• Designing process of interaction diagrams – entity sequence diagrams.

• Identifying the interaction between classes and obtaining the final class
diagram with the properties and actions.

• Starting from the final class diagram obtain the DB tables.

• Connected entities (DB tables) in the similar way as class diagram would be
connected.

After following the procedure described above, it has arrived the final structure of all
entities and their relationships as shown in the following diagram.

Only the main entities such as TravelDTO, TravelAdvanceDTO, TravelSearchDTO, etc.

have derived as accordance to the final class diagram as described above. Other
supporting entities such as Expense, Journeys, etc are derived from the entity relationship
diagram it self, after identify such entities necessary for keeping the entities in a formal
manner.

28
4.3.2 Entity Relationship Diagram
Figure 4-5

29
4.4 Design of User Interfaces
Since the system is designed in the form of dynamic web application, all the user
interaction screens are web pages. One of the main components of J2EE framework, the
JSP technology, is used as for this web page design.

JSP technology allows to easily handling content that has both static and dynamic
components. JSP technology makes available all the dynamic capabilities of Java Servlet
technology but provides a more natural approach to creating static content. The main
features of JSP technology are as follows:

• A language for developing JSP pages, which are text-based documents that
describe how to process a request and construct a response.

• An expression language for accessing server-side objects

• Mechanisms for defining extensions to the JSP language

4.4.1 Home Page

Initial home page of this web application is showing in the following figure. This page
also can be considered as the login screen for all user types.

Figure 4-6 – Home page

30
Users who in intended to login to the system have to provide valid user name and a
password in the spaces provided on this screen. Users are allowed to enter into the system
after validating such user id and the password. Any messages relating to the login process
also will display in this page.

4.4.2 Main Pages for Traveler and Administrator Users

Depending on the type of the user logged into the system, main pages appearing for each
type of user are different from each other. This page contains the available system
functionalities for each user group.

Following figures display the main screen for admin user followed by the main screen for
the traveler user.

Figure 4-7 - Admin User Page

31
 Figure 4-8 - Traveler User Page

Both the main screen has the facility of viewing the welcome message in the main body
of the screen. And messages will be displayed in the left hand side of the screen. This
message board is a dynamic component.

Menu bar of each screen shows the available options for each type of user providing the
navigation to each page of such functionality.

4.4.3 Menu Navigation Screen

Figure 4-9 - Menu navigation bar

As it shown in the Figure 4.6, all the application navigation handles by menu tool bar.

32
4.4.4 Data Entry Screen

Some of the data entry screens in the system have the same behaviors. But most of the
screen has it own ways depending on the usage. These data entry screens may include the
all the master data entry screens such as agreement master, policy master, etc and the
transaction data entry screens such as travel bill data screen etc. Common behavior of
these screens is described in the following paragraph.

Figure 4-10 – Input Search

By clicking on the icon showed in the Figure 4.7, which appears in the data selection
shown in figure 4.8,

Figure 4-11 – Search Popup

33
 Figure 4-12 – Calendar Selector

By clicking on the icon showed in the Figure 4.9, which appears in the date selection
shown in figure 4.10,

Figure 4-13 - Calendar

In the places where the user wants to enter and date values, it has given the facility to
select a particular date using a graphical screen as shown in the Figure 4.10 above.

4.4.5 Search Screen

Figure 4-14 - Export icons

In the place where user wants to export to some search results, it has given a facility to
select particular formats to export.

Figure 4-15 - Search

As it shown in the above Figure 4.12, the bottom part of each search screen contains the
list of records for the corresponding data set. All the available records for the option is
list here and with the assistance of “Next 10” and “Previous 10” buttons underneath the
records, it is possible to navigate through all the records accessible for the option.

34
 Figure 4-16 - Edit, Copy, Add Notes

By clicking on the icons showed in the Figure 4.13, which appears in the end of each
record, user can select the required record to the entry area of the screen for the purposes
such as viewing more detail of the record, editing existing contents of the record or for
deleting the record, coping data, add notes.

Figure 4-17 Search and Clear

By clicking on the search button will display the result list and clicking on the clear
button will clear the search criteria.

4.4.6 Messages
Figure 4-18 - Messages

Data entry validation and the other login messages are display in the left panel on the
system.

35
4.4.7 Help Text

Figure 4-19 - Help

Help test are display in the right panel of the system and when ever user clicked on the
input field caption, help text will be populate.

4.5 Summary
The design process of the system is explained step by step giving necessary diagrams.
The selection of modeling techniques is argued giving reasons. Design of main
components such as dynamic web pages, Enterprise Java Bean classes, other web
components also discussed in detail.

Following chapter will discuss more detail about implementation.

36