home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / ada / 2582 < prev    next >
Encoding:
Text File  |  1992-09-10  |  3.9 KB  |  80 lines
  1. Newsgroups: comp.lang.ada
  2. Path: sparky!uunet!spool.mu.edu!umn.edu!The-Star.honeywell.com!saifr00.cfsat.honeywell.com!hawkinsg
  3. From: hawkinsg@saifr00.cfsat.honeywell.com (Glenn Hawkins)
  4. Subject: Controlling Type Definition - Is it useful/necessary?
  5. Message-ID: <1992Sep10.162550.5675@saifr00.cfsat.honeywell.com>
  6. Organization: Honeywell Air Transport Systems Division
  7. Distribution: comp.ada
  8. Date: Thu, 10 Sep 92 16:25:50 GMT
  9. Lines: 69
  10.  
  11. Howdy!
  12.  
  13. I am a software engineer working on the Boeing 777 avionics suite at
  14. Honeywell in Phoenix, and I have a question about an aspect of the design
  15. process with Ada that I've been wondering about for some time now.  It's quite
  16. possible that I'm missing a basic concept that would make this
  17. question completely unnecessary.  If so, please feel free to set me straight.
  18. Otherwise, any help would be greatly appreciated on the following subject:
  19.  
  20. We have completed our OORA and are now in the early stages of preliminary 
  21. design (class to package/type transformation, final selector/constructor
  22. definition, etc.) and are trying to figure out a process to rigorously control
  23. the definition and placement of types throughout the system.  I know on my old 
  24. program (pre-Honeywell) that engineers, once they got below the specification 
  25. level, were allowed to define types and subtypes willy nilly, with the result 
  26. that during system integration an incredible number of type incompatibility 
  27. problems such as lost accuracy, constraint errors, and the like occurred.  It
  28. was also pretty difficult to maintain.  We always swore to ourselves, that, if
  29. we had it to do over again, we would establish rigorous controls over the 
  30. definition of types in a system to avoid people stepping on each other 
  31. (or on themselves, in many cases). 
  32.  
  33. I might interject here that many of you may have already decided that 
  34. we did not properly encapsulate our abstractions in the past if we could "step
  35. all over each other" - i.e. we did not do a "good" Ada design.  This is entirely
  36. possible.  However, in our current design (using OOA/OOD methods) I feel that
  37. we have a very good system architecture, and yet I can see the possibility
  38. of sloppy type definitions (and the resulting side effects) severely impacting
  39. our integration effort if we are not careful.  The big, "important" types are
  40. defined and in a sense controlled by the interface contracts (Ada specs) we 
  41. have developed as part of our requirements analysis.  Pre and post conditions,
  42. visibility issues, dependencies, etc. have all been worked out in the OORA.
  43. I'm talking about the local types down in the bodies that are defined on the
  44. fly at 3:00 am by the designer who just wants to get SOMETHING to compile for
  45. the inspection package due the next day.  NOT the right way to code, I know, 
  46. but it happens!
  47.  
  48. So, all you Ada gurus out there - How do you control the proliferation of 
  49. type definitions in a large (>10,000 Ada SLOC) system?  Do you even need to?  
  50. Does a "good" Ada design avoid all these problems for you?  What guidelines 
  51. exist for the definition and placement of "non-major" (not externally visible?)
  52. Ada types in a well-designed system?
  53.  
  54. Specifically, are there any efficient process steps that you can take 
  55. that are cheap (in terms of overhead) and easy (so the designers won't mind
  56. doing them) in order to evaluate ALL types/subtypes in the system in terms of:
  57.  
  58.     a) Is it really needed?
  59.     b) Does anyone else need it (is this the right place for it)?
  60.     c) Does it cause problems "up the ladder" (i.e. violate an 
  61.         abstraction/encapsulation)?
  62.     d) Has it already been defined?
  63.  
  64. I'd be happy to post a summary of all responses received through E-mail.
  65.  
  66.                    N.B. - ALL flames will be cheerfully ignored.
  67.  
  68. with STANDARD_DISCLAIMER; 
  69.  
  70. Glenn Hawkins
  71. Senior Project Engineer
  72. Honeywell, Inc.
  73. Air Transport Systems Division
  74. Phoenix, AZ
  75.  
  76. "You can put lipstick on a hog and call it Monique and it's STILL a pig".
  77. --Ann Richards, Governor of Texas
  78.  
  79. "hawkinsg@saifr00.cfsat.honeywell.com"
  80.