| A first-cut analysis and high-level design of a computer-based instruction system. |
Skill, Student, Lesson, Test
The Skill class is the core of the system. A skill is a concrete ability that can be objectively demonstrated. A skill may require other skills. For example, learning “multiplication” may require knowing “addition”.
The second key class is the Student. The relation from Student to Skill defines the skills that a student has demonstrated.
A Lesson Plan is the entity that tries to teach a Skill to a Student. Note that a Lesson Plan has prerequisite skills, and teaches other skills. Lesson Plan will be further described later.
A Student obtains or improves a skill through Lessons. A Lesson is a Lesson Plan in action. While a Lesson Plan is a fairly static entity, the Lesson is more dynamic. For example, a particular Lesson may have a score (representing a student’s progress in the topic) and a state (representing the student’s position in the path that makes up a Lesson Plan). The Student is related to the Lesson by taking it at a particular time.
A student demonstrates a skill via a Test, which is composed of Questions that demonstrate Skills. A Student takes a test at a particular time and receives a score for it. The Test will encapsulate its scoring policy.
Skill Dynamics
Acquiring a skill. Usually, a student will take a lesson, take a test, and qualify to claim that they have a skill.
Targeting a skill. To teach a skill, the student’s current skills must contain all prerequisite skills for the lesson, and all of the skill’s prerequisites must either be posessed by the student or taught by the lesson. There may be many acceptable plans; the student might choose by external factors (e.g., preferring simulations or preferring lessons by a particular author).
Lesson Plan and Modules
Moving into a more design-oriented mode, we’ll look at our lesson plan in more detail. We’ll consider a lesson plan as being composed of modules. Module is the superclass of any particular piece of a lesson. A Module could be one of several things: Text, Simulation, Quiz, and so on (encompassing a particular presentation). A module can also be a programming construct: a sequence (“Seq”), a Loop, or a Choice. We also have a Condition, representing something that can be evaluated by the Loop or Choice. Note that Seq, Loop, and Choice refer back to Module; this is to show that they may contain other modules.
The way Modules are set up, an initial implementation could strongly resemble a programming language. Later, more sophisticated implementation could allow for a graphical interface to compose lesson plans.
The state of the module will have to be more fully defined to make the design complete. The class diagram currently shows state as a field in Lesson; this is what a Condition (or a Quiz etc.) would affect. Loop and Choice would have access to the state to help determine the next step.
Module Dynamics
We’ll show one example of using the module elements. We have a sequence with three modules in it – a Text, a Loop, and the Text again. The Loop examines the Condition twice (test at the top – a “while” loop), and calls a Simulation once.
Conclusions and Lessons Learned
This was a first-cut analysis, and it needs refinement.
The initial analysis focused on Lesson Plan (as a sort of multimedia object) and on Test (as the result of a lesson). The comparison of Lesson Plan and Test revealed the missing but important Skill object, which is actually the focus of the system. We rearranged the diagram so Skill and Student were on top.
Splitting Lesson from Lesson Plan was another important insight. We would like lesson plans to be designed by a course author, and lesson-in-action to be used by the student.
Looking at the dynamics of the system showed the need for prerequisites on the lesson plan, and provides a basis for comparing what is known against what is learned.
Finally, the module design originally accommodated only Choice; further analysis suggested adding Seq and Loop to make it complete in the sense that structured programs can represent all program graphs.
While this analysis is by no means perfect or complete, I believe it could be used as the basis of an effective implementation.