Chapter Four 4. System Analysis

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 38

CHAPTER FOUR

4. SYSTEM ANALYSIS
4.1. System Model
System modeling helps the analyst to understand the functionality of WKU Department
Placement system. for modeling the system, the object-oriented analysis methodology used,
which includes:

 Actor specification
 Use case diagram
 Use case description
 Sequence diagram
 Class diagram

Generally, it helps the analyses to understand the functionality of the WKU Department
Placement system and it communicates the system with the user.

4.1.1. Use Case Model


A use case describes a sequence of actions that provide something of measurable value to an
actor. This section specifies and describes the actors who participate in WKU Department
Placement system and their descriptions. an actor represents a user of the system and each actor
in the system performs a specific role in the systems.

In this project, there are 6 actors for accessing the system. These are:

 Administrator
 Main Registrar
 College Registrar
 College Dean
 Department Head
 Student
Table 4.1 Actors and their specification

Actor Specification

o Administrator  the system administrator controls/manages the activity of the system:


o create account to the system user

o update account of the system user

o Delete account of the system user

o Post information

o Manage Date (activate and deactivate selection date)

o Main Registrar
o Makes the placement
o disseminates the student list into the colleges
o notify student's placement result after the placement is done
o approve or reject the student Department Change request
o Views comment

o College Registrar o accept student data from the main registrar

o modify account
o Views comment
o Post news

o College Dean o manage department:


 add Department
 update Department
o import student list from the registrar
o view placement
o post news
o modify account
o Views comment

o Department Head Department heads are responsible for:


o give orientation for the student by posting news
o view placement
o modify account
o post, delete and update department information
o Views comment
o Promote department

o Student o views the orientation


o see department placement date
o select a department as their interests
o view their department placement result
o see department information
o Change Department
o View News
o Write Comment

4.1.1.1 Use Case Diagram


The simplest representation of a user's interaction with the WKU Department placement system
that shows the relationship between the user and the different case in which the users are
involved.

WKU Department Placement System

Figure 4. 1 Use case diagram for our system

4.1.1.2 Use Case Description


Table 4.2 Use case Description for Login

Section Purpose
Use Case Name Login
Identifier UC1
Actor Administrator, Main Registrar, College Registrar, College Dean, Department
Head, Student
Description The user enters an authorized user name and password in order to access the
system.
Goal To access the system.
Pre-condition The user should have username and password.
Post-condition The user successfully login to the system.
Basic course of User action System response
action 1. user clicks the login link 2. Display the login page with login

3. Enter the authorized username, form.

password in the login form.


4. Click on login button. 5. Check the authorized
username, password.
6. If the username, password
and role is correct login in the
system
Alternative A: if step 3 is invalid
course of action A1: check the user have username and password

A2: restart from step 3

Table 4.3 Use case Description for Create Account

Section Purpose
Use Case Name Create Account
Identifier UC2
Actor Administrator
Description Creating accounts for the user.
Goal To create account to the user in the system.
Pre –condition Administrator should log in Admin page
Post-condition New account will be created.
Basic course of User action System response
action 1. The admin enters to the system create 2. The System Displays create
account page account page.
3. Open account creation Form.

5. Enter the appropriate 4. Display account creation Form.


information on the form.
7. 7 Check the filled information.
6. Click on account save button
If the filled information is correct
the system creates the new user
account in the system database and
display successful message.
Alternative A: If the filled information is incorrect
course of action A1: the system displays error message

A2: restart from step 5

Table 4.4 Use case Description for update user account

Section Purpose
Use Case Name Update User Account
Identifier UC3
Actor Administrator
Description Allow the administrator to Update accounts.
Goal To change user account in the system.
Pre-condition Administrator should log in to Admin page
Post-condition The account will be Updated.
Basic course of User action System response
action 1 The administrator enters Update User 2 The system displays the Update
Accounts button Account to form.

3 The administrator selects the 5 The system displays successfully


account to be Updated. updated message.

4 The administrator fills in the form and


click update button.

Alternative A: if step 6 is invalid


course of action A1: The system displays the wrong message dialogue and resets the values to

empty.

A2: restart from step 6


Table 4.5 Use case Description for delete user account

Section Purpose
Use Case Name Delete User Account
Identifier UC4
Actor Administrator
Description Allow the administrator to delete accounts.
Goal To delete user account from the system.
Pre-condition Administrator should log in to admin page.
Post-condition The account will be deleted.
Basic course of User action System response
action 1. The administrator clicks delete User 2 The system displays the Account
Accounts button page.
5 The system removes the account
3 The administrator selects the account from the list.
to be deleted.
4 The administrator presses delete
button

Table 4.6 Use case Description for post information

Section Purpose
Use Case Name Post information
Identifier UC5
Actor Administrator, Main Registrar, College Registrar, College Dean, Department
Head
Description Allows the Administrator, Main Registrar, College Registrar, College Dean and
Department Head to post news and information.
Goal To post news and information.
Pre-condition Administrator, College Dean and Department Head need to log in to the system
Post-condition The information is successfully posted.
Basic course of User action System response
action 1 User click post information 2 The system displays post information
button. page.
3 User click browse button. 4 The system displays the file location.

5. User select file and click upload 6 Successfully posted.

button.

Alternative A: if the system displays wrong information


course of A1: directs user to step 5
action
Table 4.7 Use case Description for view orientation

Section Purpose
Use Case Name View orientation
Identifier UC6
Actor Student
Description Allows the student to view orientation of the departments.
Goal To View orientation.
Pre-condition Student need to log in to the system
Post-condition The information is successfully accessed.
Basic course of User action System response
action 1 User click view orientation 2 The system displays view orientation
button. page and department list
3 User select department to see 4 The system displays the orientation.
orientation.

Table 4.8 Use case Description for view date

Section Purpose
Use Case Name View date
Identifier UC7
Actor Student
Description Allows the student to view department selection date.
Goal To View date.
Pre-condition Student need to log in to the system
Post-condition The information is successfully accessed.
Basic course of User action System response
action 1, User click view date button. 2 The system displays view placement
date page and the placement date.

Table 4.9 Use case Description for Select Department

Section Purpose
Use Case Name Select Department
Identifier UC8
Actor Student
Description Allows the student to Select Department.
Goal To Select Department.
Pre-condition Student need to log in to the system
Post-condition The Department selection Successfully submitted .
Basic course of User action System response
action 1 User click Select Department 2 The system displays Department
button. Selection form.
3 User fills the form 5 The system displays Successfully

4 User select submit button. submitted.

Alternative A: If the filled information is incorrect


course of A1: the system displays error message
action
A2: restart from step 3
Table 4.10 Use case Description for view placement

Section Purpose
Use Case Name View placement
Identifier UC9
Actor Administrator, Main Registrar, College Dean, College Registrar, Department
Head, Student
Description Allows the user to view department placement.
Goal To View placement.
Pre-condition user need to log in to the system
Post-condition The information is successfully accessed.
Basic course of User action System response
action 1 User click view placement button. 2 The system displays view placement
3 User enters id number to see page.
placement result. 4 The system searches and displays
department placement result.

Alternative A: If the filled information is incorrect


course of A1: the system displays error message
action
A2: restart from step 3

Table 4.11 Use case Description for Add Department

Section Purpose
Use Case Name Add Department
Identifier UC10
Actor College Dean
Description The College Dean Add Department.
Goal To Add Department on the system.
Pre –condition College Dean should log in
Post-condition New Department will be created.
Basic course of User action System response
action
1. The College Dean enters to the 2. The System Displays Add
system and click on Add Department Department page.
button
3. Open Add Department Form.
4. The System Display Form.
5. Enter the appropriate information on
8. 7 Check the filled information.
the form.
6. Click on Save Department button 8 If the filled information is correct
the system creates the new
Department in the system database
and display successful message.
Alternative A: If the filled information is incorrect
course of action A1: the system displays error message

A2: restart from step 5

Table 4.12 Use case Description for Update Department

Section Purpose
Use Case Name Update Department
Identifier UC11
Actor College Dean
Description The College Dean Update Department.
Goal To Update Department on the system.
Pre –condition College Dean should log in
Post-condition Department will be Updated.
Basic course of User action System response
action 1. The College Dean enters to the 2. The System Displays Update
system and click on Update Department Department page and displays
button Department list.
3. The College Dean select Department.

5. Enter the appropriate information on 4. The System Display Update Form.


the form.
6. Click on update Department button 9. 7 Check the filled information.

If the filled information is correct


the system updates the department
on the system database and display
successful message.
Alternative A: If the filled information is incorrect
course of action A1: the system displays error message

A2: restart from step 5

Table 4.13 Use case Description for Delete Information

Section Purpose
Use Case Name Delete Information
Identifier UC12
Actor Administrator, Main Registrar, College Dean, College Registrar, Department
Head
Description Allow the user to delete information.
Goal To delete information from the system.
Pre-condition user should log in
Post-condition The information will be deleted.
Basic course of User action System response
action 1. The user enters delete Information 2 The system displays the delete
button information page.

3. The user selects the information to be 5.The system removes the


deleted. information from the system.

4. The administrator presses delete


button
Table 4.14 Use case Description for Distribute list

Section Purpose
Use Case Name Distribute list
Identifier UC13
Actor Main Registrar

Description Allows the Main Registrar to send student list to the colleges.

Goal To distribute list to Colleges.

Pre-condition Main Registrar should log in.

Post-condition The list will be distributed.


User action System response
Basic course of action 1. The user Clicks send list button 2 The system displays the college

3. The user selects the college to list page.

send student list. 5. The system displays upload file


form
4. The user clicks on upload list
7. If the file format is correct then
6. user upload student list and system displays successfully sent
presses send button message.
Alternative course of A: If the uploaded file is incorrect
action A1: the system displays error message

A2: restart from step 4

4.1.1.2 Use case Scenario


 Use case Scenario for login:
Participating actors: - Administrator, Main Registrar, College Registrar, College Dean,
Department Head, Student.
When all users want to use the system, they must first log into the system based on their
perspective roll. The user must have valid account. And all users must enter the correct username
and password.

Flow of event

The user run the system and opens the home page and user clicks the login link. Then the
system displays a login form that accepts username and password from the user. The user
enters his/her username and password and user clicks on login button. The System must
validate user name and password, matches the username, password and roll from the
database and matches it with the password. After all, if the entry is correct, system take
the user to his/her page. otherwise the system will display an error message.

 Use case Scenario for Create Account

Participating actor: - Administrator

Flow of Event

The Administrator logs in to the system using his respective accounts and The Administrator
clicks on the Create Account button. Then The system displays the Create account form. The
administrator fills in the details of the new user and submits. The system checks the information filled and
acknowledges. Finally, the account will be created.

4.2. Object Model

Object models describe the system in terms of object classes and their associations, with
common attributes and the services (operations) provided by each object. Visualizes the elements
in a software application in terms of object. It has several major functions in developing a system
like faster development of software, Reduce development risk reduction and reusability.
4.2.1. Class Diagram

We used class diagram to describe the structure of a system by showing the system's classes,
their attributes, operations (methods), and the relationships among objects.
Please fill this space

Figure 4.2 Class Diagram

4.2.2. Data Dictionary


Table 4-1:data dictionary for System Admin table
Field name Data type Constraint Description
AdminID Varchar (30) Primary key It stores system admin id
Fname String Not null It stores first name
Mname String Not null It stores middle name
Lname String Not null It stores last name
Gender Varchar (6) Not null It stores the gender
Phone Integer Not null It stores phone
Email Varchar (30) Not null It stores email
Table 4-2:data dictionary for Student table
Field name Data type Constraint Description
Student ID Varchar (30) Primary key It stores system Student id
Fname String Not null It stores first name
Mname String Not null It stores middle name
Lname String Not null It stores last name
Gender Varchar (6) Not null It stores the gender
age integer Not null It stores student age
Nationality Varchar (30) Not null It stores student Nationality
information
Region Varchar (30) Not null It stores address
Disability Boolean Not null It stores student disability or not
CGPA double Not null It stores student first year CGPA
Phone Integer Not null It stores phone
Email Varchar (30) Not null It stores email

Table 4-3:data dictionary for Main Registrar table


Field name Data type Constraint Description
MRegistrar Varchar (30) Primary key It stores system Main Registrar id
ID
Fname String Not null It stores first name
Mname String Not null It stores middle name
Lname String Not null It stores last name
Gender Varchar (6) Not null It stores the gender
Phone Integer Not null It stores phone
Email Varchar (30) Not null It stores email

Table 4-4:data dictionary for College Registrar table


Field name Data type Constraint Description
CRegistrar Varchar (30) Primary key It stores system College Registrar id
ID
Fname String Not null It stores first name
Mname String Not null It stores middle name
Lname String Not null It stores last name
Gender Varchar (6) Not null It stores the gender
Phone Integer Not null It stores phone
Email Varchar (30) Not null It stores email
College ID Varchar (30) Foreign key It stores College primary key

Table 4-5:data dictionary for College Dean table


Field name Data type Constraint Description
Dean ID Varchar (30) Primary key It stores system College Dean id
Fname String Not null It stores first name

Mname String Not null It stores middle name


Lname String Not null It stores last name
Gender Varchar (6) Not null It stores the gender
Phone Varchar (30) Not null It stores phone
Email Integer Not null It stores email
College ID Varchar (30) Foreign key It stores College primary key

Table 4-6:data dictionary for Department Head table


Field name Data type Constraint Description
Head ID Varchar (30) Primary key It stores system Department Head
id
Fname String Not null It stores first name
Mname String Not null It stores middle name
Lname String Not null It stores last name
Gender Varchar (6) Not null It stores the gender
Phone Integer Not null It stores phone
Email Varchar (30) Not null It stores email
Department ID Varchar (30) Foreign key It stores Department foreign key

Table 4-7:data dictionary for comment table


Field name Data type Constraint Description
content text Not null It stores the content of comment
Comment Date Date Current timestamp It stores the date of notification
Student ID Varchar() Foreign key It stores the primary key of Student
table

Table 4-8:data dictionary for news table


Field name Data type Constraint Description
content text Not null It stores the content of comment
news Date Date Current timestamp It stores the date of news
AdminID Varchar(30) Foreign key It stores the primary key of Admin
table
Table 4-9:data dictionary for Selection Date table
Field name Data type Constraint Description

Content text Not null It stores the content of comment


Selection Date Date Current timestamp It stores the date of selection
AdminID Varchar(30) Foreign key It stores the primary key of Admin
table

Table 4-10:data dictionary for placement table


Field name Data type Constraint Description
placement ID Varchar (30) Primary key It stores placement id
Student ID Varchar (30) Foreign key It stores the Foreign key of student
table
Department ID Varchar (30) Foreign key It stores the primary key of
department table

Table 4-11:data dictionary for College table


Field name Data type Constraint Description
College ID Varchar (30) Primary key It stores college id
college Name Varchar (30) Not null It stores the college
Table 4-12:data dictionary for Department table
Field name Data type Constraint Description
Department ID Varchar (30) Primary key It stores Department id
Department Name Varchar (30) Not null It stores the Department
College ID Varchar (30) Foreign key It stores the primary key of college
table

Table 4-13:data dictionary for Account table


Field name Data type Constraint Description
Username Varchar (30) Unique It stores username
Password Varchar (30) Not null It stores password
Student ID Varchar (30) Foreign key stores primary key of Student table
MRegistrar ID Varchar (30) Foreign key stores primary key of Main
Registrar table
CRegistrar ID Varchar (30) Foreign key stores primary key of College
Registrar table
AdminID Varchar (30) Foreign key stores primary key of Admin table

Dean ID Varchar (30) Foreign key stores primary key of College


Dean table
Head ID Varchar (30) Foreign key stores primary key of Department
Head table

4.5. Dynamic Model


Dynamic model, represented in UML with sequence diagrams, collaboration diagrams, state
chart diagrams, and activity diagrams, describes the internal behavior of the system. Sequence
diagrams describe behavior as a sequence of messages exchanged among a set of objects,
whereas state chart diagrams describe behavior in terms of an individual object and the possible
transaction between states.

We are going to use sequence diagrams, and activity diagrams only from the dynamic parts of
UML diagrams.

4.5.1. Sequence Diagram


Sequence diagram showing the sequence of interactions among objects and used to represent or
model the flow of messages, events and actions between the objects or components of a system.
Sequence Diagrams are also used primarily to design, document and validate the architecture and
interfaces of the system by describing the sequence of actions that need to be performed to
complete a task or scenario.

Figure 4. 3 Sequence diagram for Login


Figure 4. 4 Sequence diagram for Create Account
Figure 4. 5 Sequence diagram for Update Account
Figure 4. 6 Sequence diagram for Delete User Account
Figure 4. 7 Sequence diagram for Post Information
Figure 4. 8 Sequence diagram for View Orientation
Figure 4. 9 Sequence diagram for Select Department
Figure 4. 10 Sequence diagram for View Placement
Figure 4. 11 Sequence diagram for Add Department
Figure 4. 12 Sequence diagram for Update Department
4.5.2. Activity Diagram

Figure 4. 13 Activity diagram for Login


Figure 4. 14 Activity diagram for Create Account
Figure 4. 15 Activity diagram for Update Account
Figure 4. 16 Activity diagram for post information
Figure 4. 17 Activity diagram view orientation
Figure 4. 17 Activity diagram Department selection

4.5.3. State Chart Diagram


A state diagram is used to represent the condition of the system or part of the system at finite
instances of time. It’s a behavioral diagram and it represents the behavior using finite state
transitions. State diagrams are also referred to as State machines and State-chart Diagrams.
These terms are often used interchangeably. So simply, a state diagram is used to model the
dynamic behavior of a class in response to time and changing external stimuli. We can say that
each and every class has a state but we don’t model every class using State diagrams. We prefer
to model the states with three or more states.
Uses of state chart diagram –
o We use it to state the events responsible for change in state (we do not show what
processes cause those events).
o We use it to model the dynamic behavior of the system.
o To understand the reaction of objects/classes to internal or external stimuli.

You might also like