Page 76 - Getting the Picture Modeling and Simulation in Secondary Computer Science Education

74
Chapter 3
A description of requirements and specifications was a part of project documentation and all the students who finished their projects provided it. Team 7 wrote, “The mousetraps need to be placed at random locations since we don’t know what the perfect locations would be. If a mouse contacts a mousetrap, then the mouse needs to die/disappear.” In their project documentation, Team 1 stated requirements: “In our program, two particles react to form two other particles. The probability that two particles react can be specified, as well as the reaction speed of the particles.” Then they wrote specifications extensively: “If two initial turtles (red and yellow) meet, then the current catalyst value (the left slider) determines whether they react.” Team 3, who explored the propagation of the Ebola virus, wrote, “In our model there is only one [breed of] turtles and it stands for people. These turtles can have various properties, such as being ill or healthy. They can be influenced by external factors such as medicine and their life span.”
While all students managed to implement something, some of them experienced difficulties. In the recordings we heard S1a say, “I know what I want to do, but I don’t know how to code it. I don’t think it’s all that difficult, but...” During the interview, S7a told us he refrained from including mouse reproduction because he did not know how to design this feature and program it. When constructing their programs, only one team worked top-down: the others rather engaged in bottom- up incremental development constantly adding new features to their models.
Verification and Validation. The recordings revealed a complex picture in which the distinction between validation and verification was not always clear. Team 4’s approach is representative of students’ strategy: they constructed their model (program) by cycling among stating requirements and specifications, implementing and testing, in minute steps: “We have to do that with time, man, that they can only drink one beer in ten seconds or so, otherwise they drink too much!” When testing, it was not clear whether they were validating their model or verifying their code: often they would run their program, see remarkable behavior and subsequently change the code. S4b: “All dead.” S4a: “It begins to deteriorate now [in the simulation, the beer is gone and people leave the party quickly]” S4b: “But how could they all get the same amount of beer?” S4a: “That’s because of that piece of code.” S4b: “Really? Can’t that be changed? How did they do it with the sheep? [Referring to an example from NetLogo’s models library]” Subsequently they would change their code and continue their work in a similar fashion. Team 6 worked similarly. It was not clear whether S6b was validating or experimenting: “It works now but it is not balanced, so to speak.” S6a: “Yeah.” S6b concluded: “Yeah.