On Sat, 18 Aug 2001 Geoff Canyon <[EMAIL PROTECTED]> wrote:
> >From the web page at: <http://www.mactech.com/progchallenge/2001_09_Challenge.html>
> "The basic requirement is that you open a text file containing
> valid C/C++ source code and generate a Nassi-Schneiderman diagram
> for each routine included in that file."
> It's frustrating that they aren't offering sample files. One thing
> that will definitely be needed is regex patterns to recognize C and
> C++ source code. I'm looking online for this right now, but haven't
> found anything yet. If anyone knows where such a beast exists, or
> better yet has already done C/C++ pattern matching in MC/Rev, that
> would help.
I think you probably don't want to use regex for this. It isn't
necessary and will probably just make parsing the file harder and
slower. Instead, keep in mind that spaces and returns aren't
significant in C and that the primary delimiter is the semicolon (in
fact, you might want to just convert all the returns to spaces as the
very first step to make building the labels easier because you don't
have to worry about handling statements that break over multiple
lines, or multiple statements on a single line, though the problem
description isn't specific about whether this sort of reformatting is
allowed or required). This means the main loop should probably be
something like:
set the itemDelimiter to ";"
repeat for each item i in yourcontainer
Then, switch of word 1 of i to see if it's one of the language
keywords. Dealing with "for" is a little tricky because you'll have
to set a flag to collect two more items into a container and then do
some hand-coded parsing of the last one (the stuff before the closing
")" goes with the "for" and the stuff after goes with the next
statement. If you really want to get fancy (probably not necessary
for this Challenge), use "repeat for each token" to separate out each
operator, MetaTalk being similar enough to C that that will do most of
the work for you. This would be a lot more work, though, because
you'll have to build something that has a lot better understanding of
the C language than if you just use the semicolon as a delimiter.
> Also, I think this description is vague:
> "You must provide a means for the user to select a section of the
> diagram, or click on a section of interest, and zoom in on that
> section. The zoomed-in display should increase the level of detail
> displayed, until no further increase in detail is possible."
> Does that mean that higher levels of the diagram go away, or is it
> more like the zoom feature on the dock in OS X, where everything is
> visible all the time, but whatever has the focus is expanded to the
> detriment of others?
Seems to me it could go either way. But if zoom excludes other stuff,
you're going to have to add some sort of "unzoom" feature that brings
it back. It might be sufficient to just show a single line in each of
the code blocks and have "zoom" just mean to expand a block so that
you can see all of the text in it (kind of like a progressive
disclosure/tree view, except that you raise the expanded object *on
top* of the other objects rather than pushing them all down, which
would be nice but would also be a nightmare to lay out with a deeply
nested diagram). Clicking on the object again would unzoom it back to
it's previous size.
I also don't think much of their idea of squashing the diagram down to
fit in whatever the window size is. Seem to me you'll just end up
with a solid black figure in the degenerate case. Better would be to
put a lower limit on the size and then add scrollbars if it won't fit
in the window.
If nothing else, we can all get one take-home message here: trying to
set requirement specs in the absence of a working prototype (the
hallmark of design with traditional CASE (Computer Aided Software
Engineering) methodologies) is a recipe for disaster, which of course
is the reason CASE became a dirty word among software developers and
why high-level tools are becoming so popular.
Regards,
Scott
> regards,
>
> Geoff
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
