Collect input from users of the client interface and return appropriate results from the components in the business tier.

Click on the image below to view it full size in an image viewer !
Collect input from users of the client interface and return appropriate results from the components in the business tier.

Such a big diagram for such a little sentence ! That's because it's such an important sentence, which introduces a few crucial new concepts, while also glossing over some important details, such as the matter of formatting of the results. Setting the analysis up properly now will make the later analysis and the binding to "designed" Java EE classes much easier.

Because strictly port-based engineering is used (shame BTW that a UML $Actor$ does not support Ports), the *User interacts via a stereotyped Interface representing a human-computer interaction point. Strictly speaking, the input from the user and the *Input that propagates through the system are of a different nature, however for now they'll be treated the same.

It's clear the the 'appropriate results' will in some sense depend on the 'input from users'.

We've already learnt that the *Content served to clients is formatted:

Dynamically generate content in various formats for the client

Presumably the same thing will happen with the served results. This is tentatively modelled as the business tier serving unformatted *Results which may then by formatted in the web tier, according to the format specified in the client request (or otherwise), and presumably bundled with the *Response.

It can be difficult to follow the flow of data in associative diagrams, so we now examine the same situation in a composite structure diagram.

randomness