Identifies and addresses modeling problems unique to page based web applications, and offers a clear and straightforward solution. Provides enhanced coverage of the latest security concerns regarding Web applications. Softcover.

Jim Conallen is the Web Modeling Evangelist at Rational Software Corporation, where he has continued his work on the development of the Web Application Extension for the Unified Modeling Language. Prior to joining Rational, he was a consultant specializing in full life cycle object-oriented development. He has built client/server and web-based systems in the transportation, telecommunications, and health care domains; has architected large, high-volume transaction processing systems; and has designed and developed applications in C++, Smalltalk, Java, Delphi and Visual Basic. Jim is a frequent speaker on topics ranging from web application modeling to software best practices. He has written for many industry publications, including ASPToday.com, Rose Architect, and Communications of the ACM.

0201730383AB06262002

The first edition of this book hit the streets late in 1999. For the most part, it was based on my experiences in developing Active Server Page-based applications for the retail and healthcare industries. I was an independent consultant then, but shortly before finishing the book I joined Rational Software Corporation. Working for Rational has given me the opportunity to visit and to work with many organizations that are in the process of building Web-centric applications. And I've seen everything, from well-managed teams producing top-quality software to chaotic teams desperately seeking the right guidance to a few others that still seem to be in denial. In the two years since the publication of the first edition, I've also seen the rise of the J2EE platform, and have to say that since then most of my Web application development experience has been with J2EE architectures. As a result, most of the material in this second edition is oriented toward the Java environment. This doesn't mean that .NET developers, or even Cold Fusion and PHP developers, can't build applications with the guidance in this book. You can. It's just that the majority of the examples in the design and implementation chapters, and in the reference applications, are written for JavaServer Page-based applications. The ideas in this book and in the previous edition are all the result of a desire to combine my object-oriented skills and the area of Web application development. I had little problem applying use case analysis, and it wasn't until I started creating analysis and design models that I realized things were going to get difficult. When creating a Web application, my conceptual focus was always on the Web page; and my idea of a model kept revolving around the concept of a site map. I knew that the navigation paths throughout the system were incredibly important to understanding the application and that any system model would have to include them. My earliest attempts at modeling Web applications started with Rumbaugh's OMT (Object Modeling Technique), and later when UML (Unified Modeling Language) version 0.8 was publicly released, I began to apply it. I knew that for any modeling technique to be useful it needed to capture both the relevant semantics of Web-specific elements (e.g., Web pages and hyperlinks) and their relation to the back-end elements of the system (e.g., middle-tier objects and databases). At the time, I found both OMT and UML inadequate to express the things I thought were important in a Web application. Being a somewhat successful object practitioner and engineer, I jumped to the conclusion that a whole new development methodology and notation was needed. After all, if the existing methods and notation didn't have what I needed, then the obvious solution was to invent one. This, of course, is a trap into which many of us in the software industry fall. In my free time, I started to draft new graphical and semantic ways to represent Web application architectures. Proud of my work, I began showing it to two of my colleagues--Joe Befumo and Gerald Ruldolph, both experienced object practitioners. Their immediate reaction was, Why? I tried to explain the issues involved with Web application development and the need for visually expressing their designs. Still, everyone I spoke with continued to think that developing a new method and notation was overkill. I started to rethink what I was doing. I wasn't stuck up enough to think that I was right and everyone else was wrong; I had more homework to do. I reexamined my original needs: to express Web application designs at the appropriate level of abstraction and detail, and most important, as a part of the rest of the system's design. Because UML was taking the industry by storm, I realized that anything I did would have to work with UML. So I went back to UML; t