Summary of Class Presentation for August 31, 1999

	Perhaps the most difficult part of learning about object-oriented
systems is understanding what is meant by the statement that 
object-oriented systems model behavior.  Object-oriented systems differ
from imperative systems in far more than syntax or a slightly different
way of grouping stuff into classes instead of functions.  The entire
approach is different.  These differences provide the following 
advantages:
	1.  Greater flexibility to make changes as the system continues
	to evolve, perhaps for years after initial release;
	2.  Greater opportunities for reuse of design and code;
	3.  Greater understanding by potential users of how the system
	will work and how users should work with it;
	4.  Capability to scale up to larger and more complex systems than
	with previous methods.

	A handout with seven sample problems was distributed.  We used the
first of those samples as an example for doing object-oriented design.  We
chose a simple approach that works well for small problems, but does not
scale up very well to problems with requirements specifications of more 
than a page or two.  Next class period, we will examine a more 
sophisticated approach that scales better, but is more difficult to learn
to use effectively.
	Our approach starts with the Russell Abbot noun's method for 
developing a set of candidate classes.  We take the specification and 
identify all the nouns.  These will be our candidate classes and the 
next step would be to reduce this set to the essential classes.  TO do 
this several heuristics are employed:
	1.  Any noun that refers to the product being developed as a 
	whole is dropped;
	2.  Any noun that refers to something outside of the product is 
	dropped.  THis might include other systems with which the 
	product will interact, the user, or items with which the system
	is being compared;
	3.  If two or more nouns are synonyms for each other, only one 
	is retained;
	4. If one noun means a subset or special case of what another 
	noun means and there is not substantial separate processing of 
	the separate case, the more limited noun is dropped;
	5.  If two or more nouns are just forms of the same base noun 
	( singular and plural, gerunds), only one is kept;
	6.  If a noun means an attribute of another noun, only the base
	item is kept.
To the resulting set of essential classes, we add a class to handle user
interactions when the user interacts extensively with the system.  We also
add classes for each major activity required of the product when one of 
the already present classes cannot obviously handle coordination of this 
activity.
	The resulting set of nouns is our proposed set of classes.  Now we
need to determine how these classes will interact to achieve the 
requirements.  We walk through how the classes will handle each requirement.
In this walkthrough, we assign operations to various classes as they are
needed.  To decide which class should handle an operation, we use the 
following principles:
	1.  A data structure should be known to one and only o
	unless absolutely necessary;
	2.  Each interface with an external entity ( including the user) 
	should be contained within one and only one class whenever 
	feasible.

	We did the first example problem in the handout using these 
techniques.