Teaching Basic Class Diagram Notation with UMLGrader

We discuss using UMLGrader as a tool for teaching class diagram notation in the Unified Modeling Language (UML). Given a diagram which is constructed to model a tightly constrained problem, the tool compares the diagram against a standard solution and provides feedback on missing elements and other errors. This supports using canned exercises to familiarize students with UML notation. We describe the tool and discuss its use in courses at the sophomore and junior levels. In each case, we report on the results of before and after tests, showing that there was significant improvement after using the tool. Software engineers are expected to be able to model software systems with diagrams.1, 14 However, experience shows that teaching students to use this notation is surprisingly difficult, at least in the case of the Unified Modeling Language (UML).3, 8, 19 The traditional method18, 19 for teaching diagram notation is to give students open-ended design problems and have the students use the notation to design solutions. The assumption is that students will gain skills in abstract problem solving while at the same time learning to use the notation.7 The obvious approach is to increase the size of the problems over the course of the curriculum, asking students to model systems with just a few classes in introductory courses and progressing to very large systems in advanced courses. Our experience calls this assumption into question, and we start with an example that illustrates this. At University of Wisconsin-Platteville, where much of this work was done, students are introduced to UML class diagram notation in the introductory programming sequence with further exposure in the first software engineering course. Upper-divisional courses then expand on this, covering additional diagram types as well as design patterns.9 In particular, one of these courses devotes considerable time on the command pattern. For several years, the first exam included a modeling question in which students applied the command pattern to a simple problem, and only a few students were able to give a satisfactory answer. In 2011, a simpler modeling problem was added to evaluate student’s basic skills: Draw a class diagram modeling the following: • Snow removal drivers have routes and are assigned trucks with which they clear those routes. Each route is the responsibility of one driver. • Trucks have numbers. There are two types of trucks: dump trucks and snow plows. For dump trucks, there is a name of the type of equipment attached. • A route is a sequence of street segments to traverse. • A street has a name and is made up of a sequence of segments, where each segment is defined by the crossing streets that start and end that segment. If the street is a dead-end, the crossing street is NULL. Show classes, associations, multiplicities, attributes, operations, and generalizations. P ge 24157.2 The intended response is given in in Figure 1.1 Since the notation had been introduced in earlier Figure 1: Snow plow class diagram courses and reviewed within the week before the exam, it was assumed few students would find the question challenging. Furthermore, approximately half of the students had previously taken a course called “Object-Oriented Analysis and Design” which devotes nearly a third of a semester to UML notation. However, students performed rather poorly on this question. The question was graded on a four point scale, and just 7 out of 37 received a score of 3 or higher while 20 students received a score less than 2. The students had little difficulty identifying classes—only 8 failed to identify one of the classes, and none failed to identify two—but many failed to name association roles and there were many cases in which students reversed multiplicities or used the wrong notation for generalization. The students were clearly not adequately prepared for the problem. This experience and others leads us to question the basic assumption identified in the introduction: that having students solve open-ended design problems is an effective way to teach UML diagram notation. One challenge is that the open-ended problems must be designed to exercise all of the intended notation, and if a student fails to understand where to apply a particular notation then the student misses on the opportunity to learn to use that notation. Another challenge is that grading these types of problems is very time-consuming, making it unlikely that students will receive quick feedback on how they used the notation. This paper presents an alternative approach based on teaching the notation separately from teaching its application. Teaching notation could be done in the traditional manner: assigning exercises to create diagrams that are hand-graded. While grading constrained problems is easier than open-ended ones, the turnaround time would still be a limiting factor. We developed a tool, UMLGrader, which automates the process of comparing diagrams to give more immediate feedback. Students are given a constrained problem, use a tool such as IBM Rhapsody to draw up a solution, and submit it to UMLGrader. UMLGrader responds with a list of differences between the student’s solution and the expected solution. This feedback is designed to strike a balance between guiding the students to acceptable solutions and simply telling them what to change. The result is that students can be drilled on UML notation separately from solving open-ended problems. This paper presents evidence that this approach is effective: that using UMLGrader to learn 1The problem statement is ambiguous with respect to some multiplicities, and these were ignored during grading. P ge 24157.3 diagram notation improves performance on exam questions. In addition, we present data on the types of errors made by students. The ultimate question—whether using UMLGrader improves performance on more general design problems—is necessarily left as future work. However, we believe that our results show that UMLGrader is at least useful for teaching core notation. Other approaches to teaching UML notation can certainly be considered. One is to use tools specialized for student use.2, 16, 20 Because these tools are specialized, they can be more targeted at meeting curricular goals. However, none of the existing tools have been evaluated for teaching basic notation, and none provide support for model comparison. There are other, non-modeling tools which can detect inconsistencies between different modeling diagrams. Some of these are intended for educational use4, 16 while others for professional use.5, 6, 13, 15 However, each of these require constructing multiple, interrelated diagrams documenting both the static and dynamic elements of the system. Their use depends on understanding the full range of diagram types and so are not practical for introductory students.