Klassenentwurf

Bei einem größeren Softwareprojekt ist die schwierigste Aufgabe, geeignete Klassen zu entwerfen. Die Entwurfsentscheidungen beeinflussen hinterher den Schwierigkeitsgrad der Programmierung ganz erheblich. Bei einem guten Entwurf bleibt die Übersichtlichkeit gewahrt und Fehler werden vermieden. Aber wie kann man einen geeignete Klassen finden?

Geschäftsprozesse

Grundsätzlich ist es zunächst entscheidend, dass man sich darüber klar wird, wofür die Klassen erstellt werden. Leider wird oftmals (auch in Schulbüchern) die Aufgabe gestellt, die Realität in Klassen abzubilden (z.B. den Fuhrpark eines Unternehmens oder eine Bank). Diese Aufgaben müssen scheitern, da nicht klar ist, welche Aspekte der Realität von Bedeutung sind. Außerdem – und das ist noch entscheidender – ist nicht klar, wer eine Aktion auslöst und wer nur auf Aufträge reagiert (Bekommt der Gärtner die Methode gießen oder das Beet?). Daher muss die Aufgabe immer lauten: „Es soll ein Computerprogramm geschrieben werden, bei dem der Anwender folgende Aktionen durchführen kann...“. Der erste Schritt bei einem Softwareprojekt muss also sein, die möglichen Aktionen des Benutzers zu identifizieren. Er wird sie dann im Computerprogramm durch Klicken auf einen Button oder Auswahl eines Menüpunktes anwenden. Damit ist klar, wer die Aktion auslöst. Die Objekte beschreiben dann nicht mehr die realen Gegenstände/Personen, sondern speichern nur noch die Informationen, die das Computerprogramm kennen muss. Es ist dann beispielsweise bei einem Bankverwaltungsprogramm klar, dass ein Objekt von der Klasse Kunde, nicht mehr selbst aktiv werden kann, sondern dass die Methode „einzahlen“ bedeutet, dass die Kundendaten so angepasst werden sollen, dass der angegebene Betrag dem Konto gutgeschrieben wird. Dies ist ein großer Unterschied.

Die Aktionen, die der Anwender auslösen kann, werden in der objektorientierten Modellierung Geschäftsprozesse genannt. Diese müssen in der freien Wirtschaft zwischen Auftraggeber und Softwarefirma in einem Pflichtenheft exakt definiert werden. Spätere Änderungen machen einen geeigneten Klassenentwurf oftmals unmöglich.

Klassen identifizieren

Sobald klar ist, welche Aktionen der Anwender mit dem Programm durchführen können soll, kann man sich auf die Suche nach geeigneten Klassen machen. Dabei hilft es, in der Aufgabenstellung nach Substantiven zu suchen. Diese Substantive bezeichnen häufig Objekte oder Attribute der Objekte, die für das Programm relevant sind. Die Objekte sollten abgeschlossene Einheiten darstellen.

Gleichartige Objekte werden in Klassen zusammengefasst und führen zu einem ersten Klassenentwurf. Später können weitere Klassen hinzukommen oder überflüssige weggelassen werden.

Attribute und Methoden

In den ersten Klassenentwurf können nun auch die identifizierten Attribute aufgenommen werden. Dabei sollte unbedingt darauf geachtet werden, dass nur die für das Programm relevanten Informationen gespeichert werden. Die Realität hält zu viele Details bereit, als dass diese alle im Programm Berücksichtigung finden könnten.

Um die Geschäftsprozesse durchführen zu können, müssen die Objekte angesprochen werden können. Sie müssen Aufgaben erledigen oder Informationen liefern. Dazu kann es notwendig sein, dass sie ihrerseits weitere Aufträge an andere Objekte erteilen. Diese Aufträge stellen die Methoden der Objekte dar und können in den Klassenentwurf aufgenommen werden. Die für einen Auftrag notwendigen Informationen müssen die Objekte entweder selbst kennen, da sie in den Attributwerten des Objekts gespeichert sind, oder durch Parameter beim Methodenaufruf mitgeteilt bekommen. Beispiel: einzahlen(double betrag);

Objektspiel

Es ist relativ schwierig, alle Aspekte einer Klasse von vornherein vollständig zu berücksichtigen, da in der Praxis vielfältige Interaktionen zwischen den Objekten der verschiedenen Klassen auftreten. Um den Klassenentwurf auf stabilere Füße zu stellen, bietet es sich an, die Geschäftsprozesse in einem Rollenspiel durchzuführen. Die folgende Darstellung ist weitgehend aus dem life³-Projekt der Uni Paderborn übernommen¹.

Dazu werden zunächst für die Klassen CRC-Karten² erstellt. Das Kürzel CRC steht für Classes, Responsibilities, Collaborators (Klassen, Verantwortlichkeiten, Beteiligte). CRC-Karten sind damit nichts anders als "Karteikarten", auf denen oben der Klassenname, und in zwei Spalten darunter je die Verantwortlichkeiten (Aufgaben) und die Klassen, mit denen zur Erledigung dieser Verantwortlichkeiten zusammengearbeitet werden muss, vermerkt werden:

Die CRC-Karten stellen damit die nach außen sichtbare Schnittstelle zu den Objekten dar. Die internen (private) Attribute sind auf ihr nicht vermerkt. Diese werden separat auf einer Objektkarte festgehalten. Die CRC-Karten leben davon, dass sie noch nicht so formal wie die Klassenkarten sind und viele Details später noch festgelegt werden können (z.B. notwendige Parameter) Dadurch werden spontane Änderungen leichter.

Diese CRC-Karten werden dann als Grundlage für ein Rollenspiel verwendet. Sie müssen für alle sichtbar aufgestellt werden. Die Schülerinnen und Schüler übernehmen jeweils die Rolle eines Objektes einer dieser Klassen. Sie erhalten dazu je eine Objektkarte, auf der sie den Namen des Objekts, seine Klasse und seine Attributwerte zum aktuellen Zeitpunkt festhalten und dann während des Spiels anpassen.

Unter Anleitung des Lehrers spielen die Schüler einzelne Abläufe durch. Der Lehrer stellt den Anwender des Computerprogramms dar, der die Aktionen von außen auslöst, indem er beispielsweise festlegt, wer als erster spricht. Diese „Startaktion“ kann später entweder in der UML-Ansicht durch Aufruf einer Methode erfolgen oder wird mit Hilfe einer GUI durch einen Button ausgelöst.

Der Lehrer gibt also Aufträge an die Schüler/Objekte. Die Schüler dürfen dabei nur die Aufgaben verrichten, die auf ihren Klassenkarten notiert sind. Hierzu dürfen sie auch Objekte der auf ihrer CRC-Karte notierten interagierenden Klassen zur Mitarbeit auffordern. Weiterhin dürfen sie nur von dem Wissen Gebrauch machen, das auf ihren Objektkarten festgehalten ist.

Die Regeln des Objektspiels sind also:

• nur verbale Kontaktaufnahmen zu anderen Objekten sind erlaubt,

• nur die auf den CRC-Karten aufgelisteten Aufträge sind erlaubt,

• nur mit den auf der CRC-Karte vermerkten Beteiligten darf Kontakt aufgenommen werden,

• es dürfen nur die auf der Objektkarte vermerkten Attributwerte verwendet werden ( "keine Gedächtnisleistung des Rolleninhabers").

Bei diesem Spiel müssen alle Geschäftsprozesse durchgespielt werden. Merken die Schüler dabei, dass die CRC-Karten unvollständig sind, dürfen diese sofort angepasst werden. Fehlen Informationen auf den Objektkarten dürfen auch hier weitere Attribute hinzugefügt werden.

Möchte man das Thema Sequenzdiagramme im Unterricht behandeln, dann bietet es sich an, während des Objektspiels einen Protokollanten zu bestimmen, der festhält, welche Interaktionen zwischen den Objekten stattfinden. Das Ergebnis dieses Protokolls ist dann im Prinzip schon ein Sequenzdiagramm.

Sequenzdiagramm

Bei einem Softwareprojekt, das mehrere Klassen und damit noch mehr Objekte umfasst, verlieren die Schüler leicht den Überblick über die Interaktionen zwischen diesen Klassen. Bei der Implementierung ist es später sinnvoll, diese arbeitsteilig zu erledigen, da die Aufteilung eines Projekts in kleine, möglichst unabhängige Einheiten ein entscheidender Vorteil der objektorientierten Programmierung ist. Das kann aber nur dann funktionieren, wenn alle Schüler die Zusammenhänge zwischen den Klassen verstehen und absolut klar ist, welche Funktionen die einzelnen Methoden erfüllen sollen. Dies ist ein weiteres Argument, das Objektspiel durchzuführen. Dieser Effekt wird noch verstärkt, wenn das Ergebnis des Objektspiels als Sequenzdiagramm festgehalten wird. Man kann aber auch auf die Sequenzdiagramme verzichten, wenn die Zeit im Unterricht nicht ausreicht. In den Bildungsstandards sind sie nicht gefordert.

Sequenzdiagramme sind neben UML-Diagrammen die wichtigste Diagrammart in der objektorientierten Modellierung. Sie zeigen, den Ablauf der Interaktion zwischen den Objekten. Man kann also gut erkennen, welches Objekt welche Methode eines anderen Objekts aufruft. Es kann im Unterricht nicht darum gehen, Sequenzdiagramme in der vollen Tiefe ihrer Möglichkeiten zu behandeln oder die formale Darstellung zum Unterrichtsthema zu machen. Es reicht eine sinngemäße Darstellung, die sich an die Sequenzdiagramme hält.

Im Sequenzdiagramm werden die Objekte nebeneinander dargestellt. Von oben nach unten wird der zeitliche Ablauf visualisiert. Dabei ist nicht der exakte Zeitpunkt, sondern nur die Reihenfolge der Aufrufe entscheidend. Jedes Objekt hat eine Lebenslinie, die mit dem Zeitpunkt der Erstellung (new-Operator) beginnt. Ruft ein Objekt eine Methode eines anderen Objektes auf, dann wird diese durch einen Pfeil symbolisiert. Solange die Methode aktiv ist, wird die Lebenslinie zu einem dicken Balken. Der Rücksprung zum aufrufenden Objekt wird am Ende auch wieder durch einen Pfeil symbolisiert. Gerade dieses Hin- und Herspringen zwischen verschiedenen Objekten und Methoden ist am Anfang für Schüler nicht einfach zu durchschauen und wird durch das Sequenzdiagramm unterstützt.

Eine gute Übung ist es auch, einen fertigen Quelltext in ein Sequenzdiagramm überführen zu lassen. Dies fördert das Verständnis für den Quelltext, da genau geprüft werden muss, welche Methodenaufrufe im Quelltext vorkommen und welche weiteren Methodenaufrufe dieser Aufruf nach sich zieht. Zur Erstellung von einfachen Sequenzdiagrammen kann beispielsweise das Programm Quick Sequence Diagramm Editor³ verwendet werden.

Klassendiagramm

Anschließend sollte nun das vollständige Klassendiagramm mit allen Beziehungen zwischen den Klassen erstellt werden. Dies ist keine größere Schwierigkeit mehr, da alle Methoden und Attribute schon erarbeitet wurden. Lediglich die Beziehungen zwischen den Klassen können noch diskutiert werden. Am Ende sollte ein für alle verbindliches Klassendiagramm stehen, das eventuell auch vom Lehrer schriftlich ausgeteilt werden kann, um sicherzustellen, dass wirklich alle Schüler mit den gleichen Klassendefinition arbeiten. Nur dann ist die Implementierung des Softwareprojekts arbeitsteilig möglich.

---

¹ Objektspiel, life³-Projekt Uni Paderborn, (Stand: 07.08.2012)

² CRC-Karten, life³-Projekt Uni Paderborn, (Stand: 07.08.2012); Ursprünglich stammt die Idee der CRC-Karten von Kent Beck (Apple Computer, Inc.) und Ward Cunningham (Wyatt Software Services, Inc.). Zum Originalartikel, (Stand: 07.08.2012)

³ Quick Sequence Diagramm Editor, Markus Strauch, (Stand: 08.08.2012); Die Sequenzdiagramme werden dabei in Form von Texteingaben erstellt. Die verfügbare Hilfe und die Beispiele muss man sich anschauen, um zu verstehen, wie es funktioniert. Dann ist ein Sequenzdiagramm aber schnell erstellt.

 

 

Klassenentwurf: Herunterladen [odt][82 KB]

 

Weiter zu Vorlagen im Tauschordner