Softwarearchitektur und Design

Vorlesung Softwaretechnik

• Vorlesung zum Thema Software- und Systementwurf
• Dozent: Prof. Bernhard Rumpe, Software Engineering, RWTH Aachen
• Webseite: http://www.se-rwth.de/
• Thema: Entwurfsprinzipien

Warum, Was, Wie und Wozu? Entwurfsprinzipien

• Warum:
  • Hochgradig praxisrelevant
  • Von der Analyse zum Entwurf kommen
  • Optimale Technologie gibt es nicht
• Was:
  • Grobentwurf: Architektur, Subsysteme und Schnittstellen
  • Feinentwurf: Komponenten, Datenstrukturen, Algorithmen
• Wie:
  • Problem in kleine Einheiten zerlegen
  • Komponenten realisieren und zusammensetzen
  • Softwarearchitekturen und Taktiken
• Wozu:
  • Vorbereitung für die Implementierung großer komplexer Systeme
  • Teams entwickeln die Systeme
  • Kommunikation mit Stakeholdern

Gliederung des Entwurfsprozesses

• Architektur-Entwurf
• Subsystem- & Schnittstellen-Spezifikation
• Komponenten-Entwurf
• Datenstruktur-Entwurf
• Algorithmen-Entwurf
• Grobentwurf (weitgehend unabhängig von Implementierungssprache)
• Feinentwurf (angepasst an die Implementierungssprache und Plattform)
• Gesamtstruktur des Systems (Grobentwurf)
• Detailstruktur des Systems (Feinentwurf)

Arbeitsteilung beim Entwurf

• Architekturentwurf
• Entwurfsschnittstelle 1-2
• Entwurfsschnittstelle 2↔...
• Entwurf Subsystem 1
• Entwurf Subsystem 2
• Entwurf Subsystem ...
• Entwurf der Komponenten

Kriterien für „guten“ Entwurf

• Korrektheit (Erfüllung funktionaler und nichtfunktionaler Anforderungen)
• Verständlichkeit und Präzision
• Gute Dokumentation
• Anpassbarkeit
• Hohe Kohäsion innerhalb der Komponenten
• Schwache Kopplung zwischen den Komponenten
• Wiederverwendung

Kohäsion

• Kohäsion ist ein Maß für die Zusammengehörigkeit der Bestandteile einer Komponente
• Hohe Kohäsion erleichtert Verständnis, Wartung und Anpassung
• Kohäsion wird erreicht durch:
  • Prinzipien der Objektorientierung (Daten & Methodenkapselung)
  • Einhaltung von Regeln zur Paketbildung
  • Verwendung geeigneter Muster zur Kopplung und Entkopplung
• "Kohärente" Klasse: Keine Partitionierung in unabhängige Untergruppen von zusammenhängenden Operationen und Attributen

Grade der Kohäsion

• Zufällig (beliebige Bestandteile)
• Logisch (ähnliche Funktionen)
• Zeit/Zeitlich (gleiche Ausführungszeit)
• Ablauf/Prozedural (geschlossene Ablauffolge)
• Aufruf/Sequentiell (Ausgabe eines Bestandteils=Eingabe eines anderen)
• Daten/Kommunikativ/Informativ (gemeinsame Daten)
• Funktional (einzige Gesamtfunktion)

Kopplung

• Kopplung ist ein Maß für Abhängigkeiten zwischen Komponenten
• Geringe Kopplung verbessert Wartbarkeit und Stabilität
• Arten der Kopplung: Datenkopplung, Schnittstellenkopplung, Strukturkopplung
• Reduktion der Kopplung: Vermeidung von Datenkopplung, bevorzugte Schnittstellenkopplung, Vermeidung von Strukturkopplungen

Wiederverwendung

• Wiederverwendung (Reuse) ist die Nutzung von Gemeinsamkeiten zwischen Komponenten
• Reduktion der Redundanz
• Erhöhung von Stabilität und Ergonomie
• Hilfsmittel: Vererbung, Parametrisierung, Module/Objekte mit allgemein nutzbaren Schnittstellen

Framework

• Software, durch Callback-Methoden erweiterbar
• Subklassen werden gebildet und dem Framework zugewiesen
• Aufrufe finden in entgegengesetzter Richtung statt (Framework ruft Applikation auf)

Referenzmodelle und -architekturen

• Referenzmodell: Logische Aufteilung der Systeme einer Domäne (Subsysteme, Verbindungen)
• Referenzarchitektur: Abbildung eines Referenzmodells auf Softwarekomponenten (Datenfluss, Kommunikation, technische Aspekte)
• Gruppierung von logischen Elementen auf Softwarekomponenten
• Logische Elemente können mehrfach repliziert sein

Beispiel: Referenzmodell für Workflowmanagement Systeme

• Darstellung eines Referenzmodells für Workflowmanagement Systeme mit verschiedenen Interfaces und Komponenten.
• Darstellung eines Beispiels für Zustandsübergänge eines Prozesses.

Stakeholder

• Kunden, Endnutzer, Entwickler, Projektmanager, Wartungspersonal, Vermarktung/Verkauf
• Alle am Projekt direkt oder indirekt beteiligten Personengruppen

Einfluss der Stakeholder auf die Softwarearchitektur

• Management (Niedrige Kosten, gleichmäßige Auslastung des Teams)
• Nutzer (Performance, Sicherheit, Verlässlichkeit, Nutzbarkeit)
• Softwarearchitekt (Modifizierbarkeit, Erweiterbarkeit)
• Wartungsteam (Niedrige Kosten, schnelle Auslieferung, kaum Nachbesserungen)
• Marketing (Time to Market, Features, Konkurrenzneutrale Anpassbarkeit)
• Kunde (Produktqualität, Aktualisierung, Anpassung)

Nutzen einer Architekturbeschreibung

• Kommunikation der Stakeholder (gemeinsame Sprache)
• Wesentliche Entwurfsentscheidungen
• Wiederverwendbare Abstraktion (Produktlinien)
• Fokus auf spezifische Systemeigenschaften (getrennte Betrachtung der Aspekte)
• Frühzeitige Analysemöglichkeiten (Prototypen...)

Architektur-Beispiele

• Physikalische Architekturen (Netzwerkarchitektur, Standalonearchitektur)
• Schichtenarchitektur (innerhalb eines Systems)
• Referenzmodell für Workflowmanagement Systeme

Conway´s Law

• Die Struktur eines Systems spiegelt die Kommunikationsstruktur des Entwicklungsteams wider
• Ansatz für bessere Architektur: Inverse Conway Maneuver (Entwicklungsorganisation an die erwünschte Architektur anpasst)
• Beispiele für unterschiedliche Organisationsstrukturen (Amazon, Google, Facebook, Apple, Oracle)

Analogie: Hausbau

• Ein Haus lässt sich durch verschiedene Pläne beschreiben
• Jeder Plan hat eine bestimmte Aufgabe und unterschiedliche Zielgruppen

Sicht (UML)

• Darstellung eines Systems mit relevanten Elementen und Beziehungen
• Verfeinerung, Abstrahierung, Übersichtlichkeit der Darstellung
• Konsistenz zwischen Sichten, Vollständigkeit, Abstraktionsfähigkeit, Übersicht, Realitätstreue, Beschreibungssprachen

4+1 Sichten-Modell (RUP)

• Logische Sicht, Struktursicht, Ablaufsicht, Szenarien, Physikalische Sicht
• Modellierungstechniken und Kern-Elemente
  • Logische Sicht: Klassenmodell, Verfeinerung des Analysemodells
  • Struktursicht: Subsysteme, Schnittstellen, Grobentwurf
  • Ablaufsicht: Prozesse, Koordination, Feinentwurf
  • Szenarien: Use-Cases
  • Physikalische Sicht: Komponenten, Hardwaresysteme, Netze, Feinentwurf

Primäre Zielgruppe/Aufgabe jeder der vier Sichten

• Logische Sicht: Endanwender
• Struktursicht: Programmierung, Wartung
• Ablaufsicht: System-Integratoren (Performanz, Durchsatz...)
• Physikalische Sicht: Kommunikation, Verteilung, Auslieferung, Installation
• Feinentwurf: Detaillierter Entwurf für die Implementierung

Blockdiagramm

• Graphische Darstellung der logischen Struktur eines Systems
• Subsysteme, Schnittstellen, Kommunikationsprotokolle

UML: Implementierungsdiagramm

• Zusammengesetzte Komponenten
• Schnittstellen, die diese Komponenten verbinden

Konfigurationsdiagramm

• Darstellung der physikalischen Verteilung von Systemkomponenten (Rechner, Knoten, lokales Kommunikationsnetz, Datenkommunikationsnetz)

UML: Verteilungsdiagramm

• Physische Verteilung von Systemen
• Knoten, Stereotypen, Komponentenzuordnung

Beispiel Terminverwaltung

• Blockdiagramm der physikalischen Konfiguration eines Terminverwaltungssystem (PCs, PDA, Terminserver, Anzeigetafel-Steuerung, Termin-Datenbank)

Was haben wir gelernt?

• Softwarearchitektur (Struktur, Komponenten, Schnittstellen, Beziehungen)
• Softwarearchitekt (Team/Person, Erfahrung, Stakeholder-Interessen)
• Nutzen (Kommunikation, Entwurf, Abstraktion, Fokus, Frühzeitige Analysis)

Taktiken (in Softwareentwurf)

• Technik zur Veränderung von Qualitätsattributen (Verfügbarkeit, Modifizierbarkeit, Performance, Sicherheit, Testbarkeit, Usability)
• Beispielsweise zur Optimierung der Verfügbarkeit von Systemen (Fehlererkennung, Redundanz)
• Beispiele für Taktiken für Modifizierbarkeit (Kapselung, Reduktion der betroffenen Komponenten, Antizipieren von Änderungen)
• Beispiele für Taktiken für Sicherheit

Problem: Verfügbarkeit

• Begriffsbildung:
  • Failure (beobachtbarer Fehler eines Systems)
  • Fault (interner Fehler)
• Mean Time To Repair (MTR), Mean Time To Failure (MTF), Verfügbarkeit
• Geplante Wartungsarbeiten werden nicht gerechnet

Taktiken für Verfügbarkeit

• Fehlererkennung (Exception, Delegation, Ping/Echo, Heartbeat)
• Fehlerbehandlung (Abstimmen, Aktive Redundanz, Passive Redundanz, Ersatzteile)
• Redundante Komponente wiedereinführen
• Zustands-Resynchronisation
• Checkpoint/Rollback

Problem: Modifizierbarkeit

• Modifizierbarkeit (Messbar durch Zeit/Kosten für Implementierung, Testen, Auslieferung von Änderungen)
• Erschwernisse durch Abhängigkeiten von Komponenten, fehlende Lokalisierung von Funktionalität
• Ripple-Effekt (Änderungen an einer Komponente führen zu unerwarteten Auswirkungen an anderen Komponenten)

Taktiken für Modifizierbarkeit

• Kapselung / Hohe Kohäsion
• Vermittler (Broker)
• Reduktion der notwendigen Änderungen

Taktiken für Sicherheit

• Securing the Weakest Link (Analyse des schwächsten Gliedes der Sicherheitskette)
• Failing Securely (Standardmäßige Verweigerung von Zugriffen, explizite Gewährung von Zugriffsrechten)
• Least Privilege (Benutzer/Funktionen erhalten nur notwendige Rechte/Ressourcen)
• Economy of Mechanism (einfache Sicherheitsmechanismen)

Was haben wir gelernt?

• Qualitätsattribute (Verfügbarkeit, Modifizierbarkeit)
• Taktiken zur Verbesserung von Qualitätsattributen (Beispiele für unterschiedliche Techniken)
• Entwurf von Oberflächen (Benutzerverhalten, Interaktionsarten, Darstellung von Informationen)
• Prototyperstellung, Evaluation.

Entwurf von Nutzeroberflächen

• Warum, Was, Wie, Wozu (Entwurfsgrundsätze)
• Beispiele für Interaktionsarten (Direkte Manipulation, Menüauswahl, Eingabemasken, Befehle, Natürliche Sprache)

Darstellung von Informationen

• Arten der Darstellung (textuell, graphisch)
• Richtlinie, Entkopplung der Darstellung und Daten Darstellung
• MVC-Modell (Model-View-Controller) für die Benutzerinteraktion

Informationen, die sich nicht verändern

• Text (genaue Angaben, relativ langsame Änderungen)
• Graphische Darstellung, schnell ändernde Daten

Dynamisch ändernde Informationen

• Analoge Darstellungen (Skala, Zeiger, Tortendiagramm, Thermometer, Balken)
• Kontinuierliche analoge Anzeigen des Bezuges zu Maximalwerten

Große Informationsmengen

• Abstrakte Anzeigeformen, Verknüpfung von in Beziehung stehenden Daten (Zwei-/Dreidimensionale Darstellung, Bäume, Netze, Karten)

Farben

• Richtlinien für die Verwendung von Farben (Anzahl, Kontext, Farbcodes)

Entwurf von Systemmeldungen

• Kontext, Erfahrung, Fähigkeiten, Stil (positiv, aktiv, klar, präzise)

Klassifikation von Prototyping

• explorativ, experimentell, evolutionär

Mögliche Vorgehensweise zum Entwurf von Oberflächen

• Nutzeraktivitäten analysieren und verstehen
• Fachliche Prototypen, dynamische Prototypen, Ausführbare Prototypen, Beurteilung durch Endanwender

Benutzeranalyse

• Analyse der Benutzeraktivitäten (UML-Modelle, Use-Case Modelle, Aktivitätsdiagramme)
• Interviews, Ethnographische Studien
• Wichtig: Gesamtbild des Benutzerverhaltens

Erstellen des Systemprototyps

• Evolutionär/explorativ
• Benutzerzentriert
• Beispieloberflächen
• Prototypenformale Definitionen

Objektorientierter Feinentwurf

• Ausgangspunkt: Grobentwurf, Subsysteme
• Zerlegung in Subsysteme
• Ablaufmodelle, Technologiewahl, externe Schnittstellen
• OO-Modell für jedes Subsystem, supporierende Subsysteme

UML zum logischen Detailentwurf

• Analysemodell und Entwurfmodell (Notation, Objekte, Klassen)
• Verknüpfung zum logischen Kern
• UML-Beschreibbarkeit von Konzepten
• Genauigkeit, Präzision, formale Beschreibung

Pakete und Subsysteme

• UML (Pakete als "Ordner")
• Subsytems, Java- Sprachkonstrukt: package
• Fachliches Modell, Nutzerschnittstelle, Beziehung aufrufen und nutzen

Sichtbarkeit

• UML, Java/C++ - Sichtbarkeiten (public, protected, private(default))
• Bedeutung im Entwurf

Qualifizierte Assoziationen (Erinnerung)

• Definition: Attribut einer Assoziation
• Notation (K1, a, 0..1, K2)
• Bedeutung für Datenmodellierung, Datenbanken

Geordnete und sortierte Assoziation (Erinnerung)

• Reihenfolge, Sortierung
• Implementierung in der Software

Verwaltungsklassen-Singletons

• Klasse wird nur einmal instantiiert
• Beispiele (Terminverwaltung, Besprechungsraumverwaltung...)
• Parameter- und Datentypen für Operationen, Spezifikation von Operationen

Abgeleitete (redundante) Elemente

• Definition: Elemente, aus anderen Elementen rekonstruierbar
• Notation: Modellelement {derived}
• Beispiele (Teambesprechungen, Leitung, Teammitglieder)