From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6fc39bb88f30631d X-Google-Attributes: gid103376,public From: ian@rsd.bel.alcatel.be (Ian Ward) Subject: Re: HOOD? Date: 1996/07/04 Message-ID: <4rgp4p$iv6@btmpjg.god.bel.alcatel.be> X-Deja-AN: 163688210 distribution: world references: <836340235.16937.0@assen.demon.co.uk> organization: Alcatel Bell Telephone reply-to: ian@rsd.bel.alcatel.be newsgroups: comp.lang.ada Date: 1996-07-04T00:00:00+00:00 List-Id: 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 > 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."