Shlaer–Mellor method

The Shlaer-Mellor method, developed by Sally Shlaer and Stephen Mellor, is one of a number of object-oriented analysis (OOA) / object-oriented design (OOD) methods which arrived in the late 1980s in response to established weaknesses in the existing structured analysis and structured design (SASD) techniques in use by (primarily) software engineers.

Of these well known problems, Shlaer and Mellor chose to address:

The complexity of designs generated through the use of SASD.
The problem of maintaining analysis and design documentation over time.

Background

The general solution taken by OOA/OOD methods to these particular problems with SASD, was to switch from functional decomposition to semantic decomposition. That is to say, describing the control of a passenger train as load passengers, close doors, start train, stop train, open doors, unload passengers becomes a design focused on the behavior of doors, brakes, and engines, and how those "domains" (doors, brakes, etc.) are related and interact. So door behavior, for example, becomes localized in one part of the design rather than being distributed across the design.

Translation v. elaboration

What makes Shlaer-Mellor unique among OOA/OOD methods is the degree to which object-oriented semantic decomposition is taken, the precision of the Shlaer-Mellor Notation used to express the analysis, and the defined behavior of that analysis model at run-time. The goal of the Shlaer-Mellor method is to make the documented analysis so precise that it is possible to implement the analysis model directly by translation rather than by elaboration. In Shlaer-Mellor terminology this is called recursive design. In current (2006) terminology, we would say the Shlaer-Mellor method uses a form of Model-driven Architecture (MDA) normally associated with the Unified Modeling Language (UML).

By taking this translative approach, the implementation is always generated (either manually, or more typically, automatically) directly from the analysis. This is not to say that there is no design in Shlaer-Mellor, rather that there is considered to be a virtual machine that can execute any Shlaer-Mellor analysis model for any particular hardware/software platform combination. This is similar in concept to the virtual machines at the heart of the Java programming language and the Ada programming language, but existing at analysis level rather than at programming level. Once designed and implemented, such a virtual machine is re-usable across a range of applications. Shlaer-Mellor virtual machines are available commercially from a number of tool vendors, notably Kennedy Carter in the UK, and Mentor Graphics in the USA.

Semantic decomposition

In Shlaer-Mellor the result of a semantic decomposition is a collection of (problem) domains.

The first level of semantic decomposition found in Shlaer-Mellor is the split between analysis and design models. The analysis domain expresses precisely what the system must do, the design domain is a model of how the Shlaer-Mellor virtual machine operates for a particular hardware and software platform. These models are disjoint, the only connection being the notation used to express the analysis model. The analysis domain is considered to be dependent upon the design domain.

The second level of semantic decomposition comes within the analysis domain where system requirements are modelled, and grouped, around specific, disjoint, subject matter ontologies. To return to the earlier train controller example, individual semantic models may be created based on doors, motors, braking system domains. Each grouping is considered, and modelled, independently. The only defined relationship between the groupings are dependencies e.g. a train controller may depend on both door management and motor control. Motor control may depend upon traction and braking systems.

Domain models of doors, motors, and braking systems would typically be considered as generic re-usable service domains whereas the train controller domain is likely to be a very product-specific application domain. What makes a particular system/product is specific populations of objects in each domain and the counterpart mappings defined between the domains (a decelerator object in the motor domain may be an actuator in the braking system). The mapping between objects (and typically events between objects' finite state machines) in two different domains is called a bridge.

Precise action language

One of the requirement for automated code generation is to precisely model the actions within the finite state machines used to express dynamic behaviour of Shlaer-Mellor objects. Since Shlaer-Mellor uses only Moore State Models, this means specifically state actions. Shlaer-Mellor is unique amongst OOA methods in expressing such sequential behavior graphically as Action Data Flow Diagrams (ADFDs). The (relatively) trivial behaviour of an action on an ADFD is then expressed textually.

There has never been a universally agreed textual language to express actions within the Shlaer-Mellor community. Shlaer and Mellor's own version was, and is, copyright and available only through their own commercial toolchain. Other tool vendors have similarly copyrighted and controlled their own action languages. This problem has dogged all model-driven architecture to the present day, with even the Unified Modeling Language having no unified action language to define its state actions. The best that has been achieved is the UML Action Semantics specification created as Shlaer-Mellor migrated to the UML notation, becoming Executable UML. This however describes what features an action language must possess, not its grammar. Imagine describing the requirements of spoken English without defining a grammar or vocabulary.

In practice, all tools that support Shlaer-Mellor's Recursive Design, or more generally Model Driven Architecture, provide a (vendor specific) precise action language. Usually such action languages do not support the ADFD approach, and the entire state action is written in textual form.

Test and simulation

The translative approach of the Shlaer-Mellor method lends itself to automated test and simulation environments (by switching the target platform during code generation), and this may partly explain the popularity of Shlaer-Mellor and other MDA-based methods when developing embedded systems, where testing on target systems e.g. mobile phones or engine management systems, is particularly difficult.

What makes such testing useful and productive is the concept of the Shlaer-Mellor virtual machine. As with most OOA/OOD methods, Shlaer-Mellor is an event-driven, message-passing environment. Onto this generic view, the Shlaer-Mellor virtual machine mandates a prioritised event mechanism built around Moore State Models, which allows for concurrent execution of actions in different state machines. Since any implementation of Shlaer-Mellor requires this model to be fully supported, testing under simulation can be a very close model of testing on target platform. Whilst functionality heavily dependent upon timing constraints may be difficult to test, the majority of system behaviour is highly predictable due to the prioritized execution model.

Bibliography

Books

Sally Shlaer, Stephen Mellor: Object-Oriented Systems Analysis: Modeling the World in Data, Yourdon Press, 1988, ISBN 013629023X
Sally Shlaer, Stephen Mellor: Object Lifecycles: Modeling the World in States, Yourdon Press, 1991
Stephen Mellor, Mark Balcer: Executable UML, A Foundation for Model Driven Architecture, Addison Wesley, 2002, ISBN 0201748045
Christopher Raistrick et al., Model Driven Architecture with Executable UML, Cambridge University Press, 2004
Leon Starr. How to Build Shlaer-Mellor Object Models. Prentice Hall, 1996.

Papers

Stephen Mellor, Make Models Be Assets, Communications of the ACM Volume 45, 11:76-87 (November 2002), 2002