Syntropy Methodology
Syntropy MethodologyDescribed in the book Designing Object Systems : Object-Oriented Modelling With Syntropy by SteveCook, JohnDaniels. ISBN 0132038609
Has 3 models:
(Apparently, you don't always need the three models - it's a question of pragmatism...)
JohnDaniels describes Syntropy at http://www.syntropy.co.uk/syntropy/index.htm
In the essential model, is it possible for two events to occur simultaneously? (Or is it the case that all events are "serialised".)
If multiple events can occur at some time point, then surely this would cause ambiguity in the interpretation of state charts? (In the ShlaerMellorMethod for example, only one state transition can happen on an object at any time.)
--
Events can never occur simultaneously in Syntropy; it is assumed that events are well ordered (serialised). Given this, there is no ambiguity in statecharts.
Has anyone here had any practical experience with Syntropy? If so, I'd like to hear about it.
--
Yes, I used Syntropy for a couple of years at part of what is now MetapathSoftwareInternational. In particular, to specify and design a tool for modelling microwave propagation in dense urban areas (for cellular network planning). I loved it!
A lot of the MSIers never really got it, saying that all those upside-down 'A's and back-to-front 'E's were all very well as "theoretical software engineering", but they'd rather be typing code. Conversely, I found that Syntropy has the 20% of formalism that gets you the 80% of benefit. It is hard work to get all that stuff right, but when you do, you're laughing all the way to the (time) bank. Sadly, there is no real tool support (we jury-rigged some diagramming aids in VisualThought), which is a real shame, as you could build a blinding tool for this method.
Since learning some Eiffel it seems that a lot of the ideas are similar (especially the emphasis on contracts, although the book isn't explicit on this).
We used the Specification and Implementation perspectives; since we had a well understood mathematical domain, and the predictor would run as a batch process, we knew exactly where the system boundary was and what events would pass across it. We found that all the (4) team members, who had very different backgrounds, were able to communicate very clearly, accurately and precisely using Syntropy. Even my then boss, a big "bubbles and arrows" man, was impressed by the ease with which Implementation models can be turned into correct code (C++, in this case).
Pragmatism is the key, however (as the book states). One subtle danger was the huge brains in research going well over the top. When it takes three pages of set-shuffling to specify a derived association, something is wrong.
Certainly, I have used ideas learned by using Syntropy extensively in every project I've worked on since. It presents a toolkit of very powerful ways to think about objects and systems. In particular, the classification of constructs as one of {Essential, Specification, Implementation}, one of {Static, Dynamic, "Functional"}, and one of {Interaction, Concept, Infrastructure} with a good dose of recursive nesting on the last one has served me well. Also, the "Viewpoint" idea, multiple interfaces on a class, is very powerful.
I keep seeing a lot of these notions indepenedently re-expressed elsewhere (and usually not so clearly), which is some testement to their value.
One other similarity with Eiffel: in the domain it addresses, it's difficult to see what remains to be said, at this time.
I believe that from Steve Cook via IBM some part of Syntropy lives on in the UML ObjectConstraintLanguage.
Aside from any prescriptive statements about what one should "do" in design, the book has many fascinating insights. Well worth reading. -- MichaelFeathers
EditText of this page
(last edited April 10, 2012)
or FindPage with title or text search