1	What do YOU want UML™ to be? Long Talk Kenn Hussey IBM Rational Software
2	Contents Background Language Units Compliance Levels Package Merge Redefinition Subsets Derived Unions Profiles Extending UML(2) Featherweight Extensions Lightweight Extensions Middleweight Extensions Heavyweight Extensions Summary
3	Contents Background Language Units Compliance Levels Package Merge Redefinition Subsets Derived Unions Profiles Extending UML(2) Featherweight Extensions Lightweight Extensions Middleweight Extensions Heavyweight Extensions Summary
4	Background – What is UML? Unified Modeling Language, an Object Management Group (OMG) standard A language for specifying, visualizing, and documenting models of software systems Current version is 2.1.1
5	Background – What is UML2? Unified Modeling Language 2.x A component of the Model Development Tools (MDT) Modeling subproject at Eclipse Current release, 2.0.3, is based on UML 2.1.1 Next release tentatively scheduled for June 2007 (Europa)
6	Background – What is UML2? UML2 provides a useable implementation of the UML metamodel to support the development of modeling tools a common XMI™ schema to facilitate interchange of semantic models test cases as a means of validating the specification validation rules as a means of defining and enforcing levels of compliance UML2 includes a customized EMF code generator that can handle “UMLisms” like redefinition, subsetting, and derived unions
7	Contents Background Language Units Compliance Levels Package Merge Redefinition Subsets Derived Unions Profiles Extending UML(2) Featherweight Extensions Lightweight Extensions Middleweight Extensions Heavyweight Extensions Summary
8	Language Units The modeling concepts in UML are organized into language units A language unit is a collection of tightly coupled modeling concepts that deal with a particular aspect of a system Language units are further partitioned into packages (merge increments) Language units are used as the foundation for defining compliance in UML
9	Contents Background Language Units Compliance Levels Package Merge Redefinition Subsets Derived Unions Profiles Extending UML(2) Featherweight Extensions Lightweight Extensions Middleweight Extensions Heavyweight Extensions Summary
10	Compliance Levels The modeling concepts in UML are also partitioned into horizontal layers of capability referred to as compliance points A compliance level is ultimately merged into a single “UML” package which defines a shared namespace for all compliance levels UML specifies five pre-defined compliance levels, namely L0, LM, L1, L2, and L3 UML2 is based on the L3 compliance level of UML
11	Compliance Levels – L0 Level 0 is the most basic compliance level for UML Contains the basic ability to model structure Has the same modeling capability as EMOF but does not include the other MOF™ capabilities such as reflection, identity, or extensions Level 0 is a good starting point for extending UML with additional behavior using MOF
12	Compliance Levels – L0
13	Compliance Levels – LM Level M is the Metamodel constructs compliance level from InfrastructureLibrary Adds an extra language unit for more advanced class-based structures used for building metamodels (using CMOF), such as UML itself
14	Compliance Levels – LM
15	Compliance Levels – L1 Level 1 extends the capabilities provided by Level M Adds language units for use cases, interactions, structures, actions, and activities
16	Compliance Levels – L1
17	Compliance Levels – L1
18	Compliance Levels – L2 Level 2 extends the language units already provided in Level 1 Adds language units for deployment, state machine modeling, and profiles
19	Compliance Levels – L2
20	Compliance Levels – L2
21	Compliance Levels – L3 Level 3 represents the complete UML Extends the language units provided by Level 2 Adds new language units for modeling information flows, templates, and model packaging
22	Compliance Levels – L3
23	Compliance Levels – L3
24	Compliance Levels – UML2
25	Contents Background Language Units Compliance Levels Package Merge Redefinition Subsets Derived Unions Profiles Extending UML(2) Featherweight Extensions Lightweight Extensions Middleweight Extensions Heavyweight Extensions Summary
26	Package Merge A directed relationship between two packages which indicates that the contents of the two packages are to be combined Can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge By selecting which increments to merge, it is possible to obtain a custom definition of a concept for a specific end
27	Package Merge – Terminology merged element – contained by merged package before the merge receiving element – contained by receiving package before the merge resulting element – contained by resulting package after the merge merged package – target of the merge, contains merged elements receiving package – source of the merge, contains receiving elements resulting package – result of the merge, contains resulting elements
28	Package Merge – Semantics The semantics of package merge are defined by a set of constraints and transformation rules When a merged element and a receiving element represent the same entity, their contents are conceptually merged into a single resulting element according to the rules of package merge UML2 provides a utility that will enforce these constraints and apply these transformations
29	Package Merge – Example (before)
30	Package Merge – Example (after)
31	Contents Background Language Units Compliance Levels Package Merge Redefinition Subsets Derived Unions Profiles Extending UML(2) Featherweight Extensions Lightweight Extensions Middleweight Extensions Heavyweight Extensions Summary
32	Redefinition Redefinition refers to the ability for one element to redefine another in the context of a generalization hierarchy A redefining element must be consistent with the redefined element, but may add specific constraints or other details particular to the specializing classifier The detailed semantics of redefinition vary for each specialization of RedefinableElement in UML The UML2 API and code generator provide support for Java™ code to enforce these redefinition constraints
33	Redefinition – Example (properties)
34	Redefinition – Example (properties)
35	Redefinition – Example (operations)
36	Redefinition – Example (operations)
37	Contents Background Language Units Compliance Levels Package Merge Redefinition Subsets Derived Unions Profiles Extending UML(2) Featherweight Extensions Lightweight Extensions Middleweight Extensions Heavyweight Extensions Summary
38	Subsets A property may be marked as the subset of another, as long as every element in the context of the subsetting property conforms to the corresponding element in the context of the subsetted property The collection of values associated with an instance of the subsetting property must be included in, or the same as, the collection of values associated with an instance of the corresponding subsetted property The UML2 API and code generator provide support for Java code to enforce these subset constraints
39	Subsets – Example (non-derived)
40	Subsets – Example (non-derived)
41	Subsets – Example (non-derived)
42	Subsets – Example (derived)
43	Subsets – Example (derived)
44	Contents Background Language Units Compliance Levels Package Merge Redefinition Subsets Derived Unions Profiles Extending UML(2) Featherweight Extensions Lightweight Extensions Middleweight Extensions Heavyweight Extensions Summary
45	Derived Unions If a property is derived, then its value(s) can be computed from other information A property may be marked as being a derived union The collection of values denoted by the property in some context is derived by being the strict union of all of the values denoted, in the same context, by properties defined to subset it If a derived union property is not multivalued, the values of all the subsets must be either the same or null The UML2 API and code generator provide support for Java code to enforce these derived union constraints
46	Derived Unions – Example
47	Derived Unions – Example
48	Derived Unions – Example
49	Derived Unions – Example
50	Contents Background Language Units Compliance Levels Package Merge Redefinition Subsets Derived Unions Profiles Extending UML(2) Featherweight Extensions Lightweight Extensions Middleweight Extensions Heavyweight Extensions Summary
51	Profiles UML provides a mechanism that allows metaclasses from an existing metamodel to be adapted for different purposes A profile is a kind of package that extends a reference metamodel A stereotype is a kind of class that may extend one or more metaclasses via extension relationships, as part of a profile It is possible to interchange profiles, together with models to which they have been applied, via XMI UML2 provides support for defining and interchanging profiles
52	Contents Background Language Units Compliance Levels Package Merge Redefinition Subsets Derived Unions Profiles Extending UML(2) Featherweight Extensions Lightweight Extensions Middleweight Extensions Heavyweight Extensions Summary
53	Extending UML(2) – Why? Use terminology that is adapted to a particular platform or domain Specify a syntax for constructs that do not have a notation Specify a different notation for symbols that already exist Add semantics that are left unspecified in UML Add semantics that do not exist in UML Add constraints that restrict the way one may use UML Add information that can be used when transforming a model to another model or code
54	Extending UML(2) – How? One of the strengths of the latest version of UML is that it can be customized to meet the needs of a given application or domain There are two “official” ways of customizing UML lightweight extensions using profiles heavyweight, or first-class, extensions using MOF UML2 supports these kinds of extensions but also provides two lighter-weight alternatives which we’ll call featherweight and middleweight extensions
55	Extending UML(2) – Example Assume we want to customize UML for modeling testing systems We’ll (ab)use some concepts from the UML Testing Profile and JUnit Test Suite – a package containing text contexts to test a system Test Context – a class owning test cases to test a component Test Case – an operation specifying tests to realize an objective We’ll examine how to extend UML2 for this “domain” using the four different approaches
56	Extending UML(2) – Example
57	Contents Background Language Units Compliance Levels Package Merge Redefinition Subsets Derived Unions Profiles Extending UML(2) Featherweight Extensions Lightweight Extensions Middleweight Extensions Heavyweight Extensions Summary
58	Featherweight Extensions Featherweight extensions are done by adorning model elements with keywords A keyword is a label for a model element that is typically displayed within guillemots UML2 stores these keywords in Ecore annotations
59	Featherweight Extensions – Example
60	Featherweight Extensions – Example
61	Featherweight Extensions – Example
62	Featherweight Extensions – Example
63	Featherweight Extensions – Pros/Cons
64	Contents Background Language Units Compliance Levels Package Merge Redefinition Subsets Derived Unions Profiles Extending UML(2) Featherweight Extensions Lightweight Extensions Middleweight Extensions Heavyweight Extensions Summary
65	Lightweight Extensions Lightweight extensions are done by creating profiles/stereotypes and applying them to model elements Stereotypes can be used to add keywords, constraints, images, and properties (tagged values) to model elements Metadata for profiles must be defined and deployed UML2 stores stereotype applications as dynamic EMF objects
66	Lightweight Extensions – Example
67	Lightweight Extensions – Example
68	Lightweight Extensions – Example
69	Lightweight Extensions – Example
70	Lightweight Extensions – Example
71	Lightweight Extensions – Example
72	Lightweight Extensions – Pros/Cons
73	Contents Background Language Units Compliance Levels Package Merge Redefinition Subsets Derived Unions Profiles Extending UML(2) Featherweight Extensions Lightweight Extensions Middleweight Extensions Heavyweight Extensions Summary
74	Middleweight Extensions Middleweight extensions are done by creating a metamodel that extends the UML2 metamodel via specialization An API and schema for the new metamodel must be generated, implemented, and deployed The implementation classes in the specialized metamodel extend the UML2 implementation classes (discouraged) The API and resource implementation must conform with the UML2 API and resource implementation
75	Middleweight Extensions – Example
76	Middleweight Extensions – Example
77	Middleweight Extensions – Example
78	Middleweight Extensions – Example
79	Middleweight Extensions – Example
80	Middleweight Extensions – Example
81	Middleweight Extensions – Example
82	Middleweight Extensions – Example
83	Middleweight Extensions – Pros/Cons
84	Contents Background Language Units Compliance Levels Package Merge Redefinition Subsets Derived Unions Profiles Extending UML(2) Featherweight Extensions Lightweight Extensions Middleweight Extensions Heavyweight Extensions Summary
85	Heavyweight Extensions Heavyweight extensions are done by creating a metamodel that merges packages from UML An API and schema for the new metamodel must be generated, implemented, and deployed The implementation classes in the specialized metamodel do not extend the UML2 implementation classes The API and resource implementation need not conform with the UML2 API and resource implementation
86	Heavyweight Extensions – Example
87	Heavyweight Extensions – Example
88	Heavyweight Extensions – Example
89	Heavyweight Extensions – Example
90	Heavyweight Extensions – Example
91	Heavyweight Extensions – Example
92	Heavyweight Extensions – Example
93	Heavyweight Extensions – Example
94	Heavyweight Extensions – Example
95	Heavyweight Extensions – Example
96	Heavyweight Extensions – Example
97	Heavyweight Extensions – Example
98	Heavyweight Extensions – Pros/Cons
99	Contents Background Language Units Compliance Levels Package Merge Redefinition Subsets Derived Unions Profiles Extending UML(2) Featherweight Extensions Lightweight Extensions Middleweight Extensions Heavyweight Extensions Summary
100	Summary UML can be extended to suit the needs of your application or domain The UML2 component of MDT supports several customization mechanisms, each having their own pros and cons The choice of which approach to take will depend on the amount of overlap between your domain and UML Domains having little or nothing in common with UML can be supported with a domain specific language (DSL) developed with EMF
101	Legal Notices UML, XMI, and MOF are trademarks of the Object Management Group Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both Other company, product, or service names may be trademarks or service marks of others