procedural vs object oriented

procedural vs object oriented

[Ananth the Boss]

i am working in Ada based flight software development project.as a
means of improving i took to the CASE tool based development.ours is a
procedural approach of development.but the commercial CASE tools speak
a lot about class/object/UML.how will this suit for procedure oriented
development where we dont have necessity to identify classes and do
detailed design as mentioned in OO aproach

Re: procedural vs object oriented

[Jean-Pierre Rosen]

Ananth the Boss a �crit :
> i am working in Ada based flight software development project.as a
> means of improving i took to the CASE tool based development.ours is a
> procedural approach of development.but the commercial CASE tools speak
> a lot about class/object/UML.how will this suit for procedure oriented
> development where we dont have necessity to identify classes and do
> detailed design as mentioned in OO aproach
> 
There is no sin in not being object-oriented, it all depends on your 
needs. Especially in real-time, procedural approaches are often better 
when ensuring WCET is important.

UML is an object oriented approach, and is not appropriate for 
procedural development. Other tools supporting SART for example might be 
more appropriate.

The need must be lead the choice of the tool, not the other way round!
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: procedural vs object oriented

[Jeffrey R. Carter]

Jean-Pierre Rosen wrote:
> 
> The need must be lead the choice of the tool, not the other way round!

As someone used to say, a fool with a tool is still a fool.

-- 
Jeff Carter
"Many times we're given rhymes that are quite unsingable."
Monty Python and the Holy Grail
57

Re: procedural vs object oriented

[Dmitry A. Kazakov]

On 26 Apr 2006 01:16:04 -0700, Ananth the Boss wrote:

> i am working in Ada based flight software development project.as a
> means of improving i took to the CASE tool based development.ours is a
> procedural approach of development.but the commercial CASE tools speak
> a lot about class/object/UML.how will this suit for procedure oriented
> development where we dont have necessity to identify classes and do
> detailed design as mentioned in OO aproach

I would not equalize OO with UML.

Ada is a nice language. You'd probably need less tools when working in Ada,
either OO or not.

Class/object is a different story. Even if you don't need OOA for your
problem space. It depends on how much code you'd like to reuse. You can use
generics for that, or tagged types, which are traditionally counted for OO
and "classes." But in any case you will need to identify and refactor
these.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: procedural vs object oriented

[bh]

"Ananth the Boss" <anboss@gmail.com> wrote in message
news:1146039364.130635.181590@v46g2000cwv.googlegroups.com...
> i am working in Ada based flight software development project.as a
> means of improving i took to the CASE tool based development.ours is a
> procedural approach of development.but the commercial CASE tools speak
> a lot about class/object/UML.how will this suit for procedure oriented
> development where we dont have necessity to identify classes and do
> detailed design as mentioned in OO aproach
>

If you don't _know_ how to do good OO with Ada, I'd recommend against it.
We tried a project using OO and I think it is pretty safe to say we didn't
get what we were hoping for. I think your results will be better with
procedural.

Re: procedural vs object oriented

[Ludovic Brenta]

"bh" <no-spam@nosuchaddress.com> writes:
> "Ananth the Boss" <anboss@gmail.com> wrote in message
> news:1146039364.130635.181590@v46g2000cwv.googlegroups.com...
>> i am working in Ada based flight software development project.as a
>> means of improving i took to the CASE tool based development.ours is a
>> procedural approach of development.but the commercial CASE tools speak
>> a lot about class/object/UML.how will this suit for procedure oriented
>> development where we dont have necessity to identify classes and do
>> detailed design as mentioned in OO aproach
>>
>
> If you don't _know_ how to do good OO with Ada, I'd recommend against it.
> We tried a project using OO and I think it is pretty safe to say we didn't
> get what we were hoping for. I think your results will be better with
> procedural.

According to Robert Dewar during FOSDEM, nobody uses OOP in avionics
software, because the uncertainty inherent to dynamic dispatching
hinders certification.  Is someone on this newsgroup in a position to
give a counter-example?

-- 
Ludovic Brenta.

Re: procedural vs object oriented

[Dmitry A. Kazakov]

On Thu, 27 Apr 2006 07:22:21 +0200, Ludovic Brenta wrote:

> "bh" <no-spam@nosuchaddress.com> writes:
>> "Ananth the Boss" <anboss@gmail.com> wrote in message
>> news:1146039364.130635.181590@v46g2000cwv.googlegroups.com...
>>> i am working in Ada based flight software development project.as a
>>> means of improving i took to the CASE tool based development.ours is a
>>> procedural approach of development.but the commercial CASE tools speak
>>> a lot about class/object/UML.how will this suit for procedure oriented
>>> development where we dont have necessity to identify classes and do
>>> detailed design as mentioned in OO aproach
>>
>> If you don't _know_ how to do good OO with Ada, I'd recommend against it.
>> We tried a project using OO and I think it is pretty safe to say we didn't
>> get what we were hoping for. I think your results will be better with
>> procedural.
> 
> According to Robert Dewar during FOSDEM, nobody uses OOP in avionics
> software, because the uncertainty inherent to dynamic dispatching
> hinders certification.  Is someone on this newsgroup in a position to
> give a counter-example?

Can't tell about avionics, but what uncertainty of dynamic dispatching is
meant? Or, maybe, "certification" is the context of? Then which
certification, according to which criteria?

Talking about uncertainty in general, what about "inherent uncertainty" of
a procedure call? Can you tell which procedures will be called and when at
run time? If you can then, you can also do it for dispatching calls. Are
generic bodies more certain? With "with function "*" (Left, Right : Foo)
return Foo"? Really?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: procedural vs object oriented

[Ludovic Brenta]

Dmitry A. Kazakov wrote:
> On Thu, 27 Apr 2006 07:22:21 +0200, Ludovic Brenta wrote:
>> According to Robert Dewar during FOSDEM, nobody uses OOP in avionics
>> software, because the uncertainty inherent to dynamic dispatching
>> hinders certification.  Is someone on this newsgroup in a position to
>> give a counter-example?
>
> Can't tell about avionics, but what uncertainty of dynamic dispatching is
> meant? Or, maybe, "certification" is the context of? Then which
> certification, according to which criteria?

Dynamic dispatching, by definition, means that you don't know which
subprogram you call at run-time. The compiler guarantees that the call
will succeed (i.e. that there exists a subprogram to dispatch to), but
there is uncertainty about which one it is.

DO-178B does not prohibit dynamic dispatching; it only requires that
the program be completely deterministic, and it requires the software
developers to provide reasonable proof that the program is indeed
deterministic.

If you use dynamic dispatching in a program, you must therefore prove
that you know precisely which subprogram you call each time you execute
the dispatching call. At DO-178B level A, you must also prove that the
machine code in the executable program dispatches correctly and in a
deterministic way, in bounded time and memory conditions. This
additional burden of proof is on the developer. That's what I meant
when I said that dynamic dispatching hinders certification.

The question of "how to I use dynamic dispatching while keeping the
certification costs reasonable" is quite interesting, complicated, and
has received a lot of thought, but no clear answer has come out of it.
So, for now, the only clear-cut answer in the conservative world of
avionics is, "you don't."

> Talking about uncertainty in general, what about "inherent uncertainty" of
> a procedure call? Can you tell which procedures will be called and when at
> run time? If you can then, you can also do it for dispatching calls. Are
> generic bodies more certain? With "with function "*" (Left, Right : Foo)
> return Foo"? Really?

A static procedure call has no uncertainty: when you read the program
source, you know exactly which subprogram is called, even in the
presence of overloading.

When you instantiate a generic, you also know exactly which subprogram
you pass as a parameter. Again there is no inherent uncertainty here.

At Barco, our coding standards prohibit access-to-subprogram values,
and require all generics to be preelaborated. Thus they eliminate all
uncertainty and make all subprogram calls statically deterministic.
Needless to say, our coding standards also prohibit dynamic
dispatching.

-- 
Ludovic Brenta.

Re: procedural vs object oriented

[Maciej Sobczak]

Ludovic Brenta wrote:

> A static procedure call has no uncertainty: when you read the program
> source, you know exactly which subprogram is called, even in the
> presence of overloading.

If Shape.Type = Triangle Then
   Draw_Triangle(Shape);
ElsIf Shape.Type = Rectangle Then
   Draw_Rectangle(Shape);
Else
   Put("Damn, I never thought we will have more shape types.");
End If;

In what way is this better or more certain than a dispatching call based 
on the tag?


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: procedural vs object oriented

[Ludovic Brenta]

Because:

* the dispatching logic is visible in the source and therefore easy to
trace to object code (you always certify the machine code, not the
source code).

* you see, at the call site, the complete list of possible call
targets.

Besides, peer review would reject your code. You should have used a
case statement with no "others" clause, and thought about all possible
shape types up-front.

-- 
Ludovic Brenta.

Re: procedural vs object oriented

[Pascal Obry]

Maciej Sobczak a �crit :

> In what way is this better or more certain than a dispatching call based
> on the tag?

Static analysis is possible in this case.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: procedural vs object oriented

[Georg Bauhaus]

Pascal Obry wrote:
> Maciej Sobczak a �crit :
> 
>> In what way is this better or more certain than a dispatching call based
>> on the tag?
> 
> Static analysis is possible in this case.

But static analysis should be possible for the following
program, too, as long as for example `cons` returns references
to object of a known finite set of types derived from T...

At least possible in some defined set of cases, if slightly
more difficult.

procedure dis is

   package p is

      type T is tagged null record;
      type REF is access T'class;

      procedure op(x: T);

      type D1 is new T with null record;
      procedure op(x: D1);

      type D2 is new T with null record;
      procedure op(x: D2);
   end P;

   use P;

   function cons return REF;

   y: REF := cons;
begin
   op(y.all);
end;

Re: procedural vs object oriented

[Dmitry A. Kazakov]

On 27 Apr 2006 03:42:10 -0700, Ludovic Brenta wrote:

> Dmitry A. Kazakov wrote:
>> On Thu, 27 Apr 2006 07:22:21 +0200, Ludovic Brenta wrote:
>>> According to Robert Dewar during FOSDEM, nobody uses OOP in avionics
>>> software, because the uncertainty inherent to dynamic dispatching
>>> hinders certification.  Is someone on this newsgroup in a position to
>>> give a counter-example?
>>
>> Can't tell about avionics, but what uncertainty of dynamic dispatching is
>> meant? Or, maybe, "certification" is the context of? Then which
>> certification, according to which criteria?
> 
> Dynamic dispatching, by definition, means that you don't know which
> subprogram you call at run-time. The compiler guarantees that the call
> will succeed (i.e. that there exists a subprogram to dispatch to),

(I have an impression that it will not be true in Ada 200Y.)

> but there is uncertainty about which one it is.

OK, but this is the same uncertainty as in X + 1. You don't know X, so the
result selected by "+" is uncertain (to you.) Are programs using "+"
certifiable?

> DO-178B does not prohibit dynamic dispatching; it only requires that
> the program be completely deterministic, and it requires the software
> developers to provide reasonable proof that the program is indeed
> deterministic.

Very sensible, IMO.

> If you use dynamic dispatching in a program, you must therefore prove
> that you know precisely which subprogram you call each time you execute
> the dispatching call. At DO-178B level A, you must also prove that the
> machine code in the executable program dispatches correctly and in a
> deterministic way, in bounded time and memory conditions. This
> additional burden of proof is on the developer. That's what I meant
> when I said that dynamic dispatching hinders certification.

OK, it could make things more difficult.

>> Talking about uncertainty in general, what about "inherent uncertainty" of
>> a procedure call? Can you tell which procedures will be called and when at
>> run time? If you can then, you can also do it for dispatching calls. Are
>> generic bodies more certain? With "with function "*" (Left, Right : Foo)
>> return Foo"? Really?
> 
> A static procedure call has no uncertainty: when you read the program
> source, you know exactly which subprogram is called, even in the
> presence of overloading.

Well, no:

if Read (File) then
   Foo;
else
   Bar;
end if;

The uncertainty of a dispatching call is one of the context, exactly as in
the example above. Provided, that there is nothing uncertain in how
dispatching works or what potential targets do.

> When you instantiate a generic, you also know exactly which subprogram
> you pass as a parameter. Again there is no inherent uncertainty here.

My question was about the body. If you are required to check each
instantiation, then it effectively means that you cannot certify the
generic body itself, only concrete instances of. This is no different from
a dynamically polymorphic body. Both forms of polymorphism save work
exactly because you don't need to care about specific instances. If the
certification procedure does not play with, there is little gain.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: procedural vs object oriented

[Ludovic Brenta]

Dmitry A. Kazakov wrote:
> On 27 Apr 2006 03:42:10 -0700, Ludovic Brenta wrote:
>> Dynamic dispatching, by definition, means that you don't know which
>> subprogram you call at run-time. The compiler guarantees that the call
>> will succeed (i.e. that there exists a subprogram to dispatch to),
>> but there is uncertainty about which one it is.
>
> (I have an impression that it will not be true in Ada 200Y.)

No, nothing changes in this respect, just synctactic sugar.

> OK, but this is the same uncertainty as in X + 1. You don't know X, so the
> result selected by "+" is uncertain (to you.) Are programs using "+"
> certifiable?

Yes, programs using "+" are certifiable. To obtain the certification,
you prove that X+1 is within range and that the operation does not
raise an exception. Ada's type safety features go a long way to help us
there, so we only have to test for a few boundary cases. SPARK takes
that to its logical conclusion, i.e. static proof.

>> A static procedure call has no uncertainty: when you read the program
>> source, you know exactly which subprogram is called, even in the
>> presence of overloading.
>
> Well, no:
>
> if Read (File) then
>    Foo;
> else
>    Bar;
> end if;
>
> The uncertainty of a dispatching call is one of the context, exactly as in
> the example above.

Nothing in your example is uncertain. Whatever path execution takes,
you know exactly what's happening.

> Provided, that there is nothing uncertain in how
> dispatching works or what potential targets do.

But with compiler-provided dynamic dispatching, there *is* uncertainty
as to how dispatching works and what the targets are.

-- 
Ludovic Brenta.

Re: procedural vs object oriented

[Alex R. Mosteo]

Ludovic Brenta wrote:
> Dmitry A. Kazakov wrote:
> 
>>On 27 Apr 2006 03:42:10 -0700, Ludovic Brenta wrote:
>>
>>>Dynamic dispatching, by definition, means that you don't know which
>>>subprogram you call at run-time. The compiler guarantees that the call
>>>will succeed (i.e. that there exists a subprogram to dispatch to),
>>>but there is uncertainty about which one it is.
>>
>>(I have an impression that it will not be true in Ada 200Y.)
> 
> 
> No, nothing changes in this respect, just synctactic sugar.
> 
> 
>>OK, but this is the same uncertainty as in X + 1. You don't know X, so the
>>result selected by "+" is uncertain (to you.) Are programs using "+"
>>certifiable?
> 
> 
> Yes, programs using "+" are certifiable. To obtain the certification,
> you prove that X+1 is within range and that the operation does not
> raise an exception. Ada's type safety features go a long way to help us
> there, so we only have to test for a few boundary cases. SPARK takes
> that to its logical conclusion, i.e. static proof.
> 
> 
>>>A static procedure call has no uncertainty: when you read the program
>>>source, you know exactly which subprogram is called, even in the
>>>presence of overloading.
>>
>>Well, no:
>>
>>if Read (File) then
>>   Foo;
>>else
>>   Bar;
>>end if;
>>
>>The uncertainty of a dispatching call is one of the context, exactly as in
>>the example above.
> 
> 
> Nothing in your example is uncertain. Whatever path execution takes,
> you know exactly what's happening.
> 
> 
>>Provided, that there is nothing uncertain in how
>>dispatching works or what potential targets do.
> 
> 
> But with compiler-provided dynamic dispatching, there *is* uncertainty
> as to how dispatching works and what the targets are.

This is something I'm not getting in this discussion. Provided that you 
know all derived classes, you know all possible dispatchings and you can 
validate all for correctness and time the worst one. How's this 
different than evaluating all branches in a case?

It's true that you don't have the information at the calling point, but 
you have it elsewhere.

> 

Re: procedural vs object oriented

[Ludovic Brenta]

Alex R. Mosteo writes:
> Ludovic Brenta wrote:
>> But with compiler-provided dynamic dispatching, there *is* uncertainty
>> as to how dispatching works and what the targets are.
>
> This is something I'm not getting in this discussion. Provided that you
> know all derived classes, you know all possible dispatchings and you can
> validate all for correctness and time the worst one. How's this
> different than evaluating all branches in a case?
>
> It's true that you don't have the information at the calling point, but
> you have it elsewhere.

The issue is not whether or not you *can* validate dispatching calls;
of course you can. The issue is *how much it costs* to do so. (This
same argument is also why we use Ada instead of C or handwritten
assembly).

As you said, the list of all possible call targets is not present at
the call site, but spread across the entire program source.  You'd have
to gather the list of all possible targets for each dispatching call,
and review the dispatching machine code *at every call site*. Try to do
that on the software you're currently writing. The first step would be
for you to come up with a list of all dispatching (not static) calls in
your program. If you do just that, you will then start to realise how
much effort would be required for full-fledged certification.

Furthermore, during maintenance, more possible call targets can appear,
affecting previously tested and certified call sites, and requiring you
to redo the certification process each time you add a type to a
derivation class.

In general-purpose programming, you can use all the features of the
language that help you write your source code faster; in avionics, you
only use those that help you certify your machine code faster. It
matters more to reduce the cost of certification than the cost of
writing the software, because the former far outweighs the latter.

-- 
Ludovic Brenta.

Re: procedural vs object oriented

[Alex R. Mosteo]

Ludovic Brenta wrote:
> Alex R. Mosteo writes:
> 
>>Ludovic Brenta wrote:
(interesting snip)
> In general-purpose programming, you can use all the features of the
> language that help you write your source code faster; in avionics, you
> only use those that help you certify your machine code faster. It
> matters more to reduce the cost of certification than the cost of
> writing the software, because the former far outweighs the latter.

Thanks, the issue is very clear now.

Re: procedural vs object oriented

[Ludovic Brenta]

"Alex R. Mosteo" <devnull@mailinator.com> writes:

> Ludovic Brenta wrote:
>> Alex R. Mosteo writes:
>>
>>>Ludovic Brenta wrote:
> (interesting snip)
>> In general-purpose programming, you can use all the features of the
>> language that help you write your source code faster; in avionics, you
>> only use those that help you certify your machine code faster. It
>> matters more to reduce the cost of certification than the cost of
>> writing the software, because the former far outweighs the latter.
>
> Thanks, the issue is very clear now.

Ada has unique features designed precisely to help with certification.
I suggest you re-read annexes D and H in the light of this thread; you
will see why Ada shines where lesser languages fall flat on their
face.

Particularly relevant to the present discussion is:

pragma Restrictions (No_Dispatch);

-- 
Ludovic Brenta.

Re: procedural vs object oriented

[Jean-Pierre Rosen]

Dmitry A. Kazakov a �crit :
> Well, no:
> 
> if Read (File) then
>    Foo;
> else
>    Bar;
> end if;
> 
> The uncertainty of a dispatching call is one of the context, exactly as in
> the example above. Provided, that there is nothing uncertain in how
> dispatching works or what potential targets do.
> 
Of course, you can assume that every dispatching call is equivalent to a 
case statement over all possibly redefined primitives. That works well 
for one level.

But if you consider that each called primitive may in turn redispatch 
internally, you end up with a combinatorial explosion. In theory, yes, 
the analysis can be performed. In practice, no.
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: procedural vs object oriented

[Dmitry A. Kazakov]

On Thu, 27 Apr 2006 16:01:41 +0200, Jean-Pierre Rosen wrote:

> Dmitry A. Kazakov a �crit :

>> Well, no:
>> 
>> if Read (File) then
>>    Foo;
>> else
>>    Bar;
>> end if;
>> 
>> The uncertainty of a dispatching call is one of the context, exactly as in
>> the example above. Provided, that there is nothing uncertain in how
>> dispatching works or what potential targets do.
>> 
> Of course, you can assume that every dispatching call is equivalent to a 
> case statement over all possibly redefined primitives. That works well 
> for one level.
> 
> But if you consider that each called primitive may in turn redispatch 
> internally, you end up with a combinatorial explosion.

Ah, but redispatch is luckily not allowed in Ada. The programmer has to 
explicitly convert the type to the class. That should not slip through peer 
review.

[ I would even disallow it altogether. There is your trick for such 
things.]

> In theory, yes, the analysis can be performed. In practice, no.

Yes, but it is a sort of "postmortem" or C-ish approach. There is nothing 
fundamentally evil in dispatching if LSP problematic is supported. It is a 
question of the language and tools. Something like SPARK could change it. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: procedural vs object oriented

[Peter Amey]

Ludovic Brenta wrote:
[snip]
> 
> 
> According to Robert Dewar during FOSDEM, nobody uses OOP in avionics
> software, because the uncertainty inherent to dynamic dispatching
> hinders certification.  Is someone on this newsgroup in a position to
> give a counter-example?
> 

The committee that is revising the DO-178B avionics "standard" is 
currently meeting in Los Angeles.  There is an entire sub-group devoted 
to the problem of certifying O-O software.  At the breaks, they look 
like it is proving hard work!

Those of us in the formal methods sub-group are having a slightly easier 
time.

Peter

Re: procedural vs object oriented

[Ludovic Brenta]

Peter Amey <peter.amey@praxis-cs.co.uk> writes:
> Ludovic Brenta wrote:
> [snip]
>> According to Robert Dewar during FOSDEM, nobody uses OOP in avionics
>> software, because the uncertainty inherent to dynamic dispatching
>> hinders certification.  Is someone on this newsgroup in a position to
>> give a counter-example?
>
> The committee that is revising the DO-178B avionics "standard" is
> currently meeting in Los Angeles.  There is an entire sub-group
> devoted to the problem of certifying O-O software.  At the breaks,
> they look like it is proving hard work!

That was also my understanding after reading OOTiA.

> Those of us in the formal methods sub-group are having a slightly
> easier time.

You bet :)

-- 
Ludovic Brenta.

Re: procedural vs object oriented

[Ananth the Boss]

thanks for your suggestions.i wud like to add some more.what design
digagrams should i use in a case tool to generate code that centers
around procedure approach.so that from the design diagram i can
generate the code automatically.