Analysis of web based applications

1. 1
Web Engineering
A presentation by
Athul
Sai(P3MCA12012)
Sreejith
S(P3MCA12036)

2. 2
Web Applicat ions
 WebApps encompass:
 complete Web sites
 Simple information Web sites
 Complex e-Commerce of other sites with embedded
functionality and data retrieval
 Complex Web sites that are interoperable with other
legacy software and systems
 specialized functionality within Web sites
 information processing applications that reside on
the Internet or on an intranet or ExtraNet.

3. 3
WebApp At t ribut es—I
 Network intensiveness. A WebApp resides on a network
and must serve the needs of a diverse community of
clients.
 Concurrency. A large number of users may access the
WebApp at one time; patterns of usage among end-users
will vary greatly.
 Unpredictable load. The number of users of the WebApp
may vary by orders of magnitude from day to day.
 Performance. If a WebApp user must wait too long (for
access, for server-side processing, for client-side
formatting and display), he or she may decide to go
elsewhere.

4. 4
WebApp At t ribut es—I I
 Availability. Although expectation of 100 percent
availability is unreasonable, users of popular WebApps
often demand access on a “24/7/365” basis.
 Data driven. The primary function of many WebApps is to
use hypermedia to present text, graphics, audio, and video
content to the end-user.
 Content sensitive. The quality and aesthetic nature of
content remains an important determinant of the quality of
a WebApp.
 Continuous evolution. Unlike conventional application
software that evolves over a series of planned,
chronologically-spaced releases, Web applications evolve
continuously.

5. 5
WebApp At t ribut es—I I I
 Immediacy. WebApps often exhibit a time to market that
can be a matter of a few days or weeks.
 With modern tools, sophisticated Web pages can be
produced in only a few hours.
 Security. In order to protect sensitive content and provide
secure modes of data transmission, strong security
measures must be implemented throughout the
infrastructure that supports a WebApp and within the
application itself.
 Aesthetics. When an application has been designed to
market or sell products or ideas, aesthetics may have as
much to do with success as technical design.

6. 6
WebApp Cat egories
 informational—read-only content is provided with simple navigation and links
 download—a user downloads information from the appropriate server
 customizable—the user customizes content to specific needs
 interaction—communication among a community of users occurs via chatroom,
bulletin boards, or instant messaging
 user input—forms-based input is the primary mechanism for communicating
need
 transaction-oriented—the user makes a request (e.g., places an order) that is
fulfilled by the WebApp
 service-oriented—the application provides a service to the user, e.g., assists the
user in determining a mortgage payment
 Portal—the application channels the user to other Web content or services
outside the domain of the portal application
 database access—the user queries a large database and extracts information
 data warehousing—the user queries a collection of large databases and extracts
information

7. WebE layers
7

8. 8
The WebE Process
 Must accommodate:
 Incremental delivery
 Frequent changes
 Short timeline
 Therefore,
 An incremental process model should be used in
virtually all situations
 An agile process model is appropriate in many
situations

9. 9
The WebE Process
sof t ware increment
Release
refact oring
business analysis
formulat ion
it erat ion plan
analysis model
content
iteration
function
configuration
design model
content
architecture
navigation
interface
coding
component t est
accept ance t est
cust omer use
cust omer evaluat ion

10. 10
The WebE Process
Framework—I
 Customer communication
 Business analysis defines the
business/organizational context for the WebApp.
 Formulation is a requirements gathering activity
involving all stakeholders. The intent is to describe
the problem that the WebApp is to solve
 Planning
 The “plan” consists of a task definition and a
timeline schedule for the time period (usually
measured in weeks) projected for the development
of the WebApp increment.

11. 11
The WebE Process
Framework—I I
 Modeling
 Analysis model—establishes a basis for design
 Content Analysis.
 Interaction Analysis.
 Functional Analysis.
 Configuration Analysis.
 Design model—represents key WebApp elements
 Content design
 Aesthetic design
 Architectural design
 Interface design
 Navigation design
 Component design

12. 12
The WebE Process
Framework—I I I
 Construction
 WebE tools and technology are applied to construct
the WebApp that has been modeled
 Testing of all design elements
 Delivery and Evaluation (Deployment)
 configure for its operational environment
 deliver to end-users, and
 Evaluation feedback is presented to the WebE team
 the increment is modified as required (the beginning
of the next incremental cycle)

13. 13
WebE—Best Pract ices
 Take the time to understand the business needs and product
objectives, even if the details of the WebApp are vague.
 Describe how users will interact with the WebApp using a
scenario-based approach
 Develop a project plan, even it its very brief.
 Spend some time modeling what it is that you’re going to build.
 Review the models for consistency and quality.
 Use tools and technology that enable you to construct the
system with as many reusable components as possible.
 Don’t rely on early users to debug the WebApp—design
comprehensive tests and execute them before releasing the
system.

14. 14
Analysis Modeling f or
WebApps

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

16. 16
When Do We Perf orm
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

17. 17
The User Hierarchy
SafeHomeAssured.com
user
Figure 18.1 User hierarchy for SafeHomeAssured.com
guest regist ered
user
cust omer service
st aff
exist ing cust omernew cust omer

18. 18
Use-Case Diagram
Figure 18.2 Use-case diagram f or new-cust omer
new customer
log-in to
SafeHomeAssured.com
customize
SafeHome
describe
home layout
select
SafeHome
components
save
configuration
purchase
conf iguration
view
shopping cart
provide
purchase data
recall saved
configuration
peruse
descriptive
content
complete
SafeHome order
customization functionality
e-commerce functionality
<<inc lude>>
<<inc lude>>
<<inc lude>>
<<inc lude>>
<<inc lude>>
<<inc lude>>

19. 19
The Cont ent 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

20. 20
Dat a Tree
Figure 1 8 .3 Dat a t ree for aSafeHom e com ponent
component
part Number
part Name
part Type
description
price
MarketingDescript ion
Phot ograph
TechDescript ion
Schemat ic
Video
WholesalePrice
Ret ailPrice

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

22. 22
Analysis Class Example
Figure 18.4 Analysis classes for use-case: select SafeHomecomponents
BillOfMat erials
ident ifier
priceTot al
addEnt ry( )
delet eEnt ry( )
edit Ent ry( )
name( )
save( )
comput ePrice( )
Product Component
part Number
part Name
part Type
descript ion
price
creat eNewIt em( )
get Descript ion( )
get TechSpec
BoMIt em
quant it y
price
addt oList( )
delet efromList( )
Sensor Camera Cont rolPanel Soft Feat ure
1
*
1
*

23. 23
The I nt eract ion Model
 Composed of four elements:
 use-cases
 sequence diagrams
 state diagrams
 a user interface prototype
 Each of these is an important UML
notation

24. 24
Sequence Diagram
Figure 18.5 Sequence diagram for use-case:select SafeHomecomponents
new cust omer
:Room :FloorPlan
desc ribes
room *
plac es room
in f loor plan
:Product
Component
selec t s produc t c om ponent *
:Billof
Mat erials
add t o BoM
FloorPlan
Reposit ory
sav e f loor plan c onf igurat ion
sav e bill of m at erials
BoM
Reposit ory

25. 25
St at e Diagram
Figure 1 8 .6 Part ial st at e diagram for ne w c ust ome rinteract ion
n e w cu st o m e r
Validating user
system status=“input ready”
displaymsg = “enteruserid”
displaymsg =“enterpswd”
entry/ log-in requested
do: run user validation
exit/set user access switch
select “log-in”
userid
validated
password validated
Selecting user action
system status=“link ready”
display: navigation choices”
entry/ validated user
do: link as required
exit/user action selected
select other functions
select customization functionality
select e-commerce (purchase) functionality
Customizing
system status=“input ready”
display: basic instructions
entry/validated user
do: process user selection
exit/ customization terminated
select descriptive
content
room being defined
Defining room
system status=“input ready”
display: roomdef. window
entry/ roomdef.selected
do: run room queries
do: store room variables
exit/room completed
select descriptive
content
Building floor plan
system status=“input ready”
display: floor plan window
entry/ floor plan selected
do: insert room in place
do: store floor plan variables
exit/room insertion completed
select descriptive
content
select enter room in floor plan
Saving floor plan
system status=“input ready”
display: storage indicator
entry/ floor plan save selected
do: store floor plan
exit/save completed
select save floor plan
room insertion completed
next selection
customization complete
all rooms
defined

26. 26
The Funct ional 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

27. 27
Act ivit y Diagram
Figure 1 8 .7 Act ivit y diagram f or c omput e Pr i c e( ) ope r a t i on
init ialize t ot alCost
invoke
calcShippingCost
get price and
quant it y
components remain onBoMList
invoke
det ermineDiscount
discount < = 0
discount>0
t ot alCost=
t ot alCost - discount
t axTot al=
t ot alCost x t axrat e
no components remain onBoMList
lineCost =
price x quant it y
add lineCost t o
t ot alCost
priceTot al =
t ot alCost + t axTot al
+ shippingCost
ret urns:
shippingCost
ret urns: discount

28. 28
The Conf igurat ion 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

29. 29
Relat ionship-Navigat ion
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

30. 30
Navigat ion 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?

31. 31
Navigat ion Analysis-I I
 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?

32. THANKYOU 
32