From: sally@projtech.com (Sally Shlaer)
Subject: Re: Class methods
Organization: Project Technology, Inc., Berkeley, CA
Date: Wed, 12 Aug 1992 20:01:25 GMT

In a fascinating article (1992Aug11.180111.4658 etc.), mat@mole-end writes:

> We have here a 'relationship" that is also a transaction or process of
> some sort.  May I suggest the term 'temporality"?
> We're still not paying enough attention to relationships.


I don't think we need a new term.  You are pointing to one dimension of a more 
general problem:  dynamic relationships.  See chapter 4 of Object Lifecycles:  
"This chapter explains how to formalize the dynamic behavior of relationships 
and how to deal with contention in the analysis."

But you make a good point:  Relationships are excrutiatingly important in 
explaining how the world works.  And, as far as I know, Shlaer-Mellor is the 
only analysis method (OO or otherwise) that considers this subject.  This is 
very very serious for applications where there is contention or competition 
(two airplanes want to put down on the same runway, multiple targets are 
competing for the attention of missles, multiple parts are trying to get to a 
lathe, etc.).  Shlaer-Mellor OOA treats these problems easily; Rumbaugh and 
Coad do not even mention the problem.

> Some authors have used a timing diagram/event trace to represent objects
> and relationships in time, with lines diverging and converging as objects
> and relationships come and go.

What authors are you referring to here?  I think you may be wrong about this -
- here is some data:

	Rumbaugh uses an "event trace" to show the event communication between 
objects.  This diagram shows the event communication that devolves from the 
arrival of a *single* external event.  The diagram does not say anything about 
objects and relationships coming into existance or ceasing to exist.  
	Firesmith uses a similar diagram (which he calls a timing diagram) for 
exactly the same purpose.
	Shlaer-Mellor uses an Object Communication Model to show the event 
communication that results from arrival of *all* external events.  This 
diagram also doesn't say anything about the dynamics of existance.
	Shlaer-Mellor also use a thread-of-control chart (page 97, Object 
Lifecycles) to show event communication between objects that results from the 
arrival of *several* external events.  This diagram *does* show objects coming 
into existance and ceasing to exist.

Why am I making such a deal of such a trivial point?  It seems clear to me 
that there is a lot of misunderstanding about analysis methods out there in 
the world at large.  The methods of interest to this forum are NOT all the 
same -- they have very different and distinguishing properties.  Comp.object 
readers care about those distinctions -- they often have to select a method 
that is appropriate to their particular problem.  So I believe it is important 
to be *strictly accurate* when you describe properties or work products of a 
particular method, and to identify exactly what method you are talking about -
- lest one contribute, however inadvertently, to the general confusion.

> Notice here that I am looking for an _analytic_ model, which describes
> the world modelled, not a _design_ model, which describes how to program
> it.  I think this excludes the S[c]hlaer-Mellor methods, but I invite
> Stephen or Sally to prove me wrong.

Argh, I cannot believe that we have not been clear about this -- so let us 
state our views one more time.  

	THE PURPOSE OF ANALYSIS IS TO CAPTURE ALL OF THE INFORMATION ABOUT A 
PROBLEM DOMAIN:  What are the conceptual entities in the problem (trains, 
tracks, freight cars, etc.), the interrelationships between those entities, 
how the entities have to behave over time.  That is what Shlaer-Mellor OOA is 
all about.  

	THE PURPOSE OF DESIGN IS TO RE-FORM THE ANALYSIS INFORMATION AND RE-CAST 
IT INTO CONCEPTUAL ENTITIES OF COMPUTER SCIENCE (tasks, packages, classes, 
IPCs -- whatever design units you find fit your problem best).

	AT ANALYSIS TIME, WE DO NOT ASSUME THAT AN OBJECT-ORIENTED DESIGN WILL 
BE THE BEST ANSWER.  If it turns out that an OOD fits the problem well, that 
is just great.  But there are a number of problems or parts of problems for 
which an OOD is not a good answer.  The best way to figure this out is to do 
the analysis -- then you have enough information to make a decision on this 
matter.

> Insight one:  Within the Object Model, both analysis and design 
> elaborate upon a single model,

	("single" only if you can be assured that you are going to an OOD)

> _but they do so in different ways_.  Analysis adds information from the
> problem domain, 

	Yes, and *only* that domain

> Design decomposes the model into units which can be implemented.

	Yes, and these units are in a different domain -- a computer-science-ish 
domain.

> Insight three:  That if we want to design without excessive iteration . . .
> we must learn to ask the right questions during analysis.  
> IMO, recognizing these "temporalities" is part of those right questions.

	Yes, and that is why Shlaer-Mellor gives explicit direction as to how to 
recognize them and how to put this information into your analysis models.

> (Whether they are represented by a function call, a thread, a monitor, 
> or anything else is a design issue.)

	YES, YES, YES.

> Insight four:  Our methods must support us in asking those questions, and
> must preserve the information in a useful form until we need it.

Yes.  And to preserve the information in a *useful form*, we must keep the 
information about the problem domain segregated from the information about the 
solution (a.k.a. design).  Once you mix these two domains of information, 
later designers and implementers cannot tell what they are free to change 
(design information) and what must be left intact (problem information).  

For a simple example, suppose you have analysis models describing an 
electrical power grid.  (If you are using Shlaer-Mellor but not Coad or 
Rumbaugh,) You will have linkage information that tells you which cable is 
connected to which transformer, etc.  This is part of the problem domain.  At 
design time, you may *also* want to have linkages to facilitate the operation 
of the system -- say linkages that allow you to construct iterators.  Now this 
is design information -- and if later it turns out that you don't need the 
design linkage information, the designer/maintainer is free to make such a 
change.  But he must *never* remove the linkages that tell how the grid is 
connected in the real world.


Hope this helps.  

P.S.  Stay tuned for a continuation article from Steve Mellor.
-- 
Sally Shlaer		sally@projtech.com
Project Technology	Training and Consulting using Shlaer-Mellor OOA/RD
Berkeley, CA		(510) 845 1484