Modelling Internet Applications

1
Modelling Internet Applications

• Part IIIWeb Application Development

2
What If, you Build a ...
Skyscraper, Burj Dubai
Dog House Approach tool-driven, ad-hoc, little
pre-planning
Dog House
Dog House Approach tool-driven, ad-hoc, little
pre-planning
complex construction
simple construction
3
What If, you Build a ...
But what about Today's Web Applications?
Yesterday's Simple Static Web Sites
Dog House Approach tool-driven, ad-hoc, litte
pre-planning
simple construction
Development History
4
Today's Web Applications Increased Complexity
Complexity
simple construction
Development History
5
Today's Web ApplicationsDevelopment Practices

• Current Situation
• seen as a one-time event
• spontaneous
• little pre-planning
• based on the experiences of individual developers
• limited to recycling in the sense of the
  copypaste paradigm
• inadequately documenting of design decisions
• ad-hoc implementation
• tool- and technology-driven

• Negative Consequences
• poor quality of web applications
• un-fulfilled user requirements
• failure to meet business needs
• project schedule delays
• budget overrun

"Dog House" Approach!
6
Today's Web ApplicationsDevelopment Practices
Even, seldomly works for a dog house!
7
Development Misconceptions

• Document centric approach
• development is seen as an authoring activity
• creation and linking of web pages and inclusion
  of graphics
• Assumed simplicity of development
• due the availability of different tools, such as
  HTML editors or form generators
• Know-how from related disciplines is applied
  directly
• common misconception that the development of Web
  applications is analogous to the development of
  traditional applications
• know-how from disciplines which could be used is
  not applied (e.g., Hypermedia and Human Computer
  Interaction)

8
Problems of Large Scale Web Projects

• failure to meet business needs (84)
• project schedule delays (79)
• budget overrun (63)
• lack of functionality (53)
• poor quality of deliverables (52)

like as the 60ies software crisies
Risk of a "Web Crisis" analogously to the
Software Crisis
Source Cutter Consortium, Poor Project
Management Number-one Problem of Outsourced
E-projects, Cutter Research Briefs, November,
2000, http//www.cutter.com/research/2000/crb00110
7.html
9
Web Engineering

• Today's Web applications are certainly complex!

Consequently a systematic approach is
necessary!
Web Engineering

• Definition

Web Engineering is the application of a
systematic, disciplined, and quantifiable
approaches (concepts, methods, techniques, tools)
to cost-effective requirements analysis, design,
implementation, testing, operation, and
maintenance of high-quality Web applications.
Web Engineering is also the scientific discipline
concerned with the study of these approaches.
Kappel, G., Pröll, B., Reich, S.,
Retschitzegger, W., "Web Engineering - The
Systematic Development of Web Applications",
Wiley, 2006.
10
Web Engineering

• Definition similar to Software Engineering!
• Are Web applications are just another application
  domain of Software Engineering?
• Why not just apply Software Engineering?!
• The distinguishing feature between Web
  applications and traditional software
  applications is the way in which the Web is used,
  i.e. its technologies and standards, as a
  development platform as well as a user platform.

11
Web Engineering

Web Engineering
Software Engineering
12
Web Engineering

• But, no need to throw all the good over !board
• The basic principles of Web engineering can,
  however, be described similarly to those of
  software engineering
• Clearly defined goals and requirements
• Systematic development of a Web application in
  phases
• Careful planning of these phases
• Continuous audit of the entire development process

13
Systematic DevelopmentEmploying Models

• A systematic development approach also for
  developing Web applications needed!
• Models are one instrument for
• reducing complexity
• abstracting from technology
• reusing well-documented design decisions
• Models facilitate
• comprehension of a complex system in its
  entirety
• communication among project team
• architectural soundness

14
What is a Model?

• A model is an abstraction of a part of the real
  world for a special purpose to
• ... overcome complexity
• ... point out essential aspects
• ... facilitate communication, documentation and
  reuse

merge
Metamodel Abstract Syntax
merge
merge
Diagrams Concrete Syntax
merge
merge
cd A
Person
instanceOf
Modell
Model
intover a

Student
Assistent
View
View
Real World
ref
X
15
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

16
The Role of Model in the Development

• Models as sketch
• For communicating ideas and alternatives
• Essence Selectivity
• Sketchers dont 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
17
Model - Code Interplay
Code Viszalization
RoundtripEngineering
Model-centric / Model-driven
Code only
Model only
Model
Model
Model
Code
Code
Code
"Models as Code"
18
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)

19
Historical Perspective

• Shifts to higher levels of abstraction have
  occurred before
• Years Prevalent Programming language
• 1950 Raw machine code
• 1950-1965 Assembly language
• 1965-1985 Procedural programming language
• 1985-today Object-Oriented programming
  language
• Today- Is MDA the next abstraction shift?
• In the 1960s the first machine code compilers
  were not very good. As time went by the
  generated assembly code was as good or even
  better than the code written by programmers.
• Likewise the first transformation tools are not
  very good.

Source Kleppe et al. MDA Explained The model
Driven Architecture practice and Promise
20
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

21
Model-Driven Development (MDD)The Vision

• Should go far beyond the notion of CASE tools of
  the 80s
• Reduced gap between problem and realization
  domain
• models as primary artifact througout 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., OMGs
  PIM, PSM and PDM)
• horizontal (M2M) and vertical (M2C)
  transformations
• Standards for uniform storage, exchange, and
  transformation of models, e.g., OMGs
• MOF (Meta Object Facility) and Eclipses
  realization Ecore
• XMI (XML Metadata Interchange) and
• OCL (Object Constraint Language)

22
Developing in the MDA

• PIM
• 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
Code Model
23
Benefits

• The Benefits of MDA
• Portability
• is achieved by focusing on the development of
  PIMs which are by definition platform
  independent. The same PIM can be used to
  generate multiple PSMs.
• Interoperability
• is achieved by generating not only the PSMs but
  the necessary bridges between them as well.
• Maintenance and documentation
• is achieved because MDA creates artifacts that
  are more usable than in the traditional SW
  development process.
• Productivity
• In MDA the focus for a developer shifts to the
  development of a PIM. The PSMs that are needed
  are generated by a transformation tools. (some
  one still has to come up with the transformation
  tools!)
• The main goal is to preserve the software
  investment as the infrastructure landscape
  changes around it.
• Data live longer than code!
• Hope that models live as long as data!

24
THE Difference with other software modeling tools
MDA Independence between the -Application
Developers -Platform Experts -Domain Experts

• Classic Approach
• The developers must comprehend
• Problem domain
• Platform features

25
The Role of MOF in MDA

• MDA is about expressing data and process
  precisely using formal languages
• How do we keep up with evolving languages or new
  languages?
• How do we transform models from one language to
  another?
• Solution Meta Object Facility
• Meta Object Facility (MOF) is the core
  constructs on which all other OMG models (Unified
  Modelling Language, Common Warehouse Model) are
  defined
• Acts as an Interchange facility
• Provides mechanisms to analyze XMI models
• Provides programmatic interface (IDL and JAVA) to
  manipulate models
• The MOF gives us the concepts and tools to reason
  about modeling languages. Using MOF definitions
  of a modeling language one can define
  transformations between modeling languages

"We will not be able to communicate with
extra-terrestrial since there will be no agreed
meta-language" -- linguists saying
26
MDA Specifications MOF
M3
M2
M1
27
OMG's Metamodelling Stack
M3
MOF/Ecore
Meta-Metamodel
instanceOf
Metamodel
M2
UML
Metamodel
instanceOf
Model
M1
a UML Model
Model
28
OMG's Metamodelling Stack
DTD-Grammar as EBNF ... elementdecl
'lt!ELEMENT' S Name S contentspec S? 'gt'
contentspec 'EMPTY' 'ANY' Mixed
children AttType StringType TokenizedType
EnumeratedType StringType 'CDATA' ...
M3
MOF
DTD-Grammar
Meta-metamodel Level
instanceOf
instanceOf
WebML Metamodel as DTD lt!ELEMENT ENTITY
(RELATIONSHIP)gt lt!ATTLIST ENTITY id ID REQUIRED
name CDATA IMPLIEDgt
M2
UML
WebML DTD
Metamodel Level
instanceOf
instanceOf
WebML Model as XML ltENTITY id"_4711"
name"User"/gt
29
The Role of UML in MDA

• Used for model description (UML is more
  expressive than XML,EJB, IDL, etc)
• A developer must be able to use UML to create a
  model of the system that will be built
• He/She should be able to develop models that are
  precise and consistent enough to be used with in
  MDA
• Standardization of UML profiles to create PIM -
  PSM mappings
• A fewer subset of developers will have the task
  to define transformations between models
• This group does not develop a model of a
  particular system, but instead defines
  transformations to be used for many models,
  models of many different systems
• Those developers can be called meta-developers

30
The Role of UML Profiles in MDA

• A profile defines a specialized metamodel which
  is a subset of UML metamodel
• A UML Profile defines a language specific for a
  given platform, like CORBA, JAVA or C by
  reusing some of the UML metamodel. A model with
  such a profile and its applied stereotypes can be
  used to specify PSMs

31
The Role of OCL in MDA

• Object Constraint Language (OCL) is a query and
  expression language for UML
• OCL is used in MDA to bring precision to source
  models and language definitions
• It is also used in the definitions of
  transformations
• One OCL query specifies the elements in the
  source model of a transformation while a second
  OCL expression specifies the elements in the
  target model

32
Basic concepts in MDA

• Model
• description or specification of (part of) a
  system written in a well-defined language. A
  model can be structural or behavioral.
• Platform Independent Model (PIM)
• view of a system from the platform independent
  viewpoint
• Platform Specific Model (PSM)
• view of a system from the platform specific
  viewpoint
• Platform Model
• platform and the services provided by that
  platform
• Transformation
• Is the automatic generation of a target model
  from a source model, according to a
  transformation definition
• Simple transformation
• Port interface is transformed to java class
• Component is transformed to java class etc..
• A well-defined language
• Is a language with well-defined form and meaning,
  which is suitable for automated interpretation by
  a computer. (e.g. a programming language)
• Model-driven
• using models to direct the course of
  understanding, design, construction, deployment,
  operation and maintenance.
• Computation Independent Viewpoint
• system and its environment

33
Model-Driven Development (MDD)The Challenges

• Modeling Language
• Abstraction
• general-purpose (UML) vs. domain-specific (DSLs)
• Complexity and Formality
• small set of core modeling concepts with precise
  semantics
• Separation of Concerns
• Dependability
• interdependencies (potentially conflicting)
  between concerns
• Composition
• integration of concerns for obtaining a holistic
  modeling view
• Model Management
• Heterogeneity
• abstraction mechanisms for bridging heterogenous
  (meta)-models
• Transformation
• automatic derivation of executable model
  transformations

R. France, B. Rumpe. Model-driven Development of
Complex Systems A Research Roadmap, 29th Int.
Conference on Software Engineering (ICSE), USA,
May 2007.
34
Scope of Modelling Traditional Applications
Ian Sommerville, Software Engineering,Addison
Wesley, 2006
Levels
User Interface
Application Logic
What to Model?
Structure
Phases
Analysis
Design
Implemen-tation
Behavior
Feature

• Used Modelling Formalisms
• Entity Relationship Technique (ER)
• UML (object-oriented, currently the "lingua
  franca")

• Roots of Modelling
• Data Engineering - focusing on structure
• Software Engineering - focusing on behavior

But does not regard the hypertextual and specific
characteristics of the Web!
35
Modelling Web Applications Dimensions of
Modelling
Acme-Beispiel weil WebSeite
Levels
Look Feel
Presentation
Navigation Access Structures
Hypertext
Content
Domain Dependent Data
W. Schwinger and N. Koch "Modeling Web
Applications",book chapter in Web Engineering,
Wiley Publishers, 2006.
36
Modelling Web Applications Dimensions of
Modelling
Acme-Beispiel weil WebSeite

• Separation of levels
• strict separation of levels
• explicit inter-dependencies between levels
• Flexible Mapping
• mapping as flexible as possible to allow
  derivation between levels
• Bottom-Up and Top-Down Design
• bottom-up starting with the content level
  (e.g. given database) and derive the hypertext
  and presentation level
• top-down content level is derived from the
  other levels

W. Schwinger and N. Koch "Modeling Web
Applications",book chapter in Web Engineering,
Wiley Publishers, 2006.
37
Modelling Web Applications Dimensions of
Modelling
Acme-Beispiel weil WebSeite
Levels
Presentation
Hypertext
structure user interface elements and their
composition behavior reactions to input
events, interaction and synchronization between
user interface elements
Content
Structure
structure page compositions and
navigational relationships behavior run-time
behavior of hypertext
Behavior
structure domain-dependent databehavior
domain-dependent application logic
Feature
W. Schwinger and N. Koch "Modeling Web
Applications",book chapter in Web Engineering,
Wiley Publishers, 2006.
38
Modelling Web Applications Dimensions of
Modelling
Acme-Beispiel weil WebSeite
Presentation

• Modeling formalism for structure and
  behavior
• Standard formalism vs. proprietary
  formalism
• Uniform formalism vs. divers formalism
• Concepts / Patterns

W. Schwinger and N. Koch "Modeling Web
Applications",book chapter in Web Engineering,
Wiley Publishers, 2006.
39
Modelling Web Applications Dimensions of
Modelling
Acme-Beispiel weil WebSeite
analyzing requirements
implementation independent design
implementationdecisions
Phases
Analysis
Design
Implemen-tation
W. Schwinger and N. Koch "Modeling Web
Applications",book chapter in Web Engineering,
Wiley Publishers, 2006.
40
Modelling Web Applications Dimensions of
Modelling
Acme-Beispiel weil WebSeite

• Define phases
• Define process
• Characteristics
• incremental and iterative
• prototyping
• intensive testing

Phases
Analysis
Design
Implemen-tation
W. Schwinger and N. Koch "Modeling Web
Applications",book chapter in Web Engineering,
Wiley Publishers, 2006.
41
Modelling Web Applications Dimensions of
Modelling
Acme-Beispiel weil WebSeite
W. Schwinger and N. Koch "Modeling Web
Applications",book chapter in Web Engineering,
Wiley Publishers, 2006.
42
Modelling Web Applications Dimensions of
Modelling
Acme-Beispiel weil WebSeite
Ubiquity - Technical Context - Natural Context -
Social Context
W. Schwinger and N. Koch "Modeling Web
Applications",book chapter in Web Engineering,
Wiley Publishers, 2006.