Operating System Simulation Developed as Homework

Operating System Simulation Developed as Homework | An Operating System Simulation Developed as Homework | An Operating System Simulation Developed as Homework Article | Artikel An Operating System Simulation Developed as Homework

Operating Systems I: An Operating System Simulation Developed as Homework

Dr. Ronald Marsh

Computer Science Department

University of North Dakota

Grand Forks, ND 58201

rmarsh@cs.und.edu

701-777-4013

Abstract

This paper describes the series of homework assignments made during the fall 2000 Operating Systems I course at the University of North Dakota as well as the authors experience in making the assignments. The purpose of the assignments was not only to provide the student with a good understanding of how an operating system is developed and operates, but also to reinforce some basic skills that all graduating computer science majors ought to possess.

Starting with a simple operating system simulation (one-queue round-robin CPU scheduler and one I/O queue) and progressing to a credit based priority CPU scheduler, multiple I/O queue, and page fault managing operating system simulation, the assignments mandated that the student develop a series of operating system simulations ranging in complexity.


Introduction

The primary intent of CSci-451 (Operating Systems I) at the University of North Dakota is to expose students to the fundamental theories behind operating systems. A secondary purpose is to further their development as systems analysts and improve their programming and debugging skills. CSci-451 is taught in the traditional manner - relying on a mixture of lectures, homework assignments, and tests.

In previous offerings of this course the homework assignments, while relating to operating systems concepts, were independent of each other. The author noticed two disturbing phenomena:

1. A number of students would simply ignore the more difficult assignments and count on the remaining assignments to maintain a passing grade in the course.
2. The student's systems analysis and design, programming, and debugging skills were not improving as much as expected (or desired).

A reoccurring theme in the columns in the various trade publications[1] as well as in the editorials and letters-to-the-editors in these same publications relates to the latter of the above. Namely, computer professionals are not receiving the training required to meet the demands of the current IT driven world. This is not a new revelation. Anyone who watches the evening news is well aware of the media attention that has been focused on the alleged failure of the American public school system and how American students have allegedly failed to master basic skills in reading, writing, arithmetic, and science. A more disturbing finding made in the early 90s was that few American students could use their knowledge effectively in thinking and reasoning[2]. It would appear that students simply memorize the material (the learning method they think they know best[3]) and fail to learn how to use complex reasoning skills to discover higher relationships. Most students master the material and do well in the course. However, it is also evident that a disconcerting number of students need to develop better design and debugging skills. The maxim “What you learn not only changes what you think about, but how you think.” could easily be applied to the IT profession. This author firmly believes in developing course materials that force the student to develop their design and debugging skills.

In an effort to reduce the occurrence of the phenomena listed above the decision was made to develop a series of assignments that would force to the student to build on previous assignments (admittedly, not a new idea). Since the class focuses on operating systems and since the best way to understand how something works is to build one, the assignments mandated that each student develop a series of operating system simulations ranging in complexity. The “trick” was to organize the development of the different operating system simulations such that poor programming practices or such that an initially poor design would haunt them (the student) for the rest of the semester and reinforce the precept of having a good design to start with.



Rules of The "Game"

As any educator knows, different students have different strengths and weaknesses and preferential ways of completing a task. Therefore, only a few ground rules were enforced regarding the simulation development:

• The development language was limited to C or C++.
• The simulation was required to run on the department's main UNIX cluster (Linux).
• Plagiarism was not allowed.
• Achive the goals as set forth in each assignment.

Otherwise, the students were allowed to:

• Use any data structures they desired.
• Use an object oriented design or not.
• Make use of the available queue libraries.
• Implement a simple time-keeping mechanism.
• Discuss implementation issues amongst themselves.

The above “rules” allowed the students to develop the simulation using methods/tools they felt comfortable with. Yet, forced them to understand the problem and devise an implementation providing a solution.

Read more...

PDF File: Operating Systems I: An Operating System Simulation Developed as Homework


If you want to read via Academia, click here..
If you want to read offline, click here..

Word File (translate in Bahasa - using software translation not manual translation, so not well): Sistem Operasi 1: Sebuah Simulasi Sistem Operasi yang dikembangkan sebagai pekerjaan rumah


If you want to read via Academia, click here..
If you want to read offline, click here..