|
1
|
- Long Talk
- (170)
- James Bruck
- IBM Rational Software
- UML2 Committer
|
|
2
|
- Introduction
- New Features:
- Static Profile Definition
- Summary
|
|
3
|
- Creating architectures using basic modeling techniques (Class diagrams,
Sequence diagrams etc.) is just the first step.
- Expand your toolbox by adding:
- Generics/Templates
- Ability to express generic reusable behavior.
- Static profile definition
- Generate code from profile
- Now you can specify behavior in your profiles.
- OCL Integration
- Ability to create constraints, attach them to your model and have all
the code necessary to evaluate the constraints using the MDT-OCL
project.
- Combination of these tools allows you to make practical use of your
models.
|
|
4
|
- Introduction
- New Features
- Static Profile Definition
- Summary
|
|
5
|
- Generics in Java™.
- Enhance reusability of an API by isolating generic behavior.
- Lists and Maps are commonly used since the implementation doesn’t care
about the types contained – their clients do.
- Generics in UML®.
- Practical Uses
- In an EMF-based modeling world, a practical end-goal of modeling is to
generate code.
- Understanding how to express templates and model precisely using UML
constructs is useful.
|
|
6
|
- The code generation process from UML to Java uses EMF.
- An intermediate Ecore
representation is created.
- Behind the scenes, MDT-UML2
converts from UML to Ecore.
|
|
7
|
|
|
8
|
- A TemplateableElement that contains a TemplateSignature is referred to
as a Template.
- If a TemplateableElement has
template parameters, a small dashed rectangle is superimposed.
|
|
9
|
|
|
10
|
|
|
11
|
|
|
12
|
- TemplateBinding
- Substitution of actual parameters for the formal template parameters.
|
|
13
|
|
|
14
|
- In Java, wildcards are represented by ? which stands for an unknown
type.
- When we talk about bounds we refer to the ability to specify that
bindings must either be the super type of some classifier or extend some
classifier.
|
|
15
|
|
|
16
|
- UML cannot capture everything.
- <<eGenericType>>
- For code generation, we want to mark classes as intermediary constructs
(not included in final Java representation).
- Introduce upper and lower bounds.
- <<eTypeParameter>>
- Introduce multiple bounds.
|
|
17
|
- Let’s revisit our previous example with wildcards and now consider
stereotype properties.
- We can set the ‘upper’ and ‘lower’ bounds on our
<<EGeneric>> stereotype.
- In the case of our Wildcard_extends_Car, we have the following:
|
|
18
|
|
|
19
|
- Code generation from a model with generics specified.
|
|
20
|
- Anything that can be expressed in Java can be represented with UML
constructs.
- Remember that in UML, you need concrete representations of your generic
classes (bound classes) in order to use them.
- These extra constructs are not required in Java or EMF.
- If you get stuck
- Use the Ecore to UML2 converter.
Start with EMF representation and then generate UML
representation.
- Can be simpler for those who understand EMF.
- Changes to upcoming version of UML meta-model.
- RTF issue: http://www.omg.org/issues/uml2-rtf.html#Issue11243
|
|
21
|
- More in-depth articles can be found on the UML2 wiki
- http://wiki.eclipse.org/MDT-UML2
- UML superstructure specification
- http://www.omg.org/cgi-bin/doc?formal/07-02-05
- The generics tutorial
- http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf
- Java Generics FAQ by Angelika Langer
- http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
|
|
22
|
- Introduction
- New Features:
- Static Profile Definition
- Summary
|
|
23
|
- A profile is a lightweight extension mechanism for UML.
- Does not specialize meta-types from UML, rather uses meta-class
extensions.
- It enables customization of UML for a specific domain to make modeling
easier.
- Primary extension construct is the Stereotype.
- Stereotypes can be used to add:
- Keywords
- Constraints
- Images
- Properties
- Behavior
|
|
24
|
- Stereotype extending Class meta-class from UML.
|
|
25
|
- We create our profile using UML.
- Define our profile.
- Use our profile by setting applying profile and stereotypes.
- Get and set properties of the stereotype.
|
|
26
|
- The current workflow involves “defining” our profiles.
- Generates an Ecore representation.
- Makes use of dynamic EMF.
|
|
27
|
- When we talk about “Static Profile Definition” we are talking about
generating code from our profile.
- The “define” step is therefore no longer necessary. It is replaced by a code generation
step.
- Both workflows will be supported going forward.
- Older workflow can be useful for rapid testing.
|
|
28
|
|
|
29
|
- Set the nsURI of the <<EPackage>> stereotype applied to the
profile root.
|
|
30
|
- Generating Code for your Profile.
- Reference UML and Ecore generator models since you do not need to
regenerate code for them.
|
|
31
|
|
|
32
|
- Code generation.
- Derived properties in profiles.
|
|
33
|
- Introduce behavior.
- Customize generated code.
- Opens up possibilities for derived constraints.
- Getting and setting values are easier and more intuitive since an
instance of the object is returned.
|
|
34
|
|
|
35
|
|
|
36
|
- With the older way of working with profiles, when changes are made, we
must re-define the profile.
- We are left with multiple Ecore representations.
- These representations can be difficult to maintain.
|
|
37
|
- With Static Profile Definition, if we introduce API breaking changes, we
would have to update the nsURI.
- Similar to how meta-models change.
- We don’t have to change the nsURI if the changes are backward
compatible.
|
|
38
|
- Preferred approach going forward.
- Easier to work with.
- Introduce behavior.
- Combine with our next topic: OCL Integration.
|
|
39
|
- More in-depth articles can be found on the UML2 wiki: http://wiki.eclipse.org/MDT-UML2
- New and Noteworthy section: http://wiki.eclipse.org/index.php/MDT_1.0_New_and_Noteworthy#Static_Profile_Definition
|
|
40
|
- Introduction
- New Features:
- Static Profile Definition
- Summary
|
|
41
|
- OCL is designed to be a simple language for specification of constraints
and queries in models.
- Specifying Constraints
- Invariant constraint – condition on attributes (or any feature of
context classifier) must always be true.
- Query – specified as the body expression of an operation.
- Have code generated from the expressions entered in the UML model.
|
|
42
|
- Constraints can be evaluated at runtime.
- Automated constraint checking allows greater integrity of the model.
- Catch errors early.
- Embellish your code with doc tags containing OCL.
- UML is not enough.
|
|
43
|
|
|
44
|
|
|
45
|
- OCL dependencies automatically added.
|
|
46
|
- context: Specifies the element we are referring to.
- Context in this example is Car
- self: Keyword that indicates the current object.
|
|
47
|
|
|
48
|
|
|
49
|
|
|
50
|
- Specify that you would like ‘Invariant Constraints’ processed.
- Specify ‘Operation Bodies’ to be added.
|
|
51
|
- Code generation.
- Validation.
|
|
52
|
|
|
53
|
- Have a look at bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=105199
for an example of how to hook in validation of your model
- Refer to OCL article at: http://www.eclipse.org/articles/article.php?file=Article-EMF-Codegen-with-OCL/index.html
|
|
54
|
- Introduction
- New Features:
- Static Profile Definition
- Summary
|
|
55
|
- We’ve looked at:
- Generics
- Static Profile Definition
- OCL Integration
- Tooling should make it easy for you to use these features.
- Try it out and report issues.
|
|
56
|
|
|
57
|
- 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.
|
Notes