CTIS 411 Software Design Description

T E A M 6

M e h m e t A k i f G Ü Z E Y M u s t a f a E m i n G Ü L E N

Ö m e r Ö K S Ü Z L E R Y i ğ i t Ö m e r K O Y T A K

Bilkent Club Management System

Beyhan AKPORAY

1

Contents

1 Design Strategy & Principles ................................................................................................... 2

1.1 Design Strategy .................................................................................................................. 2

1.2 Design Principles ................................................................................................................ 3

1.2.1 Open Close Principle .................................................................................................... 3

1.2.2 Dependency Inversion Principle ................................................................................... 4

1.2.3 Single Responsibility Principle...................................................................................... 4

2 Processing & Control ................................................................................................................ 4

3 COTS ........................................................................................................................................ 5

4 Non-Functional & Quality Requirements ................................................................................... 6

5 Software Architecture Design (High-Level Design) ................................................................... 8

5.1 Separation of Concerns ...................................................................................................... 9

6 Subsystem Interface Design ..................................................................................................... 9

7 Physical Design ...................................................................................................................... 10

8 Subsystem Design ................................................................................................................ 11

Table of Figures

Figure 1 Concurrent Communication Diagram _________________________________________________ 8

Figure 2 Separation of Concerns ____________________________________________________________ 9

Figure 3 Deployment Diagram ____________________________________________________________ 10

Figure 4 Class Diagram of BCM ____________________________________________________________ 11

Figure 5 Report Generation Analysis Sequence Diagram ________________________________________ 12

2

File

Name

Version Number Date Status Description

SDD 1.1 01.03.2015 Updated Development environments are updated.

Some envinronments are delete and some is added.

1 Design Strategy & Principles

1.1 Design Strategy

Our design decision is mainly object oriented design approach. The elements of object oriented

design is:

Objects: The simplest element of OOD. Every entity is an object. A club member

instantiation is represented with an object in our software.

3

Classes: A bit higher level of objects. Objects can be instantiated from classes. It is simply

a generalized description of an object. Classes, hold every information about objects. A

club will be represented through a class in our software.

Encapsulation: Due to the nature of OOD, data variables and methods(operations) are held

together as bundles. This is the encapsulation of objects, its attributes, and methods.

Member management subsystem is considered as encapsulated form of our member

management classes.

Inheritance: A class can inherit a super class. Every club member user is a user but not

every user is necessarily a club member. Club Member User class can inherit User class.

Polymorphism: This is a mechanism provided by OOD languages. Functions with same

names can be behaving differently depending on the parameters, or the place the method

is called. For example there can be different constructor methods for our objects. An object

can exist with its all attributes or with some only.

Design process for our project is:

Solution design is concluded from requirements or sequence diagrams.

Objects are identified and encapsulated depending on similarities.

A hierarchical relation between the objects is defined

Bottom-Up Design Approach will be applied throughout the project. Bottom-Up approach is about

first building one of the simplest modules then building the bigger modules and including the

smaller ones.

1.2 Design Principles

We will try to avoid three characteristics that would cause us to end up with a bad design.

Rigidity – The product should be open to changes, cost of making changes shouldn’t go up

high too much.

Fragility – When a change is made, the change that was made shouldn’t break the other

parts of the code.

Immobility – This characteristic mean that not being able to reuse another application or

code.

There are few principles that can be applied for object oriented design strategy.

1.2.1 Open Close Principle

Classes, modules, methods should be open for extendibility but close direct modification. While

the development takes place, if a class’ attributes or methods needed to be extended, class

shouldn’t be changed but needs to be extended. This principle can be applied to packages,

libraries, or modules. This principle will help us come up with a structured code and avoid fragility

4

and immobility. When a change is made in the super class it won’t affect the classes who extend

it. For our project, object for managing members extends add/delete/update methods.

1.2.2 Dependency Inversion Principle

This principle simply suggests that high level objects shouldn’t rely on low level objects. Instead

there will be interfaces in between high and low level objects. This interface object will help

communicate these two objects and ensure dependency inversion principle. Database and other

objects can communicate using a database interface file. This way, a high level module relies on

an abstraction rather than a low level module. This will ensure to avoid fragility and rigidity.

1.2.3 Single Responsibility Principle

Due to the nature of object oriented design, naturally, every object should do its specific task. One

object can undertake another object’s task(s). It wouldn’t be wrong by the syntax or anything, it

would work. But it cannot satisfy single responsibility principle and fail to avoid fragility.

2 Processing & Control

Our software will support many different users simultaneously. Therefore, it will be a concurrent

system. Apache Server is designed in a way that it will allow multiple users to connect at the same

time. Apache server uses a multi-thread mechanism within itself to handle multiple clients at the

same time. Therefore, no coding is necessary to handle multiple clients at the same time.

The arrays within the PHP language will be used for message queuing:

$GLOBALS :An array can be used for message passing through different php pages. This

array holds all global variables within the software.

$_SERVER: Information about the server is held in this array that allows message passing

among web pages. For example current php file’s name is stored in this array.

$_GET: Can be considered as the simplest predefined array in PHP language. It can be

used to pass messages among PHP pages through HTML Requests. This array can be

used with GET method within the forms or page redirects. When redirecting to a page,

message is appended at the end of the redirecting page. As can be seen here. This

package also carries host information and accepted file types.

$_POST: This is an array that can be used with POST method. POST holds more

information than GET method. It is also considered to be more secure than GET method.

5

While GET method shows the information in the web browser’s address bar, POST method

does not show the information it carries in the address bar.

$_FILES: This array contains the information about the files uploaded by the client, such as

file’s name, size, extension etc.

$_SESSION: After a user logs in to a PHP system, a specific SESSION array is allocated

for that user. This array holds necessary information about the current user. Every user has

a different SESSION allocated for them, when they log out, the SESSION array must be

destroyed. Its main advantage is that it can store very large amounts of data very easily

within itself. Another major advantage is that, it is stored in server side. This makes it more

secure comparing to Cookies.

$_ENV: This is basically same with SESSION array with one difference, which is, SESSION

is user-specific whereas this is a global array.

$_COOKIE: It is a less secure form of SESSION, it is stored on client side. This can be a

major security vulnerability if important user information is stored within COOKIES.

Because it is on client side, it can be reached and read so easily. Another difference is,

cookies will go on even the client is shut down and opened again.

HTTP is an abbreviation for Hyper Text Transfer Protocol. It is used over the internet widely today.

Under normal circumstances, it uses port 80 and requires a synchronized communication between

the client and the server.

3 COTS

IDE Tools will be used to implement the system. HTML5, CSS, PHP, JavaScript, jQuery

technologies will be used through these Integrated Development Environment Tools:

NetBeans

Eclipse

6

Sublime Text

Notepad++

Oracle MySQL Workbench 6.2.4 will be used to implement the database and maintain the

database.

Apache 2.2 shall be installed to the web server as server software.

4 Non-Functional & Quality Requirements

“Design is the way you implement the requirements. Design provides structural stability,

flexibility and cohesiveness. Design is not the same thing as requirements gathering. If you're

having trouble conceptualizing the design, write a Software Design Specification.”

Usability

o Users will be feeding inputs to the system. To minimize the human error factor, the

system will provide convenience to the users such as showing a drop-down calendar

instead of user entering the date manually.

o Time taken to learn the software will be reduced by the User’s Manual

o Informative error messages will be used

o System will have an user-friendly interface. Fitts’ Design Law and Hick’s Design Law

will be applied in order to ensure this requirement.

Reliability

o System will be designed to be able to perform its functions without any failure

o All accounting operations will be performed through this system therefore data and

calculations’ accuracy will be ensured with boundary analysis and equivalence

partitioning testing, users will not be able to input wrong data

Maintainability

o For future, improvements on the system will be done by applying

clean code

comments

indentations

7

o The system will be designed by using generalization, inheritance, include/extend

operations

Recoverability

o The database will be backed up weekly and if system goes down or hacked, it can

be recovered by using back-up. This will be ensured by PHP coding.

Working on multiple platforms

o System will be designed to be compatible with different platforms such as mobile,

tablet, pc and laptop. This will be ensured with use of compatible web template,

technologies and necessary codes.

8

5 Software Architecture Design (High-Level Design)

A HTTP request is received from the user. According to the user’s use cases coordinator object

will forward to request to the related sub-system. The sub-system will communicate with the

database wrapper objects by function calls with parameters. When the results are collected as

data from the database wrapper objects, presentation object will put the data in a nice looking form

and display it on the user’s screen.

Figure 1: Concurrent Communication Diagram

9

5.1 Separation of Concerns

The users will reach the system through their browser. Web browser will send a HTTP request to

our web server. Through our graphical user interface, the users will have access to the features of

our software. Business logic layer will handle what the user wants. This layer will handle the user’s

request by database access layer. Query result will be sent back to graphical user interface, and

from there, to the users’ web browser.

Figure 2: Separation of Concerns

6 Subsystem Interface Design

A request including modifications about a user, will be sent to member management

subsystem. Member management subsystem will reach the database through user and

club database wrappers. Because a change about a user means changing the data on user

and club tables.

A request including modifications about a club, will be sent to club management subsystem.

Club management subsystem will reach the database through user and club database

wrappers. Because a change about a club means changing the data on user and club

tables.

Every user in the system shall be able to use the accounting feature related to their

permissions. Any member can send this request to the system through their web browser.

The facade object, will send the request to accounting subsystem. Accounting subsystem

shall get the data using report, user, club, account, and activity wrappers.

10

Every user is entitled to generate reports as their accounts are given permission. The

facade object will send the request to reporting subsystem, the subsystem gets the data

from report, user, club, account, and activity wrappers.

Everyone except club managers/members will be able to manage the activities. Activity

management subsystem will reach out the necessary data through club, account, and

activity wrappers.

7 Physical Design

The users will reach the system through their web browsers. Their browsers does not have to

be necessarily a Windows machine or Linux, neither Android OS nor iOS. In other words, the

system is platform independent. The users need the Internet to reach the webserver. It is

assumed that Apache 2.0 will be used on web server. Besides, our source code will be

uploaded to the web server and there will be a database server that runs PHP MySQL

connected to this web server.

Figure 3 Deployment Diagram

11

8 Subsystem Design

Figure 4 Class Diagram of BCM

12

User User UIFACADE Report DB

Displayqueryresult($);

generateReport();

requestPage(1);

Select Report Type

transmitReportRequest($sql);

query($sql);

sendPage();

displayReportTypes();

Figure 5 Report Generation Sequence Diagram

User FACADE UserUI Member

manageMember();

requestPage();

sendPage();

enters input

DBAdapter

ManageMember($sql);

displayQueryResult();

manageMember($args)

Figure 6: Managing Member Sequence Diagram