Objektorientiertes Software-Engineering

Transkript

1 Objektorientiertes Software-Engineering Vorlesung I Inhalt der 1. Vorlesung (SE-Prozess) Strukturierte Analyse / Strukturiertes Design () Datenorientierte Software-Entwicklung () Prozesse für Objektorientierte Softwareentwicklung Rational Unified Process (RUP) Extreme Programming (XP) Weitere Vorgehensmodelle Anhang:, Grundlage und weiterführend Folie 2

2 Folie 3 Themen e Objektorientierte Software-Entwicklung UML Design Patterns Basisliteratur siehe abschnitt Technisches 12 Vorlesungen à 3 Stunden ( bis ) zusätzlich: 1 Stunde Übung - freie Termine Termin: Freitags 13:30-16:00 Uhr ACHTUNG: Zusatztermin am Uhr Tiefenhörsaal, Jägerstr. 56/58 Testat - Prüfung im vorletzten Vorlesungstermin Referent: DaimlerChrysler AG EP/QIM Tel. (07031) oder (0711) Uwe.Guehl@DaimlerChrysler.com Was ist ein? Folie 4 Zergliederung der Entwicklungstätigkeit in Teilprozesse und Aktivitäten I Aktivitäten haben definierte Eingangsvoraussetzungen: R eingetretene Ereignisse, Dokumente, Zeitpunkte Aktivitäten haben definierte Ergebnisse: Dokumente, Meilensteine, Auslöser für andere Aktivitäten Rollen sind Definitionen von Verantwortlichkeiten, Kompetenzen und erforderlichen Fähigkeiten (Beispiel: Architekt). Personen werden Rollen zugeordnet Zu Aktivitäten sind Rollen zugeordnet A O

3 Elemente von en Klassische Schritte der Software-Entwicklung Analyse Design Implementierung Weiterer Umfang im Rahmen des Software Life Cycle Dokumentation Test Wartung Anfangs nicht erwähnt wurden Erfahrung sammeln Design- und Implementierungsanalyse Projektmanagement Folie 5 Fortschritt in Softwareentwicklungsprozessen Paradigmenwechsel Software-Entwicklung in einem iterativen und inkrementellen Prozess Phasen nicht mehr streng getrennt, sondern fließen ineinander über Konzept des Roundtrip Engineering Fokus weg von Anwendungen und Anwendungsorganisation hin zur Datenmodellierung und Umgang mit Daten Ursache ist die unterschiedliche Lebensdauer der Hard- und Systemware 2 bis 4 Jahre Anwendungen 3 bis 6 Jahre Modelle 1 bis 30 Jahre (nach [Hel94, S. 180]) Folie 6

4 Wozu Softwareentwicklungsprozesse? Wozu Modelle? Ein Modell soll Fragen zu einem System beantworten können,ohne mit dem System selbst arbeiten zu müssen. Ein gutes Modell beantwortet eben diese Fragen Folie 7 Warum? Qualität von Software ist entscheidend abhängig von der Qualität und Produktivität des zugrunde liegenden Software- Entwicklungsprozesses! Qualität des es DIN EN ISO 9000 Teil 3 : Geschichte der Abstraktion Folie 8 von Spannungen und Strömen: die Programmiersprache von Befehl und Datum: die von-neumann-maschine von einzelnen Bits: Oktal- und Hexadezimalcode von Befehlscodes: Operatorsymbole von Speicheradressen: Bezeichner von Maschinenoperationen: Ausdrücke von Berechnungsvorschriften und Daten: Funktionen von Befehlssequenzen: Prozeduren von speziellen Operationen: Funktions-/Prozedur- Parameter von verschiedenen Merkmalen: Generische Einheiten von der Datenimplementierung: Kapselung von einer Typimplementierung: Abstrakte Datentypen (ADT) von ähnlichen Operationen: Overloading von ähnlichen Typen: Vererbung

5 Strukturierte Analyse / Strukturiertes Design (1) Ursache: Softwarekrise Ende der 1960er / Anfang 1970er Jahre. Die Software hielt mit steigenden Leistungsmerkmalen der Hardware nicht mehr mit wurde mit höheren Anforderungen und Erweiterungen komplexer, fehleranfälliger und unüberschaubarer wurde immer teurer, aufgrund des hohen manuellen Programmieraufwands (niedriger Automatisierungsgrad - keine Software Reuseability) Ziel: Weg von der unkoordinierten unstrukturierten Programmentwicklung hin zum Software Engineering [KKST79] Folie 9 Strukturierte Analyse / Strukturiertes Design (2) Entwicklung der Strukturierten Analyse (SA) und des Strukturierten Design (SD), zusammengefasst Hauptmerkmale Modulares Programmieren Prozedurale Programmierung Bestimmung notwendiger Prozeduren mit bestgeeigneten Algorithmen Modulares Programmieren mit Verbergen der Daten in Modulen Datenabstraktion... hilft, Funktionalitäten allgemein zu realisieren, die prinzipiell gleichartig mit unterschiedlichen Daten arbeiten Für jeden Datentyp wird eine Menge von Operationen unterstützt Folie 10

6 Strukturierte Analyse / Strukturiertes Design (3) Structured Analysis (SA) von DeMarco, McMenamin und Palmer [DeM78] erfasst Anforderungen an die Implementierung Umfang: Flussdiagramme Data Dictionary Prozess-Spezifikationen Erfassung dynamischen Verhaltens mit Verhaltensdiagrammen Petrinetzen erweitert die SA zur SA/RT (SA for Realtime Systems) Darstellungsmethoden Structured Analysis Design Technique (SADT) IDEF0 (siehe [AK94a]) Folie 11 Strukturierte Analyse / Strukturiertes Design (4) Structured Design (SD) steht für die Implementierungsplanung, damit zwischen der technologieorientierten Analyse und der eigentlichen Realisierung Analyse der zugrundeliegenden Daten Erfassung des konzeptionellen Datenmodells in Strukturdiagrammen Modellierungssprache IDEF1X (siehe [AK94b]) Folie 12

7 Strukturierte Analyse / Strukturiertes Design (5) Vorgehensmodell: Das Wasserfallmodell von Royce [Roy70] PLAN CODE COMPONENT TEST SYSTEM TEST Folie 13 FIELD SUPPORT Strukturierte Analyse / Strukturiertes Design (6) Kritik: Brooks: Wasserfallmodell ist falsch [FPB95, S. 264ff.] Lineare Einwegrichtung von der Analyse zum Design zu idealisiert und inflexibel Später entdeckte Probleme führen zu lokalen Fixes ohne wesentliche Gesamtänderungen schwierig zu handhaben Unübersichtlichkeit Darstellungsbruch zwischen Analyse und Design Folie 14

8 Datenorientierte Software-Entwicklung (1) Datenorientierte Software-Entwicklung üblich bei Datenbankanwendungen: Verwendete Daten im Vordergrund Weniger wichtig: Prozedurale Techniken, wie mit diesen Daten umgegangen werden soll Weitere Bereiche der datenorientierten Software-Entwicklung: Konvertierungs-Prozessoren EDM-Systeme (EDM = Engineering Data Management) Integrationsarchitekturen Folie 15 Datenorientierte Software-Entwicklung (2) Externes Schema Konzeptionelles Schema Internes Schema Sicht der Einzelanwendungen auf die Daten Anwendungsübergreifende logische allgemeine Datenstruktur Beschreibung der technischen Realisierung Folie 16 3-Schema-Architekturvorschlag der ANSI-SPARC (American National Standards Institute - Standard Planning and Requirement Committee)

9 Datenorientierte Software-Entwicklung (3) Modellierung üblicherweise mit dem Entity-Relationship-Model (ERM) nach Chen [Che76] Basiselemente sind Entitäten als Objekte der realen Welt Beziehungen zwischen den Entitäten Darstellungsmittel sind Entity-Relationship-Diagramme Rechtecke für Entitäten Linien zwischen den Entitäten für Beziehungen Ellipsen für Beziehungs-Attribute Folie 17 Datenorientierte Software-Entwicklung (4) Übliches Vorgehensmodell [Moe98] Anforderungsanalyse Informationserfassung Welche Daten werden benötigt? Informationsverarbeitung Wie werden Daten verarbeitet? Konzeptioneller Entwurf Erfassen der Gegenstandstypen, Beziehungen und Attribute Semantisches Modell Folie 18

10 Datenorientierte Software-Entwicklung (5) Kritik: Semantik des Entity-Relationship-Models reicht für komplexe Anwendungen nicht aus Darstellung dynamischen Verhaltens nicht möglich Weiterentwicklung zum EER-Model (Extended Entity- Relationship-Model) mit Ober- und Unterklassen Vererbungshierarchien Entwicklung von objektorientierten und objektrelationalen Datenbanken Verhalten und Dynamik sind nicht darstellbar Resümee: Relationaler Ansatz reicht für die Datenverwaltung nicht immer aus. Folie 19 Objektorientierte Analyse und Design (1) In den 1980er Jahren: Entwicklung weg von Prozessorientierung hin zur Objektorientierung (OO) Entwicklung weg vom Wasserfallmodell hin zu iterativ inkrementellen Phasenmodellen Objektorientierte Software-Entwicklung (OOSE) umfasst: Objektorientierte Analyse (OOA) Erfassen der Aufgabenstellung aus Sicht des Anwenders Objektorientiertes Design (OOD) Strukturierung des Gesamtsystems und der Klassen Objektorientierte Programmierung (OOP) Umsetzung mit geeigneter Programmiersprache Folie 20 Ab Anfang der 1990er Jahre: Idee für Formalisierung der OOA und OOD; bis dahin Forschung in OO-Programmiersprachen-Entwicklung Verwendung der im Softwareentwurf

11 Objektorientierte Analyse und Design (2) Folie 21 Wichtigste Ansätze: Objektorientiertes Design (OOD) von Booch - auf kommerzielle Anwendungen ausgerichtet Object Modeling Technique (OMT) von Rumbaugh - an strukturierte Methoden angelehnt Object-Oriented Software-Engineering (OOSE) von Jacobson Objektorientierte Analyse (OOA) von Coad, Yourdon. In OMT, OOSE und der Booch-Methode waren Methode und Notation jeweils vereint. Vielfalt der objektorientierten Methoden und Notationen führte zur Zusammenarbeit von Rumbaugh und Booch, später stieß Jacobson hinzu 3 Amigos Die Versuche zur Vereinheitlichung schlossen zunächst Methode und Notation ein, erste Fassungen hießen noch UM für Unified Method. Objektorientierte Analyse und Design (3) Unter Federführung der Firma Rational entwickelten die 3 Amigos gemeinsam die Unified Modeling Language (UML): Grafische Sprache zur Beschreibung objektorientierter Modelle Einheitliche Notation - Die UML ist ausschließlich eine Sprache, eine Notation für die Analyse und das Design objektorientierter Systeme Standardisierung durch die OMG ( Keine Methode, kann aber Basis für Methoden sein Folie 22

12 Objektorientierte Analyse und Design (4) 1990 Methodenblüte 1995 Fraktionen und Allianzen OOSE Jacobsen 1997 Standardisierung Booch Booch UML Amigos UM 0.8 Booch/Rumbaugh UML 1.1 OMT Rumbaugh u.a. Fusion Coleman SOMA Graham Team Fusion Coleman u.a. Unified Process OOSA Shlaer/Mellor OOA Coad/Yourdon MOSES Henderson-Sellers OPEN/OML Open-Group 2000 UML 1.3 Folie /2004 UML 1.4 UML 2.0 Objektorientierte Analyse und Design (5): Vorgehensmodelle Rational Unified Process (RUP) extreme Programming (XP) V-Modell: Verbindlich in der Software-Entwicklung im wehrtechnischen Bereich und in der Bundesverwaltung mit Vorgehensmodell, Methodenzuordnung und funktionalen Werkzeuganforderungen Folie 24 Unternehmensinterne Vorgehensmodelle Interne Handbücher mit Vorgaben und Richtlinien zur Softwareentwicklung Ziel: Qualität und Verkürzung der Projektlaufzeiten

13 Objektorientierte Analyse und Design (6): Rational Unified Process (1) baut auf der UML auf ist ein inkrementeller und iterativer Entwicklungsprozess (von Jacobson, Booch und Rumbaugh 1999) basiert auf Phasen: Innerhalb jeder Phase können eine oder mehrere Iterationen stattfinden Iterationen: Innerhalb jeder Iteration finden die Aktivitäten in den Teilprozessen mit einer bestimmten Gewichtung statt Prozessen: Teilprozessen sind einzelne Workflows zugeordnet Folie 25 Objektorientierte Analyse und Design (7): Rational Unified Process (2) Teilprozesse Phasen Folie 26 Iterationen [Quelle: Rational Unified Process]

14 Objektorientierte Analyse und Design (8): RUP: Phasen (1) Die vier Phasen des Rational Unified Process: Inception (Konzeptphase) Umfang eines Projekts bestimmen Elaboration (Entwurfsphase) Projekt planen, Funktionen und Architektur festlegen Construction (Konstruktionsphase) Produkt erzeugen, Funktionsumfang ausbauen Transition (Übergangsphase) Produkt an den Anwender ausliefern. Folie 27 Objektorientierte Analyse und Design (8): RUP: Phasen (2) Inception Elaboration Construction Transition Aufwand Zeit ~ 5% 10% 20% 20%-40% 65% 40%-50% 10% 10% Tabelle 1: Typisches Verhältnis der Phasen zueinander Kurzes Projekt Typisches Projekt Komplexes Projekt Riskantes Projekt 3 Iterationen (0 I, 1 E, 1 C, 1 T) 6 Iterationen (1 I, 2 E, 2 C, 1 T) 9 Iterationen (1 I, 3 E, 3 C, 2 T) 10 Iterationen (2 I, 3 E, 3 C, 2 T) Tabelle 2: Typische Anhaltswerte für Iterationen pro Phase nach Art und Grösse des Projekts Folie 28

15 Objektorientierte Analyse und Design (9): RUP: Inception Phase Folie 29 Kleines Team (ca. 3-6 Personen), möglichst hohe Qualifikation Meilensteine der Inception Phase: Pläne Definition der Verantwortlichkeiten Grobplan aller Projektphasen (inkl. Iterationenplan) Detailplan für die Elaboration Phase Problembeschreibungen Baseline Vision Baseline Anforderungen und Use Case Modelle Lösungsbeschreibungen (Optional) Verwendbarkeit einer oder mehrere Architekturen demonstrieren Entwicklung/Kauf/Wiederverwendung-Abwägungen Erstes Designmodell Evaluierung Einverständnis der Projektbeteiligten und Anwender Anforderungen werden verstanden Glaubwürdigkeit der Abschätzungen, Risiken und des Prozesses Am Ende steht die "Go/No Go"-Entscheidung Objektorientierte Analyse und Design (10): RUP: Elaboration Phase Folie 30 Kleines Team (ca Personen) Meilensteine der Elaboration Phase: Pläne Detaillierter Construction Phase Plan Grobplanung der Transisition Phase Problembeschreibungen Stabile Vision und Anforderungen (ca. 90%) Evaluierungskriterien der Releases in der Construction Phase Skizzierung des Benutzerhandbuchs Lösungsbeschreibungen Stabiles Design-Modell Entwicklung/Kauf/Wiederverwendung Entscheidung Prototypen fr die kritischen Komponenten Evaluierung Stabilität der Produktvision und der Architektur Lösung der Risiken Hinreichender und glaubwürdiger Plan für die Construction Phase Finanzielle Zusage des Auftraggebers Wichtig: Überanalyse vermeiden ("Analysis Paralysis")!

16 Objektorientierte Analyse und Design (11): RUP: Construction Phase Folie 31 Je nach Projektgröße sollte man alle 2-3 Monate ("mittelgroß") oder 6-9 Monate ("komplexes Projekt") ein Release planen. Während dieser Phase erreicht der Personalstand sein Maximum Meilensteine der Construction Phase: Pläne Detaillierter der Transisition Phase Problembeschreibungen Akzeptanzkriterien für die Produktreleases Fertiggestelltes Benutzerhandbuch Lösungsbeschreibungen Stabile Implementierung Kritische Features und Basisfähigkeiten Objektive Einsicht in die Produktqualität Evaluierung Stabilität und Reife der Produkt-Releases Lösung der Risiken Vorbereitungen für die Übergabe des Systems an die Anwender Jedes Release liefert eine Rückmeldung an die Entwickler, einen Kontrollpunkt für das Management und eine Versicherung für die Kunden Objektorientierte Analyse und Design (12): RUP: Transition Phase Folie 32 Verkleinertes Team, inklusive Support-Mitarbeiter, technischer Autoren, Trainer,... U.u. werden mehrere Releases erzeugt (Beta, "offizielles Release", Bugfixes,...) Meilensteine der Transition Phase: Pläne Eventuell Produktpläne für das nächste Release (Marketing) Problembeschreibungen Endgültige Anwenderdokumentation Lösungsbeschreibungen Stabile Auslieferung "Alle" Features Bestmögliche Qualität Evaluierung Zufriedenheit der Anwender Tatsächliche Projektkosten zu geplanten Projektkosten Jedes Release liefert eine Rückmeldung an die Entwickler, einen Kontrollpunkt für das Management und eine Versicherung für die Kunden

17 Objektorientierte Analyse und Design (13): RUP: Iterationen Artefakte werden im Laufe des Projekts vervollständigt. Während jeder Phase können Artefakte aus allen Bereichen entstehen oder weiterentwickelt werden. Folie 33 [Quelle: Rational Unified Process] Objektorientierte Analyse und Design (14): RUP: Beispiel-Prozess Teilprozess Analysis and Design Ablauf beschränkt auf eine bestimmte Phase Start des Teilprozesses Analysis and Design Kontrollfluss Workflow Folie 34 Abschluss der Workflows innerhalb des Teilprozesses [Quelle: Rational Unified Process]

18 Objektorientierte Analyse und Design (15): RUP: Rollen, Aktivitäten und Artefakte Basiselemente des Workflows Rolle Werkzeuge für Aktivitäten Dokument ( Artifact ) Folie 35 Werkzeuge für Artefakte [Quelle: Rational Unified Process] Objektorientierte Analyse und Design (16): RUP: Beispiel Prozessdetails Workflow am Beispiel Design Components Abhängiger Workflow / Folge- Workflow Folie 36 [Quelle: Rational Unified Process]

19 Objektorientierte Analyse und Design (17): RUP: Beispiel Aktivität Activity am Beispiel Subsystem Design Folie 37 [Quelle: Rational Unified Process] Objektorientierte Analyse und Design (18): Rollen im RUP Folie 38 Beispiele für Rollen im Rational Unified Process: Analysts (Business-Process Analyst, Business Designer, Requirement Specifier, System Analyst,etc.) Developers (Software Architect, Capsule Designer, Database Designer, Design Reviewer, Designer, Implementor, etc.) Testers (Test Designer, Tester) Managers (Change Control Manager, Configuration Manager, Deployment Manager, Project Manager, etc.) Verantwortung und Autorität von Rollen müssen genau definiert sein Sinnvolles Werkzeug dazu ist die RACI-Matrix RACI = Responsible, Accountable, Consulted, Informed Den Rollen müssen Personen zugeordnet werden (m:n- Abbildung) Diese Zuweisung muss nicht statisch über das ganze Projekt gleich sein, eine Änderung ist zu Beginn jeder Projektphase möglich

20 Objektorientierte Analyse und Design (18): Rational Unified Process: Kritik Zwar hat sich der RUP als Standard-Vorgehensmodell etabliert, dennoch werden Kritikpunkte geäußert [Hes01]: Der RUP folgt noch immer dem Wasserfallmodell Der RUP ist nicht ausreichend architekturzentriert Die Iterationen sind an Phasen gekoppelt, nicht an Blöcken Unnötige Komplexität der RUP Workflows (heute: Disciplines) Die Mittel Hierarchie, Rekursion und Orthogonalität werden nicht eingesetzt Ungenügende Management-Unterstützung, zu schwaches Meilensteine-Konzept Mangelnde Unterstützung der unterschiedlichen Rollen, insbesondere der Anwender-Rolle Folie 39 Objektorientierte Analyse und Design (19): Kritik In der Durchführung von OO-Projekte ergeben sich auch Probleme [va96]: Keine Durchgängigkeit Großes Fehlerrisiko bei der Erhebung und Modellierung der Anwenderspezifikationen teures Redesign Scheitern missgestalteter Applikationen Wiederverwendbarkeit im großen Maßstab bisher gescheitert Frameworks haben sich als weniger erfolgreich herausgestellt, als erwartet: für Prototyping ungeeignet Einarbeitungszeit dauert oft zu lange Anpassungsaufwand für konkreten Projekteinsatz zu groß Flexibilität Komplexität Folie 40

21 Objektorientierte Analyse und Design (20): Extreme Programming: Grundwerte Extreme Programming (XP) wurde 1996 von Kent Beck entwickelt und basiert auf vier Grundwerten: Communication: Ständige Kommunikation zwischen Kunden und Entwicklern sowie unter den Entwicklern selbst Simplicity: Kontinuierliche Überarbeitung des Source-Codes mit dem Ziel alles Überflüssige zu vermeiden Feedback: Basierend auf User Stories viele kleine Releases, laufende Integration, kontinuierliches Testen Courage: Ehrlichkeit, was man kann und was nicht Folie 41 XP is the most important movement in our field today. I predict that it will be as essential to the present generation as the S.E.I. and its Capability Maturity Model were to the last. -- Tom DeMarco, Aus dem Vorwort von Planning Extreme Programming, 2001 Objektorientierte Analyse und Design (21): Extreme Programming: User Stories Anforderungen in XP werden durch sogenannte "User Stories abgehandelt. Der Kunde beschreibt alle Abläufe, die für die Lösung des Problems notwendig sind. Der Kunde kann während des Projekts neue User Stories ergänzen, entfernen und ändern, muss dies aber priorisieren. User Stories sind ein Versprechen für einen folgenden Dialog zwischen Kunde und Entwickler. Eine User Story passt normalerweise auf ein DIN A 5 Blatt. Folie 42

22 Objektorientierte Analyse und Design (22): Extreme Programming: 12 Praktiken (1) XP umfasst zwölf Praktiken, die sich gegenseitig unterstützen bzw.. verstärken: The Planning Game On-Site Customer Metaphor Small Releases Sustainable Pace Testing Simple Design Continuous Integration Pair Programming Collective Code Ownership Refactoring Das Planungsspiel ( Kunde ist anwesend) Coding Standards Am Beginn einer Iteration wird von Kunden PM und Entwicklern gemeinsam anhand der User Stories die Releaseplanung vorgenommen. Die Priorisierung der Stories erfolgt ausschließlich durch den Kunden, die Aufwandsschätzungen nur durch die Entwickler Folie 43 Kleine Releases Kurze Iterationszeiten werden eingehalten (+/- 4 Wochen) und die (Zwischen-)Releases werden dem Kunden zur Kontrolle und Feedback übergeben. Objektorientierte Analyse und Design (23): Extreme Programming: 12 Praktiken (2) Metapher Eine einfache "Story", wie das System grundsätzlich funktioniert. Die Metapher dient als Ersatz für die Architektur. Einfaches Design ( Refactoring) Design und Code sollen so einfach wie möglich gehalten werden Regelmäßig Codekontrollen durchführen und überflüssigen Code sofort entfernen Es wird nur implementiert, was direkt Auswirkung auf die Implementierung der aktuelle bearbeiteten User Story hat. Folie 44 Tests Die Entwickler schreiben (automatisch ausführbare) Unit- Tests bevor die eigentliche Funktionalität implementiert wird ("Test-First"-Ansatz) Der Kunde definiert parallel Abnahmetests

23 Objektorientierte Analyse und Design (24): Extreme Programming: 12 Praktiken (3) Refactoring ( Tests, Einfaches Design, Pair Programming) Wenn bei der Implementierung neuer Stories erkannt wird, dass die bisherige Implementierung geändert werden muss, so wird dies immer durchgeführt Die Unit-Tests sorgen dafür dass, der geänderte Code noch die gleiche Funktionalität implementiert. Kollektiver Codebesitz ( Pair Programming, Tests, Refactoring, Einfaches Design) Jeder hat das Recht, an jeder Stelle im Code Veränderungen vorzunehmen. Folie 45 Laufende Integration ( Tests) Immer wenn ein Teil der Implementierung (z.b. ein Story) fertig gestellt ist, wird dieser in das Gesamtsystem integriert. Vor der Integration müssen alle Tests durchlaufen, wenn während der Integration Fehler auftreten, muss die Ursache im neuen Code liegen. Nach der Integration müssen wieder alle Tests durchlaufen. Objektorientierte Analyse und Design (25): Extreme Programming: 12 Praktiken (4) Nachhaltige Entwicklung (war: 40-Stunden-Woche) Aufgrund der hohen Anforderungen beim Pair Programming kann bei XP-Projekten nicht (bzw. kaum) mit Überstunden gearbeitet werden. Pair Programming ( Nachhaltiges Arbeiten) Immer zwei Entwickler arbeiten zusammen an einem Arbeitsplatz (Kontinuierliches Codereview) Die Paare wechseln nach jeder Story, evtl. öfter, nach Bedarf Jede Codestelle wird somit von mindestens zwei Entwicklern gekannt. Kunde ist anwesend Der Kunde ist am Ort der Softwareentwicklung ständig anwesend (für Rückfragen, Stories, Tests) Folie 46 Programmierrichtlinien( Kollektiver Codebesitz, Pair Programming) Alle im Entwicklungsteam verpflichten sich, einen einheitlichen Codierungsstandard einzuhalten.

24 Objektorientierte Analyse und Design (26): Extreme Programming: Bewertung XP hat einige Voraussetzungen, die den Einsatz von "XP in Reinkultur" sehr erschweren können. Anwesenheit des Kunden Mangels entsprechend qualifizierter und verfügbarer Ressourcen beim Kunden kaum durchzusetzen. Planungsspiel Bestimmte Vertragsverhältnisse (z.b. Festpreisprojekt mit definiertem Umfang) macht den Einsatz von XP riskant bis unmöglich. Folie 47 Einige XP-Praktiken können aber auch im Rahmen anderer Entwicklungsprozesse sinnvoll angewandt werden. XP hat dem "Test-First"-Ansatz zum Durchbruch verholfen Kleine Releases und kontinuierliche (oder zumindest häufige) Integration haben sich auch in anderen Projekten bewährt. Pair Programming kann sehr effizient sein, kann aber auch ein Ressourcenverschwendung darstellen (abhängig von der Komplexität der Aufgaben und dem Verhalten der Entwickler) Refactoring wird zunehmend als notwendige Aktivität gesehen, um Projekte "gesund" zu halten. Weitere Vorgehensmodelle & Ausblick Evolutionäre objektorientierte Softwareentwicklung (EOS) [Hes01] Folie 48

25 Weitere Vorgehensmodelle & Ausblick Weitere Agile Prozesse: Scrum (Takeuchi / Nonaka, 1986; Schwaber / Beedle, 2002) Terminologie aus dem Rugby Bereich: Pregame Phase, Development Phase (Sprint), Postgame Phase Crystal-Prozessfamilie (Cockburn, 1998) Crystal Clear für kleine Projekte (bis ca. 6 Entwickler) Crystal Orange für mittelgroße Projekte (bis ca. 40 Entwickler) Feature Driven Development (FDD) (Coad et. al. 2000) Adaptive Software Development (Highsmith 2000) Folie 49 Weitere Vorgehensmodelle & Ausblick Weitere Vorgehensmodelle Springbrunnenmodell [Pil96] Aktivitäten können parallel verlaufen Eine hohe Iterationstiefe ist vorhanden Einzelne Phasen können sich überlappen Chaosmodell von Raccoon entworfen [Rac95] Flexibilität, innerhalb der einzelnen Schritte des SE- Prozesses bei Bedarf zu iterieren Open-Source-Software-Entwicklung Folie 50 Ausblick Neuere Entwicklungen wie die Komponentenorientierung werden zu neuen Vorgehensmodellen führen, die auf die grundlegenden Konzepte der objektorientierten Vorgehensmodelle aufbauen werden.

26 Zusammenfassung Wesentliches Merkmal aller Vorgehensmodelle: Abstrahieren der zu lösenden Probleme Es gibt Alternativen zum Wasserfallmodell mit strukturierter Analyse und Design Gemeinsamkeit aktueller Prozesse: Iterative Vorgehensweise Trend: Agile Prozesse (nur soviel Formalismus wie nötig) Folie 51 zur Vorlesung Karl Friedrich Gebhardt Objekt-orientiertes Software- Engineering, 2002, URL: Karl Friedrich Gebhardt UML - Unified Modeling Language, 2002, URL: Bernd Oestereich Objektorientierte Softwareentwicklung - Analyse und Design mit der Unified Modeling Language, 5. Auflage, Verlag Oldenbourg, 2001 URL: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns - Elements of Reusable Object-Oriented Software, 1995 Folie 52

27 Weiterführende Folie 53 [AK94a] Adelsberger, Heimo H. und Frank Körner: IDEF-0 Eine Methode zur Funktionsmodellierung. Wirtschaftsinformatik für Produktionsunternehmen, Universität GH Essen, URL: [AK94b] Adelsberger, Heimo H. und Frank Körner: IDEF-1X Eine Methode zur Datenmodellierung. Wirtschaftsinformatik für Produktionsunternehmen, Universität GH Essen, URL: [Che76] Chen, P. P.: The Entity-Relationship Model: Toward a Unified View of Data. ACM Trans. on Database Systems 1, Seiten 9 36, [DeM78] DeMarco, Tom: Structured Analysis and Systems Specification. Yourdon Press, New York, [FPB95] Frederick P. Brooks, Jr.: The Mythical Man-Month. Addison-Wesley, [JCJO92] Jacobsen, Ivar, Magnus Christerson, Patrik Jonsson und Gunnar Overgaard: Object-Oriented Software Engineering. A Use Case Driven Approach.Addison-Wesley, [Hel94] Hellmuth, Thomas W.: Datenmodellierung zur marktgerechten Führung der Produktionsbereiche. B. G. Teubner Stuttgart, [Hes01] Wolfgang Hesse: Dinosaur meets Archaeopteryx?Seven Theses on Rational's Unified Process (RUP), Proc. CAiSE'01/IFIP 8.1 Int. Workshop on Evaluation of Modeling Methods in System Analysis and Design (EMMSAD'01), Ch. VII, Interlaken 2001 [KKST79] Kimm, R., W. Koch, W. Simonsmeier und F. Tontsch: Einführung in Software Engineering. Walter de Gruyter & Co., Berlin, [Moe98] Moekotte, Guido: Objektbanken, Vorlesung Lehrstuhl für Praktische Informatik III, Universität Mannheim. [Pil96] PILLAI, K.: The Fountain Model and its Impact on Project Schedule. ACM SIGSOFT Software Notes, 21(2):32 38, March [Rac95] RACCOON, L. B. S.: The Chaos Model and the Chaos Life Cycle. ACM SIGSOFT Software Notes, 20(1):55 66, January [Rat] Rational Software Corporation: Rational Unified Process 5.5 [Roy70] Royce, Winston W.: Managing the Development of Large Software Systems: Concepts and Techniques. In: WESCON, Band 14, Seiten A/1 1 A/1 9, Western Electronic Show and Convention, Los Angeles, Aug , [va96] Ammon, Rainer von: Wiederverwendung in der kommerziellen Softwareentwicklung läßt auf sich warten. Computerzeitung, 27:10,