SA/SD Documentation of an OBD Design

SA/SD Documentation of an OBD Design

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!newsserver.pixel.kodak.c]

We are completing an object based *redesign* of an existing medium
sized application (~300K LOC).

We have been using a modified Booch approach in the redesign
and have employed abstraction and encapsulation (but not
inheritance or dynamic binding since we are using Ada).
All of the people involved in the object based redesign believe
that this is a much better design than the SA/SA design that exists.

Now management has decided that we must document the object
based design using SA/SD. They want to se dataflows and possibly
structure charts. We are unsure about how to do this since
the design truly reflects the object model. In addition,
this is the first time we have faced this situation since all
of our past OBD and OOD projects were documented in an OOD
form.

We are looking for suggestions and opinions on the wisdom of
this approach. Any help would be appreciated. Thanks in
advance.

Joe Dvorak
dvorak@sunfs1.dsd.northrop.com

Re: SA/SD Documentation of an OBD Design

[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]

943 at Northrup asks:

How do you document an OOD design using SA/SD?  Here are some suggestions:

1. Once you've got it fully coded, use an automatic flowcharting tool to
generate a few hundred pounds of paper.  I'll testify that it looks like
SA/SD to me.

2. Take the SA/SD documentation from your last (not necessarily related) 
project, and attach the OOD documentation for this project as an appendix.
Put in a colored separator page.  No one will know the difference.

3. Buy an expensive CASE tool with re-engineering capability, and assign
some people (not your friends) to convert the design.  After a few years,
report to managment that you need another million dollars (or they can
settle for the OOD stuff instead).

4.  Write an introduction that says you analyzed and decomposed the design
into one component, using SA/SD, and then provide a copy of the OOD as
added-value backup information about the fine-grained detail of that component.

Hope that helps.

Mike "speaking only for myself" Ryer

Re: SA/SD Documentation of an OBD Design

[agate!linus!linus.mitre.org!linus!sdl]

In article <943@ast.dsd.northrop.com> dvorak@ast.dsd.northrop.com (dvorak josep
h l.) writes:

> Now management has decided that we must document the object
> based design using SA/SD. 

Why?

> They want to se dataflows and possibly
> structure charts. 

I would suggest finding out exactly what *problem* management is
trying to solve with this "solution".  Perhaps there is a way to meet
their concerns and solve their problem with some part of your
(existing) OBD or OOD approach?

Remind them:  "Before you propose a solution, be sure you understand
what the *problem* is you are trying to solve."



Steven Litvintchouk
MITRE Corporation
202 Burlington Road
Bedford, MA  01730

Fone:  (617)271-7753
ARPA:  sdl@mitre.org
UUCP:  linus!sdl
	"Where does he get those wonderful toys?"
--
Steven Litvintchouk
MITRE Corporation
202 Burlington Road
Bedford, MA  01730

Fone:  (617)271-7753
ARPA:  sdl@mitre.org
UUCP:  linus!sdl
	"Where does he get those wonderful toys?"

SA/SD Documentation of an OBD Design

[crispen]

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|
+-------------------------------+--------------------------------------+