"See virtually no traces of SADT anymore" :Keyword is "virtually". Our "modern" concepts like "cohesion" and "coupling" mostly come from SADT [Edward Yourdon-Larry L.Contantine] .There is even interesting references from modern software literature to old SADT literature. For example, Kent Beck, in his Implementation Patters book's Bibliography section says:
Edward Yourdan and Larry Constantine,Structured Design,...,1979 .
This books presents the equivalent of the laws of physics for software
design and grounds the discussion on the economics of development.[
Kent Beck, Implementation Patterns]
In that books Yourdan and Constantine says that:
Structured design is the art of designing the components of a system
and interrelationship between those components in the best possible
way.
And Meilir Page-Jones says that:
- Structured Design uses tools, especially graphic ones, to render systems readily understandable. [ Meilir Page-Jones- Practical Guide
to Structured Systems Design]
And today in software development our aim is still same... :-)
Why the world abandoned SADT?
Well, we have more changes than fashion industry :-).
The systems we build today and constraints are different than they were twenty or more years ago. I think when we begin to develop more "data-oriented" systems, where functional complexity is less of concern,SADT practices like Structure Chart-Data Flow Diagrams "lost" their efficiency for some systems..Then Object Oriented style come with its own methodologies and representations.
But Entity-Relationship(ER) diagrams and concept of Data Dictionary are still alive.
For an interesting view point of Yourdon check his blog: Watching “agile”...
Interestingly Yourdon still makes update on Structured Design Materials. Check at:
Modern Structured Analysis
What replaced SADT?
Well...For object oriented systems..
Suppose we have Responsibility Driven Design [ in which cohesion and coupling is still important] for finding best components and their interconnections in ours systems.
And UML generally gives us good visual thinking tool for finding those components and relaitionships.
And now we understand that software development is experimental activity.
We should do iterative and incremental development with evolutionary requirements.
There seem to be no magic "method" in which can be followed like a "receipt" for success.
Modeling in General:
Diagrams-Models are just thinking tools.
It is not realistic to design whole system on paper with UML or other
notations.Actually our real models are "source code" which can be
executed and tested.
There are some attempts like MDA(Model Driven Architecture) which try to produce executable code from models automatically: so we just have to model the system, then everything will be produced automatically. But we realized that this is also not realistic.For now it is just a dream that some tool vendors sell. Now our focus is more on Domain Specific Languages which is more practical and realistic.
