Yakindu Statechart Tools

Today, the Luna release train arrived at Yakindu Statechart Tools Station! Apart from Luna compatibility, the new release version 2.3.0 provides some great new features. If you are new to statecharts and Yakindu Statechart Tools you should take a ... [More] look at our Getting Started Tutorial.Installation You can download Yakindu Statechart Tools 2.3.0 for Luna either from our dowload page or install it into your existing Eclipse installation via our update site:http://updates.yakindu.org/sct/luna/releaseNew and Noteworthy Version 2.3.0 is shipped with a new C Code Generator. Of course, all advanced statechart features like history states and parallel regions are supported. Furthermore, we implemented some features requested via our user group, for example a name wrangler for c function names and fixed a bunch of bugs. Of course, all the other cool new Luna features like the split editor are working with the new release, even the dark theme is. ;-)Another interesting project worth to mention is the Statechart Tools Arduino Integration. Marco wrote a great article on how to run the generated statechart tools code on an Arduino board. What's next?  Based on the new GMF Compare feature (thanks for this, great job!) we started to create a diff/merge viewer for statechart diagrams. Since our viewer's merge functionality is not stable yet, we decided to publish it with the next release. However, if you want to test it, you can checkout the plugin from our svn repository. Do not forget to send us some feedback! Preview of the new SCT Diff/Merge viewerWe hope you like the new Statechart Tools release, if you have any questions do not hesitate to contact us via our user group! [Less]

Although GMF (Graphical Modeling Framework) editors are an endangered species and future editors will be developed with JavaFX there is still a bunch of GMF editors out there. And most of them have something in common: a lack of usability. The good ... [More] news are that some usability flaws are easy to fix. In Yakindu Statechart Tools we spend a lot of time in improving the usability of our GMF Runtime based editor. Here is a random selection of 5 usability flaws in GMF and how we fixed them.The following code snippets are just examples how a solution could look like. Most of the  snippets are still experimental and developed for specific use cases and should not be used as is! 1. Remove dithering connection anchors Everyone who ever worked with a GMF based editor knows this annoying default behavior. You spend a significant amount of time arranging the diagrams connections to produce a nice-looking diagram. When everything looks pretty nice, you enlarge a node  - and all the connection routing work was only a waste of time.... To fix this, you can use an AdjustIdentityAnchorCommand.java that can be chained to a SetBoundsCommand and recalculates the IdentityAnchor position based on the resize delta. Create a customized LayoutEditPolicy and install it on the container EditPart as shown below:installEditPolicy(EditPolicy.LAYOUT_ROLE, new XYLayoutEditPolicy() {  @Override  protected Command getResizeChildrenCommand(ChangeBoundsRequest request) {    CompoundCommand result = new CompoundCommand();    result.add(super.getResizeChildrenCommand(request));    AdjustIdentityAnchorCommand command = new         AdjustIdentityAnchorCommand(TransactionUtil         .getEditingDomain(resolveSemanticElement()), request);    result.add(new ICommandProxy(command));    return result;  }}); 2. Remove scrollable compartments and autoresize container hierachyWorking with GMF compartments is no fun. The compartment scrollbars look pretty ugly and diagram elements are hidden in non visible areas. Sometimes, edges are clipped because a node is not fully visible and you do not even know that the edge exists. A better approach is to always show all elements in the compartment. If your diagram gets too large, you should consider using sub diagrams instead of scrollable compartments. When adding new nodes to a compartment, the user has to enlarge the whole container hierachy by hand. The EnlargeContainerEditPolicy.java auto-resizes the container hierachy if more space is required. Every note that is in the way is moved to prevent overlapping nodes. It has to be installed for every EditPart in the compartment:installEditPolicy(EnlargeContainerEditPolicy.ROLE, new  EnlargeContainerEditPolicy());  3. Add a preferred size selection handleThis EditPolicy adds a new handle to the selection handles. If this handle is pressed, the selected node updates its size to the preferred size. The preferred size is the minimum size of the node, where all node children are visible. When modeling with the UML Tool Magicdraw I found this preferred size handle to be very useful, so I added it to my GMF based editors as well. To add the preferred size selection handle to a node, install the PreferredSizeHandlerEditPolicy.java to the nodes EditPart for the PRIMARY_DRAG_ROLE. Check the Type Hierachy carefully!installEditPolicy(EditPolicy.PRIMARY_DRAG_ROLE, new  PreferredSizeHandlerEditPolicy()); 4. Highlight clickable areas and open direct editing on double click It is a good idea to indicate clickable areas with a highlighted border, so the user immediately gets  feedback where he can open an in-diagram editor. These editors should open on a simple double-click, no matter which node is currently selected in the diagram. With GMF defaults it is only possible to open the direct editor when a node is selected.To highlight clickable areas within the Diagram there is a (really simple) HighlightingWrappingLabel.java that shows a border on mouse hover to indicate a clickable area. To open the direct editor on double click use the DoubleClickDirectEditDragTracker.java .This DragTracker generates DirectEditRequests on double clicks and replaces the existing DragTracker of the EditPart like this:@Overridepublic DragTracker getDragTracker(final Request request) {  if (request instanceof SelectionRequest    && ((SelectionRequest) request).getLastButtonPressed() == 3)    return null;  IDoubleClickCallback callback = new IDoubleClickCallback() {    public void handleDoubleClick(int btn) {      performDirectEditRequest(request);    }  };  return new DoubleClickDirectEditDragTracker(this, getTopGraphicEditPart(),       callback);}5. Add rich text editing support to direct editingIf you use direct editing only to set names for nodes, the default GMF Direct Editing behavior is sufficient. If you have a more formal language, for example an expression language, you should consider using Xtext to generate an editor for your grammar and integrate it into your GMF editor to support syntax coloring, validation and cross referencing.For the technical details have a look at Xtext integration into GMF ! [Less]

Although GMF (Graphical Modeling Framework) editors are an endangered species and future editors will be developed with JavaFX there is still a bunch of GMF editors out there. And most of them have something in common: a lack of usability. The good ... [More] news are that some usability flaws are easy to fix. In Yakindu Statechart Tools we spend a lot of time in improving the usability of our GMF Runtime based editor. Here is a random selection of 5 usability flaws in GMF and how we fixed them.The following code snippets are just examples how a solution could look like. Most of the  snippets are still experimental and developed for specific use cases and should not be used as is! 1. Remove dithering connection anchors Everyone who ever worked with a GMF based editor knows this annoying default behavior. You spend a significant amount of time arranging the diagrams connections to produce a nice-looking diagram. When everything looks pretty nice, you enlarge a node  - and all the connection routing work was only a waste of time.... To fix this, you can use an AdjustIdentityAnchorCommand.java that can be chained to a SetBoundsCommand and recalculates the IdentityAnchor position based on the resize delta. Create a customized LayoutEditPolicy and install it on the container EditPart as shown below:installEditPolicy(EditPolicy.LAYOUT_ROLE, new XYLayoutEditPolicy() {  @Override  protected Command getResizeChildrenCommand(ChangeBoundsRequest request) {    CompoundCommand result = new CompoundCommand();    result.add(super.getResizeChildrenCommand(request));    AdjustIdentityAnchorCommand command = new         AdjustIdentityAnchorCommand(TransactionUtil         .getEditingDomain(resolveSemanticElement()), request);    result.add(new ICommandProxy(command));    return result;  }}); 2. Remove scrollable compartments and autoresize container hierachyWorking with GMF compartments is no fun. The compartment scrollbars look pretty ugly and diagram elements are hidden in non visible areas. Sometimes, edges are clipped because a node is not fully visible and you do not even know that the edge exists. A better approach is to always show all elements in the compartment. If your diagram gets too large, you should consider using sub diagrams instead of scrollable compartments. When adding new nodes to a compartment, the user has to enlarge the whole container hierachy by hand. The EnlargeContainerEditPolicy.java auto-resizes the container hierachy if more space is required. Every note that is in the way is moved to prevent overlapping nodes. It has to be installed for every EditPart in the compartment:installEditPolicy(EnlargeContainerEditPolicy.ROLE, new  EnlargeContainerEditPolicy());  3. Add a preferred size selection handleThis EditPolicy adds a new handle to the selection handles. If this handle is pressed, the selected node updates its size to the preferred size. The preferred size is the minimum size of the node, where all node children are visible. When modeling with the UML Tool Magicdraw I found this preferred size handle to be very useful, so I added it to my GMF based editors as well. To add the preferred size selection handle to a node, install the PreferredSizeHandlerEditPolicy.java to the nodes EditPart for the PRIMARY_DRAG_ROLE. Check the Type Hierachy carefully!installEditPolicy(EditPolicy.PRIMARY_DRAG_ROLE, new  PreferredSizeHandlerEditPolicy()); 4. Highlight clickable areas and open direct editing on double click It is a good idea to indicate clickable areas with a highlighted border, so the user immediately gets  feedback where he can open an in-diagram editor. These editors should open on a simple double-click, no matter which node is currently selected in the diagram. With GMF defaults it is only possible to open the direct editor when a node is selected.To highlight clickable areas within the Diagram there is a (really simple) HighlightingWrappingLabel.java that shows a border on mouse hover to indicate a clickable area. To open the direct editor on double click use the DoubleClickDirectEditDragTracker.java .This DragTracker generates DirectEditRequests on double clicks and replaces the existing DragTracker of the EditPart like this:@Overridepublic DragTracker getDragTracker(final Request request) {  if (request instanceof SelectionRequest    && ((SelectionRequest) request).getLastButtonPressed() == 3)    return null;  IDoubleClickCallback callback = new IDoubleClickCallback() {    public void handleDoubleClick(int btn) {      performDirectEditRequest(request);    }  };  return new DoubleClickDirectEditDragTracker(this, getTopGraphicEditPart(),       callback);}5. Add rich text editing support to direct editingIf you use direct editing only to set names for nodes, the default GMF Direct Editing behavior is sufficient. If you have a more formal language, for example an expression language, you should consider using Xtext to generate an editor for your grammar and integrate it into your GMF editor to support syntax coloring, validation and cross referencing.For the technical details have a look at Xtext integration into GMF ! [Less]

Although GMF (Graphical Modeling Framework) editors are an endangered species and future editors will be developed with JavaFX there is still a bunch of GMF editors out there. And most of them have something in common: a lack of usability. The good ... [More] news are that some usability flaws are easy to fix. In Yakindu Statechart Tools we spend a lot of time in improving the usability of our GMF Runtime based editor. Here is a random selection of 5 usability flaws in GMF and how we fixed them.The following code snippets are just examples how a solution could look like. Most of the  snippets are still experimental and developed for specific use cases and should not be used as is! 1. Remove dithering connection anchors Everyone who ever worked with a GMF based editor knows this annoying default behavior. You spend a significant amount of time arranging the diagrams connections to produce a nice-looking diagram. When everything looks pretty nice, you enlarge a node  - and all the connection routing work was only a waste of time.... To fix this, you can use an AdjustIdentityAnchorCommand.java that can be chained to a SetBoundsCommand and recalculates the IdentityAnchor position based on the resize delta. Create a customized LayoutEditPolicy and install it on the container EditPart as shown below:installEditPolicy(EditPolicy.LAYOUT_ROLE, new XYLayoutEditPolicy() {  @Override  protected Command getResizeChildrenCommand(ChangeBoundsRequest request) {    CompoundCommand result = new CompoundCommand();    result.add(super.getResizeChildrenCommand(request));    AdjustIdentityAnchorCommand command = new         AdjustIdentityAnchorCommand(TransactionUtil         .getEditingDomain(resolveSemanticElement()), request);    result.add(new ICommandProxy(command));    return result;  }}); 2. Remove scrollable compartments and autoresize container hierachyWorking with GMF compartments is no fun. The compartment scrollbars look pretty ugly and diagram elements are hidden in non visible areas. Sometimes, edges are clipped because a node is not fully visible and you do not even know that the edge exists. A better approach is to always show all elements in the compartment. If your diagram gets too large, you should consider using sub diagrams instead of scrollable compartments. When adding new nodes to a compartment, the user has to enlarge the whole container hierachy by hand. The EnlargeContainerEditPolicy.java auto-resizes the container hierachy if more space is required. Every note that is in the way is moved to prevent overlapping nodes. It has to be installed for every EditPart in the compartment:installEditPolicy(EnlargeContainerEditPolicy.ROLE, new  EnlargeContainerEditPolicy());  3. Add a preferred size selection handleThis EditPolicy adds a new handle to the selection handles. If this handle is pressed, the selected node updates its size to the preferred size. The preferred size is the minimum size of the node, where all node children are visible. When modeling with the UML Tool Magicdraw I found this preferred size handle to be very useful, so I added it to my GMF based editors as well. To add the preferred size selection handle to a node, install the PreferredSizeHandlerEditPolicy.java to the nodes EditPart for the PRIMARY_DRAG_ROLE. Check the Type Hierachy carefully!installEditPolicy(EditPolicy.PRIMARY_DRAG_ROLE, new  PreferredSizeHandlerEditPolicy()); 4. Highlight clickable areas and open direct editing on double click It is a good idea to indicate clickable areas with a highlighted border, so the user immediately gets  feedback where he can open an in-diagram editor. These editors should open on a simple double-click, no matter which node is currently selected in the diagram. With GMF defaults it is only possible to open the direct editor when a node is selected.To highlight clickable areas within the Diagram there is a (really simple) HighlightingWrappingLabel.java that shows a border on mouse hover to indicate a clickable area. To open the direct editor on double click use the DoubleClickDirectEditDragTracker.java .This DragTracker generates DirectEditRequests on double clicks and replaces the existing DragTracker of the EditPart like this:@Overridepublic DragTracker getDragTracker(final Request request) {  if (request instanceof SelectionRequest    && ((SelectionRequest) request).getLastButtonPressed() == 3)    return null;  IDoubleClickCallback callback = new IDoubleClickCallback() {    public void handleDoubleClick(int btn) {      performDirectEditRequest(request);    }  };  return new DoubleClickDirectEditDragTracker(this, getTopGraphicEditPart(),       callback);}5. Add rich text editing support to direct editingIf you use direct editing only to set names for nodes, the default GMF Direct Editing behavior is sufficient. If you have a more formal language, for example an expression language, you should consider using Xtext to generate an editor for your grammar and integrate it into your GMF editor to support syntax coloring, validation and cross referencing.For the technical details have a look at Xtext integration into GMF ! [Less]

During the last weeks we supported the Papyrus team on polishing the xtext integration into their graphical editors. For those of you, who do not know Papyrus yet - "Papyrus is a graphical editing tool for UML2 diagrams. It provides a very advanced ... [More] support for UML profiles enabling support for "pure" DSL. Every part of Papyrus may be customized: model explorer, diagram editors, property editors, etc."(X)Text in PapyrusPapyrus offers graphical editors for all of the different UML diagrams. For some parts of the UML models, it provides textual languages - this is especially useful when using complex statements like expressions. The Papyrus team already provides a lot of grammars for different UML elements, for exampleProperties in class diagramsTransition expressions between states in state diagramsPorts in component diagrams   Xtext-based in-diagram editorsWhile the language grammars were already provided by the papyrus team, we added the Xtext-based in-diagram editor (maybe you know it from one of my previous posts) to the graphical editors.The in-diagram editor provides all those cool features like code completion, syntax highlighting, validation, cross referencing  that you know from your xtext editor but it is also a very lightweight component that fits seemlessly into the graphical editor. Give it a try - it is really cool. ;-)Since Papyrus has a slightly different editing paradigm than Yakindu Statecharts, you have to press "F2" instead of a double click to open the in-diagram editor. The same applies to the Model Explorer integration. Just select the Class Property you want to change in the Papyrus Model Explorer and press F2 to open a CellEditor with full-blown xtext support.For more complex expressions, an single-line CellEditor might not be well suited. For those cases, we added an Advanced Editing tab to the Properties view. If you use UML for whatever reason, you should definitely give Papyrus a try as an alternative to your propritary UML tool. Thanks to the papyrus team for the great cooperation! [Less]

During the last weeks we supported the Papyrus team on polishing the xtext integration into their graphical editors. For those of you, who do not know Papyrus yet - "Papyrus is a graphical editing tool for UML2 diagrams. It provides a very advanced ... [More] support for UML profiles enabling support for "pure" DSL. Every part of Papyrus may be customized: model explorer, diagram editors, property editors, etc." (X)Text in PapyrusPapyrus offers graphical editors for all of the different UML diagrams. For some parts of the UML models, it provides textual languages - this is especially useful when using complex statements like expressions. The Papyrus team already provides a lot of grammars for different UML elements, for example Properties in class diagrams Transition expressions between states in state diagrams Ports in component diagrams   Xtext-based in-diagram editorsWhile the language grammars were already provided by the papyrus team, we added the Xtext-based in-diagram editor (maybe you know it from one of my previous posts) to the graphical editors.The in-diagram editor provides all those cool features like code completion, syntax highlighting, validation, cross referencing  that you know from your xtext editor but it is also a very lightweight component that fits seemlessly into the graphical editor. Give it a try - it is really cool. ;-)Since Papyrus has a slightly different editing paradigm than Yakindu Statecharts, you have to press "F2" instead of a double click to open the in-diagram editor. The same applies to the Model Explorer integration. Just select the Class Property you want to change in the Papyrus Model Explorer and press F2 to open a CellEditor with full-blown xtext support.For more complex expressions, an single-line CellEditor might not be well suited. For those cases, we added an Advanced Editing tab to the Properties view. If you use UML for whatever reason, you should definitely give Papyrus a try as an alternative to your propritary UML tool. Thanks to the papyrus team for the great cooperation! [Less]

During the last weeks we supported the Papyrus team on polishing the xtext integration into their graphical editors. For those of you, who do not know Papyrus yet - "Papyrus is a graphical editing tool for UML2 diagrams. It provides a very advanced ... [More] support for UML profiles enabling support for "pure" DSL. Every part of Papyrus may be customized: model explorer, diagram editors, property editors, etc." (X)Text in PapyrusPapyrus offers graphical editors for all of the different UML diagrams. For some parts of the UML models, it provides textual languages - this is especially useful when using complex statements like expressions. The Papyrus team already provides a lot of grammars for different UML elements, for example Properties in class diagrams Transition expressions between states in state diagrams Ports in component diagrams   Xtext-based in-diagram editorsWhile the language grammars were already provided by the papyrus team, we added the Xtext-based in-diagram editor (maybe you know it from one of my previous posts) to the graphical editors.The in-diagram editor provides all those cool features like code completion, syntax highlighting, validation, cross referencing  that you know from your xtext editor but it is also a very lightweight component that fits seemlessly into the graphical editor. Give it a try - it is really cool. ;-)Since Papyrus has a slightly different editing paradigm than Yakindu Statecharts, you have to press "F2" instead of a double click to open the in-diagram editor. The same applies to the Model Explorer integration. Just select the Class Property you want to change in the Papyrus Model Explorer and press F2 to open a CellEditor with full-blown xtext support.For more complex expressions, an single-line CellEditor might not be well suited. For those cases, we added an Advanced Editing tab to the Properties view. If you use UML for whatever reason, you should definitely give Papyrus a try as an alternative to your propritary UML tool. Thanks to the papyrus team for the great cooperation! [Less]

In the upcoming statechart tools release we made a huge refactoring to the simulation infrastructure. This long overdue refactoring was necessary to define some concise APIs to plug in custom simulation engines for different execution semantics. It ... [More] took some time, but in the end our jenkins build is back to stable again ;-)  Debugging Features On top of the new APIs we build some great new debugging features for the graphical statechart editor. It is possible now to set breakpoints on transitions and states. If a breakpoint is hit, the simulation engine suspends before the transition or the state is executed. The semantic element the breakpoint is attached to is highlighted in a different color as you can see in the screenshot below.The debugging features are tightly integrated into the Eclipse debugging infrastructure. The eclipse breakpoints view shows all statechart breakpoints and allows to enable or disable them. But that's not all - it is even possible to specify conditional breakpoints with our expression language!Simply check the 'Conditional' checkbox in the breakpoints detail pane and specify any expression that evaluates to a boolean type. For the example model above, it would be possible to specify an expression like 'ABC.interfaceVar == 10'. If the result of the expression evaluates to 'true', the breakpoint hits.Simulation SnapshotsAnother great new feature we developed are so called simulation snapshots. (Thanks to Holger who developed a large part of the snapshot functionality as his 4 + 1 project) During simulation, you can take a simulation snapshot of the current execution state via the "Snapshot view". These snapshots can be restored at any time and simplifies the process of statechart debugging significantly.The snapshot details section shows the execution state at the time the snapshot was taken and previews an image with all active states. Statechart Debugging has never been so easy! ;-)This is just a short preview, detailed documentation on how to use the new features will follow. What do you think? Do you like the new features? Do you have another proposal how to simplify statechart debugging? Just leave a comment or send us some feedback via our user group !  [Less]

In the upcoming statechart tools release we made a huge refactoring to the simulation infrastructure. This long overdue refactoring was necessary to define some concise APIs to plug in custom simulation engines for different execution semantics. It ... [More] took some time, but in the end our jenkins build is back to stable again ;-)  Debugging Features On top of the new APIs we build some great new debugging features for the graphical statechart editor. It is possible now to set breakpoints on transitions and states. If a breakpoint is hit, the simulation engine suspends before the transition or the state is executed. The semantic element the breakpoint is attached to is highlighted in a different color as you can see in the screenshot below.The debugging features are tightly integrated into the Eclipse debugging infrastructure. The eclipse breakpoints view shows all statechart breakpoints and allows to enable or disable them. But that's not all - it is even possible to specify conditional breakpoints with our expression language!Simply check the 'Conditional' checkbox in the breakpoints detail pane and specify any expression that evaluates to a boolean type. For the example model above, it would be possible to specify an expression like 'ABC.interfaceVar == 10'. If the result of the expression evaluates to 'true', the breakpoint hits.Simulation SnapshotsAnother great new feature we developed are so called simulation snapshots. (Thanks to Holger who developed a large part of the snapshot functionality as his 4 + 1 project) During simulation, you can take a simulation snapshot of the current execution state via the "Snapshot view". These snapshots can be restored at any time and simplifies the process of statechart debugging significantly.The snapshot details section shows the execution state at the time the snapshot was taken and previews an image with all active states. Statechart Debugging has never been so easy! ;-)This is just a short preview, detailed documentation on how to use the new features will follow. What do you think? Do you like the new features? Do you have another proposal how to simplify statechart debugging? Just leave a comment or send us some feedback via our user group !  [Less]

In the upcoming statechart tools release we made a huge refactoring to the simulation infrastructure. This long overdue refactoring was necessary to define some concise APIs to plug in custom simulation engines for different execution semantics. It ... [More] took some time, but in the end our jenkins build is back to stable again ;-)  Debugging Features On top of the new APIs we build some great new debugging features for the graphical statechart editor. It is possible now to set breakpoints on transitions and states. If a breakpoint is hit, the simulation engine suspends before the transition or the state is executed. The semantic element the breakpoint is attached to is highlighted in a different color as you can see in the screenshot below.The debugging features are tightly integrated into the Eclipse debugging infrastructure. The eclipse breakpoints view shows all statechart breakpoints and allows to enable or disable them. But that's not all - it is even possible to specify conditional breakpoints with our expression language!Simply check the 'Conditional' checkbox in the breakpoints detail pane and specify any expression that evaluates to a boolean type. For the example model above, it would be possible to specify an expression like 'ABC.interfaceVar == 10'. If the result of the expression evaluates to 'true', the breakpoint hits.Simulation SnapshotsAnother great new feature we developed are so called simulation snapshots. (Thanks to Holger who developed a large part of the snapshot functionality as his 4 + 1 project) During simulation, you can take a simulation snapshot of the current execution state via the "Snapshot view". These snapshots can be restored at any time and simplifies the process of statechart debugging significantly.The snapshot details section shows the execution state at the time the snapshot was taken and previews an image with all active states. Statechart Debugging has never been so easy! ;-)This is just a short preview, detailed documentation on how to use the new features will follow. What do you think? Do you like the new features? Do you have another proposal how to simplify statechart debugging? Just leave a comment or send us some feedback via our user group !  [Less]