SlideShare a Scribd company logo
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Teaching material for the book
Model-Driven Software Engineering in Practice
by Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Morgan & Claypool, USA, 2012.
www.mdse-book.com
MODEL DRIVEN
ARCHITECTURE (MDA)
Chapter #4
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Contents
§ MDA
§ UML (from a metamodeling perspective)
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Model Driven Architecture
•  The Object Management Group (OMG) has defined its
own comprehensive proposal for applying MDE practices
to system’s development:
MDA (Model-Driven Architecture)
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Four principles of MDA
•  Models must be expressed in a well-defined notation,
so as to enable effective communication and
understanding
•  Systems specifications must be organized around a set of
models and associated transformations
•  implementing mappings and relations between the models.
•  multi-layered and multi-perspective architectural framework.
•  Models must be compliant with metamodels
•  Increase acceptance, broad adoption and tool competition
for MDE
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Definitions according to MDA
•  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
reqs.
•  Model: Any representation of the system and/or its environment
•  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
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Modeling Levels
CIM, PIM, PSM
§ Computation independent (CIM): describe requirements
and needs at a very abstract level, without any reference to
implementation aspects (e.g., description of user
requirements or business objectives);
§ Platform independent (PIM): define the behavior 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.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
CIM, PIM and PSM
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
CIM
MDA Computation Independent Model (CIM)
§ E.g., business process
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
PIM
MDA Platform Independent Model (PIM)
§  Specification of
structure and behaviour
of a system, abstracted
from technologicical
details
§  Using the UML(optional)
§  Abstraction of structur 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
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
PSM
MDA Platform Specific Model (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
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
CIM – PIM – PSM mappings
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Modeling language specification
•  MDA’s core is UML, a standard general-purpose software
modeling language
Two options for specifying your languages:
•  (Domain-specific) UML Extensions can be defined through
UML Profiles
•  Full-fledged domain-specific languages (DSMLs) can be
defined by MOF
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
ADM
ADM (Architecture-Driven Modernization) is addressing the
problem of system reverse engineering
It includes several standards that help on this matter
•  The Knowledge Discovery Metamodel (KDM): An
intermediate representation for existing software systems that
defines common metadata required for deep semantic
integration of lifecycle management tools. Based on MOF and
XMI
•  The Software Measurement Metamodel (SMM): A meta-
model for representing measurement information related to
software, its operation, and its design.
•  The Abstract Syntax Tree Metamodel (ASTM): A
complementary modeling specification with respect to KDM,
ASTM supports a direct mapping of all code-level software
language statements into low-level software models.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
MDA vs. ADM – the MDRE process
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
www.mdse-book.com
MOF –
META OBJECT FACILITY
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
www.mdse-book.com
UML –
UNIFIED MODELING
LANGUAGE
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Datatypes
• UML distinguishes between the following data
types:
•  Simple data types (DataType): a type with values that
have no identity; that means two instances of a datatype
with the same attributes values are indistinguishable.
•  Primitive data types (PrimitiveType): a simple data
type without structures. UML defines the following
primitive data types:
•  Integer: (Infinite) set of integers: (...,-1,0,1,...)
•  Boolean: true, false.
•  UnlimitedNatural (Infinite) set of natural numbers plus infinite (*).
•  Enumeration types – simple data types with values
that originate from a limited set of enumeration literals.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Examples of data types
Data type keywords
Attributes Enumeration literals
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
The metamodel of data types
Property
DataT ype
0..1 *
+datatype
0..1 {subsets namespace,
subsets featuringClassifier,
subsets classi fier}
+ownedAttribute
*{ordered,
subsets attribute,
subsets ownedM ember}
Operation
0..1 *
+datatype
0..1
{subsets nam espace,
subsets redefinitionContext,
subsets featuringClassifier}
+ownedOperation
*{ordered,
subsets feature,
subsets ownedM ember}
PrimitiveType Enum eration EnumerationLiteral
0..1 *
+enumeration
0..1{subsets nam espace}
+ownedLiteral
*{ordered,
subsets ownedM ember}
InstanceSpecification
Classi fier
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Overview of Diagrams
•  There is no official UML diagram overview or diagram
grouping.
•  Although UML models and the repository underlying all
diagrams are defined in UML, the definition of diagrams
(i.e. special views of the repository) are relatively free.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Overview of Diagrams
• In UML a diagram is actually more than a
collection of notational elements.
• For example, the package diagram describes the
package symbol, the merge relationship, and so
on.
• A class diagram describes a class, the
association, and so on.
• Nevertheless, we can actually represent classes
and packages together in one diagram.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Overview of the UML diagrams
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Class vs. instance
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Basic notation for diagrams
Diagram area
Diagram header
[<Diagram type>]<Name>[<Parameter>]
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example of a use case diagram
Use case Booking use cases
Branch
employee
Book vehicle
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Stereotypes-definition
• Stereotypes are formal extensions of existing
model elements within the UML metamodel, that
is, metamodel extensions.
• The modeling element is directly influenced by
the semantics defined by the extension.
• Rather than introducing a new model element to
the metamodel, stereotypes add semantics to
an existing model element.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Multiple stereotyping
• Several stereotypes can be used to classify one
single modeling element.
• Even the visual representation of an element
can be influenced by allocating stereotypes.
• Moreover, stereotypes can be added to
attributes, operations and relationships.
• Further, stereotypes can have attributes to store
additional information.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Stereotypes Notation
•  A stereotype is placed before or above the element name
and enclosed in guillemets (<<,>>).
•  Important: not every ocurrence of this notation means
that you are looking at a stereotype. Keywords
predefined in UML are also enclosed in guillemets.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Graphical symbols
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
UML standard stereotypes
Stereotype UML element Description
<<call>> Dependency(usage) Call dependency between operation or
classes
<<create>> Dependency(usage) The source element creates instances of the
target element
<<instantiate>> Dependency(usage) The source element creates instances of the
target element
Note: This description is identical to the one
of <<create>>
<<responsability>> Dependency(usage) The source element is responsible for the
target element
<<send>> Dependency (usage) The source element is an operation and the
target element is a signal sent by that
operation
<<derive>> Abstraction The source element can, for instance, be
derived from the target element by a
calculation
<<refine>> Abstraction A refinement relationship (e.g. Between a
desing element and a pertaining analysis
element)
<<trace>> Abstraction Serves to trace of requirements
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
UML standard stereotypes
Stereotype UML element Description
<<script>> Artifact A script file (can be executed on a computer)
<<auxiliary>> Class Classes that support other classes
(<<focus>>)
<<focus>> Class Classes contain the primary logic. See
<<auxiliary>>
<<implementationClass>> Class An implementation class specially designed
for a programming language, where an
object may belong to one class only
<<metaclass>> Class A class with instances that are, in turn,
classes
<<type>> Class Types define a set of operations and
attributes, and they are generally abstract
<<utility>> Class Utility class are collections of global
variables and functions, which are grouped
into a class, where they are defined as class
attributes/operations
<<buildComponent>> Component An organizational motivated component
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
UML standard stereotypes
Stereotype UML element Description
<<implement>> Component A component that contains only
implementation, not specification
<<framework>> Package A package that contains Framework
elements
<<modelLibrary>> Package A package that contains model elements,
which are reused in other packages
<<create>> Behavioral feature A property that creates instances of the class
to which it belongs (e.g. Constructor)
<<destroy>> Behavioral feature A property that destroys instances of the
class to which it belongs (e.g. Destructor)
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Class Diagrams
•  Class Diagrams refer to this area of the metamodel:
•  Package: Classes::Kernel
•  Package: Classes::Dependencies
•  Package: Classes::Interfaces
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Class Diagrams: basic concepts
•  The basis of UML is described in the Kernel package of
the metamodel.
•  Most class models have the superclass Element and has
the ability to own other elements, shown by a composition
relationship in the metamodel.
•  That’s the only ability an element has.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
The basic UML class
Element
+/owner
+/ownedElement
{union}
*
{union}
0..1
*
0..1
There is no notation for an element because you would never
user the element construct in UML models. The class is
abstract.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Relationship
•  A relationship is an abstract concept to put elements in
relation to one another.
•  Similar to Element, there is no other property or
semantics. The properties and the semantics are added
later by abstract or concrete subclasses.
•  There is no notation for Relationship either.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
The basic Relationship class
Relationship
Element
1..*
+/relatedElement
{union}
1..* +/owner
+/ownedElement
{union}
*
{union}
0..1
*
0..1
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Supplier and client
• The Relationship concept is specialized by the
concept of a direct relationship.
• The set of related elements is divided into a set of
source and a set of target elements.
• In may relationships, one element offers
something and another element wants something.
• The former is called a supplier and the later is a
client. This is expressed in one direction.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Directed relationships
DirectedRelationship
Element
1..*
+/source
{union,
subsets relatedElement}
1..*
1..*
+/target
{union,
subsets relatedElement}
1..*
+/owner
+/ownedElement
{union}
*
{union} 0..1
*
0..1
Note that we are dealing only with abstract and rather
simple concepts.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Coments and notes
•  Comments and notes are terms often used synonymously.
•  A comment can be annotated to any UML model element.
In the metamodel, you can see that the Comment class is
directly associated with the Element base class.
•  Comment is a concrete class.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
The notation for comments
Class
Comment text
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
The basic metamodel conceptsElement
*
0..1
+/ownedElement
* {union}
+/owner
0..1 {union}
Comment
0..1 *
+owningElement
0..1{subsets owner}
+ownedCom ment
*{subsets ownedElement}
DirectedRelationship
Comment
body : String
Relationship
Element
1..*
+/target
1..*{union,
subsets relatedElement}
1..*
+/source
1..*{union,
subsets relatedElement}
*
+annotatedElement
*1..*
+/relatedElement
1..*{union}
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Namespaces
• Def.-A named element is an element that can
have a name and a defined visibility (public,
private, protected, package):
•  +=public
•  -=private
•  #=protected
•  ~=package
• The name of the element and its visibility are
optional.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
The metamodel for NamedElement
NamedElement
name : String
v isibility : Visibility Kind
/ qualif iedName : String
[0..1]
[0..1]
[0..1]
Vis ibility Kind
public
priv ate
protected
package
<<enumeration>>
Element
DirectedRelationship
[0..1]
DirectedRelationship
PackageableElement
NamedElement
ElementImport
v isibility : Visibility Kind
alias : String
1
+importedElement
1{subsets target}
Pac kageableElement
vis ibility : Vis ibility Kind...
Namespace
0..1 *
+/namespace
0..1 {union,
subsets owner}
+/ownedMember
*
{union,
subsets member,
subsets ownedElement}
*
+/m ember
*{union}
1 *
+importingNamespace
1
{subsets source,
subsets owner}
+elementImport
*
{subsets ownedElement}
*
+/importedMember
* {subsets member}
PackageImport
v isibility : Visibility Kind
1 *
+importingNamespace
1 {subsets source,
subs ets owner}
+packageImport
*{subsets ownedElement}
Pac kage
1
+importedPackage
1{subsets target}
[0..1]
We are focusing in this
section of the
metamodel
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Namespace
• A namespace is a named element that can
contain named elements.
• Within a namespace, named elements are
uniquely identified by their names.
• In addition, they have a qualified name, resulting
from nested namespaces.
• The qualified name of a named element can be
derived from the nesting of the enclosing
namespaces.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Customers
Nested namespaces
Corporate customers
Insurance
Qualified name
Customers::CorporateCustomers:Insurance
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Packageable element
•  A packageable element is a named element that can
belong directly to a package.
•  Example: an operation cannot belong to a package, bua a class
may.
•  The visibility statement is mandatory for a packageable
element.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
ElementImport
• The act of importing an element is called
ElementImport and is a relationship between a
namespace and a packageable element that
resides in another namespace.
• The referenced element can then be addressed
directly by its (unqualified) name. In addition, an
optional alias name can be specified.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
PackageImport
•  The act of importing a package is called PackageImport;
it is semantically equivalent to the import of a single
element from that package.
•  We cannot specify an alias name here.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
The metamodel for NamedElement
NamedElement
name : String
v isibility : Visibility Kind
/ qualif iedName : String
[0..1]
[0..1]
[0..1]
Vis ibility Kind
public
priv ate
protected
package
<<enumeration>>
Element
DirectedRelationship
[0..1]
DirectedRelationship
PackageableElement
NamedElement
ElementImport
v isibility : Visibility Kind
alias : String
1
+importedElement
1{subsets target}
Pac kageableElement
vis ibility : Vis ibility Kind...
Namespace
0..1 *
+/namespace
0..1 {union,
subsets owner}
+/ownedMember
*
{union,
subsets member,
subsets ownedElement}
*
+/m ember
*{union}
1 *
+importingNamespace
1
{subsets source,
subsets owner}
+elementImport
*
{subsets ownedElement}
*
+/importedMember
* {subsets member}
PackageImport
v isibility : Visibility Kind
1 *
+importingNamespace
1 {subsets source,
subs ets owner}
+packageImport
*{subsets ownedElement}
Pac kage
1
+importedPackage
1{subsets target}
[0..1]
We are focusing in this
section of the
metamodel
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example of element and
package import relationships
<<import>>
<<import>>
<<access>>
<<access>>
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
<<access>> and <<import>>
• <<import>>: The visibility is public; for example,
the postal address for Order. The public import is
a transitive relationship: if A imports B and B
imports C, then A is indirectly importing C too.
• <<access>>: The visibility is private, not public:
Customer is visible in Order but not in Billing. The
private import is not transitive.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Typed elements
•  A typed element is a named element that can have a
type.
•  Ex.- Attributes and parameteres.
•  A type specifies a set of values for a typed element.
•  Ex.- Symple data types and classes are types.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example – typed element & type
Typed element Type
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Typed elements metamodel
Type and typed element are abstract classes.
They have no properties
NamedElement
TypeTypedElement
0..1
+type
0..1
PackageableElement
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Multiplicities
•  A multiplicity element is the definition of an interval of
positive integers to specify allowable cardinalities.
•  A cardinality is a concrete number of elements in a set.
•  A multiplicity element is often simply called multiplicity;
the two terms are synonymous.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example Multipicity & Cardinality
Customer Bookings
**
+bookings
Class model
:Kunde
r2:Bookings
r2:Bookings
r2:Bookings
Object model
Multiplicity=0..*
Cardinality=3
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Multiplicities
•  The notation for multiplicity is either a single number or a
value range.
•  A value range is written by stating the minimum and
maximum values, separated by two dots (e.g. 1..5).
•  In addtion, you can use the wildcard character * to specify
an arbitrary number of elements.
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Examples of multiplicities
• 0..1
• 1 (shortcut for 1..1)
• * (shortcut for 0..*)
• 1..*
• 5..3 (Invalid!)
• -1..0 (Invalid! All values must be positive)
• 3+5..7+1 (Generally meaningles, but valid; the
lower or upper value, respectively is defined by a
value specification).
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
The multiplicity metamodel
Element
ValueSpecification
MultiplicityElement
isOrdered : Boolean = false
isUnique : Boolean = true
/ upper : UnlimitedNatural
/ lower : Integer
0..1
0..1
+upperValue
0..1{subsets ownedElement}
+owningUpper
0..1
{subsets owner}
0..10..1
+lowerValue
0..1{subsets ownedElement}
+owningLower
0..1
{subsets owner}
[0..1]
[0..1]
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Checklist: multiplicities
1.  What value range is described by a multiplicity?
2.  What is the difference between multiplicity and
cardinality?
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Value specification
•  Def.- A value specification indicates one or several
values in a model.
•  Semantics.- Examples for value specifications include
simple, mathematical expressions, such as 4+2, and
expressions with values from the object model,
Integer::MAX_INT-1
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Value specification-semantics
•  In addition, there are language-dependent expressions
defined by a language statement and the pertaining
expression in that language (opaque expression), such
OCL or Java expression (the language statement can be
omitted if the language is implicity defined by the
expression or context).
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
The metamodel and the composite
pattern
•  The metamodel is based on the composite pattern:
LeafComposite
Component
*
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Example
:Expression
symbol=“+”
op1:LiteralInteger
value=1
op2:LiteralInteger
value=1
operand
operand
Object Model for
1+1
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
The metamodel for value specifications
OpaqueExpression
body [1..* ] : String {ordered}
language [0..*] : String {ordered}
LiteralSpecification
LiteralBoolean
v alue : Boolean
LiteralInteger
v alue : Integer
LiteralString
v alue : String
LiteralUnlimitedNatural
v alue : U nlimit edNat ural
LiteralNull
InstanceValue InstanceSpecif ication
1
+instance
1
ValueSpecification
Expres sion
sy m bol : String
*
0..1
+operand
*{ordered, subsets ownedElement}
+expression
0..1
{subsets owner}
TypedElement PackageableElement
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
www.mdse-book.com
UML EXAMPLES
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Class diagram
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Component Diagram
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Activity diagram
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
State Diagram
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Sequence vs. Collaboration
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
UML Extensibility: profiles
Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Model-Driven Software Engineering In Practice. Morgan & Claypool 2012.
Teaching material for the book
Model-Driven Software Engineering in Practice
by Marco Brambilla, Jordi Cabot, Manuel Wimmer.
Morgan & Claypool, USA, 2012.
www.mdse-book.com
MODEL-DRIVEN SOFTWARE
ENGINEERING IN PRACTICE
Marco Brambilla,
Jordi Cabot,
Manuel Wimmer.
Morgan & Claypool, USA, 2012.
www.mdse-book.com
www.morganclaypool.com
or buy it at: www.amazon.com

More Related Content

What's hot

Web technologies: Model Driven Engineering
Web technologies: Model Driven EngineeringWeb technologies: Model Driven Engineering
Web technologies: Model Driven Engineering
Piero Fraternali
 
5 - Architetture Software - Metamodelling and the Model Driven Architecture
5 - Architetture Software - Metamodelling and the Model Driven Architecture5 - Architetture Software - Metamodelling and the Model Driven Architecture
5 - Architetture Software - Metamodelling and the Model Driven Architecture
Majong DevJfu
 
Software Quality Attributes
Software Quality AttributesSoftware Quality Attributes
Software Quality Attributes
Hayim Makabee
 
6 - Architetture Software - Model transformation
6 - Architetture Software - Model transformation6 - Architetture Software - Model transformation
6 - Architetture Software - Model transformation
Majong DevJfu
 

What's hot (20)

Introduction to MDA
Introduction to MDAIntroduction to MDA
Introduction to MDA
 
ATL tutorial - EclipseCon 2009
ATL tutorial - EclipseCon 2009 ATL tutorial - EclipseCon 2009
ATL tutorial - EclipseCon 2009
 
Model driven architecture
Model driven architectureModel driven architecture
Model driven architecture
 
Web technologies: Model Driven Engineering
Web technologies: Model Driven EngineeringWeb technologies: Model Driven Engineering
Web technologies: Model Driven Engineering
 
Introduction to Software Engineering
Introduction to Software EngineeringIntroduction to Software Engineering
Introduction to Software Engineering
 
Spm
Spm Spm
Spm
 
MDA
MDAMDA
MDA
 
Feature Driven Development
Feature Driven DevelopmentFeature Driven Development
Feature Driven Development
 
Design Patterns (Examples in .NET)
Design Patterns (Examples in .NET)Design Patterns (Examples in .NET)
Design Patterns (Examples in .NET)
 
ATL tutorial - EclipseCon 2008
ATL tutorial - EclipseCon 2008ATL tutorial - EclipseCon 2008
ATL tutorial - EclipseCon 2008
 
OO Metrics
OO MetricsOO Metrics
OO Metrics
 
Software development process models
Software development process modelsSoftware development process models
Software development process models
 
Design patterns
Design patternsDesign patterns
Design patterns
 
5 - Architetture Software - Metamodelling and the Model Driven Architecture
5 - Architetture Software - Metamodelling and the Model Driven Architecture5 - Architetture Software - Metamodelling and the Model Driven Architecture
5 - Architetture Software - Metamodelling and the Model Driven Architecture
 
Software Quality Attributes
Software Quality AttributesSoftware Quality Attributes
Software Quality Attributes
 
Slides chapters 26-27
Slides chapters 26-27Slides chapters 26-27
Slides chapters 26-27
 
6 - Architetture Software - Model transformation
6 - Architetture Software - Model transformation6 - Architetture Software - Model transformation
6 - Architetture Software - Model transformation
 
Pressman ch-1-software
Pressman ch-1-softwarePressman ch-1-software
Pressman ch-1-software
 
1.sdlc
1.sdlc1.sdlc
1.sdlc
 
state modeling In UML
state modeling In UMLstate modeling In UML
state modeling In UML
 

Similar to Model-Driven Software Engineering in Practice - Chapter 4 - Model-Driven Architecture

Model-Driven Software Engineering in Practice - Chapter 10 - Managing models
Model-Driven Software Engineering in Practice - Chapter 10 - Managing modelsModel-Driven Software Engineering in Practice - Chapter 10 - Managing models
Model-Driven Software Engineering in Practice - Chapter 10 - Managing models
Jordi Cabot
 
Trasnformation Design Patterns - Sandeep Katoch
Trasnformation Design Patterns - Sandeep KatochTrasnformation Design Patterns - Sandeep Katoch
Trasnformation Design Patterns - Sandeep Katoch
Roopa Nadkarni
 
2 trasnformation design_patterns-sandeep_katoch
2 trasnformation design_patterns-sandeep_katoch2 trasnformation design_patterns-sandeep_katoch
2 trasnformation design_patterns-sandeep_katoch
IBM
 
CS587 Project - Raychaudhury,Shaalmali
CS587 Project - Raychaudhury,ShaalmaliCS587 Project - Raychaudhury,Shaalmali
CS587 Project - Raychaudhury,Shaalmali
sagar.247
 
4 agile modeldevelopement-danielleroux
4 agile modeldevelopement-danielleroux4 agile modeldevelopement-danielleroux
4 agile modeldevelopement-danielleroux
IBM
 
Agile Model Developement- Daniel Leroux
Agile Model Developement-  Daniel LerouxAgile Model Developement-  Daniel Leroux
Agile Model Developement- Daniel Leroux
Roopa Nadkarni
 
Mda introduction and common research problems
Mda   introduction and common research problemsMda   introduction and common research problems
Mda introduction and common research problems
Lai Ha
 

Similar to Model-Driven Software Engineering in Practice - Chapter 4 - Model-Driven Architecture (20)

Model-Driven Software Engineering in Practice - Chapter 10 - Managing models
Model-Driven Software Engineering in Practice - Chapter 10 - Managing modelsModel-Driven Software Engineering in Practice - Chapter 10 - Managing models
Model-Driven Software Engineering in Practice - Chapter 10 - Managing models
 
Sig A&D - MDA
Sig A&D - MDASig A&D - MDA
Sig A&D - MDA
 
MDD and modeling tools research
MDD and modeling tools researchMDD and modeling tools research
MDD and modeling tools research
 
System designing approaches
System designing approachesSystem designing approaches
System designing approaches
 
Trasnformation Design Patterns - Sandeep Katoch
Trasnformation Design Patterns - Sandeep KatochTrasnformation Design Patterns - Sandeep Katoch
Trasnformation Design Patterns - Sandeep Katoch
 
2 trasnformation design_patterns-sandeep_katoch
2 trasnformation design_patterns-sandeep_katoch2 trasnformation design_patterns-sandeep_katoch
2 trasnformation design_patterns-sandeep_katoch
 
Using MDE for the Formal Verification of Embedded Systems Modeled by UML Se...
Using MDE for the Formal Verification of Embedded  Systems Modeled by UML Se...Using MDE for the Formal Verification of Embedded  Systems Modeled by UML Se...
Using MDE for the Formal Verification of Embedded Systems Modeled by UML Se...
 
Semantic Approach to Verifying Activity Diagrams with a Domain Specific Language
Semantic Approach to Verifying Activity Diagrams with a Domain Specific LanguageSemantic Approach to Verifying Activity Diagrams with a Domain Specific Language
Semantic Approach to Verifying Activity Diagrams with a Domain Specific Language
 
CS587 Project - Raychaudhury,Shaalmali
CS587 Project - Raychaudhury,ShaalmaliCS587 Project - Raychaudhury,Shaalmali
CS587 Project - Raychaudhury,Shaalmali
 
4 agile modeldevelopement-danielleroux
4 agile modeldevelopement-danielleroux4 agile modeldevelopement-danielleroux
4 agile modeldevelopement-danielleroux
 
Agile Model Developement- Daniel Leroux
Agile Model Developement-  Daniel LerouxAgile Model Developement-  Daniel Leroux
Agile Model Developement- Daniel Leroux
 
Unit-1 OOAD Introduction.pptx
Unit-1 OOAD Introduction.pptxUnit-1 OOAD Introduction.pptx
Unit-1 OOAD Introduction.pptx
 
Mda introduction and common research problems
Mda   introduction and common research problemsMda   introduction and common research problems
Mda introduction and common research problems
 
Final Jspring2009 Mda Slimmer Ontwikkelen Van Java Ee Applicaties
Final Jspring2009 Mda Slimmer Ontwikkelen Van Java Ee ApplicatiesFinal Jspring2009 Mda Slimmer Ontwikkelen Van Java Ee Applicaties
Final Jspring2009 Mda Slimmer Ontwikkelen Van Java Ee Applicaties
 
OODPunit1.pdf
OODPunit1.pdfOODPunit1.pdf
OODPunit1.pdf
 
Agile and Modeling / MDE : friends or foes? (Agile Tour Nantes 2010)
Agile and Modeling / MDE : friends or foes? (Agile Tour  Nantes 2010)Agile and Modeling / MDE : friends or foes? (Agile Tour  Nantes 2010)
Agile and Modeling / MDE : friends or foes? (Agile Tour Nantes 2010)
 
Applying sys ml_with_magicdraw
Applying sys ml_with_magicdrawApplying sys ml_with_magicdraw
Applying sys ml_with_magicdraw
 
BSSML16 L10. Summary Day 2 Sessions
BSSML16 L10. Summary Day 2 SessionsBSSML16 L10. Summary Day 2 Sessions
BSSML16 L10. Summary Day 2 Sessions
 
Different Proposed Models to Mapping MDA to RUP
Different Proposed Models to Mapping MDA to RUPDifferent Proposed Models to Mapping MDA to RUP
Different Proposed Models to Mapping MDA to RUP
 
Object Oriented Database
Object Oriented DatabaseObject Oriented Database
Object Oriented Database
 

More from Jordi Cabot

More from Jordi Cabot (20)

AI and Software consultants: friends or foes?
AI and Software consultants: friends or foes?AI and Software consultants: friends or foes?
AI and Software consultants: friends or foes?
 
Model-driven engineering for Industrial IoT architectures
Model-driven engineering for Industrial IoT architecturesModel-driven engineering for Industrial IoT architectures
Model-driven engineering for Industrial IoT architectures
 
Smart modeling of smart software
Smart modeling of smart softwareSmart modeling of smart software
Smart modeling of smart software
 
Modeling should be an independent scientific discipline
Modeling should be an independent scientific disciplineModeling should be an independent scientific discipline
Modeling should be an independent scientific discipline
 
¿Quién va a desarrollar las Apps del futuro? (aviso: no serán los programador...
¿Quién va a desarrollar las Apps del futuro? (aviso: no serán los programador...¿Quién va a desarrollar las Apps del futuro? (aviso: no serán los programador...
¿Quién va a desarrollar las Apps del futuro? (aviso: no serán los programador...
 
How to sustain a tool building community-driven effort
How to sustain a tool building community-driven effortHow to sustain a tool building community-driven effort
How to sustain a tool building community-driven effort
 
All Researchers Should Become Entrepreneurs
All Researchers Should Become EntrepreneursAll Researchers Should Become Entrepreneurs
All Researchers Should Become Entrepreneurs
 
The Software Challenges of Building Smart Chatbots - ICSE'21
The Software Challenges of Building Smart Chatbots - ICSE'21The Software Challenges of Building Smart Chatbots - ICSE'21
The Software Challenges of Building Smart Chatbots - ICSE'21
 
Low-code vs Model-Driven Engineering
Low-code vs Model-Driven EngineeringLow-code vs Model-Driven Engineering
Low-code vs Model-Driven Engineering
 
Lessons learned from building a commercial bot development platform
Lessons learned from building a commercial bot development platformLessons learned from building a commercial bot development platform
Lessons learned from building a commercial bot development platform
 
Future Trends on Software and Systems Modeling
Future Trends on Software and Systems ModelingFuture Trends on Software and Systems Modeling
Future Trends on Software and Systems Modeling
 
Ingeniería del Software dirigida por modelos -Versión para incrédulos
Ingeniería del Software dirigida por modelos -Versión para incrédulosIngeniería del Software dirigida por modelos -Versión para incrédulos
Ingeniería del Software dirigida por modelos -Versión para incrédulos
 
Chatbot Tutorial - Create your first bot with Xatkit
Chatbot Tutorial - Create your first bot with Xatkit Chatbot Tutorial - Create your first bot with Xatkit
Chatbot Tutorial - Create your first bot with Xatkit
 
Création facile de chatbots - Créez votre chatbot en 20 minutes avec une plat...
Création facile de chatbots - Créez votre chatbot en 20 minutes avec une plat...Création facile de chatbots - Créez votre chatbot en 20 minutes avec une plat...
Création facile de chatbots - Créez votre chatbot en 20 minutes avec une plat...
 
An LSTM-Based Neural Network Architecture for Model Transformations
An LSTM-Based Neural Network Architecture for Model TransformationsAn LSTM-Based Neural Network Architecture for Model Transformations
An LSTM-Based Neural Network Architecture for Model Transformations
 
WAPIml: Towards a Modeling Infrastructure for Web APIs
WAPIml: Towards a Modeling Infrastructure for Web APIsWAPIml: Towards a Modeling Infrastructure for Web APIs
WAPIml: Towards a Modeling Infrastructure for Web APIs
 
Is there a future for Model Transformation Languages?
Is there a future for Model Transformation Languages?Is there a future for Model Transformation Languages?
Is there a future for Model Transformation Languages?
 
Software Modeling and Artificial Intelligence: friends or foes?
Software Modeling and Artificial Intelligence: friends or foes?Software Modeling and Artificial Intelligence: friends or foes?
Software Modeling and Artificial Intelligence: friends or foes?
 
Temporal EMF: A temporal metamodeling platform
Temporal EMF: A temporal metamodeling platformTemporal EMF: A temporal metamodeling platform
Temporal EMF: A temporal metamodeling platform
 
UMLtoNoSQL : From UML domain models to NoSQL Databases
UMLtoNoSQL : From UML domain models to NoSQL DatabasesUMLtoNoSQL : From UML domain models to NoSQL Databases
UMLtoNoSQL : From UML domain models to NoSQL Databases
 

Recently uploaded

AI/ML Infra Meetup | Improve Speed and GPU Utilization for Model Training & S...
AI/ML Infra Meetup | Improve Speed and GPU Utilization for Model Training & S...AI/ML Infra Meetup | Improve Speed and GPU Utilization for Model Training & S...
AI/ML Infra Meetup | Improve Speed and GPU Utilization for Model Training & S...
Alluxio, Inc.
 

Recently uploaded (20)

10 Essential Software Testing Tools You Need to Know About.pdf
10 Essential Software Testing Tools You Need to Know About.pdf10 Essential Software Testing Tools You Need to Know About.pdf
10 Essential Software Testing Tools You Need to Know About.pdf
 
AI/ML Infra Meetup | Reducing Prefill for LLM Serving in RAG
AI/ML Infra Meetup | Reducing Prefill for LLM Serving in RAGAI/ML Infra Meetup | Reducing Prefill for LLM Serving in RAG
AI/ML Infra Meetup | Reducing Prefill for LLM Serving in RAG
 
De mooiste recreatieve routes ontdekken met RouteYou en FME
De mooiste recreatieve routes ontdekken met RouteYou en FMEDe mooiste recreatieve routes ontdekken met RouteYou en FME
De mooiste recreatieve routes ontdekken met RouteYou en FME
 
Facemoji Keyboard released its 2023 State of Emoji report, outlining the most...
Facemoji Keyboard released its 2023 State of Emoji report, outlining the most...Facemoji Keyboard released its 2023 State of Emoji report, outlining the most...
Facemoji Keyboard released its 2023 State of Emoji report, outlining the most...
 
GraphAware - Transforming policing with graph-based intelligence analysis
GraphAware - Transforming policing with graph-based intelligence analysisGraphAware - Transforming policing with graph-based intelligence analysis
GraphAware - Transforming policing with graph-based intelligence analysis
 
KLARNA - Language Models and Knowledge Graphs: A Systems Approach
KLARNA -  Language Models and Knowledge Graphs: A Systems ApproachKLARNA -  Language Models and Knowledge Graphs: A Systems Approach
KLARNA - Language Models and Knowledge Graphs: A Systems Approach
 
AI/ML Infra Meetup | ML explainability in Michelangelo
AI/ML Infra Meetup | ML explainability in MichelangeloAI/ML Infra Meetup | ML explainability in Michelangelo
AI/ML Infra Meetup | ML explainability in Michelangelo
 
Paketo Buildpacks : la meilleure façon de construire des images OCI? DevopsDa...
Paketo Buildpacks : la meilleure façon de construire des images OCI? DevopsDa...Paketo Buildpacks : la meilleure façon de construire des images OCI? DevopsDa...
Paketo Buildpacks : la meilleure façon de construire des images OCI? DevopsDa...
 
GraphSummit Stockholm - Neo4j - Knowledge Graphs and Product Updates
GraphSummit Stockholm - Neo4j - Knowledge Graphs and Product UpdatesGraphSummit Stockholm - Neo4j - Knowledge Graphs and Product Updates
GraphSummit Stockholm - Neo4j - Knowledge Graphs and Product Updates
 
A Comprehensive Appium Guide for Hybrid App Automation Testing.pdf
A Comprehensive Appium Guide for Hybrid App Automation Testing.pdfA Comprehensive Appium Guide for Hybrid App Automation Testing.pdf
A Comprehensive Appium Guide for Hybrid App Automation Testing.pdf
 
AI/ML Infra Meetup | Perspective on Deep Learning Framework
AI/ML Infra Meetup | Perspective on Deep Learning FrameworkAI/ML Infra Meetup | Perspective on Deep Learning Framework
AI/ML Infra Meetup | Perspective on Deep Learning Framework
 
Advanced Flow Concepts Every Developer Should Know
Advanced Flow Concepts Every Developer Should KnowAdvanced Flow Concepts Every Developer Should Know
Advanced Flow Concepts Every Developer Should Know
 
WSO2Con2024 - WSO2's IAM Vision: Identity-Led Digital Transformation
WSO2Con2024 - WSO2's IAM Vision: Identity-Led Digital TransformationWSO2Con2024 - WSO2's IAM Vision: Identity-Led Digital Transformation
WSO2Con2024 - WSO2's IAM Vision: Identity-Led Digital Transformation
 
iGaming Platform & Lottery Solutions by Skilrock
iGaming Platform & Lottery Solutions by SkilrockiGaming Platform & Lottery Solutions by Skilrock
iGaming Platform & Lottery Solutions by Skilrock
 
AI/ML Infra Meetup | Improve Speed and GPU Utilization for Model Training & S...
AI/ML Infra Meetup | Improve Speed and GPU Utilization for Model Training & S...AI/ML Infra Meetup | Improve Speed and GPU Utilization for Model Training & S...
AI/ML Infra Meetup | Improve Speed and GPU Utilization for Model Training & S...
 
Workforce Efficiency with Employee Time Tracking Software.pdf
Workforce Efficiency with Employee Time Tracking Software.pdfWorkforce Efficiency with Employee Time Tracking Software.pdf
Workforce Efficiency with Employee Time Tracking Software.pdf
 
Studiovity film pre-production and screenwriting software
Studiovity film pre-production and screenwriting softwareStudiovity film pre-production and screenwriting software
Studiovity film pre-production and screenwriting software
 
TROUBLESHOOTING 9 TYPES OF OUTOFMEMORYERROR
TROUBLESHOOTING 9 TYPES OF OUTOFMEMORYERRORTROUBLESHOOTING 9 TYPES OF OUTOFMEMORYERROR
TROUBLESHOOTING 9 TYPES OF OUTOFMEMORYERROR
 
INGKA DIGITAL: Linked Metadata by Design
INGKA DIGITAL: Linked Metadata by DesignINGKA DIGITAL: Linked Metadata by Design
INGKA DIGITAL: Linked Metadata by Design
 
Tree in the Forest - Managing Details in BDD Scenarios (live2test 2024)
Tree in the Forest - Managing Details in BDD Scenarios (live2test 2024)Tree in the Forest - Managing Details in BDD Scenarios (live2test 2024)
Tree in the Forest - Managing Details in BDD Scenarios (live2test 2024)
 

Model-Driven Software Engineering in Practice - Chapter 4 - Model-Driven Architecture

  • 1. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Teaching material for the book Model-Driven Software Engineering in Practice by Marco Brambilla, Jordi Cabot, Manuel Wimmer. Morgan & Claypool, USA, 2012. www.mdse-book.com MODEL DRIVEN ARCHITECTURE (MDA) Chapter #4
  • 2. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Contents § MDA § UML (from a metamodeling perspective)
  • 3. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Model Driven Architecture •  The Object Management Group (OMG) has defined its own comprehensive proposal for applying MDE practices to system’s development: MDA (Model-Driven Architecture)
  • 4. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Four principles of MDA •  Models must be expressed in a well-defined notation, so as to enable effective communication and understanding •  Systems specifications must be organized around a set of models and associated transformations •  implementing mappings and relations between the models. •  multi-layered and multi-perspective architectural framework. •  Models must be compliant with metamodels •  Increase acceptance, broad adoption and tool competition for MDE
  • 5. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Definitions according to MDA •  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 reqs. •  Model: Any representation of the system and/or its environment •  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
  • 6. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Modeling Levels CIM, PIM, PSM § Computation independent (CIM): describe requirements and needs at a very abstract level, without any reference to implementation aspects (e.g., description of user requirements or business objectives); § Platform independent (PIM): define the behavior 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.
  • 7. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. CIM, PIM and PSM
  • 8. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. CIM MDA Computation Independent Model (CIM) § E.g., business process
  • 9. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. PIM MDA Platform Independent Model (PIM) §  Specification of structure and behaviour of a system, abstracted from technologicical details §  Using the UML(optional) §  Abstraction of structur 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
  • 10. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. PSM MDA Platform Specific Model (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
  • 11. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. CIM – PIM – PSM mappings
  • 12. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Modeling language specification •  MDA’s core is UML, a standard general-purpose software modeling language Two options for specifying your languages: •  (Domain-specific) UML Extensions can be defined through UML Profiles •  Full-fledged domain-specific languages (DSMLs) can be defined by MOF
  • 13. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. ADM ADM (Architecture-Driven Modernization) is addressing the problem of system reverse engineering It includes several standards that help on this matter •  The Knowledge Discovery Metamodel (KDM): An intermediate representation for existing software systems that defines common metadata required for deep semantic integration of lifecycle management tools. Based on MOF and XMI •  The Software Measurement Metamodel (SMM): A meta- model for representing measurement information related to software, its operation, and its design. •  The Abstract Syntax Tree Metamodel (ASTM): A complementary modeling specification with respect to KDM, ASTM supports a direct mapping of all code-level software language statements into low-level software models.
  • 14. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. MDA vs. ADM – the MDRE process
  • 15. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. www.mdse-book.com MOF – META OBJECT FACILITY
  • 16. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. www.mdse-book.com UML – UNIFIED MODELING LANGUAGE
  • 17. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Datatypes • UML distinguishes between the following data types: •  Simple data types (DataType): a type with values that have no identity; that means two instances of a datatype with the same attributes values are indistinguishable. •  Primitive data types (PrimitiveType): a simple data type without structures. UML defines the following primitive data types: •  Integer: (Infinite) set of integers: (...,-1,0,1,...) •  Boolean: true, false. •  UnlimitedNatural (Infinite) set of natural numbers plus infinite (*). •  Enumeration types – simple data types with values that originate from a limited set of enumeration literals.
  • 18. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Examples of data types Data type keywords Attributes Enumeration literals
  • 19. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. The metamodel of data types Property DataT ype 0..1 * +datatype 0..1 {subsets namespace, subsets featuringClassifier, subsets classi fier} +ownedAttribute *{ordered, subsets attribute, subsets ownedM ember} Operation 0..1 * +datatype 0..1 {subsets nam espace, subsets redefinitionContext, subsets featuringClassifier} +ownedOperation *{ordered, subsets feature, subsets ownedM ember} PrimitiveType Enum eration EnumerationLiteral 0..1 * +enumeration 0..1{subsets nam espace} +ownedLiteral *{ordered, subsets ownedM ember} InstanceSpecification Classi fier
  • 20. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Overview of Diagrams •  There is no official UML diagram overview or diagram grouping. •  Although UML models and the repository underlying all diagrams are defined in UML, the definition of diagrams (i.e. special views of the repository) are relatively free.
  • 21. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Overview of Diagrams • In UML a diagram is actually more than a collection of notational elements. • For example, the package diagram describes the package symbol, the merge relationship, and so on. • A class diagram describes a class, the association, and so on. • Nevertheless, we can actually represent classes and packages together in one diagram.
  • 22. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Overview of the UML diagrams
  • 23. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Class vs. instance
  • 24. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Basic notation for diagrams Diagram area Diagram header [<Diagram type>]<Name>[<Parameter>]
  • 25. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Example of a use case diagram Use case Booking use cases Branch employee Book vehicle
  • 26. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Stereotypes-definition • Stereotypes are formal extensions of existing model elements within the UML metamodel, that is, metamodel extensions. • The modeling element is directly influenced by the semantics defined by the extension. • Rather than introducing a new model element to the metamodel, stereotypes add semantics to an existing model element.
  • 27. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Multiple stereotyping • Several stereotypes can be used to classify one single modeling element. • Even the visual representation of an element can be influenced by allocating stereotypes. • Moreover, stereotypes can be added to attributes, operations and relationships. • Further, stereotypes can have attributes to store additional information.
  • 28. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Stereotypes Notation •  A stereotype is placed before or above the element name and enclosed in guillemets (<<,>>). •  Important: not every ocurrence of this notation means that you are looking at a stereotype. Keywords predefined in UML are also enclosed in guillemets.
  • 29. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Graphical symbols
  • 30. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. UML standard stereotypes Stereotype UML element Description <<call>> Dependency(usage) Call dependency between operation or classes <<create>> Dependency(usage) The source element creates instances of the target element <<instantiate>> Dependency(usage) The source element creates instances of the target element Note: This description is identical to the one of <<create>> <<responsability>> Dependency(usage) The source element is responsible for the target element <<send>> Dependency (usage) The source element is an operation and the target element is a signal sent by that operation <<derive>> Abstraction The source element can, for instance, be derived from the target element by a calculation <<refine>> Abstraction A refinement relationship (e.g. Between a desing element and a pertaining analysis element) <<trace>> Abstraction Serves to trace of requirements
  • 31. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. UML standard stereotypes Stereotype UML element Description <<script>> Artifact A script file (can be executed on a computer) <<auxiliary>> Class Classes that support other classes (<<focus>>) <<focus>> Class Classes contain the primary logic. See <<auxiliary>> <<implementationClass>> Class An implementation class specially designed for a programming language, where an object may belong to one class only <<metaclass>> Class A class with instances that are, in turn, classes <<type>> Class Types define a set of operations and attributes, and they are generally abstract <<utility>> Class Utility class are collections of global variables and functions, which are grouped into a class, where they are defined as class attributes/operations <<buildComponent>> Component An organizational motivated component
  • 32. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. UML standard stereotypes Stereotype UML element Description <<implement>> Component A component that contains only implementation, not specification <<framework>> Package A package that contains Framework elements <<modelLibrary>> Package A package that contains model elements, which are reused in other packages <<create>> Behavioral feature A property that creates instances of the class to which it belongs (e.g. Constructor) <<destroy>> Behavioral feature A property that destroys instances of the class to which it belongs (e.g. Destructor)
  • 33. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Class Diagrams •  Class Diagrams refer to this area of the metamodel: •  Package: Classes::Kernel •  Package: Classes::Dependencies •  Package: Classes::Interfaces
  • 34. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Class Diagrams: basic concepts •  The basis of UML is described in the Kernel package of the metamodel. •  Most class models have the superclass Element and has the ability to own other elements, shown by a composition relationship in the metamodel. •  That’s the only ability an element has.
  • 35. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. The basic UML class Element +/owner +/ownedElement {union} * {union} 0..1 * 0..1 There is no notation for an element because you would never user the element construct in UML models. The class is abstract.
  • 36. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Relationship •  A relationship is an abstract concept to put elements in relation to one another. •  Similar to Element, there is no other property or semantics. The properties and the semantics are added later by abstract or concrete subclasses. •  There is no notation for Relationship either.
  • 37. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. The basic Relationship class Relationship Element 1..* +/relatedElement {union} 1..* +/owner +/ownedElement {union} * {union} 0..1 * 0..1
  • 38. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Supplier and client • The Relationship concept is specialized by the concept of a direct relationship. • The set of related elements is divided into a set of source and a set of target elements. • In may relationships, one element offers something and another element wants something. • The former is called a supplier and the later is a client. This is expressed in one direction.
  • 39. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Directed relationships DirectedRelationship Element 1..* +/source {union, subsets relatedElement} 1..* 1..* +/target {union, subsets relatedElement} 1..* +/owner +/ownedElement {union} * {union} 0..1 * 0..1 Note that we are dealing only with abstract and rather simple concepts.
  • 40. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Coments and notes •  Comments and notes are terms often used synonymously. •  A comment can be annotated to any UML model element. In the metamodel, you can see that the Comment class is directly associated with the Element base class. •  Comment is a concrete class.
  • 41. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. The notation for comments Class Comment text
  • 42. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. The basic metamodel conceptsElement * 0..1 +/ownedElement * {union} +/owner 0..1 {union} Comment 0..1 * +owningElement 0..1{subsets owner} +ownedCom ment *{subsets ownedElement} DirectedRelationship Comment body : String Relationship Element 1..* +/target 1..*{union, subsets relatedElement} 1..* +/source 1..*{union, subsets relatedElement} * +annotatedElement *1..* +/relatedElement 1..*{union}
  • 43. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Namespaces • Def.-A named element is an element that can have a name and a defined visibility (public, private, protected, package): •  +=public •  -=private •  #=protected •  ~=package • The name of the element and its visibility are optional.
  • 44. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. The metamodel for NamedElement NamedElement name : String v isibility : Visibility Kind / qualif iedName : String [0..1] [0..1] [0..1] Vis ibility Kind public priv ate protected package <<enumeration>> Element DirectedRelationship [0..1] DirectedRelationship PackageableElement NamedElement ElementImport v isibility : Visibility Kind alias : String 1 +importedElement 1{subsets target} Pac kageableElement vis ibility : Vis ibility Kind... Namespace 0..1 * +/namespace 0..1 {union, subsets owner} +/ownedMember * {union, subsets member, subsets ownedElement} * +/m ember *{union} 1 * +importingNamespace 1 {subsets source, subsets owner} +elementImport * {subsets ownedElement} * +/importedMember * {subsets member} PackageImport v isibility : Visibility Kind 1 * +importingNamespace 1 {subsets source, subs ets owner} +packageImport *{subsets ownedElement} Pac kage 1 +importedPackage 1{subsets target} [0..1] We are focusing in this section of the metamodel
  • 45. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Namespace • A namespace is a named element that can contain named elements. • Within a namespace, named elements are uniquely identified by their names. • In addition, they have a qualified name, resulting from nested namespaces. • The qualified name of a named element can be derived from the nesting of the enclosing namespaces.
  • 46. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Customers Nested namespaces Corporate customers Insurance Qualified name Customers::CorporateCustomers:Insurance
  • 47. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Packageable element •  A packageable element is a named element that can belong directly to a package. •  Example: an operation cannot belong to a package, bua a class may. •  The visibility statement is mandatory for a packageable element.
  • 48. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. ElementImport • The act of importing an element is called ElementImport and is a relationship between a namespace and a packageable element that resides in another namespace. • The referenced element can then be addressed directly by its (unqualified) name. In addition, an optional alias name can be specified.
  • 49. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. PackageImport •  The act of importing a package is called PackageImport; it is semantically equivalent to the import of a single element from that package. •  We cannot specify an alias name here.
  • 50. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. The metamodel for NamedElement NamedElement name : String v isibility : Visibility Kind / qualif iedName : String [0..1] [0..1] [0..1] Vis ibility Kind public priv ate protected package <<enumeration>> Element DirectedRelationship [0..1] DirectedRelationship PackageableElement NamedElement ElementImport v isibility : Visibility Kind alias : String 1 +importedElement 1{subsets target} Pac kageableElement vis ibility : Vis ibility Kind... Namespace 0..1 * +/namespace 0..1 {union, subsets owner} +/ownedMember * {union, subsets member, subsets ownedElement} * +/m ember *{union} 1 * +importingNamespace 1 {subsets source, subsets owner} +elementImport * {subsets ownedElement} * +/importedMember * {subsets member} PackageImport v isibility : Visibility Kind 1 * +importingNamespace 1 {subsets source, subs ets owner} +packageImport *{subsets ownedElement} Pac kage 1 +importedPackage 1{subsets target} [0..1] We are focusing in this section of the metamodel
  • 51. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Example of element and package import relationships <<import>> <<import>> <<access>> <<access>>
  • 52. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. <<access>> and <<import>> • <<import>>: The visibility is public; for example, the postal address for Order. The public import is a transitive relationship: if A imports B and B imports C, then A is indirectly importing C too. • <<access>>: The visibility is private, not public: Customer is visible in Order but not in Billing. The private import is not transitive.
  • 53. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Typed elements •  A typed element is a named element that can have a type. •  Ex.- Attributes and parameteres. •  A type specifies a set of values for a typed element. •  Ex.- Symple data types and classes are types.
  • 54. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Example – typed element & type Typed element Type
  • 55. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Typed elements metamodel Type and typed element are abstract classes. They have no properties NamedElement TypeTypedElement 0..1 +type 0..1 PackageableElement
  • 56. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Multiplicities •  A multiplicity element is the definition of an interval of positive integers to specify allowable cardinalities. •  A cardinality is a concrete number of elements in a set. •  A multiplicity element is often simply called multiplicity; the two terms are synonymous.
  • 57. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Example Multipicity & Cardinality Customer Bookings ** +bookings Class model :Kunde r2:Bookings r2:Bookings r2:Bookings Object model Multiplicity=0..* Cardinality=3
  • 58. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Multiplicities •  The notation for multiplicity is either a single number or a value range. •  A value range is written by stating the minimum and maximum values, separated by two dots (e.g. 1..5). •  In addtion, you can use the wildcard character * to specify an arbitrary number of elements.
  • 59. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Examples of multiplicities • 0..1 • 1 (shortcut for 1..1) • * (shortcut for 0..*) • 1..* • 5..3 (Invalid!) • -1..0 (Invalid! All values must be positive) • 3+5..7+1 (Generally meaningles, but valid; the lower or upper value, respectively is defined by a value specification).
  • 60. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. The multiplicity metamodel Element ValueSpecification MultiplicityElement isOrdered : Boolean = false isUnique : Boolean = true / upper : UnlimitedNatural / lower : Integer 0..1 0..1 +upperValue 0..1{subsets ownedElement} +owningUpper 0..1 {subsets owner} 0..10..1 +lowerValue 0..1{subsets ownedElement} +owningLower 0..1 {subsets owner} [0..1] [0..1]
  • 61. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Checklist: multiplicities 1.  What value range is described by a multiplicity? 2.  What is the difference between multiplicity and cardinality?
  • 62. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Value specification •  Def.- A value specification indicates one or several values in a model. •  Semantics.- Examples for value specifications include simple, mathematical expressions, such as 4+2, and expressions with values from the object model, Integer::MAX_INT-1
  • 63. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Value specification-semantics •  In addition, there are language-dependent expressions defined by a language statement and the pertaining expression in that language (opaque expression), such OCL or Java expression (the language statement can be omitted if the language is implicity defined by the expression or context).
  • 64. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. The metamodel and the composite pattern •  The metamodel is based on the composite pattern: LeafComposite Component *
  • 65. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Example :Expression symbol=“+” op1:LiteralInteger value=1 op2:LiteralInteger value=1 operand operand Object Model for 1+1
  • 66. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. The metamodel for value specifications OpaqueExpression body [1..* ] : String {ordered} language [0..*] : String {ordered} LiteralSpecification LiteralBoolean v alue : Boolean LiteralInteger v alue : Integer LiteralString v alue : String LiteralUnlimitedNatural v alue : U nlimit edNat ural LiteralNull InstanceValue InstanceSpecif ication 1 +instance 1 ValueSpecification Expres sion sy m bol : String * 0..1 +operand *{ordered, subsets ownedElement} +expression 0..1 {subsets owner} TypedElement PackageableElement
  • 67. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. www.mdse-book.com UML EXAMPLES
  • 68. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Class diagram
  • 69. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Component Diagram
  • 70. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Activity diagram
  • 71. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. State Diagram
  • 72. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Sequence vs. Collaboration
  • 73. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. UML Extensibility: profiles
  • 74. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Teaching material for the book Model-Driven Software Engineering in Practice by Marco Brambilla, Jordi Cabot, Manuel Wimmer. Morgan & Claypool, USA, 2012. www.mdse-book.com MODEL-DRIVEN SOFTWARE ENGINEERING IN PRACTICE Marco Brambilla, Jordi Cabot, Manuel Wimmer. Morgan & Claypool, USA, 2012. www.mdse-book.com www.morganclaypool.com or buy it at: www.amazon.com