Mo - 21 - Ebert - Lecture Model-Integrating Software

From Model-Based
to Model-Integrating Software
Jürgen Ebert
University of Koblenz-Landau
ebert@uni-koblenz.de
18.7.2014 Jürgen Ebert 1

Models and Software
This talk presents a Software Engineer‘s view on modeling,

distinguishing
– software for models, e.g.,
• services available on model artifacts
– models for software, e.g.,
• prescriptive models
in computer-aided software engineering (CASE)
• descriptive models
in reverse engineering.

Main Messages
Main Messages of this talk:

– Models are (semi-)formal objects.
– A large body of knowledge about modeling and
about software support for models has been achieved.
– Modeling langugages can be defined comprehensively.
– Models can be used at runtime as first class objects.

Table of Contents
1. Some Terminology
2. A Short History
• Model-Based Development
• Model-Driven Development
3. Model-Integrating Development
• Defining Modeling Languages
• Implementing Modeling Languages
4. Conclusion

1. SOME TERMINOLOGY

Models vs. Code
A model is a goal-oriented abstraction of something.
It reduces reality to those parts that are relevant for the goal
and it allows to draw conclusions about the original system.
In software engineering, models are used to represent

relevant knowledge about software systems.
Though (along the definition) code is also a model,

i.e., a model of computational processes, we use
– the term model for more abstract design descriptions and
– the term code for programs that are directly executable

Advantages of Models
Models are widely used since they are (usually)

– easily understandable for humans
– self-documenting,
– easy to understand and to evolve
and since they support
– separation of concerns.

Modeling Languages
From a Software Engineer‘s and Tool Builder‘s point of view,

models are instances of modeling languages.
Modeling languages may be

– general purpose or domain-specific
– visual, tabular or textual
– informal, semiformal, or formal.

Description of Modeling Languages
A modeling language may be described by

– its metamodel, which defines its abstract syntax
– a renderer that visualizes its concrete syntax, and
– some formalism that catches its semantics.

Modeling Languages
Representations Visualizations
conformsTo
Metamodel
isRenderedTo
Abstract Syntax Artifact

M3: conformsTo
Metametamodel
isRenderedTo
M2:
conformsTo
Metamodel
Abstract Syntax (Metamodel)
M1: isRenderedTo
Abstract Syntax (Model) Artifact

Modeling Tools
The use of models in a special domain, e.g., enterprise

modeling, requires appropriate tools for
– management of models
(storing and editing),
– additional services on models
(querying, transforming, comparing, ...), and
– process support of modeling methods
(guidance, enactment)
Many such tools have been developed over the last decades.

2. TOOLS FOR MODELS
(SHORT HISTORY)

2.1 MODEL-BASED SOFTWARE

1960s 1970s 1980s 1990s 2000s now
Model-Based Development
Definition ([Sauer2011SDO])
A development method is model-based, if it deploys models
to describe certain aspects of the system and models play an
important role in the development method. …
This idea of using models in the course of requirements

engineering and software development is about 50 years old.

1960s 1970s 1980s 1990s 2000s now
First Software Models
With the advent of software engineering, the use of several

(mostly visual) software description languages came up as
design description documents, e.g.:
– flowcharts (DIN 66001, 1966)
– dataflow diagrams (DIN 66001, 1966; Yourdon-DeMarco, 1975)
– entity-relationship diagrams (Chen, 1976)
–…
Editing was mostly done manually.

1960s 1970s 1980s 1990s 2000s now
First Software Models
DIN66001

1960s 1970s 1980s 1990s 2000s now
First Modeling Tools

Along with the use of visual languages, the need for
tools for editing them arose. Early tools allowed editing of
model artifacts (some of them working on ascii terminals).
Editing was at first done by simple drawing.
Then more and more knowledge about the syntax of the

respective modeling language was included.
The long walk from pictures to formal artefacts started.

1960s 1970s 1980s 1990s 2000s now

1960s 1970s 1980s 1990s 2000s now
Computer-Aided Software
Engineering (CASE)
With more and more new languages, the description of

modeling language (abstract) syntax by metamodels was
adopted.
With syntax-based editing, the basis for generating code

from models automatically was laid.

1960s 1970s 1980s 1990s 2000s now
First Crisis: (Too) Many Languages
Inspired by CASE, much work was invested to invent new

(and hopefully better) modeling languages for different
purposes, some of them being quite successful like
– SADT
– several Petri-net dialects
– HIPO-Charts
– NIAM-Diagrams
–…
which lead to hundreds of different languages
(each with their editors and possibly generators).

1960s 1970s 1980s 1990s 2000s now
Way out: Small Variety of Paradigms

Though the number of languages and dialects exploded,
in essence only a few description paradigms were used:
– module paradigm
– object-relationship paradigm
– control-flow paradigm
– dataflow-flow paradigm
– state-transition paradigm
–…
Some languages were hybrid, combining more than one
paradigm.

1960s 1970s 1980s 1990s 2000s now
Solutions
There were (at least) two ways out of this language chaos:
– Unification
defining an interlingua
that could play the role of a standard
– MetaCASE
building generic tools
that are parameterizable by the langage

1960s 1970s 1980s 1990s 2000s now
Unification prevailed (UML)
Since only a few paradigms for modeling software seemed to

be necessary, it was possible to define a common basic
standard.
This was done by OMG on the basis of a proposal of the three

book (and method) authors Booch, Jacobson, and Rumbaugh:
The Unified Modeling Language (UML).

1960s 1970s 1980s 1990s 2000s now
MetaCASE Lost
MetaCASE-tools are tools meant to build CASE-tools specialized

to specific modeling languages, e.g.,
– generators which generate specific tools
from tool descriptions
– generic tools which are parameterized by a language
description
– toolkits which support quick building of the target tool

1960s 1970s 1980s 1990s 2000s now
Further Support
In the context of the language crisis, more theory on language

definition (metamodeling) and model analysis (querying, incl.
constraint checking) was developed.
Metamodeling was pushed forward by the OMG.

Querying (including constraint checking) can be done by,
e.g., by OCL.

2.2 MODEL-DRIVEN SOFTWARE

1960s 1970s 1980s 1990s 2000s now
Model-Driven Development
Definition ([Sauer2011SDO])
A development method is model-driven, if models are the
central artifacts of the development method and model
transformations accompany the models.
These methods (e.g., OMG’s model driven architecture
(MDA)) combine views of an overall system model and
stepwise transform them to the resulting system. They
separate
– domain knowledge (in the views) and
– development knowledge (in the transformations).

1960s 1970s 1980s 1990s 2000s now
Transformation
combined model views
concretize by
transformation
Programs Icons Configs

1960s 1970s 1980s 1990s 2000s now
Transformation Languages
Transformation languages transform models m conforming

to a metamodel MM to a target model m’ conforming to a
target metamodel MM’.
transform

1960s 1970s 1980s 1990s 2000s now
Transformation Languages
Transformation languages build on query languages for

extracting information.
There are several variants, e.g.,

– outplace transformation languages (e.g., ATL, QVT-o)
– inplace transformations languages (e.g., Henshin)
– bidirectional transformation languages (e.g., QVT-r)
– coevolving transformation languages (e.g., GReTL)
and multivariant languages (e.g., FunnyQT).

1960s 1970s 1980s 1990s 2000s now
Example: GReTL
GReTL (Graph Repository Transformation Language) is an
embedded transformation language with a simple notation,
which coevolves metamodels and models on the level of
classes.

3. MODEL-INTEGRATING SOFTWARE

Body of Knowledge
The history of modeling in software engineering has lead

to a solid body of knowledge about
– modeling languages (syntax, semantics, pragmatics)
– data structures for storing models
– tools (services) working on models
– development and evolution methods involving models

1960s 1970s 1980s 1990s 2000s now
Body of Knowledge
Services for models are, e.g.:

– create and edit models (editors)
– check models (constraint manager)
– query models (query evaluator)
– transform models (transformation tool)
– generate code from models (code generator)
– execute models (interpreter)
– compare models (version manager)
–…

1960s 1970s 1980s 1990s 2000s now
Body of Knowledge
Having a basic understanding of the role of abstract

representations and a basic technology available for
– metamodeling,
– constraint description,
– querying,
– transformation and
– several more powerful services,
models can now function as first-class artifacts in software
engineering.

Model-Integrating Development
Definition
A development method is model-integrating, if models
become parts of the running software as first-class objects.
All advantages of models can be used,

and there is no redundancy any more between models and
code.

Models as Objects
Running software consists of a set of objects which

reference and/or call each other:
m3
m1
m2
In model-integrating software some of these objects are

representatives of models (Facades).

Model-Integrating Software
To achieve this,
– modeling languages must be described precisely and
comprehensively, and
– an appropriate infrastructure is needed to manage and
use (e.g., edit, query, transform, execute) models

DEFINITION OF
MODELING LANGUAGES

Comprehensive Language Model
Like all software languages, modeling languages must be

precisely defined in
– their syntax,
– their semantics, and
– their pragmatics.
The different facets of a given modeling language are

collected in a comprehensive language model (CLM).

Comprehensive Language Model

(Running) Example
The facets of a CLM are explained in the following along the

language of simple Petri nets.
Petri nets are a prototypical language for process modeling.

Syntax (abstract)
The essential (abstract) syntax can be described by a

metamodel.
The class Net is a representative concept for models,

i.e., models are instances of this class.

Syntax (abstract)
Metamodels can be extended by additional (restricting)

conditions, called constraints.

Syntax (concrete)
The concrete syntax describes the visualization of the

abstract syntax.

Semantics
The semantics of Petri Nets can be decribed by

abstract automata, consisting of
– a set of configurations
– an initial configuration
– a set of transitions between configurations

Semantics (Configurations)
The set of configurations and the initial configuration can be

defined as an extension of the syntactic metamodel,
optionally with additional constraints.

Semantics (Transitions
between Configurations)
The transitions between configurations may be defined by
methods of the concepts of the extended metamodel.

Pragmatik
Since the models shall be first-class objects at runtime,

they have to implement (at least) one interface of the
host language (here: Java).

Pragmatics
There may be several interfaces for different usages.

3.2 IMPLEMENTATION OF
MODELING LANGUAGES

Infrastructure
Given such a language definition (CLM) a corresponding

infrastructure can be built
– either by generation from the CLM,
– and/or by manual programming along the CLM.

Modeling Infrastructure
At first, a modeling infrastructure, e.g., in the form of modeling

framework must be installed. (Eclipse’s EMF is an example.)
This framework must be able to generate a language-specific

infrastructure containing metamodel-specific CRUD-
Operations to ease language-specific use of models.

Language Infrastructure
Then, for each modeling language,

a language infrastructure is to be developed,
consisting of two related APIs:
– a language-specific API
generated from the metamodel supplying all
operations for creating, manipulating and traversing
models, and
– a use-specific API
implementing additional interfaces and providing all
relevant semantic functionality.

Infrastructure
Thus, the infrastructure consists of

– the modeling framework used and
– per language
• a language-specific infrastructure, and
• a use-specific infrastructure.

Language-Specific Infrastructure
The language-specific infrastructure is (usually) generated

from the extended metamodel by the modeling framework.

Use-Specific Infrastructure
The use-specific infrastructure may be realized by

implementing the required interfaces.
Class Simula

4. CONCLUSION

Conclusion
Over at least decades, a large body of knowledge about models
in software engineering has been collected.
If a full modeling framework including
– means for language definition (from metamodeling to
semantics specification) and
– all relevant services (from editing to execution),
– based on a versatile and efficient data structure for models
was provided, an equal-right combination of code and models
in running software becomes possible.
Code is generated only once for the language.

References
Work Concerning Model-Integration:
– [Derakhshanmanesh2014MSCa]
Mahdi Derakhshanmanesh, Jürgen Ebert, Thomas Iguchi, Gregor Engels.
Model-Integrating Software Components. Models 2014.
– [Derakhshanmanesh2015MSCb]
Mahdi Derakhshanmanesh.
Model-Integrating Software Components. Springer Research. 2015.
– [Derakhshanmanesh2017MDO]
Mahdi Derakhshanmanesh, Jürgen Ebert, Marvin Grieger, Gregor Engels.
Model-Integrating Development of Software Systems. submitted for publication.
available from ebert@uni-koblenz.de.
Further Work Cited:

– [Sauer2011SDO]
Stefan Sauer.
Systematic Development of Model-based Software Engineering Methods.
Dissertation. University of Paderborn. 2015

APPENDIX: ISA: A CASE STUDY

CaseStudy: Insurance Sales App
An insurance company requires an assistive “Insurance Sales
App (ISA)” for the Android mobile platform.
Flexibility is needed wrt.:

– fee computations,
they depend on frequently changing laws and other impact
factors so the software needs to be evolved permanently
– different user roles (e.g., car or home insurance specialist),
they require different variants of ISA
– parts of the fee calculations
they may even depend on geo-locations

ISA: Screenshot (Android)

ISA: Architecture

ISA: Metamodel and Model
The IsaCarProduct1 component is driven by two integrated
models.

Mo - 21 - Ebert - Lecture Model-Integrating Software

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mo - 21 - Ebert - Lecture Model-Integrating Software

Uploaded by

Copyright:

Available Formats

From Model-Based

18.7.2014 Jürgen Ebert 1

This talk presents a Software Engineer‘s view on modeling,

18.7.2014 Jürgen Ebert 2

Main Messages of this talk:

18.7.2014 Jürgen Ebert 3

18.7.2014 Jürgen Ebert 4

18.7.2014 Jürgen Ebert 5

In software engineering, models are used to represent

Though (along the definition) code is also a model,

18.7.2014 Jürgen Ebert 6

Models are widely used since they are (usually)

18.7.2014 Jürgen Ebert 7

From a Software Engineer‘s and Tool Builder‘s point of view,

Modeling languages may be

18.7.2014 Jürgen Ebert 8

A modeling language may be described by

18.7.2014 Jürgen Ebert 10

Abstract Syntax Artifact

18.7.2014 Jürgen Ebert 11

Abstract Syntax (Model) Artifact

The use of models in a special domain, e.g., enterprise

18.7.2014 Jürgen Ebert 13

18.7.2014 Jürgen Ebert 14

18.7.2014 Jürgen Ebert 15

This idea of using models in the course of requirements

18.7.2014 Jürgen Ebert 16

First Software Models

With the advent of software engineering, the use of several

Editing was mostly done manually.

18.7.2014 Jürgen Ebert 17

First Software Models

18.7.2014 Jürgen Ebert 18

First Modeling Tools

Editing was at first done by simple drawing.

Then more and more knowledge about the syntax of the

The long walk from pictures to formal artefacts started.

18.7.2014 Jürgen Ebert 19

18.7.2014 Jürgen Ebert 20

With more and more new languages, the description of

With syntax-based editing, the basis for generating code

18.7.2014 Jürgen Ebert 21

First Crisis: (Too) Many Languages

Inspired by CASE, much work was invested to invent new

18.7.2014 Jürgen Ebert 22

Way out: Small Variety of Paradigms

18.7.2014 Jürgen Ebert 24

18.7.2014 Jürgen Ebert 25

Unification prevailed (UML)

Since only a few paradigms for modeling software seemed to

This was done by OMG on the basis of a proposal of the three

18.7.2014 Jürgen Ebert 26

MetaCASE-tools are tools meant to build CASE-tools specialized

30.1.2017 Jürgen Ebert 27

In the context of the language crisis, more theory on language

Metamodeling was pushed forward by the OMG.

18.7.2014 Jürgen Ebert 28

18.7.2014 Jürgen Ebert 29

18.7.2014 Jürgen Ebert 30

combined model views

Programs Icons Configs

18.7.2014 Jürgen Ebert 31