NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/object/3186

Text File | 1992-08-12 | 9.8 KB | 209 lines

Newsgroups: comp.object
Path: sparky!uunet!projtech!steve
From: [e-mail] (Steve Mellor)
Subject: Re: Class methods (was: Re: How to design a data structure library)
Message-ID: <[e-mail]>
Organization: Project Technology, Inc., Berkeley, CA
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 12 Aug 1992 21:32:14 GMT
Lines: 198

> > ...
> > At design time, we should address *only* these issues by building a
> > transformation engine for an arbitrary analysis with the same performance
> > characteristics as the problem we are trying to solve (Man, Woman, etc)
>
> This is a dangerous statement.  It's true (for example) that circuit
> analysis and design techniques can be turned into `turn the crank'
> sequences of steps on the DC and AC circuit models.  Doing so throws
> away insight on the behavior of the circuit in the real world--because
> it throws away the knowledge of the real world!

Damn right it's a dangerous statement!  It's dangerous because it
messes  with  your mind by overturning **all** of the assumptions
of Rumbaugh/Booch/Coad regarding the meaning of design.  And,  in
fact,  asserts  a  completely  different  view  of  design  --  a
transformational view.

So what *do* we (S/M) do, if we don't do what they do?

1.  Partition the problem into domains
2.  Analyze the application ... in gory detail
3.  Extract requirements (new idea -- see below)
4.  Analyze other domains  (obvious)
5.  Architectural domain (see below)
6.  Build mechanisms and templates (see below)
7.  Populate templates  (see below)

Let's take an example.  Consider a Customer object and an Account
object.  In the Account object, there is a reference to the iden-
tifier of the Customer (in S/M OOA, a referential attribute).  It
must be placed in the Account object because of the rules we use.
(Let's not digress).  The objects are related so that a  Customer
*must*  have  at least one account in order to be a Customer. The
problem requires that a single statement (for  all  accounts)  be
produced for each customer.

Now, Step 3 (Extract requirements) says, by  examination  of  the
analysis models, "I see a 'pattern' whereby I  keep searching the
accounts to find all the accounts  that  a  customer  owns."  The
result  of this is a clear idea that we want to group all the ac-
counts with a given customer.  (Note that an analysis model  that
had  a 'pattern' that frequently interrogated the Account to find
the Customer that owned it would lead to a different conclusion.)
I  will  also note 'patterns' that come from OOA, such as sending
an event.  The 'send an event' pattern will appear in  every  ob-
ject  that has a state model, whereas the 'I search all the <x>'s
to find the ones related to the <y>' will appear less frequently.

Step 5 says to understand the architecture.  Here, we  decide  --
to  meet the requirements from step 3 -- that an o-o architecture
using classes is a good idea, that we  need  a  Collection  class
(for  all the accounts of a customer), that we shall use a single
task, that events will  be  transmitted  using  a  function  call
called  Take  Event  <ev#> that will be supplied for every class.
OR, we could choose an architecture using,  say,  an  associative
memory  for the accounts/customers, or using n tasks, or not even
using o-o at all!

**The architecture is specified completely independently  of  the
application** even though the choice of architecture is dependent
on the performance characteristics of your application.

Step 6 says to build mechanisms and templates.   A  mechanism  is
some  *application-independent*  component  required as a part of
the engine for the OOA.  A Collection class, used to  maintain  a
set  of  accounts,  and  a  Take  Event  function, all qualify as
mechanisms.  A template (not the C++ kind) is a shell that  shows
how  to  use  the mechanisms.  We would build a template for each
OOA concept that has a analogue in the OOA engine.  For  example,
a  class  that corresponds to an OOA object with a state machine,
or a class that corresponds to an OOA object that we want to  im-
plement  using a Collection.  A template will contain replacement
signifiers, such as <ev #>, for example.  The <>'s  will  be  re-
placed from the application analysis.

An example architecture, with a template, is shown in  Chapter  9
of Object Lifecycles.

In step 7, we populate the templates by filling out the  <>  with
the  stuff  from  the application.  So we'll replace each <ev #>,
for example, with an event taken from the  analysis.   And  we'll
use  the  'search  all  <x>'s'  template for all the objects that
qualify.

----------------

Stepping back for a minute, what we did was to figure out how  to
elaborate  each  of  the objects in the analysis in order to make
the system work.  But instead of adding this  to  *each*  of  the
analysis  objects,  we wrote down the architecture independently,
then we transformed the application into the design.  The concept
is  similar to (a) We wrote a program in a language, (b) we wrote
the compiler for the language (c) we applied the compiler to  the
program.   The  language,  of course, is OOA.  (S/M OOA, that is.
The others are not well enough defined to be able to  do  this!).
Step  (a) corresponds to the application analysis. (b) to the ar-
chitecture and the templates, and  (c)  to  populating  the  tem-
plates.

The obvious and beautiful economy is that once you have the  com-
piler  (architecture  and  templates), it is a low cost matter to
recompile other programs, or to change the existing program  (the
analysis).

The architecture I described will lead to a fairly  direct  tran-
formation  of  the  application.  However, the architecture could
lead to a *very* indirect transformation -- say, a  periodic  ar-
chitecture for an embedded system.

Let's take another look at your comment...

> analysis and design techniques can be turned into `turn the crank'
> sequences of steps on the DC and AC circuit models.  Doing so throws
> away insight on the behavior of the circuit in the real world--because
> it throws away the knowledge of the real world!
>
Yes, we did turn the crank.  But we did not throw away the infor-
mation about the real world.  We kept it -- pure and unsullied --
in our analysis models.

> If the `transformation techniques' apply only to the *artifacts* of the
> analysis, and ignore the context of the system/problem analyzed, they
> make it hard to follow the final causes in the design (they make it
> hard to trace from a given piece of code back to the requirement or
> world-feature it represents).  (This, by the way, is one of the dangers
> I see in the large-scale `domain model' in the Schlaer-Mellor method.)

The 'final causes in the design' are documented in the  architec-
ture  --  again  pure and unsullied.  Note that architectures are
generally highly reusable.

Why, in heaven's name, would you want 'to trace a given piece  of
code back to the requirement or world-feature it represents'? ;-)
This would be like trying to trace  an  assembly  code  statement
back  to  the  C++  whence  it  came (a useful activity only when
you're checking the architecture -- whoops! I mean the compiler.)

Sorry, I got carried away...  Of course, what you're really  try-
ing  to  do  is  to  change a *requirement*.  So let's do that by
changing the analysis models, and then reapplying  the  architec-
ture to the application analysis to build a new system.

(No, this is not fantasy, we have many systems that are partially
or fully automated from the analysis models.)

Yes, tracing of the requirements is a danger in OOA/RD  *if*  you
think  about the process in a non-transformational way.  That is,
you say "Let me add in all this architectural stuff to  each  ob-
ject  in the analysis, so that when I look at the code I can find
the application requirement."  A  reasonable  thing  to  do,  but
messy.   Note that this is precisely what Rumbaugh/Booch/Coad do,
except that thay don't have a way to do it in a  uniform  manner.
In  other  words, the *worst* case in OOA/RD is the *recommended*
case for Rumbaugh, Booch, Coad et al, for they elaborate each ob-
ject  in  the  analysis  to  produce  the  design.  In OOA/RD, we
separate the architecture explicitly, and so can find a  require-
ment in the analysis models.

----------------

Implications

The implications of OOA/RD are quite exciting.

1.  S/M OOA/RD reduces and controls iteration by confining it  to
a  single domain at a time.  Modifications to the design are made
entirely in the architectural domain and propagated to the entire
system through templates.

2.   S/M  OOA/RD  systematizes  and  supports  reuse  of  *entire
domains* because the domains are kept separate until the very end
of system construction. This is especially true for the architec-
ture,  which  can  be reused for any system with the same perfor-
mance and loading charcteristics.

3.  The approach reduces maintenance costs.  Much maintenance in-
volves  some modification of the analysis, (a problem of size m),
and some modification of the architecture (of  size  n).   Today,
this  is an m*n size problem, because the application is embedded
in the architecture.  Using OOA/RD, it becomes a m+n  size  prob-
lem, because the application and the architecture are separated.

4.  The size of the design work  is  *not*  proportional  to  the
analysis.

------------

I have a paper available describing these seven  steps.   If  you
want a copy, please mail me  ([e-mail]) with your name,
postal address(not e-mail) and phone number.

Steve

-------------------------------------
Steve Mellor            [e-mail]
Project Technology      Training and Consulting using Shlaer-Mellor OOA/RD
Berkeley, CA            Tel: [phone]
--------------------------------------