next up previous contents
Next: Response Up: Graphical Output Previous: Graphical Output

Inquiry

Mr Pearse:

We have come up with some issues concerning the graphical output that we
would like to get some feedback from you on.  We have discussed all of what
follows with Gerry, and will indicate his opinions, as well as ours, on each
issue.

Included are 5 PostScript files: wont_work.ps, one_page.ps, scale_one.ps, 
scale_two.ps, and scale_four.ps.

We looked at the output of many metrics tools, including some of McCabe's
products.  We feel that all of the graphical formats we came across are
inadequate, or unnecessarily complex for the needs of a conditional
compilation graph format.  Since there is no way to break or jump out of a
conditional compilation directive (#CCD), it is possible to draw a graph
without crossing lines.  The best tools we saw for code flow analysis use
complex bezier curves to connect nodes, because the assumption about no
crossing lines cannot be made with C code.  Therefore we came up with a
couple of different graph formats.

"wont_work.ps" is an example of a graph format similar to Battle Map.  In
this image we tried to find a logical way of drawing a graph for a simple
input file.  In doing so, we recognized a number of problems with this
format.  This example is relatively readable, but as the nesting level
increases, more and more has to be crammed inside of the outer diamond.  Even
in this example you will note that the line angles start to become messy (see
how the node at lines 14 and 16 connect to the node at line 24).  Also, we
expect that with more complex graphs, the lines would start to cross over
text quite often.  Also, the algorithm for calculating line angles could be
so complex that we would completely fail to generate correct graphs for some
input instances.  Given these problems, we recommend against such a format.

"one_page.ps", "scale_one.ps", "scale_two.ps", and "scale_four.ps" are all 
identical, except for scaling.  We chose these scales because:

* A one page graph (even if unreadable) should be useful for getting an idea
  of what the #CCD logic looks like.
* A scale factor of one is the smallest scale that is easily readable.
* A scale factor of four is the largest scale factor that is very useful.

We have limited our output to these four scales, because they are the only
ones that guarantee nodes will not be split across pages (unless we limit
output to a square area on each sheet of paper).  Note that the numbers in
the top left corner represent the (x, y) position of each page, where the top
left page is (0, 0).

We feel that block summaries are most useful when looking at large amounts of
code.  This summary value is represented by the lines that end with "BLOC"
(block lines of code).  Gerry also felt that it would be useful to know
exactly where code resides within a block, so we added the "LOC" labels
(lines of code).  In our graphs, the BLOC is the sum of all LOCs below it in
the block.  This does not include any lines of code contained within branches
from that block.

Gerry has said that he finds the BLOC abbreviation unintuitive.  If you also
find this to be a problem, we propose the text "Block LOC" one line below the
number (otherwise, it could run off the edge of the page and not get printed).

We have chosen the symbols for our graph to try to represent what each #CCD
means.  The diamond for any #CCD shows that there is a choice to be made.
The triangle for the #else statements shows that it is a default choice.  The
circle for the #endif just brings everything back together.

In this representation, a solid line signifies a logical flow within the
logic where C code can exist.  A dotted line shows logical flow where no C
code can exist.  By looking at these graphs, you can count V(g) by hand in
the same way you showed us when we met: by counting the regions on the
graph.  In this case, a region can be enclosed by solid and dotted lines.

In summary, these are the issues we need feedback on:

* Is our proposed graph format acceptable?  Note that the format exemplified 
  by "wont_work.ps" is probably not a viable alternative in our time frame.
* Is our multi-page format acceptable?
* Do you want BLOC, LOC, or both on the graphical output?

Thank you in advance for taking the time to address these issues.

Sincerely,
Noah Sutherland 
Team Leader
CS481 Team B