Does UML allow to create ports for interfaces.For instance,I have an interface MyInterface which is realized by two classes A and B.Is it right approach to create my port on the interface so that all my classes realizing from that interfaces could implement it ?

Any suggestions ?

BR/Rad

Raddy, it's not obvious what you are asking.

A port is not an interface but can be 'typed' by the interface(s) it provides/requires.

Perhaps you could express you're question through an example to clarify.

just looked through this post and I think it's an interesting question ..

imaging that you have an Interface and you add a port to it ...

can another class inherit from it from that interface ... so that it will be also inheriting the ports from that interfacse .... is this supported by UML2.1 ? ... is this possible with Rhapsody ?

[quote="Bob Senegal"]imaging that you have an Interface and you add a port to it ...
quote]

Raddy - Is this what you're asking?

There's nothing stopping you from doing this but the resultant interface would no longer be a conventional interface. As described in the UML part of the Rhapsody Essentials course provided by I-Logix:

An interface is a named collection of operations
UML interfaces specify only messages or operations
UML Interfaces have no implementation and generally have no attributes

Whereas a Port is described as follows:
Ports are “named connection points”
Ports allow a part to provide an interface across the boundary of its enclosing structured class without revealing to the client of the service the internal structure of the structured class
Client “talks to” the port without internal knowledge
Ports are “typed by” their interfaces
Provided interfaces
Required interfaces
These interfaces can consist of synchronous and / or asynchronous operations

So an 'interface with a port' is a hybrid concept. From my own point-of-view it is something to avoid as it doesn't help to simplify. It's likely to take you down the same road as inheritance-overuse. Inheritance is a good way to make simple things complicated. (not to be confused with realization which is infinitely good)

Perhaps your question is more straight-forward, if so is the attached overview of interfaces and ports useful?

The two questions are:
1. Is this possible with Rhapsody
2. Is this valid UML 2.1

I will try to answer both of these, starting with question number #1 first: is this possible with Rhapsody?
As it turns out, in a recent project I tried to create an Interface with a Port attached to it. The goal was to have the classes that realized this Interface also "inherit" the Port. The reasoning behind this was not quite straight forward and I will try to explain it below, but the short answer is that Rhapsody in C does not generate code correctly for this. I contacted tech support and was told that this does work in Rhapsody in C++. They filed a Defect on my behalf.

I admit that attaching a Port to an Interface is a strange concept and I will now try to explain why I even tried it in the first place.

What I really wanted to do was use a Port so that two classes can communicate across it without either class explicitly knowing who or what is attached to the other side of the Port. A pretty typical use for Ports. However, there is a pretty sever limitation in Rhapsody in C:

Rhapsody in C can only generate code for Ports with events, not events and functions.

For my application, I wanted to be able to make function calls and send events across the Port. Unfortunately, this was impossible. Further more, the only form of inheritance that is supported in Rhapsody in C is through realizing an Interface. However, an Interface can only contain function calls (not events). Simple enough, I thought, and tried adding a Port to the Interface so that each class that realized the Interface would contain the same Port. The code that was generated did not compile. However, it only took a simple tweak to the generated code to get things working. It looked like a name mangling bug in the code-generator, nothing else.

I sent tech support an email and was told that it works in C++, and therefore he believed it was a defect in Rhapsody in C. I didn't think much of it until I saw this post here. In fact, based on the timing of my tech support email and this post - I had a suspicion that raddy may have been my tech support contact . :) If anyone is interested in the final work-around I adopted let me know - maybe I'll create a new post as this one is getting too long already.

After seeing this post I was prompted to research the answer to question #2: is this valid UML 2.1?
Based on my current understanding of the UML superstructure document I believe the answer is NO. However, I am continually confused while reading said document and wish it was as easy to read as the ISO C standard.

Here is my reasoning. (All quotes and references are to UML Superstructure document version 2.1.2)

Section 9.3.1 defines Class. If we look the the hierarchy of Class we can see it looks like this:

Classifier <- StructuredClassifier <- EncapsulatedClassifier <- Class

Likewise, the hierarchy of Interface (7.3.24) is:

Classifier <- Interface

Note that Interface bypasses EncapsulatedClassifer and StructuredClassifer.

Interface has the following Associations:
- ownedAttribute: Property
References all the properties owned by the Interface. (Subsets Namespace::ownedMember and Classifier::feature)
- ownedOperation: Operation
References all the operations owned by the Interface. (Subsets Namespace::ownedMember and Classifier::feature)
- nestedClassifier: Classifier
(References all the Classifiers owned by the Interface. (Subsets Namespace::ownedMember)
- redefinedInterface: Interface
(References all the Interfaces redefined by this Interface. (Subsets Element::redefinedElement)

So it is clear that an Interface can have attributes and operations. But no mention of Ports.

Furthermore, if we look at EncapsulatedClassifer (9.3.8), we see that its description is:
Extends a classifier with the ability to own ports as specific and type checked interaction points.

and has the new Association:
/ownedPort: Port [0..*]
The set of port attributes owned by EncapsulatedClassifier. (Subsets Class::ownedAttribute)

OK, even more proof that a Class can own a Port (because it inherits from EncapsulatedClassifier).

This seems pretty good. But I still have some questions. This goes back to my statement about not always understanding the Superstructure document.

Question 1:
If we look at Classifier, which Interface inherits, there is one attribute that stands out:
/attribute: Property

If we look at Port (section 9.3.11) we see that it inherits from Property. Strange. So why can't a Port just be an attribute of Classifier? and therefore an attribute of Interface? What is so special about EncapsulatedClassifier that it magically allows classifiers to own Ports?

Question 2:
If we look at the definition of EncapsulatedClassifer (9.3.8) we see that the Association /ownedPort, is derived (the / in front of it) and that it subsets Class::ownedAttribute. I don't see how EncapsulatedClassifier subsets something in Class when EncapsulatedClassifer has no inheritance path through Class?

I'm not sure that you actually addressed the reason from a modeling point-of-view.

An Interface is always defined from the User's point-of-view and should never be infected by its potential realizers. Adding a Port to an interface is of no use to its user, only its realizers.

Taking this stance, the next question might be, what should you do when you suspect that all realizers of an interface contain common functionality?

My answer would be to factor out duplicate functionality into a common class and make it a part of each of the realizers. This common class would have the port in this case.

aka Aggregation vs Inheritance

Inheritance should lose every time when it is actually realization.

As an aside:
I don't like the term inheritance. Even to native english speaking people it is confusing as it has different meanings depending on context. The only nailed-down meaning in our Systems/Software world exists as a mechanism in C++ but that mechanism can be used to achieve both realization and extension. It is better to use these terms in preference to the generic term inheritance.

BTW:
The original intent of 'Inheritance in RiC' was, and still is, an attempt to provide realization. Raising a defect on not being able to put a port on a RiC interface was perhaps a way to bring your support call to a conclusion. It may be that it never gets 'fixed'.

For the record, I don't work for I-Logix, Telelogic or IBM.

What I was trying to accomplish was a set of functions for the user to call (the Interface) and a set of interrupt-style events or notifications sent back to the user asynchronously (through the Port). In this case I do think the Port is of value for the user. I admit I am very new to UML and don't fully understand how to model some of the concepts. Any thoughts would be greatly appreciated.

As a reminder, I originally wanted to use just a Port between the two classes, but RiC does not support both synchronous and asynchronous calls across a Port.



This is the solution I ended up implementing. I created an InterruptSender class that contains the Port. I put the aggregation association on the Interface class. I'm not sure if you would create that association on each of the realizers, but since it is common I put it on the Interface.

I have a hard time agreeing with you that common behavior should use aggregation instead of inheritance. I only did it in this case as a work-around (to my first work-around). When realizers share common operations/attributes they are certainly inherited, why should it be any different for functionality?


Now that I believe that putting a Port on an Interface is not even valid UML, I hope they don't "fix" it. The proper fix would to not allow it to be drawn. Or at the very least issue an error/warning during model check.

Is it a publisher/subscriber (or callback (or observer) ) pattern?

If so, the User of the publisher's Interface must realize a subscriber's interface to receive updates. The connection from the publisher to the subscriber is made dynamically at run time. The subscriber calls the publisher's interface to register and passes itself as a parameter. The connection from the subscriber to the publisher is often done via a port. The publisher typically then stores that 'subscriber' parameter (perhaps in a list if it can have more than one) to callback when things change. A Port is not needed for the return calls. Ports are used for static connections to be made at link time.

So an implied relationship from the Publisher interface to the subscriber interface exists but the subscriber interface is commonly defined as a nested interface Publisher::Subscriber.

A basic guide is that if you have to hand code the connection of a port then it shouldn't have been a port.

Hey, why C? C++ makes things so much more straightforward.

In my case I think a publisher/subscriber pattern would involve too much overhead. The Interface class I have set up is a Hardware Abstraction Layer (HAL). The idea is that the application can be paired with different hardware implementations by simply replacing the Hardware class that realizes the HAL Interface. For any given deployment there will be the Application object linked to one of X Hardware objects. The relationship is always 1:1 and does not change during run time.


What do you mean by "hand code". I am connecting the Port by drawing a link between two objects and their Ports. Depending on which hardware is targeted the link is attached to a different Hardware object.


I wish I could use C++, it indeed would make things much easier. I am doing automotive work and our company still wants the generated code to be in C, and MISRA compliant. Also, some of our target platforms don't even have C++ compilers.

Each of the hardware implementations needs a port that provides the HAL interface. Your core application has a port that requires the HAL interface. You then create a build variant for each hardware set by creating an 'outer' Core_ConcreteHardware class in which you instantiate the core and the concrete hardware and connect the ports.

OK, then why would the HAL need a port?

Sorry about the C

I have to admit I purposely avoid projects that involve safety, misra, C, Ada etc. I used to work in that sector but it frustrated me to the point that I took a 50% pay cut in 1999 just to get out.

I don't know what the answer is for safety systems development going into the future. They'll have to bite the bullet at some point you would have thought but that's a discussion for another thread perhaps.

That was precisely my original intent. As I said, my current solution is a work-around. I want my HAL Interface to have both synchronous and asynchronous calls. A limitation of RiC is that Ports can only have asynchronous calls.

The work-around was to create the HAL Interface to provide the synchronous calls and each hardware class realizes the HAL Interface. The Port is to send asynchronous events from the hardware classes to the application (interrupts and notifications, etc.). In the end the application has an association with the HAL Interface (to make the synchronous calls) and a port that connects to the hardware classes (for asynchronous messages sent from the hardware). I hope this is clear.

It's not that clear to me yet. Bear with me, it's probably because I'm not using RiC and I'm missing something specific to that.

I'm seeing 2 interfaces, HALServices and the HALUpdates. I'm not sure why HALServices needs a port that requires HALUpdates. I can see that something that realizes HALServices may well have a port but why is it necessary to put it on HALServices? I can only assume that HALServices is not a pure interface and has coded behavior that utilises HALUpdates.

You are right; there are essentially two Interfaces: HALServices and HALUpdates.

Initially I wanted them to be used across the same Port that connects the application to a specific HAL implementation. However, as I said before, RiC does not allow synchronous function calls across a Port (as HALServices requires). Therefore, I created a HALServices Interface which is not tied to a Port, but rather is used as an abstract base class for the HAL implementations. I also have a Port that requires the HALUpdates Interface for all the asynchronous signals sent from the HAL to the Application.

My thinking was that since each class that realizes HALServices needs to have a Port that requires HALUpdates - this should be part of the HALServices Interface to ensure that each implementation provides such a Port. It is not that a class that realizes HALServices CAN have a Port, but it SHOULD have a Port.

My current implementation looks like this:


I use UpdateSender, and its association with HALServices, to tie HALServices and HALUpdates together.

When implementing a HAL, a class realizes HALServices, and now has a HALUpdates Port (through UpdateSender).

Alternatively, I could remove UpdateSender altogether and simply add the HALUpdates Port to each HAL implementation manually - but that seems to be very non-OO. If every implementation of the HAL must have the Port it should inherit it (through realization).

Interfaces are always specified from the User's point-of-view. The fact that a realizer of this interface will always have a port to send back 'updates' is not relevant.



It is OO.

Perhaps you think this way because your interface is influenced by the expected implementation. There is evidence to suggest this because it is already named based on the implementation. HALServices implies that the services defined by the interface will be implemented in hardware.

Perhaps your HALServices interface has operations like:

EnableBrakeLights()
DisableBrakeLights()
ToggleLeftIndicator()
ToggleRightIndicator()
StartHorn()
StopHorn()

and HALUpdates has events like:

evAirBagDeployed()
evRainSensorUpdate(value)
evRevCounterUpdate(value)

OK the HALServices may be implemented by a Hardware device handler layer but, so what?

Why can't HALServices be called CarServices, better still, I'd split things as follows:

<<interface>> BrakeLights
Enable()
Disable()

<<interface>> IndicatorSet
ToggleLeft()
ToggleRight()

<<interface>> Horn
Start()
Stop()

<<interface>> Airbag
evDeployed()

<<interface>> Sensor
evUpdate(value)

Much more flexible.

Interface-Segregation Principle - that's exactly what OO is all about.

http://www.objectmentor.com/resources/articles/isp.pdf

I know this view can seem like a trivialisation of the real-world situations software developers have to deal with and therefore it often gets dismissed. I'm not going to argue with anyone that disagrees about it being the best approach to get to a simple, clean, portable design. Like many software things, it's hard to explain to those that don't do it and taken for granted by those that do.

I understand you're constrained somewhat by RiC but the principle of interface segregation can still be respected to a degree even in non-OO environments. Java programmers (of which I am not) just know it because that's what Java is all about (or should be).

As an aside, if you are really providing an Adapter-Layer then the HAL will be a set of interfaces, like the above, and an abstract factory that your application will use to create/access the concrete implementation for that 'build'.
The OSAL (operating system AL) in Rhapsody demonstrates this pattern.

You might be right. I may have been confusing implementation with which interfaces or services are required. I need to spend some time to rethink my approach.