Chapter 18

Analysis Modeling for

WebApps
Software Engineering: A Practitioner’s Approach, 6th edition
by Roger S. Pressman

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.

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

3
The User Hierarchy

Safe Ho m e As s u re d .co m
use r

gue st re g is t e re d cu s t o me r s e rv ice
use r s t aff

n e w cu s t o m e r e xis t in g cu s t o m e r

Figure 1 8.1 Us e r h ie rarchy fo r Safe Ho m e As s u re d .co m

4
Use-Case Diagram

de s c rib e
h o me la yo u t
<< in c lu d e > >

p e ru s e
de s c rip t iv e s e le c t
c onte nt c u s t omiz e < < in c lu d e >>
Sa fe Home
Sa fe Ho me
c o mp o ne n t s

<< in c lu d e > >

s a ve
c o n figu ra t io n

c u s t omiz a t io n fu n c t io n a lit y

lo g -in t o
Sa fe Ho me As s u re d .c om
vie w
s h o p p in g c a rt
<< in c lu d e > >

p urc h a s e
n e w c u s t o me r
c o n fig ura t ion < <in c lu d e > >

p rov ide
p u rc h a s e d a t a

re c a ll s a v e d
< <in c lu d e >>
c o nfig u ra t io n

c o mp le t e
Sa fe Ho me ord e r

e -c omme rc e fu n c t io n a lit y

Figure 18.2 Use -c a se dia gra m for ne w-c ust ome r

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

7
Data Tree
Ma rke t ingDe s c ript ion

Phot ogr a ph
pa rt Numbe r

Te c hDe s c ript ion

pa rt Na me

c ompone nt Sc he ma t ic
pa rt Type

Vide o
de s c ript ion

pr ic e
Whole s a le Pric e

Re t a ilPr ic e

Fig u re 1 8 . 3 Da t a t re e fo r aS a f e Ho m e c o m p o n e n t

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

9
Analysis Class Example
BillOfMat e rials

Pro d u ct Co mp o n e n t 1 id e n t ifie r
p rice To t al
p art Nu mb e r
p art Name
ad d En t ry( )
p art Ty p e d e le t e En t ry( )
d e s crip t io n
e d it En t ry( )
p rice
n ame ( )
s av e ( )
cre at e Ne wIt e m( ) co mp u t e Price( )
g e t De s crip t io n( )
g e t Te ch Sp e c 1

*
*
Bo MIt e m

Se n s o r Came ra Co n t ro lPan e l So ft Fe at u re q u an t it y
p rice

ad d t o Lis t( )
d e le t e fro m Lis t( )

Fig ure 18.4 An alys is clas s e s for u se -case : s e le ct S af e Hom e com p o ne n t s

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

11
Sequence Diagram
:Produc t :Billof FloorPla n BoM
:Room :FloorPla n
Compone nt Ma t e ria ls Re pos it ory Re pos it ory

new cus t o mer

d e s c rib e s
ro o m *
p la c e s ro o m
in f lo o r p la n

sa v e f lo o r p la n c o n f ig u ra t io n

s e le 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

s a v e b ill o f m a t e ria ls

Fig u re 18.5 Se que n ce d iagram for u se -cas e : s e le ct S af e Hom e co m p o ne n t s

12
State Diagram
Va lida t in g u se r Se le ct in g u se r a ct io n
use rid se le c t ot h e r fu nc t io n s
syst e m st a t u s=“inp u t re a d y ” va lid a t e d syst e m st a t u s=“lin k re a d y ”
se le ct “lo g -in” d ispla y msg = “e nt e ru se rid ” d ispla y: n a v iga t ion ch oice s”
d ispla y msg =“e n t e r p swd ”
p a ssword v a lida t e d
e n t ry / v a lid a t e d u se r
e nt ry / lo g-in re q u e st e d
n e w cu s t o m e r d o : lin k a s re q u ire d
d o: ru n u se r v a lida t io n
e xit / u se r a ct io n se le ct e d
e xit / se t u se r a cce ss swit ch

c ust omiz a t io n c o mp le t e
se le c t e -c o mme rc e (pu rc ha se ) fu n c t io na lit y

se le c t c u st o miz a t io n fu n c t ion a lit y

Cu st o miz in g
sy st e m st a t u s=“in p u t re a d y ”
disp la y : b a sic in st ru ct ion s
ro o m b e in g d e fin e d
e n t ry / va lid a t e d u se r
d o : p ro ce ss u se r se le ct io n
e xit / cu st o miz a t ion t e rmin a t e d
se le ct d e scrip t iv e
co n t e n t
De fin ing ro o m
sy st e m st a t u s=“in p ut re a d y”
d isp la y: ro omd e f. wind o w
e n t ry / ro o md e f. se le ct e d
a ll ro o ms d o : ru n ro o m q ue rie s
d e fin e d d o : st o re roo m v a ria b le s
e xit / ro o m co mp le t e d
ne xt se le ct ion
se le ct d e script iv e
co n t e n t
Sa ving flo or p la n
sy st e m st a t us=“inp u t re a d y”
disp la y : st ora ge ind ica t or
e n t ry / flo or p la n sa ve se le ct e d
do : st o re flo or pla n
e xit / sa v e co mp le t e d

Bu ilding flo o r p la n se le ct de scrip t iv e

se le ct sa v e flo or p la n
co nt e n t
sy st e m st a t us=“in pu t re a dy ”
se le ct e n t e r ro om in floo r p la n d isp la y : floo r p la n win do w

e n t ry / flo or p la n se le ct e d
d o : in se rt ro om in p la ce
d o : st o re flo or p la n v a ria b le s
e xit / ro o m in se rt io n co mp le t e d
ro o m inse rt ion co mple t e d

Figure 1 8 .6 Pa rt ia l s t a t e dia gra m for n e w c u s t o m eint

r e ra c t ion

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

14
Activity Diagram
init ialize t ot alCos t

no c o mpo n e n t s re ma in o nBo MList c o mp o n e n t s re ma in o n Bo MList

invoke g et price and

calcShipping Cos t quant it y
ret urns :
s hipping Cos t

lineCos t =
price x quant it y
invoke
det erm ineDis count
ret urns : dis count add lineCos t t o
t ot alCos t

d isc o u n t >0
t ot alCos t=
t ot alCos t - dis count

d isc o u n t < = 0

t axTot al=
t ot alCos t x t axrat e

priceTot al =
t ot alCos t + t axTot al
+ s hipping Cos t

Figure 1 8 .7 Ac t ivit y dia gra m for c o m p u t e P r i (c )e o p e r a t i o n

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

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

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?

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” his previous navigation through the WebApp
to expedite 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?

19