Vorlesung 1: Was ist Softwarearchitektur? Flashcards
Definiere Softwarearchitektur.
Es gibt keine allgemein anerkannte Definition von Softwarearchitektur
▪ Autoren haben unterschiedliche Schwerpunkte in ihrer Definition:
- Blaupause eines Systems (Strukturen etc.)
- Prozess, wie man zu einem System kommt
Definiere Softwarearchitektur als Blaupause (2 Definitionen)
-> Eine “Blaupause” im Kontext der Softwarearchitektur bezieht sich auf eine detaillierte Vorlage oder ein Modell, das als Leitfaden für die Entwicklung eines Systems dient. Diese Vorlage stellt die Struktur, die Komponenten und die Beziehungen innerhalb des Systems dar und hilft den Entwicklern, ein einheitliches und konsistentes Design zu verfolgen.
1: “Die Software-Architektur definiert die grundlegenden
Prinzipien und Regeln für die Organisation eines
Systems sowie dessen Strukturierung in Bausteine und Schnittstellen und deren Beziehungen zueinander sowie zur Umgebung.”
2: “Die Softwarearchitektur eines Systems ist das Set von Strukturen, das benötigt wird, um über das System zu schlussfolgern. Diese Strukturen umfassen Softwareelemente, deren Beziehungen untereinander und die Eigenschaften beider.”
Mit einzubeziehende Aspekte:
Struktureller Aspekt:
-Bausteine
- Beziehungen (die Verhalten implizieren!)
- Eigenschaften und Attribute
Aspekt der externen Sichtbarkeit (Schnittstellen):
- Extern bereitgestellte Dienste
- Extern sichtbares Verhalten (Leistung, Fehlerbehandlung, etc.)
Governance-Aspekt:
- Grundsätze
- Regel
Definiere Softwarearchitektur als Prozess (2 Definitionen)
1: “Softwarearchitektur ist die Summe der “ Entscheidungen, die man sich wünscht, früh in einem Projekt richtig treffen zu können […] Bei der Architektur geht es um die
wichtigen Dinge. Was auch immer das ist.”
2: “Die Struktur der Komponenten, ihre Wechselbeziehungen sowie die Prinzipien und Richtlinien, die ihr Design und ihre Entwicklung im Laufe der Zeit bestimmen.”
-> Entscheidungen zu den zuvor genannten Aspekten:
- Bausteine / Strukturen / Schnittstellen
- Prinzipien / Regeln
-> Entscheidungen zu weiteren Aspekten:
- Technologieauswahl
- Architektonischer Stil
- Nicht-funktionale Anforderungen (NFRs) - und deren Umsetzung!
Entwicklung der Software-Architektur im Laufe der Zeit
Software-Architektur ist das Ergebnis von relevanten Architekturentscheidungen
Was sind die Implikationen der vorhandenen Definitionen von Softwarearchitektur?
1: “Ein System ist eine „Gruppe von interagierenden, voneinander abhängigen Elementen, die zusammen ein komplexes Ganzes bilden”
Die Softwarearchitektur definiert die Elemente eines “Systems”.
- Legt fest, wie sich die Elemente zueinander “verhalten”.
- Die Elemente basieren auf Abstraktionen (sind abstrakt)
▪ Das Verhalten ist immer Teil der Architektur
- Legt fest, welche Elemente miteinander interagieren
- Legt fest, wie Elemente interagieren
▪ Softwarearchitektur entwickelt sich mit der Zeit (“evolutionäre Architektur”)
▪ Jedes System hat eine Architektur!
- Basiert auf den Entscheidungen, die während des Lebenszyklus getroffen wurden
- Entweder gut oder schlecht
Beschreibe die Systemtheorie
Systemmerkmale:
- Systeme sind hierarchisch strukturiert (können in Teilsysteme/Komponenten zerlegt werden)
- Veränderungen in einem Teilsystem wirken sich auf andere Teilsysteme aus (Holismus)
- Systemgrenzen grenzen das System zu seinem Kontext ab
Jedes System muss im Kontext gesehen werden:
- Teilsysteme können am besten in ihrem Kontext (d.h. in Beziehung zu anderen Teilsystemen) verstanden werden
- Das Gesamtsystem lässt sich am besten in seinem Kontext verstehen (d.h. in Bezug auf andere Systeme)
▪ Die Gesamtleistung eines Systems ist wichtiger als die Leistung der einzelnen Komponenten (Synergie)!
▪ Um ein System zu verstehen, ist der nicht-technische Kontext eines Systems relevant
Nenne und beschreibe die Elemente der Systemtheorie im Kontext der Softwarearchitektur.
Umwelt (externe Faktoren, die das System beeinflussen):
- Außerhalb der Organisation: Vorschriften, externe Stakeholder, etc.
- Innerhalb der Organisation: Richtlinien, interne Stakeholder, etc.
Transformationsprozess (das System selbst):
- Bereitgestellte Funktionalitäten, die Inputs verarbeiten und Outputs produzieren/liefern
- Kann in verschiedene Komponenten / Subsysteme unterteilt werden
Inputs (Dinge, die vom System “verwendet” werden):
- Manuelle Dateneingabe
- Daten / Ereignisse aus Quellsystemen
Outputs (Dinge, die vom System bereitgestellt werden):
- Bereitgestellte Dienste
-Informationen
Was Ziel und Zweck der Software-Architektur?
▪ Ermöglichung und Unterstützung der Langlebigkeit eines Systems
− Schaffe einen „Gestaltungsraum“, der die Entwicklung eines Systems einschränkt und leitet
- Die Langlebigkeit eines Systems ist nicht gleichzusetzen mit der Langlebigkeit seiner Architektur (!)
− Baue das Rahmenwerk für Veränderung / Weiterentwicklung (!)
- Sicherstellung der Wartbarkeit
▪ Verständlichkeit und konzeptionelle Integrität ermöglichen
-Mache Komplexität beherrschbar und verständlich
− Ermögliche einen Überblick darüber, wie Dinge funktionieren
▪ Erfüllen Sie funktionale und
Qualitätsanforderungen (d.h. NFRs)
▪ Werte aller Stakeholder erfüllen
Nenne die 4 Grundbausteine der Softwarearchitektur.
- Qualitätsanforderungen:
- Entwurfsprinzipien und Muster:
- Architekturentscheidungen:
- Strukturen
Beschreibe den Grundbaustein der Softwarearchitektur:
1. Qualitätsanforderungen
▪ Auch als Qualitätsattribute oder Architektureigenschaften bezeichnet
▪ Beziehen sich oft auf architektonisch bedeutende Anforderungen (ASRs)
▪ Definieren die „Erfolgskriterien“ eines Systems
▪ Sind unabhängig von funktionalen Anforderungen
▪ Typischerweise als nicht-funktionale Anforderungen (NFRs) definiert: Sicherheit, Skalierbarkeit, Zuverlässigkeit, Elastizität, Testbarkeit, Bereitstellbarkeit
Beschreibe den Grundbaustein der Softwarearchitektur:
2. Entwurfsprinzipien und Muster
▪ Entwickle Richtlinien, wie Dinge implementiert werden sollten
▪ Stelle keine harten Vorschriften auf, sondern leite die Entwicklung an
▪ In Bezug auf das Design von Systemen können einige Prinzipien verallgemeinert werden:
− Trennung der Anliegen (Separation of Concerns, SoC)
− You Ain’t Gonna Need It (YAGNI)
− Keep It Simple, Stupid (KISS)
▪ Einbezug der Qualitätsanforderungen
Beschreibe den Grundbaustein der Softwarearchitektur:
3. Architekturentscheidungen
▪ Definiere die unbedingt zu befolgenden Regeln dafür, wie ein System konstruiert werden sollte.
▪ Entscheidungen betreffen typischerweise alle anderen Bausteine:
− Qualitätsanforderungen
− Strukturen: Welche Schichten dürfen auf einen Datenspeicher zugreifen?
− Designmuster: Welcher Kommunikationsstil sollte zwischen Modulen verwendet werden?
▪ Ausnahmen: Manchmal können Regeln nicht umgesetzt und müssen gebrochen werden.
▪ Wenn Softwarearchitektur das Ergebnis der getroffenen Entscheidungen ist: Dokumentation ist entscheidend!
Beschreibe den Grundbaustein der Softwarearchitektur:
4. Strukturen
Bezieht sich in der Regel auf den Architekturstil, in dem das System implementiert ist (“Das ist eine xyz-Architektur”).
Unterscheidung zwischen Sichten, Sichtweisen und Strukturen:
-Eine Sicht ist eine Darstellung von Architekturelementen (Abstraktion!).
-Eine Sichtweise ist eine Konvention zur Konstruktion einer Sicht aus der Perspektive eines Stakeholders.
-Eine Struktur ist eine Menge von Elementen, wie sie existieren.
Strukturen werden in (manchmal mehreren) Sichten entworfen und dokumentiert.
Es gibt verschiedene Arten von Strukturen:
-Modulstrukturen (Funktionsblöcke und Beziehungen / Implementierungseinheiten)
-Komponenten- und Verbindungsstrukturen (Laufzeitverhalten und Interaktionen; z. B. Dienste, Clients, Datenspeicher)
-Zuweisungsstrukturen (Beziehungen zu Nicht-Software-Elementen; z. B. Netzwerke, Dateisysteme, Entwicklungsteams)
Nenne Standards der Softwarearchitektur.
Standards für Softwarearchitektur (oder Standards, die Softwarearchitektur umfassen) existieren für verschiedene Zwecke:
The Open Group Architecture Framework (TOGAF): Architekturrahmenwerk, das Methoden und Werkzeuge für die Akzeptanz, Produktion, Nutzung und Wartung einer Unternehmensarchitektur bereitstellt. Umfasst ein Prozessmodell und bewährte Praktiken.
ISO/IEC/IEEE 42010 Systems and software engineering – Architecture description:
Standard, der auf die Beschreibung (d.h. Dokumentation) von Softwarearchitekturen abzielt.
ISO/IEC/IEEE 42020 Software, systems and enterprise – Architecture processes:
Definiert Prozesse für die Governance und das Management von Architekturen sowie das Entwerfen von Systemen.
ARC42:
Standard (d.h. Vorlage) für Architekturkommunikation und -dokumentation.
Bitte ordne Software Architektur in den Kontext des Anforderungsmanagements, der Projektplanung, Risikobewertung, Organisatorisch, Softwareentwicklung, Betrieb, Hardwarearchitektur, Qualitätssicherung ein.
Anforderungsmanagement:
-Definiert funktionale und nicht-funktionale Anforderungen.
-Architektur muss diese Anforderungen widerspiegeln.
-Technische Machbarkeit und Kosten müssen bewertet werden.
-Architektur kann Anforderungen einschränken.
Projektplanung:
-Schafft ein gemeinsames Verständnis für komplexe Aufgaben.
-Zerlegt komplexe Aufgaben für bessere Schätzungen und Planung.
Risikobewertung:
-Identifiziert und bewertet organisatorische und technische Risiken.
-Entwickelt Lösungen zur Risikominderung
Organisatorischer Kontext:
-Motivation und Erfahrung aller Stakeholder
-Zeitplan und Budget der Projekte
-Entwicklungsprozesse
-Organisationsstrukturen
Softwareentwicklung (Implementierung):
-Die Softwarearchitektur bildet die abstrakten Grenzen jeder Implementierung.
-Architekturentscheidungen beeinflussen direkt die Implementierung bestimmter Aspekte.
-Softwarearchitekten sind oft an der Implementierung beteiligt und bieten Entwicklern Anleitung.
-Technische Implementierungsdetails können die Softwarearchitektur beeinflussen.
Betrieb:
-Die Softwarearchitektur bestimmt die Laufzeitumgebung.
-Randbedingungen können die Softwarearchitektur einschränken.
Hardwarearchitektur:
-Software- und Hardwarearchitektur beeinflussen sich gegenseitig und müssen zusammen entwickelt werden.
-Besonders wichtig in Bezug auf nicht-funktionale Anforderungen (Leistung, Sicherheit, Verfügbarkeit usw.).
-Kritisch für eingebettete Systeme.
Qualitätssicherung:
-Whitebox-Tests erfordern ein Verständnis der Softwarearchitektur (zumindest bis zu einem gewissen Grad).
-Softwarearchitekten können Qualitätsingenieuren helfen, die
-Testbarkeit von Anforderungen zu bewerten.
-Identifizierte Projektrisiken (im Zusammenhang mit der Softwarearchitektur) können die Qualitätssicherung unterstützen.
