Location:
[CPSC 333]
[Listing by Topic]
[Listing by Date]
[Previous Topic]
[Next Topic]
Structured Design, Completed
This material was briefly mentioned during lectures on March
12, 1997.
Structured Design seemed to be a
reasonable design method to use, quite a while ago (in the 1970's).
At that point, Pascal (or a language like it) could be
considered to be advanced, and it was to be expected that any program
you'd implement - at least, for a business application - would have a
hierarchical control structure, that interfaces were limited, that I/O
was nontrivial (and could be ``walled off'' from the rest of the system
by using something like transform analysis), and
that most coding would be done ``from scratch.''
In the 1990's, interfaces are much more interactive and
complex. You have access to programming languages with additional
features (including much better support for information hiding, as
well as the use of software components). Some things that were
``nontrivial'' programming problems in the past can be handled using
one-line system calls, or using an interface that's become
standardized (so that it may be less prone to change).
It's possible (but not definite) that you'll find something like
``structured design'' to be useful for the design of some
``subsystems'' of more modern systems today. Another (probably better)
reason for studying the method is that it helps to make some of the
characteristics of a good
design and design principles
(that have already been introduced) a bit more concrete:
- At this point, you should be able to confirm that a design
obtained using structured design does (or, at least, should)
have all the desirable
characteristics that have been presented.
- The method reflects at least some of the design principles that have
been introduced as well:
- The design should be traceable to the analysis model:
The structure chart produced using structured design was obtained
by starting with the set of data flow diagrams (and
entity-relationship diagram) that had been produced for the
system using structured analysis; module specifications include
references back to the processes included on these DFDs.
- The design should not reinvent the wheel.
This is (perhaps) best exemplified by transaction
analysis, which included a specific ``pattern'' of modules
(command acquisition modules, a transaction center, the
controllers linking them together, and the separation of the
rest of the system into subsystems for different commands)
that could be used for ``transaction-based'' subsystems.
- The design should be structured to accommodate change:
At the time when this method was in use, one change in
requirements that was to be expected was a change in the I/O
devices that the system would be required to communicate with.
During the first part of structured
design and, specifically, in ``second level factoring''
during transaction
analysis and
transform analysis, modules that interacted directly (in
a nontrivial way) with terminators - and that could be expected
to be ``linked'' to these devices - were positioned near the
bottom of the structure chart, effectively isolating them from
the rest of the system. During the
second part of structured design, sets of modules
exhibiting external coupling
(through shared access to I/O devices) were looked for, and
changes were made in order
to make these sets of modules as
small as possible, and to ensure that these modules were solely
``devoted to'' interaction with these devices. The effect of this
this (one hopes) would be to reduce the difficulty of correctly
updating the system, when these I/O devices were changed.
- The design should be assessed for quality as it is created,
not after the fact: Of course, this is the purpose of
the second part of structured
design. While this seems to come at the end of
``structured design,'' it should be noted that it happens
before detailed design, implementation, or testing!
However, structured design is out of date. More modern
object-oriented design methods will be
considered next.
Location:
[CPSC 333]
[Listing by Topic]
[Listing by Date]
[Previous Topic]
[Next Topic]
Structured Design, Completed
Department of Computer Science
University of Calgary
Office: (403) 220-5073
Fax: (403) 284-4707
eberly@cpsc.ucalgary.ca