* Re: HOOD? @ 1996-07-19 0:00 Michel.Guyot 1996-07-19 0:00 ` HOOD? Hugh Dunne 0 siblings, 1 reply; 16+ messages in thread From: Michel.Guyot @ 1996-07-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HOOD? 1996-07-19 0:00 HOOD? Michel.Guyot @ 1996-07-19 0:00 ` Hugh Dunne 1996-07-19 0:00 ` HOOD? John McCabe 0 siblings, 1 reply; 16+ messages in thread From: Hugh Dunne @ 1996-07-19 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HOOD? 1996-07-19 0:00 ` HOOD? Hugh Dunne @ 1996-07-19 0:00 ` John McCabe 0 siblings, 0 replies; 16+ messages in thread From: John McCabe @ 1996-07-19 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* HOOD? @ 1996-07-08 0:00 Jean-Marie Wallut 1996-07-08 0:00 ` HOOD? John McCabe 0 siblings, 1 reply; 16+ messages in thread From: Jean-Marie Wallut @ 1996-07-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HOOD? 1996-07-08 0:00 HOOD? Jean-Marie Wallut @ 1996-07-08 0:00 ` John McCabe 0 siblings, 0 replies; 16+ messages in thread From: John McCabe @ 1996-07-08 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HOOD? @ 1996-07-04 0:00 Jean-Marie Wallut 1996-07-04 0:00 ` HOOD? John McCabe 0 siblings, 1 reply; 16+ messages in thread From: Jean-Marie Wallut @ 1996-07-04 0:00 UTC (permalink / raw) 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 ===================================================================== ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HOOD? 1996-07-04 0:00 HOOD? Jean-Marie Wallut @ 1996-07-04 0:00 ` John McCabe 1996-07-08 0:00 ` HOOD? Hugh Dunne 0 siblings, 1 reply; 16+ messages in thread From: John McCabe @ 1996-07-04 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HOOD? 1996-07-04 0:00 ` HOOD? John McCabe @ 1996-07-08 0:00 ` Hugh Dunne 1996-07-08 0:00 ` HOOD? John McCabe 0 siblings, 1 reply; 16+ messages in thread From: Hugh Dunne @ 1996-07-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HOOD? 1996-07-08 0:00 ` HOOD? Hugh Dunne @ 1996-07-08 0:00 ` John McCabe 0 siblings, 0 replies; 16+ messages in thread From: John McCabe @ 1996-07-08 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* HOOD? @ 1996-07-02 0:00 Franz Kruse 1996-07-02 0:00 ` HOOD? John McCabe 1996-07-04 0:00 ` HOOD? Jan Wuyts 0 siblings, 2 replies; 16+ messages in thread From: Franz Kruse @ 1996-07-02 0:00 UTC (permalink / raw) What is the general opinion of the Ada community about HOOD as a design method? Franz Kruse ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HOOD? 1996-07-02 0:00 HOOD? Franz Kruse @ 1996-07-02 0:00 ` John McCabe 1996-07-04 0:00 ` HOOD? Ian Ward 1996-07-04 0:00 ` HOOD? Jan Wuyts 1 sibling, 1 reply; 16+ messages in thread From: John McCabe @ 1996-07-02 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HOOD? 1996-07-02 0:00 ` HOOD? John McCabe @ 1996-07-04 0:00 ` Ian Ward 1996-07-05 0:00 ` HOOD? John McCabe 0 siblings, 1 reply; 16+ messages in thread From: Ian Ward @ 1996-07-04 0:00 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HOOD? 1996-07-04 0:00 ` HOOD? Ian Ward @ 1996-07-05 0:00 ` John McCabe 0 siblings, 0 replies; 16+ messages in thread From: John McCabe @ 1996-07-05 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HOOD? 1996-07-02 0:00 HOOD? Franz Kruse 1996-07-02 0:00 ` HOOD? John McCabe @ 1996-07-04 0:00 ` Jan Wuyts 1996-07-04 0:00 ` HOOD? Ian Ward 1 sibling, 1 reply; 16+ messages in thread From: Jan Wuyts @ 1996-07-04 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HOOD? 1996-07-04 0:00 ` HOOD? Jan Wuyts @ 1996-07-04 0:00 ` Ian Ward 1996-07-05 0:00 ` HOOD? John McCabe 0 siblings, 1 reply; 16+ messages in thread From: Ian Ward @ 1996-07-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HOOD? 1996-07-04 0:00 ` HOOD? Ian Ward @ 1996-07-05 0:00 ` John McCabe 0 siblings, 0 replies; 16+ messages in thread From: John McCabe @ 1996-07-05 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~1996-07-19 0:00 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-07-19 0:00 HOOD? Michel.Guyot 1996-07-19 0:00 ` HOOD? Hugh Dunne 1996-07-19 0:00 ` HOOD? John McCabe -- strict thread matches above, loose matches on Subject: below -- 1996-07-08 0:00 HOOD? Jean-Marie Wallut 1996-07-08 0:00 ` HOOD? John McCabe 1996-07-04 0:00 HOOD? Jean-Marie Wallut 1996-07-04 0:00 ` HOOD? John McCabe 1996-07-08 0:00 ` HOOD? Hugh Dunne 1996-07-08 0:00 ` HOOD? John McCabe 1996-07-02 0:00 HOOD? Franz Kruse 1996-07-02 0:00 ` HOOD? John McCabe 1996-07-04 0:00 ` HOOD? Ian Ward 1996-07-05 0:00 ` HOOD? John McCabe 1996-07-04 0:00 ` HOOD? Jan Wuyts 1996-07-04 0:00 ` HOOD? Ian Ward 1996-07-05 0:00 ` HOOD? John McCabe
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox