OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und...

1

OOADObjekt Orientierte Software Analyse und Design mit UML

Dr. Beatrice Amrhein

Mai‐11

2

1. Einführung

Grundprinzipien des OOAD

Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir freundlicherweise als Ausgangspunkt für dieses Skript zur Verfügung gestellt hat. Vielen Dank!

3

Kurs Überblick1. Einführung ……………. 2

2. Use Cases …………….23

3. Klassenstruktur …………….42

4. Beziehungen …………….55

5. Weitere Strukturdiagramme …………….90

6. Aktivitäten …………..106

7. Zustände …………..119

8. Interaktion, Kommunikation …………..131

9. GUI Prototyp …………..145

10. Analyse Muster …………..154

11. Datenbank Prototyp …………..178

12. Design Pattern

4

Lernziele

Vorgehensweise in objektorientierter Software Analyse und Design

Projekt-AnalyseDesign (Entwurf)ModellierungDokumentation

Eine saubere Analyse und ein gutes Design sind Grundvoraussetzung für eine erfolgreiche Projekt‐Realisierung. Diese Entwicklungsschritte werden anhand von UML (Unified Modeling Language) vermittelt und geübt. UML ist für den objektorientierten Entwurf konzipiert. Viele Elemente daraus können aber auch für die nicht‐objektorientierte System‐Entwicklung genutzt werden. UML ist heute zum de facto Standard für die Software Analyse‐ und Design‐Phase geworden.

Die Studierenden sollen in diesem Kurs gute Kenntnisse des Software‐Design‐Vorgehens erlangen und in der Lage sein, kleinere Projekte selbständig zu analysieren, zu entwerfen und mit UML zu modellieren und zu dokumentieren; in mittleren und grösseren Projekten sollen sie als kompetente und sachkundige Partner mitwirken können.

5

Lerninhalte

Konzepte der ModularisierungTop-Down / Bottom-Up

Grobanalyse ModellProdukt-KartonUse Cases Szenarien

Objekt Orientierte SyntheseFachklassen DiagrammAktivitäts-, Zustands-, Sequenz-Diagramm, …

Objekt Orientiertes DesignDesign Pattern, Architektur, …

Um diese Ziele zu erreichen behandelt dieser Kurs die OO‐Analyse und den OO‐Design zusammen mit den entsprechenden Werkzeugen der UML wie:

Use‐Case Model und –Beschreibung, Szenarien, Fachklassen‐Diagramm, Objekt‐Diagramm, Sequenz‐Diagramm, Kommunikations‐Diagramm, Aktivitäts‐Diagramm, Zustands‐Diagramm, Paket‐Diagramm, Komponenten‐Diagramm

Weiter werden wir einfache Analyse‐ und Design Pattern, sowie Design‐Heuristiken betrachten, ein erstes GUI‐Design und Datenbank‐Design (Prototyp) entwerfen.

Im Kurs werden wir ein CASE‐Tool benutzen. Es wird darum eine kurze Einführung in ein solches Tool gegeben.

6

SW Entwicklung beginnt im Kopf

Nachdenken ist besser als nachbessernJedes Problem muss einmal durchdacht werden

besser früher als späterAm Anfang sind Änderungen noch einfach machbar

Eine falsche Design- oder Architektur-Entscheidung kann sehr viel Geld kostenEin früher Codier-Beginn erzeugt unnötige Sachzwänge und schlecht wartbaren Code

„Codierer“

Realisierung100%

0 %

Zeit

Implementations‐Beginn

„Designer“

Die Komplexität der zu realisierenden Informatik Projekte hat in den letzen Jahren laufend zugenommen. Bei so aufwändigen Projekten ist es enorm wichtig, die Software‐Entwicklung mit Design Methoden und einer sauberen Dokumentation anzufangen. Andernfalls verteuern sich solche Projekte extrem und die Software ist auch später nicht wartbar.

7

Iterative SW Entwicklung

Projekt Idee

Pflichtenheft (SRS)

Analyse ModellGrob Design

Design PhaseDetail Design

Programmierung

System Test

Beim Top‐Down Modell hat man grob die obigen Phasen. Oft ist es allerdings so, dass wir Fehler im Programm, im Detail‐Design, im Grob‐Design, … finden, was dazu führt, dass wir (in Teilen des Projekts) im Ablauf zurückgeworfen werden.

Je nachdem, wie viele Schritte wir zurück gehen müssen, entstehen höhere Kosten:Einen Schritt zurück (Codierfehler) ‐> wenig AufwandZwei Schritte zurück (Fehler im Detail‐Design) ‐> schon aufwändiger zu beheben da oft mehrere Klassen oder Pakete betroffen sind.

Drei Schritte zurück (Fehler in der Analyse/Grob‐Design) ‐> teuer zu behebenVier Schritte zurück (Fehler in der Spezifikation) ‐> riesiger Aufwand!

8

Top-Down Entwurf

Beginn auf oberster (abstrakter) EbeneGesamt Aufgabenstellung, Anforderungen, …

Schrittweise VerfeinerungProblem aufteilen -> SubsystemeSubsystem aufteilen -> Komponenten. . .

Vereins-Verwaltung

Mitglieder Anlässe Finanzen

Adressverwaltung Terminverwaltung Buchhaltung

. . . . . .

Vorteil: in sich geschlossene Lösung, sauberer Design, klare Struktur, Design Fehler werden früh erkannt

Nachteil: Grosser Initialaufwand, grosse Gefahr am Kunden vorbei zu planen oder Probleme zu lösen, die schon gelöst sind.

9

Bottom-Up Entwurf

Beginn auf unterster EbeneLösen der TeilproblemeSchrittweise Einbindung bereits erstellter TeillösungenNach und nach Zusammensetzen zu einer Gesamtlösung

Vereins-Verwaltung

Mitglieder BeiträgeMitglieder erfassen

Adresse ändern Termine verwalten Buchhaltung

. . . . . . . . .

Vorteil: schnelle Lösung von einzelnen Problemen, sofort einsetzbarNachteil: Kein Gesamtkonzept, Teillösungen passen nicht richtig zusammen, schlecht planbar, schlecht wartbar, Fehler beheben kann extrem teuer sein.

10

Beide Methoden mischen

Requirements erfassenAnalyse PhaseAusgewählte Prototypen entwickeln KundeDetail-Design erst nach Kunden FeedbackPrototyp wegwerfen!Design Variante entscheidenRealisierung

Abhängig von der Komplexität und der Grösse des Projekts muss eine geeignete Mischung der beiden Ansätze gepflegt werden.

Der Prototyp darf auf keinen Fall als Code‐Grundlage für die Realisierung benutzt werden. Er dient bloss dazu, vom Kunden die exakten funktionalen (und nichtfunktionalen) Anforderungen zu erhalten.

11

Projekt Ablauf

Zeit

Projekt‐Idee,

Vor‐Abklärungen

Stakeholder

Projekt‐Entscheid

Projekt‐Ende

Vorstudien Projekt Betrieb

Projekt‐Umriss,

Require‐mentsEngineering

Konzept‐Varianten

Grob‐Design

Prototypen

Dokumentation, Qualitätssicherung

Analyse Design (CASE‐Tool)

Realisierung

Detail‐Design

Programmierung

Daten‐Bereitstellung /

System Umfeld

Testen

EinführungRelease

Nach‐kontrolle

Projekt‐Beginn

Projekt‐Umriss, Requirements Engineering: Umschreibung und Abgrenzung des Problembereichs, Problem Analyse, Pflichtenheft

Konzept‐Varianten, Grob‐Design: Skizzen erster Lösungsideen, Variantenvergleich mit Bewertung, Wirtschaftlichkeitsanalyse, Abschätzen des Projekt‐Umfangs, Projektablauf, Arbeits‐ und Zeitplan, Antrag auf Varianten‐Entscheid

Realisierungsphase: Detail‐Design, Aufgliederung in Teilprobleme (Schichten), System‐Schnittstellen, Spezifikation der Benutzerschnittstelle, Einführungsplan

Programmierung: Implementation und Programm Dokumentation.Testen: System Tests, Performance Tests, Schnittstellen Tests, … falls Änderungen nötig sind Dokumentation nachführen

Einführung: Vorbereitung des Betriebs, Datenübernahme, ev. Schulung oder Parallel‐Betrieb, Formale Abnahme des neuen Systems.

Qualitätssicherung: Reviews, WalkThrough, Prototyping, Modultests, Systemtests, Abnahmetests, Nachkontrolle

12

Analyse Phase

Anforderungen an das Zielsystem ermitteln und beschreibenObjekte bestimmenHauptaufgaben der Objekte bestimmenErstellen eines konsistenten und vollständigen Fachklassen Modells (Struktur und Semantik)GUI Prototyp (Papier oder Mock-up) erstellen

AberKeine Implementierungs-Aspekte oder Entscheide

In der Analysephase geht es nicht um das wie, sondern nur um das was:Welche Aufgaben hat das System genau zu lösen?Was sind die Systemgrenzen?Welche Informationen, Daten, Objekte, … sind relevant?Was haben die Objekte für Eigenschaften?In welchen Beziehungen stehen diese Objekte zueinander?Was haben die Objekte für Aufgaben?

13

Ablauf der Analyse

Systemidee, Zielsetzung

Fact SheetProdukt‐Karton

Stakeholder bestimmen Umfeld, Abgrenzung

AnwendungsfälleAbläufe

NichtfunktionaleAnforderungenerfassen Glossar Fachklassen

bestimmen

Use Case DiagrammeAktivitätsdiagrammeSzenarien, . . .

Klassendiagramme, Paketdiagramme

Analyse Modell

System‐Kontext

SicherheitPerformanceProgrammiersprache. . .

Die Analyse beginnt mit der Systemidee: Was soll das Endprodukt anbieten?Die Systemidee sollte grob (zum Beispiel mit einem Fact Sheet oder einem Produkt‐Karton) skizziert werden.

Als nächstes werden die Stakeholder bestimmt. Alle Personen oder Personengruppen, die am Projekt direkt beteiligt, am Projektablauf interessiert oder von den Auswirkungen der Projektziele oder Projektergebnisse betroffen sind, definiert man als Stakeholder (Kunden, Projektleiter, Mitarbeiter, Geldgeber, …).

Dann muss das Umfeld abgegrenzt werden: Was wird gebaut? Welche bereits vorhandenen Systeme werden vorausgesetzt (Betriebsystem, Druckerei, Kundenverwaltung, Datenbank, …)?

Im Analyse Teil werden nur die Ideen und Abläufe erfasst, keinesfalls aber (technische) Lösungen beschrieben.

14

Produkte der Analyse Phase

Pflichtenheft (SRS)Fachkonzept

Statisches ModellKlassen, Attribute, Assoziationen, Vererbung, Pakete, …

Dynamisches ModellFunktionsabläufe durch Use Cases, Aktivitäten, Szenarien, State‐Event Diagramme, …

Modell-Beschreibungen / Dokumentation

Das Fachkonzept muss so viel Informationen enthalten, dass daraus ein erster Prototyp der Benutzeroberfläche erstellt werden kann. Damit lässt sich das zukünftige System mit dem zukünftigen Benutzer evaluieren. Zusätzlich benötigen wir ein Konzept für die Navigation, Zugriffsrechte, Hilfestellungen für den Benutzer, …

15

Design Phase

In der Design-Phase werden die technischen Details bestimmt:Gesamt-Architektur (Schichten)Design Pattern, Schnittstellen

-> Komponenten, Interfaces, Packages, …Ergonomie -> BenutzeroberflächeDatenhaltung -> DB Design Performance, Verteilung, Wartbarkeit, …

-> Ziel-PlattformProgrammier-Sprache, -Umgebung …

In der Analysephase geht man von einer idealen Umgebung aus, das heisst, wir kümmern uns weder um Probleme bei der Umsetzung, noch um Speicherplatz, weder um Kosten oder Aufwände oder Effizienz.

In der Design‐Phase geht es nun um das „wie“. Sie spezifiziert, wie die Anwendung auf welcher Plattform mit den geforderten technischen Randbedingungen zu realisieren ist. Allerdings sind wir dabei immer noch in der Konzept‐Phase, beginnen also noch nicht mit der Implementation.

In der Design Phase wird die Architektur bestimmt. Die Software Architektur definiert die verschiedenen Komponenten, deren Schnittstellen, Aufgaben und Verhaltensweisen. Es werden die Details wie Programmiersprache und‐ Programmierumgebung, Plattform, Schichtung, Speicherbedarf, nötige Algorithmen, zu benutzende Datenstrukturen und viele andere technische Details festgelegt.

16

Produkte der Design Phase

Software Architektur BeschreibungSchichtenPackagesKomponentenSchnittstellen

GUI Design, DB DesignPerformance AnforderungenPrioritätenliste, Implementations-PlanTest Plan, Einführungs-Plan…

Üblicherweise beginnt man mit einem Grobdesign und verschiedenen Lösungsvarianten. Die verschiedenen Lösungen werden gegeneinander verglichen und bewertet (Prioritäten). Die bevorzugten Varianten werden verfeinert, mit dem Variantenentscheid wird festgelegt, welches Detail Design ausgearbeitet wird.

Das gesamte Projekt muss oft in verschiedene, sinnvolle Teilprojekte (Spezialisten für GUI/Ergonomie oder DB‐Design) aufgeteilt werden.

17

Vorteile des OO SW-Engeneering

Ganzheitliche BeschreibungDaten/InformationenFunktionen/Operationen

Durchgängige Konzepte durch alle PhasenAkteure -> KlassenAktionen -> Operationen

Gleiche Notation für Analyse und DesignKunde, Bestellung, Rechnung, …

Objekt

Die objektorientierte Programmierung ist ein auf dem Konzept der Objektorientierung basierendes Programmierparadigma. Die Grundidee dabei ist, Daten und Funktionen, die auf diese Daten angewandt werden können, möglichst eng in einem sogenannten Objekt zusammenzufassen und nach außen hin zu kapseln, so dass Methoden fremder Objekte diese Daten nicht versehentlich manipulieren können.

Bei der objektorientierten Programmierung werden Objekte ganzheitlich beschrieben, d.h. die Festlegung der Datenstrukturen und der mit den Daten ausgeführten Aktionen erfolgt in einem.

Das objektorientierte Software‐Engineering hat den zusätzlichen Vorteil, dass durch alle Phasen die gleiche Notation und die gleichen Konzepte (Klassen, Methoden, Schnittstellen, Vererbung,…) verwendet werden kann.

18

Einfaches Abbilden von Objekten der realen WeltModularisierung in „handliche“ EinzelteileEinfache Schnittstellen zwischen den KomponentenWiederverwendbarkeitErweiterbarkeitAustauschbarkeit

Vorteile des OO SW-Engeneering

Die wichtigsten Vorteile der objektorientierten Programmierung sind:Objekte der realen Welt lassen sich (relativ) einfach in Klassen abbilden.Die Aufspaltung von komplexen Software‐Systemen in kleine, einfache, in sich geschlossene Einzelteile (Modularisierung)

einfache und klar verständliche Schnittstellen zwischen den einzelnen Komponenten,geringerer Programmieraufwand durch die Wiederverwendung von Elementen (z.B. auch durch Vererbung).

Je klarer und einfacher die Objekte (Klassen) und deren Schnittstellen gewählt werden, desto besser werden diese Ziele erreicht.

19

OO Design Prinzipien

Abstraktion, GeheimnisprinzipDatenkapselung

Polymorphie„gleiche“ Operation kann unterschiedliche Ausprägung haben.

Vererbung/Erweiterung/EinschränkungPersistenz/Lebenszeit

Objekte „überleben“ so lange sie gebraucht werden

ModularisierungKomponenten zu einem Ganzen zusammensetzen

Abstraktion Jedes Objekt im System ist ein abstraktes Modell eines Akteurs. Es kann Aufträge erledigen, seinen Zustand berichten und ändern und mit den anderen Objekten im System kommunizieren. Es gibt aber nicht bekannt, wie diese Fähigkeiten implementiert sind.

Datenkapselung Auf die interne Datenstruktur kann nicht direkt zugegriffen werden, sondern nur über definierte Schnittstellen. Objekte können den internen Zustand anderer Objekte nicht in unerwarteter Weise lesen oder ändern. Ein Objekt hat eine Schnittstelle, die darüber bestimmt, auf welche Weise mit dem Objekt interagiert werden kann. Dies verhindert das Umgehen von Invarianten des Programms.

Polymorphie Verschiedene Objekte können auf die gleiche Nachricht unterschiedlich reagieren.

Vererbung Eine abgeleitete Klasse besitzt die Methoden und Attribute der Basisklasse ebenfalls. Neue Arten von Objekten können auf der Basis bereits vorhandener Objektdefinitionen festgelegt werden. Es können neue Bestandteile hinzugenommen werden oder vorhandene überlagert (überschrieben) werden.

Persistenz Objektvariablen existieren, solange die Objekte vorhanden sind. Sie verfallen nicht nach Abarbeitung einer Methode.

Modularisierung Einzelne Komponenten lassen sich unterschiedlich zu einem Ganzenkombinieren, wenn sie klare Schnittstellen definieren (und einhalten) Kompatibilität.

20


Single Responsibility PrinzipKlare Verantwortlichkeit

Self-Documentation PrinzipSprechende Namen, dokumentierter Code

Uniform Access Prinzipgetter / setter Methoden

Open-Closed PrinzipFixe Schnittstellen, Unterschiedliche Ausführungen

Substitution PrinzipKonsistente Vererbung

Single Responsibility: Jede Klasse hat nur eine Verantwortung ‐> besser dokumentierbar, besser wartbar.

Self‐Documentation: Die Namen der Klassen, Operationen, … sind selbsterklärend. Die Dokumentation befindet sich im Programmcode ‐> Javadoc, Doxygen

Uniform Access: Durchgängige Notation der Zugriffsmethoden ‐> setter/getterOpen‐Closed: Erweiterungen von Komponenten, Klasse, Operationen müssen möglich sein, ohne dass die Schnittstelle verändert werden muss ‐> Wartbarkeit.

Substitution: Statt der Basisklasse kann jederzeit ein Objekt der abgeleiteten Klasse verwendet werden ‐> konsistente Vererbung auch bei Polymorphie.

21


Interface Segregation PrinzipAbhängigkeiten knapp halten

Persistence Closure PrinzipPersistieren des ganzen Objekt Zustands

Acyclic Dependencies PrinzipMöglichst keine zyklischen Abhängigkeiten

Gesetz von DemeterObjekte kommunizieren vor allem mit ihren Nachbarn

Design by ContractKlare, verifizierbare Schnittstellen, Vorbedingungen, Nachbedingungen, Invarianten.

Interface Segregation: Interfaces sollten so aufgeteilt werden, dass sie den Bedürfnissen der Clients (der Anwendung) entsprechen ‐> keine unnötigen Abhängigkeiten

Persistence Closure: Objekte werden mit all ihren Abhängigkeiten (Gesamt‐Zustand) persistiert ‐> späteres Wiedereinlesen stellt den gleichen Zustand her.

Acyclic Dependencies: Keine Zyklen in der Abhängigkeits‐Kette von Klassen, Packages, Komponenten.

Gesetz von Demeter: Objekte kommunizieren in erster Linie mit Objekten in ihrer Umgebung ‐> Entkoppelung, bessere Wartbarkeit, starke Bindung im Nahbereich, schwache Bindung über Komponenten‐/Pakete‐/Schichten‐Grenzen hinweg.

Design by Contract: Klare, verifizierbare Schnittstellen, die eingehalten werden müssen. Komponenten und Operationen erfüllen exakt die Spezifikation (Vorbedingungen, Nachbedingungen, Invarianten).

22

Astah Einführung

Übung 1

23

2. Use Cases

Anwendungsfälle, Szenarian Anwendungsfall-

Beschreibungen

Vgl. Oestereich Kap 2.1 Seiten 21‐49.

24

Definition

Ein Anwendungsfall (Use Case) beschreibt einen einzelnen Arbeitsgang eines oder mehrerer Akteure mit einem System aus der Sicht des Anwendershat als Namen möglichst ein aktives Verb, welches die Tätigkeit beschreibtwird mit Hilfe einer Ellipse grafisch dargestellt.

Ein Anwendungsfall ist eine zeitlich ununterbrochene Interaktion (ein Arbeitsschritt).Anwendungsfall Namen bestehen aus einem Subjekt und einem Verb wie zum Beispiel „Daten erfassen“, „Adresse ändern“, „Auto reservieren“, „Konto löschen“, … (oder Verb/Subjekt in anderen Sprachen: „change address“).

Häufig sind Anwendungsfälle die computerunterstützten Teile von Geschäftsprozessen.

25

Verwendung

Use Case Diagramme werden sehr früh im Analyse Prozess verwendet umdie verschiedenen Benutzerrollen/Anwender und deren Aufgaben (Rechte) grob festzulegenmit dem Kunden die (Haupt-)Aufgaben des Systems zu skizzierenmit dem Kunden die Systemgrenzen zu definieren

Schnittstellenwas ist nicht Aufgabe des Systems

Es werden mit dem Use Case Diagramm aber noch keine Abläufe und kein Verhalten beschrieben.

26

Use Case Diagramm

stellt Beziehungen zwischen Akteuren und Anwendungsfällen aus Sicht der Akteure darbeschreibt grob, was das System leisten sollbeschreibt einen Ablauf, ist aber keine Ablaufbeschreibung

es wird keine Ablaufreihenfolge definiertist vorwiegend ein Hilfsmittel zur Anforderungsermittlung mit dem Anwender

dient nicht der Verhaltensbeschreibung oder dem Systemdesign

Man spricht auch von Anwendungsfall Diagramm.Die einzelnen Anwendungsfälle können später noch verfeinert und aufgegliedert werden.Kunde erfassen ‐‐> Name erfassen, Geburtsdatum erfassen, Rechnungs‐Adresse erfassen,

Liefer‐Adresse erfassen, …Das Anwendungsfall Diagramm beschreibt nicht, wie die Umsetzung oder Realisierung dieser Anwendungsfälle geschehen soll.

Zur Ablaufbeschreibung von Anwendungsfällen dienen Verhaltens‐ oder Interaktionsdiagramme (Aktivitätsdiagramm, Zustandsdiagramm, Sequenzdiagramm, …)

27

AkteureAkteure sind beteiligte Personen oder Systeme

Anwender, Kunde, Mieter, Uhr, System, …Man unterscheidet

Primäre Akteuredie eigentlichen Benutzer des Systems

Sekundäre Akteure welche das System überwachen oder warten oder den Primärakteur bei seiner Arbeit unterstützen

Akteure werden mit ihrer Rolle beschriftet

PrintingSystem

Ein Akteur (actor, stake holder) ist eine an verschiedenen Anwendungsfällen beteiligte aber außerhalb des zu realisierenden Systems agierende Einheit.

Normalerweise ist ein Akteur ein Mensch oder ein technisches System, ev. auch ein Ereignis.Akteure werden nicht personifiziert, sondern nur ihre Rolle ist relevant.Akteure können untereinander Generalisierungs‐ oder Spezialisierungs‐Beziehungen haben.

Akteure werden normalerweise als Strichmännchen, Zeitereignis‐Akteure manchmal auch als Uhr, Fremdsystem Akteure als Würfel oder als Box gezeichnet.

Akteure können eine Multiplizität haben. Diese gibt an, wie viele Akteure der angegebenen Rolle am Anwendungsfall beteiligt sein müssen (Defaultwert: 1).

Auf der Seite des Anwendungsfalls gibt die Multiplizität an, wie oft dieser Anwendungsfall gleichzeitig ausgeführt werden darf (Defaultwert: 0..1).

28

Typen von Anwendungsfällen

GeschäftsanwendungsfallFerien planen, Film schauen, Meeting organisieren, …

SystemanwendungsfallKunden, Bestellungen, Informationsmaterial, Kosten, … erfassen, ändern, löschen, berechnen, …

Sekundärer AnwendungsfallLagerbestand prüfen, Rechnungs-Ausstände auflisten, Einloggen

Ein Geschäftsanwendungsfall beschreibt einen Anwendungsfall in abstrakter fachlicher Form aus Sicht des Anwenders. Aus einem fachlichen Geschäftsanwendungsfall (Ferien planen) können sich mehrere konkrete Systemanwendungsfälle ergeben (Hotelzimmer reservieren, Flug buchen, Informationsmaterial bereitstellen, …)

Der Systemanwendungsfall bündelt alle möglichen Fälle (Szenarien), die eintreten können, wenn ein Akteur versucht, ein bestimmtes Ziel zu erreichen (Kundendaten erfassen, Konto eröffnen, Bestellung bearbeiten, …). Man spricht hier oft auch von einem primären Anwendungsfall.

Sekundäre Anwendungsfälle sind normalerweise Teil eines anderen Systemanwendungsfalls und haben keine eigenes unabhängiges Ziel (Hilfs‐Aufgaben).

Der Anwendungsfall beschreibt nur sehr grob, was beim Versuch der Zielerreichung passieren kann und abstrahiert von konkreten technischen Lösungen.

Das Ergebnis des Anwendungsfalls kann ein Erfolg oder ein Fehlschlag/Abbruch sein.

29

Vererbung

Beispiele Konto eröffnen Sparkonto / Privatkonto eröffnenKundendaten ändern Adresse, Kundenstatus ändern

Die Basis Anwendungsfälle „Konto eröffnen“ und „Kundendaten ändern“ werden als abstrakter Anwendungsfall bezeichnet.

Die Anwendungsfälle „Sparkonto eröffnen“, „Privatkonto eröffnen“, … sind dann die konkreten Spezialisierungen oder Realisierungen.

30

Include Beziehung

Ein Anwendungsfall kann (logischer) Teil eines anderen Anwendungsfalls seinDie Pfeilrichtung zeigt auf den enthaltenen Anwendungsfall, die Beziehung wird mit «include» bezeichnet.

Der enthaltene Anwendungsfall ist oft ein sekundärer Anwendungsfall (vgl. Beispiel oben). Sekundäre Anwendungsfälle werden nur indirekt, durch einen primären Anwendungs

Ein Systemanwendungsfall kann aber ebenfalls in einer Include Beziehung zu einem anderen Anwendungsfall stehen Beispiele: Zinsen werden jährlich ausbezahlt, aber auch beim Löschen eines Kontos, eine Adresse wird erfasst beim Erzeugen eines neuen Kunden oder ev. auch später als Zweitadresse.

31

Extend Beziehung

Diese drückt aus, dass ein Anwendungsfall unter gewissen Bedingungen durch einen anderen Anwendungsfall erweitert wirdDie Pfeilrichtung zeigt auf die zu erweiternde Basisanwendung und wird mit «extend»bezeichnet

Die Erweiterung ist von einer Bedingung abhängig, diese muss angegeben werden. Die Bedingung (Erweiterungspunkt, extension point) wird als Notiz neben den Anwendungsfall geschrieben.

Vorsicht! Die umgekehrte Pfeilrichtung im Diagramm gibt oft zu Fehlern Anlass.

32

Assoziation

Eine Assoziation beschreibt eine Relation zwischen dem Akteur und einem AnwendungsfallDie Multiplizität beim Akteur gibt an, wie viele Akteure beteiligt sein müssen oder könnenDie Multiplizität beim Anwendungsfall gibt an, wie oft dieser vom Akteur gleichzeitig ausgeführt werden darf

Fehlen die Multiplizitätsangaben, geht man von den Default‐Werten 1 beim Akteur und 0..1 beim Anwendungsfall aus.

33

Checkliste für Use Cases

Ist mindestens ein Akteur beteiligt?Repräsentiert der Akteur eine klare Rolle oder ein klar definiertes technisches System?Enthält der Name des Anwendungsfalls ein Substantiv und ein VerbIst der Name des Anwendungsfalls aus Sicht des Systems formuliert?Sind die Abhängigkeiten (Include, Extend) zu anderen Anwendungsfällen korrekt?Ist die Anwendungsfall Beschreibung vollständig?

Jeder Anwendungsfall braucht (direkt oder indirekt) einen Akteur, welchen den Anwendungsfall anstösst.

Ein Akteur darf nicht eine konkrete Person sein, sondern muss eine Rolle oder ein System repräsentieren (Customer, Consultant, Assistant, Accountant, …).

Der Name des Anwendungsfalls ist von der Art „Verb Subjekt“, also zum Beispiel „create Account“, „send Message“, „print Report“, …

Der Name des Anwendungsfalls muss so formuliert sein, dass man ihn im der Ablaufbeschreibung direkt benutzen kann: „The system has to create an account, send a message, and print a report“,

34

Use-Case Beschreibung

Eine Anwendungsfall Beschreibung besteht ausName des Anwendungsfalls KurzbeschreibungAkteurVorbedingung, AuslöserNachbedingung, Resultat, InvariantenParameter (Eingabedaten)Essenzieller Ablauf, Ausnahmen, FehlerOffene PunkteVersionierung (Autor, Datum, Status, …)Sonstiges, Bemerkungen

Diese Auflistung ist nicht vollständig und nicht Teil von UML. Es bewährt sich, bei der Anwendungsfall Beschreibung gewisse Formalismen einzuhalten, damit nichts Wichtiges vergessen geht.

•Ein Auslöser ist eine äusseres Ereignis, das den Anwendungsfall auslöst (z.B. ein Kunde möchte Geld anlegen).

•Eine Vorbedingung beschreibt den Zustand des Systems, bevor der Anwendungsfall eintritt (eintreten kann).

•Nachbedingung, Resultat (Ergebnis) ist das, was dem Akteur geliefert wird (z.B. ein neues Konto wurde eröffnet und eine Kontonummer erzeugt).

•Eingabedaten wären dabei Kundennummer, Kontotyp, …•Essentielle Schritte sind die einzelnen Ablaufschritte, welche eventuell genauer mit Hilfe eines Verhaltensdiagramms (Zustandsdiagramm, Aktivitätsdiagramm, …) beschrieben werden ( Verweis auf entsprechendes Diagramm).

Weitere mögliche Angaben sind:•Invarianten (Bedingungen, welche stets erfüllt sind/sein müssen).•Nicht funktionale Anforderungen (Plattform Voraussetzungen, qualitative/quantitative Aussagen, Antwortzeiten, Prioritäten, Häufigkeitsschätzungen, Benutzbarkeit, Änderbarkeit, …).

•Ausnahmen, Fehlersituationen (Anwenderfehler, fachliche Fehler, z.B. fehlende Berechtigung, Eingabedaten fehlen, …).

35

Beispiel: Use-Case Beschreibung

Ein Use‐Case Diagramm enthält zwar rudimentäres Wissen über das System und seine Akteure. Allerdings beschränkt sich die Information bei Use‐Case Diagrammen hauptsächlich auf den Namen des Use‐Case und die beteiligten Akteure.

Für detaillierte Informationen über die Use‐Cases benutzt man die Use‐Case Beschreibungen. Diese werden üblicherweise in einer Tabelle aufgelistet. Der Inhalt der Use‐Case Beschreibung, also die auszufüllenden Felder in der Tabelle können dabei (je nach gewünschtem/nötigem Detaillierungsgrad) variieren.

Im diesem Beispiel sind die essentiellen Inhalte einer Use‐Case Beschreibung enthalten. Es zeigt das empfohlene Minimum an Informationen in einer Use‐Case Beschreibung (Vgl Oestereich p. 30‐34).

36

Use-Case Szenarien

Ein Szenario beschreibt eine Abfolge von Schritten, die vom Use Case zu durchlaufen sind.Normalabläufe zeigen auf, wie der Anwendungsfall "normalerweise" (erfolgreich) abläuft.Alternativabläufe zeigen "andere" Wege zum Ziel auf, als dies im Normalablauf dargestellt wird.Ausnahmeabläufe führen nicht zum Ziel, z.B. infolge eines "fachlichen Fehlers" oder bei einem Abbruch durch den Akteur.

Als Test werden für jeden Anwendungsfall sogenannte Szenarien erstellt. In diesen wird der Vorgang detailliert beschrieben, und zwar so wie der Benutzer ihn am Ende an seinem Rechner durchführen wird (Benutzer‐Interaktion).

Es kann für einen Anwendungsfall mehrere Szenarien geben. Szenarien dienen dazu, den Anwendungsfall detailliert und aus verschiedenen Perspektiven zu betrachten. So wird verhindert, dass wichtige Funktionen des Systems übersehen werden.

Aus den Szenarien können auch direkt die Test‐Fälle für diesen Use Case abgeleitet werden.

37

Use-Case SzenarienJohn möchte das Buch „Under the Bridge“ in der

Bibliothek ausleihen

Actor Precondition Post condition Result

Librarian Mary

Mary is logged in“Under the bridge" has state "ok".

Book has state "borrowed", Mary lends book to John.

success

Librarian Mary

Mary is logged in, John is no customer

Navigate to "Create new customer account".

detour

Librarian Mary

Mary is logged in, "Under the bridge" has state "borrowed".

Error message: Book can not be borrowed.

fail

Librarian Mary

Mary is not logged inError message: User is not logged in.

fail

38

Beispiel: Banken Applikation

Requirements(1)Eine Person wird Kunde, sobald der Bankangestellte

für sie ein Konto eröffnet hat. Für jeden neuen Kunden erfasst der Angestellte

dessen Name, Geburtstag, Adresse und das Datum der ersten Kontoeröffnung. Bei der Eröffnung des ersten Kontos werden darauf automatisch 10 CHF gut geschrieben.

Es gibt Privat-, Spar-, Festgeld-, … Konten. Jedes Konto hat eine eindeutige Kontonummer. Privatkonten dürfen bis zu einem festen Betrag überzogen werden. Für jeden Kontotyp wird ein Habenzins, für Privatkonten auch ein Sollzins festgelegt.

39


Requirements(2)Ein Kunde kann beliebig viele Konten haben,

Beträge einzahlen, abheben oder überweisen. Es werden Zinsen gutgeschrieben und bei

Privatkonten Überziehungszinsen abgebucht. Um die Zinsen zu berechnen, muss für jede Kontobewegung das Datum und der Betrag notiert werden. Die Gutschrift/Abzug der Zinsen erfolgt bei den Sparkonten jährlich und bei den Privatkonten quartalsweise.

Ein Kunde kann jedes seiner Konten wieder auflösen. Bei der Auflösung des letzten Kontos hört er auf, Kunde zu sein.

40

Banken Applikation: Mind-Map

41

Banken Applikation: Use Cases

42

3. Klassenstruktur

Klassendiagramme, Strukturelemente

Vgl. Oestereich Kap 2.2 Seiten 50‐74

43

Definition

Ein Klassenmodell zeigt die statische Struktur des Systemsbeschreibt, welche Klassen existierenin welchen Beziehungen diese Klassen zueinander stehen

Ein Klassenmodell beschreibt die statische Struktur eines Systems. Es besteht aus Klassen mit Attributen und Operationen, die zueinander auf verschiedene Arten in Beziehung stehen können. Das Klassenmodell wird durch ein oder durch mehrere Klassendiagramme beschrieben, welche diese Klassen und ihre Beziehungen zueinander darstellen.

44

Klassendiagramm

Ist ein UML Strukturdiagramm zur graphischen Darstellung eines Klassenmodells

deren Klassendie benötigten Schnittstellendie Beziehungen untereinander

Zusätzlich erhält jede Klasse eine kurze Beschreibung (20‐30 Wörter), welche den Sinn (den Aufgabenbereich) der Klasse beschreibt.

45

Verwendung

Das Klassendiagrammstellt die statische Struktur eines Systems dar wird zum Beispiel zum Darstellen von Geschäfts-oder Fachklassen verwendetbildet die Struktur eines Lösungskonzepts abkann in allen Phasen der Software Entwicklung eingesetzt werden

Klassendiagramme können als generelles, konzeptuelles Modell der Applikation verwendet werden. In einer späteren Phase können sie aber auch für die detaillierte Modellierung zum konkreten Erzeugen von Programmcode benutzt werden.

Das Grob‐Klassendiagramm enthält nur die Klassen (ohne Attribute und Operationen) und die Beziehungen dazwischen.

Statt von Geschäfts‐ oder Fachklassen spricht man oft auch von Domänen Modell (Domain Model / Business Model).

46

Klasse

Eine Klasse beschreibt die Struktur und das Verhalten der Objekte, welche aus ihr erzeugt werden können.Die Klasse hat einen Namen und besteht aus Attributen und Operationen.Klassen werden durch Rechtecke dargestellt

Eine Klasse ist ein Datentyp, d.h. die Beschreibung gleichartiger Objekte. Gleichartig heisst dabei, die Objekte haben die gleichen Attribute und Methoden (Objekte können aber verschiedene Zustände haben). Diese Objekte werden von der entsprechenden Klasse erzeugt (instanziiert).

Zusätzlich kann eine Klasse (bzw. ihre Attribute und Operationen) auch Zusicherungen(Bedingungen, Regeln), Merkmale (z.B. private, abstract, …) oder Stereotypen(<<create>>, <<instantiate>>, <<delete>>, …) enthalten.

Im obersten Teil stehen zuerst allfällige Klassen‐Stereotypen (<<interface>>, <<enum>>, … ) und darunter der Klassenname (ev. inklusive dem Paketnamen). Namen von Klassen beginnen normalerweise mit Grossbuchstaben. Die Namen von abstrakten Klassen (z. B. Person ) werden kursiv geschrieben.

Im zweiten Teil stehen die Attribute der Klasse mit ihrem Namen, ihrem Typ, der Sichtbarkeit (siehe Folien 51 und 52).

Im dritten Teil stehen dann die Operationen der Klasse mit ihrem Namen, ihren Parametern, der Sichtbarkeit.

Zusicherungen an Klassen können durch Notizenfelder an die Klasse notiert werden.

47

Verantwortlichkeit

Jede Klasse hat eine Aufgabe, einen Zweck oder eine Verantwortlichkeit

Bevor eine Klasse modelliert wird ist es sinnvoll, die Verantwortlichkeit der Klasse zu definieren.

Eine Klasse sollte möglichst nur für einen(!) fachlichen Zusammenhang verantwortlich sein. Andernfalls entstehen viele Abhängigkeiten und ein instabiles Design. Klassen, für welche der Zweck nicht mit wenigen Worten (20‐30) erklärbar ist, sind oft ein Hinweis für einen fehlerhaften Design.

48

Objekt

Ein Objekt ist ein Exemplar (eine Instanz) einer Klassealso eine im laufenden System konkret vorhandene Einheitwird durch ein Rechteck dargestelltenthält keine Operationen

Ein Objekt ist ein konkretes Exemplar einer Klasse (hier ein konkreter Customer mit Namen Peter Muster). Ein Objekt hat immer einen aktuellen Zustand. Dieser besteht aus der Belegung der Attribute durch konkrete Werte.

Die Operationen gehören zur Klasse, werden darum im Objekt nicht aufgeführt.

49

Abstrakte Klasse

Eine abstrakte Klasse wird wie eine normale Klasse dargestellt, ausser dass der Klassenname kursiv gesetzt wird.Abstrakte Klassen können selber bereits Operationen und Attribute enthalten, welche dann an die abgeleiteten Klassen vererbt werden.

Aus abstrakten Klassen können keine Objekte erzeugt werden. Alle Objekte sind Instanzen von den konkreten (daraus abgeleiteten) Klassen.

Statt des kursiven Klassennamens kann der Klassennamen auch mit {abstract} ergänzt werden.

Oft enthalten abstrakte Klassen „leere“ Operationsdefinitionen, welche dann in den abgeleiteten Klassen realisiert werden müssen.

50

Parametrisierbare Klasse

Eine parametrisierbare Klasse ist eine Art Schablone/Template, mit welcher echte (nicht-generische) Klassen erzeugt werden könnenDurch die Angabe der konkreten Parameterwerte (Binding) entstehen dann die daraus hergeleiteten Klassen

In Java ist dieses Konstrukt unter dem Begriff „Generics“ bekannt. Beispiele von parametrieserbaren Klassen sind Arrays, Listen, Maps, Hashtables, Trees, Sets, Queues, …

Das Konstrukt der Parametrisierbaren Klassen darf nicht mit der Vererbung (Ableitung) verwechselt werden!

51

Attribut

Jedes Attribut hateinen Nameneinen Typ (int, String, Account, …)eine Sichtbarkeitsangabe +public, #protected, -private, ~package

ev. Zusicherungen z.B. eingeschränkter Wertebereich

Klassenattribute gehören allen Objekten dieser Klasse gemeinsam

Attribut‐Namen beginnen eher mit Kleinbuchstaben.In C# oder Java werden Klassenattribute als „static“ Attribute bezeichnet.

public static float interestRate;Abgeleitete oder berechnete Attribute werden im Objekt nicht physisch realisiert, sondern bei Bedarf automatisch berechnet. Sie werden durch einen Schrägstrich /abgelAttribut bezeichnet. Das Konstrukt der abgeleiteten Attribute ist eigentlich überflüssig, da diese sowieso durch eine Operation implementiert werden müssen.

52

Operation

Jede Operation hateinen Nameneine Signatur Argumente und Rückgabewert

eine Sichtbarkeitsangabe +public, #protected, -private, ~package

Operationen können mehrfach definiert (überladen) sein.

Statische Operationen sind globale Prozeduren und damit unabhängig vom Objekt, welches sie aufruft.

Operationen sind Dienstleistungen die von einem Objekt ausgeführt werden können. Sie werden auch Methoden, Services, Prozeduren, Funktionen oder Nachrichten genannt.

Die Argumente (Operations‐Parameter) können fehlen. Die Argumente können mit den Schlüsselwörtern in, out, und inout gekennzeichnet werden, abhängig davon, ob die Argumente nur gelesen, nur zurückgegeben oder gelesen und zurückgegeben werden.

Der Rückgabewert (Resultat, Ergebnis) kann ebenfalls fehlen (void‐Funktion).Der Name der Operation beginnt mit einem Kleinbuchstaben, ebenso die Namen der Argumente.

Operationen können (in abstrakten Klassen oder Interfaces) als {abstract} bezeichnet werden, um anzugeben, dass diese Operation hier nicht implementiert wird.

#printReport() : void {abstract} protected abstract void printReport();Statische Operationen werden als solche deklariert

+getTopBalance() : float public static float getTopBalance()Operationen können mehrfach definiert sein (überladen). Sie unterscheiden sich dann (nur) durch ihre Argumente. Der Typ des Rückgabewertes ist für alle der gleiche.

public boolean checkLimit(){ … }public boolean checkLimit( float amount ){ … }

Für Operationen können Zusicherungen (Bedingungen) definiert werden (z.B. amount > 0)

53

Interface

Ein Interface (Schnittstelle) definiert das (oder einen Teil des) extern sichtbare Verhalten einer Klasse oder Komponentedeklariert die nötigen Operationenwird mit dem Schlüsselwort «interface»gekennzeichnet

Ein Interface (eine Schnittstelle) ist eine Sammlung von Operations‐ (und ev Attribut‐)Definitionen, die eine kohärente Verhaltensweise definiert. Die im Interface deklarierten Operationen sind abstrakt.

Ein Interface wird durch eine Klasse oder eine Komponente realisiert. Dazu muss die realisierende Klasse (Komponente) alle Operationen des Interfaces implementieren. Die realisierende Klasse kann weitere Operationen und Attribute enthalten.

Jede Klasse oder Komponente kann ein oder mehrere Schnittstellen implementieren.Jedes Interface kann durch eine oder mehrere Klassen oder Komponenten realisiert werden.

Ein Interface definiert eine Art „Vertrag“, welche von allen realisierenden Klassen/Komponenten erfüllt werden muss.

54

Angebotenes/Benötigtes Interface

Ein angebotenes Interface wird durch eine Klasse oder Komponente realisiert und mit einem Kreis gezeichnet.

Ein benötigtes Interface ist für die Klasse oder Komponente erforderlich, um seine Funktion korrekt wahrzunehmen.

Die Klasse TemperaturSensor implementiert das Interface Sensor (also die darin verlangten Operationen).

Die Klasse AirCondition braucht einen Sensor, um richtig funktionieren können und benutzt dazu die angebotenen Dienste der Klasse TemperaturSensor.

Falls die Klasse TemperaturSensor weitere Dienste anbietet, werden diese von AirCondition nicht benutzt.

55

4. Beziehungen

Beziehungselemente in Struktur-Diagrammen


56

Definition

Eine Beziehung ist eine gegenseitige Verbindung.

Die drei wichtigsten Beziehungsarten in der objekt-orientierten Modellierung sindGeneralisierung (Vererbung)Assoziation (Aggregation, Komposition)Abhängigkeit («use», «call», «derive»,…)

57

Verwendung

Nachdem im Klassendiagramm die verschiedenen Typen (Klassen) definiert sind, ist der nächste Schritt die Beschreibung der Beziehungen dieser Klassen untereinander.

In allen Strukturdiagrammen stehen gewisse Klassen (Classifier) in Beziehung zueinander.

Die verschiedenen Beziehungselemente helfen dabei, die verschiedenen Arten von Beziehungen zu unterscheiden.

58

Generalisierung

Die Generalisierunggliedert Eigenschaften in einer hierarchischen Ordnung allgemeinere Basisklasse

spezialisierte abgeleitete Klasse

vererbt die Eigenschaften der Basisklasse an die abgeleitete Klasse

Generalisierung (Vererbung, Spezialisierung) ist ein Abstraktionsprinzip zur hierarchischen Strukturierung der Semantik eines Modells.

Die abgeleiteten Klassen (Unterklassen) erben alle Eigenschaften (Attribute, Operationen) der Basisklasse (Oberklasse). Diese werden aber im Diagramm in der abgeleiteten Klasse nicht wiederholt.

Die abgeleiteten Klassen können die Operationen der Basisklasse überschreiben oder erweitern (spezialisieren), aber nicht eliminieren oder unterdrücken.

In UML ist auch die Mehrfachvererbung vorgesehen. Diese wird allerdings in einigen modernen Sprachen nicht unterstützt und schafft viele Probleme.

Generalisierung gibt es auch unter Interfaces (Schnittstellen), wenn ein Interface eine Spezialisierung eines anderen Interfaces ist (z.B. das Java List Interface ist abgeleitet vom Collection Interface und dieses wiederum vom Iterable Interface).

59

Verwendung der Generalisierung

Subtyp-Vererbung

Vererbung zur Erweiterung

Vererbung zur Unterstützung allgemeiner Fähigkeiten

Vererbung von Standardimplementierungen

Subtyp‐Vererbung: Bei dieser ist die abgeleitete Klasse ein Subtyp der Basisklasse im Sinne eines abstrakten Datentyps: der Wertebereich der abgeleiteten Klasse ist eine Teilmenge des Wertebereichs der Basisklasse (mit ev. zusätzlichen Operationen).

Vererbung zur Erweiterung: Die abgeleitete Klasse wird mit zusätzlicher Funktionalität oder zusätzlichen Attribute gegenüber der Basisklasse ergänzt. Dies kann auch durch Überschreiben von Methoden geschehen, um beispielsweise Funktionalität zu ergänzen, die in der Basisklasse nicht relevant ist.

Vererbung zur Unterstützung allgemeiner Fähigkeiten: Bei dieser Variante geht es darum, gewisse Basisfunktionalität zu etablieren. Eine Basisfunktionalität wie Serialisierbarkeit oder Vergleichbarkeit wird dabei durch eine abstrakte Klasse (oder Schnittstelle) deklariert – typische Beispiele sind Serializable oder Comparable.

Vererbung von Standardimplementierungen: Allgemeine für mehrere Typen verwendbare Funktionalität wird dabei in einer zentralen Klasse implementiert. Diese Variante dient dazu, allgemeine Programmteile wieder verwenden zu können.

60

Assoziation

Eine Assoziation beschreibt eine Beziehung oder Verbindung zwischen zwei (verschiedenen) Klassenermöglicht, dass zwei Objekte miteinander kommunizieren könnenkann mit einem Namen versehen werden, welche die Beziehung beschreibt

Assoziationen sind nötig, damit zwei Objekte miteinander kommunizieren können „sie müssen voneinander wissen, sich kennen“.

Die konkrete Ausprägung davon wird Objekt‐Link oder Objekt‐Verbindung genannt.Assoziationen sind normalerweise Verbindungen zwischen zwei Objekten von verschiedenen Klassen, eine Assoziation kann aber auchObjekte vom gleichen Typ verbinden (rekursive Assoziation).

Assoziationen werden dadurch realisiert, dass die beteiligten Klassen entsprechende Referenz‐Attribute enthalten:

class Customer{ class PrivateAccount {private Name name; private Customer customer;private Address address; private float balance; private PrivateAccount account; ... . . . }

}

61

Multiplizität

Assoziationen können mit einer Multiplizität versehen werden, welche angibt mit wie vielen Objekten der gegenüberliegenden Klasse ein Objekt assoziiert werden kann.

Ausserdem kann ein Rollenname und dessen Sichtbarkeit angegeben werden

Bsp: Ein Customer hat ein oder mehrere PrivateAccounts

Multiplizitäten1 genau eins0..1 null oder eins0..3 von null bis drei0..* beliebig viele (auch null)* beliebig viele (auch null) Defaultwert, wenn Angabe fehlt1..* eins oder mehrere

Die Realisierung von * Multiplizitäten erfolgt über eine Collection (List, Array,…)class Customer{

private Name name;private Address address;private List<PrivateAccount> accounts; . . .

}

62

Gerichtete Assoziation

Eine gerichtete Assoziation ist eine Beziehung, die nur in eine Richtung navigierbar ist.

Sie wird durch eine offen Pfeilspitze, welche die zugelassene Navigationsrichtung angibt, dargestellt.

Der Customer kennt also seine Accounts, der Account kennt aber nicht seinen Besitzer.

Falls der Navigationsausschluss fehlt, ist nicht bestimmt, ob der Account seinen Besitzer kennt oder nicht.

Bidirektionale Assoziationen sind genau genommen zwei inverse Assoziationen.

Assoziationen sind also nicht dasselbe wir relationale Beziehungen in ER Diagrammen, und dürfen damit nicht verwechselt werden.

63

Aggregation

Eine Aggregation ist eine Assoziation, deren beteiligte Klassen in einer Ganzes-Teile-Hierarchie stehenbeschreibt wie sich etwas Ganzes aus seinen Teilen (logisch) zusammensetzt besteht aus einem Aggregat und den Einzelteilenist normalerweise eine 1 zu n Beziehung

Ein Teil kann zu mehreren Aggregaten gehören (Employee kann mehreren Departments angehören).

Ausserdem kann das Aggregat selber wieder Teil eines Ganzen (zum Beispiel einer Firma) sein.

Aggregationen und Assoziationen sind oft schwer zu unterscheiden. Der resultierende Programmcode ist (oft) der gleiche. Falls man sich nicht sicher ist, wählt man darum im Zweifelsfall eine Assoziation.

64

Komposition

Eine Komposition ist eine Aggregation, bei welcher die Teile vom Ganzen existenzabhängig sindbeschreibt, wie sich das Ganze aus den Einzelteilen zusammensetztist eine 0..1 zu n Bedingungerfüllt ansonsten die gleichen Bedingungen wie die Assoziation

Die Lebenszeit der Teile ist abhängig von der Lebenszeit des Ganzen: Wenn die Firma (Company) aufgelöst wird, werden auch die einzelnen Filialen (BranchOffice) geschlossen.

Die Kardinalität beim Aggregat ist immer 0 oder 1, d.h. jedes Teil kann nur einem Aggregat zugehören.

Ein anderes typisches Beispiel einer Komposition ist eine Rechnung (oder Bestellung) mit ihren einzelnen Positionen. Sobald die Rechnung gelöscht wird, werden auch die einzelnen Positionen sinnlos. Die Rechnung übernimmt bestimmte Aufgaben für das Ganze, wie zum Beispiel das Berechnen der Gesamt‐Summe oder der Anzahl Positionen.

65

Abhängigkeit

Eine Abhängigkeitist eine Beziehung von einem oder mehreren Quellelementen zu einem oder mehreren Zielelementen

Typische Arten der Abhängigkeit sindcall, create, derive, realize, permit, use,…

abhängig unabhängig

Die Abhängigkeit ist dadurch gegeben, dass das das Zielelement (unabhängiges Element) für die Spezifikation oder die Implementation des Quellelements (abhängiges Element) erforderlich ist.

Beispiele von Abhängigkeiten sind:«call» Eine Operation des unabhängigen Elements wird vom abhängigen Element

aufgerufen.«create» Das unabhängige Element wird vom abhängigen Element erzeugt.«derive» Das abhängige Element ist vom unabhängigen Element abgeleitet.«permit» Das abhängige Element hat die Erlaubnis, private Eigenschaften des

unabhängigen Elementes zu verwenden.«realize» Das abhängige Element implementiert das unabhängige Element.«use» Das abhängige Element benutzt das unabhängige Element (zum Beispiel als

Parameter in einem Operationsaufruf).

Abhängigkeiten gibt es zwischen Paketen (ein Paket benutzt Klassen von einem anderen Paket), zwischen verschiedenen Klassen oder zwischen Operationen und Klassen (die Klasse wird als Operationsparameter benutzt).

66

Finden der Klassen

Objektorientierte Synthese André-Claude Godet


Die Idee der Objekt Orientierten Synthese stammt aus dem OOAD Skript von André‐Claude Godet.

67

Vorgehensweise

Kandidaten für

Fachklassen -> Substantive -> gelb

Attribute -> Substantive -> rot

Operationen -> Verben -> blau

Multiplizitäten -> Mengen-Angaben -> grün

Beziehungen -> Örtliche Nachbarschaft (zum Beispiel im gleichen Satz)

Um (erste) Klassen, Attribute und Operationen für das Fachklassendiagramm zu finden, kann man das Pflichtenheft systematisch analysieren. Dabei sucht man alle Substantive, Verben und Mengenangaben und streicht diese farbig an.

68

Kandidaten für Fachklassen

Als erstes streichen wir alle Substantive gelb an. Dies sind erste, provisorische Kandidaten für Fachklassen.

69

Kandidaten für Attribute

Beim Überprüfen der Substantive versuchen wir zu entscheiden, welche davon eher Attribute statt Fachklassen sind. Als Attribute kommen diejenigen Objekte in Frage, welche einen einfachen Aufbau haben (Datum, Kontonummer, …) oder nur einmal vorhanden sind (Name, Geburtsdatum, Zins, …).

Weiter unterstreichen wir diejenigen Substantive, welche eventuell als Klasse/Attribut im System nicht notwendigerweise vorhanden sein müssen.

70

Kandidaten für Operationen

Als drittes streichen wir aktive Verben blau an. Hilfsverben werden ebenfalls unterstrichen. Diese dienen eventuell später für das Erfassen eines Zustandsdiagramms oder zum Erkennen von Bedingungen.

71

Multiplizitäten

Die Multiplizitäten können wir aus den Mengenangaben erkennen. Jede Person hat einen Namen, ein Geburtsdatum, eine Adresse, beliebig viele Konten, …

72

Beziehungen

Gewisse (offensichtliche) Beziehungen können wir erkennen, wenn wir die Sätze untersuchen:

Kunde KontoKunde AdresseKontotyp Zinssätze Weitere Beziehungen sind in den Use Case Diagrammen zu finden

worauf/ womit operieren die Akteure?Alle korrekten (und nötigen) Beziehungen zu finden ist allerdings oft schwierig und oft erst am Ende der Design Phase möglich.

73

CRC Cards

Superclass Account SubclassesResponsibilities Collaborations check Limit ? get Balance Transactions

PrivateAccount

Description

AttributesNumberCustomerTransactions

PrivateAccount

An account type, which can be used for ...

Vorderseite

Rückseite

CRC Karten (Class, Responsibilities and Collaborations Cards) können dazu dienen, eine erste Grobskizze der Fachklassen mit deren Attributen und (public) Operationen zu erstellen.

Weitere (private) Operationen kommen oft im späteren Verlauf des Designs dazu.Collaborations zeigen erste Beziehungen zu anderen Klassen auf.

74

CRC Cards

Superclass PersonSubclassesResponsibilities Collaborations get Assets Accounts . . .

Customer

Description

AttributesNameAddressAccount List

Customer

A customer of a bank.

Vorderseite

Rückseite

75

Fachklassen Diagramm

Ein erster Entwurf

76

Checkliste

Statisches OOA ModellKlassen und Assoziationen

77

Klassendiagramm

In einem ersten Entwurf hat jede Klasse entweder nur einen Namen oder wenige wichtige Attribute mit deren Typ und die wichtigsten Operationen mit deren Sichtbarkeiteine Kurzbeschreibung von 25 oder weniger Wörternihre (vermutlichen) Beziehungen (Assoziationen) durch eine Verbindungslinie zu den anderen Klassen eingetragen

78

Klassen finden

Mögliche Klassen sindPersonen und deren RollenKonkrete Objekte, Dinge, InformationenInformationen über Aktionen (Commands)Orte, Zeitangaben, …Organisationen (Firma, Verein, Schule, …)Ereignisse (was, wer, wann, wo, …)Kataloge, Listen, Bestellungen

79

Analyse: Klassen

Mögliche Fehler:Klassen, die bloss eine Menge von Objekten verwaltenZu viele, zu kleine KlassenKlasse, welche die Benutzeroberfläche modelliert Klasse, die Entwurfs- oder Implementierungsdetails modelliert Klasse, die elementar und keine Architektur- oder Fachklasse ist (Datum, Name, Preis, …)

Im Klassendiagramm muss geprüft werden, ob wirklich alle Klassen wichtige/eigenständige Klassen sind.

80

Analyse: Klassenname

Der Klassenname sollder Fachterminologie entsprechenein Substantiv im Singular seinso präzise wie möglich gewählt werdendasselbe ausdrücken wie die Gesamtheit der Attributenicht die Rolle dieser Klasse in einer Beziehung zu einer anderen Klasse beschreibeneindeutig im Paket bzw. im System sein und sich auch semantisch von allen Namen aller anderen Klassen unterscheiden

Gut gewählte Klassennamen helfen enorm, das System leichter zu verstehen. Die richtige Wahl der Klassennamen ist darum von grosser Bedeutung und sollte entsprechendes Gewicht bekommen.

Der Klassenname sollte darum ein Wort aus dem Problemgebiet sein (z. B. in Cargo Cruise: Buchung statt Bestellung, Kunde oder Reisender statt Person, Reise statt Ausflug, Route oder Teilstrecke statt Tour …)

81

Analyse: Attribute

Sind alle Attribute wirklich notwendig?Ist die Anzahl der Attribute pro Klasse angemessen?Sind die Typen / Sichtbarkeiten korrekt?Könnten einfache Attribute zu einer Datenstruktur zusammengefasst werden?

Müsste eine Gruppe von Attributen in eine eigene Klasse ausgelagert werden?Ist das Attribut ein Klassenattribut?

Es ist oft nicht einfach zu entscheiden, ob ein Attribut korrekt gewählt wurde, oder ob es in eine eigene Klasse ausgelagert werden müsste.

Eine Klasse beschreibt eine Objektidentität und hat eine den anderen Klassen gleichgewichtige Bedeutung im System. Die Existenz des Objektes ist unabhängig von der Existenz anderer Objekte, der Zugriff ist in der Umgebung des Objektes grundsätzlich in beide Richtungen denkbar.

Ein Attribut hat keine Objektidentität, seine Existenz ist abhängig von der Existenz anderer Objekte, der Zugriff geschieht immer über das Objekt. Attribute haben im System eine untergeordnete Bedeutung.

82

Analyse: Attribute

Unnötige AttributeEs beschreibt den internen Zustand eines Lebenszyklus und ist ausserhalb des Objekts nicht sichtbar.Es beschreibt Entwurfs- oder Implementierungs-Details.Es handelt sich um ein abgeleitetes (berechnetes) Attribut, das nur aus Performance-Gründen eingefügt wurde.Es definiert eine Assoziation.

Im Modell sollten nur Attribute aufgelistet werden, die fachlich relevant sind.

83

Analyse: Attributname

Der Attributname soll… kurz, eindeutig und im Kontext der Klasse verständlich sein… möglichst ein Substantiv sein (kein Verb)… den Namen der Klasse nicht wiederholen … bei komplexen (strukturierten) Attributen der Gesamtheit der Komponente (Information) entsprechen… nur fachspezifische oder allgemein übliche Abkürzungen enthalten

Attribute sollten, ähnlich wie Klassen, sprechende und der fachterminologie entsprechende Namen haben. Dies erleichtert sehr das Verständnis für den Sinn dieses Attributes.

Es sollten darum auch möglichst keine Abkürzungen verwendet werden.Das Wiederholen des Klassennamens ist unnötig und sollte darum vermieden werden.Namen von strukturierten Attributen sollten das Ganze beschreiben (z.B. adresse ‐> strasse/nr/plz/ort/land).

84

Analyse: Operationen

Die Operationen findet man in der Spezifikation und den Szenarien. Falls nötig werden Listen-Operationen (Suche, Auswahl, …) hinzugefügt.

Operationen werden in der Vererbungshierarchie so hoch wie möglich eingetragenDie Operation muss einen geeigneten Namen haben, welcher beschreibt, was die Operation tut (Verb)Verwaltungsoperationen (new, delete, get/set…, link, unlink,…) werden nicht im Modell eingetragen

Falls das Klassendiagramm sehr komplex ist, werden auch Methoden wie update, read, print, … nicht ins Klassendiagramm eingetragen.

Falls aus dem Namen der Operation nicht eindeutig klar ist, was sie tut, sind ev. Aktivitäten‐oder Sequenzdiagramme zur Beschreibung nötig. Eine textuelle Beschreibung ist für komplexe Operationen nicht geeignet.

85

Beziehungen

Eine Assoziation zwischen A und B besteht, falls… A ein physischer oder logischer Teil von B ist… A eine Beschreibung für B ist… A ein Mitglied von B ist… A eine organisatorische Einheit von B ist… A ein B benutzt… A mit B kommuniziert … A ein B besitzt…

Eine Assoziation zwischen zwei Klassen A und B liegt vor, wenn diese in irgend einer Form von direkter Beziehung stehen.

Beziehungen findet man in der Spezifikation, den Beschreibungen der Geschäftsprozessen oder (falls bereits ein DB‐Modell vorliegt) anhand der Fremdschlüssel.

86

Eins zu eins (1:1) Assoziation

Klassen verschmelzen?

Zwei Klassen sind nötig, fallsdie Verbindung in eine oder beide Richtungen optional istsich die Verbindung zwischen beiden Objekten ändern kannes sich um zwei umfangreiche Klassen handeltdie beiden Klassen eine unterschiedliche Semantik besitzen.

1:1 Assoziationen sind mögliche Kandidaten für Klassen‐Verschmelzungen.Beispiel: Person Name.Jede Person hat einen Namen, jeder Name gehört genau zu einer Person. Da ist es ev. sinnvoll, Name nicht als eigene Klasse zu führen (ausser die Klasse ist sehr umfangreich, d.h. viele Attribute oder eigene funktionale Operationen).

87

Analyse: Assoziation

Eine Benennung der Beziehung kann sinnvoll oder sogar notwendig sein.Sie ist notwendig, wenn zwischen zwei Klassen mehrere Assoziationen bestehen.Bei reflexiven Assoziationen ist immer ein Rollenname notwendig.

Oft ist es sinnvoll, einer Assoziation einen Namen (eine Rolle) zuzuordnen, welche die Beziehung erklärt. Zum Beispiel dann, wenn die Art der Beziehung nicht offensichtlich ist.

Das Benennen der Beziehung kann auch dazu beitragen, zu erkenne, ob die Assoziation korrekt und nötig ist.

Rollennamen für Assoziationen sind besser als ein Attributname oder ein Verb.

88

Analyse: Multiplizitäten

Aus den Anforderungen an das System ergibt sich, ob ein Schnappschuss (1 bzw. 0..1-Kardinalität) oder die Historie (0..n-Kardinalität) zu modellieren ist.

Eine 1, bzw. 0..1 Beziehung liegt vor, wenn nur der aktuelle Zustand dargestellt werden muss.

Many‐Kardinalitäten sind erforderlich, falls Listen von Objekten zu verwalten sind (mehrere Adressen, Konti, Bestell‐Positionen, …) oder falls eine History (vgl. Beispiel) vorliegt.

89

Analyse: Kann / Muss Assoziation

Die Muss-Beziehung verlangt, dass für jeden neuen Kunden sofort eine Adresse erzeugt werden muss. Der Kunde kann einen Account haben.

Falsche Muss-Beziehungen führen zu unnötigen Einschränkungen.

Kann‐Assoziation Untergrenze 0Muss‐Assoziation Untergrenze 1

Falls eine 1:1 Beziehung besteht, müssen die beiden Objekte auch gleichzeitig wieder gelöscht werden.

Im Modell ist sicherzustellen, ob tatsächlich eine Muss‐Beziehung besteht oder ob es sich um eine Kann‐Beziehung handelt. Andernfalls entstehen unnötige Einschränkungen oder Aufwände.

Kompositionen sind meistens Muss‐Beziehungen.

90

5.1 Objekte

Ausprägungsspezifikation von Klassen und Assoziationen

Vgl. Oestereich Kap 2.41 Seiten 99ff

91

Definition

Das Objektdiagramm zeigt eine bestimmte Sicht auf die Struktur des modellierten Systems.

Die Darstellung umfasst dabei typischerweise Ausprägungsspezifikationen von Klassen und Assoziationen.

Das Objektdiagramm ist eine Art Schnappschuss. Es zeigt den Zustand, also die Belegung der Attribute eines Objektes zu einem bestimmten Zeitpunkt.

Das Objektdiagramm ist ebenfalls ein Strukturdiagramm.Da die Anzahl der Attribute sehr groß sein kann, wird man normalerweise nur diejenigen Attribute auflisten, welche für den Zweck, den man verdeutlichen möchte, ausreichen.

92

Verwendung

Das Objektdiagramm wird nicht so oft verwendet. Es eignet sich dazu, beispielhaft ein zur Laufzeit existierendes Objektnetz mit sein Attributwerten zu visualisieren.

Es kann zum Beispiel dazu benutzt werden, das Klassendiagramm und dessen Beziehungen zu verifizieren.

93

Beispiel: Bank

Der Aufbau des Objektdiagramms ist ähnlich wie beim Klassendiagramm, nur dass im obersten Kasten nicht der Klassenname steht, sondern Instanzname : Typ und zwar unterstrichen. Der Instanzname ist optional und kann bei nicht benannten (anonymen) Objekten weggelassen werden. Ausserdem fehlen die Operationen. Diese gehören zu der Klasse, nicht zum Objekt.

In Use‐Case‐, Sequenz‐ oder Kommunikationsdiagrammen werden Rollen und keine Objekte gezeichnet.

94

Beispiel: Firma

Rekursive Assoziationen lösen sich im Objektdiagramm auf.Ausserdem können Objekte in der Hierarchie mehrfach verbunden sein (z.B. der Angestellte Rolf, der zwei Chefs hat).

95

5.2 Komponenten

Komponenten-Diagramm

Vgl. Oestereich Kap 2.4.2 Seiten 100ff

96

Definition

Eine Komponente …ist ein modulares (in sich abgeschlossenes) Teil eines Systems. ist so strukturiert, dass sie in ihrer Umgebung einfach durch eine andere, äquivalente Komponente ersetzt werden könnte.kann als eine spezielle Klasse mit Attributen, Operationen, Beziehungen, … gesehen werden.lebt/läuft normalerweise in einer Umgebung (einem Container).

Man spricht oft auch von Softwarekomponenten. Komponenten sind eine Spezialisierung von Klassen. Sie können deshalb Strukturmerkmale wie Attribute oder Operationen haben, an Generalisierungen teilnehmen und über Assoziationen mit anderen Komponenten in Beziehung gesetzt werden.

Im Gegensatz zu einer Klasse ist eine Komponente als Modul abgeschlossen und bietet gegen aussen wohldefinierte Schnittstellen (Interfaces) an. Oft besteht eine Komponente aus mehreren Klassen oder anderen Komponenten.

Je nach Blickpunkt gibt es zwei unterschiedliche Sichten auf eine Komponente: eine Black‐Box‐Sicht, die nur den Rand (Schnittstelle, angebotene Dienste) zeigt, und eine White‐Box‐Sicht, die auch die innere Struktur der Komponente zeigt.

97

Verwendung

Das Komponentendiagramm wird vor allem für die Modellierung von komponentenbasierten Softwaresystemen wie zum Beispiel EJB, DCOM, Corba, … eingesetzt.

Falls bei einem System die Austauschbarkeit der Klassen sehr wichtig ist, können auch „normale“Klassen als Komponenten definiert werden.

Um das Innere einer Komponente darzustellen, zeigt ein Komponentendiagramm oft Notationselemente, die sonst vor allem in Klassen‐ oder Kompositionsstrukturdiagrammen angezeigt werden, zum Beispiel Klassen oder Parts.

Die Black‐Box Sicht einer Komponente wird ähnlich wie eine Klasse als Rechteck mit einem Namen gezeichnet. Das Schlüsselwort «component» sowie ein Symbol in der rechten oberen Ecke unterscheiden die Notation einer Komponente von jener einer Klasse.

98

Black-Box-Sicht

Eine Komponente wird ähnlich wie eine Klasse als Rechteck mit einem Namen gezeichnet. Zusätzlich ist das Schlüsselwort «component»sowie optional ein Symbol eingefügt

«component»JTextArea

Scrollable

ImageObserverEventListener

Beispiel einer Komponente mit drei angebotenen und einer benötigten SchnittstelleDie Black‐Box‐Sicht einer Komponente zeigt die Schnittstellen, die die Komponente gegen aussen anbietet bzw. die sie von anderen Komponenten beziehen muss. Das Beispiel hier zeigt die angebotenen Schnittstellen als Lollipops (Scrollable, ImageObserver) und die benötigten als Socket (EventListener).

99

White-Box-Sicht

Eine Komponente wird ähnlich wie eine Klasse als Rechteck mit einem Namen gezeichnet. Zusätzlich ist das Schlüsselwort «component»sowie optional ein Symbol eingefügt


View UI

DocumentModel

Transfer-Handler

Die White‐Box‐Sicht zeigt die innere Struktur der Komponente. Die Komponente JTextArea könnte zum Beispiel aus den Klassen View (für das User Interface), Document (für das Speichern der Daten) sowie aus einer Klasse TransferHandler (für das Verarbeiten von Drag und Drop) bestehen.

100

Komponenten Diagramm

Das Komponenten Diagramm zeigt die verschiedenen Komponenten und deren Schnittstellen.

Scrollable

EventListener Image

Observer

«component»JScrollPane

«component»KeyEventHandler

«component»Graphics


Das Komponentendiagramm ist ebenfalls ein Strukturdiagramm.

101

5.3 Pakete

Paket Diagramm


102

Definition

Ein Paket …fasst Klassen, Interfaces, Komponenten, …zusammenbildet einen Namespacekann Unterpakete enthaltenkann andere Pakete importieren (benutzen)kann benutzt werden, um eine hierarchische Struktur zu bilden

Ein Paket fasst eine Menge von Modellelementen (Klassen, Komponenten, Interfaces, …) zu einer Gruppe zusammen und bildet einen Namensraum (Namespace) für sie. Die Elemente innerhalb eines Paketes müssen eindeutige (verschiedene) Namen haben.

Pakete können andere Pakete als Unterpakete enthalten. Sie gliedern die Modellelemente hierarchisch in eine Struktur, analog zu einem Dateisystem (Directory).

Jede Klasse, Interface, … gehört jeweils nur zu einem Paket.Oft wird statt Paket auch der Name Subsystem oder Kategorie verwendet.

103

Verwendung

Ein komplexes Gesamtsystem sollte möglichst früh in Pakete (Subsysteme) unterteilt werden

Reduktion der Komplexität

Gruppen von Use Cases (Funktionsgruppen) …Klassen, die fachlich zusammengehören (Produkte-Gruppe, Personen-Typen, usw.) …Klassen, die stark interagieren oder zur gleichen Schicht (Layer) gehören, …Klassen, welche ähnliche Funktionalität haben (Controller, DB-Zugriff, usw.) …

… können in Paketen zusammengefasst werden.

Auch die Pakete sollten einfache, beschreibende Namen haben, welche den Sinn des Pakets klar machen.

104

Paket Diagramm

Der Name wird entweder in das Paket oder auf den Reiter geschrieben.

Der vollständig qualifizierte Klassenname ist dann der Klassenname ergänzt um den Namen des Pakets.

Falls die Internas des Pakets aufgezeichnet werden, bietet es sich an, den Paketnamen auf den Reiter zu schreiben.

Auch die Pakete sollten (kurz) Dokumentiert werden (Kurzbeschreibung, 20‐30 Wörter).

105

Checkliste

Lassen sich die Klassen eines Pakets kategorisieren (positive Gruppenbeschreibung)?Bilden die Pakete eine abgeschlossene Einheit, z.B. zu einen Themenbereich?Liegen alle Aggregationen und Kompositionen im selben Paket?Erlauben die Pakete eine Betrachtung des Systems auf einer höheren Abstraktionsebene?Ist der Paketname selbsterklärend?Ist die Anzahl Klassen im Paket angemessen?Liegen Klassen mit intensiver Kommunikation im gleichen Paket?

Eine positive Beschreibung führt zu einem klaren Gruppennamen.Eine negative Kategorisierung ist von der Art: „alles, was nicht zu … gehört“. Dies führt zu keinem geeigneten Paket (‐namen).

106

6. Aktivitäten

Beschreibung von Abläufen,Aktionen und Kontrollflüssen


107

Definition

Eine Aktivität modelliert das Verhalten eines Systems. Sie beschreibt, wie elementare Aktionen mit Hilfe von Kontroll- und Datenflüssen zu komplexen Abläufen kombiniert werden.

Zum Darstellen einer Aktivität dient ein Aktivitätsdiagramm. Es ordnet Aktionen als elementare Verhaltensbausteine in einem Netzwerk aus Knoten und Pfeilen an.

108

Verwendung

Es bietet sich darum an, für solche Zwecke ein Aktivitätsdiagramm zu zeichnen.

Umgangssprachlich ist es oft sehr schwierig, komplexere Vorgänge verständlich zu erklären.

Aktivitätsdiagramme erlauben es, sehr komplexe Abläufe mit Ausnahmen, verschiedenen Varianten, Sprüngen und Wiederholungen einfach darzustellen.

109

Aktivitätsknoten

Es gibt drei Typen von Aktivitätsknoten:

Aktionen sind die elementaren VerhaltensbausteineObjektknoten sind Hilfsknoten, die verwendet werden, um den Fluss von Objekten durch das Netzwerk zu spezifizierenKontrollknoten steuern den Kontroll- oder Objektfluss in einer Aktivität

Aktionen

Eine Aktion ist ein abstraktes Modellelement, das einen elementaren Baustein für die Spezifikation des Verhaltens eines Systems repräsentiert. Eine Aktion kann ein Operationsaufruf sein oder das Empfangen eines Signals, sie kann Objekte oder Objekt‐Beziehungen manipulieren, usw.

Eine Aktion erhält Eingabewerte über Eingabepins und produziert Ausgabewerte an Ausgabepins. An den Ein‐ und Ausgabepins kann eine Aktion mit anderen Aktionen kombiniert werden, so dass die Werte an den Ausgabepins zu den Eingabewerten der folgenden Aktion(en) werden.

Eine Aktion wird gestartet, sobald alle Eingänge bereit sind (alle Kontrollflüsse, Parameter vorliegen). Sie wird beendet wenn alle ausgehenden Kontrollflüsse bereit gestellt sind. Alle Ausgänge werden gleichzeitig ausgelöst.

Es gibt verschiedene Arten von Kontrollknoten: Startknoten (start), Endknoten (end), Parallelisierungsknoten (fork), Synchronisationsknoten (join) und Verzweigungsknoten (merge).

110

Aktionen/Unteraktionen

Einzelne Aktionen können weiter aufgeschlüsselt werden

Diese Aktion kann dann als gesamtes in ein anderes Diagramm eingesetzt werden

Eine Aktion ist entweder eine elementare (atomare, nicht unterbrechbare) Aktion oder sie besitzt weitere Unteraktionen. Sie kann also selber wieder verschachtelt sein und eine Aktivität enthalten. Solche Aktionen mit Unteraktionen werden durch ein kleines Gabelsymbol gekennzeichnet.

Aktionen haben normalerweise einen Eingang (eingehenden Kontrollfluss‐Pfeil) und einen Ausgang (ausgehenden Pfeil). Eine Aktion kann aber auch mehrere Ein‐ und Ausgänge haben.

In verschachtelten Aktionen (Aktionen mit Unteraktionen) werden die Parameter als Objektknoten auf den Rahmen der Aktion gelegt.

111

Objektknoten, Objektfluss

Objektknoten werden als eingehende oder als ausgehende Parameter einer Aktion verwendet.

Sie können auch als kleines Rechteck (Pin) an die Aktion geheftet werden.

Ein Objektknoten kann eine vorgegebene Anzahl Token (1..n) zwischenspeichern, bevor er sie an eine ausgehende Aktivitätskante weiterreicht. Die Objekte, die in einem Objektknoten zwischengespeichert sind, unterliegen einer bestimmten Ordnung, welche angibt, in welcher Reihenfolge die eintreffende Objekte den Objektknoten wieder verlassen. Übliche Ordnungen sind FIFO oder LIFO, ungeordnet ist aber ebenfalls möglich.

Der Objektfluss gibt an, dass die nachfolgende Aktion diese Parameter benötigt, bzw. dass die vorgehende Aktion diese Objekte erzeugt oder verändert hat.

Die Angabe eines Objekt‐Zustands (hier Request) ist optional.

112

Kontrollknoten

Es gibt verschiedene Arten von KontrollknotenStartknotenEndknotenAblaufende

Verzweigung (Entscheidung)Zusammenführung

TeilungSynchronisation

Der Startknoten ist der Startpunkt (Anfang) des Ablaufs, der Endknoten beendet den gesamten Ablauf (alle Aktionen und Kontrollflüsse).

Ein Ablaufende beendet einen einzelnen Objekt‐ oder Kontrollfluss.Eine Verzweigung hat mehrere Ausgänge. Die angegebenen Bedingungen (Guard) entscheiden, welche Flüsse fortgesetzt werden.

Die Zusammenführung ist eine Oder‐Verknüpfung. Jeder eingehende Objekt‐ oder Kontrollfluss führt sofort zum ausgehenden Kontrollfluss (keine Synchronisation!)

Eine Teilung (Splitting) teilt den Kontrollfluss (ohne Bedingung) in mehrere nebenläufige Kontrollflüsse auf.

Die Synchronisation ist eine Und‐Verknüpfung. Bevor weitergefahren werden darf, muss hier gewartet werden bis alle Objekt‐ und Kontrollflüsse eingegangen sind.

113

Aktivitätskanten

Aktivitätskanten werden folgendermassen eingeteilt:

Ein Kontrollfluss ist eine Aktivitätskante, über die kein Objekt-Parameter fliesst

Ein Objektfluss ist eine Aktivitätskante, über die Objekte von einem Knoten zum nächsten fliessen

Objektfluss

Ein Kontrollfluss verbindet Aktionen und Kontrollknoten. Kontrollflüsse transportieren keine Werte (Objekte), sondern nur ein Token um damit die nächste Aktion anzustossen.

Ein Kontrollfluss kann mit einer Guard ([unknown user], [wrong password], …) versehen werden, also einem booleschen Ausdruck, der ausgewertet wird sobald die produzierende Aktion dem Kontrollfluss ein Kontrolltoken anbietet. Das Kontrolltoken wird nur dann weitergereicht, wenn der boolsche Ausdruck zu wahr evaluiert.

114

Beispiel eines Aktivitätsdiagramms

Ein Aktivitätsdiagramm hat einen Startknoten und einen oder mehrere Endknoten. Der Startknoten hat nur ausgehende Pfeile, die Endknoten nur eingehende.

Der Ablauf wird durch die verschiedenen Knoten, welche durch Pfeile (Kontroll/Objektflüsse) verbunden sind, beschrieben.

Die Aktionsknoten bilden dabei den Hauptbestandteil des Diagramms. Kontrollknoten verzweigen den Kontrollfluss in mehrere Stränge (ev. mehrere Tokens), oder führen mehrere Stränge zusammen.

Mit den Objektknoten werden die Parameter einer Aktion angegeben.Jeder Endknoten führt zur sofortigen Beendigung aller Aktionen im gesamten Diagramm.

115

Partitionen

Partitionen (Verantwortlichkeiten, Swimlanes) beschreiben, wer jeweils für welche Aktion zuständig ist.

Aktivitätsdiagramme können in Partitionen unterteilt werden, mit denen die Knoten einem Verantwortungsbereich zugeordnet werden.

In was für Bereiche die Aktivität unterteilt wird, ist frei wählbar. Es kann damit zum Beispiel auch ausgedrückt werden, zu welcher Organisationseinheit oder zu welcher Komponente ein Knoten gehört.

116

Signale, Events

Während eines Ablaufs können Signale gesendet oder empfangen werden. Damit können nebenläufige Prozesse synchronisiert und auf äussere Ereignisse (Events) reagiert werden.

Zeitereignis empfangen(Timer)

Das Symbol für das Zeitereignis soll eine Sanduhr darstellen. Es kann bedeuten dass der Ablauf an einer Stelle für eine gewisse Zeit warten und erst nach Ablauf der Wartefrist weiter fahren darf.

117

Knoten, welche innerhalb eines unterbrechbaren Bereichs liegen, werden durch ein Signal sofort unterbrochen. Der Kontrollfluss wird dann an anderer Stelle fortgesetzt.

Unterbrechbarer Bereich

Sobald das Signal eintrifft, wird der aktuell bearbeitete Ablaufknoten der Aktivität (im unterbrechbaren Bereich) sofort gestoppt. Der Ausgang des Signals zeigt, wo der Kontrollfluss weiterfahren soll.

Wichtig ist hier die Entscheidung, welche Schritte zum unterbrechbaren Bereich gehören sollen, oder ab wann ein Unterbruch nicht mehr sinnvoll ist (Bestellung bereits ausgeliefert, Account eröffnet, Transaction beendet, …).

118

Beispiel: Bestellvorgang

Als Zusammenfassung ein Beispiel mit den wichtigsten Symbolen des Aktivitätsdiagramms.Es geht weniger darum, ob dies ein sinnvoller Ablauf sein könnte, als darum den Gebrauch der verschiedenen Symbole im Zusammenhang zu sehen.

119

7. Zustände

Beschreibung von Zuständen, Zustandsübergängen und Ereignissen


120

Definition

Ein Zustandsautomat (State Machine) besteht aus den Zuständen, welches ein Objekt im Verlauf seiner Lebenszeit einnehmen kannden Ereignissen (Events), welche eine Zustandsänderung (Transition) auslöseneinem Anfangszustandeiner Menge von Endzuständenweiteren Pseudo-Zuständen (split, join, …)

Ein Zustandsautomat wird durch ein Zustandsdiagramm graphisch dargestellt.

Anfangs‐ (Start‐) und End‐Zustand sind sogenannte Pseudo‐Zustände.Es gibt immer nur genau einen Anfangszustand. Es kann aber mehrere Endzustände geben.

121

Verwendung

Statt mit einem Text sind solche Abläufe viel einfacher mit Hilfe eines Zustandsdiagramms beschreibbar.

Die textuelle Beschreibung der verschiedenen Zustände und Zustandsübergänge, welches ein Objekt in seiner Lebenszeit durchlaufen kann, ist oft schwierig zu verstehen.

Aktivitäts‐ und Zustands‐Diagramm werden oft verwechselt.Es ist darum wichtig zu unterscheiden, dass im Aktivitätsdiagramm die Aktionen im Zentrum des Interesses stehen. Das Zustandsdiagramm beschreibt hingegen die verschiedenen Zustände, welches ein Objekt (hier Bankkunde) im Verlauf seines Lebens annehmen kann.

122

Zustand: Attribute

Zustände werden durch ein abgerundetes Rechteck dargestellt.

Es werden nur diejenigen Attributwerte angegeben, welche für das Verhalten des Objektes relevant sind.

Ein Zustand wird bestimmt durch die Menge der möglichen Attributwerte, welche ein Objekt während eines Ablaufs annehmen kann.

Normalerweise sind dabei nicht alle Attribute eines Objekts (einer Klasse) relevant. Es werden nur die relevanten Attribute im Zustandsdiagramm notiert.

Oft können nicht alle möglichen Attributwerte notiert werden, sondern nur die relevantenBereiche (z.B. gleich, kleiner oder grösser als 0).

Der obige Zustand stellt ein aktiven, solventen Kunden dar. Es zeigt aber weder den Namen, noch die Adresse des Kunden, noch andere für diesen Zustand unwichtige Informationen.

Nicht jede Klasse muss über Zustände verfügen. Falls alle Operationen einer Klasse jederzeit und in beliebiger Reihenfolge ausgeführt werden können, besteht kein Grund für eine Zustandsmodellierung.

123

Zustand: Interne Aktionen

Innerhalb des Zustands können interne Aktionen angegeben werden:

entry: beim Eintritt in den Zustandexit: beim Verlassen des Zustandsdo: solange der Zustand nicht verlassen wird

Alle Konten eines Kunden, welcher zwar aktiv ist, aber insolvent wird, werden gesperrt.Erst wenn der Kunde diesen Zustand wieder verlässt, werden seine Konten wieder entsperrt.

124

Unterzustand/Verfeinerung

Zustände können durch Verfeinerung genauer definiert werden.

Man spricht auch von Subzustand (nested state).

Sobald die Tür geöffnet wird, wird der Zustand „heating“ verlassen, egal ob der Ofen als Backofen oder als Mikrowelle benutzt wird. Beim Schliessen der Türe muss zuerst wieder die Art des Heizens (Backen oder Mikrowelle) gewählt werden.

125

Zustandsübergang: Ereignis

Zustandsübergänge werden durch Ereignisse ausgelöst.

Ein Ereignis besteht aus einer Bezeichnung (first deposit) und ev. einer Liste von Argumenten. Ausserdem kann an das Ereignis eine Bedingung verknüpft sein ([balance > 0]).

Ein Ereignis kann auch eine Aktion aufrufen (lock()).

Zeitereignisse werden mit at() oder after() notiert

Ein Konto wird aktiv, sobald es einen positiven Kontostand hat.Ereignisse, welche keinen Zustandsübergang auslösen, können als interne Aktionen notiert werden: Am Ende jedes Jahres werden die Zinsen gutgeschrieben.

Ein Zustandsübergang auf den selben Zustand kann Sinn machen, da dadurch die exit und entry Aktionen getriggert werden (Zinsabschlüsse würden im obigen Beispiel also nur für gesperrte Konten gedruckt).

126

Transitions-BeschreibungDie Transitions-Beschreibung

wird notiert durch

ereignis (argumente) [bedingung]/operation(argumente)

127

Übergang auf den selben Zustand

Ereignisse (Events) können in den gleichen Zustand zurückführen (openAccount, deposit, …)

Der Lebenszyklus eines Bankkunden, der Konten eröffnen und schliessen, und Geldbeträge einzahlen und beziehen kann. Wenn das letzte Konto geschlossen wurde, wird das Kundenobjekt gelöscht.

Falls entry oder exit Aktionen vorhanden sind, werden diese bei jedem Event ausgelöst, auch wenn das Event auf den selben Zustand führt (vgl. Folie 125).

128

Es gibt ausserdem die folgenden Pseudo-ZuständeStartzustand Endzustand Vereinigung (synchron) Verzweigung, Teilung EntscheidungZusammenführungHistory

In Pseudozuständen wird nicht verweilt

Pseudo-Zustände

Es gibt genau einen Startzustand (initial state), ein Zustandsdiagramm kann aber mehrere Endzustände (terminate state) haben.

Die verschiedenen Wege, welche durch eine Verzweigung (splitting, fork) entstehen, können durch eine (synchrone) Vereinigung (join, synchronisation) wieder zusammengefasst werden.

Eine Entscheidung (choice) hat (analog zum Aktivitätsdiagramm) Bedingungen für die Weiterführung des Ablaufs. Eine Kreuzung (junction) führt die verschiedenen Wege wieder zusammen.

129

History

Ein History Pseudo-Zustand merkt sich den zuletzt aktiven Subzustand einer Verfeinerung.

Beim wieder Eintreten in den Zustand wird automatisch der „alte“ Subzustand wieder angenommen, in welchem er sich vor dem Verlassen des Zustandes befunden hat.

Beispiel: Fernseher

130

Übung: Telefon

In kommerziellen Programmen kommt der Einsatz von Zustands‐Diagrammen nicht so oft vor wie in Steuerungs‐Aufgaben. Das nachfolgende Thema ist deshalb aus diesem Bereich gewählt: es geht um eine einfache Telefon‐Steuerung.

Der Telefon‐Apparat verfüge über folgende Komponenten:• Hörer (mit Mikrofon und Lautsprecher),• Hörer‐Sensor mit den Zuständen

‐ up: Amtsleitung ist zu belegen, Hörer ist einzuschalten‐ down: Amtsleitung ist freizugeben, Hörer ist auszuschalten

• Tatstatur‐Block mit den Tasten‐ Ziffern 0 – 9‐ Clear‐Taste (zum Löschen der zuletzt eingegebenen Ziffer)‐Wähl‐Taste (zur Auslösung der Tonfolge für die Nummernwahl)

• Nummern‐Anzeige (Display) und Läutwerk (Telefonklingel)

Es sollen folgende Zustände modelliert werdenWenn Hörer up:

‐ Amtsleitung belegen, Hörer einschalten‐ Eingabe von Ziffern entgegennehmen und am Display anzeigen‐ Löschen der letzten Ziffer falls die Clear‐Taste gedrückt wird‐ Drücken der Wähl‐Taste sendet die Tonfolge für die Ziffernfolge Gesprächsbereit‐ Gesprächsabbruch bei Hörer down

Wenn Hörer down und Ruf von Zentrale:‐ Läutwerk einschalten‐ sobald Hörer up: Gesprächsbereit Läutwerk ausschalten, Drücken von beliebigen Tasten bewirkt nichts.‐ Gesprächsende bei Hörer down‐ Falls der Hörer innerhalb von 10 Sekunden nicht abgenommen wird

Läutwerk ausschalten, Übergangszustand bis der Ruf von der Zentrale aufhört.

AufgabenEntwerfen Sie das Zustands‐Diagramm für das Telefon‐Objekt.Entwerfen Sie zum Vergleich ein Aktivitätsdiagramm für den Ablauf eines Telefon‐Gesprächs (anrufen/empfangen).

131

8. Interaktion/ Kommunikation

Nachrichten, Ablauf, Sender, Empfänger


132

Sequenzdiagramm

Ein Sequenzdiagramm zeigt die Kommunikation zwischen verschiedenen Objekten im zeitlichen Ablauf

Welche Objekte sind an der Szene beteiligt

Welche Informationen (Nachrichten) werden ausgetauscht

In welcher zeitlichen Reihenfolge findet der Informationsaustausch statt

Sequenzdiagramme beschreiben die Kommunikation zwischen Objekten in einer bestimmten Szene. Es wird beschrieben welche Objekte an der Szene beteiligt sind, welche Informationen (Nachrichten) sie austauschen und in welcher zeitlichen Reihenfolge der Informationsaustausch stattfindet. Sequenzdiagramme enthalten eine implizite Zeitachse. Die Zeit schreitet im Diagramm von oben nach unten fort. Die Reihenfolge der Pfeile in einem Sequenzdiagramm gibt die zeitliche Reihenfolge der Nachrichten an.

133

Verwendung

Wichtige, komplexe Szenarien, welche mehrere Mitspieler betreffen, können mit Hilfe eines Sequenzdiagramms aufgezeichnet werden.

Sequenzdiagramme zeigen die Interaktion zwischen mehreren Kommunikationspartnern (Objekten).

Es wird dabei ein zeitlicher Ablauf (von oben links beginnend) beschrieben.

Sequenzdiagramme können in der Analyse und im Design eingesetzt werden. Sie können auch zur Modellierung von komplexen Operationen eines Systems verwendet werden und detaillierte Designinformationen enthalten. Sie werden zur Modellierung von Interaktionen gewählt, wenn die Darstellung der Reihenfolge des Nachrichtenaustauschs wichtig ist.

Bevor Sequenzdiagramme modelliert werden können, müssen die an der Szene beteiligten Klassen identifiziert werden. Die in Sequenzdiagrammen modellierten Objekte und Nachrichten müssen konsistent sein zum Klassendiagramm. Damit dient das Sequenzdiagramm auch zur Überprüfung des Klassendiagramms. Wir können erkennen, ob die Klassen und deren Operationen korrekt und vollständig sind

Ein System wird in der Regel nicht vollständig durch Sequenzdiagramme spezifiziert. Es werden nur diejenigen Szenen modelliert, die häufig vorkommen, sehr komplex oder besonders wichtig sind.

134

Auslöser eines Ablaufs

Initiator eines solchen Ablaufs ist normalerweise entweder ein Akteur eines Use Case Diagramms, oder ein (anonymes) Signal (Ereignis) von aussen.

Gestartet wird ein solcher Ablauf normalerweise durch einen äusseren Anlass (Akteur, Event, …)

Der Initiator kann, muss aber nicht angegeben werden.

135

Objekt: Klasse

Für Objekte wird (analog zum Objekt-Diagramm) ein Name und/oder die Klasse angegeben.

Die gestrichelte Linie zeigt die Lebenslinie.Das senkrechte Rechteck zeigt eine aktive Phase

(Ausführen von Operationen).

In dem Rechteck oberhalb der gestrichelten Linie wird der Objektname und der Klassenname angegeben. Die senkrechte, gestrichelte Linie stellt die Lebenslinie (lifeline) eines Objekts dar. In diesem zeitlichen Bereich existiert das Objekt. Das schmale Rechteck auf der gestrichelten Linie stellt eine Aktivierung dar. Eine Aktivierung ist der Bereich, in dem eine Methode des Objektes aktiv ist (ausgeführt wird). Auf einer Lebenslinie können mehrere Aktivierungen enthalten sein.

Da Sequenzdiagramme dynamische Aspekte eines Systems darstellen, müssen normalerweise Objektname und Klassennamen angegeben werden. Häufig vernachlässigt man jedoch den Objektnamen und gibt nur den Klassennamen an. Ein solches anonymes Objekt steht stellvertretend für alle Objekte der Klasse und impliziert, dass sich alle Objekte der Klasse in dieser Szene gleich verhalten.

136

Nachrichten (Messages)

Objekte kommunizieren über Nachrichten, die fortlaufend nummeriert werden.

Nachrichten sind asynchron oder synchron

Bei asynchronen Nachrichten kann, bei synchronen muss der Antwort-Pfeil eingezeichnet werden.

Nachrichten werden als Pfeile zwischen den Aktivierungen eingezeichnet. Der Name der Nachricht steht an dem Pfeil. Die Nachricht kann auch Argumente (Parameter) haben, diese werden in die Klammer geschrieben. Eine Nachricht liegt immer zwischen einem sendenden und einem empfangenden Objekt.

Das empfangende Objekt führt die entsprechende Operation aus (hat also laut Klassendiagramm eine solche Operation!).

Asynchron bedeutet, dass die verschiedenen Nachrichten in beliebiger Reihenfolge (oder gleichzeitig) abgesetzt werden können. Die Antwort wird nicht abgewartet.

Synchron heisst, die Reihenfolge ist vorgeschrieben.

137

Objekt erzeugen, zerstören

Das Erzeugen eines Objektes wird durch eine create Nachricht, die im Kopf des Objekts endet dargestellt.Das Zerstören (Löschen) eines Objektes wird durch ein x auf der Lebenslinie markiert.

138

Rekursive Nachrichten

Ein Objekt kann auch Nachrichten an sich selbst versenden (Verschachtelung)

Dies verlangt also eine Methode deposit(), sowie eine Methode processTransaction() in der Klasse BankOfficer.

Wir sehen hier nicht, woher der Aufruf zum deposit() kommt, oder welches Objekt die create() Methode ausführt.

139

Alternativen, Referenzen

In Sequenzdiagrammen können alternative Wege aufgezeigt oder es kann auf ein weiteres Sequenzdiagramm verwiesen werden.

Es kann in einem Sequenzdiagramm auch auf ein anderes Sequenzdiagramm verwiesen werden. Im ref‐Bereich wird angegeben, auf welches andere Sequenzdiagramm hier referenziert wird.

Im Allgemeinen sollte man mit solchen Konstrukten vorsichtig sein. Das Sequenzdiagramm eignet sich weniger für das Aufzeichnen von komplexen Abläufen. Für solche Fälle sind Aktivitätsdiagramme das bessere Hilfsmittel.

140

Schleife (Loop)

Diese Abbildung zeigt eine Schleife in einem Sequenzdiagramm. Von aussen kommt ein (Zeit)‐Signal, für alle Konten die Zinsen gutzuschreiben. Das AccountManagement holt die Liste der Accounts und iteriert über diese.

Für jeden Account wird der zugehörige Besitzer (Customer) ermittelt, die geschuldeten Zinsen berechnet und eine entsprechende Transaktion (Banküberweisung) erzeugt.

Falls es auch negative Zinsen zu belasten gibt, wird eine zweite Transaktion erzeugt.

141

Checkliste

Die Namen der Akteure müssen konsistent zu den Use Case Diagrammen sein.Klassennamen/Meldungen müssen konsistent zum Klassendiagramm sein.Objekte sollten möglichst so angeordnet werden, dass in einem Diagramm nur wenig Kreuzungen entstehen.Nachrichten sollten möglichst von links nach rechts zeigen, Returns von rechts nach links.Beteiligte Akteure sollten eher am linken Rand der Diagramme stehen.

Es ist also wichtig zu überprüfen, ob das aufrufende Objekt das aufgerufene Objekt kennt (eine Referenz darauf hat) und ob das aufgerufene Objekt eine entsprechende Methode besitzt.

142

Kommunikationsdiagramm

Im Klassendiagramm können wir die Beziehungen der verschiedenen Objekte erkennen.

Ein Kommunikationsdiagramm kann hingegen aufzeigen, welches Objekt in einem Ablauf welche Operation in welcher Reihenfolge aufruft.

143

Verwendung

Kommunikationsdiagramme erlauben es, auf informelle Art, einen einfachen Ablauf zu skizzieren.

Die aufgerufenen Operationen müssen dabei den Operationsnamen im Klassendiagramm entsprechen. Ebenfalls müssen die Klassen der benutzten Objekte im Klassendiagramm vorhanden sein.

144

Notation

Die Objekte werden (analog zum Sequenz-Diagramm) durch Angabe eines Namens und der Klasse definiert.Die Pfeile zeigen die Richtung des Operations-Aufrufs (wer ruft welche Operation welches Objekts auf).Bedingungen, Iterationen, … werden in eckige Klammern geschrieben.

Die Reihenfolge der Operationsaufrufe ist durch die Nummern ersichtlich.

145

9. GUI Prototyp

Masken und Navigationsstruktur

146

GUI Prototyp

Wie findet man die nötigen Masken / Fenster /Teilfensterderen Inhaltedie richtige Reihenfolge / Struktur

Welche Informationen dazu kann man in welchem Diagramm finden?

Es geht hier nicht darum, ein ergonomisches GUI zu finden. Wir versuchen hier bloss eine erste Skizze zu erstellen, welche dem Auftraggeber als Hilfe dient, die Abläufe zu kontrollieren und die Klassen (Daten/Informationen) auf Vollständigkeit zu prüfen.

147

Use Case Diagramm

Jeder primäre Use Case wird in einem (separaten) Fenster abgebildetSekundäre Use Cases sind eventuell im selben Fenster, eventuell in einem Dialog-Fenster, eventuell auf dem GUI nicht sichtbarAblauf aus Use-Case Beschreibung

Benutzerführung

Es kommt sehr selten vor, dass ein Fenster mehr als einen Primären Use Case abbildet. Im Normalfall ist das auch ergonomisch nicht sinnvoll.

148

Die benötigten Fenster, welche man daraus ableiten kann:

149

Aktivitätsdiagramm

Reihenfolge der Aktivitäten Navigationsstruktur

Faustregel: Zu jeder Aktion gehört eine entsprechende Maske und ein Menu-Punkt oder Button (suchen, speichern, erstellen, löschen, …)

Das sind ev. Masken/Fenster, welche bereits durch die Use Cases erkannt wurden, eventuell kommen aber neue Masken/Fenster dazu (grösserer Detaillierungsgrad).

Die Reihenfolge der Aktionen wird auf dem GUI durch die Reihenfolge der Fenster (Ablauf / Navigation) widergespiegelt.

150

Die nötigen Fenster zum Erfassen eines Neukunden (inkl. Erstellen des ersten Accounts) sind:

151

Klassendiagramm

KlassenattributeMasken-Inhalte

Jede Klasseeigenes Fenster oder TeilfensterGruppierung

Alle Informationen einer Klasse befinden sich normalerweise auf dem gleichen Fenster. Es kann sein, dass mehrere Klassen auf demselben Fenster abgebildet werden. Dies vor allem bei Aggregationen oder Kompositionen. Diese werden aber üblicherweise auf dem GUI klar abgegrenzt (Gruppierung z. B. durch Linien oder Abstände).

152

Bank System

Die nötigen Textfelder zum Erfassen eines Kunden sind:

153

Balsamic Tool

154

10. Analyse Muster

Entwurfsprinzipien

Siehe auch Heide Balzert: Lehrbuch der Objektmodellierung.

155

Definition

Analyse Muster (Analysis-Pattern) beschreiben eine Lösung für eine typische Teilaufgabe bei der Erstellung eines fachlichen Modells, das heisst also in der Analyse-Phase.

Entwurfs Muster (Design-Pattern) sind bewährte Lösungsschablonen für wiederkehrende Entwurfsprobleme in der Design Phase. Sie beschreiben auf hoher Abstraktionsebene einen Ansatz für eine Software Lösung.

Der Unterschied von Analyse und Design Pattern besteht vor allem in der zeitlichen Abfolge.Analyse Muster werden in der Analyse Phase zum Definieren des fachlichen Modells beigezogen.

Design Pattern werden erst in der Design Phase eingesetzt, wenn es darum geht die Gesamt‐Lösung zu entwerfen (bzw. die konkrete Umsetzung zu definieren).

156

Anwendung

Analyse Muster dienen zur Modellierung häufig vorkommender Strukturen.beschreiben eine Gruppe von Klassen oder Objekten mit

festen Verantwortlichkeitendefinierten Beziehungendefinierten Interaktionen

haben einen eindeutigen Namenbeantworten die Frage:Wie modelliere ich diese Klassenbeziehung?

Ein Analyse Muster beschreibt also eine Lösung für eine typische Teilaufgabe bei der Erstellung eines fachlichen Modells (d.h. in der Analyse Phase).

Entwurfs Muster sind hingegen eher implementierungs‐orientierte Muster. Sie geben Antwort auf die Frage: „Wie realisiere ich diese Klassenbeziehung?“

157

Umsetzung

Design Modell

Software Entwicklungs-Prozess

KonkretesProblem

AnalyseModell

Analyse

Transformation / Einbettung

Konkrete Ebene

Abstraktion

Problem/Aufgabe Lösung

Implementation

Analyse Pattern helfen dabei, eine Struktur in die (oft amorphe) Menge von benötigten Information zu bringen. Design Pattern können dann Hinweise geben, wie das Gesamt‐System konkret implementiert werden soll.

158

Muster 1: Liste

Merkmale

Komposition (Ganzes Teile)

Alle Teile sind gleichartig

Jedes Teil gehört zu genau einem Aggregat

Aggregat enthält mindestens ein Teil

die Multiplizität ist normalerweise 1..*

Typische Listen Muster kommen vor bei Bestellungen (Bestell‐Kopf und die einzelnen Bestellpositionen), bei Aufträgen (Gesamtauftrag und die einzelnen Einzel‐Aufträge/Aufgaben) oder bei Projekten (Gesamt‐Projekt und einzelne Projekt‐Schritte).

Alle Listenelemente haben den gleichen Typ (tragen die gleichen Informationen).Die Listenelemente machen nur als Teil der Liste einen Sinn.

159

Liste

Beispiele

Weitere Listen treten zum Beispiel auf bei Auftrag ‐> Auftragspositionen ‐> EinzelAuftrag

160

Muster 2: Exemplartyp

Merkmale

Es existieren mehrere konkrete Exemplare eines Objektes (z.B. Buch -> Bibliothek)

Sammeln der gemeinsamen Informationen (Signatur, Titel, …) in einer Beschreibungsklasse

Exemplar-Informationen (ID, Ausleihe, …) in Exemplar-Klasse

Einfache Assoziation (keine Komposition)

Objektbeziehungen bleiben konstant (ausser ein Exemplar wird gelöscht)

Auch bekannt als Item / Item‐Description Analyse‐Muster (Peter Coad et al.: „Object Models: Strategies, Patterns, and Applications“, Prentice Hall, 1996 )

161

Exemplartyp

Beispiele

162

Muster 3: Baugruppe

MerkmaleEine Baugruppe beschreibt ein aus verschiedenen

Teilen zusammengebautes physisches Objekt (Schiff, Flugzeug, Turbine, …)

Physische Teile eines Objektes -> KompositionDas zusammengesetzte Objekt besteht aus unterschiedlichen TeilenDie Beziehung besteht über lange ZeitEin Teilobjekt kann vom Ganzen getrennt und in ein anderes Objekt eingebaut werden

163

BaugruppeBeispiel

Ein Flugzeug besteht aus verschiedenen physischen Teilen, welche selber auch wieder aus kleineren Teilen zusammengesetzt sein können. Ein Motor eines Flugzeugs könnte aber prinzipiell auch ausgetauscht oder in einem anderen Flugzeug eingebaut werden.

164

Muster 4: Stückliste

Stücklisten bestehen aus Teilen, die aber selber als Einzelobjekte auftreten können.

MerkmaleGanzes / Teile Verhältnis -> KompositionDas Aggregat und seine Teile können als ganzes betrachten werdenDie Teile können auch als eigenständige Objekte behandelt werdenDie Multiplizität der Aggregatsklasse ist 0..1.Jedes Objekt vom Typ A kann wieder aus Objekten vom Typ A, aber auch aus Objekten vom Typ B, C, … bestehen.

Im Gegensatz zur Baugruppe, wo eine strenge Hierarchie herrscht, kann bei einer Stückliste jedes Teil als Gesamtes oder als Teil eines anderen Teils auftreten.

Ein Flugzeug besteht aus Flugzeugteilen, aber nicht aus einzelnen Flugzeugen.Jeder Knoten eines Baumes kann hingegen selber wieder Knoten enthalten. Jeder Teilbaum hat einen Wurzel‐Knoten, das heisst, jeder Knoten kann ein Ganzes repräsentieren.

165

Stückliste

Beispiele

Ein Directory kann selber Directories, Links oder File enthalten. Ein Directory kann in einem Directory enthalten sein, muss aber nicht.

Ein Komponenten Baum ist ein Spezialfall einer Stückliste, da er aus lauter gleichartigen Objekten besteht.

166

Muster 5: Koordinator

Ein Koordinator verbindet zwei verschiedene Objekte. Seine Aufgabe besteht darin, zu wissen wer wen kennt.

MerkmaleEinfache AssoziationEin Koordinator hat wenig eigene Attribute und OperationenEr dient vor allem dazu, andere Objekte zu verbinden.

Ein Koordinator wird eingesetzt, um mehrstellige Assoziationen durch zwei einfache Assoziationen und eine (Vermittler‐)Klasse zu ersetzen.

167

Koordinator

Beispiele

168

Muster 6: Rollen

MerkmaleZwischen zwei Klassen bestehen mehrere einfache AssoziationenEin Objekt kann zu verschiedenen Zeitpunkten verschiedene Rollen einnehmenDas Objekt, welches verschiedene Rollen spielen kann, hat für alle Rollen die gleichen Eigenschaften und Operationen

Das Rollen Analyse Muster kommt sehr oft im Zusammenhang mit Personen zum Einsatz, welche zu verschiedenen Zeiten verschiedene Aufgaben wahrnehmen.

169

Rollen

Beispiele

In einer Abteilung kann abwechselnd jemand anders die Leitung übernehmen. In einem Kurs können die Redner auch Kurs‐Teilnehmer sein.

170

Muster 7: Wechselnde Rollen

MerkmaleEin Objekt kann zu verschiedenen Zeitpunkten verschiedene Rollen einnehmenFür die verschiedenen Rollen benötigt das Objekt verschiedene (zusätzliche) Eigenschaften oder OperationenDie unterschiedlichen Rollen werden mittels Generalisierung modelliertBeziehungen zwischen dem Objekt und seinen Rollen werden nur erweitert, nicht gelöschtEs gibt keine Beziehungen zwischen den Rollen und anderen Objekten

Im Unterschied zum Rollen Analyse Muster haben die Objekte der Wechselnden Rollen verschiedene Eigenschaften (zusätzliche Attribute oder Operationen).

171

Wechselnde Rollen

Beispiel

Der gleiche Mitarbeiter kann zu verschiedenen Zeiten verschiedene Rollen (Zustände) wahrnehmen. In den verschiedenen Rollen haben die Mitarbeiter andere Eigenschaften und Aufgaben, (Attribute/Operationen).

172

Muster 8: Historie

MerkmaleZwischen den Objekten ist eine einfache AssoziationFür jedes Objekt müssen mehrere Informationen gespeichert werdenJede Information bezieht sich auf einen Zeitraum, welcher angibt, was zu welchem Zeitpunkt giltBeziehungen zwischen dem Objekt und seinen Informationen werden nur erweitert, nicht gelöscht

Im Rollen Analyse Muster wird keine Historie geführt, das heisst, es ist nicht bekannt, welche Rollen diese Person zu welchem Zeitpunkt eingenommen hat.

Die Historie hingegen speichert die ganze Vorgeschichte.

173

Historie

Beispiel

Die verschiedenen (Teilzeit) Anstellungen können sich prinzipiell zeitlich überlappen. Zu jedem Zeitraum gibt es mindestens eine Anstellungsart. Jeder Anstellungswechsel führt zu einem neuen Anstellungs‐Objekt.

174

Muster 9: Gruppe

MerkmaleZwischen den Objekten ist eine einfache AssoziationMehrere Einzelobjekte gehören (zu einem gewissen Zeitpunkt) zur gleichen GruppeDie Gruppe kann kurzfristig eventuell auch ohne Mitglieder existierenDie Objektbeziehungen können erstellt und wieder gelöscht werden

Das Gruppe Analyse Muster dient zum Aufzeigen von Zugehörigkeiten verschiedener Einzel‐Objekte zu einer (möglicherweise wechselnden) Gruppe.

Diese Gruppe kann eine Abteilung, ein Projekt‐Team oder eine beliebige Menge von gleichartigen Objekten sein, welche (im Gegensatz zur Liste) auch ohne das Gruppenelement existieren können.

175

Gruppe

Beispiel

Die Angestellten gehören jeweils zu einer oder mehreren Projekt Gruppen. Dies kann jenach Zeitpunkt wechseln und muss nicht historisiert werden. Ein Angestellten kann auch keiner oder mehreren Projekt Gruppen angehören.

176

Muster 10: Gruppenhistorie

MerkmaleZwischen den Objekten ist eine einfache AssoziationMehrere Einzelobjekte gehören (zu einem gewissen Zeitpunkt) zur gleichen GruppeDie Gruppe kann kurzfristig eventuell auch ohne Mitglieder existierenDa die Informationen historisiert werden sollen, können zwar neue Objektbeziehungen entstehen, es werden aber keine Beziehungen gelöscht.

Analog zur Historie wird bei der Gruppenhistorie die ganze Vorgeschichte gespeichert.

177

Gruppenhistorie

Beispiel

Die Angestellten gehören jeweils zu einer oder mehreren Projekt Gruppen. Dies kann jenach Zeitpunkt wechseln und wird historisiert. Ein Angestellter kann auch keiner oder mehreren Projekt Gruppen angehören, oder mehrfach (zu verschiedenen Zeitpunkten) zur gleichen Gruppe.

178

11. DB-Prototyp

Objektrelationale Abbildung

179

Eigenschaften einer Datenbank

PersistenzDaten gehen bei Programmende nicht verloren

ZuverlässigkeitKonsistenz, Integrität, Unversehrtheit, Effizienz

UnabhängigkeitEigene Programmiersprache, eigenes System

AbstraktionKommunikation über Schnittstelle

DatenschutzKein unberechtigter Zugriff

Mehrfachbenutzung

Die Hauptaufgabe einer Datenbank besteht darin, Daten so lange zu speichern bis diese explizit überschrieben oder gelöscht werden. Also auch über das Ende (ev. sogar der Lebenszeit) einer Applikation hinaus.

Die Daten müssen konsistent (vollständig und widerspruchsfrei), integer (unverfälscht, sicher), unversehrbar (geschützt vor absichtlicher oder unabsichtlicher Veränderung) gespeichert werden und effizient wieder lesbar sein.

Um die Langlebigkeit der Daten zu gewähren, muss die Verwaltung der Daten unabhängig von den benutzenden Applikationen geschehen (Programmiersprache). Ausserdem will der Applikationsentwickler sich nicht um die technischen Details der Datenbank kümmern müssen, sondern auf einer höheren, abstrakten Schnittstelle auf die DB zugreifen können.

Die Daten der Datenbank müssen vor unberechtigtem Zugriff geschützt werden können, anderseits soll aber jeder berechtigte Anwender (ev. auch mehrere gleichzeitig) auf die Daten zugreifen können.

180

Datenbankmodell

Eigenschaften der DatenelementeTyp, Länge, Wertebereich, …

StrukturTabellenstruktur, Schlüssel, Beziehungen

KonsistenzbedinungenEindeutigkeit/Vorhandensein von Werten

Zugriffs-OperationenSpeichern, suchen, ändern, löschen, …

Ein Datenbankmodell ist die theoretische Grundlage für eine Datenbank und bestimmt, auf welche Art und Weise Daten in einem Datenbanksystem gespeichert und bearbeitet werden können.

Jedem Datenbanksystem muss darum ein Datenbankmodell zugrunde liegen, in welchem die DB Struktur (Tabellen), die Typen der Elemente, die Konsistenzbedingungen, …festgelegt sind.

181

Relationales DB-System

RDBS basiert auf RelationenWird in Tabellen abgebildetEinfach und flexibel

2002XML für Einsteiger2…3

2006XML kurz und gut1YearTitleIdBook

Name der Tabelle/Relation

Attribute/Felder/Spalten

Tupel/Zeilen

Relationale Datenbanksysteme sind sehr einfach und flexibel und darum heute die am häufigsten benutzten DB Systeme.

Ihr Nachteil ist allerdings, dass sie die OO‐Konzepte nicht eins zu eins abbilden können.

182

Objektrelationale Abbildung

Zusammenhang zwischen OO-Klassen und RDB-Tabellen ORM

???

???

???

??????

Objektorientierte Programmiersprachen kapseln Daten und Verhalten in Objekten, relationale Datenbanken hingegen legen Daten in Tabellen ab. Ausserdem stellt nicht jede Menge von Tabellen eine relationale Datenbank dar.

Die beiden Paradigmen OO und RDB sind grundlegend verschieden. Es braucht darum einen Mechanismus, wie man eine Abbildung zwischen Klassen(‐Strukturen) und relationalen Tabellen finden kann.

ORM: object‐relational mapping

183

DB Normalformen

Eine DB mit redundanten Daten ermöglicht, dass bei Daten-Änderungen die mehrfach enthaltenen Daten inkonsistent werden.

Anomalien, WidersprücheSpeicherplatz-Verschwendung

Redundanzen vermeiden durch Normalisierung

Das Ausmass, in denen ein Datenbankschema gegen Anomalien gefeit sein kann

erste, zweite, dritte, ... Normalform

Damit eine Menge von Tabellen (ein Datenbankschema) eine brauchbare Relationale Datenbank darstellt, müssen einige Regeln erfüllt sein. Diese sind bekannt unter dem Begriff DB Normalformen.

184

Erste Normalform

Jedes Attribut der Relation muss einen atomaren Wertebereich haben.

Zusammengesetzte oder geschachtelte Wertebereiche sind nicht erlaubt.

Kein Attributwertebereich kann in weitere (sinnvolle) Teilbereiche aufgespaltet werden

Beispiel: Adresse darf nicht als Attribut verwendet werden, sondern muss in PLZ, Ort, Straße und Hausnummer aufgeteilt werden.

185

Erste Normalform

Verletzung der ersten NormalformPublikation aus Verlag, Kürzel und JahrMehrere Autoren (mit Reihenfolge)

Keine einfache Sortierung nach Erscheinungs-Jahr möglichAutoren können nicht einfach aufgelistet werden.

1. Michael Scholz, 2. Stephan Niedermeier

Galileo (GaC: 2009)

Java und XML3

1. Helmut VonhoegenGalileo(GaC: 2011)

Einstieg in XML2

1. Simon St. Laurent, 2. Michael Fitzgerald

O'Reilly (ORe:2006)

XML kurz und gut1

AuthorPublishedBooktitleID

Die (geordnete Liste der) Autoren darf nicht in ein einzelnes Feld abgespeichert werden. Das Datumsfeld ist in dieser Form nicht gut benutzbar (Mischung aus Monat und Jahr, kein richtiges Datum).

186

Erste Normalform

Mögliche Lösung

Galileo

Galileo

Galileo

O'Reilly

O'Reilly

Publisher

Stephan

Michael

Helmut

Michael

Simon

Firstname

Scholz12009GaCJava und XML

3

Niedermeier22009GaCJava und XML

3

Vonhoegen12011GaCEinstieg in XML

2

Fitzgerald22006OReXML kurz und gut

1

St. Laurent12006OReXML kurz und gut

1

NameA-NrYearPTLABooktitleId

Diese Lösung hat allerdings immer noch Schwächen: Wir haben jetzt Buch 1 und 3 doppelt in der Datenbank. Ausserdem ist es schwierig zu prüfen, ob die Autorennummern (A‐Nr) eindeutig (und vollständig) sind.

187

Zweite Normalform

Eine Relation ist in der zweiten Normalform, wenn die erste Normalform gilt und kein Nichtschlüssel-Attribut voll funktional abhängig von einer echten Teilmenge eines Schlüsselkandidaten ist.

Das heisst: Von einer beliebigen Teil-Menge von Attributen (Spalten), die keine Schlüsselfunktion haben, kann nicht auf den Wert anderer Attribute geschlossen werden.

188

Zweite Normalform

Verletzung der zweiten Normalform

Die Spalten Id und A-Nr bilden einen (Primär-) Schlüssel. Buchtitel, Publisher und Year sind von der Id abhängig, nicht aber von der Nummer des Autors.

Galileo

Galileo

Galileo

O'Reilly

O'Reilly

Publisher

Stephan

Michael

Helmut

Michael

Simon

Firstname

Scholz12009GaCJava und XML

3

Niedermeier22009GaCJava und XML

3

Vonhoegen12011GaCEinstieg in XML

2

Fitzgerald22006OReXML kurz und gut

1

St. Laurent12006OReXML kurz und gut

1

NameA-NrYearPTLABooktitleId

Die Id des Buchs identifiziert vollständig die Spalten Buchtitel, Publisher und PTLA, das heisst, diese sind vom zweiten Schlüssel unabhängig. Damit wird aber die zweite Normalform verletzt.

Der zweite Schlüssel A‐Nr identifiziert zusätzlich (nur noch) den Namen des Autors.

189

Zweite NormalformMögliche Lösung

Galileo

Galileo

O'Reilly

Publisher

2011GaCEinstieg in XML2

2009GaCJava und XML3

2006OReXML kurz und gut1

YearPTLABooktitleId

ScholzMichael22

FitzgeraldMichael21

VonhoegenHelmut12

NiedermeierStephan13

St. LaurentSimon11

NameFirstnameA-NrB-Id

Book

Author

In der Book Tabelle haben wir jetzt nur noch den Primär-Schlüssel Id von welchem alle Spalten abhängig sind.

B-Id und A-Nr bilden zusammen einen Primär-Schlüssel, von welchem die beiden anderen Spalten abhängig sind.

B‐Id ist jetzt in der Autoren‐Tabelle ein Fremdschlüssel, welcher auf den Primärschlüssel der Book‐Tabelle verweist. Ausserdem bilden jetzt B‐Id und A‐Nr zusammen einen Primärschlüssel für die Autoren‐Tabelle.

Allerdings ist auch hier noch keine Redundanzfreiheit gewährleistet. Ein Autor, welcher mehrere Bücher geschrieben hat, wird in dieser Darstellung mehrfach aufgelistet.

190

Dritte Normalform

Die dritte Normalform ist erfüllt, wenn sich das Relationenschema in der zweiten Normalform befindet, und kein Nichtschlüsselattribut von einem Schlüsselkandidaten transitiv abhängt.

Ein Nichtschlüsselattribut darf also nicht von einer Menge von Nichtschlüsselattributen, sondern nur direkt von einem Primärschlüssel abhängig sein.

191

Dritte Normalform

Verletzung der dritten Normalform:

Die Spalte PTLA hängt direkt von der Spalte Publisher ab. Beim Ändern des Publishers müsste auch die PTLA Spalte geändert werden.

Galileo

Galileo

O'Reilly

Publisher

2011GaCEinstieg in XML2

2009GaCJava und XML3

2006OReXML kurz und gut1

YearPTLABooktitleIdBook

PTLA ist unabhängig von der Book Id und hängt allein vom Publisher ab. Publisher ist aber kein Schlüsselattribut für Buch. Darum ist hier die dritte Normalform verletzt.

192

Dritte NormalformMögliche Lösung

2

2

1

Publisher

2011Einstieg in XML2

2009Java und XML3

2006XML kurz und gut1

YearBooktitleIdBook

GalileoO'Reilly

Publisher

GaC2

ORe1

PTLAId

5

4

3

2

1

Id

VonhoegenHelmut2

St. LaurentSimon1

FitzgeraldMichael1

Stephan

Michael

Firstname

Niedermeier3

Scholz3

NameB-Id

Publisher

Author

Durch Auslagern der Publisher in eine eigene Tabelle ist PTLA direkt vom Primärschlüssel des Publishers abhängig, d.h. die dritte Normalform ist gewärleistet.

Die Autoren‐Tabelle enthält hier einen Fremdschlüssel auf die Buch‐Tabelle. Dies funktioniert hier gut, da jeder Autor nur einem Buch zugeordnet ist. Um einem Autor mehrere Bücher zuzuordnen, bräuchte es eine separate Assoziations‐Tabelle (siehe Folie weiter hinten).

193

Objekt-Relationale Abbildung

Abbilden von Klassen und Relationen

194

Abbilden von Klassen

Operationen werden nicht abgebildet.Atomare Attribute erscheinen als Spalte in der Tabelle mit (möglichst) demselben TypDie Tabelle wird um einen Primär-Schlüssel ergänzt

finished9.8.201115.2.201112OOAD3

cancelled1.1.20113.10.201041XML2

finished2.7.201112.1.2011103Java1

StateEndStartNrNameIdCourse

195

Abbilden von Vererbung

Es gibt verschiedene Möglichkeiten, Generalisierungs-Hierarchien abzubildenAbbilden der ganzen Hierarchie auf nur eine TabelleAbbilden nur der konkreten Klassen auf je eine TabelleAbbilden jeder Klasse auf je eine separate Tabelle

196

Abbilden auf nur eine Tabelle

3

2

1

Id

null15.2.201112Willi GrauTN

partTimenull41Gabi BlauDZ

null12.1.2011103Hans MusterTN

StateDateOfBirthAddressNameTypePerson Teilnehmer

Dozent

Dieser Ansatz ist zwar sehr einfach, der Zugriff auf die Daten ist schnell, da alle Daten in der gleichen Tabelle liegen. Weitere Subklassen sind einfach einzufügen, es müssen nur die entsprechenden Spalten angefügt werden.

Der Ansatz hat aber den Nachteil dass viele der Attribute auf null gesetzt werden müssen (alle, welche im speziellen Subtyp nicht vorkommen). Ausserdem sind bei einer Änderung innerhalb der Hierarchie (z.B. Ergänzen einer Klasse um ein weiteres Attribut) immer alle Objekte der Hierarchie betroffen.

Dieser Ansatz ist geeignet für Hierarchien geringer Tiefe mit wenig verschiedenen Klassen.Die Spalte Type enthält den eigentlichen Datentyp, hier also entweder Teilnehmer oderDozent. Person kann als Type vorkommen, ausser wenn die Basisklasse abstrakt (oder ein Interface) ist.

197

Abbilden jeder konkreten Klasse auf je eine Tabelle

2

1

Id

15.2.201112Willi Grau

12.1.2011103Hans Muster

DateOfBirthAddressNameTeilnehmer

1

IdpartTime41Gabi Blau

StateAddressNameDozent

Hier wird jede konkrete Klasse auf eine separate Tabelle abgebildet. Jede Tabelle hat einen eigenen Primär‐Schlüssel (Id). Auch hier ist der Zugriff effizient, da jeder Zugriff nur eine Tabelle betrifft. Der Nachteil ist, dass bei einer Änderung der abstrakten Oberklasse (hier Person) alle davon betroffenen Tabellen geändert werden müssen.

Dieser Ansatz ist daher am ehesten geeignet, wenn die Basisklasse nur wenig Attribute besitzt.

198

Abbilden jeder Klasse auf je eine Tabelle

1

IdpartTime2

StateP-IdDozent

3

2

1

Id

12Willi Grau

41Gabi Blau

103Hans Muster

AddressNamePerson

2

1

Id

15.2.20113

12.1.20111

DateOfBirthP-IdTeilnehmer

Dieser Ansatz entspricht am besten dem Objektorientierten Konzept. Änderungen in der Basisklasse hat keine Änderungen in den „abgeleiteten“ Tabellen zur Folge. Neue Attribute in den Subklassen betreffen nur die eigene Tabelle.

Der Nachteil ist, dass sehr viele Tabelle entstehen und die Abfragen aufwändiger werden, da bei dieser Variante die Informationen in verschiedenen Tabellen liegen.

199

Abbilden von Assoziationen

Unterscheiden nach Multiplizität1:1 1:mm:m

Assoziationen einer Relationalen DB sind immer bidirektional.

Je nach Multiplizität der Assoziation wählen wir eine andere Art der Abbildung.Im Gegensatz zum Objektorientierten Modell können wir in einer DB immer beide Richtungen einer Assoziation finden. Je nach Realisierung brauchen wir einfach eine andere SQL‐Abfrage.

200

Abbilden einer 1:1 Assoziation

EndTimeStartTimeWeekdayId

2

16:308:30Monday1

Stundenplan

… …Stundenplan_FKNameId

2

1Java1

Course

Java

Name EndTimeStartTimeWeekdayId

2

16:308:30Monday1

Course

Oder integriert:

1:1 Assoziationen können durch Verschmelzen der Informationen in eine einzige Tabelle abgebildet werden. Dies ist die kompakteste und effizienteste Umsetzung.

Falls man das nicht möchte, kann die Assoziation mit Hilfe eines Fremdschlüssels realisiert werden. Bei der gerichteten Assoziation von Course zu Stundenplan bietet sich ein Fremdschlüssel Stundenplan_FK in der Course Tabelle an. Das umgekehrte (Fremdschlüsssel Course_FK in Stundenplan‐Tabelle) wäre aber genau so möglich.

Die SQL Abfrage für die Wochentage aller Kurse wäre dann etwaselect c.Name, s.Weekday from Stundenplan s, Course c where c.Stundenplan_FK = s.Id

201

Abbilden einer 1:m Assoziation

…AddressNameId

2

Josef Muster1

Dozent

… …Dozent_FKNameId

2

1Java1

Course

Bei einer 1:m Assoziation wird der Fremdschlüssel in die Klasse eingefügt, welche die Multiplizität 1 hat. Hier: jeder Kurs hat (nur) einen Dozenten, Dozenten können mehrere Kurs halten.

202

Abbilden einer m:m Assoziation

…DateOfBirthNameId

2

Hans Muster1

Teilnehmer

… …NameId

XML2

Java1

Course

Teilnehmer_FKCourse_FK

12

Course_ Teilnehmer

Zum Abbilden einer m:m Assoziation benötigen wir eine zusätzliche Tabelle für die Tupel der Fremdschlüssel. Course_Teilnehmer ist eine sogenannte Assoziations‐Tabelle (associative table).

203

Abbilden eines Koordinators

Dozent

…DateOfBirthNameId

2

Hans Muster1

Teilnehmer… …NameId

XML2

Java1

Course

1

Teilnehmer_FK StateCourse_FK

active2

Registrierung

Die Koordinator‐Klasse verbindet (indirekt) zwei Klassen durch eine m:m Assoziation, trägt aber zusätzliche Informationen (hier ein state‐Attribut). Auch diese wird mit einer Assoziationstabelle (mit zusätzlichen Spalten für die Koordinator‐Attribute) realisiert.

204

Reflexive AssoziationBsp: Stückliste

11.12.2008usr21

nullFolder_FK

……

…10.1.2008root1

1.12.2008bin3

…DateNameIdFolder

Zum Abbilden einer reflexiven (rekursiven) Assoziation kann ein Fremdschlüssel benutzt werden, welcher auf den Primärschlüssel der eigenen Tabelle zeigt. Dieser ist für die Root‐Elemente der Hierarchie leer (null).

205

12. Design Pattern

Entwurfsmuster

206

Anforderungen

Ein gutes Design Pattern (Entwurfsmuster) sollteein oder mehrere bekannte, wiederkehrende Probleme lösenein erprobtes Konzept bietenauf realen Konstrukten basierenüber das völlig Offensichtliche hinausgehenBeziehungen aufzeigen, die tiefergehende Strukturen und Mechanismen eines Systems umfassenUnterstützung für (Gesamt-)DesignEntscheidungen bieten

Ein Design Pattern sollte eine bewährte Lösung zu einem oft wiederkehrenden Problem bieten.

207

Nutzen

Der primäre Nutzen eines Entwurfsmusters liegt in der Beschreibung einer Lösung für eine bestimmte Klasse von Entwurfsproblemenergibt sich aus dem Namen des Musters. Dies vereinfacht die Diskussion unter den Entwicklern

Das Benutzen (und Dokumentieren) von Design Pattern erleichtert das Lesen/Verstehen des Programmcodes.

Design Pattern sind unabhängig von der konkreten Programmiersprache. Das ermöglicht, dass man zunächst abstrakt über mögliche Lösungen sprechen kann. Damit kann auf hohem Niveau über verschiedene Strukturen diskutiert werden, also ohne eine konkrete Lösung (Programmcode).

208

Nachteile

Das Kennen vieler Design Pattern kann dazu verleitenPattern als Wunderwaffe für ein gutes Design anzusehenviele bekannte Pattern zu verwenden und dabei einfachere/elegantere Lösungen zu übersehenden Code unnötig aufzublähenein zu allgemeines (generisches) Problem zu lösen

Entwickler können durch das Kennen vieler Design Pattern dazu verleitet werden, möglichst viele Pattern zu verwenden und dabei übersehen, dass in ihrem Fall vielleicht eine einfachere, elegantere Lösung ohne den Einsatz von Design Pattern möglich gewesen wäre.

Design Pattern können den Code unnötig aufblähen, da durch das Verwenden des Pattern (ev. unnötigerweise) ein allgemeineres Problem gelöst wird.

Entwurfsmuster garantieren nicht, dass der Entwurf gut ist. Insofern ist die Anwendung zu vieler oder ungeeigneter Entwurfsmuster ein Antimuster.

209

Geschichte1970: Erste Sammlung von Entwurfsmustern des Architekten Christopher Alexander1987: Kent Beck und Ward Cunningham, Entwurfsmuster für die Erstellung von GUIs in Smalltalk1988: Erich Gamma, Entwurfsmuster für die Softwareentwickling (Promotion)1989-1991: James Coplien Advanced C++ Idioms1994: Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides Design Patterns - Elements of Reusable Object-Oriented Software (23 Entwurfsmuster)

Gang of Four (Viererbande, GoF)

210

Pattern Schablone

Pattern NameZweck

Wozu dient das Pattern?Szenario/Problem/Kontext

Ein Beispiel ProblemLösung/Struktur/ImplementationVorteile/NachteileVerwendung

AnwendungsgebieteVarianten Verweis auf andere Muster

•Pattern Name und Klassifizierung: Ein beschreibender und eindeutiger Name, welcher zur Identifizierung des Musters dient.

•Zweck: Eine Beschreibung der Ziele hinter dem Muster und der Grund für die Verwendung.•Ein Szenario, bestehend aus einem Problem und einem Kontext, in welchem dieses Muster verwendet werden kann.

•Lösung/Struktur/ Implementation: Eine grafische Darstellung des Musters. Klassen‐und Interaktionsdiagramme können für diesen Zweck verwendet werden sowie eine Auflistung der nötigen Klassen/Objekte und deren Rollen im Muster

•Vorteile/Nachteile: Die Beschreibung der Ergebnisse, Nebenwirkungen und Kompromisse welche mit dem Muster einhergehen.

•Verwendung: Beispiele von realen Anwendungen des Musters.•Optional sind Pattern Variaten anzugeben sowie Verweise auf andere, verwandte Muster.

211

DAO Pattern

Data Acces Object

Als Beispiel wird hier das DAO Pattern (gemäss der vorher angegeben Schablone) vorgestellt.

212

Pattern Name

Data Access Objekt als Verbindungsstelle zwischen den Business Objekten und der Data Source (Datenbank)

213

Zweck

Ein Data Access Object (DAO) dient als Verbindung mit der Datenquelle

Das DAO dient dazu, alle Zugriffe auf die Datenquelle zu abstrahieren und zu kapseln

Die Datenquelle kann beliebig sein: eine relationale Datanbank, ein externer Dienstleister, ein Repository, ein Business-Service (z.B. via CORBA)

214

Szenario/Problem/Kontext

Die meisten Anwendungen benötigen persistente Daten, d.h. Daten, welche nach Beenden der Applikation erhalten bleiben. Bei Änderung der Persistenz-Schicht soll die Applikation möglichst unverändert bleiben. Es gibt Anwendungen, welche (gleichzeitig) auf Daten zugreifen müssen welche sich auf verschiedenen Systemen befinden. Gewisse Daten werden durch externe Systeme zur Verfügung gestellt: Business-to-Business Integration-Systeme, Kreditkarte Büro-Services, …

215

Lösung/Struktur/Implementation

•Jeder Fachklasse kann ein DAO‐Objekt zugeordnet werden, welches den Datenzugriff für diese Fachklasse kapselt. Das ermöglicht eine direkte Verbindung zwischen Business‐Objekt und DAO‐Objekt, ist sehr effzizient, führt aber zu Abhängigkeiten zwischen Fachklassen und DAO‐Schnittstelle.

216


Das BusinessObject repräsentiert die Client Daten (Fachklassen). Es benötigt die Daten-Quelle um (indirekt) Informationen zu lesen und zu speichern.Das DAO abstrahiert den Zugriff auf die Daten-Quelle und enthält Operationen zum Lesen und Schreiben von Daten.DataSource represäntiert den Daten Zugriff. Dies kann eine DB Schnittstelle, ein File, ein anderes System, …seinTransferObjekt dient zum Transportieren von Daten von und zu der Daten-Quelle.

217

Beispiel: Finde Dozent zu Kurs

Wir nehmen als Beispiel eine Kurs‐Organisation, wo jedem Kurs ein Dozent zugerodnet ist.

218


public class PersonDAO{private static final String DRIVER_CLASS = “ . . . ";private static final StringCONNECTION_URL = “ . . . ";private Connection connection;

public PersonDAO () {

private Connection getConnection(){if (this.connection == null) {try {

// crate new connection

}return connection;

}. . .

219


private static final String query = “select . . .";private PreparedStatement stmt =

connection.prepareStatement(query);

public Person getProfessorOfCourse(Course course) {try {stmt.setInt(1, personId);ResultSet rs = readByIdStmt.executeQuery();

if (rs.next())return null;

elsereturn new Person(rs.getString(...), ...);

} catch(SQLException e) {. . .

}

}

•Jeder Fachklasse kann ein DAO‐Objekt zugeordnet werden, welches den Datenzugriff für diese Fachklasse kapselt. Das ermöglicht eine direkte Verbindung zwischen Business‐Objekt und DAO‐Objekt, ist sehr effzizient, führt aber zu Abhängigkeiten zwischen Fachklassen und DAO‐Schnittstelle.

220

Vorteile

Das DAO versteckt die Implementierungs-Details der Persistenz-Schicht vor seinen Kunden

Transparenter Zugriff. Wenn die zugrunde liegende Datenquelle ihre Implementierung ändert, bleibt die DAO Schnittstelle erhalten, verlangt also von ihren Kunden keinerlei Anpassungen

einfache MigrationDB-Zugriffs-Code (wie z.B. SQL-Anweisungen) ist in das DAO ausgelagert

Verbesserte Lesbarkeit der Business Objekte

221

Nachteile

Die DAOs legen eine zusätliche Schicht zwischen die Business Objekte und die Datenquelle

Mehr Klassen/Objekte, ev. umkopieren von Daten nötig, …

Benutzen einer Factory Klasse führt zu mehr Flexibilität, kompliziert aber das Gesamt-Design und macht die Implementierung aufwändiger

222

Verwendung

Das DAO Pattern wird sinnvollerweise angewandt wenneine Entkoppelung zwischen Business-Schicht und Daten-Quelle sinnvoll erscheint

einfachere Business Schichtverschiedene Daten-Quellen vorhanden sindeine einfache Migration der Daten-Quelle möglich sein soll

223

Varianten

Entkoppelung der Business-Schicht von den einzelnen DAO Klassen durch Benutzen einer DAOFactory (sinnvoll, falls es viele DAO-Klassen gibt)Entkoppelung von der DAOFactory durch eine AbstractFactory, falls verschiedene Datenbanken unterstützt werden sollen.

Erzeugungsmuster

224

Verweis auf andere Muster

Verwandte Muster sindTransfer ObjectEin DAO verwendet Transfer Objekte, um Daten von und zu den Business Objekten zu transportieren.

Factory Method / Abstract FactoryUm die Business Objekte von ihren DAOs zu entkoppeln können Factory-Methoden angewandt werden.Falls zusätzliche Flexibilität zur Erzeugung der DAOs nötig ist, kann das Abstract Factory-Muster eingesetzt werden.

BrokerEine weitere Entkoppelung wird durch das Broker-Pattern erreicht, bei diesem ist der Zugriff auf die Daten-Quelle als Service implementiert.

225

Multitier Architecture

Schichten Architektur

226

Pattern Name

Als Schichtenarchitektur (Multitier Architecture / n-tier Architecture) bezeichnet man ein Architekturmuster, bei der eine Applikation in mehrere eigenständige Schichten (Layers, Module) unterteilt wird.Am bekanntesten ist das OSI-Schichtenmodell (Betriebssystem-Theorie).

Das OSI‐Modell (im englischen: Open Systems Interconnection Reference Model) wurde seit 1979 zur Standardisierung von Datenverkehr zwischen Computeranwendungen entwickelt und ist heute Grundlage für jede Kommunikation zwischen Applikationen auf Computern. Es beschreibt ein Metamodell verschiedener Spezifikationen, welches Herstellern von Soft‐und Hardware erlaubt über fest definierte Schnittstellen miteinander Informationen auszutauschen.

Die Idee der Aufteilung der verschiedenen Aufgaben in verschiedene Schichten wird heute vorallem bei Web‐Applikationen eingesetzt.

227

Zweck

Eine Schichten-Architektur ist ein häufig angewandtes StrukturierungsprinzipDurch eine Schichtenarchitektur wird die Komplexität der Abhängigkeiten innerhalb des Systems reduziert

geringe Kopplung hohe Kohäsion

Schichten verhindern Zyklen im Abhängigkeits-graphenSchichten-Architekturen sind leicht verständlich und gut wartbar

In einem System mit starker Kohäsion ist jede Programmeinheit (hier jede Schicht) verantwortlich für genau eine wohldefinierte Aufgabe oder Einheit.

228


Die einzelne Aufgaben des Software-Systems werden dabei jeweils einer Schicht (tier/layer) zugeordnet. Oftmals werden Schichtenarchitekturen nach der Anzahl der verwendeten Schichten unterteilt, die häufigsten sind die 2 oder 3-Schichten Architektur.Jede Schicht darf auf darunter liegende Schichten zugreifen, nicht aber auf eine darüber liegende.

Durch Aufteilen einer Anwendung in Schichten, wird es möglich, jede dieser Ebenen für sich zu implementieren oder zu ersetzen.

Unter einer Zwei‐Schichten Architektur wird üblicherweise eine Aufteilung in einen leistungsfähigen Datenbankserver und mehrere Clients verstanden, die vom Server bedient werden. Die Verarbeitungslogik wird dann aufgeteilt zwischen Client und Server (z.B. mit Hilfe von stored procedures in der Datenbank).

Eine dreischichtige Architektur besteht aus•Präsentationsschicht: (client tier, Front‐End ) verantwortlich für die Repräsentation der Daten, Benutzereingaben und die Benutzerschnittstelle.

•Logikschicht: (application‐server tier, Business‐Schicht, Middle Tier) beinhaltet alle Verarbeitungsmechanismen. Hier ist die Anwendungslogik vereint.

•Datenhaltungsschicht: (data‐server tier, back end) enthält die Datenbank und ist verantwortlich für das Speichern und Laden von Daten.

Die Begriffe Schicht und Tier werden häufig synonym verwendet. Allerdings ist eine Schicht eher die logische Strukturierung der Software‐Lösung, während ein Tier die physikalische Strukturierung der System‐Infrastruktur darstellt (welcher Teil befindet sich auf welchem Server).

229


Typisches Beispiel: 3-Schichten Web-Applikation

230

Vorteile

Mehr-Schichten Architekturen sind sehr gut skalierbar und weisen einen hohen Grad an Flexibilität auf.Einzelne Schichten sind einfach austauschbar. Bei Veränderung der Schnittstellen/Interfaces sind nur die beiden angrenzenden Schichten betroffen.Schichtenarchitekturen kapseln Maschinen-Abhängigkeiten und sind daher leicht portierbar.

231

Nachteile

Es ist oft schwierig Systeme sauber in Schichten zu strukturieren. Zwischen den Schichten sind zusätzliche Klassen/Interfaces nötigZusätzlicher Overhead durch die Auftrennung in Schichten (Weiterleitung der Meldungen)

Performanz-ProblemeEine (zu) grosse Anzahl Schichten verursacht eine komplizierte Struktur

232

Verwendung

Mehr-Schichten Architekturen sind von Vorteil wenn grosse Skalierbarkeit und Flexibilität der Applikation erfordert ist. der Austauch einzelne Schichten einfach sein soll.Schnittstellen stabil bleiben (Standardschnittstellen)Komponenten und Hardware/Software-Plattformen austauschbar sein sollen es möglich sein soll Komponenten mit komplexer Funktionalität weiter aufzuteilendas System von mehreren Teams mit klaren Verantwortlichkeiten erstellt werden soll

233


Verwandte (Strukturierungs-) Muster sindClient/Server: Services werden von verschiedenen Servern angeboten und von den Clients zur Lösung ihrer Aufgaben benutztModel/View/Controller: Strukturierung in die drei Einheiten Datenmodell (Model), Präsentation (View) und Programmsteuerung (Controller).

234

Visitor Pattern

Besucher Verhaltensmuster

Als Beispiel wird hier das DAO Pattern (gemäss der vorher angegeben Schablone) vorgestellt.

235

Pattern Name

Vistor Pattern (Besucher Entwurfsmuster)

Ein Visitor Objekt kapselt Operationen, welche auf den verschiedenen Elementen einer Objekt-Hierarchie (wie zum Beispiel verschiedene Dokument-Typen) ausgeführt werden müssen.

236

Zweck

Operationen oder Funktionalitäten, welche eine ganze Objekt-Hierarchie (z.B. alle Dokument-Klassen) betreffen, werden mit Vorteil in eine separate Klasse (Visitor) ausgelagert.Dies kann auch für Operationen gelten, welche Informationen aus den Objekten einer Klassenhierarchie sammeln müssen.

237

Szenario/Problem/Kontext

Die Integration verschiedener Hilfs-Operationen (print, normalize, sort, transform, …) in die Klassen einer Objektstruktur ist oft schwierig.

Bei Änderungen oder Erweiterungen zum Beispiel um eine neue Funktionalität müssen alle Klassen verändert/erweitert werden.

Das Besuchermuster lagert die Operationen in externe Besucherklassen aus. Neue Operationen können dadurch ohne Veränderung der betroffenen Elementklassen definiert werden.

238


239


PrintVisitor / SortVisitorimplementiert die visit-Funktion des Interfacedelegiert die auszuführende Aufgabe an eine

interne Operation

Document Interface/Basis Klassedeklariert eine Schnittstelle zum Empfang

eines Besuchers (accept-Methode)KonkretesElement (Order, Bill, Report, …)

implementiert die accept Methode

240


public interface Visitor {public void visit(Order order);public void visit(Bill bill);public void visit(Report report);

}

public class PrintVisitor implements Visitor {

public void visit(Order order) {print(order);

}

private void print(Order order) {// print the order

}. . .

Analog dazu der SortVisitor:

public class SortVisitor implements Visitor {public void visit(Order order) {

sort(order);}public void visit(Bill bill) {

sort(bill);}public void visit(Report report) {

sort(report);}private void sort(Order order) {

// sort the order items . . .}private void sort(Bill bill) {

sort the bill items . . .}private void sort(Report report) {

// sort the report items . . .}

}

241


public class Order implements Document{

public void accept(Visitor visitor) {visitor.visit(this);

}. . .

}

public class Bill implements Document{

public void accept(Visitor visitor) {visitor.visit(this);

}. . .

}

Alle Benutzer des Visitor Patterns sind von einem gemeinsamen Interface (hier Document) abgeleitet.

public interface Document {public void accept(Visitor visitor);

}

242

Vorteile

Neue Operationen können durch die Definition neuer Visitors einfach hinzugefügt werden. Verwandte Operationen werden im Visitor zentral verwaltet und von besucherfremden Operationen getrennt. Das Visitor Pattern kann für beliebige Klassenhierarchien verwendet werden.

243

Nachteile

Für neue konkrete Elemente (z.B. neue Document-Klassen), müssen alle visit-Methoden aller Visitors implementiert werden.

244

Verwendung

Visitor Pattern ist sinnvoll anwendbar wennviele unterschiedliche, nicht verwandte Operationen auf den Objekten einer Klassen-Hierarchie realisiert werden sollensich die Klassen der Hierarchie nicht / nur selten ändernauf der Klassen-Hierarchie häufig neue Operationen integriert werden müssen ein Algorithmus über eine ganze Klassen-Hierarchie verteilt arbeiten, aber zentral verwaltet werden soll

245


Ein verwandtes Muster ist dasKomposit Pattern

Gleichbehandlung aller Elemente einer Baumstruktur (Stückliste)

OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und...

Documents

Transcript of OOAD - sws.bfh.ch · PDF file2 1. Einführung Grundprinzipien des OOAD Viele der Ideen und...