Page 1219 - The Mechatronics Handbook

0066_frame_C49.fm Page 14 Thursday, January 10, 2002 5:05 PM

TABLE 49.2 A Comparison
Traditional (After the Fact) DBTF (Before the Fact)
Interface errors (over 75% of all errors) No interface errors
Most found after implementation All found before implementation
Some found manually All found by automatic and
Some found by dynamic runs analysis static analysis
Some never found Always found
Ambiguous requirements Unambiguous requirements
Informal or semiformal language formal, but friendly language
Different phases, languages, and tools All phases, same language and tools
Different language for other systems than for Same language for software, hardware and
software any other system
Automation supports manual process Automation does real work
Mostly manual documentation, programming, Automatic documentation, programming,
test generation, traceability, etc. test generation, traceability, etc.
100% code automatically generated for any
kind of software
No guarantee of function integrity after Guarantee of function integrity after
implementation implementation
Systems not traceable or evolvable Systems traceable and evolvable
Locked in products, architectures, etc. Open architecture
Painful transition from legacy Smooth transition from legacy
Maintenance performed at code level Maintenance performed at spec level
Reuse not inherent Inherent reuse
Reuse is adhoc Every object a candidate for reuse
Customization and reuse are mutually exclusive Customization increases reuse pool
Mismatched objects, phases, products, architectures Integrated & seamless objects, phases, products,
and environment architectures, and environment
System not integrated with software System integrated with software
Function oriented or object oriented System oriented objects: integration of
function, timing, and object oriented
GUI not integrated with application GUI integrated with application
Simulation not integrated with software code Simulation integrated with software code
Automation not defined and developed with itself Automation defined with and generated by itself
#1 in all evaluations
Dollars wasted, error prone systems Better, faster, cheaper systems
Not cost-effective 10 to 1, 20 to 1, 50 to 1…dollars saved
Difficult to meet schedules Minimum time to complete
Less of what you need and more of what you No more, no less of what you need
don’t need

changing architectures and changing technologies. Table 49.2 contains a summary of some of the differ-
ences between the more modern preventative paradigm and the traditional approach.
A relatively small set of things is needed to master the concepts behind DBTF. Everything else can be
derived, leading to powerful reuse capabilities for building systems. It quickly becomes clear why it is no
longer necessary to add features to the language or changes to a developed application in an ad hoc
fashion, since each new aspect is ultimately and inherently derived from its mathematical foundations.

49.4 Experience with DBTF

That preventative development is a superior alternative has been proven rather dramatically in several
experiments. DBTF has been through many evaluations and competitions conducted and sponsored by
leading academic institutions, government agencies, and commercial organizations. In every evaluation
and competition this alternative came out on top. What set this alternative apart from the others was
that it provided a totally integrated system design and development environment, whereas the traditional

©2002 CRC Press LLC