MagicDraw UML and SysML Plugin eSchool
Motto: "Learn good ways to work with MagicDraw UML and its SysML Plugin !"
About the eSchool
UML2 in MagicDraw
MagicDraw UML tips
MagicDraw SysML Plugin
MagicDraw for Java
MagicDraw for XML
Advanced UML and SysML Training

In pure port-based engineering the Port always acts "on behalf" of its parent.

Walk up to your TV or home HiFi and turn the volume up or down:

  • If it is an old device you might have a a single volume knob as a control.
  • If it is a newer device it might have a group with volume up (+), volume down (-), and maybe also a "loudness mode" toggle if it is a HiFi.

Either way you are interacting with the device via a Port. However you are apparently changing the volume of the entire device (TV or HiFi):

The services provided via true ports always appear to act "on behalf" of the parent device.

Similarly, when you plug your headphones into the headphone socket of a device you are apparently hearing the whole device, not just the headphone Port.

(By comparison, consider now taping a small MP3 player onto the side of your TV set. There is a headphone socket, and there is a volume control group, however there is no sense in which these ports are now acting on behalf of the TV set ! Because there is no delegation from the ports of the MP3 player to the internal parts or Ports of parts of the TV.)

In Java, this effect of "ports acting on behalf of a parent" is quite easily acheived using inner classes to implement Ports, or by passing a parent reference on construction to an existing Port Class implementation that is "mixed in" to act on behalf of the parent. (We will see later exactly how this can be done in Java in the Instrument ModelServer system tutorials.)

 

Image: 
Search
UML2 Tutorial Overview [under construction]