Teaching Modeling with Objects First - Semantic Scholar

Teaching Modeling with Objects First Diethelm, Ira1,2, Geiger, Leif2 and Zündorf, Albert2 1

2

Gaußschule, Löwenwall 18a, 38100 Braunschweig, Germany. E-mail: [email protected] Software Engineering Research Group, University of Kassel, Wilhelmshöher Allee 73, 34121 Kassel, Germany. E-mail: {leif.geiger|albert.zuendorf}@uni-kassel.de

ABSTRACT Informatics education usually starts with some programming language. Frequently, it focuses on programming language issues. Object orientation and OO modeling is considered as too complicated for introductory courses. Thus, OO concepts are postponed to university degrees. To improve this situation, this paper proposes a new approach to teach OO modeling in introductory courses on computer science at high school level. We report on our teaching concepts and on our experiences gained at several German high schools in the last three years. 1.

INTRODUCTION

Most freshmen courses in computer science at high schools and universities start with concepts like “public static void main()”, “print hello world”, if-statements, and while-statements. This is a major problem since, as already Niklaus Wirth stated, the mental model of (computer science or informatics) students is formed by the first programming language, they have learned. Thus, the choice of the very first programming language for teaching computer science has a long term impact on the mental model of the students (Balzert 2004). Currently, most students are restricted to imperative mental models. In computer science and software engineering, OO concepts are the current standard. To teach our students OO concepts, they should thus start with OO programming and OO modeling in their very first lessons and courses at high schools and at universities. Unfortunately, OO concepts are considered as too complicated for freshmen. It is thought, that students need to learn about classes, visibility rules, inheritance, polymorphism, and so on before they understand OO concepts and before they are able to start with OO programming and OO modeling. Thus, a lot of overhead seems to be necessary, before one gets into it and becomes able to write one’s first program. Our approach overcomes these problems. We start with OO modeling in the very first lesson. We first introduce objects and how they model simple situations. Then we show how to operate on and with object models in simple steps. Once these ideas are understood, the derivation of class diagrams becomes straight forward. This is then systematically turned into OO programs. To illustrate our approach, the next sections discuss how we start with objects, how we derive static structures, how we build dynamic models, and how such models are executed including some discussion on tool support. We end up with a summary of our work and experiences. 2.

OBJECTS FIRST

When teaching object-oriented modeling (OOM), we follow the object first approach. This is based on (Hubwieser 2000). In our opinion, the most important concept of OOM are (of course) objects. Objects may have attributes and relationships to other objects and may send and receive messages. These simple concepts are taught to our students, first. With these concepts they are already able to create their first simple OO models. To enable our students to discuss their models and to write them down, they need an adequate modeling language. You can of course speak about models using natural language, but soon you will realize that a more formal language is more suitable, because it causes fewer misunderstandings. Ideally, this more formal language should be graphical in order to facilitate reading and group discussions. In addition, the language should be machine understandable in order to enable tools to analyze and transform such models and to give feedback to the students. An object-oriented modeling language that suits these requirements is the Unified Modeling Language [15]. UML is a graphical modeling language which is defacto standard in industry. Our approach starts with the objects that are involved in a certain scenario. First, we create a UML object diagram for the start situation of that scenario. This first object diagram may be drawn on a board or on paper or with any drawing tool you like. It does not contain information about the classes at this moment. It only contains information about the objects and their relationships between each other. It may also contain attributes and values, if necessary.

In our courses, we frequently use the board game Ludo as a first exercise. The course starts with playing the game in real life with real counters, board and die to create a fist mental model of the designated situation. Here we focus on the basic game rules. Then the students develop the first object diagram e.g. on the whiteboard during a group discussion for a certain start situation of a certain scenario. Fig. 1 shows an example object diagram modeling a game situation where player Bob may hit a counter of player Alice:

Figure 1: Object diagram of Ludo start situation As you can see in Fig. 1, the players Bob and Alice are both modeled as objects. These objects have color attributes modeling that Alice plays with the red counters and Bob with the blue ones. The scenario deals with two counters: counterA belongs to Alice and counterB to Bob. This is modeled using two counter links. Bobs counter currently is located on the field pos1. The next field would be pos2 (indicated by the next link) and so on. That means that Alice’ counter is located three fields ahead of Bob’s. Note, that we also have a ludo object representing the game, its status and its rules. Finally, there is the theDie object which represents the die currently showing a 3. The syntax of the UML object diagram is given as an information by the teacher during the discussion while he/she draws the object diagram on the whiteboard following the suggestions of the students. That way, the syntax of the diagram is understood very fast although or because we focus on the information modeled with it, not only on the notation. At the end of the first or second lesson the object diagram shown in Fig. 1 has been derived and the first issues of the modeling language UML have been taught. 3.

STATIC MODEL: CLASS DIAGRAMS

Creating class diagrams has been the main concern in OOM for a long time. But starting modeling on class diagram level has turned out to be too complicated for our students. The level of abstraction was simply too high. That’s why we start with objects. After having drawn the first object diagrams the class diagram is introduced as a construction plan for object diagrams. First, we have to think about the common structure behind the object diagram. Every object has to be bound to a class. The decisions, which objects belong to the same class, rely on the common relationships and attributes. If every object in the object diagram has got a class we can easily and systematically derive the class diagram from this object diagram: Collect all occurring classes in the main class diagram. Attributes used and methods called on an object are then added to its class. A relationship between two objects results in an association between the corresponding classes. Note, that using this approach our students have no longer problems understanding self associations. This way the class diagram simply evolves out of the object diagram. If you go through the elements of the object diagram in Fig. 1 and if you collect appropriate classes, you will automatically end up with a class diagram similar to the one presented in Fig. 2.

Figure 2: Class diagram of Ludo example In our courses this class diagram is derived in one or two lessons as well. Like the syntax of the object diagram the syntax of the class diagram is introduced by the teacher as an information when it is needed. Relying on the fact that the syntax of these two diagrams is quite similar, this usually causes minor problems. Only the cardinality direction is sometimes difficult for some students. Fortunately, as in this example, most examples employ a lot of different cardinalities for different associations. Thus, this detail is trained, early. More complex concepts of object-oriented modeling, like e.g. inheritance, differentiation between association, aggregation and composition, design patterns etc. are not that important in such an early phase of learning modeling. They can easily be introduced later when needed. 4.

MODELING BEHAVIOR

To model behavior, we use a scenario-based approach. The problem is analyzed by modeling several example runs. To model the steps of a scenario we change the object diagram of the initial situation, e.g. a relationship (link) is destroyed and a new link is created or a value of an attribute is changed or objects are created or destroyed. In addition, one may draw message invocations as UML collaboration messages. In a class room, we recommend to do the object modifications directly on the whiteboard with marker and sponge. In addition we log the changes in textual comments that may and should be used when programming the methods. In homework or written exercises or to analyse the changes in the object structure in more complex scenarios, the object diagram changes may be pictured like a comic strip, cf. Fig. 3. Here, we recommend simple UML 2.0 interaction diagrams where each interaction box contains a UML collaboration diagram. Using collaboration diagrams allows the usage of and stereotypes to mark object diagram changes. We call such specialized interaction diagrams story boards. Fig. 3 shows a story board modeling the move of player bob in the situation modeled already in Fig. 1. The syntax of story boards is quite similar to the syntax of object diagrams on the one hand and on the other hand quite similar to the syntax of our executable rule diagrams (see Chapter 5), and is additionally quite intuitive as well. The story boards can be drawn very easily with the Fujaba Tool Suite[8], because with it you don’t have to draw every step but only the first and the changes. While “playing” a scenario new kinds of objects, new kinds of links, new attributes or new kinds of messages may be introduced. Such extensions have to be added to the class diagram. Thus, dynamic and static model grow together. However, we emphasize the role of object diagrams and scenarios. Here, we do most of the modeling and design work. The class diagrams are more or less an intermediate step towards the desired OO program. At the end of this phase the students have created a very good mental and object oriented model in UML of the given problem. They understand the relationships between the occurring objects and their sphere of action. They changed their point of view from the top view to an internal view. In some way they can see the problem with the objects’ eyes so that problems in the following implementation phase are reduced.

Figure 3: Story board of scenario move counter

5.

MODEL IMPLEMENTATION

Up till now the above steps are easily done using pen and paper or on the whiteboard in team sessions. Now, we need a running program to prove the successful solving of the problem and to show the progress. For the structural part of the desired program, we recommend to use a CASE tool in order to generate the program code for the class and attribute declarations. Good CASE tools will even generate sound implementations for associations, e.g. Rhapsody[12], Rational Rose[13] and Fujaba[8]. Using a CASE tool for this purpose frees us from teaching all the syntactical elements of OO programming language at the beginning of our course. We propose to hide this part of the program from the freshmen at the beginning. Instead we

may now use e.g. a Java interpreter like BeanShell[2] or Koala[11]. Such a Java interpreter may be equipped with the compiled class structures and then the student may enter his or her first program commands on a simple prompt or using simple script files. This way, the freshmen start with commands like p1 = new Player(), p1.name = “bob”, etc. On this basis, we may introduce control structures, methods, etc. step by step. Note, using an interpreter for the first programming steps is proposed for classical imperative approaches, too. This at least avoids starting with the quite complicated “public static void main” construct. However, if you do not start with object-oriented modeling but you start with programming directly, then you are restricted to programming tasks dealing with numbers (e.g. Sieve of Eratosthenes) or tasks dealing with strings. If you start with OO modeling, you teach the students the right concepts and you may start with more interesting programming tasks as e.g. Ludo or other board games or internet shops, etc. In our courses, we go one step further. We create the complete running model without touching any source code. For this purpose we use so called rule diagrams, that look similar to story boards but describe not the special but the general case and therefore contain control flow and method calls as well. From these diagrams Fujaba generates executable Java source code for method bodies (Diethelm et al. 2002 and 2004). Using Fujaba the story boards may also be used to generate JUnit tests from them with only one click (Geiger 2004, Diethelm et al. 2004). These tests are useful to test if a scenario is matched by the implemented methods. 6.

DEBUGGING

When the students have created a somewhat complex object structure with several new commands and the calls of several setters to establish links, it is sometimes difficult to find out, how the actual object structure currently looks like. Generally, it is complicated to analyze the current object structure at a given point of the execution of a program. Traditional approaches use print commands or debugging techniques for the investigation of the system state. This success for programs is dealing only with numbers and strings. For object oriented programs in our sense we need a visualization of the current Java heap. To fit our approach it would be nice if such visualization is done using UML object diagrams. Several tools supply such features, e.g. BlueJ, DOBS which is part of the Fujaba Tool Suite and the eclipse plug-ins Java Spider[10] and eDOBS[6]. Up till now only DOBS and eDOBS can properly display links between object. Additionally, DOBS and eDOBS may not only be used for visualization but also for creation and manipulation of runtime object structures. We use these tools frequently in our courses after the derivation of the first class diagrams. This allows our students to validate their model by trying to step through scenarios based on an object structure that already employs the code generated from the class diagram. This exercise helps our students to take the viewpoint of the computer and to experience the limited possibilities the computer and the objects actually have. 7.

SUMMARY

This paper outlines our approach to teach object-oriented concepts to freshmen at introductory courses in computer science at high schools and universities. Our approach starts with the analysis of example situations using object diagrams. From the object diagrams we easily derive conceptual class diagrams. From these class diagrams modern CASE tools may generate the structural parts of the desired OO program. Equipped with the structural implementation of our model, we start with the implementation of simple operations using similar concepts as in conventional programming lessons. With our approach, the students do not just learn a programming language, but they learn OO concepts and OO problem solving techniques in their very first lessons. Our approach for teaching OO concepts has been used in 9 half year courses on introduction to computer science in the 11th year of education at 3 different German high schools. In addition, it has been used in 3 courses on UML and OO modelling at University of Kassel. Our experiences are very encouraging. After roughly 10 lectures, our students are able to use the notation for lively modeling discussions. They come up with class diagrams of an astonishingly high quality. And they are actually able to program basic behavior of e.g. the Ludo board game. During the lessons, we especially observed, that our graphical notation enables excellent collaboration between our students. If one student has a modeling problem, a colleague stepping by is very frequently able to give valuable hints after just some short looks on the created diagrams. The same holds for the teachers: frequently one look success to spot the students' approach or the students' current problem. This enables collaborative learning at its best. 8.

REFERENCES

[1]

Helmut and Heide Balzert: Modellieren oder Programmieren oder beides? in LOG IN no. 128/129, LogIn-Verlag, Berlin, pp. 20-31, 2004.

[2]

BeanShell: http://www.beanshell.org

[3]

BlueJ: http://www.bluej.org

[4]

I. Diethelm, L. Geiger, A. Zündorf: UML im Unterricht: Systematische objektorientierte Problemlösung mit Hilfe von Szenarien am Beispiel der Türme von Hanoi; in Forschungsbeiträge zur “Didaktik der Informatik“ - Theorie, Praxis und Evaluation; GI Lecture Notes, pp. 33-42, 2002.

[5]

I. Diethelm, L. Geiger, A. Zündorf: Systematic Story Driven Modeling, a case study; Workshop on Scenarios and state machines: models, algorithms, and tools, ICSE 2004, Edinburgh, Scotland, 2004.

[6]

eDOBS: http://www.se.eecs.uni-kassel.de/se/index.php?edobs

[7]

L. Geiger: Automatische JUnit Testgenerierung aus UML-Szenarien mit Fujaba, Master Thesis, Technische Universität Braunschweig, 2004.

[8]

Fujaba Homepage, Universität Paderborn, http://www.fujaba.de

[9]

P. Hubwieser: Didaktik der Informatik – Grundlagen, Konzepte, Beispiele, Springer Verlag, Berlin, 2000.

[10]

JavaSpider: http://sourceforge.net/projects/javaspider

[11]

Koala: http://koala.ilog.fr/djava/

[12]

Rhapsody: http://www.ilogix.com/rhapsody/rhapsody.cfm

[13]

Rational: http://www-306.ibm.com/software/rational/

[14]

C. Schulte, J. Niere: Thinking in Object Structures: Teaching Modelling in Secondary Schools; in Sixth Workshop on Pedagogies and Tools for Learning Object Oriented Concepts, ECOOP, Malaga, Spain, 2002.

[15]

UML Resource Page, Object Management Group, http://www.uml.org 1997.

[16]

A. Zündorf: Rigorous Object Oriented Software Development, Habilitation Thesis, University of Paderborn, 2001.