Re: OOA and OOD

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 12/20/04 

Date: Mon, 20 Dec 2004 17:24:12 GMT

Responding to Gauld...

>>>>What you are describing is requirements analysis, not OOA modeling.
>
>
> Yes but requirements analysis is only one type of analysis and
> uses many tools including, for example, IM. When I say I'm using
> IM to analyze requirements people know what I'm doing. When I say
> I'm using OOA to analyze my requirements most folks I speak to
> know what I'm doing - but what term would you use to indicate the
> same concept?

Requirements analysis. B-)) I would be happier with Object-Oriented
Requirements (OOR), but there is already a camp that employs UML to do
exactly that. That's fine in theory, but every example I have seen has
been an overspecification (i.e., it is really a solution specification).
  That's because UML itself and OOA is designed around describing a
software solution.

If you want to call what you do OOR (OORA?) and you don't get carried
away with dynamic specifications (i.e., stick to the static IM
representations), that's fine with me. B-) But then you will be
overloaded with the existing OOR camp.

>
>
>>... you are not applying a formal OOA/D methodology to produce a
>>software solution. You are just using similar techniques to do
>>requirements analysis, which is a quite different thing.
>
>
> I'm quite prepared to accept that it is a different thing, but
> nonetheless it is analysis and it is using OO techniques, and it
> is highly effective, so what do we call it?
>
>
>>Try this thought. In the translation methodologies, the /only/ work
>>product that the application developer creates is the OOA model. These
>>translations would be done routinely in that model. How can that be
>>reconciled with the notion that OOA is not a software design activity?
>
>
> Software design is, for me, only a small subset of the domain of
> problems which OO can analyze. Thats how *I* reconcile it. I'm
> not saying that, given a set of requirements (especially if they
> are pure text) a software developer would not do OOA on them to
> better understand the problem prior to commencing (Or more likely
> in parallel with) the OOD.

My point here is that an OOA model (MDA PIM) is already a well-defined
(more precisely, highly constrained and abstract) solution description
and producing that description is an OO design activity because there
are also several well-defined design methodologies for producing OOA
models. For better or for worse, that activity has been designated OOA.
  So one needs a different name when using analysis on requirements,
even if it is object-oriented.

>
>
>>Or that in two decades creating OOD models and 3GL code will be as rare
>>as writing Assembly today? B-))
>
>
> Smiley acknowledged, but they've been telling me that for 3
> decades and we are probnably about 5 years down the road
> according to that timescale(ie 25%), so by my reckoning
> it will take about 90 years away in Earth years...! :-)

The technology existed in the '80s. But the engineering problems were
formidable. Though the computing space is highly deterministic, it is
also highly complex. The optimization problems faced by a
transformation engine are much more complex than those faced by a 3GL
optimizing compiler. It took two decades to get credible optimization
in the generated. (And it took nearly a decade to produce C compilers
that could compete with established FORTRAN compilers.) But by the late
'90s those problems had been largely solved.

The only real bar today is the learning curve. Translation represents a
major sea change in the way software is developed. It is not just
pressing a button and having code pop out; the entire development
process from configuration management to testing changes. More
important, the way one develops designs is very different. There are
lots of programs written in OOPLs today but very few reflect good OOA/D.
  One can't get away with that if all one does is OOA. One has to think
about the problem solution much more rigorously because the code
generator does what you say, not what you meant. So the classical
tinker-test-tinker loop tends to be very inefficient in the translation
world where the emphasis is on getting it (the problem space) right the
first time.

[FWIW, I doubt that I have written 10 KLOC of 3GL code since the
mid-'80s. Among other things, once you have used a good model level
debugger, you regard a 3GL debugger the same way a VC++ developer
regards an Assembly debugger. B-) Life is just too short for that.]

>>books were the early bibles. (The updated '02 version, BTW, is
>>"Executable UML" by Mellor and Balcer.)
>
>
> I'll look out for it, I still use my original OOSA and MWS.
>
> BTW Have you looked at SDL? The similarity in approach between
> S-M and SDL is amazing, although perhaps not unexpected given
> Mellor's background in real-time, which is where SDL is firmly
> targetted too. And of course SDL tools all feature executable
> models and full code generation - the translationists ideal.

I haven't looked too closely but my impression is that it is not
abstract enough for OOA; essentially it is a 3GL. (I don't regard tools
like Rhapsody that use an augmented 3GL as an abstract action language
(AAL) as being proper translation tools; SDL just has more augmentation.)

<hot button>
My main problem, though, is that Telelogics is trying to get in
incorporated under MDA as THE AAL. On general principles I don't like
that. IMO OMG should stick to meta-model semantics and leave the
specific model instances for the market place to sort out. OMG has
provided a standard for action language semantics that such languages
should be compliant with. But it shouldn't be in the business of
defining AALs.

If the AALs are compliant, then building cross-compilers is relatively
trivial. (Translation vendors will gladly provide packages to customers
to convert models from rival tools, so migration between languages
doesn't even cost the customer anything.) In the long term that is a
lot better than painting oneself into the SQL trap by anointing a single
language as the only standard evermore.

OCL in UML is a good example. Like SQL, it is a dinosaur but it lives
on simply because it has been blessed as the only "official" constraint
language. As a result, most developers aren't even aware that other
constraint languages exist. Worse, language designers are reluctant to
even attempt to design a better constraint language because of the
enormous huddle to acceptance that OCL standardization represents.
</hot button>

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH