A
DMINISTRATOR
O
BJECT
The administrator object (see Table 2) contains administrator personal information.
Name
Description
Data type
Example
AdminID
Administrator‟s
Identification number
7 numbers
0054959
DateBirth
Date of Birthday
Date
1970/12/12
Name
Administrator „s name
20Characters
Mussa
MobilePhone
Number of his/her
phone
10 Number
078888800
Table 2:
Administrator Object
37
R
ES
A
DMIN
O
BJECT
The ResAdmin Object (see Table3) contains ResAdimin
‟s personal information.
Name
Description
Data type
Example
ResAdmin ID
ResAdmin
‟s
Identification number
7 numbers
0034959
DateBirth
Date of Birthday
Date
1945/1/14
Name
ResAdmin „s name
20Characters
Mussa
Mobile Phone
Number of his/her
phone
10 Number
078844400
Table 3:
ResAdmin Object
R
ESIDENCE
O
BJECT
The Residence Object (see Table 4) contains information about the residence of the
UWC.
Name
Description
Data type
Example
Residence Code
Code given to each residence
7 numbers
001
Residence Name
Actual Name of the residence
20Characters
Cassinga
NumberRoom
Number which are in residence
20Number
3000rooms
Table 4:
Residence Object
R
OOM
O
BJECT
The Room Object (see Table 5) contains information about a particular room of a given
residence.
38
Name
Description
Data type
Example
Room Code
Code given to each room
7 character
001/0001
ResidenceID
Actual code of the residence
Characters
001
Room Type
The type of rooms in that residence
10 characters
Single
Price
The Charges per room
10 numbers
R 1864
Status
The status of room
10 characters
Vacant
Table 5:
Room Object
P
AYMENT
O
BJECT
The Payment Object (see Table 6) contains information about a the payment for
accommodation.
Name
Description
Data type
Example
PaymentID
Code of payment
7 character
001/0001
StudentNumber
Student Number of student who paid
10 Number
Vincent Biruta
Amount
Price of application fees
10 Number
R 500
Date
Date of payment
Date
02/03/2009
Amountpaid
Cash student paid
10 Number
R300
Balance
Rest payment
10 Number
R200
ReferenceNumber
Number system diplay after application
5 Number
10005
Table 6:
Payment object
39
B
OOKING
O
BJECT
Name
Description
Data type
Example
BookingID
Code given to each
application made
7 character
45738
Student Number
Name of student who
paid
10 characters
Vincent Biruta
Room Code
Room code applied for
10 Number
001/0001
Date
Date of application
Date
2009/11/11
Table 7:
Booking Object
LATEST BALANCE
O
BJECT
Name
Description
Data type
Example
Ref_ID
Helps
to
retrieve
payment information
7 character
14
Latest Balance
Last payment
Double
R 700.00
Table 8:
Latest Balance Object
5.3 Class Diagram
The Class Diagram (see Figure 14) shows the relationship between classes. The student
applies for a room and s/he pays for the room. The administrator controls and records
the payments. Also, the residence has rooms and rooms are managed by the ResAdmin.
The ResAdmin manages the applications and allocates rooms to successful applicants.
40
Figure 14: Class Diagram
41
5.4 Conclusion
In this chapter, each class and its attributes were explained in detail using data dictionary.
The data dictionary described the attributes and the data type and an example was given to
each attribute. Furthermore, the class diagram demonstrated the relationship between
classes in the system. The next chapter looks at the object oriented design.
42
C h a p t e r 6
OBJECT ORIENTED DESIGN (OOD) OR LOWER LEVEL DESIGN
6.1 Introduction
In the previous chapter, each object was described and documented in data dictionary. However,
i
n this chapter, the Object Oriented Design (OOD) will take the classes in the OOA a
level deeper into the realm of pseudo-code. The OOD defines the data types for the
attributes, the algorithms and implementation details of classes. Also the state and
sequence diagrams of the system are explained.
6.2 Inner Details of Class Attributes and Methods
The class diagram described in Chapter 5 shows all classes that will be used within the
system. Also class attributes (data types) were defined in the data dictionary and methods
(functions) are described within the class diagram.
43
6.3 State Diagram
The State Diagram (see Figure 15) depicts the dynamic behavior of login and application
functions of the system. The student enters the username and password, and then the
system validates the entries. If valid, the student is accepted into the system otherwise the
student is rejected. For the student to be allocated a room, the system checks if the room
is available, if not, the application is rejected. If the room is available the system will check
whether the student has paid the room fee and has no outstanding balance.
Figure 15: State Diagram
44
6.4
Sequence Diagram
The following Sequence Diagram (see Figure 16) illustrates the sequence of activities as
the system is into operation.
The student applies on application page, after that the system checks for room availability
and makes confirmation to the application page. The application page displays the
reference number to student. Then student make payment to the UWC Administrator and
the Administrator input payment information and update the database. After that the
ResAdmin selects room and students in the system, and the system displays the
information about rooms and students‟ applications. Thereafter the ResAdmin allocates
rooms to students, update the database and send notifications to successful applicants.
Dostları ilə paylaş: |