Lecture 20: Applications of Generic Lecture

Peter Thiemann

University of Freiburg, Germany

26.07.2012

Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 1 / 21 Metamodeling Applications Feature Modeling Applications of Metamodeling Feature Modeling

I Feature models are a tool for

I Provide a hierarchical view of features and their dependencies I Establish an ontology for categorization

I Visualized by feature diagrams

I Conceived for domain analysis: Kang, Cohen, Hess, Novak, Peterson. Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical report CMU/SEI-90-TR-21. 1990.

I Popularized for Generative Programming by Czarnecki and Eisen¨acker

I Also for analyzing other domains

Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 2 / 21 Metamodeling Applications Feature Modeling Feature Modeling Example

Vehicle

Body Gearbox Engine Hitch

manual automatic electrical Combustion

I Hierarchical, but not is-a relation (as in a class diagram)

I Features may be qualified as required, optional, alternative, or n-of-m (selection)

Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 3 / 21 Metamodeling Applications Feature Modeling Feature Modeling MOF-based Metamodel

attributes MOF::Attribute MOF::Class

type:String value:String MOF

<> <> Feature <> Modelling

groups FM::SubfeatureGroup kind FM::Feature FM::GroupKind 1 n 1 1 n 1

features parent

FM::GroupKind inv:value=="required"||value=="optional"|| FM::Concept FM::Concept value=="alternative"||value=="nOfM" inv:parent==null inv:type=="String"

Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 4 / 21 Metamodeling Applications Feature Modeling Feature Modeling Feature Model in Abstract Syntax

additionalFeatureSFG AdditionalFeature addFeatureTwoSFG threadFeature FM::SubfeatureGroup FM::Feature FM::SubfeatureGroup FM::Feature

kind="optional" name="AdditionalFeatures" kind="nOfM" name="ThreadSafety"

boundsFeature FM::Feature

stackFeature: name="BoundsCheck"

FM::Concept typeFeature FM::Feature

name="TypeCheck

optimizationDFG optimizationFeature optimizationKindSFG speedFeature FM::SubfeatureGroup FM::Feature FM::SubfeatureGroup FM::Feature

kind="optional" name="Optimization" kind="alternative" name="Speed"

memoryFeature Additional Optimization Stack FM::Feature Features name="MemoryUsage"

Memory Thread Bounds Type Speed Usage Safety Check Check

Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 5 / 21 Metamodeling Applications Feature Modeling Feature Modeling Extended Metamodel and Concrete Syntax

Metamodel Object diagram Feature diagram

optimizationFeature FM::Feature

FM::Feature Optimization name="Optimization" [open] open:boolean open=true

New feature ⇒

I new attribute in metamodel I new slot in model I extension of concrete syntax Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 6 / 21 Metamodeling Applications Component Modeling Applications of Metamodeling Component Modeling

I Domain specific for small and embedded systems

I Main abstraction: component I A component may

I provide services via interfaces I require services via interfaces I have configuration parameters I be an application (does not provide services)

Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 7 / 21 Metamodeling Applications Component Modeling Component Modeling Example

MenuUtilities

<> TextEditor SMSApp

SMSIF

SMSIF CallIF EMSIF

UIManager GSMStack lookAndFeel:String

Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 8 / 21 Metamodeling Applications Component Modeling Component Modeling Simple Component Metamodel

* ConfigParam

{subsets Attributes}

1 * * 1 Component ports Port Interface

Application RequiredPort ProvidedPort

from to

context Application Port inv: ports−>select(oclIsKindOf(ProvidedPort))−>isEmpty context PortDependency Dependency inv: to.Interface = from.Interface

Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 9 / 21 Metamodeling Applications Component Modeling Component Modeling MOF-based Simple Component Metamodel

{subsets Features}

Attributes

*

UML:: Attribute UML:: UML::Class name: String Interface type: String

1 * * 1 Component Port Interface ports

* ConfigParam {subsets Attributes} RequiredPort ProvidedPort

from to context ConfigParam Port context PortDependency inv: type = "String" Application Dependency inv: to.Interface = from.Interface

context Application

inv: ports−>select(oclIsKindOf(ProvidedPort))−>isEmpty

Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 10 / 21 Pitfalls in Metamodeling Pitfalls in Metamodeling

How to avoid

I confusion with UML notation

I mixing metalevels Central question

I what is the mapping to a programming language?

Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 11 / 21 Pitfalls in Metamodeling Interfaces Constraint: Every instance of Entity should implement SomeInterface

I wrong approach

<> SomeInterface Entity

I book solution use OCL or subsetting of metaassociation

Entity realization −>exists(oclIsTypeOf(SomeInterface))

{subsets realization} 1 Entity SomeInterface

Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 12 / 21 Pitfalls in Metamodeling Interfaces/2 Constraint: Every instance of Entity should implement SomeInterface

I correct solution use OCL

realization Entity −>select(hasStereotype("interface")) −>select(name="SomeInterface") −>size() = 1

<>

implements <> :Entity SomeInterface

Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 13 / 21 Pitfalls in Metamodeling Dependency

I Problem: A Component may depend from multiple Interfaces because the Component may invoke operations of the Interfaces.

I wrong approach “metaclass Component depends on metaclass Interface”

Component Interface

I correct solution a metaassociation “uses”

uses Component Interface * *

Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 14 / 21 Pitfalls in Metamodeling Identifying Attribute

An Entity must have an identifying attribute with name ID and type String. Entity is a subclass of UML::Class.

I wrong approach

Entity

ID : String

defines a tagged value ID for all Entity instances in the model

Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 15 / 21 I incorrect attempt context Entity inv: Attribute ->select (Name="ID" and Type.Name="String") ->size() = 1

Pitfalls in Metamodeling Identifying Attribute

I correct solution

(Attribute−>select( Name = "ID")−>size=1) Entity and (Attribute−>select( Name= "ID")−>forAll( Type.Name = "String" )

I there must be exactly one attribute with name ID I all attributes named ID must have type String

Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 16 / 21 Pitfalls in Metamodeling Identifying Attribute

I correct solution

(Attribute−>select( Name = "ID")−>size=1) Entity and (Attribute−>select( Name= "ID")−>forAll( Type.Name = "String" )

I there must be exactly one attribute with name ID I all attributes named ID must have type String

I incorrect attempt context Entity inv: Attribute ->select (Name="ID" and Type.Name="String") ->size() = 1

Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 16 / 21 Pitfalls in Metamodeling Primary Key Attribute

Each instance of Entity must have exactly one attribute of type EntityPK, where EntityPK is a subclass of Attribute.

Entity

pk : EntityPK I wrong approach

I correct solution {subsets Feature} * UML::Class UML::Attribute Attribute

{subsets Attribute} 1 Entity EntityPK

Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 17 / 21 Pitfalls in Metamodeling Metalevels and Instanceof

driver Car Person

M1

M0

<> <> <>

myVWBus:Car me:Person <>

myFather’sGolf:Car myFather:Person

I Objects are instances of classes I Links are instances of associations

Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 18 / 21 Pitfalls in Metamodeling Metalevels and Instanceof Model Elements as Instances of Metamodel Elements

UML::Class UML::Object

<> <>

me: myVWBus: Car <>

Person father: myFather’sGolf

I Car and Person classes are instances of the metaclass UML::Class I me: and myFather: are instances of the metaclass UML::Object I How can that be? Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 19 / 21 Pitfalls in Metamodeling Metalevels and Instanceof A Look at the Metamodel

type instance UML::Class UML::Object 1 instanceof *

AssociationEnd

roleName cardinality 2

1

type instance UML::Association UML::Link 1 instanceof *

I ⇒ two different instanceof relations Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 20 / 21 Summary Summary

I Metamodeling required for customizing UML

I OMG relies on MOF to define profiles

I OCL defines static semantics of models

I Metalevels should not be confused

Peter Thiemann (Univ. Freiburg) Lecture 20: Applications of Metamodeling 26.07.2012 21 / 21