Page 1220 - The Mechatronics Handbook

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

methods resulted in an informal, difficult to integrate (including application modules as well as the
products used to implement them), fragmented, more manual, and “after the fact” life-cycle process.
The National Test Bed of the U.S. Department of Defense sponsored an experiment in which it provided
a development problem to each of three contractor/vendor teams chosen from a large pool of vendors
and development environments, based upon a well-defined set of requirements. The application was a
real-time, distributed, multiuser, client server system, which needed to be defined and developed under
the government 2167A guidelines.
All teams were able to complete the first part, the definition of preliminary requirements. Two teams
completed the detailed design. But only one team was able to generate complete, integrated, and fully
production-ready code automatically; a major portion of this code was running in both C and Ada at
the end of the experiment [12]. The team that was able to generate the production-ready code was using
the 001 Tool Suite, a development environment based on the DBTF methodology.

49.5 Conclusion

Businesses that expected a big productivity payoff from investing in technology are, in many cases, still
waiting to collect. A substantial part of the problem stems from the manner in which organizations are
building their automated systems. While hardware capabilities have increased dramatically, organizations
are still mired in the same old methodologies that saw the rise of the behemoth mainframes. Old meth-
odologies simply cannot build the new systems.
There are other changes as well. Users demand much more functionality and flexibility in their systems.
And given the nature of many of the problems to be solved by this new technology, these systems must
also be error-free as well.
Where the biological superorganism has built-in control mechanisms fostering quality and produc-
tivity, until now the silicon superorganism has had none. Hence, the productivity paradox.
Often, the only way to solve major issues or to survive tough times is through nontraditional paths
or innovation. One must create new methods or new environments for using new methods.
Innovation for success often starts with a look at mistakes from traditional systems. The first step is
to recognize the true root problems, then categorize them according to how they might be prevented.
Derivation of practical solutions is a logical next step. Iterations of the process entail looking for new
problem areas in terms of the new solution environment and repeating the scenario. That is how DBTF
came into being.
With DBTF all aspects of system design and development are integrated with one systems language
and its associated automation. Reuse naturally takes place throughout the life cycle. Objects, no matter
how complex, can be reused and integrated. Environment configurations for different kinds of architec-
tures can be reused. A newly developed system can be safely reused to increase even further the produc-
tivity of the systems developed with it.
The paradigm shift occurs once a designer realizes that many of the old tools are no longer needed to
design and develop a system. For example, with one formal semantic language to define and integrate
all aspects of a system, diverse modeling languages (and methodologies for using them), each of which
defines only part of a system, are no longer necessary. There is no longer a need to reconcile multiple
techniques with semantics that interfere with each other.
DBTF can support a user in addressing many of the challenges presented in today’s software development
environments. There will, however, always be more to do to capitalize on this technology. That is part of
what makes a technology like this so interesting to work with. Because it is based on a different premise
or set of assumptions (set of axioms), a significant number of things can and will change because of it.
There is the continuing opportunity for new research projects and new products. Some problems can be
solved, because of the language, that could not be solved before. Software development as we know it will
never be the same. Many things will no longer need to exist—they, in fact, will be rendered extinct, just
as that phenomenon occurs with the process of natural selection in the biological system. Techniques for
bridging the gap from one phase of the life cycle to another become obsolete. Testing procedures and tools

©2002 CRC Press LLC