Guideline: Building Web Applications with the UML








var backPath = './../../../';
var imgPath = './../../../images/';
var nodeInfo=[{view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_Jvt1cAIaEdqEutyfYo0quQ", "_jijhYAIaEdqEutyfYo0quQ", "_n7ZcgN7REdmjRZts2c4ZjQ", "{952A9CE9-D5A3-43AC-980D-0B9298F3872E}", "4.559124609104376E-305"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_jD8dUAIbEdqEutyfYo0quQ", "_2ClPcDIcEdqDs_9ORT1Rig", "4.559124609104376E-305"]}];
contentPage.preload(imgPath, backPath, nodeInfo, '', false, false, false);










Guideline: Building Web Applications with the UML















This guideline takes Use-Case Analysis a step further to jump-start the design of Web applications.






Relationships



Related Elements


Design Class






Main Description



References The following books and documents are references for these guidelines: Building Web Applications with UML, by Jim Conallen [CONA99] The Whitepaper: Modeling Web Application Architectures with UML Elaborate on Use-Case Analysis The thing that is different compared to what you find in Task: Use-Case Analysis is that the boundary classes are more focused and singular in purpose. Objects of these classes have a short life, and any client state (in web pages) needs to be managed explicitly by specific mechanisms. For example, Microsoft Active Server Pages use "cookies" as an index into a map of the state of all the currently active clients. Also, when you read the specification of a use case, the following applies:  Any mention of a web page translates to a boundary class.  Any mention of a hyperlink translates to an association from a boundary class to another boundary class or controller class.  Verbs or descriptions of processes tend to map to controller classes.  Nouns map to entity classes.  The boundary class, through which communication is initiated, talks to a controller class. The controller class typically will not respond back through the same instance of this boundary class. Using Interaction Diagrams As use-case analysis is going on, the scenarios can be described with sequence diagrams. This helps validate the existence of analysis objects against a scenario of a use case. If analysis objects are discovered not to participate in any of your scenarios, they are suspect and need to be reevaluated. The risk here is that if you go too deep in detail, the diagrams become large and unmanageable. To avoid this, concentrate on short discrete scenarios, and only include boundary and principal controller and entity objects. Remember that in web applications boundary objects have a short lifespan. A boundary class may however be instantiated several times during the execution of a scenario, meaning that there are several boundary objects instantiated from the same class in the diagram. The actor in an analysis level sequence diagram interacts with a boundary object. A navigate message is sent from the actor to the boundary object. Creating Initial Design Classes Initial Boundary Class Designs A boundary class can be mapped to a client page class. If the boundary class involves inputting information, you would typically associate it with a form (or web form) through aggregation. A form can be modeled as a nested class of the client page, since its entire lifecycle is governed by the client page. Forms always have a submit relationship to a server page, which processes the form's values, ultimately leading to a new returned client page. If the user interface requires some dynamic behavior on the client, the easiest way this can be accomplished is through the use of dynamic HTML on the client. In the design model, this usually appears as operations on the client page. Operations on the client page map directly to java script functions. Attributes of a java page map directly to page scoped variables of the page. Dynamic HTML event handlers are captured as tagged values. If the user interface has very sophisticated behavior, you would consider associating an applet with the boundary class, using an aggregation. If your architecture is based on a distributed object system (such as RMI, IIOP, or DCOM), then the client page may reference interfaces to components that communicate directly with the server using RMI, IIOP, or DCOM, circumventing HTTP. These types of relationships are usually stereotyped <<rmi>>, <<iiop>>, or <<dcom>> to indicate to the designer any areas where network traffic will happen, thus being candidate bottlenecks. Initial Entity Class Designs In designing a web application, the only thing different about entity classes is, if the object resides within the scope of the client page, the entity object will map to a java script object. Initial Controller Class Designs Control classes map to server pages. Controllers express and coordinate the business logic, and coordinate other logics. They typically reside on the server. Many controller objects are responsible for building client pages (essentially, they stream HTML as their principal output). Controller objects can interact with server-side resources, such as databases, middle tier components, transaction monitors, and so forth.  Controller classes typically map to server-side scripted web pages (active server pages, java server pages).





©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved.







contentPage.onload();