COLLEGE OF ENGINEERING AND TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE

PROJECT TITLE: WEB-BASED ONLINE AUCTION SYSTEM

 COLLEGE OF ENGINEERING AND TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE

PROJECT TITLE: WEB-BASED ONLINE AUCTION SYSTEM

GROUP MEMBERS ID NUMBER SIGNATURE

1. Abel Solomon AKU1106350

2. Abdella Buni AKU1202532

3. Mastewal Fikadu AKU1106345

4. Natnael Kenito AKU1201743

5. Tezerawork Bekele AKU1202172

6. Yohannes Mesfin AKU1202413

A group project
Submitted to the department of computer science, college of Engineering and
Technology, Bonga University, in meeting the preliminary project requirement
for partial fulfillment of the award of Bachelor of Science Degree in Computer
Science.
Bonga, Ethiopia
2023

I
 Approval Sheet
This group project entitled “Web-based auction system” has been read and approved as
meeting the preliminary project requirements of the department of Computer Science in
partial fulfillment for the award of Bachelor of Science degree in Computer Science,
Bonga University, Bonga, Ethiopia

Approved By

Name of Advisor: ___________________________ Signature: ____________ Date: _____________

Name of Project Coordinator: __________________________Signature: ________Date: ________

II
 Acknowledgment
Goes here….

III
 Table of Content
Acknowledgment................................................................................................................................III
List Of Figures....................................................................................................................................VI
List Of Tables......................................................................................................................................VII
Acronyms............................................................................................................................................IX
Abstract................................................................................................................................................X
CHAPTER ONE..................................................................................................................................1
INTRODUCTION...............................................................................................................................1
1.1 Background of the project......................................................................................................1
1.2 Problem Statement.................................................................................................................2
1.3 Justification............................................................................................................................2
1.4 Objective of Project.....................................................................................................................2
1.4.1 General Objective.................................................................................................................2
1.4.2 Specific Objective.................................................................................................................2
1.5 Scope and Limitation of the Project.............................................................................................3
1.5.1 Scope of the Project..............................................................................................................3
1.5.2 Limitation of the Project.......................................................................................................3
1.6 System Development Methodology.............................................................................................3
1.6.1 System Development Process Model....................................................................................3
1.6.2 System Development Approach............................................................................................3
1.7 System Development Tools.........................................................................................................4
1.8 Beneficiary of the Project............................................................................................................4
1.9 Feasibility Study..........................................................................................................................4
1.9.1 Economic Feasibility............................................................................................................4
1.9.2 Technical Feasibility.............................................................................................................5
1.9.3 Operational Feasibility..........................................................................................................5
1.9.4 Legal Feasibility...................................................................................................................5
1.9.5 Schedule Feasibility..............................................................................................................5
1.10.1 Work Breakdown Structure................................................................................................6
1.10.2 Gantt Chart Representation // Not done yet........................................................................6
1.11 Project Budget.......................................................................................................................6
CHAPTER TWO.................................................................................................................................8
REQUIREMENT ENGINEERING...................................................................................................8
2.1 Requirement Elicitation...............................................................................................................8
2.1.1 Overview of Current System.................................................................................................8

IV
 2.1.2 Problem of Current System...................................................................................................8
2.2 Requirement Gathering................................................................................................................9
2.2.1 Data Gathering Methodology................................................................................................9
2.3 Overview of the Proposed System...............................................................................................9
2.4 Requirement of the Proposed System..........................................................................................9
2.4.1 Functional Requirements......................................................................................................9
2.4.2 Non-Functional Requirements............................................................................................10
CHAPTER THREE...........................................................................................................................11
SYSTEM MODELLING...................................................................................................................11
3.1 Scenario.....................................................................................................................................11
3.1.1 Use Case Model..................................................................................................................11
3.1.2 Use Case Diagram..................................................................................................................11
3.2.4 Identifying Relationships among Actors and Use Cases.....................................................12
3.2.5 System Use Case Diagram..................................................................................................14
3.2.6 Description Of Use Case Model.........................................................................................15
3.2.6 Interaction Diagram................................................................................................................30
3.2.6.1 Sequence Diagram...........................................................................................................30
3.2.6.2 State Chart Diagram (State Machine Diagram)................................................................31
CHAPTER FOUR.............................................................................................................................32
SYSTEM DESIGN............................................................................................................................32
4.1 System Design Overview of The System...................................................................................32
4.2 Current Software Architecture...................................................................................................32
4.3 Proposed Software Architecture................................................................................................32
4.4 System Decomposition..............................................................................................................32
4.4.1 Component Diagram...........................................................................................................32
4.5 Package Diagram...................................................................................................................33
4.6 Hardware/Software Mapping.....................................................................................................34
4.6.1 Deployment Diagram..........................................................................................................34
4.7 Persistent Data Modelling..........................................................................................................35
4.7.1 Persistent Data Management Diagram................................................................................35
4.8 Access Control and Security......................................................................................................36
4.9 Detailed Class Diagram.............................................................................................................37
Conclusion and Recommendation.......................................................................................................38
Conclusion.......................................................................................................................................38
Recommendation.............................................................................................................................38
References.......................................................................................................................................39

V
 List Of Figures
Figure 1.1 Work break down.........................................................................................................6

Figure 1.2 Gantt chart....................................................................................................................6

Figure 3.1 Use case diagram........................................................................................................14

Figure 3.2 Bidding sequence diagram..........................................................................................30

Figure 3.3 State chat diagram......................................................................................................31

Figure 3.4 Activity diagram..........................................................................................................31

Figure 4.1 Component diagram...................................................................................................32

Figure 4.2 Package Diagram.........................................................................................................33

Figure 4.3 Deployment diagram..................................................................................................34

Figure 4.4 Persistent data management diagram........................................................................35

Figure 4.5 Detailed class diagram................................................................................................37

VI
 List Of Tables
Table1.1 Project Budget Estimates................................................................................................7

Table 3.1 Relationship between actors and use cases..................................................................13

Table 3.2 System use case description for Add categories...........................................................15

Table 3.3 System use case description for Bid on product...........................................................16

Table 3.4 System use case description for Edit profile................................................................17

Table 3.5 System use case description for Give feedback............................................................18

Table 3.6 System use case description for ID verification...........................................................19

Table 3.7 System use case description for Login.........................................................................20

Table 3.8 System use case description for Manage database.......................................................21

Table 3.9 System use case description for Product detail............................................................22

Table 3.10 System use case description for Product verification.................................................23

Table 3.11 System use case description for Request categories...................................................24

Table 3.12 System use case description for Report fraud product...............................................25

Table 3.13 System use case description for Report generation....................................................26

Table 3.14 System use case description for Upload product........................................................27

Table 3.15 System use case description for View bid information..............................................28

Table 3.16 System use case description for View feedback.........................................................29

Table 4.1 Access control and security..........................................................................................36

VII
 Acronyms

 Here it goes….

VIII
 Abstract

Goes here…..

IX
 CHAPTER ONE

INTRODUCTION
1.1 Background of the project
The usage of the online auction system makes use of the decision-making aid tool, which
increases the buyer's confidence in their selection of the seller and goods. Specifically, the
product information signals, seller rating scores, and seller shilling actions make up the three
components of the decision-assistance tool. Through the use of language and images, third-
party product certifications, descriptions of the product's attributes, the product's usage, and
its book value, the product information signals aim to completely define the product. By
using the feedback scores, the decision-making aid tool also offers seller ratings. These
evaluations of the online auction goods sellers are provided by prior successful bidders.
These bidders provide in-depth seller reviews of every element of the seller, scoring factors
such as how accurate the item description was, how happy they were with the seller's
communication, and how promptly the seller delivered the goods to them. The other
important aspect of the decision-making tool involves the process of coming up with seller’s
shill ratings. Shilling is the act of introducing fake bids into an auction on the behalf of the
seller to artificially inflate the price of an item (Weinberg, 2003). To come up with shill
rating the system monitors the shill activity characteristics which include those bidders who
make a lot of repeated failed bids on the same seller. This information is used to come up
with a shill score. Detailed evaluation of the product and seller and the use of the decision-
making assistance tool ensures consumer’s certainty on the choice of the sellers and the
products that they make.

1
 1.2 Problem Statement
People are always on the go to their renown product supplier, or nearby market center or at
times a local hawker, who goes on to supply items and at times when he cannot get the item
the buyer wants, mostly they give their hands to get them items and at times they mess and
bring fake and quarks deliver stolen and bad items. This is because unqualified people offer
delivery of items to customers. Due to the disparity of the buyers, cone-men have always
taken the advantage to offer item delivery to the customers. On the other hand, we have
suppliers and business people who are qualified to supply and sell the items yet they have
very few people who can come to them, more so in the same locality.

1.3 Justification
The use of online public sale structures that don't permit for complete powerful product
description and failure to offer choice making help equipment to online bidders’
consequences in improved product and dealers’ uncertainty. The buyer’s uncertainty in the
direction of product and vendor makes it hard for the shoppers to distinguish among the
coolest and awful dealers, the dearth of differentiation might also additionally pressure better
first-class dealers to go away the marketplace in view that their first-class merchandise does
now no longer sign and praise with truthful fees as a result lowering transaction activity
(Dimoka, 2008). A hit implementation of this mission consequences in an internet public sale
machine that permits assessment of the product this is a way plenty powerful and that come
near or identical the bodily assessment of the product.

1.4 Objective of Project

1.4.1 General Objective
 The general objective of the project is to develop a web-based online auction system

1.4.2 Specific Objective

In order to attain the above general objective, the following activities will be carried out.
These include:

 Gathering requirements: We will ask users of currently available market system

about the features that these systems lack. By collecting those we will include
them as a requirement for this new system.
 Review of related works: We will review existing system by ourselves and try to
come up with viable solution to the qualities and features these systems have.

2
  Analysis: We will examine our requirements and decide in what technologies
and in what things the system should be done.
 Propose design: We will describe every subsystem that exists in the system, it’s
persistent data management, detailed class description and others
 Implement the proposed project: We implement the e-commerce system based
on the proposed system design
 Test and evaluate the developed system: We will release the trial version of it
and the users can give our contact address so the users give us feedbacks and
release better versions of it.

1.5 Scope and Limitation of the Project

1.5.1 Scope of the Project
1.5.1.1 Geographical scope

The project is designed for Ethiopian market only.

1.5.1.2 Functional Scope

This project supposed to do the following points

 Create an online forum where bidder auction for items posted by the seller through the online
system
 Create a panel where by a seller receives requests from a buyer and sends back feedback, an
answer to a question or requests to meet the bidder

1.5.2 Limitation of the Project

Here it goes….

1.6 System Development Methodology

1.6.1 System Development Process Model
The development method that we used is Iterative and Incremental (Agile) software
development process model. We selected agile method because

 Enables better division of task to separate unit

 It offers a reliable and verified method for system development
 It improves the motivation of team members since the task is divided

1.6.2 System Development Approach

We used the object-oriented approach in order to develop of our system because

 It enables us to represent complex relations among different objects

 Represent data and process with consistent notation throughout the system.
 High code reusability
 Real world modelling
 It is easier to maintain

3
 1.7 System Development Tools

 Hardware Tools:
 Computer- To do different tasks

Processor: Intel (R) Core (TM) i7-8700 CPU @ 3.20GHz 3.19GHz

RAM: 8GB

 Flash disk (32GB)- To move the documentation easily and to store the project in
another medium since the data in the computer can be lost by different reasons
 Mobile- To reach to the team members and to search for items from the internet
 Software Tools:
 Window OS (Window 11 is used for the documentation of this project)
 Microsoft Office Word 2021- To write the document
 EdrawMax and Wondershare EdrawMax- To design and model different diagrams
 Adobe Photoshop cc 2017- To crop exported tiff image formats
 Special resource
 No special resource is used for this documentation

1.8 Beneficiary of the Project

Sellers:

 Their products will not be specific to one location rather to nation wide
 They will save different
 ……

Bidders:

 They will see a wide variety of products in the country from their places
 They will save transportation and other costs
 They will

Government:

 It becomes easy to monitor the market price used in the market

 It helps to reduce corruption
 It helps

1.9 Feasibility Study

1.9.1 Economic Feasibility
1.9.1.1 Tangible

 Reduction of different kinds of cost

 Keep the bidders from shilling activities
 Increase speed of activity

4
 1.9.1.2 Intangible

 Saves the resource of the country

 The knowledge that we experience while preparing the documentation
 Keep the bidders safe from different kinds of transmittable disease

1.9.2 Technical Feasibility

The main consideration is to be given to the study of available resources of the organization
where the software is to be implemented. The system analyst evaluates the technical merits of
the system giving emphasis on the performance, reliability, maintainability and productivity.
By taking the consideration before developing the proposed system, the resources availability
of the group was studied and it’s feasible to make the project using JavaScript and Bootstrap
in frontend and PHP at the backend.

1.9.3 Operational Feasibility

An estimate should be made to determine how much effort and care will go into developing
of the system including the training to be given to the user. Usually, people are reluctant to
changes that come in their progression. The computer initiation will certainly affect the turn
over, transfer and employee job status. Hence an additional effort is to be made to train and
educate the users on the new way of the system.

1.9.4 Legal Feasibility

This assessment refers to the potential legal and contractual ramification that could
materialize during and after the construction for the system. The project will be constructed
with in the internal policies and regulation of any standard organization and government laws
in the mind.

1.9.5 Schedule Feasibility

A project will fail if it takes too long to be completed before it is useful. Time feasibility is a
measure of how reasonable the project is completed within the given time. By estimating the
given time to each of the activities we will try to complete the project on time. Therefore, our
project is timely feasible.

Once the schedule activities are defined, they are sequenced in the order in which they must
be performed. The resource requirements and the activity durations are then estimated for
these activities. Finally, the project schedule is created which shows when each activity is
scheduled to begin and end. The project schedule also shows the planned start date and
planned finish date for the overall project.

5
Scheduling is used to perform the works in appropriate time that helps to reach the goal
effectively and efficiently.

1.10.1 Work Breakdown Structure

Figure 1.1 Work break down

1.10.2 Gantt Chart Representation // Not done yet

Figure 1.2 Gantt chart

1.11 Project Budget

The following table is the list budget estimates required for the successful development of the
proposed system.

6
 Types of Tool name Quantity Unit price (in Birr) Total
costs price (in
Birr)
Desktop 1 Free Free
Personal 1 25,000 25,000
Hardware Computer
costs Flash (32 GB) 2 1 350
Pen 1 15 15
Mobile phone 3 7000 21,000
Paper 60 0.25 15
Printing - - -
Notebook 2 50 100
EdrawMax
and 1 Free Free
Wondershare
EdrawMax
Microsoft 1 Free Free
Office 2021
Software Adobe
cost
photoshop cc 1 Free Free
2017
Window 10 1 Free Free
Pro
Window 11 1 free Free
Pro
Total cost == 46,480
Table1.1 Project Budget Estimates

7
 CHAPTER TWO

REQUIREMENT ENGINEERING
2.1 Requirement Elicitation
2.1.1 Overview of Current System
Prior to every public sale, the day of public sale, the venue and the objects on public sale are
introduced via a few multimedia platforms both newspaper, social media or different
methods. Those who want to participate within side the public sale must arrive on the venue
on that day on time. This traditional technique maximum of the instances save you involved
bidders from collaborating within side the bidding manner. Another method of the
contemporary machine is to tune every bidding manner and to make it terminate in monetary
settlement. The manner may be very cumbersome and time consuming. There is likewise
machine this is on-line like Ubid.com, Quibids.com many extra however their most important
flaws are they can’t manipulate shilling sports. Shill bidding is the act of introducing faux
bids into a public sale on behalf of the bidder to artificially inflate the fee of an item.

2.1.2 Problem of Current System

There are several problems in the current manual system that includes:

 Ease of access

The current system is very hard to understand as the price is increasing and to keep track
of that information is not

 Accountability

The current system is open to corruption especially if the auction type is first-price
sealed-bid or closed auction system since the seller and may be some third-party body
knows the bidder price.

 Environmental

The current system uses lots of paper just for one product in the auction process and this
led our world to global warming.

 Availability

As I have stated it in the overview because the system is manual reaching to multiple
users is the main drawback of the system. For example, if the seller lives in Bonga there
is no way that the bidder knows there is an auction if he lives in Aksum.

 Reliable user validation and checking

The major problem of the current online system is that there is no checking for shilling
activities and also product and description checking mechanism and also user validation

8
2.2 Requirement Gathering
2.2.1 Data Gathering Methodology
We used the following data gathering methodologies to document this project. This are:

 Observing: Using this methodology, we have seen some documents on online auction
system sand also we have seen some online auction systems how they work and what
their flaws are.
 Discussing and analyzing problems with team members

2.3 Overview of the Proposed System

The proposed system is a system in which allows the users to use the system anywhere,
anytime and anyone if they are registered to the system. The proposed system makes the
auction system simple the only pre-condition for using the system is that the user must
register and authenticate before he/she can take part in the bidding process. The system uses
HTTP forms authentication which creates a session cookie for any signed in user the span of
the session the cookie remains valid until the user logs out.

There are different modules in the proposed system. These are:

1. Product registration module: under this module the seller posts the product with their
price tag and date for the auction to expire. The proposed system will accept the
product description and photo of the product if the product description doesn’t match
the photo the product will be remove
2. Bidding module: under this module the bidder bid for a specific product and can view
the description of the product
3. Web administration module: under this module the administrator manages the
database and the user can add categories etc.
4. Photo verifier module: under this module someone or the system used to identify the
user photo and ID card photo and also the product photo with the description
5. This is not a user view module rather system module that removes the products that
the date submitted passed or the bidding process is completed

2.4 Requirement of the Proposed System

2.4.1 Functional Requirements
Functional requirements describe the interactions between the system and its environment
independent of its implementation. The environment includes the user and any other external
system with which the system.

Functional requirements capture the intended behaviors of the system. These behaviors may
be expressed as services, tasks or functions. It is a requirement that will allow users to
perform some kind of functions and enable them to interact with the system.

The major functions are:

 Here it goes….

9
2.4.2 Non-Functional Requirements
Non-functional requirement explains and describes the user visible aspects of the system.
Constraints on the services or functions offered by the system are constraints of timing, the
development process; standards, etc. are things we have to focus on developing new systems
to achieve its functionality.

Non-functional requirement are requirements which specify criteria that can be used to judge
the operation of the system.

2.4.2.1 Maintainability

Due to the development approach used and the process model used the system allow even the
slenderest alteration.

2.4.2.2 Reliability

The system can give its service as long as there is electricity, computer and the user

2.4.3.3 Environment

The system does not harm the environment hence it is environmentally friendly

2.4.3.4 Security

All users have their own user’s name and password which is required to log into the system
and each user has privilege on what they can perform using the system.

2.4.3.5 Interoperability

It can interact with other software or hardware systems

2.4.3.6 Scalability

It can cope the increasing number of users without reducing the quality it offers

2.4.3.7 Availability

The system is available 24 hours a day and 7 days in a week

2.4.3.8 Usability

The system can be learned easily by the users to operate.

2.4.3.9 Performance

Here it goes….

10
 CHAPTER THREE

SYSTEM MODELLING
3.1 Scenario
A scenario is a formal description of flow of events that occur during the execution of a use
case instance. It defines the specific sequence of events between the system and the external
actors. It is normally described in text and corresponds to the textual representation of the
sequence diagram.[1] =wwwsparxsystems.com/resources/tutorials/uml2/use-case-diagram

3.1.1 Use Case Model

A use case model is one of the unified modelling languages that indicate an interaction
between a system and external actors (users or other systems). It captures the goal of the
users and responsibility of the system to its users. It is the functionality of the system or the
service provided by the new system. The main purpose of a use case model is to show that
what system functions are performed for which actor. Use case models and sequence
diagrams present interaction at different levels of detail and so may be used together. Use
case modelling is widely used to support requirement elicitation. A use case can be taken as a
simple scenario that describes what user expects from a system.

Each use case represents a discrete task that involves external interaction with a system. In its
simplest form, a use case is shown as an ellipse with the actors involved in the use case
represented as stick figures.

3.1.2 Use Case Diagram

A use case diagram is used to represent the dynamic behavior of a system. It encapsulates the
system’s functionality by incorporating use cases, actors and their relationships.

It models the task, services and functions required by a system/ subsystem of an application.

It depicts the high-level functionality of a system and also tells how the user handles the
system [1]

A use case diagram is usually simple. It does not show the detail of the use cases:[2]

 It only summarizes some of the relationships between use cases, actors and systems.
 It does not show the order in which steps are performed to achieve the goals of each
use case

The use cases are represented by either circle or eclipses.

11
An actor represents a type of users of the system or external system that plays a role in one or
more interactions with our system. Our system comprises the following actors

 Seller
 Bidder
 System Administrator
 Validator

A use case is a written description of how users will perform tasks on your website. It
outlines, from a user’s point of view, a system’s behavior as it responds to the request. Each
use case is represented as a sequence of simple steps, beginning with a user’s goal and ending
when that goal is fulfilled.[3]

Our system has 15 identified use cases. Which are:

1. Add categories (UC01)

2. Bid on product (UC02)
3. Edit profile (UC03)
4. Give feedback (UC04)
5. ID verification (UC05)
6. Login (UC06)
7. Manage database (UC07)
8. Product detail (UC08)
9. Product verification (UC09)
10. Request categories (UC10)
11. Report fraud products (UC11)
12. Report generation (UC12)
13. Upload product (UC13)
14. View bid information (UC14)
15. View feedback (UC15)

12
 Numbe Actors Use cases
r

1. Seller  Edit profile

 Give feedback
 Login
 Logout
 Request categories
 Upload product
 View bid information

2 Bidder  Bid on product

 Edit profile
 Give feedback
 Login
 Logout
 Product detail
 View product detail

3 System Administrator  Add categories

 Edit profile
 Login
 Logout
 Report generation
 View feedback

4 Validator  ID card verification

 Login
 Logout
 Product verification

Table 3.1 Relationship between actors and use cases

13
Figure 3.1 Use case diagram

14
3.1.3 Description of Use Case Model
Use case name Add categories

Use case number UC 01

Actor System Administrator

Description Allows the system admin to enter the categories in which the
product belongs

Precondition Successful login as admin

Basic flow of events User action System response

1. Actor clicks the login button 2.The System displays

login window
3. User fills his/her user’s name
and password 4. System authenticates
the user input
5. User authenticates and gets
access to the system 7. System displays form
to be filled
6.Actor clicks add categories
8. System checks the
9. Use case terminates form

Alternative flow of events The entered filled is not correct please enter correct value
alert will show up and reload to the same page

Post condition Successful addition of categories

Table 3.2 System use case description for Add categories

Use case name Bid on product

15
 Use case number UC 02

Actor Bidders

Description The actor bidding on the product uploaded by the seller.

It includes modify bid option if the bidder wants to update

the given price

Precondition Login as bidder

Basic flow of events User action System response

1. Admin clicks the login button 2.The System displays

login window
3. User fills his/her user’s name
and password 4. System authenticates
the user input
5. User authenticates and gets
access to the system 7. System displays
bidding form to be filled
6.Actor clicks bid button
8. System checks the
9. Use case terminates form

Alternative flow of events Invalid character is inserted or less amount of bid is inserted
pop-up will be displayed

Post condition Successful update on the bidding price of the product

Table 3.3 System use case description for Bid on product

Use case name Edit profile

Use case number UC 03

16
 Actor Seller, Bidder and System administrator

Description Allows the actors to edit or update their profile

Precondition Successful login

Basic flow of events User action System response

1. Actor clicks the login button 2.The System displays

login window
3. Actor fills his/her user’s name
and password 4. System authenticates
the actor input
5. Actor authorized and gets
access to the system 7. System displays the
actor profile which can
6. Actor clicks Edit profile link be edited

9. Use case terminates 8. System checks the

edited profile

Alternative flow of events The profile is not edited pop up will display and return to the
page

Post condition Successful update of the profile

Table 3.4 System use case description for Edit profile

Use case name Give feedback

17
 Use case number UC 04

Actor Seller, bidder

Description The actors will give feedback on the system so that it

will function better

Precondition Successful login

Basic flow of events User action System response

1. Actor clicks the login button 2.The System displays

login window
3. Actor fills his/her user’s name
and password 4. System authenticates
the actor input
5. Actor authorized and gets
access to the system 7. System displays text
field in order to be
6. Actor clicks give feedback link submitted by the actor

8. Use case terminates

Alternative flow of events N/A

Post condition Successful delivery of feedback

Table 3.5 System use case description for Give feedback

18
 Use case name ID verification

Use case number UC 05

Actor Validator

Description The actor will validate the ID card submitted from sellers and
bidders

Based on this function the validator manages the user

Precondition Login as validator

Basic flow of events User action System response

1. Admin clicks the login button 2.The System displays

login window
3. User fills his/her user’s name
and password 4. System authenticates
the user input
5. User authenticates and gets
access to the system 7. System displays
pending accounts with
6.Actor clicks pending account their submitted photos
authorization page

8. Use case terminates

Alternative flow of events N/A

Post condition Account is authorized to access the system

Table 3.6 System use case description for ID verification

19
 Use case name Login

Use case number UC 06

Actor Seller, Bidder, System administrator and validator

Description Authentication to the system

Precondition Successful registration to the system

Basic flow of events User action System response

1. Admin clicks the login button 2.The System displays

login window
3. User fills his/her user’s name
and password 4. System authenticates
the user input
5. User authenticates and gets
access to the system respective to
their roles

6. Use case terminates

Alternative flow of events Either not registered or wrong password is inserted pop-up
will display and reload to the page

Post condition System authenticate and authorize based on their role

Table 3.7 System use case description for Login

Use case name Manage database

20
 Use case number UC 07

Actor System administrator

Description Allow the actor to manage the database if any flaw

has been detected

Precondition Successful login as system admin

Basic flow of events User action System response

1. Actor clicks the login button 2.The System displays

login window
3. Actor fills his/her user’s name
and password 4. System authenticates
the user input
5. Actor authenticates and gets
access to the system 7. System displays
database
6.Actor gives the link
localhost/phpMyAdmin page

8. Use case terminates

Alternative flow of events You are not connected error will be displayed

Post condition Database is updated

Table 3.8 System use case description for Manage database

Use case name Product detail

21
 Use case number UC 08

Actor Bidder

Description The actor gets the detail that the he selected which is
uploaded by the seller

Precondition The availability of the product

Basic flow of events User action System response

1. Actor clicks the login button 2.The System displays

login window
3. Actor fills his/her user’s name
and password 4. System authenticates
the user input
5. Actor authenticates and gets
access to the system 7. System gives product
description
6.Actor clicks the product which
he likes to bid

8. Use case terminates

Alternative flow of events N/A

Post condition N/A

Table 3.9 System use case description for Product detail

22
 Use case name Product verification

Use case number UC 09

Actor Validator

Description The actor validates the product description and its

photo
Due to this feature managing the product function is
the function of the actor

Precondition Report made by the bidder

Basic flow of events User action System response

1. Actor clicks the login button 2.The System displays

login window
3. Actor fills his/her user’s name
and password 4. System authenticates
the user input
5. Actor authenticates and gets
access to the system 7. System displays
product lists and their
6.Actor clicks product photos which are
verification link reported by bidders

9. Use case terminates 8. System give either

approve or amend option

Alternative flow of events N/A

Post condition The final decision sent to the System administrator

Table 3.10 System use case description for Product verification

23
 Use case name Request categories

Use case number UC 010

Actor Seller

Description The actor requests the system administrator to add the

required category

Precondition Login as seller

Basic flow of events User action System response

1. Actor clicks the login button 2.The System displays

login window
3. Actor fills his/her user’s name
and password 4. System authenticates
the user input
5. Actor authenticates and gets
access to the system 7. System displays text
box in which the actor
6.Actor clicks request categories writes to the system
link administrator

8. Use case terminates

Alternative flow of events N/A

Post condition Request sent to the system administrator

Table 3.11 System use case description for Request categories

24
 Use case name Report fraud products

Use case number UC 011

Actor Bidder

Description The actor reports products that are either mismatched with
their photo and description or not in category product

Precondition The availability of the product

Basic flow of events User action System response

1. Actor clicks the login button 2.The System displays

login window
3. Actor fills his/her user’s name
and password 4. System authenticates
the user input
5. Actor authenticates and gets
access to the system 7. System gives hybrid
question to get the report
6.Actor clicks report button type
under the product description

8. Use case terminates

Alternative flow of events N/A

Post condition The request sent to the validator

Table 3.12 System use case description for Report fraud product

25
 Use case name Report generation

Use case number UC 012

Actor System administrator

Description When the actor clicks that link the report is generated in
either graphical or in words

Precondition Successful login as system administrator

Basic flow of events User action System response

1. Actor clicks the login button 2.The System displays

login window
3. Actor fills his/her user’s name
and password 4. System authenticates
the user input
5. Actor authenticates and gets
access to the system 7. System displays
different kind of reports
6.Actor clicks report generation
link

8. Use case terminates

Alternative flow of events N/A

Post condition Report is generated

Table 3.13 System use case description for Report generation

26
 Use case name Upload product

Use case number UC 013

Actor Seller

Description The actor uploads the product that is going to be bided by the
bidders.

It includes the product description with the photo of it

It includes initializing the price and the time to halt the

auction

It includes choosing the method of bidding

Precondition Successful login and press the upload button

Basic flow of events User action System response

1. Actor clicks the login button 2.The System displays

login window
3. Actor fills his/her user’s name
and password 4. System authenticates
the actor input
5. Actor authorized and gets
access to the system 7. System displays the
upload page that contains
6. Actor clicks the upload button forms to be filled by the
actor
9. Use case terminates
8. System checks the
filled form

Alternative flow of events The filled form has flaw please check it error will appear and
reload to the page

Post condition The product is saved in the database and shown to different
bidders

Table 3.14 System use case description for Upload product

27
 Use case name View bid information

Use case number UC 014

Actor Seller, Bidder

Description For the seller it shows the history of bidding for the product
that he has posted

For the bidder it shows the bidding step for the product that
they have been participated

It also notifies the winner of the auction using notification

Precondition Uploading the product and the bidding of the product

Basic flow of events User action System response

1. Actor clicks the login button 2.The System displays

login window
3. Actor fills his/her user’s name
and password 4. System authenticates
the actor input
5. Actor authorized and gets
access to the system 7. System displays the
actor profile which can
6. Actor clicks Edit profile link be edited

9. Use case terminates 8. System checks the

edited profile

Alternative flow of events N/A

Post condition Successful logout from the system

Table 3.15 System use case description for View bid information

28
 Use case name View feedback

Use case number UC 015

Actor Seller, Bidder

Description It allows the actors to give their opinion in order to

make the system better

Precondition Login as seller or Bidder

Basic flow of events User action System response

1. Actor clicks the login button 2.The System displays

login window
3. Actor fills his/her user’s name
and password 4. System authenticates
the user input
5. Actor authenticates and gets
access to the system 7. System displays
hybrid question that tries
6.Actor clicks give feedback link to catch the user idea

8. Use case terminates

Alternative flow of events N/A

Post condition Feedback is submitted to System administrator

Table 3.16 System use case description for View feedback

29
3.1.4 Activity Diagram
Activity Diagrams are used to Document the logic of a single operation /methods, a single
use case, or the flow of logic of a business operation. In many ways, Activity Diagrams are
the object_ oriented Equivalent of flow charts and Data-flow Diagrams (DFD) from structure
development [1].

We will try to show selected activity diagram of our system….

30
3.1.5 Object Model
Here it goes….

3.1.6 Data dictionary

A Data dictionary is a collection of names, definitions, and attributes about data elements that
are being used or captured in a database, information system, or part of a research project. It

31
 describes the meaning and purposes of data elements within the context of a project, and
provides guidance on interpretation, accepted meanings and representation. A Data
Dictionary also provides a metadata about data elements. The metadata included in a Data
Dictionary can assist in defining the scope and characteristics of data elements, as well the
rules of their usage and application [6] = https://www.library.ucmerced.edu.

Table 3.17 Account entity data dictionary

Number Column Name Data Type Size Constraint Description

1 User_ID Varchar 25 Primary key References to the login table

2 First Name Varchar 25 Not Null Stores users first name

3 Middle Name Varchar 25 Not Null Stores users middle name

4 Last Name Varchar 25 Not Null Stores users last name

5 Gender varchar 6 Not Null Checks whether the user is male or female

6 Email Varchar 25 Not Null Stores users Email id

7 Contact Numeric 10 Not Null Stores users contact number

32
 8 Address Varchar 100 Not Null Stores users address

9 Password Varchar 50 Not Null Stores user’s password

10 Type Varchar 10 Not Null Checks whether the user is admin or

validator or not

11 Photo Varchar 100 Not Null Stores users ID photo

Table 3.18 Category entity data dictionary

Number Column Name Data Type Size Constraint Description

1 Category_ID Int - Primary key Stores unique category id

2 Category_Name Varchar 25 Not Null Stores category name

3 Photo Varchar 100 Not Null Stores photo of the category

Table 3.19 Product entity data dictionary

Numbe Column Name Data Type Size Constraint Description

r

1 Product_ID Int - Primary key Stores product id

2 Category_ID Int - Foreign Key Reference to category table

3 User_ID Varchar 25 Foreign Key Reference to Account table

4 Product_Name Varchar 25 Not Null Stores product name

5 Description varchar 100 Not Null Stores product description

6 Minimum_bid_price Numeric (10,2) Not Null Stores minimum bid price for products

7 Status Bool - Not Null Check whether bid on product is open

33
 or closed

(‘True’ if open, ‘False’ if closed)

8 Photo Varchar 100 Not Null Stores product photo

9 Start_Date Datetime - Not Null Starting bid date for a product

10 End_Date Datetime - Not Null Ending bid date for a product

Table 3.20 Bid entity data dictionary

Numbe Column Name Data Type Size Constraint Description

r

1 Bid_ID Varchar 25 Primary key Stores unique bid id

2 Product_ID Varchar - Foreign Key Reference to Product table

3 User_ID Varchar 25 Foreign Key Reference to Account table

4 Bid_Date Datetime - Not Null Stores the date of bidding

5 Bid_Price Numeric (10,2) Not Null Stores the bid price of a product

Table 3.21 Report entity data dictionary

Number Column Name Data Type Size Constraint Description

1 Report_ID Int - Primary key Stores unique report id

2 Product_ID Int - Foreign Key Reference to product table

3 User_ID Varchar 25 Foreign Key Reference to Account table

4 Description Varchar 100 Not Null Stores the description of the type of
report

34
 Table 3.22 Feedback entity data dictionary

Number Column Name Data Type Size Constraint Description

1 Feedback_ID Int - Primary key Stores unique feedback id

2 User_ID Varchar 25 Foreign Key Reference to Account table

3 Description Varchar 100 Not Null Stores the feedback sent from users

Table 3.23 Bid-Winner entity data dictionary

Number Column Name Data Type Size Constraint Description

1 Winner_ID Int - Primary key Stores unique winner id

2 Bid-ID Int - Foreign Key Reference to Bid table

3 User_ID Varchar 25 Foreign Key Reference to Account table

3.1.7 Class Model

Here it goes….

3.1.8 Dynamic Modelling

Here it goes….

3.1.9 User Interface

Here it goes….

3.1.6 Sequence Diagram

It is used to show the sequence of interactions among objects and used to represent or model
the flow of messages, events and actions between the objects or components of a system.

It is also used primarily to design, document and validate the architecture and interfaces of
the system by describing the sequence of actions that need to be performed to complete a task
or scenario.

We try to show search sequence diagram in the figure below:

35
Figure 3.2 Create account sequence diagram

36
 Figure 3.3 Bidding sequence diagram

3.2.6.2 State Chart Diagram (State Machine Diagram)

It shows how the object instance changes state depending on the message that it receives that
might be internal or external.

We try to show search state machine diagram in the figure below:

37
 Figure 3.3 State chat diagram

It shows how the activities involved in a process or in data processing.

We try to show how search algorithm works in the figure below:

Figure 3.4 Activity diagram

38
 Library Management System

CHAPTER FOUR

SYSTEM DESIGN
4.1 Introduction
System design is the transformation of the analysis model into a system design model. The
purpose of designing is to show the direction on to how the system is built and to obtain clear
and enough information needed to drive the actual implementation of the system. The
objectives of design are to model the system with high quality. Implementation of high-
quality systems depend on the nature of design created by the designer. If someone wants to
change or update the system after it has been put into operation depends on the quality of the
system design. So, if the system is designed effectively, it will be easy to make changes to it.

Once the software requirements have been analysed and specified, the software design
involves three technical activities: design, coding, and testing that are required to build and
verify the software.

The design activities are of main importance in this phase, because in this activity, decisions
ultimately affecting the success of the software implementation and its ease of maintenance
are made. These decisions have the final bearing upon reliability and maintainability of the
system. Design is the only way to accurately translate the customer’s requirements into
finished software or a system.

4.2 Current Software Architecture

The current software architecture is manual the form that is filled when the user borrows a
book, when comment is suggested, when requests are sent and get responses and the report
generation is on paper.

4.3 Proposed Software Architecture

The proposed library management system for Bonga university will consist a centralized
database for the management activities done in the library.

4.3.1 System Decomposition

Here it goes….

4.3.2 Hardware/Software mapping

Here it goes….

4.3.3 persistent data modelling

Here it goes….

39
 Library Management System
4.3.4 Access Control and Security
Here it goes….

4.3.5 Detailed Class Diagram

Here it goes….

4.3.6 Package Diagram

Here it goes….

4.3.7 Deployment
Here it goes….

4.4.1 Component Diagram

Figure 4.1 Component diagram

4.5 Package Diagram

Package diagrams are structural diagrams used to show the organization and arrangement of
various model elements in the form of packages. A package is a grouping of related UML
elements, such as diagrams, documents, classes or even other packages. Package diagrams
are most commonly used to provide a visual organization of the layered architecture within
any UML classifier, such as software system

40
 Library Management System

Figure 4.2 Package Diagram

4.6 Hardware/Software Mapping

4.6.1 Deployment Diagram
The purpose of deployment diagrams can be described as:
 Visualize hardware topology of a system.
 Describe the hardware components used to deploy software components.
 Describe runtime processing nodes.

41
 Library Management System

Figure 4.3 Deployment diagram

4.7 Persistent Data Modelling

4.7.1 Persistent Data Management Diagram

It describes the relationship between users to keep track of data flow by drawing out the
entity along with its attributes. Each entity uniquely identified by the primary key. Below is
an illustration of the system logical design as generated by the entity relationship diagram.

42
 Library Management System

Figure 4.4 Persistent data management diagram

4.8 Access Control and Security

Access control matrix shows which functions are performed by which system users.

43
 Library Management System

Comment

Maintain
Generate
Reserve

Manage
account
Review

request
Accept
Search

Return
Actors

Login

report
View

View

View
Send

Edit
Check
Membe      
r

Guest 

Libraria    
n

    
Library
Manage
r

Admin  

Depart   
ment
Heads

AVP  

Table 4.1 Access control and security

44
 Library Management System
4.9 Detailed Class Diagram
A class diagram is an illustration of the relationships and source code dependencies among
classes in the UML. In this context, a class defines the methods and variables in an object,
which is a specific entity in a program or the unit of code representing that entity.

Figure 4.5 Detailed class diagram

45
 Library Management System
Conclusion and Recommendation
Conclusion
 The library management system is a wide project title that it cannot be finished in this
short time but we try to show the major functions and caviars that the library has and
tries to solve the existing problem by transforming it to digital and well-organized
data base approach.
 If the library uses the idea that we imposed they would make their work so much easy
and free from error.

Recommendation
 We recommend the library management bord to use our RAD documentation and to
use it to develop the software

46
 Library Management System
References

1. www.javatpoint.com/uml-use-case-diagram
2. www.visual-paradigm.com
3. www.usability.gov/how-to-and-tools/methods/use-cases

47