Book a Demo

Author Topic: UML "port" sense  (Read 8504 times)

kamil.svoboda

  • EA User
  • **
  • Posts: 42
  • Karma: +0/-0
    • View Profile
UML "port" sense
« on: June 09, 2004, 07:12:53 am »
Hi,
have you anybody example of UML "port" using? I don't understand to sense of this structural feature.
What is difference between the port and the interface exactly?
Thanks
Kamil

barny451

  • EA Novice
  • *
  • Posts: 19
  • Karma: +0/-0
    • View Profile
Re: UML "port" sense
« Reply #1 on: June 11, 2004, 09:05:53 am »
The EA help does a pretty good job of defining what a port is, but then doesn't give a very helpful example.

Ports have their roots in ROOM (a predecessor of UML from the early/mid 90s, only implemented in IBM Rational Rose RealTime AFAIK), and in ITU Z.100 SDL gates, from the early 80s.

For me, port makes most sense when used on a composite element; they represent (the only) communication points for that assembly with the outside world.  A composite element can be assembled into another composite element (as a part), which is the same thing as saying that a composite element may itself be an assembly of other composite elements (as parts).

Ports realise interface class(es), which specify and constrain communication through the port.  Putting a required interface (socket symbol) on a port specifies communication out of the port to the environment, realised (lollipop symbol) specifies communication into the port from the environment.

In principle a composite element is then fully defined in isolation from the environment, something you couldn't do in UML 1.x, because 1.x didn't have the concept of 'required' interface, you ended up modelling a required interface as an association with an abstract class, then using inheritance from that class when you realised this in code.  Same effect in the end, I suppose, but fairly opaque.

In other words, along with composite elements, ports allow you to model hierarchical decomposition of a complex system into subsystems, subsubsystems, etc, communicating through well-defined interfaces.  Voila, Architecture in UML!

The bottom line for most people is how this turns into code.  The short answer is, it doesn't AFAIK unless you use Telelogic UML 2.0 tools where they have full code-generation, i.e. into a framework which understands ports and architecture.  I guess this is what Rose Realtime did from ROOM+UML 1.x.  It certainly doesn't map onto vanilla C++.  I don't know how EA generates it (if it does at all).  Anyone help?

HTH
Ian

kamil.svoboda

  • EA User
  • **
  • Posts: 42
  • Karma: +0/-0
    • View Profile
Re: UML "port" sense
« Reply #2 on: June 14, 2004, 06:28:31 am »
Thank you for your reply!
The port looks like very usefull element in this sence. Examples of usage would be very important.
Perhaps somebody put one.
Kamil

peter

  • Guest
Re: UML "port" sense
« Reply #3 on: July 09, 2004, 09:45:01 am »
Hello,

In the context of Java,
I could imagine, that a "port" may be realized by dynamic proxies.
Since the concept declares that the caller may only talk to the callee through ports, they may be realized as interceptors.
So a "port" may also represent the stubs and skels generated by EJB containers for EJBs.
Can you agree with this point of view?

peter



Javier

  • EA User
  • **
  • Posts: 67
  • Karma: +0/-0
  • Necessity is the mother of email
    • View Profile
Re: UML "port" sense
« Reply #4 on: November 11, 2004, 12:06:29 am »
Ian,

Quote
It certainly doesn't map onto vanilla C++


I believe it does, but not in the way that you most people is familiar with.  In UML Distilled, Third Edition, Fowler mentions that one of the examples was provided by James Rumbaugh, and that he wanted to show that a component does not necessarily map into a technology--e.g., a COM component.  Thus, a port can be tought of as an abstract concept to "group" a set of interfaces--perhaps semantically related.  This is rather a loose definition of a port, as the enforcement can not necessarily be made by a tool.

Another, more strict definition of a port can be tought of as a set of interfaces tied to a particular technology, specification or programming language.  For example, a set of COM interfaces (provided interfaces) and [source] interfaces (that translate into required interfaces), or as WSDL ports in a WSDL document, or a set of protocol classes in C++ (all methods pure virtual, translate into provided and required interfaces, depending on their use in a system).
We must become the change we want to see.
- Ghandi