Analysis of Sequence Diagram Lifelines

[ZuluTen]

I am attempting to programmatically analyse a sequence digram in order to better understand where an element has an effect on other elements.

The intention is to select a single element lifeline on a sequence diagram and then run the analyser as part of my Add In, resulting in all sequence diagrams in which that element plays a part turning red along the sequence/connector path.

Using a SQL query of t_connectors where connector type = “Sequence” is fairly straightforward, and yields an array of target and connector IDs  and I can easily change the colour of all the connectors emanting from a particular element.

I can then repeat the exercise, in each case replacing client with supplier until the end of a sequence of reached.
Simples!

Where I am struggling is in dealing with vertically discontinuous lifelines: I can't work out how to isolate only those connectors which exist(link) in the same vertical 'block' of any given lifeline:

Maybe the only way is to figure out the upper and lower 'Y' values for each of the discontinuous block and then see whether when drawn the connector arrow tip falls within the Y limits, but that seems rather crude. Surely there's a more elegant way?

Scouring 'Inside EA' yields no clue as to where the lifeline discontinuities are stored, so I'm at a loss.

Thank you in advance for any suggestions...

[qwerty]

At a first guess I'd say you have to bite the bullet and analyze the y position, though I'm not quite sure what you mean exactly with discontiguous. I assumed object activation.

q.

[Geert Bellekens]

I don't think you need positioning info to figure that out.
Messages in sequence diagrams have a
- sequence number
- Synchronous/Asyncronous
- lifecycle info (Create/Destroy)

I believe you should be able to deduct all lifeline info you need from those  properties.

Geert

[KP]

You will also need to look in t_connector.StateFlags and interpret the values of a number of flags, e.g. ForceActivation, StopActivation, EndActivation, ExtendActivationUp etc. You're on your own with those, I'm afraid, and they aren't easy. Good luck.

[ZuluTen]

Just in case my attempted narrative description wasn't clear.
The first image is what I've got, which, if it's legible shows that the Widget Painter can affect the output of both painted and unpainted widgets.



The next image shows what I want which is that failure of the Widget Painter can, unsurprisingly, only affect the painted widgets.



Thanks for the suggestions so far, I shall investigate these this morning...

I appreciate that my application of EA may well be taking it outside its comfort zone - and from KP's response, outside Sparx' as well...
...which is surprising as I would have thought they'd be keen to broaden its market...

[KP]

I appreciate that my application of EA may well be taking it outside its comfort zone - and from KP's response, outside Sparx' as well...

My comfort zone and Sparx's comfort zone are entirely different things

[qwerty]

It's definitely tricky - and interesting. Does look to me again like something one could sell as a little App

q.

[RoyC]

Ummm - it looks to me as if the two diagrams are identical, and show that the Widget Painter has no impact on the shipment of unpainted widgets. Am I missing something?

[KP]

Ummm - it looks to me as if the two diagrams are identical, and show that the Widget Painter has no impact on the shipment of unpainted widgets. Am I missing something?

The diagrams have some of their messages coloured red to indicate which messages cause which other messages. In the first diagram, the third red message shouldn't be coloured red because there is a break in the activation between it and the first red message.

[RoyC]

OK - I understand that. I don't understand how the first diagram, then, comes about, perhaps like ZuluTen, but that is well outside my comfort zone too. But not necessarily Sparx's!

[Eve]

Time for me to comment I guess.

My understanding is that the first diagram is showing the highlight created from your add-in, possibly by following every outgoing path from Widget Painter. The second is the highlight that you want to achieve based on your human understanding of the diagram.

The simple case where EA breaks an activation is when an outgoing message isn't started by an activation called by the starting activation. Where it gets complicated is when you start taking nested activations on a lifeline and the activation modifiers mentioned by KP into account. I'm not going to go into any of those.

If it's for your own use, I would consider adding them via experimentation as needed. If you're giving it to someone else you may need to do some systematic investigation in advance.

[qwerty]

Hey you guys! Is your office soooo large than you can't discuss this personally but instead have to use this forum?

q.

[Eve]

Not at all. I'm commenting for the benefit of ZuluTen (as can be seen by the fact that I addressed it to the person writing an add-in)

[RoyC]

And the whole point of the discussion forum is that everyone - especially the original poster, but also the many people who view the thread but don't add to it - gets to see what is being raised, reviewed, used or discarded.

And speaking of the original poster, has any of this helped you, ZuluTen?

[qwerty]

Wasn't meant as offense rather than as joke.

q.