VL6 - Vom Geschäftsprozess zur Softwarearchitektur Flashcards
Begriff “Softwarearchitektur”
Die grundlegende Organisation eines Systems, dargestellt durch dessen Komponenten, deren Beziehungen zueinander und zur Umgebung sowie den Prinzipien, die den Entwurf und die Evolution der Systeme bestimmen. (Hasselbring 2006)
Kernphasen von “Softwarengineering”
- Planung
- Analyse
- Entwurf
- Implementierung
- Test
- Evolution/Wartung
Ziele einer “Softwarearchitektur” (im Lebenszyklus von Standardsoftware)
- Beherrschung der Komplexität
- Testbarkeit
- Erweiterbarkeit
- Wartbarkeit / Updatefähigkeit
- Anpassbarkeit
- Integrationsfähigkeit
- Skalierbarkeit
4 Qualitätskriterien für “Softwarearchitekturen”
- Ordnungsmäßigkeit
- Richtigkeit
- Interoperabilität
- Sicherheit
- Zuverlässigkeit
- Benutzbarkeit
- Effizienz
- Übertragbarkeit
scalability
availability / reliability
security
safety
usability
portability
performance
interoperability
evolvability
extensability
Aufbau einer “Software-Architektur”
- Modellsammlung (Referenzmodelle)
- Technologie
- Umgebung (Hardware, Software)
4 Arten von Sichten
- Kontext: Zeigen den Zusammenhang des Systems mit seiner Umgebung aus der Vogelperspektive
- Bau: Statische Struktur der Architekturbausteine des
Systems, Subsysteme, Komponenten und deren
Schnittstellen zueinander - Laufzeit: Zusammenwirken der Bausteine zur
Laufzeit - Verteilung: Beschreibung der Hardwarekomponenten (Rechner, Prozessoren, Netztopologien)
Begriff “Metamodell”
Ein Modell, das eine Menge anderer Modelle definiert, die als Instanzen des Metamodells bezeichnet werden.
Begriff “Model Driven Architecture”
Ansatz mit klarer Trennung von Funktionalität und Technik.
Standardisierte Transformation vom plattformunabhängigen Modell zum Quellcode.
Lösung für Probleme:
Fachliche Sicht lässt sich nicht immer in technische Sicht abbilden
Kommunikationsprobleme zwischen den entsprechenden Abteilungen
Wissen der Entwickler wandert ab
Begriff “ATAM” (Bewertungskriterium)
Architecture Trade-off Analysis Method.
Beschreibung:
Szenariobasierter Ansatz zur Bewertung der
Architekturentscheidungen, der einen klaren
Schwerpunkt auf die Anforderungen an
Qualitätsmerkmale legt.
Vorteile:
Eindeutige Korrelation der Anforderungen an
Qualitätsattribute und der zugrunde liegenden Geschäftstreiber mit den Merkmalen einer Architektur.
Früherkennung von Risiken oder Fehlentscheidungen.
Unterstützung der Architekten bei der Architekturentwicklung.
Unterstützung bei der Auswirkungsanalyse in
Situationen mit veränderten Anforderungen
an Qualitätsmerkmale.
Vorgehensmodell für “ATAM”
- Präsentation
- Erhebung & Analyse
- Testen
- Reporterstellung
Begriff “CBAM” (Bewertungskriterium)
Cost Benefit Analysis Method.
Beschreibung:
Ökonomische Konsequenzen der
Entwurfsentscheidung
Analyse der Qualitätsattribute hinsichtlich
Kosten und Leistungen
Vorteile:
Einfache Anwendung
Verschafft Klarheit in unvorhersehbaren
Situationen
Identifizieren und bewerten von Ausgaben
Gibt an, inwiefern der Nutzen die Kosten
überwiegt
Begriff “Softwaremuster”
Beziehung zwischen einem bestimmten Kontext, einem bestimmten System an Kräften, die in diesem Kontext wiederkehrend auftreten, und einer bestimmten Software-Konfiguration, die diesen
Kräften erlaubt, sich gegenseitig aufzulösen
Begriff “Schichtenmuster”
Hierarchische Organisation.
Mittel der Strukturierung.
Darstellung verschiedener, aufeinander aufbauender
Abstraktionslevel.
Vorteile:
Leicht verständlich
Technologietrennung und -integration
Wohl definierte Zugriffskonzepte durch Beschreibung
der Protokolle
Nachteile:
Notwendigkeit von definierten stabilen Schnittstellen
Kritische Performance
Hohe Kosten bei Gesamtsystemveränderung
Beispiele:
2-Schichten-Modell, z.B. Rich-Client Szenarien
3-Schichten-Modell, z.B. Daten-, Geschäftslogik- und
Präsentationsschicht
N-Schichten-Modell, z.B. ISO OSI Referenzmodell für
die Kommunikation offener Systeme
Begriff “Client-Server-Architekturen” (Anwendung des Schichten-Musters in betrieblichen Anwendungssystemen)
Layer 1: Dienstanbieter (Server)
Stellt für die Bearbeitung der Funktionen dem Client die notwendigen Daten zur Verfügung.
Layer 2: Dienstnutzer (Client)
Enthält die Anwendungslogik, häufig umgesetzt als Fat-Client.
Eigenschaften:
Trennung von Datenhaltung und Datenverarbeitung
Keine Verantwortung für die Datenspeicherung und
sämtlicher damit verbundener Konzeptionen der
Client-Komponente
Client-Komponente nutzt die zugesicherten Dienste
der Server-Komponente
Begriff “Drei-Schichten-Architektur” (Anwendung des Schichten-Musters in betrieblichen Anwendungssystemen)
Layer 1: Datenhaltung
Layer 2: Business Logic
Layer 3: Präsentation
Eigenschaften:
Weitere Dekomposition der Client-Komponente
Businesslogik wird getrennt von der Präsentation
Variante 1: Geschäftslogik ist Teil des Servers
(Thin-Client)
Variante 2: Geschäftslogik ist Teil des Client
(FAT-Client)
3 Prinzipien von “Integrationsarchitekturen”
- Punkt zu Punkt (P2P)
- Nabe-Speiche (Hub and Spoke)
- Service-orientierte (SOA)
Begriff “Punkt zu Punkt-Architektur (P2P)”
Funktionsweise:
Verbindung einzelner Systeme zueinander mittels
Schnittstellen
Vorteil: Geringer Aufwand bei wenigen Systemen
Nachteile:
Komplexe Abhängigkeiten erschweren Weiterentwicklung und Anpassung
Skalierbarkeit bei Einführung neuer Systeme nicht gegeben, da alle bisherigen Schnittstellen aktualisiert
werden müssen
Begriff “Nabe-Speicher Architektur (Hub and Spoke)”
Funktionsweise:
Datenaustausch über eine zentrale Integrationsplattform
Vorteile:
Prozess der Extraktion, Transformation und Laden von
Daten kann separiert werden
Reduzierung der Verbindungen der einzelnen
Systemen
Nachteile:
Zentraler Knotenpunkt als “Single Point of Failure”
Zentraler Knotenpunkt als “Performance-Engpass”
Begriff “Service-orientierte-Architektur (SOA)”
Funktionsweise:
Unterteilung der Systeme in Dienste, welche loose
gekoppelt und eigenständig sind.
Merkmale:
1. Lose Kopplung
2. Schnittstellen zur Kommunikation
3. Dienstsuchverzeichnis
4. Wiederverwendung
Vorteile:
Nutzung offener, bereits verbreiteter Standards
Plattform- und sprachunabhängig
Erhöhte Code-Wiederverwendung
Bessere und schnellere Anpassungen an veränderte
Rahmenbedingungen
Einfache Entwicklung, Bereitstellung und Wartung
von Anwendungen
Einfache Integration von Services auf verschiedenen
Granularitätsstufen
Nachteile:
Aufwändige Neugestaltung
Dynamische Architektur und somit ggf. Instabilität
Inhomogene IT Umgebung
Keine Echtzeit
Zusammenspiel mit externen Services nicht unbedingt nötig
