Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Grundkurs Software-Engineering mit UML

Ähnliche Präsentationen


Präsentation zum Thema: "Grundkurs Software-Engineering mit UML"—  Präsentation transkript:

1 Grundkurs Software-Engineering mit UML
Konzepte für die erfolgreiche Software-Entwicklung Prof. Dr. Stephan Kleuker Bitte beachten Sie die Rechte des Verlages SpringerTeubner an der Buchinhalten und Bildern Diese Folien sind als Begleitfolien für das Buch konzipiert Stephan Kleuker

2 1 Was ist Software-Engineering? 2 Prozessmodellierung
Inhaltsverzeichnis 1 Was ist Software-Engineering? 2 Prozessmodellierung 3 Vorgehensmodelle 4 Anforderungsanalyse 5 Grobdesign 6 Vom Klassendiagramm zum Programm 7 Konkretisierungen im Feindesign 8 Optimierung des Designmodells 9 Implementierungsaspekte 10 Oberflächengestaltung 11 Qualitätssicherung 12 Umfeld der Software-Entwicklung Hinweis: grüne Kästchen verlinken auf das genannte Kapitel Stephan Kleuker

3 1. Motivation von Software-Engineering
Stephan Kleuker

4 Historie des SW-Engineering (1/4)
Ende 60er Bedarf für Softwaretechnik neben der reinen Programmierung erstmals voll erkannt Vorher sind zahlreiche große Programmentwicklungen (möglich durch verbesserte Hardwareeigenschaften) gescheitert Arbeiten von Dijkstra 1968 (u.a. gegen Verwendung von GOTO) und Royce 1970 (Software-Lebenszyklus), Top-Down-Entwurf, graphische Veranschaulichungen (Nassi-Shneiderman Diagramme) Mitte 70er Top-Down-Entwurf für große Programme nicht ausreichend, zusätzlich Modularisierung erforderlich Entwicklung der Begriffe Abstrakter Datentyp, Datenkapselung und Information Hiding Stephan Kleuker

5 Historie des SW-Engineering (2/4)
Ende 70er Bedarf für präzise Definition der Anforderungen an ein Softwaresystem, Entstehen von Vorgehensmodellen, z. B. Structured Analysis Design Technique (SADT) 80er Jahre Vom Compiler zur Entwicklungsumgebung (Editor, Compiler, Linker, symbolischer Debugger, Source Code Control Systems) Weiterentwicklung der Modularisierung und der Datenkapselung zur objektorientierten Programmierung 90er Jahre Objektorientierte Programmierung nimmt zu (wieder ausgehend von der Implementierung) Neue Programmiersprache Java (ab Mitte 80er C++) Anwendungs-Rahmenwerke (Application Frameworks) zur Vereinfachung von Design und – vor allem – Programmierung Stephan Kleuker

6 Historie des SW-Engineering (3/4)
90er Jahre Geeignete Analyse- und Entwurfsmethoden entstehen (Coad/Yourdon, Rumbaugh, Booch, Jacobson und andere) 1995 Vereinigung mehrerer Ansätze zunächst als Unified Method (UM) von Booch und Rumbaugh, dann kommt Jacobson hinzu (Use Cases). 3 Amigos definieren die Unified Modeling Language (UML) als Quasi-Standard. 1997 UML in der Version 1.1 bei der OMG (Object Management Group) zur Standardisierung eingereicht und angenommen UML ist jedoch keine Entwicklungsmethode (Phasenmodell), nur eine Beschreibungssprache 1999 Entwicklungsmethode: Unified Process (UP) und Rational Unified Process (RUP) (erste Version) Stephan Kleuker

7 Historie des SW-Engineering (4/4)
Heute Vorgehensweisen auf individuelle Projektanforderungen abgestimmt CASE-Methoden und –Tools orientieren sich an der UML Aktueller Stand 2013: UML 2.4.1 (http://www.uml.org/) Aufbauend auf Analyse und Design erzeugen Codegeneratoren Programmgerüste Haupttätigkeiten bei Softwareentwicklung sind Analyse und Design, vieles andere versucht man zu automatisieren (!?) Stephan Kleuker

8 Warum scheitern SW-Projekte (kleine Auswahl)
Die Software wurde wesentlich zu spät geliefert Die Software erfüllt nicht die Wünsche des Kunden Die Software läuft nicht auf den vereinbarten Rechnersystemen, sie ist zu langsam oder kommt mit dem Speicher nicht aus Die Software kann nicht erweitert werden oder mit anderer Software zusammenarbeiten Stephan Kleuker

9 Antworten des Software-Engineering
1967: Prägung des Begriffs Software-Krise Lösungsansätze: Programmiersprachen: kontinuierliche Einführung von Abstraktion (Datentypen, Funktionen, Modulen, Klassen, Bibliotheken, Frameworks) Dokumentation: Einheitliche Notationen für Entwicklungsergebnisse (UML) Entwicklungsprozesse: Aufgabenbeschreibungen, wann was wie gemacht wird Vorgehensmodelle: Entwicklung passt sich an Bedürfnisse des Kunden an Stephan Kleuker

10 Definitionsversuch Software-Engineering
Zusammenfassend kann man Software-Engineering als die Wissenschaft der systematischen Entwicklung von Software, beginnend bei den Anforderungen bis zur Abnahme des fertigen Produkts und der anschließenden Wartungsphase definieren. Es werden etablierte Lösungsansätze für Teilaufgaben vorgeschlagen, die häufig kombiniert mit neuen Technologien, vor Ihrer Umsetzung auf ihre Anwendbarkeit geprüft werden. Das zentrale Mittel zur Dokumentation von Software-Engineering-Ergebnissen sind UML-Diagramme. Stephan Kleuker

11 2. Prozessmodellierung 2.1 Unternehmensprozesse
2.2 Prozessmodellierung mit Aktivitätsdiagrammen 2.3 Risikomanagement Stephan Kleuker

12 Umfeld von SW-Projekten
2.1 Unternehmensführung Unterstützung Vertrieb Projektmanagement Controlling SW-Projekt Stephan Kleuker

13 Prozesse in Unternehmen aus SW-Projektsicht
(Annahme SW ist wichtiges Kernprodukt) Unternehmensführung gibt Geschäftsfelder und Strategien vor Vertriebsleute müssen Kunden finden, überzeugen und Aufträge generieren Aufträge führen zu Verträgen, die geprüft werden müssen Das Personal für Aufträge muss ausgewählt werden und zur Verfügung stehen Der Projektablauf muss beobachtet werden, Abweichungen z. B. in Zeitplan müssen zu Steuerungsmaßnahmen führen Die SW muss realisiert werden Stephan Kleuker

14 Unterschiedliche Menschen arbeiten in verschiedenen Rollen zusammen
Rollenbegriff Unterschiedliche Menschen arbeiten in verschiedenen Rollen zusammen Rolle: genaue Aufgabenbeschreibung, mit Verantwortlichkeiten (was soll gemacht werden) und Kompetenzen (welche Entscheidungen können getroffen werden, z. B. „Arbeit anweisen“) Mensch kann in einem Unternehmen/Projekt mehrere Rollen haben Eine Rolle kann von mehreren Menschen besetzt werden Beispielrollen: Vertriebsleiter, Vertriebsmitarbeiter, Projektleiter, Analytiker, Implementierer, Tester Stephan Kleuker

15 Prozessbegriff Prozessbeschreibungen regeln die Zusammenarbeit verschiedene Menschen (genauer Rollen), Was soll in diesem Schritt getan werden? Wer ist verantwortlich für die Durchführung des Schritts? Wer arbeitet in welcher Rolle in diesem Schritt mit? Welche Voraussetzungen müssen erfüllt sein, damit der Schritt ausgeführt werden kann? Welche Teilschritte werden unter welchen Randbedingungen durchgeführt? Welche Ergebnisse kann der Schritt abhängig von welchen Bedingungen produzieren? Welche Hilfsmittel werden in dem Prozessschritt benötigt? Welche Randbedingungen müssen berücksichtigt werden? Wo wird der Schritt ausgeführt? Prozesse sind zu dokumentieren und zu pflegen Stephan Kleuker

16 Prozessmodellierung mit Aktivitätsdiagrammen
2.2 Zur Beschreibung werden folgende elementare Elemente genutzt: genau ein Startpunkt einzelner Prozessschritt (Aktion) Kontrollknoten (Entscheidung) Kontrollknoten (Zusammenführung) Endpunkt (Terminierung) Stephan Kleuker

17 Parallelität in Prozessen
Waagerechter oder senkrechter Strich steht für mögliche Prozessteilung (ein Pfeil rein, mehrere raus) oder Zusammenführung (mehrere Pfeile rein, ein Pfeil raus) Am zusammenführenden Strich steht Vereinigungsbedingung, z. B. {und}: alle Aktionen abgeschlossen {oder}: (mindestens) eine Aktion abgeschlossen UML 1.1 hatte andere Restriktionen Stephan Kleuker

18 Beteiligte, Produkte, Werkzeuge
Beteiligte, Produkte, Werkzeuge werden hier als einfache Datenobjekte modelliert, dabei steht zunächst die Objektart und dann die genaue Bezeichnung In eckigen Klammern kann der Zustand eines Objekts beschrieben werden neben „Verantwortlicher“ noch „Mitwirkender“ möglich auch Entscheidungen können Verantwortliche haben Stephan Kleuker

19 immer erst ohne "Kästen" modellieren
Anmerkungen Lesbarkeit leidet unter Beteiligte, Produkte, Werkzeuge, da zentraler Ablauf versteckt immer erst ohne "Kästen" modellieren häufig alternative Darstellungen für Rollen und Werkzeuge Variante: nur Ablauf, Rest in Textdokumentation Stephan Kleuker

20 Beispiel: Vertrieb (1/4)
Zu modellieren ist der Vertriebsprozess eines Unternehmens, das SW verkauft, die individuell für den Kunden angepasst und erweitert werden kann Modelle werden wie SW inkrementell erstellt; zunächst der (bzw. ein) typische Ablauf, der dann ergänzt wird Typisches Szenario: Vertriebsmitarbeiter kontaktiert Kunden und arbeitet individuelle Wünsche heraus; Fachabteilung erstellt Kostenvoranschlag; Kunde unterschreibt Vertrag; Projekt geht in den Prozess Projektdurchführung (hier nicht modelliert) Beteiligt: Vertriebsmitarbeiter, Kunde, Fachabteilung Produkt: Individualwünsche, Kostenvoranschlag, Vertrag Aktionen: Kundengespräch, Kosten kalkulieren, Vertragsverhandlung Stephan Kleuker

21 Beispiel: Vertrieb (2/4)
Anmerkung: Die Raute kann natürlich weggelassen werden; man kann aber so die Aufmerksamkeit der Studierenden prüfen  Stephan Kleuker

22 Beispiel: Vertrieb (3/4)
nächster Schritt: Einbau alternativer Abläufe Kunde ist am Angebot nicht interessiert In den Vertragsverhandlungen werden neue Rahmenbedingungen formuliert, so dass eine Nachkalkulation notwendig wird [nächste Folie] Bis zu einem Vertragsvolumen von 20 T€ entscheidet der Abteilungsleiter, darüber die Geschäftsleitung ob vorliegender Vertrag abgeschlossen werden soll oder Nachverhandlungen nötig sind Die Fachabteilung hat Nachfragen, die der Vertriebsmitarbeiter mit dem Kunden klären muss Stephan Kleuker

23 Beispiel: Vertrieb (4/4)
Stephan Kleuker

24 Modellierungsfalle Basierend auf Erfahrungen mit Flussdiagrammen könnte man zu folgender Modellierung kommen Dies würde nach UML-Semantik bedeuten, dass für die Aktion Vertragsverhandlung zwei Kostenvorschläge (initial und aktualisiert) vorliegen müssten Wenn verschiedenen Wege zu einer Aktion führen sollen, muss vor der Aktion ein Zusammenführungs-Kontrollknoten stehen Stephan Kleuker

25 Diagramme können leicht komplex werden Lösungsmöglichkeiten:
Problem Lesbarkeit Diagramme können leicht komplex werden Lösungsmöglichkeiten: Verteilung von Diagrammen auf mehrere Seiten mit Ankerpunkten Verzicht, alle Elemente in einem Diagramm darzustellen (z. B. Produkte weglassen; dies nur in der immer zu ergänzenden Dokumentation erwähnen) Diagramme hierarchisch gestalten; eine Aktion kann durch ein gesamtes Aktivitätsdiagramm verfeinert werden, z. B. ist „Kosten kalkulieren“ eigener Prozess; dies sollte im Modell sichtbar werden Stephan Kleuker

26 Prozessverfeinerung: Kosten kalkulieren
Anmerkung: Verantwortliche weggelassen, da immer „Projekt-begleiter der Fachabteilung“ Stephan Kleuker

27 Nutzung von Schwimmbahnen (für Rollen)
Stephan Kleuker

28 Problem Abstraktionsgrad
Frage: Wann nur eine Aktion, wann mehrere Aktionen Indikator: Mehrere Aktionen zusammenfassen, wenn nur ein Produkt entsteht, das ausschließlich in diesen Aktionen benötigt wird („lokale Variable“) oder diese von nur einer Person bearbeitet werden Typischerweise Prozesshierarchie: Unternehmensebene; d.h. ein Diagramm für jeden Prozess der Kern-, Management- und Supportprozesse Prozessebene: Verfeinerung des Prozesses, so dass alle auch nur intern sichtbaren Rollen und Produkte sichtbar werden Arbeitsprozess: Individuelle Beschreibung der Arbeitsschritte einer Rolle für eine/ mehrere Aktionen Probleme: Flexibilität und Akzeptanz Stephan Kleuker

29 Querschnittsprozess: Projekt-Risikomanagement
Projekte stoßen häufig auf Probleme, die man frühzeitig hätte erkennen und auf die man dann reagieren könnte; dieser Prozess heißt (Projekt-) Risikomanagement (RM) Idee: frühzeitig über potenzielle Probleme nachdenken, genauer: Vermeidungsmöglichkeiten Maßnahmen zur Verringerung der Eintrittswahrscheinlichkeit Maßnahmen beim Eintreffen des Problems ersten beiden Ansätze heißen pro-aktives RM, letzter Ansatz reaktives RM oder Notfall-Plan 2.3 DeMarco, T.; Lister, T.: Bärentango – Mit Risikomanagement Projekte zum Erfolg führen, Hanser, München, 2003 Wallmüller, E.: Risikomanagement für IT- und Software-Projekte, Hanser, München, 2004 Gaulke, M.: Risikomanagement in IT-Projekten, Oldenbourg, München, 2004 Versteegen, G.: Risikomanagement in IT-Projekten, Springer, Berlin, 2003 Stephan Kleuker

30 Beispiel RM bei Projektplanung
Risiko: Mangelnder Austausch von Know-How im Projektteam Auswirkungen: Arbeiten werden doppelt gemacht, vorhandenes Wissen nicht eingesetzt Ursache: Neues Projektteam, dass noch nicht zusammengearbeitet hat Maßnahme: (Verringerung) Erste Projektveranstaltung (Kick-off) findet in kleinem Hotel außerhalb des Unternehmens statt; moderierte Workshops zum Aufbau des Verständnisses der Projektaufgabe und zur Findung vorhandener Kompetenzen Messung des Maßnahmenerfolgs: Kontrolle auf Doppelarbeiten; Verfolgung der Qualität der Ergebnisse, die von mehreren Personen erstellt wurden (nur weiches Maß) Hinweis: Ursache und Risiko können verwischen, da Ursachen wieder Ursachen haben können (... irgendjemand in den Apfel gebissen hat  ) Stephan Kleuker

31 Risikomanagement Stephan Kleuker

32 Phasen des Risikomanagements (1/3)
Risiken identifizieren Identifikation eines Risikos, Festlegung der Risikoaussage und des Risikokontextes Aufnahme in die Risikoliste Risiken analysieren Festlegung der Eintrittswahrscheinlichkeit, der Auswirkungen, der erwarteten Tendenz und des Ursachenfeldes Priorisierung der vorhandenen Risiken unter Berücksichtigung der Gesamtrisikolage Stephan Kleuker

33 Phasen des Risikomanagements (2/3)
Maßnahmen planen Passende Maßnahmen definieren Festlegen der verantwortlichen Personen/Rollen Erfolgsfaktoren für Maßnahmen festlegen Maßnahmen durchführen Sammeln von Informationen/Daten zu den Veränderungen der Risiken und dem Erfolg der Maßnahmen Erstellen von Risikomeldungen für das Management Stephan Kleuker

34 Phasen des Risikomanagements (3/3)
Maßnahmen bewerten Bewertung der Veränderung von Risiken und des Erfolgs der angewendeten Maßnahmen Entscheidungsfindung zur weiteren Behandlung der Risiken und Anpassung der Maßnahmen Informationsverteilung zu den Risiken in Richtung Team und Vertragspartnern/Kunde Optimieren Maßnahmen zielgerichtet anpassen Hinweise/ Optimierungspotenziale für zukünftige Projekte erkennen Stephan Kleuker

35 3. Vorgehensmodelle 3.1 Phasen der Software-Entwicklung
3.2 Wasserfallmodell 3.3 Prototypische Entwicklung 3.4 Iterative Entwicklung 3.5 Iterativ-inkrementelle Entwicklung 3.6 Allgemeines V-Modell 3.7 Das V-Modell der Bundesrepublik Deutschland 3.8 Rational Unified Process 3.9 Agile Vorgehensmodelle 3.10 Scrum 3.11 Extreme Programming Stephan Kleuker

36 Herausforderungen der SW-Entwicklung
3.1 Software-Systeme sind heutzutage verteilte Anwendungen Anschluss an existierende Software (z.B. SAP, MS Office, bestehende Unternehmenssoftware...) Integration neuer Komponenten in existierende Systeme Erweiterung existierender Systeme eigene Komponenten Systeme an anderen Standorten ? neues System ? ? ? ? Legacy Systeme Systeme anderer Anbieter Stephan Kleuker

37 Die Phasen der SW- Entwicklung
Erhebung und Festlegung des WAS mit Rahmenbedingungen Klärung der Funktionalität und der Systemarchitektur durch erste Modelle Detaillierte Ausarbeitung der Komponenten, der Schnittstellen, Datenstrukturen, des WIE Ausprogrammierung der Programmiervorgaben in der Zielsprache Zusammenbau der Komponenten, Nachweis, dass Anforderungen erfüllt werden, Auslieferung Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration Stephan Kleuker

38 Wasserfallmodell Anforderungsanalyse Grobdesign Feindesign
3.2 Merkmale: Phasen werden von oben nach unten durchlaufen Vorteile: Plan auch für Nichtexperten verständlich einfache Meilensteinplanung lange Zeit am häufigsten eingesetzt Nachteile: - Anforderungen müssen 100%-ig sein späte Entwicklungsrisiken werden spät erkannt Qualität des Design passt sich Zeitplan an Optimierung: es ist möglich, in die vorherige Phase zu springen Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration Stephan Kleuker

39 Prototypische Entwicklung
3.3 Merkmale: potenzielle Probleme frühzeitig identifiziert, Lösungsmöglichkeiten im Prototypen gefunden, daraus Vorgaben abgeleitet Vorteile: frühzeitige Risikominimierung schnelles erstes Projektergebnis Nachteile: - Anforderungen müssen fast 100%-tig sein Prototyp (illegal) in die Entwicklung übernommen Kunde erwartet schnell Endergebnis Optimierung: es ist möglich, in die vorherige Phase zu springen Anforderungs- analyse Grobdesign Feindesign Implemen- tierung Test und Integration Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration Prototyp Stephan Kleuker

40 Iterative Entwicklung
3.4 Merkmale: Erweiterung der Prototypidee; SW wird in Iterationen entwickelt In jeder Iteration wird System weiter verfeinert In ersten Iterationen Schwerpunkt auf Analyse und Machbarkeit; später auf Realisierung große Vorteile: dynamische Reaktion auf Risiken Teilergebnisse mit Kunden diskutierbar Nachteile im Detail: schwierige Projektplanung schwierige Vertragssituation Kunde erwartet zu schnell Endergebnis Kunde sieht Anforderungen als beliebig änderbar Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration Stephan Kleuker

41 Iterativ Inkrementelle Entwicklung (State of the Art)
3.5 Merkmal: Projekt in kleine Teilschritte zerlegt pro Schritt neue Funktionalität (Inkrement) + Überarbeitung existierender Ergebnisse (Iteration) n+1-ter Schritt kann Probleme des n-ten Schritts lösen Vorteile: siehe „iterativ“ flexible Reaktion auf neue funktionale Anforderungen Nachteile: siehe „iterativ“ (etwas verstärkt) Optimierung/Anpassung: Anforderungsanalyse am Anfang intensiver durchführen Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration Bsp.: vier Inkremente Stephan Kleuker

42 Fertigstellung mit Iterationen
Stephan Kleuker

43 Bekanntheit von Vorgehensmodellen (1/2)
Quelle: Softwareentwicklung läuft nicht auf Zuruf, Computer Zeitung Nr. 46/05 Stephan Kleuker

44 Bekanntheit von Vorgehensmodellen (2/2)
Stephan Kleuker

45 Struktur komplexer Vorgehensmodelle
3.6 Aktuelle Vorgehensmodelle, wie V-Modell XT des Bundes (Rational) Unified Process OEP (Object Engineering Process) enthalten Aktivitäten (was soll gemacht werden), Rollen (wer ist wie an Aktivität beteiligt) und Produkte (was wird benötigt; bzw. ist Ergebnis) es gibt Vorschläge für typische Anwendungsszenarien, wie Aktivitäten zu verknüpfen sind Rahmenwerke, am Anfang eines Projekts muss (werkzeuggestützt) bestimmen, welche Aktivitäten, Rollen, Produkte und Reihenfolgen von Aktivitäten für das individuelle Projekt relevant sind (tailoring, d. h. „zurecht schneidern“, benötigt viel Erfahrung) Stephan Kleuker

46 allgemeines V-Modell Konstruktion Integration Anforderungs- definition
Validierung Anforderungs- definition Abnahme- test Validierung Funktionaler Systementwurf System- test manuelle Prüfung Technischer Systementwurf Validierung Integrations- test manuelle Prüfung Komponenten- Spezifikation Validierung Komponenten- test manuelle Prüfung Programmierung manuelle Prüfung Konstruktion Integration Anmerkung: wird iterativ / inkrementell zum W-Modell Stephan Kleuker

47 V-Modell des Bundes 3.7 Regelung der Softwarebearbeitung (im Bereich der Bundeswehr, des Bundes und der Länder) einheitliche und (vertraglich) verbindliche Vorgabe von Aktivitäten und Produkten (Ergebnissen), Historie: V-Modell 92 (Wasserfall im Mittelpunkt), Überarbeitung V-Modell 97 (Anpassung an inkrementelle Ideen (W-Modell); Forderung nach zu früher Festlegung von Anforderungen) aktuell: V-Modell XT (eXtreme Tailoring), neuer Erstellung mit Fokus auf Verhältnis von Auftragnehmer und Auftraggeber (starker akademischer Einfluss bei Entwicklung) Stephan Kleuker

48 Struktur des V-Modell XT
für V-Modell XT-Informationen: Copyright Reserved © Bundesrepublik Deutschland 2004. Stephan Kleuker

49 Produktorientierung im V-Modell XT
Eine Projektdurchführungsstrategie definiert die Reihenfolge der im Projekt zu erreichenden Projektfortschrittsstufen; nutzt Entscheidungspunkte (go, no go) Produkte stehen im Mittelpunkt, sie sind DIE Projektergebnisse Projektdurchführungsstrategien und Entscheidungspunkte geben die Reihenfolge der Produktfertigstellung und somit die grundlegende Struktur des Projektverlaufs vor Die detaillierte Projektplanung und -steuerung wird auf der Basis der Bearbeitung und Fertigstellung von Produkten durchgeführt Für jedes Produkt ist eindeutig eine Rolle verantwortlich und im Projekt dann eine der Rolle zugeordnete Person Die Produktqualität ist überprüfbar durch definierte Anforderungen an das Produkt und explizite Beschreibungen der Abhängigkeiten zu anderen Produkten Stephan Kleuker

50 Entscheidungspunkte des V-Modells XT
relevant für alle V-Modell-Projekte Schnittstelle Auftraggeber / Auftragnehmer Organisationsspezifisches V-Modell Systementwicklung Projekt genehmigt Projekt definiert Anforderungen festgelegt Projekt ausgeschrieben Angebot abgegeben Vorgehensmodell analysiert Geamtprojekt aufgeteilt Gesamtfortschritt überprüft Projektfortschritt überprüft Verbesserung Vorgehensmodell konzipiert Projekt beauftragt Iteration geplant Abnahme erfolgt Projekt abgeschlossen System spezifiziert Lieferung durchgeführt Verbesserung Vorgehensmodell realisiert System entworfen System integriert Feinentwurf abgeschlossen Systemelemente realisiert Stephan Kleuker

51 Beispiel: Projektdurchführungsplan
(Systementwicklungsprojekt eines Auftraggebers (AG)) Stephan Kleuker

52 Beispielaktivität: Anforderungen festlegen
Stephan Kleuker

53 Rational Unified Process (RUP)
3.8 aus IBM/Rational: Rational Unified Process Stephan Kleuker

54 Phasen des RUP inception (Konzeption): Ermittlung zentraler Anforderungen, Projektumfang definieren, erste Entwurfs- und Implementierungsansätze, Identifikation der Projektrisiken und Aufwände elaboration (Ausarbeitung): stabile, möglichst vollständige Anforderungen, Entwurfsspezifikation, detaillierter Projektplan mit aktivem Risikomanagement construction (Konstruktion): Implementierung, Integration, auslieferbare Version transition (Inbetriebnahme): Beta-Test, Endabnahme, Inbetriebnahme, Endlieferung Stephan Kleuker

55 Struktur des RUP Stephan Kleuker

56 Kritik an klassischen Vorgehensmodellen
3.9 Es müssen viele Dokumente erzeugt und gepflegt werden Eigene Wissenschaft Modelle wie V-Modelle und RUP zu verstehen und zurecht zu schneidern Prozessbeschreibungen hemmen Kreativität Anpassung an neue Randbedingungen, z. B. neue Technologien (Web-Services) in Prozessen und benutzten Werkzeugen ist extrem aufwändig alternativer Ansatz: „Menschen machen Projekte erfolgreich, traue den Menschen“ => agile Prozesse (vorherige Name: leichtgewichtige Prozesse) Stephan Kleuker

57 Arten von agilen Prozessen (1/2)
generell: Methoden lernen von einander; es gibt nicht die eine agile Methode Variante 1: Beschreibung auf Metaprozessebene Grundregeln zur Projektorganisation Vorgehensweisen in Projekten werden vom Team festgelegt Beispiele: Scrum (u. a. Ken Schwaber, Jeff Sutherland) [s. Folien] Crystal Methodenfamilie (Alistair Cockburn) Stephan Kleuker

58 Arten von agilen Prozessen (2/2)
Variante 2: Konkrete Prozessbeschreibungen Für verschiedene Phasen der Software-Entwicklung werden konkrete Verfahren vorgeschlagen Abhängigkeiten der Verfahren werden dokumentiert („wer A macht muss auch B machen“); Möglichkeiten zur individuellen Optimierung Beispiele: eXtreme Programming (XP) (u. a. Kent Beck, Ward Cunningham) [s. Folien] Dynamic Systems Development Method (Konsortium) Stephan Kleuker

59 Agiles Manifest (Februar 2001)
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas Stephan Kleuker

60 Scrum (1/2) („Scrum“: Gedränge beim Rugby)
3.10 („Scrum“: Gedränge beim Rugby) Scrum Teams mit maximal 7 Personen mit unterschiedlichen Fähigkeiten, Koordinator (Scrum Master), Anforderungsdefinerer (Product Owner), Entwickler-Team Bei größeren Teams: mehrere Teilteams durch Scrum Master koordiniert Zentrales Steuerungselement: Scrum meetings; jeden Tag 15 Minuten: was habe ich seit letztem Meeting gemacht? was werde ich bis zum nächsten Meeting machen? was hat meine Arbeit behindert? Scrum Master ist Koordinator; beseitigt Behinderungen; kommuniziert im Unternehmen Arbeitsablauf im Team wird vom Team selbst geregelt Stephan Kleuker

61 Scrum (2/2) Projektplanung: Eng mit dem Kunden werden Hauptaufgaben identifiziert (Stack mit product backlog) Product Owner nimmt Rolle des Kunden ein (kommt von Kunden, oder erfahren im Anwendungsgebiet) Hauptaufgaben können auch Test von Technologien und die Entwicklung von Prototypen sein Scrum Team schätzt Aufwände; wählt mit Kunden aus product backlog wichtigste nächste Aufgaben für nächste Iteration (heißt sprint) aus (in sprint backlog) Jeder sprint dauert ca Tage; sprint backlog mit priorisierten Aufgaben; sorgt für nicht unterbrochene Arbeitsphase des Teams (Scrum Master kann abbrechen) Nach jedem sprint Analyse mit dem Kunden, was wurde erreicht; wie kann Projekt verbessert werden [zurück Planung] siehe auch: Stephan Kleuker

62 Scrum - Überblick Product backlog Aufgabe 1 Aufgabe 2 ... sprint
Teilaufgabe 1 Teilaufgabe 2 ... Arbeitstag Scrum-Meeting Planung für sprint Sprint Review Sprint Retrospective sprint 21 Arbeitstage Stephan Kleuker

63 Ideen des Extreme Programming (XP) (1/3)
3.11 Planning User stories are written Release planning creates the schedule Make frequent small releases The Project Velocity is measured The project is divided into iterations Iteration planning starts each iteration Move people around A stand-up meeting starts each day Fix XP when it breaks Designing Simplicity Choose a system metaphor Use CRC cards for design sessions Create spike solutions to reduce risk No functionality is added early Refactor whenever and wherever possible Stephan Kleuker

64 Ideen des Extreme Programming (XP) (2/3)
Coding The customer is always available Code must be written to agreed standards Code the unit test first All production code is pair programmed Only one pair integrates code at a time Integrate often Use collective code ownership Leave optimization till last No overtime Testing All code must have unit tests All code must pass all unit tests before it can be released When a bug is found tests are created Acceptance tests are run often and the score is published Stephan Kleuker

65 Ideen des Extreme Programming (XP) (3/3)
Testfälle User Stories neue User-Story geänderte Randbedingung Fehler Anfor- derungen Release- Planung Release- plan aktuelle Version Akzeptanz -tests Iteration System- idee unklare Annahmen abgesicherte Annahmen Kunden- zustimmung nächste Iteration Architektur- ansatz Miniprototyp (Spike) kleine Releases Quelle der XP-Folien : Varianten: z. B. in der Nutzung von Dokumentation (keine – minimal) Stephan Kleuker

66 Versuch einer Beurteilung von agilen Methoden
agile Methoden haben viele Innovationen in verstaubte SW-Entwicklungsprozesse gebracht (etwas Neues; viel neu arrangiertes) Einsetzbarkeit hängt stark von technischen und menschlichen Fähigkeiten des Teams ab große Erfolge möglich, wenn Dream-Team gefunden Aufpassen bei Beratungs-Hype („XP ist die Zukunft“) Hamburger Berater: Wir haben agile Methoden erfolgreich in Versicherung X eingeführt und manifestiert Projektleiter bei X: Haben neue Ideen zur Optimierung unseres existierenden Prozesses genutzt; konkret übrig geblieben sind Stand-Up-Meetings Agiles Manifest interessant für alle SW-Entwicklungsprozesse Ideen auf andere Ansätze übertragbar Überblick mit Kommentaren in Artikeln von J. Coldewey Generell: Vorgehensmodell muss zum Projekt und den Menschen passen Stephan Kleuker

67 4. Anforderungsanalyse 4.1 Stakeholder und Ziele
4.2 Klärung der Hauptfunktionalität (Use Cases) 4.3 Beschreibung typischer und alternativer Abläufe 4.4 Ableitung funktionaler Anforderungen 4.5 Nicht-funktionale Anforderungen 4.6 Lasten- und Pflichtenheft Literatur: [RS] C. Rupp, SOPHIST GROUP, Requirements- Engineering und – Management, Hanser Fachbuchverlag [OW] B. Oestereich, C. Weiss, C. Schröder, T. Weilkiens, A. Lenhard, Objektorientierte Geschäftsprozessmodellierung mit der UML, dpunkt.Verlag Stephan Kleuker

68 so nicht (1/4): Beispiel-Szenario
Zur Stundenerfassung und Abrechnung werden von den Projektmitarbeitern spezielle Excel-Tabellen jeden Freitag ausgefüllt und am Montag vom Projektleiter bei der Verwaltung abgegeben. Der zuständige Sachbearbeiter überträgt dann die für den Projektüberblick relevanten Daten manuell in ein SAP-System. Dieses System generiert automatisch eine Übersicht, aus der die Geschäftsführung ablesen kann, ob die Projekte wie gewünscht laufen. Dieser Bericht liegt meist am Freitag der Woche vor. Die Bearbeitungszeit ist der Geschäftsführung zu lang, deshalb soll der Arbeitsschritt automatisiert werden. Stephan Kleuker

69 so nicht (2/4): Die Projektplanung
Es wird ein Projekt „Projektberichtsautomatisierung“ (ProAuto) beschlossen. Der Leiter der hausinternen IT-Abteilung wird über die anstehende Aufgabe informiert. Er erhält eine Beschreibung der Excel-Daten und der gewünschten SAP-Daten. Der Leiter stellt fest, dass seine Abteilung das Know-how und die Kapazität hat, das Projekt durchzuführen und legt der Geschäftsführung einen Projektplan mit einer Aufwandsschätzung vor. Die Geschäftsführung beschließt, das Projekt intern durchführen zu lassen und kein externes Angebot einzuholen. Stephan Kleuker

70 so nicht (3/4): Die Schritte zum Projektmisserfolg
Die IT-Abteilung analysiert die Excel-Daten und wie die Daten in das SAP-System eingefügt werden können. Kurz nach dem geschätzten Projektende liegt eine technisch saubere Lösung vor. Excel wurde um einen Knopf erweitert, so dass die ProAuto Projektleiter per Knopfdruck die Daten nach SAP überspielen können. Vier Wochen nach Einführung des Systems wird der Leiter der IT-Abteilung entlassen, da die Daten zwar jeden Montag vorliegen, sich aber herausgestellt hat, dass sie nicht nutzbar sind und die erzürnte Geschäftsleitung falsche Entscheidungen getroffen hat. Das Projekt wird an eine Beratungsfirma neu vergeben. Stephan Kleuker

71 so nicht (4/4): so doch, Geschäftsprozessanalyse
Stephan Kleuker

72 Aufgabe der Anforderungsanalyse
4.1 Bestimmung aller Anforderungen an die zu erstellende Software bzw. an das zu erstellende DV-System, Anforderungen müssen vollständig, notwendig ("WAS statt WIE"), eindeutig und richtig ("abgestimmt als Teil einer Zielhierarchie") sein. Bemerkung zur Ablauforganisation: Anforderungen müssen nicht notwendig in einer Phase vor Beginn des Entwurfs vollständig bestimmt werden Stephan Kleuker

73 Probleme mit Anforderungen an große Systeme
Auftraggeber, Nutzer, Betreiber etc. sind häufig verschiedene Personen, unterschiedliche Personen haben teilweise widersprüchliche Anforderungen die Effekte des angestrebten Systems sind schwer vorhersehbar Anforderungen ändern sich im Laufe der Entwicklungszeit großer Umfang der Anforderungen komplexe Interaktion mit anderen Systemen Erste Aufgabe: Ermittlung der Stakeholder Definition: Jemand der Einfluss auf die Anforderungen hat, da er vom System betroffen ist (Systembetroffener) Zweite Aufgabe: Ermittlung der Ziele des Systems Stephan Kleuker

74 Checkliste zum Finden von Stakeholdern (1/3) [RS]
Endanwender Die größte und wichtigste Gruppe, liefert Großteil der fachlichen Ziele Durchdachtes Auswahlverfahren für die Anwenderrepräsentanten nötig (Vertrauensbasis der gesamten Anwendergruppe berücksichtigen!) Management des Auftragnehmers (wir) Gewährleisten die Konformität mit Unternehmenszielen und Strategien, sowie der Unternehmensphilosophie Sind die Sponsoren! Käufer des Systems Wer ist für die Kaufentscheidung verantwortlich? Liefer-Vertrags-Zahlungskonditionen? Prüfer, Auditoren sind für Prüfung, Freigabe und Abnahme notwendig, Entwickler Entwickler nennen die technologiespezifischen Ziele Stephan Kleuker

75 Checkliste zum Finden von Stakeholdern (2/3)
Wartungs- und Servicepersonal Wartung und Service muss unkompliziert und zügig durchzuführen sein Wichtig bei hohen Stückzahlen Produktbeseitiger Wichtig, wenn ausgeliefertes Produkt nicht nur Software umfasst, Frage der Beseitigung (z.B. Umweltschutz), kann enormen Einfluss auf die Zielsetzung einer Produktentwicklung haben Schulungs- und Trainingspersonal Liefern konkrete Anforderungen zur Bedienbarkeit, Vermittelbarkeit, Hilfesystem, Dokumentation, Erlernbarkeit, Marketing und Vertriebsabteilung Marketing und Vertrieb als interne Repräsentanten der externen Kundenwünsche und der Marktentwicklung Stephan Kleuker

76 Checkliste zum Finden von Stakeholdern (3/3)
Systemschützer Stellen Anforderungen zum Schutz vor Fehlverhalten von Stakeholdern Standards und Gesetze vorhandene und zukünftige Standards/Gesetze berücksichtigen Projekt- und Produktgegner Die Klasse der Projekt- und Produktgegner - vor allem zu Beginn des Projekts wenn möglich mit einbeziehen, sonst drohen Konflikte Kulturkreis setzt Rahmenbedingungen, z.B. verwendete Symbolik, Begriffe, … Meinungsführer und die öffentliche Meinung beeinflussen oder schreiben Ziele vor, Zielmärkte berücksichtigen Stephan Kleuker

77 Regeln für die Definition von Zielen
Ziele müssen vollständig, korrekt, konsistent gegenüber anderen Zielen und in sich konsistent, testbar, verstehbar für alle Stakeholder, umsetzbar — realisierbar, notwendig, eindeutig und positiv formuliert sein. Zwei weitere Merkmale: Lösungsneutralität einschränkende Rahmenbedingungen Hinweis: Ziele sind abstrakte Top-Level-Anforderungen Stephan Kleuker

78 Schablone zur Zielbeschreibung
Was soll erreicht werden? Stakeholder Welche Stakeholder sind in das Ziel involviert? Ein Ziel ohne Stakeholder macht keinen Sinn. Auswirkungen auf Stakeholder Welche Veränderungen werden für die Stakeholder erwartet? Rand-bedingungen Welche unveränderlichen Randbedingungen müssen bei der Zielerreichung beachtet werden? Abhängigkeiten Ist die Zielverknüpfung mit anderen Zielen unmittelbar verknüpft? Dies kann einen positiven Effekt haben, indem die Erfüllung von Anforderungen zur Erreichung mehrerer Ziele beiträgt. Es ist aber auch möglich, dass ein Kompromiss gefunden werden muss, da Ziele unterschiedliche Schwerpunkte haben. Sonstiges Was muss organisatorisch beachtet werden? Stephan Kleuker

79 Projektbeschreibung Zu entwickeln ist ein individuell auf die Unternehmenswünsche angepasstes Werkzeug zur Projektverwaltung. Dabei sind die Arbeitspakete (wer macht wann was) und das Projektcontrolling (wie steht das Projekt bzgl. seiner Termine und des Budgets) zu berücksichtigen. Projekte werden zur Zeit ausgehend von Projektstrukturplänen geplant und verwaltet. Projekte können in Teilprojekte zerlegt werden. Die eigentlichen Arbeiten finden in Arbeitspaketen, auch Aufgaben genannt, statt. Projekten werden von zusammenzustellenden Projektteams bearbeitet, die zugehörigen Mitarbeiterdaten sind zu verwalten. Zur Ermittlung des Projektstands tragen Mitarbeiter ihre Arbeitszeit und den erreichten Fertigstellungsgrad in das System ein. Stephan Kleuker

80 Ziele für eine Projektmanagementsoftware (1/3)
1. Die Software muss die Planung und Analyse aller laufenden Projekte ermöglichen Stakeholder Projektplaner, Projektleiter, Mitarbeiter, Controlling (alle als Endanwender) Auswirkungen auf Stakeholder Projektplaner: Alle Planungsdaten fließen in das neue Werkzeug, es gibt sofort eine Übersicht, wer an was, von wann bis wann arbeitet. Projektleiter: Der Projektleiter ist immer über den Stand informiert, er weiß, wer an was arbeitet. Mitarbeiter: Die Mitarbeiter sind verpflichtet, ihre Arbeitsstunden und erreichten Ergebnisse in das Werkzeug einzutragen. Sie sehen, für welche Folgearbeiten sie wann verplant sind. Controlling: Hat Überblick über Projektstand. Rand-bedingungen Existierende Datenbestände sollen übernommen werden. Die Randbedingungen zur Verarbeitung personalbezogener Daten sind zu beachten. Abhängigkeiten - Sonstiges Es liegt eine Studie des Kunden vor, warum kein Produkt vom Markt zur Realisierung genommen wird. Stephan Kleuker

81 Ziele für eine Projektmanagementsoftware (2/3)
2. Der neue Kunde soll von der fachlichen Kompe-tenz unseres Unternehmens überzeugt werden. Stakeholder Management, Entwickler Auswirkungen auf Stakeholder Management: Der Projekterfolg hat große Auswirkungen auf die nächsten beiden Jahresbilanzen. Entwickler: Es werden hohe Anforderungen an die Software-Qualität gestellt. Rand-bedingungen Es muss noch geprüft werden, ob langfristig eine für beide Seiten lukrative Zusammenarbeit überhaupt möglich ist. Abhängigkeiten Überschneidung mit dem Ziel 3, da eine Konzentration auf die Wünsche des neuen Kunden eventuell einer Verwendbarkeit für den allgemeinen Markt widersprechen kann. Sonstiges Das Verhalten des neuen Kunden bei Änderungswünschen ist unbekannt. Stephan Kleuker

82 Ziele für eine Projektmanagementsoftware (3/3)
3. Das neue Produkt soll für einen größeren Markt einsetzbar sein. Stakeholder Management, Vertrieb, Entwickler Auswirkungen auf Stakeholder Management: Es soll eine Marktposition auf dem Marktsegment Projektmanagement-Software aufgebaut werden. Vertrieb: In Gesprächen mit Kunden wird das neue Produkt und seine Integrationsmöglichkeit mit anderen Produkten ab Projektstart beworben. Entwickler: Die Software muss modular aufgebaut aus Software-Komponenten mit klaren Schnittstellen bestehen. Randbedingungen - Abhängigkeiten zu Ziel 2 (Beschreibung dort) Sonstiges Eine Analyse der Konkurrenten auf dem Markt liegt vor. Es sind Möglichkeiten für neue, den Markt interessierende Funktionalitäten aufgezeigt worden. Stephan Kleuker

83 Rahmenbedingungen und weiteres Vorgehen
Traceability: alle Anforderungen müssen sich auf ein Ziel zurückführen lassen alle Ziele benötigen einen Stakeholder (Ökonomie-Check) Kommunikation: die ausgewählten Stakeholder müssen nun detaillierter befragt und dauerhaft in das Projekt integriert werden Warum der ganze Aufwand: Vergessene Ziele und Stakeholder führen zu massiven Change Requests Das eigentliche SW-Projekt kann beginnen Stephan Kleuker

84 Überblick über den Analyseprozess
4.2 1. Erfassung der Systemaufgaben mit „Use Cases“ 2. Beschreibung der Aufgaben mit Aktivitätsdiagrammen (optional 3. Formalisierung der Beschreibungen in Anforderungen) 4. Aufbau eines tieferen Verständnisses durch Klassenmodellierung und Sequenzdiagramme (Grobdesign) iterativer Prozess Stephan Kleuker

85 Was sind die Hauptaufgaben des Systems?
Erfragung des WAS? Zentrale Frage: Was sind die Hauptaufgaben des Systems? Wer ist an den Aufgaben beteiligt? Welche Schritte gehören zur Aufgabenerfüllung? => Aufgaben werden als Use Cases (Anwendungsfälle) beschrieben => Beteiligte werden als Aktoren festgehalten (können meist aus der Menge der Stakeholder entnommen werden) Stephan Kleuker

86 Use Case (Anwendungsfall)
Use Case beschreibt in der Sprache der Stakeholder, d.h. in natürlicher Sprache, eine konsistente und zielgerichtete Interaktion des Benutzers mit einem System, an deren Anfang ein fachlicher Auslöser steht und an deren Ende ein definiertes Ergebnis von fachlichem Wert entstanden ist Ein Use Case beschreibt das gewünschte externe Systemverhalten aus Sicht des Anwenders und somit Anforderungen, die das System erfüllen soll eine Beschreibung was es leisten muss, aber nicht wie es dies leisten soll Unterscheidung in Geschäftsanwendungsfall (business use case) formuliert aus Geschäftssicht (z. B. Vertriebsprozess vom Anfang) und Systemanwendungsfall (system use case) formuliert aus Sicht der durch die neue SW zu lösenden Aufgabe Stephan Kleuker

87 Zusammenhang der Use Case Arten
Für ein neu geplantes SW-System wird zunächst analysiert, welche Prozesse mit der SW unterstützt werden sollen (Geschäftsprozessmodellierung) Oft geht mit dieser Modellierung auch eine Optimierung einher Man erhält zentrale Aufgaben, die das SW-System übernehmen soll (Business Use Case) Ausgehend davon werden die Aufgaben geplant, die das SW-System unterstützen/ausführen soll, dies sind die System Use Cases Häufig gehört zu einem Business Use Case ein System Use Case, d. h. es gibt die gleiche Überschrift, aber eine unterschiedliche Beschreibung (im System Use Case steht die Nutzung des neues SW-Systems im Mittelpunkt) Es kann weitere System Use Cases geben, die z. B. die Systemwartung oder neue Analysemöglichkeiten betreffen Stephan Kleuker

88 Wege zur Use Case-Ermittlung
moderierter Workshop zentraler Stakeholder Beobachtung des Kunden, der Endnutzer Fragebögen Interviews Kunde vor Ort im Projekt Analyse von Altsystemen und Dokumenten des Kunden Simulationsmodelle Stephan Kleuker

89 Darstellungsbeispiel: Lagerverwaltungssystem
Externe Sicht des Nutzers auf die Aufgaben des Systems Aktoren können Personen oder andere Systeme sein Use Cases können in Teilpaketen strukturiert werden Stephan Kleuker

90 Systematische Use-Case Ermittlung (1/2)
Welche Basisinformationen / Objekte sind zu bearbeiten (keine Detailmodellierung, keine Informationen, die aus anderen berechenbar sind)? Beispiel (Projektmanagementsystem): Projekte, Mitarbeiter Prüfe ob neues System Basisinformationen verwaltet oder Sie aus existierenden Systemen stammen neues System: Use Case „Basisinformation XY verwalten“ gefunden (evtl. in „anlegen“, „bearbeiten“, „löschen“ trennen) existierendes System: tritt als Aktor auf, wenn Daten benötigt Welche Prozessinformationen sind zu verwalten, also dynamisch entstehende Daten, Daten zur Verknüpfung von Basisinformationen Beispiel: Projektteams, Arbeitsstunden der Mitarbeiter Ergänze Use Cases, die die Verknüpfung der Daten herstellen, z. B. „Projektteams zusammenstellen“, „Arbeitsstand aktualisieren“ Stephan Kleuker

91 Systematische Use-Case Ermittlung (2/2)
Ermittle Funktionalität, die auf Basis der Verarbeitung von Basis- und Prozessinformationen benötigt wird abstrakte Beispiele: Entscheidungsprozesse/ Analyseprozesse zur Auswertung (Statistiken, Übersichten) Ergänze Use Case für jede der Prozessarten (Art bedeutet, Zusammenfassung eng verwandter Funktionalität) Beispiel: „Projektstand analysieren“ Ermittle Use Cases zur reinen Systempflege insofern es besondere Herausforderungen gibt abstrakte Beispiele: langfristige Datenhaltung, Systemstart, Systemterminierung Zeichne Use Case-Diagramm und ergänze Aktoren (z. B. Stakeholder, genutzte Systeme, Time) und Dokumentation Stephan Kleuker

92 Abgeleitetes Use Case-Diagramm
Stephan Kleuker

93 Use Case-Erstellung genauer
Beschreibung eines Use Cases zunächst verbal relativ abstrakt, wird später verfeinert Leitfragen für die Ermittlung von Akteuren und Prozessen Welcher Akteur löst Use Case aus? Welche Akteure sind am Use Case beteiligt? Welche Aufgaben sind im Use Case zu erfüllen? Wer ist verantwortlich für Planung, Durchführung, Kontrolle der Aufgaben? Welche Ereignisse starten den Use Case, treten im Use Case auf? Welche Bedingungen sind zu beachten? Was sind die Ergebnisse des Use Cases? Welche Beziehungen gibt es zu welchen anderen Use Cases? Stephan Kleuker

94 Verfeinerung der Use Case-Dokumentation
4.3 Im ersten Schritt werden in den Use Cases nur die Hauptaufgaben des Systems beschrieben Zur Dokumentation der Use Cases gehört zunächst nur eine grobe kurze Beschreibung (maximal 5 Sätze) des Inhalts Im nächsten Schritt wird dieser Inhalt konkretisiert. Dabei ist es sinnvoll, auf eine Dokumentationsschablone zurück zu greifen (oder eine für das Projekt zu entwickeln) Im ersten Schritt der Beschreibungsentwicklung wird nur der typische Ablauf des Use Cases ohne Alternativen, dann mit Alternativen beschrieben Stephan Kleuker

95 Dokumentationsschablone für Use Cases (1/3)
Name des Use Case 1 kurze prägnante Beschreibung, meist aus Verb und Nomen Nummer eindeutige Nummer zur Verwaltung, sollte von der eingesetzten Entwicklungsumgebung vergeben werden Paket 2 bei sehr komplexen Systemen können Use Cases in Teilaufgabenbereiche zusammengefasst werden, diese Bereiche können in der UML als Pakete dargestellt werden Autor wer hat den Use Case erstellt und wer mitgearbeitet Version aktuelle Versionsnummer, möglichst mit Änderungshistorie, wer hat wann was geändert Kurzbeschrei-bung kurze Beschreibung, was mit dem Use Case auf welchem Weg erreicht werden soll, beteiligte Aktoren (Stakeholder) welche Aktoren sind beteiligt, wer stößt den Use Case an Stephan Kleuker

96 Dokumentationsschablone für Use Cases (2/3)
Fachverant-wortlicher 1 wer steht auf fachlicher Seite für Fragen zum Use Case zur Verfügung und entscheidet auf Auftraggeberseite für die Software über den Inhalt Referenzen 2 Nennung aller Informationen, die bei der späteren Ausimplementierung zu beachten beziehungsweise hilfreich sind, dies können Verweise auf Gesetze, Normen oder Dokumentationen existierender Systeme sein Vorbedingun-gen was muss erfüllt sein, damit der Use Case starten kann Nachbedin-gungen wie sieht das mögliche Ergebnis aus, im nächsten Schritt sind auch die Ergebnisse alternativer Abläufe zu berücksichtigen typischer Ablauf welche einzelnen Schritte werden im Use Case durchlaufen, dabei wird nur der gewünschte typische Ablauf dokumentiert alternative Abläufe 3 welche Alternativen existieren zum typischen Ablauf Stephan Kleuker

97 Dokumentationsschablone für Use Cases (3/3)
Kritikalität 3 wie wichtig ist diese Funktionalität für das Gesamtsystem Verknüpfungen welche Zusammenhänge bestehen zu anderen Use Cases funktionale Anforderungen 4 welche konkreten funktionalen Anforderungen werden aus diesem Use Case abgeleitet nicht-funktionale Anforderungen welche konkreten nicht-funktionalen Anforderungen werden aus diesem Use Case abgeleitet Nummer gibt Iteration an, in der das Feld gefüllt wird typischer und alternative Abläufe werden jetzt genauer betrachtet funktionale und nicht-funktionale Anforderungen weiter hinten in diesem Abschnitt Stephan Kleuker

98 Beispielbeschreibung (1/2)
Name des Use Case Projektstruktur bearbeiten Nummer U1 Paket - Autor Ali Analytiker Version 1.0, , Erstellung Kurzbeschrei-bung Mitarbeiter des Projektbüros haben die Möglichkeit, Projekte mit Teilprojekten anzulegen und zu bearbeiten. beteiligte Aktoren (Stakeholder) Projektbüro (startet Use Case durch Auswahl der Funktionalität im zu erstellenden System) Fachverant-wortlicher Lisa Leitung (zentrale Ansprechpartnerin des Kunden) Referenzen Handbuch zur Führung von Projekten des Kunden Stephan Kleuker

99 Beispielbeschreibung (2/2)
Vorbedingun-gen Die Software ist vollständig installiert und wurde gestartet. Nachbedingun-gen Neue Projekte und Teilprojekte sowie Änderungen von Projekten und Teilprojekten wurden vom System übernommen. typischer Ablauf Nutzer wählt Funktionalität zur Bearbeitung von Projektstrukturen Nutzer legt Projekt mit Projektstandarddaten an Nutzer ergänzt neue Teilprojekte Nutzer verlässt Funktionalität alternative Abläufe Nutzer kann existierendes Projekt auswählen, Nutzer kann Daten eines Teilprojekts ändern Kritikalität sehr hoch, System macht ohne Funktionalität keinen Sinn Stephan Kleuker

100 Hinweise zu Use Cases (1/2)
Verwende für den Use Case eine sinnvolle Bezeichnung, die mindestens aus einem echten Substantiv und einem aktiven Verb ("Antrag erfassen") oder dem zugehörigen Gerundium ("Antragserfassung") besteht! Definiere zuerst den fachlichen Auslöser und das fachliche Ergebnis, um Anfang und Ende des Use Cases festzulegen! Formuliere den Use Case so abstrakt wie möglich und so konkret wie nötig! Betreibe zunächst keine Zerlegung in abgeleitete, sekundäre Use Cases! Standardisiere die Sprache in den Use Cases! Stephan Kleuker

101 Hinweise zu Use Cases (2/2)
Use Cases eignen sich nicht zur funktionalen Zerlegung, d.h. ein Use Case beschreibt keine einzelnen Schritte, Operationen oder Transaktionen (bspw. "Vertrag drucken", "Kunden-Nr. erzeugen" etc.), sondern relativ große Abläufe (bspw. "Neuen Kunden aufnehmen") Es wird keine Ablaufreihenfolge definiert. Hierzu gibt es andere Ausdrucksmittel, z.B. Aktivitätsdiagramme Use Cases belassen das Sprachmonopol beim Stakeholder, wodurch die Use Cases angreifbarer und besser kritisierbar werden Stephan Kleuker

102 Analyse von Use-Case-Dokumentationen
Bei der Dokumentation von Use Cases kann es passieren, dass identische Abläufe mehrfach beschrieben werden Diese (nicht trivialen) Abläufe können als eigene Use Cases ausgegliedert werden; man sagt dann „ein Use Case nutzt einen anderen Use Case“ UML-Darstellung: In spitzen <<Klammern>> stehen so genannte Steoreotypen, mit denen man UML-Elementen zusätzliche Eigenschaften zuordnen kann <<include>> A B Stephan Kleuker

103 Beispiel zu <<include>>
Stephan Kleuker

104 <<extend>>
Seltene Variation des erweiterten Use Cases Wird nur unter bestimmter Bedingung ausgeführt, z. B. Sonderfall oder Fehlerbehandlung eigentlicher Use Case nicht durch Spezialfälle überfrachtet Stephan Kleuker

105 Hinweis zu <<include>>, <<extend>> (persönlich)
<<include>> ist ein sehr nützlicher Stereotyp, der die Dokumentation verkürzen kann Gerade bei in der Modellierung unerfahrenen Kunden sollte <<include>> zunächst verheimlicht werden, da sonst funktionale Zerlegungen in Bäumen das Ergebnis sind <<include>> wird dann bei der Dokumentation und späteren Verfeinerung bei der Umstrukturierung der Use Cases als Optimierung eingesetzt Hinweis: <<extend>> und weitere nicht erwähnte Möglichkeiten werden hier ignoriert, da es Kunden eher verwirrt Stephan Kleuker

106 Beschreibung verschiedener Abläufe
Bei Projekten mit enger Kundenbindung (z.B. bei engen Beziehungen zwischen AG und IT-Abteilung bei Inhouse-Projekten) können Use Cases (oder Nutzer Stories) als Anforderungsdokumentation ausreichen, wenn das Projekt in kleinen Iterationen und der Möglichkeit eines großen Kundeneinflusses entwickelt wird Oftmals ist die Beschreibung der Use Cases aber zu ungenau, gerade bei der Darstellung typischer und Alternativer Abläufe stellt sich die rein sprachliche Beschreibung als recht aufwändig heraus Da die UML eine graphische Sprache ist, stellt sie auch für Ablaufbeschreibungen eine grafische Darstellungsmöglichkeit, nämlich Aktivitätsdiagramme, zur Verfügung Stephan Kleuker

107 Modellierungsrichtlinie für Aktivitätsdiagramme
Modelliere zu jedem Use Case genau ein Aktivitätsdiagramm Mache aus den Use Case-Schritten Aktionen. Zerlege die Aktionen ggfls. mit einem Aktivitätsdiagramm, so dass sie stets genau einen fachlichen Arbeitsschritt repräsentieren. Ergänze den Ablauf um alle bekannten fachlichen Ausnahmen, fachlichen Fehler und fachlichen Ablaufvarianten, so dass das Diagramm eine vollständige Beschreibung aller zulässigen Ablaufmöglichkeiten darstellt. (sinnvoll jetzt oder später) Modelliere den Objektfluss: Beschreibe zu jeder Aktion die vorausgesetzten (zu verarbeitenden) und resultierenden (erzeugten oder veränderten) Geschäftsobjekte (Produkte). Unterscheide, bei welchen ausgehenden Transitionen bzw. Bedingungen welche Objekte bzw. Objektzustände resultieren. Stephan Kleuker

108 Aktivitätsdiagramm mit typischen Ablauf
Use Case: Projektstruktur bearbeiten Anmerkung: typischer Ablauf ist immer einfache Sequenz von Aktionen, Ausnahme wie hier: einfache Schleifen Stephan Kleuker

109 Aktivitätsdiagramm um Alternativen ergänzt
Stephan Kleuker

110 Erinnerung: Modellierung aus Business-Sicht
Stephan Kleuker

111 Modellierung aus System-Sicht
Stephan Kleuker

112 Formulierung von Anforderungen
4.4 Analog zu den Use Cases sind die Aktivitätsdiagramme zu dokumentieren, dabei ist genau zu beschreiben, was unter Nutzung welcher Hilfsmittel unter Berücksichtigung welcher Nebenbedingungen gilt Die Beschreibungen können oft unvollständig oder unklar formuliert sein, so dass es in größeren oder kritischeren Projekten sinnvoll ist, die Texte genauer zu analysieren Statt einer Fließtextdokumentation von Aktivitätsdiagrammen, kann eine Darstellung von systematisch abgeleiteten textuellen Anforderungen sinnvoll sein Man benötigt einen Ansatz, Texte möglichst präzise zu formulieren Stephan Kleuker

113 Probleme mit natürlich-sprachlichen Formulierungen
Hauptprozesse der menschlichen Modellbildung Tilgung Generalisierung Nominalisierung Problem: Anforderungen werden für Menschen mit anderer Modellbildung (da andere Erfahrungen) unsauber formuliert In Prosatexten sind Wiederholungen unerwünscht; bei Anforderungen müssen immer die gleichen Worte für den gleichen Sachverhalt genutzt werden Stephan Kleuker

114 Anforderungen: implizite Annahmen, unvollständige Vergleiche
Definition: Tilgung Tilgung ist ein Prozess, durch den wir unsere Aufmerksamkeit selektiv bestimmten Dimensionen unserer Erfahrungen zuwenden und andere ausschließen. (Bandler/Grinder) Beispiel: Die Fähigkeit des Menschen, In einem Raum voller sprechender Menschen alle anderen Geräusche auszuschließen oder auszufiltern, um der Stimme einer bestimmten Person zuzuhören. Anforderungen: implizite Annahmen, unvollständige Vergleiche Stephan Kleuker

115 Beispiele für Tilgungen (1/2)
Grundstruktur: Manche Prozessworte (Verben und Prädikate) implizieren zwei oder mehr Substantivargumente Sprachliche Vertreter Eingeben: Wer? Was? Wie? Wo? Wann? Anzeigen: Was? Wo? In welcher Weise? Wann? Übertragen: Wer? Was? Von wo? Wohin? Wann? „Die Auszahlungsmöglichkeit soll überprüft und die Auszahlung verbucht werden“ Überprüfen: Wer überprüft? Was wird überprüft? Nach welchen Regeln wird überprüft? Wann wird überprüft? Wie? Verbuchen: Wer verbucht? Was wird verbucht? Wann wird es verbucht? Wie? Stephan Kleuker

116 Beispiele für Tilgungen (2/2)
Grundstruktur: Der Bezugspunkt. die Messbarkeit und die Messgenauigkeit für einen Komparativ oder Superlativ fehlt. Sprachliche Vertreter: Adjektiv + Endung "-er/en", "-ste" oder "more", "less", "least", oder "weniger", "mehr" In beiden Sprachen: Adjektive wie leicht, easy, schwer, complicated, ... Für durchschnittlich große Menschen soll das Display im normalen Bedienabstand gut lesbar sein. Die Eingabe des angeforderten Geldbetrages soll vom System durch eine intuitive Benutzerführung so unterstützt werden, dass Fehleingaben minimiert werden. Kann man den Sachverhalt überhaupt messen? Ist der Bezugspunkt des Vergleiches angegeben? Mit welcher Messgenauigkeit wird gemessen? Stephan Kleuker

117 Definition: Generalisierung
Generalisierung ist der Prozess, durch den Elemente oder Teile eines persönlichen Modells von der ursprünglichen Erfahrung abgelöst werden, um dann die gesamte Kategorie, von der diese Erfahrung ein Beispiel darstellt, zu verkörpern. (Bendler/Grindler) Beispiel: Ein Kind verbrennt sich an einer heißen Herdplatte die Hand. Es sollte für sich die richtige Generalisierung aufstellen, dass es schmerzhaft ist auf heiße Herdplatten zu fassen. Anforderungen: Universalquantoren, unvollständige Bedingungen Stephan Kleuker

118 Generalisierung durch Universalquantoren
Grundstruktur: Menge an Objekten wird zusammengefasst Sprachliche Vertreter: Im Deutschen: nie, immer, kein, jeder, alle, ... Im Englischen: never, ever, not, each, always, ... Frage: Wirklich alle/jede, immer/nie? Gibt es keine Ausnahme? Achtung! Auch Sätze ohne Universalquantoren überprüfen, die keine Angaben über die Häufigkeit enthalten! Stephan Kleuker

119 Beispiele für Generalisierungen
Jede Auszahlung soll für die Rückverfolgbarkeit zusätzlich mit einem Zeitstempel etikettiert werden. Wirklich jede Auszahlung? Das System soll eine Sicherung von aufgezeichneten Auszahlungsdaten auf ein externes Speichermedium ermöglichen. Durch jede Person? Immer? Aller Auszahlungsdaten? Stephan Kleuker

120 Definition: Verzerrung
Verzerrung ist der Prozess, etwas mittels Überlegungen, Fantasie oder Wünschen, so umzugestalten, dass ein neuer Inhalt oder eine neue Bedeutung entsteht. (Dörrenbacher) Beispiel: Behauptung, dass auf A dann B folgt oder Gedankenlesen Da jemand zu spät ist, ist das Projekt gefährdet Ich denke, der mag mich nicht Er wollte wissen, wie ich mich jetzt fühle Stephan Kleuker

121 Verzerrung: Beispiele und Analyse
Der Nutzer muss zunächst sein Login und dann sein Passwort eingeben. Dem Nutzer muss am Anfang immer die Übersichtsseite gezeigt werden. Der Nutzer muss eingeloggt sein, um die Übersicht zu sehen. Was führt zur Annahme, dass diese Reihenfolgen notwendig sind? Was würde sich bei einer anderen Reihenfolge oder Verlassen einer Einschränkung ändern? Stephan Kleuker

122 Verzerrung durch Nominalisierung
Grundstruktur: Ein Prozesswort (Verb oder Prädikat) wird zu einem Ereigniswort (Substantiv oder Argument) umgeformt. Dadurch wird ein Vorgang zu einem Ereignis und viele vorgangsrelevante Informationen gehen verloren. Es ist möglich, dass sich die Bedeutung der Aussage dadurch ändert. Die Berechtigung für die Administration des Geldautomaten Die Auszahlung wird nach der Buchung durchgeführt Wer? zahlt wann? Wem? Was? Unter Einhaltung welcher Regeln? Mit welcher Zuverlässigkeit? Mit welcher Verfügbarkeit? Wer? bucht wann? Was? Wohin? Unter Einhaltung welcher Regeln? Mit welcher Zuverlässigkeit? Mit welcher Verfügbarkeit? Stephan Kleuker

123 Erkennen von Nominalisierungen
Fragen/Vorgehen: Intuition, Sprachgefühl Suche nach ähnlichem Prozesswort Sprachtest durch Einsetzen in "ein(e) andauernde(r) …". Wahre Substantive passen nicht in diese Aussage Beispiele: Bei der Auswahl der Auszahlungsfunktion soll die … der Anzeige, Benutzerführung, Bestätigung, .... die Eingabe, Erfassung, .... das Ereignis, die Meldung, ... die Buchung, Ausgabe, Prüfung, .... Anmerkung: Nominalisierung wird oft auch als Tilgung angesehen Stephan Kleuker

124 Entwicklung strukturierter Anforderungen
ein Ansatz zu qualitativ hochwertigen Anforderungen: erste Version erstellen und dann Textqualität schrittweise verbessern Alternative: „von Anfang an“ hochwertige Anforderungen zu schreiben Dieser Ansatz kann durch Anforderungsschablonen unterstützt werden, die den Satzbau von Anforderungen vorgeben (vorgestellter Ansatz folgt [RS]) Man beachte, bereits erwähnte Ausdrucksprobleme auch in diesem Ansatz noch relevant Stephan Kleuker

125 Charakterisierung von Systemaktivitäten
Selbständige Systemaktivität: Das System führt den Prozess selbständig durch. Benutzerinteraktion: Das System stellt dem Nutzer die Prozessfunktionalität zur Verfügung. Schnittstellenanforderung: Das System führt einen Prozess in Abhängigkeit von einem Dritten (zum Beispiel einem Fremdsystem) aus, ist an sich passiv und wartet auf ein externes Ereignis. Für jede dieser Systemaktivitäten gibt es eine Schablone. Frage: Werden Systemaktivitäten so in disjunkte Klassen aufgeteilt? Stephan Kleuker

126 Visualisierung der Systemaktivitäten
Stephan Kleuker

127 Anforderungsformulierung (Rupp-Schablone)
<Wann?> <Randbe- dingung> muss soll wird das System - <wem?> die Möglichkeit bieten fähig sein <Objekt mit Randbedin- gung> <Prozess- wort> Typ 1 Typ 3 Typ 2 Typ 1: Selbständige Systemaktivität, System führt Prozess selbständig durch, z. B. Berechnung des bisherigen Aufwandes eines Projekts durch Abfrage aller Teilprojekte und Ergebnisanzeige Typ 2: Benutzerinteraktion, System stellt Nutzer die Prozessfunktionalität zur Verfügung, z: B. Verfügbarkeit eines Eingabefeldes, um den Projektdaten einzugeben Typ 3: Schnittstellenanforderung, d. h. das System führt einen Prozess in Abhängigkeit von einem Dritten (zum Beispiel einem Fremdsystem) aus, ist an sich passiv und wartet auf ein externes Ereignis, z. B. Anfrage einer anderen Bürosoftware nach einer Übersicht über die laufenden Projekte annehmen Stephan Kleuker

128 Typ 1: Selbständige Systemaktivität
<Wann?> <Randbe- dingung> muss soll wird das System - <wem?> die Möglichkeit bieten fähig sein <Objekt mit Randbedin- gung> <Prozess- wort> Typ 1 Typ 3 Typ 2 Nach Abschluss der Eingabe (mit „Return“-Taste oder Bestätigungsknopf) bei der Bearbeitung von Daten muss das System neu eingegebene Daten in seine permanente Datenhaltung übernehmen. [„Daten“ muss konkretisiert werden] Nach der Eingabe eines neuen Teilprojekts oder einer neuen Projektaufgabe und nach der Aktualisierung des Aufwandes eines Teilprojekts oder einer neuen Projektaufgabe muss das System die Aufwandsangaben auf Plausibilität prüfen. Generell ist zu betonen, dass im Laufe des Projekts ein Glossar erstellt wird, das gerade bei der Anforderungsanalyse stark wächst. Stephan Kleuker

129 Typ 2: Benutzerinteraktion
<Wann?> <Randbe- dingung> muss soll wird das System - <wem?> die Möglichkeit bieten fähig sein <Objekt mit Randbedin- gung> <Prozess- wort> Typ 1 Typ 3 Typ 2 In der Projektbearbeitung muss das System dem Nutzer die Möglichkeit bieten, ein neues Projekt mit Projektausgangsdaten anzulegen. In der Projektbearbeitung muss das System dem Nutzer die Möglichkeit bieten, jedes Projekt auszuwählen. Nach der Projektauswahl muss das System dem Nutzer die Möglichkeit bieten, für existierende Projekte neue Teilprojekte anzulegen. Stephan Kleuker

130 Typ 3: Schnittstellenanforderung
<Wann?> <Randbe- dingung> muss soll wird das System - <wem?> die Möglichkeit bieten fähig sein <Objekt mit Randbedin- gung> <Prozess- wort> Typ 1 Typ 3 Typ 2 Nach der Kontaktaufnahme durch die Software „Globalview“ muss das System fähig sein, Anfragen nach den Projektnamen, deren Gesamtaufwänden und Fertigstellungsgraden anzunehmen. (folgt Typ2: Nach der Annahme der Anfrage … ) Stephan Kleuker

131 Vom Aktivitätsdiagramm zur textuellen Anforderung
Jede Aktion wird mit einer Anforderung oder mehreren Anforderungen beschrieben Jede Transition und Entscheidung wird mit einer Anforderung oder mehreren Anforderungen beschrieben Aus dem Ablauf der zur Aktion, Transition oder Entscheidung führt, wird der erste Teil der jeweiligen Anforderung („Wann?“) erzeugt. Hinweis: Anforderungen zum Beispiel stehen im folgenden Kapitel Stephan Kleuker

132 Beispielübersetzung Stephan Kleuker

133 Nicht-funktionale Anforderungen (1/2) [sehr kurz]
4.5 Bisher lag der Schwerpunkt auf funktionalen Anforderungen „was muss das System machen“ SW unterliegt unterschiedlichen nicht-funktionalen Anforderungen, die maßgeblich für den Projekterfolg sein können Hier wird eine Charakterisierung vorgestellt: technische Anforderungen: Hardwareanforderungen, Architekturanforderungen, Anforderungen an die Programmiersprachen Anforderungen an die Benutzungsschnittstelle: Form und Funktion von Ein- und Ausgabe-Geräten Anforderungen an die Dienstqualität: DIN EN ISO unterteilt die Dienstgüte in die fünf Merkmale Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit Stephan Kleuker

134 Nicht-Funktionale Anforderungen (2/2)
Anforderungen an sonstige Lieferbestandteile: Selten besteht das System nur aus einem Stück kompilierten Programmcodes, es werden Zusatzlieferungen, wie Systemhandbücher und Installationshandbücher gefordert Anforderungen an die Durchführung der Entwicklung und Einführung: z. B. Anforderungen an die Vorgehensweise (Software-Erstellung, Software-Prüfung), anzuwendende Standards, Hilfsmittel (Tools), die Durchführung von Besprechungen, von Abnahmetests (fachliche Abnahme, betriebliche Abnahme) und die Festlegung von Terminen rechtlich-vertraglichen Anforderungen: z. B. Angaben zu Zahlungsmeilensteinen, Vertragsstrafen, dem Umgang mit Änderungen der Anforderungen, Eskalationspfade Stephan Kleuker

135 Lastenheft / Pflichtenheft
4.6 Lastenheft wird vom Auftraggeber (Kunden) geschrieben welche Funktionalität ist gewünscht welche Randbedingungen (SW/ HW) gibt es Pflichtenheft wird vom Auftragnehmer (Software-Entwicklung) geschrieben welche Funktionalität wird realisiert auf welcher Hardware läuft das System welche SW-Schnittstellen (Versionen) berücksichtigt Variante: Kunde beauftragt Auftragnehmer direkt in Zusammenarbeit Pflichtenheft zu erstellen ein gemeinsames Heft ist sinnvoll Pflichtenheft ist meist (branchenabhängig) zu bezahlen Stephan Kleuker

136 Lastenheft / Pflichtenheft: möglicher Aufbau
0. Administrative Daten: von wem, wann genehmigt, ... 1. Zielbestimmung und Zielgruppen In welcher Umgebung soll System eingesetzt werden? Ziele des Systems, welche Stakeholder betroffen? 2. Funktionale Anforderungen Produktfunktionen (Use Cases, Aktivitätsd., Anforderungen) Produktschnittstellen (a.GUI-Konzept b. andere SW) 3. Nichtfunktionale Anforderungen Qualitätsanforderungen weitere technische Anforderungen 4. Lieferumfang 5. Abnahmekriterien 6. Anhänge (insbesondere Glossar) Stephan Kleuker

137 5. Grobdesign 5.1 Systemarchitektur
5.2 Ableitung von grundlegenden Klassen 5.3 Ableitung von Methoden und Kontrollklassen 5.4 Validierung mit Sequenzdiagrammen 5.5 Überlegungen zur Oberflächenentwicklung Stephan Kleuker

138 Systemarchitektur 5.1 Festlegen der Randbedingungen bzgl. Hardware, Betriebssystem, verwendeter Software, zu integrierender Systeme Vorgabe der Hardware, die Software muss z. B. auf einer Spezialhardware funktionieren Vorgabe des Betriebssystems, die Software muss eventuell mit anderer Software auf Systemebene zusammenarbeiten Vorgabe der Middleware, die Software wird häufig auf verschiedene Prozesse verteilt, die miteinander kommunizieren müssen Vorgaben zu Schnittstellen und eingesetzten Programmiersprachen, die Software soll mit anderer Software kommunizieren und muss dabei deren Schnittstellen berücksichtigen Vorgaben zum „Persistenzframework“, die Daten der zu erstellenden Software müssen typischerweise langfristig gespeichert werden Stephan Kleuker

139 Beispiel: Projektstrukturplan
5.2 Stephan Kleuker

140 Erste Iteration: Klassen finden
Aktivitätsdiagramme werden durch Anforderungen konkretisiert Text der Anforderungen ist Grundlage zum Finden erster Klassen Im Text werden Objekte identifiziert; sind Individuen, die durch Eigenschaften (Exemplarvariablen) und angebotene Funktionalität charakterisiert werden grober Ansatz: Nomen in Anforderungen und Glossar ansehen; können Objekte oder Eigenschaften sein Adjektive können auf Eigenschaften hindeuten Informationen in Klassen gesammelt; Klassen beschreiben Struktur, die jedes Objekt hat Stephan Kleuker

141 Analyse der Anforderungen (1/5)
A1.1: In der Projektbearbeitung muss das System dem Nutzer die Möglichkeit bieten, ein neues Projekt mit Projektausgangsdaten anzulegen. Glossar Projektausgangsdaten: automatisch vergebene eindeutige Projektnummer, Projektname, geplanter Start- und Endtermin, geplanter Aufwand. gefunden: Klasse Projekt mit Exemplarvariablen Projektnummer, Projektname, geplanter Starttermin, geplanter Endtermin, geplanter Aufwand A1.2: Nach Abschluss der Eingabe (mit „Return“-Taste oder Bestätigungsknopf) bei der Bearbeitung von Daten muss das System neu eingegebene Daten in seine permanente Datenhaltung übernehmen. A1.3: In der Projektbearbeitung muss das System dem Nutzer die Möglichkeit bieten, jedes Projekt auszuwählen. gefunden: keine Klassen oder Exemplarvariablen (Funktionalität später) Stephan Kleuker

142 Analyse der Anforderungen (2/5)
A1.4: Nach der Projektauswahl muss das System dem Nutzer die Möglichkeit bieten, für existierende Projekte neue Teilprojekte anzulegen. gefunden: Exemplarvariable Teilprojekte für Projekt, (eventuell) neue Klasse Teilprojekt A1.5: Bei der Projektdatenbearbeitung muss das System Teilprojekte wie Projekte behandeln und dem Nutzer die gleichen Möglichkeiten zur Bearbeitung bieten. Teilprojekt und Projekt sind für die Software Synonyme, deshalb keine eigene Klasse generell auf Synonyme (verschiedene Wörter mit gleicher Bedeutung) und Homonyme (Wörter mit verschiedenen möglichen Bedeutungen achten) A1.6: Nach der Projektauswahl muss das System dem Nutzer die Möglichkeit bieten, den realen Starttermin, das aktuell kalkulierte Fertigstellungsdatum, den geplanten Aufwand und den Projektkommentar zu bearbeiten. Exemplarvariablen für Projekt: realer Starttermin, aktuelles Fertigstellungsdatum, Kommentar Stephan Kleuker

143 Analyse der Anforderungen (3/5)
A1.7: Nach der Projektauswahl muss das System dem Nutzer die Möglichkeit bieten, neue Teilaufgaben mit dem Aufgabennamen, dem geplanten Start- und Endtermin, dem Arbeitsanteil des Mitarbeiters und dem geplanten Aufwand zu definieren. Glossar Projektaufgabe: Teilaufgabe in einem Projekt, die einen Namen und einen eindeutigen Bearbeiter hat, der zu einem gewissen Prozentsatz der Aufgabe zugeordnet ist, die einen geplanten und realen Aufwand, geplante und reale Start- und Endtermine und einen Fertigstellungsgrad hat und die nicht weiter verfeinert wird. Glossar Fertigstellungsgrad: Für Projektaufgaben geben die jeweiligen Bearbeiter den Fertigstellungsgrad in % an. Die Bearbeiter sind angewiesen, dass bei einer Bearbeitung ohne besondere Probleme dieser Wert möglichst linear wächst. Der Fertigstellungsgrad von Projekten wird aus den Fertigstellungsgraden der Teilprojekte und Aufgaben, gewichtet nach dem geplanten Aufwand berechnet. Stephan Kleuker

144 Analyse der Anforderungen (4/5)
Glossar Aufwand: Für Projektaufgaben gibt der jeweilige Bearbeiter an, wie viele Stunden er bereits mit seiner Aufgabe verbracht hat. Der Aufwand von Projekten berechnet sich aus den Aufwänden der jeweiligen Teilprojekte und Projektaufgaben. gefunden: Exemplarvariable Aufgaben für Projekt neue Klasse Projektaufgabe mit Exemplarvariablen Namen, Bearbeiter, Arbeitsanteil, geplanter Aufwand, realer Aufwand, geplanter und realer Starttermin, geplanter und realer Endtermin, Fertigstellungsgrad Projekt hat auch Exemplarvariablen Fertigstellungsgrad und realer Aufwand, die allerdings vollständig aus anderen Werten berechnet werden können. Man spricht dabei von einer abhängigen Exemplarvariable. Stephan Kleuker

145 Analyse der Anforderungen (5/5)
A1.8: Nach der Projektauswahl muss das System dem Nutzer die Möglichkeit bieten, Projektaufgaben zu selektieren. A1.9: Nach der Projektaufgabenauswahl muss das System dem Nutzer die Möglichkeit bieten, sämtliche Eigenschaften der Projektaufgabe zu bearbeiten. A1.10: Nach der Projektauswahl muss das System dem Nutzer die Möglichkeit bieten, (Teil-)Projekte anzugeben, von deren Fertigstellung das Projekt abhängig ist. gefunden: (in A1.8 und A1.9) nichts, in A1.10 Exemplarvariable Vorgänger für Projekt (weitere Anforderungen nur für zweite Iteration relevant) Stephan Kleuker

146 Erstes Klassendiagramm
Klassenname, Exemplarvariable:Typ Sichtbarkeit (-) kein Zugriff von Außen (+) Zugriff von außen (für Exemplarvariable unerwünscht) Schreibweise Menge() unüblich, / für abgeleitet Stephan Kleuker

147 UML-Notation Assoziationen: Beziehung zwischen Klassen
Rollenname am Ende entspricht Exemplarvariablennamen Multiplizitäten „von..bis“, * für beliebig, alternativ 0..* statt * Stephan Kleuker

148 Zusammenhang Klasse und Objekt
Objekte lassen sich auch in der UML darstellen Kasten mit unterstrichenem „:<Klassenname>“ vor Doppelpunkt kann Objektname stehen Objekte werden nicht im Klassendiagramm dargestellt Stephan Kleuker

149 UML unterstützt iteratives Vorgehen
UML-Teile weggelassen bzw. ausblenden, abhängig von notwendigen bzw. vorhandenen Teilinformationen Je implementierungsnäher desto detaillierter Stephan Kleuker

150 Zweite Iteration: Methoden suchen
5.3 Methoden stehen für Funktionalität, die ein Objekt anbietet; typisch: Zustand (d. h.) Exemplarvariable ändern, Ergebnis basierend auf Exemplarvariablen berechnen Ansatz 1: Analysiere Verben im Text Ansatz 2: Aus Use Cases lässt sich häufig eine Steuerungsklasse (Koordinationsklasse) ableiten folgende Anforderungen an die Klassenformulierung müssen beachtet werden: Klassen übernehmen jeweils eine Aufgabe und besitzen genau die zur Durchführung benötigten Methoden und die für die Methoden benötigten Exemplarvariablen Klassen sollen möglichst wenig andere Klassen kennen, wodurch die Schnittstellenanzahl gering gehalten wird (Hinweis: unser Beispiel ist datenlastig, deshalb wenige Methoden) Stephan Kleuker

151 zweite Analyse der Anforderungen (1/5)
get- und set-Methoden werden gerne im Modell weggelassen, für Exemplarvariable x:Typ in Java public Typ getX() {return x;} public void setX(Typ x){this.x=x;} A1.1: In der Projektbearbeitung muss das System dem Nutzer die Möglichkeit bieten, ein neues Projekt mit Projektausgangsdaten anzulegen. Konstruktoren werden nur genannt, wenn besondere Arten gefordert werden. Wird kein Konstruktor explizit genannt, wird davon ausgegangen, dass ein Default-Konstruktor ohne Parameter zur Verfügung steht. hier: Projekt(String, Datum, Datum, int) A1.2: Nach Abschluss der Eingabe (mit „Return“-Taste oder Bestätigungsknopf) bei der Bearbeitung von Daten muss das System neu eingegebene Daten in seine permanente Datenhaltung übernehmen. Hier steckt nur eine verstecke Anforderung an die Benutzung dahinter, als Funktionalität wird nur set... gefordert. Datenhaltung wird später geklärt. Stephan Kleuker

152 zweite Analyse der Anforderungen (2/5)
A1.3: In der Projektbearbeitung muss das System die Möglichkeit bieten, jedes Projekt auszuwählen. Steuerungsklasse Projektverwaltung Exemplarvariablen: alle Projekte und selektiertes Projekt Projektauswahl ist set-Methode A1.4: Nach der Projektauswahl muss das System dem Nutzer die Möglichkeit bieten, für existierende Projekte neue Teilprojekte anzulegen. Wie bei Mengen von Werten üblich, wird meistens eine add- und eine delete-Methode gefordert. In diesem Fall nur teilprojektHinzufuegen(Projekt): void A1.7: Nach der Projektauswahl muss das System dem Nutzer die Möglichkeit bieten, neue Projektaufgaben mit dem Aufgabennamen, dem geplanten Start- und Endtermin, dem Arbeitsanteil des Mitarbeiters und dem geplanten Aufwand zu definieren. Projekt hat Methode aufgabeHinzufuegen(Projektaufgabe): void Konstruktor Aufgabe(String, Datum, Datum, int, int) Stephan Kleuker

153 zweite Analyse der Anforderungen (3/5)
Glossar Aufwand: ... Der Aufwand von Projekten berechnet sich aus den Aufwänden der jeweiligen Teilprojekte und Projektaufgaben. hier „versteckt“ sich die Funktionalität, dass für Projekte der aktuelle Aufwand berechnet werden soll: realenAufwandBerechnen(): int analog: fertigstellungsgradBerechnen(): double A1.8: Nach der Projektauswahl muss das System dem Nutzer die Möglichkeit bieten, Projektaufgaben zu selektieren. Projekt hat Exemplarvariable selektierteAufgabe [erster Ansatz, wichtig nur vollständiges Modell] A1.10: Nach der Projektauswahl muss das System dem Nutzer die Möglichkeit bieten, (Teil-)Projekte anzugeben, von deren Fertigstellung das Projekt abhängig ist. Projekt hat vorgaengerHinzufuegen(Projekt): void Stephan Kleuker

154 zweite Analyse der Anforderungen (4/5)
A1.11: Nach der Eingabe eines neuen Teilprojekts oder einer neuen Projektaufgabe und nach der Aktualisierung des Aufwandes eines Teilprojekts oder einer neuen Projektaufgabe überprüft das System die Aufwandsangaben auf Plausibilität. folgt, dass Teilprojekt die Möglichkeit haben muss, festzustellen, zu welchem (Teil-)Projekt es gehört. eine Lösung: in angegebener Assoziation, mit der Teilprojekte festgehalten werden, ist diese Information bereits in der Multiplizität 0..1 enthalten, es wird Rollenname zur Veranschaulichung ergänzt. (Ansatz: Durch die Angabe von Rollennamen wird ersichtlich, in welche Richtung Assoziationen navigierbar sein müssen) Projekt: aufwandsaenderungPruefen(neuerAufwand: int): bool Projektaufwand: zugeordneter Aufwand (geplanter Aufwand) minus verteilter Aufwand, also: verteilterAufwand():int Für Projekte auch: aufwandsaenderungPruefen(Projektaufgabe, int): bool Stephan Kleuker

155 zweite Analyse der Anforderungen (5/5)
A1.12: Bei der Überprüfung der Aufwandsangaben auf Plausibilität muss das System prüfen, ob die Summe der geplanten Teilprojekte und Aufgaben eines Projekts kleiner-gleich der geplanten Summe des Projekts ist. beschreibt nur detailliert, wie die vorher gefundene Methode zu realisieren ist A1.13: Nach einer gescheiterten Aufwandsplausibilitätsprüfung muss das System den Nutzer über das Problem informieren und darf den Aufwandswert nicht verändern. Projektverwaltung bekommt die Möglichkeit, auf das gefundene Problem hinzuweisen ( zu GUI-Funktionalität später mehr) inkonsisteneAktualisierungAnzeigen(grund:String):void Stephan Kleuker

156 Klassendiagramm Stephan Kleuker

157 Vererbung Analysemodell wird auf erste Optimierungen geprüft
Wenn Objekte verschiedener Klassen große Gemeinsamkeiten haben, kann Vererbung genutzt werden Variante 1: Abstrakte Klasse mit möglichen Exemplarvariablen, einigen implementierten und mindestens einer nicht-implementierten Methode Variante 2: Interface ausschließlich mit abstrakten Methoden (haben später noch Bedeutung) Vererbung reduziert den Codierungsaufwand Vererbung erschwert Wiederverwendung Liskovsches Prinzip für überschreibende Methoden der erbenden Klassen berücksichtigen: Vorbedingung gleich oder abschwächen Nachbedingungen gleich oder verstärken Stephan Kleuker

158 Beispiel: Vererbung nächster Schritt: Prüfen, wo statt Projekt und Projektaufgabe Projektkomponente stehen kann (Abstrahierung) Stephan Kleuker

159 Aufzählungen Häufiger gibt es Exemplarvariablen, die bestimmte Werte, z. B. {rot,gelb,grün} annehmen können Aufzählungstypen werden in der UML wie rechts gezeigt beschrieben Der Stereotyp <<enumeration>> gibt an, dass es sich um eine Klasse mit bestimmten Eigenschaften handelt Die UML hat einige Stereotypen vorgegeben; weitere können beliebig vereinbart werden. Wie bei allen UML-Sprachelementen gilt, dass man vor dem Modellierungsstart festlegen muss, welches Diagramm und welche Notation wann eingesetzt werden soll Stephan Kleuker

160 Validierung mit Sequenzdiagrammen
5.4 Mit Hilfe des erreichten Modells kann man mit Sequenzdiagrammen validieren, ob die im Aktivitätsdiagramm beschriebenen Abläufe möglich sind rechte Seite zeigt verschiedene Darstellungsmöglichkeiten eines Methodenaufrufs Rückgabewerte werden häufig weggelassen, wenn nur Ablauf wichtig (Stellen auch Testfälle dar) Stephan Kleuker

161 Zusammenhang: Programm und Sequenzdiagramm
extern :A b:B public class A { private B b= new B(); private C c; public char mach(int x){ int t= b.tues(x); c= new C(t,t+1); return b.yeah(c); } public class B { public int tues(int x){ return x%255; public char yeah(C c){ char e=c.sachA(); return (char) (e+1); mach(42) tues(42) 42 new C(42,43) c:C yeah(c) sach(A) 'U' 'V' 'V' Stephan Kleuker

162 Iterative Entwicklung und Validierung
Beispielablauf Ableitung von Methodennamen Zeichnen eines kleinen Sequenzdiagramms mit dieser Methode; feststellen, ob weitere Methoden benötigt Ergänzung von Methodenparametern Ergänzung des Sequenzdiagramms um Parameter; feststellen, ob weitere Methoden benötigt Falls kein Sequenzdiagramm herleitbar, auf Ursachenforschung gehen (Modellfehler?) Optimales Ziel: Mögliche Durchläufe durch Aktivitätsdiagramme werden abgedeckt Stephan Kleuker

163 Zusammenhang zwischen Aktivitäts- und Sequenzdiagrammen
Stephan Kleuker

164 Iterative Entwicklung eines Sequenzdiagramms
b:B l:Set tues() generell: zunächst unterspezifiziert, dann Parameter verfeinern abstrakter Ablauf (x) oder konkreter Beispielablauf (mit Werten) Ergänzung interner Berechnungen, z. B. in A z= this.oh(); interne Collections meist nicht dargestellt Darstellung aber möglich, in B: public void hinzu(C c){ l.add(c); } tues(x) tues(42) z=oh() hinzu(c) hinzu(c) add(c) Stephan Kleuker

165 Sequenzdiagramm und Kommunikationsdiagramm
gleiches Ausdrucksvermögen wie einfache Sequenzdiagramme Zusammenspiel der Objekte wird deutlicher interne Berechnung 2.1, 2.2 (ggfls , ) Stephan Kleuker

166 Highlevel-Sequenzdiagramme
Stephan Kleuker

167 Beispiel: Initialisierung
Anmerkung: Typischerweise „befruchten“ sich die Entwicklung von Klassendiagrammen und Sequenzdiagrammmen (Optimierung in einem iterativen Prozess) Stephan Kleuker

168 Beispiel: Anstoß der Funktionalität
häufig werden Teilsysteme spezifiziert, deren Nutzung von außen angestoßen wird dann im Sequenzdiagramm „außen“ als „Extern“ modellieren Stephan Kleuker

169 Beispiel: Fertigstellungsgrad berechnen
Stephan Kleuker

170 Beispiel: Prüfung Projektaufwand aktualisierbar (1/2)
Stephan Kleuker

171 Beispiel: Prüfung Projektaufwand aktualisierbar (2/2)
Stephan Kleuker

172 Beispiel: Projektaufgabenaufwand aktualisierbar?
Stephan Kleuker

173 GUI-Prototyp gut mit Kunden dieskutierbar
GUI-Modellierung 5.5 fachlich hängt Oberfläche (GUI, Graphical User Interface) eng mit unterliegendem Geschäftsklassenmodell (bisher behandelt) zusammen möglicher Ansatz: „Mache alle Modellanteile an der Oberfläche sichtbar, die ein Nutzer än-dern oder für dessen Inhalte er sich interessieren kann.“ Variante: mache ersten GUI-Prototyp und halte bei Ein- und Ausgaben fest, welche Modellinformationen sichtbar sein sollen GUI-Prototyp gut mit Kunden dieskutierbar Hinweis: Thema Softwareergonomie später Stephan Kleuker

174 Erweiterung mit Boundary-Klassen
Stephan Kleuker

175 Sequenzdiagramm mit Nutzungsdialog
Stephan Kleuker

176 Anforderungsverfolgung
Typische Fragen: Werden alle Anforderungen umgesetzt? Wo werden Anforderungen umgesetzt? Gibt es Spezifikationsanteile, die nicht aus Anforderungen abgeleitet sind? Woher kommt eine Klasse, eine Methode, ein Parameter? Was passiert, wenn ich eine Anforderung oder eine Klasse ändere? Generell werden die Fragen wesentlich komplexer zu beantworten, wenn Software später umgebaut oder erweitert wird Stephan Kleuker

177 Anforderungsverfolgung - Beispielzusammenhänge
Stephan Kleuker

178 6. Vom Klassendiagramm zum Programm
6.1 CASE-Werkzeuge 6.2 Übersetzung einzelner Klassen 6.3 Übersetzung von Assoziationen 6.4 Spezielle Arten der Objektzugehörigkeit 6.5 Aufbau einer Software-Architektur 6.6 Weitere Schritte zum lauffähigen Programm Stephan Kleuker

179 Analyse des Ist-Standes
bekannter Weg: Kundenwünsche, Anforderungsformulierung, Analyse-Modell Analysemodell kann realisiert werden, aber: Klassen kaum für Wiederverwendung geeignet Programme meist nur aufwändig erweiterbar viele unterschiedliche Lösungen zu gleichartigen Problemen deshalb: fortgeschrittene Designtechniken studieren aber: um fortgeschrittenes Design zu verstehen, muss man die Umsetzung von Klassendiagrammen in Programme kennen (dieses Kapitel) aber: um fortgeschrittenes Design zu verstehen, muss man einige OO-Programme geschrieben haben Stephan Kleuker

180 UML-Toolsuiten / CASE-Werkzeuge
6.1 Theorie: UML-Werkzeuge unterstützen die automatische Umsetzung von Klassendiagrammen in Programmgerüste (Skelette) Entwickler müssen die Gerüste mit Code füllen viele Werkzeuge unterstützen Roundtrip-Engineering, d.h. Änderungen im Code werden auch zurück in das Designmodell übernommen (wenn man Randbedingungen beachtet) Roundtrip beinhaltet auch Reverse-Engineering Praxis: sehr gute kommerzielle Werkzeuge (z. B. IBM Rational, Borland Together); allerdings muss man für Effizienz Suite von Werkzeugen nutzen; d. h. auf deren Entwicklungsweg einlassen ordentliche nicht kommerzielle Ansätze für Teilgebiete; allerdings Verknüpfung von Werkzeugen wird aufwändig Stephan Kleuker

181 Übersetzung einfacher Diagramme (1/3)
6.2 Anmerkung: auch bei Realisierung kann vereinbart werden, dass get- und set-Methoden in Übersichten weggelassen (und damit als gegeben angenommen) werden Klassenmethoden sind unterstrichen Stephan Kleuker

182 Übersetzung einfacher Diagramme (2/3)
public class Mitarbeiter { /** name="minr" */ private int minr; * Getter of the property <tt>minr</tt> Returns the minr. public int getMinr() { return minr; } * Setter of the property <tt>minr</tt> minr The minr to set. public void setMinr(int minr) { this.minr = minr; Stephan Kleuker

183 Übersetzung einfacher Diagramme (3/3)
private String vorname = ""; public String getVorname() { return vorname;} public void setVorname(String vorname) { this.vorname = vorname; } private String nachname = ""; public String getNachname() {return nachname;} public void setNachname(String nachname) { this.nachname = nachname; private static int mitarbeiterzaehler; public static int getMitarbeiterzaehler() { return mitarbeiterzaehler; public static void setMitarbeiterzaehler (int mitarbeiterzaehler) { Mitarbeiter.mitarbeiterzaehler = mitarbeiterzaehler; = evtl. notwendige Korrekturen, bei CASE-Werkzeug Stephan Kleuker

184 Notwendige Code-Ergänzung durch Entwickler
public Mitarbeiter(String vorname, String nachname){ this.vorname=vorname; this.nachname=nachname; this.minr=Mitarbeiter.mitarbeiterzaehler++; } @Override public String toString() { return minr+": "+vorname+" "+nachname; = vom Entwickler ergänzt Stephan Kleuker

185 Umgang mit Assoziationen im Design
6.3 Assoziationen zunächst nur Strich mit Namen (und Multiplizitäten) für Implementierung jede Assoziation konkretisieren (Richtung der Navigierbarkeit, Multiplizitäten sind Pflicht) public class Projektaufgabe { /** werkzeugspezifische Kommentare weggelassen */ private Mitarbeiter bearbeiter; public Mitarbeiter getBearbeiter() { return bearbeiter; } public void setBearbeiter(Mitarbeiter bearbeiter) { this.bearbeiter = bearbeiter; Stephan Kleuker

186 Objekreferenz darf nie null sein
Multiplizität 1 Objekreferenz darf nie null sein private Mitarbeiter bearbeiter = new Mitarbeiter(); oder im Konstruktor setzen man sieht, default-Konstruktoren sind auch hier hilfreich; deshalb, wenn irgendwie möglich definieren Gleiche Problematik mit der Werte-Existenz, bei Multiplizität 1..n Stephan Kleuker

187 Multiplizität n (1/2) Umsetzung als Collection (Sammlung, Container)
Umsetzung hängt von Art der Collection ab sollen Daten geordnet sein sind doppelte erlaubt gibt es spezielle Zuordnung key -> value Entwickler muss zur Typwahl spätere Nutzung kennen eine Umsetzung für 1..* import java.util.List; import java.util.ArrayList; public class Projektaufgabe { private List<Mitarbeiter> bearbeiter = new ArrayList<Mitarbeiter>(); bitte, bitte in Java nicht alles mit ArrayList realisieren (!!!) Multiplizität 0..7 als Array umsetzbar Stephan Kleuker

188 Multiplizität n (2/2) Zum Codefragment der letzten Zeile passt besser folgendes Klassendiagramm Hinweis: Standardhilfsklassen z. B. aus der Java-Klassenbibliothek oder der C++-STL werden typischerweise in Klassendiagrammen nicht aufgeführt Anmerkung: man sieht die UML-Notation für generische (oder parametrisierte) Klassen UML-Werkzeuge unterscheiden sich bei der Generierung und beim Reverse-Engineering beim Umgang mit Collections * Stephan Kleuker

189 Arten der Zugehörigkeit (Aggregation 1/2)
6.4 nicht exklusiver Teil eines Objekts (Mitarbeiter kann bei mehreren Projektaufgaben Bearbeiter sein) in C++: Mitarbeiter *bearbeiter; Mitarbeiter* Projektaufgabe::getBearbeiter(){ return bearbeiter;} oder Mitarbeiter bearbeiter; Mitarbeiter& Projektaufgabe::getBearbeiter(){ Realisierungsproblem: Projektaufgabe kann Namen des Bearbeiters ändern bearbeiter->setNachname("Meier"); Kann als Verstoß gegen Kapselung (Geheimnisprinzip) angesehen werden Designansatz: Klasse erhält Interface, die Methoden enthält, die bestimmte andere Klassen nutzen können Stephan Kleuker

190 Arten der Zugehörigkeit (Aggregation 2/2)
Designansatz: Verhindern unerwünschten Zugriffs durch Interface (generell gute Idee !) Kurzdarstellung Interfacerealisierer: Stephan Kleuker

191 Arten der Zugehörigkeit (Komposition 1/2)
Konkretisierung der Zugehörigkeit: existenzabhängiges Teil, Exemplarvariable gehört ausschließlich zum Objekt (Mitarbeiter kann [unrealistisch] nur exakt eine Projektaufgabe bearbeiten; niemand anderes nutzt dieses Objekt) Realisierung in C++ Mitarbeiter bearbeiter; Mitarbeiter Projektaufgabe::getBearbeiter (){ return bearbeiter; } Bei Rückgabe wird Kopie des Objekts erstellt und zurück gegeben Stephan Kleuker

192 Arten der Zugehörigkeit (Komposition 2/2)
Java arbeitet nur mit Zeigern (unschöne Ausnahme sind Elementartypen), wie realisiert man @Override // in Mitarbeiter.java public Mitarbeiter clone(){ // echte Kopie Mitarbeiter ergebnis= new Mitarbeiter(); ergebnis.minr=minr; ergebnis.nachname=nachname; //Strings sind ergebnis.vorname=vorname; //Konstanten return ergebnis; } // in Projektaufgabe public Mitarbeiter getBearbeiter() { return bearbeiter.clone(); Variante: bei Realisierung überall doll aufpassen Stephan Kleuker

193 Kurzzeitige Klassennutzungen
Klassen nutzen andere Klassen nicht nur für Exemplar- (und Klassen-) Variablen Klassen erzeugen Objekte anderer Klassen lokal in Methoden, um diese weiter zu reichen public class Projektverwaltung { private Projekt selektiertesProjekt; public void projektaufgabeErgaenzen(String name){ Projektaufgabe pa= new Projektaufgabe(name); selektiertesProjekt.aufgabeHinzufuegen(pa); } Klassen nutzen Klassenmethoden anderer Klassen In der UML gibt es hierfür den „Nutzt“-Pfeil (Omondo: <<include>>) Wenn zu viele Pfeile im Diagramm, dann mehrere Diagramme mit gleichen Klassen zu unterschiedlichen Themen UML-Werkzeuge unterstützen Analyse von Abhängigkeiten Stephan Kleuker

194 Erstellen einer Softwarearchitektur
6.5 Ziel des Design ist ein Modell, welches das Analysemodell vollständig unter Berücksichtigung implementierungsspezifischer Randbedingungen umsetzt allgemeine Randbedingungen: Es gibt ingenieurmäßige Erfahrungen zum gutem Aufbau eines Klassensystems; dieses wird auch SW-Architektur genannt Ziele für die Architektur Performance Wartbarkeit Erweiterbarkeit Verständlichkeit schnell realisierbar Minimierung von Risiken Stephan Kleuker

195 Systematische Entwicklung komplexer Systeme
Für große Systeme entstehen viele Klassen; bei guten Entwurf: Klassen die eng zusammenhängen (gemeinsame Aufgabengebiete) Klassen, die nicht oder nur schwach zusammenhängen (Verknüpfung von Aufgabengebieten) Strukturierung durch SW-Pakete; Pakete können wieder Pakete enthalten Stephan Kleuker

196 Typische 3-Schichten-SW-Architektur
Ziel: Klassen eines oberen Pakets greifen nur auf Klassen eines unteren Paketes zu (UML-“nutzt“-Pfeil) Änderungen der oberen Schicht beeinflussen untere Schichten nicht Analysemodell liefert typischerweise nur Fachklassen Datenhaltung steht für Persistenz typisch Varianten von 2 bis 5 Schichten Klassen in Schicht sollten gleichen Abstraktionsgrad haben Schicht in englisch „tier“ obere und untere Schichten können stark von speziellen Anforderungen abhängen (später) Stephan Kleuker

197 Beispiel: grobe Paketierung (eine Variante)
Anmerkung: Datenverwaltung noch nicht konzipiert Stephan Kleuker

198 Beispiel: grobe Paketierung (zweite Variante)
Stephan Kleuker

199 Forderung: azyklische Abhängigkeitsstruktur
Stephan Kleuker

200 Umsetzung von Paketen in Java und C++
package fachklassen.projektdaten; import fachklassen.projektmitarbeiter.Mitarbeiter; public class Projektaufgabe { private Mitarbeiter bearbeiter; /* ... */ } #include "Mitarbeiter.h" //evtl. mit Dateibaum using namespace Fachklassen::Mitarbeiterdaten; namespace Fachklassen{ namespace Projektdaten{ class Projektaufgabe{ private: Mitarbeiter *bearbeiter; // ... }; Stephan Kleuker

201 Paketabhängigkeiten optimieren
Ziel ist es, dass Klassen sehr eng zusammenhängen; es weniger Klassen gibt, die eng zusammenhängen und viele Klassen und Pakete, die nur lose gekoppelt sind Möglichst bidirektionale oder zyklische Abhängigkeiten vermeiden Bei Paketen können Zyklen teilweise durch die Verschiebung von Klassen aufgelöst werden Wenig globale Pakete (sinnvoll für projektspezifische Typen (z. B. Enumerations) und Ausnahmen) Es gibt viele Designansätze, Abhängigkeiten zu verringern bzw. ihre Richtung zu ändern Stephan Kleuker

202 Trick: Abhängigkeit umdrehen
generell können Interfaces häufiger in anderen Paketen liegen, als ihre Implementierer Java-Klassenbibliothek Swing fordert häufig die Interface-Implementierung bei der Ereignisbehandlung Stephan Kleuker

203 Architektursichten 6.6 Paket- und Klassendiagramme geben einen guten Überblick über die Ergebnisse des statischen SW-Entwurfs Es gibt aber mehr Sichten (Betrachtungsweisen), die für eine vollständige SW-Architektur relevant sind z. B. wurde die HW des zu entwickelnden Systems noch nicht berücksichtigt Diese Sichten müssen zu einem System führen; deshalb müssen sich Sichten überlappen z. B. eigenes Diagramm mit Übersicht über eingesetzte Hardware und Vernetzung; dazu Information, welche SW wo laufen soll Stephan Kleuker

204 4+1 Sichten Logische Sicht funktionale Ana- lyseergebnisse
Klassenmodell Implementierungs- sicht Subsysteme Schnittstellen Szenarien Ablaufsicht - Prozesse - Nebenläufigkeit - Synchronisation Physische Sicht Zielhardware Netzwerke Stephan Kleuker

205 4+1 Sichten mit (Teilen der) UML
Logische Sicht Klassendiagramme Paketdiagramme Implementierungs- sicht Komponenten- diagramme Szenarien Use Case-Diagramme Aktivitätsdiagramme Ablaufsicht Sequenzdiagramme Kommunikations- diagramme Zustandsdiagramme Physische Sicht Deployment- diagramme Stephan Kleuker

206 AktiveKlasse aktivesObjekt: AktiveKlasse
Ablaufsicht wichtig für verteilte Systeme; bzw. Systeme, die verteilt (auch auf einem Rechner) laufen Festlegen der Prozesse Festlegen etwaiger Threads so genannte aktive Klassen; werden Objekte dieser Klassen gestartet, so starten sie als eigenständige Prozesse/Threads Prozessverhalten u. a. durch Sequenzdiagramme beschreibbar (übernächste VL etwas mehr; gibt eigenes Modul dazu) AktiveKlasse aktivesObjekt: AktiveKlasse Stephan Kleuker

207 Implementierungssicht
Das Designmodell muss physikalisch realisiert werden; es muss eine (ausführbare) Datei entstehen Pakete fassen als Komponenten realisiert Klassen zusammen häufig werden weitere Dateien benötigt: Bilder, Skripte zur Anbindung weiterer Software, Installationsdateien Komponenten sind austauschbare Bausteine eines Systems mit Schnittstellen für andere Komponenten Typisch ist, dass eine Komponente die Übersetzung einer Datei ist Typisch ist, dass eine Komponente die Übersetzung eines Pakets ist; in Java .jar-Datei Stephan Kleuker

208 Komponentendiagramm Bilder zeigen zwei alternative Darstellungen
Komponenten bieten Schnittstellen(realisierungen) (Kreis) und benötigen Schnittstellen(realisierungen) (Halbkreis) Komponenten können über Schnittstellen in Diagrammen verknüpft werden in die Komponenten können die zugehörigen Klassen eingezeichnet werden Ports erlauben den Zugriff auf bestimmten Teil der Klassen und Interfaces (nicht im Diagramm) Stephan Kleuker

209 Physische Sicht: vorgegebene HW mit Vernetzung
Einsatz- und Verteilungsdiagramm (deployment diagram) Knoten steht für physisch vorhandene Einheit, die über Rechenleistung oder/und Speicher verfügt <<executable>> (ausführbare Datei) und <<artifact>> (Datei) müssen zur HW-Beschreibung nicht angegeben werden Stephan Kleuker

210 7. Konkretisierungen im Feindesign
7.1 Zustandsdiagramme 7.2 Object Constraint Language Stephan Kleuker

211 Verfeinerte Modellierung
Durch die verschiedenen Sichten der Systemarchitektur wird der Weg vom Anforderungsmodell zur Implementierung beschrieben Es bleiben offene Themen: Wie bekomme ich ein gutes Klassendesign (nächstes Kapitel)? Wie kann man das komplexe Verhalten von Objekten noch beschreiben (Klassendiagramme sind statisch, Sequenzdiagramme exemplarisch)? Antwort: Zustandsdiagramme Wie kann man bei der Klassenmodellierung Randbedingungen formulieren, was in Klassendiagrammen (Bedingungen in geschweiften Klammern) nur bedingt möglich ist? Antwort: Object Constraint Language Stephan Kleuker

212 Zustandsdiagramme 7.1 generell wird der Zustand eines Objekts durch die Werte seiner Exemplar- und Klassenvariablen beschrieben Häufig wird der Begriff Zustand auch für eine spezielle Exemplarvariable genutzt, die z. B. über eine Enumeration realisierbar ist z. B. : Ampel: rot, rotgelb, gelb, grün z. B. : Projekt: vorbereitet, grob geplant, Mitarbeiter zugeordnet, verschoben, in Bearbeitung, in Endabnahme, in Gewährleistung, beendet Die Übergänge zwischen den Zuständen werden durch Ereignisse, zumeist Methodenaufrufe, veranlasst Die Übergänge lassen sich durch ein Zustandsdiagramm (ursprünglich Statechart nach D. Harel) spezifizieren Zustandsautomaten spielen auch in der theoretischen und technischen Informatik eine zentrale Rolle Stephan Kleuker

213 Struktur von Zustandsdiagrammen
Zustandsdiagramm gehört zu einem Objekt einer Klasse alle Angaben für Zustände und Transitionen sind Optional Transition wird ausgeführt, wenn Ereignis eintritt und Bedingung erfüllt ist ohne Ereignis und Bedingung wird Transition dann ausgeführt, wenn Entry, Do, und Exit durchlaufen Einfacher Automat muss deterministisch sein Stephan Kleuker

214 Beispiel: Zustandsdiagramm eines Projekts
man erkennt: nach Planung keine Planungsänderung Stephan Kleuker

215 Hierarchische Zustände
Stephan Kleuker

216 Parallele Unterzustände
unabhängige Teilzustände können in parallelen Zuständen bearbeitet werden ohne Parallelität müsste Kreuzprodukt der Zustände der parallelen Automaten betrachtet werden Stephan Kleuker

217 Beispiel: Uhr Stephan Kleuker

218 Zustandsmodellierung und Realzeitsysteme
in klassischen OO-Programmen gibt es meist wenige zentrale Klassen, für die sich eine Zustandsmodellierung anbietet In Systemen mit Zeit kann Zustandsmodellierung Zeitbedingungen beinhalten auch warte(5 sek) Stephan Kleuker

219 Event [Condition] / Action
Transitionsbeschriftung Ereignis[Bedingung]/Aktion Was ist Ereignis? Hängt von Applikation ab Methodenaufruf Ereignis im Programm (Variable wechselt Wert) technische Systeme: Signale typisches Beispiel: Steuersysteme erhalten Signale (->Ereignisse) von Sensoren wenn etwas passiert (z. B. ein-/ausgeschaltet) lesen Werte anderer Sensoren, Teilsysteme (-> Bedingung), die Entscheidungen beeinflussen senden Signale (-> Aktion) an andere Systeme Stephan Kleuker

220 Microsteps und Macrosteps (1/2)
Actions eines Teilautomaten können Events eines anderen Teilautomaten sein Microstep: einzelne Schritte betrachten Start -> K(A1,B1) –p-> K(A2,B1) –x-> K(A2,B2) –q-> K(A3,B2) –y-> K(A3,B3) –z-> K(A3,B1) –r-> K(A1,B1) Stephan Kleuker

221 Microsteps und Macrosteps (2/2)
Macrostep: nur Zustände nach vollständiger Bearbeitung betrachten (Ausnahme: Livelock) Start -> K(A1/B1) –p-> K(A3/B3) –z-> K(A1/B1) typischerweise nur an Macrosteps interessiert Stephan Kleuker

222 Beispiel: Start-Stopp-Automatik (1/3)
zentrale Aufgabe: Start-Stopp-Automatik stellt den Motor immer dann selbstständig aus, wenn dieser nicht mehr benötigt wird (z. B. Halt an Ampel) Randbedingung: keine Abschaltung bis maximal 3 Grad und ab minimal 30 Grad Ablauf: Zündschlüssel einstecken, Motorstartknopf drücken, dann startet Automatik Motorein- und Abschaltung wird anhand der Kupplung erkannt Automatik kann auch wieder gestoppt werden [Frage: was fehlt alles zur Realität] Stephan Kleuker

223 Beispiel: Start-Stopp-Automatik (2/3)
Klärung, von welche Sensoren werden Signale empfangen: Zündschloss: start und ende Kupplung: leerlauf und druecken Automatiksteuerung: an und aus Klärung, welchen Sensoren können abgefragt werden: Temperaturwert temp in lokaler Variablen Klärung an welche Sensoren Signale geschickt werden Motorsteuerung: motor_an und motor_aus Stephan Kleuker

224 Beispiel: Start-Stopp-Automatik (3/3)
Stephan Kleuker

225 GUI als Zustandsdiagramm
Stephan Kleuker

226 Android als Zustandsdiagramm
Stephan Kleuker

227 Umsetzung von Zustandsdiagrammem
Abhängig davon, wie formal die Zustände und Transitionen spezifiziert sind, kann aus Zustandsdiagrammen Programmcode erzeugt werden Typisch: Iteratives Vorgehen: informelle Beschreibungen werden schrittweise durch formalere ersetzt Ereignisse können für folgendes stehen Methodenaufrufe externe Ereignisse des GUI (-> Methodenaufruf) Teilsituation, die bei der Abarbeitung einer Methode auftreten kann Automat wird zunächst zu komplexer Methode, die z. B. anhand der Zustände in Teilmethoden refaktoriert werden kann Stephan Kleuker

228 Klassendiagramm und versteckte Randbedingungen
7.2 Welche Randbedingungen vermuten Sie? Stephan Kleuker

229 Grundidee von Object Constraint Language (OCL)
Rahmenbedingungen (Constraints) definieren, die von Objekten bzw. Objektmengen eingehalten werden können Constraints sind prüfbar möglichst einfach formulierbar (ursprünglich zur Formulierung von Geschäftsregeln für Versicherungsanwendungen, [Syntropy, IBM]) Angepasst an Objektorientierung: Zugriff auf Exemplarvariablen Zugriff auf Methoden, die keine Objektveränderungen vornehmen Vererbung wird beachtet typisiert, Collections wichtiger Typ Stephan Kleuker

230 Einfache Bedingungen für Objekte (Invarianten)
Die Matrikelnummer ist mindestens 10000 context Studi inv hoheMatrikelnummern: self.matnr>=10000 eine Variante: context s:Studi inv: s.matnr>=10000 context gibt eindeutig an, um welche Klasse es geht Strukturierung durch Nutzung der Paketstruktur package com::meineFirma::meineSW context Studi inv: ... endpackage Stephan Kleuker

231 Vor- und Nachbedingungen für Methoden
Wenn Studi da, dann hört er Veranstaltungen context Studi::belegteVeranstaltungen():Integer pre studiIstDa: self.freisemester=false post hoertVeranstaltungen: result>0 Man kann auf Parameter der Methoden zugreifen result ist vordefiniert (vom Rückgabetyp) Erhöhung der Anzahl der belegten Veranstaltungen: context Studi::veranstaltungEintragen(v: Veranstaltung) pre: nichtBelegt(v) post: self.belegteVeranstaltungen()-1 für Ergebnis vor der Methodenausführung Stephan Kleuker

232 Einschub: Basistypen und Operationen
Jeder OCL-Ausdruck hat einen Typ Verknüpfe Ausdrücke müssen vom Typ her passen Geringe Typanpassungen möglich Typ Beispielwerte Boolean true, false Integer 1, -5, 42, Real 3.14, 42.42, String 'Hallo Again', 'Heidi', '' Typ Beispieloperationen Boolean and,or,xor,not,implies,if then else endif Integer *, +, -, /, abs() Real *, +, -, /, floor() String concat(), size(), substring() Stephan Kleuker

233 Zugriff auf Assoziationen
Zugriff auf verbundene Elemente möglich, Kardinalitäten beachten (einfach oder Menge) wenn Relation benannt, dann dieser Name sonst über Name der verbundenen Klasse (klein) Profs laufender Veranstaltungen sind nicht im Ausland context Veranstaltung inv: self.status = Veranstaltungsstatus::laeuft implies not self.prof.imAusland Man sieht auch Zugriff auf eine Enumeration Stephan Kleuker

234 Prüfungsnoten nur für abgeschlossene Veranstaltungen
Assoziationsklassen Ausgehend von Assoziationsklassen kann mit Punktnotation auf beteiligte Klassen (deren Objekte) mit deren Rollennamen zugegriffen werden Prüfungsnoten nur für abgeschlossene Veranstaltungen context Pruefung inv: self.studienfach.status = Veranstaltungsstatus::abgeschlossen implies (self.note>=1.0 and self.note<=5.0) Stephan Kleuker

235 Beispiele: Mengenoperationen (1/2)
bei der Betrachtung zugehöriger Objekte ist das Ergebnis meist eine Collection von Objekten in OCL auch: Set, OrderedSet, Sequence, Bag auf Collections existieren verschiedene Methoden, genereller Aufruf collection -> methode(<parameter>) Ergebnis kann wieder eine Collection oder ein Wert eines anderen Typs sein Studi macht höchstens 12 Veranstaltungen context Studi inv: studi.studienfach -> select (s | s.status = Veranstaltungsstatus::laeuft) -> size() <= 12 Stephan Kleuker

236 Beispiele: Mengenoperationen (2/2)
Korrektheit von hatTheorieBestanden context Studi::hatTheorieBestanden():Boolean post: result = self.pruefung -> exists( p | p.note<=4.0 and p.studienfach.titel='Theorie')) Korrektheit für bestandeneVeranstaltungen context Studi:: bestandeneVeranstaltungen():Collection post: result=self.pruefung ->select( p | p.note<=4.0) ->iterate(p:Pruefung; erg:Collection=Collection{}| erg->including(p.studienfach)) Stephan Kleuker

237 8. Optimierung des Designmodells
8.1 Design im Kleinen 8.2 Model View Controller 8.3 Vorstellung einiger GoF-Pattern 8.4 Abschlussbemerkungen zu Pattern Stephan Kleuker

238 Zentrale Aufgabe: von Analyse zum Design (1/2)
Analyse der Klassen: haben sie klar definierte Aufgabe können Klassen vereinigt werden sollten Klassen aufgeteilt werden welche Optimierungen sind aus Design-Sicht möglich? (zentrale Frage, untersuchen wir weiter) Exemplar- und Klassenvariablen müssen Typen haben Variablen und Methoden brauchen Sichtbarkeiten Methoden brauchen Rückgabe- und Parametertypen (Signaturen); in Java und C++ spielen Ausnahmen eine Rolle Stephan Kleuker

239 Zentrale Aufgabe: von Analyse zum Design (2/2)
für Assoziationen Multiplizitäten beachten über mögliche Richtungen nachdenken Art der Zugehörigkeit klären GUI-Klassen und persistente Datenhaltung einbauen Anmerkung 1: Übergang von Analyse zu Design ist durch Iterationen (Verfeinerungen) fließend Anmerkung 2: Die vorgestellten Regeln sind häufig Regeln (in 90% müssen sie angewandt werden, bei Verstößen muss man argumentieren können, warum) Stephan Kleuker

240 Einfache Basisregeln 8.1 KISS = Keep It Simple Stupid, man soll die einfachst mögliche Realisierung wählen, die das Problem vollständig löst und gut nachvollziehbar ist (kein „Quick and Dirty“, sondern eine klare Entscheidung für einen einfachen Entwicklungsstil) YAGNI = You Ain’t Gonna Need It, keine Verallgemeinerungen entwickeln, die das Design für theoretisch in der Zukunft vielleicht gewünschte Erweiterungen vereinfachen Stephan Kleuker

241 Keine allwissenden Klassen
ändere Fertigstellungsgrad einer Projektaufgabe besser: Stephan Kleuker

242 Korrekte Methodenplatzierung
Objekte sollen genau die Aufgaben übernehmen, für die sie Kenntnisse haben falscher Ansatz: allwissende Objekte saugen alles Wissen aus Exemplarvariablen und verarbeiten es Beispiel: Klasse Dominostein mit Exemplarvariablen links und rechts (Steine können nicht gedreht werden) Klasse Spiel mit Exemplarvariable mitte, einem Stein, an dem angelegt werden soll Spiel benötigt Methode, die für einen zweiten Stein prüft, ob dieser angelegt werden kann schlecht: bool Spiel::ablegbar(Dominostein d){ return d.getLinks()==mitte.getRechts || d.getRechts()==mitte.getLinks(); } gut: bool Dominostein::anlegbar(Dominostein d){ return links==d.rechts || rechts==d.links; } // in Spiel dann mit mitte.anlegbar(d) prüfen Stephan Kleuker

243 „Verpacken“ von Exemplarvariablen (Aggregation)
Generell kann man für Exemplarvariablen vom Typ X statt einer get-Methode alle Methoden von X anbieten, die man an die Exemplarvariable weiterleiten will. Ansatz auch für Collections geeignet XNutzer: Aufrufe an x weiterleiten (Methoden müssen nicht gleich heißen) public int getA(){ return x.getA(); } public void setA(int a){ x.setA(a); Stephan Kleuker

244 Erinnerung: Bedeutung von Schnittstellen
Schnittstellen sind zentrales Element des Design by Contract vorgegebene Aufgabe: Implementiere mir folgende Funktionalität ... beschrieben durch Vorbedingung Signatur <Sichtbarkeit> <Methodenname>(<Parameter>)... Nachbedingung Entwickler realisiert OO-Programm (Details sind frei) Entwickler garantiert, dass Schnittstelle (oder Fassade) gewünschte Funktionalität liefert generell sollte man bei Vererbungen und Implementierungen die am wenigsten spezielle benötigte Klasse nutzen; deshalb List<Projektaufgaben> aufgaben und nicht ArrayList<Projektaufgaben> aufgaben im Code Stephan Kleuker

245 Design by Contract Stephan Kleuker

246 woher kommen Objekte für Exemplarvariablen?
Dependency Injection woher kommen Objekte für Exemplarvariablen? Variante 1: Werte werden als Parameter übergeben, aus denen Objekte gebaut werden Variante 2: Objekte werden als Referenzen übergeben Optimierung: Typen der Objektvariablen sind Interfaces; so konkrete Objekte leicht austauschbar Variante 2 heißt Dependency Injection mit get- und set-Methoden oder über Konstruktoren Stephan Kleuker

247 Dependency Injection - Beispiel
Inter1 inter1 = new Inter1RealA(42); Inter2 inter2 = new Inter2RealC(43); Inter3 inter3 = new Inter3RealD("Hallo"); Nutzer nutzer = new Nutzer(inter1, inter2, inter3); Stephan Kleuker

248 Erinnerung: Bedeutung von Polymorphie (1/2)
Stephan Kleuker

249 Erinnerung: Bedeutung von Polymorphie (2/2)
8Rechteck: 273 5Kreis: 8Rechteck: 56 5Kreis: 6RahmenI8RechteckS0_E: 217 6RahmenI8Rechteck5KreisE: 6RahmenI5Kreis8RechteckE: 6RahmenI5KreisS0_E: #include <iostream> #include <typeinfo> #include "Rahmen.h" #include "Rechteck.h" #include "Kreis.h" int main(void){ Rechteck re1(Punkt(6,16),Punkt(27,3)); Kreis k1(Punkt(15,9),8); Rechteck re2(Punkt(12,13),Punkt(19,5)); Kreis k2(Punkt(15,9),4); Rahmen<Rechteck,Rechteck> r1(re1,re2); Rahmen<Rechteck,Kreis> r2(re1,k2); Rahmen<Kreis,Rechteck> r3(k1,re2); Rahmen<Kreis,Kreis> r4(k1,k2); GeoObjekt *g[8]={&re1,&k1,&re2,&k2,&r1,&r2,&r3,&r4}; for(int i=0;i<8;i++) std::cout<<typeid(*g[i]).name()<<":\t„ <<g[i]->flaeche()<<"\n"; return 0; } Stephan Kleuker

250 Umgang mit Collections
Collections sollen als Rückgabeparameter vermieden werden, damit nicht alle Collection-Methoden nutzbar sind Ansatz: Iteratoren auf Listen zurück geben Java: Interface Iterable implementieren public interface Iterable<T> Implementing this interface allows an object to be the target of the "foreach" statement. Method Summary  Iterator<T> iterator() Returns an iterator over a set of elements of type T. Methode gibt dann (schon implementierten) Iterator der Collection zurück Iterator leicht selbst zu implementieren, mit Methoden boolean hasNext() Returns true if the iteration has more elements.  E next()  Returns the next element in the iteration.  void remove() Removes from the underlying collection the last element returned by the iterator (optional operation). Stephan Kleuker

251 verstößt klar gegen Command-Query Separation Beispiel Integer-Menge
Method Chaining (1/3) immer sinnvolle Rückgabe nutzen; wenn wählbar wird statt void Objekt selbst zurück gegeben (this) verstößt klar gegen Command-Query Separation Beispiel Integer-Menge public class Main { public static void main(String[] args) { IntMenge tmp = new IntMenge(); tmp = tmp.hinzu(new int[]{1,21,11,41,31,1}) .kleinerAls(41).groesserAls(11); System.out.println(tmp); } [21, 31] Dr. Stephan Kleuker

252 Method Chaining (2/3) public class IntMenge {
private Set<Integer> menge = new HashSet<>(); public IntMenge(){ } public IntMenge hinzu(int... wert){ for(int w:wert){ this.menge.add(w); } return this; // hier sieht man Chaining public IntMenge kleinerAls(int grenze){ IntMenge ergebnis = new IntMenge(); for(int w:this.menge){ if(w < grenze){ ergebnis.hinzu(w); return ergebnis; Dr. Stephan Kleuker

253 Method Chaining (3/3) public IntMenge groesserAls(int grenze){ IntMenge ergebnis = new IntMenge(); for(int w:this.menge){ if(w > grenze){ ergebnis.hinzu(w); } return ergebnis; public boolean beinhaltet(int wert){ return public String toString(){ return this.menge.toString(); Stephan Kleuker

254 Grundidee von Design-Pattern
8.2 Damit nicht alle Klassen eng miteinander gekoppelt sind, gibt es Ansätze: die Aufgaben einer Klasse von der Verwaltung der Klassen, die Informationen dieser Klasse benötigen, zu trennen die Erzeugung von Objekten möglichst flexibel zu gestalten Interfaces zur Trennung von Implementierung und angebotenen Methoden einzusetzen Hierzu werden so genannte Design-Pattern eingesetzt, die für einen bestimmten Aufgabentyp eine flexible Lösung vorschlagen oft zitiert: E. Gamma, R. Helm, R. Johnson, J. Vlissides, Entwurfsmuster, Addison-Wesley, 2004 (Gang of Four [GoF]-Buch, hier neuere Auflage) Stephan Kleuker

255 Model-View-Controller
Typisch für graphische Oberflächen ist, dass es Objekte zur Eingabe gibt, die zur Bearbeitung der eigentlichen Inhaltsklasse führen, die dann eventuell zu Änderung der Anzeige führen Die Aufteilung in die drei genannten Aufgaben führt zum Model-View-Controller (MVC)-Ansatz MVC wurde zuerst in Smalltalk Ende der 80'er des vorigen Jahrhunderts eingesetzt: Model: Zustandsinformation der Komponente (Inhaltsklasse) View: Beobachter des Zustands, um diesen darzustellen; es kann viele Views geben Controller: Legt das Verhalten der Komponente auf Benutzereingaben fest Idee: Controller steuert Änderungen des Modells, Modell teilt allen Views mit, dass eine Änderung aufgetreten ist Hinweis: Spezielle Form des Beobachter-Musters (Observer) Stephan Kleuker

256 Java-Beispiel zum MVC (1/6)
Stephan Kleuker

257 Java-Beispiel zum MVC (2/6)
Stephan Kleuker

258 Java-Beispiel zum MVC (3/6)
import java.util.*; public class XModel{ private ArrayList<XModelListener> listener = new ArrayList<XModelListener> (); private int modellwert = 42; //Verwaltung der Listener des Modells public void addXModelListener(XModelListener x){ this.listener.add(x); } private void fireXModelChanged(){ for(XModelListener x:this.listener) x.xModelChanged(); //Auslesen der Modellinhalte public int getWert(){ return this.modellwert; //Veränderung des Modells public void changeValue(int delta){ this.modellwert += delta; fireXModelChanged(); Stephan Kleuker

259 Java-Beispiel zum MVC (4/6)
import javax.swing.*; public class XView extends JFrame implements XModelListener{ private XModel xmodel; private JLabel jlabel = new JLabel("Modellwert: "); public XView(XModel x){ super("Ich bin der View"); this.xmodel = x; this.xmodel.addXModelListener(this); //Rest Swing für Anzeige getContentPane().add(this.jlabel); setDefaultCloseOperation(EXIT_ON_CLOSE); setSize(250,60); setLocation(0,0); setVisible(true); } public void xModelChanged() { this.jlabel.setText("Modellwert: " + this.xmodel.getWert()); Stephan Kleuker

260 Java-Beispiel zum MVC (5/6)
import java.awt.FlowLayout; import java.awt.event.*; import javax.swing.*; public class XController extends JFrame{ private XModel xmodel; public XController(XModel x){ super("Ich bin der Controller"); this.xmodel = x; getContentPane().setLayout(new FlowLayout()); JButton plus = new JButton("plus"); getContentPane().add(plus); plus.addActionListener(new ActionListener(){ public void actionPerformed(ActionEvent e){ this.xmodel.changeValue(1); }}); JButton minus = new JButton("minus"); getContentPane().add(minus); minus.addActionListener(new ActionListener(){ this.xmodel.changeValue(-1); setDefaultCloseOperation(EXIT_ON_CLOSE); setSize(250,60); setLocation(0,90);´setVisible(true); } Stephan Kleuker

261 Java-Beispiel zum MVC (6/6)
public interface XModelListener { public void xModelChanged(); /* Anmerkung: alternativ kann man auch geänderte Werte als Parameter übertragen */ } public class XStarter { public static void main(String[] args) { XModel x = new XModel(); new XView(x); new XController(x); Stephan Kleuker

262 Interface weglassen, wenn nur eine View-Art
Pattern-Varianten Pattern schlagen eine mögliche Lösung vor; kann in Projekten variiert werden Interface weglassen, wenn nur eine View-Art Aufteilung auch sinnvoll, wenn nur ein View existiert (klare Aufgabentrennung) wenn Controller und View eng verknüpft, können sie vereinigt werden, z. B. GUI-Elemente in Java-Swing Listenerverwaltung kann vom Model in Controller verlegt werden auch ohne Listen ist MVC-Aufteilung sinnvoll 4: neue Darstellung 2: Eigenschaften aktualisieren Controller View Model 1: Nutzereingabe 3: Aktualisierung Stephan Kleuker

263 Ansatz Observer-Observable
8.3 Es gibt Subjekte für deren Zustand sich viele interessieren (z. B. Nachrichtenkanäle) Die Subjekte bieten die Möglichkeit, dass sich Interessenten anmelden (z. B. Kanal abonnieren) Bei jeder Subjektzustandsänderung werden Interessenten informiert (neue Nachrichten) Interessent muss sich bei Subjekt anmelden Damit obiges Objekt weiß, wie Interessent angesprochen werden soll, muss Interessent Schnittstelle realisieren Hinweis: Enge Verwandtschaft zu Model-View-Controller Stephan Kleuker

264 Beobachter (Observer – Observable)
Stephan Kleuker

265 Bsp.: Wertänderung mit aktualisieren übertragen
Pattern und Varianten Für fast jeden Pattern gibt es Varianten, die abhängig von Randbedingungen sinnvoller sein können Bsp.: Wertänderung mit aktualisieren übertragen Bsp.: Java hat keine Mehrfachvererbung Subjekt wird Interface Listenverwaltung in Hilfsklasse Konkretes Subjekt delegiert Listen- aufgaben an Objekt der Hilfsklasse Stephan Kleuker

266 Adapter - Problem Szenario:
Klasse IchBrauchB benötigt ein Objekt der Klasse B, genauer spezielle Funktionalität (Methode) der Klasse B Wir haben bereits eine Klasse C, die die von IchBrauchB von B geforderte Funktionalität anbietet C bietet die gewünschte Funktionalität unter dem falschen Methodennamen an, da C Teil einer komplexen Klassenstruktur ist, kann C nicht verändert werden Lösung: Schreibe Adapterklasse, die sich wie B verhält (von B erbt bzw. Interface B implementiert) und Objekt der Klasse C aggregiert Adapter leitet Aufruf der von IchBrauchB gewünschten Funktionalität an C weiter Stephan Kleuker

267 Adapter - Lösung public class Adapter implements B{
private C c = null; ... public Adapter(){ c = new C(); } @Override public void machWasTolles(){ return c.kannWasWasAuchBKoennenSoll(); Stephan Kleuker

268 Fassade nach außen Generell sollen Klassen eng zusammen-hängend sein, z. B. Methoden können nicht auf mehrere Klassen verteilt werden. anderen Nutzern möchte man nur eine einfache externe Sicht bieten, deshalb liefern zusammenhängende Klassen häufiger eine Fassadenklasse („davorgeklatscht“) nach außen. Stephan Kleuker

269 Beispielanwendung: Abstract Factory Pattern
Stephan Kleuker

270 Ausschnitt aus möglichem Code
public class Verpackung{ private Spielefabrik fabrik=null; private Spielbrett brett=null; // private Spielfigur figur=null; public Verpackung(Spielefabrik sf){ fabrik=sf; brett=fabrik.getSpielbrett(); figur=fabrik.getSpielfigur(); } ... public int berechneVolumen(){ return brett.getFlaeche()*figur.getHoehe(); Vorteil: Leichte Ergänzung neuer Spiele, mit Spielbrettern und Spielfiguren Nachteil: Aufwändig neue Objektart, z. B. Spielanleitung, zu ergänzen Stephan Kleuker

271 Einsatzmöglichkeiten von Sichtbarkeiten
Standard-OO-Programmierung: Exemplarvariablen private [oder protected], Exemplarmethoden public (analog für Klassenvariablen und –methoden) In Spezialfällen können Sichtbarkeiten geändert werden, Beispiel: Im gesamten System gibt es ein Objekt, mit dem die Verbindung zu anderen Systemen aufgebaut wird Wird das Objekt das erste Mal benötigt, wird es erzeugt, bei weiteren Anfragen werden Referenzen auf dieses identische Objekt zurück gegeben Objekt muss in Klassenvariable gespeichert werden Nutzer dürfen keine Konstruktoren aufrufen, da es sonst verschiedene Objekte gibt (Konstruktoren werden private) Zugriff auf das Objekt über Klassenmethoden Stephan Kleuker

272 Singleton (1/3) public class Singleton { private int x = 0;
private int y = 0; private static Singleton pkt = null; // einziges //Exemplar private Singleton(int x, int y){ this.x = x; this.y = y; } public static Singleton getPunkt(){ if (pkt==null) // ein einziges Mal erzeugen pkt= new Singleton(6,42); return pkt; Stephan Kleuker

273 Singleton (2/3) @Override public Singleton clone(){
//echtes Kopieren verhindern return this; } public void ausgeben(){ System.out.print("["+this.x+","+this.y+"]"); public void verschieben(int dx, int dy){ this.x += dx; this.y += dy; Stephan Kleuker

274 Singleton (3/3) public class Main {
public static void main(String[] s){ Singleton p1=Singleton.getPunkt(); Singleton p2=Singleton.getPunkt(); // Singleton sing= new Singleton(); //constructor not visible p1.ausgeben(); p2.ausgeben(); if(p1==p2) System.out.println("\n identisch"); p1.verschieben(3,5); Singleton p3=p1.clone(); if(p2==p3) } [6,42][6,42] identisch [9,47][9,47] Stephan Kleuker

275 Proxy Beim Proxy (oder Stellvertreter)-Pattern wird der Zugriff auf eine „wertvolle“ Ressource durch eine vorgeschaltete Klasse gesteuert Nutzer des Proxys nutzen diesen wie die eigentliche Klasse Stephan Kleuker

276 Proxy – Implementierungsmöglichkeit (1/2)
public interface KlasseMitWertvollemInhalt { public int anfrage(String details); } public class RealeKlasse implements KlasseMitWertvollemInhalt { private Verbindung verbindung; public RealeKlasse(String verbindungsdaten){ verbindung=new Verbindung(verbindungsdaten); public int anfrage(String details) { return verbindung.befragen(details); Stephan Kleuker

277 Proxy – Implementierungsmöglichkeit (2/2)
public class Proxy implements KlasseMitWertvollemInhalt { //Variante mit Singleton (gibt Alternativen) private static RealeKlasse realesObjekt; public Proxy(){ if(realesObjekt==null) realesObjekt= new RealeKlasse("Spezialinfos"); } public int anfrage(String details) { return realesObjekt.anfrage(details); public class Nutzer { public int proxyNutzen(String anfrage){ KlasseMitWertvollemInhalt k=new Proxy(); return k.anfrage(anfrage); public static void main(String[] s){ //etwas sinnlos, zu Testzwecken Nutzer n= new Nutzer(); System.out.println(n.proxyNutzen("gib41")); Stephan Kleuker

278 Die Wahl der Implementierungsart soll leicht verändert werden können
Strategy - Problem Für eine Methode gibt es verschiedene Möglichkeiten sie zu implementieren Die Wahl der Implementierungsart soll leicht verändert werden können Einsatzszenarien Prototypische Implementierung soll später leicht ausgetauscht werden können Wahl der effizientesten Methode hängt von weiteren Randbedingungen ab (z. B. suchen / sortieren) Ausführungsart der Methode soll zur Laufzeit geändert werden können (Kunde zahlt für einen Dienst und bekommt statt Werbe- Detailinformationen) Stephan Kleuker

279 Strategy - Lösungsbeispiel
Stephan Kleuker

280 State-Pattern (eigene Variante)
Stephan Kleuker

281 State-Pattern – Implementierungsauszug (1/2)
public abstract class Zustand { protected int x; public abstract Zustand setX(int x); public abstract String status(); protected Zustand(int x){ this.x=x; } public class ZustandOK extends Zustand{ public ZustandOK(int x) { super(x); @Override public Zustand setX(int x) { if(x>=42) return new ZustandKritisch(x); return this; public String status() {return "alles ok";} Stephan Kleuker

282 State-Pattern – Implementierungsauszug (2/2)
public class Messstation { private String standort = "City"; private Zustand z= new ZustandOK(0); public void zustandAendern(int wert){ z=z.setX(wert); } public void ausgeben(){ System.out.println(standort +" Zustand: "+z.status()); Stephan Kleuker

283 Command-Objekte kennen Details der Ausführung
Command-Pattern Problem: unterschiedliche Aktionen werden zentral ausgeführt und verwaltet Ansatz: Stecke detaillierte Ausführung in ein (Command-)Objekt; diese haben gemeinsames Interface Command-Objekte kennen Details der Ausführung Steuerung dann einfach änder- und erweiterbar Beispiel: Kleiner Taschenrechner mit + und – und einem Zwischenspeicher für einen Wert, der dann aufaddiert werden kann Stephan Kleuker

284 Beispiel 1/12 : Rechner 1/2 package business; public class Rechner { private int anzeige; private int speicher; public int getAnzeige() { return anzeige; } public void setAnzeige(int anzeige) { this.anzeige = anzeige; public int getSpeicher() { return speicher; public void setSpeicher(int speicher) { this.speicher = speicher; Stephan Kleuker

285 Beispiel 2/12 : Rechner 2/2 public void addieren(int wert) { this.anzeige += wert; } public void subtrahieren(int wert) { this.anzeige -= wert; public void speichern(){ this.speicher = this.anzeige; public void speicherAddieren(){ this.anzeige += this.speicher; public void speicherSubtrahieren(){ this.anzeige -= public String toString(){ return "Speicher: "+ this.speicher +" Wert: " + this.anzeige; Stephan Kleuker

286 Beispiel 3/12 : Klassischer Dialog 1/2
package io; import business.Rechner; public class Dialog { private Rechner rechner = new Rechner(); public void dialog() { EinUndAusgabe ea = new EinUndAusgabe(); int eingabe = -1; while (eingabe != 0) { System.out.println("(0) Programm beenden\n" + "(1) addieren\n" + "(2) subtrahieren\n" + "(3) Anzeige in Speicher\n" + "(4) Speicher addieren\n" + "(5) Speicher subtrahieren"); eingabe = ea.leseInteger(); switch (eingabe) { case 1: { System.out.print("Wert eingeben: "); this.rechner.addieren(ea.leseInteger()); break; } Stephan Kleuker

287 Beispiel 4/12 : Klassischer Dialog 2/2
case 2: { System.out.print("Wert eingeben: "); this.rechner.subtrahieren(ea.leseInteger()); break; } case 3: { this.rechner.speichern(); case 4: { this.rechner.speicherAddieren(); case 5: { this.rechner.speicherSubtrahieren(); System.out.println(this.rechner); Stephan Kleuker

288 Beispiel 5/12 : Funktioniert immerhin
(0) Programm beenden (1) addieren (2) subtrahieren (3) Anzeige in Speicher (4) Speicher addieren (5) Speicher subtrahieren 1 Wert eingeben: 43 Speicher: 0 Wert: 43 2 Wert eingeben: 1 Speicher: 0 Wert: 42 3 Speicher: 42 Wert: 42 (4) Speicher addieren 4 Speicher: 42 Wert: 84 (5) Speicher subtrahieren 5 Speicher: 42 Wert: 42 (0) Programm beenden Stephan Kleuker

289 Beispiel 6/12 : Ansatz 1: Steuerungsklassen
Stephan Kleuker

290 Beispiel 7/12 : Umsetzung 1/3
package io.commands; public interface Command { public void execute(); } import main.EinUndAusgabe; import business.Rechner; public class Addieren implements Command { private Rechner rechner; public Addieren(Rechner rechner){ this.rechner = public void execute() { System.out.print("Wert eingeben: "); this.rechner.addieren(new EinUndAusgabe().leseInt()); public String toString(){return "addieren";} typischerweise werden Zusatzinformationen benötigt eigentliche Ausführung Stephan Kleuker

291 Beispiel 8/12 : Umsetzung 2/3 (Varianten -> Praktikum)
package main; import java.util.HashMap; import java.util.Map; import business.Rechner; public class Dialog { private Rechner rechner = new Rechner(); private Map<Integer,Command> aktionen = new HashMap<>(); public Dialog(){ this.aktionen.put(1, new Addieren(this.rechner)); this.aktionen.put(2, new Subtrahieren(this.rechner)); this.aktionen.put(3 , new AnzeigeSpeichern(this.rechner)); this.aktionen.put(4 , new SpeicherAddieren(this.rechner)); this.aktionen.put(5 , new SpeicherSubtrahieren(this.rechner)); } Hinweis: Geht auch mit einfachem Array, wenn Position 0 sinnvoll gefüllt werden kann (einfache Übungsaufgabe) Stephan Kleuker

292 Beispiel 9/12 : Umsetzung 3/3
public void dialog() { EinUndAusgabe ea = new EinUndAusgabe(); int eingabe = -1; while (eingabe != 0) { System.out.println("(0) Programm beenden"); for(int tmp:this.aktionen.keySet()){ System.out.println("("+tmp+") " + this.aktionen.get(tmp)); } eingabe = ea.leseInteger(); Command com = this.aktionen.get(eingabe); if(com !=null){ com.execute(); System.out.println(this.rechner); Stephan Kleuker

293 es müssen alle Änderungen der Aktion bekannt und reversibel sein
Beispiel 10/12 : Undo Command-Pattern eignet sich sehr gut, Aktionen wieder rückgängig zu machen es müssen alle Änderungen der Aktion bekannt und reversibel sein gibt verschiedene Varianten Ansatz 1: jedes Command-Objekt hat undo-Methode und wird gespeichert Ansatz 2: es gibt eigenes Undo-Command-Objekt als Ergebnis von execute() Ansatz 3: Undo- und Command-Objekte haben keine gemeinsame Klasse / Interface Stephan Kleuker

294 Beispiel 11/12 : Variante Undo-Methode
Stephan Kleuker

295 Beispiel 12/12 : Variante Undo-Objekte (Skizze)
Hier auf abstrakte Realisierung verzichtet, da diese nur eine Exemplarvariable umfasst Stephan Kleuker

296 Fazit Command-Pattern
generell oft bei Steuerungen einsetzbar oft gut für Undo- und Redo geeignet meist individuelle Varianten des Patterns sinnvoll (in UML-Diagrammen oft zusätzliche Klasse, die auf Command zugreifen kann) Command-Klassen müssen einfach an benötigte Informationen kommen können; wird dies kompliziert, ist der Patter-Einsatz nicht sinnvoll Stephan Kleuker

297 Beschreibung des Pattern
8.4 Name: Abstract Factory Patterngruppe: Objekterzeugung Kurzbeschreibung: Client kann mit einer AbstractFactory zu einer abstrakten Klasse passende Exemplare aus einem Satz konkreter Implementierungen für bestimmtes Produkt erzeugen, kennt den konkreten Typ des erzeugten Exemplars nicht Kontext: viele verschiedene gleichartige, aber unterscheidbare Objekte sollen verwaltet werden Problem: Klasse soll verschiedene Objekte bearbeiten, benötigt aber nur deren gemeinsame Eigenschaften Lösung: Einführung von zwei abstrakten Klassen, die zum Einen Objekterzeugung, zum Anderen Objektzugriff erlauben, Client muss nur diese Klassen kennen Einsatzgebiete: Varianten: Struktur: s.o Beispiele: Stephan Kleuker

298 Gruppen von Pattern (Beispiele)
Strukturpattern befassen sich mit der Komposition von Klassen und Objekten, um größere Strukturen zu bilden Zielsetzungen: Anpassung von Schnittstellen (Adapter) Trennung von Abstraktion und Implementierung (Brücke) Zusammensetzung von Objekten (Kompositum) Erzeugen von Stellvertreterobjekten (Proxy) Erzeugungspattern sollen das Wissen um das System und die konkreten Klassen des Systems vor dem Benutzer verstecken Zielsetzungen: Systeme leichter konfigurierbar zu machen Änderungen im Entwurf vorherzusehen Verhaltenspattern ... Stephan Kleuker

299 GoF-Pattern Übersicht (nicht auswendig lernen)
Aufgabenbereich Erzeugung Struktur Verhalten Factory Adapter Interpreter Template Abstract Factory Command Builder Bridge Observer Prototype Decorator Visitor Singleton Facade Memento Composite Strategy Proxy Mediator Flyweight State Chain of Responsibility Klasse Einsatzbereich Objekt Stephan Kleuker

300 Pattern in der UML Pattern-Name im gestrichelten Kreis, verbunden mit eingekreisten Klassen, verbunden mit Pattern und Bennenung der Rollen Stephan Kleuker

301 Kritische Betrachtung von Pattern
Pattern für Anfänger wenig geeignet, man muss erste Erfahrungen haben, um von Erfahrungen anderer zu profitieren überlagernde Pattern schwer pflegbar, später in Implementierungen teilweise schwer erkennbar ?? Wer mit Pattern umgehen kann, sollte in kritischeren Bereichen einer Firma eingesetzt werden ?? Pattern finden Einzug in Bibliotheken, Beispiel: Event-Handling in Java ist „Observer-Pattern“ Generell sind Pattern ein wichtiger Teilschritt zum ingenieurmäßigen SW-Engineering Gute Programmier-Aufgabe: Entwickeln Sie kleine Beispiele zu allen GoF-Pattern !!! Stephan Kleuker

302 9. Implementierungs-aspekte
9.1 Einfluss nicht-funktionaler Anforderungen 9.2 Verteilte Systeme 9.3 Grundideen von XML 9.4 Programmbibliotheken 9.5 Komponenten 9.6 Frameworks 9.7 Persistente Datenhaltung 9.8 Annotationen 9.9 Domain Specific Languages 9.10 Model Driven Architecture 9.11 Refactoring Hinweis: Hier nur Skizze interessanter Konzepte, die Schwerpunkte weiterer Veranstaltungen sind Stephan Kleuker

303 Randbedingungen für erfolgreiches Design
Nach Analysemodell und vor Design stehen wichtige Entscheidungen bisher: wir kennen die generelle Entwicklung einer SW-Architektur (Pakete) wir entwickeln klassische SW für einen Rechner, Objekte können theoretisch Methoden beliebiger anderer Objekte aufrufen aber vor Beginn der Designphase spielt auch die Berücksichtigung weiterer Randbedingungen zentrale Rolle: muss existierende SW eingebunden werden? muss für eine spezielle HW entwickelt werden? welche Anforderungen gibt es an die Verteilung von SW auf unterschiedliche Rechner? welche Rolle spielen nichtfunktionale Anforderungen (Safety, Security, Performance, Oberflächendesign) Stephan Kleuker

304 Beispiel: Rahmenbedingungen für SW-Architektur
9.1 Berücksichtigung von speziellen SW-Schnittstellen nicht objektorientiert entwickelter Systeme, z. B. von Application Programming Interfaces (API) fremder SW Berücksichtigung/Benutzung existierender Datenhaltungssysteme, z. B. Vorgabe des Datenbankmanagementsystems (DBMS) Berücksichtigung bestimmter Design-Prinzipien, z. B. Gesamtsteuerung mit Enterprise Java Beans (EJB) oder .NET für die Realisierung Alt-Software (z. B. in COBOL), so genannte Legacy-Systeme müssen eingebunden werden; Einsatz einer Middleware (z. B. Common Object Request Broker Architecture, CORBA) Stephan Kleuker

305 Einfluss nichtfunktionaler Anforderungen
Beispiel: Sicherheit (Security) Alle Nachrichten müssen über den speziellen Krypto-Server laufen; dieser hat bestimmte Bandbreite (Bottle-neck); SW muss auf allen Seiten möglichst viel ohne Verbindung arbeiten können (Redundanz wird erlaubt) Beispiel: Sicherheit (Safety) Berechnungen zur Steuerung müssen redundant auf drei Rechnern mit unterschiedlichen Verfahren durchgeführt werden Beispiel: Performance Die rechenintensiven 3D-Berechnungen müssen sehr schnell sein; dies kann zum Einsatz von C mit langen komplexen Funktionen führen Stephan Kleuker

306 Rahmenbedingung: verteilte Systeme
9.2 in der klassischen OO-Programmierung gibt es einen Programmablauf (Prozess) und man nutzt synchrone Aufrufe: Objekt O1 ruft Methode von Objekt O2 auf; O2 übernimmt die Programmausführung und antwortet dann O1 bei verteilten Systemen laufen viele Prozesse parallel ab, die Informationen austauschen können synchroner Aufruf ist möglich, bedeutet aber, dass Verbindung aufgebaut werden muss und Sender bzw. Empfänger auf Bereitschaft warten müssen asynchroner Aufruf bedeutet, dass Sender Aufruf abschickt und danach weiterarbeitet; später prüft, ob ein Ergebnis vorliegt asnychrone Aufrufe sind schneller (nur abschicken); Prozesse sind aber schwer zu synchronisieren die Herausforderung effizienter verteilter Systeme hat nicht die eine Lösung und wird Sie Ihr Informatik-Leben-lang verfolgen Stephan Kleuker

307 Probleme der Aufrufmechanismen
synchroner Aufruf Prozess A Prozess B Prozess C berechne_x() berechne_y() warten auf Antwort warten auf Antwort Problem: Deadlock y() asynchroner Aufruf x() Problem: B denkt, x hat vor y stattgefunden Problem: C denkt, x hat vor y stattgefunden, A denkt, y hat vor x stattgefunden y() x() Stephan Kleuker

308 Typische Probleme verteilter Systeme
Deadlocks: kein Prozess/Thread kann voran schreiten partielle Deadlocks: einige Prozesse im Deadlock, andere nicht Livelocks: System versucht, sich zyklisch zu synchronisieren, ohne dass das System voran schreitet (starke) Fairness : kommen Prozesse, die immer mal wieder darauf warten, in den kritischen Bereich zu kommen, auch dran (schwache) Fairness: kommen Prozesse, die immer darauf warten, in den kritischen Bereich zu kommen, auch dran synchronized() in Java (Methode wird garantiert ohne Parallelnutzung des aufgerufenen Objekts genutzt) hat starken negativen Einfluss auf die Laufzeit Erinnerung/Ausblick: Notwendige Transaktionssteuerung bei Datenbankmanagementsystemen Stephan Kleuker

309 Beispiel: Varianten von Client-Server-Systemen
Thin Client: Hier nur Datenannahme, Weiterleitung, Darstellung, keine komplexen Berechnungen Beispiele: Web-Browser, DB-Clients Fat Client: Client führt eigene komplexe Berechnungen aus; nutzt Server nur zur Verwaltung zentraler Informationen und zum Nachrichtenaustausch Beispiel: vernetzbare Stand-alone-Spiele (Autorennen) Client Client Netzwerk Server Netzwerk Server Stephan Kleuker

310 Beispiel: 3-Tier-Architektur
Verteilung: Nur Darstellung (GUI) beim Client eigener Server für Anwendung eigene Datenspeicherung Vorteile: benötigte DB-Verbindungen können angepasst werden (Kosten) Datenbank nicht direkt für Client zugreifbar (Sicherheit) Änderungen einer Schicht müssen andere Schichten nicht beeinflussen Client Präsentationsschicht Server für Anwendung eigentliche Anwendungs-SW Datenbank-Server persistente Datenhaltung Stephan Kleuker

311 Erinnerung: XML eXtensible Markup Language
9.3 eXtensible Markup Language strukturierte maschinen- und ansatzweise menschenlesbare Informationsbeschreibung Applikationen müssen Daten vor der Programmbeendung speichern, sollten diese mit anderen Programmen austauschen können (-> Definition eines gemeinsamen XML-Formats) Neben reiner Syntax kann auch die erlaubte inhaltliche Struktur spezifiziert werden (DTD: Document Type Definition), XML-Schema Viele gute Werkzeuge und Bibliotheken zur XML-Verarbeitung zentrale Inhalte werden mit Elementen und Attributen beschrieben Strukturierung durch Namensräume Stephan Kleuker

312 Elemente beschreiben zentrale Inhalte von XML-Dokumenten
Namen der Elemente können vom Autor frei vergeben werden (soll Dokument mit verschiedenen Applikationen bearbeitet werden, muss man sich auf das Vokabular einigen -> später) Typische Form <projektname> XML-DB </projektname> Element heißt projektname, der Inhalt ist vom sogenannten Start- und End-Tag umgeben Abkürzungsmöglichkeit bei leerem Inhalt: <projektname/> Leerzeichen führen meist zu Fehlern, hier z. B. drei <■bla > <■/■bla > Stephan Kleuker

313 Hierarchischer Aufbau
Elemente können ineinander geschachtelt werden Ausgehend vom obersten Element ergibt sich ein Baum <team> <mitarbeiter> <minr>42</minr> <name>Aische Meier</name> <anteil>40</anteil> </mitarbeiter> <minr>46</minr> <name>Nabil Ibn</name> <anteil>50</anteil> </team> Stephan Kleuker

314 Jedes Element kann eine beliebige Anzahl an Attributen haben
Attribute stehen in Anführungsstrichen (" oder ') <projekt abteilung="Entwicklung" vertrag="Festpreis"> <projektname>Speichermodul</projektname> <kunde blz=" " knr=" " /> <projektleiter kosten="1000"> <minr>49</minr> <name>Ute Rose</name> <anteil>50</anteil> </projektleiter> </projekt> Stephan Kleuker

315 Attribute oder Elemente
Attribute beschreiben Eigenschaften von Elementen Eigentlicher Inhalt steht zwischen den Tags Aus theoretischer Sicht vertauschbar <projekt abteilung="Entwicklung" vertrag="Festpreis"/> alternativ <projekt> <abteilung> Entwicklung </abteilung> <vertrag> Festpreis </vertrag> </projekt> Aus Sicht der Verarbeitung leichte Unterschiede, Tendenz zu Attributen Stephan Kleuker

316 Kommentare und Namensregeln
Grundsätzlich existieren nur kommentierte Produkte XML Kommentar in <!-- und --> eingeschlossen <!-- Isch bin ähn Gommenta --> Im Kommentartext kein -- erlaubt, auch keine Schachtelung Kommentare in Elementen nicht erlaubt XML unterscheidet Groß- und Kleinschreibung, Elemente und Attribute meist klein (keine sehr feste Regel) Bezeichner müssen mit Buchstaben oder _ oder : beginnen In Bezeichnern beliebige Zeichen erlaubt Grundregeln für eigene Elementnamen: selbsterklärend nicht mit _ oder : beginnen (für Spezialfälle, : generell nicht) auf Umlaute verzichten Stephan Kleuker

317 Genereller Aufbau eines XML-Dokuments
Dokument beginnt mit XML-Deklaration gefolgt von Element folgt: jedes XML-Dokument als Baum mit Wurzel betrachtbar (mit root element oder document element) <?xml version="1.0" encoding="utf-8"?> <!-- angeblich generiert aus Spro  --> <projekt abteilung="Entwicklung" vertrag="Eigenentwicklung">   <projektname>Speicher </projektname> </projekt> version (bleibt vielleicht immer) 1.0 oder 1.1 encoding gibt verwendeten Zeichensatz an, hier klein oder Großschreibung möglich, typisch sind UTF-8 8 Bit Zeichenbereite (Standard) UTF-16 16 Bit Zeichenbreite (bel. Sprachen) ISO Westeuropäische Sprachen Stephan Kleuker

318 Nutzung von Programmbibliotheken
9.4 Programmbibliotheken stellen Standardlösungen für häufig wiederkehrende Probleme dar typische Nutzung: Nutzer erzeugt und ruft Objekte (Klassen) der Bibliothek auf Bibliotheken sind geprüft (hoffentlich) und für Laufzeiten optimiert Dokumentation von Bibliotheken wichtig zum effizienten Einsatz (was rufe ich wann auf) Je größer der Verbreitungsgrad, desto einfacher die Weiterverwendung von Ergebnissen (großer Vorteil der Java-Klassenbibliothek) Grundregel für erfahrene Entwickler: Erfinde das Rad niemals zweimal, weiß aber, wo viele Blaupausen für viele verschiedene Räder sind Grundregel für Informatikanfänger: Lerne zu verstehen, wie man das erste Rad baut, baue das erste Rad und lerne warum man wie die Blaupause variieren kann Stephan Kleuker

319 Idee von Komponenten 9.5 Komponenten sind komplexe in sich abgeschlossene „binäre“ SW-Bausteine, die größere Aufgaben übernehmen können Ansatz: SW statt aus kleinen Programmzeilen aus großen Komponenten (+ Klebe-SW) zusammen bauen Komponenten werden konfiguriert, dazu gibt es get-/set-Methoden (Schnittstelle) oder/und Konfigurationsdateien Beispiel Swing-Klassen, wie JButton haben (u. a.) Komponenteneigenschaft; man kann u. a. einstellen: Farben (Hintergrund, Vordergrund) Schrifttypen Form der Ecken dargestelltes Bild Komponenten sind themenorientiert und können unterschiedliche Aufgaben erfüllen (z. B. Daten filtern, Werte überwachen) Stephan Kleuker

320 GUI-Builder (1/2) Die Programmierung von Oberflächen in Java ist zwar recht strukturiert möglich, viele Arbeitsschritte wiederholen sich aber monoton GUI-Builder stellen einen anderen Ansatz zur Entwicklung von Oberflächen vor, Oberflächen werden per Drag-and-Drop zusammengestellt Die weitere Programmierung findet durch den Entwickler „unterhalb“ der GUI-Elemente statt, jeder Code muss einer Komponente zugeordnet werden GUI-Builder eignen sich damit sehr gut, schnell einen GUI-Prototypen zu erstellen, um mit den späteren Nutzern das Look-and-Feel zu diskutieren Stephan Kleuker

321 GUI-Builder (2/2) GUI-Builder haben aber auch Nachteile:
Software ist häufig nicht GUI-gesteuert entwickelbar, je komplexer das „Innenleben“ ist, desto weniger steht das GUI in der Entwicklung im Mittelpunkt wer nicht weiß, wie ein GUI funktioniert, programmiert nur Fragmente und kennt das Zusammenspiel des Systems nicht oftmals können ohne GUI-Builder entwickelte Oberflächen nicht mit dem GUI-Builder weiter bearbeitet werden GUI-Builder geben die Struktur des Codes vor, d.h. man muss sich auf die Programmiereigenheiten des GUI-Builders zu 100% einlassen die Unterstützung von Pattern (guten Designideen, wie MVC) ist nicht immer gegeben Fazit: Der Einsatz eines GUI-Builders sollte nur in Betracht gezogen werden, wenn man die Grundsätze zur GUI-Entwicklung in der jeweiligen Programmiersprache verstanden hat, danach muss getestet werden, ob man mit dem resultierenden Code leben kann Stephan Kleuker

322 Zentrale Eigenschaften von Komponenten
Stephan Kleuker

323 Idee der Framework-Technologie
9.6 statt vollständiger SW werden Rahmen programmiert, die um Methodenimplementierungen ergänzt werden müssen Frameworks (Rahmenwerke) können die Steuerung gleichartiger Aufgaben übernehmen typische Nutzung: Nutzer instanziiert Framework-Komponenten, d. h. übergibt seine Objekte zur Bearbeitung durch das Framework; typischer Arbeitsschritt: Framework steuert, d. h. ruft Methode der Nutzerobjekte auf eventuelles Problem: schwieriger Wechsel zu anderem Framework oder bei Ablösung des Frameworks Stephan Kleuker

324 Framework-Technologie in Swing
Framework-Technologie „im Kleinen“: auch Java-Klassenbibliothek [kritischer Name] bietet es an, dass einfache Klassen zu Komponenten des Model-Delegate-Ansatzes der Swing-Komponenten werden Beispiele: JTree (oder JTable) Forderung: Eine darzustellende Klasse muss das zugehörige Interface TreeModel implementieren Konstruktor JTree(TreeModel tm) Eigenschaften eines JTree, z. B. wie Inhalte dargestellt werden, können über Methoden gesteuert werden (JTree wird als normales Element der Klassenbibliothek genutzt) JTree steuert die Darstellung, ruft dazu Methoden des TreeModel auf Stephan Kleuker

325 TreeModel Ausschnitt: angebotene Methoden (s. Java-Dokumentation)
 void addTreeModelListener(TreeModelListener l) Adds a listener for the TreeModelEvent posted after the tree changes.  Object getChild(Object parent, int index) Returns the child of parent at index index in the parent's child array.  int getChildCount(Object parent) Returns the number of children of parent. getIndexOfChild(Object parent, Object child) Returns the index of child in parent. getRoot() Returns the root of the tree.  boolean isLeaf(Object node) Returns true if node is a leaf. removeTreeModelListener(TreeModelListener l) Removes a listener previously added with addTreeModelListener. valueForPathChanged(TreePath path, Object newValue) Messaged when the user has altered the value for the item identified by path to newValue. Stephan Kleuker

326 Skizze einer Beispielimplementierung (1/5)
Knoteninformation dient dazu, für den jeweiligen Knoten die darstellungsrelevanten Informationen zu liefern Stephan Kleuker

327 Skizze einer Beispielimplementierung (2/5)
ProjektTreeModel ptm = new ProjektTreeModel(); JTree baum = new JTree(ptm); JScrollPane scroller = new JScrollPane(baum); add(scroller,BorderLayout.CENTER); Stephan Kleuker

328 Skizze einer Beispielimplementierung (3/5)
public class ProjektTreeModel implements TreeModel { private Projektverwaltung projektverwaltung; private List<TreeModelListener> listener = new ArrayList<TreeModelListener>(); public ProjektTreeModel() { this.projektverwaltung = new Projektverwaltung(); } public Object getRoot() { return this.projektverwaltung; public Object getChild(Object arg0, int i) { return ((Knoteninformation)arg0).itesElement(i); public int getChildCount(Object arg0) { return ((Knoteninformation)arg0).anzahlElemente(); public void addTreeModelListener(TreeModelListener arg0){ this.listener.add(arg0); } // nur Ausschnitt Stephan Kleuker

329 Skizze einer Beispielimplementierung (4/5)
public class Projektverwaltung implements Knoteninformation{ private List<Projekt> projekte = new ArrayList<Projekt>(); public int anzahlElemente() { return this.projekte.size(); } public Knoteninformation itesElement(int i) { return this.projekte.get(i); public boolean istBlatt() { return false; public String titel() { return "Projektverwaltung"; @Override public String toString(){ return titel(); } // nur Ausschnitt Stephan Kleuker

330 Skizze einer Beispielimplementierung (5/5)
public class Projekt implements Knoteninformation{ private Eigenschaft[] eigenschaften = new Eigenschaft[8]; private BaumListe<Projekt> teilprojekte = new BaumListe<Projekt>("Teilprojekte"); private BaumListe<Projekt> vorgaenger = new BaumListe<Projekt>("Vorgaenger"); private BaumListe<Aufgabe> aufgaben = new BaumListe<Aufgabe>("Aufgaben"); public int anzahlElemente() { return this.eigenschaften.length+3; } public Knoteninformation itesElement(int i) { switch(i){ case 0: case 1: case 2: case 3: case 4: case 5: case 6: case 7: return eigenschaften[i]; case 8: return vorgaenger; case 9: return teilprojekte; case 10:return aufgaben; return null; } // nur Ausschnitt Stephan Kleuker

331 Ziele komplexere Framework-Ansätze
neben Spezialaufgaben werden hauptsächlich folgende Aufgaben gelöst sorgenfreies Lesen und Speichern von Objekten in Datenbanken (Persistenz) sorgenfreie konsistente Verteilung von Informationen (Prozesskommunikation) sorgenfreie Steuerung verteilter Abläufe mit Überwachung von Transaktionen Beispiele sind Enterprise Java Beans, Microsoft Dot-Net-Technologie, Spring, Hibernate, viel im Bereich AJAX Stephan Kleuker

332 Persistente Datenhaltung
9.7 Typische Java-Möglichkeiten Anschluss an klassische relationale DB über JDBC (typisch bei Anbindung an existierende DB) Nahtlose Integration der Datenhaltung in die Entwicklung (Ansatz: statt Objekt zu erzeugen Methode holeObjekt(), später sichere Objekt), typisch für Hibernate (häufig genutzt, bei kleinen Spezialanwendungen, z. B. Handy, Organizer) relativ nahtlose Integration durch zusätzliche Software, die objekt-relationales Mapping übernimmt Nutzung eines Frameworks, das Persistenz und Transaktionssteuerung übernimmt, Enterprise Java Beans Stephan Kleuker

333 Beispiel: JavaBeans (kleiner Ausschnitt)
Java unterstützt Reflektion, damit kann ein Objekt nach seiner Klasse, seinen Exemplarvariablen und Exemplarmethoden befragt werden Hält man sich an folgende einfache Regel für eine Klasse sie implementiert Serializable (geht nur, wenn alle verwendeten Typen Serializable) für alle Exemplarvariablen gibt es die Standard get- und set-Variablen es gibt einen leeren Default-Konstruktor dann sind einige Framework-Ansätze nutzbar Objekte speichern und lesen in XML Nutzung als JavaBeans (sinnvoll weitere Standardmethoden) Objekte speichern in einer Datenbank mit JDO, als Entity Objekte im Binärformat lesen und schreiben (reicht Serializable) Stephan Kleuker

334 XMLEncoder und XMLDecoder (Ausschnitt)
private void speichern(String datei){ try { XMLEncoder out= new XMLEncoder( new BufferedOutputStream(new FileOutputStream(datei))); out.writeObject(table.getModel()); out.close(); } catch (FileNotFoundException e) {} //wegschauen } private void laden(String datei){ XMLDecoder in= new XMLDecoder( new BufferedInputStream(new FileInputStream(datei))); table.setModel((DefaultTableModel)in.readObject()); in.close(); Stephan Kleuker

335 verwandt mit aspektorientierter Programmierung
Annotationen 9.8 klassische imperative Programmierung (=prozedural, objektorientiert): man beschreibt welche Schritte gemacht werden sollen Annotationen: man schreibt was man haben will; eigentliche Realisierung wird vom Framework übernommen verwandt mit aspektorientierter Programmierung Stephan Kleuker

336 Beispiel JPA (1/2) @Entity
soll persistiert werden @Entity public class Mitarbeiter implements Serializable { private static final long serialVersionUID = 1L; @Id @GeneratedValue(strategy = GenerationType.AUTO) private int minr; private String name; @OneToMany(mappedBy="bearbeiter", cascade={CascadeType.PERSIST, CascadeType.MERGE}) private Set<Projektauftrag> auftraege = new HashSet<Projektauftrag>(); ... public void auftragHinzu(Projektauftrag pa){ auftraege.add(pa); } // get- und set- für Exemplarvariablen fehlen Schlüssel automatisch generiert Exemplarvariable ist Schlüssel 1:N-Beziehung Stephan Kleuker

337 Beispiel JPA (2/2) – nur Überblick
private EntityManagerFactory emf = Persistence.createEntityManagerFactory("JPAKonfigDatei"); private EntityManager em = emf.createEntityManager(); public void mitarbeiterBeispieldaten(){ Mitarbeiter m[]= {new Mitarbeiter("Egon"), new Mitarbeiter("Aische"), new Mitarbeiter("Urs")}; em.getTransaction().begin(); for (int i=0; i<m.length; i++) em.persist(m[i]); em.getTransaction().commit(); } public void datenZeigen() { for (Mitarbeiter m : em.createQuery( "SELECT m FROM Mitarbeiter m",Mitarbeiter.class) .getResultList()) System.out.println(m.getId() + ": " + m.getName()); Dies Folie soll nicht im Detail verstanden werden. Sie zeigt aber, dass die Ideen in Frameworks verpackt sind, die die Nutzung von Annotationen ermöglichen. Stephan Kleuker

338 In Erprobung/Entwicklung: : Domain Specific Languages
9.9 Problem: General Purpose Sprachen sind sehr mächtig, aber für spezifische Entwicklungsbereiche geht sehr viel Energie in für den Bereich gleichartige Programmierung Spezielle Entwicklungssprache für individuellen Bereich, spezielle komplexe Hochsprachelemente anbietet Neue Sprache z. B. mit XML (Syntax mit XML-Schema) darstellbar; Umwandlung in Programm mit Übersetzung (z. B. XSLT) ; hilfreich ist Visualisierungsmöglichkeit der DSL Hinweis: UML (evtl. mit konkreter Ausprägung) kann mit MDA-Transformationen auch als spezieller DSL-Ansatz angesehen werden Stephan Kleuker

339 DSL Prozesse Stephan Kleuker

340 In Erprobung/Entwicklung: Model Driven Architecture
9.10 Ansatz: Häufig benötigt man die gleichen Ideen (z. B. Sortierverfahren) in sehr unterschiedlichen Sprachen; warum nicht in einer Sprache modellieren und dann in andere Sprachen transformieren? Da Sprachen extrem unterschiedlich, soll Modellumwandlung schrittweise passieren Zur Modellbeschreibung wird eigene Sprache mit eigener Semantik benötigt (Metamodell und Metametamodell) Ansatz: Umwandlung des CIM mit Transformationsregeln in ein PIM und dann ein PSM CIM: Computer Independent Model PIM: Platform Independent Model PSM: Platform Specific Model z. B. UML-Modell, dann Realisierungssprache wählen, dann HW-Plattform mit Kommunikationsprotokollen wählen (zwei parametrisierte Transformationen) Stephan Kleuker

341 Prozess der MDA (Theorie)
Realität: häufig nur eine konkrete Ebene viele manuelle Einstellungen für die Transformation Generieren gibt es schon lange (YACC, Dateien zur Beschreibung von Fenstern, von UML zum Programmskelett) Stephan Kleuker

342 Formaler Hintergrund der MDA
Semantik definiert durch Abarbeitungsreihenfolge konkrete Menge von Regeln mit konkreten Parametern konkretes Modell1 konkretes Modell2 Instanz von Instanz von Instanz von Transformations- regeln Modellart1 Modellart2 Transformations- model Meta Object Faciliy (MOF) Stephan Kleuker

343 Refactoring Komplexe Methoden sollen grundsätzlich vermieden werden
9.11 Komplexe Methoden sollen grundsätzlich vermieden werden Lösungsansatz: Refactoring, d. h. ein Programmblock wird in einer Methode mit selbsterklärendem Namen ausgegliedert Wann ist Ausgliederung möglich? Im Block darf nur eine lokale Variable auf der linken Seite einer Zuweisung stehen Wie funktioniert Refactoring? Bestimme alle lokalen Variablen, die im Block lesend genutzt werden; diese werden zu Parametern Falls eine lokale Variable links in einer Zuweisung vorkommt, bestimmt sie den Rückgabetypen (sonst void) Exemplarvariablen spielen keine Rolle, da auf sie in allen Methoden der Klasse zugegriffen werden darf Probleme bei mehr als einer zu verändernden lokalen Variablen oder bei enthaltenen Rücksprüngen (aufwändig regelbar) Stephan Kleuker

344 Refactoring – Positives Beispiel
public int ref(int x, int y, int z){ int a=0; if(x>0){ a=x; x++; --y; a=a+y+z; } return a; public int ref(int x, int y, int z){ int a=0; if(x>0){ a = mach(x, y, z); } return a; private int mach(int x, int y, int z){ int a; a=x; x++; --y; a=a+y+z; Stephan Kleuker

345 Refactoring – nicht einfaches Beispiel
public int ref2(int x){ int a=0; int b=0; int c=0; if(x>0){ a=x; b=x; c=x; } return a+b+c; Stephan Kleuker

346 Refactoring – (nicht) einfaches Beispiel in C++
int Rechnung::ref2(int x){ int a=0; int b=0; int c=0; if(x>0){ abcAnpassen(a,b,c,x); } return a+b+c; void Rechnung::abcAnpassen(int& a, int& b, int& c, int x){ a=x; b=x; c=x; Stephan Kleuker

347 10. Oberflächengestaltung
10.1 Hintergründe der Oberflächengestaltung 10.2 Konkretisierung des Nutzbarkeitsbegriffs 10.3 Berücksichtigung der Ergonomie im Software-Entwicklungsprozess 10.4 Prüfung der Nutzbarkeit (Arbeitsbereich Usability Engineering ) (U.S. Department of Health and Human Services) Stephan Kleuker

348 Begriff: Ergonomie 10.1 Der Begriff "Ergonomie" setzt sich aus den griechischen Wörtern ergon = Arbeit, Werk und nomos = Gesetz, Regel zusammen. Nach Auffassung der International Ergonomics Association wird unter Ergonomie die Lehre von der menschlichen Arbeit und die Erkenntnis ihrer Gesetzmäßigkeiten verstanden. Laut der offiziellen Definition der internationalen ISO-Norm verwendet Ergonomie wissenschaftliche Erkenntnisse, um Arbeitsaufgaben, Arbeitsumgebungen und Produkte an die physischen und mentalen Fähigkeiten und Grenzen von Menschen anzupassen. Hierbei soll Gesundheit, Sicherheit, Wohlbefinden und Leistungsvermögen verbessert werden. Stephan Kleuker

349 Ergonomie als Schnittstelle der Forschung
Psychologie: In der Gestaltungspsychologie wird u. a. untersucht, welche Wirkungen Farben und Formen haben. Dabei ist zu beachten, dass Fragen im Kontext betrachtet werden müssen. Arbeitswissenschaft: Ein Teil der Arbeitswissenschaften beschäftigt sich mit der ergonomischen Gestaltung von Arbeitsplätzen. Dabei ist eine zentrale Forderung, dass die Arbeitsumgebung und die Arbeitsmittel zur Aufgabe passen. Software ist dabei in vielen Berufen ein zentrales Arbeitsmittel von vielen Personen, die sich nicht mit der Software-Entwicklung beschäftigen. Für diese Personen muss der Zugang zur IT aus ihrer Sicht intuitiv sein. Software-Ergonomie: In der Software-Ergonomie als Informatik-Disziplin beschäftigt man sich mit der Umsetzung der Ideen der vorher genannten Arbeitsgebiete in der Software. Dabei muss als besondere Randbedingung die Realisierbarkeit von gestalterischen Ideen berücksichtigt werden. Stephan Kleuker

350 Psychologie: Beispiel Farbwahl
Farbe Assoziation weiß Reinheit, Unschuld (Asien: Trauer) schwarz Tod, Trauer, Eleganz, Schwere, Ernst grau Neutral, spannungslos blau Geist, Kosmos, Ewigkeit, wirkt kühl, steigert in Kombination die Wirkung warmer Farbtöne rot Dynamik, Aktivität, Wärme, Warnfarbe gelb Anregend, heiter, dynamisch, kalte Farben wirken durch Zusatz von gelb kälter, warme Farben wärmer orange Hohes Maß an Aktivität und Dynamik, erregt Aufmerksamkeit, Warnfarbe violett Ernst, feierlich, je nach Blauanteil kühl oder warm grün Natur, Wachstum, beruhigend (langweilig) Stephan Kleuker

351 Zusammenhang der Normen ISO 9241
10.2 Stephan Kleuker

352 Software-ergonomische Grundsätze der Dialoggestaltung
Leitlinien aus ISO Software-ergonomische Grundsätze der Dialoggestaltung Lernförderlichkeit Fehlertoleranz Erwartungskonformität Aufgabenangemessenheit Selbstbeschreibungsfähigkeit Steuerbarkeit Individualisierbarkeit Stephan Kleuker

353 Praktische Anforderungen:
Lernförderlichkeit Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen des Dialogsystems unterstützt und anleitet. Praktische Anforderungen: Kann der Benutzer sich ohne Hindernisse in die Nutzung des Systems einarbeiten? Kann der Benutzer das System ausprobieren, ohne dafür „bestraft“ zu werden? Begriffe sinnfällig wählen Gleicher Aufbau von Grundstrukturen Stephan Kleuker

354 Praktische Anforderungen: Ist die Software gegen Fehleingaben robust?
Fehlertoleranz Ein System ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand durch den Benutzer erreicht werden kann. Praktische Anforderungen: Ist die Software gegen Fehleingaben robust? Kann der Benutzer Fehlersituationen leicht korrigieren? Werden Vorschläge generiert? Warnung vor folgenschweren Fehlern Keine Werturteile („Unsinnige Eingabe!“) Stephan Kleuker

355 Erwartungskonformität
Ein Dialog ist erwartungskonform, wenn er konsistent ist und den Merkmalen des Benutzers entspricht, z.B. den Kenntnissen aus dem Arbeitsgebiet, der Ausbildung und der Erfahrung sowie allgemein anerkannten Konventionen. Praktische Anforderungen: Reagiert das System so, wie der Benutzer es erwartet? Entsprechen in Menüfolgen die suggerierten Abläufe dem typischen Arbeitsablauf? Kann der Benutzer das Systemverhalten voraussagen? Konsistenz – anwendungsintern und anwendungsübergreifend: Platzierung, wiederkehrende Ablaufschemata, einheitliche Funktionstastenbelegung, Sprache, Screen und Print Stephan Kleuker

356 Aufgabenangemessenheit
Ein System ist aufgabenangemessen, wenn es den Benutzer unterstützt, seine Aufgabe effektiv und effizient zu erledigen. Praktische Anforderungen: Muss der Benutzer unnötige Dialogschritte durchführen? Sind überflüssige / ablenkende Informationen vorhanden, die mit der Aufgabe nichts zu tun haben? Erhält der Benutzer alle gewünschten Ergebnisse? Vorgaben von Standardwerten, wenn sinnvoll Stephan Kleuker

357 Selbstbeschreibungsfähigkeit
Ein Dialog ist selbstbeschreibungsfähig, wenn jeder einzelne Dialogschritt durch Rückmeldung des Systems unmittelbar verständlich ist oder auf Anfrage erklärt wird. Praktische Anforderungen: Sind alle für einen Arbeitsschritt benötigten Informationen übersichtlich am Bildschirm vorhanden? Weiß der Benutzer, was er als nächstes tun kann? Präzise, unmissverständliche und einfache Systemmeldungen weiß der Nutzer, was das System macht? Stephan Kleuker

358 Steuerbarkeit Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist. Praktische Anforderungen: Kann der Benutzer seine Arbeitsschritte so steuern, wie es von seiner Aufgabe her notwendig ist? Reihenfolge der Arbeitsschritte wählbar bei variablen oder dynamischen Aufgaben Kann der Benutzer Arbeitsschritte unterbrechen oder abbrechen, wenn dies erforderlich ist? Kann der Nutzer mit Maus und Tastatur manövrieren? Stephan Kleuker

359 Individualisierbarkeit
Ein Dialog ist individualisierbar, wenn das System Anpassungen an die Erfordernisse der Aufgabe, individuelle Vorlieben und Fähigkeiten des Benutzers zulässt. Praktische Anforderungen: Kann der Benutzer Layout und Funktion des Systems an seine individuellen Anforderungen anpassen? Können eigene Funktionen (z. B. Macros) definiert werden? Stephan Kleuker

360 Anforderungsanalyse aus Usability-Sicht
10.3 SOLL-Prozesse müssen mit dem Kunden und den Endanwendern geklärt werden Vokabular der Kundenprozesse muss definiert sein potenzielle alternative Prozessabläufe müssen bekannt sein Technische Randbedingungen müssen definiert sein Usability (insbesondere Web-Seiten): Welche gewünschten Nutzer haben welche Erfahrungen (Computererfahrung /Alter)? Welche Technologie wird zur Implementierung eingesetzt (Browser, Javascript, ASP, ActiveX, Applets)? [je mehr heterogene Nutzer desto weniger Technik erlaubt] Wie werden erwünschte Nutzer verbunden? [Privat-Nutzer häufiger noch über analoge Modems] Stephan Kleuker

361 Design aus Usability-Sicht
Typischerweise wird SW in Paketen und Schichten entwickelt, meist wird die graphische Oberfläche als eine Schicht in getrennten Paketen entwickelt Ansatz garantiert, dass Darstellung und Inhalt konsequent getrennt werden, einheitliche Darstellung wird erleichtert Ansatz hat Problem, dass die Schnittstelle sehr breit wird, muss frühzeitig abgesprochen werden Entwicklung unterschiedlicher Oberflächenmasken orientiert sich an gewünschten Prozessabläufen (ähnlich zu einem Storyboard im Trickfilm) Gute Oberflächengestaltung ist Designern zu überlassen (die Prozesse verstehen müssen) Stephan Kleuker

362 Integration der Oberflächenentwicklung
Stephan Kleuker

363 Überblick über Usability-Testmethoden
10.4 Expertenzentrierte Methoden heuristische Evaluation Guidelines und Checklisten Nutzerzentrierte Methoden Befragung Task-based Testing / Discount Usability Testing Thinking-Aloud-Tests Kombinationen der genannten Verfahren Stephan Kleuker

364 Heuristische Evaluation
= eine Gruppe von externen Gutachtern untersucht eine Website und überprüft, inwieweit diese mit grundlegenden Prinzipien der Usability (sog. Heuristiken) übereinstimmt. Die individuellen Einschätzungen werden zuerst schriftlich fixiert und danach von der Gutachtergruppe bewertet bzw. eingestuft. Vorteile: konkrete Benennung der einzelnen Defizite Empfehlungen zur Behebung derselben Nachteile: zeitintensiver Einsatz von teuren Experten passende Experten müssen gefunden werden Stephan Kleuker

365 Guidelines und Checklisten
= eine Gruppe von (externen oder internen) Gutachtern untersucht eine SW anhand von Guidelines und Checklisten, in denen Usability-Kriterien zusammengestellt sind. Antwortvorgaben resultieren in Zahlenwerten / Noten. Besonders geeignet für ähnliche Websites. Vorteile: schnell und computergestützt realisierbar Ergebnisse erlauben unterschiedlichste Auswertungen (Abhängigkeiten) Nachteile: stark formalisierte Ergebnisse (Gewichtungen?) Anpassungsbedarf für Einsatzbereich der Seite Stephan Kleuker

366 Nutzerbefragung = mündlich, schriftlich (in Seite integriert, , online-Chat, ...); anhand von standardisierten Fragebögen oder als qualitative Interviews; Zielgruppen sind (potenzielle) Benutzer mögliche Erkenntnisziele: Erwartungen einer Zielgruppe Nutzungsformen und Gründe dafür Vorkenntnisse und Nutzungsverhalten subjektive Erfahrungen von Versuchspersonen Vorteile: viele Einschätzungen einholbar unmittelbarer Kontakt mit Endnutzern Nachteile: Subjektivität der Ergebnisse (wer antwortet warum) mögliche Heterogenität der Ergebnisse Stephan Kleuker

367 Task-based Testing / Discount Usability Testing
= typische Anfragen bzw. Aufgaben werden von für die Zielgruppe typischen Nutzern bearbeitet Die Probanden werden dabei beobachtet, ihre Reaktionen notiert und später evaluiert Vorteile: geringe Anzahl von Testpersonen erbringt schon aussagekräftige Ergebnisse man sieht, wie Ergebnis von anderen genutzt wird Nachteile: Vorkenntnisse und Voreinstellungen der Tester können die Analyse verzerren teilweise schwierige Findung typischer Anfragen Stephan Kleuker

368 Thinking-Aloud-Tests (1/2)
= Personen aus der gewünschten Nutzergruppe bearbeiten ein zumeist vorgegebenes Aufgabenszenario. Während der Bearbeitung sollen sie ihre diesbezüglichen Gedanken und ihr Handeln laut aussprechen bzw. kommentieren. Während des Tests werden in einem sog. Usability- Labor Ton und Bild von der Versuchsperson sowie Kopien des Bildschirminhalts aufgezeichnet. Ergänzend werden mit einem Screenrecorder die Bewegungen auf dem Bildschirm aufgezeichnet. Anschließend werden die Daten zur Bewertung in eine analysierbare Form gebracht. Stephan Kleuker

369 Thinking-Aloud-Tests (2/2)
Vorteile: genaue Daten aus unterschiedlicher Perspektive wenige Probanden ergeben gute Einsichten Nachteile: aufwändige und teure Grundausstattung incl. geschultem Personal nötig Fähigkeit der Testpersonen zur Verbalisierung ihres Handelns und Denkens ist unterschiedlich ggf. ist Spontanität “ausgebremst” (Laborsituation) Vorkenntnisse und Voreinstellungen der Tester können die Analyse verzerren Stephan Kleuker

370 Notwendige Anzahl von Testnutzern
Stephan Kleuker

371 11. Qualitätssicherung 11.1 Formale Korrektheit 11.2 Zusicherungen
11.3 Unit-Tests 11.4 Testbarkeit von Systemen herstellen 11.5 Äquivalenzklassentests 11.6 Kontrollflussbezogene Testverfahren 11.7 Testarten und Testumfeld 11.8 Metriken 11.9 Konstruktive Qualitätssicherung Manuelle Prüfverfahren Stephan Kleuker

372 Korrektheit 11.1 Korrekt bedeutet: Unter folgenden Vorbedingungen sollen die Ergebnisse des Programms folgende Nachbedingungen erfüllen Wunsch alles zu testen meist nicht erfüllbar public static boolean impliziert(boolean a, boolean b){ return !a || b; } public static void main(String[] args) { // Tests boolean werte[]={true,false}; for(boolean a:werte) for(boolean b:werte) System.out.println("a="+a+" b="+b +" liefert "+impliziert(a,b)); Tests sollen möglichst viele möglichst kritische Fehler finden können Stephan Kleuker

373 Ansatz: Model Checking
Idee: Gegeben ist ein Modell (oder Spezifikation) und eine Anforderung, dann überprüft der Model-Checking-Algorithmus, ob das Modell die Anforderung erfüllt oder nicht. Falls das Modell die Anforderung nicht erfüllt, sollte der Algorithmus ein Gegenbeispiel liefern Theoretisches Ergebnis: Generell gibt es so ein Verfahren nicht (unentscheidbar), man muss Modellierungssprache und Anforderungslogik einschränken Ansatz: Berechne alle erreichbaren Zustände und analysiere sie Beispiel: SPIN entwickelt von Gerard Holzmann, zunächst als Simulator, dann Verifikationswerkzeug (www.spinroot.com) Stephan Kleuker

374 Assertions in JDK ab Version 1.4
11.2 Sprachänderung neues Keyword assert Erweiterung des java.lang-Pakets java.lang.AssertionError Neue Dokumentation unter Guide to Features unter Assertion Facility unter javadoc doc/guide/lang/assert.html Compiler-Option –source 1.4 javac –source 1.4 Klasse.java damit javac assert akzeptiert Interpreter-Option –ea java –ea Klasse Stephan Kleuker

375 Syntax und Semantik von assert
assert überprüft zur Laufzeit eine Zusicherung, ist diese nicht erfüllt, wird ein AssertionError ausgelöst public void (int a, int b){ assert a>b && exemplar>5; ... } Syntax: assert <Boolescher_Ausdruck> assert <Boolescher_Ausdruck>:<bel_Objekt> <bel_Objekt> ist meist ein String, der bei der Fehlermeldung mit angezeigt wird Stephan Kleuker

376 Kostenregel Zusicherungen sollen nichts kosten, wenn sie ausgeschaltet sind [nicht immer zu 100% möglich]. Falsch: private static double EPS= ; public static double sqrt(double par) { double res = Math.sqrt( par ); boolean test = Math.abs(par -res *res) < EPS; assert test; return res; } Richtig: assert Math.abs( par - res * res ) < EPS; Stephan Kleuker

377 Vorbedingungsregel nur interne Vorbedingungen mit assert prüfen, die bei korrekter Software erfüllt sein müssten kein Ersatz für Ausnahmen Beispiel: public double sqrt(double param) { if ( param < 0 ) throw new IllegalArgumentException("Negativer Parameter"); return Math.sqrt( param ); } Nicht als zweite Zeile: assert param >= 0; deswegen AssertionError und nicht AssertionException Assertions dürfen nur in der Entwicklung zu Fehlern führen Stephan Kleuker

378 Nachbedingungen lassen sich immer mit assert beschreiben
Nachbedingungsregel Nachbedingungen lassen sich immer mit assert beschreiben Typisch stehen Nachbedingungen unmittelbar vor jedem return-Statement oder der abschließenden geschweiften Klammer Beispiel private static double EPS= ; public static double sqrt(double par) { double res = Math.sqrt( par ); assert Math.abs( par - res * res ) < EPS; return res; } Stephan Kleuker

379 Invariantenregel Invarianten von Objekten werden nach außen nie verletzt (bei internen Berechnungen erlaubt) Ansatz: Invariante wird als eigenständige Methode implementiert private boolean invariant(...){ boolean erg = <Invariantenberechnung>; return erg; } Überprüfung der Invariante assert invariant(...); am Ende eines jeden Konstruktors am Anfang jeder public-Methode am Ende jeder public-Methode Stephan Kleuker

380 Fehlermöglichkeiten mit assert
while (iter.hasNext()) { assert iter.next() != null; do_something( iter.next() ); } public class Stack { int size = 0; ... public int length() { assert this.length() >= 0; return size; } // length } // Stack Stephan Kleuker

381 Framework, um den Unit-Test eines Java-Programms zu automatisieren
JUnit 11.3 Framework, um den Unit-Test eines Java-Programms zu automatisieren einfacher Aufbau leicht erlernbar geht auf SUnit (Smalltalk) zurück mittlerweile für viele Sprachen verfügbar Stephan Kleuker

382 Idee ist inkrementeller Aufbau der Testfälle parallel zur Entwicklung
Konstruktiver Ansatz Testfälle werden in Java programmiert, keine spezielle Skriptsprache notwendig Idee ist inkrementeller Aufbau der Testfälle parallel zur Entwicklung Pro Klasse wird mindestens eine Test-Klasse implementiert JUnit ist in Entwicklungsumgebungen integriert, sonst muss das Paket junit.jar zu CLASSPATH hinzugefügt werden Stephan Kleuker

383 Testmethoden haben typischerweise keinen Rückgabewert (nicht verboten)
Testen mit JUnit Tests werden mit Methoden durchgeführt, die mit markiert sind Testmethoden haben typischerweise keinen Rückgabewert (nicht verboten) Tests stehen typischerweise in eigener Klasse; für Klasse X eine Testklasse XTest (können auch in zu testender Klasse stehen) Mit Klassenmethoden der Klasse Assert werden gewünschte Eigenschaften geprüft Assert.assertTrue("korrekter Vorname" ,m.getVorname().equals("Ute")); JUnit steuert Testausführung, Verstöße bei Prüfungen werden protokolliert Stephan Kleuker

384 Assert (1/2) Die Klasse Assert definiert eine Menge von assertXY Methoden, welche die Testklassen erben. Mit den assertXY Methoden können unterschiedliche Behauptungen über den zu testenden Code aufgestellt werden. Trifft eine Behauptung nicht zu, wird ein Testfehler protokolliert. assertTrue (boolean condition) verifiziert, ob einen Bedingung wahr ist. assertEquals(Object expected, Object actual) verifiziert, ob zwei Objekte gleich sind. Der Vergleich erfolgt mit der equals Methode. assertEquals(int expected, int actual) verifiziert, ob zwei ganze Zahlen gleich sind. Der Vergleich erfolgt mit dem == -Operator. assertNull(Object object) verifiziert, ob einen Objektreferenz null ist. Stephan Kleuker

385 Assert (2/2) assertEquals(double expected, double actual, double delta) verifiziert, ob zwei Fließkommazahlen gleich sind. Da Fließkommazahlen nicht mit unendlicher Genauigkeit verglichen werden können, kann mit delta ein Toleranzwert angegeben werden. assertNotNull(Object object) verifiziert, ob eine Objektreferenz nicht null ist. assertSame(Object expected, Object actual) verifiziert, ob zwei Referenzen auf das gleiche Objekt verweisen. Für die primitiven Datentypen float, long, boolean, byte, char und short existieren ebenfalls assertEquals Methoden. Jede Assert-Methode gibt es mit einem zusätzlichen ersten Parameter vom Typ String, dieser String wird zum Fehler ausgegeben (also sinnvoll diese Methoden zu nutzen) Stephan Kleuker

386 Assert-Methoden haben optionalen ersten String-Parameter
Anmerkungen keine gute Idee: mehrere Asserts hintereinander (scheitert das Erste, wird Zweite nicht betrachtet -> Tests trennen) Assert-Methoden haben optionalen ersten String-Parameter String kann genauere Informationen über erwartete Werte enthalten, z. B. über toString-Methoden der beteiligten Objekte generell reicht Assert.assertTrue() aus, gibt viele weitere Methoden Um nicht immer die Klasse Assert vor Methoden angeben zu müssen, kann man auch (persönlich unschön) folgendes nutzen: import static org.junit.Assert.*; Stephan Kleuker

387 Menge von Testobjekten heißt Test-Fixture
Testfall sieht in der Regel so aus, dass eine bestimmte Konfiguration von Objekten aufgebaut wird, gegen die der Test läuft Menge von Testobjekten heißt Test-Fixture Damit fehlerhafte Testfälle nicht andere Testfälle beeinflussen können, wird die Test-Fixture für jeden Testfall neu initialisiert In der annotierten Methode werden Exemplarvariablen initialisiert In der annotierten Methode werden wertvolle Testressourcen wie zum Beispiel Datenbank- oder Netzwerkverbindungen wieder freigegeben Software-Qualität

388 Exceptions in Java mit catch Block behandelt
Testen von Exceptions Exceptions in Java mit catch Block behandelt Mit der Methode fail aus der Assert Klasse wird ein Testfehler ausgelöst und protokolliert Im Beispiel wird beim Aufruf des Konstruktors der Klasse MyClass mit einer negativen Zahl die IllegalArgumentException ausgelöst @Test public void testNegativeInitialisierung() { try { new MyClass(-10); fail("Meine Meldung im Fehlerfall"); }catch (IllegalArgumentException e) {} } Stephan Kleuker

389 Zu testende Klasse (1/2) package kapitel11_Rabatt;
public class Rabatt { private double rabatt; private boolean gesperrt; public Rabatt(double rabatt, boolean gesperrt) { this.rabatt = rabatt; this.gesperrt = gesperrt; } public boolean isGesperrt() { return this.gesperrt; public void setGesperrt(boolean gesperrt) { Stephan Kleuker

390 Zu testende Klasse (2/2) public double getRabatt() { return rabatt; }
public void setRabatt(double rabatt) { this.rabatt = rabatt; double preis(double ursprungspreis) throws RabattException{ if(this.gesperrt) throw new RabattException(); return ursprungspreis*(1-(rabatt/100)); package kapitel11_Rabatt; public class RabattException extends Exception {} Stephan Kleuker

391 Testfälle (1/3) package kapitel11_Rabatt; // imports fehlen
public class RabattTest { private Rabatt gut; private Rabatt boese; @Before protected void setUp() throws Exception { super.setUp(); gut = new Rabatt(3.0,false); boese = new Rabatt(0.0,true); } @Test public void testGetRabatt(){ assertTrue(3.0 == gut.getRabatt()); assertTrue(0.0 == boese.getRabatt()); Stephan Kleuker

392 Testfälle (2/3) @Test public void testSetRabatt(){
gut.setRabatt(17.0); assertTrue(17.0 == gut.getRabatt()); } public void testIsGesperrt(){ assertTrue(!gut.isGesperrt()); assertTrue(boese.isGesperrt()); public void testSetGesperrt(){ gut.setGesperrt(true); boese.setGesperrt(false); assertTrue(gut.isGesperrt()); assertTrue(!boese.isGesperrt()); Stephan Kleuker

393 Testfälle (3/3) @Test public void testPreisErfolgreich(){ try {
double ergebnis=gut.preis(100.0); assertEquals(ergebnis,97.0,0.001); } catch (RabattException e) { fail("falsche RabattException"); } public void testPreisMitException(){ boese.preis(100.0); fail("fehlende RabattException"); public static void main(String[] args) { junit.swingui.TestRunner.run(RabattTest.class); Stephan Kleuker

394 Für große Projekte sind folgende Wünsche bzgl. der Tests typisch:
TestSuite Für große Projekte sind folgende Wünsche bzgl. der Tests typisch: mehrere Testklassen sollen zusammen laufen können man möchte Tests flexibel kombinieren können; Testwiederholung soll davon abhängen, welche Klassen betroffen sein können [schwierige Weissagung] man möchte Tests automatisiert ablaufen lassen können möglich z. B.: JUnit hat Klassen zum einfachen Start von der Konsole aus Nutzung eines cron-Jobs zu a) und b) TestSuite in JUnit Stephan Kleuker

395 Vergleich von JUnit und Assertions
Assertions werden vom Entwickler eingesetzt um Vor- und Nachbedingungen, sowie Invarianten zu beschreiben Assertions können auch innerhalb von Methoden für lokale Zustandsüberprüfungen eingesetzt werden Assertions werden tief in der Programmstruktur eingesetzt, JUnit schaut auf die Schnittstellen der Klassen von außen JUnit ist sehr mächtig, da nicht nur einzelne Klassen, sondern auch die Zusammenarbeit von Klassen geprüft werden kann (der Name „Unit“ ist eher irreführend) Es spricht nichts dagegen, Assertions und JUnit zusammen einzusetzen Stephan Kleuker

396 Klassen testbar machen
11.4 Bei Objekten mit internen Zuständen ist der Test von außen mit JUnit sehr schwierig es ist oftmals hilfreich, zusätzliche Methoden zu implementieren, die das Testen einfacher machen public String getInternenZustand(){ return "..." } Häufiger reicht ein get für den internen Zustand nicht aus, es muss Methoden geben, mit denen man ein Objekt von außen in einen gewünschten Zustand versetzen kann (Ergänzung weiterer Testmethoden) Im Quellcode sollen Testmethoden eindeutig von anderen Methoden getrennt sein, damit sie ggfls. automatisch gelöscht werden können Bei komplexeren Klassen sollte man Teile der Entwicklung bereits testen, hierzu müssen die aufgerufenen Methoden zumindest in minimaler Form implementiert werden Stephan Kleuker

397 Zusammenspiel von Klassen testen
Bis jetzt wurde nur eine Klasse betrachtet, die keine Assoziation zu anderen zu testenden Klassen hat, diese Klassen werden elementare Klassen genannt Grundsätzlich sollte man versuchen, zunächst elementare Klassen und dann Klassen, die auf diesen aufbauen, zu Testen Da es in der Entwicklung nicht garantiert werden kann, wann Klassen vorliegen, muss man sich häufiger mit einem Trick behelfen Dieser Trick ist es, die benötigte Klasse soweit selbst zu implementieren, dass man die eigene Klasse testen kann. Diese Klasse wird Mock genannt. Die Grundregel lautet, den Mock so primitiv wie möglich zu halten Liegt die Klasse vor, die man temporär durch den Mock prüfen wollte, müssen diese Tests mit der realen Klasse wiederholt werden Stephan Kleuker

398 Mocks programmieren Es wird zunächst eine Klasse mit den notwendigen Methoden implementiert, die alle die leere Implementierung oder die Rückgabe eines Dummy-Werts enthalten public void setParameter(int parameter){} public int getParameter() { return 0;} Diese Implementierung wird soweit ergänzt, dass wir unsere Klasse testen können (möglichst einfache Fallunterscheidungen, man bedenke, dass man von der Korrektheit der anderen Klasse ausgeht) Es gibt Werkzeuge, die die einfachst möglichen Mocks automatisch generieren, die können dann ergänzt werden D. h., neben den Tests entsteht ein zusätzlicher Codieraufwand für Mocks, in größeren (erfolgreichen) Projekten kann der Anteil des Testcodes am Gesamtcode in Abhängigkeit von der Komplexität des Systems zwischen 30% und 70% liegen! Stephan Kleuker

399 Beispiel für Mock-Erstellung (1/4)
public class Buchung { public static LogDatei logging; ... public synchronized void abbuchen(int id, Konto konto, int betrag) throws BuchungsException{ if(konto.istLiquide(betrag)){ konto.abbuchen(betrag); logging.schreiben(id+ " bearbeitet"); } else{ logging.schreiben(id +" abgebrochen, insolvent"); throw new BuchungsException("insolvent"); Zum Test der Methode abbuchen werden Test-Mocks der Klassen Konto und LogDatei benötigt, Ziel ist es möglichst einfache Mocks zu schreiben Stephan Kleuker

400 Beispiel für Mock-Erstellung (2/4)
Mock für LogDatei (wahrscheinlich) einfach public class LogDatei { // Mock für Buchung public void schreiben(String s){} } Für Konto verschiedene Varianten denkbar, wichtig für unsere Tests, dass istLiquide() true und false zurück geben kann public class Konto { //Mock für Buchung public boolean istLiquide(int betrag){ if( betrag < 1000) return true; return false; public void abbuchen(int betrag){} In dieser Variante muss sich der Tester den Schwellenwert zur Prüfung merken (Mocks müssen auch getestet werden) Stephan Kleuker

401 Beispiel für Mock-Erstellung (3/4)
public class BuchungTest {//nutzen private Konto konto; private Buchung buchung; @Before protected void setUp() throws Exception { Buchung.logging= new LogDatei(); buchung= new Buchung(); konto= new Konto(); } @After protected void tearDown() throws Exception { // logging schließen} @Test public void testErfolreicheBuchung(){ try { buchung.abbuchen(42,konto,100); } catch (BuchungsException e) { fail(); Stephan Kleuker

402 Beispiel für Mock-Erstellung (4/4)
@Test public void testErfolgloseBuchung(){ try { buchung.abbuchen(42,konto,2000); fail(); } catch (BuchungsException e) { } }... Die Tests des Mocks gehören in eine eigene Testklasse, da sie später bei einer Testwiederholung für eine vollständige Implementierung nicht wiederholt werden Werden kompliziertere Mock-Eigenschaften verlangt, sollte die Klasse generell spezielle Konstruktoren oder Methoden zum Setzen des internen Zustands beinhalten In Coding-Guidelines ist auf das Ziel der Testbarkeit hinzuweisen, Programmierer müssen die internen Zustände ihrer Klassen zu Testzwecken sichtbar machen Stephan Kleuker

403 Vererbung - Test von Unterklassen
Tests einer Unterklasse C’ (einer Oberklasse C) sind durchzuführen für alle neuen Methoden: neue Testfälle aufstellen und ausführen für alle redefinierten Methoden: neue Testfälle aufstellen und ausführen; semantisch ähnliche Programm(teil)e müssen unterschiedlichen Tests unterzogen werden für alle geerbten Methoden: müssen alle Testfälle der Klasse C erneut durchgeführt werden; Kontext der Unterklasse ist anders, erneuter Test daher notwendig nach : E. Perry, G. E. Kaiser, Adequate Testing and Object-Oriented Programming. Journal of Object-Oriented Programming, Vol. 2, No. 5, Seiten 13-19 Stephan Kleuker

404 Klassen von Testfällen
11.5 In der Literatur gibt es recht unterschiedlich detaillierte Klassifizierungen von Testfällen, eine erste grobe Einteilungsmöglichkei