diff options
Diffstat (limited to 'plugins/org.eclipse.sirius.sample.ecore.design/doc/user-guide.html')
| -rw-r--r-- | plugins/org.eclipse.sirius.sample.ecore.design/doc/user-guide.html | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/plugins/org.eclipse.sirius.sample.ecore.design/doc/user-guide.html b/plugins/org.eclipse.sirius.sample.ecore.design/doc/user-guide.html index a41f7a1cf3..9c37557db9 100644 --- a/plugins/org.eclipse.sirius.sample.ecore.design/doc/user-guide.html +++ b/plugins/org.eclipse.sirius.sample.ecore.design/doc/user-guide.html @@ -1 +1 @@ -<?xml version='1.0' encoding='utf-8' ?><!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"><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"/></head><body><h1 id="EcoreDesignerUserGuide">Ecore Designer User Guide</h1><h2 id="overview">Overview</h2><p>The <i>Sirius Ecore Modeler</i> provides several representations organized in different viewpoints which can be used to create, view and edit Ecore models. It also provides a good example of a realistic use of the Sirius technology. This guide is targeted to end users, but Sirius specifiers can study the source of the <i>Sirius Ecore Modeler</i> to see how many of the features of Sirius are used in practice.</p><p>The viewpoints available are:</p><ul><li><a href="#design">Design</a> is the main viewpoint which can be used to create and edit Ecore models. It provides both a graphical representation of Ecore models (similar to a UML class diagram) and a tabular (spreadsheet-like) representation of the same models.</li><li><a href="#archetype">Archetype</a> extends the main diagram from the <i>Design</i> viewpoint to add support for <a href="http://en.wikipedia.org/w/index.php?title=UML_colors&oldid=381749673">modeling in color with archetypes</a>.</li><li><a href="#documentation">Documentation</a> extends the main diagram from the <i>Design</i> viewpoint to add support for documentation annotations.</li><li><a href="#quality">Quality</a> provides several graphical representations of Ecore models which can be used to assess their quality, for example by analyzing the dependencies between different packages.</li><li><a href="#review">Review</a> provides a tabular editor to document models for review.</li><li><a href="#generation">Generation</a> provides support for customizing some of the EMF Generation properties of a model.</li></ul><p>The following sections provide more details on each viewpoint.</p><h2 id="design">The Design Sirius</h2><p>This viewpoint provides two main representations: <strong>Entities</strong> and <strong>Classes</strong>. </p><h3 id="design.entities">The Entities Diagram</h3><p><strong>Entities</strong> provides a class diagram-like graphical representation of an Ecore model. It is the main graphical representation to create, visualize and edit Ecore models. The figure below shows an example diagram: </p><p><img border="0" src="images/example_design_entities.png"/></p><p>Entities diagram are created on Ecore packages, and show all the contents of that package. If the <strong>Package</strong> optional layer is enabled (which it is by default), the sub-packages and their content is also visible. The optional layer <strong>Dynamic</strong> adds a tool in the palette to create a dynamic instance of an EClass defined in your model, without requiring EMF code generation.</p><p>The palette provides all the tools required to:</p><ul><li>create new classes, data types and enumerations (section <i>Classifier</i>),</li><li>populate them with attributes, operations and literal values (section <i>Feature</i>),</li><li>create relationships between your concepts (section <i>Relation</i>). </li></ul><p>When keeping the mouse on a selected element, a popup will appear with modeling assistants (shortcut icons) for all the tools which can be applied on the selected element. For example in the figure below, an EClass is selected, and shortcuts are available to create new EOperation and new EAttributes in that class without going back to the palette:</p><p><img border="0" src="images/modeling_assistant.png"/></p><p>To delete an element, simply select it on the diagram and hit the <i>Delete</i> key, or invoke the <i>Delete from model</i> action from the context menu or the diagram’s toolbar.</p><p>Packages, classifiers, and features can be moved into a different parent (package or classifier, depending on the case), by simple drag’n’drop. The source and target elements of all the relations can also be modified by dragging the extremity of the corresponding edge to the new source or target element.</p><p>Direct edit of all the elements labels is supported, to quickly rename the element and, in some cases, other properties beside the name:</p><ul><li><strong>Direct Edit on EAttributes</strong>: the label of an EAttribute indicates the name, type and default value (if specified). If the attribute is derived, the name is prefixed by a «/». For example: <code>/myDerivedAttribute : EString = "default"</code>. When editing an attribute’s label, each of these can be controlled. For example, entering <code>myNewName : EInt</code> will change the name of the attribute, set it non-derived (as the new name does not start with a «/») and change the type to <code>EInt</code>. The default value will not be modified as it is not mentioned in the text entered. Similarly, entering <code>myNewName = 42</code> will change the default value but not the type, which is not specified. There are also shortcuts that allow you to edit quicker the attribute’s label to your need. For example:<ul><li>entering <code>newName</code> will simply rename the method but keep its parameters and return type;</li><li>entering <code>: EInt</code> will simply rename the return type;</li><li>entering <code>= 42</code> will simply change the default value;</li><li>then you can change two or all the parts of the attribute’s label, e.g entering <code>newName = 47</code> will change the name and the value but not the type or <code>newName:EInt=105</code>will change the entire label.</li></ul></li><li><strong>Direct Edit on EOperations</strong>: the label of an EOperation indicates the operation’s name, parameters (name and type), and return value. For example: <code>m(a A, b B) : EBoolean</code>. Each part (name, parameters and type) can be modified through direct edit. If a part is not mentioned in the edit string, it will not be modified. Using the previous example, <code>m2</code> would simply rename the method but keep its parameters and return type, <code>:EInt</code> would just change the type, and <code>m()</code> would keep the same name and return type but remove all the parameters. When specifying parameters, they must be separated by a comma (<code>,</code>). The type of a parameter is optional; if specified, it can be separated from the name by a colon (<code>:</code>), although this is not required.</li><li><strong>Direct Edit on EReferences</strong>: the label of an EReference indicates its name, cardinality and whether it is derived or not. For example: <code>[0..*] /ref</code> denotes a derived reference named <code>ref</code> which can point to any number of elements (including zero). When editing the label, it is possible to specify only the name and derived attribute (e.g. <code>renamedRef</code>), only the cardinality (e.g. <code lang="1..1">@) or both (e.g. @[0..1] ref2</code>). Three special strings are also support to make some common operations quicker:<ul><li>the edit strings <code>0</code> and <code>1</code> only changes the lower bound of the cardinality of the reference, to 0 or 1;</li><li>the edit string <code>*</code> only changes the upper bound of the cardinality of the reference, to -1 (meaning «unbounded»).</li></ul></li></ul><p>These direct edit features are provided as convenience for common tasks. For more complex customization of the other properties of an element, you can always access all their properties in the <i>Semantic</i> section of the <i>Properties</i> view when the element is selected.</p><h4 id="design.entities.blank">Support for unsynchronized Entities diagrams.</h4><p>By default, Entities diagrams are in <strong>synchronized</strong> mode, which means the graphical elements visible on the diagram always include all the elements in the corresponding package. Sometimes you want a diagram to show only a subset of these elements, for example when documenting a particular aspect of the model while ignoring the rest. In addition to explicitly hiding some elements in the diagram, it is also possible to switch the diagram in <strong>unsynchronized</strong> mode from the context menu on the diagram’s background. In this mode, it becomes possible to remove the graphical representations of some of the model elements without affecting the underlying model by using the <i>Delete from diagram</i> action. Be aware that if you have an existing diagram in <i>unsynchronized</i> mode and you add new elements in the model from outside this diagram (from another diagram or table for example), the new elements will not appear automatically on the unsynchronized diagram.</p><h3 id="entities.classes">The Classes Table Editor</h3><p>This representation provides a tabular editor for all the classes in an Ecore model and their structural features (attributes and references):</p><p><img border="0" src="images/example_design_classes.png"/></p><p>The left column shows the list of classes and their structural features in the current package in a tree. If the package contains sub-packages, they are also shown with their content, recursively.</p><p>The <i>Name</i> column can be used to edit the name of a package, class or feature. To see and edit other properties of an element, simply select the corresponding line and use the <i>Properties</i> view to access all the properties of the element. </p><h2 id="archetype">The Archetype Sirius</h2><p>When the <i>Archetype</i> viewpoint is enabled, a new optional layer named <i>Archetypes</i> is available in the main <i>Entities</i> graphical modeler, which adds support for <a href="http://en.wikipedia.org/w/index.php?title=UML_colors&oldid=381749673">modeling in color with archetypes</a>.</p><p>Concretely, when the layer is enabled, four new tools become available in the palette, as shown in the figure below: </p><p><img border="0" src="images/archetypes.png"/></p><p>These tools can be used to create new EClasses with special annotations indicating they represent some particular kind of elements. Each of the four kinds of archetypes supported are represented by a different color. As shown on the figure, the tools can also be used on already existing EClasses to set or change their categorization.</p><p>Inside the model, the archetypes are encoded as EAnnotations added to the EClass, with a source of <code>http://www.eclipse.org/sirius/dnc/archetype</code> and a single details entry. The key of the entry is <code>archetype</code>, and the value can be one of (descriptions taken from the Wikipedia page):</p><ul><li><code>MomentInterval</code>: represents a moment or interval of time; displayed in pink.</li><li><code>Description</code>: a catalog-like description which classifies or ‹labels› an object; displayed in blue.</li><li><code>Role</code>: represents a way of participating in an activity (by either a person, place, or thing); displayed in yellow.</li><li><code>Thing</code>: represents something tangible, uniquely identifiable; displayed in green.</li></ul><h2 id="documentation">The Documentation Sirius</h2><p>When the <i>Documentation</i> viewpoint is enabled, a new optional layer named <i>Documentation</i> is available (and enabled by default). This layer adds two new tools to the palette in the <i>Documentation</i> section:</p><ul><li><i>Doc Annotation</i> can be used to create a note on the diagram in which free-form documentation can be typed. They are represented graphically by green rectangles.</li><li><i>Doc Assignment</i> can be used to assign a documentation note created by <i>Doc Annotation</i> to a class on the diagram. The assignment is represented by a green arrow from the note to the class.</li></ul><p>In addition, the <i>Documentation</i> layer customizes the representation of classes so that classes which do not have any documentation assigned to them are drawn with a bright red border to stand out and be identified easily.</p><p>The figure below illustrates these features:</p><p><img border="0" src="images/documentation_layer.png"/></p><p>Technically, the documentation annotations are stored in a way compatible with EMF’s documentation capabilities: the annotation has a source of <code>http://www.eclipse.org/emf/2002/GenModel</code> and the documentation string itself is stored in a details entry with key <code>documentation</code>.</p><h2 id="quality">The Quality Sirius</h2><p>The <i>Quality</i> viewpoint provides three types of diagrams and a new optional layer for the <i>Entities</i> diagram which can be used to assess the quality of a model based on different metrics.</p><h3 id="quality.dependencies">Dependencies Diagram</h3><p><i>Dependencies</i> diagrams can be created on <i>EPackages</i>. They show the target package itself and all the other packages it depends on through its contents. For example, if an EClass in the target package has a reference whose type is defined in another one, an edge will be visible between the packages to represent their dependency.</p><p>The figure below shows an <i>Entities</i> diagram on a sample Ecore model on the left, and the corresponding <i>Dependencies</i> diagram for the <code>bank</code> package on the right. The package which is analyzed is shown in yellow, and the other packages (its dependencies) in orange. A red arrow from package to another indicates a dependency.</p><p><img border="0" src="images/dependencies.png"/></p><p>The optional layer <i>Content</i> (disabled by default) can be enable to show the classifiers which are defined inside each of the packages.</p><h3 id="quality.relations">Relations Diagram</h3><p><i>Relations</i> diagrams are similar in intent to <i>Dependencies</i> diagram, but on the level of EClasses instead of packages. They are created on an EClass (say <i>A</i>), which is represented on the diagram. Two optional layers (disabled by default) are available to make visible on the diagram either the classes on which <i>A</i> depends or which depend on <i>A</i>, with connections representing the direction of the dependency. A class <i>A</i> is considered depending on another class <i>B</i> either if <i>B</i> is a direct supertype of <i>A</i> or if <i>A</i> has an EReference of type <i>B</i>.</p><p>The figure below illustrates a <i>Relations</i> diagram on the class <i>User</i> defined in the sample model already used for the <i>Dependencies</i> diagram. Here, both optional layers are enabled, so we see both classes which depend on <i>User</i> (here <i>Account</i>) and classes on which <i>User</i> depends (<i>Date</i> and <i>Address</i>).</p><p><img border="0" src="images/relations.png"/></p><h3 id="quality.hierarchy">Hierarchy Diagram</h3><p><i>Hierarchy</i> diagrams can be created on an EClass, and represent both the class itself and all its direct and indirect super-types. </p><p>The figure below shows a sample metamodel for a filesystem on the left, and on the right a <i>Hierarchy</i> diagram on the <code>Spreadsheet</code> class (shown in bold), which show all its direct and indirect super-types.</p><p><img border="0" src="images/hierarchy.png"/></p><h3 id="quality.size">Size Layer</h3><p>The <i>Quality</i> viewpoint also extends the <i>Entities</i> diagram with a new optional layer named <i>Size</i> (disabled by default). When enabled, it changes the color of the EClasses on the diagram to shades of green, based on the size of the EClass (i.e. the number of features it contains). The more features a class contains, the more complex it is considered and the darker it is represented. </p><p>The figure below shows a subset of the filestystem metamodel used above, with the <i>Size</i> layer enabled:</p><p><img border="0" src="images/size.png"/></p><p>We can see that the classes have a different color depending on how much features they contain. Small classes are bright green, classes with a few features are a darker shade of green, and very big classes which probably define too many features are shown in red.</p><h2 id="review">The Review Sirius</h2><p>The <i>Review</i> viewpoint provides a table which can be used to review and document a model.</p><h3 id="review.documentation">The Documentation Table</h3><p>The <i>Documentation</i> table (created on an <i>EPackage</i>) can be used to review and edit the documentation annotations associated with the EClasses of a package and their features. See the example below:</p><p><img border="0" src="images/documentation_table.png"/></p><h2 id="generation">The Generation Sirius</h2><p>The <i>Generation</i> viewpoint provides a table to edit the generation configuration associated to an Ecore model. Note that it can be enabled only if the <code>genmodel</code> associated to the <code>ecore</code> resource is loaded as a semantic resource inside the session.</p><h3 id="generation.genpackage">The GenPackage Attributes Table</h3><p>This table is used to edit some of the generation configuration associated to an Ecore model. To use it, you must have initialized the <code>genmodel</code> corresponding to the Ecore model and added it as a semantic resource in the session. Then you can create a new <i>GenPackage Attributes</i> table on the top-level <i>GenPackage</i> element.</p><p>For each structural feature of each type in a package (and its sub-packages), the table shows two columns, «Category» and «Description», which correspond to the category in which to put the feature’s property descriptor, and the description to use for that descriptor. These informations are stored in the <code>genmodel</code> and used by EMF to organize the properties of model elements into logical categories in the property sheets it generates.</p><p><img border="0" src="images/genpackage_table.png"/></p></body></html>
\ No newline at end of file +<?xml version='1.0' encoding='utf-8' ?><!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"><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"/></head><body><h1 id="EcoreDesignerUserGuide">Ecore Designer User Guide</h1><h2 id="overview">Overview</h2><p>The <i>Sirius Ecore Modeler</i> provides several representations organized in different viewpoints which can be used to create, view and edit Ecore models. It also provides a good example of a realistic use of the Sirius technology. This guide is targeted to end users, but Sirius specifiers can study the source of the <i>Sirius Ecore Modeler</i> to see how many of the features of Sirius are used in practice.</p><p>The viewpoints available are:</p><ul><li><a href="#design">Design</a> is the main viewpoint which can be used to create and edit Ecore models. It provides both a graphical representation of Ecore models (similar to a UML class diagram) and a tabular (spreadsheet-like) representation of the same models.</li><li><a href="#archetype">Archetype</a> extends the main diagram from the <i>Design</i> viewpoint to add support for <a href="http://en.wikipedia.org/w/index.php?title=UML_colors&oldid=381749673">modeling in color with archetypes</a>.</li><li><a href="#documentation">Documentation</a> extends the main diagram from the <i>Design</i> viewpoint to add support for documentation annotations.</li><li><a href="#quality">Quality</a> provides several graphical representations of Ecore models which can be used to assess their quality, for example by analyzing the dependencies between different packages.</li><li><a href="#review">Review</a> provides a tabular editor to document models for review.</li><li><a href="#generation">Generation</a> provides support for customizing some of the EMF Generation properties of a model.</li></ul><p>The following sections provide more details on each viewpoint.</p><h2 id="design">The Design Viewpoint</h2><p>This viewpoint provides two main representations: <strong>Entities</strong> and <strong>Classes</strong>. </p><h3 id="design.entities">The Entities Diagram</h3><p><strong>Entities</strong> provides a class diagram-like graphical representation of an Ecore model. It is the main graphical representation to create, visualize and edit Ecore models. The figure below shows an example diagram: </p><p><img border="0" src="images/example_design_entities.png"/></p><p>Entities diagram are created on Ecore packages, and show all the contents of that package. If the <strong>Package</strong> optional layer is enabled (which it is by default), the sub-packages and their content is also visible. The optional layer <strong>Dynamic</strong> adds a tool in the palette to create a dynamic instance of an EClass defined in your model, without requiring EMF code generation.</p><p>The palette provides all the tools required to:</p><ul><li>create new classes, data types and enumerations (section <i>Classifier</i>),</li><li>populate them with attributes, operations and literal values (section <i>Feature</i>),</li><li>create relationships between your concepts (section <i>Relation</i>). </li></ul><p>When keeping the mouse on a selected element, a popup will appear with modeling assistants (shortcut icons) for all the tools which can be applied on the selected element. For example in the figure below, an EClass is selected, and shortcuts are available to create new EOperation and new EAttributes in that class without going back to the palette:</p><p><img border="0" src="images/modeling_assistant.png"/></p><p>To delete an element, simply select it on the diagram and hit the <i>Delete</i> key, or invoke the <i>Delete from model</i> action from the context menu or the diagram’s toolbar.</p><p>Packages, classifiers, and features can be moved into a different parent (package or classifier, depending on the case), by simple drag’n’drop. The source and target elements of all the relations can also be modified by dragging the extremity of the corresponding edge to the new source or target element.</p><p>Direct edit of all the elements labels is supported, to quickly rename the element and, in some cases, other properties beside the name:</p><ul><li><strong>Direct Edit on EAttributes</strong>: the label of an EAttribute indicates the name, type and default value (if specified). If the attribute is derived, the name is prefixed by a «/». For example: <code>/myDerivedAttribute : EString = "default"</code>. When editing an attribute’s label, each of these can be controlled. For example, entering <code>myNewName : EInt</code> will change the name of the attribute, set it non-derived (as the new name does not start with a «/») and change the type to <code>EInt</code>. The default value will not be modified as it is not mentioned in the text entered. Similarly, entering <code>myNewName = 42</code> will change the default value but not the type, which is not specified. There are also shortcuts that allow you to edit quicker the attribute’s label to your need. For example:<ul><li>entering <code>newName</code> will simply rename the method but keep its parameters and return type;</li><li>entering <code>: EInt</code> will simply rename the return type;</li><li>entering <code>= 42</code> will simply change the default value;</li><li>then you can change two or all the parts of the attribute’s label, e.g entering <code>newName = 47</code> will change the name and the value but not the type or <code>newName:EInt=105</code>will change the entire label.</li></ul></li><li><strong>Direct Edit on EOperations</strong>: the label of an EOperation indicates the operation’s name, parameters (name and type), and return value. For example: <code>m(a A, b B) : EBoolean</code>. Each part (name, parameters and type) can be modified through direct edit. If a part is not mentioned in the edit string, it will not be modified. Using the previous example, <code>m2</code> would simply rename the method but keep its parameters and return type, <code>:EInt</code> would just change the type, and <code>m()</code> would keep the same name and return type but remove all the parameters. When specifying parameters, they must be separated by a comma (<code>,</code>). The type of a parameter is optional; if specified, it can be separated from the name by a colon (<code>:</code>), although this is not required.</li><li><strong>Direct Edit on EReferences</strong>: the label of an EReference indicates its name, cardinality and whether it is derived or not. For example: <code>[0..*] /ref</code> denotes a derived reference named <code>ref</code> which can point to any number of elements (including zero). When editing the label, it is possible to specify only the name and derived attribute (e.g. <code>renamedRef</code>), only the cardinality (e.g. <code lang="1..1">@) or both (e.g. @[0..1] ref2</code>). Three special strings are also support to make some common operations quicker:<ul><li>the edit strings <code>0</code> and <code>1</code> only changes the lower bound of the cardinality of the reference, to 0 or 1;</li><li>the edit string <code>*</code> only changes the upper bound of the cardinality of the reference, to -1 (meaning «unbounded»).</li></ul></li></ul><p>These direct edit features are provided as convenience for common tasks. For more complex customization of the other properties of an element, you can always access all their properties in the <i>Semantic</i> section of the <i>Properties</i> view when the element is selected.</p><h4 id="design.entities.blank">Support for unsynchronized Entities diagrams.</h4><p>By default, Entities diagrams are in <strong>synchronized</strong> mode, which means the graphical elements visible on the diagram always include all the elements in the corresponding package. Sometimes you want a diagram to show only a subset of these elements, for example when documenting a particular aspect of the model while ignoring the rest. In addition to explicitly hiding some elements in the diagram, it is also possible to switch the diagram in <strong>unsynchronized</strong> mode from the context menu on the diagram’s background. In this mode, it becomes possible to remove the graphical representations of some of the model elements without affecting the underlying model by using the <i>Delete from diagram</i> action. Be aware that if you have an existing diagram in <i>unsynchronized</i> mode and you add new elements in the model from outside this diagram (from another diagram or table for example), the new elements will not appear automatically on the unsynchronized diagram.</p><h3 id="entities.classes">The Classes Table Editor</h3><p>This representation provides a tabular editor for all the classes in an Ecore model and their structural features (attributes and references):</p><p><img border="0" src="images/example_design_classes.png"/></p><p>The left column shows the list of classes and their structural features in the current package in a tree. If the package contains sub-packages, they are also shown with their content, recursively.</p><p>The <i>Name</i> column can be used to edit the name of a package, class or feature. To see and edit other properties of an element, simply select the corresponding line and use the <i>Properties</i> view to access all the properties of the element. </p><h2 id="archetype">The Archetype Viewpoint</h2><p>When the <i>Archetype</i> viewpoint is enabled, a new optional layer named <i>Archetypes</i> is available in the main <i>Entities</i> graphical modeler, which adds support for <a href="http://en.wikipedia.org/w/index.php?title=UML_colors&oldid=381749673">modeling in color with archetypes</a>.</p><p>Concretely, when the layer is enabled, four new tools become available in the palette, as shown in the figure below: </p><p><img border="0" src="images/archetypes.png"/></p><p>These tools can be used to create new EClasses with special annotations indicating they represent some particular kind of elements. Each of the four kinds of archetypes supported are represented by a different color. As shown on the figure, the tools can also be used on already existing EClasses to set or change their categorization.</p><p>Inside the model, the archetypes are encoded as EAnnotations added to the EClass, with a source of <code>http://www.eclipse.org/sirius/dnc/archetype</code> and a single details entry. The key of the entry is <code>archetype</code>, and the value can be one of (descriptions taken from the Wikipedia page):</p><ul><li><code>MomentInterval</code>: represents a moment or interval of time; displayed in pink.</li><li><code>Description</code>: a catalog-like description which classifies or ‹labels› an object; displayed in blue.</li><li><code>Role</code>: represents a way of participating in an activity (by either a person, place, or thing); displayed in yellow.</li><li><code>Thing</code>: represents something tangible, uniquely identifiable; displayed in green.</li></ul><h2 id="documentation">The Documentation Viewpoint</h2><p>When the <i>Documentation</i> viewpoint is enabled, a new optional layer named <i>Documentation</i> is available (and enabled by default). This layer adds two new tools to the palette in the <i>Documentation</i> section:</p><ul><li><i>Doc Annotation</i> can be used to create a note on the diagram in which free-form documentation can be typed. They are represented graphically by green rectangles.</li><li><i>Doc Assignment</i> can be used to assign a documentation note created by <i>Doc Annotation</i> to a class on the diagram. The assignment is represented by a green arrow from the note to the class.</li></ul><p>In addition, the <i>Documentation</i> layer customizes the representation of classes so that classes which do not have any documentation assigned to them are drawn with a bright red border to stand out and be identified easily.</p><p>The figure below illustrates these features:</p><p><img border="0" src="images/documentation_layer.png"/></p><p>Technically, the documentation annotations are stored in a way compatible with EMF’s documentation capabilities: the annotation has a source of <code>http://www.eclipse.org/emf/2002/GenModel</code> and the documentation string itself is stored in a details entry with key <code>documentation</code>.</p><h2 id="quality">The Quality Viewpoint</h2><p>The <i>Quality</i> viewpoint provides three types of diagrams and a new optional layer for the <i>Entities</i> diagram which can be used to assess the quality of a model based on different metrics.</p><h3 id="quality.dependencies">Dependencies Diagram</h3><p><i>Dependencies</i> diagrams can be created on <i>EPackages</i>. They show the target package itself and all the other packages it depends on through its contents. For example, if an EClass in the target package has a reference whose type is defined in another one, an edge will be visible between the packages to represent their dependency.</p><p>The figure below shows an <i>Entities</i> diagram on a sample Ecore model on the left, and the corresponding <i>Dependencies</i> diagram for the <code>bank</code> package on the right. The package which is analyzed is shown in yellow, and the other packages (its dependencies) in orange. A red arrow from package to another indicates a dependency.</p><p><img border="0" src="images/dependencies.png"/></p><p>The optional layer <i>Content</i> (disabled by default) can be enable to show the classifiers which are defined inside each of the packages.</p><h3 id="quality.relations">Relations Diagram</h3><p><i>Relations</i> diagrams are similar in intent to <i>Dependencies</i> diagram, but on the level of EClasses instead of packages. They are created on an EClass (say <i>A</i>), which is represented on the diagram. Two optional layers (disabled by default) are available to make visible on the diagram either the classes on which <i>A</i> depends or which depend on <i>A</i>, with connections representing the direction of the dependency. A class <i>A</i> is considered depending on another class <i>B</i> either if <i>B</i> is a direct supertype of <i>A</i> or if <i>A</i> has an EReference of type <i>B</i>.</p><p>The figure below illustrates a <i>Relations</i> diagram on the class <i>User</i> defined in the sample model already used for the <i>Dependencies</i> diagram. Here, both optional layers are enabled, so we see both classes which depend on <i>User</i> (here <i>Account</i>) and classes on which <i>User</i> depends (<i>Date</i> and <i>Address</i>).</p><p><img border="0" src="images/relations.png"/></p><h3 id="quality.hierarchy">Hierarchy Diagram</h3><p><i>Hierarchy</i> diagrams can be created on an EClass, and represent both the class itself and all its direct and indirect super-types. </p><p>The figure below shows a sample metamodel for a filesystem on the left, and on the right a <i>Hierarchy</i> diagram on the <code>Spreadsheet</code> class (shown in bold), which show all its direct and indirect super-types.</p><p><img border="0" src="images/hierarchy.png"/></p><h3 id="quality.size">Size Layer</h3><p>The <i>Quality</i> viewpoint also extends the <i>Entities</i> diagram with a new optional layer named <i>Size</i> (disabled by default). When enabled, it changes the color of the EClasses on the diagram to shades of green, based on the size of the EClass (i.e. the number of features it contains). The more features a class contains, the more complex it is considered and the darker it is represented. </p><p>The figure below shows a subset of the filestystem metamodel used above, with the <i>Size</i> layer enabled:</p><p><img border="0" src="images/size.png"/></p><p>We can see that the classes have a different color depending on how much features they contain. Small classes are bright green, classes with a few features are a darker shade of green, and very big classes which probably define too many features are shown in red.</p><h2 id="review">The Review Viewpoint</h2><p>The <i>Review</i> viewpoint provides a table which can be used to review and document a model.</p><h3 id="review.documentation">The Documentation Table</h3><p>The <i>Documentation</i> table (created on an <i>EPackage</i>) can be used to review and edit the documentation annotations associated with the EClasses of a package and their features. See the example below:</p><p><img border="0" src="images/documentation_table.png"/></p><h2 id="generation">The Generation Viewpoint</h2><p>The <i>Generation</i> viewpoint provides a table to edit the generation configuration associated to an Ecore model. Note that it can be enabled only if the <code>genmodel</code> associated to the <code>ecore</code> resource is loaded as a semantic resource inside the session.</p><h3 id="generation.genpackage">The GenPackage Attributes Table</h3><p>This table is used to edit some of the generation configuration associated to an Ecore model. To use it, you must have initialized the <code>genmodel</code> corresponding to the Ecore model and added it as a semantic resource in the session. Then you can create a new <i>GenPackage Attributes</i> table on the top-level <i>GenPackage</i> element.</p><p>For each structural feature of each type in a package (and its sub-packages), the table shows two columns, «Category» and «Description», which correspond to the category in which to put the feature’s property descriptor, and the description to use for that descriptor. These informations are stored in the <code>genmodel</code> and used by EMF to organize the properties of model elements into logical categories in the property sheets it generates.</p><p><img border="0" src="images/genpackage_table.png"/></p></body></html>
\ No newline at end of file |