Page 130 - DCAP405_SOFTWARE_ENGINEERING

Unit 8: Design Engineering

for rigorously validating a high level design. The detailed design will ultimately influence (or Notes
should be allowed to influence) the high level design at least as much as other factors. Refining
all the aspects of a design is a process that should be happening throughout the design cycle. If
any aspect of the design is frozen out of the refinement process, it is hardly surprising that the
final design will be poor or even unworkable.
On any software project of typical size, problems like these are guaranteed to come up. Despite
all attempts to prevent it, important details will be overlooked. This is the difference between
craft and engineering. Experience can lead us in the right direction. This is craft. Experience will
only take us so far into uncharted territory. Then we must take what we started with and make
it better through a controlled process of refinement. This is engineering.
As just a small point, all programmers know that writing the software design documents after
the code instead of before, produces much more accurate documents. The reason is now obvious.
Only the final design, as reflected in code, is the only one refined during the build/test cycle. The
probability of the initial design being unchanged during this cycle is inversely related to the
number of modules and number of programmers on a project.

!
Caution It rapidly becomes indistinguishable from zero.
In software engineering, we desperately need good design at all levels. In particular, we need
good top level design. The better the early design, the easier detailed design will be. Designers
should use anything that helps. Structure charts, Booch diagrams, state tables, PDL, etc. — if it
helps, then use it. We must keep in mind, however, that these tools and notations are not a
software design. Eventually, we have to create the real software design, and it will be in some
programming language. Therefore, we should not be afraid to code our designs as we derive
them. We simply must be willing to refine them as necessary.
There is as yet no design notation equally suited for use in both top level design and detailed
design. Ultimately, the design will end up coded in some programming language. This means
that top level design notations have to be translated into the target programming language
before detailed design can begin. This translation step takes time and introduces errors. Rather
than translate from a notation that may not map cleanly into the programming language of
choice, programmers often go back to the requirements and redo the top level design, coding it
as they go. This, too, is part of the reality of software development.
It is probably better to let the original designers write the original code, rather than have
someone else translate a language independent design later. What we need is a unified design
notation suitable for all levels of design. In other words, we need a programming language that
is also suitable for capturing high level design concepts. This is where C++ comes in. C++ is a
programming language suitable for real world projects that is also a more expressive software
design language. C++ allows us to directly express high level information about design
components. This makes it easier also helps the process of detecting design errors. This results
in a more robust design, in essence a better engineered design.
Ultimately, a software design must be represented in some programming language, and then
validated and refined via a build/test cycle. Any pretense otherwise is just silliness. Consider
what software development tools and techniques have gained popularity. Structured
programming was considered a breakthrough in its time. Pascal popularized it and in turn
became popular. Object oriented design is the new rage and C++ is at the heart of it. Now think
about what has not worked. CASE tools? Popular, yes; universal, no. Structure charts? Same
thing. Likewise, Warner-Orr diagrams, Booch diagrams, object diagrams, you name it. Each has
its strengths, and a single fundamental weakness — it really isn’t a software design. In fact the

LOVELY PROFESSIONAL UNIVERSITY 123