Skript 5

- Gliederung des Systems in überschaubare Einheiten

- Festlegung der Lösungsstruktur

- Hierarchische Gliederung

- Bestandteil eines Systems

- Komponente bietet ihrer Umgebung Dienste an

- Übergangsstelle zwischen verschiedenen Komponenten eines Systems

- Festlegungen, die Kombinierbarkeit sicherstellen

• Prozess des Definierens einer Architektur, derer Komponenten & Schnittstellen eines Systems

• Man spricht von einem Entwurf, wenn die Tätigkeit, deren Resultat die Architektur ist, im Vordergrund steht

Grundlegende Organisation eines Systems und dessen Komponenten, deren Beziehungen zueinander und zur Umgebung, sowie den Prinzipien die den Entwurf und die Evolution des Systems bestimmen

• Beschreiben eine Architektur im Hinblick auf ihr Anliegen

• 3 besonders wichtige:

  • Systemsicht

  • Statische Sicht

  • Dynamische Sicht

Eine Software-Architektur ist gut, wenn die funktionalen und nichtfunktionalen Anforderungen erfüllt werden können

• Modularität ist eine Eigenschaft der Architektur

• Der Grad, in dem ein System/Computerprogramm aus einzelnen Komponenten besteht, sodass eine Änderung an einer Komponente nur minimale Auswirkungen auf andere Komponenten hat

- Funktionale Module

- Datenobjektmodule

- Datentypmodule

• Kohäsion handelt von Abhängigkeiten zwischen Funktionen eines Moduls

• Die Kohäsion (Zusammenhalt) (d.h. die Verwandtschaften zwischen den Teilen eines Moduls) soll möglichst hoch sein

• Kopplung handelt von Abhängigkeiten zwischen Modulen

• Die Kopplung (d.h. Breite und Komplexität der Schnittstellen) zwischen den Modulen soll möglichst gering sein

• Technik, bei der die Schnittstellen jedes Moduls so wenig wie möglich über das Innenleben des Moduls preisgeben und andere Module daran gehindert werden, Informationen zu verwenden die ihnen nicht zustehen

  • Jede Einheit gibt nur das Nötigste preis, um sie zu nutzen

• Grundprinzip, welches den Ansatz verfolgt, dass jede Komponente nur für einen ganz bestimmten Aufgabenbereich zuständig ist

• Trennung zwischen fachlichen und technischen Komponenten

• Aggregationshierarchie

  • Gliedert System in Bestandteile

  • i.d.R. Monohierarchien

• Schichtenhierarchie

  • Ordnet Komponenten (Schichten) so, dass jede Schicht genau auf einer darunterliegenden Schicht aufbaut und die Basis für die Schicht drüber bildet

  • Strenge Form der Monohierarchie

• Generalisierungshierarchie

  • Ordnet Komponenten nach Merkmalen

  • Kann Mono- oder Polyhierarchie sein

- Identifizierung von Objekten und Klassen

- Festlegen des Verhaltens der Objekte und Klassen

- Identifizierung von Beziehungen zwischen Klassen

- Festlegen der Schnittstellen zwischen Klassen

Prinzip besagt, dass Klassen offen für Erweiterungen, aber geschlossen für Veränderungen sein sollten

- “Entwurf gemäß Vertrag”

- Funktionalität der Schnittstelle wird von Nutzer beschrieben

- Entwickler realisiert und garantiert, dass Schnittstelle gewünschte

Funktionalität liefert

- Nutzer hat kein Einfluss auf Realisierung

• Berücksichtigung von speziellen SW-Schnittstellen nicht objektorientierter Systeme

• Berücksichtigung / Benutzung existierender Datenhaltungssysteme z.B. Vorgabe des DBMS

• Berücksichtigung bestimmter Design-Prinzipien

• Alt-Software muss eingebunden werden

• Jede Klasse sollte nur eine einzige Verantwortung haben

  • Verantwortung → Grund zur Änderung

• „Es sollte nie mehr als einen Grund geben, eine Klasse zu ändern“

Module sollte offen für Erweiterungen und geschlossen für Modifikationen sein

Objekte in einem Programm sollten durch Instanzen ihrer Subtypen ersetzbar sein, ohne die Korrektheit des Programms zu verändern

Clients sollten nicht (gezwungen werden) von Interfaces/Schnittstellen abhängen, die sie nicht verwenden

Module hoher Ebenen sollten nicht von Modulen niedrigerer Ebenen abhängen. Beide sollten von Abstraktion abhängen

Design-Pattern sind vorgefertigte Lösungen, um wiederkehrende Probleme nach einem bestimmten Muster zu lösen.

• Erfahrungen sind in Patterns „codiert“ und nicht im Hirn festgehalten

• Anwendungen auch für nicht erfahrene Entwerfer möglich

• Nur bestes Muster muss man sich merken

Erzeugungspattern:

• Sollen das Wissen um das System und die konkreten Klassen des Systems vor dem Benutzer verstecken

• Zielsetzungen:

  • Systeme leichter konfigurierbarer

  • Änderungen im Entwurf vorherzusehen

  • Verhaltenspattern…

Strukturpattern:

• Befassen sich mit der Komposition von Klassen und Objekten, um größere Strukturen zu bilden

• Zielsetzungen:

  • Anpassung von Schnittstellen (Adapter)

  • Trennung von Abstraktionen und Implementierung (Brücken)

  • Zusammensetzung von Objekten (Komposition)

• Erzeugen von Stellvertreterobjekten (Proxy)

Anti-Pattern sind wiederkehrende schlechte Lösungen, die man an Strukturen erkennen kann

• Spaghetti Code: viele gemischte Schleifen

• Cut and Paste Programmierung: „was oben funktionierte, funktioniert hier auch“

• Rucksack-Programmierung

• Performance

• Wartbarkeit

• Erweiterbarkeit

• Verständlichkeit

• Schnell realisierbar

• Minimierung von Risiken

• Ein Architekturmuster ist ein grundlegendes strukturelles Organisationsschema für Softwaresysteme.

• Wenn wir ein Architekturmuster verwenden, legen wir damit die Strukturen auf der obersten Ebene der Architektur fest.

• Die Wahl des Architekturmusters ist eine wichtige Entscheidung.

• Organisiert System in Schichten mit zugehörigen Funktionen, die mit jeder Schicht verbunden sind

• Eine Schicht stellt Dienste für die darüberliegende Schicht bereit → unterste Schichten für Kerndienste

• Dient dazu, eine Anwendung zu strukturieren, die Daten auf einem virtuellen Fließband verarbeitet

• Verarbeitungsschritte werden in Filtern realisiert. Ein Filter verbraucht und erzeugt Daten

• Pipes leiten die Ergebnisse des Filters an nachfolgende Filter

• Der erste Filter bekommt Daten aus der Datenquelle, der letzte liefert sie an die Datensenke

Trennt Darstellung und Interaktion von Systemdaten.

MVC gliedert eine interaktive Anwendung in drei Komponenten:

• Model verwaltet Systemdaten und dazugehörige Operationen auf diese Daten

• -View präsentiert dem Benutzer die Daten

  • Zu einem Model kann es beliebig viele Views geben

  • Controller verwaltet die Benutzerinteraktion und leitet Interaktion an View und Model weiter

• Bietet die Möglichkeit, ein System an dafür vorgesehenen Punkten zu erweitern, ohne es zu modifizieren (offen-geschlossenes-Prinzip).

• Eine Plug-In-Anwendung besteht aus einem Kern (auch Host = Wirt genannt), der durch sog. Plug-Ins um neue Funktionen erweitert werden kann

  • Host definiert spezielle Schnittstellen (Erweiterungspunkte), auf die Plug-In Bezug nehmen kann

  • Ein Plug-In kann selbst ein Host sein = Plug-ins können Erweiterungspunkte für weitere Plug-Ins sein

• Alle Daten in einem System werden im zentralen Repository verwaltet

• Alle Komponenten haben Zugriff auf Repository

• Komponenten interagieren nicht direkt, sondern über Repository

• Funktionalität des Systems ist in Diensten organisiert

• Jeder Dienst wird von einem separaten Server bereitgestellt

• Clients sind Benutzer dieser Dienste und greifen auf die Server zu

SOA repräsentieren die fachlich funktionalen Schnittstellen von

Softwarebausteinen als verteilte, wiederverwendbare, lose gekoppelte und

standardisiert zugreifbare Dienste (=Services)

• Wichtiges Architekturmuster für verteilte Systeme und deren Integration

• Strukturierung von großen Systemen in kleine fachliche Einheiten

• Jeder Microservice soll eine eigene fachliche Einheit repräsentieren

• Microservices können synchron & asynchron miteinander kommunizieren

• Microservices werden separat entwickelt und unabhängig voneinander in Produktion gebracht

Klassenbibliothek besteht aus einer Menge von Klassen, die wiederverwendbar sind und allgemein – also unabhängig vom Anwendungskontext – nutzbare Funktionalitäten anbieten

• Ein Rahmenwerk ist eine Architektur aus Klassenhierarchien, die eine allgemeine generische Lösung für ähnliche Probleme in einem bestimmten Kontext vorgibt.

• Ein Framework hat definierte Schnittstellen, an denen die Lösung durch anwendungsspezifischen Code erweitert werden kann

• Diese Stellen werden als Hot Spots bezeichnet

Eine Referenzarchitektur definiert Software-Bausteine für einen Anwendungsbereich durch ihre Strukturen und Typen, ihre Zuständigkeiten und ihre Interaktionen.

• Referenzarchitektur definiert für einen Anwendungsbereich eine erprobte und wiederverwendbare Architektur

  • Essenz aus Erfahrungen die in Praxis gesammelt wurden

• Nichtfunktionale Anforderungen besonders wichtig!

Vor allem für Anforderungen an folgende Qualitäten:

• Testbarkeit

  • Jede Software muss getestet werden, das muss bei der Architektur berücksichtig werden

• Wartbarkeit, Erweiterbarkeit

  • Systeme, die eingesetzt werden, müssen korrigiert werden und sich an neue Anforderungen anpassen lassen

• Portierbarkeit

  • Systeme müssen immer wieder auf andere Plattformen übertragen werden oder Änderungen der umgebenen Software nachvollziehen

Lehre von der menschlichen Arbeit und die Erkenntnis ihrer Gesetztmäßigkeiten

• Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen des Dialogsystems unterstützt und anleitet

  • Kann der Benutzer sich ohne Hindernisse in die Nutzung des Systems einarbeiten?

  • Begriffe sinnfällig wählen

• System ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingabe entweder mit keinem oder minimalen Korrekturaufwand durch den Benutzer erreicht werden kann

  • Ist Software gegen Fehleingaben robust?

  • Fehlersituation leicht korrigierbar? Korrekturvorschläge?

• Dialog ist erwartungskonform, wenn er konsistent ist und den Merkmalen des Nutzers entspricht

  • Reagiert System so, wie Nutzer es erwartet?

  • Kann Benutzer Systemverhalten voraussagen?

• System ist aufgabenangemessen, wenn es den Benutzer unterstützt, seine Aufgabe effektiv und effizient zu erledigen

• Muss Benutzer unnötige Dialogschritte durchführen?

• Sind überflüssige Informationen vorhanden?

• Dialog ist selbstbeschreibungsfähig, wenn jeder einzelne Dialogschritt durch Rückmeldung des Systems verständlich ist oder auf Anfrage erklärt wird

  • Sind alle für einen Arbeitsschritt benötigten Informationen übersichtlich am Bildschirm vorhanden

• Dialog ist steuerbar, wenn der Benutzer den Dialogablauf starten, Richtung und Geschwindigkeit beeinflussen kann, bis Ziel erreicht ist

  • Kann Nutzer Maus und Tastatur manövrieren?

  • Kann Nutzer Arbeitsschritte unterbrechen oder abbrechen wenn nötig

• Dialog ist individualisierbar, wenn System Anpassungen erlaubt an die Erfordernisse der Aufgabe, individuelle Vorlieben und Fähigkeiten des Benutzers

  • Können eigene Funktionen (Macros) definiert werden?

  • Kann Nutzer Layout und Funktion des Systems anpassen?

• Expertenzentrierte Methoden

  • Heuristische Evaluation

  • Guidelines & Checklisten