Softwarearchitektur (Fach) / Architekurbeschreibungssprachen (Lektion)
In dieser Lektion befinden sich 36 Karteikarten
VL02
Diese Lektion wurde von jan_kirsch erstellt.
Diese Lektion ist leider nicht zum lernen freigegeben.
- Definition von Architekturbeschreibung Eine Menge von Modellen (textuelle Spezifikation oder graphische Diagramme), welche die Softwarearchitektur dokumentieren
- Was sind Sichten/Standpunkte/viewpoints? Darstellung eines Systems von einem bestimmten Standpunkt (viewpoint) aus wird als Sicht (view) bezeichnet.
- Wofür gibt es Sichten bei Architekturbeschreibung? - geeignete Beschreibung für bestimmte Zielgruppe (Kunde, Manager, Entwickler) aus bestimmten Standpunkt (Technisch, Prozessorientiert, Wirtschaftlich etc.) - Wichtig hierbei: Fokussierung auf Kernpunkte eines Aspekts
- Herausforderungen von Sichten Konsistenz zwischen Schichten Vollständigkeit Abstraktion Übersichtlichkeit Realitätstreue Beschreibung (?)
- Architekturneschreibung Menge von Sichten basierend auf einer Auswahl von View Points
- Sichten nach Kruchten Logical View Development view Process View Physical View
- Logical View Elemente der Anwendungsdomäne und deren Verbindungen
- Process View Zuordnung der Elemente der logischen Sicht zu Kontrollflüssen Parallelität/Nebenläufigkeit, Performanz, Systemintegrität und Fehlertoleranz
- Development View Entwicklung des Systems in Klassen, Paketen etc.
- Physical View Verteilung auf physische Ressourcen
- Szenarien nach Kruchten Verbinden die 4 Sichten unter Nutzung typischer Anwendungsszenarien
- Siemens 4 Sichten Conceptual Architecture View Module Architecture View Execution Architecture View Code Architecture View
- Siemens 4 Sichten Conceptual Architecture View Beschreibung des Systems mit Mitteln der Anwendungsdomäne Zerlegung in fachliche Module und Verbindungen dazwischen
- Siemens 4 Sichten Module Architecture View technologische Umsetzung der konzeptuellen Sicht Zuordnung der fachlichen Einheiten zu Modulen und Subsystemen
- Siemens 4 Sichten Execution Architecture View Betrachtung des Systems zur Laufzeit Die logischen Abläufe der konzeptuellen Sicht werden abgebildet
- Siemens 4 Sichten Code Architecture View Umsetzung und Verteilung auf ausführbare Einheiten
-
- Sichten nach Clements Module Viewtype Component-Connector-Viewtype Allocation Viewtype
- Sichten nach Clements Module Viewtype Struktur des Systems auf Modulbasis enthält Stile wie Schichten Dekomposition Generalisierung
- Component-Connector-Viewtype Laufzeitsicht des Systems mit Hilfe von Komponenten, Onjekten und Prozessen enthält Stile wie Client-Server oder Shared Data
- Sichten nach Clements Allocation Viewtype Zuordnung von Software zur Umgebung, d. h., Hardware, Ressourcen etc. enthält work assignment und deployment
- Wesentliche Sichten für Architekturen + was stellen diese dar? Statisches strukturelles Modell (wesentliche Systemkomponenten und ihre Interfaces) Dynamisches Prozessmodell (Ablaufverhalten im System) Deployment-Modell (Verteilung der Ressourcen wie Prozessoren, Netzwerkverbindungen etc.)
- Architekturkonzepte - Struktursicht Components (Funktionalität und Daten) Connectors (Informationsaustausch / Kommunikation) Configurations (Beschreibung der konkreten Architektur)
- Was ist eine Komponente (aus Struktursicht) Systemmodul, das seinen Inhalt und seine Funktion kapselt. Das Verhalten der Komponente wird über seine provided und required Interfaces definiert. Eine Komponente kann ausgetauscht werden. Realisieren die Prinzipien Abstraktion, Modularität und Kapselung Eigenschaften: Keinen Zustand, Dokumentierte Interfaces für unabhängiges Deployment, Komponierpat und deployable (Aufwand für Verwender soll transparent bleiben)
- Interfaces (aus Struktursicht) bestehen aus: Signatur: Funktionen mit Input- und Output-Typ Semantik : EIne (formale) Beschreibung der Bedeutung der Funktionen.
- Provided Interfaces (geben was an?) wie die Komponente benutzt werden soll
- Required Interfaces (geben was an?) welche anderen Funktionalitäten benötigt werden.
- Wann kann Komponente B für eine andere Komponente A eingesetzt werden? Genau dann wenn die provided Interfaces von A durch B bewahrt oder erweitert werden und die required Interfaces von B die gleichen oder weniger sind als die von A
- Was sind Konnektoren (Aus Struktursicht) verbinden Komponenten (eine Komponente stellt einen Service für eine andere Komponente bereit)
- Rollen von Konnektoren Kommunikation (zwischen Komponenten) Koordination (Austausch des Kontrollflusses) Konversion (Umformung von Informationen für heterogene Komonenten) Facilitation (Vermittlung von Komponenten-Interatktionen) z. B. Load Balancing, Scheduling etc.
- Konnektoren - Implementierungsmöglichekeiten Einfach: - Methodenaufrufe - Shared Variable Access Komplex: client-Server Protokolle Datenbankzugangs Protokolle Asynchroner Event Multicast Piped data streams
- Probleme mit Konnektoren manchmal keine scharfe Abgrenzung zu Komponenten Durch Komponenten-Interfaces bestimmt Implementierung Mapping auf Komponenten (oder Middleware / OS / Hardware) notwendig
- Konfigurationen (aus Struktursicht) verbundener Graph von Komponeten und Konnektoren, der die Struktur der Architektur beschreibt bestimmt Eigenschaften von Nebenläufigkeit und Verteilung sollen sich an Architekurstil und Design-Richtlinien halten
-
- 5 Architekturbeschreibungssprachen (ADLs) UML Acme AADL (Architecture Analysis & Design Language) Darwin MontiArc
- MontiArc Texutelle ADL, mit wichtigsten ADL-Elementen: Komponenten (einfach und hierarchisch), Interfaces (Ports), Konnektoren, Konfigurationen Autoconnect verbindet Ports mit gleichem Typ und gleichem Namen
- Was ist eine ADL? Metamodelle/ -beschreibungssprachen
- Anforderungen an Architekturdokumentation Zweck und Zielgruppenorientierung Präzision, Eindeutigkeit Standardisiert Nachvollziebarkeit von Entscheidungen Aktualität
