Page 1213 - The Mechatronics Handbook

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

with incorporating such detail into the application. There is no separation between the specifica-
tion of what the system is to do vs. how the system does it. This results in far too much imple-
mentation detail to be included at the level of design. Once such a resource architecture becomes
obsolete, it is necessary to redesign and redevelop those applications which have old designs
embedded within them.
• Automation that minimizes manual work needs to replace “make work” automated solutions. In
fact, automation itself is an inherently reusable process. If a system does not exist for reuse, it
certainly does not exist for automation. But most of today’s development process is needlessly
manual. Today’s systems are defined with insufficient intelligence for automated tools to use them
as input. In fact, automated tools concentrate on supporting the manual process instead of doing
the real work. Typically, developers receive definitions, which they manually turn into code. A
process that could have been mechanized once for reuse is performed manually again and again.
Under this scenario, even when automation attempts to do the real work, it is often incomplete
across application domains or even within a domain, resulting in incomplete code such as shell
code. The generated code is often inefficient or hardwired to a particular kind of algorithm, an
architecture, a language, or even a version of a language. Often partial automations need to be
integrated with incompatible partial automations or manual processes. Manual processes are
needed to complete unfinished automations.
• Run-time performance analysis (decisions between algorithms or architectures) should be based
on formal definitions. Conventional system definitions contain insufficient information about a
system’s run-time performance, including that concerning the decisions between algorithms or
architectures. System definitions must consider how to separate the system from its target envi-
ronment. Design decisions, where this separation is not taken into account, thus depend on analysis
of results from ad hoc “trial and error” implementations and associated testing scenarios.
• The creation of reliable reusable definitions must be promoted, especially those that are inher-
ently provided. Conventional requirements definitions lack the facilities to help find, create,
use, and ensure commonality in systems. Modelers are forced to use informal and manual
methods to find ways to divide a system into components natural for reuse. These components
do not lend themselves to integration and, as a result, they tend to be error-prone. Because
these systems are not portable or adaptable, there is little incentive for reuse. In conventional
methodologies, redundancy becomes a way of doing business. Even when methods are object
oriented, developers are often left to their own devices to explicitly make their applications
object oriented. This is because these methods do not support all that is inherent to the process
of object orientation.
• Design integrity is the first step to usable systems. Using traditional methods, it is not known if
a design is a good one until its implementation has failed or succeeded. Usually, a system design
is based on short-term considerations because knowledge is not reused from previous lessons
learned. Development, ultimately, is driven towards failure. The solution is to have an inherent
means to build reliable, reusable definitions.
Once these issues are addressed, software will cost less and take less time to develop. But time is of the
essence. These issues are becoming compounded and even more critical as developers prepare for the
distributed environments that go hand in hand with the increasing predominance of Internet applications.
With respect to the challenges described above, an organization has several options, ranging from one
extreme to the other. The options include: (1) keep things the same; (2) add tools and techniques that
support business as usual, but provide relief in selected areas; (3) bring in more modern but traditional
tools and techniques to replace existing ones; (4) use a new paradigm with the most advanced tools and
techniques that formalizes the process of software development, while at the same time capitalizing on
software already developed; or (5) completely start over with a new paradigm that formalizes the process
of software development and uses the most-advanced tools and techniques.

©2002 CRC Press LLC