The Benefits of Object-Oriented Application Development Using the SAS System Randy Pierce, SAS Institute Inc., Cary, NC. Labeled Sections.

Transcription

1 The Benefits f Object-Oriented Applicatin Develpment Using the SAS System Randy Pierce, SAS Institute Inc., Cary, NC Presented by Thmas Emmerich, SAS Institute ABSTRACT The SAS System can nw take full advantage f the bject-riented (00) paradigm. There are vlumes f materials describing the benefits f bject-riented prgramming in general. There are als manuals describing hw t write 00 applicatins with SAS sftware. This paper describes why yu may want t use 00 techniques when writing applicatins based n SAS sftware. Object-riented prgramming (OOP) is a refinement f mdular prgramming. SAS Institute has prvided 00 cnstructs that build upn existing mdular prgramming techniques available t Screen Cntrl language (SCl) prgrammers. As a result. well-written mdular SCl prgrams are but a step away frm becming classes in a.class hierarchy. A class hierarchy can act as a set f generic tls that can be applied t virtually any applicatin. INTRODUCTION Yu d nt need a thrugh grunding in bject-riented prgramming In rder t understand this paper. On the cntrary. yu will see hw easy it is t cnvert a mdular applicatin based n the SAS System t an 00 applicatin. The prcess f cnverting an applicatin can itself enhance yur understanding f this new paradigm and hw it applies t applicatin develpment with the SAS System. It is expected that yu are familiar with the SAS System and have been expsed t SCL. Object-riented prgramming is based upn mdular prgramming. Mdular prgramming is the prcess f breaking apart cmplex prgrams and then rganizing the resulting smaller, simpler prgrams. The fllwing sectins address the ptential drawbacks as well as the advantages f fur ways t use mdular prgramming with SCL. allws yu t keep (and thus maintain) cmmnly used cde segments in nly ne lcatin regardless f the number f times thse segments are executed. Since mdular prgramming invlves writing each cmmnly used cde segment nly nce, yu must first identify frequently executed cde segments. While examining the first prgram in the HRS, yu ntice several ccurrences f cde designed t transfer an emplyee frm ne department t anther. Each ccurrence prints a warning message if the user attempts t transfer an emplyee int the department t which they already belng. Otherwise, the new department value is assigned t the emplyee. These cde segments might lk like this: if dept = newdept then put 'WARNING:... '; Discvering similar cde segments is Just the first step. Nw yu must decide hw t implement these segments as a single segment that can be called when needed. A cde segment designed t be called frm ther prgrams is called a mdule. Mdular prgramming centers arund creating and managing mdules. T see why the 00 apprach is the best way t implement these mdules, examine the fllwing traditinal altemative appraches and their limitatins. Labeled Sectins Since yu fund these lines repeated in a single prgram, yu can eliminate all but ne ccurrence f this cde segment by implementing the mdule as a labeled sectin. A labeled sectin can be executed with the SCl LINK statement. If the mdule were implemented as a labeled sectin, it might lk like this: IMPLEMENTING MODULES This paper uses a simple human resurce system (HRS) as an example f a mdular applicatin. The prgrams in questin manipulate recrds describing emplyees f a cmpany. Each emplyee recrd has a value fr these five variables: NAME DEPT STARTDTE STOPDTE ADR the name f the emplyee. the department t which the emplyee is assigned. the date the emplyee begins wrking fr the cmpany. the date the emplyee stps wrking fr the cmpany. the electrnic mail address f the emplyee. Suppse sme SCl prgrams in the HRS becme very difficult t maintain. It is imperative t minimize the maintenance csts fr an applicatin since mst applicatins are in a maintenance phase lnger than they are in any ther phase f the develpment cycle. In an attempt t make the HRS easier t maintain, yu may decide t use mdular prgramming. Mdular prgramming transfer: if dept = newdept then put 'WARNING:... '; return; If the 'transfer' mdule were implemented as a labeled sectin, it culd be invked with a line like this: I link transfer; labeled sectins are ideal when wrking with ne prgram. They can help segment a given prgram and divide it int smaller, simpler pieces. Hwever. a labeled segment can nly be executed within the prgram where it is defined. If yu find ther prgrams in the HRS which need t transfer emplyees, yu will have t create a labeled sectin in thse prgrams. All f the 'transfer' mdules will be nearly identical, and prbably need t be keep synchrnized. Thus, labeled sectins give yu the pwer t write a mdule nce per prgram, but they d nt give yu the pwer t write a mdule nce per applicatin. In rder t further I 501

2 :~ ease yur maintenance chres, yu need t find a technique that allws many different prgrams t share a cmmn mdule. Macrs A traditinal SAS prgrammer knws exactly what t d when writing mdular cde: use macrs. Macrs have lng been used t Implement DATA step and PROC step mdules. Any base SAS prgram can call a macr nce it has been defined. SCl prgrams can use this same technique. If the mdule were implemented as a macr, it might lk like this: %macr transfer(dept.newdept); if &dept = &newdept then put 'WARNING:... ; &dept = &newdept; %mend transfer; ccurrences f a mdule (ne each prgram which needs t execute that mdule) fr a Single less easily maintained ccurrence. The single macr implementatin will need additinal Infrmatin Indicating which prgrams shuld be cmpiled when the macr Is updated. Further, the statements in the macr will prbably be mre difficult t read than the statements in the riginal SCl cde. Yu can significantly reduce yur maintenance chres by keeping the implementatin f a mdule simple yet allwing many prgrams t execute that implementatin. SCl Entries Implementing each mdule in its wn SCl prgram has becme very ppular. Since each SCl prgram has its wn set f variables (and cannt affect variables In ther SCl prgrams), there is n need fr calling prgrams t rely n hw called prgrams wrk r which variables they use. Instead, use the ENTRY statement t pass the values f variables frm ne SCl prgram t anther. If the mdule were implemented as an SCl entry, it might lk like this: '.j If the 'transfer' mdule were implemented as a macr, It culd be called with a line like this: %transfer(dept. newdept); Nte that the macr actually lks mre cmplicated than the riginal cde. Opting t Implement mdules as macrs tends t lead t ampersands, percent signs, and varius quting prblems. One f the bjectives is t make already-cmplex cde easier t read and understand. Nte that the implementatin did nt have t be s cnvluted. Yu culd eliminate sme f these special characters (percent signs and ampersands) if the macr always used the same SCl variables when called. Fr example, yu culd have insisted the macr use the SCl variables DEPT and NEWDEPT. But frcing calling prgrams t knw hw a macr wrks and t use specific variable names fr specific purpses makes the macr mre difficult t use. Wrse yet, if tw macrs use the same SCl variable name fr tw different purpses, they becme virtually impssible t call frm the same SCl prgram. T help slve these variable name prblems, the macr shwn actually receives the names f all SCl variables that it can use. Hwever, slving the name scpe prblem made the cde mre difficult t read and understand. There is a secnd ptential prblem when using macrs t implement mdules. Since SCl is cmplied (rather than interpreted like the SAS language), each and every SCl prgram that calls a macr must be recmpiled whenever that macr is updated. Keeping track f which prgrams need t be cmpiled when a given macr is edited can cause lgistical prblems. A third, althugh mre technical, prblem Is that Implementing mdules as macrs des nt reduce the size f the cmpiled SCl cde. When an SCl prgram references a macr, the lines generated by that macr are included t the cmpiled cde as if thse lines existed at that lcatin in the prgram. If a cmplex prgram Is grwing s large that It is in danger f exceeding the size limit Impsed by SCl, macrs will be f little use in breaking apart the prgram. Macrs prve t be a better way t Implement a mdule than labeled sectins since yu nly need t write the mdule nce. A mdule implemented as a macr can be used by many different prgrams. Hwever, yu trade several easy t maintain I entry dept newdept $5; init: if dept = newdept then put 'WARNING:... ; return; If the 'transfer' mdule were implemented as an SCl entry, it culd be called with a line like this: call display( lib.cat.transfer.scl.curdept. newdept) ; The example call assumes that the SCl entry is named TRANSFER and is stred in a catalg named CAT in a library currently accessed by the lib ref LIB. In fact, calls t any mdule Implemented as an SCl entry require the calling prgram t knw where that SCl entry was stred in additin t its name. Nte als that the mdule name must be a valid catalg entry name. The cde cmprising the mdule is, again, simple SCl cde, vid f unnecessary ampersands and percent signs. Updating this mdule n lnger requires yu t cmpile prgrams that use this mdule. Instead, nly the SCl entry used t implement the mdule needs t be cmpiled if the lines f cde fr this mdule are updated. Nte als that any prgram in the HRS can call this implementatin f the mdule. While this technique des cmbine the advantages f bth the labeled sectin and the macr appraches, it still has sme drawbacks. The majr disadvantages f this technique apply equally well t ur last ptin, s We will delay discussin f them until ur final ptin is presented. Minr disadvantages t implementing mdules as SCl entries stem frm the islatin f each mdule In its wn catalg entry. Since each mdule is in a separate catalg entry, each mdule name must be unique amng all mdules stred In the same catalg. Yu can pt t give different mdules the same name nly If thse mdules are stred In different catalgs. Fr example, we can nly have ne TRANSFER.SCl entry per catalg. i 502

3 Suppse there were a mdule designed t mve funds frm ne accunt t anther. The mdule written t mve funds wuld either have t be named smething ther than TRANSFER r stred in a catalg ther than the ne string the TRANSFER methd written fr emplyees. A naming cnventin culd clarify the purpse f the methds, but at a cst. If yu use a naming cnventin, yu quickly lse the ability t give mdules descriptive names. Fr example, EMPTRANS and FUNDTRANS culd bth be stred in the same catalg. Mre ften, hwever, develpers use the catalg name t clarify the purpse f the mdules. Yu culd have tw SCL entries named TRANSFER if ne were stred in a catalg named EMPLOYEE and the ther were stred in a catalg named FUNDS. If yu pt t use multiple catalgs, yu may find yurself pndering the lcatin f a versin f TRANSFER yu need t call. There is anther minr prblem assciated with implementing mdules as individual SCL entries. If tw mdules cntain similar lines f cde, yu need a third SCL entry that bth mdules culd call. If yu extraplate this idea, yu can see hw easy it is t have ne SCL entry call anther which calls anther which calls anther and s n. The prliferatin f SCL entries can make the applicatin appear mre cmplex than it needs t, and the repeated calls t SCL entries can impede the applicatin's perfrmance. Using an SCL entry t implement a mdule can greatly reduce yur maintenance csts. Yu n lnger need t keep careful track f the prgrams which execute this mdule as yu d with the macr apprach. Yet the implementatin f the mdule is as simple as it was with the labeled sectin apprach. Hwever, the varius naming cnventins which tend t surrund this technique are themselves trublesme. Yu culd further reduce yur maintenance tasks if yu culd give each mdule a mre meaningful name and grup related mdules tgether. Methds Yu can implement a mdule as a methd nearly the same as yu wuld implement it as an SCL entry. In fact, the cde actually resides in an SCL entry, but there are a few syntax changes. Each mdule has a descriptive label uses the SCL METHOD statement t declare its wn parameters and starting pint uses the SCL ENDMETHOD statement t declare its wn ending pint. If the mdule were implemented as a methd, it might lk like this: transfer: methd dept newdept $5; if dept = newdept then put 'WARNING:... '; endmethd; If the 'transfer' mdule were implemented as a methd, it culd be called with a line like this: call methd('tls.master.emplyee.scl', 'TRANSFER',dept,newdept); The invcatin f a methd cntains the name f the SCL entry. cntaining the methd, the lcatin f that SCL entry, and the name f the labeled sectin t execute. A significant benefit t using the methd apprach rather than the SCL entry apprach is that yu gain an extra naming level. Rather than label the cde 'init', 'main', r 'term' as yu wuld when using SCL entries t implement a mdule, yu can nw use a mre descriptive label. Further, each mdule name need nly be unique amng ther mdules stred in the same SCL entry. The ability t stre multiple mdules in a single catalg entry leads yu t grup related cde segments tgether. As a result, fewer catalgs are required. Fr example, a FUNDS.SCL entry cntaining methds named TRANSFER and INVEST, might reside in the same catalg as the EMPLOYEE.SCL entry cntaining methds named TRANSFER and RENAME. Gruping mdules tgether has anther benefit as well. Mdules that have been stred in a single SCL entry can link t labeled sectins in that SCL entry. Thus, related mdules can share cmmn cde withut having t call yet anther SCL entry. Fr example, suppse the TRANSFER and RENAME mdules f the HRS shared a few lines f cde. If these mdules were implemented as methds in a single SCL entry, they culd simply link t cmmn lines f cde. At this pint, the maintenance chres f writing and maintaining the mdules has be reduced nearly as far as is pssible. Each mdule is implemented nly nce, yet can be executed frm any prgram. The implementatin f the mdule is as simple as the riginal SCL cde. Each mdule can be given a fairly descriptive name. Related mdules can be gruped tgether t facilitate sharing cde they might have in cmmn. Hwever, we have nt cnsidered hw easy it is t use a mdule implemented with any f the described appraches. Reducing the maintenance required when updating the mdules is nly half the prblem. Yu shuld als cnsider ways t make mdules easy t use. Cmparisn f Techniques T summarize the implementatin ptins fr mdular prgramming with SCL: Labeled Sectins are better than ne large prgram can reduce the size f anyne prgram can nly be used by the prgram in which they are defined. Macrs are better than labeled sectins can be used by mre than ne prgram have a very high maintenance cst d nt reduce the size f prgrams that call them. SCL Entries are better than macrs reduce the size f the riginal prgram are easier t maintain than macrs can lead t naming cnventins r mdules scattered ver several catalgs. Methds are better than SCL entries allw yu greater flexibility fr naming the mdule allw yu t grup related mdules tgether. 503

4 Implementing mdules as methds appears t be the ptimal way t write mdular cde with SCL. Hwever, mdular prgramming has sme limitatins that are present in all implementatins. Object-riented cde vercmes many f these limitatins. The fllwing sectins shw hw simple it is t cnvert mdular SCL prgrams int 00 nes. Yu will als see hw great the retum is fr such a small mdificatin. USING METHODS This prtin f the paper assumes that yu have practiced mdular prgramming. The tw mst viable appraches fr implementing SCL mdules are the SCL entry and methd appraches. Weeknesses discussed in this prtin f the paper apply t bth implementatins. Examples, hwever, are shwn using the methd implementatin apprach. Further, the paper assumes yu have already written the fllwing methds: RENAME TRANSFER HIRE t change the name f an emplyee. t change the department t which the emplyee is assigned. t assign the STARTDTE. t a message t the emplyee. The fllwing sectins shw hw this mdular Implementatin might be used. In the prcess, yu can nte prblems that are addressed with the 00 apprach. Parameters When yu call a methd, yu need t pass it all f the values that it requires. Fr example, the TRANSFER methd undubtedly needs the new department value. But the TRANSFER mdule already shwn als requires the current department value. Suppse the TRANSFER methd were enhanced t ensure the emplyee is currently emplyed at the cmpany. In that case, it needs the STOPDTE and STARTDTE values. If the TRANSFER methd autmatically sends the emplyee ntifying them f the transfer, it needs the address as well. In practice, many methds make use f nearly all attributes f the piece f data they manipulate. TRANSFER uses mst f the attributes fr EMPLOYEE, including the frwarding f ADR t the methd.taliwfrfutureenhancements.itis usually gd practice t pass all attributes f a piece f data t all methds that manipulate that type f data. In this case, we need t pass NAME, DEPT, STARTDTE, STOPDTE, and ADR t all methds in EMPLOYEE.SCL. There are at least tw appraches fr passing these parameters t each methd. The first and mst bvius apprach is t place these parameters n the METHOD statement fr each methd. The TRANSFER methd wuld lk smething like this: transfer: methd name $40 dept $5 startdte stpdte 8 adr $20 newdept $5; endmethd; Repeating a similar statement fr each methd can cause tremendus maintenance prblems. If the length f an attribute changes, r if additinal attributes are adcled, numerus lines f cde will be affected. Listing the parameters als requires calling prgrams t pass the right values in the right rder. N errrs wuld be generated at cmpile time if a prgram calling a mdule has tw parameters ut f rder, but executing the call wuld certainly nt perfrm as Intended. A slightly better apprach is t pass a list f attributes t each methd. In this case, the entire list f attributes is passed with a single variable: the list Identifier. Methds can retrieve values frm the list by name and can frward the list f values t ther methds as well. A versin f the transfer methd using this technique, wuld lk smething like this: transfer: methd emplyee 8 newdept $5; dept = getnitemc(emplyee, 'DEPT'); startdte = getnitemn (emplyee, 'STARTDTE'); rc = setnitemn(emplyee, newdept, 'DEPT') endmethd; Hwever, this apprach requires the methds t pull values ut f the list befre they can be used, and It requires the calling cde t insert values int a list befre calling the methd. Likewise, the methd must assign new values t named items in the list if it is t affect the values f attributes fr the emplyee. Depending n the cmplexity f the methd, yur cde may spend mre time manipulating the list f values than the values themselves. It wuld be nice if all methds in EMPLOYEE.SCL culd autmatically have at their dispsal the values fr all attributes f an emplyee. If this were possible, the methds culd be simplified t the pint f nly receiving values nt assigned t attributes f an emplyee. In ther wrds, we wuld like t be able t write the TRANSFER methd like this: transfer: methd newdept $5; if (dept = newdept) r (date() > stpdte) then put 'WARNING:... '; endmethd; Nte that this Implementatin nly receives the new department value. The current values fr all attributes f the emplyee are assumed t be available in SCL variables f the same names. Nte als that this methd affects the value f the attribute DEPT by simply assigning a value t the SCL variable f the same name. The 00 apprach makes passing attributes nearly effrtless, as described later in this paper. Generic Prgrams As we have seen, an EMPLOYEE has a NAME attribute and a RENAME methd exists t assign a new value as an emplyee's name. But many ther types f data may have a NAME attribute (and thus their wn RENAME methd). Suppse yu want t write ne Interface that will allw the user t rename any type f data. Imagine a screen that prmpts the user fr a new name. When the user enters a new name, the screen shuld Invke the RENAME methd. But which RENAME methd? Keep in mind that invking a methd requires knwing bth the name f the methd and the name f the SCL entry cntaining that methd. What wuld the cde lk like? 504

5 The cde will prbably need sme srt f IF-THEN lgic t ensure the right methd is called. The name f the SCL entry cntaining the RENAME methd depends upn the type f data being renamed. If yu can smehw derive the data type, the cde might lk like this: select(datatype}; when (, EMPLOYEE' ) call rnethd('tools.master.employee', 'RENAME',newnarne}; when ( 'FILE') call rnethd('tools.tools.file', 'RENAME',newnarne}; when ( 'CATALOG' ) call rnethd('misc.master.catalog', 'RENAME',newnarne); therwise put 'ERROR:... '; end; If the implementatin were similar t the ne shwn, then it wuld have t be updated each and every time a new data type were added. It wuld als have t be updated if the SCL entry cntaining the RENAME methd fr a given data type were mved r was itself renamed. Fllwing strict naming guidelines wuld help reduce this prblem. If the SCL entries were always named the same as the data type and they were all stred in the catalg named TOOLS.MASTER, then the invcatin f the RENAME methd wuld be as simple as USING CLASSES The EMPLOYEE data type as previusly discussed in this paper indicates that bth writing and calling mdules culd be much easier if every data type knew bth its attributes and its mdules. If data types knew their attributes, these values culd be passed autmatically t their mdules. If data types knew the lcatins f their mdules, generic cde culd invke a mdule by its name alne. SAS has pted t stre the mdule name and lcatin infrmatin in an SCL list. The mdule names are the names f list items and the mdule lcatins are the values f thse list items. String mdule lcatins as named items in a list gives yu much mre freedm fr naming yur mdules. Nte that the name f the labeled sectin cntaining the mdule is cnsidered t be a prtin f that mdule's lcatin, rather than its name. Fr example, the labeled sectin implementing a mdule t send an emplyee t SUGI might be named SUGI, but the name f a list item (and thus the name f the mdule) pinting t that labeled sectin culd be SEND_ TO_SUGI. Thus, mdule names n lnger need t be valid catalg entry names (as with the SCL entry apprach) r label names (as with the methd apprach). A table f mdule names and lcatins might lk like NAME TRANSFER HIRE LOCATION EMPLOYEE:TRANSFER EMPLOYEE:HIRE call rnethd('tools.master.' 'RENAME',newnarne}; I I datatype, RENAME EMPLOYEE:RENAME EMPLOYEE: The real questin is hw the value fr OAT A TYPE is determined. If yu claim that that value was passed t the interface as a parameter, yu have nt answered the questin. Hw did the calling cde determine DATATYPE? It wuld be cnvenient if n cde had t use the value DATATYPE directly. Yu wuld prbably like t ask a piece f data t rename itself and nt have t wrry abut its data type, the lcatin f the apprpriate RENAME methd, r anything. Suppse an entire piece f data (an emplyee, fr example) can be assigned t ne variable. It wuld be nice t ask that variable t RENAME itself withut having t use any additinal infrmatin. Suppse the data t be renamed were assigned t a variable named DATA. The SCL behind the generic RENAME interface wuld be as simple as call methd(data,'rename',newnarne); The 00 apprach makes writing generic cde this easy. It allws fr a DATA variable that nt nly knws the values fr all f its attributes, but als knws its data type. Because the DATA variable knws its data type, it can use that infrmatin t determine the lcatin f apprpriate methds. We can nw see hw the 00 apprach has vercme prblems assciated with even the mst rbust implementatin f mdular prgramming. I SEND_ TO_SUGI EMPLOYEE:'3UGI Here, the lcatin is shwn as the name f an SCL entry fllwed by a cln and the name f a labeled sectin in that SCL entry. The names f the librefs and catalgs cntaining the SCL entries are mitted due t space cnstraints, but these SCL entries could have different names r reside in different catalgs. A stred list cntaining bth the list f attributes and the list f mdules is called a class. In SAS, such a list is saved in a CLASS catalg entry. Nte that a CLASS cntains infrmatin abut a data type, but it des nt cntain infrmatin abut anyne member f the data type. Fr example, the EMPLOYEE class defines that members f that class have a name, department, address and s n. But the emplyee class des nt define the name, department, r address fr ne particular emplyee. The 00 apprach des allw fr a list cntaining values fr ne emplyee. A list representing an ccurrence f a data type is called an instance. Each instance has a value fr every attribute its data type has. Fr example, an instance f the EMPLOYEE class has a value fr NAME, DEPT, STARTDTE, STOPDTE, and ADR. Instances must als be able t access the class describing their data type. SAS has chsen t implement instances with SCL lists. The list cntains named items. The name f each item is the name f an attribute, and the value f each item is the value f that attribute. There is an additinal item named _CLASS_ in the list whse value is the class t which the instance belngs. An instance f 505

6 the emplyee class might lk smething like this: NAME NAME DEPT STARTDTE STOPDTE ADR _CLASS_ 00 Messages VALUE Oscar Oliver Peters MIS 15MAY91 TOOLS.MASTER.EMPLOYEE.CLASS Using instances and classes can reduce sme f the prblems assciated with mdular prgramming. In particular, it is easier t pass parameters and write generic prgrams when using the 00 apprach. T execute a mdule in OOP, send a message t an instance. The name f the message is the same as the name f the mdule yu wish t execute. But because the message is sent t an instance, the language immediately knws all f the attributes that shuld be passed as parameters and the lcatin f the mdule being called. Suppse Oscar (the emplyee previusly shwn) was abut t transfer frm MIS t Finance (FIN). Assume the SCL variable EMPLOYEE is the list identifier representing an instance f the EMPLOYEE class and currently hlds Oscar's infrmatin. T send a message t the instance EMPLOYEE, yu can use call send(emplyee,'transfer','fin'); Use the SCL call rutine SEND t send a message t an instance. In this case, the instance EMPLOYEE is sent the message TRANSFER. The value FIN is passed t the methd as a parameter. Since an invcatin f the SEND call rutine des nt cntain the lcatin f the methd t execute, SAS must determine its lcatin and what values will be autmatically passed t it. First, SAS must determine the class the instance belngs t. In this case, the EMPLOYEE belngs t the class TOOLS.MASTER.EMPLOYEE.CLASS. Then SAS must determine where the methd named TRANSFER used with the emplyee class is stred. In this case, the labeled sectin named TRANSFER in SCL entry named TOOLS.MASTER.EMPLOYEE.SCL will be executed. Nte that the call t the TRANSFER methd des nt cntain the lcatin f the mdule. In fact, It des nt always cntain the name f the labeled sectin used t implement the mdule. The mapping f the mdule name TRANSFER t the labeled sectin named TRANSFER in the SCL entry TOOLS.MASTER.EMPLOYEE is saved in the class definitin. 00 prgrammers use the term methd t indicate a pairing f mdule name and lcatin. A mdule need nt be implemented as an SCL methd t be used as a methd f a class. Fr example, TRANSFER, HIRE, RENAME and SEND_TO_SUGI are all methds f the EMPLOYEE class nt because f their impiementatin but because thse names have been paired with lcatins f mdules. Since the class is the nly thing referring t the lcatin f a methd, it is als the nly thing that must be changed if a methd is mved. Prgrams calling methds supply the methd name, but nt its lcatin. When an instance is sent a message, its class determines the lcatin f the methd. As a result, mving a mdule frm ne lcatin t anther n lnger requires yu t find and change all calls t that mdule. Fr example, mving the TRANSFER methd t anther SCL entry, catalg, r library wuld nt require yu t alter the CALL statement shwn abve. When using the 00 apprach, prgrammers can mit mre than just the lcatin f the methd they wish t execute. While the traditinal invcatin f a mdule requires explicitly passing it all values it uses, an 00 prgrammer need nly pass values that are nt assigned t attributes f the instance they wish t prcess. Values assigned t attributes f the instance t be prcessed will be autmatically made available t the mdule executed. Fr example, cnsider the CALL statement shwn abve. Befre the TRANSFER methd is executed, SAS assigns values t all SCL variables in its SCL entry whse names and types are the same as the names and types f attributes in the emplyee class. Thus, Oscar's name is assigned t the SCL variable NAME, his department is assigned t the SCL variable DEPT, his address is assigned t the SCL variable ADR, and s n. its imprtant t recgnize that each instance will pass its wn set f attribute values t methds when it is sent messages. This way different instances f a given class can represent different members f that class. Each instance must have attribute values that describe a particular member f the class t which it belngs. Since the values f attributes can differ frm ne instance t anther, 00 prgrammers refer t them as instance variables. Fr example, tw different instances f the EMPLOYEE class prbably have tw different values fr the instance variable NAME. Fr example, ne instance might have the value 'Oscar', while anther instance might have the value 'Juli.' The TRANSFER methd can use any instance variable f the emplyee class withut having t receive it as a parameter. Nte that when the methd has cmpleted, SAS autmatically sets the instance variable values t the values remaining in the like-named SCL variables. S the TRANSFER methd can assign a new value t Oscar's department by simply assigning a value t the SCL variable DEPT. Als nte hw easy it is t write generic prgrams with the 00 technique. The cde executed with the generic rename interface previusly discussed wuld be as Simple as this: I call send(instance,'rename',newname); SAS uses the definitin f the class t which INSTANCE belngs in determining the lcatin f the apprpriate RENAME methd and in determining what values shuld be passed autmatically t that methd. Thus, the data type f INSTANCE des nt need t be taken int accunt at the applicatin level. Instead, the language (in this case SCL), autmatically determines the data type f INSTANCE and executes the prper methd fr yu. 00 prgrammers use the term plymrphism t describe the ability t select a mdule based n mre than Just the mdule name. In OOP, plymrphism mst frequently invlves selecting a mdule based n bth a mdule name and an instance. In rder t fully utilize plymrphism, it is imprtant that classes use the same methd names fr similar prcesses. Fr example, the I 506

7 ~ : previusly shwn generic cde uses plymrphism t select the apprpriate mdule by supplying bth the name f the mdule, RENAME, and the instance t be renamed. This generic prgram, hwever, is useless unless all classes use the name RENAME fr mdules that assign new names t instances f themselves. Expliting 00 Techniques At this pint, we can see clear advantages t using instances and classes, and writing 00 prgrams. We have seen that methds need nt receive as many parameters as mdular prgramming. We have als seen that generic prgrams can be written and then used by many applicatins. We have als seen that it is much easier t maintain 00 cde since calls t mdules n lnger depend n knwing the lcatin f thse mdules. Hwever, we are still using mdular prgramming techniques. We have used OOP t help manage ur mdules, but we have nt altered ur fundamental design. In fact, we have nt yet mentined sme f the greatest strengths f the 00 paradigm. Well-managed mdular prgramming becmes 00 prgramming when yu begin t use inheritance and develp a class hierarchy. Class Hierarchies As we have seen, a class defines a data type in terms f bth instance variables and methds. Many times, tw r mre classes differ nly slightly. Fr example, suppse yu start a summer intern prgram fr cllege students. Student emplyees have all the attributes f ther emplyees (NAME, DEPT, and s n), but have an additinal attribute, SCHOOL, t indicate the cllege r university that student attends. Perhaps the student emplyee class als has a GRADUATE methd that cnverts a student emplyee int a regular emplyee. All methds and attributes pertaining t the EMPLOYEE class apply equally well t the STUDENT EMPLOYEE class. We wuld prefer t avid duplicating prtins f the EMPLOYEE class when defining the STUDENT EMPLOYEE class. If we cnsider the many pssible types f emplyees (STUDENT, PART-TIME, FULL-TIME, CONTRACT, TEMPORARY, and s n) then we can see hw difficult it wuld be t keep all f these classes synchrnized when a methd r attribute is added r changed fr the EMPLOYEE class. T vercme this prblem, the 00 apprach prvides a way fr ne class t reference anther class as its parent. A class will inherit bth the instance variables and methds defined in its parent class. The result is that any new class need nly define attributes and methds that are different frm the definitins cntained in its parent. The maintenance trubles alluded t with varius types f EMPLOYEE classes can be averted by using inheritance. Rather than trying t repeat the methds and attributes f the EMPLOYEE class in all f the mre specific classes, we can simply inherit them. Fr example, the STUDENT EMPLOYEE class need nly define the SCHOOL attribute and GRADUATE methd. Prvided the STUDENT EMPLOYEE class names the EMPLOYEE class as its parent, it will autmatically have all attributes and methds f the EMPLOYEE class. 00 prgrammers use the terms subclass and superclass t describe the parent-child relatinship mentined abve. One class is a subclass f anther if it names the ther class as its parent. The STUDENT EMPLOYEE class is a subclass f the EMPLOYEE class. Similarly, ne class is a superclass f anther if the ther class names it as its parent. The EMPLOYEE class is a superclass f the STUDENT EMPLOYEE class. The design and implementatin f a class hierarchy plays a critical rle in the success f an 00 system. The bjective is t create a hierarchy s generic and flexible that the majrity f the wrk required fr any applicatin has already been implemented in the frm f classes within the hierarchy. Develpers can spend their time cncentrating n the few classes that are unique t the new applicatin and have nt yet been implemented. If the class hierarchy is particularly rbust, the new classes can name existing classes as their parent and require relatively few new attributes and methds. A key advantage OOP has ver mdular prgramming is the ability fr ne applicatin t use mdules riginally designed fr specificatins in anther applicatin. Fr example, suppse ne applicatin requires the ability t print a file. In all prbability, the develper will create a FILE class if ne des nt exist and implement a PRINT methd if ne des nt exist. The PRINT methd fr the FILE class was created due t the needs f an applicatin under develpment. Hwever, future applicatins that might need t print files can take advantage f the newly available PRINT methd f the FILE class. Frequently, classes riginally required fr ne applicatin turn ut t be applicable t ther applicatins. When applicatins rely n cmmnly used generic classes, the distinctin between ne applicatin and anther blurs. Instead, the user is given many applicatins with similar interfaces that can cmmunicate with each ther thrugh the cmmn classes. Fr example, ne applicatin might use the FILE class t stre infrmatin, and anther applicatin might use the FILE class t retrieve infrmatin. These tw applicatins can effectively cmmunicate with each ther thrugh a generic class even if neither ne has direct knwledge f the ther. Additinal Advantages Mst f the advantages discussed s far were frm the prgrammer's perspective. There are quite a few advantages t OOP (hat pertain t the user. It is imprtant t realize that users need prgrams that can fulfill their requirements. Mst users d nt create their prgrams, but acquire them instead. If the purchased r develped applicatin is t be f any benefit t the user, they must accurately and precisely describe their requirements. Hwever, peple tend t distrt received infrmatin when they pass it t smene. The distrtin f a user's requirements is anther factr in the usefulness f the prgram acquired fr them. The number f transitins the requirements underg n their way t the finished prduct affects the extent t which they are distrted. Thus, even the mst precise and accurate requirements can lead t grssly inapprpriate applicatins if they change hands several times befre they becme statements in a prgram. Imagine a scenari where the user verbally describes sme requirements t an assistant wh writes them dwn. The written requirements are passed t a secretary that types them. The secretary passes the typed requirements t a prgram designer. The designer suggests sme data structure and prgram flw which are given t a senir prgrammer. The senir prgrammer develps a 'psud-cde' mdel and gives it t a language expert. The language expert writes sme 'cre' mdules and then lets an assistant write the rest f the prgram. Is it really difficult t understand why the cde written by the assistant prgrammer acts s differently frm the behavir described by the intended user? T help slve this prblem, it is imperative that the user be Invlved at each transitin f the requirements. Hwever, few 507

8 users can read a macr called by an SCl prgram and either cnfirm r deny that the prgram will meet their needs. The prgrammer necessarily separates the user frm the prgrams, but 00 techniques can narrw the gap between user requests and the resulting prgrams. Fr example, instances knw the class t which they belng and thus the methds t which they can respnd. Prgrammers use this fact t write generic cde. They can tell any Instance t RENAME itself, and the instance In questin will drive the apprpriate versin f the RENAME methd. Hwever, users can use this fact t get sme minimal help fr Instances. A user can ask any Instance t list the methds that are valid fr it and then execute a selected methd. There shuld prbably be sme filtering f methds presented t the user, but the fact remains that instances knw what they can d and shuld be able t prvide a list f valid ptins t the user. A user requesting the ability t terminate emplyees might als be cmfrted when they see the item TERMINATE appear in the list f actins that can be perfrmed. The emplyee in questin, hwever, might nt be s cmfrted I Anther advantage is that OOP Invlves classifying data. Each CLASS f data has its wn attributes and methds. The mre a class resembles a real-life classificatin, the easier it will be fr the user t interact with the system. It shuld make sense t a user that an Instance f the FilE class has methds named PRINT, EDIT, and MAIL. A similar advantage is that users can describe applicatin requirements in terms very similar t thse used by the prgrammer. Fr example, if the user requests that sme mechanism exist t terminate an EMPLOYEE, the prgrammer can simply implement a TERMINATE methd fr the EMPLOYEE class. Since the Implementatin f requirements mimics the user's descriptin f them, 00 cde can be easier t review. 00 cde can als be mre accurate since there are fewer translatins frm user specificatins t lines f cde. 00 prgrams center arund classes that clsely mimic a particular type f bjects In the real wrld. Since Instances f these classes are surfaced t the user, the user tends t want t manipulate them as they wuld the real-wrld bjects. Nte that the term instance identifies smething In the cmputer wrld, while the term bject identifies smething In the real wrld. These terms are frequently used as synnyms, but there are sme imprtant differences. An instance is used t represent an bject. Many times an bject (like the living, breathing emplyee named Oscar) exists bth befre and after the executin f a prgram, but an instance (like an instance f the EMPLOYEE class) can exist nly during the executin f a prgram. There is a further distinctin between Instances that represent stred data and thse that represent prtins f the Interface. A widget is an Instance f a class which the user can interact with directly. Mst widgets are visual and appear n screens presented t the user. Push buttns, scrll bars, and text entry fields are examples f widgets. When a widget is acted upn by a user, it generally sends ne r mre messages t an instance. Fr example, a scrll bar with values 0 thrugh 110 might send the message SET_AGE t an instance f the EMPLOYEE class when ever the user repsitins the slider. The user's desire t add widgets t the display, mve them, and select them has led t varius desk-tp-like Interfaces. A cmmn implementatin f this 00 envirnment Is an infinitely large plane n which tw-dimensinal shapes represent varius Objects. Display 1 Tw dimensinal view f bjects In the envirnment shwn In display 1, each shape/clr pair represents a different class. Fr example, yellw rectangles might represent emplyees, while blue ellipses might represent prjects. With the shwn envirnment, the text apprpriate fr each Instance Is placed n the shape representing that instance. Anther apprach is t give each class a unique icn and place apprpriate text centered beneath the icn. There might be sme merit t representing bjects as three-dimensinal shapes flating in space. One drawback t this apprach is the need fr apprpriate cntrls t enable the user t manipulate the bjects. A three dimensinal envirnment requires all f the tw dimensinal cntrls (like mve lefvright and mve up/dwn), but needs additinal cntrls t mve bjects twards the frnt r back as well as t tilt, twist, and rtate the Objects. Anther drawback Is the cmplexity f three-dimensinal bject manipulatin algrithms. Algrithms manipulating bjects in three dimensins generally requires mre pwerful hardware, less timely respnse, r less detailed images than d algrithms manipulating bjects In nly tw dimensins. Display 2 Three dimensinal view f bjects In the envirnment shwn in display 2, each plane (face f a cube, side f a tetrahedrn, and s n) can represent an bject. Thus a single cube can represent up t six different bjects, all ccupying rughly the same place n the display. BY'manipulating the cube, yu can see up t three f the six faces at nce. One mtivatin fr using a three dimensinal envirnment is that users Initially find it mre enjyable than a tw dimensinal ne. Anther mre substantial reasn Is that sme data simply lends itself well t three dimensinal representatin.,.',. 508

9 . 00 Terms This sectin f the paper is nt intended t be used as a glssary. It des nt cntain precise, widely accepted definitins. Instead, this sectin clarifies sme f the 00 buzzwrds yu may have heard and relates them t mdular prgramming as it is described in this paper. The terms are arranged in rder frm thse mst directly related t mdular prgramming t thse least directly related t mdular prgramming. METHOD: A pairing f a mdule name and lcatin. With SCL, mst mdules are implemented as SCL methds, but they can be implemented in ther ways. In 00 jargn, the term methd has little t d with implementatin f the mdule. Instead, it refers t the ability f a class t find a mdule when supplied with the name f a mdule. Methds eliminate the need fr calling prgrams t knw the lcatin f mdules, and thus calling cde need nt change even if mdules mve t ther lcatins. INSTANCE VARIABLE: An attribute pssessed by instances f a class. Instance variable values f ne class are autmatically passed t methds f that same class. NAME, DEPT, and ADR are examples f instance variables f the EMPLOYEE class. Prgrams calling methds d nt need t explicitly pass the values f instance variables, and thus d nt need t change even if instance variables are added, remved, r have their names changed. CLASS: A definitin f a type f data. It cntains at least three items: a list f methds, a list f instance variables, and the name f a parent class. A class is used in tw ways. It can either create an instance f r execute methds apprpriate fr the data type it represents. A class is assumed t have all instance variables defined in its parent. A class als acquires all methds in its parent that it des nt redefine. INHERITANCE: The receiving f definitins fund in anther class. Inheritance allws any given class t define nly thse instance variables and methds which have nt yet been defined in anther class. Instance vay;ables and methds which have already been defined in anther class can be inherited by a new class if the new class names the ther class as its parent. SUBCLASS: A class whse parent is the given class. Suppse that class A named class B as its parent. Class A is a SUBCLASS f class B. Since a subclass cntains all methds and instance variables f its parent, it can be used anywhere its parent can be used. Nte that any given class is a subclass f its parent, grand-parent, great grand-parent, and s n. SUPERCLASS: A class named as the parent f a given class. Suppse that class A named class B as its parent. Class B is the SUPERCLASS f class A. Nte that any given class is a superclass f its children, grand-children, great grand-children, and sn. CLASS HIERARCHY: A set f classes in which ne class is a superclass f all thers in the set. A class hierarchy is the crner stne f OOP. A gd class hierarchy cntains enugh generic classes t meet a large percentage f the requirements fr any applicatin. INSTANCE: An ccurrence f a class. An instance has a value fr all instance variables defined in its class. These values are passed autmatically t any methd that prcesses the instance. When a message is sent t an instance, it uses its class definitin t find the apprpriate mdule t execute. MESSAGE: An invcatin f a methd. When a message is passed t an instance, that instance uses its class t find the lcatin f the mdule named after the message. The named mdule is executed and autmatically receives all instance variable values. POLYMORPHISM: Selecting a mdule based n mre than just the mdule name. Mdular prgramming is nt plymrphic, since calls t mdules cntain nly the mdule name (the name f the labeled sectin, macr, SCL entry, methd, and s n). OOP is plymrphic since tw items are required when invking a mdule: the bject t be prcessed and the name f the mdule. Thus, tw different bjects f tw different classes can bth respnd t the same message, but they might execute different mdules. Fr example, the EMPLOYEE class and FUNDS class might rute a TRANSFER message t tw different mdules. Because f plymrphism, it is much easier t write generic cde with OOP than with mdular prgramming. OBJECT: A real-wrld item that a class is based upn. A class named EMPLOYEE might try t emulate emplyee bjects as they exist in reality. Generally, bjects exist lng befre and after instances representing them exist. Fr example, an emplyee f the cmpany exists even if there is currently n instance f the EMPLOYEE class whse instance variable values represent that emplyee bject. WIDGET: A visual bject in the user interface. Push buttns, list bxes, scrll bars, and windws are all examples f widgets. CONCLUSION Object-riented prgramming is a lgical extensin f mdular prgramming. 00 mdules are easier t maintain since they generally d nt have t declare as many parameters as their mdular cunterparts. 00 mdules are easier t use since calling prgrams d nt need t knw the lcatin f the mdules. Remving the need fr a calling prgram t knw the lcatin f a mdule makes writing generic tls much easier in 00 cde than in mdular cde. Gradually building a set f generic classes can make implementing an applicatin much easier than it wuld have been using the mdular apprach. Yu have much t gain if yur applicatins are bject riented. First, yu can becme mre clsely invlved with the implementatin f yur request (perhaps t the pint f brwsing the applicatin layer f cde) t ensure its accuracy. Secnd, the applicatin presents yu with a very familiar situatin. Yu can interact with the images n yur display as thugh yu were interacting with the physical bjects thse images represent. Mdular prgramming was, and still is, an effective technique fr building a simple applicatin that has little in cmmn with ther applicatins. If applicatins cntinue t becme mre cmplex and if the need fr applicatins t cmmunicate with each ther cntinues t increase, the need t use 00 techniques will als increase. REFERENCES SAS Institute, Inc. (1993), SASIAF Sftware: FRAME Entry, Usage and Reference, Versin 6, First Editin, Cary, NC: SAS Institute Inc. SAS Institute, Inc. (1993), Getting Started with the FRAME ENTRY: Develping Object-riented Applicatins, Versin 6, First Editin, Cary, NC: SAS Institute Inc. SAS is a registered trademark r trademark f SAS Institute Inc. in the USA and ther cuntries. indicates USA registratin. Other brand and prduct names are registered trademarks r trademarks f their respective cmpanies. 509