ion The design technique of abstraction can be used to increase the amount of reuse within a set of classes by describing abstract classes that embody some of their shared state and/or behavior. One uses abstraction to construct a hierarchy relating several concrete classes to common abstract classes for better reuse of state and behavior. This emphasizes sharing of both state and behavior; abstract classes often implement algorithms in terms of methods that are overridden by concrete subclasses. The result of abstraction is a more horizontal hierarchy or a new protocol family. A typical abstraction example is building model graphical objects for an object-oriented drawing package. The first pass includes several concrete classes (for the different types of displayable objects). The later passes will use abstraction to reimplement these classes as a hierarchy with significant sharing among abstract and concrete classes. One would start by prototyping a wide and shallow hierarchy of DisplayItems from a collection of classes with little reuse. The first pass implements DisplayRectangle, DisplayCircle, and DisplayTriangle with common protocol but no inheritance among them and no state or behavior sharing. The second pass adds abstract class DisplayItem with position, size, and orientation instance variables and protocol for manipulation and display; concrete subclasses now inherit all their state and reuse shared protocol specification and implementations of most algorithms. The third pass refines this, adding another level of abstract modeling for line-segmentand arc-based DisplayItems; and easy extensibility is achieved. Further passes might identify Square as a special case of Rectangle and Circle as a special case of EllipticalArc. Figures 7 and 8 show three of the possible class hierarchies for DisplayItems. There are many approaches to the architecture of a framework for algorithmic composition or an algorithmic music description language. We illustrate the design as a multistep process that starts with the construction of an abstract class named EventGenerator as a subclass of EventList. Subclasses of EventGenerator should implement the message generateEvents, so we define it in the abstract class as subclassResponsibility (i.e., it is expected that subclasses will override it). The first-pass design's concrete classes are Chord (which might hold its root and its inversion), Roll (which has a single Event and can repeat it), Trill (repeat an EventList), Arpeggio (play with internote skew), Ostinato (repeat as a process), SelectorCloud (select from given pitch, amplitude, and voice sets), and PodCloud (select from given ranges). They share little state except what EventGenerator inherits by being a subclass of EventList. Several of them add instance variables to deal with their particular representations; and each implements its own generateEvents method. Shared state and behavior among EventGenerators is often not apparent until after the first implementation; and in the implementation of further subclasses, we use some of the first-pass classes as abstract intermediate classes. We try to push as much of the method implementation as possible into the abstract class EventGenerator; protocol and method implementations such as creation, accessing, and user interface can then be shared. Increased abstraction inserts abstract classes Cluster (a more general notion for chords), and Cloud (an abstract stochastic EventGenerator), and makes Trill a subclass of Roll (that repeats a collection of notes rather than just one). In Fig. 9 one can see the first-pass class diagram for EventGenerators and one of the possible abstraction-based refinements of this design. There are several trade-offs in using abstractionbased techniques. The DisplayItem and EventGenerator examples could each be used to demonstrate extremes of factorization or abstraction. Examining the construction of classes for the generation of many types of Chords, for example, one might implement a prototype that includes a class called Chord with many different methods for generating EventLists according to given rules and root