Main Design Project

SYSTEM DESIGN
System design is the solution for the creation of a new system. This phase focuses on the
detailed implementation of the feasible system. It emphasis on translating design.
Specifications to performance specification. System design has two phases of development
Logical design
Physical design
During logical design phase the analyst describes inputs (sources), output s(destinations),
databases (data sores) and procedures (dataflows) all in a format that meets the user
requirements. The analyst also specifies the needs of the user at a level that virtually
determines the information flow in and out of the system and the data resources. Here the
logical design is done through data flow diagrams and database design. The physical design is
followed by physical design or coding. Physical design produces the working system by
defining the design specifications, which specify exactly what the candidate system must do.
The programmers write the necessary programs that accept input from the user, perform
necessary processing on accepted data and produce the required report on a hard copy or
display it on the screen.
INPUT AND OUTPUT DESIGN

INPUT DESIGN:
Input design is the link that ties the information system into the world of its users. The input
design involves determining the inputs, validating the data, minimizing the data entry and
provides a multi-user facility. Inaccurate inputs are the most common cause of errors in data
processing. Errors entered by the data entry operators can be controlled by input design. The
user-originated inputs are converted to a computer based format in the input design. Input
data are collected and organized into groups of similar data. Once identified, the appropriate
input media are selected for processing. All the input data are validated and if any data
violates any conditions, the user is warned by a message. If the data satisfies all the
conditions, it is transferred to the appropriate tables in the database. In this project the student
details are to be entered at the time of registration. A page is designed for this purpose which
is user friendly and easy to use. The design is done such that users get appropriate messages
when exceptions occur.
OUTPUT DESIGN:
Computer output is the most important and direct source of information to the user. Output
design is a very important phase since the output needs to be in an efficient manner. Efficient
and intelligible output design improves the system relationship with the user and helps in
decision making. Allowing the user to view the sample screen is important because the user is
the ultimate judge of the quality of output. The output module of this system is the selected
notifications.
DATABASE
DATABASE DESIGN:
Databases are the storehouses of data used in the software systems. The data is stored in
tables inside the database. Several tables are created for the manipulation of the data for the
system. Two essential settings for a database are the field that is unique for all the record
occurrences. the field used to set relation between tables. Normalization is a technique to
avoid redundancy in the tables.
SYSTEM TOOLS
The various system tools that have been used in developing both the frontend and the back
end of the project are being discussed in this chapter.
FRONT END:
PHP, HTML, CSS, JAVA SCRIPT are utilized to implement the frontend.
PHP (Hypertext Preprocessor): PHP is a widely-used open source general-purpose
scripting language that is especially suited for web development and can be embedded into
HTML.
HTML (Hyper Text Mark-up Language): HTML is a syntax used to format a text
document on the web.
CSS (Cascading Style Sheets): CSS is a style sheet language used for describing the look
and formatting of a document written in a mark-up language.
Java Script: JS is a dynamic computer programming language. It is most commonly used as
part of web browsers, whose implementations allow client-side scripts to interact with the
user, control the browser, communicate asynchronously, and alter the document content that
is displayed. Java Script is used to create pop-up windows displaying different alerts in
BACK END
The back end is implemented using MySQL which is used to design the
databases.
MySQL: MySQL is the world's second most widely used open-source relational
database management system (RDBMS). The SQL phrase stands for Structured Query
Language.
TABLES:
Addcolor
Name Field Type Allow Null Default Primary key Extra

Id Int (100) No None Yes Auto
Increment
Color Varchar No None No None
(100)
View Int (11) No 1 No None
Position Int (11) No None No None
Status Enum No None No None
(0,1)
Addcolorimage

Increment
Prod_id Int (100) No None No None
Color_id Int (100) No 1 No None
(0,1)
Adddeliverytime

Increment
Time Varchar No None No None
(100)
(0,1)
Addproduct

Increment
Title Varchar No None No None
(100)
Price Varchar No None No None
(100)
Discountedpric Varchar No None No None
e (100)
Description Varchar No None No None
(255)
Cat_id Int (11) No None No None
Effective_price Int (100) No None No None
Deliverytime Varchar No None No None
(100)
(0,1)
Addproductcolorimage

Increment
Color_id Int (100) No None No None
Imagepath Varchar No None No None
(255)
(0,1)
Addsize
Name Field Type Allow Null Default Primary Extra

key
Increment
Size Varchar No None NO None
(100)
(0,1)
Bianshipping
Name Field Type Allow Default Primary Extra

Null key
Increment
Site_name Varchar No None No None
(100)
Site_descriptio Medium No None No None
n text
Pagging Int (11) No 0 No None
Cod Varchar No None No No
(100)
Shipping Varchar No None No No
(100)
Cms

key
Increment
Title Text Yes Null No No
Content Text Yes Null No No
key Varchar Yes Null No No
(100)
Menucategory

key
Increment
Category Varchar No None No None
(100)
status Enum No None No None
(0,1)
Class Varchar No Edit No None
(100)
Menusbcategory

key
Increment
C_id Int (11) No None No None
Subcategor Varchar No None No None
y (255)
Link Varchar No None No None
(255)
status Enum No None No None
(0,10
Productcategory

key
Increment
Name Varchar No None No None
(255)
Imagepath Varchar No None No None
(255)
(0,1)
Userorderaddress
Name Field Type Allow Null Default Primary key

Id Int (100) No None Yes
U_id Int (11) No None No
Fname Varchar (100) No None No
Mname Varchar (100) No None No
Lname Varchar (100) No None No
Streetaddress1 Varchar (100) No None No
Zipcode Varchar (100) No None No
City Varchar (100) No None No
State Varchar (100) No None No
Contact_no Varchar (100) No None No
Purchasedate Varchar (100) No None No
Status Int (11) No None No
Email Varchar (100) No None No
Type Int (11) No None No
Shoppingcart Text No None No
Amount Varchar (100) No None No
shipping Varchar (100) No None No
Productuser

Email Varchar (100) No None No
Password Varchar (100) No None No
Fname Varchar (100) No None No
Mname Varchar (100) No None No
Lname Varchar (100) No None No
Zipcode Varchar (100) No None No
City Varchar (100) No None No
State Varchar (100) No None No
Contact_no Varchar (100) No None No
Status Int (11) No None No
Shopcart

A_id Int (100) No None No
Item Text No None No
Type Int (11) No None No
Cod Varchar (100) No None No
Shipping Varchar (100) No None No
IMPLEMENTATION
This chapter includes the detailed design used to build the application. The system's design is
used to create the functions and operations of the gathered requirements in detail, including
screen layouts, business rules, process diagrams, and other documentation. The output of this
chapter describes the new system which is defined as a collection of modules and
subsystems. This design stage takes the initial input requirements that were identified in the
approved requirements specification document. For each requirement, there is a set of one or
more design elements that are produced using the different prototypes. These design elements
describe the desired software features, in detail, including functional hierarchy diagrams,
screen layouts, activity diagrams, and class diagrams. The intention of these diagrams is to
describe the software in detail so that the system can develop the application with less
additional design input. The systems mock screen shots are shown later in this chapter.
Detailed Scope
This project is supposed to be delivered in three phases, with each phase being an add-on to
the project that makes it more usable and acceptable.
1.In the first delivery, the application must be able to add an item to the shopping cart and
case.
Browse categories on the home page
Select a category and browse through the items
View more information about an item.
Add an item to the shopping cart.
Continue shopping or go to checkout for the item.
2. The application must be able to check out the items in the cart.
Check out the items.
Continue shopping.
Delete the items to update the shopping cart.
3. The application asks for user authentication before checking out.

Add items to the cart.
Check out the items
Log in with a valid username and password.
4. The application must bring up the order form for the check out.
Complete the information on the order form.
Place the order.
Static Decomposition and Dependency Description
This section contains the system use-case diagram for the application and has a detailed
explanation for each use case in the system.
High-Level Use Case Diagram

The systems use case shows the user a detailed view of the system and how the actors would
interact with each other and with the system. The explanation for each use case is then
provided below the system use case for the administrator (Figure 1) and the user (Figure 2),
helping the user to understand who are the actors areas as well as giving the description for
each use case along with its pre- and post-conditions that should be satisfied once the use
case is implemented in the software.
Figure 1 demonstrates the use case of for an administrator where he or she has access
to the application. The administrator can access the home page, select a category, or
add/delete items to/from the cart.
Figure--1
Use-Case Diagram: Admin
Figure 2 demonstrates the use case for users where they have access to the application.
They can access the home page, select a category, add/delete items to/from the cart, view
the shopping cart, and decide to either continue shopping or check out. They are required
to go through the user-authentication form (login) which would only allow them to place
an order for the items they selected.
Figure--2
Use-Case Diagram: User
Below are the different use cases in the system, the use case, and the actors associated with
each use case. The description is used for a novice user to better understand the workings of
the system and the pre-conditions that should be satisfied before invoking each use case.
Use-Case Number: US-001

Application: Bian
Use-Case Name: Home page
Use-Case Description: This use case lets the user/administrator view the home page which
has different categories when they first run the application.
Primary Actor: Admin/User
Precondition: Run the application.
Post-condition: The user successfully runs the application and is able to view the home page
with the different categories.
Basic Flow:
Run the application
View the home page
Browse the categories
Use-case number: US-002

Application: Bian
Use-case name: Select category
Use-case description: This use case details the category for selecting a process where the user
can browse through the different categories and select one category to view items.
Primary actor: Admin/User
Precondition: The user/administrator successfully runs the application to view the home page
and browse different categories.
Post-condition: The user successfully selects a category to view items in a category.
Basic Flow:
Run the application
View the home page
Select a category
Browse through the items

Application: Bian
Use-Case Name: Add Item
Use-Case Description: This details the item-adding process for the system to access it. The
user should be able to add items to the cart and view information about the item.
Precondition: The items available for shopping are available for the user to browse.
Post-condition: The user successfully adds items to the cart.
Basic Flow:
View the home page
Select a category
Add item to the cart.
Application: Bian
Use-Case Name: View cart
Use-Case Description: This use case helps the user to view the shopping cart in the
application.
Precondition: None. The cart can be viewed with or without adding any items.
Post-condition: The user successfully adds the item to the shopping cart.
Basic Flow:
View the home page
Select a category
Add item to the cart.
View cart
Exceptional Flow:
Run the application
Select a category
Do not add items to the cart
View empty cart

Application: Bian
Use-Case Name: Continue shopping
Use-Case Description: This use case helps the user to decide whether he or she would like to
continue shopping after adding the item to the shopping cart or when he or she views the
empty cart.
Precondition: Continue shopping
Post-condition: The user is successfully able to view the shopping cart with the option to
continue shopping or to check out when there are items in the cart, or to continue shopping
when there are no items in the cart.
Basic Flow:
View the home page
Select a category
Add an item to the cart.
View cart
Continue shopping/check out
Exceptional Flow:
Run the application
Select a category
Do not add items to the cart
View empty cart
Continue shopping
Application:Bian
Use Case Name: Checkout
Use-Case Description: This use case helps the User/Admin to check out items from the
shopping cart.
Primary Actor: User/Admin
Precondition: There is at least one item in the shopping cart to cause the checkout button to
appear.
Post-condition: The user is able to click on the checkout button when there are items in the
cart.
Basic Flow:
Run the application
Add items to the cart
Go to the view-cart page
Click the checkout button
Go to the order-form page
Exceptional Flow:
Run the application
Do not add any item to the cart.
The checkout button is not available to click.

Application: Bian
Use-Case Name: Login
Use-Case Description: This use case helps the User/Admin to check out items in the shopping
cart by logging into the user-authentication form.
Precondition: There is at least one item in the shopping cart to check out the items and to
login to the user-authentication form.
Post-condition: The user is successfully able to log in.
Basic Flow:
Run the application
Enter the username and password.
Login/Register.
Exceptional Flow:
Run the application
Enter an incorrect username and password.
Login/Register fails.
Application: Bian
Use-Case Name: Place order
Use-Case Description: This use case helps the User/Admin to check out items in the shopping
cart using the order form.
Precondition: The user/administrator can login or register on the user-authentication form.
Post-condition: The user is successfully able to check out items using the order form.
Basic Flow:
Run the application
Login/Register.
Enter the information in the Order Form
Place order is success.
Exceptional Flow:
Run the application
Login/Register.
Enter the information on the order form
Invalid/Incomplete information
Place order is not allowed

Application: Bian
Use-Case Name: View database
Use-Case Description: This use case helps the administrator to view the items, the users
information, product details, and the checkout details in the database.
Primary Actor: Admin
Precondition: The administrator can connect the database controller when he or she first runs
the application.
Post-condition: The administrator is successfully able to view the database with the users
information as well as the product and checkout details.
Basic Flow:
Run the application
Connect to the database
View the users information.
DATA FLOW DIAGRAM
A Data Flow Diagram (DFD) is a structured analysis and design tool that can be used for
flowcharting. A DFD is a network that describes the flow of data and the processes that
change or transform the data throughout a system. This network is constructed by using a set
of symbols that do not imply any physical implementation. It has the purpose of clarifying
system requirements and identifying major transformations, So it is the starting point of the
design phase that functionally decomposes the requirements specifications down to the
lowest level of detail. DFD can be considered to an abstraction of the logic of an information-
oriented or a process-oriented system flow-chart. For the often referred to as logical data flow
diagrams.
EXTERNAL ENTITY
An external entity is a source or destination of a data flow. Only those entities which
originate or receive data are represented on a data flow diagram. The symbol used is a
rectangular box.
PROCESS
A process shows a transformation or manipulation of data flow within the system. The
symbol used is an oval shape.
DATAFLOW
The data flow shows the flow of information from a source to its destination. Data flow is
represented by a line, with arrowheads showing the direction of flow. Information always
flows to or from a process and may be written, verbal or electronic. Each data flow may be
referenced by the processes or data stores at its head and tail, or by a description of its
contents.
DATA STORE
A data store is a holding place for information within the system: It is represented by an open
ended narrow rectangle. Data stores may be long-term files such as sales ledgers, or may be
short-term accumulations: for example, batches of documents that are waiting to be
processed. Each data store should be given a reference followed by an arbitrary number.
LOGIN DFD:
REGISTRATION DFD
ADMIN DFD
MODERATOR DFD
Activity Diagram
This section lists the activity diagram and describes the flow of activities in the system. A
detailed description is then given after the figure for each activity. Figure 3 provides the
overview of the activity of application.
The figure below demonstrates the activity flow for this application. The flow of the
application is similar for both the user and administrator. The flow begins when the user first
runs the application home screen application that appears in the web browser. The user can
browse through the available list of categories and can choose either to select a category or to
directly view the cart. In the category, a user can select view more information for details
about an item before deciding to add it to the shopping cart by clicking on the cart icon next
to the item. The user can then decide to either continue shopping by clicking the continue
shopping button or can check out by clicking on the checkout option. If there are no items in
the cart, then the user does not have an option to click checkout. The user can check out after
doing the user authentication by logging in with the username and password. Once the user
successfully logins/registers, the order form, where the user can put the correct information to
place the order appears. If the user includes incorrect or incomplete information, then placing
the order is not allowed. After the user successfully inputs the correct information, placing
order is successful, and the user can see the success message. The additional flow step for the
administrators is that they can view the users information, the users checkout, and the
product details by using database after the user successfully places an order.
Figure--3
Activity Diagram

Main Design Project

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Main Design Project

Transféré par

Droits d'auteur :

Formats disponibles

SYSTEM DESIGN

INPUT AND OUTPUT DESIGN

Name Field Type Allow Null Default Primary key Extra

Name Field Type Allow Null Default Primary key Extra

Name Field Type Allow Null Default Primary key Extra

Name Field Type Allow Null Default Primary key Extra

Name Field Type Allow Null Default Primary key Extra

Id Int (100) No None Yes Auto

Name Field Type Allow Null Default Primary Extra

Name Field Type Allow Default Primary Extra

Name Field Type Allow Null Default Primary Extra

Name Field Type Allow Null Default Primary Extra

Name Field Type Allow Null Default Primary Extra

Name Field Type Allow Null Default Primary Extra

Name Field Type Allow Null Default Primary key

Name Field Type Allow Null Default Primary key

Name Field Type Allow Null Default Primary key

3. The application asks for user authentication before checking out.

High-Level Use Case Diagram

Use-Case Number: US-001

Use-case number: US-002

Use-Case Number: US-003

Use-Case Number: US-005

Use-Case Number: US-007

Use-Case Number: US-009

Vous aimerez peut-être aussi