Informatik/Softwaretechnik.md

title	date	author
Softwaretechnik 1	Wintersemester 20/21	Robert Jeutter

Software: Menge von Programmen oder Daten zusammen mit begleitenden Dokumenten, die für Ihre Anwendung notwendig oder hilfreich sind [Hesse]

Gute Software ist schwer herzustellen

• Entspricht Kundenwünsche, Vollständigkeit
• Funktioniert Korrekt
• Kosten- und Termintreue bei der Erstellung
• weitere nicht-funktionale Qualitätsforderungen
  • Benutzerfreundlichkeit, Ergonomie
  • Sicherheit
  • Zuverlässigkeit, Fehlertoleranz
  • Performanz
  • Ressourcen-Effizienz, Skalierbarkeit, Übertragbarkeit
  • Wartbarkeit, Änder- und Erweiterbarkeit

Softwaretechnik

• Technische Disziplin der Software Herstellung
• Zielorientierte Bereitstellung uns systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen [Balzert]

Wie kann man Software besser entwickeln?

• Ingenieursmäßige Herangehensweise
  • Verwendung bekannter Prinzipien und Methoden
  • Systematische Vorgehensweise
• Verwendung von:
  • Abstraktion, Modelle, Notation, Simulation
  • Wiederverwendung:Muster, Komponenten, Framework
• Organisation
  • Arbeitsteilung, Integration, Planung
• Verwendung von Werkzeugen
  • IDE (Integrated Development Environment)
  • Versionierung, Bugtracker, Modellierungswerkzeug

Modellierungskonzepte

Modell: ist eine Abstraktion eines Systems mit der Zielsetzung, das Nachdenken über ein System zu vereinfachen, indem irrelevante Details ausgelassen werden [Brügge] \rightarrow Beschreibung eines Ausschnitts der Realität

• erstellen einer Abstraktion
• abbilden signifikanter Eigenschaften
• Deskriptiv/präskriptiv (real oder geplant)
• Sichtweise auf ein System (Struktur, Verhalten, Zustand,...)
• heißt Weglassen
• setzt Verstehen voraus
• ist nicht automatisierbar

Verschiedene Modelle:

• Analysemodell
• Entwurfsmodell
• Implementierung (-smodell)
• Vorgehensmodell
• Produktmodell
• Dokumentation, Alternativen-Auswahl

Modelle für:

• Sichten
• Funktionen
• Daten
• Algorithmen
• Systemumgebung
• Dynamisches Verhalten
• Objektorientierte Modelle

Klassische Modelle

• Funktionen:
  • Funktionsbaum
    • Hierarchische Dekomosition der Fkt
    • nummerieren der Ebenen/Funktionen möglich
    • Bsp: Abonnement Verwaltung
  • Blockschaltbild
    • eingebettetes System, HW/SW
• Daten
  • Data Dictionary
    • Verzeichnis von Daten mit Strukturinformationen
    • Backus-Naur-Form, kontextfreie Grammatik
  • Entity Relationship Diagram
    • Daten und ihre Beziehungen
• Systemumgebung
  • Datenflussdiagramm
    • Fluss und Transformation von Daten zwischen Funktionen, Speichern und Schnittstellen
    • kein Kontrollfluss
• Algorithmen
  • Entscheidungstabelle
    • Regelbasierte Beschreibung
    • Bedingung
    • Aktionen
    • Reduktionsregeln
  • Pseudocode
    • von Programmiersprache abstrahierende, detaillierte Beschreibung eines Algorithmus
  • Programmablaufplan
    • Grafische Beschreibung des Kontrollflusses
    • DIN 66001
    • Unstrukturiert
  • Struktogramm
    • Nassi-Shneidermann-Diagramm
    • keine Sprünge
• Dynamisches Verhalten (diskrete Zustände und atomare zustandübergänge)
  • Zustandsautomat
    • Verhalten mit Zuständen und -übergängen
    • Automatenmodelle und -theorie
    • Ggf zerlegung oder kommunizierende Automaten
  • Flow-Chart
  • Ereignisgesteuerte Prozesskette (EPK)
    • Geschäftsprozesse
    • BPM
  • Petri-Netz (ggf. mit Zeitmodell)
    • Grafische Beschreibung von Nebenläufigkeit und Synchronisation
• Objektorientierte Modelle
  • Klassendiagramme
  • UML

Objektorientierung

• bessere Strukturierung für komplexe Zusammenhänge
• Abstraktere Sichtweise
• Grundprinzip: Zerlegung; Teile und Herrsche
• ein System besteht aus vielen Objekten
• ein Objekt hat
  • definiertes Verhalten
    • Menge genau definierter Operationen
    • Operation wird beim Empfang einer Nachricht ausgeführt
  • inneren Zustand
    • Zustand des Objekts ist Privatsache
    • Resultat einer Operation hängt vom aktuellen Zustand ab
  • eindeutige Identität
    • Identität ist unabhängig von anderen Eigenschaften
    • Mehrere verschiedene Objekte mit identischem Verhalten und identischem inneren Zustand im gleichen System möglich
• Klasse
  • Gleichartige Objekte mit ggf. verschiedenen Zuständen
  • Verhaltensschema – Operationen
  • Innere Struktur – Attribute

Vorteile der Objektorientierung

• Zuständigkeitsbereiche
  • Daten, Operationen und Zustand: lokal und gekapselt
• Klare Schnittstellen
  • Definiertes Objektverhalten, Nachrichten
• Hierarchie
  • Vererbung und Polymorphie (Spezialisierung), Klassenschachtelung
• Baukastenprinzip
  • Benutzung vorgefertigter Klassenbibliotheken, Anpassung durch Spezialisierung (mittels Vererbung)

Unified Modeling Language

• Grafisches Beschreibungsmittel für Aspekte des Softwareentwurfs diskreter Systeme
  • Spezifikation, Entwurf, Visualisierung, Konstruktion, Dokumentation von Software
  • Für OO-Softwareentwicklung und -prozess geeignet
  • UML ist weder Methode noch Prozess

Warum UML?

• Objektorientierung ist zur Zeit das vorherrschende Modellierungs-Paradigma, Industrie-Standard
• Kombination von Struktur-, Verhaltens-, Interaktions-, und Verteilungsmodellen
• Für Analyse, Entwurf, Implementierung und Test einsetzbar
• Gute Werkzeugunterstützung für Editieren, Versionierung, Codegenerierung
• Erweiterbarkeit der UML mit Stereotypen und Tags
• Semi-formale Modelle, z.T. verschiedene Interpretationen
• Offenheit: Erweiterung mit stereotypes, tags, constraints

Nachteile UML

• UML ist in vielen Facetten nicht präzise festgelegt
• Werkzeuge für Transformation, Analyse etc. fehlen noch
• UML ist keine „kleine Sprache“: Lernaufwand notwendig
• Komponenten sind nicht adäquat darstellbar
• Sprachen wie die UML werden erlernt durch Übung!
• Aber: LV SWT ist kein kompletter UML-Kurs

Überblick über Modelle

• 14 Diagrammarten
• Struktur-Diagramme
  • Klassen-, Objekt-, Komponenten-, Kompositions-Struktur-,
  • Paket- und Verteilungsdiagramm
  • Profildiagramm – zur UML-Erweiterung
• Verhaltens-Diagramme
  • Use-Case-, Aktivitäts- und Zustandsdiagramms
  • Interaktionsdiagramme: Sequenz-, Kommunikations-, Timing- und Interaktionsübersichts-Diagramm

Use-Case-Diagramm

• Beschreiben Systemfunktion aus Benutzersicht (Was, nicht Wie)
• Erste Anforderungsspezifikation (requirements)
• Planbare Einheiten als Inkremente für die Entwicklung
• Keine Modellierung eines Ablaufs!
• Erstellen von Testfällen (test case generation)
• Grundelemente
  • Anwendungsfall: Use Case
  • Beteiligte: Aktor
• Verfeinerung mittels Use-Case-Realisierung notwendig
  • Textuelle Beschreibung
  • Verhaltensdiagramme

Klassendiagramm

• Modellierung der Struktur (Aufbau) eines Systems
• Modellierung von statischen Aspekten
• Modellierung der Struktur von Daten
• Klasse im Mittelpunkt
  • Aufbau: Attribute, Operationen
  • Beziehungen zueinander: Assoziationen, Vererbung
• Verbreitetstes und bekanntestes Diagramm der UML

Objektdiagramm

• Struktur des Systems zur Laufzeit zu einem Zeitpunkt
• Tatsächliche Zusammenhänge und Belegungen von Attributen von Objekten zu einem Zeitpunkt
• Eine detaillierte Sicht auf einen Aspekt
  • Keine vollständige Beschreibung (zu komplex)
  • Für kompliziertere Abhängigkeiten (z.B. Rekursion)
• Objektdiagramm für alle Arten von Exemplaren
  • z.B.: Klasse (Objekt), Komponente, Knoten, ...
• Keine Exemplare von Operationen -> Ablauf -> Verhaltensdiagramme / Interaktionsdiagramme
• Kein Verlauf der Wertebelegung über die Zeit

Paketdiagramm

• Gliederung (Strukturierung) des Systems in Teile (Pakete)
• Zuordnung von Elementen zu einem Paket
• Bildung von Hierarchien (Enthält-Beziehung)
• Abhängigkeiten zwischen den Paketen
  • "Include" von Quellcode-Dateien (<>)
• Anwendung:
  • Zum Grobentwurf von Systemen
  • Definition von Schichten

Komponentendiagramm

• Strukturierung des Systems durch Komponenten
• Komponente: Modulare, austauschbare Einheit (Substitution)
• Modellierung der Abhängigkeiten zwischen Komponenten
• Modellierung der inneren Struktur von Komponenten
• Definition von Schnittstellen

Kompositionsstrukturdiagramm

• Teile-Ganzes-Strukturen -> Kompositionsstruktur
• Strukturell statische Kompositionsstrukturen:
  • Kurzschreibweise bei vielen Kompositionen
  • Modellierung des Aufbaus komplexer Systeme
• Strukturell dynamische Kompositionsstrukturen:
  • Notwendige Strukturen zur Realisierung eines Verhaltens
  • Definition von Rollen, zur Lösung wiederkehrender Probleme -> Modellierung von Mustern
• Starke Verwandtschaft mit dem Klassendiagramm
• Spezialisierte Kompositionsbeziehung -> erweiterte Semantik

Aktivitätsdiagramm

• Modellierung von
  • Kontrollflüssen
  • Datenflüssen
  • Parallelem Verhalten
  • Verzweigungen, bedingten und gewichteten Abläufen
• Geschäftsprozessmodellierung möglich
• Abstrakte und detaillierte Verhaltensbeschreibung möglich
• Grundlage zur Codegenerierung
• Zur Verfeinerung von
  • Use-Cases
  • Operationen / Interaktionen
  • anderen Aktionen und Aktivitäten

Interaktionsdiagramme

• Modellierung von
  • Kommunikation zwischen Kommunikationspartnern (Lebenslinie)
  • Operationen (Modellierung eines Programms)
  • Informationsaustausch / Nachrichten
• Gemeinsames Grundkonzept der Interaktionsdiagramme
• Sehr detaillierte Diagramme
  • Meist nicht zur vollständigen Beschreibung eines Systems
  • Betrachtung eines wichtigen Teilaspekts
• Grundlage zur Codegenerierung

Sequenzdiagramm

• Genaue zeitliche Abfolge von Nachrichten
• Umfangreichstes Interaktionsdiagramm
• Kontrollelemente möglich (Schleifen, Verzweigungen)

Kommunikationsdiagramm

• Kommunikationsbeziehungen der Kommunikationspartner stehen im Vordergrund
• Welche Komponenten arbeiten wie zusammen, um eine Funktion zu erfüllen

Timing-Diagramm

• Genaue zeitliche Darstellung von Zustandsübergängen
• Kommunikation abhängiger Zustandsautomaten
• Modellierung einzelner Interaktion

Prinzipieller Aufbau

• Zeitlicher Verlauf senkrecht
• Kommunikationspartner waagerecht (unsortiert)
• Lebenslinie
  • Rechteck mit gestrichelter senkrechter Linie
  • Start, Ende und Dauer der Ausführung einer Operation
  • Rekursive Aufrufe möglich
• Ereignisspezifikation
  • Stelle des Sendens / Empfangens der Nachricht
  • Definition der Reihenfolge des Auftretens
  • Trace: Folge von Sende- und Empfangsereignissen

Weitere Elemente des Sequenzdiagramms

• Nachrichten ohne Sender
  • z.B. am Beginn einer Interaktion
• Verlorene Nachrichten (ohne Empfänger)
  • Nachricht ohne dargestellten Empfänger
  • z. B. am Ende einer Interaktion
• Erzeugen von Lebenslinien
  • Gestrichelte Linie mit geöffnetem Pfeil
  • Keine Rückgabenachricht
  • Zeitliche Einrückung des Rechtecks
• Zerstören von Lebenslinien
  • Durchgezogene Linie mit Dreieckende
  • Kann Rückgabenachricht erzeugen

Nachrichten in Interaktionsdiagrammen

• Ereignis des Sendens bzw. Empfangens von Nachrichten
• Typen:
  • Operationsaufruf (synchron / asynchron)
  • Antwort Nachricht
  • Signal (asynchron), Create-/ Delete Message
• Operationsaufruf: Parameterliste muss kompatibel sein
• Nachrichtentypen

Zustandsdiagramm

• Modellierung des (vollständigen?) Verhaltens
  • Zustände von Klassen / Objekten / Komponenten
  • Übergänge zwischen den Zuständen
  • Ereignisse, die Zustandswechsel auslösen
• Modellierung von endlichen Automaten (Zustandsmaschinen)
  • Deterministische
  • Nichtdeterministische
• Verfeinerung von Zuständen möglich
• Modellierung von verteilten Systemen / parallelem Verhalten
• Grundlage zur Codegenerierung

Analyse

• Einordnung in den Projektablauf

• Was ist eine Anforderung?

  • Merkmal, Eigenschaft, Bedingung oder Einschränkung eines Systems
  • Notwendig für die Akzeptanz vom Kunden
  • Definition (IEEE 610.12-1990)
    • Dokumentierte Darstellung einer Fähigkeit oder Eigenschaft
    • von Anwender benötigt zur Problemlösung bzw. um Ziel zu erreichen
    • Muss von System oder Komponente erfüllt werden, um Vertrag oder Standard zu erfüllen

• Funktionale Anforderungen - Was soll es tun?

  • „...Legt eine vom Softwaresystem oder einer seiner Komponenten bereitzustellende Funktion oder Service dar“ [Balzert]
  • Was leistet das System
  • Welche Funktionen bietet es
  • Wie interagiert es mit der Umgebung
  • Anforderungen an:
    • Verhalten
    • Struktur
    • (Alternativ: Statik, Dynamik, Logik)

• Nichtfunktionale Anforderungen – Wie?

  • „...legen qualitative oder quantitative Eigenschaften des Softwareprojektes oder einer Komponente fest“ [Balzert]
  • Auch Bezeichnet als:
    • Quality of Service
    • Qualitätsanforderungen
  • Arten - FURPS (ISO 9126):
    • Functionality (Funktionalität)
    • Usability (Benutzbarkeit)
    • Reliability (Zuverlässigkeit)
    • Performance (Effizienz) / Portability (Übertragbarkeit)
    • Supportability (Änderbarkeit/ Wartbarkeit)

• Funktionalität

  • Angemessen, Genauigkeit
  • Sicherheit: Vertraulichkeit, Informationssicherheit, Datenintegrität, Verfügbarkeit
  • (Nicht ausreichend spezifizierte funktionale Anforderung)

• Benutzbarkeit

  • Verständlichkeit, Erlernbarkeit, Bedienbarkeit, Attraktivität

• Zuverlässigkeit

  • Reife (Fehler-Anzahl), Fehlertoleranz, Wiederherstellbarkeit

• Effizient/ Leistungsanforderungen

  • Zeitverhalten, Verbrauchsverhalten, Wirtschaftlichkeit

• Portabilität

  • Anpassbarkeit, Installierbarkeit, Koexistenz, Austauschbarkeit

• Wartbarkeit

  • Analysierbarkeit, Änder- und Erweiterbarkeit, Stabilität (bei Änderungen), Testbarkeit

• Weitere:

  • Konformität zu Konventionen und Bestimmungen
  • Interoperabilität zu anderen Systemen
  • Implementierungsanforderungen
  • Schnittstellenanforderungen
  • Skalierbarkeit (Änderungen des Problemumfangs)
  • Betriebliche und rechtliche Rahmenbedingungen
  • Liefer- und Verpackungsanforderungen

Nichtfunktionale Anforderungen

Schwierigkeit nichtfunktionaler Anforderungen

• Hängen oft von Verhalten ab: daher komplex und nicht direkt sichtbar
• „Das Auto hat vier Räder“ (Struktur)
• „Wenn der Blinker betätigt wird, blinkt das Auto dreimal wenn die Zündung an ist; ansonsten wird das Standlicht einseitig eingeschaltet“ (Korrektes Verhalten)
• „Das Motorsteuergerät darf innerhalb von 5 Jahren und 150.000km Laufleistung höchstens mit 0.1% Wahrscheinlichkeit ausfallen“ (Zuverlässigkeit)

Umgang mit nichtfunktionalen Eigenschaften

• Nicht direkt „by construction“ zu realisieren
• Naive Herangehensweise: Ignorieren!
  • Entwerfen und Implementieren der Software ohne Berücksichtigung nichtfunktionaler Eigenschaften
  • Testen der nichtfunktionalen Eigenschaften
  • Wenn nicht erfüllt: Entwurf und Implementierung ändern!
• Funktioniert nur bei sehr einfachen Systemen, bzw. wenn nichtfunktionale Eigenschaften nicht wichtig sind!

Sinnvoller Umgang mit nichtfunktionalen Eigenschaften

• Untersuchung der Projektrisiken bereits in der Analysephase
  • größte Risiken zuerst betrachten!
  • Immer fragen: Geht das so überhaupt?
  • Festlegungen des Entwurfs möglichst früh gegen Anforderungen prüfen – aber wie?
• Modellbasierter Entwurf
  • Modellierung des Systems und seiner Umwelt
  • Bewertung des Modells (Simulation)
  • Lehrveranstaltungen Systementwurf, KIS, LTS

Randbedingungen

• „... Eine Randbedingung ist eine organisatorische oder technologische Vorgabe, die die Art und Weise einschränkt, wie das betrachtete System realisiert werden kann.“
• Werden nicht umgesetzt
• Schränken Lösungsraum ein
• Beispiele:
  • Kosten
  • Durchlaufzeit: Time to Market
  • Vorgaben durch Marketing und Vertrieb
  • Technische Randbedingungen (nichtfunktionale Anforderung)

Geforderte (Meta-)Eigenschaften

• Vollständig: alle Szenarien sind beschrieben

• Konsistent: keine Widersprüche

• Eindeutig: nur eine Interpretation möglich

• Korrekt: genaue und richtige Darstellung

• Realistisch: unter geg. Einschränkungen implementierbar

• Überprüfbar: durch Tests am Endprodukt nachweisbar

• Rückverfolgbar: Auswirkungen bis zur Implementierung nachvollziehbar (Testfälle, Auswirkung von Änderungen)

• Klassifizierbar (Risiko, Priorität, Dringlichkeit, Nutzen ...)

• Validierung mit dem Kunden

• Requirements Engineering

  • Ermittlung, Analyse und Verwaltung von Anforderungen
  • Ausgangspunkt: Projektidee

• Anforderungsermittlung

  • requirements elicitation, requirements definition
  • Bestimmen und dokumentieren der Anforderungen an das geplante System
  • Beteiligt: Entwickler, Kunde, Benutzer
  • Ergebnis: Anforderungsspezifikation - Glossar, Vertrag, Lastenheft

• Anforderungs-Analyse

  • requirements analysis, system modeling
  • Beschreibung im Detail und formal strukturiert
  • Beteiligt: Entwickler
  • Ergebnis: funktionale Spezifikation - Produktdefinition, Analysemodell, Pflichtenheft

	Anforderungsermittlung	Systemmodellierung
Ergebnis	Anforderungsspezifikation im Lastenheft, Glossar, Lastenheft	funktionale Spezifikation in Produktdefinition, Analysemodell, Pflichtenheft
Notation	Text	Text + (semi-) formales Modell
Kommunikation	mit dem Kunden	zwischen Entwicklern
Sichtweise	des Anwenders	äußere Systemaspekte
Vor allem: Kommunikationsleistung!

Bedeutung:

• Falsche Anforderungen führen zu falschem System
• Frühe Fehler im Entwicklungsprozess sind teuer!

Fehlerentstehung und Fehlerquellen bei Anforderungserfassung

• 83% sprachliche Fehler (Un- bzw. Missverständlich)
• 75% Logische Fehler (Widersprüchlichkeit, Redundanz)
• 73% Inhaltliche Fehler (Falsche Sachverhalte, Unvollständig)

Ermiteln von Anforderungen

Woher kommen Anforderungen?

• Ausgangspunkt
  • Projektidee, schriftliche Skizze
  • Kurz und knapp
  • Stichpunkte der wichtigsten Funktionen
  • Lastenheft (falls schon existiert)
• Interessenhalter (stakeholder)
  • Identifizieren, Wichtigkeit bewerten (berücksichtigen?)
  • Ansprechpartner? Interessen und Erwartungen
  • Fachexperten, Verantwortliche, Betroffene

Beteiligte Rollen

• Endbenutzer
  • Aufnahme Ist-Zustand, Domänenwissen, Anforderungen
• Kunde
  • Definiert Ziel des Systems, Vertragsverhandlung
• Konfigurationsmanager
  • Revisionsgeschichte der Dokumente, Nachvollziehbarkeit
• Architekt
  • Integration von Anwendungsfall- und Objektmodellen
• Analytiker
  • Modelliert das System und erstellt Anwendungsfälle
• Redakteur
• Prüfer

Wie ermittelt man Anforderungen?

• Problem: Entwickler müssen sich in Begriffs- und Denkwelt des Kunden einarbeiten, sonst Kommunikationsprobleme
• Systematische Vorgehensweise
• Kommunikation mit Kunden
• Geschäftsprozess (business process)
  • fachlicher Ablauf, der Wert oder Kosten verursacht
• Akteur (actor)
  • Benutzer, Schnittstelle nach außen
• Szenario (scenario)
  • Interaktion mit System als Ablauf
• Anwendungsfall (use case)
  • Automatisierter Arbeitsschritt, vom System ausgeführt
• Interviews mit Fachanwendern
  • Mitschrift, später strukturierter Text und Tabelle
• Strukturierte Spezifikation
  • Vorlagen / sprachliche Anforderungsschablonen
  • Formulare
  • Reduzierung sprachlicher Mehrdeutigkeiten
• Anwendungsfalldiagramm (Use-Case-Diagramm)
  • Arbeitsschritt eines Geschäftsprozesses, der durch das System ausgeführt wird
  • Anforderungen an das System modellieren – was soll das System leisten
  • Systemgrenzen / Systemkontext festlegen
  • Systembeteiligte modellieren
  • Planbare Einheiten als Schritte für die Entwicklung
  • Verwendung bereits ab Projektbeginn
  • Keine Modellierung eines Ablaufs!
• Umgang mit Szenarien und Anwendungsfällen
  • Zunächst nur zum Verständnis kurz aufstellen
  • Systemgrenze definieren
  • Beschreibungen verfeinern
  • Änderungen mit Kunden abstimmen
  • Prototypen nur zur visuellen Unterstützung
  • Benutzungsschnittstelle erst beginnen, wenn funktionale Anforderungen in etwa klar sind

Leitfaden für Anwendungsfälle

• Benennen mit Verbalphrasen, die Anwendersicht beschreiben (Simuliere)

• Akteure mit Substantiven benennen (Anwender)

• Systemgrenzen klären. Arbeitsschritte von Akteuren und System kennzeichnen

• Schritte im aktiven Stil beschreiben (Auto bremst)

• Ursächliche Beziehung zwischen Folgeschritten

• 1 Anwendungsfall = 1 vollständige Transaktion

• Normalfall darstellen; Ausnahmen gesondert beschreiben

• Nicht die Benutzungsschnittstelle beschreiben (statt dessen visuellen Prototypen verwenden)

• Übersichtlichkeit (max. 2-3 Seiten), sonst zerlegen

• Typische Probleme

  • Kommunikations- und Verständnisprobleme
  • Viele verschiedene Beteiligte
  • Kunden wissen nicht, was sie genau wollen und was geht
  • Verwendung von Fachsprachen
  • Widersprüchliche Anforderungen, verschiedene Interessen
  • Nicht-technische organisatorische, historische oder rechtliche Rahmenbedingungen
  • Zusätzliche Beteiligte können auftauchen
  • Anforderungen ändern sich während der Entwicklung

• Anforderungsänderungen

  • Sind die Regel

• Tätigkeiten der Anforderungsanalyse

  • Anforderungen strukturieren
  • Eigenschaften der Anforderungen bestimmen
  • Anforderungen priorisieren
  • Anforderungen in Textform, Grafiken, Modellen dokumentieren
  • Anforderungen modellieren
  • Anforderungen auf inhaltliche Qualität prüfen
  • Auf Übereinstimmung mit den Zielen prüfen
    • Ziel Abnahme der Anforderung
  • Hängt mit Analyse des Systems zusammen

• Anforderungen strukturieren

  • Unterteilung
    • Funktional, Nichtfunktional
    • Muss, Kann,... oder Haupt- und Nebenanforderung
  • Hierarchische Zerlegung
    • Unterteilen, Verfeinern
  • Ordnung festlegen, eindeutig Nummerieren
    • auf Einmaligkeit achten
  • Beziehungen festhalten
  • Verwendung von Werkzeugen
    • MS-Project, Doors, Git issues, Trac, Bugzilla, MKS,...
    • Modellierungswerkzeuge

• Eigenschaften bestimmen

  • Wahl der Eigenschaften firmen- bzw. projektspezifisch
  • Wichtige Eigenschaften
    • Identifikationsnummer
    • Kurzbezeichnung
    • Beschreibung (Text, ggf. Grafik, Modell)
    • Aufwand
    • Priorität der Anforderung
    • Bearbeitungsstatus / Restaufwand
    • Zugeordnet (wer ist verantwortlich / bearbeitet)
    • Querverbindungen zu anderen Anforderungen
    • Ggf. zusätzliche Dokumente oder Bemerkungen
    • Stabilität der Anforderung (Änderungswkt.)
    • Kritikalität der Anforderung: Schäden bei Fehlern?
    • Entwicklungsrisiko: Erfolgsaussichten der Umsetzung
    • Abnahmekriterien / Erfüllungsnachweis durch?
    • Anforderungstyp: Funktional, nicht funktional ,...
    • Anforderungssicht: Dynamik, Statik, Logik, Struktur, Funktion
    • Mögliche Konflikte
    • Autor
    • Quelle: Wer möchte die Anforderung umgesetzt haben?
    • Status der Beschreibung: Idee, grober Inhalt, detailliert
    • Anforderungsversion

• Anforderungen priorisieren

  • MuSCoW-Priorisierung
  • Muss-, Kann-, Optional, Nicht (Abgrenzungskriterien) (must, should, could, won‘t)
  • Ad-hoc: Stakeholder priorisiert Anforderungen
  • Priorisierungsmatrix / Kosten-Wert-Analyse
    • Eigenschaften bewerten (Punkte vergeben)
    • Werte gewichten
    • Priorität berechnen Prioritäten = \frac{Nutzen - Nachteil}{Kosten + Risiko}
  • Kano-Klassifikation
    • Basiseigenschaften: Werden vorausgesetzt (fehlen stört, wenig zusätzliche Zufriedenheit)
    • Leistungseigenschaften: Sonderwünsche
    • Begeisterungseigenschaften: Wird nicht erwartet
    • Abfragen per Fragenkatalog
  • Reihenfolge festlegen

Objektorientierte Analyse und Systemmodellierung

• Übersicht
  • Aufgabe: Systemmodell erstellen, funktionale Spezifikation
  • Beschreibung der Systembenutzung und des Verhaltens
  • Was, nicht wie – Implementierungsaspekte ausklammern
    • Nicht: Datenhaltung, Verteilung, Technologien, Architektur, ..
  • Zusammenhang mit Anforderungsspezifikation
  • OO: Modell des Anwendungsbereichs
• Analysemodell
  • Korrekt, vollständig, konsistent und nachprüfbar
  • Struktur und Verhalten
  • Verschiedene Sichten (OO, Strukturiert, ...)
• Eingangsdokumente
  • Lastenheft, Anforderungsspezifikation
• Typische Ergebnisse
  • Funktionales Modell
    • Geschäftsprozesse und Anwendungsfälle
  • Objektmodell
  • Dynamisches Modell – Systemverhalten
    • Zustands- und Sequenzdiagramme
  • Vor- und Nachbedingungen von Systemoperationen
  • Prototyp / Spezifikation Benutzungsschnittstelle
  • Pflichtenheft
• Objektorientierte Analyse nach [Brügge / Dutoit]
  • Verdeutlicht iterativen Ablauf
  • Unterteilung des Analysemodells in:
    • Funktionales Modell (Anwendungsfälle)
    • Objektmodell (Klassen und Objektdiagramme)
    • Dynamisches Modell (Zustands- und Sequenzdiagramme)
    • Unterscheidung der Objekttypen

• Heuristik Sprache \rightarrow OO-Modell

• Objektarten im Systemmodell

  • Entitätsobjekte – vom System verwaltete Informationen
  • Grenzobjekte – Interaktion zwischen System und Akteuren
  • Steuerungsobjekte – Durchführung der Anwendungsfälle

• Identifizierung von Entitätsobjekten

  • Begriffe, die klargestellt werden müssen
  • Wiederkehrende Substantive in Anwendungsfällen
    • Heuristiken
  • Reale Objekte, die das System kennen muss
  • Reale Prozesse, die das System verfolgen muss
  • Anwendungsfälle
  • Datenquellen und -senken
  • Artefakte, mit denen der Nutzer interagiert

• Identifizierung von Grenzobjekten

  • Elemente der Benutzungsschnittstelle
  • Formulare für Eingaben
  • Nachrichten, Rückmeldungen
  • Endgeräte
  • In der Begriffswelt des Anwenders bleiben!
  • Schnittstellen grafisch skizzieren bzw. Prototyp!

• Identifizierung von Steuerungsobjekten

  • Koordination von Grenz- und Entitätsobjekten
  • Abarbeitung von Anwendungsfällen
    • Reihenfolge von Schritten
    • Informationen übernehmen und weiterleiten
    • Oft ein Steuerungsobjekt pro Anwendungsfall
  • Beispiel: Simulationsszenario
  • Verhaltensmodell sinnvoll! Im folgenden: dynamische Modelle

• Abläufe der Anwendungsfälle modellieren

  • Ziel - Objekte finden
  • Klassen identifizieren
  • Verhalten / Operationen finden

• Use Case durch Interaktion verfeinern

  • einfacher kurzer Ablauf: textuelle Beschreibung, Aktivitätsdiagramm
  • Ablauf mit Verzweigungen, Parallelitäten: Aktivitätsdiagramm (Kontrollflussmodellierung)
  • datengetriebener Ablauf: Aktivitätsdiagramm (Objektflussmodellierung)
  • Interaktion zwischen den Objekten wichtig: Kommunikationsdiagramm, Aktivitätsdiagramm (Aktivitätsbereiche), Sequenzdiagramm
  • zeitliche Abfolge steht im Mittelpunkt: Sequenzdiagramm
  • Zustandswechsel / zeitliche Abfolge von Zuständen: Zustandsdiagramm / Timing-Diagramm
  • komplexe Abläufe mit Verzweigungen und Parallelitäten: Interaktionsübersichtsdiagramm
  • komplexe Abläufe ohne Verzweigungen und Parallelitäten: weitere Verfeinerung durch Use-Case-Diagramm
  • komplexer strukturierter Ablauf: Kollaboration aus dem Kompositionsstrukturdiagramm

• Dynamische UML-Modelle

  • Abläufe
    • Aktivitätsdiagramm (activity diagram)
    • Kommunikationsdiagramm (communication diagram)
    • Sequenzdiagram (sequence diagram)
    • Zeitdiagramm (timing diagram)
  • Zustandsabhängiges Verhalten von Objekten
    • Zustandsautomat (state chart diagram)

• Aktivitätsdiagramm

  • Aktion – einzelner Schritt
  • Aktivität
    • Beschreibt einen Ablauf / repräsentiert ein Verhalten
      • Beinhaltet eine Folge Aktionen, Kontroll- oder Objektknoten
    • Schachtelung von Aktivitäten und Aktionen
      • Aktionen in Aktivitäten enthalten
      • Aktionen durch Aktivitäten verfeinerbar
    • Aktivitäten beschreiben / verfeinern
      • Aktionen, Use Cases, Interaktionen, Operationen ...
  • Ein- und Ausgabeparameter in Form von Objekten
    • Parameterknoten entsprechend Pins der aufrufenden Aktion
    • Alternativ: Parameterangabe mit Name und Typ
  • Angabe von Vor- und Nachbedingungen möglich
  • Optional: Parameter unter Aktivitätsnamen

• Verfeinerung der Aktionen durch Aktivitäten

• Aktion durch Interaktionen verfeinern

  • Detaillierte Diagramme
  • Meist entwurfsnah

• Verfeinerung der Aktionen durch StateChart

• Objekte zusammenstellen und klassifizieren

  • Toolunterstützung (Möglichkeiten stark toolabhängig)
  • Objekte Ergebnis der Verhaltensmodellierung
  • Ergebnis Verhaltensdiagramm: Operationen der Klassen
  • Klassen generalisieren / spezialisieren \rightarrow Klassenhierarchie

• Übergang zum Entwurf

  • Klassenstruktur festlegen

• Spezifikation von Benutzungsschnittstellen

  • Skizzieren, Prototyp generieren, Spezialwerkzeuge
  • Klassen und Operationen in Funktionen
  • Gestaltung MMI, style guides, Standards

Dokumentation von Anforderungen

• Lastenheft
  • Gesamtheit der Forderungen eines Auftraggebers (AG) an die Lieferungen und Leistungen eines Auftragnehmers (AN), manchmal Vertragsbasis
  • Muss-Kriterien, Kann-Kriterien, Abgrenzungskriterien
• Pflichtenheft
  • Entwurf aus AN-Sicht, Umsetzung des Lastenhefts
  • Meist Vertragsbasis
• Inhalt Anforderungsspezifikation
  • Zielsetzung
  • Allgemeine Beschreibung
    • Umgebung, generelle Funktion, Restriktionen, Benutzer
  • Spezifische funktionale Anforderungen
    • möglichst quantitativ (z.B. Tabellenform)
    • eindeutig identifizierbar (Nummern)
  • Spezifische nicht-funktionale Anforderungen
    • z.B. Antwortzeit, Speicherbedarf, HW/SW-Plattform
    • Entwicklungs- und Produkt-Standards
  • Qualitäts-Zielbestimmung
  • Zu erwartende Evolution des Systems, Versionen
  • Abkürzungsverzeichnis, Glossar, Index, Referenzen

Pflichtenheft (Beispiel)

1. Einleitung, Zielbestimmung
2. Übersicht
   • Einsatzbereich, Zielgruppen
   • Produkt-Umgebung
   • Produkt-Funktionen
   • Restriktionen
   • Annahmen und Abhängigkeiten
   • Vorhandenes System (ggf.)
3. Vorgeschlagenes System
   • Übersicht
   • Funktionale Anforderungen
   • Benutzungsschnittstelle
   • Nichtfunktionale Anforderungen
   • Systembeschreibung
     • Szenarien
     • Anwendungsfälle
4. Glossar

Grobentwurf

Einführung

Systementwurf – Aufgabe

• Sicht des geplanten Systems von innen (Entwickler)
• Wie sollen vereinbartes Verhalten und Funktionen (Analysemodell) intern realisiert werden?
• Von Spezifikation von Anforderungen und Funktionen -> Vorbereitung der Implementierung
• Formal: Transformation des Analysemodells in ein Systementwurfsmodell
• System(grob)entwurf, Feinentwurf/Objektentwurf

Teile und herrsche

• Grobentwurf
  • Entwurfsziele identifizieren
  • Grobe Systemstruktur festlegen (Architektur)
  • Zerlegung in Subsysteme, Spezifikation
    • Schichten, Pakete, Komponenten
  • Bewerten der Zerlegung anhand der Entwurfsziele
  • Schnittstellen festlegen
• Feinentwurf
  • Subsysteme im Detail entwerfen
    • Strukturierung der Komponenten
    • Klassen, Objekte, Funktionen, Datenstrukturen
    • Verhalten, Algorithmen – Teillösungen

Systemzerlegung

Vorgehen

• Zerlegung eines Systems in Subsysteme
• Betrachtung der Lösungsdomäne!
• Subsysteme weiter zerlegen bis Komplexität ausreichend klein ist z.B. für Arbeitspakete

Was macht ein Subsystem aus?

• Schnittstellen, Funktionen, „Verantwortung“
• Was bietet es an?
• Was benutzt es?
• Was tut es intern?

Operation

• Name und Parameter
• Funktion, Prozedur, Methode, Eintrittspunkt ...

Dienst

• Satz von Operationen, die bereitgestellt werden

Abhängigkeiten von Subsystemen

• Subsysteme untereinander: Kopplung (coupling)
• Maß für die Abhängigkeit von Subsystemen

Möglichst lose Kopplung

• Änderungen in einem beteiligten Subsystem haben geringe Auswirkungen (Stabilität)
• Erleichtert Wartbarkeit und Arbeitsteilung

Mittel zur Verringerung der Kopplung

• Zusätzliche Unterteilung in Subsysteme
• Aber: dann größere Komplexität!

Abhängigkeiten von Subsystemen

Kopplungsart	Bemerkung
Datenkopplung (gemeinsame Daten)	Möglichst vermeiden! Wenn nicht möglich, Verwaltung zentralisieren und Zugriff über Schnittstelle
Schnittstellenkopplung (gegenseitiger Aufruf)	Akzeptabel
Strukturkopplung (gemeinsame Strukturelemente)	Vermeiden! (z.B. keine Vererbung über Paketgrenzen hinweg)

• Elemente eines Subsystems: Kohäsion (cohesion)
• Maß für Zusammengehörigkeit der Elemente
• Möglichst hohe Kohäsion
  • Enge Beziehung oder ähnliche Aufgaben der Elemente
  • Erleichtert Verständnis, Wartung und Anpassung
• Mittel zum Erreichen hoher Kohäsion
  • Datenkapselung, Objektorientierung
  • Benutzung geeigneter Patterns (Kapitel 5)

Metriken für modulare Entwürfe

• Fan-in / fan-out-Metrik [S.Henry, D. Kafura 1981]:
  • Fan-in: Anzahl der Stellen, wo Kontrollfluss auf das betrachtete Modul M übergeht (Aufrufe von Funktionen / Prozeduren in M) + Anzahl globaler Variablen, die in M zugänglich sind
  • Fan-out: Anzahl von Stellen, an denen M andere Module aufruft + Anzahl der globalen Variablen, die von M verändert werden
• Heuristik Kopplung / Kohäsion
  • Hoher Fan-out bedeutet hohe Kopplung, minimieren
  • Hoher Fan-in kann auf geringe Kohäsion von M hindeuten

Komplexität beherrschen: "Wenn Du es nicht in fünf Minuten erklären kannst, hast Du es entweder selbst nicht verstanden oder es funktioniert nicht." [Rechtin, Maier: The Art of Systems Architecting 2000]

Vorgehen: Heuristiken und Erfahrungen

• „Erfahrung ist die härteste Lehrerin. Sie gibt Dir zuerst den Test und anschließend den Unterricht.“ [Ruth 1993]
• „Ein Architekt der zu Beginn seiner Arbeit vollständige und konsistente Anforderungen benötigt, mag ein brillanter Entwickler sein – aber er ist kein Architekt“ [Rechtin 2000]
• „Das Leben von Software-Architekten besteht aus einer langen und schnellen Abfolge suboptimaler Entwurfs-entscheidungen, die teilweise im Dunkeln getroffen werden.“ [Kruchten2001]

Wie organisiert man Subsysteme?

• Innerhalb einer Verfeinerungsstufe: fachlich orientierte Zerlegung
• Mehrfache Zerlegung: Hierarchie-Graph der Verfeinerung

Schicht

• Gruppe von Subsystemen in der Zerlegungshierarchie

• Verwandte Dienste

• Ähnlicher Abstraktionsgrad

• Abhängigkeit nur von darunter liegenden!

• Geschlossene Schichtenarchitektur

  • Beispiel: OSI-Modell für Kommunikationssysteme

• Offene Schichtenarchitektur

  • Beispiel: Java Swing auf X11-Plattform

Prinzipien des OO-Entwurfs

• So-einfach-wie-möglich-Prinzip (KISS)
• Fehler berücksichtigen (Strukturierung, Kapselung, Modularisierung, Wiederverwendung)
• Entwerfen nach Verantwortlichkeiten
• Hohe Kohäsion / Geringe Kopplung
• Zyklische Abhängigkeiten vermeiden
• Auf Schnittstellen konzentrieren
  • Abhängigkeiten nur von Schnittstellen
  • Abtrennung von Schnittstellen (eher viele kleine als eine große)
  • Umkehr der Abhängigkeiten (dependency inversion-Prinzip)
• Offen / Geschlossen Prinzip

Zyklische Abhängigkeiten vermeiden

• Änderungen wirken sich auf beide Komponenten aus
• Probleme beim Löschen und Initialisieren
• Auflösen durch
  • Gemeinsame Klassen in separates Paket
  • Gemeinsame Schnittstellen definieren

Symptome schlechten Designs

• Starrheit
  • Einfache Änderungen schwierig realisierbar
  • Einfache Änderungen führen zur Modifikation einer Vielzahl von Komponenten
• Zerbrechlichkeit
  • Änderungen an einer Stelle führen zu Fehlern an völlig anderer Stelle
• Schlechte Wiederverwendbarkeit
  • Komponenten können Aufgrund spezieller Anhängigkeiten kaum wiederverwendet werden

Wann ist ein Entwurf „gut“?

• Korrekt
  • Erfüllung der Anforderungen
  • Wiedergabe aller Funktionen des Systemmodells
  • Sicherstellung der nichtfunktionalen Anforderungen
• Verständlich und präzise, gut dokumentiert
• Anpassbar
• Hohe Kohäsion innerhalb der Komponenten
• Schwache Kopplung zwischen den Komponenten
• Wiederverwendung
• Kriterien gelten auf allen Ebenen des Entwurfs! (Architektur, Subsysteme, Komponenten)

Architekturmodelle

• Modellierung mit UML
  • Bisher: logische Sicht
  • Technisch: Organisation in Paketen, Namensraum, Import
• Paketdiagramm
  • Gliederung (Strukturierung) des Systems in Teile
  • Zuordnung von Elementen zu einem Paket
  • Hierarchien und Abhängigkeiten zwischen den Paketen
  • Anwendung: Definition von Schichten
• Enthält-Beziehung
  • Definiert, in welchem Paket ein Element enthalten ist
  • Ermöglicht qualifizierten Zugriff auf enthaltene Elemente
  • Löschen des Pakets bewirkt Löschen beinhalteter Elemente
  • Definition von Sichtbarkeit / Zugriffsrechte
    • Auswirkung auf weitere Enthält-Beziehung
    • '+' - public (default)
    • '-' - private
• Paket- / Element-Import
  • Unqualifizierter Zugriff auf Elemente eines anderen Namensraums (Paketes)
• Komponentendiagramm
  • Komponente – modulare, austauschbare Einheit
  • Strukturierung des Systems durch Komponenten
  • Modellierung der
    • Abhängigkeiten zwischen Komponenten
    • inneren Struktur von Komponenten
  • Definition von Schnittstellen
  • Verwendung von Elementen aus Klassen- und Objektdiagramm
  • Stärkere dynamische Sicht -> kein Verhalten
  • Komponente <>
    • Kapselt Funktionalitäten (Physisch gruppierte Klassen)
    • „Spezialisierte“ Klasse (Vererbung, Exemplare möglich)
    • Stellt Funktionalitäten über Schnittstellen bereit
    • Definiert benötigte Schnittstellen
    • Enthält Klassen oder weitere Komponenten
    • Modulares Element: Substitution (Austauschbarkeit) steht im Vordergrund
  • Black-Box-Darstellung
    • Zur Verfügung gestellte Funktionalität <<provided interfaces>>
    • Benötigte Funktionalität <<required interfaces>>‚
  • White-Box-Darstellung
    • Interner Aufbau der Komponente <<realization>>
    • Artefakte <<artifacts>>‚ Realisierende physische Einheit (z.B.: .dll)

Schnittstellen / Interfaces

• Definition Diagrammunabhängig
  • Meist Klassendiagramm
• Ähnlich Semantik einer Klasse
  • Nur public-Attribute und Operationen
• Definiert Verpflichtung zur Implementierung von
  • Operationen
  • Merkmale -> Attribute dürfen definiert werden
  • Verpflichtungen (z.B.: Vor- / Nachbedingungen)
• Meist abstrakte Klassen mit abstrakten Operationen
• Abstrakt – muss überschrieben werden
• Notation
  • Stereotyp: <>
  • Meist kursiv geschrieben, da abstrakte Klasse

Schnittstellenrealisierung, Implementierungsbeziehung

• Schnittstellen werden realisiert, nicht instanziiert
• Schnittstellenkonform
  • Klasse realisiert alle Attribute und Operationen
• Schnittstelle kann von anderen Schnittstellen erben
• Keine Schnittstellenrealisierung zwischen zwei Interface-Klassen -> Generalisierung verwenden
• Darstellung
  • Gestrichelte Linie mit nicht gefülltem Dreieck an der Seite der Superklasse
  • Alternativ: Lollipop-Darstellung

Softwarearchitekturmuster

• Wiederverwendung auf sehr hoher Abstraktionsstufe
• Falls geplante Anwendung passt, anwenden!

Schichten-Architektur (layers)

• Problem
  • Komplexität: Strukturierung des Systems, unterschiedliche Abstraktionsebenen
  • Änderungen sollen möglichst lokal bleiben
  • Teilsysteme sollen austauschbar, wiederverwendbar und getrennt entwickelbar sein
  • Schnittstellen sollen stabil sein
• Lösung
  • Zuordnung von Subsystemen zu horizontalen Schichten gleicher Abstraktionsebene
  • Komponenten einer Schicht bieten Dienste der darüber liegenden Schicht an

Client-Server (Klient/Anbieter)

• Client (front-end)
  • Benutzungsschnittstelle
  • Einbindung in Geschäftsprozesse
  • Entkoppelt von Netztechnologie und Datenhaltung
• Server (back-end)
  • Datenhaltung, evtl. Fachlogik
• Genauer: Two-tier client/server architecture
• Asynchroner Kontrollfluss
• Aufteilung Funktionen Client / Server
  • Mehr Funktionen im Server:
    • zentrale Verwaltung, Wartungsaufwand geringer, Portabilität, einfache Client-Hardware (Net PC)
    • „Thin Client“ – nur GUI
  • Mehr Funktionen im Client: Flaschenhals Server wird entlastet, individuellere Client-Funktionen
    • „Fat Client“ – Teil der Anwendung im Client
  • Entscheidet mit über Umsetzung (Java Script, ...)

Three-Tier / Four-Tier Architecture

• Client/Server mit weiterer Aufteilung ähnlich Repository

Bewertung Client-Server

• Vorteile
  • Leicht verständlich
  • Änderungen bleiben lokal
  • Geringere Kopplung zwischen den Schichten
  • Schichten austauschbar und wiederverwendbar
  • Getrennte Entwicklung der Schichten möglich
  • Vorhandene / stabilere Schnittstellen
• Nachteile
  • Geringere Performance
  • Zusätzlicher Verwaltungs- oder Datenoverhead
  • Manche Änderungen führen zu Änderungen in allen Schichten (z.B. neues Datenfeld)

Pipes and Filters

• Datenstrom- oder Kontrollflussorientiertes System
• Lose verbundene Berechnungskomponenten
• Kombination der Berechnungskomponenten nur vom Typ der Ein- und Ausgabedaten abhängig
• Leicht erweiterbar System gewünscht
• Parallele Verarbeitung vorteilhaft
• Verwendung von globalen Steuerungskontrollstrukturen (Parallelisierung, Verzweigung, Schleifen) gewünscht
• Vorteile
  • Stark entkoppelte Komponenten
  • Hohe Flexibilität gegenüber Änderungen & Erweiterungen
  • Hoher Wiederverwendungsgrad der Komponenten
  • Unabhängige Entwicklung der Komponenten
  • Leichte Parallelisierung der Berechnungen möglich
  • Überprüfung der Datenkompatibilität dynamisch / statisch
• Nachteile
  • Schwierige Fehlerbehandlung, kein expliziter Kontrollfluss
  • Fehler durch inkompatible Datentypfehler erst zur Laufzeit
  • Häufig zusätzliche Datenkonvertierungen notwendig

Plug-In Architektur (Microkernel)

• Zielstellung
  • Stabile, verbreitete Standard-Anwendung (Kern)
  • Funktionalität soll durch Komponenten leicht erweiterbar sein
  • Dritte sollen Komponenten leicht erstellen können
• Lösung
  • Möglichst schlanker zentraler Kern
  • Plugin-Manager verwaltet Komponenten: Laden, Entladen, Zugriffskontrolle, Konfiguration
• Plugin
  • Komponente mit Standard-Schnittstelle
  • Erweitert Funktionalität (extension point)
• Vorteile
  • Robustes Verhalten
  • Trennung der Zuständigkeiten
  • Erweiterbar, Austauschbar, Wiederverwendbar
  • Geringe Kopplung zu den Komponenten
  • Anpassung an eigene Bedürfnisse möglich
  • Leichte Aufteilung der Entwicklung der Arbeitspakete
• Nachteile
  • Höherer initialer Aufwand
  • Verwaltungsoverhead zur Laufzeit
  • Versionsverwaltung der Komponenten nötig
  • Abhängigkeiten unter den Komponenten schwierig realisierbar
  • Geschickte Definition der Extension Points nötig

Repository (Depot, blackboard)

• Zentrale Datenhaltung
  • Datenbankmanagementsystem, Dateisystem
• Anwendungen tauschen Daten nur über Repository aus
• Kontrollfluss z.B. über Signale oder Semaphore
• Gut für datenintensive Verarbeitungsaufgaben geeignet

Peer-to-peer

• Gleichberechtigte Partner, “Föderation”
• Verteilte kommunizierende Subsysteme
• Orts- und Umgebungsunabhängigkeit

Model-View-Controller (MVC)

• Modell / Sicht / Steuerung
• Trennung verschiedener Aufgabengebiete:
  • Model: verwaltet Domänenwissen, Daten und Zustand; häufig Datenbank
  • View: Darstellung, Anzeige, GUI
  • Controller: Steuerung der Interaktion, Nutzerbefehle
• Erlauben Austausch von Anzeige- und Speichersystem
• Kontrollfluss
  • Controller steuert
  • View wird über Datenänderungen benachrichtigt (callback)
• Geeignet für interaktive Systeme
• Problem
  • Lose Kopplung zwischen verschiedenen Komponenten
  • Daten werden in verschiedenen Sichten dargestellt
  • Realisierung von GUI‘s
• Lösung durch drei Komponenten
  • Daten (Model) enthält die Kernfunktionalität / Durchführung der Geschäftsprozesse, kapselt und Speichert die Daten
  • Sichten bzw. Dialoge (View) stellt die Daten für den Anwender in unterschiedlicher Art dar
  • Logik bzw. Steuerung (Controller) Realisiert die Interaktion mit dem Benutzer, übernimmt die Eingaben vom View und ändert die Daten im Modell, legt die Darstellungsart der Sichten fest
• Vorteile
  • Unabhängige Entwicklung der Komponenten
  • Änderung der Oberfläche ohne Änderung des Modells
  • Unterschiedliche Oberflächen für das selbe Modell
• Nachteile
  • Performance
  • Erhöhter initialer Entwicklungsaufwand

Frameworks

Was ist ein Framework?

• A framework is a set of prefabricated software building blocks that programmers can use, extend, or customize for specific computing solutions [Taligent]
• Ein framework (Rahmenwerk, Anwendungsgerüst) ist eine Menge von zusammengehörigen Klassen, die einen abstrakten Entwurf für eine Problemfamilie darstellen [nach Pomberger/Blaschek]

Ziele

• Wiederverwendung von Code, Architektur, Entwurfsprinzipien und Verhaltensschema
• Ähnliche Benutzungsschnittstelle

Klassifikation I

• Anwendungs-Framework (application framework)
  • Gibt Systemarchitektur für typische Anwendungsstruktur vor
  • GUI-Framework: Motif, Qt, Swing, ...
• Bereichsspezifisches Framework (domain framework)
  • Expertenwissen für Anwendungsbereich
  • für typische Anwendungen u.a. in den Bereichen Luftfahrt, Produktion, Finanzwesen, Automotive, ...
  • Beispiel: AUTOSAR
• Infrastrukturgerüst (support framework)
  • Gerätetreiber, Anpassung an Hardware
  • Middleware: DCOM, Java RMI, CORBA, WebSphere, ...

Klassifikation II

• Offene Programmgerüste (white box)
  • Erweiterbarkeit durch Vererbung und dynamische Bindung
  • Funktionen konkretisieren durch Ableitung von Basisklassen des Programmgerüsts und Überschreiben vordefinierter Methoden
• Geschlossene Programmgerüste (black box)
  • Erweiterbarkeit durch Definition von Schnittstellen für Module, die für eine konkrete Anwendung in das Gerüst eingesetzt werden können
  • Wiederverwendung durch Komponenten, die sich an Schnittstellen halten; Aufruf über Delegation

Webframeworks – Angular JS

• Clientseitiges Webframework von Google

• Frei verwendbar (Open Source)

• Erstellung von Single-Page-Webanwendungen

• Model View Prinzip

• Vorteile

  • Weitergabe von Expertenwissen
  • Durchdachtes Design: langfristige Aufwandsersparnis
  • Wartungsaufwand reduziert, systematische Tests möglich
  • Prinzipiell sehr hohe Produktivität möglich
  • Erleichtert Integration und Konsistenz verwandter Anforderungen

• Nachteile

  • Erstellung und Einarbeitung aufwändig
  • Zusätzlicher Dokumentations- und Wartungsaufwand
  • Fehlersuche erschwert durch Overhead des Frameworks
  • Kombination verschiedener Frameworks sehr schwierig

Systemarchitektur und Verteilung

Systemarchitektur

• Aufbau und Elemente der Ablaufumgebung, Hardware
• Häufig enger Zusammenhang mit Softwarearchitektur
  • Architekturmuster
  • Ablaufmuster
• Besonders bei eingebetteten Systemen
• Systemarchitektur hat Einfluss auf Softwarearchitektur
  • Grenzobjekte, Schnittstellen, ...
• Gute Systemarchitektur?
  • Nichtfunktionale Anforderungen
  • Modellierung und Simulation, Lastmessungen

Typische Strukturen

• Zentralrechner (mainframe) mit Terminals

• Server und einfache Stationen

• PCs und Server

• Kommunikationsverbindungen, Sensoren, Speicher, ...

• Blockdiagramm

  • Klassisches Beschreibungsmittel für Systemaufbau
  • Nicht Teil von UML

• Konfigurationsdiagramm

  • meistverbreitetes Hilfsmittel zur Beschreibung der physikalischen Verteilung von System-Komponenten
  • Nicht Teil von UML

• Verteilungsdiagramm (UML deployment diagram)

  • Darstellung der Hardwaretopologie
  • Zuordnung von Artefakten zu Hardwareeinheiten (Knoten)
    • Verteilung von Systembestandteilen auf Hardware
  • Kommunikationsverbindung und Abhängigkeiten zwischen Knoten
  • Relativ spät im Projekt Installation / Wartung des Systems

Globaler Kontrollfluss

Globaler Kontrollfluss

• Ablaufsicht der Architektur
  • Definition nebenläufiger Systemeinheiten (z.B. Prozesse)
  • Steuerung der Abfolge von Einzelfunktionen
  • Synchronisation und Koordination
  • Reaktion auf externe Ereignisse
  • Darstellung z.B. durch Sequenzdiagramme
• Nebenläufigkeit auf Architekturebene
  • Threads , Prozesse, verteiltes System
  • Asynchroner Nachrichtenaustausch
• Einfluss auf Architektur / abhängig von Architektur!
• Ablaufmuster
  • Zentral
    • Call/Return (prozedural, synchron)
    • Master/Slave (nebenläufig mit zentraler Steuerung)
  • Dezentral
    • Ereignisgesteuert (event-driven)
      • interrupts
      • publish-subscribe (ähnlich observer)
      • (selective) broadcast
    • Datenflussgesteuert (data flow architecture)

Sonstiges

Ablauf des OO-Systementwurfs [B. Oesterreich]

• Schichtenmodell definieren
• Verteilungsmodell definieren
• Fachliches Subsystemmodell definieren
• Ablaufverantwortlichkeiten definieren
• Komponentenspezifisches Klassenmodell entwickeln
• Komponentenschnittstelle entwerfen
• Zustandsmodelle weiterentwickeln
• Objektfluss modellieren
• Interaktionsmodelle entwickeln, Attribute definieren
• Dialoge spezifizieren
• Design-Diskurs
• Testgetriebene Entwicklung

Weitere Aufgaben beim Grobentwurf

• Entwurf einer persistenten Datenverwaltung
  • Dateisystem, Datenbank
• Sicherheit
  • Zugriffskontrolle
  • Fehlertoleranz (Daten und Hardware)
  • Protokollfunktionen
• Kontrollfluss
  • Ausnahmen
  • Starten, Initialisieren und Beenden der Anwendung
  • „Randanwendungsfälle“

Notwendigkeit der Architekturdokumentation

• Quellcode aufgrund niedrigen Abstraktionsniveaus ungünstig für Dokumentation
• Überblick und Arbeitsteilung
• Lebensdauer von Systemen länger als geplant
• Fehler und Probleme leichter finden und beseitigen
• Neue Anforderungen mit angemessenem Aufwand erfüllen
• Vereinfachung der Wartung, Pflege, Erweiterung, Wiederverwendung

Dokumentation

• Grundprinzipien
  • Verständlich aus Sicht des Lesers formulieren (Glossar)
  • Das Warum beschreiben (Entwurfsentscheidungen)
  • Annahmen, Voraussetzungen, Randbedingungen dokumentieren
  • Wiederholungen vermeiden
  • Notation erklären oder Standards verwenden (UML)
    • Legende hinzufügen
  • Auf Zweckdienlichkeit prüfen, Reviews durchführen (Inhalt, Qualität)
  • Verschiedene Sichten für verschiedene Zielgruppen

Feinentwurf

Analyse-Modell	Entwurfs-Modell
Fachliche Domäne	Lösungsdomäne
Teilweise unvollständig in Attributen und Operationen	Vollständige Angabe aller Attribute und Operationen
Datentypen und Parameter können noch fehlen	Vollständige Angabe von Datentypen und Parametern
Noch kaum Bezug zur Realisierungssprache	Auf Umsetzung in gewählter Programmiersprache bezogen
Keine Überlegungen zur Realisierung von Assoziationen	Navigationsangaben, Qualifikation, Ordnung, Verwaltungsklassen
	Entscheidung über Datenstrukturen, Anbindung GUI

Schließen der Lücke zwischen Grobentwurf und Implementierung

• Identifizieren und Entwerfen von Klassen der Lösungsdomäne
• Identifikation und Verwendung von Entwurfsmustern
• Detaillierte Beschreibung der Klassen
• Beschreibung von Schnittstellen
• Iterativer Prozess!
  • Verbesserung des Entwurfs – Refactoring
  • Optimieren des Entwurfsmodells zur Erfüllung nichtfunktionaler Anforderungen

Objektorientierter Feinentwurf

• Ausgangspunkt
  • Grobdefinition der Architektur, Zerlegung in Subsysteme (evtl. unter Verwendung von Standardarchitekturen)
  • Verteilungskonzept
  • Ablaufmodell
• Ergebnis
  • OO-Modell für jedes Subsystem der Architektur
  • OO-Modell für unterstützende Subsysteme unter Berücksichtigung gewählter Technologien
  • Spezifikationen der Klassen
  • Spezifikationen von externen Schnittstellen

Klassen- und Objektentwurf

• Klassen der Lösungsdomäne
  • Klassen, die nicht durch objektorientierte Analyse der Anwendungsdomäne entstehen
• Entstehungsgründe
  • Architektur von Software und System
  • nichtfunktionale Anforderungen
  • Beispiele: Kommunikation, Fehlertoleranz, Adapter, Datenhaltung, Effizienz, Benutzerschnittstellenobjekte, Middleware, ...
  • Sichtbare (Grenz- und Steuerungsobjekte) werden schon in der Analyse identifiziert

Klassen identifizieren (responsibility-driven design (Wirfs-Brock, McKean))

Verantwortlichkeits-Prinzip: Sichtweise: Objekte und Klassen sind nicht nur Behälter für Verhalten und Daten, sondern erfüllen in Zusammenarbeit mit anderen Objekten bestimmte Aufgaben eigenverantwortlich

Responsibility-Driven Design – Begriffe

• Sichtweise auf Softwaresystem
• Application = set of interacting objects
• Object = implementation of role(s)
• Role = set of related responsibilities
• Responsibility = obligation to perform a task or know information
• Collaboration = interaction of objects or roles
• Contract = agreement outlining collaboration terms

Arten von Rollen

Information holder	knows and provides information
Structurer	maintains relationship between objects and information about relationships
Service provider	performs work, offers computing services
Coordinator	reacts to events by delegating tasks to others
Controller	makes decisions and directs other’s actions
Interfacer	transforms information and requests between system parts

Hilfsmittel: CRC-Karten

• Candidate (or class), Responsibility, Collaboration
• Informelles Mittel zum
  • Finden,
  • Beschreiben und
  • iterativen Verändern von Klassen

Ein Objekt

• implementiert eine Schnittstelle und beeinflusst andere Objekte
• wird in drei Teilen entworfen
  • Öffentliche Schnittstelle
  • Art und Weise der Benutzung
  • Innere Details der Funktionsweise
• Kohärenz: zusammengehörende Verantwortlichkeiten in einer Klasse konzentrieren!

Entwurfsprinzipien

• Kapselung
  • Probleme: Zugriff auf private oder ebenen-fremde Attribute
  • Verwenden von get- und set-Operationen
  • Zusicherungen einhalten
  • Zugriffe zentralisieren
  • Verbalisierung
  • Zugriffsbeschränkung
• Zerlegung
  • Teile und Herrsche
  • Zerlegen in Komponenten
  • Verantwortlichkeitsprinzip: Komponente ist klar für eine Aufgabe verantwortlich
  • Eigenschaften und Schnittstellen im Klassendiagramm
  • Beziehungen zwischen Klassen: Assoziationen
  • Aggregation
    • „besteht aus“, „ist Teil von“ oder „Ganzes-/Teile-Beziehung“
    • Schwache Bindung der Teile mit dem Ganzen
    • Notation: ungefüllte Raute am Ganzen
  • Komposition
    • Wie Aggregation, jedoch stärkere Bindung
    • Teil nur einem Ganzen zugeordnet
    • Nur Multiplizität von 1 oder 0..1 möglich!
    • Gefüllte Raute am Ganzen
• Polymorphie
  • Reaktion auf eine Nachricht abhängig vom Typ des Objektes
  • Variablen können Objekte verschiedener Klassen aufnehmen (Voraussetzung: Typ der Variablen ist eine gemeinsame Basisklasse der (davon) abgeleiteten Klasse(n) der Objekte)
  • Überladen von Operationen
    • gleicher Operationsname, unterschiedliche Signatur
  • abstrakte Operationen: Virtuelle Operationen ohne Implementierung
  • abstrakte Klasse: Klasse mit abstrakten Operationen
  • Folgen
    • von abstrakten Klassen können keine Objekte angelegt werden (Implementierung fehlt)
    • Abgeleitete Klassen müssen Operation implementieren, damit Objekte angelegt werden können

Vererbung im Entwurf

• In der Analyse: Klassifikation von Objekten, Taxonomie, Spezialisierung/Verallgemeinerung, Organisation von Klassen in Hierarchien
• Verringerung von Redundanz und damit Inkonsistenzen
  • Funktionalität nur einmal implementieren!
  • Spezifikations-Wiederverwendung
  • Implementierungs-Wiederverwendung
• Verbesserung der Erweiterbarkeit
  • Abstrakte Schnittstellen einsetzen!

Vererbung oder Assoziation

• Schlüsselwort Vererbung: ist ein
• Schlüsselwort Assoziation: besteht aus, ist Teil, hat,...
• Vererbung: Unterscheidungsmerkmal definierbar (Diskriminator)
• Vermeide Vererbung, wenn es Alternativen gibt
• Mehrfachvererbung
  • Problem: Unabhängige Aspekte der Vererbungshierarchie
  • Vermeidung: abstrakte Klassen oder Komposition

Abstrakte Klassen

• Nur Unterklassen, keine Instanzen
• Attribute in Unterklassen füllen
• Notation: Kursiv oder Stereotyp <>

Offen / Geschlossen-Prinzip [Meyer 1988]

• Erweiterbarkeit eines Entwurfs
• Offen für Erweiterungen,
  • z.B. durch Vererbung / Polymorphie
  • Virtuelle Operationen verwenden
  • Verändert vorhandenes Verhalten nicht
  • Erweiterung um zusätzliche Funktionen oder Daten
• Geschlossen für Änderungen
  • private Attribute
  • Möglichst protected Operationen
• Beschränkung der Erweiterbarkeit
  • Keine Einschränkungen der Funktionalität der Basisklasse!

Liskovsches Ersetzungsprinzip

• Wenn S eine Unterklasse von T ist, dann können Objekte des Typs T in einem Programm durch Objekte des Typs S ersetzt werden, ohne die Funktion des Programms zu verändern. [Barbara Liskov 1987]
• Engere Definition als „ist-ein“-Beziehung
• Kein unerwartetes Verhalten eines Objektes eines Subtyps
• Methoden, die Objekte der Basisklasse erwarten, müssen auch mit Objekten der abgeleiteten Klasse funktionieren
• Zusicherungen der Basisklasse müssen von der abgeleiteten Klasse erfüllt werden!

Gesetz von Demeter (LoD)

• Gesetz von „schüchternen“ Objekten
• Objekte sollen nur mit Objekten in ihrer unmittelbaren Umgebung kommunizieren
• Aus einer Methode M dürfen (sollten) nur Nachrichten an Objekte gesendet werden, die ...
  • unmittelbarer Bestandteil des Objekts von M sind (super)
  • M als Argument übergeben wurden
  • direkt in M erzeugt wurden
  • (oder sich in globalen Variablen befinden)
• Als Metrik überprüfbar

Ein Objekt sollte

• Nur Methoden aufrufen, die zur eigenen Klasse gehören
• Nur Methoden von Objekten aufrufen, die:
  • Von Attributen referenziert werden
  • Als Parameter übergeben wurden
  • Selbst erzeugt wurden

Entwurfsmodelle

Klassendiagramm

• Eigenschaften
  • Modellierung der statischen Struktur (Aufbau)
  • Modellierung der Struktur von Daten
  • Klasse im Mittelpunkt (Aufbau, Beziehungen zueinander)
  • Wichtigstes und bekanntestes Diagramm der UML!
• Elemente des Klassendiagramms
  • Klasse (Attribute, Operationen)
  • Vererbung / Realisierung
  • Assoziationen
  • Beziehungen / Abhängigkeiten
• Attribute
  • Klassenattribut: "X" static – statisch, nur einmal pro Klasse vorhanden
  • Sichtbarkeit
    • "+" public – im Namensraum sichtbar
    • "#" protected – nur in abgeleiteten Klassen sichtbar
    • "~" package – im Paket sichtbar
    • "-" private – nur in der Klasse selbst sichtbar
  • Ableitung "/" derived – abgeleitetes Attribut
• Weitere Eigenschaften
  • readOnly – nach Initialisierung nicht änderbar
  • composite – Aggregation: Composition
  • redefines X – überschreibe Attr. der Oberklasse
  • subsets X – Teilmenge
  • union – Attribut ist Vereinigung der subsets
  • unique – Elemente eindeutig (Schlüsselattribut)
  • ordered – Elemente sind geordnet (unordered)
  • sequence – Speicherung der Elemente als Liste
  • bag – Elemente sind Multimenge

Schnittstellen

Entwurfsmuster

Klassenbibliotheken und Komponenten

Dokumentation

Implementierung

Vorgehensweise

Projektmanagement