R. Clayton (rclayton@monmouth.edu)
Mon, 14 Feb 2000 12:18:12 -0500 (EST)
It seems as though the design diagrams involved in the SDD depict only data
flows and are not intended to describe logic flow.
Correct; design diagrams concern themselves almost exclusively with the
high-level, architectural structure of the solution. In addition to omitting
the control-flow details, design diagrams omit details about data
(structure and content) as well as the behavior of each box.
for example - we have seen how Structure charts can display iterative calls
or decisions - but I do not see how a designer communicates to the programmer
which call to make based off a decision box. And I don't trust a programmer
to figure it out for him/herself!
Design diagrams are one-half the process of doing architectural (or high-level)
design; the other half involves including a design specification that fills in
the details omitted by the design diagrams. But, keep in mind these details
are still architectural in the sense that they refer to features between boxes
and along arrows, not within individual boxes (although I suppose you could
argue that behavioral specifications for modules don't fit this
characterization).
Should the SDD describe this low-level of design I am referring to?
Yes it should, as part of (the second half of) architectural design.
Are flowcharts used more in the programmers domain, or have they become so
passe that I should be embarrassed by their mentioning?
Yes, passe and abhorred (I was reading one of those OO design books and they
used flow charts to describe part of the design, but the text was quite adamant
about not calling them flow charts). And yes, programmers still use them.
The System Design phase, to my understanding, is intended to develop the best
solution without describing it's lowest level - implementation.
That's right, although the client may, as part of their requirements, insist
that certain implementation details be used in the solution. For example,
anybody writing financial software had better be sure the calculations done in
their implementation conform to what the tax code and the IRS require.
Does this mean that concepts such as queues, lists, and stacks do not belong
in this document?
It does.
If not - how do we deal with the flow of objects and data when simple
relationships aren't enough?
You have to specify the object and data flows with enough detail to capture the
essence of the relationships, but without so much detail that you end up
implementing the code.
For example, if you're fighting the urge to specify a queue of objects in your
design, the relation you probably want to specify is: "the objects are
processed in the order they're created". This circumlocution may seem
pointless for relations and concepts as simple as queues and stacks, but it
doesn't take too much more complexity to see the advantages.
Suppose order tickets are to be processed in order by the date and time they're
written up; in addition, all tickets written up on the same hour of the same
day are to be processed in the order received. A priority queue can handle the
first part of the spec, but priority queues make no guarantees about the order
of removal for items with the same priority, so they aren't enough to handle
the second part of the spec. It's better for you, as a designer, to make sure
you clearly specify the behavior required, and let the implementors worry about
how to provide the behavior.
This archive was generated by hypermail 2.0b3 on Thu Mar 30 2000 - 20:50:05 EST