Should you type a UML Port with a Class or an Interface?

[mse]

The question may sound rather meticulous but I have a very large model an need to make a decision. What are the implications of typing a UML port with an interface and with a Class? I used to think that it was appropriate to type a port with an interface, but the more I think about and after seeing the context menu in EA, I am thinking of inserting Provided/Required interfaces in the ports. If I do that, the question then is, what is the type of the port? Are all the ports then of the same type if say I have some bus-like communication?

Take AUTOSAR for example, with its RTE virtual bus, are the ports then of type RTE because in the end, a very large module called RTE is generated and it has the function implementations for both reading and writing, not the software components themselves.

[horszasz]

Hello mse,

This is a complex issue. There is no right or wrong answer, it all depends on what you want to express with the model.

Thinking in a platform-independent approach, the port expresses an abstract endpoint where certain services are available. The services themselves are the interfaces behind the provided / required interfaces on the port. This approach does not deal with physical design, it is very good for depicting high-level communication or collaboration models, for example.

In a platform-specific approach, the port (endpoint) is the interface itself through which operations can be accessed. In this case, the design of the port may reflect the physical implementation of the endpoint.

I know what I wrote is a bit plastic, but I don’t think there is a generally correct guideline to follow on. It all depends on what (and for what purpose) we want to represent in the model.

In my modeling praxis, both aspects are modeled; platform-specific models are generated based on the platform-independent model with EA model transformation.

I hope I could help with that.

Cheers,
Gergely

[ngong]

Hi, mse, horszasz

thank you for bringing up this subject. The usefulness of ports are part of my concerns since they came up with - i guess - UML 2.0. We did not need them in former UML 1.4.
And, for me, there is no easily to grasp semantics about ports. The easy to understand similarities to a hardware connector (e.g. D-SUB-9 in case of CAN communication) did not work for me.

For naming purposes you may need a port if you want to use an interface definition more than ones for different providing components, because a port uses the namespace of the owning component, while an interface is kind of "not owned" like a data type. This is the way AUTOSAR is doing in their non-UML way of specifying.

In my embedded systems modeling practice I do not use ports at all (the same way AUTOSAR is doing in its EA models, because because they startet with UML prior to 2.0). It is such a rare case that the same interface is provided by more than one component - and I am free to use a data type instead, then - it shall not burden all my modelling work, cluttering all component and class diagrams with ports.

If you can accept that an interface (like a port) is owned by exactly one providing component - a good decision to have someone responsible for the definition - there is no need for using a port.

Some seek to describe the information exchange between components on a more abstract level than calling operations. They use ports as a place to specify the transport details.
My best pratice is to apply easy to grasp information flows instead, associated with clearly defined data types ("information items conveyed" they call it in UML).  I leave the details of information transport to some separately specified protocol definition which becomes a stereotype of the information flow.

Unfortunately EA15.1 is not completely up-to-date regarding UML 2.5.1 with respect to information flows, information items and protocol state machines, but even in EA15.1 information flows and items can be applied sufficiently for the described purposes.

Hope this helps and/or leads to more discussions.

Rolf

[mse]

Hi Rolf,

If I could somehow go back to modeling without ports I would do it especially given a project constraint that has reduced our tooling to model pretty much what amounts to UML 1.4. However, I have a hard time reconciling that with AUTOSAR. In AUTOSAR there is a concept of a port and name of the port even appears in the generated function prototypes such as Rte_Write_<port>_<data element>(). The interface name is not used.

Regarding UML and AUTOSAR, in the area of ports, there seems to be outdated information or conflicting newer information. For example, if you look in the BSW modeling guidelines for UML, in that document they write about Modeling of Services, and they show SW-Cs with ports. They however bypass any discussion on what the port type is. They also draw a strange dependency arrow from the port regardless of whether it is a required or provided port to the interface that it requires. The UML profile for AUTOSAR which was written back in AUTOSAR version 2 or earlier doesn't provide much more. The document itself has not been updated.

I briefly explored the possibility of information flows, but that also was in the context of ports. If I did model with information flows, how can I eventually map to AUTOSAR ports? How does a developer for example know that he has to configure his AUTOSAR SW-C with a certain port and interface based on information flows?

I am willing to accept the fact that only one SW-C provides an interface, because that is the case for my project. I just don't know how to proceed however.

[Uffe]

Hello,


I'm not much familiar with AUTOSAR, but in general I think a good rule of thumb is to use ports when they mean something.

That sounds facetious. I mean, if there is a reason why you would wish to organize provided / required interfaces into groups rather than just sticking them directly onto the class / component, then you should include them. Otherwise, leave them out.

If you were modelling a web server, you could for instance have certain services available over HTTP, and others over HTTPS. HTTP and HTTPS would then be ports with a number of provided interfaces (of which some would no doubt recur in both groups).

As to classifiers for ports, if you want to use those, I'd say definitely Class, not Interface. Possibly Component.

I have in the past used information flows between ports, and either assemblies or «use»s between provided / required interfaces.
Another approach is to use port classifiers and draw the information flows between those.

I'm afraid in the end it does all come down to the specifics of your model, so it's hard to give more than hints and pointers.
I will say that the number of times I've wanted to expose operations rather than whole interfaces...! I see this as a design flaw in UML.

HTH,


/Uffe