Sie sind auf Seite 1von 64

Efficient Electronic Auction System for Wholesale

Markets in India
A project report submitted to National Academy of Agricultural Research Management,
Hyderabad
in partial fulfilment of the requirements
for the
Post Graduate Diploma
in
Information Technology Management in Agriculture

by

Alok Gora
(ITMA0802)
August – October, 2009

Under guidance of

Project Guide Project Supervisor


Dr J. S. Yadav Ms Pratibha Bisht
Chief Operating Officer (COO) Management Trainee
Premium Farm Fresh Produce Ltd. Premium Farm Fresh Produce Ltd.

National Academy of Agricultural Research Management,


Hyderabad, India - 500407
BONAFIDE CERTIFICATE

It is certified that this project report titled “Efficient Electronic

Auction System for Wholesale Markets in India” is the bonafide

work of Mr. Alok Gora who carried out the project work under my

supervision.

Signature Signature

Head of the ICM Division Supervisor

Dr. Rama Rao Ms. Pratibha Bisht


Course Director PGDITMA Premium Farm Fresh Produce Ltd.
NAARM, Hyderabad New Delhi
ACKNOWLEDGEMENT

With great pleasure and deep sense of gratitude, I take this opportunity to
express my sense of indebtedness to Ms. Pratibha Bisht, Management Trainee, Premium
Farm Fresh Produce Ltd, New Delhi, for her valuable guidance, painstaking effort and
constant encouragement given at each and every step of my project work.

I am also indebted to Dr. J.S. Yadav Chief Operating Officer (C.O.O.)


Premium Farm Fresh Produce Ltd, New Delhi, for his valuable guidance, helpful
counsel and encouragement throughout my project work. Thanks are also due for
providing me all the necessary facilities during the course of my project work.

It gives great immense pleasure to convey my deep thanks to Dr. Rama Rao,
Course Director & HOD ICM Division NAARM, Hyderabad for their inspiring
guidance and succor.

I would like to thank Mr. Sudheer, Mr. Ashwani Rajput, Mr. Manish, Mr.
Laxman, Mr. Anil, Mr, Praveen, Ms. Anita, Mr. Vinod, Mr. Anwer and other staff
member for their co-operation at appropriate time through the completion of this
project.

I wish to convey my heartfelt thanks to all my friends for their encouragement


and moral support during the course of my project work.

I can’t quote in words the wholehearted sense of reverence to my parents. The


inspiration behind successful completion of my project work is their endurance,
everlasting strong support and endless prayers.

Lastly I express my thanks to all those who help me directly or indirectly for
the conduct of project work.

28th Oct. 2009 (Alok Gora)


COMPANY PROFILE

Premium Farm Fresh Produce Limited is a company of THE SURI GROUP –


promoted by Late MR LALIT SURI. Premium Farm Fresh Produce intends to be the pioneers in
Terminal markets in India and to become the biggest and best service provider for fresh produce.
The company has already pioneered in exporting fruits and vegetables from India to different
countries in the World. The company is engaged in providing premium quality fresh produce to
the markets worldwide and promotes world class standards for agricultural marketing practices,
progressive farming techniques, identification and adoption of appropriate technologies through
(a) Backward Linkages: Corporate farming, Contract farming, Field Procurement, General
Trading etc.

Its unique strength in this business is the extensive backward linkages which has
established with the farmers. This networking with the farming community has enabled PFFPL to
build a highly cost effective procurement system. The Company has set up a complete
warehousing and cold chain infrastructure for ensuring the availability of fresh products in the
world market, besides direct linkages with the farmers for helping source farm fresh produce.
Fresh Table Grapes & Pomegranates are sourced from PFFPL's EUREPGAP Certified Farmer
groups

Its investments and resource planning form the backbone of the company ensuring a
strong produce- supply chain to deliver safe, consistent and competitively priced produce, all year
round. Along with this it intends to establish Electronic Grading Lines for Onions, Vegetables and
other fruits and Vegetables in the country.

Imports of Agro commodities, spices with cost effective global sourcing with trading in
commodity exchanges and physical deliveries make PFFPL one of the leading Agri Business
Venture in the country. The Company is fully prepared to take up this innovative premier and
challenging task and to handle in the most professional manner. The Former Director, NIAM
(National Institute of Agricultural Marketing) Dr J S Yadav (C.O.O.), who conceptualized this
new hub and spoke format for Terminal Market. He is India’s leading expert in the field of
Agricultural Marketing, Development and pioneer in Terminal Market Research, Project
preparation and Implementation, in India.
CONTENTS

CHAPTER DESCRIPTION PAGE


No.

LIST OF TABLES
LIST OF FIGURES

EXECUTIVE SUMMARY 1
1 OVERVIEW 2
1.1 Introduction 2
1.2 Problem Area 2
1.3 Objectives 4
1.4 Scope 4
1.5 Definitions 5

2 ANALYSIS EAS 6
2.1 Software Requirement Specifications 6
2.2 Constraint 7
2.3 System Wide Requirement 7
2.4 Functional Requirement 8
2.4.1 Use Case Model 8
2.4.2 Use Case Overview 9
2.4.3 Use Case Specifications 10
2.4.4 Activity Diagrams 18

3 ARCHITECTURE FOR EAS 30


3.1 Solution Model 30
3.2 J2EE Realization Model 31
3.3 .Net Realization Model 33

4 INTERFACES 34
4.1 Hardware Interface 34
4.2 Software Interface 35
4.3 User Interface 36
4.3.1 Log in Page 36
4.3.2 Home Page 37
4.3.3 Registration page 38
4.3.4 Generate Identification Number Page 39
4.3.5 Product Registration Page 40
4.3.5.1 Seller ID Page 40
4.3.5.2 Product Detail Form 41
4.3.5.3 View Product Detail 42
4.3.6 Verification of Product Details 43
4.3.7 Update Product details 44
4.3.8 Pre Auction Page 45
4.3.9 Auction Setup Page 46
4.3.10 Invoice Form 47
4.3.11 View Invoice 48
4.3.12 Search profile 49
4.3.13 Search Result of Profile 50
4.3.14 Search Commodity 51
4.3.15 Search Result of Commodity 51
4.3.16 View Commodity Result 52
4.3.17 Lot Preparation 53

5 OTHER REQUIREMENTS 54
5.1 Performance Requirement 54
5.2 Security Recoverability and Usability 54
5.3 Maintainability 54
5.4 Safety 54

6 MINIMUM H/W & S/W REQUREMENT 55

REFERENCES 56

APPENDIX 57
LIST OF TABLES

CONTENTS Page No.

2.1 Consolidate View of Use Cases 10


6.1 Minimum Hardware & Software Requirement 55

LIST OF FIGURES

S.No DESCRIPTION Page


No.

2.1 Use Case of EAS 9


2.2 Activity Diagram-Login User 18
2.3 Activity Diagram-Registration of Seller/Buyer 19
2.4 Activity Diagram-Edit Seller/Buyer Profile 20
2.5 Activity Diagram-Remove Seller/Buyer Profile 21
2.6 Activity Diagram-Product Details 22
2.7 Activity Diagram-Product Conformation 23
2.8 Activity Diagram-Lot Preparation 24
2.9 Activity Diagram-Update Lot 25
2.10 Activity Diagram-Setup Auction 26
2.11 Activity Diagram-View Profile 27
2.12 Activity Diagram-Commodity Search 28
2.13 Activity Diagram-Generate Invoice 29
3.1 Solution Model 30
3.2 J2EE Realization Model for EAS 32
3.3 Net Realization Model for EAS 33
EXECUTIVE SUMMARY

This report documents the software modeling, analysis, architecture, and design of EAS
(Electronic Auction System), a tool for e-Auction that can be used by a buyers and sellers. UML
(Unified Modeling Language) has been used in EAS modeling. The key features of EAS
architecture and design are extensibility, reusability, robustness, and scalability. These features
have been achieved through the use of best practices in software engineering such as design
patterns.

This report is organized as follows. Section 2 is devoted to object oriented analysis of EAS. In
this section, the software requirements specification is presented first, followed by a detailed use-
case model, accompanied by a description of the use cases. Activity diagrams are presented next.
In Section 3, the discussion is centered on EAS architecture. A solution model, a technology
realization model, a J2EE realization model, and a .NET realization model are described. Section
4 presents the EAS interfaces with hardware, software and user interface. The emphasis in this
section is on the user interface which has developed with the help of PHP. Section 5 is
concentrate on other requirement such as performance, security, usability, maintainability and
safety.

1
1 OVERVIEW

1.1 Introduction

Transactions for goods and services via internet and other computer networks, or electronic
commerce (EC), have increased dramatically in recent years with progress in information
technology and expansion of the network infrastructure. The types of product involved in EC
transactions are still strongly biased toward electronic- and information-related hardware,
automobiles, and auto parts, which account for 84% of the total. However, increasing adoption of
EC can now be seen in industry as a whole, as shown by the remarkable growth of transactions
in raw materials, chemicals, textiles, food products, construction, industrial machinery, and other
sectors.
In these circumstances, a response to the EC needs of wholesale markets in India which
mainly handle fresh food and other perishables produce. It is believed that poor linkage in
marketing channels and poor marketing infrastructures are leading to high post harvest losses,
low competitiveness, low transparency and fluctuation in price. Hence, small proportion of
consumer money is reaching to the farmers. There is need to create modernization of wholesale
market in India by introducing advance technologies, beginning with efficient electronic auction
system.
These modern wholesale markets will provide the electronic auction system for perishables
produce and also there will be a provision of modern logistic facilities and services such as
display hall, cold storage, electronic weighing and electronic disseminated market information
through display panel. So farmers can get more benefit as compared to the present market.
The fundamental objective of electronic auction system is to improve the agriculture market
efficiency. By centralizing transactions of data at a single location, reducing the period for
transactions, and promote greater transparency and better price formation through a clearer
interplay of supply and demand.

1.2 Problem Area

At present wholesale market does not have adequate infrastructure facilities within the market
yard. Uncontrolled and wild way of utilization of space by traders or service providers create

2
extreme congestion in fruits and vegetable markets. Chaos is a common phenomenon at trading
places in fruits and vegetables since there is no single centralized auction system. Traders’ often
organize auctions at various places in a random manner and in a un sequential order. This
creates unnecessarily excessive user population pressure on market, which creates unhygienic
condition in the market. This discourages the civilized and educated people to go to market and
participate in the business.
Also there is hardly any facility/ infrastructure on post harvest handling, assembling, sorting,
grading, packing, transportation, quality certification, and labeling, pre-cooling, cold-store,
ripening chambers in fruits and vegetables markets. This leads to post harvest losses and low
price realization to the farmer.
The present system does not cope up with cultural change and technological advancements.
IT applications have opened various dimensions for networking of backward and forward
linkages, which will ensure transparency and efficiency.

The distribution of goods system is information on trends in production and consumption is


easily lost. The trading system of agricultural cooperatives, wholesalers, and middlemen has
important advantages for distribution, as the quantities of multiple products can be adjusted
to meet demand and products can be supplied quickly to multiple consumers, but on the
other hand, information may not be transmitted effectively at every stage.

In this background, Premium Farm Fresh Produce Ltd. (PFFPL) wants to setup Electronic
Auction System (EAS) for Wholesale Markets in India.

Release 1 of EAS will be based on the data collected from the Premium Farm Fresh
Produce Ltd. (PFFPL) and mainly intend not only to disseminate meaningful information
(general, from research projects) related to electronic auction system but also enable capturing of
relevant data from the buyers and sellers.

3
1.3 Objectives

¾ To study the present electronic auction system for wholesale markets and develop a
business case document w.r.t. India

¾ To develop a User Requirement Document (URD) that specifies the requirements which
the user expects in terms software w.r.t. electronic auction operations.

¾ To develop a software requirement specification (SRS) document having complete


description of the behavior of the software.

¾ To develop a prototype for electronic auction system

1.4 Scope

Stakeholder of EAS is PFFPL employees, buyers and sellers. PFFPL is going to develop the
software for the wholesale market (set up by PFFPL) on intranet. As a result the following
facility would be available on the Local Area Network (LAN) of wholesale market.

• The main function of EAS is to provide registration facility for incoming buyer and seller
in wholesale market.
• The EAS will provide a facility to set auction.
• The whole management could be controlled through admin interface through which the
clients and host system could be managed from anywhere.
• There will be different rights for different type of user.
• This EAS will help in management of documents related to seller and seller to the server.
• This EAS will provide a facility for buyers to place a bid on product.

4
1.5 Definitions

Intranet An intranet is essentially a small, internal version of the Internet--an


internal computer network designed specifically for efficient and easy
sharing and distribution of information, data, and applications.

Operator The person who will operate the software.

Admin Administrator of the Software

End User Any user using the software

Database A database is a collection of an organized data so that its contents can


easily be accessed, managed, and updated.

5
2 ANALYSIS EAS

Analysis is a process of identifying the conceptual items and properties necessary for a
solution to be both correct and proper. The analysis process is done through Requirements
Analysis phase. During the requirements analysis, reformulate and expand an informal set of
requirements into a more formal description. This transformation is done gradually through use
cases. Use cases offer a systematic and intuitive way to capture the functional requirements with
particular focus on the value added to each individual user or to each external system. Use cases
play a key role in driving the rest of the development work and that is the important reason for
their acceptance in most approaches to modern software engineering.

2.1 Software Requirements Specification

We expect EAS to have the following stakeholders:

1. Buyer(s)
2. Seller(s)
3. PFFPL employee (Admin/Auction officer)

The stakeholders’ requirements are captured below:

Admin/Auction Officer
ƒ Add new information, delete, edit the information related the system.
ƒ View information about the EAS.
ƒ Can delete the user or create the new user.
ƒ Can set the status of the work.
Employees
ƒ View information.
ƒ Edit information
ƒ Edit self profile
ƒ Search information
ƒ Upload documents on server
ƒ Issue the smart card for buyer and seller

6
Buyer
ƒ Register at wholesale market for participating in auction
ƒ Can place a bid on display product
ƒ View Bids
Seller
ƒ Register at wholesale market for participating in auction
ƒ Inward the product information with the help entry officer of wholesale market
ƒ Can cancel the auction with the help of Admin/Auction Monitor

2.2 Constraint

ƒ Only registered user (seller & Buyers) can participate in Auction


ƒ The EAS will be accessible all over the market

2.3 System Wide Requirement (Received)

The EAS will process exceptions in consistent fashion.


If the exception is a user error that can be corrected:
a. EAS displays error message with explanation of mistake.
b. EAS allows user to correct mistake without starting over.

If the exception is a rule violation that cannot be corrected:


1. EAS displays informational message explaining the constraint to the user.

Rules:
¾ Non-registered users can not participate in auction
¾ Any user – cannot delete information

7
2.4 Functional Requirement

A functional requirement defines a function of software or its component. A function is described is a


set of input, behavior and output. Here, Use cases method is using for capturing functional requirements.

2.4.1 Use Case Model


A use case model describes what the system does for each type of user and provides the
essential input for analysis, design, and testing. It is a top-level view of the system and shows
the actors, use cases, and their relationships. The actors are entities that interact with the system.
From an understanding of the stakeholders of the system, PFFPL have identified the following
actors: System Administrator, Employee, Buyer, and Selling.

The use cases are complete functionalities as perceived by an actor. In order to discover the
set of use cases that captures the functionality of the system.

8
2.4.2 Use Case Overview

Login

Logout

Entry Officer

Inward Product Details

Add /Register User System Administrator/Auction Officer


Give the product detail to entry officer

Issue Smart Card for Buyers/Sellers

Update User Information

Sellers
Remove User
Buyers

Lot Preparation

Set Up Auction (DU, EN & Com)

Accountant

Modify Auction Rule

Submit Bid

Close Auction
Billing Clerk

Auction Summary Report

User Summary Report

Security Officer

Generate Invoice

Generate Security Report

Fig 2.1: Use Case of EAS

9
The table below gives a consolidated view of the Use Cases. Detailed descriptions of the use cases are
given in the Use Case Specification section following this table.

S. Use Case ID Use Case Name Priority1 Stability2 Verifiability3


No.
1. UC-EAS-01 Login User Medium Stable Verifiable
2. UC-EAS-02 Add Buyers/Seller High Stable Verifiable
Details
3. UC-EAS-03 Update Seller/Buyer Low Stable Verifiable
Details
4. UC-EAS-04 Remove Seller/Buyer Low Stable Verifiable
details
5. UC-EAS-05 Add product details High Stable Verifiable
6. UC-EAS-06 Product Conformation High Stable N.A.
7. UC-EAS-07 Lot Preparation High Stable N.A.
8. UC-EAS-08 Setup Auction High Stable N.A.
9. UC-EAS-09 Modify Auction Rule Low Stable N.A.
10. UC-EAS-10 Submit Bid High Stable Verifiable
11. UC-EAS-11 Auction Summary Medium Stable N.A.
Report
12. UC-EAS-12 User Summary Report Medium Stable N.A.
13. UC-EAS-13 Generate Invoice High Stable N.A
14. UC-EAS-14 Generate Security High Stable N.A.
Report

Table 2.1 Consolidated Views of Use Cases

2.4.3 Use Case Specifications 
Use Case ID: UC-EAS-01 Use Case Name: Login User

Description: Enables user to login using user Id and password


Preconditions: User should have a registered user id and password
Post conditions: NA
Frequency of Use: High
Normal Course of • User click on the EAS icon
Events: • User enters user id and password & click submit option
• Home page will be displayed

Alternative Courses: None


Exceptions: • Username &Password are incorrect. The system take the use back to
the login page
Includes: None
Associated None
Requirements:

1 Priority: High, Medium or Low


2 Stability: Stable / Unstable
3 Verifiability: Verifiable / Not Verifiable

10
Use Case ID: UC-EAS-02 Use Case Name: Add Sellers/Buyers Details

Description: Use case enables user to Add Sellers/Buyers Details.

Pre-conditions: User should login the EAS and should be viewing Home page of EAS
Post conditions: Database has been updated with new value
Frequency of Use: Medium
Normal Course of • User opens the EAS
Events: • User login using user id and password & clicking submit option
• User is shown the home page
• EAS displays several options including Add Sellers/Buyers Details
• Clicking on Add Seller/Buyers Option will display a questionnaire
regarding the Seller/Buyers details to be filled by the Auction
Officer/System Administrator.

Alternative Courses: None


Exceptions: • If user is already registered. Display message” User already
registered”.
Includes: NA
Associated NA
Requirements:

Use Case ID: UC-EAS-03 Use Case Name: Update Sellers/Buyers Details

Description: Use case enables user to Update Sellers/Buyers Details.

Pre-conditions: User should login the EAS and should be viewing Home page of EAS
Post conditions: Database has been updated with new value
Frequency of Use: Medium
Normal Course of • User opens the EAS
Events: • User login using user id and password & clicking submit option
• User is shown the home page
• “View Profile” option is displayed for user to enter either ID or name or
location.
• User enters either one or all the three details and click on ‘Submit’
• User will get a response in form of display of list of Seller/Buyers
• Clicking on single Seller/Buyers will display his complete details.
• Seller/Buyers details can be updated by System Administrator/Auction
officer.
• Click on the update button.

Alternative Courses: None


Exceptions: • ID number is incorrect. Display message” User doesn’t exist”.
Includes: Links to go back for view profile option
Associated NA
Requirements:

11
Use Case ID: UC-EAS-04 Use Case Name: Remove Sellers/Buyers Details

Description: Use case enables user to Remove Sellers/Buyers Details.

Pre-conditions: User should login the EAS and should be viewing Home page of EAS
Post conditions: Database has been updated with new value
Frequency of Use: Low
Normal Course of • User opens the EAS
Events: • User login using user id and password & clicking submit option
• User is shown the home page
• “View Profile” option is displayed for user to enter either ID or name or
location.
• User enters either one or all the three details and click on ‘Submit’
• User will get a response in form of display of list of Seller/Buyers
• Select a particular seller/buyer and remove the profile by System
Administrator/Auction officer.
• Click on the remove button.
Alternative Courses: None
Exceptions: • ID number is incorrect. Display message” User doesn’t exist”.
Includes: Links to go back for Product Detail option
Associated NA
Requirements:

Use Case ID: UC-EAS-05 Use Case Name: Add Product Detail

Description: Use case enables user to enter product detail.

Pre-conditions: User should login the EAS and should be viewing Home page of EAS
Post conditions: Database has been updated with new value
Frequency of Use: High
Normal Course of • User opens the EAS
Events: • User login using user id and password & clicking submit option
• User is shown the home page
• User click on the Add product details opting
• User enters the seller ID and submit
• System will display the product details form for particular seller
• User enters the product detail
• User click on the submit button
• System will generate the unique lot number.
Alternative Courses: None
Exceptions: • ID number is incorrect. Display message” User doesn’t exist”.
• Mandatory product information is missing. Display message “please
enter the complete details”.
Includes: Links to go back for Product Detail option
Associated NA
Requirements:

12
Use Case ID: UC-EAS-06 Use Case Name: Product Conformation

Description: Use case enables user to enter product conformation.

Pre-conditions: User should login the EAS and should be viewing Home page of EAS
Post conditions: Database has been updated with new value
Frequency of Use: High
Normal Course of • User opens the EAS
Events: • User login using user id and password & clicking submit option
• User is shown the home page
• User click on the product conformation opting
• User enters the seller ID and submit
• System will display the product details which were entered in entry
gate.
• If any change in the product details user will have to select the change
button and enter the new details.
• User click on the submit button
Alternative Courses: None
Exceptions: • ID number is incorrect. Display message” User doesn’t exist”.
Includes: Links to go back for Product Detail option
Associated NA
Requirements:

Use Case ID: UC-EAS-07 Use Case Name: Lot Preparation

Description: Use case enables user to enter lot preparation.

Pre-conditions: User should login the EAS and should be viewing Home page of EAS
Post conditions: Database has been updated with new value
Frequency of Use: High
Normal Course of • User opens the EAS
Events: • User login using user id and password & clicking submit option
• User is shown the home page
• User click on the Lot Preparation opting
• User enters the details.
• User click on the submit button
Alternative Courses: None
Exceptions: NA
Includes: Links to go back for Product Detail option
Associated NA
Requirements:

13
Use Case ID: UC-EAS-08 Use Case Name: Setup Auction

Description: Use case enables user to setup auction.

Pre-conditions: User should login the EAS and should be viewing Home page of EAS
Post conditions: None
Frequency of Use: High
Normal Course of • User opens the EAS
Events: • User login using user id and password & clicking submit option
• User is shown the home page
• User click on the auction button
• User select the type of auction (DU,EN &COMBI)
• User select the product
• System display whole details of the product like variety, quantity,
grade, minimum, maximum price and also seller details name & ID.
• User click on the auction start button
• System will ask minimum and maximum bidding price
• User enters the price details and click ok
• Auction clock will start and price will increase/decrease according to
the type of auction.
Alternative Courses: None
Exceptions: • If user will not enter the minimum & maximum the system will display
the message “Please enter the Price”.
Includes: Links to go back for auction option
Associated NA
Requirements:

Use Case ID: UC-EAS-09 Use Case Name: Modify auction Rule

Description: Use case enables user to modify auction rule.

Pre-conditions: User should login the EAS and should be viewing Home page of EAS
Post conditions: None
Frequency of Use: Low
Normal Course of • User opens the EAS
Events: • User login using user id and password & clicking submit option
• User is shown the home page
• User click on the modify auction rule.
• User modifies the auction rule.
• User click on ok button.
Alternative Courses: None
Exceptions: NA
Includes: Links to go back for home page.
Associated NA
Requirements:

14
Use Case ID: UC-EAS-10 Use Case Name: Submit Bid

Description: Use case enables user to submit bid.

Pre-conditions: User should insert the smart card in bidding terminal.


Post conditions: Bid database has been updated with new value
Frequency of Use: High
Normal Course of • User inserts the smart card in bidding terminal then user is able to
Events: places a bid.
• User enters a bid through bidding terminal
• User enters a product quantity
Alternative Courses: None
Exceptions: NA
Includes: NA
Associated NA
Requirements:

Use Case ID: UC-EAS-11 Use Case Name: Auction Summary Report

Description: Use case enables user to auction summary report.

Pre-conditions: User should login the EAS and should be viewing Home page of EAS
Post conditions: None
Frequency of Use: Low
Normal Course of • User opens the EAS
Events: • User login using user id and password & clicking submit option
• User is shown the home page
• User click on the summary report
• User select auction summary report
• User enter the date or select the date
• User click on the get summary report
• System will display the auction summary report.
Alternative Courses: None
Exceptions: NA
Includes: Links to go back for Home Page
Associated NA
Requirements:

15
Use Case ID: UC-EAS-12 Use Case Name: User Summary Report

Description: Use case enables user to user summary report.

Pre-conditions: User should login the EAS and should be viewing Home page of EAS
Post conditions: None
Frequency of Use: Low
Normal Course of • User opens the EAS
Events: • User login using user id and password & clicking submit option
• User is shown the home page
• User click on the summary report
• User select user summary report
• User enter the name/id of seller and buyer
• User click on the get summary report
• System will display the auction summary report.
Alternative Courses: None
Exceptions: NA
Includes: Links to go back for Home Page
Associated NA
Requirements:

Use Case ID: UC-EAS-13 Use Case Name: Invoice

Description: Use case enables user to generate invoice.

Pre-conditions: User should login the EAS and should be viewing Home page of EAS
Post conditions: None
Frequency of Use: Low
Normal Course of • User opens the EAS
Events: • User login using user id and password & clicking submit option
• User is shown the home page
• User click on the invoice button
• User enter buyer name and date
• User click on the get invoice
• System will display the invoice.
Alternative Courses: None
Exceptions: NA
Includes: Links to go back for Home Page
Associated NA
Requirements:

16
Use Case ID: UC-EAS-14 Use Case Name: Security Reports

Description: Use case enables user to generate security reports.

Pre-conditions: User should login the EAS and should be viewing Home page of EAS
Post conditions: None
Frequency of Use: Low
Normal Course of • User opens the EAS
Events: • User login using user id and password & clicking submit option
• User is shown the home page
• User click on the security reports button
• User click on the get security reports
Alternative Courses: None
Exceptions: NA
Includes: NA
Associated NA
Requirements:

17
2.4.4 Activity Diagram

Activity diagrams describe the workflow behavior of a software/ system. The diagrams describe
the state of activities by showing the sequence of activities performed. Activity diagrams can show
activities that are conditional or parallel.

User System

Start

Not Valid
Varify & Validate
User Enters Usename, Password

Valid

User Submit Details Display Invalid Username or Password Display Home Page

End

Fig 2.2: Activity Diagram-Login User

18
User System

Start

Invalid
Varify & Validation
Display Home Page

User click on registration

Display Message "User Already Registered" Valid


Display Registration Page

Save the user details in database

User Enters Seller/buyer Details

System generate unique ID for seller/buyer


submit Details

Display seller/buyer details

End

Fig 2.3: Activity Diagram-Registration of Seller/Buyer

19
User System
Start

Display view profile page

Invalid Varify & Validation


User entres detail

Display "Profile does not exit"

Submit details

Valid

User click on edit profile Display the profile of seller/buyer

User edit the profile

Submit query Edit & save in the data base

End
Display message "Profile has been Edited"

Fig 2.4: Activity Diagram-Edit Seller/Buyer Profile

20
User System
Start

Display view profile page

Invalid
Varify & Validation
User entres detail

Display "Profile does not exist"

Submit details

Valid

User select a profile Display the profile of seller/buyer

click on remove Delete from the data base

End Display "profile Deleted"

Fig 2.5: Activity Diagram-Remove Seller/Buyer Profile

21
User System
Start

Home page
Invalid
Varify & Validation

User click on product detail tab


Display User ID Invalid

User enters seller ID

Submit the details Valid

Display the product detail page

User enters the product details

Submit the details Details save in the database

Generate a lot number

Display the details

Fig 2.6 Activity Diagram-Product Details

22
User System

Display Home Page

Invalid
Varify & Validation

User click on product conformation tab

User enter the seller ID


Valid

Submit the detail


Display the product details which were entered at entry gate

Details is correct
Varification of product details

Detail is incorrect

User select no change botton


User select the change button

User enter the new product details

Submit the details update and save in the database

Display the details

End

Fig 2.7: Activity Diagram-Product Conformation

23
User System

Display lot detail page

User click on the lot preparation Display the lot preparation form

User enters the details

submit the details Save in the database

End

Fig 2.8: Activity Diagram-Lot Preparation

24
User System

Start

Display lot details page

User click on the update lot preparation Display the lot details page

User enters the update details

Submit details Save in the database

End

Fig 2.9 Activity Diagram-Update Lot

25
User System

Display home page

User click on the Auction System display home page with auction clock

User select the product

User starts the auction System will ask the maximum & Minimum price

user enters peice

submit the price Related product information shown in auction

End
System decreases/increases the price according to auction

Fig 2.10: Activity Diagram-Setup Auction

26
User System

Display View Profile Page

Invalid
Verify & Validation

User enter the required detailes


Display profile does not exist

Submit Details

Valid

Display the profile of seller/buyers

End

Fig 11: Activity Diagram-View Profile

27
User System

Display Commodity Search Page

Invalid
Varify & Validate

User enter the detail


Display "Commodity does not exist"

Submit

Valid

Display the commodity details

End

Fig 2.12 Activity Diagram-Commodity Search

28
User System

Display Invoice Page

Invalid
Varify & Validation

User enter details

Display Invoice does not exist

Submit details

Valid

Display Invoice

Fig 2.13: Activity Diagram-Generate Invoice

29
3 ARCHITECTURE FOR EAS

Successful systems invariably need robust, scalable and flexible architectures. In this phase
the models have class diagrams which are organized into various packages, tiers and
components. The better this organization is, the more successful the system will be. The
architecture of EAS can be described at two different levels. In the first level is the technology
independent, model-driven diagram. In the second level is a technology realization of the
various components of the earlier model. We refer to the first model as the Solution Model, and
refer to the second model as the Technology Realization model.

3.1 Solution Model


Architectures of systems are known to be better in most features when they are multi-tiered.
The existence of multiple tiers allows the system to be highly modular and flexible. For this
reason, EAS will be designed to be a multi-tier system. It will have the following tiers:

• The Presentation Tier


• The Control Tier
• The Business Logic Tier
• The Data Handling Tier

Fig 3.1: Solution Model

30
The Web Presentation Tier: This tier will be designed to allow the user to access the services
offered by the system. The user will be allowed to perform a set of well-defined operations,
which achieves the ultimate business goal.

The Control Tier: This tier essentially choreographs the various activities of the system. It will
responsible for access control, right control, directing the requests to specific business logic
components or data handling components, ensuring the scalability of the system by creating
appropriate threads and pools of resources. This layer will also responsible for load balancing.

The Business Logic Tier: This is the cardinal layer of the system. The services that are
promised by the system will be actually performed here. The determinations of winners, bid
decrement and management of auctions, etc are some of the prominent functionalities of this tier.

The Data Handling Tier: This tier will responsible for handling all operations related to the
database(s) that store the information of the system. This tier is responsible for initializing
databases, maintaining the database connections, pooling them, manipulating databases, and
optimizing their performance.

3.2 J2EE (Java to Enterprise Edition) Realization Model

Figure 4.2 depicts the J2EE Realization Model for EAS.

Web Presentation Tier: The responsibilities of this tier will be achieved using Java Server
Pages (JSPs). This tier will offer an interface to the users which they use to interact with the
system.

Control Tier: This tier will be implemented using servlets and tag libraries. In case of using
Enterprise Java Beans at the lower levels, an Application Server would be necessary for these to
run. Otherwise a Web Server will be enough.

31
Business Logic Tier: This tier will perform its responsibilities using worker bean classes or
session beans.

Data Handling Tier: These tire will be contained plain jdbc (Java database connectivity)
handler classes, which manage the database.

Fig 3.2: J2EE Realization Model for EAS

32
3.3 .Net Realization Model

Figure 4.3 depicts the .NET Realization Model of EAS.

Web Presentation Tier: Here ASP.Net will be used instead of the JSP of J2EE.
Control and Business Logic Tiers: These will handled by .NET managed components like
COM, DCOM, COM+ etc.
Data Handling Tier: the Classes in this layer will realize using ADO.NET components.

Fig 3.3: .Net Realization Model for EAS

33
4 INTERFACES

4.1 Hardware Interface


1. Auction Display Panel
• 4 or more fields of information
• 4” high Alphanumeric display
• Serial Port
• Ethernet Port
• Steel Frame
• Built-in Power supply, Compact Design

2. Wireless Bidding Terminal (RC-5 transmitter)


• Buttons
• Indicator light for on & off
• Smart card reader. System will allow user to place a bid when user will
insert the smart card into the bid terminal.

3. Auction Master’s Console (Includes Computer system, audio connectivity Public Address system and
related hardware)
4. Auction Master’s Console (Includes Computer system, audio connectivity Public Address system and
related hardware)
5. Server System (Full set of all server hardware required for Auction Market)
6. Desktop Computer System (Full set of all Desktop computers required for Auction Market)
7. Smart Card for Buyers/Sellers
8. WLAN (Communication between mobile clock and LAN network)
• Access points – Antennas
• Radiographic network card

34
4.2 Software Interface

The software interfaces that will be required to be used for using EAS software are

Front End
The front-end is responsible for collecting input in various forms from the user. The front-end is
a kind of interface between the user and the back-end. Java/.Net can be used for development of
front end.

Back End
A back-end is a database that is accessed by users indirectly through an external application rather than
by application programming stored within the database itself or by low level manipulation of the data.
Oracle/MySQL can be use for backend database. MySQL is user for developing a prototype.

Server
A server is an application running on a computer that delivers a service. For example, a web server will
deliver web pages when requested by a browser (called client in this context).
• Apache tomcat sever : When J2EE platform will be used
• Internet Information Server (IIS): When .NET will be used

XAMPP server and PHP platform is used for developing EAS prototype.

35
4.3 User Interface

4.3.1 Login Page

First in case of log in screen of the user interface it displays only two field’s username and
password and the submit button

36
4.3.2 Home Page

37
4.3.3 Registration Page (Seller/Buyer)

38
4.3.4 Generate Identification Number Page

39
4.3.5 Product Registration Page

For product registration it is necessary to enter the seller ID in seller ID page. After that
user can able to access the product registration page.

4.3.5.1 Seller ID Page

40
4.3.5.2 Product Detail Form

41
4.3.5.3 View Product Detail

42
4.3.6 Verification of Product Detail

43
4.3.7 Update Product Detail

44
4.3.8 Pre Auction Page

45
4.3.9 Auction Setup Page

46
4.3.10 Invoice Form

47
4.3.11 View Invoice

48
4.3.12 Search Seller/ Buyer Profile

49
4.3.13 Search Result of Profile

50
4.3.14 Search Commodity

4.3.15 Search Result of Commodity

51
4.3.16 View Commodity Details

52
4.3.17 Lot Preparation

53
5 OTHER REQUIREMENTS

5.1 Performance Requirements


In EAS performance depends on many factors. There are some factors which are mentioned
below.
• Response Time: Response time is also a constraints in our system and its depend on the
LAN bandwidths and we will try to provide good facility to access the system.
• Concurrent User: This system will support as many as possible user with some amount
of user can request concurrently at the same time for accessing system when buyers place
a bid.
5.2 Security Recoverability and Usability
• Since all the data contained in the system are sensitive data such as seller/buyer
information, bid information, commodity information etc so for that there is a need to
provide some security or some access rights to different type of users so that we can
make it secure.
• Different type of users will use this software directly or indirectly in some context so we
will provide them to some access rights that will secure our system.
5.3 Maintainability
• The whole system shall be built in a modular fashion with some kind of
interdependencies between the modules. But each module can be updated independently
without causing any interference with other modules or the system itself. Proper
documentation will ensure that there will not be a problem for any person not of this team
to review and develop any module.
5.4 Safety
In EAS project the safety is major point so we provides some constraints that will keep
safe our system to violating from other system when it is working with other system or
environment and there is also need some testing facility that will also provide safeguard for
EAS. There will also some procedure that will ensure that the system is safe from user that is
using that system.

54
6 MINIMUM H/W AND S/W REQUIREMENT

Resources Requirement Performance and


For Presenters For Participants Reliability
Consideration
Internet network Cable, Wireless LAN Cable, Wireless LAN It is
connection system system Recommended for
Virtual Classroom
System
Platform Windows 98 or higher or Windows 98 or higher Recommended or
Linux or Linux there are some
issues about
service pack that
may be required
Processor Pentium II or higher Pentium II or higher Recommended
Memory At least 128MB RAM At least 128MB RAM
Display color Higher color for clarity Higher color for clarity
Display resolution Recommended
1024x768 1024x768
800x600 800x600 Marginal, and if
you want to
scroll large
content
Disk space Free space more than 50 Some amount of free Recommended
MB which is used for space to install some
installation of virtual useful software which
classroom software are related to Virtual
classroom Software

Table 6.1 Minimum Hardware & Software Requirement

55
REFERENCES

• Document on Operational and Working Guidelines for Premium Market, Adgaon, Nasik.

• Detail Project Report on Setup Terminal Markets for Perishable Commodities.

• Project Report developed by Mr. Saurabh Pandey on Electronic Auction System for Premium
Farm Fresh Produce Ltd.

• Business case and vision of EAS for wholesale markets in India developed for this particular
project.

• Case Study: Implementing a Web Based Auction System Using UML and Component-Based
Programming (http://www.computer.org/portal/web/csdl/doi/10.1109/CMPSAC.2002.1044554 ).

• Electronic Auction System for Fish, Looe Fish Market (http://www.looe-fish-


selling.co.uk/electronic_auction.htm)

• A report on Electronic Fish Auction developed by Mr. Crick Carleton, Nautilus Consultant
Ltd. Scotland (http://www.nautilus-consultants.co.uk/pdfs/final-1b.pdf )

• A research paper on Flexible and Secure Auction Architecture Using Trusted Hardware (I
http://www.eecs.berkeley.edu/~tygar/papers/SAM/sam-ejeta.pdf)
• Agent-Based Mobile Auctions: The Flea Market Scenario (http://ray.tk.uni-
linz.ac.at/~reinhard/iit04dubai.pdf)

• UML as a modeling tool for developing an Agent-Based Auction System


(http://repository.gunadarma.ac.id:8000/browse.php?nfile=313)

• Towards a Test-bed for Trading Agents in Electronic Auction Markets


(http://www.iiia.csic.es/~jar/papers/1998/aicom.pdf)

56
ABBREVIATIONS

ADO ActiveX Data Objects

COM Component Object Model

DCOM Distributed Component Object Model

EAS Electronic Auction System

EC Electronic Commerce

IIS Internet Information Server

J2EE Java to Enterprise Edition

JDBC Java Database Connectivity

JSP Java Server Page

LAN Local Area Network

PHP Hypertext Preprocessor

SRS Software Requirement Specifications

URD User Requirement Document

57

Das könnte Ihnen auch gefallen