port-based engineering

Java EE Technologies Used in the EIS Tier.

Java EE Technologies Used in the EIS Tier.

The source text of Your First Cup: An Introduction to the Java EE Platform does not yet expand on these technologies, so we provide this diagram as a navigation point, then move on ..

These resources typically are located on a separate machine than the Java EE server, and are accessed by components on the business tier

These resources typically are located on a separate machine than the Java EE server, and are accessed by components on the business tier
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_Business Property, 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_Business Property.

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.

The enterprise information systems (EIS) tier consists of database servers, enterprise resource planning systems, and other legacy data sources, like mainframes

The enterprise information systems (EIS) tier consists of database servers, enterprise resource planning systems, and other legacy data sources, like mainframes

We are told that all the '(EIS) tier .. consists of .. data sources'.

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 *Get Interface 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 *Query Interface as well. This opportunity for non-exclusive redundancy is a very powerful aspect of port-based service-orientation.

Figure 02: Flowport notation for mapping UML2 to Java

Figure 02: Flowport notation for mapping UML2 to Java

Flowport notation for base interfaces and classes for port-based systems engineering with UML2 and Java implementation.

Note that this notation precedes the introduction of the formal Systems Modeling Language™ (SysML™) Flowport.

Port-based systems engineering of block models for control and simulation of Neutron Beam Instruments of the OPAL research reactor using UML/SysML

The content or the technology discussed here is HISTORICAL or ARCHIVAL
Authors: 
Kelly, D. R. C.
Year: 
2007
Publication type: 
Journal

The OPAL research reactor serves as a neutron source for diverse Neutron Beam Instruments
(NBIs) undergoing commissioning throughout 2007 by The Bragg Institute of the Australian Nuclear Science
and Technology Organisation (ANSTO) [1]. Port-based Systems Engineering (PBSE) using UML2.1.1[2] -
and more recently SysML [3] with explicit physical flowport support - has been employed to support Model-
Based Systems Engineering (MBSE) of NBIs, including reverse- and forward-engineering of Java
components, and development of XML schemas for NBI hardware components and sensor-actuator device
networks. Electronic systems, neutron flows, and vacuum systems are modelled as UML2 ports with custom
notation and SysML flowports. The NBI models thus engineered are incorporated into a ModelServer system
(implemented in Java+XML), which acts as a distributed, multi-client, control system façade that integrates
low-level, logical device interactions (via a real or simulated control system) into high-level, physical
instrument block models that support recursive control [4] and derived, controllable, physical system values.

Syndicate content