Re: HOOD?

Re: HOOD?

[John McCabe]

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>

HOOD?

[Franz Kruse]

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

Franz Kruse

Re: HOOD?

[Jean-Marie Wallut]

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 :

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

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

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

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

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.

======================================================================
  __   __   ___   ___    | Denis Minguillon & Jean-Marie Wallut
 /    /  \ /___\ /___    | CT/TI/PS/MP Bpi 1501
 \____|  | \____ ____/   | CNES - 18, av. Edouard Belin
                         | 31055 Toulouse Cedex (FRANCE)
 Centre National         |
                         | Tel    : (33) 61 27 34 49
    d'Etudes Spatiales   | Fax    : (33) 61 27 30 84
                         | E-Mail : wallut@cst.cnes.fr
=====================================================================

Re: HOOD?

[Jan Wuyts]

Franz Kruse wrote:
> 
> What is the general opinion of the Ada community about HOOD as a design method?
> 
> Franz Kruse
Just like John Mc Cabe I can only speak for myself...

I think it all boils down to the TOOL you use in support of your
methodology.
In my early days of Columbus, when we were sort of forced to use
the HSF tool (I my mind about the worsed tool I've ever seen) I
wasn't in favour of the method most likey because I hated the tool.

Nowadays, we use the 'stood' tool from TNI (Bretagne) and I see
no reason anymore to dislike the method.  The tool helps you 
every step of the way.  It helps you to generate your design
documentation (As you know there is a lot of that), It helps you
to keep your CODE inline with your DESIGN.  

There are however a few remarks to be made about the method itself.
It is quite easy to break down the problem into smaller 'objects'.
In a natural way of breaking down of the problem you end up with
A LOT of 'buffer' objects.  These get automatically translated into
'Ada tasks' since they are Active objects.  As a result, you get a
piece of SW with A LOT of simple tasks and your performance goes down
the tubes.  If you take that aspect into account when you start your 
design work and break it down in such a way that you avoid the
unnecessary buffer tasks then there is nothing against this 
HOOD method.

Cheers
-- 
                                        _____________
      Jan Wuyts (RS34)                  \     ^     /
                                         \ALC/_\TEL/
------------------------------------------\TELECOM/----
 Internet: wuytsj@rsd.bel.alcatel.be       \ ,,, /     
 Alcanet:  btmx.wuytsj                      (. .)      
-----------------------------------------o00-(_)-00o---
Alcatel Bell Telephone                        V
    Berkenrodelei 33         Phone:    (+32) 3/829.5479
     B-2660 Hoboken          Fax:      (+32) 3/829.5502
        Belgium.

Re: HOOD?

[Ian Ward]

In article 3A7B@rsd.bel.alcatel.be, Jan Wuyts <wuytsj@rsd.bel.alcatel.be> () writes:
.. Little snip...

> If you take that aspect into account  when you start your 
>design work and break it  down in such a way that you avoid the
>unnecessary buffer tasks t hen there is nothing against this 
>HOOD method.
>
>Cheers
>-- 
>                                        _____________
>      Jan Wuyts (RS34)                  \     ^     /

... another little snip ...

It seems that Jan was thinking exactly the same thing as me
here, but he put it much more succintly, just like I wish I had
been able to do. I have to agree with what he says (not just
because he's my boss :-)


---
Ian Ward's opinions only (oh, and Jan's) : ian@rsd.bel.alcatel.be

Re: HOOD?

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

Re: HOOD?

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

Re: HOOD?

[John McCabe]

ian@rsd.bel.alcatel.be (Ian Ward) wrote:

<..snip..>

>I am amazed that you like the IPSYS HOOD tool John, I always thought
>it was really crap.

I didn't say I _liked_ it, just that it was far better than the HOOD
Nice one :-)

>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!!)

So you used to work for that lot did you?  :-)

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

I've used a couple of versions of it over the last few years. It seems
to have got pretty stable, but it's by no means perfect.

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

I'm glad someone brought up this subject because I've learned of at
least 2 HOOD tools I'd never heard of before! (I haven't actually
looked into who produces HOOD tools as I've always just used what we
have).

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

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

Re: HOOD?

[John McCabe]

ian@rsd.bel.alcatel.be (Ian Ward) wrote:

<..snip..>

>It seems that Jan was thinking exactly the same thing as me
>here, but he put it much more succintly, just like I wish I had
>been able to do. I have to agree with what he says
>(not just because he's my boss :-)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That's what they all say :-)


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

Re: HOOD?

[John McCabe]

Hugh Dunne <dunneh@lhd.logica.com> wrote:

<..snip..>
>As for tools, stay well away from Concerto - it is a total dog! It is by
>far the most user-hostile, obscure, idiosyncratic and all-round
>infuriating piece of software I've ever had to endure.

Interesting - someone tried to mandate that for use on my project,
then once that had failed, tried to mandate HOOD Nice.

>Select Software used to do a cheap and cheerful HOOD tool which didn't do
>code generation but had just about everything I needed - this was several
>years ago so I don't know what they offer at present.

I was aware of the Select HOOD tool, PC based wasn't it? I believe
that it has been dropped though, possibly in favour of OMT but don't
take my word for it.

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

Re: HOOD?

[John McCabe]

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

>In our previous message we used "we" because we were two of us writing
>(jean-Marie Wallut & Denis Minguillon). We didn't think we were expessing
>the opinion of CNES poeple but only our vue as responsible of development
>methods.

Thank you for that clarification.

>We agree with John McCabe when he says that the hierarchical aspect can
>bring some inefficiency in the resulting code. But we also think that coding
>style and performance always need a compromise. This compromise is not the
>same depending on the fact that the software to design is an onboard
>realtime software with strong constraints or a piece of ground segment.
>However the compromise is always possible. One can design a hierarchical
>solution and then, making sure he respects it, find some bypasses to enhance
>performance (supress parent level for example).

I do agree here. My own point of view (which I obviously haven't
explained clearly) is from an on-board realtime system with very tight
time constraints so this may help to explain where my views are
derived from.


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

Re: HOOD?

[Hugh Dunne]

On the plus side, I think the basic idea of HOOD is very sensible. When
you have an extremely complex system, dividing it up hierarchically is
(or at least can be) a natural way of getting a handle on it and taming
the complexity.

On the other hand, HOOD is formalised to a very large degree and this is
bad. With any methodology there is a temptation to tart it up with fancy
symbols and force an appearance of rigour and universality on it that
just isn't justified, and HOOD is particularly prone to this. The reason
this is bad is that instead of the methodology being a *tool* which helps
you to get the work done, it starts to drive the work and creates more
work for you to do, more things to dot and cross. In my experience
everyone who uses HOOD has to adapt it to their own needs and relax some
of the more onerous restrictions, otherwise they'd never get much code
written. The outcome is a constant battle between the developers and
the customer's QA auditors who want to see every little rule and
regulation followed to the letter even if it totally obscures the design!

As for tools, stay well away from Concerto - it is a total dog! It is by
far the most user-hostile, obscure, idiosyncratic and all-round
infuriating piece of software I've ever had to endure.

Select Software used to do a cheap and cheerful HOOD tool which didn't do
code generation but had just about everything I needed - this was several
years ago so I don't know what they offer at present.

DISCLAIMER (since my .sig is probably not explicit enough) - the above
opinions are strictly my own personal opinions and in no way reflect
the opinions of Logica.
-- 
--------------- http://www.vjf.com/PUBLIC/86/27186.html ---------------
Hugh Dunne/Logica UK Ltd/Stephenson House/75 Hampstead Rd/London NW1 2PL
Should any of my posts be flamed, Logica     #     dunneh@lhd.logica.com
will disavow any knowledge of my actions.    #     +44 171 446-1608

HOOD?

[Jean-Marie Wallut]

In our previous message we used "we" because we were two of us writing
(jean-Marie Wallut & Denis Minguillon). We didn't think we were expessing
the opinion of CNES poeple but only our vue as responsible of development
methods.

We agree with John McCabe when he says that the hierarchical aspect can
bring some inefficiency in the resulting code. But we also think that coding
style and performance always need a compromise. This compromise is not the
same depending on the fact that the software to design is an onboard
realtime software with strong constraints or a piece of ground segment.
However the compromise is always possible. One can design a hierarchical
solution and then, making sure he respects it, find some bypasses to enhance
performance (supress parent level for example).

Jean-Marie Wallut & Denis Minguillon

Re: HOOD?

[Michel.Guyot]

I've been aware of information circulating about the HOOD tools
and, in particular, a sharp comment (from Hugh Dunne) about the 
Concerto tool. Being a  provider of this tool, I'm glad Hugh claims
that the opinion he expresses is strictly a personal one.

All tools have qualities and drawbacks. We have some critics from 
Concerto users and they are welcome. They help us improve the tool as
we've done several times, in the successive versions.

However, no one ever rejected the Concerto tool and we can state that
most of the users are happy with it. Moreover, it is recommended by the
European Space Agency (in the ESSDE environment) and is used in
several European space projects as well as in important defence and
energy projects.

I wonder if Hugh has a problem with the method (he doesn't seem very
enthousiastic about it). Or is it that he prefers a simple tool
like Select Software which has limited functionalities and therefore
is much easier to use. In my opinion, a powerful tool is the best way
to take full advantage of the HOOD method.

In any case, Concerto/HOOD proceeds with its successful career
and brings to its users new important facilities such as the
recent "reverse Ada/HOOD" feature making easier to update the design
after modification of the code, and thus helping to keep the design
and the code consistent.

--------------------------------------------------------------------------

Gerard Cohen
Sema Group, Fontenay-sous-bois, France
Email: Gerard.Cohen@sema-taa.fr

Re: HOOD?

[Hugh Dunne]

"Michel.Guyot" <mguyot@sema-taa.fr> wrote:

>I wonder if Hugh has a problem with the method (he doesn't seem very
>enthousiastic about it). Or is it that he prefers a simple tool
>like Select Software which has limited functionalities and therefore
>is much easier to use. In my opinion, a powerful tool is the best way
>to take full advantage of the HOOD method.

I recognise that Concerto is a powerful tool with a lot of features.
My problem with it is that the user interface is highly idiosyncratic,
counterintuitive and inconsistent, and follows no conventions that I'm
aware of. What is the point of having powerful features if people can't
figure out how to use them?
-- 
--------------- http://www.vjf.com/PUBLIC/86/27186.html ---------------
Hugh Dunne/Logica UK Ltd/Stephenson House/75 Hampstead Rd/London NW1 2PL
The above are strictly my own personal opinions  | dunneh@lhd.logica.com
and in no way reflect the opinions of Logica.    | +44 171 446-1608

Re: HOOD?

[John McCabe]

Hugh Dunne <dunneh@lhd.logica.com> wrote:

>"Michel.Guyot" <mguyot@sema-taa.fr> wrote:

<..snip..>

>I recognise that Concerto is a powerful tool with a lot of features.
>My problem with it is that the user interface is highly idiosyncratic,
>counterintuitive and inconsistent, and follows no conventions that I'm
>aware of. What is the point of having powerful features if people can't
>figure out how to use them?

This type of problem seems to be quite common with tools of this sort.
I find IPSYS Hood a bit of a handful at times because the
functionality of the mouse buttons (for example) seems to be a bit hit
and miss. Sometimes you use the right button to get a menu up,
sometimes the left, selecting text is very odd, and theres no apparent
support for cut and paste in the ODS editor.

I've also been looking at Teamwork by Cadre recently, and it also
seems to be a bit idiosyncratic and hit and miss, especially when
you're trying to attach text to a data flow in the DFD editor!

And the HOOD Nice interface has its quirks as well (we had trouble
trying to get it to run under Motif for a start never mind getting it
to look consistent across X Servers!)

The PC based tools however seem to stick a bit closer to the usual PC
conventions (i.e. ^C to copy, ^V to paste and so on).

If only the manufacturers paid a bit more attention to this kind of
thing, they may find that criticism of their products is much more
constructive. The user interface is supposed to be there to facilitate
the use of the tool (and method), not to hinder it, and an irritating
and inconsistent user interface is highly likely to give the user a
negative attitude towards the tool from the outset.



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