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