Achieving Effective Learning Outcomes through the Use of Analogies in Teaching Computer Science ^†

Abstract

Analogy-based learning methods map the concept being learned to a concept well understood by the learner. An analogy is primarily useful when learners do not know the topic being studied. Computer science is an area where the concepts exhibit a high level of abstraction and, hence, are hard for students to comprehend. The use of analogies in instruction can significantly reduce the cognitive load a student faces in learning abstract computer science concepts. The role of analogies in helping students learn computer science topics has not been explored adequately. This paper presents our efforts related to using analogy-based teaching in computer science. Over the last several years, we have developed extensive analogies for many advanced computer science concepts. We have used these analogies extensively in classroom teaching at our institution. We list the analogies that we have developed and used in our classroom teaching and, as illustration, discuss two analogies: one from the field of operating systems and another one in modular software design. We have also conducted experiments to evaluate the impact of using these two analogies on student learning outcomes. Our results confirm our hypothesis that analogy-based instruction techniques are effective and result in improved student learning outcomes.

1. Introduction

Computer science (CS) is a subject that is hard to learn. Teaching computer science concepts effectively to undergraduate students is also a difficult task. There are two primary reasons why undergraduate students find computer science difficult to comprehend:

• Most students receive little or no exposure to computer science concepts during their pre-university education. Some students may acquire computer programming skills during high school, but even so, they will not be exposed to concepts such as how the internals of a compiler are organized or how an operating system works.
• Most computer science concepts are quite abstract. Computing essentially involves coming up with an abstract representation of the problem domain and then programming a solution based on this abstract representation. Students often struggle with abstract thinking as they are not accustomed to representing the concepts involved in a problem domain in computer memory, a fundamental aspect of computer science.

Through this paper, we demonstrate our dedicated efforts in effectively conveying abstract computer science concepts to undergraduate students by employing analogies [1]. We have used analogy-based teaching in the classroom for the last fourteen years for many advanced CS topics. By employing analogy-based teaching, we establish a mapping between abstract computer science concepts (target concepts) and familiar concrete concepts known to students (familiar concepts). This results in better understanding of the target concept. Analogy-based teaching results in better learning outcomes, as students learn by using their existing knowledge that comes from common daily life examples [2]. We have developed quite extensive analogies for CS concepts over the last 14 years. We have found that analogy-based teaching makes understanding of a concept easier for students. It significantly improves student learning outcomes. In this paper we present some of the analogies we have developed. We elaborate on two such analogies: one on the topic of process scheduling in a CPU, and another around modular software design. We present the results of our experimental evaluation as well.

2. Analogy-Based Instruction

Analogies play a significant role in various cognitive processes, such as “problem solving, decision making, argumentation, perception, generalization, creativity, invention, emotion, prediction, explanation, conceptualization and communication” [3]. This paper emphasizes the utilization of analogies as an effective means of communicating information related to computer science concepts. We follow structure-mapping theory [4] for our analogies. The theory describes how familiar knowledge about a base domain can be used to understand a less familiar or unfamiliar idea in the target domain. Structure-mapping theory has three components:

• Structure alignment, i.e., how closely do the base domain and the target domain match each other (a one-to-one correspondence is ideal).
• Analogical inference, i.e., an inference drawn in the base domain can be transferred to the target domain (e.g., narrow pipes will cause water flow to slow down, analogous to how increased resistance will cause electric current to be reduced).
• Evaluation, i.e., judging whether the analogy is relevant, plausible, and useful. The inferences drawn in the target domain should be factually correct, i.e., align with reality. They should be useful, i.e., they should provide insight in the target domain.

With the structural alignment theory in mind, we have designed many analogies for advanced computer science subjects in the last fourteen years. We observed that analogical teaching did generate effective learning in students. We developed several analogies in computer science, such as those in the following subjects, to name just a few: (a) parallel processing and pipelining in computer architecture; (b) virtual memory in operating systems; (c) processes in operating systems; (d) asymptotic notations in the analysis and design of algorithms; (e) Chomsky’s hierarchy in formal languages and automata theory; (f) lists, stacks, and several topics in data structures; (g) compilers, macros, and the OS in systems programming; (h) the design of the central processing unit (CPU), control unit (CU), and cache in computer architecture.

In SE (software engineering), we have also developed several analogies, the main ones being the following: (a) software maintenance and its analogy with maintaining a physical house; (b) coupling and cohesion in software modules explained through the analogy of a multi-semester degree program in a university; (c) levels of testing for a software system with the analogy of testing of computer chips; (d) the waterfall lifecycle model with a detailed analogy of constructing a house. We describe two analogies in this paper, one of them in detail.

3. Analogy-Based Teaching in Computer Science

Teaching advanced computer science topics to students is a challenging task. The problem is that students are not familiar with computer science concepts as they have likely not studied them before joining the university. Even if they had studied programming courses earlier, they would not have been exposed to computer science concepts such as formal languages and automata theory, operating systems, computer architecture, compilers, etc. Almost all students learn these concepts for the first time when they study these computer science courses in their university program. A good example of such concepts that are hard to understand is the concept of processes and process scheduling in operating systems. Additionally, several CS topics are abstract. This abstract nature of CS concepts makes it tough for students to grasp them when they face these concepts initially. A good pedagogical technique is to teach students by building upon their prior knowledge [5]. Due to the abstract nature of CS concepts, teaching students by building upon their prior knowledge becomes quite challenging, as their knowledge of advanced CS is minimal.

Thus, analogy-based instruction is particularly helpful for teaching computer science concepts to average students who may not yet have developed the mental ability to abstract complex concepts. Possessing the ability to understand abstract concepts and develop abstract mental models of complex concrete concepts is essential to being a proficient computer scientist. Analogy-based instruction helps beginner and intermediate students of computer science in developing the ability to abstract complex subjects and is important for producing better CS graduates. Our research indicates that learning outcomes for students become better when analogy-based teaching methods are used.

Research indicates that explaining abstract concepts through concrete representations and making a direct mapping between the abstract and the concrete assists students in grasping abstract topics much more easily. If abstract terms are used, then students have a hard time fully understanding the concept. Similarly, teaching a new concept in an exclusively concrete manner curtails students from developing their capacity to generalize and to be able to apply the concept to other similar contexts. To begin with, in computer science, most of the concepts are very abstract. For example, consider the concept of a process in an OS (this concept does not have a tangible or definitive representation). Resorting to analogies is the only way to achieve concretization. Hence, the challenge of teaching CS concepts to computer science undergraduates is solved by resorting to analogies. These analogies use common concepts that students know and to which they can easily relate. The advantage of using analogy has a strong foundation [6]. Employing analogies for teaching CS concepts has two major benefits:

• Abstract concepts are transformed into tangible or concrete forms, facilitating better comprehension for students. Since in computer science even concrete concepts are abstract, the utilization of analogies that link challenging concepts to familiar and concrete concepts in other areas significantly enhances the attainment of improved and effective learning outcomes. Research indicates that understanding abstract concepts directly is significantly harder [7].
• An analogy-based teaching method reinforces the pedagogical principle that a new concept should be taught by building upon existing knowledge that the student possesses related to that concept. Analogizing an abstract concept to a concrete concept taken from daily life allows students to understand new topics much more easily by building upon knowledge that they already possess.

4. Related Work

Analogical reasoning plays an important part in daily life when it comes to teaching, communication, and research [2,8]. Analogy has been extensively researched in cognitive science over the past two decades. Gentner developed the concept of structure mapping to explain the processes involved in analogical reasoning [4,9,10,11]. The analogies we developed use this structural-mapping theory.

A theory of teaching with analogies was developed by Glynn. He, along with his colleagues, created a six-step process of teaching with analogies [12]. These steps are as follows: (i) introduce the new topic (target) and provide some general knowledge on the subject; (ii) review the base concept; (iii) find relevant features within the analogy of the two concepts; (iv) find similarities between the base and target concepts; (v) draw a conclusion about the analogy and compare target and base concepts; and (vi) indicate where the analogy breaks down (if at all). Typically, Glynn’s method is applied to learn topics in science. We follow Glynn’s methodology in designing the analogies for the various computer science concepts. However, while developing our analogies, we invested significant effort to make sure that the analogies we develop work for the minutest details and do not break down.

Nokes. along with his fellow researchers, showed that analogies can be used to support collaborative learning, especially when conceptual understanding is essential [13,14]. Chang proposed an instructional comparison approach using an analogy tutor [15]. Chang’s goal was to use analogy to automate the process of conceptual learning in an AI system. In our work, we are interested in direct instruction and not collaborative learning. Chang’s method of formalizing analogy can help in designing new analogies. Ruef developed a method of teaching that uses analogies in the classroom to explain topics under the Private Eye Project [16]. Alizadeh et al. [17] have studied the role of analogies in the context of tutoring of students in data structures.

Lulis et al. also studied the use of analogies in tutoring sessions [18]. Likewise, Murray et al. developed an analogy-based computer tutor for remediating physics misconceptions [19]. Most uses of analogies for teaching CS topics are quite simple, e.g., explaining the concept of an input to a program as an ingredient in cooking a dish [20]. While these efforts are commendable, none of them focus directly on teaching advanced concepts in computer science. In contrast, our work uses direct analogies in the instruction process to teach advanced concepts in computer science.

Jiménez Toledo et al. extensively studied the use of analogies in the teaching of introductory computer science courses (CS1) [21]. They found that in developing analogies and employing them in such courses, professors included keywords that are typical of the terminology used in computational examples. Jiménez Toledo report that most of the analogies developed to describe CS1 concepts were in the form of verbs. Jimenez Toledo et al.’s insightful work can guide an instructor when developing effective analogies for teaching CS1 [21]. In contrast to Jiménez Toledo et al.’s work, our interest is in developing analogies for advanced concepts in computer science rather than an introductory computer science course. Strunz and Louie have used the analogy of data storage in computer engineering to teach the concept of electrical power storage to students [22], while Plapally has used psychological stress in humans as an analogy for illustrating stress-strain in metals to mechanical engineering majors [23].

We next illustrate a detailed analogy for the concept of process scheduling in operating systems. Here, we attempt to explain to the students how processes are scheduled on a CPU. The scheduling process is quite complex, as it involves the secondary memory (disk), the main memory, and the CPU. There is a short-term scheduler, a long-term scheduler, and a medium-term scheduler, all three of which work in tandem to produce optimal results. The concept of a process itself is quite abstract for new computer science students to understand, and their difficulty in understanding is further compounded by having to deal with the scheduling of these processes for execution on the CPU. Details of process scheduling can be found in any operating systems textbook, such as [24].

In addition, we provide an elaborate analogy for the topic of processes in an OS. Here, we impart knowledge to the student’s about how selected processes are moved from the hard disk to Random Access Memory (RAM) before then being scheduled by the CPU. Scheduling is a complex procedure, as it involves the hard disk, RAM, and the central processing unit (CPU). It also involves three types of schedulers: a short-term scheduler (STS), a medium-term scheduler (MTS), and a long-term scheduler (LTS). These schedulers work in a synchronized manner to produce desired results. Details of processes, process scheduling, and context switching can be found in any OS textbook [24].

5. Processes and Their Scheduling in Operating Systems

A program stored in secondary storage (say the hard disk of a laptop) is in a sleeping state until either the user activates it, or it is activated by the system, which is the moment when it changes to a process. For all such activated programs (processes), a job queue is created by the long-term scheduler scheduling all these active processes. Some of the processes move from hard disk to RAM and form a ready queue in RAM. The number of processes residing in the ready queue is decided by the degree of multiprogramming. While the processes wait in the ready queue, a short-term scheduler is activated which decides which process from the ready queue should be selected for execution by the CPU, and the CPU is then allocated to that process. With the generation of processes, a PCB (process control block) is generated for each process. A PCB contains several fields, and each field contains some information about that specific process. The main fields in a PCB (process control block) are (a) the program counter, (b) the process state, (c) CPU scheduling information, (d) CPU register values, (e) accounting information, (f) memory management information, and (g) input/ output status information. The short-term scheduler (STS) employs one of the following scheduling algorithms to schedule the processes waiting in the ready queue and hence selects a process for execution by the CPU. These algorithms are (a) FIFO (first-in-first-out), (b) SJF (shortest job first), (c) priority scheduling, (d) round robin scheduling, and (e) SRTF (shortest remaining time first).

The CPU executes a process until either an input/output for the process occurs, the process is interrupted by a higher priority process, or the process terminates. If input/output occurs for the process, the I/O processor carries it out. The various parameters (state, register values, memory bounds, etc.) of the process are saved in its PCB. The CPU is then given some other process from the ready queue by the short-term scheduler, and this whole process is known as “context switching”. Once the input/output (I/O) for the process is over, it returns to the ready queue and waits for its turn. The processes which are interrupted by the higher priority processes, after the execution of higher priority processes waiting in the ready queue, also stand in contention for the CPU. Some of the processes are partially executed, and because of their long input/output (I/O) they are swapped between RAM and the hard disk (secondary storage) and are temporarily not in competition for the CPU (i.e., not available in the ready queue in RAM). These processes are retrieved later from the RAM (and their execution starts from the point at which they had stopped for I/O) and are scheduled by a scheduler known as the medium-term scheduler.

When context switching occurs, the state of the running process (which is interrupted) is saved in its PCB and this PCB is saved onto the hard disk. The PCB of the process which is now scheduled to run on the CPU is loaded from the hard disk to RAM and this process starts executing. The time taken during this context switching is total overhead and does not contribute in any way to process execution time. Thus, this overhead should be minimized. If a process passes through all the states normally and terminates, its results are saved and are available for further use.

Next, we provide an analogy for CPU process scheduling using the analogy of a hospital or doctor’s clinic. The analogy is very close and is almost a one-to-one mapping between different attributes of the two domains. Note that to keep things simple, we only consider process management in a single CPU OS and provide an analogy for it. The analogy can be extended to accommodate multiple variations, e.g., for process management in a multiprocessor OS. Indeed, we have extended this analogy for a multiprocessor OS, a topic that we teach later in the OS course.

6. Analogy for Process Scheduling

We consider a HD (hard disk/secondary storage) to be like a residential colony in which people reside either in individual houses or apartments located within residential colonies. Each person is like a program, and when this person is unwell, they change to being a patient. At a specific moment of time, all patients call the hospital (OS), and a receptionist/manager at the reception (equivalent to a long-term Scheduler (LTS)) creates a list of all these patients (equivalent to a job queue) and schedules them. A file is created for each patient (equivalent to the process control block (PCB)) which has the patient’s ID (equivalent to a process ID), patient state (waiting for their turn, getting tests done, waiting on a bench, all equivalent to process states (i.e., new, suspended, waiting)), the patient’s meeting time with a doctor (value in the program counter), the patient’s previous illness records and history (equivalent to data stored in registers of the PCB), and the person’s current medical situation and current medication (equivalent to the data of files being used). Figure 1a,b illustrate one-to-one mapping of the PCB to a patient file. We consider a doctor as equivalent to the CPU, the front desk manager/receptionist as equivalent to the long-term scheduler, and a nurse/physician assistant equivalent to a short-term scheduler.

The receptionist/front desk manager (equivalent to the long-term scheduler) schedules some of the patients (processes) who arrive and wait on seats in the hospital waiting room. The count of patients scheduled for a session (morning, afternoon, evening), who are waiting on seats in the hospital lobby/waiting room, very much depends upon the number of patients the doctor can see during a session (comparable to the “degree of multiprogramming”). A nurse or a physician assistant (comparable to a short-term scheduler) responsible for scheduling the patients who are waiting for their turn to enter the doctor’s room has their own criteria (scheduling algorithm) for letting the patient’s go in the doctor’s chamber. These criteria can be first come first serve (FIFO) or organized on a priority basis (emergency patient) or decided by the shortest time requirement among patients (shortest job first, SJF) or follow round robin assignment (equal time to each patient). Patients may be directed to the back of the queue after a stipulated amount of time. A patient enters the chamber, and they are then examined and questioned by the doctor (the CPU running a process, or a process in the running state). The doctor (CPU) then cross-examines the patient and, with the help of the patient’s previous medical history in the patient file (process control block), thoroughly examines the patient (process in the running state). If, while examining this patient (process in the running state), another emergency patient (an accident case or a critically ill patient) arrives in the hospital (high-priority process) or a senior doctor calls this doctor (equivalent to an interrupt by the OS), this current patient (process) is asked by the doctor to return to and wait in the lobby/waiting room (process interrupted, waits in ready queue). This patient will be called back (process resumes) after the doctor (CPU) has attended to the high-priority patient (“Interrupt Service Routine” executed). Figure 2a,b show a one-to-one correspondence between the various states of a process and the various states of a patient while visiting a doctor in a hospital.

A doctor, while examining a patient, may ask them (entry in the patient file [PCB] updated) to undergo a few pathological tests (e.g., blood sugar test, blood test, X-ray, etc.) and revert to them with the test results. These tests are carried out in different rooms (pathology rooms) of the hospital (equivalent to I/O processes placed in I/O queues and I/O carried out by the I/O processor). Other patients (processes) are also waiting outside the pathology rooms (input/output queues) and the patient files (PCBs) are arranged in sequence in the pathology labs (linked lists of PCBs). Patients must wait their turn and their pathology tests are assessed by pathology attendants (I/O processor). Eventually, the patient obtains their reports (I/O takes place for processes by the I/O processor and process PCBs are updated). The patient goes back to the hospital lobby/waiting room (process returns to the ready queue) and waits to be scheduled to return to the doctor’s chamber. This is equivalent to a process being in a suspended state due to I/O and returning to the ready queue after I/O is over, wait to be scheduled as some part of the process is still left to be executed. The nurse/assistant (STS) keeps records of the patients (processes) to determine whether they are new entrant patients or the ones who were diverted for tests (processes suspended due to I/O), with the patients thus scheduled accordingly. Those patients who were suspended for pathology tests (processes suspended due to I/O) are given priority over the new waiting patients (new entrant processes). Processes being suspended due to I/O and waiting in different queues along with their linked PCBs is shown in Figure 3a, and patients waiting in different pathology lab queues with their patient files submitted in order (equivalent to linked list of PCBs) is shown in Figure 3b.

In some cases, the doctor may ask a patient to get certain tests done (MRI scan, stool culture), the reports of which will be available in a few days’ time (an I/O event which might take substantial time to be executed by the I/O processor). Under such circumstances, the patient is requested to undergo the necessary tests in the laboratory and then return home. They are scheduled to come back on a specific day by a junior doctor (equivalent to a medium-term scheduler) when the lab report becomes available (processes with a long I/O time are not retained in RAM and the space in RAM is freed for new processes to be moved into the ready queue from the job queue; the long I/O process is swapped out to the hard disk and is called back to RAM once I/O is completed). This swapping out and calling in is scheduled by a medium-term scheduler (junior doctor/manager), which keeps track of all the swapped-out processes and schedules them to RAM as and when their I/O completes. These patients will once again be examined by the doctor, who, with the help of their latest reports, completes the overall diagnosis (an incomplete process is completely executed with the help of the latest data set obtained) and writes the analysis and medication on the patient file (PCB and files updated with final data and results). Figure 4a shows the processes with long I/O being swapped out of RAM to the hard disk and later swapped into RAM by the medium-term scheduler, and Figure 4b shows a junior doctor/manager sending patients back home and calling them back to hospital once their awaited test reports are available. These swapped outpatients are scheduled for remaining examination by the doctor, who writes down the overall diagnosis along with any medication.

When a doctor examining a patient is interrupted by an emergency and called to the emergency department, they suspend the patient they are currently examining (context switching takes place) and ask the patient to wait in the lobby/waiting room (ready queue) once again. The doctor stores the status of the patient on their file (the PCB of the process is updated and the status of the process is saved in registers of the PCB), and the patient carries their file with them to the lobby/waiting room. The file (PCB) of the emergency patient (priority process) is opened by the doctor (CPU) so that they can attend to this emergency patient (priority process starts running). The doctor temporarily closes the previous file (saving the previous PCB) and opens the latest file for the emergency patient (opening the newest PCB) whenever an emergency patient arrives at the hospital. The responsibility of managing the situation falls on the junior doctor (a system call or an interrupt takes place, with these activities executed by the kernel of the operating system (OS) during process context switching). Figure 5a shows context switching from one process to a higher priority process in an OS, and Figure 5b shows an equivalent situation where the doctor switches from a normal patient to an emergency patient in a hospital.

7. Experimental Evaluation

The first author has been using analogy-based methods to teach computer science concepts for more than a decade. In fact, he has developed analogies, like the one described above, for a plethora of advanced computer science (CS) concepts. The different analogies have evolved through the investment of significant effort once he realized the advantage of teaching advanced computer science concepts to students through analogies. Care was taken to develop realistic analogies that are strongly structurally aligned. These analogies have been subsequently refined over many years. The first author observed significant improvements in students’ understanding of the subject and students’ learning outcomes when he used analogies in his teaching. However, his analysis of the improvements seen in learning outcomes was qualitative in nature and based on student verbal and written feedback. Indeed, the feedback from students regarding the teaching of complex subjects via analogies was quite positive. In fact, anecdotal evidence indicates that students show a preference toward registering for classes where analogy-based methods are used. The research in this paper is motivated by our desire to quantitatively establish the following hypothesis:

H1: 

Analogy-based teaching of a complex topic in computer science leads to improved student learning outcomes for that topic.

We transformed this general hypothesis into a more specific hypothesis and tested it through an experiment. The specific hypothesis is as follows:

H2: 

Analogy-based teaching of the concept of processes in operating systems leads to improved student learning outcomes for this topic.

To test the hypothesis, we taught the concept of processes in operating systems in the classroom. The class was divided into two groups, and both groups were taught the same material on processes in operating systems. One group was taught this concept using the hospital analogy described earlier, and another (control) group was taught the same concept in a regular manner, i.e., without using the analogy. We used careful planning in our experimental setup (described next) to ensure that other factors did not influence the outcome. The outcomes were measured by evaluating students’ performance on a 20-question multiple-choice test that was administered after the concept was taught. Our experimental results show that students taught with our analogy-based method produced improved learning outcomes compared to those students in the control group who were taught without using an analogy. We subsequently performed another experiment to measure the impact of analogy-based teaching of a topic in software engineering, namely the topic of modules in software design.

7.1. Experiment 1: Student Performance Evaluation

7.1.1. Experiment Design

To test the above specified hypothesis, we conducted a study involving a cohort of 119 undergraduate information technology majors at an institution. These students were studying in their second year of the program, and they were enrolled in the operating systems course. We obtained permission from the head of the Department of Information Technology. The first author assumed the role of the instructor for the class, taking over from the regular instructor of the course when the time came to teach the topic of processes in operating systems. The students in the class were divided into two groups of nearly equal size; one group consisted of students with odd enrollment numbers, while the other group comprised students with even enrollment numbers. The student demographics for the admitted cohort at this university were quite uniform as most students came from middle class families with comparable socio-economic status in a provincial state capital (city of Lucknow) in the country (India). The enrollment numbers of student cohorts in the major course are assigned consecutive numbers as students gain admission to the information technology major at this institution. These enrollment numbers are assigned as the files of students admitted to the major course arrive in a random order. Thus, dividing the students into two groups (an experiment group and a control group) using even and odd enrollment numbers has the same effect as assigning students randomly to the two groups. This protocol ensures that the experiment group and the control group are very similar in composition and that factors other than the use of analogy in teaching the subject will not impact the learning outcome. Thus, to the best of our knowledge, there is no bias in the assignment of students to either of the two groups.

Both groups were taught the concept of processes in operating systems by the first author of this paper, who taught the topic as a guest lecturer. He ensured that the two groups were taught identical topics in an identical manner to avoid the influence of other extraneous factors. The only difference was that the experiment group (n = 59) was also taught the analogy described in this paper, while no mention of the analogy was made to the control group (n = 60). Both groups were taught by the same person (first author) on the same day; the experiment group was taught first, followed by the control group. After finishing the topic on processes, the two groups were given a 20-question multiple-choice test in their class on the next day. Both groups appeared for the same test (on processes) that was designed by the regular course instructor teaching operating systems at that institution without any input from us (it should be noted that the first author solely instructed these students on the topic of processes as a guest lecturer and was not the course instructor). The maximum obtainable score was 20 (1 mark for each question). The test was conducted by the regular instructor, who created the test paper, administered it, evaluated it, and e-mailed the student scores to the authors. Thus, the first author who taught the topic of processes to the two groups, both using analogies and without analogies, respectively, had nothing to do with the design, administration, and grading of the test or compilation of the test scores. The other authors also did not have any involvement in the design and administration of the test either.

7.1.2. Results

We measured improvements in outcome through a 20-question multiple-choice test administered by the course’s regular instructor, who was distinct from the guest lecturer (the first author) who taught the concept to the two groups. The course’s regular instructor designed the test, administered it, graded it, compiled the scores, and then e-mailed the results to this paper’s authors, who then analyzed it. The mean, median, mode, and standard deviation of students’ test scores are stated in

Table 1. Statistics for marks earned in the 20-question multiple-choice test (max score = 20).

	Group A (without Analogy)	Group B (with Analogy)
N	60	59
Mean	14.5	16.66
S.D.	1.76	1.46
Median	14	17
Mode	13	18

. The two-sample t-test was also performed (described later). Students in experiment group B who were taught with the analogy averaged a full 2.16 points above those in control group A who were taught without the analogy (10.8% improvement in score). This represents an improvement equal to one full letter grade based on the US grading system, where typically A = 90% or more, B = 80% or more, C = 70% or more, and so on.

The standard deviation of experiment group B was also lower, indicating that their performance was better overall as it was clustered more around the average. The higher standard deviation of control group A indicates that their performance was poorer, as their scores exhibited greater divergence or variability. Along the same lines, the median of experiment group B was 17, whereas the median of control group A was 14; the mode values of groups B and A were 18 and 13, respectively. It should be noted that the first author put in his best effort to teach control group A, with the only difference being that he did not use the analogy to illustrate the concept. Given that the control group’s mean score was 14.5, students in that group did develop an understanding of the topic, though it was not as good as that of experiment group B (mean score 16.66) that was taught with the analogy.

7.1.3. Two-Sample t-Test

Next, we needed to establish that the observed differences in the mean scores of the two groups are statistically significant. To validate that the difference of 2.16 points in the mean values between the two groups is significant and not merely a result of random chance, i.e., the null hypothesis can be rejected, we carried out the two-sample t-test. To verify the assumption of the two-sample t-test—that the distribution of student scores in the two groups follows a normal distribution—we conducted a check. This check confirmed our assumption, which is evident in Figure 6 that depicts the data distribution as histograms. We then proceeded to conduct the two-sample t-test with the mean and standard deviation (SD) values depicted in Table 1. The values computed for the two-sample t-test were 8.0358, a p-value of 8.305 × 10⁻¹³, and a degree of freedom of 117 (t = 8.0358, p = 8.305 × 10⁻¹³, df = 117). The exceptionally small p-value indicates a significantly low statistical probability of the two groups having the same mean score. The experiment conducted hence validates that teaching the topic of processes in an OS using analogies had material impact on students’ test performance.

7.2. Experiment 2: Analyzing Student Feedback

Next, we assessed if students themselves saw the benefits of the use of analogy-based methods for the teaching of advanced CS concepts. We conducted an experiment to evaluate our methods based on feedback from students. All 59 students in the experiment group who were taught the topic of processes using the analogy described above were sent a questionnaire. We hypothesized that students prefer analogy-based teaching methods and find them more engaging. The survey was sent to the students after the quiz mentioned in the first experiment was administered. The survey was sent to only the group that was taught using the doctor’s office analogy. Fifty of the fifty-nine students responded. The questions are reproduced below.

Q1:

The doctor’s office analogy aided in your comprehension of the concept of processes.

Q2:

Topics that were explained using analogies were more comprehensible to you.

Q3:

You faced difficulty in understanding topics that lacked the use of analogies.

Q4:

Topics that did not incorporate analogies were less captivating for you.

Q5:

Topics which used an analogy were more engaging for you.

Q6:

Would you prefer concepts of computer science to be taught to you using analogies?

The responses were collected using the Likert scale, where participants indicated their level of agreement on a scale ranging from 1 (strongly disagree) to 5 (strongly agree). A total of fifty responses were received.

Table 2. Measuring student’s satisfaction with analogy-based teaching.

	Q1	Q2	Q3	Q4	Q5	Q6
Mean	4.33	4.4	4.2	4.14	4.22	4.38
Median	5	5	4	4	5	5
Mode	5	5	5	5	5	5

presents the calculated mean, median, and mode values for the set of (above) six questions.

Clearly, students found analogies from everyday life to be quite useful for teaching advanced CS concepts such as operating system processes in terms of understanding the topic (Q1 and Q2). They were, however, able to understand other topics where analogies were not used (Q4), but their response was neutral. Students showed a clear preference for analogy-based teaching (Q3, Q5, Q6). It should be mentioned that these results are consistent with the qualitative feedback we have received from our students, where students often walk up to the instructor after class or after the course is over and express their appreciation for being able to understand a complex topic/subject.

Our two experiments show not only the students recognized, that they learned better with analogy-based methods, but that they also performed better in exams administered to test the knowledge of the subject matter.

8. Using Analogy to Teach a Software Engineering Concept

We further tested our hypothesis in the teaching of another concept, this time related to software engineering. Here, we tested the following specific hypothesis:

H3: 

Analogy-based teaching of the concept of modularity in software design leads to improved student learning outcomes for this topic.

The main concepts in teaching modular software design are module cohesion and module coupling. We have developed an analogy for teaching these two concepts of cohesion and coupling in modular software design. First, we provide a brief introduction to modular software design, before then briefly describing our analogy for it.

8.1. Modularity in Software Design

A modular system is a collection of manageable components that are clearly defined with proper interfaces within the units. A system with modules has the following desirable properties: (a) a module is essentially a clearly defined subsystem that holds the potential for utilization in various other applications; (b) a module serves a singular, well-defined purpose; (c) well-designed modules possess the ability to utilize other modules; (d) using a module is simpler than constructing it; and (e) the modules appear simpler from an external perspective, although they may not necessarily be simpler internally. The presence of modularity improves the clarity of design, subsequently facilitating tasks related to debugging, implementation, documentation, testing, and maintenance of the software product.

Coupling quantifies the level of interdependence between modules. Two modules with high coupling exhibit a significant level of interconnectedness and, consequently, a strong interdependence. A well-designed system exhibits low coupling, and interfaces should be designed in a way that promotes reduced levels of coupling.

Cohesion is the metric used to assess the level of functional interdependence among the components within a module. A strong cohesive module implements functionality, and its components are related among themselves, often having no communication with other modules. An important objective in design is to minimize coupling and maximize cohesion.

We noticed that the idea of cohesion and coupling in software designing is tough for students to grasp. To impart these concepts, we employed analogy-based instruction. We utilized a bachelor’s degree in computer science (CS) as an example to show the concept of modularity. Given that all students are enrolled in an undergraduate program, they can easily relate or draw connections with the analogy. In our analogy, the design of a degree program is analogous to the design of a software system. The first author has been using this analogy for the past fourteen years to teach the concept of modularity in software design, which has yielded excellent results. We briefly describe our analogy for the topic of modularity in software design.

We consider a computer science department at a university that is responsible for designing a B.S. Computer Science (CS) program. Designing the B.S. CS program can be considered analogous to designing software. The B-Tech program is structured into eight semesters (modules) and starts from the initial semesters before progressing to the intermediate ones, ultimately culminating in the final semesters. The courses offered within each semester (module) can be considered as submodules of that module.

Modularity enhances the design of an eight-semester (module) B-Tech program by providing a structured and well-designed curriculum. This modularity contributes to clarity, making implementation easier. Additionally, it facilitates testing, debugging, and documentation through continuous internal assessment, class tests, final exams, and final grade cards. The structural mapping between various concepts in our analogy is illustrated in

Table 3. Analogy for cohesion and coupling in software module.

SW MODULARITY CONCEPT	ANALOGICAL CONCEPT
Software system	Degree Program (e.g., B.Tech CS)
Module	Semester
Submodule/Function/Procedure	Course (or Subject)
Parameter or Data	Concept or a Subject Topic
Design Assessment	Continuous Internal Assessment
Design Refinement	Program Updates and changes
Software Debugging and Testing	Class Tests & Exams
SW Designers	Faculty & Administration
Users of the Software	Students in the Program

. Courses should be as self-contained as possible but are dependent on other courses due to the course prerequisite structure. This is analogous to the concept of coupling and cohesion in software design. We do not provide too many details of the analogy here as they are described in detail elsewhere [25].

8.2. Experiment 3

To establish that our use of analogy in teaching these concepts in software engineering is effective, we carried out an experiment like the one reported earlier. We took over a software engineering class at the same institution where we performed our earlier experiment, though this class had a different set of students compared to our previous experiment. We followed the same procedure for experiment design as that described in Section 7.1.1. We split the class into experiment and control groups based on odd and even enrollment numbers. Once again, since the students came from similar socio-economic backgrounds and because the enrollment numbers were assigned to the students as they were admitted to the program (in random order), the two groups were very similar in terms of all characteristics. Next, the first author taught the topic of modular design, cohesion, and coupling to both groups on the same day, one after another. The topic was taught to both groups in an identical manner, except that the experiment group was also taught the analogy and the control group was not. A multiple-choice 20-question test was given the next day by the regular course instructor, who administered it, graded it, and e-mailed the results to the authors. The first author and the other authors of the paper were not involved at all in designing, administering, or grading of the test (the first author only taught the two sections as a guest lecturer). The mean, median, mode, and standard deviation were analyzed, and a two-sample t-test was performed. All the assumptions needed for performing the two-sample t-test did hold, namely that the test scores of both groups followed a normal distribution. The results are shown in

Table 4. Statistics for marks earned in the 20-question multiple-choice quiz (max score = 20).

	Group A (w/o Analogy)	Group B (with Analogy)
N	52	50
Mean	14.57	16.60
S.D.	1.82	1.55
Median	14	17
Mode	13	18

below.

As we can see in Table 4, students who were taught with the aid of the analogy averaged 2.03 marks more than those who we taught without the analogy, representing an overall 10 percent score elevation with analogical teaching. This improvement is the same as what was seen for the processes in an operating system (OS) experiment. The standard deviation of experiment group B (analogy-taught group) was also lower, indicating that their test performance was better overall as it was clustered around the average. The higher standard deviation of control group A (non-analogy-taught group) indicates that their performance was poorer, as their scores exhibited greater divergence or variability. Along the same lines, the median of experiment group B was 17, whereas he median of control group A was 14; the mode values of groups B and A were 18 and 13, respectively. After this, we carried out the two-sample t-test using the mean and standard deviation values depicted in Table 4. The value for the two-sample t-test was 6.8758 with a degree of freedom (df) of 100 and a p-value of 5.4 × 10⁻¹⁰ (p = 5.4 × 10⁻¹⁰, t = 6.8758, df = 100). This significantly low p-value once again shows the very low statistical odds of the two groups (experimental and control groups) having their means differing due to random chance. Our experiment thus demonstrates that teaching the topic of software modules using analogies had a material impact on students’ test performance.

As one can observe, the results of our two experiments are quite similar. They both show that using an analogy to teach a complex topic in computing resulted in an approximately 10% improvement in test scores, which corresponds to an improvement of one full letter grade. In both cases, the p-value was quite low, indicating that these improvements are statistically significant and not due to random chance. We plan to perform similar experiments for another of our analogies, and we are confident that the results will be very similar.

9. Limitations and Future Work

As discussed earlier, we have designed both of our experiments extremely carefully. The classroom was split into two groups in a manner that ensured that the characteristics of the two groups were the same. This ensures that any differences in the test scores of the two groups are attributable only to the analogy-based instruction method used in one group and nothing else. However, our experiments are limited to only two topics: processes in an OS and cohesion and coupling in software modules. Similar experiments need to be performed for each analogy developed. Additionally, the class was taught by one instructor (the first author of this paper). The experiments should be repeated with different instructors to ensure that analogy-based instruction leads to better outcome regardless of the instructor. We intend to perform these experiments in the future (this research is part of the first author’s PhD thesis). It should also be noted that an effective analogy cannot be developed for every topic. There are topics for which effective analogies may not exist. Finally, an analogy should have close structural similarity to the concept it is designed to illustrate. It is possible that an instructor who attempts to design an analogy for a new topic does a poor job, in which case the use of analogy may further confuse the students. Thus, the careful design, review, and refinement of each analogy is important.

With respect to our future research, we plan to continue our work of developing analogies for more complex topics and further improve the ones that we have developed. We are planning to publish a listing of analogies for various computer science and software engineering concepts to disseminate the results of our efforts. For each analogy we develop, we should quantitatively establish that analogy-based teaching of a concept leads to better student learning outcomes. We also plan to work with instructors at other institutions to replicate our analogy-based teaching experiments so that the results reported in this paper can be further confirmed.

10. Conclusions

In this paper, we reported on our experience of teaching advanced computer science concepts to undergraduate students with the help of analogies. Over the past fourteen years or so, we have compiled a collection of analogies that we have developed and used for the teaching of advanced computer science and software engineering concepts. Our experiments show that analogy-based teaching techniques produce a more than 10% improvement in test performance scores, which is equivalent to an increase of one letter grade. The main contributions of this paper are the following:

• We have devised a plethora of analogies for the teaching of advanced topics in computer science and software engineering. We have employed these analogies extensively in the classroom, resulting in significantly improved student learning outcomes. We described two such analogies (from the field of operating systems and modular software design) in this paper.
• We have demonstrated quantitatively that the two analogy-based teaching methods described in the paper are effective. We developed experiments to evaluate the effectiveness of using these two analogies in our teaching and we reported the (quite positive) results. These experiments involved the testing of two groups of students (one group taught using analogy and another one taught without) and the measurement of their performance in the test. Our findings indicate that the use of each of the two analogies in our teaching resulted in statistically significant improvements in student performance.

Thus, in summary, our qualitative and quantitative evaluations of two of the analogies show excellent results in terms of improving student learning outcomes through analogy-based teaching methods.