Click on the image below to view it full size in an image viewer !
Many different types of applications can be Java EE clients, and they are not always, or even often Java applications.

It turns out that the «JavaEE» stereotype was applied a bit too eagerly; either it has to be removed from the *Client that interacts with a Java EE server, or it can be clarified through analysis annotations, as shown above.

Instead of changing the analysis model, the «JavaEE» is now defined to mean something that can participate in a complete JavaEE application, not something written in the Java language (for which the stereotype «in Java» is introduced). The basic JavaEE *Client is characterised by a Port that requires (Usage) a «JavaEE» Interface *Serve_ via a Port.

Compare the two different analyst's annotation forms shown in parallel:

  • The "1st order" form of UML™ Parsing Analysis uses only a Comment with graphical handles to relevant analysis elements, which is NOT a Relationship, so there is only suggested binding through placement in the diagram, there is no traceable binding to the relevant analysis element.
  • The stronger "2nd order" form of UML™ Parsing Analysis used a «wrapper» Component for the analyst's annotation, which then generates automatically a ComponentRealization to the stereotype element it wraps and clarifies, which can be traced also indirectly from the outer «wrapper» Component with the source text.

BTW the older 0th order form of UML™ Parsing Analysis used UML Notes, which are not even true Elements and are not in the repository, and it should now be avoided completely.

Visit also
randomness