EDS Electronic Diary System

COM3021 – Final Dissertation Report
EDS – Electronic Diary System
Usman Aslam
Professor Martin Cooke
05/05/04
This report is submitted in partial fulfillment of the requirement for the degree of
Bachelors of Science with Honors in Computer Science by Usman Aslam.
I. Declaration
All sentences or passages quoted in this dissertation from other people's work have been
specifically acknowledged by clear cross-referencing to author, work and page(s). Any
illustrations which are not the work of the author of this dissertation have been used with
the explicit permission of the originator and are specifically acknowledged. I understand
that failure to do this amounts to plagiarism and will be considered grounds for failure in
this dissertation and the degree examination as a whole.
Name: Usman Aslam
Signature:
Date: 05 May 2004

II. Abstract
This report describes the design and implementation of EDS an Electronic Diary System
for the Department of Computer Science. EDS allows both staff and students of this
department to arrange meetings and appointments with other members of the staff. A
number of architectures and design models were examined for this purpose but MVC
design pattern within a three tier architecture was found to be the most suitable approach.
Although, a number of technologies such as Jakarta Velocity and XMLC could have been
used for implementing the designed architecture but JSP Type II solution was deemed to
be the best approach.
III. Acknowledgements
I would like to thank the following people:
• My Project Supervisor, Professor Martin Cooke for all his help and support
•
throughout this semester.
•
My parents for their prayers.
My cousins Syka and Qamar Khan for proof reading my report.
IV. Contents
Chapter 1 Introduction……………………………………………………………... 1
Chapter 2 Technology and Design Review………………………………………… 3

2.1 System Comparison………………………………………………………….......…….. 3
2.2 Architecture…………………………………………………………………...…….…. 3
2.3 Web Tier – Design Patterns……………………………………………………...…..… 5
2.4 Web Tier – Programming Technology……………………………..…………..……… 6
2.5 Web Tier – Server Technology………………………………………………………… 9
2.6 Data Tier – Database………………………………………………...………….……… 9
2.7 Data Tier – Database Design…………………………………………...……….……… 9
2.8 Data Tier - MySQL Database Management System…………………..………..……… 11
2.9 Interface Design and Usability………………………………….……………...……… 12
2.10 Chapter Summary ………………………………………………………………….... 12
Chapter 3 Requirements and Analysis…………………………………………….. 14

3.1 Aims and Objectives……………………………………………………………… 14
3.2 User Analysis…………………………………………………………………….. 15
3.3 Approach to Requirement Gathering………………………………………………. 16
3.4 Requirements……………………………………………………………………... 16
3.5 System Testing and Evaluation……………………………………………………. 19
3.6 Chapter Summary………………………………………………………………… 20
Chapter 4 Design…………………………………………………………………….. 22
4.1 Web Tier Design………………………………………………………………….. 23
4.2 Data Tier – Design………………………………………………………………... 25
4.3 Connection Pooling……………………………………………………………….. 27
4.4 Interface Design and Compliancy of Nielsen’s Usability Heuristic………………….. 27
4.5 Prototype…………………………………………………………………………. 28
4.6 Chapter Summary………………………………………………………………… 28
Chapter 5 Implementation………………………………………………………….. 29
5.1 Web Tier – Overview……………………………………………………….…….. 29
5.2 Web Tier – Controller Implementation……………………………………….……. 31
5.3 Web Tier – Model Implementation………………………………………….……... 31
5.4 Connection Pooling………………………………………………………….……. 33
5.5 Web Tier – View Implementation………………………………………….….…… 34
5.6 Data Tier – Implementation………………………………………………….……. 39
5.7 System Statistics…………………………………………………………….……. 40
5.8 Apache Ant……………………………………………………………………….. 40
5.9 Chapter Summary………………………………………………………………… 40
Chapter 6 Testing………………………………………………………………… 41
6.1 Application Functionality…………………………………………………………. 41
6.2 Performance Testing………………………………………………………………. 42
6.3 Results and Discussions………………………………………………………….... 44
Chapter 7 Case Study: A Web Application Interacting with LDAP…………….. 45

7.1 Introduction...…………………………………………………………………….. 45
7.2 LDAP Server.…………………………………………………………………….. 45
7.3 LDAP Application………………………………………………………………... 46
Chapter 8 Evaluation………………………………………………………………... 50
8.1 System Evaluation………………………………………………………………... 50
8.2 Planning………………………………………………………………………….. 52
Chapter 9: Conclusions……………………………………………………………... 53
10 References………………………………………………………………………… 54
11 Glossary…………………………………………………………………………… 56
12 Appendices ………………………...……………………………………………... 57
12.1 Appendix: Use Case Diagrams…………………………………………………... 57
12.2 Appendix: EDS File Structure…………………………………………………..... 58
12.3 Appendix: web.xml……………………………………………………………… 58
12.4 Appendix: EDS Database Tables ………………………………………………… 59
12.5 Appendix: build.xml……………………………………………………………... 60
12.6 Appendix: Example LDIF File…………………………………………………… 60
12.7 Appendix: Administration Guide…………………………………………………. 60
12.8 Appendix: Deployment Guide……………………………………………………. 61
Figures
The first digit in the figure refers to the chapter in which that figure can be found
Figure 2.1: Interface of Corporate Time displaying the weekly schedule………………….. 2

Figure 2.2: Interface of MyAppointments.net displaying the weekly schedule,
appointments and diaries to which the user has/her access to……………………………... 3
Figure 2.3: Three Tier Architecture ……………………………………………………... 4
Figure 2.4: Model View Controller Design Pattern………………………………………. 6
Figure 2.5: MVC design pattern with in a Velocity application…………………………… 7
Figure 2.6: MVC design pattern within an XMLC application……………………………. 8
Figure 4.1: MVC design pattern within a three tier architecture of EDS…………………… 22
Figure 4.2: Activity Diagram for Add/Staff Student ……………………………………... 24
Figure 4.3: Activity Diagram for searching staff schedule………………………………… 24
Figure 4.4: Sequence Diagram for login…………………………………………………. 24
Figure 4.5: Sequence Diagram for Add Staff/Student…………………………………….. 25
Figure 4.6: Conceptual Database Design………………………………………………… 26
Figure 5.1: Architecture and file structure of EDS………………………………………... 29

Figure 5.2: Code listing of the method init defined in the ControllerServlet……………….. 30
Figure 5.3: Code listing of the method getEvent in the EventHandler class………………... 31
Figure 5.4: Code listing of the method staff in the EventHandler class…………………….. 31
Figure 5.5: Establishing a connection with the database…………………………………... 32
Figure 5.6: Code listing of Schedule.jsp…………………………………………………. 32
Figure 5.7: Code listing of addSchedule method of ScheduleBean………………………... 33
Figure 5.8: Code listing of the addSchedule method in ScheduleDataHandler………….….. 33
Figure 5.9 Code listing of ConnectionPooling class…………………………………..…... 34
Figure 5.10: Screen shot of upper part of the Schedule.jsp………………………………... 35
Figure 5.11: Screen shot of lower part of the Schedule.jsp………………………………... 35
Figure 5.12: Screen shot of the ViewAppointments.jsp…………………………………… 36
Figure 5.13: Screen shot of the upper part of Search.jsp…………………………………... 37
Figure 5.14: Screen shot of the lower part of Search.jsp…………………………………... 37
Figure 5.15: Screen shot of ViewStudents.jsp……………………………………………. 38
Figure 5.16: Screen shot of UpdateStudents.jsp…………………………………………... 38
Figure 5.17: Screen shot of ImportData.jsp………………………………………………. 39
Figure 5.18 Screen shot of ResetSystem.jsp……………………………………………… 39
Figure 6.1: Code listing of LoggingIn.tsl………………………………………………… 41

Figure 6.2: LoggingIn.frm generated by catpart………………………………………….. 42
Figure 7.1: Code listing of the first part of the method getEnv……………………………. 47
Figure 7.2: Code listing of the second part of the method getEnv…………………………. 47
Figure 7.3: Code listing of the third part of the method getEnv…………………………… 47
Figure 7.4: Code listing of storing the Hashtable object in the ServeltContext……………... 47
Figure 7.5: Code listing for searching LDAP server……………………………………… 47
Figure 7.6 Code listing of obtaining the full DN…………………………………………. 48
Figure 7.7: Code listing of changing the credentials and a reattempt to connect……………. 48
Figure 7.8 Code listing of the method getUser…………………………………………… 49
Figure 8.1: Modified version of MVC design pattern used in EDS……………………...… 51

Tables
Table 3.1: User Analysis………………………………………………………………... 16
Table 5.1 EDS programming statistics 40
Table 6.1: Test case for LoggingIn.frm…………………………………………………... 42

Table 6.2: Performance Testing Test Case 1……………………………………………... 43
Chapter 1 Introduction
Web-based diaries are becoming increasingly common in both commercial and educational
institutions for countless reasons. Commercially, web diaries are used in large institutions
where they serve as effective means of organising schedules between employees.
Scientifically, they can be used to carry out studies or research. For instance, in 2002, the
Department of Epidemiology, School of Public Health and Community Medicine of the
University of Washington, finished a study in the transmission rates of genital human disease
using a web based diary. A web diary was held for each of the study participant and could
only be accessed through the university facilities. The data was entered in the diary through
the selection of check boxes and radio buttons, which suggests that the diary was designed to
accommodate even for the most novice users. On completion, the researchers of this study
found that their aims and objectives were fully achieved and this would not have been the
case if they had used an alternative that did not involve the use of web diaries.
Within the Department of Computer Science in the University Of Sheffield, the current
practice for arranging appointments between staff is governed via the email system. If a
member of staff needs to make an appointment with his/her counterpart, he/she would send
them an email and wait for their response. This cycle can continue till they both agree on a
time. Similarly, if the students in the department encounter any hardships or difficulties in
their relevant subjects, their points of contact are their relevant lecturers. At the moment, the
most common and advised trait among students for arranging an appointment with the desired
lecturer is also via email. As such, the arrangement described is not only lethargic and time
consuming, but it also requires a lot of effort, considering the entire aim is just to arrange
meetings.
Thus, the central concern of the project is to develop a system that allows meetings and
appointments to be set up between staff of the DCS in an efficient and simple manner with
minimal effort. Initially, this project was to apply to staff only but at a later stage it was
explained to the client that this functionality could be extended to incorporate students as
well. Thus, a secondary or an optional concern of this project is to allow students to setup
meetings with members of staff. However, an important thing to note is that this project will
not allow students to setup meetings with each other or staff to set up meetings with students.
It seems that a web based application will provide an ideal solution for such concerns and as
in any such application the objective is to build a web based secure, efficient, robust and user
friendly diary system for the use of students and staff of DCS.
In order to achieve the aims and objectives described above, time-scale can be identified as
the single and most important constraint. To gain a realistic result from design to actual
implementation, effective planning will play an important role.
This report describes the development of a system named as EDS “Electronic Diary System”
It commences by identifying various architecture and designs, which could have been used in
this project along with a detailed examination of any decisions or choices made. It then
follows on to the Requirements and Analysis section which offers an analysis of the user
community while explaining how the final application will be tested and evaluated. Using the
concepts considered in the Technology and Design Review, the Design section presents the
high level design of EDS. The knowledge from all previous chapters is then used in the
implementation of EDS and is described in the Implementation section. The following chapter
details the approaches used for testing EDS. The issues encountered and the results achieved
during the course of this project are discussed in the Evaluation section. Based on the issues
raised in the Evaluation a case study that describes how to connect, authenticate and query
LDAP is also described. Finally, the Conclusion chapter highlights the main points that run
through out the project.
1
Chapter 2 Technology and Design Review
This chapter starts by providing a brief account of similar applications to EDS. However, the
main focus of this chapter is the review of the literature that forms the basis for the selection
of architecture and design patterns for EDS. Furthermore, it also highlights technologies that
have been selected to implement EDS, as well as the reasons for choosing them.
2.1 System Comparison:

This section gives a brief background to existing software applications that provide similar
functionality.
2.1.1 Corporate Time:
Recently, a web based diary called “Corporate Time” has been made available by the
University of Sheffield for all the members of the staff via MUSE, the new University portal
service. “It is group calendar software that allows computerised diary scheduling. With
Corporate Time, users can arrange meetings and view other user’s agendas” [www.17].
Although, from the outset it seems that this application does posses some functionality similar
to what is required for EDS as illustrated in Figure 2.1. However, EDS will be made available
only for the students and staff of DCS, unlike Corporate Time which can be accessed by all
the staff in the University of Sheffield. Furthermore, students do not have access to Corporate
Time and therefore it was not possible to analyse the design or features implemented by this
application in detail without actually testing it.
Figure 2.1: Interface of Corporate Time displaying the weekly schedule
2.1.2 MyAppointments.net:
MyAppointments.net is a shared diary system that can be accessed from anywhere in the
world [www.18]. There are two versions of this application:
2
• Windows version that runs on the user’s PC and connects to the internet using
•
MyAppointments web server.
Web Browser version that doesn’t require installation and which can be used from
any PC connected to the internet.
For this project we are only concerned with the evaluation of the web version. The evaluation
was carried out by analysing the functionality and the ease with which the user can use the
application. Some of the basic features of this application are as follows:
• Administrator can add as many users to the system and a diary is created
•
automatically by the system for the added user.
•
Each user can decide who has access to his/her diary.
This application supports multiple accesses by concurrent users. Also, as soon as an
•
appointment is added it becomes available to other users.
•
Each user can organise diaries into groups to avoid a long list of diaries.
•
An appointment can be added in multiple diaries at once.
This application also allows users to add appointments on a daily or weekly basis in
more than one diary.
Figure 2.2: Interface of MyAppointments.net displaying the weekly schedule,

appointments and diaries to which the user has/her access to
As far as functionality is concerned, this application implements far more functionality then
the scope of this project. However, in terms of quality of the user interface this application is
very complex because it takes quite a long time to figure out how different functions are
performed.
2.2 Architecture:
In computing, architecture can be defined as “the conceptual structure and overall logical
organisation of a computer or computer based system from the point of view of its use or
design” [www.1].
Architecture is one of the first considerations while developing any web based application. At
a high level, the architecture of an application defines how different parts of the system are
organised and logically separated yet ensuring that they work together. Furthermore,
3
architectures can be split into tiers and it is the concept of tiers that provides a convenient way
to group different classes of architectures [www.2].
Designing the architecture in tiers is useful because it supports layering, promotes scalability
and allows easy maintenance of the application. At present, three-tier architectures are most
commonly employed in web based applications.
As in any web based application, a typical three tier architecture consists of the following
tiers; client tier, web tier and the data tier as illustrated in the Figure 2.3.
Client tier
Request
Web tier Response
Application
Controls
Query
Data tier Data
Data Storage
Figure 2.3: Three Tier Architecture
Client tier: is the topmost layer. Its primary concern is to display the results of any user
requests. This layer, in most cases will consist of a web browser running on the user’s
machine.
Web tier (Business logic layer): This layer is primarily concerned with business logic (or
tasks). Business logic includes [www.3] [www.4]:
•
•
validation of input
•
performing calculations (or tasks)
•
keeping track of sessions
access and retrieval of any data required for the presentation layer
Data tier: This layer is concerned with data storage and persistence issues and can be
implemented by using a database or some sort of file storage mechanism. The data can either
be stored on the web server itself or on a different machine; however it needs to be easily
accessible by the web server.
An alternative approach to three-tier architecture is the page-centric approach (two-tier

architecture). The applications built using this approach normally consist of one or more
programs running on the client’s machine communicating over the network with a server
based application. Such applications can be built by using a collection of JSPs or Servlets that
have direct access to database for servicing a client’s request.
During the course of this semester, a prototype was built using the “page centric with bean
approach”. However, on completion of the prototype, it was realised that
4
•
•
The application’s code is a mixture of presentation, business and data access logic.
•
The application’s business and presentation logic code is not reusable.
•
The prototype application did not support scalability.
It will be difficult to enhance or change a part of the system’s functionality, if
required to do so at a later stage.
In addition to the above factors, the main disadvantages of using this approach are as follows
[www.5, www.6]:
•
•
Changing business logic layer involves recompiling and redeploying the client layer.
In efficient use of network services as database drivers have to be installed and
•
configured on the client tiers.
Database connection costs are high because each client will have to establish a
database connection.
Thus by taking these factors into account, a “three-tier architecture” is selected for EDS as
compared to “page centric approach”. Also, another key reason for choosing a three-tier
architecture is that it splits the application into manageable components by allowing these
components to exist as separate entities at each level and therefore each component can be
developed in parallel to each other. Further benefits of using a three-tier architecture include
[www.7], [www.8], [www.9]:
• The resource allocation is more flexible because the middle tier can be changed
•
dynamically according to the needs.
•
The middle tier can also be used by other applications.
Change in one tier does not necessarily have an effect on the other tier (e.g. data
structure in the database can be changed with out affecting the client tier).
2.3 Web Tier - Design Patterns:

While designing and building applications, problems are encountered that are either same
or similar to particular problem domains. Instead of developing a new solution each time
for a similar problem, “it would be ideal if there was a repository which captured such
common problem domains and proven solutions” [www.10]. Thus, a solution to such a
scenario is the use of design patterns as they “describe a problem which occurs over and
over again in our environment, and then describe the core of the solution to that problem,
in such a way that you can use this solution a million times over, without ever doing it the
same way twice” [www.22]. In addition to this, design patterns can identify potential
pitfalls in the early stages of software development as well as providing a common
vocabulary for designers [www.10].
2.3.1 Model View Controller (MVC):
Model View Controller design pattern was originally defined by Smalltalk in 1970’s. It was
defined to be used in development of traditional software applications but MVC has a lot to
offer for web applications as well.
5
Figure 2.4: Model View Controller Design Pattern
MVC design pattern splits the application into three parts, which can be considered as black
boxes whose inner workings are hidden and independent of each other. These three parts are
illustrated in Figure 2.4 and are described below:
Model: represents business logic or processes that govern access and modification of data.
The model is responsible for alerting the view when it changes and provides the ability for the
view to inquire from the model about its state. It also allows the controller to access the
functionality encapsulated by the model.
View: renders the contents of the model. It is responsible for accessing data from the model
and then indicating how that data should be presented. It updates the presentation data when
the model changes. A view also forwards user inputs to the controller.
Controller: defines the behaviour of the application. It is responsible for dispatching user
requests and selecting views for presentation. It also defines how to react to user inputs by
mapping them into actions to be performed by the model and furthermore controller also
decides the next view to display. In a stand-alone application, inputs from the user usually
consist of button clicks and menu selections. However, in a Web application, these are HTTP
GET and POST requests to the Web tier. A typical application has one controller for each set
of related functionality. However, some applications use a separate controller for each
different type of client, because view interaction and selection often vary between client types
[www.9].
The web tier of the EDS architecture will be structured by using MVC design pattern. The
concept for using this approach in EDS is to divide the functionality of the application
“among objects involved in presenting and maintaining data to minimise the degree of
coupling between the objects” [www.9]. Besides this, further reasons for using MVC in this
project include:
•
•
It supports flexibility.
•
It allows reuse of components e.g. model can be represented in several ways.
It decreases coupling.
2.4 Web Tier – Programming Technology:
6
This section examines the technologies that can be used in the implementation of a web
application that is structured by using the MVC design pattern within a three tier architecture.
2.4.1 Jakarta -Velocity:
Velocity is a Java based template engine that ensures the separation of logics by supporting
the development of a system based on MVC design pattern within a three tier architecture.
However, before any implementation can take place, the designers and programmers need to
decide on a set of data to be made available to the templates. This allows the designer to
create the velocity templates, whilst the programmer can concentrate on writing the Java
classes representing the business logic. The high level architecture of the application using the
Velocity engine based on MVC design pattern is given in Figure 2.5.
request get template

Controller View
Velocity Templates
response Velocity Servlet
Merge template Put data in

with context initialise
context Model
Java classes
Context data
Figure 2.5: MVC design pattern with in a Velocity application
In Velocity, all communication between different components of the MVC design pattern is
controlled through the “Context” object, which is obtained by extending the VelocityServlet.
Furthermore, in Velocity applications the object Context is populated by using data from the
Java classes representing the model, which is then made available to the templates by merging
them with the Context object.
2.4.2 Enhydra XMLC:
XMLC provides an object-orientated mechanism for creating dynamic content from static
HTML and XML document [www.17]. Whilst using XMLC, the first step is to create
template pages in HTML or XML. Furthermore, elements within the page need to be uniquely
identified by using the id tags. The pages are then compiled offline by XMLC, which results
in the creation of a Java class. This class contains a Document Object Model (DOM) tree
representing the page.
The web tier of the application developed using XMLC based on the MVC will have the
following design as illustrated in Figure 2.6:
7
View
XML/HTML compile Java classes containing
Templates DOM Tree
instantiate
Controller data
Servlet
Model
Java classes
instantiate
Figure 2.6: MVC design pattern within an XMLC application
2.4.3 JSP Type II Solution:
Type II solution involves using the following technologies:
•
•
Java Servlet
•
Java Server Pages
Java Beans
This section gives a brief overview of each of these technologies and the role they play in the
MVC design pattern.
Java Servlets:
Java Servlets are small, pluggable extension to a server that enhances the server’s
functionality [13]. The life cycle of a servlet consists of it being loaded on to the web server;
when the first request is received for it. After this, the servlet remains in the memory of the
server and thereafter upon receiving a request; it processes the client’s request and returns a
response to the server.
The servlet in this type of solution will act as the controller and will be responsible for
dispatching user requests.
Java Server Pages:
Java Server Pages (JSP) is an extension of the servlet technology and provides a framework to
create dynamic content on the server using HTML and XML templates. A JSP page is
executed by a JSP engine or container installed on the web server. In the type II solution JSP
will constitute the view.
Java Beans:
Java Bean is essentially a class written in Java language, in which the actual data is usually a
private or protected instance variable that can be accessed\edited via publicly available
methods. Java Beans specification acts as the model component and serves as the final
addition to type II solution. It encapsulates the business logic behind the application and
therefore removes bulk of the scriptlet code that would have cluttered up JSPs. They are
reusable components that can be manipulated by JSP action tags and are used across multiple
JSP pages.
8
JSP Type II solution will be used in implementing the web tier of EDS. Although, all the
above technologies support the development of web applications by the use of MVC design
model but the main reason for not using XMLC and Velocity is that they are relatively new
and therefore the documentation for these is relatively scarce as compared to the technologies
used in JSP Type II solution. Furthermore, in Type II solution it is easy to change the
presentation layer in contrast to XMLC because updating the HTML/XML templates requires
recompilation.
2.5 Web Tier - Server Technology:

The web tier of the application will consist of a collection of JSPs, servlets and Java Beans,
which need to run on a web server. The basic task of a web server is to “listen for HTTP
(where HTTP is a protocol used to transfer information on the world wide web) requests on a
network, receive HTTP requests by the user agents, serve the request, and return the HTTP
responses that contain the required resources” [12 (Section 1.3.1)].
Tomcat is a popular open source web server, which is part of the Apache Software
Foundation project. Tomcat consists of the following two containers [14]:
•
•
Catalina: A servlet container that executes both servlets and compiled JSP pages.
Jasper: A container that compiles a JSP into a servlet before the execution of the JSP.
The combination of these two containers is known as a “web container”, which is capable of
hosting Java web applications.
Tomcat serves as Sun’s official reference implementation (RI), which means that tomcat’s
first priority is to be fully compliant with the Servlet and JSP specifications [www.12], [14].
2.6 Data Tier - Database:

The data tier of the architecture is primarily concerned with data storage and handling. EDS
will have a very large user community and every function performed by the system, in
essence will depend on data storage or information retrieval at some stage, therefore key
issues that need to be considered while handling data are persistency, concurrency, portability
and security [www.10]. These issues can be addressed by using a database system, as it
provides sophisticated data retrieval and manipulation facilities, together with enhanced
security and integrity facilities [2], [1]. Thus this was one of the main reasons for deciding to
use a database system or to be more precisely a “relational database system” to implement the
data tier.
A database is “an organised collection of inter-connected data items” [www.11] and is

managed by Database Management System (DBMS), which is “a complex set of programs
that control the organisation, storage and retrieval of data for many users” [www.11].
Database and DBMS, together with the applications that use the database are collectively
called a database system [16].
2.7 Data Tier - Database Design:

Database design is “the process of creating a design for a database that will support the
enterprise’s operations and objectives” [3 (p.119)]. For EDS, the major aims of the database
design are to:
•
•
present a data model that supports any transactions required on the data.
represent relationships between different parts of the data model.
9
• provide a minimal design, which is suitably structured to achieve the specified
requirements for the system.
2.7.1 Entity/Attribute Analysis:
For EDS, Entity/Attribute Analysis will be used to divide the data into the following
classifications [www.13]:
• Entities: are representations of the real world objects that need to be described in the
database. An entity class is a collection of similar objects and an entity is an instance
•
of an entity class.
Attributes: describe the properties or characteristics of an entity class and each
instance of an entity has a similar set of attribute values. Attributes are not necessarily
specific to any entity class and therefore the same attribute can occur in more than
•
one entity class.
Relationships: are connections between two entities; and it is an instance of a
relationship type. Relationships fall into three categories:
a. 1 : 1 (One to One) Such a relationship links a pair of entities e.g. ‘is married
to’.
b. 1 : m (One to Many) Such a relationship links a single entity with a collection
of other entities and each member of this collection can only be linked to one
entity e.g. ‘is the mother of’.
c. m : m (Many to Many) Such a relationship links one entity with a collection
of other entities each of which may be linked to other entities as part of the
same relationship e.g. ‘is the cousin of’.
2.7.2 Top-down and Bottom-up Approaches:
There are two main approaches to the design of a database system, which are referred to as
“top-down” and “bottom-up” [1]. The top-down approach starts by identifying high-level
entities and relationships between them. The developed data structure then undergoes top-
down refinement successively to produce a final model that contains lower-level entities,
associated attributes and relationships. The alternative approach bottom-down is effectively
the opposite of top down and starts from the “fundamental level of attributes, which through
analysis of the association of attributes, are grouped into relations that represent types of
entity and associations between entities” [3 (p.119)]. For EDS, top-down approach will be
used to design the database. The reason being that this approach has been used in previous
modules and not only was it easy to use but it also produced satisfactory and reliable results.
Furthermore this approach has been found to be much more suitable for designing a database
for large and complex organisations as compared to the bottom-up approach [1].
2.7.3 Three Stages of Database Design:
The database design consists of the following three stages [2], [3]:
Conceptual Database Design: This is the first phase of database design and involves
gathering of information and constructing a “conceptual data model” about the concerned
organisation (or part of the organisation) that relates to the system in question. Also, no
considerations are given to any implementation details or physical conditions, during this
phase of the database design.
Logical Database Design: This is the second phase of the database design and involves the
construction of a logical data model by refining the data model that was constructed during
the conceptual phase. Unlike, the conceptual data model, the logical data model is constructed
while keeping in mind the underlying data model of the target DBMS e.g. relational, network
10
or hierarchical etc. However, this model does not take into account any other aspects of the
chosen DBMS or other physical conditions. Also, through out this stage, the technique of
normalisation is used to test the correctness of the logical data model.
Physical Database Design: This is the final stage of the database design and is concerned
with how to physically implement the database, which in turn depends on the specific DBMS
that has been selected for the task. E.g. for EDS, MySQL DBMS has been selected, therefore
the data model is relational and hence for a relational model, this phase involves designing the
database tables and constraints, identifying storage structures and access methods and
designing security protection.
2.8 Data Tier - MySQL Database Management System:

MySQL is a very popular open source, free Relational Database Management System that
uses Structured Query Language (SQL) [www.20]. Although MySQL is widely considered as
a RDBMS but strictly speaking MySQL is not truly a Relational Database Management
System as it does not support views or atomic transactions [6]. Therefore, it does not qualify
as a true Relational DBMS under Codd’s rules.
A key reason for deciding to use MySQL is the author’s familiarity with SQL from previous
modules. Alternatives to MySQL include open source packages such as MiniSQL (known as
mSQL) or PostgreSQL. A brief comparison of MySQL with these technologies is given in
below.
2.8.1 Comparison of MySQL and mSQL:
Performance wise mSQL is quicker than MySQL in performing INSERT, CREATE TABLE
or DROP TABLE operations on a very simple database that has few tables with a small
number of columns and keys. This is because “MySQL has a higher start-up overhead and
these operations are so simple that it is hard to be better at them when you have a higher start-
up overhead” [5 (p.59)]. However, once a connection has been established MySQL is faster
than mSQL in performing [5], [6]:
•
•
Complex SELECT operations.
•
Retrieving large results.
•
Efficient handling of columns that have variable length string values.
•
Supports indexes on VARCHAR columns.
•
Handling tables with large record lengths.
Handles multiple connections at the same time (where in mSQL, when one
connection is established every other connection must wait until the first connection
•
is terminated).
Supports GROUP BY statements (whereas mSQL does not).
Although mSQL does have its advantages but the benefits of MySQL outweigh them and thus
mSQL is not a suitable contender by any means for this project.
2.8.2 Comparison of MySQL and PostgreSQL:
As compared to MySQL PostgreSQL offers [5]:
• Better transaction support (because the transaction support in MySQL is not tested as
•
well as Postgre SQL).
•
Features that are yet not supported by MySQL such as triggers and stored procedures.
Additional speed by allowing the user to code things as stored procedures.
11
• Better optimisation then current MySQL optimiser.
MySQL offers the following advantages over PostgreSQL [5], [www.16]:
• MySQL has a query cache that can boost up the query speed and thus it is generally
•
much faster than PostgreSQL.
MySQL has more APIs to other languages and is supported by more existing
•
programs than PostgreSQL.
MySQL server supports more of the standard ODBC functions than PostgreSQL.
Although, both of these technologies have distinct advantages over each other in certain
aspects and any one of these could have been used for EDS but the main reason for selecting
MySQL over PostgreSQL is that there is far more literature available on MySQL.
2.9 Interface Design and Usability:

A good interface design determines the popularity of the system and therefore becomes a
competitive advantage in the field that it is designed for. For EDS, one of the key
requirements is to build a system that is efficient and is easy to use; therefore the interface
design will serve as a vital ingredient in the success of this project.
Design rules in interface design are in the “form of standards and guidelines that provide
direction for design, regarding issues of presentation, behaviour and interaction for interface
elements and controls” [www.15]. Although, the use of standards and guidelines supports
decisions in design choices but these need to be adjusted according to the needs of the
interface. Thus, all design choices, while designing the interface for EDS will be made
according to the user needs and the task for which the system will be made for.
Further to the interface design, it is also essential to consider the usability of the system,
which is considered a key factor in the design of any software application. According to ISO
9241, usability is defined as “the effectiveness, efficiency and satisfaction with which
specified users achieve specified goals in particular environment” [www.21]. In simple
words, it denotes how well the users can make use of the functionalities of the system. One of
the most accepted measures of such usability comes in the form of Nielsen’s Usability
Heuristics, which are given below:
•
•
Simple and natural dialogue
•
Speak the user’s language
•
Minimise the user’s memory load
•
Consistency
•
Feedback
•
Help and documentation
•
Clearly marked exits
•
Prevent errors
Good error messages
2.10 Chapter Summary:

A three tier architecture will be used in the development of EDS and will consist of the client,
web and data tier. The client tier is the user’s web browser from which requests and responses
are sent and received respectively. Tomcat is the overall container of the web tier for EDS.
The application controls located on the web tier will be structured by using MVC design
pattern. Finally, the data-tier will developed by MySQL Database Management System using
12
the three phases of logical, conceptual and physical design. The user interface of EDS will be
designed while keeping in mind Nielsen’s Usability Heuristics.
13
Chapter 3 Requirements and Analysis
This chapter explains the aims and objectives of this project along with an analysis of the user
community. It then outlines the functional and non functional requirements. Finally, details of
how the system will be tested and evaluated are provided.
3.1 Aims and Objectives:

The aims and objectives of this project are outlined as follows:
Functionality:
• This project’s primary concern is to develop a system that allows meetings and
appointments to be set up between staff of the Department of Computer Science in an
•
efficient and simple manner with minimal effort.
Furthermore, a secondary aim of this project is to extend this facility to students of
Department of Computer Science as well by allowing them to arrange appointments
with members of staff. However, this functionality is optional as it was suggested by
the author to the client.
Design:
The design of EDS must be according to the following guidelines:
• Three tier architecture: EDS must be designed by using a three tier architecture,
•
which consists of client, web and data tier.
MVC Design Pattern: Web tier of EDS must be designed using this design pattern.
General Concerns:
Thus, a “web based diary” serves as an ideal solution to the above concerns and like in any
web based applications, EDS also must satisfy the following:
• Security: Security is of paramount importance in any web application, both from the
point of view of the owner and the users of the application. Therefore, EDS should
only be accessible to authorised users and furthermore all data stored in the database
•
must be secure.
Efficiency: Users are becoming increasingly unwilling to wait for pages to load;
therefore the speed at which the site operates is vital for its success. In order to
minimise the time it takes to generate and dispatch a new page for EDS, interface
design will not include any large graphic files and middle-tier processing code will be
•
made as efficient as possible.
Robustness: A web application should be rigorous enough to handle errors or
exceptions. Even though, sometimes errors in such applications are inevitable
because of the factors that are out of the developer’s hand but for the purpose of this
project, these should be dealt correctly, either by trying to solve the problem or
•
displaying a helpful error message.
Usability: Usability is an important consideration for web applications. Therefore,
the EDS should be easily navigable. Also, the interface of EDS will be designed
while keeping in mind Nielsen’s Usability Heuristics.
Personal Aim:
14
A personal aim of this project is that on completion of EDS it should be deployed on the DCS
network. Thus for the attainment of this aim, the objectives identified were namely
maintainability and compatibility.
• Compatibility: Technologies used in the development of EDS should be compatible
•
with the existing technology in DCS.
Maintainability: The system should be maintainable by the System Administrator
and therefore documentation that covers all aspects of the system needs to be
provided. Also, all the application code should be commented.
3.2 User Analysis:

The user community of the EDS can be split in to the following groups:
- System Administrator
- Staff
- Students
Table 3.1 gives a brief description of each type of user, their approximate number, skills
needed to use the system and the responsibilities they will have when EDS is implemented.
System Administrator
An individual who will be responsible for maintaining the system.
Approximate number: 1 (exact number in this case)
Skills Required:
Ability to access the site and login.
Ability to follow the documentation (that covers all aspects of the system) for the System
Administrator.
Understand the programming technology that will be used to implement the web tier of EDS.
Understand the database technology that will be used to implement the data tier of EDS.
Ability to use the server technology.
Responsibilities:
Managing users of the system and their details.
Respond to any errors or fault in the system (when EDS is up and running).
Staff
For EDS, the term “Staff” includes all Academic, Secretarial and Technical personnel of the
Department of Computer Science.
Approximate number: 50
Skills Required:
Ability to follow the documentation (that covers only those aspects that is related staff’s use)
to perform the desired tasks.
Responsibilities:
Add their schedule to the system.
Update system if schedule is changed.
Students
In DCS, this user group can be split into Undergraduates, Postgraduates and Research
students and hence for the purpose of EDS, the term “Students” will incorporate every one
15
studying in the DCS.
Approximate Number: 500
Skills Required:
Ability to follow the documentation (that covers only those aspects that is related student’s
use) to perform the desired tasks.
Responsibilities:
As such students do not have any particular responsibilities in EDS. In fact, EDS is more like
a facility to them. However, if EDS is implemented in DCS one such responsibility could be
to use EDS for arranging or booking appointments with member of the staff as compared to
sending emails or knocking on their doors.
Table 3.1: User Analysis
3.3 Approach to Requirements Gathering:

Requirements gathering process started even before the summer holidays. Weekly meetings
with the Project Supervisor Professor Martin Cooke served as “Client Meetings” and were
vital source of requirements gathering procedure. Two meetings with the client (Project
Supervisor) before summer holidays served as a basis for the development of the prototype.
However, most of the requirements were gathered in the first three weeks of the first semester
but this is an ongoing process and any comments or feedback from the client (Project
Supervisor) at any stage is vital for ensuring the success of this project. Also, a prototype was
completed during the course of this semester which helped in further clarification and
addition of functional requirements.
The questioning techniques that were used to gather requirements included (learnt during the
COM2070 Software Hut Project):
• Free Exploration: Encouraging the client to explain his view of the system and what
•
he/she wants.
•
Bluesky Wishlists: Identifying more stake holders and pushing for extreme positions.
Iterative Prompting: Prompting the client by asking him questions starting with what,
who, how, why etc.
These questioning techniques were found to be very useful in the COM2070 Software Hut
Project, where the client had no knowledge of computer systems. Although the same
approach was taken for this project but no need was found to fully use these techniques in
depth because of the client’s technical knowledge and background in such systems.
3.4 Requirements:
Requirement Identifiers:
SectionNumber.RequirementNumber
• 3 identifies the section e.g. Staff Requirements

Example: 3.4
• 4 represents the requirement number.
Priority Abbreviations:
16
Each requirement is given a requirement identifier, a description and a priority, which is used
to categorise the requirements according to the following shorthand:
•
•
M – a mandatory requirement, the system must satisfy the requirement.
D – a desirable requirement but one which is not absolutely necessary to the running
•
of the system.
O – an optional requirement which may be implemented if there is sufficient time
remaining.
3.4.1 Functional Requirements:
1 Global Requirements
Req. ID Description Priority

1.1 The System Administrator has access to the system. M
1.2 All members of the staff within the DCS have access to the system M
from anywhere in the world via world wide web (WWW).
1.3 All the student community within the DCS have access to the system D
from anywhere in the world via the web.
2 System Administrator Requirements

2.1 The system should allow the Administrator to add students to the M
system.
2.2 The system should allow the Administrator to delete students from the M
system.
2.3 The system should allow the Administrator to edit student details. M
2.4 The system should allow the Administrator to add staff to the system. M
2.5 The system should allow the Administrator to delete staff from the M
system.
2.6 The system should allow the Administrator to edit staff details. M
3 Staff Requirements
Manage Groups
3.1 The system should allow staff to add group to the system. M
3.2 The system should allow staff to edit group to the system. M
3.3 The system should allow staff to delete group from the system. M
Manage Schedule
3.4 The system should allow staff to add available time slots to their M
schedule.
3.5 The system should allow staff to view their schedule. M
3.6 The system should allow staff to delete available time slots from their M
schedule.
3.7 The system should allow staff to add a single appointment in their M
schedule.
3.8 The system should allow staff to add appointments in their schedule on M
a daily basis.
3.9 The system should allow staff to add appointments in their schedule on M
17
a weekly basis.
3.10 The system should send an automatic email message to the other party, M
if an appointment is deleted by the staff.
3.11 The system should allow staff to search for time slots when specified M
staff member/members is/are free.
3.12 The system should allow staff to search for possible time slots when M
specified staff members are free by selecting a group (that has already
been added in the system).
3.13 The system should allow staff to arrange meetings by selecting a group M
(that has already been added in the system).
3.14 The system should allow staff to arrange meetings by specifying a M
group of staff members manually. (When there is no need to add a
group to the system)
3.15 The system should send an automatic email message to the other M
parties, if a meeting is deleted by a staff.
4 Student Requirements

4.1 The system should allow student to search for possible times when a D
specified staff member is free.
4.2 The system should allow student to add a single appointment with a D
member of staff.
4.3 The system should allow student to arrange a meeting of a group of D
students with a member of staff.
5 Security

5.1 The system should use a password mechanism to grant access to M
System Administrator.
5.2 The system should use a password mechanism (user name and M
password) to grant access to Staff.
5.3 The system should use a password mechanism (user name and D
password) to grant access to students.
6 Concurrency

6.1 The system should allow more than one (many) student to view the D
schedule of a specified staff member at the same time.
6.2 The system should allow more than one student (many) to search for M
available time slots for a specified staff member at the same time.
6.3 The system should allow more than one (many) staff to view the M
schedule of the specified staff member at same time.
6.4 The system should allow more than one (many) staff to search for M
available time slots for specified staff member/members at the same
time.
3.4.2 Non Functional Requirements:
1 Maintainability
18
Req. ID Description
1.1 The system should be designed in a way that it is easy to test.
1.2 The system should be designed in such a way that it is easy to modify.
1.3 All the code should be clearly commented.
2 Portability
Req. ID Description
2.1 The system should be easy to install.
3 Usability
Req. ID Description
3.1 The site should be designed in such a way that it is easily navigable
4 Efficiency
Req. ID Description
4.1 The system should take no longer than 45 seconds (max limit) to log a
user in.
4.2 Each page should take no longer than 45 seconds (max limit) to load.
3.5 System Testing and Evaluation:

The basic definition of software testing is “a process that is concerned with the selection of
inputs for a system with the intention of causing failures in the system, and thereby revealing
the presence of faults” [www.14]. However, this definition is not adequate for the purpose of
this project because it is only concerned with the functionality of the application. Also, for
web applications we also need to take into consideration issues such as concurrency and
efficiency. Therefore, for this project the process of testing can be split into two major parts:
• The first part of this process will be concerned with the functionality of the
•
application.
The second part of this process will be concerned with aspects such as concurrency
and efficiency and can be named as performance testing.
Overall, a combination of functional and structural based testing will be used to test the
functionality of the final system. In specification based testing methods, system as a whole is
treated as a “black box” and the general aim of such methods is to define partitions and
boundaries systematically by relying on the “reasonable implementation” assumption.
Usually, for functional based testing methods some sort of formal specification is written.
However, for the purpose of this project no formal specification will be provided, which
basically means that some test cases might not identified and the question that needs to be
asked is “whether this is justified”. The answer would be yes because time is of vital
importance as far as this project is concerned and writing formal specification will mean
spending less time on actually building the system.
For EDS, Category Partition Method, which is a functional based testing method, will be used
to construct a set of test cases. This method was described by Ostrand & Balcher and consists
of the following steps:
• First of all identify functional units and then for each functional unit identify
parameters and environment conditions that are relevant.
19
• Partition the category into choices: Identification of different cases that can occur
•
within each parameter and environment category.
Determine constraints among choices: Identify the effects of choices on each other
•
and the restrictions that could be applied on them.
Write and process test specification: The information identified for each functional
unit is written in a test specification language and is then processed by a generator to
•
produce a set of test frames.
Evaluate generated output: The generated output is then checked for omission of any
obvious cases or the existence of impossible combinations. If the test specification
•
needs any changing then “write and process test specification” again.
Transform into test scripts: This step involves converting the final test frames into test
cases which are then organised into test scripts.
An alternative approach to Category Partition Method is Cause Effect Graphing Method,

which is also a specification based testing method. This method is based on the idea that the
system can be thought of as “defining a set of partial functions from its inputs to its output.”
First of all this method identifies causes and effects. A cause “is any property or condition of
the input that can either be true or false” and similarly an effect “is any property of the output
that can either be true or false.” Then a graph is developed, in which nodes represent causes
and effects, and the edges represent the connections between them. The edges are annotated
to show how these individual connections need to be combined. Finally, the graph is
converted into a decision table, which is a compact way of representing a set of boolean
functions.
Although Cause Effect Graphing like Category Partition Method provides a very systematic
and pretty thorough way of checking the end functionality required by the user. However, for
EDS it is not a very suitable option due to time constraints. The process of actually drawing
the graphs is a very time consuming process and furthermore the size of the decision table
more often than not is enormous.
Also, in conjunction with test cases from “Category Partition Method”, a small set of test
cases will also be generated from using the underlying knowledge of the code. The aim of
such test cases would be to check decision points in the codes such as if and while statements
etc instead of testing the entire code.
The performance of any web application is a dependant upon a number of external factors,
which cannot be influenced by the developer of the application such as speed of the client’s
connection etc. However, in order to evaluate the performance of EDS in terms of efficiency
and concurrency, OpenSTA (Open System Testing Architecture) will be used. It is an open
source software tool that generates realistic heavy loads simulating the activity of multiple
virtual users. Furthermore, it “graphs virtual user response times and resource utilisation
information from all web, application and database servers as well as operating platforms
under test, so that performance measurements can be gathered” [www.19]
The evaluation of EDS will be carried out by analysing the test results against the functional
and non functional requirements. In addition to this, there is a need to assess personal
performance, which can be analysed in terms of planning and technical ability.

Like in any web based application, the aims and objectives of this project include security,
efficiency and robustness. Furthermore, if EDS is to be deployed by the DCS, it needs to be a
practical solution that is compatible with existing technologies within the department.
20
The testing process for EDS can be split into two major parts. The first part is concerned with
testing the functionality of the system and the second part is concerned with non functional
aspects such as concurrency and efficiency. The functionality of the application will be tested
by using both functional and structural based testing methods. However, no formal
specification will be written for functional based testing method due to time constraints. The
evaluation of this project will be carried out by testing the application against functional and
non functional requirements as well as analysing personal performance.
21
Chapter 4 Design
This chapter describes the initial high level design of the system based on the concepts
examined in the Technology and Design Review. It provides an overview of both the web and
the database design and also outlines the technologies that will be used in their
implementation. The use of connection pooling and Nielsen’s Usability Heuristic for EDS is
also explained. Finally, the chapter concludes by providing a brief account of the prototype
developed.
4.1 Web tier – Design:

The design of the web tier of EDS is based on the MVC design pattern within a three tier
architecture in conjunction with UML design methodology. Thus, a high level structure of the
web tier will be as follows:
• Model: In EDS, the model component will consist of two layers i.e. the data access
and the business layer. The sole responsibility of the data access layer is to interact
with the data tier, whereas the business layer provides the business logic required by
the view and the controller.
• View: The view will be implemented by using Java Server Pages. In addition, java
scripts will be used for input validation.
• Controller: Java Servlet technology will be used for developing the controller.
Controller’s responsibilities include initialising the application, user authentication
and authorisation and deciding, which presentation JSP to display next.
Model
Business extends Data Access
layer layer
data instantiate data instantiate
forward user
Controller View
Figure 4.1: MVC design pattern within a

three tier architecture of EDS
The screen flow and the structure of the model within the web tier of the application will be
dictated by UML use case, activity and sequence diagrams.
4.1.1 Design Methodology:
A design methodology is a “structured approach that uses procedures, techniques, tools and
documentation aids to support and facilitate the process of design” [3]. For EDS, UML is the
chosen design methodology that will be used for analysing the project requirements. It is an
object orientated modelling language that primarily consists of diagramming techniques to
22
represent the concepts required for modelling a system from analysis through implementation
[17].
An alternative design methodology that was considered for this project was the Discovery
Method. “It provides a completely guided approach to modern object-orientated and
component-based software development. The method covers the part of the software lifecycle
ranging from initial requirements elicitation, through task, object and sub system
identification, to detailed coding specifications” [www.23].
It was felt that it would not be wise to use the Discovery Method due to the lack of
information resources available on the use of this method.
UML Use Case Diagrams:
UML use cases provide textual descriptions of the functionality of the system from the user’s
point of view. From the requirements outlined by the client, UML use case diagrams were
drawn to identify the required functional units as can be seen in [12.1 Appendix: Use Case
Diagrams].
UML Activity Diagrams:
An activity diagram is a variation of a state chart that focuses on a sequential flow of activity
within an object. In an activity diagram, states are activities, each of which represents the
execution of an operation. The transition out of a state is usually triggered by the completion
of the respective operation. The UML use case diagrams were used to create the UML
activity diagrams for each of the functional units of EDS, examples of which are shown in
Figure 4.2 and Figure 4.3:
Click Relevant Enter User Display error

[input error(s)]
Link from Menu Details dialog box and
input form again
[valid input]
Generate username
and password
Add Staff/ Student [database errors] Display error

to the database dialog box
[no errors]
Display
confirmation
Figure 4.2: Activity Diagram for Add/Staff Student
23
Click Relevant Select date and Group/Staff
Link from Menu to be searched for
Get available time slots from Add appointment to [database errors] Display error
database for the relevant date the database dialog box
[no errors]
Display
confirmation
Figure 4.3: Activity Diagram for searching staff schedule
UML Sequence Diagrams:
A sequence diagram shows an interaction between objects arranged in a time sequence. A

sequence diagram aims to represent the detailed object interaction that occurs for a single use
case; therefore these diagrams can be seen as an expansion of use cases to the lowest possible
level of detail. Example of sequence diagrams drawn for EDS can be seen in Figure 4.4 and
4.5.
: User : Controller Servlet

doGet
doPost
: EventHandler
handleEvent
getRequestDispatcher
forward : Login.jsp
page displayed
submit
doPost
<<create>>
: LoginHandler
validateUser
[if invalidUser] forward

: Relevant JSP
[else validUser] forward
24
Figure 4.4: Sequence diagram for user login
: User : Controller Servlet

doGet doPost
: EventHandler
handleEvent
forward
: AddStaff / Student.jsp
page displayed
submit
doPost
<<create>>
: EventHandler
handleEvent
forward
<<create>> : StaffBean/
StudentBean
addStaff/Student
message message
Figure 4.5: Sequence Diagram for Add Staff/Student
4.2 Data Tier – Design:
The EDS database design consists of the use of conceptual, logical and physical phases in
conjunction with top-down approach, as described in the Technology and Design Review. An
overview of each stage of the database design for EDS is given below.
Conceptual Database Design:
Conceptual database design involves constructing a conceptual data model from the
requirements specification by identifying the relevant entity types along with their associated
attributes and relationships. As top-down approach was used, high-level entities and their
relationships were identified first, which underwent top-down refinement successively to
produce a final data model that contained lower-level entities along with their associated
attributes and relationships as illustrated in Figure 4.6.
25
Group GroupAndStaff
Contains
PK Name PK1 Name of Group
PK2 Username
SystemAdministrator
PK Username
Belongs To
Schedule
Staff
PK Username PK ScheduleId
Has FK Username
Appointment
Books
PK AppointmentId
FK ScheduleId
Student
FK Requestor
PK Username Username
Books
Figure 4.6: Conceptual Database Design
Logical Database Design:
Logical database design involves the correctness of conceptual data model by using the
process of normalisation. Normalisation is a formal technique for analysing relations based on
primary keys and functional dependencies. This process involves a series of steps where each
step corresponds to a specific normal form that has known properties. For a relational data
model, it is critical to apply the first normal form, which consists of putting all the data into
tables where each element is atomic. While examining the conceptual data model, no cases
were found that violated the first normal form. Although, the use of subsequent normal forms
is optional but in order to avoid any update anomalies, the process of normalisation was
applied until the third normal form to the conceptual model. However, no changes were
required for the conceptual data model as it already satisfied the relevant constraints. It is
believed that this is the result of prior knowledge of database design from previous projects
and modules.
Physical Database Design:
This is the final stage of the database design and is concerned with issues regarding the
physical implementation of the logical data model such as transformation of the logical data
model for the target DBMS, access methods and data security. The first step involves the
identification of the target DBMS. The DBMS selected for EDS is a relational one i.e.
MySQL, therefore the logical data model developed can be mapped directly on to it. The data
stored in the database will be protected by a password mechanism of the host DBMS.
Furthermore, indexes will be used to speed up access to the contents of the tables. One of the
key tasks in this stage was the identification of columns that will be used for indexing.
The decision of which columns will be used for indexing was based on columns that will be
commonly used for looking up values. For instance, for the table staff, the columns staffId
26
and surname will be used as indexes, as most of the queries will use these columns for
selecting records.
4.3 Connection Pooling:

Web applications have large user communities due to which, the probability of a request
coming in before the previous request is finished is greatly increased. Therefore, it is very
unrealistic to plan applications that can entertain only one database request at a time. One
approach would be to create a database connection for every request. However, creating a
database connection is a very expensive operation and more often than not 80% of time taken
to process a Http request requiring interaction with the database is accounted by the creation
of a database connection [7]. For a high user load this approach leads to the exhaustion of
resources, resulting in system’s crash.
At the moment, connection pooling is deemed as the best way of handling database
connections. This involves initialising a pool of connections, then using one of the
connections from the pool for interacting with the database. Once the connection is used, it is
returned back in the pool. This approach reflects a balance against performance and efficiency
4.4 Interface Design and Compliancy of Nielsen’s Usability Heuristic:
A key part of the interface design will be based on UML use case diagrams and Nielsen’s
Usability Heuristics. Use case diagrams will play an important role in architecting the site
design (i.e. screen flow) as well as deciding how and which functional units can be grouped
together into a cluster that can be represented by a single interface screen e.g. functional units
view schedule, add schedule and remove schedule can be grouped together and represented
by a single screen.
Usability plays a pivotal role in the success of any software and therefore will be an important
consideration while designing the interface. As one of the most accepted measures of
usability comes in the form of Nielsen’s Usability Heuristics, it was decided to employ these
heuristics. Furthermore, interface of EDS will be made compliant to these heuristics as
explained below.
Heuristic 1- Visibility of system status

The user will be kept informed for any change in state of the system such as selection of dates
etc. Detailed messages will be provided in case of errors.
Heuristic 2- Match between the system and the real world

Information will be represented in a natural and a logical order which is familiar to the user
and matches the language that has been used by the client throughout the requirements
gathering process.
Heuristic 3- User control and freedom

If the user performs a function, which is not intended by him\her, the system will allow the
user to get back to the previous state i.e. the system will support undo and redo.
Heuristic 4- Consistency and Standards

Header, footer and menu will be made in separate files and will then be called in all the JSP
pages. This will help in keeping the Look-and-feel consistent. Further to this, it will also
make learning faster for the user and improve the speed with which he\she can navigate
throughout the system.
Heuristic 5- Error Prevention

Error prevention will be implemented as much as possible by presenting the user with only
valid choices e.g. when a member of staff does a search for available times to set a meeting
27
with a group of staff, only those times will be offered at which staff members are free, thus
avoiding any exception or errors.
Heuristic 6- Recognition rather than recall

Interface will be made in such a way as to minimise the user’s memory load by making
actions and options visible and easily retrievable e.g. In EDS, a common feature is the
selection of date that will be implemented by clicking the respective date on the calendar
object as compared to a text field or a drop down menu.
Heuristic 7- Flexibility and efficiency of use

Direct links to system sub sections will be provided on every page.
Heuristic 8- Aesthetic and minimalist design

The interface will not contain any irrelevant information, as greater the amount of information
presented to the user, the greater will be the effort required by the user to filter it.
Heuristic 9- Help users recognise, diagnose and recover from errors

Error messages will be expressed in a plain language explaining precisely what the problem is
and constructively suggesting a solution.
4.5 Prototype:
The planning and design of software projects requires a great deal of communication between
the parties involved [www.24]. Thus, to be sure that all the details are being properly
communicated a prototype was developed during the course of this project by using the
design principles explained in this chapter. It offered different views for all the users as well
as navigation within the system. However, the motivation for developing this prototype was
to identify new requirements as well as finding defects in the existing ones. Such prototypes
are known as Requirements prototype.
Besides the achievement of its main concern, the development process of the prototype itself
has proven to be very useful as it provided a great deal of familiarity with technologies that
were to be used in the implementation stage. Further to this, it took the guesswork out of the
design by allowing the parties (mostly client) involved to identify potential design problems
and come up with a solution satisfactory to the client. One such example was the change in
the way that the date and time is selected by the staff for various tasks.
The developed prototype was intended to be a Requirements prototype and it should have
been discarded before the implementation. However, due to the amount of time spent in its
development and the satisfaction shown by the client, it was decided to extend this prototype
in to the final product. As such, the developed prototype would be called an Evolutionary
prototype as compared to a Requirements one.

This chapter details the formalised design and the overall structure of the system. The web
tier of EDS is driven by Model View Controller pattern and is designed by using the UML
design methodology. The database design is composed of conceptual, logical and physical
phases where each phase involves in either developing or modifying the data model
developed during the previous stage. Nielsen’s Usability Heuristics and the ways in which
EDS will adhere to this have also been outlined. Through the development of EDS prototype,
it was possible to gain clarification of existing and the identification of new functional
requirements. Furthermore, the prototype developed was then extended into the final product.
28
Chapter 5 Implementation
The chapter begins by giving a brief overview of the web tier by illustrating the file structure
and how it supports scalability and maintainability. It then moves on to provide a detailed
explanation of the principles and techniques employed in the implementation of each
component of MVC design pattern. Next, database implementation along with statistics
concerning the delivered system are outlined. Finally, the chapter concludes by providing a
brief on the use of apache ant build tool in the implementation of EDS.
5.1 Web Tier - Overview:

Establishing an effective and maintainable file structure for EDS was an activity that was
finalised over several weeks of implementation and can be seen in [12.2 Appendix: EDS File
Structure]. All files are structured in terms of the role they play in the MVC design pattern.
Moreover, for each component of MVC the files are further split according to the type of
user. This approach supports:
• scalability as it allows both the view and model to be extended for a particular user
without having an effect on any of these components for the other users. For instance,
in future if there is a need to include further functionality for the students, then the
relevant JSP(s) and related Java class(es) will be added in the students folder of the
•
jsp and classes directory.
maintainability as files for both model and view are separated for each type of user
demonstrating the ease with which the system can be maintained.
Furthermore, Figure 5.1 demonstrates how well the file structure fits with the final
architecture of EDS.
$home:- application root directory

Model:- located in the $home/WEB-INF/classes directory
Controller:-located in $home/WEB-INF/classes
View:-located in $home/jsp
Controller Model
ControllerServlet.java controller
View
systemAdministrator staff
staff students
students systemAdministrator
login.jsp
Figure 5.1: Architecture and file structure of EDS
5.1.1 Configuration File (web.xml):
29
Before work could begin on the actual functionality, the first step was to build a configuration
file called “web.xml” that is located in the WEB-INF folder of the application directory [12.3
Appendix: web.xml]. This file identifies and establishes the values for the global parameters
that are to be used within the EDS. The global parameters defined in this file are:
• base – specifies the URL of the application i.e.
•
http://localhost:8080/eds/servlet/ControllerServlet
•
sqlDriver – specifies the name of the sqlDriver that is to be used by the application.
•
dbUrl – specifies the location of the database.
•
dbUserName – specifies the username required to connect to the database.
•
dbPassword – specifies the password required to connect to the database.
•
mailHost – specifies the name of the mail host.
•
images – specifies the location of images used by this application.
javascripts – specifies the location of java scripts used by the JSPs.
5.2 Web Tier – Controller Implementation:

The controller was implemented by using the Java Servlet technology. Its responsibilities
include:
•
•
Initialising the application.
•
User authentication and authorisation.
Screen flow i.e. deciding which view to display next.
5.2.1 Initialising the application:
On initialisation, the method init specified in the ControllerServlet is invoked. The controller
reads the values of the global parameters from the configuration file and stores them in the
ServletContext, so that this information could be made readily available to the entire
application as illustrated in the Figure 5.2.
Figure 5.2: Code listing of the method init

defined in the ControllerServlet
5.2.2 User authentication and authorisation:
On receiving a user name and password submitted by the user, the controller instantiates a
LoginBean that extends the LoginDataHandler. The controller then invokes the method
authenticateUser of the LoginBean, which in turn calls the authenticateUser method of the
super class i.e. LoginDataHandler. If the user is valid, then this method returns a UserDetails
object containing the user details such as name, type, email address etc otherwise it returns a
null object.
30
5.2.3 Screen flow:
Controller defines the behaviour of the application by deciding which JSP to display next.
The process involves obtaining the value of the action parameter from the Http GET or POST
request and retrieving the user type stored in the session object of the user. As such, the URLs
used to move between different pages in EDS are of the form:
……./servlet/ControllerServlet?action=X
The values obtained are passed as parameters for instantiating the EventHandler class and
then invoking the method getEvent. This method returns a URL by calling the relevant
method depending on the type of the user as illustrated in Figure 5.3.
Figure 5.3: Code listing of the method getEvent

in the EventHandler class
For instance, if the user type is staff, then the staff method will be invoked. The method staff
will return the URL of the relevant page depending on the value of the action variable as
shown in Figure 5.4.
Figure 5.4: Code listing of the method staff

in the EventHandler class
The implementation of the controller illustrates the ease with which it allows interface pages
to be added or removed. Any addition of a new interface page simply involves the addition of
a single else if statement in the relevant method depending on the type of the user.
5.3 Web Tier – Model Implementation:

For EDS, the model component is responsible for interacting with the data tier and supplying
the business logic to both the view and the controller, whilst hiding these details from them.
Thus, the approach used in implementation resulted in splitting of model classes into two
layers:
31
Data Access layer – abstract data handler classes that interact with the data tier
Business layer – Java Beans extend the abstract data handler classes and act as an
intermediate between the other components of MVC and abstract data access classes.
5.3.1 Data Access Layer – DataHandler Classes:
These are abstract Java classes, which contain processes to govern access and modification of
the backend data source. As such, all these classes extend the DataAccessParameters class
that contains variables specifying the location, user name and password of the data source.
This information is read by the controller on initialisation from the configuration file and then
stored in the ServletContext object as shown in Figure 5.2.
Since, all data handler classes extend the DataAccessParameters class; a connection with the
database is established as shown in Figure 5.5.
Figure 5.5: Establishing a connection with the database.
The methods getDbUrl(), getDbUserName() and getDbPassword() are inherited from the
DataAccessParameters and these methods return the values for the location of the database,
user name and password respectively as specified in the configuration file.
5.3.2 Business Layer – Java Beans:
This layer consists of beans, which encapsulate the business logic required by JSPs, resulting
in removal of bulk of the script code. For instance, Schedule.jsp requires the user to
check/uncheck check boxes to specify the time slots he/she wants to add or remove from
his/her schedule. The values of the check boxes are strings, therefore these need to be
converted into the right format (i.e. Date and Time objects) before any interaction with the
data tier takes place. Furthermore, Beans do not interact with the data tier directly. In fact they
do so by extending the relevant abstract data handler class. If user actions require the system
to add time slots to his/her schedule, then Schedule.jsp will first of all map the values of the
form by using the set property tag and then call the method addSchedule of the
ScheduleBean, as can be seen in Figure 5.6.
Figure 5.6: Code listing of Schedule.jsp
As beans don’t interact with the data tier, the addSchedule method in ScheduleBean invokes
the addSchedule method of the super class i.e. ScheduleDataHandler as detailed in Figure 5.7.
Figure 5.7: Code listing of addSchedule method of ScheduleBean
32
In the addSchedule method of the super class, after establishing the database connection, the
connection’s auto commit mode is set to false; meaning that all the SQL statements are
grouped into transactions that are terminated by a call to the method commit. In case, an error
occurs, a call to the method rollback undoes all the changes in the current transaction as
illustrated in the Figure 5.8.
Figure 5.8: Code listing of the addSchedule method in ScheduleDataHandler
5.4 Connection Pooling:

To implement connection pooling, the initial approach involved creating a class called
ConnectionPooling. This class maintained a Hashtable object that uses Connection objects as
keys and a Boolean object as stored values. This Boolean value indicates whether the
connection is free or not. A program calls the getConnection() method of this class to be
assigned a connection. Once the connection is used, returnConnection() method is called that
returns the connection back to the pool as is illustrated in the Figure 5.9.
33
Figure 5.9 Code listing of ConnectionPooling class
However, from Com 3180 Java Ecommerce it was learnt that drivers that use JDBC 2.0
package implement connection pooling; thus it was felt that there is no point in re-inventing
the wheel and therefore a type IV driver was used instead.
5.5 Web Tier – View Implementation:

In EDS, the view component is responsible for accessing data from the model and then
indicating how the data should be presented. This component was mainly implemented by
JSP technology and Java Script to a small extent for changing the presentation JSP and input
validation. Although, the use of Java Script could have been avoided by performing these
tasks with JSP itself but this involves sending the request to the server and then waiting for its
response. From the server’s perspective, this means an increase in workload and from the
user’s point of view it means a slower response.
The following section gives a brief overview of the important aspects of the view for staff and
system administrator. The student view is not explained in this section as it is similar to staff
and due to the constraints relating to the size of this report.
5.5.1 View – Staff:
Managing schedule
Once a member of staff logs in he/she is directed to Schedule.jsp, which displays their
schedule for the current week. Furthermore, the user can view the schedule for the desired
week by simply by selecting the relevant week from the calendar located in the left hand
corner.
34
Figure 5.10: Screen shot of upper part of the Schedule.jsp
The time slots coloured in red show that these times are blocked for every one and therefore
no one can book an appointment with the user during these times. On the other hand, time
slots coloured in green mean that these times are available for students to book meetings with
the user. Also, other members of staff are allowed to book appointments with the user during
those times which are not blocked for every one or are not specified to be used by students.
Staff can add schedule simply by checking the relevant time slots, highlighting the available
option i.e. (Bookable by students or Blocked for everyone) and selecting the number of weeks
that they want these time slots to be added for. The activity remove schedule is similar to add
schedule but it does not require the user to highlight the Bookable field.
Figure 5.11: Screen shot of lower part of the Schedule.jsp
View Appointments
35
On selection of the view appointments field from the menu, the user is directed to the
“ViewAppointments.jsp” that displays all the appointments booked with the user for the
current week by both staff and student. The displayed week can again be changed by simply
clicking on any date of the desired week. Furthermore, if the user wishes to remove any
appointment, he/she can do so by checking the relevant remove checkbox(s) and then clicking
on “Remove Selected Appointments” button.
Figure 5.12: Screen shot of the ViewAppointments.jsp
Search Staff Schedule
The search option in EDS allows member of staff to search the schedule of a single or
multiple staff by selecting the concerned staff member(s), groups or both.
36
Figure 5.13: Screen shot of the upper part of Search.jsp
The search result returns time slots at which all the selected staffs are available. The searcher
then simply checks the relevant time slots and clicks on the “Add Appointments” button. This
action will add appointments into all the selected staffs’ schedule.
A key thing to note is that all the non available time slots have been disabled, so therefore the
user is not allowed to enter any invalid input.
Figure 5.14: Screen shot of the lower part of Search.jsp
5.5.2 View – System Administrator:
Manage students
The administrator can view all the students by selecting the “View Students” link from the
menu. Students are displayed alphabetically according to their surnames.
37
Figure 5.15: Screen shot of ViewStudents.jsp
Administrator can update or remove an individual student by simply clicking on relevant link
next to their name. On selecting the update link, the system takes the administrator to the
update student page where all the student details are populated by connecting to database.
Furthermore, any student detail can be changed apart from their username.
Figure 5.16: Screen shot of UpdateStudents.jsp
Import User Details:
In order to import user details, the administrator needs to specify the name of the driver,
location, username and password required to connect to an external SQL database. Then
he/she can specify whether they want to import student or staff details or both. In case of an
38
invalid driver name or if the connection with the database cannot be established the system
will provide the administrator with an informative message explaining the root cause of the
problem.
Figure 5.17: Screen shot of ImportData.jsp
Reset System:
At the end of the semester, administrator can reset the system by specifying, which data needs
to be removed from the application. Furthermore, EDS also allows the administrator to update
the level field (i.e. year of study) of student details.
Figure 5.18 Screen shot of ResetSystem.jsp
5.6 Data Tier – Implementation:

The first task of implementation was to create the database tables. Initially, the data model
developed during the design stage was implemented in Microsoft Access for the purpose of
prototyping. However, this database was later replaced by a MySQL one. Since then, no
design or implementation changes were made to the data tier, during the course of
39
implementation. An outline of the database tables is given in [12.4 Appendix: EDS Database
Tables].
5.7 System Statistics:

Table 5.1 shows the number of files for each programming technology used in the
implementation of EDS.
Technology Number of files

JSP 26
Java classes 34
Java Servlet 1
Table 5.1 EDS programming statistics

5.8 Apache Ant:
Ant is a Java based build tool that is developed by the Apache Software Foundation. For
EDS, this tool is used to manage compilation and creation of the deployment hierarchy of
Java source files. Ant operates under the control of a build file called “build.xml” [12.5
Appendix: build.xml]. The file is located in the application’s home directory and defines the
processing steps that are to be performed by the tool.
Before any implementation could take place, the first step was to set up a configuration file
called “web.xml”. The controller then reads information from this file in order to initialise the
application. The controller’s other responsibilities include user authentication and
authorisation and deciding which view to display next. The approach taken towards
implementation resulted in splitting the model into two layers, namely data access layer and
business layer. The chapter also provides screen shots and a brief explanation of major
aspects of the view for staff and the system administrator. Finally, the chapter concludes by
detailing the implementation of data tier and the use of Apache Ant build tool.
40
Chapter 6 Testing
As explained in Requirements and Analysis stage, the testing process of EDS was split into
two major portions where:
• the first part of this process involves testing the compliance of the application against
•
the functional requirements specified by the client.
the second part of the testing process is concerned with aspects such as concurrency
and efficiency.
6.1 Application Functionality:
A major portion of the application functionality was tested whilst the system was being built.
This involved the use of structural or white box testing on completion of each functional unit,
by using the underlying knowledge of the code. The aim of this approach was to test
boundary and decision conditions within the code. Furthermore, no formal documentation
was produced for this part of the testing process.
On completion of EDS, the Category Partition (black box testing) method, was applied to
develop a set of test cases as can be seen in Table 6.1. Usually, for specification based testing
methods some sort of formal specification is written. However, for EDS no formal
specification was provided because writing a formal specification would have meant spending
less time on building the system.
For each functional unit categories, partitions and constraints were identified and then written
in a test specification language. For instance, test specification language for a user logging in
can be seen in Figure 6.1.
Figure 6.1: Code listing of LoggingIn.tsl
The test specification language was then processed by a tool called catpart to generate a set of
test frames, example of which is given in Figure 6.2.
41
Figure 6.2: LoggingIn.frm generated by catpart
The catpart tool simply outputs the test frames. Each test frame contains set of values that
need to appear in test cases. However, the generated values are not in a format that matches
the system’s requirements and therefore need to be reformatted to produce actual sets of input
values that are to be included in the test case. Examples of test cases produced from the
LoggingIn.frm are given in Table 6.1.
Test Inputs Expected Output Actual Output

Case No
1 username = null Error dialog Error dialog
password = admin displayed. displayed.
2 username = admin Error dialog Error dialog
password = null displayed. displayed.
3 username = administrator Error dialog Error dialog
(invalid) displayed. displayed.
password = administrator
(invalid)
4 username = admin (valid) Error dialog Error dialog
password = administrator displayed. displayed.
(invalid)
5 username = administrator Error dialog Error dialog
(invalid) displayed. displayed.
password = admin (valid)
6 username = admin (valid) User forwarded to User forwarded to
password = admin (valid) home page. home page.
Table 6.1: Test cases for LoggingIn.frm
6.2 Performance Testing:

This part of the testing process involved the use of a load testing application to simulate
server usage at different loads. The aim was to highlight potential bottlenecks and to ensure
that EDS will have a good response time during peak usage. Here, “response time” means
“the time it takes between initial request and complete download of response i.e. rendering of
an entire web page”.
OpenSTA is the selected tool that will be used for performance testing. The key reason for
using this tool is that it was the only open source software found. A variety of test cases were
carried out to cover the following two scenarios:
42
•
•
Requests that do not require database connection
Requests for which database connection is required
All tests were carried out by using the following specification machine, with the web site and
load testing tool present on the same machine:
Processor: 2 GHz
Memory: 256 MB
Operating System: Windows XP
Test Case: 1
Description of Tasks: Database Connection
Staff enters URL of application – login page displayed No
Staff requests login – login successful Yes
Staff forwarded to Schedule.jsp – schedule displayed. Yes
Number of users Min Request Time Max Request Average Request
(ms) (ms) Time (ms) Time (ms)
10 10.26 10.61 10.41
50 11.81 13.48 12.53
100 11.79 16.19 14.09
1000 50.33 65.80 63.23
Table 6.2: Performance Testing Test Case 1
Test Case: 2
Description of Tasks: Database Connection
Staff selects search from menu No
Staff selects a group and presses search – search results displayed. Yes
10 12.24 13.35 12.38
50 15.18 17.48 16.79
100 19.43 23.82 22.05
1000 70.17 90.23 88.76
Test Case: 3
Description of Tasks: Database Ctonnection
Student enters URL of application – login page displayed No
Student requests login – login successful Yes
Student forwarded to Appointments.jsp – appointments displayed. Yes
Student selects staff and presses search – search results displayed. Yes
10 41.86 44.17 43.23
50 42.45 46.58 45.42
100 47.83 50.60 48.25
1000 144.56 146.73 146.49
43
6.3 Results and Discussions:
Overall, all the testing conducted to test the functionality of the application led to a single
conclusion that EDS is compliant with all the functional requirements detailed in the
Requirements and Analysis stage. Whilst, the use of “catpart” tool does provide an automated
way of processing categories and partitions but it allows very little flexibility in the syntax.
For instance if a blank line is not left at the end of the file that is to be processed then the
compiler wont compile the file. However, once a person gets used to the writing the test
specification language the use of this tool is highly recommended for Category Partition
Method.
Results obtained from performance testing highlight the efficiency and the scalability of the
approaches used in the implementation of EDS. It was also felt that EDS would perform
substantially better as compared to its performance during the testing process mainly because
of two reasons:
• simulating X concurrent users with a load testing software is not representative of the
web surfing patterns of X people. This is because virtual users in the load test only
•
wait milliseconds before hitting the server again.
the machine on which EDS was hosted during testing cannot achieve the same
performance level as a high-end web server because the server would have a faster
processor and a lot more memory. Furthermore, during performance testing the load
testing application was also being run on the same machine as EDS, which means an
increased burden on the machine resources as compared to normal circumstances.
44
Chapter 7 Case Study: A Web Application Interacting with LDAP
7.1 Introduction:
Throughout the implementation, emphasis was placed on creating a system that could feasibly
be deployed within the DCS. To this end, it was made sure that the selected technologies for
developing EDS are compatible with the ones that are being used in the department.
Also, EDS has a large user community. Adding all the users individually is not practical and
therefore EDS allows the administrator to populate user details from an external SQL
database provided the administrator supplies a valid database URL, user name and password
to connect to that source. The administrator also needs to provide the name of a valid driver.
If EDS is used in the DCS, then user information will most likely be imported from CICS
data storage. Last year, by contacting the CICS it was found that they were using an
ORACLE database to store staff and student details. For EDS, it was not possible to check
whether it will import user information from an ORACLE database because it is a
commercial software. However, recently it was revealed from a meeting with Mr George
Wilson that CICS have changed their data storage from an ORACLE database to Light
Directory Access Protocol (LDAP). Furthermore, this meeting also concluded that
maintaining staff and student details separately for EDS is not practical mainly because:
•
•
it increases the work load of the technical staff.
results in duplication of data, which is a very serious issue for the DCS.
Although, EDS can be further improved in various fields such as security and interface design
etc but major scope in the future development of EDS remains in integrating it in the
departmental network. To achieve this, EDS will need to interact with two data tiers:
•
•
EDS database – that will hold data for schedules, appointments and groups etc.
CICS LDAP Server – for user authentication and authorisation. Also, to obtain user
information such as names and email addresses etc.
Due to the fact that the above raised issues were identified at a very late stage in the project,
therefore it was not possible to modify EDS as to satisfy these concerns. However, during this
small space of time a case study was developed that involved developing a web application
that queries the LDAP Server. The aim to provide some sort of foundation to anyone who
chooses to extend EDS according to the fore mentioned proposal.
7.2 LDAP Server:
LDAP Server specialises in Directory Services and is a simplified version of OSI DAP
protocol. It runs over standard TCP/IP protocol due to which it is becoming increasingly
popular among institutions who want to standardise their directory services across the entire
organisation [18].
LDAP servers are similar to databases but they provide an optimised service for read access.
Data stored in LDAP reflects the hierarchical structure of an organisation. By defining,
user/organisation/location objects, LDAP makes it easy for a Java programmer to store
objects into this type of data architecture.
7.2.1 LDAP Data:
45
Data in LDAP is organised in a tree called a “Directory Information Tree (DIT)”. Each leaf in
the DIT is called an entry. The first entry in the DIT is called a root entry.
An entry consists of a unique Distinguished Name (DN) and any number of attribute/value
pairs. DN can be considered as an equivalent of a primary key of a relational database. An
example DN is as follows:
uid=u1ua, ou=DepartmentOfComputerScience, o=UniversityOfSheffield
DN reads from right to left, where the leftmost part of a DN is called a Relative Distinguished
Name (RDN). It is made up of an attribute/value that is in the entry. In the above example,
RDN would be uid=u1ua.
Attributes in LDAP can have values that are either text or binary. Also, attributes can have
multiple values if permitted by the schema that defines the data to be stored.
7.3 LDAP Application:

It is a very small application in which the view consists of two JSPs, namely a login and a
welcome JSP. Furthermore, controller will be implemented by using the Java Servlet
technology and business logic is encapsulated by two beans that interact with LDAP server
for authenticating and obtaining user information respectively.
7.3.1 LDIF File:
Before work could begin on actual implementation, an LDAP entry is required which can be
loaded on to the LDAP server. An example LDIF (LDAP Data Interchange Format) file that
will be used in this application is given in [Appendix: 12.5 Example LDIF File].
7.3.2 Configuration File:
This file identifies and establishes the values for the global parameters that are to be used
within the EDS. The global parameters defined in this file are:
• base – specifies the URL of the application i.e.
•
http://localhost:8080/eds/servlet/ControllerServlet
•
serviceProvider – name of JNDI service provider
•
ldapHost – name of the machine hosting the LDAP server
•
ldapPort – port on which connection is available for the LDAP server (usually 389)
•
searchBase – search base for LDAP queries.
•
managerDN – manager’s DN (distinguished name)
managerPW – maanger’s password
7.3.3 Environment Configuration:
The first step is to set up configuration environment for LDAP and store it in the
ServletContext so it can be made available to all the application. On initialisation of the
ControllerServlet, getEnv(ServletConfig config) method which reads in the configuration
information from the web.xml file as can be seen in Figure 7.1.
46
Figure 7.1: Code listing of the first part of the method getEnv
Then, the entries consisting of named keys and values for JNDI are added in the Hashtable.
The first of them is the javax.naming.Context.INITIAL_CONTEXT_FACTORY that tells the
JNDI (Java Naming and Directory Interface), which service provider to use. Next step
involves specifying the protocol, host and port to which the connection is to be made as
illustrated in Figure 7.2. For LDAP, the this is of the form “ldap://host_name:port”.
Figure 7.2: Code listing of the second part of the method getEnv
Next, simple authentication is set up along with binding of name and password. In JNDI the
simple authentication means that the user will provide a text password.
Figure 7.3: Code listing of the third part of the method getEnv
Once, all the configuration information is placed in a Hashtable object, then it is stored in the
ServletContext as shown below in Figure 7.4:
Figure 7.4: Code listing of storing the Hashtable

object in the ServeltContext
7.3.4 LDAP Authentication:
When the user first enters the URL, he/she is forwarded to a traditional login form consisting
of a username and a password field. On receiving the submitted form, the controller retrieves
the Hashtable containing the configuration information and passes it to
LdapAuthenticationBean along with the username and password. In LdapAuthenticationBean,
the method ldapAuthenticate performs the authentication. The first task is to initiate the
DirContext object by using the configured Hashtable as follows:
DirContext ctx = new IntialDirContext(env);
Next, search the LDAP server for an entry that matches the LDAP search filter
“uid=username”.
Figure 7.5: Code listing for searching LDAP server

by building the LDAP search filter
47
If the search returns any results, get the user’s DN using the method getName of the
SearchResult class and store it in a StringBuffer. Furthermore, authentication requires full
DN, therefore searchBase also needs to be included in the StringBuffer.
Figure 7.6 Code listing of obtaining the full DN
Finally, the authentication credentials are changed from the manager’s DN and password to
the user’s DN and password and then an attempt is made to reconnect to the server. If no
exception is thrown during this process then authentication succeeds otherwise authentication
fails.
Figure 7.7: Code listing of changing the credentials and a reattempt to connect
7.3.5 How to Query LDAP:
Once, the user is authenticated, he/she is forwarded to the welcome jsp. This JSP retrieves the
relevant parameters and initialises the UserBean and calls the method getUser to obtain
surname and forename of the user.
This piece of code is very similar to the authentication code, therefore detailed explanation is
not provided. Again, the first step is to initialise the DirContext object and build the LDAP
filter “uid=username”. Next step involves specifying the attributes to be retrieved as follows:
String [ ] attrs = {“uid”, “surname”, “forename”};
LDAP server is then searched and returns the relevant result in the form of a
javax.naming.directory.Attributes object, which contains the specified attributes as can be
observed in Figure 7.8. A key thing to note is that the value of the attribute is returned in a
NamingEnumeration object. This is because an attribute in LDAP can have more then one
value.
48
Figure 7.8 Code listing of the method getUser
The method getUser returns a UserBean object containing the surname and forename of the
user, which are then displayed on the welcome page as follows:
Welcome <%=userBean.getForename()%><%=userBean.getSurname()%>
49
Chapter 8 Evaluation
This chapter provides an overall evaluation of the entire dissertation project in terms of the
final system developed and the level of planning.
8.1 System Evaluation:
The evaluation of the application developed can best be carried against the aims and
objectives detailed for functionality and design in the Requirements and Analysis stage.
8.1.1 Functionality:
Success can be measured on many different levels but for an implementation based project
the primary measure of success would usually be at the level on which the original functional
and non functional requirements were achieved. However, in the context of a dissertation
project there are a number of external factors that need to be taken in to account such as this
project being run in conjunction with a number of other modules. Producing a full project
report is more challenging than producing a technical document, as would be the case in a
commercial environment.
However, despite of all the constraints and challenges faced during the course of this project,
EDS in its current state satisfies all the functional requirements detailed in the Requirements
and Analysis stage.
8.1.2 Design:
One of the design objectives was the use of MVC design pattern within a three tier
architecture. The use of this approach is clearly evident from the Implementation Chapter.
Even though, the benefits of using a three tier architecture were clearly visible from the
implementation stage but at the same time the dependence of the model on the data tier was
also highlighted. As such, any change in the type of the data source has a dramatic effect on
the on the entire model.
In order to minimise this dependency, the traditional MVC design pattern was slightly
modified. The model in the modified version was split into two components, namely the data
access layer and the business layer as can be seen in Figure 7.1. In the modified version, the
data access layer consists of abstract classes, which are responsible for interacting with the
data source whereas the business layer consists of beans that extend the data access classes.
This layer is responsible for all the business logic required by both the view and the controller
besides the interaction with the data source.
50
Model
Controller Data Access Layer
{Abstract classes}
Extends
View Business Layer
Figure 8.1: Modified version of MVC design pattern

used in EDS
Using this approach in EDS did not resolve all the coupling issues between the model and the
data tier, but it had the benefit of keeping both the data access and business layer together in
the same location as before while reducing the amount of coupling between the two. It means
that if the data tier is changed in the future, only the data access layer will need to be
reworked on while the business layer will be virtually free of any change.
The use of Nielsen’s Usability Heuristics for designing the interface was also a part of the
design objectives. Whilst, these heuristics were adhered to best as possible but there still is the
need for evaluating the interface design for finding usability problems. This process is
formally termed as “Heuristic Evaluation” and it involves the use of a small set of evaluators
examining the interface and judging it’s compliance with the employed heuristics. For EDS,
the evaluation process employed the use of a single evaluator i.e. the author and this process
was carried out iteratively till no further usability problems could be found. If EDS was being
built in a commercial environment, this process would have been documented to provide a
formal record. However, no formal EDS evaluative documentation was produced, due to time
constraints.
In principle, heuristic evaluation can be performed by a single evaluator, but studies

conducted by Jacob Nielsen have shown that fairly poor results are achieved when relying on
single evaluators. Averaged over six of his projects single evaluators have found only 35% of
the usability problems in the interfaces [www.25]. Also, based on the results obtained from
their studies they developed a formula for predicting the number of usability problems in a
heuristic evaluation [www.25], which is as follows:
Problems Found (i) = N (1 – (1 – L) i )

where
i = indicates the number of usability problems found by aggregating reports from i
independent evaluators
N = the total number of usability problems in the interface
L = proportion of all usability problems found by a single evaluator.
Since different evaluators tend to find different problems, it would therefore, have been
possible to design a substantially better interface for EDS by aggregating the evaluations from
several evaluators. However, in the context of this project, there are a number of other factors
that come into play. Ultimately, it must be considered that this was a dissertation project,
which was being run in conjunction with several other modules and therefore carrying out a
51
formal heuristic evaluation would have meant spending less time on the build, which was not
practical as far as this dissertation was concerned.
8.2 Planning:
Planning was undertaken at every stage of the project. The approach adopted for planning
included a high level plan that was expanded during the implementation stage so indicating a
completion time for each section of the system.
The key issue with planning was that the plans produced were often too optimistic. For
instance, the project plan created before Christmas emphasized that work on implementation
will start in week 12 of autumn semester and the architecture of EDS would be finished in
Christmas Holidays week 4. Although, implementation did start in week 12 but not to the
extent as it was expected. Furthermore, the effort and time required to develop the underlying
architecture was seriously miscalculated and was a major flaw in the project plan. Initial plans
involved finishing the architecture by week 4 of Christmas holidays but in reality this activity
was at the heart of the implementation stage and the architecture was being worked upon till
the end.
The fundamental flaw in the approach taken towards planning was that the original plan was
not fine grained enough to be of real use in assessing the time required to build the system
especially in the case of building the underlying architecture of EDS. Moreover, if the initial
plan had provided a deeper analysis of the complexity and the size of each task, it would have
allowed better appreciation of the time involved in each stage of the build.
52
Chapter 9: Conclusions
Many valuable lessons were learnt during the course of this project on both technical and
human level. Perhaps the most important of them being related to the extent of planning
required for an implementation based project. The initial technology survey along with the
requirements analysis provided valuable background knowledge for the implementation stage.
Still setting up a working web application architecture where all the technologies interact with
each other is a sizeable task in itself that was seriously miscalculated during the course of this
project. Moreover, it was felt that if the initial plan had provided a deeper analysis of the steps
involved in each of the tasks, it would have allowed better appreciation of the time involved
in each stage of the build.
The evaluation of the model two architecture leads to the conclusion that it is very well suited
for this purpose as it allows separation of logics between the different components and
supports scalability. However at the same time the coupling between the model and the data
tier was also highlighted. Any change in the data tier dramatically affects the model
component. Therefore, in order to minimise this dependency in EDS the traditional MVC
design pattern was slightly modified as to split the model component in two layers namely the
business and data access layers. In the modified version, the sole responsibility of the data
access layer is to interact with the data tier, whereas the business layer not only acts as an
intermediate between the data access layer and other components of MVC design pattern but
it also provides the business logic required by the view and the controller.
Success can be measured on many different levels but for an implementation based project
the primary measure of success can be deemed as the system’s compliance with functionality
required by the client. In terms of functionality it is clear that EDS satisfies both its primary
and secondary aim by providing the facility to staff and students of the DCS in setting up
meetings with other members of the staff. Furthermore, a key thing to note is that throughout
the build emphasis was placed on developing a system that could feasibly be employed with
in the DCS. To this end, EDS allows the administrator to populate its user details from an
external data source such as CICS data storage. However, if EDS is to maintain staff and
student details separately, this causes a situation called update anomalies that arises from
duplication of data within an organisation. Furthermore, this will also increase the work load
of the technical staff. In order for EDS to be a practical system, it needs to interact with two
data tiers, which are CICS LDAP server and EDS’s own database.
53
References:
Literature References:
1. Date, C. J. (2000), An Introduction to Database Systems, Seventh Edition, Addison

Wesley
2. Elmasri & Navathe (2000), Fundamentals of Database Systems, Third Edition,
Addison Wesley
3. Connoly, T., Begg, C., Strachan, A. (2002), Database Systems: A Practical Approach
to Design, Implementation and Management, Second Addition, Addison Wesley
4. Baer, A., Saroiu, S., Koutsky, L.A., Obtaining Sensitive Data Through the Web: An
Example of Design and Methods
5. Widenius, M.M.,Axmark, D. (2002), MySQL Reference Manual: Documentation
from the Source
6. Kline , K. E. (2001), SQL in a nutshell: A Desktop Quick Reference, O’Reilly
7. Avedal, K. (2001), Professional JSP: Using Java Server Pages, Servlets, EJB, JNDI,
JDBC, XML, XSLT and WML to create dynamic and customizable web content,
Wrox Press
8. Kaurniawan, B. (2002), Java for the Web with Servlets, JSP and EJB, New Riders
9. Bakharia, A. (2000), Java Server Pages fast & easy web development, Prima Tech
10. Pekowsky, L., Java Server Pages
11. Alexander, C., Ishikawa, S., Silverstein, M. (1977), A Pattern Language: Towns,
Buildings and Construction, Oxford University Press
12. Lane, D., Williams, H.E. (2002), Web Database Applications with PHP and MySQL,
O’Reily.
13. Moss, K. (1998), Java Servlets, McGraw-Hill
14. Bakore, A. (2002), Professional Apache Tomcat, Wrox Press
15. Hunter, J., Crawford, W. (1998), Java Servlet Programming, O’Reily
16. Eaglestone, B., Ridley, M. (2001), Web Database Systems, McGraw-Hill
17. Simon, B., McRobb, S., Farmer, R. (1999),Object Oriented Systems Analysis and
Design using UML, McGraw-Hill
18. Weltman, R., Dahbura, T. (2000)LDAP Programming with Java, Addison Wesley
Web References:
[www.1] http://www.oed.com (03/05/2004)

[www.2] http://www.javaworld.com/javaworld/jw-01-2000/jw-01-ssj-tiers.html
(03/05/2004)
[www.3] http://www.woodger.ca/archweb.htm (03/05/2004)
[www.4] http://chainlink.unifiedconsulting.com/cycle.php (03/05/2004)
[www.5] http://www.csc.vill.edu/~rbalasub/netclass/disarti1.doc (03/05/2004)
[www.6] www.inf.ethz.ch/personal/iks/Other/ PDDBS/pdf/2Vers3Tiers.pdf(03/05/2004)
[www.7] http://www.cs.ucf.edu/~fhamza/papers/VirtualUniversity_Hamza-Lup.pdf
(27/11/2003)
[www.8] www.midrangeserver.com/mpo/mpo120502-story04.html (03/05/2004)
[www.9] http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_
2e/ app-arch/app-arch2.html (03/05/2004)
[www.10] http://www.dcs.shef.ac.uk/~martin/teaching/ecommerce (03/05/2004)
[www.11] http://www.computeruser.com/resources/dictionary/index.html (03/05/2004)
[www.12] http://www.apache.org/ (03/05/2004)
[www.13] http://www.dcs.shef.ac.uk/%7Esdn/campus_only/databases/notes/entities.pdf
(03/05/2004)
[www.14] https://www.dcs.shef.ac.uk/~ajc/campus_only/
teach/com3210/notes/tslides1.pdf (03/05/2004)
54
[www.15] https://www.dcs.shef.ac.uk/~steve/campus_only/
com20906540/HCILecture9.pdf (03/05/2004)
[www.16] http://www.mysql.com/ (03/05/2004)
[www.17] http://www.shef.ac.uk/cics/corportime 03/05/2004)
[www.18] http://www.myappointments.net/diaryfeatures.htm (03/05/2004)
[www.19] http://opensta.org/ (03/05/2004)
[www.20] mysql.mainseek.com/press/release_2002_12.html (03/05/2004)
[www.21] www.nviron.co.uk/solutions/nable/ technical/qualities.htm (03/05/2004)
[www.22] www.mgtaylor.com/mgtaylor/jotm/winter97/patintro.htm (03/05/2004)
[www.23] http://www.dcs.shef.ac.uk/~ajhs/discovery/(03/05/2004
[www.24] http://www.eckhartandco.com/HH-0308BB-prototypes.htm (03/05/2004)
[www.25] http://www.useit.com/papers/heuristic/heuristic_list.html (03/05/2004)
55
Glossary:
Apache Tomcat:
It is a free, open source web server.
Black Box Testing

Testing a system without knowing its internal workings
HTTP:
HTTP is a protocol used to transfer information on the world wide web.
Java Beans
A Java Bean is essentially a class written in Java language, in which data is accessed\edited
via accessor methods.
Java Servlets
Java Servlets are small, pluggable extension to a server that enhances the server’s
functionality.
JSP (Java Server Pages)

JavaServer Pages (JSP) is a Java based server-side scripting language that combines static
HTML with dynamic content.
Model-View-Controller (MVC)
MVC is a design pattern used to separate the different parts of an application into the three
components called Model, View and Controller.
MySQL
A Relational Database Management System (RDMS)
SQL (Structured Query Language)

A unified language for defining, querying, modifying and controlling the data in a relational
database.
Three-tier Architecture
Architecture design pattern that is used for web applications – the three tiers are the Client,
Web and the Data tier.
RDMS (Relational Database Management System)

A form of managing a database that involves storing data in the form of related tables.
Servlet Container
A servlet container that executes both servlets and compiled JSP pages.
56
Appendices:
12.1 Appendix: Use Case Diagrams
Staff
Update Add
View Groups
Schedule
Add Groups
Add
Schedule
Remove
Remove Groups
Schedule
Remove
Appointment View View Groups
Appointments
Add Remove
Appointments Appointments
Add Appointment
in other
Staff schedule
Students
Search Staff Schedule Remove Appointments
Add Appointments View Appointments
Add Staff
Update Student System Add Student

Administrator
Update Staff View Staff
Reset System View Student
57
12.2 Appendix: EDS File Structure
12.3 Appendix: web.xml
58
12.4 Appendix: EDS Database Tables:
Appointments:
Field Type Description
AppointmentId int(11) Unique identifier for the appointment.
ScheduleId int(11) Unique identifier for the schedule entry.
RequestersUsername Char(20) Username of the requester.
Subject Char(20) Subject of appointment.
Groups:
Name Char(100) Unique identifier and name of group.
Description Char(100) Description of group.
GroupsAndStaff:
NameOfGroup Char(100) Unique identifier for the group.
Username Char(20) Unique identifier for the staff.
Schedule:
ScheduleId int(11) Unique identifier for the schedule.
Username Char(20) Unique identifier for the staff
StartTime Time Start time of the schedule entry.
EndTime Time End time of the schedule entry.
Date Date Date of the schedule entry.
Bookable Char(30) Indicates whether this schedule is book
able or not
Staff:
Username Char(20) Unique identifier for staff.
Title Char(10) Staff’s title.
Forename Char(50) Staff’s forename.
Surname Char(50) Staff’s surname.
Password Char(10) Staff’s password.
Email Char(50) Staff’s email address.
TypeOfStaff Char(15) Indicate whether staff is academic,
technical or secretarial.
Students:
Username Char(20) Unique identifier for student.
Title Char(10) Student’s title.
Forename Char(50) Student’s forename.
Surname Char(50) Student’s surname.
Password Char(10) Student’s password.
Email Char(50) Student’s email address.
Level Char(20) Indicates the year of study of student.
59
SystemAdministrator:
Username Char(20) Unique identifier of system administrator.
Title Char(10) System Administrator’s title.
Forename Char(50) System Administrator’s forename.
Surname Char(50) System Administrator’s surname.
Password Char(10) System Administrator’s password.
Email Char(50) System Administrator’s email address.
12.5 Appendix: build.xml
12.6 Appendix: Example LDIF File
12.7 Appendix: Administration Guide

To enter the administration section of the site, use the following details:
Username: admin
Password: admin
60
The administrator can change the password, from the Change Password page.
Furthermore, system configuration parameters can be changed by modifying their values in
the web.xml file.
12.8 Appendix: Deployment Guide

Open a new command prompt window and move to the application directory. Then type:
>ant dist
This will automatically compile the project and create a build folder with all the Java classes.
In order to associate the context with tomcat, a new context entry needs to be added to the
server.xml file in the conf folder of tomcat. The entry is as follows:
<Context path="/eds05" docBase="eds05" debug="0"

reloadable="true">
</Context>
This is assuming that the eds05 folder is in the webapps folder of tomcat.
This entry only needs to be made once. This is to associate the web application with tomcat.
61

EDS Electronic Diary System

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EDS Electronic Diary System

Uploaded by

Copyright:

Available Formats

COM3021 – Final Dissertation Report

EDS – Electronic Diary System

Name: Usman Aslam

Date: 05 May 2004

I would like to thank the following people:

Chapter 2 Technology and Design Review………………………………………… 3

Chapter 3 Requirements and Analysis…………………………………………….. 14

Chapter 7 Case Study: A Web Application Interacting with LDAP…………….. 45

Figure 2.1: Interface of Corporate Time displaying the weekly schedule………………….. 2

Figure 5.1: Architecture and file structure of EDS………………………………………... 29

Figure 6.1: Code listing of LoggingIn.tsl………………………………………………… 41

Figure 8.1: Modified version of MVC design pattern used in EDS……………………...… 51

Table 3.1: User Analysis………………………………………………………………... 16

Table 5.1 EDS programming statistics 40

Table 6.1: Test case for LoggingIn.frm…………………………………………………... 42

2.1 System Comparison:

2.1.1 Corporate Time:

Figure 2.1: Interface of Corporate Time displaying the weekly schedule

Figure 2.2: Interface of MyAppointments.net displaying the weekly schedule,

Web tier Response

Data tier Data

Figure 2.3: Three Tier Architecture

An alternative approach to three-tier architecture is the page-centric approach (two-tier

2.3 Web Tier - Design Patterns:

2.3.1 Model View Controller (MVC):

2.4 Web Tier – Programming Technology:

2.4.1 Jakarta -Velocity:

request get template

Merge template Put data in

Figure 2.5: MVC design pattern with in a Velocity application

2.4.2 Enhydra XMLC:

Figure 2.6: MVC design pattern within an XMLC application

2.4.3 JSP Type II Solution:

Type II solution involves using the following technologies:

Java Server Pages:

2.5 Web Tier - Server Technology:

2.6 Data Tier - Database:

A database is “an organised collection of inter-connected data items” [www.11] and is

2.7 Data Tier - Database Design:

2.7.1 Entity/Attribute Analysis:

2.7.2 Top-down and Bottom-up Approaches:

2.7.3 Three Stages of Database Design:

2.8 Data Tier - MySQL Database Management System:

2.8.1 Comparison of MySQL and mSQL:

2.8.2 Comparison of MySQL and PostgreSQL:

As compared to MySQL PostgreSQL offers [5]:

MySQL offers the following advantages over PostgreSQL [5], [www.16]:

2.9 Interface Design and Usability:

2.10 Chapter Summary:

3.1 Aims and Objectives:

The design of EDS must be according to the following guidelines:

• Compatibility: Technologies used in the development of EDS should be compatible

3.2 User Analysis:

Table 3.1: User Analysis

3.3 Approach to Requirements Gathering:

• 3 identifies the section e.g. Staff Requirements

• 4 represents the requirement number.

3.4.1 Functional Requirements:

Req. ID Description Priority

2 System Administrator Requirements

Req. ID Description Priority

Req. ID Description Priority

Req. ID Description Priority