Grundkurs Software-Engineering mit UML Konzepte für die erfolgreiche SoftwareEntwicklung Prof. Dr. Stephan Kleuker • Bitte beachten Sie die Rechte des Verlages Vieweg+Teubner an der Buchinhalten und Bildern • Diese Folien sind als Begleitfolien für das Buch konzipiert Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 1 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 2 1. Motivation von SoftwareEngineering Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 3 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 4 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 5 Historie des SW-Engineering (3/4) • • • • 90er Jahre – Geeignete Analyse- und Entwurfsmethoden entstehen (Coad/Yourdon, Rumbaugh, Booch, Jacobson und andere) 1995 – Vereinigung mehrerer Ansätze zunächst als Unified Method (UM) von Booch und Rumbaugh, dann kommt Jacobson hinzu (Use Cases). – 3 Amigos definieren die Unified Modeling Language (UML) als Quasi-Standard. 1997 – UML in der Version 1.1 bei der OMG (Object Management Group) zur Standardisierung eingereicht und angenommen – UML ist jedoch keine Entwicklungsmethode (Phasenmodell), nur eine Beschreibungssprache 1999 – Entwicklungsmethode: Unified Process (UP) und Rational Unified Process (RUP) (erste Version) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 6 Historie des SW-Engineering (4/4) • Heute – Vorgehensweisen auf individuelle Projektanforderungen abgestimmt – CASE-Methoden und –Tools orientieren sich an der UML – Aktueller Stand 2010: UML 2.3 – Aufbauend auf Analyse und Design erzeugen Codegeneratoren Programmgerüste – Haupttätigkeiten bei Softwareentwicklung sind Analyse und Design, vieles andere versucht man zu automatisieren (!?) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 7 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 • … Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 8 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 9 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-EngineeringErgebnissen sind UML-Diagramme. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 10 2. Prozessmodellierung 2.1 Unternehmensprozesse 2.2 Prozessmodellierung mit Aktivitätsdiagrammen 2.3 Risikomanagement Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 11 Umfeld von SW-Projekten 2.1 Unternehmensführung Unterstützung Vertrieb Projektmanagement Controlling SW-Projekt Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 12 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 13 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 14 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 15 Prozessmodellierung mit Aktivitätsdiagrammen 2.2 Zur Beschreibung werden folgende elementare Elemente genutzt: genau ein Startpunkt einzelner Prozessschritt (Aktion) Kontrollknoten (Entscheidung) Kontrollknoten (Zusammenführung) Endpunkt (Terminierung) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 16 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 17 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 18 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 19 Beispiel: Vertrieb (2/4) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 20 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 21 Beispiel: Vertrieb (4/4) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 22 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 23 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 24 Prozessverfeinerung: Kosten kalkulieren Anmerkung: Verantwortliche weggelassen, da immer „Projektbegleiter der Fachabteilung“ Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 25 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 26 Querschnittsprozess: Projekt-Risikomanagement 2.3 • 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, 2003 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 27 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 (Kickoff) 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 ) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 28 Risikomanagement Risiken identifizieren Optimieren Risiken analysieren Maßnahmen planen RisikoDatenbank Maßnahmen durchführen Maßnahmen bewerten Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 29 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 30 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 31 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 32 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 33 Herausforderungen der SW-Entwicklung 3.1 Software-Systeme sind heutzutage verteilte Anwendungen – Anschluss an existierende Software (z.B. SAP, MS Office, bestehende Unternehmenssoftware...) – Integration neuer Komponenten in existierende Systeme – Erweiterung existierender Systeme eigene Komponenten neues System ? ? ? Legacy Systeme Grundkurs Software-Engineering mit UML, 2. Auflage Systeme an anderen Standorten ? ? Systeme anderer Anbieter Stephan Kleuker 34 Die Phasen der SW- Entwicklung • Erhebung und Festlegung des Anforderungsanalyse WAS mit Rahmenbedingungen Grobdesign Feindesign Implementierung Test und Integration • 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 35 Wasserfallmodell 3.2 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 36 Prototypische Entwicklung 3.3 Anforderungsanalyse Anforderungsanalyse Grobdesign Grobdesign Feindesign Feindesign Implementierung Implementierung Test und Integration Test und Integration Prototyp Grundkurs Software-Engineering mit UML, 2. Auflage 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 Stephan Kleuker 37 Iterative Entwicklung 3.4 Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 38 Iterativ Inkrementelle Entwicklung (State of the Art) 3.5 Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration Bsp.: vier Inkremente Grundkurs Software-Engineering mit UML, 2. Auflage Merkmal: - Projekt in kleine Teilschritte zerlegt - pro Schritt neue Funktionalität (Inkrement) + Überarbeitung existierender Ergebnisse (Iteration) - n+1-ter Schritt kann Probleme des nten 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 Stephan Kleuker 39 Fertigstellung mit Iterationen Iterationen 1. 2. 3. 4. Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration 0% Grundkurs Software-Engineering mit UML, 2. Auflage Fertigstellungsgrad Stephan Kleuker 100% 40 Bekanntheit von Vorgehensmodellen 41 Wasserfallmodell 71 24 V-Modell 63 19 Spiralmodell 52 26 Inkrementelle Entwicklung 45 17 Evolutionäres Prototyping Extreme Programming RUP (Rational Unified Process) keines dieser Modelle 41 4 39 15 32 20 11 genutzte Modelle bekannte Modelle Quelle: Softwareentwicklung läuft nicht auf Zuruf, Computer Zeitung Nr. 46/05 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 41 Struktur komplexer Vorgehensmodelle 3.6 • Aktuelle Vorgehensmodelle, wie V-Modell XT des Bundes (Rational) Unified Process OEP (Object Engineering Process) enthalten Aktivitäten (was soll gemacht werden), Rollen (wer ist wie an Aktivität beteiligt) und Produkte (was wird benötigt; bzw. ist Ergebnis) • es gibt Vorschläge für typische Anwendungsszenarien, wie Aktivitäten zu verknüpfen sind • Rahmenwerke, am Anfang eines Projekts muss (werkzeuggestützt) bestimmen, welche Aktivitäten, Rollen, Produkte und Reihenfolgen von Aktivitäten für das individuelle Projekt relevant sind (tailoring, d. h. „zurecht schneidern“, benötigt viel Erfahrung) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 42 allgemeines V-Modell Validierung Anforderungsdefinition manuelle Prüfung Validierung Funktionaler Systementwurf manuelle Prüfung Validierung Technischer Systementwurf manuelle Prüfung Konstruktion KomponentenSpezifikation manuelle Prüfung Abnahmetest Systemtest Integrationstest Validierung Komponenten- test Programmierung Integration Anmerkung: wird iterativ / inkrementell zum W-Modell Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 43 V-Modell des Bundes 3.7 • Regelung der Softwarebearbeitung (im Bereich der Bundeswehr, des Bundes und der Länder) • einheitliche und (vertraglich) verbindliche Vorgabe von – Aktivitäten und – Produkten (Ergebnissen), • Historie: V-Modell 92 (Wasserfall im Mittelpunkt), Überarbeitung V-Modell 97 (Anpassung an inkrementelle Ideen (W-Modell); Forderung nach zu früher Festlegung von Anforderungen) • aktuell: V-Modell XT (eXtreme Tailoring), neuer Erstellung mit Fokus auf Verhältnis von Auftragnehmer und Auftraggeber (starker akademischer Einfluss bei Entwicklung) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 44 Struktur des V-Modell XT http://www.v-modell-xt.de für V-Modell XT-Informationen: Copyright Reserved © Bundesrepublik Deutschland 2004. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 45 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 46 Entscheidungspunkte des V-Modells XT relevant für alle V-Modell-Projekte Schnittstelle Auftraggeber / Auftragnehmer Organisationsspezifisches V-Modell Systementwicklung Projekt genehmigt Vorgehensmodell analysiert Verbesserung Vorgehensmodell konzipiert Verbesserung Vorgehensmodell realisiert Projekt definiert Anforderungen festgelegt Geamtprojekt aufgeteilt Projekt ausgeschrieben Gesamtfortschritt überprüft Projektfortschritt überprüft Projekt beauftragt Iteration geplant System spezifiziert Abnahme erfolgt Projekt abgeschlossen Lieferung durchgeführt System entworfen System integriert Feinentwurf abgeschlossen Grundkurs Software-Engineering mit UML, 2. Auflage Angebot abgegeben Systemelemente realisiert Stephan Kleuker 47 Beispiel: Projektdurchführungsplan (Systementwicklungsprojekt eines Auftraggebers (AG)) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 48 Beispielaktivität: Anforderungen festlegen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 49 Rational Unified Process (RUP) 3.8 Phasen Disziplinen Konzeption Entwurf Konstruktion Inbetriebnahme Geschäftsprozessmodell Anforderungsanalyse Design Implementierung Test Installation Konfigurations- und Änderungsmanagement Projektmanagement Projektumfeld Start nach IBM/Rational: Rational Unified Process Entwurf Iteration 1 Entwurf Iteration 2 Grundkurs Software-Engineering mit UML, 2. Auflage Konstruktion Konstruktion Konstruktion Inbetrieb Iteration 1 Iteration 2 Iteration n Iteration 1 Inbetrieb Iteration 2 Iterationen Stephan Kleuker 50 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 51 Struktur des RUP Software Engineering Process bearbeitet Rolle strukturiert durch Disziplin beschrieben in Aktivität Ergebnis Eingabe verantwortlich für Arbeitsablauf Hilfsmittel verfeinert durch erstellt mit Hilfe von Hilfsmittel Checkliste Arbeitsablaufdetails Produkt (Artifact) Strukturbeschreibung (Template) Werkzeuganleitung Hilfsmittel Bericht beschrieben durch Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 52 Kritik an klassischen Vorgehensmodellen 3.9 • Es müssen viele Dokumente erzeugt und gepflegt werden • Eigene Wissenschaft Modelle wie V-Modelle und RUP zu verstehen und zurecht zu schneidern • Prozessbeschreibungen hemmen Kreativität • Anpassung an neue Randbedingungen, z. B. neue Technologien (Web-Services) in Prozessen und benutzten Werkzeugen ist extrem aufwändig • alternativer Ansatz: „Menschen machen Projekte erfolgreich, traue den Menschen“ => agile Prozesse (vorherige Name: leichtgewichtige Prozesse) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 53 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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 54 Arten von agilen Prozessen (2/2) • Variante 2: Konkrete Prozessbeschreibungen – Für verschiedene Phasen der SoftwareEntwicklung 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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 55 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 www.agileAlliance.org Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 56 Scrum (1/2) 3.10 • („Scrum“: Gedränge beim Rugby) • Scrum Teams mit maximal 7 Personen mit unterschiedlichen Fähigkeiten, einem Leiter (Scrum Master) • 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 57 Scrum (2/2) • Projektplanung: Eng mit dem Kunden werden Hauptaufgaben identifiziert (Stack mit product backlog) • 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 • Jeder sprint dauert ca. 30 Tage; hat 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: www.controlchaos.com Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 58 Scrum - Überblick Product backlog sprint backlog Aufgabe 1 Teilaufgabe 1 Aufgabe 2 Teilaufgabe 2 ... ... Planung für sprint Arbeitstag StatusReview Grundkurs Software-Engineering mit UML, 2. Auflage Scrum-Meeting sprint 30 Arbeitstage Stephan Kleuker 59 Ideen des Extreme Programming (XP) (1/3) 3.11 • • • • • • • • • Planning User stories are written Release planning creates the schedule Make frequent small releases The Project Velocity is measured The project is divided into iterations Iteration planning starts each iteration Move people around A stand-up meeting starts each day Fix XP when it breaks Grundkurs Software-Engineering mit UML, 2. Auflage • • • • • • Designing Simplicity Choose a system metaphor Use CRC cards for design sessions Create spike solutions to reduce risk No functionality is added early Refactor whenever and wherever possible Stephan Kleuker 60 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 Grundkurs Software-Engineering mit UML, 2. Auflage • • • • Testing All code must have unit tests All code must pass all unit tests before it can be released When a bug is found tests are created Acceptance tests are run often and the score is published Stephan Kleuker 61 Ideen des Extreme Programming (XP) (3/3) Testfälle neue User-Story geänderte Randbedingung User Stories Anforderungen Systemidee Architekturansatz Fehler Release- ReleaseIteration plan Planung unklare Annahmen abgesicherte Annahmen aktuelle Version nächste Iteration Miniprototyp (Spike) Akzeptanz -tests Kundenzustimmung kleine Releases • Quelle der XP-Folien : www.extremeprogramming.org • Varianten: z. B. in der Nutzung von Dokumentation (keine – minimal) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 62 Versuch einer Beurteilung von agilen Methoden • agile Methoden haben viele Innovationen in verstaubte SWEntwicklungsprozesse 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 http://www.coldewey.com/publikationen/Kolumne.html Generell: Vorgehensmodell muss zum Projekt und den Menschen passen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 63 4. Anforderungsanalyse 4.1 4.2 4.3 4.4 4.5 4.6 Stakeholder und Ziele Klärung der Hauptfunktionalität (Use Cases) Beschreibung typischer und alternativer Abläufe Ableitung funktionaler Anforderungen Nicht-funktionale Anforderungen Lasten- und Pflichtenheft weiterführende Literatur: • [RS] C. Rupp, SOPHIST GROUP, Requirements- Engineering und – Management, Hanser Fachbuchverlag, 2004 • [OW] B. Oestereich, C. Weiss, C. Schröder, T. Weilkiens, A. Lenhard, Objektorientierte Geschäftsprozessmodellierung mit der UML, dpunkt.Verlag, 2003 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 64 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. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 65 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 Knowhow 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. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 66 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 ProAuto 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. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 67 so nicht (4/4): so doch, Geschäftsprozessanalyse Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 68 Aufgabe der Anforderungsanalyse 4.1 Bestimmung aller Anforderungen an die zu erstellende Software bzw. an das zu erstellende DV-System, Anforderungen müssen –vollständig, –notwendig ("WAS statt WIE"), –eindeutig und –richtig ("abgestimmt als Teil einer Zielhierarchie") sein. Bemerkung zur Ablauforganisation: Anforderungen müssen nicht notwendig in einer Phase vor Beginn des Entwurfs vollständig bestimmt werden Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 69 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 70 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 71 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 72 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 73 Regeln für die Definition von Zielen Ziele müssen – vollständig, – korrekt, – konsistent gegenüber anderen Zielen und in sich konsistent, – testbar, – verstehbar für alle Stakeholder, – umsetzbar — realisierbar, – notwendig, – eindeutig und positiv formuliert sein. Zwei weitere Merkmale: – Lösungsneutralität – einschränkende Rahmenbedingungen Hinweis: Ziele sind abstrakte Top-Level-Anforderungen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 74 Schablone zur Zielbeschreibung Ziel Stakeholder Was soll erreicht werden? Welche Stakeholder sind in das Ziel involviert? Ein Ziel ohne Stakeholder macht keinen Sinn. Auswirkungen Welche Veränderungen werden für die auf Stakeholder Stakeholder erwartet? RandWelche unveränderlichen Randbedingungen bedingungen müssen bei der Zielerreichung beachtet werden? Abhängigkeiten Ist die Zielverknüpfung mit anderen Zielen unmittelbar verknüpft? Dies kann einen positiven Effekt haben, indem die Erfüllung von Anforderungen zur Erreichung mehrerer Ziele beiträgt. Es ist aber auch möglich, dass ein Kompromiss gefunden werden muss, da Ziele unterschiedliche Schwerpunkte haben. Sonstiges Was muss organisatorisch beachtet werden? Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 75 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 Projektsstands tragen Mitarbeiter ihre Arbeitszeit und den erreichten Fertigstellungsgrad in das System ein. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 76 Ziele für eine Projektmanagementsoftware (1/3) Ziel 1. Die Software muss die Planung und Analyse aller laufenden Projekte ermöglichen Projektplaner, Projektleiter, Mitarbeiter, Controlling Stakeholder (alle als Endanwender) Auswirkungen Projektplaner: Alle Planungsdaten fließen in das auf Stakeholder 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. Existierende Datenbestände sollen übernommen Randbedingungen werden. Die Randbedingungen zur Verarbeitung personalbezogener Daten sind zu beachten. Abhängigkeiten Es liegt eine Studie des Kunden vor, warum kein Sonstiges Produkt vom Markt zur Realisierung genommen wird. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 77 Ziele für eine Projektmanagementsoftware (2/3) Ziel 2. Der neue Kunde soll von der fachlichen Kompetenz unseres Unternehmens überzeugt werden. Management, Entwickler Stakeholder Auswirkungen Management: Der Projekterfolg hat große auf Stakeholder Auswirkungen auf die nächsten beiden Jahresbilanzen. Entwickler: Es werden hohe Anforderungen an die Software-Qualität gestellt. Es muss noch geprüft werden, ob langfristig eine Randfür beide Seiten lukrative Zusammenarbeit bedingungen ü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. Das Verhalten des neuen Kunden bei Sonstiges Änderungswünschen ist unbekannt. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 78 Ziele für eine Projektmanagementsoftware (3/3) Ziel 3. Das neue Produkt soll für einen größeren Markt einsetzbar sein. Management, Vertrieb, Entwickler Stakeholder Auswirkungen Management: Es soll eine Marktposition auf dem auf Stakeholder 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) Eine Analyse der Konkurrenten auf dem Markt liegt Sonstiges vor. Es sind Möglichkeiten für neue, den Markt interessierende Funktionalitäten aufgezeigt worden. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 79 Überblick über den Analyseprozess 4.2 1. Erfassung der Systemaufgaben mit „Use Cases“ 2. Beschreibung der Aufgaben mit Aktivitätsdiagrammen (optional 3. Formalisierung der Beschreibungen in Anforderungen) 4. Aufbau eines tieferen Verständnisses durch Klassenmodellierung und Sequenzdiagramme (Grobdesign) iterativer Prozess Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 80 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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 81 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 82 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 SWSystem 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 83 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 84 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 85 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“ Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 86 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 87 Abgeleitetes Use Case-Diagramm Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 88 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? Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 89 Verfeinerung der Use Case-Dokumentation 4.3 • Im ersten Schritt werden in den Use Cases nur die Hauptaufgaben des Systems beschrieben • Zur Dokumentation der Use Cases gehört zunächst nur eine grobe kurze Beschreibung (maximal 5 Sätze) des Inhalts • Im nächsten Schritt wird dieser Inhalt konkretisiert. Dabei ist es sinnvoll, auf eine Dokumentationsschablone zurück zu greifen (oder eine für das Projekt zu entwickeln) • Im ersten Schritt der Beschreibungsentwicklung wird nur der typische Ablauf des Use Cases ohne Alternativen, dann mit Alternativen beschrieben Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 90 Dokumentationsschablone für Use Cases (1/3) Name des Use Case Nummer 1 Paket 2 Autor 1 Version 1 Kurzbeschreibung beteiligte Aktoren (Stakeholder) 1 1 1 kurze prägnante Beschreibung, meist aus Verb und Nomen eindeutige Nummer zur Verwaltung, sollte von der eingesetzten Entwicklungsumgebung vergeben werden bei sehr komplexen Systemen können Use Cases in Teilaufgabenbereiche zusammengefasst werden, diese Bereiche können in der UML als Pakete dargestellt werden wer hat den Use Case erstellt und wer mitgearbeitet aktuelle Versionsnummer, möglichst mit Änderungshistorie, wer hat wann was geändert kurze Beschreibung, was mit dem Use Case auf welchem Weg erreicht werden soll, welche Aktoren sind beteiligt, wer stößt den Use Case an Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 91 Dokumentationsschablone für Use Cases (2/3) Fachverantwortlicher 1 Referenzen 2 Vorbedingungen Nachbedingungen 2 typischer Ablauf 2 alternative Abläufe 3 2 wer steht auf fachlicher Seite für Fragen zum Use Case zur Verfügung und entscheidet auf Auftraggeberseite für die Software über den Inhalt Nennung aller Informationen, die bei der späteren Ausimplementierung zu beachten beziehungsweise hilfreich sind, dies können Verweise auf Gesetze, Normen oder Dokumentationen existierender Systeme sein was muss erfüllt sein, damit der Use Case starten kann wie sieht das mögliche Ergebnis aus, im nächsten Schritt sind auch die Ergebnisse alternativer Abläufe zu berücksichtigen welche einzelnen Schritte werden im Use Case durchlaufen, dabei wird nur der gewünschte typische Ablauf dokumentiert welche Alternativen existieren zum typischen Ablauf Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 92 Dokumentationsschablone für Use Cases (3/3) Kritikalität 3 Verknüpfungen 3 funktionale 4 Anforderungen nicht4 funktionale Anforderungen wie wichtig ist diese Funktionalität für das Gesamtsystem welche Zusammenhänge bestehen zu anderen Use Cases welche konkreten funktionalen Anforderungen werden aus diesem Use Case abgeleitet welche konkreten nicht-funktionalen Anforderungen werden aus diesem Use Case abgeleitet • Nummer gibt Iteration an, in der das Feld gefüllt wird • typischer und alternative Abläufe werden jetzt genauer betrachtet • funktionale und nicht-funktionale Anforderungen weiter hinten in diesem Abschnitt Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 93 Beispielbeschreibung (1/2) Name des Use Case Projektstruktur bearbeiten Nummer U1 Paket - Autor Ali Analytiker Version 1.0, 30.01.2008, Erstellung Kurzbeschreibung 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) Fachverantwortlicher Lisa Leitung (zentrale Ansprechpartnerin des Kunden) Referenzen Handbuch zur Führung von Projekten des Kunden Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 94 Beispielbeschreibung (2/2) Vorbedingungen Die Software ist vollständig installiert und wurde gestartet. Nachbedingungen Neue Projekte und Teilprojekte sowie Änderungen von Projekten und Teilprojekten wurden vom System übernommen. typischer Ablauf 1. 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ät sehr hoch, System macht ohne Funktionalität keinen Sinn Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 95 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! Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 96 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 97 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: A <<include>> B • In spitzen <<Klammern>> stehen so genannte Steoreotypen, mit denen man UML-Elementen zusätzliche Eigenschaften zuordnen kann Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 98 Beispiel zu <<include>> Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 99 <<extend>> • Seltene Variation des erweiterten Use Cases • Wird nur unter bestimmter Bedingung ausgeführt, z. B. Sonderfall oder Fehlerbehandlung • eigentlicher Use Case nicht durch Spezialfälle überfrachtet Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 100 Hinweis zu <<include>>, <<extend>> (persönlich) • <<include>> ist ein sehr nützlicher Stereotyp, der die Dokumentation verkürzen kann • Gerade bei in der Modellierung unerfahrenen Kunden sollte <<include>> zunächst verheimlicht werden, da sonst funktionale Zerlegungen in Bäumen das Ergebnis sind • <<include>> wird dann bei der Dokumentation und späteren Verfeinerung bei der Umstrukturierung der Use Cases als Optimierung eingesetzt • Hinweis: <<extend>> und weitere nicht erwähnte Möglichkeiten werden hier ignoriert, da es Kunden eher verwirrt Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 101 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 102 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. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 103 Aktivitätsdiagramm mit typischen Ablauf Use Case: Projektstruktur bearbeiten Anmerkung: typischer Ablauf ist immer einfache Sequenz von Aktionen, Ausnahme wie hier: einfache Schleifen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 104 Aktivitätsdiagramm um Alternativen ergänzt Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 105 Formulierung von Anforderungen 4.4 • Analog zu den Use Cases sind die Aktivitätsdiagramme zu dokumentieren, dabei ist genau zu beschreiben, was unter Nutzung welcher Hilfsmittel unter Berücksichtigung welcher Nebenbedingungen gilt • Die Beschreibungen können oft unvollständig oder unklar formuliert sein, so dass es in größeren oder kritischeren Projekten sinnvoll ist, die Texte genauer zu analysieren • Statt einer Fließtextdokumentation von Aktivitätsdiagrammen, kann eine Darstellung von systematisch abgeleiteten textuellen Anforderungen sinnvoll sein • Man benötigt einen Ansatz, Texte möglichst präzise zu formulieren Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 106 Probleme mit natürlich-sprachlichen Formulierungen • Auslassungen bzw. implizite Annahmen, da etwas für Experten „offensichtlich“ ist • Tilgung: „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? • Generalisierung: „Das System soll eine Sicherung von aufgezeichneten Auszahlungsdaten auf ein externes Speichermedium ermöglichen.“ Durch jede Person? Immer? Alle Auszahlungsdaten? • Nominalisierung: „Die Auszahlung wird nach der Buchung durchgeführt“ Wer? bucht wann? Was? Wohin? Unter Einhaltung welcher Regeln? Wem? wird wo? ausgezahlt • In Prosatexten sind Wiederholungen unerwünscht; bei Anforderungen müssen immer die gleichen Worte für den gleichen Sachverhalt genutzt werden Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 107 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 108 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? Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 109 Visualisierung der Systemaktivitäten Typ 2 Anforderungen: Funktionalität zur Verfügung stellen Typ 1 Anforderungen: System führt Prozess aus stößt an Nutzer ruft auf Schnittstelle externer Prozess stößt an zu entwickelndes System System-Kern macht Eingaben Typ 3 Anforderungen: System fähig, externe Anfrage zu bearbeiten Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 110 Anforderungsformulierung - muss <Wann?> <Randbedingung> soll Typ 1 Typ 2 das System <wem?> die Möglichkeit bieten <Objekt mit Randbedingung> <Prozesswort> wird fähig sein Typ 3 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 111 Typ 1: Selbständige Systemaktivität - muss <Wann?> <Randbedingung> soll Typ 1 Typ 2 das System <wem?> die Möglichkeit bieten <Objekt mit Randbedingung> <Prozesswort> wird fähig sein Typ 3 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 im Glossar 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. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 112 Typ 2: Benutzerinteraktion - muss <Wann?> <Randbedingung> soll Typ 1 Typ 2 das System <wem?> die Möglichkeit bieten <Objekt mit Randbedingung> <Prozesswort> wird fähig sein Typ 3 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. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 113 Typ 3: Schnittstellenanforderung - muss <Wann?> <Randbedingung> soll Typ 1 Typ 2 das System <wem?> die Möglichkeit bieten <Objekt mit Randbedingung> <Prozesswort> wird fähig sein Typ 3 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 … ) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 114 Vom Aktivitätsdiagramm zur textuellen Anforderung • Jede Aktion wird mit einer Anforderung oder mehreren Anforderungen beschrieben • Jede Entscheidung wird mit einer Anforderung oder mehreren Anforderungen beschrieben • Aus dem Ablauf der zur Aktion oder Entscheidung führt, wird der erste Teil der jeweiligen Anforderung („Wann?“) erzeugt • Hinweis: Anforderungen zum Beispiel stehen im folgenden Kapitel Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 115 Nicht-funktionale Anforderungen (1/2) [sehr kurz] 4.5 • Bisher lag der Schwerpunkt auf funktionalen Anforderungen „was muss das System machen“ • SW unterliegt unterschiedlichen nicht-funktionalen Anforderungen, die maßgeblich für den Projekterfolg sein können Hier wird eine Charakterisierung vorgestellt: • technische Anforderungen: Hardwareanforderungen, Architekturanforderungen, Anforderungen an die Programmiersprachen • Anforderungen an die Benutzungsschnittstelle: Form und Funktion von Ein- und Ausgabe-Geräten • Anforderungen an die Dienstqualität: DIN EN ISO 66272 unterteilt die Dienstgüte in die fünf Merkmale Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 116 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 117 Lastenheft / Pflichtenheft 4.6 • Struktur 0. Administrative Daten: von wem, wann genehmigt, ... 1. Zielbestimmung und Zielgruppen In welcher Umgebung soll das System eingesetzt werden? Was soll das System lösen, welche Stakeholder betroffen? 2. Funktionale Anforderungen Produktfunktionen (Anforderungen) Produktschnittstellen 3. Nichtfunktionale Anforderungen Qualitätsanforderungen weitere technische Anforderungen 4. Lieferumfang 5. Abnahmekriterien 6. Anhänge (insbesondere Glossar) • Alternativ / zusätzlich kann der Auftragnehmer ein Pflichtenheft schreiben, detaillierter als Lastenheft • Lasten- oder Pflichtenheft ist zentraler Vertragsbestandteil Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 118 5. Grobdesign 5.1 5.2 5.3 5.4 5.5 Systemarchitektur Ableitung von grundlegenden Klassen Ableitung von Methoden und Kontrollklassen Validierung mit Sequenzdiagrammen Überlegungen zur Oberflächenentwicklung Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 119 Systemarchitektur 5.1 Festlegen der Randbedingungen bzgl. Hardware, Betriebssystem, verwendeter Software, zu integrierender Systeme • Vorgabe der Hardware, die Software muss z. B. auf einer Spezialhardware funktionieren • Vorgabe des Betriebssystems, die Software muss eventuell mit anderer Software auf Systemebene zusammenarbeiten • Vorgabe der Middleware, die Software wird häufig auf verschiedene Prozesse verteilt, die miteinander kommunizieren müssen • Vorgaben zu Schnittstellen und eingesetzten Programmiersprachen, die Software soll mit anderer Software kommunizieren und muss dabei deren Schnittstellen berücksichtigen • Vorgaben zum „Persistenzframework“, die Daten der zu erstellenden Software müssen typischerweise langfristig gespeichert werden Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 120 Beispiel: Projektstrukturplan 5.2 Projekt Perpetuum (Teil-)Projekt Aufgabe Projektleitung P. Palaver (30%) Qualitätssicherung Projektinfrastruktur QS-Leitung G. Genau (30%) Adminstration S. Super (20%) Tester P. Penibel (100%) Installation P. Prökel (50%) Entwicklung Entwicklungsleitung P. Palaver (70%) Sicherung S. Safe (20%) Oberflächenentwicklung Programmierung W. Widget (100 %) Businessmodell Datenbankanbindung Analyse S. Schlaubi (100 %) Programmierung E. Entität (100 %) Programmierung M. Muster (100 %) Programmierung H. Hack (100 %) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 121 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 122 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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 123 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 124 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. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 125 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. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 126 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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 127 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 128 UML-Notation • Assoziationen: Beziehung zwischen Klassen • Rollenname am Ende entspricht Exemplarvariablennamen • Multiplizitäten „von..bis“, * für beliebig, alternativ 0..* statt * Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 129 Zusammenhang Klasse und Objekt • • • • Objekte lassen sich auch in der UML darstellen Kasten mit unterstrichenem „:<Klassenname>“ vor Doppelpunkt kann Objektname stehen Objekte werden nicht im Klassendiagramm dargestellt Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 130 UML unterstützt iteratives Vorgehen • UML-Teile weggelassen bzw. ausblenden, abhängig von notwendigen bzw. vorhandenen Teilinformationen • Je implementierungsnäher desto detaillierter Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 131 Zweite Iteration: Methoden suchen 5.3 • Methoden stehen für Funktionalität, die ein Objekt anbietet; typisch: Zustand (d. h.) Exemplarvariable ändern, Ergebnis basierend auf Exemplarvariablen berechnen • Ansatz 1: Analysiere Verben im Text • Ansatz 2: Aus Use Cases lässt sich häufig eine Steuerungsklasse (Koordinationsklasse) ableiten • folgende Anforderungen an die Klassenformulierung müssen beachtet werden: – Klassen übernehmen jeweils eine Aufgabe und besitzen genau die zur Durchführung benötigten Methoden und die für die Methoden benötigten Exemplarvariablen – Klassen sollen möglichst wenig andere Klassen kennen, wodurch die Schnittstellenanzahl gering gehalten wird • (Hinweis: unser Beispiel ist datenlastig, deshalb wenige Methoden) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 132 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. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 133 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 addund 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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 134 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 135 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 136 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 137 Klassendiagramm Hinweis: Als Handout verteilen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 138 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 nichtimplementierten 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 139 Beispiel: Vererbung nächster Schritt: Prüfen, wo statt Projekt und Projektaufgabe Projektkomponente stehen kann (Abstrahierung) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 140 Aufzählungen • Häufiger gibt es Exemplarvariablen, die bestimmte Werte, z. B. {rot,gelb,grün} annehmen können • Aufzählungstypen werden in der UML wie rechts gezeigt beschrieben • Der Stereotyp <<enumeration>> gibt an, dass es sich um eine Klasse mit bestimmten Eigenschaften handelt • Die UML hat einige Stereotypen vorgegeben; weitere können beliebig vereinbart werden. • Wie bei allen UML-Sprachelementen gilt, dass man vor dem Modellierungsstart festlegen muss, welches Diagramm und welche Notation wann eingesetzt werden soll Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 141 Validierung mit Sequenzdiagrammen 5.4 • Mit Hilfe des erreichten Modells kann man mit Sequenzdiagrammen validieren, ob die im Aktivitätsdiagramm beschriebenen Abläufe möglich sind • rechte Seite zeigt verschiedene Darstellungsmöglichkeiten eines Methodenaufrufs • Rückgabewerte werden häufig weggelassen, wenn nur Ablauf wichtig • (Stellen auch Testfälle dar) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 142 Zusammenhang zwischen Aktivitäts- und Sequenzdiagrammen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 143 Highlevel-Sequenzdiagramme Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 144 Beispiel: Initialisierung • Anmerkung: Typischerweise „befruchten“ sich die Entwicklung von Klassendiagrammen und Sequenzdiagrammmen (Optimierung in einem iterativen Prozess) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 145 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 146 Beispiel: Fertigstellungsgrad berechnen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 147 Beispiel: Prüfung Projektaufwand aktualisierbar (1/2) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 148 Beispiel: Prüfung Projektaufwand aktualisierbar (2/2) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 149 Beispiel: Projektaufgabenaufwand aktualisierbar? Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 150 GUI-Modellierung 5.5 • fachlich hängt Oberfläche (GUI, Graphical User Interface) eng mit unterliegendem Geschäftsklassenmodell (bisher behandelt) zusammen • möglicher Ansatz: „Mache alle Modellanteile an der Oberfläche sichtbar, die ein Nutzer än-dern oder für dessen Inhalte er sich interessieren kann.“ • Variante: mache ersten GUI-Prototyp und halte bei Ein- und Ausgaben fest, welche Modellinformationen sichtbar sein sollen • GUI-Prototyp gut mit Kunden dieskutierbar • Hinweis: Thema Softwareergonomie später Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 151 Erweiterung mit Boundary-Klassen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 152 Sequenzdiagramm mit Nutzungsdialog Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 153 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 154 Anforderungsverfolgung - Beispielzusammenhänge Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 155 6. Vom Klassendiagramm zum Programm 6.1 6.2 6.3 6.4 6.5 6.6 CASE-Werkzeuge Übersetzung einzelner Klassen Übersetzung von Assoziationen Spezielle Arten der Objektzugehörigkeit Aufbau einer Software-Architektur Weitere Schritte zum lauffähigen Programm Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 156 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 157 UML-Toolsuiten / CASE-Werkzeuge 6.1 Theorie: • UML-Werkzeuge unterstützen die automatische Umsetzung von Klassendiagrammen in Programmgerüste (Skelette) • Entwickler müssen die Gerüste mit Code füllen • viele Werkzeuge unterstützen Roundtrip-Engineering, d.h. Änderungen im Code werden auch zurück in das Designmodell übernommen (wenn man Randbedingungen beachtet) • Roundtrip beinhaltet auch Reverse-Engineering Praxis: • sehr gute kommerzielle Werkzeuge (z. B. IBM Rational, Borland Together); allerdings muss man für Effizienz Suite von Werkzeugen nutzen; d. h. auf deren Entwicklungsweg einlassen • ordentliche nicht kommerzielle Ansätze für Teilgebiete; allerdings Verknüpfung von Werkzeugen wird aufwändig Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 158 Übersetzung einfacher Diagramme (1/3) 6.2 Anmerkung: auch bei Realisierung kann vereinbart werden, dass getund set-Methoden in Übersichten weggelassen (und damit als gegeben angenommen) werden Klassenmethoden sind unterstrichen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 159 Übersetzung einfacher Diagramme (2/3) public class Mitarbeiter { /** * @uml.property name="minr" */ private int minr; /** * Getter of the property <tt>minr</tt> * @return Returns the minr. * @uml.property name="minr" */ public int getMinr() { return minr; } /** * Setter of the property <tt>minr</tt> * @param minr The minr to set. * @uml.property name="minr" */ public void setMinr(int minr) { this.minr = minr; } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 160 Übersetzung einfacher Diagramme (3/3) private String vorname = ""; public String getVorname() { return vorname;} public void setVorname(String vorname) { this.vorname = vorname; } private String nachname = ""; public String getNachname() {return nachname;} public void setNachname(String nachname) { this.nachname = nachname; private static int mitarbeiterzaehler; public static int getMitarbeiterzaehler() { return mitarbeiterzaehler; } public static void setMitarbeiterzaehler (int mitarbeiterzaehler) { Mitarbeiter.mitarbeiterzaehler = mitarbeiterzaehler; } } = evtl. notwendige Korrekturen, bei CASE-Werkzeug Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 161 Notwendige Code-Ergänzung durch Entwickler public Mitarbeiter(String vorname, String nachname){ this.vorname=vorname; this.nachname=nachname; this.minr=Mitarbeiter.mitarbeiterzaehler++; } @Override public String toString() { return minr+": "+vorname+" "+nachname; } = vom Entwickler ergänzt Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 162 Umgang mit Assoziationen im Design 6.3 • Assoziationen zunächst nur Strich mit Namen (und Multiplizitäten) • für Implementierung jede Assoziation konkretisieren (Richtung der Navigierbarkeit, Multiplizitäten sind Pflicht) public class Projektaufgabe { /** werkzeugspezifische Kommentare weggelassen */ private Mitarbeiter bearbeiter; public Mitarbeiter getBearbeiter() { return bearbeiter; } public void setBearbeiter(Mitarbeiter bearbeiter) { this.bearbeiter = bearbeiter; } } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 163 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 164 Multiplizität n (1/2) • Umsetzung als Collection (Sammlung, Container) • Umsetzung hängt von Art der Collection ab – sollen Daten geordnet sein – sind doppelte erlaubt – gibt es spezielle Zuordnung key -> value • Entwickler muss zur Typwahl spätere Nutzung kennen • eine Umsetzung für 1..* import java.util.List; import java.util.ArrayList; public class Projektaufgabe { private List<Mitarbeiter> bearbeiter = new ArrayList<Mitarbeiter>(); • bitte, bitte in Java nicht alles mit ArrayList realisieren (!!!) • Multiplizität 0..7 als Array umsetzbar Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 165 Multiplizität n (2/2) • Zum Codefragment der letzten Zeile passt besser folgendes Klassendiagramm * • Hinweis: Standardhilfsklassen z. B. aus der JavaKlassenbibliothek 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 166 Arten der Zugehörigkeit (Aggregation 1/2) 6.4 • nicht exklusiver Teil eines Objekts (Mitarbeiter kann bei mehreren Projektaufgaben Bearbeiter sein) • in C++: Mitarbeiter *bearbeiter; Mitarbeiter* Projektaufgabe::getBearbeiter(){ return bearbeiter;} oder Mitarbeiter bearbeiter; Mitarbeiter& Projektaufgabe::getBearbeiter(){ 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 167 Arten der Zugehörigkeit (Aggregation 2/2) • Designansatz: Verhindern unerwünschten Zugriffs durch Interface (generell gute Idee !) Kurzdarstellung Interfacerealisierer: Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 168 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 169 Arten der Zugehörigkeit (Komposition 2/2) • Java arbeitet nur mit Zeigern (unschöne Ausnahme sind Elementartypen), wie realisiert man @Override // in Mitarbeiter.java public Mitarbeiter clone(){ // echte Kopie Mitarbeiter ergebnis= new Mitarbeiter(); ergebnis.minr=minr; ergebnis.nachname=nachname; //Strings sind ergebnis.vorname=vorname; //Konstanten return ergebnis; } // in Projektaufgabe public Mitarbeiter getBearbeiter() { return bearbeiter.clone(); } • Variante: bei Realisierung überall doll aufpassen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 170 Kurzzeitige Klassennutzungen • Klassen nutzen andere Klassen nicht nur für Exemplar- (und Klassen-) Variablen • Klassen erzeugen Objekte anderer Klassen lokal in Methoden, um diese weiter zu reichen public class Projektverwaltung { private Projekt selektiertesProjekt; public void projektaufgabeErgaenzen(String name){ Projektaufgabe pa= new Projektaufgabe(name); selektiertesProjekt.aufgabeHinzufuegen(pa); } • Klassen nutzen Klassenmethoden anderer Klassen • In der UML gibt es hierfür den „Nutzt“-Pfeil • (Omondo: <<include>>) • Wenn zu viele Pfeile im Diagramm, dann mehrere Diagramme mit gleichen Klassen zu unterschiedlichen Themen • UML-Werkzeuge unterstützen Analyse von Abhängigkeiten Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 171 Erstellen einer Softwarearchitektur 6.5 • Ziel des Design ist ein Modell, welches das Analysemodell vollständig unter Berücksichtigung implementierungsspezifischer Randbedingungen umsetzt • allgemeine Randbedingungen: Es gibt ingenieurmäßige Erfahrungen zum gutem Aufbau eines Klassensystems; dieses wird auch SW-Architektur genannt • Ziele für die Architektur – Performance – Wartbarkeit – Erweiterbarkeit – Verständlichkeit – schnell realisierbar – Minimierung von Risiken Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 172 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 173 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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 174 Beispiel: grobe Paketierung (eine Variante) • Anmerkung: Datenverwaltung noch nicht konzipiert Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 175 Beispiel: grobe Paketierung (zweite Variante) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 176 Forderung: azyklische Abhängigkeitsstruktur Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 177 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::Projektmitarbeiter; namespace Fachklassen{ namespace Projektdaten{ class Projektaufgabe{ private: Mitarbeiter *bearbeiter; // ... }; } } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 178 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 179 Trick: Abhängigkeit umdrehen • generell können Interfaces häufiger in anderen Paketen liegen, als ihre Implementierer • Java-Klassenbibliothek Swing fordert häufig die InterfaceImplementierung bei der Ereignisbehandlung Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 180 Architektursichten 6.6 • Paket- und Klassendiagramme geben einen guten Überblick über die Ergebnisse des statischen SWEntwurfs • 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 181 4+1 Sichten Logische Sicht - funktionale Analyseergebnisse - Klassenmodell Implementierungssicht - Subsysteme - Schnittstellen Szenarien Ablaufsicht - Prozesse - Nebenläufigkeit - Synchronisation Grundkurs Software-Engineering mit UML, 2. Auflage Physische Sicht - Zielhardware - Netzwerke Stephan Kleuker 182 4+1 Sichten mit (Teilen der) UML Logische Sicht Implementierungssicht - Komponenten- - Klassendiagramme - Paketdiagramme diagramme Szenarien -Use Case-Diagramme - Aktivitätsdiagramme Ablaufsicht - Sequenzdiagramme Physische Sicht - Kommunikations- Deploymentdiagramme - Zustandsdiagramme diagramme Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 183 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 AktiveKlasse aktivesObjekt: AktiveKlasse • Prozessverhalten u. a. durch Sequenzdiagramme beschreibbar • (übernächste VL etwas mehr; gibt eigenes Modul dazu) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 184 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 185 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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 186 Physische Sicht: vorgegebene HW mit Vernetzung • Einsatz- und Verteilungsdiagramm (deployment diagram) • Knoten steht für physisch vorhandene Einheit, die über Rechenleistung oder/und Speicher verfügt • <<executable>> (ausführbare Datei) und <<artifact>> (Datei) müssen zur HW-Beschreibung nicht angegeben werden Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 187 7. Konkretisierungen im Feindesign 7.1 Zustandsdiagramme 7.2 Object Constraint Language Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 188 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 189 Zustandsdiagramme 7.1 • generell wird der Zustand eines Objekts durch die Werte seiner Exemplar- und Klassenvariablen beschrieben • Häufig wird der Begriff Zustand auch für eine spezielle Exemplarvariable genutzt, die z. B. über eine Enumeration realisierbar ist • z. B. : Ampel: rot, rotgelb, gelb, grün • z. B. : Projekt: vorbereitet, grob geplant, Mitarbeiter zugeordnet, verschoben, in Bearbeitung, in Endabnahme, in Gewährleistung, beendet • Die Übergänge zwischen den Zuständen werden durch Ereignisse, zumeist Methodenaufrufe, veranlasst • Die Übergänge lassen sich durch ein Zustandsdiagramm (ursprünglich Statechart nach D. Harel) spezifizieren • Zustandsautomaten spielen auch in der theoretischen und technischen Informatik eine zentrale Rolle Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 190 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 191 Beispiel: Zustandsdiagramm eines Projekts • man erkennt: nach Planung keine Planungsänderung Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 192 Hierarchische Zustände Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 193 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 194 Beispiel: Uhr Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 195 Zustandsmodellierung und Realzeitsysteme • in klassischen OOProgrammen 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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 196 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 197 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 198 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] Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 199 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 200 Beispiel: Start-Stopp-Automatik (3/3) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 201 GUI als Zustandsautomat Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 202 Klassendiagramm und versteckte Randbedingungen 7.2 • Welche Randbedingungen vermuten Sie? Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 203 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 204 Einfache Bedingungen für Objekte (Invarianten) • Die Matrikelnummer ist mindestens 10000 context Studi inv hoheMatrikelnummern: self.matnr>=10000 • eine Variante: context s:Studi inv: s.matnr>=10000 • context gibt eindeutig an, um welche Klasse es geht • Strukturierung durch Nutzung der Paketstruktur package com::meineFirma::meineSW context Studi inv: ... context Studi inv: ... endpackage Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 205 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()@pre= self.belegteVeranstaltungen()-1 • self.belegteVeranstaltungen()@pre, für Ergebnis vor der Methodenausführung Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 206 Einschub: Basistypen und Operationen • Jeder OCL-Ausdruck hat einen Typ • Verknüpfe Ausdrücke müssen vom Typ her passen • Geringe Typanpassungen möglich Typ Beispielwerte Boolean true, false Integer 1, -5, 42, 4242424242 Real 3.14, 42.42, -99.999 String 'Hallo Again', 'Heidi', '' Typ Beispieloperationen Boolean and,or,xor,not,implies,if then else endif Integer *, +, -, /, abs() Real *, +, -, /, floor() String concat(), size(), substring() Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 207 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 208 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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 209 Beispiele: Mengenoperationen (1/2) • bei der Betrachtung zugehöriger Objekte ist das Ergebnis meist eine Collection von Objekten • in OCL auch: Set, OrderedSet, Sequence, Bag • auf Collections existieren verschiedene Methoden, genereller Aufruf collection -> methode(<parameter>) • Ergebnis kann wieder eine Collection oder ein Wert eines anderen Typs sein • Studi macht höchstens 12 Veranstaltungen context Studi inv: studi.studienfach -> select (s | s.status = Veranstaltungsstatus::laeuft) -> size() <= 12 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 210 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)) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 211 8. Optimierung des Designmodells 8.1 8.2 8.3 8.4 Design im Kleinen Model View Controller Vorstellung einiger GoF-Pattern Abschlussbemerkungen zu Pattern Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 212 Zentrale Aufgabe: von Analyse zum Design • 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 • für Assoziationen – Multiplizitäten beachten – über mögliche Richtungen nachdenken – Art der Zugehörigkeit klären • GUI-Klassen und persistente Datenhaltung einbauen • Anmerkung: Übergang von Analyse zu Design ist durch Iterationen (Verfeinerungen) fließend Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 213 Einfache Basisregeln 8.1 • KISS = Keep It Simple Stupid, man soll die einfachst mögliche Realisierung wählen, die das Problem vollständig löst und gut nachvollziehbar ist (kein „Quick and Dirty“, sondern eine klare Entscheidung für einen einfachen Entwicklungsstil) • YAGNI = You Ain’t Gonna Need It, keine Verallgemeinerungen entwickeln, die das Design für theoretisch in der Zukunft vielleicht gewünschte Erweiterungen vereinfachen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 214 Keine allwissenden Klassen besser: Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 215 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 216 „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); } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 217 Erinnerung: Bedeutung von Schnittstellen • Schnittstellen sind zentrales Element des Design by Contract • vorgegebene Aufgabe: Implementiere mir folgende Funktionalität ... beschrieben durch – Vorbedingung – Signatur <Sichtbarkeit> <Methodenname>(<Parameter>)... – Nachbedingung • Entwickler realisiert OO-Programm (Details sind frei) • Entwickler garantiert, dass Schnittstelle (oder Fassade) gewünschte Funktionalität liefert • generell sollte man bei Vererbungen und Implementierungen die am wenigsten spezielle benötigte Klasse nutzen; deshalb List<Projektaufgaben> aufgaben und nicht ArrayList<Projektaufgaben> aufgaben im Code Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 218 Erinnerung: Bedeutung von Polymorphie (1/2) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 219 Erinnerung: Bedeutung von Polymorphie (2/2) 8Rechteck: 273 #include <iostream> 5Kreis: 201.062 8Rechteck: 56 #include <typeinfo> 5Kreis: 50.2655 #include "Rahmen.h" 6RahmenI8RechteckS0_E: 217 #include "Rechteck.h" 6RahmenI8Rechteck5KreisE: 222.735 #include "Kreis.h" 6RahmenI5Kreis8RechteckE: 145.062 6RahmenI5KreisS0_E: 150.796 int main(void){ Rechteck re1(Punkt(6,16),Punkt(27,3)); Kreis k1(Punkt(15,9),8); Rechteck re2(Punkt(12,13),Punkt(19,5)); Kreis k2(Punkt(15,9),4); Rahmen<Rechteck,Rechteck> r1(re1,re2); Rahmen<Rechteck,Kreis> r2(re1,k2); Rahmen<Kreis,Rechteck> r3(k1,re2); Rahmen<Kreis,Kreis> r4(k1,k2); GeoObjekt *g[8]={&re1,&k1,&re2,&k2,&r1,&r2,&r3,&r4}; for(int i=0;i<8;i++) std::cout<<typeid(*g[i]).name()<<":\t„ <<g[i]->flaeche()<<"\n"; return 0; } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 220 Umgang mit Collections • Collections sollen als Rückgabeparameter vermieden werden, damit nicht alle Collection-Methoden nutzbar sind • Ansatz: Iteratoren auf Listen zurück geben • Java: Interface Iterable implementieren public interface Iterable<T> Implementing this interface allows an object to be the target of the "foreach" statement. Method Summary Iterator<T> iterator() Returns an iterator over a set of elements of type T. • Methode gibt dann (schon implementierten) Iterator der Collection zurück • Iterator leicht selbst zu implementieren, mit Methoden boolean hasNext() Returns true if the iteration has more elements. E next() Returns the next element in the iteration. void remove() Removes from the underlying collection the last element returned by the iterator (optional operation). Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 221 Grundidee von Design-Pattern 8.2 Damit nicht alle Klassen eng miteinander gekoppelt sind, gibt es Ansätze: • die Aufgaben einer Klasse von der Verwaltung der Klassen, die Informationen dieser Klasse benötigen, zu trennen • die Erzeugung von Objekten möglichst flexibel zu gestalten • Interfaces zur Trennung von Implementierung und angebotenen Methoden einzusetzen • Hierzu werden so genannte Design-Pattern eingesetzt, die für einen bestimmten Aufgabentyp eine flexible Lösung vorschlagen • oft zitiert: E. Gamma, R. Helm, R. Johnson, J. Vlissides, Entwurfsmuster, Addison-Wesley, 2004 (Gang of Four [GoF]Buch, hier neuere Auflage) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 222 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 ModelView-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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 223 Java-Beispiel zum MVC (1/6) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 224 Java-Beispiel zum MVC (2/6) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 225 Java-Beispiel zum MVC (3/6) import java.util.*; public class XModel{ private ArrayList<XModelListener>listener= new ArrayList<XModelListener> (); private int modellwert=42; //Verwaltung der Listener des Modells public void addXModelListener(XModelListener x){ listener.add(x); } private void fireXModelChanged(){ for(XModelListener x:listener) x.xModelChanged(); } //Auslesen der Modellinhalte public int getWert(){ return modellwert; } //Veränderung des Modells public void changeValue(int delta){ modellwert+=delta; fireXModelChanged(); } } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 226 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"); xmodel=x; xmodel.addXModelListener(this); //Rest Swing für Anzeige getContentPane().add(jlabel); setDefaultCloseOperation(EXIT_ON_CLOSE); setSize(250,60); setLocation(0,0); setVisible(true); } } public void xModelChanged() { jlabel.setText("Modellwert: "+xmodel.getWert()); } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 227 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"); xmodel = x; getContentPane().setLayout(new FlowLayout()); JButton plus = new JButton("plus"); getContentPane().add(plus); plus.addActionListener(new ActionListener(){ public void actionPerformed(ActionEvent e){ xmodel.changeValue(1); }}); JButton minus = new JButton("minus"); getContentPane().add(minus); minus.addActionListener(new ActionListener(){ public void actionPerformed(ActionEvent e){ xmodel.changeValue(-1); }}); setDefaultCloseOperation(EXIT_ON_CLOSE); setSize(250,60); setLocation(0,90);´setVisible(true); } Grundkurs Software-Engineering mit UML, 2. Auflage } Stephan Kleuker 228 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); } } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 229 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 230 Ansatz Observer-Observable 8.3 • Es gibt Subjekte für deren Zustand sich viele interessieren (z. B. Nachrichtenkanäle) • Die Subjekte bieten die Möglichkeit, dass sich Interessenten anmelden (z. B. Kanal abonnieren) • Bei jeder Subjektzustandsänderung werden Interessenten informiert (neue Nachrichten) • Interessent muss sich bei Subjekt anmelden • Damit obiges Objekt weiß, wie Interessent angesprochen werden soll, muss Interessent Schnittstelle realisieren • Hinweis: Enge Verwandtschaft zu Model-ViewController Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 231 Beobachter (Observer – Observable) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 232 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 233 Adapter - Lösung public class Adapter implements B{ private C c = null; ... public Adapter(){ c = new C(); } ... @Override public void machWasTolles(){ return c.kannWasWasAuchBKoennenSoll(); } } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 234 Fassade nach außen • Generell sollen Klassen eng zusammenhä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. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 235 Beispielanwendung: Abstract Factory Pattern Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 236 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 237 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 238 Singleton (1/3) public class Singleton { private int x=0; private int y=0; private static Singleton pkt=null; //für 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; } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 239 Singleton (2/3) @Override public Singleton clone(){ //echtes Kopieren verhindern return this; } public void ausgeben(){ System.out.print("["+x+","+y+"]"); } public void verschieben(int dx, int dy){ x+=dx; y+=dy; } } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 240 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); [6,42][6,42] p1.ausgeben(); identisch p2.ausgeben(); [9,47][9,47] Singleton p3=p1.clone(); identisch if(p2==p3) System.out.println("\n identisch"); } } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 241 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 242 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); } } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 243 Proxy – Implementierungsmöglichkeit (2/2) public class Proxy implements KlasseMitWertvollemInhalt { //Variante mit Singleton (gibt Alternativen) private static RealeKlasse realesObjekt; public Proxy(){ if(realesObjekt==null) realesObjekt= new RealeKlasse("Spezialinfos"); } public int anfrage(String details) { return realesObjekt.anfrage(details); } } public class Nutzer { public int proxyNutzen(String anfrage){ KlasseMitWertvollemInhalt k=new Proxy(); return k.anfrage(anfrage); } public static void main(String[] s){ //etwas sinnlos, zu Testzwecken Nutzer n= new Nutzer(); System.out.println(n.proxyNutzen("gib41")); } Grundkurs Software-Engineering mit UML, 2. Auflage } Stephan Kleuker 244 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 WerbeDetailinformationen) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 245 Strategy - Lösungsbeispiel Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 246 State-Pattern Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 247 State-Pattern – Implementierungsauszug (1/2) public abstract class Zustand { protected int x; public abstract Zustand setX(int x); public abstract String status(); protected Zustand(int x){ this.x=x; } } public class ZustandOK extends Zustand{ public ZustandOK(int x) { super(x); } @Override public Zustand setX(int x) { this.x=x; if(x>=42) return new ZustandKritisch(x); return this; } @Override public String status() {return "alles ok";} } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 248 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()); } } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 249 Beschreibung des Pattern 8.4 Name: Abstract Factory Patterngruppe: Objekterzeugung Kurzbeschreibung: Client kann mit einer AbstractFactory zu einer abstrakten Klasse passende Exemplare aus einem Satz konkreter Implementierungen für bestimmtes Produkt erzeugen, kennt den konkreten Typ des erzeugten Exemplars nicht Kontext: viele verschiedene gleichartige, aber unterscheidbare Objekte sollen verwaltet werden Problem: Klasse soll verschiedene Objekte bearbeiten, benötigt aber nur deren gemeinsame Eigenschaften Lösung: Einführung von zwei abstrakten Klassen, die zum Einen Objekterzeugung, zum Anderen Objektzugriff erlauben, Client muss nur diese Klassen kennen Einsatzgebiete: ... Varianten: ... Grundkurs Software-Engineering mit UML, 2. Auflage Struktur: s.o. Stephan Kleuker Beispiele: 250 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) Grundkurs Software-Engineering mit UML, 2. Auflage • Erzeugungspattern sollen das Wissen um das System und die konkreten Klassen des Systems vor dem Benutzer verstecken Zielsetzungen: – Systeme leichter konfigurierbar zu machen – Änderungen im Entwurf vorherzusehen • Verhaltenspattern ... Stephan Kleuker 251 GoF-Pattern Übersicht (nicht auswendig lernen) Objekt Einsatzbereich Klasse Aufgabenbereich Erzeugung Struktur Verhalten Factory Adapter Interpreter Template Abstract Factory Adapter Command Builder Bridge Observer Prototype Decorator Visitor Singleton Facade Memento Composite Strategy Proxy Mediator Flyweight State Chain of Responsibility Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 252 Pattern in der UML Pattern-Name im gestrichelten Kreis, verbunden mit eingekreisten Klassen, verbunden mit Pattern und Bennenung der Rollen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 253 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 !!! Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 254 9. Implementierungsaspekte 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 Domain Specific Languages 9.9 Model Driven Architecture 9.10 Refactoring Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 255 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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 256 Beispiel: Rahmenbedingungen für SW-Architektur 9.1 • Berücksichtigung von speziellen SW-Schnittstellen nicht objektorientiert entwickelter Systeme, z. B. von Application Programming Interfaces (API) fremder SW • Berücksichtigung/Benutzung existierender Datenhaltungssysteme, z. B. Vorgabe des Datenbankmanagementsystems (DBMS) • Berücksichtigung bestimmter Design-Prinzipien, z. B. Gesamtsteuerung mit Enterprise Java Beans (EJB) oder .NET für die Realisierung • Alt-Software (z. B. in COBOL), so genannte LegacySysteme müssen eingebunden werden; Einsatz einer Middleware (z. B. Common Object Request Broker Architecture, CORBA) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 257 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 258 Rahmenbedingung: verteilte Systeme 9.2 • in der klassischen OO-Programmierung gibt es einen Programmablauf (Prozess) und man nutzt synchrone Aufrufe: Objekt O1 ruft Methode von Objekt O2 auf; O2 übernimmt die Programmausführung und antwortet dann O1 • bei verteilten Systemen laufen viele Prozesse parallel ab, die Informationen austauschen können • synchroner Aufruf ist möglich, bedeutet aber, dass Verbindung aufgebaut werden muss und Sender bzw. Empfänger auf Bereitschaft warten müssen • asynchroner Aufruf bedeutet, dass Sender Aufruf abschickt und danach weiterarbeitet; später prüft, ob ein Ergebnis vorliegt • asnychrone Aufrufe sind schneller (nur abschicken); Prozesse sind aber schwer zu synchronisieren • die Herausforderung effizienter verteilter Systeme hat nicht die eine Lösung und wird Sie Ihr Informatik-Leben-lang verfolgen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 259 Probleme der Aufrufmechanismen synchroner Aufruf Problem: Deadlock Prozess A Prozess B Prozess C warten auf Antwort warten auf Antwort asynchroner Aufruf Problem: B denkt, x hat vor y stattgefunden Problem: C denkt, x hat vor y stattgefunden, A denkt, y hat vor x stattgefunden Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 260 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 261 Beispiel: Varianten von Client-Server-Systemen • Thin Client: Hier nur Datenannahme, Weiterleitung, Darstellung, keine komplexen Berechnungen • Beispiele: Web-Browser, DBClients Client Netzwerk • Fat Client: Client führt eigene komplexe Berechnungen aus; nutzt Server nur zur Verwaltung zentraler Informationen und zum Nachrichtenaustausch • Beispiel: vernetzbare Standalone-Spiele (Autorennen) Client Netzwerk Server Server Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 262 Beispiel: 3-Tier-Architektur Client Präsentationsschicht Server für Anwendung eigentliche Anwendungs-SW Datenbank-Server persistente Datenhaltung Grundkurs Software-Engineering mit UML, 2. Auflage 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 Stephan Kleuker 263 Erinnerung: XML 9.3 • eXtensible Markup Language • strukturierte maschinen- und ansatzweise menschenlesbare Informationsbeschreibung • Applikationen müssen Daten vor der Programmbeendung speichern, sollten diese mit anderen Programmen austauschen können (-> Definition eines gemeinsamen XML-Formats) • Neben reiner Syntax kann auch die erlaubte inhaltliche Struktur spezifiziert werden (DTD: Document Type Definition), XMLSchema • Viele gute Werkzeuge und Bibliotheken zur XML-Verarbeitung • zentrale Inhalte werden mit Elementen und Attributen beschrieben • Strukturierung durch Namensräume Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 264 Elemente • Elemente beschreiben zentrale Inhalte von XMLDokumenten • Namen der Elemente können vom Autor frei vergeben werden (soll Dokument mit verschiedenen Applikationen bearbeitet werden, muss man sich auf das Vokabular einigen -> später) • Typische Form <projektname> XML-DB </projektname> • Element heißt projektname, der Inhalt ist vom sogenannten Start- und End-Tag umgeben • Abkürzungsmöglichkeit bei leerem Inhalt: <projektname/> • Leerzeichen führen meist zu Fehlern, hier z. B. drei <■bla > <■/■bla > Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 265 Hierarchischer Aufbau • Elemente können ineinander geschachtelt werden • Ausgehend vom obersten Element ergibt sich ein Baum <team> <mitarbeiter> <minr>42</minr> team <name>Aische Meier</name> <anteil>40</anteil> mitarbeiter mitarbeiter </mitarbeiter> <mitarbeiter> minr name anteil minr name anteil <minr>46</minr> <name>Nabil Ibn</name> <anteil>50</anteil> </mitarbeiter> </team> Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 266 Attribute • Jedes Element kann eine beliebige Anzahl an Attributen haben • Attribute stehen in Anführungsstrichen (" oder ') <projekt abteilung="Entwicklung" vertrag="Festpreis"> <projektname>Speichermodul</projektname> <kunde blz="65566445" knr="35674534" /> <projektleiter kosten="1000"> <minr>49</minr> <name>Ute Rose</name> <anteil>50</anteil> </projektleiter> </projekt> Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 267 Attribute oder Elemente • Attribute beschreiben Eigenschaften von Elementen • Eigentlicher Inhalt steht zwischen den Tags • Aus theoretischer Sicht vertauschbar <projekt abteilung="Entwicklung" vertrag="Festpreis"/> • alternativ <projekt> <abteilung> Entwicklung </abteilung> <vertrag> Festpreis </vertrag> </projekt> • Aus Sicht der Verarbeitung leichte Unterschiede, Tendenz zu Attributen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 268 Kommentare und Namensregeln • Grundsätzlich existieren nur kommentierte Produkte • XML Kommentar in <!-- und --> eingeschlossen <!-- Isch bin ähn Gommenta --> • Im Kommentartext kein -- erlaubt, auch keine Schachtelung • Kommentare in Elementen nicht erlaubt • XML unterscheidet Groß- und Kleinschreibung, Elemente und Attribute meist klein (keine sehr feste Regel) • Bezeichner müssen mit Buchstaben oder _ oder : beginnen • In Bezeichnern beliebige Zeichen erlaubt • Grundregeln für eigene Elementnamen: – selbsterklärend – nicht mit _ oder : beginnen (für Spezialfälle, : generell nicht) – auf Umlaute verzichten Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 269 Genereller Aufbau eines XML-Dokuments • Dokument beginnt mit XML-Deklaration gefolgt von Element • folgt: jedes XML-Dokument als Baum mit Wurzel betrachtbar (mit root element oder document element) <?xml version="1.0" encoding="utf-8"?> <!-- angeblich generiert aus Spro --> <projekt abteilung="Entwicklung" vertrag="Eigenentwicklung"> <projektname>Speicher </projektname> </projekt> • version (bleibt vielleicht immer) 1.0 oder 1.1 • encoding gibt verwendeten Zeichensatz an, hier klein oder Großschreibung möglich, typisch sind UTF-8 8 Bit Zeichenbereite (Standard) UTF-16 16 Bit Zeichenbreite (bel. Sprachen) ISO-8859-1 Westeuropäische Sprachen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 270 Nutzung von Programmbibliotheken 9.4 • Programmbibliotheken stellen Standardlösungen für häufig wiederkehrende Probleme dar • typische Nutzung: Nutzer erzeugt und ruft Objekte (Klassen) der Bibliothek auf • Bibliotheken sind geprüft (hoffentlich) und für Laufzeiten optimiert • Dokumentation von Bibliotheken wichtig zum effizienten Einsatz (was rufe ich wann auf) • Je größer der Verbreitungsgrad, desto einfacher die Weiterverwendung von Ergebnissen (großer Vorteil der JavaKlassenbibliothek) • 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 271 Idee von Komponenten 9.5 • Komponenten sind komplexe in sich abgeschlossene „binäre“ SW-Bausteine, die größere Aufgaben übernehmen können • Ansatz: SW statt aus kleinen Programmzeilen aus großen Komponenten (+ Klebe-SW) zusammen bauen • Komponenten werden konfiguriert, dazu gibt es get-/setMethoden (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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 272 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 273 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 274 Idee der Framework-Technologie 9.6 • statt vollständiger SW werden Rahmen programmiert, die um Methodenimplementierungen ergänzt werden müssen • Frameworks (Rahmenwerke) können die Steuerung gleichartiger Aufgaben übernehmen • typische Nutzung: Nutzer instanziiert FrameworkKomponenten, 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 275 Framework-Technologie in Swing Framework-Technologie „im Kleinen“: • auch Java-Klassenbibliothek [kritischer Name] bietet es an, dass einfache Klassen zu Komponenten des Model-DelegateAnsatzes 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 276 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. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 277 Skizze einer Beispielimplementierung (1/5) Knoteninformation dient dazu, für den jeweiligen Knoten die darstellungsrelevanten Informationen zu liefern Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 278 Skizze einer Beispielimplementierung (2/5) ProjektTreeModel ptm= new ProjektTreeModel(); JTree baum=new JTree(ptm); JScrollPane scroller= new JScrollPane(baum); add(scroller,BorderLayout.CENTER); Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 279 Skizze einer Beispielimplementierung (3/5) public class ProjektTreeModel implements TreeModel { private Projektverwaltung projektverwaltung; private List<TreeModelListener> listener= new ArrayList<TreeModelListener>(); public ProjektTreeModel() { projektverwaltung= new Projektverwaltung(); } public Object getRoot() { return 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){ listener.add(arg0); } } // nur Ausschnitt Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 280 Skizze einer Beispielimplementierung (4/5) public class Projektverwaltung implements Knoteninformation{ private List<Projekt> projekte = new ArrayList<Projekt>(); public int anzahlElemente() { return projekte.size(); } public Knoteninformation itesElement(int i) { return projekte.get(i); } public boolean istBlatt() { return false; } public String titel() { return "Projektverwaltung"; } @Override public String toString(){ return titel(); } } // nur Ausschnitt Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 281 Skizze einer Beispielimplementierung (5/5) public class Projekt implements Knoteninformation{ private Eigenschaft[] eigenschaften= new Eigenschaft[8]; private BaumListe<Projekt> teilprojekte= new BaumListe<Projekt>("Teilprojekte"); private BaumListe<Projekt> vorgaenger= new BaumListe<Projekt>("Vorgaenger"); private BaumListe<Aufgabe> aufgaben= new BaumListe<Aufgabe>("Aufgaben"); public int anzahlElemente() { return 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; } } Grundkurs // nur Ausschnitt Software-Engineering mit UML, 2. Auflage Stephan Kleuker 282 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 DotNet-Technologie, Spring, Hibernate, viel im Bereich AJAX Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 283 Persistente Datenhaltung 9.7 Typische Java-Möglichkeiten • Anschluss an klassische relationale DB über JDBC (typisch bei Anbindung an existierende DB) • Nahtlose Integration der Datenhaltung in die Entwicklung (Ansatz: statt Objekt zu erzeugen Methode holeObjekt(), später sichere Objekt), typisch für Hibernate (häufig genutzt, bei kleinen Spezialanwendungen, z. B. Handy, Organizer) • relativ nahtlose Integration durch zusätzliche Software, die objekt-relationales Mapping übernimmt • Nutzung eines Frameworks, das Persistenz und Transaktionssteuerung übernimmt, Enterprise Java Beans Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 284 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 setVariablen – 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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 285 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 } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 286 In Erprobung/Entwicklung: : Domain Specific Languages 9.8 • 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 XMLSchema) 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 DSLAnsatz angesehen werden Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 287 DSL Prozesse Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 288 In Erprobung/Entwicklung: Model Driven Architecture 9.9 • 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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 289 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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 290 Formaler Hintergrund der MDA Semantik definiert durch Abarbeitungsreihenfolge konkretes Modell1 konkrete Menge von Regeln mit konkreten Parametern Instanz von Instanz von Modellart1 Transformationsregeln konkretes Modell2 Instanz von Modellart2 Transformationsmodel Meta Object Faciliy (MOF) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 291 Refactoring 9.10 • 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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 292 Refactoring – Positives Beispiel public int ref(int x, int y, int z){ int a=0; public int ref(int x, int y, int z){ if(x>0){ int a=0; a=x; if(x>0){ x++; a = mach(x, y, z); --y; } a=a+y+z; return a; } } return a; private int mach(int x, int y, int z){ } int a; a=x; x++; --y; a=a+y+z; return a; } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 293 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; } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 294 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; } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 295 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 http://usability.is.uni-sb.de/index.php (Arbeitsbereich Usability Engineering ) http://usability.gov/guidelines/index.html (U.S. Department of Health and Human Services) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 296 Begriff: Ergonomie 10.1 • Der Begriff "Ergonomie" setzt sich aus den griechischen Wörtern ergon = Arbeit, Werk und nomos = Gesetz, Regel zusammen. Nach Auffassung der International Ergonomics Association wird unter Ergonomie die Lehre von der menschlichen Arbeit und die Erkenntnis ihrer Gesetzmäßigkeiten verstanden. • Laut der offiziellen Definition der internationalen ISO-Norm verwendet Ergonomie wissenschaftliche Erkenntnisse, um Arbeitsaufgaben, Arbeitsumgebungen und Produkte an die physischen und mentalen Fähigkeiten und Grenzen von Menschen anzupassen. Hierbei soll Gesundheit, Sicherheit, Wohlbefinden und Leistungsvermögen verbessert werden. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 297 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 SoftwareEntwicklung beschäftigen. Für diese Personen muss der Zugang zur IT aus ihrer Sicht intuitiv sein. • Software-Ergonomie: In der Software-Ergonomie als InformatikDisziplin 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. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 298 Psychologie: Beispiel Farbwahl Farbe Assoziation weiß Reinheit, Unschuld (Asien: Trauer) schwarz Tod, Trauer, Eleganz, Schwere, Ernst grau Neutral, spannungslos blau Geist, Kosmos, Ewigkeit, wirkt kühl, steigert in Kombination die Wirkung warmer Farbtöne rot Dynamik, Aktivität, Wärme, Warnfarbe gelb Anregend, heiter, dynamisch, kalte Farben wirken durch Zusatz von gelb kälter, warme Farben wärmer orange Hohes Maß an Aktivität und Dynamik, erregt Aufmerksamkeit, Warnfarbe violett Ernst, feierlich, je nach Blauanteil kühl oder warm grün Natur, Wachstum, beruhigend (langweilig) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 299 Zusammenhang der Normen ISO 9241 10.2 ISO 9241 Teil 17 Formulardialoge Teil 16 Direkte Manipulation Teil 15 Kommandodialoge Teil 14 Menüdialoge Teil 110 Dialogprinzipien Teil 13 Benutzerführung Teil 12 Informationsdarstellung Teil 11 Anforderungen an die Gebrauchstauglichkeit Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 300 Leitlinien aus ISO 9241-110 Software-ergonomische Grundsätze der Dialoggestaltung • • • • • • • Lernförderlichkeit Fehlertoleranz Erwartungskonformität Aufgabenangemessenheit Selbstbeschreibungsfähigkeit Steuerbarkeit Individualisierbarkeit Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 301 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 302 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!“) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 303 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 304 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 305 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? Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 306 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? Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 307 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? Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 308 Anforderungsanalyse aus Usability-Sicht 10.3 • SOLL-Prozesse müssen mit dem Kunden und den Endanwendern geklärt werden • Vokabular der Kundenprozesse muss definiert sein • potenzielle alternative Prozessabläufe müssen bekannt sein • Technische Randbedingungen müssen definiert sein Usability (insbesondere Web-Seiten): • Welche gewünschten Nutzer haben welche Erfahrungen (Computererfahrung /Alter)? • Welche Technologie wird zur Implementierung eingesetzt (Browser, Javascript, ASP, ActiveX, Applets)? [je mehr heterogene Nutzer desto weniger Technik erlaubt] • Wie werden erwünschte Nutzer verbunden? [Privat-Nutzer häufiger noch über analoge Modems] Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 309 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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 310 Überblick über Usability-Testmethoden 10.4 • Expertenzentrierte Methoden – heuristische Evaluation – Guidelines und Checklisten • Nutzerzentrierte Methoden – Befragung – Task-based Testing / Discount Usability Testing – Thinking-Aloud-Tests • Kombinationen der genannten Verfahren Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 311 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 312 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 313 Nutzerbefragung • = mündlich, schriftlich (in Seite integriert, e-mail, 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 314 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 315 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. UsabilityLabor 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. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 316 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 317 Notwendige Anzahl von Testnutzern Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 318 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 11.10 Manuelle Prüfverfahren Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 319 Korrektheit 11.1 • Korrekt bedeutet: Unter folgenden Vorbedingungen sollen die Ergebnisse des Programms folgende Nachbedingungen erfüllen • Wunsch alles zu testen meist nicht erfüllbar public static boolean impliziert(boolean a, boolean b){ return !a || b; } public static void main(String[] args) { // Tests boolean werte[]={true,false}; for(boolean a:werte) for(boolean b:werte) System.out.println("a="+a+" b="+b +" liefert "+impliziert(a,b)); } • Tests sollen möglichst viele möglichst kritische Fehler finden können Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 320 Ansatz: Model Checking • Idee: Gegeben ist ein Modell (oder Spezifikation) und eine Anforderung, dann überprüft der ModelChecking-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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 321 Assertions in JDK ab Version 1.4 11.2 • Sprachänderung – neues Keyword assert • Erweiterung des java.lang-Pakets java.lang.AssertionError • Neue Dokumentation – unter Guide to Features – unter Assertion Facility – unter javadoc doc/guide/lang/assert.html • Compiler-Option –source 1.4 javac –source 1.4 Klasse.java damit javac assert akzeptiert • Interpreter-Option –ea java –ea Klasse Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 322 Syntax und Semantik von assert assert überprüft zur Laufzeit eine Zusicherung, ist diese nicht erfüllt, wird ein AssertionError ausgelöst public void (int a, int b){ assert a>b && exemplar>5; ... } Syntax: assert <Boolescher_Ausdruck> assert <Boolescher_Ausdruck>:<bel_Objekt> <bel_Objekt> ist meist ein String, der bei der Fehlermeldung mit angezeigt wird Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 323 Kostenregel • Zusicherungen sollen nichts kosten, wenn sie ausgeschaltet sind [nicht immer zu 100% möglich]. • Falsch: private static double EPS=0.000001; 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; Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 324 Vorbedingungsregel • nur interne Vorbedingungen mit assert prüfen, die bei korrekter Software erfüllt sein müssten • kein Ersatz für Ausnahmen Beispiel: public double sqrt(double param) { if ( param < 0 ) throw new IllegalArgumentException("Negativer Parameter"); return Math.sqrt( param ); } • Nicht als zweite Zeile: assert param >= 0; • deswegen AssertionError und nicht AssertionException • Assertions dürfen nur in der Entwicklung zu Fehlern führen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 325 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=0.000001; public static double sqrt(double par) { double res = Math.sqrt( par ); assert Math.abs( par - res * res ) < EPS; return res; } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 326 Invariantenregel • Invarianten von Objekten werden nach außen nie verletzt (bei internen Berechnungen erlaubt) • Ansatz: Invariante wird als eigenständige Methode implementiert private boolean invariant(...){ boolean erg = <Invariantenberechnung>; return erg; } • Überprüfung der Invariante assert invariant(...); am – Ende eines jeden Konstruktors – am Anfang jeder public-Methode – am Ende jeder public-Methode Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 327 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 328 Testfall 11.3 Vor dem Testen müssen Testfälle spezifiziert werden • Vorbedingungen – Zu testende Software in klar definierte Ausgangslage bringen (z. B. Objekte mit zu testenden Methoden erzeugen) – Angeschlossene Systeme in definierten Zustand bringen – Weitere Rahmenbedingungen sichern (z. B. HW) • Ausführung – Was muss wann gemacht werden (einfachster Fall: Methodenaufruf) • Nachbedingungen – Welche Ergebnisse sollen vorliegen (einfachster Fall: Rückgabewerte) – Zustände anderer Objekte / angeschlossener Systeme Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 329 JUnit • Framework, um den Unit-Test eines JavaProgramms zu automatisieren • einfacher Aufbau • leicht erlernbar • geht auf SUnit (Smalltalk) zurück • mittlerweile für viele Sprachen verfügbar Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 330 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 Eclipse integriert, sonst muss das Paket junit.jar zu CLASSPATH hinzugefügt werden. • wenn junit heruntergeladen wird, ist KlassenDokumentation unter \junit3.8.2\javadoc\index.html lesbar (http://sourceforge.net/projects/junit/) • weitere Dokumentation unter \junit3.8.2\doc Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 331 Grundsätzliche JUnit-Nutzung • Jede Testklasse wird von der Framework-Basisklasse junit.framework.TestCase abgeleitet. • JUnit erkennt die Testfälle anhand des Signaturmusters (Methodenname beginnt mit test) public void testXXX() • Das Framework kann mit dem Java-Reflection Package die Testfälle somit automatisch erkennen. • Die assertEquals Methode dient dazu, eine Bedingung zu testen. • Ist eine Bedingung nicht erfüllt, d.h. false, protokolliert JUnit einen Testfehler. • Der junit.swingui.TestRunner stellt eine grafische Oberfläche dar, um die Test kontrolliert ablaufen zu lassen. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 332 Das JUnit-Framework Anmerkungen zu JUnit 4: - hebt Notwendigkeit des Erbens von TestCase auf, Methode mit @Test annotieren - damit müssen Testnamen nicht mit „test“ beginnen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 333 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. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 334 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) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 335 Test-Fixture • Ein Testfall sieht in der Regel so aus, dass eine bestimmte Konfiguration von Objekten aufgebaut wird, gegen die der Test läuft. • Diese Menge von Testobjekten wird auch als TestFixture bezeichnet. • Damit fehlerhafte Testfälle nicht andere Testfälle beeinflussen können, wird die Test-Fixture für jeden Testfall neu initialisiert. • In der Methode setUp werden Exemplarvariablen initialisiert. • Mit der Methode tearDown werden wertvolle Testressourcen wie zum Beispiel Datenbank- oder Netzwerkverbindungen wieder freigegeben. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 336 Testen von Exceptions • Exceptions werden in Java mit dem catch Block behandelt. • Mit der Methode fail aus der Assert Klasse wird ein Testfehler ausgelöst und protokolliert. • Im Beispiel wird beim Aufruf des Konstruktors der Klasse MyClass mit einer negativen Zahl die IllegalArgumentException ausgelöst. public void testNegativeInitialisierung() { try { new MyClass(-10); fail("Meine Meldung im Fehlerfall"); }catch (IllegalArgumentException e) {} } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 337 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 gesperrt; } public void setGesperrt(boolean gesperrt) { this.gesperrt = gesperrt; } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 338 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(gesperrt) throw new RabattException(); return ursprungspreis*(1-(rabatt/100)); } } package kapitel11_Rabatt; public class RabattException extends Exception {} Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 339 Testfälle (1/3) package kapitel11_Rabatt; import junit.framework.TestCase; public class RabattTest extends TestCase { private Rabatt gut; private Rabatt boese; protected void setUp() throws Exception { super.setUp(); gut= new Rabatt(3.0,false); boese= new Rabatt(0.0,true); } public void testGetRabatt(){ // besser trennen assertTrue(3.0==gut.getRabatt()); assertTrue(0.0==boese.getRabatt()); } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 340 Testfälle (2/3) 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()); } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 341 Testfälle (3/3) 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); } } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 342 TestSuite • Um eine Reihe von Tests zusammen ausführen zu können, werden die Tests zu TestSuites zusammengefasst. • Eine Zusammenfassung von Tests wird dabei durch ein TestSuite Objekt definiert. • Mit JUnit können beliebig viele Tests in einer TestSuite zusammengefasst werden. • Um eine Testsuite zu definieren, ist ein TestSuite Objekt zu bilden und mittels der addTestSuite Methode verschiedene Testfallklassen hinzuzufügen. • Jede Testfallklasse definiert implizit eine eigene suite Methode, in der alle Testfallmethoden der betreffenden Klasse eingebunden werden. [Reflection Package] • In vielen Fällen ist es praktisch, pro Package eine TestSuiteKlasse zu definieren. • Es hat sich eingebürgert diese Klasse AllTest zu nennen. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 343 Beispiel: Aufbau einer Testsuite import junit.framework.Test; import junit.framework.TestSuite; public class AllTests { public static Test suite(){ TestSuite suite= new TestSuite("Kundensystem"); //hinzufügen von Testklassen suite.addTestSuite(RabattTest.class); suite.addTestSuite(KundeTest.class); //hinzufügen anderer TestSuiten suite.addTest(VerwaltungAllTests.suite()); return suite; } public static void main(String[] args) { junit.swingui.TestRunner.run(AllTests.class); } } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 344 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 345 Klassen testbar machen 11.4 • Bei Objekten mit internen Zuständen ist der Test von außen mit JUnit sehr schwierig • es ist oftmals hilfreich, zusätzliche Methoden zu implementieren, die das Testen einfacher machen public String getInternenZustand(){ return "..." } • Häufiger reicht ein get für den internen Zustand nicht aus, es muss Methoden geben, mit denen man ein Objekt von außen in einen gewünschten Zustand versetzen kann (Ergänzung weiterer Testmethoden) • Im Quellcode sollen Testmethoden eindeutig von anderen Methoden getrennt sein, damit sie ggfls. automatisch gelöscht werden können • Bei komplexeren Klassen sollte man Teile der Entwicklung bereits testen, hierzu müssen die aufgerufenen Methoden zumindest in minimaler Form implementiert werden Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 346 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 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 347 Mocks programmieren • Es wird zunächst eine Klasse mit den notwendigen Methoden implementiert, die alle die leere Implementierung oder die Rückgabe eines Dummy-Werts enthalten public void setParameter(int parameter){} public int getParameter() { return 0;} • Diese Implementierung wird soweit ergänzt, dass wir unsere Klasse testen können (möglichst einfache Fallunterscheidungen, man bedenke, dass man von der Korrektheit der anderen Klasse ausgeht) • Es gibt Werkzeuge, die die einfachst möglichen Mocks automatisch generieren, die können dann ergänzt werden • D. h., neben den Tests entsteht ein zusätzlicher Codieraufwand für Mocks, in größeren (erfolgreichen) Projekten kann der Anteil des Testcodes am Gesamtcode in Abhängigkeit von der Komplexität des Systems zwischen 30% und 70% liegen! Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 348 Beispiel für Mock-Erstellung (1/4) public class Buchung { public static LogDatei logging; ... public synchronized void abbuchen(int id, Konto konto, int betrag) throws BuchungsException{ if(konto.istLiquide(betrag)){ konto.abbuchen(betrag); logging.schreiben(id+ " bearbeitet"); } else{ logging.schreiben(id +" abgebrochen, insolvent"); throw new BuchungsException("insolvent"); } } ... } • Zum Test der Methode abbuchen werden Test-Mocks der Klassen Konto und LogDatei benötigt, Ziel ist es möglichst einfache Mocks zu schreiben Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 349 Beispiel für Mock-Erstellung (2/4) • Mock für LogDatei (wahrscheinlich) einfach public class LogDatei { // Mock für Buchung public void schreiben(String s){} } • Für Konto verschiedene Varianten denkbar, wichtig für unsere Tests, dass istLiquide() true und false zurück geben kann public class Konto { //Mock für Buchung public boolean istLiquide(int betrag){ if( betrag<1000) return true; return false; } public void abbuchen(int betrag){} } • In dieser Variante muss sich der Tester den Schwellenwert zur Prüfung merken (Mocks müssen auch getestet werden) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 350 Beispiel für Mock-Erstellung (3/4) import junit.framework.TestCase; public class BuchungTest extends TestCase {//nutzen private Konto konto; private Buchung buchung; protected void setUp() throws Exception { Buchung.logging= new LogDatei(); buchung= new Buchung(); konto= new Konto(); } protected void tearDown() throws Exception { // logging schließen} public void testErfolreicheBuchung(){ try { buchung.abbuchen(42,konto,100); } catch (BuchungsException e) { fail(); } } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 351 Beispiel für Mock-Erstellung (4/4) public void testErfolgloseBuchung(){ try { buchung.abbuchen(42,konto,2000); fail(); } catch (BuchungsException e) { } }... • Die Tests des Mocks gehören in eine eigene Testklasse, da sie später bei einer Testwiederholung für eine vollständige Implementierung nicht wiederholt werden • Werden kompliziertere Mock-Eigenschaften verlangt, sollte die Klasse generell spezielle Konstruktoren oder Methoden zum Setzen des internen Zustands beinhalten • In Coding-Guidelines ist auf das Ziel der Testbarkeit hinzuweisen, Programmierer müssen die internen Zustände ihrer Klassen zu Testzwecken sichtbar machen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 352 Vererbung - Test von Unterklassen • Tests einer Unterklasse C’ (einer Oberklasse C) sind durchzuführen • für alle neuen Methoden: neue Testfälle aufstellen und ausführen • für alle redefinierten Methoden: neue Testfälle aufstellen und ausführen; semantisch ähnliche Programm(teil)e müssen unterschiedlichen Tests unterzogen werden • für alle geerbten Methoden: müssen alle Testfälle der Klasse C erneut durchgeführt werden; Kontext der Unterklasse ist anders, erneuter Test daher notwendig nach : E. Perry, G. E. Kaiser, Adequate Testing and ObjectOriented Programming. Journal of Object-Oriented Programming, Vol. 2, No. 5, Seiten 13-19 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 353 Klassen von Testfällen 11.5 In der Literatur gibt es recht unterschiedlich detaillierte Klassifizierungen von Testfällen, eine erste grobe Einteilungsmöglichkeit ist : • Datenbezogene Testfälle: Ausgehend von der Spezifikation des zu untersuchenden Objekts werden verschiedene Eingaben überlegt, deren gewünschtes Resultat aus der Spezifikation abzuleiten ist • Ablaufbezogene Testfälle: Es wird die Struktur des zu untersuchenden Programms analysiert und versucht, möglichst alle Ablaufalternativen (if, while) durchzuspielen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 354 Äquivalenzklassenbildung • Äquivalenzklassenbildung zerlegt Menge in disjunkte Teilmengen • jeder Repräsentant einer Teilmenge hat das gleiche Verhalten bzgl. einer vorgegebenen Operation • Beispiel: Restklassen (modulo x), werden zwei beliebige Repräsentanten aus Restklassen addiert, liegt das Ergebnis immer in der selben Restklasse • Übertragungsidee auf Tests: Eingaben werden in Klassen unterteilt, die durch die Ausführung des zu testenden Systems zu „gleichartigen“ Ergebnissen führen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 355 Beispiele für Äquivalenzklassen von Eingaben • erlaubte Eingabe: 1 <= Wert <= 99 (Wert sei ganzzahlig) – eine gültige Äquivalenzklasse: 1 <= Wert <= 99 – zwei ungültige Äquivalenzklassen: Wert < 1, Wert > 99 • erlaubte Eingabe in einer Textliste: für ein Auto können zwischen einem und sechs Besitzer eingetragen werden – eine gültige Äquivalenzklasse: ein bis sechs Besitzer – zwei ungültige Äquivalenzklassen: kein Besitzer, mehr als sechs Besitzer • erlaubte Eingabe: Instrumente Klavier, Geige, Orgel, Pauke – vier gültige Äquivalenzklassen: Klavier, Geige, Orgel, Pauke – eine ungültige Äquivalenzklasse: alles andere, z.B. Zimbeln Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 356 Regeln zur Bildung von Äquivalenzklassen • man muss mögliche Eingaben kennen (aus Spezifikation) • für einfache Zahlenparameter meist einfach: – Intervall mit gültigen Werten – eventuell Intervall mit zu kleinen und Intervall mit zu großen Werten (wenn z. B. alle int erlaubt, gibt es nur eine Äquivalenzklasse, etwas schwieriger bei double)) • explizit eine Menge von Werten vorgegeben: – jeder Wert eine Äquivalenzklasse dar – andere Eingaben möglich: dies zusätzliche Äquivalenzklasse • falls nach Analyse der Spezifikation Grund zur Annahme besteht, dass Elemente einer Äquivalenzklasse unterschiedlich behandelt werden, ist die Klasse aufzuspalten Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 357 Beispiel (1/5) Spezifikation: • Als Beispiel dient eine Methode, genauer ein Konstruktor, zur Verwaltung von Studierendendaten, der ein Name, ein Geburtsjahr und ein Fachbereich übergeben werden. Dabei darf das Namensfeld nicht leer sein, das Geburtsjahr muss zwischen 1900 und 2000 liegen und es können nur die Fachbereiche FBING, FBBWL und FBPOL aus einer Aufzählung übergeben werden. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 358 Beispiel (2/5) Äquivalenzklassen: Eingabe gültige Äquivalenzklassen ungültige Äquivalenzklassen Name Ä1) nicht leer Ä2) leer Geburtsjahr Ä4) 1900< = Ä3) Geburtsjahr < 1900 Geburtsjahr <= 2000 Ä5) Geburtsjahr > 2000 Fachbereich Ä6) FBING Ä7) FBBWL Ä8) FBPOL Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 359 Testfallerzeugung aus Äquivalenzklassen • Die Äquivalenzklassen sind eindeutig zu nummerieren. Für die Erzeugung von Testfällen aus den Äquivalenzklassen sind zwei Regeln zu beachten: • gültige Äquivalenzklassen: – möglichst viele Klassen in einem Test kombinieren • ungültige Äquivalenzklassen: – Auswahl eines Testdatums aus einer ungültigen Äquivalenzklasse – Kombination mit Werten, die ausschließlich aus gültigen Äquivalenzklassen entnommen sind. – Grund: für alle ungültigen Eingabewerte muss eine Fehlerbehandlung existieren Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 360 Beispiel (3/5) Testfälle nach einer Äquivalenzklassenanalyse: (jeder Klasse wird [mindestens] einmal getestet, die Testanzahl soll möglichst gering sein) Testnummer 1 geprüfte Ä1 Äquivalenz- Ä4 klassen Ä6 Name 2 3 4 5 6 (Ä1) (Ä4) Ä7 (Ä1) (Ä4) Ä8 Ä2 Ä3 Ä5 „Meier“ „Meier“ „Meier“ „Schmidt“ „Schulz“ „“ Geburtsjahr 1987 1985 1988 1892 2006 Fachbereich FBING FBBWL FBPOL FBING FBING FBING Ergebnis ok Abbruch Abbruch Abbruch ok 1989 ok Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 361 Grenzwertanalyse • Viele Software-Fehler sind auf Schwierigkeiten in Grenzbereichen der Äquivalenzklassen zurück zu führen (z.B. Extremwert nicht berücksichtigt, Array um ein Feld zu klein) • Aus diesem Grund wird die Untersuchung von Äquivalenzklassen um die Untersuchung der Grenzen ergänzt • Beispiel: 1<=Wert<=99 (wobei Wert ganzzahlig ist) – Äquivalenzklasse Int-Wert<1: obere Grenze Wert=0 (untere Grenze spielt hier keine Rolle) – Äquivalenzklasse Int-Wert>99: untere Grenze Wert=100 (obere Grenze spielt keine Rolle) – Äquivalenzklasse 1<=Int-Wert<=99 : untere Grenze Wert=1 und obere Grenze Wert=99 • Diese Grenzfallbetrachtung kann direkt in die Testfallerzeugung eingehen (es gibt Ansätze, bei denen zusätzlich ein Fall mit einem Wert aus der „Mitte“ der Äquivalenzklasse genommen wird) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 362 Beispiel (4/5) • Testfälle nach einer Äquivalenzklassenanalyse und Grenzwertanalyse • Anmerkung: Testfallanzahl erhöht sich meist Testnummer 1 geprüfte Ä1 Äquivalenz- Ä4U klassen Ä6 Name 2 3 4 5 6 (Ä1) Ä4O Ä7 (Ä1) (Ä4) Ä8 Ä2 Ä3O Ä5U „Meier“ „Schmidt“ „Schulz“ „“ Geburtsjahr 1900 1985 1988 1899 2001 Fachbereich FBING FBBWL FBPOL FBING FBING FBING Ergebnis ok Abbruch Abbruch Abbruch ok 2000 „Meier“ „Meier“ ok Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 363 Beispiel (5/5) • mögliche Übersetzung nach JUnit (Ausschnitt) import junit.framework.TestCase; public class ImmatrikulationTest extends TestCase { ... public void test1(){ try{ new Immatrikulation("Meier",1900,Bereich.FBING); }catch(ImmatrikulationsException e){ fail("falsche Exception"); } } public void test4(){ try{ new Immatrikulation("",1988,Bereich.FBING); fail("fehlende Exception"); }catch(ImmatrikulationsException e){ } } ... Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 364 Schwierige Äquivalenzklassenbildung (1/4) • Schreibe eine Methode max(), der drei Integer-Werte übergeben werden, die den größten Wert dieser Werte zurück gibt public class Maxi { public static int max(int x, int y, int z){ int max=0; if(x>z)max=x; if(y>x)max=y; if(z>y)max=z; return max; } } • nullter Klassenansatz: jeder Parameter darf beliebige Werte annehmen, jeweils eine Klasse für x, y, z • erster Klassen-Ansatz: es gibt keine Ausnahmefälle, also drei Ergebnisse : Maximum steht an erster, zweiter oder dritter Stelle Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 365 Schwierige Äquivalenzklassenbildung (2/4) import junit.framework.TestCase; Alle Tests laufen erfolgreich, public class MaxiTest extends TestCase { allerdings war die public MaxiTest(String arg0) { Klassenbildung zu ungenau, super(arg0); } nächster Versuch mit den public void testErstesMax(){ Klassen: assertTrue("Maximum an erster Stelle", x>=y>=z 7==Maxi.max(7,5,4)); x>=z>=y } z>=x>=y public void testZweitesMax(){ assertTrue("Maximum an zweiter Stelle", z>=y>=x 7==Maxi.max(5,7,4)); y>=x>=z y>=z>=x } public void testDrittesMax(){ [Frage: sind dies assertTrue("Maximum an dritter Stelle", Äquivalenzklassen ??] 7==Maxi.max(4,5,7)); } public static void main(String[] args) { junit.swingui.TestRunner.run(MaxiTest.class); } } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 366 Schwierige Äquivalenzklassenbildung (3/4) • sechs Testfälle, Ausschnitt: public void testXYZ(){ assertTrue("X>=Y>=Z", 7==Maxi.max(7,5,4));} public void testXZY(){ assertTrue("X>=Z>=Y", 7==Maxi.max(7,4,5));} public void testYXZ(){ assertTrue("Y>=X>=Z", 7==Maxi.max(5,7,4));} • Der Fall X>=Z>=Y offenbart, dass das Verfahren nicht funktioniert • Allerdings ist die Äquivalenzklassenwahl nicht sauber Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 367 Schwierige Äquivalenzklassenbildung (4/4) • Saubere Äquivalenzklassen sind: – x>y=z y=z>x – y>x=z x=z>y – z>y=x y=x>z – z>y>x z>x>y – y>z>x y>x>z – x>z>y x>y>z – x=y=z • Bei Grenzwertanalyse muss der Übergang zwischen den untersuchten Klassen betrachtet werden, d.h. wenn zwei oder drei Argumente gleich sind (letzter Fall liefert auch Fehler) • Aus der Spezifikation nicht ableitbar, allerdings gegebenenfalls aus der Erfahrung mit der Mathematik zu ergänzen, ist die Untersuchung des Verhaltens bei negativen Zahlen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 368 Äquivalenzklassenbildung und Objektorientierung • Äquivalenzklassenbildung ist ein zentrales Verfahren, um systematisch Tests aufzubauen • für Methoden von Objekten spielt neben Ein- und Ausgaben der interne Zustand häufig eine wichtige Rolle (erst wenn Methode x ausführt wurde, dann kann Methode y sinnvoll ausgeführt werden) • Konsequenterweise muss man sich also mit dem Ein-/Ausgabeverhalten pro möglichem Objektzustand beschäftigen (was noch extrem aufwändiger sein kann) • das bisher vorgestellte Verfahren kann in der reinen Form nur für gedächtnislose Objekte genutzt werden Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 369 Äquivalenzklassen und Objekte (1/5) Spezifikation: • In einem Bestellsystem wird für jeden Kunden im Objekt einer Klasse Zuverlaessigkeit festgehalten, wie er bezüglich seines Bezahlverhaltens eingestuft wird. Diese Einstufung wird durch die folgende Aufzählung beschrieben. public enum Bezahlstatus { STANDARD, GEPRUEFT, KRITISCH; } • Die Klasse Zuverlaessigkeit soll eine Methode anbieten, mit der geprüft werden soll, ob eine Bestellung über eine bestimmte Summe ohne eine weitere Liquiditätsprüfung erlaubt werden soll. Die Bestellung soll für geprüfte Kunden immer und für kritische Kunden nie ohne zusätzliche Prüfung möglich sein. Für sonstige Kunden muss eine Prüfung ab einer Bestellstumme von 500€ erfolgen. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 370 Äquivalenzklassen und Objekte (2/5) public class Zuverlaessigkeit { // zu testen private Bezahlstatus status; public void setStatus(Bezahlstatus status){ this.status=status; } public boolean einkaufssummePruefen(int wert){ switch(status){ case GEPRUEFT:{ return true; } case STANDARD:{ return wert<500; } } return false; } } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 371 Äquivalenzklassen und Objekte (3/5) • erste Überlegung: nur Parameter wert zu testen, [wert<500] und [wert>=500] (zwei Tests) • zweite Überlegung: Objektzustand als weiteren Parameter berücksichtigen; ergibt drei Testfälle: jeder Objektzustand mit wert=499 oder wert=500 (Grenzwertanalyse) kombiniert • dritte Überlegung: Kombination von Äquivalenzklassen betrachten [status==STANDARD && wert==499] und [status==STANDARD && wert==500] (d. h. vier Tests, noch einen für GESPRUEFT und KRITISCH) • vierte Überlegung: Alle Kombinationen betrachten (leider nur selten machbar) (d. h. sechs Tests) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 372 Äquivalenzklassen und Objekte (4/5) import junit.framework.TestCase; // vierter Ansatz public class ZuverlaessigkeitTest extends TestCase { private Zuverlaessigkeit zvl; protected void setUp() throws Exception { super.setUp(); zvl= new Zuverlaessigkeit(); } public void testGeprueft1(){ zvl.setStatus(Bezahlstatus.GEPRUEFT); assertTrue(zvl.einkaufssummePruefen(499)); } public void testGeprueft2(){ zvl.setStatus(Bezahlstatus.GEPRUEFT); assertTrue(zvl.einkaufssummePruefen(500)); } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 373 Äquivalenzklassen und Objekte (5/5) public void testKritisch1(){ zvl.setStatus(Bezahlstatus.KRITISCH); assertTrue(!zvl.einkaufssummePruefen(499)); } public void testKritisch2(){ zvl.setStatus(Bezahlstatus.KRITISCH); assertTrue(!zvl.einkaufssummePruefen(500)); } public void testStandard1(){ zvl.setStatus(Bezahlstatus.STANDARD); assertTrue(zvl.einkaufssummePruefen(499)); } public void testStandard2(){ zvl.setStatus(Bezahlstatus.STANDARD); assertTrue(!zvl.einkaufssummePruefen(500)); } } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 374 Kontrollflussgraph (KFG) 11.6 • eines Programms P ist ein gerichteter Graph KFG(P) =def G = (V,E, VStart, VZiel) • V: Menge der Knoten (Anweisungen des Programms) • E ist Teilmenge von V×V: Menge der Kanten (Nachfolgerelation bezüglich der Ausführung des Programms) • VStart , VZiel aus V : Ausgewählte Knoten für Start, Ende des Programms (VZiel kann auch eine Menge von Knoten sein) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 375 Beispiel: KFG public int aha(int ein){ int erg=-ein/2; // int i=ein; // while(i>0){ // erg=erg+(i--); // } if (ein <0 || ein%2==1){// erg=0; // } return erg*2; // } 0 1 2 3 4 5 6 0 01 1 2 2 3 3 4 4 5 5 6 6 • Wunsch: Graph sollte unabhängig von der Formatierung sein! • Programm gibt Quadrat aller positiven geraden Zahlen, sonst 0 zurück • Testergebnisse werden vereinfachend bei folgenden Testfallbeschreibungen weggelassen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 376 Normalisierung eines KFG durch Blockung folgende Regeln, mit denen mehrere Knoten k1,k2,...,kn, die nacheinander durchlaufen werden können, also k1k2...kn, zu einem Knoten verschmolzen werden. • Die Knotenfolge wird bei jedem Durchlauf immer nur über k1 betreten, es gibt außer den genannten Kanten keine weiteren Kanten, die in k2,...,kn enden. • Die Knotenfolge wird bei jedem Durchlauf immer nur über kn verlassen, es gibt außer den genannten Kanten keine weiteren Kanten, die in k1,...,kn-1 beginnen. • Die Knotenfolge ist maximal bezüglich a) und b). Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 377 Analyse vollständiger Pfade • Ein vollständiger Pfad ist eine Folge von verbundenen Knoten (über Kanten) im KFG, die mit Vstart beginnt, und mit Vziel endet. • Die möglichen Ausführungsreihenfolgen des Programms sind eine Teilmenge der vollständigen Pfade • Wunsch: Durchlauf „repräsentativer“ vollständiger Pfade beim Test • Überdeckung aller vollständigen Pfade ist im allgemeinen nicht ausführbar • Ansatz: Verschiedene Approximationsstufen (Anweisungsüberdeckungstest, ..., MehrfachBedingungsüberdeckungstest) für die Menge der vollständigen Pfade bei Auswahl der Testdurchläufe wählen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 378 Anweisungsüberdeckung (C0) • Ziel: alle Anweisungen des Programms durch Wahl geeigneter Testdaten mindestens einmal ausführen, alle Knoten des KFG mindestens einmal besuchen. Anzahl der ausgeführten Knoten • Testmaß C0= |V| • Ziel: C0=1 (=100%) • für {-1} C0= 5/6 • für {-1,0} C0= 5/6 • für {-1,2} C0= 6/6 C0= ein=-1 ein=0 ein=1 ein=2 01 01 01 01 2 2 2 2 3 3 3 3 4 4 4 4 5 5 5 5 6 6 6 6 5/6 4/6 6/6 5/6 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 379 Zweigüberdeckung (C1) • Ziel :alle Kanten des KFG überdecken, d.h. alle Zweige des Programms einmal durchlaufen • Testmaß Anzahl der durchlaufenen Kanten C1= |E| ein=-1 • Ziel: C1=1 • für {-1} C1= 4/7 • für {-1,0} C1= 5/7 • für {-1,2} C1= 7/7 C1= ein=0 ein=1 ein=2 01 01 01 01 2 2 2 2 3 3 3 3 4 4 4 4 5 5 5 5 6 6 6 6 4/7 3/7 6/7 5/7 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 380 Kommentare zu C0 und C1 • Vorteile der Anweisungsüberdeckung: – einfach – geringe Anzahl von Eingabedaten – nicht ausführbare Programmteile werden erkannt • großer Nachteil der Anweisungsüberdeckung: – Logische Aspekte werden nicht überprüft • deshalb: Zweigüberdeckungstest gilt als das Minimalkriterium im Bereich des dynamischen Softwaretests, – schließt den Anweisungsüberdeckungstest ein, – fordert die Ausführung aller Zweige eines KFG, – jede Entscheidung mindestens einmal wahr und falsch • Nachteile der Zweigüberdeckung: – Fehlende Zweige werden nicht automatisch entdeckt – Kombinationen von Zweigen sind unzureichend geprüft – Komplexe Bedingungen werden nicht analysiert – Schleifen werden nicht ausreichend analysiert Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 381 Bedingungsüberdeckungstest • Ziel: Teste gezielt Bedingungen in Schleifen und Auswahlkonstrukten • Bedingungen sind Prädikate – A1,..., A4 atomar • z.B. (x==1) [auch !(x==1)] – zusammengesetzt • Konjunktion K • Disjunktion D • ( ( (x==1) || (x==2) )&&( (y==3) || (y==4) ) ) hat 7 Teilprädikate: x==1, x==2, y==3, y==4, (x==1) || (x==2), (y==3) || (y==4) , ( ( (x==1) || (x==2) )&&( (y==3) || (y==4) ) ) • Hinweis: Bei Java und anderen Programmiersprachen ist der Unterschied zwischen || und && (mit Kurzschlussauswertung) und | und & (ohne Kurzschlussauswertung) zu beachten if(true || 5/0==0) läuft, if(true | 5/0==0) läuft nicht Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 382 Einfache Bedingungsüberdeckung (C2) • Ziel: alle atomaren Prädikate einmal TRUE, einmal FALSE |wahre Atome| + |falsche Atome| • Testmaß: C2= 2 * |alle Atome| • |alle Atome| =Anzahl aller Atome, |wahre Atome|= Anzahl aller Atome, die mit true ausgewertet werden (analog | falsche Atome|) Testfälle {-1} {0} {1} {2} {-1,0} {0,1} {1,2} {-1,1} {-1,1,2} i>0 f f f,t f,t f f,t f,t f,t f,t ein<0 t f f f t,f f f t,f t,f ein%2==1 - f t f f f,t t,f t t,f C2-Überdeckung 3/6 4/6 4/6 4/6 5/6 5/6 5/6 6/6 2/6 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 383 Kein Zusammenhang zwischen C1 und C2 • Die Nummerierung ist historisch gewachsen • betrachte if (a || b) – a=true, b=false a=false, b=true • garantiert vollständige C2-Überdeckung • else-Zweig wird nicht durchlaufen, kein C1 oder C0 – a=true, b=false a=false, b=false • if- und else-Zweig wird durchlaufen, damit C1 und C0 • keine vollständige C2-Überdeckung, da b=true fehlt Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 384 Minimale Mehrfachüberdeckung (C3) • Ziel: alle Prädikate und Teil-Prädikate einmal TRUE, einmal FALSE |wahre Teilprädikate| + |falsche Teilprädikate| C3= • Testmaß: 2 * |alle Teilprädikate| Testfälle {-1} {0} {1} {2} {-1,0} {0,1} {1,2} {-1,1} {-1,1,2} i>0 f f f,t f,t f f,t f,t f,t f,t ein<0 t f f f t,f f f t,f t,f ein%2==1 - f t f f f,t t,f t t,f t ein<0 || ein%2==1 f t f t,f f,t t,f t t,f C3-Überdeckung 4/8 5/8 5/8 6/8 7/8 7/8 6/8 8/8 3/8 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 385 Zusammenhang zwischen den Testverfahren Anmerkung: Diese Thema kann noch wesentlich vertieft werden Minimaler Mehrfach-Bedingungsüberdeckungstest (C3) Zweigüberdeckungstest (C1) Einfacher Bedingungsüberdeckungstest (C2) Anweisungsüberdeckungstest (C0) vollständige Überdeckung des einen bedeutet vollständige Überdeckung des anderen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 386 Automatisierung der Ci-Tests • Ohne eine Tool-Unterstützung ist es sehr aufwändig und fehlerträchtig, solche Überprüfungen zu machen • Für andere Sprachen als Java (und C#) sind Coverage-Werkzeuge vorhanden, die man bzgl. der zu untersuchenden Überdeckung einstellen kann • Für Java gibt es nur verschiedene Programme, die den Anweisungsüberdeckungstest und teilweise den Zweigüberdeckungstest (CoceCover, Eclemma, Coverlipse, JCoverage, Hansel für JUnit, Clover) unterstützen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 387 Info: Standard DO-178B • • • • • • Um die Zertifizierung der Federal Aviation Administration (FAA) zu erhalten, muss Software für Luftverkehrssysteme den Richtlinien des Standards DO-178B für requirement-basiertes Testen und Code Coverage Analysen genügen. DO-178B-Levels orientieren sich an den Konsequenzen möglicher Softwarefehler: katastophal (Level A), gefährlich/schwerwiegend (Level B), erheblich (Level C), geringfügig (Level D) bzw. keine Auswirkungen (Level E). Je nach DO-178B-Level wird der 100%-ige Nachweis folgender Testabdeckungen (Code Coverages) verlangt: DO-178B Level A: – Modified Condition Decision Coverage (MC/DC) – Branch/Decision Coverage – Statement Coverage DO-178B Level B: – Branch/Decision Coverage – Statement Coverage DO-178B Level C: – Statement Coverage Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 388 Teststufen (grober Ablauf) 11.7 Klassentest entwicklungsintern Integrationstest Systemtest entwicklungsextern (mit Kunden) Grundkurs Software-Engineering mit UML, 2. Auflage Abnahmetest Stephan Kleuker 389 Klassentest (Modultest) • Varianten: – Unit-Test: einzelne Methoden und/oder Klassen – Modultest: logisch-zusammengehörige Klassen, z.B. ein Package in Java • Testziel: Prüfung gegen Feinspezifikation – Architektur, Design, Programmierkonstrukte • Testmethode: White-Box-Test • Alle Module müssen getestet werden – eventuell mit unterschiedlicher Intensität Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 390 Integrationstest • Module werden zu einem System integriert und gemeinsam getestet • Testziele: – Werden Schnittstellen richtig benutzt? – Werden Klassen bzw. ihre Methoden richtig aufgerufen? • Konzentration auf (Export-) Schnittstellen – Interne Schnittstellen können nicht mehr direkt beeinflusst werden – Geringere Testtiefe als beim Modultest – Grey-Box-Test (oder auch Black-Box) • Techniken ähnlich wie bei Modultest – Pfadanalyse über die komplette Interaktion der Module oft nicht mehr sinnvoll • Mit minimaler Systemkonfiguration beginnen, Integrationsstrategie spielt eine Rolle Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 391 Systemtest • Orientierung an den spezifizierten Systemaufgaben (z.B. Use Cases) • Interaktion mit den (simulierten) Nachbarsystemen • (endgültige) Validierung der nicht-funktionalen Anforderungen, z.B. Skalierbarkeit, Verfügbarkeit, Robustheit, ... • wichtige Teilaufgabe: Testdaten-Verwaltung – Wiederherstellung des ursprünglichen Zustands der Testdaten – Autarke Datenbestände: Kein gegenseitiges “Zerschießen“ der Testdaten – für DB: Kollisionen in den Nummernkreisen der Schlüsselattribute vermeiden – Datumsfelder können altern. Wie können Testdaten zum aktuellen Datum passen? • Tagesdatum aus (manipuliertem) Kalender-Modul holen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 392 Testansätze zusammengefasst White-Box-Test Gray-Box-Test Anweisungen Black-Box-Test Paket/ Komponente Entscheidungen Pfade Eingaben Schnittstellen System Ausgaben Methoden-/Klassentest Integrationstest Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker Systemtest 393 Testfälle und die UML Entwicklung in der UML Testen Use Case Diagramme Systemtestfälle Aktivitätsdiagramme Komponentendiagramme Integrationstestfälle Sequenzdiagramme Klassentestfälle Klassendiagramme Zustandsdiagramme Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 394 Effiziente Massentests • Oftmals muss man recht ähnliche Daten zum Testen nutzen, dabei bietet es sich an, diese Testdaten in einem File zu speichern und die Daten schrittweise auszulesen • Generell können professionelle Testwerkzeuge meist Daten aus Datenbanken, kommaseparierten Listen, Excel-Files, ... lesen • TestNG als JUnit-Erweiterung erlaubt Testdatengenerierung für Unit-Tests Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 395 Prinzip des Regressionstests Software Version n Testfallspezifikation Version n Test Testarchivierung der Iteration n Referenztestfälle Testfallergebnisse Software Version n+1 Regressionstest Testfalldatenbank Vergleich der Testergebnisse Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 396 Regressionstests im Entwicklungszyklus Testfallentwicklung erste Entwicklung Version 1 Test Testfallentwicklung Weiterentwicklung Regressionstestfälle Test Testfallentwicklung Version 2 Weiterentwicklung Regressionstestfälle Test Grundkurs Software-Engineering mit UML, 2. Auflage Version n Stephan Kleuker 397 Regressionstest • Änderungen an bereits freigegebenen Modulen sind notwendig • Gibt es Auswirkungen auf die alten Testergebnisse? • Wenn ja, welche? • Wiederholbarkeit der Tests • Wiederherstellung der Testdaten • Der Testprozess muss automatisierbar sein • Testfälle müssen gruppiert werden können, damit man sie wegen der untersuchten Funktionalität (oder auch Testdauer) gezielt einsetzen kann Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 398 Wartung und Testen • Der Test ist geteilt in Änderungstest (White-Box) und Regressionstest (Black-Box) • Änderungstest vom Entwickler, er schreibt die Testfälle fort. • Regressionstest von unabhängiger Testgruppe mit den alten plus neuen Testfällen durchgeführt • Testgruppe ist für Pflege und Fortschreibung der Systemtestfälle verantwortlich Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 399 Lasttest • Geforderte Performance – Durchsatz bzw. Transaktionsrate – Antwortzeiten • Skalierbarkeit – Anzahl Endbenutzer – Datenvolumen – Geografische Verteilung • Zugriffskonflikte konkurrierender Benutzer • Entspricht dem Zeitraum nach der Inbetriebnahme • Simulation von – Anzahl Endbenutzer, – Transaktionsrate , ... – Über einen signifikanten Zeitraum (mehrere Stunden) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 400 Untersuchung des Laufzeitverhaltens • wie oft wird jede Methode aufgerufen (oder Quellcodezeile durchlaufen) • welche Methode ruft wie oft welche andere Methode (descendants) auf oder von welchen Methoden (callers) wird eine Methode wie oft gerufen • wie viel Prozent der Gesamtlaufzeit wird mit Ausführung einer bestimmten Methode verbracht (ggf. aufgeteilt nach callers und descendants) Nutzen der ermittelten Daten • Operationen, die am meisten Laufzeit in Anspruch nehmen, können leicht identifiziert (und optimiert) werden • tatsächliche Aufrufabhängigkeiten werden sofort sichtbar Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 401 Untersuchung des Speicherplatzverhaltens • welche Operationen fordern wie viel Speicherplatz an (geben ihn frei) • wo wird Freigabe von Speicherplatz vermutlich bzw. bestimmt vergessen (memory leak = Speicherloch): • bestimmt vergessen: Objekt lebt noch, kann aber nicht mehr erreicht werden (Garbage Collector von Java würde es entsorgen) • vermutlich vergessen: Objekt lebt noch und ist erreichbar, wird aber nicht mehr benutzt (Garbage Collector von Java kann es nicht freigeben) • wo wird auf bereits freigegebenen Speicherplatz zugegriffen (nur für C++) bzw. wo wird Speicherplatz mehrfach freigegeben (nur für C++) • wo wird auf nicht initialisierten Speicherplatz zugegriffen; anders als bei der statischen Programmanalyse wird für jede Feldkomponente (Speicherzelle) getrennt Buch darüber geführt • wo finden Zugriffe jenseits der Grenzen von Arrays statt (Laufzeitfehler in meisten Programmiersprachen) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 402 Lasttest und Speicherverhalten in Java • Hinweis: Java unterstützt das „Profiling“, hierzu stehen explizite Compiler- und Ausführungsoptionen zur Verfügung • kommerzielle Produkte, z. B. „IBM/Rational Purify und Quantifiy • freie Wekzeuge: – Test and Performance Tools Platform (TPTP) für Eclipse – JMeter: http://jakarta.apache.org/jmeter/ (besonders interessant für Lasttests von Web-Servern und Datenbankzugriffen) – jMechanic: http://jmechanic.sourceforge.net/ (einfaches Eclipse-Plugin, am wenigsten weit entwickelt) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 403 Test von Oberflächen • Grundsätzlich sind Oberflächen gewöhnliche SW-Module und können wie diese getestet werden. • Für xUnit-Werkzeuge ist der Zugriff auf Oberflächen teilweise schwierig (xUnit muss auf Oberflächenkomponenten zugreifen und diese bedienen können, JButton in Java hat z.B. Methode doClick()) • Für Oberflächen gibt es deshalb Capture & Replay-Werkzeuge • Grundidee: Das Werkzeug zeichnet alle Mausbewegungen und Tastatureingaben auf, die können dann zur Testwiederholung erneut abgespielt werden • Typisch ist, dass der Nutzer die aufgezeichneten Skripte modifizieren kann (z. B. Test von berechneten Daten) • Tools können teilweise auch Oberfläche lesen (Frage ob Texte richtig ausgegeben), Snapshots vergleichen • professionelle Beispiele: Winrunner von HP (früher Mercury), VisualTest von IBM-Rational • zum Ausprobieren: Abbot (http://abbot.sourceforge.net/) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 404 Nutzung von Maßsystemen • Die bisherigen Überprüfungsverfahren sind recht aufwändig, es besteht der Wunsch, schneller zu Qualitätsaussagen zu kommen • Der Ansatz ist die Einführung eines Maßsystems, aus dem System werden Zahlenwerte generiert, deren Werte ein Indiz für die Qualität eines Produktes geben • Werden diese Maße automatisch berechnet, kann man Qualitätsforderungen stellen, dass bestimmte Maßzahlen in bestimmten Bereichen liegen • Wichtig ist, dass man weiß, dass nur Indikatoren betrachtet werden, d.h. gewonnene Aussagen müssen nachgeprüft werden • Ähnliche Ansätze in der Projektverfolgung und Analyse der Firmengesamtlage (-> Balanced Scorecard) -> siehe Qualitätsmanagement Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 405 Metriken zur Ermittlung des Projektstands 11.8 programmiert/ überdeckt 100% 50% 0% Use Cases Pakete Grundkurs Software-Engineering mit UML, 2. Auflage C1-Überdeckung Stephan Kleuker C2-Überdeckung 406 Grobe Metriken (Min, Max, Schnitt, Abweichung) • Lines of Code pro Methode (LOC) Nach der Grundregel des guten Designs sollte die maximale Zahl unter 20 liegen • Methoden pro Klasse Die Zahl sollte zwischen 3 und 15 liegen • Parameter pro Methode Die Zahl sollte unter 6 liegen • Exemplarvariablen pro Klasse Die Zahl sollte unter 10 liegen [Entitäten ?] • Abhängigkeiten zwischen Klassen Keine Klasse sollte von mehr als vier Klassen abhängen • andere Maßzahlen, wie die Anzahl von Klassenvariablen und Klassenmethoden können auch als Indikatoren eingesetzt werden Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 407 Zyklomatische Zahl nach McCabe 1. Man konstruiere die Kontrollflussgraphen 2. Man messe die strukturellen Komplexität Die zyklomatische Zahl z(G) eines Kontrollflussgraphen G ist: z(G) = e – n + 2 mit • e = Anzahl der Kanten des Kontrollflussgraphen • n = Anzahl der Knoten Zyklomatische Komplexität gibt Obergrenze für die Testfallanzahl für den Zweigüberdeckungstest an In der Literatur wird 10 oft als maximal vertretbarer Wert genommen (für OO-Programme geringer, z. B. 5) für Java: #if + #do + #while + #switch-cases+ 1 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 408 Beispiele für die zyklomatische Zahl Anzahl Kanten Anzahl Knoten McCabe Zahl 0 2 4 3 6 1 3 4 3 5 1 1 2 2 3 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 409 Erweiterte McCabe-Zahl • Komplexität von Verzweigungen berücksichtigen • gezählt werden alle Booleschen Bedingungen in if(<Bedingung>) und while(<Bedingung>): anzahlBedingung • gezählt werden alle Vorkommen von atomaren Prädikaten: anzahlAtome z. B.: ( a || x>3) && y<4 dann anzahlAtome=3 • erweitere McCabe-Zahl ez(G) = z(G) + anZahlAtome - anzahlBedingung • wenn nur atomare Bedingungen, z. B. if( x>4), dann gilt ez(G) = z(G) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 410 Lack of Cohesion in Methods (LCOM*) • nutzt(a) die Zahl der Methoden, die eine Exemplarvariable a der untersuchten Klasse nutzen • sei avgNutzt der Durchschnitt aller Werte für alle Exemplarvariablen • sei m die Anzahl aller Methoden der untersuchten Klasse • LCOM* = (avgNutzt–m) /(1-m) • Ist der Wert nahe Null, handelt es sich um eine eng zusammenhängende Klasse • Ist der Wert nahe 1, ist die Klasse schwach zusammenhängend, man sollte über eine Aufspaltung nachdenken • Hinweis: Es muss vorher festgelegt werden, ob Klassenvariablen und Klassenmethoden berücksichtigt werden sollen • Was passiert, wenn man konsequent exzessiv OO macht und auch in den Exemplarmethoden get() und set() Methoden nutzt? Wie ist LCOM* dann rettbar? Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 411 LCOM*-Beispiel public class LCOMSpielerei { private int a; private int b; private int c; public void mach1(int x){ a=a+x; } public void mach2(int x){ a=a+x; b=b-x; } nutzt(a)=3 nutzt(b)=2 nutzt(c)=1 avgNutzt=6/3=2 LCOM*= (2-3) /(1-3) = -1/-2= 0.5 public void mach3(int x){ a=a+x; für Eclipse gibt es Plugin Metrics b=b-x; http://sourceforge.net/projects/metrics/ c=c+x; berechnet u. A. erweiterte } MCCabe-Zahl und LCOM* } Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 412 Konstruktive Qualitätssicherung 11.9 • die analytische Qualitätssicherung greift erst, wenn ein Produkt erstellt wurde • interessant ist der Versuch, Qualität bereits bei der Erstellung zu beachten • typische konstruktive Qualitätsmaßnahmen sind – Vorgabe der SW-Entwicklungsumgebung mit projekteigenem Werkzeughandbuch, was wann wie zu nutzen und zu lassen ist – Stilvorgaben für Dokumente und Programme (sogenannte Coding-Guidelines) • Die Frage ist, wie diese Maßnahmen überprüft werden Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 413 Coding Guidelines • Detailliertes Beispiel: Taligent-Regeln für C++ (http://pcroot.cern.ch/TaligentDocs/TaligentOnline/Do cumentRoot/1.0/Docs/index.html) • Sun hat auch Regeln für Java herausgegeben (nicht ganz so stark akzeptiert) • z. B. Eclipse-Erweiterung Checkstyle • Generell gibt es Regeln – zur Kommentierung, – zu Namen von Variablen und Objekten (z.B. PräfixRegeln), – zum Aufbau eines Programms (am schwierigsten zu formulieren, da die Programmarchitektur betroffen ist und es nicht für alle Aspekte „die OO-Regeln“ gibt) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 414 Beispiel-Coding-Regel • • Ausschnitt aus „Java Code Conventions“, Sun, 1997 Inhalt soll sich nicht nur auf Formatierung beziehen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 415 Anti-Pattern • Pattern dienen zur sinnvollen Strukturierung komplexer, aber gleichartiger Systeme • Anti-Pattern sind wiederkehrende schlechte Lösungen, die man an Strukturen erkennen kann, z. B. – Spaghetti-Code, viele if, while und repeat-Schleifen gemischt, intensive Nutzung der Möglichkeiten mit break, früher: goto – Cut-and-Paste-Programmierung: „was oben funktionierte, funktioniert hier auch“ – allmächtige Klassen, kennen jedes Objekt, sitzen als Spinne im Klassendiagramm, immer „gute“ Quelle für Erweiterungen – Rucksack-Programmierung: bei vergessenem Sonderfall in allen betroffenen Methoden if (Sonderfall){ Reaktion } else { altes Programm} • Literatur (z. B.): W. J. Brown, R. C. Malveau, H. W. McCormick III, T. J. Mowbray, AntiPatterns, Wiley, 1998 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 416 Manuelle Prüfmethoden 11.10 • Produkte und Teilprodukte werden manuell analysiert, geprüft und begutachtet. • Ziel ist es, Fehler, Defekte, Inkonsistenzen und Unvollständigkeiten zu finden. • Die Überprüfung erfolgt in einer Gruppensitzung durch ein kleines Team mit definierten Rollen. • Anmerkung: Es werden hier Inspektionen, Reviews und Walkthroughs betrachtet (in abnehmender Formalität), in der Literatur ist „Reviews“ teilweise der Oberbergriff Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 417 Voraussetzungen manueller Prüfmethoden • notwendigen Aufwand und benötigte Zeit einplanen • Jedes Mitglied des Prüfteams muss in der Prüfmethode geschult sein • Prüfergebnisse nicht zur Beurteilung von Mitarbeitern nutzen • Die Prüfmethode muss schriftlich festgelegt und deren Einhaltung überprüft werden • Prüfungen haben hohe Priorität, d.h. sie sind nach der Prüfbeantragung kurzfristig durchzuführen • Vorgesetzte und Zuhörer sollen an den Prüfungen nicht teilnehmen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 418 Inspektionsablauf (1/3) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 419 Inspektionsablauf (2/3) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 420 Inspektionsablauf (3/3) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 421 weitere manuelle Prüfmethoden (1/2) Review • weniger formal als Inspektion • Gutachter überprüfen ein schriftliches Dokument, um dessen Stärken und Schwächen festzustellen. • Review-Ablauf ist im wesentlichen wie der Ablauf einer Inspektion. Die Unterschiede bestehen darin, dass: – der Autor dabei ist (passiv und um Missverständnisse zu klären), – der Autor die verteilten und markierten Kopien des Prüfobjekts erhält und – das Review-Team im Falle einer Zurückweisung eine erneute Sitzung verlangen kann. • Während des Reviews werden keine Lösungen diskutiert! Damit gute Ideen nicht verloren gehen, kann eine formlose „dritte Stunde“ angehängt werden. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 422 weitere manuelle Prüfmethoden (2/2) Walkthrough • ist abgeschwächte Form des Reviews. • Der Autor leitet als Moderator die WalkthroughSitzung. Zu Beginn [evtl. früher] der Sitzung erhält jeder Gutachter eine Kopie des Prüfobjektes. • Das Prüfobjekt wird Schritt für Schritt vorgestellt und die Gutachter stellen spontane Fragen und versuchen so, mögliche Probleme zu identifizieren. Diese werden protokolliert. • Walkthrough-Variante besteht darin, vor der Sitzung eine individuelle Vorbereitung durchzuführen. Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 423 Vor- und Nachteile manueller Prüfmethoden + Oft die einzige Möglichkeit, Semantik zu überprüfen. + Notwendige Ergänzung werkzeuggestützter Überprüfungen + Die Verantwortung für die Qualität der geprüften Produkte wird vom ganzen Team getragen. + Da die Überprüfungen in einer Gruppensitzung durchgeführt werden, wird die Wissensbasis der Teilnehmer verbreitert. + Jedes Mitglied des Prüfteams lernt die Arbeitsmethoden seiner Kollegen kennen. + Die Autoren bemühen sich um eine verständliche Ausdrucksweise, da mehrere Personen das Produkt begutachten. + Unterschiedliche Produkte desselben Autors werden von Prüfung zu Prüfung besser, d.h. enthalten weniger Fehler. - In der Regel aufwändig (bis zu 20 Prozent der Erstellungskosten des zu prüfenden Produkts). - Autoren geraten u.U. in eine psychologisch schwierige Situation (»sitzen auf der Anklagebank«, »müssen sich verteidigen«). Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 424 12. Umfeld der SoftwareEntwicklung 12.1 Versionsmanagement 12.2 Build-Management 12.3 Grundlagen der Projektplanung und verfolgung 12.4 Aufwandsschätzung 12.5 Qualitätsmanagement 12.6 Der Mensch im Projekt Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 425 Typischer Weg der Software-Entwicklung 12.1 Aufgabenteil auswählen Programmstück kodieren Programmstück testen [läuft] [nicht fertig] [kleiner Fehler] Korrekturversuch [Fehler unklar] Einbau/Nutzung von Debuginformationen [kleine Überarbeitung] kleine Lösungsvariante [Umstrukturierung] große Lösungsvariante [fertig] Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 426 Software-Versionen • Software entwickelt sich inkrementell, bei Versuchen muss der Weg zurück möglich sein • Versionsbaum Paket 1 Paket 2 Paket 3 V1 V1 V1 V2 V2 V2 V3 V4 V3 V4 V5 V6 V3 Inkrement 1 V4 V5 V6 Inkrement 2 V7 V5 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 427 Verwaltung von Software • Die gemeinsame Entwicklung von Software hat u. a. folgende Aufgaben zu lösen: – wie kann ein Entwickler seine eigene Softwareentwicklung koordinieren – wie bekommen andere Entwickler mit, was der aktuelle Entwicklungsstand ist – wie wird aus den einzelnen Dateien effizient das lauffähige System kompiliert • Die ersten beiden Fragen beantwortet ein Versionskontrollsystem • die letzte Frage fordert die Erweiterung zum Softwarekonfigurationsmanagementsystem (-> Ant) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 428 Konflikt bei gemeinsamer Bearbeitung Arton Datei D auschecken Nadia Datei D Version n Datei D auschecken D bearbeiten D bearbeiten Datei D Version n+1 Datei D einchecken Datei D einchecken Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 429 Versionskontrolle: konservative Variante • • • • Dateien werden zentral im Repository verwaltet Entwickler checkt zu ändernde Software aus Entwickler erhält damit lokale Kopie zur Bearbeitung Während der Entwickler an der Software arbeitet, kann niemand anderes diese Software bearbeiten (erhält die Situation klärenden Hinweis) • Entwickler checkt lokale Kopie (mit Änderungsverweis) wieder ein; jeder kann diese Kopie zur erneuten Bearbeitung auschecken • Vorteil: garantiert nur ein Bearbeiter • Nachteile: keine gleichzeitige Arbeit an unterschiedlichen Programmstellen, wartende Entwickler, vergessenes Einchecken • Realisierung von Repository sehr unterschiedlich lösbar (Datenbanksystem, Aufsatz auf Filesystem) • Hinweis: Generell sollte das Einchecken mit einer Prüfung verbunden sein Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 430 Versionskontrolle: progressive/chaotische Variante • • • • Dateien werden zentral im Repository verwaltet Entwickler checkt zu ändernde Software aus Entwickler erhält damit lokale Kopie zur Bearbeitung andere Entwickler können gleichen Programmcode auschecken • erst beim Einchecken wird geprüft, ob seit dem Auschecken zwischenzeitliche neue Version eingecheckt wurde, wenn ja, passiert Versionsabgleich, Konflikt muss gelöst werden • Vorteil: massive parallele Arbeit wird möglich, kein Ausbremsen anderer Entwickler • Nachteil: Chaos bei häufig veränderten Ressourcen • Lösung: für selten genutzte Dateien progressiver, für sehr kritische oder häufig genutzte Dateien konservativer Ansatz Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 431 Herstellung der Entwicklungsumgebung 12.2 • In großen Projekten arbeiten Entwickler häufig nicht auf einer Quelldatei; Dateien werden lokal kopiert und dort bearbeitet – Vorteil: ordentliche Verfolgung von Änderungen, laufende Programmversionen können nicht verloren gehen – Nachteil: Entwickler muss Kopien für seinen Arbeitsbereich erstellen • Lösung: Automatisierung des Kopier- und Übersetzungsprozesses (+ weiterer Standardaufgaben) – Einsatz von Skripten sh, *.bat – besser: Einsatz von Werkzeugen, wie make und ant (auch Build-Tools genannt) • In Großprojekten muss der Entwickler die dahinter liegenden automatisierten Prozesse nicht kennen, er muss nur wissen, wo „seine“ mit welchen Randbedingungen läuft • Software durchläuft bei der Installation häufig eine Installationsroutine, bei der u. a. Pfade gelesen und bearbeitet werden Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 432 Ant • Apache Ant (another neat tool, James Duncan Davidson) ist Alternative zu make-Files • Ant-Files können betriebssystemunabhängig formuliert werden • alle Befehle im XML-Format • viele Werkzeuge bieten XML-Tasks an, mit denen verschiedene Befehle des Werkzeugs aus Ant heraus ausgeführt werden können (z. B. Kompilieren) • Ant kann leicht erweitert werden, da in Java geschrieben, als Framework konzipiert • Ant benötigt XML-Parser, Apache Xerces mitgeliefert • erste Schritte auf Veranstaltungswebseite Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 433 Konzept von Ant (und make) • Es gibt zentrales Ziel (project) , was erreicht werden soll (z. B. vollständige Kompilation) • Jedes Ziel besteht aus Teilzielen (target), die vorher erreicht werden müssen (z. B. Übersetzung eines Teilpakets) • Werkzeug stellt Regeln auf, was in welcher Reihenfolge gemacht werden muss, um zentrales Ziel zu erreichen • Werkzeug bietet dabei u. a. – Reaktionsmöglichkeiten bei Fehlern – Varianten bei der Ausführung – Möglichkeit, Ordner zu löschen und anzulegen, Dateien zu kopieren, verschieben und löschen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 434 Erinnerung an make all : file1.o file2.o file3.o gcc -o prog file1.o file2.o file3.o file1.o : file1.c gcc -Wall -c file1.c file2.o : file2.c gcc -Wall -c file2.c file3.o : file3.c gcc -Wall -c file3.c Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 435 Beispiel für Abhängigkeiten <target <target <target <target name="init"/> name="preprocess" depends="init"/> name="compile" depends="init,preprocess"/> name="package" depends="compile"/> • Die Reihenfolge der Ziele (target) in der Datei hat keine Bedeutung, nur „depends“ dabei wichtig • Neben einem default-Ziel kann man beim Start ein Ziel auswählen, z. B. compile • alle depends betrachtet und schrittweise vom Werkzeug in mögliche Reihenfolge gebracht, hier: – init hat keine Abhängigkeiten, wird zuerst ausgeführt (was, hier nicht sichtbar) – preprocess benötigt init, da schon ausgeführt, wird nur preprocess ausgeführt Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 436 Ant-Basisskript (erzeugt von Eclipse) <?xml version="1.0"?> <!-- ============================================= Projekt, Datum, Aufgabe Autor, ============================================= --> <project name="project" default="default"> <description> description </description> <!-- ================================= target: default ================================= --> <target name="default" depends="depends" description="--> description"> </target> <!-- - - - - - - - - - - - - - - - - target: depends - - - - - - - - - - - - - - - - - --> <target name="depends"> </target> </project> Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 437 Skript-Konstanten (Eigenschaften, Properties) • <property name="eigen" value = "Wert" /> • Nutzung von Property-Werten mit ${eigen} <property name= "db" value = "${eigen}.db"/> • Bei Pfaden wird statt „value“ dann „location“ genutzt, dabei werden / und \ automatisch angepasst <property name="ziel" location="${p}/bla/fas"/> <property name="ziel" location="${p}\bla\fas"/> • Laufwerksbuchstaben, wie „C:“ sind verboten (möglichst mit relativen Pfaden arbeiten) • Es gibt vordefinierte Properties, z. B. ${user.home} Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 438 Beispiel-Task: Kompilieren <!-- classpath in der Form besser weglassen! --> <target name="compile" depends="start" description="kompiliere"> <javac srcdir="src" destdir="build" classpath="." debug="on"> </javac> <echo message="in compile"/> </target> • weitere Parameter können der Ant-Dokumentation entnommen werden (...\ant\docs\manual\index.html) • classpath nur nutzen, wenn weitere Pakete genutzt werden • echo hier als Spielerei • Übersetzung aller Klassen in Verzeichnis src und Unterverzeichnissen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 439 Beispiel-Task: Packen <!-- existierendes Manifest mit Attribut file="" --> <target name="pack" depends="compile" description="packe"> <jar destfile="dist/gepackt.jar" basedir="build"> <manifest> <attribute name="Main-class" value="de.kleuker.XStarter"> </attribute> </manifest> </jar> <echo message="in pack"/> </target> • hier wird Manifest-Datei direkt erzeugt, zu nutzende Datei kann auch angegeben werden Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 440 Hilfsmittel: Zeitstempel • Einfachste Form: Task <tstamp/> , dann nutzbare Variablen: – DSTAMP: aktuelles Datum, Default-Format yyyymmdd – TSTAMP: aktuelle Uhrzeit, Default-Format hhmm – TODAY: aktuelles Datum als String • konfigurierbar über format-Property <target name="zeigeZeit"> <tstamp> <format property="TODAY" pattern="dd.MMMM.yyyy" locale="de,DE"/> </tstamp> <echo message="DSTAMP = ${DSTAMP}"/> <echo message="TSTAMP = ${TSTAMP}"/> <echo message="TODAY = ${TODAY}"/> </target> [echo] DSTAMP = 20080209 [echo] TSTAMP = 1234 [echo] TODAY = 09.Februar.2008 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 441 Umgang mit Files und Dateien • <mkdir dir="${builddir}"/> – legt auch fehlende Unterverzeichnisse z. B. bei /dist/nase/simpel/billig an – übersprungen, falls Verzeichnis existiert • <delete dir="${builddir}"/> • <copy file="src/Hai.java" tofile="back/Hai.java"/> • <move file="src/Hai.java" tofile="back/Hai.java"/> • Pattern / Wildcards / reguläre Ausdrücke – * für beliebig viele Zeichen – ? für genau ein Zeichen – ** alle Unterverzeichnisse, z. B. **/*.java • häufig Property fileset zum Ein- und Ausschließen nutzbar <copy todir="archive"> <fileset dir="src"> <include name="*.java"/> </fileset> </copy> Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 442 Aufgaben des Konfigurationsmanagements (1/3) BuildManagement ReleaseManagement Versionsmanagement Änderungsmanagement Grundkurs Software-Engineering mit UML, 2. Auflage ProzessUnterstützung Stephan Kleuker 443 Aufgaben des Konfigurationsmanagements (2/3) • Versionsmanagement – soll Produkte zu einem definierten Zeitpunkt eindeutig identifizieren und kennzeichnen – erstellt damit Gültigkeitsreihenfolge • Build-Management – den Build-Prozess vollständig beschreiben – automatische Abläufe unterstützen – Reproduzierbarkeit von Softwareintegrationen sicher stellen • Release-Management – Verwaltung von ausgelieferter Software – Releaseplanung – Distribution (Erstauslieferung, Ersatz gelieferter SoftwareVersionen) – Rückruf gelieferter Software Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 444 Aufgaben des Konfigurationsmanagements (3/3) • Änderungsmanagement – stellt die kontrollierte Änderung von akzeptierten Produkten sicher – dazu werden Daten festgehalten über: • Fehler- und Problemmeldungen • Änderungsaufträge • Bearbeitungsstand der Änderungsaufträge • erforderliche und geleistete Aufwände • geänderte Produkte • Prozessunterstützung – da im KM alle Projekt-Produkte verwaltet werden, muss das werkzeuggestützte KM die zugehörigen Prozesse unterstützen – Erstellung und Änderung von Produkten – Berücksichtigung von Abhängigkeiten Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 445 Voraussetzungen für einen Projektbeginn 12.3 • klare Aufgabenbeschreibung • Festlegung des Projektleiters • Klärung, welche technischen und organisatorischen Randbedingungen berücksichtigt werden müssen • in studentischen Projekten liegt meist keine Aufwandsschätzung vor, diese muss durch Annahmen ersetzt werden • Übung: Diskutieren Sie typische Vorgaben für Projekte in Unternehmen, die gemacht werden, aber nicht unbedingt hilfreich sind Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 446 Auswahl des Vorgehensmodells • Vorgehensweise beeinflusst Planung maßgeblich – Wasserfall – prototypische Entwicklung – iterativ inkrementelles Modell – agiles Vorgehensmodell • Planungsaufwand (am Anfang und im Laufe des Projekts) nimmt von oben nach unten zu • Vorgehensweise muss zur Aufgabengröße und Projektmitarbeitern passen • im folgenden: kurzer inkrementeller Ansatz (leicht für komplexere Ansätze erweiterbar) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 447 Festlegung der Arbeitspakete • Zerlegung in sogenannter Work-BreakdownStructure (auch Projektstrukturplan) • hierarchische Untergliederung • Ziele: klare Aufgabenpakete, Vermeidung überflüssiger Schnittstellen • Berücksichtigung von Querschnittsaufgaben wie Projektleitung, Qualitätssicherung • für Aufgabenpakete werden Aufwände kalkuliert (wie siehe später) • Später kann WBS weiter verfeinert werden (Detailaufgaben, Verantwortliche, Beteiligte) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 448 Beispiel für WBS • PT = Personentage • Es muss deutlich sein, wo welches Produkt zugehört (hier z. B. Dokumentation querschnittlich bei allen) Projekt Perpetuum 130 PT 10 PT Projektleitung 80 PT Qualitätssicherung Prototypentwicklung 15 PT Projektinfrastruktur 35 PT Use Case Energieverbrauch 10 PT Grundkurs Software-Engineering mit UML, 2. Auflage 5 PT Entwicklung Use Case Energieerzeugung 35 PT Stephan Kleuker Netzwerkanbindung 20 PT 449 Abhängigkeiten von Arbeitspaketen Es gibt Beziehungen zwischen Arbeitspaketen: • typisch: Paket 2 benötigt Ergebnisse von Paket 1, also muss Paket 1 vorher fertig werden (Ende-Anfang-Beziehung) • Anfang-Anfang-Beziehung: Arbeiten sollen bzw. müssen parallel starten (z. B. Nutzung gemeinsamer Ressourcen, wie Testumgebungen) • Ende-Ende-Beziehung: Arbeiten sollen möglichst gleichzeitig abgeschlossen werden (z. B. damit Ergebnisse integriert werden können) • (Anfang-Ende-Beziehung, vor dem Anfang einer Arbeit muss andere Arbeit abgeschlossen sein, bei Rückwärtsplanung) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 450 Netzplan und kritische Pfade • Abhängigkeiten und Aufwände können als Graph dargestellt werden P2 Paket 4 6 min. max. P1 P5 Dauer Dauer 3 7 5 7 P3 P4 2 5 3 4 • Grundregel 1: Jedes Arbeitspaket enthält einen gewissen Risikoaufschlag • Jeder zeitlich mögliche Durchlauf durch den Graphen stellt möglichen Projektplan dar • Beispiel P1 P2 P3 P4 P5, minimale Dauer 17, maximale Dauer 29 • Optimierungen berechnen, hier z. B. zuerst P1, dann parallel P2 und P3 starten, nach P3 dann P4, nach P4 und P2 dann P5, minimale Dauer 13, maximale Dauer 23 • zwischen P2 und P5 maximale Pause von 5 • Man erkennt kritische Pfade (legen Projektdauer fest) • Grundregel 2: Jedes Arbeitspaket auf dem kritischen Pfad erhält einen zusätzlichen Risikoaufschlag Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 451 Einflüsse der Projektplanung Abhängigkeiten von Arbeitspaketen Risikominimierung durch Zeitpuffer Projektplan Verfügbarkeit von Mitarbeitern Grundkurs Software-Engineering mit UML, 2. Auflage individuelle Randbedingungen (z. B. Kundenwünsche, Ausbildungen, Messen) Stephan Kleuker 452 Erster Projektplan (1/2) Mai 2008 Juni 2008 Juli 2008 Projekt Perpetuum Machmann[30%] [30 %] > Projektleitung Penibel[30%] [30 %] > Qualitätssicherung Versionmann[20%] [30 %] > Infrastruktur > Entwicklung > Prototyp > Analyse > Design > Codierung Schmidt[60%] [100 %] Schmidt[80%] [100 %] Meier[80%] [100 %] > Abnahme Netzbert[50%] Grundkurs Software-Engineering mit UML, 2. Auflage > Netzwerkanbindung Stephan Kleuker [70 %] 453 > Codierung Meier[80%] [100 %] Erster Projektplan (2/2) > Abnahme Netzbert[50%] > Netzwerkanbindung [70 %] > UC Energieverbrauch > Analyse > Design > Codierung Meier[20%], Schmidt[60%] [30 %] Meier[80%] [0 %] Meier[100%] [0 %] > Abnahme > UC Energieerzeugung Schmidt[80%] > Analyse > Design > Codierung [30 %] Schmidt[80%] [0 %] Schmidt[80%] [0 %] Meier[40%] Schmidt[80%] [0 %] > Integration > Endabnahme Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 454 Sachstandsanalyse Ressourcenverbauch (Abweichung) zu langsam Verbrauch ok -50% (zu) schnell (zu) effizient zu langsam Verbrauch nicht ok Fertigstellungsgrad (Abweichung) 0 -50% Desaster! +50% (zu) schnell Verbrauch ok 50% (zu) schnell Verbrauch nicht ok Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 455 Aufwand oder Kosten ? 12.4 • Aufwand (costing): –was getan werden muss, Personenmonate für technische Ausführung, Verwaltung, Management, Material • Kosten (prizing): –wie viel wird vom Kunden verlangt? –Gewinnmaximierung vs. Ölfleck Kosten können sich aus politischen Gründen ändern, der Aufwand für die gleiche Aufgabe nicht Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 456 Warum schätzt man? • Aufwandsbestimmung am Anfang des Projekts • Schätzung des verbleibenden Aufwands im laufenden Projekt • Gegenseitige Aufwandsschätzung bei Geschäftspartnern • Offenlegung der Aufwandsansetzung gegenüber dem Kunden (Preisfindung) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 457 Zusammenfassung der Function Point Analyse funktionale Anforderungen Einflussfaktoren Schätzung Schätzung ungewichtete Function-Points Projekteinflüsse Berechnung gewichtete Function-Points Ableitung Aufwand Personenmonate Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 458 Function-Point-Methode (1/4) [Bal98] Jede Anforderung (bzw. ermittelte Funktionalität) in eine der fünf Kategorien einordnen • Internal Logical Files (ILF, Datenbestand): Datenbestände, die innerhalb des zu entwickelnden Systems bearbeitet werden, z. B. die selbstentwickelten Klassen • External Interface Files (EIF, Referenzdaten): Datenbestände die von außerhalb des zu entwickelnden Systems kommen und bearbeitet werden • External Inputs (EI, Eingabe): Eingaben von außerhalb in das zu entwickelnde System mit denen der Datenbestand verändert wird, z. B. über Eingabemasken, Dateien in bestimmten Eingabeformaten, Eingaben von externen Systemen • External Outputs (EO, Ausgabe): Ausgaben an außerhalb des zu entwickelnden System liegende Komponente, z. B. Ausgabemasken, Dateien in bestimmten Ausgabeformaten; Ausgaben weden aus vorhandenen Daten berechnet • External Inqueries (EQ, Abfrage): Abfragen von Informationen des Datenbestands von außerhalb des Systems, z. B. Abfragemasken, reines Anzeigen der verwalteten Daten Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 459 Function-Point-Methode (2/4) Kategorie Eingabedaten Abfragen Ausgaben Datenbestände Referenzdaten Anzahl Klassifizierung Gewichtung Zeilensumme 6 einfach *3 18 4 mittel *4 16 komplex *6 einfach *3 mittel *4 komplex *6 6 einfach *4 24 9 mittel *5 45 komplex *7 einfach *7 mittel * 10 komplex * 15 einfach *5 mittel *7 komplex * 10 4 7 Summe ungewichteten Function-Points Grundkurs Software-Engineering mit UML, 2. Auflage 12 49 164 Stephan Kleuker 460 Function-Point-Methode (3/4) Summe unbewertete Function-Points 164 Verflechtung mit anderen Anwendungssystemen (0-5) 1 Dezentrale Daten, dezentrale Verarbeitung (0-5) 2 Transaktionsrate (0-5) 2 Verarbeitungslogik Rechenoperationen (0-10) 1 Kontrollverfahren (0-5) 3 Ausnahmeregelungen (0-10) 0 Logik (0-5) 2 Wiederverwendbarkeit (0-5) 3 Datenbestandskonvertierungen (0-5) 2 Anpassbarkeit (0-5) 1 Summe der Einflussfaktoren (EF) Faktor Einflussbewertung (FE) = 17 EF / 100 + 0,7 0,87 Gewichtete Function-Points = ungewichtete Functionpoints *FE 143 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 461 Function-Point-Methode (4/4) 1000 Personenmonate X X X X X X o X o o X X 0 0 X X Unternehmen 1 Unternehmen 2 o X Function Points Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 5000 462 Fazit zur Function-Point Analyse • Wissenschaftlich fundiert • Schätzdetails nur von speziellen Schätzexperten beurteilbar • firmenspezifische und methodenspezifische Optimierung schwierig • Wenn FPA eingesetzt werden soll, muss sie (evtl. rückwirkend) für verschiedene Projekte evaluiert werden • sinnvoll, wenn eigene Schätzabteilung zur Betreuung aller Schätzungen aufgebaut wird • wesentlich höherer Aufwand als später vorgestellte vereinfachte Analogieschätzung, Schätzer fühlen sich nicht für Schätzergebnis verantwortlich Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 463 Von CoCoMo81 zu CoCoMo II Kostenschätzverfahren von Barry W. Boehm (ab 1981) • Die Art der SW-Entwicklung hat sich in den Jahren wesentlich verändert (Methodik) • Die Programmiersprachen haben sich verändert (Aufkommen von OO-Sprachen) • Man kann weitere Einflussfaktoren auf den Aufwand feststellen • Es ist interessant, eine Schätzung zu verschiedenen Zeitpunkten des Projektfortschritts durchzuführen • Mittlerweile viele Varianten für verschiedene Vorgehensmodelle und Projektarten -> führt zur Verbesserung von CoCoMo 81 Literatur: B. W. Boehm, C. Abts, A. W. Brown, Software Cost Estimation with Cocomo II, Prentice Hall PTR, 2000 http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 464 CoCoMo II – zentrale Formel • Personenmonat wird mit 152h gerechnet • EM sind die einzelnen Kostentreiber • für Early Design : n=7 • für Post Architecture: n=17 • A ist Produktionskonstante, kann für verschiedene IT-Sektoren unterschiedlich sein (Default 2.45 in 1999) • Size bezieht sich wieder auf KDSI (Kilo Lines of Documented Source Instrctions) • Hinweis: Alle Default-Werte von CoCoMo basieren auf einer größeren Anzahl (>60) von Projekten Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 465 Variable E • B hat Standardwert 0.91 (1999) • Dazu kommen fünf Scaling Factors: Sehr gering Geschäftstätigkeit im PREC Produktbereich Entwicklungsfreiräume FLEX Ausgereiftheit des RESL Produktentwurfs Einvernehmen zwischen TEAM Stakeholdern Software-Prozessreife (nach SEI-CMM[I]) PMAT Grundkurs Software-Engineering mit UML, 2. Auflage Gering Normal Hoch Sehr hoch Extra hoch 6.20 4.96 3.72 2.48 1.24 0 5.07 4.05 3.04 2.03 1.01 0 7.07 5.65 4.24 2.83 1.41 0 5.48 4.38 3.29 2.19 1.10 0 7.80 6.24 4.68 3.12 1.56 0 Stephan Kleuker 466 Kostentreiber EM (Early Design) Einflussfaktor Extra Sehr Gegering gering ring Produktzuverlässigkeit 0.73 und -Komplexität 0.81 Normal Hoch Sehr Extra hoch hoch 0.98 1 1.30 1.74 2.38 Angestrebte Wiederverwendbarkeit 0.95 1 1.07 1.15 1.24 Zielplattformbesonder heiten 0.87 1 1.29 1.81 2.61 Personalfähigkeit 2.12 1.62 1.26 1 0.83 0.63 0.50 Personalerfahrung 1.59 1.33 1.12 1 0.87 0.71 0.62 Qualität der Entwicklungsbedingungen 1.43 1.30 1.10 1 0.87 0.73 0.62 1.43 1.14 1 1 Entwicklungszeitrahmen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 1 467 CoCoMo im Überblick Abschätzung der Systemgröße (KDSI) Produkt-, Prozess-, Plattformund Personal-Attribute Wiederverwertbarkeits- und Wartbarkeitsparameter CoCoMo II Abschätzung für Entwicklungsund Wartungskosten für verschiedene Entwicklungsphasen Daten bereits abgeschlossener Projekte Iterative Aktualisierung Kalibrierung auf eigene Organisation Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 468 Vereinfachter Analogieschluss Forderungen an das Schätzverfahren • Erfahrungen aus anderen Projekten müssen einfließen können • Verfahren muss für alle Schätzbeteiligten verständlich sein • Einzelne Schätzfaktoren müssen verständlich sein • Schätzfaktoren müssen an Projekteigenheiten anpassbar sein • Schätzergebnisse müssen an neue Projektsituationen anpassbar sein • Schätzergebnis muss dokumentierbar (nachvollziehbar) sein • Einbettung in weitere Geschäftsprozesse Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 469 Vorbereitung der Schätzung Grundkurs Software-Engineering mit UML, 2. Auflage Optionseinstellungen Graphikeinbindung Ansichtenerstellung 2. vergleichbares Projekt liegt mit Aufwandsdaten und vergleichbarer Komponentenstruktur vor Nutzer-Interface Textbearbeitung 1. Projekt in dokumentierte Komponenten /SWEinheiten / Use Cases zerlegt Basisdienste Stephan Kleuker 470 Umgang mit „Projektumfeldkosten“ • HW wird getrennt betrachtet • Projektmanagement (PM), Qualitätsmanagement und Konfigurationsmanagement wird analog zum Vergleichsprojekt (Normierungsprojekt) behandelt Wünschenswert: genannte Managementkosten in Komponenten des Normierungsprojekts eingerechnet Wenn nicht möglich: Aufwände aus bekannten Aufwänden des Normierungsprojekts extrapolieren Beispiel: Entwicklungsaufwand 100 PT (Personentage), für PM 15 PT, dann später 15% für PM auf berechneten Wert aufschlagen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 471 Aufbau des Schätzansatzes Vorbereitung der Schätzung Durchführung der Schätzung Analogieschluss Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 472 Analogie-Schätzung (1/3): Vorbereitung 1. Festlegung der Schätzparameter A: Wiederverwendung [1-3] (vollständig bis neu) B: Funktionsumfang [1-8] (einfach bis hoch komplex) C: Abhängigkeiten [1-3] (gering bis stark) D: Kritikalität [1-2] (niedrig, mittel, hoch) K-Faktor= A*B*C*D 2. gemeinsame Skalierung der Parameter durch Schätzer („B=4 heisst ...“) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 473 Schätzparameter- zwischen Erfahrung und Voodoo Generell gilt: gezeigte Schätzparameter sind Vorgabe, die sich häufig als sinnvoll herausgestellt hat Aber: Anpassungen der Wertebereiche und der Anzahl der Schätzparameter erlaubt Ansatz: mit Standardparametern anfangen, bei unrealistischem Ergebnis modifizieren, Änderungen dokumentieren Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 474 A: Wiederverwendung 1 1,3 1,6 1,9 3 Komponente besteht rein aus der Wiederverwendung bereits existierender Ergebnisse, die nur neu zusammengesetzt werden müssen Hoher Grad der Wiederverwendung, es müssen nur Anpassungen an relativ leicht zu identifizierenden Stellen vorgenommen werden Hoher Grad der Wiederverwendung, neben kleinen Anpassungen müssen einige eigenständige Erweiterungen vorgenommen werden, aus der vorliegenden Dokumentation wird deutlich, wo Neuentwicklungen eingebunden werden sollen Einige Teile können wiederverwendet werden, grundlegende Designideen sind übernehmbar Neuentwicklung, bzw. alle existierenden Ergebnisse müssen intensiv überprüft werden Hinweis: Wiederverwendung kann sich auf selbst erstellte Software, Freeware oder gekaufte SW beziehen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 475 B: Funktionalität 1-8 es muss festgehalten werden, wie groß der maximale Unterschied in der Größe der Komponenten sein kann, für einen oder mehrere Werte sollen konkrete Beispielfunktionalitäten (Teilkomponenten) genannt werden, es werden nur neue und zu modifizierende Funktionalitäten betrachtet 1- sehr einfach 8 - hochkomplex Hinweis: Funktionalität bezieht sich nur auf die Komplexität der neu zu erstellenden SW (also B=0, wenn nichts gemacht werden muss) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 476 C: Schnittstellen 1 keine oder geringe Abhängigkeiten von anderen Komponenten 2 Kommunikationsaufwand mit verschiedenen Komponenten 3 hoher Kommunikationsaufwand mit anderen Komponenten, starke Abhängigkeit von anderen Komponenten Hinweis: Der C-Wert steigt, wenn es um Schnittstellen über Firmengrenzen hinweg oder um Schnittstellen noch zu entwickelnder Systeme geht Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 477 D: Kritikalität 1 niedrige Kritikalität Projekt scheitert nicht, wenn Komponente kleinere/ mittlere Fehler enthält 1,5 mittlere Kritikalität Funktionalität und Kundenzufriedenheit wird bei Fehlern eingeschränkt, System bleibt nutzbar 2 hohe Kritikalität Projekt scheitert, wenn nur kleinere oder mittlere Fehler in dieser Komponente sind Hinweis: Kritikalität ist hier zunächst nach V-Modell gegeben, Übersetzung für andere Modelle: Projektrisiko, wenn Komponente nicht vollständig oder „wie gewünscht“ funktioniert (-> Testaufwand) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 478 Skalierung der Schätzparameter Alle Schätzer setzen sich an einen Tisch, wählen eine Beispielkomponente, die jeder gut verstanden hat und legen beispielhaft Werte für A,B,C,D fest. Achtung! Der resultierende Wert A*B*C*D hat zunächst keine Bedeutung. Technisches Ziel: Vermeidung, dass später zu häufig B=1 auftritt Gesamtziel: „Gleichschaltung“der Köpfe bzgl. Parameterwerte Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 479 Analogie-Schätzung: Durchführung 1. Gemeinsame Schätzung einer neuen Beispielteilaufgabe (evtl. mehrere) Teilaufgabe A Neu1 B C D ABCD 1.9 5 2 2 38 2. Individuelle Schätzung mit Konsolidierung durch Schätzkonferenz Teilaufgabe A B C D ABCD Neu1 1.9 5 2 2 38 Neu2 3 4 2 1.5 32 Neu3 3 6 1 1.5 27 Neu4 3 2 3 2 36 Neu5 1.6 5 2 1 16 Grundkurs Software-Engineering mit UML, 2. Auflage 3. Individuelle Schätzung des Altprojekts (Aufwand in Personentagen, PT, bekannt), mit Konsolidierung durch Schätzkonferenz Teilaufgabe PT A B C D ABCD Alt1 188 3 5 2 2 60 Alt2 62 1.9 5 2 1 19 Alt3 149 3 6 1.5 2 54 Alt4 54 3 2 3 18 Summe 453 1 151 4. Berechnung des Wertes eines Aufwandspunktes 453/151 = 3 Stephan Kleuker 480 Analogie-Schätzung: Analogieschluss 5. Bestimmung des Aufwandes in PT des neuen Projekts mit Analogieschluss Teilaufgabe A B Neu1 1.9 5 Neu2 3 4 C 2 2 D ABCD 2 38 1.5 32 Aufwand 114 96 Neu3 Neu4 Neu5 1 3 2 1.5 27 2 36 1 16 81 108 48 3 6 3 2 1.6 5 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 481 Kommentare zum Schätzverfahren • Schätzendergebnis wird von allen Schätzern begutachtet, wenn nicht plausibel, dann Parameter modifizieren Beispiel: C=1,2,3 zu weit, Ansatz C=2, 2.5, 3 • Die Qualität steigt, wenn jeder Schätzer jede Komponente schätzen kann, dies ist in der Realität meist nicht möglich • Zur Normierung der Schätzer im Schritt 2 ist auch Komponente des Vergleichsobjekts wählbar • Vergleichsprojekt können Teilkomponenten aus einem größeren System sein • Der Begriff der mathematischen Unabhängigkeit (insbesondere zwischen Funktionalität und Schnittstellen, sowie Funktionalität und Kritikalität) muss den Schätzern klar sein • Ergänzung um Vergleich der Projektrisiken der beiden Projekte sinnvoll (Skalierungsfaktor), nächste Folie; falls große Abweichung von Null Skalierungsprojekt evtl. nicht geeignet Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 482 Logische und psychologische Zahlen • Diskussionspunkte sind häufig die Wertebereiche der einzelnen Schätzfaktoren, dabei ist das Verständnis wichtig, dass von C=1 zu C=1.5 der Aufwand um 50% steigt • Der Wertebereich bei der Funktionalität wurde aus „psychologischen Gründen“ sehr hoch angesetzt, da hier meist der größte Klärungsbedarf im Verständnis besteht • Man beachte: wird ein Wertebereich z.B. bei C von [1…3] auf [1…9] erweitert und wird dann statt C=2 mit C=6 gerechnet, ändert sich am Schätzwert nichts AufwandN = AN*BN*CN*DN*(AufwandA/ (AA*BA*CA*DA)) = AN*BN*CN*3*DN*(AufwandA/ (AA*BA*CA*3*DA)) N = neu, A= alt Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 483 Teufelsquadrat für IT-Projekte nach Sneed 12.5 Qualität Funktionalität Kosten Zeit • Konzentration auf ein Ziel erzwingt bei gleichen Rahmenbedingungen Vernachlässigung mindestens eines anderen Ziels (Verbesserung im Bild bedeutet ziehen des Schwerpunkts in diese Richtung) • generelle Verbesserung nur durch Verbesserung der Rahmenbedingungen (z.B. der Prozesse) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 484 Definition Qualitätsmanagement (eine Variante) Definition: Umfasst »alle Tätigkeiten der Gesamtführungsaufgabe, welche die Qualitätspolitik, Ziele und Verantwortungen festlegen sowie diese durch Mittel wie Qualitätsplanung, Qualitätslenkung, Qualitätssicherung und Qualitätsverbesserung im Rahmen des Qualitätsmanagementsystems verwirklichen« (DlN EN ISO 8402). Unterscheidung in: • Produktorientiertes Qualitätsmanagement (Produkt und Zwischenergebnisse auf festgelegte Gütemerkmale prüfen) • Prozessorientiertes Qualitätsmanagement (Alle Mitarbeiter müssen ein Qualitätsbewusstsein entwickeln permanente Adaptierung) Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 485 Zusammenhang der Q-Begriffe Qualitätsmanagement (Qualität aller Prozesse) Prozess X Prozess Y Software-Entwicklungsprozess Qualitätssicherung konstruktiv Grundkurs Software-Engineering mit UML, 2. Auflage analytisch Stephan Kleuker 486 Prozesse als Firmenqualitätsmaßstab: CMM[I] • ursprünglich Capability Maturity Model (CMM) • Auftrag durch das DoD • Hilfsmittel zur Beurteilung der Leistungsfähigkeit von Softwarelieferanten • Reifegrad der Software-Entwicklungs5 Optimizing prozesse ermitteln • gezielte Prozessverbesserung 4 Quantitatively Managed • CMM(I) definiert 5 Stufen der Managed (CMM) Reife einer Organisation 3 Defined • aktuell: CMMI for Development, 2 Managed Version 1.2 Repeatable (CMM) (CMMI-DEV) 1 Initial Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 487 Stufe 1: Initial • Merkmal: Keine stabile Umgebung, ad-hoc Durchführung • Fokus: gute Mitarbeiter • Unvorhersagbares Ergebnis: bei erneuter Durchführung des Projektes würde alles ganz anders laufen • Brandbekämpfung statt Planung, Planabweichung in Krisensituationen • Gelingen des Projektes nur durch äußersten Einsatz aller Beteiligter, hängt an Einzelpersonen • Risikobehaftet, unplanbar und ineffizient Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 488 Stufe 2: Nachvollziehbar (managed) • Merkmal: Gleiche Anforderungen ergeben gleiche Resultate • Fokus: Projektmanagement – Richtlinien für Software-Projektmanagement existieren und werden umgesetzt – Überwachung von Zeit, Kosten, Produktqualität • Basierend auf früheren Projekten • Softwarestandards, Konfigurationsmanagement • Stabiler Prozess Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 489 Stufe 3: Definiert (defined) • Merkmal: Wohldokumentierte Prozesse • Fokus: Organisationsunterstützung – Stabile und wiederholbare SW-Entwicklungs- und SW-Projektmanagement-Prozesse – Abnahmekriterien, Standards, QS-Maßnahmen definiert und dokumentiert – Möglichkeit der Anpassung von Standards • Rolle des Softwareprozess-Verantwortlichen • Weiterbildungsmaßnahmen eingeplant • Regelmäßige Expertenbegutachtung Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 490 Stufe 4: Beherrscht (quantatively managed) • Merkmal: Quantitativ messbare Prozesse • Fokus: Produkt- und Prozessqualität – Leistungsmessung von Produktivität und Qualität – Metriken für Software • Messbare, vorhersagbare Prozesse in definierten Grenzen • Messbare, vorhersagbare Produktqualität • Steuerungsmöglichkeit bei Schwankungen Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 491 Stufe 5: Optimierend (optimizing) • Merkmal: Gesamte Organisation fokussiert auf kontinuierliche Prozessverbesserung • Fokus: Ständige Evaluation und Einführung neuer Technologien und Verbesserungsmöglichkeiten – Möglichkeit zur Stärken/Schwächenanalyse – Proaktive Fehlervermeidung – Dauernde Implementierungsmöglichkeit für Verbesserungen der Softwareprozesse (direkte Einbringung von Verbesserungsvorschlägen) • Verbesserungen auf der Meta-Ebene Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 492 Überblick: Verbesserungen mit dem CMMI Stufe 5 Optimizing Start Ende Start Ende Stufe 3 Defined Start Ende Stufe 2 Managed Start Stufe 1 Initial Start Stufe 4 Quantitatively Managed Analyse Grundkurs Software-Engineering mit UML, 2. Auflage Entwicklung Bearbeitung Stephan Kleuker Test Ende Ende 493 Skizze einer CMMI-Anpassung alter Firmenstandard SP 1.1 des CMMI Grundkurs Software-Engineering mit UML, 2. Auflage nach CMMIÜberarbeitung fehlen: Produkte, Verantwortlichkeiten Stephan Kleuker 494 Personal Software Process (PSP) • CMMI gibt Rahmen für Unternehmensprozesse; nicht einfach auf Individuum herunterbrechbar • Ansatz: Entwickler durchlaufen Qualitätsentwicklung z. B. durch Schulungen; Ansatz des PSP in Programmierung ausgebildete Entwickler definierten Prozess nutzen Zeit erfassen PSP 0 Defekte erfassen und analysieren PSP 1 Arbeiten planen Aufwände schätzen, Zeitpläne erstellen Optimierungen analysieren PSP 2 Qualitätsmanagement Erstellung von Qualitätsplänen Messung eigener Qualität Entwickler mit garantierter Qualität und Schätzfähigkeit Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 495 Ganzheitliche Projektsicht 12.6 Arbeitsumfeld [schwarz] Fähigkeiten (Know how) [blau] soziale Ebene [rot] Grundkurs Software-Engineering mit UML, 2. Auflage Prozessebene [grün] Stephan Kleuker 496 Ebenen des ganzheitlichen Projektmanagements • Fähigkeiten: was können Projektmitglieder, welche Erfahrungen haben sie • Prozessebene: wie sind Arbeitsprozesse organisiert, sind Rollen klar abgegrenzt • Arbeitsumfeld: welche Werkzeuge gibt es, wie sind Arbeitsplätze organisiert • soziale Ebene: wer kann wie mit wem Grundregel: Probleme der einen Ebene können nicht auf der anderen Ebene gelöst werden • wenn Leute nicht miteinander können, helfen Prozessregelungen wenig • fähige Mitarbeiter werden durch schlechte Werkzeuge, große räumliche Trennung, unsaubere Toiletten ausgebremst • neue Werkzeuge benötigen Schulungen und Einarbeitung Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 497 Teamrollen • Es gibt einige psychologische Ansätze Menschen in ihrem Verhalten zu kategorisieren • Grobe Beschreiben, wie „eher extrovertiert“ oder „introvertiert“ sind möglich • Es gibt Typen die typischerweise gut miteinander können und andere, die zu Konflikten führen • Selten, dass Menschen sehr gute Techniker und sehr gute Verkäufer sind • Für erfolgreiche Projekte werden unterschiedliche Typen benötigt • „zu einem Typ gehörig“ ist weder negativ noch positiv; Teams müssen harmonisch zusammengesetzt werden • vorgestellter Ansatz beruht auf Meredeth Belbin • Achtung: Das Einteilen von Menschen in Typen mit bestimmten Verhaltensweisen ist aus gutem Grund von vielen Seiten angreifbar Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 498 Teamrollentypen nach Belbin (1/3) • Specialist – Experten, können sich neue Techniken erarbeiten, Stolz auf eigene Fähigkeiten – wenig Interesse an Anderen • Completer Finisher – sorgfältig bis ins Detail, beginnen nur Sachen, die sie beenden können, arbeiten stark aus eigenem Antrieb – delegieren ungern, undiplomatisch gegenüber Generalisten • Implementer – gute Pragmatiker (was ist wichtig und machbar), systematisch im Umgang mit komplexen Aufgaben, loyal zum Unternehmen, eher introvertiert, integer – nicht spontan, steht sehr kreativen Ideen ablehnend gegenüber Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 499 Teamrollentypen nach Belbin (2/3) • Teamworker (ausgeglichen, extrovertiert, kaum dominant) – guter Zuhörer, kommuniziert frei mit allen im Team, passt sich neuen Situationen schnell an – geht Konfrontationen aus dem Weg, überfordert mit zentralen Entscheidungen • Monitor Evaluator – ausgeglichen, ernsthafter klarer Blick für die aktuelle Situation, meist hohe Intelligenz, hohe Kreativität, entdeckt schnell Fehler – braucht lange für Entschlüsse, manchmal taktlos und herabsetzend in Analysen, zu kritisch • Shaper – hoch motiviert, leitet und koordiniert Teams gerne, findet Wege um Probleme, extrovertiert, besorgt, ob gewünschter Fortschritt erreicht wird – impulsiv, ungeduldig, manchmal leicht reizbar, gibt vielleicht zu schnell auf Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 500 Teamrollentypen nach Belbin (3/3) • Co-ordinator – stabil, dominant, extrovertiert, diszipliniert, führt Team, bemüht, externe Ziele und Vorgaben zu erreichen, guter Kommunikator, gut in der Besetzung von Projektrollen – eher kein kreativer Denker, geht (zu) ruhig an Aufgaben heran • Resource Investigator – locker, kommunikativ, leicht zu interessieren, bringt Ideen von Außen, Diplomat, Verkäufer, viele Außenkontakte – neigt zu zu großem Enthusiasmus, lässt Sachen schnell fallen, benötigt Anregungen von Außen • Plant – Quelle von originellen Ideen, Anregungen und Vorschlägen, dominierend, meist hohe Intelligenz, konzentriert auf Hauptaufgaben – introvertiert, kann störend oder kränkend wirken, kein Detailinteresse, wenig kritikfähig Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 501 Ermittlung des Teamrollentypen • Möglichkeit mit Fragebogen, möglich zur Selbstbewertung und Fremdbewertung • Beispiel: Verteilen Sie 10 Punkte auf die folgenden Aussagen, die auf Sie am Besten zutreffen (Häufung von Punkten auf wenigen Aussagen gewünscht) Wie verhalte ich mich, wenn ich mit anderen Leuten an einem Projekt beteiligt bin: – Ich besitze die Gabe jemanden zu beeinflussen, ohne ihn unter Druck zu setzen – Meine ständige Wachsamkeit verhindert Leichtsinnsfehler und Versäumnisse – Man kann sich darauf verlassen, dass ich originelle Ideen habe – Ich bin immer bereit, gute Vorschläge zu unterstützen, wenn sie im allgemeinen Interesse sind – Ich bin immer begierig, die allerneusten Ideen und Entwicklungen zu entdecken – ... Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 502 Kommunikation • Paul Watzlawik: „Man kann nicht nicht kommunizieren“ • Versuch, eine gemeinsame Informationsbasis zu finden • abhängig vom gemeinsamen Verständnis Decodierung Feedback Codierung Sender Empfänger Codierung Nachricht Decodierung • wichtig: Hintergründe, was passiert wann bei wem wohl warum, der Kommunikation erkennen • Achtung! Überinterpretationen • Kommunikationsverhalten kann/soll geschult werden, wobei Authentizität erhalten bleiben muss Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 503 vierfache Gestalt einer Äußerung (1/4) [SRS03] • Jeder Äußerung kann man vier Ebenen zuordnen • Beispiel: Prof zum Studi, „Die Klasse sollten Sie endlich mal kommentieren“ • Jede Äußerung enthält die vier genannten Botschaften • für jede Botschaft kann es eine Interpretation des Senders und des Empfängers geben • bei mehreren Anwesenden vervielfacht sich die Interpretation Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 504 vierfache Gestalt einer Äußerung (2/4) • Sachinhalt (worüber ich informiere) – Beispiel: Klassen sind zu kommentieren – kann aus Wahrheitsgehalt geprüft werden – kann auf Relevanz geprüft werden – kann auf Hinlänglichkeit geprüft werden (reicht Information aus, verstehen beide das Gleiche) – meist zentraler Bestandteil der Äußerung • Selbstkundgabe (was ich von mir zu erkennen gebe) – Beispiel: Prof ist verunsichert, ob zentrale Wünsche ernst genommen werden, Studi meint, dass Prof schlechte Laune hat – was geht in mir vor, wofür stehe ich, wie sehe ich meine Rolle – individuelle Schnabelform: Selbstdarstellung, Authentizität Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 505 vierfache Gestalt einer Äußerung (3/4) • Beziehung (was ich von dir halte und wie ich zu dir stehe) – Beispiel: Prof glaubt, dass Studi Potenzial hat, seine Schludrigkeit ihn aber von besseren Ergebnissen abhält, Studi meint, dass Prof ihn für unfähig hält, selbst einfachste Aufgaben zu lösen – geprägt durch Tonfall, Formulierung und Kontext der Äußerung – meist ein sehr sensibles Ohr – Beziehungsebene muss stabil sein, da sonst hier viele unterschwellige Konflikte möglich • wenn nicht: Uneinigkeit auf der Sachebene führt zu Störung der Beziehungsebene Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 506 vierfache Gestalt einer Äußerung (4/4) • Appell (was ich bei dir erreichen möchte) • Beispiel: Prof möchte, dass der Studi systematischer arbeitet, Studi (miss)-interpretiert, mach erstmal einfache Aufgaben bevor du programmierst • bei längeren Äußerungen kann der konkrete Appell verloren gehen • wenig erfolgreich, aber verbreitet: Appell mit negativer Beziehungsbotschaft zu verknüpfen „können Sie endlich mal ...“ Literatur • [SRS03] F. Schulz von Thun, J. Ruppel, R. Stratmann, Miteinander Reden: Kommunikationspsychologie für Führungskräfte, 2. Auflage, Rowohlt, Reinbek, 2003 Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 507 Teufelskreis „Führung“ [SRS03] • Kommunikationsproblem: „Verstärkung der Ansichten und negativen Empfindungen“ Führungskräfte machen: planen ihre Entscheidungen am „grünen Tisch“, tun seltene Kritik ab „höre ich selten, andere schaffen es auch“ fühlen: Bestätigung, dass der Kurs stimmt fühlen: Druck, Angst vor Positionsverlust machen: schweigen, dulden, antworten, auf Nachfragen „Läuft alles soweit gut“ Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker Mitarbeiter 508 Metakommunikation • Denken über Kreise, statt handeln in den Rechtecken • Kommunikation über den Nachrichtenfluss • Ausgangspunkt: Beschreibung des eigenen Fühlens und der Wahrnehmung des Anderen • persönliches Gespräch • fördert offene Kommunikation • Metakommunikation ist ein scharfes Schwert, dass mit Bedacht eingesetzt werden muss • Übungsaufgabe: Überlegen Sie Kommunikationsteufelskreise in Ihrem momentanen Leben und ob Metakommunikation helfen könnte Grundkurs Software-Engineering mit UML, 2. Auflage Stephan Kleuker 509
© Copyright 2024 Paperzz