Dr. Beatrice Amrhein. April 13

Transkript

1 Dr. Beatrice Amrhein April 13

2 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 3

4 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 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. 5

6 Die Komplexität der zu realisierenden Informatik Projekte hat in den letzten Jahren laufend zugenommen. Bei so 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 die Software später schlecht wartbar ist. 6

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

9 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 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 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 für Eigenschaften? In welchen Beziehungen stehen diese Objekte zueinander? Was haben die Objekte für Aufgaben? 11

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

13 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, die Zugriffsrechte, die Hilfestellungen für den Benutzer, 13

14 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, Schichtung, Speicherbedarf, nötige Algorithmen, zu benutzende Datenstrukturen und viele andere technische Details festgelegt. 14

15 Ü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. 15

16 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 Ein wichtiger Vorteil der objektorientierten Programmierung ist, dass sich die Objekte der realen Welt (relativ) einfach in Klassen abbilden lassen. Ihre Aufgaben/Rollen sind natürlich sprachlich 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 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 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 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 Vgl. Oestereich Klappentexte 21

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

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

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

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

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