Syntropy: the method
Syntropy is an object-oriented analysis and design method developed at
Object Designers Limited in the UK in the early 1990s. The goal in developing Syntropy was to provide a set of modelling techniques
that would allow precise specification and would keep separate different areas of concern. The approach was to
take established techniques, as found in methods such as OMT and Booch, and reposition and refine them. Graphical notations
were much favoured by the market but lacked rigour, so Syntropy adopted ideas from formal
specification languages, specifically Z, to provide tools for both precise definition of the graphical notations
and for the construction of richer models than are possible with pictures alone.
Syntropy is described in the book Designing Object Systems: Object-Oriented Modelling with Syntropy
by Steve Cook and
John Daniels,
(originally published by Prentice Hall in 1994, ISBN 0-13-203860-9, but now freely available here).
Summary and reference
We define three different perspectives for the construction of object models. We call each of these three perspectives a model:
- An Essential Model is a model of a real or imaginary situation. It has nothing at all to do with software: it describes the elements of the situation, their structure and behaviour.
- A Specification Model is an abstract model of a software system that treats the system as a stimulus-response mechanism. It assumes a computing environment infinitely fast and with no limit on resources.
- An Implementation Model is a detailed model of software structure and behaviour that takes into account the limitations of the computing environment.
The distinction between essential, specification and implementation models allows us to keep separate the concerns of different people and activities in the software development process. An essential model allows us to think about, say, a business process without having to consider where the boundary between a possible software system to support that process and its environment might lie. A specification model allows us to consider the interface between the software and its environment, and the overall structure of the software (together with the responsibilities of its parts), without having to consider low-level design issues. An implementation model allows us to express our design intentions in a programming language-independent way. The implementation model is the only one of the three to use object-to-object message sending as the means of inter-object communication.
Each of the three models is expressed by a number of views, each kind of view having a defined notation.
The structure of the system is captured in type views. A type view describes object types, their properties and their relationships. The notation used for type views is an extension of the class diagram found in OMT.
The behaviour of the system is captured in state views, one per object type. The notation used for state views is an extension of the Harel statechart notation, a form of state transition diagram, also found in OMT.
A third view, the mechanism diagram, is used in the Implementation Model to describe the flow of messages between objects in response to a stimulus. We notate such flows using mechanism diagrams, first proposed by Booch. These diagrams are examples, not a fully generic description.
Syntropy also supports the notion of domains. A domain is a sub-system defined as a set of object types. We use domains to make a clear separation between the application logic (located in concept domains) and those parts of the software system that connect the logic to the environment (interaction domains) or that provide infrastructure services (infrastructure domains).
We think the notion that object types define separate private and public interfaces, as found in many object-oriented programming languages, is too simplistic to be useful for large-scale modelling, particularly when we wish to build libraries of reusable designs. We have therefore developed a technique for defining subsets of an object's interface, which we call viewpoints.
Comments, corrections to
jdaniels@cix.co.uk