It is possible to code Java so that it admits a port-based interpretation under reverse engineering to UML. One recipe is shown in this trail.
In PortServer_ services are only ever offered via associated port implementors - never directly - and services are accessed by service accessors which trigger lazy instantiation of the the port implementors (in this case Manage_ and Serve_). These implementors can be modelled as UML2 Ports. This recipe works particularly well when using Java inner classes as the Port implementors (which I've custom stereotyped with «port»).
From the point of view of clients to the services, the port-based class only ever reveals selected aspects through interfaces. This greatly reduces coupling to implementation, and promotes opportunities for substitutability of components.
The port-based Class PortServer_ shown below is inflexible, as it relies entirely on particular implementations to type its ports. For now the point is just to see how the graphical representation of Ports maps from Java fields, for which it is of little consequence whether the implementors are considered to relay to delegates, or whether they implement provided service Interfaces directly.
However the whole point of adopting port-based software engineering is to exploit the ability of the EncapsulatedClassifier to support highly reusable, substitutable components, by decoupling the specification of provided and required Interfaces from the provision of them via Ports. Later in this tutorial trail we'll see how to represent delegation and assembly Connectors with passed Java references and with resolution of abstract port creators, and how to create a truly replaceable, encapsulated abstract port-based class. The full port-based recipe is subtle, so for now we'll use the simpler PortServer_.
Let's now see how to convert the Properties manage_:Manage_ and serve_:Serve_ to UML Ports ..
