1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link rel="stylesheet" href="images/../../../css/book.css" type="text/css" />
<link rel="stylesheet" href="images/../../../css/emf-book.css" type="text/css" />
<title>Specifying Package Information in Rose</title>
</head>
<body lang="EN-US" xml:lang="EN-US">
<h1>Specifying Package Information in Rose</h1>
<p>When a Rational Rose class diagram is used as the source for EMF
model generation, there are a number of pieces of information about
each package that are not expressed in the UML, requiring the
generator to infer them from the package name. Instead, it is
preferable to store them directly in the Rose model as model
properties.</p>
<p>To show how this is done, we will use a slightly modified
version of the library model from the
<a href="../../tutorials/clibmod/clibmod.html">Generating an EMF Model</a>
tutorial: <a target="_code" href="images/../library.mdl">library.mdl</a>.</p>
<p>The model elements must belong to a package. When the model is
converted to Ecore, if there are any elements that are not
contained in a package, a package will be created for them, and its
properties will be inferred from the name of the model.</p>
<ul>
<li>Observe that all the elements of the library model are
contained in the "library" package.<br />
<img src="images/rp01.gif" alt="Library package" width="241"
height="206" /><br />
</li>
<li>The model elements are the same as in the previous
tutorial.<br />
<img src="images/rp02.gif" alt="Class diagrams" width="577"
height="403" /><br />
</li>
</ul>
<p>Ecore's additional Rose model properties are defined in a
property file, "ecore.pty". Before we can set them, we must add
them to Rose's vocabulary.</p>
<ul>
<li>From the "Tools" menu, select "Model Properties", and then
"Add...".<br />
<img src="images/rp03.gif" alt="Tools/Model Properties/Add..."
width="246" height="196" /><br />
</li>
<li>The property file is located in the "rose" subdirectory of the
"org.eclipse.emf.codegen.ecore" plug-in. Navigate to that directory,
select "ecore.pty", and click the "Open" button.<br />
<img src="images/rp04.gif"
alt="Update model properties from ecore.pty" width="426"
height="264" />
<br />
</li>
</ul>
<p>The Ecore package properties can now be edited.</p>
<ul>
<li>Right-click the "library" package and select "Open
Specification..." from the pop-up menu.<br />
<img src="images/rp05.gif" alt="Open Specification..." width="301"
height="165" /><br />
</li>
<li>Switch to the "Ecore" tab. To change a property, simply click
on the "Value" column, and type the new text. When finished setting
properties, click the "OK" button.<br />
<img src="images/rp06.gif" alt="Ecore properties" width="344"
height="401" /><br />
</li>
</ul>
<p>The properties that can be set divide into two groups:
properties of the Ecore model itself, and properties of the
GenModel that drives code generation.</p>
<p>The Ecore properties are as follows:</p>
<blockquote>
<table cellpadding="8" cellspacing="0" border="0">
<tr>
<td valign="top">packageName</td>
<td valign="top">The name of the Ecore package, if different from
the Rose/UML name. If not set, the Rose package name, converted to
lower case, is used.</td>
</tr>
<tr>
<td valign="top">nsPrefix</td>
<td valign="top">The namespace prefix for the package's <a
href="http://www.w3.org/TR/REC-xml-names/">XML namespace</a>, used
in a qualified name to select the package's namespace. If not set,
the value of packageName, qualified by basePackage below, is used.</td>
</tr>
<tr>
<td valign="top">nsURI</td>
<td valign="top">The unique URI reference that indentifies the
package's XML namespace. If not set, the value of nsPrefix, with
"http:///" prepended, ".ecore" appended, and all "/"s converted to "."s, is
used.</td>
</tr>
<tr>
<td valign="top">annotation</td>
<td valign="top">Any annotations to be attached to the package. Annotations
provide a flexible mechanism for attaching additional information to Ecore model
elements. An annotation is identified by a source, a unique string that's
typically a URI, and includes as details key/value string pairs. It is specified
as follows:<br /><br />
<tt>http://www.example.org/sourceURI key1='value1' key2='value2' ...</tt></td>
</tr>
</table>
</blockquote>
<p>The GenModel properties are as follows:</p>
<blockquote>
<table cellpadding="8" cellspacing="0" border="0">
<tr>
<td valign="top">prefix</td>
<td valign="top">The prefix used in the names of generated package,
factory, switch, adapter factory (and more) classes for this
package. If not set, the value of packageName, with its first
character capitalized, is used.</td>
</tr>
<tr>
<td valign="top">basePackage</td>
<td valign="top">The Java package of which the generated package is
to be a subpackage. This allows code with globally unique package
names to be easily generated (without modeling empty, nested base
packages). If not set, no default is used.</td>
</tr>
</table>
</blockquote>
<p>In addition to these package properties, the Ecore property file
defines properties for classes, attributes, relations, and
operations, all of which can be found on the "Ecore" tabs of their
respective Specification dialog boxes.</p>
</body>
</html>
|
