Grundkurs Software-Engineering mit UML

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

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

1. Motivation von Software-Engineering
Stephan Kleuker

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Anmerkung: Die Raute kann natürlich weggelassen werden; man kann aber so die Aufmerksamkeit der Studierenden prüfen  Stephan Kleuker

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

Stephan Kleuker

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

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

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

Nutzung von Schwimmbahnen (für Rollen)
Stephan Kleuker

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

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

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

Risikomanagement Stephan Kleuker

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

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

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

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

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

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

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

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

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

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

Fertigstellung mit Iterationen
Stephan Kleuker

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

Bekanntheit von Vorgehensmodellen (2/2)
Stephan Kleuker

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

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

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

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

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

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

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

Beispielaktivität: Anforderungen festlegen
Stephan Kleuker

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

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

Struktur des RUP Stephan Kleuker

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Abgeleitetes Use Case-Diagramm
Stephan Kleuker

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

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

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

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

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

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

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

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

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

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

Beispiel zu <<include>>
Stephan Kleuker

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

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

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

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

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

Aktivitätsdiagramm um Alternativen ergänzt
Stephan Kleuker

Erinnerung: Modellierung aus Business-Sicht
Stephan Kleuker

Modellierung aus System-Sicht
Stephan Kleuker

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Visualisierung der Systemaktivitäten
Stephan Kleuker

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

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

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

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

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

Beispielübersetzung Stephan Kleuker

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

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

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

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

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

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

Beispiel: Projektstrukturplan
5.2 Stephan Kleuker

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Klassendiagramm Stephan Kleuker

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

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

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

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

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

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

Zusammenhang zwischen Aktivitäts- und Sequenzdiagrammen
Stephan Kleuker

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

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

Highlevel-Sequenzdiagramme
Stephan Kleuker

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

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

Beispiel: Fertigstellungsgrad berechnen
Stephan Kleuker

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

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

Beispiel: Projektaufgabenaufwand aktualisierbar?
Stephan Kleuker

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

Erweiterung mit Boundary-Klassen
Stephan Kleuker

Sequenzdiagramm mit Nutzungsdialog
Stephan Kleuker

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

Anforderungsverfolgung - Beispielzusammenhänge
Stephan Kleuker

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Beispiel: grobe Paketierung (zweite Variante)
Stephan Kleuker

Forderung: azyklische Abhängigkeitsstruktur
Stephan Kleuker

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hierarchische Zustände
Stephan Kleuker

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

Beispiel: Uhr Stephan Kleuker

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

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

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

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

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

Klärung, von welche Sensoren werden Signale empfangen: Zündschloss: start und ende Kupplung: leerlauf und druecken Automatiksteuerung: an und aus Klärung, welchen Sensoren können abgefragt werden: Temperaturwert temp in lokaler Variablen Klärung an welche Sensoren Signale geschickt werden Motorsteuerung: motor_an und motor_aus Stephan Kleuker

Stephan Kleuker

GUI als Zustandsdiagramm
Stephan Kleuker

Android als Zustandsdiagramm
Stephan Kleuker

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Design by Contract Stephan Kleuker

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

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

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

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

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

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

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

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

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

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

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

Stephan Kleuker

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

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

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

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

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

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

Beobachter (Observer – Observable)
Stephan Kleuker

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

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

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

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

Beispielanwendung: Abstract Factory Pattern
Stephan Kleuker

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

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

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

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

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

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

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

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

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

Strategy - Lösungsbeispiel
Stephan Kleuker

State-Pattern (eigene Variante)
Stephan Kleuker

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

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

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

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

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

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

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

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

Beispiel 6/12 : Ansatz 1: Steuerungsklassen
Stephan Kleuker

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

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

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

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

Beispiel 11/12 : Variante Undo-Methode
Stephan Kleuker

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Zentrale Eigenschaften von Komponenten
Stephan Kleuker

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

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

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

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

ProjektTreeModel ptm = new ProjektTreeModel(); JTree baum = new JTree(ptm); JScrollPane scroller = new JScrollPane(baum); add(scroller,BorderLayout.CENTER); Stephan Kleuker

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

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

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

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

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

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

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

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

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

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

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

DSL Prozesse Stephan Kleuker

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

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

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

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

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

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

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

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

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

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

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

Zusammenhang der Normen ISO 9241
10.2 Stephan Kleuker

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

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

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

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

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

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

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

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

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

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

Integration der Oberflächenentwicklung
Stephan Kleuker

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

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

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

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

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

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

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

Notwendige Anzahl von Testnutzern
Stephan Kleuker

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Stephan Kleuker

Ä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 Stephan Kleuker

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 Beispiel: Überschneidung von Intervallen: ueberschneide(int i1u, int i1o, int i2u, int i2o) Stephan Kleuker

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 Stephan Kleuker

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. Stephan Kleuker

Beispiel (2/5) Äquivalenzklassen: Eingabe gültige Äquivalenzklassen
ungültige Name Ä1) nicht leer Ä2) leer Geburtsjahr Ä4) 1900< = Geburtsjahr <= 2000 Ä3) Geburtsjahr < 1900 Ä5) Geburtsjahr > 2000 Fachbereich Ä6) FBING Ä7) FBBWL Ä8) FBPOL Stephan Kleuker

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 Stephan Kleuker

Beispiel (3/5) Testfälle nach einer Äquivalenzklassenanalyse: (jeder Klasse wird [mindestens] einmal getestet, die Testanzahl soll möglichst gering sein) Test-nummer 1 2 3 4 5 6 geprüfte Äquivalenzklassen Ä1 Ä4 Ä6 (Ä1) (Ä4) Ä7 Ä8 Ä2 Ä3 Ä5 Name „Meier“ „Schmidt“ „Schulz“ „“ Geburtsjahr 1987 1989 1985 1988 1892 2006 Fachbereich FBING FBBWL FBPOL Ergebnis ok Abbruch Stephan Kleuker

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) Stephan Kleuker

Beispiel (4/5) Testfälle nach einer Äquivalenzklassenanalyse und Grenzwertanalyse Anmerkung: Testfallanzahl erhöht sich meist Test-nummer 1 2 3 4 5 6 geprüfte Äquivalenzklassen Ä1 Ä4U Ä6 (Ä1) Ä4O Ä7 (Ä4) Ä8 Ä2 Ä3O Ä5U Name „Meier“ „Schmidt“ „Schulz“ „“ Geburtsjahr 1900 2000 1985 1988 1899 2001 Fachbereich FBING FBBWL FBPOL Ergebnis ok Abbruch Stephan Kleuker

Beispiel (5/5) mögliche Übersetzung nach JUnit (Ausschnitt)
public class ImmatrikulationTest { ... @Test public void test1(){ try{ new Immatrikulation("Meier",1900,Bereich.FBING); }catch(ImmatrikulationsException e){ fail("falsche Exception"); } public void test4(){ new Immatrikulation("",1988,Bereich.FBING); fail("fehlende Exception"); Stephan Kleuker

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 Stephan Kleuker

public class MaxiTest { public MaxiTest(String arg0) { super(arg0); } @Test public void testErstesMax(){ assertTrue("Maximum an erster Stelle", 7==Maxi.max(7,5,4)); public void testZweitesMax(){ assertTrue("Maximum an zweiter Stelle", 7==Maxi.max(5,7,4)); public void testDrittesMax(){ assertTrue("Maximum an dritter Stelle", 7==Maxi.max(4,5,7)); Alle Tests laufen erfolgreich, allerdings war die Klassenbildung zu ungenau, nächster Versuch mit den Klassen: x>=y>=z x>=z>=y z>=x>=y z>=y>=x y>=x>=z y>=z>=x [Frage: sind dies Äquivalenzklassen ??] Stephan Kleuker

sechs Testfälle, Ausschnitt: @Test 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));} Fall X>=Z>=Y offenbart, dass das Verfahren nicht funktioniert Allerdings ist die Äquivalenzklassenwahl nicht sauber Stephan Kleuker

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 Stephan Kleuker

Ä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 Stephan Kleuker

Ä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. Stephan Kleuker

public class Zuverlaessigkeit { // zu testen private Bezahlstatus status; public void setStatus(Bezahlstatus status){ this.status = status; } public boolean einkaufssummePruefen(int wert){ switch(this.status){ case GEPRUEFT:{ return true; case STANDARD:{ return wert < 500; return false; Stephan Kleuker

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) Stephan Kleuker

public class ZuverlaessigkeitTest extends { private Zuverlaessigkeit zvl; @Before protected void setUp() throws Exception { zvl = new Zuverlaessigkeit(); } @Test public void testGeprueft1(){ zvl.setStatus(Bezahlstatus.GEPRUEFT); assertTrue(zvl.einkaufssummePruefen(499)); public void testGeprueft2(){ assertTrue(zvl.einkaufssummePruefen(500)); Stephan Kleuker

@Test public void testKritisch1(){ zvl.setStatus(Bezahlstatus.KRITISCH); assertTrue(!zvl.einkaufssummePruefen(499)); } public void testKritisch2(){ assertTrue(!zvl.einkaufssummePruefen(500)); public void testStandard1(){ zvl.setStatus(Bezahlstatus.STANDARD); assertTrue(zvl.einkaufssummePruefen(499)); public void testStandard2(){ Stephan Kleuker

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) Stephan Kleuker

Beispiel: KFG 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 Stephan Kleuker

Normalisierung eines KFG durch Blockung
folgende Regeln, mit denen mehrere Knoten k1,k2,...,kn, die nacheinander durchlaufen werden können, also k1k2...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). Stephan Kleuker

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, ..., Mehrfach-Bedingungsüberdeckungstest) für die Menge der vollständigen Pfade bei Auswahl der Testdurchläufe wählen Stephan Kleuker

Anweisungsüberdeckung (C0)
Ziel: alle Anweisungen des Programms durch Wahl geeigneter Testdaten mindestens einmal ausführen, alle Knoten des KFG mindestens einmal besuchen. Testmaß Ziel: C0=1 (=100%) für {-1} C0= /6 für {-1,0} für {-1,2} C0= /6 Anzahl der ausgeführten Knoten |V| C0= C0= / / / /6 Stephan Kleuker

Anzahl der durchlaufenen Kanten
Zweigüberdeckung (C1) Ziel :alle Kanten des KFG überdecken, d.h. alle Zweige des Programms einmal durchlaufen Testmaß Ziel: C1=1 für {-1} C1= /7 für {-1,0} C1= /7 für {-1,2} C1= /7 Anzahl der durchlaufenen Kanten |E| C1= C1= / / / /7 Stephan Kleuker

Kommentare zur Anweisungs- und Zweigüberdeckung
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 Stephan Kleuker

Einfache Bedingungsüberdeckung
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 Stephan Kleuker

Einfache Bedingungsüberdeckung (C2)
Ziel: alle atomaren Prädikate einmal TRUE, einmal FALSE Testmaß: |alle Atome| =Anzahl aller Atome, |wahre Atome|= Anzahl aller Atome, die mit true ausgewertet werden (analog | falsche Atome|) |wahre Atome| + |falsche Atome| 2 * |alle Atome| C2= Testfälle {-1} {0} {1} {2} {-1,0} {0,1} {1,2} {-1,1} {-1,1,2} i>0 f f,t ein<0 t t,f ein%2==1 - C2-Über-deckung 2/6 3/6 4/6 5/6 6/6 Stephan Kleuker

Kein Zusammenhang zwischen C1 und C2
Die Nummerierung C1, C2 ist historisch gewachsen betrachte if (a || b) a=true, b=false a=false, b=true garantiert vollständige einfache Bedingungsüberdeckung (C2) else-Zweig wird nicht durchlaufen, keine Zweig- oder Anweisungsüberdeckung (C1, C0) a=true, b=false a=false, b=false if- und else-Zweig wird durchlaufen, damit Zweig- und Anweisungsüberdeckung keine vollständige einfache Bedingungsüberdeckung, da b=true fehlt Stephan Kleuker

Minimale Mehrfachbedingungsüberdeckung (C3)
Ziel: alle Prädikate und Teil-Prädikate einmal TRUE, einmal FALSE Testmaß: |wahre Teilprädikate| + |falsche Teilprädikate| 2 * |alle Teilprädikate| C3= Testfälle {-1} {0} {1} {2} {-1,0} {0,1} {1,2} {-1,1} {-1,1,2} i>0 f f,t ein<0 t t,f ein%2==1 - ein<0 || ein%2==1 C3-Über-deckung 3/8 4/8 5/8 6/8 7/8 8/8 Stephan Kleuker

Zusammenhang zwischen den Testverfahren
Anmerkung: Diese Thema kann noch wesentlich vertieft werden Minimaler Mehrfachbedingungs- überdeckungstest (C3) Einfacher Bedingungs- überdeckungstest (C2) Zweigüberdeckungstest (C1) Anweisungsüberdeckungstest (C0) vollständige Überdeckung des einen bedeutet vollständige Überdeckung des anderen Stephan Kleuker

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 Stephan Kleuker

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: DO-178B Level C: Stephan Kleuker

Teststufen (grober Ablauf)
11.7 Klassentest Integrationstest entwicklungs- intern Systemtest entwicklungs- extern (mit Kunden) Abnahmetest Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

Testansätze zusammengefasst
White-Box-Test Gray-Box-Test Black-Box-Test Anwei- sungen Paket/ Komponente Entschei- dungen Eingaben Pfade Schnittstellen System Ausgaben Methoden-/Klassentest Integrationstest Systemtest Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

Prinzip des Regressionstests
Software Version n Testfallspezifikation Version n Test Testarchivierung der Iteration n Referenz- testfälle Testfall- ergebnisse Software Version n+1 Regressionstest Testfalldatenbank Vergleich der Testergebnisse Stephan Kleuker

Regressionstests im Entwicklungszyklus
Testfallentwicklung erste Entwicklung Version 1 Test Testfallentwicklung Weiterentwicklung Regressionstestfälle Test Version 2 Testfallentwicklung Weiterentwicklung Regressionstestfälle Test Version n Stephan Kleuker

Änderungen an bereits freigegebenen Modulen sind notwendig
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 Stephan Kleuker

Änderungstest vom Entwickler, er schreibt die Testfälle fort.
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 Stephan Kleuker

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) Stephan Kleuker

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 Stephan Kleuker

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) Stephan Kleuker

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 freies Werkzeug: JMeter: (besonders interessant für Lasttests von Web-Servern und Datenbankzugriffen) Stephan Kleuker

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 ( Stephan Kleuker

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 Stephan Kleuker

Metriken zur Ermittlung des Projektstands
11.8 programmiert/ überdeckt 100% 50% 0% Use Cases Pakete C1-Über- deckung C2-Über- deckung Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

Beispiele für die zyklomatische Zahl
Anzahl Kanten Knoten McCabe Zahl Stephan Kleuker

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) Stephan Kleuker

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? Stephan Kleuker

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){ b=b-x; public void mach3(int x){ c=c+x; nutzt(a)=3 nutzt(b)=2 nutzt(c)=1 avgNutzt=6/3=2 LCOM*= (2-3) /(1-3) = -1/-2= 0.5 für Eclipse gibt es Plugin Metrics berechnet u. A. erweiterte MCCabe-Zahl und LCOM* Stephan Kleuker

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 Stephan Kleuker

z. B. Eclipse-Erweiterung Checkstyle Generell gibt es Regeln
Coding Guidelines Detailliertes Beispiel: Taligent-Regeln für C++ ( 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äfix-Regeln), zum Aufbau eines Programms (am schwierigsten zu formulieren, da die Programmarchitektur betroffen ist und es nicht für alle Aspekte „die OO-Regeln“ gibt) Stephan Kleuker

Beispiel-Coding-Regel
Ausschnitt aus „Java Code Conventions“, Sun, 1997 Inhalt soll sich nicht nur auf Formatierung beziehen Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

Inspektionsablauf (1/3)
Stephan Kleuker

Stephan Kleuker

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 Stephan Kleuker

weitere manuelle Prüfmethoden (2/2)
Walkthrough ist abgeschwächte Form des Reviews Autor leitet als Moderator die Walkthrough-Sitzung 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 Probleme werden protokolliert Walkthrough-Variante besteht darin, vor der Sitzung eine individuelle Vorbereitung durchzuführen Stephan Kleuker

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«) Stephan Kleuker

12. Umfeld der Software-Entwicklung
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 Stephan Kleuker

Typischer Weg der Software-Entwicklung
12.1 Stephan Kleuker

Software-Versionen Software entwickelt sich inkrementell, bei Versuchen muss der Weg zurück möglich sein Versionsbaum Paket 1 Paket 2 Paket 3 V 1 V 1 V 1 Inkrement 1 V 2 V 2 V 2 V 5 V 4 V 3 V 3 V 3 Inkrement 2 V 6 V 6 V 5 V 4 V 4 V 7 V 5 Stephan Kleuker

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) Stephan Kleuker

Konflikt bei gemeinsamer Bearbeitung
Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

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 Installa-tionsroutine, bei der u. a. Pfade gelesen und bearbeitet werden Stephan Kleuker

Ant-Files können betriebssystemunabhängig formuliert werden
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 Stephan Kleuker

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 Stephan Kleuker

gcc -o prog file1.o file2.o file3.o file1.o : file1.c
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 Stephan Kleuker

Beispiel für Abhängigkeiten
<target name="init"/> <target name="preprocess" depends="init"/> <target name="compile" depends="init,preprocess"/> <target 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 Stephan Kleuker

Ant-Basisskript (erzeugt von Eclipse)
<?xml version="1.0"?>  <project name="project" default="default"> <description> description </description>  <target name="default" depends="depends" description="--> description"> </target> <! target: depends > <target name="depends"> </project> Stephan Kleuker

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} Stephan Kleuker

Beispiel-Task: Kompilieren
 <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 Stephan Kleuker

Beispiel-Task: Packen
 <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 Stephan Kleuker

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 = [echo] TSTAMP = 1234 [echo] TODAY = 09.Februar.2008 Stephan Kleuker

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> Stephan Kleuker

Aufgaben des Konfigurationsmanagements (1/3)
Build- Management Release- Management Versions- management Änderungs- management Prozess- Unterstützung Stephan Kleuker

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 Software-Versionen) Rückruf gelieferter Software Stephan Kleuker

Ä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 Stephan Kleuker

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 Stephan Kleuker

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) Stephan Kleuker

Festlegung der Arbeitspakete
Zerlegung in sogenannter Work-Breakdown-Structure (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) Stephan Kleuker

Beispiel für WBS PT = Personentage
Es muss deutlich sein, wo welches Produkt zugehört (hier z. B. Dokumentation querschnittlich bei allen) Stephan Kleuker

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) Stephan Kleuker

Netzplan und kritische Pfade
Abhängigkeiten und Aufwände können als Graph dargestellt werden P2 4 6 Paket min max. Dauer Dauer P1 3 7 P5 5 7 P3 2 5 P4 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 Stephan Kleuker

Einflüsse der Projektplanung
Stephan Kleuker

Erster Projektplan (1/2)
Stephan Kleuker

Erster Projektplan (2/2)
Stephan Kleuker

Sachstandsanalyse Ressourcenverbauch (Abweichung) zu langsam
Verbrauch ok (zu) schnell (zu) effizient -50% zu langsam Verbrauch nicht ok Fertigstellungsgrad (Abweichung) -50% +50% (zu) schnell Verbrauch ok Desaster! 50% (zu) schnell Verbrauch nicht ok Stephan Kleuker

Meilensteintrendanalyse zur erwarteten Fertigstellung
Stephan Kleuker

Burndown-Chart zur erwarteten Fertigstellung (Scrum)
Stephan Kleuker

wie viel wird vom Kunden verlangt? Gewinnmaximierung vs. Ölfleck
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 Stephan Kleuker

Aufwandsbestimmung am Anfang des Projekts
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) Stephan Kleuker

Zusammenfassung der Function Point Analyse
funktionale Anforderungen Projekteinflüsse Einflussfaktoren gewichtete Function-Points Aufwand Personenmonate Schätzung Berechnung Ableitung ungewichtete Function-Points Stephan Kleuker

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 Stephan Kleuker

Function-Point-Methode (2/4)
Kategorie Anzahl Klassifizierung Gewichtung Zeilensumme Eingabedaten 6 einfach * 3 18 4 mittel * 4 16 komplex * 6 Abfragen 12 Ausgaben 24 9 * 5 45 * 7 Datenbestände 7 49 * 10 * 15 Referenzdaten Summe ungewichteten Function-Points 164 Stephan Kleuker

Summe unbewertete Function-Points 164 Verflechtung mit anderen Anwendungssystemen (0-5) 1 Dezentrale Daten, dezentrale Verarbeitung (0-5) 2 Transaktionsrate (0-5) Verarbeitungslogik Rechenoperationen (0-10) Kontrollverfahren (0-5) 3 Ausnahmeregelungen (0-10) Logik (0-5) Wiederverwendbarkeit (0-5) Datenbestandskonvertierungen (0-5) Anpassbarkeit (0-5) Summe der Einflussfaktoren (EF) 17 Faktor Einflussbewertung (FE) = EF / ,7 0,87 Gewichtete Function-Points = ungewichtete Functionpoints *FE 143 Stephan Kleuker

Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

Variable E B hat Standardwert 0.91 (1999)
Dazu kommen fünf Scaling Factors: Sehr gering Ge-ring Nor-mal Hoch Sehr hoch Extra hoch Geschäftstätigkeit im Produktbereich 6.20 4.96 3.72 2.48 1.24 Entwicklungsfreiräume 5.07 4.05 3.04 2.03 1.01 Ausgereiftheit des Produktentwurfs 7.07 5.65 4.24 2.83 1.41 Einvernehmen zwischen Stakeholdern 5.48 4.38 3.29 2.19 1.10 Software-Prozessreife (nach SEI-CMM[I]) 7.80 6.24 4.68 3.12 1.56 PREC FLEX RESL TEAM PMAT Stephan Kleuker

Kostentreiber EM (Early Design)
Einflussfaktor Extra gering Sehr gering Ge-ring Nor-mal Hoch Sehr hoch Extra hoch Produktzuverlässigkeit und -Komplexität 0.73 0.81 0.98 1 1.30 1.74 2.38 Angestrebte Wiederverwendbarkeit 0.95 1.07 1.15 1.24 Zielplattformbesonderheiten 0.87 1.29 1.81 2.61 Personalfähigkeit 2.12 1.62 1.26 0.83 0.63 0.50 Personalerfahrung 1.59 1.33 1.12 0.71 0.62 Qualität der Entwick-lungsbedingungen 1.43 1.10 Entwicklungszeit-rahmen 1.14 Stephan Kleuker

CoCoMo im Überblick Abschätzung der Systemgröße (KDSI) Abschätzung für
CoCoMo II Abschätzung für Entwicklungs- und Wartungskosten für verschiedene Entwicklungsphasen Produkt-, Prozess-, Plattform- und Personal-Attribute Wiederverwertbarkeits- und Wartbarkeitsparameter Daten bereits abgeschlossener Projekte Iterative Aktualisierung Kalibrierung auf eigene Organisation Stephan Kleuker

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 Stephan Kleuker

Vorbereitung der Schätzung
Projekt in dokumentierte Komponenten /SW-Einheiten / Use Cases zerlegt vergleichbares Projekt liegt mit Aufwandsdaten und vergleichbarer Komponentenstruktur vor Stephan Kleuker

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 Stephan Kleuker

Aufbau des Schätzansatzes
Vorbereitung der Schätzung Durchführung der Schätzung Analogieschluss Stephan Kleuker

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 ...“) Stephan Kleuker

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 Stephan Kleuker

A: Wiederverwendung 1 Komponente besteht rein aus der Wiederverwendung bereits existierender Ergebnisse, die nur neu zusammengesetzt werden müssen 1,3 Hoher Grad der Wiederverwendung, es müssen nur Anpassungen an relativ leicht zu identifizierenden Stellen vorgenommen werden 1,6 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 1,9 Einige Teile können wiederverwendet werden, grundlegende Designideen sind übernehmbar 3 Neuentwicklung, bzw. alle existierenden Ergebnisse müssen intensiv überprüft werden Hinweis: Wiederverwendung kann sich auf selbst erstellte Software, Freeware oder gekaufte SW beziehen Stephan Kleuker

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 hochkomplex Hinweis: Funktionalität bezieht sich nur auf die Komplexität der neu zu erstellenden SW (also B=0, wenn nichts gemacht werden muss) Stephan Kleuker

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 Stephan Kleuker

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) Stephan Kleuker

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 Stephan Kleuker

Analogie-Schätzung: Durchführung
1. Gemeinsame Schätzung einer neuen Beispielteilaufgabe (evtl. mehrere) 3. Individuelle Schätzung des Altprojekts (Aufwand in Personen-tagen, PT, bekannt), mit Konsoli-dierung durch Schätzkonferenz Teilaufgabe A B C D ABCD Neu1 1.9 5 2 38 Teilaufgabe PT A B C D ABCD Alt1 188 3 5 2 60 Alt2 62 1.9 1 19 Alt3 149 6 1.5 54 Alt4 18 Summe 453 151 2. Individuelle Schätzung mit Konsolidierung durch Schätzkonferenz Teilaufgabe A B C D ABCD Neu1 1.9 5 2 38 Neu2 3 4 1.5 32 Neu3 6 1 27 Neu4 36 Neu5 1.6 16 4. Berechnung des Wertes eines Aufwandspunktes 453/151 = 3 Stephan Kleuker

Analogie-Schätzung: Analogieschluss
5. Bestimmung des Aufwandes in PT des neuen Projekts mit Analogieschluss Teilaufgabe A B C D ABCD Aufwand Neu1 1.9 5 2 38 114 Neu2 3 4 1.5 32 96 Neu3 6 1 27 81 Neu4 36 108 Neu5 1.6 16 48 Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

Variante Planning Poker
statt Schätzung von ABCD wird nur mit einer jeweils verdeckt aufgelegten Karte geschätzt ? = keine Ahnung, ∞ = gibt zu wenig Informationen höchster und niedrigster Wert werden diskutiert solange wiederholen, bis konsolidiert wieder Analogieschluss mit vorherigen Projekten oder bei Sprints mit vorherigen Sprints Stephan Kleuker

Teufelsquadrat für IT-Projekte nach Sneed
12.5 Qualität Kosten Funktionalität 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) Stephan Kleuker

Definition Qualitätsmanagement (eine Variante)
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) Stephan Kleuker

Zusammenhang der Q-Begriffe
Qualitätsmanagement (Qualität aller Prozesse) Prozess X Prozess Y Software-Entwicklungsprozess konstruktiv analytisch Qualitätssicherung Stephan Kleuker

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-Entwicklungs- prozesse ermitteln gezielte Prozessverbesserung CMM(I) definiert 5 Stufen der Reife einer Organisation 5 Optimizing 4 Quantitatively Managed Managed (CMM) 3 Defined 2 Managed Repeatable (CMM) 1 Initial aktuell: CMMI for Development, Version 1.2 (CMMI-DEV) Stephan Kleuker

Merkmal: Keine stabile Umgebung, ad-hoc Durchführung
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 Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

Überblick: Verbesserungen mit dem CMMI
es gibt schönere Bilder mit besser platzierten Uhren Stephan Kleuker

Skizze einer CMMI-Anpassung
alter Firmen- standard nach CMMI-Überarbeitung fehlen: Produkte, Verantwortlichkeiten SP 1.1 des CMMI Stephan Kleuker

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 Defekte erfassen und analysieren PSP 0 Arbeiten planen Aufwände schätzen, Zeitpläne erstellen Optimierungen analysieren PSP 1 Qualitätsmanagement Erstellung von Qualitätsplänen Messung eigener Qualität PSP 2 Entwickler mit garantierter Qualität und Schätzfähigkeit Stephan Kleuker

Ganzheitliche Projektsicht
12.6 Arbeitsumfeld [schwarz] Fähigkeiten (Know how) [blau] soziale Ebene [rot] Prozessebene [grün] Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

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 ... Stephan Kleuker

Kommunikation Paul Watzlawik: „Man kann nicht nicht kommunizieren“
Versuch, eine gemeinsame Informationsbasis zu finden abhängig vom gemeinsamen Verständnis 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 Sender Empfänger Deco- dierung Feedback Co- dierung Nachricht Co- dierung Deco- dierung Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

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 Stephan Kleuker

Teufelskreis „Führung“ [SRS03]
Kommunikationsproblem: „Verstärkung der Ansichten und negativen Empfindungen“ machen: planen ihre Entscheidungen am „grünen Tisch“, tun seltene Kritik ab „höre ich selten, andere schaffen es auch“ Führungskräfte fühlen: Bestätigung, dass der Kurs stimmt fühlen: Druck, Angst vor Positions- verlust machen: schweigen, dulden, antworten, auf Nachfragen „Läuft alles soweit gut“ Mitarbeiter Stephan Kleuker

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 Stephan Kleuker

Grundkurs Software-Engineering mit UML

Ähnliche Präsentationen

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

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Grundkurs Software-Engineering mit UML

Ähnliche Präsentationen

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

Ähnliche Präsentationen

Über Projekt

Feedback