OOAD. Objektorientierte Software Analyse und Design mit UML. Dr. Beatrice Amrhein

Transkript

1 OOAD Objektorientierte Software Analyse und Design mit UML Dr. Beatrice Amrhein

2 1. 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! 2

3 Kurs Überblick Use Cases 3. Aktivitäten 4. Zustände 5. Klassenstruktur 6. Beziehungen 7. Weitere Strukturdiagramme 8. Interaktion, Kommunikation 9. Analyse Muster 10. GUI Prototyp 11. Datenbank Design 3

4 Lernziele Vorgehensweise in objektorientierter Software Analyse und Design Software Analyse Design (Entwurf) Modellierung Dokumentation 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. 4

5 Lerninhalte Konzepte der Modularisierung Grobanalyse Modell Mind Map, Produkt-Karton Use Cases Szenarien 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. 5

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 Realisierung 100% Designer Codierer 0 % Implementations- Beginn Zeit 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. 6

7 Fehlerkosten Projekt Idee Lasten-/Pflichtenheft Analyse Modell Grob Design In jedem Schritt etwa mal 10 Design Phase Detail Design Programmierung Missverständnis, Redesign, Fehlerfall, 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 (Codier Fehler) -> wenig Aufwand Zwei 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 beheben Vier Schritte zurück (Fehler in der Spezifikation) -> riesiger Aufwand! 7

8 Top-Down Entwurf Beginn auf oberster (abstrakter) Ebene Gesamt Aufgabenstellung, Anforderungen, Schrittweise Verfeinerung Problem aufteilen -> Subsysteme Subsystem 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 bereits durch bestehende Software gelöst sind. 8

9 Bottom-Up Entwurf Beginn auf unterster Ebene Lösen der Teilprobleme Schrittweise Einbindung bereits erstellter Teillösungen Nach und nach Zusammensetzen zu einer Gesamtlösung Vereins-Verwaltung Adresse ändern Termine verwalten Buchhaltung Mitglieder erfassen Mitglieder Beiträge Vorteil: schnelle Lösung von einzelnen Problemen, sofort einsetzbar Nachteil: Kein Gesamtkonzept, Teillösungen passen eventuell nicht richtig zusammen, schwierig planbar, ev. schlecht wartbar, Fehler beheben kann teuer werden (viele unterschiedliche Schnittstellen). 9

10 Beide Methoden mischen Alle Requirements erfassen Analyse Phase Klare Abgrenzung (aller Teile) System-Grenzen Schnittstellen Ausgewählte Prototypen entwickeln Kunden Feedback Detail-Design Design Variante entscheiden Realisierung 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. 10

11 Analyse Phase Anforderungen an das Zielsystem ermitteln beschreiben und validieren Objekte/Komponenten bestimmen Hauptaufgaben der Komponenten bestimmen Erstellen eines konsistenten und vollständigen 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? 11

12 Ablauf der Analyse Systemidee, Zielsetzung Fact Sheet Produkt-Karton Stakeholder bestimmen Umfeld, Abgrenzung System-Kontext Anwendungsfälle Abläufe Use Case Diagramme Aktivitätsdiagramme Szenarien,... Nichtfunktionale Anforderungen Sicherheit Performance Wartbarkeit... Glossar Datenobjekte, Komponenten Komponenten-Diagramm Fachklassen-Diagramm Analyse Modell 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). 12

13 Produkte der Analyse Phase Lastenheft (System-Anforderungen) Fachkonzept (Grobdesign) Dynamisches Modell Funktionsabläufe durch Use Cases, Szenarien, Aktivitätsund Zustands-Diagramme, Statisches Modell Datenaspekte, Komponenten, Assoziationen, Modell-Beschreibungen / Dokumentation GUI Prototyp Das Fachkonzept sollte 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, die Zugriffsrechte, die Hilfestellungen für den Benutzer, 13

14 Design Phase In 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. 14

15 Produkte der Design Phase Software Architektur Beschreibung Komponenten Schnittstellen Klassendiagramme... GUI Design, DB Design Prioritätenliste Implementations und Zeit-Plan Test Plan, Deployment Ü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. 15

16 Vorteile des OO SW-Engineering Ganzheitliche Beschreibung Daten/Informationen Funktionen/Aktionen Objekte Durchgängige Konzepte durch alle Phasen Akteur, Rolle, Aufgabe -> Klassen-Name Aktion -> Operations-Name 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. 16

17 Vorteile des OO SW-Engineering Einfaches Abbilden von Objekten der realen Welt Modularisierung in handliche Einzelteile Einfache Schnittstellen zwischen den Komponenten Wiederverwendbarkeit Erweiterbarkeit Austauschbarkeit 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. 17

18 OO Design Prinzipien Abstraktion, Geheimnisprinzip Datenkapselung Polymorphie gleiche Operation kann unterschiedliche Ausprägung haben. Vererbung/Erweiterung/Einschränkung Persistenz/Lebenszeit Objekte leben so lange wie sie gebraucht werden Modularisierung Komponenten zu einem Ganzen zusammensetzen 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. 18

19 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 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/getter Open-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. 19

20 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. 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 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). 20

21 UML Überblick Die wichtigsten Diagramme Vgl. Oestereich Klappentexte 21

22 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 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. 22

23 Use Case Beschreibungen Textuelle Beschreibung der Use Cases Grundlage für Systemtests und Abnahme -> Analyse-Phase 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. 23

24 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. 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. 24

25 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. 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. 25

26 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. 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. 26

27 Klassendiagramm (Kap. 5) Festlegen der konkreten Schnittstellen -> Interfaces Aufteilen der verschiedenen Aufgaben (Zuständigkeiten) auf die verschiedene Klassen -> Attribute -> Operationen -> Assoziationen Design Phase 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. 27

28 Komponenten-Diagramm (Kap. 6) Festlegen einer logischen Grob- Struktur Aufteilen der Aufgabenbereiche zu verschiedenen Komponenten Analyse oder Design Phase 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. 28

29 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 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. 29