You are on page 1of 38

SWE 313

Software Process and Modeling


Chapter 3
Modeling Principles and Languages
Dr. Mohammed F. Alhamid • SWE 313 • Spring 2017

This is the instructor’s notes. Students has to read the required textbook to understand the covered concepts.
Outline

• General Concepts
• Metamodeling
• Model Transformation
• Types of Models
• Model-driven Architecture
• Modeling Levels
• Modeling Languages
Outline

• General Concepts
• Modeling Language
• Metamodeling
• Model Transformation
• Types of Models
• Model-driven Architecture
• Modeling Levels
Concepts

Abstraction from specific realization technologies

● Requires modeling languages, which do not hold specific concepts


of realization technologies (e.g. Java EJB)
● Some models are considered as blueprints; used to provide a
complete and detailed specification of the system
● Improved portability of software to new/changing technologies –
model once, build everywhere
● Interoperability between different technologies can be automated
(so called Technology Bridges)
Concepts

Automated code generation from abstract models

● Generating running code from a higher level model, very much like
compilers are able to produce executable binary files from source
code, Code-generators are sometimes referred to as model
compilers.
● e.g., generation of Java-APIs, XML Schemas, etc. from UML
● Requires expressive und precise models
● Increased productivity and efficiency (models stay up-to-date)
● Protects the intellectual property of the modeler
● Transforms many kinds of models to different artifacts (classes,
test cases, documentation, configuration files,..etc)
Code generation

Source: https://www.visual-paradigm.com
Concepts

Separate development of application and infrastructure

● Separation of application-code and infrastructure-code


(e.g., Application Framework)
● Increases reusability
● Flexible development cycles as well as different development
roles possible
Famous equation from Niklaus Wirth:

Algorithms + Data Structures = Programs

Models + Transformations = Software


Modeling Languages

● Tools that allow for the definition of a concrete representation of a


conceptual model
● May consist of graphical representations, textual specifications, or
both.
● They are formally defined and ask the designers to comply with their
syntax when modeling.
● Two big classes of languages can be identified:
▪ Domain-Specific Modeling Languages (DSMLs, DSLs)
Languages that are designed specifically for a certain domain or context
• DSLs have been largely used in computer science.
• Examples: HTML, Logo, VHDL, Mathematica, SQL
▪ General Purpose Modeling Languages (GPMLs, GMLs, or
GPLs):
Languages that can be applied to any sector or domain for software modeling
purposes
• The typical examples are: UML, Petri-nets, or state machines
Outline

• General Concepts
• Metamodeling
• Model Transformation
• Types of Models
• Model-driven Architecture
• Modeling Levels
• Modeling Languages
Metamodeling

▪ To represent the models Meta-metamodel «instanceOf»


themselves as “instances” of
some more abstract models.
▪ Metamodel (modeling a model) M3 Class
Another abstraction,
highlighting properties of the «instanceOf» «instanceOf»
model itself. Metamodel
▪ Used for:
▪ defining new languages
M2 Attribute Class
▪ defining new properties or
features of existing
information (metadata) «instanceOf» «instanceOf»

▪ Models: models of reality Model


▪ Metamodels: models that Video
describe models M1
▪ Meta-metamodels: recursively, + title: String
models that describe
metamodels. Real «instanceOf»
world
M0 objects
Outline

• General Concepts
• Metamodeling
• Model Transformation
• Types of Models
• Model-driven Architecture
• Modeling Levels
• Modeling Languages
Model Transformations

▪ Model Transformation:
The conversion of a model into another model

▪ Transformations are defined at the metamodel level, and then


applied at the model level, upon models that conform to those
metamodels.

▪ MDSE provides appropriate languages for defining model


transformation rules
Model Transformations

▪ Rules can be written manually from scratch by a developer, or


can be defined as a refined specification of an existing one.

▪ Alternatively, transformations themselves can be produced


automatically out of some higher level mapping rules between
models. This technique is based on two phases:
1. defining a mapping between elements of a model to
elements to another one (model mapping or model
weaving)
2. automating the generation of the actual transformation
rules through a system that receives as input the two model
definitions and the mapping
InstanceOf vs. ConformsTo

▪ Conformance is between models


▪ Instantiation is between model elements

Metamodel
class

«instanceOf» «conformsTo»

Model
object
Model Transformations
MOF and transformation setting
▪ Transformations
«conformsTo»
themselves can be
seen as models! MMM
«conformsTo» «conformsTo»
«conformsTo»

«uses» «uses»
MMa MT Language MMb
«conformsTo»
«conformsTo» «conformsTo»

Ma MT Definition Mb
«reads» «executes» «writes»
MT
Execution
Engine
Model Engineering Basic Architecture

● Overview of the main aspects considered in MDSE

Application Application domain Meta-Level


Realization Automation Modeling

Meta-
Modeling
Model modeling
language
language

Transformation / Transformation Transformation


Code generation definition language

defined using
Artifacts Platform defined by
(e.g. code) uses
Outline

• General Concepts
• Metamodeling
• Model Transformation
• Types of Models
• Model-driven Architecture
• Modeling Levels
• Modeling Languages
Types of models

▪ Static models
Focus on the static aspects of the system in terms
of managed data and of structural shape and
architecture of the system.

▪ Dynamic models
Emphasize the dynamic behavior of the system by
showing the execution.

▪ Just think about UML!


Tool Support

Drawing vs. modeling


● A drawing tool is considered a modeling tool only if it
“understands” the drawings, i.e. it does not deal with
just shapes, lines, and arrows, but understands that
they represent classes, associations,..etc
Tool Support

Drawing vs. modeling


● Modeling tools use a concrete textual syntax for
specifying models (not all models need to be graphical
models)
● Modeling, as opposed to simply drawing, allows for:
○ syntactical validation
○ model checking
○ model simulation
○ model transformations
○ model execution
(either through
code generation
or model interpretation)
○ model debugging
Outline

• General Concepts
• Metamodeling
• Model Transformation
• Types of Models
• Model-driven Architecture
• Modeling Levels
• Modeling Languages
Model-Driven Architecture (MDA)

The MDA infrastructure is based on a few core definitions:


• System
The subject of any MDA specification (program, computer
system, federation of systems)

• Problem Space (or Domain)


The context or environment of the system

• Solution Space
The spectrum of possible solutions that satisfy the requirements

• Model
Any representation of the system and/or its environment
Model-Driven Architecture (MDA)

• Architecture
The specification of the parts and connectors of the system,
and the rules for the interactions of the parts using the
connectors
• Platform
Set of subsystems and technologies that provide a coherent
set of functionalities for a specified goal
• Viewpoint
A description of a system that focuses on one or more
particular concerns
• View
A model of a system seen under a specific viewpoint
• Transformation
The conversion of a model into another model
Model-Driven Architecture (MDA)

...that’s just an overview of MDA. You will learn


more about it in:

SWE 321
Software Design and Architecture

which aims at providing a comprehensive coverage


of the MDA framework.
Outline

• General Concepts
• Metamodeling
• Model Transformation
• Types of Models
• Model-driven Architecture
• Modeling Levels
• Modeling Languages
Modeling Levels

The level of abstraction of models can vary depending on the


objectives of the models themselves:
▪ Computation-independent (CIM)
Describe context, requirements and needs at a very
abstract level, without any reference to implementation
aspects (e.g., user requirements or business
objectives)
▪ Platform-independent (PIM)
Define the behavior and structure of the systems in
terms of stored data and performed algorithms, without
any technical or technological details
▪ Platform-specific (PSM)
Define all the technological aspects in detail
CIM, PIM and PSM
Computation-independent (CIM)

Example:
the description of a business process performed
within an organization;
a firm’s invoicing process
Platform-independent (PIM)

The definition of the concept (Account), its properties and constraints to


be considered for any system implementation dealing with that concept

▪ Using the UML (optional)


▪ Abstraction of structure and behaviour of a system with the PIM
simplifies the following:
▪ Validation for correctness of the model
▪ Create implementations on different platforms
▪ Tool support during implementation
Platform-specific (PSM)

▪ Specifies how the functionality described in the PIM is realized


on a certain platform
▪ Using a UML-Profile for the selected platform, e.g. EJB-based
implementation model; the PSM description of the (Account)
concept, including all the details of the specific implementation
platform of choice (i.e. Enterprise Java Beans, EJB).
CIM – PIM – PSM Mappings

● A set of mappings
between each level
and the
subsequent one
can be defined
through model
transformations

● Typically, every
CIM can map to
different PIMs,
which in turn can
map to different
PSMs
Outline

• General Concepts
• Metamodeling
• Model Transformation
• Types of Models
• Model-driven Architecture
• Modeling Levels
• Modeling Languages
Modeling Language Anatomy

• Abstract Syntax
Describes the structure of the language, and the way the
different primitives can be combined together,
independently of any particular representation or encoding.

• Concrete Syntax
Describes specific representations of the modeling
language, covering encoding and/or visual appearance.

• Semantics
Describing the meaning of the elements defined in the
language, and the meaning of the different ways of
combining them.
Modeling Language Anatomy

● The three main ingredients of a modeling language (semantics,


abstract syntax, and concrete syntax) and their relationships.
● These three ingredients are mandatory for a modeling language,
which is not well defined if any of the three is missing or incomplete.
DSL vs. GPL

First distinction is between:


•General Purpose languages (GPL or GPML) and
•Domain Specific languages (DSL or DSML)
(Both mentioned earlier in Chapter 3)

•We take UML as an exemplary case of GPL


UML
Will be discussed in the next chapter!
References

• Model-Driven Software Engineering in Practice, by


Marco Brambilla, Jordi Cabot, Manuel Wimmer
Morgan & Claypool, 2012.

You might also like