Automation Process in Online Shopping

Automation Process in Online Shopping 1. INTRODUCTION Online Shopping 1.1 About The Project This project is developed for the automation process of shopping throw online i.e through web. In marchant module adding the catogories,products,itemSales, giving orders, stock maintenace, creating invoice (bill) for orders, shipping of items order given by customer. creation, details, and other transactions like automatic increment,decrement of stock, paid invoice(amount),shipping invoice And all other transactions for large scale whole sale or retail sales, very big shops, or organizations. This project mainly contains 3 modules like Marchant module, Customer module, and invoice module. In customer module customers will give orders for items which are being available in that shop. In our project that order is processed and details are stored in data base. In invoice module total bill for ordered items will be created. In case if the ordered items are not being shipped at a time then the pending order details will be processed and the bill for the pending order will be created. In Marchant Module products are being maintained in category wise and product wise, item wise and up to date stock will be maintained in computerized manner. And up to date order given by the customer through online web status will be shown with help of dynamic web pages by getting data from database. EXISTING SYSTEM In existing system every thing is manual like customer will go to shop manually and he/she selects items which are available in shop and the marchant will calculate the bill for products selected by the customer and then shipping process will take place. Existing System is manual, every thing we have to do manually displaying items Selecting items Billing process Shipping Problems in present system Could not synchronize the Outward information to shopping order details. No track of the complaints and replaced goods after ordering Order status is updated manually using Order Confirmation. Very high levels of effort for preparing invoices and dispatch related documents and routing them to relevant departments or locations and high levels of clerical activity on account of applicability of different customers and products. Increased levels of expectation from customers with respect to prompt delivery of items. Inability to accurately judge changing patterns of fast and slow moving items on account of large volumes of data, and inability to track goods in transit. Difficulties in handling customer queries pertaining to consignments in-transit and partial dispatches. Important orders not discriminated from others since all orders since all orders were processed on a FIFO basis-hence need to be able to prioritize and process orders on a preferential basis (for high value orders or important customers), if required. Increase in frequency of goods returned on account of damage leading to high stock levels of damaged goods in the factory. Discrepancy between ordered and invoiced quantities on account of either partial availability of stocks or clerical oversights. Insufficient checks in the current system for ensuring customer credit limits are not exceeded. Sales data not analyzed properly to streamline production volumes. This is primarily on account of varying sales patterns across the year and high volumes of transaction. Customers could communicate to the Sales people but no information is kept in track for future references. Marchant or Management couldnt not have any information regarding latest sales reports unless requested and taken it for Spreadsheet applications. Marchant or Management requires the Quality information updates against the complaints and quality measures and metrics, which the current system couldnt provide such facilities. The end user of this product is a departmental store where the application is hosted on the web and administrator maintains database.This application which is deployed at the departmental store will automate the following process. the customer details are appended to the customer database. The details of the items are brought forward from the database for customers view based on the selection through the menu. Database of all the products are products are updated at the end of the each transaction. 1. MODULE Marchant Module Marchant will enter into the next form by entering username,password in this login page,after entering into next page marchant will add new products, categories, different different items what are all the items available in that store,and if he wants he will modify the things,he will delete things And maintains everything by date wise. Enhancing stores update stores delete from stores Software and Hardware Requirements The following software and hardware are recommended for the company. Hardware Requirements: Processor : Pentium Speed : 233 MHz Monitor : samtron HardDisk : 4.2 GB RAM : 128 MB Software Requirements: Operating : SystemWindows NT Language : JAVA (JSP, JDBC).JDK 1.4 Backend : ORACLE 2.0 SYSTEM SPECIFICATION 2.1 Introduction 2.4 Advantages of the Proposed System Inter-Department Communication using Intranet Mailing Services (emails)Tracking the mails received from the customers as complaints and using them for appraisal and audit purpose purposes. Customized and adhoc reports for the MIS for decision-making. Order indent-automation from the direct sales dept. Shop Inventory Database updates. Stock in shop information Communication with the customers regarding the orders and complaints and tracking them for the future purposes. Application Portfolio It is recommended that the organization takes up the following four functional areas for automation Marchant department customer department Stores department Billing, shipping Information System The reasons for selecting the above are that firstly they directly address the problems enumerated. Secondly, together they forma cohesive set of well-integrated application with one system acting as the feeder system for the other. System Architecture DATA FLOW DIAGRAMS: A data flow diagram is a logical model of a system. The model does not depend on hardware, software and data structures of the organization. There is no physical implication in a data flow diagram. Because the diagram is a graphic picture of the logical system, it tends to be easy for every non-technical user to understand and thus serves as an excellent communication tool. Finally a data flow diagram is a good starting point for system design. To construct a data flow diagram it uses four basic symbols. They are given below. Rectangle: The above symbol is used to define source or destination of data. Circle or Rounded Corners Rectangle: The above symbols are defined to represent a process that transforms or modifies the data. 3.21 INTRODUCTION UML is a notation that resulted from the unification Of Object Modeling Technique and Object Oriented Software Technology .UML has been designed for broad range of application. Hence, it provides constructs for a broad range of systems and activities. An Overview of UML in five notations 1. use case diagrams Use cases are used during requirements elicitation and analysis To represent the functionality of the system.Use cases focus on the behaviour of the system from the external point of view.The actor are Outside the boundary of the system,whereas the use cases are inside the boundary of the system. 2. class diagrams Class diagrams to describe the structure of the system. Classes Are abstraction that specify the common structure and behaviour of a set Of objects. Class diagrams describe the system in terms of objects, classes, attributes, operations and their associations. 3. Sequence diagrams Sequence diagrams are used to formalize the behaviour of the system and to visualize the communication among objects. They are useful for identifying additional objects that participate in the use cases. A Sequence diagram represents the interaction that take place among these objects. 4. Statechart diagrams State chart diagrams describe the behaviour of an individual object as a number of states and transitions between these states. A state represents a particular set of values for an object. The sequence diagram focuses on the messages exchanged between objects, the state chart diagrams focuses on the transition between states. 5.Activity diagrams An activity diagram describes a system in terms of activities. Activities are states that represents the execution of a set of operations. Activity diagrams are similar to flowchart diagram and data flow. Screens of online shopping 3. REQUIREMENTS SPECIFICATION PURPOSE The purpose of â€Å"Online Shopping† is to evaluate the performance of the various products, maintain stock details, product details, and customer details of â€Å"very big shops†. SCOPE This document is meant for the use of the organization and also will be the basis for clarifications. Alterations will not be made without the permission of the organization. PRODUCT FUNCTIONS OVERVIEW Online Shopping is mainly designed for the big shops to automate the maintenance of stock, maintaining customer details, manipulating product details and maintaining the payment details. It also promotes in monitoring the marketing strategy to be implemented depending on the performance of the various products. 3.1 Requirements In system analysis the developer interacts with the customer/client and works with him in order to find out what he specifically needs. Later he sees the past system, which is in use, and tries to find out what is lacking in that system. This examination of past system is not mandatory. That helps the developer to dig in the problem of the client or the customer. System Analysis is the study of gathering and interpreting facts, diagnosing problems, and using the recommended improvements to the system. Analysis specifies what the system should do whereas design states how to accomplish the objective. System Analysis is comprised of following things. Identify the customers need. Feasibility study. Analyzing the system technically and economically. Resource allocation. Cost Estimations and Work schedule preparation. Defining the system, which forms the base of the following activities. The success of a system depends largely on how accurately a problem is defined, thoroughly investigated and properly carried out through the choice of solution. User need identification and analysis are concerned with the user needs rather than what the customer wants. This step is intended to help the user and the analyst understand the real problem rather than its symptoms. This package has been developed in order to overcome the difficulties encountered while using the manual system. Faster and timely generation of reports is another motivating factor for the development of this package. The following requirements are identified. 3.1.1 Functional Requirements Customer Order Processing New order (Order no auto generated). View Products in category Status. Log User Complaints. Order Search and Processing Status. Internal Mail. Merchants Inventory Processing Category wise prod Details. Department Orders. Internal Mails. Management Information System Processing Adhoc Report. Internal Mails. Inter office Memos. 3.1.2 User Interfaces: A LOGIN form is presented with three fields to be entered. When the Login button is pressed, based on the empid, department values in the login form, database the respective form gets displayed. After that the user can perform the required activities. 3.2.2 Analysis Objects 1. Interface Objects: The interface object (also known as Boundary Object) is responsible for controlling access to the Enterprise Java Beans tier from any client. This includes other server-side components, such as Servlets and Jsp pages.An excellent example of interface object is the controller servlets for the web applications MVC architecture. 2. Control Objects: Control objects provide services to the application. They model functionality that is not naturally associated with a particular entity or interface. Often, this is because more than one entity needs to be operated on at one time; an example might be determining if there is sufficient inventory to manufacture a product. Other times, it may be because a relevant entity was not identified in the model; an example might be charging someones credit card. 3. Entity Objects: Entity objects model those business objects that should maintain their state after the use case completes. Typically, this means that they represent data from the database. Some examples are Customer, product, and an order. Entity objects should be represented by entity beans in the implementation model. The Entity Objects: Customer Invoice Order Stock Product 3.3 INPUTS The following inputs are collected for proposed system during the requirements specification from the Industries. 1. Goods Inward Note (GIN) The factory receives this document from the factory along with the finished goods. It consists of the details of items received .The warehouse in charge is supposed to physically verify the stock received against this document. Discrepancies are to be noted on the GIN and send back to the factory. It is use to enter details into the Goods inward register. It is also used to update stock book on weekly basis. 2. Goods received Confirmation On receiving the goods the customer is supposed to send a letter or telephonically in form the receipt of the consignment. Having got this information, the relevant invoice from the in transit file is to be removed and destroyed is fixed format for this document. 3. Goods Returned Note This is prepared based on the information send by the direct customer or dealer on goods that have been damaged in transit. It contains the details of the damaged goods. A copy of this is sent to the order-processing department, anther copy to the quality control department and third is field in the GRN file. The GRN details are entered into the damaged goods ledger. 4. Order Company receives order from their direct customer and detailers. The dealers fill in the details on Flowells order form itself. The orders from the direct customers are transcribed on the regular format. Orders can be sent by one warehouse to another. They are used for checking the availability of the stock. They are serialized and then filled. In is used to check the availability of the required stock in stock book and the goods inward register. The order could be serviced completely, partially or pending as the case may be. 3.5 Outputs The following outputs are collected for proposed system during the requirements specification from the Shops. 1. Invoice Once an order (either direct customer order or the dealer order) gets serviced partially or fully, an invoice for the same needs to be prepared. Most of the details are picked up from the order itself .An order may have multiple invoices. The discount for special customers is worked out. The rate is got form the product rate file. A copy of the invoice is sent to the direct customer, dealer, in-transit file, invoice file. The invoice details are entered into the issue register. Once supplementary gets service partially or fully nil valued supplementary invoice for the same needs to be prepared. Most of the details are picked up from the supplementary order itself. A copy of the supplementary invoice is sent to the direct customer, dealer, in-tansit file, and supplementary invoice file. The supplementary invoice details are entered into the issue register. 2. Dispatch Instructions The invoice department picks up dispatch instructions for the invoices that are prepared from the order form. This they send to the dispatch department. They prepare a packing slip. This is a regular report being prepared, consisting of order that are pending as of a particular date. The details for this report are taken from the pending orders. 3. Weekly Stock Status Report This is another weekly report prepared giving the details of the stock of each product. The details are obtained from the stock book. This report is prepared on adhoc basis. Whenever the actual stock is compared with book stock, and discrepancies found, they are entered product wise in this report. 4. DESIGN SPECIFICATION 4.1 DATA DESIGN Data objects A data object is a thing about which you want to store information. It has independent existence and can be uniquely identified. The following data objects are derived for the system. Customer Order Product Invoice category Relationships A relationship is a named association between agent and customer entity or more than entities we say that relationship exists between clerk and customer entity type. Similarly a relation between a clerk entity type and a manager entity type. The following relationships are identified for the system. For instance let us take the objects CUSTOMER, CATEGORY,PRODUCT, ORDER ,BILL the following relationships are identified. Customer â€Å"places† an Order. Order â€Å"contains† Product. Product â€Å"dispatched to† Customer. The relationships between the remaining entities are as follows : Customer â€Å"receives† Invoice. Invoice â€Å"has† Product. E-R Diagram E-R Diagram as a method to represent a Data model and was developed by Chen (1976). The main focus of a Data Model is to identify the required data and show it diagrammatically, which is called Entity Relationship Diagram. Its popularly is attributed to its simplicity. It has a top-down design approach to decide the minimum data that we would like to store for a given information system. 4.2 Screens ONLINE SHOPPING SCREENS TESTING It is a process of establishing confidence that a program or system does what it is proposed of. Testing is the only way to assure the quality of software and it is an umbrella activity rather than a separate phase. This is an activity to be performed in parallel with the software effort and one that consists of its own phases of analysis, design, implementation, execution and maintenance. 5.1 Testing strategy 5.1.1 Unit Testing: This testing method considers a module as single unit and checks the unit at interfaces and communicates with other modules rather than getting into details at statement level. Here the module will be treated as a black box, which will take some inputs and generate output. Outputs for a given set of input combination are pre-calculated and are generated by the module. 5.1.2 Integration testing: Here all the pre-tested individual modules will be assembled to create the larger system and tests are carried out at system level to make sure that all modules are working in synchronous with each other. This testing methodology helps in making sure that all modules which are running perfectly when checked individually and are also running cohesion with other modules. For this testing we create test cases to check all modules once and then generated test combinations of test paths through out the system to make sure that no path is making its way into chaos. 5.1.3 Validation testing: Testing is a major quality control measure employed during software development. Its basic function is to detect errors. Sub functions when combined may not produce than it is desired. Global data structures can represent the problems. Integrated testing is a systematic technique for constructing the program structure while conducting the tests. To uncover errors that are associated with interfacing the objective is to make test modules and built a program structure that has been detected by design. In a non-incremental integration all the modules are combined in advance and the program is tested as a whole. Here errors will appear in an endless loop function. In incremental testing the program is constructed and tested in small segments where the errors are isolated and corrected. Different incremental integration strategies are top-down integration, bottom-up integration, regression testing. 5.1.4 High-order testing (a.k.a. System Testing) Modules are integrated by moving downwards through the control hierarchy beginning with main program. The subordinate modules are incorporated into structure in either a Breadth First manner or in a Depth First manner. This process is done in five steps: Main control module is used as a test driver and steps are submitted are all modules directly to main program. Depending on the integration approach selected subordinate is replaced at a time with actual modules. Tests are conducted. On completion of each set of tests another stub is replaced with the real module. Regression testing may be conducted to ensure that new errors have not been introduced. This process continues from step 2 until entire program structure is reached. In top down integration strategy decision making occurs at upper levels in the hierarchy and is encountered first. If major control problems do exists early recognitions is essential. If Depth First integration is selected a complete function of the software may be implemented and demonstrated. Some problems occur when processing at low levels in hierarchy is required to adequately test upper level steps to replace low-level modules at the beginning of the top-down testing. So no data flows upwards in the program structure. BOTTOM-UP INTEGRATION TESTING Begins construction and testing with automatic modules. As modules are integrated from the bottom-up, processing requirement for modules subordinate to a given level is always available and need for stubs is eliminated. The following steps implement this strategy: Low-level modules are combined in to clusters that perform a specific software sub function. A driver is written to coordinate test case input and output. Cluster is tested. Drivers are removed and moving upward in program structure combines clusters. Integration moves upward, the need for separate test drovers lesions. If the top-levels of the program are integrated top-down, the number of drivers can be reduced substantially and integration of clusters is greatly simplified. REGRESSION TESTING Each time a new module is added as a part of integration as the software changes. Regression testing is an actually that helps to ensure changes that do not introduce unintended behavior as additional errors. Regression testing may be conducted manually by executing a subset of all test cases and results for subsequent playback tools enables the software engineer to capture the test case and results for subsequent playback and compression. The regression suit contains different classes of test cases. 6. CONFIGURATION 7. FEATURES USED 7.1 About J2EE (Javaâ„ ¢ 2 Platform Enterprise Edition, v1.3) Today, more and more developers want to write distributed transactional applications for the enterprise and leverage the speed, security, and reliability of server-side technology. If you are already working in this area, you know that in todays fast-moving and demanding world of e-commerce and information technology, enterprise applications have to be designed, built, and produced for less money, with greater speed, and with fewer resources than ever before. To reduce costs and fast-track enterprise application design and development, the Javaâ„ ¢2 Platform, Enterprise Edition (J2EEâ„ ¢) technology provides a component-based approach to the design, development, assembly, and deployment of enterprise applications. The J2EE platform offers a multitiered distributed application model, the ability to reuse components, integrated Extensible Markup Language (XML)-based data interchange, a unified security model, and flexible transaction control. Not only can you deliver innovative customer solutions to market faster than ever, but your platform-independent J2EE component-based solutions are not tied to the products and application programming interfaces (APIs) of any one vendor. Vendors and customers enjoy the freedom to choose the products and components that best meet their business and technological requirements. Distributed Multitier Applications The J2EE platform uses a multitier distributed application model for both enterprise applications. Application logic is divided into components according to function, and the various application components that make up a J2EE application are installed on different machines depending on the tier in the multitier J2EE environment to which the application component belongs. The following Figure shows two multitier J2EE applications divided into the tiers described in the following list. The J2EE application parts shown in the Figure are presented in J2EE Components. Client-tier components run on the client machine. Web-tier components run on the J2EE server. Business-tier components run on the J2EE server. Enterprise information system (EIS)-tier software runs on the EIS server. Although a J2EE application can consist of the three or four tiers shown in Figure, J2EE multitiered applications are generally considered to be threetiered applications because they are distributed over three different locations: client machines, the J2EE server machine, and the database or legacy machines at the back end. Three-tiered applications that run in this way extend the standard two-tiered client and server model by placing a multithreaded application server between the client application and back-end storage. J2EE Architecture The required relationships of architectural elements of the J2EE platform are shown in Figure. Note that this figure shows the logical relationships of the elements; it is not meant to imply a physical partitioning of the elements into separate machines, processes, address spaces, or virtual machines.The Containers, denoted by the separate rectangles,are J2EE runtime environments that provide required services to the application components represented in the upper half of the rectangle. The services provided are denoted by the boxes in the lower half of the rectangle. For example, the Application Client Container provides Java Messaging Service (JMS) APIs to Application Clients, as well as the other services represented. All these services are explained below. The arrows represent required access to other parts of the J2EE platform. The Application Client Container provides Application Clients with direct access to the J2EE required Database through the Java API for connectivity with database systems, the JDBCTM API. Similar access to databases is provided to JSP pages and servlets by the Web Container, and to enterprise beans by the EJB Container. As indicated the APIs of the JavaTM 2 Platform, Standard Edition (J2SETM), are supported by J2SE runtime environments for each type of application component. J2EE Architecture Diagram J2EE Components J2EE applications are made up of components. A J2EE component is a self-contained functional software unit that is assembled into a J2EE application with its related classes and files and that communicates with other components. The J2EE specification defines the following J2EE components: Application clients and applets are components that run on the client. Java Servlet and JavaServer Pagesâ„ ¢ (JSPâ„ ¢) technology components are Web components that run on the server. Enterprise JavaBeansâ„ ¢ (EJBâ„ ¢) components (enterprise beans) are business Components that run on the server. J2EE components are written in the Java programming language and are compiled in the same way as any program in the language. The difference between J2EE components and â€Å"standard† Java classes is that J2EE components are assembled into a J2EE application, verified to be well formed and in compliance with the J2EE specification, and deployed to production, where they are run and managed by the J2EE server. J2EE Clients A J2EE client can be a Web client or an application client. Web Clients A Web client consists of two parts: dynamic Web pages containing various types of markup language (HTML, XML, and so on), which are generated by Web components running in the Web tier, and a Web browser, which renders the pages received from the server. A Web client is sometimes called a thin client. Thin clients usually do not do things like query databases, execute complex business rules, or connect to legacy applications. When you use a thin client, heavyweight operations like these are off-loaded to enterprise beans executing on the J2EE server where they can leverage the security, speed, services, and reliability of J2EE server-side technologies. Applets A Web page received from the Web tier can include an embedded applet. An applet is a small client application written in the Java programming language that executes in the Java virtual machine installed in the Web browser. However, client systems will likely need the Java Plug-in and possibly a security policy file in order for the applet to successfully execute in the Web browser. Web components are the preferred API for creating a Web client program because no plug-ins or security policy files are needed on the client systems. Also, Web components enable cleaner and more modular application design because they provide a way to separate applications programming from Web page design. Personnel involved in Web page design thus do not need to understand Java programming language syntax to do their jobs. Application Clients A J2EE application client runs on a client machine and provides a way for users to handle tasks that require a richer user interface than can be provided by a markup language. It typically has a graphical user interface (GUI) created from Swing or Abstract Window Toolkit (AWT) APIs, but a command-line interface is certainly possible. Application clients directly access enterprise beans running in the Automation Process in Online Shopping Automation Process in Online Shopping 1. INTRODUCTION Online Shopping 1.1 About The Project This project is developed for the automation process of shopping throw online i.e through web. In marchant module adding the catogories,products,itemSales, giving orders, stock maintenace, creating invoice (bill) for orders, shipping of items order given by customer. creation, details, and other transactions like automatic increment,decrement of stock, paid invoice(amount),shipping invoice And all other transactions for large scale whole sale or retail sales, very big shops, or organizations. This project mainly contains 3 modules like Marchant module, Customer module, and invoice module. In customer module customers will give orders for items which are being available in that shop. In our project that order is processed and details are stored in data base. In invoice module total bill for ordered items will be created. In case if the ordered items are not being shipped at a time then the pending order details will be processed and the bill for the pending order will be created. In Marchant Module products are being maintained in category wise and product wise, item wise and up to date stock will be maintained in computerized manner. And up to date order given by the customer through online web status will be shown with help of dynamic web pages by getting data from database. EXISTING SYSTEM In existing system every thing is manual like customer will go to shop manually and he/she selects items which are available in shop and the marchant will calculate the bill for products selected by the customer and then shipping process will take place. Existing System is manual, every thing we have to do manually displaying items Selecting items Billing process Shipping Problems in present system Could not synchronize the Outward information to shopping order details. No track of the complaints and replaced goods after ordering Order status is updated manually using Order Confirmation. Very high levels of effort for preparing invoices and dispatch related documents and routing them to relevant departments or locations and high levels of clerical activity on account of applicability of different customers and products. Increased levels of expectation from customers with respect to prompt delivery of items. Inability to accurately judge changing patterns of fast and slow moving items on account of large volumes of data, and inability to track goods in transit. Difficulties in handling customer queries pertaining to consignments in-transit and partial dispatches. Important orders not discriminated from others since all orders since all orders were processed on a FIFO basis-hence need to be able to prioritize and process orders on a preferential basis (for high value orders or important customers), if required. Increase in frequency of goods returned on account of damage leading to high stock levels of damaged goods in the factory. Discrepancy between ordered and invoiced quantities on account of either partial availability of stocks or clerical oversights. Insufficient checks in the current system for ensuring customer credit limits are not exceeded. Sales data not analyzed properly to streamline production volumes. This is primarily on account of varying sales patterns across the year and high volumes of transaction. Customers could communicate to the Sales people but no information is kept in track for future references. Marchant or Management couldnt not have any information regarding latest sales reports unless requested and taken it for Spreadsheet applications. Marchant or Management requires the Quality information updates against the complaints and quality measures and metrics, which the current system couldnt provide such facilities. The end user of this product is a departmental store where the application is hosted on the web and administrator maintains database.This application which is deployed at the departmental store will automate the following process. the customer details are appended to the customer database. The details of the items are brought forward from the database for customers view based on the selection through the menu. Database of all the products are products are updated at the end of the each transaction. 1. MODULE Marchant Module Marchant will enter into the next form by entering username,password in this login page,after entering into next page marchant will add new products, categories, different different items what are all the items available in that store,and if he wants he will modify the things,he will delete things And maintains everything by date wise. Enhancing stores update stores delete from stores Software and Hardware Requirements The following software and hardware are recommended for the company. Hardware Requirements: Processor : Pentium Speed : 233 MHz Monitor : samtron HardDisk : 4.2 GB RAM : 128 MB Software Requirements: Operating : SystemWindows NT Language : JAVA (JSP, JDBC).JDK 1.4 Backend : ORACLE 2.0 SYSTEM SPECIFICATION 2.1 Introduction 2.4 Advantages of the Proposed System Inter-Department Communication using Intranet Mailing Services (emails)Tracking the mails received from the customers as complaints and using them for appraisal and audit purpose purposes. Customized and adhoc reports for the MIS for decision-making. Order indent-automation from the direct sales dept. Shop Inventory Database updates. Stock in shop information Communication with the customers regarding the orders and complaints and tracking them for the future purposes. Application Portfolio It is recommended that the organization takes up the following four functional areas for automation Marchant department customer department Stores department Billing, shipping Information System The reasons for selecting the above are that firstly they directly address the problems enumerated. Secondly, together they forma cohesive set of well-integrated application with one system acting as the feeder system for the other. System Architecture DATA FLOW DIAGRAMS: A data flow diagram is a logical model of a system. The model does not depend on hardware, software and data structures of the organization. There is no physical implication in a data flow diagram. Because the diagram is a graphic picture of the logical system, it tends to be easy for every non-technical user to understand and thus serves as an excellent communication tool. Finally a data flow diagram is a good starting point for system design. To construct a data flow diagram it uses four basic symbols. They are given below. Rectangle: The above symbol is used to define source or destination of data. Circle or Rounded Corners Rectangle: The above symbols are defined to represent a process that transforms or modifies the data. 3.21 INTRODUCTION UML is a notation that resulted from the unification Of Object Modeling Technique and Object Oriented Software Technology .UML has been designed for broad range of application. Hence, it provides constructs for a broad range of systems and activities. An Overview of UML in five notations 1. use case diagrams Use cases are used during requirements elicitation and analysis To represent the functionality of the system.Use cases focus on the behaviour of the system from the external point of view.The actor are Outside the boundary of the system,whereas the use cases are inside the boundary of the system. 2. class diagrams Class diagrams to describe the structure of the system. Classes Are abstraction that specify the common structure and behaviour of a set Of objects. Class diagrams describe the system in terms of objects, classes, attributes, operations and their associations. 3. Sequence diagrams Sequence diagrams are used to formalize the behaviour of the system and to visualize the communication among objects. They are useful for identifying additional objects that participate in the use cases. A Sequence diagram represents the interaction that take place among these objects. 4. Statechart diagrams State chart diagrams describe the behaviour of an individual object as a number of states and transitions between these states. A state represents a particular set of values for an object. The sequence diagram focuses on the messages exchanged between objects, the state chart diagrams focuses on the transition between states. 5.Activity diagrams An activity diagram describes a system in terms of activities. Activities are states that represents the execution of a set of operations. Activity diagrams are similar to flowchart diagram and data flow. Screens of online shopping 3. REQUIREMENTS SPECIFICATION PURPOSE The purpose of â€Å"Online Shopping† is to evaluate the performance of the various products, maintain stock details, product details, and customer details of â€Å"very big shops†. SCOPE This document is meant for the use of the organization and also will be the basis for clarifications. Alterations will not be made without the permission of the organization. PRODUCT FUNCTIONS OVERVIEW Online Shopping is mainly designed for the big shops to automate the maintenance of stock, maintaining customer details, manipulating product details and maintaining the payment details. It also promotes in monitoring the marketing strategy to be implemented depending on the performance of the various products. 3.1 Requirements In system analysis the developer interacts with the customer/client and works with him in order to find out what he specifically needs. Later he sees the past system, which is in use, and tries to find out what is lacking in that system. This examination of past system is not mandatory. That helps the developer to dig in the problem of the client or the customer. System Analysis is the study of gathering and interpreting facts, diagnosing problems, and using the recommended improvements to the system. Analysis specifies what the system should do whereas design states how to accomplish the objective. System Analysis is comprised of following things. Identify the customers need. Feasibility study. Analyzing the system technically and economically. Resource allocation. Cost Estimations and Work schedule preparation. Defining the system, which forms the base of the following activities. The success of a system depends largely on how accurately a problem is defined, thoroughly investigated and properly carried out through the choice of solution. User need identification and analysis are concerned with the user needs rather than what the customer wants. This step is intended to help the user and the analyst understand the real problem rather than its symptoms. This package has been developed in order to overcome the difficulties encountered while using the manual system. Faster and timely generation of reports is another motivating factor for the development of this package. The following requirements are identified. 3.1.1 Functional Requirements Customer Order Processing New order (Order no auto generated). View Products in category Status. Log User Complaints. Order Search and Processing Status. Internal Mail. Merchants Inventory Processing Category wise prod Details. Department Orders. Internal Mails. Management Information System Processing Adhoc Report. Internal Mails. Inter office Memos. 3.1.2 User Interfaces: A LOGIN form is presented with three fields to be entered. When the Login button is pressed, based on the empid, department values in the login form, database the respective form gets displayed. After that the user can perform the required activities. 3.2.2 Analysis Objects 1. Interface Objects: The interface object (also known as Boundary Object) is responsible for controlling access to the Enterprise Java Beans tier from any client. This includes other server-side components, such as Servlets and Jsp pages.An excellent example of interface object is the controller servlets for the web applications MVC architecture. 2. Control Objects: Control objects provide services to the application. They model functionality that is not naturally associated with a particular entity or interface. Often, this is because more than one entity needs to be operated on at one time; an example might be determining if there is sufficient inventory to manufacture a product. Other times, it may be because a relevant entity was not identified in the model; an example might be charging someones credit card. 3. Entity Objects: Entity objects model those business objects that should maintain their state after the use case completes. Typically, this means that they represent data from the database. Some examples are Customer, product, and an order. Entity objects should be represented by entity beans in the implementation model. The Entity Objects: Customer Invoice Order Stock Product 3.3 INPUTS The following inputs are collected for proposed system during the requirements specification from the Industries. 1. Goods Inward Note (GIN) The factory receives this document from the factory along with the finished goods. It consists of the details of items received .The warehouse in charge is supposed to physically verify the stock received against this document. Discrepancies are to be noted on the GIN and send back to the factory. It is use to enter details into the Goods inward register. It is also used to update stock book on weekly basis. 2. Goods received Confirmation On receiving the goods the customer is supposed to send a letter or telephonically in form the receipt of the consignment. Having got this information, the relevant invoice from the in transit file is to be removed and destroyed is fixed format for this document. 3. Goods Returned Note This is prepared based on the information send by the direct customer or dealer on goods that have been damaged in transit. It contains the details of the damaged goods. A copy of this is sent to the order-processing department, anther copy to the quality control department and third is field in the GRN file. The GRN details are entered into the damaged goods ledger. 4. Order Company receives order from their direct customer and detailers. The dealers fill in the details on Flowells order form itself. The orders from the direct customers are transcribed on the regular format. Orders can be sent by one warehouse to another. They are used for checking the availability of the stock. They are serialized and then filled. In is used to check the availability of the required stock in stock book and the goods inward register. The order could be serviced completely, partially or pending as the case may be. 3.5 Outputs The following outputs are collected for proposed system during the requirements specification from the Shops. 1. Invoice Once an order (either direct customer order or the dealer order) gets serviced partially or fully, an invoice for the same needs to be prepared. Most of the details are picked up from the order itself .An order may have multiple invoices. The discount for special customers is worked out. The rate is got form the product rate file. A copy of the invoice is sent to the direct customer, dealer, in-transit file, invoice file. The invoice details are entered into the issue register. Once supplementary gets service partially or fully nil valued supplementary invoice for the same needs to be prepared. Most of the details are picked up from the supplementary order itself. A copy of the supplementary invoice is sent to the direct customer, dealer, in-tansit file, and supplementary invoice file. The supplementary invoice details are entered into the issue register. 2. Dispatch Instructions The invoice department picks up dispatch instructions for the invoices that are prepared from the order form. This they send to the dispatch department. They prepare a packing slip. This is a regular report being prepared, consisting of order that are pending as of a particular date. The details for this report are taken from the pending orders. 3. Weekly Stock Status Report This is another weekly report prepared giving the details of the stock of each product. The details are obtained from the stock book. This report is prepared on adhoc basis. Whenever the actual stock is compared with book stock, and discrepancies found, they are entered product wise in this report. 4. DESIGN SPECIFICATION 4.1 DATA DESIGN Data objects A data object is a thing about which you want to store information. It has independent existence and can be uniquely identified. The following data objects are derived for the system. Customer Order Product Invoice category Relationships A relationship is a named association between agent and customer entity or more than entities we say that relationship exists between clerk and customer entity type. Similarly a relation between a clerk entity type and a manager entity type. The following relationships are identified for the system. For instance let us take the objects CUSTOMER, CATEGORY,PRODUCT, ORDER ,BILL the following relationships are identified. Customer â€Å"places† an Order. Order â€Å"contains† Product. Product â€Å"dispatched to† Customer. The relationships between the remaining entities are as follows : Customer â€Å"receives† Invoice. Invoice â€Å"has† Product. E-R Diagram E-R Diagram as a method to represent a Data model and was developed by Chen (1976). The main focus of a Data Model is to identify the required data and show it diagrammatically, which is called Entity Relationship Diagram. Its popularly is attributed to its simplicity. It has a top-down design approach to decide the minimum data that we would like to store for a given information system. 4.2 Screens ONLINE SHOPPING SCREENS TESTING It is a process of establishing confidence that a program or system does what it is proposed of. Testing is the only way to assure the quality of software and it is an umbrella activity rather than a separate phase. This is an activity to be performed in parallel with the software effort and one that consists of its own phases of analysis, design, implementation, execution and maintenance. 5.1 Testing strategy 5.1.1 Unit Testing: This testing method considers a module as single unit and checks the unit at interfaces and communicates with other modules rather than getting into details at statement level. Here the module will be treated as a black box, which will take some inputs and generate output. Outputs for a given set of input combination are pre-calculated and are generated by the module. 5.1.2 Integration testing: Here all the pre-tested individual modules will be assembled to create the larger system and tests are carried out at system level to make sure that all modules are working in synchronous with each other. This testing methodology helps in making sure that all modules which are running perfectly when checked individually and are also running cohesion with other modules. For this testing we create test cases to check all modules once and then generated test combinations of test paths through out the system to make sure that no path is making its way into chaos. 5.1.3 Validation testing: Testing is a major quality control measure employed during software development. Its basic function is to detect errors. Sub functions when combined may not produce than it is desired. Global data structures can represent the problems. Integrated testing is a systematic technique for constructing the program structure while conducting the tests. To uncover errors that are associated with interfacing the objective is to make test modules and built a program structure that has been detected by design. In a non-incremental integration all the modules are combined in advance and the program is tested as a whole. Here errors will appear in an endless loop function. In incremental testing the program is constructed and tested in small segments where the errors are isolated and corrected. Different incremental integration strategies are top-down integration, bottom-up integration, regression testing. 5.1.4 High-order testing (a.k.a. System Testing) Modules are integrated by moving downwards through the control hierarchy beginning with main program. The subordinate modules are incorporated into structure in either a Breadth First manner or in a Depth First manner. This process is done in five steps: Main control module is used as a test driver and steps are submitted are all modules directly to main program. Depending on the integration approach selected subordinate is replaced at a time with actual modules. Tests are conducted. On completion of each set of tests another stub is replaced with the real module. Regression testing may be conducted to ensure that new errors have not been introduced. This process continues from step 2 until entire program structure is reached. In top down integration strategy decision making occurs at upper levels in the hierarchy and is encountered first. If major control problems do exists early recognitions is essential. If Depth First integration is selected a complete function of the software may be implemented and demonstrated. Some problems occur when processing at low levels in hierarchy is required to adequately test upper level steps to replace low-level modules at the beginning of the top-down testing. So no data flows upwards in the program structure. BOTTOM-UP INTEGRATION TESTING Begins construction and testing with automatic modules. As modules are integrated from the bottom-up, processing requirement for modules subordinate to a given level is always available and need for stubs is eliminated. The following steps implement this strategy: Low-level modules are combined in to clusters that perform a specific software sub function. A driver is written to coordinate test case input and output. Cluster is tested. Drivers are removed and moving upward in program structure combines clusters. Integration moves upward, the need for separate test drovers lesions. If the top-levels of the program are integrated top-down, the number of drivers can be reduced substantially and integration of clusters is greatly simplified. REGRESSION TESTING Each time a new module is added as a part of integration as the software changes. Regression testing is an actually that helps to ensure changes that do not introduce unintended behavior as additional errors. Regression testing may be conducted manually by executing a subset of all test cases and results for subsequent playback tools enables the software engineer to capture the test case and results for subsequent playback and compression. The regression suit contains different classes of test cases. 6. CONFIGURATION 7. FEATURES USED 7.1 About J2EE (Javaâ„ ¢ 2 Platform Enterprise Edition, v1.3) Today, more and more developers want to write distributed transactional applications for the enterprise and leverage the speed, security, and reliability of server-side technology. If you are already working in this area, you know that in todays fast-moving and demanding world of e-commerce and information technology, enterprise applications have to be designed, built, and produced for less money, with greater speed, and with fewer resources than ever before. To reduce costs and fast-track enterprise application design and development, the Javaâ„ ¢2 Platform, Enterprise Edition (J2EEâ„ ¢) technology provides a component-based approach to the design, development, assembly, and deployment of enterprise applications. The J2EE platform offers a multitiered distributed application model, the ability to reuse components, integrated Extensible Markup Language (XML)-based data interchange, a unified security model, and flexible transaction control. Not only can you deliver innovative customer solutions to market faster than ever, but your platform-independent J2EE component-based solutions are not tied to the products and application programming interfaces (APIs) of any one vendor. Vendors and customers enjoy the freedom to choose the products and components that best meet their business and technological requirements. Distributed Multitier Applications The J2EE platform uses a multitier distributed application model for both enterprise applications. Application logic is divided into components according to function, and the various application components that make up a J2EE application are installed on different machines depending on the tier in the multitier J2EE environment to which the application component belongs. The following Figure shows two multitier J2EE applications divided into the tiers described in the following list. The J2EE application parts shown in the Figure are presented in J2EE Components. Client-tier components run on the client machine. Web-tier components run on the J2EE server. Business-tier components run on the J2EE server. Enterprise information system (EIS)-tier software runs on the EIS server. Although a J2EE application can consist of the three or four tiers shown in Figure, J2EE multitiered applications are generally considered to be threetiered applications because they are distributed over three different locations: client machines, the J2EE server machine, and the database or legacy machines at the back end. Three-tiered applications that run in this way extend the standard two-tiered client and server model by placing a multithreaded application server between the client application and back-end storage. J2EE Architecture The required relationships of architectural elements of the J2EE platform are shown in Figure. Note that this figure shows the logical relationships of the elements; it is not meant to imply a physical partitioning of the elements into separate machines, processes, address spaces, or virtual machines.The Containers, denoted by the separate rectangles,are J2EE runtime environments that provide required services to the application components represented in the upper half of the rectangle. The services provided are denoted by the boxes in the lower half of the rectangle. For example, the Application Client Container provides Java Messaging Service (JMS) APIs to Application Clients, as well as the other services represented. All these services are explained below. The arrows represent required access to other parts of the J2EE platform. The Application Client Container provides Application Clients with direct access to the J2EE required Database through the Java API for connectivity with database systems, the JDBCTM API. Similar access to databases is provided to JSP pages and servlets by the Web Container, and to enterprise beans by the EJB Container. As indicated the APIs of the JavaTM 2 Platform, Standard Edition (J2SETM), are supported by J2SE runtime environments for each type of application component. J2EE Architecture Diagram J2EE Components J2EE applications are made up of components. A J2EE component is a self-contained functional software unit that is assembled into a J2EE application with its related classes and files and that communicates with other components. The J2EE specification defines the following J2EE components: Application clients and applets are components that run on the client. Java Servlet and JavaServer Pagesâ„ ¢ (JSPâ„ ¢) technology components are Web components that run on the server. Enterprise JavaBeansâ„ ¢ (EJBâ„ ¢) components (enterprise beans) are business Components that run on the server. J2EE components are written in the Java programming language and are compiled in the same way as any program in the language. The difference between J2EE components and â€Å"standard† Java classes is that J2EE components are assembled into a J2EE application, verified to be well formed and in compliance with the J2EE specification, and deployed to production, where they are run and managed by the J2EE server. J2EE Clients A J2EE client can be a Web client or an application client. Web Clients A Web client consists of two parts: dynamic Web pages containing various types of markup language (HTML, XML, and so on), which are generated by Web components running in the Web tier, and a Web browser, which renders the pages received from the server. A Web client is sometimes called a thin client. Thin clients usually do not do things like query databases, execute complex business rules, or connect to legacy applications. When you use a thin client, heavyweight operations like these are off-loaded to enterprise beans executing on the J2EE server where they can leverage the security, speed, services, and reliability of J2EE server-side technologies. Applets A Web page received from the Web tier can include an embedded applet. An applet is a small client application written in the Java programming language that executes in the Java virtual machine installed in the Web browser. However, client systems will likely need the Java Plug-in and possibly a security policy file in order for the applet to successfully execute in the Web browser. Web components are the preferred API for creating a Web client program because no plug-ins or security policy files are needed on the client systems. Also, Web components enable cleaner and more modular application design because they provide a way to separate applications programming from Web page design. Personnel involved in Web page design thus do not need to understand Java programming language syntax to do their jobs. Application Clients A J2EE application client runs on a client machine and provides a way for users to handle tasks that require a richer user interface than can be provided by a markup language. It typically has a graphical user interface (GUI) created from Swing or Abstract Window Toolkit (AWT) APIs, but a command-line interface is certainly possible. Application clients directly access enterprise beans running in the