Page 1212 - The Mechatronics Handbook

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

• Integration is a challenge and needs to be considered at the onset. With traditional systems,
developers rely on mismatched modeling methods to capture aspects of even a single definition.
Whether it be integration of object to object, module to module, phase to phase, or type of
application to type of application, the process can be an arduous one. The mismatch of products
used in design and development compounds the issue. Integration is usually left to the devices of
myriad developers well into development. The resulting system is sometimes hard to understand
and objects are difficult to trace. The biggest danger is there is little correspondence to the real
world. Interfaces are often incompatible and errors usually propagate throughout development.
As a result, systems defined in this manner can be ambiguous and just plain incorrect.
• Errors need to be minimized. Traditional methods including those that are object oriented can
actually encourage the propagation of errors, such as propagating errors through the reuse of
objects with embedded and inherited errors throughout the development process. Errors must be
eliminated from the very onset of the development process before they take on a life of their own.
2
• Languages need to be more formal. Although some languages are formal and others are friendly,
it is hard to find languages both formal and friendly. Within environments where more informal
approaches are used, lack of traceability and an overabundance of interface errors are a common
occurrence. Recently, more modern software requirements languages have been introduced (for
example, the Unified Modeling Language, UML [8]), most of which are informal (or semi-formal);
some of these languages were created by “integrating” several languages into one. Unfortunately,
the bad comes with the good—often, more of what is not needed and less of what is needed; and
since the formal part is missing, common semantics need to exist to reconcile differences and
eliminate redundancies.
• The syndrome of locked-in design needs to be eliminated. Often, developers are forced to develop
in terms of an implementation technology that does not have an open architecture, such as a
specific database schema or a GUI. Bad enough is to attempt an evolution of such a system; worse
yet is to use parts of it as reusables for a system that does not rely on those technologies. Well
thought-out and formal business practices and their implementation will help minimize this
problem within an organization.
• Flexibility for change and handling the unpredictable must be dealt with up front. Too often it is
forgotten that the building of an application must take into account its evolution. Users change
their minds, software development environments change, and technologies change. Definitions of
requirements in traditional development scenarios concentrate on the application needs of the
user, but without consideration of the potential for the user’s needs or environment to change.
Porting to a new environment becomes a new development for each new architecture, operating
system, database, graphics environment, or language. Because of this, critical functionality is often
avoided for fear of the unknown, and maintenance, the most risky and expensive part of a system’s
life cycle, is left unaccounted for during development. To address these issues, tools and techniques
must be used to allow cross technology and changing technology, as well as provide for changing
and evolving architectures.
• Developers must prepare ahead of time for parallelism and distributed environments. Often, when
it is known that a system is targeted for a distributed environment, it is first defined and developed
for a single processor environment and then redeveloped for a distributed environment—an unpro-
ductive use of resources. Parallelism and distribution must be dealt with at the very start of the
project.
• Resource allocation should be transparent to the user. Whether or not a system is allocated to
distributed, asynchronous, or synchronous processors and whether or not two or ten processors
are selected, with traditional methods, it is still up to the designer and developer to be concerned

2
See Defining Terms for definition of formal.
©2002 CRC Press LLC