jharkins@sagpd1.UUCP (Jim Harkins) (11/18/89)
I'm trying to use a CASE tool to create structure charts for a project
being done under the DOD's 2167 spec, and have found a few things that don't
seem to be addressed in either the CASE documentation nor any books I've got.
1. I had to write some system wide utility routines, in my structure charts
I use a library module to represent these. Then I have separate structure
charts for these utilities. In the structure charts for the library
routines should the top module be a library or a regular module?
Below are (poor) examples of each type of module.
---------- ----------
| | || ||
| | || ||
---------- ----------
normal module library module
2. Modules on the structure charts have data couples going into/out of them.
In the text description of a module I have to make a list of it's inputs
and outputs. But these may not have the same name, or may not even have
a name. For example, one library routine is a specialized malloc
I call GPM_Malloc. Below are 3 examples of how it could be called:
time_buffer = GPM_Malloc(1024 * 31);
constants = GPM_Malloc(sizeof(constants_type));
fft_buffer = GPM_Malloc(fft_size);
So I have 3 different names representing the data returned, and 1 name
with 2 constants representing data input. Currently I've decided all
inputs are GPM_Size_Type and all outputs GPM_Address_Type. I tried
using these on the structure charts instead of the actual names but that
doesn't exactly make it clear what I'm doing.
I think the problem can be summed up as follows. I can either name the
inputs/outputs accurately in the structure chart, which means my inputs
and outputs don't match those mentioned in the definition of GPM_Malloc.
Or, I can use names like GPM_Size_Type and GPM_Address_Type, which matches
the names used in the definition of GPM_Malloc but make the structure
chart confusing.
3. My project is divided into tasks, with a structure chart for each different
task. Communication between tasks is via queues. In structure chart A
it seems I should show message A going to queue A and message B being
received from queue B. In chart B I should show message A being received
from queue A and messages being sent to queue B. But I've never seen
a way to show this type of thing in a structure chart. It seems to me
this is pretty important information that shouldn't be forgotten or
overlooked. So how do I do this? Come to think of it, I've yet to see
a way to show queues on structure charts. The best we've come up with
are data only modules, which need to be tricked in order to work properly
in this context.
4. All the books we have around here seem to stop at the point I'm at. That
is, the last chapter says "now that you've analyzed your system and
created your tasks you need tools to make them work. This is an
introduction to structure charts, which is just what the doctor ordered."
I don't want an introduction, I want a thorough treatment of not only
what a structure chart is but a good description of how one should look,
what kinds of modules/couples/etc go where, and the mechanics of
creating them. A book that does for structure charts what DeMarco's
book Structured Analysis and System Specification did for object
oriented design. (We used that book to get this far.)
For what it's worth, our CASE tool is CADRE's Teamwork running on a Sun.
But the answers to these questions should be general enough so this won't
matter, nor should it matter what language I'm using (hint AB*DEF...Z).
jim
jharkins@sagpd1
"Congress. Outside of Zsa Zsa Gabor the most bloated and self indulgent entity
in the world."kschnitz@puff.UUCP (Kevin Schnitzius) (12/01/89)
In article <541@sagpd1.UUCP>, jharkins@sagpd1.UUCP (Jim Harkins) writes: > I'm trying to use a CASE tool to create structure charts for a project > being done under the DOD's 2167 spec, and have found a few things that don't > seem to be addressed in either the CASE documentation nor any books I've got. > 1. I had to write some system wide utility routines, in my structure charts > I use a library module to represent these. Then I have separate structure > charts for these utilities. In the structure charts for the library > routines should the top module be a library or a regular module? If it is a library module, it has alread been desgined and implemented for ANOTHER system. All that is needed is the reference to that name and the particular system and the reader should be able to find out more about the module. If you feel it is necessary for clarity to include the library module in your design, it should be as a regular module (assuming it was one the previous system. > 2. Modules on the structure charts have data couples going into/out of them. [ example of specialized malloc deleted ] The implemetor who is building your system can choose to use your special malloc or not but all that is need is a routine which produces a specific object. This is an implementation detail and NOT a design detail. There needs to be enough detail in your design to make the implementor cognizant of the need of specialize routines when necessary. >3. My project is divided into tasks, with a structure chart for each different > task. Communication between tasks is via queues. In structure chart A > it seems I should show message A going to queue A and message B being > received from queue B. In chart B I should show message A being received > from queue A and messages being sent to queue B. But I've never seen > a way to show this type of thing in a structure chart. It seems to me > this is pretty important information that shouldn't be forgotten or > overlooked. So how do I do this? Come to think of it, I've yet to see > a way to show queues on structure charts. The best we've come up with > are data only modules, which need to be tricked in order to work properly > in this context. I either show the couple as the whole queue or just an element from the queue. I have not found a good way to show this. > 4. All the books we have around here seem to stop at the point I'm at. [...] > I don't want an introduction, I want a thorough treatment of not only > what a structure chart is but a good description of how one should look, > what kinds of modules/couples/etc go where, and the mechanics of > creating them. A book that does for structure charts what DeMarco's > book Structured Analysis and System Specification did for object > oriented design. (We used that book to get this far.) Personnally, I prefer the Hatley/Pirbhai methodology because I deal with more realtime problems. For structure charts, this book recommends: Page-Jones, Meilir. The Practical Guide to Structured Systems Design, 2nd ed. Englewood Cliffs, N.J.: Prentice-Hall, 1988. Yourdon, E. & Constantine, L. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. Englewood Cliffs, N.J.: Prentice-Hall, 1975. Myer, G. Reliable Software Through Composite Design. New York: Van Nostrand Reinhold, 1975. > jim > jharkins@sagpd1 > > "Congress. Outside of Zsa Zsa Gabor the most bloated and self indulgent entity > in the world." Good Luck.... -- Kevin Schnitzius (Encore Computer Corporation, Ft. Lauderdale, Florida) (formerly Gould CSD) ************!!!!!!!!! Please ignore the From: line !!!!!!!!!!!************* Uucp: {pur-ee,sun,codas!novavax,uunet,mcnc!rti,etc}!gould!kschnitzius Internet: encore.com!gould!kschnitzius What a bunch of typing, huh?