Open Andrew-Dunn opened 8 years ago
Issue discussion here: #156
Awesome, a quick glance and things look good! I need to find some time to properly review. However quick comment, 'executionSpecification' seems long, can we just drop the word specification or spec everywhere. I think without it out is still easy to read and understand the code.
Can do! Don't review this until I've done that, I've found some more avenues for refactoring.
@bramp Good to go!
Also, I added an error message for the issue described in the main pull-request post.
I'm confused a little at what it means for level to be > 1. Would you show me an example where you mix different levels.
participant Actor
note right of Actor: This actor does not currently have an execution in progress, so level = -1
Actor->+Actor: Increase level
note right of Actor: An execution has started, so level = 0
Actor->+Actor: Increase level
note right of Actor: The level of execution nesting has increased, so level = 1
Actor->-Actor: Decrease level
note right of Actor: level = 0
Actor->-Actor: Decrease level
note right of Actor: The execution has ended, so we are back at -1
Made some changes addressing your comments.
Hey, @bramp just a friendly ping to see the progress of this review? Cheers!
:+1: Any hope to see progress on this awesome change?
Friendly ping 🙂. Would love to see this land.
I've added support for UML ExecutionSpecifications, which are the grey bars commonly seen in UML Sequence Diagrams, and indicate the execution of an action.
Using them is quite simple, all you need to do is prepend a
+
or-
character before the actor/lifeline that will be executing an action. The+
character will begin the ExecutionSpecification, and the-
character will end it.Example
The following example shows an API executing a function in response to a user calling function foo().
Known Issues:
Doing a double jump in a single self-signal will cause some rendering issues. I don't expect this will be commonly encountered.