comp.lang.ada
 help / color / mirror / Atom feed
From: hfrumblefoot@yahoo.com (Hambut)
Subject: Re: Which OO is in ??
Date: 3 Aug 2001 02:27:59 -0700
Date: 2001-08-03T09:27:59+00:00	[thread overview]
Message-ID: <fb75c450.0108030127.6c60f9a2@posting.google.com> (raw)
In-Reply-To: 9kc0h3$ftu$1@newsg4.svr.pol.co.uk

"Paul Foster" <paul@fos-ltd.freeserve.co.uk> wrote in message news:<9kc0h3$ftu$1@newsg4.svr.pol.co.uk>...
> In the early nineties choosing an OO design method was
> quite straight forward, if you were using SPARK Ada
> as your primary language then you would used HOOD,
> otherwise for full blown Ada you would used teamwork
> Yourdon. Here in 2001 things are slightly different with
> Ada95 and UML now firmly established on the scene.
> Can anybody give me some guidance as to what OO
> methods are being used now and why, and if the project
> is restricted to only a subset of the Ada language ??
> 

I think it's probably even more straight forward for new projects now.
 The choice seems to be UML, UML or possibly HOOD (although HOOD
doesn't seem to have the visible level of support that UML has.  My
impression is that HOOD is mainly used for large legacy projects and
(possibly) within ESA).

Note I'm not necessarily saying that this is a good or bad thing.

Shlaer-Mellor is a possibility, but I believe that S-M vendors are
starting to re-align to UML.

As for dealing with the sub-set issue I don't believe that there is as
yet a UML profile which explicitly supports things like SPARK or
C-SMART, although it's probably been worked on by some tool vendors.

My thought is that you'd need to look carefully at what the chosen
language sub-set was trying to achieve, and then potentially 'sub-set'
the design methodology to support those same aims (at the very least
I'd expect a Code of Design Practice to be defined which defines
guidelines to support the aims).

As a simple (UML) example;

o  The chosen sub-set might 'ban' aliasing of variables (because it
greatly complicates static verification).

o  The use of the UML 'aggregation' construct might be banned during
design in favour of the 'composition' construct because 'aggregation'
may imply aliasing.

The point of doing this is to ensure that your design doesn't 'clash'
with the sub-set.  'Clashing' with the sub-set is potentially bad
because developers will spend most of their time 'fighting' with the
sub-set.  Which may mean that the sub-set is subverted, and that the
benefits you should gain from the sub-set are not gained.

cheers,

Hambut



  parent reply	other threads:[~2001-08-03  9:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-02 16:51 Which OO is in ?? Paul Foster
2001-08-02 17:10 ` Ted Dennison
2001-08-02 18:02   ` Paul Foster
2001-08-03  9:27 ` Hambut [this message]
2001-08-03 12:33   ` Martin Dowie
2001-08-03 13:31     ` Ted Dennison
2001-08-03 20:28     ` Hambut
2001-08-06 13:25       ` Martin Dowie
2001-08-03 18:00   ` Jean-Pierre Rosen
2001-08-04 10:30   ` Shayne Flint
replies disabled

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