DESIGNING TO FACILITATE CHANGE

WITH OBJECT-ORIENTED FRAMEWORKS

BY

BRIAN FOOTE

B.S., University of Illinois at Urbana-Champaign, 1977

THESIS

Submitted in partial fulfillment of the requirements

for the degree of Master of Science in Computer Science

in the Graduate College of the

University of Illinois at Urbana-Champaign, 1988

Urbana, Illinois

DESIGNING TO FACILITATE CHANGE

WITH OBJECT-ORIENTED FRAMEWORKS

Brian Foote

Department of Computer Science

University of Illinois at Urbana-Champaign, 1988

Ralph E. Johnson, Advisor

Application domains that are characterized by rapidly changing software requirements pose challenges to the software designer that are distinctly different from those that must be addressed in more conventional application domains. This project assesses the impact of applying object-oriented programming tools and techniques to problems drawn from one such domain: that of realtime laboratory application programming. The project shows how a class inheritance hierarchy can promote the emergence of application specific frameworks as a family of applications evolves. Such frameworks offer significant advantages over conventional skeleton program-based approaches to the problems of managing families of applications. Particular attention is given to design issues that arise both during the initial design and implementation of such applications, and during later stages of their lifecycles, when these applications become the focus of reuse efforts. The project also addresses the impact of object-oriented approaches on the simulation of realtime systems and system components.

To Henry Hudson

This project has a longer history than most masters projects. This one is based on a larger system upon which I worked at the University of Illinois Department of Psychology's Cognitive Psychophysiology Laboratory (CPL). I am indebted to Emanuel Donchin, the CPL's Director, and to Earle F. Heffley III, the CPL's Technical Director, both for their willingness to allow me to explore new programming techniques with the CPL battery, which laid the foundation for this project, and for their support for my efforts to juggle school and work, which made this project possible.

I am grateful as well to Michael Faiman, Walter Schneider, and Arthur Kramer, who helped to convince me of the wisdom of pursuing an advanced degree.

Roy Campbell's advanced software engineering course had a major impact on my thinking about object-oriented framework lifecycle issues.

I'd like to thank Dan Ingalls, Kent Beck, and Barry Haynes of Apple Computer for providing me with up-to-date tools and assistance with the Macintosh Smalltalk that I used for the battery simulation.

Without the tireless help of my writing coach, Audrey Wells, this document would be in much sorrier shape than it is. The responsibility for those warts that remain, is of course, entirely mine.

Finally, I'd like to gratefully acknowledge the assistance, encouragement, enthusiasm and patience of my thesis advisor, Ralph Johnson. Without his willingness to embark on an open-end investigation rooted in an application domain somewhat foreign to day-to-day computer science, this effort (such as it is) would simply not have been possible.

Chapter II -- Background 5

Chapter III -- Anatomy of the Battery Framework 18

Chapter IV -- Anatomy of the Battery Library 143

Chapter V -- A Tour of the Battery Simulation 225

Chapter VI -- Discussion 229

Chapter VII -- Conclusion 277

References 279

Not all programming systems and methodologies are equally effective in supporting the graceful evolution of applications and systems. Certainly high-level languages such as Algol-68 and Pascal, and approaches such as stepwise refinement and structured programming have done much to ease the burden of the programmer designing new applications. The notions of encapsulation and information hiding, which have been embodied in languages like Ada and Modula-2, have contributed much to our ability to deal with large, complex problems and systems. These approaches, powerful though they may be, only begin to address the sorts of pressures one faces when an existing system must adapt to new requirements. The central focus of the work described herein is on how object-oriented languages, techniques and tools confront the problem of volatile requirements.

This document describes a project (the battery simulation) that assesses the value of bringing object-oriented tools and techniques to bear on problems drawn from the domain of realtime laboratory programming. The project was based upon a large laboratory system (the CPL battery, or the battery) developed by the author using more traditional tools and approaches. The project involved the reimplementation of substantial portions of the CPL battery using Smalltalk-80. The principal question that motivated this effort was: How might the use of object-oriented tools and techniques affect the design, implementation, and evolution of programs in this application domain?

The problems of realtime laboratory programming are quite distinct from those in areas that have been more comprehensively studied by computer scientists, such as compiler construction or operating system design. Realtime laboratory data acquisition and experimental control applications must flourish in a research environment that is (by the very nature of research itself) characterized by rapidly changing requirements. These applications must also operate under severe timing and performance constraints, and must be designed to facilitate graceful evolution.

The applications which provided the basis for this project (the CPL battery) resulted from a fairly ambitious attempt to address some of the requirements stated above using traditional programming tools. A number of the approaches taken in the design of the CPL battery were inspired by object-oriented techniques. This project (the battery simulation) represented an attempt to ascertain what impact the use of a full-blown, bona-fide object-oriented programming environment (Smalltalk-80) might have on a redesign and reimplementation of representative portions of the CPL battery.

This Smalltalk-80 reimplementation had, from the onset, an exploratory character. An important aim of the project was to examine how the Smalltalk language and system might affect the sort of code produced to solve laboratory programming problems. The "plumbing" data stream classes for data analysis and the "accessable object" record/dictionary classes are two of the more interesting results. Another goal was to assess the utility of Smalltalk's user interface construction tools in constructing these applications. The waveform and parameter browsing tools incorporated into the project resulted from this effort. The plumbing data stream classes, accessable objects, and the battery browsing tools are presented in detail in Chapters III and IV of this document.

The overriding focus of this effort, however, was not as much to see how object-oriented techniques might aid in the construction of any given application as it was to assess the ways in which these techniques might be used to avoid the sort of wasteful duplication that is conventionally seen in these sorts of application domains as requirements change.

One way in which object-oriented schemes help to meet this goal is by encouraging the design of general, application independent libraries of reusable components. More conventional programming environments do this too. The information hiding capabilities present in object-oriented languages and systems are of great benefit in promoting the development of reusable libraries.

Another way in which object-oriented approaches facilitate graceful component evolution is via the ability of an object-oriented system to support the customization of a general kernel of components through the specialization ability provided by inheritance. The specialization and reuse capabilities provided by object-oriented inheritance and polymorphism increase the potential applicability of both preexisting and user generated system components. Hence, effort spent making a component more general is likely to pay off sooner than it might in a conventional system.

The Smalltalk battery simulation uses a class inheritance hierarchy to help manage a set of related, evolving applications as they diverge from a common ancestor. The emergence of an application specific framework in the face of volatile requirements is perhaps the most interesting consequence of the use of object-oriented techniques.

Traditional tools and approaches in the laboratory domain encourage a programming style built around a library of context independent reusable subroutines and disposable custom programs built (perhaps) from simple skeletons. An object-oriented approach allows a broad middle ground between these two extremes: the application framework.

The existence of a mechanism that allows the graceful evolution of program components from the specific to the general is a valuable asset during the design of any system, but the value of such a capability takes on an additional dimension of importance when such systems must evolve in the face of highly dynamic requirements. Thus, designing to facilitate change takes in lifecycle issues that normally are addressed under the rubrics of reuse, maintenance and evolution.

Chapter II gives the history and background of this project, including a detailed description of the system upon which the project was based (the CPL battery), and discusses Smalltalk and object-oriented programming in general.

Chapters III and IV give the detailed anatomy of the Smalltalk-80 battery simulation framework and library.

Chapter V gives an illustrated tour of the battery simulation.

Chapter VI contains a discussion of a number of general questions and points raised by this research.

Chapter VII summarizes the project's results and conclusions.

A basic psychophysiological paradigm employed by researchers at the CPL is the so-called "oddball" paradigm [Donchin 81]. In an oddball experiment, a subject (typically human) is presented with a Bernoulli series of one of two alternative stimuli, such as high or low tones. Each such presentation constitutes a single trial. A complete series of such trials is called a block. In the simplest case, the subject's task is to count each occurrence of one type of stimuli, and ignore all occurrences of the other.

During this procedure, EEG is collected from the subject via electrodes affixed to the subject's scalp. This EEG is amplified and and fed into a computer-driven analog-to-digital converter. The phenomena of interest are low amplitude signals that are difficult to detect in the wash of noise that is typically present in the EEG collected for any given single trial. Thus, signal averaging is necessary to produce aggregate responses across collections of many trials.

All aspects of data collection and experimental control are under the realtime control of a laboratory computer system. This system must concurrently generate and present stimuli to the subject, digitize and store collected data on some secondary storage medium, and conduct an interactive dialog with the experimenter, which may include the generation of realtime waveform displays and the presentation of statistical information.

A single trial might last for a period of 1 to 2 seconds. Data are typically digitized at 100 to 200 points per second. Data from 2 to 32 channels (electrode sites) are recorded for each trial, and stored in real time to magtape or cartridge tape. In addition to the analog data, digital input data reporting a subject response to a given stimulus, together with a response time (RT) may be collected for each trial.

The definition of what constitutes adequate realtime performance varies enormously from one application domain to the next. Certain applications in high energy physics may require that microsecond or better accuracy be present in the relative timing among experimental events. Many process control applications (and so-called realtime operating systems) effectively define realtime as being within a line clock "tick" (1/50th or 1/60th of a second). Psychophysiological applications usually require that experimental timing be accurate to within a millisecond or so.

The computer system used to run these experiments is one designed and constructed at the CPL. These systems, called Pearl II systems [Heffley 85] are built around DEC LSI-11/73 processors, and contain from 256k to 4M bytes of memory. Among the more noteworthy attributes of these systems is the set of 6 custom PC cards that provide 6 realtime clocks, a 16/32 channel 12 bit DMA clocked A/D system, a 4 channel clocked 12 bit DMA system, and a custom DMA cartridge interface.

Programs are developed and run under the DEC RT11 operating system. Application programs are usually written in Fortran IV, with the assistance of a structured preprocessor called FLECS [Beyer 75] that provides facilities such as advanced control structures, constant definition, and internal procedures that are not (or were not) present in the Fortran 66-based DEC Fortran IV implementation.

Application development is supported by a large library of Fortran and PDP11 assembly language (Macro-11) subroutines called LABPAK [Donchin 75], [Foote 85]. This library provides fast implementations of operations that are time or performance critical, or beyond what can easily be accomplished in Fortran (such as device drivers).

The LABPAK library hides much of the detail and complexity of dealing with realtime device programming and high performance data manipulation from the application programmer. Hence, laboratory application development can be undertaken by researchers themselves.

Naturally, there is a great deal of variation among the levels of programming skills exhibited by researchers in this environment. A typical simple laboratory application program might be a few hundred lines long. Usually, such applications are written by a single individual to solve some problem immediately at hand. (Often, the programs generated by researchers are variations on the oddball theme discussed above.) Once written, such an application program may take on a life of its own. This is because research, by its nature, ensures that no single application stays current for very long. The problems presented by moving target requirements will be addressed in detail in Chapter VI.

It seemed obvious at the outset of this project that using the conventional approach of developing and maintaining a single separate application program for each required battery task was not feasible. The burden of maintaining such a large collection of programs appeared to have the potential of becoming overwhelming. The commonalities in the underlying structures of these applications ensured that large portions of each application would be duplicated across many or all of them. What's more, the high level of flexibility required by each of the specifications would have required that several versions of each item be developed if each had a scope similar to that of one of the applications we were used to.

Even when surface differences could be otherwise be reconciled, there was a need for variations in the user interfaces of the programs to tailor them to the needs of the various contractors, particularly with respect to the operator interfaces.

It was to meet these requirements that we developed the CPL Battery.

Typical CPL laboratory application programs have always had a brief list of parameters that could be modified by the experimenter using a simple table editing scheme. This parameter dialog might allow an experimenter to alter between 10 and 50 experimental parameters. In order to allow the large number of variations called for in the specification, a much larger number parameters seemed necessary.

To support this capability, we developed a stand-alone parameter editor, which could accommodate up to 512 parameters per battery item. This editor is table driven, and provides both type and subrange checking. Integer, Option (Boolean) and String types are supported by the battery editor. The editor provided a full screen, arrow and key-letter driven interface (which was still a novelty during the early 1980s) as well as a per parameter help capability (which is still more of a novelty than it should be.) The editor also supports the realtime interpretation of symbolic arithmetic expressions, and included a primitive constraint resolution mechanism. It also provided facilities for storing and retrieving sets of parameter values.

The tables that drive the parameter editor are also the basis for the battery data management scheme. By retaining symbolic information describing the contents of battery data records, any battery program or other utility may access data generated by any other utility. These tables are generated by a preprocessor that takes a textual description of each parameter, along with its help information, and generates binary tables, help files, and FLECS common definition files. These include files provide an efficient mechanism for establishing a correspondence between symbolic names in the parameter editor and variables in the application programs themselves.

The development of support for a multi-page parameter dialog permitted the design of a handful of general applications that could, by virtue of the high degree of configurability made possible by the large number of parameters present, take the place of a large number of single purpose programs.

To attempt to exploit the structural similarities between battery items, a decision was made to use the internal procedure and conditional compilation capabilities of the FLECS preprocessor to attempt to mimic an object-oriented inheritance hierarchy. This attempt proved quite successful. Each of the eight or so battery items is derived from a single common FLECS framework. The sharing of large amounts of structural code among all the battery items permits one to lavish this common core with additional attention and features, with the knowledge that this effort will benefit all the applications derived from it.

This attempt to employ object-oriented principles was motivated by a keen interest on the part of the author in object-oriented programming, and Smalltalk in particular. It was this interest, combined with the battery effort, that motivated the Smalltalk battery simulation described herein.

This chapter illustrates how an experimenter interacts with the CPL Battery. The screens depicted here show how an experimenter choses a battery item, inspects an item's parameters, and runs a block of trials.

The screen above shows the CPL battery's main menu page. Users select an item either by using the vertical arrow keys, or by using one of a set of single keystroke command synonyms.

The screen above shows the main menu of the Word Oddball battery item. User may run a block of trials, inspect and change parameter values, or manipulate and examine the contents of either a Pearl II 1/4 inch cartridge tape, or a 9 track magtape.

The screen above depicts one of the Word Oddball items parameter directory pages. This battery item has three such pages. Each entry in the directory refers to a parameter page that may in turn contain up to 16 parameters.

This screen shows one of the Word Oddball's parameter pages. This page contains parameters associated with data collection. The values of the A/D digitizing rate, the A/D digitizing time, and the number of data points per sweep may be traded off against one another. The results of doing so are immediately displayed. The single degree of freedom present in this calculation may be assigned using the "Calc" parameters. The effect of such manipulations on memory usage is reflected immediately in the "Bytes Free" parameter. Such calculations are conducted by special constraint satisfaction code built into the menu management program that drives this display.

The text at the bottom gives a brief description of the "A/D Gain" parameter. Such interactive help is available for all of a battery item's parameters. The user alters a parameter by moving the cursor to it using arrow keys, and typing return. The user may then type an expression, the value of which becomes the new parameter value, if the parameter's limit constraints are not violated. This expression may include most standard Fortran and C operators, as well as symbolic parameter names. Hence, "A/D Gain"*2+1 is a legal expression.

The Battery main menu and parameter dialogs seen here are all conducted by a single program, called MENU. This program operates on tables produced by a preprocessor called DICT. The input to this program is an ASCII description of each parameter, giving its type, limits, and initial value. The help information is also given in this file. The DICT program produces tables for the MENU program, along with Fortran common and constant definition files that are used by the FLECS preprocessor to allow efficient Fortran level access to battery variables.

The screen above gives a list of the commands available to the user in the parameter editor.

Thescreen above shows the information given to the experimenter just before a block is begun.

The Macintosh screen dump above shows part of the Word Oddball items runtime display. Trial categories are distinguished by bold and dim text. The trial number is given in the leftmost column, followed by the stimulus. The next three columns give subject response information. Since no subject was present when this example was run, the reaction time column (RT) is filled with zeros, and the response columns are written in reverse video, indicating that the responses for this trial are in error.

A number of factors made simulating the CPL battery in Smalltalk seem like a potentially worthwhile enterprise. The CPL battery was constructed using techniques and approaches that were taken from Smalltalk. The simulated inheritance hierarchy used to manage related applications and the highly interactive user interface present in the CPL battery were both inspired by Smalltalk. Both were simulated at considerable expense in the CPL battery. It seemed natural to ask what advantage there might be in using Smalltalk itself to construct a system with similar objectives.

The inheritance mechanism in Smalltalk is much more powerful (and less coarse) than the one used in the CPL battery. As for the user interface, Smalltalk is (rightfully) well known for having originated the bit-mapped, windowed user interface style that is so popular today. The Smalltalk environment comes with an extensive array of classes that support this user interface.

It seemed interesting to ask as well what impact an object-oriented language like Smalltalk might have on low level coding. Object-oriented polymorphism seemed to have the potential to allow low level code to cope with the needs of a family of related applications in a tidier fashion than conventional languages (like Fortran) might allow. Also, object-oriented programming styles encourage the development of a collection of modular application specific abstractions. Assessing the impact of using such abstractions on the coding process seemed a worthwhile pursuit.

Above all, however, the battery simulation was inspired by a desire to investigate the impact of object-oriented techniques and environments on the design of a family of diverging applications. In particular, I wanted to determine how a Smalltalk implementation of a system like the battery would support the sort of extension and change present in a laboratory environment.

Certain other aspects of the Smalltalk system made it attractive as well. Under Smalltalk-80, all the objects known to a given copy of the system are resident in that system's image. It struck me that such an environment might be an interesting place to investigate new ideas about managing the large volumes of data that are produced by laboratory applications, particularly with respect the problem of identifying and labeling such data. In a resident environment, stored data could retain their original identities as objects, and respond to their full repertoire of messages. The combination of resident data and the Smalltalk user interface tools seemed to have considerable potential.

One last aspect of Smalltalk versus the CPL development environment seemed compelling as well. The Apple Lisa and Macintosh MC68000 systems that supported the Smalltalk battery simulation had up to 2 megabytes of directly addressable memory available to them. The original CPL battery ran (and still runs) on DEC PDP-11 family processors that can, for most purposes, address only 64kb of memory directly.

This chapter, and the one that follows it, give a detailed exposition of all the code in the Battery simulation. It is hoped that the battery simulation can serve as a case study in the application of object-oriented frameworks. Every line of code in the simulation is presented, warts and all. The class definitions for this code are organized into 14 major categories. (The names given are Smalltalk system category names.) The first 8 categories contain code that is relatively battery specific. These constitute the bulk of the battery framework. The remaining 6 categories contain code that is largely battery independent. These classes hence play a role similar to that of library components in a conventional system. These classes are discussed in Chapter IV. The categories are:

Battery-Items The Sternberg, Word and Tone Oddball

Battery-Parameters Parameter carriers for the Battery Items

Stimulus-Generators Pluggable stimulus presentation devices

Stimulus-Support Stimulus descriptor objects

Sequence-Support Stimulus sequences generation support

Response-Support Subject response descriptor objects

Data-Management Data archive simulation objects

Interface-Battery Support for browsing battery items

Realtime-Support Simulated realtime timebase code

Realtime-Devices Clocks, digitizers, digital I/O devices

Waveform-Support Waveform collection and statistics

Random-Support Random integer and stream support

Plumbing-Support Objects for connecting streams together

Accessable-Objects Support for record/dict. transparency

The Battery-Items category contains the core of the battery simulation: the abstract class BatteryItem. BatteryItem is the principal component of the psychophysiological experimental application framework. This class is the superclass of the three concrete battery items presented here: WordOddball, ToneOddball, and SternbergTask. One of the central goals of this simulation was to demonstrate how a class inheritance hierarchy could be used allow a family of related application programs to share common code.

The Battery-Parameters category contains a set of record-like objects that carry the user modifiable parameter values for each battery item. These are organized in a hierarchy that mirrors the battery item hierarchy. The use of separate objects to embody the configurable state of battery items simplifies and isolates the design of the battery parameter viewing mechanism.

The Stimulus-Generator category embodies an attempt to construct interchangeable stimulus generation modules that could be fitted into any appropriate application.

The Stimulus-Support and Response-Support categories contain classes that function as descriptors that ferry information between the battery items themselves and the stimulus generation and response reporting systems.

The Battery-Parameters, Stimulus-Generator, Stimulus-Support, and Response-Support categories are examples of objects which have been factored out of the original battery item design as discrete components. An experimenter constructing a new experiment will extend BatteryItem, or some subclass thereof, along with members of these hierarchies. Because these elements are not subclasses of BatteryItem itself, these components can be mixed and matched as black boxes among BatteryItems.

The Sequence-Support category supports the generation of experimental stimulus sequences.

The Data-Management category contains a set of descriptor classes that provide the foundation for a dictionary-based data archiving scheme. Class BatteryTrial contains waveform data and descriptive scalar information for each single trial that is performed. A BatteryBlock contains all the trials collected during a given experimental run. Each completed BatteryBlock is entered into a DataDictionaryEntry descriptor and entered into a DataDictionary. Class BatteryItem contains an instance of DataDictionary that serves as the master repository for battery data.

The Interface-Battery category supports the Battery browser. This browser allows an experimenter to access a list of battery items, inspect or alter the parameters for a given battery item, and run a battery item. A running battery item maintains a dynamic waveform display.

The code for the battery independent categories is described in the Chapter IV.

The code for each system category is presented in turn. A general description of each category is given first, along with a list of the classes defined in that category. Each class in the category is then presented. Each class description begins with a table that resembles a standard Smalltalk class definition template. The class name and its superclass are given, first followed by lists of instance and class variables. Inherited instance variable names are given in italics. These lists are followed by the pool dictionary list, the category name, and a table showing the class hierarchy.

The classes in the Battery-Items category constitute the framework around which the Battery simulation is built. The classes are:

BatteryItem A generic battery item

SternbergTask A Sternberg memory task

ToneOddball An auditory oddball experiment

WordOddball A visual semantic oddball experiment

Class BatteryItem is the central core of each of the three actual battery items implemented herein. BatteryItem is an abstract superclass, since it exists only to provide a repository for the common behaviors among the three concrete battery items.

A BatteryItem is a generic psychophysiological experiment. A BatteryItem object's job is to run a block of experimental single trials whenever it receives the doBlock message. A block is a collection of a designated number of single trials. The number of trials in a block is an experimental parameter.

A single trial, or trial, corresponds to the presentation of a stimulus or a sequence of stimuli to an experimental subject. For each trial, a BatteryItem must coordinate the timing and presentation of stimuli, the collection of A/D waveform data (using an analog-to-digital converter, or digitizer), the collection of discrete response time information, and the maintenance of cumulative statistics and experimenter displays. A BatteryItem must accurately orchestrate all these activities in (simulated) real time.

BatteryItem is a subclass of AccessableObject, which enables each of its instance variables to be accessed as though a BatteryItem were a dictionary. AccessableObjects allow new key/value pairs to be defined, which will then also respond to the conventional instance variable accessing protocol (item, item: value). See the discussion of category Accessable-Objects for more information on what AccessableObjects can do. BatteryItems inherit the instance variable items from AccessableObject. This instance variable helps to provide the soft instance variable facility mentioned above.

The class variable BatteryDataDictionary is an important component of the battery simulation's rudimentary data management scheme. Rather than writing battery data to some external medium, the battery simulation enters the data collected during each run of a battery item into a dictionary that is kept in BatteryDataDictionary.

class name BatteryItem

superclass AccessableObject

trialClock

stimulusClock

digitizer

responseDevice

parameters

stimulusSequence

sequenceGenerator

stimulusGenerator

buffer

experimenterLog

waveformDisplay

block

blockNumber

nextTrial

currentTrial

currentTrialNumber

outputStream

averagePipeline

tallyPipeline

BatteryDataDictionary

category Battery-Items

Object

AccessableObject

BatteryItem

SternbergTask

ToneOddball

WordOddball

The fundamental operation that a BatteryItem can be called upon to perform is to doBlock, which defines the basic sequence of block activities. Any time consuming block preparations are made by prepareBlock. These include updating the block counter, preparing a stimulus sequence, preparing the data management system, and setting up the dataflow data processing fixtures. Then, time-critical block start-up actions are performed by startBlock, such as informing the stimulus generator object that the block is starting.

The division of labor among the components that constitute a battery item is such that each battery item works with a discrete stimulus generating object of some sort. For some applications, the internal mechanisms of this object might be quite complex, and hence there is a need to synchronize it with the block and trial sequencing done by the battery item.

The runBlock method is the heart of the block control mechanism. It zeros a trial counter, and proceeds to generate and execute trials. A trial is executed by sending the doTrial message to a battery item. The trial control code is discussed below.

When the block has completed, the finishBlock method is executed. This method tells the data management and stimulus generation components to perform any block termination activities that they might require.

An experiment that required that basic changes be made to a BatteryItem's block sequencing behavior might override these methods. For example, an experiment that required that a sequence of blocks be run in order with only minor, systematic changes to experimental parameters might override some of these methods.

The doTrial method conducts an experimental trial. The startTrial method starts the single trial timer (which is returned by the trialClock method) for an amount of time indicated by the trialDuration method. The runTrial method is the generic trial body. It calls collectData and processData.

The collectData method must be provided by BatteryItem's subclasses, and is, in this implementation of the battery, the primary locus of differences among BatteryItem's concrete subclasses.

The processData method takes the data deposited in the buffer object and per-trial data structures and performs per-trial processing on them.

The prepareNextTrial method constructs the per-trial data objects for the next trial. This method allows us to overlap the perhaps time consuming preparation of the next trial with the often relatively quiescent period at the end of the current trial.

The finishTrial method simply waits for the trial clock's time to elapse.

The methods in this category are all called in response to an initialize message to a BatteryItem. The initialize message zeros the block number instance variable, and sends an allocateResources message to the BatteryItem. This method then invokes the remainder of the resource allocation code. They are concerned primarily with the one-time creation or allocation of per-item resources.

Note that allocateParameters and allocateStimulusGenerator are responsibilities of the concrete subclasses of BatteryItem. None of the other initialization messages in this incarnation of the battery are overridden.

Data collection strategies will usually differ sufficiently among different battery items so as to make it necessary for this code to be implemented further down in the inheritance hierarchy.

The collectData method must be implemented by each subclass of BatteryItem to orchestrate the basic data collection sequence for that item. This method will usually contain a sequence of experimental control and data acquisition method invocations that will together define the heart of the experiment implemented by a given battery item.

The startDigitizer method will often (always given the current framework) be called from collectData to start the A/D system.

The prepareProcessingFixtures method prepares the data averaging and statistical data accumulation pipelines. The averaging fixture set up method, prepareAverageFixtures should be provided by subclasses of BatteryItem. Each subclass will typically call average:using:withLabel: for each average category it wishes to define.

The average:using:withLabel: method constructs a dataflow pipeline that evaluates a given source block after the data for each trial are collected, and forces the result of that block down a pipeline using the indicated valve (conditional) block. If this valve is open, this result can then flow into the Averager object for the pipeline. The pipeline is constructed using the pseudo-Stream objects defined in the system category Plumbing-Supplies.

The average:using:withLabel: method works as follows: First, an average buffer into which a running average will be accumulated is created. Next, this buffer (the WaveformCollection) is entered into the average dictionary in the current TrialBlock object using the given label as a key. Next, a Pump object is created, and a ValueSupply object using the given source block as its source is connected to the input (source) side of the Pump (using the << or connect input message). Then, the output side of the dataflow pipeline is connected (using >>) to the effluent (sink) side of the pump. The first stage of the output pipeline is the Valve object, and the final stage is an Averager on the average buffer we created. Finally, the fixture is entered into an averagePipeline dictionary kept by this instance of BatteryItem.

The tally:using:withLabel: method uses a similar scheme to construct pipelines for incrementally accumulating statistical information using Tally objects. Tally objects are objects into which pipelined data can be fed that monitor the data that pass through them and accumulate statistical information about those data. Tally objects can later be asked for statistical characterizations of the data that have passed through them. (For instance, they can be asked to give a count, or an average, of the data they have seen.) The nature of the data collected will of course depend on the nature of the Tally object itself. The pipelined scheme used here allows the nature of strategies for accumulating and processing statistical data to be implemented independently of the contexts in which they are employed.

The prepareStatsFixtures method constructs a set of fixtures for collecting BatteryItem button box response time data. First, the tally pipeline and tally collection dictionaries are created. The tally pipeline dictionary holds the root of each pipeline we have built (i.e. its Pump object), so that when the time is right, each pipeline can be told to move data from its ValueSupply block down (Value permitting) to its effluent sink (the Tally object). The TrialBlock's tally dictionary provides access to the Tally objects at the end of the pipelines for posterity's sake. The pipeline fixtures and tally objects are entered into these dictionaries by tally:using:withLabel:. The real work in the prepareStatsFixtures method is performed by calls to tally:using:withLabel:.

For all three of the pipelines constructed by this method, the values are generated using a block that asks the current trial for its response time. The pipelines differ in the labels given them, and in the condition under which the pipeline's Valve object will permit the data returned as a result of evaluating the value block to be passed through to the Tally object. The first pipeline checks only that the value passed it is not nil. Each of the other two adds at test for whether one or the other of the response buttons was pressed in addition to the test for nil. Note that the block passed through to the ValueSuppy takes no arguments, while the block passed to the Valve object takes one argument. When a Valve object is passed a value, it will pass this value in turn to its test block as the block's argument.

The purpose of all of this is to simplify the process of adding new statistical categories to data collection programs. Using the pipelining scheme, all one would have to do to add a new statistical category is make a single additional call to tally:using:withLabel: to define the new category. All of the statistical characterizations of which the Tally objects are capable will then be available. It is interesting to contrast the relative ease of this process with the tangle of additional variables, declarations and code that is typically generated when an experimenter desires that new statistical categories be added to a program using a conventional programming language, such as Fortran. The pipeline approach encapsulates the details of the statistical collection process, such as the temporary variables, the category criteria, etc.

The processData method is called from runTrial. It outlines our generic mechanism for dealing with collected data. First, the subject's response, (if any) is evaluated. Next, the data for this trial are stored. Then the per-block averages and statistics are updated. Finally, the waveform and experimenter log displays are refreshed.

The system transcript is used as an experimenter log in this implementation of the battery. Single channel number one of the (single trial) data buffer is displayed in the BatteryItem's WaveformView.

The updateAverages and updateStatistics methods illustrate how data are extracted from the ValueSupply blocks of the plumbing fixtures and are flushed down into the effluent sides of the pipelines. Each pump object in the average and tally pipeline dictionaries is sent the message nextPut to accomplish this. The nextPut method moves one value from the intake to the effluent side of a Pump.

This implementation of the battery uses a class variable common to all instances of BatteryItem to store a global data dictionary. The dataDictionary method returns this dictionary.

Every time a battery item collects a block of data, it enters a DataDictionaryEntry object containing the TrialBlock object into the data dictionary under a name generated by the entryName method. The entryLabel method provides additional descriptive information. This label is stored in the DataDictionaryEntry object as well.

The prepareDataManagement method allocates a new BatteryBlock object, and fills it with a copy of the BatteryItem's own parameter object, and an empty trial array. It then creates a WriteStream over the trial array, and installs this as the BatteryItem's output stream. To the rest of the BatteryItem code, outputStream is merely a sink of some sort down which single trial objects can flushed.

The storeCurrentTrial method copies data from the digitizing buffer into the current trial object, and sends this object down our outputStream.

The finishDataManagment method is charged with creating the DataDictionaryEntry for a completed block, and storing this entry in the master data dictionary.

The prepareStimulusSequence method sets up a stream from which individual stimuli can be read for each trial. It does this by first creating a sequence (using the sequenceGenerator) using a given collection of stimulus template objects, a trial count, and a collection of relative stimulus probabilities. We then set up a SampledStream over this sequence so that we may draw from it in a random order without replacement. The sequence generation scheme is interesting in that it is constructed using parts (WeightedCollections and SampledStreams) that were much more specific to this application domain earlier in the design process. The current design broke out these two potentially general components and employs the Unix philosophy of constructing special purpose components by composing a handful of general building blocks rather than building a single special purpose component from scratch.

The selectNextStimulus method merely copies the next stimulus from the stimulus stream into the current trial object. Note that we make a deepCopy of the stimulus object rather than passing a reference to it. This is because the stimulus sequence uses multiple references (via the WeightedCollection) rather than copies, and because there is no telling whether a subsequent analysis application might elect to make some destructive reference to one of these objects. (The issue of when to copy an object or when to pass a reference to it is one that arises frequently in languages like Smalltalk and Lisp. [Bobrow 86] describes an approach to this sort of problem-based on a lazy copy-upon-destructive-reference-scheme.)

The turnOnTheStimulus and turnOffTheStimulus methods pass the current stimulus object to this BatteryItem's stimulus generator.

The response control protocol for battery items consists of two methods. The enableResponseReporting method passes an enable method on to the response device. The evaluateResponse method queries the response device, and loads the fields of the returned response into the current trial object. Note that these values are stored using message sends to self, so that a different data management scheme might easily be substituted.

The use of message sends to self insulates the bulk of the code in BatteryItem from changes in the design of the data structures (which have indeed occurred during the evolution of this project).

The use of message sends to self helps to encapsulate the bulk of the battery item framework from the details of our single trial data management strategy. This strategy, like the parameter and stimulus management strategies, has evolved considerably since the start of this project.

Perhaps the most interesting thing about this protocol category is that it was generated automatically, using

the accessingSubclass: instanceVariableNames: classVariableNames: poolDictionaries: category: method found on page 289 of the Smalltalk Blue book [Goldberg 83].

class BatteryItem class

superclass AccessableObject class

The backUpEverything method first files out all the categories in the list returned by the batteryCategories method as separate <Category-Name>.st files using the fileOutCategories: method. It then files out these same categories into a single file named 'Project-Sources.st' using the fileOutCategories:on: method. Then it files out the changes set [Goldberg 85] to 'Project-Changes.st' using the fileOutChangesOn: method.

The fileOutBundledCategories:on: method creates a Unix shar archive file that can create a set of individual system category *.st files on a Unix system. (Use the Bourne shell). The comment at the beginning of this method givens an example of how one might use the matchSystemCategories: method.

The print out messages printOutBundledCategories:on:, printOutCategories and printOutCategories:on: are similar in function to the analogous file out messages, except that they create Unix troff ready output files. These may be processed along with a macro file named tmac.st using the command: rditroff -ms <name>. (The tmac.st file should be in the default directory when rditroff is run.) The Smalltalk code to generate troff ready output was derived from code from the Berkeley Smalltalk distribution kit [Krasner 83].

class name SternbergTask

superclass BatteryItem

category Battery-Items

Object

AccessableObject

BatteryItem

SternbergTask

ToneOddball

WordOddball

The pattern for presenting the actual stimulus (i.e. the probe) is similar. First, a probe is prepared. The program then waits until the time at which the probe is to be presented arrives. Then, a timer is started so that there will be a timebase relative to the stimulus onset. Next, the probe is turned on, and the response reporting system is enabled. When the stimulus duration has elapsed, the stimulus is turned off.

When all the data have been collected, a check is made to see whether additional time is necessary for subject response data collection.

The prepareNextStimulus method selects both a memory set and a probe for the next trial. The way in which the memory set is selected shows a novel application of SampledStreams. The memory set should be a set of a given size drawn at random (without replacement) from a given vocabulary of characters.

This set is constructed as follows: First, a SampledStream is created over the BatteryItem's vocabulary string. Then an empty output string (the memory set) is created, and a WriteStream is defined over it (memorySetStream). The memory set is constructed by moving the appropriate number of characters from the input (sampled) stream to the output stream. The underlying collection of this output stream is the memory set, which can then be used.

The probe is selected and prepared as follows: If a positive trial is called for, a single character is selected at random, using a RandomStream (sample with replacement) over the memory set. If a negative probe is required, the next character in the vocabulary stream that was used to create the memory set, from which the memory set has already been drawn, is selected as the stimulus character.

The prepareTheMemorySet method simply forwards the current stimulus descriptor to the stimulus generator. The remaining methods in this protocol category similarly forward stimulus manipulation requests to the stimulus generator.

class SternbergTask class

superclass BatteryItem class

class name ToneOddball

superclass BatteryItem

category Battery-Items

Object

AccessableObject

BatteryItem

SternbergTask

ToneOddball

WordOddball

class ToneOddball class

superclass BatteryItem class

It is instructive to point out that to implement a concrete BatteryItem, it is necessary for an experiment to implement just four methods: allocateParameters, allocateStimulusGenerator, collectData, and prepareAverageFixtures. To fully exploit the battery framework, an experimenter might also need to create new subclasses of BatteryParameter, StimulusGenerator, and Stimulus hierarchies.

class name WordOddball

superclass BatteryItem

category Battery-Items

Object

AccessableObject

BatteryItem

SternbergTask

ToneOddball

WordOddball

The battery simulation has attempted to separate battery items and (simulated) stimulus generation equipment so that stimulus generators might be mixed and matched among several different battery items. Frequently, the major differences among a collection of experimental designs will be in sorts of stimuli they employ. By separating the stimulus generation code from the rest of the experimental code, the reusability of both should be enhanced.

The stimulus generation and response reporting hierarchies are examples of places in this battery simulation where tasks handled in the original CPL battery by (simulated) inheritance are now handled by discrete components. The evolution of inheritance frameworks into component frameworks is discussed in Chapter VI.

The allocateParameters and allocateStimulusGenerator methods implement item specific parameter and stimulus generator resource allocation code. Of interest here is the scheme we use in allocateStimulusGenerator for implementing our random word lists. A dictionary of streams is created which is keyed by the two stimulus categories. Each stream is a RandomStream over a vocabulary array. Since RandomStreams sample with replacement, they will provide, each time they are asked, a random word from their respective underlying vocabularies. This dictionary, once constructed, is given to a newly created WordGenerator (a subclass of StimulusGenerator).

The collectData method specifies experimental control and data acquisition scheme used for this item. First, the digitizer is started. Then the method waits for a baseline period, relative to the start of this trial, to elapse. Then, the stimulus timer is started. Immediately thereafter, the method turns on the stimulus and enable response reporting. When the stimulus presentation period has elapsed, the stimulus is turned off. The method then waits until data collection is complete, and the response window time has elapsed.

The perceptive reader will note that the collectData method given here is identical to the one given in ToneOddball. I could have either defined an intermediate abstract calls (say, SimpleOddball) between BatteryItem and these two classes to take advantage of this. Alternately, I could have made this implementation of collectData the default in BatteryItem itself. That I did neither is in recognition of the fact that in a somewhat fuller battery simulation, detail that would distinguish a larger set of applications from one another would quickly emerge at this level, just as it does in the SternbergTask battery item.

Each concrete battery item must provide its own prepareAverageFixtures method. This is necessary to take into account item specific stimulus characteristics and labeling requirements. A detailed discussion of the mechanics of fixture preparation can be found in the discussion of this protocol category given for class BatteryItem.

class WordOddball class

superclass BatteryItem class

BatteryParameters Houses common BatteryItem parameters

SternbergTaskParameters Adds SternbergTask specific parameters

ToneOddballParameters Adds ToneOddball specific parameters

WordOddballParameters Adds WordOddball specific parameters

Parameter objects are distinct objects rather than parts of the items themselves for several reasons. One is that, as separate objects, they can be copied and archived along with the collected data without recording the entire state of the item itself. This distinction between the parameter objects and the item objects could become more significant should an external data management scheme be implemented. The second reason for keeping parameter objects separate is to distinguish values that should be presented to the user for alteration via the battery user interface from the battery item's other instance variables. Parameter objects might also serve as a components in a more general (and yet to be designed) user parameter management/interface scheme.

class name BatteryParameters

superclass AccessableObject

baseline

channels

points

digitizingRate

responseMax

stimulusDuration

trialDuration

trials

writeDataFlag

probabilities

stimuli

inputBitA

inputBitB

name

label

category Battery-Parameters

Object

AccessableObject

BatteryParameters

SternbergTaskParameters

ToneOddballParameters

WordOddballParameters

class BatteryParameter class

superclass AccessableObject class

class name SternbergTaskParameters

superclass BatteryParameters

memorySetBaseline

memorySetDuration

probeBaseline

probeDuration

memorySetSize

vocabulary

category Battery-Parameters

Object

AccessableObject

BatteryParameters

SternbergTaskParameters

ToneOddballParameters

WordOddballParameters

class name ToneOddballParameters

superclass BatteryParameters

outputBitA

outputBitB

category Battery-Parameters

Object

AccessableObject

BatteryParameters

SternbergTaskParameters

ToneOddballParameters

WordOddballParameters

class name WordOddballParameters

superclass BatteryParameters

category Battery-Parameters

Object

AccessableObject

BatteryParameters

SternbergTaskParameters

ToneOddballParameters

WordOddballParameters

Stimulus generator objects are designed to be self-contained embodiments of specific stimulus generation schemes. Since these schemes themselves vary with experimental designs as well as with the basic hardware and software characteristics of the stimulus generators, the external protocols for these objects vary as well. Note that though the stimulus generator classes defined here exactly mirror the BatteryItem hierarchy, this might not necessarily be the case in a fuller simulation.

The StimulusGenerator hierarchy shows how a portion of the battery simulation that was formerly embedded in the BatteryItem hierarchy has, under Smalltalk, evolved into a separate part of the overall battery framework. The reuse of pluggable, black-box components is, all other things being equal, preferable to reuse via inheritance. The identification of components that may be factored out of an inheritance hierarchy in this fashion is usually possible only after several iterations through the design process. (This issue is discussed in detail in Chapter VI.)

Indeed, the StimulusGenerator hierarchy is in some respects still in transition between membership in the original battery hierarchy and clean isolation from it. The degree of coupling seen in the interface between each battery item and these classes is still somewhat high.

One very intriguing route by which this coupling might be reduced is via the introduction of parallelism. Under such an approach, stimulus generators would run in parallel with battery items, with both tied to the same underlying timebase. Such an approach would simplify both the battery item stimulus coordination code, and the stimulus sequencing code in this stimulus generators. Hence, the use of parallelism could greatly increase the generality and reusability of components of both hierarchies.

Realtime application programs frequently exhibit a structure in which the mainline code must explicitly schedule sequences of otherwise unrelated events. The use of parallel processes can free the designer from this temporal yoke.

The classes in this category are:

StimulusGenerator Abstract StimulusGenerator superclass

SternbergDisplayGenerator The SternbergTask stimulus generator

ToneGenerator The ToneOddball stimulus generator

WordGenerator The WordOddball stimulus generator

class name StimulusGenerator

superclass Object

category Stimulus-Generators

Object

StimulusGenerator

SternbergDisplayGenerator

ToneGenerator

WordGenerator

class StimulusGenerator class

superclass Object class

class name SternbergDisplayGenerator

superclass StimulusGenerator

category Stimulus-Generators

Object

StimulusGenerator

SternbergDisplayGenerator

ToneGenerator

WordGenerator

This class is probably misplaced in the StimulusGenerator hierarchy. The fact that it in effect removes nearly the entire StimulusGenerator protocol is evidence that this hierarchy needs reorganization. This class is an example of a stimulus generation scheme that uses multiple stimulus events. In the CPL Battery, two items exhibited this structure. The other items exhibited the simpler structure that is reflected in the standard protocol for stimulus generation given in StimulusGenerator.

I deferred a major reorganization of this hierarchy in recognition of the potential a process-based organization might bring to the battery framework.

class name ToneGenerator

superclass StimulusGenerator

bitA

bitB

category Stimulus-Generators

Object

StimulusGenerator

SternbergDisplayGenerator

ToneGenerator

WordGenerator

When a block is begun, the startBlock method sends clear messages to both the output bits to ensure that they are off. The same thing occurs at the end of a block in finishBlock.

The turnOn: and turnOff: methods both accept a stimulus descriptor, and check its primary stimulus field. If this field is #toneA, the output bit A is affected, and if it is #toneB, output bit B is affected.

class ToneGenerator class

superclass StimulusGenerator class

class name WordGenerator

superclass StimulusGenerator

streamDictionary

category Stimulus-Generators

Object

StimulusGenerator

SternbergDisplayGenerator

ToneGenerator

WordGenerator

The turnOn: method simulates the display of a word stimulus by writing it to the system transcript.

class WordGenerator class

superclass StimulusGenerator class

Note that these streams might be RandomStreams over a relatively small vocabulary (as in the implementation of WordOddball given herein), or actual word lists. The stream dictionary scheme isolates this class from such detail.

This system category defines a family of stimulus descriptor objects which are manipulated by the various objects concerned with stimulus identity, such as the battery items themselves, the stimulus sequencing and generation objects, the data management system, and the averaging and statistics collection code. The objects in this category are:

Stimulus Defines the basic stimulus descriptor

SternbergStimulus Adds Sternberg specific stimulus fields

ToneStimulus Adds ToneOddball specific fields

WordStimulus Adds WordOddball specific fields

Stimulus is an abstract superclass for a family of stimulus objects. It defines a field for a stimulus category indicator of some sort.

class name Stimulus

superclass Object

category

category Stimulus-Support

Object

Stimulus

SternbergStimulus

ToneStimulus

WordStimulus

The SternbergStimulus class adds fields for the memory set and probe stimulus to Stimulus.

class name SternbergStimulus

superclass Stimulus

instance variable names

memorySet

probe

category Stimulus-Support

hierarchy

Object

Stimulus

SternbergStimulus

ToneStimulus

WordStimulus

The ToneStimulus class adds a field for the primary stimulus type to Stimulus.

class name ToneStimulus

superclass Stimulus

primary

category Stimulus-Support

Object

Stimulus

SternbergStimulus

ToneStimulus

WordStimulus

The ToneStimulus class adds a field for the primary stimulus type to Stimulus.

class name WordStimulus

superclass Stimulus

primary

word

category Stimulus-Support

Object

Stimulus

SternbergStimulus

ToneStimulus

WordStimulus

WeightedCollection A collection with fixed proportions

SequenceGenerator A stimulus sequence constructor

class name WeightedCollection

superclass RunArray

weights

category Sequence-Support

Object

Collection

SequencableCollection

ArrayedCollection

RunArray

WeightedCollection

Note that the weight and run sets should be changed only at the user's peril, since these are not mutually constrained in this implementation of WeightedCollection.

class WeightedCollection class

superclass RunArray class

If the sum of the counts produced by weighting the size comes up short, then error will be positive. If this value is too large, error will be negative. The test on error is used to set adjust to a positive count of the number of values that need to be changed to balance the counts, and increment to plus or minus one. The error is then distributed among the first adjust elements of the counts collection. This collection then appeals to RunArray class to construct our underlying RunArray. The original weight set is also stored for use by grow:.

class name SequenceGenerator

superclass Object

length

probabilities

stimuli

category Sequence-Support

Object

SequenceGenerator

The constructSequence method merely passes the buck to WeightedCollection to get its work done.

class SequenceGenerator class

superclass Object class

ButtonBox Simulates a subject response box

ButtonBoxResponse Describes a subject response instance

A clock is also associated with each ButtonBox for response time reporting. Since InputBit events are simulated using the Smalltalk mouse buttons, it is possible to demonstrate actual ButtonBox events when a simulated BatteryItem is run.

class name ButtonBox

superclass Object

bitA

bitB

clock

category Response-Support

Object

ButtonBox

ButtonBoxResponse

The enable method arms the ButtonBox by passing an enableUsingClock: message to both of the ButtonBox's InputBits.

The response query is sent by the user of a ButtonBox to test for whether any response activity has taken place. A ButtonBoxResponse object will always be the result of such a query. If no button press has occurred since the last query, the ButtonBoxResponse object will contain only default values.

Responses are detected by testing the flags of each InputBit object. If one of these flags is set, a #buttonA or #buttonB response event is reported, together with the time (relative to the clock that was originally passed) at which the event occurred. Note that if both button A and button B were pressed, the button A event is given precedence. More complex button box designs might adopt some different strategy.

class ButtonBox class

superclass Object class

ButtonBoxResponse objects are returned by ButtonBoxes in response to response queries. They convey a response button code and a response time. The possible response button codes are determined by the ButtonBox object.

class name ButtonBoxResponse

superclass Object

responseButton

responseTime

category ResponseSupport

Object

ButtonBox

ButtonBoxResponse

BatteryBlock A per-block data record

BatteryTrial A per-trial data record

DataDictionary Repository for archived battery data DataDictionaryEntry An entry in a DataDictionary

class name BatteryBlock

superclass Object

parameters

singleTrials

tallies

averages

category Data-Management

Object

BatteryBlock

class name BatteryTrial

superclass Object

trialNumber

stimulus

responseType

responseTime

data

category Data-Management

Object

BatteryTrial

class name DataDictionary

superclass AccessableDictionary

category Data-Management

Object

Collection

Set

Dictionary

AccessableDictionary

DataDictionary

class name DataDictionaryEntry

superclass Object

name

type

label

date

time

data

category Data-Management

Object

DataDictionaryEntry

class DataDictionaryEntry class

superclass Object class

ListHolder A simple generic model for ListViews

ItemListController Controller for a battery item list

ParameterListController Controller for a parameter list

BatteryCodeController Controller for the expression window

WaveformController Controller for a waveform view

BatteryBrowser Model for a set of battery items

ItemListView View of a list of battery items

ParameterListView View of the parameter list

BatteryView TopView for a battery browser

BatteryCodeView View for expression evaluation

WaveformView A graphical view of a waveform

This function has been largely subsumed by Version II SelectionInListView objects. The Apple Smalltalk image used for this simulation was based on a Xerox Smalltalk-80 Version I image that did not have pluggable views.

class name ListHolder

superclass AccessableObject

list

listIndex

category Interface-Battery

Object

AccessableObject

ListHolder

class ListHolder class

superclass AccessableObject class

class name ItemListController

superclass ListController

ItemListYellowButtonMessages

ItemListYellowButtonMenu

category Interface-Battery

Object

Controller

MouseMenuController

ScrollController

ListController

ItemListController

The changeModelSelection: method inherited from ListController is overridden here to invoke toggleItemListIndex instead of toggleListIndex. When complex models like the BatteryBrowser with multiple cooperating views are used, it is necessary to differentiate at the model level among list update requests. In conventional ListViews, this is usually done by overriding changeModelSelection in the manner just described.

Version II SelectionInListViews allow the selectors for these sorts of functions to be built into "adaptor" variables stored in the Views. The views themselves must also distinguish multiple update requests when a complex model is used. This is done using view defined update: parameter protocols. Traditional ListViews must override update: to add this behavior. SelectionInListViews once again make this part of the adaptor.

class ItemListController class

subclass ListController class

class name ParameterListController

superclass ListController

ParameterListYellowButtonMessages

ParameterListYellowButtonMenu

category Interface-Battery

Object

Controller

MouseMenuController

ScrollController

ListController

ParameterListController

class ParameterListController class

superclass ListController class

Two menu entries are defined (as examples) here, both of which are linked to the doNothing method.

class name BatteryCodeController

superclass StringHolderController

paragraph

category Interface-Battery

Object

Controller

MouseMenuController

ScrollController

ParagraphEditor

StringHolderController

BatteryCodeController

class name WaveformController

superclass Controller

cursorPosition

category Interface-Battery

Object

Controller

WaveformController

class name BatteryBrowser

superclass StringHolder

itemList

itemListIndex

parameterList

parameterListIndex

runSwitch

parameterKeyList

waveformView

category Interface-Battery

Object

StringHolder

BatteryBrowser

The toggleItemListIndex: method is invoked when a new item list selection is made. First, the wait cursor is turned on. Then our item list selection is updated. Next, since either the current battery item was deselected or a new battery item in the item list was selected, the parameter list must be reset. We update the parameter list and the parameter key list, set its selection to zero, and clear the contents of our code view. We then declare that the item list has changed. (ParameterListViews respond to both item list and parameter list changes. BrowserCodeControllers respond to any update whatsoever.)

The toggleParameterListIndex: method saves the new list index given it, and stores the store string for the current parameter value as our contents. A parameter list update is then declared, which will update the ParameterListView and the BatteryCodeView.

The currentItem method uses the itemListIndex to return either nil or the current battery item itself. The currentItemList is constructed by asking each battery item in our item list to ask its parameter object for an item name. These names are collected and returned as the current item list.

The currentParameterKeyList method returns an OrderedCollection containing the keys for the current list of parameters. It derives this by calling the currentParameterList method. This method returns an empty AccessableDictionary if no item is currently selected. If an item is selected, we fetch its parameter object (which is an AccessableObject) and turn this into an AccessableDictionary, which we then return.)

The currentParameterValue method uses the key list to index the parameter list which in turn allows us access to a parameter value.

class BatteryBrowser class

superclass StringHolder class

class name ItemListView

superclass ListView

category Interface-Battery

Object

View

ListView

ItemListView

class name ParameterListView

superclass ListView

category Interface-Battery

Object

View

ListView

ParameterListView

class name BatteryView

superclass StandardSystemView

category Interface-Battery

Object

View

StandardSystemView

BatteryView

class BatteryView class

superclass StandardSystemView class

class name BatteryCodeView

superclass StringHolderView

category Interface-Battery

Object

View

StringHolderView

BatteryCodeView

class name WaveformView

superclass View

dataWindow

dataBox

dataTransformation

dataInsets

graphBox

length

interval

thickness

topMargin

bottomMargin

leftMargin

rightMargin

quill

title

titleEmphasis

lastPosition

category Interface-Battery

Object

View

WaveformView

The clear method fills our inset display box with our insideColor. The displayAbscissa method draws an X axis.

The displayData method plots our model (a Waveform).

The displayOrdinate method draws our Y axis.

The displayTitle method draws our title.

The displayView method is the standard method for drawing a view. It resets our variables, clears us, and draws our components.

The displayXTick: and displayYTick: methods are used for tick mark generation.

The resetVariables method resets the reference boxes that we use to draw a waveform graph.