What’s a Good Model and How to Teach It? – Introducing object oriented modeling by using scenarios Ira Diethelm,
[email protected] University of Kassel, Software Engineering, Wilhelmshöher Allee 73, 34121 Kassel and Gaußschule, Löwenwall 18a, 38100 Braunschweig, Germany
Leif Geiger,
[email protected] University of Kassel, Software Engineering, Wilhelmshöher Allee 73, 34121 Kassel
Albert Zündorf,
[email protected] University of Kassel, Software Engineering, Wilhelmshöher Allee 73, 34121 Kassel
Abstract When teaching object oriented modeling using the objects first approach the course typically starts with creating some kind of object models. We found that it is very hard for our students to judge whether those first models they create are good and useful ones or not. This is even a hard task for experienced programmers who do object oriented modeling for the first time. To overcome this problem we use the active learning approach. We let the students articulate and discuss their modeling decisions from the very beginning. This enables the students to explain, to question and to correct their modeling decisions. To allow a lively discussion among beginners and avoid misunderstandings our models should not be too complex. And the models should be formal enough to be translatable into an object oriented program. We use UML object diagrams first and then class diagrams for modeling data structure. To model behavior, we use two kinds of semi-formal textual descriptions and so-called rule diagrams. These representations allow our students to judge on the quality of their models. This paper will present our specific form for introducing objects first and our experience with it.
Keywords Object oriented modeling, objects first, active learning, UML
INTRODUCTION We have been using the objects first approach with UML diagrams for a long time in our introductory courses at a secondary school and a university for many years now and have achieved promising results. But we found that still some students produce cryptic and awkward models. We noticed that it is hard to decide for our students whether a model is a good model or not. So we asked ourselves what comprises good models, how can one “measure” the quality of a model and how can we teach this to our students. It turned out that a simple rule for measuring the quality of a model works quite well for the beginning: Good models are easily understood and can quickly be interpreted by persons who did not create them, especially by other beginners on the one hand and by those (us) who have to review and assess them on the other hand. Following this idea when setting up our courses, we let the students review their models and explain their modeling decisions to each other right in the first lesson. We will show how we integrate active learning in the different phases of learning modeling. Our understanding of objects first is to start with objects and modeling in the first lesson (and not with classes or OOP first). So in their first exercise in object oriented modeling the students create an object diagram for a certain scenario and systematically derive a class diagram from it. Teaching
how to make good modeling decisions we use the active learning approach: 6 to 8 groups of students are assigned to model one scenario out of 3 related use cases. Within their group the students have to agree on a good object model and then they have to explain their decisions to the class. The class has to agree on one common class diagram in an intensive discussion that is like a big peer-reviewing process. We describe these exercises in next section. Afterwards we use active learning to teach the students how to develop a good model for the behavior. Therefore, we use a triple jump approach. The basic idea of this part is quite similar to the one before. We call on the students to express the behavior in a way that others could understand easily. They have to do this at three different abstraction levels, each from the developer’s point of view: At level one they have to write down a text that describes the behavior in the problem area. At the second level (the second jump) they have to translate this description into a text that represents the same information but refers to the data model. And in the third level they have to create a representation for this in UML or source code. We close with our experiences, a short summary and future prospect.
TEACHING GOOD DATA MODELS FROM THE BEGINNING As mentioned above, we follow the (strictly) objects first approach in our courses. We will give a short definition of objects and models in the first subsection. In the second subsection we describe how we introduce object oriented modeling in freshmen courses by using this approach. In the third and fourth subsection we show how we use active learning in the first modeling exercise to teach the students the difference between good and bad models using small group discussions and allclass discussions. The learning targets of our first lessons are:
The students should be able to model a situation described by a textual scenario using an object diagram, be able to derive a class diagram from this object diagram systematically, merge object and class diagrams for different situations concerning the same problem area into one class diagram that covers all situations and find out that each way of modeling depends on the aim the modeling addresses and, according to this, that models may need modification during the modeling process.
What’s modeling? Our definition of modeling is based on the information-oriented approach in computer science education, see Breier (2005), and it is described as follows: To solve a problem by using the help of a computer program two sorts of modeling are needed: firstly the information in the given problem area has to be modeled as a data model on which the data processing operates and secondly the problem solving process, the data processing itself has to be modeled. Both models together generate new data which represent the solution in the data model. The data has to be interpreted by humans to derive the information which solves the given problem. The interpretation changes if the aim of the model changes. Due to this fact a model should be easily interpretable and can only be interpreted in the right way if you know the aim and context it was created for. This definition differs strongly from most advices how models can be derived which rely on the verb/noun method, e.g. by Barnes, Kölling (2006), and Balzert (1996). Modeling information with objects first We teach modeling in our course in programming methodology at a university and in the CS1 courses at a secondary school. Usually, we use the board game ludo as a
first running example; see Diethelm, Geiger, Zündorf (2005), because in Germany almost everybody knows it quite well. We start by playing the game in real life with real pawns, board and a die to create at first mental model of a standard situation. The exercise to create a computer version for this game complies with the requirements for good examples stated by Holland, Griffiths, Woodman (1997): It is large enough to cover different use cases and scenarios, it is complex enough to activate changes in the model and it allows to split the exercise and to give the parts to smaller groups. It has more than 3 classes and at least two with more than one object, different cardinalities for the associations between two classes and the behavior can be modeled as changes in the object structure. One main reason for choosing ludo was that in our country nearly everyone knows this game and its rules. We find it important to teach modeling techniques in a known context where everything seems to be bright clear. A standard scenario to start with could be the following: ”Bob and Alice are playing Ludo. Alice plays with the red pawns and Bob’s are blue. Each of them has one pawn on the board but there are 2 empty fields in between. It’s Bob’s turn and he just diced a 2.” When drawing the first UML object diagram for this scenario some interesting modeling decisions can be discussed. An object diagram for this situation could look as follows (these drawings are translations of samples that our students draw with pen and paper):
Figure 1: object diagram for the standard situation Alternatively, one could leave out the color attribute because the color just models the relationship between pawns and players in real life, cf. fig. 2. In an object diagram this relationship can be represented by links between the two objects. But you can also argue that the color is needed later on for the GUI. Using the attribute color or not can both be a possible and a good decision. What’s most important is the explanation. By broaching the issue of the color into the classroom discussion the students are motivated to discuss other modeling decisions: How to model the information, that it’s Bob’s turn now? Should this be modeled by an attribute, a link to the die or another link to an object modeling the game itself? After they agree on one object diagram, the first small class diagram can be systematically derived from it: Every object is sorted into a particular class and then all occurring classes are collected in the first class diagram. All attributes are added to its class and the links in the object diagram result in associations in the class diagram, see also Leue, Systä (2003). The class diagram for the first object diagram in fig. 1 is shown in fig. 3.
Figure 2: alternative object diagram for the standard situation
Figure 3: Class diagram derived from the standard situation Modeling given situations in small groups The short introduction shown in the previous chapter takes up less than one lesson of 45 minutes. Afterwards the class is divided into small groups of 3 to 5 students. Each group gets a different scenario and the exercise to model the given situation as an object diagram and then to derive a class diagram from their model or to expand the given class diagram in a way that the information from their situation is covered as well. The six examples we use are: 1. It’s Alice’s turn and she has just diced a 3. One of her pawns is located 3 fields behind the only pawn of Bob on the board. 2. Alice has just kicked Bob’s pawn and her pawn is now located at the field where Bob’s one was standing a few seconds ago. Now he has all 4 pawns in his base field. 3. Bob has one pawn on the board and 3 in his base field. He has just diced a 6. 4. Bob has just moved one pawn from his base to his start field and may now throw the die again. 5. One of Alice’s pawns is located 2 fields away from her target fields and she has just diced a 3. 6. Alice has just moved one of her pawns onto her first target field. In fig. 4 to 6 we show solutions which our students created. Fig. 4 shows two suggestions for situation 4 and fig. 5 and fig. 6 show object diagrams for situation 2.
Figure 4: Two alternatives for an object diagram for situation 4 The left object diagram in fig. 4 shows a link between a field and the player Bob to model that this field is the start field for his pawns. The students who created the right one in fig. 4 decided to model the relation of the start field to Bob in a different way: It is just the field next to Bob’s base. As a consequence of that there have to be different associations in the class diagram. These two object diagrams for the same situation differ also in the links between player and die. The second object diagram even uses the color of the pawns although it was not mentioned in the text.
Figure 5: Object diagram for situation 2 In fig. 5 there is a link called ”was in” to show where Bob’s pawn was located a few seconds before although this information is not needed for the game. Fig. 6 leaves this out but models that the players are next to each other. In addition to that the object diagrams differ in the number of base fields: The first one has only one field while the alternative object diagram has 4. All groups draw their diagrams on slides which are used to present their solution. The differences in these solutions then have to be merged during the next phase. In-class Validation Subsequent to this exercise the groups present their diagrams one after another. Using slides and an overhead projector they explain their decisions in front of the class. This lesson is used to assure and validate the results of the students. They have to argue why they decided e.g. to model the relationship between player and start field in the one or the other way and they have to decide which model represents the information best and what information needs not to be represented at all, e.g. where the pawn has been a few seconds before. Here the entire class, and not only the teacher, decides which modeling decision will be part of the joint solution and the combined class diagram and which won’t. We’ve noticed many times that students change or alleviate their decisions while
presenting their model right before another student has the chance to comment on this point. Because in the moment they were saying it out aloud they realized that their modeling decision was ”not so good”.
Figure 6: alternative Object diagram for situation 2 Fig. 7 shows one possibility for a merged class diagram. Afterwards you may now discuss the combined solution as well, e.g. if it is necessary to use three different classes for the fields.
Figure 7: class diagram for all situations In this active process the students find out what a good model looks like. This discussion with six groups lasts at least one hour and we think that it is especially this long lasting process of deciding and arguing that gives the students the desired experience to decide if a model is ”good” or not and if the model is appropriate to solve the given problem or not. In addition, they learn that there is not only one solution for a problem, not only one good model. And they learn that models may be changed or even have to be changed during the problem solving process. So they get the necessary experience for further modeling decisions for their own projects in the future.
DERIVATION OF CLEARLY STRUCTURED METHODS As already discussed, at first a good data model facilitates the coding of information i.e. the mapping from the application domain to the model domain. Similarly, a good data model facilitates the interpretation of computation results, i.e. the mapping from the model domain to the application domain. However, there is a second major feature of a good data model: a good data model should facilitate the construction of the behavior model, i.e. it should facilitate the actual programming.
Although our students create quite satisfying data models using our approach, modeling or programming their first method has still been a major problem for the students. To leverage this problem, we have introduced textual scenario descriptions and story boards and systematic approaches for the derivation of behavior models; see Diethelm, Geiger, Zündorf (2005) and Zündorf (2001). Although these approaches provide a certain help for our students, we are still not satisfied with their programming performance. Thus we further analyzed this problem area and made a number of observations. Firstly, writing good textual scenarios is still a problem for our students and therefore they frequently have no good basis for the subsequent steps. Secondly, our approach for the derivation of behavior models is still very data oriented. Story boards focus on the data structures in certain example steps. In addition, they still focus on single example scenarios. The derivation of general behavior relies on the comparison of different scenario steps (usually derived from different scenarios). From this comparison the students have to identify if and while structures. This turns out to be a fairly complex task for our students. To overcome this problem, we have now introduced a triple jump approach addressing control structures and general behavior descriptions more directly. Our triple jump approach for the development of behavior models works as follows: Jump 1: Textual description of the behavior at application level: We call on our students to derive a general description of behavior for the considered use case at the application level first. For example, an application level description of the operation release new pawn might look as follows: “The chosen pawn shall be moved from its base to its start field. This may only be done if the player has diced a 6.” Such a textual description may be developed with a physical ludo board at hand. Thus we do this description at application model level it does not need to deal with the chosen data model yet. This reduces the mental complexity of this task. We just focus on behavior descriptions not yet burdened with the concern on how to do this in the chosen data model. However, in contrast to a scenario description, this description has to cover the behavior in a more general way. For example, the text above describes explicitly all the preconditions that must be fulfilled in order to execute the desired operation. In more complex cases, the description might also outline iterations and the invocation of sub-behavior that are interpreted later on as method calls. Jump 2: Textual behavior description at model level: Once the general behavior has been outlined at application level, in the second step, the general behavior description has to be connected to the data model. Therefore we call on our students to rephrase their behavior description at the data model level with explicit references to data model elements: The isIn link between the pawn and its base object is destroyed. The start field is identified via a next link from base. We create an isOn link connecting the pawn and the start field. All this is done only if the current pawn has a link to its owner and if the owner has a link to the die and if the eyes attribute of the die equals 6. This step identifies how different cases are distinguished at the data model level and how the desired state changes are reflected in the data model. During this step, the students may utilize data model examples from earlier lessons. Although those data model descriptions show only example situations the students have only little problems to identify those parts of the data model that they need for the considered general behavior.
Jump 3: Graphical behavior description via rule diagrams: With the help of the data model level behavior description the actual programming becomes now manageable. In our approach we use a graphical programming language for the specification of behavior as shown in fig. 8.
Figure 8: Rule diagram for the release of a pawn The next step for the students would be to translate this diagram into code or generate the code automatically using the case tool Fujaba, (see the FujabaHomepage). Due to our experience our new triple jump approach helps the students a lot in developing their first method implementations. The triple jump approach helps them to deal with the different concerns of programming one by one. Firstly they outline the control flow. Secondly, step by step they connect the basic queries and update operations to the data model. Thirdly, they formalize their concept within a (visual) programming language. Each of these steps may involve active learning. At each level the students may develop their descriptions for various examples. They may also present their approaches to the class and discuss pros and cons of alternative designs from different groups. However, this still needs to be further validated in class projects.
EXPERIENCES We have used this approach in some courses of different qualifications: The first part described in section was used in 5 courses at school with first and second year students aged 17 to 20 and three tutorials for secondary school teachers. We used the triple jump approach from section in 3 of the courses at school and one lecture for programming methodologies at university. As a result of the first part we discovered that the models our students created were better to interpret than models of students from the years before, see Diethelm (2007). Most of the models created were then meaningful, better to understand and covered the needed information. Often the students detected during discussion that they left out some information and added or corrected it in their diagram, sometimes without any other student mentioning it. The fact that they have to present the personal solution in front of the class seems to benefit the modeling abilities. As a side effect we noticed that the students used the discussion and presentation to
correct the syntax of their diagrams. The object and class diagrams with the fewest errors and the best understandability were created by students with no previous knowledge. We noticed that students with experiences in procedural programming have had difficulties to focus on the certain situation. They often tried to cover more information than needed and made mistakes while trying so. One striking point was that they tried to include generalizations and variables in object diagrams or created the class diagram first and drew the object diagram for their scenario at last. The teachers in the tutorials had the very most difficulties to restrict themselves to their own scenario. They were discussing more than twice as long as the students did and did not agree easily. They tend to stuck to their decisions even if it was clear that another model was better, i.e. better to understand. In these two groups the previous knowledge seems to interfere with the modeling abilities. We think that the presentation and group discussion strengthens the students’ self-confidence in their modeling abilities. They get immediate feedback from the whole class and don’t have to wait for comments from the teacher or until the program runs. During appliance of the triple jump approach we did not notice any differences between the different target groups as in the first part. On the contrary: Beginners and students with programming experience both seem to benefit from this approach and find it helpful but difficult to express themselves with words before programming. In the first few exercises at university most of students left the first two steps out and risked to fail the exercise. We only could get the students to formulate the behavior by the announcement, that they wouldn’t get any points for the programming at all if they hand their solution without any text for the behavior. Using this approach, we found that beginners are able to model quite complex methods on their own, e.g. the behavior for the release of a pawn including the kicking of another pawn if it is on the start field.
SUMMARY AND FURTHER WORK Our observations make us think that we are on the right track to help students creating good models using these methods of active learning. We call on them to model not only for them but to create understandable models that their colleagues are able to interpret. In this different way of peer-reviewing the students are supported to create models that are implementable and therefore maintainable and expandable more easily. To study these effects and to enlarge them, empirical studies in various problem areas are needed. In the future we will try to analyze the effects of these verbalizing and active learning techniques regarding the mental models of the students. Especially the difficulties that procedural experienced students have with this method for creating a good object oriented data model give us a clue for the direction of further research.
REFERENCES Balzert H. (1996) Lehrbuch der Software-Technik. Spektrum Verlag,1996 (in German). 1996. Barnes, D. J. and Kölling, M. (2006) Objects First with Java – A Practical Introduction using BlueJ. 3rd ed. Prentice Hall / Pearson Education. 2006.
Breier, N. (2005) Der informationsorientierte didaktische Ansatz – Eine Basis für Bildungsstandards der Schulinformatik. In: LOG IN (2005), No. 135, p. 50-53 (in German). Diethelm, I. (2007) (strictly) models and objects first – Unterrichtskonzept und -methodik für objektorientierte Modellierung im Informatikunterricht. Dissertation. University of Kassel, Germany. 2007 (in German). Diethelm, I., Geiger, L. and Zündorf, A. (2005) Teaching Modeling with Objects First. In: 8th IFIP World Conference on Computers in Education. Cape Town, South Africa, July 2005 Eckstein, J., Bergin, J. and Sharp, H. (2002) Patterns for Active Learning. Proceedings of the Pattern Languages of Programs Conference. 2002. fujaba-Homepage www.fujaba.de, last visited Sep. 2007. Holland, S., Griffiths, R. and Woodman, M. (1997) Avoiding object misconceptions. In: SIGCSE Bull. 29 (1997), No. 1, p. 131-134. Leue, S. and Systä, T. J. (2003) Scenarios: Models, Transformation and Tools. International Workshop Dagstuhl Castle, Germany. Zündorf, A. R. (2001) Object Oriented Software Development. Habilitation thesis. University of Paderborn. 2001.
Biographies Ira Diethelm is scientific assistant at the Software Engineering Research Group at the University of Kassel. She also teaches math, chemistry and computer science at a secondary school, the Gaußschule Braunschweig, Germany.
Leif Geiger is scientific assistant at the Software Engineering Research Group at the University of Kassel, Germany.
Albert Zündorf is professor and leads of the Software Engineering Research Group at the University of Kassel, Germany.
Copyright Statement B This work is licensed under the Creative Commons Attribution-NonCommercialNoDerivs2.5 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-nd/2.5/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
