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

Assembly connections as Java references to services

One interpretation of "assembly connection" in a Java system is the passing of a reference to a required service Interface.

This is illustrated in the following code, where references to the Manage and Serve Interfaces are obtained from the port-based PortServer_ (via an Interface PortServer) and passed to the port-based classes Administrator and PortClient on construction (in lazy instantiators), which in turn pass those references to their Ports' constructors. This approach combines well with cascading lazy instantiators, so that the entire creation and wiring up of the system is triggered in the top-level system constructor in advance (if desired) or as and when needed.


public class PortBasedComposite {

private PortServer_ server_;

@Lazy
protected PortServer server() {
if (server_==null) {
server_ = new PortServer_();
}
return server_;
}

private PortClient client_;

@Lazy
protected PortClient client() {
if (client_==null) {
client_ = new PortClient(server().serve()); //connect !
client_.printNameOfThing();
}
return client_;
}

private Administrator administrator_;

@Lazy
protected Administrator administrator() {
if (administrator_==null) {
administrator_ = new Administrator(server().manage()); //connect !
}
return administrator_;
}

public PortBasedComposite () {
administrator();
client();
}

public static void main(String[] args) {
new PortBasedComposite();
}
}


There are however some problems with this naive strategy:

  • A UML Interface does not have Ports, so a symbol of a Property typed by Interface PortServer in a composite structure diagram can't show Ports; the server with ports is not well encapsulated.
  • The Ports of the port-based classes seem to be bound to particular implementations of provided and required Interfaces.
  • While the "Connector as reference" approach works ok for simple Ports that provide 1 Interface, it turns out that it does not scale well to complex Ports.

What is needed is a better abstraction of the port-based contract than is possible with a UML Interface, as well as abstract Port implementors that define only what Interfaces are required and provided, without stating where or how they are required and provided, so that they can be flexibly delegated to different internal parts with Ports.  For this purpose a new example and some useful terms and definitions will be introduced ..

Search
MagicDraw UML for Java software engineering