copyright © ibm corp., 2007-2008. | march-17-2008 | creating robust scalable dsls with uml tutorial...

Copyright © IBM Corp., 2007-2008. | March-17-2008 |

Creating Robust Scalable DSLs with UML

Tutorial(172)

James Bruck,Christian Damus

IBM Rational Software

Creating Robust Scalable DSLs with UML | Tutorial | Copyright © IBM Corp., 2007-2008. All rights reserved. 2

Agenda

• Introduction• Exploring Extension Mechanisms

Featherweight Lightweight Middleweight Heavyweight

• Deciding which Technique to Use• Advanced Concepts

Subsetting Derived Unions Redefinition

• Meta-model Decomposition Package Merge Language Units Compliance Levels

• Summary


Introduction – What is a DSL?

• DSL stands for “Domain Specific Language”.

• A DSL is created specifically to solve problems in a particular domain.

A language designed to be useful for a specific task.

• UML® is a general purpose modeling language. Large and very expressive. UML 1.x was sometimes criticized for being too large, UML

2.x adds even more concepts.


Introduction – Why extend UML?

• A common end-goal of those wishing to extend UML is to leverage existing tools and conventions defined by UML while making modeling easier for the end user.

Give a terminology that is adapted to a particular domain. Give a different notation for already existing symbols Add semantics that do not exist in the meta-model. Add constraints that restrict the way you use the meta-model. Add information that can be used when transforming a model to another model or

code.


Introduction – Understanding the Options

• Need to know: The types of customizations you wish to create.

Add/remove behavior Add/remove properties Add/remove constraints

How the extended meta-model is intended to be used. How will end user create instances of new meta-types and meta-

types from the extended meta-model.

How much overlap exists between new domain and extended domain.


Agenda




Subsets Derived Unions Redefinition


• Summary


Exploring Extension Mechanisms - Featherweight

• Why use Keywords? To distinguish a particular concept from others sharing the

same general graphical form.

• For example: uml::Interface has a similar appearance to uml::Class.

The keyword <<interface>> is used to distinguish interfaces from other classifiers.



• Why use Keywords? To distinguish a particular kind of relationship from other

relationships sharing the same graphical form.



• Why use Keywords? To specify the value of some modifier attached to a meta-attribute

value. The keyword <<singleExecution>> appearing within an Activity signifies that the

isSingleExecution attribute of the Activity is true.

To indicate standard stereotype. For example the <<modelLibrary>> keyword attached to a package identify that the

package contains a set of model elements intended to be shared by multiple models.

• There is support in the API: Element::addKeyword(), Element::removeKeyword(), Element::hasKeyword() etc.



• Pro Adding keyword is trivial Great to visually distinguish items

• Con Limited functionality Cannot add attributes or operations


Agenda






• Summary


Exploring Extension Mechanisms - Lightweight

• A profile defines a limited extension to a reference meta-model.

• Primary extension construct is the Stereotype.

• Stereotypes can be used to add: Keywords Constraints Images Properties Behavior

• Should be your first choice when considering extending UML.


Exploring Extension Mechanisms - Lightweight


Exploring Extension Mechanisms - Lightweight• Pro

Easy to create and work with. Well described and documentation in the superstructure spec. Standard means to define icons and display options. Low implementation cost. Standard mechanism that interoperates with other compliant tools.

• Con Cannot remove existing constraints. Cannot modify existing structures. Not a first class extension mechanism.

Cannot use redefinition for example since Stereotypes are not specializations of the meta-types they extend.


Exercise 1 – Lightweight Extension

• Objectives: Learning how to describe domain specific constructs with a

profile. Explore Static Profile Definition.

Generate Java™ API for the profile. Register the generated profile to make it available at run-time.

Work with your profile. Apply and use the profile in a UML model.


Exercise 1 – Lightweight Extension• Core stereotypes of the MyUnit profile.


Exercise 1 – Lightweight Extension

• Timing stereotypes of MyUnit profile For performance sensitive tests


Agenda






• Summary


Exploring Extension Mechanisms - Middleweight

• Extension by specialization of UML meta-classes. Extend by specializing types within UML.metamodel.uml

(the merged UML meta-model)

• Creating dependencies on a specific version of UML.

• Implementation classes in the specialized meta-model reference internal UML implementation classes (compiler warnings)


Exploring Extension Mechanisms - Middleweight

• Pro First class extension mechanism. Easier than heavyweight to create initially. Easy for end user to use programmatically than profiles. Can add behavior. Can add structure. Can add constraints.

• Con Creates dependence on specific version of UML. Difficult to maintain especially if UML changes. User must know about 2 factories for creating elements, the

UMLFactory and the new one defined by the extension.


Agenda






• Summary


Exploring Extension Mechanisms – Heavyweight

• Reuse by copy instead of reuse by extension as middleweight.

• Heavyweight extensions involve 2 steps Select the language units you wish to extend and merge. Add your own domain specific types.

• Merging packages forms the basis for constructing UML itself.

• Have access to all concepts used to create UML Subset Redefinition Derived unions


Exploring Extension Mechanisms – Heavyweight

• Pro Easy for end users to use programmatically (only 1 meta-model

in the end) Ability to override or customize operations and behavior. Can add behavior/constraints/structure. Isolate yourself from changes to UML meta-model. You can stratify your own specialized meta-model for different

levels of abstraction and DSL concerns.

• Con Costly development (more complex than profiles). Difficult to maintain (re-merge). Lose interoperability with other UML based tools since we have

a new meta-model.


Agenda






• Summary


Other concepts – Subsets

• Comes in 2 flavors Derived subsets Non-derived subsets

• UML2 includes a customized EMF code generator to handle subsets.


Other concepts – Subsets - Derived

• Values are computed from the values of the superset property.

Often read-only.

• Example Package::nestedPackage is a derived subset of

Package::packageableElement.

Since nested package collection is derived, a user cannot add directly to it.

Clients must add to the packageableElement collection.


Other concepts – Subsets – Non-Derived

• Values are not computed from the superset values. Must be writable.

• Example Operation::precondition subsets Namespace::ownedRule.

Adding a precondition to some operation means that if you call Operation::getOwnedRules(), that precondition will appear in the collection.

A precondition has a “Subset-Superset” implementation meaning that if a Constraint was added to owned rule collection that it would not be added to precondition list. However, adding to the precondition collection does mean that it gets added to the owned rule collection.


Other concepts – Derived unions

• Indicate that a property is the union of one or more collections (or scalar).

• Typically applied to properties on abstract types high up in the inheritance hierarchy.

• Concrete types make a derived union useful by contributing subsets.

• Derived unions are read only and derived ().


Other concepts – Derived unions

• Element::ownedElement is a derived union.

Element contributes Element::ownedComment to that collection.

Package contributes Package::ownedTemplateSignature and Package::profileApplication amongst others.


Derived unions: Example


Other concepts – Redefinition

• Redefinition replaces an existing property.

• Redefinition only makes sense in the context of specialization.

• May be used to change the definition of a feature.

• The detailed semantics of redefinition vary for each specialization of RedefinableElement in UML.


Other concepts – Redefinition

• Redefinition can be used to restrict the kinds of things added to a collection (like co-variant returns in Java™).

• The name of a property which has been redefined does not have to match the one redefining it.


Other concepts – Redefinition: Example

• Class::superClass redefines Classifier::general


Exercise 2 – Creating Middleweight Extension

• Objectives: Explore subsets. Explore extending UML using specialization. Explore code generator options.


Exercise 2 – Creating Middleweight Extension• Core meta-classes of the MyUnit meta-model.


Exercise 2 – Creating Middleweight Extension• Timing meta-classes of the MyUnit meta-model


Agenda• Introduction• Exploring Extension Mechanisms



Subsetting Derived Unions Redefinition


• Summary


Package Merge

• A directed relationship between two packages which indicates that the contents are to be combined.

• This mechanism should be used when elements defined in different packages are intended to represent the same concept.

• By selecting which increments to merge, it is possible to obtain a custom definition of a concept.

• Package merge allows modeling concepts defined in one package to be extended with new features.

• UML itself is a merge of a large number of packages.


Package Merge

• Package merge allows modeling concepts defined at one level to be extended with new features.


Package Merge - Example


Language Units

• In order to deal with the problem of language complexity, UML 2.0 was modularized in a way that allows selective use of language units.

• The modeling concepts in UML are also partitioned into layers of capability referred to as compliance levels.

• UML itself is ultimately merged into a single package which defines a shared namespace for all compliance levels.


Language Units and Compliance Levels


Compliance Levels – L0

• Represents a common denominator that can serve as a basis for interoperability.

• The core of EMOF.



• Adds language units for use cases, interactions, structures, actions, and activities.



• Adds language units for deployment, state machine modeling and profiles.



• Adds language units for information flows, templates and model packaging.

• Represents the complete UML.


Exercise 3 – Creating Heavyweight Extension

• Objectives: Explore Package Merge. Explore working with your extension (generating an editor).



• Core package of the MyUnit library



Timing Language Unit Objectives Language Unit



• Overview of the MyUnit library



Basic Compliance Level Complete Compliance Level


Agenda






• Summary


Summary

• Four basic techniques. Flyweight Lightweight Middleweight Heavyweight

• Favor “lightweight” extension (use of profiles). A practical solution for most applications.


Thank You!


Legal Notices

• Copyright © IBM Corp., 2007-2008. All rights reserved. Source code in this presentation is made available under the EPL, v1.0; remainder of the presentation is licensed under Creative Commons Att. Nc Nd 2.5 license.

• IBM and the IBM logo are trademarks or registered trademarks of IBM Corporation in the United States, other countries, or both.

• Rational and the Rational logo are trademarks or registered trademarks of International Business Corporation in the United States, other countries, or both.

• UML, Unified Modeling Language, and MOF are trademarks or registered trademarks of Object Management Group, Inc.

• Java and all Java-based trademarks, among others, are trademarks or registered trademarks of Sun Microsystems in the United States, other countries, or both

• Eclipse and the Eclipse logo are trademarks of the Eclipse Foundation, Inc.

• Other company, product, and service names may be trademarks or service marks of others.

• THE INFORMATION DISCUSSED IN THIS PRESENTATION IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY. WHILE EFFORTS WERE MADE TO VERIFY THE COMPLETENESS AND ACCURACY OF THE INFORMATION, IT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, AND IBM SHALL NOT BE RESPONSIBLE FOR ANY DAMAGES ARISING OUT OF THE USE OF, OR OTHERWISE RELATED TO, SUCH INFORMATION. ANY INFORMATION CONCERNING IBM’S PRODUCT PLANS OR STRATEGY IS SUBJECT TO CHANGE BY IBM WITHOUT NOTICE.

copyright © ibm corp., 2007-2008. | march-17-2008 | creating robust scalable dsls with uml tutorial...

Documents