Arbeitsblatt: Vorgehensmodelle

Objektorientierter Softwareentwurf mit UML Inhalte: 9 Was ist unter einem Softwareentwicklungsprozess zu verstehen? 9 Wodurch unterscheiden sich Makro- und Mikro-Prozess? 9 Welche Vorgehensmodelle können gewählt werden? 9 Welche Phasen werden bei der OOP durchlaufen? 1 Objektorientierter Softwareentwurf mit UML Softwareentwicklungsprozess Die Einteilung in zwei Teilprozesse hat sich bewährt: Mikro – Prozess Makro – Prozess Der Mikro-Prozess wird über den Makro-Prozess gesteuert. Einhalten von Qualitätsanforderungen, Termintreue Der Makro-Prozess dient als Kontrollprozess. 2 Objektorientierter Softwareentwurf mit UML Mikro-Prozess Es werden in diesem Prozess folgende Aufgaben bearbeitet: erforderliche Klassen und Objekte werden identifiziert Sinn und Bedeutung (Semantik) der Objekte und Klassen werden identifiziert Beziehungen zwischen diesen Klassen und Objekten werden identifiziert Schnittstellen der Klassen und Implementierung der Klassen und Objekte werden spezifiziert 3 Objektorientierter Softwareentwurf mit UML Makro-Prozess Dieser Prozess erstellt eine Vielzahl von messbaren Ereignissen und Aktivitäten. Æ sinnvolle Risikoabschätzung Æ frühzeitige Korrekturmöglichkeit im Mikro-Prozess Er bildet die gesamte Entwicklungstätigkeit in Einheiten aus Wochen und Monaten ab. Ziel: Forderung nach zeitgemäßer Fertigstellung, Qualität, Vollständigkeit und Korrektheit des Produktes abzusichern. 4 Objektorientierter Softwareentwurf mit UML Makro-Prozess Folgende Aktivitäten kennzeichnen den Prozess: Festlegung der Kernanforderungen für die Software Festlegung des Konzeptes Entwicklung eines Modells für das gewünschte Verhalten des Systems (Analyse) Erstellung einer Architektur für die Implementierung (Entwurf) Realisierung des Fortschritts der Entwicklung durch schrittweise Verfeinerung (Evolution) Verwaltung der Entwicklung in der Wartungsphase 5 Objektorientierter Softwareentwurf mit UML Vorgehensmodelle Der Softwareentwicklungszyklus wird in Modellen dargestellt. Diese kategorisieren ihn nach: den Beziehungen zwischen den einzelnen Phasen der Anordnung der einzelnen Phasen der Art und dem Inhalt der einzelnen Phasen dem betrachtete Projektumfang 6 Objektorientierter Softwareentwurf mit UML Vorgehensmodelle Das Bild unterteilt sich in vier Bereiche: Rollenmodell, Vorgehensmodell, Methoden und Werkzeuge, Tätigkeitsbereiche. 7 Objektorientierter Softwareentwurf mit UML Vorgehensmodelle Das Vorgehensmodell definiert das Rollenmodell und gibt Methoden und Werkzeuge vor. 8 Objektorientierter Softwareentwurf mit UML Vorgehensmodelle Das Rollenmodell ist den Tätigkeitsbereichen zugeordnet. 9 Objektorientierter Softwareentwurf mit UML Vorgehensmodelle Das Vorgehensmodell definiert Regeln für die Tätigkeitsbereiche. 10 Objektorientierter Softwareentwurf mit UML Vorgehensmodelle Die Methoden und Werkzeuge unterstützen die Tätigkeitsbereiche. 11 Objektorientierter Softwareentwurf mit UML Das Wasserfallmodell Sequentieller Ablauf – lineares Modell Überprüfbare, vollständige Ergebnisse vor Start einer neuen Phase Werden Vorgaben/Ziele nicht erreicht, erfolgt Rücksprung in frühere Phase 12 Objektorientierter Softwareentwurf mit UML Das Wasserfallmodell Vorteile Nachteile • Modell mit geringem Aufwand • Änderungen mit hohem Aufwand • leicht verständlich • Unflexibel – strenge Sequenz • kein Risikomanagement • Probleme werden erst am Ende erkannt 13 Objektorientierter Softwareentwurf mit UML Durchführbarkeitskonzept Das V- Modell Betrieb Entstanden im Auftrage des Bundes und wurde eingeführt für Projekte öffentlicher Auftraggeber, aber auch in der Wirtschaft. 14 Objektorientierter Softwareentwurf mit UML Durchführbarkeitskonzept Das V- Modell Betrieb An der linken Seite stehen, abwärts angeordnet: Anforderungsdefinition, Grobentwurf, Feinentwurf und Modulimplementation. 15 Objektorientierter Softwareentwurf mit UML Durchführbarkeitskonzept Das V- Modell Betrieb Dem folgen ablauftechnisch an der rechten Seite aufwärts angeordnet: Modultest, Integrationstest, Systemtest und Abnahmetest. 16 Objektorientierter Softwareentwurf mit UML Durchführbarkeitskonzept Das V- Modell Betrieb Von der Anforderungsdefinition werden Anwendungsszenarien direkt an den Abnahmetest geleitet. 17 Objektorientierter Softwareentwurf mit UML Durchführbarkeitskonzept Das V- Modell Betrieb Vom Grobentwurf werden Testfälle direkt an den Systemtest gegeben. 18 Objektorientierter Softwareentwurf mit UML Durchführbarkeitskonzept Das V- Modell Betrieb Ebenso wie vom Feinentwurf zum Integrationstest und von der Modulimplementation zum Modultest. 19 Objektorientierter Softwareentwurf mit UML Durchführbarkeitskonzept Das V- Modell Betrieb Kommunikationsschritte können sowohl von der linken oberen Seite des V aus startend durchlaufen werden, als auch von der rechten oberen Seite. 20 Objektorientierter Softwareentwurf mit UML Das V- Modell Vorteile Nachteile • Gesamt-Modell • Vorgehensweisen sehr allgemein • für große Projekte geeignet • für kleine Projekte ungeeignet • betrachtet viele Aspekte • CASE Werkzeuge erforderlich • Qualitätssicherung steht im Vordergrund • kann angepasst/erweitert werden 21 Objektorientierter Softwareentwurf mit UML Prototyping (lauffähige, nicht voll funktionsfähige Modelle) Werden angewendet um folgende Ziele zu erreichen: klare Definition der Anforderungen Klärung möglichst aller offenen Fragen Einbeziehung der Auftraggeber und der Benutzer Überprüfung und Sicherung der Realisierbarkeit Aufzeigen verschiedener Lösungsmöglichkeiten 22 Objektorientierter Softwareentwurf mit UML Prototyping (lauffähige, nicht voll funktionsfähige Modelle) Arten von Prototypen: Demonstrationsprototyp Labormuster Pilotsystem (Kunden-Aquisitation) (Klärung technischer Fragen) (kann zum Produkt weiterentwickelt werden) 23 Objektorientierter Softwareentwurf mit UML Prototyping (lauffähige, nicht voll funktionsfähige Modelle) Man unterscheidet zwischen einem vertikalen und einem horizontalen Prototyp. Horizontal: vollständige Ebene mit eingeschränkter Funktionalität Vertikal: vollständige Funktionalität für ein Teilsystem 24 Objektorientierter Softwareentwurf mit UML Prototyping Vorteile Nachteile • Entwicklungsrisiko wird reduziert • hoher Entwicklungsaufwand • Lösungsalternativen aufzeigen • keine klare Abgrenzung, welchen Aufgaben ein Prototyp abdeckt • Auftraggeber sind eingebunden • Prototypen können in andere Vorgehensmodelle integriert werden 25 Objektorientierter Softwareentwurf mit UML Das Spiralmodell Kombination vom klassisch linearen Modell (Wasserfallmodell) und dem evolutionären Modell (Prototyping). Softwareentwicklung läuft in vier Schritten ab. Diese werden so lange wiederholt, bis das Softwareprodukt fertig gestellt ist. 26 Objektorientierter Softwareentwurf mit UML Das Spiralmodell (die vier Schritte) Definition von Zielen, Alternativen und Nebenbedingungen. Evaluieren der Ziele und Alternativen, Risiken erkennen und reduzieren. Entwickeln und überprüfen des Zwischenprodukts der Phase. Nächste Phase des Projekts planen. 27 Objektorientierter Softwareentwurf mit UML 1 2 3 4 28 Objektorientierter Softwareentwurf mit UML Das Spiralmodell (Schritt 1) Definition von Zielen, Alternativen und Nebenbedingungen. Zu Beginn jeder Phase (jeder neuen Windung der Spirale) werden inhaltliche Vorgaben für das Teilprodukt definiert. Es werden alternative Vorgehensweisen ausgearbeitet. Die Randbedingungen (z.B. Finanzen, Personal, Zeit) sind festzulegen. 29 Objektorientierter Softwareentwurf mit UML Das Spiralmodell (Schritt 2) Evaluieren der Ziele und Alternativen, Risiken erkennen und reduzieren. Zu Beginn des zweiten Schrittes werden die Alternativen unter Berücksichtigung der Ziele und Randbedingungen evaluiert. Risikofaktoren werden benannt und soweit wie möglich reduziert. Es können unterschiedliche Techniken verwendet werden (z.B. Entwicklung von Prototypen). Das Ergebnis sind die Prototypen P1, P2, 30 Objektorientierter Softwareentwurf mit UML Das Spiralmodell (Schritt 3) Entwickeln und überprüfen des Zwischenprodukts der Phase. Das Teilprodukt (z.B. einzelne Module oder in der letzten Phase die komplette Software) wird unter Einhaltung des Ziels unter geplanten Ressourcen realisiert und getestet. Die Methode für die Realisierung kann flexibel unter Beachtung des Restrisikos gewählt werden. Ergebnis dieses Schrittes sind beispielsweise die fertig getesteten Module. 31 Objektorientierter Softwareentwurf mit UML Das Spiralmodell (Schritt 4) Nächste Phase des Projekts planen. Als letzter Schritt einer Phase wird die nächste Phase inhaltlich und organisatorisch geplant. Diese Planung kann mehrere Phasen umfassen, sodass unabhängige Teilprojekte entstehen. Diese werden zu einem späteren Zeitpunkt wieder zusammengeführt. In einem Review (Prüfung) werden die Schritte 1 bis 3 analysiert, und es werden Schlussfolgerungen für die weitere Entwicklung gezogen. Sind die technischen oder wirtschaftlichen Risiken einer Projektfortsetzung zu hoch, kann das Projekt abgebrochen werden. Am Ende der Spirale liegt die fertige Software vor, die bezüglich der Anforderungen getestet wird. 32 Objektorientierter Softwareentwurf mit UML Das Spiralmodell Vorteile • Fehler werden zeitig erkannt. Nachteile • Hoher Managementaufwand. • Regelmäßige Überprüfung. • Änderungen sind leicht möglich. • Vorhandene Risikoaspekte werden meist nicht konsequent berücksichtigt. • Risiken, die mit dem Entwicklungsweg entstehen, können, werden minimiert. 33 Objektorientierter Softwareentwurf mit UML Entity-Relationship-Modell (ER-Modell) Ziel: Abbildung permanent gespeicherter Daten und ihrer Beziehungen untereinander Analyse der Informationen erfolgt aus fachlicher Sicht. Es entsteht ein konzeptionelles Modell, das gegen Veränderungen der Funktionalität weitgehend stabil ist. Es ist ein historischer Vorgänger des objektorientierten Konzepts. Einsatz in der Datenbankmodellierung. 34 Objektorientierter Softwareentwurf mit UML Entity-Relationship-Modell (ER-Modell) Dinge, Objekte (Entitäten) werden zu Entitätstypen zusammengefasst. Fachliche Zusammenhänge zwischen Entitäten werden durch Beziehungen (Assoziationen, relationships) beschrieben. Durch Rollen wird angegeben, welche Funktion eine Entität in einer Beziehung spielt. Eigenschaften von Entitäten werden durch Attribute beschrieben. Jede Entität muss durch einen eindeutigen Schlüssel identifizierbar sein. Der Komplexitätsgrad einer Assoziation wird durch die Kardinalität 35 angegeben. Objektorientierter Softwareentwurf mit UML Entity-Relationship-Modell (ER-Modell) Entität Als Entität wird ein individuelles Exemplar von Elementen bezeichnet. Entitäten werden zu Entitätstypen (Entitätsklassen) zusammengefasst. z.B. ein bestimmtes Haus aus der Klasse Häuser Entitäten entstehen durch Abstraktion und werden in einer Tabelle einer Datenbank gespeichert. 36 Objektorientierter Softwareentwurf mit UML Entity-Relationship-Modell (ER-Modell) Entität Entitäten können in Tabellen notiert werden. Die Spaltenüberschriften enthalten den Entitätstyp, den Schlüssel und die Attribute. Name des Entitätstyp Schlüssel Attribut 1 Attribut Entitätstyp Schlüssel Attribut 1 Attribut 37 Objektorientierter Softwareentwurf mit UML Entity-Relationship-Modell (ER-Modell) Beispiel für den Entitätstyp Auto Auto Entitäten Fahrgestell-Nr. Name Farbe WagenKlasse Baujahr 58127256 Opel Vectra blau Mittelklasse 2001 9215678 L300 marine Kleinbus 1998 38 Objektorientierter Softwareentwurf mit UML Entity-Relationship-Modell (ER-Modell) Autos auf einem Firmenparkplatz mit Autovermietung 39 Objektorientierter Softwareentwurf mit UML Entity-Relationship-Modell (ER-Modell) Autos auf einem Firmenparkplatz mit Autovermietung 9 Ein Mitarbeiter kann keines, oder ein oder mehrere Fahrzeuge besitzen oder mieten (Notation: MC Kardinalität: 0,1,, mal). 9 Eine Führerscheinklasse wurde von einem Mitarbeiter abgelegt oder nicht abgelegt (Notation: / Kardinalität: 0 oder 1). 9 Eine bestimmte Führerscheinklasse berechtigt zum Führen eines Fahrzeugtyps (Notation: 1 Kardinalität: 1). 9 Die Berechtigung zum Führen eines Fahrzeugtyps kann durch mehrere Führerscheinklassen abgedeckt werden (Notation: MC Kardinalität; 0,1,,n mal). 9 Ein Fahrzeugtyp kann keinem, einem oder mehreren Fahrzeugen zuerkannt werden. 9 Jedes Fahrzeug wird genau einem Fahrzeugtyp zugeordnet und gehört genau einem Mitarbeiter (evtl. dem Firmeninhaber). 9 Jede Fahrzeug kann von keinem, einem oder mehreren Mitarbeitern gemietet werden. 40 Objektorientierter Softwareentwurf mit UML Entity-Relationship-Modell (ER-Modell) Symbolerklärung für die Anzahl der Abhängigkeiten Notation Kardinalität (Vorkommen) MC 0,1, n mal 0 oder 1 1 genau 1 mal 41 Objektorientierter Softwareentwurf mit UML Ausblick auf das nächste Kapitel: 9 aus welchen Notationsformen sich die UML entwickelte 9 welche Notationen die UML vereinigt 9 wie Sie mit der UML die Modellierung von Anwendungen gestalten 42