On/Off-page and On/Off diagram connectors

[Paolo F Cantoni]

A recent post: Off-Page Connectors in BPMN reminded me about the fact that support for "long" connectors in EA is limited (and, to a small extent, disfunctional).

So, before I submit a formal feature request, I thought I should sort out some of the ideas involved and get any feedback from our knowledgeable user base.

Whatever proposal that we generate, needs to be both human usable and manageable by automation.  The solution should also apply to the HTML and RTF reports.  In particular, for my own part, I seem to be working increasingly at the level of generating websites corresponding to the portions of the model - "page" will have two meanings:  Web screen (at a particular resolution) and printed page.

Metamodel:  A model is composed of related vertexes connectable by arcs  (not every vertex is related to it's related vertexes by arcs).  The vertexes and their interconnections can be represented in diagrams.  Diagrams are rendered onto one or more pages, printed or web.

The saying goes:  "A picture is worth a thousand words" - to which I have added the rejoinder: "until there's more than 6 shapes and twelve lines in which case, all bets are off!".  However, often, we need to have more complex diagrams that include the many more arcs and shapes.

Given the current drawing engine (or paradigm - as a user it's not clear which) that EA uses forces arcs to overlay vertexes, a diagram can become visually confusing very quickly.  (NOTE: I'm not criticising the overlay approach, just observing that's the functionality).

EA provides a somewhat convoluted mechanism to allow the creation of on-diagram:  You first have to make the arc a "custom line" style, then you have to add "bends" (way-points) on the line to create multiple segments.  Next you have to suppress one of the line segments - and EA will then place a marker at either end of the suppressed segment.  The markers (at each end of the suppressed segment) have no explicit identity - so, if you had more than one suppressed line segment on the diagram, this might be a source of confusion (depending on circumstances).  If you have named the arc, then the name of the arc is embedded within the marker.  (NOTE: again, some (possibly mostly) of these actions are necessary, but, in my view, some of the mechanisms used here are not optimal).

So what to do?

Firstly, it seems to me we need to clearly separate model infrastructure from rendering infrastructure.  The original post (and KP's response) cite BPMN as providing off-page connectors.  The BPMN specification (in section 10.2.1 Normal Flow) describes the use of Link Intermediate Events as "Off-page Connectors" or "Goto Objects".  In my view, this is conflating two ideas - modelling and rendering. Your model should not be constrained by the rendering constraints imposed by an arbitrary rendering technology.  The reduction of "clutter" on a diagram is a function of the diagram - hence mechanism such as on/off page connectors should be attached to the diagrams themselves - thus requiring: Diagrams as first class citizens of Repository.

Now, to the concepts themselves...

I have made a distinction in the topic title between on/and off diagram connectors.  I believe they are conceptually different - although not by much.  EA already provides mechanisms for linking between diagrams:  The incorrectly named "composite" element mechanism and hyperlinks.  The former attaches a diagram (of arbitrary type and, once linked, arbitrary location within the repository) to a vertex.  The latter allows you to move to another diagram by double-clicking the (adorned) vertex or the hyperlink.  Now, it seems to me that in the context of this discussion, an off-diagram connector is about "splitting" an arc so that one end is in one diagram and the other end is in another diagram.  Consequently, it is a rendering function.  Neither of the existing mechanisms achieve this.  So a new mechanism is required.

The ability to create/suppress segments shouldn't be restricted to "custom line" style arcs...  The number of segments is orthogonal to the "shape" of the arc.  In particular the creation of such connectors should be a first class function of the arc.  (Not as at present almost a side effect of a series of operations).

As regards on-diagram connectors, I believe an indication of whether the other end is on the same page or on a different page would be useful.  This would apply to whether the page were printed or nominated screen size.

(See part 2 below)

[Paolo F Cantoni]

(see part 1 above)

In all cases, each end of the suppressed segment should be (either automatically or manually) identified with an identifier particular to that diagram (or in the case of off-diagram connectors particular to both diagrams).  This identifier should not be part of the arc itself as it is purely a rendering convenience.

Lastly, there needs to be a function "take me to the other end of this suppressed segment.  This would take the user to the location of the opposite connector - whether on this diagram or another.

I think that's enough to "get the ball rolling".

Thoughts?  Feedback?
Paolo

[Geert Bellekens]

Wow, you just wrote a whole chapter of a book here.

Lets see if I understand what you mean.
1. You want to be able to show a connector from A to B even if B is not shown on the diagram.
2. You want to be able to show the part that is missing from the first diagram on another diagram
3. You want a way to navigate between the two diagrams showing the two parts of the connector.

I this is what you are asking for, I think it should be very clear that all of this is related to the "DiagramLink", i.e. the representation of a connector on a (two) diagram(s). So all the splitting, hiding, continuing function should act on the DiagramLink, and not on the Connector.

Hmm, yes, I can see a function like this to be usefull in some circumstances, but it can also lead to some confusion.
If I needed such a functionality right now I would just show both A and B on my diagram. I would then link a hyperlink to the second diagram to B (and the other way around on the second diagram).
I wonder if that way of working wouldn't be easier to understand because in this case you clearly see to which element the connector goes.

Geert

[Paolo F Cantoni]

Hi Geert,

Thanks for your response...  I see I wasn't as clear as I wanted to be - I did write the post as one stream.  Once the discussion is stable, I'll refactor the original post.

Anyway to address some of your points...

Wow, you just wrote a whole chapter of a book here.

Lets see if I understand what you mean.
1. You want to be able to show a connector from A to B even if B is not shown on the diagram.
2. You want to be able to show the part that is missing from the first diagram on another diagram
3. You want a way to navigate between the two diagrams showing the two parts of the connector.

This is only ONE of the types of connections I wrote about.  This is specifically the off-diagram connector.  Its job is to allow you to leave one end of the arc off the diagram, but still link to it.  Rare, I agree since normally, one would use the hyperlink to do this, but, I think, as we investigate this functionality, we might find more uses for it.  Let's wait and see.

I tried to abstract the concept of "connection" via suppression and treat all the connection types as uniformly as possible.

If this is what you are asking for, I think it should be very clear that all of this is related to the "DiagramLink", i.e. the representation of a connector on a (two) diagram(s). So all the splitting, hiding, continuing function should act on the DiagramLink, and not on the Connector.

Yes, that's what I'm saying...  One problem is that the same DiagramLink would be on more than one Diagram - which violates the RI.  We'll have to find a way around this (one suggestion below).

Hmm, yes, I can see a function like this to be useful in some circumstances, but it can also lead to some confusion.
If I needed such a functionality right now I would just show both A and B on my diagram. I would then link a hyperlink to the second diagram to B (and the other way around on the second diagram).
I wonder if that way of working wouldn't be easier to understand because in this case you clearly see to which element the connector goes.

Geert

The problem here is that the hyperlink ISN'T the vertex and vice versa.  If DiagramObjects were first class elements of the repository then you could create an alternate rendering of the vertex (as "off-diagram connector") and place the hyperlink details in the DiagramObject.  This wouldn't violate the "have only one instance of a vertex on the diagram" constraint as if you already had the vertex on the diagram, you wouldn't need the off-diagram connector.

Hope this clarifies things...
Paolo

[skiwi]

Bump

[jeshaw2]

Hi Paolo.  I'm back for a short visit.

As usual, your writings require multiple/careful readings.  I enjoy the way you clarify messy situations. So far, I like the differentiation between modeling and rendering; that is important. I would vote for keeping the hyperlink as a rendering adornment; not a different kind of rendering link.

I'm wondering what might your take be on arcs that model trees.  One might initially think the solution would be to have all of the arcs defined on the parent rendering and the off-page links at the end of each branch.  But we have an opportunity here.

If one wanted to add another limb to the tree, the parent tree would have to be modified to make the link (as well as declaring the link on a related diagram).  Assuming that the off-page links are named, could we not just establish the tree by referencing the parent link on the child diagram?  (As I build my Banyan Tree, I hate to keep modifying parent diagrams. I'm lazy that way  )

[Paolo F Cantoni]

Hi Paolo.  I'm back for a short visit.

As usual, your writings require multiple/careful readings.  I enjoy the way you clarify messy situations. So far, I like the differentiation between modeling and rendering; that is important. I would vote for keeping the hyperlink as a rendering adornment; not a different kind of rendering link.

Jim,
As usual, you are too kind.  However, I DO believe that modelling is an essential part of complexity management (by trying to reduce complexity through modelling insights).

I'm wondering what might your take be on arcs that model trees.  One might initially think the solution would be to have all of the arcs defined on the parent rendering and the off-page links at the end of each branch.  But we have an opportunity here.

If one wanted to add another limb to the tree, the parent tree would have to be modified to make the link (as well as declaring the link on a related diagram).  Assuming that the off-page links are named, could we not just establish the tree by referencing the parent link on the child diagram?  (As I build my Banyan Tree, I hate to keep modifying parent diagrams. I'm lazy that way  )

Here I have to admit that I'm not getting my head around what you're saying.

Here on the West Coast of OZ it's 36°C and the air conditioning has broken down in this multi-storey office - so any deep thought is rather problematic at the moment.  

Can you clarify?
Paolo

[jeshaw2]

[snip]

Here I have to admit that I'm not getting my head around what you're saying.

Here on the West Coast of OZ it's 36°C and the air conditioning has broken down in this multi-storey office - so any deep thought is rather problematic at the moment.  

Can you clarify?

[snip]

Perhaps my comments are not in the same context as yours.  Is your context a single diagram type?  I think not and neither is mine.  What's going on in my mind is the presence of a fork/join or perhaps the existance of many concurent processes or states.  Often, I've had situations where a single page could not contain them all and thus the need for off page connectors with a one to many connection from the fork to the concurrent element.  Your discussion seemed to be constrained to a 1:1 connection.  I then went on to discuss a way to ease the work load in maintaining 1:m connectors in a dynamic design environment.

Does any of this help?

I've got -6C with heavy winds and snow falling at the rate of 50 miles / hour all last night.  I got 20 cm of the stuff in my driveway.

Got to go dig myself out now

[Paolo F Cantoni]

[size=18]...[/size]
What's going on in my mind is the presence of a fork/join or perhaps the existence of many concurrent processes or states.  Often, I've had situations where a single page could not contain them all and thus the need for off page connectors with a one to many connection from the fork to the concurrent element.  Your discussion seemed to be constrained to a 1:1 connection.  I then went on to discuss a way to ease the work load in maintaining 1:m connectors in a dynamic design environment.

Does any of this help?
[size=18]...[/size]

Sure does, I get it now...

I think the link issue can be handled by the off-page/off-diagram connectors that I mentioned.  I don't think you can get away with NOT amending the parent diagram.

However, you've reminded me of a related issue.  In the situation you've outlined and (probably more often) with a set of generalizations, you need a marker (in addition to indicating whether the "fan-out" is complete or not in the model) to indicate that of the fan-out in the model "you are NOT seeing the complete list..."  So, in this situation, when you add the additional link to the child diagram, you need to amend the marker in the parent diagram to show (there are more links than you see available in this fan-out) - until you add the new link tot he parent diagram.

Do you follow?

I have an analogous case with my neighborhood diagrams that suppress some links.  In my view, if the set of links visible on the diagram is NOT complete then EA should provide a small indicator to that effect.  I'll be adding one programatically.

Paolo

[jeshaw2]

I think the link issue can be handled by the off-page/off-diagram connectors that I mentioned.  I don't think you can get away with NOT amending the parent diagram.

I'm suggesting that all off-page connectors are uniquely named and that these names are kept in a table of connector/diagram names.  That is, all connectors participating in a union of connectors, would share the same name.  Then in the case of a hyper link adornment on the connector, a drop down list of diagram names could show the list of other diagrams having related connectors.  When a new diagram with a mating connector is established, EA could amend the  the table automatically and the modeler would not have to amend the parent diagram.

However, you've reminded me of a related issue.  In the situation you've outlined and (probably more often) with a set of generalizations, you need a marker (in addition to indicating whether the "fan-out" is complete or not in the model) to indicate that of the fan-out in the model "you are NOT seeing the complete list..."  So, in this situation, when you add the additional link to the child diagram, you need to amend the marker in the parent diagram to show (there are more links than you see available in this fan-out) - until you add the new link tot he parent diagram.

Do you follow?

Yes, I follow.  This can be a bit of a sticky wicket though.  Obviously, the software could not detect a complete fan out/in list so that would be left to the human modeler to determine.  But, even if the human thinks the list is complete, a 'change order' would come along and render the list incomplete.  I'm not sure I'd trust the little completeness indicator;  I'd want another way to assure completeness has been established.

I have an analogous case with my neighborhood diagrams that suppress some links.  In my view, if the set of links visible on the diagram is NOT complete then EA should provide a small indicator to that effect.  I'll be adding one pragmatically.

Perhaps a list element(s) suppression indicator on the drop down list instead of an 'incomplete list' indicator?  It is so hard to prove a negative.

JimS

[Paolo F Cantoni]

[size=18]...[/size]
I'm suggesting that all off-page connectors are uniquely named and that these names are kept in a table of connector/diagram names.  That is, all connectors participating in a union of connectors, would share the same name.  Then in the case of a hyper link adornment on the connector, a drop down list of diagram names could show the list of other diagrams having related connectors.  When a new diagram with a mating connector is established, EA could amend the  the table automatically and the modeler would not have to amend the parent diagram.

I defined off-page as connectors to a different page of the SAME diagram.  Off-diagram connectors as connectors to a DIFFERENT diagram.  Are you meaning off-diagram connectors here?

[size=18]...[/size]
Yes, I follow.  This can be a bit of a sticky wicket though.  Obviously, the software could not detect a complete fan out/in list so that would be left to the human modeler to determine.  But, even if the human thinks the list is complete, a 'change order' would come along and render the list incomplete.  I'm not sure I'd trust the little completeness indicator;  I'd want another way to assure completeness has been established.

In the case of Generalization and GeneralizationSets, UML provides the IsComplete property for this purpose.  Obviously, the modeller has to set the value; but I don't think that's germane to the argument.  The model knows the set of links under the GeneralizationSet.  If the number rendered on any diagram is less than that number, then it displays a "links missing" symbol - to indicate "...but wait! There's more!"

I have an analogous case with my neighborhood diagrams that suppress some links.  In my view, if the set of links visible on the diagram is NOT complete then EA should provide a small indicator to that effect.  I'll be adding one programatically.

Perhaps a list element(s) suppression indicator on the drop down list instead of an 'incomplete list' indicator?  It is so hard to prove a negative.

I'm talking about links here, not elements.  But your point is taken; the indicator (on the diagram) should be designated: "some links suppressed".

Paolo

[jeshaw2]

[size=18]...[/size]
I'm suggesting that all off-page connectors are uniquely named and that these names are kept in a table of connector/diagram names.  That is, all connectors participating in a union of connectors, would share the same name.  Then in the case of a hyper link adornment on the connector, a drop down list of diagram names could show the list of other diagrams having related connectors.  When a new diagram with a mating connector is established, EA could amend the  the table automatically and the modeler would not have to amend the parent diagram.

I defined off-page as connectors to a different page of the SAME diagram.  Off-diagram connectors as connectors to a DIFFERENT diagram.  Are you meaning off-diagram connectors here?

[size=18]...[/size]
Well, I meant 'different page of the same diagram', but now I have to think about how to name pages...page numbers are not helpful in a drop down list...  But isn't the issue the same for 'off page' and 'off diagram'?  After all, a connector is a connector.??

Jim