IMPORTANT: in UML™ Parsing Analysis one sometimes has to explore a confused or unclear description in the source text, even if it leads in the wrong direction for a while; the whole point is to analyse each sentence of the source text on its own merits.

If only I had a penny for every time somebody new to the method looked at a diagram which correctly (according to the spirit of UML™ Parsing Analysis) models a somewhat confusing source text sentence, only to be told be somebody that "that's wrong"; it's right in UML™ Parsing Analysis to model what's "wrong" first, with annotations indicating possible problems, consistencies, or errors.

None of the source text sentences from the First Cup tutorial analysed yet in this demonstration of UML™ Parsing Analysis have actually stated to date whether a 'tier' is something physical (associated with perhaps a separate machine), or whether it is an architectural "layer", which may or may not be spread across several machines. It has also not been stated whether the 'business tier' is characterised by a Java EE Server, or whether indeed a single Java EE server can manage more than one tier, including the 'business tier' ! Or could in fact a Java EE Server include somehow the 'web tier' ? After all, no mention has been made yet of a separate web server, or even how the 'web tier' might relate to it. So these matters are left - most deliberately - completely open, with question stereotypes inviting later clarification, which MUST be provided by the First Cup source text (or another authoritative source text, which would be clearly indicated through dedicated, stereotyped, source text «wrapper» Components).

Consider for example the source text sentence at hand. It does not in fact say whether 'components on the business tier' are in someway also on or running in 'the Java EE server', or in fact whether (as nevertheless assumed and shown) the Java EE server ever even accesses a data store or data source !

Lastly, we have not even been told whether the 'business tier' and Java EE Server are related at all (although we can guess they are).

To represent this complex state of affairs, hybrid associative and composite diagramming is used, and I would ask readers to spend a little extra time examining this important diagram in detail.

Note in particular that both *Tier_Business and *Server have a shared *:Component_BusinessProperty, and the meaning of this sharing could by quite different for the different contexts. Likewise, the Connectors used might cross in fact many other implied Property boundaries.

For example: if *Tier_Business is in fact "part" of a Java EE *Server, then a delegating Connector from a boundary Port of the Server to a Port of *:Component_Business might logically or conceptually "cross" the business tier boundary (and this could be represented by finer delegation via it's Port); if instead the *Tier_Business is considered to be outside the JavaEE *Server (or perhaps even characterised by it), then similar will apply to its Connectors to its (shared) *:Component_BusinessProperty.

This kind of situation arises again and again when analysing technical source documents, because natural language is far less precise than the UML™. When in doubt, share !

By simply following through the UML™ Parsing Analysis process, sentence by sentence, these matters will simply "come out in the wash". However that can only happen if one resists the temptation to inject too many of one's own assumptions in advance, without reference to the source text, even if it means going a wild goose chase for a little while.

It might be tempting to allow *Datastore to provide an Interface for getting (or loading) data, however this does not meet the case where the data source is readonly; for the sake of illustration I've decided the *Mainframe analysis component will only be read, imagining we are only migrating from it, never storing new data into it.

A better solution is to inherit from an abstract *Datasource, which provides a *GetInterface via a Port, which also appears now on the *Tier_Data (a.k.a. 'EIS tier'), since it integrates all data sources and data stores (and will delegate to/from them as needed).

IMPORTANT: there is no end to the number of convenient analysis Interfaces we may include under port-based engineering, and they may freely overlap; for example, if a database supports SQL queries (which may be used to store and/or load data), there is no reason why we can't also have a *QueryInterface as well. This opportunity for non-exclusive redundancy is a very powerful aspect of port-based service-orientation.