RE: [OEP] minutes of 5/26 telecon - Naming the 3rd Use Case

Michael Uschold wrote in the part tagged [MFU]:
>Yes, the sentence you quoted describes the difference. The two use  
>cases are close, but in one case, you really have a binary relation  
>with additional information about it. In the second, you cannot  
>actually say which one of the two values is "more important" -- you  
>can think of this as a "multi-valued" value.
>
>[MFU] Hmmm. This is an extremely subtle point which I'm not sure I get,
>and if I do, I'm not sure how important it is to make the distinction. I
>guess my view is that these are too close to pull out as separate use
>cases. Maybe better to call them two different examples of the same use
>case?  
>Then you could add the between example as another example of the last
>use case? Not necessarily the full example with code an all, but the
>gist of it. .
>What do others think?  
>====

This is NOT a subtle point for an object modeler, and I don't understand why 
it is so hard for some to see that.  There is a good example from the Driving
Task Decomposition problem that I worked on with Craig Schlenoff, David Aha, and 
others from the robotics side of our lab.  The control system for this includes
a World Model (WM) that holds information about any sensed objects that may be of
interest.  For this discussion, lets just consider "active" objects, such as
people and vehicles.  These objects will be in the World Model and they will
have attributes for size, type, position, behavior, velocity or even projected 
path.  But the relationship between the controlled vehicle and these objects is
also modeled.  Often characteristics that exist between these objects are the
important criteria for making driving decisions.  When I created a UML diagram 
for the WM, I used an AssociationClass for this relationship so that characteristics
such as velocity, distance, and minimum_safe_distance between the objects could be 
rendered as attributes of this relation.  Note that these characteristics are only 
relevant in the reference frame of the relation and are not otherwise available in 
the model (although they are derivable from it),  thus it is quite natural to think 
of them as "belonging to the relation".

A modeler with a relational DB background may tend to think (because of a 
relation-oriented rather than object-oriented perspective) of this same relation 
as an N-ary relation with a joint uniqueness constraint on the roles for 
controlled_object and active_object showing the primacy of those objects in
the relation.  Note that OWL has NO way to define joint uniqueness (compound keys) 
and 95+% of UML users wouldn't even think of doing this, let alone know the notation
in UML for saying it.   Whereas data modeling languages such as ORM do support
ideas similar to AssociationClass in addition to joint uniqueness constaints.

-Evan

Received on Friday, 27 May 2005 15:15:48 UTC