Objektorientierte Software-Entwicklung Klaus Becker 2006

Objektorientierte Software-Entwicklung Problem Auftrag Ermittlung der Anforderungen Pflichtenheft (Prototyp) Entwicklung eines Modells OO-Analysemodell OO-Designmodell Implementierung des Modells Lauffähiges Programm Testen des Programms Auftraggerechtes Produkt

Software-Entwicklungsprozess Teil 1 Software-Entwicklungsprozess

Vom Problem zum Auftrag Software-Entwicklung geht in der Regel von einer Problemstellung und einer hieraus resultierenden Zielsetzung aus. Eine Formulierung der Zielsetzung kann auch als Auftrag für einen Entwicklungsprozess aufgefasst werden. Problem Auftrag 1 4 1$ 1$ 2 5 1$ 1$ 1$ 1$ 1$ 3 1$ 1$ 1$ 1$ 3 3 6 Auftrag „chuck a luck“: Entwicklung eines Simulationsprogramms, mit dem das Würfelspiel „chuck a luck“ am Rechner gespielt werden kann.

Ermittlung der Anforderungen Zu Beginn eines Software-Entwicklungsprozesses legen die Entwickler gemeinsam mit dem Auftraggeber die Funktionalität des gewünschten Systems fest. Beide Parteien müssen dabei genau vereinbaren, was das zu entwickelnde System leisten soll. Problem Auftrag Ermittlung der Anforderungen Pflichtenheft (Prototyp)

Prototyp Ein Prototyp dient dazu, bestimmte Aspekte eines zu entwickelnden Software-Systems vor der Realisierung zu überprüfen. Häufig wird ein Prototyp der Benutzungsoberfläche erstellt. Anhand dieses Prototyps können die Entwickler mit dem Auftraggeber diskutieren, inwieweit dessen Wünsche beachtet und umgesetzt wurden. Prototyp „chuck a luck“: Benutzungsoberfläche, bei der noch keine Funktionalitäten implementiert sind.

Pflichtenheft Ein Pflichtenheft ist eine textuelle Beschreibung dessen, was das zu realisierende System leisten soll. Es soll dabei zwei Zielsetzungen erfüllen: Zum einen ist es das „Einstiegsdokument“ in das Projekt für alle, die das System später pflegen und warten sollen, zum anderen soll es den Systemanalytiker in die Lage versetzen, eine objektorientierte Analyse vorzunehmen. Pflichtenheft „chuck a luck“ /0/ Der Benutzer erhält zu Beginn einen bestimmten Geldbetrag, mit dem er spielen kann. /1/ Der Benutzer kann eine Zahl auf einem Spielbrett auswählen. Er kann die Wahl dieser Zahl auch korrigieren. /2/ Der Benutzer kann sämtliche Spielaktionen einzeln auslösen: Einsatz zahlen, Würfel werfen, ... /3/ Der Spielablauf wird vom System „überwacht“, so dass keine unzulässigen Aktionen möglich sind. /4/ Sämtliche Spieldaten werden jeweils aktualisiert angezeigt. /5/ ...

Objektorientierte Modellierung Problem Auftrag Ermittlung der Anforderungen Pflichtenheft (Prototyp) Ein komplexeres Software-System muss zunächst entworfen werden, bevor es mit einer Programmiersprache realisiert werden kann. Hierzu werden Modelle des Systems aus unterschiedlicher Blickrichtung erstellt. Entwicklung eines Modells OO-Analysemodell OO-Designmodell

Objektorientierte Analyse 1 4 1$ 1$ 2 5 1$ 1$ 1$ Miniwelt 1$ 1$ 3 1$ 1$ 1$ 1$ 3 3 6 Der Blick richtet sich auf die Struktur der Miniwelt. Abbild der Miniwelt Vorlage für das System Modell Aufgabe der objektorientierten Analyse (kurz: OOA) ist es, die Miniwelt unabhängig von der späteren Implementierung mit Hilfe von Objekten, Klassen sowie deren Beziehungen zu beschreiben. Die Miniwelt wird dabei soweit abstrahiert, dass alle für den Auftraggeber relevanten Bestandteile des Problembereichs abgebildet sind. Das Ergebnis einer OOA ist also eine präzise, abstrahierende Beschreibung der Miniwelt.

Objektorientiertes Design Aufgabe des objektorientierten Designs (kurz: OOD) ist es, das OOA-Modell zu erweitern und an die Rahmenbedingungen des zu erstellenden Systems anzupassen. Hier werden dann u. a. auch programmiertechnische Details festgelegt wie die genaue Spezifikation der Attribute (Datentypen) und Methoden (Parameter und ihre Datentypen) oder die Anbindung an die Benutzungsoberfläche. Der Blick richtet sich auf das zu entwickelnde System. Abbild der Miniwelt Vorlage für das System Modell System

Objektorientierte Analyse 1 4 1$ 1$ 2 5 1$ 1$ 1$ Miniwelt 1$ 1$ 3 1$ 1$ 1$ 1$ 3 3 6 Identifikation der Objekte Zuständigkeit: verwaltet den Spielzustand und erteilt die passenden Aufträge an die Spiel-Objekte spielmanager zustand = ... spielbrett wuerfelA wuerfelB wuerfelC konto zahl = 3 augen = 3 augen = 3 augen = 5 stand = 9 Zuständigkeit: getippte Zahl merken Zuständigkeit: würfeln Zuständigkeit: Geldbetrag verwalten

Objektorientierte Analyse 1 4 1$ 1$ 2 5 1$ 1$ 1$ Miniwelt 1$ 1$ 3 1$ 1$ 1$ 1$ 3 3 6 Klassenentwurf TSpielmanager kennt zustand einsatzZahlen spielzahlSetzen(zahl) wuerfelWerfen gewinnVerbuchen kennt kennt 3 TKonto TSpielbrett TWuerfel stand zahl augen abheben(betrag) einzahlen(betrag) setzen(tipp) werfen

Objektorientiertes Design Anbindung an die GUI FGUI spielmanager konto hat kennt System

Objektorientiertes Design TKonto TKonto stand – stand: integer abheben(betrag) einzahlen(betrag) + create(betrag: integer) + destroy + abheben(betrag: integer) + einzahlen(betrag: int.) + getStand: integer + setStand(betrag: integer) Schnittstellenspezifikation System

Implementierung des Modells Problem Auftrag Ermittlung der Anforderungen Pflichtenheft (Prototyp) Entwicklung eines Modells OO-Analysemodell OO-Designmodell Das entwickelte Modell wird mit den Mitteln der gewählten Programmiersprache implementiert. Implementierung des Modells Lauffähiges Programm

Implementierung des Modells unit uKonto; interface type TKonto = class private stand: integer; public constructor create(startkapital: integer); procedure einzahlen(betrag: integer); procedure abheben(betrag: integer); function getStand: integer; end; implementation ... TKonto – stand: integer + create(betrag: integer) + destroy + abheben(betrag: integer) + einzahlen(betrag: int.) + getStand: integer + setStand(betrag: integer)

Testen des Programms Problem Auftrag Ermittlung der Anforderungen Pflichtenheft (Prototyp) Entwicklung eines Modells OO-Analysemodell OO-Designmodell Implementierung des Modells Lauffähiges Programm Bevor das fertige System an den Auftraggeber abgeliefert werden kann, muss systematisch getestet werden, ob es die gewünschten Anforderungen auch erfüllt. Gegebenenfalls müssen Korrekturen vorgenommen werden. Testen des Programms Auftraggerechtes Produkt

Testen des Programms Testprotokoll: /1/ Der Benutzer hat keine Zahl auf dem Spielfeld ausgewählt. (ok) /2/ Der Benutzer versucht, mehrfach zu würfeln. (ok) ...

Prozessdokumentation Problem Auftrag Genaue Formulierung des Auftrags Ermittlung der Anforderungen Pflichtenheft (Prototyp) Detailliertes Pflichtenheft Entwicklung eines Modells OO-Analysemodell OO-Designmodell Diagramme zur Darstellung der Modelle Implementierung des Modells Lauffähiges Programm Kommentiertes Programm Testen des Programms Auftraggerechtes Produkt Testprotokoll

Werkzeuge zur Unterstützung Problem Auftrag Textverarbeitung Ermittlung der Anforderungen Pflichtenheft (Prototyp) Textverarbeitung; Entwicklungsumgebung Entwicklung eines Modells OO-Analysemodell OO-Designmodell UML-Editor (z. B. Violet) Implementierung des Modells Lauffähiges Programm Code-Generator (z. B. UMLEd), Entwicklungsumgebung Testen des Programms Auftraggerechtes Produkt Entwicklungsumgebung, Textverarbeitung

Sequentielles Vorgehen Die Schritte zur Entwicklung der Software werden streng sequentiell – einer nach dem anderen – durchlaufen. Problem Auftrag Ermittlung der Anforderungen In der Praxis ist dieses Vorgehen kaum einsetzbar, da in späteren Phasen oft Erkenntnisse gewonnen werden, die eine Überarbeitung früher gewonnener Ergebnisse erforderlich machen. Pflichtenheft (Prototyp) Entwicklung eines Modells OO-Analysemodell OO-Designmodell Implementier-ung des Modells Lauffähiges Programm Testen des Programms Auftraggerechtes Produkt Wasserfallmodell

Iteratives Vorgehen Während des Entwicklungsprozesses wird eine Folge von Produktversionen erstellt, wobei die Funktionalität des Software-Produkts fortlaufend erweitert und angepasst wird. Zunächst werden nur die Kernfunktionalitäten des Systems realisiert. Anschließend werden weitere Funktionen sukzessive ergänzt. Dabei werden die sich ergebenden Anforderungen und Rahmenbedingungen mit berücksichtigt. Problem Auftrag Produkt Version 1 Produkt Version 2 Produkt Version ...

Teil 2 Beispiele

Zielsetzung Ziel ist es, dass Sie einen gesamten Software-Entwicklungsprozess selbstständig durchlaufen. Sie sollen in kleineren Teams eine etwas komplexere Software entwickeln und den gesamten Prozess gut dokumentieren. Problem Auftrag Ermittlung der Anforderungen Pflichtenheft (Prototyp) Entwicklung eines Modells OO-Analysemodell OO-Designmodell Implementierung des Modells Lauffähiges Programm Testen des Programms Auftraggerechtes Produkt

Entwicklungs-Teams Ein Team besteht aus den an den jeweiligen Tischen sitzenden Personen. Diese müssen gemeinsam ein Software-Produkt entwickeln.

Entwicklungsauftrag Als Auftraggeber möchte ich Ihnen zwei Aufträge zur Auswahl stellen: Simulation eines einfachen Roulette-Spiels / Simulation eines Galton-Bretts

Roulett Auftrag: Entwickeln Sie ein Programm zur Simulation eines Roulett-Spiels. Die Simulation kann einfach gehalten werden. Folgende Vereinfachungen könnte man z. B. vornehmen: - Es gibt nur 8 Felder auf dem Tisch zum Setzen. - Es gibt nur eine Sorte Chips. Es können aber mehrere auf ein Feld gelegt werden. - Ein Chip kann nicht über mehrere Felder gelegt werden. - ...

Galton-Brett Auftrag: Entwickeln Sie ein Programm zur Simulation eines Galton-Bretts. Die Simulation sollte zunächst eher einfach gehalten werden. So sollten Sie zunächst auf eine (sicher wünschenswerte, aber schwierig zu realisierende) Visualisierung verzichten.

Teamarbeit Auftraggeber Das bin ich. Teamleitung Eine / einer sollte die Koordination des Teams übernehmen. Diese Person sollte insbesondere darauf achten, dass das Produkt fristgemäß erstellt wird und sämtliche Dokumentationsaufgaben erledigt werden. Arbeit im Team Innerhalb eines Teams sollte die Arbeit gemeinsam geplant und dann aber arbeitsteilig ausgeführt werden. Beachten Sie: Je genauer Sie sich abstimmen, desto reibungsloser funktioniert das Zusammensetzen der Arbeitsergebnisse.

Zeitvorgaben Phase 1: Ermittlung der Anforderungen (bis zur Vormittagspause) beachte: Diese Anforderungen müssen mit dem Auftraggeber abgesprochen werden. Phase 2: Entwicklung eines Modells (bis zur Mittagspause) beachte: Das Modell sollte dokumentiert werden. Benutzen Sie hierzu das Werkzeug Violet und / oder UMLed Phase 3: Implementierung des Modells (bis zur Nachmittagspause) Phase 4: Testen des Programms (bis zur Abendpause)

Literaturhinweise Eine Linksammlung zum Thema „Software-Entwicklung“ findet man unter: http://hsg.region-kaiserslautern.de/faecher/inf/material/se/index.php