Java EE

The clients make requests to the server

The clients make requests to the server

Although the source text only mentions concepts we've already met, this is a good opportunity to introduce a JavaEE version of the *Request, and to assign it to a Connector as conveyed information of an InformationFlow.

The sense of flow from the client to the server can be made stronger by using a mini scenario with Properties typed by Nodes, with a Connector to carry the *Request as conveyed information.

Also, to bind it to the «wrapper» Component, the new *Request must appear as a wrapped Class, since the «wrapper» Component does not "see" the InformationFlow directly.

The client tier consists of application clients that access a Java EE server and that are usually located on a different machine from the server.

The client tier consists of application clients that access a Java EE server and that are usually located on a different machine from the server.

Since the source text refers to a 'machine' the UML Node has been used. (And BTW, yes I do realise that I might therefore have better used an implementation diagram here.)

So far only Classes have been used for analysis, however since a Component is a special kind of Class every part of the UML™ Parsing Analysis recipe that was shown so far also applies just as well for Component (roughly speaking), and we can "promote" any desired analysis Class to a Component in order to benefit from its extra capabilities, such as being able to contain a Node. This has been done for *Tier_Client above.

The source text is a bit inexact; previously 'client' was taken in the most general sense, and now it is used to refer to interaction with a specific kind of server, a Java EE one. This is handled by a Generalization "ladder", with the more concrete (less abstract) JavaEE elements stereotyped (and presumably in a separate namespace).

It is assumes that the when the machine dies, the client program dies, so the *Client Node composes strongly the *Client client program, whereas the *Tier_Client is now only considered to share it (loose aggregation).

Finally, the 'access' is assumed to be via the *Serve Interface, strictly modelled in port-based fashion.

*Application_Tiered_typical

*Application_Tiered_typical

Before moving on to more detail, let's see how the model is converging so far, by examining a composite structure diagram from on analysis Class, which shows the flow of some of the information implied by the source text descriptions, modelled using port-based engineering.

We can also bring some of the information from existing source text «wrapper» Components into the diagram as instance-like Properties typed by the wrappers, which does show the text nicely, and with a little effort we can relate it to the analysis Properties with Dependencies, however this is in fact repeating work already done elsewhere in more automated fashion, and it also pollutes the Property space of the analysis element.

Java EE application development concentrates on the middle tier to make enterprise application management easier, more robust, and more secure.

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.

The middle tier's business functions handle client requests and process application data, storing it in a permanent datastore in the data tier: NESTED PROPERTY FORM

The middle tier's business functions handle client requests and process application data, storing it in a permanent datastore in the data tier: NESTED PROPERTY FORM
For illustration only, DO NOT show all ComponentRealizations like this in production modelling !

Here the nested Property approach has been chosen, with an explicit, manually introduced Dependency FROM the «wrapper» Component TO the analysis element.

The middle tier's business functions handle client requests and process application data, storing it in a permanent datastore in the data tier.

The middle tier's business functions handle client requests and process application data, storing it in a permanent datastore in the data tier.

This complex diagram (which we'll see later in more friendly form) shows an "unwrapped" «wrapper» Component with the automatically generated ComponentRealizations, along with redundant representations of Properties as Association ends and in structure compartments, just to enable study of the challenge of tracing source text to analysis Properties

For illustration only, DO NOT diagram like this in production modelling !

Consider for example the concept 'application data', which we wish to relate to the analysis element *Data_Application in the general sense (as a Class) and in the more specific context of an instance-like Property of a Datastore, and likewise being processed by a 'business function' (*Function_business analysis element).

The Property case requires another way of tracing from the text to the analysis element (a Dependency may be used).

Typically, multi-tiered applications have a client tier, a middle tier, and a data tier (often called the enterprise information systems tier).

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)

In a multi-tiered application, the functionality of the application is separated into isolated functional areas, called tiers

In a multi-tiered application, the functionality of the application is separated into isolated functional areas, called tiers

We work through the 1st paragraph on Tiered Applications, at quite a high level of abstraction. A more specific «wrapper» Component is also shown, and provides a navigation point, without yet resolving the analysis of its source text; it is hyperlinked to its own dedicated focus diagram.

The client tier consists of a client program that makes requests to the middle tier (composite version)

The client tier consists of a client program that makes requests to the middle tier (composite version)

The composite structure of a source text «wrapper» Component can be used directly to illustrate a scenario using "instance-like" Properties typed by analysis elements. While this approach can lead to compact commentaries, it has however one huge drawback for UML™ Parsing Analysis:

This approach does not easily admit the creation of models as the union of bindings from many source text wrappers to analysis elements,
because the wrapper's Properties are unique to the context provided by the «wrapper» Component.

Nevertheless, such diagrams can make a useful contributions to interpreting a technical text as UML.

In many cases it will be found that a domain analysis element that can provide a context for reusable Properties is indicated elsewhere, which can then likewise be used to illustrate such composite structures with flows.

The client tier consists of a client program that makes requests to the middle tier (associative version)

The client tier consists of a client program that makes requests to the middle tier (associative version)

Here we see an alternative "focus" Class Diagram for a «wrapper» Component of one sentence, this time usually a purely "associative" approach, with no inline composite structure (and thus also no Connectors for delegation from/to the boundary of Ports of Classes. It certainly makes it easier to handle at least some tracing to the Classes of analysis elements mentioned, however it is not clear (unless the attributes compartments are shown) how to relate the text to Properties like :Request, and it is also harder to show some flows.

Syndicate content