Teaching Operating Systems
Through Role Play
And Textbook Authoring

Netiva Caftori
Computer Science department and Women Studies program
Northeastern Illinois University
5500 N. St Louis
Chicago, IL 60645

Track: Information Systems Curriculum


In this paper I describe a rather novel idea for teaching an operating-
systems course using role-play, class presentations, and textbook writing
by the students themselves.  The purpose was to stimulate students into
active participation and not mere absorption of the facts.

Keywords: Operating systems, role-play, textbook writing.
 Anyone who has ever had to teach an operating systems course probably
knows of the wide body of theory which traditionally is being passed on to
the students through lecturing.  As evidenced by much research (Bork,
Caftori, and Paprczki), lecturing is not pedagogically sound.  Involving
students actively has been proven to be a most effective learning and
teaching tool.
How does one keep students involved in a course that has so few
opportunities for exercise?  Fortunately the theory covers the behavior of
the various programs of the operating system, which include job
scheduling, memory, CPU, I/O (input/output), and file management.  All
these programs represent numerous components which are hard to keep track
of unless represented somehow graphically or physically.

Experiential Learning
Graphic representations appeal to many people who are visually oriented.
By physical involvement in learning I mean experiential learning, a
learning that is not soon forgotten.  A comparison can be made to learning
to bike.  Learning the theory behind biking will not advance one very far
as opposed to actually mounting the bike, pedaling and maybe falling a few
times.  Many of us use the expression "it's like riding a bike".  One does
not forget how to do it once one knows it, even after many years of not
riding.  If we carry this philosophy of experiential learning to the
classroom whenever possible, we can accomplish this rare achievement of
having students remember what they learn many months or years later.  Of
course we are talking here about cognitive learning and not only physical
exercise, however since the life of a job resembles the life of a human,
we may learn by analogy.

Role Play
The idea was to give each student a part in a "play" where the play is
about processing jobs.  The stage, or the center of the classroom,
represents the internal memory of the computer.  Depending on the number
of students, as few as five, and as many as a couple dozens can easily
accommodate many situations.  Students in excess of the players are part
of the audience.  By observing their friends act, they learn too and
provide an additional incentive to the players to better perform.
An area is designated for the input queue, and students representing
waiting jobs line up there even in their seats.  The actor representing
the operating system may designate helpers, or routines, to help him or
her to carry on the task of the overall management.  An
initiator/terminator routine for example, will load the first job off the
input queue into internal memory, or center stage.  There too we will have
a line of waiting processes, a ready queue.  The CPU (Central Processing
Unit) may be one (or more, in a multiprocessing environment) person who
can process one process at a time.  Representing processing may be done in
several diverse formats:

Examples of Scenarios
· One way is to represent the CPU as a cashier at a cash register in a
store, and a process as a person purchasing groceries.  The operating
system is the store manager orchestrating most of the comings and goings.
Customers line up at the cashier as a ready queue.  Whenever a request for
a price check or a special item is made, the cashier has to stop entering
data (interrupt) and the purchaser needs to wait for a search (or I/O) by
a clerk or I/O routine.  If it's at the deli counter, the customer may
need to take a number and wait for the I/O device.  Once the item or the
price check is obtained the purchaser is back at the ready queue waiting
for the cashier/CPU to process him/her again.  If all items are finally
entered by the cashier and the bill is paid, the customer/process may
leave (is terminated) the store.  Since room in the store is limited a
long-term scheduler may be at the door letting in new customers as old
customers leave.
· Another popular scenario chosen by my students is at a restaurant.
Different parties of people are in line to be seated.  The host/ess, or
the operating systems long-term scheduler, sits each down, as tables of
different sizes become available.  Once seated (in the ready queue) the
patrons are waiting to be served by the waiter or waitress (the CPU).  The
CPU will take their order (execute) after first offering the menu, water,
and drinks being interrupted throughout.  The waiter or waitress can serve
only one table at a time.  Other tables are then waiting for the
CPU/waiter (ready queue) or waiting for I/O (food, drinks).  Once a party
finishes eating, the host/ess (terminator part of the operating systems)
takes their money and greets them farewell (termination).  It seems to be
faster to have smaller parties with smaller demand for food (I/o-bound
jobs versus CPU-bound jobs).
· A traffic situation is fairly common: A cop is placed in a busy
intersection (maybe a six-way).  Big trucks may be compared to CPU-bound
jobs, and sport cars likened to I/O-bound jobs.  The cop has to alternate
between them so the traffic will flow smoothly.  Red lights mean the time
slice is over.
· Another scenario is of a tutor (CPU) who can only tutor one student at a
time.  Since s/he is very efficient s/he gives her students exercises
(I/O) so that s/he can take care of the next student, and keep the room
full of students at various stages of progress.
· The tutor example leads to a very convenient example for Round Robin
scheduling: A professor's office hour where each student gets attention
for only two minutes of a time quantum before the student needs to go back
to the end of the waiting line outside the office.  A difficulty with RR
that my students encountered was that from a table given on paper, as in
table 1; they could not place the end of the line easily:
(See Table 1 in the appendix).

See also the corresponding Gantt chart in Table 2:

Very commonly however, before role-playing was ever introduced, my
students produced an erroneous Gantt chart as in Table 3:
A more elaborate arrival-time table, such as in table 4, can help lead to
the correct solution.  However role-playing was found to be the most

More examples:
I keep being surprised by innovative scenarios suggested by my students:
One such scenario is situated in the chemistry lab where the Bunsen burner
is the CPU and the test tubes with water in them are the processes.  Most
other examples bring up normal life situations that we encounter daily
where the management and the scheduling of activities are involved.
Examples abound and range from the lawyer's office, bank teller, mother's
day, to the US immigration office and the car-repair garage.
Multiple-queues algorithms can be nicely demonstrated by an airline
check-in counter where first-class customers get privileged service while
their counterparts stand in another line.
Deadlock prevention and avoidance can also be easily demonstrated through
examples of children fighting over toys, gridlock in traffic, and more.

Textbook writing:
At ISECON '98, we learned that students in a systems analysis course wrote
a successful textbook.  As of the writing of this paper, the same idea is
used in my current operating systems class.  I adopted this ingenious
idea, as I've been dissatisfied with our current textbook, which is the
best available so far.
Northeastern Illinois University is known nationally as the most
ethnically diverse campus in the US.  Many of my students are new
immigrants whose mastery of the English language is very poor.  Students
self chose the chapters they wanted to cover and divided into teams
accordingly all in making sure one amongst them has a good control of the
English language.  Six students (out of a total of 37) volunteered to be
on the editorial staff.  They will review the written chapters.

Class presentations:
One final chapter of the textbook is dedicated to the diverse operating
systems currently or previously available on the market.  Operating
systems teams have worked since the beginning of the semester on a class
presentation about particular operating systems and for the final chapter.
In the past these class presentations have been the most applauded by the
students judging by their anonymous evaluations.  Students have enjoyed
seeing their peers present and learn about all the operating systems they
constantly keep hearing about in the media.  An extra motivator for good
attendance at these presentations is the requirement to turn in summaries.

Future teaching:
I agree with Paulo Freire describing the current learning situation:  
"Education thus becomes an act of depositing, in which the students are
the depositories and the teacher is the depositor.  Instead of
communicating, the teacher issues communiqués and makes deposits which the
students patiently receive, memorize, and repeat."  (Freire, 1993)
I would like to believe that this is not the situation of my class.  In
this course I attempted to involve the students physically as well as
academically.  These students will retain more from this course than their
predecessors just for this reason.  Although students evaluate the course
at the end of the semester only, their enthusiasm is shown more than in a
traditional class and provides me with encouragement.  In the future I
will have the students prepare scenarios in small teams to be presented to
the entire class and possibly involving more people from the audience in
order to convey their idea.  It's by working together that learning can
take shape and become a reality.

Active participation by students in learning has always been a primary
motivation for me.  Role-play happened to be a natural way for me to
visualize what was going on in the memory of the computer.  In the past I
have given examples to the students which helped some, but only when I
made the students act the examples up that I noticed real learning happen
on a larger scale.  I would like to hear from other educators who have
tried this strategy, and see if we together can improve teaching and
learning of operating systems.


Caftori, N. (1997):. Give up Your Pedestal, but Don't Give up Your Lesson
Plans, "CPSR Winter newsletter".

Bork, A.(1997): The Future of Computers and Learning, "T.H.E. Journal",
25th anniversary issue.
Freire, P. (1993): Pedagogy of the Oppressed, Seabury Press, NY.

Land, B.L. & Taylor, R. (1995): Planning and Creating Interactive,
Multimedia Lessons for Literature-Based Reading Programs. In D.A. Willis,
B. Robin, & J. Willis (Eds.), Technology and Teacher Education Annual,
1995 (pp. 336-340). Charlotleville, VA: Association for the Advancement of
Computing Education. 

Paprzycki, M. (1996): Computer literacy across curriculum. "Journal of
Computing in Small Colleges", 11 (7), 94103



Table 1:

Process	Arrival Time	Burst Time
A	0	5
B	1	4
C	3	3

Table 2:

Remain time	3	2	1	1	0	0	0
	Gantt	A	B	A	C	B	A	C
Time limits	0----2	2---4	4---6	6---8	8---10	10---11	11---12

Table 3:

Remain time	3	2	1	1	0	0	0
Gantt		A	B	C	A	B	C	A
Time limits	0----2	2----4	4----6	6----8	8----10	10---11	11---12

Table 4:

Process	Arrival-time	Remaining Burst time
A		0	5
B		1	4
A		2	3
C		3	3
B		4	2
A		6	1
C		8	1