UML Parsing Analysis

The Enterprise Information Systems Tier

The Enterprise Information Systems Tier

Just a navigation point for the data tier analysis.

Java EE Technologies Used in the Business Tier

Java EE Technologies Used in the Business Tier

These are not elaborated yet in the "first cup" tutorial, so we'll just move on.

In a properly designed enterprise application, the core functionality exists in the business tier components (composite structure diagram)

In a properly designed enterprise application, the core functionality exists in the business tier components (composite structure diagram)

The analysis model - as driven by the source text - is not converging in the business tier. Perhaps it's best to return to this later with insights gained from the first cup demonstration application.

In a properly designed enterprise application, the core functionality exists in the business tier components.

In a properly designed enterprise application, the core functionality exists in the business tier components.

Before the source text is analysed within a «wrapper» Component, a large part of the previous analysis regarding enterprise applications are tiers is repeated. If we assume that a Java EE application is 'properly designed' and is also a 'typical tiered application' (as previously described) then we can trace (albeit somewhat indirectly) from *Application_JavaEE (which is also an *Application_Enterprise) to *Tier_Business, without adding any additional Generalization.

Although the 'core functionality' seems already well placed in *Function_business it's still not clear from the first cup source text whether this is the same as 'business logic' mentioned elsewhere, indeed 'functionality' and 'logic' seem to have been used interchangeably, or at best indistinctly or vaguely. For example, policy is often well decoupled from functionality, and can be separately "injected" to affect the logic of an application.

To track the matter, a question analysis «wrapper» Component is introduced with Dependencies to elements of interest.

Associative diagrams like this can be hard to understand, even for UML experts, so let's now look at a consistent representation of parts of this as a composite structure diagram ..

Business logic is code that provides functionality to a particular business domain, like the financial industry, or an e-commerce site

Business logic is code that provides functionality to a particular business domain, like the financial industry, or an e-commerce site

Here we are told that 'Business logic is code', which can be represented in at least two ways in the analysis model:

  1. As a code artifact, presumably something that is executable, and which serves to "realize" a business component, at least partially.
  2. As a UML Class model element, that must be either consistently forward or reverse engineered to/from code.

Presumably these provide only part of the functionality of a business component, which can perhaps be "manifested" in its entirety by a Java class.

Also shown is a quick attempt at a domain model for (somewhat eponymously) domain models, including business domain analysis, inspired by definitions at http://www.businessdictionary.com.

For the sake of analysis, the *Logic_Business class provides (via a Port, as always under the port-based form of the UML™ Parsing Analysis recipe) a *Function Interface, which might turn out to be the same as the *Logic Interface provided by the *Component_Business anyway.

Lastly, because I (Dr Darren) am a scientist, and because it is so very well known that scientists know absolutely nothing about business, ecommerce, productivity, or industry, I've included a separate *Domain qualified by the (analysis.science) namespace, which obviously has nothing at all in common with the business domain at all, except a very abstract base *Domain.

The business tier consists of components that provide the business logic for an application

The business tier consists of components that provide the business logic for an application

It is now apparent that the original model of the 'middle tier' gleaned from analysis of previous source text snippets was naive; the business functions do not directly serve clients (as immediate delegates of the middle tier), rather they provide logic within the business tier (as part of the middle tier), which is quarantined from direct client requests by the web tier (another part of the middle tier).ms

The type of one of the Ports of *Function_business is stereotyped as an ERROR (yet left in the analysis for tracking on previous diagrams).

So is the *Logic Interface provided by the business components the same thing as the *Serve if provides to the web tier ? More information is needed.

The Business Tier

The Business Tier

Just a navigation point for the business tier analysis.

A set of standard tags used in JSP and Facelets pages to refer to Java EE components

A set of standard tags used in JSP and Facelets pages to refer to Java EE components

This source text sentence and analysis until now leave a lot of questions open:

  • Is there some kind of "Java EE page" Artifact abstraction that would unify JSP and Facelet pages ?
  • How - if at all - do JavaBeans and the user interface components of JavaServer Faces relate to 'Java EE components' ?
  • Are the Expression Language tags defined in the JavaServer Pages Standard Tag Library ?
  • 'Facelet applications .. use XHTML pages'

These might become clearer when executable examples from the First Cup tutorial are examined and related to this analysis.

Facelets applications are a type of JavaServer Faces applications that use XHTML pages rather than JSP pages.

Facelets applications are a type of JavaServer Faces applications that use XHTML pages rather than JSP pages.

It seems reasonably clear now that:

  • All JavaEE applications are (at least) web applications.
  • JSF applications are J2EE applications that use 'JSP pages' (although it is not clear what kind of JSP pages)
  • 'Facelet applications .. use XHTML pages'

Something is still a bit suspicious; why isn't there a nice "ladder" between the application types and the page artifacts ? More information is needed.

A user-interface component framework for web applications that allows you to include UI components (such as fields and buttons) on a page, convert and validate UI component data, save UI component data to server-side data stores, and maintain component st

A user-interface component framework for web applications that allows you to include UI components (such as fields and buttons) on a page, convert and validate UI component data, save UI component data to server-side data stores, and maintain component st

The source text sentence is nearly as long as a Thomas Mann novel:

A user-interface component framework for web applications that allows you to include UI components (such as fields and buttons) on a page, convert and validate UI component data, save UI component data to server-side data stores, and maintain component state.

"Divide and Conquer" is our very good friend.

It's not clear (yet) whether a JavaEE application is a kind of 'web application', or whether a 'web application' is a part of a Java EE application.

Is it possible that a *JavaBean acts as a datastore to which 'UI component data' is saved ? And is saving the same as storing (permanently) ?

Also,it may be that the first attempt at a *Datastore model was naive, assuming that it only stores application data. Is 'UI component data' a special kind of application data, or should there perhaps be a more general *Data that both extend ?

Finally, since there are no candidate Classes mentioned that could 'convert', 'validate', or 'maintain component state', for the sake of analysis the *JavaServerFaces technology provides these services as interfaces.

Syndicate content