Biomedical Engineering Reference
In-Depth Information
should include descriptions of the class hierarchies,
of state transitions, and of object persistence. It
should also describe other objects that were consid-
ered and should give reasons for preferring the
chosen organization.
Description of a strategy for handling changes clearly.
It should show that possible enhancements have
been considered and that the enhancements most
likely are also the easiest to implement
Estimation of the amount of memory used for
nominal and extreme cases
Software architecture contemplates two important
characteristics of a computer program: The hierarchical
structure of procedural components (modules); and the
structure of data. Software architecture is derived
through a partitioning process that relates elements of
a software solution to parts of a real-world problem im-
plicitly defined during requirements analysis. The evo-
lution of a software structure begins with a problem
definition. The solution occurs when each part of the
problem is solved by one or more software elements.
done to ensure a proper fit for the organization and
product.
Regardless of the approach used, the most important
factor to be considered for the successful implementation
of a design methodology is software-development-team
buy-in. The software development teammust possess the
confidence that the approach is appropriate for the ap-
plication and must be willing and ''excited'' to tackle the
project. The implementation of a design methodology
takes relentless discipline. Many projects have been
unsuccessful as a result of lack of commitment and faith.
The two most popular formal approaches applied to
the design of medical products are the Object Oriented
Analysis/Design and, the more traditional, (top-down)
Structured Analysis/Design. There are advantages and
disadvantages to each. Either approach, if done in a dis-
ciplined and systematic manner along with the electrical
system design, can provide for a safe and effective
product.
Choosing a language
Programming languages are the notational mechanisms
that are used to implement software products. Features
available in the implementation language exert a strong
influence on the architectural structure and algorithmic
details of the software. Choice of language has also been
shown to have an influence on programmer productivity.
Industry data have shown that programmers are more
productive using a familiar language than an unfamiliar
one. Programmers who work with high-level languages
achieve better productivity than do those who work with
lower-level languages. Developers who work with inter-
preted languages tend to be more productive than those
who work with compiled languages. In languages that are
available in both interpreted and compiled forms, pro-
grams can be productively developed in the interpreted
form, and then released in the better-performing, com-
piled form.
Modern programming languages provide a variety of
features to support development and maintenance of
software products. These features include:
Strong type checking
Separate compilation
User-defined data types
Data encapsulation
Data abstraction.
The major issue in type checking is flexibility versus se-
curity. Strongly typed languages provide maximum
security, while automatic type coercion provides maxi-
mum flexibility. The modern trend is to augment strong
type checking with features that increase flexibility while
maintaining the security of strong type checking.
Choosing a methodology
It seems there are about as many design methodologies as
there are engineers to implement them. Typically, the
methodology selection entails a prescription for the
requirements analysis and design processes. Of the many
popular methods, each has its own merit, based on the
application to which the methods are applied. The tool
set and methodology selection should run hand-in-hand.
Tools should be procured to support established or ten-
tative design methodology and implementation plans. In
some cases, tools are purchased to support a methodol-
ogy already in place. In other cases, an available tool set
dictates the methodology. Ideally, the two are selected at
the same time, following a thorough evaluation of need.
Selecting the right tool set and design methodology
should not be based on a flashy advertisement or a sug-
gestion from an authoritative methodology guru. It is
important to understand the environment in which it will
be employed and the product to which it will be applied.
Among other criteria, the decision should be based on
the size of the project (i.e., the number of requirements),
the type of requirements (i.e., hard or soft real-time), the
complexity of the end-product, the number of engineers,
the experience and skill level of the engineers, the pro-
ject schedules, the project budget, the reliability re-
quirements, and the future enhancements to the product
(i.e., maintenance concerns). Weight factors should be
applied to the evaluation criteria. One way or another,
whether the evaluation is conducted in a formal or
informal way, involving one person or more, it should be
