See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/299411282

Case Study of Student Registration System (SRS) Domain

Technical Report · May 2015

DOI: 10.13140/RG.2.1.1169.3205

CITATIONS READS

0 3,322

1 author:

Loay Aladib
University of Malaya
5 PUBLICATIONS   0 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Pattern Detection and Design Rationale Traceability: An Integrated Approach to Software Design Quality. View project

All content following this page was uploaded by Loay Aladib on 25 March 2016.

The user has requested enhancement of the downloaded file.

 SOFTWARE REUSABILITY (WXGC 6302)

CASE STUDY

Student Registration System (SRS)

Domain

25-May-2015

By: LOAY ALADIB

I
 TABLE OF CONTENTS

SRS Domain Description ........................................................................................................................................ 1

Requirements Capture (Part A)........................................................................................................................... 2
SRS Use Case Diagram .................................................................................................................................. 2
SRS Class Diagram ........................................................................................................................................ 2
Use Case Components (Part A*) .................................................................................................................... 2
Robustness Analysis (Part B) ............................................................................................................................. 3
Design Phase (Part C) ......................................................................................................................................... 3
SRS Domain Solutions ........................................................................................................................................... 4
Requirements Capture (Part A)........................................................................................................................... 4
Use Case Diagram .......................................................................................................................................... 4
SRS Class Diagram ........................................................................................................................................ 9
Use Case Component (Part A*) .................................................................................................................... 10
Analysis Component (Part B) ........................................................................................................................... 16
Authentication Management ......................................................................................................................... 16
Registration Management ............................................................................................................................. 17
Course Management ..................................................................................................................................... 18
Circulation Management .............................................................................................................................. 19
Grade Management ....................................................................................................................................... 20
Overdue Management ................................................................................................................................... 21
Payment Management .................................................................................................................................. 22
Report Management ..................................................................................................................................... 23
Notification Management ............................................................................................................................. 24
Design Component (Part C).............................................................................................................................. 25
Authentication Management ......................................................................................................................... 25
Registration Management ............................................................................................................................. 26
Course Management ..................................................................................................................................... 27
Circulation Management .............................................................................................................................. 28
Grade Management ....................................................................................................................................... 29
Overdue Management ................................................................................................................................... 30
Payment Management .................................................................................................................................. 31
Report Management ..................................................................................................................................... 32
Notification Management ............................................................................................................................. 33
UML Tools Used .................................................................................................................................................. 34
Reference .............................................................................................................................................................. 34

II
SRS Domain Description

As Head of the component system engineering team for a software company, that are
tasked with modeling a reusable component system for a Student Registration System (SRS)
domain that should cover requirements capture, robustness analysis, and design.
The company would like the component system to be highly effective to be reusable
and customizable for developing a new student registration system that would be able to deploy
on any operation system platform.
The newly customized system will allow students to register for courses and view their
semester results from any type of computer device that attaches to any type of campus
networks. Lecturers will be able to access the system to sign in to access to the courses that
have been assigned to them as well as to record grades. The component system should allow
all courses offered by any educational institutions to be maintained up-to-date, and can be
accessible through the Internet.
The registrar’s office will maintain course information and grades through dedicated
user interfaces. At the beginning of each semester, students may request/access a list of course
offerings for the semester. Information about each course, such as lecturers, departments, and
any prerequisites, will be included to help students make informed decisions.
Educational institutions should be able to allow students to sign in to select a number
of course offerings for the semester. Each course offering will limit to a maximum number and
a minimum number of students. A course offering with fewer than the minimum number of
students will be canceled.
Students can change their registered courses during the first 2 weeks of the semester.
Therefore, they must be able to gain access to the system during this time to add or drop
courses. Once the registration process is completed for a student, the system will send the
information to the billing system so he or she can be billed for the semester. If a course fills up
during the registration process, the student must be notified of a selected course is submitted
for processing. At the end of the semester, the students will be able to access the system to
view an electronic report card containing the grades of all courses taken by him or her. Since
grades are sensitive information, the system must employ extra security measures to prevent
unauthorized access.

1
 Lecturers must be able to see which students who had signed up for their course
offerings. In addition, the lecturers will be able to record and view the grades of courses taken
by the students in their classes.

By using the various modeling constructs of UML/OOSE for component modeling

analysiz these tasks as follows:

Requirements Capture (Part A)

SRS Use Case Diagram

o Model a complete use case diagram for the student reiteration system by including,
the use cases and requirements described in the system.
o The generalization and include/exclude relationships must be considered in your
diagram based on SRS domain.
o Use case description for each use case must be converted to the flow of events
“paths” which shows the actor actions and system responses and set the priority of
each use case.

SRS Class Diagram

o Model a domain class diagram to show the structure of student registration system.
o Show the explicitly the class attributes and operations and also the relationships
between the classes, multiplicity specifications, and other model elements that you
find appropriate.

Use Case Components (Part A*)

o Analyze the problem domain of the SRS, including investigating and analyzing the
most common cases of the specific student registration system from other sources,
o Model, a domain component to show the structure of the student registration system
that should be traceable to between all use case components.
o Model each use case with identifying the common functionally and variable
functionality into a use case component system model that is to an analysis model
component system model.

2
Robustness Analysis (Part B)

 Continue with the analysis phase from (Part A*) for the purpose of documenting the
analysis component system model using relevant analysis techniques, considering also
the development and communication platforms.
 Include traceability between the use case component system model and the analysis
component system model, which should be detailed to the level of component
traceability between the two models.
 Variable features specific to the various cases of the SRS should be taken into account
in both the use case component system and analysis component system models for
modeling variants and variability points.
 Illustrate the modeling of developing two separate student registration application
systems of different educational institutions by reuse suitable components (with or
without variability points) of the analysis component system model through façades
and using the UML/OOSE import statement. Demonstrate appropriate
customization/adaptation of components and variable features into these application
systems.

Design Phase (Part C)

 Continue with the design phase from (Part B) for the purpose of documenting a design
component system model using relevant design techniques, considering also the
development and communication platforms.
 Include also traceability between the analysis component system model and the design
component system model, which should be detailed to the level of components
traceability between the two models.

3
SRS Domain Solutions
Requirements Capture (Part A)
Use Case Diagram

4
Use Case Description
1- Register for a course

Element Description
Use Case Name Register for a course
Use Case ID UC10
Priority High
Actor(s) Student
Description This use case allows a Student to register for course
offerings in the current semester. The Student can
also modify or delete course selections if changes are
made within add/drop period at the beginning of the
semester "two weeks”. The course catalog System
provides a list of all the course offerings for the
current semester.
Precondition(s) The student has logged onto the system
Post-condition(s) There are no post-conditions associated with this use
case.
Flow of events: Actor Action System Responses

1- The student
selects the
"maintain
schedule" activity
from the main
form
2- The student
selects “create
schedule”
3- The system displays a
blank schedule form.
4- The system retrieves a
list of available course
offerings from the
course catalog
System.
5- The student
selects 4 primary
course offerings
and 2 alternate
course offerings
from the list of
available
offerings. Once
the selections are
complete the
student selects
"submit."

5
 6- The "add course
offering" sub-
flow is performed
at this step for
each selected
course offering.
7- The system saves the
schedule.

Alternative Flows: Modify a Schedule 1- The student selects

"modify the
schedule."

2- The system retrieves

and displays the Student’s
current schedule (e.g., The
schedule for the current
semester).

3- The system retrieves a

list of all the course
offerings available for the
current semester from the
course catalog system. The
system displays the list to
the student.
4- The student can
then modify the
course selections by
deleting and adding
new courses. The
Student selects the
courses to add from
the list of available
courses. The student
also selects any course
offerings to delete
from the existing
schedule. Once the
edits are complete the
student selects
"submit".
5- The "add course
offering" sub-flow is
performed at this step
for each selected
course offering.
6- The system saves the
schedule.

6
Delete a Schedule 1- The student selects
the "delete the
schedule" activity.
2- The system retrieves
and displays the Student
current schedule.
3- The student selects
"delete."
4- The system prompts the
Student to verify the
deletion.
5- The student verifies
the deletion.
6- The system deletes the
schedule.
Save a Schedule: At any point, the student may choose to save a schedule without submitting it by
selecting "save". The current schedule is saved, but the student is not added to any of the selected course
offerings. The course offerings are marked as "selected" in the schedule.
Add Course Offering: The system verifies that the Student has the necessary prerequisites and that the
course offering is open. The system then adds the Student to the selected course offering. The course
offering is marked as "enrolled in" in the schedule.
Unfulfilled Prerequisites or Course Full: If in the "add course" sub-flow the system determines that
the Student has not satisfied the necessary prerequisites or that the selected course offering is full, an error
message is displayed. The Student can either select a different course offering or cancel the operation, at
which point the use case is restarted.
No Schedule Found: If in the "modify a schedule" or "delete a schedule" sub-flows the system is unable
to retrieve the student’s schedule, an error message is displayed. The student acknowledges the error and
the use case is restarted.
Course Catalog System Unavailable: If the system is unable to communicate with the course catalog
system after a specified number of tries, the system will display an error message to the student. The student
acknowledges the error message and the use case terminates.
Course Registration Closed: If, when the student selects "maintain schedule", registration for the
current semester has been closed, a message is displayed in the Student and the use case terminates.
Students cannot register for courses after registration for the current semester has been closed.

2- Submit record grades

Element Description
Use Case Name Submit record grades
Use Case ID UC-04
Priority High
Actor(s) Lecture
Description This use case allows a professor to submit student
grades for one or more classes completed in the
previous semester.
Precondition(s) The lecture ‘professor’ has logged onto the system.
Post-condition(s) There are no post-conditions associated with this use
case.
Flow of events: Actor Action System Responses
1- The professor
selects the "submit

7
 grades" activity from
the main Form.
2- The system displays a
list of course offerings the
Professor taught in the
previous semester.
3- The professor
selects a course
offering.

4- The system retrieves a

list of all students who
were registered for the
course offering. The
system also retrieves the
grade information for each
student in the offering.
5- The system displays
each student and any grade
that was previously
assigned for the offering.

6- For each student on

the list, the Professor
enters a grade: A, B, C,
D, F, or I. The system
records the student’s
grade for the course
offering. If the
Professor wishes to
skip a particular
student, the grade
information can be left
blank and filled in at a
later time. The
professor may also
change the grade for a
student by entering a
new grade.
Alternative flows: no courses taught: If in the basic flow, the professor did not teach any course
offerings in the previous semester the system displays an error message and the use case ends.
Course canceled: If too many students withdrew from the course during the add/drop period and the
course was canceled after the beginning of the semester, the system displays an error message. If the
professor chooses to cancel the operation the use case terminates, otherwise is restarted at step 2 of the
basic flow.

8
SRS Class Diagram

9
Use Case Component (Part A*)

10
Use Case Model (Login)

Use Case Model (Registering)

11
Use Case Model (Payment)

Use Case Model (Course Circulation)

12
Use Case Model (Report)

Use Case Model (Grade)

13
Use Case Model (Notify)

Use Case Model (Acquiring)

14
Use Case Model (Organizing Course)

Use Case Model (Overdue)

15
Analysis Component (Part B)
Traceability between the use case component model and the analysis object component model

Authentication Management

16
Registration Management

17
Course Management

18
Circulation Management

19
Grade Management

20
Overdue Management

21
Payment Management

22
Report Management

23
Notification Management

24
Design Component (Part C)
Traceability between the analysis object component model and the design object component model

Authentication Management

25
Registration Management

26
Course Management

27
Circulation Management

28
Grade Management

29
Overdue Management

30
Payment Management

31
Report Management

32
Notification Management

33
 UML Tools Used

 Enterprise architecture 6.5

 Visual paradigm 12.1

Reference

 Architecture process and organization for business success

34

View publication stats