Software Engineering II

• Vorhandensein einer Architektur
• Definition eines Teams
• Treffen einer Entscheidung bzgl. Programmiersprache und Toolunterstützung

• Kenntnisse des Teams
• Anforderung des Kunden (Stichwort Integration in Systemlandschaft
• Lizenzerfordernisse der Entwicklungswerkzeuge
• Verfügbarkeit von notwendigen Frameworks und Bibliotheken

• Applikationsskelett, welches vom Entwickler angepasst (spezialisiert) werden kann, um Anforderungen optimal umzusetzen
• wiederverwendbarer Entwurf; oft durch Menge von abstrakten Klassen + Zusammenspiel ihrer Instanzen beschrieben
• effiziente Art der Softwarewiederverwendung
• Programmierung von Rahmen, die um Methodenimplementierungen ergänzt werden können
• können Steuerung gleichartiger Aufgaben übernehmen
• typische Nutzung: Nutzer instanziiert Framework-Komponenten, d.h übergibt seine Objekte zur Bearbeitung durch das Framework
• typischer Arbeitsschritt: Framework steuert, d.h. ruft Methoden der Nutzerobjekte auf

• stellen Standardlösungen für häufig wiederkehrende Probleme dar
• typische Nutzung: Nutzer erzeugt und ruft Objekte (Klassen) der Bibliothek auf
• sind geprüft und für Laufzeiten optimiert
• ihre Dokumentation wichtig zum effizienten Einsatz
• je größer Verbreitungsgrad, desto einfacher die Weiterverwendung von Ergebnissen

• decken oft benötigte Funktionalitäten ab --> Vermeidung von erneuten Implementierungen von Standardfunktionalitäten 
• Wiederverwendung existierender Funktionalität --> Kosteneinsparung, gesteigerte Qualität

• innerhalb der Methode: Kommentare beschreiben konkrete Aufgabe eines bestimmten Code-Segments
• in Verbindung mit automatischen Dokumentationsgeneratoren: auch innerhalb der Klasse, aber Fokus liegt auf Methodenbeschreibungen; Verwendung definierter Tags --> Kommentare können automatisch ausgewertet werden --> Erzeugung einer umfassenden Dokumentation

• Verwaltungsdokumentation (Autor, Datum, ...)
• Schnittstellendokumentation (Voraussetzungen, Ergebniszusicherungen, ...)
• Deklarationsdokumentation (Bedeutung von Konstanten + Variablen)
• Ablaufdokumentation (Verdeutlichen des Algorithmus)
• Strukturdokumentation (statischer Aufbau des Programms; typisch durch Einrücken + Zwischentitel)

• konsistent
• kein Nachbeten des Codes
• schlechen Code + Tricks nicht dokumentieren, sondern neu schreiben
• Programmstruktur durch Einrücken
• geeignete Namen
• Coderichtlinien beachten
• falscher Code wird durch ausführliche Dokumentation nicht richtig
• schlechter Code wird durch Dokumentation nicht besser
• nicht überdokumentieren

• komplizierter als eine 1-Person-Entwicklung
• Notwendigkeit definierter Entwicklungsprozesse
  • Verwaltung + Zuweisung der Tasks
  • definierte Namingconventions + Codestrukturierungen
  • Verwendung von Versionskontrollsystem
  • Verwendung von Continuous Integration Tools
  • Verwendung von Tools für Konfigurationsmanagement
• Notwendigkeit definierter Codeverantwortlichkeiten

• Faktor 1: bei Entdeckung durch den Programmierer selbst
• Faktor 10: bei Entdeckung durch einen Tester
• Faktor 100: bei Entdeckung im Live-Betrieb

• formeller Prozess
• von speziellem Testteam durchgeführt
• bewilligte Testfälle

• Identifikation von Testfällen, mit denen die höchste Wahrscheinlichkit gegeben ist festzustellen, ob das Softwaresystem korrekt funktioniert
• guter Test =hohe funktionale oder nichtfunktionale Abdeckung
• Idenktfikation von Fehlern von Programmen
• Fehler gefunden --> Test erfolgreich

1. Testen zeigt die Anwesenheit von Fehlern
2. Vollständiges Testen ist nicht möglich
3. Mit dem Testen frühzeitig beginnen
4. Häufung von Fehlern
5. Wiederholungen haben keine Wirksamkeit
6. Testen ist abhängig vom Umfeld
7. Trugschluss: Keine Fehler bedeuten ein brauchbares System

• Integrationstest
  • Big-Bang-Integration
  • Top-Down-Integration
  • Bottom-Up-Integration
  • Vertikale Integration
• Systemtest
• Akzeptanztest
• Funktionale Softwaretests
  • strukturelle Abdeckung mit White-Box-Tests
    • Anweisungsüberdeckungstest (C₀)
    • Zweigüberdeckungstest (C₁)
    • Einfacher Bedingungsüberdeckungstest (C₂)
    • Mehrfach-Bedingungsüberdeckungstest (C₃)
    • Pfad-Überdeckungstest (C₄)
  • funktionale Abdeckung mit Black-Box-Tests
    • Äquivalenzklassenanalyse
    • Grenzwertanalyse
    • Informelle Testmethoden
  • Kombination von beiden mit White- und Black-Box-Tests
• Nichtfunktionale Softwaretests
  • Performance-Test

• Beschreibung von Systemstrukturen
• erstes Artefakt zur Analyse der Einhaltung von Qualitätseigenschaften
• Beschreibung der Beziehung von Komponenten und Verbindungen
• fundamentale Organisation eines Systems, verkörpert durch
  • seine Komponenten,
  • deren Beziehungen,
  • deren Umwelt,
  • die Prinzipien hinter dem Design + der Evolution des Systems

• strategischer Entwurf
• taktischer Entwurf

• Architektur im „Großen“
• Entwurf auf Systemebene
• Entscheidungen über Technologie, Gesamtaufbau des Systems, etc.

• Architektur im "Kleinen“
• Entwurf auf Bausteinebene (also im klassischem SWE-Sinne)
• Entscheidungen über Aufbau der einzelnen Bausteine (z. B. Entwurf der Klassen, usw.)

• Performanz
• Veränderbarkeit
• Sicherheit

Das Ziel des Entwurf ist eine Abbildung eines Systems, das die Anforderungen optimal beschreibt.

• Nicht-funktionale Anforderungen:
  • z. B. Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit, Übertragbarkeit
  • Faktoren hinter strategischem Entwurf
• Funktionale Anforderungen:
  • z. B. Verarbeitung von Eingaben, Erstellen und etwaige Verarbeitung von Ausgaben
  • Faktoren hinter taktischem Entwurf

• Erfahrung des Softwarearchitekten
• Unterstützung durch Auftraggeber

• prozedurale --> objektorientierte Programmiersprache
• Großcomputer --> mobile Geräte
• monolithische Applikationen --> modulare Systeme
• Unified Modeling Language (UML) zur Abbildung von komplexen Systemen
• 80er, 90er, frühe 00er: Rich-Client-Applikationen
• durch PHP, Java Server Pages, ASP.net --> Webapplikationen
• heutzutage: Server Oriented Architecture (SOA)

• gesamte Geschäftslogik und Funktionalität der Anwendung wird so weit wie möglich in die Desktop-Applikation verlagert
• etwaiges Backend (z. B. Datenbank-Server) bedient sich ausschließlich Funktionalitäten, die nicht in der Desktop-Anwendung abgebildet werden können

• 2-Tier-Architekur
• 3-Tier-Architektur
• Service-orientierte Architektur (SOA)

• Anwendung + Backend-Komponente --> Trennung von Logik/Präsentation + Datenbank
• Vorteil: zentral verfügbare Datenmenge, die von mehreren Benutzern verwendet wird; nur an einer Stelle Administrationsaufwand
• Nachteil: Notwendigkeit von erweiterten Maßnahmen zur Sicherstellung der Datenkonsistenz

• Geschäftslogik wird aus Anwendungsschicht extrahiert und ähnlich wie die Datenbank zentral verfügbar gemacht --> Präsentation + Logik + Datenbank
• Vorteile: konsistenter Datenzugriff + bessere Wartbarkeit
• Nachteil: längere + detailliertere Planungsphase

• Services als komplett eigenständige Komponenten
• Neukonfiguration der Kommunikation mit minimalem Aufwand möglich