Move local properties from Lifeline to Message

[Matthias Schoettle]

For temporary properties used in a message view we store these in localProperties of the Lifeline. However, with nested operation definitions, it is possible that one lifeline is used to define several behaviours. In that case, the temporary properties of both are available to each other, which makes it hard for the generator to know which property belongs to which operation.

Therefore, the localProperties containment should be moved to the Message, i.e., the message representing the call to the operation being defined.

All existing models have to be updated accordingly, as well as the weaver, code generator etc.

[Matthias Schoettle]

Currently, all code dealing with local properties can easily access them through the lifeline. With the requested change, somehow the message has to be retrieved, which defines the behaviour.

However, the current message or fragment could be inside a combined fragment (even nested) and the message we are looking for is outside of it. Therefore, we need some recursive way to while moving up in the list of fragments to find the message.

Since this functionality is needed almost in any part (edit, controller, gui, weaver and generator) we should put this into the model directly.

[Matthias Schoettle]

An alternative way of modeling this as discussed in our meeting would be to use the execution "box" (execution specification or similar in UML) and store it in there. This would definitely make it easier to retrieve the local properties. However, it would complicate the definition of message views even more and currently we don't need it as we only have synchronous calls.

[Matthias Schoettle]

As per meeting today we decided to move it to Message and provide functionality to find the initial message.

[Matthias Schoettle]

References issue #153: Moved localProperties from Lifeline to Message. All code that used local properties currently still has errors, which will be resolved later.

→ <<cset 4f2365f85fef>>

[Thomas Di Meco]

Generator: Updated the generator to support local properties on messages (Ref #153)

→ <<cset 0db49bb45f90>>

[Thomas Di Meco]

Note: We will have to merge the Generator branch on the master when everything will be ported to the new model.

[Matthias Schoettle]

References issue #153: Added helper method to find the initial message. Includes the recursive lookup when the given fragment is contained in a InteractionOperand (CombinedFragment).

→ <<cset b8e68dde7d14>>

[Matthias Schoettle]

References issue #153: Adjusted controller, item providers and handler to use the helper method and the local properties from the corresponding message.

→ <<cset 67ef17b79057>>

[Matthias Schoettle]

References issue #153: Updated message view weaver to handle local properties of initial message.

Also, when creating the initial message view/interaction, when copying the message, the properties are copied as well, these are removed.

→ <<cset b56018b73a49>>

[Matthias Schoettle]

All models are updated and branch merged to master.

Generator branch merged to master as well.

[Matthias Schoettle]

References issue #153: Fixed problem when finding initial message (index off by one).

→ <<cset 1b39b3c72965>>

[Matthias Schoettle]

References issue #153: Changed the beginning index when finding the initial message to be the one of the given fragment, so that in case that one is a receive event, its message will be found.

→ <<cset 04a0d0d7650e>>