Re: RTSA vs. OO approach to RTE design

[nobody@REPLAY.COM (Anonymous)]

On 13 Jul 1997 00:46:42 GMT, "Paul Van Bellinghen" <pvanbell@mhv.net>
wrote:

> My company has been using the principles of Real-Time Structured Analysis
> to design the software for its real-time embedded systems for several years
> (we use Cadre Teamwork with Rational Apex Ada (83) - cross compiled with
> VADScross). They (primarily our SW engineering manager) claim that they
> have nothing against an object oriented approach but that none of their SW
> engineers are trained in applying its principles to an actual system
> design. Not being all that knowledgeable in OO design myself, I was
> wondering if anyone  is familiar with both approaches to requirements
> design/implementation and can give an opinion as to which approach is
> better for RT embedded systems?

If your designs are nicely modular, with highly cohesive, loosely
coupled modules that encapsulate data structures and the operations on
them, then they are already object oriented. They are not inheritance or
dispatching oriented, but I don't see that those attributes have
anything to do with being object oriented; they are implementation
features, while being object oriented is a design feature. Inheritance
and dispatching may be inappropriate for your real-time systems; only
you can decide.

We used to work to obtain such modules, which we called "Parnas
modules". Now we call them "objects".

However, if you're doing RTSA, you're analyzing by decomposing into
functions. In order to create objects, you then re-analyze by
decomposing into objects so you can synthesize them into a design. This
is a waste of time, and I doubt that the 2nd analysis is properly
rigorous or documented. So what you're talking about is eliminating the
1st analysis, obtaining all the information you need from the 2nd
analysis, and making the 2nd analysis properly rigorous and documented.

This makes it seem less mysterious and intimidating, doesn't it? The
problem is that the term "object oriented" has become synonymous with
"inheritance and dispatching oriented". Everything you read about object
orientation has a lot to say about inheritance and dispatching, and
little or nothing to say about objects. The highly touted "OO" methods
concentrate on inheritance, with the assumption that dispatching will be
used in the implementation.

There are definite advantages to going to a true object-oriented
approach from the start, such as eliminating the informal 2nd analysis,
and making your analysis documents more relevant to your design and
code. However, it's a difficult transition to make alone, and most of
the consultants out there think that something's object oriented if it
uses inheritance and dispatching. Good luck.

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"Now go away, or I shall taunt you a second time."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/