flute 2016

Addis Ababa Institute of Technology

Center of Information Technology and
Scientific Computing
Department of Information Technology
Project Title: FLUTe
Software Design Specification
Team Members:-
1.Abel Kefale
2.Tekleab Hadush
3.Yohans T/Wold
4.Zelalem Molla
Advisors: Eyob Wondimkun
Date:- 21 January, 2017
 flute 2016

Table of Contents
List of Tables ........................................................................................................ ii

List of figures ...................................................................................................... iii

Acronyms, Abbreviations ............................................................................... iv

1. Introduction ......................................................................................................1
1.1 Purpose.............................................................................................................1

1.2 General Overview ...........................................................................................1

1.3 Development Methods & Contingencies.......................................................3

2. System Architecture .......................................................................................4

2.1 Subsystem decomposition ..............................................................................4

2.1.1 UML Activity Diagram ........................................................................4

2.1.2 UML Component Diagram ...................................................................9

2.2 Hardware/software mapping .......................................................................10

2.2.1 UML Deployment Diagram ...................................................................10

3. Object Model ..................................................................................................12

3.1 Class Diagram ...............................................................................................12

3.2 Sequence Diagram ........................................................................................13

4. Detailed Design ..............................................................................................18

References ...............................................................................................................25

i|Page
 flute 2016

List of Tables

Table 4.1: Account class…………………………………………………………………………18

Table 4.2: Attributes description for Account class ……………………………………………..18

Table 4.3: Operation description for Mobile Client class………………………………………..18

Table 4.4: User class……………………………………………………………………………...19

Table 4.5: Attributes description for user…………………………………………………………19

Table 4.6: Update Profile………………………………………………………………………….19

Table 4.7: Attributes description for Update Profile………………………………………………20

Table 4.8: student class……………………………………………………………………………20

Table 4.9: Attributes description for Student Class………………………………………………..20

Table 4.10: Attributes description for Student Class………………………………………………21

Table 4.11: Adminstrator class…………………………………………………………………….21

Table 4.12: Attributes description for Adminstrator class………………………………………..22

Table 4.13: Operation description for Adminstrator class………………………………………..22

Table 4.14: Instructor class……………………………………………………………………….22

Table 4.15: Attributes description for Instructor class……………………………………………23

Table 4.16: Operation description for Instructor class …………………………………………..23

ii | P a g e
 flute 2016

Table 4.17: chat class………………………………………..………………………………………….24

Table 4.18: Attributes description for Chat class………………………………………..……………...24

Table 4.19: Operation description for Chat class………………………………………………………24

List of figures

Figure 1.1 Context-Diagram…..…………………………………….………….………….…….2

Figure 2.1 Sign in Activity diagram ……………………………….………….………….……..4

Figure 2.2 Admin activity diagram…..…………………………………….………….…………6

Figure 2.3 View announcement and post idea activity diagram..………….………….…………7

Figure 2.4 Upload/Download files activity diagram...…….…….……….………….…………..8

Figure 2.5 Component Diagram of FLUTe.……………………………….………….………….9

Figure 2.6 Deployment diagram………………………………….………….………….……….11

Figure 3.1 Class diagram for Model……………………………...….………….………….……12

Figure 3.2 Class diagram for control ………………………………….………….………….….13

Figure 3.3 Login Sequence Diagram.………………………………….………….………….….15

Figure 3.4 Logout Sequence Diagram..……………………………….………….………….…..16

Figure 3.5 Register Sequence Diagram..……………………………….………….………….…17

Figure 3.6 Admin Sequence Diagram..……………………………….………….………….…..18

iii | P a g e
 flute 2016

Acronyms, Abbreviations

-AAiT---------------------Addis Ababa Institute of Technology

-SDS----------------------Software Design Specification.

-UML---------------------Unified Modeling Language.

-URL----------------------Uniform Resource Locator.

-ECTS---------------------European Credit Transfer and Accumulation System.

-ITSC----------------------Center of Information Technology and Scientific Computing.

-FDD----------------------Future-Driven Development.

-SRS----------------------Software Requirement Specification.

iv | P a g e
 flute 2016

1. Introduction
1.1 Purpose
The purpose of System Design document is to translate the business requirements and business
processes into a technical design that will be used to develop the application.

This software design specification documentation is intended to describe the detailed structure of
the components of the project flute and the precise implementation details required to satisfy the
requirements as specified in the software requirements specification (SRS). It is assumed that the
reader of this document has already read the SRS, since this document also defines the
implementation details of the desired behavior given the requirements within it. This document
will build heavily on the SADD and therefore the knowledge of the general system architecture is
greatly recommended prior to commenting this design specification document.

This document will be used to help:

 To identify the functional structure, data and algorithms to be implemented in the project
development.
 To identify required system resources.
 To be used to assess the impact of requirement changes and handle them.
 To assist in producing test cases.
 To be used to verify compliance with requirements specified in the SRS.
 To aid in maintenance activities after the product is in launched in times of failure.

1.2 General Overview

This system is a web application platform for the AAiT community and it is mainly aimed at
providing a digital or web based announcements, news feed updates, student and instructor course
group for handling any updates, reschedules and lecture materials sharing within a group of the

1|Page
 flute 2016

students enrolled for that course. In addition, administrators and offices can be able to create a
course group form this web application and announce their updates for the community, students
will also be able to share files, upload or download from the local server shared by their peers.
Chatting with users will also be delivered.

For the development of the system we choose an incremental approach type of called feature-
driven development (FDD) in which a number of dependent phases that are repeated sequentially
with no feedback loops.

Till now we haven’t made any changes or modifications to the previously designated system
design. And from the general point of view the system looks like the context-diagram below.

Figure 1.1 Context-Diagram

2|Page
 flute 2016

1.3 Development Methods & Contingencies

For developing this system, we have chosen the incremental approach type of called feature-driven
development (FDD), a software development approach, in which a number of dependent phases
that are repeated sequentially with no feedback loops. With this approach the clear goal and
solutions will be primarily identified, requirements will be splinted for development purposes and
delivered in increments. Complete product evolves over time and therefore customers do not need
to wait for the final deliverable, each incremental releases a partial of known solution so that they
can began to realize business value without having to wait for the complete solution. The first
increment in developing the system is often the core product that is the basic requirements are
addressed and other supplementary features will be delivered incrementally as a module for the
basic system. This approach will also enable to provide new and creative features to be added at
any time. This conceptual approach will be used for the whole system development in order to
achieve a scalable solution.

Despite the conceptual design of the system is designed based on an incremental approach, an
object oriented approach will be used for the diagraming and modeling of the system components
and users. The UML modeling will be used for designing the objects class diagrams and
interactions.

While in the process of the design phase if the interface design and the system performance gets
very high with the consideration of the hardware’s capability for handling the systems final
deliverable, there might be an alternative approach to switch the system design to a fully social
network with the addition of video streaming and wiki features in which the users to have an
advantage of publishing articles and stories.

3|Page
 flute 2016

2. System Architecture

2.1 Subsystem decomposition

2.1.1 Activity diagram

Sign in Activity Diagram

Figure 2.1 Sign in Activity diagram

4|Page
 flute 2016

 Login: - enables the user to login to the system using his/her account information.
 If registered the system authenticates his account information deny or accept his/her request
and enable access to the system.
 If unregistered the system will notify the user he needs to be authenticated to the system
before logging in and displays a registration form.
 If registered user insert invalid username and/or password the system will notify the user to
insert valid username and password and redirect to the sign in page.

5|Page
 flute 2016

Admin Activity diagram

Figure 2.2 Admin activity diagram

6|Page
 flute 2016

 View user: - enables the admin to see the number of users and their activities.
 Control post:-enables the admin to evaluate uploaded files, stories or comments.
 Post Announcement:-The admin can post Announcements.
 The Admin can view posted ideas.
 The admin can deny or allow comments according to the sites policy.

 The admin can deny or allow posted ideas according to the sites policy.

View announcement and post idea activity diagram

Figure 2.3 View announcement and post idea activity diagram

 View announcement: - enables users to view public announcements.

 Users can give comment and like on these public announcements.
7|Page
 flute 2016

 Post idea:-enables users to post ideas.

 Users can give comment and like these on these posted ideas.

Upload/Download files activity diagram

Figure 2.4 Upload/Download files activity diagram

8|Page
 flute 2016

 Upload file:-enable users to upload files.

 If users try to upload invalid files the system will notify the user to select and upload
valid files.
 Download files: - enable users to download files on the file spot.

2.1.2 UML Component Diagram

Figure 2.5 Component Diagram of FLUTe

9|Page
 flute 2016

2.2 Hardware/software mapping

2.2.1 UML Deployment Diagram

Deployment diagram shows the physical nature or topology of the system, and describes what runs
where. Represents the deployment view of the system.

Nodes are nothing but physical hardwares used to deploy the application. The nodes included in
our system are the following

Database Server: - used to store site data, user information and account data.

Web Server: - middle layer between the internet cloud and the database server used to sort and
organize requests and responses between the client and server.

Modem/ Middle layer device: - used to create connection between the user and the internet cloud
or to provide network communication link.

Internet: - the main communication media between the client/user and server/data provider.

End Device: - an end device in the user side for accessing and retrieving data from the site.

End user: - a user accessing the website.

10 | P a g e
 flute 2016

Figure 2.6 Deployment diagram

Deployment diagram also describes the topology of the system and configuration of run-time
processing elements and the software components and processes.

11 | P a g e
 flute 2016

3. Object Model
3.1 Class Diagram

The architectural design have total of 11 classes.

12 | P a g e
 flute 2016

Figure 3.1 Class diagram

13 | P a g e
 flute 2016

3.2 Sequence Diagram

The system allow users to login

Figure 3.3 Login Sequence Diagram

14 | P a g e
 flute 2016

The system should allow users to logout

Figure 3.4 Logout Sequence Diagram

15 | P a g e
 flute 2016

The system should allow users to register an account

Figure 3.5 Register Sequence Diagram

16 | P a g e
 flute 2016

Admin Sequence Diagram

Figure 3.6 Admin Sequence Diagram

17 | P a g e
 flute 2016

4. Detailed Design

Table 4.1: Account class

Account
+Create Account:String
+Login:String
+Logout:String

+getNewAccount()
+getLogint()

Table 4.2: Attributes description for Account class

Attribute Type Visibility Invariant

Create Account String Public Create Account <> NULL and must contain first, middle
and last name and shouldn’t contain special characters and
integers.
Login String Public Login <> NULL must be enter to the system if the user
have valid account.
Logout String Public Address <>NULL and it must be contain to exit from the
system.

Table 4.3: Operation description for Mobile Client class

Operation Visibility Return Argum Pre-Condition Post

type ent Condition
Get New Account Public void . The user personal can get a The user
new account if he never personal can
open account. get a new
account if he
never open
account.
Get Login Public void . The user can logged to the The user can
system if he has an account logged to the
already. system if he
has an
account
already.

18 | P a g e
 flute 2016

Table 4.4: User class

User
+full name:String
+last name:String
+Email:String
+Password:String

Table 4.5: Attributes description for user

Attribute Type Visibility Invariant

Full name: String Public Name <> NULL and must contain first, middle and
last name and shouldn’t contain special characters
and integers.
Lname: String Public Name <> NULL and must contain first, middle and
last name and shouldn’t contain special characters
and integers.
Password Integer Public Password<>NULL
 Must contain capital letter
 Must contain special character
 Must contain numbers
Email String Private Email <> NULL
 Must contain @
 Must contain. (dot)
 Position of @ >1
 Position of (dot)>position of @ + 2
 Position of (dot)+3<= total length of email
address and the total character of the Email
is at least 5 characters
Table 4.6: Update Profile

Update profile
+change fullname:String
+change username:String
+Password:String

19 | P a g e
 flute 2016

Table 4.7: Attributes description for Update Profile

Attribute Type Visibility Invariant

Change full name String Public Change full name <> NULL and must contain first,
middle and last name and shouldn’t contain special
characters and integers.
Change username String Public Change username <> NULL and must contain first, last
name and shouldn’t contain special characters and
integers.
Password Integer Public Password<>NULL
 Must contain capital letter
 Must contain special character
 Must contain numbers

Table 4.8: student class

Student
+student id : String
+update profile : String
+Comment : String
+Post : String
+getStudent id()
+getUpdate profile()

Table 4.9: Attributes description for Student Class

Attribute Type Visibility Invariant

Student id Integer Public Student id <> NULL and must contain id number and
shouldn’t contain special characters and integers.
Update profile String Public Update profile <> NULL and must contain first, middle
and last name and shouldn’t contain special characters
and integers.
comment Integer Public comment<>NULL
 Doesn’t blank
 Doesn’t contain special character
post String Private post <> NULL
 New ideas
 Suggestions
 Announcements
 messages
20 | P a g e
 flute 2016

Table 4.10: Attributes description for Student Class

Operation Visibility Return Argument Pre-Condition Post

type Condition
Get Student id Public void . The user have his or The user
her own personal id have his
number. or her
own
personal
id
number.
Get Update Profile Public void . The user can update The user
his personal status. can
update
his
personal
status.

Table 4.11: Adminstrator class

Adminstrator
+adduser:String
+ removeUser:String
+announcement:String
+post:String
+verify user:String
+announcement()
+post()

21 | P a g e
 flute 2016

Table 4.12: Attributes description for Adminstrator class

Attribute Type Visibility Invariant

+adduser String Public Adduser<> NULL and must contain users profile.

+removeuser Integer Public Remove user <> NULL remove user entirely from the
system.
Post String Public post <>NULL and it must be contain all new
informatioins.
Announcement String Private Announcement <> NULL
 new class schedules
 upcoming events
 seminars
 meetings

Verify user

Table 4.13: Operation description for Adminstrator class

Operation Visibility Return type Argument Pre-Condition Post Condition

announcement Public void . The administrator The administrator can

can announce new announce new events
events for users and for users and
instructors. instructors.
post Public void . The administrator The administrator can
can post class post class schedules
schedules and other and other related
related things for things for clients.
clients.

Table 4.14: Instructor class

Instructor
+adduser:String
+ removeUser:String
+create page:String
+chat:String
+describe service:String

22 | P a g e
 flute 2016

+getchat()
+getdescribe service()

Table 4.15: Attributes description for Instructor class

Attribute Type Visibility Invariant

+adduser String Public Adduser<> NULL and must contain users profile.

+removeuser Integer Public Remove user <> NULL remove user entirely from the
system.
Create page String Public Create page <>NULL and it must be contain instructor
name.profile and files and not contain special character.
Chat String Private Chat<> NULL clients can talk each other.

Describe service String private Describe service<>NULL describe services that are
belongs for clients.

Table 4.16: Operation description for Instructor class

Operation Visibility Return Argument Pre-Condition Post

type Condition
getChat Public void . To talk clients each To talk
other. clients
each
other.
getDescribeService Public void . Services like office Services
hour give directions like office
for users. hour give
directions
for users..

23 | P a g e
 flute 2016

Table 4.17: chat class

Chat
+isonline:String
+isoffline:String
+savechat:String
+saveChat()

Table 4.18: Attributes description for Chat class

Attribute Type Visibility Invariant

isonline String Public isonline<> NULL and must check the users is online.

+isoffline Integer Public Isoffline <> NULL must check the user is offline.

+saveChat String Public saveChat <>NULL and it must be save the chat
conversations.

Describe service String private Describe service<>NULL describe services that are
belongs for clients.

Table 4.19: Operation description for Chat class

Operation Visibility Return type Argument Pre-Condition Post

Condition
saveChat Public void . Save chat conversation Save chat
by date,time and type of conversation
the conversation. by date,time
and type of
the
conversation.

24 | P a g e
 flute 2016

References

Bibliography
 Competitive Counselling System, Software DesignSpecification Version 1 By Saurabh
Singh.

Web resource
 The Complete Guide to UML Diagram Types with Examples
< http://creately.com/blog/diagrams/uml-diagram-types-examples/> Date:29.12.2016
 UML - Deployment Diagrams
< https://www.tutorialspoint.com/uml/uml_deployment_diagram.htm >Date:30.12.2016
 UML - Component Diagrams
< https://www.tutorialspoint.com/uml/uml_component_diagram.htm > Date:13.01.2017
 UML Activity Diagrams: Guidelines
< https://msdn.microsoft.com/en-us/library/dd409465.aspx> Date:07.01.2017
 Lucid Chart-Component Diagram Tutorial
< https://www.lucidchart.com/pages/uml/component-diagram> Date:11.01.2017
 The component diagram
< http://www.ibm.com/developerworks/rational/library/dec04/bell/> Date:15.01.2017

25 | P a g e