- Zielorientierte Bereitstellung uns systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen [Balzert]
> 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!
- 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.“
| 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
- 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
> 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
- 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)
- 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 <<abstract>>
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
