Вы находитесь на странице: 1из 37
See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/299411282

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

Technical Report · May 2015

DOI: 10.13140/RG.2.1.1169.3205

CITATIONS

0

1 author:

5 PUBLICATIONS

0 CITATIONS

READS

3,322

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 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)

SOFTWARE REUSABILITY (WXGC 6302) CASE STUDY Student Registration System (SRS) Domain By: LOAY ALADIB 25-May-2015 I

CASE STUDY

Student Registration System (SRS) Domain

By: LOAY ALADIB

25-May-2015

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

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.

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.

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.

SRS Domain Solutions

Requirements Capture (Part A)

Use Case Diagram

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."

 
 

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.

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

 
 

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.

SRS Class Diagram

SRS Class Diagram 9

Use Case Component (Part A*)

Use Case Component (Part A*) 10

Use Case Model (Login)

Use Case Model (Login) Use Case Model (Registering) 11

Use Case Model (Registering)

Use Case Model (Login) Use Case Model (Registering) 11

Use Case Model (Payment)

Use Case Model (Payment) Use Case Model (Course Circulation) 12

Use Case Model (Course Circulation)

Use Case Model (Payment) Use Case Model (Course Circulation) 12

Use Case Model (Report)

Use Case Model (Report) Use Case Model (Grade) 13

Use Case Model (Grade)

Use Case Model (Report) Use Case Model (Grade) 13

Use Case Model (Notify)

Use Case Model (Notify) Use Case Model (Acquiring) 14

Use Case Model (Acquiring)

Use Case Model (Notify) Use Case Model (Acquiring) 14

Use Case Model (Organizing Course)

Use Case Model (Organizing Course) Use Case Model (Overdue) 15

Use Case Model (Overdue)

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

B) Traceability between the use case component model and the analysis object component model Authentication Management

Registration Management

Registration Management 17

Course Management

Course Management 18

Circulation Management

Circulation Management 19

Grade Management

Grade Management 20

Overdue Management

Overdue Management 21

Payment Management

Payment Management 22

Report Management

Report Management 23

Notification Management

Notification Management 24

Design Component (Part C)

Traceability between the analysis object component model and the design object component model Authentication Management

between the analysis object component model and the design object component model Authentication Management 25

Registration Management

Registration Management 26

Course Management

Course Management 27

Circulation Management

Circulation Management 28

Grade Management

Grade Management 29

Overdue Management

Overdue Management 30

Payment Management

Payment Management 31

Report Management

Report Management 32

Notification Management

Notification Management 33

UML Tools Used

Enterprise architecture 6.5

Visual paradigm 12.1

Reference

Architecture process and organization for business success

34