2006-06-14: The WebEl system is going Open Source ! The SourceForge WebEl project page with user facilities complements this main WebEl project site. Stay tuned for downloads, Javadoc API, and UML models !

Feedback on this project welcome at webel@users.sourceforge.net

This project is currently supported by the Bragg Institute of the Australian Nuclear Science and Technology Organisation (ANSTO) for application to the computer systems of the Neutron Beam Instrument program of the OPAL research reactor.

Port-based systems engineering for Java and UML2.0

The WebEl system employs port-based systems engineering and signal processing idioms under model-driven development with UML2.0 to provide reflectively encapsulated and distributed control, visualisation, sonification, animation, and web re-presentation of models.

The system is documented throughout with detailed and educational exported Unified Modelling Language (UML)^TM diagrams embedded in the Javadoc API, and is consistently model-driven, employing advanced systems-engineering techniques, design patterns, and component-based software engineering.

It consists of a common All+El package - influenced strongly by the Unified Modelling Language (UML)^TM version 2.0, and popular Design Patterns - combined with a 4-layer <<boundary>> - <<control>> - <<entity>> - <<database>> architecture, and an extending signal package for signal processing via composite Processors with ports, as well as developmental import/export facilities for UML/XMI, native XML i/o, and other utility packages.

A "WebEl" is an interactive "web element" based on the underlying All+El architecture.
Although many re-presentation technologies are implemented, WebEl is used as the project name.

Throughout the system, object-oriented reuse is achieved through "horizontal" distribution of aggregated <<ports>> (as <<inner>> classes or <<mixin>> classes), which act on behalf of their "parent" classes, which act as the <<manager>> or <<engine>> of the wrapping component with ports. Services can ONLY be accessed via ports, which are accessed via the <<meta>>-interface of each component to trigger lazy instantiation of port implementors, which provide <<export>>ed interfaces that act strictly on behalf of their parent classes.

This port-based systems engineering strategy addresses the "method pollution" that direct "vertical" inheritance causes, and also manages multi-inheritance issues with ease using <<mixin>> classes. Further, since services are only ever accessed via ports, operations are presented cleanly to developers in prompting interactive IDEs, thus the ports act as menus for selecting quarantined functionality.

UML2.0 graphical representation of El Java components with ports

The port-based systems engineering strategy can be represented graphically as UML2.x components with ports engineered consistently against Java source and thus the "holon" nature of UML2.x components can be exploited directly to realise in software the component engineering that has long been natural to systems engineers of electronic and mechatronic systems.

The WebEl system is designed from the outset to interact with UML tools, and in particular with the Java-based MagicDraw UML^TM system, its Open API, and its XMI project files. Domain models and entity instances can be modelled in Magicdraw and then exported to the All+El system via XMI. And a degree of "Executable UML" has already been achieved via the system. (The systematic coding style throughout the system reflects the intention that it become increasingly a target for a form of "Executable UML".)

In the current El approach forward/reverse-engineering is done strictly on the the class and interface (which are truly model-driven), whereas the port interpretation is imposed by encapsulation with UML2.0, the ports and interfaces of which are truly model-driven. Forward engineering from UML2.0 components to Java from MagicDraw UML^TM is work-in-progress.

Q: Can I use the system with other UML tools (mainstream or otherwise) ?
A: The project is aligned with the move towards validation of XMI files from UML tools. If your UML tool adheres to OMG recommendations and specification then the WebEl system should soon be able to read your project files. The focus is - however - on support for MagicDraw UML^TM.

Together, the above features mean that one can realise systems engineering modelling of composite process networks in tools like MagicDraw UML^TM using UML2.0 components with ports and provided/required interfaces (in combination with <<meta>>-interfaces directly from the components). Combining this system engineering design idiom with a multi-representational, multi-sensual Java implementation engine is the primary objective of the All+El system.

Thus - in combination with the All+El system - UML2.x tools become "patch editors" for Java ! And - in combination with the WebEl and Java/Java3D/JSyn user interface packages - clients can interact using port-based encapsulation with models generated directly from UML2.x tools ! (This approach is strongly influenced by Darren Kelly's experience with systems engineering tools like Matlab/SimuLink, LabView, and animation tools employing channel operator "patch" systems.)

It means UML2.x compliant tools become animation (Java3D) and sonification (JSyn) modelling and synthesis network tools.

Q: Can I use this system without a UML tool ?
A: Developers can model systems and take advantage of the notification system and El entity encapsulators, the control layer, and user interface (boundary) components entirely without a UML tool. However, to take full advantage of the system, a UML tool is strongly recommended, in particular for domain modelling of entities that are wrapped by the system (you are doing domain modelling first, right ?).

Q: Can I read the docs without knowing UML ?
A: The UML images embedded in the Javadoc are designed to be educational. In combination with the Javadoc texts and many examples most engineers, mathematicians, and scientists should be able understand quite a bit. In fact, in many respects the graphical docs are easier to understand than code. UML promotes knowledge sharing.

---

Overview of the top-level All+El packages

common

The <<universal>> Publisher/All superclass pair provides for common publishing (notification) of property changes, property subscriber registration, uniform logging, debugging, XML and i/o, visitor management, and other common services, via ports that act on behalf of their parent.

The El components encapsulate the UML2.0 metamodel elements as ports, and provide a uniform interface for hierarchical representation of composed and shared aggregations of elements. The El subsystem thus distributes the "vertical" UML2.0 metamodel "horizontally" as inherited ports. The El component hierarchy effectively implements the UML2.0 metamodel, however the real work is done by aggregated ports that correspond to metamodel elements.

Together, the All+El system can already be used independent of the architectural layers
in combination with user interface (<<boundary>>)components for a wide range of applications.

---

The architectural layers

<<boundary>>

A range of user interface components for interactive control (Java Swing), visualisation (Java2D), animation (Java3D), sonification (JSyn, and dynamic web serving (XML/XSL+JSF) are under active development (and many are already used in a number of projects). The UI components are organised in technology partition packages.

<<control>>

A primary application of the All+El system is the development of UML-based instrument control systems. For applications such as scientific control systems (such as particle accelerators, neutron bean instruments,telescope control systems), control of entity beans can be "redirected" viaa low-level networked instrument control system, to impose strong control.For applications such as haptic control systems more direct controlof encapsulated models of synthesis networks can be employed, while still taking advantage of the multi-casting notification system.

<<entity>>

JavaBean entities are introspectively encapsulated as ElEntity components,being an extension of the UML2.0 InstanceSpecification metamodel element. The entity package extends the UML2.0 metamodel Property element to include explicit ElAttribute and ElReference elements, and also extends the UML2.0 Slot element to include"operation instance" slots as actions that can be invoked on encapsulated representations of entities in user interface components. Underlying "entity bean" structures need not know about the El encapsulators, or even about the common.Publisher notification system. The valuesof instances of an ElEntityProperty are carried by ElEntitySlot components, which can be configured with direct or ElControlledValue value specifiersfor mitigated control via a strong control layer. Each ElControlledValuehandles notifications ON BEHALF of the slot (property instance) of the entitybean it controls.

<<database>>

Hibernate is being adopted for the object-relational persistence integration layer and query system.

---

Additional packages and utilities

signal

Components of the signal package afford realisation of signal processing through explicit signal ports handling parameter (var) ports and connectable input and output ports. Java Processor components can implement their own signal processing, can compose sub-processors, or wrap processes realised in other languages via the Java Native Interface (JNI).

ElProcessor components can encapsulate Processor components introspectively, thus adapting them to the El system for presentation and interaction through the <<boundary>> layer.

The process package is being developed in collaboration with the Data Analysis Group of the Bragg Institute at ANSTO for reduction and processing of neutron beam scattering data, and will also by used in the next version of the Drancing gestural synthesis instrument. It is conceived as a general signal processing toolkit for Java using UML2.0 modelling.

By design, the system DOES NOT provide a process patch editor; instead, Java-friendly UML2.0 tools (like Magicdraw UML) are to be used as patch editors for the system ! XSL stylesheets and MagicDraw UML^TM Open API plugins are being developed to extract process synthesis models from XMI project files and in-memory UML models respectively.

For an example of Synthesis Network modelling in MagicDraw UML^TM please visit The Drancing UML model zone.

---

History

The WebEl system evolved over ten years as the synthesis of a number of Darren Kelly's project as physicist, IT consultant, and inventor, including:

• Model-driven, Java-based, ModelServer, control system facade, and control/monitor client, for the Neutron Beam Instrument program of the OPAL research reactor, for the Bragg Institute of the Australian Nuclear Science and Technology Organisation (ANSTO).
  
• Automated translation of the NeXus neutron science data format from XML component templates ("meta-DTDs") to Java "NeXusBean" components modelled in the Unified Modelling Language (UML)^TM.
• A custom Java+Java3D+JSyn application developed for the Drancing gestural synthesis system, a music and performance instrument which processes signals from triaxial accelerometers to synthesise, trigger, and control audio and video, sound and light, from human dance and movement.
  
• A custom Java+JSP+Java3D+JDO application developed for component modelling, tracking, simulation, and animation of the Molonglo Observatory Synthesis Telescope (MOST), a rotational synthesis radiotelescope operated by the University of Sydney, Australia.
  
• Experience with the control system and user interfaces of the HERA particle accelerator/collider
• A custom interactive, distributed, Java "dataspace" system for the VisLab of the University of Sydney.
• The many past Java+XML dynamic web projects of webel.com.au