home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / ada / 3290 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  2.5 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!sdd.hp.com!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!wupost!uwm.edu!linac!att!ucbvax!efftoo.boeing.com!crispen
  2. From: crispen@efftoo.boeing.com (crispen)
  3. Newsgroups: comp.lang.ada
  4. Subject: SA/SD Documentation of an OBD Design
  5. Message-ID: <9211161358.AA29045@efftoo.boeing.com>
  6. Date: 16 Nov 92 13:58:36 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 38
  11.  
  12. I'm so confused!  Look, gang, you perform vanilla systems engineering,
  13. right?  And you end up with partitions that allocate your functional
  14. requirements to components in some sort of decomposition step, right?
  15. Or don't you OODers have any functional requirements to allocate?
  16. Didn't think so.
  17.  
  18. But once you've finished decomposing your system, there's a step in
  19. vanilla systems engineering practice called "synthesis".  Or at least
  20. there is unless the "elegance" of your functional decomposition fools
  21. you into thinking that you've already got a design.
  22.  
  23. Could it be that the reason everybody thinks that functional decomposition
  24. sucks is that nobody has done a *design*?
  25.  
  26. We have recently had an experience in redevelopment for STARS where
  27. we tried to incorporate what we knew at the time about the SEI's
  28. Air Vehicle Structural Model.  The segments and the top-level functions
  29. were derived from functional decomposition, but once you got inside
  30. the segments, it was what we've been calling "object focused design".
  31.  
  32. The biggest surprise was that there were no surprises, no disconnects.
  33. I suspect that when we enlarge our domain (as we're required to do on
  34. another STARS program) and when we understand Structural Modeling
  35. a little better, we're going to have to iterate our decomposition/synthesis
  36. process a few times.  Surprise, surprise!  That's what you *do*!
  37.  
  38. So what's the big deal?  You begin by allocating your requirements,
  39. 'cause you have to.  Then you build a design that suits your problem
  40. domain and solution domain the best (you know, a domain-specific
  41. software architecture) -- perhaps (probably?) using some sort of
  42. object-oriented/object-abstracted architecture.  Then you iterate.
  43.  
  44. Or have I got it all wrong?
  45. +-------------------------------+--------------------------------------+
  46. | Bob Crispen                   |   The owls are not what they seem    |
  47. | crispen@foxy.boeing.com       +--------------------------------------+
  48. | (205) 461-3296                |Opinions expressed here are mine alone|
  49. +-------------------------------+--------------------------------------+
  50.