Introduction University Record System (URS)

Getting started is the most difficulty part of any A University record system should keep information

new process. about its students and academic staff.
In software modelling, the first thing you need Records for all university members are to include their
Use Case Diagrams

to do is understand what are you going to
model and ultimately develop.
Creating a highest form details about a system-
id number, surname, given name, email, address, date
of birth, and telephone number.
Students and academic staff each have their own unique ID


number: studN (students), acadN (academic employee), where
-use case diagram--is an almost natural point of N is an integer (N> 0).
origin for the software design. I n addition to the attributes mentioned above:

A use case diagram is an excellent way to Students will also have a list of subjects they are enrolled in. A


communicate to management, customers, and student cannot be enrolled in any more than 10 subjects.
other non-development people what a system Academic employees will have a salary, and a list of subjects


will do when it is completed. they teach. An academic can teach no more than 3 subjects.

1 2 3

Some Actions Supported by URS Use Case Diagrams Use Case Diagram - URS System
URS
The system should be able to handle Use Case diagrams show the various



add member
the following commands. activities the users can perform on the
Add and remove university members system. system
del member


System is something that performs a user add subject academic

(students, and academic staff)


function.
Add and Delete subjects del subject


They model the dynamic aspects of the



Assign and Un-assign subjects to students assg subject



system.
Assign and Un-assign subjects to academic


Provides a user’s perspective of the unass subject



staff.
system. enrol subject

unenrol subject
student
4 5 6
 Use Case Diagrams Use Case Diagrams - Actors Use Case Diagrams – Use Cases

A set of ACTORS : roles users can play in An actor is a user of the system playing Use case is a particular activity a user can


interacting with the system.
a particular role. do on the system.
An actor is used to represent something that users


our system. Actor is shown with a stick figure. Is represented by an ellipse.


A set of USE CASES: each describes a possible Following are two use cases for a library


kind of interaction between an actor and the
system. system.
Uses cases are actions that a user takes on a system


A number of RELATIONSHIPS between these

entities (Actors and Use Cases). Borrow Reserve
Relationships are simply illustrated with a line employer employee


client
connecting actors to use cases.
7 8 9

Use Case Diagram – Example1 Use Case Diagram for Student

(Library) Assessment Management System
Use Case Vs Scenarios
library system
Each use case is one or more scenarios.


Grade system
borrow
Add Subject Use Case :


Record
client employee grades Scenario 1 : Subject gets added successfully.


reserve Scenario 2 : Adding the subject fails since the


Student
View grades subject is already in the database.
Order title Enroll Subject Use Case:


Teacher Distribute
Scenario 1 : Student is enrolled for the subject.


Report cards
Scenario 2 : Enrollment fails since the student is


Fine payment
supervisor already enrolled in the subject.
Create report
cards
Printing administrator
Each scenario has a sequence of steps.


A Library System.
10 11 12
 Scenarios Scenarios Use Case Diagrams - Relationships

Each scenario has a sequence of steps. Each scenario has a sequence of steps. Inclusion



Scenario 1 : Student is enrolled for the Scenario 2 : Enrolling fails since the student Inclusion enables to reuse one use case’s steps





subject. is already enrolled in 10 subjects. inside another use case.
Student chooses the “enroll subject” action. Student chooses the “enroll subject” action. Extension





Check the student has enrolled in less than 10 Check the student has enrolled in less than 10 Allows creating a new use case by adding steps to



subjects. subjects. existing use cases
Check if the subject is valid. Return an error message to the student. Generalization



Assign the subject to the student.


Allows child use cases to inherit behavior from


parent use cases

13 14 15

Use Case – Example (self service Use Case – Example (self service machine Use Case – Example (self service machine
machine) – includes relationship) – extends relationship)

<<includes>> <<includes>>
Open Machine Open Machine
Self service machine Restock Restock

Buy a product
Self service machine <<includes>>
customer <<includes>> Close Machine Close Machine
Collect Money
<<extends>>
Collector <<includes>>
Self service machine Open Machine
Collect Restock According
Restock
to Sales
Supplier
<<includes>>
Close Machine
16 17 18
Use Case – Example (self service machine – Use Case – Example (self service machine – Use Case – Example (self service
generalize relationship): Actor-to-Actor generalize relationship): Actor-to-Actor
relationship relationship – example 2 machine)
Buy a
generalized actor generalized actor product Self Service Machine

<<includes>>
customer Open Machine
Restock
Cook
Supplier Agent <<includes>> Close Machine
Restock according to sales
<<includes>>
Open Machine
specialized specialized
Collect
actor actor

Restocker Mom Cook <<includes>>

Collector Father Cook supplier Close Machine

19 20 21

Identify Classes (Extract Nouns) Nouns which are potential classes

A University record system should keep information about A University record system should keep information about



its student s and academic staff. its student s and academic staff .
Records for all university members are to include their id Records for all university members are to include their id



number, surname, given name, email, address, date number, surname, given name, email, address, date
of birth, and telephone number. of birth, and telephone number.
Students and academic staff each have their own unique ID Students and academic staff each have their own unique ID
From Use Case to Classes



number: studN (students), acadN (academic employee), number: studN (students), acadN (academic employee),
where N is an integer (N> 0). where N is an integer (N> 0).
In addition to the attributes mentioned above: In addition to the attributes mentioned above:



Students will also have a list of subjects they are enrolled in. A Students will also have a list of subjects they are enrolled in. A



student cannot be enrolled in any more than 10 subjects. student cannot be enrolled in any more than 10 subjects.
Academic employees will have a salary, and a list of subjects Academic employees will have a salary, and a list of subjects



they teach. An academic can teach no more than 3 subjects. they teach. An academic can teach no more than 3 subjects.

22 23 24
Classes identified in the first pass URS - High Level Class Diagram

UniversityRecordSystem - URS URSDataBase

Student 1

1 has

Academic Staff has

* *
UniversityMembers

UniversityMember Subject
Subject

0…10 0..3

* takes
AcademicStaff Student

1 teaches
25 26