Re: RTSA vs. OO approach to RTE design

Re: RTSA vs. OO approach to RTE design

[Ken Garlington]

Paul Van Bellinghen 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?

Keep in mind there is a third option: use RTSA for requirements and an
obejct-based approach for design. The Software Productivity Consortium's
ADARTS methodology (which has been used on multiple 1MSLOC+ real-time
projects) is one such example which is targeted to use with Ada 83. SPC
provides extensive training and support. (Some Lockheed Martin companies
are members of the SPC).

> 
> --
> Paul Van Bellinghen
> Staff Analyst
> Lockheed Martin Fairchild
> pvanbell@mhv.net

Re : RTSA vs. OO approach to RTE design

[Laurentau]

>Sujet : 	RTSA vs. OO approach to RTE design
>De :	"Paul Van Bellinghen" <pvanbell@mhv.net>
>Date :	13 Jul 1997 00:46:42 GMT
>
>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.

Yes : this is a very important point. In the compagny where I work (they
don't pay me enough to make me give their name :-), there were a report
written on this subject. A team cannot start from scratch such a work. It
means that you will need some "gurus" to help you not to make too much
MAJOR errors. And the team must be "young enough" to be able to switch to
object oriented stuff.

BTW, I am not sure that pure object oriented thinking is good for real
time software. If the implementation rely on high level objects, are you
sure that you'll be able to control the timings ?

L. Aufrechter

RTSA vs. OO approach to RTE design

[Paul Van Bellinghen]

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?

-- 
Paul Van Bellinghen
Staff Analyst
Lockheed Martin Fairchild
pvanbell@mhv.net

Re: RTSA vs. OO approach to RTE design

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

Re: Re : RTSA vs. OO approach to RTE design

[Joseph Wisniewski]

Side note. Over the years I have seen Ada projects claim that they use
"OO" and have not a clue what that means to Ada projects that never
use the term "OO" but have VERY good package interfacing scheme. The
answer to the following question tells me more about the understanding
of what OO is supposed to do than the use of any methodology or tool.

"Tell me how you decided to design your packages"

Joe     

Laurentau <laurentau@aol.com> wrote:
: >Sujet : 	RTSA vs. OO approach to RTE design
: >De :	"Paul Van Bellinghen" <pvanbell@mhv.net>
: >Date :	13 Jul 1997 00:46:42 GMT
: >
: >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.

: Yes : this is a very important point. In the compagny where I work (they
: don't pay me enough to make me give their name :-), there were a report
: written on this subject. A team cannot start from scratch such a work. It
: means that you will need some "gurus" to help you not to make too much
: MAJOR errors. And the team must be "young enough" to be able to switch to
: object oriented stuff.

: BTW, I am not sure that pure object oriented thinking is good for real
: time software. If the implementation rely on high level objects, are you
: sure that you'll be able to control the timings ?

: L. Aufrechter



-- 
Joe Wisniewski
President, Commercial Software Solutions, Ltd.

Full Onsite/Offsite Software Engineering Consulting Services
Specializing in Embedded RealTime Applications and Training

4403 W. Chama Suite #101
Glendale, Arizona 85310

(Voice) 602-580-4008	888-229-7597
(Fax)   602-580-4010    888-568-8734
wisniew@primenet.com

Co-Author: Program Smarter, Not Harder. 
           Get Mission-Critical Projects Right the First Time
           ISBN: 0-07-021232-5 McGraw-Hill