CHAPTER

ANALYSIS FOR WEBAPPS

KEY CONCEPTS

18

analysis model configurat ion model content mod el content relationships data tree functional model interaction model navigation analysis relationship analysis

t first glance,there is an apparent contradiction when we consider analysis modeling within the context of Web engineering. Aller all, we have noted (Chapter 16) that WebApps have an immediacy and a volatility that mitigate against detailed modeling at either the analysis or the design level. And if we do any modeling at all, the agile philosophy (an appropriate process model for many Web engineering projects) suggests that analysis modeling is downplayed in favor of limited design modeling. Franklin [FRA02] notes this situation when he writes:
Web sites are typically complex and highly dynamic .They require short development phases in order to get the product up and running quickly. Frequently, developers go straight to the coding phase without really understanding what they are trying to build or how they want to build it. Server-side coding is often done ad hoc. database tables are added as needed.and the architecture evolves in a sometimes unintentional man ner. But some modeling and disciplined sothvare engineering can make the software development process much smoother and ensure that the Web system is more maintainable in the future

RNA
use-cases user hierarchy

Is it possible to have it both ways? Can we do "some modeling and disciplined sonware engineering" and still work effectively in a world where immediacy and volatility reign? The answer is a qualified yes.

What is it? The analysis of a poten

tial Web application focuses on three important questions: (l)what informa tion or content is to be presented or manipulated; (2) what functions are to be per formed for the end-user; and (3) what behaviors will the WebApp exhibit as it presents content and performs functions? The answers to these questions ore represented as port of an analysis model that encompasses a variety of UMl representations. Who does it? Web engineers, nontechnical con tent developers, and stakeholders participate in the creation of the analysis model. Why is it important? Throughout this book we hove emphasized the need to understand the problem before you begin to solve it. Analysis

modeling is important not because it enables a Web engineering team to develop a concrete model of WebApp requirements (things change too frequen y for this to be a realistic expecto tion), but rather, analysis modeling enables a Web engineer to define fundamental aspects of the problem-things that are unlikely to change (in the near term). When fundamental content, function, and behavior ore understood, design and construction are facilitated . What are the steps? Analysis modeling focuses on four fundamental aspects of the problemcontent, interaction, function,and configuration. Content analysis identifies content classes and col laborotions. Interaction analysis describes basic elements of user interaction, navigation, and the

539

PART THREE

APPLYING WEB ENGINEERING

system behaviors that occur as o consequence. Function analysis de nes the WebApp functions that ore performed for the user and the sequence of processing that occurs as o consequence . Congurotion analysis identifies the operational environmen s) in which the WebApp resides. What is the work product? The analysis model i s comprised of o set of UML diagrams

and text that describe content, interaction , func tion, and configuration .
How

do I ensure that I've done it right?

Analysis modeling work products must be reviewed for correctness, completeness, and consistency.

A Web engineering team should embrace analysis modeling when most or all of the following conditions are met: 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 Web App w ill have a strong bearing on the success of the business. If these conditions are not present, it is possible to de-emphasize analysis modeling, using information obtained during formulation and requirements gathering (Chapter 1 7) as the basis for creating a design model for the WebApp. In such circumstances, limited analysis modeling may occur, but it w ill be rolled into design.

18 1 REQUIREMENTS ANALYSIS FOR WEBAPPS

I

Requirements analysis for WebApps encompasses three major tasks: formulation. requirements gathering, 1 and analysis modeling. During formulation, the basic motivation (goals) and objectives for the WebApp are identified, and the categories of users are defined. As requirements gathering begins, communication between the Web engineering team and WebApp stake holders (e.g., customers, end-users) intensifies. Content and functional require ments are listed and interact ion scenarios (use-cases) written from the end-user's point-of-view are developed. The intent is to establish a basic understanding of why the WebApp is to be bujlt, who will use it,and w hat problem(s) it will solve for its users.

"The engineering principles of planning before designing and designing before building hove withstood every prior tedmology transition;they'll survive this transition as well.
Watts Humphrey

I Formulalion and requirements gathering are discussed in detail in Chapter 17.

CHAPTER 18

ANALYSIS FOR WEBAPPS

541

18.1.1 The User Hierarchy

The categories of end-users who will interact with the WebApp are identified as part of the formulation and requirements gathering tasks. In most cases, user categones are relatively limited and a UML representat ion of them is unnecessary. However when the number of user categories grows. it is sometimes advisable to develop a user hierarchy as shown in Figure I8. I. The figure depicts users for the SafeHomeAssured.com e-commerce site discussed in Chapters 16 and 1 7. The user categories (often called actors) shown in Figure I8. 1 provide an indication of the functionality to be provided by the WebApp and indicate a need for usecases to be developed for each end-user (actor) noted in the hierarchy. Referring to the figure, the SafeHomeAssured.com user at the top of the hierarchy represents the most general user class (category) and is refined in levels below. A guest is a user who visits the site but does not register. Such users are often searching for general informat ion. comparison shopping, or otherw ise interested in "free" content or functionality . A registered user takes the time to provide contact information (along with other demographic data requested by forms input). Subcategories for registered user include: new customer-a registered user who wants to customize and then purchase SafeHome components (and hence. must interact with the WebApp e-commerce functionality); existing customer-a user who already owns SafeHomc components and is using the WebApp to ( 1) purchase additional components; (2) to acquire tech support information ;or (3) contact customer support.

eDVIC:flt's a good idea to build o user hierarchy. It provides you with o snapshot of the user population and a cross check to help ensure that the needs of every userhovebeen addressed.

4iNII!II:i+
User hierarchy for SafeHomeAssured.com

SofeHomeAssured.com user

t
Guest New customer

1 I 1
1

Registered user

Customer service staff

Existing customer

542

PART TH R EE

APPLYING WEB ENGINEERING

Members of customer service staff are special users who can also interact with SafeHomeAssured.com content and functionality as they assist customers who have contacted SafeHome customer support.

18.1.2

Developing Use-Cases

Franklin lFRAO 1 J refers to use-cases as "bundles of funct ionality." This description captures the essence of this important analysis modeling technique.2 Use-cases are developed for each user category described in the user hierarchy. In the context of Web engineering, the use-case itself is relatively informal-a narrative paragraph that describes a specific interaction between a user and the webApp.3 Figure 18.2 represents a UML use-case diagram for the new customer user category (Figure 18.1). Each oval in the diagram represents a use-case that describes a specific interaction between new customer and the WebApp. For example, the first interaction is described by the

log-in to SafeHomeAssured.com use-case. No more

than a single paragraph would be required to describe this common interaction. Major WebApp functional ity (and the use-cases that are relevant for it) are noted inside the dashed boxes in Figure 18.2. These are referred to a "packages" in

UH"':f'
Use-case diagram for new-customer

- -- ------- --------L-1

I I

2 Techniques for developing use-cases have been discussed in detail earlier in lhis book (see Chapters 7 and 8)

J Alt hough it is possible to develop more formal use-case descriptions, the need for WebE agility often precludes this approach.

CHAPTER 18

ANALYSIS FOR WEBAPPS

543

UMLand represent specific functionality. l\No packages are noted: customization and e-commerce. As an example, we consider the customization package of use-cases. A new cus-

SafeHome will be installed To accomplish this, the use-cases describe home layout, select Safe! lome hardware, and save configuration are initiated by new customer. Consider these preliminary use-cases written from the point of view of a new customer:
tomer must describe the home environment into which

eDVIC'fAs the size of a

Use-case: describe home layout The WebApp will ask some general questions about the environment in which 1 plan to install SafeHome-the number of rooms, size of rooms, type of room, the number of floors, the number of exterior doors and windows. The WebApp will enable me to build a rough floor plan by putting together outline shapes of the rooms for each floor.I 'll be able to give the floor plan a name and save it for future reference (see use case: save con

WebApp grows and

anaftsis modeling

be!omes mOle rigorous, the prelim nary use-cases presented here would have to be expanded to canfOfm ffl()(e closely to the format suggested in Section 8.5 of Chapter 8.

jiguracion).
Use-case: select SafeHome componencs The WebApp will then recommend product components (e.g., control panels, sensors, cameras) and other features (e.g., PC-based functionality implemented in software) for each room and exterior entrance. If Irequest alternatives. the WebApp will provide them, iflhey exist. 1 will be able to get descriptive and pricing information for each product component. The WebApp will create and display a biJI-of-materials as Iselect various components.I 'll be able to give the bill-of-materials a name and save it for future reference (see use-case: save configuration). use-case: save configuration The WebApp will allow me to save customization data so that 1 can return to it later. Ican save the house layout and the SafeHome bill-of materials Ichoose for the layout. To accomplish this, 1 provide a unique identifier for the house layout and the bill-of-materials. Ialso provide a special configuration password that must be validated before Ican gain access to the saved information.

Although considerab y more detailcould be provided for each of these use-cases,the l informal text description provides useful insight. Similar descriptions would be de veloped for each oval in Figure 18.2.

SAFEHOME

Refining Use-casesfor WebApps

The scene: Doug Miller's office. The players: Doug Miller (manager of the SafeHome
software engineering group), Sharon Woods, manager of the outsourcing vendor's Web engineering team for the SafeHome e commerce Web site, and Sam Chen, manager of the SofeHomeAssured .com customer support organization .

The conversation:
Doug: Glad to hear things ore progressing well, Sharon . Analysis modeling is almost complete?

544

PART THREE

APPLYING WEB ENGINEERING

Sharon (smiling): We're making progress.The only set of use coses left to develop from the user hierarchy [Figure 18.1) i s the customer service staff category. Doug (looking at Sam): And you have those now, Sam? Sam: I do. I've e moiled them to you, Sharon, and cc'd you, Doug. Here's the hardcopy version . (He hands sheets of paper to Doug ond Sharon.) Sam: The way we look at it, we wont to use the SofeHomeAssured .com Web site as o support tool when customers phone in on order.Our phone reps will complete all necessary forms, etc.and process the order for the customer. Doug: Why not just refer the customer to the Web site? Sam (smiling): You techies think that everyone is comfortable with the Web. They're not! Plenty of people still like the telephone, so we hove to give them that option. But we don't wont to build a separate order processing system when most of the pieces ore already in place on the Web. Sharon: Makes sense. (All parties read the usecoses [on example follows)) :

I will ask the customer {via the phone) to describe each room of the house and will enter room dimensions and other characteristics on one big form designed specifically for customer support personnel. Once the house dolo are entered I can save the data under the customer's name or phone number. Sharon: Sam, you've been kind of terse in your preliminary use cose desriptions. I think we're going to need to flesh them out obit. Doug (nodding): I agree. Sam (frowning): How so? Sharon:Well ...you mention N one big form designed specifically for customer support personnei.H We're going to need more detail. Sam:What I meant wos that we don't need to walk our reps th rough the process like you do for on online customer.One big form should do the trick. Sharon: let's sketch out what the form should look like. The parties work to provide sufficient detail to allow Sharon's team to make effective use of the usecose .

Use-case: describe home layout [note that th i s differs from the usecose of the some nome for new customer category)

18.1.3

Refining the Use-Case Model

As use-case diagrams are created for each user category, a top-level view of externally observable WebApp requirements is developed. Use-cases are organized into functional packages, and each package is assessed (CONOO] to ensure t hat it is:

we assess packages of usecases that hove been grouped by user function?

? Howdo

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 is kept to a minimum.

Hierarchically sha/lo eep 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. Because requirements analysis and modeling are iterative activities,it is like l y that new use-cases will be added to packages that have been defined, that existing use-cases will be refined,and that specific use-cases might be reallocated to different packages.

CHAPTER 18 ANAL YSIS FOR WEBAPPS

545

18 2
I

THE ANALYSIS MoDEL FOR WEBArrs

A WebApp analysis model is driven by information contained within the use-cases that have been developed for the application. use case descriptions are parsed to identify potential analysis classes and the operat ions and attributes associated with each class. Content to be presented by the WebApp is identified, and functions to be performed are extracted from the use-case descriptions. Finally, implementationspecific requirements should be developed so that the environment and infrastructure that support the WebApp can be built. Four analysis activities-each contributing to the creation of a complete analysis model are:

of analysis activity occur during modeling of a WebApp?

? What types

Content analysis identifies the full spectrum of content to be provided by the WebApp . Content includes text, graphics and images, and video and audio data . Interaction analysis describes the manner in which the user interacts with the WebApp . Functional analysis defines the operations that will be applied to WebApp content and desc ribes other processing functions that are independent of content but necessary to the end-user. Con figuration analysis describes the environment and infrastructure in which the WebApp resides. The information collected during these four analysis tasks should be reviewed,modified as required, and then organized into a model that can be passed to WebApp designers. The model itself contains structural and dynamic elements. Structural elements identify the ana ysis classes and content objects that are requjred to create a WebApp l that meets stakeholders needs. The dynamic elements of the analysis model describe how the structural elements interact with one another and with end-users.

"Successful [WebApps] allow customers to meet their needs beller, foster, or cheoper themselves, rather than working through [a company's]employee endusers."
Mark McDonald

183
I

THE CONTENT MODEL

The content model contains structural elements that provide an important view of content requirements for a WebApp . These structural elements encompass content objects (e.g.. text ,graphical images,photographs,video images. audio) that are pre sented as part of the WebApp . In addition, the content model includes all analy::;ts classes-user-visible entities that are created or manipulated as a user interacts with

546

PART THREE

APPLY ING WE B ENGI NEERING

the WebApp. An analysis class encompasses attributes that describe it, operat ions that effect behavior required of the class, and collaborations that allow the class to communicate with other classes. Like other elements of the analysis model. the content model is derived from a careful examination of use-cases developed for the WebApp. use-cases are parsed to extract content objects and analysis classes.

18.3.1 Defining Content Objects

" INf
A content object rs any item of cohesive mformafion !hot is to be presented to on end-user.Typically, content objed5 ore

Web applications present pre-existing information-called content-to an end-user. The type and form of content spans a broad spectrum of sophist ica tion and complexity. Content may be developed prior to the implementation of the WebApp, while the WebApp is being built, or long after the WebApp is operational. In every case, it is incorporated via navigational reference into the overall WebApp structure. A con-

tent object might be a textual description of a product, an article describing a news

event, an action photograph taken at a sporting event, an animated representation of a corporate logo, a short video of a speech, or an audio overlay for a collection of Powerpoint slides. Content objects are extracted from use cases by examining the scenar io descrip tion for direct and indirect references to content. For examp le, in the use-case select SafeHomc componenlS, we encounter the sentence:
Iwill be able to get descriptive and pricing information for each product component.

exhoded from usecases.

Although there is no direct reference to content, it is implied. The Web engineer wou ld meet with the author of the use-case and gain a more detailed understanding of what "descriptive and pricing information" means. In this case, the author of the use-case might indicate that "descriptive information" includes (I) a one paragraph general description of the component ; (2) a photograph of the com ponent; (3) a multiparagraph technical description of the component; (4) a schema tic diagram of the component show ing how it !its into a typical SajeHome system, and (5) a thumbnail video that shows how to install the component in a typical household setting. It is important to note that each of these content objects must be developed (often by content developers who are not Web engineers) or acquired for integration into the WebApp architecture (discussed in Chapter 19).

"The Web-so much contenl, so little time.

Author unknown

"POINf
A ocrc

18.3.2 Content Relationships and Hierarchy

In many instances, a simple list of content objects, coupled with a brief description of each object, is sufficient to define the requirements for content that must be designed and implemented. Ilowever, in some cases, the content model may contain

ee epH;sents o h1ermchv oi conrent

obied5.

CHAPTER 18 ANA L YSIS rOR WEBAPPS

547

4 Uh"i:f+
Data tree for a SafeHome component

MarketingDescriptian Photograph TechDescription Schematic

Video

WhalesalePrice RetaiiPrice

ent ity relationship diagrams (Chapter 8) or

data trees ISRJO IJ that depict the relation-

ships among content objects and/or the hierarchy of content maintained by a WebApp. Consider the data tree created for a SafeHome component shown in Figure 18.3. The tree represents a hierarchy of information that is used to describe the component (later we w ill see that a Sa)eHome component is actually an analysis class for this application). Simple or composite data items (one or more data values) are represented as unshaded rectangles. Content objects are represented as shaded rectangles. In the figure, description is defined by five content objects (the shaded rectangles). In some cases,one or more of these objects would be further refined as the data tree expands.

18.3.3 Analysis Classes4 for WebApps

As we have already noted, analysis classes are derived by examining each use-case. For example, consider the preliminary use-case: select sented in Section 18.1.2.

SafeHome components pre-

use-case: select SofeHome components

The WebApp will then recommend Product components (e.g.,control panels,sensors cameras) and other features (e.g., PC-based functionality implemented in soflware) for each room and exterior entrance.If Irequest alternatives, the WebApp will provide them if they exist. Iwill be able to get descript ive and pricing information for each product component The WebApp will create and display a bjll-of-materjals as 1 select various components. I'll be able to give the bill-of-materials a name and save it for future reference (see use-case:save configuration) .

A quick gramma t ical parse of the use-case identifies L wo candidate classes (under lined): ProductComponent and BiliOfMateriaJs. A nrst-cut descnption of each class is shown in Figure 18.4.

A detailed discussion of the mechanics for identifying and representing analys1 s classes has been presented in Chapter 8 If you have not already done so. review Chapter 8 at this time.

PART THREE

APPLYIN G WEB ENGINEERING

4j!ijlj.j11:&+
Analysis classes for usecase: select
SateHome
PraductComponent portNumber portNome portType description price creoteNewltem( I getTechSpec
0

I 1

BiiiOfMaterials Identifier priceTotal oddEntry( I deleteEntry( I editEntry(I nome( I $Ove( I computePrice( I

components

Q.

Sensor

Camero

Y'
:_ BoMitem quantity price oddtoli,t( I deletefrornlist( I

ControlPanel

I
Softfeature

The ProductComponent class encompasses all SafeHome components that may be purchased to customize the product for a particular installation. It is a generalized representation of Sensor, Camera, ControlPanel, and SoftFeature. Each ProductComponent object contains information corresponding to the data tree shown in Figure 1 8.3 for the class. Some of these class attributes are single or composite data items and others are content objects (see Figure 18.3). Operations relevant to the class are also shown. The BillOtMaterials class encompasc;es a list of components that new customer has selected. BiJJOtMaterials is actually an aggregation of BoMitem (many instances of BoMitem comprise one BiliOtMaterials)-a class that builds a list composed of each component to be purchased and specific allributes about the component as shown in Figure 18.4. Each use-case identified for SafeHomeAssured .com is parsed for analysis ob jects . Class models similar to the one described in this section are developed for each use-case.

18 4
I

THE INTERACTION MODEL

The vast majority of WebApps enable a "conversation" between an end-user and application functionality, content, and behavior. This interaction model is composed of four elements: ( 1) use-cases, (2) sequence diagrams, (3) state diagrams,5 and (4) a user interface prototype. In addition to these representations, the interaction is also represented within the contex t of the navigation model (Section 18.7).

Eachof these is an important UML notation and has been described in Chapter 8.

CHAPTER 18

ANALYSIS FOR WEBAPPS

5 4 9

m'L"'"'
Sequence use-case :
select SafeHome components diagram for New
customer
I Describes 1

t
t I

I I
I

t
I I

room

IPloces room

I
I I t

L------ !!. e1
I I

-:
I

:
t
t I t ----------- I 1

I I
I

I
1

------ ------ ----- ----------r------r----------- ,

I

S o ve H oo r p I io n conftgu ro tion I
t

Selects product comP?nenl"

1 1

1 od d lo

8 oM
I

I
I I I

,
1

I
-'-

!...I

_L
I I I

_:i'l."!.f!l o.!. o.!_eL!o s t I I

_ 1
I I I

.J
I I I

I t I

eDVICES.
The techniques associated with tosk analysis (Chapter 12) con be used to help define modes of user interaction.

Use-cases . Use-cases are t he dominant element of the interaction model for WebApps. It is not uncommon to describe 100 or more use-cases when large, complex WebApps are analyzed, designed,and constructed. However. a relatively small percentage of these use-cases describe the major interactions between end-user categories (actors) and the system. Other use-cases refine the interactions, providing the analysis detail necessary to guide design and construction.

Sequen ce diagrams . UML sequence diagrams provide a shorthand representation

of the manner in whic h user actions (t he dynamic elements of a system defined by use-cases) collaborate with analysis classes (the st ructural elements of a syste m defined by class diagrams). Since analysis classes are extracted from use case descriptions, there is a need to ensure that traceabilit y exists between the classes t hat have been defined and the use-cases that describe system interaction. In earlier chapters we noted that sequence diagrams provide a link between the actions described in the use-case and the analysis classes (st ructural entities). Conallen (CONOO( notes this when he writes: "The merging of dynamic and structural e l ements of the (analysis] model is the key link in the traceability of the model and should be taken very seriously."

eDVICES.
In some cases, excerpts from the octuol text of the usecase con be reprodu<ed in the leh hand column (below the user) so that direct traceability con be represented.

A sequence diagram for the

select Safe! lome components

use-case is shown in

Figure 18.5.The vertica laxis of the diagram depicts actions that are defined w ithin the use-case.The horizontal axis identifies the analysis classes that are used as t he usecase proceeds.For example,a new customer must first describe each room within the house (the asterisk following "describe room" indicates that the action is iterative) To accomplish this, the new customer answers questions about the room's size doors and windows.and so forth. Once a room is defined. it is placed in a floor plan tor the house. The new customer then describes the next room or proceeds to t he next action (which is to save the floor plan configuration) . The movement across and down the sequence diagra m ties each analysis class to use case actions. Ifa use case action

550

PART THREE

APPLYING WEB E NGIN EER ING

...

Partial state diagram for new customer interaction

System status D userid 'input ready"
Selecting user action

System status = 'link ready' Display: 'navigation choices' entry/validated user do:link os required exit/user oction selected Select other functions

Validating user

validated

New
cus1omer

a Select 'log-m" Display msg "enter userid" Display msg = 'enter pswd' password validated entry/log-in r:::Juested

1---

do:run user vo idotion

exil/set user access switch

Cusrom zotion complete

I
content

Select e<ommerce (purchase) functionality

Select customizolion functionality

L
L ]-

Customizing

storvs input ready " IL-- System Display: bosic instructions

Next selection

elect descriptive

Select descript ive

Saving Roar plan

System status .. input ready
11

"'\

I'

De ning room

content

Room being defined

SysJem status "input ready

entry/valida ted user do: process user selection

r---

Display: room def. window entry/room def. selected All

rooms

exit/customizotion terminated

r-h
de ned

Display:storage indicator entry/room pion save selected do:store Roar pion exit/save compl eted Select
descriptive

do:run room queries

do:store room variables exit/room completed Building floor plan

Select save floor plan Select enter room in floor plan

System status = 'input ready ' Display:lloor pion winclow entry/Roar plan selected do: insert room in place do: store floor pion variables

S t

Room insertion completed

exit/room insertion completed

is missing from the diagram, the Web engineer must re-evaluate the description of analysis classes to determine if one or more classes is missing. Sequence diagrams can be created for each use-case once analys is classes are defined for the use-case. State diagrams . The UML state diagra m (Chapter 8) provides another representation of the dynam ic behavior of the WebApp as an interaction occurs. Like most modeling representations used in Web engineering (or software engineering). the state diagram can be represented at different levels of abst raction. Figure 18.6 depicts a partia l, top- level (high level of abstraction) state diagram for the i nteraction between a new customer and the SafeHomeAssw-ed.com WebApp. In the state diagram shown. six externally observable states are identified: vali-

dating uset; selecting user action, customizing, defining room, buildingfloor plan, and savingjloor plan. The state diagram indicates the events that are required to move
the new customer from one state to another, t he information that is displayed as a state is entered,the processing that occurs within a state,and the exit condition that causes a t ransition from one state to another . Because use-cases, sequence diagrams, and state diagrams all present related

information, it is reasonab le to ask why all three are necessary. In some cases, they are not. Use-cases may be sufficient in some situations. However, use-cases

CHAPTER 18 ANALYSIS FOR WEBAPPS

551

provide a rather one-dimensional view of the interaction. Sequence diagram:::present a second dimension that is more procedura l (dynamic) in nature State diagrams provide a third dimension t hat is more behavioral and contains informa tion about potential navigation pathways that is not provided by use-cases or the sequence diagram. When all three dimensions are used, omissions or incons1s tencies that might escape discovery in one dimens ion become obv ious when a second (or third) dimension is examined. ll is for this reason that large complex WebApps can benefit from an interaction model that encompasses all three represen tations.
User interface prototype. The layout of the user interface, the content it

eDVIC:Es .
Some Web engineers prefer o pencil and paper storrboorrf of major WebApp pages (screens). Although such storyboards con be developed verr quickly, the navigation flow is less obvious than with on opelofionol prototype.

presents, the interaction mechanisms it implements, and the overall aest hetic of the user-WebApp connections have much to do with user satisfaction and the overa ll acceptance of the WebApp . Although it can be argued that the creation of a user interface prototype is a design activity, it is a good idea to perform it during the creation of the analysis model. The sooner that a physical representation of a user interface can be reviewed. the higher the likelihood that end-users will get w hat they wan t. user int er face a nalysis and design are discussed in detail in Chapter 12. Because WebApp development tools are plentiful, relatively inexpensive. and functionally powerful,it is best to create the interface prototype using suc h tools. The prototype should implement the major navigational links and represent the overall screen layout m much the same way that it will be constructed.

18.5

THE fUNCTIONAL MODE L

ThefuncUonal model addresses t wo processi ng elements of the WebA pp, each rep resenting a different level of procedural abstraction: (IJ user observable functionality that is delivered by t he WebApp to end-users,and (2) the operations contained w ithin analysis classes that implement behaviors assoc iated with the class. user-observable functionality encompasses any processing functions that are initiated directly by the user. For example, a financial Web site might implement a va riety or financial functions (e.g., a college tuition savings calcula tor or a ret1rement savings calculator). These functions may actually be implemented using operations within analysis classes, but from the point of view of the end-user, the function (more correctly, the data provided by the funct ion) is the visible outcome . At a lower level of procedural abstraction, the analysis model describes the pro cessing to be performed by analysis class operations. These operations mampulate class attributes and are involved as classes collaborate with one another t o accom plish some required behavior. Regardless of the level of procedura l abstraction the Ul\lL actiVIty diagram can be used to represent processing details. Figure 18.7 depicts an activity diagram for the

552

PART THREE

APPL YING WE B E NGIN EERING

4j@l-!II:Q
Activity diagram for computePrice() operation

eDVIC'Is .
As on alternative, you con also write o simple processing narrative or 01ogrom design 1 anguoge represento 'JOn (Chapter II ). i'fowever, many people :xeier a graphical ;tesentotion.

computePI'ice() operation that is part of the Bi110fMaterials analysis class.6 As we

noted in Chapter 8, the act ivity diagram is similar to the flowchart , illustrating the processing now and logica l decisions w ith the now. rt should be noted that two additional operations are invoked within the procedural now : calcShippingCost(), which calculates the cost of shipping depending upon the shipping method chosen by the customer, and determineDiscount (), which determines any special discounts for the SafeHome components that were selected for purchase. The construction details indicating how these operations are invoked and the interface details for each operat ion are not considered until WebApp design commences.
6 A review oft he BillOfMaterials analysis class might determine that in the interest of cohesion,the

compurePrice() operation might best be placed within an Invoice class This suggestion has merit. However, it remains within the BiJJOfMateria s analysis class for the purposes of this example. l

CHAPTER 18

ANALYSIS FOR WEBAPPS

553

186
I

THE CoNFIGURATION MopEL

WebApps must be designed and implemented in a manner that accommodates a va riety of environments on both the server-side and the client -side.7 The WebApp can reside on a server that provides access via the Internet, an Intranet, or an Extranet Server hardware and operating system environment must be specified. In addition interoperability considerations on the server -side should be considered. If the WebApp must access a large database or intemperate with corporate applications that exist on the server side, appropriate interfaces, commun ication protocols, and related collaborative information must be specified.

eDVICE S.
Although it's very important to consider all configurations that ore likely to be used, remember that o WebApp must be engineered to serve its end-users, not the iditr syncrosies of o particular browser.

Client-side software provides the infrastructure that enables access to the WebApp from the user's location. In general, browser software is used to deliver the WebApp content and functionality that is downloaded from the server. Although standards do exist, each browser has its own peculiarities. For this reason, the WebApp must be thoroughly tested within every browser configLira tion that is specified as part of the configuration model. In some cases,the configuration model is nothing more than a list of server -side and client-side attributes. However, for more complex WebApps, a variety of config uration complexities (e.g., distributing load among multiple servers, caching architectures, remote databases, multiple servers serving various objects on the same Web page) may have an impact on analysis and design. The UML deployment diagram (Chapter
1 0)

can be used in situations in which complex configuration archi-

tectures must be considered.

187
I

RELAIIONSHIP-NAYIGATJON

ANALYSIS

The elements of the analysis model described in the preceding sections identify content and functional elements along with the manner in which they are used to implement user interaction. As analysis evolves into design, these elements become part of the WebApp architecture. In the context of Web applications, each architec tural element has the potential to be linl-. d to all other architectural elements . But as the number of links increases, navigatJc,nal complexity t11roughout the WebApp also increases. The question, then, is how to e t..,l11ish the appropria te links between content objects and among the functions that provide user-required capabilities

[Navigation) is not only the action of jumpi ng from page to page, but the idea of moving through an information space: A.Reina and J. Tones

7 The server-side hosts the WebApp and all related system features that enable mulupte users to gam access to the WebApp v1a a network. The c/iem side provides a software environment (e.g. browsers) that enable end-users to interact with the WebApp on the user's desktop.

554

PART THREE

APPLYING WEB ENGINEERING

Relationship -navigation analysis (RNA) provides a series of ana ysis steps that strive l to identify relationships among the elements uncovered as part of the creation of the analysis model.8 Yoo and Bieber [YOOOOJ describe RNA in the following manner:
RNA provides systems analysts with a systematic technique for determining the relationship structure of an application. helping them to discover all potentially useful relationships in application domains. These later may be implemented as links. RNA also helps determine appropriate navigat ional structures on top of these links. RNA enhances system developers' understanding or application domains by broadening and deepening their conceptual model of the domain. Developers can then enhance their implementation by including additional links, metainformation,and navigation.

The RNA approach is organized into five steps: Stakeholder analysis-identifies the various user categories (as described in Section 18. 1) and establishes an appropriate stakeho lder hierarchy. Element analysis-identifies the content objects and functional elements that are of interest to end-users (as described in Sections 18.3 and 18.5). 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 w ith implementing the relationships defined earlier. The first two steps in the RNA approach have been discussed earlier in this chapter. In the sections that follow, we consider methods for establishing the relationships that exist among content objects and functions.

18.7.1

1 Relationship Questions

Analysis-Key

Yoo and Bieder (YOOOO] suggest a list of questions that a Web engineer or systems analyst should ask about each element (content object or function) that has been identified within the analysis model. The following list, adapted for WebApps, is representative IYOOOO] :

we assess analysis model elements to understand the relationships between them?

? Howdo

Is the element a member of a broader category of elements? What attributes or parameters have been identified for the element? Does descriptive information about the element already exist? If so, where is it? Does the element appear in different locations wit hin t he WebApp? If so, where? Is the element composed of other smaller elements? If so, what are they?

8 It should be noted that RNA can be applied to any information system and was originally developed for hypermedia systems in general. It can,however,be adapted nicely for Web engineering.

CHAPTER 18

ANALYSIS FOR WEBAPPS

555

Is the element a member of a larger collection of elements? If so, what is it and what is its structure? Is the element described by an analysis class? Are other elements similar to the element being considered? If so, is it possible that they could be combined into one element? Is the element used in a specific ordering of other elements? Does its appear ance depend on other elements? Does another element always follow the appearance of the element being considered? What pre- and post-conditions must be met for the element to be used? Do specific user categories use the element? Do different user categories use the element differently? If so, how? Can the element be associated with a specific formulation goal or objective? With a specific WebApp requirement? Does this element always appear at the same time as other elements appear? If so, what are the other elements? Does this element a lways appear in the same place (e.g., same location of the screen or page) as other elements? If so,what are the other elements? The answers to these and other questions help the Web engineer to position the element in question within the WebApp and to establish relationships among elements. It is possible to develop a relationsh ip taxonomy and to categorize each relationship identified as a result of the questions noted. The interested reader should refer to [YOOOOJ for more detail.

18.7.2 Navigation Analysis

Once relationships have been developed among elements defined within the analysis model,the Web engineer must consider the requirements that dictate how each user category will navigate from one element (e.g., content object) to another The mechanics of navigation are defined as part of design. At this stage, developers should consider overall navigation requirements. The following questions should be asked and answered: Should certain elements be easier to reach (require fewer navigation steps) than others? What is the priority for presentation? Should certain elements be emphas ized to force users to navigate in their direction? How should navigation errors be handled? Should navigation to related groups of elements be given pnority over navigation to a specific elemen t ?

questions should be asked to better understand navigation requirements?

? What

----------------

556

PART THREE

APPLYI NG WEB ENG INEERING

Should navigation be accomplished via links, via sea rch-based access, or by some other means? Should certain elements be presented to users based on the context of previous navigation act ions? Should a navigation log be maintained for users?

eDVJCEAs you analyze naviga-

Should a full navigalion 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 optimalnavigation be designed? How should links external to the WebApp be handled? Overlaying t he existing browser window? As a new browser window? As a separate frame? These and many other questions should be asked and answered as part of navigation analysis . The Web engineering team and its stake holders must also determ ine overall requirements for navigation . For example, will a "site map" be provided to give users an overview of the entire WebApp structure? Can a user take a guided tour" that will highlight the most important elements (content objects and functions) that are available? Will a user be able to access content objects or functions based on defined attributes of those elements (e.g., a user might want to access all photographs of a specific building or all functions that allow computation of weight).

tional requirements, remember that the user must always know where she is and where she con go. To do this, the user needs a map.

18 . 8

SUMMARY Formulation, requirements gathering, and analysis modeling are performed as part of requirements analysis for WebApps. The intent of these activities is to (I) describe the basic motivation (goals) and objectives for the WebApp; (2) define the categories of users; (3) note the content and functional requirements for the WebApp; and (4) establish a basic understanding of why the WebApp is to be buill, who will use it, and what problem(s) it will solve for its users. Use-cases are the catalyst for all requirements analysis and modeling activities. Usecases can be organized into functional packages, and each package is assessed to ensure that it is comprehensible, cohesive. loosely coupled, and hierarchically shallow. Four ana lysis activities contribute to the creation of a complete analysis model: content analysis identifies the full spectrum of content to be provided by the WebApp; interaction analysis describes the manner in which the user interacts with the WebApp; functiona l analysis defines the operations that will be applied to WebApp content and describes ot her processing funclions that are independent of

CHA

PTER

18

ANALYSIS

FOR

WEBAPPS

557 content but necessary to the end-user, and configuration analys is describes the environment and infrastructure in which the WebApp resides. The content model describes the spectrum of content objects that are to be incorporated into a WebApp. These content objects must be developed or acquired for integration into the WebApp architecture. A data tree can be used to represent a content object hierarchy. Analysis classes {derived from use-cases) provide another means for representing key objects that the WebApp will manipulate. The interaction model is constructed with use-cases, UML sequence diagrams, and UML state diagrams to describe the "conversation" between the user and the WebApp. In addition, an interface prototype may be constructed to assist in developing layout and navigation requirements. The functional model describes user observable functions and class operations using the UML activity diagram. The configuration model describes the environment that the WebApp will require on both the server-side and the client-side of the system. Relationship-navigation analysis identifies relationships among the content and functional elements defined in the analysis model and establishes requirements for defining appropriate navigation links throughout the system. A series of questions help to establish relationships and identify characteristics that will have an innuence on navigation design. REFERENCES
[CONOOI Conallen.)., Bwldmg Web Applications with UML, Addison-Wesley, 2000. fFRAOI 1 Franklin, 5., "Planning Your Web Site with UML," webRevie1v, available at http:// www.webreview .com/2001/05_ 1 8/developers/indexo l.shtml. [SRIO II Sridhar, M., and N. Mandyam, "Effective use of Data Models in Building Web Appli cations," 200 I.available at http:// www2002.org/CDROM /alternate/698/ [Y00991 Yoo,) ., and M Bieber,"A Systematic Relationship Analysis for Modeling Information Domains," 1999,download from hllp://citeseer.nj.nec .com/ 312025. html. [YOOOOI Yoo, )., and M. Bieber, "Toward a Relationship Navigation Analysis," Proc. 33rd Hawau Conf On System Sciences, vol. 6., IEEE, January 2000, download from www.cs.njit.edu/ -bieber/pub/hicss00/1NWEB02.pdf.

PROBLEMS AND POINTS TO PONDER

18.1. Use-cases or use-case packages are assessed to ensure that they are comprehensible co hesive, loosely coupled, and hierarchically shallow. Describe what these terms mean inyour own

words. 18.2. If you were forced to do "analysis modeling lite"-that is, minimal analysis modeling what representations, diagrams, and information would you define during this Web engineer ing activity? 18.3. Using the vast array of resources on agile software development available on the Web, do a bit of research and make an argument against analysis modeling for WebApps. Do you believe that your argument applies in all cases? 18.4. What does represent? a use-case package

18.5. Using a diagram similar to the one shown in Figure 18 I.establish a user hierarchy for (a) a financial services Web site or (b) a book-seller Web site.

558

PART THREE

APPLYING WEB ENGINEERING

Select a WebA pp that you visit regularly from one of the follow ing categories: (a) news or sports, (b) entertainment, (c) e-commerce, (d) gaming, (e) computer-related, (t) a'NebApp recommended by your instructor. Perform the activities noted in Problems 1 8.6 through 1 8. 12: 18.6. Develop one or more use-cases that describe specific user behavior for the WebApp.
18.7. Select a content object or function that is part of the WebApp architecture and answer the relationship-navigation questions listed in Section 18.7.1. 18.8. Develop a UML sequence diagram and a UML slate diagram that descr ibes a specific interaction within the WebApp.

18.9. Consider the existing WebApp interface. Prototype a change to the interface that you believe will improve it.
18.1o. Considering the existing WebApp,answer the relationship-navigation questions listed in Section 18.7.2. 18.11. Represent a partial content hierarchy and define at least three analysis classes for the WebApp. 18.12. Select a user observab le function provided by the WebAp p and model il using a UML activity diagram.

fURTHER READINGS AND INFORMATION SOURCES

Many books dedicated to analysis modeling for conventional software-wi th particular emphasis on use-cases and UML notation-contain much useful information that can be readily adapted by Web engineers. Use-cases form the foundation of analysis modeling for WebApps. Books by Kulak and his colleagues (Use Cases: RequiremeniS in Context, second edition. Addison-Wes ley, 2004), Bittner and Spence (Use Case Modeling, Addison-Wes ley, 2002). Cockburn (Writing Effective Use cases, Addison-Wesley, 200 I), Armour and Miller (Advanced Use-Case Modeling: Software systems, Addison-Wesley, 2000), Rosenberg and Scott (Use case Driven Object Modeling with UML: A Practical Approach, Addison-Wesley, 1999), and Schneider, Winters, and J acobson (Applying Use Cases: A Practical Guide, Addison -Wesley, 1 998) prov ide worthwhile guidance in the creation and use of t his important requirements representation mechanism. Worthwh ile discussions of UML have been written by Arlow and Neustadt (UMLand the Unified Process, Addison-Wesley, 2002). Schmuller (Teach Yourse!{UML, Sams Publishing, 2002), Booch and his colleagues (The UML User Guide, A ddison-Wesley, 1998). and Rumbaugh and his colleagues (The Unified Modeling Language Reference Manual, Addison -Wesley, t 998). Books dedicated to Web site design often contain one or two chapters that discuss analysisi ssues (although these are often cursory discussions). The following books containone or more aspects ofanalysis within the context of Web engineering: VanDuyne and his colleagues (The Design ofSites, Addison-Wesley, 2002), Rosenfeld and Morville (Information Architecturefor the World Wide Web, O'Reilly & Associates, 2002). Wodtke (lnfomwtion ATcflitecture, New Riders Publishing, 2002). Garrett (The Elements of User Experience: User Centered Designfor U1e Web, New Riders Publishing, 2002), Niederst (Web Design in a Nutsile/1, O'Reilly & Associates, 2001). Lowe and Hall (Hypertext and the Web: An Engineeling ApproadJ, Wiley, 1 999), and Powell (Web Site Engineering. Prent ceHall, 1998) provide reasonably complete coverage. Norris, West, and Watson (Media Engineering: A Guide to Developing Information ProduciS, Wiley. 1 997). Navarro and Khan (E.ffective Web Design: Master the Essentials, Sybex, 1998). and Fleming and Koman (Web Navigation: Designing the User Experience, O'Reilly & Associates. 1998) provide additional guidance for analysis and design. A wide var iety of informa tion sources on analysis modeling for Web engineering is available on the Internet. An up-to-date list of World Wide Web references can be found under "software engineering resources" at the SEPA Web site: http://www.mhhe.com/pressman.