Does a class inherit Ports and interfaces

[richardf]

Am I mis-defining something here?

I have a class with a port realizing an interface.

I want to use the class in a sequence diagram and have the class's port's interface's signals available as drop down options when connecting signals to it, but they're not available.

If I drop a link to the class into a class diagram and do 'Embedded Elements' > 'Show Realized Interfaces' nothing turns up. If I drop the interface onto the diagram and make a realization connection from the class to the interface and repeat then a realized interface lollypop turns up attached to the class. And in a sequence diagram the signal appears as an named option when attaching a signal the class.

Is there a way to make the class inherit the interface realized by its port?

Thanks,
Richard.

[thomaskilian]

"Show Realized" does what it tells (wow, a consitent place in EA ) Draw a Realize relation to an interface somewhere and it will show up once you set the option.

[hermajo]

Am I mis-defining something here?

I have a class with a port realizing an interface.
....

I do have a quite similar questions. I would like to apply a port with a contract to a class and I had expected that the class would automatically realize the applies interface. Instead, it does not seem to have any effect. So I have to manually add a realize to the interface.
(I'm used this method from another vendor's UML tool, where
the port needs to be marked as 'behavioral' and the class will automatically inherit the entire interface)
Does anybody know, if there's a way to do this with EA, or if there are any plans to provide a similar functionality?
--
best regards, Joerg

[sargasso]

Richard,

I think the bit you are missing is that the interface realized by the port may not be the same interface realized by the class.  In general, the port realization may be a specific set of services provided by the class.  These may or may not be the same ones as the class realizes.

For example, suppose the class realization is a complete CRUD "interface" set, and in addition the class exposes a derived property, say "CurrentColor".  We can define several ports on the class and impose certain constraints on the port, say "UserType" that will constrain the exposed methods to, say, (A) CRU and GetCurrentColor only, (B) R only and (C) all.

We can define interface elements for A, B and C that are subsets of the CRUD interface and implement each of those as a particular port. This is supported by making each of A,B and C derive from the CRUD interface.

Then we can make each port realize the specific exposure contract we want.  But the class must realize the entire and original CRUD interface, as well as its "value added" methods and properties.

So, in short, if a port realizes a specified interface it is not encumbent on the class to "inherit therefrom".  It is only mandatory that the modeller ensure that the class can fully implement all the required services specified by the ports.

hth
bruce

...
trying to put this more simply, the class must obey the contract specified by it's interface realizations, the ports must obey the contract(s) specified by their realizations, it is up to the modeller to ensure that all of these are consistent.

[Paolo F Cantoni]

bruce,

How apposite your posting...

I think the [size=13]UML 2.1.1 Superstructure (formal)[/size] Specification  allows the ball and socket interface renderings to be attached directly to the class and not via a port.  I don't have a copy with me (@ airport at Changi).  EA certainly allows it even with strict UML set.

Earlier today I was asked when should you put the interface directly to the class and when should you use a port.  With a component it's pretty obvious you need ports (essentially for the reasons you gave above), but with a Class is there any guideline?

TIA,
Paolo

[sargasso]

I think the UML 2.1.1 Superstructure (formal) Specification  allows the ball and socket interface renderings to be attached directly to the class and not via a port.

Quite my understanding too.

ut with a Class is there any guideline?

Not that I could find.  
I was just trying to explain my (current) taking on your exact taking - when and where is "port" modelling useful.

To me, at  the class level they are a useful modelling artefact (or possibly "aspect"). They are not a directly implementable element, or alternatively (if thats not tautological) they are design time elements, useful for ellucidating certain nuances of design but perhaps not a true structural or "directly implementable" facet of the MDA.  Perhaps they should be explicitly marked "abstract", but even that does not convey the essence ...

c'est la guerre

bruce  

Reflecting further, perhaps the difference between a ball-and-socket connected directly to a class vs a ball-and-socket connected via a port is that the "port" imposes some constraints dependent on its knowledge of the connection. Alternatively, a direct connection implies that the implementation must blindly follow the local ruels of exposure whereas a port may have some intelligence of its own and hence modify its behaviour based on its knowledge of the entire environment.  By way of example, consider a firewall's ICMP rules.  The firewall will either drop (totally ignore) a ping request, deny the request or respond  to the request.  In any of these cases the firewall must implement certain behaviours at the "class" level i.e. it meets the prescribed IFirewall contract.  The way in which it either responds or not depends on the entire construct of the attempted connection. IOW, if I know you and you are allowed then I'll respond with an echo, if I know you and  you are not allowed I'll respond with a "rack off Normie" message, if I dont know you I'll respond with ().  Thoughts?