Re: HOOD?

[john@assen.demon.co.uk (John McCabe)]

Jean-Marie Wallut <Jean-Marie.Wallut@CST.CNES.FR> wrote:

>Franz.Kruse@erno.de (Franz Kruse) wrote:


>>What is the general opinion of the Ada community about HOOD as a design
>method?

>>Franz Kruse

>We would like to explain why we think HOOD is an excellent design method
>particularly for Ada developments :

"We"?

I imagine CNES are not exactly impartial in their opinions on the HOOD
method - check out its history w.r.t. Matra/CNES/ESA.

>- first of all we think that the concepts of the methods are very good :
>encapsulation (as in every object oriented method) but also hierarchy that
>promotes the strict definition of interfaces between separate domains at
>each level of the design. This last feature is very important for
>prototyping and/or for shared development.

However the hierarchy does cause problems with system size and
performance when you get to the implementation level. It also caused
implementation difficulties with Ada 83 because hierarchical objects
(e.g. packages) were not supported by that language. This resulted in
many tasks being generated by the code generators of the tools (as
mentioned by Jan Wuyts) and hence inefficient systems with a lot of
hand modification required. I haven't looked into Ada 95 use of HOOD
yet but I get the impression the hierarchy could work better there.

>- complete corerage of the development process from the first brain storming
>to the final coding with the same technology. This changes from previous
>methods that used different technologies
>for each phase that implies translation between several formalisms (with
>risks of non respect of what was approved at the previous phase)

That's interesting. I know for definite that at least up to version
3.1. of the HOOD definition there was NO coverage for requirements
capture and analysis except effectively a note that these should be
done and inserted in the document. In order to overcome this
fundamental weakness it was common for the tool manufacturers (e.g.
IPSYS and Cadre) to stick on a Yourdon based front end to their tools.

>- One can make a strict correspondance between the explanations he gives in
>the textual part of an object in his design and the code resulting from
>these design decisions.

True.

>The layered approche makes this strict correspondance easy. Specially for
>Ada development each feature of the method is directely implemented by an
>Ada feature (a parent object is a package specification, a terminal object
>as a body for implementing his "duty", an internal data is a variable in the
>body etc....).

True.

>Some rules have been added thant enhance the quality of the
>generated Ada (for example it is forbidden to offer a data in the provided
>interface of an object that is to say in an Ada specification : this avoid
>data to be modified by any client of the object responsible of the data.

Yes and also leads to inefficient code through the use of too many
levels of "buffering" (as Jan Wuyts mentioned).

>- More and more the design can be independant from the design tools. The
>concept of SIF (Standard Interchange Format) allows to bring a design from a
>tool to another one (even if the SIF does not take into account some aspects
>as the graphical aspect of the solution and also if the tools do not all
>implement perfectly the SIF import/export).

Close but in my experience SIF has not been particularly well
implemented and it's been practically impossible to import from one
tool into another.

>Our opinion is based on our personnal feeling from personnal developments
>but also on the fact that at the moment each project developped in Ada in
>our company is designed in HOOD and the results are good in most of the cases.

>Last point to focus on is that the method is evolving to take into account
>the new concepts of Ada 95 that is to say inheritance an polymorphism. These
>new possiblities combined with hierarchy (as soon as one knows how to use
>properly both features together) can make of HOOD an even more powerful method.

I would agree with this to some extent but I feel that it's come too
late in the day as there are probably better OO design methods around
now.

A problem with HOOD is that it is basically ESA/Matra's baby, and I
get the impression that because of their investment in the method, its
use is almost mandated for ESA projects even where an OO based method
may not be the most suitable method for the job. I know that that has
been the case on my current project.

It's clear though that as long as you understand the how the tool you
are using implements the method with respect to its mapping onto Ada,
then you can take account of it early on in the design cycle and HOOD
should prove to be a very reasonable method to use as long as the
system you are designing maps well onto an object based design.

I think this is very important, don't use HOOD just because it is OO.
Make sure your system is suitable for that kind of design - not all
are!


Best Regards
John McCabe <john@assen.demon.co.uk>