M. W9-“ t.“"‘—~M— o 0.. 9-0. -¢- ~Oo—o 4UP>WQ‘_ ~~W~ .— 7 - - “m...“«-’ “w“ _"'"'A-=““‘Y fi‘ v. w“ r,‘ USER ORIENIED FEATURES WITH IMPLICIT comm STRUCTURE roe A COMPUTER BASED INSTRUCTIONAL MANAGEMENT SYSTEM Thesis for the Degree of M. S. RICHARD GEORGE HANNON MICHIGAN STATE UNIVERSITY 1975 ' Jr) r 5. L. b, u."’ ~~“., ABSTRACT USER ORIENTED FEATURES WITH IMPLICIT CONTROL STRUCTURE FOR A COMPUTER BASED - INSTRUCTIONAL MANAGEMENT SYSTEM By Richard George Hannon The ASAG system was designed to generate student assignments, correct submitted solutions and maintain records that monitor the student's progress. Two of its primary objectives were to produce individualized assignments and remove much of the clerical burden from the instructor. This second objective was only partially met because of the relative difficulty of creating new assignment subprograms to be used with ASAG. To remedy this, ASAG/Anthor was developed. This program provided a simplified way for the instructor to write his assignment, yet remain ignorant of the specific linkage conventions required by ASAG. However, even with this addition, experience showed that the system was too difficult to use, and therefore, could not gain ‘wideSpread acceptance. The purpose of the research done in support of this thesis was to develop a method of integrating the several tasks involved with creating and maintaining ASAG assignments into a straightforward, user-oriented system. In doing this, the original ASAG/Author was expanded to allow ‘more flexibility in assignment creation; on-line documentation was added for user convenience; and a testing procedure was developed to facilitate the checkout of new assignments. A library fileamanager was also added for convenient maintenance of all existing assignments. Finally, these modules were integrated with linking control cards. In creating this system, each of the basic program.control structures (IF-THEN-ELSE, DO-WHILE and sequential statements) had to be implemented at the operating system comand language level. This thesis explains the reasons for the system's development, its overall organization, and the programming methodology for each subtask. Included as an appendix is the User's Guide to ASAG/Author. USER ORIENTED FEATURES WITH IMPLICIT CONTROL STRUCTURE FOR A COMPUTER BASED INSTRUCTIONAL MANAGEMENT SYSTEM BY Richard George Hannon A THESIS Submitted to Michigan State University in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE Department of Computer Science 1975 ACKNOWLEDGEMENTS I wish to acknowledge the efforts of my advisor, Dr. Leonard Weiner, Assistant Professor of Computer Science, and the members of my committee, Dr. Ronald Rosenberg, Professor of Mechanical Engineering, Dr. Richard Reid, Professor of Computer Science, and Dr. Allen Abedor, Assistant Director of the Educational Development Program. I also wish to acknowledge the efforts of Mrs. Marilyn Weiner for her help in the review and proofreading of this thesis, and my wife Sherri for her help in typing the final draft. 11 TABLE OF CONTENTS Abstract Acknowledgements . . . . . . . . . . . . . . . . . List of Figures . . . . . . . . . . . . . . . . . . 1.0 Introduction ; . . . . . . . . . . . . . . . 1.1 The Original System . . . . . . . . . . . 1.2 The Addition of ASAG/Author , . . . . . . 1.3 Additional Needs . . . . . . . . . . . . 11.0 Existing Shortcomings and Proposed Solutions 111.0 Organization of ASAG/Author . . . . . . . . . 111.1 EXEC Files . . . . . . . . . . . . . . 111.2 Flow of Control . . . . . . . . . . . . 111.2.1 Creation Run Flow . . . . . . . 111.2.2 Testing Run Flow . . . . . . . 111.2.3 Library Run Flow . . . . . . . 111.3 Control Card Structures . . . . . . . . 111.4 Organization of ABSOLUTEAA . . . . . . Iv.0 Programming Methodology . . . . . . . . . . . IV.1 Creation Run Program . . . . . . . . . . IV.1.1 Definition Divisions . . . . . . IV.1.2 Text and Solution Algorithm Divisions IV.2 Library Run Program. . . . . . . . . . . . . 1V.3 Testing Run Program . . . . . . . . . . v.0 Limitations and Suggestions for Future Work . V.l Non-Numerical Deficiencies . . . . . . . V.1.l The gig-£35 Construct . . . . V.l.2 TheggggConstruct . . . . . . . . V.l.3 The pigEDConstruct . . . . . . . . V.2 Correction Run . . . . . . . . . . . . . v.3 Implementation Deficiencies . . . . . . . v.4 Security Additions . . . . . . . . . . . v.5 Summary . . . . . . . . . . . . . . . . . V1.0 Conclusion . . . . . . . . . . . . . . . . . BibliOgraphy . . . . . . . . . . . . . . . . . . . Appendix A . . . . . . . . . . . . . . . . . . . . H-H- < H- \JUIUIJ-‘UNHH heed he’d WUWUUUNNHHHHHHH WNNNl-‘I-‘UIUIQNNNGUN 81131383 Uh? ~40 LIST OF FIGURES Figure l - ASAG/AUTHOR Control Card Flow . . . . . . . . . . . . Fig‘lre 2 - “AG/AWR EEC F1188 O O O O O O C O O O O O O O 0 Figure 3 A/A System Flowchart . . . . . . . . . . . . . . . . Figure 4 Overlay Structure and Subprogram Names of ABSOLUTEAA Figure 5 Assignment Parameters Division of Creation Run . . Figure 6 validity Checking Routine . . . . . . . . . . . Figure 7 Syntax Error Messages . . . . . . . . . . . . . Figure 8 Text Editor for Division 4 of Creation Run . . Figure 9 Library Run . . . . . . . . . . . . . . . . . . Figure 10 ASAGTESTER . . . . . . . . . . . . . . . . . . iv 14 16 18 20 21 22 26 29 1.0 Introduction ASAG, an Assignment Scheduler, Analyzer and Generator was originally developed in 1968 by L. Weiner at Northwestern University [5]. It was intended as a teaching aid which could bridge the gap between "graders" (i.e. programs that corrected student assignments) and traditional Computer Aided Instruction (CA1) techniques. In 1973 an author interface was designed for the ASAG system by W. Allaire at Michigan State University [1]. This extension.was necessitated by the relative difficulty of creating new assignments to be used with ASAG. However, the extended system was still not sufficiently user oriented for widespread use. The next logical step, then, was to further extend, modify and document Allaire's work. 1.1 The Original System The ASAG system is a complex computer program that generates individualized objective-type assignments for a class, compares the submitted answers with those expected and provides feedback help. Pro- gress-monitoring statistics are kept and new assignments are generated based on the students' past performance. ASAG, then, creates variations on an assignment, presumably authored by the instructor. Previously, the instructor would write a subroutine (called a BASIC) containing the particulars of that assignment and con- forming to specific ASAG requirements. The organization of a BASIC allows ASAG to generate and check that assignment on one of three increasing levels of difficulty. The level generated for each student is dependent upon his previous performance record. The students submit their solutions as computer input. Using the same BASIC, ASAG then checks each one for correctness, updating a variety of error counters in the process. The statistics gathered here provide feedback for both instructor and student. When a solution is deemed correct the next assignment is generated. Individual work is further encouraged by using random-valued assignment parameters. The major objectives of ASAG may be summarized as follows: A. Generate individualized assignments commensurate ‘with the student's ability, as indicated by his past performance. B. Thoroughly and impartially analyze the submitted assignments and maintain complete records of all activity. C. Provide progress feedback, and reenforcement help for the student's weaknesses. D. Provide the instructor with a variety of information to allow subsequent in-class activity to meet demonstrated class needs. E. Be reasonably inexpensive, easily modifiable and widely applicable to courses having objective-type assignments. ASAG was initially used in an introductory programming course at Northwestern. This first implementation.was considered a success, both from the students' and instructors' viewpoint. The second implementation was at Michigan State University, again in an introductory programming course. This time Dr. Weiner consulted for, but did not have direct control over, the course. The results showed that the students and instructors were not entirely satisfied with ASAG. The major reason for this attitudinal change was undoubtedly the fact that the course instructors, who were unfamiliar with the system, could not properly prepare the class for ASAG's operation. Also, because of the time required to enter their own programming assignments into the ASAG system, the instructors reluctantly used the existing assignment library and their frustrations were communicated to the students. 1.2 The Addition of ASAG/Agthor This second trial helped clarify two major weaknesses of ASAG: the instructor had to be very familiar with the system and, in order to use his own assignments, had to program and enter them into the system well in advance. Part of the problem could be resolved by thorough documentation, but, beyond this, there remained the involved and time consuming task of constructing class assignments. Each new assignment required the writing and debugging of a moderately complex subroutine (hereafter referred to as a BASIC) which had many specialized conventions and restrictions to enable it to interface properly with the rest of the system. Having to tackle such a formidable task would certainly help dissuade the instructor from using ASAG. It was decided, therefore, to add an "author mode" capability to ASAG whereby the instructor might interactively create BASICS, yet remain uninvolved with internal details of the system. The first version of ASAG/Author (A/A) was completed in 1973 by W. Allaire. It is a stand—alone program through which the instructor can create class assignments for the ASAG library. It produces as output a FORTRAN subroutine which, after being compiled, tested, and debugged, may be added to the system. ASAG/Author prompts the instructor for all information needed to create a BASIC. While the instructor, of course, must conform to the input conventions of A/A, these are not complicated and he can concentrate on the content of the assignment rather than the conventions of ASAG. 1.3 Additional Needs A/A suffered from some shortcomings, however. It lacked several desirable options and provided no on-line help for the user. Certainly, it suffered from lack of documentation. It was clear, then, that additional work was needed before ASAG could be widely used. The remainder of this thesis describes that work. Chapter 111 describes the organization of ASAG/Author at the system level. The control card structure of A/A is discussed, as is the theoretical implications and possibilities of such an organization. Chapter IV examines program methodology. Each major routine within A/A is discussed and diagrammed. Chapter V considers current limitations and possibilities for expansion. A User's Guide to ASAG/Author is included as Appendix A. 11.0 ’Existing Shortcomings and Proposed Solutions While A/A enabled the user to construct new BASICs without having to write FORTRAN subroutines, it limited his capacity to produce vari- ations of the basic assignment for the individual student. It was decided, therefore, to allow'him.greater variety in expressing the problem.statement and increased flexibility in algorithmic construction. Another weakness in A/A.was its inflexible input format and lack of on-line documentation. Perhaps the most frustrating example of the former was the user's inability to edit text or the solution algorithm. If he entered an erroneous line he had to abort the program, discarding the partially complete BASIC, and begin again. To improve his situation, editing commands had to be added to A/A to give the user freedom to manipulate previously entered lines. On-line documentation also had to be provided to allow appropriate explanatory messages to be output upon request. V Finally, since A/A's only function was to produce FORTRAN source code, it was still the user’s responsibility to test the BASICs and integrate them.into ASAG. These chores required the author to have some degree of expertise in using the local operating system and know the details of the ASAG/BASIC integration scheme. Such requirements greatly restricted the number of potential ASAG users. It was decided to include most of the testing and cataloging tasks within A/A itself. Accordingly,.A/A had to be expanded to include two entirely new’func- tions: a testing routine to allow thorough checkout of new BASICs, and a library routine to supervise the manipulation and maintenance of all existing BASICs. A/A also had to be expanded to include a set of structured control cards whereby BASICs might be created, compiled and tested'within a single run. .A somewhat separate task from the upgrading of A/A was to provide user documentation. .A user guide to ASAG/Author (Appendix A) was written to meet this need. 111.0 Organigation of ASAG/Author The original ASAG/Author was written as a stand-alone FORTRAN program designed for interactive execution. Much of this thesis work involved its upgrading and reorganization. The original program has been rewritten, expanded and, along with several new programs, struc- tured into overlays; The resulting A/A, then, is a system of programs (compiled under the FORTRAN Extended compiler) and linking control card files. Chapter IV will consider the design and strategy of the programs themselves; this chapter considers the organization of the new A/A system. 111.1 EXEC Files The CDC6500 operating system at MSU allows control cards to be executed from alternate input files using the EXEC command. This command may be issued by an EXEC control card or from a running program which uses the EXECM macro [4]. The A/A control structure utilizes both methods. The control cards governing A/A's execution sequence have been divided into eight files (called EXEC files). Their names are: ASAGAUTHOR LIBRUNEXECFILE BASICEXECFILE TESTRUNEXECFILE LOADERLOOPEXEC ASAGT ES TEREXEC WRAPUPBASICTEST ESCAPEFRGMTEST Within these control card files, programs are ATTACHed and executed; files are created, CATALOGed and/or RETURNed; field lengths are adjusted; etc. Figure 1 shows all possible transfer paths between files. Notice that it is possible for A/A to terminate following any of its eight EXEC files, though most of the indicated stops would constitute abnormal termination. The user initiates execution of A/A by EXECing the file ASAGAUTHOR. The operating system reads control cards from this file and acts accord- ingly. As Figure 1 indicates, there are four ways to transfer control from this EXEC file, three of which result in another file being EXECed. C 3 ASAGAUTHOR TESTRUNEXECFIL C O LIBRUNEXECFILE BASICEXECFILE _———{> C stops D LOADERLOOPEXEC c m) (w > C st0P5 D WRAPUPBASICTEST ( L j ASAGTESTEREXEC I < D ESCAPEFROMTEST C. Figure 1 - ASAG/AUTHOR Control Card Flow I top8 j 111.2 Flow of Control Figure 2 shows the control cards in each file. We now consider how the execution sequence of these cards passes control from file to file. The initial file, ASAGAUTHOR, begins with the control card DAYMSG,OFF (Figure 2(a)). This suppresses messages normally sent to the user's remote terminal upon execution of the other control cards. This suppres— sion serves to speed up execution and masks the internal system operation from the user. The next control card is RETURN,AA,ZZAA. These local file names will shortly be used by A/A and precaution is taken to make sure they are not already in use. The permanent file, ABSOLUTEAA, is next ATTACHed with the local file name AA. ABSOLUTEAA contains the primary program of the A/A system, an expanded and overlayed version of the original A/A program. (For simplicity, we will refer to the programs found on various permanent files by their Permanent File Names.) This routine begins communicating with the author by printing the heading: WELCOME TO ASAG/AUTHOR As explained in Appendix A, at this point the user has the choice of three run types: Creation, Library or Testing. If the Creation Run is chosen, ABSOLUTEAA will prompt the author and begin constructing a new BASIC. When the BASIC is finished it will be automatically compiled. The appropriate control cards for this are in the file BASICEXECFILE. ABSOLUTEAA transfers control by first calling the subroutine EXECFIL and then terminating execution. L EXECFIL, a COMPASS subprogram, is shown below. IDENT EXECFIL ENTRY EXECFIL CCBUF DATA CEATTACH,ZZAA,BASICEXECFILE,PW=secret.* DATA C*EXEC,ZZAA.* PARM BSSZ 1 EXECFIL BSS 1 3X6 PARM-CCBUF SX7 CCBUF LX6 1 LX7 12 BX6 X6+X7 SA6 FARM EXECM PARM EQ EXECFIL END DAYMSG,OFF. RETURN,AA,ZZAA. ATTACH,AA,ABSOLUTEAA. RFL,60000. RTL,30. AA. COMMENT, FOLLOWING CONTROL CARDS WILL BE EXECUTED ONLY COMMENT, 1F ESC‘IS PRESSED, OR LIB CHOSEN WITH NO PERM CHANGES RFL,45000. RTL,10. RETURN,ZZZZHAL,AA. DATMSG,ON. EXIT,S. COMMENT, COME HERE 1F ESC KEY PRESSED COMMENT, ALL SCRATCH FILES ALREADY RETURNED BY AA. RFL,45000. RTL,10. RETURN,AA,ZZZZHAL,TAPE88. DAYMSG,ON. (a) - ASAGAUTHOR EXEC file COMMENT, FOLLOWS AA. ON A CREATION RUN RETURN,ZZAA,AA,ZZZZHAL. REWIND,BASIC. HAL,BANNER,O=ZZBOUT,BASIC,LISTING. AUTORFL,PART. RUN,S,,,BASIC,ZZBOUT,ZZBLGO. AUTORFL,OFF. ERRS,1=ZZBOUT. ATTACH,ZZOK,CALLER1LGO. ATTACH , ZZAT , ASAGTESTEREXEC . EXEC , ZZAT . EXIT,S. ATTACH,ZZFATAL,EASICFATALRELBIN. RETURN,BASIC,ZZBLGO. ZZFATAL. DAYMSG,ON. DISPOSE,ZZBOUT,PR,L=40. (b) - BASICEXECFILE EXEC file Figure 2 - ASAG/AUTHOR EXEC Files RETURN,ZZTEST. ATTACH,ZZOK,CALLER2LGO. ATTACH, ZZAT ,ASAGTE STEREXEC . NEWNAME,TAPE10,ZZBLGO. EXEC , ZZAT. EXIT,S. RETURN,TAPE88,TAPE10,ZZBLGO,AT,ZZOK. RFL,45000. RTL,10. DAYMSC,ON. (c) - TESTRUNEXECFILE EXEC file RETURN,ZZAT. ATTACH,ZZOTHER,AASUBSCALLEDBYBASIC. ATTACH,ZZATLCO,ASACTESTER. ATTACH,ZZASAG,SUBSFROMASAG. HAL,BANNER,O=TAPE2,BASIC,TESTING. LOAD,ZZOTHER. LOAD,ZZASAC. LOAD,ZZBLGO. LOAD,ZZATLGO. zzox. EXIT,S. COMMENT, COME HERE ONLY IF ERROR BEFORE ZZOK GETS EXECUTED RETURN,ZZBLGO,ZZOK,ZZASAG,ZZOTHER,LISTING,TAPE2,TAPE88. NEWNAME,ZZBOUT,LISTING. RFL,45000. RTL,10. DAYMSC,ON. (d) - ASAGTESTEREXEC EXEC file RETURN,ZZLIB. ATTACH,ZZASAG,ABSASAGFORLOADING. ATTACH,TAPE10,BASICINDEX,Pw=secret. ATTACH,BASIC,BASICFILE,PW=secret. SKIPF,BASIC,63,00,B. ATTACH,ZZLOOP,LOADERLOOPEXEC,PW=secret. ATTACH , zz INQ , INQUIRE OFTAPElO . (e) - LIBRUNEXECFILE EXEC file Figure 2 - Continued 10 ZZINQ. COPYBR,ZZBLGO,TMPBAS,2. REWIND,TMPBAS. LOAD,ZZASAG. LOAD,TMPBAS. NOGO. ~ RETURN,TMPBAS,TAPE10,ZZBLGO. NEWNAME ,TAPES ,TAPElO. EXEC,ZZLOOP. EXIT,S. RETURN,ZZLOOP,WASTE,ZZASAG,TMPBAS,ZZINQ. ATTACH,TAPE10,BASICINDEX,PW=secret. PURGE,TAPE10. CATALOG,TAPE5,BASICINDEX,EX=***,CN=***,MD=***,RD=***, 1D=***,RP=999. EXTEND,BASIC. RETURN,TAPE10,BASIC,TAPES. RFL,45000. RTL,10. DAYMSG,ON. (f) - LOADERLOOPEXEC EXEC file RETURN,TAPE7,TAPEl,TAPE88,TAPE10,ZZBLGO,ZZASAG. RETURN,ZZOTHER,ZZOK,LISTING. NEWNAME,ZZBOUT,LISTING. RFL,45000. RTL,10. DAYMSC,ON. (g) - ESCAPEFROMTEST EXEC file RETURN,TAPE7,TAPEl,TAPE2,TAPE88,TAPE10,ZZBLGO,ZZASAG. RETURN,ZZOTHER,ZZOK,LIST1NG. RFL,45000. RTL,10. DAYMSG,ON. (h) - WRAPUPBASICTEST EXEC file Figure 2 - Continued 11 The EXECM macro used in this routine takes the data at location CCBUF and puts it into the user's control card buffer, destroying what had been there previously. When ABSOLUTEAA terminates, this data will become the next control cards to be executed; consequentlx it is impos- sible to continue executing control cards from ASAGAUTHOR. The replace- ment control cards ATTACH the file BASICEXECFILE and EXEC it. The transfer is now accomplished. If the user had chosen the Testing Run, a similar transfer would have been made to the file TESTRUNEXECFILE. A branch to LIBRUNEXECFILE can occur if the Library Run is chosen, but will_occur only if the user changes the status of any assignment from temporary to permanent (Appendix A, Section 2.2). If no status changes are made, control cards will continue to be read from ASAGAUTHOR after the program ABSOLUTEAA finishes. 111.2.1 Creation Run Flow After a new assignment has been created, a local file named BASIC is produced and control transfers to the EXEC file BASICEXECFILE. Now preliminary checkout begins. The FORTRAN source file (BASIC) is rewound and a header for the compilation listing is written to the file ZZBOUT. The subroutine is compiled.using the RUN FORTRAN compiler, with the relocatable binary written to the file ZZBLGO (which is later cataloged . as LCOBASICnn). The MSU system program ERRS [4] is used to scan the listing for fatal FORTRAN errors. If any are found, ERRS lists them at the teletype and then aborts. This abort causes a skip to the control card EXIT,S shown in Figure 2(b). Following EXIT,S in this file is the ATTACH and execution of the program BASICFATALRELBIN. This short program merely informs the user that (1) this BASIC will not compile, (2) A/A is terminating, and (3) a listing of this BASIC will be printed at the central site to aid him in debugging. (This is accomplished by DISPOSE,ZZBOUT,PR,L=40.) If no abort occurs the driver program CALLERlLGO is ATTACHed and ASAGTESTEREXEC is ATTACHed and EXECed. The remainder of this run proceeds as described for the Testing Run. 12 111.2.2 TestinggRun Flow The Testing Run may be chosen by the user during execution of ABSOLUTEAA. During this run any existing temporary BASIC may be tested. The user chooses, and ABSOLUTEAA ATTACHes, the appr0priate LGOBASICnn, naming it TAPElO. Finally, control transfers to the file TESTRUNEXECFILE (Figure 2(c)). This file first ATTACHes an alternate driver program, CALLERZLGO, naming it 220K. The driver simply calls the testing subroutine CHECKER (contained on permanent file ASAGTESTER). Next the file ASAGTESTEREXEC (Figure 2(d)) is ATTACHed, TAPElO is renamed ZZBLGO and control passes to ASAGTESTEREXEC. At this point, both Testing and Creation Runs proceed virtually identically. Now the actual testing occurs. Assignment generation or checking (as performed during an ASAG run) will be simulated. Accordingly, the appropriate ASAG subroutines must be used along with the testing program and the BASIC. These are found on files AASUBSCALLEDBYBASIC and SUBSFROMASAG. The testing subroutine, ASAGTESTER, is also ATTACHed and all are LOADed and executed. Depending on the test results, control will transfer from this running program to one of two EXEC files: ESCAPEFROMTEST (abnormal) or WRAPUPBASICTEST (normal termination). Transfer is again accomplished by use of EXECM. These two short EXEC files perform a few housekeeping chores before A/A terminates (Figures 2(g) and 2(h)). 111.2.3 Library Run Flow As noted earlier, control passes to the file LIBRUNEXECFILE (Figure 2(e)) only if one or more temporary BASICs are to be made per- manent. Temporary BASICs are retained as relocatable binary subroutines on separate permanent files, while permanent BASICs are retained as secondary overlays on a single permanent file. Making a BASIC permanent, then, involves the creation of an appropriate overlay and adding it to the proper file. LIBRUNEXECFILE (Figure 2(e)) sets up this process by ATTACHing ABSASAGFORLOADING for loading and overlay creation. Next the files BASICINDEX (see Appendix A, Section 2.1) and BASICFILE (which contains the absolute binary of the permanent BASIC routines) are ATTACHed. 13 A SKIPF positions the file for adding the new permanent BASIC(s). The next EXEC file, LOADERLOOPEXEC (Figure 2(f)), is ATTACHed as is the program ZZINQ (on permanent file, INQUIREOFTAPEIO) and control transfers to LOADERLOOPEXEC. ZZINQ examines the index file to determine which BASIC(s), if any, should be made permanent. When the user chooses to make a BASIC permanent, ABSOLUTEAA sets a flag in the file BASICINDEX. ZZINQ searches for this flag and, upon finding it, writes the appropriate overlay header to file TMPBAS and ATTACHes LGOBASICnn as local file ZZBLGO. BASICINDEX is updated and written to file TAPES. Upon termination of ZZINQ, LGOBASICnn is copied behind the overlay header and loaded with ABSASAGFORLOADING. The overlay loader adds the new secondary overlay to the file BASICFILE and routes the main and primary overlays to the file WASTE. The new BASICINDEX (TAPES) reflects the fact that this BASIC is now permanent. Accordingly, it replaces the old version (NEWNAME,TAPE5,TAPE10.) and the LOADERLOOPEXEC control card sequence begins again (EXEC,ZZLOOP.). When ZZINQ can find no BASICINDEX entries indicating changes, the program aborts. Control cards which follow the EXIT,S cause the new BASICINDEX to be CATALOGed, the file of permanent BASICs to be EXTENDed and A/A to be terminated. A more detailed flowchart of control cards, programs and decision flow is shown in Figure 3. 111.3 Control Card Structures It is worthwhile to note the basic control structures which are simulated in this system with control cards. The IF-THEN-ELSE structure: V’ a—W—b 14 < > <7 DAYMSG,OFF execute ABSOLUTEAA perform ATTACH Library Run .LGOBASICnn perform load Creation Run CALLERZLGO compile BASIC prepare for - ”any CZngle I L creation DISPOSE copy to print execute ASAGTESTER changes -' left? (: wrapup i:) o terminatio CATALOG new BASICINDEX: create EXEC BASICFILE t: overlay ESCAPEFROMTEST I I EXEC L <: wrapup ::> RAPUPBASICTEST TAPElO<+TAPE5 ( wrapup I I wrapup ) Figure 3 - A/A System Flowchart 15 can be realized with the control card sequence: ALPHA. I: control card block a (THEN clause) EXIT,S. [L control card block b (ELSE clause) where ALPHA is a prOgram which triggers an abort if some condition is false. An example of this in A/A is the compile/no-compile decision in BASICEXECFILE. The DOJWHILE structure: can be realized with the control card sequence: ALPHA. (ALPHA will trigger an EXEC [: control card block a abort when some con- file EXEC,IOOP. dition becomes false.) “med EXIT S IDOP ’ ' remaining control cards An example of this in A/A is the file IOADERLOOPEXEC. The capability of simulating the fundamental control structures becomes more interesting when one considers the results of Bohm and Jacopini dealing with flow diagrams [2]. Their paper demonstrates that any algorithmic process can be expressed as a combination of three basic forms: IF-THEN-EISE, DO-WHILE, and sequential statements. If is evident that implementation of these principles is entirely realizable and applicable at the control card level. 16 111.4 Organization of ABSOLUTEAA The main part of A/A is the program ABSOLUTEAA. Figure 4 shows its overlay organization. When the user responds to the message: CHOOSE RUN TYPE- CREATION,LIBRARY OR TESTING (TYPE C,L OR T)- one of three primary overlays is loaded: Overlay (1,0) for Creation Run, Overlay (2,0) for Library Run, or Overlay (3,0) for Testing Run. Two secondary overlays are associated with the Creation Run. Overlay (1,1) generates the first part of the BASIC subroutine,through the Data Variables section. Overlay (1,2) generates source code,beginning with the Text section,and completes the BASIC. MAIN SIZTEST CATAL LIBEXEC (0,0) GETFILE RETURN PURGE GETBNUM ATTACH ATTACHl (1,0) PACKIO (2,0) BASLIB (3,0) GETO AUTHOR VARVAL ERR LOADJK WHICH LODEXEC (1.1) (1.2) AUTHORl AUTHOR2 DIMEN EDCMND DIM EXAMINE CETFORM EXAM 1N2 BRKU'P ICVT GETREP PUTEXT DELETE GETLINE SCRNCH PUTDCL SEARCH PUTPROC NMCRNCH GENFREE COMOUT KODOUT TAB LOUT SOLGEN GENFIX GETPOS BKFIX EXECFIL Figure 4 - Overlay Structure and Subprogram Names of ABSOLUTEAA 1V. 0 Prggramnigg Methodology In Chapter 111, we discussed flow of control of the three major A/A system functions. In this chapter, we will discuss organization of the programs, contained in ABSOLUTEAA, which enable the user to perform these functions: the creation, maintenance, and testing of the ASAG assignment generating routines (the BASICS). 1V.1 Creation Run Program As indicated in Section 111.4 the creation program is set up as a primary overlay, Level (1,0), with two secondaries, Levels (1,1) and (1,2). While Appendix A, Section 3.1, discusses the Creation Run from the user's perspective, we will now consider the organization of the creation program and its five logical divisions: . definition of assigmnent parameters . definition of data variables . definition of solution variables . formulation of assignment text . formulation of the solution algorithm Ln-I-‘WNIH 1V. 1 . 1 Definition Divisions The first three logical divisions are used to define parameters and variables of the assignment. Most of the code to accomplish this is in Overlay (1,1). Figure 5 shows the general flow of control for Division 1; Divisions 2 and 3 are organized almost identically, with minor differences in syntax checking and code generation. Most of the work in these three divisions involves checking val- idity and constructing tables to reflect correct definitions. As discussed in [1] there are three such tables, each with twenty entries L of seven words. Author's definitions are checked for syntactical correctness (with additional information solicited in some cases). When correct, the information is stored in the appropriate table. 17 18 Chew? EL ask for and get assignment description write heading for this BASIC —:> ask for and get assignment parameter definitions print //HELP //END //END‘ <}-—-— help or //HELP message ? neither check validity print <+__Jappropriate no definition error message add to Information Table I write code into new BASIC to define these variables next L division Figure 5 - Assignment Parameters Division of Creation Run 19 Figure 6 is a refinement of the validity checking portion of Figure 5. If the user gives the assignment parameters without a FORTRAN format Specification, the routine GETFORM is called. CETFORM: builds a format based upon the user's reaponses to further prompting. Thus, the author whose knowledge of FORTRAN is limited may easily use A/A. .Assignment parameters may be defined by means of either bounded, uniformly distributed, random variables or expressions involving previously defined parameters. The Information Table contains a sevendword entry for each defined parameter. If, however, a parameter is defined in terms of other parameters, an entry is also made in the Expression Table; a pointer in the Information Table links the two entries for each expression-defined parameter. Although only assignment parameters may be defined by use of expressions, the validity of data and solution variables is checked in the same manner, using the same routines. Syntax errors are class- ified into twenty four categories; error messages are shown in Figure 7. IV.1.2 Text and Solution Algorithm.Divisions The Text and Solution Algorithm divisions (with associated sub- routines) are organized into Overlay (1,2). The user has four edit- ing commands available in these last two divisions (see Appendix A, Section 3.1.4). Text is entered into a work array which may be mod- ified ani examined. 'When //END is typed the contents of this file are processed and become part of the BASIC under construction. Figure 8 shows flow of control in the text editor. The subroutine EDCMND checks for valid editing commands and also returns the numeric command parameters. For example, if llMODIFY,3 were entered, the returned parameter would be 3. If no command is indicated, the line is checked syntactically by EXAMINE. This routine checks the legality of assignment parameter variables (if any) and validates line continuation limits. When l/END is typed, text processing begins. The routines PUTEXT and GETLINE take text from the work array,using it to create WRITE and FORMAT statements for inclusion in the BASIC being created. 20 c 3 ‘V orrect no variable ame? yes present no ? es set format no format present flag ? yes format no correct ? yes COPY expression to ex- expr. bounds Expression ' or bounds Table yes no ‘ bounds OK ? V’ parens no match ? yes call CETFORM turn off fzrmat fla lag se 3 2 I no complete Information Table print error message 5 Figure 6 - Validity Checking Routine (:return ;:) O \DQVO‘UIJ-‘UNH N N N N N H H H H H H H H H H 4> u N r 0 So on s: as u: 4‘ a N H o I O O O O O O O O O O O O O 21 What? I= is an illegal form. Illegal format. Only types I,F,E,D,A,R,L are allowed. Bounds not Specified. No ( found. Only variable name found. Illegal character follows bounds specification. Illegal character in . I-longer than 7 characters. Illegal Character in bounds Specifications. Illegal character in format Specification. Format size error. ( is illegal. No bounds should be Specified here. No variable name Specified. =, is an illegal form at this point. Illegal format. No period allowed. Illegal format. .A number must follow period. No array length Specified. Assumed to be 1. Dimensioning variable is undefined. Illegal format. Period, number must follow initial number. Bounds Specifications incomplete. No closing parens for expression. Illegal character follows expression. 'Max number of expressions exceeded. No format length Specified. Figure 7 - Syntax Error Messages 22 from last division print header line-no. <— 1 MOD =(59 Form 2: =((0) Variable names must begin with a letter and may contain up to seven letters and/or digits. However, no variable name may begin with the letters 22 as all A/A internally generated identifiers begin that way. All s and s must conform to standard FORTRAN syntax. This is because A/A constructs a FORTRAN subroutine, part of which is taken directly from the author's input. However, if the user does not give a format specification when defining a variable, A/A solicits the necessary information, then builds the FORTRAN format for him.(Section 3.2, Comment (2) ). The bounds must be constants which specify the value range of the random numbers to be drawn for this variable. An example of the first form is: PARAM=IZ(10,20) Here, A/A will generate a random integer whose value is in the range [10,20] for each student and will assign it to the variable PARAM. Note that the FORTRAN implicit type-convention is not in effect; the format specification, 12, determines the variable type (in this case, integer). An example of the second form is: PARAM2=IZ((2*PARAM)) This form allows a variable to be defined as a function of previously defined assignment parameters. However, care must be exercised because A/A will not check the definitions. A mistake can be corrected simply by redefining the variable. When the user has defined all assignment parameters, he terminates this division by typing //END on a separate line. 3.1.2 Data Variables In the Data Variable Division, ASAG's ability to generate individualized assignments is implemented in two ways: (1) by allowing for randomly generated assignment data and (2) by allowing the assignment statement to be given at three levels of complexity. Most assignments will involve data which the student is asked to manipulate in some way. In this division the instructor is asked to define variables that represent such data. Values for these variables will be generated and printed for the student at assignment-generation time. 51 Since the problem statement is more complex at higher levels, it is often necessary to include additional data and text, and require additional answers of Level 2 and Level 1 students. Accordingly, the second, third and fourth divisions of the Creation Run will each ask for input at three levels. Beginning with the simplest assignment level the author defines the data variables needed. A/A begins with the message: DATA‘VARIABLES- LEVEL 3 * When all necessary Level 3 variables have been defined, the author types //END on a separate line. A/A responds with: LEVEL 2 _ * Additional user variables may now be defined for students who will receive Level 2 assignments. As before, //END is typed to proceed to Level I. ' At each level, A/A is seeking definitions of the form: =(5),’ This is identical to Form 1 for assignment parameters except for the addition of' ,’which is optional. is an integer constant (or variable defined in the Assignment Parameter Division) which allows many values to be given the same variable name (similar to a one-dimensional array). As before, if the format specif- ication is not included,the information will be solicited from the user. An example of a data variable definition is: X=IZ(30,90),10 This would define a set of 10 data items, all integers, in the range [30,90]. Another example is: =F3.l(l.0,2.0),PARAM Assume that PARAM is the assignment parameter defined in the example of Section 3.1.1; i.e., it may take on any integer value in the range [10,20]. Then Y will be generated as a collection of from ten to twenty real numbers, each of which has a value in the range [1.0,2.0]. 52 The data generated for these variables would be listed for the student when ASAG generates the assignment. One such listing might be: USE THESE VALUES AS DATA X 42 Y 1.3 1.9. 1.3 1.6 1.8 1.3 1.5 1.0 2.0 1.4 1.1 1.6 3.1.3 Solution Variables Each assignment will, Of course, require a set of answers. These must be labeled by the student if the free field option has been chosen by the instructor (Section 3.1.5). The defining Of solution variables in this division amounts to providing a list Of answer-labels for the student. In addition, formats are specified to inform the student Of the answer-field size specifications expected by ASAG. Under the fixed field Option, this format (and the expected page position) are all that ASAG needs tO correctly locate the student answers. Variables defined in this section are Of the form: =5- with both ’and , again being Optional. Some examples Of correct forms are: KGB=I2,16 XYZ=,B ABC DEF=F6.1,PVAR PRB=I4 If the format is omitted A/A will solicit that information from the author. Note also that if both ’and are omitted the variable should be written without a following equal sign. There should be one solution variable defined for each answer (or string Of answers) expected. If additional answers are expected from students working at a more difficult level, then a corresponding number Of solution variables must be defined at that level. The names and formats selected will be listed for the student as part Of the ASAG-gen- erated assignment. The following example illustrates the type Of output received by the student: 53 VARIABLES REQUIRED FOR SOLUTION MEAN (F6. 2) VAR (F6.2) TOTAL (15) Typing //END following the last solution variable of Level 1 terminates this division. 3.1.4 Text In this division the instructor enters the assignment statement. Again there are three possible levels Of difficulty. Level 3 text states the basic assignment which all must solve. Level 2 text gives additional requirements for more advanced students, etc. The Text Division begins with the header: PLEASE ENTER TEXT. AT END TYPE //END ON A NEW LINE. 1* In order tO facilitate entering relatively large amounts Of information, this division (and the one following) allows four editing commands. They are: //SCRATCH,' //DELETE,» / MODIFY, //LIST,3 A/A generates line numbers tO aid the editing process. //SCRATCH,’ deletes all lines from 'through the highest line number yet generated. This has the effect Of erasing the last n lines Of text entered. Before complying with this command, A/A lists the last remaining line (one less than ) and gives the user an Option to reconsider and reject his SCRATCH request. //DELETE,' removes the specified line from the text. //MODIFY,' deletes the text at and requests the author to input new text for that line. Upon completion Of a I/MODIFY or a //DELETE, A/A again requests input for the next available line. //LIST,3- lists text beginning with - and ending with u If is not specified, listing is to the end of the author's current text. If only //LIST is entered, 54 all text lines are listed. Only 60 characters per line are allowed. However, since assignments 'will most likely be produced on the line printer, text lines may contain up to 135 characters. Typing + immediately following a line number allows continuation Of the preceeding line. An example Of line con- tinuation is: 4*I'HIS LINE IS TO BE 5*+ CONTINUED HERE. Note that trailing blanks on each line will be trimmed. The above ex- ample, then, will print out as 34 characters, all on one line. If a ‘word is not aplit across two text lines the user must remember to leave a blank following the plus sign to avoid running two words together. Also note that the first character on the line is printed and not used for carriage control. Names Of assignment parameters may be included in the text. The apprOpriate variable name (as defined in the Assignment Parameters Div- ision) should be enclosed by double dollar signs, e.g., $$PARAM1$$ . At assignment-creation time ASAG will insert an appropriate value in the text. For example, assume PARAMl had been defined previously as PARAM1=I2(10,20) and the text contained the lines: 4*FIND THE AVERAGE OF THE $$PARAM1$$ VARIABLES 5*+ NAMED SUMI. ASAG would draw a random value for PARAMl in the range [10,20]. If that value was 14, the statement printed for the student would look like: FIND THE AVERAGE OF THE 14 VARIABLES NAMED SUMI. Up to 99 lines Of text may be entered and edited before renumbering occurs. Before line number 99 is Output, A/A cautions the user that renumbering will occur following this line. The first 99 lines will remain intact, but no further editing may be done on them. Each level Of the Text Division terminates when the user types //END on a new line. 3.1.5 Solution Algorithm Each assignment (BASIC) involves two phases: generation and checking. During assignment generation the text (which describes the problem) is output to the student along with any data and solution labels required. 55 The student later submits his solution and the BASIC is called for checking. To provide this checking capability the author must design a general algorithm to calculate answers for all student assignments (based on the data values given them). Accordingly, he enters a sequence Of'FORTRAN statements tO implement this algorithm. ASAG will calculate answers from the algorithm and compare them.with those submitted by the student. The Solution Algorithm Division is divided into three sections: Declaration, Procedure and Solution Method. The editing commands (described in 3.1.4) are again available to help the user recover from mistakes. The Solution Algorithm Division begins with the heading: PLEASE PROVIDE THE SOLUTION ALGORITHM DECLARATION SECTION. 1* The author may now declare any variables (not previously defined) needed for the algorithm by using the standard FORTRAN declarations: TYPE, DIMENSION, EQUIVALENCE and DATA. Again, nO variable names should begin ‘with the letters ZZ. It is the user's responsibility to use correct FORTRAN syntax as minimal checking is done by A/A. One A/A restriction, though, is that COMMON statements are not allowed. Note also that DATA statements should follow all other declarations, just as in a regular FORTRAN program. The declarative statements may begin anywhere on the line. A plus sign at the beginning Of a line is used to signify con- tinuation Of the source statement. Following all declarations //END should be typed on a new line. A/A responds with: PROCEDURE SECTION. 1* Executable statements are entered in the Procedure Section. Restrictions are: no user defined FUNCTION or SUBROUTINE calls should be made and no STOP, PAUSE, CALL EXIT, RETURN or END statements should be used. A/A ‘will not prevent the user from doing this, nor will it check FORTRAN syntax, but the resulting program may not be properly formed. Cements 56 are allowed, beginning with either C or *. Statement numbers must be in the range [1,8999] (A/A generated statement numbers begin at 9000). The same continuation rules apply as in the Declaration Section. Statements may begin anywhere on the line. At least one Space must be left between a statement number and its statement. The following are examples of legal input: 1*CCMMENT. THIS IS A CQ‘MENT BECAUSE IT STARTS WITH C. 2% THIS IS ALSO A COMMENT 3*1234 A=B+C 4*IF(X.GT.5)GO 5*+TO 10 The next set of examples are illegal and will not be accepted by A/A. 6*1234 A=B+C (no space between number and statement) 7*1234 (only statement number found) 8*1234567 A=B+C (statement number too big) The next set are illegal but will be accepted by A/A. 9*99999 A=B+C (statement number greater than 9000) 10*STOP (STOP statement not allowed) 11* CALL MYSUB (calls to user defined subroutine not allowed) 12* C(MMENT (the C not in column 1, FORTRAN will reject this) Typing //END on a separate line will terminate the Procedure Section and A/A will respond with:2 SOLUTION METHOD, FIXED OR FREE? If FREE is chosen the student may display his answers in any order and anywhere on his output, but must label each answer in the form: = where is a solution variable defined earlier and is the student's submitted answer. The answer must be printed using the format specified to the student on the generated assignment (and defined by the instructor in the Solution Variables Division). The variable name must be delimited by at least one blank on the left and separated from the value by an equal sign. The equal sign may be preceeded and/or followed by any number of blanks. 2 The remainder of this Section is taken in part from: Allaire, William P., An Author Interface for the ASAG System, Unpublished 14.8. Thesis, Department of Computer Science, East Lansing, Michigan, Michigan State University, 1974, pp. 19-22. 57 If, however, FIXED is chosen, A/A will prompt the user for the location Of each solution variable defined earlier. The prompting will be Of the form: 2 to which the user responds with input Of the form: PP/LL/CC where PP is the page number, LL is the line number, and CC is the print position where the rightmost character of the field for that variable should be located. Note that print position 1 is the first character printed and is not the carriage control column. When the user types FIXED, A/A responds with the name of the first solution variable. For example: SOLUTION METlDD, FIXED OR FREEm PLEASE ENTER VARIABLE FIELD LOCATIONS: VARl? 1/5/20 (User response is underlined for clarity.) If we assume that the field width specified for VARl is 8 then its expected location will be page 1, line 5, columns 13-20. Note that since the position is fixed, no variable-name tag should prefix the student's answer. Once all solution variables have been given positions, this section terminates automatically. 3.1.6 Termination Of Assignment Creation After the solution method has been determined, and positions assigned to variables (if necessary), A/A responds with the message: THIS ASSIGNMENT IS TITLED BASICnn ONE MOMENT WHILE IT OOMPILES.. . nn is an integer in the range [01,63]. If the assignment compiles ‘without error, it is entered into the BASICINDEX file under the name BASICnn. The compilation may take anywhere from 5 to 20 seconds (clock time, not computer time). If the BASIC does not compile, a listing Of the FORTRAN errors is given to the author and a listing Of the entire source program is printed at the central site. The message: SUBMITTED UNDER SEQUENCE SBnnnnn 'will appear giving the number needed for pickup. The most likely cause Of compilation failure is a syntactical FORTRAN error made in the Solution Algorithm Division. 58 3.2 Sample Creation Run Session The following illustrates use of the A/A.Creation Run. All user input is underlined for clarity. Parenthesized numbers are keyed to comments which follow the session. (1) (2) (3) (4) (5) (6) WELCOME To ASAG/AUTHOR RUN OF 11/08/74 AT 14.15.59 TYPE //END TO TERMINATE ANY SECTION TYPE //HELP WHENEVER YOU NEED IT CHOOSE RUN TYPE- CREATION, LIBRARY OR TESTING. (TYPE C,L OR T)-g_ PLEASE INPUT A.SHORT (LESS THAN 60 CHARACTER) DESCRIPTION OF THIS ASSIGNMENT *POLYNOMIAL CALCULATION, SUMMATION ASSIGNMENT PARAMETERS- *P1=12(5,8) *P2=((P1-1)) WILL THIS VARIABLE BE INTEGER OR REAL (TYPE I OR R)11 ‘MAX.NUMBER 0F SIGNIFICANT FIGUREszg *P3=K2(10,15) ERR3. ILLEGAL FORMAT. ONLY TYPES I,F,E,D,A,R,L ARE ALLOWED. TRY AGAIN. *P3=12(10;15) ERR20. BOUNDS SPECIFICATIONS INCOMPLETE. TRY AGAIN. *P3=12(10,15) *P4=I2(10,15) */7END DATA.VARIABLES- LEVEL 3 *COEFF=I3(-15,15)P1 ERR6. ILLEGAL CHARACTER FOLLOWS BOUNDS SPECIFICATIONS. *COEFF=I3(-15,15),P1 *XARRAY=12(.9,9),P3 *YARRAY=I2(100,999),P4 *YARRAY=13(100,999),P4 *7YEND LEVEL 2 *ILEI‘R LEVEL 1 *LLEEQ SOLUTION VARIABLES- LEVEL 3 <7) (8) (9) (10) (11) (12) 59 *ANSWER=18,P3 *ANSWER2=F8.2.P4 ILLEEQ. LEVELZ *“END LEVEL 1 *L/_E_N2 PLEASE ENTER TEXT. AT END TYPE //END ON A.NEW LINE. LEVEL 3 1*GIVEN ARE $$Pl§$ INTEGERS LABELED COEFF. 2*CONSIDER THEM TO BE COEFFICNTS OF A $$P2$$ DEGREE 3*IYSCRATCH,2 LAST LINE RETAINED WILL BE- 1*GIVEN ARE $$P1$$ INTEGERS LABELED COEFF. TYPE C TO CONTINUE-g, ’ 2*CONSIDER THEM TO BE COEFFICIENTS OF A $$P2$$TH DEGREE 3*POLYNOMIAL (I.E. FIRST VALUE Is THE X**$$P2$$ COEFFICIENT, 4%LAST ONE x**0 COEFFICIENT, ETC.) 5* SFNOW CONSIDER THE $$P3$‘ VALUES LABELED XARRAY. EACH WILL 7*_BE CONSIDERED AS A PARTICULAR VALUE FOR x, THE POLYNCMIAL 8*UNKNOWN. EVALUATE THIS POLYNOMIAL FOR EACH VALUE IN 9*XARRAY.,LAEEL,THE RESULTING VECTOR- ANSWER. 10* 11*7/MODIFY,6 6*NOW CONSIDER THE $$P3$$ VALUES LABELED XARRAY. EACH WILL 11*SUM THE VECTOR ANSWER. IF THE RESULT Is POSITIVE FIND 12*THE FOURTH ROOT FOR EACH OF THE $$P4$$ ELEMENTS OF 13*YARRAY. OTHERWISE FIND THE SQUARE ROOT OF 14*EACH ELEMENT OF YARRAY. LABEL THIS RESULT ANSWERz. 15*PRINT BOTH ANSWER AND ANSWERz, USING THE FORMATS GIVEN, ‘ 16*PREFIXED BY THEIR RESPECTIVE LABELS, THEN AN .EQUAL SIGN. 17* 18*READ IN ALL DATA.VALUES FROM CARDS. 19*77END LEVEL 2 1*!!EEQ LEVEL 1 1*/_/_EN_P. PLEASE PROVIDE THE SOLUTION ALGORITHM DECLARATION SECTION ' Rama 60 PROCEDURE SECTION 1* mark --0 2*DO 20 Ie1,Ps 3*ANSWER(I)=0 expo IO J=1,P1 5*ANSWER(I)=ANSWER(I)+COEFF(J)*XARRAY(I)**(J-l) 6*IO TOTAL=TOTAL+ANSWER(I) 7*20 CONTINUE (13) 8*l/MODIFY,6 6*10 ITOTAL=ITOTAL+ANSWER(I) 8*DO 3o K=1,P4 9*ANSWER2(K)=SQRT(YARRAY(K)) 10*IF(ITOTAL.LT.0)GOTO 30 11*ANSWER2(K)=SQRT(ANSWER2(K)) (14) 12*30 CONTINUE 13*ZIE_N2 SOLUTION METHOD, FIXED OR FREE?E§E§ THIS ASSIGNMENT IS TITLED BASIC19 ONE MOMENT WHILE IT CCMPILES. . . Notes on the above session. 1. 12. 13. 14. ,P2 is defined as a function of P1. Notice that this makes each generated P2 value one more than the correSponding P1 value. The user neglected to Specify a format for P2 so AlA solicited the information. Accidentally typing K caused Error 3. A/A detects 22 different syntactical errors. Here the user forgot a separating comma, YARRAY was redefined because the user realized that 3 digits would not fit into an 12 format. End of the Data Variables Section. This assignment will involve only one level of difficulty. ANSWER is an array of answers with multiplicity P3. The ASAG-generated value for P1 will be inserted in the text. User decided tO erase line 2 Since coefficients was misspelled. Skipping a line causes a blank line to be printed. The MODIFY command responds with 6* . User then Changes that line only. Numbering begins again with line 11. NO declaration statements needed. User notices a mistake in his program. The 30 CONTINUE is the last line in the algorithm. It is a good practice to end solution algorithms on a CONTINUE statement since RETURN is illegal. Although not exemplified in the above Procedure 61 Section, it is Often necessary to conditionally skip the last step(s) Of an algorithm; e.g. IF(I.GT.5)GO TO 20 XfiY+Z A=B+C 20 CONTINUE Use Of a terminating CONTINUE provides a convenient, common ending point. 3.3 Assigpment Testing If the BASIC does compile correctly, A/A automatically enters the Testing Run. This option can also be called explicitly to test any temporary BASIC already in the Library by typing T as the response to A/A's initial request for the run type (Section 1.0). lDetails Of the Testing Run are given in Section 4.0. ~ 4.0 AJA Testinglg; Reaponding to the request: ‘ CHOOSE RUN TYPE- CREATION, LIBRAM OR TESTING. (TYPE C,L OR T)- by typing T allows the user to begin the A/A Testing Run. This run permits my temporary. BASIC to be tested for correctness. The author has the Option of testing the generation or checking portions of the BASIC. If generation is chosen, A/A will create up to three individualized assignments at each of the three levels Of diff- iculty (as specified by the user). These sample assignments will be printed at a site selected by him and can later be checked for correct- ness. Prefixed to each of the nine possible assignments is a label, CODE=mn, where m is the level number and n is a number between one and three identifying that particular version of the assigmnent. (This code will be needed later to test the assignment checking portion Of the BASIC.) Recall that during the A/A Creation Run, this testing Option is begun automatically if the BASIC just created has compiled correctly (see Section 4.2). The author tests a BASIC by first preparing trial answers for one or more sample assignments. Each answer set will be different if the instructor has created the BASIC so as to individualize the assignments generated. Therefore, the apprOpriate label, CODE=mn, must be prefixed to each trial answer set. This Special identifier, which would _I_1_O_1_:_ be part of the students' submitted answers during an ASAG SOLUTION run, allows A/A's Testing Run to generate the correct answer set during assigmnent checking. The collection of the instructor's trial answer sets must be available to A/A on a local file named ANSWER when this Option is run. The results for each assignment are listed at the teletype. 62 63 4.1 Sample Testing Run - Stand-alone Generation Option CHOOSE RUN TYPE- CREATION, LIBRARY OR TESTING. (TYPE C,L OR T)-T WHICH BASIC DO YOU WISH TO TEST? (1) ENTER NAME (E.G., BASIC43)-BASICl9 WOULD YOU LIKE To TEST ASSIGNMENT GENERATION OR CHECKING? (TYPE G OR C')-_G WHAT COMBINATION OF LEVELS WOULD YOU LIKE GENERATED? (2) (l, 2, 3, 12, 13, 23, 123).; HOW MANY VERSIONS 0F LEVEL 32(1 TO 3»; (3) WHERE WOULD YOU LIKE THE SAMPLE ASSIGNMENTS PRINTED? (A, B OR V)-§_ SUBMITTED UNDER SEQUENCE SB10678 (4) READY .12.23.21. Notes on the above session. 1. Assume this is the same assignment that was created as an example in Section 3.2. 2. By typing 3, only sample assignments at Level 3 would be generated; by typing 123, sample assignments at all three levels would be gen- erated; etc. In this example there was only one level created. 3. The destination codes (A, B, V) apply only to MSU. The user's problem.number must be authorized for any destination chosen or the system will refuse the request. 4. These assignments will be printed at the central site. The READY message indicates that A/A.has ended. The user later picks up the two assignments printed, identified by the Sequence Number SB10678. An example of this output follOws: CODE=31 PROBLEM NUMBER 0 GENERATED FOR .. STUDENT NAME CREDIT- ID NUMBER .. 999999 SECTION 999 DATE DUE .. NONE GIVEN ARE THE 5 INTEGERS LABELED COEFF. CONSIDER THEM.TO BE COEFFICIENTS OF A. 4TH DEGREE POLYNQIIAL (LE. FIRST VALUE IS THE X**4 COEFFICIENT, LAST ONE X**O COEFFICIENT, ETC.) NOW CONSIDER THE 10 VALUES LABELED XARRAY. EACH WILL BE CONSIDERED AS A PARTICULAR VALUE FOR x , THE POLYNCMIAL UNKNOWN. EVALUATE THIS POLYNmIAL FOR EACH VALUE IN XARRAY. LABEL THE RESULTING VECTOR- ANSWER. SUM THE VECTOR ANSWER. IF THE RESULT IS POSITIVE FIND THE FOURTH ROOT FOR EACH OF THE 11 ELEMENTS OF YARRAY. OTHERWISE FIND THE SQUARE ROOT OF EACH ELEMENT OF YARRAY. LABEL THIS RESULT ANSWERZ. PRINT BOTH ANSWER AND ANSWERZ, USING THE FORMATS GIVEN, PREFIXED BY THEIR RESPECTIVE LABELS, THEN AN EQUAL SIGN. 64 READ IN ALL DATA.VALUES FROM CARDS. USE THESE VALUES AS DATA COEFF -7 -14 9 13 2 XARRAY -4 0 7 3 9 -6 1 -5 -2 7 YARRAY 562 831 692 415 106 902 558 293 296 191 708 VARIABLES REQUIRED FOR SOLUTION ANSWER (I8) ANSWERZ (P8.2) 4.2 Sample Testing Run Session - Generation Option Called From Creation Run We continue from the last two lines produced by A/A.in the sample Creation Run Session (Section 3.2). THIS ASSIGNMENT IS TITLED BASIC19 (1) ONE MQIENT WHILE IT C(MPILES. . . (2) DO YOU WISH TO TEST THIS ASSIGNMENT NOW?YES WOULD YOU LIKE To TEST ASSIGNMENT GENERATION OR CHECKING? (TYPE G OR C)-_g (3) etc. Notes on the above session. 1. If the BASIC compiles correctly, the Testing Run is initiated automatically. 2. Note that this message does not appear in the session of Section 4.1. In this case the user has the option of testing now or at a later time. 3. At this point the session follows the same pattern shown in Section 4.1. 4.3 Creation of the ANSWER File To test assignment checking the author must prepare a file named ANSWER, containing pseudo-student answers, to be used with the Checking Option of the Testing Run. This must be prepared outside of the A/A system. While the file can be created in a variety of ways, the follow- ing control card sequence illustrates one way of preparation as a batch job. COPYCR,INPUT,OUTPUT. FTN. LGO. NEWNm,wTPUT.A. .r, .‘ k I .. I 1. .-~ c n. ’— ,I ir‘ . .-....., 65 CATALOG,A,ANSWERFILE,TK=secret. 789 CODE=31 789 [FORTRAN source program 6789 In the above example the author has written a FORTRAN program to produce answers to the problem defined as CODE=31. First the label CODE=31 is copied to OUTPUT, then the FORTRAN listing and execution output follow. The file name is changed from OUTPUT to A, then cataloged for later retrieval and use by A/A. (NOte that this file must be attached to the local file name ANSWER before the A/A.Testing Run (Checking Option) is entered.) 4.4 Sample Testing;Run Session- Checking Option (1) (2) (3) CHOOSE RUN TYPE- CREATION, LIBRARY OR TESTING. (TYPE C,L OR T)-'_l'_ - WHICH BASIC DO YOU WISH TO TEST? ENTER NAME (E.G., BASIC43)-BASICl9 WOULD YOU LIKE TO TEST ASSIGNMENT GENERATION OR CHECKING? (TYPE G OR C)-C CODE 31 VARIABLE STATUS ANSWER (1) 'CORRECT ( 2) CORRECT ( 3) CORRECT ( 4) CORRECT ( 5) CORRECT ( 5) CORRECT ( 7) CORRECT ( 8) CORRECT ( 9) CORRECT (10) CORRECT ANSWER2 ( 1) CORRECT ( 2) INCORRECT ( 3) INCORRECT ( 4) INCORRECT ( 5) INCORRECT ( 6) CORRECT ( 7) CORRECT ( 8) INCORRECT ( 9) MISSING (10) MISSING (11) MISSING 66 EOF NO. 1 (4) E01 ON ANSWER FILE END TESTING RUN READY .12.35.32. Comments on the above session. 1. Checking Option Chosen. 2. This option reports on each solution variable and its status- correct, incorrect or missing. This report would normally be printed out to each student. 3. If the variable has been defined with multiplicity, each element of the vector is checked and its status reported beside its position number. 4. EaCh answer set (correSponding to a different CODE=mn) is separated by an EDR.on the file ANSWER. In this example there was only one sample assignment being Checked. The Checking Option terminates when an end-of-informstion is detected on ANSWER. MICHIGAN STATE UNIVERSITY LIBRARIES I | IIIIIIII I‘ I I" II I‘ll IIIIIAIII‘. I 84 8554 I‘," |‘ TI‘ I]? 3 1293 030 .._.._- - _