Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[nickt@bain.oz.au (Nick Thurn)]

Alan Lovejoy (alovejoy@concentric.net) wrote:
> Nick Thurn wrote:
> > 
> > The objects that exist when the program runs are a mixture of implementation
> > objects, domain objects, library objects, ui objects, comms... etc. Trying to
> > think back from them seems very unhelpful. IMHO even thinking *forward* to
> > these implementation objects too early is dangerous.
> > 
> > Do you mean this or do I have it wrong?
> 
> Pardon me, I see I wasn't clear.  The "dynamic model" or "dynamic design" **deals with**
> or **is concerned with** the objects that will exist at run time, what roles they will
> play, what responsibilities they will have and how they will interact.  Of course the
> run time objects are NOT themselves the design (in spite of the fact that my imprecise 
> wording might give one the impression that I was saying that).
> 
Alan,

I see what you mean, however I still don't agree. In my experience the dynamic model
is several things:
	- sanity check on static model
	- discoverer of missing abstractions
	- discoverer of patterns of interaction to be further encapsulated

The static and dynamic model interact in a feedback loop so precedence is not clear
ie static first vs dynamic first. IMHO you must start with a static model of your
domain prior to embarking on the dynamic model. Sure this model may be incomplete
or prove inappropriate but it is the seed from which an implementable system should
be grown (IMO). read on.. 

> Many objects that exist at run time may have internal mechanisms that you have no
> control over, such as those that may be instantiated from classes in the standard
> library.  You can of course always choose not to use such "standard" or "system"
> objects, and in some languages (such as Smalltalk) you may be able to easily change
> them, but simply using them as-is is what usually happens.  You don't need to design
> such "standard" objects, 
>
Again I disagree. Standard objects *are* part of your design just because you *use*
vs. *implement* doesn't reduce their importance. In fact the greatest benefits come
when programmers -stop- -writing- -code- and -start- -using- -code-. 

> but you do need to know how to interface to them, and 
> decide what roles (if any) they will play in your system.
>
I agree with this. The timing is still *after* you have a static analysis or domain
model and a set of requirements stating what your users want this system to do. How
can you even think about object roles until you know which objects you have? and
what your program should do?

> Perhaps a concrete example will clear up the confusion.  The Model-View-Controller
> concept is now familiar to many, so I will use that as the example.
> 
[...snipped MVC discription...]
> 
> The collaborating objects in a role model are understood as instances, not classes.  And a 
> role is a function of 
> 	a) the responsibility of an object and what purpose it serves
> 	b) messages that it will be expected to respond to 
>		(which might well be a subset of all the messages it could respond to)
> 	c) the messages it will send to other collaborators
> 		(which might not be all the messages it could send, 
>		nor all the receivers to which it may potentially send messages).
>
[...snipped MVC discription...]
> 
> From this it should be clear that roles are not classes. 
>
No they are perhaps patterns and certainly design artifacts. They may be implemented
as classes if appropriate, and could be abstract base classes or cooperating generics.
Or whatever your language supports.

> I wholeheartedly endorse role modelling, and recommend doing it **before** trying to worry
> overmuch about the class hiearchy.  Wouldn't it be nice to identify the role models in which
> the objects in your program will participate before designing the class hierarchy that will
> provide the classes whose instances can be collaborators in those role models?
>
You are forgetting that at this point you know stuff that makes the role relevant eg
that your app is GUI based vs embedded vs commandline vs ... How did you get to
know this stuff? You are talking about plumbing which IMO should be put into librarys
if possible and reused. Yes plumbing is a design issue, yes object interaction roles are
relevant but plumbing comes AFTER your static model, AFTER you know what you are
doing and why you are doing it. 

Object roles are *discovered* during dynamic modeling, (this can mean "force fit" :)
they are not ends in themselves.

cheers
Nick (my opinions only) 

> --
> Alan L. Lovejoy		|==============================================| 
> Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
> alovejoy@concentric.net |==============================================|