Al Hussain I

Web Development
of
a Cricket Progress File
Yousuf Al Hussaini
MSc. Information Systems
(2001/2002)
The candidate confirms that the work submitted is his own and the appropriate credit has been given where
reference has been made to the work of others.
I understand that failure to attribute material which is obtained from another source may be considered as
plagiarism.
Summary
This project is intended to help the Bradford/Leeds Centre for Cricketing Excellence introduce
student progress files in which student cricketers will record their development in various skill
areas, including technical, tactical, physical and mental skills as well as lifestyle development.
An iterative evolutionary prototype has been developed consisting of a database and a web front-
end to enable the students to use it to log their skills development. The coach, in turn, will also be
able to use the prototype to monitor the performance progress of his students (players) textually;
statistically and graphically, record his comments, and obtain players feedback through the use of
the electronic questionnaires provided by the prototype. The prototype should also enable the
players to reflect, to their academic tutor, on how their cricketing progress has contributed to their
academic achievement.
The reader should note that this report documents the iterative developments of the prototype where
there is no clear cut between development stages (or phases). In other words, part of the
requirements could be captured in middle or late stages and may not be necessary in initial stages
such as requirement analysis stage. He should also note that, throughout the report, the words
“system”, “application” and “prototype” are used interchangeably to reference the same
product/artifact.
i
Acknowledgement
I would like to take this opportunity to thank all of the following:
- My supervisors, Mr. Peter Mott and Dr. Julika Matravers for their full support, advice,
guidance and finding the time to see me.
- Dr. Lydia Lau for her interim report feedback and her valuable advices in the early
stages of this project, which helped me start it off.
- My client members, Peter Rees Jones, Kevin Sharp, Clive Souter, Andy Siddall and
Andy Walker for their time and support, and their interest, that without them it wouldn’t
be possible to accomplish this project.
- My family members and my friends, here and back home, for their continues
encouragement, prayers and wishes during the entire MSc. Course.
For all of these, I would say: many thanks and bless you.
ii
Contents
Chapter 1: Introduction 1
1.1 Background 1
1.2 Objectives 1
1.3 Minimum Requirements 2
1.4 Deliverables 2
1.5 Deployment 2
1.6 Development Approach 2
1.7 Project Schedule 4
1.8 Literature Review of Tools/Techniques 5
1.8.1 System Architecture 5
1.8.2 Active Server Pages (ASP) 6
1.8.3 SQL Server 8
Chapter 2: Requirement Capture 10
2.1 What is a Progress File 10
2.2 The Cricket Progress File (CPF) 10
2.3 Information Gathering 11
2.4 System Requirements 11
2.4.1 The Current CPF System 13
2.4.2 The Proposed CPF System 13
Chapter 3: Requirement Analysis 15
3.1 The Detailed Use Case Diagram of the CPF 15
3.2 Use Case Description 16
3.3 Modeling the Interaction 17
3.4 Modeling System Functionalities 19
Chapter 4: Prototype Design 21
4.1 Moving from Analysis to Design 21
4.2 Mapping Classes into ASP/HTML Files and SQL Server Database Tables 21
4.3 Software Architecture of the CPF Prototype 23
4.4 Database Design 24
4.4.1 The E-R Model-Overall View 24
4.4.2 Normalization 25
4.4.3 The E-R Model-Detailed View 25
4.4.4 The Relational Model 28
4.5 User Interface Design 29
4.5.1 Web Design 29
Chapter 5: Prototype Implementation 31
5.1 Database Creation 31
5.2 Website Construction 31
5.2.1 Controlling Appearance and Access 32
5.2.2 Signing-in to the CPF 32
5.2.3 System Administration 33
5.2.4 Scoring against Cricketing Skills 34
5.2.5 Commenting on Player’s Performance 35
5.2.6 Monitoring Progress 36
5.2.7 Managing Questionnaires 39
5.3 User Input Validation 43
iii
Chapter 6: Evaluation 44
6.1 Meeting the Objectives 44
6.2 Meeting the Requirements 45
6.3 User Acceptance Test 47
6.4 Suggestions for Further Improvement 48
Chapter 7: Conclusion 49
References 51
Appendix A: Reflection upon the Project Experience 52
Appendix B: Objectives, Deliverables and Agreed Marking Scheme 53
Appendix C: A Copy of the Interim Report Header Sheet 54
Appendix D: Requirement Specifications Report 56
Appendix E: Information Gathering Samples 70
Appendix F: Code Segment Samples 78
Appendix G: User’s Feedback and the Outcome of the Acceptance Test 85
Appendix H: CPF Installation Guide 89
iv
Web Development of a Cricket Progress File 1/89
Chapter 1: Introduction
This chapter gives a brief introduction to the problem, the objectives, the suggested solution and a
literature review of the associated technology. It also describes the overall structure of this report
and the approach used to carry out the project.
1.1 Background
The Bradford/Leeds Cricketing Centre of Excellence is a member of the University Centres of

Cricketing Excellence (UCCE). The centre is located in Bradford City and dedicated to the students
from west Yorkshire universities, i.e. University of Bradford, Bradford College, University of
Leeds and Leeds Metropolitan University. The main task of the centre is to train and educate the
players (students of west Yorkshire universities) on cricketing skills, both physical and mental. The
mission of the centre is to help players mature faster and become excellent professional cricketers.
At present, the centre does not have a standard way of monitoring cricket progress files of the
players. The coach keeps his own set of paper files to log the development of players’ skills and
monitor their achievements. Recently, the centre has decided to adopt a better way of keeping the
cricket progress files. The plan is to create a standard file and join up all separate records into this
file. The planned cricket progress file is to be maintained by the players themselves (not the coach)
and to be made available to the coach electronically through the Internet. The key objective of this
project is to develop a software prototype as a first step (iteration) to form the basis of an iterative
development of a cricket progress file.
1.2 Objectives
The objectives of this project are:

• To use the Internet to allow the players maintain their own cricket progress files.
• To maintain the players’ various skills and achievement records into a database system so
that their progress can be monitored by themselves and by their coach.
• To improve the way the cricket progress file is being handled, and eliminate the need for the
coach to keep manual records.
• To facilitate the coach’s job by letting the players keep their own performance records
electronically and make them available to him at any time.
• To provide a working prototype that would help in creating a standard cricket progress file.
1.3 Minimum Requirements
The minimum requirements of this project are:

• Design of a database system using SQL Server database.
• Development of an interactive web interface with Active Server Pages and HTML.
1.4 Deliverables
The deliverables of this project are:

1. A project report.
2. A working prototype of “a database system accompanied by a web front-end”.
1.5 Deployment
The system will be deployed under Microsoft Windows NT/2000 platform that supports Microsoft
SQL Server and Microsoft Active Server Pages. There is no specific reason to develop it and deploy
it under Microsoft environment. However, prototyping under Microsoft environment can be done
faster and easier, saving the time and the effort of coding, because of the powerful development
tools provided by Microsoft. More general reasons like the ones listed in [11] do also apply to the
development of the prototype. The client is to decide whether to find a sponsor who would host the
system, or to go for a commercial Internet Support Provider. The later is recommended; as most of
the commercial hosts provide range of services such as email accounts, email forwarding, files
uploading, etc. The monthly charge of a commercial hosting ranges from £30 to £50. However, the
prototype has been developed using the School of Computing web/database server on CSMS2
machine. The prototype can be accessed through http://csiis.leeds.ac.uk/msczyka/cpf provided that
login information is issued.
1.6 Development Approach
The object oriented method will be adopted for analysis and conceptual design of the Cricket
Progress File system. Unified Modeling Language (UML) will be used to model the development
system components. After system components are identified, they will be mapped into a form that
can be implemented under the development environment. Design of the database will involve the
use of Entity-Relationship modeling diagrams; as the underlying database is relational. An iterative

approach is demanded for construction of an evolutionary prototype. The prototype will give the
user/client the chance to be involved in the development stages and therefore help him express his
full requirements as the development progresses. It will also help the developer understand the
actual user requirements and enable him to accommodate them into the system.
Object oriented analysis and design has been preferred over the structured methods for the
following reasons:
• It provides an abstract view of the system and hence shows the big picture of the
requirement specifications;
• It is, unlike the structured methods, provides an organic structure of the system. That is both
data and processes are coupled together in the same unit (or class). Therefore, it enables the
designer to discover system operations without the need for a separate process modeling;
• It is a good candidate for the development of a Three-tier architecture system. System
components in object oriented can be distributed into the different layers of the system
architecture quite easily;
• It minimizes the cost of maintenance and of future development; as the conceptual system
components can be re-used.
Furthermore, UML has been chosen to model system components because it is the standard
modeling language, for object oriented systems, adopted by the Object Management Group (OMG).
This has been stated by [6] and [7].
The basic concept of the System Development Life Cycle will be used as a framework for every
iteration of the prototype. Two to three iterations of the life cycle will be performed and their
outcome will be checked against user requirements. Figure 1.1 illustrates the iterative life cycle
approach.
Requirement
Analysis
Requirement
Specifications
Prototype
Design
Next Iteration
Prototype
Implementation
Test &
Evaluation
Figure 1.1 Iterative System Development Life Cycle.

Adapted from [6]
1.7 Project Schedule
Project schedule has been revised and adjusted from the original schedule given in the interim
report. It was quite difficult to follow the original schedule as I had to base the new schedule on the
client availability. The tasks have been accomplished as per Table 1.1 below. Every iteration of the
prototype includes the life cycle processes shown in Figure 1.1. The report has been re-visited and
modified to accommodate the modifications in the prototype as suggested by the client.
Date Period Task Accomplished

March 2002 - Background research.
- Problem investigation.
April-May 2002 - Requirement gathering.
- Requirement analysis and specifications.
June 2002 - Write up of Chapter 1 (Introduction).
- Write up of Chapter 2 (Requirement Capture).
- Start first iteration of the prototype.
July 2002 - Continue first iteration of the prototype.
- Write up of Chapter 3 (Requirement Analysis).
- Write up of Chapter 4 (Prototype Design).
- Release of first iteration of the prototype.
Beginning-Mid - Write up of Chapter 5 (Prototype Implementation).
Aug 2002 - Start second iteration of the prototype.
Mid August-5th of - Release second iteration of the prototype.
September 2002 - Write up of Chapter 6 (Evaluation).
- Write up of Chapter 7 (Summary).
- Report review, sum-up and delivery.
- Review and delivery of the prototype.
Table 1.1 Project Schedule
1.8 Literature Review of Tools/Techniques
In this section, an overview of software and hardware requirements is represented. The tools and/or
techniques discussed below are based on the requirement specifications of the prototype. Please see
appendix D (Requirement Specifications Report) for details.
1.8.1 System Architecture
The software system to be delivered is of Three-tier Architecture type. This architecture is used for
many Internet technology database applications. Three types of processors or tiers are shown in
Figure 1.2. From right to left, they are the database server, the web server, and the browser or client
computers. Each of the three tiers can run under a different operating system/platform. In the
Cricket Progress File application, the database server and the web server both run under Windows
2000 server, and the browsers can run heterogeneous PC operating systems. The application is
independent of the browser operating system.
The software products shown underneath each tier of Figure 1.2 are Microsoft SQL Server on the
database server, Microsoft Internet Information Server (IIS) on the web server, and any kind of
browser on the clients, e.g. Netscape Navigator 4.0+ or Microsoft Internet Explorer 5.0+.
The interface between the web server and the database server transmits SQL statements and
relational data. The interface between the web server and the browser transmits web pages and
client code (HTTP requests). The purpose of the database server is to run the Database Management
System (DBMS) to process SQL statements and perform database management tasks. It is a pure
data engine; receiving SQL requests and processing table rows. [1]
Browser HTTP
Requests
Web SQL
Server Requests
Database
Browser Server
Browser
Microsoft IIS, SQL Server,

Netscape Navigator/
Windows 2000 Windows 2000
Internet Explorer
Figure 1.2 Three-tier Architecture.

Adapted from [1].
1.8.2 Active Server Pages (ASP)
As shown in Figure 1.2, the web server will always be IIS since it is part of Windows 2000
operating system. IIS, as described by [1], provides an interface called Internet Server Application
Program Interface (ISAPI) by which other programs can trap and process HTTP messages. The
Active Server Pages (ASP) is one such program. It processes all web pages with the suffix .asp.
When IIS receives such a page, it sends it to ASP over the ISAPI interface. ASP then processes the
page and sends a response back to the client via the ISAPI interface to IIS.
ASP is defined by [2] as follows: “ASP (Active Server Pages) is a technology developed by
Microsoft. Pages using ASP are primarily developed in JavaScript, VBScript , or PerlScript and are
integrated into the HTML of your Web pages. The ASP code is compiled on-the-fly by the server
and the resulting output is standard HTML. By using ASP, Web pages can be dynamic, full of ever-
changing content, and browser independent”.
Besides generating dynamic HTML pages, ASP can be integrated with Microsoft Component
Object Model (COM) objects to access databases or to call another COM object that is written in
C++, Visual Basic or Java. The COM object used to access databases is called ActiveX Data Object
(ADO). Figure 1.3 shows the way that ASP accesses databases and generates dynamic HTML
pages.
DB Storage
Figure 1.3 ASP Architecture and Work Mechanism [3]
ASP, as described by [2], includes five standard objects for global use, which are:
- Request: to get information from the user, normally through HTML forms.
- Response: to send information to the user.
- Server: to control the Internet Information Server.
- Session: to store the information and the settings of the user's current Web-server session.
- Application: to share application-level information and control settings for the lifetime of
the application.
1.8.3 SQL Server
The SQL Sever description in this section is provided by [4].
SQL Server is a relational database management system (RDBMS). A database typically has two
main parts: first, the files holding the physical database and second, the database management
system (DBMS) software that applications use to access data. The DBMS is responsible for
enforcing the database structure, including:
• Maintaining relationships between data in the database.
• Ensuring that data is stored correctly, and that the rules defining data relationships are not
violated.
• Recovering all data to a point of known consistency in case of system failures.
The data in a database is organized into the logical components visible to users. A database is also
physically implemented as two or more files on disk. When using a database, the user works
primarily with the logical components such as tables, views, procedures, and users. The physical
implementation of files is largely transparent. Typically, only the database administrator needs to
work with the physical implementation. Figure 1.4 shows the two components of a database.
Figure 1.4 Components of a Database [4]
The database in the SQL Server has two different database components (see Figure 1.5):
• System databases: these are administrative databases used to control and secure the whole
database system. They also maintain information about user databases.
• User databases: these are user created databases for specific applications.
Figure 1.5 SQL Server Architecture [4].
Figure 1.5 shows that SQL Server is settled above the databases. In fact, it is the memory instance
or the engine that enable the user to communicate with the database (the physical storage) by using
the Structured Query Language (SQL). Through SQL the user can enquire or manipulate the
information stored in the database, or even alter the database structure.
Chapter 2: Requirement Capture
This chapter gives an understanding of the business, i.e. the Cricket Progress File (CPF), and
describes the user requirements in brief. It shows an overall view of what the CPF system is about.
2.1 What is a Progress File?
A progress file is defined by [5] as the following: “While the term Progress File suggests that it is a
document charting the progress of an individual, the overall concept contains:
• The transcript: a record of an individual's learning and achievement, provided by the
institution;
• an individual's personal records of learning and achievements, progress reviews and plans
that are used to clarify personal goals and can provide a resource from which material is
selected to produce personal statements (e.g. CVs etc) for employers, admissions tutors and
others;
• structured and supported processes to develop the capacity of individuals to reflect upon
their own learning and achievement, and to plan for their own personal educational and
career development. The term Personal Development Planning (PDP)is used to denote this
process.
Progress files help to make the outcomes, or results, of learning in higher education more explicit,
identify the achievements of learning, and support the concept that learning is a lifetime activity”.
2.2 The Cricket Progress File (CPF)
The Cricket Progress File (CPF) from the client point of view is described as follows:
The Cricket Progress File (CPF) will be used by the UCCE cricketers to log their performance and
review with their coach the higher-level skills, such as concentration, in order to improve their
performance. This is the primary function of the CPF. The qualities this develops in players are
relevant to their personal and academic development, and a secondary function of the CPF is to
communicate the value of this to the academic tutor in the terms used by the generic university
progress file.
The CPF is a valuable document for the player, his coach and others who are contributing to his
development as a cricketer. It uses a detailed log of the player’s developing cricketing skills to help
him identify the more general skills, attitudes and aptitudes he is acquiring, and in this way helps
him mature as a player more quickly. This will also help the player express the value of sporting
excellence to his university academic tutor and cope with the competing demands of sport, study
and social life.
The CPF will also help the player to express to his academic tutor the value of cricket from
developing his general skills, such as teamwork and motivation; and attitudes, such as the ability to
set goals and achieve them.
2.3 Information Gathering
There are different information gathering techniques that are used by analysts to investigate
requirements. [6] describes the five main information gathering techniques in broad details. These
techniques are Sample Documents, Questionnaires, Interviews, Background Reading and
Observations. They are also referred to as SQIRO techniques.
Through the CPF project, three of the information gathering techniques have been used, which are
Sample Documents, Interviews and Questionnaires. In addition to these, Email Enquiries have also
been used for answering some short questions that do not require meeting with the client. Email,
overall, was an effective communication tool throughout the project. Examples of information
gathering techniques used throughout the CPF project can be found in Appendix E (Information
Gathering Samples). The user requirements, listed in Appendix D (Requirement Specifications
Report), is the outcome resulted from using such techniques.
2.4 System Requirements
The aim of developing a new system must be to produce something that meets the need of the
people who will be using it. In order to do this, we must have a clear understanding both of the
overall objectives of the business and of what is that the individual users of the system are trying to
achieve in their jobs. Unless we are in a rare position of developing a system for a new
organization, we will need to understand how the business is operating at present and how people
are working now. Many aspects of the current system will need to be carried forward into the new
system, so it is important that the information about what people are doing is gathered and
documented. These are the requirements that are derived from the ‘current system’. The motivation
for the development of a new system is usually problems with and inadequacies of the current
system, so it is also essential to capture what is that users require of the new system that they cannot
do with their existing system. These are the ‘new requirements’. [6]
System requirements, as described by [6] fall into one of the three categories: functional
requirements, non-functional requirements and usability requirements.
Functional requirements describe what a system does or is expected to do, often referred to as its
functionality [6]. In the object-oriented approach, which is adopted for the analysis and design of
the CPF, I shall initially employ use cases to document the functionality of the system. As I
progress into the analysis stage, the detail of the functionality will be recorded in the data that are
held about the objects, their attributes and operations. “Functional requirements include the
following:
• Description of the processing that the system will be required to carry out.
• Details of the inputs into the system form paper forms and documents, from interactions
between people, such as telephone calls, and from other system.
• Details of the outputs that are expected from the system in the form of printed documents
and reports, screen displays and transfers to other systems.
• Details of data that must be held in the system.” [6]
Non-functional requirements, as described by [6], are those that describe aspects of the system that
are concerned with the quality of providing the functional requirements. These include the
following:
• Performance criteria such as desired response times for updating data into the system or
retrieving data from the system.
• Anticipated volume of data, either in terms of throughput or of what must be stored.
• Security considerations.
• Hardware and software constraints.
Usability requirements are those that will enable us to ensure that there is a good match between the
system that is developed and both the users of that system and the tasks that they will undertake
when using it. The International Standards Organization (ISO) has defined the usability of a product
as “the degree to which specific users can achieve specific goals within a particular environment;
effectively, efficiently, comfortably and in acceptable manner”. “In order to build usability into the
system from the outset, we need to gather the following type of information:
• Characteristics of the users who will use the system.

• The tasks that the users undertake, including the goals that they are trying to achieve.
• Situational factors that describe the situation that could arise during system use.
• Acceptance criteria by which the user will judge the delivered system.” [6]
2.4.1 The Current CPF System
I shall describe the current system briefly as it does not offer a great contribution to the
development of the proposed CPF system. Instead, the requirements of the proposed system are
discussed in detail bearing in mind the concept of the current system.
The existing CPF system is very simple. It is paper based, and involves two types of users
(stakeholders) who are the coach and the player. The coach interviews each player at a time and
record his skills and performance progress on a paper. This interview is done informally, after a
cricket match or during a training session. By time, the coach should have a clear view about the
player’s progress. The player also is informed of his progress regularly. The use case diagram
below demonstrates this interaction between the coach and the player.
Interview P lay er
Coac h P lay er
Rec ord P erform anc e P rogres s
Figure 2.1 The Current CPF System
2.4.2 The Proposed CPF System
The new (or proposed) CPF system is to be fully computerized. The player plays the most crucial
part on maintaining his progress file(s) on behalf of his coach. The coach does only need to
monitor/view those files, and should be able to add his comments on them. A third actor is involved
in the new system, which is the academic tutor. He should also be able to monitor the skills related
to the player’s academic life, and also add his own comments where applicable. Figure 2.2 is an
overall view of how the requirements of the new system should look like.
M aintain Cric ket P rogres s File
P layer
Coac h
M onitor Cric k et P rogres s File
A c ad emic Tutor
Figure 2.2 Overall-View Use Case Diagram of the New CPF System Requirements
Chapter 3: Requirement Analysis
This chapter analyzes the detailed functionality of the CPF system. All components of the system
will be identified, and the interactions between these components will be examined. It will start to
go into more details of the user requirements by representing these requirements with a detailed use
case diagram. It will then take every use case, describe it textually using use case description
technique, and systematically using the standard UML interaction diagrams such as
collaboration/sequence diagrams, and activity diagrams. Since the end product (i.e. the program
code) will not be object oriented, the interaction diagrams will be used to extract the candidate class
diagram, whereas, the activity diagrams will be used mainly to model the functionalities of the
system/subsystems so that the functionalities can be translated into program codes. This chapter will
finally arrive at a conceptual class diagram model that should have been constructed from the
description of the detailed use case diagram. The conceptual, or concept-level, class diagram will be
the first cut of the solution model which is the detailed class diagram.
Requirement analysis will be illustrated using only some examples of the CPF UML notational
diagrams. The detailed specifications, including the essential UML models of the CPF, can be
found in Appendix D (Requirement Specifications Report).
3.1 The Detailed Use Case Diagram of the CPF
“The most influential factor for the success of an information system project is whether the software
product fulfils its users’ requirements. Models constructed from an analysis perspectives aim at
determining these requirements. This means much more than just gathering and documenting facts
and requests.” [6]
The use case diagram shown in Figure 3.1 models the textual user requirements of the CPF (as
given by Appendix D) in a visual abstract view. It gives a perspective on many user requirements
and models them in terms of what the CPF system can do to help the users perform their work (i.e.
what functionalities can the CPF system provide). The model in the figure introduces a new actor
which is the System Administrator. This actor plays an administrative role such as creating and
managing user accounts for the users who will be involved in using the CPF system.
E nter Tex t Comments about

Fill-in S c ores of Cric k eting S kills
Play er's P rogres s
Coac h
View Cric k eting Progres s

Play er
Sum mary View/Collec t Ans wered
Qustionnaire
Ac ad emic Tutor
Ans wer Ques tionnaire << ex tend> > Ge nerat e Ques tionnaire
<<ex tend>> < <ex tend> >
Alter Us er Ac c ount Inform ation Delete Ques tionnaire M odify Ques tionnaire
<<ex tend>>
< <inc lude> >
Create Us er A c c ount As sign Ac c es s Rol e

S y stem
A dministrator
Figure 3.1 The Detailed Use Case Diagram of the CPF system
3.2 Use Case Description
Use case description is described by [7] as an informal specification of the system functionalities. It
does not have any formal syntax, and the description can be written in a format that is most useful
to the development team and, of course, to the system actors. The simplest and most common
approach used is to describe each use case using simple English text. Table 3.1 describes one of the
use cases of Figure 3.1. An extra column has been added to construct possible candidate classes
from the text. Full description of the use cases can be found in Appendix D (Requirement
Specifications Report).
Use Case Name Actor(s) Description Possible Candidate

Involved Classes
1. Fill-in Scores of Player Player records his cricketing skills Player, Skill, Score
Cricketing Skills regularly (once a week or so). He has to
fill-in/select the score against each
particular listed skill. The score value is
defined in the range 1-10.
Table 3.1 Description of the Use Case “Fill-in Scores of Cricketing Skills”
3.3 Modeling the Interaction
Having constructed the candidate classes for each use case, the interaction between these classes
can now be modeled. In object orientation, objects interact with each other by sending messages
(see [6] and [7]). In Figure 3.2 below, sequence diagram is used to model all possible interactions
between objects of the classes found in use case 1 (Fill-in Scores of Cricketing Skills). Please note
that some of the classes are not in the use case description text as they are going to be the interface
classes the user of the system will be using to interact with the system. Fore example, in Figure 3.2,
CPFHomePage and PlayerHomePage are the interface classes which are going to be web pages
eventually.
: CP F Hom eP age : Us erA c c ount : P lay erHom eP age : S k ill : S c ore : P la y erDB
: P lay er
s ignIn( )
get A c c ount Details ( )
aut horiz e( )
dis play ("U RL")
lis t S k ill( )
get P lay erID ( )
fill-inS c ore( )
r ecord Sc ore( )
Figure 3.2 Sequence Diagram for the Use Case “Fill-in Scores of Cricketing Skills”
Part of the concept-level class diagram can now be drawn using the classes and associations
resulted from the above sequence diagram. See Figure 3.3 below.
Pl ay erHom ePage
CPFHom eP age
dis play ()
authoriz e()
fill-inSc roe()
s ignIn()
ans werQues tionnaire()
Us erA c c ount
Play erDB
getA c c ountDetails ()
addUs er()
getP lay erID()
Ques tionnaire
c reat eNewQues t ionnaire()

a ddAns wer( )
a ddQu es tion()
g etDet ail s()
Sc or e
S k ill
rec ordS c ore()

lis tSk ill()
getSc ore()
addTex tComm ent()
Figure 3.3 Part of Concept-Level Class Diagram Resulted from

the Sequence Diagram in Figure 3.2
Likewise, the interaction of other use cases can be modeled and their partial concept-level class
diagrams can be drawn. All resulted partial concept-level class diagrams can eventually be joined
into one concept-level class diagram (Figure 3.4). This concept-level class diagrams forms the basis
of the detailed class diagram which will be described in chapter 4 (Prototype Design).
P la y e rH o m e P a g e
A d m in H o m e P a g e C P FH om e P a ge
d is p la y ()
d is p la y () a u th o riz e ()
fi ll- in S c r o e( )
c re a te U s e rA c c o u n t () s ig n In ()
a n s w e rQ u es t io n n a ire( )
U s e rA c c o u n t
P la y e rD B
C oa c hH om eP age g e tA c c o u n t D e ta ils ()
a d d U s e r()
g e t P la y e rID ()
d is p la y () C oac hD B
vie w S u m m a ry ()
g e n e ra te Q u e s tio n n a ire () C om m en t
c o lle c t Q u e s t io n n a ire ()
e n t e rTe x t C o m m e n t () a d d T e x t C o m m e n t ()
Q u es t io n n a ir e
c re a t e N e w Q u es t io n n a ir e()
a d d A n s w e r( )
a d d Q u e s ti o n( )
g e tD et a il s( )
S c o re
S u m m a ry
S k ill
re c o rd S c o re ()
d is p la y S um m a ry( )
g e tS c o re () lis t S k ill()
Figure 3.4 Concept-Level Class Diagram of the CPF System
3.4 Modeling System Functionalities
UML activity diagrams can be used to model functionalities and information flow in a use case.
Activity diagrams, as described by [7], has many purposes. They can be used throughout a project
from business analysis through to program design. In the CPF system, activity diagrams are used as
a bridge to bring the high-level functionalities of use cases towards producing the program code.
Figure 3.5 describes the high-level logic encapsulated in use case 1 (Fill-in Scores of Cricketing
Skills).
S ig n In
A u t h o riz e
[ In v a lid u s e r n a m e / p a s s w o r d ]
[ V a lid u s e r n a m e / p a s s w o rd ]
Di s p la y P l a y er
Hom e P age
L is t S k i ll
S c o re a g a in s t
t h e S k ill
[ M o re s k ill s t o lis t ]
[ N o m o re s k ills t o l is t ]
R e c o rd S c o r e s
Figure 3.5 Activity Diagram for the Use Case “Fill-in Scores of Cricketing Skills”
Chapter 4: Prototype Design
This chapter describes the design of the CPF prototype. Since the prototype to be developed is an
evolutionary prototype, all software components should be constructed and linked together to form
a working prototype system. This prototype is an iterative one (as introduced in chapter 1).
Additional functionalities will be incorporated as new iterations are performed. The client
involvement plays an essential part of the development of this prototype.
This chapter begins with a description of the detailed class diagram that its operations will be
mapped into functions (i.e. ASP/HTML and JavaScript codes), and its classes will be mapped into
user interfaces and relational database tables. It will then describe the steps involved in designing
the relational database. Finally, this chapter will discuss the issues related to Human Computer
Interface (HCI) and web design.
4.1 Moving from Analysis to Design
The concept-level class diagram, described in section 3.3, is recalled here. Further refinements
should be performed to the diagram, attributes should be constructed and extra operations may be
added. Figure 4.1 shows the detailed class model of the CPF Prototype. Refinements have been
made to the model after further study of user requirements. Please note that there is no home page
dedicated to the academic tutor. Nevertheless, the coach’s home page, is to be used by him, only, to
generate and collect questionnaires related to the academic aspects.
4.2 Mapping Classes into ASP/HTML files and SQL Server Database Tables
Since the implementation of the CPF prototype is to be done using ASP as the coding language,
and/or SQL Server as the database engine, classes need to be mapped into a form that is suitable to
the development environment. Classes need to be expressed either into ASP/HTML files and/or
SQL Server database tables. For example the interface class “PlayerHomePage” will be in a form of
HTML file, while the class “PlayerDB” will be in a form of database table since it is meant to hold
player’s biographical details. However, some of the classes, that are to be used as data storage and
processing at the same time, need to be expressed in both forms, ASP/HTML and SQL Server
database tables. An example of this type of classes is the “Questionnaire” class. Operations of the
classes will be encapsulated into the ASP scripts. Table 4.1 shows the forms of how the different
classes are going to be in.
< < W eb P age> >

< < W eb P age> >
P layerHom eP age
CPFHom eP age
1 0..n
< < W eb P age> > 1
1 display()
A dm inHom eP age authorize()
fill-inS croe()
signIn()
TutorDB answerQuestionnaire()
display() 1
tutorid 1
createUserA ccount()
Use rA ccount tutornam e 1 1
1
userid P lay erDB
1
1 usernam e 0 .. n playerid
passwd
< < W eb P age> > 1 playernam e
accessrole 1
Coa chHom eP ag e dob
status
institution
0. .n
cou rse
display() getA ccount Details()
viewS um m ary() 1
addUser()
getP layerID()
generate Q ues tionnaire() 1
0..n 1
collectQuestionnaire()
1
enterTextCom m ent() 1 0.. n
0.. n
CoachDB 1 S c ore
Com m ent
1 coachid 1 0.. n valu e S um m ary
0.. n 0..n
coachnam e
addTextCom m ent()
recordS c ore() disp laySum m ary()
1 ge tS core()
0..n 0.. n
0..n Questionnaire
qid 1
qtitle S kill
c reationdate
skillid
available
skillnam e
answered
listS kill()
c reateNewQues tionnaire()
addA nswer()
addQuestion()
getDetails()
Figure 4.1 Detailed Class Model of the CPF Prototype
Class Name ASP/HTML Database

CPFHomePage !
AdminHomePage !
PlayerHomePage !
CoachHomePage !
UserAccount !
PlayerDB !
CoachDB !
TutorDB !
Skill !
Score ! !
Questionnaire ! !
Comment ! !
Summary !
Table 4.1 Possible Different Forms of the Mapped Classes

4.3 Software Architecture of the CPF Prototype
The system architecture of the CPF prototype has already been described in Chapter 1 from the
hardware point of view. Since the system architecture of the CPF is a three-tier architecture,
software components should conform to this architecture and hence they should be distributed
across the three tiers according to their roles and functionalities. Software architecture defined by
[6] as: “A description of the sub-systems and components of software system and the relationship
between them. Subsystems and components are typically specified in different views to show the
relevant functional and non-functional properties of a software system. The software architecture is
an artifact. It is the result of the software design activity”.
There are different types of software architecture approaches described in [6]. One popular
approach is what is called the “layered architecture”. Layered architecture means that system
components are placed on separated layers. Tightly related components are placed in the same
layer. In three-tier architecture, layers are divided into data storage layer, application layer and
presentation layer. The CPF software architecture is kind of three-tier layered architecture. Figure
4.2 represents the CPF software architecture and shows the main components of the prototype.
Presentation Layer CPFHomePage

(HTML/ASP User Interfaces)
AdminHomePage PlayerHomePage CoachHomePage
HTTP Requests
Application Layer Score Questionnaire Summary Comment
(ASP Dynamic Scripts)
Data Connectivity ADO/OLE-DB
Data Layer
(SQL Server Database Tables) Skill Questionnaire Comment
Score PlayerDB CoachDB
TutorDB UserAccount
Figure 4.2 Software Architecture of the CPF Prototype

4.4 Database Design
As the database layer and its components have already been identified, further work need to be
curried out to make sure that this layer conforms to the Relational Database Management System
(RDBMS) roles. Referring to Figure 4.2, the database tables within the data layer are the candidate
relations (or entities) to start with. In this section the Entity-Relationship, or E-R, diagram will be
constructed. Relations of the E-R diagram need to be normalized to the Third Normal Form (3NF).
Then the Relational Model of the CPF prototype can be drawn as the final step prior to database
creation. The relational model is supported by description of relations and attributes. This
description is attached to Appendix D (Requirement Specifications Report).
4.4.1 The E-R Model-Overall View
“To insure that we get a precise understanding of the nature of the data and how it is used by the
enterprise, we need to have a model for communication that is non-technical and free of
ambiguities. The Entity-Relationship (ER) model is one such example. ER modeling is a top-down
approach to database design that begins by identifying the important data called entities and
relationships between the data that must be represented in the model” [8].
The candidate entities that form the E-R model of the CPF prototype, as presented in Figure 4.2, are
Questionnaire, Skill, Score, Comment, UserAccount, PlayerDB, CoachDB and TutorDB. For
simplicity, PlayerDB, CoachDB and TutorDB entities will be renamed to Player, Coach and Tutor
respectively. The diagram represented by Figure 4.3 is the first cut E-R model of the CPF prototype.
has 1
USERACCOUNT 1 has
has 1
1 1
0..M coaches 1
PLAYER COACH
1 views writes 1
0..M
0..M 0..M 0..M 1
tutors COMMENT
possesses 0..M generates
1 1 answers
TUTOR 0..M
QUESTIONNAIRE
0..M 0..M
SKILL
Figure 4.3 First Cut E-R Model of the CPF Prototype

The entity “Score” is not shown in the diagram because it is a derived entity. It will be needed later
in the relational model to resolve the many-to-many relationship between Player and Skill.
4.4.2 Normalization
Normalization is meant to bring database entities into a form that is free of redundancy and
update/insert anomalies. Normalization, as defined by [8] is “A technique for producing a set of
relations with desirable properties, given the data requirements of an enterprise”. It is often
performed as a series of tests on a relation to determine whether it satisfies or violates the
requirements of a given normal form. There are different levels or degrees of normal forms which
are first normal form (1NF), second normal form (2NF), third normal form (3NF) and Boyce-Codd
normal form (BCNF) . BCNF was introduced by R. Boyce and E.F. Codd as a stronger definition of
3NF [8]. Higher normal forms that go beyond BCNF were introduced later such as fourth normal
form (4NF) and fifth normal form (5NF). However these later normal forms deal with situations
that are very rare [8].
There are 2 common approaches, described by [8] and [9], of arriving at normal forms:
• Bottom-up: Starting with the original entities and use normalization rules to move the
design from 1NF to a higher normal form such as 3NF.
• Top-down: Start with data modeling and, if done properly, it should lead to a normalized
database. Normalization can be used later on, as a crosscheck, to resolve any anomaly
problem.
In the database design of the CPF prototype, the top-down approach will be followed. Resulted
entities (or relations) will end up to be normalized up to the 3NF at least, although, 3NF is
satisfactory for such small-scale database.
4.4.3 The E-R Model-Detailed View
A fully normalized E-R model is demanded. A deeper analysis of user requirements would be very
useful to construct the final model. As a result of this, new entities have been constructed and added
to the E-R model. Also some relations in the original model need to be decomposed to eliminate
many-to-many (M2M) relationships as this relationship violates 1NF. The following are set of steps
that have been performed to arrive at a fully normalized E-R model:
Skills Categorization: In cricket, players (cricketers) can play different roles on the pitch. For
examples “Batting”, “Bowling” and “Fielding” are said to be roles. Players are expected to possess
set of commonly defined skills belonging to different roles. The word “skill” is used as a shortcut
referring to different levels, types, or categories, of skills. “Technical & Tactical”, “Physical” and
“Mental” are such examples of skill types. The diagram below illustrates an example of this
categorization.
Batting Role
Technical & Tactical Physical Mental Skill Type

- Hitting over the Top - Speed - Confidence
- Versus Spin - Strength - Toughness Skills
- Running between Wickets - Flexibility - Awareness
Figure 4.4 Example of Skill Categorization
Another two entities can be extracted from the above figure, which are Role and Skill_Type, in
addition to the entity Skill. The following E-R model segment has resulted from this categorization
process:
belongs to has
ROLE 1 0..M SKILL 0..M 1 SKILL_TYPE
Player-Skill Relationship: The relationship between Player and Skill is many-to-many (M2M).
This must be decomposed by introducing a third entity. In the CPF it is meant that player records
his performance progress by scoring against each cricketing skill, and hence the entity Score
introduced previously in the class diagram in Figure 4.1, as a class, is a good candidate to form the
relationship between Player and Skill entities. The new E-R structure of this relationship should
look like the following:
records against
PLAYER 1 0..M SCORE 0..M 1 SKILL
Questionnaire Formatting: Questionnaire is a complex entity. It contains set of questions. This

has to be broken down to avoid multi-valued dependency. Therefore, questions should be placed in
a separate entity say Questionnaire_Body. Questionnaire is to be answered by players later on, and,
likewise, the answers of the Questionnaire should be placed into another entity say
Player_Questionnaire. This would also resolve the Player-Questionnaire M2M relationship. Below
is the E-R segment resulting from this formatting process:
PLAYER 1 answers 0..M PLAYER_ 0..M contains 1 QUESTIONNAIRE

QUESTIONNAIRE
1
contains
0..M
QUESTIONNAIRE_
BODY
Consequently, the detailed, and fully normalized, E-R model resulting from the top-down
normalization approach can be constructed now (see Figure 4.5 below).
has 1 USERACCOUNT
1 has
has 1
1 1
0..M coaches 1
0..M PLAYER COACH
1 views writes 1
tutors 1
1 0..M 1
1 1 generates
records answers 0..M COMMENT
TUTOR
0..M PLAYER_ 0..M
0..M QUESTIONNAIRE QUESTIONNAIRE
SCORE 0..M
contains 1 1
0..M
contains
against
0..M
1 QUESTIONNAIRE_
has BODY
SKILL 0..M 1 SKILL_TYPE
0..M
belongs to
1
ROLE
Figure 4.5 The Full E-R Model of the CPF Prototype

4.4.4 The Relational Model
In this section, the entities of the final E-R model, shown in Figure 4.5, are expressed into relational
database tables with their key attributes. Relationships between the tables are represented by
primary key-foreign key referential integrity. The relational model is considered to be the final step
prior to database creation activity. Figure 4.6 shows the relational model of the CPF prototype. Only
key attributes are shown in the model. For full listing of attributes and description, please refer to
Appendix D (Requirement Specifications Report). Primary key attributes are underlined while
foreign keys are printed in Italic face. Attributes that are both underlined and printed in Italic face
are foreign keys and part of the primary key at the same time.
Figure 4.6 Relational Model of the CPF Prototype

4.5 User Interface Design
Designing the user interface can be critical in the development of an information system. The core
issues related to the user interface design process are described by [12] as:
• Understanding the essential properties of users which effect their interaction with the
computer system;
• Analyzing what users do with computer systems;
• Specifying how the interface should respond to the user and its appearance;
• Evaluating the properties of human-computer interfaces and their effect on people to ensure
good quality.
The issue of the user interface has been incorporated into the CPF prototype form the early stages of
the system development process. This can be seen obvious in Chapter 3 (Requirement Analysis)
where interface, or boundary, classes are within the class diagram of the prototype. Software
architecture of the CPF prototype, in this chapter, has also emphasized the user interface issue
considering the user interface as a separate layer of the architecture that has to be separated from the
other layers of the architecture.
4.5.1 Web Design
The CPF prototype user interface is web-based, therefore, it should follow web design standards.
Web design is defined by [10] as “The process by which a web designer, working with the web’s
specifications, makes decisions about how web components will accomplish the web’s objectives”.
The following are the key issues, that have to be achieved, in web design as described by [10]:
• Create a consistent look and feel for the web;
• Separate information into page-sized chunks;
• Use links to connect pages along the routes of use and user thinking.
The website of the CPF is organized into four main pages, as shown in Figure 4.7, which are the
CPF Home Page (login page), the Player’s Home Page and the Administrator’s (Admin) Home
Page. This structure allows user security access to be built into the design. The user is required to
login using the CPF Home Page, his account is validated and then he will be redirected to the
appropriate home page according to the access role he has been given. For example, a player will be
redirected to the Player’s Home Page. Every main page consists of sections (sub pages), and inside
each section there are different tasks the user may choose to perform. Consistent look and feel has
been maintained into all pages and sections, although, contents of the pages vary according to the
type of the user. Figure 4.8 shows screen shots of Player’s Home Page sections. More explanation
of the website will be given in Chapter 5 (Prototype Implementation).
CPF Home Page
Player’s Coach’s Admin’s

Home Page Home Page Home Page
Figure 4.7 Main Components of the CPF Website
Figure 4.8 Screen Shots of Two Sections from Player’s Home Page
Chapter 5: Prototype Implementation
This chapter describes the creation of the software system. The software is distributed between
three separate layers, as explained in section 4.3, which are the database, the application program
(the business code) and the user interface. The chapter starts by describing database creation. Then
it will describe the construction of the website including the program code (the ASP scripting). At
the end, the chapter gives a brief description about user input validation mechanism built into the
CPF prototype. Please note that only code segments are demonstrated in this report. The full code is
quite long and contains large amounts of embedded HTML text.
5.1 Database Creation
The database is created under Microsoft SQL Server. The database creation implements the
relational model described in section 4.4.4. The SQL script for creating the database can be found in
Appendix D, Section D.6.
5.2 Website Construction
The website contains both the user interface and the program code. It is organized into ASP files
with “asp” extension. The ASP files contain embedded HTML text in a way that both ASP codes
and HTML text exist inside one container which is the ASP file; this is to maintain the dynamics of
the pages and the security of access. Figure 5.1 shows the website structure of the CPF prototype.
Figure 5.1 The Website Dynamic Structure of the CPF

5.2.1 Controlling Appearance and Access
The function of the ASP file connection.asp is to unify the appearance of text and links on all web
pages. It also controls the access to the different web pages, and connects the users to the database
as well. All web pages reference this file as a header information file;

The connection.asp file consists of the following:

• A style sheet design to initialize font and link behaviors of web pages;
<style>
A:link, A:active { text-decoration : none;
color : 008080#;
background : transparent;
}
A:visited { color : 008080#;
text-decoration : none;
}
A:hover { color : white;
background : 008080#;
}
</style>
• A connection object that connects the users to the CPF database;

<%
Set conn = Server.CreateObject("adodb.connection")
conn.ConnectionTimeout = 0
Conn.ConnectionString = "Provider=SQLOLEDB.1;" & _
"Persist Security Info=False;" & _
"User ID=******;" & _
"Password =******;" & _
"Initial Catalog=CPF;" & _
"Data Source=CSMS2"
• A sub-routine that controls users’ access to the web pages;

'This sub program verifys accessability of users to a specific page
Sub VerifyAccess (p_accessrole)
if session("accessrole") <> p_accessrole then
Response.Write "<b> Access to this page is denied. Please contact the web site administrator! </b>"
Response.End
end if
end sub
%>
5.2.2 Signing-in to the CPF
In order to use the CPF prototype, the user is required to sign (log) into the system. His user name
should have been created first by the system administrator. The sign-in page, default.asp, is shown
in Figure 5.2.
Figure 5.2 The Start-up (Sign-in) Page of the CPF Prototype
The page is to be used as the start-up page of the CPF prototype. After the user has supplied his
username and password, the system verifies that his user record exists into the database, and that
username and password match. After that, the system redirects the user to the appropriate web page
according to his access role. There are four different types of access roles, which are:
• PLAYER: if the user is a player;
• COACH: if the user is a coach;
• TUTOR: if the user is an academic tutor; and
• ADMIN: if the user is the system administrator.
The code segment of the sign-in process can be found in Appendix F, Section F.1.
5.2.3 CPF System Administration
Access to the CPF is controlled by the system administrator’s home page which is admin.asp.
System administrator can create a new user using useraccount.asp or alter access information of an
existing user using updateuser.asp. Both options are shown in Figure 5.3 below.
Figure 5.3 System Administration Page Options
5.2.4 Scoring against Cricketing Skills
Players are required to record their progress of cricketing skills by scoring. They do the scoring
periodically say every week, or after every cricket match or a training programme. The script that
enables them to score is score.asp. The script reads the standard cricketing skills, as defined by the
UCCE (see the document sample in Appendix E, Section E.3), from the database and displays them
on a web page prompting the players to enter a score value against each listed skill. Skills are
displayed according to the role they belong to and to their type (skills categorization has already
been described in Section 4.4.3). Scores are defined within the range 1-10 (poor-excellent). A score
of 10 means player reached a maximum level of excellence on the particular skill. Figure 5.4 shows
a screen shot of a scoring scenario. The scoring process workflow of score.asp script is described
briefly by the following lines:
1. Retrieve the set of skills according to the given role and skill type in an HTML form (see
Appendix F, Section F.2 for the code segment).
2. Read and save score values, and move to the next set of skills (see Appendix F, Section F.3
for the code segment).
Figure 5.4 Screen Shot of a Scoring Scenario
5.2.5 Commenting on Player’s Performance
The coach should also be able to contribute to the development of his players’ skills. After watching
the player physically or even after looking into his performance record, the coach can enter text
comments as a feedback about the player’s performance progress. These comments will be stored as
a log history, with date stamp, into the database so that both the coach and the player can monitor
the improvement of the player’s performance (as described in the next section). The script
comment.asp is used to record the comments (see Figure 5.5) and can be accessed through the
interface script progress.asp. First, the progress.asp script displays the players’ list to enable the
coach to select one player at a time. Pressing “Text Comments” button allocated underneath the
player’s list invokes the comment.asp script that pops up a text-area box for comments entry. The
following is the code segment of recording the text comments;
<%if (Request.Form("add") <> "") then%>
<form method="POST" action="comment.asp">
<p><textarea rows="13" name="commenttext" cols="58"></textarea></p>
<p><input type="submit" value="Save Comments" name="save">
<input type="reset" value="Clear Text" name="B2"></p>
</form>
<%end if
' add new comments to DB

if (Request.Form("commenttext") <> "") then
my_text = Server.HTMLencode(Request.Form("commenttext"))
my_sql = "insert into comment (commenttext, coachid, playerid, entrydate) values('"
my_sql = my_sql & my_text & "'," & my_coachid & "," & my_playerid & ",'" & date() & "')"
conn.Execute my_sql
end if%>
Figure 5.5 Screen Shot of Entering Text Comments
5.2.6 Monitoring Progress
The coach and the player can both monitor the player’s performance progress. Monitoring the
progress means observing the development/improvement of the player’s skills. In other words, it
means viewing the text comments log and the history of the accumulated scores using comment.asp
and summary.asp scripts respectively. Both scripts are accessed through the interface script
progress.asp shown in Figure 5.6. The players do not see the players’ list, and will not be prompted
to enter text comments when they access their progress records. Instead, they will be shown
different options so a player may only access his own progress records (see Figure 5.7). Windows
of comment and summary are viewed side by side so that the contents of the two progress files can
be compared and contrasted.
Text comments log can be viewed simply by pressing “Text Comments” button. A complete log of
comments will be displayed by date of entry. The following is the code segment of viewing text
comments log:
my_sql = "select entrydate, commenttext from comment "
my_sql = my_sql & "where coachid = " & my_coachid
my_sql = my_sql & " and playerid = " & my_playerid
my_sql = my_sql & " order by commentid desc"
rs.Source = my_sql
rs.Open%>
<font face="Arial" color="#008080"><b><u>Progress Record of <%=my_playername%> </u></b><br><br>
<table border="0" width="700">
<%while not rs.EOF
my_entrydate = day(rs("entrydate")) & "/" & month(rs("entrydate")) & "/" & year(rs("entrydate"))%>
<tr>
<td width="100" valign="top"> <font face="Arial" color="#008080"><b> <%=my_entrydate%> </b></font> </td>
<td width="600" valign="top"> <font face="Arial" color="#008080"> <%=rs("commenttext")%></font></td>
<tr><td></td><td></td></tr>
</tr>
<%rs.MoveNext
wend
rs.Close%>
</table>
Similarly, progress summary can be viewed by pressing “Progress Summary” button underneath
players’ list. It is based on a, from-to, date period that is provided at the top of the page. The
summary page contains the following sections:
• An HTML form that inputs the, “From” and “To”, date period (see Appendix F, Section F.4
for the code segment);
• A statistical summary of average score displayed by scoring date (see Appendix F, Section
F.5 for the code segment);
• A line-chart graph plotting the average score by date∗ (see Appendix F, Section F.6 for the
code segment);
∗
The JavaScript library, glib.js, used to draw the graph is a freeware provided by http://siva.cc.hirosaki-u.ac.jp/usr/koyama/glib.
It is a modified version of Netscape JavaScript graph builder graph.js (http://developer.netscape.com/docs/technote/javascript/graph ).
• A statistical summary of the overall average score across the date period (see Appendix F,
Section F.7 for the code segment).
Figure 5.6 Screen Shot of Monitoring Progress (Coach Options)
Figure 5.7 Screen Shot of Monitoring Progress (Players Options)

5.2.7 Managing Questionnaires
The player, the coach and the academic tutor can use the questionnaire facility provided in the CPF
prototype. The player may only answer the questionnaires that are made available for him by his
coach or his tutor, whereas, the coach and the tutor are responsible for generating and maintaining
their own questionnaires. The coach and the tutor should also be able to view (collect) the
questionnaires that have been answered by their players (or tutees). Table 5.1 lists the different
possible actions that can be performed on questionnaires, and who is responsible for performing
each particular action. Figure 5.8 shows the questionnaire.asp main page with the different
actions/options accessible to the coach.
Action Script Name User Responsible

Generate Questionnaire questionnaire.asp Coach, Tutor
Modify Questionnaire questionnaire.asp Coach, Tutor
Delete Questionnaire questionnaire.asp Coach, Tutor
Answer Questionnaire qanswer.asp Player
View Answered Questionnaire qview.asp Coach, Tutor
Table 5.1 Actions Performed on Questionnaires
Figure 5.8 Screen Shot of questionnaire.asp Page
The following lines describe the actions listed in Table 5.1. The tutor can also do all tasks that can
be done by the coach:
Generate Questionnaire: Questionnaire consists of header and body (see Figure 5.9). The header
contains information like questionnaire title, author, creation date, etc. The coach is to enter the title
and has to decide whether to make the questionnaire available online to his players or not. Other
information like author and creation date is to be stored internally by the system. After header
information has been filled, coach will be prompted to enter questionnaire body information. Body
information is actually the set of questions the questionnaire may contain. Questions are to be
entered one by one, each per screen. Pressing “Proceed” button will save the current question and
leads to the next one, whereas, pressing “Finish and Exit” button will save the current question, if
text area is not empty, and ends questionnaire generation process. The code segments for generating
a new questionnaire can be found in Appendix F, Section F.8.
Figure 5.9 Screen Shots of Questionnaire Generation Steps
Modify Questionnaire: Questionnaire modification takes two steps, modification of the current
structure (e.g. modifying header and body information) and adding more questions to the existing
structure. This is shown in figure 5.10. Modification of the current structure includes editing header
information, and editing or deleting existing questions. Removing text from question text area will
delete the question from the structure, after “Save Changes” button has been pressed, and the
questions order will be re-arranged. Adding more questions is actually the same process, described
above, of entering questions one by one. The code segment of questionnaire modification can be
found in Appendix F, Section F.9.
Figure 5.10 Screen Shots of Questionnaire Modification Steps
Delete Questionnaire: Deleting a questionnaire is a simple process. The coach needs to select the
questionnaire he wants to delete from the list provided and press “Delete” button. An alert message
will pop-up to confirm the deletion. The scenario is shown in Figure 5.11. The code segment of
questionnaire deletion follows;
' 1. Deleting Questionnaire
if (Request("edit") = 1 and Request.Form("del") = "Delete") then
conn.BeginTrans
my_sql = "delete from player_questionnaire where qid = " & Request.Form("qid")
conn.Execute my_sql
my_sql = "delete from questionnaire_body where qid = " & Request.Form("qid")
conn.Execute my_sql
my_sql = "delete from questionnaire where qid = " & Request.Form("qid")
conn.Execute my_sql
conn.CommitTrans
end if
As the code segment above shows, all questionnaire components are deleted including the answers,
if any, to maintain data consistency. Answers are stored in PLAYER_QUESTIONNAIRE table.
Figure 5.11 Screen Shot of Questionnaire Deletion Scenario

Answer Questionnaire: Answering of questionnaire is to be done by the player through the script
qanwer.asp. A list of questionnaires is displayed to the player so that he can select the questionnaire
he wishes to answer. Player is then get a listing of all questions of the questionnaire, and he will be
required to fill-in the text area, below each question, with his answers. If an answer text area is left
empty, then the answer for the corresponding question will not be stored and will be treated as not
answered. The scenario is shown in Figure 5.12.
Figure 5.12 Screen Shots of Questionnaire Answering Scenario
View Answered Questionnaire: A questionnaire, after answered by the players, is to be collected

by the coach (or perhaps by the academic tutor if he has created it). By using the qview.asp script,
the coach would be able to view any answered questionnaire. After selecting a questionnaire, the
questions and the answers of that questionnaire will be viewed on a new window. The answers will
be displayed as one screen per player. The coach can scroll to the different players by clicking on
“Next >>” that allows him to view the next set of a player’s answers. The scenario is shown in
Figure 5.13.
Figure 5.13 Screen Shot of Viewing Answered Questionnaire Scenario

5.3 User Input Validation
Validating user input is an essential step to be done before submitting user’s input data to the
database. In the CPF prototype, input data are even verified before forms are posted to the ASP
scripts. In other words, input data are verified in the client side. Client side scripting, therefore, has
been implemented in the CPF using JavaScript. JavaScript can perform the preliminary check of the
data inputted to HTML forms. It can also give immediate feedback to the user like displaying pop-
up alert messages.
Input data in the CPF are checked against null values and against incorrect formats. Further check is
to be done at the server side using ASP if a contact to the database is required to perform the check.
Figure 5.14 shows an example of user’s input validation within two stages (e.g. client side and
server side). In the first (left) scenario it ensures that the “password” to be entered must be at least 6
characters of length, while in the second one (right) it verifies that the user to be created is a new
user (i.e. “user name” must not be already in the database). The code segments of the two scenarios
are as following;
1. The JavaScript code segment of the first scenario;
if (theForm.password.value.length < 6)
{
alert("Please enter at least 6 characters in the \"password\" field”.);
theForm.password.focus();
return false;
}
2. The ASP code segment of the second scenario;

'Check to see if this userid is already in use
rs.Source = "Select userid from useraccount where userid = '" & my_id"'" &
rs.Open
if not rs.EOF then
userfound = 1
end if
rs.Close
set rs = nothing
if (Request.Form("userid") <> "" and userfound <> 1) then%>
<font color="#008080" face="Arial"><br><b>User <%=Request.Form("userid")%> has been created! </b><br></font>
<% elseif (userfound = 1) then%>
<font color="red" face="Arial"><br><b>Error: User <%=Request.Form("userid")%> already exists! </b><br></font>
<% end if %>
Figure 5.14 Screen shots of User’s Input Validation Scenarios

Chapter 6: Evaluation
This chapter describes the evaluation of the project. It begins with a discussion on how the
objectives and the user requirements have been met. It then describes the outcome of the user
acceptance test that has been performed by the users themselves. The chapter, finally, raises some
issues and arrived at a couple of suggestions for future development.
6.1 Meeting the Objectives
Objective 1: To use the Internet to allow the players maintain their own cricket progress files.
The players could now login to the system and perform various tasks of maintaining their progress
file.
Objective 2: To maintain the players’ various skills and achievement records into a database
system so that their progress can be monitored by themselves and by their coach.
The database system has been created to enable the players to store all various skills and
achievement records (e.g. Scores). The database has also been tested with sample data, and that all
different kinds of progress records could be monitored by the players and their coach.
Objective 3: To improve the way the cricket progress file is being handled, and eliminate the need
for the coach to keep manual records.
This is now obvious, as the CPF system could be used indeed, and that it should alter the manual
procedures.
Objective 4: To facilitate the coach’s job by letting the players keep their own performance records
electronically and make them available to him at anytime.
This has already been addressed by objectives 1 and 2 above.
Objective 5: To provide a working prototype that would help in creating a standard cricket
progress file.
The CPF prototype is functioning and it has been created according to the user needs. Therefore, it
should lead to the creation of a standard cricket progress file system.
Furthermore, the client feedback letter in Appendix G, Section G.1, reflects the user satisfaction on
what has been achieved. I therefore conclude that all the objectives have been met.
6.2 Meeting the Requirements
All user requirements have been incorporated into the CPF prototype. A common way to verify this
is to use test cases. Test cases can be derived from the use cases and they are used to verify user
requirements (see [6], [13] and [14]). Accordingly, I shall match the use cases of the CPF use case
diagram, described in Chapter 3, with the various functionalities provided by the prototype. The
following figures demonstrate this match and insures that all user requirements have been met. The
figures are self-explanatory and do not require further explanation.
Fill-in Sc o res of Cri ck et ing S ki ll s
View Cric k eting Progres s

Play er
S umm ary
Ans wer Q ues t ionn aire
Figure 6.1 Meeting Player’s Requirements

Enter Text Comments about

Player's Progress
Coach
View Cricketing Progress

Summary
View/Collect Answered
Qustionnaire
<<extend>> Generate Questionnaire
<<extend>> <<extend>>
Delete Questionnaire Modify Questionnaire
Figure 6.2 Meeting Coach’s Requirements
View/Collect Answered
Qustionnaire
Academic Tutor
<<extend>> Generate Questionnaire
<<extend>> <<extend>>
Delete Questionnaire Modify Questionnaire
Figure 6.3 Meeting Academic Tutor’s Requirements

Alter User Account Information
<<extend>>
<<include>>
Create User Account AssignAccess Role

System
Administrator
Figure 6.4 Meeting System Administrator’s Requirements
6.3 User Acceptance Test
User acceptance test has been done to verify that the prototype meets the user’s requirements, goals
and expectations, and to capture any bugs that might persist. All types of the CPF users were
involved in the test including the system administrator, the coach, a player and an academic tutor.
The outcome of the test is shown in Appendix G, Section G.2. The following lines summarize the
outcome of the test and the actions that have been taken as a result of the outcome:
• All user accounts of the testers were successfully created by the system administrator before
the beginning of the test.
• The testers were able to do all different tasks happily and efficiently.
• All user’s requirements have been implemented, however, the coach asked for an additional
feature that should enable him to view the individual score values of his players. The
prototype, at the moment, provides an average summary of the scores and plots skills
development as a line-graph but there is no option to view the individual score values. This
option has been considered and it could be added in the future.
• Some skill names were spelt incorrectly. These are database entries and they have been
corrected.
• There were a few bugs encountered during the test, which are:
o In progress summary (comments), general comments on player’s skills do not view
to the coach. The bug has been identified and fixed.
o In questionnaires (answering), the player gets an error message when submitting
long answers. The reason was the length of the database field, that holds the answers,
was not satisfactory. Field length has been resized and the problem has been sorted
during the test. The player could then resubmit his answers successfully.
o In questionnaires (modification), the tutor was not supposed to see the questionnaires
generated by other users. This bug has also been identified and fixed.
6.4 Suggestions for Further Improvement
The evaluation has also raised some issues that should be considered in the future development. The
following lines address these issues while suggesting further improvement:
• While it is desirable to adopt Microsoft development tools to implement an iterative

prototype, the resulting end-product will be hardware/software dependent. The CPF
application is limited to run under Microsoft platform only.
• User errors in the CPF prototype are minimized and handled on the application (business
code) level. Unfortunately, the ASP version running in the School of Computing IIS Server
is 2.0 which does not have the facility to handle system errors and/or server errors
appropriately. The solution of handling system and server errors has already been
incorporated in the connection.asp script file. The line codes for handling such errors has
been remarked (commented). The remark signs must not be removed unless ASP is
upgraded to version 3.0 or to the latest release which is ASP.NET. The full listing of
connection.asp script can be found in Appendix F, Section F.10.
• The client has to find a system administrator that has the capability of maintaining and
upgrading the system. Knowledge of SQL Server and ASP is demanded.
• The client has to find an ISP who can host the system. This issue has been raised before the
development has started and still has not been resolved yet. A commercial ISP host was
recommended (see Section 1.5). List of the top ASP/SQL Server hosts can be found at:
http://www.webhostsearch.info/Search/ASPHosting.asp.
• Iterative prototyping requires rapid development. The use of powerful web development
tools such as “Dreamweaver MX” (http://www.macromedia.com/software/dreamweaver/) to
speed up the process is highly recommended.
Chapter 7: Conclusion
This report has started with Chapter 1, which has explored the problem domain and the overall
technical evaluation of the hardware/software tools that might be used to implement the proposed
solution. Chapters 2 and 3 explained how user requirements have been gathered and analyzed to
give more understanding to the problem. Chapter 3 has also suggested a conceptual solution to the
problem. Based on the outcome of Chapter 3, Chapter 4 has explained how the different system
components could be derived from the conceptual solution and fitted within a system architecture
that is applicable to the web environment. It has also described the issues related to HCI and web
design. Chapter 5 explained how the different system design components have been converted into
software components that formed the prototype. The chapter has also featured the various facilities
provided by the prototype. Finally, in Chapter 6, the project has been evaluated to see if it has
achieved users’ objectives and met their needs. It has also addressed the issues that should be
considered in the future development.
The project has been started with a little hope of getting feasible user requirements. It was under-
specified as quoted by my former supervisor, Peter Mott (see interim report feedback in Appendix
C). The situation was even worse, as there has been no similar application can be found on the Net.
What might a cricket progress file contain? Was the hard question to be answered.
The obvious answer to the above question was prototyping. After the users saw the first iteration of
the prototype, they could recognize what they wanted to keep in this progress file. The actual
requirements then could be extracted and gathered as the iterative development went on. The
experience showed that prototyping is a very effective technique to get user attention and
involvement in the project. One thing I would like to emphasize is that prototyping that lacks user
commitment is like a waste of time. I was fortunate to find my client, in a few times, during the
summer period to discuss the project.
The prototype developed is an evolutionary prototype. There are advantages as well as drawbacks
of the evolutionary prototypes. [12] suggests that evolutionary prototypes save efforts as no code is
discarded; however, they may not produce maintainable systems, as the code structure may be poor.
I also argue with this and just want to make it certain to my client that the code has been revisited
many times and some of the modules (ASP scripts) have been totally re-written to tackle such a
drawback.
Finally, my experience of this project reflected that documenting the prototype was the hardest of
the whole bit. The prototype keeps changing and so is the report. As a mater of fact, the report
shows an incremental evolution of the requirements where many facts have been discovered in later
stages (perhaps in the implementation stage). This could give the evidence that the prototyping
approach has been adopted successfully.
References
[1] David M. Kroenke (c2002), Database processing : “fundamentals, design & implementation”,
Prentice Hall.
[2] http://www.powerasp.com/ [11/04/2002 7:30 PM]
[3] http://www.csis1.leeds.ac.uk/dbmodules/module_menu.asp?module=DB32 [11/04/2002 9:32
PM]
[4] http://msdn.microsoft.com/library/ [11/04/2002 11:12 PM]
[5] http://www.nicats.ac.uk/using/related.htm [19/06/2002 9:15 PM]
[6] Simon Bennett, Steve McRobb and Ray Farmer (2002), Object-Oriented Systems Analysis and
Design Using UML, McGraw Hill.
[7] Simon Bennett, John Skelton and Ken Lunn (2001), Schaum’s Outlines of UML, McGraw Hill.
[8] Thomas Connolly and Carolyn Begg (2002), Database Systems: “A Practical Approach to
Design, Implementation, and Management”, Addison Wesley.
[9] Lydia Lau (2001), COMP5050 Information Modeling (Lecture Handouts), University of Leeds-
School of Computing.
[10] http://www.december.com/web/develop/design.html [28/07/2002 7:30 PM]
[11] http://www.15seconds.com/faq/IIS%203.0/471.htm [23/08/2002 9:10 PM]
[12] A. G. Sutcliffe (1995), Human-Computer Interface Design, Macmillan press LTD.
[13] Edward Kit (1995), Software Testing in the Real World: “Improving the Process”, Addison
Wesley.
[14] Philippe Kruchten (1998), The Rational Unified Process: “An Introduction”, Addison Wesley.
Appendix A: Reflection upon the Project Experience
This project has made a significant contribution to my knowledge in Information Systems and/or
Information Technology in general. In fact, it is my first time developing an Information System
from scratch going through all system development life cycle phases, as well as dealing with
external people (i.e. people outside my organization). I could really achieve my strategy that I have
put into my mind before selecting my MSc. project, which was to select a project that can put the
chunks of knowledge I gained from the MSc. Information System modules into one container and
hence apply it, comprehensively, in practice.
In brief, the following are the set of benefits, skills and achievements I gained from this experience:
• Comprehensive knowledge of systems analysis, design and implementation skills.
• Knowledge of process and data modeling in both object oriented method and E-R technique.
• Knowledge of prototyping through the iterative development and user involvement.
• Skills of web development, particularly through learning and applying ASP in a professional
way.
• Solid knowledge of research and academic writing gained from the books I have consulted
as well as from the comments and the recommendations of my supervisors.
• Skills of professionalism gained from dealing with an external organization.
• Skills of communication, which is the key skill for the analyst, through the various meetings
and interviews I have conducted with my client.
• Skill of project, time and resources management gained from project planning task.
• Knowledge of politics. I believe that projects that have unclear set of requirements and
conflict of interests among stakeholders require politics. Although, I have never been
involved in such case before, I am quite proud of bringing this project to success.
• And last, but not least, learning cricket laws and knowing the necessary cricketing skills.
Who can believe that, before this project, I had never knew what on the earth is “Batting” or
“Wicket Keeping”?!
Appendix B: Objectives, Deliverables and Agreed Marking Scheme

School of Computing, University of Leeds
MSC PROJECT OBJECTIVES AND DELIVERABLES
This form must be completed by the student, with the agreement of the supervisor of each project, and submitted to the
MSc project co-ordinator (Mrs A. Roberts) via CSO by 21st March 2002. A copy should be given to the supervisor and
a copy retained by the student. Amendments to the agreed objectives and deliverables may be made by agreement
between the student and the supervisor during the project. Any such revision should be noted on this form. At the end of
the project, a copy of this form must be included in the Project Report as an Appendix.
Student: Al Hussaini, Yousuf Khamis
Programme of Study: MSc Information Systems
Supervisor: Peter Mott
Title of project: Web Development of a Cricket Progress File
External Organisation*: Bradford/Leeds Centre for Cricketing Excellence
*(if applicable)
AGREED MARKING SCHEME
Understand the Produce a Evaluation Write -Up Appendix A TOTAL

Problem Solution *
%
20 40 20 15 5 100
* This category includes Professionalism
OVERALL OBJECTIVES:
• To use WWW to allow players to maintain their own sports progress reports.
• To produce online progress forms.
• To develop existing forms as necessary.
MINIMUM REQUIRMENTS:
3. To produce a working system available over the Internet.
SOFTWARE AND HARDWARE RESOURCES REQUIRED:
DELIVERABLE(s):
1. A project report.
2. On-line database system with web front-end.
Signature of student: Date:
Signature of supervisor: Date:

Appendix C: A Copy of the Interim Report Header Sheet

Appendix D: Requirement Specifications Report
In this appendix, user and system requirements are brought together and maintained in one report to
act as a reference.
D.1 Problem Definition
D.1.1 Problem Statement

The Bradford/Leeds UCCE wants to improve the way of monitoring the players’ cricket progress
file by the implementation of a database solution with a web front-end.
D.1.2 Vision Statement

Help players mature faster to become excellent cricketers.
D.1.3 Objectives
• To use the Internet to allow the players maintain their own cricket progress files.
• To maintain the players’ various skills and achievement records into a database system so
that their progress can be monitored by themselves and by their coach.
• To improve the way the cricket progress file is being handled, and eliminate the need for the
coach to keep manual records.
• To facilitate the coach’s job by letting the players keep their own performance records
electronically and make them available to him at anytime.
• To provide a working prototype that would help in creating a standard cricket progress file.
D.2 Requirements
D.2.1 Stakeholders
• Player
• Coach
• Academic Tutor
• System Administrator
D.2.2 Functional Requirements from User’s Perspective

• Player’s Personal Profile
- Player should be able to alter his personal information like password, name, institution,
coach, tutor, etc.
• Player’s Performance Record
- Player should be able to fill-in scores about his cricketing skills. The skills are defined as
per the “Wagon Wheels” provided by the UCCE (see Appendix E, Section E.3). The
scores are defined as 1-10 (poor-excellent) range.
- Coach should be able to enter text comments on a particular skill of his player(s).
- Player should be able to read the text-comments feedback of his coach on a particular
skill or in general.
• Player’s Progress
- Player should be able to view a statistical average summary, in a given period of time, of
his skills development. The summary is to be supported by a line graph.
- Coach should also be able to view a statistical average summary, in a given period of
time, of the skills of his players. The summary is to be supported by a line graph.
• Questionnaires
- Coach should be able to generate questionnaires and make them available to his players
on-line to be answered by them. He should also be able to view/collect the answered
questionnaire per each player.
- Academic tutor should be able to generate questionnaires and make them available to his
tutees (students) on-line to be answered by them. He should also be able to view/collect
the answered questionnaire per each player
- Players should be able to answer questionnaires provided by their coach and/or their
academic tutor. Questionnaires have varying purpose such like evaluating a training
programme or even self evaluation after a cricket match, on one hand. On the other
hand, questionnaires have academic purpose in a way that players are required to answer
a set of questions of how their cricket progress has contributed to their academic
achievement for a given period of time (a semester or an academic year for instance).
• System Administration
- System Administrator should be able to create user accounts on the system.
- System Administrator should be able to assign access roles to the users of the system.
- System Administrator should be able to alter user access information.
D.2.3 Security Requirements

• Player is allowed to access his own files/data only.
• Coach is allowed to access his players’ files/data only.
• Academic Tutor is allowed to access his tutees’ files/data only.
• System Administrator has unlimited access.
D.2.4 Technical Requirements

• The system is to be a database system with web interface front-end.
• The database is to be developed under SQL Server, and the scripting language to be used for
the web development is ASP.
• No decision made yet by the client about where to host the system.
D.3 Use Case Requirement Model
D.3.1 Use Case Diagram
E nt e r Te x t C o m m e n ts a b o u t
F ill-in S c o res o f C ric k e t in g S k ills
P la y e r's P rog r e s s
Coac h
V ie w C ri c k e t in g P ro g re s s
P la y e r
S um m ar y V ie w /C o lle c t A n s w e re d
Q u s t io n n a ire
A c a d e m ic Tu t o r
A n s w e r Q u e s ti on n a ire < < e x t en d > > G e n e ra t e Q u e s t io n n a ire
< < e x te n d > > < < ex t e n d> >
A lt e r U s e r A c c o u n t Inform a t io n D e le t e Q u e s ti on n a ire M o d ify Q u e s t io n n a ire
< < extend> >
< < in c l ud e > >
C re a t e U s e r A c c o u n t A s s ig n Ac c e s s R o l e
S y s t em
A d m in is t ra t o r
D.3.2 Use Case Description
Use Case Actor(s) Description Possible

Name Involved Candidate
Classes
1. Fill-in Player Player records his cricketing skills regularly Player, Skill,
Scores of (once a week or so). He has to fill-in/select the Score
Cricketing score against each particular listed skill. The
Skills score value is defined in the range 1-10.
2. View Player, Coach Player can monitor his progress of skills Player, Coach,
Cricketing development by selecting the option that should Skill,
Progress provide various types of statistical summaries. Summary
Summary Coach can also do so and view summaries of his
own players.
3. Enter Text Coach Coach can provide feedback regarding the Coach, Player,
Comments development progress of his player(s) by Skill,
about Player’s entering a text comment against his cricketing Comment
Progress skills or in general.
4. Generate Coach Coach can create new questionnaire by Coach,
Questionnaire navigating into the questionnaire feature that will Questionnaire
be provided by the system and selecting “new
questionnaire” option.
5. Modify Coach Coach can modify existing questionnaires, Coach,
Questionnaire created by him, by navigating into the Questionnaire
questionnaire feature that will be provided by the
system and selecting “modify questionnaire”
option.
6. Delete Coach Coach can delete existing questionnaires, created Coach,
Questionnaire by him, by navigating into the questionnaire Questionnaire
feature that will be provided by the system and
selecting “delete questionnaire” option.
7. Answer Player Player is to answer questionnaires generated by Player, Coach,
Questionnaire his coach and/or tutor by entering text of Questionnaire
answers against each question of the
questionnaire.
8. Coach Coach can view/collect answered Coach,
View/Collect questionnaire(s) that should be made available to Questionnaire
Answered him whenever a questionnaire, created by him,
Questionnaire has been answered.
9. Create User System System Administrator is responsible for creating System
Account Administrator accounts for any user of the system. He should Administrator,
type a user Id, a user name and a password for User Account
the user to be created in the interface that will be
provided by the system.
10. Assign System System Administrator is to assign access role for System
Access Role Administrator the user he creates according to the type of user. Administrator
11. Modify System System Administrator can modify any user System
User Account Administrator account information by viewing existing user Administrator,
Information account and make necessary modifications. User Account
D.4 Analysis and Design Model
D.4.1 Interaction Diagrams
: CP FHom eP age : Us erA ccount : P layerHomePage : S kill : Sc ore : P la y erDB

: Player
s ignIn( )
getAcc ountDetails( )
authorize( )
display ("URL" )
lis t Sk ill( )
get P lay erID( )
fill-inSc ore( )
record Sc ore( )
Figure D.1 Fill-in Scores of Cricketing Skills
: CP FHom e Pa ge : UserA ccount : Coac hHom eP age : P la yerDB : S kill : S co re : S umm ary
: Coach
signIn( )
getA ccountDetails( )
authorize( )
dis p lay("URL")
viewS um m ary( )
displayS um m ary ( )
getP layerID( )
getS c ore( )
listS kill( )
Figure D.2 View Cricketing Progress Summary

: CP FHom eP age : Us erA cc ount : Coac hHom eP age : Com m ent : P la y erDB
: Coach
s ignIn( )
getA c c ountDetails ( )
authoriz e( )
display("URL")
enterTex tCom ment( )
getP lay erID( )
addTextCom m ent( )
Figure D.3 Enter Text Comments about Player’s Progress
: C P F H om eP age : U s e rA c c o u n t : C o a c hH om e P a g e : Q u e s t io n n a i re
: C oac h
s ig n In ( )
g e t A c c o u n t D e t a il s ( )
a u t h o r iz e ( )
d is p la y (" UR L " )
g en e r a t e Q u e s t io nn a ire ( )
c r e a t e N e w Q u e s t io n n a ire ( )
a d d Q u e s tio n ( )
Figure D.4 Generate Questionnaire

: C P F H om eP a ge : U s erA c c ount : P la y erH om eP a ge : Q ues t ionn aire

: P la y er
s ign In ( )
get A c c o unt D et ails ( )
auth oriz e( )
dis p lay ( "U R L" )
an s w erQ ues tion naire ( )
get D et ails ( )
ad dA ns w er( )
Figure D.5 Answer Questionnaire
: C P F Ho m eP a ge : U s e rA c c o u n t : Coac hHom eP age : Q u e s t i o n n a i re : P la y e rD B

: C o ac h
s i g n In ( )
g e t A c c o u n t D e t a i ls ( )
a u t h o r iz e ( )
d i s p l a y (" U R L " )
c o ll e c t Q u e s t i o n n a i re ( )
g etD e tails ( )
g e t P l a y e rID ( )
Figure D.6 View/Collect Answered Questionnaire

: CP F Hom eP age : A dm inH om eP age : U s erA c c ount

: S y s tem
A dm inis trator
s ignIn( )
getA c c ountD etails ( )
authoriz e( )
dis play (" UR L" )
c reateU s erA c c ount( )
addUs er( )
Figure D.7 Create User Account

D.4.2 Activity Diagrams
S ign In S ign In
A uthoriz e A uthorize
[ Invalid u serna me/pas s wor d ] [ Invalid us ernam e/pas sword ]
[ V alid us ernam e/pas s word ] [ V alid usernam e/pas s word ]
Dis play P lay er

Hom e P age Dis play Coac h
Hom e P age
S elec t a P lay er
List S k i ll
L ist S k i ll
S core against
the S k ill
[ Mor e s k il ls t o l is t ] Get the S c ore
[ No m ore sk ills to lis t ]

[ M ore ski ll s to lis t ]
Rec ord S c ores
[ No m ore s k ills to lis t ]
V iew S um m ary
Figure D.8 Fill-in Scores of Cricketing Skills Figure D.9 View Cricketing Progress Summary
S ign In
S ign In
A uthoriz e
A uthorize
[ Invalid usernam e/pass word ]
[ Invalid us ernam e/pas s word ]
[ V alid us ernam e/pas s word ]
[ V ali d usernam e/p as s word ]
Dis play Coach

Hom e P age Dis play Coac h
Hom e Page
S elec t P lay er E nter Ques tionnaire

Header Inform ation
E nter Tex t E nter a

Com m ent Ques tion
S ave C om me nt
[ M ore ques tions to enter ]
[ No m o re ques tions to enter ]

[ M ore play ers to selec t ]
S ave and E x it
[ No m ore play ers to s elec t ]
Figure D.10 Enter Text Comments about Figure D.11 Generate Questionnaire
Player’s Progress
Sign In S ign In
Authorize A uthoriz e
[ Invalid username/password ] [ Invalid usernam e/pas s word ]
[ Valid userna me/password ] [ V alid us ernam e/pas s word ]
Displ ay Coa c h
Display Player Hom e P age
Home Page
Se lect a Qu es tionnaire
Select a Questionnaire
Li s t P layer
List Questi on
[ More questions to list ] Lis t A ns wer
[ No more questions to list ]

Enter Answer [ M ore answers to lis t ]
[ No m ore ans wers to lis t ]
[ More questions t o answer ] [ M ore play ers to lis t ]
[ No m ore play ers to list ]

[ No more questions t o answer ]
Save and Exit
Figure D.12 Answer Questionnaire Figure D.13 View/Collect Answered

Questionnaire
S ign In
A uthorize
[ Invali d us ernam e /pas s word ]
[ V alid us ernam e/pas s word ]
Dis p lay A dm in
Hom e P age
E nter U s er A c count
Inform ati on
Create Us er Record
Figure D.14 Create User Account
D.5 Data Dictionary
The following is the description of tables and attributes of the database. Underlined attributes are
the primary key(s) of the table, while attributes printed in Italic face are the foreign key(s).
Attributes that are underlined and printed in Italic face are primary and foreign keys at the same
time.
USERACCOUNT: User account information table.

Attribute Name Data Type Length Description
USERID Varchar 8 User account identifier
PASSWD Numeric 8 User password
ACCESSROLE Varchar 15 User access role (e.g. PLAYER, COACH, TUTOR, ADMIN)
STATUS Varchar 3 User account status (ACT for active accounts, BLK for blocked accounts)
USERNAME Varchar 50 User full name
COACH: Coach’s information table.

COACHID Integer 4 Coach’s unique identifier
USERID Varchar 8 Foreign key references USERACCOUNT table
COACHNAME Varchar 50 Coach’s full name
TUTOR: Academic tutor’s information table.

TUTORID Integer 4 Tutor’s unique identifier
TUTORNAME Varchar 50 Tutor’s full name
PLAYER: Player’s information table.

PLAYERID Integer 4 Player’s unique identifier
PLAYERNAME Varchar 50 Player’s full name
DOB Date Player’s date of birth
INSTITUTION Varchar 50 Name of the academic institution the player belongs to
COURSE Varchar 80 Name of the course the player is studying
COACHID Interger 4 Player’s coach. Foreign key references COACH table
TUTORID Interget 4 Player’s academic tutor. Foreign key references TUTOR table
EMAIL Varchar 30 Player’s electronic mail
CONTACTNO Varchar 14 Player’s contact telephone number
ROLE: Cricketing role look-up table

ROLECODE Varchar 4 Role abbreviation code (e.g. BAT for Batting, BOW for Bowling)
ROLENAME Varchar 15 Role name (e.g. Batting, Bowling, Bowling-Spin, etc)
SKILL_TYPE: Cricketing skill type (category) look-up table

SKILLTYPECODE Varchar 6 Skill type abbreviation code (e.g. TEC for Technical, TAC for Tactical)
SKILLTYPENAME Varchar 25 Skill type name (e.g. Technical, Tactical, Physical, Mental, etc)
SKILL: Cricketing skill look-up table

SKILLID Integer 4 Skill unique identifier
SKILLNAME Varchar 25 Skill name (e.g. Versus Spin, Running between Wickets, etc)
ROLECODE Varchar 4 Role the skill belongs to. Foreign key references ROLE table
SKILLTYPECODE Varchar 6 Type of the skill. Foreign key references SKILL_TYPE table
SCORE: Player’s scoring storage table

SCOREID Integer 4 Skill unique identifier
PLAYERID Integer 4 Foreign key references PLAYER table
SKILLID Integer 4 Foreign key references SKILL table
SCOREVAL Integer 2 Value of the score. Defined between 1-10
UPDATEDATE Date Date of scoring
QUESTIONNAIRE: Questionnaire header information table

QID Numeric 9 Questionnaire unique identifier
QTITLE Varchar 80 Questionnaire title (or about)
AUTHOR Varchar 8 Author of the questionnaire. Foreign key references USERACCOUNT
table
CREATIONDATE Date Questionnaire creation date
AVAILABLE Varchar 1 A flag to decide if the questionnaire is to be made available for
answering (Y/N)
ANSWERED Varchar 1 A flag marking answered and non-answered questionnaires (Y/N)
QUESTIONNAIRE_BODY: Questionnaire questions table

QID Numeric 9 Foreign key references QUEATIONNAIRE table
QNO Interger 4 Question serial number
QTEXT Varchar 500 Question text
PLAYER_QUESTIONNAIRE: Players’ answers of the questionnaires table

QID Numeric 9 Foreign key references QUEATIONNAIRE table
ANO Interger 4 Answer serial number
ATEXT Varchar 900 Answer text
COMMENT: Coach’s comment entry table

COMMENTID Numeric 9 Row unique identifier
COMMENTTEXT Varchar 500 Comment text
TERM Varchar 10 Calendar term of the session (Christmas, Easter, Summer)
ROLECODE Varchar 4 Cricketing role abbreviation code
SKILLTYPECODE Varchar 6 Skill type
COACHID Integer 4 Foreign key references COACH table
ENTRYDATE Varchar 300 Entry date of the comment
D.6 Database Creation Script
CREATE TABLE USERACCOUNT

(USERID VARCHAR(8) NOT NULL PRIMARY KEY,
PASSWD VARCHAR(8) NOT NULL,
ACCESSROLE VARCHAR(15) NOT NULL,
STATUS VARCHAR(3),
USERNAME VARCHAR(50) )
CREATE TABLE COACH

(COACHID INT IDENTITY(1,1) NOT NULL PRIMARY KEY,
USERID VARCHAR(8) NOT NULL,
COACHNAME VARCHAR(50) NOT NULL
FOREIGN KEY (USERID) REFERENCES USERACCOUNT(USERID) )
CREATE TABLE TUTOR

(TUTORID INT IDENTITY(1,1) NOT NULL PRIMARY KEY,
TUTORNAME VARCHAR(50) NOT NULL
FOREIGN KEY (USERID) REFERENCES USERACCOUNT(USERID) )
CREATE TABLE PLAYER

(PLAYERID INT IDENTITY(1,1) NOT NULL PRIMARY KEY,
PLAYERNAME VARCHAR(50) NOT NULL,
DOB DATETIME,
INSTITUTION VARCHAR(50),
COURSE VARCHAR(80),
COACHID INT,
TUTORID INT,
EMAIL VARCHAR(30),
CONTACTNO VARCHAR(14)
FOREIGN KEY (USERID) REFERENCES USERACCOUNT(USERID),
FOREIGN KEY (COACHID) REFERENCES COACH(COACHID),
FOREIGN KEY (TUTORID) REFERENCES TUTOR(TUTORID) )
CREATE TABLE ROLE

(ROLECODE VARCHAR(4) NOT NULL PRIMARY KEY,
ROLENAME VARCHAR(15) NOT NULL)
CREATE TABLE SKILL_TYPE

(SKILLTYPECODE VARCHAR(6) NOT NULL PRIMARY KEY,
SKILLTYPENAME VARCHAR(25) NOT NULL)
CREATE TABLE SKILL

(SKILLID INT IDENTITY(1,1) NOT NULL PRIMARY KEY,
SKILLNAME VARCHAR(50) NOT NULL,
ROLECODE VARCHAR(4) NOT NULL,
SKILLTYPECODE VARCHAR(6) NOT NULL
FOREIGN KEY (ROLECODE) REFERENCES ROLE (ROLECODE)
FOREIGN KEY (SKILLTYPECODE) REFERENCES SKILL_TYPE (SKILLTYPECODE) )
CREATE TABLE SCORE

(SCOREID NUMERIC IDENTITY(1,1) NOT NULL PRIMARY KEY,
PLAYERID INT NOT NULL,
SKILLID INT NOT NULL,
SCOREVAL SMALLINT,
UPDATEDATE DATETIME NOT NULL
FOREIGN KEY (PLAYERID) REFERENCES PLAYER (PLAYERID),
FOREIGN KEY (SKILLID) REFERENCES SKILL (SKILLID) )
CREATE TABLE QUESTIONNAIRE

(QID NUMERIC IDENTITY(1,1) NOT NULL PRIMARY KEY,
QTITLE VARCHAR(80) NOT NULL ,
AUTHOR VARCHAR(8) NOT NULL,
CREATIONDATE DATETIME,
AVAILABLE VARCHAR(1),
ANSWERED VARCHAR(1)
FOREIGN KEY (AUTHOR) REFERENCES USERACCOUNT (USERID) )
CREATE TABLE QUESTIONNAIRE_BODY

(QID NUMERIC NOT NULL,
QNO INT NOT NULL ,
QTEXT VARCHAR(500) NOT NULL
PRIMARY KEY (QID, QNO),
FOREIGN KEY (QID) REFERENCES QUESTIONNAIRE (QID) )
CREATE TABLE PLAYER_QUESTIONNAIRE

(PLAYERID INT NOT NULL,
QID NUMERIC NOT NULL ,
ANO INT NOT NULL,
ATEXT VARCHAR(900)
PRIMARY KEY (PLAYERID, QID, ANO),
FOREIGN KEY (QID) REFERENCES QUESTIONNAIRE (QID),
FOREIGN KEY (PLAYERID) REFERENCES PLAYER (PLAYERID) )
CREATE TABLE COMMENT

(COMMENTID NUMERIC IDENTITY(1,1) NOT NULL PRIMARY KEY,
COMMENTTEXT VARCHAR(500) NOT NULL,
TERM VARCHAR(10) NOT NULL,
ROLECODE VARCHAR(4),
SKILLTYPECODE VARCHAR(6),
COACHID INT NOT NULL,
PLAYERID INT NOT NULL,
ENTRYDATE DATETIME NOT NULL
FOREIGN KEY (COACHID) REFERENCES COACH (COACHID)
FOREIGN KEY (PLAYERID) REFERENCES PLAYER (PLAYERID) )
Appendix E: Information Gathering Samples
E.1 Meetings/Interviews
Development of the UCCE Progress File

Meeting Minutes
Meeting Number: 1
Date: 20/03/2002
Time: 11:00 AM
Place: Leeds University
Attendees: Peter Rees Jones, UCCE Project Coordinator
Yousuf Al Hussaini, Leeds University
The meeting started with Peter Rees Jones welcoming me (Yousuf) and introducing himself. He then asked me about
my interest on this project. I replied him that I always find and interest in computer projects especially those requiring
dynamic web development. Peter then gave me a brief summary about the cricket game, its laws and the role of each
player on the pitch. He then introduced the UCCE (University Centre of Cricketing Excellence) and described its
functions. The main function of the UCCE is to develop students (players) skills and make them good excellent
cricketers.
Peter then continued his discussion by representing some manual documents (records) they are keeping to monitor
players performance. He said that during training and after every cricket matches, the coach and players and try to
record all performance or skills related aspects of their game to help players reflect, set themselves targets and apply
improvements to their game. The skills are divided into low-level skills (the behaviour of the player on the pitch) and
high-level skills (physical and mental related). The low-level and the high-level skills then linked together and a
summary page about each will be produced. Peter has expressed some of these paper records as a Currently they are
using Microsoft Excel Worksheet to store the related data. He also showed me some interesting graphical representation
diagrams. Those diagrams are set of circles and each circle is divided into sectors (representing the type of skills) and
tracks (each track represents performance in training or a cricket match).
We then talked about the project they want to develop. He represented to me a power point slides file describing his
idea of developing the progress file. This file suggests bringing all possible records together so that all relevant skills of
the player could by highlighted and his achievement could be monitored. The file also suggests linking low-level skills
to high-level skills to and then matched with the academic achievement of the player (student).
After Peter finished his description, I raised a couple of questions to him. The dialogue went as follows:
Yousuf: What is the relationship between the UCCE and the universities around such as
Leeds University?
Peter: The UCCE is dedicated for the students in Yorkshire universities: Leeds University,
LMU, Bradford University and Bradford College.
Yousuf: Who is in charge of the UCCE?
Peter: Kevin Sharp, the coach of the centre;
Jim Parry, Chairman of the School of Humanities, University of Leeds and the UCCE academic liaison officer;
Clive Souter, Director of Joint Honours Science, University of Leeds, responsible for electronic (information
technology) aspects,
Peter Rees Jones, Quality Management and Enhancement Unit, University of Leeds, centre project coordinator.
Yousuf: Could you describe briefly your objectives and requirements of the proposed web-
based progress file system?
Peter: Shared access between the players and the coach;
Shift performance recording process to the players;
Easy and global access to players’ information;
Link low-level skills with high-level skills;
Provide summary page covering player’s achievement (assessment);
Improves development of players’ skills;
Help players mature faster;
The facility to add/modify players’ records on-line;
The system development process should be iterative and the players will be involved
in this process.
Yousuf: Could you describe the organizational hierarchy of the UCCE?
Peter: There is no real hierarchy; the coach is leading the squad and the rest act as supportive/consultants.
Yousuf: Who is going to use the proposed system?
Peter: The coach (will be able to see all records) and the players (each will only be allowed to access his own record).
At the end of the meeting, I gave a quick introduction about myself; as it was not possible to do this in the beginning,
since we rushed into discussion immediately. And then we greet each other and we agreed to see later on April.
Development of the UCCE Progress File

Meeting Minutes
Meeting Number: 2
Date: 03/04/2002
Time: 10:30 AM
Place: University of Leeds.
Attendees: Clive Souter, Director of Science Joint Honours, University of Leeds.
Peter Rees Jones, Quality management and Enhancement Unit,
University of Leeds, UCCE Project Coordinator.
Kevin Sharp, University of Bradford, UCCE Coach.
Andrew Siddall, UCCE Marketing and PR officer.
Yousuf Al Hussaini, University of Leeds.
This meeting was held to capture user requirements based on the agenda which I have introduced to the attendees at the
beginning of the meeting. Unfortunately, the requirements still have not been clearly stated by the client and another
meeting has been scheduled to take place on 26th of April, 10:30 AM in Clive’s office.
The meeting started with each individual introducing himself and then a long discussion about the requirements
followed.
The following summarizes the resulted requirements/specifications:
Components of the UCCE Progress File

1. Cricket Progress File:
o Contains player’s physical and mental skills.
o To be created/maintained by player once a week (one record per week or so).
o To be viewed and commented by coach.
2. Academic Progress File:
o Contains player’s academic achievement progress.
o To be created/maintained by player (how often?).
o To be viewed and commented by academic tutor.
3. Performance Progress File:
o Contains facts and statistics about player’s skills on the pitch.
o To be created/maintained by player after a cricket match (one record per match).
o To be viewed and commented by coach.
Structure and details of the above file components is to be prepared by the client.
Users (stakeholders) of the system

1. Player.
2. Coach.
3. Academic tutor.
4. Web site administrator.
5. Liaison officer: is not a direct user. Players contact him by phone or email to sort out any clash problem in a
training session or a cricket match.
Roles of stakeholders
Player should be able to:
• Create and maintain his own cricket progress file.
• Receive coach’s comments on cricket progress file.
• Feedback on coach’s comments on cricket progress file.
• Create and maintain his own academic progress file.
• Receive academic tutor’s comments on academic progress file.
• Feedback on academic tutor’s comments on academic progress file.
• Create and maintain his own performance progress file.
• Receive coach’s comment on performance progress file.
• Feedback on coach’s comments on performance progress file

Coach should be able to:
• View cricket progress file of his players.
• Give feedback on each skill in the cricket progress file.
• View performance progress file of his players.
• Give feedback on each skill in the performance progress file.
Academic tutor should be able to:

• View academic progress file of his tutees.
• Give feedback on each skill in the academic progress file.
Web site administrator should be able to:

• Add/delete users and assign access roles.
• Maintain the structure of the web site.
Functional requirements
• A database is to be designed to store file components and player’s relevant data.
• A web-based ‘working prototype’ is to be developed to interact with the database and to handle stakeholders’
roles/activities.
• A calendar of events is to be included in the prototype.
Security Requirements
• Player is allowed to access his own files/data only.
• Coach is allowed to access his players’ files/data only.
• Academic Tutor is allowed to access his tutees’ files/data only.
Technical Requirements
• The system is to be a database system with web interface front-end.
• No decision made yet about where to host the system.
• Database and scripting language to be used depend on the facilities provided by the host. Yousuf suggests
ASP/SQL Server.
Project Meeting Agenda

15/08/2002 10:30 AM
Attendees:
• Kevin Sharp, Bradford/Leeds UCCE Coach;
• Peter Rees Jones, Academic Tutor;
• Andy Walker, Bradford/Leeds UCCE Cricket Player;
• Yousuf Al Hussaini.
Points discussed:
# Project progress;
Project progress was discussed in the meeting briefly.
# Demonstration of the prototype (iteration 2);
I have demonstrated the new features I added to the system since our last meeting on the 2nd of August, which
are “Text Comments” and “Progress Summary”. The attendees will start using the system, (the coach already
did), to get used to it and to be able to spot and errors or suggest modifications.
# Players Report (from Kevin);
Kevin (the coach) has suggested another way of keeping text comments to the player records. A report
showing the different Roles of the cricket against subjective assessments to the skills (Tactical, Technical,
etc.). This has to be entered by the coach once every session or term (e.g. Christmas, Easter and Summer). This
is to be put as the main “Text Comment” screen and the existing one to be attached to it.
Kevin also suggested that he should be able to answer some questions of the questionnaires that are created by
himself, and so is Tutor.
# Prototype testing.
We agreed to run a workshop of user acceptance test on the 2nd of September. This workshop will involve the
coach, an academic tutor and a player. Scenario of the test workshop is to be created by me. The same people
who attended this meeting will turn in for the workshop.
Summary:
# Text Comments Screen to be modified;

# Access to be given to coach and tutor to be able to answer questionnaires.
# All other areas of the system are okay;
# User acceptance test will be run on 2nd of September
E.2 Questionnaires
Hi Yousuf,
I've made some comments against the questions you set out below: -
-----Original Message-----
From: Al Hussaini Yousuf [mailto:msczyka@comp.leeds.ac.uk]
Sent: 30 June 2002 17:21
To: Peter Reece Jones
Subject: Enquiries
Hi Peter.
I have started the implementation of the CPF prototype. I will try to get it ready for you to try it, in 10
days.
I need to clarify the following points:
1- I should consider using graphics representation as an option. I need to know what specific data is
to be represented by the graphs, and in what format (shape) of graphs shall I produce?
I think that simple graphs would be a very good way of presenting information about how
performance is developing and whether it is consistent between different areas for a one to one
between coach and player. A stacked line graph with markers would show the relative trend in
several areas and make it easy to relate performance to particular times. It would be good to view
any skill within a single wagon wheel against any other single skill or against the average of skills for
that wheel (2 lines). Also it would be good to view any skill or average against any skill or average
on the other wheels (3 lines). I'm not clear how (or whether) a more detailed breakdown of an
individual skill (like toughness) could be plotted. You would also need to take account of skills within
wheels to which no score had been assigned so that they did not warp the average; I would suggest
discounting them.
This could give the player a view of their performance relative to indicators set by the coach, but it
might also be useful for the coach and player to be able to view the player against the average
performance of all players. (These 2 perspectives are used within the med school to look at the
assessed performance of students in 5 key skills.)
It is important that Kevin gives his view on this and I would suggest simply being able to illustrate
the approach in the first para to Kevin for his feedback before going further.
2- Is there any other type of skills apart from what I got from you (those represented by wagon
wheels). If there is, to what they belong (e.g. physical, mental, technical, tactical)?
The wagon wheels cover a particular domain of skills relevant to cricket. It would be useful to look
at how a skill like 'toughness', which is represented on the wagon wheel could be further analysed by
the player and the coach.
There will be further skills in the domain of skills relevant to cricket which have not been specified.
By resolving the problem of the 'wagon wheel' skills you will make it easier to take account of further
skills. I am not sure that you should go beyond the 'wagon wheel skills' and Clive would be well
placed to advise on what is practicable given the other parts of the project.
I promised to provide a standard set of prompts which might be used by the player to articulate the
value of the generic skills he is acquiring in cricket to the tutor and added to the University Progress
File. (In other words express the value of the skills acquired by the student in the cricket domain in
general terms which can be understood in the academic domain). This will be a single side of A4 for
each level of study.
I think its important that we now meet, so I am copying this email to Clive and Kevin. I am free all
the week beginning the 8th except the Wednesday the 10th and Monday the 15th.
Best Wishes
Peter
Please provide me with a deep clarification for the 1st point particularly.
Thanking you.
Yousuf.
E.3 Sample Documents
Developing a Progress File for Cricket
This document is a template setting out the broad structure of the Progress File for the Bradford
Leeds UCCE. Page 3 simulates a home page from which hot links lead on to definitions of the structure
of the progress file given in red italic with some illustrative material.
The file will draw material from: -

• The Performance Diary provided by the ECB for developing under 17s, in particular the sections
logging the development of physical and tactical skills related to performance as they articulate
with higher level skills.
• The generic academic Progress File developed By Geography and in current use within other
faculties.
• Further material to be supplied by ECB from the National Cricketing Academy.
Stakeholders: -
The following types of people will draw upon the Progress File: -
• The player, who will complete the performance logs provided within the progress file, use them to
review and reflect on how performance may be improved in terms of higher level skills;
• The coach, who is responsible for the design of the progress file as a means by which players can
take increasing responsibility for their own development and as a basis for reviewing players
performance in one to ones and setting targets;
• The academic tutor, who needs to be aware of the importance of cricket to the students personal
and academic development to deal with practical issues, such as the need to reconcile sporting and
academic timetables, and in providing references to employers.
The progress file will contain the following types of data: -

• Objective numeric data about the player's performance;
• Subjective numeric data about the player's self assessment of the skills required for
performance;
• Text entered by the player and the coach reviewing the player's performance and skills;
• Some of the above material may best be represented within active images, for example the bulls'
eyes representing performance and the physical and mental qualities good performance requires.
• Dates attached to all the above material in order that trends can be identified and within a diary
allowing the academic and cricketing schedule to be reconciled.
The progress file will be used by cricketers to log their performance and review with their coach the
higher level skills, such as concentration, they need to bring to bear in order to improve their
performance. This is the primary function of the progress file. The qualities this develops in players
are relevant to their personal and academic development and a secondary function of the progress file
is to communicate the value of this to the Academic Tutor in the terms used by the generic University
Progress File.
Data about performance and skills will be input by the player and reviewed by the player and the
coach either of whom may add comments into text fields. The player will add further text into a form
derived which can readily be used to complete the University's generic progress file and this subset of
data may be used as a basis for discussions between the player and their University tutor.
Appendix F: Code Segment Samples
F.1 The Sign-in Process

'Check if user/password exist
rs.Source = "Select userid, accessrole, status from useraccount where userid = '" & my_id & "'" & " and passwd = '" & my_pass & "'"
rs.Open
if (not rs.EOF) then
if (rs("status") <> "BLK") then
session("userid") = rs("userid")
session("accessrole") = rs("accessrole")
rs.Close
set rs = nothing
conn.Close
set conn = nothing
if (session("accessrole") = "PLAYER") then
Response.Redirect "player.asp"
elseif (session("accessrole") = "COACH") then
Response.Redirect "coach.asp"
elseif (session("accessrole") = "TUTOR") then
Response.Redirect "tutor.asp"
else
Response.Redirect "admin.asp"
end if
else
blocked = 1
end if
else
notfound = 1
end if
F.2 Skills Retrieval for Scoring

<%
'retrieve skill information
if (Request.QueryString ("add") <> 1) then
my_sql = "Select s.skillid, s.skillname, r.rolecode, r.rolename, st.skilltypecode, st.skilltypename "
my_sql = my_sql & "from skill s, role r, skill_type st "
my_sql = my_sql & "where st.skilltypecode = '" & Request.QueryString ("skilltypecode") & "' "
my_sql = my_sql & "and s.skilltypecode = st.skilltypecode "
my_sql = my_sql & "and r.rolecode = '" & Request.QueryString ("rolecode") & "' "
my_sql = my_sql & "and s.rolecode = r.rolecode"
rs.Source = my_sql
rs.Open%>
<font face="Arial" color="#008080"><br>
<center><b><%=rs("rolename") & " (" & rs("skilltypename")& " Skills)"%></b><br>
<img src="<%=rs("rolecode") & ".gif"%>"> </center>
</font>
</font>
<font >
<font face="Arial" color="#008080">
<form name ="frmScore" method="POST" action="score.asp?rolecode=<%=rs("rolecode")%>&skilltypecode=<%=rs("skilltypecode")%>&add=1">
<div align="center">
<center>
<table border="0" width="927" cellpadding="3" bgcolor="#ECFFF5">
<tr> <font face="Arial" color="#008080">
Select the desired score against each skill.
<p>
</font>
</tr>
<%index = 1
while not rs.EOF%>
<tr>
<%for i = 1 to 4
' generate 4 columns
my_skill = "skill" & index
my_score = "score" & index%>
</font>
<td width="673">
<%if (not rs.EOF) then%>
<%=rs("skillname")%>
</font>
</td>
<td width="232">
<input type="hidden" name="<%=my_skill%>" value="<%=rs("skillid")%>" >
<select size="1" name="<%=my_score%>" >
<option value=""></option>
<option value="1">1</option>
</select>
</font>
</td>
<%index = index + 1
rs.MoveNext
end if
next%>
</tr>
<%wend
rs.Close
set rs = nothing
conn.close
set conn = nothing%>
</table>
</center>
</div>
<p> </p>
<input type="hidden" name="skillcounter" value="<%=index-1%>" >
<p align="center"><input type="submit" value="Save Scores" name="B1" onClick = "return
frmScore_Validate()">
<input type="reset" value="Reset Entries" name="B2"></p>
</form>
F.3 Reading and Saving Score Values
<%else
' record scores
my_counter = Request.Form("skillcounter")
conn.BeginTrans
for i = 1 to my_counter
my_skillid = Request.Form ("skill" & i)
my_score = Request.Form ("score" & i)
my_sql = "insert into score (playerid, skillid, scoreval, updatedate) "
my_sql = my_sql & "values(" & my_playerid & "," & my_skillid & "," & my_score & ",'" & date() & "')"
if (my_score <> "") then
conn.Execute my_sql
end if
next
conn.CommitTrans
conn.close
set conn = nothing
' move to next set of skills
my_nextset = Request.QueryString("rolecode")& Request.QueryString("skilltypecode")
select case my_nextset
case "BATTECTAC" Response.Redirect ("score.asp?rolecode=BAT&skilltypecode=PHYS")
case "BATPHYS" Response.Redirect ("score.asp?rolecode=BAT&skilltypecode=MENT")
case "BATMENT" Response.Redirect ("score.asp?rolecode=BAT&skilltypecode=TOUG")
case "BATTOUG" Response.Redirect ("score.asp?rolecode=BP&skilltypecode=TECTAC")
case "BPTECTAC" Response.Redirect ("score.asp?rolecode=BP&skilltypecode=PHYS")
case "BPPHYS" Response.Redirect ("score.asp?rolecode=BP&skilltypecode=MENT")
case "BPMENT" Response.Redirect ("score.asp?rolecode=BP&skilltypecode=TOUG")
case "BPTOUG" Response.Redirect ("score.asp?rolecode=BS&skilltypecode=TECTAC")
case "BSTECTAC" Response.Redirect ("score.asp?rolecode=BS&skilltypecode=PHYS")
case "BSPHYS" Response.Redirect ("score.asp?rolecode=BS&skilltypecode=MENT")
case "BSMENT" Response.Redirect ("score.asp?rolecode=BS&skilltypecode=TOUG")
case "BSTOUG" Response.Redirect ("score.asp?rolecode=FLD&skilltypecode=TECTAC")
case "FLDTECTAC" Response.Redirect ("score.asp?rolecode=FLD&skilltypecode=PHYS")
case "FLDPHYS" Response.Redirect ("score.asp?rolecode=FLD&skilltypecode=MENT")
case "FLDMENT" Response.Redirect ("score.asp?rolecode=FLD&skilltypecode=TOUG")
case "FLDTOUG" Response.Redirect ("score.asp?rolecode=WK&skilltypecode=TECTAC")
case "WKTECTAC" Response.Redirect ("score.asp?rolecode=WK&skilltypecode=PHYS")
case "WKPHYS" Response.Redirect ("score.asp?rolecode=WK&skilltypecode=MENT")
case "WKMENT" Response.Redirect ("score.asp?rolecode=WK&skilltypecode=TOUG")
case "WKTOUG" Response.Redirect ("player.asp")
end select
end if%>
F.4 Summary HTML Input Form

<%rs.Source = "select distinct updatedate from score where playerid = " & my_playerid & " order by updatedate desc"
rs.Open%>
<form method="POST" action="summary.asp">
<p>Period of the summary: From
<select size="1" name="from">
<%while not rs.EOF
my_option = ""
my_request = "'" & Request.Form("from") & "'"
my_date = "'" & rs("updatedate") & "'"
if (my_date = my_request) then
my_option = "selected"
end if
my_updatedate = day(rs("updatedate")) & "/" & month(rs("updatedate")) & "/" & year(rs("updatedate"))%>
<option value="<%=rs("updatedate")%>" <%=my_option%>> <%=my_updatedate%> </option>
<%rs.moveNext
wend
rs.Close%>
</select>
To
<select size="1" name="to">
<%rs.Open
while not rs.EOF
my_option = ""
my_request = "'" & Request.Form("to") & "'"
my_date = "'" & rs("updatedate") & "'"
if (my_date = my_request) then
my_option = "selected"
end if
my_updatedate = day(rs("updatedate")) & "/" & month(rs("updatedate")) & "/" & year(rs("updatedate"))%>
<option value="<%=rs("updatedate")%>" <%=my_option%>> <%=my_updatedate%> </option>
<%rs.moveNext
wend
rs.Close%>
</select></p>
<p><input type="submit" value="View Summary" name="view"></p>
</form>
F.5 Statistical Summary of Average Score by Scoring Date

<%' 1- view summary statistics by scoring date
if (Request.Form("view") <> "") then
my_sql = "select r.rolename, avg(sc.scoreval*1.0) as average, sc.updatedate from score sc, role r, skill sk "
my_sql = my_sql & "where sc.playerid = " & my_playerid
my_sql = my_sql & " and sc.updatedate between '" & Request.Form("from") & "' and '" & Request.Form("to") & "'"
my_sql = my_sql & "and sc.skillid = sk.skillid and r.rolecode = sk.rolecode "
my_sql = my_sql & "group by sc.updatedate, r.rolename order by sc.updatedate, r.rolename"
rs.Source = my_sql
rs.Open%>
<u>Average Summary by Date of Scoring</u>
<tr>
<td bgcolor="#008080" width="195"><font face="Arial" color="#FFFFFF"><b>Date Period</b></font></td>
<td bgcolor="#008080" width="195"><font face="Arial" color="#FFFFFF"><b>Date of Scoring</b></font></td>
<td bgcolor="#008080" width="287"><font face="Arial" color="#FFFFFF"><b>Role/Skill
Name</b></font></td>
<td bgcolor="#008080" width="135"><font face="Arial" color="#FFFFFF"><b>Average
Performance</b></font></td>
</tr>
<%my_datebreak = "" 'break summary on date
my_period = 0
while not rs.EOF
if (my_datebreak = rs("updatedate")) then
my_updatedate = ""
my_seq = ""
else
my_datebreak = rs("updatedate")
my_updatedate = day(rs("updatedate")) & "/" & month(rs("updatedate")) & "/" & year(rs("updatedate"))
my_period = my_period + 1
my_seq = my_period & " "
end if%>
<tr>
<td width="120">
<font face="Arial" color="#008080"><b><%=my_seq%></b></font></td>
<td width="195">
<font face="Arial" color="#008080"><b><%=my_updatedate%></b></font></td>
<td width="287">
<font face="Arial" color="#008080"> <%=rs("rolename")%></font></td>
<td width="135"> <font face="Arial" color="#008080"> <%=cint(rs("average"))%></font></td>
</tr>
<%rs.MoveNext
wend
rs.Close%>
</table>
F.6 Skills development Line-Graph Plotter

<%' 2- plot the results in 1
my_sql = "select distinct updatedate from score "
my_sql = my_sql & "where playerid = " & my_playerid
my_sql = my_sql & " and updatedate between '" & Request.Form("from") & "' and '" & Request.Form("to") & "'"
my_sql = my_sql & " order by updatedate"
rsDate.Source = my_sql
rsDate.CursorType = 3
rsDate.Open
my_xrange = rsDate.RecordCount + 5
my_period = 1
' intialize the graph
Response.Write "<script src=glib.js></script> "
Response.Write "<script> "
Response.Write "Gopen(""white"",650,300,"""",0); "
Response.Write "xyinit(50,270,1,0,0,0); "
Response.Write "goffset(1,0,1); "
Response.Write "gscale(3,4,1); "
Response.Write "xscale(""BLACK""," & my_xrange & ",""Date Period"",1); "
Response.Write "yscale(""BLACK"",10,""Avergae Score"",1); "
Response.Write "xygrid(""lightcyan""); "
Response.Write "Glabel(""Batting"",""Bowling-Pace"",""Bowling-Spin"",""Fielding"",""Wicket Keeping""); "
Response.Write "Gsymbol(""B"",""BP"",""BS"",""F"",""WK""); "
while not rsDate.EOF
my_updatedate = rsDate("updatedate")
' get avg score of Batting
rs.Source = "select avg(sc.scoreval*1.0) as average from score sc, skill sk "
rs.Source = rs.Source & "where sc.playerid = " & my_playerid & " and sc.updatedate = '" & my_updatedate & "'"
rs.Source = rs.Source & " and sc.skillid = sk.skillid and sk.rolecode = 'BAT'"
rs.Open
if (isNull(rs("average"))) then
my_BAT = 0
else
my_BAT = cint(rs("average"))
end if
rs.Close
' get avg score of Bowling-Pace
rs.Source = rs.Source & " and sc.skillid = sk.skillid and sk.rolecode = 'BP'"
rs.Open
my_BP = 0
else
my_BP = cint(rs("average"))
end if
rs.Close
' get avg score of Bowling-Spin
rs.Source = rs.Source & " and sc.skillid = sk.skillid and sk.rolecode = 'BS'"
rs.Open
my_BS = 0
else
my_BS = cint(rs("average"))
end if
rs.Close
' get avg score of Fielding
rs.Source = rs.Source & " and sc.skillid = sk.skillid and sk.rolecode = 'FLD'"
rs.Open
my_FLD = 0
else
my_FLD = cint(rs("average"))
end if
rs.Close
' get avg score of Wicket Keeping
rs.Source = rs.Source & " and sc.skillid = sk.skillid and sk.rolecode = 'WK'"
rs.Open
my_WK = 0
else
my_WK = cint(rs("average"))
end if
rs.Close
my_row = "Gdata(" & my_period & "," & my_BAT & "," & my_BP & "," & my_BS
my_row = my_row & "," & my_FLD & "," & my_WK & "); "
Response.Write my_row
my_period = my_period + 1
rsDate.MoveNext
wend
rsDate.Close
Response.Write "Gclose(); </script> <br>"%>
</font>
</font><font face="Arial" size="2"color="black">* 0 indicates no score <br>
* Javascript library used to draw the above graph<br>
is provieded as a freeware by http://siva.cc.hirosaki-u.ac.jp/usr/koyama/glib</font>
F.7 Statistical Summary of the Overall Average Score

<%' 3- view overall summary
my_sql = "select r.rolename, avg(sc.scoreval*1.0) as average from score sc, role r, skill sk "
my_sql = my_sql & "where sc.playerid = " & my_playerid
my_sql = my_sql & " and sc.updatedate between '" & Request.Form("from") & "' and '" & Request.Form("to") & "'"
my_sql = my_sql & "and sc.skillid = sk.skillid and r.rolecode = sk.rolecode "
my_sql = my_sql & "group by r.rolename"
rs.Source = my_sql
rs.Open%>
<u>Overall Average Summary</u>
<tr>
<td bgcolor="#008080" width="287"><font face="Arial" color="#FFFFFF"><b>Role/Skill
Name</b></font></td>
<td bgcolor="#008080" width="135"><font face="Arial" color="#FFFFFF"><b>Average
Performance</b></font></td>
</tr>
<%while not rs.EOF%>
<tr>
<td width="287">
<font face="Arial" color="#008080"> <%=rs("rolename")%></font></td>
<td width="135"> <font face="Arial" color="#008080"> <%=cint(rs("average"))%></font></td>
</tr>
<%rs.MoveNext
wend
rs.Close%>
</table>
F.8 New Questionnaire Generation

<%' adding new questionnaire
if (Request("add") = 1) then
Response.Write "<hr>"
Application.Lock
if (Request("qno") = 1001) then
' create header
my_sql = "insert into questionnaire (qtitle, author, creationdate, available, answered) values ('"
my_sql = my_sql & Request.Form("qtitle") & "','" & my_author & "','" & date() &"','" & Request.Form("available") & "', 'N')"
conn.Execute my_sql
session("qno") = 1
else
' get qid and qno of this question from a different form (e.g. qupdateform)
if (Request.QueryString("addmore") = 1) then
session("qno") = Request.QueryString("qno") + 1
my_qid = Request.Form("qid")
else
' get qid of this questionnaire from DB
if (Request.Form("qid") = "") then
rs.Source = "select max(qid) as qid from questionnaire"
rs.Open
my_qid = rs("qid")
rs.Close
end if
end if
if (my_qid = "") then
my_qid = Request.Form("qid")
end if
' create body (save questions)
if (Request.Form ("qtext") <> "") then
my_sql = "insert into questionnaire_body (qid, qno, qtext) values ("
my_sql = my_sql & my_qid & "," & session("qno") & ",'" & Request("qtext") & "')"
conn.Execute my_sql
session("qno") = session("qno") + 1
end if
end if
my_qno = session("qno")
' Check if Exit button has been pressed
if (Request("qno") = 99) then
Response.Redirect ("questionnaire.asp")
end if%>
<form method="POST" name="qbody" action="questionnaire.asp?add=1&qno=<%=my_qno%> ">
<input type="hidden" name="qid" value="<%=my_qid%>">
<p><font face="Arial" color="#008080">Enter Question Number <%=my_qno%> </font></p>
<p><textarea rows="8" name="qtext" cols="79"></textarea></p>
<p><input type="submit" value="Proceed" name="B1">
<input type="submit" value="Finish and Exit" name="B2" onClick="qbody_Exit()"></p>
</form>
<%Application.UnLock
end if
F.9 Questionnaire Modification

' 2. Modifying Questionnaire
' Update modification changes
if (Request.QueryString ("savemod") = 1) then
conn.BeginTrans
' update header
my_sql = "update questionnaire set qtitle = '" & Request.Form("qtitle") & "',"
my_sql = my_sql & "available = '" & Request.Form("available") & "' where qid = " & Request.Form("qid")
conn.Execute my_sql
' update body
my_qid = Request.Form ("qid")
if (Request.Form("qcounter") <> "") then
for i = 1 to Request.Form("qcounter")
my_qtext = Request.Form( "q" & i & "text")
' If no text is entered, delete question
if (my_qtext = "") then
my_sql = "delete from questionnaire_body where qid = " & my_qid & " and qno = " & i
else
' else update question text
my_sql = "update questionnaire_body set qtext = '" & my_qtext & "' "
my_sql = my_sql & "where qid = " & my_qid & " and qno = " & i
end if
conn.Execute my_sql
next
end if
conn.CommitTrans
' Re-arange questions if any has been deleted

rs.Source = "select qno from questionnaire_body where qid = " & my_qid
rs.Open
i=0
while not rs.EOF
my_qno = rs("qno")
i=i+1
if (my_qno> i) then
my_sql = "update questionnaire_body set qno = " & i & " where qno = " & rs("qno") & " and qid = " & my_qid
conn.Execute my_sql
end if
rs.MoveNext
wend
rs.Close
if (my_qno = "") then
my_qno = 0
end if
' Prompt for adding more questions%>
<br><font color="#008080" face="Arial">
Changes have been saved. Click the button below to add more questions.</font>
<form name="addmore" method="post" action="questionnaire.asp?add=1&addmore=1&qno=<%=my_qno%>" >
<input type="hidden" name="qid" value="<%=my_qid%>">
<input type="submit" name="B9" value="Add More Questions">
</form>
<%end if%>
F.10 Listing of connection.asp Script

<style>
A:link, A:active
{ text-decoration : none;
color : #008080;
}
A:visited { color : #008080;
text-decoration : none;
}
A:hover { color : white;
background : #008080;
}
</style>
<%
' Error handling
' on error go to error_handler
' Connection to DB
Set conn = Server.CreateObject("adodb.connection")
conn.ConnectionTimeout = 0
Conn.ConnectionString = "Provider=SQLOLEDB.1;" & _
"Persist Security Info=False;" & _
"User ID=********;" & _
"Password =*******;" & _
"Initial Catalog=CPF;" & _
"Data Source=CSMS2"
'This sub program verifys accessability of users to a specific page

Sub VerifyAccess (p_accessrole)
if session("accessrole") <> p_accessrole then
Response.Write "<b> Access to this page is deniend. Please contact the web site administrator! </b>"
Response.End
end if
end sub
'error_handler:
' set err = Server.GetLastError()
'if (err.number <> 0 ) then
'Response.Write err.description
'end if
%>
Appendix G: User’s Feedback and the Outcome of the Acceptance Test
G.1 Client’s Feedback Letter

G.2 The Outcome of the User’s Acceptance Test

Appendix H: CPF Installation Guide
The following are the steps required to install the CPF prototype or to move it into a new host
server. An electronic copy of the directories/files described below will be packed and handed to the
client.
Step 1: Copy the cpf entire directory under the active directory of the IIS server (e.g.
C:\InetPub\wwwroot).
Step 2: Create a new database in the SQL Server and call it CPF.
Step 3: Open the SQL Query Analyzer utility and run the script cpf.sql that is located under the
directory export (the script may also be copied and pasted). This should create the database table
structure. 13 tables should have been created as a result of this step, which are USERACCOUNT,
COACH, PLAYER, TUTOR, ROLE, SKILL_TYPE, SKILL, SCORE, COMMENT, QUESTIONNAIRE,
QUESTIONNAIRE_BODY, and PLAYER_QUESTIONNAIRE.
Step 4: Import the data of the lookup tables into the CPF database. Use append table option to
avoid recreating the tables. The import files are located under the export directory and named
role.txt, skill_type.txt and skill.txt. They should also be imported in the same order respectively.
Step 5: Create a new user with a password in the CPF database and grant him full access (i.e.
select, insert, update, delete) on all tables of the CPF database.
Step 6: Modify the following lines of the script connection.asp that is located under the cpf
directory:
"User ID=********;" & _ Replace the stars with the user id you have created in Step 5.
"Password =*******;" & _ Replace the stars with the password you have assigned to the
user you have created in Step 5.
"Initial Catalog=CPF;" & _ If you named the database as CPF then ignore this line,
otherwise, replace CPF with the database name you have
created in Step 2.
"Data Source=CSMS2" Replace CSMS2 with your IIS Server/Machine name.
Step 7: Open the database table USERACCOUNT and add a new user account entry. This user is
supposed to be the System Administrator of the CPF. Type ADMIN in the ACCESSROLE field.
This user account should be used to create other user accounts, through the website.
Step 8: Test the prototype from your browser (IE or NN). Type <<machine name, domain name or
the IP address>> of your IIS Server proceeded by /cpf in the address bar. The log-in page should
be displayed. Use the useraccount/password created in Step 7 to login to the system and to create
the rest of the user accounts, including coach, players and tutors with the appropriate access role.

Al Hussain I

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Al Hussain I

Diunggah oleh

Hak Cipta:

Format Tersedia

Web Development

I would like to take this opportunity to thank all of the following:

The Bradford/Leeds Cricketing Centre of Excellence is a member of the University Centres of

The objectives of this project are:

1.3 Minimum Requirements

The minimum requirements of this project are:

The deliverables of this project are:

1.6 Development Approach

use of Entity-Relationship modeling diagrams; as the underlying database is relational. An iterative

Figure 1.1 Iterative System Development Life Cycle.

1.7 Project Schedule

Date Period Task Accomplished

Table 1.1 Project Schedule

1.8 Literature Review of Tools/Techniques

1.8.1 System Architecture

Microsoft IIS, SQL Server,

Figure 1.2 Three-tier Architecture.

1.8.2 Active Server Pages (ASP)

Figure 1.3 ASP Architecture and Work Mechanism [3]

1.8.3 SQL Server

The SQL Sever description in this section is provided by [4].

Figure 1.4 Components of a Database [4]

Figure 1.5 SQL Server Architecture [4].

Chapter 2: Requirement Capture

2.1 What is a Progress File?

2.2 The Cricket Progress File (CPF)

2.3 Information Gathering

2.4 System Requirements

• Characteristics of the users who will use the system.

2.4.1 The Current CPF System

Rec ord P erform anc e P rogres s

Figure 2.1 The Current CPF System

2.4.2 The Proposed CPF System

M aintain Cric ket P rogres s File

M onitor Cric k et P rogres s File

Chapter 3: Requirement Analysis

3.1 The Detailed Use Case Diagram of the CPF

E nter Tex t Comments about

View Cric k eting Progres s

<<ex tend>> < <ex tend> >

< <inc lude> >

Create Us er A c c ount As sign Ac c es s Rol e

3.2 Use Case Description

Use Case Name Actor(s) Description Possible Candidate

3.3 Modeling the Interaction

get A c c ount Details ( )

dis play ("U RL")

get P lay erID ( )

c reat eNewQues t ionnaire()

rec ordS c ore()

Figure 3.3 Part of Concept-Level Class Diagram Resulted from

Figure 3.4 Concept-Level Class Diagram of the CPF System

3.4 Modeling System Functionalities

Chapter 4: Prototype Design

4.1 Moving from Analysis to Design

< < W eb P age> >

Figure 4.1 Detailed Class Model of the CPF Prototype

Class Name ASP/HTML Database

Table 4.1 Possible Different Forms of the Mapped Classes

4.3 Software Architecture of the CPF Prototype

Presentation Layer CPFHomePage

AdminHomePage PlayerHomePage CoachHomePage

Data Connectivity ADO/OLE-DB