SoftwaretechnikSommer 2019: Teil 1: Einleitung

Henning Schnoor

Institut für Informatik, Christian-Albrechts-Universität zu Kiel

1

Vorstellung

Bio

2004 Diplom Mathematik / Informatik in Hannover

2007 Promotion in HannoverAlgebraic Techniques for Satisfiability Problems

2007/8 Postdoc in Rochester, NY, USA

2015 Habilitation in Kiel, AG Theoretische InformatikKnowledge-based, Strategic, and Temporal Security Properties

s. 2016 Privatdozent, AG Software Engineering

Forschungsinteressen• Metriken für Softwarequalität

• Formale Methoden für IT Sicherheit

• Komlexitätstheorie

• Logik

• Computational Social Choice2

Erstellung komplexer Softwaresysteme

Früherer “Ansatz”Komplexe System zweimal konstruieren:

• erster Schritt: “learn from failure”

• zweiter Schritt: Erfahrungen im tatsächlichen System umsetzen

Anforderungen Heute

• Systeme müssen schnell entwickelt werden, time-to-market niedrig

• Systeme müssen nach Auslieferung noch leicht, schnell und zuverlässig änderbar sein

• Websysteme: leichter änderbar als lokal installierte Anwendungen

KonsequenzBrauchen Techniken, die Erstellung von Softwaresystemen beschleunigen und planbar machen

3

Wissen über Softwareerstellung

Fragen

• Welches Wissen entstehtim (hypothetischen)ersten Schritt?

• WelchesprojektübergreifendesWissen entsteht währendder Entwicklung einesSoftwaresystems?

Erfahrungen

• Domänen-Wissen, Konkrete Lösungen für dieses Produkt

• Algorithmen für Probleme von allgemeinem Interesse

• Best Practices• Qualitätsindikatoren für Software• Design Patterns: “Schablonen” für Standard-Fälle• Vorgehensweisen bei Planung und Implementierung

• Tools• technisch: IDEs, VCS, Build-Prozesse, . . .• konzeptuell: Modellierung, Vorgehensmodelle, . . .• Qualitätssicherung: Tests, Metriken, . . .

4

Implementierung zu Deployment

−→

Nötige Schritte?• Implementieren

• Review

• Features einfügen

• Testen (automatisch)

• Release-Entscheidung

• Bauen

• Auslieferung

• (virtuelle) Maschinen skalieren

• . . . 5

Was fehlt?

Wichtiger Schritt

• diskutiert: Implementierung bis Deployment

• was fehlt?

6

Konzeption zu Implementierung

−→

Nötige Schritte?• Auftrag erhalten

• Anforderungen erfassen

• Umfang und Funktionenfesthalten

• System planen und entwerfen

• passende Technologien auswählen

• . . .

7

Struktur Vorlesung

Abschnitte1. Einleitung

2. Konfigurationsmanagement

3. Modellierung und UML

4. Modellierung der Struktur

5. Modellierung der Dynamik

6. Anforderungsermittlung

7. Entwurfsmuster

8. Komponenten und Schnittstellen

9. Qualitätssicherung

10. Projektmanagement und Vorgehensmodelle

8

Organisatorisches

Formalia zur Modulbewertung

• Die Belegung des Moduls erfolgt über die StudiDB.

• Es findet eine schriftliche Klausur statt.

• Klausurzulassung: mindestens 50% aller Hausaufgabenpunkte müssen erreicht werden.

• Nötig für das Bestehen ist das Erreichen von 50% der Klausurpunkte.

• Übungen liefern Bonuspunkte in der Klausur. Prozentpunkte P in Klausur wegeben sich wie folgt:

P = 100% ∗ kK, falls

kK

< 0.5, ansonsten

P = 100% ∗ kK

+max(0, 20% ∗ (2h

H− 1)

)k = erreichte Punktsumme in der Klausur,K = erreichbare Punktsumme in der Klausur,h = erreichte Punktsumme in den Hausaufgaben,H = erreichbare Punktsumme in den Hausaufgaben.

9

Termine

VorlesungMo 16-18 CAP2 C

Di 16-18 CAP2 H

• V+Ü 3/2 SWS (7 ECTS)

• V 4-stündig

• nur 34 der Termine

Feiertage

• 22. April: Ostern

• 10. Juni: Pfingsten

• 22.-30 Juni: Kieler Woche

Termine1. 8. April

2. 9. April

3. 15. April

////16.//////April

////23.//////April

4. 29. April

5. 30. April

6. 6. Mai

7. 7. Mai

8. 13. Mai

9. 14. Mai

10. 20. Mai

11. 21. Mai

////27./////Mai

12. 28. Mai

13. 3. Juni

14. 4. Juni

////11.//////Juni

15. 17. Juni

16. 18. Juni

////24.//////Juni

////25.//////Juni

17. 1. Juli

18. 2. Juli

10

Übung - Betreuer

• Christian Zirkelbach Link

• Di: 10:15-11:45 + 12:15-13:45 Uhr• Mail: czi@informatik.uni-kiel.de• Korrektur: Johannes Brück (stu204865@mail.uni-kiel.de)

• Alexander Krause Link

• Do: 10:15-11:45 + 12:15-13:45 Uhr• Mail: akr@informatik.uni-kiel.de• Korrektur: Pascal Stücker (stu120567@mail.uni-kiel.de)

• Björn Vonheiden• Mi: 10:15-11:45 Uhr• Mail: stu202077@mail.uni-kiel.de

SprechstundenNach Vereinbarung

11

Übung - Anmeldung

StudiDB Link

• Für das Modul anmelden

iLearn Link

• Anmeldung wird heute Abend um 20:00 Uhr freigeschaltet.

• Partner zur Kleingruppe einladen.• Übungspartner besuchen den gleichen Termin.• Es wird keine Ein-Personen-Gruppen geben.

• Sicherstellen, dass valide E-Mail eingetragen ist.

12

Übung - Betrieb

• Übungsserien werden im iLearn ausgegeben und im iLearn und Git abgegeben.

• Serien werden montags um 10:00 Uhr aus- und abgegeben.

• Serie 1 ist heute Abend im iLearn verfügbar(Abgabe: 15.04.19 um 10:00 Uhr).

• Erster Übungstermin: nächste Woche (ab 16.04.19).

13

Einleitung

Software Engineering (Softwaretechnik)

Programmierung

• Programmierung: EigentlichesImplementieren

• Resultat: Programmcode

• einziger nicht-optionaler Aspekt derSoftware-Entwicklung

vs.

Software-Entwicklung

• Gesamter Prozess von Projektbeginn

• Resultat: Laufende Software

• Beinhaltet Planung, Organisation undBetrieb

14

Was ist (Software) Engineering?

Engineering (Wikipedia)Engineering is the application of mathematics, as well as scientific, economic, social, andpractical knowledge, to invent, innovate, design, build, maintain, research, and improvestructures, machines, tools, systems, components, materials, processes, solutions, andorganizations.

Ingenieurwissenschaften (nach Wikipedia)Galten als angewandte Naturwissenschaft. Es geht den Ingenieurwissenschaften insbesondereum Wissen, das geeignet ist, Handlungen, etwa von Ingenieuren, anzuleiten. Sie werden daherauch den Handlungswissenschaften zugerechnet.

15

Engineering vs. Non-Engineering [PW17; LL13]

Technisches Produkt Nicht-Technisches Produkt

Voraussetzungen Technisches Wissen Inspiration

Deadlines planbar mit hoher Genauigkeit nicht planbar

Preis kostenorientiert, kalkulierbar abhängig von Marktwert

Standards existieren und werden eingehalten unüblich

Vergleich objektive, quantitative Kriterien schwierig und subjektiv

Autor anonym, oft keine emotionaleVerbindung zum Produkt

starke Bindung (für Autor undKunden)

Haftung gesetzlich geregelt, kann nichtausgeschlossen werden

nicht anwendbar

Wo steht Software? 16

Definitionen von Software Engineering nach [PW17]

F. L. Bauer, 1971the establishment and use of sound engineering principles to obtain economically software thatis reliable and works efficiently on real machines.

IEEE 610.12 (1990)

1. The application of a systematic, disciplined, quantifiable approach to the development,operation, and maintenance of software; that is, the application of engineering to software.

2. The study of approaches as in (1).

ISO/IEC/IEEE 24765 (2019)

1. the systematic application of scientific and technological knowledge, methods, andexperience to the design, implementation, testing, and documentation of software.

2. see IEEE 610.12 (1)17

Typische Fragen in Ingenieur-Disziplinen

nach [PW17]

• Wie beschreiben wir Anforderungen und vermeiden Missverständnisse mit dem Kunden?

• Wie beschreiben wir Design-Ideen und vermeiden Missverständnisse mit denImplementierern?

• Wie gehen wir sicher dass wir• das richtige Produkt bauen? (Validation)• das Produkt richtig bauen? (Verifikation)

• Wie messen wir Produktqualität?

• Wie planen wir Reihenfolge und Prioritäten von Aktivitäten im Projekt?

18

Softwaretechnik im Kontext des Studiums

Softwaretechnik / Software EngineeringFrage: Wie verwenden wir Methoden der Informatik, umgroße Softwaresysteme

• korrekt,

• zuverlässig,

• kosteneffizient

zu erstellen?

Insbesondere

• Viele (aber nicht alle!) Techniken zahlen sich erst bei “großen” Projekten aus

• Schwierigkeit für Übung, (etwas) realistischer im Softwareprojekt

19

Softwaretechnik im Kontext des Studiums

Vorlesung Bezug

Programmierung Java in Vorlesung, Übung und Softwareprojekt

Informationssysteme Datenbanken zentral für viele moderne Anwendungen. Anknüp-fungspunkt für Software Engineering als Abstraktionsschicht: Ob-ject Relational Mapping

Algorithmen und Daten-strukturen

Verwenden Datenstrukturen wie Graphen, Arrays, Listen

Theoretische Grundlagender Informatik

Verwenden Automaten-Modellierung, formale Analyse (semanti-scher) Eigenschaften von Software 20

Softwareprojekt

Übersicht

• Anschlussveranstaltung zu Softwaretechnik

• Programmierung „im Großen“

• 4 Wochen Blockveranstatung: 19. August bis 13. September(IT-Sicherheit: 16. September bis 27. September)

• Begrenzte Plätze

56 im Softwareprojekt30 in IT-Sicherheit

Anmeldung

• Anmeldung jetzt über StudiDB

• Zuteilung der Plätze durch Prüfungsamt

• Absicht: „keine zwei Absagen“ 21

Referenzen

BasisWilhelm Hasselbring (2018). Softwaretechnik Folienskript.

Lehrbücher I

• Ian Sommerville (2018). Software Engineering. 10. Auflage.http://software-engineering-book.com. Pearson. ISBN: 978-3-86326-835-0Liefert eine breiten Überblick, jedoch ohne sehr tief zu gehen.

• Helmut Balzert (2011). Lehrbuch der Softwaretechnik: Entwurf, Impementierung,Installation und Betrieb. 3. Spektrum Akademischer VerlagLiefert eine breiten Überblick, mit Betonung auf den Entwurf.

• Thomas Grechenig, Mario Bernhart, Roland Breiteneder und Karin Kappel (2010).Softwaretechnik. Pearson StudiumLiefert einige Fallbeispiele aus der Praxis.

22

Referenzen

Lehrbücher II

• B. Brügge und A. Dutoit (2010). Object Oriented Software Engineering Using UML,Patterns, and Java. 3rd. Prentice Hall. ISBN: 978-0138152215 Betont objektorientierteTechniken.

• C. Rupp, S. Queins u. a. (2012). UML 2 glasklar: Praxiswissen für die UML-Modellierung.4. Auflage. Hanser. ISBN: 978-3-446-43057-0 UML. Online-Ausgabe im CAU-Netz:http://dx.doi.org/10.3139/9783446431973

• C. Kecher und A. Salvanos (2015). UML 2.5: Das umfassende Handbuch. GalileoComputing. Rheinwerk Verlag GmbH. ISBN: 9783836229777 UML-Teil basiert zum großenTeil hierauf

Original-LiteraturWissenschaftliche Arbeiten, siehe Referenzen am Ende

23

Was ist Software?

Software„Software: Computer programs, procedures, rules, and possibly associateddocumentation and data pertaining to the operation of a computer system“

IEEE Standard Glossary of Software Engineering Terminology [90]

Zu unterscheiden:

• Software as a Service

• Software as Code

24

Softwaresysteme und Software Engineering

• Ein Softwaresystem ist ein System, dessen Komponenten aus Software bestehen.• Softwaresysteme sind Produkte von Softwareprojekten.• Betrachtet wird im Software Engineering vor allem die Entwicklung „großer“

Softwaresysteme, z.B.:• Betriebssysteme,• Datenbankmanagementsysteme,• Web-Informationssysteme,• Steuerung von Industrieanlagen.

• Komplexe Softwaresysteme finden sich mittlerweise in allen Bereichen des Lebens,beispielsweise

• Eingebettete Software in PKWs, Haushaltsgeräten,• Steuerungen in der Verkehrs- und Energietechnik,• Informationssysteme in Unternehmen, und• die neue elektronische Gesundheitskarte (genauer gesagt, die dazugehörigen Server).

25

Zunehmende Bedeutung von Software

Soft

war

e Com

plex

ity

1977100

Lines of Code

198150.000

Lines of Code

20081–10 Mio.

Lines of Code

Heute50–100 Mio.Lines of Code

Zukünftig200–300 Mio.Lines of Code

5% 8% 15% 40% 80%

Erstes Auto mit Software:

GM Oldsmobile Toronado

Komplexität/Größe (Lines of Code) und Anteil Gesamtwertschöpfung26

Übersicht

Einleitung

Herausforderungen in derSoftwareentwicklung

Software Engineering als Lösung

Prinzipien des Software Engineering

Abstraktion

Strukturierung

Modularisierung

Kapselung

Separation of Concerns

Änderbarkeit

Inkrementalität

Gründlichkeit und Formalität

Beziehungen zu anderen Bereichen undDisziplinen

Professionelle Verantwortung

27

Übersicht

Einleitung

Herausforderungen in derSoftwareentwicklung

Software Engineering als Lösung

Prinzipien des Software Engineering

Abstraktion

Strukturierung

Modularisierung

Kapselung

Separation of Concerns

Änderbarkeit

Inkrementalität

Gründlichkeit und Formalität

Beziehungen zu anderen Bereichen undDisziplinen

Professionelle Verantwortung

28

Erwartungen an Softwaresysteme

Was wir nicht wollen:Fehlerhafte Software

DennFehler sind teuer:

• Personenschäden,

• Sachschäden,

• Konventionalstrafen (für zu späte und/oder fehlerhafte Software),

• Kosten für Fehlersuche und Fehlerbehebung,

• Schaden für das Unternehmens-Image,

• Rechtliche Konsequenzen, z.B. Schadenersatz.

29

Boing 737 Abstürze

30

Boing 737: Was ist passiert?

MCAS

• Maneuvering Characteristics Augmentation System

• andere Aerodynamik als Vorgängermodell: Zusätzlicher Auftrieb führt zum “Nasehochziehen”

• MCAS steuert mit Höhenleitwerk gegen um Flugzeug zu stabilisieren

31

Boing 737: Falsche Dokumentation

DokumentationMCAS verstellt Leitwerk um bis zu 0, 6 Grad

Realität

• Verstellung bis 2, 5 Grad, mehrmals

• MCAS hat “volle Kontrolle überBewegung des Höhenleitwerks bis zumAnschlag”

Konsequenzen

• Zertifizierung aufgrund falscher Informationen

• Falsche Informationen für Piloten

32

Boing 737: Mangelnde Redundanz

MCAS Verhalten

• System triggert abhängig von Lage des Flugzeugs

• Lage wird (für MCAS) durch nur einen Anstellwinkelsensor gemessen

• Sensordaten fehlerhaft

33

Boing 737: Mangelnde Kontrolle

Zulassung

• zuständig: FAA (Federal Aviation Administration)

• Prüfungen z.T. an Hersteller delegiert

• enger Zeitplan für Zulassungen

34

Security-Beispiel: Meltdown

OS-Sicherheit

• Betriebssysteme: Prozess-Isolation

• Prozess A kann nicht auf Daten von Prozess B zugreifen

(Bsp: kryptografische Schlüssel, Login-Daten, . . . )

Angriff

• Isolation größtenteils wirkungslos

• Zusammenspiel von verschiedenen Prozessor-Features

• „Fehler“ in Prozessor-Microcode

• Reine Software-Lösung: Bis zu 30% Performance-Einbußen

35

Beispiel: Meltdown Angriff

RückblickMikroprozessor Design

Gründe für nicht-Ausführung von Code

• unerlaubter Speicherzugriff

• Abzweigung in „unerwartete“ Richtung

Spekulative Ausführung

• Code dennoch ausführen

• roll-back wenn Code doch nicht ausgeführtwerden soll (backtrack)

36

Meltdown Übersicht

Angriff

• Angreifer will Wert b erfahren,gespeichert an Stelle x desSpeichers K

• legt Array A von Objekten Q an(Größe = Cache-Seitengröße)

• Array wird nur angelegt, nichtgelesen oder initialisiert

→ Inhalt von A nicht im Cache

Fälle

b 6= 0 while-Schleife wird beendet, A[b] im Cache → Zugriff auf A[b] danach schneller

b = 0 race condition Behandlung (evtl. kein fetch) 37

Meltdown Referenz

PaperMoritz Lipp, Michael Schwarz, Daniel Gruss, Thomas Prescher, Werner Haas, Stefan Mangard,Paul Kocher, Daniel Genkin, Yuval Yarom und Mike Hamburg (2018). “Meltdown”. In: ArXive-prints. arXiv: 1801.01207

Kernpunkte

• Betriebssysteme: Linux, Windows

• Docker

• Intel: Lesegeschwindigkeit 503 KB/sec

• nur „Spielzeugbeispiele“ für AMD, ARM

38

Beispiel: Airbus A320 (1993)

Bruchlandung beim Landeanflug auf Flughafen WarschauFolgen: 2 Tote, erheblicher Sachschaden

39

Warum stürzte der Airbus ab?

• Die Maschine hatte Probleme durch Scherwinde, so dass das rechteHauptfahrwerk der Maschine erst nach 770 Metern ersten Bodenkontakt hatte, daslinke Fahrwerk nach 1525 Metern.

• Bereits beim ersten Bodenkontakt betätigte der Pilot die Radbremsen, welcheaber aufgrund der ungenügenden Haftung auf der nassen Landebahn nicht griffen.

• Erst nach dem Aufsetzen des linken Fahrwerkes gab das Programm desFly-by-Wire-Systems die Störklappen und die Schubumkehr als Bremshilfen frei.

• Zum Stand des damaligen Wissens seitens des Herstellers galt Bodenkontakt erstdann als erreicht, wenn das Fahrwerk mit mindestens 12 t belastet wurde und sichdie Räder des Hauptfahrwerkes in Drehung befanden.

• Aufgrund des starken Wasserfilms und des dadurch entstehenden Aquaplaningssetzte die Maschine zwar auf, die Räder drehten sich jedoch so langsam, dass derBordcomputer davon ausging, die Maschine befinde sich noch nicht auf demBoden, und deshalb jegliches Bremsmanöver verhinderte.

40

Was waren die Konsequenzen?

• Die Software des Fly-by-Wire-Systems aller Typen der Airbus-A320-Familie wurdeüberarbeitet und der notwendige Aufsetzdruck des Fahrwerks für die Freigabe vonStörklappen und Schubumkehr von 12 t auf 2 t gesenkt.

• Ferner ist die Aktivierung der Störklappen und der Schubumkehr nicht mehr an dieRaddrehung gekoppelt, die Bremsaktivierung jedoch nach wie vor.

• Somit soll gewährleistet sein, dass die aerodynamische und triebwerksseitigeBremsung in jedem Fall funktioniert, auch wenn sich die Räder nicht ausreichendschnell drehen.

41

Update 1:

• Am 1. März 2008 musste Flug LH 044 am Hamburger Flughafen mitten imOrkantief Emma durchstarten.

• Der Airbus 320 schrammt mit der Flügelspitze über die Landebahn.

• Weil ein Reifen der Maschine bereits kurz den Boden berührt hatte, schaltete derComputer vom Anflug- in den Bodenmodus.

• Letzterer aber erlaubt keinen so starken Einschlag des Querruders, damit es nichtzum Aufschaukeln kommt – bei extrem starken Seitenwinden ist dies jedoch eineerhebliche Einschränkung für die Piloten.

• „Bei Landungen mit starkem Seitenwind, sieht die BFU in der beschriebenenSystemauslegung eine designbedingte Schwäche, speziell im Übergangsbereich vomFlight Mode zum Ground Mode, wenn das Flugzeug nach dem Aufsetzen denBodenkontakt wieder verliert.“

42

Aus dem abschließenden Untersuchungsbericht durch die Bundesstelle fürFlugunfalluntersuchung aus dem März 2010 (http://www.bfu-web.de/):Besonders sei auf Abschnitt 2.2.4 „Designbedingtes Systemverhalten des Flugzeuges“hingewiesen. Im letzten Absatz wird sehr deutlich auf die vorhandene Problematik beider Modellierung der realen Vorgänge unter den vielen verschiedenenWetterbedingungen hingewiesen. Es lässt sich nicht einfach als ein Problem vonunzureichender Anforderungsanalyse einordnen. Hier kann jedoch deutlich gesagtwerden, dass eine widerspruchsfreie und korrekte Dokumentation nicht vorgelegen hat.Vorfälle im Luftfahrtbereich – das zeigt die Geschichte – sind stets sehr komplexeVorgänge, bei denen eine einfache Ursachenermittlung nicht möglich ist.

43

Beispiel: Airbus A400M

Update 2:

• Am 9. Mai 2015 sützte ein nagelneues Militärtransportflugzeug vom Typ A400M inSevilla ab.

• Die Nachforschungen ergaben ein deutliches Ergebnis:• Kurz nach dem Start der Testmaschine hatten drei Triebwerke von den Computern

widersprüchliche Befehle erhalten und daraufhin die Leistung abgeschaltet.

• „Es handelt sich sehr wahrscheinlich um ein Qualitätsproblem in unserem Werk“,heißt es aus Airbus-Kreisen.

• Eine „Dringliche technische Empfehlung des Herstellers“ vom 19. Mai 2015 (AOT)sieht die Durchführung eines einmaligen Kontroll-Checks der elektronischenTriebwerkskontrolleinheit bei jedem Flugzeugtriebwerk vor dem nächsten Flug vor.Quelle: http://airbusdefenceandspace.com/wp-content/uploads/2015/05/ma-10-2015-n-19052015-de.pdf

44

Beispiel: Ariane 5 (1996)

Ca. 40 Sek. nach dem Start kam die Rakete vom Kurs ab und wurde gesprengt.

Folgen: Gesamtschaden von mehr als 1 Milliarde Euro

45

Warum ist die Ariane 5 beim Erstflug explodiert?

• Die Software für das Trägheitsnavigationssystem wurde unverändert von der Ariane4 übernommen.Ein Test dieser Software-Komponente unterblieb daher.

• Die übrigen Systeme der Rakete wurden komponentenweise gründlich getestet.Ein gemeinsamer Test der gesamten Steuerungssoftware der Rakete unterblieb ausKosten- und Machbarkeitsgründen.

• In der Software für das Trägheitsnavigationssystem gibt es eine Abgleichsfunktion,deren Werte eigentlich nur sinnvoll sind, solange die Rakete noch nicht fliegt.Diese Funktion arbeitet programmgemäß bis ca. 40 s nach der Zündung weiter,weil das bei der Ariane 4 im Fall eines Countdownabbruchs kurz vor dem Abhebensinnvoll war.

46

Chronik der Ereignisse

1. Flug 501 startet am 4. Juni 1996. Die Triebwerke zünden um 933:59 Uhr.

2. Die ersten 36 Sekunden des Flugs verlaufen normal.

3. Die Ariane 5 hat eine andere Flugbahn als die Ariane 4, deshalb berechnet dieAbgleichsfunktion einen Wert, der wesentlich größer ist als erwartet

4. Bei der Konvertierung dieses Werts tritt ein Überlauf auf (64 Bit Gleitkommazahlin 16 Bit Ganzzahl)

5. Das Programm erzeugt eine Ausnahmebedingung (Fehlermeldung)

47

Chronik der Ereignisse (Forts.)

6. Die Ausnahmebedingung wird nicht behandelt (obwohl dies in der verwendetenProgrammiersprache Ada möglich wäre)

7. Der Trägheitsnavigationsrechner setzt eine Fehlermeldung an den Steuerrechner abund schaltet sich 36,75 s nach Start ab.

8. Das Trägheitsnavigationssystem ist doppelt ausgelegt

9. Ein Umschalten auf das zweite System schlägt fehl, da dieses System das gleicheProblem hatte und sich vor 0,05 s ebenfalls abgeschaltet hat

10. Der Steuerrechner ist nicht auf den Ausfall beider Trägheitsnavigationssystemeausgelegt und interpretiert die gemeldeten Fehlercodes als Flugbahndaten

48

Chronik der Ereignisse (Forts.)

11. Dies führt zu völlig unsinnigen Berechnungen und als Folge davon zu unsinnigenStellbefehlen an die Steuerdüsen der Rakete:Diese werden bis zum maximal möglichen Anstellwinkel ausgeschwenkt.

12. Aufgrund der Schwerkräfte zerbricht die Rakete.

13. Der Selbstzerstörungsmechanismus wird aktiviert.

14. Rakete und Nutzlast werden gesprengt um zu verhindern, dass größereTrümmerteile auf den Boden fallen.

49

Schaden durch den Absturz

Juni 1996

• Vier Satelliten verloren: 400 - 500 Millionen Euro

• Zwei Jahre Verzug im Entwicklungsprogramm: > 500 Millonen Euro

• Zwei zusätzliche Erprobungsstarts bei Gesamtkosten des Projekts von 1987 bis1998 von 6.700 Millionen Euro

50

Folgerungen für das Software Engineering

Spezifikation: Bestehende Software darf nicht unbesehen für eine neueAufgabe wiederverwendet werden.

Dokumentation: Die Fähigkeiten einer Software sowie alle Annahmen, die sieüber ihre Umgebung macht, müssen dokumentiert sein.Andernfalls ist die Prüfung auf Wiederverwendbarkeit extremaufwändig.

Design by Contract: Kooperieren zwei Software-Komponenten miteinander, somüssen eindeutige Regeln definiert, dokumentiert undeingehalten werden.Wer liefert wem was unter welchen Bedingungen?

Abstraktionen: Welche Systemeigenschaften gehen bei Abstraktion verloren?Welchen Einfluss hat das auf systemrelevante Eigenschaften?

51

Folgerungen für das Software Engineering

Fehlerbehandlung: Jede potentielle Fehlersituation in einer Software muss• entweder behandelt werden,• oder die Gründe für die Nichtbehandlung müssen so dokumentiert

werden, dass die Gültigkeit der dabei getroffenen Annahmen überprüfbarist.

Software 6= Hardware: Mehrfache identische Auslegung von Systemen hilft nichtgegen logische Fehler in der Software.

Sicherheit: Bei Störungen in sicherheitskritischen Systemen ist Abschalten nur danneine zulässige Maßnahme, wenn dadurch wieder ein sicherer Zustand erreichtwird.

Fehlertoleranz: Eine hundertprozentige Absicherung gegen Fehler ist nicht möglich,daher müssen Verfahren zur Tolerierung von Fehlern entwickelt werden.

52

Qualitätsmanagement

Test: Bei der Prüfung von Software, die aus mehreren Komponentenbesteht, genügt es nicht jede Komponente einzeln zu prüfen.Umfangreiche Integrations- und Systemtests unter möglichstrealistischen Bedingungen sind notwendig.

Review: Jedes Programm sollte (neben einem sorgfältigem Test) durchkompetente Fachleute inspiziert werden, weil insbesondere dieErfüllbarkeit und Adäquatheit von Annahmen und Ergebnissenhäufig nicht testbar ist.

Risikomanagement: Die Risiken erkennen, angemessene technische Maßnahmen(siehe oben) planen, durchsetzen und überprüfen.Evtl. Entscheiden, Projekte frühzeitig zu beenden.

53

Weitere Beispiele für versagende Software I

Korrektheit Versicherer Ergo hat sich bei Hunderttausenden Kunden verrechnet(2015):Ursache des Problems sind nach Ergo-Angaben Fehler in denteilweise Jahrzehnte alten Computerprogrammen, mit denen dieErträge berechnet wurden.http://heise.de/-2761451

Sicherheit/Safety Ford Explorer und Mountaineer: Der Tempomat erhöht gelegentlicheigenständig die Geschwindigkeit (2000):Software-Fehler in Antriebselektronik

54

Weitere Beispiele für versagende Software II

Verfügbarkeit Die Verfügbarkeit der webbasierten Hartz-IV-Software A2LL sinktvon 99,7 Prozent im Jahr 2005 auf 98,3 Prozent im Jahr 2006[Bun06].

Zuverlässigkeit Transporter Vito und Viano von Mercedes-Benz: Ausfall derKraftstoffzufuhr (2004):Die Software der Dieselsteuergeräte aktiviert in Situationen, indenen dies eigentlich nicht vorkommen sollte, dieKraftstoffabschaltung

55

Weitere Beispiele für versagende Software III

Performance Polizei-Informationssystem: NiedersächsischeVorgangsbearbeitungs-, Analyse-, Dokumentations- undInformationssystem NIVADIS (2003):Extrem lange Wartezeiten bei der Bearbeitung von VorgängenÄhnliche Probleme in Bayern mit Mängeln desComputerprogramms für die Dienstplangestaltung (DiPlaZ).http://heise.de/-124385

Sicherheit/Security W32.Sasser.Worm: Systemabstürze (2004):Schwachstelle im “Local Security Authority Subsystem Service” vonWindows

56

Weitere Beispiele für versagende Software IV

Privacy Hacker-Einbruch im Web-Informationssystem der MelbourneTransurban CityLink (2002):Veröffentlichung von Kreditkartendetails von über 500000 Kundenauf einer Web-Seite

Stromausfall Acht Staaten im Nordosten der USA und Teile Kanadas blieben imAugust für fünf Tage ohne Strom (2003):Schuld am Blackout war ein Softwarefehler desManagementsystems zur Überwachung und Steuerung vonStromnetzen.

57

Performance und Verfügbarkeit

https://www.healthcare.gov/ Progress and Performance Report, December 2013:

• The assessment highlighted a number of significant problems, most notably anunacceptable user experience marked by very slow response times, inexplicableuser error messages and frequent website crashes and system outages.

• At the same time, the team identified the root cause problems that needed to beaddressed to fix the site.

• These root causes included: hundreds of software bugs, inadequate hardware andinfrastructure, and a general lack of system monitoring and incident responsecapabilities.

• The assessment also identified weaknesses in how the project was being managed,with slow decision making and diffuse or unclear accountability.

Quelle: https://www.cms.gov/newsroom/mediareleasedatabase/press-releases/2013-press-releases-items/2013-12-01.html 58

Lösung der Probleme

Siehe auch die Monitoring-FrameworksKieker (http://kieker-monitoring.net/) undExplorViz (https://www.explorviz.net/).

59

Sichten auf Software Engineering

DefensivSoftware Engineering ist defensiveWissenschaft: „Verhindert Katastrophen“

KonstruktivSoftware Engineering ist konstruktiveWissenschaft: Erlaubt Konstruktion vonkomplexen Softwaresystemen

„Success Stories“Große Software-Systeme sind ohne strukturierte Herangehensweise nicht möglich.

60

„Große“ Software-Systeme I

Linux Kernel

It’s the largest software development project ever, in the historyof computing – by the number of people using it, developing it,and now using it, and the number of companies involved.

Greg Kroah-Hartman

• über 25 Millionen Code-Zeilen (LoC)

• über 4000 Entwickler von über 440 Unternehmen

61

Linux Kernel Map (http://makelinux.net/kernel_map/)

62

Linux Kernel Map (freeCodeCamp)

63

„Große“ Software-Systeme II

Webshop otto.de

• 2,5 Milliarden Euro Umsatz (2015/16), 90% online

• 500 deployments / Woche

64

„Große“ Software-Systeme III

65

Allgemeingültige Methoden?

Beispiele

• Linux Kernel „Groß“ nach LoC, Anzahl Entwickler, Einsatz

• otto.de „Groß“ nach Deployment-Infrastruktur, Kosten für Ausfall

• Netflix „Groß“ nach Anzahl Nutzer, Datenverarbeitung

KonsequenzVerschiedene Methoden für verschiedene Projekte!

Weitere Faktoren?

• Web-Anwendung vs. eingebettete Systeme

• sicherheitskritische Systeme

• Verhältnis Entwickler / Betreiber

• . . .

„no silver bullet!“

66

Arten von Softwaresystemen

Beispiele

• Stand-Alone Anwendungen

• Interaktive transaktionsbasierteAnwendungen

• Eingebettete Steuerungssoftware

• Batch Processing Systeme

• Unterhaltungssysteme

• Systeme für Modellierung und Simulation

• Datenerfassungssysteme

• Systeme von Systemen

nach [Som18]

Konsequenzen?Welche Konsequenzen ergeben sich für denEntwicklungsprozess?

67

Software Engineering

AnliegenWissen über Erstellung vonSoftwaresystemen allgemein nutzbar machen

• Planung

• Entwurf

• Implementierung

• Betrieb und Wartung

68

Tools in der Informatik

Tools„Informatiker“ brauchen Tools für verschiedene Zwecke.

69

Tools in der Informatik

Beispiel: Theorie

• LATEX+ pdf-Viewer

• EMail

• Browser

Beispiel: Software-Entwicklung• java(c)

• Maven

• Jenkins

• Tomcat

• docker

• gradle

• git

• Visual Paradigm

• FindBugs

• CheckStyle

• JUnit

• PMD

• ant

• svn

• eclipse

• npm

• gitlab

• . . .

70

Tools in Softwaretechnik

Tools in dieser Vorlesung (Auswahl)• Code-Editor (IDE)

• eclipse, IntelliJ, Android Studio, . . .

• Compiler• gcc, javac, . . .

• Management von Abhängigkeiten undBibliotheken

• Maven, Gradle

• Source Code Management• svn, git

• Statische Analyse• PMD• FindBugs• CheckStyle

• Automatisches Testen: JUnit

• Deployment und Virtualisierung:Docker

• Modellierung: VisualParadigm

• Continuous Intrgration: Jenkins, Gitlab

71

Umgang mit Tools

Entwicklungstools im Informatikstudium

• Schwerpunkt in Softwaretechnik und Softwareprojekt!

• z.T. eigene Einarbeitung nötig

Schwierigkeiten

• viele Tools

• komplexe Tools

• oft sehr system-spezifische Probleme

Hilfen

• Diskussion in Übungsgruppen

• Installation von Zweit-OS? Für vieleTools Linux einfacher

72

Mehr als Tools

Begriff „Tool“ =̂ Werkzeug

• konkretes Programm

• Vorgehensweise, Verfahren

Begriffe werden nicht immer sauber getrennt

„Tools“ im Software EngineeringVerfahren und Werkzeuge zur “Erstellung” komplexer Software-Produkte

• Planung und Entwurf

• Implementierung und Auslieferung (Deployment)

• Anpassung und Wartung

73

Qualität der Software

Externe Qualität Korrektheit, Stabilität,Performance (Effizienz, Skalierbarkeit),Benutzungsfreundlichkeit und Benutzbarkeit,Sicherheit (Safety, Security),Zuverlässigkeit, Verfügbarkeit, usw.

Interne Qualität Modularität, Strukturiertheit, Wartbarkeit, Wiederverwendbarkeit,Portierbarkeit, Interoperabilität, Programm-Dokumentation,systematischer Entwicklungsprozess, Konfigurationsmanagement,usw.

74

Qualität der Software I

Die Produktqualität wird von der Prozessqualität, d.h. der Güte desEntwicklungsprozesses, abgegrenzt. Für die Produktqualität unterscheiden wir zwischeninterner, externer und Gebrauchsqualität:

• Interne Qualität ist die Gesamtheit der Gütemerkmale aus einerherstellungsorientierten Sicht. Sie umfasst die Qualitätsattribute an alleZwischenprodukte der Entwicklung.

• Externe Qualität beinhaltet die technischen Gütemerkmale des Produkts aus einerexternen Sicht. Die externe Qualität wird i. Allg. durch Messungen und Testswährend der Ausführung der Software in einer definierten Umgebung bestimmt.

75

Qualität der Software II

• Gebrauchsqualität beschreibt die Gütemerkmale aus Sicht des Benutzers, dabei istnicht nur der Kontext der Benutzung zu berücksichtigen, sondern auch inwieweitder Benutzer die angestrebten Ziele mit der Software erreichen kann.

Process

quality

Internal

properties

External

properties

Quality

in use

influences influences influences

depends on depends ondepends on

Process Software product Effect of software product

Process

measures

Internal

measuresQuality in use measures

Context

of use

External

measures

76

Übersicht

Einleitung

Herausforderungen in derSoftwareentwicklung

Software Engineering als Lösung

Prinzipien des Software Engineering

Abstraktion

Strukturierung

Modularisierung

Kapselung

Separation of Concerns

Änderbarkeit

Inkrementalität

Gründlichkeit und Formalität

Beziehungen zu anderen Bereichen undDisziplinen

Professionelle Verantwortung

77

Übersicht

Einleitung

Herausforderungen in derSoftwareentwicklung

Software Engineering als Lösung

Prinzipien des Software Engineering

Abstraktion

Strukturierung

Modularisierung

Kapselung

Separation of Concerns

Änderbarkeit

Inkrementalität

Gründlichkeit und Formalität

Beziehungen zu anderen Bereichen undDisziplinen

Professionelle Verantwortung

78

Geschichte des Software Engineering

1968: Sogenannte Software-Krise

• Symptome• Software fehlerhaft,• Kostenschätzung für Software völlig fehlerhaft,• Termine kaum eingehalten,• Änderung von Programmen kaum möglich.

• Ursachen• Die Komplexität der zu konstruierenden Softwaresysteme überstieg die Möglichkeiten

der verfügbaren Methoden und Techniken zu ihrer Konstruktion bei weitem!• Insbesondere gab (und gibt) es Defizite im Management großer Teams.

• Ausweg• 1968: Prägung des Begriffs Software Engineering als Antwort auf die Software-Krise

79

Ziele des Software Engineering

Zentrales Ziel des Software EngineeringInterne Qualität erhöhen, um externe Qualität zu erreichen

EssenzQualität wird sowohl vom Produkt als auch vom Prozess seiner Konstruktion gefordert.

„Axiom“ im Software EngineeringGuter Entwicklungsprozess

=⇒ Gute interne Qualität=⇒ Gute externe Qualität

=⇒ Gute Nutzungsqualität

80

Charakterisierung: Software Engineering

Ingenieurmäßiges Entwickeln von Software

• Komplexe Softwaresysteme werden im Team entwickelt.

• Hohe Qualität der Software ist ein zentrales Ziel zur Erfüllung der• funktionalen (fachlichen) Anforderungen und der• nicht-funktionalen (technischen) Anforderungen.

Software Engineering hat etwas mit Beherrschung von Komplexität zu tun:

• Die zu konstruierende Software hat viele Komponenten.

• Die zu konstruierende Software wird von vielen Anwendern benutzt.

• Die zu konstruierende Software wird von vielen Entwicklern realisiert.

• Die zu konstruierende Software soll auf vielen Plattformen laufen.

81

Benötigte Fähigkeiten im Software Engineering

Zitat aus [GJM03, Seite 5]A software engineer must of course be a good programmer, be well-versed in datastructures and algorithms, and be fluent in one or more programming languages. Thesoftware engineer must be familiar with several design approaches, be able to translatevague requirements and desires into precise specifications, and be able to converse withthe user of a system in terms of the application rather than in „computerese“.

Einige daraus folgende, notwendige Fähigkeiten• Programmiertechniken

• Erstellung und Nutzung von Modellen / Spezifikationen auf verschiedenenAbstraktionsebenen

• Kommunikation mit Personen mit unterschiedlichen Zielsetzungen, Vorstellungen,Ausbildungen (Stakeholder)

• Arbeitsplanung und -koordination82

System- vs. Software-Entwicklung I

Software-Entwicklung

• Ausschließliche Betrachtung der Entwicklung von Software

Software Engineering ist die Lehre von den Methoden der Softwarekonstruktion. Zielder Disziplin ist die Entwicklung methodischer Hilfsmittel zur Erstellung korrekter undeffizienter Software. Zum Repertoire des Software Engineering gehören Prozesse,Modelle, Werkzeuge und Prinzipien. Dies orientiert sich am sogenanntenSoftwarelebenszyklus, in dem die Entwicklung in allen Phasen vorangetrieben wird. DasLeben eines komplexen Softwaresystems beginnt mit der Anforderungsanalyse, aufderen Basis ein erster Entwurf des Systems entsteht. Nach weiterenVerfeinerungsschritten kann eine Implementierung zunächst von Einzelkomponenten

83

System- vs. Software-Entwicklung II

erzeugt werden, die nach Einzeltests integriert werden, um das Gesamtsystem zurealisieren. Dem Integrationstest folgt das “Deployment”, also die Installation desSystems auf den Zielrechnern. Bis zur Außerdienststellung der Software wird dasSystem nun typsicherweise regelmäßig gewartet.

System-Entwicklung

• Entwicklung eines Systems, das aus Hardware- und Software-Komponenten bestehtund/oder in einen organisatorischen Kontext eingebunden ist.

• Bei der Entwicklung müssen zusätzliche Randbedingungen berücksichtigt werden.

84

System- vs. Software-Entwicklung III

Systems Engineering ist ein interdisziplinärer Ansatz, um erfolgreich Systeme zuentwickeln und zu realisieren. Dabei bezieht sich die Disziplin nicht auf einen speziellenBereich wie etwa Software, sondern erhebt einen allgemeineren Anspruch. Betrachtetman jedoch die Methoden des Systems Engineering, so fällt eine Übereinstimmung inmehreren Punkten auf:

• Projektmanagement, um die Organisation des Entwicklungsprozesses unterKontrolle zu halten;

• Anforderungsanalyse, Anforderungsdefinition und Anforderungsmanagement, dieGrundlage der Systementwicklung;

• Systementwurf (Modellbildung, Simulation und Bewertung), die Entwicklung desSystems;

85

System- vs. Software-Entwicklung IV

• Veränderungsmanagement, in der Entwicklung gibt es oft Veränderungen diesemüssen jedoch nachvollziehbar sein;

• Systemintegration (Schnittstellen-Spezifikation beziehungsweise-Produktentwicklung), um eine perfekte Einbindung in das nächst größere Systemszu gewährleisten;

• Systemverifikation und -validation um sicherzustellen, dass die Anforderungenerfüllt wurden;

• Risikomanagement (also zum Beispiel Fehlerbäume, Fehleranalyse, FMEA), derEinfluss von Risiken sollten bei der Systementwicklung minimiert werden;

• Nachhaltige Entwicklung, anpassbar sollte jedes System entwickelt werden.

86

System- vs. Software-Entwicklung V

Der wesentliche Unterschied zum Software Engineering besteht in einer deutlichstärkeren Konzentration auf den Systemgedanken, d.h. der Blick auf das Ganze steht inallen Schritten im Vordergrund. Dabei werden auch die Schnittstellen zu anderen alssoftwaretechnischen Systemkomponenten (insbesondere Mensch, Organisation, Umwelt)umfassend berücksichtigt. Dies drückt sich durch eine Vielzahl vonManagement-Funktionen aus, die sowohl zu Projektbeginn als auch während derLaufzeit eine ständige Kontrolle des Gesamtprojekts gewährleisten sollen.

Software Systems Engineering kombiniert nun die beiden Disziplinen miteinander, indemdie eher übergreifenden Funktionen des Systems Engineering in die softwarebezogenenProzesse, Methoden, Werkzeuge und Prinzipien integriert.

87

Worum geht es also?

• Software Engineering dient zum Konstruieren von Softwaresystemen nachbestimmten Prinzipien.

• Wir verwenden einen Prozess zur Konstruktion dieser Systeme:• Arbeitsteilung, Prüfungen bei Übergabe.

• Anforderungen an• den Entwicklungsprozess, u.a. Effizienz, bzgl. Kosten,• das Produkt, u.a. Erfüllung von Qualitätskriterien.

• Wir benötigen Werkzeuge, um diesen Prozess zu unterstützen.

88

Der Softwareentwicklungsprozess

Machbarkeits-studie

Anforderungs-analyse

System-entwurf

Codieren & Modultest

Integrations- & Systemtest

Auslieferung & Installation

Wartung & Betrieb

→ LE 6

→ LE 7

→ LE 4, 5, 8

→ LE 9

89

Übersicht

Einleitung

Herausforderungen in derSoftwareentwicklung

Software Engineering als Lösung

Prinzipien des Software Engineering

Abstraktion

Strukturierung

Modularisierung

Kapselung

Separation of Concerns

Änderbarkeit

Inkrementalität

Gründlichkeit und Formalität

Beziehungen zu anderen Bereichen undDisziplinen

Professionelle Verantwortung

90

Übersicht

Einleitung

Herausforderungen in derSoftwareentwicklung

Software Engineering als Lösung

Prinzipien des Software Engineering

Abstraktion

Strukturierung

Modularisierung

Kapselung

Separation of Concerns

Änderbarkeit

Inkrementalität

Gründlichkeit und Formalität

Beziehungen zu anderen Bereichen undDisziplinen

Professionelle Verantwortung

91

Prinzipien des Software Engineering

Prinzip Grundsatz, dem man seinem Handeln zugrunde legt.Noch unabhängig von konkreten Methoden und Techniken

http://prinzipien-der-softwaretechnik.blogspot.de/

92

Komplexität als Herausforderung

Beten wir Komplexität an? https://heise.de/-4170914

93

Abstraktion in der Physik (Zeichnung: Dr. Christian Jäkel)

Quelle: http://www.zeichen.uni-kiel.de/geschichte/abstraktion/

94

Abstraktion in der Physik (Prof. Dr. Reimer Lincke)

„Bekanntlich ist es ein zentrales Arbeitsprinzip der Physik, jedes reale Problem zuerstauf das Wesentliche zu reduzieren und reale Abweichungen von dieser Idealisierung erstspäter als ’Störung’ zu berücksichtigen.

Mein Mitarbeiter Dr. Christian Jäkel hat diesen Abstraktionsvorgang für meineVorlesung illustriert: das gegebene Realproblem ’War das Huhn zuerst da oder das Ei?’ist für einen Physiker natürlich viel zu kompliziert.

Zuerst lässt er die Federn des Huhnes weg, dann approximiert er die tatsächlichenFormen durch einfachere geometrische Körper, am Ende durch elementar zuberechnende Würfel und Quader.

Schließlich wird das Problem noch auf zwei Dimensionen reduziert.

Der Physiker geht nun davon aus, dass die Erkenntnisse, die er an dieser idealisiertenSituation gewinnt, dann das reale Problem (nach einigen Korrekturen) angemessenbeschreibt.“

Quelle: http://www.zeichen.uni-kiel.de/geschichte/abstraktion/

95

Abstraktion vom Unwichtigen

Wichtigkeit und Unwichtigkeit ist relativ zum Zweck der Abstraktion

Realität Modell

verkürzendeEigenschaft

erweiternde Eigenschaft

Ergänzte Eigenschaften :

- Längen- und Breitengrade- Legende

, z.B.Verkürzende Eigenschaften, z.B.:

- Temperatur- Luftfeuchtigkeit

Erde Landkarte

96

Unterschiedliche Sichten erfordern unterschiedliche Abstraktionen [Boo94; Boo+07]

“The entire history of software engineering is that of the rise in levels of abstraction.”[Grady Booch]

Warum?

97

Prinzip: Abstraktion

Abstraktion bedeutet Verallgemeinerung:

• Zerlegung in Hinblick auf die Identifizierung wichtiger und (zunächst) wenigerwichtiger Aspekte

• Statt direkt ein spezielles Problem zu lösen, kann es sinnvoll sein, zunächst einallgemeineres Problem zu lösen, dessen Lösung dann als Grundlage zur Lösung desspeziellen Problems verwendet wird.

• Abstraktion ist notwendig, um Komplexität meistern zu können.

• Vielzahl von Abstraktionen erfordern eine weitere Gliederung:Modularisierung, Kapselung, Separation of Concerns

• Eine Abstraktion kann auch verschiedene Sichten auf ein zu lösendes Problemliefern.

98

Modell als Abstraktion I

Ein Modell hat nach [Sta73] grundsätzlich

• einen Zweck,

• einen Bezug zu einem Original, und

• abstrahiert bestimmte Eigenschaften des Originals.

Aufgrund der Immaterialität von Software, die bei einem weit gefassten Modellbegriffauch ein Modell von sich selbst bzw. den durch sie beschriebenen Abläufen ist, bestehenzwischen dem Original und seinen Modellen vielfältige Beziehungen, die sich auch durchden jeweiligen Einsatzzweck bemerkbar machen. So werden Modelle nicht nur zurErringung eines substantiellen Anforderungs- bzw. Systemverständnisses, sondern häufigauch zur konstruktiven Generierung von Code oder zur qualitätssichernden Ableitungvon Tests eingesetzt.

99

Modell als Abstraktion in der Softwaretechnik

Modell

Programm

Reale Welt

Abstrahiert vonImplementierungs-Details

Abstrahiert von un-wichtigen Details

@@

@@@I

@@@

@@R

101

Achtung: „Unwichtige Details“?

102

Modellierung und Abstraktion

[Kra07]Abstraktionsfähigkeit ist eine derKern-Qualifikationen für die Informatik,bzw. für ein Informatikstudium.Bitte lesen Sie sich dieses Papier für dieVorlesung durchWas ist Ihre Meinung dazu?

IS ABSTRACTION THE KEYTO COMPUTING?

Why is it that some software engineers and computer scientists are able to produce clear, elegant designs and programs, while others cannot?

Is it possible to improve these skills through education and training? Critical to these questions is the notion of abstraction.

For over 30 years, I have been involved in teaching and research in computer science and software engineering.My teaching experience ranges from courses in programming,to distributed systems, distributed algorithms, concurrency,and software design. All these courses require that students areable to perform problem solving, conceptualization, modeling,and analysis. My experience is that the better students are clearly able to handle complexity and to produceelegant models and designs. The same students are also able to cope with the complexities of distributed algorithms, theapplicability of various modeling notations, and other subtle issues.

By JEFF KRAMER

36 April 2007/Vol. 50, No. 4 COMMUNICATIONS OF THE ACM COMMUNICATIONS OF THE ACM April 2007/Vol. 50, No. 4 37

103

Prinzip: Strukturierung

Arten der Strukturierung

• zeitliche Strukturierung:Anforderungsanalyse / Entwurf / Programmierung / Test

• qualitative Strukturierung:Effizienz / Robustheit / Korrektheit

• perspektivische Strukturierung:Verwendung von Datenstrukturen / Datenfluss / Kontrollfluss

• Dekomposition (Strukturierung in Bestandteile):Komponente 1, Komponente 2Diese Strukturierung ist so wesentlich, dass sie unter dem Prinzip Modularisierunggesondert betrachtet wird!

Strukturierung ist wichtig für Teamarbeit und Arbeitsteilung, um Verantwortlichkeitenzuordnen zu können. 104

Zyklenfreiheit und Hierarchisierung

Semantik der Pfeile?

105

Modularisierung: Produkteigenschaften

Kohäsion Innerhalb einzelner Module sollte ein enger Zusammenhang bestehen.⇒ hohe Modul-Kohäsion

Kopplung Zwischen Modulen sollten möglichst wenig Abhängigkeiten bestehen.⇒ geringe inter-modulare Kopplung

Modularisierung hilft Programme zu verstehen

• Es ist leichter mit Änderungen umzugehen (Information Hiding, Kapselung).

• Es ist leichter Verantwortlichkeiten zuzuordnen (Separation of Concerns).

• Es ist leichter bereits implementierte und evtl. benutzte Modulewiederzuverwenden.

106

Kohäsion und Kopplung

hohe Kohäsion /geringe Kopplung

geringe Kohäsion /geringe Kopplung

geringe Kohäsion / hohe Kopplung

hohe Kohäsion / hohe Kopplung

107

Prinzip: Modularisierung

bottom up Zuerst werden unabhängige Module konstruiert, die dann später‚zusammengebaut‘ werden.⇒ Zusammensetzbarkeit

top down Zuerst wird das Gesamtsystem in unabhängige Module aufgeteilt, die danneinzeln implementiert werden.⇒ Zerlegbarkeit

108

Prinzip: Kapselung

Die Kapselung dient dem “Information Hiding.”

• Begrenzen der Details (Geheimnisse) eines Moduls, die von außen sichtbar sind,• Secrets are key to sustainability

• Abgrenzen von Verantwortungsbereichen,

• Verringern von Abhängigkeiten zwischen Modulen,

• Zusammenhang mit anderen Prinzipien:• Modularisierung wird unterstützt.• Abstraktionen werden abgegrenzt.

109

Prinzip: Separation of Concerns

Trennung von Belangen / Zuständigkeiten:

• Aufteilen in unabhängige Belange / Aspekte, z.B.• in Kontroll- und Datenfluss,• in fachlich und technisch geprägte Lösungsteile,• nach Produkteigenschaften,• nach externen und internen Qualitätskriterien.

110

Separation of Concerns

“Let me try to explain to you, what to my taste is characteristic for all intelligent thinking.It is, that one is willing to study in depth an aspect of one’s subject matter in isolation forthe sake of its own consistency, all the time knowing that one is occupying oneself only withone of the aspects. We know that a program must be correct and we can study it fromthat viewpoint only; we also know that it should be efficient and we can study itsefficiency on another day, so to speak. In another mood we may ask ourselves whether,and if so: why, the program is desirable. But nothing is gained—on the contrary!—bytackling these various aspects simultaneously. It is what I sometimes have called ‘theseparation of concerns’, which, even if not perfectly possible, is yet the only availabletechnique for effective ordering of one’s thoughts, that I know of. This is what I mean byfocussing one’s attention upon some aspect: it does not mean ignoring the other aspects, itis just doing justice to the fact that from this aspect’s point of view, the other is irrelevant.It is being one- and multiple-track minded simultaneously.”

E.W. Dijkstra, On the role of scientific thought, 1974

111

Prinzip: Änderbarkeit

Software ist Gegenstand von Änderungen.

Typische Ursachen für Änderungen:

Korrektive Wartung Beseitigung von Fehlern

Perfektive Wartung Verbesserung nicht-funktionaler Eigenschaften

Adaptive Wartung Anpassung der Funktionalität wegen sich ändernderRahmenbedingungen

Inkrementelle Wartung Erweiterung der Funktionalität wegen Erkenntnisgewinnwährend der Entwicklung

112

Prinzip: Inkrementalität

• Schrittweises vorgehen, Rückkopplung nach jedem Schritt

• Anders sind große Projekte oft nicht zu organisieren

• Erlaubt frühzeitiges Feedback vom Kunden

Beispiel:

• es werden einzelne Software-Komponenten entwickelt und integriert, bevor alleKomponenten entwickelt werden

113

Prinzip: Gründlichkeit und Formalität

Aspekte u.a.:

• Formale Anforderungsspezifikation

• Formale Dokumentation des Software-Prozesses und seiner Ergebnisse

• Formaler Entwurf

• Formale Verifikation der Korrektheit von Software

Formalität ist (zumeist) Voraussetzung für einen Werkzeugeinsatz.

Formalität benötigt i.A. mathematische Fertigkeiten und zumeist auch eine gewisseDisziplin.

114

Übersicht

Einleitung

Herausforderungen in derSoftwareentwicklung

Software Engineering als Lösung

Prinzipien des Software Engineering

Abstraktion

Strukturierung

Modularisierung

Kapselung

Separation of Concerns

Änderbarkeit

Inkrementalität

Gründlichkeit und Formalität

Beziehungen zu anderen Bereichen undDisziplinen

Professionelle Verantwortung

115

Übersicht

Einleitung

Herausforderungen in derSoftwareentwicklung

Software Engineering als Lösung

Prinzipien des Software Engineering

Abstraktion

Strukturierung

Modularisierung

Kapselung

Separation of Concerns

Änderbarkeit

Inkrementalität

Gründlichkeit und Formalität

Beziehungen zu anderen Bereichen undDisziplinen

Professionelle Verantwortung

116

Beziehungen zu anderen Bereichen der Informatik

Programmierung und Programmiersprachen

• Unterstützung für Modularität spielt eine zentrale Rolle.

• Strenge (statische) Typisierung erhöht die Zuverlässigkeit.

• „Generierung“ von Programmen aus formalen Spezifikationen (z.B.Compiler-Compiler oder modellgetriebene Softwareentwicklung)

• Domänenspezifische Sprachen (Domain Specific Languages, DSLs) enthaltenvorgefertigte Elemente für bestimmte Anwendungsbereiche.

• Beispielprojekte dazu:• Xbase: http://kosse-sh.de/projekte/xbase/• MENGES: http://menges.informatik.uni-kiel.de/• Sprat: http://www.sprat.uni-kiel.de/en/

117

Beziehungen zu anderen Bereichen der Informatik

Datenbanksysteme

• Die Trennung von Modellbildung und Implementierung hat hier seine Ursprünge.Der Begriff „Modell“ wird hier jedoch nicht immer konsistent verwendet.

• Modellierung in Software Engineering und Datenbanken ähnlich:• Vergleich Klassendiagramm ↔ ER-Diagramm• starke inhaltliche Bezüge, siehe ORM später

• Datenbanksysteme können zur Integration verschiedenerSoftware-Entwicklungswerkzeuge dienen.

118

Beziehungen zu anderen Bereichen der Informatik

Theoretische Informatik

• Entwicklung von Modellen zur formalen Spezifikation

• Problem: Reale Systeme sind so komplex, dass sie praktisch nicht vollständigformal beschrieben werden können.

• Ausweg: Kompositionalitätsergebnisse

• In der Praxis werden überwiegend semi-formale Methoden eingesetzt (z.B. dieUML).

• Formale Methoden spielen jedoch bei der Entwicklung sicherheitskritischer Systemeeine wichtige Rolle und werden dort auch eingesetzt.

119

Beziehungen zu anderen Disziplinen

Wirtschaftswissenschaften

• Betriebswirtschaftliche AspekteLohnt sich EDV finanziell?

• Volkswirtschaftliche AspekteWelche informationstechnische Infrastruktur benötigt die Republik?

• Muss die Softwareindustrie durch den Staat bzw. die EU subventioniert werden?Beispiel: „Konferenz - Förderung der Künstlichen Intelligenz“ in SH, März 2019

Psychologie

• User Experience: Nutzungsschnittstellen und Ergonomie• Organisation, Personalführung, Projektmanagement• Persönliche Qualifikation (Soft Skills): Kommunikation, Diskussionsleitung,

Projektleitung, Vortragspräsentation120

Unterschiede zu klassischen Ingenieurdisziplinen

Ingenieure (Bau, Elektro, Maschinenbau)

• Haben zumeist präzise Anforderungen an die zu entwickelnden Systeme,z.B. Abschalteinrichtung in der Motorsteuerung.

• Verwenden Mathematik,z.B. Differentialgleichungen.

• Arbeiten nach etablierten Prinzipien und Prozessen.

Die Informatik kommt sowohl aus der Mathematik als auch aus denIngenieurwissenschaften:

• Mathematik: Produktbezogene Strukturwissenschaft

• Ingenieurwesen: Eher Prozessbezogen

121

Übersicht

Einleitung

Herausforderungen in derSoftwareentwicklung

Software Engineering als Lösung

Prinzipien des Software Engineering

Abstraktion

Strukturierung

Modularisierung

Kapselung

Separation of Concerns

Änderbarkeit

Inkrementalität

Gründlichkeit und Formalität

Beziehungen zu anderen Bereichen undDisziplinen

Professionelle Verantwortung

122

Übersicht

Einleitung

Herausforderungen in derSoftwareentwicklung

Software Engineering als Lösung

Prinzipien des Software Engineering

Abstraktion

Strukturierung

Modularisierung

Kapselung

Separation of Concerns

Änderbarkeit

Inkrementalität

Gründlichkeit und Formalität

Beziehungen zu anderen Bereichen undDisziplinen

Professionelle Verantwortung

123

Professionelle Verantwortung

Software-Entwickler sollten sich nicht nur mit technischen Fragestellungen beschäftigen.Sie haben auch ethische, soziale und professionelle Verantwortung. Für viele Tätigkeitengibt es keine klaren Vorgaben:

• Entwicklung von militärischen Systemen

• Entwicklung von Systemen zur Überwachung

• Was ist das Beste für die Profession?

124

Software Engineering Code of Ethics I

ACM / IEEE Computer Society:

PUBLIC Software engineers shall act consistently with the public interest.

CLIENT / EMPLOYER Software engineers shall act in a manner that is in the bestinterests of their client and employer consistent with the publicinterest.

PRODUCT Software engineers shall ensure that their products and relatedmodifications meet the highest professional standards possible.

JUDGMENT Software engineers shall maintain integrity and independence intheir professional judgment.

125

Software Engineering Code of Ethics II

MANAGEMENT Software engineering managers and leaders shall subscribe to andpromote an ethical approach to the management of softwaredevelopment and maintenance.

PROFESSION Software engineers shall advance the integrity and reputation of theprofession consistent with the public interest.

COLLEAGUES Software engineers shall be fair to and supportive of their colleagues.

SELF Software engineers shall participate in lifelong learning regarding thepractice of their profession and shall promote an ethical approach tothe practice of the profession.

126

Software Engineering Code of Ethics III

Quelle: http://www.computer.org/web/education/code-of-ethics

Update:https://ethics.acm.org/code-2018

Kommentare?

127

Spezifischer

Recognize when a computer system is becoming integrated into theinfrastructure of society, and adopt an appropriate standard of care for thatsystem and its users.

When organizations and groups develop systems that become an important part ofthe infrastructure of society, their leaders have a responsibility to be good stewardsof these socially integrated systems.Part of that stewardship requires establishingpolicies for fair system access, including for those who may have been excluded.. . .Continual monitoring of how society is using a system will allow theorganization or group to remain consistent with their ethical obligations outlined in theCode. As the level of adoption changes, there are likely to be changes in theethical responsibilities of the organization or group. When appropriate standards ofcare do not exist, computing professionals have a duty to ensure they are developed.

128

Aktuelle Beispiele

Gesellschaftliche Fragen

• „Fake News“ und politische Beeinflussung

• Datenschutz, Big Data Analysen von Nutzerdaten

• „Attention is media’s true currency“

129

Verantwortung von Software-Ingenieuren: Entwicklung militärischer Systeme

1983: SDI (Strategic Defense Initiative von Ronald Reagan)⇒ „Software ist die Achillesferse von SDI“David L. Parnas (SDI-Software-Berater bis 1985)

Seit 2001: NMD (National Missile Defence von George W. Bush) – Nationale Raketenabwehr der USA2007–2009 Planungen der USA zur Installation einer Raketenabwehr in Polen und Tschechien; wurden

dann jedoch wieder verworfen.2010 Diskussion in der NATO zur Installation einer europäischen Raketenabwehr: Das Medium

Extended Air Defense System (MEADS)2011 Die USA und Deutschland steigen aus MEADS aus.

Herbst 2011 Lockheed Martin gibt MEADS nicht auf: erster Testschuss am 17.11.2011April 2014 Im Zuge der Krise in der Ukraine 2014 forderte der SPD-Wehrexperte Rainer Arnold die

Luftverteidigung als besondere deutsche Schwerpunktfähigkeit zu sichern und unter Rückgriffauf die Entwicklungsergebnisse MEADS zukunftsfähig zu machen.

Juni 2015 Die Verteidigungsministerin kündigt die Beschaffung von MEADS an. Von der Leyen sprachvon einer „Käseglocke“, die eine Großstadt oder ein Feldlager schützen könne.

März 2017 DPA: „Die Beschaffung des mehrere Milliarden Euro teuren RaketenabwehrsystemsMEADS für die Bundeswehr verzögert sich.“

. . . To be continued

130

Berufsaussichten von Software-Ingenieuren

Rank Job TitleNumber ofPostings perMillion

Average BaseSalary

Average Growth inPostings 2013-2016

1Full StackDeveloper

641 $110,770 122%

2 Data Scientist 360 $129,938 108%

3DevelopmentOperationsEngineer

731 $123,165 106%

4SalesforceAdministrator

80 $89,702 103%

5 IT Engineer 41 $85,563 89%

6SalesforceDeveloper

230 $108,089 83%

7 Quality Engineer 311 $71,111 83%

8Digital ProductManager

58 $73,169 75%

9 Cloud Engineer 217 $118,878 67%

10ManagementConsultingAnalytics Manager

47 $90,994 66%

http://spectrum.ieee.org/view-from-the-valley/at-work/tech-careers/software-engineering-jobs-dominate-list-of-best-careers-for-2017

131

Lernziele

• Lernen aus den Fehlern der Vergangenheit• Würdigen, dass ein planmäßiges Vorgehen bei der Entwicklung komplexer

Softwaresysteme im Team sinnvoll ist.Bei der Entwicklung kleiner „Progrämmchen“ ist das i.A. nicht erforderlich.

• Wissen, dass die Fähigkeit zur Zerlegung komplexer Probleme schon Teil derLösung ist. Insbesondere den Unterschied verstehen zwischen

• Programmieren im Kleinen,• Programmieren im Großen.

• Erkennen, dass vielfältige Beziehungen zu anderen Bereichen der Informatik und zuanderen Disziplinen existieren.

• Software-Entwickler haben auch Verantwortung.• Ein Verständnis der Prinzipien ist wichtiger als das Kennen konkreter Methoden.• Die konkreten Methoden ändern sich, die Prinzipien bleiben.

Trotzdem sehen wir uns im Folgenden einige konkrete Methoden an . . .132

Lernziele

ZielQualität ist das Ziel.

HerausforderungKomplexität und Evolution.

133

References I

Balzert, Helmut (2011). Lehrbuch der Softwaretechnik: Entwurf, Impementierung,Installation und Betrieb. 3. Spektrum Akademischer Verlag.

Booch, G. (1994). Object-Oriented Analysis and Design with Applications. 2nd.Benjamin/Cummings.

Booch, G., R.A. Maksimchuk, M.W. Engel, B.J. Young, J. Conallen und K.A. Houston(2007). Object-Oriented Analysis and Design with Applications. 3nd.Addison-Wesley. ISBN: 0-201-89551-X.

Brügge, B. und A. Dutoit (2010). Object Oriented Software Engineering Using UML,Patterns, and Java. 3rd. Prentice Hall. ISBN: 978-0138152215.

134

References II

Bundestag (2006). Verfügbarkeit der webbasierten Hartz-IV-Software A2LL.http://www.heise.de/newsticker/meldung/88318,http://dip.bundestag.de/btd/16/049/1604938.pdf.

Ghezzi, C., M. Jazayeri und D. Mandrioli (2003). Fundamentals of SoftwareEngineering. 2nd. Prentice Hall.

Grechenig, Thomas, Mario Bernhart, Roland Breiteneder und Karin Kappel (2010).Softwaretechnik. Pearson Studium.

Hasselbring, Wilhelm (2018). Softwaretechnik Folienskript.Standard Glossary of Software Engineering (1990). IEEE Std 610.12-1990. The Institute

of Electrical und Electronics Engineers. New York.Kecher, C. und A. Salvanos (2015). UML 2.5: Das umfassende Handbuch. Galileo

Computing. Rheinwerk Verlag GmbH. ISBN: 9783836229777.

135

References III

Kramer, Jeff (2007). “Is abstraction the key to computing?” In: 50.4, S. 36–42. DOI:10.1145/1232743.1232745.

Lipp, Moritz, Michael Schwarz, Daniel Gruss, Thomas Prescher, Werner Haas,Stefan Mangard, Paul Kocher, Daniel Genkin, Yuval Yarom und Mike Hamburg(2018). “Meltdown”. In: ArXiv e-prints. arXiv: 1801.01207.

Ludewig, J. und H. Lichter (2013). Software Engineering: Grundlagen, Menschen,Prozesse, Techniken. dpunkt.verlag. ISBN: 9783864912993. URL:https://books.google.de/books?id=OMtNDAAAQBAJ.

Podelski, Andreas und Bernd Westphal (2017). Softwaretechnik / Software-Engineering.

Rupp, C., S. Queins u. a. (2012). UML 2 glasklar: Praxiswissen für dieUML-Modellierung. 4. Auflage. Hanser. ISBN: 978-3-446-43057-0.

136

References IV

Sommerville, Ian (2018). Software Engineering. 10. Auflage.http://software-engineering-book.com. Pearson. ISBN: 978-3-86326-835-0.

Stachowiak, H. (1973). Allgemeine Modelltheorie. Wien: Springer-Verlag.

137