Lollipop vs. Interface

[siaccarino]

This is confusing:
I can add an interface as a lollipop to a port but I can't describe this interface in a second different diagram in detail. I have to create a interface element in a class diagram but it has no physical relation to the lollipop. I can only connect both representations via name or "realize" relationship.

I would expect that I can drag & drop the lollipop into a class diagram and it is shown as an interface element there.

Even if I click on "..." in "Exposed Interface" dialog to assign an interface element to the lollipop: If I click to "Operations..." in lollipop context menu from project browser the operations of the assigned interface are invisible. Only if I click on "Operations..." in diagram I see the interface functions (EA 12)

It seems that this functionality is somehow broken

[qwerty]

No, it's not brokeb. The lollilop is just a rendering for aa general interface. Which interface it is must be shown by drawing a <<realize>> relation to the respective interface class. I usually show that on a different diagram, e.g. an embedded diagram of the inteface class.

q.

[siaccarino]

But why can I see the interface operations when I click on "Operations..." on lollipop context menu within a diagram and if I click on "Operations..." on the same lollipop in project browser not?

And if I have to create a distinct link between the lollipop and interface definition: why can I assign an interface definition to the lollipop via "..." button? What is the purpose of this assignment then?

[Richard Freggi]

What qwerty said.  It's the UML 2.x standard... not as use friendly as UML 1 in this case, but standards are standards...

[siaccarino]

No matter if UML 1 or 2:
It is a bug that the element context menu in project tree behaves differently from element context menu in diagram.

[qwerty]

That's not a bug. It's intentional Sparx GUI design. Please send complaints to Sirius Cybernetics Co.

q.

[Paolo F Cantoni]

That's not a bug. It's intentional Sparx GUI design. Please send complaints to Sirius Cybernetics Co.

q.

You shouldn't use a generic term in a specific context.  You're saying it's not a Sparxian bug, it's a Sparxian GUI Design.
It may well be a bug (from a human point of view) - I'll not comment on that - just the use of language.

It's Friday!   

Paolo

[matthew.james]

intentional Sparx GUI design

It might be intentional, but I must say that I find it somewhat baffling.  Good user interface design is both difficult to achieve and a joy to experience (if it's really good you won't event realise it is happening). The approach taken with EA seems to almost deliberately violate the principle of least astonishment.

[qwerty]

Paolo, whether or not it's a bug is defined by Sparx, not us users. It should be the other way round but that's how it is. Don't they (and you?) live down under?

q.