![Page 1: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/1.jpg)
1
OOADObjekt Orientierte Software Analyse und Design mit UML
Dr. Beatrice Amrhein
Mai‐11
![Page 2: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/2.jpg)
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!
![Page 3: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/3.jpg)
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
![Page 4: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/4.jpg)
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.
![Page 5: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/5.jpg)
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.
![Page 6: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/6.jpg)
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.
![Page 7: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/7.jpg)
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!
![Page 8: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/8.jpg)
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.
![Page 9: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/9.jpg)
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.
![Page 10: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/10.jpg)
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.
![Page 11: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/11.jpg)
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
![Page 12: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/12.jpg)
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?
![Page 13: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/13.jpg)
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.
![Page 14: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/14.jpg)
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, …
![Page 15: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/15.jpg)
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.
![Page 16: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/16.jpg)
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.
![Page 17: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/17.jpg)
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.
![Page 18: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/18.jpg)
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.
![Page 19: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/19.jpg)
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.
![Page 20: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/20.jpg)
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.
![Page 21: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/21.jpg)
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).
![Page 22: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/22.jpg)
22
Astah Einführung
Übung 1
![Page 23: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/23.jpg)
23
2. Use Cases
Anwendungsfälle, Szenarian Anwendungsfall-
Beschreibungen
Vgl. Oestereich Kap 2.1 Seiten 21‐49.
![Page 24: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/24.jpg)
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.
![Page 25: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/25.jpg)
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.
![Page 26: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/26.jpg)
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, …)
![Page 27: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/27.jpg)
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).
![Page 28: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/28.jpg)
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.
![Page 29: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/29.jpg)
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.
![Page 30: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/30.jpg)
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.
![Page 31: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/31.jpg)
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.
![Page 32: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/32.jpg)
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.
![Page 33: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/33.jpg)
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“,
![Page 34: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/34.jpg)
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, …).
![Page 35: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/35.jpg)
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).
![Page 36: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/36.jpg)
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.
![Page 37: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/37.jpg)
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
![Page 38: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/38.jpg)
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.
![Page 39: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/39.jpg)
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.
![Page 40: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/40.jpg)
40
Banken Applikation: Mind-Map
![Page 41: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/41.jpg)
41
Banken Applikation: Use Cases
![Page 42: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/42.jpg)
42
3. Klassenstruktur
Klassendiagramme, Strukturelemente
Vgl. Oestereich Kap 2.2 Seiten 50‐74
![Page 43: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/43.jpg)
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.
![Page 44: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/44.jpg)
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.
![Page 45: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/45.jpg)
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).
![Page 46: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/46.jpg)
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.
![Page 47: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/47.jpg)
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.
![Page 48: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/48.jpg)
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.
![Page 49: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/49.jpg)
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.
![Page 50: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/50.jpg)
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!
![Page 51: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/51.jpg)
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.
![Page 52: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/52.jpg)
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)
![Page 53: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/53.jpg)
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.
![Page 54: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/54.jpg)
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.
![Page 55: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/55.jpg)
55
4. Beziehungen
Beziehungselemente in Struktur-Diagrammen
Vgl. Oestereich Kap 2.3 Seiten 75‐98
![Page 56: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/56.jpg)
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»,…)
![Page 57: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/57.jpg)
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.
![Page 58: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/58.jpg)
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).
![Page 59: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/59.jpg)
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.
![Page 60: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/60.jpg)
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; ... . . . }
}
![Page 61: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/61.jpg)
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; . . .
}
![Page 62: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/62.jpg)
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.
![Page 63: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/63.jpg)
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.
![Page 64: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/64.jpg)
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.
![Page 65: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/65.jpg)
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).
![Page 66: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/66.jpg)
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.
![Page 67: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/67.jpg)
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.
![Page 68: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/68.jpg)
68
Kandidaten für Fachklassen
Als erstes streichen wir alle Substantive gelb an. Dies sind erste, provisorische Kandidaten für Fachklassen.
![Page 69: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/69.jpg)
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.
![Page 70: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/70.jpg)
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.
![Page 71: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/71.jpg)
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, …
![Page 72: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/72.jpg)
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.
![Page 73: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/73.jpg)
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.
![Page 74: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/74.jpg)
74
CRC Cards
Superclass PersonSubclassesResponsibilities Collaborations get Assets Accounts . . .
Customer
Description
AttributesNameAddressAccount List
Customer
A customer of a bank.
Vorderseite
Rückseite
![Page 75: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/75.jpg)
75
Fachklassen Diagramm
Ein erster Entwurf
![Page 76: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/76.jpg)
76
Checkliste
Statisches OOA ModellKlassen und Assoziationen
![Page 77: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/77.jpg)
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
![Page 78: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/78.jpg)
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
![Page 79: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/79.jpg)
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.
![Page 80: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/80.jpg)
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 …)
![Page 81: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/81.jpg)
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.
![Page 82: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/82.jpg)
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.
![Page 83: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/83.jpg)
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).
![Page 84: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/84.jpg)
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.
![Page 85: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/85.jpg)
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.
![Page 86: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/86.jpg)
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).
![Page 87: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/87.jpg)
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.
![Page 88: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/88.jpg)
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.
![Page 89: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/89.jpg)
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.
![Page 90: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/90.jpg)
90
5.1 Objekte
Ausprägungsspezifikation von Klassen und Assoziationen
Vgl. Oestereich Kap 2.41 Seiten 99ff
![Page 91: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/91.jpg)
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.
![Page 92: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/92.jpg)
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.
![Page 93: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/93.jpg)
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.
![Page 94: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/94.jpg)
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).
![Page 95: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/95.jpg)
95
5.2 Komponenten
Komponenten-Diagramm
Vgl. Oestereich Kap 2.4.2 Seiten 100ff
![Page 96: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/96.jpg)
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.
![Page 97: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/97.jpg)
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.
![Page 98: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/98.jpg)
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).
![Page 99: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/99.jpg)
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.
![Page 100: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/100.jpg)
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.
![Page 101: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/101.jpg)
101
5.3 Pakete
Paket Diagramm
Vgl. Oestereich Kap 2.5 Seiten 112‐126
![Page 102: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/102.jpg)
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.
![Page 103: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/103.jpg)
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.
![Page 104: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/104.jpg)
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).
![Page 105: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/105.jpg)
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).
![Page 106: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/106.jpg)
106
6. Aktivitäten
Beschreibung von Abläufen,Aktionen und Kontrollflüssen
Vgl. Oestereich Kap 2.5 Seiten 112‐126
![Page 107: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/107.jpg)
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.
![Page 108: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/108.jpg)
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.
![Page 109: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/109.jpg)
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).
![Page 110: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/110.jpg)
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.
![Page 111: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/111.jpg)
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.
![Page 112: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/112.jpg)
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.
![Page 113: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/113.jpg)
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.
![Page 114: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/114.jpg)
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.
![Page 115: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/115.jpg)
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.
![Page 116: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/116.jpg)
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.
![Page 117: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/117.jpg)
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, …).
![Page 118: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/118.jpg)
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.
![Page 119: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/119.jpg)
119
7. Zustände
Beschreibung von Zuständen, Zustandsübergängen und Ereignissen
Vgl. Oestereich Kap 2.6 Seiten 127‐133
![Page 120: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/120.jpg)
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.
![Page 121: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/121.jpg)
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.
![Page 122: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/122.jpg)
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.
![Page 123: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/123.jpg)
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.
![Page 124: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/124.jpg)
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.
![Page 125: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/125.jpg)
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).
![Page 126: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/126.jpg)
126
Transitions-BeschreibungDie Transitions-Beschreibung
wird notiert durch
ereignis (argumente) [bedingung]/operation(argumente)
![Page 127: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/127.jpg)
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).
![Page 128: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/128.jpg)
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.
![Page 129: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/129.jpg)
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
![Page 130: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/130.jpg)
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).
![Page 131: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/131.jpg)
131
8. Interaktion/ Kommunikation
Nachrichten, Ablauf, Sender, Empfänger
Vgl. Oestereich Kap 2.7 Seiten 134‐147
![Page 132: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/132.jpg)
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.
![Page 133: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/133.jpg)
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.
![Page 134: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/134.jpg)
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.
![Page 135: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/135.jpg)
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.
![Page 136: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/136.jpg)
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.
![Page 137: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/137.jpg)
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.
![Page 138: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/138.jpg)
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.
![Page 139: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/139.jpg)
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.
![Page 140: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/140.jpg)
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.
![Page 141: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/141.jpg)
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.
![Page 142: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/142.jpg)
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.
![Page 143: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/143.jpg)
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.
![Page 144: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/144.jpg)
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.
![Page 145: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/145.jpg)
145
9. GUI Prototyp
Masken und Navigationsstruktur
![Page 146: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/146.jpg)
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.
![Page 147: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/147.jpg)
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.
![Page 148: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/148.jpg)
148
Die benötigten Fenster, welche man daraus ableiten kann:
![Page 149: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/149.jpg)
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.
![Page 150: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/150.jpg)
150
Die nötigen Fenster zum Erfassen eines Neukunden (inkl. Erstellen des ersten Accounts) sind:
![Page 151: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/151.jpg)
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).
![Page 152: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/152.jpg)
152
Bank System
Die nötigen Textfelder zum Erfassen eines Kunden sind:
![Page 153: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/153.jpg)
153
Balsamic Tool
![Page 154: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/154.jpg)
154
10. Analyse Muster
Entwurfsprinzipien
Siehe auch Heide Balzert: Lehrbuch der Objektmodellierung.
![Page 155: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/155.jpg)
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).
![Page 156: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/156.jpg)
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?“
![Page 157: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/157.jpg)
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.
![Page 158: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/158.jpg)
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.
![Page 159: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/159.jpg)
159
Liste
Beispiele
Weitere Listen treten zum Beispiel auf bei Auftrag ‐> Auftragspositionen ‐> EinzelAuftrag
![Page 160: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/160.jpg)
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 )
![Page 161: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/161.jpg)
161
Exemplartyp
Beispiele
![Page 162: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/162.jpg)
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
![Page 163: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/163.jpg)
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.
![Page 164: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/164.jpg)
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.
![Page 165: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/165.jpg)
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.
![Page 166: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/166.jpg)
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.
![Page 167: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/167.jpg)
167
Koordinator
Beispiele
![Page 168: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/168.jpg)
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.
![Page 169: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/169.jpg)
169
Rollen
Beispiele
In einer Abteilung kann abwechselnd jemand anders die Leitung übernehmen. In einem Kurs können die Redner auch Kurs‐Teilnehmer sein.
![Page 170: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/170.jpg)
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).
![Page 171: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/171.jpg)
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).
![Page 172: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/172.jpg)
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.
![Page 173: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/173.jpg)
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.
![Page 174: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/174.jpg)
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.
![Page 175: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/175.jpg)
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.
![Page 176: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/176.jpg)
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.
![Page 177: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/177.jpg)
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.
![Page 178: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/178.jpg)
178
11. DB-Prototyp
Objektrelationale Abbildung
![Page 179: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/179.jpg)
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.
![Page 180: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/180.jpg)
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.
![Page 181: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/181.jpg)
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.
![Page 182: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/182.jpg)
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
![Page 183: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/183.jpg)
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.
![Page 184: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/184.jpg)
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.
![Page 185: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/185.jpg)
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).
![Page 186: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/186.jpg)
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.
![Page 187: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/187.jpg)
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.
![Page 188: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/188.jpg)
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.
![Page 189: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/189.jpg)
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.
![Page 190: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/190.jpg)
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.
![Page 191: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/191.jpg)
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.
![Page 192: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/192.jpg)
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).
![Page 193: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/193.jpg)
193
Objekt-Relationale Abbildung
Abbilden von Klassen und Relationen
![Page 194: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/194.jpg)
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
![Page 195: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/195.jpg)
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
![Page 196: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/196.jpg)
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.
![Page 197: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/197.jpg)
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.
![Page 198: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/198.jpg)
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.
![Page 199: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/199.jpg)
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.
![Page 200: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/200.jpg)
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
![Page 201: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/201.jpg)
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.
![Page 202: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/202.jpg)
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).
![Page 203: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/203.jpg)
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.
![Page 204: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/204.jpg)
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).
![Page 205: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/205.jpg)
205
12. Design Pattern
Entwurfsmuster
![Page 206: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/206.jpg)
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.
![Page 207: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/207.jpg)
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).
![Page 208: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/208.jpg)
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.
![Page 209: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/209.jpg)
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)
![Page 210: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/210.jpg)
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.
![Page 211: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/211.jpg)
211
DAO Pattern
Data Acces Object
Als Beispiel wird hier das DAO Pattern (gemäss der vorher angegeben Schablone) vorgestellt.
![Page 212: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/212.jpg)
212
Pattern Name
Data Access Objekt als Verbindungsstelle zwischen den Business Objekten und der Data Source (Datenbank)
![Page 213: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/213.jpg)
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)
![Page 214: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/214.jpg)
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, …
![Page 215: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/215.jpg)
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.
![Page 216: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/216.jpg)
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.
![Page 217: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/217.jpg)
217
Beispiel: Finde Dozent zu Kurs
Wir nehmen als Beispiel eine Kurs‐Organisation, wo jedem Kurs ein Dozent zugerodnet ist.
![Page 218: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/218.jpg)
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;
}. . .
![Page 219: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/219.jpg)
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.
![Page 220: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/220.jpg)
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
![Page 221: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/221.jpg)
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
![Page 222: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/222.jpg)
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
![Page 223: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/223.jpg)
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
![Page 224: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/224.jpg)
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.
![Page 225: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/225.jpg)
225
Multitier Architecture
Schichten Architektur
![Page 226: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/226.jpg)
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.
![Page 227: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/227.jpg)
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.
![Page 228: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/228.jpg)
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).
![Page 229: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/229.jpg)
229
Lösung/Struktur/Implementation
Typisches Beispiel: 3-Schichten Web-Applikation
![Page 230: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/230.jpg)
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.
![Page 231: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/231.jpg)
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
![Page 232: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/232.jpg)
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
![Page 233: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/233.jpg)
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).
![Page 234: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/234.jpg)
234
Visitor Pattern
Besucher Verhaltensmuster
Als Beispiel wird hier das DAO Pattern (gemäss der vorher angegeben Schablone) vorgestellt.
![Page 235: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/235.jpg)
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.
![Page 236: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/236.jpg)
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.
![Page 237: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/237.jpg)
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.
![Page 238: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/238.jpg)
238
Lösung/Struktur/Implementation
![Page 239: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/239.jpg)
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
![Page 240: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/240.jpg)
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 . . .}
}
![Page 241: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/241.jpg)
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);
}
![Page 242: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/242.jpg)
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.
![Page 243: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/243.jpg)
243
Nachteile
Für neue konkrete Elemente (z.B. neue Document-Klassen), müssen alle visit-Methoden aller Visitors implementiert werden.
![Page 244: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/244.jpg)
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
![Page 245: OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir](https://reader034.vdokument.com/reader034/viewer/2022042708/5a78e21e7f8b9aa17b8e08f8/html5/thumbnails/245.jpg)
245
Verweis auf andere Muster
Ein verwandtes Muster ist dasKomposit Pattern
Gleichbehandlung aller Elemente einer Baumstruktur (Stückliste)