Objektorientierte Analyse und Design

Transkript

1 Hochschule Darmstadt Fachbereich Informatik Objektorientierte Analyse und Design 1. Motivation SS 2011 Einige Folien dieser Vorlesung entstammen Präsentationen von Prof. U. Andelfinger, B. Humm, G. Raffius OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 1

2 1. Motivation Planspiel Stellen Sie sich vor, Sie sollen Software entwickeln für ein Projekt, dessen Fachgebiet Sie nicht kennen (z.b. ein Verwaltungssystem für ein Krankenhaus) Randbedingungen der Kunde kennt sich nicht mit IT aus die Aufgabe ist nicht ganz trivial die Software hat eine Wartungsverpflichtung von 10 Jahren Wie würden Sie vorgehen? Welche Arbeitsergebnisse würden Sie anstreben? OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 2

3 1. Motivation Grundidee OOAD Problem: Wie entwickle ich ein komplexes System? Analysiere die reale Welt Abstrahiere daraus ein Modell mit den wesentlichen Daten und Klassen (Objekten) und deren Beziehungen zueinander Entwerfe ein detailliertes Modell, das auf dem abstrakten Modell basiert Setze das Ergebnis um Arzt.cpp OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 3

4 1. Motivation Abstraktionsebenen gedankliche Ebene Reale Welt Abstraktion logische Ebene (Modell) OOA-Ebene OOD-Ebene Implementierungskonzepte Codierung physische Ebene (Implementierungsebene) Programm Arzt.cpp Abstraktionsebenen der objektorientierten Systementwicklung (4-Schichten-Modell) OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 4

5 1. Motivation Phasenmodell der objektorientierten Systementwicklung reale Welt Code Konsistenz Abstraktion Isomorphismus Konkretisierung Abbildung Informationsgehalt Design- Modell Coderahmen Analyse-Modell OOA (Analyse) OOD (Design) OOP (Programmierung) Entwicklungs -phase OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 5

6 1. Motivation Phasen und Tätigkeiten (I) OOA: Objektorientierte Analyse Ziele: - Anforderungen an das zu entwickelnde Softwaresystem erfassen und beschreiben - ein gemeinsames Verständnis der Produktidee bei Auftraggeber, Auftragnehmer, Benutzer und Entwicklern schaffen Tätigkeiten: - Herausarbeiten der wesentlichen Sachverhalte, Vernachlässigen von Details - Dokumentation von Anwendungsfällen (Szenarien) - Dokumentation der Systemidee, der Leistungsmerkmale, der Rahmenbedingungen und Voraussetzungen - Entwicklung eines objektorientierten Analysemodells ("OOA-Modell", "Domänenmodell") Umsetzung - als Text und/oder als Modell - weitgehend unabhängig von der späteren konkreten Umsetzung - Modellierung oft mit Elementen der Unified Modeling Language (UML) OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 6

7 1. Motivation Phasen und Tätigkeiten (II) OOD: Objektorientiertes Design Ziele: - Erarbeitung eines Lösungskonzepts zu einem gegebenen Problem / gegebenen Anforderungen(vgl. OOA) - Dokumentation des Konzept als Vorarbeit für die Implementierung Tätigkeiten: - das in der OOA erstellte Analysemodell wird kontinuierlich weiterentwickelt und darauf aufbauend ein objektorientiertes Designmodell ("Architektur / Design") erstellt - Festlegung von Verantwortlichkeiten, Schnittstellen, Implementierungsvorgaben - Dokumentation von Klassen, Objekten, Komponenten (uvm.) und deren Interaktion Umsetzung - Modellierung in der Regel mit Elementen der Unified Modeling Language (UML) - Das Designmodell berücksichtigt neben den fachlichen Aspekten des Auftraggebers auch technische Gegebenheiten (Betriebssystem, Zielsprache etc.) OOP: Objektorientierte Programmierung Umsetzung des OOD-Modells in ein objektorientiertes Computerprogramm OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 7

8 1. Motivation Modelle und Inhalte Beschreibung der wesentlichen Klassen mit Verantwortlichkeit & Attributen unabhängig vom Zielsystem Ergänzung um Umsetzungsdetails Komponenten mit Verantwortlichkeit & Schnittstellen Detaillierte Beschreibung von Klassen, Operationen, Attributen in der Zielsprache Case-Tool macht den Abgleich zwischen Designmodell und Code Forward Engineering Analyse-Modell Konkretisierung Design-Modell Round-trip Engineering Code Reverse Engineering OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 8

9 1. Motivation Inhalte der Vorlesungen zur Softwaretechnik OO: Grundlagen der Objektorientierung OOAD: Analyse und Design UML: einheitliche und präzise "Sprache" zur Dokumentation Modellierung und Darstellung Inhalt und Einsatz der diversen Diagramme OOAD Entwicklung: Entstehung der Softwaretechnik Vorgehen Techniken zum Vorgehen in Projekten Prozesse allgemeine und systematische Vorgehensmöglichkeiten Qualität Beurteilung der Arbeitsergebnisse SWE Planung Arbeiten mit Plänen und Ressourcen Organisation Aufbau von Teams Projektmgmt OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 9

10 1. Motivation Konzept von Praktikum und Vorlesung zur Softwaretechnik OOAD Objektorientierung Analyse und Design Dokumentation der Arbeit - UML "Handwerkszeug" für SW-Entwickler - Gutes Design Praktikum OOAD Umgang mit dem Handwerkszeug - Erste Modellierung - "Entwickeln" eines Mini-Projekts - Arbeit mit der UML - Kennenlernen des CASE-Tools - Kennenlernen der Entw.umgebung SWE Gesamtkonzept / Zusammenhänge - Arbeit in großen Projekten - Anwendung des Handwerkszeugs - Qualitätssicherung - Organisation Praktikum SWE Anwendung der Verfahren aus OOAD und SWE Entwicklung eines Systems in kleinen Teams Möglichst hohe Realitätsnähe - Eigenständige Lösung der Aufgaben - Überprüfung durch Reviews - Aufteilung der Arbeiten im Team OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 10

11 1. Motivation Themen in OOAD im Detail OOAD 1. Motivation 2. Grundkonzepte der Objektorientierung 3. Objektorientierte Software-Entwicklung 4. Objektorientierte Analyse - Use Cases - Aktivitätsdiagramme - Analysemodell 5. Objektorientiertes Design - Darstellung der Statik eines Systems (Klassendiagramm) - Umsetzung von Klassen in C++ - Darstellung der Dynamik eines Systems (Sequenz-, Zustandsdiagramme) - Weitere Diagramme in der UML 6. Welches Design ist das Richtige? 7. Manuelle Prüfverfahren OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 11

12 1. Motivation Lernziele der Veranstaltung OOAD Sie beherrschen die Grundprinzipien der Objektorientierung Sie können Anforderungen an ein zu entwickelnde Softwaresystem erfassen und beschreiben Sie beherrschen die UML als Standard zur Darstellung der (meisten) Ergebnisse Sie können die Statik eines Systems in Diagrammen darstellen? Sie können die Dynamik eines Systems in Diagrammen darstellen? Sie können ein adäquates Lösungskonzepts zu einem gegebenen Problem erarbeiten Sie beherrschen das Handwerkszeug zur Mitarbeit in einem modernen Projekt! OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 12

13 1. Motivation Literatur Brett D. McLaughlin, G. Pollice, D. West: Objektorientierte Analyse & Design von Kopf bis Fuß", O'REILLY, 2007 Mario Winter; Methodische objektorientierte Software-Entwicklung; dpunkt-verlag; 2005 Chonoles, Schardt: UML2 für Dummies; Wiley-VCH; 2003 Rupp, Queins, Zengler: UML2 glasklar; 3. Auflage, Hanser-Verlag; 2007 OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 13

14 Hochschule Darmstadt Fachbereich Informatik Objektorientierte Analyse und Design 2. Grundkonzepte der Objektorientierung OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 14

15 2. Grundkonzepte der Objektorientierung Historie Erfinder der objektorientierten SW-Entwicklung Prof. Dr. e. h. Kristen Nygaard ( ), Oslo, Norwegen Department of Informatics University of Oslo - Erfinder der Programmiersprache SIMULA 67, die das Klassenkonzept in die Programmiersprachenwelt einführte (zusammen mit Ole-Johan Dahl) - Erfinder der objektorientierten Programmiersprache BETA (zusammen mit B. B. Kristensen, O. L. Madsen, B. Møller-Pedersen). Bertrand Meyer, Programmiersprache Eiffel, 1988; kurz danach auch C++ OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 15

16 2. Grundkonzepte der Objektorientierung Objektorientierung (OO) OO ist ein Ansatz zur Entwicklung von Software vorhergehende Ansätze betrachteten Daten und Operationen darauf unabhängig voneinander nun werden die zu verarbeitenden Daten anhand ihrer Eigenschaften und der möglichen Operationen klassifiziert und gruppiert - Teile die zu beschreibende "Welt" in Objekte mit Eigenschaften und Operationen auf - das Zusammenspiel der Objekte erfolgt über Kommunikation untereinander Anspruch, die "reale Welt" besser nachbilden zu können Umsetzung durch unterstützende Konzepte Klassen Vererbung... Objektorientierung ist seit den 90-ern das zentrale Programmierparadigma OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 16

17 2. Grundkonzepte der Objektorientierung Grundidee Objektorientierung Problem: Wie entwickle ich ein komplexes System? Analysiere die Welt der Anwendung bestimme Objekte die darin vorkommen Entwickle die Anwendung basierend auf den wesentlichen Daten und Klassen (Objekten) und deren Beziehungen zueinander Arzt.cpp OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 17

18 2. Grundkonzepte der Objektorientierung Die Herausforderung Bildquelle: Wikipedia Objektorientierung an sich ist einfach. Betrachte (und definiere) Dinge in der Welt der Anwendung und extrahiere die wesentlichen Teile ( Objekte / Attribute / Klassen) Untersuche das Zusammenspiel / die Kommunikation der einzelnen Objekte ( Operationen) Betrachte die Welt aus der Sicht eines einzelnen Objekts Gehe davon aus, dass die anderen Objekte schon alles richtig machen spiele iterativ die Anwendungsfälle durch, bis das skizzierte System die gewünschte Leistung erbringen kann OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 18

19 2. Grundkonzepte der Objektorientierung Abstraktion Abstraktion ist das Weglassen von unwesentlichen Details, so dass die Essenz der Sache übrig bleibt Beispiel: Karte der U-Bahn in London, 1928 (links) und 1933 (rechts) Bildquelle: J. Kramer. Is Abstraction the Key to Computing? Communications of the ACM, Vol. 50, No. 4, April 2007 OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 19

20 2. Grundkonzepte der Objektorientierung Einführungsbeispiel: Makler-Software Sie sollen eine Software für den Verkauf von Häusern entwickeln welche Objekte interessieren Sie? was ist wesentlich? was ist unwesentlich? welche Interaktion gibt es mit den Objekten? Bildquelle: R. Hahn OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 20

21 2. Grundkonzepte der Objektorientierung Objekte Haben Attribute Bieten Operationen an :Einfamilienhaus Haustyp = Landhaus Besitzer = Dr. Kaiser Adresse = Königstein Wohnfläche = 400 [qm] Anzahl Bäder = 3 Hat Schwimmbad = ja Garten = 5000 [qm] Baujahr = 1976 Verkaufspreis = 2 Mio. [ ] :Einfamilienhaus Haustyp = Bungalow Besitzer = Herzog Adresse = Stiepel Wohnfläche = 250 [qm] Anzahl Bäder = 2 Hat Schwimmbad = nein Garten = 1500 [qm] Baujahr = 1986 Verkaufspreis = 1,5 Mio. [ ] :Einfamilienhaus Haustyp = Stadthaus Besitzer = Urban Adresse = Bochum Wohnfläche = 200 [qm] Anzahl Bäder = 2 Hat Schwimmbad = nein Garten = 400 [qm] Baujahr = 1990 Verkaufspreis = 1 Mio. [ ] anfragen Verkaufspreis anfragen Verkaufspreis anfragen Verkaufspreis OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 21

22 2. Grundkonzepte der Objektorientierung Abstraktion für Objekte Trenne Konzept und Umsetzung (Abstraktion) Je nach Anwendung sind unterschiedliche Abstraktionen sinnvoll (je nachdem was für die Anwendung wesentlich ist z.b. Makler, Architekt, Katasteramt,...) Eine Klasse definiert die (gemeinsamen)... Attribute ihrer Objekte Operationen ihrer Objekte Objekte werden oft auch Instanzen einer Klasse genannt Einfamilienhaus Haustyp Besitzer Adresse Wohnfläche Anzahl Bäder Hat Schwimmbad Garten Baujahr Verkaufspreis anfragen Verkaufspreis OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 22

23 2. Grundkonzepte der Objektorientierung Von Objekten zu Klassen... Klasse als Schablone Mitarbeiter-Objekt ändern Name Name Mitarbeiter-Objekt ändern Name Name Geh alt Geh alt ändern Gehalt ändern Gehalt OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 23

24 2. Grundkonzepte der Objektorientierung Kapselung Da Objekte nur noch über Methoden interagieren, kann das Innenleben der Objekte und Klassen verborgen werden Objekt Operation 1 Eine Klasse kapselt Attribute und Operationen Daten Operation 2 Zugriff auf die Daten erfolgt nur über die Operationen Die interne Realisierung ist von außen nicht sichtbar Botschaft Auswahl einer Operation OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 24

25 2. Grundkonzepte der Objektorientierung Kapselung und Klassen ein Beispiel Aufgabe: Entwerfe eine Klasse für die Verwaltung von Personen Name und Geschlecht sollen erfasst werden Das Alter soll später ausgegeben werden können Attribute Operationen -Name - SetName() und GetName(); - Gender - SetGender() und GetGender(); - DateOfBirth - SetDateOfBirth() und GetDateOfBirth(); - GetAge(); Operationen können mehr leisten als nur Attribute zurückliefern! Berechnungen durchführen (z.b. das Alter aus Datum und Geb.datum berechnen) Gültigkeitsprüfungen machen (z.b. bei SetDateOfBirth) Automatische Ergänzungen (z.b. in SetName Gender nach Vornamen vorbelegen)... OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 25

26 2. Grundkonzepte der Objektorientierung Wiederverwendung Klassen verbergen die Realisierung und bieten zum Objekt passende Schnittstellen Klassen können in verschiedenen Kontexten eingesetzt werden Klassen fördern die (systematische) Wiederverwendung OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 26

27 2. Grundkonzepte der Objektorientierung Beziehungen (Assoziationen) Objekte (bzw. Klassen) ausführlich im Kapitel UML stehen oft untereinander in Beziehung (z.b. ein Haus wird von einer Person bewohnt) bestehen oft aus mehreren anderen Objekten "Aggregation" (ein Auto besteht aus Reifen, Karosserie,... ) Konkretisieren die Eigenschaften einer anderen Klasse Spezialisierung (bei Programmierung -> Vererbung ); invers: Generalisierung (Ein LKW ist ein spezielles Kfz; ein Kfz ist eine Verallgemeinerung von PKW und LKW) können als Hierarchie dargestellt werden Generalisierungshierarchie bzw. Vererbungshierarchie (Ein Cabrio ist ein spezieller Pkw und ein Pkw ist ein spezielles Kfz.) OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 27

28 2. Grundkonzepte der Objektorientierung Polymorphismus Vielgestaltigkeit kennen Sie evtl. von generischen Datenstrukturen (Stack, Vector, Queue, etc.) Konzept der Programmierung, das es erlaubt, einem Wert oder einer Variablen mehrere Datentypen zuzuordnen gleiche Operation anwendbar auf unterschiedliche Objekte innerhalb einer Vererbungshierarchie oder gleiche Operation anwendbar auf Objekte mit einem Datentyp, der als Parameter übergeben wird ("Template") Vorteile: Vermeidung von typbasierten Fallunterscheidungen bzw. Casts konkrete Umsetzung erfolgt über Compiler bzw. Linker erleichtert die Benutzung von Klassen OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 28

29 2. Grundkonzepte der Objektorientierung Prinzipien der Objektorientierung: Zusammenfassung Sie kennen jetzt Objekte Klassen Attribute Operationen / Methoden Abstraktion Kapselung Spezialisierung bzw. Generalisierung Polymorphismus OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 29

30 Hochschule Darmstadt Fachbereich Informatik Objektorientierte Analyse und Design 3. Objektorientierte Software-Entwicklung OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 30

31 3. Objektorientierte SW-Entwicklung Lernziele Sie sollen in diesem Kapitel verstehen, wie die objektorientierte Entwicklungsmethode mit den traditionellen Entwicklungsmethoden zusammenhängen welche Vorteile die neuen Entwicklungsmethoden bieten welche Nachteile dadurch überwunden werden wie es zur Entstehung der UML kam und was sie beinhaltet welche Unterstützung Werkzeuge bei der objektorientierten SW-Entwicklung bieten Hinterher ahnen Sie, warum man in professionellen Projekten so entwickelt! OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 31

32 3. Objektorientierte SW-Entwicklung: Einleitung Klassen wie Sie es bisher kennen Sie kennen C++-Klassen aus Programmieren 1 mit C++ Header: class CTaschenrechner { private: CSpeicher m_cspeicher; }; private: CEinAusgabe m_ceinausgabe; private: CProzessor m_cprozessor; public: CTaschenrechner(void); public: void benutze(); class CSpeicher { private: double mstack[255]; }; public: CSpeicher(void); public: void push(double p); public: bool pop(double &p); public: void clear(); public: double readtop(); public: void dump(); OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 32

33 3. Objektorientierte SW-Entwicklung: Einleitung Bewertung der C++ Darstellung (I) Nachteile Verweise auf andere Klassen sind als Pointer oder Klassenobjekte in der Klassendefinition zwischen lokalen Variablen etc. "versteckt" viele Details sind im Code (.cpp) versteckt bei komplexen Aufgaben geht der Überblick schnell verloren Einarbeitung in fremden Code ist schwierig Idee Stelle die Inhalte übersichtlich dar Trenne in der Darstellung die Beziehungen zwischen Klassen von lokalen Daten Umsetzung UML bietet solche Darstellungsmöglichkeiten OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 33

34 3. Objektorientierte SW-Entwicklung: Einleitung Klassen etwas anders (C++ DesignKlassendiagramm) realisieren Beziehungen "besteht aus" "kennt" OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 34

35 3. Objektorientierte SW-Entwicklung: Einleitung Bewertung der Darstellung als C++ DesignKlassendiagramm Vorteile übersichtliche Darstellung Beziehung sind explizit dargestellt Nachteile Idee Darstellung hängt von der Syntax der Programmiersprache ab Darstellung hängt von den Features der Programmiersprache ab Immer noch viele Details definiere und verwende eine allgemeine Sprache mit mächtigen Features und bilde diese später auf die jeweilige Programmiersprache ab (so gut es eben geht) abstrahiere von Details (z.b. von Methoden) um die Übersichtlichkeit zu erhöhen Umsetzung UML bietet solche Darstellungsmöglichkeiten Abbildung der UML-Konstrukte auf Programmiersprachen erfolgt automatisch durch CASE-Tools OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 35

36 3. Objektorientierte SW-Entwicklung: Einleitung Klassen noch mal anders (AnalyseKlassendiagramm) keine Methoden verallgemeinerte Datentypen UML-Syntax für Attribute attributname [ : attributtyp [ = initialwert ] ] UML-Syntax für Methoden methodenname [( parametername [ : parametertyp] [,...] )] [ : rückgabetyp] OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 36

37 3. Objektorientierte SW-Entwicklung: Einleitung Bewertung der Darstellung als UML-AnalyseKlassendiagramm Vorteile übersichtliche Darstellung leicht verständlich unabhängig von der Programmiersprache...wenn man sich dran gewöhnt hat Modellierung auf hoher Abstraktionsebene auch mit Konstrukten, welche die Zielsprache evtl. nicht bietet Nachteile Syntax der UML muss erlernt werden Code-Rahmen müssen aus der UML-Darstellung generiert werden für Anfänger oft verwirrend Umsetzung UML bietet diese und noch viele weitere - Darstellungsmöglichkeiten CASE-Tools unterstützen die UML und das üben wir im Praktikum OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 37

38 3. Objektorientierte SW-Entwicklung: Einleitung Und nun das Ganze andersrum Es gibt viele Projekte, in denen das prinzipielle Vorgehen vom Code hin zum Analyse-Modell geht (Aufarbeitung von Altanwendung) Die Anforderungen und Modelle werden aus dem Code rekonstruiert Der Übergang vom Design- zum Analysemodell erfolgt manuell In einem "normalen" Projekt werden aber zuerst die Anforderungen erarbeitet und darauf basierend der Entwurf und der Code erstellt Analyse-Modell Konkretisierung Design-Modell Round-trip Engineering Code OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 38

39 Hochschule Darmstadt Fachbereich Informatik Objektorientierte Analyse und Design 3.1 Objektorientierte SW-Entwicklung: UML OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 39

40 3.1 Objektorientierte SW-Entwicklung: UML Die Entstehungsgeschichte der UML OML Firesmith, Henderson- Sellers, Page-Jones; 1998 Unified Method Booch, Rumbaugh; 1995 Unified Modeling Language v1.0 Booch, Jacobson, Rumbaugh; 1997 Catalysis D Souza, Willes; 1996 MOSES Henderson-Sellers; 1994 SOMA Graham; 1994 Fusion Coleman, et. al.; 1994 OBA Rubin; 1992 BON Nerson; 1992 OOA Coad, Yourdan; 1991 SCOOP Cherry; 1990 OOA&D Martin, Odell; 1992 HOOD ESA; 1990 OMT Rumbaugh, et. al.; 1991 Quelle und Literaturhinweis: OOD Booch; 1992 OBA Bailin; 1989 OOSE Jacobson; 1992 OSA Embley; 1991 RDD Wirfs-Brock; 1990 State Charts Harel; 1987 OOAD&I Henderson-Sellers, Macrone; 1992 OOSA Shlear, Mellor; 1991 OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 40

41 3.1 Objektorientierte SW-Entwicklung: UML UML als Vorgehensmodell? Es existier(t)en verschiedene objektorientierte Methoden Am bekanntesten: OMT: Object Modelling Technique (James Rumbaugh) OMT: Object Modelling Technique v. Rumbaugh,... OOD: Object Oriented Design v. Booch OOSE: Object Oriented Software-Eng. v. Jacobson OSA: Object Oriented System Analysis v. Shlaer/Mellor OOA: Object Oriented Analysis v. Coach/Yourdon Rumbaugh, Booch, Jacobson, Firma Rational. Standardisierungsvorschlag bei OMG eingereicht: 1997 Kein Vorgehensmodell! "Nur" Sammlung von Beschreibungsmitteln. OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 41

42 3.1 Objektorientierte SW-Entwicklung: UML UML Inhalte Die UML eignet sich zur durchgängigen (OO)-Modellierung vom Entwurf bis zur Implementierung: Statische Aspekte Struktur-Diagramme 1. Klassendiagramm 2. Objektdiagramm 3. Komponentendiagramm 4. Paketdiagramm 5. Verteilungsdiagramm 6. Kompositionsstrukturdiagramm 7. Profildiagramm Dynamische Aspekte Verhaltens-Diagramme 8. Use-Case-Diagramm 9. Zustandsautomat 10. Aktivitätsdiagramm Interaktionsdiagramme 11. Sequenzdiagramm 12. Kommunikationsdiagramm 13. Zeitverlaufsdiagramm 14. Interaktionsübersichtsdiagramm OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 42

43 3.1 Objektorientierte SW-Entwicklung: UML Quellen zur UML OOSE: Übersetzungstabelle Deutsch English UML-Notationsübersicht Glossar und vieles mehr OMG (Object Management Group): Offizielle Spezifikation und vieles mehr... OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 43

44 Hochschule Darmstadt Fachbereich Informatik Objektorientierte Analyse und Design 3.2 Werkzeuge zur objektorientierten SW-Entwicklung OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 44

45 3.2 Objektorientierte SW-Entwicklung: Werkzeuge Werkzeuge für die objektorientierte Entwicklung Leider meist proprietär! kein echter Im- / Export lange Zeit nur Werkzeuge für spezifische Teile der Entwicklung verfügbar Editoren Programmierumgebungen Analysetools Designtools Heute zunehmend CASE-Tools, die den gesamten SW-Lebenszyklus unterstützen z.b. Innovator, Eclipse, Rational Rose, Visual Studio.Net Generieren Designmodell aus Code ( Reverse Engineering ) Generieren Code(rahmen) aus Desingmodell ( Forward Engineering ) Zusammen Round-Trip-Engineering Unterstützen die UML Unterstützen Arbeit in großen Projekten und Teams OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 45

46 3.2 Objektorientierte SW-Entwicklung: Werkzeuge Warum sind diese Tools so kompliziert? Entwicklung in mehreren Teams an mehreren Standorten Schutz gegen gleichzeitiges Ändern an einem Modul: "Sperren (Locking)" Sicherung von Zwischenständen: "Versionsverwaltung" Verbergen von Zwischenständen vor anderen: "Freigabe"-Mechanismen Ergänzen von "Namespaces" zum Schutz vor gleichen Variablennamen Auslieferung von mehreren Releases Wiederherstellung von Zwischenständen (Releases) z.b. zum Bug-Tracking: erfordert Anbindung an "Konfigurationsmanagement" Pflege der Abhängigkeiten zwischen Modellen und Code Änderungen werden automatisch nachgezogen: "Round-Trip-Engineering" Arbeit mit sehr vielen Informationen Darstellung ausgewählter Teilinformationen: "Sichten und verschiedene Diagramme" Viele Dinge sind in großen Projekten einfach kompliziert und deshalb auch die Verwendung dieser Tools! OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 46

47 3.2 Objektorientierte SW-Entwicklung: Werkzeuge Überblick Objektorientierte Programmiersprachen C++ Bjarne Stroustrup (1986) Ziel: Erweiterung von C um Objektorientierung Viele Bibliotheken und Klassen verfügbar Pointer Speicherplatzverwaltung in Eigen-Regie Performanz statt Entwicklungskomfort OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 47

48 3.2 Objektorientierte SW-Entwicklung: Werkzeuge Überblick Objektorientierte Programmiersprachen Java SUN Microsystems (1995) Ziel: Plattformunabhängigkeit (Java Virtual Machine) Keine (fehlerträchtigen) Pointer Komponententechnik integriert Viele Bibliotheken und Klassen verfügbar Einsatz im Web-Umfeld Automatische Speicherverwaltung Rechnerleistung wird vorausgesetzt Entwicklungskomfort statt Performanz OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 48

49 3.2 Objektorientierte SW-Entwicklung: Werkzeuge Überblick Objektorientierte Programmiersprachen C# Microsoft (2001?) Ziel: Kombination der Vorteile von C++ & Java keine Header, keine Makros Compilierung des Codes in eine Zwischensprache Ausführung in der proprietären.net-laufzeitumgebung Entwicklungskomfort und Performanz (?) OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 49

50 3. Objektorientierte SW-Entwicklung Kontrollfragen Warum verwendet man in der UML eine spezielle Syntax zum spezifizieren von Attributen und Methoden? Wodurch unterscheidet sich das Analysemodell vom Designmodell? Was ist Polymorphismus? Was ist Kapselung? Ist jedes C++ - Programm auch objektorientiert? Kann man auch in Assembler objektorientiert entwickeln? In welchem Zusammenhang stehen Code und Designmodell? Warum kam es zur Entstehung der UML? Ist die UML ein Vorgehensmodell? Ahnen Sie jetzt, warum man in großen Projekten so entwickelt? OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 50

51 Hochschule Darmstadt Fachbereich Informatik Objektorientierte Analyse und Design 4. Objektorientierte Analyse OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 51

52 4. Objektorientierte Analyse Zur Erinnerung: Abstraktionsebenen gedankliche Ebene Reale Welt Abstraktion logische Ebene (Modell) OOA-Ebene OOD-Ebene Implementierungskonzepte Codierung physische Ebene (Implementierungsebene) Programm Arzt.cpp Abstraktionsebenen der objektorientierten Systementwicklung (4-Schichten-Modell) OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 52

53 4. Objektorientierte Analyse Anforderungsanalyse Typische Situation: Der Kunde oder Auftraggeber kommt und erklärt was er haben will... d.h. er beschreibt mehr oder weniger präzise seine Anforderungen In seiner eigenen Sprache mit Hinweisen auf Vorgängersysteme mit Lösungsideen Anforderungen können sein funktionale Anforderungen: - Gesamtablauf (Workflow): Beschreibt auch interne Abläufe - Anwendungsfälle: Beschreiben das Verhalten eines "Systems" an der Systemgrenze nicht funktionale Anforderungen: - Qualitäten des zukünftigen Systems: z.b. Performance, Ausfallsicherheit, Benutzerfreundlichkeit, Robustheit,... - Fertigstellungstermin, HW, SW Aber wie schreibt man das auf? OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 53

54 4. Objektorientierte Analyse Lernziele Sie sollen in diesem Kapitel verstehen, Wie die Ergebnisse der Anforderungsanalyse dokumentiert werden Was zur Dokumentation einer Anforderung gehört Welche Möglichkeiten Use Cases bieten Wie man Use Cases in Textform aufschreibt Wie man Use Cases in UML darstellt Wie man ein gesamtes System mit Use Cases beschreibt Welche alternativen Beschreibungsmöglichkeiten es gibt Hinterher wissen Sie wie man die Ergebnisse einer objektorientierten Analyse dokumentiert! OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 54

55 Hochschule Darmstadt Fachbereich Informatik Objektorientierte Analyse und Design 4.1 Textuelle Beschreibung von Use Cases OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 55

56 4.1 Textuelle Beschreibung von Use Cases Beispiel: Kundenanforderungen Geldautomat (ATM) Verbale Beschreibung eines (ungewöhnlich präzisen) Kunden: "Geld abheben" Nachdem der Kunde die Karte eingeschoben und die PIN und den Betrag eingegeben hat, wird der Betrag vom Konto abgebucht und die Karte und das Geld ausgegeben. Falls die PIN das 1. oder 2. Mal falsch eingegeben wurde, wird der Kunde benachrichtigt und die PIN wird erneut eingegeben. Falls die PIN ein 3. Mal falsch eingegeben wurde, protokolliert das System den Versuch, zieht die Karte ein und bricht die Kommunikation ab. Falls die Karte nicht gültig ist, wird dies dem Kunden mitgeteilt und die Karte wieder ausgegeben. Welche Teile müssen sequentiell ablaufen, was darf oder soll parallel laufen? Ist bei "oder" eventuell "entweder-oder" gemeint? Natürliche Sprachen sind oft nicht eindeutig genug für eine exakte Beschreibung! OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 56

57 4.1 Textuelle Beschreibung von Use Cases Notation am Beispiel: Geldautomat Exakte Beschreibung: "Geld abheben" 1. Kunde schiebt Karte ein. 2. Das System stellt fest, dass die Karte gültig ist. 3. Kunde gibt PIN ein. 4. Das System stellt fest, dass die PIN die richtige PIN zur Karte ist. 5. Kunde gibt gewünschten Betrag ein. 6. System bucht Betrag vom Konto ab. 7. System gibt Karte aus. 8. System gibt Geld aus. Ziel ("Goal") Ablauf ("Basic Course") "Aktionen" ("Action-Steps") Verwenden Sie einfache und klare Sätze! Aktive Formulierungen mit Subjekt, Prädikat, Objekt! OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 57

58 4.1 Textuelle Beschreibung von Use Cases Ergebnis eines Anwendungsfalls (Use Case) Der Benutzer des Systems erwartet ein bestimmtes Ergebnis, wenn der Anwendungsfall erfolgreich verläuft Success Guarantees oder Use Case-Business-Result Sind Bedingungen, die im Erfolgsfall erfüllt werden Der Use Case wurde bis zum Ende durchgeführt und nicht abgebrochen Beispiele für Success Guarantees - "Das Geld wurde vom Automat ausgegeben und vom Konto abgebucht" - "Die Karte wurde vom Automat ausgegeben" Minimal Guarantees Bedingungen, die immer d.h. im Erfolgsfall und auch bei Abbruch erfüllt sind Beispiele für Minimal Guarantees - "Alle Fehler und Transaktionsdaten wurden protokolliert." - "Das System ist wieder bereit für den nächsten Kunden" Aber was passiert, wenn der Use Case nicht erfolgreich abläuft? OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 58

59 4.1 Textuelle Beschreibung von Use Cases Alternativer Ablauf eines Use Cases Bedingung Alternative Course: 4a. Das System erkennt, dass die PIN das 1. oder 2. Mal falsch eingegeben wurde: 4a1. Das System protokolliert den Fehlversuch. 4a2. Das System benachrichtigt den Kunden. 4a3. Rückkehr nach 3. Bezug zum Basic Course Alternative Course: 4b. Das System erkennt, dass die PIN das 3. Mal falsch eingegeben wurde: 4b1. Das System protokolliert den Versuch. 4b2. Das System zieht endgültig die Karte ein. 4b3. Das System benachrichtigt den Kunden. 4b4. Use Case wird abgebrochen. "Alternative Course" "Aktionen" ("Action-Steps") OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 59

60 4.1 Textuelle Beschreibung von Use Cases Alternative Course: Übung Es wird eine ungültige Karte in den Geldautomaten eingeschoben (z.b. die Mensakarte). Beschreiben Sie den alternativen Ablauf! Alternative Course: 2a. Das System erkennt, dass die Karte nicht gültig ist: 2a1. Das System protokolliert den Versuch. 2a2. Das System benachrichtigt den Kunden 2a3. Das System gibt die Karte aus. 2a4. Der Use Case wird abgebrochen. OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 60

61 4.1 Textuelle Beschreibung von Use Cases Auslösung eines Use Cases Ein Use Case wird durch ein bestimmtes Ereignis gestartet ein Kunde ruft an um 19:00 Uhr startet die Datensicherung das System stellt einen Fehler fest Der "Trigger" ist die erste Aktion, die mit unserem System interagiert Der "Primary Actor" ist derjenige, der die erste Aktion des Use Case anstößt, um ein Ziel zu erreichen Das muss nicht derjenige sein, der selbst direkt mit dem System kommuniziert, sondern evtl. auch der Anrufer, der die Erfassung eines Auftrags durch einen Sachbearbeiter anstößt. Beispiel: Ein Kunde ruft an und will einen Auftrag vergeben. Die erste Aktion (mit unserem Auftragserfassungssystem) ist dann: Der Sachbearbeiter ruft das Auftragserfassungsprogramm auf "Trigger" "Primary Actor" "Actor" OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 61

62 4.1 Textuelle Beschreibung von Use Cases Wer definiert Use Cases? Alle Personen, die ein berechtigtes Interesse an einem bestimmten Verhalten des Systems haben nicht nur die Akteure, sondern auch: Besitzer des zukünftigen Systems, der Abteilungsleiter, die interne Revisionsabteilung aber nicht der Einbrecher für eine Alarmanlage Die Akteure sind oft für die Definition der Use Cases gar nicht so wichtig Die Interessen der Stakeholder äußern sich in den Action-Steps z. B. Interesse des Kunden / der Bank: "keine unberechtigte Abhebung": - Einschieben EC-Karte, PIN-Überprüfung "Stakeholders" & "Interests" ist zwar Actor, aber kein Stakeholder! Interesse des Kunden: "Falls Karte / Geld nach Ausgabe nicht entnommen wird, soll dem Kunde kein Schaden entstehen": - Wieder-Einziehen der Karte / des Geldes und späteres Abholen der Karte am Schalter / Gutschrift des Gelds aufs Konto OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 62

63 4.1 Textuelle Beschreibung von Use Cases Muster für Use Case-Spezifikation (I) Use Case Name Primary Actor Further Actors <name = Use Case-Goal> <a role name for the primary actor or description> <Role Name for further actors or description> Stakeholders and their Interests Success Guarantees Minimal Guarantees Trigger <list of stakeholders and their key interests in the use case> <the state of the world if goal succeeds> <how the interests are protected under all exits> <what starts the Use Case (may be a time event)> OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 63

64 4.1 Textuelle Beschreibung von Use Cases Muster für Use Case-Spezifikation (II) Basic Course (Main Success Scenario) Alternative Course <put here the steps of the scenario from trigger to goal delivery and any cleanup after> <step#> <action description> <step#> <action description> <step# with reference to step in Basic Course (same step-number with following a. or b...., e.g. 2a.)> <Condition> <step# of the Alternative Course, e.g. 2a1.> <action description>... (Return point is specified in the action description in step(s) in the alternative Course) Es gibt diverse ähnliche Templates für die Beschreibung! Häufig mit weiteren Rubriken (z.b. Vor- & Nachbedingungen oder Ausnahmen) OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 64

65 4.1 Textuelle Beschreibung von Use Cases Beispiel "Geld abheben": Use Case-Spezifikation (I) Use Case Name Primary Actor Further Actors Stakeholders and their Interests Success Guarantees Minimal Guarantees Trigger Geld abheben Kunde -- Bank: Schutz vor unberechtigtem Zugriff Kunde: Abbuchung nur nach Auszahlung Das Geld wurde vom Automat ausgegeben und vom Konto abgebucht Die Karte wurde vom Automat ausgegeben. Alle Fehler und Transaktionsdaten wurden protokolliert Das System ist bereit für den nächsten Kunden. Kunde schiebt Karte ein OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 65

66 4.1 Textuelle Beschreibung von Use Cases Beispiel "Geld abheben": Use Case-Spezifikation (II) Basic Course (Main Success Scenario) Alternative Course (2a) 1.Kunde schiebt Karte ein. 2.Das System stellt fest, dass die Karte gültig ist. 3.Kunde gibt PIN ein. 4.Das System stellt fest, dass die PIN die richtige PIN zur Karte ist. 5.Kunde gibt gewünschten Betrag ein. 6.System bucht Betrag vom Konto ab. 7.System gibt Karte aus. 8.System gibt Geld aus. 2a. System erkennt, dass die Karte nicht gültig ist: 2a1. Das System protokolliert den Versuch. 2a2. Das System benachrichtigt den Kunden 2a3. Das System gibt die Karte aus. 2a4. Use Case wird abgebrochen. OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 66

67 4.1 Textuelle Beschreibung von Use Cases Beispiel "Geld abheben": Use Case-Spezifikation (III) Alternative Course (4a) 4a. Das System erkennt, dass die PIN das 1. oder 2. Mal falsch eingegeben wurde: 4a1. Das System protokolliert den Versuch. 4a2. Das System benachrichtigt den Kunden. 4a3. Rückkehr nach 3. Alternative Course (4b) 4b. Das System erkennt, dass die PIN das 3. Mal falsch eingegeben wurde: 4b1. Das System protokolliert den Versuch. 4b2. System zieht die Karte endgültig ein. 4b3. Das System benachrichtigt den Kunden. 4b4. Use Case wird abgebrochen. (2a) und (4b) sind Exceptions, d. h. hier sind die Success Guarantees nicht erfüllt die Minimal Guarantees aber schon! OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 67

68 4.1 Textuelle Beschreibung von Use Cases Gedanken zu Use Cases Ein Use Case beschreibt eine Menge von Aktionsfolgen, einschließlich Varianten, die ein System ausführt, um ein erkennbares, für einen Aktor nützliches Ergebnis zu erarbeiten. Ein Use Case stellt eine funktionale Anforderung an das System als Ganzes dar Ein Use Case beschreibt nicht, wie das Verhalten implementiert wird Use Cases sind geeignet um das Verhalten eines Systems zu visualisieren, zu spezifizieren, und zu dokumentieren Use Cases bieten eine Basis für die Verständigung von Entwicklern, Endanwendern und Fachleuten für den Anwendungsbereich; für die Requirements, für die Überprüfung der Architektur, und für den Test Die Sammlung der Use Cases ergibt noch keine vollständige Sammlung der Requirements! OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 68

69 4.1 Textuelle Beschreibung von Use Cases Tipps für die Beschreibung des Ablaufs Benutze eine einfache Grammatik Zeige immer klar: Wer hat den Ball : System gibt Meldung... aus Kunde wählt am System... aus System führt... aus, bis... eintritt Schreibe aus der User- (bzw. Vogel)perspektive (keine System-Interna!) Vermeide Passiv und Konjunktiv ("Es sollte angezeigt werden") Zeige wie sich der Prozess fortbewegt Zeige was der Aktor will, nicht seine Bewegungen Benutze eine sinnvolle Menge von Aktionen Wähle exakte Begriffe und Wörter verwende z.b. validiere, und nicht überprüfe"! Das System validiert das Passwort und überprüft es nicht wenn sinnvoll, erwähne die Zeit OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 69

70 4.1 Textuelle Beschreibung von Use Cases Lange Use Cases Geld abheben 1. Kunde schiebt Karte ein. 2. Das System stellt fest, dass die Karte gültig ist. 3. PIN-Eingabe: Kunde gibt PIN ein. 4. PIN-Prüfung: Das System stellt fest, dass die PIN die richtige PIN zur Karte ist. 5. Kunde gibt gewünschten Betrag ein. 6. System bucht Betrag vom Konto ab. 7. System gibt Karte aus. 8. System gibt Geld aus. Annahmen In Schritt 5 können alternativ neue Schecks angefordert werden (mit Angabe der Anzahl) In Schritt 5 kann zusätzlich ein Kontoauszug gedruckt werden Nach der Eingabe des Betrags in Schritt 5 kann die Stückelung des Geldes (Große oder kleine Scheine) gewählt werden. Diese Schritte werden auch von anderen Use-Cases verwendet... Wie kann das dargestellt werden ohne alles mehrfach in verschiedenen Use Cases zu beschreiben? OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 70

71 4.1 Textuelle Beschreibung von Use Cases Auslagern von Teilen von Use Cases Aber bitte nicht zum "Programmieren" verwenden! Es gibt bei Use Cases zwei Mechanismen um Teile auszulagern Include Analog zu dem Include von C++ d.h. durch einen Include-Befehl im Hauptablauf wird der ausgelagerte Ablauf eingelesen und an dieser Stelle eingefügt Extend Ein Extend lagert einen Ablauf aus, der optional ist d.h. nicht immer ausgeführt wird. Ein Schritt im normalen Ablauf wird durch einer ausgelagerte Funktionalität ausgedehnt. Der Extend-Use Case verweist auf den zu erweiternden Schritt im Hauptablauf. Extend- und Include-Use Cases werden immer als vollständige Use Cases beschrieben! müssen eine Funktionalität aus Benutzersicht erbringen Unterschiedliche Verweis-Richtungen! Das bisherige Use Case Template muss um entsprechende Verweise erweitert werden! OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 71

72 4.1 Textuelle Beschreibung von Use Cases Extend und Include: Verknüpfung Use Case Name Primary Actor Further Actors Stakeholders and their Interests Success Guarantees Minimal Guarantees Trigger Extend Use Case for Base UC: Condition: Extension Point (in Base UC) Return Point (in Base UC): Basic Course (Main Success Scenario) <name = Use Case-Goal> <a role name for the primary actor or description> <Role Name for further actors or description> <list of stakeholders and their key interests in the use case> <the state of the world if goal succeeds> <how the interests are protected under all exits> <what starts the Use Case (may be a time event)> If the described Use Case is an Extend Use Case to one or more Base UCs: For each Base Use Case please specify: Name of Base Use Cases that are extended: Condition: <Condition> Extension Point <step# or label in Base UC> Return Point: <step# in Base Use Case > <step # Extend Label>... <step #>... <step #> Include: <Name of Included Use Case> Use Case Name Primary Actor Further Actors Stakeholders and their Interests Success Guarantees Minimal Guarantees Trigger <name = Use Case-Goal> Extend Use Case Extend Use Case for Base UC: Condition: Extension Point (in Base UC) Return Point (in Base UC): Basic Course (Main Success Scenario) Extend-Ablauf <a role name for the primary actor or description> <Role Name for further actors or description> <list of stakeholders and their key interests in the use case> <the state of the world if goal succeeds> <how the interests are protected under all exits> <what starts the Use Case (may be a time event)> If the described Use Case is an Extend Use Case to one or more Base UCs: For each Base Use Case please specify: Name of Base Use Cases that are extended: Condition: <Condition> Extension Point <step# or label in Base UC> Return Point: <step# in Base Use Case > Use Case Name <step #>... Primary Actor <step #> Include: <Name of Included Use Case> <step #>... Further Actors Stakeholders and their Interests <name = Use Case-Goal> <a role name for the primary actor or description> <Role Name for further actors or description> <list of stakeholders and their key interests in the use case> Success Guarantees <the state of the world if goal succeeds> Include Use Case Minimal Guarantees <how the interests are protected under all exits> Trigger Extend Use Case for Base UC: Condition: Extension Point (in Base UC) Verweis auf Include-Ablauf Return Point (in Base UC): <what starts the Use Case (may be a time event)> If the described Use Case is an Extend Use Case to one or more Base UCs: For each Base Use Case please specify: Name of Base Use Cases that are extended: Condition: <Condition> Extension Point <step# or label in Base UC> Return Point: <step# in Base Use Case > Basic Course (Main Success Scenario) <step #>... <step #> Include: <Name of Included Use Case> <step #>... OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 72

73 4.1 Textuelle Beschreibung von Use Cases Erweitertes Muster für Use Case-Spezifikation (mit Extend & Include) Extend Use Case for Base UC: Condition: Extension Point (in Base UC) Return Point (in Base UC): Basic Course (Main Success Scenario) If the described Use Case is an Extend Use Case to one or more Base UCs: For each Base Use Case please specify: Name of Base Use Cases that are extended: Condition: <Condition> Extension Point <step# or label in Base UC> Return Point: <step# in Base Use Case > or "abort" <step # Extend Label>... <step #>... <step #> Include: <Name of Included Use Case> OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 73

74 4.1 Textuelle Beschreibung von Use Cases Beispiel: Der bisherige Use Case "Geld abheben" Basic Course Alternative Course (2a) 1. Kunde schiebt Karte ein. 2. Das System stellt fest, dass die Karte gültig ist. 3. Kunde gibt PIN ein. 4. Das System stellt fest, dass die PIN die richtige PIN zur Karte ist. 5. Kunde gibt gewünschten Betrag ein. 6. System bucht Betrag vom Konto ab. 7. System gibt Karte aus. 8. System gibt Geld aus. 2a. Das System erkennt, dass die Karte nicht gültig ist: 2a1. Das System protokolliert den Versuch. 2a2. Das System benachrichtigt den Kunden 2a3. Das System gibt die Karte aus. 2a4. Use Case wird abgebrochen. Modelliere den Alternative Course 2a als eigenständigen Extend Use Case "Auf ungültige Karte reagieren Grund: Auf ungültige Karte reagieren wird auch von anderen Use-Cases verwendet OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 74

75 4.1 Textuelle Beschreibung von Use Cases Beispiel: Extend - Use Case "Auf ungültige Karte reagieren" Use Case Name Primary Actor Further Actors Stakeholders & Interests Success Guarantees Minimal Guarantees Trigger Auf ungültige Karte reagieren Kunde -- Bank: Schutz vor unberechtigtem Zugriff Die Karte wurde vom Automat ausgegeben. Alle Fehler und Transaktionsdaten wurden protokolliert Der Automat hat kein Geld ausgegeben und auch kein Geld abgebucht Das System ist bereit für den nächsten Kunden. Das System erkennt, dass die Karte nicht gültig ist OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 75

76 4.1 Textuelle Beschreibung von Use Cases Beispiel: Extend - Use Case "Auf ungültige Karte reagieren" (II) Extend Use Case for Base UC: Condition: Extension Point (in Base UC) Return Point (in Base UC): Basic Course (Main Success Scenario) Geld abheben Das System erkennt, dass die Karte nicht gültig ist 2. bzw. <Karten-Prüfung> (ein Label ist besser) abort 1. Das System protokolliert den Versuch 2. Das System benachrichtigt den Kunden 3. Das System gibt die Karte aus 4. Use Case wird beendet Für jeden UC, der damit erweitert wird An der Zeilennummer bei Extension Point und Return Point erkennt man, ob es sich um einen Vorwärts- oder Rückwärtssprung handelt! OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 76

77 4.1 Textuelle Beschreibung von Use Cases Beispiel: "Geld abheben" - Änderungen wegen Extend (I) Use Case Name Primary Actor Further Actors Stakeholders and their Interests Success Guarantees Minimal Guarantees Trigger Geld abheben Kunde -- Bank: Schutz vor unberechtigtem Zugriff Kunde: Abbuchung nur nach Auszahlung Das Geld wurde vom Automat ausgegeben und vom Konto abgebucht Die Karte wurde vom Automat ausgegeben. Unverändert Alle Fehler und Transaktionsdaten wurden protokolliert Das System ist bereit für den nächsten Kunden. Kunde schiebt Karte ein OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 77

78 4.1 Textuelle Beschreibung von Use Cases Beispiel: "Geld abheben" - Änderungen wegen Extend (II) Extend Use Case for Base UC: Condition: Extension Point Return Point: Basic Course (Main Success Scenario) -- wird nicht als Extend-UC eingesetzt 1. Kunde schiebt Karte ein. 2. <Karten-Prüfung> Das System stellt fest, dass die Karte gültig ist. 3. Kunde gibt PIN ein. 4. Das System stellt fest, dass die PIN die richtige PIN zur Karte ist. 5. Kunde gibt gewünschten Betrag ein. 6. System bucht Betrag vom Konto ab. 7. System gibt Karte aus. 8. System gibt Geld aus. Label für Extend eingefügt OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 78

79 4.1 Textuelle Beschreibung von Use Cases Beispiel: "Geld abheben" - Änderungen wegen Extend (III) Alternative Course (4a) Alternative Course (4b) 4a. Das System erkennt, dass die PIN das 1. oder 2. Mal falsch eingegeben wurde: 4a1. Das System protokolliert den Versuch. 4a2. Das System benachrichtigt den Kunden. 4a3. Rückkehr nach 3. 4b. Das System erkennt, dass die PIN das 3. Mal falsch eingegeben wurde: 4b1. Das System protokolliert den Versuch. 4b2. Das System zieht endgültig die Karte ein. bisheriger Alternative Course 2a fehlt, sonst unverändert 4b3. Das System benachrichtigt den Kunden. 4b4. Use Case wird abgebrochen. OOAD, Prof. Dr. Ralf Hahn, Prof. Dr. Wolfgang Weber SS2011, h_da, Fachbereich Informatik 79