Relations here, there and every where...

[Martin Terreni]

Relations between elements in EA can be created at least in three different ways:
- Connectors
- Reference through tagged values
- Nesting in project tree

All of this create relation between elements, which creates a few problems:
- Only connector relations are seen in relationship view.
- Only connector relations are seen in diagrams ( even nested packages not show nested in diagram!).
- If I reference an element through a tagged value and add the same tagged to the referenced element I won't see the referencing element.
- When coding an adding I need to look for relation through three different paths.

I think I would expect all type of relations to be implicitly represented in the under lying model by connectors. This way all relationship would show in diagrams (as they should in a graphic tool) and I could search them all the same way. Specially because I believe a relationship is a relationship is a relationship...

I know this would be a big change for EA, but I think it is a very important and principal one (modeling wise speaking).

[«Midnight»]

Hi Martin,

I almost agree with you, but not quite.

Sadly, the issue of representing all such relationships with connectors is not compliant with UML, so you are out of luck there.

Almost...

Since the idea is non-compliant, such a solution won't work everywhere. But there is nothing that says you cannot build your own implementation that extends UML - for you - to do this.

First thing to do is get a firm grip on the Nesting connector. See if it will handle all the situations you describe. It will not allow you to create some relationships, but you'd be surprised what it will allow. [For example, you can nest use cases in classes.] If this provides enough flexibility for you, create an add-in (one that works 'inside' EA) that traps the appropriate events and creates nesting connectors when you create the appropriate relations (or create or move elements).

If nesting does not work, create your own stereotyped connector, perhaps with a custom connector end (via a shape script) to represent what you want.

[BTW, you might notice that the Nesting connector renders one end differently than you'd expect - it can be hard to see. Sparx is aware of this and will resolve it; it did not make the 7.1 production release in time.]

For tagged value relationships you will need to create your own stereotyped connector. I suggest doing this through a profile (so you can easily load it and test for it). Then once again trap events and add the connector.

The trick here is to make sure these connectors get onto all diagrams. Perhaps the best way is to trap events when new elements are added to diagrams. AFAIK EA does not automatically list our extended stereotypes in the Add Related dialog - but I could be wrong on this.

David

[Thomas Mercer-Hursh]

Likewise, I can sympathize, but not quite.  Project browser relationships can also be expressed using packages and subcomponents as appropriate and there is no reason not to also use connectors, again to express specific relationships.  Really, without the connector and a stereotype, one would have no way to indicate the many kinds of relationship that might exist.

Likewise, I think, for tagged values.  If the tag really is a relationship, then create the connector.  Otherwise, it is more appropriate left as a property and found via queries.

[Martin Terreni]

You might be just right, the problem is that referencing an object through tag value is "legal" but not reflected in any way as a relationship, right or wrong - it is a little confusing...

[Thomas Mercer-Hursh]

Note that, if it is natural in your development to create tags and you would then like to recognize some of these tags as relationships, you could probably create some automation that would create the relationships for you.

In my own work I am creating a lot of connectors, including both detail connectors and summary connectors from higher level entities and assigning different stereotypes so that we can select the level of entity and the level of relationship by diagram.  This seems very powerful to me.

[«Midnight»]

...
In my own work I am creating a lot of connectors, including both detail connectors and summary connectors from higher level entities and assigning different stereotypes so that we can select the level of entity and the level of relationship by diagram.  This seems very powerful to me.

Yes Thomas,

And more to the point, it is working! If you ask me, that pays the bulldog.

As far as the automation overhead is concerned, it only hurts once. Martin's been there, as have we. It will probably be more of a bother to write the business case, but such is life.

David

[Martin Terreni]

The problem would be to catch the "add taggged value" event, I don't think it is possible. If it is not this would mean I would have to run seom batch job to create this linke not on-line - very problematic.
Maybe the way is just not to connect objects through tags, this will (rightfully IMHO) piss my ucstomers, but as misnight stated "such is life".

PS: I still wasn't conviced that related to entities through tags and not enbling automatic genration of links from this, is an inconsistency.

[«Midnight»]

Perhaps set this up in a profile. I don't know if this would trigger the event but it might (since the tagged value looks more like an element this way).

David

[Thomas Mercer-Hursh]

If you know from the outset that it is a relation, then it is a relation, so create the connector.  If you create a bunch of tags and then later on figure out that one of them defines a relation, then use code to create the relations and create new relations directly from there on.

Bottom line here, I think, is that tags are properties, not relations.  They might imply relations, but when they do, one should create an appropriately stereotyped connector to express that relationship.  That's UML.

[«Midnight»]

...
Bottom line here, I think, is that tags are properties, not relations.  They might imply relations, but when they do, one should create an appropriately stereotyped connector to express that relationship.  That's UML.

Yes, which is why they (OMG) did it this way.

If you need to say more about the connector, add some tagged values to it...

David

[Martin Terreni]

I guess you are right...

[Thomas Mercer-Hursh]

If you need to say more about the connector, add some tagged values to it...

Indeed, one of the things I find very useful about creating the connector is that one can then add values to describe it more fully.  E.g., in the current work where we are modeling existing legacy code, one of the kinds of connectors we are creating is between various units of code and the data tables accessed by the code.  We use four different stereotypes depending on whether the access is read only or not and for summarizing each to higher level units (think in terms of detail to the method and summary on the class, although most of this is not OO).  Each connector also gets a tag which has flags for create, read, update, and delete as appropriate to the actions in that code along with tags for each field in the table and whether it is read and/or written or both.  Another tag contains the actual "where clause", i.e., the query specification used to make the connection.  All of that provides a very rich set of descriptors about what is happening.

[Martin Terreni]

sounds like a very professional work.  Good luck.
I wish I could bring my customers to work like that easily...people is always so reluctant of moving forward (like I'll probably be one day...)
I'm in charge of moving  Amdocs (a 17000 employees company) to UML modeling in a couple of years, and do it with a very heterogeneous population in terms of modeling knowledge.
It is the greatest opportunity, for young engineer like me, but  an unimaginable infinite head ache... (like kids )

[Thomas Mercer-Hursh]

I might note that these relations and tags I am referring to are being built directly into the schema of the database based on the empirical code.  Thus, the developers at the customer company need to learn more to read models, than to create them.  One of the people who consults there is doing some nice automation.  One piece allows pointing at a particular code object and selecting stereotypes and depth and it drags all indicated components and connectors into a diagram.  Another will automatically hide or make visible connectors by stereotype.  Another allows leaping from a component in the model to an HTML page showing the code, heavily populated with links.

It is all coming out rather nicely, I think.

And, yes, I do hope to publish some of the automation later so that others can take advantage of it too.