Products

Last Updated: 9 January 2009

Tools

There are a number of essential tools required to apply Shlaer-Mellor OOA/RD or Executable UML successfully:

an editor allowing models to be developed,
a simulator allowing models to be tested and debugged as they are developed,
and an translator for code and report generation.

All such tools should support the XML-based OOA Interchange Format being proposed as part of OOA10, allowing Shlaer-Mellor and Executable UML users to utilize a variety of tools from different sources. The XML Metadata Interchange (XMI) and Diagram Interchange standards from the OMG are not a suitable alternative at the present time. Unlike XMI, the OOA Interchange Format is not based on a meta-metamodel. It is based directly on a metamodel of Shlaer-Mellor OOA/RD and relies on a two-way mapping between Shlaer-Mellor OOA/RD and Executable UML for representing Executable UML models. It is also a standalone model interchange format containing model and diagram information. OOA files using the OOA Interchange Format are human readable, can be directly edited and can be independently validated against a complete DTD.

OOA Tool

OOA Tool is a Shlaer-Mellor and Executable UML CASE tool implemented in 100% pure Java™ which includes a model editor and will include a simulator and translator. It is currently being developed in parallel with OOA10. Once development finishes, a Professional edition will be released at a competitive price, while a Standard edition will be distributed at no cost indefinitely. In the meantime, an early access BETA release is available for download.

Service Domains

Service domain products consist of several deliverables:

an executable model for the service domain,
an optional set of bridges to specific service domains making life easier if any of those service domains are used,
an optional set of bridges to specific software architectures making life easier if one of those software architectures is used,
an optional set of run-time libraries required by any bridges to specific software architectures,
an optional set of plug-ins to specific model simulators,
and a user manual.

The value of some service domains greatly depends on the set of bridges supplied with it, while others may be supplied with no bridges and work equally well in any configuration.

Service domains may be supplied as black boxes with no documentation beyond the public interface. The supplier may even obfuscate model element names to deter users from investigating the internal logic. Black box domains generally restrict the scope of any bridging to the public interface, i.e. synchronous services and external events incoming, domain-crossing events and bridging processes outgoing. However, service domains are more adaptable if supplied as white boxes with documentation covering the whole domain. White box domains allow users to create arbitrary bridge mappings between internal model elements. They also make it easier for users to debug the service domain in a model simulator and optimize bridges from the service domain to new software architectures in unforeseen ways.

Java Swing User Interface

Once development of OOA Tool finishes, a number of service domains will be developed. The first will be a Java Swing User Interface domain which plugs into the OOA Tool simulator allowing simple graphical user interfaces to be created and used prior to any translation effort. This service domain will also be bridged to any Java software architectures offered by Kavanagh Consultancy.

Software Architectures

Software architecture products consist of several deliverables:

a model for the software architecture which may need to be executed to create architecture specific instance data,
a default bridge to the software architecture mapping metamodel instance data to architecture specific instance data,
a set of archetype templates to translate instance data into source code and build scripts for one or more deployment platforms,
a set of run-time libraries required by the software architecture,
and a code generation manual.

The use of a model for the software architecture allows complex validation and optimization processes to be performed that can't easily be carried out in archetype templates. However, archetype templates should still be used since this allows users to tailor the structure and content of generated code without having to change the generated code.

Java Software Architecture

Once development of OOA Tool finishes, a production quality Java Software Architecture will be developed. This software architecture will support concurrent and distributed applications using Java Remote Method Invocation (RMI).

We would like to talk to anyone interested in developing software architectures for other deployment platforms. Few Shlaer-Mellor or Executable UML users have the ability or resources to develop a software architecture from scratch. Therefore, the more deployment platforms there are available, the faster the Shlaer-Mellor and Executable UML user base will grow.

(Top Tabs)