Summary of Class Presentation of August 26, 1999

	We reviewed some of the basic concepts of object-orientation 
that were presented last class period.  In particular, we looked at the
relationships among classes, objects, and meta-classes more carefully.
Some of our major areas of comparison were:
-Purpose
	Meta-class:  support modification of how classes operate
	Class:  provide a model for a set of similar objects and provide
		facilities common to that set of objects
	Object:  represent an entity in the simulation model presented 
		below and manipulate private data to provide specific 
		services for the system
-When Active:
	Meta-class:  generally at program construction and compile-time
	Class: program construction, compile-time, execution-time
	Object:  execution-time
-Directly Participates in Inheritance:
	Meta-class:  yes, when it exists
	Class: yes
	Object:  not directly
-Availability:
	Meta-class:  only a few languages make this available to the 
		programmer.  In other cases, it might be implicit and 
		used by the implementation
	Class:  most commonly used object-oriented languages, but not all
	Object:  all object-oriented languages

	We looked at the major architectures for object-oriented systems
including single-threaded, interrupt-driven, and pipeline.  In single
threaded, each object in turn passes messages to other objects and 
receives values back from those objects.  There is a single distinguished
function ( usually part of a class, but it might be standalone) that 
starts execution.  In interrupt-driven, a single function starts execution.
It sets up several objects, each assigned to monitor a particular external
activity.  Whenever, an external activity occurs, the corresponding 
monitor object executes.  THis is a very common way to implement user 
interfaces, for example.  In pipeline organizations, the objects are 
organized into several clusters.  Each cluster operates asynchronously 
from the others.  A cluster communicates with other clusters only by 
placing data in a common area for access by the other cluster.  THere is 
a need for facilities to support synchronization among clusters.

	Then we discussed how to decide upon the objects and classes that
should be present in a particular system.  The two most important
criteria for deciding how to organize the architecture of a system are:
1.  modularity:  since change is constant, try to partition the system as 
much as possible into small nearly-independent, but logically meaningful
 pieces.  Consequences of this criterion include:  each object should 
represent something meaningful, each object and class should be small ( usually no
more than about ten to twelve operations), and each operation should 
be small ( usually no more than about 10 to 12 executable lines of code);
2.  reusability:  the portions of a system that are specific to that
application or environment should be isolated.  Other objects should be 
as general-purpose as feasible given constraints on performance and size.
  We usually start by developing ideas for possible objects without worryin
about inheritance or classes.  Then we consider grouping objects into 
classes.  Finally we consider relationships among objects and classes
such as inheritance, delegation, and composition.

Remember:  developing the architecture for a system is an iterative
process.  THe first architecture you come up with should almost always be
thrown away in favor of a better one soon after you start to develop the
details.  If a software system has a lifetime of more than a couple of 
months, you should expect to redo your architecture as the system evolves.
   One commonly used technique
involves viewing the system as a simulation of a real or mythical part
of the world.  There are various agents in this world-view, each 
providing particular services.  The system has carry out particular 
responsibilities.  To do those, each agent may do one or more of three
activities:
1.  manipulate its private data;
2.  ask other agents to assist;
3.  interact with external entities such as users, files, networks, etc.
We try to identify the agents in this type of model and then 
implement each agent as an object.