HARAMAYA UNIVERSITY

College of Computing and Informatics

Department of Information Tchnology

Project Report

HARAMAYA UNIVERSITY ONLINE

AUCTION SYSTEM

GROUP MEMBERS NAME AND ID

1. HAILEMARYAM GOBENA………………. 3095/14

2. HABTAMU TILAHUN……………………...3084/14

3. TADELE KASSEW…………………………1612/14

4. MESFINE ANDARGIE………………………3422/14

5. DINEDIG TEFERY…………………….……2577/14

6. ABAYiNEH PAWULOS…………………..… 1854/14

Contents
Abstract ................................................................................................................................1
CHAPTER ONE .......................................……………….................………............… ..... 1
1.1 Background ............................................................................................................... ... 2

1.2 INTRODUCTION .......................................… ........................................................... 1

1.3 STATEMENT OF THE PROBLEM ....................................................................… 2

1.4 OBJECTIVE OF PROJECT .................................................................................… . 3

1.4.1 General Objective ................................................................................................... 3

1.4.2 Specific Objective...........................… ................................................................... .3

1.5 SIGNIFICANCE OF THE STUDY........................................................................… 3

1.6 SCOPE OF STUDY .................................................................................................... 4

1.7 METHODOLOGY..........… ........................................................................................4

1.8 System Development Model……………………………………...…………………..5

1.9 FEASIBLITY ANALAYSIS…………………………………………………………5

1.9.1 ECONOMIC FEASIBILITY……………………………………………..……….6

1.9.2 TECHNNICAL FEASIBILITY…………………………………………..……….6

1.9.3 OPERATIONAL FEASIBILITY…………………………………………………6

1.9.4 LEGAL FEASIBILITY…………………………………………………………....6

1.9.5 POLITICAL FEASIBILITY………………………………………………………6

2.0 DATA FLOW DIAGRAM AND CONCEPTUAL DATA MODELING……………....7

2.1 DATA FLOW DIAGRAM………………………………………………..…………..7

2.2 Decomposition of DFDs…………………………………………………..………….7

CHAPTER TWO………………………………………………………………………15

2. MODELING AND PROTOTYPE……………………………………………..……15

2.1 EXISTING SYSTEM AND PROPOSED SYSTEM………………………………15

2.1.1 THE EXISTING SYSTEM……………………………………………………….15

2.1.2 THE PROPOSED SYSTEM………………………………………………………16

2.2 SRS AND SYSYTEM ANALYSIS MODELING ………………………………….16

2.2.1 FUNCTIONAL REQUIREMENT………………………………………………16

2.2.2 NON FUNCTIONAL REQUIREMENT…………………………………………17

2.3 CRC CLASS RESPONSIBILITY COLLABORATION…………………………17

2.4 LOGICAL DATABASE MODELING AND DESIGN……………………………20

2.4.1 REQUIREMENT ANALYSIS…………………………………………………….21

2.4.2 CONCEPTUAL DATABASE DESIGHN………………………………………22

2.4.3 NORMALIZATION………………………………………………………………..23

2.4.4 LOGICA DATABASE DESIGNE………...………………………………………23

2.4.5 DATA INTEGRITY………………………………………………………………..24

2.6 USE CASE MODELING……………………………………………………………26

2.6.1 ESSENTIAL USE CASE DESCRIPTON………………………………………..27

CHAPTER THREE………………………………………………………………………31

3.0 DESIGN DOCUMENT………………………………………………………………31

3.1 PURPOSE AND GOAL……………………………………………………..………31

3.2 CURRENT SOFTWARE ARCHITECTURE (OOAD PERSPECTIVE)………32

3.2.1 USER INTERFACE DESIGNE …………………………………………………..35

3.3 PROPOSED SOFTWARE ARCHITECTURE(OOAD PERSPECTIVE)………35

3.3.2 SEQUENCE DIAGRAM…………………………………………………………36

3.4 OBJECT MODELING DIAGRAM………………………………………………..40

3.4 .1 CLASS DIAGRAM ……………………………………………………………….40

3.5 OBJECT ATRIBUTES/INTERNALS……………………………………………..40

3.5.1 CLASS DIAGRAM ………………………………………………………………41

3.6 OBJECT BEHAVIOURS/ACTIONS………………………………………………41

3.6.1 SEQUENCE DIAGRAM…………………………………………………………42

3.6.2 ACTIVITY DIAGRM ……………………………………………………………42

3.7 OBJECT INTRACION………………………………………………………………42

3.7.1 SEQUENCE DIAGRAM…………………………………………………………42

3.7.2 CLASS DIAGRAM …………………………….………………………………….43

3.7.3 DEPLOYMENT DIAGRAM…………………………………………………….44

3.7.4 CONCLUSION……………………………………………………………………45
ABSTRACT
The abstraction of an online auction system in Haramaya University would be a digital platform
where users can buy and sell items through an online bidding process. This system would allow
users to create accounts, list items for auction, place bids on items, and make payments securely
online. The system would also include features such as notifications for auction updates, a rating
system for sellers and buyers, and a secure payment gateway. Overall, the abstraction of an
online auction system in Haramaya University would provide a convenient and efficient way for
members of the university community to engage in buying and selling items online.

CHAPTER ONE

1.1 Background
The background of an online auction system in Haramaya University could be rooted in
the need for a convenient and efficient platform for members of the university
community to buy and sell items. Traditionally, auctions have been held in physical
locations, requiring participants to be present in person. However, with advancements in
technology and the increasing popularity of online shopping, universities like Haramaya
may see the benefit of having an online auction system.
The online auction system could provide a way for students, faculty, and staff to easily exchange
goods without the need for physical presence, making transactions more accessible and
convenient. Additionally, an online auction system could promote sustainability by encouraging
the reuse and recycling of items within the university community.
Furthermore, an online auction system could also serve as a platform for fundraising events or
charity auctions organized by student clubs, departments, or university initiatives. This could
help raise funds for various projects and initiatives within the university while engaging the
community in a fun and interactive way.
Overall, the background of an online auction system in Haramaya University could be driven by
the desire to create a digital marketplace that enhances convenience, accessibility, and
sustainability within the university community.
1.2 INTRODUCTION

1
 The introduction of an online auction system in Haramaya University could have been a
response to the growing demand for a more convenient and efficient way for members of
the university community to buy and sell goods. The traditional method of holding
physical auctions may have presented challenges such as limited accessibility, time
constraints, and the need for participants to be physically present.
By introducing an online auction system, Haramaya University aimed to provide a digital
platform that would allow students, faculty, and staff to engage in buying and selling activities
from the comfort of their own devices. This online platform could offer features such as easy
item listing, bidding mechanisms, secure payment options, and user-friendly interfaces to
streamline the auction process.

The introduction of an online auction system in Haramaya University may have been
driven by the desire to promote sustainability by encouraging the reuse and recycling of
items within the university community. Additionally, the system could have been
implemented to facilitate fundraising events, charity auctions, or other initiatives that aim
to raise funds for various university projects and activities.
Overall, the introduction of an online auction system in Haramaya University likely aimed to
enhance convenience, accessibility, and engagement among members of the university
community while providing a digital marketplace for buying and selling goods.

1.3 STATEMENT OF THE PROBLEM

The online auction system in Haramaya University faces several challenges that hinder its
effectiveness and efficiency in facilitating transparent and seamless transactions within the
university community. These challenges include:

Limited Access and Awareness: A significant portion of the university community may not be
aware of the existence or functionality of the online auction system. This lack of awareness
limits participation and adoption among potential users, thereby reducing the diversity and
competitiveness of auctions.

User Authentication and Verification: Ensuring the authenticity of users participating in auctions
is crucial for maintaining trust and transparency. However, the current system may lack robust

2
 mechanisms for verifying the identity of users, leading to potential fraudulent activities and
disputes.

Technical Issues and Reliability: Technical glitches, server downtimes, and slow response times may
impede the smooth operation of the online auction system. Such issues not only disrupt ongoing
auctions but also erode user confidence in the reliability of the platform.
Security Concerns: The security of sensitive user data, including personal information and payment
details, is paramount in an online auction system. Inadequate security measures may expose users to
risks such as data breaches and identity theft, undermining trust in the system.
Dispute Resolution Mechanisms: Resolving disputes that arise during auctions is essential for
maintaining fairness and trust among participants. However, the current system may lack efficient
mechanisms for handling disputes in a timely and impartial manner, leading to dissatisfaction and
conflict.
Payment Processing Challenges: Processing payments securely and efficiently is crucial for
completing transactions and facilitating the exchange of goods and services. However, the online
auction system may face challenges related to payment gateways, currency conversion, and
transaction fees, hindering the seamless flow of transactions.
1.4 OBJECTIVE OF PROJECT

1.4.1 General objective

The objectives of Haramaya University's online auction system are to streamline

and enhance the efficiency, transparency, and accessibility of the auction process.

1.4.2 Specific objective

The specific objective of Haramaya University's online auction system could be to streamline the
process of buying and selling goods or services within the university community. This system
aims to provide a convenient and transparent platform for conducting auctions, facilitating fair
competition among participants, maximizing the value of assets, and ensuring efficient resource
allocation. Additionally, it might aim to enhance financial management and accountability by
digitizing the auction process, thereby reducing paperwork and increasing accessibility for
stakeholders.
1.6 SIGNIFICANCE OF THE STUDY

3
 The significance of the study of the online auction system in Haramaya University lies in
its potential to modernize and streamline the process of buying and selling goods and
services within the university community. By providing a digital platform, it enhances
accessibility, transparency, and efficiency, fostering fair competition and improving
resource allocation.
1.4 SCOPE OF STUDY

The scope of the study of the online auction system in Haramaya University encompasses:

 Analysis of the current system's functionality and limitations.

 Identification of user requirements and preferences within the university community.
 Development and implementation of enhancements to improve system performance and
user experience.
 Integration of security measures to safeguard user data and transactions.
 Evaluation of the system's effectiveness in facilitating transparent and efficient auctions.
 Consideration of scalability and sustainability for future expansion and adoption.
 Collaboration with stakeholders to gather feedback and address concerns throughout the
implementation process.
1.5 METHDOLOGY
Methodology in a project refers to the systematic approach or set of procedures used to
plan, execute, and manage the project from inception to completion. It outlines the steps,
techniques, tools, and resources required to achieve project objectives efficiently and
effectively.
The methodology of the online auction system in Haramaya University involves:

 Requirement Analysis: Understanding the needs and preferences of users within the
university community.
 System Design: Developing a comprehensive plan for the architecture, features, and
functionalities of the online auction platform.
 Development: Implementing the system according to the design specifications,
incorporating security measures and user-friendly interfaces.

4
  Testing: Conducting thorough testing to ensure the reliability, performance, and security
of the system.
 Deployment: Launching the online auction system and providing necessary training and
support to users.
 Monitoring and Evaluation: Continuously monitoring the system's performance and
gathering feedback from users to identify areas for improvement.

1.6 SYSTEM DEVELOPMNET MODEL

In system development, a waterfall model is a sequential design process, often used in software
development processes, in which progress is seen as flowing steadily downwards (like a
waterfall) through several phases. These phases generally include:

 Requirement Analysis

 Project Planning

 System design

 Coding

 Unit testing

 System integration & testing

Each phase in the waterfall model is completed before moving on to the next phase, and changes
to previous phases are typically not allowed once they are completed. This model is often
criticized for its rigidity and lack of flexibility, as it does not easily accommodate changes or
iterations once the development process has begun. However, it can be useful for projects with
well-defined and stable requirements where the final product is expected to remain largely
unchanged.

1.7 FEASIBILITY ANALAYSIS

5
Feasibility analysis is a process of evaluating the practicality and potential success of a proposed
project or idea, typically considering factors like costs, resources, risks, and benefits. There are
many types of feasibility thus are:

1.7.1 Economic Feasibility

Economic feasibility assesses whether a proposed project or system is financially viable and if
the benefits outweigh the costs, considering factors such as investment required, potential
revenue, and return on investment.

1.7.2 Technical Feasibility

Technical feasibility evaluates whether a proposed project or system can be successfully

developed and implemented using available technology, expertise, and resources. It considers
factors such as compatibility, scalability, and the availability of necessary skills and
infrastructure.

1.7.3 Operational Feasibility

Operational feasibility examines whether a proposed project or system aligns with the
organization's operations, processes, and goals, and if it can be effectively integrated into
existing workflows. It assesses the practicality of implementing and using the system from an
operational standpoint.

1.7.4 Legal Feasibility

Legal feasibility evaluates whether a proposed project or system complies with relevant laws,
regulations, and industry standards. It aims to minimize legal risks and ensure compliance with
applicable legal requirements throughout the development and implementation process.

1.7.5 Political Feasibility

Political feasibility assesses whether a proposed project or system has the necessary
support from stakeholders, including management, employees, and external entities, to

6
 overcome potential resistance or opposition. It considers factors such as stakeholder
interests, power dynamics, and the overall socio-political environment.
1.9 DATA FLOW DIAGRAM AND CONCEPTUAL DATA MODELING

1.9.1 DATA FLOW DIAGRAM

A Data Flow Diagram (DFD) is a graphical representation of the flow of data within a system.
It consists of processes, data stores, data flows, and external entities.
Processes: Represent activities or functions within the system that transform input data
into output data.
Data Stores: Represent repositories where data is stored within the system.
Data Flows: Represent the movement of data between processes, data stores, and
external entities.
External Entities: Represent sources or destinations of data outside the system, such as
users or other systems.

1.9.2 Decomposition of DFDs

Decomposition of DFDs:

Context Diagram (Level 0 DFD):

At the highest level, the Level 0 DFD provides a bird's eye view of the entire system. For the
online auction system at Haramaya University, the Level 0 DFD might include major processes
like:

User Interaction: This process represents interactions between users and the system, such as
browsing items, bidding, and managing user accounts.
Auction Management: This process handles the management of auctions, including creating
new auctions, managing bids, and closing auctions.
Payment Processing: This process deals with handling payments for items won in auctions,
integrating with payment gateways, and managing financial transactions securely.

 This is the highest level of the DFD, representing the system as a whole and showing its
interaction with external entities.

7
  Data stores are generally not included at this level because the focus is on the external
inputs and outputs of the entire system.

Figure 1.1 Level 0 DFD

In this diagram:

 External Users interact with the Online Auction System.

 The system manages auctions, users, and processes payments.

This is a basic representation of the Level 0 DFD, showing the high-level interactions and
processes of the system.
Level 1 DFDs:
Each process from the Level 0 DFD can be decomposed into more detailed processes in the
Level 1 DFDs. For example:

User Interaction:

8
 View Items
Place Bid
Manage Account
Auction Management:
Create Auction
Manage Bids
Close Auction
Payment Processing:
Process Payment
Handle Refunds
Manage Financial Records

Figure 1.2 Level 1 DFD

In this diagram:
 External Users interact with the Online Auction System.
 The system manages auctions, users, and processes payments.
 Auctions can be created, bids can be managed, and auctions can be closed.

9
  Users can register, update their profiles, and delete their accounts.
 Payments are processed, refunds are handled, and financial records are managed.

This Level 1 DFD provides more detail about the processes involved in the Haramaya University
online auction system compared to the Level 0 DFD.

Level 2 DFDs:

Further decomposition can be done for specific processes to provide even more detail. For
instance:

View Items:

Retrieve Item Information

Display Item Details
Place Bid:
Validate Bid
Record Bid
Manage Account:
Register New User
Update User Profile
Delete User Account

10
Figure 1.3 Level 2 DFD

In this Level 2 DFD:

 External Users interact with the Online Auction System.

 The system manages auctions, users, and processes payments.
 Auctions can be created, bids can be managed, and auctions can be closed.
 Users can register, update their profiles, and delete their accounts.
 Payments are processed, refunds are handled, and financial records are managed.
 The Create Auction process gathers item information and displays item details.
 The Manage Bids process validates bids and records them.

11
This Level 2 DFD provides even more detail about specific processes involved in the Haramaya
University online auction system compared to the Level 1 DFD.

Figure 1.4 Data Flow Diagram

1.9.2 CONCEPTUAL DATA MODELING

12
Conceptual Data Model:

A conceptual data model describes the high-level entities and their relationships within the
system without delving into implementation details. For the online auction system at Haramaya
University, the conceptual data model might include entities like:

User: Represents individuals interacting with the system.

Attributes: UserID, Username, Password, Email, Address, Phone
Item: Represents items put up for auction.
Attributes: ItemID, ItemName, Description, StartingPrice, SellerID, AuctionEndDate
Bid: Represents bids placed on items.
Attributes: BidID, ItemID, BidAmount, BidderID, TimeOfBid
Auction: Represents the auction process.
Attributes: AuctionID, ItemID, SellerID, StartDate, EndDate, WinningBidID
Payment: Represents payments made for winning bids.
Attributes: PaymentID, BidID, Amount, PaymentMethod, PaymentDate
Transaction: Represents financial transactions.
Attributes: TransactionID, UserID, Amount, TransactionDate, Type (e.g., Bid, Payment,
Refund)

13
14
 Figure 1.5 conceptual data modeling

This E-R data model reflects the relationships between entities in the Haramaya University
online auction system:

 Users can create auctions and place bids.

 Auctions manage bids, consist of items, and result in payments.
 Bids lead to payments.
 Users initiate transactions.

Each entity has its attributes, and relationships between entities are depicted using lines and
annotations. This conceptual E-R data model provides a clear representation of the structure and
connections within the system.

1.9.3 Relationships

 A User can create multiple auctions (one-to-many relationship).

 An Item can be associated with only one auction (one-to-one relationship).
 An Auction can have multiple bids (one-to-many relationship).
 A Bid is made by a single User (many-to-one relationship).
 A Payment is made for a single Bid (one-to-one relationship).
 A Transaction can involve multiple users or entities (many-to-many relationship).

By decomposing DFDs and creating a conceptual data model, stakeholders can gain a clear
understanding of the system's processes and data requirements, laying a solid foundation for
further system design and development.

CHAPTER TWO
MODELING AND PROTOTYPE

2.1 Description of the Current System/Existing System and Proposed System

2.1.1 The Existing System

The existing online auction system at Haramaya University is a platform that facilitates the

15
buying and selling of goods or services through an online bidding process. It likely allows users,
such as students, faculty, and staff, to participate in auctions for various items, including
equipment, textbooks, and other university-related goods. The system may feature functionalities
such as user registration, item listings, bidding, payment processing, and auction management. It
serves as a digital marketplace within the university community, offering convenience and
accessibility for transactions.

2.1.2 The proposed System

The proposed online auction system for Haramaya University aims to enhance the existing
platform by introducing new features and improvements. It may include upgrades such as :

 System more user-friendly interface,

 System enhanced security measures for transactions,
 . The system will have high performance to handle simultaneous user interactions.
 System improved search and filtering options, and
 The system will prioritize minimal downtime and robust data protection measures to
ensure the safety of user information.
 increase user engagement
 ensuring a responsive and intuitive experience..

2.2 System Requirement Specification (SRS) and System analysis modeling

We prepare the set of documents that describes the features and behaviors of the
proposed system those are: -

 Functional requirements of the projects.

 Class responsibility collaboration of the project.
 Use case diagram of the project.
 User interface prototype of the project.
 Nonfunctional requirements of the project.

2.2.1 Functional Requirement

16
A functional requirement specifies what a system should do, detailing the behaviors, features,
and functions necessary to meet user needs and business objectives. Examples include user
authentication, data processing, and report generation.

Functional requirements for an online auction system at Haramaya University might include:

 To register and create accounts with unique credentials.

 To browse and search for items.
 To place bids on items.
 To receive notifications about bidding activity.
 To make payments securely.

2.2.2 Non Functional Requirement

A non-functional requirement defines how a system should perform and the constraints within
which it must operate. These requirements focus on the quality attributes of the system, such as
performance, security, scalability, and usability.
The non-functional requirements of an online auction system at Haramaya University might
include:

 The system must be secure, scalable, reliable, user-friendly,

 To have high performance to handle simultaneous user interactions.
 The system should also have a responsive and intuitive user interface, with minimal
downtime .
 To robust data protection measures in place.

2.2.3 CRC (Class Responsibility collaboration)

Class Responsibility Collaboration (CRC) is a technique used in object-oriented analysis and
design to identify and define the classes, their responsibilities, and their interactions within a
system.

Here's a breakdown of the components of CRC:

 Class: A class represents a blueprint for creating objects in the system. It defines the
properties (attributes) and behaviors (methods) of objects belonging to that class.
 Responsibility: Responsibility refers to what a class is responsible for doing within the
system. This includes the tasks it performs, the information it manages, and the services it
provides to other classes.

17
 Collaboration: Collaboration describes how classes interact with each other to fulfill
their responsibilities. It involves identifying which classes need to communicate with
each other and how they exchange messages to accomplish tasks or share information.
There are three types of classes in CRC such us:

1, Actor class

2, Business class

3, UI (user interface) class

Figure 2.1 Actor class

18
Figure 2.2 Business class

19
 Figure 2.3 User interface class

2.3 Logical Database Modeling and Design

Logical database modeling and design is the process of translating conceptual data models into a
structured format that can be implemented in a database management system (DBMS). It
involves defining the structure of the database, including tables, columns, relationships, and
constraints, without considering the physical implementation details such as storage and
indexing. The goal is to create a logical representation of the data that accurately reflects the
organization's requirements and supports efficient data retrieval, manipulation, and maintenance.

20
Designing a database for an online auction system for Haramaya University involves several
steps in logical database modeling and design. Here's a high-level overview of the process:

2.3.1 Requirement Analysis

Requirement analysis in logical database modeling for Haramaya University's online auction
system involves thoroughly understanding the needs and objectives of the university regarding
the management of the auction platform. This process includes:

Identifying Stakeholders: Recognizing all parties involved in the system, including university
administrators, auction participants (buyers and sellers), and system administrators.
Gathering Requirements: Conducting interviews, surveys, and meetings to collect detailed
requirements from stakeholders. These requirements encompass functional aspects (such as user
registration, item listing, bidding, and transaction processing) as well as non-functional
requirements (including security, scalability, and performance).

Analyzing Requirements: Evaluating the gathered requirements to ensure they are clear,
complete, and consistent. This involves identifying any conflicts or ambiguities and resolving
them through further communication with stakeholders.

Prioritizing Requirements: Ranking requirements based on their importance and urgency to

guide the development process. Critical features essential for the system's operation should be
prioritized over less crucial ones.

Documenting Requirements: Creating comprehensive documentation that clearly outlines all

identified requirements, including use cases, user stories, and system specifications. This
documentation serves as a reference for developers during the design and implementation
phases.

Validating Requirements: Reviewing the documented requirements with stakeholders to verify

their accuracy and ensure they meet the university's objectives. Any necessary adjustments or
refinements should be made based on feedback received.

21
Requirement analysis lays the foundation for the subsequent stages of logical database modeling
and design, guiding the development team in creating a database schema that aligns with the
identified needs and functionalities of Haramaya University's online auction system.

2.3.2 Conceptual Database Design

Conceptual database design in logical database modeling for Haramaya University's online
auction system involves creating an abstract representation of the database structure without
considering specific implementation details. This stage focuses on understanding the entities,
attributes, relationships, and constraints that will be part of the database schema.

Here's how conceptual database design for the Haramaya University online auction system might
be defined:

Identifying Entities: Recognizing the main objects or entities within the system. In this context,
entities could include users (buyers, sellers, administrators), items (products being auctioned),
bids (offers made by buyers), and transactions (completed auctions).
Defining Attributes: Determining the properties or characteristics of each entity. For example,
users may have attributes such as username, password, email, and user type (buyer or seller).
Items could have attributes like item name, description, starting price, start date, and end date.
Establishing Relationships: Identifying the associations between entities. For instance, users
may have relationships with items, such as sellers listing items for auction and buyers placing
bids on those items. Bid entities are related to both users and items, representing the act of
bidding.
Capturing Constraints: Understanding any rules or limitations that apply to the data.
Constraints could include business rules (e.g., minimum bid amount), cardinality constraints
(e.g., one-to-many relationship between users and items), and integrity constraints (e.g., ensuring
data consistency and accuracy).
Creating an Entity-Relationship Diagram (ERD): Visualizing the entities, attributes, and
relationships using a graphical representation. The ERD serves as a blueprint for the database
schema and helps communicate the database structure to stakeholders.

22
2.3.3 Normalization
Normalization in logical database modeling for Haramaya University's online auction system
refers to the process of organizing the database tables and their attributes to minimize
redundancy and dependency, ensuring data integrity and efficient storage.

Here's a brief overview of normalization in this context:

Identifying Functional Dependencies: Analyze the relationships between attributes in each

table to identify functional dependencies. Functional dependency occurs when the value of one
attribute uniquely determines the value of another attribute within the same table.
Applying Normal Forms: Apply normalization rules, typically up to the third normal form
(3NF), to remove any anomalies and ensure that each table represents a single subject. The
normalization process involves several normal forms, including:
First Normal Form (1NF):
 Ensures that each table has a primary key and that each attribute within the table contains
atomic values.
 In the online auction system:
 Each table, such as the User, Item, and Bid tables, should have a primary key to uniquely
identify each record.
 Attributes within each table should not contain repeating groups or arrays, ensuring that each
cell holds a single, indivisible value.
Second Normal Form (2NF):
Ensures that no partial dependencies exist in a table, meaning that all non-key attributes are fully
functionally dependent on the entire primary key.
 In the online auction system:
 If an attribute depends on only part of the primary key, it should be moved to a separate
table with that part of the primary key, thereby removing partial dependencies.
 For example, if an attribute like StartPrice depends only on ItemID in the Item table, it
should be moved to a new table with ItemID as the primary key.
Third Normal Form (3NF):
Ensures that no transitive dependencies exist in a table, meaning that non-key attributes are not
dependent on other non-key attributes.

23
 In the online auction system:
 If an attribute depends on another non-key attribute, it should be moved to a separate table
with
 For example, if an attribute like Description depends on an attribute other than the primary
key in the Item table, it should be moved to a new table with the dependent attribute as the
primary key.
Breaking Down Tables: If necessary, decompose tables into smaller, more normalized tables to
adhere to the normalization principles. This may involve creating new tables, establishing
relationships between them, and redistributing the attributes.
2.3.4 Logical Database Design
Logical database design in the context of Haramaya University's online auction system involves
translating the conceptual database model into a structured format that can be implemented in a
database management system (DBMS). This phase focuses on defining the tables, columns,
relationships, and constraints based on the requirements identified during the conceptual design
phase. Here's how logical database design can be defined for the online auction system:Define
Database Tables:

Identify the entities from the conceptual model and create corresponding tables in the database.
These tables represent the main objects or entities in the system, such as User, Item, and
Bid.Determine the attributes for each table, representing the properties or characteristics of the
entities. For example, the User table may include attributes like UserID, Username, Password,
and UserType.

User Table

24
Figure 2.1 User table

Item Table

Figure 2.2 Item table

Bid Table

25
Figure 2.3 Bid Table

Auction Table

Figure 2.4 Auction table

Establish Relationships:

 Define relationships between the tables to represent the associations or connections between
entities. This involves specifying foreign keys to link related tables.
 For example, the Item table may have a foreign key referencing the UserID in the User table
to establish the relationship between sellers and their listed items.
2.3 Use Case Modeling

Use case modeling is a technique used in software engineering to describe the functional
requirements of a system from the perspective of its users. It involves identifying and
documenting the interactions between users (actors) and the system to achieve specific goals or

26
tasks. When describing questions related to use case modeling, they often revolve around
understanding the system's behavior and functionality. Here are some example questions:

What are the primary goals or objectives of the system?

Who are the primary actors or users of the system?
What are the main tasks or actions that users need to perform within the system?
How do users interact with the system to accomplish their tasks?
Are there any alternative or exceptional scenarios that need to be considered?
What are the dependencies or relationships between different use cases?
What are the inputs and outputs for each use case?
How does the system respond to various user actions or events?

2.3.1 Essential Use Case Modeling

Essential use case modeling is a technique in software engineering that focuses on
identifying and documenting the fundamental interactions between users (actors) and a
system to achieve specific goals or tasks. It provides a high-level overview of the
system's functionality without getting into detailed implementation specifics.

27
 2.3.1 Essential Use Case Modeling
2.3.2 Essential Use Case Description

User Registration
Actor: User
Description: Allows users to create accounts by providing necessary information such as
name, email, and password.
Item Listing

28
 Actor: User (Seller)
Description: Enables users to list items for auction, including item details such as name,
description, images, starting bid price, and auction duration.
Bidding
Actor: User (Buyer)
Description: Allows registered users to place bids on items within the specified auction
duration.
Auction Management
Actor: Administrator
Description: Enables administrators to manage the auction process, including creating new
auctions, editing existing ones, and closing auctions.
Notifications
Actor: System
Description: Notifies users about important events related to auctions, such as bid updates,
auction start and end times, and auction results.
Payment Processing
Actor: User (Buyer)
Description: Facilitates secure payment transactions for winning bids, including integration
with payment gateways and tracking payment statuses.
Search and Filtering
Actor: User
Description: Enables users to search for specific items and filter search results based on
criteria such as category, price range, and auction status.
User Feedback
Actor: User (Buyer/Seller)
Description: Allows users to leave feedback and ratings for each other based on their auction
experiences.
2.3.2 System Use Case Modeling
A System Use Case Diagram for the Haramaya University online auction system would illustrate
the various functionalities of the system and how different actors interact with it to achieve their
goals. Let's break down the key components and provide an explanation for each:

29
Actors:
Guest: Represents visitors who are not registered users but can browse auction listings.
User: Represents registered members of the university community who participate in
auctions by browsing, bidding, and selling items.
Admin: Represents administrators who manage the online auction system, including user
accounts, item listings, and system settings.
External Systems: Represents external services or systems that interact with the auction
system, such as payment gateways, shipping services, and notification services.
Use Cases:
Browse Listings: Allows users and guests to browse through available auction listings.
Search Listings: Enables users and guests to search for specific items within the auction
listings.
View Item Details: Allows users and guests to view detailed information about a specific
item.
Place Bid: Allows users to place bids on items they are interested in purchasing.
Sell Item: Allows users to list items they want to sell in the auction.
Manage Listings: Enables administrators to manage auction listings, including
adding ,editing, or removing them.
Manage Users: Allows administrators to manage user accounts, including approving
registrations and handling account issues.
View Reports: Enables administrators to view reports and analytics related to auction activity.
Process Payment: Represents the interaction with a payment gateway to process payments for
items sold in auctions.
Track Shipment: Represents the interaction with a shipping service to track the shipment of
items sold in auctions.
Send Notifications: Represents the interaction with a notification service to send notifications
to users about auction events.
System Boundary:
The system boundary encloses all the actors and use cases involved in the Haramaya
University online auction system, representing the scope of the system under consideration.
Relationships:

30
 Association: Actors are associated with the use cases they are involved in. For example, users
are associated with use cases such as Browse Listings, Place Bid, and Sell Item.
Inclusion: Some use cases may include others. For example, the Place Bid use case may
include the Login use case, as users need to be logged in to place bids.
External Systems:
Represented as separate blocks outside the system boundary, indicating their interaction with
the auction system.
CHAPTER THREE

Design Document

INTRODUCTION

Purpose and Goals

In the realm of OOAD, the purpose and goals of the system design are translated into object-
oriented terms. Here's a breakdown:

Purpose

The purpose of the system is to facilitate efficient and transparent online auctions within the
Haramaya University community. From an OOAD perspective, this translates to creating objects
and classes that represent the various entities and processes involved in the auction system, such
as Users, Items, Bids, and Auctions.

Goals
Efficiency: Design classes and methods that optimize the performance of the system, ensuring
that actions like placing bids or listing items for auction are executed swiftly.
Transparency: Implement object relationships and attributes that provide clear visibility into
the auction process, including bid histories, item details, and user feaedbck.
Scalability: Architect the system in a way that allows it to scale gracefully as the user base and
transaction volume grow over time.
Security: Integrate security features at the object level to safeguard user data, prevent
unauthorized access, and protect against fraudulent activities.

31
3.1 Current Software Architecture (OOAD Perspective)

In the current software architecture from an OOAD perspective, we would identify and describe
the key classes and their relationships:

1.User Class: Represents individuals registered on the platform. Attributes may include
username, password, email, and role (e.g., buyer, seller).
2. Item Class: Represents items available for auction. Attributes may include item ID, name,
description, condition, starting price, and seller ID.
3.Bid Class Represents bids placed on items. Attributes may include bid ID, bidder ID, item ID,
bid amount, and timestamp.

4. Auction Class: Represents the auction process. It may manage the lifecycle of auctions,
including starting, ending, and managing bids.

3.1.1 USER INTRFACE DESIGN

User Interface Design refers to the process of designing the visual layout and interactive
elements of a software application or system, focusing on enhancing user experience and
usability. It involves creating intuitive interfaces that allow users to interact with the system
efficiently and effectively. User Interface Design encompasses aspects such as layout,
navigation, visual aesthetics, interaction design, and usability testing to ensure that the interface
meets the needs and expectations of its users.

32
Figure 3.1 Login interface

Figure 3.2: New account interface

33
Figure 3.4 all listings

34
Figure 3.5 Active listings

3.2 Proposed Software Architecture (OOAD Perspective)

In a more sophisticated real-world scenario, the proposed software architecture would further
refine and extend the current design to meet evolving needs and challenges:

1.Refined Class Structure: Refine class attributes and methods to incorporate additional details
and functionalities based on user feedback and system analysis.
2.Inheritance and Polymorphism: Utilize inheritance and polymorphism to create more
flexible and reusable code structures. For example, different types of auctions (e.g., English
auction, Dutch auction) could inherit from a common Auction class, with each implementing its
specific rules and behaviors.
3.Design Patterns: Apply design patterns such as Observer for real-time updates on auction
status, Strategy for handling different bidding strategies, and Singleton for managing critical
system resources like the auction scheduler.
4.Integration with External Services: Integrate with external services such as payment
gateways, shipping providers, and notification systems to enhance the functionality and user
experience of the platform.

35
5. Testing and Validation: Implement comprehensive unit tests and validation mechanisms to
ensure the reliability and robustness of the system, especially in handling edge cases and
unexpected scenarios.
By adopting these enhancements in the proposed software architecture, the Haramaya University
online auction system can achieve higher levels of sophistication, scalability, and reliability
while maintaining its core objectives of efficiency and transparency.
3.2.1 Sequence Diagram

In the context of Haramaya University's online auction system, a sequence diagram would
illustrate the interactions and flow of messages between different components or objects
involved in a specific scenario or use case. For example, it could depict the sequence of actions
when a user places a bid on an item, showing how the user interface communicates with the
backend server, how the bid is processed, and how the database is updated. This diagram helps
visualize the runtime behavior of the system and the order of interactions between its
components.

36
Figure 3.6 Sequence Diagram

37
38
39
3.3 Object model diagram

TIn Object-Oriented Analysis and Design (OOAD) perspective, organizing identified objects
involves creating an object model diagram. For the Haramaya University online auction system,
we identify objects like User, Item, Bid, Auction, and Category. The object model diagram
represents these objects with their attributes and methods, showing relationships between them.
This diagram aids in visualizing the structure of the system, including how objects interact and
collaborate.

3.3.1 Class Diagram

A class diagram is a type of UML (Unified Modeling Language) diagram that represents the
structure and relationships of classes within a system. It illustrates the classes, attributes,
methods, and associations between classes in a visual format. Class diagrams provide a high-
level overview of the system's architecture, helping to understand the organization of classes and
their interactions, facilitating effective communication among stakeholders during the design and
development process.

40
Figure 3.7 Class Diagram

41
3.4 Object Atributes/internals

In Object-Oriented Analysis and Design (OOAD) for the Haramaya University auction
system:Define the internals of the objects (classes):

 Identify relevant classes like User, Item, Bid, etc.

 Determine attributes for each class such as Username, ItemID, BidAmount, etc.
 Establish relationships between classes (associations, aggregations, compositions).
 Specify methods or behaviors if needed (e.g., validateBid(), placeBid()).
Object Attributes:
 User Class: Username, Password, Email, Address, Phone, Role, etc.
 Item Class: ItemID, Name, Description, Category, StartingPrice, etc.
 Bid Class: BidID, BidderID, ItemID, Amount, Time, Status, etc.
 Transaction Class: TransactionID, BuyerID, SellerID, ItemID, Amount, Time, Status,
etc.

This defines the internal structure and attributes of objects/classes within the Haramaya
University auction system, facilitating further analysis, design, and implementation.

3.5 Object behaviours/actions

The behavior of objects in the Haramaya University auction system involves actions such as
placing bids, browsing items, registering users, and viewing transaction history. These actions
are orchestrated through interactions between users, the user interface, controllers, and item
objects, as depicted in sequence diagrams.

3.5.2 Activity Diagram

The activity diagram for the Haramaya University online auction system illustrates the sequence
of actions or behaviors performed by users and administrators. It starts with users browsing
items, placing bids, registering (if bid is successful), and viewing transaction history.
Administrators manage auctions and users. The diagram shows the flow of activities and
decisions, guiding users and administrators through the system's functionalities and interactions.

42
Figure 3.10 Activity Diagram
3.6 Object Interaction

In the Haramaya University online auction system, objects interact through various actions such
as placing bids, browsing items, registering users, managing auctions, and viewing transaction
history. Users interact with the system to perform these actions, while administrators oversee and
manage the auction process. Objects such as User, Item, Bid, Transaction, and Admin
collaborate to facilitate these interactions, with each object playing a specific role in the system's

43
functionality. The interactions are orchestrated through a series of messages exchanged between
objects, enabling users to participate in auctions and administrators to oversee the system's
operation.
3.6.3 Deployment Diagram

A sophisticated Deployment Diagram for the Haramaya University online auction system in a
real-world scenario would depict a distributed architecture with multiple layers of servers and
services. It would include components such as load balancers for traffic distribution, redundant
web servers for hosting the application, application servers for processing logic, caching servers
for performance optimization, and clustered database servers for data storage. This setup ensures
scalability, fault tolerance, and high availability, meeting the demands of a large-scale online
auction platform while maintaining performance and reliability.

Figure 3.13 Deployment Diagram

3.6.4 Persistence Modeling

The Persistence Modeling of Haramaya University's online auction system likely refers to the
design and implementation of the database structure and functionality that allows the system to
store and manage data persistently. This includes creating tables to represent entities such as

44
 users, items, bids, transactions, and their relationships, as well as defining the rules and
constraints to ensure data integrity and reliability. Additionally, it involves implementing
mechanisms for data retrieval, manipulation, and storage optimization to support the efficient
operation of the online auction system over time.

3.6.5 CONCLUSION
The implementation of an online auction system at Haramaya University offers a modern
solution to streamline asset disposal processes. By leveraging digital platforms, the system
enhances efficiency, transparency, and accountability, while also broadening the reach of
potential buyers. This not only maximizes revenue from surplus items but also establishes a
robust framework for effective asset management in the university.

REFERENCE

1. Simform Guide: Simform's Guide to Online Auction Systems (Simform).

2. RainWorx Software: RainWorx Auction Software (RainWorx).
3. GitHub Django Auction: GitHub Online Auction System (GitHub).
4. TechJini Auction Platform: TechJini Online Auction System (Simform).

45