Re: Popular Design Diagram Methods For Ada

["Jeffrey D. Cherry" <jdcherry@utech.net>]

Comments interspersed ...

"Marin D. Condic" wrote:
> 
> In a large system, there is usually some sort of structure imposed
> simply by the distribution of the workload. In the case I'm currently
> looking at, I have a bunch of Sun boxes that talk to each other and to a
> bunch of specialized computers as well as getting data from other
> network sources. We need to start by identifying at a gross level
> how/what each of these boxes is communicating to each other. (That would
> be one layer of "CSC") Then push down into the software on any given box
> and look at the interactions of major components within that context.
> (Another layer of "CSC") Ultimately, we'll get down to the individual
> packages and procedures which make up the whole thing. We need the view
> at all these layers and I think almost any large system has *some*
> breakdown into this kind of structure. (Unless the designer started from
> line one of the code and kept writing it until it was done - but I don't
> think such a system could actually be built successfully. Especially
> when you involve more than one developer on the job. ;-)
> 
There is indeed a "layering" to the end product imposed by the physical 
distribution of computers and the host operating system on each computer.  
However, building CSCs from an analysis of these layers will not (typically) 
recover the original CSC hierarchy.  My perspective is to verify that a 
particular CSC hierarchy was implemented in the code under analysis.  A 
rather narrow view of the problem which was, no doubt, generated by my bias 
to IV&V.  Thanks for removing my blinders.

> I don't know that it would be possible to do this, or even necessarily
> desirable. Short of a breakthrough in artificial intelligence, how could
> you derive the intent of the programmer from just the code? You can
> diagram what the code tells you, but just because a package has a data
> type and some subprograms does not make it "Object Oriented" or any
> other specific approach.The best you can hope for is to draw a picture
> of what is in the code and to the extent that the pictures have some
> sort of Object Oriented meaning, they may correctly reflect the design
> methodology.
> 
Yes this is the point I was trying to make.  No tool can read the mind of a 
developer.  It goes beyond that though, since the tool would actually need 
to derive the intention of the developer since it is possible that the 
developer did not implement the design they intended.  The idealistic tool 
would then be able to tell where the implemented design differed from the 
intended design.  Of course if there was a tool like that, then I'd 
probably be out of a job.

> I don't have a lot of faith in automated reverse engineering from the
> code. The way it *should* be done is to do some diagramatic work first -
> not ex post facto. I'd like to do some code generation and be able to go
> back and forth between tweaking the code and updating the diagrams, so
> to that extent, reverse engineering (if that is what you would call it?)
> would be desirable. When someone builds a large system with no
> documentation, I doubt that feeding the code into a diagraming tool is
> really going to help much. There can be no substitute for meatware and a
> reverse engineering tool can't capture what was in the developer's head.
> 
My experience with reverse engineering tools also has made me rather 
pessimistic regarding their usefulness.  The remainder of the comments 
here echo the first paragraph.  In my job, there are few diagrams generated 
during the development.  Further, if diagrams are generated, they are not 
used to generate code (via some automated process).  Nor are the diagrams 
maintained over the development cycle to reflect what was actually implemented.  
The only reliable documentation is the requirements specifications; however, 
they don't dictate design.  The software design documents follow the pattern 
of the aforementioned diagrams - they are outdated by the time the actual 
software is delivered.  Product specifications follow your "ex post facto" 
observation.  Pardon my babbling.  I'm just venting my own frustration.  
Thanks for listening. :)

> My current problem is just to produce something that will facilitate
> discussion of system level issues, so I don't think reverse engineering
> will matter much.
> 
From your previous explanation, I think you are right.

> I've always believed that UNIX was the first computer virus with a GUI
> interface. :-)
> 
I like that.  Can I use it?

> I was a big VMS fan when it came to reliability. Too bad it is basically
> withering away.
> 
I've used VMS on and off for over 15 years.  I've also used quite a variety 
of other operating systems.  VMS is definitely good, but our discussion was, 
I thought, focused on PCs and I don't recall VMS being implemented on a PC.  
In the PC world, I still believe that a UNIX variant (such as LINUX) 
provides the most reliability.  I really liked OS/2 and I'd have to rate it 
up there as a close second.  Then comes NT and way at the bottom I'd list 
both Windows 95 and Windows 98.  Now if we start talking larger computers, 
then we could go on ....

> MDC

-- 
Regards,
Jeffrey D. Cherry
Senior IV&V Analyst
Logicon Space and Information Operations
Logicon Inc.
a Northrop Grumman company