CTIS 411 Software Design Description - … · CTIS 411 Software Design Description TEAM 6 ......
Transcript of CTIS 411 Software Design Description - … · CTIS 411 Software Design Description TEAM 6 ......
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