Lecture 20: Applications of Metamodeling 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 domain analysis
I Provide a hierarchical view of features and their dependencies I Establish an ontology for categorization
I Visualized by feature diagrams
I Conceived for software 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
<
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 modeling language 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
<
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
<
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 <
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