Exploring Techniques for
Active Learning of OO Design

Robert Biddle, James Noble, Ewan Tempero
Computer Science
Victoria University of Wellington
New Zealand
http://www.mcs.vuw.ac.nz

Introduction

In recent courses introducing object oriented development we have attempted to introduce more active learning. This brief paper outlines some of the techniques we used, and comments on our experience.

Active learning includes a variety of techniques, but the main idea is active involvement of learners. An overview of this area of education is provided by Bonwell and Eison (1991). Learning and design are strongly related, both because design can be difficult to learn, and because design as an activity itself has similarities with learning, requiring exploration, problem solving, and evaluation.

The courses we are discussing are introducing object orientation to students with little or no background in the area. Some courses have been at our university, and other courses have been for industry groups. In some cases, the students have been programmers, but other courses have involved managers or business analysts. We focus on analysis and design, and do not address implementation details at the same time. Some of the university courses have been large, with lecture sessions of 140 students.

Our starting points were two well-known techniques for OO design, CRC cards and roleplay (Beck and Cunningham, 1989 and Bellin and Suchman Simone, 1997). These techniques are already valued for their ability to highlight issues in OO design, and their active nature also makes them very useful in teaching and learning. CRC card design requires work in small teams, and the CRC cards are concrete artifacts that support active engagement as they are created, arranged, modified, and so on. Roleplay necessarily involves each team member participating and having to really engage with the design work. However, we wanted to introduce more active elements in other activities involved in overall system development, especially at earlier stages.

OO principles

The students in these courses are newcomers to OO, so we begin by introducing the basic principles. The core ideas are objects and classes, behaviour, encapsulation, and collaboration. We also introduce basic UML at the same time, class diagrams and sequence diagrams. We then want the students to get an idea of how an OO system actually worked, and we want to check their understanding.

The active technique we introduced was a kind of scripted roleplay. We introduced a simple design using a class diagram. We then presented a situation, and presented a sequence diagram that detailed how the system worked in this situation. We introduced the idea of roleplay, describing how each person played the role of an object. To remind them of their roles, we handed out index cards with the objects names. The students then walk through the situation according to the sequence diagram.

This active exercise worked very well, for several reasons. The active nature required involvement for everyone, so everyone became alert. The sequence diagram provided enough detail, but also required some insight from the students. As we facilitated, there were many opportunities to remind them about the OO principles, and their implications. As well, the students focussed carefully on the diagrams, and picked up details they had missed in our initial presentation.

As we have repeated this in various courses, we made some minor modifications. Initially, we had distributed blank cards, assigned the students to be certain objects, and asked them to write the object and class name on the card. However, this was cumbersome, and the students often got object and class names confused. Later, we pre-prepared the cards to make sure the names were correct. This also saved time, and allowed us to hand out roles at random. It also allows slight of hand, meaning that we can sometimes assign more busy roles to students who need to participate more!

There are some factors to consider in choosing a design for such an exercise. One is that it should have enough objects for everyone to have a role. However, we accommodate some extra people as "critics" who have the special task of checking each interaction, and ensuring correct continuity. We found that the quality of the design was not critical, because even poor design elements give something to talk about, and allow the OO principles to be reviewed.

Domain Analysis and Use Cases

After introducing OO principles, we then discuss how OO systems are designed. We begin with domain analysis and then move on to use cases.

To add some active elements to domain analysis, we introduce simple textual analysis and brainstorming through active exercises. We typically do this in a large group, with one person acting as scribe at an overhead projector. For textual analysis, we start with a transparency with a text description of the domain, and students first identify nouns, which we then filter and prioritise. After introducing use cases, we then introduce similar large group active exercises to identify use cases from textual descriptions by looking for verbs.

Figure 1: Using textual analysis with a scribe at an overhead projector.

Although these exercises are very simple, their impact can be considerable. Nouns are identified as suggesting candidate objects, and verbs are identified as candidate use cases. But as the scribe underlines these on the overhead transparency, it is often possible to see a sudden understanding on the student faces. The large group atmosphere, the focus on the projected text, and the gradual annotation all seem to create a helpful environment.

Some care is needed in crafting a textual description. On the one hand, it must lead to a reasonable identification. On the other hand, it should not be overly explicit, must allow include some diversity in vocabulary and grammar, and should even include a small amount of misdirection.

With candidate objects and candidate use cases in mind, we discuss actors, and introduce how to detail use cases. We introduced "essential use cases" (Constantine and Lockwood, 1999). In these, the detail of interaction is present, but the details are given in a high-level way, remaining technology-free. As well as allowing implementation using various technologies, this avoids lengthy digression, and allows faster development. After introducing the key ideas and showing some examples, we then ask the students to work in small groups to detail some use cases.

Figure 2: An example "use case card" for an essential use case, showing a dialogue between actor intentions on the left, and system responsibilities on the right.

We introduce an active technique for them to use, again based on cards and roleplay. We call the cards "use case cards", and write the name of the use case at the top, and divide the card with a line down the middle. On the left we detail the "actor intent", and on the right we detail the "system responsibility". The result is a written dialog, where the lines on the left interleave with the lines on the right. Two people can read the parts in this dialogue, in what we call "use case roleplay".

Use case cards and roleplay work for much the same reasons familiar from experience with CRC. The cards are concrete artifacts that can be manipulated, and the roleplay involves people who identify with the points of view. With use cases, there are only two roles, actor and system. However, the very tangible dialog nature makes for a story atmosphere that facilitates critical listening, so other team members can act as critics, sometimes offering alternatives. As with CRC, the use case roleplay is also useful for presenting the design to others. After teams have developed their use cases, we typically re-assemble, and a pair for each team play out their use cases, and the larger group listens critically.

 

Figure 3: Students performing a "use case roleplay" in front of the larger group.

The use case cards are useful in the longer term, as we suggest keeping them to drive more detail design. The cards are easy to understand, and the left-right split works especially well in distinguishing the actor from the system. When we introduce internal design of the system using CRC, we often discuss how the later design creates the overall system behaviour as seen on the right hand sides of the use case cards.

Later Activities

In later sessions in our introductory courses, we keep the active involvement throughout. After our introductory sessions, and our sessions on domain analysis and uses cases, the next session directly involves CRC.

Our use of CRC is reasonably conventional, but we do play up the role of objects more than classes. In fact, although we keep and explain the term CRC, we describe the approach as concentrating more on ORH: objects, responsibilities, and helpers. We keep responsibility at the centre, especially pointing out how the word responsibility implies both authority and duty, allows collaboration or delegation, and so is a useful heuristic for distribution of intelligence.

In following session we stress evaluation of designs, and have team exercises using heuristic evaluation following the practice of usability evaluation (Nielsen, 1994), and also look for potential change situations to consider their affect on the design (similar to the approach of Ecklund et al., 1996). We even introduce both frameworks and patterns, and integrate active exercises in our presentations. These topics conclude our introductory courses, and we believe that longer exercises and mentoring should be the next steps.

Other Aspects

We integrate the major active elements into our course in a reasonably conservative way. We still present topics in a standard lecture or seminar format. However, such presentations only last 30 minutes or so, and we then break into design teams for a quick exercise. We move about and ensure teams stay on track, but we try to keep a low profile. Between presentation sessions, we ask the students to undertake similar but longer exercises as teams.

 

Figure 4: A student team using the CRC technique during a breakout from a large lecture.

Even in our large lecture session with 140 students, we have organised breakouts with a large number of teams, some one whom stay in the lecture theatre, while others colonise areas nearby. This has been helped by having a cafe nearby, which supplies convenient tables for students to work around, aside from supplying coffee. A further advantage of cafes in our city is that they frequently have racks of postcards suitable for use as use case or CRC cards; they are provided free because the cards feature colourful advertisements on the front, but backs are largely blank, and are even conveniently ruled down the middle. 

We generally review the team design efforts as a large group, choosing which to present as time allows. The teams present their own work, and perform roleplay for the larger audience. Expecting this acts as an incentive for teams to focus on the work, and everyone looks forward to seeing what other teams have come up with. We try and allow comments on both process and results, and invite comments by team members and audience.

We find a document camera and video projector very useful for quickly displaying design documents and cards. Without these, we distribute overhead transparencies and pens, and use an overhead project for teams to present documents. Some teams initially make efforts to produce beautiful neat diagrams, but we stress that in these early stages of development it is important to focus on thinking, not on presentation: messy is good!

It is clear to us that the active learning approach has great benefits, but there is one large caveat. Active learning does require a positive attitude in the audience and significant cooperation. We have found it important to foster the right attitude continually. We explain explicitly that these techniques often involve exploration and incremental improvement, and that all kinds of ideas and suggestions can be involved in the steps along the way to a good design.

We also take a very positive attitude ourselves, and try and create an atmosphere of exploration and excitement. We liken the roleplay sessions to "actors studio", and remind people that the idea is to help us all concentrate on the design issues at hand. Early in the course, we make some early physical analogies with audio equipment (Biddle and Tempero 1997), and use this as an excuse to play music. We then play music quietly during team exercises, and loudly to signal coming back together as a larger group. Selecting music acceptable to everyone can be a challenge, but even disagreements can help lighten the atmosphere! We have found more abstract quickly paced music to work best overall.

Conclusion

In this brief paper, we have outlined some of our attempts to involve more active learning techniques in our courses that introduce OO design. We have concentrated here on techniques early in system development. We have adapted our techniques in successive uses, but each of the techniques has been worthwhile. Our experience has been very encouraging, and student evaluations have been very positive.

The connection between learning and design is important for two different reasons. The first is that design is difficult, and learning how to design is itself an important issue. The second is that design itself is an activity with important similarities to learning. Design involves learning about the domain, and about requirements. Many important design techniques involve attempting solutions through use of heuristics, evaluation of the result, and iteration to improve. The CRC technique, for example, was proposed for learning design, but found widespread application as standard design practice. Some of our active learning techniques really did focus just on learning, such as the initial object roleplay. However, other techniques, especially the use case cards and use case roleplay, seem to have potential as reasonable design techniques themselves.
 
 

References