ITC508 Object modeling Assessment 2: Enrollment System UML Diagrams

Desklib provides past papers and solved assignments. This report details the design of a university enrollment system using UML diagrams.

ITC508 Object modeling Assessment 2

Contents
Introduction.................................................................................................................................................3
Functional requirements for Enrollment system..........................................................................................4
Non-functional requirements of Enrollment system....................................................................................5
Use case diagram of enrollment system.......................................................................................................6
Use case diagram description......................................................................................................................7
Domain model class diagram for enrollment system...................................................................................8
Domain model class diagram description....................................................................................................9
Event portioning System model for enrollment system.............................................................................11
Event model description............................................................................................................................12
Conclusion.................................................................................................................................................13
References.................................................................................................................................................14
List of figures
Figure 1 use case diagram of enrollment system.............................................................................6
Figure 2 use case description table..................................................................................................8
Figure 3 domain model class diagram.............................................................................................8
Figure 4 event partitioning system model diagram......................................................................11

Introduction
The report aims to represent a part of the software development life cycle and the functionalities
of UML diagrams. In order to build an enrollment system for university students, the UML
diagrams have to be created defining the functionalities present in the system as given in the case
scenario. According to the case scenario, the functional requirements and non-functional
requirements have to be gathered so that the system can be implemented with the most accuracy.
After the requirement gathering part, a use case diagram has to be made depicting all the use
cases present in order to implement the system. A major use case has to be found out and its
description has to be written. The report also contains the domain model class diagram and event
portioning system model made on the basis of the use case diagram.

Functional requirements for Enrollment system
The functional requirements of Enrollment system should be able to provide all its users the
basic functionality listed down below:
 Students can enroll in the system.
 Students can enter and update their personal information using the system.
 Students can choose the major and term for enrollment from the available major choices
present in the system.
 The system can match the major chosen and term selected so as to ensure that the student
has made the correct choice.
 The system can display the courses available for the major selected by the student.
 Student can select the courses available according to his own interest.
 Student can view the available class timings for the selected courses.
 Student can choose the class timing from the available timings.
 The system can check the number of students already been enrolled in a system so as to
ensure that a particular class doesn’t have students more than the upper limit which is a
maximum of 40 students.
 The system can remove class timings for the students when it has reached the upper
limit.
 Students can have the functionality of updating the information before paying for the
courses (Broy 2018).
 Student can choose the payment method suitable from the list of available payment
methods.
 The system can check for the validation of payments made.
 The system can display the location of classes, timings, course details, assessment details,
orientation details, etc. to the enrolled students using the dashboard.
 Admin can check the enrolled student’s details.
 The system can check for the login verification for students, admin, and tutors.
 Tutors and admin can check the course details allotted to them including the timings,
location, etc.
 Admin can perform operations in the enrolled number of students to track the number of
interested students, highest enrolled major, etc.
 Admin can assign tutors to the course available and update the details when required
(Anish, Daneva, Cleland-Huang, Wieringa and Ghaisas 2015).

Non-functional requirements of Enrollment system
The non-functional requirements that should be present in the enrollment system don’t have to
do anything with the functionalities that the system will perform. It includes the attributes which
will define the quality of the system.
 Performance- the information including the resources required should be accurate. The
response time of each query and operations performed by the user should be less and the
system should respond quickly. The transaction rates should be fast. Throughput should
be high.
 Operating system constraints- the run time constraints including the software and system
resources should be in accordance with the functionality of the system (Ahmad, García
and Rodríguez 2016).
 Platform constraints- the enrollment system should be able specific and should target the
required audience appropriately. The system should be consistent in the layouts but the
layout should be according to the different user for example tutors, staff and students.
 Modifiability- the enrollment system should not be too rigid to resist the changes. The
system should be adaptable to changes like memory space etc.
 Accuracy- the enrollment system should be displaying accurate data and should consist
of all the possible requirements needed by the user.
 Portability- the enrollment system should be flexible to move to a different platform in
case of new technology arrived.
 Reliability- the meantime present between the system failures should be less. The system
should avoid failures in the first place but should be able to protect itself after the
failures. The system should be able to detect the errors that might affect the system and
their possible remedies.
 Security- the enrollment system should be secure enough to protect the personal
information of students, tutors and admins, such as contact details, card details, payment
history, etc. the password should be present in an encrypted format. The system should be
able to grant different user access and privileges to the different users (Bahill and Madni
2017).
 Usability- it is defined as the ease with the users can operate the system. Hence the
system should be easy to use and understand.
 Availability- enrollment system should work continuously without failures.


Use case diagram of enrollment system
Figure 1 use case diagram of the enrollment system

Use case diagram description
Use case name Update the details
Scenario To update the entered information by the student during enrollment.
Triggering event When the students want to update the details entered by him/her
before payment for the course.
Description This use case will provide the customer with the functionality of
updating the details such as his/her name, id, address, contact details,
major selected by him/her or the term. These are the basic
information that a student has to enter to enroll him in the system. To
review the details and to correct any mistake that the student might
have made while entering the details, it is necessary to add this
functionality into this system (Singh, Sharma and Saxena 2016).
Actors Student
Related use case Enter personal details, choose major and term and select course and
time
Stakeholders Student, admin, tutor
Preconditions 1. The student must have logged into the system.
2. The student has filled his personal details.
3. The student has selected course, major and term.
Postconditions 1. The student has saved the details.
Flow of activities Student System
1. The student enters the
details.
2. The student chooses the
major and term
3. The student selects the
course and timings
4. The student chooses the
update option.
1. The system displays the
option to enter the
details.
2. The system displays the
major available.
3. The system displays the
list of courses available
for selected major and
term.
4. The system displays the
option to update the
details.
Exception conditions 1. The student didn’t save the entered details.

2. The system failed to update the information.
3. Student updated the details but forgot to save.
Figure 2 use case description table
Domain model class diagram for enrollment system
Figure 3 domain model class diagram

Domain model class diagram description
Domain model class diagram displays the structure of the enrollment system by categorizing the
system into classes where each class has its own set of characteristics and behaviors (Akour,
Falah, Madi and Bouali 2016). The description of each class is as follow:
Student class- the student class possess the attributes that the student will have while enrolling
into the system. The attributes are a name, student’s id and password, mobile number, email id,
and address, etc. The student class will have all these attributes so that the user can enter these
details while registering for enrollment. The behaviors for student class are add_Details, enrolls,
and payment which enables the student to add and save the personal details, enrolling into the
system and paying through the payment methods available respectively. A student can have
multiple numbers of courses and tutors. The enrollment functionality further provides the
students to select the major, term and courses. The students can access the course class to view
the course timings and class availability.
Enrollment class- the enrollment class is made to have the functionality to save the details such
as the student’s name, student id, major opted, term, course opted, the class timings allotted to
the student and the payment details. The enrollment class has two additional attributes to let the
admin know the date and time when a particular student was enrolled in a course. The enrollment
class has the functionalities to cancel the enrollment; save the enrollment, etc. admin class will
be able to track all the public and private fields of this class.
Course class- course class has the attributes to define the courses available in a major selected
by the student. The attributes are course name, code, timings, and tutor assigned with the
particular course. The class will be managed by the admin class. The functionalities of course
class are to change the timings of class for a course and to remove a student from a particular
course or class. A tutor can have multiple courses.
Admin class- the admin will manage and track all other classes in the enrollment system. The
admin can view the private members of other classes as well. The functionalities of an admin
class are to track the enrollment of students, delete the enrolled student’s details, track the details
of the course, track the student’s details, assign tutors to a class.
Tutor class- the tutor class is similar to the student class in its attributes. The tutors can also
enroll into the system to check the details of the courses assigned to them and other relevant
information such as the timings, locations of classrooms, etc. the tutor can select the course,
mark a student’s attendance and track the performance of a student.

Event portioning System model for enrollment system
Figure 4 event partitioning system model diagram

Event model description
Event model diagram has depicted the sequence in which a student will use the functionalities of
the enrollment system. The student will first enter the personal details into the system by entering
the name, address, id, and contact details, etc. into the system. All these details will be saved into
the student database and in the next step; the details will be verified by the system. On
completion of the first step, the student can invoke the other event which is to choose the major
and term for the enrollment. The system will first verify the details entered by the system and
then those details will be saved into the enrollment database, the details of which have been
provided in the class diagram. The next step is to choose the courses; the student will request to
display the courses available which will be displayed from the course database. The student then
can make the choices to select 3-4 courses according to his wish. The next event will be invoked
to choose the class timings for the courses the student has adopted. The course database will
check for the availability of class timings and once the class timing gets verified the student can
select the class for the courses. These details will be stored in the enrollment database. The final
event will be triggered in clicking the payment option so that the user can pay for the selected
courses. The payment details after verification will be saved into the enrollment database. Admin
can view and track all three databases, student, enrollment and course database.