{"id":9721,"date":"2017-08-06T13:56:40","date_gmt":"2017-08-06T11:56:40","guid":{"rendered":"https:\/\/www.herr-rau.de\/wordpress\/?p=9721"},"modified":"2023-06-12T09:14:38","modified_gmt":"2023-06-12T07:14:38","slug":"der-java-klassendiagramm-implementierungs-aufgaben-generator","status":"publish","type":"post","link":"https:\/\/www.herr-rau.de\/wordpress\/2017\/08\/der-java-klassendiagramm-implementierungs-aufgaben-generator.htm","title":{"rendered":"Der Java-Klassendiagramm-Implementierungs-Aufgaben-Generator"},"content":{"rendered":"
(11 Kommentare.<\/a>)<\/small> <\/div>

Nachtrag: aktualisierte Fassung des Programms ist am Ende des Beitrags<\/em><\/p>\n

Das mit dem Verstehen ist ja sch\u00f6n und gut, aber bei Sprachen – Programmiersprachen wie anderen – reicht es nicht, wenn man die grammatischen Kategorien kennt, man muss die Sprache auch anwenden k\u00f6nnen. In Bayern lernen die Sch\u00fcler in Informatik in der 10. Klasse Gymnasium (im naturwissenschaftlich-technologischen Zweig) die Grundprinzipien es objektorientierten Modellierens und Programmierens. Mit den Prinzipien haben sie auch wenig Schwierigkeiten; Klassendiagramme kriegen sie einigerma\u00dfen hin – aber das Umsetzen der Diagramme in Programmcode macht vielen mehr Probleme.<\/p>\n

Also habe ich mir vorgenommen, im n\u00e4chsten Durchgang mehr zu pauken. Eine Doppelstunde nur Klassendiagramme implementieren. Und dann nochmal, wenn es n\u00f6tig ist. Das kriegt man n\u00e4mlich nur durch \u00dcbung rein. – Ob ich das dann wirklich so mache, h\u00e4ngt nat\u00fcrlich von der konkreten Klasse ab. Aber ich habe mir schon etwas vorbereitet, und zwar den Java-Klassendiagramm-Implementierungs-Aufgaben-Generator. So sieht er aus:<\/p>\n

\"Benutzeroberfl\u00e4che<\/p>\n

Wenn man auf den wei\u00dfen Knopf kriegt, erzeugt und speichert das Programm zwei Textdateien. Die eine ist ein Klassendiagramm f\u00fcr eine zuf\u00e4llig erstellte Klasse, mit 1 zuf\u00e4llig ausgew\u00e4hlten Attribut, einem Standardkonstruktor und je einer getter- und setter-Methode f\u00fcr das Attribut:<\/p>\n

|--------------------\n| Raumschiff\n|--------------------\n| alter: int\n|--------------------\n| Raumschiff()\n| getAlter(): int\n| setAlter(int): void\n|--------------------<\/pre>\n
Wenn man sparsam mit den Leerzeilen ist, kann man das in sechs kurzen Zeilen programmieren. Wenn die Sch\u00fclerin das getan hat, importiert sie die zweite Datei, die das Programm erzeugt hat, in ihr Projekt. Diese Datei enth\u00e4lt den Code f\u00fcr eine weitere Java-Klasse, und zwar eine Testklasse, die \u00fcberpr\u00fcft, ob die Klasse auch semantisch richtig implementiert worden ist, also ob die Methoden auch das tun, was sie sollen, und ob das Attribut da ist, und ob die Datentypen und die Schreibung exakt mit dem Klassendiagramm \u00fcbereinstimmen. Die Testklasse sieht so aus, auch wenn die Sch\u00fclerin sich den Code nie anschauen muss:<\/p>\n
import static org.junit.Assert.*;\nimport org.junit.After;\nimport org.junit.Before;\nimport org.junit.Test;\n\npublic class RaumschiffTest {\n\n  Raumschiff testObject;\n\n  public RaumschiffTest() {\n  }\n\n  @Before\n  public void setUp() {\n    testObject = new Raumschiff();\n  }\n\n  @After\n  public void tearDown() {\n    testObject=null;\n  }\n\n  @Test\n  public void attributeUeberpruefen() {\n    testObject.alter = 8;\n  }\n\n  @Test\n  public void setAlterTest() {\n    testObject.setAlter(40);\n    assertEquals(40, testObject.alter);\n    testObject.setAlter(11);\n    assertEquals(11, testObject.alter);\n    testObject.setAlter(31);\n    assertEquals(31, testObject.alter);\n  }\n\n  @Test\n  public void getAlterTest() {\n    testObject.alter = -5;\n    assertEquals(-5, testObject.getAlter());\n    testObject.alter = 64;\n    assertEquals(64, testObject.getAlter());\n    testObject.alter = -17;\n    assertEquals(-17, testObject.getAlter());\n  }\n\n}\n<\/pre>\n
Mit einem Mausklick startet man den Test, und herauskommt eine Anzeige, welche Tests bestanden wurde:<\/p>\n
\"Java-Testergebnis\"<\/p>\n
Dazu muss die von der Sch\u00fclerin erstellte Klasse erst existieren, und zwar grammatisch fehlerfrei. Die Tests \u00fcberpr\u00fcfen nur, ob das Programm auch das tut, was es soll, nicht ob es \u00fcberhaupt l\u00e4uft – das sagt einem schon der Compiler eine Stufe zuvor.<\/p>\n
Man kann sich auch Klassen mit zwei, drei oder vier Attributen erzeugen lassen. Wenn die Attribute nicht als private<\/code> markiert sind, werden die Attribute \u00fcberpr\u00fcft und die getter\/setter-Methoden anhand dieser Attribute \u00fcberpr\u00fcft – ansonsten wird die getter-Methode anhand der setter-Methode auf Richtigkeit getestet, und umgekehrt. Man auch ausw\u00e4hlen, dass ein zweiter Konstruktor mit zu den Attributen passenden Argumenten erzeugt werden soll. Au\u00dferdem kann man noch ankreuzen, ob die neuen Objekte der Klasse bestimmte Startwerte f\u00fcr die Attribute haben sollen, die dann im Konstruktor festgelegt werden. Dann hei\u00dft es unter dem Klassendiagramm:<\/p>\n
Der Wert des Attributs 'alter' soll am Anfang sein: 32<\/pre>\n
Die Werte f\u00fcr die Attribute werden ebenfalls zuf\u00e4llig ausgew\u00e4hlt. Attribute k\u00f6nnen vorerst nur vom Typ String, boolean, char, double, int<\/code> sein. Die Testklasse wird jeweils unter Ber\u00fccksichtigung all dieser Entscheidungen erstellt.<\/p>\n
Das k\u00f6nnte man jetzt ausweiten und die Sch\u00fcler selber Klassenbezeichner und Attribute ausw\u00e4hlen lassen. Oder mit Referenzattributen arbeiten, dass also – f\u00fcr den Anfang – zwei Klassendiagramme erstellt werden, wobei das eine ein Referenz auf das zweite enth\u00e4lt.<\/p>\n
Wen es st\u00f6rt, dass das so eine Art Liegest\u00fctzen f\u00fcr Java sind, also eher sinnlose, wiederholende \u00dcbungen, der kann sich vielleicht daran erfreuen, dass die Sch\u00fcler so an den Umgang mit Testklassen und Testverfahren herangef\u00fchrt werden.<\/p>\n