Klasse vermitteln! (K)ein Drama in 11 Akten – 4. Akt: Objekte nennen

Im Rahmen dieser Blogserie stellen wir Ihnen vor, wie wir das Wissen vermitteln das Sie benötigen, um ein Begriffsmodell auf Basis des UML-Klassendiagramms zu erstellen. Wenn Sie noch einmal nachlesen möchten, finden Sie hier den vorigen Artikel.

Heute stellen wir eine kreative Methode vor, mit der wir den Unterschied zwischen einem Objekt und einer Klasse im Verständnis des UML-Klassendiagramms erarbeiten lassen.

Zuordnungsaufgabe – die Lösung

Im letzten Teil dieser Blogserie haben wir Ihnen die Zuordnungsaufgabe präsentiert, bei der das Szenario herausgefunden werden soll, bei dem ein Klassendiagramm als Begriffsmodell sinnvoll ist.

Wie Sie bestimmt richtig erkannt haben, macht dies bei folgendem Szenario am meisten Sinn.

Zur Begründung:

Da Sie nun wissen, wo der Einsatz eines Begriffsmodells auf Basis des UML-Klassendiagramms sinnvoll ist, können wir weiter in dieses wichtige Themengebiet eintauchen.

Die Unterscheidung zwischen Objekt und Klasse

Um ein Begriffsmodell auf Basis des Klassendiagramms modellieren zu können, ist es essenziell, die Notationselemente zu kennen. Welches Notationselement könnte zu einem KLASSENdiagramm gehören? Richtig, die Klasse. Doch was ist eine Klasse eigentlich genau? Ich habe doch auch einmal den Begriff „Objekt“ aufgeschnappt – ist das nicht das Gleiche? Oder ist das etwas Anderes, und wenn ja: wie kann man diese Begriffe unterscheiden? Das sind die typischen Fragen, die Trainingsteilnehmer in dieser Phase des Lernens beschäftigen.

Eine Klasse und ein Objekt sind nicht das Gleiche – klar, darauf wären Sie auch selbst gekommen. Wo beginnt man nun mit der Unterscheidung?

Bevor wir im Rahmen des Innovationsprojektes zur Wissensvermittlung im Requirements Engineering eine neue Methode entwickelt haben, die wir Ihnen gleich präsentieren, wurde dieses deklarative Wissen (also der Unterschied zwischen Objekt und Klasse) in Form eines Vortrags vermittelt. Die Umschreibung passierte in etwa wie hier dargestellt:

Nach [Rupp2009] versteht die UML unter einer Klasse eine Sammlung von Exemplaren, die über gemeinsame Eigenschaften, Einschränkungen und Semantik verfügen. Somit stellt jede Klasse einen abstrahierten Sammelbegriff für eine Menge an gleichartigen Dingen dar. Eine Klasse kann also als eine Art Bauplan oder Schablone gesehen werden, nach der man Objekte erzeugt. Ein Beispiel für eine solche Klasse kann beispielsweise „Stuhl“ sein. Ein Stuhl zeichnet sich immer durch folgende Eigenschaften aus: Er besitzt Stuhlbeine und eine Sitzfläche sowie eine Farbe.

Objekte hingegen sind konkrete Ausprägungen einer Klasse, d.h. sie haben konkrete Eigenschaften. So kann aus der Klasse Stuhl das Objekt „Hocker Nummer 27“ erzeugt werden, der 3 Stuhlbeine und eine runde Sitzfläche aus Lederimitat hat, die schwarz ist.

Übertragen auf den RE-Kontext kann „textuelle Anforderung“ eine Klasse sein, die als Eigenschaften „Text“, „rechtliche Verbindlichkeit“ und eine „ID“ besitzt.

Ein Objekt kann folgende Anforderung sein:

„Anforderung Bib-002: Das Bibliothekssystem muss dem Bibliothekar die Möglichkeit bieten zu drucken.“ [Rupp2009]

Warum verwenden wir „Objekte nennen“ als Form des fachlichen Gesprächs?

Im Rahmen unseres Innovationsprojektes haben wir wertvolle Erkenntnisse gesammelt:

Der Konstruktivismus als didaktischer Ansatz nach [Dewey1910] beschreibt, dass Wissen besser im Gehirn verankert werden kann, wenn es selbst erarbeitet wurde und mit Handlungen und Erfahrungen verknüpft ist. Diese Erkenntnis findet man auch in der weitverbreiteten Aussage „aus Fehlern lernen“, und wahrscheinlich haben auch Sie diese Erfahrung bereits gemacht.

Die Übung „Objekte nennen“ soll Fehler provozieren, und durch angeleitetes Hinterfragen eine eigenständige Erarbeitung der richtigen Lösung ermöglichen.

Damit Sie sich jedoch kein falsches Wissen aneignen, muss der Trainer sehr stark lenkend und moderierend eingreifen – wenn die Lernenden jedoch schon auf einem guten Weg sind, den Unterschied zu verstehen, ist ein Eingreifen nicht nötig.

Objekte nennen

Aus den oben präsentierten Ergebnissen unserer Forschung haben wir uns für das Handlungsmuster „fachliches Gespräch“ entschieden und in Form einer kreativen Aufgabe namens „Objekte nennen“ verpackt.

Wir fordern unsere Trainingsteilnehmer auf, Objekte zu nennen, die sie im Schulungsraum sehen. Dabei ist es wichtig, dass die Teilnehmer, die den Unterschied zwischen Klasse und Objekt bereits kennen, sich zunächst zurückhalten. Üblicherweise werden Begriffe genannt wie „Stuhl“ oder „Tisch“. Wir notieren die genannten Beispiele auf Moderationskarten – auch wenn wir wissen, dass die genannten Begriffe Klassen darstellen und nicht Objekte. Durch geschicktes Fragen und Hilfestellungen lassen wir die Teilnehmer rätseln, warum die genannten Begriffe einer Klasse entsprechen. Die Teilnehmer kommen dann schnell darauf, dass beispielsweise „der Stuhl auf dem ich sitze“ ein Objekt ist.

Wir leiten sie weiterhin dabei an, sich den Unterschied zwischen Objekt und Klasse selbst zu erarbeiten. Die gesammelten Moderationskarten werden dann gemeinsam noch einmal besprochen und nach Objekt und Klasse sortiert.

Ein Ergebnis dieser Aufgabe sehen Sie hier:

Im nächsten Blogbeitrag stellen wir Ihnen das Handlungsmuster „perspektivenbasiertes Lesen“ vor. Seien Sie gespannt und wir freuen uns schon darauf, Sie wieder begrüßen zu dürfen.

Quellen & Literatur

[Dewey1910] Dewey, John: How we think. D.C.Heath & Co., Boston, New York, Chicago, 1910.

[Rupp2012] Rupp, Chris; Queins, Stefan: UML2 glasklar – Praxiswissen für die UML-Modelllierung.4. Auflage, Carl Hanser Verlag, München, 2012.

[Rupp2009] Rupp, Chris & die SOPHISTen: Requirements-Engineering und –Management – Professionelle, iterative Anforderungsanalyse für die Praxis. 5.Auflage, Carl Hanser Verlag, München, 2009.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.


drei × = 15