comp.lang.ada
 help / color / mirror / Atom feed
From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com>
Subject: SA/SD Documentation of an OBD Design
Date: Mon, 16 Nov 92 07:58:36 CST	[thread overview]
Message-ID: <9211161358.AA29045@efftoo.boeing.com> (raw)

I'm so confused!  Look, gang, you perform vanilla systems engineering,
right?  And you end up with partitions that allocate your functional
requirements to components in some sort of decomposition step, right?
Or don't you OODers have any functional requirements to allocate?
Didn't think so.

But once you've finished decomposing your system, there's a step in
vanilla systems engineering practice called "synthesis".  Or at least
there is unless the "elegance" of your functional decomposition fools
you into thinking that you've already got a design.

Could it be that the reason everybody thinks that functional decomposition
sucks is that nobody has done a *design*?

We have recently had an experience in redevelopment for STARS where
we tried to incorporate what we knew at the time about the SEI's
Air Vehicle Structural Model.  The segments and the top-level functions
were derived from functional decomposition, but once you got inside
the segments, it was what we've been calling "object focused design".

The biggest surprise was that there were no surprises, no disconnects.
I suspect that when we enlarge our domain (as we're required to do on
another STARS program) and when we understand Structural Modeling
a little better, we're going to have to iterate our decomposition/synthesis
process a few times.  Surprise, surprise!  That's what you *do*!

So what's the big deal?  You begin by allocating your requirements,
'cause you have to.  Then you build a design that suits your problem
domain and solution domain the best (you know, a domain-specific
software architecture) -- perhaps (probably?) using some sort of
object-oriented/object-abstracted architecture.  Then you iterate.

Or have I got it all wrong?
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   The owls are not what they seem    |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+

             reply	other threads:[~1992-11-16 13:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1992-11-16 13:58 crispen [this message]
  -- strict thread matches above, loose matches on Subject: below --
1992-11-15 22:20 SA/SD Documentation of an OBD Design agate!linus!linus.mitre.org!linus!sdl
1992-11-13 16:03 cis.ohio-state.edu!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!qt.cs.utexas.edu!news.Brown.EDU!noc.near.net!inmet!ryer
1992-11-12 14:20 cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!newsserver.pixel.kodak.c
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox