Online board documentation

ADIGRAT UNIVERSITY
COLLEGE OF ENGINEERING AND TECHNOLOGY
DEPARTMENT OF INFORMATION TECHNOLOGY
BY: Group one
Student Name Student ID signature
1. Kudus Zerabruk RET/00593/08
2. Tsegenet G/Michael RET/00582/08
3. Mitku Alemu RET/00611/08
4. Berhe Kiros RET/00549/08
5. Yerdanos Solomon RET/00
6. Fasil Alemu RET/00568/08
Submitted to: Department of Information Technology
Submission date:

i
Declaration
This Project is done by our effort and cooperation of all our team memembers. Additionally
by full guidance and supervision of our advisor we can keep all our expected result.
Name Signature
1. Kudus Zerabruk ----------------------------------
2. Tsegenet G/mikael ----------------------------------
3. Berhe Kiros ----------------------------------
4. Mitku Alemu ----------------------------------
5. Yerdanos Solomon ----------------------------------
6. Fasil Alemu ----------------------------------
College: College of Engineering and Technology
Program: Information Technology
Project subject: Online Notice Board Application for AdU
We certify that this project satisfies all the requirements as a project for the Bachelor degree
of Information Technology.
------------------------------------- --------------------------------------
Name of Department Head Signature
This is to certify that we have read this project and that in our opinion it is fully adequate, in
scope and quality, as a thesis for the degree of Bachelor of Science in Information
Technology.
-------------------------------- ------------------------------
Name of Advisor
--------------------------------
Name of Co-advisor
Signature
----------------------------
Signature
Examining committee members Signature Date
1. Examiner 1 ____________ ___________ ___________
2. Examiner 2 ____________ ___________ ___________
3. Examiner 3 ____________ ___________ ___________
It is approved that this project has been written in compliance with the formatting rules laid
down by the college of the university.

ii
List of figures
Figure 1 use case diagram for ADU online notice board.................................16
Figure 2 Register user sequence diagram ........................................................24
Figure 3 Login sequence diagram....................................................................25
Figure 4 View notice sequence diagram..........................................................26
Figure 5 Post Notice sequence diagram...........................................................27
Figure 6 manage notice sequence diagram ......................................................29
Figure 7 Manage user sequence diagram.........................................................31
Figure 8 Edit profile sequence diagram...........................................................31
Figure 9 state chart diagram for ADU online notice board .............................33
Figure 10 register activity diagram..................................................................34
Figure 11 Login activity diagram ....................................................................35
Figure 12 View notice activity diagram...........................................................36
Figure 13 Post Notice activity diagram ...........................................................37
Figure 14 Manage notice activity diagram ......................................................38
Figure 15 Manage user activity diagram..........................................................39
Figure 16 Edit profile activity diagram............................................................40
Figure 17 Class diagram for ADU Online notice board ..................................41
Figure 18 Mobile registration interface ...........................................................42
Figure 19Mobile login interface ......................................................................43
Figure 20 mobile notice list interface ..............................................................44
Figure 21 Web based Login interface..............................................................45
Figure 22 Admin homepage interface..............................................................46
Figure 23 Encoder homepage interface ...........................................................47
Figure 24 system architecture for adu online notice board system..................49
Figure 25 subsystem diagram for Adu Online notice board ............................51
Figure 26 persistent diagram for ADU online notice board ............................53

iii
List of tables
Table 1 Register use case documentation ........................................................17
Table 2 Login use case documentation............................................................18
Table 3 View notice use case documentation ..................................................18
Table 4 Post notice use case documentation....................................................19
Table 5 Manage user use case documentation.................................................20
Table 6 Manage user use case documentation.................................................21
Table 7 Edit profile use case documentation ...................................................22
Table 8 Access controls of ADU online notice board system .........................54

iv
Table content
Table of Contents
Declaration..................................................................................................................................i
List of figures............................................................................................................................. ii
List of tables...............................................................................................................................iii
Table content............................................................................................................................. iv
CHAPTER ONE ......................................................................................................................1
1. INTRODUCTION............................................................................................................3
1.1. Background................................................................................................................3
1.1.1. Background of the system....................................................................................3
1.1.2. Background of the organization......................... Error! Bookmark not defined.
1.2. Statement of problem................................................................................................4
1.3. OBJECTIVES............................................................................................................4
1.3.1. General objective .................................................................................................4
1.3.2. Specific objective.................................................................................................5
1.4. Methodology ..............................................................................................................6
1.4.1. Data gathering methodology................................................................................6
1.4.2. Design methodology............................................................................................7
1.4.3. Tools and instruments used for developing the system......................................7
1.5. Feasibility study.........................................................................................................8
1.5.1. Economic feasibility ............................................................................................8
1.5.2. Technical feasibility.............................................................................................9
1.5.3. Time feasibility ....................................................................................................9
1.6. Project scope and limitations .................................................................................10
1.6.1. Project scope ......................................................................................................10
1.7. The significance of the project ...............................................................................10

v
1.8. DOCUMENT ORGANIZATION..........................................................................11
CHAPTER TWO ...................................................................................................................12
2. ANALYSIS .....................................................................................................................12
2.1. Existing system........................................................................................................12
2.1.1. Existing system description ...............................................................................12
2.1.2. Business rules.....................................................................................................12
2.2. Proposed system......................................................................................................13
2.2.1. Functional Requirements ...................................................................................13
2.2.2 Nonfunctional Requirements .............................................................................13
2.2.3. Use case diagram..................................................................................................16
2.2.4. Use case documentation ......................................................................................17
2.2.5. Sequence diagram................................................................................................23
2.2.6. Statechart diagram..............................................................................................32
2.2.7. Activity diagram ..................................................................................................34
2.2.8. Class diagram ........................................................................................................41
2.2.9. User interface prototyping ..................................................................................42
CHAPTER THREE ...............................................................................................................47
3. DESIGN ..........................................................................................................................47
3.1. Design goals..............................................................................................................47
3.2. System architecture.................................................................................................48
3.3. System decomposition.............................................................................................49
3.4. Persistent data management ..................................................................................52
3.5. Access control and security ....................................................................................54
3.6. Deployment diagram...............................................................................................55

3
CHAPTER ONE
1. INTRODUCTION
Tigray Family Unifying System is Android-based system intended for meeting peoples (who
are departed due to war), notifying founded peoples, events, and other important
information’s. Families get notified by the system about the status of their depart relatives,
such as being alieve or not, health status, location (where they are), finally allow them to
connect. This application helps users to access Family Unifying System on your phone. The
system will be android based to facilitate easy access to all users. In addition to this, it will
also have supplementary application programs for today’s leading operating platforms like
web based.
1.1. Background
1.1.1. Background of the system
Family Unifying System is an android application, which is engaged in providing up-to-
date informations for all the users associated with the war crimes in Tigray. The Family
Unifying System is one of the applications to improve the usage of unifying of departed
peoples of Tigray by making it available online. This application involves almost all the
features of the Unifying system, where the implementation helps the users to retrieve all the
information’s and news directly through their cell phones. The Family Unifying System will
take care of the current information’s detail at any point in time. We intend to run the Family
Unifying System as a program that can be viewed anywhere and anytime. The Family
Unifying System program runs on personal mobile phones so information dissemination is
efficient.

4
1.2. Statement of problem
In today’s world, almost countries are in prosperity and development with democracy and
related policies. But when we come to the horn of Africa specifically in Ethiopia in the past
three years peoples are in trouble and in internal conflicts. Due to this a lot of peoples are
displaced from their home and families. Currently the situation gets worsen and leads to
actives war Tigray.
We observe that the war causes tens of thousands’ of people are migrated to Sudan and
hundreds of thousands are internally displaced. Due to this family member, Childs, relatives
are far apart to each other. Those people are searching each other. Fathers are worrying about
their child’s and wife’s, child’s about their father, brothers and sisters. This is done using
letters and phone call. It is bulky and almost fruitless.
The proposed application focuses on unifying displaced families.
1.3. OBJECTIVES
1.3.1. Generalobjective
 The general objective of this project is to develop a mobile-based application for
unifying displaced families .

5
1.3.2. Specific objective
The specific objectives of family unifying system is
 To identify the displaced peoples,family members.
 To search peoples and families (seekers)
 To connecting both(seekers and displaced families) by
 To design architecture, database, interface
 To implement the system according to the design
 To test the system weather, it meets its functional as well as non-functional
requirements or not
 To deploy the system for use
 To prepare user manuals

6
1.4. Methodology
1.4.1. Data gathering methodology
Two types of data source to collect information about the study. These are primary and
secondary sources.
Primary sources
 Direct observation
 Means looking at it with our own eyes, feeling it with your fingers (or other
body points), field observation as the whole. For this project, we are going
conduct direct observation on the refugee’s camp which is mostly primary
schools in Mekelle (Kisanet, Ethio-china, Hawelti,Ayder schools) . This were
helping us to gather more information, which was helpful for our project.
Secondary sources
Secondary sources were ones in which the author gave us second-hand account of the
information from these sources of data it was to mean that the brainstorming of information
that we got from primary sources and other automation systems for further information about
the study. For this technique, we had observed different information form international
media’s such as BBC world, CNN, Aljezira, France 24,Newyork time,Assena and TMH etc.
Most of the domestic and real informations were gathered from our Honor MassMedia TMH.

7
1.4.2. Design methodology
In our project, we applied the concept of object-oriented system Analysis and design
development methodology, because it was the best way to construct, manage and assemble
objects that we implemented in our system, and the composition of objects and collaboration
between objects on the system. It Models the functions of the system (use case modeling),
organize the objects and also the relationship between them and finally model the behavior of
the objects. It also shows object interactions and behaviors that support the use case and
scenario, and finally, update the object model to reflect the implementation environment. We
choose this approach because of the following advantages:
 Increased reusability: object-oriented system support reusability of the system.
 Increased extensibility: to add and change the existing module without affecting the
rest of the program.
 Easy error handling mechanism.
The above advantage will make object-oriented approach powerful and to be used most
widely.
1.4.3.Tools and instruments used
Hardware tools
Some of the hardware tools are:
 Networked desktop or laptop computer with:
 Intel Core i5 processor
 RAM 8 GB and Above
 HDD 500 GB Hard Disk Space and Above
 OS type 64 bit
 USB flash
 USB cable
 Mostly Smart mobile phone
Software tools
For design, documentation, presentation

8
 Microsoft Visio 2016
 Microsoft Word 2016
 Microsoft power point 2016
For implementation
 For mobile app
 Android studio IDE 3.2.0,
 Genymotion emulator
 Java - primary android development language
 For back end
 webserver: Apache
 database: MySQL
 server-side scripting language: node js
 editor: visual studio code
 browser: Google chrome
1.5. Feasibility study
1.5.1. Economic feasibility

9
Tangible benefits: This means the concrete benefit that can be expressed in terms of money
(birr).This project is going to provide economic benefit to adu by reducing the cost of extra
human resources for posting notices, many papers, printing notices in hard copy, redundant
notices papers, and physical notice board. In addition to this, it also reduces cost of painting
walls of the building that are removed their color and look bad due to many notice papers
posted over them. But after the system was developed it will reduce those costs by providing
digital notice board through a mobile application.
Intangible benefits: Those benefits cannot be expressed in terms of money. It includes
providing more readable, reliable, easily manageable, secure system, which contains all
notices track. The properly categorized notices will be provided and users can access them
without small of time, energy and other benefits.
1.5.2. Technical feasibility
This system is technically feasible because the system was developed mainly using
android the world leading/popular operating system currently. Therefore, we believe
that most of the users of the system can access them easily with their smartphone and
admins, faculties can use their desktops to access the system as well.
1.5.3. Time feasibility
The time feasibility required for the development of this system is very important since more
development time affects effort, cost and cause delaying development of another system. A
reliable unifying can be developed in a considerable amount of time. The total time needed to
develop this system can be approximately in 6 months with the assumption we planned, the
documentation is intended to be completed in approximately three months, and the
implementation will be completed in three months as well.

10
1.6. Project scope and limitations
1.6.1. Project scope
This system intends to implement the online notice board system for Adigrat University
(posting notices, viewing notices, sending notification alerts, generating reports,). These
services are going to access according to the privilege given by the admin. That means every
student, teachers, faculties, departments will be register to the system with some information
and validated by their identity number (ID). This registration can be done anywhere that has
internet access. After registering, every user of the system can view notices, events and keep
them up-to-date on what is going on the campus. If the users are not a member of ADU the
system due to graduation, dismissal and other factors, they do not have access to the system.
1.7. The significance of the project
At the end of the project it will provide the following advantages to ADU:
 Eliminate wastage of time and energy:
 The proposed project will be able to save a lot of paper and time. It
avoids posting of the notice on different places so it saves a lot of
energy and paperwork.
 Avoid duplication and overlapping:
 This application will help to remove the duplication of notices. The
only authorized person can post the notice. No one else would be able
to do so. Soo student and staff will be given correct information all the
time.
 Ensure due attention of the student to each and every notice:

11
 This project ensures that everyone has kind attention to every notice
and updates going on in college. There will be a buzz at each notice to
drive the attention of the student to check it once. In this way, students
will be well informed about their university activities.
 Prevent Crowd in campus:
 As you can see, there is always a crowd at the notice board. Since
notice board is one, and people to see notice are more. With this
application, there will be no more crowd. Everyone will be well
informed even at their homes. So they are free to do their other work.
 Automatically Updated Dashboard:
 The dashboard of notice is automatically updated when a new message
arrives. The user can himself refresh the dashboard to see any new
notice.
 Anytime Anywhere Service:
 With this application, notices will be delivered anytime and at any
place. There is no restriction of time to send a notice.
 Keeping Notices in one place:
 This application allows you to notify in one place only. So there will
be no here and there of notices.
1.8. DOCUMENT ORGANIZATION
In our document, we have included the system details through all the following chapters.
 Chapter one: includes the introduction, background, general object, specific object, the
scope of the project, methodology, feasibility study we have used.
 Chapter two: includes the requirement analysis description, Overview of the existing
system, Activities of the system, Problem of the existing system, Business rule,
Overview of the proposed system, Functional requirement, Non-functional requirement,
System requirement, Constraints, Assumption we have used.

12
 Chapter three: System Modelling, use-case modeling, Actor specification, use case
diagram, use case description, Sequence diagrams, Class diagram we have used.
 Chapter four: System design, Design goal, System decomposition, System
architecture, Deployment diagram, Persistence data management, Access control and
security, User interface design, references we have used.
CHAPTER TWO
2. ANALYSIS
2.1. Existing system
2.1.1. Existing system description
Currently, adu is using manual/traditional notice board system where all notices, events are
posted in building walls, in the gates of the campus and cafeterias as well as in physical
notice board in ADU. Since there are no electronic notice boards there is no adequate on
delivering the information to the ADU staff. Lack of system development in the current
environment, knowledge and the skills that were previously applied in the whole process of
systems development was limited and not broad enough. The current manual system has a lot
of paperwork and also wastage of papers, time-consuming, the student cannot get notices on
time, ones the notice displayed then difficult to update it.
2.1.2. Business rules
The current system have some rules for posting notices manually, but do not mean that all
these rules are implemented correctly since managing every notices manually is very
complex.
In ADU some of the rules on posting notice board are:
 Posting of notices everywhere is not allowed.
 Posting irrelevant notices to disseminate misinformation is not allowed

13
 Removing of legal notices is not allowed except by the authorized users.
2.2. Proposed system
2.2.1. Functional Requirements
The system should meet the following functional requirements:
 The system should be able to register users
 The system should be able to post notices.
 The system should be able to update, delete notices.
 The system should be able to add, delete users.
 The system should be able to generate a report.
 The system should be able to manage and maintain a proper database.
 The app should be able to provide push notification in real time whenever new notice
is posted.
 The app should be able to categorize notices to easily search by users.
 Enable users to edit their profile.
 Enable users to change their password.
 Enable users to login and log out.
2.2.2 Nonfunctional Requirements
i. Performance Requirements
These requirements are concerned with quantifiable attributes of the system such as
response time (how quickly the system reacts to a user input), throughout (how much work
the system can accomplish within a specified amount of system of time), availability (the
degree to which a system or component is operational and accessible when required for use),
and accuracy.
ii. Safety Requirements

14
Major attention should be given to the safety and security of the data and information that are
stored in the software. The database must be trustworthy and non-leakage to ensure no data
loss occurs.
iii. Security Requirements
User authentication must be absolute and non-by-passable. No user should be able to access
the software without providing proper authentication. In the case of guest users, only public
notices and events should be visible.
iv. Software Quality Attributes
Several additional qualities and characteristics of the system will be important to the client
and/or the developers, like correctness, maintainability, portability, testability, and usability.
For correctness, proper care and attention should be given during the design and coding from
both developers and customer (should correct some false and unwanted features) side.
Usability is achieved by developing the product as user-friendly as possible. Similarly,
maintainability and testability play a vital role in the long life of the software.
v. Reliability
Is the ability of a system or component to perform its required function under stated
conditions for a specified period of time? Reliability requirements include, for example, an
acceptable mean time to failure and the ability to detect specified faults or to withstand
specified security attacks.

16
2.2.3.Use case diagram
client
view notice
view notification
manage notices
updatae
notice
delete
notice
manage users
edit user
delete
user
post notice
encoder
admin
login
logout
<<extend>>
view report
register
edit profile <<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<extend>> <<extend>>
<<extend>> <<extend>>
Figure 1 use case diagram for ADU online notice board

17
2.2.4.Use case documentation
Table 1 Register use case documentation
Id UC01
Name Register
Actors Admin, encoder(faculty, departments), clients (students, teachers,…)
Description This use case provides users to register to the system and create an
account to access the system
Precondition For encoders and clients, their ID must be uploaded to the database by
Admin for authenticating users.
The basic flow of
the event
 The above actors can press register link
 The system displays the registration form
 Then the actors fill the necessary information on the form and
press login.
 The system checks whether the above actors are found with that
ID on the database or not.
 If the user is valid cheek whether the user is registered before
 If not registered the user will be registered to the database and
display the successful message.
The alternative flow
of events
 If user ID not found in database display unauthorized user
message
 if the user is authorized and already registered before system
display already registered user.
Postcondition The user can log in to the system

18
Table 2 Login use case documentation
Id UC02
Name Login
Actors Admin, encoder, client
Description This use case ensures security and access privilege for accessing the
system
Precondition They must first create an account(register) on the database.
The basic flow of
the event
 The above actors can press login link according to their level of
privilege.
 Then the actors should fill the necessary information on the
form and press login.
 The system checks whether the above actors are found with that
login detail on database or not.
 If the user is valid displays homepage(main page)
of events
 If user information not found in database recommend user to
register.
 If the message is error enter detail correctly again.
Postcondition The user can navigate to the page what he/she wants and can access
system functions
Table 3 View notice use case documentation
Id UC03
Name View notice
Actors Encoder, client
Description Users can view new notices displayed on the notice list from the notice
database.

19
The user can view notice detail by clicking on the notice detail
Precondition  Users must be login to the system
 There must be an available notice on the database
The basic flow of
the event
 The above actor's login to the system
 The system display homepage with new notice list if there are
available notices in notice database
 The user clicks on single notice and can view notice detail
of events
 If there is no available notice on the database the system display
no notice message.
Postcondition
Table 4 Post notice use case documentation
Id UC04
Name Post notice
Actors Encoder
Description The encoders(notice posters) can post notices, messages, events to the
users
Precondition Encoder must first be login to the system
The basic flow of
the event
 Encoder click on post notice page
 system display notice form
 Encoder fill notice and click the post button
 system store notice to database
 notices available for users
of events
 If the encoder enters invalid input the system will validate user
input and display a descriptive error message

20
Postcondition The encoder can update or delete the notice that he/she posted by
clicking manage notices page.
Table 5 Manage user use case documentation
Id UC05
Name Manage notice
Actors Encoder
Description  Encoder can delete/update notice posted by him.
Precondition  Encoder must first be login to the system
 There must be a notice to be managed
The basic flow of
the event
 Encoder click on manage notice page
 System display notice list with delete and update action links
 If delete link is clicked the notice will be removed from notice
list as well as from notice database
 If update link is clicked the system display update notice forms
with the previous data
 Then Encoder edits the previous data and click ‘save changes’
button.
 System updates notice and save changes to the database.
of events
 If there are no available notices to be managed then the system
display ‘no notice to be managed message’
Postcondition

21
Table 6 Manage user use case documentation
Id UC06
Name Manage users
Actors Admin
Description This use case provides admin to delete or edit encoders(departments,
faculties) and decoders(students, teachers)
Precondition  They first are login to the system
 There must be users to be managed
The basic flow of
the event
 Actor click on manage users page
 System display users list with delete and edit action links
 If delete link is clicked the user will be removed from notice list
as well as from notice database
 If edit link is clicked the system display edit notice forms with
the previous data
 Then user edits the previous data and clicks ‘save changes’
button.
 System updates user and saves changes to the database.
of events
If there are no available users to be managed then the system display
‘no user to be managed message’
Postcondition

22
Table 7 Edit profile use case documentation
Id UCID06
Name Edit profile
Actors Admin, encoder, client
Description This use case provides users to edit their account
Precondition Actors first Must be login to the system
The basic flow of
the event
 user click on edit profile page
 system display edit profile form with previous data
 user edit the previous data and click save changes button
 user updated his profile and save changes to
of events
If the user enters invalid input the system will validate user input and
display a descriptive error message.
Postcondition

24
user
<<UI>>
Registration form
<<controller>>
Register
<<DB>>
Account
fill registration form
register(form data)
isUserAuthorized(ID)
alt
elsenot authorized
ifauthorized
yes/authorized
isRegisterd
alt
elsenot registered
ifalready registered
registered
user already registered message
not registered
register to db
registered
sucessfullyregistered message
no/unAuthorized
not authorized user message
Figure 2 Register user sequence diagram

25
user
<<UI>>
login interface
<<controller>>
login
<<DB>>
account
fill form
login(uname,pass)
verify(username,password)
alt
else
ifuser is valid valid
display homepage
invalid
login not sucess full
Figure 3 Login sequence diagram

26
user
<<controller>>
login
<<UI>>
notice list
<<controller>>
notice detail
<<DB>>
notice
login()
redirect to notice list
cheek noticeifexist
noticeexist
display noticelist
click on noticelist
noticedetail(id)
display noticedetail
noticenot exist
no available notice
alt
ifnoticenot exist
ifnoticeexist
Figure 4 View notice sequence diagram

27
encoder
<<controller>>
login
<<UI>>
notice form
<<controller>>
post notice
<<DB>>
notice
login()
display notice form
fill notice form
post notice(data)
store to db
stored
display sucessmessage
display homepage
navigate post form
Figure 5 Post Notice sequence diagram

29
encoder
<<controller>>
login
<<UI>>
manage notice
<<controller>>
update notice
<<controller>>
delete notice
<<DB>>
notice
login
managenotice
update ordeletenotice
alt
ifdelete
ifupdate update notice
display update form + previous data
edit previous data
update(new data)
save changes to db
delete notice
delete notice(id)
delete fromdb
display homepage
updated
sucess message
deleted
sucess message
selectpreviousdata
returnprevious data
Figure 6 manage notice sequence diagram

30
admin
<<controller>>
login
<<UI>>
manage user
<<controller>>
edituser
<<controller>>
delete user
<<DB>>
users
login
edit or delete user
alt
ifdelete
ifupdate edit user
display editform+ previous data
edit previous data
update(newdata)
save changes todb
delete user
delete user(id)
delete fromdb
display homepage
manage users
saved
sucess message
deleted
sucess message
select previous data
returnpreviousdata

31
Figure 7 Manage user sequence diagram
1. Edit profile sequence diagram
user
<<controller>>
login
<<controller>>
edit profile
<<DB>>
account
login()
display homepage
navigate edit profile
<<UI>>
edit profile form
display edit form + previous data
edit profile forms
update(newData)
save changes
saved
profile edited sucessfully
select previous data
return previousdata
Figure 8 Edit profile sequence diagram

33
registerd
Open app/open system Is user registerd
yes
login
Fill uname and pass
authentication
invalid
identify accoun
Invalid username password
encoder admin
client
post notice nanage notice edit ptofile
view notice
no
loged in
valid
manage user edit ptofile
view notice
edit ptofile
logout
register
Figure 9 state chart diagramfor ADU online notice board

34
2.2.7.Activity diagram
user open
registration form
user open
the
application user fill registration
form
is user registerd
yes user already exist
no
user registerd
sucessfully
user ready to login
is user authorized?
no unauthorized user
verify id if the user
is authorized
yes
verify user if user is
already registerd
Figure 10 register activity diagram

35
user enters
username and
password
is login/ password correct ?
no
invalid login/
password
yes
user sucessfully
logged in
system display
homepage
user logged in
user already
registerd
Figure 11 Login activity diagram

36
user navigate
notice list
user already
logged in
is notice available?
no no notice available
yes
display notice list
user click on notice
display notice
detail
Figure 12 View notice activity diagram

37
encoder
already
loged in
navigate post
notice
system display post
notice form
fill notice form
click post notice
button
notice stored to
database
notice
available to
users
Figure 13 Post Notice activity diagram

38
encoder
already
loged in
navigate manage
notice
click update link click delete link
delete
update
link display update
notice form with
the prevouse data
page display notice
list with update and
delete actions
edit previouse data
click save changes
button
notice updated
notice deleted from
notice list and
notice database
update or delete ?
Figure 14 Manage notice activity diagram

39
admin navigate
manage users
admin clik edit user
link
admin clik delete
user link
edit
link display edit user
form with the
prevouse profile
page display users
list with edit and
delete actions
admin edit user
data
admin click save
changes button
user updated
user deleted from
user list and users
database table
edit or delete?
delete
admin
already log
in
Figure 15 Manage user activity diagram

40
user enters
homepage
user already
login
user navigate edit
profile
system display edit
profile form
user edit his profile
user submit his
profile
profile updated
Figure 16 Edit profile activity diagram

41
2.2.8. Class diagram
notice
#id: int
#title: string
encoder
+postNotice()
admin client
#desc: string
-department
+manageEncoder()
+manageDecoder()
+sendNotification()
+manageNotice()
+viewReport()
view notice
+getNotice()
post notice
+setNotice()
1 *
+Role: string
#catagory: string
+Role: string
*
1
manage notice
+updateNotice()
+role: string
+deleteNotice
profile
-id: string
+register()
+editProfile()
-fullName: string
-username: string
-role:string
-password: string
+logout()
+login()
users
+register()
#id: string
+role: string
#password:string
#username:string
+logout()
+editprofile()
+login()
+viewNotification()
1
*
1 1
+viewNotice()
1
*
notification
+title
+message
*
*
*
*
*
*
Figure 17 Class diagram for ADU Online notice board

42
2.2.9.User interface prototyping
Figure 18 Mobile registration interface

43
Figure 19Mobile login interface

44
Figure 20 mobile notice list interface

45
Figure 21 Web based Login interface

46
Figure 22 Admin homepage interface

47
Figure 23 Encoder homepage interface
CHAPTER THREE
3. DESIGN
3.1.Design goals
The purpose of design is to model the system with high quality and to make all users of the
system can access easier and faster to the system. Design goal primarily emerged from the
non-functional requirement of the system and the objectives of the design goal are to model a
system with high quality.
The design goal of the system may include with the perspective of dependability,
performance, and end-user criteria.
 Dependability

48
Dependability is a measure of a system's availability, reliability, and its maintainability, in
some cases, it includes other characteristics such as safety and security .
 Availability: our design considers that adu online notice board system will be
available 24/7.
 Reliability: the system will be designed to provide continuous and correct service to
ensure the reliability of the system.
 Maintainability: the system design must consider the ability to undergo
modifications and repairs when maintenance is needed.
 Security: The system should be secured that unauthorized user cannot access the data
that does not concern with them. Our system design applies security mechanism and
access controls to handle access privileges of different users of the system.
 Performance
The system should respond fast with high throughput, i.e. It should perform retrieving
notices, registering users, and generating a report as quickly as possible. Therefore, this
design will ensure the performance of the system.
 Usability
Usability is the extent to which specified users to achieve specified goals with effectiveness,
efficiency, and satisfaction. From the end users’ perspective, the proposed system should be
designed in such a way that it is easy to learn and use, efficient and having few errors if any.
 End User Criteria:
The proposed system should have a simple and understandable graphical user Interface such
as forms and buttons, which have descriptive names. It should give a reliable response to
each request before the session expires.
3.2.System architecture
In this system, we use the three-tier architecture which has three layers. These three layers are
the Presentation layer, the business layer, and the data access/management layer.
 Application or presentation layer : is the form, which provides the user interface
to either programmer or end user.

49
 The business logic layer : is the class, which the team uses to write the function,
which works as a mediator to transfer data from the application or presentation layer
to the data management layer.
 Data access/management layer: is also a class to get or set data to the database
queries back and forth. This layer only interacts with the database. The database
queries or stored procedures will be written here to access the data from the database
or to perform any operation to the database.
Figure 24 system architecture for adu online notice board system
3.3.System decomposition
Subsystem decomposition is the process of dividing the system into manageable subsystems
from the analysis model of the proposed system. The goal of the system decomposition is to
reduce the complexity of the design model and to distribute the class of the system into large
scale and cohesive components. In dividing the system we decompose the system based on
the function that the system does.

50
The following are some of the main subsystems of ADU online notice board system which
needs to decompose for easy management.
 Manage account subsystem:
 Manage notices subsystem
 Manage users subsystem
 View notices subsystem
 Generate report subsystem

51
ADU onlinenoticeboardsystem
manage notice
viewnotice
manage account
manage users
update
notice
delete
notice
edituser delete user
viewby
category
all notices
editprofile
change
password
change
profilepic
login
admin
encoder
client
number
of users
post
notice
number
of notices
Figure 25 subsystem diagram for Adu Online notice board

52
3.4.Persistent data management
Some communication and activity in our system generate and stores different data, such as
users account, user’s profile, and notice data. Moreover, these data need relation, integration
and persistent data management to achieve the system design goals.
Persistent data management deals with how the system is going to handle the actual data need
to be stored on the database of the system. The purpose of persistence modeling is which
objects in the system design are required to be stored persistently. Clearly, in a database is
driven application like our system, almost all system interactions have a deal with persistent
data models that shows the relationship of tables in the database.

53
notice
notice_id: int
PK
title : varchar(100)
category: varchar(100)
description: Text
posted_date: Date
encoder_ID: varchar(20)
FK
account
ID: varchar(20)
PK
username: varchar(20)
password: varchar(20)
encoder
encoder_ID: varchar(20)
PK
FK
full_name: varchar(20)
department: varchar(50)
profile_pic: varchar(100)
role: varchar(20)
client
client_ID: varchar(20)
PK
FK
department: varchar(50)
role: varchar(20)
admin
admin_id
PK
FK
1
1
*
1
1
1
1
1
*
*
target: varchar(50)
file: varchar(100)
*
1
*
1
Figure 26 persistent diagramfor ADU online notice board

54
3.5.Access control and security
Access control is a way of limiting access to a system or to physical or virtual resources. In
computing, access control is a process by which users granted access and certain privileges to
systems, resources or information. In access control systems, users must present credentials
before they can be granted to access. In physical systems, these credentials may come in
many forms, but credentials that can't be transferred provide the most security.
Table 8 Access controlsof ADU online notice board system
Actors
Activities Admin Encoder Client
Register   
Login   
View notice  
Post notice 
Manage notice 
Manage users 
Edit profile   
logout   

55
3.6.Deployment diagram
Deployment diagrams are used for describing the hardware components where software
components are deployed. The three-dimensional boxes, known as nodes, represent the basic
software or hardware elements, or nodes, in the system. Lines from node to node indicate
relationships and artifact that indicates product developed by the software, symbolized by a
rectangle with the name and the word “artifact” enclosed by double arrows. The node can
include components that indicate a part/component of the system.
<<device>>
client
<<device>>
Applicationserver
<<device>>
Database server
View notice
Manage notice
Mange notice
Manage users
MySQL
databse
security
<<device>>
PC
<<device>>
Mobile
phone
TCP/IP
<<artifact>>
AONBwebsite
<<artifact>>
AONB.apk

Online board documentation

More Related Content

What's hot (20)

Similar to Online board documentation (20)

Recently uploaded (20)

Online board documentation