Re: HOOD?

[ian@rsd.bel.alcatel.be (Ian Ward)]

In article 0@assen.demon.co.uk, john@assen.demon.co.uk (John McCabe) writes:
>Franz.Kruse@erno.de (Franz Kruse) wrote:
>
>
>>What is the general opinion of the Ada community about HOOD as a design method?
>
>>Franz Kruse
>
>
>I can't tell you the general opinion, only my opinion having used it
>over the last few years - only up to the 3.1 definition.
>
>I think it works out as a fairly reasonable method, the only pitfall
>being that it couldn't handle "provided data" after version 3.0. From
>a purist point of view this is good for encapsulation and information
>hiding etc, but it can be bad for performance. Obviously the method
>isn't going to force you not to modify your code to break the rules,
>but if you're using a tool, you then get to the point where your
>design and your implementation (code) start to diverge.
>
>The other major problem with it is a lack of tool support. There never
>were many tools, they weren't particularly good anyway (especially
>HOOD Nice from Intecs - IPSYS is much better and still supported
>because of the EFA contract), and they appear to be being dropped from
>companies' repertoires.
>
>Finally, the hierarchy could cause problems with Ada 83, and (at least
>up to 3.1) the Object Based, rather than Object-Oriented nature was
>not totally ideally suited to e.g. C++ or Ada 95 (apparently).
>
>On the whole, it was OK but I think there are probably more suitable
>methods for most things.
>
>
>
>Best Regards
>John McCabe <john@assen.demon.co.uk>
>

I like it. At the risk of sounding sacreligous, it has a structured 
nature to it. By this I mean, the Hierarchical nature to the objects
(as opposed to the free position nature of, say, Jackson Structured
Design, where a "process" can be anywhere and is open to State Vector
Inspections [or messages sent] by just any other component the
designer wishes) works in the same way that ordinary structured 
design does. This nature of HOOD is no bad thing; many engineers,
in my experience, still work with the structured engineering mindset,
having not yet had a great deal of experience with inheritance, and
dispatching. I must confess myself being, put off, ("scared by" is
probably a better phrase) by the inheritance concept, before I
understood the mechanics of the situation. 

That is not to say that JSD is bad, there are some places where "I"
think it was a good model, (I've given up using the word "abstraction"
for this, as I recently found out that it means something completely
different to what I thought it meant.) such as in distributed systems.
Here I found message passing, and SVI's to be very suited to the early 
simple message passing systems between old multiprocessor multiboard
embedded systems. This I guess could make for easy partitioning.

I do however think that more people would find HOOD an easier concept
(from scratch) than JSD, or Yourdon, though this is probably biased.
I remember some time ago the delight of feeling the penny drop with
Yourdon when somebody told me of the concept of taking one of the
Yourdon processes in my hand, and lifting it from the page, allowing
all the other connected processes hang by their dataflows, at this point
I saw how to get the best from it, how it worked if you like.

I do think that HOOD has one problem, this is not a problem with
the design, but more a flaw with the people that use it. Humans,
again I am afraid, need to be compensated for.

[Please accept my apologies, for the following explanation which I see
is without much clarity, having read it back. I know what I wish to
say, but cannot think of a good way of putting it.]

The problem I have seen, two or three times, is where, say two or
three objects use an object. One of the users has an interface
with remote software, not through I/O, which because of the design
needs to be active. An object needs to be created, using both I/O 
and one of the higher objects to allow the data to be passed back
to the user. (Because the higher level object needs to monitor
the information.)

This becomes, in effect, a buffer object. The way to get around
it is, of course, to make the monitor object passive as an internal
child of the lower level object, and to route the methods through
the lower level object into the monitor object. 
(Or at least that is the way it occurs to me to do it.)

The design works both ways of course, but a task is removed from
the final implementation in the modified instance, along with acres
of Object Control Structure Code. The absence of a select statement,
and some kind of storage array has benefits for the whole system. 
This is not the fault of the designer, I think, because I have seen
some very clever people end up with this scenario, after months of
design. It does not occur to people to think about it until it is,
perhaps getting on a bit in the project, thus they end up with
performance problems.

As such, I think the design method could be modified, perhaps, to 
prevent this scenario, or at least make the consequences of their
actions more obvious, earlier on. 

   The problem, I think, can be thought of in terms of the two
gardeners, John and Harry, repositioning a path in a garden.

Is the system such that Harry asks John to lift a flagstone from
it's seat and give it to him, so he can place it in it's new position;
or is the system such that John lifts a flag and tells Harry to put
it in it's new seat. 

This kind of process inversion, as often required with JSD, to 
convert the design to the implementation, is not the problem, per
se. The problem occurs when a lifted flagstone is found to have a body
underneath it, and someone has to phone the police. This information,
which must be passed to the controller, needs to be stored (or 
passed back as status information, but we'll ignore that case.)

In the second case where John tells Harry to place the flag,
he does not need to store the information about the dead body,
so that Harry can be FORCED to do something about it. John IS
the controller, so HE just rings the police.

I did state the other fix in there as well, which is to pass back 
status information, but the fact remains that there are three solutions
to this problem, and it is not altogether obvious that one of them
is going to, at some point in the future, cause problems with storage
and performance.

Just like languages, which should try and design out human type
errors, so should formal design methods. By that I mean somebody
noted earlier that the syntax : 

A, B : char*;

eradicates the common fault :

char *A, B; 

I know that this was one of the things that language designers of
Ada looked at.

By comparison, I have often felt that design methods have been
produced as a result of clever people simply defining formally 
the way THEY design things. They of course don't pick option
three because they have made that mistake before, and clever
people do not make the same mistake three times.

Part of the rationale behind design methods, is such that
ordinary people, who aren't geniuses, can come along, and just
turn a handle, and out shall pop something that when implemented
shall observe it's formal requirements.

I wish I could design such a design method, that designed out human
faults in design, but I am just not clever enough. I have put a lot 
of thought into this over the years, more so than just about anything
else, and have concluded that it is very easy to make a design method
which is makes for easy and effiecient implementation (such as JSP,
Note: Loops, Sequences, Conditions; not JSD there), but extremely
difficult to make it simultaneously able to model real world
solutions; a good abstraction of the problem if you like. 

As such I have a lot of respect for design method and language
designers, who have a hard time of it.

If I was clever enough, and if I did, no-one would use it anyway,
the populus would rather have something flawed, slow to use, and
cryptic. 

----------------------------------------------------------------
End of discussion of method, now onto tools.
----------------------------------------------------------------

It's not all done though, because, even though design methods
are solidifying, I will be interested to see how new HOOD design
tools cope with protected data. I suspect this functionality 
will be quite useful in saving implementations from dying due
to task buffer performance overload.

1. To rescue implementation, simply get GNAT, and replace all buffer
objects with protected Stacks and Round Robins. Make environment
objects out of buffer objects, and then use GNAT's access to posix
threads, to allow you to make your netowrk IO tasks blocking,
instead of non blocking polled comms. This will get rid of a third
of you active objects. If this does not speed up your software and
reduce code size by a third, then I'll play golf in Rennes on
holiday next year. It would be an appalling hack, but I think it
should work. Every body could perform ritual suicide on the alter
of software engineering after it was implemented, sell you soul to
the Devil etc.

I am amazed that you like the IPSYS HOOD tool John, I always thought
it was really crap. I was once HOOD tool coordinator on a small, 115
object, twenty man project, and we had a guy, claiming to be an
accountant, demanding to be paid (have you guessed the slow paying
company yet? Answers in private please, I do not want to be sued!!)
I almost choked with disbelief that they wanted money for it. However,
they have had five years to sort it out, so to be fair, I can believe
that it now works. It is good to see it has become a success, I will
bear your comments for future reference. It is amazing that I could
have been so badly tainted by poor reliability. It is not surprising
that millions of people had left the Ada scene by 1987 with a sour
taste in their mouths. Perhaps I should be a bit more forgiving, it
is difficult though when one is not enjoying the work.

As I said in an earlier post, I think TNI's STOOD tool is the best HOOD
tool I have ever used. In fact, I think it is the best tool I have ever
used of any description, full stop, the cross referencer, it gets me
tingly just thinking about it. Rock on.

Come down to earth Mr Ward. - Ed

So on the whole, I think it is a good method, it has it's faults but
often the tool one uses is as important as the method itself. 

I'm sorry this post is so long. If the mailer had, instead of saying
"Mailer failure! included text longer than addition" I would have
simply said, "Yes it's ok."

Best regards,
Ian.

---
Ian Ward's opinions only : ian@rsd.bel.alcatel.be
The author wishes not to be criticised for technical
inaccuracy of the text, and so includes the statement
near the head of his document, which he knows that the
reviewer will miss because part of it's in Latin :-)
"Due to further changes in the domain concept all given
hints concerning domains should be taken cum grano salis."