A Roadmap to E-Commerce Development

I l @ ve RuBoard

E-commerce developers have never had a larger suite of tools to use in deploying their magnum opuses than they do now. Many of us can remember our first Web site that had any kind of a back end, strung together with some C code or maybe a lot of Perl. Design consisted of flailing around until you ended up with something that you hoped resembled what the customer wanted. And you considered yourself lucky if the site did anything more than generate 404 and 501 error pages.

Today, of course, we have an entire arsenal of tools to assist us in putting together an impressive Web site. There are HTML development tools such as FrontPage, HotMetal, and Dreamweaver. Applications developers use Java in combination with integrated development tools (IDEs) such as TogetherJ. Data is stored in the latest versions of relational databases, which have been extended to support the Web. Believe me, you've never had it so good.

But with new toys come new challenges. More than ever, you need to start with a good understanding of the problem you're trying to solve, and a good process to ensure successful execution. In a while, we'll take a look at some of these best practices and how you'll be using them to build a working e-commerce Web site.

In case you're getting the idea that I'm some kind of standards addict, let me correct the impression right now. I have little patience for people who believe that the value of a project is equal to the weight of its documentation. In the fast-paced e-commerce world, you don't always have time to deforest a subcontinent before you begin actual work. At the same time, I've seen firsthand the perils of going off half-cocked before you have a thorough understanding of the problem.

The procedures that I recommend in this book are all designed around capturing and understanding the customer's needs. There is a minimum of paperwork designed solely to protect your job, and there's nothing that I haven't found essential through painful experience. For that reason, bypassing them is not recommended. You might be under intense pressure to start coding this instant, but if you start down a road before you know where you want to end up, you're likely to find yourself up the creek without a paddle (how's that for a contorted analogy?)

Before you can even begin designing, you need to understand what you're trying to do. This is the wonderful world of requirements gathering, and it will be spelled out in detail in Chapter 4, "The Sample Application Functional Requirements Document." Requirements gathering is the unglamorous paperwork-laden part of this business, but it is the single most important activity that you will undertake. The most wonderful Web site in the world won't earn you that holiday bonus if it doesn't do what your customer (internal or external) wants it to do.

More importantly, failure to comprehensively document the requirements early leads to two curses of this business: "feature creep" and last-minute redesign. Both will cause you to be rewriting your code late in the process when time is tight and tempers are frazzled. Doing it right the first time will save your sanity and your profit margins.

As part of this process, it can be very useful to develop a nonfunctional set of HTML pages as a mockup of the user 's view of the site. One term for these pages I've heard used frequently is wireframes. They serve three purposes. First, they provide visual feedback to your customer so that you're both talking about the same thing. Second, they can uncover problems with site navigation and flow very early, when there's still ample time to fix it. Third, they can serve as templates for your JSP pages later in development.

THE FRONT END AND THE BACK END

Another pair of terms that you'll see a lot in this book is the front end and the back end. They form the division between what the user sees and the magic that goes on behind the scenes.

The front end consists of the presentation given to the user. Think of it as everything that the user can see and touch. In this environment, the JSP pages represent it.

The back end is all the grungy processing that occurs when the user makes a request (recording things in the database, sending email confirmations , and so on). It also includes integrations with other subsystems, such as an inventory system.

This book is almost entirely concerned with the back end and the interface between the front end and the back end. If you're looking for a tutorial on HTML design, this isn't the book for you.

At the end of the book, we'll look at the Struts development framework, which implements a particular type of front end/back end division called Model-View-Controller (MVC), and a more extreme division called Enterprise Java Beans (EJB).

The output of the requirements-gathering process is the functional requirements document (FRD). This is a contract between you and your customer: You're committing to a body of work, and your customer is committing to be satisfied with the results if they conform to the FRD. It is usually a detailed walkthrough of the entire site, describing what a visitor to the site can do at each stage and what must occur as a result of a user action. In addition, it must document things such as input validation (did the user enter the data right?) and any back-end processing that must occur.

The less specific you are in the FRD, the more "wiggle room" you've left the customer come development time. "You didn't say that the user couldn't enter the quantity in hexadecimal," says the customer, and you've suddenly bought yourself another man-day to add the feature. Again, it's a silly example, but bad things do happen if you don't resolve them early.

After you have gathered the requirements and turned them into some kind of FRD, you need to study the task and determine the underlying object models that you will be using for the project. Using an object-oriented language such as Java and relational databases such as MySQL forces you to think about problems in terms of objects first. You need to go through and identify your candidates using tools such as entity relationship diagrams (ERDs) and use cases.

You might have been exposed to Java classes and objects if you've written Java applets, perhaps using Swing. However, this only scratches the surface of what object-oriented programming is all about. A typical browser applet has one main class that does all the work and makes calls out to a few GUI classes. A fully developed e-commerce design can have dozens of classes, modeling everything from the customer to the products to a shopping cart, as you will soon see.

Next, you will get your underlying infrastructure in place. This means installing software that you'll need for the project, creating your database schema, and making sure that all the technology pieces talk to each other. Setting up your development platform can be one of the most frustrating experiences in the entire project. For example, I'm currently working on a project that requires six hours to set up the platform correctly. You'll be happy to hear that the setup and integration for the projects in this book will be easy. Only after you have completed all this will you be ready to start actually producing code.

I l @ ve RuBoard


MySQL and JSP Web Applications. Data-Driven Programming Using Tomcat and MySQL
MySQL and JSP Web Applications: Data-Driven Programming Using Tomcat and MySQL
ISBN: 0672323095
EAN: 2147483647
Year: 2002
Pages: 203
Authors: James Turner

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net