Building Web Applications with UML (The Addison-Wesley Object Technology Series) - Softcover

Jim Conallen; Conallen, Jim

Softcover

ISBN 10: 0201615770 ISBN 13: 9780201615777

Publisher: Addison Wesley Longman, 1999

Synopsis

Provides a guide to building robust, scalable, and feature-rich Web applications using proven objectoriented techniques. Written for the project manager, architect, analyst, designer, and programmer of Web applications. Examines the unique aspects of modeling Web applications with the Web Application Extension for the UML. DLC: Web site development.

About this title

Review

The Universal Modeling Language (UML) is a flexible and comprehensive way to design and diagram any software development project. Building Web Applications with UML covers the Web Application Extension (WAE) for UML and includes enough background information about Web applications to ease traditional software analysts and designers into the world of the Web.

Author Jim Conallen divides the text into two logical parts: the first is dedicated to explaining the various Web application architectures out there, the second to the process of modeling such systems with UML. The first chapter concisely explains the basics of the standard elements of the Web such as HTML, HTTP, forms, frames, and session management. Subsequent chapters provide an excellent overview to server-side and client-side functionality, delving into key technologies such as Active Server Pages (ASP), Java applets, and XML.

The remainder of the book is devoted to defining the requirements, architecture, and design elements of Web applications using UML. The reader will learn about Use Cases, apply analysis, and represent Web applications with the distinctive graphical elements of UML. A sample ASP application is used to illustrate the concepts. This material may be a level of abstraction above the working coder but is excellent for project managers and system architects. --Stephen W. Plain

Topics covered: Browser/Server interactions, Web page design elements, session management, dynamic client and server languages, Web security, model design, use cases, requirement specifications, analysis, sequence diagrams, and class diagrams.

From the Inside Flap

Late in 1996, I downloaded the preview edition of Microsoft's Active Server Pages. It was my first taste of what could be done on the Web. Even then I could see the potential for sophisticated Web applications. I began to investigate alternative architectures: CGI (Common Gateway Interface) and Allaire's Cold Fusion. Even before then, I had started tinkering with the Java beta and later bought Symantec's CafE to experiment with this new language.

At that time, I was an independent consultant working for AT&T in New Jersey. The project had nothing to do with the Web, so my only opportunity to experiment with this technology was during the evenings and whatever spare time I could find. In the end, it was all worth it. I learned a lot and was prepared for the coming onslaught and frenzy of Web application development.

My first opportunity to build a real Web application came at the request of a friend whose father owned a live cut rose wholesale and retail company, Hortico Nurseries Inc. Hortico was interested opening up a retail sales front on the newly emerging Internet. Together with a mutual friend, Jeff Wilkinson, we built our first production e-commerce site. The site was simple. It allowed customers to browse and to search a database of more than 1,400 varieties of roses and even to place orders. At first, the site didn't generate as many orders as we had hoped, but it did expose Hortico to a new market and certainly helped it's sales grow in other ways. To the best of our knowledge, Hortico was the first Web site to make a comprehensive catalog of rose varieties and pictures available to the Internet community. Jeff has pretty much taken over the management of the site, and I help when I can. He has gone on to win awards for Web site design for some of his other projects, and I moved on to other contracts.

My first professional contract dealing with Web applications was with a small start-up company in the healthcare business. This experience got me even more involved with the subtleties of building Active Server pages (ASP) applications, especially with the issues of managing server-side resources and transaction management in a Web application environment. I learned a lot about the use of client-side scripting, applets, and ActiveX controls. I also learned a valuable lesson about testing applications: Client machines with different operating systems can behave differently with the exact same HTML, Java, and browser code. All of these experiences have driven me even more to a belief that Web applications need to be modeled and built just like any other complex software system. In the years that followed, I continued to experiment with the latest Web technologies and consulted with other companies with Web-related issues.

All throughout my Web application experiences, I tried to practice my object-oriented skills in 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 that things were going to get difficult. When creating a Web application, my conceptual focus was always on the Web page. 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 the understanding of the application and that any model of the system would have to include them.

My earliest attempts at modeling Web applications started with Rumbaugh's OMT (Object Modeling Technique); later, when UML version 0.8 was publicly released, I began to apply it. I knew that for any modeling technique to be useful, it needed to both capture the relevant semantics of Web-specific elements, such as Web pages and hyperlinks and their relations to the back-end elements of the systemo 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 were needed. After all, if the existing methods and notation didn't have what I needed, the obvious solution was to invent new ones. This, of course, is a trap that many of us in the software industry fall into. 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. Yet everyone I spoke with continued to think that developing a new method and notation was a little overkill.

I started to rethink what I was doing. I wasn't so stuck up to think that I was still right and everyone else 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. Since UML was taking the industry by storm, I realized that anything I did would have to work with UML.

So I went back to the UML. By now, it was in version 0.91, and a new concept was included: stereotypes. At first, I was clueless to what a stereotype was. The UML specification is not the easiest reading, after all. It was long and difficult, but I knew that any success in the area of modeling Web applications had to come from this direction. Eventually, I started to understand what was meant by stereotyping and the other extension mechanisms: tagged values and constraints. I was finally starting to see light at the end of the tunnel.

I now had a mechanism with which I could introduce new semantics into the UML grammar without disturbing the existing semantics. I always knew that the key was to provide a consistent and coherent way to model Web-specific elements at the right level of abstraction with the models of the rest of the system. The UML extension mechanism provided me with the framework to do so.

The next step was to start defining the extension by creating stereotypes, tagged values, and constraints. For me, the ability to use custom icons in diagrams with stereotyped elements went a long way to ease my concern for intuitive diagrams; also, Rational Rose, my visual modeling tool of choice,1 had just introduced a way to use one's own stereotypes in Rose models. I quickly created a set of icons for Web page abstractions. I tried to make them consistent, mostly rectangular with the stereotype indication in the upper-left corner. I used filled-in dog ears to represent pages and unfilled dog ears2 to denote components. Icons without any dog ears typically represented contained classes, which cannot be requested directly by a Web browser. The icon for Web page components is pretty much a copy of the icon used by the three amigosoGrady Booch, James Rumbaugh, and Ivar Jacobsonoin their book, The Unified Modeling Language User Guide (Addison Wesley Longman, 1999).

Looking back, I remember spending less than a day to draw up the icons. I didn't spend much time on it then, since I always believed that eventually someone with a little more experience would design some meaningful ones. In the almost two years since then, they have remained essentially the same. I am surprised that I have received absolutely no comments on the style of the icons from the hundred or more people who have been using them. I think that for this version of the extension, the style of icons is gonna stick.

As the extension evolved and a lot of the details and inconsistencies were getting corrected, I always kept an eye out for code-generation possibilities. In my mind, the modeling technique could be validated if it were possible, in theory only, to unambiguously generate and reverse engineer code. Since most of my experience was with Microsoft Active Server Pages, I began creating Rational Rose scripts to forward engineer ASP code. I've tailored the scripts to create Java Server Pages code also; from a code structure point of view the two are very similar.

From that point, things proceeded at a tremendous rate. I published a white paper on the Internet and presented the topic at the 1998 Rational User's Conference in Orlando, Florida. Grady Booch took an interest in the work and encouraged me. Addison Wesley Longman asked whether I was interested in expanding the topic into a book. If I had only known how difficult was going to be to write, I'm not sure that I would have agreed. I followed the original white paper with a stream of other articles for both online and print publications and started to get a regular stream of e-mail comments on the extension.

By the time this book hits the streets, I will have introduced the topic at five professional conferences and written at least a dozen articles and white papers on the topic. Ideally, this book will continue to propel the recognition that Web application development is a serious topic and one from which we can learn and adopt the successful practices of the past.

Jim Conallen
August 19991. All of the sample models used in this effort were developed with Rational Rose. I had worked with the Rose tools for many years prior to this and have recently given up independent consulting to join the Rational team. (My praise of the Rose tool, however, would have been made even if I were not a current Rational employee.)
2. A dog ear is the slang term for a bent or folded corner of paper.
0201615770P04062001

Edition details

• Publisher: Addison Wesley Longman
• Publication date: 1999
• ISBN 10: 0201615770
• ISBN 13: 9780201615777
• Binding: Paperback
• Language: English
• Edition number: 1
• Number of pages: 320