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 <<instanceof>> <<instanceof>> Feature <<instanceof>> 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 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 <<application>> 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 <<interface>> 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 <<instanceof>> implements <<interface>> :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 <<instanceof>> <<instanceof>> <<instanceof>> myVWBus:Car me:Person <<instanceof>> 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 <<instanceof>> <<instanceof>> me: myVWBus: Car <<instanceof>> 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.