OOADObjektorientierte Software Analyse und Design mit UML

Dr. Beatrice Amrhein

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!

Einführung

3

Kurs Überblick1. Einführung2. Use Cases3. Aktivitäten4. Zustände5. Klassenstruktur6. Beziehungen 7. Weitere Strukturdiagramme8. Interaktion, Kommunikation9. Analyse Muster 10. GUI Prototyp 11. Datenbank Design

Einführung

4

Lernziele Vorgehensweise in objektorientierter Software

Analyse und Design

Software AnalyseDesign (Entwurf)ModellierungDokumentation

Ein Bild sagt mehr als 1000 Worte

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. 

Einführung

5

Lerninhalte Konzepte der Modularisierung Grobanalyse Modell

Mind Map, Produkt-Karton Use Cases Szenarien, User Stories Subsysteme, Komponenten

Objekt Orientierte Synthese Aktivitäts-, Zustands-Diagramm, … Klassen, Sequenz-Diagramm

Objekt Orientiertes Design Analyse 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‐Pattern und Design‐Heuristiken betrachten, sowie ein erstes GUI‐Design und ein einfaches Datenbank‐Design (Prototyp) entwerfen. 

Einführung

6

SW Entwicklung beginnt im Kopf

Planen ist besser als nachbessern Jedes Problem muss einmal durchdacht werden

besser vorher als nachher Am Anfang sind Änderungen noch einfach machbar

Eine falsche Design- oder Architektur-Entscheidung kann sehr viel Geld kosten

Ein 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 letzten Jahren laufend zugenommen. Bei aufwändigen Projekten ist es enorm wichtig, die Software‐Entwicklung mit Design Methoden und einer sauberen Dokumentation anzufangen. Andernfalls besteht die Gefahr, dass das Projekt scheitert oder sich extrem verteuert, und dass die Software später schlecht wartbar ist. 

Einführung

7

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 (Codier Fehler) ‐> 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!

Fehlerkosten

Projekt Idee

Lasten-/Pflichtenheft

Analyse ModellGrob Design

Design PhaseDetail Design

Programmierung

System Test

Missverständnis,

Redesign,

Fehlerfall, …

In jedem Schrittetwa mal 10

Einführung

8

Analyse Phase Anforderungen an das Zielsystem ermitteln Komponenten/Subsysteme bestimmen Hauptaufgaben der Komponenten bestimmen Erstellen eines Daten-Modells (Struktur und

Semantik) GUI Prototyp (Papier oder Mockup) erstellen

Aber: Implementierungs-Aspekte oder Entscheide nur

falls gefordert.

In der Analysephase geht es vor allem 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/Komponenten für Eigenschaften?• In welchen Beziehungen stehen diese Objekte/Komponenten zueinander?• Was haben die Objekte für Aufgaben?

Einführung

9

Ablauf der Analyse

Systemidee, Zielsetzung

Product VisionFact Sheet       

Wish Lists

Stakeholder bestimmen Umfeld, Abgrenzung

NichtfunktionaleAnforderungen

GlossarDatenobjekte,Komponenten

Komponenten‐DiagrammFachklassen‐Diagramm 

Analyse Modell

System‐Kontext

SicherheitPerformanceWartbarkeit. . . 

Funktionale Anforderungen

Use Cases, User Stories, Aktivitätsdiagramme,. . .

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 (Betriebssystem, Druckerei, Kundenverwaltung, Datenbank, …)?Im Analyse Teil werden die Ideen und Abläufe erfasst, aber noch keine technischen Lösungen beschrieben (ausser sie gehören zu den Anforderungen).

Einführung

10

Produkte der Analyse Phase Produkt Vision, Wish-Lists, System-Anforderungen Fachkonzept (Grobdesign)

Dynamisches ModellFunktionsabläufe durch Use Cases, Features, Epics, User Stories, Aktivitäts‐Diagramme, …

Statisches ModellDatenaspekte, Komponenten, Assoziationen, … 

Modell-Beschreibungen / DokumentationGUI Prototyp

Priorisiertes Product Backlog

Einführung

11

Design PhaseIn der Design-Phase werden normalerweise die

technischen Details bestimmt: Design Pattern, Schnittstellen

->Klassen, Interfaces, Packages, … Gesamt-Architektur Anforderungen an die Benutzeroberfläche Datenhaltung -> DB Design Performance, Verteilung, Wartbarkeit, …

-> Ziel-Plattform Programmier-Sprache, -Umgebung …

In der Analysephase geht man oft von einer idealen Umgebung aus, das heisst, wir kümmern uns noch nicht um Probleme bei der Umsetzung, um Speicherplatz, um Kosten, Aufwände oder Effizienz. In der Design‐Phase geht es dann um das „wie“. Sie spezifiziert, auf welcher Plattform die Anwendung  mit den geforderten technischen Randbedingungen zu realisieren ist. Allerdings sind wir dabei immer noch in der Konzept‐Phase, das heisst wir beginnen noch nicht mit der Implementation.  

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

Einführung

12

Produkte der Design Phase Software Architektur Beschreibung

Komponenten, Subsysteme Schnittstellen Klassendiagramme . . .

GUI Design, DB Design Prioritätenliste

Sprints / Zeit-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, DB‐Design, Testing, …) aufgeteilt werden. 

Einführung

13

Vorteile des OO SW-Engineering

Ganzheitliche BeschreibungDaten/Informationen Funktionen/Aktionen

Durchgängige Konzepte durch alle Phasen Akteur, Rolle, Aufgabe -> Klassen-Name Aktion -> Operations-Name

Objekte

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, in einem Objekt (bzw. einer Klasse) zusammenzufassen und nach aussen hin zu kapseln, so dass Operationen fremder Objekte diese Daten nicht versehentlich manipulieren können.Die Namen der Klassen und Operationen sollten dabei möglichst den bereits in den vorherigen Phasen verwendeten Namen entsprechen.

Einführung

14

Einfaches Abbilden von Objekten der realen Welt Modularisierung in „handliche“ Einzelteile Einfache Schnittstellen zwischen den

Komponenten Wiederverwendbarkeit Erweiterbarkeit Austauschbarkeit

Vorteile des OO SW-Engineering

Ein wichtiger Vorteil der objektorientierten Programmierung ist, dass sich die Objekte der realen Welt (relativ) einfach in Klassen abbilden lassen. Ihre Aufgaben/Rollen sind in natürlicher Weise fassbar und dokumentierbar.Ausserdem erlaubt sie 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. 

Einführung

15

Abstraktion, Geheimnisprinzip: 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 Ganzen kombinieren, wenn sie klare Schnittstellen definieren (und einhalten) Kompatibilität.

OO Design Prinzipien Abstraktion, Geheimnisprinzip

Datenkapselung Polymorphie

Wiederverwendung von Methoden-Namen Vererbung/Erweiterung/Einschränkung Persistenz/Lebenszeit

Objekte leben so lange wie sie gebraucht werden

Modularisierung Komponenten zu einem Ganzen

zusammensetzen

Einführung

16

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, DoxygenUniform 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.

OO Design Prinzipien Single Responsibility Prinzip

Klare Verantwortlichkeit Self-Documentation Prinzip

Sprechende Namen, dokumentierter Code Uniform Access Prinzip

getter / setter Methoden Open-Closed Prinzip

Fixe Schnittstellen, Unterschiedliche Ausführungen

Substitution Prinzip Konsistente Vererbung

Einführung

17

Interface Segregation: Interfaces sollten so aufgeteilt werden, dass sie den Bedürfnissen der Clients (der Anwendung) entsprechen ‐> keine unnötigen AbhängigkeitenPersistence Closure: Objekte werden mit all ihren Attribut‐Werten (in der Datenbank) gespeichert‐> späteres Wiedereinlesen stellt den gleichen Zustand wieder 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).

OO Design Prinzipien Interface Segregation Prinzip

Abhängigkeiten so klein wie möglich halten Persistence Closure Prinzip

Speichern des ganzen Objekt Zustands Acyclic Dependencies Prinzip

Möglichst keine zyklischen Abhängigkeiten Gesetz von Demeter

Objekte kommunizieren vor allem mit ihren Nachbarn

Design by Contract Klare, verifizierbare Schnittstellen,

Vorbedingungen, Nachbedingungen, Invarianten.

Einführung

18

UML Überblick

Die wichtigsten Diagramme

Vgl. Oestereich Klappentexte

Einführung

19

Mit Hilfe einer Use Case Beschreibung können die verschiedenen Use Cases genauer spezifiziert werden.Den Ablauf eines einzelnen Use Case kann dann textuell oder (bei komplexen Prozessen) mit Hilfe eines Aktivitäten‐Diagramms spezifiziert werden.Die Zustände eines Objekts (z.B. Meal: ordered, cooked, eaten, payed), werden separat mit Hilfe eines Zustandsdiagramms definiert. 

Use Case Diagramm (Kap. 2)

Grobe Beschreibung der zentralen Aufgaben Erfassen der wichtigsten User Bedürfnisse

-> Wer will was? Beschreibt kein Verhalten, keinen Ablauf Sehr früh im Prozess

-> Analyse-Phase

Einführung

20

Use Case Beschreibungen können benutzt werden, um die einzelnen Use Cases genauer zu spezifizieren. Die daraus abgeleiteten Szenarien lassen sich später sehr einfach in Test Szenarien umformulieren. Jedes Szenario ergibt einen separaten Test.

Use Case Beschreibungen Textuelle Beschreibung der Use Cases Grundlage für Systemtests und Abnahme

-> Analyse-Phase

Einführung

21

Use Case Szenarien sind (fast) das selbe wie User Stories (Scrum). 

User Stories werden leicht anders formuliert, nämlich in der Art: ‐ Als Kundenberater möchte ich mit Cargo‐Cruise für einen bestehenden Kunden auf dem Frachter Grande San Paolo für den November eine Doppelkabine von Rio de Janeiro nach Tilbury reservieren können.‐ Als Kundenberater möchte ich mit Cargo‐Cruise den nächstmöglichen Termin für zwei freie Plätze für eine Rundreise Salermo‐Ismir‐Alexandria‐Salermo auf einem beliebigen Frachter herausfinden können.

In Scrum werden dann die User Stories in die einzelnen Tasks aufgeteilt, also einzelne Aufgabenteile von ca. 1‐4 Wochen.

Use Case Szenarien Textuelle Beschreibung der Szenarien Test Szenarien ableiten

Beispiele:

Der bestehende Kunde A möchte auf der Grande San Paolo im November eine Doppel-Kabine von Rio de Janeiro nach Tilbury buchen.

Der neue Kunde B fragt nach den nächstmöglichen Terminen für zwei freie Plätze für die Rundreise von Salerno via Ismir und Alexandria zurück nach Salermo.

Einführung

22

Komplexe Use Cases können mit Hilfe eines Aktivitätsdiagramms genauer erklärt werden. Aktivitäts‐Diagramme sind für den Leser (Stakeholder/Prüfer/Entwickler) im Allgemeinen schneller und einfacher zu verstehen und überprüfen als lange, verschlungene WENN, FALLS, SONST – Texte.Im Verlauf der Design Phase werden diese Abläufe weiter verfeinert und konkretisiert (Ausnahme‐, Fehlerfälle), was zu einer Verfeinerung/Verbesserung der Diagramme führt.

Aktivitäts-Diagramm (Kap. 3)

Erfassen der komplexen Abläufe (was passiert wann -> Reihenfolge?)

Konkretisieren der Use Cases Erster Entwurf schon früh im Prozess (Analyse) Verfeinerung/Konkretisierung im Verlauf der

Analyse oder Design Phase.

Einführung

23

Objekte welche sich im Verlauf der Applikation in verschiedenen Zuständen befinden können, werden mit Hilfe eines Zustands‐Diagramms genauer erklärt. Zustands‐Diagramme sind für den Leser (Stakeholder/Prüfer/Entwickler) im Allgemeinen schneller und einfacher zu verstehen und überprüfen als lange, verschlungene WENN, FALLS, SONST – Texte.

Oft wird erst während der Design Phase festgestellt, dass weitere Zustände nötig sind. Eine Korrektur/Verbesserung des Diagramms wird dann nötig.Ein erstes grobes GUI (Navigations‐Schritte) wird ebenfalls mit Hilfe eines Zustands‐Diagramms gefunden.

Analog sind auch Zeitdiagramme, welche die verschiedenen Zustände eines Objekts/Systems in der zeitlichen Abfolge beschreibt.

Zustands-Diagramm (Kap. 4)

Beschreiben der verschiedenen Zustände eines Objekts in zeitlicher Reihenfolge

Beschreibung der GUI Navigation Erster Entwurf schon früh im Prozess (Analyse) Verfeinerung/Konkretisierung im Verlauf der

Analyse oder Design Phase.

Einführung

24

Klassendiagramme definieren dann die konkret zu implementierenden Interfaces und Klassen, deren Attribute und Operationen. Üblicherweise werden in einem Klassendiagramm entweder nur die wichtigsten Klassen, oder nur die Klassen eines Paketes, oder nur die Klassennamen gezeichnet. Andernfalls werden die Klassendiagramme zu komplex und damit unlesbar.

Jede Klasse hat eine Rolle/Aufgabe/Zuständigkeit. Die dazu nötigen Attribute und Operationen werden hier spezifiziert.

Klassendiagramm (Kap. 5)

Festlegen der konkreten Schnittstellen-> Interfaces

Aufteilen der verschiedenen Aufgaben (Zuständigkeiten) auf die verschiedene Klassen -> Attribute-> Operationen-> Assoziationen

Design Phase

Einführung

25

Sobald die wichtigsten Aufgaben eines Systems bekannt sind, können diese in verschiedene Aufgaben‐Bereiche zerlegt und entsprechend verschiedenen Komponenten zugeordnet werden. Jede der Komponenten ist dann für eine Reihe von verwandten Aufgaben zuständig. Jede Komponente wird dann später in Pakete (Packages) aufgeteilt, die Pakete bestehen dann wiederum aus Interfaces und Klassen.

Komponenten-Diagramm (Kap. 6)

Festlegen einer logischen Grob-Struktur

Aufteilen der Aufgabenbereiche zu verschiedenen Komponenten

Analyse oder Design Phase

Einführung

26

Zum Überprüfen der Vollständigkeit eines Modells können zentrale oder komplexe Abläufe mit Hilfe eines Sequenzdiagramms modelliert werden.Dadurch kann festgestellt werden, ob alle nötigen Klassen und Operationen vorhanden sind und ob die nötigen Referenzen existieren.

Dieses Sequenzdiagramm gibt zum Beispiel einen Hinweis darauf, dass das Klassendiagramm auf der vorderen Seite nicht vollständig ist.

Sequenz-Diagramm (Kap. 7)

Aufzeichnen eines konkreten Ablaufs auf den Objekten der Klassen (mit konkreten Operationen, Parametern, Rückgabewerten)

Überprüfen der Konsistenz/Vollständigkeit des Modells (Operationen, Assoziationen)

Design- oder Implementations-Phase

Einführung