ooad - sws.bfh.ch · pdf file2 1. einführung grundprinzipien des ooad viele der ideen und...
TRANSCRIPT
1
OOADObjekt Orientierte Software Analyse und Design mit UML
Dr. Beatrice Amrhein
Mai‐11
2
1. Einführung
Grundprinzipien des OOAD
Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir freundlicherweise als Ausgangspunkt für dieses Skript zur Verfügung gestellt hat. Vielen Dank!
3
Kurs Überblick1. Einführung ……………. 2
2. Use Cases …………….23
3. Klassenstruktur …………….42
4. Beziehungen …………….55
5. Weitere Strukturdiagramme …………….90
6. Aktivitäten …………..106
7. Zustände …………..119
8. Interaktion, Kommunikation …………..131
9. GUI Prototyp …………..145
10. Analyse Muster …………..154
11. Datenbank Prototyp …………..178
12. Design Pattern
4
Lernziele
Vorgehensweise in objektorientierter Software Analyse und Design
Projekt-AnalyseDesign (Entwurf)ModellierungDokumentation
Eine saubere Analyse und ein gutes Design sind Grundvoraussetzung für eine erfolgreiche Projekt‐Realisierung. Diese Entwicklungsschritte werden anhand von UML (Unified Modeling Language) vermittelt und geübt. UML ist für den objektorientierten Entwurf konzipiert. Viele Elemente daraus können aber auch für die nicht‐objektorientierte System‐Entwicklung genutzt werden. UML ist heute zum de facto Standard für die Software Analyse‐ und Design‐Phase geworden.
Die Studierenden sollen in diesem Kurs gute Kenntnisse des Software‐Design‐Vorgehens erlangen und in der Lage sein, kleinere Projekte selbständig zu analysieren, zu entwerfen und mit UML zu modellieren und zu dokumentieren; in mittleren und grösseren Projekten sollen sie als kompetente und sachkundige Partner mitwirken können.
5
Lerninhalte
Konzepte der ModularisierungTop-Down / Bottom-Up
Grobanalyse ModellProdukt-KartonUse Cases Szenarien
Objekt Orientierte SyntheseFachklassen DiagrammAktivitäts-, Zustands-, Sequenz-Diagramm, …
Objekt Orientiertes DesignDesign Pattern, Architektur, …
Um diese Ziele zu erreichen behandelt dieser Kurs die OO‐Analyse und den OO‐Design zusammen mit den entsprechenden Werkzeugen der UML wie:
Use‐Case Model und –Beschreibung, Szenarien, Fachklassen‐Diagramm, Objekt‐Diagramm, Sequenz‐Diagramm, Kommunikations‐Diagramm, Aktivitäts‐Diagramm, Zustands‐Diagramm, Paket‐Diagramm, Komponenten‐Diagramm
Weiter werden wir einfache Analyse‐ und Design Pattern, sowie Design‐Heuristiken betrachten, ein erstes GUI‐Design und Datenbank‐Design (Prototyp) entwerfen.
Im Kurs werden wir ein CASE‐Tool benutzen. Es wird darum eine kurze Einführung in ein solches Tool gegeben.
6
SW Entwicklung beginnt im Kopf
Nachdenken ist besser als nachbessernJedes Problem muss einmal durchdacht werden
besser früher als späterAm Anfang sind Änderungen noch einfach machbar
Eine falsche Design- oder Architektur-Entscheidung kann sehr viel Geld kostenEin früher Codier-Beginn erzeugt unnötige Sachzwänge und schlecht wartbaren Code
„Codierer“
Realisierung100%
0 %
Zeit
Implementations‐Beginn
„Designer“
Die Komplexität der zu realisierenden Informatik Projekte hat in den letzen Jahren laufend zugenommen. Bei so aufwändigen Projekten ist es enorm wichtig, die Software‐Entwicklung mit Design Methoden und einer sauberen Dokumentation anzufangen. Andernfalls verteuern sich solche Projekte extrem und die Software ist auch später nicht wartbar.
7
Iterative SW Entwicklung
Projekt Idee
Pflichtenheft (SRS)
Analyse ModellGrob Design
Design PhaseDetail Design
Programmierung
System Test
Beim Top‐Down Modell hat man grob die obigen Phasen. Oft ist es allerdings so, dass wir Fehler im Programm, im Detail‐Design, im Grob‐Design, … finden, was dazu führt, dass wir (in Teilen des Projekts) im Ablauf zurückgeworfen werden.
Je nachdem, wie viele Schritte wir zurück gehen müssen, entstehen höhere Kosten:Einen Schritt zurück (Codierfehler) ‐> wenig AufwandZwei Schritte zurück (Fehler im Detail‐Design) ‐> schon aufwändiger zu beheben da oft mehrere Klassen oder Pakete betroffen sind.
Drei Schritte zurück (Fehler in der Analyse/Grob‐Design) ‐> teuer zu behebenVier Schritte zurück (Fehler in der Spezifikation) ‐> riesiger Aufwand!
8
Top-Down Entwurf
Beginn auf oberster (abstrakter) EbeneGesamt Aufgabenstellung, Anforderungen, …
Schrittweise VerfeinerungProblem aufteilen -> SubsystemeSubsystem aufteilen -> Komponenten. . .
Vereins-Verwaltung
Mitglieder Anlässe Finanzen
Adressverwaltung Terminverwaltung Buchhaltung
. . . . . .
Vorteil: in sich geschlossene Lösung, sauberer Design, klare Struktur, Design Fehler werden früh erkannt
Nachteil: Grosser Initialaufwand, grosse Gefahr am Kunden vorbei zu planen oder Probleme zu lösen, die schon gelöst sind.
9
Bottom-Up Entwurf
Beginn auf unterster EbeneLösen der TeilproblemeSchrittweise Einbindung bereits erstellter TeillösungenNach und nach Zusammensetzen zu einer Gesamtlösung
Vereins-Verwaltung
Mitglieder BeiträgeMitglieder erfassen
Adresse ändern Termine verwalten Buchhaltung
. . . . . . . . .
Vorteil: schnelle Lösung von einzelnen Problemen, sofort einsetzbarNachteil: Kein Gesamtkonzept, Teillösungen passen nicht richtig zusammen, schlecht planbar, schlecht wartbar, Fehler beheben kann extrem teuer sein.
10
Beide Methoden mischen
Requirements erfassenAnalyse PhaseAusgewählte Prototypen entwickeln KundeDetail-Design erst nach Kunden FeedbackPrototyp wegwerfen!Design Variante entscheidenRealisierung
Abhängig von der Komplexität und der Grösse des Projekts muss eine geeignete Mischung der beiden Ansätze gepflegt werden.
Der Prototyp darf auf keinen Fall als Code‐Grundlage für die Realisierung benutzt werden. Er dient bloss dazu, vom Kunden die exakten funktionalen (und nichtfunktionalen) Anforderungen zu erhalten.
11
Projekt Ablauf
Zeit
Projekt‐Idee,
Vor‐Abklärungen
Stakeholder
Projekt‐Entscheid
Projekt‐Ende
Vorstudien Projekt Betrieb
Projekt‐Umriss,
Require‐mentsEngineering
Konzept‐Varianten
Grob‐Design
Prototypen
Dokumentation, Qualitätssicherung
Analyse Design (CASE‐Tool)
Realisierung
Detail‐Design
Programmierung
Daten‐Bereitstellung /
System Umfeld
Testen
EinführungRelease
Nach‐kontrolle
Projekt‐Beginn
Projekt‐Umriss, Requirements Engineering: Umschreibung und Abgrenzung des Problembereichs, Problem Analyse, Pflichtenheft
Konzept‐Varianten, Grob‐Design: Skizzen erster Lösungsideen, Variantenvergleich mit Bewertung, Wirtschaftlichkeitsanalyse, Abschätzen des Projekt‐Umfangs, Projektablauf, Arbeits‐ und Zeitplan, Antrag auf Varianten‐Entscheid
Realisierungsphase: Detail‐Design, Aufgliederung in Teilprobleme (Schichten), System‐Schnittstellen, Spezifikation der Benutzerschnittstelle, Einführungsplan
Programmierung: Implementation und Programm Dokumentation.Testen: System Tests, Performance Tests, Schnittstellen Tests, … falls Änderungen nötig sind Dokumentation nachführen
Einführung: Vorbereitung des Betriebs, Datenübernahme, ev. Schulung oder Parallel‐Betrieb, Formale Abnahme des neuen Systems.
Qualitätssicherung: Reviews, WalkThrough, Prototyping, Modultests, Systemtests, Abnahmetests, Nachkontrolle
12
Analyse Phase
Anforderungen an das Zielsystem ermitteln und beschreibenObjekte bestimmenHauptaufgaben der Objekte bestimmenErstellen eines konsistenten und vollständigen Fachklassen Modells (Struktur und Semantik)GUI Prototyp (Papier oder Mock-up) erstellen
AberKeine Implementierungs-Aspekte oder Entscheide
In der Analysephase geht es nicht um das wie, sondern nur um das was:Welche Aufgaben hat das System genau zu lösen?Was sind die Systemgrenzen?Welche Informationen, Daten, Objekte, … sind relevant?Was haben die Objekte für Eigenschaften?In welchen Beziehungen stehen diese Objekte zueinander?Was haben die Objekte für Aufgaben?
13
Ablauf der Analyse
Systemidee, Zielsetzung
Fact SheetProdukt‐Karton
Stakeholder bestimmen Umfeld, Abgrenzung
AnwendungsfälleAbläufe
NichtfunktionaleAnforderungenerfassen Glossar Fachklassen
bestimmen
Use Case DiagrammeAktivitätsdiagrammeSzenarien, . . .
Klassendiagramme, Paketdiagramme
Analyse Modell
System‐Kontext
SicherheitPerformanceProgrammiersprache. . .
Die Analyse beginnt mit der Systemidee: Was soll das Endprodukt anbieten?Die Systemidee sollte grob (zum Beispiel mit einem Fact Sheet oder einem Produkt‐Karton) skizziert werden.
Als nächstes werden die Stakeholder bestimmt. Alle Personen oder Personengruppen, die am Projekt direkt beteiligt, am Projektablauf interessiert oder von den Auswirkungen der Projektziele oder Projektergebnisse betroffen sind, definiert man als Stakeholder (Kunden, Projektleiter, Mitarbeiter, Geldgeber, …).
Dann muss das Umfeld abgegrenzt werden: Was wird gebaut? Welche bereits vorhandenen Systeme werden vorausgesetzt (Betriebsystem, Druckerei, Kundenverwaltung, Datenbank, …)?
Im Analyse Teil werden nur die Ideen und Abläufe erfasst, keinesfalls aber (technische) Lösungen beschrieben.
14
Produkte der Analyse Phase
Pflichtenheft (SRS)Fachkonzept
Statisches ModellKlassen, Attribute, Assoziationen, Vererbung, Pakete, …
Dynamisches ModellFunktionsabläufe durch Use Cases, Aktivitäten, Szenarien, State‐Event Diagramme, …
Modell-Beschreibungen / Dokumentation
Das Fachkonzept muss so viel Informationen enthalten, dass daraus ein erster Prototyp der Benutzeroberfläche erstellt werden kann. Damit lässt sich das zukünftige System mit dem zukünftigen Benutzer evaluieren. Zusätzlich benötigen wir ein Konzept für die Navigation, Zugriffsrechte, Hilfestellungen für den Benutzer, …
15
Design Phase
In der Design-Phase werden die technischen Details bestimmt:Gesamt-Architektur (Schichten)Design Pattern, Schnittstellen
-> Komponenten, Interfaces, Packages, …Ergonomie -> BenutzeroberflächeDatenhaltung -> DB Design Performance, Verteilung, Wartbarkeit, …
-> Ziel-PlattformProgrammier-Sprache, -Umgebung …
In der Analysephase geht man von einer idealen Umgebung aus, das heisst, wir kümmern uns weder um Probleme bei der Umsetzung, noch um Speicherplatz, weder um Kosten oder Aufwände oder Effizienz.
In der Design‐Phase geht es nun um das „wie“. Sie spezifiziert, wie die Anwendung auf welcher Plattform mit den geforderten technischen Randbedingungen zu realisieren ist. Allerdings sind wir dabei immer noch in der Konzept‐Phase, beginnen also noch nicht mit der Implementation.
In der Design Phase wird die Architektur bestimmt. Die Software Architektur definiert die verschiedenen Komponenten, deren Schnittstellen, Aufgaben und Verhaltensweisen. Es werden die Details wie Programmiersprache und‐ Programmierumgebung, Plattform, Schichtung, Speicherbedarf, nötige Algorithmen, zu benutzende Datenstrukturen und viele andere technische Details festgelegt.
16
Produkte der Design Phase
Software Architektur BeschreibungSchichtenPackagesKomponentenSchnittstellen
GUI Design, DB DesignPerformance AnforderungenPrioritätenliste, Implementations-PlanTest Plan, Einführungs-Plan…
Üblicherweise beginnt man mit einem Grobdesign und verschiedenen Lösungsvarianten. Die verschiedenen Lösungen werden gegeneinander verglichen und bewertet (Prioritäten). Die bevorzugten Varianten werden verfeinert, mit dem Variantenentscheid wird festgelegt, welches Detail Design ausgearbeitet wird.
Das gesamte Projekt muss oft in verschiedene, sinnvolle Teilprojekte (Spezialisten für GUI/Ergonomie oder DB‐Design) aufgeteilt werden.
17
Vorteile des OO SW-Engeneering
Ganzheitliche BeschreibungDaten/InformationenFunktionen/Operationen
Durchgängige Konzepte durch alle PhasenAkteure -> KlassenAktionen -> Operationen
Gleiche Notation für Analyse und DesignKunde, Bestellung, Rechnung, …
Objekt
Die objektorientierte Programmierung ist ein auf dem Konzept der Objektorientierung basierendes Programmierparadigma. Die Grundidee dabei ist, Daten und Funktionen, die auf diese Daten angewandt werden können, möglichst eng in einem sogenannten Objekt zusammenzufassen und nach außen hin zu kapseln, so dass Methoden fremder Objekte diese Daten nicht versehentlich manipulieren können.
Bei der objektorientierten Programmierung werden Objekte ganzheitlich beschrieben, d.h. die Festlegung der Datenstrukturen und der mit den Daten ausgeführten Aktionen erfolgt in einem.
Das objektorientierte Software‐Engineering hat den zusätzlichen Vorteil, dass durch alle Phasen die gleiche Notation und die gleichen Konzepte (Klassen, Methoden, Schnittstellen, Vererbung,…) verwendet werden kann.
18
Einfaches Abbilden von Objekten der realen WeltModularisierung in „handliche“ EinzelteileEinfache Schnittstellen zwischen den KomponentenWiederverwendbarkeitErweiterbarkeitAustauschbarkeit
Vorteile des OO SW-Engeneering
Die wichtigsten Vorteile der objektorientierten Programmierung sind:Objekte der realen Welt lassen sich (relativ) einfach in Klassen abbilden.Die Aufspaltung von komplexen Software‐Systemen in kleine, einfache, in sich geschlossene Einzelteile (Modularisierung)
einfache und klar verständliche Schnittstellen zwischen den einzelnen Komponenten,geringerer Programmieraufwand durch die Wiederverwendung von Elementen (z.B. auch durch Vererbung).
Je klarer und einfacher die Objekte (Klassen) und deren Schnittstellen gewählt werden, desto besser werden diese Ziele erreicht.
19
OO Design Prinzipien
Abstraktion, GeheimnisprinzipDatenkapselung
Polymorphie„gleiche“ Operation kann unterschiedliche Ausprägung haben.
Vererbung/Erweiterung/EinschränkungPersistenz/Lebenszeit
Objekte „überleben“ so lange sie gebraucht werden
ModularisierungKomponenten zu einem Ganzen zusammensetzen
Abstraktion Jedes Objekt im System ist ein abstraktes Modell eines Akteurs. Es kann Aufträge erledigen, seinen Zustand berichten und ändern und mit den anderen Objekten im System kommunizieren. Es gibt aber nicht bekannt, wie diese Fähigkeiten implementiert sind.
Datenkapselung Auf die interne Datenstruktur kann nicht direkt zugegriffen werden, sondern nur über definierte Schnittstellen. Objekte können den internen Zustand anderer Objekte nicht in unerwarteter Weise lesen oder ändern. Ein Objekt hat eine Schnittstelle, die darüber bestimmt, auf welche Weise mit dem Objekt interagiert werden kann. Dies verhindert das Umgehen von Invarianten des Programms.
Polymorphie Verschiedene Objekte können auf die gleiche Nachricht unterschiedlich reagieren.
Vererbung Eine abgeleitete Klasse besitzt die Methoden und Attribute der Basisklasse ebenfalls. Neue Arten von Objekten können auf der Basis bereits vorhandener Objektdefinitionen festgelegt werden. Es können neue Bestandteile hinzugenommen werden oder vorhandene überlagert (überschrieben) werden.
Persistenz Objektvariablen existieren, solange die Objekte vorhanden sind. Sie verfallen nicht nach Abarbeitung einer Methode.
Modularisierung Einzelne Komponenten lassen sich unterschiedlich zu einem Ganzenkombinieren, wenn sie klare Schnittstellen definieren (und einhalten) Kompatibilität.
20
OO Design Prinzipien
Single Responsibility PrinzipKlare Verantwortlichkeit
Self-Documentation PrinzipSprechende Namen, dokumentierter Code
Uniform Access Prinzipgetter / setter Methoden
Open-Closed PrinzipFixe Schnittstellen, Unterschiedliche Ausführungen
Substitution PrinzipKonsistente Vererbung
Single Responsibility: Jede Klasse hat nur eine Verantwortung ‐> besser dokumentierbar, besser wartbar.
Self‐Documentation: Die Namen der Klassen, Operationen, … sind selbsterklärend. Die Dokumentation befindet sich im Programmcode ‐> Javadoc, Doxygen
Uniform Access: Durchgängige Notation der Zugriffsmethoden ‐> setter/getterOpen‐Closed: Erweiterungen von Komponenten, Klasse, Operationen müssen möglich sein, ohne dass die Schnittstelle verändert werden muss ‐> Wartbarkeit.
Substitution: Statt der Basisklasse kann jederzeit ein Objekt der abgeleiteten Klasse verwendet werden ‐> konsistente Vererbung auch bei Polymorphie.
21
OO Design Prinzipien
Interface Segregation PrinzipAbhängigkeiten knapp halten
Persistence Closure PrinzipPersistieren des ganzen Objekt Zustands
Acyclic Dependencies PrinzipMöglichst keine zyklischen Abhängigkeiten
Gesetz von DemeterObjekte kommunizieren vor allem mit ihren Nachbarn
Design by ContractKlare, verifizierbare Schnittstellen, Vorbedingungen, Nachbedingungen, Invarianten.
Interface Segregation: Interfaces sollten so aufgeteilt werden, dass sie den Bedürfnissen der Clients (der Anwendung) entsprechen ‐> keine unnötigen Abhängigkeiten
Persistence Closure: Objekte werden mit all ihren Abhängigkeiten (Gesamt‐Zustand) persistiert ‐> späteres Wiedereinlesen stellt den gleichen Zustand her.
Acyclic Dependencies: Keine Zyklen in der Abhängigkeits‐Kette von Klassen, Packages, Komponenten.
Gesetz von Demeter: Objekte kommunizieren in erster Linie mit Objekten in ihrer Umgebung ‐> Entkoppelung, bessere Wartbarkeit, starke Bindung im Nahbereich, schwache Bindung über Komponenten‐/Pakete‐/Schichten‐Grenzen hinweg.
Design by Contract: Klare, verifizierbare Schnittstellen, die eingehalten werden müssen. Komponenten und Operationen erfüllen exakt die Spezifikation (Vorbedingungen, Nachbedingungen, Invarianten).
22
Astah Einführung
Übung 1
23
2. Use Cases
Anwendungsfälle, Szenarian Anwendungsfall-
Beschreibungen
Vgl. Oestereich Kap 2.1 Seiten 21‐49.
24
Definition
Ein Anwendungsfall (Use Case) beschreibt einen einzelnen Arbeitsgang eines oder mehrerer Akteure mit einem System aus der Sicht des Anwendershat als Namen möglichst ein aktives Verb, welches die Tätigkeit beschreibtwird mit Hilfe einer Ellipse grafisch dargestellt.
Ein Anwendungsfall ist eine zeitlich ununterbrochene Interaktion (ein Arbeitsschritt).Anwendungsfall Namen bestehen aus einem Subjekt und einem Verb wie zum Beispiel „Daten erfassen“, „Adresse ändern“, „Auto reservieren“, „Konto löschen“, … (oder Verb/Subjekt in anderen Sprachen: „change address“).
Häufig sind Anwendungsfälle die computerunterstützten Teile von Geschäftsprozessen.
25
Verwendung
Use Case Diagramme werden sehr früh im Analyse Prozess verwendet umdie verschiedenen Benutzerrollen/Anwender und deren Aufgaben (Rechte) grob festzulegenmit dem Kunden die (Haupt-)Aufgaben des Systems zu skizzierenmit dem Kunden die Systemgrenzen zu definieren
Schnittstellenwas ist nicht Aufgabe des Systems
Es werden mit dem Use Case Diagramm aber noch keine Abläufe und kein Verhalten beschrieben.
26
Use Case Diagramm
stellt Beziehungen zwischen Akteuren und Anwendungsfällen aus Sicht der Akteure darbeschreibt grob, was das System leisten sollbeschreibt einen Ablauf, ist aber keine Ablaufbeschreibung
es wird keine Ablaufreihenfolge definiertist vorwiegend ein Hilfsmittel zur Anforderungsermittlung mit dem Anwender
dient nicht der Verhaltensbeschreibung oder dem Systemdesign
Man spricht auch von Anwendungsfall Diagramm.Die einzelnen Anwendungsfälle können später noch verfeinert und aufgegliedert werden.Kunde erfassen ‐‐> Name erfassen, Geburtsdatum erfassen, Rechnungs‐Adresse erfassen,
Liefer‐Adresse erfassen, …Das Anwendungsfall Diagramm beschreibt nicht, wie die Umsetzung oder Realisierung dieser Anwendungsfälle geschehen soll.
Zur Ablaufbeschreibung von Anwendungsfällen dienen Verhaltens‐ oder Interaktionsdiagramme (Aktivitätsdiagramm, Zustandsdiagramm, Sequenzdiagramm, …)
27
AkteureAkteure sind beteiligte Personen oder Systeme
Anwender, Kunde, Mieter, Uhr, System, …Man unterscheidet
Primäre Akteuredie eigentlichen Benutzer des Systems
Sekundäre Akteure welche das System überwachen oder warten oder den Primärakteur bei seiner Arbeit unterstützen
Akteure werden mit ihrer Rolle beschriftet
PrintingSystem
Ein Akteur (actor, stake holder) ist eine an verschiedenen Anwendungsfällen beteiligte aber außerhalb des zu realisierenden Systems agierende Einheit.
Normalerweise ist ein Akteur ein Mensch oder ein technisches System, ev. auch ein Ereignis.Akteure werden nicht personifiziert, sondern nur ihre Rolle ist relevant.Akteure können untereinander Generalisierungs‐ oder Spezialisierungs‐Beziehungen haben.
Akteure werden normalerweise als Strichmännchen, Zeitereignis‐Akteure manchmal auch als Uhr, Fremdsystem Akteure als Würfel oder als Box gezeichnet.
Akteure können eine Multiplizität haben. Diese gibt an, wie viele Akteure der angegebenen Rolle am Anwendungsfall beteiligt sein müssen (Defaultwert: 1).
Auf der Seite des Anwendungsfalls gibt die Multiplizität an, wie oft dieser Anwendungsfall gleichzeitig ausgeführt werden darf (Defaultwert: 0..1).
28
Typen von Anwendungsfällen
GeschäftsanwendungsfallFerien planen, Film schauen, Meeting organisieren, …
SystemanwendungsfallKunden, Bestellungen, Informationsmaterial, Kosten, … erfassen, ändern, löschen, berechnen, …
Sekundärer AnwendungsfallLagerbestand prüfen, Rechnungs-Ausstände auflisten, Einloggen
Ein Geschäftsanwendungsfall beschreibt einen Anwendungsfall in abstrakter fachlicher Form aus Sicht des Anwenders. Aus einem fachlichen Geschäftsanwendungsfall (Ferien planen) können sich mehrere konkrete Systemanwendungsfälle ergeben (Hotelzimmer reservieren, Flug buchen, Informationsmaterial bereitstellen, …)
Der Systemanwendungsfall bündelt alle möglichen Fälle (Szenarien), die eintreten können, wenn ein Akteur versucht, ein bestimmtes Ziel zu erreichen (Kundendaten erfassen, Konto eröffnen, Bestellung bearbeiten, …). Man spricht hier oft auch von einem primären Anwendungsfall.
Sekundäre Anwendungsfälle sind normalerweise Teil eines anderen Systemanwendungsfalls und haben keine eigenes unabhängiges Ziel (Hilfs‐Aufgaben).
Der Anwendungsfall beschreibt nur sehr grob, was beim Versuch der Zielerreichung passieren kann und abstrahiert von konkreten technischen Lösungen.
Das Ergebnis des Anwendungsfalls kann ein Erfolg oder ein Fehlschlag/Abbruch sein.
29
Vererbung
Beispiele Konto eröffnen Sparkonto / Privatkonto eröffnenKundendaten ändern Adresse, Kundenstatus ändern
Die Basis Anwendungsfälle „Konto eröffnen“ und „Kundendaten ändern“ werden als abstrakter Anwendungsfall bezeichnet.
Die Anwendungsfälle „Sparkonto eröffnen“, „Privatkonto eröffnen“, … sind dann die konkreten Spezialisierungen oder Realisierungen.
30
Include Beziehung
Ein Anwendungsfall kann (logischer) Teil eines anderen Anwendungsfalls seinDie Pfeilrichtung zeigt auf den enthaltenen Anwendungsfall, die Beziehung wird mit «include» bezeichnet.
Der enthaltene Anwendungsfall ist oft ein sekundärer Anwendungsfall (vgl. Beispiel oben). Sekundäre Anwendungsfälle werden nur indirekt, durch einen primären Anwendungs
Ein Systemanwendungsfall kann aber ebenfalls in einer Include Beziehung zu einem anderen Anwendungsfall stehen Beispiele: Zinsen werden jährlich ausbezahlt, aber auch beim Löschen eines Kontos, eine Adresse wird erfasst beim Erzeugen eines neuen Kunden oder ev. auch später als Zweitadresse.
31
Extend Beziehung
Diese drückt aus, dass ein Anwendungsfall unter gewissen Bedingungen durch einen anderen Anwendungsfall erweitert wirdDie Pfeilrichtung zeigt auf die zu erweiternde Basisanwendung und wird mit «extend»bezeichnet
Die Erweiterung ist von einer Bedingung abhängig, diese muss angegeben werden. Die Bedingung (Erweiterungspunkt, extension point) wird als Notiz neben den Anwendungsfall geschrieben.
Vorsicht! Die umgekehrte Pfeilrichtung im Diagramm gibt oft zu Fehlern Anlass.
32
Assoziation
Eine Assoziation beschreibt eine Relation zwischen dem Akteur und einem AnwendungsfallDie Multiplizität beim Akteur gibt an, wie viele Akteure beteiligt sein müssen oder könnenDie Multiplizität beim Anwendungsfall gibt an, wie oft dieser vom Akteur gleichzeitig ausgeführt werden darf
Fehlen die Multiplizitätsangaben, geht man von den Default‐Werten 1 beim Akteur und 0..1 beim Anwendungsfall aus.
33
Checkliste für Use Cases
Ist mindestens ein Akteur beteiligt?Repräsentiert der Akteur eine klare Rolle oder ein klar definiertes technisches System?Enthält der Name des Anwendungsfalls ein Substantiv und ein VerbIst der Name des Anwendungsfalls aus Sicht des Systems formuliert?Sind die Abhängigkeiten (Include, Extend) zu anderen Anwendungsfällen korrekt?Ist die Anwendungsfall Beschreibung vollständig?
Jeder Anwendungsfall braucht (direkt oder indirekt) einen Akteur, welchen den Anwendungsfall anstösst.
Ein Akteur darf nicht eine konkrete Person sein, sondern muss eine Rolle oder ein System repräsentieren (Customer, Consultant, Assistant, Accountant, …).
Der Name des Anwendungsfalls ist von der Art „Verb Subjekt“, also zum Beispiel „create Account“, „send Message“, „print Report“, …
Der Name des Anwendungsfalls muss so formuliert sein, dass man ihn im der Ablaufbeschreibung direkt benutzen kann: „The system has to create an account, send a message, and print a report“,
34
Use-Case Beschreibung
Eine Anwendungsfall Beschreibung besteht ausName des Anwendungsfalls KurzbeschreibungAkteurVorbedingung, AuslöserNachbedingung, Resultat, InvariantenParameter (Eingabedaten)Essenzieller Ablauf, Ausnahmen, FehlerOffene PunkteVersionierung (Autor, Datum, Status, …)Sonstiges, Bemerkungen
Diese Auflistung ist nicht vollständig und nicht Teil von UML. Es bewährt sich, bei der Anwendungsfall Beschreibung gewisse Formalismen einzuhalten, damit nichts Wichtiges vergessen geht.
•Ein Auslöser ist eine äusseres Ereignis, das den Anwendungsfall auslöst (z.B. ein Kunde möchte Geld anlegen).
•Eine Vorbedingung beschreibt den Zustand des Systems, bevor der Anwendungsfall eintritt (eintreten kann).
•Nachbedingung, Resultat (Ergebnis) ist das, was dem Akteur geliefert wird (z.B. ein neues Konto wurde eröffnet und eine Kontonummer erzeugt).
•Eingabedaten wären dabei Kundennummer, Kontotyp, …•Essentielle Schritte sind die einzelnen Ablaufschritte, welche eventuell genauer mit Hilfe eines Verhaltensdiagramms (Zustandsdiagramm, Aktivitätsdiagramm, …) beschrieben werden ( Verweis auf entsprechendes Diagramm).
Weitere mögliche Angaben sind:•Invarianten (Bedingungen, welche stets erfüllt sind/sein müssen).•Nicht funktionale Anforderungen (Plattform Voraussetzungen, qualitative/quantitative Aussagen, Antwortzeiten, Prioritäten, Häufigkeitsschätzungen, Benutzbarkeit, Änderbarkeit, …).
•Ausnahmen, Fehlersituationen (Anwenderfehler, fachliche Fehler, z.B. fehlende Berechtigung, Eingabedaten fehlen, …).
35
Beispiel: Use-Case Beschreibung
Ein Use‐Case Diagramm enthält zwar rudimentäres Wissen über das System und seine Akteure. Allerdings beschränkt sich die Information bei Use‐Case Diagrammen hauptsächlich auf den Namen des Use‐Case und die beteiligten Akteure.
Für detaillierte Informationen über die Use‐Cases benutzt man die Use‐Case Beschreibungen. Diese werden üblicherweise in einer Tabelle aufgelistet. Der Inhalt der Use‐Case Beschreibung, also die auszufüllenden Felder in der Tabelle können dabei (je nach gewünschtem/nötigem Detaillierungsgrad) variieren.
Im diesem Beispiel sind die essentiellen Inhalte einer Use‐Case Beschreibung enthalten. Es zeigt das empfohlene Minimum an Informationen in einer Use‐Case Beschreibung (Vgl Oestereich p. 30‐34).
36
Use-Case Szenarien
Ein Szenario beschreibt eine Abfolge von Schritten, die vom Use Case zu durchlaufen sind.Normalabläufe zeigen auf, wie der Anwendungsfall "normalerweise" (erfolgreich) abläuft.Alternativabläufe zeigen "andere" Wege zum Ziel auf, als dies im Normalablauf dargestellt wird.Ausnahmeabläufe führen nicht zum Ziel, z.B. infolge eines "fachlichen Fehlers" oder bei einem Abbruch durch den Akteur.
Als Test werden für jeden Anwendungsfall sogenannte Szenarien erstellt. In diesen wird der Vorgang detailliert beschrieben, und zwar so wie der Benutzer ihn am Ende an seinem Rechner durchführen wird (Benutzer‐Interaktion).
Es kann für einen Anwendungsfall mehrere Szenarien geben. Szenarien dienen dazu, den Anwendungsfall detailliert und aus verschiedenen Perspektiven zu betrachten. So wird verhindert, dass wichtige Funktionen des Systems übersehen werden.
Aus den Szenarien können auch direkt die Test‐Fälle für diesen Use Case abgeleitet werden.
37
Use-Case SzenarienJohn möchte das Buch „Under the Bridge“ in der
Bibliothek ausleihen
Actor Precondition Post condition Result
Librarian Mary
Mary is logged in“Under the bridge" has state "ok".
Book has state "borrowed", Mary lends book to John.
success
Librarian Mary
Mary is logged in, John is no customer
Navigate to "Create new customer account".
detour
Librarian Mary
Mary is logged in, "Under the bridge" has state "borrowed".
Error message: Book can not be borrowed.
fail
Librarian Mary
Mary is not logged inError message: User is not logged in.
fail
38
Beispiel: Banken Applikation
Requirements(1)Eine Person wird Kunde, sobald der Bankangestellte
für sie ein Konto eröffnet hat. Für jeden neuen Kunden erfasst der Angestellte
dessen Name, Geburtstag, Adresse und das Datum der ersten Kontoeröffnung. Bei der Eröffnung des ersten Kontos werden darauf automatisch 10 CHF gut geschrieben.
Es gibt Privat-, Spar-, Festgeld-, … Konten. Jedes Konto hat eine eindeutige Kontonummer. Privatkonten dürfen bis zu einem festen Betrag überzogen werden. Für jeden Kontotyp wird ein Habenzins, für Privatkonten auch ein Sollzins festgelegt.
39
Beispiel: Banken Applikation
Requirements(2)Ein Kunde kann beliebig viele Konten haben,
Beträge einzahlen, abheben oder überweisen. Es werden Zinsen gutgeschrieben und bei
Privatkonten Überziehungszinsen abgebucht. Um die Zinsen zu berechnen, muss für jede Kontobewegung das Datum und der Betrag notiert werden. Die Gutschrift/Abzug der Zinsen erfolgt bei den Sparkonten jährlich und bei den Privatkonten quartalsweise.
Ein Kunde kann jedes seiner Konten wieder auflösen. Bei der Auflösung des letzten Kontos hört er auf, Kunde zu sein.
40
Banken Applikation: Mind-Map
41
Banken Applikation: Use Cases
42
3. Klassenstruktur
Klassendiagramme, Strukturelemente
Vgl. Oestereich Kap 2.2 Seiten 50‐74
43
Definition
Ein Klassenmodell zeigt die statische Struktur des Systemsbeschreibt, welche Klassen existierenin welchen Beziehungen diese Klassen zueinander stehen
Ein Klassenmodell beschreibt die statische Struktur eines Systems. Es besteht aus Klassen mit Attributen und Operationen, die zueinander auf verschiedene Arten in Beziehung stehen können. Das Klassenmodell wird durch ein oder durch mehrere Klassendiagramme beschrieben, welche diese Klassen und ihre Beziehungen zueinander darstellen.
44
Klassendiagramm
Ist ein UML Strukturdiagramm zur graphischen Darstellung eines Klassenmodells
deren Klassendie benötigten Schnittstellendie Beziehungen untereinander
Zusätzlich erhält jede Klasse eine kurze Beschreibung (20‐30 Wörter), welche den Sinn (den Aufgabenbereich) der Klasse beschreibt.
45
Verwendung
Das Klassendiagrammstellt die statische Struktur eines Systems dar wird zum Beispiel zum Darstellen von Geschäfts-oder Fachklassen verwendetbildet die Struktur eines Lösungskonzepts abkann in allen Phasen der Software Entwicklung eingesetzt werden
Klassendiagramme können als generelles, konzeptuelles Modell der Applikation verwendet werden. In einer späteren Phase können sie aber auch für die detaillierte Modellierung zum konkreten Erzeugen von Programmcode benutzt werden.
Das Grob‐Klassendiagramm enthält nur die Klassen (ohne Attribute und Operationen) und die Beziehungen dazwischen.
Statt von Geschäfts‐ oder Fachklassen spricht man oft auch von Domänen Modell (Domain Model / Business Model).
46
Klasse
Eine Klasse beschreibt die Struktur und das Verhalten der Objekte, welche aus ihr erzeugt werden können.Die Klasse hat einen Namen und besteht aus Attributen und Operationen.Klassen werden durch Rechtecke dargestellt
Eine Klasse ist ein Datentyp, d.h. die Beschreibung gleichartiger Objekte. Gleichartig heisst dabei, die Objekte haben die gleichen Attribute und Methoden (Objekte können aber verschiedene Zustände haben). Diese Objekte werden von der entsprechenden Klasse erzeugt (instanziiert).
Zusätzlich kann eine Klasse (bzw. ihre Attribute und Operationen) auch Zusicherungen(Bedingungen, Regeln), Merkmale (z.B. private, abstract, …) oder Stereotypen(<<create>>, <<instantiate>>, <<delete>>, …) enthalten.
Im obersten Teil stehen zuerst allfällige Klassen‐Stereotypen (<<interface>>, <<enum>>, … ) und darunter der Klassenname (ev. inklusive dem Paketnamen). Namen von Klassen beginnen normalerweise mit Grossbuchstaben. Die Namen von abstrakten Klassen (z. B. Person ) werden kursiv geschrieben.
Im zweiten Teil stehen die Attribute der Klasse mit ihrem Namen, ihrem Typ, der Sichtbarkeit (siehe Folien 51 und 52).
Im dritten Teil stehen dann die Operationen der Klasse mit ihrem Namen, ihren Parametern, der Sichtbarkeit.
Zusicherungen an Klassen können durch Notizenfelder an die Klasse notiert werden.
47
Verantwortlichkeit
Jede Klasse hat eine Aufgabe, einen Zweck oder eine Verantwortlichkeit
Bevor eine Klasse modelliert wird ist es sinnvoll, die Verantwortlichkeit der Klasse zu definieren.
Eine Klasse sollte möglichst nur für einen(!) fachlichen Zusammenhang verantwortlich sein. Andernfalls entstehen viele Abhängigkeiten und ein instabiles Design. Klassen, für welche der Zweck nicht mit wenigen Worten (20‐30) erklärbar ist, sind oft ein Hinweis für einen fehlerhaften Design.
48
Objekt
Ein Objekt ist ein Exemplar (eine Instanz) einer Klassealso eine im laufenden System konkret vorhandene Einheitwird durch ein Rechteck dargestelltenthält keine Operationen
Ein Objekt ist ein konkretes Exemplar einer Klasse (hier ein konkreter Customer mit Namen Peter Muster). Ein Objekt hat immer einen aktuellen Zustand. Dieser besteht aus der Belegung der Attribute durch konkrete Werte.
Die Operationen gehören zur Klasse, werden darum im Objekt nicht aufgeführt.
49
Abstrakte Klasse
Eine abstrakte Klasse wird wie eine normale Klasse dargestellt, ausser dass der Klassenname kursiv gesetzt wird.Abstrakte Klassen können selber bereits Operationen und Attribute enthalten, welche dann an die abgeleiteten Klassen vererbt werden.
Aus abstrakten Klassen können keine Objekte erzeugt werden. Alle Objekte sind Instanzen von den konkreten (daraus abgeleiteten) Klassen.
Statt des kursiven Klassennamens kann der Klassennamen auch mit {abstract} ergänzt werden.
Oft enthalten abstrakte Klassen „leere“ Operationsdefinitionen, welche dann in den abgeleiteten Klassen realisiert werden müssen.
50
Parametrisierbare Klasse
Eine parametrisierbare Klasse ist eine Art Schablone/Template, mit welcher echte (nicht-generische) Klassen erzeugt werden könnenDurch die Angabe der konkreten Parameterwerte (Binding) entstehen dann die daraus hergeleiteten Klassen
In Java ist dieses Konstrukt unter dem Begriff „Generics“ bekannt. Beispiele von parametrieserbaren Klassen sind Arrays, Listen, Maps, Hashtables, Trees, Sets, Queues, …
Das Konstrukt der Parametrisierbaren Klassen darf nicht mit der Vererbung (Ableitung) verwechselt werden!
51
Attribut
Jedes Attribut hateinen Nameneinen Typ (int, String, Account, …)eine Sichtbarkeitsangabe +public, #protected, -private, ~package
ev. Zusicherungen z.B. eingeschränkter Wertebereich
Klassenattribute gehören allen Objekten dieser Klasse gemeinsam
Attribut‐Namen beginnen eher mit Kleinbuchstaben.In C# oder Java werden Klassenattribute als „static“ Attribute bezeichnet.
public static float interestRate;Abgeleitete oder berechnete Attribute werden im Objekt nicht physisch realisiert, sondern bei Bedarf automatisch berechnet. Sie werden durch einen Schrägstrich /abgelAttribut bezeichnet. Das Konstrukt der abgeleiteten Attribute ist eigentlich überflüssig, da diese sowieso durch eine Operation implementiert werden müssen.
52
Operation
Jede Operation hateinen Nameneine Signatur Argumente und Rückgabewert
eine Sichtbarkeitsangabe +public, #protected, -private, ~package
Operationen können mehrfach definiert (überladen) sein.
Statische Operationen sind globale Prozeduren und damit unabhängig vom Objekt, welches sie aufruft.
Operationen sind Dienstleistungen die von einem Objekt ausgeführt werden können. Sie werden auch Methoden, Services, Prozeduren, Funktionen oder Nachrichten genannt.
Die Argumente (Operations‐Parameter) können fehlen. Die Argumente können mit den Schlüsselwörtern in, out, und inout gekennzeichnet werden, abhängig davon, ob die Argumente nur gelesen, nur zurückgegeben oder gelesen und zurückgegeben werden.
Der Rückgabewert (Resultat, Ergebnis) kann ebenfalls fehlen (void‐Funktion).Der Name der Operation beginnt mit einem Kleinbuchstaben, ebenso die Namen der Argumente.
Operationen können (in abstrakten Klassen oder Interfaces) als {abstract} bezeichnet werden, um anzugeben, dass diese Operation hier nicht implementiert wird.
#printReport() : void {abstract} protected abstract void printReport();Statische Operationen werden als solche deklariert
+getTopBalance() : float public static float getTopBalance()Operationen können mehrfach definiert sein (überladen). Sie unterscheiden sich dann (nur) durch ihre Argumente. Der Typ des Rückgabewertes ist für alle der gleiche.
public boolean checkLimit(){ … }public boolean checkLimit( float amount ){ … }
Für Operationen können Zusicherungen (Bedingungen) definiert werden (z.B. amount > 0)
53
Interface
Ein Interface (Schnittstelle) definiert das (oder einen Teil des) extern sichtbare Verhalten einer Klasse oder Komponentedeklariert die nötigen Operationenwird mit dem Schlüsselwort «interface»gekennzeichnet
Ein Interface (eine Schnittstelle) ist eine Sammlung von Operations‐ (und ev Attribut‐)Definitionen, die eine kohärente Verhaltensweise definiert. Die im Interface deklarierten Operationen sind abstrakt.
Ein Interface wird durch eine Klasse oder eine Komponente realisiert. Dazu muss die realisierende Klasse (Komponente) alle Operationen des Interfaces implementieren. Die realisierende Klasse kann weitere Operationen und Attribute enthalten.
Jede Klasse oder Komponente kann ein oder mehrere Schnittstellen implementieren.Jedes Interface kann durch eine oder mehrere Klassen oder Komponenten realisiert werden.
Ein Interface definiert eine Art „Vertrag“, welche von allen realisierenden Klassen/Komponenten erfüllt werden muss.
54
Angebotenes/Benötigtes Interface
Ein angebotenes Interface wird durch eine Klasse oder Komponente realisiert und mit einem Kreis gezeichnet.
Ein benötigtes Interface ist für die Klasse oder Komponente erforderlich, um seine Funktion korrekt wahrzunehmen.
Die Klasse TemperaturSensor implementiert das Interface Sensor (also die darin verlangten Operationen).
Die Klasse AirCondition braucht einen Sensor, um richtig funktionieren können und benutzt dazu die angebotenen Dienste der Klasse TemperaturSensor.
Falls die Klasse TemperaturSensor weitere Dienste anbietet, werden diese von AirCondition nicht benutzt.
55
4. Beziehungen
Beziehungselemente in Struktur-Diagrammen
Vgl. Oestereich Kap 2.3 Seiten 75‐98
56
Definition
Eine Beziehung ist eine gegenseitige Verbindung.
Die drei wichtigsten Beziehungsarten in der objekt-orientierten Modellierung sindGeneralisierung (Vererbung)Assoziation (Aggregation, Komposition)Abhängigkeit («use», «call», «derive»,…)
57
Verwendung
Nachdem im Klassendiagramm die verschiedenen Typen (Klassen) definiert sind, ist der nächste Schritt die Beschreibung der Beziehungen dieser Klassen untereinander.
In allen Strukturdiagrammen stehen gewisse Klassen (Classifier) in Beziehung zueinander.
Die verschiedenen Beziehungselemente helfen dabei, die verschiedenen Arten von Beziehungen zu unterscheiden.
58
Generalisierung
Die Generalisierunggliedert Eigenschaften in einer hierarchischen Ordnung allgemeinere Basisklasse
spezialisierte abgeleitete Klasse
vererbt die Eigenschaften der Basisklasse an die abgeleitete Klasse
Generalisierung (Vererbung, Spezialisierung) ist ein Abstraktionsprinzip zur hierarchischen Strukturierung der Semantik eines Modells.
Die abgeleiteten Klassen (Unterklassen) erben alle Eigenschaften (Attribute, Operationen) der Basisklasse (Oberklasse). Diese werden aber im Diagramm in der abgeleiteten Klasse nicht wiederholt.
Die abgeleiteten Klassen können die Operationen der Basisklasse überschreiben oder erweitern (spezialisieren), aber nicht eliminieren oder unterdrücken.
In UML ist auch die Mehrfachvererbung vorgesehen. Diese wird allerdings in einigen modernen Sprachen nicht unterstützt und schafft viele Probleme.
Generalisierung gibt es auch unter Interfaces (Schnittstellen), wenn ein Interface eine Spezialisierung eines anderen Interfaces ist (z.B. das Java List Interface ist abgeleitet vom Collection Interface und dieses wiederum vom Iterable Interface).
59
Verwendung der Generalisierung
Subtyp-Vererbung
Vererbung zur Erweiterung
Vererbung zur Unterstützung allgemeiner Fähigkeiten
Vererbung von Standardimplementierungen
Subtyp‐Vererbung: Bei dieser ist die abgeleitete Klasse ein Subtyp der Basisklasse im Sinne eines abstrakten Datentyps: der Wertebereich der abgeleiteten Klasse ist eine Teilmenge des Wertebereichs der Basisklasse (mit ev. zusätzlichen Operationen).
Vererbung zur Erweiterung: Die abgeleitete Klasse wird mit zusätzlicher Funktionalität oder zusätzlichen Attribute gegenüber der Basisklasse ergänzt. Dies kann auch durch Überschreiben von Methoden geschehen, um beispielsweise Funktionalität zu ergänzen, die in der Basisklasse nicht relevant ist.
Vererbung zur Unterstützung allgemeiner Fähigkeiten: Bei dieser Variante geht es darum, gewisse Basisfunktionalität zu etablieren. Eine Basisfunktionalität wie Serialisierbarkeit oder Vergleichbarkeit wird dabei durch eine abstrakte Klasse (oder Schnittstelle) deklariert – typische Beispiele sind Serializable oder Comparable.
Vererbung von Standardimplementierungen: Allgemeine für mehrere Typen verwendbare Funktionalität wird dabei in einer zentralen Klasse implementiert. Diese Variante dient dazu, allgemeine Programmteile wieder verwenden zu können.
60
Assoziation
Eine Assoziation beschreibt eine Beziehung oder Verbindung zwischen zwei (verschiedenen) Klassenermöglicht, dass zwei Objekte miteinander kommunizieren könnenkann mit einem Namen versehen werden, welche die Beziehung beschreibt
Assoziationen sind nötig, damit zwei Objekte miteinander kommunizieren können „sie müssen voneinander wissen, sich kennen“.
Die konkrete Ausprägung davon wird Objekt‐Link oder Objekt‐Verbindung genannt.Assoziationen sind normalerweise Verbindungen zwischen zwei Objekten von verschiedenen Klassen, eine Assoziation kann aber auchObjekte vom gleichen Typ verbinden (rekursive Assoziation).
Assoziationen werden dadurch realisiert, dass die beteiligten Klassen entsprechende Referenz‐Attribute enthalten:
class Customer{ class PrivateAccount {private Name name; private Customer customer;private Address address; private float balance; private PrivateAccount account; ... . . . }
}
61
Multiplizität
Assoziationen können mit einer Multiplizität versehen werden, welche angibt mit wie vielen Objekten der gegenüberliegenden Klasse ein Objekt assoziiert werden kann.
Ausserdem kann ein Rollenname und dessen Sichtbarkeit angegeben werden
Bsp: Ein Customer hat ein oder mehrere PrivateAccounts
Multiplizitäten1 genau eins0..1 null oder eins0..3 von null bis drei0..* beliebig viele (auch null)* beliebig viele (auch null) Defaultwert, wenn Angabe fehlt1..* eins oder mehrere
Die Realisierung von * Multiplizitäten erfolgt über eine Collection (List, Array,…)class Customer{
private Name name;private Address address;private List<PrivateAccount> accounts; . . .
}
62
Gerichtete Assoziation
Eine gerichtete Assoziation ist eine Beziehung, die nur in eine Richtung navigierbar ist.
Sie wird durch eine offen Pfeilspitze, welche die zugelassene Navigationsrichtung angibt, dargestellt.
Der Customer kennt also seine Accounts, der Account kennt aber nicht seinen Besitzer.
Falls der Navigationsausschluss fehlt, ist nicht bestimmt, ob der Account seinen Besitzer kennt oder nicht.
Bidirektionale Assoziationen sind genau genommen zwei inverse Assoziationen.
Assoziationen sind also nicht dasselbe wir relationale Beziehungen in ER Diagrammen, und dürfen damit nicht verwechselt werden.
63
Aggregation
Eine Aggregation ist eine Assoziation, deren beteiligte Klassen in einer Ganzes-Teile-Hierarchie stehenbeschreibt wie sich etwas Ganzes aus seinen Teilen (logisch) zusammensetzt besteht aus einem Aggregat und den Einzelteilenist normalerweise eine 1 zu n Beziehung
Ein Teil kann zu mehreren Aggregaten gehören (Employee kann mehreren Departments angehören).
Ausserdem kann das Aggregat selber wieder Teil eines Ganzen (zum Beispiel einer Firma) sein.
Aggregationen und Assoziationen sind oft schwer zu unterscheiden. Der resultierende Programmcode ist (oft) der gleiche. Falls man sich nicht sicher ist, wählt man darum im Zweifelsfall eine Assoziation.
64
Komposition
Eine Komposition ist eine Aggregation, bei welcher die Teile vom Ganzen existenzabhängig sindbeschreibt, wie sich das Ganze aus den Einzelteilen zusammensetztist eine 0..1 zu n Bedingungerfüllt ansonsten die gleichen Bedingungen wie die Assoziation
Die Lebenszeit der Teile ist abhängig von der Lebenszeit des Ganzen: Wenn die Firma (Company) aufgelöst wird, werden auch die einzelnen Filialen (BranchOffice) geschlossen.
Die Kardinalität beim Aggregat ist immer 0 oder 1, d.h. jedes Teil kann nur einem Aggregat zugehören.
Ein anderes typisches Beispiel einer Komposition ist eine Rechnung (oder Bestellung) mit ihren einzelnen Positionen. Sobald die Rechnung gelöscht wird, werden auch die einzelnen Positionen sinnlos. Die Rechnung übernimmt bestimmte Aufgaben für das Ganze, wie zum Beispiel das Berechnen der Gesamt‐Summe oder der Anzahl Positionen.
65
Abhängigkeit
Eine Abhängigkeitist eine Beziehung von einem oder mehreren Quellelementen zu einem oder mehreren Zielelementen
Typische Arten der Abhängigkeit sindcall, create, derive, realize, permit, use,…
abhängig unabhängig
Die Abhängigkeit ist dadurch gegeben, dass das das Zielelement (unabhängiges Element) für die Spezifikation oder die Implementation des Quellelements (abhängiges Element) erforderlich ist.
Beispiele von Abhängigkeiten sind:«call» Eine Operation des unabhängigen Elements wird vom abhängigen Element
aufgerufen.«create» Das unabhängige Element wird vom abhängigen Element erzeugt.«derive» Das abhängige Element ist vom unabhängigen Element abgeleitet.«permit» Das abhängige Element hat die Erlaubnis, private Eigenschaften des
unabhängigen Elementes zu verwenden.«realize» Das abhängige Element implementiert das unabhängige Element.«use» Das abhängige Element benutzt das unabhängige Element (zum Beispiel als
Parameter in einem Operationsaufruf).
Abhängigkeiten gibt es zwischen Paketen (ein Paket benutzt Klassen von einem anderen Paket), zwischen verschiedenen Klassen oder zwischen Operationen und Klassen (die Klasse wird als Operationsparameter benutzt).
66
Finden der Klassen
Objektorientierte Synthese André-Claude Godet
Beispiel: Banken Applikation
Die Idee der Objekt Orientierten Synthese stammt aus dem OOAD Skript von André‐Claude Godet.
67
Vorgehensweise
Kandidaten für
Fachklassen -> Substantive -> gelb
Attribute -> Substantive -> rot
Operationen -> Verben -> blau
Multiplizitäten -> Mengen-Angaben -> grün
Beziehungen -> Örtliche Nachbarschaft (zum Beispiel im gleichen Satz)
Um (erste) Klassen, Attribute und Operationen für das Fachklassendiagramm zu finden, kann man das Pflichtenheft systematisch analysieren. Dabei sucht man alle Substantive, Verben und Mengenangaben und streicht diese farbig an.
68
Kandidaten für Fachklassen
Als erstes streichen wir alle Substantive gelb an. Dies sind erste, provisorische Kandidaten für Fachklassen.
69
Kandidaten für Attribute
Beim Überprüfen der Substantive versuchen wir zu entscheiden, welche davon eher Attribute statt Fachklassen sind. Als Attribute kommen diejenigen Objekte in Frage, welche einen einfachen Aufbau haben (Datum, Kontonummer, …) oder nur einmal vorhanden sind (Name, Geburtsdatum, Zins, …).
Weiter unterstreichen wir diejenigen Substantive, welche eventuell als Klasse/Attribut im System nicht notwendigerweise vorhanden sein müssen.
70
Kandidaten für Operationen
Als drittes streichen wir aktive Verben blau an. Hilfsverben werden ebenfalls unterstrichen. Diese dienen eventuell später für das Erfassen eines Zustandsdiagramms oder zum Erkennen von Bedingungen.
71
Multiplizitäten
Die Multiplizitäten können wir aus den Mengenangaben erkennen. Jede Person hat einen Namen, ein Geburtsdatum, eine Adresse, beliebig viele Konten, …
72
Beziehungen
Gewisse (offensichtliche) Beziehungen können wir erkennen, wenn wir die Sätze untersuchen:
Kunde KontoKunde AdresseKontotyp Zinssätze Weitere Beziehungen sind in den Use Case Diagrammen zu finden
worauf/ womit operieren die Akteure?Alle korrekten (und nötigen) Beziehungen zu finden ist allerdings oft schwierig und oft erst am Ende der Design Phase möglich.
73
CRC Cards
Superclass Account SubclassesResponsibilities Collaborations check Limit ? get Balance Transactions
PrivateAccount
Description
AttributesNumberCustomerTransactions
PrivateAccount
An account type, which can be used for ...
Vorderseite
Rückseite
CRC Karten (Class, Responsibilities and Collaborations Cards) können dazu dienen, eine erste Grobskizze der Fachklassen mit deren Attributen und (public) Operationen zu erstellen.
Weitere (private) Operationen kommen oft im späteren Verlauf des Designs dazu.Collaborations zeigen erste Beziehungen zu anderen Klassen auf.
74
CRC Cards
Superclass PersonSubclassesResponsibilities Collaborations get Assets Accounts . . .
Customer
Description
AttributesNameAddressAccount List
Customer
A customer of a bank.
Vorderseite
Rückseite
75
Fachklassen Diagramm
Ein erster Entwurf
76
Checkliste
Statisches OOA ModellKlassen und Assoziationen
77
Klassendiagramm
In einem ersten Entwurf hat jede Klasse entweder nur einen Namen oder wenige wichtige Attribute mit deren Typ und die wichtigsten Operationen mit deren Sichtbarkeiteine Kurzbeschreibung von 25 oder weniger Wörternihre (vermutlichen) Beziehungen (Assoziationen) durch eine Verbindungslinie zu den anderen Klassen eingetragen
78
Klassen finden
Mögliche Klassen sindPersonen und deren RollenKonkrete Objekte, Dinge, InformationenInformationen über Aktionen (Commands)Orte, Zeitangaben, …Organisationen (Firma, Verein, Schule, …)Ereignisse (was, wer, wann, wo, …)Kataloge, Listen, Bestellungen
79
Analyse: Klassen
Mögliche Fehler:Klassen, die bloss eine Menge von Objekten verwaltenZu viele, zu kleine KlassenKlasse, welche die Benutzeroberfläche modelliert Klasse, die Entwurfs- oder Implementierungsdetails modelliert Klasse, die elementar und keine Architektur- oder Fachklasse ist (Datum, Name, Preis, …)
Im Klassendiagramm muss geprüft werden, ob wirklich alle Klassen wichtige/eigenständige Klassen sind.
80
Analyse: Klassenname
Der Klassenname sollder Fachterminologie entsprechenein Substantiv im Singular seinso präzise wie möglich gewählt werdendasselbe ausdrücken wie die Gesamtheit der Attributenicht die Rolle dieser Klasse in einer Beziehung zu einer anderen Klasse beschreibeneindeutig im Paket bzw. im System sein und sich auch semantisch von allen Namen aller anderen Klassen unterscheiden
Gut gewählte Klassennamen helfen enorm, das System leichter zu verstehen. Die richtige Wahl der Klassennamen ist darum von grosser Bedeutung und sollte entsprechendes Gewicht bekommen.
Der Klassenname sollte darum ein Wort aus dem Problemgebiet sein (z. B. in Cargo Cruise: Buchung statt Bestellung, Kunde oder Reisender statt Person, Reise statt Ausflug, Route oder Teilstrecke statt Tour …)
81
Analyse: Attribute
Sind alle Attribute wirklich notwendig?Ist die Anzahl der Attribute pro Klasse angemessen?Sind die Typen / Sichtbarkeiten korrekt?Könnten einfache Attribute zu einer Datenstruktur zusammengefasst werden?
Müsste eine Gruppe von Attributen in eine eigene Klasse ausgelagert werden?Ist das Attribut ein Klassenattribut?
Es ist oft nicht einfach zu entscheiden, ob ein Attribut korrekt gewählt wurde, oder ob es in eine eigene Klasse ausgelagert werden müsste.
Eine Klasse beschreibt eine Objektidentität und hat eine den anderen Klassen gleichgewichtige Bedeutung im System. Die Existenz des Objektes ist unabhängig von der Existenz anderer Objekte, der Zugriff ist in der Umgebung des Objektes grundsätzlich in beide Richtungen denkbar.
Ein Attribut hat keine Objektidentität, seine Existenz ist abhängig von der Existenz anderer Objekte, der Zugriff geschieht immer über das Objekt. Attribute haben im System eine untergeordnete Bedeutung.
82
Analyse: Attribute
Unnötige AttributeEs beschreibt den internen Zustand eines Lebenszyklus und ist ausserhalb des Objekts nicht sichtbar.Es beschreibt Entwurfs- oder Implementierungs-Details.Es handelt sich um ein abgeleitetes (berechnetes) Attribut, das nur aus Performance-Gründen eingefügt wurde.Es definiert eine Assoziation.
Im Modell sollten nur Attribute aufgelistet werden, die fachlich relevant sind.
83
Analyse: Attributname
Der Attributname soll… kurz, eindeutig und im Kontext der Klasse verständlich sein… möglichst ein Substantiv sein (kein Verb)… den Namen der Klasse nicht wiederholen … bei komplexen (strukturierten) Attributen der Gesamtheit der Komponente (Information) entsprechen… nur fachspezifische oder allgemein übliche Abkürzungen enthalten
Attribute sollten, ähnlich wie Klassen, sprechende und der fachterminologie entsprechende Namen haben. Dies erleichtert sehr das Verständnis für den Sinn dieses Attributes.
Es sollten darum auch möglichst keine Abkürzungen verwendet werden.Das Wiederholen des Klassennamens ist unnötig und sollte darum vermieden werden.Namen von strukturierten Attributen sollten das Ganze beschreiben (z.B. adresse ‐> strasse/nr/plz/ort/land).
84
Analyse: Operationen
Die Operationen findet man in der Spezifikation und den Szenarien. Falls nötig werden Listen-Operationen (Suche, Auswahl, …) hinzugefügt.
Operationen werden in der Vererbungshierarchie so hoch wie möglich eingetragenDie Operation muss einen geeigneten Namen haben, welcher beschreibt, was die Operation tut (Verb)Verwaltungsoperationen (new, delete, get/set…, link, unlink,…) werden nicht im Modell eingetragen
Falls das Klassendiagramm sehr komplex ist, werden auch Methoden wie update, read, print, … nicht ins Klassendiagramm eingetragen.
Falls aus dem Namen der Operation nicht eindeutig klar ist, was sie tut, sind ev. Aktivitäten‐oder Sequenzdiagramme zur Beschreibung nötig. Eine textuelle Beschreibung ist für komplexe Operationen nicht geeignet.
85
Beziehungen
Eine Assoziation zwischen A und B besteht, falls… A ein physischer oder logischer Teil von B ist… A eine Beschreibung für B ist… A ein Mitglied von B ist… A eine organisatorische Einheit von B ist… A ein B benutzt… A mit B kommuniziert … A ein B besitzt…
Eine Assoziation zwischen zwei Klassen A und B liegt vor, wenn diese in irgend einer Form von direkter Beziehung stehen.
Beziehungen findet man in der Spezifikation, den Beschreibungen der Geschäftsprozessen oder (falls bereits ein DB‐Modell vorliegt) anhand der Fremdschlüssel.
86
Eins zu eins (1:1) Assoziation
Klassen verschmelzen?
Zwei Klassen sind nötig, fallsdie Verbindung in eine oder beide Richtungen optional istsich die Verbindung zwischen beiden Objekten ändern kannes sich um zwei umfangreiche Klassen handeltdie beiden Klassen eine unterschiedliche Semantik besitzen.
1:1 Assoziationen sind mögliche Kandidaten für Klassen‐Verschmelzungen.Beispiel: Person Name.Jede Person hat einen Namen, jeder Name gehört genau zu einer Person. Da ist es ev. sinnvoll, Name nicht als eigene Klasse zu führen (ausser die Klasse ist sehr umfangreich, d.h. viele Attribute oder eigene funktionale Operationen).
87
Analyse: Assoziation
Eine Benennung der Beziehung kann sinnvoll oder sogar notwendig sein.Sie ist notwendig, wenn zwischen zwei Klassen mehrere Assoziationen bestehen.Bei reflexiven Assoziationen ist immer ein Rollenname notwendig.
Oft ist es sinnvoll, einer Assoziation einen Namen (eine Rolle) zuzuordnen, welche die Beziehung erklärt. Zum Beispiel dann, wenn die Art der Beziehung nicht offensichtlich ist.
Das Benennen der Beziehung kann auch dazu beitragen, zu erkenne, ob die Assoziation korrekt und nötig ist.
Rollennamen für Assoziationen sind besser als ein Attributname oder ein Verb.
88
Analyse: Multiplizitäten
Aus den Anforderungen an das System ergibt sich, ob ein Schnappschuss (1 bzw. 0..1-Kardinalität) oder die Historie (0..n-Kardinalität) zu modellieren ist.
Eine 1, bzw. 0..1 Beziehung liegt vor, wenn nur der aktuelle Zustand dargestellt werden muss.
Many‐Kardinalitäten sind erforderlich, falls Listen von Objekten zu verwalten sind (mehrere Adressen, Konti, Bestell‐Positionen, …) oder falls eine History (vgl. Beispiel) vorliegt.
89
Analyse: Kann / Muss Assoziation
Die Muss-Beziehung verlangt, dass für jeden neuen Kunden sofort eine Adresse erzeugt werden muss. Der Kunde kann einen Account haben.
Falsche Muss-Beziehungen führen zu unnötigen Einschränkungen.
Kann‐Assoziation Untergrenze 0Muss‐Assoziation Untergrenze 1
Falls eine 1:1 Beziehung besteht, müssen die beiden Objekte auch gleichzeitig wieder gelöscht werden.
Im Modell ist sicherzustellen, ob tatsächlich eine Muss‐Beziehung besteht oder ob es sich um eine Kann‐Beziehung handelt. Andernfalls entstehen unnötige Einschränkungen oder Aufwände.
Kompositionen sind meistens Muss‐Beziehungen.
90
5.1 Objekte
Ausprägungsspezifikation von Klassen und Assoziationen
Vgl. Oestereich Kap 2.41 Seiten 99ff
91
Definition
Das Objektdiagramm zeigt eine bestimmte Sicht auf die Struktur des modellierten Systems.
Die Darstellung umfasst dabei typischerweise Ausprägungsspezifikationen von Klassen und Assoziationen.
Das Objektdiagramm ist eine Art Schnappschuss. Es zeigt den Zustand, also die Belegung der Attribute eines Objektes zu einem bestimmten Zeitpunkt.
Das Objektdiagramm ist ebenfalls ein Strukturdiagramm.Da die Anzahl der Attribute sehr groß sein kann, wird man normalerweise nur diejenigen Attribute auflisten, welche für den Zweck, den man verdeutlichen möchte, ausreichen.
92
Verwendung
Das Objektdiagramm wird nicht so oft verwendet. Es eignet sich dazu, beispielhaft ein zur Laufzeit existierendes Objektnetz mit sein Attributwerten zu visualisieren.
Es kann zum Beispiel dazu benutzt werden, das Klassendiagramm und dessen Beziehungen zu verifizieren.
93
Beispiel: Bank
Der Aufbau des Objektdiagramms ist ähnlich wie beim Klassendiagramm, nur dass im obersten Kasten nicht der Klassenname steht, sondern Instanzname : Typ und zwar unterstrichen. Der Instanzname ist optional und kann bei nicht benannten (anonymen) Objekten weggelassen werden. Ausserdem fehlen die Operationen. Diese gehören zu der Klasse, nicht zum Objekt.
In Use‐Case‐, Sequenz‐ oder Kommunikationsdiagrammen werden Rollen und keine Objekte gezeichnet.
94
Beispiel: Firma
Rekursive Assoziationen lösen sich im Objektdiagramm auf.Ausserdem können Objekte in der Hierarchie mehrfach verbunden sein (z.B. der Angestellte Rolf, der zwei Chefs hat).
95
5.2 Komponenten
Komponenten-Diagramm
Vgl. Oestereich Kap 2.4.2 Seiten 100ff
96
Definition
Eine Komponente …ist ein modulares (in sich abgeschlossenes) Teil eines Systems. ist so strukturiert, dass sie in ihrer Umgebung einfach durch eine andere, äquivalente Komponente ersetzt werden könnte.kann als eine spezielle Klasse mit Attributen, Operationen, Beziehungen, … gesehen werden.lebt/läuft normalerweise in einer Umgebung (einem Container).
Man spricht oft auch von Softwarekomponenten. Komponenten sind eine Spezialisierung von Klassen. Sie können deshalb Strukturmerkmale wie Attribute oder Operationen haben, an Generalisierungen teilnehmen und über Assoziationen mit anderen Komponenten in Beziehung gesetzt werden.
Im Gegensatz zu einer Klasse ist eine Komponente als Modul abgeschlossen und bietet gegen aussen wohldefinierte Schnittstellen (Interfaces) an. Oft besteht eine Komponente aus mehreren Klassen oder anderen Komponenten.
Je nach Blickpunkt gibt es zwei unterschiedliche Sichten auf eine Komponente: eine Black‐Box‐Sicht, die nur den Rand (Schnittstelle, angebotene Dienste) zeigt, und eine White‐Box‐Sicht, die auch die innere Struktur der Komponente zeigt.
97
Verwendung
Das Komponentendiagramm wird vor allem für die Modellierung von komponentenbasierten Softwaresystemen wie zum Beispiel EJB, DCOM, Corba, … eingesetzt.
Falls bei einem System die Austauschbarkeit der Klassen sehr wichtig ist, können auch „normale“Klassen als Komponenten definiert werden.
Um das Innere einer Komponente darzustellen, zeigt ein Komponentendiagramm oft Notationselemente, die sonst vor allem in Klassen‐ oder Kompositionsstrukturdiagrammen angezeigt werden, zum Beispiel Klassen oder Parts.
Die Black‐Box Sicht einer Komponente wird ähnlich wie eine Klasse als Rechteck mit einem Namen gezeichnet. Das Schlüsselwort «component» sowie ein Symbol in der rechten oberen Ecke unterscheiden die Notation einer Komponente von jener einer Klasse.
98
Black-Box-Sicht
Eine Komponente wird ähnlich wie eine Klasse als Rechteck mit einem Namen gezeichnet. Zusätzlich ist das Schlüsselwort «component»sowie optional ein Symbol eingefügt
«component»JTextArea
Scrollable
ImageObserverEventListener
Beispiel einer Komponente mit drei angebotenen und einer benötigten SchnittstelleDie Black‐Box‐Sicht einer Komponente zeigt die Schnittstellen, die die Komponente gegen aussen anbietet bzw. die sie von anderen Komponenten beziehen muss. Das Beispiel hier zeigt die angebotenen Schnittstellen als Lollipops (Scrollable, ImageObserver) und die benötigten als Socket (EventListener).
99
White-Box-Sicht
Eine Komponente wird ähnlich wie eine Klasse als Rechteck mit einem Namen gezeichnet. Zusätzlich ist das Schlüsselwort «component»sowie optional ein Symbol eingefügt
«component»JTextArea
View UI
DocumentModel
Transfer-Handler
Die White‐Box‐Sicht zeigt die innere Struktur der Komponente. Die Komponente JTextArea könnte zum Beispiel aus den Klassen View (für das User Interface), Document (für das Speichern der Daten) sowie aus einer Klasse TransferHandler (für das Verarbeiten von Drag und Drop) bestehen.
100
Komponenten Diagramm
Das Komponenten Diagramm zeigt die verschiedenen Komponenten und deren Schnittstellen.
Scrollable
EventListener Image
Observer
«component»JScrollPane
«component»KeyEventHandler
«component»Graphics
«component»JTextArea
Das Komponentendiagramm ist ebenfalls ein Strukturdiagramm.
101
5.3 Pakete
Paket Diagramm
Vgl. Oestereich Kap 2.5 Seiten 112‐126
102
Definition
Ein Paket …fasst Klassen, Interfaces, Komponenten, …zusammenbildet einen Namespacekann Unterpakete enthaltenkann andere Pakete importieren (benutzen)kann benutzt werden, um eine hierarchische Struktur zu bilden
Ein Paket fasst eine Menge von Modellelementen (Klassen, Komponenten, Interfaces, …) zu einer Gruppe zusammen und bildet einen Namensraum (Namespace) für sie. Die Elemente innerhalb eines Paketes müssen eindeutige (verschiedene) Namen haben.
Pakete können andere Pakete als Unterpakete enthalten. Sie gliedern die Modellelemente hierarchisch in eine Struktur, analog zu einem Dateisystem (Directory).
Jede Klasse, Interface, … gehört jeweils nur zu einem Paket.Oft wird statt Paket auch der Name Subsystem oder Kategorie verwendet.
103
Verwendung
Ein komplexes Gesamtsystem sollte möglichst früh in Pakete (Subsysteme) unterteilt werden
Reduktion der Komplexität
Gruppen von Use Cases (Funktionsgruppen) …Klassen, die fachlich zusammengehören (Produkte-Gruppe, Personen-Typen, usw.) …Klassen, die stark interagieren oder zur gleichen Schicht (Layer) gehören, …Klassen, welche ähnliche Funktionalität haben (Controller, DB-Zugriff, usw.) …
… können in Paketen zusammengefasst werden.
Auch die Pakete sollten einfache, beschreibende Namen haben, welche den Sinn des Pakets klar machen.
104
Paket Diagramm
Der Name wird entweder in das Paket oder auf den Reiter geschrieben.
Der vollständig qualifizierte Klassenname ist dann der Klassenname ergänzt um den Namen des Pakets.
Falls die Internas des Pakets aufgezeichnet werden, bietet es sich an, den Paketnamen auf den Reiter zu schreiben.
Auch die Pakete sollten (kurz) Dokumentiert werden (Kurzbeschreibung, 20‐30 Wörter).
105
Checkliste
Lassen sich die Klassen eines Pakets kategorisieren (positive Gruppenbeschreibung)?Bilden die Pakete eine abgeschlossene Einheit, z.B. zu einen Themenbereich?Liegen alle Aggregationen und Kompositionen im selben Paket?Erlauben die Pakete eine Betrachtung des Systems auf einer höheren Abstraktionsebene?Ist der Paketname selbsterklärend?Ist die Anzahl Klassen im Paket angemessen?Liegen Klassen mit intensiver Kommunikation im gleichen Paket?
Eine positive Beschreibung führt zu einem klaren Gruppennamen.Eine negative Kategorisierung ist von der Art: „alles, was nicht zu … gehört“. Dies führt zu keinem geeigneten Paket (‐namen).
106
6. Aktivitäten
Beschreibung von Abläufen,Aktionen und Kontrollflüssen
Vgl. Oestereich Kap 2.5 Seiten 112‐126
107
Definition
Eine Aktivität modelliert das Verhalten eines Systems. Sie beschreibt, wie elementare Aktionen mit Hilfe von Kontroll- und Datenflüssen zu komplexen Abläufen kombiniert werden.
Zum Darstellen einer Aktivität dient ein Aktivitätsdiagramm. Es ordnet Aktionen als elementare Verhaltensbausteine in einem Netzwerk aus Knoten und Pfeilen an.
108
Verwendung
Es bietet sich darum an, für solche Zwecke ein Aktivitätsdiagramm zu zeichnen.
Umgangssprachlich ist es oft sehr schwierig, komplexere Vorgänge verständlich zu erklären.
Aktivitätsdiagramme erlauben es, sehr komplexe Abläufe mit Ausnahmen, verschiedenen Varianten, Sprüngen und Wiederholungen einfach darzustellen.
109
Aktivitätsknoten
Es gibt drei Typen von Aktivitätsknoten:
Aktionen sind die elementaren VerhaltensbausteineObjektknoten sind Hilfsknoten, die verwendet werden, um den Fluss von Objekten durch das Netzwerk zu spezifizierenKontrollknoten steuern den Kontroll- oder Objektfluss in einer Aktivität
Aktionen
Eine Aktion ist ein abstraktes Modellelement, das einen elementaren Baustein für die Spezifikation des Verhaltens eines Systems repräsentiert. Eine Aktion kann ein Operationsaufruf sein oder das Empfangen eines Signals, sie kann Objekte oder Objekt‐Beziehungen manipulieren, usw.
Eine Aktion erhält Eingabewerte über Eingabepins und produziert Ausgabewerte an Ausgabepins. An den Ein‐ und Ausgabepins kann eine Aktion mit anderen Aktionen kombiniert werden, so dass die Werte an den Ausgabepins zu den Eingabewerten der folgenden Aktion(en) werden.
Eine Aktion wird gestartet, sobald alle Eingänge bereit sind (alle Kontrollflüsse, Parameter vorliegen). Sie wird beendet wenn alle ausgehenden Kontrollflüsse bereit gestellt sind. Alle Ausgänge werden gleichzeitig ausgelöst.
Es gibt verschiedene Arten von Kontrollknoten: Startknoten (start), Endknoten (end), Parallelisierungsknoten (fork), Synchronisationsknoten (join) und Verzweigungsknoten (merge).
110
Aktionen/Unteraktionen
Einzelne Aktionen können weiter aufgeschlüsselt werden
Diese Aktion kann dann als gesamtes in ein anderes Diagramm eingesetzt werden
Eine Aktion ist entweder eine elementare (atomare, nicht unterbrechbare) Aktion oder sie besitzt weitere Unteraktionen. Sie kann also selber wieder verschachtelt sein und eine Aktivität enthalten. Solche Aktionen mit Unteraktionen werden durch ein kleines Gabelsymbol gekennzeichnet.
Aktionen haben normalerweise einen Eingang (eingehenden Kontrollfluss‐Pfeil) und einen Ausgang (ausgehenden Pfeil). Eine Aktion kann aber auch mehrere Ein‐ und Ausgänge haben.
In verschachtelten Aktionen (Aktionen mit Unteraktionen) werden die Parameter als Objektknoten auf den Rahmen der Aktion gelegt.
111
Objektknoten, Objektfluss
Objektknoten werden als eingehende oder als ausgehende Parameter einer Aktion verwendet.
Sie können auch als kleines Rechteck (Pin) an die Aktion geheftet werden.
Ein Objektknoten kann eine vorgegebene Anzahl Token (1..n) zwischenspeichern, bevor er sie an eine ausgehende Aktivitätskante weiterreicht. Die Objekte, die in einem Objektknoten zwischengespeichert sind, unterliegen einer bestimmten Ordnung, welche angibt, in welcher Reihenfolge die eintreffende Objekte den Objektknoten wieder verlassen. Übliche Ordnungen sind FIFO oder LIFO, ungeordnet ist aber ebenfalls möglich.
Der Objektfluss gibt an, dass die nachfolgende Aktion diese Parameter benötigt, bzw. dass die vorgehende Aktion diese Objekte erzeugt oder verändert hat.
Die Angabe eines Objekt‐Zustands (hier Request) ist optional.
112
Kontrollknoten
Es gibt verschiedene Arten von KontrollknotenStartknotenEndknotenAblaufende
Verzweigung (Entscheidung)Zusammenführung
TeilungSynchronisation
Der Startknoten ist der Startpunkt (Anfang) des Ablaufs, der Endknoten beendet den gesamten Ablauf (alle Aktionen und Kontrollflüsse).
Ein Ablaufende beendet einen einzelnen Objekt‐ oder Kontrollfluss.Eine Verzweigung hat mehrere Ausgänge. Die angegebenen Bedingungen (Guard) entscheiden, welche Flüsse fortgesetzt werden.
Die Zusammenführung ist eine Oder‐Verknüpfung. Jeder eingehende Objekt‐ oder Kontrollfluss führt sofort zum ausgehenden Kontrollfluss (keine Synchronisation!)
Eine Teilung (Splitting) teilt den Kontrollfluss (ohne Bedingung) in mehrere nebenläufige Kontrollflüsse auf.
Die Synchronisation ist eine Und‐Verknüpfung. Bevor weitergefahren werden darf, muss hier gewartet werden bis alle Objekt‐ und Kontrollflüsse eingegangen sind.
113
Aktivitätskanten
Aktivitätskanten werden folgendermassen eingeteilt:
Ein Kontrollfluss ist eine Aktivitätskante, über die kein Objekt-Parameter fliesst
Ein Objektfluss ist eine Aktivitätskante, über die Objekte von einem Knoten zum nächsten fliessen
Objektfluss
Ein Kontrollfluss verbindet Aktionen und Kontrollknoten. Kontrollflüsse transportieren keine Werte (Objekte), sondern nur ein Token um damit die nächste Aktion anzustossen.
Ein Kontrollfluss kann mit einer Guard ([unknown user], [wrong password], …) versehen werden, also einem booleschen Ausdruck, der ausgewertet wird sobald die produzierende Aktion dem Kontrollfluss ein Kontrolltoken anbietet. Das Kontrolltoken wird nur dann weitergereicht, wenn der boolsche Ausdruck zu wahr evaluiert.
114
Beispiel eines Aktivitätsdiagramms
Ein Aktivitätsdiagramm hat einen Startknoten und einen oder mehrere Endknoten. Der Startknoten hat nur ausgehende Pfeile, die Endknoten nur eingehende.
Der Ablauf wird durch die verschiedenen Knoten, welche durch Pfeile (Kontroll/Objektflüsse) verbunden sind, beschrieben.
Die Aktionsknoten bilden dabei den Hauptbestandteil des Diagramms. Kontrollknoten verzweigen den Kontrollfluss in mehrere Stränge (ev. mehrere Tokens), oder führen mehrere Stränge zusammen.
Mit den Objektknoten werden die Parameter einer Aktion angegeben.Jeder Endknoten führt zur sofortigen Beendigung aller Aktionen im gesamten Diagramm.
115
Partitionen
Partitionen (Verantwortlichkeiten, Swimlanes) beschreiben, wer jeweils für welche Aktion zuständig ist.
Aktivitätsdiagramme können in Partitionen unterteilt werden, mit denen die Knoten einem Verantwortungsbereich zugeordnet werden.
In was für Bereiche die Aktivität unterteilt wird, ist frei wählbar. Es kann damit zum Beispiel auch ausgedrückt werden, zu welcher Organisationseinheit oder zu welcher Komponente ein Knoten gehört.
116
Signale, Events
Während eines Ablaufs können Signale gesendet oder empfangen werden. Damit können nebenläufige Prozesse synchronisiert und auf äussere Ereignisse (Events) reagiert werden.
Zeitereignis empfangen(Timer)
Das Symbol für das Zeitereignis soll eine Sanduhr darstellen. Es kann bedeuten dass der Ablauf an einer Stelle für eine gewisse Zeit warten und erst nach Ablauf der Wartefrist weiter fahren darf.
117
Knoten, welche innerhalb eines unterbrechbaren Bereichs liegen, werden durch ein Signal sofort unterbrochen. Der Kontrollfluss wird dann an anderer Stelle fortgesetzt.
Unterbrechbarer Bereich
Sobald das Signal eintrifft, wird der aktuell bearbeitete Ablaufknoten der Aktivität (im unterbrechbaren Bereich) sofort gestoppt. Der Ausgang des Signals zeigt, wo der Kontrollfluss weiterfahren soll.
Wichtig ist hier die Entscheidung, welche Schritte zum unterbrechbaren Bereich gehören sollen, oder ab wann ein Unterbruch nicht mehr sinnvoll ist (Bestellung bereits ausgeliefert, Account eröffnet, Transaction beendet, …).
118
Beispiel: Bestellvorgang
Als Zusammenfassung ein Beispiel mit den wichtigsten Symbolen des Aktivitätsdiagramms.Es geht weniger darum, ob dies ein sinnvoller Ablauf sein könnte, als darum den Gebrauch der verschiedenen Symbole im Zusammenhang zu sehen.
119
7. Zustände
Beschreibung von Zuständen, Zustandsübergängen und Ereignissen
Vgl. Oestereich Kap 2.6 Seiten 127‐133
120
Definition
Ein Zustandsautomat (State Machine) besteht aus den Zuständen, welches ein Objekt im Verlauf seiner Lebenszeit einnehmen kannden Ereignissen (Events), welche eine Zustandsänderung (Transition) auslöseneinem Anfangszustandeiner Menge von Endzuständenweiteren Pseudo-Zuständen (split, join, …)
Ein Zustandsautomat wird durch ein Zustandsdiagramm graphisch dargestellt.
Anfangs‐ (Start‐) und End‐Zustand sind sogenannte Pseudo‐Zustände.Es gibt immer nur genau einen Anfangszustand. Es kann aber mehrere Endzustände geben.
121
Verwendung
Statt mit einem Text sind solche Abläufe viel einfacher mit Hilfe eines Zustandsdiagramms beschreibbar.
Die textuelle Beschreibung der verschiedenen Zustände und Zustandsübergänge, welches ein Objekt in seiner Lebenszeit durchlaufen kann, ist oft schwierig zu verstehen.
Aktivitäts‐ und Zustands‐Diagramm werden oft verwechselt.Es ist darum wichtig zu unterscheiden, dass im Aktivitätsdiagramm die Aktionen im Zentrum des Interesses stehen. Das Zustandsdiagramm beschreibt hingegen die verschiedenen Zustände, welches ein Objekt (hier Bankkunde) im Verlauf seines Lebens annehmen kann.
122
Zustand: Attribute
Zustände werden durch ein abgerundetes Rechteck dargestellt.
Es werden nur diejenigen Attributwerte angegeben, welche für das Verhalten des Objektes relevant sind.
Ein Zustand wird bestimmt durch die Menge der möglichen Attributwerte, welche ein Objekt während eines Ablaufs annehmen kann.
Normalerweise sind dabei nicht alle Attribute eines Objekts (einer Klasse) relevant. Es werden nur die relevanten Attribute im Zustandsdiagramm notiert.
Oft können nicht alle möglichen Attributwerte notiert werden, sondern nur die relevantenBereiche (z.B. gleich, kleiner oder grösser als 0).
Der obige Zustand stellt ein aktiven, solventen Kunden dar. Es zeigt aber weder den Namen, noch die Adresse des Kunden, noch andere für diesen Zustand unwichtige Informationen.
Nicht jede Klasse muss über Zustände verfügen. Falls alle Operationen einer Klasse jederzeit und in beliebiger Reihenfolge ausgeführt werden können, besteht kein Grund für eine Zustandsmodellierung.
123
Zustand: Interne Aktionen
Innerhalb des Zustands können interne Aktionen angegeben werden:
entry: beim Eintritt in den Zustandexit: beim Verlassen des Zustandsdo: solange der Zustand nicht verlassen wird
Alle Konten eines Kunden, welcher zwar aktiv ist, aber insolvent wird, werden gesperrt.Erst wenn der Kunde diesen Zustand wieder verlässt, werden seine Konten wieder entsperrt.
124
Unterzustand/Verfeinerung
Zustände können durch Verfeinerung genauer definiert werden.
Man spricht auch von Subzustand (nested state).
Sobald die Tür geöffnet wird, wird der Zustand „heating“ verlassen, egal ob der Ofen als Backofen oder als Mikrowelle benutzt wird. Beim Schliessen der Türe muss zuerst wieder die Art des Heizens (Backen oder Mikrowelle) gewählt werden.
125
Zustandsübergang: Ereignis
Zustandsübergänge werden durch Ereignisse ausgelöst.
Ein Ereignis besteht aus einer Bezeichnung (first deposit) und ev. einer Liste von Argumenten. Ausserdem kann an das Ereignis eine Bedingung verknüpft sein ([balance > 0]).
Ein Ereignis kann auch eine Aktion aufrufen (lock()).
Zeitereignisse werden mit at() oder after() notiert
Ein Konto wird aktiv, sobald es einen positiven Kontostand hat.Ereignisse, welche keinen Zustandsübergang auslösen, können als interne Aktionen notiert werden: Am Ende jedes Jahres werden die Zinsen gutgeschrieben.
Ein Zustandsübergang auf den selben Zustand kann Sinn machen, da dadurch die exit und entry Aktionen getriggert werden (Zinsabschlüsse würden im obigen Beispiel also nur für gesperrte Konten gedruckt).
126
Transitions-BeschreibungDie Transitions-Beschreibung
wird notiert durch
ereignis (argumente) [bedingung]/operation(argumente)
127
Übergang auf den selben Zustand
Ereignisse (Events) können in den gleichen Zustand zurückführen (openAccount, deposit, …)
Der Lebenszyklus eines Bankkunden, der Konten eröffnen und schliessen, und Geldbeträge einzahlen und beziehen kann. Wenn das letzte Konto geschlossen wurde, wird das Kundenobjekt gelöscht.
Falls entry oder exit Aktionen vorhanden sind, werden diese bei jedem Event ausgelöst, auch wenn das Event auf den selben Zustand führt (vgl. Folie 125).
128
Es gibt ausserdem die folgenden Pseudo-ZuständeStartzustand Endzustand Vereinigung (synchron) Verzweigung, Teilung EntscheidungZusammenführungHistory
In Pseudozuständen wird nicht verweilt
Pseudo-Zustände
Es gibt genau einen Startzustand (initial state), ein Zustandsdiagramm kann aber mehrere Endzustände (terminate state) haben.
Die verschiedenen Wege, welche durch eine Verzweigung (splitting, fork) entstehen, können durch eine (synchrone) Vereinigung (join, synchronisation) wieder zusammengefasst werden.
Eine Entscheidung (choice) hat (analog zum Aktivitätsdiagramm) Bedingungen für die Weiterführung des Ablaufs. Eine Kreuzung (junction) führt die verschiedenen Wege wieder zusammen.
129
History
Ein History Pseudo-Zustand merkt sich den zuletzt aktiven Subzustand einer Verfeinerung.
Beim wieder Eintreten in den Zustand wird automatisch der „alte“ Subzustand wieder angenommen, in welchem er sich vor dem Verlassen des Zustandes befunden hat.
Beispiel: Fernseher
130
Übung: Telefon
In kommerziellen Programmen kommt der Einsatz von Zustands‐Diagrammen nicht so oft vor wie in Steuerungs‐Aufgaben. Das nachfolgende Thema ist deshalb aus diesem Bereich gewählt: es geht um eine einfache Telefon‐Steuerung.
Der Telefon‐Apparat verfüge über folgende Komponenten:• Hörer (mit Mikrofon und Lautsprecher),• Hörer‐Sensor mit den Zuständen
‐ up: Amtsleitung ist zu belegen, Hörer ist einzuschalten‐ down: Amtsleitung ist freizugeben, Hörer ist auszuschalten
• Tatstatur‐Block mit den Tasten‐ Ziffern 0 – 9‐ Clear‐Taste (zum Löschen der zuletzt eingegebenen Ziffer)‐Wähl‐Taste (zur Auslösung der Tonfolge für die Nummernwahl)
• Nummern‐Anzeige (Display) und Läutwerk (Telefonklingel)
Es sollen folgende Zustände modelliert werdenWenn Hörer up:
‐ Amtsleitung belegen, Hörer einschalten‐ Eingabe von Ziffern entgegennehmen und am Display anzeigen‐ Löschen der letzten Ziffer falls die Clear‐Taste gedrückt wird‐ Drücken der Wähl‐Taste sendet die Tonfolge für die Ziffernfolge Gesprächsbereit‐ Gesprächsabbruch bei Hörer down
Wenn Hörer down und Ruf von Zentrale:‐ Läutwerk einschalten‐ sobald Hörer up: Gesprächsbereit Läutwerk ausschalten, Drücken von beliebigen Tasten bewirkt nichts.‐ Gesprächsende bei Hörer down‐ Falls der Hörer innerhalb von 10 Sekunden nicht abgenommen wird
Läutwerk ausschalten, Übergangszustand bis der Ruf von der Zentrale aufhört.
AufgabenEntwerfen Sie das Zustands‐Diagramm für das Telefon‐Objekt.Entwerfen Sie zum Vergleich ein Aktivitätsdiagramm für den Ablauf eines Telefon‐Gesprächs (anrufen/empfangen).
131
8. Interaktion/ Kommunikation
Nachrichten, Ablauf, Sender, Empfänger
Vgl. Oestereich Kap 2.7 Seiten 134‐147
132
Sequenzdiagramm
Ein Sequenzdiagramm zeigt die Kommunikation zwischen verschiedenen Objekten im zeitlichen Ablauf
Welche Objekte sind an der Szene beteiligt
Welche Informationen (Nachrichten) werden ausgetauscht
In welcher zeitlichen Reihenfolge findet der Informationsaustausch statt
Sequenzdiagramme beschreiben die Kommunikation zwischen Objekten in einer bestimmten Szene. Es wird beschrieben welche Objekte an der Szene beteiligt sind, welche Informationen (Nachrichten) sie austauschen und in welcher zeitlichen Reihenfolge der Informationsaustausch stattfindet. Sequenzdiagramme enthalten eine implizite Zeitachse. Die Zeit schreitet im Diagramm von oben nach unten fort. Die Reihenfolge der Pfeile in einem Sequenzdiagramm gibt die zeitliche Reihenfolge der Nachrichten an.
133
Verwendung
Wichtige, komplexe Szenarien, welche mehrere Mitspieler betreffen, können mit Hilfe eines Sequenzdiagramms aufgezeichnet werden.
Sequenzdiagramme zeigen die Interaktion zwischen mehreren Kommunikationspartnern (Objekten).
Es wird dabei ein zeitlicher Ablauf (von oben links beginnend) beschrieben.
Sequenzdiagramme können in der Analyse und im Design eingesetzt werden. Sie können auch zur Modellierung von komplexen Operationen eines Systems verwendet werden und detaillierte Designinformationen enthalten. Sie werden zur Modellierung von Interaktionen gewählt, wenn die Darstellung der Reihenfolge des Nachrichtenaustauschs wichtig ist.
Bevor Sequenzdiagramme modelliert werden können, müssen die an der Szene beteiligten Klassen identifiziert werden. Die in Sequenzdiagrammen modellierten Objekte und Nachrichten müssen konsistent sein zum Klassendiagramm. Damit dient das Sequenzdiagramm auch zur Überprüfung des Klassendiagramms. Wir können erkennen, ob die Klassen und deren Operationen korrekt und vollständig sind
Ein System wird in der Regel nicht vollständig durch Sequenzdiagramme spezifiziert. Es werden nur diejenigen Szenen modelliert, die häufig vorkommen, sehr komplex oder besonders wichtig sind.
134
Auslöser eines Ablaufs
Initiator eines solchen Ablaufs ist normalerweise entweder ein Akteur eines Use Case Diagramms, oder ein (anonymes) Signal (Ereignis) von aussen.
Gestartet wird ein solcher Ablauf normalerweise durch einen äusseren Anlass (Akteur, Event, …)
Der Initiator kann, muss aber nicht angegeben werden.
135
Objekt: Klasse
Für Objekte wird (analog zum Objekt-Diagramm) ein Name und/oder die Klasse angegeben.
Die gestrichelte Linie zeigt die Lebenslinie.Das senkrechte Rechteck zeigt eine aktive Phase
(Ausführen von Operationen).
In dem Rechteck oberhalb der gestrichelten Linie wird der Objektname und der Klassenname angegeben. Die senkrechte, gestrichelte Linie stellt die Lebenslinie (lifeline) eines Objekts dar. In diesem zeitlichen Bereich existiert das Objekt. Das schmale Rechteck auf der gestrichelten Linie stellt eine Aktivierung dar. Eine Aktivierung ist der Bereich, in dem eine Methode des Objektes aktiv ist (ausgeführt wird). Auf einer Lebenslinie können mehrere Aktivierungen enthalten sein.
Da Sequenzdiagramme dynamische Aspekte eines Systems darstellen, müssen normalerweise Objektname und Klassennamen angegeben werden. Häufig vernachlässigt man jedoch den Objektnamen und gibt nur den Klassennamen an. Ein solches anonymes Objekt steht stellvertretend für alle Objekte der Klasse und impliziert, dass sich alle Objekte der Klasse in dieser Szene gleich verhalten.
136
Nachrichten (Messages)
Objekte kommunizieren über Nachrichten, die fortlaufend nummeriert werden.
Nachrichten sind asynchron oder synchron
Bei asynchronen Nachrichten kann, bei synchronen muss der Antwort-Pfeil eingezeichnet werden.
Nachrichten werden als Pfeile zwischen den Aktivierungen eingezeichnet. Der Name der Nachricht steht an dem Pfeil. Die Nachricht kann auch Argumente (Parameter) haben, diese werden in die Klammer geschrieben. Eine Nachricht liegt immer zwischen einem sendenden und einem empfangenden Objekt.
Das empfangende Objekt führt die entsprechende Operation aus (hat also laut Klassendiagramm eine solche Operation!).
Asynchron bedeutet, dass die verschiedenen Nachrichten in beliebiger Reihenfolge (oder gleichzeitig) abgesetzt werden können. Die Antwort wird nicht abgewartet.
Synchron heisst, die Reihenfolge ist vorgeschrieben.
137
Objekt erzeugen, zerstören
Das Erzeugen eines Objektes wird durch eine create Nachricht, die im Kopf des Objekts endet dargestellt.Das Zerstören (Löschen) eines Objektes wird durch ein x auf der Lebenslinie markiert.
138
Rekursive Nachrichten
Ein Objekt kann auch Nachrichten an sich selbst versenden (Verschachtelung)
Dies verlangt also eine Methode deposit(), sowie eine Methode processTransaction() in der Klasse BankOfficer.
Wir sehen hier nicht, woher der Aufruf zum deposit() kommt, oder welches Objekt die create() Methode ausführt.
139
Alternativen, Referenzen
In Sequenzdiagrammen können alternative Wege aufgezeigt oder es kann auf ein weiteres Sequenzdiagramm verwiesen werden.
Es kann in einem Sequenzdiagramm auch auf ein anderes Sequenzdiagramm verwiesen werden. Im ref‐Bereich wird angegeben, auf welches andere Sequenzdiagramm hier referenziert wird.
Im Allgemeinen sollte man mit solchen Konstrukten vorsichtig sein. Das Sequenzdiagramm eignet sich weniger für das Aufzeichnen von komplexen Abläufen. Für solche Fälle sind Aktivitätsdiagramme das bessere Hilfsmittel.
140
Schleife (Loop)
Diese Abbildung zeigt eine Schleife in einem Sequenzdiagramm. Von aussen kommt ein (Zeit)‐Signal, für alle Konten die Zinsen gutzuschreiben. Das AccountManagement holt die Liste der Accounts und iteriert über diese.
Für jeden Account wird der zugehörige Besitzer (Customer) ermittelt, die geschuldeten Zinsen berechnet und eine entsprechende Transaktion (Banküberweisung) erzeugt.
Falls es auch negative Zinsen zu belasten gibt, wird eine zweite Transaktion erzeugt.
141
Checkliste
Die Namen der Akteure müssen konsistent zu den Use Case Diagrammen sein.Klassennamen/Meldungen müssen konsistent zum Klassendiagramm sein.Objekte sollten möglichst so angeordnet werden, dass in einem Diagramm nur wenig Kreuzungen entstehen.Nachrichten sollten möglichst von links nach rechts zeigen, Returns von rechts nach links.Beteiligte Akteure sollten eher am linken Rand der Diagramme stehen.
Es ist also wichtig zu überprüfen, ob das aufrufende Objekt das aufgerufene Objekt kennt (eine Referenz darauf hat) und ob das aufgerufene Objekt eine entsprechende Methode besitzt.
142
Kommunikationsdiagramm
Im Klassendiagramm können wir die Beziehungen der verschiedenen Objekte erkennen.
Ein Kommunikationsdiagramm kann hingegen aufzeigen, welches Objekt in einem Ablauf welche Operation in welcher Reihenfolge aufruft.
143
Verwendung
Kommunikationsdiagramme erlauben es, auf informelle Art, einen einfachen Ablauf zu skizzieren.
Die aufgerufenen Operationen müssen dabei den Operationsnamen im Klassendiagramm entsprechen. Ebenfalls müssen die Klassen der benutzten Objekte im Klassendiagramm vorhanden sein.
144
Notation
Die Objekte werden (analog zum Sequenz-Diagramm) durch Angabe eines Namens und der Klasse definiert.Die Pfeile zeigen die Richtung des Operations-Aufrufs (wer ruft welche Operation welches Objekts auf).Bedingungen, Iterationen, … werden in eckige Klammern geschrieben.
Die Reihenfolge der Operationsaufrufe ist durch die Nummern ersichtlich.
145
9. GUI Prototyp
Masken und Navigationsstruktur
146
GUI Prototyp
Wie findet man die nötigen Masken / Fenster /Teilfensterderen Inhaltedie richtige Reihenfolge / Struktur
Welche Informationen dazu kann man in welchem Diagramm finden?
Es geht hier nicht darum, ein ergonomisches GUI zu finden. Wir versuchen hier bloss eine erste Skizze zu erstellen, welche dem Auftraggeber als Hilfe dient, die Abläufe zu kontrollieren und die Klassen (Daten/Informationen) auf Vollständigkeit zu prüfen.
147
Use Case Diagramm
Jeder primäre Use Case wird in einem (separaten) Fenster abgebildetSekundäre Use Cases sind eventuell im selben Fenster, eventuell in einem Dialog-Fenster, eventuell auf dem GUI nicht sichtbarAblauf aus Use-Case Beschreibung
Benutzerführung
Es kommt sehr selten vor, dass ein Fenster mehr als einen Primären Use Case abbildet. Im Normalfall ist das auch ergonomisch nicht sinnvoll.
148
Die benötigten Fenster, welche man daraus ableiten kann:
149
Aktivitätsdiagramm
Reihenfolge der Aktivitäten Navigationsstruktur
Faustregel: Zu jeder Aktion gehört eine entsprechende Maske und ein Menu-Punkt oder Button (suchen, speichern, erstellen, löschen, …)
Das sind ev. Masken/Fenster, welche bereits durch die Use Cases erkannt wurden, eventuell kommen aber neue Masken/Fenster dazu (grösserer Detaillierungsgrad).
Die Reihenfolge der Aktionen wird auf dem GUI durch die Reihenfolge der Fenster (Ablauf / Navigation) widergespiegelt.
150
Die nötigen Fenster zum Erfassen eines Neukunden (inkl. Erstellen des ersten Accounts) sind:
151
Klassendiagramm
KlassenattributeMasken-Inhalte
Jede Klasseeigenes Fenster oder TeilfensterGruppierung
Alle Informationen einer Klasse befinden sich normalerweise auf dem gleichen Fenster. Es kann sein, dass mehrere Klassen auf demselben Fenster abgebildet werden. Dies vor allem bei Aggregationen oder Kompositionen. Diese werden aber üblicherweise auf dem GUI klar abgegrenzt (Gruppierung z. B. durch Linien oder Abstände).
152
Bank System
Die nötigen Textfelder zum Erfassen eines Kunden sind:
153
Balsamic Tool
154
10. Analyse Muster
Entwurfsprinzipien
Siehe auch Heide Balzert: Lehrbuch der Objektmodellierung.
155
Definition
Analyse Muster (Analysis-Pattern) beschreiben eine Lösung für eine typische Teilaufgabe bei der Erstellung eines fachlichen Modells, das heisst also in der Analyse-Phase.
Entwurfs Muster (Design-Pattern) sind bewährte Lösungsschablonen für wiederkehrende Entwurfsprobleme in der Design Phase. Sie beschreiben auf hoher Abstraktionsebene einen Ansatz für eine Software Lösung.
Der Unterschied von Analyse und Design Pattern besteht vor allem in der zeitlichen Abfolge.Analyse Muster werden in der Analyse Phase zum Definieren des fachlichen Modells beigezogen.
Design Pattern werden erst in der Design Phase eingesetzt, wenn es darum geht die Gesamt‐Lösung zu entwerfen (bzw. die konkrete Umsetzung zu definieren).
156
Anwendung
Analyse Muster dienen zur Modellierung häufig vorkommender Strukturen.beschreiben eine Gruppe von Klassen oder Objekten mit
festen Verantwortlichkeitendefinierten Beziehungendefinierten Interaktionen
haben einen eindeutigen Namenbeantworten die Frage:Wie modelliere ich diese Klassenbeziehung?
Ein Analyse Muster beschreibt also eine Lösung für eine typische Teilaufgabe bei der Erstellung eines fachlichen Modells (d.h. in der Analyse Phase).
Entwurfs Muster sind hingegen eher implementierungs‐orientierte Muster. Sie geben Antwort auf die Frage: „Wie realisiere ich diese Klassenbeziehung?“
157
Umsetzung
Design Modell
Software Entwicklungs-Prozess
KonkretesProblem
AnalyseModell
Analyse
Transformation / Einbettung
Konkrete Ebene
Abstraktion
Problem/Aufgabe Lösung
Implementation
Analyse Pattern helfen dabei, eine Struktur in die (oft amorphe) Menge von benötigten Information zu bringen. Design Pattern können dann Hinweise geben, wie das Gesamt‐System konkret implementiert werden soll.
158
Muster 1: Liste
Merkmale
Komposition (Ganzes Teile)
Alle Teile sind gleichartig
Jedes Teil gehört zu genau einem Aggregat
Aggregat enthält mindestens ein Teil
die Multiplizität ist normalerweise 1..*
Typische Listen Muster kommen vor bei Bestellungen (Bestell‐Kopf und die einzelnen Bestellpositionen), bei Aufträgen (Gesamtauftrag und die einzelnen Einzel‐Aufträge/Aufgaben) oder bei Projekten (Gesamt‐Projekt und einzelne Projekt‐Schritte).
Alle Listenelemente haben den gleichen Typ (tragen die gleichen Informationen).Die Listenelemente machen nur als Teil der Liste einen Sinn.
159
Liste
Beispiele
Weitere Listen treten zum Beispiel auf bei Auftrag ‐> Auftragspositionen ‐> EinzelAuftrag
160
Muster 2: Exemplartyp
Merkmale
Es existieren mehrere konkrete Exemplare eines Objektes (z.B. Buch -> Bibliothek)
Sammeln der gemeinsamen Informationen (Signatur, Titel, …) in einer Beschreibungsklasse
Exemplar-Informationen (ID, Ausleihe, …) in Exemplar-Klasse
Einfache Assoziation (keine Komposition)
Objektbeziehungen bleiben konstant (ausser ein Exemplar wird gelöscht)
Auch bekannt als Item / Item‐Description Analyse‐Muster (Peter Coad et al.: „Object Models: Strategies, Patterns, and Applications“, Prentice Hall, 1996 )
161
Exemplartyp
Beispiele
162
Muster 3: Baugruppe
MerkmaleEine Baugruppe beschreibt ein aus verschiedenen
Teilen zusammengebautes physisches Objekt (Schiff, Flugzeug, Turbine, …)
Physische Teile eines Objektes -> KompositionDas zusammengesetzte Objekt besteht aus unterschiedlichen TeilenDie Beziehung besteht über lange ZeitEin Teilobjekt kann vom Ganzen getrennt und in ein anderes Objekt eingebaut werden
163
BaugruppeBeispiel
Ein Flugzeug besteht aus verschiedenen physischen Teilen, welche selber auch wieder aus kleineren Teilen zusammengesetzt sein können. Ein Motor eines Flugzeugs könnte aber prinzipiell auch ausgetauscht oder in einem anderen Flugzeug eingebaut werden.
164
Muster 4: Stückliste
Stücklisten bestehen aus Teilen, die aber selber als Einzelobjekte auftreten können.
MerkmaleGanzes / Teile Verhältnis -> KompositionDas Aggregat und seine Teile können als ganzes betrachten werdenDie Teile können auch als eigenständige Objekte behandelt werdenDie Multiplizität der Aggregatsklasse ist 0..1.Jedes Objekt vom Typ A kann wieder aus Objekten vom Typ A, aber auch aus Objekten vom Typ B, C, … bestehen.
Im Gegensatz zur Baugruppe, wo eine strenge Hierarchie herrscht, kann bei einer Stückliste jedes Teil als Gesamtes oder als Teil eines anderen Teils auftreten.
Ein Flugzeug besteht aus Flugzeugteilen, aber nicht aus einzelnen Flugzeugen.Jeder Knoten eines Baumes kann hingegen selber wieder Knoten enthalten. Jeder Teilbaum hat einen Wurzel‐Knoten, das heisst, jeder Knoten kann ein Ganzes repräsentieren.
165
Stückliste
Beispiele
Ein Directory kann selber Directories, Links oder File enthalten. Ein Directory kann in einem Directory enthalten sein, muss aber nicht.
Ein Komponenten Baum ist ein Spezialfall einer Stückliste, da er aus lauter gleichartigen Objekten besteht.
166
Muster 5: Koordinator
Ein Koordinator verbindet zwei verschiedene Objekte. Seine Aufgabe besteht darin, zu wissen wer wen kennt.
MerkmaleEinfache AssoziationEin Koordinator hat wenig eigene Attribute und OperationenEr dient vor allem dazu, andere Objekte zu verbinden.
Ein Koordinator wird eingesetzt, um mehrstellige Assoziationen durch zwei einfache Assoziationen und eine (Vermittler‐)Klasse zu ersetzen.
167
Koordinator
Beispiele
168
Muster 6: Rollen
MerkmaleZwischen zwei Klassen bestehen mehrere einfache AssoziationenEin Objekt kann zu verschiedenen Zeitpunkten verschiedene Rollen einnehmenDas Objekt, welches verschiedene Rollen spielen kann, hat für alle Rollen die gleichen Eigenschaften und Operationen
Das Rollen Analyse Muster kommt sehr oft im Zusammenhang mit Personen zum Einsatz, welche zu verschiedenen Zeiten verschiedene Aufgaben wahrnehmen.
169
Rollen
Beispiele
In einer Abteilung kann abwechselnd jemand anders die Leitung übernehmen. In einem Kurs können die Redner auch Kurs‐Teilnehmer sein.
170
Muster 7: Wechselnde Rollen
MerkmaleEin Objekt kann zu verschiedenen Zeitpunkten verschiedene Rollen einnehmenFür die verschiedenen Rollen benötigt das Objekt verschiedene (zusätzliche) Eigenschaften oder OperationenDie unterschiedlichen Rollen werden mittels Generalisierung modelliertBeziehungen zwischen dem Objekt und seinen Rollen werden nur erweitert, nicht gelöschtEs gibt keine Beziehungen zwischen den Rollen und anderen Objekten
Im Unterschied zum Rollen Analyse Muster haben die Objekte der Wechselnden Rollen verschiedene Eigenschaften (zusätzliche Attribute oder Operationen).
171
Wechselnde Rollen
Beispiel
Der gleiche Mitarbeiter kann zu verschiedenen Zeiten verschiedene Rollen (Zustände) wahrnehmen. In den verschiedenen Rollen haben die Mitarbeiter andere Eigenschaften und Aufgaben, (Attribute/Operationen).
172
Muster 8: Historie
MerkmaleZwischen den Objekten ist eine einfache AssoziationFür jedes Objekt müssen mehrere Informationen gespeichert werdenJede Information bezieht sich auf einen Zeitraum, welcher angibt, was zu welchem Zeitpunkt giltBeziehungen zwischen dem Objekt und seinen Informationen werden nur erweitert, nicht gelöscht
Im Rollen Analyse Muster wird keine Historie geführt, das heisst, es ist nicht bekannt, welche Rollen diese Person zu welchem Zeitpunkt eingenommen hat.
Die Historie hingegen speichert die ganze Vorgeschichte.
173
Historie
Beispiel
Die verschiedenen (Teilzeit) Anstellungen können sich prinzipiell zeitlich überlappen. Zu jedem Zeitraum gibt es mindestens eine Anstellungsart. Jeder Anstellungswechsel führt zu einem neuen Anstellungs‐Objekt.
174
Muster 9: Gruppe
MerkmaleZwischen den Objekten ist eine einfache AssoziationMehrere Einzelobjekte gehören (zu einem gewissen Zeitpunkt) zur gleichen GruppeDie Gruppe kann kurzfristig eventuell auch ohne Mitglieder existierenDie Objektbeziehungen können erstellt und wieder gelöscht werden
Das Gruppe Analyse Muster dient zum Aufzeigen von Zugehörigkeiten verschiedener Einzel‐Objekte zu einer (möglicherweise wechselnden) Gruppe.
Diese Gruppe kann eine Abteilung, ein Projekt‐Team oder eine beliebige Menge von gleichartigen Objekten sein, welche (im Gegensatz zur Liste) auch ohne das Gruppenelement existieren können.
175
Gruppe
Beispiel
Die Angestellten gehören jeweils zu einer oder mehreren Projekt Gruppen. Dies kann jenach Zeitpunkt wechseln und muss nicht historisiert werden. Ein Angestellten kann auch keiner oder mehreren Projekt Gruppen angehören.
176
Muster 10: Gruppenhistorie
MerkmaleZwischen den Objekten ist eine einfache AssoziationMehrere Einzelobjekte gehören (zu einem gewissen Zeitpunkt) zur gleichen GruppeDie Gruppe kann kurzfristig eventuell auch ohne Mitglieder existierenDa die Informationen historisiert werden sollen, können zwar neue Objektbeziehungen entstehen, es werden aber keine Beziehungen gelöscht.
Analog zur Historie wird bei der Gruppenhistorie die ganze Vorgeschichte gespeichert.
177
Gruppenhistorie
Beispiel
Die Angestellten gehören jeweils zu einer oder mehreren Projekt Gruppen. Dies kann jenach Zeitpunkt wechseln und wird historisiert. Ein Angestellter kann auch keiner oder mehreren Projekt Gruppen angehören, oder mehrfach (zu verschiedenen Zeitpunkten) zur gleichen Gruppe.
178
11. DB-Prototyp
Objektrelationale Abbildung
179
Eigenschaften einer Datenbank
PersistenzDaten gehen bei Programmende nicht verloren
ZuverlässigkeitKonsistenz, Integrität, Unversehrtheit, Effizienz
UnabhängigkeitEigene Programmiersprache, eigenes System
AbstraktionKommunikation über Schnittstelle
DatenschutzKein unberechtigter Zugriff
Mehrfachbenutzung
Die Hauptaufgabe einer Datenbank besteht darin, Daten so lange zu speichern bis diese explizit überschrieben oder gelöscht werden. Also auch über das Ende (ev. sogar der Lebenszeit) einer Applikation hinaus.
Die Daten müssen konsistent (vollständig und widerspruchsfrei), integer (unverfälscht, sicher), unversehrbar (geschützt vor absichtlicher oder unabsichtlicher Veränderung) gespeichert werden und effizient wieder lesbar sein.
Um die Langlebigkeit der Daten zu gewähren, muss die Verwaltung der Daten unabhängig von den benutzenden Applikationen geschehen (Programmiersprache). Ausserdem will der Applikationsentwickler sich nicht um die technischen Details der Datenbank kümmern müssen, sondern auf einer höheren, abstrakten Schnittstelle auf die DB zugreifen können.
Die Daten der Datenbank müssen vor unberechtigtem Zugriff geschützt werden können, anderseits soll aber jeder berechtigte Anwender (ev. auch mehrere gleichzeitig) auf die Daten zugreifen können.
180
Datenbankmodell
Eigenschaften der DatenelementeTyp, Länge, Wertebereich, …
StrukturTabellenstruktur, Schlüssel, Beziehungen
KonsistenzbedinungenEindeutigkeit/Vorhandensein von Werten
Zugriffs-OperationenSpeichern, suchen, ändern, löschen, …
Ein Datenbankmodell ist die theoretische Grundlage für eine Datenbank und bestimmt, auf welche Art und Weise Daten in einem Datenbanksystem gespeichert und bearbeitet werden können.
Jedem Datenbanksystem muss darum ein Datenbankmodell zugrunde liegen, in welchem die DB Struktur (Tabellen), die Typen der Elemente, die Konsistenzbedingungen, …festgelegt sind.
181
Relationales DB-System
RDBS basiert auf RelationenWird in Tabellen abgebildetEinfach und flexibel
2002XML für Einsteiger2…3
2006XML kurz und gut1YearTitleIdBook
Name der Tabelle/Relation
Attribute/Felder/Spalten
Tupel/Zeilen
Relationale Datenbanksysteme sind sehr einfach und flexibel und darum heute die am häufigsten benutzten DB Systeme.
Ihr Nachteil ist allerdings, dass sie die OO‐Konzepte nicht eins zu eins abbilden können.
182
Objektrelationale Abbildung
Zusammenhang zwischen OO-Klassen und RDB-Tabellen ORM
???
???
???
??????
Objektorientierte Programmiersprachen kapseln Daten und Verhalten in Objekten, relationale Datenbanken hingegen legen Daten in Tabellen ab. Ausserdem stellt nicht jede Menge von Tabellen eine relationale Datenbank dar.
Die beiden Paradigmen OO und RDB sind grundlegend verschieden. Es braucht darum einen Mechanismus, wie man eine Abbildung zwischen Klassen(‐Strukturen) und relationalen Tabellen finden kann.
ORM: object‐relational mapping
183
DB Normalformen
Eine DB mit redundanten Daten ermöglicht, dass bei Daten-Änderungen die mehrfach enthaltenen Daten inkonsistent werden.
Anomalien, WidersprücheSpeicherplatz-Verschwendung
Redundanzen vermeiden durch Normalisierung
Das Ausmass, in denen ein Datenbankschema gegen Anomalien gefeit sein kann
erste, zweite, dritte, ... Normalform
Damit eine Menge von Tabellen (ein Datenbankschema) eine brauchbare Relationale Datenbank darstellt, müssen einige Regeln erfüllt sein. Diese sind bekannt unter dem Begriff DB Normalformen.
184
Erste Normalform
Jedes Attribut der Relation muss einen atomaren Wertebereich haben.
Zusammengesetzte oder geschachtelte Wertebereiche sind nicht erlaubt.
Kein Attributwertebereich kann in weitere (sinnvolle) Teilbereiche aufgespaltet werden
Beispiel: Adresse darf nicht als Attribut verwendet werden, sondern muss in PLZ, Ort, Straße und Hausnummer aufgeteilt werden.
185
Erste Normalform
Verletzung der ersten NormalformPublikation aus Verlag, Kürzel und JahrMehrere Autoren (mit Reihenfolge)
Keine einfache Sortierung nach Erscheinungs-Jahr möglichAutoren können nicht einfach aufgelistet werden.
1. Michael Scholz, 2. Stephan Niedermeier
Galileo (GaC: 2009)
Java und XML3
1. Helmut VonhoegenGalileo(GaC: 2011)
Einstieg in XML2
1. Simon St. Laurent, 2. Michael Fitzgerald
O'Reilly (ORe:2006)
XML kurz und gut1
AuthorPublishedBooktitleID
Die (geordnete Liste der) Autoren darf nicht in ein einzelnes Feld abgespeichert werden. Das Datumsfeld ist in dieser Form nicht gut benutzbar (Mischung aus Monat und Jahr, kein richtiges Datum).
186
Erste Normalform
Mögliche Lösung
Galileo
Galileo
Galileo
O'Reilly
O'Reilly
Publisher
Stephan
Michael
Helmut
Michael
Simon
Firstname
Scholz12009GaCJava und XML
3
Niedermeier22009GaCJava und XML
3
Vonhoegen12011GaCEinstieg in XML
2
Fitzgerald22006OReXML kurz und gut
1
St. Laurent12006OReXML kurz und gut
1
NameA-NrYearPTLABooktitleId
Diese Lösung hat allerdings immer noch Schwächen: Wir haben jetzt Buch 1 und 3 doppelt in der Datenbank. Ausserdem ist es schwierig zu prüfen, ob die Autorennummern (A‐Nr) eindeutig (und vollständig) sind.
187
Zweite Normalform
Eine Relation ist in der zweiten Normalform, wenn die erste Normalform gilt und kein Nichtschlüssel-Attribut voll funktional abhängig von einer echten Teilmenge eines Schlüsselkandidaten ist.
Das heisst: Von einer beliebigen Teil-Menge von Attributen (Spalten), die keine Schlüsselfunktion haben, kann nicht auf den Wert anderer Attribute geschlossen werden.
188
Zweite Normalform
Verletzung der zweiten Normalform
Die Spalten Id und A-Nr bilden einen (Primär-) Schlüssel. Buchtitel, Publisher und Year sind von der Id abhängig, nicht aber von der Nummer des Autors.
Galileo
Galileo
Galileo
O'Reilly
O'Reilly
Publisher
Stephan
Michael
Helmut
Michael
Simon
Firstname
Scholz12009GaCJava und XML
3
Niedermeier22009GaCJava und XML
3
Vonhoegen12011GaCEinstieg in XML
2
Fitzgerald22006OReXML kurz und gut
1
St. Laurent12006OReXML kurz und gut
1
NameA-NrYearPTLABooktitleId
Die Id des Buchs identifiziert vollständig die Spalten Buchtitel, Publisher und PTLA, das heisst, diese sind vom zweiten Schlüssel unabhängig. Damit wird aber die zweite Normalform verletzt.
Der zweite Schlüssel A‐Nr identifiziert zusätzlich (nur noch) den Namen des Autors.
189
Zweite NormalformMögliche Lösung
Galileo
Galileo
O'Reilly
Publisher
2011GaCEinstieg in XML2
2009GaCJava und XML3
2006OReXML kurz und gut1
YearPTLABooktitleId
ScholzMichael22
FitzgeraldMichael21
VonhoegenHelmut12
NiedermeierStephan13
St. LaurentSimon11
NameFirstnameA-NrB-Id
Book
Author
In der Book Tabelle haben wir jetzt nur noch den Primär-Schlüssel Id von welchem alle Spalten abhängig sind.
B-Id und A-Nr bilden zusammen einen Primär-Schlüssel, von welchem die beiden anderen Spalten abhängig sind.
B‐Id ist jetzt in der Autoren‐Tabelle ein Fremdschlüssel, welcher auf den Primärschlüssel der Book‐Tabelle verweist. Ausserdem bilden jetzt B‐Id und A‐Nr zusammen einen Primärschlüssel für die Autoren‐Tabelle.
Allerdings ist auch hier noch keine Redundanzfreiheit gewährleistet. Ein Autor, welcher mehrere Bücher geschrieben hat, wird in dieser Darstellung mehrfach aufgelistet.
190
Dritte Normalform
Die dritte Normalform ist erfüllt, wenn sich das Relationenschema in der zweiten Normalform befindet, und kein Nichtschlüsselattribut von einem Schlüsselkandidaten transitiv abhängt.
Ein Nichtschlüsselattribut darf also nicht von einer Menge von Nichtschlüsselattributen, sondern nur direkt von einem Primärschlüssel abhängig sein.
191
Dritte Normalform
Verletzung der dritten Normalform:
Die Spalte PTLA hängt direkt von der Spalte Publisher ab. Beim Ändern des Publishers müsste auch die PTLA Spalte geändert werden.
Galileo
Galileo
O'Reilly
Publisher
2011GaCEinstieg in XML2
2009GaCJava und XML3
2006OReXML kurz und gut1
YearPTLABooktitleIdBook
PTLA ist unabhängig von der Book Id und hängt allein vom Publisher ab. Publisher ist aber kein Schlüsselattribut für Buch. Darum ist hier die dritte Normalform verletzt.
192
Dritte NormalformMögliche Lösung
2
2
1
Publisher
2011Einstieg in XML2
2009Java und XML3
2006XML kurz und gut1
YearBooktitleIdBook
GalileoO'Reilly
Publisher
GaC2
ORe1
PTLAId
5
4
3
2
1
Id
VonhoegenHelmut2
St. LaurentSimon1
FitzgeraldMichael1
Stephan
Michael
Firstname
Niedermeier3
Scholz3
NameB-Id
Publisher
Author
Durch Auslagern der Publisher in eine eigene Tabelle ist PTLA direkt vom Primärschlüssel des Publishers abhängig, d.h. die dritte Normalform ist gewärleistet.
Die Autoren‐Tabelle enthält hier einen Fremdschlüssel auf die Buch‐Tabelle. Dies funktioniert hier gut, da jeder Autor nur einem Buch zugeordnet ist. Um einem Autor mehrere Bücher zuzuordnen, bräuchte es eine separate Assoziations‐Tabelle (siehe Folie weiter hinten).
193
Objekt-Relationale Abbildung
Abbilden von Klassen und Relationen
194
Abbilden von Klassen
Operationen werden nicht abgebildet.Atomare Attribute erscheinen als Spalte in der Tabelle mit (möglichst) demselben TypDie Tabelle wird um einen Primär-Schlüssel ergänzt
finished9.8.201115.2.201112OOAD3
cancelled1.1.20113.10.201041XML2
finished2.7.201112.1.2011103Java1
StateEndStartNrNameIdCourse
195
Abbilden von Vererbung
Es gibt verschiedene Möglichkeiten, Generalisierungs-Hierarchien abzubildenAbbilden der ganzen Hierarchie auf nur eine TabelleAbbilden nur der konkreten Klassen auf je eine TabelleAbbilden jeder Klasse auf je eine separate Tabelle
196
Abbilden auf nur eine Tabelle
3
2
1
Id
null15.2.201112Willi GrauTN
partTimenull41Gabi BlauDZ
null12.1.2011103Hans MusterTN
StateDateOfBirthAddressNameTypePerson Teilnehmer
Dozent
Dieser Ansatz ist zwar sehr einfach, der Zugriff auf die Daten ist schnell, da alle Daten in der gleichen Tabelle liegen. Weitere Subklassen sind einfach einzufügen, es müssen nur die entsprechenden Spalten angefügt werden.
Der Ansatz hat aber den Nachteil dass viele der Attribute auf null gesetzt werden müssen (alle, welche im speziellen Subtyp nicht vorkommen). Ausserdem sind bei einer Änderung innerhalb der Hierarchie (z.B. Ergänzen einer Klasse um ein weiteres Attribut) immer alle Objekte der Hierarchie betroffen.
Dieser Ansatz ist geeignet für Hierarchien geringer Tiefe mit wenig verschiedenen Klassen.Die Spalte Type enthält den eigentlichen Datentyp, hier also entweder Teilnehmer oderDozent. Person kann als Type vorkommen, ausser wenn die Basisklasse abstrakt (oder ein Interface) ist.
197
Abbilden jeder konkreten Klasse auf je eine Tabelle
2
1
Id
15.2.201112Willi Grau
12.1.2011103Hans Muster
DateOfBirthAddressNameTeilnehmer
1
IdpartTime41Gabi Blau
StateAddressNameDozent
Hier wird jede konkrete Klasse auf eine separate Tabelle abgebildet. Jede Tabelle hat einen eigenen Primär‐Schlüssel (Id). Auch hier ist der Zugriff effizient, da jeder Zugriff nur eine Tabelle betrifft. Der Nachteil ist, dass bei einer Änderung der abstrakten Oberklasse (hier Person) alle davon betroffenen Tabellen geändert werden müssen.
Dieser Ansatz ist daher am ehesten geeignet, wenn die Basisklasse nur wenig Attribute besitzt.
198
Abbilden jeder Klasse auf je eine Tabelle
1
IdpartTime2
StateP-IdDozent
3
2
1
Id
12Willi Grau
41Gabi Blau
103Hans Muster
AddressNamePerson
2
1
Id
15.2.20113
12.1.20111
DateOfBirthP-IdTeilnehmer
Dieser Ansatz entspricht am besten dem Objektorientierten Konzept. Änderungen in der Basisklasse hat keine Änderungen in den „abgeleiteten“ Tabellen zur Folge. Neue Attribute in den Subklassen betreffen nur die eigene Tabelle.
Der Nachteil ist, dass sehr viele Tabelle entstehen und die Abfragen aufwändiger werden, da bei dieser Variante die Informationen in verschiedenen Tabellen liegen.
199
Abbilden von Assoziationen
Unterscheiden nach Multiplizität1:1 1:mm:m
Assoziationen einer Relationalen DB sind immer bidirektional.
Je nach Multiplizität der Assoziation wählen wir eine andere Art der Abbildung.Im Gegensatz zum Objektorientierten Modell können wir in einer DB immer beide Richtungen einer Assoziation finden. Je nach Realisierung brauchen wir einfach eine andere SQL‐Abfrage.
200
Abbilden einer 1:1 Assoziation
EndTimeStartTimeWeekdayId
2
16:308:30Monday1
Stundenplan
… …Stundenplan_FKNameId
2
1Java1
Course
Java
Name EndTimeStartTimeWeekdayId
2
16:308:30Monday1
Course
Oder integriert:
1:1 Assoziationen können durch Verschmelzen der Informationen in eine einzige Tabelle abgebildet werden. Dies ist die kompakteste und effizienteste Umsetzung.
Falls man das nicht möchte, kann die Assoziation mit Hilfe eines Fremdschlüssels realisiert werden. Bei der gerichteten Assoziation von Course zu Stundenplan bietet sich ein Fremdschlüssel Stundenplan_FK in der Course Tabelle an. Das umgekehrte (Fremdschlüsssel Course_FK in Stundenplan‐Tabelle) wäre aber genau so möglich.
Die SQL Abfrage für die Wochentage aller Kurse wäre dann etwaselect c.Name, s.Weekday from Stundenplan s, Course c where c.Stundenplan_FK = s.Id
201
Abbilden einer 1:m Assoziation
…AddressNameId
2
Josef Muster1
Dozent
… …Dozent_FKNameId
2
1Java1
Course
Bei einer 1:m Assoziation wird der Fremdschlüssel in die Klasse eingefügt, welche die Multiplizität 1 hat. Hier: jeder Kurs hat (nur) einen Dozenten, Dozenten können mehrere Kurs halten.
202
Abbilden einer m:m Assoziation
…DateOfBirthNameId
2
Hans Muster1
Teilnehmer
… …NameId
XML2
Java1
Course
Teilnehmer_FKCourse_FK
12
Course_ Teilnehmer
Zum Abbilden einer m:m Assoziation benötigen wir eine zusätzliche Tabelle für die Tupel der Fremdschlüssel. Course_Teilnehmer ist eine sogenannte Assoziations‐Tabelle (associative table).
203
Abbilden eines Koordinators
Dozent
…DateOfBirthNameId
2
Hans Muster1
Teilnehmer… …NameId
XML2
Java1
Course
1
Teilnehmer_FK StateCourse_FK
active2
Registrierung
Die Koordinator‐Klasse verbindet (indirekt) zwei Klassen durch eine m:m Assoziation, trägt aber zusätzliche Informationen (hier ein state‐Attribut). Auch diese wird mit einer Assoziationstabelle (mit zusätzlichen Spalten für die Koordinator‐Attribute) realisiert.
204
Reflexive AssoziationBsp: Stückliste
11.12.2008usr21
nullFolder_FK
……
…10.1.2008root1
1.12.2008bin3
…DateNameIdFolder
Zum Abbilden einer reflexiven (rekursiven) Assoziation kann ein Fremdschlüssel benutzt werden, welcher auf den Primärschlüssel der eigenen Tabelle zeigt. Dieser ist für die Root‐Elemente der Hierarchie leer (null).
205
12. Design Pattern
Entwurfsmuster
206
Anforderungen
Ein gutes Design Pattern (Entwurfsmuster) sollteein oder mehrere bekannte, wiederkehrende Probleme lösenein erprobtes Konzept bietenauf realen Konstrukten basierenüber das völlig Offensichtliche hinausgehenBeziehungen aufzeigen, die tiefergehende Strukturen und Mechanismen eines Systems umfassenUnterstützung für (Gesamt-)DesignEntscheidungen bieten
Ein Design Pattern sollte eine bewährte Lösung zu einem oft wiederkehrenden Problem bieten.
207
Nutzen
Der primäre Nutzen eines Entwurfsmusters liegt in der Beschreibung einer Lösung für eine bestimmte Klasse von Entwurfsproblemenergibt sich aus dem Namen des Musters. Dies vereinfacht die Diskussion unter den Entwicklern
Das Benutzen (und Dokumentieren) von Design Pattern erleichtert das Lesen/Verstehen des Programmcodes.
Design Pattern sind unabhängig von der konkreten Programmiersprache. Das ermöglicht, dass man zunächst abstrakt über mögliche Lösungen sprechen kann. Damit kann auf hohem Niveau über verschiedene Strukturen diskutiert werden, also ohne eine konkrete Lösung (Programmcode).
208
Nachteile
Das Kennen vieler Design Pattern kann dazu verleitenPattern als Wunderwaffe für ein gutes Design anzusehenviele bekannte Pattern zu verwenden und dabei einfachere/elegantere Lösungen zu übersehenden Code unnötig aufzublähenein zu allgemeines (generisches) Problem zu lösen
Entwickler können durch das Kennen vieler Design Pattern dazu verleitet werden, möglichst viele Pattern zu verwenden und dabei übersehen, dass in ihrem Fall vielleicht eine einfachere, elegantere Lösung ohne den Einsatz von Design Pattern möglich gewesen wäre.
Design Pattern können den Code unnötig aufblähen, da durch das Verwenden des Pattern (ev. unnötigerweise) ein allgemeineres Problem gelöst wird.
Entwurfsmuster garantieren nicht, dass der Entwurf gut ist. Insofern ist die Anwendung zu vieler oder ungeeigneter Entwurfsmuster ein Antimuster.
209
Geschichte1970: Erste Sammlung von Entwurfsmustern des Architekten Christopher Alexander1987: Kent Beck und Ward Cunningham, Entwurfsmuster für die Erstellung von GUIs in Smalltalk1988: Erich Gamma, Entwurfsmuster für die Softwareentwickling (Promotion)1989-1991: James Coplien Advanced C++ Idioms1994: Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides Design Patterns - Elements of Reusable Object-Oriented Software (23 Entwurfsmuster)
Gang of Four (Viererbande, GoF)
210
Pattern Schablone
Pattern NameZweck
Wozu dient das Pattern?Szenario/Problem/Kontext
Ein Beispiel ProblemLösung/Struktur/ImplementationVorteile/NachteileVerwendung
AnwendungsgebieteVarianten Verweis auf andere Muster
•Pattern Name und Klassifizierung: Ein beschreibender und eindeutiger Name, welcher zur Identifizierung des Musters dient.
•Zweck: Eine Beschreibung der Ziele hinter dem Muster und der Grund für die Verwendung.•Ein Szenario, bestehend aus einem Problem und einem Kontext, in welchem dieses Muster verwendet werden kann.
•Lösung/Struktur/ Implementation: Eine grafische Darstellung des Musters. Klassen‐und Interaktionsdiagramme können für diesen Zweck verwendet werden sowie eine Auflistung der nötigen Klassen/Objekte und deren Rollen im Muster
•Vorteile/Nachteile: Die Beschreibung der Ergebnisse, Nebenwirkungen und Kompromisse welche mit dem Muster einhergehen.
•Verwendung: Beispiele von realen Anwendungen des Musters.•Optional sind Pattern Variaten anzugeben sowie Verweise auf andere, verwandte Muster.
211
DAO Pattern
Data Acces Object
Als Beispiel wird hier das DAO Pattern (gemäss der vorher angegeben Schablone) vorgestellt.
212
Pattern Name
Data Access Objekt als Verbindungsstelle zwischen den Business Objekten und der Data Source (Datenbank)
213
Zweck
Ein Data Access Object (DAO) dient als Verbindung mit der Datenquelle
Das DAO dient dazu, alle Zugriffe auf die Datenquelle zu abstrahieren und zu kapseln
Die Datenquelle kann beliebig sein: eine relationale Datanbank, ein externer Dienstleister, ein Repository, ein Business-Service (z.B. via CORBA)
214
Szenario/Problem/Kontext
Die meisten Anwendungen benötigen persistente Daten, d.h. Daten, welche nach Beenden der Applikation erhalten bleiben. Bei Änderung der Persistenz-Schicht soll die Applikation möglichst unverändert bleiben. Es gibt Anwendungen, welche (gleichzeitig) auf Daten zugreifen müssen welche sich auf verschiedenen Systemen befinden. Gewisse Daten werden durch externe Systeme zur Verfügung gestellt: Business-to-Business Integration-Systeme, Kreditkarte Büro-Services, …
215
Lösung/Struktur/Implementation
•Jeder Fachklasse kann ein DAO‐Objekt zugeordnet werden, welches den Datenzugriff für diese Fachklasse kapselt. Das ermöglicht eine direkte Verbindung zwischen Business‐Objekt und DAO‐Objekt, ist sehr effzizient, führt aber zu Abhängigkeiten zwischen Fachklassen und DAO‐Schnittstelle.
216
Lösung/Struktur/Implementation
Das BusinessObject repräsentiert die Client Daten (Fachklassen). Es benötigt die Daten-Quelle um (indirekt) Informationen zu lesen und zu speichern.Das DAO abstrahiert den Zugriff auf die Daten-Quelle und enthält Operationen zum Lesen und Schreiben von Daten.DataSource represäntiert den Daten Zugriff. Dies kann eine DB Schnittstelle, ein File, ein anderes System, …seinTransferObjekt dient zum Transportieren von Daten von und zu der Daten-Quelle.
217
Beispiel: Finde Dozent zu Kurs
Wir nehmen als Beispiel eine Kurs‐Organisation, wo jedem Kurs ein Dozent zugerodnet ist.
218
Lösung/Struktur/Implementation
public class PersonDAO{private static final String DRIVER_CLASS = “ . . . ";private static final StringCONNECTION_URL = “ . . . ";private Connection connection;
public PersonDAO () {
private Connection getConnection(){if (this.connection == null) {try {
// crate new connection
}return connection;
}. . .
219
Lösung/Struktur/Implementation
private static final String query = “select . . .";private PreparedStatement stmt =
connection.prepareStatement(query);
public Person getProfessorOfCourse(Course course) {try {stmt.setInt(1, personId);ResultSet rs = readByIdStmt.executeQuery();
if (rs.next())return null;
elsereturn new Person(rs.getString(...), ...);
} catch(SQLException e) {. . .
}
}
•Jeder Fachklasse kann ein DAO‐Objekt zugeordnet werden, welches den Datenzugriff für diese Fachklasse kapselt. Das ermöglicht eine direkte Verbindung zwischen Business‐Objekt und DAO‐Objekt, ist sehr effzizient, führt aber zu Abhängigkeiten zwischen Fachklassen und DAO‐Schnittstelle.
220
Vorteile
Das DAO versteckt die Implementierungs-Details der Persistenz-Schicht vor seinen Kunden
Transparenter Zugriff. Wenn die zugrunde liegende Datenquelle ihre Implementierung ändert, bleibt die DAO Schnittstelle erhalten, verlangt also von ihren Kunden keinerlei Anpassungen
einfache MigrationDB-Zugriffs-Code (wie z.B. SQL-Anweisungen) ist in das DAO ausgelagert
Verbesserte Lesbarkeit der Business Objekte
221
Nachteile
Die DAOs legen eine zusätliche Schicht zwischen die Business Objekte und die Datenquelle
Mehr Klassen/Objekte, ev. umkopieren von Daten nötig, …
Benutzen einer Factory Klasse führt zu mehr Flexibilität, kompliziert aber das Gesamt-Design und macht die Implementierung aufwändiger
222
Verwendung
Das DAO Pattern wird sinnvollerweise angewandt wenneine Entkoppelung zwischen Business-Schicht und Daten-Quelle sinnvoll erscheint
einfachere Business Schichtverschiedene Daten-Quellen vorhanden sindeine einfache Migration der Daten-Quelle möglich sein soll
223
Varianten
Entkoppelung der Business-Schicht von den einzelnen DAO Klassen durch Benutzen einer DAOFactory (sinnvoll, falls es viele DAO-Klassen gibt)Entkoppelung von der DAOFactory durch eine AbstractFactory, falls verschiedene Datenbanken unterstützt werden sollen.
Erzeugungsmuster
224
Verweis auf andere Muster
Verwandte Muster sindTransfer ObjectEin DAO verwendet Transfer Objekte, um Daten von und zu den Business Objekten zu transportieren.
Factory Method / Abstract FactoryUm die Business Objekte von ihren DAOs zu entkoppeln können Factory-Methoden angewandt werden.Falls zusätzliche Flexibilität zur Erzeugung der DAOs nötig ist, kann das Abstract Factory-Muster eingesetzt werden.
BrokerEine weitere Entkoppelung wird durch das Broker-Pattern erreicht, bei diesem ist der Zugriff auf die Daten-Quelle als Service implementiert.
225
Multitier Architecture
Schichten Architektur
226
Pattern Name
Als Schichtenarchitektur (Multitier Architecture / n-tier Architecture) bezeichnet man ein Architekturmuster, bei der eine Applikation in mehrere eigenständige Schichten (Layers, Module) unterteilt wird.Am bekanntesten ist das OSI-Schichtenmodell (Betriebssystem-Theorie).
Das OSI‐Modell (im englischen: Open Systems Interconnection Reference Model) wurde seit 1979 zur Standardisierung von Datenverkehr zwischen Computeranwendungen entwickelt und ist heute Grundlage für jede Kommunikation zwischen Applikationen auf Computern. Es beschreibt ein Metamodell verschiedener Spezifikationen, welches Herstellern von Soft‐und Hardware erlaubt über fest definierte Schnittstellen miteinander Informationen auszutauschen.
Die Idee der Aufteilung der verschiedenen Aufgaben in verschiedene Schichten wird heute vorallem bei Web‐Applikationen eingesetzt.
227
Zweck
Eine Schichten-Architektur ist ein häufig angewandtes StrukturierungsprinzipDurch eine Schichtenarchitektur wird die Komplexität der Abhängigkeiten innerhalb des Systems reduziert
geringe Kopplung hohe Kohäsion
Schichten verhindern Zyklen im Abhängigkeits-graphenSchichten-Architekturen sind leicht verständlich und gut wartbar
In einem System mit starker Kohäsion ist jede Programmeinheit (hier jede Schicht) verantwortlich für genau eine wohldefinierte Aufgabe oder Einheit.
228
Lösung/Struktur/Implementation
Die einzelne Aufgaben des Software-Systems werden dabei jeweils einer Schicht (tier/layer) zugeordnet. Oftmals werden Schichtenarchitekturen nach der Anzahl der verwendeten Schichten unterteilt, die häufigsten sind die 2 oder 3-Schichten Architektur.Jede Schicht darf auf darunter liegende Schichten zugreifen, nicht aber auf eine darüber liegende.
Durch Aufteilen einer Anwendung in Schichten, wird es möglich, jede dieser Ebenen für sich zu implementieren oder zu ersetzen.
Unter einer Zwei‐Schichten Architektur wird üblicherweise eine Aufteilung in einen leistungsfähigen Datenbankserver und mehrere Clients verstanden, die vom Server bedient werden. Die Verarbeitungslogik wird dann aufgeteilt zwischen Client und Server (z.B. mit Hilfe von stored procedures in der Datenbank).
Eine dreischichtige Architektur besteht aus•Präsentationsschicht: (client tier, Front‐End ) verantwortlich für die Repräsentation der Daten, Benutzereingaben und die Benutzerschnittstelle.
•Logikschicht: (application‐server tier, Business‐Schicht, Middle Tier) beinhaltet alle Verarbeitungsmechanismen. Hier ist die Anwendungslogik vereint.
•Datenhaltungsschicht: (data‐server tier, back end) enthält die Datenbank und ist verantwortlich für das Speichern und Laden von Daten.
Die Begriffe Schicht und Tier werden häufig synonym verwendet. Allerdings ist eine Schicht eher die logische Strukturierung der Software‐Lösung, während ein Tier die physikalische Strukturierung der System‐Infrastruktur darstellt (welcher Teil befindet sich auf welchem Server).
229
Lösung/Struktur/Implementation
Typisches Beispiel: 3-Schichten Web-Applikation
230
Vorteile
Mehr-Schichten Architekturen sind sehr gut skalierbar und weisen einen hohen Grad an Flexibilität auf.Einzelne Schichten sind einfach austauschbar. Bei Veränderung der Schnittstellen/Interfaces sind nur die beiden angrenzenden Schichten betroffen.Schichtenarchitekturen kapseln Maschinen-Abhängigkeiten und sind daher leicht portierbar.
231
Nachteile
Es ist oft schwierig Systeme sauber in Schichten zu strukturieren. Zwischen den Schichten sind zusätzliche Klassen/Interfaces nötigZusätzlicher Overhead durch die Auftrennung in Schichten (Weiterleitung der Meldungen)
Performanz-ProblemeEine (zu) grosse Anzahl Schichten verursacht eine komplizierte Struktur
232
Verwendung
Mehr-Schichten Architekturen sind von Vorteil wenn grosse Skalierbarkeit und Flexibilität der Applikation erfordert ist. der Austauch einzelne Schichten einfach sein soll.Schnittstellen stabil bleiben (Standardschnittstellen)Komponenten und Hardware/Software-Plattformen austauschbar sein sollen es möglich sein soll Komponenten mit komplexer Funktionalität weiter aufzuteilendas System von mehreren Teams mit klaren Verantwortlichkeiten erstellt werden soll
233
Verweis auf andere Muster
Verwandte (Strukturierungs-) Muster sindClient/Server: Services werden von verschiedenen Servern angeboten und von den Clients zur Lösung ihrer Aufgaben benutztModel/View/Controller: Strukturierung in die drei Einheiten Datenmodell (Model), Präsentation (View) und Programmsteuerung (Controller).
234
Visitor Pattern
Besucher Verhaltensmuster
Als Beispiel wird hier das DAO Pattern (gemäss der vorher angegeben Schablone) vorgestellt.
235
Pattern Name
Vistor Pattern (Besucher Entwurfsmuster)
Ein Visitor Objekt kapselt Operationen, welche auf den verschiedenen Elementen einer Objekt-Hierarchie (wie zum Beispiel verschiedene Dokument-Typen) ausgeführt werden müssen.
236
Zweck
Operationen oder Funktionalitäten, welche eine ganze Objekt-Hierarchie (z.B. alle Dokument-Klassen) betreffen, werden mit Vorteil in eine separate Klasse (Visitor) ausgelagert.Dies kann auch für Operationen gelten, welche Informationen aus den Objekten einer Klassenhierarchie sammeln müssen.
237
Szenario/Problem/Kontext
Die Integration verschiedener Hilfs-Operationen (print, normalize, sort, transform, …) in die Klassen einer Objektstruktur ist oft schwierig.
Bei Änderungen oder Erweiterungen zum Beispiel um eine neue Funktionalität müssen alle Klassen verändert/erweitert werden.
Das Besuchermuster lagert die Operationen in externe Besucherklassen aus. Neue Operationen können dadurch ohne Veränderung der betroffenen Elementklassen definiert werden.
238
Lösung/Struktur/Implementation
239
Lösung/Struktur/Implementation
PrintVisitor / SortVisitorimplementiert die visit-Funktion des Interfacedelegiert die auszuführende Aufgabe an eine
interne Operation
Document Interface/Basis Klassedeklariert eine Schnittstelle zum Empfang
eines Besuchers (accept-Methode)KonkretesElement (Order, Bill, Report, …)
implementiert die accept Methode
240
Lösung/Struktur/Implementation
public interface Visitor {public void visit(Order order);public void visit(Bill bill);public void visit(Report report);
}
public class PrintVisitor implements Visitor {
public void visit(Order order) {print(order);
}
private void print(Order order) {// print the order
}. . .
Analog dazu der SortVisitor:
public class SortVisitor implements Visitor {public void visit(Order order) {
sort(order);}public void visit(Bill bill) {
sort(bill);}public void visit(Report report) {
sort(report);}private void sort(Order order) {
// sort the order items . . .}private void sort(Bill bill) {
sort the bill items . . .}private void sort(Report report) {
// sort the report items . . .}
}
241
Lösung/Struktur/Implementation
public class Order implements Document{
public void accept(Visitor visitor) {visitor.visit(this);
}. . .
}
public class Bill implements Document{
public void accept(Visitor visitor) {visitor.visit(this);
}. . .
}
Alle Benutzer des Visitor Patterns sind von einem gemeinsamen Interface (hier Document) abgeleitet.
public interface Document {public void accept(Visitor visitor);
}
242
Vorteile
Neue Operationen können durch die Definition neuer Visitors einfach hinzugefügt werden. Verwandte Operationen werden im Visitor zentral verwaltet und von besucherfremden Operationen getrennt. Das Visitor Pattern kann für beliebige Klassenhierarchien verwendet werden.
243
Nachteile
Für neue konkrete Elemente (z.B. neue Document-Klassen), müssen alle visit-Methoden aller Visitors implementiert werden.
244
Verwendung
Visitor Pattern ist sinnvoll anwendbar wennviele unterschiedliche, nicht verwandte Operationen auf den Objekten einer Klassen-Hierarchie realisiert werden sollensich die Klassen der Hierarchie nicht / nur selten ändernauf der Klassen-Hierarchie häufig neue Operationen integriert werden müssen ein Algorithmus über eine ganze Klassen-Hierarchie verteilt arbeiten, aber zentral verwaltet werden soll
245
Verweis auf andere Muster
Ein verwandtes Muster ist dasKomposit Pattern
Gleichbehandlung aller Elemente einer Baumstruktur (Stückliste)