1. Modeling Web Based Applications with UML Terry Quatrani Rose Evangelist Terry Quatrani Rose Evangelist

2. Web Application  A web system where user input (navigation and data input) effects the state of the business.

3. Web Application Architecture  There are a number of web application architectures and components in use today. All of which can benefit by applying Rational’s best practices and modeling.  This presentation will focus on page based web applications. This type of enabling technology relies on technologies and products like Active Server Pages (ASP), Java Server Pages (JSP), Servlets, CGI, etc.  Other technologies like RMI, DCOM, IIOP, are beyond the scope of this presentation, but not the ability to capture and understand with UML.

4. Web CentricClassic Browser Web Server Page Request External Systems File System Web Application Architecture Application Server Data  Browsers request web pages.  The web server coordinates the delivery of HTML documents and any processing necessary to build those pages.

5. Modeling  Today’s software is complex  Modeling helps us manage this complexity  Other benefits to modeling  Communication  Code generation  Metrics gathering The key to effective modeling is to do so at the proper level of abstraction and detail The key to effective modeling is to do so at the proper level of abstraction and detail

6. The Process  The Rational Unified Process is a Software Engineering Process.  It provides a disciplined approach to assigning tasks and responsibilities within a development organization.  It captures many of the best practices in modern software development  It supports object oriented techniques and component based software development  It is a controlled iterative process  It is use case driven  It focuses on early development and baselining of a robust software architecture

7. Requirements Set  A collection of project artifacts that captures and presents information which defines the required capabilities of the system.  Vision Document, Project Glossary, Supplementary Requests  Requirements Attributes  Use Case Model  Storyboards, User Interface Prototypes  Requirements form the contract between the developers of a system and the users and stake holders.  They must be understandable by both parties.

8. The Vision  A software development project begins with a Vision document.  The Vision is a general vision of the core project's requirements, and provides the contractual basis for the more detailed technical requirements.  It is important to express the vision in terms of its use cases and primary scenarios as these are developed, so that you can see how the vision is realized by the use cases.

9. Use Cases  A use case expresses the dialog between users and the system  Use cases express what the system should do without specifying how  Use cases form the basis for testing and the systems documentation.  The use case model expresses all of the system’s use cases and their relationships to each other.

10. Use Cases in a Web Application  Most of the techniques for creating and expressing use cases in a web application are the same as when building other software systems.  The vocabulary used in web application use cases makes heavy use of some web specific terms:  Navigate, Browse  Hyperlink, Link  Page, Window  Use case specifiers need to be conscious of limitations of the user interface.

11. Web Application Use Case Diagram

12. Use Case Analysis  Goals  Identify the classes which perform a use case’s flow of events.  Distribute the use case behavior to those classes, using use- case realizations.  Identify the responsibilities, attributes and associations of the classes.

13. Activity Diagrams  Use Cases can be expressed in detail with the UML activity diagram.  Activity diagrams express all scenarios

14. Sequence Diagramming Use Case Scenarios : Customer System request( home page) select category A customer connects to the application, by pointing the browser to the URL for the application's home page. display category list display home page, top level categories The customer browsers through the catalog. The customer can select a category to see a list of all the products in that category. Browsing Searching The customer enters in a textual phrase to search the product catalog with. enter search phrase display search results The system searches the database for any product that contains the search text. All products that match are returned to the customer in a list. The customer selects one of the search results. select product display product The system displays the product. If the product has sub-items (for example male and female versions) these are listed.

15. Analysis Classes  Analysis level classes are categorized into: Boundary Controller Entity

16. Analysis Classes in Web Applications  Boundary classes in a web application often represent the web pages of the system.  When defining these classes it is important not to overload their responsibilities.  Web applications tend to have many more boundary and controller objects that a comparable client server application.

17. Analysis Patterns - Multipage  Stimulus/Response behavior  Boundary and controllers are very specialized

18. Analysis Patterns - One Page  Few boundary objects  Often used for XML based web applications  Controllers are specialized and are typically used to create XML documents.

19. Use Case Realizations

20. Analysis Model Evolves into Design Model  The activities of design take the analysis model and evolve it into a model that can be directly mapped into code and components.  When designing web applications it is important to model the artifacts of the system.  What you choose to model has an enormous impact on your understanding of the problem and the shape of the solution.

21. What to model  The important things to model in a web application are the web pages, hyperlinks, forms, applets, etc. Those components of the system that designers design and the implementers implement.  It is not necessary to model things like animated GIFs or flyover help, since these are not a direct result of a business requirement.  The UML model of a system should be focused on describing the business logic of the system, and not be concerned with the look and feel of the user interface. These details are better captured in a separate User Interface Model.

22. Modeling Web Pages  Scripted or compiled web pages are architecturally significant components that need to be integrated into system’s design model.  A web page maps directly to a component in the Component View.  Its not obvious where web page functions (scripts) get mapped.

23. Modeling Web Page Behavior  Scripted pages define operations that execute on the server and potentially operations that execute on the client (DHTML).  Mapping a scripted web page to a class in the logical view, poses problems.  How do we know where the operations are executed?  What types of relationships can these classes have?

24. Extend the UML  The solution is to separate the server side and client side behaviors into separate classes.  Use the UML extension mechanism’s stereotypes to define a new semantic behavior for these elements.  Expand the extension to define stereotypes for associations, attributes and operations.

25. Stereotypes, Tagged Values and Constraints  Stereotypes - Allow us to define new semantics for a modeling element. Stereotypes are used to make a normal modeling element (like a class or association) represent a new type of element.  Tagged Values - Allow us to “tag” new information to a modeling element. Tagged values are used to capture additional information about an element, often this information is related to code generation or versioning.  Constraints - Allow us to define new rules for working with modeling elements.

26. Server Pages  A > is a class stereotype that abstracts the web page’s behavior on the server.  operations are executed on the server  attributes are variables with page scope  associations are with server side resources (components, TPMs, databases, external systems, …)

27. Client Page  A > abstracts the behavior of a web page on the client.  Operations are executed by the browser (JavaScript)  Attributes are globally accessible by all the client’s scripts.  Associations are with client side resources (Applets, ActiveX controls, plug-ins, DOM).

28. Server and Client Page Relationship  > and > classes in the logical view have a special stereotyped relationship: >.  Server pages build client pages. The resulting output of a server page is an HTML stream that is sent to the requesting browser.

29. Web Page Components  Components represent physical artifacts of the system. Web pages are physical artifacts.  A > component realizes server and client pages.

30. Hyperlinks  Hyperlinks between pages are expressed with > stereotyped associations from a client page to another page (client or server). Hyperlink parameters are expressed with tagged values. A link to a client page or the server page that builds it is equivalent.

31. Server Side Collaborations

32. Client Side Collaborations

33. Forms  The most common data input mechanism for web applications is the HTML form.  Forms are modeled with another class stereotype: >.  Properties of a form are its input fields.  A > class does not define operations since any operation in a form is really owned by the client page.

34. Processing Forms

35. Beginning Design  Design begins by examining the use cases, and the analysis model  Analysis level classes are evolved into design level classes.

36. Model Evolution  Boundary classes have a tendency to evolve into > and > classes.  Controller classes have a tendency to evolve into >  Entity classes have a tendency to evolve into server tier classes.

37. Designing Client Pages  Client pages are an abstraction of a web page as seen on the client (HTML page).  Client page attributes represent JavaScript variables, client page operations represent Java Script functions.  Normal client page associations are only to client side objects (applets, controls, JavaScript objects).  Client pages can have > associations to other client pages or server pages.

38. Designing Forms  Forms are always contained (aggregation) by a client page.  They conceptually represent HTML forms.  Attributes represent the form’s fields  Forms typically have > relationships to server pages (which process their information).

39. Designing Server Pages  Server pages orchestrate the server side activity and are responsible for building the HTML response.  Server page attributes represent page scoped variables, operations represent functions that are processed on the server.  Normal server page associations are with server side objects (business objects, database connections, etc.)  If a server page is responsible for delivering an HTML response it has a > association to a client page.

40. Components  A component is a distributable part of the run time system.  Components are things like EXEs, DLLs, and libraries.  Components in a web application are the scripted web pages (JSP, ASP), servlets, CGI modules, or web server DLLs (ISAPI, NSAPI).  Component diagrams end up being site maps.

41. Enterprise JavaBeans  Response to Java Specification Request (JSR) 26  JSR-000026 UML/EJB Mapping Specification  Endorsed by Sun, Rational, and IBM  Defines standard UML extensions that combine and/or refine existing UML constructs to create a dialect to describe EJB-based artifacts  Current version supports UML 1.3 and EJB 1.1

42. EJB Stereotypes  Logical Model  Class Diagram > class > method > class > method > class  Physical Model  Component Diagram > component

43. Modeling Enterprise JavaBeans

44. Logical Data Models  The structure of the database can be as important to an application as the business objects.

45. Data Modeling Profile  Tables are modeled as stereotyped classes.  Columns are modeled as attributes.  Constraints and triggers are stereotyped and modeled in the operation compartment.

46. Requirements : Customer System select category display home page, top level categories request( home page) display category list enter search phrase display search results select product display product

47. Analysis: Object Discovery

48. Analysis: Realizations

49. Design

50. Connecting all the Tiers WEB Business Object Tier Data Tier

51. Summary  When designing web applications it is critical to model the right things and at the right level of abstraction and detail.  UML can be extended to model web specific components like pages, hyperlinks, client scripts and forms at the level of abstraction and detail suitable for web application designers and architects.  Web pages are architecturally significant elements that belong in the Design Model.  Presentation elements (like fly over help and animations) do not belong in the business logic model.

52. Additional Resources  Whitepapers (Rational Web Site)  Context Whitepaper, Per Kroll  Designing web applications with UML, J. Conallen  Books (Addison Wesley Longman)  The Unified Modeling Language Users Guide: G. Booch, J. Rumbaugh, I. Jacobson  The Unified Modeling Language Reference Guide: J. Rumbaugh, G. Booch, I. Jacobson  The Unified Process: I. Jacobson, G. Booch, J. Rumbaugh  The Rational Unified Process an Introduction: P. Krutchen  Building Web Applications with UML: J. Conallen  Visual Modeling with Rational Rose 2000 and UML: T. Quatrani