Slightly weird question: direction of use case-actor associations

[Richard Freggi]

In use case diagrams is there any difference (semantic, query/documentation/reporting, tool-specific quirks or otherwise) if I draw the association from the use case to the actor, or the other way around?
Asking for a friend.

[qwerty]

No. It's just the API that offers role names and navigability "the other way round". From an UML perspective only the connector counts. It has 2 memberEnds, not a start/end.

q.

[Richard Freggi]

Thank you!

[Modesto Vega]

The only problem you may encounter is if the association is directional. By default, a directional association is Source to Destination/Target, with the arrow on the target side.

However, Sparx allows you to create a directional association which is Destination/Target to Source, with the arrow on the source side. Interestingly, it "changes" the direction but does not "reverse" it, it does not switch the source and target around. The latter is accomplished via the Reverse Direction menu item.

I do not understand the rationale behind this, but it allows a welcomed level of flexibility around how to draw connectors.

[Geert Bellekens]

We always try to impose a fixed source/target in any of our relations.
These conventions are documented in the method guidelines, and checked with validation rules.

Having a fixed direction make things like SQL Queries a lot easier (and we use those in searches, scripts, document generation templates,...)

Geert

[Paolo F Cantoni]

We always try to impose a fixed source/target in any of our relations.
These conventions are documented in the method guidelines and checked with validation rules.

Having a fixed direction make things like SQL Queries a lot easier (and we use those in searches, scripts, document generation templates,...)

Geert

Wot 'e sed!

One needs to distinguish between directionality (which end is the origin and which the destination when dragging the connection), and navigability how one might semantically traverse the resulting connection.  Sparx EA conflates the two.

As Geert describes, is you don't impose a degree of semantic rigour, your ability to effectively query the model is reduced.

Note, however, as qwerty said, that once the line is drawn you can't ipso-facto determine which was the origin and which was the destination - especially if drawn by hand on paper.  However, that's why we aren't using paper and why we are validating the model electronically.

Paolo

Paolo

[qwerty]

As a side note: I made me a wrapper to have EAConnector return "the other side" rather than having to check start and end which side the element's connector is attached too. EA has quite some design faults. That happens when you design systems from scratch and I don't blame Sparx for that. However, I blame them for never fixing any of their design faults.

q.

[Paolo F Cantoni]

As a side note: I made me a wrapper to have EAConnector return "the other side" rather than having to check start and end which side the element's connector is attached too. EA has quite some design faults. That happens when you design systems from scratch and I don't blame Sparx for that. However, I blame them for never fixing any of their design faults.

q.

"You might well think that; I couldn't possibly say that."  - Francis Urquhart (House of Cards, the book and UK series)

Paolo

[Modesto Vega]

Just a number of random comments.

As suggested by Geert, trying to impose a  source/target when creating relations (and using validation rules to monitor rule adherence) is a good idea but the key word is trying and not imposing. Sparx is so flexible that imposing is virtually impossible. I presume that this is easier to do if the related elements have different base classes - e.g., the source of a Use/Usage relationship should be the Actor and the target the Use Case - or the relationship is naturally directed - e.g., Generalisation
I also Presume this is not so easy to implement if the elements do not have the same base class. How do you try to enforce this for associations between classes?

When Paolo distinguishes between directionality and navigability, I presume he is not using navigability in the UML sense of the word. In UML, are not directionality and navigability separate concepts?

Sparx makes life a bit too easy sometimes, it is way to easy to create a semantically inconsistent relationship that visually looks right - e.g. a Usage relationship between an Actor a Use Case with the source on the Use Case and the target on the Actor, and therefore implying that Use Case uses the Actor (and not the other way around). I can see the argument for suggesting that more should be done to improve this.

[qwerty]

Directionality is no UML term. Navigability is.

q.

[Modesto Vega]

There are 17 uses of the word "directed" in the latest UML specification, I am not going to quote them all. Direction is a UML concept.

A directed association indicates that control flows from one classifier to another; for example an actor to a use case. This flow of control means that only one of the association ends specifies navigability.
[...]
A directed association is displayed as a solid line with an arrow that indicates the direction of navigation.

From: https://www.ibm.com/support/knowledgecenter/SS8PJ7_8.5.1/com.ibm.xtools.modeler.doc/topics/cdirasn.html

Direction is achieved by having only one of the association ends specified as navigable. There are 2 other possibilities, having no ends navigable (which is Sparx default behaviour for most associations) or having both ends navigable.

Sparx handles this is a follows:

• Unspecified direction - Navigability on both ends of the relation is set to Unspecified
  
• Source to Destination direction - Navigability on Source set to Unspecified, Navigability on Target set to Navigable
• Destination to source direction - Navigability on Source set to Navigable, Navigability on Target set to Unspecified
• Bidirectional - Navigability on both ends set to Navigable

Only the last 3 options are directed.

If a relationship is navigable, it is directed. Hence, my query to seek clarification on Paolo's comment regarding navigability.

As qwerty and Geert, have stated the fact that Sparx chose to store both ends as 2 columns, one called source and the other called target, instead of 2 rows, is to simplifying writing and reading data from the database.

[qwerty]

Sorry, I mixed things. However, DirectedRelationship is a concept that applies to Dependency, Generalization, Import, PackageMerge, Include, Extend, InformationFlow and TemplateBinding.  Associations don't have direction. They only have navigability. So here's where things get mixed up in EA. They all have as well as direction as navigation. Even Dependencies go both sides which is incorrect. For ControlFlow etc. EA just blocks the dropdown. But obviously it takes the same mix-concept.

q.