Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!uwm.edu!rpi!uupsi!grebyn!schultz
From: schultz@grebyn.com (Ronald Schultz)
Newsgroups: comp.object
Subject: How do you evaluate objects?
Keywords: OO Design Evaluation
Message-ID: <23645@grebyn.com>
Date: 29 Nov 90 13:30:08 GMT
Organization: Grebyn Timesharing, Vienna, VA
Lines: 132


WHAT IS A "GOOD" OBJECT ?

The following are some brief notes on how we evaluate objects in
our environment.  Any additional comments or suggestions would be
appreciated.

Designing objects is not easy.  Design is a complex task.  But
determining whether or not a design is good or appropriate is
crucial to being successful.  Our review review process for
objects consists of the following checks:

     o    Model Correspondence
     o    Mapping
     o    Constraints
     o    Visibility
     o    Feedback

(Please note that while our development is conducted in
Smalltalk/V 286 and any specific examples are provided in this
enviroment these notes should be appropriate to an OO development
effort.)

Model Correspondence:
          
It should go without saying that the naming of an object is
extremely important, particularly if issues of reuse are
involved.  Associated with any name is a user's conceptual model
of what the object is.  When the object, as designed by the
designer, corresponds closely to the user's mental model of the
object, we have defined a "good" object.  When the user's mental
model of the object conflicts with the object as designed is, we
will have problems.  Designers of objects, and the users of the
objects, are often not the same people.  Object designers must
pay particular attention to their customers (object users) and
listen and respond to the needs of their customer.  Object users
must be willing to specify and present to the designers
situations where differences exist between their mental model and
the actual object.  Communication between designer and user is
the key to ensuring that model correspondence is accurate and
complete.  

Mapping:

This evaluation involves determining if the mapping between
operations, and what they operate on, is clear and unambiguous. 
The assignment of operations (methods if you wish) to objects is
a critical analysis and design consideration.  

In particular we look for the following.  If the number of
possible behaviors/states exceeds the number of operations, there
is apt to be difficulty in the use of the object.  In general,
operations that perform more than one action are apt to be
difficult to remember.  When the number of operations equals the
number of actions, each operation can be specialized and labeled
specific to its task.  In this case the operations are visible
through the name of the operation.

In addition we look for instances of object blindness during the
mapping evaluation.  AN EXAMPLE OF OBJECT BLINDNESS.  A power
drill and a block of wood are the objects of interest.  One
wishes to drill a hole in the wood block.  Where does one assign
the operation "drill hole"; to the wood block or to the drill? 
What is missing here is a "person" object.  A "person" drills the
hole, not the drill or the block of wood.  The mapping of "drill
hole" to wood block or power drill does not make "real world"
sense, and hence serves as a clue to a mapping problem.

Visibility:    

Necessary operations should be visible. This ensures that the
interface is understandable and usable.  Visibility of operations
not essential to the use of the object must be restricted from
view.  Public operations should be visible to the object user,
private ones should not.

Visibility acts as a good reminder of what can be done with the
object.  A good relationship between the name of an operation and
what it does makes it easy to find the appropriate operation for
a task.  As a result, there is little to remember.

For an example of a "bad" operation one can look in the Smalltalk
ClassHierarchyBrowser Class for an operation named "hierarchy". 
As an operation name this particular operation suffers because
(a) the name of the operation is not a verb and (b) it is
difficult to discern the action that this operation performs.

Constraints:

The appropriate use of constraints in object design can help in
ensuring the proper use of objects.  First there are physical
constraints.  The development environment itself can be used to
physically restrict what a user of an object can see about the
object itself.  Restricting source code viewing to the object
interface and public methods is one way.  Typing provides another
mechanism.

Next there are semantic constraints.  The names of objects and
operations provide a great deal of semantic information to the
user of the object.  Appropriately naming objects and operations
provides in many cases sufficient information to the user to
ensure that his use of objects is appropriate.  If your
development environment supports associating graphics with your
objects, the appropriate selection of icons, and even colors, can
be used to provide cues to the user as to how to use the object. 
In these cases semantic information provides a constraint to the
user that assists the user is rationally using the object.

Another constraint is the logical constraint.  In this case logic
dictates how the use of an object should occur.  Adding an
integer object to an icon object does not make sense logically. 
Providing cues to the user as to what the logical constraints are
in the object's use helps ensure the appropriate use of the
object.


Feedback:

Objects should "feedback" to the user appropriate information
about their state, and their response to a particular operation. 
Error handling and exceptional processing should be well
understood and detailed.  If an exception condition occurs, the
object should provide details back to the user in manner that
allows the user to respond quickly, with a minimum of research. 
Unformatted dumps of an object's state is not an appropriate
feedback mechanism.  

Any comments or suggestions as to additional evaluation criteria?

Ron Schultz
schultz@grebyn.com
614-759-3127


Brought to you by Super Global Mega Corp .com