| jpasch | 1b00fb9 | 2011-07-27 10:34:25 +0200 | [diff] [blame] | 1 | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
| 2 | <html>
|
| 3 |
|
| 4 | <head>
|
| 5 | <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
|
| 6 | <title>Graphics Framework introduction</title>
|
| 7 | <link href="../book.css" rel="Stylesheet" type="text/css">
|
| 8 | <link href="../code.css" rel="stylesheet" type="text/css">
|
| 9 |
|
| 10 | <style type="text/css">
|
| 11 | .ms-grid5-main {
|
| 12 | border-left: .75pt solid black;
|
| 13 | border-right: 1.5pt solid black;
|
| 14 | border-top: 1.5pt solid black;
|
| 15 | border-bottom: .75pt solid black;
|
| 16 | background-color: white;
|
| 17 | }
|
| 18 | .ms-grid5-tl {
|
| 19 | font-weight: normal;
|
| 20 | color: black;
|
| 21 | border-left: .75pt solid black;
|
| 22 | border-right-style: none;
|
| 23 | border-top-style: none;
|
| 24 | border-bottom: 1.5pt solid black;
|
| 25 | background-color: white;
|
| 26 | }
|
| 27 | .ms-grid5-left {
|
| 28 | font-weight: normal;
|
| 29 | color: black;
|
| 30 | border-left: .75pt solid black;
|
| 31 | border-right-style: none;
|
| 32 | border-top-style: none;
|
| 33 | border-bottom: .75pt solid black;
|
| 34 | background-color: white;
|
| 35 | }
|
| 36 | .ms-grid5-top {
|
| 37 | font-weight: normal;
|
| 38 | color: black;
|
| 39 | border-left: .75pt solid black;
|
| 40 | border-right-style: none;
|
| 41 | border-top-style: none;
|
| 42 | border-bottom: 1.5pt solid black;
|
| 43 | background-color: white;
|
| 44 | }
|
| 45 | .ms-grid5-even {
|
| 46 | font-weight: normal;
|
| 47 | color: black;
|
| 48 | border-left: .75pt solid black;
|
| 49 | border-right-style: none;
|
| 50 | border-top-style: none;
|
| 51 | border-bottom: .75pt solid black;
|
| 52 | background-color: white;
|
| 53 | }
|
| 54 | </style>
|
| 55 |
|
| 56 | </head>
|
| 57 |
|
| 58 | <body>
|
| 59 |
|
| 60 | <h1>Graphiti Introduction</h1>
|
| 61 | <h2>Development of High-Quality Graphical Model Editors</h2>
|
| 62 | <p>Graphiti supports the fast and easy creation of homogeneous graphical editors
|
| 63 | that visualize an underlying Domain Model using a tool-defined graphical
|
| 64 | notation and make editable. We locate Graphiti in the Eclipse Modeling arena and
|
| 65 | distinguish the framework from GMF and GEF. Then, we give an overview of the
|
| 66 | architecture and an introduction into the basic concepts of Graphiti.</p>
|
| 67 | <p>Typical examples are class diagram editors (using the UML notation) or process
|
| 68 | flow editors (using the BPMN notation).</p>
|
| 69 | <p> </p>
|
| 70 | <p><img alt="" height="379" src="visio/class-editor.gif" width="810"></p>
|
| 71 | <p><strong>Figure: Example screenshot of a class diagram editor</strong></p>
|
| 72 | <p> </p>
|
| 73 | <p> </p>
|
| 74 | <p><img alt="" height="576" src="visio/process-editor.gif" width="739"></p>
|
| 75 | <p><strong>Figure: Example screenshot of a process flow editor</strong></p>
|
| 76 | <p> </p>
|
| 77 | <p>If one tries to build a graphical editor for a Domain Model using Eclipse, he
|
| 78 | will soon come across the Eclipse Modeling Framework (EMF) and the Graphical
|
| 79 | Editing Framework (GEF). While EMF provides the basis for modeling, GEF supports
|
| 80 | programming graphical editors.</p>
|
| 81 | <p>But it is immediately noticeable, that GEF is fairly complex and it needs a
|
| 82 | notable amount of work to get used to the framework. Therefore, and also to
|
| 83 | homogenize their tooling, SAP built a framework that hides GEF's complexities
|
| 84 | from the developer and bridges EMF and GEF to ease and speed up the development
|
| 85 | of graphical editors.</p>
|
| 86 | <p>After SAP AG decided in 2009 to donate the framework to the eclipse
|
| 87 | community, the development team was able to deliver the 0.7.0 incubation release
|
| 88 | of the Graphical Tooling Infrastructure (Graphiti) in October, 2010 and 0.8.0
|
| 89 | with Indigo in June 2011. We should emphasize that already the SAP-internal
|
| 90 | predecessor of Graphiti was in productive use.</p>
|
| 91 | <p>Graphiti provides the following benefits for development and usage:</p>
|
| 92 | <ul>
|
| 93 | <li>low entry barrier: platform specific technologies (GEF/Draw2D) are
|
| 94 | hidden</li>
|
| 95 | <li>incremental development: fast payoffs by using default implementations,
|
| 96 | short development cycle (program, debug)</li>
|
| 97 | <li>homogeneous editors: editors on top of Graphiti look and behave
|
| 98 | similarly</li>
|
| 99 | <li>optional support of different platforms: diagrams are defined platform
|
| 100 | independently, in principle they can be rendered on any platform</li>
|
| 101 | </ul>
|
| 102 | <p>Graphiti is an alternative to the <em>Graphical Modeling Framework (GMF)</em>
|
| 103 | that exists for some time at Eclipse. Basic differences in the paradigms of
|
| 104 | Graphiti and GMF are listed in table below.</p>
|
| 105 | <p>
|
| 106 | </p>
|
| 107 |
|
| 108 |
|
| 109 | <table class="ms-grid5-main" style="width: 500" cellspacing="1">
|
| 110 | <!-- fpstyle: 20,011111100 -->
|
| 111 | <tr>
|
| 112 | <td class="ms-grid5-tl" style="width: 20%; height: 19px"></td>
|
| 113 | <td class="ms-grid5-top" style="width: 40%; height: 19px"><strong>Graphiti</strong></td>
|
| 114 | <td class="ms-grid5-top" style="width: 40%; height: 19px"><strong>GMF</strong></td>
|
| 115 | </tr>
|
| 116 | <tr>
|
| 117 | <td class="ms-grid5-left" style="width: 20%"><strong>Architecture</strong></td>
|
| 118 | <td class="ms-grid5-even" style="width: 40%">runtime-oriented</td>
|
| 119 | <td class="ms-grid5-even" style="width: 40%">generative</td>
|
| 120 | </tr>
|
| 121 | <tr>
|
| 122 | <td class="ms-grid5-left" style="width: 20%"><strong>Interface</strong></td>
|
| 123 | <td class="ms-grid5-even" style="width: 40%">self-contained</td>
|
| 124 | <td class="ms-grid5-even" style="width: 40%">GEF-dependent</td>
|
| 125 | </tr>
|
| 126 | <tr>
|
| 127 | <td class="ms-grid5-left" style="width: 20%"><strong>Client-Logic</strong></td>
|
| 128 | <td class="ms-grid5-even" style="width: 40%">centralized (feature concept)</td>
|
| 129 | <td class="ms-grid5-even" style="width: 40%">distributed functionality</td>
|
| 130 | </tr>
|
| 131 | <tr>
|
| 132 | <td class="ms-grid5-left" style="width: 20%"><strong>Look & Feel</strong></td>
|
| 133 | <td class="ms-grid5-even" style="width: 40%">standardized, defined by SAP usability experts</td>
|
| 134 | <td class="ms-grid5-even" style="width: 40%">simple, adaptable in generated code</td>
|
| 135 | </tr>
|
| 136 | </table>
|
| 137 | <p><strong>Table: Graphiti vs. GMF</strong></p>
|
| 138 | <p> </p>
|
| 139 | <p>As paramount difference between the architectures of the frameworks we rate
|
| 140 | that GMF follows a generative approach, while in Graphiti one programs against a
|
| 141 | plain old Java interface. Graphiti's approach has the big advantage, that no
|
| 142 | generated source code must be manipulated to adapt the editor – in contrast to
|
| 143 | GMF where one has to change generated sources, which can cause headaches when
|
| 144 | regenerating. </p>
|
| 145 | <p> </p>
|
| 146 |
|
| 147 | <h2>Architecture</h2>
|
| 148 | <p>Naturally, communication between a user and a Graphiti based tool happens via
|
| 149 | the screen as well as by mouse and keyboard (see figure). An Interaction
|
| 150 | Component will receive requests such as resizing, drag-and-drop, or deleting.
|
| 151 | The actual processing of these requests happens in a so-called <strong>Diagram
|
| 152 | Type Agent</strong>, which will be discussed in the following section in more
|
| 153 | detail.</p>
|
| 154 | <p>It is the objective of the Rendering Engine to display the current data on
|
| 155 | the screen. Rendering Engine and Interaction Component together form the
|
| 156 | framework components of Graphiti - and thus the actual Graphiti runtime. The
|
| 157 | technical realization of the Graphiti runtime is based on the Graphical Editing
|
| 158 | Framework (GEF) in conjunction with Draw2d. Graphiti’s defaults ensure a uniform
|
| 159 | user interface (look and feel) of all Graphiti based tools.</p>
|
| 160 | <h2>Diagram Type Agent </h2>
|
| 161 | <p>As mentioned already above, the Diagram Type Agent is addressed via the
|
| 162 | Interaction Component. This happens over a standardized interface. The Diagram
|
| 163 | Type Agent has to be implemented and made available by the developer. For this
|
| 164 | implementation developers can make use of lots of various services as well as
|
| 165 | many meaningful standard implementations. </p>
|
| 166 | <p>Assistance of the services and standard implementations can support a
|
| 167 | developer to create his own graphical editor really fast. For example, actions
|
| 168 | like move, resize, delete, remove, and print are available immediately. One
|
| 169 | should not regard a first version as a prototype which has to be thrown away
|
| 170 | later. Rather the initial version can be extended to a complete product
|
| 171 | incrementally with increasing Graphiti know-how and rising requirements.</p>
|
| 172 | <p>In other words: In the beginning a developer comes to a functional editor
|
| 173 | very quickly. This editor can be adorned gradually (e.g. color gradients) and
|
| 174 | can be equipped with additional functionality (e.g. direct editing, extension of
|
| 175 | the context menus and context buttons).</p>
|
| 176 | <p>A Diagram Type Agent’s major task is to modify the <em>model data</em>. On
|
| 177 | the one side we have the <em>Pictogram Model</em> (incl. <em>Link Model</em>)
|
| 178 | whose <em>metamodel</em> is made available by Graphiti and on the other side we
|
| 179 | have the <em>domain specific model</em> which comes from the developer. These
|
| 180 | models are explained in the following.</p>
|
| 181 | <h2>Domain Model </h2>
|
| 182 | <p>The Domain Model contains the data which has to be visualized graphically. A
|
| 183 | developer would for example use the Ecore metamodel for a graphical Ecore
|
| 184 | editor. An editor for BPM (Business Process Management) would use the Businesses
|
| 185 | Process Modeling Notation.</p>
|
| 186 | <p>It is of advantage (however not absolutely necessary) if this model is
|
| 187 | available in EMF just like the Pictogram Model. But Graphiti can deal also with
|
| 188 | models outside EMF. In Graphiti, the data of the Domain Models are called
|
| 189 | <strong>Business Objects</strong>.</p>
|
| 190 | <h2>Pictogram Model</h2>
|
| 191 | <p>The Pictogram Model contains the complete information for representing a
|
| 192 | diagram. That implies that each diagram can be represented without the presence
|
| 193 | of the Domain Data. This requires a partially redundant storage of data, which
|
| 194 | is present both in the Pictogram Model and in the Domain Model. Imagine the
|
| 195 | class names in case of an Ecore editor. Since data redundancy always draws the
|
| 196 | problem of the synchronization, Graphiti offers a concept to update this data.
|
| 197 | Data which is out of sync can be visualized graphically and can be corrected
|
| 198 | (semi-) automatically by the use of so-called<strong> Update Features</strong>.
|
| 199 | This approach enables an editing of Domain Data with different tools and a
|
| 200 | subsequent updating of already existing diagrams.</p>
|
| 201 | <p>A detailed discussion of the Pictogram metamodel would blow up the content of
|
| 202 | this article. Further information can be found in the „<em>org.eclipse.graphiti.mm</em>
|
| 203 | “-plugin which contains the metamodel and some diagrams. The diagrams can be
|
| 204 | viewed with the help of the Ecore tooling.</p>
|
| 205 | <p>Th<a name="Hyperlink to tutorial"></a>e tutorial will show where data of the
|
| 206 | Pictogram Model is produced for the graphical representation.</p>
|
| 207 | <h2>Link Model</h2>
|
| 208 | <p>The Link Model is responsible for connecting data from the Domain Model and
|
| 209 | the graphical representation (that is, data from the Pictogram Model). These
|
| 210 | connections are again needed by many actions in the graphical editor. For
|
| 211 | instance, a deletion or a move of a graphical object needs also access to the
|
| 212 | associated object of the Domain Model in order to be able to make the necessary
|
| 213 | changes.</p>
|
| 214 | <h2>Tasks of the Diagram Type Agent </h2>
|
| 215 | <p>The tasks of the Diagram Type Agent can be explained most conveniently on the
|
| 216 | basis of a small example - in this case we use a create operation which is
|
| 217 | initiated by the user through the Interaction Component. The user clicks into
|
| 218 | the tools palette of the graphical editor and draws a rectangle in the diagram
|
| 219 | to indicate size and position of the object to be created. Now the Diagram Type
|
| 220 | Agent does the following:</p>
|
| 221 | <ul>
|
| 222 | <li> Create a new object in the Domain Model.</li>
|
| 223 | <li>Create the graphical visualization in the Pictogram Model. E.g., create
|
| 224 | Graphics Algorithms like a <span class="keyword">RoundedRectangle</span> or
|
| 225 | a text element. Initialize them with colors and fonts and do the layout.</li>
|
| 226 | <li>Create the link between<em> Pictogram Model object</em> and<em> Domain
|
| 227 | Model object</em> (<em>Link Model</em>).</li>
|
| 228 | </ul>
|
| 229 | <h2>The Feature Concept </h2>
|
| 230 | <p>Figure 2 displays the internal structure of the Diagram Type Agent. The
|
| 231 | actors shown there are to be provided by the developer. This means he has to
|
| 232 | implement an amount of so-called Features which are similar to operations. Here
|
| 233 | are some typical examples for Graphiti Features:</p>
|
| 234 | <ul>
|
| 235 | <li><em>Add Features</em> create the graphical representation of Domain
|
| 236 | Model elements in the Pictogram Model.</li>
|
| 237 | <li><em>Create Features</em> produce new objects in the Domain Model as well
|
| 238 | as the appropriate graphical representations. Here it makes sense to reuse
|
| 239 | existing <em>Add Features</em>.</li>
|
| 240 | <li><em>Remove Features</em> delete graphical representations in the
|
| 241 | Pictogram Model.</li>
|
| 242 | <li><em>Delete Features</em> delete both, a Domain Model object and its
|
| 243 | graphical representations, in the Pictogram Model.</li>
|
| 244 | </ul>
|
| 245 | <p>A <strong>Feature Provider</strong> supplies the needed features considering
|
| 246 | the given context. Processing the features leads to the modification of the
|
| 247 | appropriate data specified above.</p>
|
| 248 | <p>Further diagram type specific and tool specific requests to the <strong>
|
| 249 | Interaction Component</strong> are handled by the <strong>Diagram Type Provider</strong>.
|
| 250 | This includes the selection of the appropriate update strategy, that is, the
|
| 251 | decision when synchronizations between Domain and Pictogram Model have to be
|
| 252 | done.</p>
|
| jpasch | 1b00fb9 | 2011-07-27 10:34:25 +0200 | [diff] [blame] | 253 | <p> </p>
|
| 254 | <p> </p>
|
| 255 | <p> </p>
|
| 256 | <p> </p>
|
| 257 | <p> </p>
|
| 258 | <p> </p>
|
| 259 | <p> </p>
|
| 260 | <p> </p>
|
| 261 |
|
| 262 | </body>
|
| 263 |
|
| 264 | </html>
|