1.

Document Outline :This document provides brief description about the following points: Introduction

This section provides an overview of purpose, scope, intended audience of proposed system. This section also includes references for any other document, acronyms and abstract of document. System Overview

This section provides general description of the software system including its functionality and matters related to the overall system and its design. Design Considerations

This section describes many of the issues which need to be addressed or resolved before attempting to devise a complete design solution. Assumptions and Dependencies

This section describes assumptions and dependency related to : Software and hardware Operating systems End-user characteristics Possible and/or probable changes in functionality General Constraints

This section describe any global limitations or constraints that have a significant impact on the design of the system's software like Hardware or software environment ,Performance requirements, Standards compliance , Memory , other capacity limitations and End-user environment. Goals and Guidelines This section describes goals, guidelines, principles, or priorities which dominate or embody the design of the system's software . Development Methods This section describe the method or approach used for this software design. If one or more formal/published methods were adopted or adapted, then include a reference to a more detailed description of these methods.

Page 1

Architectural Strategies This section describes any design decisions and/or strategies that affect the overall organization of the system and its higher-level structures. System Architecture

This section should provide a high-level overview of how the functionality and responsibilities of the system were partitioned and then assigned to subsystems or components. Policies and Tactics

This section describe any design policies and/or tactics which would not significantly affect the overall organization of the system and its high-level structures but which nonetheless affect the details of the interface and/or implementation of various aspects of the system. Detailed System Design

This section includes the UML diagrams like use case , sequence diagram , collaboration diagram related to time table generation. A use case diagram in the Unified Modeling Language (UML) is a type of behavioral diagram defined by and created from a Use-case analysis A sequence diagram in Unified Modeling Language (UML) is a kind of interaction diagram that shows how processes operate with one another and in what order. It is a construct of a Message Sequence Chart. Collaboration diagram expresses a single scenario like the sequence diagram, but in this case the focus is not on time but rather object instances Glossary

It is a list of difficult and specialized words with their definitions, placed at the end of document. Bibliography

It is the list of books and web sites which helped to prepare this document.

2. Document Description :Page 2

2.1 Introduction: The main objective of this project is to build an online market where people can buy, sell or advertise their products. It will provide a platform for companies to advertise their products and services. The basic idea is to change the conventional system of marketing which saves the time of customers by providing all the facilities through internet. Transaction security and product quality is the most important elements of online marketing in the customer-oriented factors. It would be a better solution to provide a platform for such needs. Looking at their aspects we are going to provide a place for such people. Purpose The Online Market web application is intended to provide complete solutions for vendors as well as customers through a single gateway using the internet as the sole medium. It will enable vendors to setup online shops, customer to browse through the shop and purchase them online without having to visit the shop physically. The administration module will enable a system administrator to approve and reject requests for new shops and maintain various lists of shop category This document is meant to delineate the features of Online Market, so as to serve as a guide to the developers on one hand and a software validation document for the prospective client on the other.

Scope Initial functional requirements will be: Secure registration and profile management facilities for Customers Browsing through the e-Market to see the items that are there in each category of products like Apparel, Kitchen accessories, Bath accessories, Food items etc. Adequate searching mechanisms for easy and quick access to particular products and services. Creating a Shopping cart so that customers can shop n no. of items and checkout finally with the entire shopping carts Regular updates to registered customers of the Online Market about new arrivals. Maintaining database of regular customers of different needs. Shop employees are responsible for internal affairs like answering client's queries online. Feedback mechanism, so that customers can give feedback for the product or service which they have purchased. Also facility rating of individual products by relevant customers. Adequate payment mechanism and gateway for all popular credit cards, and other relevant payment options, as available from time to time. Secure access of confidential data (users details). SSL can be used.
Page 3

24 X 7 availability Better component design to get better performance at peak time Advertisement space where it will effectively catch the customers attention and as a source of revenue.

References:

www.marketingterms.com

www.themarketingmentor.com O'Docherty, Object Oriented Analysis and Design Understanding, System Development with UML2.0, Wiley India. www.wikipedia.org

Abbreviations: EJB GUI HTML JIT JVM OOPL SQL XML TCP/IP HTTP HTTPS JAVA EE Enterprise Java Beans Graphical User Interface Hyper Text Markup Language Just In Time Java Virtual Machine Object Oriented Programming Language Structured Query Language Extensible Markup Language Transmission Control Protocol/Internet Protocol Hypertext Transfer Protocol Hypertext Transfer Protocol Secure Java Enterprise Edition 5

2.2 System overview: Online Market aims towards the vendors who want to reach out to the maximum cross-section of customer and common people who can be potential customer. This project envisages bridging the gap between the seller, the buyer and the vendor. Online Market should be userfriendly, quick to learn and reliable software for the above purpose. Online Market is intended to be a stand-alone product and should not depend on the availability of other software. The main users of the system are: User: Administrator
Page 4

Functions: The Administrator is the super user and has complete control over all the activities that can be performed. The application notifies the administrator of all shop creation requests, and the administrator can then approve or reject them. The administrator also manages the list of available product categories. The administrator can also view and delete entries in the list. User: Vendor Functions: Any user can submit a shop creation request through the application. When the request is approved by the Administrator, the requester is notified. The Vendor can add or remove items. The Vendor can decide to discontinue his shop and remove it. User: Customer Functions: A Customer can browse through the categories and choose products to place in a shopping cart. The shopping cart details can be viewed and items can be removed from the cart. To proceed with the purchase, the customer is prompted to login. Also, the customer can modify personal profile information (such as phone number and shipping address) stored by the application. The customer can also view the status of any previous orders, and cancel any order that has not been shipped yet. They can also sell the products after getting registered into the system. User: Guest Customer Functions: A guest Customer will be the one who can only browse the various categories of products which will be provided on the site but they cannot buy or sell it. If they find anything as per their requirement in future then they can do so by registering into the system. 2.3 Design Consideration: There are many aspects to consider in the design of a piece of software. The importance of each should reflect the goals the software is trying to achieve. Some of these aspects which are related to our project are: Some software quality factors which can be considered during design are listed here: Understandability The software is easily understandable to any layman if he/she goes through the software and has superficial knowledge of time table generation and any software engineer can understand the whole functionality of the software if he/she goes through documentation. Extensibility New capabilities can be added to the software without major changes to the underlying architecture. Fault-tolerance The software is resistant to and able to recover from component failure.
Page 5

 Completeness Presence of all constituent parts, with each part fully developed. The software calls a subroutine from an external library, the software package provide reference to that library and all required parameters are passed. All required input will be available when system asks for it. Conciseness The document as a whole is to the point and elaborated in section wherever necessary so that any technically sound person can understand the software. The coding done in the software contains minimum SLOC as software is rated according to KLOC which considers the property such as cost, efficiency, security etc. Portability The software built will be able to operate on multiple systems having different hardware and software specification with the basic constraints as will be specified after the software is well built. Modularity The resulting software comprises well defined, independent components. That leads to better maintainability. The components could be then implemented and tested in isolation before being integrated to form a desired software system. This allows division of work in a software development project. Packaging Printed material such as the box and manuals , matches the style designated for the target market .All compatibility information will be visible on the outside of the package. Maintainability Propensity to facilitate updates to satisfy new requirements. Thus the software product that is maintainable should be well-documented, should not be complex, and should have spare capacity for memory, storage and processor utilization and other resources. Reliability The software is able to perform a required function under stated conditions for a specified period of time. Security The software will be able to withstand hostile acts and influences. 2.3.1 Assumptions and Dependencies:
Page 6

The details related to the product, customer, payment and service transaction provided manually. Administrator is created in the system already. Roles and tasks are predefined.

Related software, hardware and operating system Online Market System will be executed on Intel/AMD based platforms and under following systems: MS Windows XP, MS Windows 2000/Vista/7. End-user characteristics: There are no special requirements for users because of online market system will be quite easy in apply. Only knowledge of English (all interface is going to be represented in this language) and ordinary skill of different web-browsers (Such as Netscape Navigator, MS Explorer and Opera) using are required. Possible and/or probable changes in functionality: All new customers requirements will be taken into account. But since Performances term is insignificant so probability of changes in functionality without shifting deadline is very low.
2.3.2 General Constraints:

Next items must be used to verify software: 1) For user home PC Hardware IBM-compatible PC with Pentium I processor and higher 50Mbytes free space on HDD 32Mbytes RAM Internet connection

Software
Page 7

MS Windows 95/98/2000/NT/XP MS IE, Netscape or Opera browsers with Java2 support

2) For Server Hardware IBM-compatible PC with Pentium and higher 256Mbytes RAM or higher 80Gbytes free space on HDD

3) For Online Market System interface

Interface will be implemented in English To each user status should be appropriated It should be implemented as web-based software

2.3.3 Goals and Guidelines: Main principle of creating Online Market is developing it according to customers requirements. It has to be available from the web and user could use it anywhere and anytime he need. 2.3.4 Development Method: The method or approach used for this software design is Incremental model. Incremental Model When the elements of waterfall model are applied in iterative manner, the result is the Incremental Model. In this, the product is designed, implemented, integrated and tested as incremental builds. This model is more applicable where software requirements are well defined and basic software functionality is required early. In incremental model, a series of releases called 'increments' are delivered that provide more functionality progressively for customer as each increment is delivered. The first increment is known as core product. This core product is used by customers and a plan is developed for next increment and modifications are made to meet the needs of the customer. The process is repeated.

Incremental software development model is applicable to project because:

Page 8

Software Requirements are well defined. The basic software functionality can be achieved early. Flexible Easier to test and debug during a smaller iteration. Easier to manage risk because risky pieces are identified and handled during its iteration.

Advantages: Delivers an operational quality product at each stage, but one that satisfies only a subset of the clients requirements. A relative small number of programmers/developers may be used. From the delivery of the first build, the client is able to perform useful work (portions of the complete product might be available to customers in weeks instead of waiting for the final product, compared waterfall, rapid prototyping model, which deliver only then the complete product is finished). Reduces the traumatic effect of imposing a completely new product on the client organization by providing a gradual introduction. There is a working system at all times. Clients can see the system and provide feedback. Progress is visible, rather than being buried in documents. Most importantly, it breaks down the problem into sub-problems, dealing with reduced complexity, and reduced the ripple effect of changes by reducing the scope to only a part of the problem at a time. Distributes feedback throughout the whole development cycle, leading to more stable artifacts. Disadvantages:

Page 9

2.4

Each additional build has somehow to be incorporated into the existing structure without degrading the quality of what has been build to date. Addition of succeeding builds must be easy and straightforward. The more the succeeding builds is the source of unexpected problems, the more the existing structure has to be reorganized, leading to inefficiency and degrading internal quality and degrading maintainability. The incremental models can easily degenerate into the build and fix approach. Design errors become part of the system and are hard to remove. Clients see possibilities and want to change requirements.
Architectural Strategies

In order to create good software, design constraints and other contingencies need to be addressed. In this section we will enumerate any and all considerations that must be made when creating this project. Must be coded efficiently enough to run well on provided server Hardware Client side code and/or web pages must be able to run efficiently on low end hardware. The database will be created and maintained in a way that makes it of reasonable and manageable size. Three-tier (layer) is a client-server architecture in which the user interface, business process (business rules) and data storage and data access are developed and maintained as independent modules or most often on separate platforms. The Architecture of Online Market is based on three-tier architecture. The three logical tiers are Presentation tier Java Web forms, Master Pages, Images. Middle tier Java classes. Data tier- Database The main reason for considering three-tier architecture for the Online Market is as follows: Flexibility: Management of data is independent from the physical storage support, Maintenance of the business logic is easier, Migration to new graphical environments is faster. If there is a minor change in the business logic, we dont have to install the entire system in individual users PCs.
Page 10

 Reusability: Reusability of business logic is greater for the presentation layer. As this component is developed and tested, we can use it in any other project and would be helpful for future use. Team Work: Team work is optimized. Security: More secured architecture since the client cannot access the database directly. Technologies to be used

In order to credit the tools we will use and to provide some insight as to what is needed to create a project like this, the list below will highlight all software and technologies used in order to create the project and what it was used for. Requisite Pro - Used to track progress on the project and to manage Requirements: MyEclipse - Integrated Development Environment used to write and debug code MySQL - Database management system MS Project - Project management software which is used to develop plans, assign resources, and create time lines RSA - Used to model our desired architecture for the project 2.5 System Architecture: Comparing to previous structures or architecture of functions or Actors, this part mostly focuses on the overall system design Architecture, which describes the internal necessary requirements and Structures during design process for system designers.

Page 11

In this figure, means related function or management implementations, and means related communication modules. Except for UI, testing and optimization, the on-line shopping mall System is divided into 4 major modules as below. Each of them implements a primary utility for either vendors or customers or both. 2.5.1 Subsystem Architecture: The system consists of following subsystem: Product Module: Some of its sub-modules (or functions) are exclusive for customers. This module requires designers to implement browse and search function for our web visitors and is supposed to be as friendly as possible and as reliable as possible. Then cart is necessary for users convenience and they should be able to modify any selected items in the cart list. The history record could function as a browse/search history review, similar product recommendation, etc.

Order Module:
Page 12

It contains three major roles, check-out, which connects customers, vendors, banks and administrators. Order information/status check, and order maintenance, which allows users to act (cancel/return etc.) on their placed orders to some extent. Payment Module: Provides payment methods (i.e. various bank cards or other commercial tools) and provides security mechanism Account & Authorization Module: This part creates and records users information in database with different priority and authority, which might allow customers or vendors to have their own account to buy or sell. Related architecture is very straight forward. Administrator authorization required. All the modules above should be able to connect to database system, normally execute basic SQL. 2.6 Policies and Tactics:
The software will be using javac, JIT(just in time) compilers and JVM interpreter and

MySql database. Coding guidelines and conventions:

Flexible, open and extensible time table generation process. Rapid time table generator ensuring data integrity with no loss of data. Uniform approach for generation of time table for different semester and branches. Easy to Install and Easy to Use tool with user friendly and intuitive GUI. Plans for ensuring requirements traceability: Requirement specifications and validation: First we prepare detailed software requirement specifications that include functional, technical architecture and details and then validate those requirements.

It includes:
Systematic methodology to prioritize requirements .

Creation, description, modification and progress tracking of project requirements. Classification of requirements, including the ability to have several independent classifications of the same requirement set. Specification of relationships between requirements, including requirement decompositions, dependencies, correlations, conflicts, etc. Maintenance of traceability links from requirements to information sources where these requirements have originated. Plans for testing the software:
Page 13

Run simple initial test plan that validates software installation. Check for allotment of faculty to each subject. Check that maximum 2 subjects will be allocated to each faculty. Report exceptions to client team Perform data validation Verify completion by checking the successful generation of time table.

Plans for maintaining the software:

Maintaining Application & its performance. Maintaining Data Integrity. Maintain the tables and their relationship. Maintaining software continuity

Maintaining the privacy and confidentiality of data. Maintain cost of software. How to build and/or generate the system's deliverables: Deliverables included need analysis, functional finding solutions, setup and testing. mapping, business process re-engineering,

2.7 Detailed System Design: 2.7.1 Use case description: A Use Case Diagram is a type of behavioral diagram defined by and created from a Use-case analysis. It is used to identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases." The Use case diagram shows which actors interact with each use case. The main purpose of a use case diagram is to show what system functions are performed for which actors. The elements used for this representation are

Actors
Page 14

Use Cases System Boundary Associations Use case description: A Use Case Diagram is a type of behavioral diagram defined by and created from a Use-case analysis. It is used to identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases." The Use case diagram shows which actors interact with each use case. The main purpose of a use case diagram is to show what system functions are performed for which actors. The elements used for this representation are

Actors Use Cases System Boundary Associations

Use Case Diagram for Customer and GuestUser:

Page 15

Diagram 2.7.1.1: Use Case diagram for Customer and GuestUser

1. Login:
Page 16

Brief description:This use case allows customer to access his account. Actors:Customer Basic Flow of Event:1. Customer clicks on the button or link to initiate the login process on Home page. 2. System prompts the Customer for his/her email and password. 3. System verifies the information. 4. System creates session cookie. 5. System displays account home page to the Customer. Alternative Flows Invalid Name/Password If, in the Basic Flow, the actor enters an invalid id and/or password, the system displays an error message. The customer can choose to either return to the beginning of the Basic Flow or cancel the login, at which point the use case ends. Pre conditions:None Post conditions:If the use case was successful, the customer is now logged into the system. If not, the system state is unchanged.
2. Edit profile

Brief description:This use case allows customer to edit his personal information Actors:Customer Basic Flow of Event:1. Customer first login to the system 2. Customer clicks the button or link to initiate the process to edit the profile. 3. System displays the account home page to the Customer. 4. Customer makes the changes in current information in his/her profile. 5. Customer clicks on the button to make and submit the changes.
Page 17

6. System verifies the changes. 7. System stores new changes. Alternative Flows: None Pre conditions:Customer must be logged into the system. Post conditions:The Customer has changed the profile details.
3. Search products:

Brief description:This use case allows user to search the product of his/her interest Actors:Customer GuestUser Basic Flow of Event:1. Customer/guest user open the search window for products. 2. Customer/guest user enter the product name in search box. 3. System will display the available products. Alternative Flows None Pre conditions:None Post conditions:None
4. Categorize products

Brief description:Page 18

This use case allows user to categorize the product of his/her interest Actors:Customer GuestUser Basic Flow of Event:1. Customer/guest opens the search product screen. 2. Customer/guest user enters the product name in search box. 3. Customer/guest user then selects the category according to his interest (company, price). 4. System will display the available products. Alternative Flows None Pre conditions:None Post conditions:None
5. View product specifications

Brief description:This use case allows user to see the product specifications. Actors:Customer GuestUser Basic Flow of Event:1. Customer/guest user opens the search product screen. 2. Customer/guest user enters the product name in search box. 3. System will display the available products. 4. Customer click on the view product specification button or link. 5. System will display the product specifications. Alternative Flows
Page 19

None Pre conditions:None Post conditions:None 6. Register Brief description:This use case allows a user to register into the system. Actors:GuestUser Basic Flow of Event:1. System prompts the customer to fill out his/her first name, last name, permanent address, current address, email address, their password etc. 2. GuestUser enters fields. 3. System validates the guest Users information. 4. System creates a new account for the guestUser. 5. System will send a e-mail notification to the respected e-mail id for verification. Alternative Flows None Pre conditions:None Post conditions:The guestUser registers and creates a new customer account with the system

7. Advertise products Brief description:This use case allows customer to advertise his products.
Page 20

Actors:Customer Basic Flow of Event:1. Customer first login to the system 2. Customer clicks the button or link to advertise. 3. System displays the advertise your product page to the Customer. 4. Customer enters the information regarding the advertisement. 5. System sends the advertisement request to the user. Alternative Flows: None Pre conditions:Customer must be logged into the system. Post conditions:The Customer advertisement request will be sent to the admin. 8. Shopping Brief description:This use case allows customer to purchase the items from the system(website). Actors:Customer Basic Flow of Event:1. Customer first login to the system 2. System will issue a shopping cart to the customer. 3. Customer can perform shopping. Alternative Flows: None Pre conditions:Customer must be logged into the system. Post conditions:Customer purchased his desired product from the system.
Page 21

9. Add item to cart Brief description:This use case allows customer to add items to the shopping cart Actors:Customer Basic Flow of Event:1. Customer first login to the system 2. Customer clicks the button or link in order to add to the cart with specified quantity. 3. System adds the item(s) to the cart. 4. System prompts the Customer to edit the quantity or remove the item from cart. 5. Customer confirms the items in the cart. 6. Customer returns to product listings.. Alternative Flows: None Pre conditions:Customer must be logged into the system. Post conditions:The Customer has added item(s) to the shopping cart. 10. Remove items from cart Brief description:This use case allows customer to remove items from the shopping cart Actors:Customer Basic Flow of Event:1. Customer first login to the system 2. Customer clicks the button or link in order to remove items from the cart. 3. System removes the item(s) from the cart. 4. System again prompts the Customer to edit the quantity or remove the item from cart. 5. Customer confirms the items in the cart. 6. Customer returns to product listings..
Page 22

Alternative Flows: None Pre conditions:Customer must be logged into the system. Post conditions:The Customer has removed item(s) to the shopping cart. 11. Review contents of cart Brief description:This use case allows customer to review the shopping cart Actors:Customer Basic Flow of Event:1. Customer first login to the system.

2. Customer clicks on the search product screen. 3. Customer click on the product in order to purchase the product and will click on the add to cart link. 4. The product in now added to the cart. 5. Customer will do purchasing and will add the products that he wanted to purchase. 6. Customer clicks the button or link in order to checkout the shopping cart when he finishes the shopping. 7. System displays the shopping cart. Alternative Flows: None Pre conditions:Customer must be logged into the system. Post conditions:The Customer has viewed shopping cart. 12. Purchase content of cart Brief description:Page 23

This use case allows customer to purchase the items of the shopping cart Actors:Customer Basic Flow of Event:1. Customer first login to the system 2. Customer clicks the button or link in order to purchase to the shopping cart. 3. System will display a form for shipping and creditcard details. 4. Customer fills the information. 5. System verifies the information. 6. System done the transaction. Alternative Flows: None Pre conditions:Customer must be logged into the system. Post conditions:The Customer has purchased the contens of the shopping cart. 13. Send feedback Brief description:This use case allows customer to send feedback to the admin. Actors:Customer Basic Flow of Event:1. Customer first login to the system 2. Customer clicks the button or link in order to send feedback. 3. System displays the feedback form. 4. Customer writes the feedback. 5. Customer submits the feedback form. 6. System sends the feedback to the admin. Alternative Flows: None
Page 24

Pre conditions:Customer must be logged into the system. Post conditions:Feedback will be sent to the admin. 14. Logout Brief description:This use case allows customer to logout from the system. Actors:Customer Flow of Event:1. Customer clicks button or link to initiate logout process. 2. System terminates the session cookie. 3. System displays home page. Pre conditions:Customer must be logged into the system. Post conditions:The Customer is logged out of the system.

Use Case Diagram for Vendor:

Page 25

Diagram 2.7.1.2: Use Case diagram for Vendor

1. Login: Brief description:This use case allows vendor to access his account.

Actors:Vendor
Page 26

Basic Flow of Event:1. Vendor clicks on the button or link to initiate the login process. 2. System prompts the Vendor for his/her email and password. 3. Vendor gives the information and submit it. 4. System verifies the information. 5. System creates session cookie. 6. System displays account home page to the Vendor. Alternative Flows Invalid Name/Password If, in the Basic Flow, the actor enters an invalid id and/or password, the system displays an error message. The vendor can choose to either return to the beginning of the Basic Flow or cancel the login, at which point the use case ends. Pre conditions:None Post conditions:If the use case was successful, the vendor is now logged into the system. If not, the system state is unchanged. 2. Make request for shop Brief description:This use case allows vendor to create a shop Actors:Vendor Flow of Event:1. Vendor first login to the system. 2. Vendor clicks the button or link in order to add the shop. 3. System will display a form for filling the shop details. 4. Vendor fills the information. 5. System verifies the information. 6. System forwards the request to the admin. Pre conditions:Vendor must be logged into the system. Post conditions:Page 27

Shop request has sent to the customer. 3. Advertise product Brief description:This use case allows vendor to advertise. Actors:Vendor Basic Flow of Event:1. Vendor first login to the system 2. Vendor clicks the button or link to advertise. 3. System displays advertiseProduct page to the Vendor. 4. Vendor enters the information regarding the advertisement. 5. System sends the advertisement request to the user. Alternative Flows: None Pre conditions:Vendor must be logged into the system. Post conditions:The Vendor advertisement request will be sent to the admin. 4. Manage product category Brief description:This use case allows vendor to add or remove the product categories from the shop. Actors:Vendor Flow of Event:1. Vendor must login first.
2. Vendor clicks the button or link in order to edit the category.

3. System will display the current categories in the shop. 4. Vendor can add or remove the category. 5. System will save the changes
Page 28

Pre conditions:Vendor must be logged into the system. Post conditions:Vendor has edited the category 5. Manage company profile Brief description:This use case allows customer to edit shops information Actors:Vendor Basic Flow of Event:1. Vendor first login to the system 2. Vendor clicks the button or link to initiate the process to edit the profile. 3. System displays the account home page to the Vendor. 4. System verifies the changes. 5. System stores new changes. Alternative Flows: None Pre conditions:Vendor must be logged into the system. Post conditions:The Vendor has changed the shops profile details.
6. Request for discontinue shop Brief description:-

This use case allows vendor to delete the shop from the system. Actors:Vendor Basic Flow of Event:1. Vendor first login to the system
Page 29

2. Vendor clicks the button or link to initiate the process to discontinue the shop. 3. System displays the discontinuous request page to the Vendor. 4. Vendor makes the request. 5. System forwards the request to the admin. Alternative Flows: None Pre conditions:Vendor must be logged into the system. Post conditions:The Vendor has deleted the shop. 7. Logout Brief description:This use case allows vendor to logout from the system. Actors:Vendor Flow of Event:1. Vendor clicks button or link to initiate logout process. 2. System terminates the session cookie. 3. System displays home page. Pre conditions:Vendor must be logged into the system. Post conditions:The Vendor is logged out of the system. Use Case Diagram for Admin:

Page 30

Diagram 2.7.1.3: Use Case diagram for Admin

1. Login: Brief description:This use case allows admin to access his account. After login he will be able to maintain user and Company profile, Approve/reject product requests and Advertisement, maintain product catalog,send email notifications and reply to customer feedback. Actors:Page 31

Admin Basic Flow of Event:1. Admin clicks on the button or link to initiate the login process. 2. System prompts the admin for his/her email and password. 3. System verifies the information. 4. System creates session cookie. 5. System displays account home page to the Customer Alternative Flows Invalid Name/Password If, in the Basic Flow, the actor enters an invalid id and/or password, the system displays an error message. The admin can choose to either return to the beginning of the Basic Flow or cancel the login, at which point the use case ends. Pre conditions:None Post conditions:If the use case was successful, the admin is now logged into the system. If not, the system state is unchanged.
2. Add/remove user:

Brief description:This use case allows admin to add a new user and maintain the existing user's profile. Actors:Admin Flow of Event:1. Admin must login first. 2. Enter the userid of customer/vendor of which he wants to see details. 3. Then he can view and edit details of that customer/vendor. Pre conditions:None Post conditions:None
Page 32

3. Add/remove shop:

Brief description:This use case allows admin to add or remove the companies (shops). Actors:Admin Flow of Event:1. 2. 3. 4. 5. Admin must login first. Enter the shopid of the shop he want to edit. Enter the details. Admin will submit the details. System will edit the shop profile.

Pre conditions:Admin should be logged into the system. Post conditions:None 4. Approve/reject product request: Brief description:This use case allows admin to either approve or reject the product request. Actors:Admin Flow of Event:1. Admin must login first. 2. Enter the productid of the requested product. 3. Admin will either approve or reject the product request. Pre conditions:Admin should be logged into the system and there should a product request in the inbox. Post conditions:None
Page 33

5. Approve Advertisement: Brief description:This use case allows admin to approve the display of Advertisement in the system. Actors:Admin Flow of Event:1. Admin must login first. 2. Enter the advertisementid for approval. 3. Admin will approve/reject the advertisement. Pre conditions:Admin must be logged into the system. Post conditions:None
6. Add/remove product catalog:

Brief description:This use case allows admin to add or remove the product categories in the catalog. Actors:Admin Flow of Event:1. Admin must login first.
2. Enter the categoryId.

3. Admin will add/remove the product category by click on add or remove button. Pre conditions:Admin must be logged into the system. Post conditions:None
Page 34

7. Send email notifications: Brief description:This use case allows admin to send e-mail notifications to the customer/vendor Actors:Admin Flow of Event:1. Admin must login first.
2. Enter the email text.

3. Admin will send email to customer and vendor. Pre conditions:Admin must be logged into the system. Post conditions:None 8. Reply to customer feedback: Brief description:This use case allows admin to reply for the customer feedback or complaint. Actors:Admin Flow of Event:1.
2.

Admin must login first.

Admin will see the complaints and feedback in feedback box.

3.

Admin will reply to the complaints and feedbacks.

Pre conditions:Admin must be logged into the system. Post conditions:None 9. Logout:
Page 35

Brief description:This use case allows admin to logout from the system. Actors:Admin Flow of Event:1. 2. 3. Admin clicks button or link to initiate logout process. System terminates the session cookie. System displays home page.

Pre conditions:Admin must be logged into the system. Post conditions:The admin is logged out of the system. 2.7.2 Sequence diagrams: The sequence diagram is used primarily to show the interactions between objects in the sequential order that those interactions occur. One of the primary uses of sequence diagrams is in the transition from requirements expressed as use cases to the next and more formal level of refinement. Use cases are often refined into one or more sequence diagrams. In addition to their use in designing new systems, sequence diagrams can be used to document how objects in an existing (call it "legacy") system currently interact.

Page 36

Diagram 2.7.2.1: Sequence diagram for Membership request by guestUser

Diagram 2.7.2.2: Sequence diagram for customer login to the system

Page 37

Diagram 2.7.2.3: Sequence diagram for searching the product

Page 38

Diagram 2.7.2.4: Sequence diagram for advertisement request by the user

Page 39

Diagram 2.7.2.5: Sequence diagram for shopping cart bill.

Page 40

Diagram 3.7.2.6: Sequence diagram for shopping cart issue to customer

Page 41

Diagram 2.7.2.7: Sequence diagram for advertisement request by the vendor

Diagram 2.7.2.8: Sequence diagram for shop request by the vendor

Page 42

Diagram 2.7.2.9: Sequence diagram for adding new category by the vendor

Page 43

Diagram 2.7.2.10: Sequence diagram for adding new product by the vendor

2.7.3 Collaboration diagrams: A collaboration diagram, also called a communication diagram or interaction diagram, is an illustration of the relationships and interactions among software objects in the Unified Modeling Language (UML).
The difference between sequence diagrams and collaboration diagrams is that

collaboration diagrams emphasize more on the structure than the sequence of interactions.
Within sequence diagrams the order of interactions is established by vertical positioning

whereas in collaboration diagrams the sequence is given by numbering the interactions.

Page 44

Diagram 2.7.3.1: Collaboration diagram for Membership request by guestUser

Diagram 2.7.3.2: Collaboration diagram for customer login to the system

Page 45

Diagram 2.7.3.3: Collaboration diagram for searching the product

Diagram 2.7.3.4: Collaboration diagram for advertisement request by the user

Diagram 2.7.3.5: Collaboration diagram for shopping cart bill.

Page 46

Diagram 2.7.3.6: Collaboration diagram for shopping cart issue to customer

Diagram 2.7.3.7: Collaboration diagram for advertisement request by the vendor

Page 47

Diagram 2.7.3.8: Collaboration diagram for shop request by the vendor

Diagram 2.7.3.9: Collaboration diagram for adding new category by the vendor

Page 48

Diagram 2.7.3.10: Collaboration diagram for adding new product by the vendor

2.7.4 Class Diagram: In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among the classes.

Page 49

Diagram 2.7.4.1: Class diagram

2.8 Glossary: DBMS

A database management system (DBMS) is designed to manage a large body of information. Data management involves both defining structures for storing information and providing mechanisms for manipulating the information. GUI

An interface for issuing commands to a computer utilizing a pointing device, such as a mouse,
Page 50

that manipulates and activates graphical SQL

SQL is a database computer language designed for managing data in relational database management systems (RDBMS). HTML

Hypertext markup language: a set of tags and rules for using them in developing hypertext documents. JIT

In the Java programming language and environment, a just-in-time (JIT) compiler is a program that turns Java bytecode into instructions that can be sent directly to the processor. JVM

A Java virtual machine (JVM), an implementation of the Java Virtual Machine Specification, interprets compiled Java binary code for a computer's processor so that it can perform a Java program's instructions. SLOC

Source lines of code (SLOC) is a software metric used to measure the size of a software program by counting the number of lines in the text of the program's source code. UML

UML is the abbreviation of unified modeling language.It is standardized general purpose modeling language in the field of software engineering created by object management group.It includes a set of graphic notations to create visual models of software. Policies: A policy is typically described as a principle or rule to guide decisions and achieve rational outcome(s). The term is not normally used to denote what is actually done, this is normally referred to as either procedure or protocol. Whereas a policy will contain the 'what' and the 'why', procedures or protocols contain the 'what', the 'how', the 'where', and the 'when'. Policies. Use case diagram A use Case Diagram is a type of behavioral diagram defined by and created from a Usecase analysis. It is used to identify the primary elements and processes that form the system. Tactics It is defined as near term actions taken to solve specific problems or accomplish specific goals. Sequence diagram
Page 51

A sequence diagram shows a particular behavior sequence of the use case. It shows sequence of messages, not their exact timing. It is used to show the interaction of a system with its actor to perform all or part of use case. Collaboration diagram In collaboration diagram the interaction is drawn on what is essentially a fragment of a class or object diagrams. Since the diagram has no time dimension the order in which messages are sent. References:Web references:
www.wikipedia.org www.ispirer.com www.databaseanswers.org www.w3schools.com

www.algorithm.co.il 2.9 Bibliography: Elmasri, Navathe, Fundamentals Of Database Systems, Addision Wesley.

Michael Blaha and J. Rumbugh, Object oriented Modeling and design with UML, Pearson Education. ODocherty, Object Oriented Analysis and Design Understanding, System Development with UML2.0, Wiley India. Korth, Silbertz, Sudarshan, Database Concepts, McGraw Hill. Software project Management from concept to development Black Book by Kieron Conway, Dreamtech Press.

Page 52