Objektorientierte Software Entwicklung Klaus Becker 2016 2 SoftwareEntwicklung

Objektorientierte Software. Entwicklung Klaus Becker 2016

2 Software-Entwicklung

3 Teil 1 Softwareentwicklung als Herausforderung

4 Softwareentwicklung ist schwierig Am 4. Juni 1996 startete die ESA eine unbemannte Rakete mit vier Satelliten an Bord von Französisch Guyana aus. 40 Sekunden nach dem Start explodierte die Ariane 5. Verlust ca. 500 Millionen Dollar für Rakete und Satelliten. Entwicklungskosten ca. 7 Milliarden Dollar. Ursache für den Absturz: Der Bordcomputer stürzte 36. 7 Sek. nach dem Start ab als er versuchte, den Wert der horizontalen Geschwindigkeit von 64 Bit Gleitkommadarstellung in 16 Bit signed Integer umzuwandeln: -+ b 1 b 2. . . b 15. Die entsprechende Zahl war grösser als 2^{15}=32768 und erzeugte einen Overflow. Das Lenksystem brach zusammen und gab die Kontrolle an eine zweite, identische Einheit ab. Selbstzerstörung wurde ausgelöst, da die Triebwerke abzubrechen drohten. Quelle: http: //www 5. in. tum. de/~huckle/bugs. html Quelle: http: //www. capcomespac e. net/dossiers/espace_eu ropeen/ariane 5/A R 501/V 88_AR 501. htm

5 kleine Projekte – große Projekte Worin unterscheiden sich kleine und große Projekte hinsichtlich der Vorgehensweise? Quelle: https: //commons. wikimedia. org/wiki/File: Juge ndfarm-Baumh%C 3%BCtte. jpg Quelle: https: //commons. wikimedia. org/wiki/File: Bloc kbohlenhaus_im_Bau_09. 04. 2014_16 -3340. jpg? uselang=de

6 kleine Projekte – große Projekte Worin unterscheiden sich kleine und große Projekte hinsichtlich der Vorgehensweise? >>> Ausgangsliste [25, 17, 32, 56, 25, 19, 8, 66, 29, 6, 20, 29] sortierte Liste [6, 8, 17, 19, 20, 25, 29, 32, 56, 66]

7 kleine Projekte – große Projekte Quelle: https: //files. ifi. uzh. ch/rerg/arvo/ftp/se_I/kapitel_01. pdf

8 kleine Projekte – große Projekte Quelle: https: //files. ifi. uzh. ch/rerg/arvo/ftp/se_I/kapitel_01. pdf

9 SW-Entwicklung - Herausforderungen Quelle: http: //www. projectcartoon. com/

10 Herausforderungen / Lösungsansätze n Oft handelt es sich um eine komplexe Aufgabe, die interdisziplinäres Vorgehen erfordert. n Die Zielsetzung ist nicht ganz klar. Evtl. werden auch Ziele während des Entwicklungsprozesses abgeändert. n An der Entwicklung von Software sind viele Personen mit unterschiedlichen Interessen und Aufgaben beteiligt: Auftraggeber, Entwickler, Anwender, … n Die Rahmenbedingungen sind ungünstig (z. B. knappe Ressourcen). n Die Organisation des gesamten Projekts und die Koordination der Aktivitäten ist schwierig. n Die Kommunikation zwischen den Beteiligten bereitet oft Probleme. n Das zu erstellende Software-Produkt ist immateriell (also nicht direkt greifbar und nur schwer begreifbar). n Strukturiertes Vorgehen n Projektmanagement n Dokumentation

11 Fachkonzept - Software: Die Programme, Verfahren, zugehörige Dokumentation und Daten, die mit dem Betrieb eines Computersystems zu tun haben (IEEE 610. 12). Also: Software umfasst mehr als Programme.

12 Fachkonzept - Softwareentwicklung (SE) umfasst alle Prozesse der – Planung, – Realisierung (Implementierung), – Wartung und – Pflege, die zur (Weiter-) Entwicklung von Software notwendig sind. Software Engineering ist das technische und planerische Vorgehen zur systematischen Herstellung und Pflege von Software, die zeitgerecht und unter Einhaltung der geschätzten Kosten entwickelt bzw. modifiziert wird.

13 Ein klassisches Vorgehensmodell Analyse Wasserfallmodell Problem Auftrag Analyse Entwurf Lastenheft (Prototyp) Entwurf Implementierung Modelle Softwarearchitektur Implementierung Test Programm gesamte Software Test Einführung/Wartung Auftraggerechtes Produkt

14 Klassische Vorgehensmodelle Traditionelle Vorgehensmodelle für die Softwareentwicklung versuchen, die in der Industrie erfolgreichen Prinzipien auf die Projektarbeit zu übertragen. Konkret manifestiert sich das so: ■ Der Prozess der Software-» Herstellung « ist wie in der Fabrik funktional zerlegt, hier in sogenannte Disziplinen. Was der Lackierer und der Monteur in der Fabrikhalle sind, sind die Analysten, Architekten und Entwickler im Softwareprojekt. ■ Es gibt einen mehr oder weniger sequenziellen Prozess mit aufeinander aufbauenden Arbeitsergebnissen. Was die Karosserie und der Motor in der Autofabrik sind, das sind die Spezifikation und Architekturdefinition im Softwareprojekt. ■ Die Arbeitsergebnisse der einzelnen Disziplinen werden kontrolliert bzw. qualitätsgesichert. Software wird getestet, im Falle von Dokumenten geschieht dies mittels Reviews. ■ Die Schritte vom Beginn des Projekts bis zum fertigen Endprodukt werden so exakt wie möglich geplant. Quelle: Jörg Dirbach, Markus Flückiger, Steffen Lentz: Software entwickeln mit Verstand. Dpunkt Verlag. Siehe auch: https: //www. dpunkt. de/leseproben/11031/3_Wie%20 wir%20 heute%20 Software%20 entwickeln. pdf

15 Agile Vorgehensmodelle Das Ziel agiler Softwareentwicklung ist es, den Softwareentwicklungsprozess flexibler und schlanker zu machen, als das bei den klassischen Vorgehensmodellen der Fall ist. Man möchte sich mehr auf die zu erreichenden Ziele konzentrieren und auf technische und soziale Probleme bei der Softwareentwicklung eingehen. Die agile Softwareentwicklung ist eine Gegenbewegung zu den oft als schwergewichtig und bürokratisch angesehenen traditionellen Softwareentwicklungsprozessen. https: //de. wikipedia. org/wiki/Agile_Softwareentwicklung Das agile Manifest bricht bewusst mit etlichen Prinzipien der traditionellen Softwareentwicklung. Es umfasst folgende vier Prinzipien: ■ Individuen und Interaktion sind wichtiger als Prozesse und Tools. ■ Funktionierende Software ist wichtiger als überbordende Dokumentation. ■ Enge Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen. ■ Auf Änderungen reagieren ist wichtiger, als einem Plan zu folgen. Quelle: Jörg Dirbach, Markus Flückiger, Steffen Lentz: Software entwickeln mit Verstand. Dpunkt Verlag. Siehe auch: https: //www. dpunkt. de/leseproben/11031/3_Wie%20 wir%20 heute%20 Software%20 entwickeln. pdf

16 Iterative und inkrementelle V. modelle Iteratives und inkrementelles Vorgehen: Während des Entwicklungsprozesses wird eine Folge von Produktversionen erstellt. Zunächst werden nur die Kernfunktionalitäten des Systems realisiert. Anschließend werden weitere Funktionen sukzessive ergänzt. Diese Vorgehensweise wird auch evolutionär genannt. Quelle: https: //de. wikipedia. org/wiki/Inkrementelles_Vorgehensmodell

17 Scrum Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Er beruht auf der Erfahrung, dass viele Entwicklungsprojekte zu komplex sind, um in einen vollumfänglichen Plan gefasst werden zu können. Ein wesentlicher Teil der Anforderungen und der Lösungsansätze ist zu Beginn unklar. Diese Unklarheit lässt sich beseitigen, indem Zwischenergebnisse geschaffen werden. Anhand dieser Zwischenergebnisse lassen sich die fehlenden Anforderungen und Lösungstechniken effizienter finden als durch eine abstrakte Klärungsphase. In Scrum wird neben dem Produkt auch die Planung iterativ und inkrementell entwickelt. Der langfristige Plan (das Product Backlog) wird kontinuierlich verfeinert und verbessert. Der Detailplan (das Sprint Backlog) wird nur für den jeweils nächsten Zyklus (den Sprint) erstellt. Damit wird die Projektplanung auf das Wesentliche fokussiert. n Transparenz: Fortschritt und Hindernisse eines Projektes werden regelmäßig und für alle sichtbar festgehalten. n Überprüfung: In regelmäßigen Abständen werden Produktfunktionalitäten geliefert und sowohl das Produkt als auch das Vorgehen beurteilt. n Anpassung: Anforderungen an das Produkt, Pläne und Vorgehen werden nicht ein für alle Mal festgelegt, sondern kontinuierlich detailliert und angepasst. Scrum reduziert die Komplexität der Aufgabe nicht, strukturiert sie aber in kleinere und weniger komplexe Bestandteile, die Inkremente. Quelle: https: //de. wikipedia. org/wiki/Scrum

Scrum 18 Kunde, Anwender Produkt. Verantwortlicher Entwickler -Team Überprüfung der Anforderungen Team-Sitzung Fertige Produktfunktionalität Planung: Was? Wie? Coach Entwicklungszyklus Anforderungen Quelle: https: //de. wikipedia. org/wiki/Inkrementelles_Vorgehensmodell Detailplan langfristiger Plan Überprüfung der Anforderungen Überprüfung der Arbeitsweise

19 Softwareentwicklung im Unterricht Software-Entwicklung ist eine komplexe Aufgabe, an der üblicherweise mehrere Personen beteiligt sind und die zur Bewältigung gut geplantes Vorgehen erfordert. Im Rahmen von schulgerechten Software-Entwicklungsprojekten lassen sich erste Einblicke in Arbeitsprozesse gewin-nen, die typisch für viele Bereiche in Wirtschaft und Technik sind. Schülerinnen und Schüler sollen hierbei u. a. erfahren, wie man komplexere Prozesse strukturiert und die Vorgehensweise organisiert, wie man im Team gemeinsam Teilaufgaben bearbeitet und dass man Verantwortung für das Gelingen des Projektes und für das entwickelte Produkt übernehmen muss. Bereits klei-nere Entwicklungsprojekte zeigen zudem sehr schnell, wie schwierig es ist, zuverlässig funktio-nierende und benutzergerechte Software zu erstellen und helfen so, Anforderungen an Software-Qualität realistisch einzuschätzen. Quelle: Lehrplan Informatik

20 Softwareentwicklung im Unterricht Um Software-Entwicklungsprojekte erfolgreich zu gestalten, sollten die zu bewältigenden Aufgaben eher klein und überschaubar gehalten werden. Mehrere kleinere Projekte sind daher in der Regel einem einzigen größeren Projekt vorzuziehen. Hierdurch können auch die zur erfolgreichen Durchführung erforderlichen Kompetenzen gezielter weiterentwickelt werden. Vorrangiges Ziel des Unterrichts zu diesem Inhaltsbereich besteht im Erwerb der folgenden Kompetenz: Software verantwortungsbewusst, systematisch und kooperativ entwickeln. Dazu gehört: - Gütekriterien bei der Entwicklung von Software kennen und beachten - Software-Entwicklungsprozesse systematisch durchführen - Ein Software-Entwicklungs-Projekt organisieren Quelle: Lehrplan Informatik

21 Teil 2 Beispiel: Chuck a Luck

22 Chuck a Luck ist ein Glücksspiel, das nach folgenden Regeln gespielt wird: Der Spieler / die Spielerin zahlt zuerst einen Dollar (Cent) als Einsatz. Diesen setzt er / sie auf eine Zahl des Spielfeldes. Anschließend wirft er / sie drei Würfel. Jetzt wird bestimmt, wie viele Würfel mit der gesetzten Spielzahl übereinstimmen. Gibt es keine Übereinstimmungen, ist der Einsatz verloren, ansonsten erhält der Spieler / die Spielerin den Einsatz zurück und zusätzlich für jede Übereinstimmung einen Dollar (Cent).

23 Das Problem Wie bei vielen realen Glücksspielen liegt auch beim Spiel Chuck a Luck die Vermutung nahe, dass man als Spieler auf Dauer sein Geld verliert.

24 Der Auftrag Als Auftraggeber hätte ich gerne ein Softwareprodukt, mit dem ein Spieler / eine Spielerin das Spiel Chuck a Luck interaktiv erkunden kann.

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

26 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 ggf. arbeitsteilig ausgeführt werden. Beachten Sie: Je genauer Sie sich abstimmen, desto reibungsloser funktioniert das Zusammensetzen der Arbeitsergebnisse.

27 Ermittlung der Anforderungen Ziel: Jedes Entwicklerteam ermittelt und präzisiert – in Anstimmung mit dem Auftraggeber – die Anforderungen an das Softwareprodukt. Methode: Mit einem Demonstrationsprototyp soll dem Auftraggeber ein erster Eindruck vermittelt werden, wie das Software-Produkt im Prinzip aussehen und funktionieren könnte. Was sollte der Demonstrationsprototyp leisten? n die Funktionalitäten der Software verdeutlichen n die Interaktionen des Benutzers mit der Software und das Verhalten der Software verdeutlichen n Szenarien zur Verwendung der Software verdeutlichen n einen Eindruck von der Benutzeroberfläche vermitteln Werkzeug: Der Demonstrationsprototyp soll mit einem Präsentationsprogramm wie Power. Point oder Open. Office-Impress erstellt werden. Darstellung des Ergebnisses: Die Anforderungen sollen als User Stories dargestellt werden.

28 Anforderungen – User Stories S 1: Spielkapital festlegen S 1: Als Anwender möchte ich das Spiel mit einem bestimmten Spielkapital spielen. Dieses Spielkapital wird vom Programm vorgegeben (z. B. 100 €) / kann vom Anwender eingegeben werden. … S 2: Einsatz zahlen vorher nachher

29 Vorgehen nach dem Wasserfallmodell Aufgabe: Das Team entwickelt zunächst ein objektorientiertes Datenmodell. Dieses Datenmodell sollte mit einem Objektdiagramm und einem passenden Klassendiagramm dargestellt und dokumentiert werden. In einem zweiten Schritt wird das Datenmodell implementiert und getestet. Die Tests bestehen aus Durchführungen von Chuck a Luck Spielen im Python-Ausführfenster. Alle Tests sollen dokumentiert werden. Anschließend (oder parallel hierzu) wird die GUI implementiert und mit dem Datenmodell verknüpft. Hierbei muss darauf geachtet werden, dass die GUI Zugriff auf das Datenmodell hat, aber nicht umgekehrt. Die GUI wird getestet, typische Spielabläufe sollen dabei dokumentiert werden. Wenn noch Zeit übrig bleibt: Das Softwareprodukt kann um zusätzliche Funktionalitäten erweitert werden.

30 Vorgehen nach dem Scrum-Modell Aufgabe: Einzelne User-Stories werden Schritt für Schritt umgesetzt. Das Datenmodell und die GUI werden hierzu jeweils so erweitert, dass die Story mit der Software durchführbar ist. In jedem Schritt muss also das objektorientierte Modell (in Form eines Objekt- und Klassendiagramms) entwickelt und dokumentiert werden. Die GUI muss nach jedem Schritt lauffähig sein. Alle hierzu durchgeführten Tests werden dokumentiert. Das Entwickler-Team hält den Fortschritt des Entwicklungsprozesses in einer jederzeit einsehbaren Übersicht fest. Wenn noch Zeit übrig bleibt: Das Softwareprodukt kann um zusätzliche Funktionalitäten erweitert werden.

31 Literaturhinweise Eine Linksammlung zum Thema „Software-Entwicklung“ findet man unter: http: //hsg. region-kaiserslautern. de/faecher/inf/material/se/index. php Projektmanagement: https: //wiki. rz. hochschuletrier. de/index. php/Durchf%C 3%BChrung_eines_Softwareprojekts