1. Web Application Modeling
Web Engineering
Web Application Modeling
Lecture III – 21st October 2008
Federico M. Facca

2. Where are we? There are some changes! # Date Title Lecturer 1 7th Oct
Web Engineering Introduction and Overview
F. M. Facca 2
14h Oct
Collection Requirements for Web Applications 3
21st Oct
Web Application Modeling 4
28th Oct
Developing Applications with WebML 5
4th Nov
Web Application Architectures 6
11th Nov
Testing and Usability on the Web 7
18th Nov
Web Technologies I 8
25th Nov
Mid Term Exam 9
2nd Dec
Web Technologies II 10
9th Dec
Web Technologies III 11
6th Jan
Web Application Development Process 12
13th Jan
Web 2.0 Mash-ups
F. Daniel (UNITN) 13
20th Jan
Project Management for Web Applications 14
27th Jan
Final Exam
There are some changes!

3. Overview
Introduction
Model Driven Development
Reference Scenario
Content Modeling
Hypertext Modeling
Presentation Modeling
Overview of Other Modeling Methods
Wrap-up

4. Why do we need modeling?
INTRODUCTION

5. Define an abstract view of a real-world entity
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

6. 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
Data Engineering (structure) E-R Chen 1976
UML covers structure, behavior, application logic and user interface
Aspects=orthogonal dimension! They refer to the aspects of levels. E.g. application logic structure, application logic behavior.
This is take from the book. As regards me, also content should be modeled for normal software applications….

7. 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
Methods adopted or the web are not new. They are derived from traditional SW.
But… hyperlinks?!
Why adding a new layer?
Corresponds to the status of web applications
Improve reuse
Content, is the content as displayed in the web application=information structure
Several pages access the same content…. If you model it you can reuse it.
Presentation:
structure: user interface elements and their composition
behavior: reactions to input events, interaction and synchronization between user interface elements
Hypertext:
structure: page compositions and navigational relationships
behavior: run-time behavior of hypertext
Content structure: domain-dependent data behavior: domain-dependent application logic
Phases: There are several approaches:
Information based
Presentation based
Logic based

8. We focus on object-oriented analysis & design
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.

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

10. 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
We saw something about “sharing” and “reusing” knowledge. Where? Can it help?

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

12. Model Driven Development
From sketch models to code models
Model Driven Development

13. Diagrams are, after all, just pretty pictures
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
Provision of an expressive modeling language
… to allow the specification, construction, visualization, and documentation of different artifacts of a software system
… to build different types of diagrams
… to provide for the exchange of models
Meaning of the term »Unified«
Support of the whole development process
Flexibility with respect to process models
Independence from development tools/platforms and programming languages
Employment for various application areas
Genericity of language concepts defined in the metamodel
Integration of »Best Practices«
M. Fowler, ”UML Distilled”, 1st edition, Addison Wesley, 1997

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

15. 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
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
degree of model-drivenness

16. Roundtrip Engineering Model-centric / Model-driven
Model - Code Interplay
Code Visualization
Roundtrip Engineering
Model-centric / Model-driven
Code only
Model only
Model
Model
Model
Model
In media stat virtus… but…
Round trip is not easy…. Why?
Code
Code
Code
Code
"Models as Code"

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

18. What is Model Driven Architecture?
MDA is defined and developed by the Object Management Group (OMG) since March 2001
MDA is:
"Model-Driven …"-framework for software development, defined by the OMG
open, vendor-neutral approach to interoperability using OMG's modeling specifications:
Unified Modelling Language (UML), Meta-Object Facility (MOF) and Common Warehouse Model (CWM)
Main ideas:
Addresses the complete system development life cycle
Separate specification from implementation
Specify a system that is independent of a platform
Transform a platform-independent (PIM) system specification into a specific platform (PSM)
Code generation
The MDA is an innovative approach to constructing an enterprise architecture. It is an initiative created by the Object Management Group. OMG’s focus has always been, and still is, to help users solve integration problems, in a productive way, by supplying open, vendor-neutral interoperability specifications, which is being achieved by the widely adopted CORBA standard . The MDA is OMG’s next step in solving integration problems, which is upward from application implementation to the level of application design, which takes full advantage of the successful Unified Modeling Language(UML) standard, also developed by OMG.

19. Model-Driven Development (MDD) The Vision
Should go far beyond the notion of CASE tools of the 80’s
Reduced gap between problem and realization domain
models as primary artefact throughout the lifecycle instead of code
models as program instead of models as sketch/blueprint
Systematic transformations of abstract models to concrete implementations
multiple levels of abstractions, (e.g., OMG’s PIM, PSM and PDM)
horizontal (M2M) and vertical (M2C) transformations
Standards for uniform storage, exchange, and transformation of models, e.g., OMG’s
MOF (Meta Object Facility) and Eclipse’s realization “Ecore”
XMI (XML Metadata Interchange) and
OCL (Object Constraint Language)

20. Developing in the MDA PIM PSM Code Model
Platform Independent Model(PIM) represents business functionality and behavior without technology details
PSM
Applies a standard mapping to create or generate a Platform Specific Model (PSM) from the PIM
Code Model
Create or generate the code for PSM
Platform
Independent
Model
Platform
Specific
Model
Lets now look at how applications are developed using the MDA.
Step 1.
All MDA development projects start with the creation of a Platform Independent Model(PIM), which is expressed in UML. The PIM expresses only business functionality and behavior. Built by business and modeling experts working together, this model expresses business rules and functionality undistorted, as much as possible, by technology. The clarity of this modeling environment allows business experts to ascertain, much better than they could if working with a technological model or application, that the business functionality embodied in the PIM is complete and correct. Another benefit: Because of its technological independence, the PIM retains its full value over the years, requiring change only when business conditions mandate.
Transition: MDA tool applies an standard mapping to generate Platform-Specific Model (PSM) from the PIM. Code is partially automatic, partially hand-written
Step 2.
Once the first iteration of the PIM is complete, it is stored in a MOF based Repository and input to the mapping step which will produce a Platform-Specific Model (PSM). To produce your PSM, you will have to select a target platform or platforms for the modules of your application. Such as J2EE, .NET etc.
Transition: MDA Tool generates all or most of the implementation code for deployment technology selected by the developer.
Step 3.
Once the PSM has been created/generated, the 3rd and final step is to generate the code/implementation model. This will create/generate all of the files the platform requires. When I talk about platforms, I’m referring to the application server(s) your application will run on and programming languages, such as Java, C++ or C# your application will be generated into. This will result in a first cut working application, which can be further enhanced through the MDA process or by hand-coding.
Take note that the mapping standard between PIM, PSM and the Code Model has been defined by OMG but the implementation not. MDA compliant tool vendors have implemented portions of the MDA, but OptimalJ is one of the few tools that has implemented the MDA completely to automatically generate a complete application from a PIM to PSM and finally to the Code Model.
Code
Model

21. Modeling Methods (not all are MDA)ER
OMT
1990
UML
HDM
1995
RMM
OOHDM
HDM-lite
WSDM
WAE
2000
WEBML
W2000
UWE
OOWS
MDA
HERA
WAE2
MDA appears only in 2001
Many existing approaches can be related to MDA principles even if the arrived before
WebSA is the only 100% MDA
WebML, UWE and OO-H has a MDA like approach
OO-H
2005
WebSA
Data-oriented
Hypertext-oriented
Object-oriented
SW-oriented

22. UML for Web Engineering
The book adopts the UML Web Engineering (UWE) notation
UML-compliant
Comprehensive modeling tool
Download it here:
Requires MagicDraw UML (the free edition is enough)
In the next lecture we will see WebML in details

23. A simple walkthrough case study
Reference SCENARIO

24. 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
IWWOST=International Workshop on Web-Oriented Software Technology

25. Actors I PC Chair PC Member 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

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

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

28. 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 message with the list of papers, and a URL to a page where he can access these papers is sent

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

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

31. How to model the data underlying a Web application
CONTENT MODELING

32. Purpose: To model the information requirements of a Web application
Introduction
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

33. Content Structure Model
Relation
Class name
Class attributes
Composition
Class operations
Can you model it with a E-R diagram? What will be missing?
Invariant
Derived attribute

34. Content Behavior Model
Initial State
Condition
Final State

35. How to model the hypertext of a Web application
Hypertext Modeling

36. Purpose: To model the navigation paths available to users
Introduction
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

37. 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 …
HDM:
Structural links connect elements of the same node, e.g., from a review summary to the review details
Perspective links put various views of a node in relation to each other, e.g., the PostScript and the PDF versions of a paper
Application links put different nodes in relation to each other, depending on the application, e.g., a link pointing to “best paper”.
WebML:
Contextual links carry context information, e.g., the unique number of a reviewer, to navigate from one reviewer to the reviews he or she created
Non-contextual links have no associated context information, e.g., links pointing from a single review to the list of all reviews.
With regard to the distribution of nodes on the hypertext level over pages on the presentation
level (see section 3.7), WebML specifies additionally the following types of links:
• Intra-page links are used when the source and the destination of a link belong to the same
page, e.g., when a link allows the user to directly navigate to the summary of a paper,
which is displayed further down on the page.
• Inter-page links are used when the source and the destination are on different pages, e.g.,
when detailed information about the authors and their papers are on different pages.

38. Navigation Structure Model
Is this model easy to understand?
Does this model resemble what you will have in the end?

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

40. Navigation Access Model
Is it clear to what page each component belongs?
I.e. what the relation with the previous schema?
Page identity is missing! The models cannot be mixed together: this is not intuitive.

41. Presentation Modeling
How to model the look&feel of a Web application
Presentation Modeling

42. The design should aim for simplicity and self-explanation.
Introduction
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

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

44. Presentation Structure Model

45. Presentation Behavior Model

46. Overview of Oder Modeling Methods
How other model looks like?!
Overview of Oder Modeling Methods

47. HERA

48. OOHDM

49. WebML

50. That’s almost all for day…
WRAP-up

51. Things to keep in mind (or summary)
Modeling is fundamental
Helps development
Support communication
Model Driven Design and Development
Automatic code generation of Web applications
One model for each layer
Content
Navigation
Presentation
Different methods have different expressive power

52. Bibliography Mandatory reading Suggested Web Engineering
Chapter 3
Suggested
First International Workshop on Web-Oriented Software Technology
UML-based Web Engineering

53. Assignments I It’s a compulsory team assignment
Up to 8 points (as always extras are possible)
You have to use UWE to model the described system
It’s the starting point for next assignments
You have to prepare a presentation
10 minutes
~ 5 slides
You have to prepare a report
To be delivered on 2nd November for the opponents to read it
The grade will be assigned during a design review
A opponent group will revise the design models according to requirements
The review will be “live” in the lecture on 4th November
Review guidelines in the next lecture

54. Assignment II
The hospital of Innsbruck needs a Web application to handle online visit reservation
The application should handle:
Information on patient (name, surname, social security code, date of birth, address, blood type, family anamnesis, physiologic anamnesis, pathologic anamnesis)
Information on doctors (name, surname, social security code, date of birth, specialization, role, year of experience)
Information on visits (ID visit, visit type, information on the visit, date, report)
All the visit reservation process:
Reservation
Provisioning
Report publication

55. Assignment III
The application requires different type of user with different functionalities
Patients
General Information
Reservation of visits
Visualization of existing visit reservations
Visualization of reports
Doctors
Editing of reports
Administrators
Editing of data related to visit typology and associated price

56. All the users needs to authenticate through username and password
Assignment IV
All the users needs to authenticate through username and password
Simplification
When the users logs in is redirected to the proper Web application/page according to the role
Calendar handling is not required
For reservation only data required are the day and the time (from Monday to Friday) and the time (from 8.00 to 17.00)

57. Next Lecture # Date Title Lecturer 1 7th Oct
Web Engineering Introduction and Overview
F. M. Facca 2
14h Oct
Collection Requirements for Web Applications 3
21st Oct
Web Application Modeling 4
28th Oct
Developing Applications with WebML 5
4th Nov
Web Application Architectures 6
11th Nov
Testing and Usability on the Web 7
18th Nov
Web Technologies I 8
25th Nov
Mid Term Exam 9
2nd Dec
Web Technologies II 10
9th Dec
Web Technologies III 11
6th Jan
Web Application Development Process 12
13th Jan
Web 2.0 Mash-ups
F. Daniel (UNITN) 13
20th Jan
Project Management for Web Applications 14
27th Jan
Final Exam

58. Questions?