Click on the image below to view it full size in an image viewer !
Typically, multi-tiered applications have a client tier, a middle tier, and a data tier (often called the enterprise information systems tier).

This diagram includes one degree of Generalization, which is shown completely contained by the "focus" «wrapper» Component, in order to ensure that a tracing ComponentRealization is generated for the suppliers of each Generalization (an alternative is to show them in the parent «wrapper» Component at the very top, which can lead to graphical clutter, and does not provide as much immediate context for the more specialised elements).

The resulting ComponentRealizations have been shown verbosely - FOR ILLLUSTRATION ONLY - to indicate that the more general analysis elements like *Tier can now be traced to 2 «wrapper» Components, to both the parent and the focus «wrapper» Component.

Our attention returns now to the case of many source text «wrapper» Components referring to 'middle tier', and thus "competing" graphically for its matching analysis element. Instead of wrapping the analysis element *Tier_middle with the lower/deeper wrappers like 'The client tier consists of a client program that makes requests to the middle tier.', only the "focus" «wrapper» Component wraps it here, so that a ComponentRealization will be generated for tracing to it.

Again, just for illustration purposes, the ComponentRealizations that will be generated for deeper «wrapper» Components are also shown (don't do this during production work, it leads to graphical clutter).

Let's now bury down into: The client tier consists of a client program that makes requests to the middle tier (nested Property version)

randomness