Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Grundkurs Software-Engineering mit UML1Stephan Kleuker Grundkurs Software-Engineering mit UML Konzepte für die erfolgreiche Software- Entwicklung Prof.

Ähnliche Präsentationen


Präsentation zum Thema: "Grundkurs Software-Engineering mit UML1Stephan Kleuker Grundkurs Software-Engineering mit UML Konzepte für die erfolgreiche Software- Entwicklung Prof."—  Präsentation transkript:

1 Grundkurs Software-Engineering mit UML1Stephan Kleuker 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

2 Grundkurs Software-Engineering mit UML2Stephan Kleuker 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

3 Grundkurs Software-Engineering mit UML3Stephan Kleuker 1. Motivation von Software- Engineering

4 Grundkurs Software-Engineering mit UML4Stephan Kleuker 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

5 Grundkurs Software-Engineering mit UML5Stephan Kleuker 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

6 Grundkurs Software-Engineering mit UML6Stephan Kleuker 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 –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)

7 Grundkurs Software-Engineering mit UML7Stephan Kleuker 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 (http://www.uml.org/)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 (!?)

8 Grundkurs Software-Engineering mit UML8Stephan Kleuker 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 …

9 Grundkurs Software-Engineering mit UML9Stephan Kleuker 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

10 Grundkurs Software-Engineering mit UML10Stephan Kleuker 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.

11 Grundkurs Software-Engineering mit UML11Stephan Kleuker 2. Prozessmodellierung 2.1 Unternehmensprozesse 2.2 Prozessmodellierung mit Aktivitätsdiagrammen 2.3 Risikomanagement

12 Grundkurs Software-Engineering mit UML12Stephan Kleuker Unternehmensführung Unterstützung Controlling Vertrieb Projektmanagement Umfeld von SW-Projekten SW-Projekt 2.1

13 Grundkurs Software-Engineering mit UML13Stephan Kleuker 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

14 Grundkurs Software-Engineering mit UML14Stephan Kleuker 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

15 Grundkurs Software-Engineering mit UML15Stephan Kleuker 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

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

17 Grundkurs Software-Engineering mit UML17Stephan Kleuker 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

18 Grundkurs Software-Engineering mit UML18Stephan Kleuker 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

19 Grundkurs Software-Engineering mit UML19 Anmerkungen Stephan Kleuker 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

20 Grundkurs Software-Engineering mit UML20Stephan Kleuker 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

21 Grundkurs Software-Engineering mit UML21Stephan Kleuker Beispiel: Vertrieb (2/4)

22 Grundkurs Software-Engineering mit UML22Stephan Kleuker 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

23 Grundkurs Software-Engineering mit UML23Stephan Kleuker Beispiel: Vertrieb (4/4)

24 Grundkurs Software-Engineering mit UML24Stephan Kleuker 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

25 Grundkurs Software-Engineering mit UML25Stephan Kleuker 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

26 Grundkurs Software-Engineering mit UML26Stephan Kleuker Prozessverfeinerung: Kosten kalkulieren Anmerkung: Verantwortliche weggelassen, da immer Projekt- begleiter der Fachabteilung

27 Grundkurs Software-Engineering mit UML27 Nutzung von Schwimmbahnen (für Rollen) Stephan Kleuker

28 Grundkurs Software-Engineering mit UML28Stephan Kleuker 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

29 Grundkurs Software-Engineering mit UML29Stephan Kleuker 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 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,

30 Grundkurs Software-Engineering mit UML30Stephan Kleuker 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 )

31 Grundkurs Software-Engineering mit UML31Stephan Kleuker Risikomanagement

32 Grundkurs Software-Engineering mit UML32Stephan Kleuker 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

33 Grundkurs Software-Engineering mit UML33Stephan Kleuker 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

34 Grundkurs Software-Engineering mit UML34Stephan Kleuker 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

35 Grundkurs Software-Engineering mit UML35Stephan Kleuker 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

36 Grundkurs Software-Engineering mit UML36Stephan Kleuker Herausforderungen der SW-Entwicklung 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 Systeme an anderen Standorten Legacy Systeme Systeme anderer Anbieter eigene Komponenten neues System ?? ? ? ? 3.1

37 Grundkurs Software-Engineering mit UML37Stephan Kleuker 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

38 Grundkurs Software-Engineering mit UML38Stephan Kleuker Wasserfallmodell Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration 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 3.2

39 Grundkurs Software-Engineering mit UML39Stephan Kleuker Prototypische Entwicklung 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 Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration Anforderungs- analyse Grobdesign Feindesign Implemen- tierung Test und Integration Prototyp 3.3

40 Grundkurs Software-Engineering mit UML40Stephan Kleuker Iterative Entwicklung 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 3.4

41 Grundkurs Software-Engineering mit UML41Stephan Kleuker Iterativ Inkrementelle Entwicklung (State of the Art) 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 3.5

42 Grundkurs Software-Engineering mit UML42Stephan Kleuker Fertigstellung mit Iterationen

43 Grundkurs Software-Engineering mit UML43Stephan Kleuker Bekanntheit von Vorgehensmodellen (1/2) Quelle: Softwareentwicklung läuft nicht auf Zuruf, Computer Zeitung Nr. 46/05

44 Grundkurs Software-Engineering mit UML44 Bekanntheit von Vorgehensmodellen (2/2) Stephan Kleuker

45 Grundkurs Software-Engineering mit UML45Stephan Kleuker Struktur komplexer Vorgehensmodelle 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) 3.6

46 Grundkurs Software-Engineering mit UML46Stephan Kleuker Validierung allgemeines V-Modell Anmerkung: wird iterativ / inkrementell zum W-Modell Anforderungs- definition Funktionaler Systementwurf Technischer Systementwurf Komponenten- Spezifikation Programmierung Komponenten- test Integrations- test System- test Abnahme- test manuelle Prüfung manuelle Prüfung manuelle Prüfung manuelle Prüfung KonstruktionIntegration Validierung

47 Grundkurs Software-Engineering mit UML47Stephan Kleuker V-Modell des Bundes 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) 3.7

48 Grundkurs Software-Engineering mit UML48Stephan Kleuker Struktur des V-Modell XT für V-Modell XT-Informationen: Copyright Reserved © Bundesrepublik Deutschland

49 Grundkurs Software-Engineering mit UML49Stephan Kleuker 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

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

51 Grundkurs Software-Engineering mit UML51Stephan Kleuker Beispiel: Projektdurchführungsplan (Systementwicklungsprojekt eines Auftraggebers (AG))

52 Grundkurs Software-Engineering mit UML52Stephan Kleuker Beispielaktivität: Anforderungen festlegen

53 Grundkurs Software-Engineering mit UML53Stephan Kleuker Rational Unified Process (RUP) aus IBM/Rational: Rational Unified Process 3.8

54 Grundkurs Software-Engineering mit UML54Stephan Kleuker 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

55 Grundkurs Software-Engineering mit UML55Stephan Kleuker Struktur des RUP

56 Grundkurs Software-Engineering mit UML56Stephan Kleuker Kritik an klassischen Vorgehensmodellen 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) 3.9

57 Grundkurs Software-Engineering mit UML57Stephan Kleuker 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)

58 Grundkurs Software-Engineering mit UML58Stephan Kleuker 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)

59 Grundkurs Software-Engineering mit UML59Stephan Kleuker 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

60 Grundkurs Software-Engineering mit UML60Stephan Kleuker Scrum (1/2) (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 3.10

61 Grundkurs Software-Engineering mit UML61Stephan Kleuker 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:

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

63 Grundkurs Software-Engineering mit UML63Stephan Kleuker Ideen des Extreme Programming (XP) (1/3) 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 3.11

64 Grundkurs Software-Engineering mit UML64Stephan Kleuker 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

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

66 Grundkurs Software-Engineering mit UML66Stephan Kleuker 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

67 Grundkurs Software-Engineering mit UML67Stephan Kleuker 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

68 Grundkurs Software-Engineering mit UML68Stephan Kleuker 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.

69 Grundkurs Software-Engineering mit UML69Stephan Kleuker 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.

70 Grundkurs Software-Engineering mit UML70Stephan Kleuker 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 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. ProAuto

71 Grundkurs Software-Engineering mit UML71Stephan Kleuker so nicht (4/4): so doch, Geschäftsprozessanalyse

72 Grundkurs Software-Engineering mit UML72Stephan Kleuker Aufgabe der Anforderungsanalyse 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 4.1

73 Grundkurs Software-Engineering mit UML73Stephan Kleuker 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

74 Grundkurs Software-Engineering mit UML74Stephan Kleuker 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

75 Grundkurs Software-Engineering mit UML75Stephan Kleuker 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

76 Grundkurs Software-Engineering mit UML76Stephan Kleuker 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

77 Grundkurs Software-Engineering mit UML77Stephan Kleuker Regeln für die Definition von Zielen Hinweis: Ziele sind abstrakte Top-Level-Anforderungen 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

78 Grundkurs Software-Engineering mit UML78Stephan Kleuker Schablone zur Zielbeschreibung ZielWas soll erreicht werden? StakeholderWelche 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ängigkeitenIst 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. SonstigesWas muss organisatorisch beachtet werden?

79 Grundkurs Software-Engineering mit UML79Stephan Kleuker 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.

80 Grundkurs Software-Engineering mit UML80Stephan Kleuker Ziele für eine Projektmanagementsoftware (1/3) Ziel 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.

81 Grundkurs Software-Engineering mit UML81Stephan Kleuker Ziele für eine Projektmanagementsoftware (2/3) Ziel 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.

82 Grundkurs Software-Engineering mit UML82Stephan Kleuker Ziele für eine Projektmanagementsoftware (3/3) Ziel 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.

83 Grundkurs Software-Engineering mit UML83Stephan Kleuker 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

84 Grundkurs Software-Engineering mit UML84Stephan Kleuker Überblick über den Analyseprozess 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 4.2

85 Grundkurs Software-Engineering mit UML85Stephan Kleuker 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)

86 Grundkurs Software-Engineering mit UML86Stephan Kleuker 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

87 Grundkurs Software-Engineering mit UML87Stephan Kleuker 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

88 Grundkurs Software-Engineering mit UML88Stephan Kleuker 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

89 Grundkurs Software-Engineering mit UML89Stephan Kleuker 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

90 Grundkurs Software-Engineering mit UML90Stephan Kleuker Systematische Use-Case Ermittlung (1/2) 1.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 2.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

91 Grundkurs Software-Engineering mit UML91Stephan Kleuker Systematische Use-Case Ermittlung (2/2) 3.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 4.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

92 Grundkurs Software-Engineering mit UML92Stephan Kleuker Abgeleitetes Use Case-Diagramm

93 Grundkurs Software-Engineering mit UML93Stephan Kleuker 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?

94 Grundkurs Software-Engineering mit UML94Stephan Kleuker Verfeinerung der Use Case-Dokumentation 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 4.3

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

96 Grundkurs Software-Engineering mit UML96Stephan Kleuker Dokumentationsschablone für Use Cases (2/3) Fachverant- wortlicher 1wer steht auf fachlicher Seite für Fragen zum Use Case zur Verfügung und entscheidet auf Auftraggeberseite für die Software über den Inhalt Referenzen2Nennung 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 2was muss erfüllt sein, damit der Use Case starten kann Nachbedin- gungen 2wie sieht das mögliche Ergebnis aus, im nächsten Schritt sind auch die Ergebnisse alternativer Abläufe zu berücksichtigen typischer Ablauf 2welche einzelnen Schritte werden im Use Case durchlaufen, dabei wird nur der gewünschte typische Ablauf dokumentiert alternative Abläufe 3welche Alternativen existieren zum typischen Ablauf

97 Grundkurs Software-Engineering mit UML97Stephan Kleuker Dokumentationsschablone für Use Cases (3/3) Kritikalität3wie wichtig ist diese Funktionalität für das Gesamtsystem Verknüpfungen3welche Zusammenhänge bestehen zu anderen Use Cases funktionale Anforderungen 4welche konkreten funktionalen Anforderungen werden aus diesem Use Case abgeleitet nicht- funktionale Anforderungen 4welche 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

98 Grundkurs Software-Engineering mit UML98Stephan Kleuker Beispielbeschreibung (1/2) Name des Use Case Projektstruktur bearbeiten NummerU1 Paket- AutorAli Analytiker Version1.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) ReferenzenHandbuch zur Führung von Projekten des Kunden

99 Grundkurs Software-Engineering mit UML99Stephan Kleuker 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 Ablauf1. Nutzer wählt Funktionalität zur Bearbeitung von Projektstrukturen 2. Nutzer legt Projekt mit Projektstandarddaten an 3. Nutzer ergänzt neue Teilprojekte 4. Nutzer verlässt Funktionalität alternative Abläufe Nutzer kann existierendes Projekt auswählen, Nutzer kann Daten eines Teilprojekts ändern Kritikalitätsehr hoch, System macht ohne Funktionalität keinen Sinn

100 Grundkurs Software-Engineering mit UML100Stephan Kleuker 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!

101 Grundkurs Software-Engineering mit UML101Stephan Kleuker 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

102 Grundkurs Software-Engineering mit UML102Stephan Kleuker 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 > stehen so genannte Steoreotypen, mit denen man UML-Elementen zusätzliche Eigenschaften zuordnen kann AB >

103 Grundkurs Software-Engineering mit UML103Stephan Kleuker Beispiel zu >

104 Grundkurs Software-Engineering mit UML104Stephan Kleuker > 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

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

106 Grundkurs Software-Engineering mit UML106Stephan Kleuker 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

107 Grundkurs Software-Engineering mit UML107Stephan Kleuker 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.

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

109 Grundkurs Software-Engineering mit UML109Stephan Kleuker Aktivitätsdiagramm um Alternativen ergänzt

110 Grundkurs Software-Engineering mit UML110Stephan Kleuker Erinnerung: Modellierung aus Business-Sicht

111 Grundkurs Software-Engineering mit UML111Stephan Kleuker Modellierung aus System-Sicht

112 Grundkurs Software-Engineering mit UML112Stephan Kleuker Formulierung von Anforderungen 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 4.4

113 Grundkurs Software-Engineering mit UML113Stephan Kleuker 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

114 Grundkurs Software-Engineering mit UML114Stephan Kleuker 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

115 Grundkurs Software-Engineering mit UML115Stephan Kleuker 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?

116 Grundkurs Software-Engineering mit UML116Stephan Kleuker 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?

117 Grundkurs Software-Engineering mit UML117Stephan Kleuker 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

118 Grundkurs Software-Engineering mit UML118Stephan Kleuker Generalisierung durch Universalquantoren 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!

119 Grundkurs Software-Engineering mit UML119Stephan Kleuker 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?

120 Grundkurs Software-Engineering mit UML120 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 Grundkurs Software-Engineering mit UML121 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 Grundkurs Software-Engineering mit UML122Stephan Kleuker 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?

123 Grundkurs Software-Engineering mit UML123Stephan Kleuker 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

124 Grundkurs Software-Engineering mit UML124Stephan Kleuker 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

125 Grundkurs Software-Engineering mit UML125Stephan Kleuker 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?

126 Grundkurs Software-Engineering mit UML126Stephan Kleuker Visualisierung der Systemaktivitäten

127 Grundkurs Software-Engineering mit UML127Stephan Kleuker Anforderungsformulierung (Rupp-Schablone) muss soll wird das System - die Möglichkeit bieten fähig sein 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

128 Grundkurs Software-Engineering mit UML128Stephan Kleuker Typ 1: Selbständige Systemaktivität muss soll wird das System - die Möglichkeit bieten fähig sein 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.

129 Grundkurs Software-Engineering mit UML129Stephan Kleuker Typ 2: Benutzerinteraktion muss soll wird das System - die Möglichkeit bieten fähig sein 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.

130 Grundkurs Software-Engineering mit UML130Stephan Kleuker Typ 3: Schnittstellenanforderung muss soll wird das System - die Möglichkeit bieten fähig sein 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 … )

131 Grundkurs Software-Engineering mit UML131Stephan Kleuker 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

132 Grundkurs Software-Engineering mit UML132Stephan Kleuker Beispielübersetzung

133 Grundkurs Software-Engineering mit UML133Stephan Kleuker Nicht-funktionale Anforderungen (1/2) [sehr kurz] 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 4.5

134 Grundkurs Software-Engineering mit UML134Stephan Kleuker 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

135 Grundkurs Software-Engineering mit UML135Stephan Kleuker Lastenheft / Pflichtenheft 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 4.6

136 Grundkurs Software-Engineering mit UML136Stephan Kleuker Lastenheft / Pflichtenheft: möglicher Aufbau 0. Administrative Daten: von wem, wann genehmigt, 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)

137 Grundkurs Software-Engineering mit UML137Stephan Kleuker 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

138 Grundkurs Software-Engineering mit UML138Stephan Kleuker Systemarchitektur 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 5.1

139 Grundkurs Software-Engineering mit UML139Stephan Kleuker Beispiel: Projektstrukturplan 5.2

140 Grundkurs Software-Engineering mit UML140Stephan Kleuker 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

141 Grundkurs Software-Engineering mit UML141Stephan Kleuker 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)

142 Grundkurs Software-Engineering mit UML142Stephan Kleuker 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

143 Grundkurs Software-Engineering mit UML143Stephan Kleuker 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.

144 Grundkurs Software-Engineering mit UML144Stephan Kleuker 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.

145 Grundkurs Software-Engineering mit UML145Stephan Kleuker 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)

146 Grundkurs Software-Engineering mit UML146Stephan Kleuker 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

147 Grundkurs Software-Engineering mit UML147Stephan Kleuker UML-Notation Assoziationen: Beziehung zwischen Klassen Rollenname am Ende entspricht Exemplarvariablennamen Multiplizitäten von..bis, * für beliebig, alternativ 0..* statt *

148 Grundkurs Software-Engineering mit UML148Stephan Kleuker Zusammenhang Klasse und Objekt Objekte lassen sich auch in der UML darstellen Kasten mit unterstrichenem : vor Doppelpunkt kann Objektname stehen Objekte werden nicht im Klassendiagramm dargestellt

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

150 Grundkurs Software-Engineering mit UML150Stephan Kleuker Zweite Iteration: Methoden suchen 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) 5.3

151 Grundkurs Software-Engineering mit UML151Stephan Kleuker 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.

152 Grundkurs Software-Engineering mit UML152Stephan Kleuker 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)

153 Grundkurs Software-Engineering mit UML153Stephan Kleuker 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

154 Grundkurs Software-Engineering mit UML154Stephan Kleuker 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

155 Grundkurs Software-Engineering mit UML155Stephan Kleuker 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

156 Grundkurs Software-Engineering mit UML156Stephan Kleuker Klassendiagramm

157 Grundkurs Software-Engineering mit UML157Stephan Kleuker 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

158 Grundkurs Software-Engineering mit UML158Stephan Kleuker Beispiel: Vererbung nächster Schritt: Prüfen, wo statt Projekt und Projektaufgabe Projektkomponente stehen kann (Abstrahierung)

159 Grundkurs Software-Engineering mit UML159Stephan Kleuker 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 > 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

160 Grundkurs Software-Engineering mit UML160Stephan Kleuker Validierung mit Sequenzdiagrammen 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) 5.4

161 Grundkurs Software-Engineering mit UML161Stephan Kleuker Zusammenhang: Programm und Sequenzdiagramm 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); } :Ab:B c:C mach(42) tues(42) new C(42,43) 42 yeah(c) 'U' sach(A) 'V' extern

162 Grundkurs Software-Engineering mit UML162Stephan Kleuker 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

163 Grundkurs Software-Engineering mit UML163Stephan Kleuker Zusammenhang zwischen Aktivitäts- und Sequenzdiagrammen

164 Grundkurs Software-Engineering mit UML164Stephan Kleuker Iterative Entwicklung eines Sequenzdiagramms 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); } :Ab:B tues() z=oh() tues(x) tues(42) l:Set hinzu(c) add(c)

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

166 Grundkurs Software-Engineering mit UML166Stephan Kleuker Highlevel-Sequenzdiagramme

167 Grundkurs Software-Engineering mit UML167Stephan Kleuker Beispiel: Initialisierung Anmerkung: Typischerweise befruchten sich die Entwicklung von Klassendiagrammen und Sequenzdiagrammmen (Optimierung in einem iterativen Prozess)

168 Grundkurs Software-Engineering mit UML168Stephan Kleuker 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

169 Grundkurs Software-Engineering mit UML169Stephan Kleuker Beispiel: Fertigstellungsgrad berechnen

170 Grundkurs Software-Engineering mit UML170Stephan Kleuker Beispiel: Prüfung Projektaufwand aktualisierbar (1/2)

171 Grundkurs Software-Engineering mit UML171Stephan Kleuker Beispiel: Prüfung Projektaufwand aktualisierbar (2/2)

172 Grundkurs Software-Engineering mit UML172Stephan Kleuker Beispiel: Projektaufgabenaufwand aktualisierbar?

173 Grundkurs Software-Engineering mit UML173Stephan Kleuker GUI-Modellierung 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 5.5

174 Grundkurs Software-Engineering mit UML174Stephan Kleuker Erweiterung mit Boundary-Klassen

175 Grundkurs Software-Engineering mit UML175Stephan Kleuker Sequenzdiagramm mit Nutzungsdialog

176 Grundkurs Software-Engineering mit UML176Stephan Kleuker 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

177 Grundkurs Software-Engineering mit UML177Stephan Kleuker Anforderungsverfolgung - Beispielzusammenhänge

178 Grundkurs Software-Engineering mit UML178Stephan Kleuker 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

179 Grundkurs Software-Engineering mit UML179Stephan Kleuker 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

180 Grundkurs Software-Engineering mit UML180Stephan Kleuker UML-Toolsuiten / CASE-Werkzeuge 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 6.1

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

182 Grundkurs Software-Engineering mit UML182Stephan Kleuker Übersetzung einfacher Diagramme (2/3) public class Mitarbeiter { /** name="minr" */ private int minr; /** * Getter of the property minr Returns the minr. name="minr" */ public int getMinr() { return minr; } /** * Setter of the property minr minr The minr to set. name="minr" */ public void setMinr(int minr) { this.minr = minr; }

183 Grundkurs Software-Engineering mit UML183Stephan Kleuker 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; } Übersetzung einfacher Diagramme (3/3) = evtl. notwendige Korrekturen, bei CASE-Werkzeug

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

185 Grundkurs Software-Engineering mit UML185Stephan Kleuker Umgang mit Assoziationen im Design 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; } 6.3

186 Grundkurs Software-Engineering mit UML186Stephan Kleuker 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

187 Grundkurs Software-Engineering mit UML187Stephan Kleuker 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 bearbeiter = new ArrayList (); bitte, bitte in Java nicht alles mit ArrayList realisieren (!!!) Multiplizität 0..7 als Array umsetzbar

188 Grundkurs Software-Engineering mit UML188Stephan Kleuker 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 *

189 Grundkurs Software-Engineering mit UML189Stephan Kleuker Arten der Zugehörigkeit (Aggregation 1/2) 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(){ return bearbeiter;} 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 6.4

190 Grundkurs Software-Engineering mit UML190Stephan Kleuker Arten der Zugehörigkeit (Aggregation 2/2) Designansatz: Verhindern unerwünschten Zugriffs durch Interface (generell gute Idee !) Kurzdarstellung Interfacerealisierer:

191 Grundkurs Software-Engineering mit UML191Stephan Kleuker 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

192 Grundkurs Software-Engineering mit UML192Stephan Kleuker Arten der Zugehörigkeit (Komposition 2/2) Java arbeitet nur mit Zeigern (unschöne Ausnahme sind Elementartypen), wie realisiert // 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

193 Grundkurs Software-Engineering mit UML193Stephan Kleuker 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: >) Wenn zu viele Pfeile im Diagramm, dann mehrere Diagramme mit gleichen Klassen zu unterschiedlichen Themen UML-Werkzeuge unterstützen Analyse von Abhängigkeiten

194 Grundkurs Software-Engineering mit UML194Stephan Kleuker Erstellen einer Softwarearchitektur 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 6.5

195 Grundkurs Software-Engineering mit UML195Stephan Kleuker 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

196 Grundkurs Software-Engineering mit UML196Stephan Kleuker 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)

197 Grundkurs Software-Engineering mit UML197Stephan Kleuker Beispiel: grobe Paketierung (eine Variante) Anmerkung: Datenverwaltung noch nicht konzipiert

198 Grundkurs Software-Engineering mit UML198Stephan Kleuker Beispiel: grobe Paketierung (zweite Variante)

199 Grundkurs Software-Engineering mit UML199Stephan Kleuker Forderung: azyklische Abhängigkeitsstruktur

200 Grundkurs Software-Engineering mit UML200Stephan Kleuker 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; //... }; }

201 Grundkurs Software-Engineering mit UML201Stephan Kleuker 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

202 Grundkurs Software-Engineering mit UML202Stephan Kleuker 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

203 Grundkurs Software-Engineering mit UML203Stephan Kleuker Architektursichten 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 6.6

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

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

206 Grundkurs Software-Engineering mit UML206Stephan Kleuker 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

207 Grundkurs Software-Engineering mit UML207Stephan Kleuker 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

208 Grundkurs Software-Engineering mit UML208Stephan Kleuker 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)

209 Grundkurs Software-Engineering mit UML209Stephan Kleuker 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 > (ausführbare Datei) und > (Datei) müssen zur HW-Beschreibung nicht angegeben werden

210 Grundkurs Software-Engineering mit UML210Stephan Kleuker 7. Konkretisierungen im Feindesign 7.1 Zustandsdiagramme 7.2 Object Constraint Language

211 Grundkurs Software-Engineering mit UML211Stephan Kleuker 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

212 Grundkurs Software-Engineering mit UML212Stephan Kleuker Zustandsdiagramme 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 7.1

213 Grundkurs Software-Engineering mit UML213Stephan Kleuker 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

214 Grundkurs Software-Engineering mit UML214Stephan Kleuker Beispiel: Zustandsdiagramm eines Projekts man erkennt: nach Planung keine Planungsänderung

215 Grundkurs Software-Engineering mit UML215Stephan Kleuker Hierarchische Zustände

216 Grundkurs Software-Engineering mit UML216Stephan Kleuker 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

217 Grundkurs Software-Engineering mit UML217Stephan Kleuker Beispiel: Uhr

218 Grundkurs Software-Engineering mit UML218Stephan Kleuker 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)

219 Grundkurs Software-Engineering mit UML219Stephan Kleuker 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

220 Grundkurs Software-Engineering mit UML220 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 Grundkurs Software-Engineering mit UML221 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 Grundkurs Software-Engineering mit UML222Stephan Kleuker 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]

223 Grundkurs Software-Engineering mit UML223Stephan Kleuker 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

224 Grundkurs Software-Engineering mit UML224Stephan Kleuker Beispiel: Start-Stopp-Automatik (3/3)

225 Grundkurs Software-Engineering mit UML225Stephan Kleuker GUI als Zustandsdiagramm

226 Grundkurs Software-Engineering mit UML226 Android als Zustandsdiagramm Stephan Kleuker

227 Grundkurs Software-Engineering mit UML227Stephan Kleuker 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

228 Grundkurs Software-Engineering mit UML228Stephan Kleuker Klassendiagramm und versteckte Randbedingungen Welche Randbedingungen vermuten Sie? 7.2

229 Grundkurs Software-Engineering mit UML229Stephan Kleuker 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

230 Grundkurs Software-Engineering mit UML230Stephan Kleuker Einfache Bedingungen für Objekte (Invarianten) Die Matrikelnummer ist mindestens 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

231 Grundkurs Software-Engineering mit UML231Stephan Kleuker 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

232 Grundkurs Software-Engineering mit UML232Stephan Kleuker Einschub: Basistypen und Operationen Jeder OCL-Ausdruck hat einen Typ Verknüpfe Ausdrücke müssen vom Typ her passen Geringe Typanpassungen möglich TypBeispielwerte Booleantrue, false Integer1, -5, 42, Real3.14, 42.42, String'Hallo Again', 'Heidi', '' TypBeispieloperationen Booleanand,or,xor,not,implies,if then else endif Integer*, +, -, /, abs() Real*, +, -, /, floor() Stringconcat(), size(), substring()

233 Grundkurs Software-Engineering mit UML233Stephan Kleuker 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

234 Grundkurs Software-Engineering mit UML234Stephan Kleuker 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)

235 Grundkurs Software-Engineering mit UML235Stephan Kleuker 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( ) 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

236 Grundkurs Software-Engineering mit UML236Stephan Kleuker 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))

237 Grundkurs Software-Engineering mit UML237Stephan Kleuker 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

238 Grundkurs Software-Engineering mit UML238Stephan Kleuker 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

239 Grundkurs Software-Engineering mit UML239Stephan Kleuker 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)

240 Grundkurs Software-Engineering mit UML240Stephan Kleuker Einfache Basisregeln 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 Aint Gonna Need It, keine Verallgemeinerungen entwickeln, die das Design für theoretisch in der Zukunft vielleicht gewünschte Erweiterungen vereinfachen 8.1

241 Grundkurs Software-Engineering mit UML241Stephan Kleuker Keine allwissenden Klassen ändere Fertigstellungsgrad einer Projektaufgabe besser:

242 Grundkurs Software-Engineering mit UML242Stephan Kleuker 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

243 Grundkurs Software-Engineering mit UML243Stephan Kleuker 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); }

244 Grundkurs Software-Engineering mit UML244Stephan Kleuker Erinnerung: Bedeutung von Schnittstellen Design by ContractSchnittstellen sind zentrales Element des Design by Contract vorgegebene Aufgabe: Implementiere mir folgende Funktionalität... beschrieben durch –Vorbedingung –Signatur ( )... –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 aufgaben und nicht ArrayList aufgaben im Code

245 Grundkurs Software-Engineering mit UML245 Design by Contract Stephan Kleuker

246 Grundkurs Software-Engineering mit UML246 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 Grundkurs Software-Engineering mit UML247 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 Grundkurs Software-Engineering mit UML248Stephan Kleuker Erinnerung: Bedeutung von Polymorphie (1/2)

249 Grundkurs Software-Engineering mit UML249Stephan Kleuker Erinnerung: Bedeutung von Polymorphie (2/2) #include #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 r1(re1,re2); Rahmen r2(re1,k2); Rahmen r3(k1,re2); Rahmen r4(k1,k2); GeoObjekt *g[8]={&re1,&k1,&re2,&k2,&r1,&r2,&r3,&r4}; for(int i=0;i<8;i++) std::cout<

250 Grundkurs Software-Engineering mit UML250Stephan Kleuker 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 Implementing this interface allows an object to be the target of the "foreach" statement. Method Summary Iterator 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).

251 Grundkurs Software-Engineering mit UML251 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); } Dr. Stephan Kleuker [21, 31]

252 Grundkurs Software-Engineering mit UML252 Method Chaining (2/3) public class IntMenge { private Set 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 Grundkurs Software-Engineering mit UML253 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 this.menge.contains(wert); public String toString(){ return this.menge.toString(); } Stephan Kleuker

254 Grundkurs Software-Engineering mit UML254Stephan Kleuker Grundidee von Design-Pattern 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) 8.2

255 Grundkurs Software-Engineering mit UML255Stephan Kleuker 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)

256 Grundkurs Software-Engineering mit UML256Stephan Kleuker Java-Beispiel zum MVC (1/6)

257 Grundkurs Software-Engineering mit UML257Stephan Kleuker Java-Beispiel zum MVC (2/6)

258 Grundkurs Software-Engineering mit UML258Stephan Kleuker Java-Beispiel zum MVC (3/6) import java.util.*; public class XModel{ private ArrayList listener = new ArrayList (); 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(); }

259 Grundkurs Software-Engineering mit UML259Stephan Kleuker 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()); }

260 Grundkurs Software-Engineering mit UML260Stephan Kleuker 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(){ public void actionPerformed(ActionEvent e){ this.xmodel.changeValue(-1); }}); setDefaultCloseOperation(EXIT_ON_CLOSE); setSize(250,60); setLocation(0,90);´setVisible(true); }

261 Grundkurs Software-Engineering mit UML261Stephan Kleuker 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); }

262 Grundkurs Software-Engineering mit UML262Stephan Kleuker 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 Controller ModelView 1: Nutzereingabe 4: neue Darstellung 3: Aktualisierung 2: Eigenschaften aktualisieren

263 Grundkurs Software-Engineering mit UML263Stephan Kleuker Ansatz Observer-Observable 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 8.3

264 Grundkurs Software-Engineering mit UML264Stephan Kleuker Beobachter (Observer – Observable)

265 Grundkurs Software-Engineering mit UML265Stephan Kleuker 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

266 Grundkurs Software-Engineering mit UML266Stephan Kleuker 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

267 Grundkurs Software-Engineering mit UML267Stephan Kleuker Adapter - Lösung public class Adapter implements B{ private C c = null;... public Adapter(){ c = new C(); public void machWasTolles(){ return c.kannWasWasAuchBKoennenSoll(); }

268 Grundkurs Software-Engineering mit UML268Stephan Kleuker 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.

269 Grundkurs Software-Engineering mit UML269Stephan Kleuker Beispielanwendung: Abstract Factory Pattern

270 Grundkurs Software-Engineering mit UML270Stephan Kleuker 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

271 Grundkurs Software-Engineering mit UML271Stephan Kleuker 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

272 Grundkurs Software-Engineering mit UML272Stephan Kleuker 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; }

273 Grundkurs Software-Engineering mit UML273Stephan Kleuker Singleton 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; }

274 Grundkurs Software-Engineering mit UML274Stephan Kleuker 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); p1.ausgeben(); p2.ausgeben(); Singleton p3=p1.clone(); if(p2==p3) System.out.println("\n identisch"); } [6,42][6,42] identisch [9,47][9,47] identisch

275 Grundkurs Software-Engineering mit UML275Stephan Kleuker 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

276 Grundkurs Software-Engineering mit UML276Stephan Kleuker 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); }

277 Grundkurs Software-Engineering mit UML277Stephan Kleuker 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")); } Proxy – Implementierungsmöglichkeit (2/2)

278 Grundkurs Software-Engineering mit UML278Stephan Kleuker 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)

279 Grundkurs Software-Engineering mit UML279Stephan Kleuker Strategy - Lösungsbeispiel

280 Grundkurs Software-Engineering mit UML280Stephan Kleuker State-Pattern (eigene Variante)

281 Grundkurs Software-Engineering mit UML281Stephan Kleuker 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); public Zustand setX(int x) { this.x=x; if(x>=42) return new ZustandKritisch(x); return this; public String status() {return "alles ok";} }

282 Grundkurs Software-Engineering mit UML282Stephan Kleuker 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()); }

283 Grundkurs Software-Engineering mit UML283 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 Grundkurs Software-Engineering mit UML284 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 Grundkurs Software-Engineering mit UML285 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 -= this.speicher; public String toString(){ return "Speicher: "+ this.speicher +" Wert: " + this.anzeige; } Stephan Kleuker

286 Grundkurs Software-Engineering mit UML286 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 Grundkurs Software-Engineering mit UML287 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(); break; } case 4: { this.rechner.speicherAddieren(); break; } case 5: { this.rechner.speicherSubtrahieren(); break; } System.out.println(this.rechner); } Stephan Kleuker

288 Grundkurs Software-Engineering mit UML288 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) subtrahieren 2 Wert eingeben: 1 Speicher: 0 Wert: 42 (3) Anzeige in Speicher 3 Speicher: 42 Wert: 42 Stephan Kleuker (4) Speicher addieren 4 Speicher: 42 Wert: 84 (5) Speicher subtrahieren 5 Speicher: 42 Wert: 42 (0) Programm beenden 0 Speicher: 42 Wert: 42

289 Grundkurs Software-Engineering mit UML289 Beispiel 6/12 : Ansatz 1: Steuerungsklassen Stephan Kleuker

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

291 Grundkurs Software-Engineering mit UML291 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 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)); } Stephan Kleuker

292 Grundkurs Software-Engineering mit UML292 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 Grundkurs Software-Engineering mit UML293 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 Grundkurs Software-Engineering mit UML294 Beispiel 11/12 : Variante Undo-Methode Stephan Kleuker

295 Grundkurs Software-Engineering mit UML295 Beispiel 12/12 : Variante Undo-Objekte (Skizze) Stephan Kleuker

296 Grundkurs Software-Engineering mit UML296 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 Grundkurs Software-Engineering mit UML297Stephan Kleuker Beschreibung des Pattern 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: 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 8.4

298 Grundkurs Software-Engineering mit UML298Stephan Kleuker 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...

299 Grundkurs Software-Engineering mit UML299Stephan Kleuker GoF-Pattern Übersicht (nicht auswendig lernen) Einsatzbereich Klasse Objekt Aufgabenbereich ErzeugungStrukturVerhalten FactoryAdapterInterpreter Template Abstract Factory AdapterCommand BuilderBridgeObserver PrototypeDecoratorVisitor SingletonFacadeMemento CompositeStrategy ProxyMediator FlyweightState Chain of Responsibility

300 Grundkurs Software-Engineering mit UML300Stephan Kleuker Pattern in der UML Pattern-Name im gestrichelten Kreis, verbunden mit eingekreisten Klassen, verbunden mit Pattern und Bennenung der Rollen

301 Grundkurs Software-Engineering mit UML301Stephan Kleuker 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 !!!

302 Grundkurs Software-Engineering mit UML302Stephan Kleuker 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

303 Grundkurs Software-Engineering mit UML303Stephan Kleuker 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)

304 Grundkurs Software-Engineering mit UML304Stephan Kleuker Beispiel: Rahmenbedingungen für SW-Architektur 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) 9.1

305 Grundkurs Software-Engineering mit UML305Stephan Kleuker 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

306 Grundkurs Software-Engineering mit UML306Stephan Kleuker Rahmenbedingung: verteilte Systeme 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 9.2

307 Grundkurs Software-Engineering mit UML307Stephan Kleuker Probleme der Aufrufmechanismen synchroner Aufruf asynchroner Aufruf berechne_x() berechne_y() Prozess A Problem: Deadlock Prozess BProzess C Problem: B denkt, x hat vor y stattgefunden Problem: C denkt, x hat vor y stattgefunden, A denkt, y hat vor x stattgefunden warten auf Antwort warten auf Antwort x() y() x()

308 Grundkurs Software-Engineering mit UML308Stephan Kleuker 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

309 Grundkurs Software-Engineering mit UML309Stephan Kleuker 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 Server Netzwerk Client Server Netzwerk

310 Grundkurs Software-Engineering mit UML310Stephan Kleuker 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

311 Grundkurs Software-Engineering mit UML311Stephan Kleuker Erinnerung: XML 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 9.3

312 Grundkurs Software-Engineering mit UML312Stephan Kleuker Elemente 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 XML-DB Element heißt projektname, der Inhalt ist vom sogenannten Start- und End-Tag umgeben Abkürzungsmöglichkeit bei leerem Inhalt: Leerzeichen führen meist zu Fehlern, hier z. B. drei

313 Grundkurs Software-Engineering mit UML313Stephan Kleuker Hierarchischer Aufbau Elemente können ineinander geschachtelt werden Ausgehend vom obersten Element ergibt sich ein Baum 42 Aische Meier Nabil Ibn 50

314 Grundkurs Software-Engineering mit UML314Stephan Kleuker Attribute Jedes Element kann eine beliebige Anzahl an Attributen haben Attribute stehen in Anführungsstrichen ( " oder ' ) Speichermodul 49 Ute Rose 50

315 Grundkurs Software-Engineering mit UML315Stephan Kleuker Attribute oder Elemente Attribute beschreiben Eigenschaften von Elementen Eigentlicher Inhalt steht zwischen den Tags Aus theoretischer Sicht vertauschbar alternativ Entwicklung Festpreis Aus Sicht der Verarbeitung leichte Unterschiede, Tendenz zu Attributen

316 Grundkurs Software-Engineering mit UML316Stephan Kleuker Kommentare und Namensregeln Grundsätzlich existieren nur kommentierte Produkte XML Kommentar in eingeschlossen 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

317 Grundkurs Software-Engineering mit UML317Stephan Kleuker 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) Speicher version (bleibt vielleicht immer) 1.0 oder 1.1 encoding gibt verwendeten Zeichensatz an, hier klein oder Großschreibung möglich, typisch sind UTF-88 Bit Zeichenbereite (Standard) UTF-1616 Bit Zeichenbreite (bel. Sprachen) ISO Westeuropäische Sprachen

318 Grundkurs Software-Engineering mit UML318Stephan Kleuker Nutzung von Programmbibliotheken 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 9.4

319 Grundkurs Software-Engineering mit UML319Stephan Kleuker Idee von Komponenten 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) 9.5

320 Grundkurs Software-Engineering mit UML320Stephan Kleuker 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

321 Grundkurs Software-Engineering mit UML321Stephan Kleuker 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

322 Grundkurs Software-Engineering mit UML322 Zentrale Eigenschaften von Komponenten Stephan Kleuker

323 Grundkurs Software-Engineering mit UML323Stephan Kleuker Idee der Framework-Technologie 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 9.6

324 Grundkurs Software-Engineering mit UML324Stephan Kleuker 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

325 Grundkurs Software-Engineering mit UML325Stephan Kleuker 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. int getIndexOfChild(Object parent, Object child) Returns the index of child in parent. Object getRoot() Returns the root of the tree. boolean isLeaf(Object node) Returns true if node is a leaf. void removeTreeModelListener(TreeModelListener l) Removes a listener previously added with addTreeModelListener. void valueForPathChanged(TreePath path, Object newValue) Messaged when the user has altered the value for the item identified by path to newValue.

326 Grundkurs Software-Engineering mit UML326Stephan Kleuker Skizze einer Beispielimplementierung (1/5) Knoteninformation dient dazu, für den jeweiligen Knoten die darstellungsrelevanten Informationen zu liefern

327 Grundkurs Software-Engineering mit UML327Stephan Kleuker Skizze einer Beispielimplementierung (2/5) ProjektTreeModel ptm = new ProjektTreeModel(); JTree baum = new JTree(ptm); JScrollPane scroller = new JScrollPane(baum); add(scroller,BorderLayout.CENTER);

328 Grundkurs Software-Engineering mit UML328Stephan Kleuker Skizze einer Beispielimplementierung (3/5) public class ProjektTreeModel implements TreeModel { private Projektverwaltung projektverwaltung; private List listener = new ArrayList (); 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

329 Grundkurs Software-Engineering mit UML329Stephan Kleuker Skizze einer Beispielimplementierung (4/5) public class Projektverwaltung implements Knoteninformation{ private List projekte = new ArrayList (); 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"; public String toString(){ return titel(); } } // nur Ausschnitt

330 Grundkurs Software-Engineering mit UML330Stephan Kleuker Skizze einer Beispielimplementierung (5/5) public class Projekt implements Knoteninformation{ private Eigenschaft[] eigenschaften = new Eigenschaft[8]; private BaumListe teilprojekte = new BaumListe ("Teilprojekte"); private BaumListe vorgaenger = new BaumListe ("Vorgaenger"); private BaumListe aufgaben = new BaumListe ("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

331 Grundkurs Software-Engineering mit UML331Stephan Kleuker 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

332 Grundkurs Software-Engineering mit UML332Stephan Kleuker Persistente Datenhaltung 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 9.7

333 Grundkurs Software-Engineering mit UML333Stephan Kleuker 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)

334 Grundkurs Software-Engineering mit UML334Stephan Kleuker 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){ try { XMLDecoder in= new XMLDecoder( new BufferedInputStream(new FileInputStream(datei))); table.setModel((DefaultTableModel)in.readObject()); in.close(); } catch (FileNotFoundException e) {} //wegschauen }

335 Grundkurs Software-Engineering mit UML335 Annotationen 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 9.8

336 Grundkurs Software-Engineering mit UML336Stephan Kleuker Beispiel JPA public class Mitarbeiter implements Serializable { private static final long serialVersionUID = GenerationType.AUTO) private int minr; private String cascade={CascadeType.PERSIST, CascadeType.MERGE}) private Set auftraege = new HashSet ();... public void auftragHinzu(Projektauftrag pa){ auftraege.add(pa); } // get- und set- für Exemplarvariablen fehlen soll persistiert werden Exemplarvariable ist Schlüssel Schlüssel automatisch generiert 1:N-Beziehung

337 Grundkurs Software-Engineering mit UML337Stephan Kleuker Beispiel JPA (2/2) – nur Überblick private EntityManagerFactory emf = Persistence.createEntityManagerFactory("JPAKonfigD atei"); 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

338 Grundkurs Software-Engineering mit UML338Stephan Kleuker In Erprobung/Entwicklung: : Domain Specific Languages 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 9.9

339 Grundkurs Software-Engineering mit UML339Stephan Kleuker DSL Prozesse

340 Grundkurs Software-Engineering mit UML340Stephan Kleuker In Erprobung/Entwicklung: Model Driven Architecture 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) 9.10

341 Grundkurs Software-Engineering mit UML341Stephan Kleuker 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)

342 Grundkurs Software-Engineering mit UML342Stephan Kleuker Formaler Hintergrund der MDA Modellart1Modellart2 Transformations- regeln Transformations- model Meta Object Faciliy (MOF) konkretes Modell1 konkretes Modell2 konkrete Menge von Regeln mit konkreten Parametern Instanz von Semantik definiert durch Abarbeitungsreihenfolge

343 Grundkurs Software-Engineering mit UML343Stephan Kleuker Refactoring 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) 9.11

344 Grundkurs Software-Engineering mit UML344Stephan Kleuker 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; return a; }

345 Grundkurs Software-Engineering mit UML345Stephan Kleuker 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; }

346 Grundkurs Software-Engineering mit UML346Stephan Kleuker 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; }

347 Grundkurs Software-Engineering mit UML347Stephan Kleuker 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)

348 Grundkurs Software-Engineering mit UML348Stephan Kleuker Begriff: Ergonomie 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. 10.1

349 Grundkurs Software-Engineering mit UML349Stephan Kleuker 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.

350 Grundkurs Software-Engineering mit UML350Stephan Kleuker FarbeAssoziation weißReinheit, Unschuld (Asien: Trauer) schwarzTod, Trauer, Eleganz, Schwere, Ernst grauNeutral, spannungslos blauGeist, Kosmos, Ewigkeit, wirkt kühl, steigert in Kombination die Wirkung warmer Farbtöne rotDynamik, Aktivität, Wärme, Warnfarbe gelbAnregend, heiter, dynamisch, kalte Farben wirken durch Zusatz von gelb kälter, warme Farben wärmer orangeHohes Maß an Aktivität und Dynamik, erregt Aufmerksamkeit, Warnfarbe violettErnst, feierlich, je nach Blauanteil kühl oder warm grünNatur, Wachstum, beruhigend (langweilig) Psychologie: Beispiel Farbwahl

351 Grundkurs Software-Engineering mit UML351Stephan Kleuker Zusammenhang der Normen ISO

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

353 Grundkurs Software-Engineering mit UML353Stephan Kleuker 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

354 Grundkurs Software-Engineering mit UML354Stephan Kleuker 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!)

355 Grundkurs Software-Engineering mit UML355Stephan Kleuker 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

356 Grundkurs Software-Engineering mit UML356Stephan Kleuker 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

357 Grundkurs Software-Engineering mit UML357Stephan Kleuker 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?

358 Grundkurs Software-Engineering mit UML358Stephan Kleuker 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?

359 Grundkurs Software-Engineering mit UML359Stephan Kleuker 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?

360 Grundkurs Software-Engineering mit UML360Stephan Kleuker Anforderungsanalyse aus Usability-Sicht 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] 10.3

361 Grundkurs Software-Engineering mit UML361Stephan Kleuker 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)

362 Grundkurs Software-Engineering mit UML362 Integration der Oberflächenentwicklung Stephan Kleuker

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

364 Grundkurs Software-Engineering mit UML364Stephan Kleuker 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

365 Grundkurs Software-Engineering mit UML365Stephan Kleuker 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

366 Grundkurs Software-Engineering mit UML366Stephan Kleuker 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

367 Grundkurs Software-Engineering mit UML367Stephan Kleuker 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

368 Grundkurs Software-Engineering mit UML368Stephan Kleuker 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.

369 Grundkurs Software-Engineering mit UML369Stephan Kleuker 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

370 Grundkurs Software-Engineering mit UML370Stephan Kleuker Notwendige Anzahl von Testnutzern

371 Grundkurs Software-Engineering mit UML371Stephan Kleuker 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

372 Grundkurs Software-Engineering mit UML372Stephan Kleuker Korrektheit 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 11.1

373 Grundkurs Software-Engineering mit UML373Stephan Kleuker 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)

374 Grundkurs Software-Engineering mit UML374Stephan Kleuker Assertions in JDK ab Version 1.4 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 11.2

375 Grundkurs Software-Engineering mit UML375Stephan Kleuker 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 assert : ist meist ein String, der bei der Fehlermeldung mit angezeigt wird

376 Grundkurs Software-Engineering mit UML376Stephan Kleuker 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;

377 Grundkurs Software-Engineering mit UML377Stephan Kleuker 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 newIllegalArgumentException("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

378 Grundkurs Software-Engineering mit UML378Stephan Kleuker 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; }

379 Grundkurs Software-Engineering mit UML379Stephan Kleuker 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 = ; return erg; } Überprüfung der Invariante assert invariant(...); am –Ende eines jeden Konstruktors –am Anfang jeder public-Methode –am Ende jeder public-Methode

380 Grundkurs Software-Engineering mit UML380Stephan Kleuker 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

381 Grundkurs Software-Engineering mit UML381Stephan Kleuker JUnit 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 11.3

382 Grundkurs Software-Engineering mit UML382Stephan Kleuker 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

383 Grundkurs Software-Engineering mit UML383Stephan Kleuker 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

384 Grundkurs Software-Engineering mit UML384Stephan Kleuker 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.

385 Grundkurs Software-Engineering mit UML385Stephan Kleuker 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)

386 Grundkurs Software-Engineering mit UML386Stephan Kleuker 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.*;

387 Grundkurs Software-Engineering mit UML387Software-Qualitä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

388 Grundkurs Software-Engineering mit UML388Stephan Kleuker 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 public void testNegativeInitialisierung() { try { new MyClass(-10); fail("Meine Meldung im Fehlerfall"); }catch (IllegalArgumentException e) {} }

389 Grundkurs Software-Engineering mit UML389Stephan Kleuker 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) { this.gesperrt = gesperrt; }

390 Grundkurs Software-Engineering mit UML390Stephan Kleuker 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 {}

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

392 Grundkurs Software-Engineering mit UML392Stephan Kleuker Testfälle 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()); }

393 Grundkurs Software-Engineering mit UML393Stephan Kleuker Testfälle 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(){ try { boese.preis(100.0); fail("fehlende RabattException"); } catch (RabattException e) { } public static void main(String[] args) { junit.swingui.TestRunner.run(RabattTest.class); }

394 Grundkurs Software-Engineering mit UML394Stephan Kleuker TestSuite Für große Projekte sind folgende Wünsche bzgl. der Tests typisch: a)mehrere Testklassen sollen zusammen laufen können b)man möchte Tests flexibel kombinieren können; Testwiederholung soll davon abhängen, welche Klassen betroffen sein können [schwierige Weissagung] c)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

395 Grundkurs Software-Engineering mit UML395Stephan Kleuker 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

396 Grundkurs Software-Engineering mit UML396Stephan Kleuker Klassen testbar machen 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 11.4

397 Grundkurs Software-Engineering mit UML397Stephan Kleuker 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