Entwurf und Modellierung Flashcards
(34 cards)
Was beschreibt die Architektur einer Software?
- Komponenten und deren Beziehungen untereinander
Grenze Makro- und Mikro-Entwurf voneinander ab
Makro-Entwurf = Architekturentwurf --> High-Level Mikro-Entwurf = Komponentenentwurf --> Low-Level
Was ist ein Architekturmuster?
= Schablone für konkrete Softwarearchitekturen
- Lösung für ein wiederkehrendes Problem in spezifischen Situationen
- entwickeln sich aus der praktischen Erfahrung (“once is chance, twice is coincidence, three times is a pattern” –> unbedingt sagen, das erfreut ihn)
- beschreibt Gruppe von Komponenten und deren Interaktion –> höhere Abstraktion als explizite Klassen
Aus welchen drei Bestandteilen setzt sich ein Entwurf mindestens zusammen?
- Kontext (Situation in der Problem auftritt)
- Problem (wiederholt auftretendes Problem im Kontext)
- Lösung (geprüfter Ansatz zur Lösung des Problems)
Beschreiben Sie das Architekturmuster: n-Tier (Schichtenarchitektur)
- System ist in Schichten strukturiert, jede Schicht stellt darüber liegenden Schichten Funktionen zur Verfügung
- sinnvoll wenn auf ein vorhandenes System neue Funktionen aufgesetzt werden ODER Aufteilung der Entwicklung auf Team pro Schicht
Vorteil:
- Solange Schnittstelle erhalten bleibt, ganze Schichten problemlos ersetzbar
- redundante Funktionen können in jeder Schicht eingebaut werden
Nachteil:
- saubere Schichtentrennung in der Praxis schwierig
- Leistungsfähigkeit schlecht, wenn Anfrage von oberster Schicht durch alle Schichten bis nach unten gereicht werden muss (= strict Layering)
(Ausweg: Layer Bridging –> Anfragen dürfen auch Schichten überspringen)
… Layer Bridging birgt aber auch Gefahr, dass System zum Netz mutiert
Beschreiben Sie das Architekturmuster: Plugin-Architektur
Kontext/Problem: Der Funktionsumfang eines Systems muss dynamisch erweiterbar sein
Lösung: Plugins (Softwarekomponenten mit spezifischer Funktionalität). Schnittstelle (Plugin-Manager) implementiert Erweiterungspunkte für Plugins
Plugin-Manager gliedert Plugins ein/aus
Plugins können wiederum neue Erweiterungspunkte definieren
Beschreiben Sie das Architekturmuster: Repository-Architektur
- Daten eines Systems werden in zentralem Datenspeicher verwaltet. Alle Komponenten können darauf zugreifen
- Komponenten interagieren nur über Repository
- Verwendung: bei großer Informationsmengen-Erzeugung (mit langer Speicherung) (z.B. Versionskontrolle)
Vorteil:
- Komponenten können unabhängig sein
- konsistente Datenverwaltung (da nur an einem zentralen Ort)
Nachteil:
- Repository ist SPOF
- gesamte Kommunikation läuft über Repository –> Performance-Probleme
- Verteilung des Datenspeichers auf mehrerere Computer schwierig
Beispiel: IDE mit zentralem Projektrepository
Beschreiben Sie das Architekturmuster: Client-Server-Architektur
- Systemfunktionen = Dienste ; jeder Dienst wird von einem Server angeboten
- Clients greifen auf Server zu, um Dienste in Anspruch zu nehmen
Verwendung: Daten befinden sich in gemeinsam genutzter Datenbank; Zugriff auf diese von unterschiedlichen Orten aus
- gut bei Schwankungen der Systemauslastung
Vorteile:
- Verteilung der über ein Netzwerk
- Allgemeine Funktionen können allen Clients zur Verfügung gestellt werden (z.B. Druckerdienst)
Nachteile:
- jeder einzelne Dienst ist SPOF –> anfällig für DoS-Angriff
- Performance hängt nicht nur vom System, sondern auch vom Netzwerk ab
Beschreiben Sie das Architekturmuster: Pipes-and-Filter
- Aufbau aus mehreren Verarbeitungskomponenten (Filter), die jeweils eine Form der Datenverarbeitung durchführen
- Daten fließen wie durch ein Rohr (Pipe) durch die einzelnen Komponenten
Verwendung: in Stream-Datenverarbeitung
Vorteil:
- einfach zu verstehen
- Wiederverwendbarkeit von Filtern
- sequentiell oder parallel implementierbar
Nachteil:
- Datenübertragungsformat muss vereinbart werden
- -> in Pipes Konvertierung durchführen (ggf. mit Mehraufwand oder Datenverlust)
Beschreiben Sie das Architekturmuster: Broker-Architektur
Problem: kennt jede Komponente jede andere Komponenten in einem verteilten System entsteht hohe Abhängigkeit (= starr). Ansprache über logische Namen wäre effizienter und dynamischer.
Lösung: Broker/Zwischenschicht verwaltet logische Namen und vermittelt Kommunikation zwischen Komponenten
! Vgl. DNS: hier wird nur Adresse aufgelöst –> aber keine Kommunikation vermittelt
Beispiel: CORBA
Beschreiben Sie das Architekturmuster: SOA
(wer Bock hat labert hier ein bisschen das Riechert-Zeugs :P)
Problem: verschiedene Anwendungsfälle müssen auf Systeme abgebildet werden. Würde sich der Geschäftsprozess ändern, müsste das gesamte System adaptiert werden.
Lösung: Kapselung von Verarbeitungsfunktionen eines Geschäftsprozesses in Services (hohe Kohärenz, lose Kopplung)
- Serviceanbieter veröffentlicht Service in Service-Verzeichnis
- Servicenutzer –> Suchanfrage in Service-Verzeichnis
- Rückgabe Verweis auf veröffentlichten Service
- Service-Nutzer ruft Service auf
Beschreiben Sie das Architekturmuster: EDA (Event Driven Architecture)
Kontext: Anwendung mit verteilten Softwarekomponenten, relativ stabiler Kommunikation
Problem: möglichst lose Kopplung zwischen den Softwarekomponenten, bspw. um verschiedene Entwicklerteams zu integrieren, einfache Erweiterbarkeit zu erreichen usw.
Lösung: statt direkten Aufrufen –> sende Zustandsänderung als Ereignis über Ereigniskanal. Interessierte Softwarekomponenten greifen auf Kanal zu –> führen Verarbeitung unabhängig/asynchron aus
Vorteil:
- enorm lose Kopplung
- einfache Erweiterbarkeit
- Sprachvielfalt möglich
- Skalierung einfach
Nachteil:
- Debugging nur anhand verteilter Logs
- Zustand der Gesamtanwendung/System zu beliebigem Zeitpunkt schwer zu definieren
Beschreiben Sie das Architekturmuster: MicroService
Komponenten = Services mit innerem zustand und zugänglich über API
Kontext: Anwendung, welche aus verschiedenen Komponenten besteht
Problem: verschiedene Komponenten der Anwendung werden unterschiedlich gefordert, was eine Skalierung der Gesamtanwendung (Monolith) schwierig macht.
Verschiedene Teams sollen einzelne Komponenten der Anwendung entwickeln
Lösung: Module auf Services verteilen; Zugriff über API –> jedes Modul für sich entwickelbar und skalierbar
Vorteil:
- lose Kopplung der Services
- einfacher Austausch über Schnittstelle
- unabhängige Entwicklung und Skalierung
- einfaches Testing der einzelnen Services
Nachteil:
- komplexes Management der Gesamtanwendung
- Granularität der Aufteilung auf Services nicht klar definiert
- gemeinsame Vision der Teams kann abhanden kommen
Beschreiben Sie das Architekturmuster: Monolith
Kontext: Anwendung durch einzelnes Team entwickeln, einfaches Deployment
Problem: Anwendung soll einfach verständlich sein. Hinter Load-Balancer werden Instanzen horizontal skaliert.
Lösung: Verpacke alle Module/Services in einzelnes Deployment-Paket
Vorteil:
- typischerweise einfaches Deployment, einfache Entwicklung, einfaches Management
- geringer Initialaufwand
Nachteil:
- Gesamtarchitektur schwierig schlüssig zu fassen (z.B. für neue Entwickler)
- schwierig zu testen
Welche drei Faktoren berücksichtigt der Architektur-Entwurf?
- Nützlichkeit:
durch weitest mögliche Abdeckung der Anforderungen - Stabilität:
durch Integration von stabilen Technologien - Anmut:
durch durchdacht gewählte Komponenten, gute Wartbarkeit und Lesbarkeit
Welche Sichten auf die Architektur sind im Entwurf zu berücksichtigen?
Logische Sicht: Abstraktion im System als Objekte/Klassen –> Klassen-Diagramm
Prozesssicht: Zusammensetzung des Systems aus interaktiven Prozessen
Entwicklungssicht: Zerlegung der Software in Komponenten (Zuordnung von Entwicklern möglich)
Physische Sicht: auf welcher Hardware soll es laufen? Systemkomponenten auf entsprechender Hardware
Konzeptuelle Sicht: zeigt den Systemverbund –> Erkennung systemübergreifender Komponenten
Was sind Referenzarchitekturen und wie unterscheiden sie sich von Architektur-Mustern?
Muster liefert fachbereichsübergreifende Vorlagen
… Referenzarchitektur liefert Vorlagen für bestimmten Anwendungsbereich
- -> umfassende, vollständige Architektur
- -> fordert vom Architekt entsprechende Reduktion
- -> zeigt Besonderheiten des Anwendungsbereichs auf
Nenne Beispiel für Referenzarchitekturen
OSI-Referenzarchitektur
Azure Referenzmodell Single VM, N-Tier multiple VM
SOA reference Architecture
Referenzarchitekturmodell Industrie 4.0
Welche grundsätzlichen Prinzipien verfolgt man im Software Engineering Entwurf (Mikro-Entwurf)?
- Abstraktion
- Strukturierung (Kopplung und Kohäsion)
- Hierarchisierung
- Geheimnisprinzip (Datenkapselung)
- Trennung von Schnittstelle und Implementierung
- Vollständigkeit und Einfachheit
- Trennung der Zuständigkeiten
Was kennzeichnet einen Aspekt im Software Engineering Entwurf (+ Beispiele)?
Aspekt ist Querschnittsbelang (cross-cutting-concern) –> funktionsübergreifende Integration
Bsp.:
- Nebenläufigkeit
- Protokollierung (Logging)
- Ereignisverarbeitung (Callbacks, Events, …)
- Fehlerbehandlung
- Sicherheit
- Persistenz
Welche vier grundsätzlichen Strategien gibt es zur Erstellung des Software Engineering Entwurfs?
Top-Down: abstrakt -> konkret / allgemein -> speziell
+ Strukturelle Zusammenhänge gut zu erkennen
- “Top” schwer zu bestimmen - wann ist es abstrakt genug
Bottom-Up: konkret -> abstrakt / speziell -> allgemein
+ weniger Abstraktionsvermögen erforderlich
- Entscheidungen in niedrigen Ebenen –> Fixes in höheren Ebenen (fehlender Überblick)
Outside-In: erst Systemumwelt, dann System modellieren
+ Fokus auf Umweltschnittstellen –> gute Anforderungsabdeckung
- schlechte Wiederverwendung durch mangelnde Innensicht
Inside-Out: erst System, dann Systemumwelt modellieren
+ Wiederverwendbarkeit, gute Strukturierung
- Verlust des Umweltbezugs/ Anforderungen nicht ausreichend berücksichtigt
Nach welcher Strategie würde man eine (a) Neuentwickklung (b) Weiterentwicklung entwerfen?
Neuentwicklung: outside-in + top-down –> Anforderungen ausreichend berücksichtigen
Weiterentwicklung: inside-out + bottom-up –> bestehende Funktionalität sichern
Nennen Sie Entwurfsparadigmen im Mikro-Entwurf
- Function-Oriented Design
- Data Structure-Centered Design
- Component-Based Design
- Object-Oriented Design
- Serviceorientiertes Design
Charakterisieren Sie das Paradigma Object-Oriented Design. Welche formelle Sprache wird üblicherweise zur Beschreibung verwendet?
- Verbindung der Data-Structure und Function-Oriented Designs durch Kapselung der Daten in Klassen mit entsprechenden Methoden
- Erweiterung der Diagramme und Modelle aus Object Oriented Analysis (OOA) –> Ziel: möglichst genaue Abbildung des zu implementierenden Systems
Notation: UML
