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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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: john@assen.demon.co.uk (John McCabe) Subject: Re: HOOD? Date: 1996/07/04 Message-ID: <836505513.6472.2@assen.demon.co.uk> X-Deja-AN: 163710726 x-nntp-posting-host: assen.demon.co.uk references: <199607041313.PAA22700@imhotep.cst.cnes.fr> newsgroups: comp.lang.ada Date: 1996-07-04T00:00:00+00:00 List-Id: Jean-Marie Wallut 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