CHAPTER FOUR

SYSTEM DESIGN AND IMPLEMENTATION

4.1 INTRODUCTION
System design is the process of designing the architecture, components, modules, interfaces and
data for a system to satisfy specified requirements. The basic goal of system design is to plan a
solution for the problem. This phase is composed of several systems. 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 and physical
design.
During logical design phase the inputs (sources) are described, outputs (destinations), databases
(data stores) and procedures (data flows) all in a format that meets the user requirements. The
user needs are also specified and at a level that virtually determines the information flow into and
out of the system and the data resources. Here the logical design is done through data flow
diagrams and database design.
The logical design is followed by physical design or coding. Physical design produces the
working system by defining the design specifications, which tell the programmers 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 through call and produce the
required report on a hard copy or display it on the screen.
4.2 SYSTEM SPECIFICATION
Specification is literally the discussion of a specific point or issue. A projects specifications
consist of the body of information that should guide the project developers, engineers and
designers through the work of creating the software given by the user of the software. Hence,
this work is aimed at designing and implementing an online auction system; detailed
specification and requirements of how the system should function will aid in developing the
system.

4.2.1 ARCHITECTURAL DESIGN


USER AGENTS AUCTION SERVER




Fig 4.1 System Architecture
Figure 4.1 shows the architecture of the online auction system. There are four sub-systems: The
access module is for processing incoming user agents. The backend system stores the necessary
information (e.g., user information). The administrative sub-system is for management purposes.
Finally, there are other supporting systems, such as payment gateways to handle payment
functions.
4.2.2 TYPES OF SPECIFICATION
There are different types of specification used in the development of the new system which is
listed below:
4.2.2.1 Main Menu Specification
The main menu is a link to other forms and subsystems in the system. It consists of the menus
and submenus that display another form on click event.

Access module
Backend system module
Administration module
Other module(s)
INTERNET

4.2.2.2 Input Specification
The input specification of this system specifies the data the user has to supply for the system to
work efficiently and generate accurate results. There are three major points of data input; input is
made while trying to register to enable the user has access to the application, input is also made
while trying to login into the system. Below are the major inputs to the system:
Table 4.1: Registration Form Input
USERNAME TEXTFIELD
EMAIL TEXTFIELD
PASSWORD TEXTFIELD
CONFIRM PASSWORD TEXTFIELD
SECURITY QUESTION LISTBOX
SECURITY ANSWER TEXTFIELD

This table shows the registration form for new user of the system
Table 4.2: Login Form Input
USER NAME TEXTFIELD
PASSWORD TEXTFIELD

4.2.2.3 Output Specification
The output specification displays result after the keyed data have been processed. This comprises
after the user must have register the information entered during registration will be stored in the
database for easy retrieval; the user can now login into the system via the username and
password entered during registration. The reports may not contain all the data that were keyed in,
but should contain only pertinent information that can be used to carry out proper analysis of
operations.
4.2.2.4 Database Specification
Database specification specifies the structure of the database(s) that will be used in the system.
The system comprises of two databases (AuctionSk.mdf and ASPNETDB.mdf). The AuctionSk
database contains six tables and the ASPNETDB.mdf contains eleven tables. Some of this tables
definition are listed below.
Table 4.3: Membership Table
S/NO FIELD NAME FIELD TYPE ALLOW NULLS
1 USERID UNIQUEIDENTIFIER FALSE
2 USERNAME NVARCHAR(128) FALSE
3 EMAIL NVARCHAR(256) FALSE
6 CREATEDATE DATETIME FALSE
7 PASSWORD NVARCHAR(128) FALSE
8 RETYPE PASSWORD NVARCHAR(128) FALSE
9 PASSWORDQUESTION NVARCHAR(256) TRUE
10 PASSWORANSWER NVARCHAR(128) TRUE

Table 4.3 above shows the information of registered membership table. The primary key in the
table is the UserID for it links the membership database table to other tables in the database
Table 4.4: Database User Table
S/NO FIELD NAME FIELD TYPE(SIZE) ALLOW NULLS
1 USERID UNIQUEIDENTIFIER FALSE
2 USERNAME NVARCHAR(256) FALSE
3 ISANONYMOUS BIT FALSE
4 MOBILEALIAS NVARCHAR(16) TRUE
5 LASTACTIVITYDATE DATETIME FALSE

This table (aspnet_Users) shows additional details of the user that can be viewed and accessed by
the administrator. For example, it shows the last activity date of the system user.
Table 4.5: Auction Table
S/NO FIELD NAME FIELD TYPE(SIZE) ALLOW NULLS
1 AUCTIONID INT FALSE
2 OWNERID UNIQUEIDENTIFIER FALSE
3 TITLE VARCHAR(50) FALSE
4 SUBTITLE VARCHAR(50) TRUE
5 DESCRIPTION NTEXT FALSE
6 STARTINGPRICE MONEY FALSE
7 RESERVEAMOUNT MONEY FALSE
8 CONDITION VARCHAR(100) FALSE
9 STARTINGDATE DATETIME TRUE
10 CATEGORYID INT FALSE

The above table describes the details of an online item to be auctioned to be stored in the
database. The AuctionID column stores the Id for the item to be auctioned. It is the primary key
of the table while the CategoryID and OwnerID are foreign keys that links the table to other
tables in the database.
Table 4.5: Bid Table
S/NO FIELD NAME FIELD TYPE(SIZE) ALLOW NULLS
1 BIDID INT FALSE
2 AUCTIONID INT FALSE
3 OWNERID UNIQUEIDENTIFIER FALSE
4 BIDAMOUNT MONEY FALSE

The bid table of the ASPNETDB.mdf defines the elements of the bidding information. The bidID
is the primary key of thr table while auctionID, ownerID are the foreign keys.


Table 4.6 Category Table
S/NO FIELD NAME FIELD TYPE(SIZE) ALLOW NULLS
1 CATEGORYID INT FALSE
2 NAME VARCHAR(50) FALSE
3 DESCRIPTION VARCHAR(300) FALSE

Table 4.6 of the ASPNETDB.mdf database defines the items category. The categoryID column is
the primary key of this table.
Table 4.7: Feedback Table
S/NO FIELD NAME FIELD TYPE(SIZE) ALLOW NULLS
1 FEEDBACKID INT FALSE
2 OWNERID UNIQUEIDENTIFIER FALSE
3 SENDERID UNIQUEIDENTIFIER FALSE
4 AUCTIONID INT FALSE
5 COMMENT VARCHAR(300) FALSE
6 SCORE INT FALSE

The Feedback table of the ASPNETDB.mdf database helps to store the information that serves as
interaction between the user and the system administrator. The Primary key is the FeedbackID
while the OwnerID, SenderID and AuctionID are foreign keys that link the Feedback table to the
Owner table, sender table and auction table respectively.
Table 4.8: Images table
S/NO FIELD NAME FIELD TYPE(SIZE) ALLOW NULLS
1 IMAGEID INT FALSE
2 AUCTIONID INT FALSE
3 IMAGE IMAGE FALSE

Theimage table of the ASPNETDB.mdf database stores the corresponding images for the items
to be auctioned. The imageID is the primary key while the auctionID is the foreign key.
4.2.3 USER INTERFACE DESIGN
The interface design describes how the software communicates within itself, with systems that
inter operate with it and with humans who. The component -level design transforms structural
elements of the software architecture into a procedural description of software components.
Computer software is considerably more complex than a house; hence we need a blue print-like
design. It is the place where quality is important in software engineering. Design is the only way
that can accurately translate a customer's requirements into a finished software produce or
system. Without design, we risk building an unstable system-one that will fail when small
changes are made: one that may be difficult to test: one whose quality cannot be assessed until
late in the software process.

4.4 DESIGN TOOLS
The essence of design tools is to enable rapid application development thereby increasing
productivity. Most of the framework communities and vendors provide some kind of integrated
development environment plug-in technology-based tools to help in development. However,
usually this plug-in support is limited to one or two IDE at most. Some of the tools worth
looking at when building an application such as the one in focus are spelt out below:
(i) Testing tool: In other to test the status of the application especially the web pages,
different web browsers such as Opera, Internet Explorer 9.0, Google Chrome and Mozilla
Firefox for portability.
(ii) Database server: For proper incorporation with ASP.Net webpages and adequate data
storage, I used the Microsoft SQL Server 2008.
(iii) IDE: The choice of integrated development environment is Visual Studio for web (Visual
Web Developer 2010) which aid in the rapid development of ASP.Net web forms.
(iv) Web development tools: In other to develop the web pages, I use Visual Web
Developer, Photo Paint for image editing, cascading style sheet, JavaScript in other to validate
the text field and the AJAX toolkit in other to create flicker-free webpages.
(v) UML modelling tool: The tool use in the modelling is Microsoft word 2007 for creation
of scenario specification, use case diagrams, class diagrams and data flow diagram.
(vi) UNIFIED MODELING LANGUAGE (UML) / SYSTEM MODEL
The UML includes a set of graphic notation techniques to create visual models of software-
intensive systems. The Unified Modelling Language (UML) is used to specify, visualize, modify,
construct and document the artefacts of an object-oriented software-intensive system under
development. The UML shows actors and use case diagram. Fig 4.4.0 displays the UML diagram
of user interacting with the system. Fig 4.4.1 displays the scenario-based specification of the
system, Fig 4.4.2 displays the UML diagram of the user interaction with the system while Fig
4.4.3 shows the overall interaction between the administrator and the student in the system.
Scenario-based Specification: Scenario-based specifications allow an intuitive way of
visualizing, understanding and analyzing the system design requirements.












Entrance
Negotiation
Room
Auctioneer Register
Goods
Select
Goods
Auction
Processing
Bidder
History of
Auction
Selecting
Bidder

Chatting
View/Update
End of auction


Fig 4.4.1: Scenario Auction Process













Fig 4.4.2: Purchasers Use Case Diagram
Figure 4.4.2 is the Use Case Diagram that represents the Purchasers behavior. It defines the
behavior of the purchaser while participating in an auction after login.


Login
Select method of bidding
View History
Validate User
Buy Goods Chatting
Bidder/Purchaser

















Fig 4.4.3: Use Case Diagram of Auction System
Figure 4.43 is the Use Case Diagram for the actions that the Users (Seller, Purchaser) can
perform in an auction. Users, after Login, can select the method of auction (auction, reverse
Auctioneer
Bidder
Login
Select auction method
Select Method of bidding
Chattin
Buy Goods
Register for Goods
Logout
Select History of database
auction) and the method of bidding (Speed, Medium and Leisure). They can also express
opinions about products or exchange information about products.