Designing Complex Systems Using SCL Data Objects

Andrew A. Norton, Trilogy Consulting Corporation, Kalamazoo, Michigan

INTRODUCTION Complexity: If you can change code easily. you can be"gin with a simple program and elaborate upon it in stages. This incremental development strategy is discussed further below. "Object-oriented ~ has become the buzzword of the moment. The recent marketing blitz has bleached it of all meaning, but Reuse: Reusing code in a different, unanticipated context the underlying concepts go back 25 years. Although these is a form of change. concepts developed incrementally from earlier software design principles, the end result is revolutionary -- once you have Transition from Analysis to Design: A well-established learned the new way of thinking, you can't go back. principle in software development is to separate analysis (determining what needs to be done) from design A complete object-oriented language is developing within the (determining how to do it). Object-oriented programming SAS* System. Many of the pieces are in place in releases 6.08 supports this principle by allowing design decisions to be and 6.10 of Screen Control Language (SCL). It is already postponed and revised. feasible to develop object-oriented systems in SAS just as yOll might in C++ or Smalltalk. This paper focuses on object~oriented strategies for managing change. Discussions of object-oriented programming in SAS often focus on small "toy" problems. Although this teChnique helps the Incremental Development novice to understand every aspect of the example, it gives a limited and artificial view of these powerful new features. This Traditional "waterfall" methodologies assume a predominantly paper is different. It focuses on how objects are used in one-way flow from analysis to design to implementation to constructing large-scale complex systems. I will not be testing. The analysis phase is completed before coding begins. spending much time discussing the nuts and bolts of how This requires committing to important decisions early, when you individual objects can be implemented in SAS. instead, I will have limited knowledge of their implications. be discussing what objects can do, and how they can be used in combination to tame complex and changing systems. Incremental development (Cockburn, 1995) strategies begin by developing a simplified prototype version. This prototype is Object-oriented programming is a natural progression from then incrementally enhanced based upon what has been learned traditional programming, so I will start there. Terms of special so far. This process can be repeated or "iterated" many times: significance are italicized the first time they appear. analyze-design-code-test, analyze-design-code-test.

Object-oriented programming is especially suited to incremental WHAT'S SO GREAT ABOUT OO? development (and vice-versa) because it is easy to make changes. Because the penalty for design mistakes is relatively small, you :

187 understand (Simon, 1981, page 219). This strategy for handling locate, revise, and test every use of the subroutine. This is a complex problems can be summed up by the phrase: disaster! Divide and Conquer. Suppose driver license policy changes: High school dropouts Subroutines are ineligible for a license until- age 18. The ELIGJBLE subroutine now requires another parameter HIGHSCHL The traditional way to "divide and conquer" computer programs (dropout status). Every program calling the ELIGIBLE has been through the use of subroutines (known in SAS as subroutine will need to be modified to read: "methods" and "macros".) Subroutines let applications share call method ('Driver' , 'eligible' , code. There is only one copy of the code to maintain, which age, drivtrn, highschl, ok); Some of the programs that call the ELIGffiLE program may ensures consistency, saves effort, improves quality, and themselves need to be modified to obtain the IDGHSCHL minimizes testing. infonnation. Subroutines also protect applications from changes in the Unfortunately, subroutine signatures often need to be modified subroutine code. When an application calls a subroutine, the to handle new siruations or make additional distinctions. If a two programs communicate through a limited and well-defined modified subroutine requires additional data, the signature will set of variables called parameters. need to be changed accordingly. Remember: Exposed data details lead to ripple effects. As long as the subroutine returns the correct output for the provided input data, then the details of implementation on either Luckily there is a solution, and this solution sets us on the path side (calling program or called subroutine) are irrelevant. What towards object-oriemed programming. the subroutine does (the external interface) has -been separated from how the subroutine works (the internal implementation). The Solution There is a natural division of responsibilities: the subroutine knows what to do with the input and the caller knows what to We need a way to pass additional information to a subroutine do with the results. without modifYing the signature. This can be done if a parameter contains a bundle of data rather than an individuat The use of subroutines simplifies testing because the behavior of variable. In some languages this can be done with a compound each subroutine is dependent upon its parameters alone and does data structure. In Screen Control Language, you can use an not change from one context to another. Similarly, maintenance SCL list (SAS Institute, 1991). If more data elements are becomes much easier: Once you have located and corrected the needed by the subroutine, just add them to the list. For appropriate subroutine, you are done. example, assuming an SCL list DRIVER! contains elements named SEX, AGE, and COUNTRY for a certain automobile In Screen Control Language, a typical subroutine call might be: driver, we could have: call method ('Oriver','eligible', age, drivtrn, ok); call method ('Driver','eligible', The first argument identifies the SCL entry containing the driver1, ok); method code: DRIVER.SCL. The second argument identifies No harm is done if the list includes additional information not the labeled block of code to be executed: ELIGIBLE .. The used by the subroutine. Because a variety of subroutines will remaining parameters (if any) are defmed by the programmer. need some data about drivers, we could maintain one list for In this case there are two input parameters, AGE and each driver containing all attributes of that driver. Such a list DRIVTRN (driver training status), and one output parameter could be used by any subroutine needing data about that driver: OK (eligibility for a driver's license). Because subroutines call method ('Driver' , Irenew', contain no persistent data, we know that the result OK is solely driver1, result); determined by the ELIGIBLE algorithm using the parameters AGE and DRIVTRN. The SeL lists for different drivers may contain different elements. The SCL list DRIVER1 might refer to a suspended This technology has been well-established for many years, and driver and contain different elements than SCL lists DRIVER2 you might not see any flaws with it until a bener way has been and DRIVER3 which refer to drivers with active licenses. described.

The Problem Encapsulation

If you write a really good subroutine, it might get used over and I have been emphasizing the importance of separating internal over again, in many different contexts. It might be used years implementations from external interfaces. Code is hidden within after you wrote it, or by people you have never met. This is a subroutine, and data parameters are hidden within a data list. success! Both are intimately related: Changes to data and code occur together. So instead of considering code to be the internals of The internal code of the subroutine can be changed without a subroutine, let's consider the internal contents of the data list causing difficulty for its client programs. But if the signature and the code of its associated subroutines to be part of the same Of form of the subroutine call changes, you might need to thing: an object. In a shift of perspective, instead of passing data parameters into a subroutine, a message is sent to an object

188 which contains b

Now we can discuss method code as part of the internals of an Inheritance features let you extend an existing class with new or object rather than standing on its owo. I mentioned before that modified methods. Classes are organized in a hierarchy of the data attributes (instance variables) contained within one superclass-subclass relationships: Methods added or changed in object could be different from another. In the same way, the the superclass are automatically inherited by any subclasses. code executed when a given message is received can differ from Inheritance lets classes share code in an orderly fashion. one object to another. For example, the ELIGffiLE method could execute entirely different code for automobile drivers If a subclass inherits from more than one superclass, this is from different states, even though the call looks the same. called multiple inheritance. Multiple inheritance is not supported by SAS, but can be simulated to some degree by In conventional programming, conditional progranuning in

As more variations are introduced, the SELECT statement must Let's review the object-oriented concepts in terms of their be further extended. Each time the code is modified there is the implementation in SAS. Objects are implemented as SCL lists chance of an error damaging the existing code, so the method containing data and a link to one class defmition. Each class must be retested. defmition maintains a list of supported methods with the location of the source'code corresponding to each method. Each class Object-oriented programming offers an alternative: different defInition (except for the root object SASHELP.FSP.OBJECT) implementations of a method for different objects. Because also contains a pointer to one parent class. If a method sent to changes to one implementation cannot damage other separate an instance of a class is undefmed for that class, the ancestors implementations, less code needs to be retested. 00 lets you of that class are searched until the method is found. extend the system (such as adding another value of STATE) without disturbing any previously tested code. During the execution of a method, the automatic SCL variable _SELF_points tothe target Object. This crucial feature is called polymorphism in object-oriented jargon. Polymorphism makes frameworks possible. SAS supports both Widget objects, which are displayed on Conventional subroutines are typically used as standard SAS/AF FRAME entries during interactive applications, and components -- standard structures that are used by applications data objects which function as non-display data structures. as generic building blocks. Frameworks are exactly the opposite -- standard structures that call application-specific modules to implement the details. For example, the SAS/AF® EXAMPLE: INTERACTIVE DATA EDITOR FRAME entry processor is a framework which executes the user-specified INIT, MAIN, and TERM labels. Object-oriented programming provides both framework and component Now let's look at an example currently under development at capabilities. Trilogy Consulting Corporation: an interactive data editor that identifies potential data problems and allows their co-rrection.

189 Traditional "data cleaning" programs require repeated "cleaning o Data User passes" to print edit reports .. Sometimes changes in response to o Reads Document Fields. these repons introduce or reveal additional-problems, so the o Reads Document Edits. process is repeated. Documents are not available for general use until all problems have been resolved. Scenario

The Interactive Data Editor (IDE), by contrast, maintains A typical scenario or sequence of events might be: continuous records of the status of each edit. It gives immediate feedback in response to a change, indicating which problems 1. Specification Writerdefmes Forms, Variables. and Edit have been resolved and which new problems have been Specifications. introduced. All documents are always available to everyone, with problems flagged. 2. Data Entry Clerk enters the Field data for each Document. Some basic terminology used in the IDE specifications: 3. Problem Resolver o Respondent: a source of information (typically a a. Locates Fields flagged in error. person or organization). b. Updates Field values, Overrides Field Flags, o Variable: a question to be asked of Respondents. Overrides Edits. c. repeats processes Sa and 5b. o Form: a set of Variables to be processed together. 4. Data User reads Field values (with Flags). o Document: an instance of a Fonn returned from a Respondent. OBJECT-ORIENTED ARCIllTECTURE o Field: an instance of a Variable, part of a Document.

o Edit Specification: a rule estimating whether a Field The futeractive Data Editor example will help us explore some or group of Fields is likely to contain a data error. of the common patterns of cooperation and interaction between objects. o Edit: the application of an Edit Specification to a Document. Document-centered Processing

o Edit Override: a manually~entered exception fu the early days of interactive applications, only one program specifying that the Edit does not apply in this instance. could be run at a time. The application would be opened first, and then the data to be processed would be identified. Only one o Flag: an attribute of a Field summarizing the overall set of data (e.g., word processing documents, charts, likelihood of a data error in that Field. based upon the spreadsheets) could be processed at a time. Later enhancements Edits associated with that Field. pennined two or more sets of data to be swapped or simultaneously processed. a Flag Override: A manually-entered exception forcing a particular Flag value. More advanced operating systems (such as Microsoft® Windows~ or OS/2~ from IDM") allow the user to select the o Constraint: a rule that always must be satisfied, data object first, and then choose an application from a context­ thereby limiting the updates that can be made. sensitive of applications appropriate for that data. The itself provides multitasking capabilities. so Actors each data object can be processed independently. Multitasking capabilities for SAS/AF are provided by the AFAPPLICATION Four classes of users or actors will use the IDE system: comntand (SAS Institute. 1991:4).

o Specification Writer To be compatible with this approach, the IDE design requires o Adds, deletes, and modifies Edit Specifications. each instance of the Document class to be able to open an interactive application (Viewer) with which users can view and o Data Entry Clerk edit the contents. o Enters Documents into the system. Client-8erver Relationships o Problem Resolver o Locates Fields with error Flags. Given a complex system to design, ohe of the first tasks is to o Updates data Fields. partition it into more manageable modules. Often, one module o Overrides Edits and Flags. (the server) can be interpreted as providing services to other o Checks updated results. modules (the clients). [Although the term "client-server" has

190 come to imply a particular hardware configuration, this need not object-oriented paradigm is intended for a world in which be the case.] The relationship is asymmetrical: the client computer power is much cheaper (and less vulnerable to error) module knows about and needs the server module, but the than human power; the advance of technology continues to server module is independent of the client module. move us in that direction. Object-oriented applications are organized into many small independent pieces, improving ease One of the first decisions made during the design of the IDE of comprehension. debugging. maintenance, and reuse at the was to separate the user interface Viewer which displays the potential cost of computer efficiency. Sometimes object­ data from the Document class which manages the data. Each oriented solutions are surprisingly efficient, but this is not the Viewer is a client of a Document which provides it with data primary goal. management services. This separation: Composition o allows the Document to function independently or serve other classes of clients, Objects may be composed of other objects by having one object contain pointers to other objects. This PART_OF relationship o allows Viewer specifications to be changed without differs from ordinary association relationships because certain disturbing the Document code, methods (such as Create, Delete, and Move) are transitively applied co all parts (sub-objects). o allows for future support of multiple or alternative Viewer components, and In the IDE example, Fields are part of Documents. This relationship generally is mirrored by a relationship between o eases maintenance, coding. and testing by partitioning Widgets and Frames in the user interface. Most communication a complex system into smaller simpler components. usually travels directly between a given Widget and the corresponding Field. But when the Widget is initialized, it The server module responds to requests by client modules. but obtains the address or object id of the appropriate Field by does not directly initiate communications with clients. Instead, asking the Document to locate a certain Field Name: servers are only responsible for broadcasting announcements of call send (Document, 'get_field' , server events to all subscribing clients. It is the client's fietdname, field object); responsibility to respond appropriately when a broadcast is The widget then remembers the object id returned by the received. parameter FIELD_OBJECT, for future reference.

Each class of objects in the system has assigned responsibilities. Frameworks The responsibilities of the different classes of human actors were described above. To carry out those responsibilities, a class Even though there are many different subclasses of Field may use or collaborate with other classes. In the case of the associated with many subclasses of edits, we can write a general Interactive Data Editor, the human actors fulfill their Update framework method thac can apply Co any Field. Changes responsibilities by collaborating with one or more Viewers. in overall policy should be made here: Viewers do not work with the data directly; rather, they fulfill their responsibilities by collaborating with their associated I) Validate Document. Validate update against any constraints. If the update Within the IDE, the following classes have been assigned the is invalid. return with error message. responsibilities noted: 2) Read o Viewer o Presents Field data (using Document). Read existing value. If new value is the same as the o Updates Fields (using Document). existing value, then return (no message). o Presents Field flags (using Document). o Overrides Edits (using Document) 3) Update o Locates flagged Fields (using Document). Update field. o Document o Reads Field data. 4) Propagate o Updates Fields. o Reads Field flags. Notify all objects depending upon this value (such as o Overrides Edits. Edic Flags) that the value has changed. o Locates flagged Fields. o Broadcasts notice of changes in the Document and For each subclass of Field, we must write implementations of its contents. the Validate, Read, Update, and ProNgate methods (or take the default). Changes in the behavior of a particular subclass should At this point you are probably thinking that this is a tremendous be made in the subclass methods. volume of messages to be passing back and forth. and it is. The

191 Delegation Similarly, if we want (0 be able to store and retrieve each object separately, we need to change embedded Every Document of the same Fonn shares the same editing object pointers into Object names, and change them specifications. Thus, it makes sense to manage the editing back to object pointers on. retrieval. This could be specifications as part of an Edit Specification object rather than done by defming a Store method for each object which for each Document separately. Responsibility for determining would store the target object and instruct each the Edit results for each document is delegated from the component object to store itself. A Library Manager Document to the Edit Specification. would determine whether an object has already been stored. Retrieval would work in an analogous manner. The Edit Specification object supports a method EVALUATE which requires a Document Object as an input parameter. The o Objects can serve as a wrapper around SAS data sets. result of the edit is a joint product of the Edit Specification and the Document which is being edited. The EVALUATE method Remember that the implementation of a method is obtains data from the specified document and then determines hidden within an encapsulated object. We have been the result of the edit. assuming that the data for each object is stored on the _SELF_list within that object. But we could construct In the driver's license example, the rules for determining the various methods so that they read and write from a eligibility are applied to data from individual drivers. but the SAS data set observation rather than from an SCL list. rules themselves only vary from one state to another. Thus, it If necessary, an object could be based upon makes sense to delegate the ELIGffiLE method from the observations from several data sets. DRNER object to a STATE_DRNER]OLICY class. This approach seems preferable for a Data Editor Lazy Computation because the data would be maintained in the form of a SAS data set which could be read by standard SAS Suppose we have a derived sum based upon 10 fields. When procedures. the fields are first entered, 10 different messages will instruct the derived sum to refresh itself, even though no one will read The availability of two strong alternatives suggests that we the derived sum until later. When I developed a similar data should isolate (that is, encapsulate) objects dependent upon this editor in 1986, elimination of these duplicate messages was a decision from the rest of the system, so the manner of data major source of difficulty. storage can easily be changed later. In the IDE, details of Document storage and retrieval are encapsulated within a Later I read an article by Rizwan Mithani (1994) which led me Document_Library class which checks-out and checks-in to realize that derived fields do not need to be recomputed until Document objects. there is a request to read the field. This is easily implemented using objects. The Refresh message sets an internal marker The Document Library class is also responsible for locating indicating that the value will need recomputing. When a Read desired documents based on criteria such as the ID of the request is received, the value is recomputed and stored, then the respondent. This is also how documents containing flagged marker is cleared. Subsequent Read requests simply retrieve the fields are located. stored value. Using this design, derived values are computed no more often than they need to be. One of the nicest features of object-oriented programming is that different components and frameworks can be independently Object Databases developed. For example. development of the Document Editor can begin without knowing how the data values will be Of course we would like to be able to save our Documents and pennanently stored. Object-oriented programming is ideal for continue processing on another day. Unfortunately. the SAS incremental development and iterative prototyping. System does not yet provide an Object DBMS. Nevertheless. there are two other ways to store and retrieve objects: Audit Trail

o Objects can be stored as SCL lists. An audit trail feature (a list of changes to values with a datetime stamp) is easy to implement because only one class of objects is SAS objects are implemented as SCL lists. These lists affected: Value. Whenever a value is updated, the previous can be stored as SLIST catalog entries, and later value is stored on a history list. A new method retrieved. GET_HISTORY_LIST is defmed to provide access to previous values. The tricky part is that each object is linked to its class defmition and possibly to other objects. If we want to The Value class (with audit trail) can then be modified to anow the class defmition to be modified while the respond to the Read method by returning the value as of any object is in storage, we need to separate the object specified date. This enables the entire_system to appear as it did from its class definition and reattach it when we on any date in the past simply by changing a virtual date setting. retrieve the Object. This could help the user understand actions taken in the past.

19~ CONCLUSION ANNOTATED BmLIOGRAPHY

Not all object-oriented systems are this complex. In fact, many are quite simple. If you -.have a relatively simple problem, I have found these references to be especially useful. The SAS object-oriented techniques can make it even easier to understand, bibliography emphasizes references which discuss SCL data debug, and maintain. If you have a difficult problem concerned objects rather than just SAS/AF Frame widgets. with complexity and change, then "00" could help you divide and conquer. Object-Oriented Analysis and Design

ENDNOTES Taylor, David A. (1990), Object-Oriented Technology: A Manager's Guide. Reading. MA: Addison-Wesley.

1. Screen Control Language can be executed in the batch mode This very concise book presents an accurate yet highly of SAS using PROC DISPLAY (Norton, 1991) or the readable overview of the basic principles of object-oriented DMSBATCH system option introduced in release 6.09 (SAS progranuning. I recommend it as the starting point for Instirute, 1993). anyone interested in the topic.

2. Between 1985 and 1988, I developed a similar data editor Taylor, David A. (1995), Business Engineering with Object as pan of the Integrated Post-secondary Education Data Technology. New York, NY: John Wiley and Sons. System (!PEDS) for the National Center for Education Statistics (NCES). This system was developed by Derek This exciting new book (a companion to the above) Drununond, Brenda Matthews, and myself while at ORI, examines the relationship between business engineering and Inc., using the Model 204 database management system. object-oriented software engineering. An excellent case study illustrates the use of my favorite object-oriented methodology, Responsibility-Driven Design. The book REFERENCES concludes with a thought-provoking analysis of the life cycle of object-oriented software.

Cockburn, Alistair A. R. (1995), "Unraveling incremental Wirfs-Brock. Rebecca, Brian Wilkerson and Lauren Wiener development," Object Magazine, Volume 4 Number 8 (January, (1990). Designing Object-Oriented Software. Englewood 1995), pages 49-51. Cliffs, NJ: Prentice Hall.

Mithani, Rizwan (1994), "Modeling databases with objects and This book is the original description of the Responsibility­ rules: a new dimension for distributed processing." Object Driven Design (RDD) methodology. RDD emphasizes the Magazine, Volume 3 Number 5 (January, 1994), page 59. allocation of responsibilities to classes and the defmition of client-server collaborations between classes. Norton, Andrew A. (1991), "Screen Control Language versus Macros in Batch Environments," pages 1325-1330 in Beck, Kent (1994), "Patterns and Software Development," Dr. Proceedings of the Sixteenth Annual SASC& Users Group Dobbs Journal, Volume 19 Number 2 (February, 1994), pages International Conference. Cary, NC: SAS Instirute, Inc. 18-21. Reprinted in SAS Instirute (1994), SAS®Macro Facility Tips and Techniques, Version 6, First Edition, pages 106-111. Cary, This article introduces the concept of "Patterns". a NC: SAS Instirute, Inc. systematic way of conununicating good practices from one programmer to another, inspired by the work of architect Peter, LaurenceJ. (1986), The Peter Pyramid. New York, NY: Christopher Alexander. William Morrow. Gamma, Erich. Richard Helm, Ralph Johnson, and John Simon, Herbert A. (1981), The Sciences ofthe Artificial, second Vlissides (1995). Design Patterns: Elements of Reusable edition. Cambridge, MA: The MIT Press. Object-Oriented Software. Reading, MA: Addison-Wesley.

SAS Instirute, Inc. (1991), SAS® Technical Report P-2I6, This handbook of solutions to common problems in object­ SASIAF® Software, SASIFSp® Software, and SAS'" Screen oriented design is the most useful computer book in my Control Language: Changes and Enhancements, Release 6.07. library. Twenty-three patterns of relationships between Cary, NC: SAS Instirute, Inc. objects are presented in a standardized format which discusses the problem addressed, a recommended solution, and the context in which the ·solution is appropriate. SAS Instirute, Inc. (1993), SAS ® Technical Report P-252, SAS® Software: Changes and Enhancements, Release 6.09, pages 2-3. Examples are in Smalltalk or C++ but for the most pan Cary, NC: SAS Instirute, Inc. are readily adaptable to SAS. _ The target audience is assumed to understand object-oriented fundamentals.

193 Object Magazine. SIGS Publications, New York. Pierce, Randy (1994), "The Benefits of Object-Oriented Application Development Using the SAS® System, ~ in SIGS publishes Object Magazine, Journal of Object­ Proceedings of the Nineteenth Annual SAS0 Users Group Oriented Progranuning, C++ Report, The Smalltalk International Conference. Cary, NC: SAS Institute, Inc. Report, and Report on Object Analysis and Design (ROAD). They are expensive and worth it. Object Covers essentially the same ground as the "What's So Great Magazine is the most general and accessible. About aD?" section of this paper. with an approach more explicitly connected to traditional SAS programming teChniques. fucludes a derailed glossary. Object~Oriented User Interfaces SAS Institute (1993), Building SCL Applications Using FRAME ffiM® Corporation (1992). Object-Oriented Inteljace Design: Entries Course Notes. Cary, NC: SAS Institute, Inc. IBM Common User Access Guidelines. Carmel. IN: Que. Although this book has little to say about user-defmed Conunon User Access (CUA) is ffiM's standard for user objects. it is indispensable as an orientation to SAS/ AF interfaces, as exemplified by OS/21Zl. Even if you aren't FRAME Entry progranuning. using OS/2, this book is valuable for the excellent discussion of object-oriented user interface design principles. ACKNOWLEDGEMENTS

Microsoft® Corporation (1992). The Windowsminteljace: An Application Design Guide. Redmond, WA: Microsoft Press. Thanks to Grant Blank, David Biesack, Sally GooSlrey, Tony Ettwein, Mark Olson, and Peter Lord for reviewing earlier If yOll want your SAS applications on Windows 3.1 to look drafts of this paper, and to Derek Drummond and Brenda like other Windows applications, this is the primary Matthews for their contributions to the design and development reference. of the !PEDS data editor_

SAS: Object-Oriented SCL NOTES

SAS Institute (1993), SASIAF® Software: FRAME Entry Usage and Reference, Version 6, First Edition. Cary, NC: SAS An earlier version of this paper was presented at the 1994 Institute, Inc. Midwest SAS Users Group conference.

Chapters 7 ("Creating Customized Classes and Methods"), SAS and SASI AF are registered trademarks of SAS Institute, 9 ("SCL Functions to Support Object-Oriented Inc. mM and OS/2 are registered trademarks of International Progranuning"), 10 ("The CLASS Entry"), and 14 ("The Business Machines Corporation. ~ indicates USA registration. Object Class") fOnD the primary reference for object­ oriented programming in Screen Control Language. Other brand and product names are registered trademarks or SAS Institute (1993), Getting Started with the FRAME Entry: trademarks of their respective companies. Developing Object-Oriented Applications. Version 6, First Edition. Cary 1 NC: SAS Institute, Inc. The author may be contacted at:

Chapters 5 ("Using Subclasses and Methods") and 6 Andrew A. Norton ("Communicating Between Objects") focus on widget Trilogy Consulting Corporation objects within SAS!AF FRAME entries. but also serve as 5148 Lovers Lane a useful supplement for the topic of SCL data objects. Kalamazoo, MI 49002 (616) 344-4100 voice Biesack, David J. (1993), "Objecl-Orienled User Interface (616) 344-6849 fax (OOGUl) Using FRAME Entries in SAS/AF® Software: Part Internet: [email protected] IV," pages 1404-1411 in Proceedings of the Eighteenth Annual SAS Users Group International Conference. Cary, NC: SAS Institute, Inc.

Source code for an appointment calendar application using two classes of data 'Objects (called "utility classes").

194