26-02-2010, 04:23 PM
[attachment=2447]
ONLINE WEBSTORE
PROJECT REPORT Submitted by
SIJO.T.K MIDHUN.M JESMON JOSEPH
ABSTRACT
Online WebStore is a site which has the capability of creating shops for different users and providing them the needed supply and managing their business. Here mainly two sorts of users are logging in one category is the one who needs to start shops and the other category is the normal users who wants to have some shopping.
Online WebStore has to handle both the types of users. This site is capable of handling many numbers of stores. Each shop would be owned by different shop owners. This site would act as shopping complex, where we know people come and buys the space for their shops and making their business.
Online WebStore would be managed by an administrator. Thus there would be three different class users logging to the site, one the shop owners,then the regular customers for shopping, and the administrator who controls the whole process. It is the job of the administrator to allocate space for the shop owners for their business and monitor the whole process.
Online WebStore consist of a common godown which is handled by the administrator. Each shop in the site would be provided with individual spaces to store these goods. The administrator has to give goods to the different shop owners on their demand from the common godown , and he has to track the business going with in each shop.
When a user comes and log in to the site as a new shop owner a database would be created for that user. The shop owner has to pay some amount to buy the space for the shop. He will also remit some amount to site owner for purchasing goods to his shop. The administrator will give the goods for the common godown. When a customer comes in to the site he has freedom to visit each shop in the site.
LIST OF TABLES
Tables Page
9.1 REGISTRATION 40
9.2 VENDORENTRY 40
9.3 MAINGROUPENTRY 41
9.4 SUBGROUPENTRY 41
9.5 PHOTOUPLOAD 42
9.6 PURCHASEDETAILS1 42
9.7 PURCHASEDETAILS2 42
LIST OF FIGURES
Figure Page
10.1 Context diagram 43
12.1 Admin Level 0 DFD 43
13.1 Vendor Level 0 DFD 44
10.1 Visitor Level 0 DFD 44
10.2 Admin Level 1 DFD 45
10.3 Vendor Level 1 DFD 45
10.4 Visitor Level 1 DFD 46
10.5 Admin Level 2 DFD 46
10.6 Vendor Level 2 DFD 47
10.7 Visitor Level 2 DFD 47
CHAPTER 1 INTRODUCTION
ABOUT THE PROJECT
Online WebStore is a site which has the capability of creating shops for different users and providing them the needed supply and managing their business. Here mainly two sorts of users are logging in one category is the one who needs to start shops and the other category is the normal users who wants to have some shopping.
Online WebStore has to handle both the types of users. This site is capable of handling many numbers of stores. Each shop would be owned by different shop owners. This site would act as shopping complex, where we know people come and buys the space for their shops and making their business.
Online WebStore would be managed by an administrator. Thus there would be three different class users logging to the site, one the shop owners,then the regular customers for shopping, and the administrator who controls the whole process. It is the job of the administrator to allocate space for the shop owners for their business and monitor the whole process.
Online WebStore consist of a common godown which is handled by the administrator. Each shop in the site would be provided with individual spaces to store these goods. The administrator has to give goods to the different shop owners on their demand from the common godown , and he has to track the business going with in each shop.
When a user comes and log in to the site as a new shop owner a database would be created for that user. The shop owner has to pay some amount to buy the space for the shop. He will also remit some amount to site owner for purchasing goods to his shop. The administrator will give the goods for the common godown. When a customer comes in to the site he has freedom to visit each shop in the site.
CHAPTER 2 SYSTEM ANALYSIS
2.1 STUDY OF EXISTING SYSTEM
In normal shopping the customer has to go to shopping center for purchase. It causes wastage of time. More over the shopkeeper's may not display verities of items, which the customer wants.
2.2 PROPOSED SYSTEM
In online webstore we can allocate space for starting our business very easily. We can do it from our home itself. The user can purchase the products from his home itself according to information by given by him. The user can feel the atmosphere of real shopping complex.In this project; we mainly used three modules admin module, vendor module, viditor module.
2.3 FEASIBILITY STUDY
All projects are feasible when given unlimited resources and infinite time. It is both necessary and prudent to evaluate the feasibility of a project at the earliest possible time. A feasible study is not warranted for system in which economic justification is observed, technical risk is low, few legal problems are expected and no reasonable alternative exists. An estimate is made of whether the identified user needs may be satisfied using our recent software and hardware technologies. The study will decide if the proposed system will be cost effective, from the business point of view and it can be developed in the existing budgetary constraints. The feasibility study should be relatively sharp ad quick. The gesture should inform the decision of whether to go ahead with a more detailed analysis.
Feasibility study may be documented as a separated report to higher officials of the top-level management and can be included as appendices to the system specification. Feasibility and risk analysis is detailed in many worries. If there is more project risk then the feasibility of producing the quality software is reduced. The study is done in three phases
2.3.1 Operational Feasibility
2.3.2 Technical Feasibility
2.3.3 Economical Feasibility
2.3.1 Operational Feasibility
Proposed projects are beneficial only if they can be turned into information systems that will meet the organizations operating requirements. Simply stated, the test of feasibility asks if the system will work when it is developed and installed. Are there any major barriers to implementations Is there sufficient support for the project from the management Are current business methods acceptable to the users Have the users been involved in the planning and development of the project Will the proposed system cause any harm
The purpose of the operational feasibility study is to determine whether the new system will be used if it is developed and installed. And whether there will be resistance from users that will undermine the possible application benefit.
In the proposed System named Online Webstore the operational feasibility study is performed with the help of the users of the system and the management. The first challenge was whether the system meets the organizational requirement. This is checked by the system requirement collected from the users and the management and the operational feasibility proved that the system is capable to meet its functional requirements.
During the operational feasibility study the proposed system, is checked whether it can run with universal standards. All the business methods implemented in the system is selected according to increase the user acceptance.
There was no difficulty in implemented the software and proposed system is so effective, user friendly, functionally reliable so that the users in the company will find that the new system reduces the hard steps.
2.3.2 Technical Feasibility
The technical feasibility study is a study of function, performances and constraints and improve the ability to create an acceptable system .Technical feasibility is frequently the most difficult area to achieve at the stage of product engineering process. Considering that are normally associated with the technical feasibility include
> Development risk
> Resource availability
> Technology
In the proposed system named Online Webstore the technical feasibility study is conducted by considering the risk related to developing the system, the resources available to develop the system and the availability of the technology to develop the system. The development risk considered the factors like whether the system can implement using existing technology and the design of the system can run on the real environment. The resource availability checks the availability of resources like time, human, hardware etc. The technology using to implement the system is selected according to the technical feasibility study. The technical feasibility study on the technology found that it can implement all the functional requirements of the proposed system. The technology selected according to accept the system globally and the development of the system according to the universal standards.
Technical feasibility study of Online Webstore covered the hardware as well as the software requirements. The scope was whether the work for the project is done with the current equipments and the existing software technology has to be examined in the feasibility study. The outcome was found to be positive.
2.3.3 Economical Feasibility
A cost evaluation is weighted against ultimate income or benefit derived from the developed system or product. Economic justification is generally the "Bottom line" consideration that includes cost benefit analysis, long term corporate income strategies, impact on other profit centers or products, cost of resources needed for development and potential market growth. When compared to the advantage obtained from implementing the system its cost is affordable. Also the system is designed to meet the modifications required in the future. Therefore most of the modifications can be done without much re-work.
The economical feasibility of the Online Webstore is checked and accepted by both the users and the management of the organization. Since the Online Webstore has to deals with sensitive data like the software codes of organization the economical feasibility proved that it is economical and it can help the organization to avoid financial disaster due to the lose of data. Since Online Webstore is developed using the available resources in the organization it doesn't added any financial liabilities to the organization. Since cost input for the software is almost nil the output of the software is always a profit. Hence the economical feasibility study of Online Webstore found that the system is economically feasible.
2.4 DATA FLOW DIAGRAMS
Data Flow Diagram is the graphical description of the system's data and how the processes transform the data. Data Flow diagram depicts information flow, the information flow and the transforms that are applied as data move from the input to output. It is the starting point of the design phase that functionally decomposes the requirement specifications down to the lowest level of details. Thus a DFD describes what data flows (logical) rather than how they are processed.
Unlike detailed flowchart, Data Flow Diagrams do no supply detailed description of the modules but graphically describes a system's data and how the data interacts with the system. To construct a Data Flow Diagram, we use
Arrows
Circles
Open End Box Squares
An arrow identifies the dataflow in motion. It is a pipeline through which information is flown like the rectangle in the flowchart. A circle stands for process that converts data into information. An open-ended box represents a data store, data at rest or a temporary repository of data. A square defines a source or destination of system data.
Rules for constructing a Data Flow Diagram
> Arrows should not cross each other.
> Squares, circles and files must bear names.
> Decomposed data flow squares and circles can have same names.
> Choose meaningful names for data flow
> Draw all data flows around the outside of the diagram.
2.5 SYSTEM REQUIREMENT SPECIFICATION
Requirement analysis can be defined as a detailed study of various operations performed by a system and their relationship within and outside of the system. One aspect of the analysis is designing the boundaries of the system and determining whether or not a candidate system should other related systems. During analysis data are collected on the available files, decision points and transactions handled by the present system. The common tools used in the analysis phase are Data Flow Diagram, interviews and on site observations.
We can say Analysis as the process of taking known facts concerning a system, breaking these into their elements and establishing logical relationships between the laments, with objective of producing a specification of requirements. Analysis can be done in a disciplined way, using appropriate tools in all stages of the project. During fact-finding, the use of standard forms will help to ensure that nothing conflicts or is omitted. The tool of analysis consists of lists, structure charts, grid charts and flow charts. The steps in the analysis are:
¢ Defining system objectives and results.
¢ Trace back to the actions required for the achievement of objectives and results.
¢ Carry out instructions, which prompt the achievement of objectives and must be analyzed In relation to the decisions, which produce them.
¢ Confirm the notifications that have been carried out.
¢ The information based on the decisions can be analyzed into the data and procedures required to produce it.
At each step it is necessary to:
¢ Identify the relevant facts, and establish the relationship between them.
¢ Compare that set of facts with the sets at each adjoining steps and establish the relationship between the facts in these sets.
The analysis of the user requirements takes place throughout the investigation and outline design stages of a system development project, but at some point in time it should be formally documented. The information collected if not organized or stated formally. The input to the Software Requirement Specification (SRS) is inherently informal and imprecise, inconsistent, and it is likely to be incomplete.
Since the collected information is just an imagination stress is given to this phase, which exactly gives shape to the problem. If the information collected is put in an organized manner, which will lead to understand the problem clearly will reduce the error. By correcting the errors in this phase we can minimize the cost of the project.
The requirement phase translate the ideas in the minds of the clients (the input), into formal document (the output of the requirement phase). Thus the output of the phase is a set of
formally specified requirements, which hopefully are complete, while the input has none of these qualities.
By this explanation we define Requirement as "A condition of capability needed by a user to solve a problem or achieve an objective or in other words a condition that must be met or possessed by the system to satisfy a contract, standard, rectification, or other formally imposed document". The output of the requirement specification is the "Software Requirement Specification (SRS)".
Software Requirement Specification (SRS) Abstract
Software requirement specification (SRS) is a fundamental document, which forms the foundation of the software development process. SRS not only lists the requirements of a system but also has a description of its major feature. The recommendations extend the IEEE standards and include use cases and sequence diagrams to incorporate UML standards. The recommendation would form basis for providing clear visibility of the product to be developed serving as baseline for execution of a contract between a client and a developer.
Objectives
These recommendations are designed to serve as a reference for standardized preparation of the SRS for software projects. The body of this document contains various templates that would help guide this process and provide the software engineers with concrete framework to accomplish their task. The idea is to help and assist the software engineers and to promote a scalable structure format to ensure uniformity of concept and practice.
Introduction
Typically, SRS constitutes the agreement between clients and developers regarding the contents of the software product that is going to be developed. SRS should accurately and completely represent the system requirements as it makes a huge contribution to the overall project plan. The software being developed may be a part of the overall larger system or may be a complete stand alone system. If the software is a system component, the SRS should state the interfaces between the system and the software portion.
Features of an SRS
SRS comprises of specification for a software product, program, or set of programs that perform a certain function in a specific environment. Some integral features a typical SRS should support are:
1. Functionality- What the software is supposed to do.
2. External interface- How the system interacts with the people using it, or with other systems that would use it, or other hardware that would invoke it.
3. Performance- Speed. Availability, response, recovery time, recovery time of various software functions etc.
4. Attributes- What is the portability, correctness, maintainability and security considerations, etc
5. Design Constraints- Standard to be followed, resource limits, operating environments, policies for database integrating. Etc
6. Non-functional requirements- Non-functional requirements are the business rules, software quality attributes, safety requirements, security requirements and performance parameters, etc
To ensure an error and ambiguity free SRS, it is imperative to identify all major characteristics of a good SRS. Essentially, SRS should comprehensively cover every requirement that the software has to meet. It is important to note that while writing SRS.
The terminology used for a particular component should be consistent throughout the document. Every term should represent only one meaning to avoid confusion. It is recommended that an expert to eliminate ambiguity review language and grammar of SRS. An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in the future development or enhancement documentation. Nevertheless a quality SRS ensures end-to-end trace ability. End-to-end trace ability might be explained by chunking it into backward and forward trace ability, which is given below.
¢ Backward trace ability (i.e., to previous stages of development). This depends upon each
requirement explicitly referencing its source in earlier documents.
¢ Forward traceability (i.e., to all documents spawned by the SRS.) This depends upon
each requirement in the SRS having a unique name or reference number
The following is the SRS abstract of Online Webstore
User Personas and Characteristics
The persona concept allows for a short hand to refer to typical or special types of users of the application. In this project, the typical users are parameterized by their rights and responsibilities they hold in the Industry. Each user of this application is treated according to their permissions and these security constraints are strictly followed throughout the application. The personas used in this project are:
1 Administrator
2 User - Proj ect Leaders
3 User - Programmers
While the Administrator has all rights and extended privileges, the Users have only limited rights.
Product Perspective
It is designed to develop a stand-alone product to be installed on a java enabled web server like apache tomcat. The application is designed to implement using technologies; Struts, XML, Java Script, JSP and Oracle 9i server as the back end. The entire application is designed to work on Apache Tomcat server. This decision is not a requirement, but rather a conclusion that the team has reached after evaluating possible alternatives.
General Constraints
1 The product is developed using Struts, XML, Java Script and JSP so a Java Runtime is needed at the server side for its operation.
2 Access to an Oracle 9i database server must also be available.
3 This project is designed to run on Linux operating system environment.
4 The users of the application need a HTTP web browser for accessing.
Assumptions
1 The Users have basic knowledge of how to use typical web application on internet.
2 The Users have knowledge of how to input information on a web from using a mouse or keyboard.
Dependencies
1 The product needs an Oracle 9i server as the back end.
2 The functionality provided by the project will be based on the needs of the user.
External Interface requirements
The application's basic interfaces with user / operator are:
1. GUI: Helps user to input and output data from database system.
2. Database: User does not see lay out of data base, but through GUI, information can be set.
3. Code Backup Structures: The user does not see the lay out of this structure, all the information's are providing through the GUI.
The user interface from a human perspective:
1 Interface format will be easy and intuitive to use for a human user.
2 Our product is user friendly and prompts the user for easy usage.
Characteristic Requirements between software and hardware:
1 Operating system of hardware must meet with software. We are basically building this product for Linux Operating system environment.
Interfaces with other software components or products, including other systems, utility software, OS file system, databases and operating systems:
1 Database interface is hidden between user interface and software.
(From the point of view of the end-user, the interface with the software will be primarily mouse and key board based)
2 The file system interface is hidden between the user and the software
CHAPTER 3 SYSTEM SPECIFICATIONS
3.1 HARDWARE REQUIREMENTS
Intel Pentium IV Min 14" color monitor
64 MB 40 GB
Standard 104 keys
56 KBPS
Serial mouse.
Client machine
Processor : Monitor :
RAM :
Hard Disk :
Keyboard :
Modem :
Mouse :
10/100 Ethernet LAN
Server Machine
Processor : Intel Pentium IV or higher with minimum 1 GHz Speed.
Monitor : Min 14" color monitor
RAM : 1 GB
Hard Disk : 40 GB (Or higher for Code backup)
Keyboard : Standard 104 keys
Modem : 56 KBPS
Mouse : Serial mouse
10/100 Ethernet LAN
3.2 SOFTWARE REQUIREMENTS
Client's Machine
Operating system Browser
Server Machine
Operating system User Interface Scripting Database Layer Web Server Browser
: Windows, Linux
: Internet Explorer 5.5 or any http Browser Internet connection with a valid internet service provider
: Redhat Linux Enterprise Edition : Struts 1.2.9, JSP, HTML. : Java Script : Oracle 9i
: Apache Tomcat 5.0 : Mozilla
3.3 TECHNOLOGY SPECIFICATION
Client-Server Architecture
Typical client-server systems are based on the 2-tiered architecture, whereby there is a clear separation between the data and the presentation/business logic. These are generally data driven, with the application existing entirely on the client machine while the database server is deployed somewhere in the organization.
2-Tier Architecture
In a traditional 2- Tiered application, the processing load is given to the client PC while the server simply acts as a traffic controller between the application and data. As a result, not only does the application performance suffer due to the limited resources of the PC, but the network traffic tends increase as well.
Client
Fig 3.1: 2 Tier Architecture
3- Tier Architecture
In 3- Tier architecture an application is broken into three separate logical layers, each with a well - defined set of interfaces. The first tier is referred to as the presentation layer and typically consists of graphical user interface of some kind. The middle tier, or business layer, consists of application or business layer and the third layer- the data layer contains the data that is needed for the application. The middle tier is basically the code that the user calls upon to retrieve the desired data. The presentation layer then receives the data and formats it for display. This separation of application logic from the user interface adds enormous flexibility to the design of application. The third tier contains the data that is needed for the application.
n- Tier Architecture
In an n - tier architecture the application logic is divided by function rather than physically. n - Tier architecture then breaks down like this:
> A user interface that handle the user's interaction with the application; this can be web browser running through a firewall, a heavier desktop application or even a wireless device
> Presentation logic that defines what the user interface displays and how a user's requests are handled- depending on what user interfaces are supported we need to have slightly different versions of the presentation logic to handle the client appropriately.
> Business logic that models the application's business rules, often through the interaction with the application's data.
> Interface services that provide additional functionality required by the application components, such as messaging, transactional support etc.
> The Data layer where the enterprise's data resides.
Overview of J2EE
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 today's 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.
Struts Framework
Struts are a Java MVC framework for building web applications on the J2EE platform.
Struts MVC
The Model 2 architecture for designing JSP pages is in reality, Model View Controller (MVC) applied to web applications. Hence the two terms can be used interchangeably in the web world. MVC originated in SmallTalk and has since made its way into Java community. Model 2 architecture and its derivatives are the cornerstones for all serious and industrial strength web applications designed in the real world. Hence it is essential for you understand this paradigm thoroughly. The main difference between Model 1 and Model 2 is that in Model 2, a controller handles the user request instead of another JSP. The controller is implemented as a Servlet. The following steps are executed when the user submits the request.
1. The Controller Servlet handles the user's request. (This means the hyperlink in the JSP should
point to the controller servlet).
2. The Controller Servlet then instantiates appropriate JavaBeans based on the request parameters (and optionally also based on session attributes).
3. The Controller Servlet then by itself or through a controller helper communicates with the middle tier or directly to the database to fetch the required data.
4. The Controller sets the resultant JavaBeans (either same or a new one) in one of the following contexts - request, session or application.
5. The controller then dispatches the request to the next view based on the request URL.
6. The View uses the resultant JavaBeans from Step 4 to display data. Note that there is no
presentation logic in the JSP. The sole function of the JSP in Model 2 architecture is to display
the data from the JavaBeans set in the request, session or application scopes.
Fig 3.2: Struts Architecture
Advantages Struts
Since there is no presentation logic in JSP, there are no scriptlets. This means lesser nightmares. [Note that although Model 2 is directed towards elimination of scriptlets, it does not architecturally prevent you from adding scriptlets. This has led to widespread misuse of Model 2 architecture.] With MVC you can have as many controller servlets in your web application. In fact you can have one Controller Servlet per module. However there are several advantages of having a single controller servlet for the entire web application. In a typical web application, there are several tasks that you want to do for every incoming request. For instance, you have to check if the user requesting an operation is authorized to do so. You also want to log the user's entry and exit from the web application for every request. You might like to centralize the logic for dispatching requests to other views.
Java Server Pages (JSP)
The Java 2 Enterprise Edition (J2EE) has taken the once-chaotic task of building an Internet presence and transformed it to the point where developers can use Java to efficiently create multi-tier, server-side applications. Today, the Java Enterprise APIs have expanded to encompass a number of areas: RMI and CORBA for remote object handling, JDBC for database interaction, JNDI for accessing naming and directory services, Enterprise Java Beans for creating reusable business components, JMS (Java Messaging Service) for message oriented middleware, JAXP for XML processing, and JTA (Java Transaction API) for performing atomic transactions. In addition, J2EE also supports Servlets, an extremely popular Java substitute for CGI scripts. The combination of these technologies allows programmers to create distributed business solutions for a variety of tasks. In late 1999, Sun Microsystems added a new element to the collection of Enterprise Java tools: Java Server Pages (JSP). Java Server Pages are built on top of Java Servlets and are designed to increase the efficiency in which programmers, and even nonprogrammers, can create web content.
What Are Java Server Pages
Put succinctly, Java Server Pages is a technology for developing web pages that include dynamic content. Unlike a plain HTML page, which contains static content that always remains the same, a JSP page can change its content based on any number of variable items, including the identity of the user, the user's browser type, information provided by the user, and selections made by the user. This functionality is key to web applications such as online shopping and employee directories, as well as for personalized and internationalized content. A JSP page contains standard markup language elements, such as HTML tags, just like a regular web page. However, a JSP page also contains special JSP elements that allow the server to insert dynamic content in the page. JSP elements can be used for a variety of purposes, such as retrieving information from a database or registering user preferences. When a user asks for a JSP page, the server executes the JSP elements, merges the results with the static parts of the page, and sends the dynamically composed page back to the browser.
JSP defines a number of standard elements that are useful for any web application, such as accessing Java Beans components, passing control between pages and sharing information Programmers can also extend the JSP syntax by implementing application-specific elements that perform tasks such as accessing databases and Enterprise Java Beans, sending email, and generating HTML to present application-specific data. One such set of commonly needed custom elements is defined by a specification related to the JSP specification: the JSP Standard Tag Library (JSTL) specification. The combination of standard elements and custom elements allows for the creation of powerful web applications.
Why Use JSP
In the early days of the Web, the Common Gateway Interface (CGI) was the only tool for developing dynamic web content. However, CGI is not an efficient solution. For every request that comes in, the web server has to create a new operating-system process, load an interpreter and a script, execute the script, and then tear it all down again. This is very taxing for the server and doesn't scale well when the amount of traffic increases.
Numerous CGI alternatives and enhancements, such as FastCGI, mod_perl from Apache, NSAPI from Netscape, ISAPI from Microsoft, and Java Servlets from Sun Microsystems, have been created over the years. While these solutions offer better performance and scalability, all these technologies suffer from a common problem: they generate web pages by embedding HTML directly in programming language code. This pushes the creation of dynamic web pages exclusively into the realm of programmers. Java Server Pages, however, changes all that.
Oracle 9i
An Oracle database comprises an instance and data storage. The instance comprises a set of operating system processes and memory structures that interact with the storage. Typical processes include PMON (the process monitor) and SMON (the system monitor).
Oracle users refer to the server-side memory-structure as the SGA (System Global Area). The SGA typically holds cache information like data-buffers, SQL commands and user information. In addition to storage, the database consists of online redo logs (which hold transactional history). Processes can in turn archive the online redo logs into archive logs (offline redo logs), which provide the basis (if necessary) for data recovery and for some forms of data replication.
The Oracle RDBMS stores data logically in the form of tablespaces and physically in the form of data files. Tablespaces can contain various types of segments, for example, Data Segments, Index Segments etc. Segments in turn comprise one or more extents. Extents comprise groups of contiguous data blocks. Data blocks form the basic units of data storage. At the physical level, data files comprise one or more data blocks, where the blocksize can vary.
Oracle keeps track of its data storage with the help of information stored in the SYSTEM tablespace. The SYSTEM tablespace contains the data dictionary - and often (by default) indexes and clusters. (A data dictionary consists of a special collection of tables that contains information about all user objects in the database). Since version 8i, the Oracle RDBMS also supports "locally managed" tablespaces which can store space management information in bitmaps in their own headers rather than in the SYSTEM tablespace (as happens with the default "dictionary-managed" tablespaces).
The Oracle DBMS can store and execute stored procedures and functions within itself. PL/SQL (Oracle Corporation's proprietary procedural extension to SQL), or the object-oriented language Java can invoke such code objects and/or provide the programming structures for writing them.
CHAPTER 4 SYSTEM DESIGN
4.1 MODULARIZATION CRITERIA Fundamental design concepts
A set of fundamental design concepts are evolved over the past decades, although the degree of interest in each concept has varied over the years, each has stood the test of time. Each one provides the software designer with a foundation from which more sophisticated design methods can be applied. Fundamental design concepts provide the necessary frame work for "getting it right".
Abstraction
Abstraction permits one to concentrate on a problem at some level of generalization without regard to irrelevant low level details, user abstraction also permits one to work with concepts and terms that are familiar in the problem environment without having to transform them to an unfamiliar structure. Two types of abstraction are there, one is procedural abstraction and data abstraction. A procedural abstraction is a named sequence of instructions that5 has a specific and limited function. A data abstraction is a named collection of data that describes a data object.
Modularity
Modularity is the single attribute software that allows a program to be intellectually manageable. Software architecture embodies modularity, that is , software is divided into named and addressable component called modules that are integrated to satisfy problem requirements.
Software Architecture
Software architecture alludes to "the overall structure of the software and the ways in which that structure provides conceptual integrity ". Control hierarchy also called program structure, represents the organization of control. The tree structure used to represent the control hierarchy.
Structural partitioning
The program structure should be partitioned both horizontally and vertically. Horizontal portioning defines separate branches of the modular hierarchy for each major program function, vertical portioning called factoring; suggest that control and work should be distributed. Top down in the program architecture. Top level modules should perform control functions and do actual processing works. Modules reside low in the architecture should be the workers, performing all input, computation and output tasks.
Data structure
Data structure is a representation of logical relationship among individual elements of data. Because the structure of information will invariably affect the final procedural design, data structure is very important as the program structure to the representation of the software architecture. Data structure dictates the organization, methods of access, degree of associatively, and processing alternatives for information. The organization and complexity of a data structure are limited only by ingenuity of the designer. Scalar item array and linked list are some of the representations of the data structure.
Software procedure
Program structure defines control hierarchy without regard to the sequence of processing and decisions. Software procedures focus on the processing details of each module individually. Procedure must provide a precise specification processing, including sequence of events, exact, decision points, repetitive operations and even data organization/structure. Information hiding suggests that modules be "characterized by design decisions that hide from all others".
Design is defining a model of a new system and continues by converting this model to a new system. The method is used to convert the model of the proposed system into computer specification. Data models are converted to a database processes and flows to user procedures and computer programs. Design proposes a new system that meets these requirements. This new system may be built by a fresh or by changing the existing system. The detailed design starts with three activities, database design, user design and program design. Database design uses conceptual data model to produce a database design. User procedure design uses those parts of the DFD outside the automation boundary to design user procedures.
4.2 INPUT DESIGN
Input design is the page link between the information system and the users and those steps that are necessary to put transaction data into a usable form for processing data entry. The activity of putting data in to the computer for processing can be activated by instructing the computer to read data from a written printed document or it can occur by keying data directly ion to the system. The designs of input focusing on controlling the amount of input required controlling the errors, avoid delaying extra steps, and keeping the process simple. System analyst decides the following design details.
¢ What data to input
¢ What medium to use
¢ How the data is arranged and coded
¢ The dialogue to guide the users in providing input.
¢ Data items and transactions needing validation to detect errors.
¢ Methods to perform input validation and steps to follow when errors occurs.
4.3 OUTPUT DESIGN
Designing output should proceed in well thought out manner. The term output means any information produced by the information system whether printed or displayed.
When analyst design computer out put they identified the specific output that is needed to meet the requirement. Computer is the most important source of information to the users. Output design is a process that involves designing necessary outputs that have to be used by various users according to requirements. Efficient intelligent output design should improve the system relationship with the user and help in decision making. Since the reports are directly required by the management for taking decisions and to draw the conclusion must be simple, descriptive and clear to the user. Options for outputs and forms are given in the system menus.
¢ When designing the output, system analyst must accomplish the following:
¢ Determine the information to present
¢ Decide whether to display, print the information and select the output medium.
¢ Arrange the information in acceptable format.
¢ Decide how to distribute the output of intended recipient.
4.4 DEVELOPMENT APPROACH
The development approach is based on the waterfall model (figure 4.1). This model particularly expresses the interaction between the subsequent phases. Testing software is not an activity, which strictly follows the implementation phase. In each phase of the software development process, we have to compare the results obtained against that which is required. In all phases quality has to be assessed and controlled.
Fig 4.1: waterfall model
4.5 DATA BASE DESIGN
The overall objective in the development of database technology has been to treat data as an organizational resource and as an integrated whole. DBMS allow data to be protected and organized separately from other resources. Database is an integrated collection of data. The most significant form of data as seen by the programmers is data as stored on the direct access storage devices. This is the difference between logical and physical data.
Database files are the key source of information into the system. It is the process of designing database files, which are the key source of information to the system. The files should be properly designed and planned for collection, accumulation, editing and retrieving the required information.
The organization of data in database aims to achieve three major objectives:-
¢ Data integration.
¢ Data integrity.
¢ Data independence.
The proposed system stores the information relevant for processing in the MS SQL SERVER database. This database contains tables, where each table corresponds to one particular type of information. Each piece of information in table is called a field or column. A table also contains records, which is a set of fields. All records in a table have the same set of fields with different information. There are primary key fields that uniquely identify a record in a table. There are also fields that contain primary key from another table called foreign keys.
Normalization
Normalization is a technique of separating redundant fields and braking up a large table in to a smaller one. It is also used to avoid insertion, deletion and updating anomalies. All the tables have been normalized up to the third normal form. In short the rules for each of the three normal forms are as below.
¢ First Normal Form
A relation is said to be in 1NF if all the under lying domain of attributes contain simple individual values.
¢ Second Normal Form
The 2NF is based on the concept of full functional dependency. A relation said to be in 2NF if and only if it is in 1NF and every non-key attribute is fully functionally dependent on candidate key of the table.
¢ Third Normal Form
The 3NF is based on the concept of transitive dependency. A relation in 2NF is said to be in 3NF if every non-key attribute is non-transitively.
CHAPTER 5
CODING
The goal of coding phase is to translate the design of the system in to code in a given programming language. For a given design, the aim in this phase is to implement the design in the best possible manner. Well-written code can reduce the resting and maintenance effort. During coding, the focus should on developing programs that are easy to read and understand and not simply on developing programs that are easy to write. Simplicity and clarity should be strived for during the code phase.
An important concept that helps the understandability of programs is structured programming. The program that should be organized as a sequence of statements and during execution the statements are executed in the sequence given in the program. There are many different criteria for judging of the program, execution time and required memory.
CHAPTER 6
SYSTEM TESTING
Testing is the major quality measure employed during software development. After the coding phase, computer program s are available that can be executed for testing purposes. Testing not only has to uncover errors introduced during coding, but also locates errors committed during the previous phases. Thus the aim of testing is to uncover requirements, design or coding errors in the program.
6.1 TYPES OF TESTING
This is the phase where bug in the program was to be found and corrected. One of the goals during dynamic testing is to produce a test suite. This is applied to ensure that the modification of the program does not have any side effects. This type of testing is called regression testing. Testing generally removes all the residual bugs and improves the reliability of the program. The basic testing types are
> Unit testing
> Integration testing
> Validation testing
> Output testing
> User acceptance testing
6.1.1 Unit Testing
This is the first level of testing. In this different modules are tested against the specifications produced during the design of the modules. Unit testing is done for the verification of the code produced during the coding of the single module in an isolated environment. Unit testing first focuses on the modules independently of one another to locate errors. After coding, each dialogue is tested and run individually. All unnecessary coding were removed and it was ensured that all the modules worked, as the programmer would expect. Logical errors found were corrected. So, by working all the modules independently and verifying the outputs of each module in the presence of staff was conducted that the program was functioning as expected.
6.1.2 Integration Testing
Data can be lost access an interface, one module can have as adverse effect on another sub-functions when combined, may not produce the desired major functions. Integration testing is a systematic testing for constructing the program structure, while at the same time conducting test to uncover errors associated within the interface. The objectives are to take unit tested as a whole. Here correction is difficult because the vast expenses of the entire program complicate the isolation of causes. Thus in the integration testing step, all the errors uncovered are corrected for the next testing stages.
6.1.3 Validation Testing
This provides the final assurance that the software meets all the functional, behavioral and performance requirements. The software is completely assembled as a package. Validation succeeds when the software functions in a manner in which the user expects. Validation refers to the process of using software in a live environment in order to find errors. During the course of validating the system, failures may occur and sometimes the coding has to be changed according to the environment.
Once the application was free all the logical and interface errors, inputting dummy data ensured that the software developed satisfied all the requirements of the user.
6.1.4 Output Testing
After performing the validation testing, the next step is the output testing of the proposed system since no system could be useful if it does not produces the required output generated or considered into two ways; one is on screen and another is printed format.
The output format on the screen is found to be correct as the format was designed in the system design phase according to the user needs. For the hard copy also the output comes out as the specified requirements by the user. Hence output testing does not result in any correction in the system.
6.1.5 User Acceptance Testing
User acceptance of a system is the key factor for the success of any system. The system under consideration is tested for user acceptance by constantly keeping in touch with the prospective system users at the time of developing and making changes whenever required. Preparation of test data plays a vital role in the system testing. After preparing g the test data the system under study is tested using the test data. While testing the system by using the test data, errors are again uncovered and corrected and the corrections are also noted for the future.
6.1.6 Black box Testing
Knowing the specified function that a product has been designed to perform, test can be conducted that each function is fully operational. Black box test are carried out to test that input to a function is properly accepted and output is correctly produced. A black box tests examines some aspects of a system with little regard for the internal structure of the software.
Errors in the following categories were found through Black box testing,
¢ Incorrect or missing functions.
¢ Interface errors.
¢ Errors in database structure or external database access.
¢ Performance errors.
¢ Initialization and termination errors.
6.1.7 White box Testing
White box testing of software is predicted on a close examination of procedural detail. The status of the project may be tested at various points to determine whether the expected or asserted status is corresponding to the actual status. Using this, the following test cases can be derived:-
¢ Exercise all logical conditions on their true and false side.
¢ Execute all loops within their boundaries and their operation bounds.
¢ Exercise internal data structure to ensure their validity.
6.2 QUALITY ASSURANCE
Quality assurance consists of the auditing and reporting functions of management. The goal of quality assurance is to provide management with the data necessary to be informed about product quality is meeting its goals. This is an umbrella activity that is applied throughout the engineering process.
Software quality assurance encompasses
¢ Analysis, design, coding, and testing methods and tools.
¢ Formal technical reviews that are applied during each software engineering
¢ Multi tiered testing strategy.
¢ Control of software documentation and the change made to it.
¢ A procedure to ensure compliance with software development standards.
¢ Measurement and reporting measurements.
6.3 QUALITY FACTORS
The factors that affect the quality can be categorized into two broad groups:
¢ Factors that can be directly measured.
¢ Factors that can be indirectly measured.
These factors focus on three important aspects of a software product
¢ Its operational characteristics
¢ Its ability to undergo change.
¢ Its adaptability to the new environment.
CHAPTER 7
SYSTEM IMPLEMENTATION
Implementation is the stage of the project where the theoretical design is turned into a working system. At this stage the main work load, the greatest upheaval and the major impact on the existing system shifts to the user department. If the implementation is not carefully planned and controlled it can cause chaos and confusion.
Implementation includes all those activities that take place to convert from the old system to the new one. The new system may be totally new, replacing an existing manual or automated system or it may be a major modification to an existing system. Proper implementation is essential to provide a reliable system to meet the organization requirements. Successful implementation may not guarantee improvement in the organization using the new system, but improper installation will prevent it.
The process of putting the developed system in actual use is called system implementation. This includes all those activities that take place to convert from the old system to the new system. The system can be implemented only after thorough testing is done and if it is found to be working according to the specifications. The system personnel check the feasibility of thy system.
The most crucial stage achieving a new successful system and giving confidence on the new system for the user that it will work efficiently and effectively. It involves careful planning, investigation of the current system and its constraints on implementation, design of methods to achieve the change over. The more complex the system being implemented, the more involved will be the system analysis and the design effort required just for implementation. The system implementation has three main aspects. They are education and training, system testing and change over.
The implementation stage involves following tasks.
¢ Careful planning.
¢ Investigation of system and constraints.
¢ Design of methods to achieve the change over.
¢ Training of the staff in change over phase.
¢ Evaluation of the change over method.
The method of implementation and the time scale to be adopted are found out initially. Next the system is tested properly and the at the same time users are trained in the new procedures.
7.1 IMPLEMENTATION PROCEDURE
Implementation of software refers to the final installation of the package in its real environment, to the satisfaction of the intended users and the operation the system. In many organizations some one who will not be operating it, will commission the software development project. The people who are not sure that the software meant to make their job easier. In the initial state, they doubt about the software but we have to ensure that they resistance does not build up as one has to make sure that;
¢ The active user must be aware of the benefits of using the system
¢ Their confidence in the software is built up
¢ Proper guidance be imparted to user so that he is conformable in using the application.
7.2 USER TRAINING
To achieve the objectives and benefits expected from computer based system, it is essential for the people who will be involved to be confident of their role in the new system. As systems become more complex, the need for education and training and training is more and more important.
Education is complimentary to training. It brings life to formal training by explaining the background to the resources for them. Education involves creating the right atmosphere and motivating user staff. Education sections should encourage participation from All staff with protection for individuals for group criticism. Education should start before any development work to enable users to maintain or to regain the ability to participate in the development of their system.
Education information can make training more interesting and more understandable. The aim should always be to make individual feel that they can still make all important contributions, to explain how they participate in making system changes, and to show that the computer and computer staff don't operate in isolation, but are of the same organization.
7.3 TRAINING ON APPLICATION SOFTWARE
After providing the necessary basic training on the computer awareness the users will have to be trained on the new application software. This will give the underlying philosophy of the use of the new system such as the screen flow, screen design, type of help on the screen, type of errors while entering the data. The corresponding validation check at each entry and the ways to correct the data entry. It should then cover information needed by the specific user/group to use this system or part of the system while imparting the training of the program on the application. This training may be different across different user groups and across different levels of hierarchy.
7.4 OPERATIONAL DOCUMENTATION
Once the implementation plan is decided, it is essential that the user of the system is made familiar and comfortable with the environment. Education involves right atmosphere and motivating the user. A documentation providing the whole operation of the system is being developed. The system is developed in such a way that the user can work with it in a well consistent way. The system is developed user friendly so that the user can work the system from the tips given in the application itself. Useful tips and guidance is given inside the application itself to help the user.
CHAPTER 8 SYSTEM MAINTENANCE
8.1 INTRODUCTION
It is impossible to produce software that doesn't need to be changed. Over the lifetime of any system the original requirements will be modified to reflect the changing user and customer needs. The system environment may change as new hardware is introduced. Errors undiscovered during system testing may emerge as a result. Hence the system maintenance is a process of changing a system after it has been delivered and is in use currently. These changes may be simple changes to correct coding errors, design errors, or even significant enhancement to correct specification errors to accommodate new requirements. Maintenance is therefore evolution of the system in accordance with the changes in environment. It is a process of changing a system to maintain its ability to survive. There are three different types of maintenance with very blurred distinction between them.
8.2 CORREPUTIVE MAINTENANCE
It is concerned with fixing reported errors in the software. Coding errors are usually relatively cheap to correct. Design errors are more expensive as they involve the rewriting of several program components. Requirement errors are the most expensive to repair due to extensive system redesign that is involved.
8.3 ADAPTIVE MAINTENANCE
This involves changing the system to some new environments such as different network platform or for use with a different operating system. The system functionality does not radically change.
8.4 PERFECTIVE MAINTENANCE
This involves implementing new functional or non-functional system requirements, software customer policy changes; business changes are changes in top management. The maintenance process is usually triggered by a set of change request from the users, management or customers. The cost and impact of these changes are first assessed. If proposed changes are accepted a new release of the system is planned. This release usually involves elements of adaptive, corruptive as well as perfective maintenance. These changes are implemented and validated and a new version of the system is released. Rather than viewing maintenance as a separate process it should be normally considered as an iteration of the development process. New requirements must be formulated and validated, components of the system must be redesigned and implemented and part or all of the system should be tested.
CHAPTER 9
TABLES
Table 9.1 Registration
Field Size Constraints Description
name varchar2 20 Primary key Name of the user
password varchar2 10 Not Null Password for the user authentication
address varchar2 50 Not Null Address of th user
role varchar2 20 Not Null Role of the new user involved
phone number 7 Not Null Phone number of the user
This table stores the details of registered user such as user name, password, etc. The entries in the table all inserted during the new user registration process.
Table 9.2 Vendorentry
Field Type Size Constraints Description
Date1 date Not Null Date of vendor creation
shopid varchar2 20 Not Null Name of the shop
shopdesc varchar2 20 Not Null Description of the shop
vendorname varchar2 20 Not Null Name of the vendor
This table stores the details of vendorentry created by the administrator .The entries in the table all inserted during the new vendor creation process.
This table stores the details of maingroupentry of the vendors. This data contains mainitemname,shopid,description etc..
Table 9.4 Subgroupentry
Field Size Constraints Description
id varchar2 20 Not Null Unique id of the subitem
subitem varchar2 20 Not Null Name of the subitem
description varchar2 50 Not Null Description of the sub item
price varchar2 20 Not Null Price of the sub item
subid number 6 Not Null Sub id number of the subitem
This table stores the details of the subgroupentry items.it contains subitem name,id,description,subid etc.
This table contains the purchase details of the visitors. It contains userid, total amount, date of purchase etc.
Table 9.7 Purchase_ details2
Field Size Constraints Description
userid vrchar2 20 Not Null Id of the user
itemsid varchar2 100 Not Null Id of the purchased item
This table contains the purchase details of the visitors. It contains userid, total amount, date of purchase etc.
CHAPTER 10
DATA FLOW DIAGRAMS
Fig 10.1 Context diagram
Fig 10.2 Admin Level 0 DFD
->
Shopentry
Fig 10.3 Vendor Level 0 DFD
->
Purchase
Fig 10.4 Visitor Level 0 DFD
Fig 10.5 Admin Level 1 DFD
Vendor
maingroupentry
Subgroup entry
Fig 10.6 Vendor Level 1 DFD
Visitor
Purchase Purchase bill
/ *
Fig 10.7 Visitor Level 1 DFD
Admin
Fig 10.8 Admin Level 2 DFD
photoupload
Photo upload
Admin
Online webstore processing
Add cart
Purchase
Purchase bill
Fig 10.10 Visitor Level 2 DFD
CHAPTER 11
SCREEN SHOTS
web store - Mozilla Firelox
File Edit View Go Bookmarks Tools He'P
<Cp ' O * [§ V'f) | .. http://192.168.rj.122:8080/webstore/ < ©Go |EL
Fig 11.1 Home page This page is the home page of the online webstore
This page is used to register the new users. There are three types of users, they are administrator, vendor, visitors.
Y ffi U R. SI + E
ONLINE m\tm
fffffff
® firefox-bin (2) j Ol students1 static I
Fig 11.3 Login form
This form is used as the login form
Y ffiU R.
ONLINE
LOAD IMG
TTTTTTT
Si firefox-bin (21 131 student© 5tati<[
Figure 11.4 Vendor entry form
Here vendor entries are created. This is done by administrator
T^hiWib store - Mozilla Firefoit
File Edit View Go Bookmarks Tools H_elp
htTp://192.168.0.122:8080/webstore/index...roupingjsp . ^. © Go |[Gl.
rlredirectbody.jsp
¦I O A D ¦ I N G
TTTTTT'T
firefox-b [File Brc [oracled
Figure11.5 Shop entry form
This form is mainly consists of two parts. Main group entry and sub group entry. These are used by the vendors to create their shops
This form is used to create the main group entry of the vendor
jj) web store - Mozilln Firelox â€â€**^^*^
File Edit View Go Bookmarks Tools Help vj
J3 " |f) | .. hnp://192J68.0J2Z:808[ywebstore/indexjsp7uriredirect=/shop(letailsentrv/subgroupentrv.jsp T © Go ||GL
Fig 11.7 Subgroup entry form
This form is used to enter the subgroup items of the shop.
Here users visits the shops and purchase the items
Back Forward Reload 5top
it- http://192llG8l0J22:8080/webstore/in^ ^i],^,Search
' U (O) A D I N G
TTTTTTI
Fig 11.9 Shop details
Here visitors get the shop's main item details.
mob hokia 2000 hu
SHOW CART
¦ mob hokia 2000 null
LOAD IMG
frrrfTt
Ge M Tei « FileI* [W. §
Fig 11.10 Item details form
Here the visitor selects the items from the shop provided by the vendor. He gets a cart to purchase the items
store - Mozilla
File Edit View Go Bookmarks Tools Window H_elp
Back Forward Reload 5top
Li hup://192.1C8.0.122:S08L^,webstore/indexJspur1redire<:t=viewcarrJsp
LI rlredirectbody.jsp
Si WlliTOM
' L O A D I N G
fTTYYTl
\& Done
kfCeilTei * File ®[W.Q[..
Fig 1.11 Show cart form
Here he has a option to remove or purchase the items from the cart.
In this form he get a bill of the purchased items.
||binoy ||B3-0 ||2007-02-22 00j00:00.0||#1 2E
retieve sub item details
collected itms subids
LOAD IMG
TtTTTTt
firef ox-bin (2) ' [oracle©srariol
Fig 11.13 Admin report form
Here the administrator gets the report of the purchased persons and items.
Fig 11.14 Subitem details form
Here the administrator gets the detailed bill of the item.
CHAPTER 12 CONCLUSION
In online webstore the users can purchase the product from his home itself according to information given by the webstore.The user can feel the atmosphere of real shopping complex.
In this project we are committed to providing customer with easy and secure way to shop online for quality products. Here we provide an interface for creating shops for different vendors; and managing their dataset very effic
