KE1: Software Engineering im Überblick

KE1: Software Engineering im Überblick 2.2 Eigenschaften von Software (S. 6) Softwareeigenschaften: nicht sinnlich wahrnehmbar, Text, digital Eigenschaften großer Software: komplex, besteht aus umfangreichen Artefakten, hat eine lange Lebensdauer, verfestigt Sichtweisen 3.1 Kriterien für Softwarequalität (S. 10) Kriterien: Produktqualität (Korrektheit, Verständlichkeit, Änderbarkeit, Wiederverwendbarkeit), Gebrauchsqualität (Zuverlässigkeit, Effizienz, Fehlerrobustheit) nach ISO9126-1: Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit 3.2 Aktivitäten (S. 13) Aktivitätenarten: Anforderungsermittlung, Entwurf, Implementation, Test, Systemeinführung Anforderungsermittlung: Anforderungen stammen aus dem Anwendungsbereich, Ausgangsbasis sind informelle Gespräche mit den Anwendern; in der Anforderungsspezifikation (»Pflichtenheft«) wird der Leistungsumfang der Software möglichst exakt festgeschrieben, beihaltet was, aber nicht wie, Endabnahme erfolgt nach dieser Spezifikation; Unterscheidung in funktionale Anforderungen (Eigenschaften, Schnittstellen) und nichtfunktionale Anforderungen (Qualität, Performanz); Validieren (wird das richtige Programm geschrieben?), Verifizieren (wird das Programm richtig geschrieben?) Entwurf: damit wird die innere Struktur der Software festgelegt; jedes Modul sollte ein logisch zusammenhängendes Teilproblem behandeln (starke Köhäsion); die Abhängigkeit zu anderen Modulen sollte gering sein (schwache Kopplung); Geheimnisprinzip (Realisierung braucht anderen Modulen nicht bekannt zu sein); Unterstützung durch Klassenbibliotheken, Rahmenwerke und Entwurfsmuster (wie MVC) Implementation: Ausprogrammierung der Modulinterna auf der Grundlage der Entwurfsspezifikation; bei Verwendung von Rahmenwerken besteht zwischen Entwurf und Implementation keine scharfe Trennung Test: Einzeltest der Module im Modultest; danach Integrationstest (Hinzufügen einzelner Module), danach Systemtest Systemeinführung: Übertragung aus der Entwicklungs- in die Einsatzumgebung 4 Vorgehensmodelle (S. 20) Modelle: iterativ, inkrementell und evolutionär; Wasserfall, Prototyping, RUP, XP 1

KE2: Strukturelle Modellierung 9.1 Objekte (S. 72) allgemein: Abstraktion eines Objektes beschreibt die Herausarbeitung der Gemeinsamkeiten, die dieses Objekt von anderen unterscheidet; Prinzip des»geringsten Erstaunens«; Name des Objektes wird in UML im Rechteck dargestellt und unterstrichen, Attribute darunter, Operationen gar nicht; Verbindungen: Objekte können Dienstleister und -nutzer sein (ein Dienstnutzer aktiviert eine Operation des Dienstleisters); Namen von Verbindungen können optional an der Verbindungskante eingetragen werden (unterstrichen), uni- und bidirektionale Kanten werden als Pfeile mit offener Spitze dargestellt; ein Objekt kann bezüglich seiner Verbindungen unterschiedliche Rollen spielen, eine Rolle ist eine Teilmenge der vom Objekt angebotenen Operationen, sie definiert das Verhalten des Objekts gegenüber den verbundenen Objekten, Kennzeichnung: Substantive, die an den jeweiligen Verbindungsenden notiert kleingeschrieben und nicht unterstrichen werden 10 Klassen und Beziehungen (S. 80) Klassen: können als abstrakter Objekttyp verstanden werden; Ziel der Klassenmodellierung ist das Herausarbeiten von Gemeinsamkeiten von Objekten; abgeleitete Attribute (die aus anderen Attributen der gleichen Klasse berechnet werden können) werden mit einem vorgestellten Schrägstrich geschrieben Schreibweisen von Klassen in UML: wird im Rechteck, aber nicht unterstrichen dargestellt; Schreibweise von Objekten: [Objektname] [: Klassenname]; Attribute werden mit erstem Kleinbuchstaben geschrieben, Sichtbarkeit und Änderbarkeit kann angegeben werden: public menge : Integer = 0 changeable; Attribute werden im Kästchen unter dem Objektnamen aufgelistet, Operationen nochmal darunter (jeweils durch einen Querstrich getrennt) Operationen: Übergabeart von Parametern kann angegeben werden: in Eingabeparameter als Werteparameter, die von der Operation nicht modifiziert werden können; inout Eingabeparameter als Referenzparameter, die von der Operation modifiziert werden können; out reine Rückgabeparameter als Referenzparameter; Selektoren werden mit der Eigenschaft isquery gekennzeichnet; Bsp: public monatsumsatz(in aktmonat : Monat) : Geld isquery 10.3 Assoziationen (S. 86) Assoziationen: sind Verbindungen von Instanzen von Klassen; werden in UML durch durchgezogene Linien zwschen den Kästchen dargstestellt, der Name der Assoziation steht in der Mitte der Linie, an den Ende die Multiplizität: 1..1 (genau eine verbundene Instanz, Abkürzung: 1), 0..* (beliebig viele 2

verbundene Instanzen, Abkürzung: *), 0..1 (keine oder eine verbundene Instanz) und 1..* (unbegrenzt viele verbundene Instanzen, aber mindestens eine); kennt eine Instanz der Klasse A Instanzen der Klasse B, aber nicht umgekehrt, so wird die Assoziation zwischen den Klassen als (einseitig) navigierbar (unidirektional) gekennzeichnet und im Klassendiagramm als Pfeil mit offener Spitze in der (Kenntnis-) Richtung von Klasse A zu Klasse B gezeichnet; ungerichtete könen auch als bidirektional aufgefaßt werden; bei verschiedenen Assoziationsbeziehungen zwischen zwei Klassen können mehrere Assoziationen gemalt werden, sie werden an den Enden mit Rollenbezeichnungen versehen; Aggregation: sind spezielle Assoziationen, die eine Hierarchie auf den verbundenen Instanzen definieren; anschaulich gesprochen besteht ein Teil-Ganzes-Verhältnis zwischen den verbundenen Instanzen, Dabei hat die Ganzes-Instanz eine Verantwortung für die Teil-Instanzen; in UML wird eine Aggregation durch eine nicht ausgefüllte Raute am Ganzes-Ende der Assoziationslinie gekennzeichnet. Komposition: ist eine spezielle Assoziation, bei der noch schärfere semantische Bedingungen als bei der Aggregation gelten: Teilobjekte einer Komposition dürfen nur von Operationen der Ganzes-Klasse entfernt oder ausgetauscht werden, sie dürfen nicht Teil anderer Kompositionen sein und sie werden beim Zerstören des Ganzes-Objekts automatisch mitzerstört; Darstellung durch gefüllte Raute am Ganzes-Ende oder es kann auch die Teil-Klasse innerhalb der Ganzesklasse gezeichnet werden, die Multiplizität des Teils wird dann rechts oben in die Darstellung der Teil-Klasse geschrieben Assoziationsklassen: stattet Assoziationen mit Attributen und Operationen aus; jede Assoziationsklasse repräsentiert genau eine Assoziation; wird in UML mit einer gestrichelten Linie mit der jeweiligen Assoziationslinie verbunden; Standardoperationen: für Klassen: gibatt() : T und setzeatt(in wert:t) (Getter und Setter), für Assoziationen: verbindeass(in EinB : B) verbindet die ausführende A-Instanz mit der übergebenen B-Instanz EinB; gibass(): B gibt die mit der ausführenden A-Instanz verbundene B-Instanz zurück; loeseass(in EinB : B) hebt die Verbindung zwischen der ausführenden A-Instanz und der übergebenen B-Instanz EinB wieder auf; erzeuge(): K gibt eine neue Instanz der Klasse K zurück, zerstoere() zerstört die ausführende Instanz Generalisierung: betrachtet klassenübergreifende Gemeinsamkeiten; vermeidet Redundanz; die allgemeinere Klasse heißt Oberklasse und die speziellere Klasse Unterklasse; die Unterklasse erbt alle Attribute und Operationen sowie alle Assoziationen der Oberklasse, im UML werden Generalisierungsbeziehungen mit zu der Oberklasse weisenden Pfeilen mit nicht ausgefülltem Dreieck und durchgezogener Linie dargestellt; 11 Klassen und Beziehungen: fortgeschrittene Konzepte (S. 99) Darstellung von Sichtbarkeiten in UML: public wird durch + und private durch - kenntlich gemacht; protected mittels # (ist nur in einer Klasse und deren Unterklassen sichtbar) 3

Stereotype: können Klassen oder Assoziationen besonders aussagekräftig an die jeweilige Situation anpassen; jeder Stereotyp wird durch einen Bezeichner identifiziert, Zusätzlich kann auch ein vereinbart werden; in UML-Diagrammen können stereotypisierte Klassen auf drei verschiedene Arten dargestellt werden: der Bezeichner des Stereotyps wird textuell, eingefaßt in guillemets (), über dem Namen der Klasse angegeben, oder Tdas grafische Symbol des Stereotyps (Kreis mit Pfeilspitze) erscheint oben rechts im Klassenrahmen oder es ist nur das grafische Symbol des Stereotyps mit darunterstehendem Klassennamen aufgeführt; Aufzählungstypen werden mit dem Stereotyp «enumeration» dargestellt Abhängigkeiten: gerichtete Beziehung, welche die hinsichtlich eines bestimmten Sachverhalts abhängigen Elemente mit den unabhängigen Elementen verknüpft; Darstellung in UML mittels gestrichelter Linie und offener Spitze hinzu den unabhängigen Elementen Klassenattribute und Klassenoperationen: gelten für alle Instanzen der Klasse (sozusagen global, in Java static); werden in UML durch Unterstreichung des Bezeichners dargstellt; Zusicherungen: geben zu geltende Bedingungen an; wird in das Klassendiagramm integriert, indem sie eingeschlossen in geschweifte Klammern an die Elemente im Klassenmodell geschrieben wird, für welche sie gilt, das kann umgangssprachlich oder in Pseudocode sein; Verwendung zum Beispiel bei mehrwehrtigen Assoziationen, daß eine Menge {geordnet} ist (jedes Objekt kommt nur einmal vor; darf ein Objekt mehrfach vorkommen, so wird dies durch die Zusicherung {Kollektion} angezeigt; Pakete: Gruppierung von Elementen, die selbst wieder Pakete sein können; Modellierungselemente, die innerhalb des Pakets und innerhalb aller (hierarchisch) im Paket enthaltenen Pakete sichtbar sein sollen, werden als paketweit (package) deklariert; Default-Sichtbarkeit (keine Angabe) gilt innerhalb des eigenen Paketes; Pakete können importiert werden oder die Namen werden voll qualifiziert angesprochen; in UML werden als Pakete als Rechtecke dargestellt, die mit einem kleinen Schildchen an der linken oberen Ecke versehen sind; ~ (paketweit sichtbar); Import- bzw. Access-Abhängigkeiten werden als gestrichelte mit «import» bzw. «access» gekennzeichnete Pfeile mit offener Spitze dargestellt, die Pfeilspitze zeigt dabei jeweils auf das benutzte Paket 11.4 Abstrakte Klassen und Interfaces (S. 103) Typen von Klassen: reguläre Klassen (alle Operationen sind implementiert), abstrakte Klassen mit mindestens einer abstrakten Definition, Interfaces (ohne Attribute und implementierte Klassen, ohne Kenntnis von Assoziationen, dürfen nur Ziel einseitig navigierbarer Assoziationen sein); Zweck: abstrakte Klassen und Interfaces dienen primär der Strukturierung, sie extrahieren Gemeinsamkeiten von Klassen und definieren Vorgaben für deren Schnittstellen, wobei in abstrakten Klassen nicht nur die Schnittstelle, sondern auch Teile der Implementierung zur Redundanzvermeidung vordefiniert 4

werden können; ein Interface kann die öffentlichen Schnittstellen von Klassen einschränken; Schreibweise in UML: abstrakte Klassen und Operationen werden kursiv geschrieben, oder es wird das Schlüsselwort abstract vorangestellt; Interfaces werden mit dem Stereotyp «interface» oder als ein kleiner, mit dem Namen des Interface unterschriebener, Kreis dargestellt; eine «realizes»-abhängigkeit wird als vom Klassensymbol der realisierenden Klasse zum Klassensymbol des Interfaces zeigender, an die Ähnlichkeit zur Generalisierungsbeziehung erinnernder Pfeil mit Dreieckspitze und gestrichelter Linie gezeichnet (Abkürzung: Lollipopmit Interfacename); benötigt eine Klasse ein Interface als Attribut- oder Parametertyp, so wird dies im Klassenmodell mit einer «use»-abhängigkeit festgehalten; 11.8 Textuelle Spezifikationen (S. 110) Anwendung: wird zu präziseren Definition verwendet; enthält z. B. die grundsätzlichen Verantwortlichkeiten der Klasse und ihre Eigenschaften, die Semantik der Operationen wird dabei durch Vor- und Nachbedingungen sowie durch eine Klasseninvariante präzisiert Vorbedingungen: definieren, welche Voraussetzungen vor dem Aufruf einer Operation gelten müssen, damit diese die definierte Leistung erbringen kann, sie beziehen sich meist auf die Zustände der aktuellen in- und inout-parameter und den Zustand des dienstleistenden Objekts Nachbedingungen: definieren das durch das dienstleistende Objekt abgelieferte Ergebnis der Operation unter der Annahme, dass die Vorbedingung beim Aufruf erfüllt war, sie beziehen sich meist auf den Zustand des dienstleistenden Objekts und die inout- und out-pa-rameter sowie auf die Zustände verbundener Objekte nach der Operationsausführung Klasseninvariante: erlaubt es, gemeinsame Teile aus allen Vor- und Nachbedingungen der Operationen der Klasse herauszuziehen und nur einmal zu notieren, gilt vor und nach jeder Ausführung jeder öffentlichen Operation der Klasse Aufbau: im Abschnitt responsibilities wird der Verantwortungsbereich der Klasse beschrieben; die Klasseninvariante ist unter inv angegeben; das Schlüsselwort features leitet die Unterabschnitte für die Attribut- und Operationsspezifikationen ein; Vor- und Nachbedingungen mittels pre und post, Kommentare mit comment KE3: Funktions-und Verhaltensmodellierung 13 Anwendungsfalldiagramme (S. 120) Akteure: das sind Benutzer, die eine mit bestimmten Aufgaben verknüpfte Rolle einnehmen; werden in UML als Strichmännchen dargstellt; können in einer Generalisierungsbeziehung zueinander stehen 5

Anwendungsfälle: formuliert eine in sich abgeschlossene Teilfunktionalität des Anwendungssystems, an denen Akteure beteiligt sind; werden grafisch als Ellipsen dargestellt, wobei der Name in der Ellipse eingetragen ist; können in einem bezeichneten Rechteck gebündelt werden; Assoziation zwischen Akteuren und Anwendungsfällen werden wie im Klassendiagramm dargestellt; werden textuell aus Sicht der Akteure beschrieben; mögliche Abweichungen vom normalen Ablauf werden in eigenen Abschnitten aufgeführt: alternative/exceptional flows, bei letzterem wird eine gesonderte Nachbedingung angegeben; ein Szenario ist ein konkreter Ablauf eines Anwendungsfalls; können in einer Generalisierungsbeziehung stehen Beziehungen zwischen Anwendungsfällen: Strukturierung kann wegen vielen oder komplexen Anwendungsfällen notwendig werden, dafür gibt es «include» und «extend»; include wird verwendet, wenn verschiedene Anwendungsfälle diesselbe Teilfunktionalität beihalten, in UML wird das durch einen gestrichelten Pfeil mit offener Spitze Richtung benutzten Anwendungsfall dargestellt, der mit «include» beschriftet ist; textuell durch (include Anwendungsfallname ) extend bedeutet, daß ein Anwendungsfall unter bestimmten Bedingungen durch eine beschriebene Funktionalität erweitert werden kann (optional); in UML wie bei include dargestellt, nur daß der Pfeil zum Basisanwendungsfall hin gerichtet ist; Erweiterungspunkte eines Basisanwendungsfalls werden durch horizontale Unterteilung des Anwendungsfallsymbols dargestellt 14 Interaktionsdiagramme (S. 134) allgemeines: beschreiben den Ablauf von Funktionen und präzisieren so die Semantik; ein konkreter Ablauf wird mit den Aktionen der Akteure und dem Austausch von Nachrichten durch die Objekte erfaßt; Sequenzdiagramme: jedes Objekt wird am oberen Ende einer gestrichelten vertikalen Linie dargestellt (Lebenslinie); der Aufruf einer Operation wird als Pfeil mit geschlossener, ausgefüllter Spitze von der Lebenslinie des dienstnutzenden zu der des dienstleistenden Objekts wiedergegeben, dabei wird von oben nach unten der zeitliche Ablauf wiedergegeben; jeder Pfeil wird mit dem Namen der aufgerufenen Operation beschriftet; es können Bedingungen und Iterationen dargestellt werden; Erzeugung durch Pfeil auf Objekt, Zerstörung durch am Ende der Lebenslinie; Synchrone Nachrichten und Aktivierungen: synchrone Nachrichten werden durch geschlossene gefüllte Pfeile dargestellt; wenn ein Objekt auf die Antwort einer synchronen Nachricht wartet, wird auf der Lebenslinie ein schmales Rechteck (Aktivierungsbalken) dargestellt; Rückkehr ist implizit, kann aber mit gestricheltem Pfeil zurück dargestellt werden; Asynchrone Nachrichten und aktive Objekte: bei asynchroner Verarbeitung werden alle aktiven Objekte durch fette Umrandung dargestellt und asynchrone Nachrichten durch Pfeile mit offener Spitze Kollaborationsdiagramme: stellen Objektdiagramme mit ablauforientiertem Verhalten dar; Abfolge der Nachrichten wird durch Numerierung verdeutlicht, entweder Ordinalzahlen oder hierarchische Dezimalnotation; Objekte werden mit {new}, 6

{destroy} oder {transient} gekennzeichnet; Nachteil ist, daß die Abfolge der Nachrichten nicht mehr so leicht wie im Sequenzdiagramm zu erkennen ist; 15 Zustandsdiagramme (S. 148) Zustände: es wird dargestellt,wie die Instanzen einer Klasse in Abhängigkeit von ihrem Zustand und weiteren Bedingungen auf bestimmte Ereignisse wie z. B. den Aufruf einer Operation reagieren; der Zustand eines Objekts zu einem bestimmten Zeitpunkt ist durch die vorliegende Kombination seiner konkreten Attributwerte und Verbindungen zu anderen Objekten determiniert; bei der Modellierung von Zuständen werden Eigenschaften, die das Verhalten nicht beeinflussen, ignoriert; Zustände werden in der UML als abgerundete Rechtecke dargestellt,in denen der Bezeichner des Zustands angegeben werden kann; Ereignisse: bezeichnet das Eintreten eines bestimmten Sachverhalts zu einem bestimmten Zeitpunkt, das im Kontext der Modellierung eine vernachlässigbare Zeitdauer besitzt; Aufruf-, Änderungs-,Zeitereignisse; die Reaktion auf den Eintritt eines Ereignisses ist ein Zustandsübergang, dieser wird mit einem Pfeil mit offener Spitze vom Ausgangs- zum Folgezustand dargestellt, der mit dem Namen des Ereignisses beschriftet ist; wenn ein Ereignis mehrere Folgen haben kann, wird die Bedingung eines Zustandsübergangs im Zustandsdiagramm in eckigen Klammern hinter dem Ereignisnamen angegeben; UML-Syntax: Ereignis [Wächterbedingung] / Aktionsfolge ^ Sendeaktion Initial-/Terminal-, Zusammengesetzte Zustände: beides optional; Initialzustand wird durch erzeugt, von dem aus ein Zustandsübergang stattfindet und das Objekt erzeugt wird; Terminalzustände werden durch schwarz gefüllten Doppelkreis dargstellt; zusammengesetzte Zustände werden als abgerundetes rechteck gezeichnet, wobei jeder zusammengesetzte Zustand ein Zustandsdiagramm mit Initialzustand umfaßt; KE4: Anforderungsermittlung Ziele und Vorgehensweise: Basisanforderungen in einem Lastenheft; (nicht-)funktionale Anforderungen; Ergebnis der funktionalen Anforderungen ist die Anforderungsspezifikation; Teilaufgaben: Extraktion (Studium der Domäne, Befragungen), Verhandlung (Art und Umfang, Qualität, Zeitplan), Spezifikation (Erstellen eines Referenzdokumentes), Validierung (Überprüfung der fachlichen Vollständigkeit und Korrektheit); zuerst verschafft sich ein Analytiker den Überblick, dann werden mit Anwendern Szenariern durchgegangen, daraus entstehen Akteure und Anwendungsfälle; aus identifizierten Objekte und Klassen entsteht das Domänenklassenmodell ohne Operationen; Einstieg: Studium der Domäne und Gewinn von Informationen, dann Erstellen eines Glossars unter Vermeidung von DV-technischen Begriffen und Beachtung von Synonymen und Homonymen; 7

18 Anwendungsfallmodellierung (S. 169) Vorgehensweise: Ausgangsbasis Lastenheft; dann Ermittlung und Beschreibung von Szenarien; dann Benutzer mit Akteuren modellieren und die für die einzelnen Akteure wichtigen Szenarien in Anwendungsfällen bündeln; gegenseitige Abhängigkeiten untersuchen und im Anwendungsfalldiagramm verknüpfen; evtl. Zusammenfassung in Paketen; Szenarien: jede Teilfunktion wird in Szenarien festgehalten; konkrete Beispielsituationen werden durchgespielt; Akteure: für jeden menschlichen Akteur muß eine Person existieren, welche die Rolle des Akteurs spielen kann; als Ergebnis erhält man die Akteure selbst sowie einen Überblick über die von ihnen benutzten Funktionen des Anwendungssystems; weisen die Aufgaben und Verantwortlichkeiten verschiedener Akteure Gemeinsamkeiten auf, können diese durch einen allgemeineren Akteur und entsprechende Generalisierungsbeziehungen ausgedrückt werden Anwendungsfälle: Szenarien werden zuerst zu einigen wenigen großen Anwendungsfällen zusammengefaßt; dann so trennen, daß jeder Anwendungsfall eine klar abgegrenzte Aufgabe behandelt; Anwendungsfälle sollten Akteure haben und die Systembenutzung (nicht das System) beschreiben; jeder Anwendungsfall wird auch niedergeschrieben, sollte aber nicht eine Seite übersteigen Beziehungen zwischen Anwendungsfällen: Teilszenarien können mittels include oder extend verwendet werden; die Beziehungen sollen aber keine Abläufe, sondern modulare Aufteilung modellieren; Pakete: Pakete von Anwendungsfällen werden nach ihrer fachlichen Zusammengehörigkeit gebildet; Anwendungsfälle aus verschiedenen Paketen sollten nur minimale Abhängigkeiten besitzen, im Idealfall impliziert die Aufteilung der Anwendungsfälle auf Pakete auch eine entsprechende Aufteilung der Akteure 19 Domänen-Klassenmodellierung (S. 175) Vorgehensweise: zuerst werden potentiellen Objekte, Klassen, Attribute und Assoziationen notiert und in ein Glossar eingefügt; die Domänen-Klassenmodellierung beginnt mit der Identifizierung von Objekten und Klassen und bestimmt dann Attribute und Assoziationen; dann werden die Klassen grob textuell spezifiziert, abschließend werden bei umfangreichen Klassendiagrammen fachlich zusammengehörende Klassen zu Paketen gebündelt; jedes Element des Domänen-Klassenmodells sollte ein Pendant besitzen,das ein relevanter Gegenstand oder Sachverhalt der Problemwelt ist. Klassen und Assoziationen: auf jede Klasse des Domänen-Klassenmodells muss in mindestens einem Anwendungsfall oder Szenario Bezug genommen werden; Attribute und Assoziationen einer Klasse ergeben sich aus der Problemwelt und aus den Informationen, die von den Anwendungsfällen und Szenarien benötigt werden, sie werden nur grob und umgangssprachlich beschrieben; es sollten nur öffentliche Attribute angegeben werden; 8

Generalisierungsbeziehungen: besitzen zwei Klassen mehrere gleiche Attribute oder gehen mit den gleichen Klassen Assoziationsbeziehungen ein, so kann eine Generalisierung angebracht sein; Attribute und Assoziationen werden in der Generalisierungshierarchie stets so hoch wie möglich angesiedelt; Modellbereinigung: Klassen mit nur einem Attribut können evtl. anderen Klassen zugeteilt werden; abgeleitete Attribute und Assoziationen müssen als solche markeiert werden; zu jeder Domänenklasse sollte mehr als ein Objekt existieren textuelle Spezifikationen: Eigenschaften, die in Klassendiagrammen nicht genau genug ausgedrückt werden können, werden in knapper Form textuell spezifiziert; sie sollte möglichst spät angefertigt werden Pakete: werden wiederum nach fachlicher Zusammengehörigkeit gebildet; als Kernklassen von Paketen kommen die obersten Klassen von Aggregationen, Kompositionen und Generalisierungshierarchien sowie alle anderen Klassen in Frage, die nicht Teil einer solchen Beziehung sind; Nicht-Kernklassen ordnet man den Paketen zu, von deren Kernklassen sie Unter- bzw. Teilklassen darstellen; 20 Benutzungsoberfläche (S. 181) Anforderungen: die Beschreibung der Benutzungsoberfläche in der Anforderungsermittlung muß die wesentlichen Fenster und ihre Verbindungen sowie die Navigation zwischen den Fenstern konzipieren; 22 Validierung und Verifikation (S. 186) Validierung: Wird das richtige Produkt entwickelt? wird vom Auftraggeber beantwortet; Schritte dafür sind sog. walg-throughs und Reviews Verifikation: Wird das Produkt richtig entwickelt wird von Analytikern, Entwicklern und Testern beantwortet; im Rahmen der Anforderungsermittlung ist nur ein grober Abgleich mit dem validierten Anwendungsfallmodell sinnvoll; KE5: Analyse Ziele und Vorgehensweise: Anwendungsfälle werden in Klassen überführt, siese Klassen werden zum Teil als Schnittstellen- und Kontrollklassen neu eingeführt, zum Teil wird das Domänen-Klassenmodell beibehalten, die neuen Klassen werden mit dem Domänen-Klassenmodell zu einem Analyse-Klassenmodell zusammengefaßt; das Analyse-Klassenmodell wird mit Operationen gefüllt; abschließend Verifikation; die daraus entstehende Analysespezifikation bildet die Vorgabe für die Realisierung des Anwendungssystems; die Analysespezifikation umfaßt das Analyse-Klassenmodell, Interaktions-und Zustandsdiagramme und Dokumente, in denen die Durchführung und die Ergebnisse der Verifikationsaktivitäten festgehalten sind 9

25 Klassenmodellierung: Heuristiken (S. 228) 1-1 Assoziation oder eine Klasse?: zwei verschiedene Klassen sind die bessere Wahl, wenn die 1-1 As- soziation zwischen diesen beiden Klassen in einer Richtungen optional spezifiziert ist; zwei verschiedene Klassen sind die bessere Wahl, wenn eine Instanz eine Verbindung zu Instanzen weiterer Klassen eingehen kann. Attribute oder Generalisierung?: wenn sich die Objekte bei Attributen und Verhalten unterscheiden, wird die Generalisierung benutzt; ansonsten werden Attribute benutzt; im Zweifelsfalle werden die Objekte zunächst anhand der Attributwerte unterschieden, sollte sich im Laufe der Modellierung herausstellen, daß sich in Abhängigkeit von den Attributwerten unterschiedliche Verhaltensweisen oder Verbindungen ergeben,k ann man immer noch zur Unterklassenbildung greifen 26 Klassenmodellierung (S. 234) Einleitung: Analyseklassen sind sehr abstrakt (nur funktionale Anforderungen, keine Angaben auf programmiersprachlicher Ebene, keine Navigierbarkeit bei Assoziationen); Symbole für Typen der Analyseklassen sind (Schnittstellenklasse), < (Kontrollklasse) und (Entitätsklasse) (sieht scheiße aus, ich weiß); Entitätsklassen: repräsentieren langlebige Informationen im Anwendungssystem; zur Übertragung von Domänenklassen in Entitätsklassen werden zunächst die Domänenklassen mit dem Stereotyp «Entitätsklasse» oder dem Symbol gekennzeichnet, dann werden Attribute und Assoziationen der Entitätsklassen noch verfeinert sowie Operationen aufgenommen; Schnittstellenklassen: Schnittstellenklassen bündeln die Interaktionen zwischen den Akteuren und dem Anwendungssystem; für jeden Akteur wird eine Akteur-Schnittstellenklasse (AS) definiert, welche dem Akteur erlaubt, die ihm zur Verfügung stehenden Anwendungsfälle zu aktivieren; Akteur-Schnittstellenklassen werden durch den Namen des Akteurs mit angehängtem AS bezeichnet; es wird sich nur auf menschliche Akteure konzentriert; für jeden Anwendungsfall und jeden am Anwendungsfall beteiligten Akteur wird eine Anwendungsfall-Akteur-Schnittstellenklasse (AAS-Klasse) modelliert, über welche die Interaktion des Akteurs mit dem Anwendungsfall abgewickelt wird; eine AAS-Klasse wird durch den Namen des Anwendungsfalls gefolgt von dem des Akteurs und angehängtem AAS bezeichnet Kontrollklassen: die fachliche Logik wird in einer Kontrollklasse pro Anwendungsfall gekapselt, sie kontrolliert die Entitätsklassen gemäß der fachlichen Logik und spielen eine Vermittlerrolle zwischen Schnittstellen- und Entitätsklassen; sie werden durch den Namen des Anwendungsfalls mit angehängtem K bezeichnet Operationen: die in der Anforderungsspezifikation festgehaltenen Anwendungsfälle bilden zusammen mit den Interaktionen aus den Sequenzdiagrammen die Basis für die Operationen; jede externe Interaktion entspricht einer Operation; ist Voraussetzung für Verifikation; danach wird nach den Heuristiken bereinigt Pakete: es wird sich zuerst nach Akteuren und Anwendungsfällen gerichtet; die resultierenden Pakete werden z. B. mit dem Namen des Akteurs oder einem 10

Oberbegriff für die zusammengefassten Anwendungsfälle mit angehängtem P bezeichnet und nach den drei Kategorien von Klassen jeweils in Unterpakete SchnittstelleP, KontrolleP und EntitaetenP weiter zerlegt; 27 Verhaltensmodellierung (S. 242) Ablauf: erst werden die den Anwendungsfall realisierenden Klassen kenntlich gemacht, dann wird ein Kollaborationsdiagramm gezeichnet; die zugehörigen Entitätsklassen werden aus der textuellen Beschreibung ermittelt, an den Verbindungen werden die Operationsaufrufe notiert; Szenario beginnt mit einem Operationsaufruf vom Akteur an die AAS-Klasse; 28 Verifikation Intra-Modell-Verifikation: die Modelle werden hinsichtlich ihrer Vollständigkeit, Eindeutigkeit und Konsistenz geprüft; im Anwendungsfallmodell werden die textuellen Beschreibungen auf include und extend geprüft; im Klassenmodell wird geprüft, ob alle Assoziationsenden mit Multiplizitäten versehen sind, keine ableitbaren Attribute existieren und in Generalisierungshierarchien keine Redundanzen enthalten sind und Interfaces bzw. abstrakte Klassen vollständig implementiert sind; bei Interaktionsdiagrammen wird überprüft, ob jeder Pfeil mit einem Operationsnamen beschriftet ist und jedes Objekt explizit erzeugt wird Inter-Modell-Verifikation: Modelle werden gegeneinander abgeglichen, zuerst das Analyse-Klassenmodell mit dem Anwendungsfallmodell, dann gegen Zustandsdiagramme und Interaktionsdiagramme; die Konsistenz ist gewährleistet wenn für jede Aktion im Szenario eine Operation im Klassenmodell vorhanden ist und umgekehrt, sowie wenn die aufeinander folgenden Nach- und Vorbedingungen konsistent sind KE5: Architekturentwurf Ziele und Vorgehensweise: Verfeinerung einer groben Grundstruktur; ein guter Architekturentwurf verwendet objektorientierte Konzepte, ist unabhängig vom Anwendungsbereich und unterstützt Wiederverwendung; der Architekturentwurf mündet in die Architekturspezifikation Schichtenarchitekturen: Aufgabenarten werden auf unterschiedliche Schichten mit getrennten Verantwortlichkeiten aufgeteilt; Änderungen sollen sich nur schichtenlokal auswirken; 3-Schichten-Architektur: externe Schnittstelle, Anwendungskern, Datenhaltung KE6: Grundlagen des Entwurfs Ziele und Vorgehensweise: Ausgangspunkt ist die Analyse- und Architekturspezifikation; im Entwurf wird die Zerlegung der komplexen und 11

kleinere beherrschbare Teile bewerkstelligt; der Grobentwurf abstrahiert von der Implementationssprache; als Ergebnis entsteht eine Entwurfsspezifikation, die als Hauptbestandteil ein feingranulares Klassenmodell hat, dieses wird um Interaktions- und Zustandsdiagramme ergänzt; Grundkonzepte: Geheimnisprinzip mit Gettern und Settern; Veringerung der Kopplung und Stärkung der Kohäsion; Minimierung des Überschreibens von Operationen der Oberklasse; Interfaces: definieren eine Menge von öffentlich sichtbaren Operationen; lassen Instanzen verschiedener Klassen mit einer gemeinsamen Eigenschaft einheitlich verwenden, dient zur Wahrung des Geheimnisprinzips; 35.4 Entwurf mit Verträgen (S. 290) Grundlagen: regelt die Zusammenarbeit von Objekten; Verhältnis zwischen Dienstnutzer und Dienstleister weist eine Analogie zur Vertragspartnern auf; jede Partei hat Rechte und Pflichten; Techniken: Spezifikation der Operationen der Schnittstelle mit Vor- und Nachbedingungen und Klasseninvarianten; klar geregelte Verantwortlichkeiten von Dienstnutzer und Dienstleister; systematische Behandlung von Ausnahmefällen; es gilt: wenn der Dienstnutzer die Vorbedingung erfüllt, dann garantiert der Dienstleister die Nachbedingung, sowie Dienstnutzer und Dienstleister erfüllen die Invariante ihrer Klasse vor und nach jeder Ausführung einer öffentlichen Operation Konsequenzen: Vertragsverletzung führt zu einem Programmfehler; die Verletzung einer Vorbedingung weist auf ein Fehlverhalten des Dienstnutzers hin, die Verletzung der Nachbedingung weist auf ein Fehlverhalten des Dienstleisters hin; bei erfüllter Vertragsbedingung müssen alle möglichen Fälle behandelt werden; unerfüllte Vertragsbedingungen können zu Wiederaufruf oder organisiertem Abbruch führen Entwurfsmuster (S. 302) Einführung: Entwurfsmuster (eine Beschreibung einer Familie von Lösungen) machen die lokale, sich jeweils auf wenige Klassen beziehende Entwurfserfahrung der Wiederverwendung zugänglich; Rahmenwerke erlauben die Wiederverwendung ganzer Entwürfe; Entwurfsmuster sind abstrakt, sie lassen sich in erzeugende, strukturelle und Verhaltensmuster unterteilen; Rahmenwerke enthalten und instanziiren Entwurfsmuster; Bsp. für Rahmenwerke: MVC; erzeugende Muster: abstrakte Fabrik (bietet eine Schnittstelle zum Erzeugen verwandter Objekte), Einzelstück (singleton, stellt sicher, daß von einer Klasse nur eine global zugreifbare Instanz existiert), Erzeuger (trennt den Aufbau eines Objektes von seiner Darstellung), Fabrikmethode (definiert eine Schnittstelle zur Erzeugung eines Objektes), Prototyp (bietet exemplarische Instanz) Strukturmuster: Adapter (wandelt die Schnittstelle dienstleistender Klassen so um, daß dienstnutzende Klassen sie verwenden können), Brücke (entkoppelt eine 12

Abstraktion von ihrer Implementierung, damit beide unabhängig voneinander verändert werden können), Dekorateur (heftet dynamisch zusätzliche Verantwortlichkeiten (Operationen) an, Alternative zur Generalisierung), Fassade (stellt eine einheitliche Schnittstelle für eine Menge von Schnittstellen zur Verfügung), Fliegengewicht (benutzt wenige komplexe Objekte mehrfach, um eine große Anzahl kleiner Objekte effizient handhaben zu können), Kompositum (ermöglicht den einheitlichen Zugriff auf die Elemente hierarchisch strukturierter Objektstrukturen), Surrogat (stellt über ein stellvertretendes Objekt eingeschränkte Zugriffe auf das eigentliche Objekt zur Verfügung) Verhaltensmuster: z. B. Beobachter, Iteratoren, Schablonen (definiert Grundgerüst von Algorithmen) Auswahl von Entwurfsmustern: Hinweise auf anzuwendende Muster geben oft nicht-funktionale Anforderungen; Überarbeitungsgründe sind Abhängigkeiten von Operationen, der Hardwareplattform oder von Schnittstellen, Algorithmen, sowie Flexibilisierungswünsche Einsatz von Entwurfsmustern: Algorithmus: Musterbeschreibungen durchlesen (Anwendbarkeit, Konsequenzen) vertiefendes Studium der Auswahl (Struktur, Beteiligte, Zusammenspiel) Beispielquelltexte ansehen Namen wählen anwenden KE6: Grobentwurf Ziele und Vorgehensweise: es wird nur auf Kopien von Entitätsobjekten gearbeitet, Änderungen werden nach endgültiger Prüfung wirksam; Kontroll- und Entitätsklassen sind in Bezug auf Schnittstellenklassen ausschließlich Dienstleister, Entitätsklassen sind wiederum in Bezug auf Kontrollklassen nur Dienstleister; Grobentwurf soll unabhängig von der Implementationssprache sein; 3-Schichten-Architektur: Schnittstellenklassen werden der externen Schnittstelle zugeordnet; Kontrollklassen und Entitätsklassen werden dem Anwendungskern zugeordnet; die Datenhaltung ist für den Grobentwurf nicht relevant 40 Externe Schnittstelle (S. 339) Benutzungsschnittstelle: ein Zustand der Benutzungsschnittstelle ist durch die Fenster und die in diesem Zustand möglichen Operationen charakterisiert; Einführung der Haupt-Schnittstellenklasse (HS-Klasse), die die Startseite des Anwendungssystems modelliert, ihre einzige Instanz wird beim Start des Anwendungssystems erzeugt, ihr Name ergibt sich aus dem Namen des Anwendungssystems mit angehängtem S; nach der Anmeldung des Benutzers erzeugt die Instanz der HS-Klasse eine Instanz der Akteur-Schnittstellenklasse, wonach der Akteur zum Fenster einer Instanz der AAS gelangen kann, die dem Anwendungsfall zugeordnet ist; externe Systeme: besitzen meist definierte aber nicht standardisierte Schnittstelle; zur Verkapselung externe Systeme wird für jedes externe System eine 13

korrespondierende Akteur-Schnittstellenklasse entworfen, die sämtliche Kommunikation mit dem externen System kontrolliert; wird im Grobentwurf ausschließlich aus Sicht der Dienstnutzer spezifiziert; 41 Anwendungskern (S. 342) Umfang: umfaßt die Kontrollklassen und Entitätsklassen aus dem Analyse-Klassenmodell; Kontrollklassen: für jedes Anwendungssystem wird eine Haupt-Kontrollklasse modelliert; von ihr gibt es nur eine Instanz, die beim Start von der Haupt-Schnittstellenklasseninstanz erzeugt wird, sie wird durch den Namen des Anwendungssystems mit angehängtem K bezeichnet; Entitätsklassen: die aus der Analyse übernommenen Entitätsklassen werden als persistente Klassen markiert und um einige Standardoperationen erweitert; Assoziationen zwischen Kontrollklassen und Entitätsklassen sind einseitig navigierbar von den Kontrollklassen zu den Entitätsklassen hin; 42 Modellverfeinerung (S. 345) Entitäts- und Kontrollklassen: Schnittstellenobjekten stehen nur Kopien von Entitätsobjekten zur Verfügung, während Kontrollobjekte sowohl auf Kopien als auch auf Originalen von Entitätsobjekten arbeiten; es sind die Standardoperationen von Entitäts- und Kontrollklassen in geeigneter Weise zu erweitern; Erweiterung um giballenamen():string [] (liefert eine Liste mit den Namen aller E-Instanzen), gibkopie(in name:string):e (liefert eine Kopie der E-Instanz mit dem Namen name), gib(in name:string):e (liefert die E-Instanz mit dem Namen name) und kopiereattribute(in instanz:e) (kopiert alle Attribute der E-Instanz instanz in die der ausführenden E-Instanz) Schnittstellenklassen: Erweiterung um öffnen() (stellt das entsprechende Fenster und die Attributwerte von Entitätsobjekten, deren Namen als Parameter übergeben wurden, am Bildschirm dar), schließen() (entfernt das entsprechende Fenster vom Bildschirm und beendet den Anwendungsfall, abbrechen() (wird zum vorzeitigen Abbruch des Anwendungsfalls aufgerufen) und ausgeführt() (wird vom Schnittstellenobjekt eines benutzten Anwendungsfalls bei dessen Beendigung aufgerufen) Pakete: weitere import-beziehungen werden notwendig 43 Verhaltensmodellierung (S. 349) Vorgehensweise: zuerst werden die in der Analyse erstellten Interaktionsdiagramme für das ablauforientierten Verhalten komplexer Anwendungsfälle an die Detaillierung des Grobentwurfs angepaßt; dann werden die Abläufe von in den Anwendungsfällen auftretenden komplexen Operationen modelliert; komplexe Operationen: Ausgangspunkt ist die textuelle Beschreibung der Verantwortlichkeiten der betreffenden komplexen Operation; man untersucht, 14

ob die Operation Instanzen erzeugt oder zerstört, Verbindungen errichtet oder weitere Operationen benötigt; nicht-standardoperationen werden nachgetragen, woraufhin der Ablauf einer komplexen Operation z. B. als Sequenzdiagramm modelliert werden kann; KE7: Feinentwurf Ziele und Vorgehensweise: zuerst wird sich für ein Rahmenwerk entschieden; als nächstes wird die Benutzungsschnittstelle realisiert; danach reichert man die Kontrollklasse des Anwendungsfalls um Operationen an, welche die von der Externen Schnittstelle geforderten Funktionen realisieren; nun werden die UML-Modellierungselemente, die sich nicht direkt in der Zielsprache implementieren lassen, mit Hilfe von Transformationsregeln in zielsprachenkonforme Entwurfskonstrukte überführt; daraufhin werden verbliebene große Pakete und Klassen in kleinere und weniger komplexe Pakete und Klassen zerlegt; danach werden Entitätsklassen in das Rahmenwerk integriert; abschließend werden die Klassen im Hinblick auf ihre Realisierung mit Operationen und Datenstrukturen versehen; Benutzungsschnittstelle: Ausgangspunkt sind Skizzen oder Prototypen; im Feinentwurf erfolgt die Abbildung der Interaktionsinformationen von Schnittstellenklassen auf technische Klassen des verwendeten GUI-Rahmenwerks (z. B. Java-Swing); jedes Fenster entspricht einer Schnittstellenklasse; Attribute der Entitätsklassen entsprechen Eingabefelder im Fenster; AAS-Klassen aggregieren mehrere Sicht-Schnittstellenklassen (auch Sicht-Klassen), welche die darzustellenden Eigenschaften der von dem entsprechenden Anwendungsfall betroffenen Instanzen von Entitätsklassen modellieren und verantwortlich für deren Präsentation sowie für die Entgegennahme der zugehörigen Benutzeraktionen sind;es gibt zu jeder Entitätsklasse und jeder AAS-Schnittstellenklasse eine Sicht-Klasse, jede Sicht-Klasse beschreibt die Attribute und Assoziationen einer Entitätsklasse, die im Rahmen des Anwendungsfalls durch einen Akteur in einem Fenster bearbeitet werden können; eine Sicht-Klasse wird durch den Namen der AAS-Schnittstellenklasse gefolgt von dem der Entitätsklasse mit angehängtem S bezeichnet; Anwendungskern: Hauptziel im Feinentwurf dieser Schicht ist es, die Kontrollklassen um Operationen anzureichern, welche die von der externen Schnittstelle geforderten Zugriffe auf Entitätsklassen der Datenhaltungsschicht sowie die fachlichen Funktionen realisieren; das vom Anwendungssystem allein determinierte ablauforientierte Verhalten der Anwendungsfälle wird in Kontrollklassen realisiert; Pakete: es bietet sich eine Aufteilung der Klassen auf anwendungsspezifische und anwendungsunabhängige Pakete an, erstere enthalten alle Klassen der drei Schichten, die speziell für das Anwendungssystem entwickelt werden, letztere enthalten Klassen,die auch für andere Anwendungssysteme der Domäne wiederverwendbar sind; 15

48 Transformationen (S. 379) Einführung: dienen zur Abbildung von Modellierungselemente wie Assoziationen oder Zustandsdiagramme auf Entwurfskonstrukte, so daß eine Implementation in einer objektorientierten Programmiersprache unmittelbar durchführbar ist Assoziationen: Standardfälle: vorher klären: ist die Navigierbarkeit einseitig oder bidirektional? Sind die Multiplizitäten der beiden Assoziationsenden beschränkt (z. B. 0..2), exakt (z. B. 1) oder unbeschränkt (*)? Einseitig navigierbare 1:1-Assoziationen: man kann die Assoziation direkt auf ein neu zu deklarierendes Attribut der Klasse transformieren, von der aus die Assoziation navigierbar ist.das Attribut erhält den Namen der Assoziation oder ggf. den der Rolle der assoziierten Klasse Bidirektional navigierbare 1:1-Assoziationen: transformiert man auf je ein Attribut in jeder der beiden an der Assoziation beteiligten Klassen; die Konsistenz der Verbindungen muß durch die entsprechende Implementierung der Standardoperationen verbinde() und löse() sichergestellt werden Einseitig navigierbare 1:n-Assoziationen mit festem n: bei sehr kleinem n kann für jede Referenz ein Attribut vorgesehen werden; bei großem n können die Referenzen auf verbundene Instanzen in einem Feld vorgehalten werden; Einseitig navigierbare 1:n-Assoziationen mit variablem n: die Transformation hängt wesentlich von der Richtung der Navigierbarkeit ab, ist die Assoziation zu der Klasse hin navigierbar, von der höchstens eine Instanz an einer entsprechenden Verbindung teilnimmt, reicht die für einseitig navigierbare 1:1-Assoziationen vorgestellte Transformation aus; im umgekehrten Fall müssen bezüglich der Assoziation mehrere verbundene Instanzen gespeichert werden, was auf eine 1:1-Assoziation zu einer Behälterklasse wie Collection oder List zurückgeführt werden kann Bidirektional navigierbare 1:n-Assoziationen: Aufspaltungin zwei einseitig navigierbare 1:n-Assoziationen n:m-assoziationen: zunächst wird eine weitere Klasse, deren Instanzen jeweils zwei miteinander verbundene Instanzen der assoziierten Klassen enthalten, hinzugefügt; jede Instanz dieser Klasse stellt ein Paar dar, von der global sichtbaren einzigen Instanz einer Relationsklasse (Einzelstück) werden alle Paarinstanzen verwaltet und Iteratoren zum Zugriff auf die mit einer Instanz verbundenen Instanzen zur Verfügung gestellt; Instanzen der Paarklasse werden aus- schließlich von der Instanz der Relationsklasse erzeugt; Spezielle Assoziationen und Assoziationsklassen: Aggregations-und Kompositionsbeziehungen: unterscheidet sich nicht wesentlich von der Transformation von Assoziationen mit gleichwertigen Multiplizitäten Assoziationsklassen: stellt eine Erweiterung der Transformation einer n:m-assoziation dar; die Assoziationsklasse wird zur Realisierung der Paarklasse um Attribute und Operationen sowie jeweils eine Assoziation zu den ursprünglich assoziierten Klassen erweitert echte Ganzes-Klassen: eine Klasse ist eine echte Ganzes-Klasse, wenn es Situationen gibt, in denen zu ihren Instanzen nicht über Verbindungen von Instanzen einer anderen Klasse aus hin navigiert werden kann; für jede echte Ganzes-Klasse legt man eine Ordner-Klasse (als Einzelstück) an, die zur echten Ganzes-Klasse in 16

einer 1:n-Assoziation steht und deren Instanz alle Instanzen der echten Ganzes-Klasse enthält sowie Iteratoren für entsprechende Zugriffe bereitstellt, anschließend ist die 1:n-Beziehung von der Ordner-Klasse zur echten Ganzes-Klasse mit der entsprechenden Transformation zu behandeln include- und extend-beziehungen: diese Beziehungen haben sich im Klassenmodell der Analyse und des Grobentwurfs in einer Assoziation zwischen den entsprechenden Schnittstellenklassen niedergeschlagen, diese Assoziation wurde als einseitig navigierbar spezifiziert und zwar von der Schnittstellenklasse des benutzenden bzw. des erweiternden Anwendungsfall hin zu der des benutzten bzw. erweiterten Anwendungsfalls; für include wird die hierfür eingeführte Assoziation zwischen den Schnittstellenklassen beizubehalten und die Aktivierung des benutzten Anwen- dungsfalls über entsprechende Operationsaufrufe vorgenommen; extend wird mit dem Beobachter-Mister realisiert Zustandsdiagramme: (die Erklärung auf S. 398 kapiere ich jetzt nicht) 17