Mit UML einen Softwareentwurf verständlich machen

Drei Gespräche, drei verschiedene Fragen

Die Fahrradwerkstatt Nordkette möchte ein Portal für Reparaturtermine einführen. Kundinnen und Kunden sollen einen Terminwunsch mit Fahrradtyp und Fehlerbeschreibung senden. Die Disposition prüft den Wunsch, reserviert einen freien Werkstattplatz und bestätigt oder lehnt die Anfrage ab.

Im ersten Gespräch fragt die Werkstattleitung: “Wer kann im Portal was tun?” Die Entwicklerin fragt danach: “Welche fachlichen Objekte und Beziehungen brauchen wir?” Beim technischen Entwurf kommt noch eine dritte Frage hinzu: “Welche Softwareteile sprechen beim Bestätigen eines Termins in welcher Reihenfolge miteinander?”

Eine einzige Zeichnung beantwortet diese Fragen nicht gleich gut. UML, die Unified Modeling Language, bietet verschiedene Sichten auf ein System. Eine Sicht hebt gezielt einen Teil hervor und lässt anderes weg. Das macht UML zu einem Kommunikationswerkzeug, nicht zu einem vollständigen Abbild der späteren Software.

Nach dieser Lektion kannst du:

• eine passende Sicht für eine Entwurfsfrage auswählen,
• aus Anforderungen Akteure, Anwendungsfälle und Klassen ableiten,
• ein kleines Klassen- und Sequenzdiagramm lesen,
• ein Modell gegen den Ausgangstext prüfen.

Du solltest bereits wissen, was eine Klasse und ein Objekt sind. Die Lektion erklärt nicht die gesamte objektorientierte Programmierung und nicht alle UML-Symbole. Sie konzentriert sich auf Entscheidungen, die du in einem überschaubaren Softwareentwurf begründen kannst.

Wähle die Sicht nach der Frage aus

Bevor du ein Diagramm zeichnest, klärst du seinen Zweck und die Personen, die damit arbeiten sollen. Vier Sichten sind für den Einstieg besonders hilfreich:

Ein Anwendungsfalldiagramm betrachtet das System von außen. Akteure stehen für Rollen oder andere Systeme. Anwendungsfälle benennen Ziele, die diese Akteure mit dem betrachteten System erreichen wollen.

Ein Klassendiagramm zeigt statische Struktur. Es kann Klassen, Attribute, Methoden und Beziehungen enthalten. “Statisch” bedeutet nicht, dass sich Daten nie ändern. Gemeint ist, dass das Diagramm nicht den zeitlichen Ablauf eines einzelnen Vorgangs zeigt.

Ein Aktivitätsdiagramm beschreibt einen Fluss aus Aktionen, Entscheidungen und möglichen parallelen Wegen. Ein Sequenzdiagramm konzentriert sich dagegen auf den Nachrichtenaustausch zwischen konkreten Beteiligten. Beide zeigen Verhalten, beantworten aber unterschiedliche Fragen.

Zuordnungsaufgabe

Ordne jeder Entwurfsfrage eine Sicht zu

Wähle die Diagrammart, die die jeweilige Frage am direktesten beantwortet.

Welche Rolle darf einen Terminwunsch bestätigen? Bitte zuordnen AnwendungsfalldiagrammKlassendiagrammAktivitätsdiagrammSequenzdiagramm

Richtig zugeordnet. Prüfe diese Zuordnung noch einmal.

Wie viele Terminwünsche kann ein Werkstattplatz haben? Bitte zuordnen AnwendungsfalldiagrammKlassendiagrammAktivitätsdiagrammSequenzdiagramm

Richtig zugeordnet. Prüfe diese Zuordnung noch einmal.

Welche Schritte folgen auf einen belegten Werkstattplatz? Bitte zuordnen AnwendungsfalldiagrammKlassendiagrammAktivitätsdiagrammSequenzdiagramm

Richtig zugeordnet. Prüfe diese Zuordnung noch einmal.

Ruft der Terminservice zuerst die Platzsuche oder zuerst den Benachrichtigungsdienst auf? Bitte zuordnen AnwendungsfalldiagrammKlassendiagrammAktivitätsdiagrammSequenzdiagramm

Richtig zugeordnet. Prüfe diese Zuordnung noch einmal.

Zuordnung prüfen Neu versuchen

von 4 richtig

Rollen und Ziele gehören in die Anwendungsfallsicht. Klassen und Multiplizitäten beschreiben Struktur. Ein Aktivitätsdiagramm führt durch Arbeitsschritte und Entscheidungen. Die zeitliche Reihenfolge von Nachrichten zwischen Beteiligten zeigt ein Sequenzdiagramm.

Die Anwendungsfallsicht klärt Systemgrenze und Ziele

Aus dem Szenario lassen sich zunächst zwei menschliche Rollen ableiten:

• Die Kundschaft möchte einen Terminwunsch senden und dessen Status sehen.
• Die Disposition möchte offene Wünsche prüfen, einen Werkstattplatz reservieren und eine Entscheidung festhalten.

Die Rollen sind Akteure, weil sie von außen mit dem Portal zusammenarbeiten. “Datenbank” ist hier kein Akteur. Sie liegt innerhalb der geplanten Lösung und verfolgt kein eigenes fachliches Ziel. Ein externer Benachrichtigungsdienst könnte dagegen als technischer Akteur erscheinen, wenn sein Zusammenspiel mit dem Portal für die betrachtete Frage wichtig ist.

Ein kleiner Entwurf lässt sich auch ohne Grafik eindeutig notieren:

Die Tabelle ersetzt kein formal gefordertes Anwendungsfalldiagramm. Sie ist aber ein guter Zwischenschritt: Erst wenn Akteure, Ziele und Systemgrenze stimmen, lohnt sich die Notation mit Akteuren, Ellipsen und Beziehungen.

Zwei Beziehungen werden häufig verwechselt:

• <<include>> bedeutet, dass ein Anwendungsfall einen anderen immer als gemeinsamen Teil einbezieht.
• <<extend>> ergänzt einen Basisfall nur unter einer Bedingung an einem vorgesehenen Erweiterungspunkt.

Für Nordkette muss “Werkstattplatz reservieren” bei jeder Bestätigung erfolgreich stattfinden. Wird “Terminwunsch bestätigen” als eigener Anwendungsfall modelliert, kann die Reservierung als verpflichtend einbezogener Teil betrachtet werden. Eine optionale SMS wäre dagegen eine mögliche Erweiterung, wenn die Kundschaft diesen Kontaktweg gewählt hat.

Schnellcheck

Prüfe die Anwendungsfallsicht

Entscheide dich bei jeder Frage. Du bekommst die Erklärung direkt nach deiner Antwort.

/2

Das Team nimmt die Datenbank als Akteur auf, weil sie Terminwünsche speichert. Was ist in der beschriebenen Systemgrenze die beste Korrektur?

Das passt.

Noch nicht ganz.

Akteure stehen außerhalb der betrachteten Systemgrenze und arbeiten mit dem System zusammen. Die interne Datenbank gehört in diesem Entwurf zur Lösung. Würde ein eigenständiges Fremdsystem betrachtet, könnte es als technischer Akteur auftreten.

Nächste Frage

Eine Bestätigung darf nur entstehen, wenn ein Werkstattplatz reserviert wurde. Welche Beziehung beschreibt diesen verpflichtenden gemeinsamen Teil am ehesten?

Das passt.

Noch nicht ganz.

Die Reservierung ist im Szenario ein notwendiger Teil jeder Bestätigung. include drückt diesen verpflichtenden Teil aus. extend wäre für eine bedingte Ergänzung geeignet.

Ergebnis ansehen

Geschafft

von 2

Situationen richtig eingeordnet.

Quiz noch einmal machen

Das Klassendiagramm ordnet Verantwortlichkeiten und Beziehungen

Aus Nomen im Anforderungstext entstehen nicht automatisch Klassen. “Fehlerbeschreibung” ist hier eher ein Attribut des Terminwunsches. “Werkstattplatz” braucht dagegen eine eigene Identität und kann über viele Termine hinweg verwendet werden. Die Entscheidung folgt der Verantwortung im Modell, nicht einer mechanischen Wortsuche.

Für einen ersten Entwurf genügen drei Klassen. Die Tabelle notiert denselben Inhalt zunächst textlich, damit du die fachlichen Entscheidungen vor der grafischen Notation prüfen kannst:

In einem grafischen Klassendiagramm steht jede Klasse als Rechteck. Der Name steht oben, Attribute wie status stehen im mittleren und Operationen wie bestaetigen() im unteren Bereich. Linien verbinden die Klassen. Die Multiplizitäten stehen an den jeweiligen Enden der Linie.

Eine Multiplizität gibt an, wie viele Objekte auf einer Beziehungsseite beteiligt sein dürfen. 1 bedeutet genau eines, 0..1 keines oder eines und 0..* beliebig viele einschließlich null. Multiplizitäten beschreiben erlaubte Mengen. Sie erklären noch nicht alle Geschäftsregeln.

Genau dort liegt eine wichtige Grenze des Diagramms: Die Beziehung erlaubt mehrere Terminwünsche pro Werkstattplatz. Aus ihr allein folgt nicht, dass deren Zeiträume überschneidungsfrei sein müssen. Diese Regel gehört ergänzend in eine Anforderung, eine Bedingung oder einen Testfall.

Fehlersuche

Finde den Widerspruch zur Anforderung

Die Anforderung lautet: Jeder Terminwunsch gehört genau zu einem Kundenkonto. Eine Person kann mehrere Terminwünsche stellen. Welche Modellzeile widerspricht ihr?

1. 1 Am Ende Terminwunsch steht aus Sicht des Kundenkontos die Multiplizität 0..*.
2. 2 Am Ende Kundenkonto steht aus Sicht des Terminwunsches die Multiplizität 0..1.
3. 3 Die Beziehung trägt die Leserichtung stellt.
4. 4 Terminwunsch besitzt das Attribut status.

Fehler gefunden.

Diese Stelle ist nicht die Ursache.

0..1 würde einen Terminwunsch ohne Kundenkonto erlauben. Die Anforderung verlangt genau ein Konto, also muss dort 1 stehen. Die Multiplizität 0..* auf der anderen Seite erlaubt passend dazu mehrere Wünsche pro Konto.

Noch einmal suchen

Das Sequenzdiagramm zeigt einen konkreten Ablauf

Das Klassendiagramm sagt, welche Teile es gibt. Es zeigt nicht, welcher Teil beim Bestätigen zuerst handelt. Dafür wählt das Team einen einzigen Erfolgsfall: Die Disposition bestätigt einen offenen Wunsch, und ein Platz ist frei.

In einem grafischen Sequenzdiagramm stehen diese vier Beteiligten als Lebenslinien nebeneinander. Die Nachrichten werden in derselben Reihenfolge von oben nach unten eingezeichnet. Die Tabelle ist zugleich die Textfassung: Die Disposition sendet den Bestätigungsauftrag an den Terminservice. Dieser fragt die Platzsuche nach einem freien Werkstattplatz. Nach der Rückgabe speichert er die Reservierung und beauftragt die Benachrichtigung. Erst danach meldet er der Disposition die erfolgreiche Bestätigung. Der Entwurf zeigt nur diesen Erfolgsfall. Ein belegter Platz oder ein fehlgeschlagener Versand braucht eine eigene Ergänzung oder eine textliche Regel.

Im Sequenzdiagramm liest du die Zeit von oben nach unten. Die Beteiligten stehen nebeneinander. Ein durchgezogener Pfeil zeigt hier eine Nachricht oder einen Aufruf, ein gestrichelter Pfeil eine Rückgabe. Die Namen sollten ausdrücken, was fachlich oder technisch angefordert wird.

Das Diagramm macht eine offene Entwurfsfrage sichtbar: Soll ein fehlgeschlagener Benachrichtigungsversand die Reservierung zurücknehmen? Diese Entscheidung lässt sich nicht aus UML ableiten. Das Team muss festlegen, welches Verhalten fachlich gewünscht ist, und anschließend Modell sowie Tests daran ausrichten.

Sortieraufgabe

Ordne den erfolgreichen Bestätigungsablauf

Bringe die Nachrichten in die Reihenfolge des dargestellten Entwurfs.

Ziehe die Einträge an die richtige Position. Geht auch per Tastatur über den Griff.

Reihenfolge prüfen Neu versuchen

Die Reihenfolge stimmt.

Die Reihenfolge passt noch nicht.

Der Terminservice erhält zuerst den Auftrag. Danach sucht er einen Platz, speichert die Reservierung und stößt die Benachrichtigung an. Erst zum Schluss bestätigt er der Disposition den Erfolg. Eine andere Reihenfolge wäre möglich, müsste aber bewusst entworfen und begründet werden.

Prüfe jedes Modell zurück gegen die Anforderungen

Ein sauber gezeichnetes Diagramm kann fachlich falsch sein. Prüfe deshalb nicht nur Symbole, sondern die Verbindung zum Ausgangstext:

1. Abdeckung: Ist jede für die Fragestellung wichtige Anforderung im Modell erkennbar?
2. Widerspruchsfreiheit: Erlaubt das Modell etwas, das die Anforderung verbietet, oder umgekehrt?
3. Eindeutigkeit: Sind Namen, Leserichtung und Systemgrenze verständlich?
4. Angemessene Tiefe: Enthält das Modell die nötigen Details, ohne eine andere Sicht mit hineinzupressen?
5. Anschlussfähigkeit: Lassen sich aus dem Modell offene Entscheidungen, Schnittstellen oder Testfälle ableiten?

Das ist auch die Grenze zur Prozessmodellierung: Ein Aktivitätsdiagramm kann einen Ablauf innerhalb oder rund um eine Softwarefunktion zeigen. Für die umfassende Beschreibung betrieblicher Prozesse mit Rollen, Ereignissen und organisatorischen Regeln können andere Notationen oder ergänzende Texte passender sein. UML ist eine Auswahl an Sichten, kein Ersatz für Anforderungen, Quellcode, Datenbankentwurf und Tests.

Schnellcheck

Bewerte Modellierungsentscheidungen

Entscheide dich bei jeder Frage. Du bekommst die Erklärung direkt nach deiner Antwort.

/3

Ein Team will zeigen, ob der Benachrichtigungsdienst vor oder nach dem Speichern der Reservierung aufgerufen wird. Welche Sicht hilft am direktesten?

Das passt.

Noch nicht ganz.

Die Frage betrifft die zeitliche Reihenfolge von Nachrichten zwischen Softwareteilen. Genau darauf konzentriert sich ein Sequenzdiagramm. Andere Sichten können ergänzen, beantworten diese Frage aber nicht direkt.

Nächste Frage

Im Klassendiagramm ist ein Terminwunsch ohne Kundenkonto erlaubt, obwohl die Anforderung genau ein Konto verlangt. Welche Prüfung hat den Fehler sichtbar gemacht?

Das passt.

Noch nicht ganz.

Die Notation ist nur dann nützlich, wenn sie den fachlichen Sachverhalt korrekt ausdrückt. Der Rückvergleich zeigt hier einen Widerspruch zwischen 0..1 und genau einem verlangten Konto.

Nächste Frage

Warum sollte ein Klassendiagramm nicht vorsorglich jede Methode der späteren Anwendung enthalten?

Das passt.

Noch nicht ganz.

Klassen können Methoden darstellen. Für einen frühen fachlichen Entwurf reichen aber oft Verantwortlichkeiten und zentrale Beziehungen. Zusätzliche Details helfen nur, wenn sie die betrachtete Frage beantworten.

Ergebnis ansehen

Geschafft

von 3

Situationen richtig eingeordnet.

Quiz noch einmal machen

Entwirf die passenden Sichten für einen Geräteverleih

Transferaufgabe

Wähle und entwirf zwei zusammenpassende UML-Sichten

Ein Medienzentrum verleiht Kameras. Beschäftigte erfassen eine Reservierung für ein Kundenkonto. Das System prüft, ob die gewählte Kamera im Zeitraum frei ist. Bei Erfolg speichert es die Reservierung und sendet eine Bestätigung. Eine Kamera kann über die Zeit viele Reservierungen haben, Zeiträume dürfen sich aber nicht überschneiden. Wähle zwei UML-Sichten, skizziere sie und begründe, welche Frage jede Sicht beantwortet.

Deine Lösung

Musterlösung vergleichen

Musterlösung: Eine passende Kombination ist ein Klassendiagramm mit Kundenkonto, Reservierung und Kamera sowie ein Sequenzdiagramm für den erfolgreichen Reservierungsfall.

Im Klassendiagramm gehört jede Reservierung genau zu einem Kundenkonto und genau zu einer Kamera. Ein Kundenkonto kann 0..* Reservierungen besitzen. Auch eine Kamera kann über die Zeit 0..* Reservierungen haben. Die Reservierung trägt mindestens Beginn, Ende und Status. Die Multiplizität allein verhindert keine zeitliche Überschneidung. Deshalb notiere ich ergänzend die Regel: Für dieselbe Kamera dürfen sich die Zeiträume bestätigter Reservierungen nicht überschneiden.

Im Sequenzdiagramm sendet die beschäftigte Person reservieren(kontoId, kameraId, zeitraum) an den Reservierungsservice. Dieser fragt die Verfügbarkeitsprüfung an. Nach der positiven Rückgabe speichert er die Reservierung, beauftragt den Benachrichtigungsdienst und meldet den Erfolg zurück. Der Fall “Kamera belegt” ist bewusst nicht dargestellt. Er müsste als Alternative ergänzt werden: Es wird nichts gespeichert und die beschäftigte Person erhält eine Ablehnung.

Das Klassendiagramm beantwortet die Frage nach Struktur und erlaubten Zuordnungen. Das Sequenzdiagramm beantwortet die Frage nach der Reihenfolge im Erfolgsfall. Zusammen machen beide Sichten außerdem einen Testfall sichtbar: Eine zweite Reservierung derselben Kamera mit überlappendem Zeitraum muss abgewiesen werden.

Das steckt auch in meiner Lösung:

jede gewählte Diagrammart passt zu einer ausdrücklich genannten Entwurfsfrage Akteure, Klassen oder Softwareteile sind aus dem Szenario begründet abgeleitet Beziehungen, Multiplizitäten oder Nachrichten sind eindeutig lesbar die Regel zu überschneidungsfreien Zeiträumen wird als Regel oder offene Prüfung berücksichtigt Grenzen und bewusst ausgelassene Details werden kurz benannt

Was du aus der Lektion mitnehmen kannst

UML beginnt nicht mit einem Symbol, sondern mit einer Frage. Eine Anwendungsfallsicht klärt Rollen und Ziele. Ein Klassendiagramm ordnet Struktur und Verantwortlichkeiten. Ein Aktivitätsdiagramm führt durch Aktionen und Entscheidungen. Ein Sequenzdiagramm macht den Nachrichtenaustausch in einem konkreten Fall sichtbar.

Ein Modell bleibt absichtlich unvollständig. Seine Qualität zeigt sich daran, ob es den gewählten Ausschnitt verständlich, angemessen genau und ohne Widerspruch zu den Anforderungen beschreibt. Wo das Modell eine Entscheidung nicht trägt, brauchst du ergänzende Anforderungen, Regeln oder Tests.

Belegmatrix