Software Engineering: Definition und Arten

Software Engineering Definition

• Software Engineering bezieht sich auf die Anwendung eines systematischen, disziplinierten und quantifizierbaren Ansatzes für die Entwicklung, den Betrieb und die Wartung von Software.
• Es ist die Anwendung der Ingenieurwissenschaften auf Software.

Softwarearten

• Anwendungssoftware wie Texteditoren und Browser
• Systemsoftware wie Betriebssysteme, Firmware und Treiber, die keine direkte Nutzerinteraktion erfordern
• Software as a Service (SaaS) wie Serverprogramme, auf die über Browser oder Remote Shell zugegriffen wird

Eigenschaften von Software

• Erreichbarkeit über Netzwerke erhöht die Angriffsfläche.
• Fehlende physische Grenzen erschwert die Trennung von Subsystemen.
• Geringe Vertriebskosten ermöglichen eine einfache Fehlerbehebung.
• Mangelnde Kontrolle über Updates kann schnell zur Veralterung führen.
• Kein Verschleiß, aber veränderliche Umgebungen bringen unvorhergesehene Anforderungen mit sich.
• Lange Lebenszeiten sind typisch.
• Eigenschaften sind oft schwierig zu messen.

Bereiche des Software Engineering

• Anforderungsanalyse
• Domain-Driven Design
• Entwicklung inklusive Entwicklungswerkzeuge, Validierung, Designprinzipien, Entwurfsmuster und Architektur
• Betrieb

Entwicklungswerkzeuge - IDEs

• Bieten Hilfestellung durch Dateiexplorer, Syntaxhervorhebung, Codevervollständigung, Problemindikatoren, Codenavigation, Refactoring, Validierung, Debugging und Versionskontrolle
• Beinhalten Terminal/Shell

Shell

• Interaktive Programmiersprache zur Verwaltung von Prozessen und Dateien
• Ermöglicht Automatisierung von Entwicklungsaufgaben und das Zusammenfassen von Befehlen in Skripten
• Gute Dokumentation erleichtert die Einarbeitung.
• Das Format ist: BEFEHL [FLAGS] ARGUMENTE, z.B. ls --recursive --ignore=*.png dir1 dir2 dir3

Nützliche Shell-Befehle

• touch: Erzeugt eine leere Datei
• ls: Listet Dateien auf
• mv: Verschiebt Dateien
• cp: Kopiert Dateien
• rm: Löscht Dateien
• find: Sucht Dateien
• chown/chmod: Ändert Dateizugriffsrechte
• cat: Hängt Dateiinhalte aneinander
• wc: Zählt Wörter
• sort: Sortiert
• grep: Durchsucht Text
• echo: Gibt Text aus
• head/tail: Gibt Anfang/Ende eines Textes aus
• less: Gibt Teile eines langen Textes aus
• tee: Gibt Text in Datei und Shell aus
• pwd: Gibt das aktuelle Verzeichnis aus
• mkdir: Erstellt ein Verzeichnis
• cd: Ändert das Verzeichnis
• rmdir: Löscht ein Verzeichnis
• Input-/Output-Redirection: Umlenkung der Standardein- und ausgabe

Pipes und Redirects

• Pipes und Redirects verknüpfen und verändern Standardein-/ausgaben
• |: Leitet die Ausgabe von Befehl 1 in die Eingabe von Befehl 2 um.
• 1>: Leitet die Ausgabe eines Befehls in eine Datei um.
• 2>: Leitet Fehlermeldungen eines Befehls in eine Datei um.
• &>: Leitet sowohl Ausgabe als auch Fehlermeldungen eines Befehls in eine Datei um.
• <: Leitet den Inhalt einer Datei als Eingabe in einen Befehl um.

Fehlerbehandlung in der Shell

• Erfolgt durch Exit-Codes (0-255)
• 0: Erfolg
• 1-255: Fehler, wobei der Wert den Typ des Fehlers angibt.
• Es gibt auch Variablen, Arithmetik, Bedingungen und Schleifen

Entwicklungsprozesse

• Systematischer Ansatz zum Entwerfen, Implementieren, Betreiben und Warten von Software
• Ziel ist es, Software mit dem höchsten Wert zu den geringsten Kosten zu liefern.
• Die Prozessgestaltung wird durch Kollaboration, Skalierbarkeit, Konsistenz, Qualitätssicherung, Risikomanagement und kontinuierliche Verbesserung erreicht.

Aktivitäten im Prozess

• Anforderungsanalyse
• Design
• Entwicklung
• Validierung
• Betrieb
• Wartung

Prozessmodelle: Traditionell vs. Agile

• Traditionell:*
• Anforderungen müssen klar definiert und unveränderlich sein.
• Validierung erfolgt erst nach der Implementierung.
• Software geht erst am Ende des Prozesses in Betrieb.
• Agile:*
• Kürzere Entwicklungszyklen (Sprints/Iterationen) ermöglichen bessere Reaktion auf Veränderungen.
• Kontinuierliches Feedback durch Zyklusstruktur.
• Diese Modelle sind veraltet; agile werden eher benutzt.

Anforderungsanalyse

• Siehe Requirements Engineering

Architektur Definition

• Architektur beschreibt das übergeordnete Design/Organisation von Software (Komponenten und Interaktionen.)
• Ermöglicht Anforderungserfüllung, Qualität, Wartbarkeit und Erweiterbarkeit.

Dimensionen der Softwarearchitektur

• Operational: Verfügbarkeit, Skalierbarkeit, Performance (Eigenschaften der Ausführung)
• Strukturell: Erweiterbarkeit, Wartbarkeit, Nachnutzbarkeit, Konfigurierbarkeit (Eigenschaften des Codes)
• Übergreifend: Datenschutz, Sicherheit, Lokalisierung, Bedienbarkeit (betreffen alle Teile der Software)

Architekturstil Definition

• Komponenten der Software, wie sie organisiert und voneinander abhängig sind und miteinander kommunizieren
• Beispiele sind Schichten, Pipes & Filter, Service-orientiert, Broker und Microservices
• Jeder Stil hat Vor- und Nachteile.

Schichtenarchitektur

• Trennung der Aufgaben erhöht Wartbarkeit und Testbarkeit.
• Nutzeranfragen werden von oben nach unten durch Schichten gereicht.
• Es gibt geschlossene (Schicht muss passiert werden) und offene Schichten (kann umgangen werden).
• Architecture-Sinkhole Anti-Pattern: Evtl. unnötiges Durchreichen.
• Keine vertikale Skalierung: Verteilung auf mehrere Server schwer.

Service-orientiert

• Komponenten sind in mehreren, getrennten Diensten organisiert.
• Unabhängige Entwicklung, Wartung, Einsatz und Technologien.
• Kommunikation über Message Bus.
• Skalierung durch Hinzufügen neuer Dienste.
• Datenflüsse schwer nachvollziehbar, Overhead für Kommunikation.

Pipes & Filter

• Filter transformieren Daten, die durch Pipes verbunden sind.
• Filter sind eigenständig, unabhängig und zustandslos.
• Parallele Laufzeit erhöht Skalierbarkeit, niedriger Speicherbedarf & Aufgabentrennung durch Unabhängigkeit.
• Zwischenspeicherung/Serialisierung aufwändig, teilweise unpraktisch, komplizierte Fehlerbehandlung.

Domain-Driven Design

• Es zielt auf die Entwicklung nahe an der Problemdomäne ab, reduziert "Cruft" und erleichtert die Kommunikation mit Stakeholdern.
• Es erstellt ein Domänenmodell, identifiziert Kernkonzepte, generalisiert und erarbeitet deren Eigenschaften unter Nutzung der Domäne-Vokabulars

Designprinzipien

• Unterscheidung in:
  • Komplexitätsbewältigung: Keep it simple, stupid; Trennung von Seiteneffekten; Vermeiden mehrdeutiger Dateitypen; Liskovsches Substitutionsprinip
  • Änderungsauswirkungen minimieren: Don't repeat yourself; Single-Responsibility-Prinzip; Hohe Kohäsion, niedrige Kopplung; Interface-Segregation-Prinzip
• Keep it simple, stupid! (KISS): Reduziert unbeabsichtigte Komplexität, passt die Software an und erkennt, dass essentielle Komplexität aus der Problemdomäne entsteht und nicht reduziert werden kann.

Gründe für hohe Komplexität

• Mangelnde Dokumentation, schlechte Architekturentscheidungen, voreilige Optimierung, unerfahrene Entwickler und Softwarerevolution.

Bewältigung von Komplexität

• Funktionalem Programmierstil für kürzeren, weniger komplexen Code.
• Komplexitätsmetriken: Fan-in, Fan-out, Codegröße, Zyklomatische Komplexität, Schachtelungstiefe und Kopplung.
• Komplexe Komponenten erkennen: Statische (Komponenten im Projekt) & Longitudinale Analyse (Analyse über Zeitraum, Trends identifizieren)

Seiteneffekte

• Häufige Quelle von Komplexität und Fehlern.
• Sollten von der Geschäftslogik getrennt werden.
• Seiteneffektfreier Code ist leichter zu verstehen.
• Methoden mit Seiteneffekten können nicht-deterministisch sein.
• Typische Seiteneffekte: Mutation von Variablen/Datenstrukturen, Systemzustand auslesen, Netwerkanfragen und Lesen/Schreiben von Dateien/Datenbanken.

Mehrdeutige Datentypen

• Semantische Namen vermeiden Mehrdeutigkeit und verbessern das Verständnis des Codes.
• Das Liskovsche Substitutionsprinzip (LSP) ist ein starkes verhaltensbasiertes Subtyping.

Don't repeat yourself (DRY)

• Vermeidet Wiederholungen im Code, da Änderungen an mehreren Stellen erforderlich wären.
• Dies wird durch Ersetzen wiederholter Ausdrücke durch Variablen, Wrapper-Methoden und Verschieben von Code in Superklassen erreicht.

Single-Responsibility-Prinzip

• Jede Klasse/Modul sollte genau eine Verantwortlichkeit haben, um Änderungen kleiner zu halten.
• Tätigkeitsverantwortlichkeit: Führt eine Aufgabe aus
• Wissensverantwortlichkeit: Stellen Informationen für andere zur Verfügung
• Bei mehreren Aufgaben: Refactoring betreiben und Aufgaben auskoppeln

Hohe Kohäsion, niedrige Kopplung

• Kopplung: Klassen, die sich häufig ändern
• Kohäsion: Klassen mit mehreren Verantwortlichkeiten
• Hohe Kopplung ist problematisch: Kaskadierende Änderungen, schwierig zu verstehen, schlecht nachnutzbar und wenig modular.
• Arten von Kopplung: Attribute, (Teil-)Ausdrücke, Methodenaufrufe, Methoden, die von einer anderen Instanz verwendet werden, Subtypisierung und Metrik CBO (Coupling between Objects).
• Kohäsion bezieht sich auf die Zusammengehörigkeit der Methoden einer Klasse; niedrige Kohäsion bedeutet, dass Methoden wenig miteinander zu tun haben und aufgespaltet werden sollten.
• Metrik: LCOM (Lack of Cohesion of Methods).
• Interface-Segregation-Prinzip (ISP): Große Interfaces in kleinere aufspalten, damit Nutzer nötige Funktion besser erkennen

Entwurfsmuster

• Bewährte Lösungen für häufige Probleme
  • Vermeiden „das Rad neu zu erfinden“
• Verbessern Komplexität, Kopplung, Nachnutzbarkeit, Codeverständnis & Kommunikation mit Entwickler:innen

Kritik an Entwurfsmustern

• Boilerplate: Benötigen Code, der nicht direkt zur Lösung beiträgt
• Unnötige Nutzung: Teilweise einfachere Lösungen, die zugunsten von Entwurfsmustern bevorzugt werden
• Dogmatismus: Strikte Befolgung, statt Anpassung an jeweiliges Programm

Kategorien der Entwurfsmuster

• Erzeugung: Beschreiben, wie Objekte erzeugt werden (Bsp: Abstract Factory)
• Struktur: Beschreiben die Komposition von Klassen (Bsp: Decorator)
• Verhalten: Beschreiben Interaktion von Klassen (Bsp: Iterator & Observer)

Abstract Factory Pattern

• Delegiert Objekterzeugung an Subklassen- Bspw. Sinnvoll bei Cross-Platform-Apps, wo die GUI-Erzeugung unterschiedlich implementiert werden muss
• Beteiligte Klassen:
• AbstractFactory: Interface erzeugt Produkte einer Familie
• ConcreteFactory: Ermöglicht Erzeugung konkreter Objekte einer Familie
• AbstractProduct: Interface für konkrete Produkte
• ConcreteProduct: Implementierung des konkreten Produkts
• Client: Nutzt konkr. Produkte über AbstractProduct Interface, erzeugt konkr. Produkte mit einer ConcreteFactory, verwendet dazu das AbstractFactory Interface

Decorator

• Erweitert Klassen mit Delegation statt Vererbung -> Vererbung beschränkt Erweiterbarkeit
• Beteiligte Klassen/Struktur:
  • Component: zu erweiternde Interface
  • Decorator: erweitern andere Komponenten um neue Funktionalität
  • BasicComponent: implementiert Grundfunktionalität (ohne Erweiterung)
  • Vorteile: Erlaubt Erweiterung ohne Vererbung, dynamisch zur Laufzeit
  • Nachteile: Oft von Reihenfolge der Decorator abhängig, Boilerplate für Methoden (nicht erweitert)

Iterator

• Ermöglicht den Zugriff auf Elemente einer Collection, ohne deren Struktur preiszugeben
• Versteckt Komplexität und vermeidet Fehler bei Traversierung
• Stellt Traversierung mit next/hasnext bereit
  • Vorteile: Versteckt Komplexität und vermeidet Fehler bei Traversierung
  • Nachteile: Schwere Parallelisierung, Implementierung evtl. komplex, Zustandsbehaftet und Probleme im Umgang mit Änderung, da komplexe Datenstruktur

Observer

• Erlaubt, Änderungen eines Objekts zu sehen, ohne Kopplung zu erzeugen
• Beteiligte Klassen:
  • Subject: kennt Observer, nutzt entsprechendes Observer Interface
  • Observer: Interface, um über Änderung am Subject zu informieren
  • ConcreteSubject: Informiert die Observer bei Änderung am Zustand
  • ConcreteObserver: ist an Änderung des ConcreteSubjects interessiert
    • Vorteile: Kopplung nur abstrakt (Subject ↔ Observer) und Ermöglicht Broadcast-Kommunikation
    • Nachteile: Gefahr von Update-Kaskaden und Benachrichtigungen werden an alle Observer geschickt, auch wenn sie nicht interessiert sind.

Funktionale Entwurfsmuster

• Monoid - Akkumulierung: Vermeidung von Wiederholungen; konkrete Beispiele: Listenkonkatenation, Strings (appendString), Zahlen (add, mul...) Boolesche Werte (Kon-/Disjunktion)
• Monade - Erweiterung: zusätzliche Funktionaliät Beispiele: Option (Wert vorhanden oder nicht); Liste: beliebig viele Werte

Software-Qualität

• Extern - Wahrnehmung Stakeholder:
  • Funktionalität, Validität, Reaktionsgeschwindigkeit, Bedienbarkeit, Kompatibilität, Portabilität, Effizienz
    • Maßnahme für Sicherstellung: Stakeholder-Feedback, Domänen-Modellierung, Testen, Statische Analyse
• Intern - Wahrnehmung Entwicker:innen:
  • Erweiterbarkeit, Wartbarkeit, Verständlichkeit, Enjoyability - Sicherstellung durch: Architekturentscheidungen; Designprinzipen und Metriken; Entwurfsmuster.

Testen

• Stichprobenartige Ausführung des Testobjekts, unter spezifizierten Bedingungen zur Überprüfung der Ergebnisse
• Test-Orakel:
  • Soll-Ausgaben, um Fehler zu erkennen -> Orakel ist Quelle
  • Meistens manuell erstellt -> idealerweise aus Spezifikation generiert
  • Testfall-Kriterien: repräsentativ, fehlerintensiv, redundanzarm und ökonomisch.
• Testarten: Automatisch vs. Manuell; beispielbasiert vs. Eigenschaftsbasiert; Black-box vs. White-box; funktionsorientiert vs. Strukturorientiert; Komponenten/Integration/System/UI; Akzeptanz/Smoketest/Usability/Accessibility...

Statische Analyse

• Tests alleine reichen nicht aus, da sie nur bestimmte Fälle berücksichtigen
• Statische Analyse: Infos über Code/Programm gewinnen, ohne Ausführung
  • Einsatzfelder:
    • In IDEs zur Unterstützung von Entwickler:innen:Klassenhierarchiel, Codenavigation, Methodenaufruf-Infos; Fehler, Warnungen, Code Smells, Optimierungsvorschläge; Refactoring, Auto Complete
    • In Compilern: Type Checking, semantische Analyse; Optimierung von Code
    • Für formale Verifikation: Informationssammlung für Beweise; Sicherstellen valider Spezifikationen
    • In Sicherheitsanalysen: Schwachstellen finden; Schadsoftware identifizieren; Datenleaks erkennen
  • Herausforderungen:
    • Unentscheidbare Eigenschaften: terminiert? / doppelte Pointer? → keine definitive Antwort: Über- und Unterapproximation
    • Vollständigkeit: keine unmögliche Ergebnisse produzieren → keine Überapproximation
    • Korrektheit: alle mögliche Ergebnisse produzieren → keine Unterapproximation, vollständige Korrektheit oft nicht erreichbar
    • Skalierbarkeit: Anforderungen stehen oft im Konflikt miteinander!
  • Analysetypen:
    • Kontrollflussanalyse; Datenflussanalyse
    • Nach Eigenschaften: Umfang: intraprozedural (jede Methode für sich) & interprozedural (gesamtes Programm); Flusssensitivität: Insensitiv (global gültiges Ergebnis) & Sensitiv (Ergebnis je Anweisung beurteilen); Kontextsensitiv: Insensitiv (Codestück nur 1x betrachten) & Sensitiv (mehrere Kontexte, bspw. Methodenaufrufe)
  • Analysetechniken: Typsysteme (Weisen Ergebnis einen Typ zu, Kompositional: Typ folgt aus Typen der Teilausdrücke, häufg genutzt (compilieren)) und Effektsysteme (Weisen Ausdruck einen Effekt zu, Kompositinal, seltener genutzt); Monotone Datenflussanalyse (intraprozedural, wie Werte zwischen Variablen fließen; Liveness, Reaching definitions und Available expressions); Interprozedurale Datenflussanalyse (IFDS & IDE), Datenfluss als Graph-Erreichbarkeits-Problem, wenn geeignet:: sehr effizient, Nutzung in z.B. Taintanalyse, Symbolische Ausführung, interpretiert Programme mit symbolischen Werten, Big-Step abstrakte Interpreter, Berechnen Abstraktionen konkreter Werte, Vereinigt Werte nach Verzweigungen à Pfadexplosion wird vermieden; Constraint-basierte Analyse; Slicing, wichtig für z.B. CFG & Dominator Baum, Callgraphen, Points-to-Analyse, Escape & Alias Analyse und Immutability & Purity

Langlebige Software (Gastvortrag)

• Softwaresysteme, die so lange eingesetzt werden, dass sich diese regelmäßig über einen Zeitraum an sich ändernde Hardware, Softwareumgebungen und Benutzungsanforderung anpassen
• Stichwort: Softwareerosion - Innerer Strukturverlust von Software führt zu- schlechter Wartbarkeit; schlechter Anpassbarkeit; schlechter Performanz und Anhäufung von Fehlern und Sicherheitsrisiken. → Anzeichen, Quellen, Verstärker und Bändigung
  • Anzeichen: Code passt nicht zur Dokumentation, schlechte Codequalität, Wartung schwierig.
  • Verstärker: Fehlende Automatisierung, All-In-One-Developer, unvollständige Entscheidungsfindung, fehlendes Update-Management
  • Quelle: Fehlendes Code-Verständnis, Ignorieren von Teamwissen, geänderte Code-Paradigmen werden nicht angepasst, Copy-Paste-Programmierung und Übermäßige Nutzung von KI
  • Bändigung: Gute Codequalität, strukturierte Entscheidungsverfahren, geeignetes Projektmanagement und echte Architektur-Arbeit

Testabdeckung/Spezifikationsbasiertes Testen (Black Box)

• Referenz: Spezifikation des Prüfobjekts (der Software)
• Bewertung: Vollständigkeit & Korrektheit auf Spezifikation
• Äquivalenzklassentest
  • Unmöglich, alle Kombinationen von Eingabewerten zu testen -> Unterteilung der Eingaben in „Gruppen ähnlicher Werte“
  • Zerlege mögliche Eingaben in gültige und ungültige Äquivalenzklassen
  • → getestet durch einen/mehrere Repräsentanten Bildung von Klassen
• geordneter Wertebereich:
  • eine gültige, zwei ungültige Klassen
• mit unterer und oberer Schranke
  • eine gültige, zwei ungültig
• Bedingung
  • eine gültige, eine ungültige
• Aufzählung/ungeordneter Wertebereich mit Gleichbehandlung
  • eine gültige, eine ungültige
• Aufzählung/ungeordneter Wertebereich ohne Gleichbehandlung
  • eine gültige Pro Wert, eine ungültige
• Beim Testen: Pro Testfall mehrere gültige Klassen abdeckena und pro Testfall nur EINE ungültige Klasse
• Quellcodebasiertes Testen (White Box) :Testreferenz, Bewertung, Techniken, Testabdeckung

Kontrollflussorientiertes Testen

• Referenz ist der Kontrollfluss, der aus dem Quellcode abgeleitet ist
• Umfasst:
  • Strukturbasierte Testabdeckung
  • Schleifentests
  • Logikbasierte Testabdeckung
• Datenflussorientiertes Testen
  • Referenz: Datenfluss, abgeleitet aus Quellcode
  • Ziel: Erreichen einer angemessenen Güte der test
  • Operationalisierung: hinreichende Testabdeckung
  • Beispiel: Zweigüberdeckung
  • Strukturelle Abdeckung:
• Kontrollflussgraph: Test auf gültige Pfade(Start à Endknoten)
  • Pfad: kann Kanten mehrfach durchlaufen, muss nicht alle Knoten durchlaufen

Arten der Strukturellen Abdeckung- Tests

• Anweisungsüberdeckungstest: Anteil der ausgeführten Anweisungen: Schwaches Kriterium
• Kantenüberdeckung: Jede Kante min. 1x ausführen
• Zweigüberdeckung: Zweige sind Kanten nach Entscheidung
  • Kanten/Zweigüberdeckung allgemein äquivalent
• Pfadüberdeckungstest: feste Abfolge von Knoten im CFG

Performance Metriken

• Die Messung und Optimierung der Anwendungsperformance, organisiert nach Metriken wie Laufzeit und Ressourcennutzung.

Laufzeit

• Die für eine Aufgabe benötigte Zeit
• Abhängig von Systemlast, Speicherbedarf, Thread-Synching und JIT-Optimierung.
• Verschiedene Maße sind Real-Zeit, Nutzer-CPU Zeit und System-CPU Zeit.
• Messungen über Benchmarks, wobei Variation durch Garbage Collection, Systemlast und Festplattennutzung entsteht und Varianzreduzierung durch Medianbildung erreicht wird
• Visualisierung durch Flame Graphs, die die Laufzeit einzelner Methoden messen.

Ressourcennutzung

• Umfasst CPU-Nutzung (CPU-Zyklen zur Ausführung nutzen) und Speicherbedarf (benötigte Menge an Arbeitsspeicher).
• Hoher Speicherverbrauch gleich hohe Laufzeit.
• Unterscheidung in physischen & virtuellen Speicher zur Abgrenzung von Prozessen.
• Maße wie Durchsatz, Bandbreite und Sondermetriken
• Just-in-Time Optimierungen zur Laufzeit zur Verminderung von Systemlast.

Theoreische Performanzmaße

• Zeitkomplexität zur Beschreibung der Laufzeit eines Algorithmus mit zunehmender Eingabegröße
  • Worst-Case-Zeitkomplexität
  • Durchschnittliche Zeitkomplexität