Building Web Applications with UML

Description

• Copyright 2000
• Edition: 1st

• Book
• ISBN-10: 0-201-61577-0
• ISBN-13: 978-0-201-61577-7

Building Web Applications with UML is a guide to building robust, scalable, and feature-rich web applications using proven object-oriented techniques. Written for the project manager, architect, analyst, designer, and programmer of web applications, this book examines the unique aspects of modeling web applications with the Web Application Extension (WAE) for the Unified Modeling Language (UML). The UML has been widely accepted as the standard modeling language for software systems, and as a result is often the best option for modeling web application designs.

The WAE extends the UML notation with semantics and constraints enabling developers to model web-specific architectural elements using the Rational Unified Process or an alternative methodology. Using UML allows developers to model their web applications as a part of the complete system and the business logic that must be reflected in the application. Readers will gain not only an understanding of the modeling process, but also the ability to map models directly into code.

Key topics include:

• A basic introduction to web servers, browsers, HTTP, and HTML
• Gathering requirements and defining the system's use cases
• Transforming requirements into a model and then a design that maps directly into components of the system
• Defining the architecture of a web application with an examination of three architectural patterns describing architectures for thin web client, thick web client, and web delivery designs
• Modeling, at the appropriate level of abstraction and detail, the appropriate artifacts, including web application pages, page relationships, navigate routes, client-side scripts, and server-side generation
• Creating code from UML models using ASP and VBScript
• Client-side scripting using DHTML, Java Script, VBScript, Applets, ActiveX controls, and DOM
• Using client/server protocols including DCOM, CORBA/IIOP, and Java's RMI
• Securing a web application with SET, SSL, PGP, Certificates, and Certificate Authorities

0201615770B04062001



Downloads

Source Code

Click below for Source Code related to this title:
conallensource.zip



Sample Content

Table of Contents

(Each chapter concludes with a chapter summary.)

I. INTRODUCTION AND SUMMARY OF WEB-RELATED TECHNOLOGIES.

1. Introduction.

What Is This Book?

Who Should Read This Book?

Book Organization.

2. Web Application Basics.

HTTP.

HTML.

Anchors.

Forms.

Frames.

Web Applications.

Session Management.

Enabling Technologies.

3. Dynamic Clients.

Document Object Model.

Scripting.

JavaScript Objects.

Custom JavaScript Objects.

Events.

Java Applets and Beans.

ActiveX/COM.

Summary.

4. Beyond HTTP and HTML.

Distributed Objects.

RMI.

CORBA.

DCOM.

XML.

5. Security.

Types of Security Risks.

Technical Risk.

Server-Side Risks.

Client-Side Risks.

Security Strategies.

Encryption.

Best Practices.

II. BUILDING WEB APPLICATIONS.

6. The Process.

The Model.

Workflows.

Project Management.

Requirements Gathering.

Analysis.

Design.

Implementation.

Test.

Deployment.

Configuration and Change Management.

Risk.

Iteration.

7. Defining the Architecture.

Examining the Use Cases.

Web Application Architecture Patterns.

Thin Web Client.

Thick Web Client.

Dynamics.

Web Delivery.

8. Requirements and Use Cases.

Requirements.

Gathering Requirements.

Guidelines for Writing Good Requirements.

Prioritization.

Use Cases.

9. Analysis.

Iteration.

Packages.

Defining the Top-Level Model.

Analysis.

Sequence Diagrams.

Collaboration Diagrams.

Activity Diagrams.

10. Design.

UML Extension for Web Applications.

Designing Web Applications.

Partitioning Objects for Thick Web Client Web Applications.

Partitioning Objects for Web Delivery Web Applications.

Elaborating the Design with Sequence Diagrams.

Thin Web Client Design.

Server Pages.

Links.

Forms.

Frames.

Thick Web Client Design.

Web Delivery Design.

DCOM.

RMI/IIOP.

Guidelines for Web Application Design.

11. Implementation.

Server Pages.

Client Pages.

Links.

Frames.

Client Side-Objects.

Server Side Includes.

Appendices.
Appendix A: Web Application Extension for UML.

Description.

Prerequisite Extensions.

Stereotypes.

Well-Formedness Rules.

Comments.

Appendix B: An E-Commerce Use Case ExampleUse Case.

Specification: Browse Catalog.

1. Browse Catalog.

1.1 Goal.

1.2 Brief Description.

2. Flow of Events.

2.1 Basic Flow.

2.2 Alternative Flows.

3. Preconditions.

3.1 Internet Access.

3.2 HTML 3.2-Compliant Browser.

4. Extension Points.

4.1 Add Item to Shopping Cart.

4.2 Checkout Shopping Cart. Appendix C: Glossary ASP Application Sample Model.

Vision Statement.

Top-Level Use Case View.

Analysis Model: Main Diagram.

Analysis Model: Use Case Sequence Diagrams.

Browse Glossary Main Sequence Diagram.

Search Glossary Main Sequence Diagram.

Edit Glossary Sequence Diagram for Entry Use Case.

Design Model.

Top Level Class Diagram.

Use Case Realizations.

Top-Level Logical View.

Server Components Package: Main Class Diagram.

Web Pages Package.

Component View.

Source Code (after implementation).

GlossaryHome.htm.

GetEntries.asp.

ProcessSearch.asp.

EditEntry.asp.

UpdateEntry.asp.

string-util.asp.

ErrorMsg.asp.

global.asa.

Appendix D: Roses Alive! Project Plan Outline.

Iteration 1: Getting started.

Iteration 2: Elaboration of the Vision.

Iteration 3: Realizing Use Cases.

Iteration 4: First Real Executables.

Iteration 5: The System Comes to Life.

Iteration 5: The System Continues to Evolve.

Iteration 5-6: Beta Releases and Updates.

Iteration 7: Initial System Release.

Appendix E: Sample Rational Rose Scripts.

ASPTool.

MakeASPComponents.

Index. 0201615770T04062001

Preface

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,¹ 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 ears² 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 1999

1. 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



Updates

Submit Errata

