1. Web Application Modeling
Web Engineering
Web Application Modeling

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

3. 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….

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

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

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

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

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

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

10. Unified Modeling Language (UML)
“The Unified Modeling Language is a visual language for specifying and documenting the systems.”
Language of choice (and ISO standard) for diagramming notation in 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

11. 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
Models as program
Applications are automatically generated
Essence: models become the source code
degree of model-drivenness

12. 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),
Model Driven Architecture (MDA)
Model Driven Web Engineering (MDWE)

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

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

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