Click on the image below to view it full size in an image viewer !
Tiered Applications

Already with only a few «wrapper» Components in one diagram there is a lot of graphical complexity, and a combination of analysis elements that are easily automatically related to «wrapper» Components using generated ComponentRealization (such as Classes), and analysis elements that are only related through graphical location in the diagram, or through combination with an explictly related element (such as Ports of related Classes).

An interesting case is the Request Class, which - being a Classifier - may also appear as the conveyedInformation of an InformationFlow of certain types of UML Relationships, and in the tool used here it can be applied on Connectors within inline composite structures. However, without including the Request Class explicitly in the logical and graphical grouping of «wrapper» Components that refer to it, they would not relate to it, for it otherwise only appears as a deeply nested Property, which can be manually related via a Dependency.

Closer inspection reveals that the Dependency FROM the «wrapper» Component (the 'source' or 'client') TO the Property :Request (the 'target' or 'supplier') has its head arrow in the opposite sense to the ComponentRealization between the «wrapper» Component and the Property. This is not a mistake (of the UML™ Parsing Analysis recipe), it is because in a ComponentRealization in UML2 the large arrow "head" is in fact at the 'client' or 'source' end ! This has to do with the history of UML2 and UML2 tools, and is explained in detailed in this UML™ Parsing Analysis analysis of the UML2 spec:

7.3.45 Realization (from Dependencies)

8.3.4 ComponentRealization (from BasicComponents)

For now, just know that where possible it is best to rely on an automatically generated ComponentRealization where possible.

Notice how the concept 'middle tier' appears in at least 2 different source text sentences with matching «wrapper» Components, however the corresponding analysis element can't simultaneously appear graphically in more that one «wrapper» Component, unless its symbol is repeated, which opens up another can of worms.

This is at least one reason for handling each «wrapper» Component in a dedicated "focus" diagram (usually a class diagram), which may also offer navigation points to to other types of UML diagrams (including Activity Diagrams and Statecharts for Finite State Machines). In UML™ Parsing Analysis each and every «wrapper» Component MUST be hyperlinked to at least one focus diagram; advanced UML tools offer the possibility of navigating from one UML symbol to more than one hyperlink target, and thus to any desired focus diagram type.

Besides, the diagram is already quite complex, so let's break it down, sentence by sentence ..