Circle notation for interfaces

[Paolo F Cantoni]

The EA Help says:

"Interfaces are drawn in a similar way to a Class, with operations specified, as shown below. They can also be drawn as a circle with no explicit operations detailed. Use the right-click context menu option Use Circle Notation to switch between styles. Realization links to an Interface drawn as a circle are drawn without target arrows."

In a(n admittedly quick) search of the [size=13]UML 2.1.1 Superstructure (formal)[/size] Specification, I couldn't actually find any reference to "Circle" notation for Interfaces.  I think it predates UML.

Anyway, my question relates to the second part of the quotation above: "Realization links to an Interface drawn as a circle are drawn without target arrows"

What it DOESN'T say is that the actual Realization edge is also drawn as a solid rather than dotted line.  This makes it look like an Association.

On that statement, I would have expected the edge to remain dotted.

So, is it an inconsistency in the help or the product?

Paolo

[RoyC]

What it DOESN'T say is that the actual Realization edge is also drawn as a solid rather than dotted line.  This makes it look like an Association.

On that statement, I would have expected the edge to remain dotted.

Paolo

And another quote from page 87 of the UML Superstructure Specification (2.1.1):

"The interface realization dependency from a classifier to an interface is shown by representing the interface by a circle or ball, labeled with the name of the interface, attached by a solid line to the classifier that realizes this interface."

We will change the Help sentence to finish with "are drawn as a solid line without target arrows."

[«Midnight»]

Which I think addresses the immediate issue.

I keep thinking there's something beneath this, some kind of secondary issue. Perhaps this feature of EA is covering two aspects of UML, and we have a push-pull conflict when both need to satisfied.

Perhaps it's just me being suspicious. I need to read through this thing in depth. In the meantime my working assumption is that I'm talking through my (Canadian-winter strength) hat (once again).

David

[Paolo F Cantoni]

And another quote from page 87 of the UML Superstructure Specification (2.1.1):

"The interface realization dependency from a classifier to an interface is shown by representing the interface by a circle or ball, labeled with the name of the interface, attached by a solid line to the classifier that realizes this interface.

Well, my copy of 07-02-03 2.1.1 Superstructure has that quote on page 89 (simple typo?). BUT more importantly relates to the use of the ball notation for the realizing classifier - not the interface itself.  It specifically refers to Figure 7.55 - which illustrates this and was left off your quote - no criticism, just observation.  EA does this correctly (as far as I can tell).

That is NOT the behaviour I'm referring to.  Create and interface (Rectangular notation, add a Realize relationship from a Class and then change the rendering of the Interface to circle.  That's what I'm referring to!

Again, I state that as far as I can (easily) see, there is NO reference to representing an Interface element itself as a Circle (using Circle notation - as described in EA's Help) within the UML 2.1.1 specification.

If you argue (and as far as I can see this is a valid argument) that the solid line is to simulate the effect of Figure 7.55 with separate elements, then the "mini" ball notation should be removed from the realizing classifier if the realized interface is on the same diagram - which EA currently does not do.  So something's crook (inconsistent) in the state of Denmark.

I'll settle for the solid line if the mini-lollipop is removed when the actual interface element is on the diagram!
[Edit 1: BTW - the same applied to the required interface socket!  Don't show if the actual interface element is on the diagram.]
[Edit 2: Oh and while we're at it... if the ball and the socket of the interface relationship are BOTH on the same diagram, the connecting dependency should also be rendered (by default) - I can remove it later if I want, but is should be there initially.]
[Edit 3 (David, the safety valve is starting to vibrate!)  What gives with the Expose Interface functionality?  It adds yet another element (for an existing interface) when it should clearly just reuse the existing one!  If you define a new interface then EA should create the interface element and the corresponding Realization or Dependency!]

Paolo [Edit 3 - going for a walk to settle the ranting function...]

[«Midnight»]

This is the suspicion I was referring to.

As to the specification, there are two versions: with and without change bars. The page numbers differ. Perhaps that is the alignment issue.

David

[Paolo F Cantoni]

As to the specification, there are two versions: with and without change bars. The page numbers differ. Perhaps that is the alignment issue.

Yes, probably - mine has change bars -maybe we should use section numbers...

Paolo

[RoyC]

No, I'm sorry Paolo, but Figure 7.55 distinctly shows the interface ISensor (ball) attached to the Classifier ProximitySensor (rectangle). On page 88 (in my copy of the spec, probably 90 in yours; I have the 2007/02/05 edition) there are illustrations of the alternative notation of the interface ISensor, i.e rectangular notation (figure 7.57) with your expected dotted-line realization.

[Paolo F Cantoni]

No, I'm sorry Paolo, but Figure 7.55 distinctly shows the interface ISensor (ball) attached to the Classifier ProximitySensor (rectangle). On page 88 (in my copy of the spec, probably 90 in yours; I have the 2007/02/05 edition) there are illustrations of the alternative notation of the interface ISensor, i.e rectangular notation (figure 7.57) with your expected dotted-line realization.

Roy,

I accept what you say - and in the intervening time have updated the post a couple of posts back.  See Edit 1 and Edit 2.

But... Since "pieces of paper" don't have behaviours of themselves, it's not clear whether the "balls" represent an actual element or are merely in "loco elementis" (in place of).  

If they are the actual element, then EA's rendering is flawed since one can't select the "lollipop" and observe the referred interface's properties.  If they are merely graphical representations, then there should be no additional representation if the thing represented is already present on the diagram.

This is why consistency is SO important - it is NOT possible to argue correctness about an inconsistency!

Paolo

[Geert Bellekens]

I'm sorry Paolo, but I'd have to agree with Roy. According to my interpretation the circle/solid line is a valid representation of a class realizing an interface.
As far as I can see EA handles this correctly.

I do agree that there is something strange with the "exposed interfaces". They seem to have the same representation on the diagram (albeit smaller) but for a "provided" interface there is an element added to the modeltree. (from which it is a pain in the b... to navigate to the actual interface) Maybe I should digg a little deeper in the OMG specs to find out the specifics of these "exposed interfaces"

[thomaskilian]

Geert,
if you happen to discover any meaningful info please post the reference here. I also had my fights with the exposed interfaces. I used a strict notation with a lot of <<trace>> relations in order to get it manageable. I have a feeling in my guts that there should be a better way for handling them.

[Paolo F Cantoni]

I'm sorry Paolo, but I'd have to agree with Roy. According to my interpretation the circle/solid line is a valid representation of a class realizing an interface.
As far as I can see EA handles this correctly.

Yes Geert, I'm no longer disagreeing with that.  My point is now more related to the "Strangeness" of the Exposed Interfaces you mention below...

I do agree that there is something strange with the "exposed interfaces". They seem to have the same representation on the diagram (albeit smaller) but for a "provided" interface there is an element added to the model tree. (from which it is a pain in the b... to navigate to the actual interface) Maybe I should dig a little deeper in the OMG specs to find out the specifics of these "exposed interfaces"

By all means check the OMG specs, but I'm arguing from "first principles".  If you have an interface and its instantiating class on a diagram and the realization edge between them, then (if rectangular notation is used) you get a dotted realization and if circle notation is used the realization becomes solid - producing a "Super-sized lollipop".  My point is that this supersedes any "mini" lollipop's for that interface on the diagram.

If you agree thus far, then it follows that if I get properties on the circle, I get the Interface properties and if I get properties on the line I get the realization.  Consequently it should follow that if I delete the interface from the diagram, I should get a mini lollipop on the class.

If I get the mini-lollipop on the class, I should be able to get the properties of the interface and realization by selecting the appropriate parts of the lollipop.

OK so far?

Break for 2000 Charactrers!  SHEESH!

[Paolo F Cantoni]

Resuming ...

OK so far?

If so, then on the browser, I should get a "link" to the interface - not a new element which isn't an interface, and if I really want the realization, I use the relationships window.

EA has a related and similar problem with the (IMO) incorrect implementation of the "Assembly" between required and provided interfaces.

The diagram may look OK, but the underlying model is flawed and "(from which it is a pain in the b... to navigate to the actual interface)"

Thoughts?

Paolo

[Geert Bellekens]

Hmm, no such thing as "exposed interfaces" in the OMG specs. So search for provided/required interfaces and BINGO.
I think EA is referring to the provided and required interfaces on components in the UML spec. (8.3.1 in superstructure v2.0).
The mini-lollipop then points to the provided interfaces of a component. From the OMG spec. :

/provided: Interface [ * ]
The interfaces that the component exposes to its environment. These interfaces may be Realized by the Component or any
of its realizingClassifiers, or they may be the Interfaces that are provided by its public Ports. The provided interfaces
association is a derived association:
context Component::provided derive:
let implementedInterfaces = self.implementation->collect(impl|impl.contract) and
let realizedInterfaces = RealizeInterfaces(self) and
let realizingClassifierInterfaces = RealizedInterfaces(self.realizingClassifier) and
let typesOfRequiredPorts = self.ownedPort.provided in
(((implementedInterfaces->union(realizedInterfaces)->union(realizingClassifierInterfaces))->
union(typesOfRequiredPorts))->asSet()

So the lollipop is actually a representation of a derived association between the component and an interface realized by itself or its parts.
In my opinion that should not be a seperate element. I even think that the list of interfaces for wich you can make a "mini-lollipop" should be limited to the interfaces that are actually realized by the component.

Hope this makes some sense :-/

[Paolo F Cantoni]

So the lollipop is actually a representation of a derived association between the component and an interface realized by itself or its parts.
In my opinion that should not be a separate element. I even think that the list of interfaces for which you can make a "mini-lollipop" should be limited to the interfaces that are actually realized by the component.

Hope this makes some sense :-/

Yes,

I think we may be in violent agreement (at least that the "exposed" interface is not an element in and of itself...)

From your OMG quote, the reason why the edge changes from dashed to solid is that it is a derived association... Hence visualizing as a Lollipop.

Paolo

[sargasso]

Hi guys,

Just to make your day.

1) [Pedantry] The lollipop notation at 7.15.3 Notation (Spec 2.1.2 no changebars 2-Nov-2007) page 87 ^* represents "the interface realization dependency..."  which to me suggests that its a class adornment not a representation of the actual interface element. [/Pedantry]

2) What is interesting, in EA, is that if a lollipop is added to an embedded element on the class, say a port, then the lollipop does allow navigation to the interface operation declarations. And I mean direct navigation to the interface element, not the realizing class element.

3) I always thought that interface "exposure" was a feature of components not classes???

bruce