Sparx Systems Forum
Enterprise Architect => Uml Process => Topic started by: Paolo F Cantoni on February 13, 2008, 07:27:27 pm
-
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] (http://www.omg.org/cgi-bin/doc?formal/07-02-03) 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
-
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."
-
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
-
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...]
-
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
-
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
-
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.
-
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
-
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"
-
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.
-
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!
-
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
-
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 :-/
-
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
-
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
-
3) You're probably right. And EA offers the exposed iface icon only in the components toolbox.
-
1) Just to top the [pedantry].. In my spec (just dowloaded the 2.1.2 no changebasrs 2-11-2007) the topic is numbered 7.3.24 (I don't even find a 7.15.3). Anyway, I think you better quote the whole paragraph there:
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 (see Figure
7.55).
The important part here is "representing the interface by a circle or ball". So we are representing the actual interface. (or we should be)
3) Indeed that is exaclty what I use it for, but I don't think it is really relevant to the discussion. Whether it is on a component or a class doesn't really matter. It still feels a bit akward.
-
(just dowloaded the 2.1.2 no changebasrs 2-11-2007) the topic is numbered 7.3.24 (I don't even find a 7.15.3).
Geert, absolutely correct! With all the versions around now, I guess I was just looking at the wrong one.
What I'm (still pedantically) trying to say is:
"The <<connection>> between the <<bicycle_rider>> and the <<bicycle>> is shown by representing the <<fish>> by a <<squiggle>>".
(Which makes about as much sense!!) However the point I am trying to illuminate, is that the <<squiggle>> represents the connection not the <<fish>>.) But, heh! I am the last person to suggest that a committee can speak English.
(Sigh) The 1.3 spec, as self-contradictory as it was, was at least "readable".(/Sigh)
bruce
-
BUT! To get back to the core issue.
If (and only if), I am correct in that the lollipop notation represesents the realisation and not the actual interface, then, there is no reason why you cannot have n classes adorned with the same realisation and an element describing the actual interface on the same diagram.
We could have lots of different, say "textboxes", on a diagram that all realise "_I_am_a_textbox". A red one, a blue one, perhaps even a duggite one. There is no reason that I can see that one cannot include an element ("round" or square) on that diagram that describes in detail the actuality of the interface.
So Paolo, I concur, in fact I disagree!
bruce
-
3) Indeed that is exaclty what I use it for, but I don't think it is really relevant to the discussion. Whether it is on a component or a class doesn't really matter. It still feels a bit akward.
There is actually a big difference between exposure and realisation between the class and the component. I have writ much elsewhere, but between you and I, I still aint too sure what they were gettin at.
bruce