Classroom Support and System Administration Support forLarge-Scale Educational Computer System

Akinori Saitoh,1 Tomohiro Nishida,2 Michio Nakanishi,3 Seigo Yasutome,4 Ken-ichi Baba,3 Yuji Shigehiro,5 Akira Harada,6 Nariyoshi Yamai,7 and Toshio Matsuura8

1Graduate School of Engineering Science, Osaka University, Toyonaka, 560-8531 Japan

2Faculty of Informatics, Osaka Gakuin University, Suita, 564-8511 Japan

3Cybermedia Center, Osaka University, Toyonaka, 560-0043 Japan

4Faculty of Business Administration, Southern Osaka University, Osaka, 587-8555 Japan

5Faculty of Engineering, Osaka Institute of Technology, Osaka, 535-8585 Japan

6Graduate School of Human Sciences, Osaka University, Suita, 565-0871 Japan

7Computer Center, Okayama University, Okayama, 700-8530 Japan

8Media Center, Osaka City University, 558-8585 Japan

SUMMARY

University and other educational computer systemsmay have several thousands to several tens of thousands ofusers, and several hundreds to several thousands of termi-nals. When the scale of the system is enlarged, not only isthe burden of management increased, but various problemsare produced in the system configuration and administra-tion due to the character of the educational system, in whichmany identical manipulations are performed at the sametime. This study was performed in the educational computersystem of the Osaka University Information ProcessingEducation Center (now the Cybermedia Center). Throughthe design and development of a system to support smoothadministration of the computer system and classroom ac-tivities in the center, the functions needed for support were

organized and practical problems were identified, togetherwith methods for their solution. The new system was oper-ated at the Osaka University Information Processing Edu-cation Center and was found to contribute greatly toclassroom and administration support. © 2003 Wiley Pe-riodicals, Inc. Electron Comm Jpn Pt 2, 86(9): 42–52,2003; Published online in Wiley InterScience (www.interscience.wiley.com). DOI 10.1002/ecjb.10180

Key words: educational computer system; systemmanagement; classroom support; administration support;distributed system.

1. Introduction

As increasing emphasis is laid on information tech-nology, information-oriented education and education that

© 2003 Wiley Periodicals, Inc.

Electronics and Communications in Japan, Part 2, Vol. 86, No. 9, 2003Translated from Denshi Joho Tsushin Gakkai Ronbunshi, Vol. J84-D-I, No. 6, June 2001, pp. 956–965

42

makes use of computers are attracting increasing interest.In educational institutions, including universities, the num-ber of classes that use computers continues to increase. Itis not rare to find a large-scale educational system that hasseveral thousands to several tens of thousands of studentsand several hundreds to several thousands of terminals.Generally, when the scale of the computer system is en-larged, administration and operation become more difficult.Consequently, a framework to support classrooms and ad-ministration is indispensable in such a large-scale educa-tional system.

Before this project was started, the Osaka UniversityInformation Processing Education Center included a class-room support system for each computer update in its speci-fications, and the industry responded. The newlyintroduced system operated effectively at the beginning, butvarious problems were soon discovered. It is quite naturalthat with system requirements always changing, the neces-sary resources to meet the requirements are not available,or the center is not authorized to modify the system. Con-sequently, only unsatisfactory classroom support systemshave been introduced to date.

Furthermore, the classroom support systems gener-ally found on the market include only CAI components,such as functions for the management of learning historyor the evaluation of test results, while there are no functionsfor supporting the operation of the whole computer system,such as the display of message on all user terminals, notonly for the students in the classroom, but also for voluntaryusers, or for the acquisition and management of the usehistory of each terminal [1, 6, 7]. The recent classroomsupport systems on the market have built-in functions forterminal locking and the presentation/collection of reports,but these functions were not provided in the early stage [8].

In this context, the authors decided to design anddevelop by themselves a system (called Ocean) to supportboth classroom activities and administration on the occa-sion of an equipment update in 1996 [2–4]. The designgoals were set as follows. The classroom and the admini-stration support functions were to be kept to a minimum,and to be made as machine-independent as possible. Thesystem should have scalability, allowing it to be used at anysize of university in Japan. The system should be con-structed in as short a period as possible. This paper de-scribes in detail the problems encountered in achievingthese goals and their solutions. The resulting system hasbeen operated in the Information Processing EducationCenter at Osaka University, and has contributed greatly tothe support of classroom activities and administration.

In the following, Section 2 outlines the classroom andadministration support system. The design principles aredescribed, together with the problems to be solved. Sections3 and 4 describe in detail the implementations of the class-room and administration support server and the client ap-

plications in the system. Section 5 discusses the extent towhich the design goals were achieved.

2. Design of Classroom and AdministrationSupport System

2.1. Outline of system

This study describes the design of a classroom andadministration support system which can handle an educa-tional system with several thousands to several tens ofthousands of users and several hundreds to several thou-sands of computer terminals.†

As regards administration support, only items inher-ent to education are considered in this paper. General sys-tem backup, version upgrading, and the like are notconsidered. References 5 and 9 should be consulted regard-ing manpower saving in version upgrading and reinstalloperations.

Based on past experience in the design of classroomsupport systems at the Osaka University Information Proc-essing Education Center, the minimum required functionsfor classroom and administration support were extracted.The functions were broadly classified into the functionssupporting the teacher, functions supporting the student,and functions supporting the administrator (Table 1).

2.2. Design principles

The system was designed on the basis of the follow-ing principles.

(1) Independence of system environment

The system should be designed to be independent ofthe hardware and of the environment, such as the OS, as faras possible. The major services of the proposed systemshould be based on the server–client model. Functionswhich are inevitably OS dependent, such as the acquisitionof information needed in the management of the attendancedata and management of the use of each terminal (i.e., theuser information during login), are separated as auxiliaryserver functions (Fig. 1).

The server (called the mix server) contains the data-base (mixDB) for classroom and administration support,and a set of database access functions (mixLib) is provided.The client can obtain service from the server by calling theaccess functions. Communication by TCP/IP is assumedbetween the client and server. The implementation environ-ment is not restricted, so long as the above conditions aresatisfied.

†The system can of course also handle a small-scale system with severaltens of terminals.

43

The functions shown in Table 1 are not always real-ized by using only the tools in Fig. 1; some are realized asseparate tools (see Section 4).

(2) Scalability

In contrast to, for example, an enterprise informationprocessing system, the use of computer systems in theclassroom has the feature that a large number of terminalsreceive logins or make access to mail at almost the sametime. Thus, there is a danger that access will be concentratedon a particular service or server, making it impossible toprovide an adequate response. In particular, careful designis required when there is a large number of clients. Individ-ual problems are discussed in the section on implementa-tion.

(3) Reduction of development period

It is very important to realize the required functionsas quickly as possible. Delay in realization causes large

losses. In fact, one of the specified goals was to provide thefunctions needed in the classroom at the time of equipmentupdate, and there was not much time to spare. Conse-quently, steps were taken in the design of the database andin the implementation procedure so that operation could bestarted without waiting for the preparation of all functions.

As discussed in the previous section, existing soft-ware rarely can be utilized for classroom or administrationsupport. Customization is required in most cases, and thecost is not small. In addition, numerous corrections andimprovements are usually required after starting operation.Consequently, it is very significant in this kind of supportsystem that the source code is made publicly available. Itwas decided that the source code of this system would beprovided as open software.

3. Realization of Classroom andAdministration Support Server

3.1. Design of database

The information needed for classroom and admini-stration support is retained in the mixDB of the servercomputer. The mixDB is based on an ordinary file system,rather than using a commercial database management sys-tem. This is partly because of budget constraints, but wasalso a decision related to publicizing the whole system asfree software.

Data are essentially handled with the file as the unit.The document information “Notice from center,” for exam-ple, is identified by the name “/global/information”.

The data handled by mixDB are integrated into thetext data. When a structured data item is to be stored, eachrow is defined as a record and the fields are TAB-delimited.

Table 1. Functions for supporting classroom and administration

For teacher Student registration function Register/delete of student in each class

Presence/absence management function Display of presence/absence data of student in each class

Assignment presentation function Presentation of assignment for report, etc.

Report collection function Collection of reports and statistics of presentation status

Terminal lock function Forced inhibition of use of terminal

For student Assignment referral function Refer of registered class assignment

Report submission function Submission of report for assignment

For manager User registration function Integrated and sequential register/delete of users

Class registration function Registration of class hours, classroom and teacher in chargefor each class

Use statistics function Summary of usage of terminals and printers

Message presentation function Forced display of message from teacher

Fig. 1. System configuration.

44

Owing to the use of this structure, the data can be completedmanually by using a text editor before the data generationtool is constructed, which helps in debugging and the like.

3.1.1. Provision for data preservation

As discussed above, the data are stored on the mixserver as individual files. The reason is to minimize theimpact of destruction of data by accidents such as faultyclient applications. The details are described below.

The mix server process runs in a nonprivileged userspace called mixadmin. Files for which no modification isnecessary are owned by root in order to prevent erroneousrewriting by mixadmin, which has no write privileges. Thiskind of file is written by the management tool whichdirectly operates the server file system, without passingthrough the mix server. The files are composed so thatadditions or modifications are avoided so far as possible.The lecture schedule data, for example, are stored as anindividual file for each lecture. Thus, even if lecture contentis added or a manipulation error occurs during a semester,the existing lecture-related data are kept secure.

For data which must be written from the client appli-cation, the file is structured as follows. The part of the datawhich is to be prepared by the system, and the part of thedata which is to be written by the application, are separatedinto different files. The attendance data, for example, aregenerated from the login/logout time record. In addition,the attendance statistics can be overwritten by decision ofthe teacher in order to deal with transport strikes or absencebecause of illness. In such a case, the attendance correctioninformation for each lecture is preserved in a separate filefrom the attendance data generated from the login/logouttimes.

3.1.2. User information

The content of the registered user list for the com-puter (the “passwd” file in UNIX) and the login name differfrom system to system. In addition, the names in kanji formof the students belonging to each faculty and departmentand their dates of admission are not stored in the passwdfile. Consequently, they must be handled in the mixDB.

To deal with this point, the internal representation ofusers in the system, such as the user ID, is not handled inthe mixDB; a user information database is prepared withthe login name as the key. This database stores the loginname, the faculty and department affiliation, the year ofadmission, the name and ID number of the student, and thedate of registration verification. Addition, updating, or de-letion of this information is performed by using the userregistration tool.

3.1.3. User authentication

The user names of the teachers (login names) areregistered in the mixDB by using the class registrationfunction shown in Table 1. Consequently, even if a studentstarts the teacher GUI tool (see Section 4.1.1), the informa-tion on the teacher is not displayed. This is the result of userauthentication in mix server, which is designed to preventstudents from pretending to be the teacher. More precisely,the procedure is as follows. The terminal at the center isverified by using the IP address. Then, the user name isexamined by accessing the ident service of the terminal(RFC1413). This user authentication scheme prevents ateacher from seeing or editing the data display of anotherteacher’s classroom.

3.1.4. Attendance data

In this system, the login/logout time of each terminalis collected in the server and is compared with the lectureschedule to construct the attendance data. The schemedepends on the individual system and is constructed as anindependent system; the data obtained by processing arestored in the mixDB.

However, the following problem arises. If the finalattendance data, as displayed in GUI tool of the teacher, areconstructed from the login/logout record and stored in amixDB, a student who was present but has not yet beenincluded in the presenter’s list will be dropped. Further-more, if the list of login/logout sequences is simply regis-tered in the mixDB, the amount of data becomestremendous, which may degrade the response time of theattendance display function. Consequently, the data at theintermediate stage are registered in the minDB.

The basic attendance data are stored in the minDB asindependent files for each date, classroom, and school hour.These files contain the login records of all users who loggedin at a classroom terminal in the class hour. The details ofthe file record are omitted in this paper, but the file isdesigned so that the system can handle cases such as achange of terminal by a student or duplicated logins.

The teacher’s GUI tool extracts only the registeredstudents from the basic attendance data. The attendanceinformation is constructed dynamically each time, based onthe attendance threshold specified by the teacher (which isthe ratio of the time logged in to the total length of the classperiod which will be considered as having attended; thisitem can be set flexibly at the option of the teacher).

3.2. Communication library (mixLib)

Table 2 shows the set of functions used for access tothe minDB. Considering efficiency in constructing clientapplications, the specifications are defined to be as similar

45

to those of UNIX file access functions as possible. It ispossible, for example, to get the file descriptor withmix_open and to read the data by a read system call. Or, itis possible to acquire a buffered file pointer by usingfdopen, and to read the data by means of fscanf or getc.

When a “Notice from Center” is to be displayed inthe terminal, the tool can be described as follows:

In mixLib, a copy is sent from the mixDB to the localdisk when the file is opened, and the file descriptor of thecopy is returned. As a result, the server is not burdened nomatter how many times the file is accessed by using Iseek,etc. In data registration or modification in the mixDB, thecopy or append function shown in Table 2 is used.

The data registered in the mixDB ranges from severalhundreds of bytes to several kilobytes at most, except foruser data files and teaching materials.

The size of teaching materials can be several mega-bytes. It is of a nature such that all the data must be copiedat once and passed to the student on the client side. Theserver is less heavily burdened compared with a protocol inwhich the data are divided and transferred multiple times.Teaching material of large size which will burden the clientmachine if stored in the working file is refused registrationby the teacher’s GUI tool. The system is designed so thatthe user data file is not copied to the local disk, and only thenecessary partial information is transferred to the client sideby using a dedicated retrieval function.

3.3. Auxiliary systems

3.3.1. The terminal usage data collectionprogram

In the proposed system, NextStep 3.3J is used as theOS of the user terminal computers. Consequently, wtmpdata with 4.3BSD compatibility are stored in each terminalcomputer (/usr/adm/wtmp).

The tool consists of a program to collect wtmp datafor the mixDB and a manipulation program which proc-esses the wtmp data to extract the attendance data.

In each terminal computer, the program that extractsthe increment of wtmp is started at each hour (only indaytime) and the results are uploaded to the server. Theprogram also uploads the time-stamp of the final record, inaddition to the increment data of wtmp. At start-up of theprogram, the server is queried and the previous time-stampis obtained. Consequently, if transmission fails, such as dueto a fault in the network, the increment from the previoustransmission success, not from the data one hour before, issent. In order to handle partial failures in uploading, theupload to the server is performed under a different filename, and the file is renamed when the upload succeeds.Due to this mechanism, the manipulation program neveraccesses a file to which a terminal is writing.

The manipulation program manipulates the data onthe server computer once a day, at night when wtmp dataare not being transmitted from the terminal computer. Theprogram examines the increment of the wtmp data from theprevious processing and its relation to the final output. Evenif wtmp data for several days are uploaded from a terminalwhich has been stopped due to a failure, the manipulationprocessing is performed correctly.

3.3.2. Printer usage data collection program

Statistics on printer users are recorded in the terminalcomputers to which the printer is connected. The collection

Table 2. mixLib functions

mix_start initialize

mix_open open file

mix_1stat search file/directory of server

mix_creat construct file

mix_delete delete file

mix_mkdir construct directory

mix_rmdir delete directory (recursive delete ispossible)

mix_append_line add a line to file (only text string)

mix_copy_file copy local file to server

mix_append_file add local file to server file

mix_getuinfo acquire information of specifieduser

mix_setuinfoent set condition for user data retrieval

mix_getuinfoent derive a user data meetingcondition set by mix_setuinfoent

mix_enduinfoent end search of user information

mix_db_creat construct BTREE database

mix_db_get take out a record meeting key

mix_db_put store record in BTREE database

mix_db_delete delete record

mix_db_open open existing BTREE database

46

program collects statistical data early in the morning andstores the data in the mixDB.

4. Client Applications

4.1. Teacher tools

4.1.1. The teacher’s GUI tools

Figure 2 shows the GUI tools for the teacher devel-oped in NextStep 3.3J. When a lecture is selected in thelecture selection window (upper left of screen) the mainwindow appears (upper right of screen). This tool canperform student registration, lecture announcements, thereport collection, and the attendance management. Thelower-right window of the screen is used to register stu-dents. Registration is performed by simply selecting thestudent from the list of all students. The lower-left windowof the screen is used for attendance management. Theattendance list of registered students can be displayed, andthe data are preserved in a file.

4.1.2. Terminal locking tool

It often happens in a class with an exercise that astudent concentrates on terminal operation and does notlisten to the lecture. It is convenient in such a case to lockthe operation of the student terminals and to interrupt thestudent operations. The terminal lock tool interrupts opera-tion by the student by forced display of the same windowat full screen size on all terminals. This window mayinclude a warning message to the student.

The problem then arises that Windows systems havean authentication function, and it can happen that the startedGUI application cannot be displayed on the screen, evenwith system privileges. In order to solve this problem, theterminal side generates a process at the time of login, whichwaits for display commands in the background, and retainsthe process until logout. This monitoring process operateswith root privilege, and cannot be forced to stop by, say, akill command by an ordinary user. On the other hand, sinceit is started as a part of the login process, the accessprivileges to the window system are retained.

The monitoring program runs a tool for messagedisplay by command from the server computer. However,if this command is given by TCP, a problem arises. Inmanagement of the system, the message must be sent to all

Fig. 2. GUI tool for teachers.

47

terminals. If TCP connections are established from theserver to several hundred clients, a considerable burdenresults. Furthermore, when a TCP connection is set up fromthe server side, as in this tool, a different local port numbermust be used for each connection. However, it is not desir-able to use a large number of privileged ports for a singleservice. Furthermore, when a TCP connection is to be setup with a terminal which has stopped due to a fault, etc., atime-out process is required. A considerable time is neededin order to consider such a situation and to generate severalhundred TCP connections in succession.

Consequently, in this tool the message is transmittedfrom a single socket to the necessary terminals by usingUDP. To deal with packet loss, the server side sends thepacket containing the message iteratively at a constantinterval. The packet indicating termination of the display isalso set twice with an interval of several seconds. From thefail-safe viewpoint, the display at the terminal is terminatedafter a certain period of time even if the packet indicatingdisplay termination does not arrive.

4.2. The student tool

Figure 3 shows the student GUI tool. The student canread comments from the teacher, receive teaching materials,and present corresponding reports. The reports can be pre-sented in any format or number, so long as they are pre-served as files. It is also possible to present several files ina folder.

4.3. The management tools

The management tools are a set of GUI commandsrun on the server. The manager can use these tools byremote login to the server.

4.3.1. The user registration tool

Two user registration tools are provided. The inte-grated registration tool generates and registers a login nameand the password from the data of an admitted student. Thesequential registration tool handles additional registration.These tools perform their processing functions in an inte-grated way, including the registration of UNIX user ac-counts with NIS, construction of the home directory andsetting of the disk quota, in addition to the registration ofstudent data in the mixDB.

As regards the modification of registered content,capabilities for modification of passwords, processing tohandle changes of faculty/department, and extension of theperiod of use (within the same school year) are provided.

4.3.2. The classroom registration tool

As regards the registration of classroom data in themixDB, integrated registration and the additional registra-tion are possible from a text file list containing the classcode, the class name, the login name of the teacher incharge, the cognizant faculty, the class hour, and the class-room.

4.3.3. The usage statistics tool

The usage status data for terminals and printers whichare stored in the mixDB can be summarized as a diagramor a table by using the usage statistics tool. This tool makesit possible to specify in detail the range of statistics, suchas the classroom, the time period, and the cognizant fac-ulty/department of the user.

4.3.4. The message display tool

A message which must be transmitted securely to theuser, such as a temporary change of the working period ofthe center, is displayed at the time of login by a panel witha verification button.

The tool displays the specified message in the win-dow at the time of login. From one to three buttons can beincluded, and other automatic start-up applications are kept

Fig. 3. GUI tool for students.

48

waiting until the buttons are clicked. When the terminalcannot be used because of maintenance operations, a mes-sage to that effect is displayed and the logout is performedby pressing the button. It is also possible to assign a buttonto start another application. This function is utilized in theprocess in which a WWW browser is started to display aquestionnaire page, to which the user is requested to re-spond.

In this tool the host name or login name may also bebuilt into the start conditions, so that the message is dis-played only in some classrooms, or the display is not shownto center personnel.

5. Discussion

Below we discuss how well the system satisfies eachof the design principles described in Section 2.

5.1. Independence of system environment

The mix server was implemented in Sony NEWS OS4.2.1a+. Except for some functions of the auxiliary system(such as the terminal usage data collection function), thereis little OS dependence. Consequently, the system shouldbe able to operate directly with almost all UNIX flavors. Inaddition, the system should operate with little modificationon any OS with POSIX system calls and Berkeley sockets.

The communication protocol between the server andclient uses text-based commands in TCP with three-digitnumeral response codes, as in smtp and ftp. Communica-tions can be performed without problems even if the byteorder is different between the server and the client.

Since the ident service is used in user authentication,a controllable multiuser OS must be used on the terminalside, so that the ordinary users cannot use the privilegedports. Consequently, when an OS such as Windows 95 or98 is used in the terminal, modification is needed so that theuser must input his or her account name and password.

The client was implemented in NEXTSTEP, sincemixLib performs only TCP/IP communication with the mixserver. In addition, it is written in C, assuring good portabil-ity.

5.2. Scalability

The mix server runs on a Sony NEWS5900 (MIPSR4400/200 MHz) with 512 Mbyte of main memory, whichacts as the file server and NIS master server. There are 600clients, with Sony QL50N (Pentium 75 MHz, 32-Mbytememory) machines as the core.

The system was designed carefully so as to assuresufficient response performance even if a large number of

clients make accesses at the same time. However, the fol-lowing problem arose.

During a lecture, when many instances of the studentGUI tool are run at the same time, the response from theserver was sometimes lost, or server processing occupiesalmost 100% of the CPU cycles, degrading the NFS per-formance of the server. This phenomenon tends to occurwhen the number of concurrent users is increased. As atemporary measure it is suggested that concurrent use beavoided during lectures. In the meantime, the cause of thetrouble has been investigated.

The cause of the trouble was the scheduler that han-dles communications with multiple network connectionswithin the server process. In some situations a state occursin which service is not provided to a socket with data arrival,or in which the system does not wait when it should, butenters the busy wait state. The problem was solved by a fixin the scheduler, and the load of the mix server process(CPU time) was lowered to approximately 1/100 of the NFSdaemon load.

The number of clients that can be connected concur-rently to the mix server is limited by the maximum numberof file descriptors per process. When the number of connec-tion requests exceeds the limit during performance, thesystem hangs up. Consequently, when the number of re-quests approaches the limit of the number of file descrip-tors, the proposed system temporarily stops receiving newconnection requests. Then, although connection waitingoccurs in the client application, a server crash due to over-loading can be avoided.

To use the proposed scheme in a larger-scale systemthan in this center, it is necessary to solve the concurrentconnection problem. One possibility is to increase the num-ber of servers, which, however, will increase the systemload. Even if the number of connections per server processis reduced, there remains the problem that the number ofactive TCP connections in the whole system will be in-creased.

A powerful server machine that can handle severalthousands of TCP connections is available, although itrequires a considerable cost. Consequently, a solution tothis problem is to change the structure to the UDP protocolwith packetwise authentication. In the UDP program, reli-ability is not guaranteed in general, but sufficient perform-ance and reliability can be realized by the combined use ofa simple retry, as in NFS implemented by using UDP.

5.3. Reduction of the development period

Steps were taken to allow the classroom supportserver and the client application to be constructed in paral-lel, so that the service could be started quickly.

49

The usual approach in the development of this kindof remote service is to determine the communications pro-tocol, and then to develop the server and the client (inde-pendently). In this system, in contrast, the specifications ofmixLib were defined as the first step. In addition, thedeveloping engineer of the mix server also developed mix-Lib. This arrangement allowed the set of tools to be devel-oped in parallel to the development of the communicationsprotocol. It was not necessary to modify the set of toolswhen the communication protocol was modified, since thespecifications of mixLib were already fixed.

The data access model in mixLib is the same as inUNIX file access in order to make communications trans-parent to the tool programmer. By this arrangement, theamount of knowledge required in developing the set of usertools was reduced, which contributed to early realization ofthe classroom and administration support system.

Also as a consequence of the use of the file accessmodel, a development substitute library was constructed inwhich the local file system was accessed instead of com-munication with the mix server. Using the substitute library,the set of user tools could be developed and debuggedwithout waiting for detailed design and development of themix server and mixLib.

An additional advantage was that, in case of trouble,it was easy to determine whether the bug was in the mixserver/mixLib or in the user tool itself, which contributedto the early realization of the system.

Data such as user data, for which quick retrieval isimportant, were transferred in the course of development toa Btree database with higher speed. Such a modification ofthe system can easily be absorbed in mixLib, making itpossible to deal with version upgrading of the server bysimply recompiling and relinking the user tools.

6. Conclusions

This paper has described the design and implementa-tion of a classroom and administration support system inthe educational computer system of the Osaka UniversityInformation Processing Education Center. Problems whichmust be considered in the classroom and administrationsupport system for a large-scale educational system havebeen discussed in detail, and methods of solution have beenpresented. Approximately a year was spent in constructingthe system, with the collaboration of several student volun-teers in addition to the authors.

Acknowledgments. The authors thank the follow-ing student volunteers for their collaboration in program-ming: Mr. Y. Masuda, Mr. M. Baba, Mr. M. Kakiuchi, Mr.H. Niiho, Mr. H. Tomita, Mr. T. Nagai, Mr. I. Nakahashi,Mr. M. Ito, Mr. M. Yasugi, Miss A. Mitsuta, Mr. T. Yahata,Mr. Y. Yanagisawa, Mr. T. Shiroyama, Mr. T. Namba, Mr.K. Fukuda, and Mr. H. Ikemoto.

REFERENCES

1. Hagiwara T, Yamaguchi H, Nishio S. An educationalcomputer system based on NeXT computers at OsakaUniversity. Bit 1992;24:(4).

2. Saitoh A, Harada A, Yamai N, Baba K, Yasutome S,Matsuura T. Present status and prospects of admini-stration and classroom support systems in educa-tional computer system. Tech Rep Inf Process Soc,Distributed System Operation Tech, DSM-9501031,p 278–285, 1995.

3. Matsuura T, Saitoh A, Harada A, Shigehiro Y, BabaK, Yasutome S, Yamai N, Nakanishi M. A new class-room support system at the Osaka University Infor-mation Processing Education Center. Proc StudyMeeting Inf Process Education, Dec. 1995, p 213–216.

4. Saitoh A, Yasutome S, Baba K, Shigehiro Y, NishidaT, Nakanishi M, Harada A, Yamai N, Matsuura T.Functions and realization of the Ocean classroomsupport system. Tech Rep Inf Process Soc DistributedSystem Operation Tech, 96-DSM-4, p 43–48, 1996.

5. Saitoh A, Nakanishi M, Yasutome S, Shigehiro Y,Nishida T, Baba K, Abes H, Matsuura T. A method ofmanpower saving on system administration in a com-puter environment for a large number of students.Tech Rep Inf Process Soc Distributed System Opera-tion Tech, 97-DSM-2, p 61–66, 1997.

6. Possibility of learning space R2.0. Lotus NotesMagazine, July 1998, p 90–96, Softbank Co.

7. CAMPUSsurf catalog. NTT Software Co., Sept.1998.

8. CAMPUS ESPer version 5.1 catalog. CompacqComputer Co., Aug. 2000.

9. Saitoh A. A manpower saving method in the admini-stration of large-scale educational computer systems.Trans Inf Process Soc 2000;41:3198–3207.

50

AUTHORS (from left to right)

Akinori Saitoh (member) received his B.S. degree from the Department of Information Science, Osaka University, in1986, completed the doctoral program in 1991, and became a research associate there. He has been a lecturer in the GraduateSchool of Engineering Science since 1999. He is engaged in research on distributed system operation techniques, educationalengineering, and user interface. He holds a D.Eng. degree, and is a member of the Information Processing Society.

Tomohiro Nishida (member) received his B.S. degree from the Department of Information Science, Osaka University,in 1991. Before completion of the second half of the doctoral program, he became a research associate at the InformationProcessing Education Center in 1996. He has been a lecturer at Osaka Gakuin University since 2000. He is chiefly engaged inresearch on education and human interface using computers. He is a member of ACM and the Information Processing Society.

Michio Nakanishi (member) received his B.S. degree from the Department of Information Science, Osaka University in1978, completed the M.E. program in 1980, and joined Mitsubishi Electric Corporation. He was chiefly engaged in developmentof a general-purpose computer OS at the Computer Works. He moved to Osaka University in 1990, and has been an associateprofessor at the Cybermedia Center since 2000. He is engaged in research on databases, bioinformation processing, andeducation on information processing. He holds a D.Eng. degree, and is a member of AACE, the Information Processing Society,and the Educational Systems Information Society.

Seigo Yasutome (member) received his B.S. degree from the Department of Information Science, Tokushima University,in 1987, completed the doctoral program in 1993, and became a research associate at the Processing Education Center. He hasbeen an associate professor on the Faculty of Business Administration, Southern Osaka University, since 1998. He is engagedin research on computational geometry. He holds a D.Eng. degree, and is a member of IEEE-CS, ACM, and the InformationProcessing Society.

Ken-ichi Baba (member) received his B.S. degree from the Department of Information Science, Osaka University, in1990 and completed the first half of the doctoral program. Before completion of the second half he became a research associatein the Information Processing Education Center. After serving as a lecturer at Kochi Institute of Technology, he moved to OsakaUniversity and has been an associate professor in the Cybermedia Center since 2000. He is engaged in research on wide-areacommunication networks, computer networks, and photonic networks. He holds a D.Eng. degree.

Yuji Shigehiro (member) received his B.S. degree from the Department of Electronic Engineering, Osaka University, in1987. Before completing the second half of the doctoral program he became a research associate in the Department of ElectricalEngineering, Osaka Institute of Technology. He has been engaged in research on automation of VLSI design, informationprocessing education, and optimization algorithms. He is a member of IEEE, the Information Processing Society, the Societyof Electronic Implementation, the Society of Instrument and Control Engineers, and IEEJ.

51

AUTHORS (continued) (from left to right)

Akira Harada (member) received his B.S. degree from the Faculty of Human Science, Osaka University, in 1992,completed the first half of the doctoral program in 1994, and became a research associate at the Information Processing EducationCenter. He has been a research associate on the Faculty of Human Science since 1996. He is engaged in research on musicpsychology, information processing education, and behavioral metrics. He is a member of the Japan Psychological Society, theInformation Processing Society, the Society for Cognitive Science, and the Society for Behavioral Metrics.

Nariyoshi Yamai (member) received his B.S. degree from the Department of Electronic Engineering, Osaka University,in 1984 and completed the first half of the doctoral program in 1986. Before completing the second half (physical science,information engineering) he became a research associate and subsequently a lecturer at Nara College of Technology. Afterserving as a research associate and lecturer at Osaka University, he has been an associate professor at the Information ProcessingCenter of Okayama University since 1997. He is engaged in research on distributed systems, multimedia systems, andmultimedia networks. He holds a D.Eng. degree, and is a member of IEEE and the Information Processing Society.

Toshio Matsuura (member) received his B.S. degree from the Department of Information Science, Osaka University, in1975. Before completing the second half of the doctoral program he became a research associate on the Faculty of EngineeringScience. He became an associate professor at the Information Processing Education Center in 1992. He has been a professor atOsaka City University since 1995. His research interests are user interface, multimedia, and information processing education.He holds a D.Eng. degree, and is a member of ACM, IEEE, and the Information Processing Society.

52