Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added support for UML ExecutionSpecifications #157

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

Andrew-Dunn
Copy link

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().

User->+API: foo()
note right of API: Processing foo.
-API-->User: Result.

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.

+A->+A: This will cause some rendering issues regarding arrow placement.

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().

    User->+API: foo()
    note right of foo: Processing foo.
    -API-->User: Result.
Signals were being rendered before execution specifications because
I was using the signal draw code to calculate the y position of each
signal. Signal y-positions are now calculated independently by the
execution specification drawing code. This means execution
specifications no longer overlay signal arrows and/or labels.
Tests syntax changes, and makes sure it doesn't break anything else.
Also did some cleanup and updated the EBNF grammar.
@Andrew-Dunn Andrew-Dunn changed the title Feature execution specifications Added support for UML ExecutionSpecifications Jul 20, 2016
@Andrew-Dunn
Copy link
Author

Issue discussion here: #156

@bramp
Copy link
Owner

bramp commented Jul 20, 2016

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.

@Andrew-Dunn
Copy link
Author

Can do! Don't review this until I've done that, I've found some more avenues for refactoring.

@Andrew-Dunn
Copy link
Author

Andrew-Dunn commented Jul 20, 2016

@bramp Good to go!

Also, I added an error message for the issue described in the main pull-request post.

@@ -108,6 +176,12 @@
OVER : 2
};

Diagram.EXECUTION_LVL_CHANGE = {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe just "Diagram.EXECUTION_CHANGE"

@bramp
Copy link
Owner

bramp commented Jul 21, 2016

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.

@Andrew-Dunn
Copy link
Author

Andrew-Dunn commented Jul 21, 2016

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

@Andrew-Dunn
Copy link
Author

Made some changes addressing your comments.

@Andrew-Dunn
Copy link
Author

Hey, @bramp just a friendly ping to see the progress of this review?
Cheers!

@crdev
Copy link

crdev commented Mar 8, 2019

👍 Any hope to see progress on this awesome change?

@jessegreenwald
Copy link

Friendly ping 🙂. Would love to see this land.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants