Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 Tools » Connecting DSL-eCore w/ UML2
Connecting DSL-eCore w/ UML2 [message #471129] Mon, 11 June 2007 09:54 Go to next message
Stefan Kuhn is currently offline Stefan KuhnFriend
Messages: 355
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------080404030005060101030601
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

hi folks,

the following text is quite long, so if you're in a rush just read
abstract, look at the picture, read constraints, the idea and the last
point of ecore-mapping.

Abstract:
basically I want to be able to read & write proper UML2 models with my
GMF-DSL Editor. For me this sounds like a real common problem, but I'm
going to outline it in detail because I didn't find a good way to start
/ solve it.

Use Case:
We're working with MDSD and already have a cardridge for a domain. Right
now, the generator gets the model from an uml2 tool. The graphical
editor I have to make (using GMF) for this domain should be able to read
and write uml2 models because of reasons like flexibility (wheather or
not to use my editor) or extended control of an uml tool (e.g to model
the DTOs in the same file). Both, UML2 Tools and the generator accept
uml2 models from ecore.

DSL:
There various reasons why a tend to create my own domain specific
language (DSL) for my graphical editor (GE) in contrast to use uml2.ecore:
* a DSL which uses around 10 classes seems to be overburdened if it's
based on the uml2.ecore with several hundred classes.
* not that error prone because less confusion for the GMF framework and
even more important for me.
* some constraints are already implicit from my DSL Metamodel (MM) and
the others should be easier to write on a simple MM.
* It seems unhandy to create the uml2.ecore model code (after 5 hours I
stopped the generation).
* there must be a reason why GMF enforces the creation of DSLs rather
than building a customized UML2 editor.

The two worlds:
This results in two worlds for my "MetaModel" sketch (see attached
picture). In the left corner, we see famous UML with his well known
metaclasses and packages. On the right corner we can see the young DSL
also with metaclasses described in ecore. Now my experiments showed that
the heavyweigth extensions in which I extended classes from the
uml2.ecore are uml2-xmi compliant. So the only way to customize uml and
still be able to use standard uml tools is the lightweight approach. I
sketched this with the outer circle around uml.

Contraints:
* I assume that I'm not restricting UML and
* that every DSL Class has a pendant in uml with a lack of semantics
expressable by stereotypes.
* both MM are defined in EMF.

The idea:
is to connect my DSL-MM with the uml2-MM. This should be realizable by
creating a profile with sterotypes and enumerations for my DSL and
represent my DSL classes in uml with the appropriate stereotype. I
illustrated this in the 2nd picture "Concrete example" which shows
instances of both MM. So on the right we can see the instance classes of
MyDSL: a container, a class named Ex1 which is an instance of
DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
association between Ex1 and Ex2 and a class named Ex3 which is an
instance of DSL-Class#2. Now I want to map them to UML. Following my
example this would result in mapping:
* an instance of container to an uml-package with sterotype dsl-container
* an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
sterotype dsl-class#1
* an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
sterotype dsl-class#1
* an association between Ex1 and Ex2 to an uml association (which may be
stereotyped as "dsl-association if easier)
* an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
sterotype dsl-class#2

Other Mapping possibilities (mentioned if my vision doesn't work in time):
* Model-to-Model transformation is an option. I rather dislike this for
the classic reasons e.g. consistency between the models, overwriting or
synchronization of changes and -for me the most important one- possible
information loss due to the lack of representation in one language. In
my example this means that if a "NotDslClass" exists in the left UML
world for which I have no representation in MyDSL there is no need to
represent it in MyDSL. But I guess I would be forced to handle it
somehow not to loose information in the back-to-uml transformation.
* Customized XML/XMI serialization through extending the XMLHelper also
seems error prone and seems to require a good knowledge of XMI,too.

Ecore Mapping:
So a better approach would be to simulate the DSL-MM for my GMF-DSL
editor but actually work directly on an UML model. I found the EMF part
of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
found the some starting points or ideas how to realize it. My problem is
I can hardly value them nor I know a kind of best practice for this. So
it would be really nice to start a discussion about them or if you say
just read this f****** manual because I'm stuck right now ;(
* refering the UML-MM in MyDSL (as described in IBMs book p. 36ff) looks
like an option but my impression is that this is not really what I want.
* Abuse the Model classes (or facades), normally generated by generate
model code as an adapter to eclipse-uml2 facades seems like a lot of
work implying a pretty good understanding of EMF.
* My Favourite: to use the Ecore2Ecore mapper and a customized rescource
handler as mentioned in EMF-EclipseCon p.158ff. My issue here is that
it's just mentioned and not really described, but it seems exactly like
what I want. This feeling is emphazied by features like
OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
resources about that or if there isn't a simple proof-of-concept example
somewhere.

Thanks for reading already
-stefan


--------------080404030005060101030601
Content-Type: image/jpeg;
name="sketch.jpeg"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="sketch.jpeg"

/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsL DBkSEw8UHRof
Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwL DBgNDRgyIRwh
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjL/wAAR
CAT6BJ8DASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcI CQoL/8QAtRAA
AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS 0fAkM2JyggkK
FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWG
h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW 19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcI CQoL/8QAtREA
AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMz UvAVYnLRChYk
NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0 dXZ3eHl6goOE
hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk
5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwC/8Lfhb4N8R/DjSdW1bRvt F9P53mS/apk3
bZnUcK4A4AHArsP+FJfDz/oXv/J24/8AjlHwS/5JDoX/AG8f+lElegUAef8A /Ckvh5/0L3/k
7cf/AByj/hSXw8/6F7/yduP/AI5XoFFAHn//AApL4ef9C9/5O3H/AMco/wCF JfDz/oXv/J24
/wDjlegUUAef/wDCkvh5/wBC9/5O3H/xyj/hSXw8/wChe/8AJ24/+OV6BRQB 5/8A8KS+Hn/Q
vf8Ak7cf/HKP+FJfDz/oXv8AyduP/jlegUUAef8A/Ckvh5/0L3/k7cf/AByj /hSXw8/6F7/y
duP/AI5XoFFAHn//AApL4ef9C9/5O3H/AMco/wCFJfDz/oXv/J24/wDjlegU UAef/wDCkvh5
/wBC9/5O3H/xyj/hSXw8/wChe/8AJ24/+OV6BRQB5/8A8KS+Hn/Qvf8Ak7cf /HKP+FJfDz/o
Xv8AyduP/jlegUUAef8A/Ckvh5/0L3/k7cf/AByj/hSXw8/6F7/yduP/AI5X oFFAHn//AApL
4ef9C9/5O3H/AMco/wCFJfDz/oXv/J24/wDjlegUUAef/wDCkvh5/wBC9/5O 3H/xyj/hSXw8
/wChe/8AJ24/+OV6BRQB5/8A8KS+Hn/Qvf8Ak7cf/HKP+FJfDz/oXv8AyduP /jlegUUAef8A
/Ckvh5/0L3/k7cf/AByj/hSXw8/6F7/yduP/AI5XoFFAHn//AApL4ef9C9/5 O3H/AMco/wCF
JfDz/oXv/J24/wDjlegUUAef/wDCkvh5/wBC9/5O3H/xyj/hSXw8/wChe/8A J24/+OV6BRQB
5/8A8KS+Hn/Qvf8Ak7cf/HKP+FJfDz/oXv8AyduP/jlegUUAef8A/Ckvh5/0 L3/k7cf/AByj
/hSXw8/6F7/yduP/AI5XoFFAHn//AApL4ef9C9/5O3H/AMco/wCFJfDz/oXv /J24/wDjlegU
UAef/wDCkvh5/wBC9/5O3H/xyj/hSXw8/wChe/8AJ24/+OV6BRQB5/8A8KS+ Hn/Qvf8Ak7cf
/HKP+FJfDz/oXv8AyduP/jlegUUAef8A/Ckvh5/0L3/k7cf/AByj/hSXw8/6 F7/yduP/AI5X
oFFAHn//AApL4ef9C9/5O3H/AMco/wCFJfDz/oXv/J24/wDjlegUUAef/wDC kvh5/wBC9/5O
3H/xyj/hSXw8/wChe/8AJ24/+OV6BRQB5/8A8KS+Hn/Qvf8Ak7cf/HKP+FJf Dz/oXv8AyduP
/jlegUUAef8A/Ckvh5/0L3/k7cf/AByj/hSXw8/6F7/yduP/AI5XoFFAHn// AApL4ef9C9/5
O3H/AMco/wCFJfDz/oXv/J24/wDjlegUUAef/wDCkvh5/wBC9/5O3H/xyj/h SXw8/wChe/8A
J24/+OV6BRQB5/8A8KS+Hn/Qvf8Ak7cf/HKP+FJfDz/oXv8AyduP/jlegUUA ef8A/Ckvh5/0
L3/k7cf/AByj/hSXw8/6F7/yduP/AI5XoFFAHn//AApL4ef9C9/5O3H/AMco /wCFJfDz/oXv
/J24/wDjlegUUAef/wDCkvh5/wBC9/5O3H/xyj/hSXw8/wChe/8AJ24/+OV6 BRQB5/8A8KS+
Hn/Qvf8Ak7cf/HKP+FJfDz/oXv8AyduP/jlegUUAef8A/Ckvh5/0L3/k7cf/ AByj/hSXw8/6
F7/yduP/AI5XoFFAHn//AApL4ef9C9/5O3H/AMco/wCFJfDz/oXv/J24/wDj legUUAef/wDC
kvh5/wBC9/5O3H/xyj/hSXw8/wChe/8AJ24/+OV6BRQB5/8A8KS+Hn/Qvf8A k7cf/HKP+FJf
Dz/oXv8AyduP/jlegUUAef8A/Ckvh5/0L3/k7cf/AByj/hSXw8/6F7/yduP/ AI5XoFFAHn//
AApL4ef9C9/5O3H/AMco/wCFJfDz/oXv/J24/wDjlegUUAef/wDCkvh5/wBC 9/5O3H/xyj/h
SXw8/wChe/8AJ24/+OV6BRQB5/8A8KS+Hn/Qvf8Ak7cf/HKP+FJfDz/oXv8A yduP/jlegUUA
ef8A/Ckvh5/0L3/k7cf/AByj/hSXw8/6F7/yduP/AI5XoFFAHn//AApL4ef9 C9/5O3H/AMco
/wCFJfDz/oXv/J24/wDjlegUUAef/wDCkvh5/wBC9/5O3H/xyj/hSXw8/wCh e/8AJ24/+OV6
BRQB5/8A8KS+Hn/Qvf8Ak7cf/HKP+FJfDz/oXv8AyduP/jlegUUAef8A/Ckv h5/0L3/k7cf/
AByj/hSXw8/6F7/yduP/AI5XoFFAHn//AApL4ef9C9/5O3H/AMco/wCFJfDz /oXv/J24/wDj
legUUAef/wDCkvh5/wBC9/5O3H/xyj/hSXw8/wChe/8AJ24/+OV6BRQB5/8A 8KS+Hn/Qvf8A
k7cf/HKP+FJfDz/oXv8AyduP/jlegUUAef8A/Ckvh5/0L3/k7cf/AByj/hSX w8/6F7/yduP/
AI5XoFFAHn//AApL4ef9C9/5O3H/AMco/wCFJfDz/oXv/J24/wDjlegUUAef /wDCkvh5/wBC
9/5O3H/xyj/hSXw8/wChe/8AJ24/+OV6BRQB5/8A8KS+Hn/Qvf8Ak7cf/HKP +FJfDz/oXv8A
yduP/jlegUUAef8A/Ckvh5/0L3/k7cf/AByj/hSXw8/6F7/yduP/AI5XoFFA Hn//AApL4ef9
C9/5O3H/AMco/wCFJfDz/oXv/J24/wDjlegUUAef/wDCkvh5/wBC9/5O3H/x yj/hSXw8/wCh
e/8AJ24/+OV6BRQB5/8A8KS+Hn/Qvf8Ak7cf/HKP+FJfDz/oXv8AyduP/jle gUUAef8A/Ckv
h5/0L3/k7cf/AByj/hSXw8/6F7/yduP/AI5XoFFAHn//AApL4ef9C9/5O3H/ AMco/wCFJfDz
/oXv/J24/wDjlegUUAef/wDCkvh5/wBC9/5O3H/xyj/hSXw8/wChe/8AJ24/ +OV6BRQB5/8A
8KS+Hn/Qvf8Ak7cf/HKP+FJfDz/oXv8AyduP/jlegUUAef8A/Ckvh5/0L3/k 7cf/AByj/hSX
w8/6F7/yduP/AI5XoFFAHn//AApL4ef9C9/5O3H/AMco/wCFJfDz/oXv/J24 /wDjlegUUAef
/wDCkvh5/wBC9/5O3H/xyj/hSXw8/wChe/8AJ24/+OV6BRQB5/8A8KS+Hn/Q vf8Ak7cf/HKP
+FJfDz/oXv8AyduP/jlegUUAef8A/Ckvh5/0L3/k7cf/AByj/hSXw8/6F7/y duP/AI5XoFFA
Hn//AApL4ef9C9/5O3H/AMco/wCFJfDz/oXv/J24/wDjlegUUAef/wDCkvh5 /wBC9/5O3H/x
yj/hSXw8/wChe/8AJ24/+OV6BRQB5/8A8KS+Hn/Qvf8Ak7cf/HKP+FJfDz/o Xv8AyduP/jle
gUUAef8A/Ckvh5/0L3/k7cf/AByj/hSXw8/6F7/yduP/AI5XoFFAHn//AApL 4ef9C9/5O3H/
AMco/wCFJfDz/oXv/J24/wDjlegUUAef/wDCkvh5/wBC9/5O3H/xyj/hSXw8 /wChe/8AJ24/
+OV6BRQB5/8A8KS+Hn/Qvf8Ak7cf/HKP+FJfDz/oXv8AyduP/jlegUUAef8A /Ckvh5/0L3/k
7cf/AByufn8E+HfB3xe8Cf2Bp/2P7V/aHnfvpJN223+X77HGNzdPWvYK8/8A Fv8AyV74df8A
cT/9J1oAPgl/ySHQv+3j/wBKJK9Arz/4Jf8AJIdC/wC3j/0okr0CgAooooAK KKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKA
CiiigArz/wAW/wDJXvh1/wBxP/0nWvQK8/8AFv8AyV74df8AcT/9J1oAPgl/ ySHQv+3j/wBK
JK9Arz/4Jf8AJIdC/wC3j/0okr0CgAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiio554bW3luLiWOGCJC8kkjBVRQ MkkngADnNAEl
Fc//AMJ34P8A+hr0P/wYw/8AxVH/AAnfg/8A6GvQ/wDwYw//ABVAHQUVz/8A wnfg/wD6GvQ/
/BjD/wDFUf8ACd+D/wDoa9D/APBjD/8AFUAdBRXP/wDCd+D/APoa9D/8GMP/ AMVXQUAFFFFA
BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFA
BRRXGfFDxbf+CvBz6xpsNtLcCeOLbcqzJhs54Vgc8etJtLcaVzs6K+YP+Gjv F/8A0DdD/wC/
Ev8A8dr6S0fUotZ0Wx1OD/VXcCTqPQMoOP1qraXJvrYu0UUUhhRXE/FLxxL4 D8KDULSOCW+m
nWGCOcEoe7EgEHgA9+pFeR6P+0H4s1DW7Cyl0/RVjuLmOJykMoIDMAcfvOvN EfedkEvdV2fS
VFFFABRRRQAUUUUAFFIzBVLMQFAySegrmNG+IPh/xF4nuNC0e6N7NbQGaW4i AMI+YLtDfxHk
HIyPehauwPRXOoooooAKKKKACiiigAoryT4ufFHW/AOr6daaVa6fNHcwNK5u o3YghscbXXiu
V8IfH3XtX8XaXpurWOlR2V3OsDvbxSK6luFIJcj7xGeOmaIe/ogl7u59C0UU UAFFFeQ/Fn4t
6j4G1yz0vR7exnmeAzXBukdtuThQNrLjoTz7Um7DSuevUV4p8Lfi/wCIPG/j D+yNSs9Mit/s
zy7raKRXypGOWcjHPpXtdU1YlO4UUUUhhRRRQAUUUUAFFFFABRXmPxf+I2r/ AA/j0htKtrGY
3hlEn2pHbG3ZjG1l/vH1rZ+FvjDUPG/hA6vqUNrFcfaXh22ysq4ULjhmJzz6 0R95NroEvdtf
qdrRRRQAUUUUAFFFcz8QfEV34T8D6lrdhHBJc2wQos6kod0iqcgEHoT3pN2V 2NK7sjpqK8i+
EnxT1zx7rl/Y6pa6dDFb23nIbWN1JO4Dnc7cc167VNWsSne4UUUUhhRRRQAV 5/4t/wCSvfDr
/uJ/+k616BXn/i3/AJK98Ov+4n/6TrQAfBL/AJJDoX/bx/6USV6BXn/wS/5J DoX/AG8f+lEl
egUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR XD6x8W/B2lSp
bQ6n/a19LsENppS/aXlLNtCqV+Tdn+EsD7cjIB3FFeZv4i+JfidHGgeGLTw/ aOkoS81yUmVv
m2oREozG/VsMrKfUjG6T/hU39sz+f408Uar4hxL5gtd32W04TYv7pDwwyTuU rnPI65AOg1n4
jeDtA3jUfEVikiSmF4YZPOkRxnIZI9zLjBByODx1rn2+L1vqfmJ4S8M654gY SpDHcw2xitGc
7SQ0rcpgNzuUfgDurqNE8DeFvDnkNpOg2NvNBu8u48oPMu7Of3rZc8Ejk9OO ldBQB5u938Xd
YiumtdL8OaDG+Y4Y724e4nj+UfOGjzGeScZXtggjkyT+DPiDc28sD/FCQJIh RjHokKMARjhl
YFT7ggjtXolFAHnc3whsb1BBqfizxdqNmXVpbO71TfFMFYNtYbQcZA6EH0IP NSf8KS+Hn/Qv
f+Ttx/8AHK9AooA5/wD4QTwf/wBCpof/AILof/iaP+EE8H/9Cpof/guh/wDi a6CigDn/APhB
PB//AEKmh/8Aguh/+Jo/4QTwf/0Kmh/+C6H/AOJroKKAOf8A+EE8H/8AQqaH /wCC6H/4msOf
4MfD65uJZ38Oxh5HLsI7mZFBJzwquAo9gAB2rvKKAPOx8G9Asrh5dB1TxB4f SRFWWLS9RZFl
Kk4ZtwYk/MR1x7cnJH4C8Yac80Wj/EzUo7N33qmo2Md9Kp2gH965BxkZAAAG fXJPolFAHm5h
+MOmWc0cV14U1fyd5jlnjlinuBklQVXbGrEYGMgDuTyakPxC8UabcIuu/DbW YYJEYxvpc6ag
24EcMqABRgnkntwDzj0SigDh9G+L3gbW9ixa9BazGIStHfA2+zplSz4QsCei sehIyBmu0gnh
ureK4t5Y5oJUDxyRsGV1IyCCOCCOc1T1PQtH1vyv7W0qxv8Ayc+X9rt0l2Zx nG4HGcDp6CuH
ufgt4dt90/hq81Xw3feU8Yn0+9k+fOCN4YklQVB2grn16EAHpFFeby2nxW8P StPbappXiy1/
dl4Lm3Wyn+8QyxlfkGVIO5yenC8YaSw+L2kQ3v8AZfiyyu/DGrbwvkXqlony 7KGSVRgp8vLk
KvPBIBNAHolFV7G/s9Ts47ywu4Lu1kzsmgkEiNgkHDDg4II/CrFABRRRQAUU UUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAF
FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFeXfH/wD5JhJ/1+Q/1r1GvLvj/wD8 kwk/6/If61nU
2+a/NFw3+/8AI+Y7XR5rvQNR1WPJSxlhSUeiybwG/NQP+BV9MfAHxB/a3gD+ zpHzPpcxiwTz
5bfMp/Vh+Fea/BXQ08S+HvG+juBm6s4kQns+XKH8GAP4VW+A2uPofxEbSrgm OPUY2t2RuMSr
8y59+GH41uvicO6v/X9dTKW3N2f9f15H1RRRUVzcRWlrNczsEihRpHY9lAyT WbdldlJX0Pmv
9oPW31bxrY+H7YlxYxDKL3mkwcf987fzrzfSbKTTfH1jYykGS21SOFiOhKyg H+Vdr8PLeXx/
8bDq1ypaJLiTUZQf4Qp+RfwJQfhXMz/8lek/7Dx/9KKdFcrhfd6/iv8AghVd 1K2y0/Bn2lRR
WP4n8T6X4R0ObVtWmMdvH8qqoy8jnoijuTj+ZOACaTaWrGlfY2KK+UvEvxy8 YeIrl7bSZP7J
tZf3aQ2g3TNnGMyEbt3oU29aypbr4tWUL3VxL40hhhHmPJKboIoHJLE8Y+vF Nd2J9kfYVFfN
vgn9oLVba+jtfF2y8spGw15FEElhz0JVQFZR6AA8k5OMV9G21zBeWsV1bSpN BMgkjkQ5V1Iy
CD3BFNrS4r62ON+L3/JKtf8A+uK/+hrXjf7OH/I76n/2Dz/6MSqHxV+IXimT xN4h8MvqmdHE
5i+z/Z4vugggbtu7qPWuD8N+K9b8I30t7od79kuJY/Kd/KSTK5BxhwR1AqaT 15+jX6FVFpyd
n/l/kfc1FeX/AAR8Xa54v8Palda7ffa5oboRxt5SR4XYDjCKB1NN+J/xht/A 8/8AZWmW8d7r
JUO4lJ8q3U8jdg5JI/hBHBznoC5e7oxR97Y9Sor5Bfxx8UPGcrNY32t3Atzl k0iFkEYboG8k
Anpxuz0PvVW91r4n6Ckd7qN/4ssohIAsl5JcLGW6gfPweh4PXBo9Q9D7Ior5 1+H3x71NtVg0
3xa0VxbTvsW+SMRvExPG8LhSv0AI6819FU2rK4k9bHzd+0p/yMuif9eb/wDo deTXWmXOlWGj
asjMEvUeWJxxteORlIH0wp/GvWf2lP8AkZdE/wCvN/8A0Oqd74f/ALV/Zq0r U40zPpd1LLkD
ny2lZWH57T/wGs6btBy7P9WaTV5KPdfofQvhTW08SeFNM1hCP9Kt1dwOz4ww /BgRWxXin7Of
iD7X4b1DQpXzJYzedED/AM836gfRgf8Avqva62mve0MobW7CEhQSTgDkmvjH xbe3Hjnx9ruo
253RKJpkPZYIUOPzCj8TX078U/EH/CN/DvVbxH2zyx/ZoMdd7/LkfQEn8K8K +Gvh/wD4tv46
8RSp/wAw+WzgJH+zuf8A9k/Wsd3KX8qf9fl95rsku7/r+vIj/Z8/5KZ/24y/ zWvquvlT9nz/
AJKZ/wBuMv8ANa+q62lsvT9WYx3f9dEFFeffEn4qad4Ctxaxxi91mVN0Vruw qA9Hc9h7dT7d
a8CvPiR8R/GmoeTY3+pGQFpEtNHjaMovGf8AV/Oyjj7xOKzTvsaNW3Pr6ivj x/FXxQ8JzRXl
9qHiOz35SM6msjRse+FmBUn8MivXPhp8cYvEN3DoviVIbXUJMJBdp8sU7dNr A/dY9uxJxxwD
SV9iW7bns9FFc5418aaZ4G0F9T1El2J2QW6Eb5n9B6DuT2HqcAy2krspK7sj o6K+Rtc+Lnjr
xfqC2theXNkkso8iz0oMrk8gDcvzsTnkZwT2FMi8WfFTwdIuo3tx4hhhZhGf 7WileJz12/vR
gE4PTBxnBprzE/I7/wDaY/1Phr/euf8A2nXUfs9/8k0P/X/L/Ja8h+JvxEtv iD4d8PT+SLbU
bV50u4AcqCRHhlP904PB5BBHPBPr37Pf/JND/wBf8v8AJadNWUl/W6FUd+T+ u56rRVPVtVsd
D0q41PUrhLezt03ySN0A/qSeABySa+bPF37QHiHVLqSHw6F0qxBIWQosk8g5 GWJyF7HCjIP8
RqW+iKtpc+n6K+PUl+LckSyo/jZo2Xcrg3ZBHXOfSt/wj8fPEmkXcUPiAjVt PyquSipPGoGM
qwwGPc7sk46jOapLoTfqfUdcF8aP+SS65/uxf+jkrr9H1ew17SbfVNMuFuLO 4XdHIvf1BHYg
5BHYiuQ+NH/JJdc/3Yv/AEclRUVlZmlJ3mjyf9m3/kbdX/68B/6MWvpWvmr9 m3/kbdX/AOvA
f+jFr6VrWW0fT9WYw3l6/ogoooqCwooooAK8/wDFv/JXvh1/3E//AEnWvQK8 /wDFv/JXvh1/
3E//AEnWgA+CX/JIdC/7eP8A0okr0CvP/gl/ySHQv+3j/wBKJK9AoAKKKKAC iiigAooooAKK
KKACiiigAooooAKKKKACiiigAoqnquq2Oh6XcanqdzHbWdum+WV+ij+ZJOAA OSSAMk153J47
8U+NN9v8PtE8qxO5P7e1YGOH/louYkwS/KjBw2DwyDrQB6BrOuaX4e057/V7 +CytVyN8z43E
Anao6s2AcKMk44FcHJ8TdS8T3Bs/h3oUmpgOFk1a/VobKLlCeuGcgOcr8rDG QGFXNK+E+lrq
J1fxTeT+KNXOR52oD9zGCXO1IclQvz/dO4AjKha9AoA8zj+GWpeJ7gXnxE12 TUwHLR6TYM0N
lFy4HTDOQHGG+VhjBLCu40Tw3ovhy38jRtLtLFCiI5hiCtIFGF3t1cjJ5Yk8 n1rUooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACq99YWep2cln f2kF3ayY3wzx
iRGwQRlTwcEA/hViigDzu/8AhDpEN7/anhO9u/DGrby3n2TFony6sVeJjgp8 vCAqvPIIAFVx
rnxI8Il4ta0KPxVp6OpGo6WRHcbDIQd0GPncKVO1AAAOWPJHplFAHN+FPHnh zxnbh9G1GOSc
JuktJPknj4XOUPJALAbhlc8Amukrk/E/w58OeKrhL26tpLTVI3V49SsH8m4R lK4O4DDEBAAW
BwOmOtc3HdfEXwHsjv7f/hM9ETav2m0TZfxL+7XJj58z+PgbmPJZ1FAHqFFc 34U8eeHPGduH
0bUY5Jwm6S0k+SePhc5Q8kAsBuGVzwCa6SgAooooAKKKKACiiigAooooAKKK KACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACi
iigAry74/wD/ACTCT/r8h/rXqNeXfH//AJJhJ/1+Q/1rOpt81+aLhv8Af+Rx f7NH/H54j/65
wfzeuP8AibYS+B/jHJqNom1WuI9Ttx2JLbmH/fYYfSuw/Zo/4/PEf/XOD+b1 rftH6F9o0HS9
cjjy9pMYJWH9xxkZ+jL/AOPVrUfLKM10/r87EQSkpRf9aHs2n30Op6ba39s2 6C5iWaNvVWAI
/Q1wPxv8Qf2H8N7uGN9txqLC0T12nl//AB0EfjVb4DeIP7Y+HkdlI+6fTJWt zk87D8yH6YJH
/Aa83/aB1mXWfG+n+HbTMn2OMDYveaUjj8tn50qsfe5F1/LcKT05n0Ov/Z08 Omy8NX2vTJh7
+XyoSf8AnmmQT+LEj/gNeLT/APJXpP8AsPH/ANKK+vfDWjR+HvDOm6RFjbaW 6REj+JgPmP4n
J/GvkKf/AJK9J/2Hj/6UVV/38bf1sRb9zJv+tz7Sr5Y+PniiXWPHH9jRSk2e lqE2A8GVgCx+
oyF/A19T18R+NmmuPiLrxQO0z6nMECZJJ8wgAd/SsnrNJmq0i2fT/wAL/h7p /gvw9bTNbIda
uYQ13cMMsuefLU9lHHA6kZPbHe18gf8AF3/+p5/8m6P+Lv8A/U8/+TdaSd3c iKsrHpHx98A2
C6T/AMJbp1tHBdRyhb0RjAlVjgOR/eDYye+eelXf2dvE02oeH7/QbmQudPdZ LfceRG+cr9Aw
/wDHq8ivbH4qalaSWl/a+Mrq2kxvhnjunRsHIyp4PIBrvfgH4e8QaL40vpNT 0TUrG2ksGXzL
q1kiUtvTAywAzjPHtRSVrrowqO9n1PU/i9/ySrX/APriv/oa143+zh/yO+p/ 9g8/+jEr2T4v
f8kq1/8A64r/AOhrXjf7OH/I76n/ANg8/wDoxKVL+JL0/Rjqfw16/wCR9N18 06j8FPGeq+PV
u9XW2ubK+uvPvLu0uRiJGYllAcK2QOmFI5FfS1eZeP8A406P4MvG0y0t21TV E/1sSSBI4fZn
wfm6fKB9SKV0pKQ9XFo9E0/T7TSrCGxsLeO3tYF2RxRrhVFTuiyIyOoZGGGV hkEehr5V1L9o
LxvfQLHbtp2nuG3GW1ttzEeh8xnGPwzx1rK/4Tn4n+MH22epa3dvbDLLpURj Kg92ECjPTjPv
im7sSsit8WNCs/DnxH1Sx0+JYbQlJY4k6JvUMQPQZJwOwr628N3LXvhbSLpz l5rKGRj7lATX
xNruk6rouqyWutQSw37Ks0iysGf5xuBbk8nPOefWvtLwb/yJGg/9g+D/ANFr TgrU2vNfqKbv
UT8v8jwn9pT/AJGXRP8Arzf/ANDr0D4RadBrHwQg025GYLtLmF/ozuP615/+ 0p/yMuif9eb/
APodel/Az/kk+l/9dJv/AEY1TSV6Uk/P82VUdpxa8vyPE/hLqE3g74vJpl7h POkk02fPZ92F
/wDH1UfjX1lXyr8c9Jl0D4nDVbUGIXqR3cbr2lXhse+VB/GvpXw3rUXiDwxp 2sxkBLq3WVhn
7pI+Yfgcj8KqL5qab6af1+JMly1Gl11/r8Dw79pDxB5l7pPh2J8iJTdzKP7x +VP0DfnXa/8A
COnwv+zzfaZImy4GlTSzjv5jqWYfhnH4V5JpwPxL+PvnsDJZG8Mx7jyIfuj6 EKo/4FX0L8R/
+SbeI/8AsHzf+gms3pQb6u7/AK/roXvWS7f1/XqfPf7Pn/JTP+3GX+a19R39 5Fp2n3N7OcQ2
8TSuc4wqgk/yr5c/Z8/5KZ/24y/zWvoP4jyNF8NvEbICT9glHHupFaVW1C67 f5kUknNp9/8A
I+UrWLUPiX8R0SWUi51W7JZz83lJ1OPZUHH0r6/8OeGtK8KaRFpmkWqQQIBu IA3StjlnP8TH
1/DpXzT+z9Gj/E1WYDKWUrLn1+UcfgTX1ZTsowUUK/NNtkN1a299ayWt3BFc W8q7ZIpUDK49
CDwRXyR8XPAkfgXxWn9nh10y9UzWuTkxEH5kz1OOCD6EdTmvr2vDv2lIojoG hTHHmrdSIv8A
ulcn+QrKWjUkax1vFnoHwu8SyeKvh/puoXDl7tFNvcMerOnGT7kYP418+/HH xDLrvxGuLGNm
a300C1iQf3+C5x67jj/gIr1D9nGRm8C6jGT8q6ixH4xpXiF+PtXxcuFmO7zN dYNnvmfFazjz
Vorvr+X+ZnF8tJvt/wAH/I+nPhn4CsfBHhuBBAp1W4jV7y4IyxYjOwHso6Ae 2etdnLFHPC8M
0aSRSKVdHGVYHggg9RT6KUnzMIqyPkv40eBbfwb4oin02Py9M1FWkiiHSJwR vQe3II+uO1ev
/s9/8k0P/X/L/Jayf2koUbwpo85H7xL4oD7FCT/6CK1v2e/+SaH/AK/5f5LS pfDJdv8ANBV3
i/62Zxv7RniiR7/T/DEEpEMafarlVP3mOQgP0AJx/tCur+CPw9sNH8N2fiS8 tkl1e9TzYpHG
fIib7oX0JHJPXDY6Zz458bJGk+LOs7j93yVHsPKSobVPiulpClovjRbZUURC IXQQJjjbjjGO
mKVJ2i31ZVRe8l2PsWvKPjb4BsNc8LXniC2to49XsE85plGDNEv3lb1wOQev GO9eL/8AF3/+
p5/8m6jng+LVzBJBcReNZYZVKSRyLdMrqRggg8EEdqUldDi7M7n9nLxNNHqm oeGppCbeWM3U
Ck/ddSAwH1BB/wCA16b8aP8Akkuuf7sX/o5K8X+D/hfxNpPxO0q6vfD+q2lq BKsk09nJGigx
tjLEADnAr2j40f8AJJdc/wB2L/0clVW+BP8ArcVHSpbzPJ/2bf8AkbdX/wCv Af8Aoxa+la+a
v2bf+Rt1f/rwH/oxa+lauW0fT9WZw3l6/ogoooqCwooooAK8/wDFv/JXvh1/ 3E//AEnWvQK8
/wDFv/JXvh1/3E//AEnWgA+CX/JIdC/7eP8A0okr0CvP/gl/ySHQv+3j/wBK JK9AoAKKKKAC
iiigAooooAKKKKACiiigAooooAKKKw/FHi7RfB2lvf6xexwgIzRQBgZZyMDb GmcscsvsM5JA
5oA3K83vviVea7q0mi/DvT4NauocfatRncpZ2n7wLyeDJkBj8h6DK78ECmdK 8TfFK4RvEFtJ
ofg5LhnXS33R3t6EI2ef/cQsGOBg8d/lkHpGlaVY6HpdvpmmW0dtZ26bIok6 KP5kk5JJ5JJJ
yTQBwenfCr+0byDVvHusT+JNSjwyW7/u7OBsJkLEMA8pgnAVgfmTNekUUUAF FFFABRXO+O9e
uvC/grU9aso4ZLm1jDIswJQksByAQe/rWpo15JqOh6ffTKqy3NtHM4QYALKC cZ7c0LW/kD0t
/X9bl6iuP1XxXfWPxO0Lw1FFbGy1C2lmldlbzFKAkbTnGOO4NcrrXxU1fRvi yfDslnZHQo57
eGa52P5qeagIJO7H3j/d6ChatJdf87A9L+R61RSEhQSTgDkmvLvh98T9S8Z+ OtW0qS1tI9Kg
ikltJY0cSSKJAikksQcjPQDmhauwPRXPUqK4+z8V31x8VdR8LPFbCxttPS6S QK3mFyVBBOcY
59K7ChbX/rewdbBRRXm2seK/Glx8SL3wt4ai0AJbWaXRk1JZskHAIyh9SO1K +qQdLnpNFeZ6
rrfxT8N6dNq+o6d4W1CxtR5lxBp73CTGMfeKl+Bgc9D9K7rw/rlp4k0Cy1ix LfZ7uISKG6r6
qfcHIP0p9ANKiiigAorF8W6+vhbwpqOttD5/2SLesW7G9sgAZ7DJFc5ol78S tT8OPfzJ4Vju
bm3imsUAuNq7sFhLyf4TxtJ574o3uHY72iuM8QeK9T0bxl4S0RIrRo9XaVbp irEqUUH5DkY5
J6g12dHS4eQUUUUAFFFFABRRRQAUUUUAFFFFAHH+LPh3pfieddRt5p9H12Lc YtV08+XNkpsw
5GC64xxkHAwCATnn08beJfAkrWnjvTp7/TFlIj8R2MSlChZApmiX/V43kZ74 woflj6hUc8EN
1by29xFHNBKhSSORQyupGCCDwQRxigCOxv7PU7OO8sLuC7tZM7JoJBIjYJBw w4OCCPwqxXm9
98NbzQtWk1r4d6hBot1Nj7Vp06F7O7/eBuRyY8AsPkHQ4XZkk6Hg74iW+uXn /CP63D/ZPiy3
3Jc6dICA5UAl4m5DKQdwGScZPzKNxAO4ooooAKKKKACiiigAooooAKKKKACi iigAooooAKKK
KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACvLvj/
AP8AJMJP+vyH+teo15d8f/8AkmEn/X5D/Ws6m3zX5ouG/wB/5HF/s0f8fniP /rnB/N69n8aa
CvibwbqukEAvcW7CPPaQcof++gK8Y/Zo/wCPzxH/ANc4P5vX0LW1VcyS8jOm 7Sb8z5a+A3iO
Pw/4xv7G+kMMF1auW3cAPFl+f+A76Z8NbeXx78bZNaukLRRTSajID2wcRr+B Kf8AfNYXxa0J
vDXxK1OOEGOG6b7VCVOPlkzuH03bhXr/AOzr4f8AsPhO91yVMS6jPsjJ/wCe ceR+rFvyFKm+
a030X4/1+QVFy3gur/r8D2avi2f/AJK9J/2Hj/6UV9pV8Wz/APJXpP8AsPH/ ANKKUP40f66o
c/4Uv67n2lXxv8VdMl0H4pawAuwSXH2uIjuH+bI/EkfhX2RXmPxh+Gr+NtLi 1DS1T+2rJSEV
jjz4+pTPY55GeOSO+RLvGSmuhSs04s7jwxr1r4m8N2GsWjhormIMRnJRv4lP uDkfhWtXxn4V
8d+KfhrqNxa24Mab/wDSNOvY2278YyV4Kt05GM4GcgV6TL+0zKYXEPhNElKn Yz6gWUN2JAjG
R7ZH1q5NPWJEU1oz2Lxj4y0vwPog1TVfOaJpFiSKBQ0jsfQEgcAEnntVfwh8 Q/DvjcOujXMz
3EcYkmglgdGiBOMMcbSfoxr5X1vxB4q+KfiWBJY3vLtvktrO1QiOId8DJwO5 Zj25OBx9NfC7
wEvgPwx9mmZJNSumEt3InTOOEB7hf5knvRFaNyCT1SiHxe/5JVr/AP1xX/0N a8b/AGcP+R31
P/sHn/0Yle6/EPSbjXPh9renWkZkuJbZjGg6sy4YAe5xivlDwD42uvAHiQ6p BardI8TQT27u
U3qSDwcHBBA5we9TTdqjv2/zKmm6at3/AMj6/wDE+pyaN4V1bU4hmW1tJZk4 z8yqSP1r5A8B
6BH418fWGmahcuI7qR5J5N3zuApdgCe5x196+jvBHjq2+Leg67Yz6YbBVj+z yILjzSySKwzn
auOhr5s1fSde+G/jIRO0lrf2Uvm21yq/LIoPyuueCp9PqD3FOPu1fe7f1+gP 3qdon19o/g3w
14fML6VoVhazQpsSdIFMoGMHMh+Y/Unmtyvnex/aXvI7ONNQ8MQXFyM75YLw xI3PGFKMRxj+
I/h0rB8QfGHxl4+n/sLQrI2MV2di29lukuJBjkGTjjgk7QvGc5GaHfpqJW66 HNfFjWoNe+Je
sXlrIslurrDG69GCKFJHqMg819YeDf8AkSNB/wCwfB/6LWvkDxl4J1TwPeWN pqpj8+6thcER
nKoSxBTd0JGBnHHPfqfq74ZajHqnw10C4jfdts0hbnPzINh/VacElTa81+op u9RPy/yPGv2l
P+Rl0T/rzf8A9Dr0v4Gf8kn0v/rpN/6MavNP2lP+Rl0T/rzf/wBDr0v4Gf8A JJ9L/wCuk3/o
xqVH+HL1/Vjq/FH+uhk/tB+H/wC0/A8OrRpmbTJwzEDny3wrfrtP4Vw/gnx6 NJ+BHiCz84i9
tJDBbDPIE/Qj6HzD+FfQut6XDreh32l3AzFdwPC3tuGM/h1r4Yvba5069utO n3JJDMY5Uzxu
UkdPzqF9qHf+n/XmX/LLse9/s3eH9lvq3iKVOXYWcBI7DDP+uz8jXqnxH/5J t4j/AOwfN/6C
aX4e+H/+EY8B6RpbJtmSAPOP+mj/ADN+RJH4UnxH/wCSbeI/+wfN/wCgmrxG zXZEUN0+7Pnv
9nz/AJKZ/wBuMv8ANa+lvEumnWPC+q6aAS11aSxLj1ZSB+tfNP7Pn/JTP+3G X+a19V06i5op
eX6sVN2k35/5Hxv8KteTwr8StOnvT5MDu1rcF+Ngb5cn0w2CfpX2RXzb8Zvh TeWWp3fijQrZ
ptPnzNeQxDLQP1Z8d0PU46c9qxvBnx11/wAMWMWn6hbR6vYwrtiEshjmQcYX zMHKj0IJ98DF
KMuaNnuglHlldbM+q6+b/wBo3xDBea3pmg28odrJGmuAP4XfG0H3CjP/AAIU zXf2j9YvbEw6
No1vpkzAhp5ZvtDL6FRtUA/UMPauS8B/DrXPiNrZvbo3Caa0pe81GXJMhJyw Qn77nnnnHU9g
VyuUrdCuZRVz3L4C6TJpvwzhmlUq19cyXIB/u8IPz2Z/GvA/iVp8/hn4qars Uoftf2yAleCH
O8EeoBJH4V9iWdpBYWUFnaxrFbwRrFEi9FVRgD8hXmnxk+Gs3jXTIdS0pVOs WKlVjJA+0R9d
mexByR25I78OpL31NdP6/QUF7ri+p6BoOsWviDQrLVrNw8F1CsikHOCRyD7g 5B9xWjXx14L+
JHiT4b3k1isXmWglxc6ddqV2MCN23uj4BHceoOBXc6p+0pqNxYvFpfh2Czum 4E010Zwo9lCL
z6ZOPY05NbxFFNaMtftJa7C76PoEbhpYy13MoP3cjamff73+TXW/s9/8k0P/ AF/y/wAlr5+1
/Q9fm0KPxnrskpbVbrbEZwfMmG0kyey8AL7dMADP0D+z3/yTQ/8AX/L/ACWi mrKSe/8Aw36C
qO7jbb/gM8p/aA0h7D4jNfbMRahbJIrerKNhH/jo/Ovd/hV4ht/Efw70qaKT dNawra3Ck8q6
ALz9Rg/Q034neAYvHvhr7NGyRalbEyWcz9A3dT/stgfQgHtXzJpGueLPhZ4k mSNJbG7Uhbi0
uUzHMoPG4dx1wynoTg81NNpJwZc1dqaPtGsrxH4gsfC2gXes6kzi2tl3MEAL MScBVBIBJJA6
14jD+0zKsEYn8KI8wUB2S/KqzdyAYzge2T9a838XePvE/wASb+2tLhNyB8W+ n2UbFS54zjJL
N2/PAGTQ77IFbdn0t4R+KvhfxpdJZ6bPdR37qzfZZ7dgyqvUllygH/Aqr/Gj /kkuuf7sX/o5
KzPg38NpvBWlzahqqqNYvlAaMEHyIxyEz3JPJxxwB2zWn8aP+SS65/uxf+jk orJJfcOi25r1
PJ/2bf8AkbdX/wCvAf8Aoxa+la+av2bf+Rt1f/rwH/oxa+la0ltH0/VmUN5e v6IKKKKgsKKK
KACvP/Fv/JXvh1/3E/8A0nWvQK8/8W/8le+HX/cT/wDSdaAD4Jf8kh0L/t4/ 9KJK9Arz/wCC
X/JIdC/7eP8A0okr0CgAooooAKKKKACiiigAooooAKKKKACiivL9U8Wa748v LvQPAaeTpscq
2974mLjZFwS6wLwXbGAGU/xfwgrJQBseLPHlxp2sL4a8L6X/AG34lkiaVrcS BI7RNuQ8rHgZ
JXC5GQRyNy7o/C/w2hsL1Ne8T3kmv+JGRS1xdYeK2YOXxboR8gDHg9sfKEBI rc8J+C9C8Fac
1notp5Xm7TPM7F5JmUYBZj+JwMKCTgDJroKACiiigAooooAKKKKAOI+L3/JK tf8A+uK/+hrX
Q+F/+RS0X/rwg/8ARa0vibRU8R+GdS0d5PLF5bvEHxnYSODjvg4NcDoHjDXv COi2ugeIfBXi
C6urCNYI7rSLb7VDPGowrbsjBwOh57nGcAjpzedv1BrZ+v6E/iL/AJL54Q/6 8Ln/ANBauY13
QT4k+IPxJ05Bmc6bbSwY6iRERlx+Ix+NdV4a0zW/EvxCPjbWNLk0mzt7M2mn Wdwf37KSSZJF
/gOCRt68+2TN4f02+h+Nni2/lsrmOyntLZYbh4mEchCLkK2MEjHakovReUv1 aHfWT/w/oV9Q
8ZTXvwSt9WtjnUtTt0sogp5Nw58o49wdx/CszwbpMWg/Gm80mDHl2nh6CIH1 wUyfxOTVfQ/C
2sw/EsaFPYzr4Z0vUJtYtbhoz5TtIq7I1bGPlZmOM+tdHp2m3yfHjWNReyuV sZNJjjS5MTCN
nDLlQ2ME8dKpO8lLvd/+Sv8AVslq0XHtb/0pfokVtM/5OJ1v/sCxf+hJXpZI AJJwB1JryTU7
++8M/GrU9bfw1r+pWM+mx26SabYtMN+VJ5yB29a6K0+JQvbyC1PgjxlCJpFj Mk+lbY0ycZY7
uFHc+lTHWKS8/wA2N6Sbfl+SN6Lxp4VuJ0gh8TaNJNIwRI0v4izMTgAANknP avNdQ8Q/8I58
e9Xuv7H1bVPM0mKPytLtvPkXlTuIyMDjGfcV6VF4L8K286Tw+GdGjmjYOkiW EQZWByCCFyDn
vXMadpt8nx41jUXsrlbGTSY40uTEwjZwy5UNjBPHSn9qPz/Jg/hfy/NFHXvH es+IdFu9G0Hw
H4mW/vongWTUrMW0MYZSCxcsRkdgcZPfsed8b+GLjwr8MfBegw3hS8h1eEfa Y/4JX3sWX6M3
H0r3OvPPi1pt9qVj4cWxsrm6aHW7eWQQRM5RBuyxwOAPWjqvNr8w1s/JP8jI 8X6RYfC/wfcz
eEoGttW1ieGx+1SStI+9ixL5YnBxu6YGSD2qXUvg7o+m+Hp9Q0u6v4fE9tE9 wmr/AGuTzZZg
CSW524Y5BwM479c9P8SPCtz4u8IyWVhIseoW8qXVozHA8xOgJ7ZBI/GuZ1Hx v4q1nQJtCtPA
mt2+v3Mb20ktxCFsoiQQziYnDDHI7E9z3l3s7b9Pu0/G/wCo1a6vt1/W/wAv 1Mbxa9l48+Ad
v4q1O2Eup2lsTHKGZAkvmKkjbQQDnb0IOO1J4r8M6P4c/Z8u30qz+ztfQWc9 wfNd97lo8n5i
cdegwK6HxB4RutF+Atx4aso5b68htFTbAhdpHMgZtqgZIyTjjpR490vULz4F Lp1rYXU999kt
F+zRQs0mVMeRtAzkYOfpTqW9/l7r82FO94X8/wBCp4o/5KF8L/pN/wCikrmd c8UeEfEXj7W7
bx7q88ek6ZP9msdLQT+W7rkPK5iXJOc457+ldj4j0vUJ/HXw5uIbC6kgtBL9 pkSFisOY1A3k
DC8+tVjFrfw38c61qNvoV/rXh7XJhcN/Z0fmz20+GJ+TOSCc88Dkc5GDT317 y/T/AIJK+FW7
R/X/AIBi+B/FHh/TfiXZ6B4M1a4vPDupQSZspRLtsplBfMZkAOGAORzyfpin 4on0AfE7Vovi
jBqDaawH9jPmX7MiADfgRnO4/LnGec5xxXpPh3xJ4n8Sa+0w8PSaP4ciQgtq kRS8mkx/CgbC
KCepBzjg84GTqut+JPD/AIi1a117QNQ8S+Gb8Zs/7OsknaEfxRSRgDI56sT0 HXJwn0v2e/8A
W/byGutvLb+vv8zQ+G+nadY2t8dB8UDV9BldWs7Tf5hsARkx7ixIHI+UgEd+ ck9zXlfw78Oz
jx1q/im18Py+HNGurZbe3sJkEUkjBhmRoh/q/unjjrkZzmvVKb6CW7CiiikM KKKKACiiigAo
oooAK5/xX4O0vxhZ28V/58Fxayia1vbR/Lnt3BByj4OM4GeOwPUAjoKKAPL9 L8Wa74DvLTQP
HiedpskrW9l4mDjZLwCizryUbGQWY/w/xANJXpkE8N1bxXFvLHNBKgeOSNgy upGQQRwQRzmo
76ws9Ts5LO/tILu1kxvhnjEiNggjKng4IB/CvL7nTNd+Em7UdFmn1bwWkryX WkFQ01hG2CZI
nJyyqdxKnAAJzklpFAPWKKp6Vqtjrml2+p6Zcx3NncJvilTow/mCDkEHkEEH BFXKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKK
ACiiigAooooAKKKKACquoaZYatam11Kxtry3JDeVcxLImR0OGBGatUUAZ2ma Bo2itI2laTYW
BlwJDa2yRb8dM7QM9TWjRRQBmal4c0PWZkm1TRtOvpUXar3VqkrKOuAWBwKu Wdna6faR2llb
Q21tGMJDDGERR14UcCp6KACsU+DvDBvDeHw5pBujJ5vnfYYt+/Od27bnOec1 tUUAFFFFAGPr
nhXQPEsRj1nSLS9OwxiSWMeYinsrj5l/AiuX/wCFJfDz/oXv/J24/wDjlegU UWAzdH8PaN4f
gMOj6XaWKMFD/Z4VQvtGBuI5Y+5yea0qKKG7hawVyOt/DDwX4ivzfanoMEl0 2d8kTvCXJOSW
8tl3H3OTXXUUWC5z/hnwR4d8H/af7B00WhudvmnzZJC23OOXY46npWlqui6X rlqLbVtOtb6E
HKpcRK4U4xkZHBwTyOavUUPXcFpsef8A/Ckvh5/0L3/k7cf/AByut0bw5ovh 2AxaPpVpYqyq
rmCIKzhem5urHk8kk8mtOii4GdqegaNrTRtqukWF+0QIjN1bJKUz1xuBx0FT 6fpthpNqLXTb
K2s7cEsIraJY0BPU4UAVaooAzdS8O6JrUqS6ro+n30kY2o11apKVHoCwOBVm x0+y0u0W00+z
t7S2TJWG3iWNFycnCgAdas0UAFY0/hDwzc3j3lx4d0iW6d97TSWUbOzepYrk n3rZoo8wCorm
2gvLaS2uoI54JVKSRSoGV1PUEHgipaKAMrT/AAx4f0i6+06boWmWVxtK+bbW kcb4PUZUA4rV
oooAK5XW/hr4N8QzedqXh+0eYu0jSwgwO7N1LNGVLH65rqqKLBc4rT/hH4C0 y6+0W/hu2d9p
XFy73CYP+zIzLn3xmuzjjSKNY40VEQBVVRgADoAKdRQAUUUUAYPiHwX4b8VL jWtHtbt8BRMV
2ygA5AEi4YDJPGcc1k6b8JPAelXYurbw5bNKBgfaHknUe+2RmGffGa7Sihab A9dyjqWjaXrM
SRapptnfRxtuRLqBZQp6ZAYHBp+n6Xp+kW32bTbG1srfcW8q2hWNcnqcKAM1 booAKz9V0LSd
dgWHVtMtL6Nc7FuYVk2EjBK5HB9xWhRQ1cDz/wD4Ul8PP+he/wDJ24/+OV02 g+EfD3hiNV0b
R7SzYJ5ZlSMGVlznDSHLNz6k1tUUXCwVXvbG01K0ktL+1guraTG+GeMOjYOR lTweQDViigDM
03w5oejTPNpejadYyuu13tbVIiw64JUDIrToooAKKKKACiiigArz/wAW/wDJ Xvh1/wBxP/0n
WvQK8/8AFv8AyV74df8AcT/9J1oAPgl/ySHQv+3j/wBKJK9Arz/4Jf8AJIdC /wC3j/0okr0C
gAooooAKKKKACiiigAooooAKjnnhtbeW4uJY4YIkLySSMFVFAySSeAAOc0Tz w2tvLcXEscME
SF5JJGCqigZJJPAAHOa8r/0z4y6j/wAt7PwBay+8cmsSKfwKwgj65H97/VgA X1T4xXkwtby+
0jwLDviE8B8qfVXwVbGRxCMkYIOehBPEfpmlaVY6HpdvpmmW0dtZ26bIok6K P5kk5JJ5JJJy
TViCCG1t4re3ijhgiQJHHGoVUUDAAA4AA4xUlABRRRQAUUUUAFFFFABRRRQA UUV45ca3ql98
O/HviiDVL1I57l000pOwEMURCBo8H5dx3E4qXKyb7K40r283Y9jorH8KTS3P g/RZ55XlmksY
XeR2LMzFASST1NUfGlxpdvb6WdU1zUdJVr+NYWsXZTPJziJ9qtlD3BwOOtXJ csuXzsTF3jc6
aiqOsazpugabLqOq3kVpaRD5pJDj8AOpPoBkntXMQfFzwJcWFxeReIIjDblR IDBKHG44BCFd
xGSBkAgZGetJa6IZ2tFeZa94kOkfGvT1vdXe00YaI88ySTlIN29gGKk43dAO /QV0nh74j+Ef
FN+bHR9aiuLrbuETRvEzDvtDqN34ZoWu39av/IHp/Xkn+p1NFeR+K/ilYaN8 VtM06bW3g0iz
jk/tKJYHIE21tgJC7mHzDgZGcHqK9G8P+JtH8U6e99o14Lm3jlMLt5boVcAE gqwBHUdqFrHm
QPR2ZrUVkeH/ABRo3iq0nutFvRdQQSmGRxGyYcAEjDAZ4I5HFSaF4g0vxLp5 v9IuvtNqJGi8
zy2Qbl6gbgCfr0oA06K4y6+LHgWy1VtMn8RW4uVcRttjkaMMfWQKUHXk5wOc 4xV/xje6T/wh
lxeX+u3mmaa4jb+0dNlIkUFhtKMgY4OQOAeDSvpcdtbHSUVl3ut6VoOgrqWo 6gkFjHGp+0Tt
y4xx7sx9AMn0rnoPi54EuLC4vIvEERhtyokBglDjccAhCu4jJAyAQMjPWqtr YS2udrRXm/xB
1q40vxx4FCalLZ2E1xObsCcxxuiqh/ecgEDk89Oa2dM+KPgrWdYXSrHX4JLx 2KIjRuiu2cYV
2UKxPbB57ZpLVf10B6HX0V5X8TviLB4b8SeH9Li1d7QC7jm1SNIWJ+z5BHzB TxwchTkjg8Gv
SdM1K01jTLbUbCbzrS5QSRSbSu5T0OCAR+IoWqv8v6/roD0di3RXnnxov77T vAQm0++urKdr
2FPOtpmjcKScjIOacvwsyoP/AAnnjnkf9Bj/AOwpLW7/AK6f5g9LI9BorkbD TLL4eaXqGp6j
4j1/ULPajSyanO135IBIyoVcgHdzx2HpWvdeJ9FsvDQ8RT38a6SYllFyAWBV sYwAMknI4xmm
7Brsa9FeW/Fj4hRaJ4SsjpOqS2l9qRSSE/Z2V2tz98/MvyHBHo3pXcaX4s0L VvDv9vWupRHS
13brqYGJV2nBzvAI5o6N9g6pdzaorj9G+KXgrX9STT9O16F7qThEkiki3nOM KXUAnngA5Nbu
ueIdK8OW0Fxq119ninnW3jby2fdI2cD5QcdDyeKANOiuN/4Wv4F/tcaX/wAJ Ham5L+XkK/lZ
/wCuu3Zj33Yrb8QeJ9F8K2Avdb1GKzgY7VLZZnPoqqCzdewOOtHS4dbGvRXO eHPHnhjxbLJF
oerw3U0Yy0RVo3x6hXAJHI5AxTNIuNLfxxrsNtrmo3WoRpF9p0+Z2MFqCvym MFQAWHJwTR1s
HS501FcjrfxQ8GeHdSfTtT12KK7QfPHHFJLs9mKKQD7Hmumsr601GyivbK5i ubWVd0c0ThlY
exFHS/QNnY83v/D2u/DrWLnWvBGnf2lol5vlv/D6yCPypApPm2/BxnABQAno ACNvl9x4Y8T6
X4u0OHV9In823k4ZW4eJx1Rx2YZH5ggkEE4c3xa8C2+nw30viCJYZnZEHkyl yQSCdgXcBkEZ
Ix71zV3b7Lp/iN8MpotQWc/8TbSYiQl+o5LBcZScZJxjJznBJZZAHpoz1mis fwx4n0vxdocO
r6RP5tvJwytw8TjqjjswyPzBBIIJ2KACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKAC
iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArz/AMW/8le+HX/c T/8ASda9Arz/
AMW/8le+HX/cT/8ASdaAD4Jf8kh0L/t4/wDSiSvQK8/+CX/JIdC/7eP/AEok r0CgAooooAKK
KKACiiigAoorzPxRfzeP/Er+BdC1OS30+2Rn8Q3luhJC5AFsknQO3zbgewI5 2uhAK88N98XN
ZlgcyWvgKwuCjGOT5tZlRscMp/1AYdQeccfN/q/UIIIbW3it7eKOGCJAkcca hVRQMAADgADj
FV9K0qx0PS7fTNMto7azt02RRJ0UfzJJySTySSTkmrlABRRRQAUUUUAFFFFA BRRRQAUUUUAc
34+1pvD/AIF1bUIji4WAxwepkf5Ex75YVy/ijRf+Ed/Z+u9JIAe201Vkx3ky C5/FiTXS+L/D
d14mn0OASQrp1pfpeXiuzBpAgOxVAGCCx5yR0qx420O58SeDNU0ezeGO4u4f LjaYkIDkHkgE
9vSomm6cl1f6L/gsqL9+Pl/n/wAD8STwb/yJGg/9g+D/ANFrXG/Gf/kH+F/+ w/bf+zU/TLD4
taVpVpp8DeCWhtYUhRnN0WKqABnAHPFLrvhTxp4r0jS4tal0CO9sdXivP9Ca YRmFByPmBO/J
PoPetZPmnzLun+JnBWhZ9n+RB4ugh1z40eFNF1CPztPgtJr0QPykkoyBkd8b Qef8RVT9oHSL
G58DR6pJCgvbS5jWKbA3FWJBTPpznHqK1/iFZWOoeItBistaXSvGERkk0p5I WeOYbTvjcgFQ
Djvz6A5xXDfFjTPGN74atpPFWp6SpN5FDZafpCSbZpWJBdzJ8xIXcABxz27z H7K8/wBf6X/A
LvaTb7fp/TOg1/SbPV/2g/DsV9BHPFDo5nEci7lLK0m3I9ic/hVv4q28MHir wFqccareDWY7
fzRwxjYjKk9x/ifWuguPCd/L8VNO8ULLbCxttMazeMs3mlyzHIGMY5HeneOf Cl94mvfDU1lL
bRrpeqR3kwmZgWRTyFwDk/XH1prTl8nf/wAm/wAiej9Lf+S/5mH4i/5L54Q/ 68Ln/wBBasSb
U/8AhBda+JdpnZHNajVbME/xyAo3/kRlGPaus8aeEtf1DxTovibwzdadHqOn JJC0Ooh/KdHB
5ymTkZPHHXrxg5/jn4caj4w1rw/qQubSBoESHVUDOBNEHVyqcZI3BsZx2qEr pRfmn6Nt/wCR
TdpN+j+7+mcVoTP8L9M8XaTJIVd9Dt9QgDHpMyeU+B/10YfpXU6ta3Hgn9nO S3tj5N0lgiyF
eCHlZQ/4/O1aPj/4cXXi/wAVaFqVtcW0NrbYi1BJCQ00IkVwq4BB5B4OO1dx rGk2muaPd6Vf
IXtbqIxSKDg4PcHsR1FOd5Qfd/kr2/B2+QQ92cey1++1/wAvxPLvDt54psfB lnpFn8KIJ9Le
2UMG1q223AZRlmUryW6nPrWFq2k69of7PWu6drtkbIxXqm0t2nWYxwNLGwXc pIOCWHb6V1un
+Gvif4c0z+wtH1vw/dabEvl2t3fxSi5hTGAAqgodvbOe3bgXdd+H+qX3wtu/ DEWty6jqVw6S
Pe6nK+GYOrHH3iq4HCjOP1p1Nbtdf81/X5Cp+64p9P6/r8TG1qCHXPij4H0X UI/O0+DTWvRA
/KSShSBkd8bQef8AEUftA6RY3PgaPVJIUF7aXMaxTYG4qxIKZ9Oc49RWh410 yzuNU8MWdrra
aX4yto2bS5Ghd45sJh0Y7cBTjvz7HOK434saZ4xvfDVtJ4q1PSVJvIobLT9I STbNKxILuZPm
JC7gAOOe3em7yVv5v/bv6X/AFD3dX2/T+mdF8U9NttX8afDuwvI1ltpbuUSR sMh1AjOD7HGK
s/HSyto/h3FdpAiT2F3C1s6jBi5xgY6DGOB6D0roPFHhO/1vxX4R1W2ltkg0 eeSS4WVmDMGC
gbQAQT8p6kU/4leFb7xl4Nm0fTpbeK4eaOQNcMyphWyeVBP6VMdl/iv+KHHp f+W35nP/ABPJ
bxH8PSep1hD/AOg1v614/wD7F1afT/8AhEfFd95WP9IsdN82F8gH5W3DPXH1 BqLx/wCEdT8R
2ujXOjXVpBqmkXiXUH2sMYnxjIYrkjoD07Y4zmuo0n+0/wCyrf8AtkWg1Hb+ /wDsZbyt2f4d
3OMY60LZ+v6L/IS6X7fq/wDM82+M122pfCi1u1guLNri7tnEVzHtliJJ4Zex HcVqr4S+Ie0Y
+J/b/oAW/wDjWh8S/CuoeMPCf9l6ZLaxXIuY5g1yzKmFJP8ACCf0qgB8XwAP +KG4/wCvukuv
r+iG+np+rOi0HRtYtNNurTxHrq68ZyQGaxjtwqEYKFVJDA89fWvE9BtLW8+J MfgK61YT+FdN
v5rixiKnbPMArfZyx4IQluO/P94Y9PaD4n3Wi6nbXUvhaG7mh8u0ms3uF8ti cMzFlPQdMDrV
O++FVuPhxZaBpkyQatp7rd2t+cqftQOS5IBOCeO+AF9BTTtLm/r+lv6g9Y8v 9f09vT5Efx0/
5J6n/YQt/wCZrP8AjLc3Ml94O0iGw/tKG7vmkewM6xLctGF2oWYYAO49a6fx j4U1Xxl8Pl0m
5uLO21keXN5kZZoPOQ56kA7Tz24z0OKrat4L1rxh4UtrfxHeWNlr9lci4s73 Sg7JEy42nD4J
J7j2BFK1vk7/AC0/yDez8mvzOb8XL428WeGJdGk+F8duQAbWca1bsbZ1+6yD AxjpwRxxTfi1
bXt18L/C1rrI230t/Zx3Y3A4kMbB+QSDznoa2pNC+KWs20Omat4g0TTbPK+f e6Qswu5AOwLA
KpbuVxjsMcHU8eeDb3xLoGj6bp1zGGsL+C4aS8lYl0jBB+YAkscjr155qvXu vzD/ACf5EXxM
0bTo/hJq9lHZwpb2dput41QYiKfdK+h/xNcrd+H/ABPf6R4C8X6BDa6ne6bp sQexu3C+ZvRc
upJADck5JHQdelekeMdGuPEPg/VdItHiS4u7doo2lJCAn1IBOPwrkrz4d6vH p3hbUNG1K1tf
Eug2cdqGlVntrhQoVkbjcFPOCBnnoDghLdvzX/twNaJev6GfpvjDRdV8eaW3 ivwhqPh/xMrS
W9hcTFzFIPulQ42h8ljjKlRng81Ba3k2n/Ej4o3ttnz7fTYpY8D+JYSR+orb j8IeLfEfiDS9
Q8aX2jpa6TOLm2tNJSQiWXsztJyMYHAznnpWlpHg+7s/iB4o1y7e1l0/V4YY o4gWL4VdrBwR
jB9iaTV/ul+K/wAxp2v8vz/yKXwg0ewt/hnYTrDHLNqSNNeSuoZp2ZmyGPcA cYPv71n/AAuR
dM8T+OtBtBt0yy1BZLeMdIzIDuUDsBtGKWy8H+PPB8NxpXhDVtFm0V2Z7dNW STzbQsSSqFAQ
wyc5bv2656fwV4Ni8H6ZdRNeSX+oXs7XF7eyLtaaQ+3OAPTJ6n1py15pLqrf l+X/AAxNrJR8
/wDP8zjvgDpVpb+CrnUkhT7XdXkiyS7fmKrgBc+nU/jU/wANYIrD4jfEKwtU WK0juoHSFAAq
llcnAHSuj+GvhW+8G+EhpOoy28s4uJJd1uzMuGORywBz+FJ4Y8KX2i+NvFet XMts9tq8sL26
xsxdQgYHcCAB17E1X2v+3f8AIctU/wDFf8WYfivSm8B+ID4+0K2u3tJXx4g0 6027ZosN/pIU
9HRiCcdckkqC7H0DStVsdc0u31PTLmO5s7hN8UqdGH8wQcgg8ggg4Iq5Xleq 6VffCvVLjxH4
ctpLnwrcP5mr6NF1tT3uIB0AA+8vQAdlAMcgeqUVHBPDdW8VxbyxzQSoHjkj YMrqRkEEcEEc
5qSgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKKK5fxP8Q/C3hGKb+1NWgF1Fwb KFhJOWK7lGwc
rkYwWwvIyRmgDqKjnnhtbeW4uJY4YIkLySSMFVFAySSeAAOc15vL4m+Ifip5 4vC/huPQrNUd
Pt3iFWjlZ9q42RLkqQWYgkOpx2IKmS3+DejX0sl74wvr7xNqcvBuLmZ4UjG5 m2xojDYvzfdy
QMcBc4oAuap8YfBen3DWdvqMmq3+9EjtdMhadpmYjARh8jH5um7sR14qn/wm PxC1iDOi/D77
FHNLsgu9XvVTy0D4Ly24xIOATgE+o3DGe803SdN0a3a30vT7SxgZy7R2sKxK WwBkhQBnAAz7
CrlAHnY0T4qancPLe+LtG0RFRVji0vT/ALSshycs3nYKnoOCQfQdyH4X30qG XU/iF4umvJHZ
5XtL77NESWJ+WLDBAAQMA49MDgeiUUAedx/BTwfK80+sJqWt3kr7mvNRv5Gl IChQuUKggAcZ
BPvjAEn/AApL4ef9C9/5O3H/AMcr0CigDz//AIUl8PP+he/8nbj/AOOUf8KS +Hn/AEL3/k7c
f/HK9AooA87m+CPgfYGsLC7027R1eK8tL2USwsrAgqXZgDx1x9MHBok+Gmr2 jw3Gi/EXxPBd
xvndqM4vYipUgjym2gnkEE5xjpnBHolFAHnZ0T4qaZcJLZeLtG1tGRlki1TT /syxnIwy+Tks
eo5IA9D2jXxt450Ty18R+AZ7qESvFJe6FOLjf94qyQcuFIA5Zh1zwSFr0iig Dg9L+MPgvULh
bO41GTSr/e6SWupwtA0LKTkOx+RT8vTd3A68V2ljf2ep2cd5YXcF3ayZ2TQS CRGwSDhhwcEE
fhUepaTpus262+qafaX0CuHWO6hWVQ2CMgMCM4JGfc1w958JLG2vZ9Q8Jazq Xhi8ldJGSyk3
WrurlsvCeGGGIC5Cgfw4yCAeiUV5mdW+JfhAo2saZaeKtLV2V7nS0Md6FMg2 u0WNrHax+RB2
5YYyeg8MfEbw54quHsrW5ktNUjdkk02/TybhGUtkbScMQEJIUnA646UAdZRR RQAUUUUAFFFF
ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV5/4t /wCSvfDr/uJ/
+k616BXn/i3/AJK98Ov+4n/6TrQAfBL/AJJDoX/bx/6USV6BXn/wS/5JDoX/ AG8f+lElegUA
FFFFABRRRQAUUVh+LfEsPhTw/LqT28l3OXWG1s4iBJczOcJGg6kk8nAJwCQD jFAGP448S6va
XFn4b8LW8c/iLUkZkkkIMdjCCA08g5OMnC5GCQfvEbW2PCPhex8HeGrTR7CO MCJAZpVTaZ5c
DdI3JOSR0ycDAHAFY/gHwY2g28mtazJJeeKdURZNRu5tpZCQD5KbSQqLgD5e DtHYKF7SgAoo
ooAKKKKACiiuT8UfEnwp4Qd4NV1WP7YqM32OAGWXIUMFIXhCQwxvKg564yaA Osorzd/HfjbU
4rp/D/w3vvJXMcE2q3Udo+/aDloWwSoJ7NzjqDnEh0r4r6pcIt34k8P6JBGj Hfpdm1y0rEjA
ZZ+AAM8gj6HsAeiUV53H8NNXu3muNa+Iviee7kfO7TpxZRBQoAHlLuAPBJIx nPTOSSH4I+B9
ha/sLvUrt3Z5by7vZTLMzMSSxRlBPPXH1ycmgD0SivP/APhSXw8/6F7/AMnb j/45R/wpL4ef
9C9/5O3H/wAcoA9Aorz/AP4Ul8PP+he/8nbj/wCOVHD8IbGyQwaZ4s8XadZh 2aKztNU2RQhm
LbVG0nGSepJ9STzQB6JRXm48J/ErTbOH7B8Q4L+S32BLe/0tESZVIyJJQWk5 Gcnlj6gnIG8V
/EXQfM/tzwRBqtvHKm680K6z+7baDsgfMjsCT/dHHYDdQB1HirwZpHjC2gj1 KOVJ7Z/Mtbu2
kMc1u395G/AdQRwDjIFZOlfDDSNP1m31a+1PWtcvLU5tW1e9M4tz3KDAGenX PQEYIqHTfi94
Uu79tO1Ga70HUFcqbXWYDbsBsDhi3KKCDxuYE+nIz3EE8N1bxXFvLHNBKgeO SNgyupGQQRwQ
RzmhaO6B6qzJKKKKACiiigAooooAKKKKAOf8VeDNI8YW0EepRypPbP5lrd20 hjmt2/vI34Dq
COAcZArJ0r4YaRp+s2+rX2p61rl5anNq2r3pnFue5QYAz0656AjBFdtRQtHd A9VZhRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVHPBDdW8tvcRRz QSoUkjkUMrqR
ggg8EEcYqSigDzPQBN8NvFi+FpbaT/hFtWuC+j3j3BcWszLlrZyx4DMGKAck n+MlivplY/if
wxpfi7Q5tI1eDzbeTlWXh4nHR0PZhk/mQQQSDz/w/wBf1R/P8KeJoPJ1/SIk Bl83et/Byq3C
Fjubphj/AHiM4JKqAdxRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFZ+s65pfh7Tnv9Xv4LK1X I3zPjcQCdqjq
zYBwoyTjgUAaFcv4r8f6F4Plt7W+knuNSusfZtPs4jLPNlgowvQZJ4yRnBAy RiuTl8S+L/iO
k9v4Nt49I8PSO8J1+6LCWZQyhmt4xgqfvgE9cfejYYHWeFPAGheD5bi6sY57 jUrrP2nULyUy
zzZYsct0GSecAZwCckZoA5e20n4i+N4FvNX1v/hFNMuNjJpunxZu/L3lsPKc NHJt2jK8eqLy
p6jwx8PPC3hGKH+y9JgF1FyL2ZRJOWK7WO88rkZyFwvJwBmuoooAKKKKACii igAooooAKKKK
ACiiigAooooAKKr31/Z6ZZyXl/dwWlrHjfNPII0XJAGWPAySB+NedyfE3UvE 9wbP4d6FJqYD
hZNWv1aGyi5QnrhnIDnK/KwxkBhQB6ZRXm8XgTxjrcq3Pinx5fW+PMK2fh// AEVIizDA83G6
RQo6MuRnr1LWP+FWf9T745/8HH/2FAHoFc34r8B+HPGduU1nTo5Jwm2O7j+S ePhsYcckAsTt
OVzyQa5+b4X30SCXTPiF4uhvI3V4nu777TECGB+aLChwQCME49cjg1zq3xL8 IFG1jTLTxVpa
uyvc6WhjvQpkG12ixtY7WPyIO3LDGSAEnh7x/wCDrg3HhzWpPE+ms4aTTNam /wBIGSgPlznA
zgOecKo/hcmtzwn8RNL8Tztp1xDPo+uxbRLpWoDy5slN+UBwXXGecA4GSACM 3PCnjzw54ztw
+jajHJOE3SWknyTx8LnKHkgFgNwyueATR4r8B+HPGduU1nTo5Jwm2O7j+SeP hsYcckAsTtOV
zyQaAOkorys6v43+GoQ+IPM8VeG0Rgb+ztyL22CxggyrnBT5WyxJP8TODhT6 Jo2uaX4h05L/
AEi/gvbVsDfC+dpIB2sOqtgjKnBGeRQBoUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFF
FFABRRRQAUUUUAFFFFABXn/i3/kr3w6/7if/AKTrXoFef+Lf+SvfDr/uJ/8A pOtAB8Ev+SQ6
F/28f+lElegV5/8ABL/kkOhf9vH/AKUSV6BQAUUUUAFFFFABXmfh1F+JHjE+ MLhI5fD2ku9v
oUU1syNJL8nmXXPUbl2r1xjOEZTm58QtSvNWvLX4f6JN5OpaxEz3tw9uZEtb HDK7E9NzEbB9
cZUlTXcWFjb6Zp1tYWcfl2trEkMKbidqKAFGTycADrQBYooooAKKK871v4ow z3/9h+BrSPxL
rjo7FYZQLe3UJkO8v3WGWUYDDJyCytgEA7y+v7PTLOS8v7uC0tY8b5p5BGi5 IAyx4GSQPxrz
u6+La607WHw/0a78R3+zJnMbQWtuSrkeY77TnKfdO0MDgNnipNO+FX9o3kGr ePdYn8SalHhk
t3/d2cDYTIWIYB5TBOArA/Mma9EgghtbeK3t4o4YIkCRxxqFVFAwAAOAAOMU Aebv8PfFfiZH
/wCEx8b3awSpKradoai3iUO33S5GZU2jGHUnnqed3WeG/A/hrwj5h0PSILSS TIabLSSEHGV3
uS235QducZGcZroKKACiiigAooooAKKKKACiiigAooooAp6lpOm6zbrb6pp9 pfQK4dY7qFZV
DYIyAwIzgkZ9zXBy/B7TtNla58H61qvhq6PlnbbXDSwSMjEgyRucycEjBbb7 HkH0iigDy9/F
3j3wXEsnjDQINY0xIgZNS0LLPEVVyzSRtjOdoJYBEXPU8KO48PeKtC8V2Zut D1OC9jX74QkP
HkkDchwy52nGQM4yOK2K4fxL8LdC1y8bVbBp9D10bmTUtMcxPuYNkuBgNkuS x4Y9NwFAHcUV
5enjbxL4Ela08d6dPf6YspEfiOxiUoULIFM0S/6vG8jPfGFD8sfSLG/s9Ts4 7ywu4Lu1kzsm
gkEiNgkHDDg4II/CgCxRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFcX498JTaslr4g0KGNfFOkustjIZDGJlDZaCQjG 5GUsMEjluoDN
ntKKAMfwr4ht/FfhfTtctV2R3cQcpkny3Bw6ZIGdrBhnHOMjitivN/3Xw9+J X/LddB8WS/7c
iwakW/JFlDe5LL/Cq8ekUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFF
FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFcP4r8b3lrrlv4V8KWsGo+JZsSSr MT5FjDwTJMVO
RkEYUHPIPdVcAueM/iBpHg1Et5vMvNYuUzZaZbqWluGLBVHAO0FjjJ64baGI xWHoPw7uNXvI
vEXxBm/tTVn3vHpbkPY2IcKNixnILALgnJBPPzEBzseCPBH/AAjn2nVtWuv7 T8Taj81/qDD6
fu4+BtjGAMYGcDgAKq9hQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF U9V1Wx0PS7jU
9TuY7azt03yyv0UfzJJwABySQBkmrleXxW//AAtXxat5e2O7wbossi2m+XKa ndBgpkKjKvCu
GAPfPUguigEelaVffFTVLfxH4jtpLbwrbv5mkaNL1uj2uJx0II+6vQg91JMn qEEENrbxW9vF
HDBEgSOONQqooGAABwABxipKKACiiigAooooA4vxn4Bh1501nRZY9J8U2j+b a6lEgBdgoXZN
gfOhUBeQcDsRlWk8HeKdU1HUdR8P+JrGCx1/T8SEW7fubuBiQs0IY7ioxg+h IzgkqvYVxfj7
wY2vW8etaNJJZ+KdLRpNOu4doZyAT5L7iAyNkj5uBuPYsGAO0rzfW/h/qOh6 jP4h+HVxBpd8
0Si40nyVFpfbCCoxwI2xuGRjOeqZZj1nhHxRY+MfDVprFhJGRKgE0SvuMEuB ujbgHIJ64GRg
jgitygDj/CfxE0vxPO2nXEM+j67FtEulagPLmyU35QHBdcZ5wDgZIAIz2Fcv 4x8C6X4ws8yj
7Hq0O1rPVIFxPbupJQhhglQSTtz3yMHBGP4T8dXEWot4U8bGCw8S2+1Y5SwS HUkY7UkiJwCx
PBUY5zgDDKgB6BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAV5/4t
/wCSvfDr/uJ/+k616BXn/i3/AJK98Ov+4n/6TrQAfBL/AJJDoX/bx/6USV6B Xn/wS/5JDoX/
AG8f+lElegUAFFFFABWfrms2fh7Q73V799lraRNK+CAWx0VckAsTgAZ5JArQ rz/xR/xV/jnT
fCEf7zTNP26nrWOUfB/cW7dVO5vnZHAyqgg8UAXPhzoFzp+l3Ovawsg8Qa84 vL8Mz4iHJihV
X5QIrbdpyQcjJAGO0oooAKx/E/ifS/COhzavq8/lW8fCqvLyueiIO7HB/Ikk AEin4z8Z2Pg3
S0nnjkur+5fybDT4OZbqU4AVQATjJGTg4yOCSAef8PeDNa1jxBB4r8fSWk2o WyL/AGdplrk2
9iSAWcgk7pd3fLAEAgnCbADPfTfF/wAT3c6q134X8Jl5VSyiLRahdrt2Dzsg hUOXO38CGG16
9E0bQ9L8PaclhpFhBZWq4OyFMbiABuY9WbAGWOSccmtCigAorgpvi1oMPjwe D2tNSOoG5W28
wRp5W5gMHO/OOfSu9oWqv0DZ2CiiuJ8b/FHRPAN9a2mq2uoTSXMZlQ2saMAA cc7nXmk2kOx2
1FQ2lyl5ZQXUYYJNGsihuoBGRn86811v47+F9A1y90m6sNYe4tJWhkaKGIqS DzgmQHH4U3o7
PcS1V0eoUVk+GvEVj4r8P2utad5gtrkEqsoAdSCQQwBIzketa1NqzsxJ3Cik ZgilmICgZJPY
V5Mf2iPB/wBrNullrMn7zYsiwRbW5xkZkzj8KS1dkPZXPWqKQHIzXCeFfi1o Pi/xJJoWn2mp
RXUaO5e4jRUwpAPIcnv6UdbB0ud5RRRQAUUUUAFFFFAEc8EN1by29xFHNBKh SSORQyupGCCD
wQRxivN9T+H+peFtUk8QfDb7JaXEqOL3SLlm+y3f3mUqM/I4Y4ABVQD1Ubg3 plFAHJ+DPiBp
HjJHt4fMs9Ytkze6ZcKVlt2DFWHIG4BhjI6ZXcFJxXWVyfjHwFY+LHt75Lu7 0rWrRHW11Oxf
ZKgKkbWI5ZMtnGQeoBG45z/BnjO+k1R/CHi+OO18UWybkkXiLUYhnEsRwBnA JK8dCQBhlQA7
yiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAoo
ooAx/FXh638V+F9R0O6bZHdxFA+CfLcHKPgEZ2sFOM84weKy/AWv32raXdaf rjR/8JBpFw1n
fhF2CQjlJlXrsdcENhQSGwAK6yvO/G8EPhHxLpvxAtoo4okcWOuMqgGS1kKq srdSTG4ThVLM
MDIAoA9EooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigA
ooooAKKKKACiiuH8b+K9UtdRtvCnhW28/wAS6hF5qyyL+5sYMlTPISMHBBAH PI5B+VXAK/jH
Wdd1rXP+EJ8Jv9mumiWXVNXBBGnwtnCqAc+cwBIHBwQR1Lp0HhPwXoXgrTms 9FtPK83aZ5nY
vJMyjALMfxOBhQScAZNR+DPBlj4N0t4IJJLq/uX86/1CfmW6lOSWYkk4yTgZ OMnkkknpKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooA4/4oazeaJ8P9Rl0x8an c7LOzRSfMeSV
gmIgpDGQKWZcc5XODiug0PRrPw9odlpFgmy1tIliTIALY6s2AAWJyScckk1x /jf/AEz4j/D7
Sbj57GS7ur14umZoId0TZHPylicZwc8g10vifxXpPhHTRearMy+Y2yCCJd8s 79kRe5P5c8kU
N2A26K4vR/iZpWpaxBpV7pus6HeXPFrHq9mYPtB7hDkgkcdcdRjNbHijxbpP hDTVvNUlf943
lwQQpvlnfsqL3P1wORkih6K4LV2NyiuR8O/ETSvEOsPo72WqaTqgj81LPVbU wSSJ3ZRkgj8c
8HjANP8AEvxB0jw3qUOlm31DU9VlG8WGmW/nzKmCdxGQAOPXPfGOaHoC1Oro rm/C3jjSPFrX
MFoLm11C1OLnT76LyriHnGWXJ4+hOMjODWHJ8XNG+13tnZ6RruoXdlcyW88F lZiVowhwZDhs
BCeASQeDwKOtg8z0CiuT8Q/EHSvD19BpptNS1LVpU8z+ztNt/PnRMZ3MAcAf jnn05qx4Y8b6
V4qkuba2S7s9RtcG40+/hMNxED0JU9jweCeozjNC12B6GHp//FPfGa/0yL9z puv6eNQVJPlR
ryNtkghHALFMO4wWOAScV6BXn/xK/wBD1jwNq1v8l9H4ghskl64hnVllXB4+ YKBnGRjgivQK
ACsPxR4R0Xxjpb2GsWUcwKMsU4UCWAnB3RvjKnKr7HGCCOK3KKAPN/DHifVP DGuQ+CvGs/m3
EnGkay3Cagg4COT0mGQOTzkAkkq0npFYfi7wvY+MfDV3o9/HGRKhMMrJuMEu DtkXkHIJ6ZGR
kHgmuf8ABnjO+k1R/CHi+OO18UWybkkXiLUYhnEsRwBnAJK8dCQBhlQA7yii igAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACvP/Fv/ACV74df9xP8A9J1r0CvP /Fv/ACV74df9
xP8A9J1oAPgl/wAkh0L/ALeP/SiSvQK8/wDgl/ySHQv+3j/0okr0CgAooooA z9c1mz8PaHe6
vfvstbSJpXwQC2OirkgFicADPJIFc/8ADvRryx0OXV9YTGu63Kb6+yDmLd/q 4RuG4LGmAEYn
adwBxWf4u/4qfx9ongt+LCGL+2tSRulxGj7Iosch1MnLqwxgAg5FegUAFc34 z8Z2Pg3S0nnj
kur+5fybDT4OZbqU4AVQATjJGTg4yOCSAbnifxPpfhHQ5tX1efyrePhVXl5X PREHdjg/kSSA
CRy/gbwxcXmoy+OfE0E41++3fZrW5wf7MtiTsiQDoxU8nAPzEEAl9wBJ4L8D 3dpfr4p8V30m
qeKJ7dEDyxoq2K7BuijVCVzksC4xnJwBubd3lFFABRRRQB8u3/8Ayc+n/YXi /ktfUVfLt/8A
8nPp/wBheL+S19RUQ/gx/rohT/jS/rqwr5u/aU/5GXRP+vN//Q6+ka+bv2lP +Rl0T/rzf/0O
s57x9f0ZpHZ/11R9A6D/AMi9pn/XpF/6AK+S/FWjza/8Y9c0y3z5897ceWAP vMFZgPxIA/Gv
rTQf+Re0z/r0i/8AQBXzdpv/ACc+3/YWm/8AQWrWaviLev5ozg7UL+n5M6z9 nDXzJp2q+HZm
+e3kF1Cp67W+Vh+BA/76r3Wvmhf+LcftGEf6uwvrj6Dyp/6K5/8AHa+l6d+a Kl/WgW5ZOP8A
WpxHxb8Qf8I78N9UnR9txcp9kh5wd0nBI9wu4/hXybcaRcaTc6Q1yNrXsMd2 i9wjOwX8wufx
r2r433k/ibx34f8ABNm5I3o8oHZ5DgE/7qZP/Aq5f432sNj8SdLtLdQkMGn2 0cajsqswA/IV
NL4lLvK33f8ABKqfC49lf7/+AfUq/wCrH0r5g+B3/JYLv/rhcf8AoQr6fX/V j6V8wfA7/ksF
3/1wuP8A0IUR/i/Jkv8AhfNH1DRXN+Mpnaz07S1Yqmq38dnMwPPlEM7j/gSo V/4FWDqfjbUr
fU9Ut9JsmaDSnWEWyaPdXLXbBQzKssQ2RcMFG4NzyQBihO/9en+aG1/X9ejP QqK5S11rXNa1
W9GlJYwWdhPFBNDexSebMWRJHwwbEZVXAAKtkg5xVfVvE2s2667qNlFZDTtD bbNBMjNLdbUW
R9jhgI8KwAyrZIOcUf1/wfxDfY7OiuGuPF+qW8niTUGW0Ok6IRiFYXM9zmBJ AA2/CHcw52tk
HoMZLtE17UdZ1D+ydXsmu7O8tXMki6Ld2kcJ4Bjcz8SBgxwRt+6cjkYNQ0O3 orn/AAbdzT6J
JbXDtJLp91NYmRzlnWNyqsT3JXbk+ua6Cj0D1Cub8Z+DLHxlpaQTySWt/bP5 1hqEHEtrKMEM
pBBxkDIyM4HIIBHSUUAcH4Q8T31t4gvvBfivUI59et3M1ndfZ/IW/tiNwZR0 Lr8wYAYG3gtt
Y13lc34z8GWPjLS0gnkktb+2fzrDUIOJbWUYIZSCDjIGRkZwOQQCM/wP4l1e 7uLzw34pt44P
EWmorPJGQI76EkhZ4xwcZGGwMAkfdJ2qAdpRRRQAUUUUAFFef/G3/kkOu/8A bv8A+lEdH/Ck
vh5/0L3/AJO3H/xygD0CivP/APhSXw8/6F7/AMnbj/45R/wpL4ef9C9/5O3H /wAcoA9Aorz/
AP4Ul8PP+he/8nbj/wCOUf8ACkvh5/0L3/k7cf8AxygD0CivP/8AhSXw8/6F 7/yduP8A45R/
wpL4ef8AQvf+Ttx/8coA9Aorz/8A4Ul8PP8AoXv/ACduP/jlH/Ckvh5/0L3/ AJO3H/xygD0C
ivP/APhSXw8/6F7/AMnbj/45R/wpL4ef9C9/5O3H/wAcoA9Aorz/AP4Ul8PP +he/8nbj/wCO
Uf8ACkvh5/0L3/k7cf8AxygD0CivP/8AhSXw8/6F7/yduP8A45R/wpL4ef8A Qvf+Ttx/8coA
9Aorz/8A4Ul8PP8AoXv/ACduP/jlH/Ckvh5/0L3/AJO3H/xygD0CivP/APhS Xw8/6F7/AMnb
j/45R/wpL4ef9C9/5O3H/wAcoA9Aorw/4pfC3wb4c+HGratpOjfZ76DyfLl+ 1TPt3TIp4ZyD
wSORXuFABWfrmjWfiHQ73SL9N9rdxNE+ACVz0ZcggMDgg44IBrQooA4/4d6z eX2hy6RrD513
RJTY32Scy7f9XMNx3FZEwQ7AbjuIGK7CvP8AxR/xSHjnTfF8f7vTNQ26ZrWO ETJ/cXDdFG1v
kZ3JwrAAc16BQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFA
BRRRQAUUVXv7630zTrm/vJPLtbWJ5pn2k7UUEscDk4APSgDm/HHi+bwzb2dl penyaj4g1R2i
02zVTtZlALO7cAIoIJ5H1AyyngfwhN4Zt7y91TUJNR8Qao6y6leMx2syghUR eAEUEgcD6AYV
cv4fWL65qOofEHUI50utVzDp0MrMvkWCkeWNhyAzld5wSpyCuNxz6BQAUUUU AFFcfrfxS8G+
HNYn0nVtZ+z30G3zIvssz7dyhhyqEHgg8Gs//hdvw8/6GH/ySuP/AI3QB6BR Xn//AAu34ef9
DD/5JXH/AMbo/wCF2/Dz/oYf/JK4/wDjdAHoFFef/wDC7fh5/wBDD/5JXH/x uj/hdvw8/wCh
h/8AJK4/+N0AegUV5/8A8Lt+Hn/Qw/8Aklcf/G6P+F2/Dz/oYf8AySuP/jdA HoFFef8A/C7f
h5/0MP8A5JXH/wAbo/4Xb8PP+hh/8krj/wCN0AegUV5//wALt+Hn/Qw/+SVx /wDG6P8Ahdvw
8/6GH/ySuP8A43QB6BRXL+G/iJ4V8XajJYaHqv2u6jiMzJ9nljwgIBOXUDqw /OuooAKKKKAP
P/Fv/JXvh1/3E/8A0nWue8ePrkvxt8N2+jDTTdR6dJJaDVPM8jzCX3kbOd21 R/nFdD8Q/wDi
U+I/BniqT5rXTtQe0uQ3ypFHcp5Zmd+iqhA6jB3AZFbHjPwRZeMbe2drqew1 KycyWV/bHEkL
/wBVyASMjp1FLqn2/wCGH0a7nGeKfCvxR8XaZFY38vg6EQ3CXEU1sblZI3U8 FSwIH5Vd8SL5
3x28Gw3eGhjsriSEHoZdrZI98AGrY+G2qave2r+MfGFzrtlaOJYrJLOO0jaQ dDJsJ3geh/PB
IO74x8GW3iy3tJFu59P1Owcy2N/b/fhfHcfxKcDI4zjqKa0s/P8AS39egnrd eX63/r1E8QDw
rF4q8PXGsgDWTI8WlsPNyWIG4fJxjBH3uOa5f4aBZvH3xBubnDagNSWLLHLL CN2wD0GB+g9K
2ND8BXdv4ji8QeJfEU+v6lbRmOzZrZbeK3DfeIjUkbj0z6fQEO1/wBNeeIT4 i8O69caBrEiC
O5ljhWeK4QDA3xsQCw4wfbpnmhafj+Nv8tfUHqren4X/AM9PQxtc22/7QXhl rTCz3Gmzpd4/
jjAYrn/gQ6+3tTfhFEg1bx1KFHmNrsqlu5AJIH6n866Hwr4ETQdVutc1PVLj Wdfu08ua+mQR
hUzkLHGOEHA7npxjpVnwj4Q/4RW41yX7d9q/tS/e9x5Wzyt38P3jn68fShaa eT/GVweuvmvw
TR5p4YfxpcfEHx1P4dHh43C6j5c51bz/ADRGCwjC7P4cCul07wr46uviNpXi fXpfDkUdpBJb
zLphmDyxsDgEOpzhiD1Famv/AA8kvPEh8SeHdduNA1mRRHcSxwLNFOgGPnjY gFunJPYcZ5qX
w74CfTtfbxFr2t3Gva2EMUVxLEsMcCYxhIl4UnnJzznoMnJDRLyX6WCerfn/ AF+BS+Kf/Mlf
9jXY/wDs9egV5/47/wCJz408F+HIf9ZHqH9s3EifOYI7cHbuUdFkZtgckAEd CeK9AoAKKKKA
CuX8deDrfxhoZiH7jVrXM2mXqOY3t5xypDgEhSQucDtkcgEdRRQBy/gjxTce JNOuYdVsf7O1
3Tpfs+oWRYHY+AQ6jJPluDlSeuDgsBuPUV5/438PXmm6xbeO/C+nfadbs/kv rSOQp/aFrtIZ
SAPmkX5Sv+6OGKotdhoes2fiHQ7LV7B99rdxLKmSCVz1VsEgMDkEZ4IIoA0K KKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigArz/wAW/wDJXvh1/wBxP/0nWvQK8/8A Fv8AyV74df8A
cT/9J1oAPgl/ySHQv+3j/wBKJK9Arz/4Jf8AJIdC/wC3j/0okr0CgAqOeeG1 t5bi4ljhgiQv
JJIwVUUDJJJ4AA5zUlcP8Ur64PhdfDumSY1fxBKun2yhQ2EY/vnYckRiPcGY A7dwPHUAEfwy
gmvrfWfF13FIk/iG9M8HmqUkFmg2W6uv3QQuSCM7gwOTXcTzw2tvLcXEscME SF5JJGCqigZJ
JPAAHOajsLG30zTraws4/LtbWJIYU3E7UUAKMnk4AHWuD8az3fi7xBD4B0uW 7gtmRbjXb+1Z
P3FuQ22A55DyEDjrtwcOpYAAr+GLNfiF4qfxzqVvHJpNk7W/h6LzWZWCOwe6 aMjh2YDbnBG3
kZVWr0yo4IIbW3it7eKOGCJAkccahVRQMAADgADjFSUAFFFFABRRRQB8uak4 j/adVjnH9rwj
j6LX1HXyz8YrW48LfGOLXVQtHO0F9CegLJgFc+uU/wDHhX0noGv6b4m0eDVN KuUntpR1U8o3
dWHYj0op/wAFLt/wAnpVb7/1+pp182ftJuD4p0ZOciyY/m5/wr6RkkSGJ5ZX VI0BZmY4CgdS
T2FfJ3xJ1ZPiN8WobPRnE8G6Kwt5U5D/ADHcw/2cs3PoM1LXNOMV3KTSjJs+ o9B/5F7TP+vS
L/0AV83ab/yc+3/YWm/9Bavp2CFbe3ihT7saBBn0AxXzFpv/ACc+3/YWm/8A QWq73xCa8/zR
na1Bp+X5M6v9o/QC1lpHiOBSHgc2szDrtPzIfwIb/vqvUvBfiSLX/AWm65LI o3W264YnhXQY
fP4g1N400FfE3g3VdIIBe4t2Eee0g5Q/99AV80eG/HraH8JvE3hqSQpeTSrH bKeoWT5ZR+AU
/i1QnaMor1X9fiaNXcZfJna/CVG8afFzxB4zmUtDblvILDoXyqflGpH41z3x 7/5KtZ/9ecH/
AKG9ewfBjw6NA+G9gzxhbm/zdynHJ3fdH/fIX9a8f+Pf/JVrP/rzg/8AQ3rS 3LUpwXRpfmQn
zRnLufT6/wCrH0r5g+B3/JYLv/rhcf8AoQr6fX/Vj6V8wfA7/ksF3/1wuP8A 0IVMf4vyYP8A
hfNH0R4l06e/02KWzRXvrK4ju7ZWIG5kPK5PTcpZc9t1VrjwpFc31ze22pap pn27Y15BaSoq
zMBjJJVmRtuFLRsp4HOQDXRUULQZg3HhWGXUpry31PUrJblo2uoLWZVW4ZAA CzFS6nAAJRly
BzUWo+DLHUbu8kN3ewW1+VN/ZwsgiuyoA+fKlhkAKdjLkDnNdHRQBkDw3pxX WY5kaeHV33XU
UhG3HlrHhcAEDao981BY6HNoqPcDVNX1Z4Lcx29tcTRgYA+6NqoGY4A3SEke oyc71FAGR4Z0
mTR9EjguGVruWSS5uWU5BlkYu+PYFiB7AVr0UUAFFFFABXF+PfCU2rJa+INC hjXxTpLrLYyG
QxiZQ2WgkIxuRlLDBI5bqAzZ7SigDD8JeJYfFfh+LUkt5LScO0N1ZykGS2mQ 4eNx1BB5GQDg
gkDOK3K831u2/wCEA8cxeKbNYINA1qWO01uNYseVMS/l3RYkKi7mCuTgc5wz NkekUAFFFFAH
n/xt/wCSQ67/ANu//pRHXV+IPEmkeFtMOo61fJaWoYIHYFizHoAqgkn6DoCe 1cp8bf8AkkOu
/wDbv/6UR11fiDw3pHinTDp2tWKXdqWDhGJUqw6EMpBB+h6EjvSd+g1bqcno fxC1fxTr9pFp
PhLULfQWHmzarqC+UGj2tgxr0bJ28hjxn5R1EOpfF+we5lsvCWj6j4ovImCy fYomEEZLEfNJ
tOOhIIBU+tTaH8PdX8La/aS6T4t1C40FR5U2lag3mhY9rYEbdFwdvAUcZ+Y9 DDqXwgsEuZb3
wlrGo+F7yVg0n2KVjBIQxPzR7hnqQACFHpTdtO34i79/wOZ+JvibxJbJ4W07 VNWk8K29/btJ
qV7ZxvIYplAOxShLYBwMK3O7kkCpfDF74y8OjWJLDXYPG+hw2TTxXZvYy0dw ADsbLs4GMnGS
OmMEmtHxkPHWlWuj3Fxptt4t0xbVYtW0tbVHEs4P+tUbN3JI6KQNvTuOU8Ie FtW1bxncatpn
g248Iab9huILqGeWQ/aZJFYABXC4XJU4VQo2degpO9pW8/8Agf8AA+Q9Lq/l /X+fTc6Lwd8T
tUtPhodf8UafPPum8uzuI5kZ9QleRxsWMAeXtxjnsOB2rqtC8eX114li8PeJ PDkug6jcwmez
Bu0uEnVfvDcuMMOuOeAenGfK4fDet638HLbw63hvVI9S8P3n2qS3u4WijvUL yblibI3EBucf
hnIrqPAfh3QX8W297pPw11XRUtIy7X+qXM0TJIQRtSJmbzBg9eMdwOM6aOb7 fpbf7/8AKxLv
bz/W/wDX3mppXxV1PWbvUPsnhFv7P0y7eG/v31BFjgjU8yYK5Y4DEqBxgc80 sHxbuPJtNYvf
Cd5Z+FrucQw6s91GWGSVVnhHKrkHnPTpnIBo+BPDGo3Pg7xzpN5a3FjJqWoX awNcRNHuV0wr
jI5XPcVxmgeDNOW2sdG1D4Uatda+kvlXV3LdzW9mVBOZBMGKnjHAGDzg9AYh uk+y/Hf+unUq
Wzfm/wANj1HWPiLer4ivNE8L+GZ/EFzp8Ye+dLpII4SeihmB3N1468cZ5xzf jb4p3tx8L01z
wvDJbyTXP2S7eUqJbFx1XaerHoD2Bzwej7X+1fhp418ST/8ACNatrGmay63N tLpkPntG4zlH
HVR83U+nAPOMHU/AHiJPg5rHm2Dtq2oaqNTfT4P3jxqSBsAHVgOePp2pLZP0 /NXX3X+4a+L7
/wAt/vseiaB461G78VW/hvXvD39j3s9ibuH/AE1bgPhtpXKqBnALcE1i6x8Y /wCzbfxFdwaD
9qs9Hvo7ETfa9nnyNndgbDjbt9TnI6VlfErUrw+F/D/xC03T7zTr/Sbhka31 CHypVjfKEMue
hIGPZs1ieLdAl8Pfs52UNwCb25u4ru5J6mSQlufcDA/Cm7/c7fe1b8CYrZd1 f7k7/id9Z/E6
8XX9Kstc8KXej2GsNt068luUkMjHG0SIo/dkgjgkkHjHUh2qfEm+XVtVtPDv hW41u30c7dQu
VukgEbAElUVgTIQAcgc5GO4J5/WH1/4g694W0xvC+p6UmlXaXmo3V2gWEFMf LC4JEgJyAR7H
GMkc3qfgqz0Xxd4jOv8AgLV/EiXtw13pt1pzSlfnJPlyFGGzBIGSCepwRih/ 5/Pa369r2COq
+75b3/Tvud9efFuC5m0S08L6PJrV/q1ubmO3e6S28tBuyCzZG8FGG0f3Tz0z PN458Uv4a/tO
z8DX/wBvtLpor7TZyVZowrfPDJj94N23lVOeeOjVx3ibwjZQaNoVpffDa9/s 1YJVc6NePd3l
jK5LBRnAcdTltygscY/ik8H+EfG9z4av9P07WtV8P6PNdhbL+013XkNsquGA UY2Ets4BXoSO
vI+tv61/r13Qdm/60/r8ju/D3xL0TxDqB0jy7zTNdCk/2ZqMDRS8KG47Hg5A znAJxisW0+LM
ukN9n8eeHNQ0CRWEZvVhaa0kbbnh1B5POAN/uetbXhz4aaJ4cv21dWu9S11l YHU9RmMsuSAO
Ow4GM4zgkZIrFtfhLJrDi68eeItQ1+Ut5n2JZWhtI224+VVI6c4I2Z7jrT6/ 1+AdCx8ZLmC8
+C+r3VtKk0EyW0kciHKupnjIIPcEV6LXnfxlt4bT4MaxbW0SQwRJbJHHGoVU UTxgAAdABXol
DtfQSvbUKKKKQzH8VeHrfxX4X1HQ7ptkd3EUD4J8twco+ARnawU4zzjB4rP+ HviG48S+C7G9
v12anFutr+JiA6Txkq29QBsY4DbcDG4fWuorz/Rf+KW+KuraEPk03X4jrFqX +UC6BCzxqTky
MwCyEA/KBwuOaAPQKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACii
igAooooAK8z8ROvxI8YjwfbvHL4e0l0uNdlhuWRpJfn8u146jcu5uuMYyjKM 9J4/8Q3Hh7wu
76cu/V7+VLDTUyBuuZThOWBUY5b5sA7cEjNXPCXhqHwp4fi01LiS7nLtNdXk oAkuZnOXkc9S
SeBkk4ABJxmgDcooooAKKKKAPP8Awl/yV74i/wDcM/8ASdq6DxJ448NeETEu uatDaSS8pFta
SQjnnYgLBeCM4xniuf8ACX/JXviL/wBwz/0naub8D6FpPir4h+OdQ8Q2VvqF 7a3/ANmhhu0E
qxRAsFwrcchQM47cdTS1bt8/y/zHsrnp3h/xPoviqw+3aJqEV5ADtYpkMh9G UgMvTuBkc1rV
5nq2meHfhtpnizxN4bhjTUxAgktI5cxQMxAT90Pugk7uewOMDNcvqkfiXwd4 J0vx6PF2q397
I0M17ZXUwa1kSUglEj6JjIGR74Ap3T/D8RWf5/ge6VW1DUbPSbCa+1C5itrW EbpJZW2qo6fz
wAO5NeT6odX8R/Go6Lb+I9W0vTJdGW4ljtJircn+HOQjZI+YDOAR3rz3xRca rd+BPEWl6nrW
oXo0HXlt4JJptzSoxcfvCeWxtyM9MntgUa6f19rlGrP+vK59RAhgCOh5FUtY 1ex0HSrjVNTn
8izt1DSybGbaCQOigk8kdBXlPi3fpFxoPhW38TeMLyXyXmNtphD3sxYna8ty SNsYJIxtIAGT
0BrC0rxN4lT4WeO7W+v9QivtHuVjhllu/MuIcvgoZlxuIwRuHrxxgUpOybXT /Owo6uKfW346
nvVneQahYwXtq/mW9xGssT4I3KwyDg8jg96nrxLV73XtQ8QfDbTbTxDqNgNR 03ddSwzEmT92
CxIOQWIzhiDgnPas668V6/8AD+/8daRHrN9qkdhbQTWU2oyefJE8hjXJJHOP MzjplRxyc1Ky
b+f4Cjql8vxPfqK8C8O6z4osNf0G4soPH98lzIkerJrNoWtSr4y8RGfLAJJ+ mOcZzsabp+re
Lfip4x06fxVr1jpthLE0cFjeGP5iOACc7V+9kDGSR6UW1t6/hb/ML6X9PxOl /wCbhf8AuVP/
AG7r0CvPlXb+0GFBJx4Uxycn/j6r0GkMKKKKAOf8ceG/+Eu8F6poYk8uS6i/ dOWwBIpDpuOD
8u5VzgZxnHNR+BvFS+LvDUd88MlvfwObXULd4mjMFygHmJg5OMnI5JwQDyCB 0leb+LE1TwN4
ouPHGlWf27SLuKOPXrOMZmAjBC3CEn+FTgqMDAyepdAD0iio4J4bq3iuLeWO aCVA8ckbBldS
MggjggjnNSUAFFFFABRRRQAUUV53451LV/EmqSeAfDaxo89uDrGpOA6WVvJk bNueZXUHAODg
gjqWQAPBUy+MPGureO4RIumrbjSNLZo2jM8StvllIYcgycKQRwGDKCK9EqvY WNvpmnW1hZx+
Xa2sSQwpuJ2ooAUZPJwAOtWKACiiigAooooAK830xE+HnxAl0dLPyPDXiOUT WUkYVIbS92kP
CcnP7wIpUcDOFVepHpFYfi7wvY+MfDV3o9/HGRKhMMrJuMEuDtkXkHIJ6ZGR kHgmgDcork/A
PiW717RpLTWLeS18QaW62upW8pTcZAoIlAXjY4+YEADqBkDJ6ygAooooAKKK KACiiigAoooo
AKKKKACiiigAooooAK8/8W/8le+HX/cT/wDSda9Arz/xb/yV74df9xP/ANJ1 oAPgl/ySHQv+
3j/0okr0CvP/AIJf8kh0L/t4/wDSiSvQKACvP7T/AIqP40ajJc8Q+FLSKK0i /vTXSbnlyMY+
QbNp3D+IYNegV5/8H/8ATPCF5r/3P7e1W71LyOvkbpNmzd/F/q85wOvTigDq PFXiG38KeF9R
1y6XfHaRFwmSPMcnCJkA43MVGccZyeKy/h/4Xbw54f8AOv44217UnN5qtwEU NJO5LFTtJGF3
FRt+XqQBuNZeq/8AFX/FCy0Yc6Z4Y8vUr3/bvHB+zp2YbV3SZBZTnawr0CgA ooooAKKKKACi
iigDl/HPgXS/HmifYNQBinjy1tdIMvC57+6njK9/YgEeEXHwV+Ivha/M/hu8 E5k3R+fp979m
kEeQRv3FcZ4OAW5H0r6fopJWd0O91Zny5J8L/i74ieKw1qe7NoW379R1YTRI wBwSodzntkKe
vpXrPw0+ENh4Fb+0ryZb7WnTb5oXEcAI+YRg8k9tx5I7Lk59Koqk7bEtX3Cv GrT4S69b/GNv
F73emnTzfSXHliR/N2sCAMbMZ59a9lopLSSl1Q3rFx7hXgGv/ADU9U8dXWo2 17p0WjXN2Jnj
MjiZUYguAAhXPLY59K9/ooWklIL6WGQxJBDHDEoWONQqqOgAGAK8e+Jvwl17 xn42t9a06702
K2jt44itxI6vlWYnhUIxyO9eyUUfaUuqDo0IBhQPavme7/Z28XT3s8y6jogW SRmAM8ucE5/5
5V9M0Ura3GnZWPmD/hnHxh/0EtD/AO/83/xqj/hnHxh/0EtD/wC/83/xqvp+ imIyvDOmzaN4
W0nS7ho2ns7OKCRoySpZVAJGQDjj0rVoopybbuxJWVgooopDCiiigAooooAK KKKAKeq6VY65
pdxpmp20dzZ3CbJYn6MP5gg4II5BAIwRXH/DnUruwS58Eawsi6noaBLeaQIg vbPcVilRQegU
KrdcHGW3Egd5Xn/xB/4p7XPD/jkfLa6dKbPVCnylrWfChmI5dY32sEAOS2Rj BNAHoFFFFAHn
/wAbf+SQ67/27/8ApRHR/wAJb8Q/+iYf+V+3/wAKPjb/AMkh13/t3/8ASiOj /hLfiH/0TD/y
v2/+FAB/wlvxD/6Jh/5X7f8Awo/4S34h/wDRMP8Ayv2/+FH/AAlvxD/6Jh/5 X7f/AAo/4S34
h/8ARMP/ACv2/wDhQAf8Jb8Q/wDomH/lft/8KP8AhLfiH/0TD/yv2/8AhR/w lvxD/wCiYf8A
lft/8KP+Et+If/RMP/K/b/4UAH/CW/EP/omH/lft/wDCj/hLfiH/ANEw/wDK /b/4Uf8ACW/E
P/omH/lft/8ACj/hLfiH/wBEw/8AK/b/AOFAB/wlvxD/AOiYf+V+3/wo/wCE t+If/RMP/K/b
/wCFH/CW/EP/AKJh/wCV+3/wo/4S34h/9Ew/8r9v/hQAf8Jb8Q/+iYf+V+3/ AMKP+Et+If8A
0TD/AMr9v/hR/wAJb8Q/+iYf+V+3/wAKP+Et+If/AETD/wAr9v8A4UAcr4m0 /wAY+LdUtLvV
fh7qT21ttP8AZyeJ7dbWVlJIZ02cnnGcjgAVc8Xf8Jp4z0I6RqPw1uYbfzVl 3W3iG1Vsr0+8
hGPwre/4S34h/wDRMP8Ayv2/+FH/AAlvxD/6Jh/5X7f/AAo/4cd9biL4s+Ia qFHww4Ax/wAh
+3/+Jpf+Et+If/RMP/K/b/4Uf8Jb8Q/+iYf+V+3/AMKP+Et+If8A0TD/AMr9 v/hQJKwf8Jb8
Q/8AomH/AJX7f/Cj/hLfiH/0TD/yv2/+FH/CW/EP/omH/lft/wDCj/hLfiH/ ANEw/wDK/b/4
UAH/AAlvxD/6Jh/5X7f/AAo/4S34h/8ARMP/ACv2/wDhR/wlvxD/AOiYf+V+ 3/wo/wCEt+If
/RMP/K/b/wCFAHH/ABS8ReMr74catbat4E/suxfyfMvP7Xhn8vEyEfIoyckA cdM57V7hXh/x
S8ReMr74catbat4E/suxfyfMvP7Xhn8vEyEfIoyckAcdM57V7hQAUUUUAFcH 8TYJrG30bxda
RSPP4evRPP5Sl5DZuNlwqL90krgknG0KTkV3lU9W02HWdGvtLuGkWC9t5LeR oyAwV1KkjIIz
g+hoAsQTw3VvFcW8sc0EqB45I2DK6kZBBHBBHOakri/hRqU2ofDfSUu1jivL FGsLiBQVaFoW
MYV1Jyr7VQkHHXOACK7SgAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAoo
ooAKKK5P4jeJ5vCvg64urJJJNUunWz06ONCzPcSZC4G1gSAC2CMHbjuKAMvS v+Kv+KF7rJ50
zwx5mm2X+3eOB9ofsw2rtjwQynO5TXoFY/hXw9b+FPC+naHatvjtIghfBHmO Tl3wScbmLHGe
M4HFbFABRRRQAUUUUAef+Ev+SvfEX/uGf+k7VF4t+FEeua+2v6Hr994e1aVQ lxPaZxKvuFZS
CcLk7sfL0zzWJB4V/wCEm+L3jv8A4n2uaV9n/s//AJBV55Hm7rf+Pg5xt49M n1roP+FWf9T7
45/8HH/2FK3Udxvhj4SaTounatHql5ca1favEYr28uOGZSSflGSQehJLE5UH jpVS2+Et1Ill
pms+LbzVPDdhIHttLe2ROFPyLJKDl1A4xge2OlXf+FWf9T745/8ABx/9hR/w qz/qffHP/g4/
+wqr63FbSxrx+DRH8SZPF4vuHsBZfZPJ6cg7t+726Y/GucvPhBDfab4qtJtY bOu3630brbf8
ezBmYDG75/vEfw1c/wCFWf8AU++Of/Bx/wDYUf8ACrP+p98c/wDg4/8AsKX9 fjf8wv8A18rf
kVrr4Z65PqOma3D41lg8Q2lu1tLqA06MrPEWJUGLdtBAbGec4BxnmmW3wjNr 4e8UaOviGeaP
XXSTzri33yRODlixDAPk+y/jVz/hVn/U++Of/Bx/9hR/wqz/AKn3xz/4OP8A 7Ch63T6/8OC0
s10LX/Cvf+J74S1P+1P+RetTbeX9n/4+Mpt3Z3fL64waivfhjZap4n8R6pqF 601rrdmlq9qs
W1otoTDh8nJBQEfL19ai/wCFWf8AU++Of/Bx/wDYUf8ACrP+p98c/wDg4/8A sKHrv5/juC02
8vw2HeH/AABrml3unnUvHOpahp2nLttrKKIWwOMBRKysTKAB0b+WQdXQPB39 h+MPEOv/AG/z
/wC2GjbyPJ2+TsBH3tx3Zz6Csj/hVn/U++Of/Bx/9hR/wqz/AKn3xz/4OP8A 7Cnd3v8A1qK2
lg/5uF/7lT/27r0CvJ/Degf8I58dZLP+19V1Tf4aMvnanc+fIubkDaGwMLxn HqT616xSGFFF
FABUc8EN1by29xFHNBKhSSORQyupGCCDwQRxipKKAPK5NA1r4W3sN/4YXUta 8LyPsvND3GaW
0DOSJLYdSAW5XqerE53J2HhTx54c8Z24fRtRjknCbpLST5J4+FzlDyQCwG4Z XPAJrpK5PxP8
OfDniq4S9uraS01SN1ePUrB/JuEZSuDuAwxAQAFgcDpjrQB1lFebxeGfiT4e lWPQ/FtjrNj+
8CweIIX3xAsGU+bHl5GxkZJAHYdNtj/i7/8A1I3/AJN0AegVXvr+z0yzkvL+ 7gtLWPG+aeQR
ouSAMseBkkD8a4Oa1+L16gt21Dwjp6O6h7q0inkliXcMlVkBRjjIwfXqOoLP 4SWNzewah4t1
nUvE95E7yKl7JttUdnDZSEcKMKAVyVI/hxgAAz7/AMb6l8Q3/sL4frdw2kjl L3xHLAyRW8YV
SwhzgmX5sYO0jqODvXtPCng7S/B9ncRWHnz3F1KZrq9u38ye4cknLvgZxk44 7k9SSdyCCG1t
4re3ijhgiQJHHGoVUUDAAA4AA4xUlABRRRQAUUUUAFFFFABRRRQB5/qv/FIf FCy1kcaZ4n8v
Tb3/AGLxAfs792O5d0eAFUY3Ma9ArH8VeHrfxX4X1HQ7ptkd3EUD4J8twco+ ARnawU4zzjB4
rP8AAHiG48Q+F0fUV2avYSvYakmQdtzEcPyoCnPDfLkDdgE4oA6iiiigAooo oAKKKKACiiig
AooooAKKKKACiiigArz/AMW/8le+HX/cT/8ASda9Arz/AMW/8le+HX/cT/8A SdaAD4Jf8kh0
L/t4/wDSiSvQK8/+CX/JIdC/7eP/AEokr0CgDi/ivqU2n/DfVktFjlvL5FsL eBgWaZpmEZVF
Byz7WcgDPTOCAa1L65s/AfgGSUN5lro2nhIhPKEMvloFRS2MbmIVeB1PA7Vz /jD/AIn3xF8I
+Go/mjs5W128KfK8SxZWAgngq0jFSAC3+6OaPiX/AMTi88MeDf8AlnrWoeZd q/CSWtuPNlQs
PmVj8mNuOnJA6gGp8OdEm0bwdbyXvmHVNTdtS1FpIzGxuJsMwKdFKjC4AA+X OBk11lFFABRR
RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUA
FFFFABVe/sbfU9OubC8j8y1uonhmTcRuRgQwyORkE9KsUUAcP8ML64XQ7zw3 fyb77w7dtp25
1CPLAuDDKY/4VZMAdc7M5OTXcV5/qH/FK/Fywv4/lsPFMRs7wv8AKiXUK5gY uc/M6kxhBtzj
PzGvQKAOP+KWiaj4j+HGraTpNv8AaL6fyfLi3qm7bMjHliAOATyaz/8AhLfi H/0TD/yv2/8A
hXoFFAHn/wDwlvxD/wCiYf8Alft/8KP+Et+If/RMP/K/b/4V6BRQB5//AMJb 8Q/+iYf+V+3/
AMKP+Et+If8A0TD/AMr9v/hXoFFAHn//AAlvxD/6Jh/5X7f/AAo/4S34h/8A RMP/ACv2/wDh
XoFFAHn/APwlvxD/AOiYf+V+3/wo/wCEt+If/RMP/K/b/wCFegUUAef/APCW /EP/AKJh/wCV
+3/wo/4S34h/9Ew/8r9v/hXoFFAHn/8AwlvxD/6Jh/5X7f8Awo/4S34h/wDR MP8Ayv2/+Feg
UUAef/8ACW/EP/omH/lft/8ACj/hLfiH/wBEw/8AK/b/AOFegUUAef8A/CW/ EP8A6Jh/5X7f
/Cj/AIS34h/9Ew/8r9v/AIV6BRQB5/8A8Jb8Q/8AomH/AJX7f/Cj/hLfiH/0 TD/yv2/+FegU
Re: Connecting DSL-eCore w/ UML2 [message #471135 is a reply to message #471129] Mon, 11 June 2007 12:47 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33108
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------070307040505060403060902
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Stefan,

It is indeed a long post and I actually can't find a single "?" in it,
so I'm not really sure what to say. I does sound like it would be
perhaps a lot simpler to design your own independent model that has no
relation to UML2, but I don't think I really understood well all the
issues and concerns...


SKuhn wrote:
> hi folks,
>
> the following text is quite long, so if you're in a rush just read
> abstract, look at the picture, read constraints, the idea and the last
> point of ecore-mapping.
>
> Abstract:
> basically I want to be able to read & write proper UML2 models with my
> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
> going to outline it in detail because I didn't find a good way to
> start / solve it.
>
> Use Case:
> We're working with MDSD and already have a cardridge for a domain.
> Right now, the generator gets the model from an uml2 tool. The
> graphical editor I have to make (using GMF) for this domain should be
> able to read and write uml2 models because of reasons like flexibility
> (wheather or not to use my editor) or extended control of an uml tool
> (e.g to model the DTOs in the same file). Both, UML2 Tools and the
> generator accept uml2 models from ecore.
>
> DSL:
> There various reasons why a tend to create my own domain specific
> language (DSL) for my graphical editor (GE) in contrast to use
> uml2.ecore:
> * a DSL which uses around 10 classes seems to be overburdened if it's
> based on the uml2.ecore with several hundred classes.
> * not that error prone because less confusion for the GMF framework
> and even more important for me.
> * some constraints are already implicit from my DSL Metamodel (MM) and
> the others should be easier to write on a simple MM.
> * It seems unhandy to create the uml2.ecore model code (after 5 hours
> I stopped the generation).
> * there must be a reason why GMF enforces the creation of DSLs rather
> than building a customized UML2 editor.
>
> The two worlds:
> This results in two worlds for my "MetaModel" sketch (see attached
> picture). In the left corner, we see famous UML with his well known
> metaclasses and packages. On the right corner we can see the young DSL
> also with metaclasses described in ecore. Now my experiments showed
> that the heavyweigth extensions in which I extended classes from the
> uml2.ecore are uml2-xmi compliant. So the only way to customize uml
> and still be able to use standard uml tools is the lightweight
> approach. I sketched this with the outer circle around uml.
>
> Contraints:
> * I assume that I'm not restricting UML and
> * that every DSL Class has a pendant in uml with a lack of semantics
> expressable by stereotypes.
> * both MM are defined in EMF.
>
> The idea:
> is to connect my DSL-MM with the uml2-MM. This should be realizable by
> creating a profile with sterotypes and enumerations for my DSL and
> represent my DSL classes in uml with the appropriate stereotype. I
> illustrated this in the 2nd picture "Concrete example" which shows
> instances of both MM. So on the right we can see the instance classes
> of MyDSL: a container, a class named Ex1 which is an instance of
> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
> association between Ex1 and Ex2 and a class named Ex3 which is an
> instance of DSL-Class#2. Now I want to map them to UML. Following my
> example this would result in mapping:
> * an instance of container to an uml-package with sterotype dsl-container
> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
> sterotype dsl-class#1
> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
> sterotype dsl-class#1
> * an association between Ex1 and Ex2 to an uml association (which may
> be stereotyped as "dsl-association if easier)
> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
> sterotype dsl-class#2
>
> Other Mapping possibilities (mentioned if my vision doesn't work in
> time):
> * Model-to-Model transformation is an option. I rather dislike this
> for the classic reasons e.g. consistency between the models,
> overwriting or synchronization of changes and -for me the most
> important one- possible information loss due to the lack of
> representation in one language. In my example this means that if a
> "NotDslClass" exists in the left UML world for which I have no
> representation in MyDSL there is no need to represent it in MyDSL. But
> I guess I would be forced to handle it somehow not to loose
> information in the back-to-uml transformation.
> * Customized XML/XMI serialization through extending the XMLHelper
> also seems error prone and seems to require a good knowledge of XMI,too.
>
> Ecore Mapping:
> So a better approach would be to simulate the DSL-MM for my GMF-DSL
> editor but actually work directly on an UML model. I found the EMF
> part of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
> found the some starting points or ideas how to realize it. My problem
> is I can hardly value them nor I know a kind of best practice for
> this. So it would be really nice to start a discussion about them or
> if you say just read this f****** manual because I'm stuck right now ;(
> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff)
> looks like an option but my impression is that this is not really what
> I want.
> * Abuse the Model classes (or facades), normally generated by generate
> model code as an adapter to eclipse-uml2 facades seems like a lot of
> work implying a pretty good understanding of EMF.
> * My Favourite: to use the Ecore2Ecore mapper and a customized
> rescource handler as mentioned in EMF-EclipseCon p.158ff. My issue
> here is that it's just mentioned and not really described, but it
> seems exactly like what I want. This feeling is emphazied by features
> like OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
> resources about that or if there isn't a simple proof-of-concept
> example somewhere.
>
> Thanks for reading already
> -stefan
>
>
> ------------------------------------------------------------ ------------
>


--------------070307040505060403060902
Content-Type: multipart/related;
boundary="------------080608070903060108060300"


--------------080608070903060108060300
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Stefan,<br>
<br>
It is indeed a long post and I actually can't find a single "?" in it,
so I'm not really sure what to say.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Connecting DSL-eCore w/ UML2 [message #471138 is a reply to message #471135] Mon, 11 June 2007 13:13 Go to previous messageGo to next message
Stefan Kuhn is currently offline Stefan KuhnFriend
Messages: 355
Registered: July 2009
Senior Member
Hi Ed,

I expressed my hopes with "So it would be really nice to start a
discussion about them or if you say just read this f****** manual
because I'm stuck right now ;( " in a way that people can say I did it
this way or this way is really awful/awesome or this is the best way to
do it.

and later on my 'question' in the last point "I'm wondering where I can
find good resources about that or if there isn't a simple
proof-of-concept example somewhere.".

Anyway, the question-representation looks like this:
Does anybody know good resources which may help me realizing My
Favourite approach(the last) point under EcoreMapping?

I can't imagine that this is a new problem/approach, so is there already
a proof-of-concept example somewhere?

> I does sound like it would be
> perhaps a lot simpler to design your own independent model that has no
> relation to UML2
Of course ;). My problem is that I somehow need this representation in
UML (I described this in Use Case).

greets
stefan





Ed Merks schrieb:
> Stefan,
>
> It is indeed a long post and I actually can't find a single "?" in it,
> so I'm not really sure what to say. , but I don't think I really understood well all the
> issues and concerns...
>
>
> SKuhn wrote:
>> hi folks,
>>
>> the following text is quite long, so if you're in a rush just read
>> abstract, look at the picture, read constraints, the idea and the last
>> point of ecore-mapping.
>>
>> Abstract:
>> basically I want to be able to read & write proper UML2 models with my
>> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
>> going to outline it in detail because I didn't find a good way to
>> start / solve it.
>>
>> Use Case:
>> We're working with MDSD and already have a cardridge for a domain.
>> Right now, the generator gets the model from an uml2 tool. The
>> graphical editor I have to make (using GMF) for this domain should be
>> able to read and write uml2 models because of reasons like flexibility
>> (wheather or not to use my editor) or extended control of an uml tool
>> (e.g to model the DTOs in the same file). Both, UML2 Tools and the
>> generator accept uml2 models from ecore.
>>
>> DSL:
>> There various reasons why a tend to create my own domain specific
>> language (DSL) for my graphical editor (GE) in contrast to use
>> uml2.ecore:
>> * a DSL which uses around 10 classes seems to be overburdened if it's
>> based on the uml2.ecore with several hundred classes.
>> * not that error prone because less confusion for the GMF framework
>> and even more important for me.
>> * some constraints are already implicit from my DSL Metamodel (MM) and
>> the others should be easier to write on a simple MM.
>> * It seems unhandy to create the uml2.ecore model code (after 5 hours
>> I stopped the generation).
>> * there must be a reason why GMF enforces the creation of DSLs rather
>> than building a customized UML2 editor.
>>
>> The two worlds:
>> This results in two worlds for my "MetaModel" sketch (see attached
>> picture). In the left corner, we see famous UML with his well known
>> metaclasses and packages. On the right corner we can see the young DSL
>> also with metaclasses described in ecore. Now my experiments showed
>> that the heavyweigth extensions in which I extended classes from the
>> uml2.ecore are uml2-xmi compliant. So the only way to customize uml
>> and still be able to use standard uml tools is the lightweight
>> approach. I sketched this with the outer circle around uml.
>>
>> Contraints:
>> * I assume that I'm not restricting UML and
>> * that every DSL Class has a pendant in uml with a lack of semantics
>> expressable by stereotypes.
>> * both MM are defined in EMF.
>>
>> The idea:
>> is to connect my DSL-MM with the uml2-MM. This should be realizable by
>> creating a profile with sterotypes and enumerations for my DSL and
>> represent my DSL classes in uml with the appropriate stereotype. I
>> illustrated this in the 2nd picture "Concrete example" which shows
>> instances of both MM. So on the right we can see the instance classes
>> of MyDSL: a container, a class named Ex1 which is an instance of
>> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
>> association between Ex1 and Ex2 and a class named Ex3 which is an
>> instance of DSL-Class#2. Now I want to map them to UML. Following my
>> example this would result in mapping:
>> * an instance of container to an uml-package with sterotype dsl-container
>> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
>> sterotype dsl-class#1
>> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
>> sterotype dsl-class#1
>> * an association between Ex1 and Ex2 to an uml association (which may
>> be stereotyped as "dsl-association if easier)
>> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
>> sterotype dsl-class#2
>>
>> Other Mapping possibilities (mentioned if my vision doesn't work in
>> time):
>> * Model-to-Model transformation is an option. I rather dislike this
>> for the classic reasons e.g. consistency between the models,
>> overwriting or synchronization of changes and -for me the most
>> important one- possible information loss due to the lack of
>> representation in one language. In my example this means that if a
>> "NotDslClass" exists in the left UML world for which I have no
>> representation in MyDSL there is no need to represent it in MyDSL. But
>> I guess I would be forced to handle it somehow not to loose
>> information in the back-to-uml transformation.
>> * Customized XML/XMI serialization through extending the XMLHelper
>> also seems error prone and seems to require a good knowledge of XMI,too.
>>
>> Ecore Mapping:
>> So a better approach would be to simulate the DSL-MM for my GMF-DSL
>> editor but actually work directly on an UML model. I found the EMF
>> part of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
>> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
>> found the some starting points or ideas how to realize it. My problem
>> is I can hardly value them nor I know a kind of best practice for
>> this. So it would be really nice to start a discussion about them or
>> if you say just read this f****** manual because I'm stuck right now ;(
>> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff)
>> looks like an option but my impression is that this is not really what
>> I want.
>> * Abuse the Model classes (or facades), normally generated by generate
>> model code as an adapter to eclipse-uml2 facades seems like a lot of
>> work implying a pretty good understanding of EMF.
>> * My Favourite: to use the Ecore2Ecore mapper and a customized
>> rescource handler as mentioned in EMF-EclipseCon p.158ff. My issue
>> here is that it's just mentioned and not really described, but it
>> seems exactly like what I want. This feeling is emphazied by features
>> like OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
>> resources about that or if there isn't a simple proof-of-concept
>> example somewhere.
>>
>> Thanks for reading already
>> -stefan
>>
>>
>> ------------------------------------------------------------ ------------
>>
>
Re: Connecting DSL-eCore w/ UML2 [message #471139 is a reply to message #471138] Mon, 11 June 2007 15:26 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi SKuhn,

For an example of the ecore2ecore mapping have a look at
org.eclipse.uml2.uml \model at UML2_2_UML.ecore2ecore and .ecore2xml. This
is a mapping between older and newer verion of UML and is used for forward
migration. The org.eclipse.uml2.uml.resource contains code behind the
migration. ( you might want to have a look at the migration guide from the
UML wiki .. it explains the mapping in a human readable format ).

There are draft articles for creating DSL in bugzilla [77413], and links
from the UML wiki.

You might also want to have a look at the UMLTools project for creating
editors for your own metamodel.

Hope that helps,

- James.


"SKuhn" <kuhn@oio.de> wrote in message
news:f4jhq2$76t$1@build.eclipse.org...
> Hi Ed,
>
> I expressed my hopes with "So it would be really nice to start a
> discussion about them or if you say just read this f****** manual
> because I'm stuck right now ;( " in a way that people can say I did it
> this way or this way is really awful/awesome or this is the best way to
> do it.
>
> and later on my 'question' in the last point "I'm wondering where I can
> find good resources about that or if there isn't a simple
> proof-of-concept example somewhere.".
>
> Anyway, the question-representation looks like this:
> Does anybody know good resources which may help me realizing My
> Favourite approach(the last) point under EcoreMapping?
>
> I can't imagine that this is a new problem/approach, so is there already
> a proof-of-concept example somewhere?
>
> > I does sound like it would be
> > perhaps a lot simpler to design your own independent model that has no
> > relation to UML2
> Of course ;). My problem is that I somehow need this representation in
> UML (I described this in Use Case).
>
> greets
> stefan
>
>
>
>
>
> Ed Merks schrieb:
> > Stefan,
> >
> > It is indeed a long post and I actually can't find a single "?" in it,
> > so I'm not really sure what to say. , but I don't think I really
understood well all the
> > issues and concerns...
> >
> >
> > SKuhn wrote:
> >> hi folks,
> >>
> >> the following text is quite long, so if you're in a rush just read
> >> abstract, look at the picture, read constraints, the idea and the last
> >> point of ecore-mapping.
> >>
> >> Abstract:
> >> basically I want to be able to read & write proper UML2 models with my
> >> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
> >> going to outline it in detail because I didn't find a good way to
> >> start / solve it.
> >>
> >> Use Case:
> >> We're working with MDSD and already have a cardridge for a domain.
> >> Right now, the generator gets the model from an uml2 tool. The
> >> graphical editor I have to make (using GMF) for this domain should be
> >> able to read and write uml2 models because of reasons like flexibility
> >> (wheather or not to use my editor) or extended control of an uml tool
> >> (e.g to model the DTOs in the same file). Both, UML2 Tools and the
> >> generator accept uml2 models from ecore.
> >>
> >> DSL:
> >> There various reasons why a tend to create my own domain specific
> >> language (DSL) for my graphical editor (GE) in contrast to use
> >> uml2.ecore:
> >> * a DSL which uses around 10 classes seems to be overburdened if it's
> >> based on the uml2.ecore with several hundred classes.
> >> * not that error prone because less confusion for the GMF framework
> >> and even more important for me.
> >> * some constraints are already implicit from my DSL Metamodel (MM) and
> >> the others should be easier to write on a simple MM.
> >> * It seems unhandy to create the uml2.ecore model code (after 5 hours
> >> I stopped the generation).
> >> * there must be a reason why GMF enforces the creation of DSLs rather
> >> than building a customized UML2 editor.
> >>
> >> The two worlds:
> >> This results in two worlds for my "MetaModel" sketch (see attached
> >> picture). In the left corner, we see famous UML with his well known
> >> metaclasses and packages. On the right corner we can see the young DSL
> >> also with metaclasses described in ecore. Now my experiments showed
> >> that the heavyweigth extensions in which I extended classes from the
> >> uml2.ecore are uml2-xmi compliant. So the only way to customize uml
> >> and still be able to use standard uml tools is the lightweight
> >> approach. I sketched this with the outer circle around uml.
> >>
> >> Contraints:
> >> * I assume that I'm not restricting UML and
> >> * that every DSL Class has a pendant in uml with a lack of semantics
> >> expressable by stereotypes.
> >> * both MM are defined in EMF.
> >>
> >> The idea:
> >> is to connect my DSL-MM with the uml2-MM. This should be realizable by
> >> creating a profile with sterotypes and enumerations for my DSL and
> >> represent my DSL classes in uml with the appropriate stereotype. I
> >> illustrated this in the 2nd picture "Concrete example" which shows
> >> instances of both MM. So on the right we can see the instance classes
> >> of MyDSL: a container, a class named Ex1 which is an instance of
> >> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
> >> association between Ex1 and Ex2 and a class named Ex3 which is an
> >> instance of DSL-Class#2. Now I want to map them to UML. Following my
> >> example this would result in mapping:
> >> * an instance of container to an uml-package with sterotype
dsl-container
> >> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
> >> sterotype dsl-class#1
> >> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
> >> sterotype dsl-class#1
> >> * an association between Ex1 and Ex2 to an uml association (which may
> >> be stereotyped as "dsl-association if easier)
> >> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
> >> sterotype dsl-class#2
> >>
> >> Other Mapping possibilities (mentioned if my vision doesn't work in
> >> time):
> >> * Model-to-Model transformation is an option. I rather dislike this
> >> for the classic reasons e.g. consistency between the models,
> >> overwriting or synchronization of changes and -for me the most
> >> important one- possible information loss due to the lack of
> >> representation in one language. In my example this means that if a
> >> "NotDslClass" exists in the left UML world for which I have no
> >> representation in MyDSL there is no need to represent it in MyDSL. But
> >> I guess I would be forced to handle it somehow not to loose
> >> information in the back-to-uml transformation.
> >> * Customized XML/XMI serialization through extending the XMLHelper
> >> also seems error prone and seems to require a good knowledge of
XMI,too.
> >>
> >> Ecore Mapping:
> >> So a better approach would be to simulate the DSL-MM for my GMF-DSL
> >> editor but actually work directly on an UML model. I found the EMF
> >> part of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
> >> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
> >> found the some starting points or ideas how to realize it. My problem
> >> is I can hardly value them nor I know a kind of best practice for
> >> this. So it would be really nice to start a discussion about them or
> >> if you say just read this f****** manual because I'm stuck right now ;(
> >> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff)
> >> looks like an option but my impression is that this is not really what
> >> I want.
> >> * Abuse the Model classes (or facades), normally generated by generate
> >> model code as an adapter to eclipse-uml2 facades seems like a lot of
> >> work implying a pretty good understanding of EMF.
> >> * My Favourite: to use the Ecore2Ecore mapper and a customized
> >> rescource handler as mentioned in EMF-EclipseCon p.158ff. My issue
> >> here is that it's just mentioned and not really described, but it
> >> seems exactly like what I want. This feeling is emphazied by features
> >> like OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
> >> resources about that or if there isn't a simple proof-of-concept
> >> example somewhere.
> >>
> >> Thanks for reading already
> >> -stefan
> >>
> >>
>
>> ------------------------------------------------------------ ------------
> >>
> >
Re: Connecting DSL-eCore w/ UML2 [message #471140 is a reply to message #471139] Mon, 11 June 2007 16:37 Go to previous messageGo to next message
Stefan Kuhn is currently offline Stefan KuhnFriend
Messages: 355
Registered: July 2009
Senior Member
hi james,

> For an example of the ecore2ecore mapping have a look at
> org.eclipse.uml2.uml \model at UML2_2_UML.ecore2ecore and .ecore2xml.
This
> is a mapping between older and newer verion of UML and is used for
forward
> migration. The org.eclipse.uml2.uml.resource contains code behind the
> migration. ( you might want to have a look at the migration guide
from the
> UML wiki .. it explains the mapping in a human readable format ).
I stumbled over it some weeks ago but skipped it because I thought it
has nothing to do with my problem. So I'm definitly going to take a look
on it soon. Thanks for the hint.

> There are draft articles for creating DSL in bugzilla [77413], and links
> from the UML wiki.
> You might also want to have a look at the UMLTools project for creating
> editors for your own metamodel.
I already looked at both. I played around with Heavyweight-Extensions
but it seemed preety much that other UML Tools e.g. MagicDraw won't
handle heavyweight extensions at all. So customizing the UML editor of
UMLTools is not an option neither.

I found an error in my first post:
"Now my experiments showed that the heavyweigth extensions in which I
extended classes from the uml2.ecore are !!!NOT!!! uml2-xmi compliant.
So the only way to customize uml and still be able to use standard uml
tools is the lightweight approach."

thanks so far
-stefan



>
> Hope that helps,
>
> - James.
>
>
> "SKuhn" <kuhn@oio.de> wrote in message
> news:f4jhq2$76t$1@build.eclipse.org...
>> Hi Ed,
>>
>> I expressed my hopes with "So it would be really nice to start a
>> discussion about them or if you say just read this f****** manual
>> because I'm stuck right now ;( " in a way that people can say I did it
>> this way or this way is really awful/awesome or this is the best way to
>> do it.
>>
>> and later on my 'question' in the last point "I'm wondering where I can
>> find good resources about that or if there isn't a simple
>> proof-of-concept example somewhere.".
>>
>> Anyway, the question-representation looks like this:
>> Does anybody know good resources which may help me realizing My
>> Favourite approach(the last) point under EcoreMapping?
>>
>> I can't imagine that this is a new problem/approach, so is there already
>> a proof-of-concept example somewhere?
>>
>> > I does sound like it would be
>> > perhaps a lot simpler to design your own independent model that has no
>> > relation to UML2
>> Of course ;). My problem is that I somehow need this representation in
>> UML (I described this in Use Case).
>>
>> greets
>> stefan
>>
>>
>>
>>
>>
>> Ed Merks schrieb:
>>> Stefan,
>>>
>>> It is indeed a long post and I actually can't find a single "?" in it,
>>> so I'm not really sure what to say. , but I don't think I really
> understood well all the
>>> issues and concerns...
>>>
>>>
>>> SKuhn wrote:
>>>> hi folks,
>>>>
>>>> the following text is quite long, so if you're in a rush just read
>>>> abstract, look at the picture, read constraints, the idea and the last
>>>> point of ecore-mapping.
>>>>
>>>> Abstract:
>>>> basically I want to be able to read & write proper UML2 models with my
>>>> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
>>>> going to outline it in detail because I didn't find a good way to
>>>> start / solve it.
>>>>
>>>> Use Case:
>>>> We're working with MDSD and already have a cardridge for a domain.
>>>> Right now, the generator gets the model from an uml2 tool. The
>>>> graphical editor I have to make (using GMF) for this domain should be
>>>> able to read and write uml2 models because of reasons like flexibility
>>>> (wheather or not to use my editor) or extended control of an uml tool
>>>> (e.g to model the DTOs in the same file). Both, UML2 Tools and the
>>>> generator accept uml2 models from ecore.
>>>>
>>>> DSL:
>>>> There various reasons why a tend to create my own domain specific
>>>> language (DSL) for my graphical editor (GE) in contrast to use
>>>> uml2.ecore:
>>>> * a DSL which uses around 10 classes seems to be overburdened if it's
>>>> based on the uml2.ecore with several hundred classes.
>>>> * not that error prone because less confusion for the GMF framework
>>>> and even more important for me.
>>>> * some constraints are already implicit from my DSL Metamodel (MM) and
>>>> the others should be easier to write on a simple MM.
>>>> * It seems unhandy to create the uml2.ecore model code (after 5 hours
>>>> I stopped the generation).
>>>> * there must be a reason why GMF enforces the creation of DSLs rather
>>>> than building a customized UML2 editor.
>>>>
>>>> The two worlds:
>>>> This results in two worlds for my "MetaModel" sketch (see attached
>>>> picture). In the left corner, we see famous UML with his well known
>>>> metaclasses and packages. On the right corner we can see the young DSL
>>>> also with metaclasses described in ecore. Now my experiments showed
>>>> that the heavyweigth extensions in which I extended classes from the
>>>> uml2.ecore are uml2-xmi compliant. So the only way to customize uml
>>>> and still be able to use standard uml tools is the lightweight
>>>> approach. I sketched this with the outer circle around uml.
>>>>
>>>> Contraints:
>>>> * I assume that I'm not restricting UML and
>>>> * that every DSL Class has a pendant in uml with a lack of semantics
>>>> expressable by stereotypes.
>>>> * both MM are defined in EMF.
>>>>
>>>> The idea:
>>>> is to connect my DSL-MM with the uml2-MM. This should be realizable by
>>>> creating a profile with sterotypes and enumerations for my DSL and
>>>> represent my DSL classes in uml with the appropriate stereotype. I
>>>> illustrated this in the 2nd picture "Concrete example" which shows
>>>> instances of both MM. So on the right we can see the instance classes
>>>> of MyDSL: a container, a class named Ex1 which is an instance of
>>>> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
>>>> association between Ex1 and Ex2 and a class named Ex3 which is an
>>>> instance of DSL-Class#2. Now I want to map them to UML. Following my
>>>> example this would result in mapping:
>>>> * an instance of container to an uml-package with sterotype
> dsl-container
>>>> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
>>>> sterotype dsl-class#1
>>>> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
>>>> sterotype dsl-class#1
>>>> * an association between Ex1 and Ex2 to an uml association (which may
>>>> be stereotyped as "dsl-association if easier)
>>>> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
>>>> sterotype dsl-class#2
>>>>
>>>> Other Mapping possibilities (mentioned if my vision doesn't work in
>>>> time):
>>>> * Model-to-Model transformation is an option. I rather dislike this
>>>> for the classic reasons e.g. consistency between the models,
>>>> overwriting or synchronization of changes and -for me the most
>>>> important one- possible information loss due to the lack of
>>>> representation in one language. In my example this means that if a
>>>> "NotDslClass" exists in the left UML world for which I have no
>>>> representation in MyDSL there is no need to represent it in MyDSL. But
>>>> I guess I would be forced to handle it somehow not to loose
>>>> information in the back-to-uml transformation.
>>>> * Customized XML/XMI serialization through extending the XMLHelper
>>>> also seems error prone and seems to require a good knowledge of
> XMI,too.
>>>> Ecore Mapping:
>>>> So a better approach would be to simulate the DSL-MM for my GMF-DSL
>>>> editor but actually work directly on an UML model. I found the EMF
>>>> part of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
>>>> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
>>>> found the some starting points or ideas how to realize it. My problem
>>>> is I can hardly value them nor I know a kind of best practice for
>>>> this. So it would be really nice to start a discussion about them or
>>>> if you say just read this f****** manual because I'm stuck right now ;(
>>>> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff)
>>>> looks like an option but my impression is that this is not really what
>>>> I want.
>>>> * Abuse the Model classes (or facades), normally generated by generate
>>>> model code as an adapter to eclipse-uml2 facades seems like a lot of
>>>> work implying a pretty good understanding of EMF.
>>>> * My Favourite: to use the Ecore2Ecore mapper and a customized
>>>> rescource handler as mentioned in EMF-EclipseCon p.158ff. My issue
>>>> here is that it's just mentioned and not really described, but it
>>>> seems exactly like what I want. This feeling is emphazied by features
>>>> like OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
>>>> resources about that or if there isn't a simple proof-of-concept
>>>> example somewhere.
>>>>
>>>> Thanks for reading already
>>>> -stefan
>>>>
>>>>
>>> ------------------------------------------------------------ ------------
>
>
Re: Connecting DSL-eCore w/ UML2 [message #471142 is a reply to message #471140] Mon, 11 June 2007 22:36 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: carrasco.ModelDrivenDevelopment.co.uk

My 2 cents:

Two forces:
You must facilitate modeling of instances of your DSL in your Tool.
You must interoperate with UML tools.

Deal with them separately:

Do your custom DSL editor, i.e. with GMF
Convert to/from Eclipse UML2.1 with Model2Model transformations,
Save UML2 interoperable .xmi files from Eclipse UML2.1
(some tools will not interoperate with the default .xmi from Eclipse)
Keep asking, to figure out how to interoperate with Diagrams
from other tools.

Cheers,
Antonio








"SKuhn" <kuhn@oio.de> wrote in message
news:f4jtnn$d33$1@build.eclipse.org...
> hi james,
>
> > For an example of the ecore2ecore mapping have a look at
> > org.eclipse.uml2.uml \model at UML2_2_UML.ecore2ecore and .ecore2xml.
> This
> > is a mapping between older and newer verion of UML and is used for
> forward
> > migration. The org.eclipse.uml2.uml.resource contains code behind the
> > migration. ( you might want to have a look at the migration guide
> from the
> > UML wiki .. it explains the mapping in a human readable format ).
> I stumbled over it some weeks ago but skipped it because I thought it has
> nothing to do with my problem. So I'm definitly going to take a look on it
> soon. Thanks for the hint.
>
> > There are draft articles for creating DSL in bugzilla [77413], and links
> > from the UML wiki.
> > You might also want to have a look at the UMLTools project for creating
> > editors for your own metamodel.
> I already looked at both. I played around with Heavyweight-Extensions but
> it seemed preety much that other UML Tools e.g. MagicDraw won't handle
> heavyweight extensions at all. So customizing the UML editor of UMLTools
> is not an option neither.
>
> I found an error in my first post:
> "Now my experiments showed that the heavyweigth extensions in which I
> extended classes from the uml2.ecore are !!!NOT!!! uml2-xmi compliant. So
> the only way to customize uml and still be able to use standard uml tools
> is the lightweight approach."
>
> thanks so far
> -stefan
>
>
>
>>
>> Hope that helps,
>>
>> - James.
>>
>>
>> "SKuhn" <kuhn@oio.de> wrote in message
>> news:f4jhq2$76t$1@build.eclipse.org...
>>> Hi Ed,
>>>
>>> I expressed my hopes with "So it would be really nice to start a
>>> discussion about them or if you say just read this f****** manual
>>> because I'm stuck right now ;( " in a way that people can say I did it
>>> this way or this way is really awful/awesome or this is the best way to
>>> do it.
>>>
>>> and later on my 'question' in the last point "I'm wondering where I can
>>> find good resources about that or if there isn't a simple
>>> proof-of-concept example somewhere.".
>>>
>>> Anyway, the question-representation looks like this:
>>> Does anybody know good resources which may help me realizing My
>>> Favourite approach(the last) point under EcoreMapping?
>>>
>>> I can't imagine that this is a new problem/approach, so is there already
>>> a proof-of-concept example somewhere?
>>>
>>> > I does sound like it would be
>>> > perhaps a lot simpler to design your own independent model that has
>>> no
>>> > relation to UML2
>>> Of course ;). My problem is that I somehow need this representation in
>>> UML (I described this in Use Case).
>>>
>>> greets
>>> stefan
>>>
>>>
>>>
>>>
>>>
>>> Ed Merks schrieb:
>>>> Stefan,
>>>>
>>>> It is indeed a long post and I actually can't find a single "?" in it,
>>>> so I'm not really sure what to say. , but I don't think I really
>> understood well all the
>>>> issues and concerns...
>>>>
>>>>
>>>> SKuhn wrote:
>>>>> hi folks,
>>>>>
>>>>> the following text is quite long, so if you're in a rush just read
>>>>> abstract, look at the picture, read constraints, the idea and the last
>>>>> point of ecore-mapping.
>>>>>
>>>>> Abstract:
>>>>> basically I want to be able to read & write proper UML2 models with my
>>>>> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
>>>>> going to outline it in detail because I didn't find a good way to
>>>>> start / solve it.
>>>>>
>>>>> Use Case:
>>>>> We're working with MDSD and already have a cardridge for a domain.
>>>>> Right now, the generator gets the model from an uml2 tool. The
>>>>> graphical editor I have to make (using GMF) for this domain should be
>>>>> able to read and write uml2 models because of reasons like flexibility
>>>>> (wheather or not to use my editor) or extended control of an uml tool
>>>>> (e.g to model the DTOs in the same file). Both, UML2 Tools and the
>>>>> generator accept uml2 models from ecore.
>>>>>
>>>>> DSL:
>>>>> There various reasons why a tend to create my own domain specific
>>>>> language (DSL) for my graphical editor (GE) in contrast to use
>>>>> uml2.ecore:
>>>>> * a DSL which uses around 10 classes seems to be overburdened if it's
>>>>> based on the uml2.ecore with several hundred classes.
>>>>> * not that error prone because less confusion for the GMF framework
>>>>> and even more important for me.
>>>>> * some constraints are already implicit from my DSL Metamodel (MM) and
>>>>> the others should be easier to write on a simple MM.
>>>>> * It seems unhandy to create the uml2.ecore model code (after 5 hours
>>>>> I stopped the generation).
>>>>> * there must be a reason why GMF enforces the creation of DSLs rather
>>>>> than building a customized UML2 editor.
>>>>>
>>>>> The two worlds:
>>>>> This results in two worlds for my "MetaModel" sketch (see attached
>>>>> picture). In the left corner, we see famous UML with his well known
>>>>> metaclasses and packages. On the right corner we can see the young DSL
>>>>> also with metaclasses described in ecore. Now my experiments showed
>>>>> that the heavyweigth extensions in which I extended classes from the
>>>>> uml2.ecore are uml2-xmi compliant. So the only way to customize uml
>>>>> and still be able to use standard uml tools is the lightweight
>>>>> approach. I sketched this with the outer circle around uml.
>>>>>
>>>>> Contraints:
>>>>> * I assume that I'm not restricting UML and
>>>>> * that every DSL Class has a pendant in uml with a lack of semantics
>>>>> expressable by stereotypes.
>>>>> * both MM are defined in EMF.
>>>>>
>>>>> The idea:
>>>>> is to connect my DSL-MM with the uml2-MM. This should be realizable by
>>>>> creating a profile with sterotypes and enumerations for my DSL and
>>>>> represent my DSL classes in uml with the appropriate stereotype. I
>>>>> illustrated this in the 2nd picture "Concrete example" which shows
>>>>> instances of both MM. So on the right we can see the instance classes
>>>>> of MyDSL: a container, a class named Ex1 which is an instance of
>>>>> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
>>>>> association between Ex1 and Ex2 and a class named Ex3 which is an
>>>>> instance of DSL-Class#2. Now I want to map them to UML. Following my
>>>>> example this would result in mapping:
>>>>> * an instance of container to an uml-package with sterotype
>> dsl-container
>>>>> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
>>>>> sterotype dsl-class#1
>>>>> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
>>>>> sterotype dsl-class#1
>>>>> * an association between Ex1 and Ex2 to an uml association (which may
>>>>> be stereotyped as "dsl-association if easier)
>>>>> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
>>>>> sterotype dsl-class#2
>>>>>
>>>>> Other Mapping possibilities (mentioned if my vision doesn't work in
>>>>> time):
>>>>> * Model-to-Model transformation is an option. I rather dislike this
>>>>> for the classic reasons e.g. consistency between the models,
>>>>> overwriting or synchronization of changes and -for me the most
>>>>> important one- possible information loss due to the lack of
>>>>> representation in one language. In my example this means that if a
>>>>> "NotDslClass" exists in the left UML world for which I have no
>>>>> representation in MyDSL there is no need to represent it in MyDSL. But
>>>>> I guess I would be forced to handle it somehow not to loose
>>>>> information in the back-to-uml transformation.
>>>>> * Customized XML/XMI serialization through extending the XMLHelper
>>>>> also seems error prone and seems to require a good knowledge of
>> XMI,too.
>>>>> Ecore Mapping:
>>>>> So a better approach would be to simulate the DSL-MM for my GMF-DSL
>>>>> editor but actually work directly on an UML model. I found the EMF
>>>>> part of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
>>>>> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
>>>>> found the some starting points or ideas how to realize it. My problem
>>>>> is I can hardly value them nor I know a kind of best practice for
>>>>> this. So it would be really nice to start a discussion about them or
>>>>> if you say just read this f****** manual because I'm stuck right now
>>>>> ;(
>>>>> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff)
>>>>> looks like an option but my impression is that this is not really what
>>>>> I want.
>>>>> * Abuse the Model classes (or facades), normally generated by generate
>>>>> model code as an adapter to eclipse-uml2 facades seems like a lot of
>>>>> work implying a pretty good understanding of EMF.
>>>>> * My Favourite: to use the Ecore2Ecore mapper and a customized
>>>>> rescource handler as mentioned in EMF-EclipseCon p.158ff. My issue
>>>>> here is that it's just mentioned and not really described, but it
>>>>> seems exactly like what I want. This feeling is emphazied by features
>>>>> like OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
>>>>> resources about that or if there isn't a simple proof-of-concept
>>>>> example somewhere.
>>>>>
>>>>> Thanks for reading already
>>>>> -stefan
>>>>>
>>>>>
>>>> ------------------------------------------------------------ ------------
>>
Re: Connecting DSL-eCore w/ UML2 [message #471145 is a reply to message #471129] Tue, 12 June 2007 08:31 Go to previous messageGo to next message
Marco MosconiFriend
Messages: 63
Registered: July 2009
Member
Hi,

I didn't read through the whole post, but if you just want to bridge
your DSL with UML2 Profiles, perhaps the following is exactly what you want:
http://www.eclipse.org/gmt/amw/usecases/umlprofiles/

Regards,
Marco

SKuhn schrieb:
> hi folks,
>
> the following text is quite long, so if you're in a rush just read
> abstract, look at the picture, read constraints, the idea and the last
> point of ecore-mapping.
>
> Abstract:
> basically I want to be able to read & write proper UML2 models with my
> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
> going to outline it in detail because I didn't find a good way to start
> / solve it.
>
> Use Case:
> We're working with MDSD and already have a cardridge for a domain. Right
> now, the generator gets the model from an uml2 tool. The graphical
> editor I have to make (using GMF) for this domain should be able to read
> and write uml2 models because of reasons like flexibility (wheather or
> not to use my editor) or extended control of an uml tool (e.g to model
> the DTOs in the same file). Both, UML2 Tools and the generator accept
> uml2 models from ecore.
>
> DSL:
> There various reasons why a tend to create my own domain specific
> language (DSL) for my graphical editor (GE) in contrast to use uml2.ecore:
> * a DSL which uses around 10 classes seems to be overburdened if it's
> based on the uml2.ecore with several hundred classes.
> * not that error prone because less confusion for the GMF framework and
> even more important for me.
> * some constraints are already implicit from my DSL Metamodel (MM) and
> the others should be easier to write on a simple MM.
> * It seems unhandy to create the uml2.ecore model code (after 5 hours I
> stopped the generation).
> * there must be a reason why GMF enforces the creation of DSLs rather
> than building a customized UML2 editor.
>
> The two worlds:
> This results in two worlds for my "MetaModel" sketch (see attached
> picture). In the left corner, we see famous UML with his well known
> metaclasses and packages. On the right corner we can see the young DSL
> also with metaclasses described in ecore. Now my experiments showed that
> the heavyweigth extensions in which I extended classes from the
> uml2.ecore are uml2-xmi compliant. So the only way to customize uml and
> still be able to use standard uml tools is the lightweight approach. I
> sketched this with the outer circle around uml.
>
> Contraints:
> * I assume that I'm not restricting UML and
> * that every DSL Class has a pendant in uml with a lack of semantics
> expressable by stereotypes.
> * both MM are defined in EMF.
>
> The idea:
> is to connect my DSL-MM with the uml2-MM. This should be realizable by
> creating a profile with sterotypes and enumerations for my DSL and
> represent my DSL classes in uml with the appropriate stereotype. I
> illustrated this in the 2nd picture "Concrete example" which shows
> instances of both MM. So on the right we can see the instance classes of
> MyDSL: a container, a class named Ex1 which is an instance of
> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
> association between Ex1 and Ex2 and a class named Ex3 which is an
> instance of DSL-Class#2. Now I want to map them to UML. Following my
> example this would result in mapping:
> * an instance of container to an uml-package with sterotype dsl-container
> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
> sterotype dsl-class#1
> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
> sterotype dsl-class#1
> * an association between Ex1 and Ex2 to an uml association (which may be
> stereotyped as "dsl-association if easier)
> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
> sterotype dsl-class#2
>
> Other Mapping possibilities (mentioned if my vision doesn't work in time):
> * Model-to-Model transformation is an option. I rather dislike this for
> the classic reasons e.g. consistency between the models, overwriting or
> synchronization of changes and -for me the most important one- possible
> information loss due to the lack of representation in one language. In
> my example this means that if a "NotDslClass" exists in the left UML
> world for which I have no representation in MyDSL there is no need to
> represent it in MyDSL. But I guess I would be forced to handle it
> somehow not to loose information in the back-to-uml transformation.
> * Customized XML/XMI serialization through extending the XMLHelper also
> seems error prone and seems to require a good knowledge of XMI,too.
>
> Ecore Mapping:
> So a better approach would be to simulate the DSL-MM for my GMF-DSL
> editor but actually work directly on an UML model. I found the EMF part
> of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
> found the some starting points or ideas how to realize it. My problem is
> I can hardly value them nor I know a kind of best practice for this. So
> it would be really nice to start a discussion about them or if you say
> just read this f****** manual because I'm stuck right now ;(
> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff) looks
> like an option but my impression is that this is not really what I want.
> * Abuse the Model classes (or facades), normally generated by generate
> model code as an adapter to eclipse-uml2 facades seems like a lot of
> work implying a pretty good understanding of EMF.
> * My Favourite: to use the Ecore2Ecore mapper and a customized rescource
> handler as mentioned in EMF-EclipseCon p.158ff. My issue here is that
> it's just mentioned and not really described, but it seems exactly like
> what I want. This feeling is emphazied by features like
> OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
> resources about that or if there isn't a simple proof-of-concept example
> somewhere.
>
> Thanks for reading already
> -stefan
>
>
> ------------------------------------------------------------ ------------
>
Re: Connecting DSL-eCore w/ UML2 [message #471147 is a reply to message #471145] Tue, 12 June 2007 14:58 Go to previous messageGo to next message
Stefan Kuhn is currently offline Stefan KuhnFriend
Messages: 355
Registered: July 2009
Senior Member
yeah, if it's really working it is- I'll keep you up to date.

Marco Mosconi schrieb:
> Hi,
>
> I didn't read through the whole post, but if you just want to bridge
> your DSL with UML2 Profiles, perhaps the following is exactly what you
> want:
> http://www.eclipse.org/gmt/amw/usecases/umlprofiles/
>
> Regards,
> Marco
>
> SKuhn schrieb:
>> hi folks,
>>
>> the following text is quite long, so if you're in a rush just read
>> abstract, look at the picture, read constraints, the idea and the last
>> point of ecore-mapping.
>>
>> Abstract:
>> basically I want to be able to read & write proper UML2 models with my
>> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
>> going to outline it in detail because I didn't find a good way to
>> start / solve it.
>>
>> Use Case:
>> We're working with MDSD and already have a cardridge for a domain.
>> Right now, the generator gets the model from an uml2 tool. The
>> graphical editor I have to make (using GMF) for this domain should be
>> able to read and write uml2 models because of reasons like flexibility
>> (wheather or not to use my editor) or extended control of an uml tool
>> (e.g to model the DTOs in the same file). Both, UML2 Tools and the
>> generator accept uml2 models from ecore.
>>
>> DSL:
>> There various reasons why a tend to create my own domain specific
>> language (DSL) for my graphical editor (GE) in contrast to use
>> uml2.ecore:
>> * a DSL which uses around 10 classes seems to be overburdened if it's
>> based on the uml2.ecore with several hundred classes.
>> * not that error prone because less confusion for the GMF framework
>> and even more important for me.
>> * some constraints are already implicit from my DSL Metamodel (MM) and
>> the others should be easier to write on a simple MM.
>> * It seems unhandy to create the uml2.ecore model code (after 5 hours
>> I stopped the generation).
>> * there must be a reason why GMF enforces the creation of DSLs rather
>> than building a customized UML2 editor.
>>
>> The two worlds:
>> This results in two worlds for my "MetaModel" sketch (see attached
>> picture). In the left corner, we see famous UML with his well known
>> metaclasses and packages. On the right corner we can see the young DSL
>> also with metaclasses described in ecore. Now my experiments showed
>> that the heavyweigth extensions in which I extended classes from the
>> uml2.ecore are uml2-xmi compliant. So the only way to customize uml
>> and still be able to use standard uml tools is the lightweight
>> approach. I sketched this with the outer circle around uml.
>>
>> Contraints:
>> * I assume that I'm not restricting UML and
>> * that every DSL Class has a pendant in uml with a lack of semantics
>> expressable by stereotypes.
>> * both MM are defined in EMF.
>>
>> The idea:
>> is to connect my DSL-MM with the uml2-MM. This should be realizable by
>> creating a profile with sterotypes and enumerations for my DSL and
>> represent my DSL classes in uml with the appropriate stereotype. I
>> illustrated this in the 2nd picture "Concrete example" which shows
>> instances of both MM. So on the right we can see the instance classes
>> of MyDSL: a container, a class named Ex1 which is an instance of
>> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
>> association between Ex1 and Ex2 and a class named Ex3 which is an
>> instance of DSL-Class#2. Now I want to map them to UML. Following my
>> example this would result in mapping:
>> * an instance of container to an uml-package with sterotype dsl-container
>> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
>> sterotype dsl-class#1
>> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
>> sterotype dsl-class#1
>> * an association between Ex1 and Ex2 to an uml association (which may
>> be stereotyped as "dsl-association if easier)
>> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
>> sterotype dsl-class#2
>>
>> Other Mapping possibilities (mentioned if my vision doesn't work in
>> time):
>> * Model-to-Model transformation is an option. I rather dislike this
>> for the classic reasons e.g. consistency between the models,
>> overwriting or synchronization of changes and -for me the most
>> important one- possible information loss due to the lack of
>> representation in one language. In my example this means that if a
>> "NotDslClass" exists in the left UML world for which I have no
>> representation in MyDSL there is no need to represent it in MyDSL. But
>> I guess I would be forced to handle it somehow not to loose
>> information in the back-to-uml transformation.
>> * Customized XML/XMI serialization through extending the XMLHelper
>> also seems error prone and seems to require a good knowledge of XMI,too.
>>
>> Ecore Mapping:
>> So a better approach would be to simulate the DSL-MM for my GMF-DSL
>> editor but actually work directly on an UML model. I found the EMF
>> part of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
>> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
>> found the some starting points or ideas how to realize it. My problem
>> is I can hardly value them nor I know a kind of best practice for
>> this. So it would be really nice to start a discussion about them or
>> if you say just read this f****** manual because I'm stuck right now ;(
>> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff)
>> looks like an option but my impression is that this is not really what
>> I want.
>> * Abuse the Model classes (or facades), normally generated by generate
>> model code as an adapter to eclipse-uml2 facades seems like a lot of
>> work implying a pretty good understanding of EMF.
>> * My Favourite: to use the Ecore2Ecore mapper and a customized
>> rescource handler as mentioned in EMF-EclipseCon p.158ff. My issue
>> here is that it's just mentioned and not really described, but it
>> seems exactly like what I want. This feeling is emphazied by features
>> like OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
>> resources about that or if there isn't a simple proof-of-concept
>> example somewhere.
>>
>> Thanks for reading already
>> -stefan
>>
>>
>> ------------------------------------------------------------ ------------
>>
Re: Connecting DSL-eCore w/ UML2 [message #471158 is a reply to message #471142] Wed, 13 June 2007 08:02 Go to previous messageGo to next message
Stefan Kuhn is currently offline Stefan KuhnFriend
Messages: 355
Registered: July 2009
Senior Member
hi antonio,

> You must facilitate modeling of instances of your DSL in your Tool.
> You must interoperate with UML tools.
right.

I've got some concerns about M2M Transformation:
* Possible data loss, because my target model (MyDSL) doensn't represent
all the elements I have in my source model (e.g. UML+Profile). (main
concern)
* It looks like my problem already is adressed with ecore2ecore (using
the OPTION_RECORD_UNKNOWN_FEATURE) with pre/post-processing the data
with an recource handler.
* M2M implies addional overhead, serverals RecourceSets and I guess no
chance for event based handling (this would result in sync 'models', so
I can use eclipse with MyGui4MyDSL and the eclipse UML2 modelling tools
at the same time) (this point is -of course- just nice to have).


cheers
stefan

Antonio Carrasco schrieb:
> My 2 cents:
>
> Two forces:
> You must facilitate modeling of instances of your DSL in your Tool.
> You must interoperate with UML tools.
>
> Deal with them separately:
>
> Do your custom DSL editor, i.e. with GMF
> Convert to/from Eclipse UML2.1 with Model2Model transformations,
> Save UML2 interoperable .xmi files from Eclipse UML2.1
> (some tools will not interoperate with the default .xmi from Eclipse)
> Keep asking, to figure out how to interoperate with Diagrams
> from other tools.
>
> Cheers,
> Antonio
>
>
>
>
>
>
>
>
> "SKuhn" <kuhn@oio.de> wrote in message
> news:f4jtnn$d33$1@build.eclipse.org...
>> hi james,
>>
>>> For an example of the ecore2ecore mapping have a look at
>>> org.eclipse.uml2.uml \model at UML2_2_UML.ecore2ecore and .ecore2xml.
>> This
>>> is a mapping between older and newer verion of UML and is used for
>> forward
>>> migration. The org.eclipse.uml2.uml.resource contains code behind the
>>> migration. ( you might want to have a look at the migration guide
>> from the
>>> UML wiki .. it explains the mapping in a human readable format ).
>> I stumbled over it some weeks ago but skipped it because I thought it has
>> nothing to do with my problem. So I'm definitly going to take a look on it
>> soon. Thanks for the hint.
>>
>>> There are draft articles for creating DSL in bugzilla [77413], and links
>>> from the UML wiki.
>>> You might also want to have a look at the UMLTools project for creating
>>> editors for your own metamodel.
>> I already looked at both. I played around with Heavyweight-Extensions but
>> it seemed preety much that other UML Tools e.g. MagicDraw won't handle
>> heavyweight extensions at all. So customizing the UML editor of UMLTools
>> is not an option neither.
>>
>> I found an error in my first post:
>> "Now my experiments showed that the heavyweigth extensions in which I
>> extended classes from the uml2.ecore are !!!NOT!!! uml2-xmi compliant. So
>> the only way to customize uml and still be able to use standard uml tools
>> is the lightweight approach."
>>
>> thanks so far
>> -stefan
>>
>>
>>
>>> Hope that helps,
>>>
>>> - James.
>>>
>>>
>>> "SKuhn" <kuhn@oio.de> wrote in message
>>> news:f4jhq2$76t$1@build.eclipse.org...
>>>> Hi Ed,
>>>>
>>>> I expressed my hopes with "So it would be really nice to start a
>>>> discussion about them or if you say just read this f****** manual
>>>> because I'm stuck right now ;( " in a way that people can say I did it
>>>> this way or this way is really awful/awesome or this is the best way to
>>>> do it.
>>>>
>>>> and later on my 'question' in the last point "I'm wondering where I can
>>>> find good resources about that or if there isn't a simple
>>>> proof-of-concept example somewhere.".
>>>>
>>>> Anyway, the question-representation looks like this:
>>>> Does anybody know good resources which may help me realizing My
>>>> Favourite approach(the last) point under EcoreMapping?
>>>>
>>>> I can't imagine that this is a new problem/approach, so is there already
>>>> a proof-of-concept example somewhere?
>>>>
>>>> > I does sound like it would be
>>>> > perhaps a lot simpler to design your own independent model that has
>>>> no
>>>> > relation to UML2
>>>> Of course ;). My problem is that I somehow need this representation in
>>>> UML (I described this in Use Case).
>>>>
>>>> greets
>>>> stefan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Ed Merks schrieb:
>>>>> Stefan,
>>>>>
>>>>> It is indeed a long post and I actually can't find a single "?" in it,
>>>>> so I'm not really sure what to say. , but I don't think I really
>>> understood well all the
>>>>> issues and concerns...
>>>>>
>>>>>
>>>>> SKuhn wrote:
>>>>>> hi folks,
>>>>>>
>>>>>> the following text is quite long, so if you're in a rush just read
>>>>>> abstract, look at the picture, read constraints, the idea and the last
>>>>>> point of ecore-mapping.
>>>>>>
>>>>>> Abstract:
>>>>>> basically I want to be able to read & write proper UML2 models with my
>>>>>> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
>>>>>> going to outline it in detail because I didn't find a good way to
>>>>>> start / solve it.
>>>>>>
>>>>>> Use Case:
>>>>>> We're working with MDSD and already have a cardridge for a domain.
>>>>>> Right now, the generator gets the model from an uml2 tool. The
>>>>>> graphical editor I have to make (using GMF) for this domain should be
>>>>>> able to read and write uml2 models because of reasons like flexibility
>>>>>> (wheather or not to use my editor) or extended control of an uml tool
>>>>>> (e.g to model the DTOs in the same file). Both, UML2 Tools and the
>>>>>> generator accept uml2 models from ecore.
>>>>>>
>>>>>> DSL:
>>>>>> There various reasons why a tend to create my own domain specific
>>>>>> language (DSL) for my graphical editor (GE) in contrast to use
>>>>>> uml2.ecore:
>>>>>> * a DSL which uses around 10 classes seems to be overburdened if it's
>>>>>> based on the uml2.ecore with several hundred classes.
>>>>>> * not that error prone because less confusion for the GMF framework
>>>>>> and even more important for me.
>>>>>> * some constraints are already implicit from my DSL Metamodel (MM) and
>>>>>> the others should be easier to write on a simple MM.
>>>>>> * It seems unhandy to create the uml2.ecore model code (after 5 hours
>>>>>> I stopped the generation).
>>>>>> * there must be a reason why GMF enforces the creation of DSLs rather
>>>>>> than building a customized UML2 editor.
>>>>>>
>>>>>> The two worlds:
>>>>>> This results in two worlds for my "MetaModel" sketch (see attached
>>>>>> picture). In the left corner, we see famous UML with his well known
>>>>>> metaclasses and packages. On the right corner we can see the young DSL
>>>>>> also with metaclasses described in ecore. Now my experiments showed
>>>>>> that the heavyweigth extensions in which I extended classes from the
>>>>>> uml2.ecore are uml2-xmi compliant. So the only way to customize uml
>>>>>> and still be able to use standard uml tools is the lightweight
>>>>>> approach. I sketched this with the outer circle around uml.
>>>>>>
>>>>>> Contraints:
>>>>>> * I assume that I'm not restricting UML and
>>>>>> * that every DSL Class has a pendant in uml with a lack of semantics
>>>>>> expressable by stereotypes.
>>>>>> * both MM are defined in EMF.
>>>>>>
>>>>>> The idea:
>>>>>> is to connect my DSL-MM with the uml2-MM. This should be realizable by
>>>>>> creating a profile with sterotypes and enumerations for my DSL and
>>>>>> represent my DSL classes in uml with the appropriate stereotype. I
>>>>>> illustrated this in the 2nd picture "Concrete example" which shows
>>>>>> instances of both MM. So on the right we can see the instance classes
>>>>>> of MyDSL: a container, a class named Ex1 which is an instance of
>>>>>> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
>>>>>> association between Ex1 and Ex2 and a class named Ex3 which is an
>>>>>> instance of DSL-Class#2. Now I want to map them to UML. Following my
>>>>>> example this would result in mapping:
>>>>>> * an instance of container to an uml-package with sterotype
>>> dsl-container
>>>>>> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
>>>>>> sterotype dsl-class#1
>>>>>> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
>>>>>> sterotype dsl-class#1
>>>>>> * an association between Ex1 and Ex2 to an uml association (which may
>>>>>> be stereotyped as "dsl-association if easier)
>>>>>> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
>>>>>> sterotype dsl-class#2
>>>>>>
>>>>>> Other Mapping possibilities (mentioned if my vision doesn't work in
>>>>>> time):
>>>>>> * Model-to-Model transformation is an option. I rather dislike this
>>>>>> for the classic reasons e.g. consistency between the models,
>>>>>> overwriting or synchronization of changes and -for me the most
>>>>>> important one- possible information loss due to the lack of
>>>>>> representation in one language. In my example this means that if a
>>>>>> "NotDslClass" exists in the left UML world for which I have no
>>>>>> representation in MyDSL there is no need to represent it in MyDSL. But
>>>>>> I guess I would be forced to handle it somehow not to loose
>>>>>> information in the back-to-uml transformation.
>>>>>> * Customized XML/XMI serialization through extending the XMLHelper
>>>>>> also seems error prone and seems to require a good knowledge of
>>> XMI,too.
>>>>>> Ecore Mapping:
>>>>>> So a better approach would be to simulate the DSL-MM for my GMF-DSL
>>>>>> editor but actually work directly on an UML model. I found the EMF
>>>>>> part of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
>>>>>> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
>>>>>> found the some starting points or ideas how to realize it. My problem
>>>>>> is I can hardly value them nor I know a kind of best practice for
>>>>>> this. So it would be really nice to start a discussion about them or
>>>>>> if you say just read this f****** manual because I'm stuck right now
>>>>>> ;(
>>>>>> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff)
>>>>>> looks like an option but my impression is that this is not really what
>>>>>> I want.
>>>>>> * Abuse the Model classes (or facades), normally generated by generate
>>>>>> model code as an adapter to eclipse-uml2 facades seems like a lot of
>>>>>> work implying a pretty good understanding of EMF.
>>>>>> * My Favourite: to use the Ecore2Ecore mapper and a customized
>>>>>> rescource handler as mentioned in EMF-EclipseCon p.158ff. My issue
>>>>>> here is that it's just mentioned and not really described, but it
>>>>>> seems exactly like what I want. This feeling is emphazied by features
>>>>>> like OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
>>>>>> resources about that or if there isn't a simple proof-of-concept
>>>>>> example somewhere.
>>>>>>
>>>>>> Thanks for reading already
>>>>>> -stefan
>>>>>>
>>>>>>
>>>>> ------------------------------------------------------------ ------------
>
Re: Connecting DSL-eCore w/ UML2 [message #471227 is a reply to message #471138] Thu, 05 July 2007 13:12 Go to previous messageGo to next message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Stefan,

Several of the approaches you describe seem valid. A major difference (an
perhaps a deciding factor) between them seems (to me) to be whether
synchronization between the two domains (your DSL and UML, which
incidentally can also be viewed as a DSL) happens dynamically (at the
in-memory object representation level) or only when a resource is
serialized/deserialized.

The Ecore2Ecore model was designed as a mechanism to describe simple
mappings between two arbitrary EMF (Ecore) models. Ecore2XML was introduced
to provide an alternative representation of suuch mappings that is tailored
to (de)serialization in XML/XMI. In practice, Ecore2XML is really only
useful for mapping between two models that are similar in structure - as
James has mentioned, it is being used successfully in UML2 to migrate models
between different versions of UML. Note that complex mappings still need to
be handled using custom resource handlers and/or post processors (as
described in the advanced EMF tutorials from EclipseCon 2006 and 2007).
Beyond the EMF tutorials, perhaps the best source of information is the
source code. James has already provided you with pointers to the releated
classes in UML2... has this been of some help?

Kenn

"SKuhn" <kuhn@oio.de> wrote in message
news:f4jhq2$76t$1@build.eclipse.org...
> Hi Ed,
>
> I expressed my hopes with "So it would be really nice to start a
> discussion about them or if you say just read this f****** manual because
> I'm stuck right now ;( " in a way that people can say I did it this way
> or this way is really awful/awesome or this is the best way to do it.
>
> and later on my 'question' in the last point "I'm wondering where I can
> find good resources about that or if there isn't a simple proof-of-concept
> example somewhere.".
>
> Anyway, the question-representation looks like this:
> Does anybody know good resources which may help me realizing My Favourite
> approach(the last) point under EcoreMapping?
>
> I can't imagine that this is a new problem/approach, so is there already a
> proof-of-concept example somewhere?
>
> > I does sound like it would be
> > perhaps a lot simpler to design your own independent model that has no
> > relation to UML2
> Of course ;). My problem is that I somehow need this representation in UML
> (I described this in Use Case).
>
> greets
> stefan
>
>
>
>
>
> Ed Merks schrieb:
>> Stefan,
>>
>> It is indeed a long post and I actually can't find a single "?" in it, so
>> I'm not really sure what to say. , but I don't think I really understood
>> well all the issues and concerns...
>>
>>
>> SKuhn wrote:
>>> hi folks,
>>>
>>> the following text is quite long, so if you're in a rush just read
>>> abstract, look at the picture, read constraints, the idea and the last
>>> point of ecore-mapping.
>>>
>>> Abstract:
>>> basically I want to be able to read & write proper UML2 models with my
>>> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
>>> going to outline it in detail because I didn't find a good way to start
>>> / solve it.
>>>
>>> Use Case:
>>> We're working with MDSD and already have a cardridge for a domain. Right
>>> now, the generator gets the model from an uml2 tool. The graphical
>>> editor I have to make (using GMF) for this domain should be able to read
>>> and write uml2 models because of reasons like flexibility (wheather or
>>> not to use my editor) or extended control of an uml tool (e.g to model
>>> the DTOs in the same file). Both, UML2 Tools and the generator accept
>>> uml2 models from ecore.
>>>
>>> DSL:
>>> There various reasons why a tend to create my own domain specific
>>> language (DSL) for my graphical editor (GE) in contrast to use
>>> uml2.ecore:
>>> * a DSL which uses around 10 classes seems to be overburdened if it's
>>> based on the uml2.ecore with several hundred classes.
>>> * not that error prone because less confusion for the GMF framework and
>>> even more important for me.
>>> * some constraints are already implicit from my DSL Metamodel (MM) and
>>> the others should be easier to write on a simple MM.
>>> * It seems unhandy to create the uml2.ecore model code (after 5 hours I
>>> stopped the generation).
>>> * there must be a reason why GMF enforces the creation of DSLs rather
>>> than building a customized UML2 editor.
>>>
>>> The two worlds:
>>> This results in two worlds for my "MetaModel" sketch (see attached
>>> picture). In the left corner, we see famous UML with his well known
>>> metaclasses and packages. On the right corner we can see the young DSL
>>> also with metaclasses described in ecore. Now my experiments showed that
>>> the heavyweigth extensions in which I extended classes from the
>>> uml2.ecore are uml2-xmi compliant. So the only way to customize uml and
>>> still be able to use standard uml tools is the lightweight approach. I
>>> sketched this with the outer circle around uml.
>>>
>>> Contraints:
>>> * I assume that I'm not restricting UML and
>>> * that every DSL Class has a pendant in uml with a lack of semantics
>>> expressable by stereotypes.
>>> * both MM are defined in EMF.
>>>
>>> The idea:
>>> is to connect my DSL-MM with the uml2-MM. This should be realizable by
>>> creating a profile with sterotypes and enumerations for my DSL and
>>> represent my DSL classes in uml with the appropriate stereotype. I
>>> illustrated this in the 2nd picture "Concrete example" which shows
>>> instances of both MM. So on the right we can see the instance classes of
>>> MyDSL: a container, a class named Ex1 which is an instance of
>>> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
>>> association between Ex1 and Ex2 and a class named Ex3 which is an
>>> instance of DSL-Class#2. Now I want to map them to UML. Following my
>>> example this would result in mapping:
>>> * an instance of container to an uml-package with sterotype
>>> dsl-container
>>> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
>>> sterotype dsl-class#1
>>> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
>>> sterotype dsl-class#1
>>> * an association between Ex1 and Ex2 to an uml association (which may be
>>> stereotyped as "dsl-association if easier)
>>> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
>>> sterotype dsl-class#2
>>>
>>> Other Mapping possibilities (mentioned if my vision doesn't work in
>>> time):
>>> * Model-to-Model transformation is an option. I rather dislike this for
>>> the classic reasons e.g. consistency between the models, overwriting or
>>> synchronization of changes and -for me the most important one- possible
>>> information loss due to the lack of representation in one language. In
>>> my example this means that if a "NotDslClass" exists in the left UML
>>> world for which I have no representation in MyDSL there is no need to
>>> represent it in MyDSL. But I guess I would be forced to handle it
>>> somehow not to loose information in the back-to-uml transformation.
>>> * Customized XML/XMI serialization through extending the XMLHelper also
>>> seems error prone and seems to require a good knowledge of XMI,too.
>>>
>>> Ecore Mapping:
>>> So a better approach would be to simulate the DSL-MM for my GMF-DSL
>>> editor but actually work directly on an UML model. I found the EMF part
>>> of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
>>> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
>>> found the some starting points or ideas how to realize it. My problem is
>>> I can hardly value them nor I know a kind of best practice for this. So
>>> it would be really nice to start a discussion about them or if you say
>>> just read this f****** manual because I'm stuck right now ;(
>>> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff) looks
>>> like an option but my impression is that this is not really what I want.
>>> * Abuse the Model classes (or facades), normally generated by generate
>>> model code as an adapter to eclipse-uml2 facades seems like a lot of
>>> work implying a pretty good understanding of EMF.
>>> * My Favourite: to use the Ecore2Ecore mapper and a customized rescource
>>> handler as mentioned in EMF-EclipseCon p.158ff. My issue here is that
>>> it's just mentioned and not really described, but it seems exactly like
>>> what I want. This feeling is emphazied by features like
>>> OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
>>> resources about that or if there isn't a simple proof-of-concept example
>>> somewhere.
>>>
>>> Thanks for reading already
>>> -stefan
>>>
>>>
>>> ------------------------------------------------------------ ------------
>>>
>>
Re: Connecting DSL-eCore w/ UML2 [message #471232 is a reply to message #471227] Thu, 05 July 2007 17:25 Go to previous message
Stefan Kuhn is currently offline Stefan KuhnFriend
Messages: 355
Registered: July 2009
Senior Member
Honestly I have the feeling that there is no really good solution. I
ended up with the decicion to implement a DSL->UML2 M2M transformation
with xTend (oAW, because GMF already uses xPand and they're similar).
I'm running out of time, so I have no space left for experiments ;(.
Thanks for your reply anyway.


Kenn Hussey schrieb:
> Stefan,
>
> Several of the approaches you describe seem valid. A major difference (an
> perhaps a deciding factor) between them seems (to me) to be whether
> synchronization between the two domains (your DSL and UML, which
> incidentally can also be viewed as a DSL) happens dynamically (at the
> in-memory object representation level) or only when a resource is
> serialized/deserialized.
>
> The Ecore2Ecore model was designed as a mechanism to describe simple
> mappings between two arbitrary EMF (Ecore) models. Ecore2XML was introduced
> to provide an alternative representation of suuch mappings that is tailored
> to (de)serialization in XML/XMI. In practice, Ecore2XML is really only
> useful for mapping between two models that are similar in structure - as
> James has mentioned, it is being used successfully in UML2 to migrate models
> between different versions of UML. Note that complex mappings still need to
> be handled using custom resource handlers and/or post processors (as
> described in the advanced EMF tutorials from EclipseCon 2006 and 2007).
> Beyond the EMF tutorials, perhaps the best source of information is the
> source code. James has already provided you with pointers to the releated
> classes in UML2... has this been of some help?
>
> Kenn
>
> "SKuhn" <kuhn@oio.de> wrote in message
> news:f4jhq2$76t$1@build.eclipse.org...
>> Hi Ed,
>>
>> I expressed my hopes with "So it would be really nice to start a
>> discussion about them or if you say just read this f****** manual because
>> I'm stuck right now ;( " in a way that people can say I did it this way
>> or this way is really awful/awesome or this is the best way to do it.
>>
>> and later on my 'question' in the last point "I'm wondering where I can
>> find good resources about that or if there isn't a simple proof-of-concept
>> example somewhere.".
>>
>> Anyway, the question-representation looks like this:
>> Does anybody know good resources which may help me realizing My Favourite
>> approach(the last) point under EcoreMapping?
>>
>> I can't imagine that this is a new problem/approach, so is there already a
>> proof-of-concept example somewhere?
>>
>>> I does sound like it would be
>>> perhaps a lot simpler to design your own independent model that has no
>>> relation to UML2
>> Of course ;). My problem is that I somehow need this representation in UML
>> (I described this in Use Case).
>>
>> greets
>> stefan
>>
>>
>>
>>
>>
>> Ed Merks schrieb:
>>> Stefan,
>>>
>>> It is indeed a long post and I actually can't find a single "?" in it, so
>>> I'm not really sure what to say. , but I don't think I really understood
>>> well all the issues and concerns...
>>>
>>>
>>> SKuhn wrote:
>>>> hi folks,
>>>>
>>>> the following text is quite long, so if you're in a rush just read
>>>> abstract, look at the picture, read constraints, the idea and the last
>>>> point of ecore-mapping.
>>>>
>>>> Abstract:
>>>> basically I want to be able to read & write proper UML2 models with my
>>>> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
>>>> going to outline it in detail because I didn't find a good way to start
>>>> / solve it.
>>>>
>>>> Use Case:
>>>> We're working with MDSD and already have a cardridge for a domain. Right
>>>> now, the generator gets the model from an uml2 tool. The graphical
>>>> editor I have to make (using GMF) for this domain should be able to read
>>>> and write uml2 models because of reasons like flexibility (wheather or
>>>> not to use my editor) or extended control of an uml tool (e.g to model
>>>> the DTOs in the same file). Both, UML2 Tools and the generator accept
>>>> uml2 models from ecore.
>>>>
>>>> DSL:
>>>> There various reasons why a tend to create my own domain specific
>>>> language (DSL) for my graphical editor (GE) in contrast to use
>>>> uml2.ecore:
>>>> * a DSL which uses around 10 classes seems to be overburdened if it's
>>>> based on the uml2.ecore with several hundred classes.
>>>> * not that error prone because less confusion for the GMF framework and
>>>> even more important for me.
>>>> * some constraints are already implicit from my DSL Metamodel (MM) and
>>>> the others should be easier to write on a simple MM.
>>>> * It seems unhandy to create the uml2.ecore model code (after 5 hours I
>>>> stopped the generation).
>>>> * there must be a reason why GMF enforces the creation of DSLs rather
>>>> than building a customized UML2 editor.
>>>>
>>>> The two worlds:
>>>> This results in two worlds for my "MetaModel" sketch (see attached
>>>> picture). In the left corner, we see famous UML with his well known
>>>> metaclasses and packages. On the right corner we can see the young DSL
>>>> also with metaclasses described in ecore. Now my experiments showed that
>>>> the heavyweigth extensions in which I extended classes from the
>>>> uml2.ecore are uml2-xmi compliant. So the only way to customize uml and
>>>> still be able to use standard uml tools is the lightweight approach. I
>>>> sketched this with the outer circle around uml.
>>>>
>>>> Contraints:
>>>> * I assume that I'm not restricting UML and
>>>> * that every DSL Class has a pendant in uml with a lack of semantics
>>>> expressable by stereotypes.
>>>> * both MM are defined in EMF.
>>>>
>>>> The idea:
>>>> is to connect my DSL-MM with the uml2-MM. This should be realizable by
>>>> creating a profile with sterotypes and enumerations for my DSL and
>>>> represent my DSL classes in uml with the appropriate stereotype. I
>>>> illustrated this in the 2nd picture "Concrete example" which shows
>>>> instances of both MM. So on the right we can see the instance classes of
>>>> MyDSL: a container, a class named Ex1 which is an instance of
>>>> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
>>>> association between Ex1 and Ex2 and a class named Ex3 which is an
>>>> instance of DSL-Class#2. Now I want to map them to UML. Following my
>>>> example this would result in mapping:
>>>> * an instance of container to an uml-package with sterotype
>>>> dsl-container
>>>> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
>>>> sterotype dsl-class#1
>>>> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
>>>> sterotype dsl-class#1
>>>> * an association between Ex1 and Ex2 to an uml association (which may be
>>>> stereotyped as "dsl-association if easier)
>>>> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
>>>> sterotype dsl-class#2
>>>>
>>>> Other Mapping possibilities (mentioned if my vision doesn't work in
>>>> time):
>>>> * Model-to-Model transformation is an option. I rather dislike this for
>>>> the classic reasons e.g. consistency between the models, overwriting or
>>>> synchronization of changes and -for me the most important one- possible
>>>> information loss due to the lack of representation in one language. In
>>>> my example this means that if a "NotDslClass" exists in the left UML
>>>> world for which I have no representation in MyDSL there is no need to
>>>> represent it in MyDSL. But I guess I would be forced to handle it
>>>> somehow not to loose information in the back-to-uml transformation.
>>>> * Customized XML/XMI serialization through extending the XMLHelper also
>>>> seems error prone and seems to require a good knowledge of XMI,too.
>>>>
>>>> Ecore Mapping:
>>>> So a better approach would be to simulate the DSL-MM for my GMF-DSL
>>>> editor but actually work directly on an UML model. I found the EMF part
>>>> of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
>>>> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
>>>> found the some starting points or ideas how to realize it. My problem is
>>>> I can hardly value them nor I know a kind of best practice for this. So
>>>> it would be really nice to start a discussion about them or if you say
>>>> just read this f****** manual because I'm stuck right now ;(
>>>> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff) looks
>>>> like an option but my impression is that this is not really what I want.
>>>> * Abuse the Model classes (or facades), normally generated by generate
>>>> model code as an adapter to eclipse-uml2 facades seems like a lot of
>>>> work implying a pretty good understanding of EMF.
>>>> * My Favourite: to use the Ecore2Ecore mapper and a customized rescource
>>>> handler as mentioned in EMF-EclipseCon p.158ff. My issue here is that
>>>> it's just mentioned and not really described, but it seems exactly like
>>>> what I want. This feeling is emphazied by features like
>>>> OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
>>>> resources about that or if there isn't a simple proof-of-concept example
>>>> somewhere.
>>>>
>>>> Thanks for reading already
>>>> -stefan
>>>>
>>>>
>>>> ------------------------------------------------------------ ------------
>>>>
>
>
Re: Connecting DSL-eCore w/ UML2 [message #597635 is a reply to message #471129] Mon, 11 June 2007 12:47 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33108
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------070307040505060403060902
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Stefan,

It is indeed a long post and I actually can't find a single "?" in it,
so I'm not really sure what to say. I does sound like it would be
perhaps a lot simpler to design your own independent model that has no
relation to UML2, but I don't think I really understood well all the
issues and concerns...


SKuhn wrote:
> hi folks,
>
> the following text is quite long, so if you're in a rush just read
> abstract, look at the picture, read constraints, the idea and the last
> point of ecore-mapping.
>
> Abstract:
> basically I want to be able to read & write proper UML2 models with my
> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
> going to outline it in detail because I didn't find a good way to
> start / solve it.
>
> Use Case:
> We're working with MDSD and already have a cardridge for a domain.
> Right now, the generator gets the model from an uml2 tool. The
> graphical editor I have to make (using GMF) for this domain should be
> able to read and write uml2 models because of reasons like flexibility
> (wheather or not to use my editor) or extended control of an uml tool
> (e.g to model the DTOs in the same file). Both, UML2 Tools and the
> generator accept uml2 models from ecore.
>
> DSL:
> There various reasons why a tend to create my own domain specific
> language (DSL) for my graphical editor (GE) in contrast to use
> uml2.ecore:
> * a DSL which uses around 10 classes seems to be overburdened if it's
> based on the uml2.ecore with several hundred classes.
> * not that error prone because less confusion for the GMF framework
> and even more important for me.
> * some constraints are already implicit from my DSL Metamodel (MM) and
> the others should be easier to write on a simple MM.
> * It seems unhandy to create the uml2.ecore model code (after 5 hours
> I stopped the generation).
> * there must be a reason why GMF enforces the creation of DSLs rather
> than building a customized UML2 editor.
>
> The two worlds:
> This results in two worlds for my "MetaModel" sketch (see attached
> picture). In the left corner, we see famous UML with his well known
> metaclasses and packages. On the right corner we can see the young DSL
> also with metaclasses described in ecore. Now my experiments showed
> that the heavyweigth extensions in which I extended classes from the
> uml2.ecore are uml2-xmi compliant. So the only way to customize uml
> and still be able to use standard uml tools is the lightweight
> approach. I sketched this with the outer circle around uml.
>
> Contraints:
> * I assume that I'm not restricting UML and
> * that every DSL Class has a pendant in uml with a lack of semantics
> expressable by stereotypes.
> * both MM are defined in EMF.
>
> The idea:
> is to connect my DSL-MM with the uml2-MM. This should be realizable by
> creating a profile with sterotypes and enumerations for my DSL and
> represent my DSL classes in uml with the appropriate stereotype. I
> illustrated this in the 2nd picture "Concrete example" which shows
> instances of both MM. So on the right we can see the instance classes
> of MyDSL: a container, a class named Ex1 which is an instance of
> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
> association between Ex1 and Ex2 and a class named Ex3 which is an
> instance of DSL-Class#2. Now I want to map them to UML. Following my
> example this would result in mapping:
> * an instance of container to an uml-package with sterotype dsl-container
> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
> sterotype dsl-class#1
> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
> sterotype dsl-class#1
> * an association between Ex1 and Ex2 to an uml association (which may
> be stereotyped as "dsl-association if easier)
> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
> sterotype dsl-class#2
>
> Other Mapping possibilities (mentioned if my vision doesn't work in
> time):
> * Model-to-Model transformation is an option. I rather dislike this
> for the classic reasons e.g. consistency between the models,
> overwriting or synchronization of changes and -for me the most
> important one- possible information loss due to the lack of
> representation in one language. In my example this means that if a
> "NotDslClass" exists in the left UML world for which I have no
> representation in MyDSL there is no need to represent it in MyDSL. But
> I guess I would be forced to handle it somehow not to loose
> information in the back-to-uml transformation.
> * Customized XML/XMI serialization through extending the XMLHelper
> also seems error prone and seems to require a good knowledge of XMI,too.
>
> Ecore Mapping:
> So a better approach would be to simulate the DSL-MM for my GMF-DSL
> editor but actually work directly on an UML model. I found the EMF
> part of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
> found the some starting points or ideas how to realize it. My problem
> is I can hardly value them nor I know a kind of best practice for
> this. So it would be really nice to start a discussion about them or
> if you say just read this f****** manual because I'm stuck right now ;(
> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff)
> looks like an option but my impression is that this is not really what
> I want.
> * Abuse the Model classes (or facades), normally generated by generate
> model code as an adapter to eclipse-uml2 facades seems like a lot of
> work implying a pretty good understanding of EMF.
> * My Favourite: to use the Ecore2Ecore mapper and a customized
> rescource handler as mentioned in EMF-EclipseCon p.158ff. My issue
> here is that it's just mentioned and not really described, but it
> seems exactly like what I want. This feeling is emphazied by features
> like OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
> resources about that or if there isn't a simple proof-of-concept
> example somewhere.
>
> Thanks for reading already
> -stefan
>
>
> ------------------------------------------------------------ ------------
>


--------------070307040505060403060902
Content-Type: multipart/related;
boundary="------------080608070903060108060300"


--------------080608070903060108060300
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Stefan,<br>
<br>
It is indeed a long post and I actually can't find a single "?" in it,
so I'm not really sure what to say.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Connecting DSL-eCore w/ UML2 [message #597651 is a reply to message #471135] Mon, 11 June 2007 13:13 Go to previous message
Stefan Kuhn is currently offline Stefan KuhnFriend
Messages: 355
Registered: July 2009
Senior Member
Hi Ed,

I expressed my hopes with "So it would be really nice to start a
discussion about them or if you say just read this f****** manual
because I'm stuck right now ;( " in a way that people can say I did it
this way or this way is really awful/awesome or this is the best way to
do it.

and later on my 'question' in the last point "I'm wondering where I can
find good resources about that or if there isn't a simple
proof-of-concept example somewhere.".

Anyway, the question-representation looks like this:
Does anybody know good resources which may help me realizing My
Favourite approach(the last) point under EcoreMapping?

I can't imagine that this is a new problem/approach, so is there already
a proof-of-concept example somewhere?

> I does sound like it would be
> perhaps a lot simpler to design your own independent model that has no
> relation to UML2
Of course ;). My problem is that I somehow need this representation in
UML (I described this in Use Case).

greets
stefan





Ed Merks schrieb:
> Stefan,
>
> It is indeed a long post and I actually can't find a single "?" in it,
> so I'm not really sure what to say. , but I don't think I really understood well all the
> issues and concerns...
>
>
> SKuhn wrote:
>> hi folks,
>>
>> the following text is quite long, so if you're in a rush just read
>> abstract, look at the picture, read constraints, the idea and the last
>> point of ecore-mapping.
>>
>> Abstract:
>> basically I want to be able to read & write proper UML2 models with my
>> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
>> going to outline it in detail because I didn't find a good way to
>> start / solve it.
>>
>> Use Case:
>> We're working with MDSD and already have a cardridge for a domain.
>> Right now, the generator gets the model from an uml2 tool. The
>> graphical editor I have to make (using GMF) for this domain should be
>> able to read and write uml2 models because of reasons like flexibility
>> (wheather or not to use my editor) or extended control of an uml tool
>> (e.g to model the DTOs in the same file). Both, UML2 Tools and the
>> generator accept uml2 models from ecore.
>>
>> DSL:
>> There various reasons why a tend to create my own domain specific
>> language (DSL) for my graphical editor (GE) in contrast to use
>> uml2.ecore:
>> * a DSL which uses around 10 classes seems to be overburdened if it's
>> based on the uml2.ecore with several hundred classes.
>> * not that error prone because less confusion for the GMF framework
>> and even more important for me.
>> * some constraints are already implicit from my DSL Metamodel (MM) and
>> the others should be easier to write on a simple MM.
>> * It seems unhandy to create the uml2.ecore model code (after 5 hours
>> I stopped the generation).
>> * there must be a reason why GMF enforces the creation of DSLs rather
>> than building a customized UML2 editor.
>>
>> The two worlds:
>> This results in two worlds for my "MetaModel" sketch (see attached
>> picture). In the left corner, we see famous UML with his well known
>> metaclasses and packages. On the right corner we can see the young DSL
>> also with metaclasses described in ecore. Now my experiments showed
>> that the heavyweigth extensions in which I extended classes from the
>> uml2.ecore are uml2-xmi compliant. So the only way to customize uml
>> and still be able to use standard uml tools is the lightweight
>> approach. I sketched this with the outer circle around uml.
>>
>> Contraints:
>> * I assume that I'm not restricting UML and
>> * that every DSL Class has a pendant in uml with a lack of semantics
>> expressable by stereotypes.
>> * both MM are defined in EMF.
>>
>> The idea:
>> is to connect my DSL-MM with the uml2-MM. This should be realizable by
>> creating a profile with sterotypes and enumerations for my DSL and
>> represent my DSL classes in uml with the appropriate stereotype. I
>> illustrated this in the 2nd picture "Concrete example" which shows
>> instances of both MM. So on the right we can see the instance classes
>> of MyDSL: a container, a class named Ex1 which is an instance of
>> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
>> association between Ex1 and Ex2 and a class named Ex3 which is an
>> instance of DSL-Class#2. Now I want to map them to UML. Following my
>> example this would result in mapping:
>> * an instance of container to an uml-package with sterotype dsl-container
>> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
>> sterotype dsl-class#1
>> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
>> sterotype dsl-class#1
>> * an association between Ex1 and Ex2 to an uml association (which may
>> be stereotyped as "dsl-association if easier)
>> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
>> sterotype dsl-class#2
>>
>> Other Mapping possibilities (mentioned if my vision doesn't work in
>> time):
>> * Model-to-Model transformation is an option. I rather dislike this
>> for the classic reasons e.g. consistency between the models,
>> overwriting or synchronization of changes and -for me the most
>> important one- possible information loss due to the lack of
>> representation in one language. In my example this means that if a
>> "NotDslClass" exists in the left UML world for which I have no
>> representation in MyDSL there is no need to represent it in MyDSL. But
>> I guess I would be forced to handle it somehow not to loose
>> information in the back-to-uml transformation.
>> * Customized XML/XMI serialization through extending the XMLHelper
>> also seems error prone and seems to require a good knowledge of XMI,too.
>>
>> Ecore Mapping:
>> So a better approach would be to simulate the DSL-MM for my GMF-DSL
>> editor but actually work directly on an UML model. I found the EMF
>> part of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
>> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
>> found the some starting points or ideas how to realize it. My problem
>> is I can hardly value them nor I know a kind of best practice for
>> this. So it would be really nice to start a discussion about them or
>> if you say just read this f****** manual because I'm stuck right now ;(
>> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff)
>> looks like an option but my impression is that this is not really what
>> I want.
>> * Abuse the Model classes (or facades), normally generated by generate
>> model code as an adapter to eclipse-uml2 facades seems like a lot of
>> work implying a pretty good understanding of EMF.
>> * My Favourite: to use the Ecore2Ecore mapper and a customized
>> rescource handler as mentioned in EMF-EclipseCon p.158ff. My issue
>> here is that it's just mentioned and not really described, but it
>> seems exactly like what I want. This feeling is emphazied by features
>> like OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
>> resources about that or if there isn't a simple proof-of-concept
>> example somewhere.
>>
>> Thanks for reading already
>> -stefan
>>
>>
>> ------------------------------------------------------------ ------------
>>
>
Re: Connecting DSL-eCore w/ UML2 [message #597658 is a reply to message #471138] Mon, 11 June 2007 15:26 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi SKuhn,

For an example of the ecore2ecore mapping have a look at
org.eclipse.uml2.uml \model at UML2_2_UML.ecore2ecore and .ecore2xml. This
is a mapping between older and newer verion of UML and is used for forward
migration. The org.eclipse.uml2.uml.resource contains code behind the
migration. ( you might want to have a look at the migration guide from the
UML wiki .. it explains the mapping in a human readable format ).

There are draft articles for creating DSL in bugzilla [77413], and links
from the UML wiki.

You might also want to have a look at the UMLTools project for creating
editors for your own metamodel.

Hope that helps,

- James.


"SKuhn" <kuhn@oio.de> wrote in message
news:f4jhq2$76t$1@build.eclipse.org...
> Hi Ed,
>
> I expressed my hopes with "So it would be really nice to start a
> discussion about them or if you say just read this f****** manual
> because I'm stuck right now ;( " in a way that people can say I did it
> this way or this way is really awful/awesome or this is the best way to
> do it.
>
> and later on my 'question' in the last point "I'm wondering where I can
> find good resources about that or if there isn't a simple
> proof-of-concept example somewhere.".
>
> Anyway, the question-representation looks like this:
> Does anybody know good resources which may help me realizing My
> Favourite approach(the last) point under EcoreMapping?
>
> I can't imagine that this is a new problem/approach, so is there already
> a proof-of-concept example somewhere?
>
> > I does sound like it would be
> > perhaps a lot simpler to design your own independent model that has no
> > relation to UML2
> Of course ;). My problem is that I somehow need this representation in
> UML (I described this in Use Case).
>
> greets
> stefan
>
>
>
>
>
> Ed Merks schrieb:
> > Stefan,
> >
> > It is indeed a long post and I actually can't find a single "?" in it,
> > so I'm not really sure what to say. , but I don't think I really
understood well all the
> > issues and concerns...
> >
> >
> > SKuhn wrote:
> >> hi folks,
> >>
> >> the following text is quite long, so if you're in a rush just read
> >> abstract, look at the picture, read constraints, the idea and the last
> >> point of ecore-mapping.
> >>
> >> Abstract:
> >> basically I want to be able to read & write proper UML2 models with my
> >> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
> >> going to outline it in detail because I didn't find a good way to
> >> start / solve it.
> >>
> >> Use Case:
> >> We're working with MDSD and already have a cardridge for a domain.
> >> Right now, the generator gets the model from an uml2 tool. The
> >> graphical editor I have to make (using GMF) for this domain should be
> >> able to read and write uml2 models because of reasons like flexibility
> >> (wheather or not to use my editor) or extended control of an uml tool
> >> (e.g to model the DTOs in the same file). Both, UML2 Tools and the
> >> generator accept uml2 models from ecore.
> >>
> >> DSL:
> >> There various reasons why a tend to create my own domain specific
> >> language (DSL) for my graphical editor (GE) in contrast to use
> >> uml2.ecore:
> >> * a DSL which uses around 10 classes seems to be overburdened if it's
> >> based on the uml2.ecore with several hundred classes.
> >> * not that error prone because less confusion for the GMF framework
> >> and even more important for me.
> >> * some constraints are already implicit from my DSL Metamodel (MM) and
> >> the others should be easier to write on a simple MM.
> >> * It seems unhandy to create the uml2.ecore model code (after 5 hours
> >> I stopped the generation).
> >> * there must be a reason why GMF enforces the creation of DSLs rather
> >> than building a customized UML2 editor.
> >>
> >> The two worlds:
> >> This results in two worlds for my "MetaModel" sketch (see attached
> >> picture). In the left corner, we see famous UML with his well known
> >> metaclasses and packages. On the right corner we can see the young DSL
> >> also with metaclasses described in ecore. Now my experiments showed
> >> that the heavyweigth extensions in which I extended classes from the
> >> uml2.ecore are uml2-xmi compliant. So the only way to customize uml
> >> and still be able to use standard uml tools is the lightweight
> >> approach. I sketched this with the outer circle around uml.
> >>
> >> Contraints:
> >> * I assume that I'm not restricting UML and
> >> * that every DSL Class has a pendant in uml with a lack of semantics
> >> expressable by stereotypes.
> >> * both MM are defined in EMF.
> >>
> >> The idea:
> >> is to connect my DSL-MM with the uml2-MM. This should be realizable by
> >> creating a profile with sterotypes and enumerations for my DSL and
> >> represent my DSL classes in uml with the appropriate stereotype. I
> >> illustrated this in the 2nd picture "Concrete example" which shows
> >> instances of both MM. So on the right we can see the instance classes
> >> of MyDSL: a container, a class named Ex1 which is an instance of
> >> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
> >> association between Ex1 and Ex2 and a class named Ex3 which is an
> >> instance of DSL-Class#2. Now I want to map them to UML. Following my
> >> example this would result in mapping:
> >> * an instance of container to an uml-package with sterotype
dsl-container
> >> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
> >> sterotype dsl-class#1
> >> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
> >> sterotype dsl-class#1
> >> * an association between Ex1 and Ex2 to an uml association (which may
> >> be stereotyped as "dsl-association if easier)
> >> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
> >> sterotype dsl-class#2
> >>
> >> Other Mapping possibilities (mentioned if my vision doesn't work in
> >> time):
> >> * Model-to-Model transformation is an option. I rather dislike this
> >> for the classic reasons e.g. consistency between the models,
> >> overwriting or synchronization of changes and -for me the most
> >> important one- possible information loss due to the lack of
> >> representation in one language. In my example this means that if a
> >> "NotDslClass" exists in the left UML world for which I have no
> >> representation in MyDSL there is no need to represent it in MyDSL. But
> >> I guess I would be forced to handle it somehow not to loose
> >> information in the back-to-uml transformation.
> >> * Customized XML/XMI serialization through extending the XMLHelper
> >> also seems error prone and seems to require a good knowledge of
XMI,too.
> >>
> >> Ecore Mapping:
> >> So a better approach would be to simulate the DSL-MM for my GMF-DSL
> >> editor but actually work directly on an UML model. I found the EMF
> >> part of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
> >> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
> >> found the some starting points or ideas how to realize it. My problem
> >> is I can hardly value them nor I know a kind of best practice for
> >> this. So it would be really nice to start a discussion about them or
> >> if you say just read this f****** manual because I'm stuck right now ;(
> >> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff)
> >> looks like an option but my impression is that this is not really what
> >> I want.
> >> * Abuse the Model classes (or facades), normally generated by generate
> >> model code as an adapter to eclipse-uml2 facades seems like a lot of
> >> work implying a pretty good understanding of EMF.
> >> * My Favourite: to use the Ecore2Ecore mapper and a customized
> >> rescource handler as mentioned in EMF-EclipseCon p.158ff. My issue
> >> here is that it's just mentioned and not really described, but it
> >> seems exactly like what I want. This feeling is emphazied by features
> >> like OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
> >> resources about that or if there isn't a simple proof-of-concept
> >> example somewhere.
> >>
> >> Thanks for reading already
> >> -stefan
> >>
> >>
>
>> ------------------------------------------------------------ ------------
> >>
> >
Re: Connecting DSL-eCore w/ UML2 [message #597666 is a reply to message #471139] Mon, 11 June 2007 16:37 Go to previous message
Stefan Kuhn is currently offline Stefan KuhnFriend
Messages: 355
Registered: July 2009
Senior Member
hi james,

> For an example of the ecore2ecore mapping have a look at
> org.eclipse.uml2.uml \model at UML2_2_UML.ecore2ecore and .ecore2xml.
This
> is a mapping between older and newer verion of UML and is used for
forward
> migration. The org.eclipse.uml2.uml.resource contains code behind the
> migration. ( you might want to have a look at the migration guide
from the
> UML wiki .. it explains the mapping in a human readable format ).
I stumbled over it some weeks ago but skipped it because I thought it
has nothing to do with my problem. So I'm definitly going to take a look
on it soon. Thanks for the hint.

> There are draft articles for creating DSL in bugzilla [77413], and links
> from the UML wiki.
> You might also want to have a look at the UMLTools project for creating
> editors for your own metamodel.
I already looked at both. I played around with Heavyweight-Extensions
but it seemed preety much that other UML Tools e.g. MagicDraw won't
handle heavyweight extensions at all. So customizing the UML editor of
UMLTools is not an option neither.

I found an error in my first post:
"Now my experiments showed that the heavyweigth extensions in which I
extended classes from the uml2.ecore are !!!NOT!!! uml2-xmi compliant.
So the only way to customize uml and still be able to use standard uml
tools is the lightweight approach."

thanks so far
-stefan



>
> Hope that helps,
>
> - James.
>
>
> "SKuhn" <kuhn@oio.de> wrote in message
> news:f4jhq2$76t$1@build.eclipse.org...
>> Hi Ed,
>>
>> I expressed my hopes with "So it would be really nice to start a
>> discussion about them or if you say just read this f****** manual
>> because I'm stuck right now ;( " in a way that people can say I did it
>> this way or this way is really awful/awesome or this is the best way to
>> do it.
>>
>> and later on my 'question' in the last point "I'm wondering where I can
>> find good resources about that or if there isn't a simple
>> proof-of-concept example somewhere.".
>>
>> Anyway, the question-representation looks like this:
>> Does anybody know good resources which may help me realizing My
>> Favourite approach(the last) point under EcoreMapping?
>>
>> I can't imagine that this is a new problem/approach, so is there already
>> a proof-of-concept example somewhere?
>>
>> > I does sound like it would be
>> > perhaps a lot simpler to design your own independent model that has no
>> > relation to UML2
>> Of course ;). My problem is that I somehow need this representation in
>> UML (I described this in Use Case).
>>
>> greets
>> stefan
>>
>>
>>
>>
>>
>> Ed Merks schrieb:
>>> Stefan,
>>>
>>> It is indeed a long post and I actually can't find a single "?" in it,
>>> so I'm not really sure what to say. , but I don't think I really
> understood well all the
>>> issues and concerns...
>>>
>>>
>>> SKuhn wrote:
>>>> hi folks,
>>>>
>>>> the following text is quite long, so if you're in a rush just read
>>>> abstract, look at the picture, read constraints, the idea and the last
>>>> point of ecore-mapping.
>>>>
>>>> Abstract:
>>>> basically I want to be able to read & write proper UML2 models with my
>>>> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
>>>> going to outline it in detail because I didn't find a good way to
>>>> start / solve it.
>>>>
>>>> Use Case:
>>>> We're working with MDSD and already have a cardridge for a domain.
>>>> Right now, the generator gets the model from an uml2 tool. The
>>>> graphical editor I have to make (using GMF) for this domain should be
>>>> able to read and write uml2 models because of reasons like flexibility
>>>> (wheather or not to use my editor) or extended control of an uml tool
>>>> (e.g to model the DTOs in the same file). Both, UML2 Tools and the
>>>> generator accept uml2 models from ecore.
>>>>
>>>> DSL:
>>>> There various reasons why a tend to create my own domain specific
>>>> language (DSL) for my graphical editor (GE) in contrast to use
>>>> uml2.ecore:
>>>> * a DSL which uses around 10 classes seems to be overburdened if it's
>>>> based on the uml2.ecore with several hundred classes.
>>>> * not that error prone because less confusion for the GMF framework
>>>> and even more important for me.
>>>> * some constraints are already implicit from my DSL Metamodel (MM) and
>>>> the others should be easier to write on a simple MM.
>>>> * It seems unhandy to create the uml2.ecore model code (after 5 hours
>>>> I stopped the generation).
>>>> * there must be a reason why GMF enforces the creation of DSLs rather
>>>> than building a customized UML2 editor.
>>>>
>>>> The two worlds:
>>>> This results in two worlds for my "MetaModel" sketch (see attached
>>>> picture). In the left corner, we see famous UML with his well known
>>>> metaclasses and packages. On the right corner we can see the young DSL
>>>> also with metaclasses described in ecore. Now my experiments showed
>>>> that the heavyweigth extensions in which I extended classes from the
>>>> uml2.ecore are uml2-xmi compliant. So the only way to customize uml
>>>> and still be able to use standard uml tools is the lightweight
>>>> approach. I sketched this with the outer circle around uml.
>>>>
>>>> Contraints:
>>>> * I assume that I'm not restricting UML and
>>>> * that every DSL Class has a pendant in uml with a lack of semantics
>>>> expressable by stereotypes.
>>>> * both MM are defined in EMF.
>>>>
>>>> The idea:
>>>> is to connect my DSL-MM with the uml2-MM. This should be realizable by
>>>> creating a profile with sterotypes and enumerations for my DSL and
>>>> represent my DSL classes in uml with the appropriate stereotype. I
>>>> illustrated this in the 2nd picture "Concrete example" which shows
>>>> instances of both MM. So on the right we can see the instance classes
>>>> of MyDSL: a container, a class named Ex1 which is an instance of
>>>> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
>>>> association between Ex1 and Ex2 and a class named Ex3 which is an
>>>> instance of DSL-Class#2. Now I want to map them to UML. Following my
>>>> example this would result in mapping:
>>>> * an instance of container to an uml-package with sterotype
> dsl-container
>>>> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
>>>> sterotype dsl-class#1
>>>> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
>>>> sterotype dsl-class#1
>>>> * an association between Ex1 and Ex2 to an uml association (which may
>>>> be stereotyped as "dsl-association if easier)
>>>> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
>>>> sterotype dsl-class#2
>>>>
>>>> Other Mapping possibilities (mentioned if my vision doesn't work in
>>>> time):
>>>> * Model-to-Model transformation is an option. I rather dislike this
>>>> for the classic reasons e.g. consistency between the models,
>>>> overwriting or synchronization of changes and -for me the most
>>>> important one- possible information loss due to the lack of
>>>> representation in one language. In my example this means that if a
>>>> "NotDslClass" exists in the left UML world for which I have no
>>>> representation in MyDSL there is no need to represent it in MyDSL. But
>>>> I guess I would be forced to handle it somehow not to loose
>>>> information in the back-to-uml transformation.
>>>> * Customized XML/XMI serialization through extending the XMLHelper
>>>> also seems error prone and seems to require a good knowledge of
> XMI,too.
>>>> Ecore Mapping:
>>>> So a better approach would be to simulate the DSL-MM for my GMF-DSL
>>>> editor but actually work directly on an UML model. I found the EMF
>>>> part of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
>>>> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
>>>> found the some starting points or ideas how to realize it. My problem
>>>> is I can hardly value them nor I know a kind of best practice for
>>>> this. So it would be really nice to start a discussion about them or
>>>> if you say just read this f****** manual because I'm stuck right now ;(
>>>> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff)
>>>> looks like an option but my impression is that this is not really what
>>>> I want.
>>>> * Abuse the Model classes (or facades), normally generated by generate
>>>> model code as an adapter to eclipse-uml2 facades seems like a lot of
>>>> work implying a pretty good understanding of EMF.
>>>> * My Favourite: to use the Ecore2Ecore mapper and a customized
>>>> rescource handler as mentioned in EMF-EclipseCon p.158ff. My issue
>>>> here is that it's just mentioned and not really described, but it
>>>> seems exactly like what I want. This feeling is emphazied by features
>>>> like OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
>>>> resources about that or if there isn't a simple proof-of-concept
>>>> example somewhere.
>>>>
>>>> Thanks for reading already
>>>> -stefan
>>>>
>>>>
>>> ------------------------------------------------------------ ------------
>
>
Re: Connecting DSL-eCore w/ UML2 [message #597686 is a reply to message #471140] Mon, 11 June 2007 22:36 Go to previous message
Eclipse UserFriend
Originally posted by: carrasco.ModelDrivenDevelopment.co.uk

My 2 cents:

Two forces:
You must facilitate modeling of instances of your DSL in your Tool.
You must interoperate with UML tools.

Deal with them separately:

Do your custom DSL editor, i.e. with GMF
Convert to/from Eclipse UML2.1 with Model2Model transformations,
Save UML2 interoperable .xmi files from Eclipse UML2.1
(some tools will not interoperate with the default .xmi from Eclipse)
Keep asking, to figure out how to interoperate with Diagrams
from other tools.

Cheers,
Antonio








"SKuhn" <kuhn@oio.de> wrote in message
news:f4jtnn$d33$1@build.eclipse.org...
> hi james,
>
> > For an example of the ecore2ecore mapping have a look at
> > org.eclipse.uml2.uml \model at UML2_2_UML.ecore2ecore and .ecore2xml.
> This
> > is a mapping between older and newer verion of UML and is used for
> forward
> > migration. The org.eclipse.uml2.uml.resource contains code behind the
> > migration. ( you might want to have a look at the migration guide
> from the
> > UML wiki .. it explains the mapping in a human readable format ).
> I stumbled over it some weeks ago but skipped it because I thought it has
> nothing to do with my problem. So I'm definitly going to take a look on it
> soon. Thanks for the hint.
>
> > There are draft articles for creating DSL in bugzilla [77413], and links
> > from the UML wiki.
> > You might also want to have a look at the UMLTools project for creating
> > editors for your own metamodel.
> I already looked at both. I played around with Heavyweight-Extensions but
> it seemed preety much that other UML Tools e.g. MagicDraw won't handle
> heavyweight extensions at all. So customizing the UML editor of UMLTools
> is not an option neither.
>
> I found an error in my first post:
> "Now my experiments showed that the heavyweigth extensions in which I
> extended classes from the uml2.ecore are !!!NOT!!! uml2-xmi compliant. So
> the only way to customize uml and still be able to use standard uml tools
> is the lightweight approach."
>
> thanks so far
> -stefan
>
>
>
>>
>> Hope that helps,
>>
>> - James.
>>
>>
>> "SKuhn" <kuhn@oio.de> wrote in message
>> news:f4jhq2$76t$1@build.eclipse.org...
>>> Hi Ed,
>>>
>>> I expressed my hopes with "So it would be really nice to start a
>>> discussion about them or if you say just read this f****** manual
>>> because I'm stuck right now ;( " in a way that people can say I did it
>>> this way or this way is really awful/awesome or this is the best way to
>>> do it.
>>>
>>> and later on my 'question' in the last point "I'm wondering where I can
>>> find good resources about that or if there isn't a simple
>>> proof-of-concept example somewhere.".
>>>
>>> Anyway, the question-representation looks like this:
>>> Does anybody know good resources which may help me realizing My
>>> Favourite approach(the last) point under EcoreMapping?
>>>
>>> I can't imagine that this is a new problem/approach, so is there already
>>> a proof-of-concept example somewhere?
>>>
>>> > I does sound like it would be
>>> > perhaps a lot simpler to design your own independent model that has
>>> no
>>> > relation to UML2
>>> Of course ;). My problem is that I somehow need this representation in
>>> UML (I described this in Use Case).
>>>
>>> greets
>>> stefan
>>>
>>>
>>>
>>>
>>>
>>> Ed Merks schrieb:
>>>> Stefan,
>>>>
>>>> It is indeed a long post and I actually can't find a single "?" in it,
>>>> so I'm not really sure what to say. , but I don't think I really
>> understood well all the
>>>> issues and concerns...
>>>>
>>>>
>>>> SKuhn wrote:
>>>>> hi folks,
>>>>>
>>>>> the following text is quite long, so if you're in a rush just read
>>>>> abstract, look at the picture, read constraints, the idea and the last
>>>>> point of ecore-mapping.
>>>>>
>>>>> Abstract:
>>>>> basically I want to be able to read & write proper UML2 models with my
>>>>> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
>>>>> going to outline it in detail because I didn't find a good way to
>>>>> start / solve it.
>>>>>
>>>>> Use Case:
>>>>> We're working with MDSD and already have a cardridge for a domain.
>>>>> Right now, the generator gets the model from an uml2 tool. The
>>>>> graphical editor I have to make (using GMF) for this domain should be
>>>>> able to read and write uml2 models because of reasons like flexibility
>>>>> (wheather or not to use my editor) or extended control of an uml tool
>>>>> (e.g to model the DTOs in the same file). Both, UML2 Tools and the
>>>>> generator accept uml2 models from ecore.
>>>>>
>>>>> DSL:
>>>>> There various reasons why a tend to create my own domain specific
>>>>> language (DSL) for my graphical editor (GE) in contrast to use
>>>>> uml2.ecore:
>>>>> * a DSL which uses around 10 classes seems to be overburdened if it's
>>>>> based on the uml2.ecore with several hundred classes.
>>>>> * not that error prone because less confusion for the GMF framework
>>>>> and even more important for me.
>>>>> * some constraints are already implicit from my DSL Metamodel (MM) and
>>>>> the others should be easier to write on a simple MM.
>>>>> * It seems unhandy to create the uml2.ecore model code (after 5 hours
>>>>> I stopped the generation).
>>>>> * there must be a reason why GMF enforces the creation of DSLs rather
>>>>> than building a customized UML2 editor.
>>>>>
>>>>> The two worlds:
>>>>> This results in two worlds for my "MetaModel" sketch (see attached
>>>>> picture). In the left corner, we see famous UML with his well known
>>>>> metaclasses and packages. On the right corner we can see the young DSL
>>>>> also with metaclasses described in ecore. Now my experiments showed
>>>>> that the heavyweigth extensions in which I extended classes from the
>>>>> uml2.ecore are uml2-xmi compliant. So the only way to customize uml
>>>>> and still be able to use standard uml tools is the lightweight
>>>>> approach. I sketched this with the outer circle around uml.
>>>>>
>>>>> Contraints:
>>>>> * I assume that I'm not restricting UML and
>>>>> * that every DSL Class has a pendant in uml with a lack of semantics
>>>>> expressable by stereotypes.
>>>>> * both MM are defined in EMF.
>>>>>
>>>>> The idea:
>>>>> is to connect my DSL-MM with the uml2-MM. This should be realizable by
>>>>> creating a profile with sterotypes and enumerations for my DSL and
>>>>> represent my DSL classes in uml with the appropriate stereotype. I
>>>>> illustrated this in the 2nd picture "Concrete example" which shows
>>>>> instances of both MM. So on the right we can see the instance classes
>>>>> of MyDSL: a container, a class named Ex1 which is an instance of
>>>>> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
>>>>> association between Ex1 and Ex2 and a class named Ex3 which is an
>>>>> instance of DSL-Class#2. Now I want to map them to UML. Following my
>>>>> example this would result in mapping:
>>>>> * an instance of container to an uml-package with sterotype
>> dsl-container
>>>>> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
>>>>> sterotype dsl-class#1
>>>>> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
>>>>> sterotype dsl-class#1
>>>>> * an association between Ex1 and Ex2 to an uml association (which may
>>>>> be stereotyped as "dsl-association if easier)
>>>>> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
>>>>> sterotype dsl-class#2
>>>>>
>>>>> Other Mapping possibilities (mentioned if my vision doesn't work in
>>>>> time):
>>>>> * Model-to-Model transformation is an option. I rather dislike this
>>>>> for the classic reasons e.g. consistency between the models,
>>>>> overwriting or synchronization of changes and -for me the most
>>>>> important one- possible information loss due to the lack of
>>>>> representation in one language. In my example this means that if a
>>>>> "NotDslClass" exists in the left UML world for which I have no
>>>>> representation in MyDSL there is no need to represent it in MyDSL. But
>>>>> I guess I would be forced to handle it somehow not to loose
>>>>> information in the back-to-uml transformation.
>>>>> * Customized XML/XMI serialization through extending the XMLHelper
>>>>> also seems error prone and seems to require a good knowledge of
>> XMI,too.
>>>>> Ecore Mapping:
>>>>> So a better approach would be to simulate the DSL-MM for my GMF-DSL
>>>>> editor but actually work directly on an UML model. I found the EMF
>>>>> part of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
>>>>> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
>>>>> found the some starting points or ideas how to realize it. My problem
>>>>> is I can hardly value them nor I know a kind of best practice for
>>>>> this. So it would be really nice to start a discussion about them or
>>>>> if you say just read this f****** manual because I'm stuck right now
>>>>> ;(
>>>>> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff)
>>>>> looks like an option but my impression is that this is not really what
>>>>> I want.
>>>>> * Abuse the Model classes (or facades), normally generated by generate
>>>>> model code as an adapter to eclipse-uml2 facades seems like a lot of
>>>>> work implying a pretty good understanding of EMF.
>>>>> * My Favourite: to use the Ecore2Ecore mapper and a customized
>>>>> rescource handler as mentioned in EMF-EclipseCon p.158ff. My issue
>>>>> here is that it's just mentioned and not really described, but it
>>>>> seems exactly like what I want. This feeling is emphazied by features
>>>>> like OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
>>>>> resources about that or if there isn't a simple proof-of-concept
>>>>> example somewhere.
>>>>>
>>>>> Thanks for reading already
>>>>> -stefan
>>>>>
>>>>>
>>>> ------------------------------------------------------------ ------------
>>
Re: Connecting DSL-eCore w/ UML2 [message #597703 is a reply to message #471129] Tue, 12 June 2007 08:31 Go to previous message
Marco MosconiFriend
Messages: 63
Registered: July 2009
Member
Hi,

I didn't read through the whole post, but if you just want to bridge
your DSL with UML2 Profiles, perhaps the following is exactly what you want:
http://www.eclipse.org/gmt/amw/usecases/umlprofiles/

Regards,
Marco

SKuhn schrieb:
> hi folks,
>
> the following text is quite long, so if you're in a rush just read
> abstract, look at the picture, read constraints, the idea and the last
> point of ecore-mapping.
>
> Abstract:
> basically I want to be able to read & write proper UML2 models with my
> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
> going to outline it in detail because I didn't find a good way to start
> / solve it.
>
> Use Case:
> We're working with MDSD and already have a cardridge for a domain. Right
> now, the generator gets the model from an uml2 tool. The graphical
> editor I have to make (using GMF) for this domain should be able to read
> and write uml2 models because of reasons like flexibility (wheather or
> not to use my editor) or extended control of an uml tool (e.g to model
> the DTOs in the same file). Both, UML2 Tools and the generator accept
> uml2 models from ecore.
>
> DSL:
> There various reasons why a tend to create my own domain specific
> language (DSL) for my graphical editor (GE) in contrast to use uml2.ecore:
> * a DSL which uses around 10 classes seems to be overburdened if it's
> based on the uml2.ecore with several hundred classes.
> * not that error prone because less confusion for the GMF framework and
> even more important for me.
> * some constraints are already implicit from my DSL Metamodel (MM) and
> the others should be easier to write on a simple MM.
> * It seems unhandy to create the uml2.ecore model code (after 5 hours I
> stopped the generation).
> * there must be a reason why GMF enforces the creation of DSLs rather
> than building a customized UML2 editor.
>
> The two worlds:
> This results in two worlds for my "MetaModel" sketch (see attached
> picture). In the left corner, we see famous UML with his well known
> metaclasses and packages. On the right corner we can see the young DSL
> also with metaclasses described in ecore. Now my experiments showed that
> the heavyweigth extensions in which I extended classes from the
> uml2.ecore are uml2-xmi compliant. So the only way to customize uml and
> still be able to use standard uml tools is the lightweight approach. I
> sketched this with the outer circle around uml.
>
> Contraints:
> * I assume that I'm not restricting UML and
> * that every DSL Class has a pendant in uml with a lack of semantics
> expressable by stereotypes.
> * both MM are defined in EMF.
>
> The idea:
> is to connect my DSL-MM with the uml2-MM. This should be realizable by
> creating a profile with sterotypes and enumerations for my DSL and
> represent my DSL classes in uml with the appropriate stereotype. I
> illustrated this in the 2nd picture "Concrete example" which shows
> instances of both MM. So on the right we can see the instance classes of
> MyDSL: a container, a class named Ex1 which is an instance of
> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
> association between Ex1 and Ex2 and a class named Ex3 which is an
> instance of DSL-Class#2. Now I want to map them to UML. Following my
> example this would result in mapping:
> * an instance of container to an uml-package with sterotype dsl-container
> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
> sterotype dsl-class#1
> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
> sterotype dsl-class#1
> * an association between Ex1 and Ex2 to an uml association (which may be
> stereotyped as "dsl-association if easier)
> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
> sterotype dsl-class#2
>
> Other Mapping possibilities (mentioned if my vision doesn't work in time):
> * Model-to-Model transformation is an option. I rather dislike this for
> the classic reasons e.g. consistency between the models, overwriting or
> synchronization of changes and -for me the most important one- possible
> information loss due to the lack of representation in one language. In
> my example this means that if a "NotDslClass" exists in the left UML
> world for which I have no representation in MyDSL there is no need to
> represent it in MyDSL. But I guess I would be forced to handle it
> somehow not to loose information in the back-to-uml transformation.
> * Customized XML/XMI serialization through extending the XMLHelper also
> seems error prone and seems to require a good knowledge of XMI,too.
>
> Ecore Mapping:
> So a better approach would be to simulate the DSL-MM for my GMF-DSL
> editor but actually work directly on an UML model. I found the EMF part
> of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
> found the some starting points or ideas how to realize it. My problem is
> I can hardly value them nor I know a kind of best practice for this. So
> it would be really nice to start a discussion about them or if you say
> just read this f****** manual because I'm stuck right now ;(
> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff) looks
> like an option but my impression is that this is not really what I want.
> * Abuse the Model classes (or facades), normally generated by generate
> model code as an adapter to eclipse-uml2 facades seems like a lot of
> work implying a pretty good understanding of EMF.
> * My Favourite: to use the Ecore2Ecore mapper and a customized rescource
> handler as mentioned in EMF-EclipseCon p.158ff. My issue here is that
> it's just mentioned and not really described, but it seems exactly like
> what I want. This feeling is emphazied by features like
> OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
> resources about that or if there isn't a simple proof-of-concept example
> somewhere.
>
> Thanks for reading already
> -stefan
>
>
> ------------------------------------------------------------ ------------
>
Re: Connecting DSL-eCore w/ UML2 [message #597709 is a reply to message #471145] Tue, 12 June 2007 14:58 Go to previous message
Stefan Kuhn is currently offline Stefan KuhnFriend
Messages: 355
Registered: July 2009
Senior Member
yeah, if it's really working it is- I'll keep you up to date.

Marco Mosconi schrieb:
> Hi,
>
> I didn't read through the whole post, but if you just want to bridge
> your DSL with UML2 Profiles, perhaps the following is exactly what you
> want:
> http://www.eclipse.org/gmt/amw/usecases/umlprofiles/
>
> Regards,
> Marco
>
> SKuhn schrieb:
>> hi folks,
>>
>> the following text is quite long, so if you're in a rush just read
>> abstract, look at the picture, read constraints, the idea and the last
>> point of ecore-mapping.
>>
>> Abstract:
>> basically I want to be able to read & write proper UML2 models with my
>> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
>> going to outline it in detail because I didn't find a good way to
>> start / solve it.
>>
>> Use Case:
>> We're working with MDSD and already have a cardridge for a domain.
>> Right now, the generator gets the model from an uml2 tool. The
>> graphical editor I have to make (using GMF) for this domain should be
>> able to read and write uml2 models because of reasons like flexibility
>> (wheather or not to use my editor) or extended control of an uml tool
>> (e.g to model the DTOs in the same file). Both, UML2 Tools and the
>> generator accept uml2 models from ecore.
>>
>> DSL:
>> There various reasons why a tend to create my own domain specific
>> language (DSL) for my graphical editor (GE) in contrast to use
>> uml2.ecore:
>> * a DSL which uses around 10 classes seems to be overburdened if it's
>> based on the uml2.ecore with several hundred classes.
>> * not that error prone because less confusion for the GMF framework
>> and even more important for me.
>> * some constraints are already implicit from my DSL Metamodel (MM) and
>> the others should be easier to write on a simple MM.
>> * It seems unhandy to create the uml2.ecore model code (after 5 hours
>> I stopped the generation).
>> * there must be a reason why GMF enforces the creation of DSLs rather
>> than building a customized UML2 editor.
>>
>> The two worlds:
>> This results in two worlds for my "MetaModel" sketch (see attached
>> picture). In the left corner, we see famous UML with his well known
>> metaclasses and packages. On the right corner we can see the young DSL
>> also with metaclasses described in ecore. Now my experiments showed
>> that the heavyweigth extensions in which I extended classes from the
>> uml2.ecore are uml2-xmi compliant. So the only way to customize uml
>> and still be able to use standard uml tools is the lightweight
>> approach. I sketched this with the outer circle around uml.
>>
>> Contraints:
>> * I assume that I'm not restricting UML and
>> * that every DSL Class has a pendant in uml with a lack of semantics
>> expressable by stereotypes.
>> * both MM are defined in EMF.
>>
>> The idea:
>> is to connect my DSL-MM with the uml2-MM. This should be realizable by
>> creating a profile with sterotypes and enumerations for my DSL and
>> represent my DSL classes in uml with the appropriate stereotype. I
>> illustrated this in the 2nd picture "Concrete example" which shows
>> instances of both MM. So on the right we can see the instance classes
>> of MyDSL: a container, a class named Ex1 which is an instance of
>> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
>> association between Ex1 and Ex2 and a class named Ex3 which is an
>> instance of DSL-Class#2. Now I want to map them to UML. Following my
>> example this would result in mapping:
>> * an instance of container to an uml-package with sterotype dsl-container
>> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
>> sterotype dsl-class#1
>> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
>> sterotype dsl-class#1
>> * an association between Ex1 and Ex2 to an uml association (which may
>> be stereotyped as "dsl-association if easier)
>> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
>> sterotype dsl-class#2
>>
>> Other Mapping possibilities (mentioned if my vision doesn't work in
>> time):
>> * Model-to-Model transformation is an option. I rather dislike this
>> for the classic reasons e.g. consistency between the models,
>> overwriting or synchronization of changes and -for me the most
>> important one- possible information loss due to the lack of
>> representation in one language. In my example this means that if a
>> "NotDslClass" exists in the left UML world for which I have no
>> representation in MyDSL there is no need to represent it in MyDSL. But
>> I guess I would be forced to handle it somehow not to loose
>> information in the back-to-uml transformation.
>> * Customized XML/XMI serialization through extending the XMLHelper
>> also seems error prone and seems to require a good knowledge of XMI,too.
>>
>> Ecore Mapping:
>> So a better approach would be to simulate the DSL-MM for my GMF-DSL
>> editor but actually work directly on an UML model. I found the EMF
>> part of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
>> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
>> found the some starting points or ideas how to realize it. My problem
>> is I can hardly value them nor I know a kind of best practice for
>> this. So it would be really nice to start a discussion about them or
>> if you say just read this f****** manual because I'm stuck right now ;(
>> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff)
>> looks like an option but my impression is that this is not really what
>> I want.
>> * Abuse the Model classes (or facades), normally generated by generate
>> model code as an adapter to eclipse-uml2 facades seems like a lot of
>> work implying a pretty good understanding of EMF.
>> * My Favourite: to use the Ecore2Ecore mapper and a customized
>> rescource handler as mentioned in EMF-EclipseCon p.158ff. My issue
>> here is that it's just mentioned and not really described, but it
>> seems exactly like what I want. This feeling is emphazied by features
>> like OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
>> resources about that or if there isn't a simple proof-of-concept
>> example somewhere.
>>
>> Thanks for reading already
>> -stefan
>>
>>
>> ------------------------------------------------------------ ------------
>>
Re: Connecting DSL-eCore w/ UML2 [message #600327 is a reply to message #471142] Wed, 13 June 2007 08:02 Go to previous message
Stefan Kuhn is currently offline Stefan KuhnFriend
Messages: 355
Registered: July 2009
Senior Member
hi antonio,

> You must facilitate modeling of instances of your DSL in your Tool.
> You must interoperate with UML tools.
right.

I've got some concerns about M2M Transformation:
* Possible data loss, because my target model (MyDSL) doensn't represent
all the elements I have in my source model (e.g. UML+Profile). (main
concern)
* It looks like my problem already is adressed with ecore2ecore (using
the OPTION_RECORD_UNKNOWN_FEATURE) with pre/post-processing the data
with an recource handler.
* M2M implies addional overhead, serverals RecourceSets and I guess no
chance for event based handling (this would result in sync 'models', so
I can use eclipse with MyGui4MyDSL and the eclipse UML2 modelling tools
at the same time) (this point is -of course- just nice to have).


cheers
stefan

Antonio Carrasco schrieb:
> My 2 cents:
>
> Two forces:
> You must facilitate modeling of instances of your DSL in your Tool.
> You must interoperate with UML tools.
>
> Deal with them separately:
>
> Do your custom DSL editor, i.e. with GMF
> Convert to/from Eclipse UML2.1 with Model2Model transformations,
> Save UML2 interoperable .xmi files from Eclipse UML2.1
> (some tools will not interoperate with the default .xmi from Eclipse)
> Keep asking, to figure out how to interoperate with Diagrams
> from other tools.
>
> Cheers,
> Antonio
>
>
>
>
>
>
>
>
> "SKuhn" <kuhn@oio.de> wrote in message
> news:f4jtnn$d33$1@build.eclipse.org...
>> hi james,
>>
>>> For an example of the ecore2ecore mapping have a look at
>>> org.eclipse.uml2.uml \model at UML2_2_UML.ecore2ecore and .ecore2xml.
>> This
>>> is a mapping between older and newer verion of UML and is used for
>> forward
>>> migration. The org.eclipse.uml2.uml.resource contains code behind the
>>> migration. ( you might want to have a look at the migration guide
>> from the
>>> UML wiki .. it explains the mapping in a human readable format ).
>> I stumbled over it some weeks ago but skipped it because I thought it has
>> nothing to do with my problem. So I'm definitly going to take a look on it
>> soon. Thanks for the hint.
>>
>>> There are draft articles for creating DSL in bugzilla [77413], and links
>>> from the UML wiki.
>>> You might also want to have a look at the UMLTools project for creating
>>> editors for your own metamodel.
>> I already looked at both. I played around with Heavyweight-Extensions but
>> it seemed preety much that other UML Tools e.g. MagicDraw won't handle
>> heavyweight extensions at all. So customizing the UML editor of UMLTools
>> is not an option neither.
>>
>> I found an error in my first post:
>> "Now my experiments showed that the heavyweigth extensions in which I
>> extended classes from the uml2.ecore are !!!NOT!!! uml2-xmi compliant. So
>> the only way to customize uml and still be able to use standard uml tools
>> is the lightweight approach."
>>
>> thanks so far
>> -stefan
>>
>>
>>
>>> Hope that helps,
>>>
>>> - James.
>>>
>>>
>>> "SKuhn" <kuhn@oio.de> wrote in message
>>> news:f4jhq2$76t$1@build.eclipse.org...
>>>> Hi Ed,
>>>>
>>>> I expressed my hopes with "So it would be really nice to start a
>>>> discussion about them or if you say just read this f****** manual
>>>> because I'm stuck right now ;( " in a way that people can say I did it
>>>> this way or this way is really awful/awesome or this is the best way to
>>>> do it.
>>>>
>>>> and later on my 'question' in the last point "I'm wondering where I can
>>>> find good resources about that or if there isn't a simple
>>>> proof-of-concept example somewhere.".
>>>>
>>>> Anyway, the question-representation looks like this:
>>>> Does anybody know good resources which may help me realizing My
>>>> Favourite approach(the last) point under EcoreMapping?
>>>>
>>>> I can't imagine that this is a new problem/approach, so is there already
>>>> a proof-of-concept example somewhere?
>>>>
>>>> > I does sound like it would be
>>>> > perhaps a lot simpler to design your own independent model that has
>>>> no
>>>> > relation to UML2
>>>> Of course ;). My problem is that I somehow need this representation in
>>>> UML (I described this in Use Case).
>>>>
>>>> greets
>>>> stefan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Ed Merks schrieb:
>>>>> Stefan,
>>>>>
>>>>> It is indeed a long post and I actually can't find a single "?" in it,
>>>>> so I'm not really sure what to say. , but I don't think I really
>>> understood well all the
>>>>> issues and concerns...
>>>>>
>>>>>
>>>>> SKuhn wrote:
>>>>>> hi folks,
>>>>>>
>>>>>> the following text is quite long, so if you're in a rush just read
>>>>>> abstract, look at the picture, read constraints, the idea and the last
>>>>>> point of ecore-mapping.
>>>>>>
>>>>>> Abstract:
>>>>>> basically I want to be able to read & write proper UML2 models with my
>>>>>> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
>>>>>> going to outline it in detail because I didn't find a good way to
>>>>>> start / solve it.
>>>>>>
>>>>>> Use Case:
>>>>>> We're working with MDSD and already have a cardridge for a domain.
>>>>>> Right now, the generator gets the model from an uml2 tool. The
>>>>>> graphical editor I have to make (using GMF) for this domain should be
>>>>>> able to read and write uml2 models because of reasons like flexibility
>>>>>> (wheather or not to use my editor) or extended control of an uml tool
>>>>>> (e.g to model the DTOs in the same file). Both, UML2 Tools and the
>>>>>> generator accept uml2 models from ecore.
>>>>>>
>>>>>> DSL:
>>>>>> There various reasons why a tend to create my own domain specific
>>>>>> language (DSL) for my graphical editor (GE) in contrast to use
>>>>>> uml2.ecore:
>>>>>> * a DSL which uses around 10 classes seems to be overburdened if it's
>>>>>> based on the uml2.ecore with several hundred classes.
>>>>>> * not that error prone because less confusion for the GMF framework
>>>>>> and even more important for me.
>>>>>> * some constraints are already implicit from my DSL Metamodel (MM) and
>>>>>> the others should be easier to write on a simple MM.
>>>>>> * It seems unhandy to create the uml2.ecore model code (after 5 hours
>>>>>> I stopped the generation).
>>>>>> * there must be a reason why GMF enforces the creation of DSLs rather
>>>>>> than building a customized UML2 editor.
>>>>>>
>>>>>> The two worlds:
>>>>>> This results in two worlds for my "MetaModel" sketch (see attached
>>>>>> picture). In the left corner, we see famous UML with his well known
>>>>>> metaclasses and packages. On the right corner we can see the young DSL
>>>>>> also with metaclasses described in ecore. Now my experiments showed
>>>>>> that the heavyweigth extensions in which I extended classes from the
>>>>>> uml2.ecore are uml2-xmi compliant. So the only way to customize uml
>>>>>> and still be able to use standard uml tools is the lightweight
>>>>>> approach. I sketched this with the outer circle around uml.
>>>>>>
>>>>>> Contraints:
>>>>>> * I assume that I'm not restricting UML and
>>>>>> * that every DSL Class has a pendant in uml with a lack of semantics
>>>>>> expressable by stereotypes.
>>>>>> * both MM are defined in EMF.
>>>>>>
>>>>>> The idea:
>>>>>> is to connect my DSL-MM with the uml2-MM. This should be realizable by
>>>>>> creating a profile with sterotypes and enumerations for my DSL and
>>>>>> represent my DSL classes in uml with the appropriate stereotype. I
>>>>>> illustrated this in the 2nd picture "Concrete example" which shows
>>>>>> instances of both MM. So on the right we can see the instance classes
>>>>>> of MyDSL: a container, a class named Ex1 which is an instance of
>>>>>> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
>>>>>> association between Ex1 and Ex2 and a class named Ex3 which is an
>>>>>> instance of DSL-Class#2. Now I want to map them to UML. Following my
>>>>>> example this would result in mapping:
>>>>>> * an instance of container to an uml-package with sterotype
>>> dsl-container
>>>>>> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
>>>>>> sterotype dsl-class#1
>>>>>> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
>>>>>> sterotype dsl-class#1
>>>>>> * an association between Ex1 and Ex2 to an uml association (which may
>>>>>> be stereotyped as "dsl-association if easier)
>>>>>> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
>>>>>> sterotype dsl-class#2
>>>>>>
>>>>>> Other Mapping possibilities (mentioned if my vision doesn't work in
>>>>>> time):
>>>>>> * Model-to-Model transformation is an option. I rather dislike this
>>>>>> for the classic reasons e.g. consistency between the models,
>>>>>> overwriting or synchronization of changes and -for me the most
>>>>>> important one- possible information loss due to the lack of
>>>>>> representation in one language. In my example this means that if a
>>>>>> "NotDslClass" exists in the left UML world for which I have no
>>>>>> representation in MyDSL there is no need to represent it in MyDSL. But
>>>>>> I guess I would be forced to handle it somehow not to loose
>>>>>> information in the back-to-uml transformation.
>>>>>> * Customized XML/XMI serialization through extending the XMLHelper
>>>>>> also seems error prone and seems to require a good knowledge of
>>> XMI,too.
>>>>>> Ecore Mapping:
>>>>>> So a better approach would be to simulate the DSL-MM for my GMF-DSL
>>>>>> editor but actually work directly on an UML model. I found the EMF
>>>>>> part of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
>>>>>> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
>>>>>> found the some starting points or ideas how to realize it. My problem
>>>>>> is I can hardly value them nor I know a kind of best practice for
>>>>>> this. So it would be really nice to start a discussion about them or
>>>>>> if you say just read this f****** manual because I'm stuck right now
>>>>>> ;(
>>>>>> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff)
>>>>>> looks like an option but my impression is that this is not really what
>>>>>> I want.
>>>>>> * Abuse the Model classes (or facades), normally generated by generate
>>>>>> model code as an adapter to eclipse-uml2 facades seems like a lot of
>>>>>> work implying a pretty good understanding of EMF.
>>>>>> * My Favourite: to use the Ecore2Ecore mapper and a customized
>>>>>> rescource handler as mentioned in EMF-EclipseCon p.158ff. My issue
>>>>>> here is that it's just mentioned and not really described, but it
>>>>>> seems exactly like what I want. This feeling is emphazied by features
>>>>>> like OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
>>>>>> resources about that or if there isn't a simple proof-of-concept
>>>>>> example somewhere.
>>>>>>
>>>>>> Thanks for reading already
>>>>>> -stefan
>>>>>>
>>>>>>
>>>>> ------------------------------------------------------------ ------------
>
Re: Connecting DSL-eCore w/ UML2 [message #602187 is a reply to message #471138] Thu, 05 July 2007 13:12 Go to previous message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Stefan,

Several of the approaches you describe seem valid. A major difference (an
perhaps a deciding factor) between them seems (to me) to be whether
synchronization between the two domains (your DSL and UML, which
incidentally can also be viewed as a DSL) happens dynamically (at the
in-memory object representation level) or only when a resource is
serialized/deserialized.

The Ecore2Ecore model was designed as a mechanism to describe simple
mappings between two arbitrary EMF (Ecore) models. Ecore2XML was introduced
to provide an alternative representation of suuch mappings that is tailored
to (de)serialization in XML/XMI. In practice, Ecore2XML is really only
useful for mapping between two models that are similar in structure - as
James has mentioned, it is being used successfully in UML2 to migrate models
between different versions of UML. Note that complex mappings still need to
be handled using custom resource handlers and/or post processors (as
described in the advanced EMF tutorials from EclipseCon 2006 and 2007).
Beyond the EMF tutorials, perhaps the best source of information is the
source code. James has already provided you with pointers to the releated
classes in UML2... has this been of some help?

Kenn

"SKuhn" <kuhn@oio.de> wrote in message
news:f4jhq2$76t$1@build.eclipse.org...
> Hi Ed,
>
> I expressed my hopes with "So it would be really nice to start a
> discussion about them or if you say just read this f****** manual because
> I'm stuck right now ;( " in a way that people can say I did it this way
> or this way is really awful/awesome or this is the best way to do it.
>
> and later on my 'question' in the last point "I'm wondering where I can
> find good resources about that or if there isn't a simple proof-of-concept
> example somewhere.".
>
> Anyway, the question-representation looks like this:
> Does anybody know good resources which may help me realizing My Favourite
> approach(the last) point under EcoreMapping?
>
> I can't imagine that this is a new problem/approach, so is there already a
> proof-of-concept example somewhere?
>
> > I does sound like it would be
> > perhaps a lot simpler to design your own independent model that has no
> > relation to UML2
> Of course ;). My problem is that I somehow need this representation in UML
> (I described this in Use Case).
>
> greets
> stefan
>
>
>
>
>
> Ed Merks schrieb:
>> Stefan,
>>
>> It is indeed a long post and I actually can't find a single "?" in it, so
>> I'm not really sure what to say. , but I don't think I really understood
>> well all the issues and concerns...
>>
>>
>> SKuhn wrote:
>>> hi folks,
>>>
>>> the following text is quite long, so if you're in a rush just read
>>> abstract, look at the picture, read constraints, the idea and the last
>>> point of ecore-mapping.
>>>
>>> Abstract:
>>> basically I want to be able to read & write proper UML2 models with my
>>> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
>>> going to outline it in detail because I didn't find a good way to start
>>> / solve it.
>>>
>>> Use Case:
>>> We're working with MDSD and already have a cardridge for a domain. Right
>>> now, the generator gets the model from an uml2 tool. The graphical
>>> editor I have to make (using GMF) for this domain should be able to read
>>> and write uml2 models because of reasons like flexibility (wheather or
>>> not to use my editor) or extended control of an uml tool (e.g to model
>>> the DTOs in the same file). Both, UML2 Tools and the generator accept
>>> uml2 models from ecore.
>>>
>>> DSL:
>>> There various reasons why a tend to create my own domain specific
>>> language (DSL) for my graphical editor (GE) in contrast to use
>>> uml2.ecore:
>>> * a DSL which uses around 10 classes seems to be overburdened if it's
>>> based on the uml2.ecore with several hundred classes.
>>> * not that error prone because less confusion for the GMF framework and
>>> even more important for me.
>>> * some constraints are already implicit from my DSL Metamodel (MM) and
>>> the others should be easier to write on a simple MM.
>>> * It seems unhandy to create the uml2.ecore model code (after 5 hours I
>>> stopped the generation).
>>> * there must be a reason why GMF enforces the creation of DSLs rather
>>> than building a customized UML2 editor.
>>>
>>> The two worlds:
>>> This results in two worlds for my "MetaModel" sketch (see attached
>>> picture). In the left corner, we see famous UML with his well known
>>> metaclasses and packages. On the right corner we can see the young DSL
>>> also with metaclasses described in ecore. Now my experiments showed that
>>> the heavyweigth extensions in which I extended classes from the
>>> uml2.ecore are uml2-xmi compliant. So the only way to customize uml and
>>> still be able to use standard uml tools is the lightweight approach. I
>>> sketched this with the outer circle around uml.
>>>
>>> Contraints:
>>> * I assume that I'm not restricting UML and
>>> * that every DSL Class has a pendant in uml with a lack of semantics
>>> expressable by stereotypes.
>>> * both MM are defined in EMF.
>>>
>>> The idea:
>>> is to connect my DSL-MM with the uml2-MM. This should be realizable by
>>> creating a profile with sterotypes and enumerations for my DSL and
>>> represent my DSL classes in uml with the appropriate stereotype. I
>>> illustrated this in the 2nd picture "Concrete example" which shows
>>> instances of both MM. So on the right we can see the instance classes of
>>> MyDSL: a container, a class named Ex1 which is an instance of
>>> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
>>> association between Ex1 and Ex2 and a class named Ex3 which is an
>>> instance of DSL-Class#2. Now I want to map them to UML. Following my
>>> example this would result in mapping:
>>> * an instance of container to an uml-package with sterotype
>>> dsl-container
>>> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
>>> sterotype dsl-class#1
>>> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
>>> sterotype dsl-class#1
>>> * an association between Ex1 and Ex2 to an uml association (which may be
>>> stereotyped as "dsl-association if easier)
>>> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
>>> sterotype dsl-class#2
>>>
>>> Other Mapping possibilities (mentioned if my vision doesn't work in
>>> time):
>>> * Model-to-Model transformation is an option. I rather dislike this for
>>> the classic reasons e.g. consistency between the models, overwriting or
>>> synchronization of changes and -for me the most important one- possible
>>> information loss due to the lack of representation in one language. In
>>> my example this means that if a "NotDslClass" exists in the left UML
>>> world for which I have no representation in MyDSL there is no need to
>>> represent it in MyDSL. But I guess I would be forced to handle it
>>> somehow not to loose information in the back-to-uml transformation.
>>> * Customized XML/XMI serialization through extending the XMLHelper also
>>> seems error prone and seems to require a good knowledge of XMI,too.
>>>
>>> Ecore Mapping:
>>> So a better approach would be to simulate the DSL-MM for my GMF-DSL
>>> editor but actually work directly on an UML model. I found the EMF part
>>> of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
>>> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
>>> found the some starting points or ideas how to realize it. My problem is
>>> I can hardly value them nor I know a kind of best practice for this. So
>>> it would be really nice to start a discussion about them or if you say
>>> just read this f****** manual because I'm stuck right now ;(
>>> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff) looks
>>> like an option but my impression is that this is not really what I want.
>>> * Abuse the Model classes (or facades), normally generated by generate
>>> model code as an adapter to eclipse-uml2 facades seems like a lot of
>>> work implying a pretty good understanding of EMF.
>>> * My Favourite: to use the Ecore2Ecore mapper and a customized rescource
>>> handler as mentioned in EMF-EclipseCon p.158ff. My issue here is that
>>> it's just mentioned and not really described, but it seems exactly like
>>> what I want. This feeling is emphazied by features like
>>> OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
>>> resources about that or if there isn't a simple proof-of-concept example
>>> somewhere.
>>>
>>> Thanks for reading already
>>> -stefan
>>>
>>>
>>> ------------------------------------------------------------ ------------
>>>
>>
Re: Connecting DSL-eCore w/ UML2 [message #602215 is a reply to message #471227] Thu, 05 July 2007 17:25 Go to previous message
Stefan Kuhn is currently offline Stefan KuhnFriend
Messages: 355
Registered: July 2009
Senior Member
Honestly I have the feeling that there is no really good solution. I
ended up with the decicion to implement a DSL->UML2 M2M transformation
with xTend (oAW, because GMF already uses xPand and they're similar).
I'm running out of time, so I have no space left for experiments ;(.
Thanks for your reply anyway.


Kenn Hussey schrieb:
> Stefan,
>
> Several of the approaches you describe seem valid. A major difference (an
> perhaps a deciding factor) between them seems (to me) to be whether
> synchronization between the two domains (your DSL and UML, which
> incidentally can also be viewed as a DSL) happens dynamically (at the
> in-memory object representation level) or only when a resource is
> serialized/deserialized.
>
> The Ecore2Ecore model was designed as a mechanism to describe simple
> mappings between two arbitrary EMF (Ecore) models. Ecore2XML was introduced
> to provide an alternative representation of suuch mappings that is tailored
> to (de)serialization in XML/XMI. In practice, Ecore2XML is really only
> useful for mapping between two models that are similar in structure - as
> James has mentioned, it is being used successfully in UML2 to migrate models
> between different versions of UML. Note that complex mappings still need to
> be handled using custom resource handlers and/or post processors (as
> described in the advanced EMF tutorials from EclipseCon 2006 and 2007).
> Beyond the EMF tutorials, perhaps the best source of information is the
> source code. James has already provided you with pointers to the releated
> classes in UML2... has this been of some help?
>
> Kenn
>
> "SKuhn" <kuhn@oio.de> wrote in message
> news:f4jhq2$76t$1@build.eclipse.org...
>> Hi Ed,
>>
>> I expressed my hopes with "So it would be really nice to start a
>> discussion about them or if you say just read this f****** manual because
>> I'm stuck right now ;( " in a way that people can say I did it this way
>> or this way is really awful/awesome or this is the best way to do it.
>>
>> and later on my 'question' in the last point "I'm wondering where I can
>> find good resources about that or if there isn't a simple proof-of-concept
>> example somewhere.".
>>
>> Anyway, the question-representation looks like this:
>> Does anybody know good resources which may help me realizing My Favourite
>> approach(the last) point under EcoreMapping?
>>
>> I can't imagine that this is a new problem/approach, so is there already a
>> proof-of-concept example somewhere?
>>
>>> I does sound like it would be
>>> perhaps a lot simpler to design your own independent model that has no
>>> relation to UML2
>> Of course ;). My problem is that I somehow need this representation in UML
>> (I described this in Use Case).
>>
>> greets
>> stefan
>>
>>
>>
>>
>>
>> Ed Merks schrieb:
>>> Stefan,
>>>
>>> It is indeed a long post and I actually can't find a single "?" in it, so
>>> I'm not really sure what to say. , but I don't think I really understood
>>> well all the issues and concerns...
>>>
>>>
>>> SKuhn wrote:
>>>> hi folks,
>>>>
>>>> the following text is quite long, so if you're in a rush just read
>>>> abstract, look at the picture, read constraints, the idea and the last
>>>> point of ecore-mapping.
>>>>
>>>> Abstract:
>>>> basically I want to be able to read & write proper UML2 models with my
>>>> GMF-DSL Editor. For me this sounds like a real common problem, but I'm
>>>> going to outline it in detail because I didn't find a good way to start
>>>> / solve it.
>>>>
>>>> Use Case:
>>>> We're working with MDSD and already have a cardridge for a domain. Right
>>>> now, the generator gets the model from an uml2 tool. The graphical
>>>> editor I have to make (using GMF) for this domain should be able to read
>>>> and write uml2 models because of reasons like flexibility (wheather or
>>>> not to use my editor) or extended control of an uml tool (e.g to model
>>>> the DTOs in the same file). Both, UML2 Tools and the generator accept
>>>> uml2 models from ecore.
>>>>
>>>> DSL:
>>>> There various reasons why a tend to create my own domain specific
>>>> language (DSL) for my graphical editor (GE) in contrast to use
>>>> uml2.ecore:
>>>> * a DSL which uses around 10 classes seems to be overburdened if it's
>>>> based on the uml2.ecore with several hundred classes.
>>>> * not that error prone because less confusion for the GMF framework and
>>>> even more important for me.
>>>> * some constraints are already implicit from my DSL Metamodel (MM) and
>>>> the others should be easier to write on a simple MM.
>>>> * It seems unhandy to create the uml2.ecore model code (after 5 hours I
>>>> stopped the generation).
>>>> * there must be a reason why GMF enforces the creation of DSLs rather
>>>> than building a customized UML2 editor.
>>>>
>>>> The two worlds:
>>>> This results in two worlds for my "MetaModel" sketch (see attached
>>>> picture). In the left corner, we see famous UML with his well known
>>>> metaclasses and packages. On the right corner we can see the young DSL
>>>> also with metaclasses described in ecore. Now my experiments showed that
>>>> the heavyweigth extensions in which I extended classes from the
>>>> uml2.ecore are uml2-xmi compliant. So the only way to customize uml and
>>>> still be able to use standard uml tools is the lightweight approach. I
>>>> sketched this with the outer circle around uml.
>>>>
>>>> Contraints:
>>>> * I assume that I'm not restricting UML and
>>>> * that every DSL Class has a pendant in uml with a lack of semantics
>>>> expressable by stereotypes.
>>>> * both MM are defined in EMF.
>>>>
>>>> The idea:
>>>> is to connect my DSL-MM with the uml2-MM. This should be realizable by
>>>> creating a profile with sterotypes and enumerations for my DSL and
>>>> represent my DSL classes in uml with the appropriate stereotype. I
>>>> illustrated this in the 2nd picture "Concrete example" which shows
>>>> instances of both MM. So on the right we can see the instance classes of
>>>> MyDSL: a container, a class named Ex1 which is an instance of
>>>> DSL-Class#1, a class named Ex2 which is an instance of DSL-Class#1 an
>>>> association between Ex1 and Ex2 and a class named Ex3 which is an
>>>> instance of DSL-Class#2. Now I want to map them to UML. Following my
>>>> example this would result in mapping:
>>>> * an instance of container to an uml-package with sterotype
>>>> dsl-container
>>>> * an instance of DSL-Class#1 named Ex1 to an uml-class named Ex1 with
>>>> sterotype dsl-class#1
>>>> * an instance of DSL-Class#1 named Ex2 to an uml-class named Ex2 with
>>>> sterotype dsl-class#1
>>>> * an association between Ex1 and Ex2 to an uml association (which may be
>>>> stereotyped as "dsl-association if easier)
>>>> * an instance of DSL-Class#2 named Ex3 to an uml-class named Ex3 with
>>>> sterotype dsl-class#2
>>>>
>>>> Other Mapping possibilities (mentioned if my vision doesn't work in
>>>> time):
>>>> * Model-to-Model transformation is an option. I rather dislike this for
>>>> the classic reasons e.g. consistency between the models, overwriting or
>>>> synchronization of changes and -for me the most important one- possible
>>>> information loss due to the lack of representation in one language. In
>>>> my example this means that if a "NotDslClass" exists in the left UML
>>>> world for which I have no representation in MyDSL there is no need to
>>>> represent it in MyDSL. But I guess I would be forced to handle it
>>>> somehow not to loose information in the back-to-uml transformation.
>>>> * Customized XML/XMI serialization through extending the XMLHelper also
>>>> seems error prone and seems to require a good knowledge of XMI,too.
>>>>
>>>> Ecore Mapping:
>>>> So a better approach would be to simulate the DSL-MM for my GMF-DSL
>>>> editor but actually work directly on an UML model. I found the EMF part
>>>> of IBMs EMF/GEF book and the "Effective Use of Eclipse Modeling
>>>> Framework" from EclipseCon 2007 (EMF-EclipseCon) quite interesting and
>>>> found the some starting points or ideas how to realize it. My problem is
>>>> I can hardly value them nor I know a kind of best practice for this. So
>>>> it would be really nice to start a discussion about them or if you say
>>>> just read this f****** manual because I'm stuck right now ;(
>>>> * refering the UML-MM in MyDSL (as described in IBMs book p. 36ff) looks
>>>> like an option but my impression is that this is not really what I want.
>>>> * Abuse the Model classes (or facades), normally generated by generate
>>>> model code as an adapter to eclipse-uml2 facades seems like a lot of
>>>> work implying a pretty good understanding of EMF.
>>>> * My Favourite: to use the Ecore2Ecore mapper and a customized rescource
>>>> handler as mentioned in EMF-EclipseCon p.158ff. My issue here is that
>>>> it's just mentioned and not really described, but it seems exactly like
>>>> what I want. This feeling is emphazied by features like
>>>> OPTION_RECORD_UNKOWN_FEATURE. I'm wondering where I can find good
>>>> resources about that or if there isn't a simple proof-of-concept example
>>>> somewhere.
>>>>
>>>> Thanks for reading already
>>>> -stefan
>>>>
>>>>
>>>> ------------------------------------------------------------ ------------
>>>>
>
>
Previous Topic:Re: UML2 XMI > SVG via XSLT
Next Topic:Association Owner Package
Goto Forum:
  


Current Time: Tue Mar 19 10:56:53 GMT 2024

Powered by FUDForum. Page generated in 0.05361 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top