Information System Architecture (Fach) / 02 - Architekturgestaltung (Lektion)
In dieser Lektion befinden sich 14 Karteikarten
Lernziele: * Was sind typische Kontrollarchitekturen/stile? * Welche Vor- und Nachteile haben sie? * Was ist eine Softwarearchitektur? * Welche Anforderungen sollte eine gute Architektur im Allgemeinen erfüllen? * Wozu benötigt man eine Architektur? * Welche architektonischen Strukturen können zur Beschreibung von Software benutzt werden?
Diese Lektion wurde von hannemac erstellt.
- Was beschreibt das Kontrollmodell? Kontrollfluss zwischen Subsystemen eines Systems. Externer vs. interner Kontrollfluss zwischen den Elementen (Objekten oder Prozessen) eines Subsystems.
- Welche zwei Modelle der Kontrolle gibt es? Centralized Control Ein Subsystem hat die Gesamtverantwortung für Kontrolle, Start und Stop der anderen Subsysteme Es kann Kontrolle deligieren, sie kehrt aber immer wieder zu ihm zurück Event-based Controll Jedes Subsystem kann auf externe Ereignisse reagieren Externe Ereignisse sind solche, die für alle Subsysteme "sichbar" sind Externe Ereignisse können außerhalb des Systems oder von anderen Subsystemen erzeugt werden
- Nenne die zwei Modelle der Centralized Controll Call-return Modell Kontrolle wird von einem "Top-Programm" durch Aufrufe an andere Programme übergeben, die ihrerseits die Kontrolle deligieren können. Kontrolle kehrt entlang der Aufrufkette zum "Top-Programm" zurück Nur für sequentielle Systeme, da immer nur ein Subsystem aktiv ist, anwendbar Manager Modell Ein Subsystem ist System-Kontroller, die anderen sind Prozesse Verschiedene Prozesse und verschiedene Instanzen eines Prozesses könnnen gleichzeitig ablaufen (concurrent systems) Start, Stop und Koordination der Prozesse geschieht durch den System-Kontroller
- Vorteile und Nachteile des Call-return Modells (Centralized Control) Vorteile Kontrollfluß einfach zu übersehen und leicht in prozeduralen Sprachen implementierbar Das System hat die Kontrolle. Reaktion auf äußere Ereignisse nur an definierten Stellen im Auflauf möglich Nachteile Benötigt eine Prozedur externen Input, wird auf Input gewartet Ausnahmen vom "gewöhnlichen Fluß der Kontrolle" und Änderungen schwierig, weil keine Trennung von Kontrollfluss und Verarbeitung Einzelne Prozeduren müssen nacheinander ablaufen (sequentielle Kontrolle)
- Vorteile und Nachteile des Manager Modells (Centralized Control) Vorteile Systeme können durch Polling entsprechender Prozesse von externen Ereignissen gesteuert werden Nachteile Kontrollfluß bei parallelen Prozessen auf unabhängigen Prozessoren mit wechselnder Last schwer vorhersehbar
- Nenne zwei Modelle der Event-based Controll Broadcasting Model Im Prinzip wird jedes Ereignis an alle Subsysteme übertragen Jedes Subsystem, welches das Ereignis verarbeiten kann, reagiert darauf Anwendung: Interaktion von Subsystemen auf vernetzten Rechnern Interrupt-driven Model Externe Interrups werden von Interrupt-Handler identifiziert und an andere Subsysteme weitergegeben Anwendung ausschließlich in Realzeitsystemen mit engen zeitlichen Restriktionen, z.B. aktive Unfall-Vorbereitung im Auto Wegen Hardware-Realisierung der Interrupts und des Interrupt-Handler kaum änderbar, schwer beherrschbar für betriebliche Anwendungen nicht relevant Anwendungebeispiele: Neuberechnung der Zellen eines Spreadsheets Neuberechnung aller abhängigen Variablen in Simulationssystemen
- Vorteile und Nachteile des Broadcast Model Vorteile Leicht um Subsysteme zu erweitern, die eine bestimmte Klasse von Events behandeln (Events im Event Register eintragen) Jedes Subsystem kann jedes andere aktivieren, ohne den Namen und die Adresse zu kennen Leicht zu verteilen, Verteilung ist für alle Subsysteme transparent Nachteile Subsysteme "wissen" nicht, ob und wann ein von ihnen erzeugtes Event behandelt wird Verschiedene Subsysteme können sich für dieselbe Klasse von Events registrieren lassen, daraus können Konflikte entstehen
- Was ist ein Architekturstil? Beschreibung von Komponententypen und Muster der Laufzeitkontrolle und/oder des Datenaustausches. Ist ein Menge von Bedingungen an eine Architektur. Definiert eine Menge von Architekturen. Beispiel: Client-Server Komponententypen sind Clients und Server Koordination gegeben durch Kommunikationsprotokoll Es gibt mehrere Clients, es kann mehrere Server geben Clients sind nicht identifiziert, Server sind identifiziert Funktionalität der Clients und Server nicht festgelegt Es gibt viele Konkrete Architekturen, die Instanzen des Architekturstils Client-Server sind
- Referenzmodell Eine Aufteilung von Funktionalität auf Komponenten zusammen mit dem Datenfluß zwischen den Komponenten Standardzerlegung zur Lösung eines bekannten Problems z.B. Referenzmodell eines Compilers oder eines DBMS Wenn man beschreiben möchte, wie ein DBMS funktioniert, benutzt man üblicherweise ein Referenzmodell
- Referenzarchitektur Abbildung des Referenzmodells auf Softwarekomponenten, die zusammen die Funktionalität des Referenzmodells implementieren Abbildung muss nicht bijektiv (1zu1) sein Komponente kann einen Teil einer Funktion oder mehrere Funktionen implementieren
- Architectual structures / Architectual views Architectual views Beschreibt die Sicht auf eine Menge von architektonischen Elementen des Systems., die durch die Benutzer des Systems wahrgenommen und genutzt werden sowie die Beziehung der Elemente untereinander. Architectual structures Beschreibt die Menge der Elemente eines Systems ansich, die in Hard- und Software abgebildet sind.
- Qualitätsmerkmale auf Systemebene (6 Stück) Performane (Rechenleistung), bezieht sich auf System- oder Benutzerereignisse und deren Durchführungszeit Änderbarkeit, bezieht sich auf die Änderungen und die damit verbundenen Kosten Useability (Bedienbarkeit), bezieht sich darauf, wie einfach es für einen Benutzer ist, eine gewünschte Aufgabe durchzuführen Verfügbarkeit, bezieht sich auf Systemausfälle und deren Konsequenzen Sicherheit, bezieht sich auf die Wiederstandsfähigkeit des Systems gegen unauthorisierte Nutzung Testbarkeit, bezieht sich darauf, wie einfach Fehler im System durch Tests erkannt werden können
- Architektonische Taktiken Designentscheidungen, die dazu dienen, bestimmte Qualitätsanforderungen zu erreichen Ein architektonisches Muster oder eine architektonische Strategie implementiert meist mehrere Taktiken Taktiken können durch weitere konkretere Taktiken verfeinert werden Beispiel: Verfügbarkeit Eine Anwendung sendet einen Ping an eine andere Anwendung und erwartet ein Echo. Bleibt das Echo aus, ist dies ein Hinweis dafür, dass die Komponent ausgefallen ist und es kann entsprechend reagiert werden. Diese Ausfallerkennung kann als Hierarchie über das gesamte Softwaresystem organisiert werden.
- Qualitätsattributszenario Elemente Quelle: Generiert den Stimulus Stimulus: Ereignis Artefakt: Teil des Systesm, welches vom Stimuluss betroffen ist Kontext: In welchem Zustand sich das System zurzeit befindet Reaktion: Wie reagiert das System auf den Stimulus Reaktionsmessgröße: Wie ist der Erfolg der Reaktion zu messen Beschreibt anhand eines Szenarios ein oder mehrere Qualitätsattribute des Systems.