The Shlaer–Mellor method, also known as Object Oriented Systems Analysis (OOSA) or Object Oriented Analysis (OOA) is an object-oriented software development methodology introduced by Sally Shlaer and Stephen Mellor in 1988. The goal of the 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 the new millennium the Shlaer–Mellor method has migrated to the UML notation, becoming Executable UML.
The Shlaer–Mellor method is one of a number of software development methodologies which arrived in the late 1980s. Most familiar were Object-Oriented Analysis and Design (OOAD) by Grady Booch, Object Modeling Technique (OMT) by James Rumbaugh, Object-Oriented Software Engineering by Ivar Jacobson and Object Oriented Analysis (OOA) by Shlaer and Mellor. These methods had adopted a new object-oriented paradigm to overcome the established weaknesses in the existing structured analysis and structured design (SASD) methods of the 1960s and 1970s. Of these well-known problems, Shlaer and Mellor chose to address:
- The complexity of designs generated through the use of structured analysis and structured design (SASD) methods.
- The problem of maintaining analysis and design documentation over time.
What makes Shlaer–Mellor unique among the object-oriented 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 general solution taken by the object-oriented analysis and design methods to these particular problems with structured analysis and design, was to switch from functional decomposition to semantic decomposition. For example, one can describe the control of a passenger train as:
- load passengers, close doors, start train, stop train, open doors, unload passengers.
Then a design becomes focused on the behavior of doors, brakes, and passengers, and how those objects (doors, brakes, etc.) are related and behave within the passenger train domain. Other objects, that provide services used by the passenger train domain, are modeled in other domains connected to the passenger train domain.
Shlaer-Mellor method topics 
Translation v. elaboration 
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 (2011) 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 Abstract Solutions, Mentor Graphics and Pathfinder Solutions.
Semantic decomposition 
Shlaer-Mellor proposes a semantic decomposition in multiple (problem) domains.
- 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 models.
- Decomposition within the analysis domain where system requirements are modelled, and grouped, around specific, disjoint, subject matters. To return to the earlier passenger train example, individual semantic models may be created based on door actuators, motor controls, and braking systems. Each grouping is considered, and modelled, independently. The only defined relationship between the groupings are dependencies e.g. a passenger train application may depend on both door actuation and motor control. Braking systems may depend upon motor control.
Domain models of door actuators, motor controls, and braking systems would typically be considered as generic re-usable service domains whereas the passenger train controller domain is likely to be a very product-specific application domain.
A particular system is composed of domains and the defined bridges between the domains. A bridge is described in the terms of the assumptions held by the domain acting as a client bridged to a domain acting as a server.
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 object oriented analyse methods in expressing such sequential behavior graphically as Action Data Flow Diagrams (ADFDs). The (relatively) trivial behaviour of an action on that type of diagram is then expressed textually.
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.
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 that was 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.
Graham (1994) described Shlaer–Mellor method as early example of object-oriented analysis, that could not really be regarded as object-oriented. According to Graham the method lacks "notion of inheritance. As described in their book it was little more than an object-based extension of data modelling." In line with comment Capretz (1996) argues that the Shlaer–Mellor method "fails to account for the vast majority of object-oriented ideas and an ordinary graphical notation is prescribed", which is primarily taken "from entity-relationship diagrams and data flow diagrams found in other structured methods".
In the early 1990s other object-oriented systems analysis methods were proposed. Notable is the Object-oriented Systems Analysis (OSA) introduced by Embley, Kurtz, Woodfield in their 1992 book Object-oriented systems analysis: a model-driven approach. This method "avoids being a preliminary design method as it specifically omits several design aspects claimed to aid implementation but to hinder analysis".
Before publication of their second book in 1991 Shlaer and Mellor had stopped naming their method "Object-Oriented Systems Analysis". They started focusing on the concept of Recursive Design (RD) migrating to Executable UML.
See also 
- Embedded Systems
- Executable UML
- Finite State Machine
- Functional decomposition
- Massive parallelism
- Model-driven architecture
- Structured analysis
- UML action
- Unified Modeling Language
- Stephen Mellor, Mark Balcer (2002) Executable UML, A Foundation for Model Driven Architecture, Addison Wesley, 2002, ISBN 0-201-74804-5
- Stephen Mellor (2002) Make Models Be Assets, Communications of the ACM Volume 45, 11:76-87 (November 2002), 2002
- Rodney C. Montrose (2001) Object-Oriented Development Using The Shlaer-Mellor Method. Project Technology, Inc.
- Christopher Raistrick et al. (2004) Model Driven Architecture with Executable UML, Cambridge University Press.
- Sally Shlaer, Stephen Mellor (1988) Object-Oriented Systems Analysis: Modeling the World in Data, Yourdon Press. ISBN 0-13-629023-X
- Sally Shlaer, Stephen Mellor (1991) Object Lifecycles: Modeling the World in States, Yourdon Press.
- Leon Starr (1996) How to Build Shlaer-Mellor Object Models. Prentice Hall.
- Martin Reddy (2011) API Design for C++. p.127
- Andreas Zendler (1997) Advanced Concepts, Life Cycle Models and Tools for Objeckt-Oriented Software Development. p. 122
- Martin Fowler (2004) A Brief Guide to the Standard Object Modeling Language. p. 7
- Robert J. Müller (1999) Database Design for Smarties: Using Uml for Data Modeling. p. 106. Müller adds here:
Much of the work in OO modeling had its roots in data modeling, the fit with database design was fairly good.
- Hassan Gomaa (2011) Software Modeling and Design: UML, Use Cases, Patterns, and Software Architectures. p. 10. Gomaa explains here:
Shlaer and Mellor (1988, 1992), and Coad and Yourdon (1991, 1992). The emphasis in these methods was on modeling the problem domain, information hiding, and inheritance...
- Martin Reddy (2011) API Design for C++. p.126. Reddy states:
The Shlaer–Mellor method first partitions a system horizontally to create generic “domains” and then partitions these vertically by applying a separate analysis to each domain... One of the benefits of this devide-and -conquer approach is that domains tend to form reusable concepts that van be applied to other design problems.
- Sally Shlaer, Stephen Mellor (1991) Object Lifecycles: Modeling the World in States, p.142.
- Marcel Toussaint (1996) Ada in Europe: Second International Eurospace-Ada-Europe Symposium, Frankfurt, Germany, October 2–6, 1995, Volume 2. p.172 confirms:
... analysis and design using Object Oriented (OO) techniques (in this case Shlaer-Mellor) and a Computer Aided Software Engineering (CASE) tool giving the possibility for automatic code generation and more reuse in subsequent simulators.
- Ian Graham (1994) Object-oriented methods. p.229
- Luiz Fernando Capretz (1996) Object-Oriented Software: Design. p.77
Capretz describes OOSA as "analysis methodology with associated graphical notation, which is based on a variation of the Entity-Relationship Model combined with Structured Systems Analysis. The notation can be applied to describe objects, attributes and relationships, were a relationship indicates a link between objects.".
- Embley, BD Kurtz, SC Woodfield (1992) Object-oriented systems analysis: a model-driven approach.
- B. Kitchenham (1995) "Case Studies for Method and Tool Evaluation". In: IEEE Software archive. Volume 12 Issue 4, July 1995. pp. 52-62
|Wikiversity has learning materials about Object Oriented Software Design|