Transcript Modeling Web Pages - Tribury Media, LLC

Modeling Web Based Applications
with UML
Terry Quatrani
Rose Evangelist
Web Application
 A web system where user input (navigation and data
input) effects the state of the business.
Network
(Intranet/
Internet)
Client Browser
Database
Web/Application Server
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.
Web Application Architecture
Application
Server
Page
Request
Data
Web
Server
External
Systems
Computer
Browser
Web Centric
File System
Classic
 Browsers request web pages.
 The web server coordinates the delivery of HTML
documents and any processing necessary to build
those pages.
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 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
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.
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.
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.
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.
Web Application Use Case Diagram
<<extend>>
Search
Browse Catalog
<<extend>>
View Details
Customer
Checkout
Order Server
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 usecase realizations.
 Identify the responsibilities, attributes and associations of the
classes.
Activity Diagrams
 Use Cases
can be
expressed
in detail
with the
UML
activity
diagram.
 Activity
diagrams
express all
scenarios
Customer
System
Navigate to home
page
Build home page
Navigate to
Catalog
Build catalog
home
shop controller
[ category available ]
[ search form available ]
[ product available ]
[ add product available ]
Select category
Build category
Enter and submit
search criteria
Search catalog
Request product
detail
Get product details
Add product to
cart
Navigate to cart
Update cart
Build cart
Edit line item
quantities
Request Checkout
Activity Diagram: Shop /
Checkout
Sequence Diagramming Use Case Scenarios
System
: Customer
A customer connects to the application, by pointing
the browser to the URL for the application's home
page.
Browsing
The customer browsers through the catalog. The
customer can select a category to see a list of all the
products in that category.
request( home page)
display home page, top level categories
select category
display category list
Searching
enter search phrase
The customer enters in a textual phrase to search
the product catalog with.
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.
select product
The customer selects one of the search results.
The system displays the product. If the product has
sub-items (for example male and female versions) these
are listed.
display product
Analysis Classes
 Analysis level classes are categorized into:
Boundary
Controller
Entity
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.
Analysis Patterns - Multipage
 Stimulus/Response
behavior
 Boundary and
controllers are very
specialized
Searchable Criteria
Home
Request Search
Search Form
Inventory
Process search
Search Results
Product
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.
PatientRepository
Patient Search
Patient
Patient Record
Health Record
Update Patient
Visit Note
Get Medical History
Payment Record
Use Case Realizations
: Customer
: _Application Home Page
A customer connects to the application, by pointing
the browser to the URL for the application's home
page.
The actor can either browse or search through the store catalog.
Browsing
The customer browsers through the catalog. The
customer can select a category to see a list of all the
products in that category.
Search Alterrnate
Instead of browsing the catalog hierarchy the actor
can search. The alternate's post condition is a
screen with links to individual products.
Sequence Diagram: Shop for pets realization /
Searching
The customer selects one of the displayed products.
The system displays the product. If the product has
sub-items (for example male and female versions) these
are listed.
: _Category Listing
: _Product Information
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.
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.
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.
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?
<<web page>>
ScriptedPage
serverAttribute
clientAttribute
serverOperation()
clientOperation()
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.
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.
Server Pages
 A <<Server Page>> 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, …)
Client Page
 A <<Client Page>> 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).
Server and Client Page Relationship
 <<Server Page>> and <<Client Page>> classes in the
logical view have a special stereotyped relationship:
<<build>>.
 Server pages build client pages. The resulting output of
a server page is an HTML stream that is sent to the
requesting browser.
<<build>>
Web Page Components
 Components represent physical artifacts of the system.
Web pages are physical artifacts.
 A <<web page>> component realizes server and client
pages.
<<build>>
<<web page>>
Hyperlinks
 Hyperlinks between pages are expressed with <<link>>
stereotyped associations from a client page to another
page (client or server).
<<link>>
ShoppingCart
Checkout
<<link>>
{ ProdID }
<<link>>
0..*
ShippingOptions
ProductDetail
Hyperlink
parameters are
expressed with
tagged values.
A link to a client
page or the server
page that builds it
is equivalent.
Server Side Collaborations
Session
cart
CartItem
quantity : int
Checkout
updateCart()
validateCart()
startOrder()
<<build>>
ShoppingCart
clientIP : string
+myCart
createTime : date
sessionID : long
1
items()
itemCount()
total()
createOrder()
+items total()
0..n tax()
shipWeight()
+theProduct
Product
name : string
description : string
unitPrice : Currency
unitWeight : float
PaymentInfo
validateFields()
onSubmit()
onBodyLoad()
Client Side Collaborations
Calendar
value : Date
style : long
TimeCard
validate
computeHours
defaultProject
nextMonth()
refresh()
today()
<<ActiveX>>
DataGrid
rows : int
cols : int
currentCell()
value()
scroll()
Forms
 The most common data input mechanism for web
applications is the HTML form.
 Forms are modeled with another class stereotype:
<<Form>>.
 Properties of a form are its input fields.
 A <<Form>> class does not
define operations since any
operation in a form is really
owned by the client page.
Processing Forms
PaymentInfo
validateFields()
onSubmit()
onBodyLoad()
<<submit>>
PaymentInfoForm
CCType : string
CCNumber : string
ExpDate : string
Name : string
ProcessPaymentInfo
Beginning Design
 Design begins by examining the use cases, and the
analysis model
 Analysis level classes are evolved into design level
classes.
Model Evolution
 Boundary classes have a tendency to evolve into <<client
page>> and <<form>> classes.
 Controller classes have a tendency to evolve into
<<server pages>>
 Entity classes have a
tendency to evolve
into server tier
classes.
Customer
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 <<link>> associations to other
client pages or server pages.
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 <<submit>> relationships to server
pages (which process their information).
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 <<build>> association to a client page.
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.
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
EJB Stereotypes
 Logical Model
 Class Diagram
•
•
•
•
•
•
•
•
•
<<EJBHomeInterface>>
<<EJBHomeMethod>>
<<EJBCreateMethod>>
<<EJBFinderMethod>>
<<EJBRemoteInterface>>
<EJBRemoteMethod>>
<<EJBSession>>
<<EJBEntity>>
<<EJBPrimaryKey>>
class
method
method
method
class
method
class
class
class
 Physical Model
 Component Diagram
• <<EJBDeploymentDescriptor>>
• <<EJB-JAR>>
component
component
Modeling Enterprise JavaBeans
E
shoppingCartEJB
+ context : EntityContext
<<EJBCreateMethod>> + ejbCreate() : shoppingCartEJBPK
<<EJBCreateMethod>> + ejbPostCreate() : void
+ ejbActivate() : void
+ ejbPassivate() : void
+ ejbLoad() : void
+ ejbStore() : void
+ ejbRemove() : void
+ setEntityContext(ctx : EntityContext) : void
+ unsetEntityContext() : void
<<EJBRemoteMethod>> + businessOperation() : void
<<EJBPrimaryKey>>
shoppingCartEJBPK
+ hashCode()
+ equals()
Remote
shoppingCart
<<EJBRemoteMethod>> + businessOperation() : void
Home
shoppingCartHome
<<EJBFinderMethod>> + findByPrimaryKey(primaryKey : shoppingCartEJBPK) : shoppingCart
<<EJBCreateMethod>> + create(primaryKey : shoppingCartEJBPK) : shoppingCartEJBPK
Logical Data Models
 The structure of the database can be as important to an
application as the business objects.
<<Identifying>>
<<Non-Identifying>>
1
0..*
ORDERS
ACCOUNT
1
0..*
1
<<Identifying>>
0..*
LINEITEM
ITEM
<<Non-Identifying>>
0..*
0..*
1
PRODUCT
0..*
<<Non-Identifying>>
1
CATEGORY
<<Non-Identifying>>
0..1
INVENTORY
SUPPLIER
ORDERSTATUS
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.
Requirements
Navigate to home
page
Build home page
: Customer
Build catalog
request( home
page)
home
Navigate to
A customer connects to the application, by pointing
Catalog
the browser to the URL for the application's home
page.
Browsing
display home page, top level categories
shop controller
The customer browsers through the catalog. The
customer can select a category to see a list of all the
[ category available ]
Select category
products in that category.
Searching
Shop for pets
Customer
[ search form available ]
<<include>>
Build category
display category
list
Search
catalog
enter search
phrase
Request product
display search results
The system searches the database for any product
detailthat
contains the search text. All products that match are
returned to the customer in a list.
[ add product available ]
The customer selects one of the search results.
Add product to
cart
Sign in
select category
Enter and submit
search criteria
The customer enters in a textual phrase to search
the product catalog with.
[ product available ]
System
The system displays the product. If the product has
sub-items (for example male and female versions) these
are listed.
Navigate to cart
The customer can add the product to the cart, or can
request detail information to be displayed on the product
or one of its sub items.
Edit line item
The customer selects a particular product in the list.
quantities
the application displays detailed information about the
Request
Checkout
selected
product.
Get product details
select product
Update cart
display product
Build cart
Analysis: Object Discovery
_Application Home Page
_Catalog
_Browse
0..n
_Category
_Category Listing
0..n
_Get Product Information
_Product Information
_Product
Analysis: Realizations
System
: Customer
A customer connects to the application, by pointing
the browser to the URL for the application's home
page.
: _Application Home Page
request( home page)
request
: _Browse
: _Catalog
: _Category
display home page, top level categories
select category
select category
get top categories
Browsing
display category list
The customer browsers through the catalog. The
customer can select a category to see a list of all the
products in that category.
enter search phrase
Searching
display search results
get information
select category
The customer enters in a textual phrase to search
the product catalog with.
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.
The system displays the product. If the product has
sub-items (for example male and female versions) these
are listed.
The customer can add the product to the cart, or can
request detail information to be displayed on the product
build
select product
display product
: _Category Listing
Design
Catalog
name
Home
getCategories()
<<link>>
_Application Home Page
_Catalog
CATEGORY
BrowseCatalog
DESCN : VARCHAR2
NAME : VARCHAR2
CATID : CHAR
<<build>>
Category
_Browse
CategoryListing
id0..n
: String
name : String
description : String
<<PK>> PK_CATEGORY()
+PK_CATEGORY
1
<<link>>
<<Non-Identifying>>
getProducts()
_Category
_Category Listing
GetProduct
<<build>>
_Get Product Information
name : String
id : String
description : String
available()
_Product Information
0..*
PRODUCT
0..nProduct
Product Info
+FK_PRODUCT_1
_Product
DESCN : VARCHAR2
NAME : VARCHAR2
CATEGORY : CHAR
PRODUCTID : CHAR
<<PK>> PK_PRODUCT()
<<FK>> FK_PRODUCT_1()
Connecting all the Tiers
Account
getDetails()
changeContactInformation()
AccountHome
create()
findByPrimaryKey()
-acctEjb
Business Object
Data Tier
Tier
Connection
<<EJBEntity>>
AccountEJB
AccountWebImpl
AccountWebImpl()
AccountWebImpl()
performUpdate()
AccountEJB()
<<EJBCreateMethod>> ejbCreate()
ejbRemove()
setEntityContext()
ejbLoad()
ejbStore()
<<EJBFinderMethod>> ejbFindByPrimaryKey()
unsetEntityContext()
ejbActivate()
ejbPassivate()
<<EJBCreateMethod>> ejbPostCreate()
changeContactInformation()
getDetails()
getDBConnection()
+account
CreditCard
<<use bean>>
+card
BrowseCatalog
<<build>>
GetProduct
-dbConnection
-dbConnection
userId : String
status : String
<<link>>
CategoryListing
ContactInformation
telephone : String
email : String
-info familyName : String
givenName : String
+contact
ContactInformation()
getGivenName()
getFamilyName()
getEMail()
getAddress()
getTelephone()
toString()
WEB
-info
AccountDAO
userId : String
status : String
getUserId()
getStatus()
getContactInformation()
setUserId()
setStatus()
setContactInformation()
create()
load()
store()
remove()
findByPrimaryKey()
userExists()
isValidData()
insertAccount()
selectAccount()
deleteAccount()
updateAccount()
ACCOUNT
COUNTRY : VARCHAR2
FIRSTNAME : VARCHAR2
LASTNAME : VARCHAR2
ADDR2 : VARCHAR2
ADDR1 : VARCHAR2
STATUS : CHAR
ZIP : VARCHAR2
PHONE : VARCHAR2
EMAIL : VARCHAR2
USERID : VARCHAR2
STATE : VARCHAR2
CITY : VARCHAR2
<<PK>> PK_ACCOUNT()
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.
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