Click on the image below to view it full size in an image viewer !
Java EE application development concentrates on the middle tier to make enterprise application management easier, more robust, and more secure.

Such a big diagram for such a little sentence ! What's going on ? Massive reuse of analysis, that's what's going on, driving the analysis model towards convergence, under port-based engineering. Let's break it down to understand why there is so much implied detail, and how it helps setup the analysis system so that in later diagrams we will have less and less work to do.

If you don't have a cup of tea or a coffee or a beer or a glass of wine, now is the time to fetch one.

Port-based engineering - like service oriented architecture - is highly verb/action oriented, so the notion of 'management' will be handled as an Interface *Manage grouping management services, provided via a Port, which is typed by the abstract *Manage_, and belongs to a very general *Application, because there is no need to assume that only enterprise applications need to be managed.

It is assumed that an application is managed by a Developer Actor, which requires the Manage Interface.

By the way, since an Actor can't participate in a ComponentRealization, a Dependency FROM the «wrapper» Component is used, and the graphical containment is only contrived; a stronger solution for the UML™ Parsing Analysis recipe is to introduce an extra actor stereotype for Class.

It is claimed that 'Java EE application development .. ' can 'make enterprise application development management easier, more robust, and more secure'. Since we don't yet have strongly defined analysis elements for concept such as security, the analyst has decided here to instead use simple boolean attributes to express the claim (although one could easily use a finer measure of effectiveness (MOE) approach common in systems engineering). The interpretation offered is that the concrete Java EE analysis version of *Manage_ (distinguished by its unique owner namespace) offers attributes '?robust', '?secure', '?easier' with default values true, expressed as redefined Properties.

The Java EE version of *Manage_ can be modelled as "injected", or perhaps being fetched from a local PortFactory. One way to think of it is as pointers, or Java references. The *Application_JavaEE holds a reference to its local *Manage_, and the inherited Port typed by it is forced to delegate to it by reference assignment. From the outside all that is known is that the Port provides $Manage$. Through this port-based injection magic the Java EE application will offer secure, easier, robust management services.

Both the Class *Manage_ and the Port it types are shown realizing the same Interface, both for illustration purposes, and so that the «wrapper» Component can bind to *Manage_; you needn't show this in most diagrams.

So far the First Cup source text has been a bit vague about tiered applications, enterprise applications, and typical tiered applications, without ever saying whether a Java EE application is always a typical tiered application and whether enterprise applications are in fact all tiered (as assumed). For the moment multiple inheritance is used, at least until further details come to light.

And lastly, since the data tier and client tier are not the subject of this wrapper, they appear outside it, and are neither logically nor graphically grouped by it (whereas many other implied analysis elements are).

Phew, so much to do already ! But don't worry, there is a good reason for it. We are setting up a very powerful system, and when it comes to mapping these analysis classes to design classes reverse engineering from actual Java EE, this effort will be rewarded ten-fold, at least. I promise. Get another drink, you've earned it.