Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd
Upload
2 views

Lecture 7- Modeling Web Application

The lecture by Dr. Divya Rishi Sahu focuses on modeling web applications through various phases such as requirements analysis, design, implementation, and maintenance. It emphasizes the importance of creating models to define abstract views, reduce complexity, and serve as communication tools, while introducing UML as a standard for diagramming in object-oriented development. The lecture also covers use cases, class diagrams, state machine diagrams, and hypertext structure modeling to illustrate the dynamic and structural aspects of web applications.

Uploaded by

Deshna Jain
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
2 views

Lecture 7- Modeling Web Application

The lecture by Dr. Divya Rishi Sahu focuses on modeling web applications through various phases such as requirements analysis, design, implementation, and maintenance. It emphasizes the importance of creating models to define abstract views, reduce complexity, and serve as communication tools, while introducing UML as a standard for diagramming in object-oriented development. The lecture also covers use cases, class diagrams, state machine diagrams, and hypertext structure modeling to illustrate the dynamic and structural aspects of web applications.

Uploaded by

Deshna Jain
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 43

Lecture 7

Topic: Modeling Web Application


By
Dr. Divya Rishi Sahu
Assistant Professor, CSE Department
Samrat Ashok Technological Institute (SATI), Vidisha
2.3 Modeling Web
Application
Summary – Web Engineering

Requirements
Analysis

Maintenance Design

Testing Implementation
Why Create Models?

■ Define an abstract view of a real-world entity


□ Finding & discovering objects/concepts in a domain
□ Assigning responsibilities to objects

■ Tool of thought
□ Reduce complexity
□ Document design decisions

■ Means of communication
Web Modeling

■ Modeling static & dynamic aspects of


content, hypertext, and presentation.

■ We focus on object-oriented analysis &


design
□ Analysis: Finding & discovering objects/ concepts
in a domain
□ Design: Defining software objects & how they
interact to fulfill requirements.

■ Key skill: Assigning responsibilities to


objects
Assigning Responsibilities

■ Responsibilities are obligations or specific


behaviors related to its role.

■ What does an object do?


□ Doing something itself
□ Pass actions (messages) to other objects
□ Controlling & coordinating the activities in other objects

■ What does an object know?


□ Private, encapsulated data
□ Its related objects
□ Items it can derive or calculate
Software Application Modeling
Levels

User interface

Application Logic

Phases
Structure Analysis Design Implementation

Behavior

Aspects

■ Levels – the “how” & “what” of an application

■ Aspects – objects, attributes, and relationships; function & processes

■ Phases – Development cycle


Unified Modeling Language (UML)

■ “The Unified Modeling Language is a visual


language for specifying and documenting the
artifacts of systems.” [OMG03a]

■ Language of choice (and ISO standard) for


diagramming notation in OO development.
□ Structural – Class diagrams
□ Behavioral – Use Case diagrams, State machine
diagrams
Web Application Modeling
Levels
Presentation
Hypertext
Customization
Content

Phases
Structure Analysis Design Implementation

Behavior

Aspects
■ Levels – Information, node/link structure, UI & page layout separate.

■ Aspects – Same as Software Applications

■ Phases – Approach depends upon type of application

■ Customization – Context information


Web Application Modeling

■ For Web-centric modeling, we will employ


the UML Web Engineering (UWE) notation.
□ http://www.pst.ifi.lmu.de/projekte/uwe/
□ Relies on Object Management Group (OMG)
standards – (i.e., UML-compliant)
□ Comprehensive modeling tool
□ Supports semi-automatic generation of code
Modeling Requirements

■ Already know the methods of web


application requirements, to-
■ Identify
■ Analyse
■ Describe
■ Evaluate
■ Manage

■ Use case are the preferred modelling


technique for functional requirements
Modeling Requirements

■ Serves as a bridge between Requirements &


Design phases

■ Uses cases – functional requirements written as


a collection of related success & failure
scenarios.
□ Scenario – a sequence of actions & interactions
between actors and a system.

■ Preferred means of modeling requirements


□ Written descriptions are easy to understand
□ Emphasize the users goals and perspective
Use Cases

■ Defining valid use cases:


□ The Boss Test – measurable value
□ The EBP Test – one person, one place, one time
□ The Size Test – more than one step

■ Which is a valid use case?


□ Negotiate a Supplier Contract
□ Handle Returns
□ Log In
□ Move Piece on Game Board
Use Cases

■ Critical components
□ Use Case Name – starts with a verb
□ Level – “user-goal” or “subfunction”
□ Primary Actor – the user whose goal is fulfilled
□ Stakeholders & Interests – Who cares, and what do
they want?
□ Preconditions – What must be true at the start
□ Success Guarantee – defines the successful
completion of the use case for all stakeholders
Use Case – Example 1
■ Use Case 1: Create User

■ Scope: University or business network

■ Level: user goal

■ Primary Actor: user (system administrator)

■ Stakeholders and Interests:


□ System Administrator: Wants control over users’ access to system resources.
□ New User: Wants access to system resources for communication, business,
and research.
□ Organization: Wants security and controlled access of organization resources,
data, intellectual property; wants employees/students to have appropriate
system access to fulfill the goals of the organization.

■ Preconditions: User is identified, authenticated, and has opened


administration tool

■ Success Guarantee: New user account is created and saved. Username


and password grant the new user access to network.
Use Case – Example 1 [cont.]

■ Main Success Scenario:


1. System requests input for username & password
2. User enters username & password
3. System requests other identifiable user information (ex.
real name, SSN#, address)
4. User enters other identifiable user information
5. System verifies username & password
6. System stores new user information
7. System displays success message
8. System presents user options
Use Case Guidelines

■ Use shorts sentences

■ Delete “noise” words


□ NO : “The System authenticates…”
□ YES: “System authenticates…”

■ Avoid technology-specific terms (initially, at


least)
□ NO : “Cashier swipes Product ID across scanner.”
□ YES: “Cashier enters Product ID.”
Use Case Diagrams

■ Provide a graphical overview of a system’s use


cases, its external actors, and their relationships

■ Use case diagrams are NOT requirements!

■ Can be used for functional & hypertext


requirements
□ Same model (UWE/authors’ approach)
□ Use “<<navigation>>” annotation to distinguish
hypertext from functional
Use Case Diagram - Example

■ Conference Paper Submission System

Source: Web Engineering – Kappel et al.


Content Modeling

■ Purpose: To model the information


requirements of a Web application
□ Diagramming the structural (i.e., information
objects) & behavioral aspects of the information.
□ NOT concerned with navigation.

■ Primary Models
□ Class diagrams – enough for static applications.
□ State machine diagrams – captures dynamic
aspects
Class Diagram – Example 1

■ Conference Paper Submission System

Source: Web Engineering – Kappel et al.


Class Diagrams

■ Notations

Class Name

Multiplicity
Attributes

Operations

Source: Web Engineering – Kappel et al.


SWE 444: Internet & Web Application Development
Class Diagrams
■ Notations (continued)

Composition Derived Attribute Value

Invariant

Source: Web Engineering – Kappel et al.


SWE 444: Internet & Web Application Development
Class Diagram – Example 2
■ Online Library Application

Source: Web Engineering – Kappel et al.


SWE 444: Internet & Web Application Development
State Machine Diagrams

■ For dynamic Web applications, they depict


important states and events of objects, and how
objects behave in response to an event (transitions)

■ Show the life-cycle of an object.

■ Used only for state-dependent objects

■ For pure UML modeling, can be very useful for


hypertext models (next section).
State Machine Diagram - Example

Source: Web Engineering – Kappel et al.


Hypertext Structure Modeling

■ Purpose: To model the navigation paths available


to users.

■ Artifacts
□ Hypertext Structure Model – navigating among classes
□ Access Model – UML-compliant site map

■ Focuses on the structure of the hypertext &


access elements.

■ Use “<<navigation class>>” annotation to


distinguish from content classes.
Hypertext Structure Model

■ Conference Paper Submission System

Source: Web Engineering – Kappel et al.


Link Classification Types

■ HDM (Hypertext Design Model)


□ Structural Link vs. Perspective Link vs.
Application Link

■ WebML (Web Modeling Language)


□ Contextual vs. Non-contextual Links
□ Intra-page vs. Inter-page Links
■ UWE (UML based web Engineering)
□ Navigation vs. Process vs. External links

■ OO-H (Object Oriented Hypermedia)


□ I, T, R, X, S-links
Link Classification Types

■ OO-H (Object Oriented Hypermedia)


□ I-Link (Internal Link)
□ T-Link (Traversal Link)
□ R-Link (Requirement Link)
□ X-Link (External Link)
□ S-Links (Service Link)
Access Model

■ Hypertext structure models describe


navigation, but not orientation.

■ Access models describe both through


Navigation patterns, used to consistently
describe conventional elements.
□ <<index>> (list)
□ <<guided-tour>> (sequential links)
□ <<menu>>, <<query>>
Access Model - Example

Source: Web Engineering – Kappel et al.


Presentation Modeling

■ Purpose: To model the look & feel of the Web


application at the page level.

■ The design should aim for simplicity and self-


explanation.

■ Describes presentation structure:


□ Composition & design of each page
□ Identify recurring elements (headers/footers)

■ Describes presentation behavior:


□ Elements => Events
Levels of Presentation Models

■ Presentation Page – “root” element;


equivalent to a page container.

■ Presentation Unit
□ A fragment of the page logically defined by
grouping related elements.
□ Represents a hypertext model node

■ Presentation Element
□ A unit’s (node’s) informational components
□ Text, images, buttons, fields
Composition Model - Example

■ Paper and Author Page Templates

Source: Web Engineering – Kappel et al.


Sequence Diagrams

■ Purpose: Depicts sequential interactions


(i.e., the flow of logic) between objects in an
application over time.
□ What messages, what order, & to whom.
□ Ex.: Object A calls method of Object B
□ Ex.: Object B passes method call from Object A
to Object C.

■ Result: Dynamic system interactions


diagrammed in a “fence” format.
Sequence Diagram - Notation

Object Instance

Lifeline

Focus of Control

Synchronous
Message

Destroy Object

Source: Wikipedia – Sequence Diagram


Sequence Diagram – Example 1

Source: Web Engineering – Kappel et al.


Sequence Diagram – Example 2

Source: Web Engineering – Kappel et al.


Modeling Methods

■ We’ve primarily discussed Object-Oriented


Modeling (e.g., UML), but there are other
methodologies:
□ Data-Oriented (Hera, WebML)
□ Hypertext-Oriented (HDM)
□ Software-Oriented (WAE)

■ Choosing a method depends on system


purpose, focus, and requirements
DRS
Conclusion
1. DD
2.43

drsahu.cse@satiengg.in
https://sites.google.com/view/drdivyarishisahu/home

You might also like