Software Architecture and Desig Part of Family Follow Ups

WEB BASED FAMILY FOLLOW UP SYSTEM FOR HARAMAYA UNIVERSITY MODEL SCHOOL
COLLEGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF SOFTWARE ENGINEERING
“Web Based Family Student Follow-up management system for Haramaya

University model School”
Group members
No. Name ID
1 Zeleke Niguse 0648/09
2 Dufera Bekele 0668/09
3 Mulgeta Ayana 0669/09
4 Daniel Tsegaye 0677/09
5 Dinaol Takala 520/08
6 Abdi Waqwaya 0699/09
Advisor’s Name: Mr.Afendi Abdi
A senior project submitted to Department of Software Engineering, College of

Computing and Informatics, Haramaya University, in Partial fulfillment for the
requirement of the Degree of Bachelor Science in Software Engineering.
Haramaya, Ethiopia
February 10, 2020
1|Page
Contents
CHAPTER ONE..............................................................................................................................................5
1.INTRODUCTION........................................................................................................................................5
1.1 Purpose of the document......................................................................................................................5
1.2 Scope of the Project...........................................................................................................................6
1.3 Overview...........................................................................................................................................8
1.4 Reference materials...........................................................................................................................8
1.5 Definitions and Acronyms.................................................................................................................9
CHAPTER TWO..........................................................................................................................................10
SYSTEM OVERVIEW...................................................................................................................................10
CHAPTER THREE........................................................................................................................................12
3.SYSTEM ARCHITECTURE..........................................................................................................................12
3.1 Architectural Design...........................................................................................................................12
3.1.1 Overall system modular architecture............................................................................................13
3.1.1 Component descriptions...........................................................................................................14
3.1.2 Systems’ subsystem model/ Logical view of the system...........................................................15
3.2 Decomposition Description.........................................................................................................16
3.3 Design rationale...............................................................................................................................21
CHAPTER FOUR..........................................................................................................................................22
DATA DESIGN.............................................................................................................................................22
4.1 Data description...............................................................................................................................23
4.2 Data dictionary................................................................................................................................24
CHAPTER FIVE............................................................................................................................................27
COMPONENT DESIGN................................................................................................................................27
5.1 Object Diagrams..............................................................................................................................27
5.2 Collaboration/communication diagram............................................................................................28
5.3 Component Diagram........................................................................................................................29
...............................................................................................................................................................30
5.4 Deployment diagram.......................................................................................................................30
5.5 Activity diagram..............................................................................................................................32
5.6 Sequence diagrams..........................................................................................................................39
ii | P a g e
5.7 Class Diagram.................................................................................................................................44

5.8 Statecchart diagram.........................................................................................................................44
5.9 Pseudo Code/ Algorithm..................................................................................................................45
CHAPTER SIX..............................................................................................................................................49
HUMAN INTERFACE DESIGN......................................................................................................................49
6.1. Overview of User Interface.............................................................................................................49
6.2 Screen Images..................................................................................................................................50
6.3 Screen objects and actions...............................................................................................................52
6.4 Requirements matrix........................................................................................................................53
Appendix...................................................................................................................................................54
iii | P a g e
List of Figures and Tables
Fig 3. 1 System layered architectural design.............................................................................14

Fig 3. 2 Logical view of the system.............................................................................................16
Y
Table 4. 1Data description..........................................................................................................23

Table 4. 2 Description:detail of student......................................................................................24
Table 4. 3Description:Details of Registrar.................................................................................24
Table 4. 4 Description:Detail of Parents....................................................................................25
Table 4. 5 Description:Detail of Admin......................................................................................26
Fig 5. 1 Object diagram of Admin..............................................................................................28
Fig 5. 2 Collaboration diagrams for Registrar..........................................................................30
Fig 5. 3Component diagram of our system................................................................................31
Fig 5. 4 Deployment diagram of our system..............................................................................32
Fig 5. 5 Activity diagram Create account..................................................................................35
Fig 5. 6 Activity diagram to view report....................................................................................36
Fig 5. 7 Activity diagram Record officer to Update report......................................................37
Fig 5. 8 Activity diagram for insert result.................................................................................38
Fig 5. 9Activity diagram for the record officer to prepare transcript....................................39
Fig 5. 10 Sequence diagram Create account..............................................................................40
Fig 5. 11 sequence diagram Insert attendance..........................................................................41
Fig 5. 12 Sequence diagram for Insert Result...........................................................................42
Fig 5. 13 Sequence diagram for Generate report......................................................................43
Fig 5. 14 Sequence diagram for View Report............................................................................44
Fig 5. 15 Class diagram of our system........................................................................................45
Fig 5. 16 State chart diagram for login......................................................................................46
Figure 6. 1 User interface for home page...................................................................................50

Figure 6. 2 User interface for create account form...................................................................51
Figure 6. 3 User interface for teacher student assessment form …………………………………………………………52
4|Page
CHAPTER ONE
1. INTRODUCTION
1.1 Purpose of the document
This software design document describes the architecture and system design of web based
family-student follow up system for Hu model school. The basic purpose of this system is to
analysis, modeling or designing and developing the software that simplify the manual base work
of the model school regarding to family follow their students. Additionally, Additionally, it helps
the students to see their results or grades and makes the user to use the web based application
familiarity.
This web based family follow up system enables the admin or the system administrator to
create ,update and delete the user accounts and responsible for managing and administering of
the whole school in appropriate way and perform the process throughout the systems
functionality. It is used for all actors exist in the system development. These intended users are
as follows:-
Basically this subtopic is concerning to the beneficiaries of the developed products, so

depending up on this the following are identified:-
Students:-They use this system for learning and also they can see the computed result and their
behaviour with respective course.
Registrar:-While the registrar want to register students,approve application and registration

report he/she will used this web based system for doing their respective works.
Record officer: Record officier is also beneficieries with this proposed systems and he can do
his/her responsibility like generate report, prepare transcript, and update report easily.
Parent:The parent is also easily follow their children by using this proposed web based
system.for viewing report, view their student result, view their student attendance, give comment
and view comment this proposed system is a good way.Rather they go to school physically they
can follow their children by this online system.
Guest: Guest is anyone capable of using a web-based system to explore the non-members' area
of the system.Home room teacher also use this system to insert student result,insert attendance
,prepare report card, give comment and view comment.
5|Page
Administrator of the system usability: Simple way of controlling all other employer in system
and for simple way of managing the task performed..
1.2 Scope of the Project

The scope of our project is to make the system web based system where registered parents have
access to student’s profile and information’s such as assessment, final result, and get information
on the student in concern submitted by the teacher. The teachers also have the access and
obligation to regularly update the status of the student in uploading every score, absence,
lateness. This system is applicable only for Haramaya university model school teachers, students,
parents and record officer.
Specifically the scope of our projects include
 Administrator manages all the users participated in the system usability that create
account and remove account.
 Home room teacher Insert Attendance, insert result, Prepare report card, insert
Assessment, comment and view comment.
 Registrar take a responsibility in Registration of students, Approved Application,
Regisration report.
 Record officer generate report, prepare transcript, and update report.
 Teachers also have the access and obligation to regularly update the status of the student
in uploading every score, absence, lateness.
 Parent view report, view their student result, view their student attendance, give
comment and view comment.
 The student is recommended to register before access the system.
 No manual work of preparing and storing the result information.
The goal of our project is by solving the problems of manual based family-student follow up
system and achieve to developed and implemented to be proposed and automated computer
based for HU family-student follow up system.
6|Page
Objectives,
General objective
The general objective of this project is to design and implement a web based family-student
follow up system for Haramaya University Model School.
Specific Objectives
In order to achieve the general objective the following specific objectives are needed:-
 Understanding the existing system to see how the actors interact to each other and
pointing the areas of weakness to be improved.
 Gathering requirement specifications and analyzing them.
 Designing the proposed system and sub systems according to the requirement analysis.
 Designing and implementing the whole system.
 Building the system that implements the designs and compile full documentation.
 Allow the parents as they enable to follow their student’s result,attendance and lateness.
The relevant benefits of our projects are: -
 The students can have good behavior.

 Parents control their children easily.
 Parent and school communications is efficient and effective.
 Parents know their Childs status in school.
 The students can success their goal or aim.
 It supports the student to attend in the class every day.
 Making students more successful and disciplined from school.
 Gave more relation between school and parent communication.
 The students are attending in class properly.
7|Page
1.3 Overview
The following section of this specification document will give the general description related to the product
under discussion. It will provide information about the specific requirements including detailed functional,
non-functional and database requirements. The rest of the document is organized as follows:-
1. The general factors that affect the product under discussion product interfaces, constraints, assumptions
and dependencies will be under the heading “Overall Description”.
2. In the next section which is named “specific Requirements”, detailed functional requirements,
design constraints and product attributes will be discussed.
Sequencially,Any one who is interested to read this document, the better way is to start from introduction
because the introduction clearly states the aim of this document and for what purpose the document is
written for.
For system developers there is use case diagram that help them to understand the system functionality using
standard UML diagram. The sections are divided based on the IEEE templet and there is a section that use
to illustrate the meaning of the use case so, you can see that for better understanding of the use case or
about the system functionality.
They recommended to begin from most important section,overview sections then scope of our project and
then product functionality,and after that design and implementations constraints and then the requirements
including FR and non-functional and lastly use case design with corresponding actors functionality
between them.
1.4 Reference materials
1. System analysis and design method, 6th edition.
2. HU model school record officer file and school profiles.
3.Bruegge, B. and Allen Dutoit. 1999. Object Oriented Software Engineering: Conquering Complex and
Changing Systems. Prentice hall PTR
4. A.Hoffer. (2007). Modern Systems Analysis and Design (6th Edition).
5.Ambler, S.W.2001. The Object Primer, 2nd edition. The application Developer’s Guide to Object
8|Page
Oriented and the UML. Cambridge: Cambridge University Press
6.http://www.visual-paradigm.com/product/vpuml/features/behavioralmodeling.jsp Retrieved on
September, 2017.
7.http://creately.com/diagram-type/article/simple-guidelines-drawing-uml-class-diagrams Retrieved on
September, 2017.
1.5 Definitions and Acronyms

Basic Terms with description:
HUMS:Haramaya university model school
CBD:Common Based Development.
HUMSFFUS:Haramaya university model school family follow up system
FFUP:family follow up system
DEC:Decision
OR:Office recorder
HRT:Home room teacher
PK:Primary key
BR: business rule
CPU: Central Processing Unit
FR: Functional Requirement
HTTP: Hypertext Transfer Protocol
MYSQL: My Standard Query Language.
NFR : Nonfunctional Requirement
OOSAD: Object Oriented System Analysis and Design.
PHP: Hypertext Preprocessor
RAM: Random Access Memory.
9|Page
CHAPTER TWO
SYSTEM OVERVIEW
The proposed system is a web based system that allows, the parents who have an account to
access the students’ data and get information on the student in concern uploaded by the
teacher. The teachers also have the access and obligation to regularly update the status of the
student in uploading every score, absence, lateness and also the teacher and the parent are
communicated each other easily in the school learning process by sending and receiving
message.
In general the proposed system has the following importance.
 Fast rate of operation and excellent response time.
 The system is flexible i.e. it can be accessed at anytime and anywhere.
 Minimizes the wastage of resource.
 Makes the task easy and interactive.
 It provides easy data storage and management.
The Overall indication of our system describes and able to show the product developed
regarding Haramaya University Model school family follow up system in their academic area.
The system also has different actors or stake holder who is usable from the produce system
development the time of delivery as much as possible. These requirements and actors with
their scope of work have been described in the following scenarios.
The requirements are as follows:
A. Users/Actors: -
a).Login to the system through the first page of the application
b).Change the password after login to the application (Optional) and each actor in his/her
dashboard perform the basic task given to them.
After the end of their use case or function they can logout.
c).See his/her details and change it (Optional)
d).help from the system
B. Administrator:-
a).Should be able to register new unauthorized user.
b).Should be able to change any of the editable details for follow up related work.
This HUWBFFS has a fast functionality in consideration of academic area. The lists of
10 | P a g e
operations (functions) that can be made by this system can be seen in terms of the actor
performance /work.
Register (admin can register the Teacher, Registrar,Record officer and parents in to the
system), delete the account, Update the account.In this system the users are signup to the
system first.
 The student registered by using computer based system.
 The parent can check the student’s progress by using online and by computer based system.
 The overall result will be viewed twice a year and the parents have not to be physically present.
 Attendance is taken in the morning and afternoon at the first period any latecomers will be allowed
to only three strikes and then the school will contact the parents and let them know what is going
on. If the student is absent the first time he/she will sign a form without the parents present and if
happens the second time the parent has to be present and will sign the form of showing his/her
know-how of the situation, the parent will also state the reason why the student was absent besides
signing a form.
 For every action, the school takes on the student the parents have not to be physically present so
that they will take full responsibility,because they follow their students through web based system.
Our system also performed the tasks such as,
 The Record officer can, generate transcript, update report a students’ detail and prepare final
report.
 The Admin account (i.e., create, update, activate, deactivate, delete the user account), the
Admin can view change password, view feedback and the home room teacher can add
attendance of the student, view report.
 The parent can view report,See attendance, see student result and add notification. To access
the service where registered parents have access to student’s profile and get information on
the student in concern uploaded by the teacher.
 The new proposed system which is called web based parent-student follow up system for
Haramaya University Model School which solves the problems of the existing system.
The design of our project describes the process of designing our system by data flow diagram and
designing process.
11 | P a g e
CHAPTER THREE
3.SYSTEM ARCHITECTURE
A system architecture is the conceptual model that defines structural, behavioral and more views of the
system. Architecture is the formal description and representation of a system, organized in a way that
supports reasoning about the structures and behavior of the system. A system architecture can consist of
system components and sub-system developed, that will work together to implement the overall system.
In our cases the system architecture is the conceptual model that defines the follow up system
structure,behaviour and views.
3.1 Architectural Design

This is the general architecture of our system that we are going to develop on HUFSFS in general
description for our reader.
The system allows the user to access the database through the web browser on client side via secured or
open network connection. Once the system files are stored on the database it can be accessed. The side of
application server/web server consists of XAMPP Server/WAMPP Server that enables the user to be
usability of the product developed. Servers will response to users request through internet service. This all
communication process is accomplished after the user information. The students and the parents in are the
users of the system as the follow this proposed architecture.
12 | P a g e
3.1.1 Overall system modular architecture

The overall system modular architecture of our system is as follows,
PRESENTATION LAYER
ADMINISTRATOR MODULE
TEACHER, HOME ROOM TEACHER
MODULE RECORD OFFICER

HU MS FFS
PARENT
REGISTRAR
SERVER
XAMPP/WAMPP/APACHE SERVER
ORAGE SERVICE DATABASE
Fig 3. 1 System layered architectural design
13 | P a g e
3.1.1 Component descriptions

Basically, since system architecture enables the user to use according to they send a request to the server
side once they have been authorized in area of their dashboard. The main components of our system are
the following:-
 Administrator
 Home room teacher
 Registrar
 Record Officer
 Parent
 Teacher
Administrator: System administrator has the responsibility to control the system in all and the
stakeholders those interact with the application. Admin manages the newly coming user and modify the
users exist as the complete or fail to apply in the system. Every users in the system has to full fill the
necessary information to be registered by the admin. The accessibility of the data is impossible unless the
user is authorized by an admin.
Home room teacher: This is responsible for give and insert Attendance,Prepare the student result, Prepare
report card,Prepare and insert Assessment,write comment and view comment.
Registrar this is responsible for Registration of students, Approved Application, Registeration report.
Record officer: This are responsible for generate report and update report.
Parent: Is responsible for viewing report, view student result, view student attendance, give comment and
view comment.
Teacher: is who insert student assessment and write comment.
14 | P a g e
3.1.2 Systems’ subsystem model/ Logical view of the system
The decomposition of the overall system with the subsystem that will exist in our system software is
described as follows:
FFS
HR Teacher Record
Admin Parent Registrar
officer
Insert Registe Prepar

Vw result rStuden Transcrip
Creat attendan t t
e
accoun ce
t Prepare
report card Approved Generat
Remov Applicatio ereport
e
accoun n
t view Insert
report Assesment
Registration
Update
Insert Repor report
attendance t
View
student
result Give
Comment
View
View
Comment
Comment
Give
Comment
Fig 3. 2 Logical view of the system
15 | P a g e
The system decomposition with the entire component is necessary refined for of the system simplification
while readers need to understand the system easily. The system decomposition is the breaking down of the
module exists in a system. The help with the diagram makes the user to be familiar with the project product
they are going to build. The basic functionality and message flow in between the system and the user can
also be dedicated through the decomposition diagram. The component appears in the project product has a
role in respective area of their task. The breaking down of the systems components can be explained via the
UML diagrams. Since the users of this system has the special understanding when they are supported by
graphical interfaces.
3.2 Decomposition Description
3.2.1Administrator
Identification Administrator
Type Component
Purpose System needs to be administrated by an admin to be usable by other. And also

controls all the users and exist in the system. Enable the system as whole.
Function Apply in different area of the system ( create account for others,
manages users, control system).
Subordinates Internally there may be an administrator has his/her individual profile, has
different qualification of education level. Have classes manage User and create
Account.
Dependencies This Administrator component is based on all the systems component

performance.
16 | P a g e
Interface Admin page to apply profile update add and removes account for users.
Resource The resources we have used in the systems include both hardware and software
that may this administrator component used in the produced system. (Time,
Computer Memory, Database Server, Xammp Software, Computer).
Process The administrator has followed many steps or procedure to perform the tasks
given to him/her.
First of all enable the system and initiate the system. The he/she will enter by
his/her username and password to see the system confortability .
Data The data that entered by an administrator to the database are stored in respective
table those later accessed while the manager want to view users information.
14
17 | P a g e
3.2.2 Home room teacher
Identification Home room teacher
Type Component
Purpose In academic area he/she teaches the student as per the rules and regulation of the
organization.
This is responsible for take and insert Attendance,Prepare the student result,
Prepare report card,Prepare and insert Assessment,write comment and view
Function comment.
Teacher has also different series of classes and subclasses such as give additional
Subordinates learn for students..
Dependencies While he/she give learning. he/she should have to depend/based on

the course objectives he/she taught. Not beyond the course contents.
Interface He/she should have to use he/his username to enter in to his/her

dashboard to give education for students
Resource The resources we have used in the systems include both hardware and software
Process The procedure for the home room teacher will start while he/she is registered for
18 | P a g e
the course
to teach the student.
Data His/her account. All the action done by an home room teacher is stored in
Database
15
19 | P a g e
3.2.3 Registrar
Identification
Registrar
Type Component
Purpose Registering students that can be done by it should have to be checked and approved
Different operations can performed by registrar those are approved

Function application,register students,report register.
Subordinates The classes and subclasses is displayed in record officer for check as registered
Dependencies He/she should have to depend on the account created by admin
Interfaces The interfaces starting from home page with username and password.
Resources The resources we have used in the systems include both hardware and software
Process It own process/procedure while perform the task.
Registrar data is based on the database of the admin create account for them and its
Data data is stored on database.
20 | P a g e
21 | P a g e
22
3.3 Design rationale

A design rationale is an explicit documentation of the reasons behind decisions made when
designing a system or artifact.
The design rationale for selecting the above architecture is our system is proposing on follow up
process the logical part is good for it and the architecture we choose decomposes our system to
clearify the working functionality of the whole system.
The critical issues are the system in our case needs to be decomposed into sub components
before achieve the specified goal.
DP stands for-Design process.
Parent
HRT
Substysem model
assumption
admin
Registrar Requirements
experts opinion
System model DP
other knowledge
DP
OR
Option dec1 dec2 dec3 dec4 dec5 dec6
22/
23
CHAPTER FOUR
DATA DESIGN
Database design is the communication or interaction among the tables in a system. This will
happen to identify what type of relationship exists in between them simply.
1*
1 1*
1
home room Record
Admin teacher officer
1 istra PK-HR-ID PK-RO-ID
Account PK-ADMIN- ID Fname fname
fname lname lname
password
1* 1 lname ID ID
user name ID grade
subject
section
parent 1
1* 1
1
PK-PA-ID 1
user name 1*
password
ID
1*
1*
1 1* 1 1*
Prepare
attendance Result Registrartion
Transcript Registrar
stud name
absence result result PK-RG-ID
semester
semester semester semester 1* 1
stud id
stud id stud id stud id
Fname
subject subject
Lname
user id user id
1* id
Fig 4. 1 Data design
23/
24
4.1 Data description
Sno Entity Attribute of an Data type Primary key

entity
1 Administrator Fname varchar(40) adimin_id
Lname varchar(40)
2 Teacher Lname varchar(56) Staff_ id
Staff id varchar(56)
Fname
3 Registrar Fname varchar(40) Reg_id
Lname varchar(56)
4 Parent stud_name varchar(40) Stud_id
stud_id varchar(30)
Parent_name
5 Fname varchar(30) Record
Record officer Lname varchar(30) officer ID
Table 4. 1Data description
24/
25
4.2 Data dictionary

Description:detail of student
Field name Description Constraint Data type Size
Student id Unique student id Primary key Varchar 30
that given to
student
First name First name of the Not Null Varchar 30
student
Last name Last name of the Not Null Varchar 30
student
Gender Gender of the Not Null Varchar 30
student
Age Age of the student Not Null Integer 20
Grade Grade of the Not Null Integer 20
student
Parent name The parent name Not Null Varchar 30
of the student
Phone Phone number of Not null Varchar 30
the student
Table 4. 2 Description:detail of student
Description:Details of Registrar
Table 4. 3Description:Details of Registrar

user id Unique user id for Primary key Varchar 30
registrar
Username Username of the Not Null Varchar 30
Registrar
Email Address Email address of Not Null Varchar 30
registrar
Password Password of Not Null Varchar 30
registrar
First name First name of Not Null Varchar 20
registrar
Last name Last name of Not Null Varchar 20
25/
26
registrar.
User Type The user type Not Null Varchar 30
the Registrar
Description:Detail of Parents
Parents
Parents
parents
parents
parents
parents.
the Parents
Table 4. 4 Description:Detail of Parents
Description:Detail of Admin
Administrator
Administrator
Administrator
Administrator
Administrator
26/
27
Administrator.
Administrator
Table 4. 5 Description:Detail of Admin
CHAPTER FIVE
COMPONENT DESIGN
The main objectives and uses of this component are to model component-based software
systems, define software architecture and divide systems into subsystems (e.g. graphical user
interfaces (GUI), business fields, and persistence in relational databases). In addition, these
subsystems and their interfaces are assigned specific tasks and functions inside a system.
27/
28
5.1 Object Diagrams

Object diagrams are derived from class diagrams so object diagrams are dependent upon class
diagrams. Object diagrams represent an instance of a class diagram. The basic concepts are
similar for class diagrams. Object diagrams also represent the static view of a system but this
static view is a snapshot of the system at a particular moment. Object diagrams are used to render
a set of objects and their relationships as an instance.
In our system we have designed the object diagram of Administrator below.
Fig 5. 1 Object diagram of Admin
5.2 Collaboration/communication diagram

Collaboration diagram is also known as communication diagram, is an indication of the
relationships and interactions among software objects in the Unified Modeling Language (UML).
The relationships between the objects are shown as lines connecting the rectangles. Pre-drawn
UML collaboration diagram symbols represent object, multi-object, association role, delegation,
link to self, constraint and note. These symbols help create accurate diagrams and
documentation.
28/
29
A collaboration diagram describes interactions among objects in terms of sequenced messages.

The UML Collaboration diagram is used to model how objects involved in a scenario interact,
with each object instantiating a particular class in the system. Objects are connected by links,
each link representing an instance of an association between the respective classes involved. The
link shows messages sent between the objects.
1:Enter login Details()
User LoginUI
5: Forward()
)
ard(
rw
Fo
5:
4: Acknowledgment()
Login
Controller Database
3:Verify Details
Fig 5.1 Collaboration diagrams of Login
29/
30
1:Enter login Details()
Admin LoginUI
5: Forward()
()
ward
r
Fo
2:
6: Click on()
4: Forward()
Registrar
7: Fill the Login

form() Controller Database
3:Verify Details
8: Verify Details
()
Registrar Registrar
Form Controller
9: Forward()
10: store()
User Data
base
Fig 5. 2 Collaboration diagrams for Registrar
5.3 Component Diagram

Component diagram shows components, provided and required interfaces, ports, and
relationships between them. This type of diagrams is used in Component-Based Development
(CBD) to describe systems with Service-Oriented Architecture (SOA).
A component diagram, also known as a UML component diagram, describes the organization
and wiring of the physical components in a system.
30/
Creat
31 e
Account
Remov
eAccount
Admi
n Generat
e repor
t
Prepare
Transcripit
Record
Officer Prepare
report card
Insert
Teache Attendance
r
Register
SStudent
Approved Security
Registra
Application
r
Register
Report
HU
Databas
e
Paren View result

t
View Report
car
d
Fig 5. 3Component diagram of our system
5.4 Deployment diagram

Deployment diagram is a structure diagram which shows architecture of the system as
deployment (distribution) of software artifacts to deployment targets. Artifacts represent
concrete elements in the physical world that are the result of a development process.
It describes the physical architecture of the hardware and software in the system. They depict
the software components, processors, and devices that make up the system’s architecture.
Deployment modeling depicts a static view of the run-time configuration of processing nodes
and components that run on those nodes.
31/
32
Creat
e
Account
Remov
eAccount
Generat Adminis
e repor trato
t r
Prepare
Transcripit
Record
Officer
Prepare
report card
Insert HoomRoom
Resul Security
Teache
t r
Register
studen
t
Approved
Registra
Application
r
Registratio
n
report
HUMS
Databas
e
View result Paren

t
View Report
car
d
Fig 5. 4 Deployment diagram of our system
5.5 Activity diagram

Activity diagram is another important diagram in UML to describe the dynamic aspects of the
32/
33
system. Activity diagram is basically a flowchart to represent the flow from one activity to
another activity. The activity can be described as an operation of the system. The control flow is
drawn from one operation to another.
The sequence of activity/the flow of that task from activity to activity are decided at the activity
diagram level.
Login
Enter user name & password
Ckeck user name & password
If input is invalid If input is valid
Logged succesfully
Figure 5.4: Activity diagram for login
33/
34
Login
No
Yes
Display create account form
Fill account forms and submit
Fill again Valid

No
Yes
Account created successfully

for user
Fig 5. 5 Activity diagram Create account
34/
35
Login
Click the View

report link
Display View
Report Page
Fig 5. 6 Activity diagram to view report
35/
36
Login
No
Yes
Display Record officer page
Click Upadate link
Select update report and

submit
The Update report is

successfully
Fig 5. 7 Activity diagram Record officer to Update report
36/
37
Login
NO
yes
Display The Home room Teacher Page
Click Insert result
Display Insert result form
Fill the form
Check Validity
NO
yes
result inserted
Fig 5. 8 Activity diagram for insert result
37/
38
login
NO
yes
Display The Record Officer Page
Prepare Transcript
Display the form
Fill the form
Check Validity
NO
yes
Transcript inserted
Fig 5. 9Activity diagram for the record officer to prepare transcript
38/
39
5.6 Sequence diagrams
Create Create
Create account
account account
<<controller>> Database
<<link> <<ui>>
Admin
1: Click the link

()
1.1: Fill the

form
2: The admin
fills the form()
3:Validate the
form()
3.1 If the form

is invalid()
3.2: If Valid()
4:Display Success message()
Fig 5. 10 Sequence diagram Create account
39/
40
Insert Insert Insert

attendance attendance attendance
Database
<<link> <<ui>> <<controller>>
Subject
Teacher
1: Click the link

()
1.1: Fill the

form
2: Insert student
attendance()
3:Validate the
form()
3.1 If the form

is invalid()
3.2: If Valid()
Fig 5. 11 sequence diagram Insert attendance
40/
41
Insert result Insert result Insert result

<<link> <<ui>> <<controller>> Database
Home
room
Teacher
1: Click the link

()
1.1: Fill the

form
2: Insert student
result()
3:Validate the
form()
3.1 If the form

is invalid()
3.2: If Valid()
Fig 5. 12 Sequence diagram for Insert Result
41/
42
Generate Generate Generate report

report report <<controller>>
Database
<<link>> <<ui>>
Record
officer
1: Click the link

()
1.1: Fill the

form
2:Record officer
fills the form ()
3:Validate the
form()
3.1 If the form

is invalid()
3.2: If Valid()
Fig 5. 13 Sequence diagram for Generate report
42/
43
View report View report View report

<<link>> <<ui>> <<controller>> Database
Parent
1: Click the link

()
1.1: Fill the

form
2: Input student
Id and grade
level()
3:Validate the
form()
3.1 If the form

is invalid()
3.2: If Valid()
Fig 5. 14 Sequence diagram for View Report
43/
44
5.7 Class Diagram
Fig 5. 15 Class diagram of our system
5.8 Statecchart diagram

A Statechart diagram describes a state machine. State machine can be defined as a machine
which defines different states of an object and these states are controlled by external or internal
events. A state diagram, sometimes known as a state machine diagram, is a type of behavioral
diagram in the Unified Modeling Language (UML) that shows transitions between various
objects.
44/
45
Fig 5. 16 State chart diagram for login
5.9 Pseudo Code/ Algorithm.

Algorithm plays a great role in the systems work flow of the components. So we have tried to
explain the components algorithm with respective pseudo code. The algorithm or the procedure
for the entire component in the system can be described according to the following as follows as
per their task.
5.9.1. Algorithm for Admin
Start Initialize the system
Enter his/her respective user name and password
View the feedback that has been come from others
45/
46
IF there is any comment read it and can reply
Then check if the database can accommodate newly registered users
IF it can accommodate register new comer user
Else no space END
5.9.2. Algorithm for Home room teacher insert result
Start
IF not registered before, click signup
And then submit user info
ELSE IF already exist
Enter username and password
Click login button option
IF he/she should have finished the course he/she have taught and IF the student finished all
subject
Take the student score and insert it
ELSE inform the students as he/she finish the subjects taken
Then post the result.
END
5.9.3. Algorithm for Parent
Start
IF authorized before enter username and password to get into the system
ELSE again register as Parent user type
46/
47
IF the result is posted,see their student result by entering student id.
Else Incorrect user id message displayed.
END
5.9.4. Algorithm for Student
Start
IF not registered before click signup option
And fill the form
Submit user information in to respective database
IF not fill the form with necessary contents the system display invalid message
Else registered successfully message display
Be prepare to attend the class
Fill the necessary info that needs to be fill during education like result and attendance
END
Logout
5.9.5. Algorithm for Registrar
Start
Initiate the site for academic matter
View all student grade attended
47/
48
The registrar office should have to decide to register the student per their grade to attend the
class.
Report registration
END
CHAPTER SIX
HUMAN INTERFACE DESIGN
6.1. Overview of User Interface

User interface is the basic way of indication via which the users communicate with the system.
Because without the users interaction with the system there will be difficult way of message
48/
49
transmission between them.
With the development of the Internet technology, family follow up system has become more and
more popular since it helps people save much energy and time.
Our produced system will able to allow the users to interact in a well manner as they want to use
the produced product finally. Once the actor/ outside users needs this system to apply in their
identical page through which they register and create own username and password
according to the system permission.
The upper menu will give full information of the system to the user want to interact
with our system according to the produced product.
The label with username and password with respective user type has described.
The system will allow the user to create new password if he/she forgot the password
with notification forgot password described on home page of the system.
6.2 Screen Images
49/
50
Figure 6. 1 User interface for home page
50/
51
Figure 6. 2 User interface for create account form
51/
52
Figure 6. 3 User interface for teacher student assessment form
6.3 Screen objects and actions

The objects associated with our systems are including buttons for every users to login and
connect to the system example Login button.
 Selection field for selecting the objects of user type.

 There is also text fields for entering the information required.
52/
53
6.4 Requirements matrix
This will conclude the components with their functional requirements as follow in tabular form:
SYSTEM COMPONENTS FUNCTIONAL REQUIREMENTS
Administrator Manage user in the system
He/she is responsible for take and insert

HR Teacher Attendance,Prepare the student result
He/she is responsible for generate report,

Record officer prepare transcript, and update report.
Give comment,view comment,view student

Parent result,view attendance and view report
this is responsible for Registration of students,

Registrar Approved Application,
Teacher is responsible for inserting assessment

Teacher and write comments.
Table 6. 1Table of Requirements Matrix
Appendix
53/
54
Symbol description
Actor …………….…………………..UML actor
……………………………System boundary
Use Case
…………………………….Use case diagram
Class name
Attributes
Operations
……………………………Class
……………………………………object activation
Object Lifeline
……………………………Life line of an object
1: [condition]
message name
…………………message return
1: [condition]
message name
……………………call a message
………………………………decision
54/
55
………………………dependency
State
…………………………object state
Activity
……………………………activity
………………………….....Initial state
……………………………finish state
55/

Software Architecture and Desig Part of Family Follow Ups

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Architecture and Desig Part of Family Follow Ups

Uploaded by

Copyright:

Available Formats

WEB BASED FAMILY FOLLOW UP SYSTEM FOR HARAMAYA UNIVERSITY MODEL SCHOOL

COLLEGE OF COMPUTING AND INFORMATICS

“Web Based Family Student Follow-up management system for Haramaya

A senior project submitted to Department of Software Engineering, College of

5.7 Class Diagram.................................................................................................................................44

List of Figures and Tables

Fig 3. 1 System layered architectural design.............................................................................14

Table 4. 1Data description..........................................................................................................23

Figure 6. 1 User interface for home page...................................................................................50

Basically this subtopic is concerning to the beneficiaries of the developed products, so

Registrar:-While the registrar want to register students,approve application and registration

1.2 Scope of the Project

Specifically the scope of our projects include

The relevant benefits of our projects are: -

 The students can have good behavior.

1.4 Reference materials

1. System analysis and design method, 6th edition.

2. HU model school record officer file and school profiles.

4. A.Hoffer. (2007). Modern Systems Analysis and Design (6th Edition).

Oriented and the UML. Cambridge: Cambridge University Press

1.5 Definitions and Acronyms

HUMS:Haramaya university model school

CBD:Common Based Development.

HUMSFFUS:Haramaya university model school family follow up system

FFUP:family follow up system

HRT:Home room teacher

BR: business rule

CPU: Central Processing Unit

FR: Functional Requirement

HTTP: Hypertext Transfer Protocol

MYSQL: My Standard Query Language.

NFR : Nonfunctional Requirement

OOSAD: Object Oriented System Analysis and Design.

PHP: Hypertext Preprocessor

RAM: Random Access Memory.

 Fast rate of operation and excellent response time.

 The system is flexible i.e. it can be accessed at anytime and anywhere.

 Minimizes the wastage of resource.

 Makes the task easy and interactive.

 It provides easy data storage and management.

Our system also performed the tasks such as,

3.1 Architectural Design

3.1.1 Overall system modular architecture

TEACHER, HOME ROOM TEACHER

MODULE RECORD OFFICER

ORAGE SERVICE DATABASE

Fig 3. 1 System layered architectural design

3.1.1 Component descriptions

Teacher: is who insert student assessment and write comment.

3.1.2 Systems’ subsystem model/ Logical view of the system

Insert Registe Prepar

Fig 3. 2 Logical view of the system

3.2 Decomposition Description

Purpose System needs to be administrated by an admin to be usable by other. And also

Dependencies This Administrator component is based on all the systems component

3.2.2 Home room teacher

Identification Home room teacher

Dependencies While he/she give learning. he/she should have to depend/based on

Interface He/she should have to use he/his username to enter in to his/her

Different operations can performed by registrar those are approved

Dependencies He/she should have to depend on the account created by admin

Process It own process/procedure while perform the task.