Warsaw University of Technology, Department of Electrical Engineering
pl. Politechniki 1, 00-661 Warszawa, Poland
InfoVIDE Ltd., ul. Kolejowa 5/7, 01-217 Warszawa, Poland
e-mail: smialek@iem.pw.edu.pl

The paper presents three basic elements of teaching object orientation. For each of the elements active learning techniques are described. These techniques were tested in courses conducted in the academia and for the industry. An idea of "active lecture" is presented. This technique is used to show the "big picture" and "clear traces" to the learners. Another set of techniques is used to present various design methods. These include use case sessions, CRC sessions, and role-play sessions. For each of the techniques various ideas that would allow enhancing their pedagogical impact are presented.

My position on the subject of "Active learning for OOD" comes from three main ideas. These three elements form the basic attempt to teaching object orientation in general:

• We need to show the big picture instead of just showing the programming or design constructs.
• We need to show clear traces that lead from requirements through design models to code.
• We need to show techniques for finding good models.

Showing (or presenting) things is the basis of teaching. The most obvious way (or technique) of "showing things" is to conduct a lecture. However, this technique is certainly not sufficient when we teach software modeling (and specifically OO modeling). Creating software models is a task that requires certain level of experience. This leads to another obvious conclusion that we need classes where the learners would gain this experience. Often, during these practical classes the students create models of more or less complicated systems given to them as assignments. Unfortunately, this type of gaining experience is quite passive. There is little interaction between the learner and the teacher, and between the learners. The teacher comments the effects of learner’s work, but not the way, which lead to his/her solution. In effect, the learners receive little direct guidance on how to actually create models.

The conclusion is that perhaps we need some way of involving the learners into active discussion about the models. During such active sessions, the teacher could offer his guidance in applying specific modeling techniques. Here, the learner’s solutions can find direct verification and this experience can be shared among all the participants. This leads us to a rule that can be used when designing a course in the area of object-orientation:

• During any course on object orientation we need to involve learners into active design or brainstorming sessions that lead to the construction of "good" OO models.

In the following sections I will try to present my experience in applying this rule.

It is obvious that a course on object-oriented programming has to be different than a course on object-oriented analysis and design (or OO modeling). Moreover, the courses in the industry are significantly different that the academic ones. I have the fortune to create and conduct courses in all of these fields. This experience leads me to a conclusion that still all these courses need to have one thing in common: presentation of the "big picture".

What does the "big picture" mean in case of object orientation? For me it means to define the position of various OO models in respect to the real world and how all of these models fit together. So, whether you are a programmer, or business analyst, you need to know where your models come from and how others will use them. This also means that if we teach OO design we also need to teach a bit of OO analysis and programming. This is especially visible when we consider vague boundaries between all the OO development activities.

Let’s now imagine that we take a typical university programming course. We start with learning all the programming constructs. We get to know the loops, decisions, I/O operations, simple variables, records, or pointers. Then we begin to learn procedures, classes, constructors, templates, streams, exceptions, and so on. Finally we use all these freshly learned constructs to write several fancy programs given for assignments. This is what our world becomes limited to. There is no place for the big picture, we create structured programs with classes being placeholders for functions. No relation to something that would allow us to take part in creating large good quality systems. Maybe we shall learn it next year...

How about taking an alternative course with a "big picture"? We start with learning what are "objects" and "classes". We get to know how they relate to objects on the real world. Immediately after this we learn how to denote them in a language (a modeling one like UML or a programming one like C++ or Java). Then we study class relationships similar to relationships between people or things. These relationships have direct translation into class type variables, pointers or function arguments in a programming language. We also learn the dynamics of systems. We acquire knowledge about interactions between objects that can form interaction diagrams. These in turn translate into function call structure. Finally we get to know how this all fits together...

My position here is that the inclusion of the big picture as described in this alternative course is necessary. What’s more, it is only the placement of accents inside the picture that distinguishes a programming course from e.g. a design course. My experience shows that if we properly show this big picture to the learners, their understanding of details rises dramatically. But what do I mean by "proper". Here is where active learning techniques come to the scene...

To show the overall structure of the object oriented models we basically need just a lecture. Even better if we can conduct an "active lecture". Basic prerequisite is that we have a lecture hall that has a computer with a CASE tool available for each of the students (or at least the lecturer has a computer connected to an overhead projector). After presenting the theory (notation, semantics, etc.) we can offer a very simple problem related to the theory. The students then sketch their "big picture" solutions. After this, the lecturer gathers a common solution in an interactive session where all offer their propositions. Finally, the lecturer shows a ready solution that additionally has links to the "small picture" (e.g. code already generated and written). This final solution shows all the specific constructs of the programming language or the modeling tool.

The big picture couldn’t be complete without clear traces that link all the models. Such traces are one of the biggest advantages of object orientation over e.g. structured methods. I think, that communicating all the links between OO models is one of the most important tasks of any course on object orientation. Good design is not only well structured class diagrams or sequence diagrams with proper communication patterns. To me, good design means design that is strictly compliant with the user requirements, and allows producing understandable and efficient code. The only way to achieve this is to keep full dependency between all the produced OO models.

What should we present to the learners when showing traces? In my opinion, showing a "map" of all the models is the first step to success. On the first lecture, this map can be treated as a skeleton where all the models and their relationships are presented in an overview style. Then, each consecutive lecture fills this skeleton with contents. This style allows us to keep the "big picture" constantly present. It also allows the learners to create a picture of each model in relation to other models.

In the above I have already determined a lecture style presentation for traces. I think that we should not treat relationships between models as a different subject taught during separate lectures. The idea of active lectures supports this area very well. We can thus extend our lecture activities described in the previous section, onto showing model relationships. This extension is quite simple if we use CASE tools. In some of the active lectures we can relate to models created previously. For example, the task might be to create scenarios for use cases created earlier, or sequence diagrams that relate to these scenarios and to the class model.

Another aspect is keeping sync with code. This is especially important in a programming course. If we want to relate our models to code, we can simply generate code from the CASE tools directly during an active lecture. This of course will not show the learners any of the detailed programming constructs. However, it will certainly show a completely different approach to programming – programming by design.

Even the best active lecture will not give the learners any experience in building good models. We can present there all the guidelines and conditions describing how a "good" model should look like. We can even show some examples of such good models. However, one basic limitation is that these examples need to be short in order to fit into a single lesson. We are thus left with a problem of showing well-designed and non-trivial systems. There is also another problem: we need to show how to build such systems. Obviously, these two requirements are very strong in the industry courses.

Practically all the object-oriented methods offer various techniques for creating models. Many of these techniques are well documented and tested in real projects. Of these techniques, several seem to be perfectly suited for teaching the software design process. They are all active techniques that involve all the students in a group into a "design" session. Below I will try to present my experience in applying and modifying these techniques.

Use case sessions. During these sessions we try to model the use cases of our system. There can be several variants of these sessions. They have all in common that we try to develop specific scenarios for every, or some of the use cases. The participants write the scenarios using a very simple grammar. This resembles programming on a very high level. In real life, such scenarios can be written during interviews with the user or during interactive sessions. Teaching the process of writing scenarios in a course can be a simple emulation of a real life interview or session. If we want the learners to gain individual analytical skills we can emulate an interview. One or two of the participants can play the role of a user. One or two other participants play the role of analysts. The rest of the group will review the session. If we have more time, the participants can change their roles for each of the use cases. If we just want the learners to gain general knowledge on scenarios we can conduct a group scenario session, where all the participants develop a common solution.

CRC sessions. A CRC session is very well documented and I will not describe it here in much detail. As for a use case session, teaching CRC sessions means emulating them in a course. We can simply gather all the participants and let them brainstorm. If the lecturer becomes a moderator of the session, he’s got a perfect way of giving the learners feedback on their object-oriented thinking. There are also several variants that I use during my courses. The one I use most often is where we divide the group into two groups. The first group is the users group, and the second group is the analysts/designers group. Before coming to a session, both groups try to discuss their own solutions. The users develop a common vocabulary and a common position on their requirements. The analysts/designers try to think about classes, responsibilities, and collaborators that exist in the problem domain. During a common session the requirements are verified with the design. This way the learners have a direct example of how important is proper cooperation with the customer.

Role playing sessions. During a role-play session each of the participants plays the role of one of the designed classes. It is a perfect way to design communication patterns in an application, where also the users can be involved. It is also a perfect way to teach the design of system dynamics. This session is also very important if we want to show traces between models. Trace to the CRC model is quite obvious. Less obvious is the trace to the use case model. Thus, it is important to have a person that keeps track of a scenario while the others play. The role playing sessions can produce good interaction diagrams. So, a variant might include drawing a sequence diagram during the role-play.

My experience with active learning techniques shows that they are a good way of teaching object orientation. The learners seem to gain good understanding quickly. Unfortunately, I cannot back this thesis with any statistical data. The only way of verifying the quality of teaching methods are the exam results in academia and frequency of course re-ordering in the industry. I cannot compare these to the results for a traditional course, as I have always used active methods. I hope to get some information on this subject during the workshop.

Another important summary remark is that all the active techniques we use should fit together. The active sessions should thus form a lifecycle for a system given as an assignment. This way we enforce our support of the "big picture" and "clear traces". The first part of this big picture is a use case session. This traces into a CRC session. Finally the previous two sessions are the basis for a role playing session. All these have a more theoretical support in active lectures. By combining these techniques, and giving stress to different aspects we can create very general and very specific courses on object orientation...