UML State is in effect a sub-diagram and I need a few improvements on how I visualize sub-diagrams. Under is a classic example on how I would draw 2 diagrams with 8 events/methods that goes from diagram to diagram. While this is possible and sometimes wanted it is also a bit clumbersome.
To improve precentation I have added two changes – the first is to tag events (exit labels) with a cross so the circles look different from methods (input labels). The second is to allow lines to be collected and replaced by a thicker line that indicat this is a collection of events. If you click on this line you will see a list of events/methods that are hidden. This makes it easier if you have multiple events from a diagram that all goes to the same place.
The last change is to add a title label. I don’t want to use the same header used in function call, so I will try the one below and see how it works out. This will be visually different from function calls and it solves the issue with lines on top conflicting with a small label above the sub-diagram.
The new lines are a bit of work – the lines themself are easy to make, but the collection of event/methods needs a bit of work. As for the methods/events I think we also need an option to place fixed methods/events freely on all four sides. Another issue is how I visualize unused methods/events and mandatory ones. In an earlier version I visualized everything like illustrated above and went against it – I did not like the result, but I could visualize unused ones and hide the circles once events/methods are used – but, that is details for another day.
But, how do I edit code that execute inside a selected device ?
The obvious answer is that we let the device be associated with a diagram and that everything inside that diagram executes on the device! If we in addition decide that this diagram reprecent a module we can also alter the visualization a bit to differ it from standard diagrams then used from other modules. Methods called then become messages sent to that device while events becomes messages received from that device.
Back to the idea of using small circles on absolutely all events/methods – that option is implemented, but I switched it off because I did not like the resulting diagrams. All the small circles made the diagram fuzzy to read, but that should be different if they only reprecent “TODO’s” – you see a circle because you have an unused method/event and once you use it the circle is hidden. If I also implement a right-click menu I can chose to move or hide a connection point.
I hard-coded modules in my previous entry to reprecent ECU w/sub-parts, but the real package will be a used add-on created as modules with fixed diagrams. This means I need some new property options on diagrams to control behavior. The idea is that you import a SDK to a project and that it add itself to the tool bar. That SDK is only a previously saved module tagged as a SDK so that the interface add itself to the toolbar. BSA itself should only contain core modules as “build-in” – these are tools that you never will be able to change, but you are free to create duplicates that is extensions or behave differently. As we save a projects we also save the modules you have used so that your project is consistent.