J2EE Project Report

Project Report On Online Shopping Mall

Project Members :Arunangshu Sen Debashis Sharma Sabarna Sundar Ghosh Of Dr. B. C. Roy Engineering College

Online Shopping Mall

Contents Serial No. Name 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.

Acknowledgement Project Analysis Objectives Tools And Platform Used Preliminary Investigation Feasibility Study System Requirement Specification System Design Data Flow Diagram Entity Relationship Diagram User Interface And Module Overview Table Structure Project Testing Limitations Of The Project Future Enhancements Conclusions Bibliography

Page No. 3 4 5 6 7 8-9 10-12 13 14-15 16 17 18-19 20-21 22 23 24 25

Page 2


Acknowledgement At such an early stage of our career in INFORMATION TECHNOLOGY and it’s applications we deem ourselves fortunate in having an opportunity to work in such project. A large number of individuals had contributed directly in this project. We would like to thank the countless number of people who have helped get this work out of door. While developing this project we had to consult many people from different grounds of activity, which includes Software Professionals, Database Administrator, Networking professional and many more. First and foremost, we thank our project guide Mr. Dibakar Sanyal of Moniba Compu Academy Pvt. Ltd. (IBM ACE), whose earnest suggestion, inspiration and involvement paved the way for the successful completion of the project. We would like to offer our special gratitude to them for sharing the ups and downs during the development and bearing inconvenience. We also express our sincere gratitude to all the faculty members of Moniba Compu Academy Pvt. Ltd. (IBM ACE) for their suggestions & enormous encouragement. We hope to get the same help and guidance from the academy in near future when needed.

Page 3


Project Analysis Shopping, be it a necessity or pleasure, has been an important aspect of the society. Beginning from food items, garments, stationary etc., the essence of shopping extends to jewellery ,cars , apartments etc. Since the demand of the time is “ease of access”, the concept of “online-shopping” was introduced. Instead of searching for a right shop for the right thing, a customer can just search for a right website and have his purchase delivered at home directly! BestBuy, an online shopping cart will provide customers a soothing shopping experience which will be saving both time and energy. All a customer has to do is register to the website and provide us with his/her area of requirement for shopping, i.e he/she has to just search for the desired products of the desired brand or other items of the same category. Development of BestBuy is an attempt to ease the process of shopping, realizing the ever-increasing value of time. The success of our website depends on how much the time consumption of customers can be reduced to sell them their desired products.

Page 4


Objectives The main objective of our project is to create a website that is both userfriendly and has a wide section of use. More the user finds ease in the operations the more this website is close to success. Our objective behind the development of this project is to provide best security using the right security policies and correct technologies. The development of this website would make us aware of the various dangers that may occur due to lack of security and other issues when launch this website in the internet. Some Salient Features Of The Project Are: Easy navigability: the customer should find it easy to navigate through the website as our effort is to reduce time consumption. User Friendly: since many operations are listed in a single page, it will be easy for the user to search through the website, rather than going on navigating for the product of his choice. Prepaid Options: creating an account of the customers in the database of the website will help the user to perform the “Cash on Delivery”. It also ensures security. Can be Commercialised: the website developed by us is so realistic that it can be realized by commercialising.

Page 5


Tools And Platform Used Software

: NetBeans 7.01

Platform

: Windows XP

Architecture Client Tier Web Tier

: :

HTML , Java Script Servlet , JSP

Database

:

MySQL Essential

Hardware Requirement:1. 2. 3. 4. 5. 6.

Intel Pentium 1.5 Ghz. 1 GB main memory. 3 GB of free hard disk space. 14” or bigger monitor. Mouse. Standard Keyboard.

Software Requirement:1. Operating System: Windows Xp 2. Server: GlassFish 3.1 3. Database: My SQL

Page 6


Preliminary Investigation A request to take assistance from information systems can be made for many reasons, but in each case someone in the organization initiates the request. When the request is made, the first systems activity the preliminary investigation begins. This activity has three parts: • Request Clarification • Feasibility Study • Request Approval Request Clarification: Many requests from employees and users in the organizations are not clearly defined. So it becomes necessary that project request must be examined and clarified properly before considering systems investigation. Feasibility Study: An important outcome of the preliminary investigation is the determination that system requested is feasible. There are three aspects in the feasibility study portion of the preliminary investigation: • Technical Feasibility • Economic Feasibility • Operational Feasibility Request Approval: The projects that are feasible and desirable should be put into a schedule. In some cases, development can start immediately although usually systems staff members are busy on other projects. When such situation arises, management decides which projects are most urgent and schedules them accordingly. After a project request is approved, its cost, priority completion time and personnel requirements are estimated.

Page 7


Feasibility Study Feasibility is the determination of whether or not a project is worth doing. The process followed in making this determination is called a feasibility study. This type of study determines if a project can and should be taken. Once it has been determined that a project is feasible, the analyst can go ahead and prepare the project specification which finalizes project requirements. Feasibility studies are undertaken within tight time constraints and normally culminate in a written and oral feasibility report. The contents and recommendations of such a study will be used as a sound basis for deciding whether to proceed, postpone or cancel the project. Thus since the feasibility should may lead to the commitment of large resources, it becomes necessary that it should be conduc \ted competently and that no fundamental errors of judgment are made. In the conduct of feasibility study the analyst will usually consider seven distinct but interrelated types of feasibility. They are:Technical Feasibility: This is concerned with specifying equipment and software that will successfully satisfy the user requirement. The technical needs of the system may vary considerably but might include: • The facility to produce outputs in a given time. • Response time under certain conditions. • Ability to process a certain volume of transaction at a particular speed. • Facility to communicate data to distant location. In examining technical feasibility, configuration of the system is given more importance than the actual make of hardware. The configuration should give the complete picture about the system’s requirement. Out of all feasibilities technical feasibility is most difficult to determine. Operational Feasibility: It is mainly related to human organizational and political aspects. The points to be considered are: • What changes will be brought with the system? • What organizational structures are disturbed? Page 8


• What new skills will be required? Do the existing staff members have these skills? If not, can they be trained in due course of time? Generally project will not be rejected simply because of operational infeasibility but such considerations are likely to critically affect the nature and scope of the eventual recommendations. This feasibility study is carried out by a small group of people who are familiar with information system techniques, who understand the parts of the business that are relevant to the project and are skilled in system analysis and design process. Economic Feasibility: Economic analysis is the most frequently used technique for evaluating the effectiveness of a proposed system. More commonly known as cost/ benefit analysis; the procedure is to determine the benefits and savings that are expected from a proposed system and compare them with costs. If benefits outweigh costs, a decision is taken to design and implement the system. Otherwise, further justification or alternative in the proposed system will have to be made if it is to have a chance of being approved. Time Feasibility: Time feasibility is a determination of whether a proposed project can be implemented fully within a stipulated time frame. If project takes too much time it is likely to be rejected. Management Feasibility: It is a determination of whether a proposed project will be acceptable to management. If management does not accept a project or gives a negligible support to it, the analyst will tend to view the project as a nonfeasible one.

Page 9


System Requirement Specification: 1. System Requirements – The problem which software engineers are called upon to solve is often immensely complex. Understanding the nature of the problem can be very difficult. If the system is new, there is no existing system to help understand the nature of the problem. Consequently, it is difficult to establish exactly what the system should do. The process of establishing the services the system should provide and the constraints under which it must operate is called requirements engineering. The term engineering is used rather loosely in this respect. It means that a systematic process is used to derive a definition of the software system which is to be developed. Requirements analysis is done in order to understand the problem the software system is to solve. The problem could be automating an existing manual process, developing a new automated system, or a combination of two. My project emphasis on requirements analysis is on identifying what is needed from the system, not how the system achieves its goal. This task is complicated by the fact there are often at least two parties involved in software development-a client and a developer. The developer has to develop the system to satisfy the client’s needs. The developer usually does not understand client’s problem domain, and the client often does not understand the issues involved in software systems. This causes a communication gap, which has to be adequately bridged during requirement analysis. Some of the problems that arise during the requirements engineering process are a result of failing to make a clear separation between these different levels of description. We make this separation by using the term requirement definition to mean the high level abstract description of requirements and requirements specification to mean the detailed description of what the system should do. As well as these two levels detail, a further even more detailed description may be produced to bridge the requirements engineering and design activities. Requirement specification, requirement defication and software specification may be defined as follows:

Page 10


A requirements defication is a statement, in a natural language plus diagrams, of what services the system is expected to provide and constraints under which it must operate-it is generated using customersupplied information. A requirements specification is a structured document which sets out the system services in detail this document. Which is sometimes called a functional specification, should be precise. It may serve as a contract between the system buyer and software developer. A software specification is an abstract description of the software which is a basis for design and implementation. This specification may add further detail to the requirement specification. 2. Requirement Validation:Requirement validation is concerned with showing that the requirements are actually define the system that the clients want. If this validation is adequate, errors in the requirements will be propagated to the system design and implementation. Expensive system modifications may be required at a larger stage to correct problem with requirements. The cost of errors in requirements is particularly high if these errors are not discovered until the system is not implemented. The cost of making a system change resulting from a requirement problem is much greater than repairing design or coding errors. A requirements change implies that the design and implementation must also be changed. The system testing and validation process must be repeated. The cost of changing a system after delivery because of a requirement change can therefore be up to 100 times more than the cost of repairing a programming error. There are several aspects of the requirements which must be checked: Validity : A user may think that a system is needed to perform certain functions. However, further thought and analysis may identify additional or different functions that are required. Systems have diverse users with different needs and any set of requirements is inevitably a compromise across the user community. Consistency: Any one requirement should not conflict with any other. Completeness : Should include all functions and constraints intended by the system user.

Page 11


Realism : There is no point in specifying requirements that are unrealizable. It may be acceptable to anticipate some hardware developments in software technology are much less predicted. 2. Requirement Evolution:Developing software requirement forces attention on software capabilities, business objectives and other business systems. As the requirements definition is developed, a better understanding of user’s needs is achieved. This feeds information back to the user, which causes the requirements. To be changed. Furthermore, the time required analyzing requirements and to develop a large system may take several years. The inevitability of change should be recognized and anticipated when producing a requirements document. It is unwise to prematurely freeze requirements. Although this is attractive as far as system development is concerned, it leads to systems that are unlikely to meet the real business needs of systems procurer. This activity is at the heart of system analysis the analyst must study the present system and document feature for further analysis by using various fact by gathering techniques. The analyst must evaluate the flow and structure of information, refine all software functions in detail, and establish system: Therefore characteristic and uncovered details design consideration. Each of these tasks servers to described the problem so that an overall approach or solution may be synthesized. The analyst must determine the problems with the current system and determined what information will be produced by new system and what data will be provided to the system. After doing this analyst must synthesize one or more possible solution.

Page 12


System Design Abstraction is a tool that provides a design of components at an abstraction level, without considering the details of the implementation of the components. Any component provides services to its environment. An abstraction of a component describes only the external behaviour. There are two common abstraction mechanisms for the software system: functional abstraction and data abstraction . In data abstraction, data is not relatively treated simply as objective with some predefined operation on them. The operation defined on the data object is the only operation that can be performed on the object. Only the operation on the object is visible and not the internal of it. Data abstraction forms the basics of object-oriented designing. In using the abstraction, a system is viewed as set of object providing some services hence the decomposition is done with respect to the objects the system contents. Design-“The process of applying various techniques and principle for the purpose of defining a device, a process or a system in sufficient details to permit is physical realization ….”-is the out of analysis. The designer’s goal is to produce a model or representation of entity that will later be built. Software design sits at the technical kernel of the software engineering and is applied regardless of the development paradigm that used as Rojer Pressman says. There are types of design namely 1. Preliminary Design. 2. Detailed Design. The preliminary design consists of data and structural design where the latter consists of the input and output design. Validation for the input data is designed common for all the modules. Modularization increases as the integrity and efficiency of the system. But care must be taken to avoid nesting of modules in higher levels, this will increase complexity of the system designing will be done in three steps:• Database Design • Input Design

Page 13


• Output Design

Data Flow Diagram: A data flow diagram (DFD) is a significant modelling technique for analyzing and constructing information processes. DFD literally means an illustration that explains the course or movement of information in a process based on the input and outputs. A DFD can be referred to as a Process Model. Data flow diagram can be used to provide a clear representation of any business function. The technique starts with an overall picture of the business and continues by analyzing each of the functional areas of interest. This analysis can be carried out to precisely the level of details required. The technique exploits a method called top-down expansion to conduct the analysis in a targeted way.

Data Flow Diagram 1

Page 14


Data Flow Diagram 2

Data Flow Diagram 3

Data Flow Diagram 4

Page 15


Entity Relationship Diagram Entity-Relationship Model : The E-R (entity-relationship) data model views the real world as a set of basic objects (entities) and relationships among these objects. It is intended primarily for the DB design process by allowing the specification of an enterprise scheme. This represents the overall logical structure of the database

Page 16


User Interface & Module Overview:

Page 17


Table Structures:

Page 18


Page 19


Project Testing System testing: System testing does not test each module individually, but rather the integration of each module in the system. It also tests to find description between the system and its original object, current specification and system documentation.

Unit testing: In unit testing the analysis test the programming making up the system. The software units in a system are the modules and routines that are assembled and integrated to perform a specific function. In a large system many modules at different levels are needed for unit testing should exercises each condition and option. Unit testing comprises the set of tests performed by an individual programming prior to implementation of the unit into a large system.

Integration Testing and System Testing: This phase of testing helps to uncover error in the interfaces. The name Integration Testing suggests the testing of the entire module interfaces before they are integrated from the entire system. Testing is an essential stage of Software Development Life Cycle. If they are done properly by following an organization’s standards – the end result will be more robust programs going into System integration. Proper Coding and Unit Testing are basic steps to ensure that the system being built will work once it is put together.

Page 20


Regulations expect that the accurate coding and testing will be performed and documented The Quality Assurance Professional must help educate programming staff if they do not already know what standards should be followed and internal reviews are required. During the SDLC, there are many types of reviews including requirements review, design review, code review (walkthroughs) and test readiness review. The Quality Assurance Professional can be a part of each of these review process. And most importantly – we all know that it isn’t documented, it never happened. Software Developers must be persuaded to save the results of their hard work for future use.

Page 21


Limitations Of The Project:  Real life implementation of the project cannot be done  Storage of blob objects on the database is hectic and data retrieval speed entirely depends on the server.  No implementation of credit card payments through secure gateway could be done

Page 22


Future Enhancements: With the ever-increasing usage of internet, it can be easily projected that that online-shopping will gain much popularity in future, because of its easy and efficient access. If the following things are incorporated in the project, future scopes will again increase: • Addition of “admin” control panel. • Security would be mandatory with digital signature, which is no longer impossible. • Including an self-defined encryption logic to encrypt the various files & folders • Implementation of a module for checking and destroying the virus affecting the software can be done.

Page 23


Conclusions : The main objective in shopping cart project was to classify the whole Product. So we use a hierarchal abstraction as SEGMENT having CATEGORY having BANDS having PRODUCT having various items. It helps us to build a database which is easily manageable. The web pages are very user friendly as User can easily browse through the whole product in all pages, can add items in their Cart anytime before login or after login. Payment modes are easy and online. Thus we gave our best in the project as beginner.

Page 24


Bibliography: 1. Roger S. Pressman – Software Engineering (A Practitioner’s Approach) 2. S. Allamaraju & Cedric Buest – Professional Java Server Programming 3. O’Reilly Publication – Core Servlets & JSP 4. Jim Keogh – Complete Reference J2EE 5. Kathy Sierra & Bert Bates – Head First JSP & Servlets 6. Black Book- Java Server Programming

Page 25

J2EE Project Report

Recommend Documents