Pedagogical Pattern #18
Discussion-Activity-Review-Lab-Review Pattern
(Version 1.0)
Gary L. Craig
Superlative Software Solutions, Inc.
5800 Magellan Way #107
Raleigh, NC 27612 USA
craig@cat.syr.edu
http://www.cat.syr.edu/3Si
Intent:
Present ideas which must be considered at a variety of abstraction levels
Motivation:
There are many OO concepts which must be understood at several abstraction levels, e.g., Polymorphism -- which has implication on design and programming. In general an iterative approach to learning is best; but not always the most effective from a time management perspective. This pattern in some ways is an extension to the discussion-lab
paradigm. The goal is to permit the student to embrace an abstract view before tackling
a more concrete view.
Applicability:
Use the DARLR pattern to link two abstraction levels for a topic. Introduce the high level material in context through a guided activity; followed by "implementation" as an exercise.
Structure:
Discussion:
Establish the context for the development cycle. Utilize the property of large group discussion to stimulate the class.
Activity:
Once the big picture has been established through the class-wide discussion, move forward to small group exercises. This permits more specific (detailed) issues to be considered.
Review:
Bring the class back together to evaluate the different results (e.g., analysis models, design
models, ...). Consider the alternatives observed. Determine a "common" set of "work-products". Transition to the next abstraction layer, i.e., raise the issues.
Lab:
For most analysis/design and design/implementation steps, the "lower" abstraction layer can be produced in part through a transformation. This transformation should be performed as an
exercise.
Review:
Evaluate results of Lab work. In addition, the mapping between abstraction levels is reviewed.
Consequences:
There is linking between development phases. Both models and mapping between them can be reviewed for consistency. For example, development of an analysis model; followed by discussion of
impact on design; followed by design exercise; followed by a review of the resultant design model including reflection back to the analysis model.
This pattern can be exploited and tuned to highlight either "phase". For example, one may have a design discussion to clarify the requirements for the implementation task. The design may only be
roughed out (or certain non-functional requirement left unconsidered). Alternatively, the design discussion may be very involved, and the coding is performed (perhaps only at pseudo-code level) to validate the "workability" of the design.
Implementation:
Issues to consider:
- What is to be emphasized, e.g., phase 1, phase 2, or the transformation process between the phases. This drives the level of detailed required in each discussion/activity/lab/reviews.
- What measure is to be used to evaluate consistency between abstraction levels. Such measures may be "access paths"; scenarios; metrics; ...
Related Patterns:
(none as yet)
Example Instances:
Used frequently in analysis and design courses to show the relationship between these phases; and provide context for decisions made.
Very successful for "involved" coding exercises where design issues can be contained within a separate design discussion. At the completion of the design exercise, student have a sense of "ownership" of the problem and subsequent design -- and can concentrate on the
implementation issues. (This has been employed in teaching "synchronization" mechanisms in Java. The overall concurrent architecture is designed in a separate discussion prior to
doing the implementation lab.)