Software Engineering: A Practitioner’s Approach,
6/e
Chapter 18
Analysis Modeling for WebApps
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.
For University Use Only
May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
1
Analysis
Content Analysis. The full spectrum of content to be provided by the WebApp
is identified, including text, graphics and images, video, and audio data.
Data modeling can be used to identify and describe each of the data
objects.
Interaction Analysis. The manner in which the user interacts with the WebApp
is described in detail. Use-cases can be developed to provide detailed
descriptions of this interaction.
Functional Analysis. The usage scenarios (use-cases) created as part of
interaction analysis define the operations that will be applied to WebApp
content and imply other processing functions. All operations and functions
are described in detail.
Configuration Analysis. The environment and infrastructure in which the
WebApp resides are described in detail.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
2
When Do We Perform Analysis?

In some WebE situations, analysis and design merge.
However, an explicit analysis activity occurs when …





the WebApp to be built is large and/or complex
the number of stakeholders is large
the number of Web engineers and other contributors is large
the goals and objectives (determined during formulation) for the
WebApp will effect the business’ bottom line
the success of the WebApp will have a strong bearing on the
success of the business
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
3
The User Hierarchy
SafeHomeAssured.com
user
guest
regist ered
user
new cust omer
cust omer serv ice
st aff
exist ing cust omer
Figure 18.1 User hierarchy f or Saf eHomeAssured.com
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
4
Use-Case Diagram
describe
home lay out
<<i n c l u d e >>
peruse
desc ript ive
c ont ent
cust omize
Saf eHome
s elec t
Saf eHome
component s
<<i n c l u d e >>
<<i n c l u d e >>
s ave
c onf igurat ion
c us t omiz at ion f unc t ionalit y
log-in t o
Saf eHomeA s sured.com
v iew
shopping c art
<<i n c l u d e >>
purc has e
conf igurat ion
new c ust omer
<<i n c l u d e >>
provide
purchase dat a
recall sav ed
conf igurat ion
<<i n c l u d e >>
complet e
Saf eHome order
e-commerc e f unct ionalit y
Figure 18.2 Use-case diagram f or new-cust omer
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
5
Refining the Use-Case Model


Use-cases are organized into functional packages
Each package is assessed [CON00] to ensure that it is:




Comprehensible—all stakeholders understand the purpose of the
package
Cohesive—the package addresses functions that are closely related to
one another
Loosely coupled—functions or classes within the package collaborate
with one another, but collaboration outside the package are kept to a
minimum.
Hierarchically shallow—deep functional hierarchies are difficult to navigate
and hard for end-users to understand; therefore, the number of levels within a
use-case hierarchy should be minimized whenever possible.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
6
The Content Model

Content objects are extracted from use-cases



examine the scenario description for direct and indirect references to
content
Attributes of each content object are identified
The relationships among content objects and/or the
hierarchy of content maintained by a WebApp


Relationships—entity-relationship diagram or UML
Hierarchy—data tree or UML
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
7
Data Tree
Market ingDescript ion
Phot ograph
part Number
part Name
component
part Type
descript ion
TechDescript ion
Schemat ic
Video
price
WholesalePrice
Ret ailPrice
Figure 1 8 .3 Dat a t ree for aSafeHom e c om ponent
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
8
Analysis Classes



Analysis classes are derived by examining
each use-case
A grammatical parse is used to identify
candidate classes
A UML class diagram is developed for each
analysis class
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
9
Analysis Class Example
BillOfMat erials
Product Component
1
ident ifier
priceTot al
part Number
part Name
part Ty pe
descript ion
price
addEnt ry( )
delet eEnt ry( )
edit Ent ry( )
name( )
sav e( )
comput ePrice( )
creat eNewIt em( )
get Descript ion( )
get TechSpec
1
*
*
Sensor
Camera
Cont rolPanel
Soft Feat ure
BoMIt em
quant it y
price
addt oList( )
delet efromList( )
Figure 18.4 Analysis classes f or use-case: select Saf eHome component s
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
10
The Interaction Model

Composed of four elements:
use-cases
 sequence diagrams
 state diagrams
 a user interface prototype
Each of these is an important UML notation and has
been described in Chapter 8


These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
11
Sequence Diagram
:Room
:FloorPlan
:Product
Component
:Billof
Mat erials
FloorPlan
Reposit ory
BoM
Reposit ory
new cust o mer
d e sc ri b e s
ro o m *
p l a c e s ro o m
in f loor plan
sa v e f l o o r p l a n c o n f i g u ra t i o n
se l e c t s p ro d u c t c o m p o n e n t *
a d d t o Bo M
sa v e b i l l o f m a t e ri a l s
Figure 18.5 Sequence diagram f or use-case:select Saf eHome component s
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
12
State Diagram
Validat ing user
select “log-in”
Select ing user act ion
userid
validat ed
syst em st at us=“input ready ”
display msg = “ent eruserid”
display msg =“ent er pswd”
password v alidat ed
n e w cu st o m e r
ent ry / log-in request ed
do: run user validat ion
exit / set user access swit ch
selec t ot her f unct ions
sy st em st at us=“link ready”
display : navigat ion choices”
ent ry/ v alidat ed user
do: link as required
exit / user act ion select ed
cust omiz at ion complet e
select e-c ommerce (purchase) f unct ionalit y
select cust omizat ion f unct ionalit y
next select ion
Cust omizing
select descript iv e
cont ent
syst em st at us=“input ready ”
display: basic inst ruct ions
Def ining room
room being def ined
ent ry/ v alidat ed user
do: process user select ion
exit / cust omiz at ion t erminat ed
select descript iv e
cont ent
Sav ing f loor plan
syst em st at us=“input ready ”
display: st orage indicat or
ent ry/ f loor plan sav e select ed
do: st ore f loor plan
exit / save complet ed
syst em st at us=“input ready”
display: roomdef . window
ent ry/ roomdef . select ed
all rooms do: run room queries
def ined
do: st ore room v ariables
exit / room complet ed
select sav e f loor plan
select ent er room in f loor plan
Building f loor plan
select descript ive
cont ent
sy st em st at us=“input ready”
display : f loor plan window
ent ry/ f loor plan select ed
do: insert room in place
do: st ore f loor plan v ariables
exit / room insert ion complet ed
room insert ion complet ed
Figure 1 8 .6 Part ial st at e diagram f or n e w c u s t o m eint
r eract ion
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
13
The Functional Model

The functional model addresses two processing
elements of the WebApp



user observable functionality that is delivered by the WebApp to
end-users
the operations contained within analysis classes that implement
behaviors associated with the class.
An activity diagram can be used to represent processing
flow
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
14
Activity Diagram
init ialize t ot alCost
no c omponent s remain onBoMList
c omponent s remain on BoMList
invoke
calcShipping Cost
ret urns:
shipping Cost
invoke
det ermineDiscount
ret urns: discount
discount >0
g et price and
quant it y
lineCost =
price x quant it y
add lineCost t o
t ot alCost
t ot alCost=
t ot alCost - discount
discount < = 0
t axTot al=
t ot alCost x t axrat e
priceTot al =
t ot alCost + t axTot al
+ shipping Cost
Figure 1 8 .7 Act ivit y diagram f or c o m p u t e Pr i (c)e o p e r a t i o n
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
15
The Configuration Model

Server-side




Server hardware and operating system environment must be
specified
Interoperability considerations on the server-side must be
considered
Appropriate interfaces, communication protocols and related
collaborative information must be specified
Client-side


Browser configuration issues must be identified
Testing requirements should be defined
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
16
Relationship-Navigation Analysis


Relationship-navigation analysis (RNA) identifies relationships
among the elements uncovered as part of the creation of the
analysis model
Steps:





Stakeholder analysis—identifies the various user categories and
establishes an appropriate stakeholder hierarchy
Element analysis—identifies the content objects and functional
elements that are of interest to end users
Relationship analysis—describes the relationships that exist among the
WebApp elements
Navigation analysis—examines how users might access individual
elements or groups of elements
Evaluation analysis—considers pragmatic issues (e.g., cost/benefit)
associated with implementing the relationships defined earlier
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
17
Navigation Analysis-I







Should certain elements be easier to reach (require fewer navigation
steps) than others? What is the priority for presentation?
Should certain elements be emphasized to force users to navigate in
their direction?
How should navigation errors be handled?
Should navigation to related groups of elements be given priority
over navigation to a specific element.
Should navigation be accomplished via links, via search-based
access, or by some other means?
Should certain elements be presented to users based on the context
of previous navigation actions?
Should a navigation log be maintained for users?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
18
Navigation Analysis-II





Should a full navigation map or menu (as opposed to a single “back” link or
directed pointer) be available at every point in a user’s interaction?
Should navigation design be driven by the most commonly expected user
behaviors or by the perceived importance of the defined WebApp elements?
Can a user “store” hi rre ooss nvvigation throughtth WebApp to exped ee
future usage?
For which user category should optimal navigation be designed?
How should links external to the WebApp be handled? overlaying the
existing browser window? as a new browser window? as a separate frame?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
19