<selamawi 2016

Addis Ababa Institute of Technology

Center of Information Technology and Scientific
Computing
Department of IT/SW Eng.

<Selamawi>
Software Design Specification
Team Members

1. Anteneh Behailu
2. Essey Bisrat
3. Natnael Awoke
4. Newal Abrar
5. Salhadin Bilal
6. Yehualashet Abebe
7. Tabor Nekatibeb

Advisors: Lisanu Tebikew

Fitsum Alemu

May, 2016
 <selamawi 2016

Table of Contents
List of Tables ................................................................................................................................................. ii
List of figures ................................................................................................................................................ iii
Definitions, Acronyms, Abbreviations ......................................................................................................... iv
1. Introduction ........................................................................................................................................... 1
1.1 Purpose ............................................................................................................................................... 1
1.2 General Overview ............................................................................................................................... 1
1.3 Development Methods & Contingencies ............................................................................................ 1
2. System Architecture .............................................................................................................................. 3
2.1 Subsystem decomposition ................................................................................................................... 4
2.1.1 Components ................................................................................................................................. 4
2.2 Hardware/software mapping ............................................................................................................... 6
3. Object Model............................................................................................................................................ 9
3.1 Class Diagram ...................................................................................................................................... 9
3.2 Sequence Diagram ............................................................................................................................ 10
4. Detailed Design ....................................................................................................................................... 13
References ................................................................................................................................................... 22

i|Page
 <selamawi 2016

List of Tables
Table 1 user Class ........................................................................................................................................ 13
Table 2 Attribute Description...................................................................................................................... 14
Table 3 operation Description .................................................................................................................... 14
Table 4 student Class .................................................................................................................................. 14
Table 5 Attribute Description 2................................................................................................................... 15
Table 6 Method Description ....................................................................................................................... 15
Table 7 petition Class .................................................................................................................................. 16
Table 8 Attribute Description3.................................................................................................................... 17
Table 9 operation Description .................................................................................................................... 17
Table 10 Comment class ............................................................................................................................. 17
Table 11 Attirbute Description4.................................................................................................................. 18
Table 12 operational description2 .............................................................................................................. 18
Table 13 vote Class...................................................................................................................................... 18
Table 14 Attribute Description5.................................................................................................................. 19
Table 15 operational Description3.............................................................................................................. 19
Table 16 tag class ........................................................................................................................................ 19
Table 17 Attribute Description6.................................................................................................................. 20
Table 18 operational Description4.............................................................................................................. 20
Table 19 Authenticator Class ...................................................................................................................... 20
Table 20 operational Description6.............................................................................................................. 20
Table 21 Attribute Description7.................................................................................................................. 21

ii | P a g e
 <selamawi 2016

List of figures
Figure 1 Deployment Diagram ...................................................................................................................... 8
Figure 2 Class Diagram .................................................................................................................................. 9
Figure 3 Sequence Diagram1 ...................................................................................................................... 10
Figure 4 Sequence Diagram2 ...................................................................................................................... 11
Figure 5 Sequence Diagram3 ...................................................................................................................... 12

iii | P a g e
 <selamawi 2016

Definitions, Acronyms, Abbreviations

UML-Unified Modeling Language

PHP –Hypertext Pre Possessor
SDS-Software Design and Specification
HTML-Hypertext Markup language
DBMS-Database Management System

iv | P a g e
 <selamawi 2016

1. Introduction
1.1 Purpose
The purpose of this SDS document is to give insight into the design of the “Selamawi” web
application. This document will contain information about the system architecture, design
considerations and so on. This is to give the reader, a better understanding of the design
process and procedure for this web application. This document is also used by our team as a
“template” in order to continue with the implementation (coding).

1.2 General Overview

The software we are designing is “Selamawi”, a web application that will help the students
of Addis Ababa University to collect petitions online. The product will enable and help
students to create their own petitions, involve on existing petitions either by voting to it or
down voting against, check their and other petitions status and vote from anywhere, with the
only requirements being that the user has to have a device with a web browser installed, an
internet connection and valid account information.

The implementation of “Selamawi” will take a layered and three tier architecture. Details
about the system architecture is briefly describe in chapter 2(System Architecture) of this
document.

The web application is written in PHP 5 and it will be run on Apache web server. It connects
to the database (MySQL 5.3) through the PHP PDO technology. In terms of design the aim
is to make it simple, understandable as well as easy to use.

1.3 Development Methods & Contingencies

The Evolutionary prototyping development method was identified as the most desirable
among the group members and was therefore adopted for the system design.

The development method is divided into these parts:

1. Designing the database by sketching the E/R Diagram.
2. UML Designs (System Sequence Diagrams, component diagram…)
3. Analyzing the classes that will be needed for implementation.
3. Designing the class diagram.

1|Page
 <selamawi 2016

Beside while implementing the system the following technologies are use:

 Frontend development-It will be written in HTML5, CSS3,javascript

 Backend development- The server side application is written in PHP 5
 The database system will be deployed on MySQL Server.
 This system will be running on Apache Web server. Apache is closely available as it is
cheap

2|Page
 <selamawi 2016

2. System Architecture

Layered Approach plus three Tier Architecture

This part of the SDS talks about the overall structure of applications in terms of the logical
grouping of components into separate layers that communicate with each other and with
clients.

Layers are concerned with the logical division of components and functionality, and do not
take into account the physical location of components. Layers can be located on different
tiers, or they may reside on the same tier. On our case some layers are located on the same
tiers and other on different tiers

Why is layered architecture and three tier architecture chosen?

After reviewing our functional and nonfunctional requirement, the team has decided our
application to have a hybrid architecture or layer and three tier architecture.

From our non-functional requirement the main priority given by our application is security.
As the system consists of some sensitive information about students, we have decided to use
layered approach to make sure that these information are not accessible by other than
legitimate persons, by making them wrapped by other layers making them accessible by inner
most layers.

The second priority given to the non-functional requirement is performance. To achieve

this requirement we have decided to use the MVC architecture to meet the desired
performance beside the layered approach. Other details about the Architectures is discussed
in the section below.

How Required Layers Defined?

The technique we used to determine our layers is by separating presentation, services,

business, and data access functionality into separate layers.

 Presentation layer. This layer contains the user oriented functionality responsible for
managing user interaction with the system, and generally consists of components that
provide a common bridge into the core business logic encapsulated in the business
layer.
 Service layer. This layer is important when the application must provide services to
other applications, as well as implementing features to support clients directly
(System Administrators in our case).

3|Page
 <selamawi 2016

 Business layer. This layer implements the core functionality of the system, and
encapsulates the relevant business logic.
 Data layer. This layer provides access to data hosted within the boundaries of the
system.
How layers and components are distributed?

In this system, layers and components are distributed across separate physical tiers as
necessarily. Where the UI processing occurs on the desktop, we prefer to deploy the business
components in a physically separate business tier for security reasons. Also the business and
data access components are deployed separately to increase performance.

Mode of interaction between the layers

Strict interaction. Each layer must interact with only the layer directly below. This rule will
enforce strict separation of concerns where each layer knows only about the layer directly
below. The benefit of this rule is that modifications to the interface of the layer will only
affect the layer directly above. This interaction also accommodate the introduction of new
functionality thereby minimizing the impact of those changes.It is also much suitable for
application that are distributed across different physical tiers like ours.

Interfaces between Layers

The primary goal of defining interfaces between layers in our system is largely from security
point of view. A layer should not expose internal details on which another layer could
depend. Instead, the interface to a layer should be designed to minimize dependencies by
providing a public interface that hides details of the components within the layer. The
implementation used for the interfaces is message-based. It is shortly described below.

Message-based. Instead of interacting directly with components in other layers by calling

methods or accessing properties of these objects, we use message-based communication to
implement interfaces and provide interaction between layers.

2.1 Subsystem decomposition

2.1.1 Components
The system is decompose into six major components. Each of them are listed and described
below

2.1.1.1 Authentication
This component is responsible for the logging and logging out events and all other events
that is relevant to authentication. It is decomposed into these sub components:

4|Page
 <selamawi 2016

 Login / Logout: Allows users to log onto the web application and log out from it.
 Password Manager: This allows the user to change his/her password.
 Password Recovery: This allows the user to retrieve his/her password in the event
that the user forgets his login details.

2.1.1.2 Administration Tool

This component is responsible for all the functionalities that only the manager is allowed
to use. It is decomposed into these sub systems:

 Manage users: This contains the functionalities of adding / deleting users

 Manage Reports: This contains the functionality of reviewing and delivering
actions towards these reports.

2.1.1.3 Notification
This component is responsible for delivering notifications that rise form votes (up vote
and down vote) comments and reports towards a given posted petition.

2.1.1.4 Petition
This component is responsible for everything that is done regarding petitions. It is
decomposed into three sub systems.

 Create petition: This sub-component contains the functionality of creating

petition
 Vote for petition: This allows users to vote for a particular petition (includes
both up vote and down vote)
 Report on petition: This allows user to report against petition that they assume
it is inappropriate

2.1.1.5 Searching and Sorting

This component is responsible for searching and sorting of the various petitions posted
previously by other user. It is decomposed into two subsystem:

 Searching: Returns closest matching petition title with the given search query
 Sorting: sorts available petition with different tags (Popular, most voted,
department……)

2.1.1.6 Petition Lists

This component is responsible for displaying the details of each petition that the user
created itself and other petitions. This component is decomposed into two sub-components.

 View about petition: This allows user to view the different status about a given
petition like its problem description, date first posted and number of up and
down votes

5|Page
 <selamawi 2016

 Petition History : This allows user to access the petition he has posted
previously

2.1.1.7 Database Access

This components abstract the logic required to access the underlying data stores. It is
responsible for returning queries from upper layers, and writing data to the database.

Component Diagram: Layer 1

In this scenario, users can access the

application through the presentation
layer, which communicates directly with
the components in the business layer.
Meanwhile, administrators can access
the application and make use of its
functionality by communicating with the
business layer through service interfaces.
This allows the application to better
support multiple client types(users and
administrator).

6|Page
 <selamawi 2016

Component Diagram: Layer 2

7|Page
 <selamawi 2016

2.2 Hardware/software mapping

Figure 1 Deployment Diagram

8|Page
 <selamawi 2016

3. Object Model
3.1 Class Diagram

Figure 2 Class Diagram

9|Page
 <selamawi 2016

3.2 Sequence Diagram

Figure 3 Sequence Diagram1 (Login)

10 | P a g e
 <selamawi 2016

Figure 4 Sequence Diagram 2 (create petition)

11 | P a g e
 <selamawi 2016

Figure 5 Sequence Diagram 3 (Deactivate User)

12 | P a g e
 <selamawi 2016

4. Detailed Design
User class

User
#firstname:string
#middleName:string
#lastName:string
#role:int
#userID:int
#email:string
+role(role:int):Boolean
+getFullName():string
+getRole():int
+getUserID():int
+loggedIn():boolean
Table 1 user Class

Attribute description for user class

Attribute Type Visibility Invariant

firstName String protected firstName<>NULL and must contain only

strings, and the number of characters must not
exceed 15
lastName String Protected <>NULL and must contain only strings, and
the number of characters must not exceed 15
middleName String Protected <>NULL and must contain only strings, and
the number of characters must not exceed 15
Role Integer Protected role<>NULL and the value must be either 1
or 2.
userID Integer Protected userID<>NULL and must contain only
integer.
Email String Protected Email<>NULL
 Must contain exactly one @
symbol.
 Must contain dot(.)
 The length of the string before @
must be at least 1 character long.
And alphanumeric characters along
with dot(.) and underscore(_) are
allowed.
 The length of the string between @
and dot (.) must be at least 3
characters long. Only alphanumeric

13 | P a g e
 <selamawi 2016

characters are allowed in this part

of the string.
 The length of the string after the
last dot(.) must be at least two
characters long.

Table 2 Attribute Description

Operation description for user class

Operation Visibility Return type Argument Pre- Post-

Condition condition

role Public Boolean Integer

getFullName Public String void User’s full
name will be
retrieved.
getRole Public Integer void Role of the
user should
exist
logedIn Public Boolean void Either true or
false values
are provided
as flag to
whether a
user logged
in or not.
Table 3 operation Description

Student class

Student
-department:int
-school:int
-year:int
+createPetition(title:string,description:string,tag:Tag):boolean
+comment(petition:Petition,message:string):boolean
+vote(petition:Petition,type:int):boolean
+deletePetition(petition:Petition):boolean
+changeName(first:string,middel:string,last:string):boolean
+changeYear(year:int):boolean
+searchPetition(keyWord:string):Petition

Table 4 student Class

14 | P a g e
 <selamawi 2016

Attribute description for Student class

Attribute Type Visibility invariant

Department Integer Private Department<>NULL
and department must
contain only integer.
The value of
department must
contain only values
from pre defined set
of elements.
School Integer Private School <>NULL and
must contain only
integer. The value of
school is from pre
defined set of
elements.
Year Integer Private Year<>NULL and
the value of year
must be between 1
and 5, inclusively.
Table 5 Attribute Description 2

Method description for Student class

Operation Visibility Return type Argument Pre-condition Post-condition

createPetition Public Boolean String, Petition Petition should
String, Tag shouldn’t exist. exist.
Comment Public Boolean Petition, Comment Comment should
String shouldn’t exist. exist.
Vote Public Boolean Petition, Vote shouldn’t Vote should exist.
integer exist.
deletePetition Public Boolean Petition Petition should Petition shouldn’t
exist. exist.
changeName Public Boolean String, Name should Old name replaced
String, String exist. with new name.
changeYear Public Boolean Integer Year should New year
exist. information should
replace old year.
searchPetition Public Boolean String Petitions which
match the provided
key word will be
retrieved.
Table 6 Method Description

15 | P a g e
 <selamawi 2016

Petition class

Petition
-sent:Boolean
-petitionID:int
-title:string
-description:string
-date:date
-getComments():Comment[]
-getVotes():vote[]
+addComment(message:string,commentorID:int):Boolean
+castVote(type:int,voterID:int):Boolean
+getTitle():string
+getDesc():string
+getDate():date
Table 7 petition Class

Attribute description for Petition class

Attribute Type Visibility Invariant

Sent Integer Private
PetiionID Integer Private petitioned<>NULL
Must be integer and
unique.
title String Private Title<>NULL and
must be string.
Length of title
mustn’t exceed 50
characters. And it
mustn’t contain less
than 10 characters.
Description String Private Description <>
NULL and must be at
least 40 characters
long. And the
description mustn’t
exceed 500
characters.
Date Date Private Date<>NULL and
the date should be in
‘dd-mm-yyyy
hh:mm:ss’ format,
where d is for date, m
for month, y for year,
h for hour, m for
16 | P a g e
 <selamawi 2016

minute and s for

second.
Table 8 Attribute Description3

Operation description for Petition class

Operation Visibility Return Argument Pre-condition Post-condition

type
getComments Public Array Void Retrieve comments for
the specified petition.
getVotes Public Array Void Retrieve votes – up and
down – for the specified
petition.
addComment Public Boolean String,integer Comment Comment should exist.
shouldn’t exist.
castVote Public Boolean Integer,integer Vote shouldn’t Vote should exist
exist
getTitle Public String Void Retrieve title of the
petition.
getDesc Public String Void Retrieve description of
the petition.
getDate Public Date Void Retrieve the date when
the petition was created.
Table 9 operation Description

Comment class

Comment
-commentID
-message
-date
+getMessage():string
+getDate():date
+getCommentor():Student
Table 10 Comment class

17 | P a g e
 <selamawi 2016

Attribute description for Comment class

Attribute Type Visibility Invariant

commentID Integer Private commentID<>NULL
and must e integer
Message String Private Message<>NULL
and cant be empty.
And must contain
only string.
Date String Private Date<>NULL and
the date should be in
‘dd-mm-yyyy
hh:mm:ss’ format,
where d is for date, m
for month, y for year,
h for hour, m for
minute and s for
second.
Table 11 Attirbute Description4

Operation description for comment class

Operation Visibility Return Argument Pre-condition Post-condition

type
getMessage Public String Void Retrieve the content
of the comment.
getDate Public Date Void Retrieve the date
specifying when the
comment was
created.
getCommentor Public Student Void Retrieve the creator
of the comment.
Table 12 operational description2

Vote class

Vote
-voteID:int
-voteType:int
+getVoter():Student
+getVoteTYpe():Student
+isType(type:int):Boolean
+getVoteID():int
Table 13 vote Class

18 | P a g e
 <selamawi 2016

Attribute description for vote class

Attribute Type Visibility Invariant

voteID Integer Private voteID<>NULL. It
must contain only
unique integers.
voteType Integer Private voteType<>NULL. 0
and 1 are the only
possible values that
can be assigned to
this field.
Table 14 Attribute Description5

Operation description for vote class

Operation Visibility Return type Argument Pre-condition Post-

condition
getVoter Public Student Void Vote should Retrieve the
exist. voter.
getVoteType Public Integer Void Vote should Retrieve the
exist. vote type.
isType Public Boolean Void
getVoteID Public Integer Void Vote should Retrieve the
exist. ID of vote.
Table 15 operational Description3

Tag class

Tag
-tagID:int
-tagName:string
+getName():string
+getID():int
Table 16 tag class

19 | P a g e
 <selamawi 2016

Attribute description for tag class

Attribute Type Visibility Invariant

tagID Integer Private tagID<>NULL. It

must contain only
unique integers.
tagName String Private tagName<>NULL>.
It must contain only
characters.
Table 17 Attribute Description6

Operation description for Tag class

Operation Visibility Return Argument Pre-condition Post-condition

type
getName Public String Void Tag should exist Retrieve the name of the
tag.
getID Public Integer Void Vote should exist Retrieve the ID of the
vote.
Table 18 operational Description4

Authenticator class

Authenticator
-userName:string
-password:string
+authenticate():Boolean
+encryptPassword():string
Table 19 Authenticator Class

Operation description for Authenticator class

Operation Visibility Return type Argument Pre- Post-condition

condition
authenticate Public Boolean Void Session Session pertaining
pertaining user should exist.
user shouldn’t
exist.
encryptPassword Public String Void Password Password should
should be in be in encrypted
plain or form.
unencrypted
form.
Table 20 operational Description6

20 | P a g e
 <selamawi 2016

Attribute description for Authenticator class

Attribute Type Visibility Invariant

Username String Private Username<>NULL.
 Only alpha
numerical
characters are
allowed.
 Must be at least
6 characters
long.
 Mustn’t contain
space
 Must be unique
for every user.
Password String Private Password<>NULL.
 Must contain at
least one
punctuation
mark.
 Must include
number.
 Must contain
both upper and
lower case letters.
 Must be at least 7
characters long.
 Can’t contain
space.
Table 21 Attribute Description7

21 | P a g e
 <selamawi 2016

References

 Tutorials Point{http://www.tutorialspoint.com/struts_2/basic_mvc_architecture.htm}
[May 21,2:00PM]

Bibliography
 KidusMakonnen, Tibebe Solomon, FraolChala, Eyob Solomon, DerejeMengistu

(Deccember 2015), Software Design Specification:Identification System

 Videk(May 2004), Software Design Specification: InserterVision Report System

 Ian Sommerville (2011). Software Engineering 9.Boston: Pearson Education, Inc.

22 | P a g e