Bachelor of Information Technology

CIT3124
WEB PROJECT
WEEK 3
Web Applications Modeling
Ashley Ng Sok Choo
[email protected]
1
Last Updated:May 4, 2024
© LMS SEGi education group
 LEARNING OBJECTIVES

 Describe the Model Driven Web Application

Development.
 Identify content modeling and hypertext
modeling and presentation modeling in Web
Application Development.
 Identify different modeling methods.
 Overview of state-of-the-art modeling and tools.
2
Last Updated:May 4, 2024
© LMS SEGi education group
 LEARNING OUTCOMES

 After completing this lesson, learners will be able to:

 Describe the Model Driven Web Application
Development.
 Identify content modeling and hypertext modeling and
presentation modeling in Web Application
Development.
 Choose an appropriate modeling methods for web
application development.
 Apply modeling tool in web application development.
3
Last Updated:May 4, 2024
© LMS SEGi education group
 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

4
Last Updated:May 4, 2024
© LMS SEGi education group
 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
5
Last Updated:May 4, 2024 © LMS SEGi education group 5
 WEB APPLICATION MODELING
Levels
Presentation
Hypertext
Customization
Content

Structure
Phases
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 6
Last Updated:May 4, 2024 © LMS SEGi education group 6
 WEB MODELING

 Modeling static & dynamic aspects of content, hypertext,

and presentation
 We focus on object-oriented analysis & design
 Analysis: Finding & discovering classes of objects/
concepts in a domain
 Design: Defining software objects & how they interact
to fulfill requirements.

7
Last Updated:May 4, 2024 © LMS SEGi education group 7
 OBJECTS

 Software entities – like real-world entities - that consist of

states and behaviors
 States:
 Variables store the states of an object’s properties
 Hidden from the outside world (data encapsulation)
 Behaviors:
 Methods define the object’s behaviors
 Used by objects to communicate with other objects
 Classes
 blueprints for creating objects of a particular type
8
Last Updated:May 4, 2024 © LMS SEGi education group 8
 DISCOVERING OBJECTS IN A DOMAIN
 The way we represent a domain’s software model should resemble the

physical model as closely as possible

 To find key classes of objects:
 Reuse existing models, if they exist
 Make a category list
 People, places, things
 Transactions
 Events
 Identify noun phrases
 When naming classes, use terms that are commonly used in the domain
 i.e., terms users would understand
9
Last Updated:May 4, 2024 © LMS SEGi education group 9
 ASSIGNING RESPONSIBILITIES

 Responsibilities are an object’s obligations, or behaviors

related to its role in the system
 What does an object do?
 Doing something (to) 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 10
Last Updated:May 4, 2024 © LMS SEGi education group 10
 WHY MODELS AT ALL?

 When it comes down to it, the real point of

software development is cutting code.
 Diagrams are, after all, just pretty pictures.
 No user is going to thank you for pretty pictures;
what a user wants is software that executes.

M. Fowler, ”UML Distilled”, 1st edition, Addison Wesley, 1997

11
Last Updated:May 4, 2024 © LMS SEGi education group 11
 UNIFIED MODELING LANGUAGE (UML)

 “The Unified Modeling Language is a visual

language for specifying and documenting the
artifacts of systems.”
 Language of choice (and ISO standard) for
diagramming notation in OO development.
 Structural – Class diagrams (domain models)
 Behavioral – Use Cases, Sequence diagrams
 Currently at version 2.0, although many analysts
and designers still use 1.0. 12
Last Updated:May 4, 2024 © LMS SEGi education group 12
 THE ROLE OF MODEL IN THE DEVELOPMENT
 Models as sketch
 For communicating ideas and alternatives
 Essence: Selectivity
 “Sketchers” don’t have to care much about
degree of model-drivenness

 Models as blueprint
 All design decisions (maybe of a particular area) are laid out
 Essence: Completeness – programming should be pretty

straightforward
 Issue of reverse engineering
 Models as program
 Applications are automatically generated
 In MDA separation of Platform Independent Model (PIM) and Platform Specific Model (PSM);

ideally the transformation is "parameterized" by a Platform Description Model (PDM)

 Essence: models become the source code
 Semantics and transformations (QVT, ATL) the holy grail of MDA
13
Last Updated:May 4, 2024 © LMS SEGi education group 13
 MODEL - CODE INTERPLAY

Code only Code Roundtrip Model-centric /

Model only
Visualization Engineering Model-driven

Model Model Model Model

Code Code Code Code

"Models as Code"

14
Last Updated:May 4, 2024 © LMS SEGi education group 14
 MODEL-DRIVEN

 Systematic development on basis of models

 Models become the first hand artifacts in the software development cycle
 Key concepts
 abstraction from implementation detail
 systematic transformations
 Related Terminology
 Model Driven [Software] Engineering (MDE),
 Model Driven [Software] Development (MDD/MDSD),
 Model Driven Architecture (MDA)
 Model Driven Web Engineering (MDWE)

15
Last Updated:May 4, 2024 © LMS SEGi education group 15
 MODELING METHODS
ER
OMT
1990 UML

HDM

1995 RMM
HDM-lite OOHDM
WSDM
WAE

2000 WEBML
W2000 UWE
2001 HERA MDA OOWS WAE2

OO-H
2005
WebSA
Data- Hypertext Object- SW-
oriented -oriented oriented oriented

16
Last Updated:May 4, 2024 © LMS SEGi education group 16
 A SIMPLE WALKTHROUGH CASE STUDY

REFERENCE SCENARIO

17
Last Updated:May 4, 2024 © LMS SEGi education group 17
 THE CONFERENCE REVIEW SYSTEM

 This case study was presented at IWWOST 2001 to compare

different Web application modeling methods

 The purpose of the system is to support the process of

submission, evaluation and selection of papers for a

conference.
 Reviewed methods includes:
 UWE
 OOHDM
 WSDM
 WEBML 18
Last Updated:May 4, 2024 © LMS SEGi education group 18
 ACTORS I
 PC Chair
 creating the conference

 determining the conference topics (or tracks) and

subjects
 establishing the Program Committee

 defining the final list of accepted and rejected papers

 defining the conference deadlines: submission,

review, and notification.

 PC Member
 evaluating a set of papers assigned to him

 indicating another person as a reviewer of a paper

 advising the PC Chair for the final list of accepted

papers
19
Last Updated:May 4, 2024 © LMS SEGi education group 19
 ACTORS II

 Reviewer
 responsible for reviewing a paper
 Author
 submitting a paper for acceptance at the conference
 PC Members and Reviewers may also be Authors,
they must have different Ids for each role

20
Last Updated:May 4, 2024 © LMS SEGi education group 20
 FUNCTIONS I: PAPER SUBMISSION

 Any registered author may submit a paper

 The author must register: the title, the abstract, the conference
track, and a set of subjects chosen from a list previously
determined by the PC Chair, if there is one
 The system, after checking the authors’ registrations, assigns a
paper ID to the new paper, and allows the user to submit it by
uploading a file
 At any moment, an author is allowed to check the data about his
submitted papers. Until the submission deadline, the author is
also allowed to substitute the uploaded file by a new one, or to
change any of the informed data about the paper
21
Last Updated:May 4, 2024 © LMS SEGi education group 21
 FUNCTIONS II: ASSIGNMENT OF PAPERS TO PC MEMBERS

 The PC Chair may indicate potential conflicts of interest

between PC Members and submitted papers.
 Once the submission deadline has been reached
 PC Members may indicate their interest and also conflicts
of interest with some papers.
 In case of conflict of interest, the PC Member will not see
any information about the paper.
 The PC Chair assigns papers to PC Members for
reviewing, an email message with the list of papers, and a
URL to a page where he can access these papers is sent.
22
Last Updated:May 4, 2024 © LMS SEGi education group 22
 FUNCTIONS III: ENTERING A REVIEW

 A PC Member, or a Reviewer, may enter a review for a

paper assigned to him
 The review is entered by accessing a form containing all
the evaluation items
 A PC Member may see other reviews (entered by others)
for any of the papers he is reviewing, but only after he
has entered his own review
 The PC Chair has full access to all papers and all
reviews
23
Last Updated:May 4, 2024 © LMS SEGi education group 23
 FUNCTION IV: CHOOSING ACCEPTED AND REJECTED PAPERS

 Once the review deadline has been reached, the review

process is closed
 The PC Chair, taking into account the recommendations
of the PC Members and reviewers, chooses the papers
that will be accepted and rejected
 Once the process is marked as finalized by the PC
Chair, the system issues a notification message to paper
authors, which includes the appropriate parts of the
reviews submitted by the PC Members and reviewers
24
Last Updated:May 4, 2024 © LMS SEGi education group 24
 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

25
Last Updated:May 4, 2024 © LMS SEGi education group 25
CONTENT STRUCTURE MODEL
Relation

Class name

Class attributes

Composition
Class operations

Invariant

Derived attribute

26
 CONTENT BEHAVIOR MODEL

Initial State

Condition
Final State

27
Last Updated:May 4, 2024 © LMS SEGi education group 27
 HYPERTEXT MODELING

 Purpose: To model the navigation paths available to users

 UWE 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
 Based on content models

28
Last Updated:May 4, 2024 © LMS SEGi education group 28
 DIFFERENT MODELS DIFFERENT LINKS

 HDM (Hypertext Design Model)

 Structural links
 Perspective links
 Application links
 WebML (Web Modeling Language)
 Contextual links
 Non-contextual links
 Intra-page links
 Inter-page links 29
Last Updated:May 4, 2024 © LMS SEGi education group 29
 NAVIGATION STRUCTURE MODEL

30
Last Updated:May 4, 2024 © LMS SEGi education group 30
 NAVIGATION 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 of objects of the same type)
 <<menu>> (list of heterogeneous objects)
 <<guided-tour>> (sequential links)
 <<query>>
31
Last Updated:May 4, 2024 © LMS SEGi education group 31
 NAVIGATION ACCESS MODEL

32
Last Updated:May 4, 2024 © LMS SEGi education group 32
 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
33
Last Updated:May 4, 2024 © LMS SEGi education group 33
 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
34
Last Updated:May 4, 2024 © LMS SEGi education group 34
 PRESENTATION STRUCTURE MODEL

35
Last Updated:May 4, 2024 © LMS SEGi education group 35
 PRESENTATION BEHAVIOR MODEL

36
Last Updated:May 4, 2024 © LMS SEGi education group 36
 REFERENCES

 Gerti Kappel, Birgit Proll, Seiegfried, and Werner

Retschitzegger. (2003). Web Engineering, Gerti Kappel,
et al. (eds.), John Wiley and Sons.
 Kathy Schwalbe.(2009). Introduction to Project
Management, 2nd Edition. Cengage Learning.
 James Bennett.(2008). Exploring Web Technologies for
Designers, Cengage Learning.

37
Last Updated:May 4, 2024
© LMS SEGi education group
 KEY TERMS

 Modeling: the representation, often mathematical, of a process,

concept, or operation of a system.
 Unified Modeling Language (UML): a visual language for
specifying and documenting the artifacts of systems.
 Actor: a person or system that interacts with the software
application in support of a specific process or to perform a
specific operation or related set of operations.
 Class: an software object’s interface and implementation.
 Workflow: the set of relationships between all the activities in a
project, from start to finish.
38
Last Updated:May 4, 2024
© LMS SEGi education group