Re: Popular Design Diagram Methods For Ada

Re: Popular Design Diagram Methods For Ada

[Ted Dennison]

In article <38986B2C.D4BDB7A4@quadruscorp.com>,
  "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:
> I have a large body of Ada code which may need some "reverse
> engineering" That is to say, producing some design documentation by
> analysis of the code. Its been a while since I've had to deal with an
> issue such as this, so what I would like to know is: What is/are the
> currently popular design methodologies for Ada and what tools are
> currently in vogue for doing this design work?

When last I used ObjectTeam it had the ability to reverse-engineer into
UML. It has since been bought by Sterling Software and is now
COOL:somethingorother.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Popular Design Diagram Methods For Ada

[Marin D. Condic]

I have a large body of Ada code which may need some "reverse
engineering" That is to say, producing some design documentation by
analysis of the code. Its been a while since I've had to deal with an
issue such as this, so what I would like to know is: What is/are the
currently popular design methodologies for Ada and what tools are
currently in vogue for doing this design work?

Quite some time ago, there were tools available from IDE (Software thru
Pictures?) Mark V Systems and a bunch of other companies. (We went on to
build our own at the time.) What might be available today? 

Are there any papers on the web that describe design methodologies that
fit well with Ada? Any freeware tools to draw diagrams? Any commercially
available tools to do this?

If you have any favorite design methodologies and/or tools that you
think do a good job with Ada, please respond here and/or to my e-mail
address as it appears in my trailer. Thanks.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Popular Design Diagram Methods For Ada

[Chris M. Moore]

On Wed, 02 Feb 2000 20:37:25 GMT, Ted Dennison <dennison@telepath.com>
wrote:

>In article <38986B2C.D4BDB7A4@quadruscorp.com>,
>  "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:

>> I have a large body of Ada code which may need some "reverse
>> engineering" That is to say, producing some design documentation by
>> analysis of the code. Its been a while since I've had to deal with an
>> issue such as this, so what I would like to know is: What is/are the
>> currently popular design methodologies for Ada and what tools are
>> currently in vogue for doing this design work?

I can't help thinking that design comes before coding and that you
should have a design to document already.  If it's locked in the head
of some ex-employee then I guess a few derrived diagrams are better
than nothing...

>When last I used ObjectTeam it had the ability to reverse-engineer into
>UML. It has since been bought by Sterling Software and is now
>COOL:somethingorother.

So once expressed in UML can you code generate C++?  Would you want
to?  :-)

--
Chris M. Moore
Software engineer
speaking for myself

Re: Popular Design Diagram Methods For Ada

[Jeffrey D. Cherry]

My group has looked at a lot of Ada code.  The software that we've looked 
at was developed by different companies (I'm with the IV&V contractor).  It's 
almost exclusively Ada83, but there is some Ada95.  The various projects 
range in size from about 30KLOC to over 250KLOC.  As you would expect, we're 
always looking for better tools to automate the code analysis process.  We 
can't depend on the developer's software design diagrams since they often 
don't exist or are not updated through the long development cycle.  We also 
need to focus on the code, since its what actually does the work.  Another 
limitation is that we only have PCs on which we may do the analysis.  Thus, 
any tool we consider must run under Windows 95/98 or NT.  We have one Linux 
machine that we've just recently acquired, so things are looking up.

Given the above context, and if you're talking just code analysis ... not, for 
example, requirements tracking or automated testing ... then we've been using 
a tool called "Understand for Ada" by Scientific Toolworks, Inc.  They also 
have a C++ and FORTRAN variant of the same tool.  Their web site is at 
http://www.scitools.com.  We've found that this tool gives you the most 
bang for the buck.  It generates a variety of reports and diagrams that 
we've found quite useful, and the latest version (1.3, currently in beta 
but due out at the end of February) is an impressive improvement over the 
previous version (1.2.7).  The tool doesn't generate UML diagrams (I'll 
address that topic below) but the diagrams it does generate gives you an idea 
of structure and other dependency relationships.  The browser makes 
navigation of these diagrams easy and we use the text reports for additional 
processing and analysis.

We've tried reverse engineering options in tools such as Rational's Rose and 
Software Through Pictures from Aonix, but were unimpressed with their results.  
The reason these reverse engineering tools don't help that much is because we 
look at (mostly) Ada83 code and these tools generate UML diagrams.  Since Ada83 
isn't as object-oriented as Ada95, the resulting class diagrams are 
uninformative.  This isn't a failure of the tool but merely a consequence of 
the implementation.  What we would like to see in these reverse engineering 
tools, but haven't seen, is as follows:

1) Class diagrams should use the data type name for the class name, and 
component boxes should list all the explicitly defined primitive operations 
on the type.  Implicit primitive operations could be listed as well but 
should be "hidable" from the diagram.

2) Component diagrams should be generated to show the relationships of the 
source files and their resulting application programs and/or libraries.

3) For a given subprogram, generate an activity diagram.

Other UML diagrams are, IMHO, not creatable from the source without some, or  
a lot of, input from the user.  Use Case diagrams, I think, are not derivable 
from the code, but must be generated by the user(s).  Statechart diagrams 
would be very difficult to generate from the code due the variety of ways to 
implement a state machine.  Sequence diagrams might be generated for common 
GUIs, but would require help from the user for event definition and 
callback routines, and at the very least would require processing files 
other than Ada source.  Collaboration diagrams would be even more difficult 
since the interaction must be defined by the user.  Deployment diagrams may 
be generated but again require the user to define the partitioning of 
applications to nodes, etc.  Something that, once again, can't be derived 
from the source code.

If you have money that you can devote to a project, you may want to consider 
using ASIS to develop your own analysis tools.  We've identified several 
ASIS tools that we'd like to develop but simply don't have the resources.  
Also, if you use a real operating system (i.e. _not_ Windows), there are 
many more analysis tools available.

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

Re: Popular Design Diagram Methods For Ada

[Marin D. Condic]

Chris M. Moore wrote:
> 
> I can't help thinking that design comes before coding and that you
> should have a design to document already.  If it's locked in the head
> of some ex-employee then I guess a few derrived diagrams are better
> than nothing...
> 
You are pretty close to exactly on target. There is no documentation for
the body of code I am examining. I wouldn't do it that way, but what's
done is done. Now the job involves doing various systems analysis things
and we think we'd be better off with at least some sketchy diagrams that
illustrate the links between various subsystems, etc. So I'm off on a
quest for a design methodology & tools which are the current "state of
the art" and would allow us to diagram general Ada structures since the
software was not entirely built on one specific methodology. (Its Ada83
and has some Object Oriented appearance, but is not entirely so. I've
got to represent any Ada structures - in particular tasks.)

At one time, I took a cursory look at the HOOD design methodology but I
don't recall where I found documentation on it. I also don't know if it
is currently very popular. I'd like to steer this project (and future
ones) towards something that is fairly common and which has a good
future. I don't want to be stranded with something obscure and
unsupported.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Popular Design Diagram Methods For Ada

[Marin D. Condic]

Jeffrey D. Cherry wrote:
> 
> Given the above context, and if you're talking just code analysis ... not, for
> example, requirements tracking or automated testing ... then we've been using
> a tool called "Understand for Ada" by Scientific Toolworks, Inc.  They also
> have a C++ and FORTRAN variant of the same tool.  Their web site is at
> http://www.scitools.com.  We've found that this tool gives you the most

I've used their AdaDL tool in the past and it did useful things for us
at the time. In this case, I don't think I'm looking so much for some
sort of static code analysis as I am looking for a diagraming tool. What
we need to do is more at a gross level rather than resolving detailed
design issues. It's not so much a case of trying to identify where some
variable is declared or what is the "with" chain for a specific module
as it is a case of identifying how all the CSCs hang together, how and
what they communicate to each other, etc.

A "reverse engineering" tool that produced some sort of diagrams showing
who calls what might be helpful. I don't think that is as critical to
our problem as other factors though. My experience with reverse
engineering from code has been pretty disappointing, so I'd rather have
a tool I can use to draw my own diagrams with after using the meatware
to look over the code. I also want to select a methodology and tool with
which we can also go forward with future designs.

Helpful Hint For Toolmakers: A design tool that lets you draw things at
a gross level and then "push down" into details (or "pop up" from
details to a higher context) would be *very* useful. Also, the ability
to flag features such that they can be "filtered out" of the view of a
diagram would be useful. Think about how a package may have one major
type and a handful of important subprograms. Yet there may be a
half-dozen other visible types which are necessary, but unimportant to
understanding what the package is all about. Being able to specify
levels of importance and filtering out the details (a sort of "zoom"
function) would be a very handy thing to have. 

As I said elsewhere, I need something that supports the full Ada
language so that we can represent any Ada structures that occur. I'm not
against something that supports OOD, but it has to allow us to step
outside of that box when the code doesn't fit that model.


> The reason these reverse engineering tools don't help that much is because we
> look at (mostly) Ada83 code and these tools generate UML diagrams.  Since Ada83
> isn't as object-oriented as Ada95, the resulting class diagrams are
> uninformative.  This isn't a failure of the tool but merely a consequence of

I've heard many mentions of UML diagrams. I must admit my ignorance in
this area. For the last 10 or so years, I've been designing with a
custom tool aimed specifically at Control Laws problems - Its a
specialty that is not as well served by "general purpose" software
design methodologies. As a result, I've not kept up with most of the
recent developments in design methodologies. Could you point me at any
web resources that describe UML and anything related to it?

> If you have money that you can devote to a project, you may want to consider
> using ASIS to develop your own analysis tools.  We've identified several
> ASIS tools that we'd like to develop but simply don't have the resources.
> Also, if you use a real operating system (i.e. _not_ Windows), there are
> many more analysis tools available.
> 
We should all be so lucky as to have enough money to spend on custom
tool development! :-) I think I'd disagree about the "real operating
system" part - at least if we're talking Windows-NT and its descendents.
We need Windows as one platform for a design tool, but we'd also like to
be able to run on Sun boxes. The reality of the world is that lots of
platforms exist and a tool needs to be available on many of them if it
wants to succeed. If it only runs on Sun/Unix, I can't make use of it in
all the places it would need to run.

Thanks for the info. Anything else you can suggest would be appreciated.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Popular Design Diagram Methods For Ada

[Jeffrey D. Cherry]

Comments interspersed ...

"Marin D. Condic" wrote:
> 
> I've used their AdaDL tool in the past and it did useful things for us
> at the time. In this case, I don't think I'm looking so much for some
> sort of static code analysis as I am looking for a diagraming tool. What
> we need to do is more at a gross level rather than resolving detailed
> design issues. It's not so much a case of trying to identify where some
> variable is declared or what is the "with" chain for a specific module
> as it is a case of identifying how all the CSCs hang together, how and
> what they communicate to each other, etc.

I'd like that as well, and if you find something, please let me know where 
I can get my hands on it.  IMHO, the problem here is that I don't think there 
is any way to derive CSC structure from code unless the developer followed 
a structured design methodology, or the tool can divine the intentions of 
the developer's thoughts on CSC interaction.  If the developer used an 
object-oriented approach, then Rose and Software Through Pictures (StP) can 
help tremendously since that is their underlying assumption when those tools 
reverse engineering a set of software.  The Understand for Ada tool can 
help in the diagramming of call trees, with trees, used by trees, etc., so if 
a structured design were originally used on the software, you'll get a good 
part of the CSC structure and interaction captured.  Since their text 
reports repeat the graphic tree in text form, you may be able to import it 
into a drawing tool.  This would give you a start on a drawing with the 
basic structure defined.  You could then add and move things around based on 
your experience with the code in order to recover the original CSC design.

> A "reverse engineering" tool that produced some sort of diagrams showing
> who calls what might be helpful. I don't think that is as critical to
> our problem as other factors though. My experience with reverse
> engineering from code has been pretty disappointing, ...

Ditto.

> so I'd rather have
> a tool I can use to draw my own diagrams with after using the meatware
> to look over the code. I also want to select a methodology and tool with
> which we can also go forward with future designs.

I agree, but I'm sure you realize that this is still a largely manual 
process.  It would be great to be able to automate such an activity.

> Helpful Hint For Toolmakers: A design tool that lets you draw things at
> a gross level and then "push down" into details (or "pop up" from
> details to a higher context) would be *very* useful. Also, the ability
> to flag features such that they can be "filtered out" of the view of a
> diagram would be useful. Think about how a package may have one major
> type and a handful of important subprograms. Yet there may be a
> half-dozen other visible types which are necessary, but unimportant to
> understanding what the package is all about. Being able to specify
> levels of importance and filtering out the details (a sort of "zoom"
> function) would be a very handy thing to have.

I couldn't have said it better myself.

> As I said elsewhere, I need something that supports the full Ada
> language so that we can represent any Ada structures that occur. I'm not
> against something that supports OOD, but it has to allow us to step
> outside of that box when the code doesn't fit that model.

Yes this should be a capability of a great tool, to use either a structured 
design or a object-oriented design.  Likewise I'd like to be able to tell 
an idealistic reverse engineering tool that the software was developed using 
a structured approach, or an OO approach, and then have it generate the 
appropriate diagrams.  Once the diagrams were generated, I would like to 
be able to extend the design (by manipulating the diagrams) and then have 
the tool forward engineer the appropriate changes.  Now that's what I call 
round trip engineering. ;)

> I've heard many mentions of UML diagrams. I must admit my ignorance in
> this area. For the last 10 or so years, I've been designing with a
> custom tool aimed specifically at Control Laws problems - Its a
> specialty that is not as well served by "general purpose" software
> design methodologies. As a result, I've not kept up with most of the
> recent developments in design methodologies. Could you point me at any
> web resources that describe UML and anything related to it?

Start at Rational's web site at http://www.rational.com, then follow the 
link for the "UML Resource Center".  If you're looking for a pseudo-intro 
book to UML, I liked the book "UML Toolkit" by Hans-Erik Eriksson and 
Magnus Penker.  If you get into the real-time UML stuff, then I highly 
recommend the book "Doing Hard Time, Developing Real-Time Systems with 
UML, Objects, Frameworks, and Patterns" by Bruce Powel Douglass.  It's a 
_great_ book!

> We should all be so lucky as to have enough money to spend on custom
> tool development! :-) I think I'd disagree about the "real operating
> system" part - at least if we're talking Windows-NT and its descendents.
> We need Windows as one platform for a design tool, but we'd also like to
> be able to run on Sun boxes. The reality of the world is that lots of
> platforms exist and a tool needs to be available on many of them if it
> wants to succeed. If it only runs on Sun/Unix, I can't make use of it in
> all the places it would need to run.

I use Windows NT on my PC at home.  I can also boot Windows 98 since I use 
IBM's boot manager from the Partition Magic product.  But the last time I 
booted Windows 98 was the day I finished the Tomb Raider III game, about 
7 months ago.  I definitely think NT is more reliable and useful than 
either Windows 95 or 98, but there are much more reliable operating systems 
than NT, UNIX variants being the most prominent.

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

Re: Popular Design Diagram Methods For Ada

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]


Marin D. Condic <mcondic-nospam@quadruscorp.com> a �crit dans le message :
3899C331.94E24911@quadruscorp.com...
> At one time, I took a cursory look at the HOOD design methodology but I
> don't recall where I found documentation on it. I also don't know if it
> is currently very popular. I'd like to steer this project (and future
> ones) towards something that is fairly common and which has a good
> future. I don't want to be stranded with something obscure and
> unsupported.
>
HOOD is used in Europe, mainly for space (it is funded by ESA), energy and
transportation project. There is information (and further links) about HOOD
on Adalog's page: http://pro.wanadoo.fr/adalog. There are several vendors of
HOOD tools.

Small plug here: if you are interested in HOOD, I'll be giving a half-day
tutorial on HOOD at the upcomming Ada-Europe conference.
--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Popular Design Diagram Methods For Ada

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1278 bytes --]


Marin D. Condic <mcondic-nospam@quadruscorp.com> a �crit dans le message :
3899CE45.FDF88C8F@quadruscorp.com...
> Helpful Hint For Toolmakers: A design tool that lets you draw things at
> a gross level and then "push down" into details (or "pop up" from
> details to a higher context) would be *very* useful. Also, the ability
> to flag features such that they can be "filtered out" of the view of a
> diagram would be useful. Think about how a package may have one major
> type and a handful of important subprograms. Yet there may be a
> half-dozen other visible types which are necessary, but unimportant to
> understanding what the package is all about. Being able to specify
> levels of importance and filtering out the details (a sort of "zoom"
> function) would be a very handy thing to have.
>
If that's what you want, then you should *really* have a look at HOOD. The
leading ideas  behind the method are "separate concerns" and "manage
complexity".

UML/OMT is a terrific tool to *show* all the complexity of a design, but
HOOD is a very effective method to *hide* (and manage) the complexity.

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Popular Design Diagram Methods For Ada

[Marin D. Condic]

Jean-Pierre Rosen wrote:
> HOOD is used in Europe, mainly for space (it is funded by ESA), energy and
> transportation project. There is information (and further links) about HOOD
> on Adalog's page: http://pro.wanadoo.fr/adalog. There are several vendors of
> HOOD tools.
> 
Thanks for the link. I'll check it out.

> Small plug here: if you are interested in HOOD, I'll be giving a half-day
> tutorial on HOOD at the upcomming Ada-Europe conference.

I'd love to do it, but unfortunately, I'm stuck here in California for a
while. I doubt I could get the time & funding to go to Europe for a
tutorial. :-) However if there are any papers to come out of it, I'd be
interested in looking them over.

Thanks again.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Popular Design Diagram Methods For Ada

[Marin D. Condic]

Jean-Pierre Rosen wrote:
> If that's what you want, then you should *really* have a look at HOOD. The
> leading ideas  behind the method are "separate concerns" and "manage
> complexity".
> 
Well, I've always felt that it is very important to have some sort of
overall "block diagram" of a large system so that you can talk about the
big issues. You also need some ability to keep fleshing that out with
more and more details until you can see where all the rivets and bolts
are located. Having the ability to zoom in and out to various levels of
complexity is something I've always wanted in a design tool, but in most
of the things I've looked at, this is only supported weakly. Of course
it has been a number of years since I last went through this exercise of
trying to evaluate design methodologies and tools, so maybe things have
improved some.

If I can find a document describing HOOD, I'll definitely read it over.
It sounds like you are saying the methodology itself supports a layered
view of a large system. I'm hoping that despite the name, it is not
limited to describing only Object Oriented Design, since I've got to
cover software that is not structured this way.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Popular Design Diagram Methods For Ada

[Marin D. Condic]

Jeffrey D. Cherry wrote:
> 
> I'd like that as well, and if you find something, please let me know where
> I can get my hands on it.  IMHO, the problem here is that I don't think there
> is any way to derive CSC structure from code unless the developer followed
> a structured design methodology, or the tool can divine the intentions of
> the developer's thoughts on CSC interaction.  If the developer used an

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. ;-)


> Yes this should be a capability of a great tool, to use either a structured
> design or a object-oriented design.  Likewise I'd like to be able to tell
> an idealistic reverse engineering tool that the software was developed using
> a structured approach, or an OO approach, and then have it generate the
> appropriate diagrams.  Once the diagrams were generated, I would like to
> be able to extend the design (by manipulating the diagrams) and then have
> the tool forward engineer the appropriate changes.  Now that's what I call
> round trip engineering. ;)
> 
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.

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 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.

> 7 months ago.  I definitely think NT is more reliable and useful than
> either Windows 95 or 98, but there are much more reliable operating systems
> than NT, UNIX variants being the most prominent.
> 
I've always believed that UNIX was the first computer virus with a GUI
interface. :-)

I was a big VMS fan when it came to reliability. Too bad it is basically
withering away.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Popular Design Diagram Methods For Ada

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 757 bytes --]


Marin D. Condic <mcondic-nospam@quadruscorp.com> a �crit dans le message :
389B14F0.4473C2FC@quadruscorp.com...
> > Small plug here: if you are interested in HOOD, I'll be giving a
half-day
> > tutorial on HOOD at the upcomming Ada-Europe conference.
>
> I'd love to do it, but unfortunately, I'm stuck here in California for a
> while. I doubt I could get the time & funding to go to Europe for a
> tutorial. :-) However if there are any papers to come out of it, I'd be
> interested in looking them over.
>
Well, you can get the official HOOD book... from Adalog (another plug ;-)

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Popular Design Diagram Methods For Ada

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2939 bytes --]


Marin D. Condic <mcondic-nospam@quadruscorp.com> a �crit dans le message :
389B1783.473576F5@quadruscorp.com...
> Jean-Pierre Rosen wrote:
> > If that's what you want, then you should *really* have a look at HOOD.
The
> > leading ideas  behind the method are "separate concerns" and "manage
> > complexity".
> >
> Well, I've always felt that it is very important to have some sort of
> overall "block diagram" of a large system so that you can talk about the
> big issues. You also need some ability to keep fleshing that out with
> more and more details until you can see where all the rivets and bolts
> are located. Having the ability to zoom in and out to various levels of
> complexity is something I've always wanted in a design tool, but in most
> of the things I've looked at, this is only supported weakly. Of course
> it has been a number of years since I last went through this exercise of
> trying to evaluate design methodologies and tools, so maybe things have
> improved some.
HOOD is for large designs, but you NEVER see all the details of the whole
structure. Remember that the 'H' in the name stands for "Hierarchical".
Either you see a few main blocks (but not what's inside), or you zoom into a
module and see its internals, but you don't see the outside anymore (except
for the connections to the outside world, but I won't give the whole
tutorial here :-)

> If I can find a document describing HOOD, I'll definitely read it over.
> It sounds like you are saying the methodology itself supports a layered
> view of a large system. I'm hoping that despite the name, it is not
> limited to describing only Object Oriented Design, since I've got to
> cover software that is not structured this way.
>
As I mentionned in the previous message, the official document is the HOOD
book ("HOOD: an Industrial Approach for Software Design", by HOOD User Group
and (hum) J-P. Rosen). Direct link:
http://pro.wanadoo.fr/adalog/hoodbook.htm. Note that you can view the
"overview" chapter of the book directly off this page, so it would give you
an idea.

The "OOD" in the name refers mainly to Booch-1 ("Software Engineering with
Ada") OOD, that is mostly composition-oriented, although there is now
support for inheritance,  but certainly not as a major direction. Over the
time, HOOD became less directive about the design process, so that it can
now be used with various design approaches.

(After reading you next message).
HOOD supports virtual nodes for the distribution of applications. You design
your application independently from distribution, then project it over a
logical structure of virtual nodes, which in turn get assigned to physical
nodes. Note BTW that this process matches very well with Annex E (although
designed independently)

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Popular Design Diagram Methods For Ada

[Pierre Dissaux]

Marin D. Condic wrote:
> 
> ...
>
> If I can find a document describing HOOD, I'll definitely read it over.
> It sounds like you are saying the methodology itself supports a layered
> view of a large system. I'm hoping that despite the name, it is not
> limited to describing only Object Oriented Design, since I've got to
> cover software that is not structured this way.
> 

You can find a few downloadable papers about the HOOD method on our
site, and a free demo version of a HOOD tool (STOOD) for Windows and
Unix:

 http://www.tni.fr/contact/formgb.htm?prod=stood

Among proposed documentation (pdf):
- The HOOD4 Reference Manual (parts 1 to 4)
- A technical paper related to HRT-HOOD (HOOD for Hard Real-Time)
- The STOOD User's Manual (parts 1 to 3)
- Ada2HOOD User's Manual (a free reverse engineering tool)
- and several other technical papers.

You can also find "success stories" at:

 http://www.tni.fr/produits/genielo/stood/tigregb.htm
 http://www.tni.fr/produits/genielo/stood/poseidongb.htm
 http://www.tni.fr/produits/genielo/stood/poldergb.htm
 http://www.tni.fr/produits/genielo/stood/dorisgb.htm
 http://www.tni.fr/produits/genielo/stood/dimosgb.htm

All that will be available in a few weeks on a CD-Rom. We will be
pleased to send a copy of it to anyone interested, upon simple request.

Pierre Dissaux
TNI

Re: Popular Design Diagram Methods For Ada

[Jeffrey D. Cherry]

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

Re: Popular Design Diagram Methods For Ada

[Marin D. Condic]

Pierre Dissaux wrote:

> You can find a few downloadable papers about the HOOD method on our
> site, and a free demo version of a HOOD tool (STOOD) for Windows and
> Unix:

Thanks for the info. I had earlier downloaded the STOOD demo, but have
not downloaded all the documentation. I have driven the tool around in a
cursory manner and have not yet figured out how to do all the things I
think I need to do. The tools seems very much oriented towards Object
Oriented Design (that should be a surprise?) and so I am not sure it
meets my needs. My current need is to create some documentation for
existing software that was not built strictly on an OOD paradigm. Hence,
I need some ability just to make general pictures that represent
packages, procedures and tasks and be able to illustrate
interrelationships between them. (Tasks being internal to packages, one
package withing and calling another, etc.)

So far with the STOOD tool I have not been able to determine how to show
interconnections between library level packages and mostly there seems
to be no method of describing tasks. I'm sure that some of this will
become more apparent as I sift through the documentation, but my initial
reaction is that I won't meet my "general purpose" requirement with this
tool.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Popular Design Diagram Methods For Ada

[Jean St-Pierre]

For documentation of existing software, I just downloaded this week an
evaluation copy of Understand Ada from http://www.scitools.com/ and ran a
test case. It did a pretty good job. I've just started looking at it really,
so I can't tell if it will do everything you need. It's worth a try anyway.
The only problem I've encountered until now is getting readable printouts
(too large if I use "print poster" and too small if I use "print drawing").

Marin D. Condic <mcondic-nospam@quadruscorp.com> wrote in message
news:38A05CA8.9F671DAF@quadruscorp.com...
> Pierre Dissaux wrote:
>
> > You can find a few downloadable papers about the HOOD method on our
> > site, and a free demo version of a HOOD tool (STOOD) for Windows and
> > Unix:
>
> Thanks for the info. I had earlier downloaded the STOOD demo, but have
> not downloaded all the documentation. I have driven the tool around in a
> cursory manner and have not yet figured out how to do all the things I
> think I need to do. The tools seems very much oriented towards Object
> Oriented Design (that should be a surprise?) and so I am not sure it
> meets my needs. My current need is to create some documentation for
> existing software that was not built strictly on an OOD paradigm. Hence,
> I need some ability just to make general pictures that represent
> packages, procedures and tasks and be able to illustrate
> interrelationships between them. (Tasks being internal to packages, one
> package withing and calling another, etc.)
>
> So far with the STOOD tool I have not been able to determine how to show
> interconnections between library level packages and mostly there seems
> to be no method of describing tasks. I'm sure that some of this will
> become more apparent as I sift through the documentation, but my initial
> reaction is that I won't meet my "general purpose" requirement with this
> tool.
>
> MDC
> --
> =============================================================
> Marin David Condic   - Quadrus Corporation -   1.800.555.3393
> 1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
> http://www.quadruscorp.com/
> m c o n d i c @ q u a d r u s c o r p . c o m
>
> Visit my web site at:  http://www.mcondic.com/
>
> "Capitalism without failure is like religion without sin."
>         --  Allan Meltzer, Economist
> =============================================================