Skip to Content
Last modified by Richard Kreissig on 2023/09/14 10:13
From version 22.1
edited by msp
on 2013/08/01 11:13
Change comment: There is no comment for this version
To version 25.1
edited by msp
on 2014/03/05 13:22
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -1,17 +1,18 @@
1 1  {{panel title="Project Overview" borderStyle="dashed"}}
2 2  Responsible:
3 3  
4 -* {{mention reference="XWiki.msp" style="FULL_NAME" anchor="XWiki-msp-uygHH"/}}
4 +* {{mention reference="XWiki.msp" style="FULL_NAME" anchor="XWiki-msp-Rqwxy"/}}
5 5  
6 6  Related Publications:
7 7  
8 -* (% style="color: rgb(0, 0, 0); color: rgb(0, 0, 0)" %)Miro Spönemann, Hauke Fuhrmann, and Reinhard von Hanxleden. //Automatic Layout of Data Flow Diagrams in KIELER and Ptolemy II//. Technical Report 0914, Christian-Albrechts-Universität zu Kiel, Department of Computer Science, 2009. ((% style="color: rgb(0,0,0);" %)[[pdf>>url:http://rtsys.informatik.uni-kiel.de/~~biblio/downloads/papers/report-0914.pdf||shape="rect"]](% style="color: rgb(0, 0, 0); color: rgb(0, 0, 0)" %) / (% style="color: rgb(0,0,0);" %)[[bib>>url:http://rtsys.informatik.uni-kiel.de/~~biblio/cgi-bin/bibcgi.cgi?key=SpoenemannFvH09||shape="rect"]])
9 -* (% style="color: rgb(0,0,0);" %)Hauke Fuhrmann, Miro Spönemann, Michael Matzen, and Reinhard von Hanxleden. Automatic layout and structure-based editing of UML diagrams. In (% class="cmti-10" %)//Proceedings of the 1st Workshop on Model Based//(%%)// (% class="cmti-10" %)Engineering for Embedded Systems Design (M-BED'10)//(%%), Dresden, 2010. ((%%)[[pdf>>url:http://rtsys.informatik.uni-kiel.de/~~biblio/downloads/papers/mbed10.pdf||shape="rect"]] (% style="color: rgb(0,0,0);" %)/ (%%)[[bib>>url:http://rtsys.informatik.uni-kiel.de/~~biblio/cgi-bin/bibcgi.cgi?key=FuhrmannSM+10||shape="rect"]])
10 -* (% style="color: rgb(0,0,0);" %)Christian Schneider, Miro Spönemann, and Reinhard von Hanxleden. Transient view generation in Eclipse. In (% class="cmti-10" %)//Proceedings of the First//(%%)// (% class="cmti-10" %)Workshop on Academics Modeling with Eclipse//(%%), Kgs. Lyngby, Denmark, 2012. ((%%)[[pdf>>url:http://rtsys.informatik.uni-kiel.de/~~biblio/downloads/papers/acme12.pdf||shape="rect"]] /(% style="color: rgb(0,0,0);" %) (%%)[[bib>>url:http://rtsys.informatik.uni-kiel.de/~~biblio/cgi-bin/bibcgi.cgi?key=SchneiderSvH12a||shape="rect"]])
8 +* Miro Spönemann, Hauke Fuhrmann, and Reinhard von Hanxleden. //Automatic Layout of Data Flow Diagrams in KIELER and Ptolemy II//. Technical Report 0914, Christian-Albrechts-Universität zu Kiel, Department of Computer Science, 2009. ([[pdf>>url:http://rtsys.informatik.uni-kiel.de/~~biblio/downloads/papers/report-0914.pdf||shape="rect"]] / [[bib>>url:http://rtsys.informatik.uni-kiel.de/~~biblio/cgi-bin/bibcgi.cgi?key=SpoenemannFvH09||shape="rect"]])
9 +* Hauke Fuhrmann, Miro Spönemann, Michael Matzen, and Reinhard von Hanxleden. Automatic layout and structure-based editing of UML diagrams. In //Proceedings of the 1st Workshop on Model Based Engineering for Embedded Systems Design// (M-BED'10), Dresden, 2010. ([[pdf>>url:http://rtsys.informatik.uni-kiel.de/~~biblio/downloads/papers/mbed10.pdf||shape="rect"]] / [[bib>>url:http://rtsys.informatik.uni-kiel.de/~~biblio/cgi-bin/bibcgi.cgi?key=FuhrmannSM+10||shape="rect"]])
10 +* Christian Schneider, Miro Spönemann, and Reinhard von Hanxleden. Transient view generation in Eclipse. In //Proceedings of the First Workshop on Academics Modeling with Eclipse//, Kgs. Lyngby, Denmark, 2012. ([[pdf>>url:http://rtsys.informatik.uni-kiel.de/~~biblio/downloads/papers/acme12.pdf||shape="rect"]] / [[bib>>url:http://rtsys.informatik.uni-kiel.de/~~biblio/cgi-bin/bibcgi.cgi?key=SchneiderSvH12a||shape="rect"]])
11 +* Miro Spönemann, Christoph Daniel Schulze, Christian Motika, Christian Schneider, and Reinhard von Hanxleden. KIELER: Building on Automatic Layout for Pragmatics-Aware Modeling (Showpiece). In //Proceedings of the IEEE Symposium on Visual Languages and Human-Centric Computing// (VL/HCC’13), San Jose, CA, USA, 15–19 September 2013.
11 11  
12 12  Related Theses:
13 13  
14 -* (% style="color: rgb(0,0,0);" %)Björn Duderstadt, //Evolutionary Meta Layout for KIELER//, May 2011 ((%%)[[pdf>>url:http://rtsys.informatik.uni-kiel.de/~~biblio/downloads/theses/bdu-st.pdf||style="text-decoration: none;" shape="rect" class="extTarget"]](% style="color: rgb(0,0,0);" %))
15 +* Björn Duderstadt, //Evolutionary Meta Layout for KIELER//, May 2011 ([[pdf>>url:http://rtsys.informatik.uni-kiel.de/~~biblio/downloads/theses/bdu-st.pdf||shape="rect" class="extTarget"]])
15 15  {{/panel}}
16 16  
17 17  
... ... @@ -18,11 +18,13 @@
18 18  
19 19  ===== Contents =====
20 20  
22 +
23 +
21 21  {{toc maxLevel="2"/}}
22 22  
23 23  = Getting Started[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/kieler/wiki/Projects/KIML#GettingStarted||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] =
24 24  
25 -This subproject deals with the automatic layout of graph-based models. KIML offers interfaces to connect layout algorithms to diagram editors and viewers. The focus is on flexible configurability, which is a crucial issue for creating good layouts for different graphical languages and in different circumstances. The term //meta layout// relates to the idea of specifying the layout of a diagram on an abstract level, while //concrete layout// information is calculated by layout algorithms.
28 +This subproject deals with the automatic layout of graph-based models. KIML offers interfaces to connect layout algorithms to diagram editors and viewers. The focus is on flexible configurability, which is a crucial issue for creating good layouts for different graphical languages and in different circumstances. The term //meta layout// relates to the idea of specifying the layout of a diagram on an abstract level, while //concrete layout// information is computed by layout algorithms.
26 26  
27 27  In order to use KIML with your own GMF-based editor, you need to do the following steps:
28 28  
... ... @@ -30,6 +30,8 @@
30 30  1*. It includes the Java-based layout algorithms developed in the [[KLay project>>doc:Layout Algorithms (KLay)]].
31 31  1. Open a diagram and press the layout button [[image:attach:kieler-arrange.gif]] or use the shortcut Ctrl+R L.
32 32  
36 +Similarly, the "//KIELER Layout for Graphiti//" feature provides the KIML interface to Graphiti-based editors.
37 +
33 33  === Terminology ===
34 34  
35 35  //**Layout Graph**//
... ... @@ -50,12 +50,16 @@
50 50  
51 51  **//Layout Configurator//**
52 52  
53 -* A component that is responsible for retrieving specific layout option values for each model element.
58 +* A component that is responsible for retrieving specific layout option values for model elements.
54 54  
55 55  **//Layout Data//**
56 56  
57 57  * Concrete layout data (position and size) and abstract layout data (layout options) attached to elements of the layout graph using the [[KLayoutData>>doc:KLayoutData Meta Model]] model.
58 58  
64 +//**Layout Meta Data**//
65 +
66 +* Meta information on layout algorithms, layout options, etc. gathered through extension points.
67 +
59 59  **//Layout Type//**
60 60  
61 61  * Classification of layout algorithms depending on their basic approach (e.g. layered, force, etc.).
... ... @@ -68,9 +68,13 @@
68 68  
69 69  * The central interface for connecting diagram editors with layout algorithms.
70 70  
80 +//**Diagram Layout Engine**//
81 +
82 +* A singleton class for invoking layout algorithms on diagram viewers and editors.
83 +
71 71  = User Interface[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/kieler/wiki/Projects/KIML#UserInterface||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] =
72 72  
73 -The main user interface element of KIML is the command to layout the current diagram. This command is availabe in the main KIELER menu, in the toolbar ([[image:attach:kieler-arrange.gif]]), or using the Ctrl+R L shortcut. Additionally, an entry in the context menu allows to layout only a selected part of the diagram.
86 +The main user interface element of KIML is the command to layout the current diagram. This command is available in the toolbar ([[image:attach:kieler-arrange.gif]]) or using the Ctrl+R L shortcut. Additionally, an entry in the context menu allows to layout only a selected part of the diagram.
74 74  
75 75  == Layout View[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/kieler/wiki/Projects/KIML#LayoutView||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ==
76 76  
... ... @@ -78,12 +78,14 @@
78 78  
79 79  The //Layout// view allows flexible customization of layout options for the selected objects in the diagram. If no object is selected, the view shows the options for the top-level container of the diagram. Options are stored persistently in the notation model of the diagram, so that they are still available after the next Eclipse restart. Of course this requires the diagram to be saved after an option was changed.
80 80  
81 -The options are grouped according to the function of the selected objects. The group //Nodes// (respectively //Edges//, //Ports//, or //Labels//) contains options related to the object itself, such as its size or priority, while the group //Parents// contains options for the elements contained in the selected objects, such as the applied layout algorithm or the spacing between elements. Which layout options are displayed depends on the types of selected objects and the active layout algorithm, since each algorithm supports only a subset of the available options. Furthermore, some options are only visible if the //Show Advanced Properties// button in the view toolbar is activated. The group types can be hidden using the //Show Categories// button.
94 +The options can be grouped according to the function of the selected object. The groups //Node,// //Edge//, //Port//, and //Label// contain options related to the object itself, such as its size or priority, while the groups //Graph// and// Subgraph// contain options for the elements contained in the selected object, such as the applied layout algorithm or the spacing between elements. Which layout options are displayed depends on the types of selected objects and the active layout algorithm, since each algorithm supports only a subset of the available options. Furthermore, some options are only visible if the //Show Advanced Properties// button in the view toolbar is activated. The group types can be hidden using the //Show Categories// button.
82 82  
83 83  An option can be changed by selecting or entering a new value in the corresponding cell of the //Value// column. The most important option is //Layout Algorithm//, which is used to determine the layout algorithm for the contents of the selected element. Here either a specific layout algorithm or a layout type can be chosen; in the latter case, the most suitable layout algorithm of the given type is taken. By changing the active layout algorithm, the content of the layout view is updated to display only those options that are supported by the new layout algorithm.
84 84  
85 85  Selecting //Restore Default Value// in the context menu or the view toolbar removes any value for the currently selected option that is stored in the current model file, thus resetting the option to its default value. The view menu has an entry //Remove all Layout Options// which resets all options of the current model by removing persistent data in the model file.
86 86  
100 +The standard layout options defined in KIML are documented in [[doc:KIML Layout Options]]. However, layout algorithms may define additional layout options.
101 +
87 87  [[image:attach:context_menu.png]]
88 88  
89 89  The context menu for a specific layout option has different alternatives to set the currently active value as default value: //Set as Default for this Diagram// changes the open model file so that the same value is applied to all similar objects of that model. //Set as Default for ... in this Context// applies the value to all similar objects that are displayed with the same diagram editor (the option is linked to the //edit part// class of the selected object). Choosing //Set as Default for all ...// links the option value with the domain model element or diagram type of the selected object (see the context menu depicted above). These four alternatives have different priorities: if present, the default value for the current diagram is taken first, then the default value for the edit part is checked, then the default value for the domain model element, and then the default value for the diagram type.
... ... @@ -92,61 +92,22 @@
92 92  
93 93  == Preference Page[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/kieler/wiki/Projects/KIML#PreferencePage||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ==
94 94  
95 -[[image:attach:preferences.png]]
110 +[[image:attach:preference_page.png]]
96 96  
97 -If //Set routing style of all edges to oblique// is active, all routing styles and smoothness settings of edges are removed when automatic layout is performed. Since most layouters compute the routing of edges as part of their algorithm, these styles usually do not yield the expected results.
112 +//Animate layout// enables animation of the transition of the old layout to the new layout whenever the layout is recomputed.
98 98  
99 -The //Default Layout Option Values// table is used to manage the default setting for layout options, which can also be modified with the context menu of the layout view (see above). All user-defined settings are displayed here, and the buttons on the right of the table serve to create, edit, and remove entries. The //Type// column shows the type of element the option is linked with: either //edit part//,//model element//, or //diagram type//. The //Element// column shows the class name for options that relate to edit parts or domain model elements, and the diagram type name for options that relate to diagram types. //Option// is the name of the layout option, and //Value// is the currently set value of the option.
114 +Automatic zooming can be enabled with //Zoom to fit after layout//.
100 100  
101 -Creating a new entry requires the selection of the type of related element and entering its class name or identifier. Class names of edit parts and domain model elements can be explored using the information button of the layout view, while diagram type identifiers can be selected with the //Browse// button. After that, a layout option has to be selected from the list using the corresponding //Browse //button. Hitting //OK// creates an entry, and its value can then be set using the //Edit// button.
116 +If //Show layout progress// is active, a progress dialog is shown during the computation of layouts.
102 102  
103 -= Special Layout Options =
118 +If //Oblique edge routing// is active, all routing styles and smoothness settings of edges are removed when automatic layout is performed on GMF editors. Since most layouters compute the routing of edges as part of their algorithm, these styles usually do not yield the expected results.
104 104  
105 -While most layout options are used to affect how the active layout algorithm computes concrete coordinates for the graph elements, there are some layout options that have a special role in KIML.
120 +The option //Debug graph output// is used for debugging, as the name suggests. It writes the layout graph of each layout computation to a file in the current user's home directory.
106 106  
107 -== Layout Algorithm ==
122 +The //Default Layout Option Values// table is used to manage the default setting for layout options, which can also be modified with the context menu of the layout view (see above). All user-defined settings are displayed here, and the buttons on the right of the table serve to create, edit, and remove entries. The //Type// column shows the type of element the option is linked with: either //Diagram Part//, //Model Element//, or //Diagram Type//. The //Element// column shows the class name for options that relate to diagram parts (i.e. edit parts) or domain model elements, and the diagram type name for options that relate to diagram types. //Option// is the name of the layout option, and //Value// is the currently set value of the option.
108 108  
109 -The option with identifier {{code language="none"}}de.cau.cs.kieler.algorithm{{/code}} specifies which layout algorithm to use for the content of a composite node. The value can be either the identifier of a layout algorithm or the identifier of a layout type. In the latter case the algorithm with highest priority of that type is applied.
124 +Creating a new entry requires the selection of the type of related element and entering its class name or identifier. Class names of diagram parts and domain model elements can be explored using the information button of the layout view, while diagram type identifiers can be selected with the //Browse// button. After that, a layout option has to be selected from the list using the corresponding //Browse //button. Hitting //OK// creates an entry, and its value can then be set using the //Edit// button.
110 110  
111 -The following layout types are predefined:
112 -
113 -* **Layered** - The layer-based method emphasizes the direction of edges by pointing as many edges as possible into the same direction. The nodes are arranged in layers and then reordered such that the number of edge crossings is minimized. Afterwards, concrete coordinates are computed for the nodes and edge bend points.
114 -* **Orthogonal** - Orthogonal methods follow the "topology-shape-metrics" approach, which first applies a planarization technique, resulting in a planar representation of the graph, then compute an orthogonal shape, and finally determine concrete coordinates for nodes and edge bend points by applying a compaction method.
115 -* **Force** - Layout algorithms that follow physical analogies by simulating a system of attractive and repulsive forces.
116 -* **Circular** - Circular layout algorithms emphasize biconnected components of a graph by arranging them in circles. This is useful if a drawing is desired where such components are clearly grouped, or where cycles are shown as prominent properties of the graph.
117 -* **Tree** - Specialized layout methods for trees, i.e. acyclic graphs. The regular structure of graphs that have no undirected cycles can be emphasized using an algorithm of this type.
118 -
119 -=== Available Algorithms and Libraries ===
120 -
121 -* **The [[KLay Project>>doc:Layout Algorithms (KLay)]]** - Java implementations of standard layout approaches, augmented with special processing of graph features such as ports and edge labels.
122 -* **Randomizer** - Distributes the nodes randomly; not very useful, but it can show how important a good layout is for understanding a graph.
123 -* (((
124 -**Box Layout** - Ignores edges, places all nodes in rows. Can be used to layout collections of unconnected boxes, such as Statechart regions.
125 -)))
126 -* **Fixed Layout** - Does not compute a new layout, but leaves all nodes and edges where they are. If the Position and Bend Points options are set for the elements of the graph, the pre-defined layout is applied.
127 -* **OGDF** ((% style="color: rgb(0, 0, 0); color: rgb(0, 0, 0); color: rgb(0, 0, 0); color: rgb(0, 0, 0)" %)[[www.ogdf.net>>url:http://www.ogdf.net/||shape="rect"]](%%)) - A self-contained C++ class library for the automatic layout of diagrams. The version that is shipped with KIELER is compiled as an executable that reads files in OGML format and outputs the computed concrete layout.
128 -* **Graphviz** ([[www.graphviz.org>>url:http://www.graphviz.org/||shape="rect"]]) - An open source graph visualization tool with several graph layout programs, web and interactive graphical interfaces, auxiliary tools, libraries, and language bindings. Graphviz needs to be installed separately in order to be used within KIELER, since it is called in a separate process using the DOT language for communication.
129 -
130 -== Diagram Type ==
131 -
132 -Diagram types are used to classify graphical diagrams for setting default layout option values for a set of similar diagrams. The diagram type of an element is specified with the layout option {{code language="none"}}de.cau.cs.kieler.diagramType{{/code}}. Layout algorithms can declare which diagram types they support well, and give a priority value for each supported type. KIML decides at runtime which layout algorithm has the highest priority for a given diagram, so that the most suitable algorithm is always used. Usual values for such priorities are between 1 and 10, where the highest value should only be assigned if the algorithm is especially designed for diagrams of the respective type, or if it has proven to be very adequate for them. Lower values should be given if the algorithm is able to draw the diagrams correctly, but with lower quality of the resulting layout.
133 -
134 -The following diagram types are predefined:
135 -
136 -* **General** - This type is automatically assigned to all diagrams for which no specific type is declared. A layout algorithm that has the highest priority on the //General// diagram type is taken as the default algorithm when no further information on a diagram is available to KIML.
137 -* **State Machine** - All kinds of state machines, automata, and activity diagrams. Examples: [[doc:SCCharts SyncCharts]], UML Activity diagrams.
138 -* **Data Flow Diagram** - Actor-oriented diagrams, where connections are mostly done between //ports// of nodes. These diagrams can only be handled properly by very special layout algorithms, such as those developed in the [[KLay project>>doc:Layout Algorithms (KLay)]].
139 -* **Class Diagram** - Class diagrams such as Ecore diagrams for the [[EMF>>url:http://www.eclipse.org/modeling/emf/||shape="rect"]] or UML Class diagrams.
140 -* **Use Case Diagram** - Use case diagrams as defined by the UML.
141 -* **Unconnected Boxes** - Sets of nodes that have no connections and are treated as resizable boxes. This is related to mathematical [[packing problems>>url:http://en.wikipedia.org/wiki/Packing_problem||shape="rect"]]. Example: Regions in [[doc:SCCharts SyncCharts]].\\
142 -
143 -== Other Options ==
144 -
145 -* **Layout Hierarchy** ({{code language="none"}}de.cau.cs.kieler.layoutHierarchy{{/code}}) - If this option is supported and active, the layout algorithm is requested to process the full hierarchy contained in the input node. This means that instead of executing another algorithm on each hierarchy level, all levels are arranged in a single algorithm execution.
146 -* **Hypernode** ({{code language="none"}}de.cau.cs.kieler.hypernode{{/code}}) - A node that is marked as hypernode has a special role in the graph structure, since all its incident edges are treated as parts of the same [[hyperedge>>url:http://en.wikipedia.org/wiki/Hypergraph||shape="rect"]]. Example: relation vertices in [[Ptolemy>>url:http://ptolemy.eecs.berkeley.edu/||shape="rect"]] models.
147 -* **Comment Box** ({{code language="none"}}de.cau.cs.kieler.commentBox{{/code}}) - A node that is marked as comment box is treated as a label that needs to be placed somewhere. This is different to normal node labels, which are usually regarded as fixed.
148 -* **No Layout** ({{code language="none"}}de.cau.cs.kieler.noLayout{{/code}}) - Elements that are marked with this option are excluded from layout. This is used to identify diagram objects that should not be regarded as graph elements.
149 -
150 150  = Internal Structure[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/kieler/wiki/Projects/KIML#InternalStructure||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] =
151 151  
152 152  The primary public interface of KIML is the [[DiagramLayoutEngine>>url:http://rtsys.informatik.uni-kiel.de/fisheye/browse/kieler/plugins/de.cau.cs.kieler.kiml.ui/src/de/cau/cs/kieler/kiml/ui/diagram/DiagramLayoutEngine.java||shape="rect"]], which is responsible for analyzing diagrams, creating a [[KGraph>>doc:KGraph Meta Model]] structure, configuring and executing the layout algorithms, and writing new position information back to the diagram. The interaction with the diagram editor or viewer is handled by [[IDiagramLayoutManager>>url:http://rtsys.informatik.uni-kiel.de/fisheye/browse/kieler/plugins/de.cau.cs.kieler.kiml.ui/src/de/cau/cs/kieler/kiml/ui/diagram/IDiagramLayoutManager.java||shape="rect"]] implementations.
Confluence.Code.ConfluencePageClass[0]
Id
... ... @@ -1,1 +1,1 @@
1 -7700942
1 +9469966
URL
... ... @@ -1,1 +1,1 @@
1 -https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/7700942/Infrastructure for Meta Layout (KIML)
1 +https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/9469966/Infrastructure for Meta Layout (KIML)